# A Measurement Study of BLE iBeacon and Geometric Adjustment Scheme for Indoor Location-Based Mobile Applications

Authors: Jeongyeup Paek; JeongGil Ko; Hyungsik Shin
Journal: Mobile Information Systems
 (2016)

---

## Abstract

Bluetooth Low Energy (BLE) and the iBeacons have recently gained large interest for enabling various proximity-based application services. Given the ubiquitously deployed nature of Bluetooth devices including mobile smartphones, using BLE and iBeacon technologies seemed to be a promising future to come. This work started off with the belief that this was true: iBeacons could provide us with the accuracy in proximity and distance estimation to enable and simplify the development of many previously difficult applications. However, our empirical studies with three different iBeacon devices from various vendors and two types of smartphone platforms prove that this is not the case. Signal strength readings vary significantly over different iBeacon vendors, mobile platforms, environmental or deployment factors, and usage scenarios. This variability in signal strength naturally complicates the process of extracting an accurate location/proximity estimation in real environments. Our lessons on the limitations of iBeacon technique lead us to design a simple class attendance checking application by performing a simple form of geometric adjustments to compensate for the natural variations in beacon signal strength readings. We believe that the negative observations made in this work can provide future researchers with a reference on how well of a performance to expect from iBeacon devices as they enter their system design phases.


---

## Body

## 1. Introduction

Bluetooth is ubiquitous in today’s everyday life, used in laptops, mobile devices, keyboards, headsets, and many other consumer electronics for wire replacement. Bluetooth Low Energy (BLE) is an extension of the Bluetooth standard in version 4.0 that enables low-power low-cost short-range wireless communication [1, 2]. It has significantly reduced its power consumption, among other extended features, compared to classical Bluetooth versions, and is now possible to run BLE devices for several months to even a couple years on a coin cell battery. Such aspects make BLE ideal for applications requiring infrequent or periodic transfers of small amount of data; thus, it can be applied in a wide range of medical, industrial, and consumer applications.iBeacon is a BLE-based proximity sensing framework proposed by Apple [3], which allows a mobile device to detect its proximity to an iBeacon station (and possibly its location) by knowing how close it is to (usually wall-mounted) low-complexity, low-cost BLE transmitters, the iBeacons. Each iBeacon transmits periodically short identification frames that are received by a mobile BLE device to estimate the distance between the mobile device and the iBeacon using received signal strength indicator (RSSI). Based on this detection of proximity, iBeacons provide automatic and location specific triggering of services on the mobile device such as advertising, coupons, or route guidance. Although the specifications of the iBeacon were initially proposed by Apple (iOS7 or later), it is just one way of utilizing BLE’s proximity features, and thus it is (and can be made) compatible with other devices (e.g., Android 4.3 or later) that use BLE. More generally, any BLE device can use the same concept to provide similar proximity functionality. Technically, iBeacon technology is a subset of BLE beacons, but iBeacon and BLE proximity beacons became nearly synonyms today despite Google’s recent release of their own open beacon format called Eddystone (Eddystone is a protocol specification by Google that defines a Bluetooth Low Energy message format for proximity beacon messages) [4].Note here that the original goal of BLE beacons was to provide proximity-based application services, possibly to extend the features to coarse-grained location-based applications. Given that BLE beacons solely focus on RSSI measurements, combined with lessons learned from the long history of research in RF-based localization, it is somewhat expected to be able to achieve only a limited accuracy in indoor localization services. It is well known that the variability of RF signals with respect to the indoor environment complicates the accurate estimation of the mobile devices’ location or its relative distance to the BLE beaconing transmitter device. However, most prior work on BLE-based indoor localization merely states the possibility of error due to signal variation but does not quantify them, and their reported results show only the positive side of the picture. For example, the work in [5] reports a positioning accuracy of 0.53 meters, but this work was bounded by a 9 × 10 m2 area. The work in [6] reports a 1.2-meter accuracy with fingerprinting, but only within a 47.4 × 15.9 m2 area. Recently work in [7] shows that distance estimation error can increase significantly with longer distance when the measured signal RSSI vary over time but does not show other dimensions of possible error.In this work, we perform an extensive set of experiments to quantify the impact of various indoor obstacles on the BLE signal variance. Specifically, we show that different iBeacon devices from different vendors along with the paired mobile device platform (e.g., iOS or Android) can give significant impact on the RSSI measurements to complicate the process of designing a generally acceptable distance/location estimation model. Furthermore, practical factors such as the deployment height or environmental factors also introduce a significant amount of impact on the RSSI values to introduce an additional level of complexity in designing highly accurate location estimation systems using iBeacons. Lessons from these empirical studies lead us to design an application that is “practically designable.” Specifically, we design and evaluate a class attendance monitoring application system, by combining distance estimations made from locally accessible iBeacon signals and an estimation adjustment scheme designed from the lessons from our empirical signal measurements.This paper is structured as follows. Section2 introduces the relationship between RSSI readings and the estimated distances and then motivates our empirical studies on the relationship. Section 3 describes our approaches to the empirical studies and experiment settings including various parameters that we change during our studies. Section 4 is the main section, and it describes our measurements data and illustrates our analysis results based on the data. Section 5 presents an application case study, an automatic attendance monitoring system, which is based on our empirical studies. This system also proposes a novel geometric approach to overcome the limitations of practical iBeacon systems. Section 6 reviews prior and related work and finally Section 7 concludes the paper.


## 2. Limitations of Bluetooth Low Energy-Based Localization Systems

As Bluetooth Low Energy (BLE) and Apple’s iBeacon protocols begin to see widespread adoption and deployment, indoor proximity and/or location enabled applications are quickly penetrating into our everyday lives and consumer space. iBeacon has been installed in Apple stores in the US to provide product information as well as customer services, and the National Football League (NFL) has used iBeacons in the MetLife Stadium to provide personalized advertisements to football fans during the Super Bowl game [8]. Furthermore, iBeacon can be used to track luggage at the airport [9], provide interactive experiences to visitors in museums [10], plan evacuation paths in emergency guiding systems [11], track patients in emergency rooms [12], guide indoor/outdoor routes [13, 14], and detect the occupancy of rooms [15, 16]. The application space to which iBeacons and BLE proximity applications can be applied is extremely large. These applications all use proximity measurements based on the received signal strength indicator (RSSI) as the sole source of information; thus, these applications exploit information on how close a mobile device is to an iBeacon rather than trying to pinpoint the exact and absolute location of the mobile device.The original purpose of iBeacon technology is to provide proximity-based application services and coarse-grained indoor location positioning and navigation based solely on proximity. Note that proximity (being near to some object) is related to the location (where you are) but is not necessarily identical. A location (or position) is more than just proximity, and it is an absolute value usually defined by some coordinate system (e.g., latitude and longitude for GPS). Recently, however, there have been several proposals to use BLE for indoor positioning, extending several prior works that use other technologies such as ultrasonic sound, infrared, WiFi, GSM, RFID, IEEE802.15.4, and earlier versions of Bluetooth for indoor localization [17–22] (there are many more related prior work on indoor localization that uses other wireless technologies, but we list only a subset here for brevity and to keep the reference list focused on BLE only since there are too many of them). Indoor positioning and localization are still an active area of research, and BLE is extending the literature using its new wireless features.There are several approaches (beyond simple proximity-based ones [12]) that can be applied to BLE-based indoor positioning. In all cases, an iBeacon will periodically broadcast an advertisement packet containing a unique ID and a calibrated RSSI value (R0) corresponding to one-meter distance (d0). This value allows us to determine the distance between an iBeacon and a device using a model in (1), where γ is a calibration parameter for the path loss exponent. Based on the RSSI or the estimated distances between iBeacons and a mobile device, a weighted average model [5], trilateralization/triangulation model [23], or fingerprinting [7, 24] can be applied for the localization process. The estimations can also be combined with Pedestrian Dead Reckoning (PDR) or filtering techniques to improve tracking or to reduce positioning errors [6, 25]. Of course, all of these approaches assume that all installed iBeacons possess their predefined location information including their exact coordinates.(1)RSSI=R0-10γlog⁡d^d0⟹d^=10R0-RSSI/10γ.If distances are used instead of raw RSSI values for positioning, RF propagation model such as (1) is used to convert RSSI readings into distances. The main challenge here is the sensitivity of RSSI values to environment changes such as object movements or obstacles, which result in signal propagation or radio map changes. It is obvious that the accuracy and efficiency of this distance estimation (and thus the location estimation) depend heavily on the accuracy of the measured RSSI values and the model used to derive and calculate the distance and also significantly influenced by the surrounding environment. Therefore, in this work, we perform a detailed empirical measurement study on the location/distance estimation performance based on RSSI measurements for different types of iBeacon devices and mobile device platforms. We consider various environmental factors to gather a practical perspective on the performance limitations of iBeacon technologies.


## 3. Approach and Experiment Setup

We carried out experiments in two different environments: an open soccer field of a university campus without any obstacles and an unblocked corridor of an office building to ensure line-of-sight (LOS) signal propagation. In these environments, we used three different types of iBeacons: Estimote [26], Wizturn Pebble [27], and GELO [28] iBeacons to examine differences in performance among vendors. Furthermore, we used two different mobile devices: iPhone 5 with iOS 7.1.2 and Galaxy Round (SM-G910S) with Android 4.4.2, to verify any existing particularities. Mobile applications used for data collection are the applications provided by the respective iBeacon vendors: “Estimote app” for Estimote iBeacons, “GELO toolkit app” for GELO iBeacons, and “Wizturn beacon manager” app for Wizturn Pebble iBeacons (Figure 1).Figure 1
Three different types of iBeacons used for the experiments: top row shows the images of the Estimote, GELO, and Wizturn Pebble iBeacons. Bottom row shows the icons of their corresponding smartphone applications.The default configuration parameters used in the experiments are as follows. The transmission (TX) power of iBeacon was set to the maximum of 4 dBm unless stated otherwise to verify the maximum distance that can be covered by any iBeacon. We also experiment with minimum TX power (which is −19~−23 dBm depending on the device) to observe the lower-bounds of connectivity. The advertising interval of the iBeacons was set to 950 milliseconds, which was the factory default for all three devices. Device placement height from ground was set to 1.2 meters for both the iBeacons and the mobile phones unless stated otherwise. We selected this height of 1.2 meters to imitate the height at which a user holds their mobile device in their hands. Finally, the orientation of the iBeacon was set to face the direction of LOS towards the mobile device. Using these configurations, a mobile application continuously detected signals from iBeacons and logged their RSSI measurements while the distance between the iBeacon and the mobile device was increased from 1 meter to the maximum distance and recorded manually until reaching the maximum distance. Here, we note that the maximum distance is defined to be the farthest distance where the RSSI value can be detected by the device. At each location (e.g., relative distance to the iBeacon) we took twenty RSSI measurements for each configuration.


## 4. Measurement Data Analysis

In this section, we focus on identifying and quantifying the various characteristics related to the performance of iBeacons for localization applications by carefully analyzing the extensive measurement data that we have collected.


### 4.1. Difference between iOS and Android Phones

We first start by comparing the differences between iPhone 5 with iOS 7.1.2 and Galaxy Round (SM-G910S) with Android 4.4.2 in receiving iBeacon signals. The experiment was conducted outdoors in an open soccer field using an Estimote beacon with 4 dBm TX power at 1.2-meter height in LOS. Figure2 presents our results from this experiment, where the dotted line represents the average RSSI reading at each distance, and the boxes represent the 25 and 75 percentile values along with their minimum and maximum error bars.Figure 2
Distance versus RSSI plot for iOS and Android comparison. (Estimote, 4 dBm TX power, 1.2 m height, and LOS).From this result, we can identify several interesting facts. First, compared to the 100 meters for the Android platform, iOS showed notably shorter maximum distances of 85 meters. Note that the 100 meters observed for the Android is not the actual maximum distance, given that 100 m was the maximum length we could achieve for LOS links in our environment. Therefore, the difference between the maximum distances of the two platforms turned out to be very large. Second, RSSI readings on Android phone decreased more gradually whereas iOS showed a sudden drop in RSSI after ~10 meters. Lastly, RSSI readings on the Android platform had more temporal variation than iOS. While it is difficult to conclude whether the hardware specification shows any difference or this is an effect of the software platform, it is known that there is a difference between iOS and Android in scanning and sampling iBeacon advertisements [16]. More importantly, the RSSI readings differ between different phones (regardless of it being an impact of the operating system or the hardware), and we should point out that this effect itself will have significant implications for distance estimation and localization, causing difficulties for the application developers to generalize information extracted from the collected RSSI values.


### 4.2. Effect of Device Placement Height

In this experiment, we examine the impact of the iBeacon installation height from the ground on RSSI. For this, we place an Estimote beacon on the ground (e.g., 0-meter height) and measure the RSSI readings using the Android mobile phone. We compare this value with the case when the same beacon is installed at a 1.2-meter height. Figure3 shows the result from this experiments. We can first notice that the values are substantially different for the two experiment cases. When the iBeacon is placed on the ground while all other configurations are identical, the maximum distance reduces from 100+ meters to only 12 meters with significant and drastic drop in RSSI. This result implies that the placement of iBeacon is very important when designing and deploying an iBeacon system. Distance estimation and thus the localization accuracy can be significantly impacted by the precise placement of iBeacons, and planning the installation carefully as part of the site survey will be very important. Based on our experimental data, the optimistic advertisements that declare “ease of deployment” and “place nodes anywhere!” may not be valid when targeting precise accuracy on the iBeacon systems.Figure 3
Distance versus RSSI plot that shows the impact of device placement height from ground (Estimote, 4 dBm TX power, and Android).


### 4.3. Difference between iBeacons from Different Manufacturers

Next, we compare the RSSI reading differences between different iBeacon products for three different manufacturers: Estimote, GELO, and Wizturn Pebble. iPhone5 was used as the mobile device, and both the beacons and the mobile devices were installed at 1.2 meters’ height in an outdoor soccer field. One important thing to note is that the maximum transmission power supported by GELO iBeacon was 0 dBm whereas Estimote and Wizturn Pebble allowed configuration up to 4 dBm. We used respective maximum powers for each device to examine the maximum distance coverage. Our initial intuition was that GELO iBeacon will exhibit 4 dBm lower RSSI values compared to other beacons at identical distances, and thus it will result in a shorter maximum transmission distance.Surprisingly, Figure4 shows that, unlike our expectation, GELO along with Wizturn beacons shows a maximum distance of 100+ meters, far exceeding Estimote’s 85 meters. Furthermore, the RSSI readings were all similar between distinct iBeacon types despite the 4 dBm difference in transmission power. This implies several interesting points. First, the configured TX power difference does not directly translate into received RSSI reading difference, which makes the calibration process for distance estimation (and thus indoor localization) more challenging when the transmission power must be adjusted for the given environment. Second, iBeacons from different vendors exhibit different maximum distances, and higher maximum TX power configuration does not necessarily lead to longer maximum transmission distances. Lastly, due to the aforementioned reasons, it will be very challenging for application developers and service providers to design an iBeacon-based system with heterogeneous iBeacons since multiple sets of calibration parameters will be required for each pair of iBeacon and mobile device type. Again, these results imply that designing a reasonably reliable iBeacon-based localization system can be extremely challenging.Figure 4
Distance versus RSSI plot for three different types of iBeacons: Estimote, GELO, and Wizturn Pebble (4 dBm/0 dBm TX power, 1.2 m height, LOS, and iOS).


### 4.4. Reducing to Minimum TX Power

We now focus on the fact that not all systems fully benefit from the use of maximum transmission power. For example, if we are designing an indoor localization system based on trilateralization or fingerprinting method, we would prefer a higher transmission power to cover a larger area and/or achieve denser deployments while using fewer number of iBeacons (e.g., for cost reasons). However, when building a system based on only the proximity function, reducing the transmission power to the minimum just enough to cover the target region (e.g., in front of a store or a product for advertisement) while keeping the energy cost low to extend the lifetime of the batteries can be a reasonable system design option. With this motivation in mind, we conducted an experiment using the respective minimum TX power for the three types of beacons. The minimum TX power configuration allowed on Estimote, GELO, and Wizturn Pebble beacons was −20 dBm, −23 dBm, and −19 dBm, respectively.Figure5 depicts the results from this study. First, we observe the drastic drop in the maximum distance (note the different x-axis values compared to the previous figures). Estimote with −20 dBm showed a maximum distance of 8 meters and Wizturn Pebble with −19 dBm gave 8 meters while the RSSI from a GELO beacon with −23 dBm TX power was detectable within only 0.3 meters. The second observation is that while the RSSI reductions for Estimote and Wizturn Pebble approximately matched their reduction in TX power (24 and 23 dBm, resp.), this was not true for the GELO beacons. GELO beacons showed RSSI reductions of 44–58 dBm while the TX power was reduced only by 23 dBm. Again, as our previous results concluded, these differences can cause significant complication when designing a system with multiple types of iBeacons; different TX powers, different reductions in RSSI, and different maximum distances will make the calibration process practically impossible unless only a single TX power configuration and a homogeneous iBeacon from a particular vendor is used for designing the entire system. This may be a plausible approach in the initial system design phase, but with the system scaling overtime for supporting additional regions or new use cases, considerations for heterogeneous systems are a must.Figure 5
Distance versus RSSI plot when minimum transmission power is used by three different types of iBeacons (minimum TX power, 1.2 m height, LOS, and iOS).


### 4.5. Indoors versus Outdoors

iBeacon is often referred to and is well known as an “indoor proximity/location system” because a major motivator for its development was to provide indoor location awareness where the already widely used GPS is unavailable. However, physically, there is no reason why iBeacon cannot be used outdoors. In fact, there are manufacturers (e.g., GELO) that provide durable weather-proof iBeacons for outdoor use. Through our next experiments we wanted to compare the performance of iBeacons in the indoor and outdoor environments. For this, we performed additional experiments in an unblocked 3 meters’ wide corridor of a university building. Here, we use the Estimote beacons and an Android phone, again at 1.2 meters height and 4 dBm TX power so that we can make direct comparisons with our experiments performed outdoors.Figure6 presents our results. To our surprise, after ~25 meters in distance, the RSSI readings remained almost steady, or even increased slightly with distance. The maximum distance is shown as 50 meters only because our corridor within the building was 50 meters’ long, and the actual maximum distance is projected to be longer with more physical space. To verify our unexpected results, we also conducted additional experiments with the Wizturn Pebble and GELO beacons and found similar results (plots omitted for brevity). The only plausible explanation for such behavior is the multipath effect caused from the walls and ceiling of the corridor. What is more important here is the fact that the RSSI value did not decay for a wide range of distances (25–50 m in our case). This means that the distance model in (1) is no longer valid, and any indoor localization method that relies on distance estimation and trilateralization can face large errors in the order of tens of meters. In bolder words, it isnot possible to design an accurate indoor localization system with iBeacons using simple distance estimation.Figure 6
Distance versus RSSI plot for indoor versus outdoor comparison (Estimote, 4 dBm TX power, 1.2 m height, LOS, and Android).


### 4.6. Effect of WiFi on iBeacon Signal Reception

Another issue when using iBeacons for indoor applications is the interference effect of WiFi signals, which operates on the same 2.4 GHz ISM frequency band. BLE was designed to use channels 37, 38, and 39 for advertisement (out of 40 total channels and the remaining 37 channels for data communication), and their allocated frequencies are designed to avoid the most popular WiFi channels 1, 6, and 11 (c.f. Figure7). Unfortunately, the WiFi AP deployment at our university campus used channels 1, 5, and 9, and WiFi channel 5 happens to interfere with BLE channel 38. This is not an unusual case and can occur generally in any WiFi environment. Therefore, we performed an additional experiment to quantify the consequences of WiFi-oriented collisions.Figure 7
Channel frequency allocation for BLE and its relation to WiFi channels 1, 6, and 11.For this experiment, we placed an Estimote beacon directly under a WiFi AP and measured the RSSI readings from an Android phone 5 meters apart (c.f. Figure8). We show a subset of observations in Figure 9 where the x-axis represents the sequence of measurements (e.g., time) and the y-axis is again RSSI. The dotted line with squares shows the readings when WiFi AP was powered off, and the solid line with circles shows the readings when the WiFi AP is in normal operation. The shaded rectangle regions, along with the disconnection in the solid line, represent the cases when there was no iBeacon RSSI reading on the mobile phone, due to the lack of packet reception.Figure 8
Setup for WiFi interference experiment. An Estimote iBeacon was placed vertically below an WiFi AP that uses channel 5, and the receiving Android mobile smartphone was placed 5 meters away. Both the iBeacon and the mobile device were 1.2 meters from the ground.Figure 9
Time versus RSSI plot for a sequence of beacon reception that shows reception failures (packet losses) and reduction in RSSI (identical configuration as Figure8).We make two important observations from this experiment. First, when the WiFi AP is active, the beacon reception ratio dropped to around 75% even at a short distance of 5 meters, a distance where a 100% beacon reception can be achieved without the WiFi AP. Second, even when an iBeacon advertisement was successfully received, the RSSI readings showed significantly lower values (e.g., more than 10 dBm reduction) for ~53% of the beacons. Note that the packet loss of low-power BLE beacons under high-power WiFi interference is somewhat expected, but a consistent reduction in RSSI is an unexpected phenomenon that can be regarded as another type of wireless signal “gray region” [29]. These findings suggest that, with the widely deployed and ubiquitously utilized WiFi in today’s indoor environments, an iBeacon system can be significantly affected with reduced reliability and higher estimation errors.


### 4.7. Effect of Obstacles

In this experiment, we examine the effect of physical obstacles on the iBeacon signal reception and compare against the LOS case. Specifically, here, we considered six different cases: three cases with obstacles of an iron door, a wooden door and a window each, one case for signal amplification using a sheet of aluminum foil, and two cases where the mobile phone is covered by hand or paper. In this experiment, we used the Estimote beacon paired with an iPhone5, and the distance between the iBeacon and the mobile phone was ~3 meters. Again, the height was 1.2 meters and the TX power was 4 dBm.We present the results from this study in Figure10. As expected, the iron door blocked the signal drastically with an RSSI drop of ~20 dBm, but the wooden door or window also had some (nonnegligible) effect of ~3 to 8 dBm drop, while covering the phone with a pile of paper caused a ~6 dBm drop. More interestingly, however, covering the mobile phone with the hands of the user resulted in a noticeable reduction of ~30 dBm. This suggests that, in an indoor localization system, despite undergoing a careful deployment phase and extensive calibrations, the distance and/or position estimation can have significant errors just because the user is holding the phone tightly in his/her hands or the environment changes naturally (e.g., door statuses). This is another challenge in designing an iBeacon-based system since mobile devices will inevitably be held by the users’ hands and obstacle statuses will change actively in an indoor environment.Figure 10
Average RSSI plot for different types of obstacles (Estimote, 4 dBm TX power, 1.2 m height, 3 m distance, and iOS).As a final note, we were able to amplify the beacon signal by using a sheet of aluminum foil behind the iBeacon which resulted in an RSSI increase of 6 dBm. While it is unlikely that iBeacon deployment will intentionally be wrapped in a sheet of aluminum foil, this result suggests that some environmental artifact or ornament can also unexpectedly cause such an effect: implying that obstacles not only reduce the RSSI levels but can also amplify the signal strength.


### 4.8. Distance Estimation Using the Curve-Fitted Model

Finally, we now take all the measurement data from the four iBeacon-mobile device pairs, combination of Estimote and Wizturn Pebble beacons with Android and iOS phones, and fit the data on to the model in (1) using the least-mean square method to calculate the estimated distance based on the RSSI. We note that all data are for the outdoors, LOS, 1.2-meter height, and 4 dBm TX power experiments. We then use this derived model to compare the real distance to the estimated distance as in Figure 11. One point to take away from this plot is the fact that distance estimation can show significant errors even under LOS conditions due to high signal strength variations. Furthermore, the errors increase as distance increases (e.g., as RSSI gets closer to the reception sensitivity). While we omit additional figures for brevity, we note that we can see similar plots even with data from a single pair of iBeacon-mobile device. Quantitatively, the errors can increase from tens of meters to even hundreds of meters. This means that when designing an iBeacon-based system, a system designer should either cope with the large distance estimation errors (and hence positioning errors) or densely deploy a large number of iBeacons to reduce the errors, which can threat the “low-cost” argument in iBeacon systems. Unfortunately, as per our experimental results, neither is satisfactory.Figure 11
Real distance versus estimated distance plot where the previously collected RSSI data was used to curve fit the model in (1) and empirically determine the model parameter.


## 4.1. Difference between iOS and Android Phones

We first start by comparing the differences between iPhone 5 with iOS 7.1.2 and Galaxy Round (SM-G910S) with Android 4.4.2 in receiving iBeacon signals. The experiment was conducted outdoors in an open soccer field using an Estimote beacon with 4 dBm TX power at 1.2-meter height in LOS. Figure2 presents our results from this experiment, where the dotted line represents the average RSSI reading at each distance, and the boxes represent the 25 and 75 percentile values along with their minimum and maximum error bars.Figure 2
Distance versus RSSI plot for iOS and Android comparison. (Estimote, 4 dBm TX power, 1.2 m height, and LOS).From this result, we can identify several interesting facts. First, compared to the 100 meters for the Android platform, iOS showed notably shorter maximum distances of 85 meters. Note that the 100 meters observed for the Android is not the actual maximum distance, given that 100 m was the maximum length we could achieve for LOS links in our environment. Therefore, the difference between the maximum distances of the two platforms turned out to be very large. Second, RSSI readings on Android phone decreased more gradually whereas iOS showed a sudden drop in RSSI after ~10 meters. Lastly, RSSI readings on the Android platform had more temporal variation than iOS. While it is difficult to conclude whether the hardware specification shows any difference or this is an effect of the software platform, it is known that there is a difference between iOS and Android in scanning and sampling iBeacon advertisements [16]. More importantly, the RSSI readings differ between different phones (regardless of it being an impact of the operating system or the hardware), and we should point out that this effect itself will have significant implications for distance estimation and localization, causing difficulties for the application developers to generalize information extracted from the collected RSSI values.


## 4.2. Effect of Device Placement Height

In this experiment, we examine the impact of the iBeacon installation height from the ground on RSSI. For this, we place an Estimote beacon on the ground (e.g., 0-meter height) and measure the RSSI readings using the Android mobile phone. We compare this value with the case when the same beacon is installed at a 1.2-meter height. Figure3 shows the result from this experiments. We can first notice that the values are substantially different for the two experiment cases. When the iBeacon is placed on the ground while all other configurations are identical, the maximum distance reduces from 100+ meters to only 12 meters with significant and drastic drop in RSSI. This result implies that the placement of iBeacon is very important when designing and deploying an iBeacon system. Distance estimation and thus the localization accuracy can be significantly impacted by the precise placement of iBeacons, and planning the installation carefully as part of the site survey will be very important. Based on our experimental data, the optimistic advertisements that declare “ease of deployment” and “place nodes anywhere!” may not be valid when targeting precise accuracy on the iBeacon systems.Figure 3
Distance versus RSSI plot that shows the impact of device placement height from ground (Estimote, 4 dBm TX power, and Android).


## 4.3. Difference between iBeacons from Different Manufacturers

Next, we compare the RSSI reading differences between different iBeacon products for three different manufacturers: Estimote, GELO, and Wizturn Pebble. iPhone5 was used as the mobile device, and both the beacons and the mobile devices were installed at 1.2 meters’ height in an outdoor soccer field. One important thing to note is that the maximum transmission power supported by GELO iBeacon was 0 dBm whereas Estimote and Wizturn Pebble allowed configuration up to 4 dBm. We used respective maximum powers for each device to examine the maximum distance coverage. Our initial intuition was that GELO iBeacon will exhibit 4 dBm lower RSSI values compared to other beacons at identical distances, and thus it will result in a shorter maximum transmission distance.Surprisingly, Figure4 shows that, unlike our expectation, GELO along with Wizturn beacons shows a maximum distance of 100+ meters, far exceeding Estimote’s 85 meters. Furthermore, the RSSI readings were all similar between distinct iBeacon types despite the 4 dBm difference in transmission power. This implies several interesting points. First, the configured TX power difference does not directly translate into received RSSI reading difference, which makes the calibration process for distance estimation (and thus indoor localization) more challenging when the transmission power must be adjusted for the given environment. Second, iBeacons from different vendors exhibit different maximum distances, and higher maximum TX power configuration does not necessarily lead to longer maximum transmission distances. Lastly, due to the aforementioned reasons, it will be very challenging for application developers and service providers to design an iBeacon-based system with heterogeneous iBeacons since multiple sets of calibration parameters will be required for each pair of iBeacon and mobile device type. Again, these results imply that designing a reasonably reliable iBeacon-based localization system can be extremely challenging.Figure 4
Distance versus RSSI plot for three different types of iBeacons: Estimote, GELO, and Wizturn Pebble (4 dBm/0 dBm TX power, 1.2 m height, LOS, and iOS).


## 4.4. Reducing to Minimum TX Power

We now focus on the fact that not all systems fully benefit from the use of maximum transmission power. For example, if we are designing an indoor localization system based on trilateralization or fingerprinting method, we would prefer a higher transmission power to cover a larger area and/or achieve denser deployments while using fewer number of iBeacons (e.g., for cost reasons). However, when building a system based on only the proximity function, reducing the transmission power to the minimum just enough to cover the target region (e.g., in front of a store or a product for advertisement) while keeping the energy cost low to extend the lifetime of the batteries can be a reasonable system design option. With this motivation in mind, we conducted an experiment using the respective minimum TX power for the three types of beacons. The minimum TX power configuration allowed on Estimote, GELO, and Wizturn Pebble beacons was −20 dBm, −23 dBm, and −19 dBm, respectively.Figure5 depicts the results from this study. First, we observe the drastic drop in the maximum distance (note the different x-axis values compared to the previous figures). Estimote with −20 dBm showed a maximum distance of 8 meters and Wizturn Pebble with −19 dBm gave 8 meters while the RSSI from a GELO beacon with −23 dBm TX power was detectable within only 0.3 meters. The second observation is that while the RSSI reductions for Estimote and Wizturn Pebble approximately matched their reduction in TX power (24 and 23 dBm, resp.), this was not true for the GELO beacons. GELO beacons showed RSSI reductions of 44–58 dBm while the TX power was reduced only by 23 dBm. Again, as our previous results concluded, these differences can cause significant complication when designing a system with multiple types of iBeacons; different TX powers, different reductions in RSSI, and different maximum distances will make the calibration process practically impossible unless only a single TX power configuration and a homogeneous iBeacon from a particular vendor is used for designing the entire system. This may be a plausible approach in the initial system design phase, but with the system scaling overtime for supporting additional regions or new use cases, considerations for heterogeneous systems are a must.Figure 5
Distance versus RSSI plot when minimum transmission power is used by three different types of iBeacons (minimum TX power, 1.2 m height, LOS, and iOS).


## 4.5. Indoors versus Outdoors

iBeacon is often referred to and is well known as an “indoor proximity/location system” because a major motivator for its development was to provide indoor location awareness where the already widely used GPS is unavailable. However, physically, there is no reason why iBeacon cannot be used outdoors. In fact, there are manufacturers (e.g., GELO) that provide durable weather-proof iBeacons for outdoor use. Through our next experiments we wanted to compare the performance of iBeacons in the indoor and outdoor environments. For this, we performed additional experiments in an unblocked 3 meters’ wide corridor of a university building. Here, we use the Estimote beacons and an Android phone, again at 1.2 meters height and 4 dBm TX power so that we can make direct comparisons with our experiments performed outdoors.Figure6 presents our results. To our surprise, after ~25 meters in distance, the RSSI readings remained almost steady, or even increased slightly with distance. The maximum distance is shown as 50 meters only because our corridor within the building was 50 meters’ long, and the actual maximum distance is projected to be longer with more physical space. To verify our unexpected results, we also conducted additional experiments with the Wizturn Pebble and GELO beacons and found similar results (plots omitted for brevity). The only plausible explanation for such behavior is the multipath effect caused from the walls and ceiling of the corridor. What is more important here is the fact that the RSSI value did not decay for a wide range of distances (25–50 m in our case). This means that the distance model in (1) is no longer valid, and any indoor localization method that relies on distance estimation and trilateralization can face large errors in the order of tens of meters. In bolder words, it isnot possible to design an accurate indoor localization system with iBeacons using simple distance estimation.Figure 6
Distance versus RSSI plot for indoor versus outdoor comparison (Estimote, 4 dBm TX power, 1.2 m height, LOS, and Android).


## 4.6. Effect of WiFi on iBeacon Signal Reception

Another issue when using iBeacons for indoor applications is the interference effect of WiFi signals, which operates on the same 2.4 GHz ISM frequency band. BLE was designed to use channels 37, 38, and 39 for advertisement (out of 40 total channels and the remaining 37 channels for data communication), and their allocated frequencies are designed to avoid the most popular WiFi channels 1, 6, and 11 (c.f. Figure7). Unfortunately, the WiFi AP deployment at our university campus used channels 1, 5, and 9, and WiFi channel 5 happens to interfere with BLE channel 38. This is not an unusual case and can occur generally in any WiFi environment. Therefore, we performed an additional experiment to quantify the consequences of WiFi-oriented collisions.Figure 7
Channel frequency allocation for BLE and its relation to WiFi channels 1, 6, and 11.For this experiment, we placed an Estimote beacon directly under a WiFi AP and measured the RSSI readings from an Android phone 5 meters apart (c.f. Figure8). We show a subset of observations in Figure 9 where the x-axis represents the sequence of measurements (e.g., time) and the y-axis is again RSSI. The dotted line with squares shows the readings when WiFi AP was powered off, and the solid line with circles shows the readings when the WiFi AP is in normal operation. The shaded rectangle regions, along with the disconnection in the solid line, represent the cases when there was no iBeacon RSSI reading on the mobile phone, due to the lack of packet reception.Figure 8
Setup for WiFi interference experiment. An Estimote iBeacon was placed vertically below an WiFi AP that uses channel 5, and the receiving Android mobile smartphone was placed 5 meters away. Both the iBeacon and the mobile device were 1.2 meters from the ground.Figure 9
Time versus RSSI plot for a sequence of beacon reception that shows reception failures (packet losses) and reduction in RSSI (identical configuration as Figure8).We make two important observations from this experiment. First, when the WiFi AP is active, the beacon reception ratio dropped to around 75% even at a short distance of 5 meters, a distance where a 100% beacon reception can be achieved without the WiFi AP. Second, even when an iBeacon advertisement was successfully received, the RSSI readings showed significantly lower values (e.g., more than 10 dBm reduction) for ~53% of the beacons. Note that the packet loss of low-power BLE beacons under high-power WiFi interference is somewhat expected, but a consistent reduction in RSSI is an unexpected phenomenon that can be regarded as another type of wireless signal “gray region” [29]. These findings suggest that, with the widely deployed and ubiquitously utilized WiFi in today’s indoor environments, an iBeacon system can be significantly affected with reduced reliability and higher estimation errors.


## 4.7. Effect of Obstacles

In this experiment, we examine the effect of physical obstacles on the iBeacon signal reception and compare against the LOS case. Specifically, here, we considered six different cases: three cases with obstacles of an iron door, a wooden door and a window each, one case for signal amplification using a sheet of aluminum foil, and two cases where the mobile phone is covered by hand or paper. In this experiment, we used the Estimote beacon paired with an iPhone5, and the distance between the iBeacon and the mobile phone was ~3 meters. Again, the height was 1.2 meters and the TX power was 4 dBm.We present the results from this study in Figure10. As expected, the iron door blocked the signal drastically with an RSSI drop of ~20 dBm, but the wooden door or window also had some (nonnegligible) effect of ~3 to 8 dBm drop, while covering the phone with a pile of paper caused a ~6 dBm drop. More interestingly, however, covering the mobile phone with the hands of the user resulted in a noticeable reduction of ~30 dBm. This suggests that, in an indoor localization system, despite undergoing a careful deployment phase and extensive calibrations, the distance and/or position estimation can have significant errors just because the user is holding the phone tightly in his/her hands or the environment changes naturally (e.g., door statuses). This is another challenge in designing an iBeacon-based system since mobile devices will inevitably be held by the users’ hands and obstacle statuses will change actively in an indoor environment.Figure 10
Average RSSI plot for different types of obstacles (Estimote, 4 dBm TX power, 1.2 m height, 3 m distance, and iOS).As a final note, we were able to amplify the beacon signal by using a sheet of aluminum foil behind the iBeacon which resulted in an RSSI increase of 6 dBm. While it is unlikely that iBeacon deployment will intentionally be wrapped in a sheet of aluminum foil, this result suggests that some environmental artifact or ornament can also unexpectedly cause such an effect: implying that obstacles not only reduce the RSSI levels but can also amplify the signal strength.


## 4.8. Distance Estimation Using the Curve-Fitted Model

Finally, we now take all the measurement data from the four iBeacon-mobile device pairs, combination of Estimote and Wizturn Pebble beacons with Android and iOS phones, and fit the data on to the model in (1) using the least-mean square method to calculate the estimated distance based on the RSSI. We note that all data are for the outdoors, LOS, 1.2-meter height, and 4 dBm TX power experiments. We then use this derived model to compare the real distance to the estimated distance as in Figure 11. One point to take away from this plot is the fact that distance estimation can show significant errors even under LOS conditions due to high signal strength variations. Furthermore, the errors increase as distance increases (e.g., as RSSI gets closer to the reception sensitivity). While we omit additional figures for brevity, we note that we can see similar plots even with data from a single pair of iBeacon-mobile device. Quantitatively, the errors can increase from tens of meters to even hundreds of meters. This means that when designing an iBeacon-based system, a system designer should either cope with the large distance estimation errors (and hence positioning errors) or densely deploy a large number of iBeacons to reduce the errors, which can threat the “low-cost” argument in iBeacon systems. Unfortunately, as per our experimental results, neither is satisfactory.Figure 11
Real distance versus estimated distance plot where the previously collected RSSI data was used to curve fit the model in (1) and empirically determine the model parameter.


## 5. Application Case Study: Automatic Attendance Checker System

As our experimental results show, the main challenge in using iBeacon signals for accurate indoor positioning is the variability of RSSI readings and its sensitivity to environment changes which result in drastic changes in signal propagation. Our findings in Section4 show that the RSSI value (and the corresponding signal propagation model for estimating distances) varies significantly among iBeacons from different vendors (e.g., Estimote versus Wizturn Pebble versus GELO), mobile device types (iOS versus Android), height of the device installation from the ground, indoor or outdoor environmental factors, and physical obstacle types. Overall, these experiences suggest that, with such iBeacon devices, we should take these limitations and performance characteristics into consideration when designing applications and apply improvement schemes with respect to the intuitions collected from such real-world pilot deployment experiences.In this case study, we extend the line of possible iBeacon applications by proposing an automatic attendance checker system that automatically checks the attendance of a college student to her classes in a university. However, simple proximity is not enough to accurately determine whether a student is inside the classroom or not since the beacon signal can be received behind the walls of the classrooms as well. Thus, we use the trilateration-based position estimation to make a decision on whether the student is attending the class in the room or not. To compensate for RSSI reading errors due to unexpected obstacles (e.g., users holding their mobile phone tightly, or their phones being in a bag), we make simple yet novel geometric adjustments in trilateration calculation to improve the detection accuracy. On a system-level perspective, our system is composed of not only iBeacons and mobile devices, but also a database server which maintains and handles information about students, classes, classrooms, time-table, and attendance information. As we later show, the complete system allows for a fully automated attendance checking mechanism to take place with 100% accuracy under the circumstance that the students have enabled our application on their smartphones. Our system not only saves time wasted for manual attendance checking during classes, but also prevents attendance cheatings since it is very unlikely that a student will give his/her smartphone to a friend just for attendance checking.


### 5.1. System Architecture

Figure12 shows the overview of our system architecture. Three iBeacons are deployed in each classroom with unique identification numbers (major-minor pair) for each iBeacon, and the relativex-y coordinate of each classroom is preconfigured. We developed an Android application for our system, which receives beacon signals in the background and communicates with the web/DB server over the Internet for attendance checking without user intervention. The server maintains all the necessary information to compute and confirm attendance in the database. The recorded attendance data can be viewed on our system’s website by the faculty and staff members as well as on the students’ mobile devices.Figure 12
Overall system architecture of our iBeacon-based automatic attendance checker system.Specifically, we used an Oracle DB to maintain information regarding students, professors, classes, time tables, and, most importantly, deployed iBeacons including theirx-y coordinates (relative, within each classroom) and identification numbers. This information is relatively static in the sense that student information changes only when they join and login for the first time, and class/time-table information changes only at the beginning of each semester for which we use web-crawling to automatically populate from the university website. To store the actual attendance information (the class, date, time, andx-y coordinate within classroom) for each student, we used the MongoDB to handle the frequently updated data. Figure 13 shows our database structure.Figure 13
Databased structure in our iBeacon-based automatic attendance checker system server.Using the aforementioned system, the automatic attendance check process operates as follows. When a student enters a classroom, the smartphone application will receive beacon advertisements from three or more iBeacons (there may be signals from nearby classrooms). At this point, the application sends the list of identification numbers (UUID, major/minor values [3]) and RSSI readings from the iBeacons to the server and queries the server for verification of attendance. Given this information, the server will first check the classroom information of each iBeacon and validates it against the classroom at which the student should be attending at the given time instance. If the classroom information indicates that the student is in a wrong classroom or if there are only two or less number of beacons detected from the target classroom, then the server returns FALSE for attendance. If no beacon is detected, attendance is FALSE by default. For all other cases, the server uses the relativex-y coordinates (within the target classroom) of the iBeacons to estimate a position of the mobile device and checks whether the device is within the boundaries of the classroom. If so, the server returns TRUE for attendance and records it in the database. This process is repeated periodically so that attendance can be checked during the class as well. This is to account for students who are a few minutes late, as well as those students who leave early during class. However, to reduce the unnecessary power consumption from the use of BLE for the duration when a student does not have a class to attend, her time-table can be locally cached on the mobile device to enable attendance checking only when needed.Note that thex-y coordinates stored in the database are only relative andlocal to the target classroom. This is in contrast to other indoor positioning systems where globalx-y coordinate within the entire target area (e.g., whole floor of the building to map) is required and is made possible given that we maintain preknowledge on which classroom a student should be at a given time. This greatly simplifies the system architecture not only in terms of estimating the position of the mobile device, but also in terms of iBeacon deployment, replacement, and reconfiguration. In other words, if systems are mostly concerned for a small geographical region, iBeacon placements can be independently (and better) customized and optimized. We provide detailed descriptions on such calibration procedures in the following section.


### 5.2. Geometric Adjustment for Improved Accuracy

The main challenge in using iBeacon signals for accurate indoor positioning is the variability of RSSI readings and their sensitivity to environment changes such as obstacles or user handling of the mobile device. Our findings earlier show that RSSI values can drop significantly when a beacon signal is received behind an obstacle, and the amount of signal attenuation varies depending on the obstacle types (e.g., window, wooden/metal door, walls, etc.). Furthermore, the height of the mobile device from the ground also affects the RSSI (height of the iBeacon also introduces a high impact, but iBeacons are usually wall-mounted and its height is fixed in typical scenarios). More significantly, the signal attenuation due to holding the mobile device tightly in users’ hands (which happens often) can be as much as 30 dBm. Such a high variation is a significant challenge when using trilateration for position estimation. However, we see one commonality from the aforementioned cases; the signal attenuates (RSSI is lower than the model for a given distance), and it is extremely rare to see higher RSSI than the (best-case) line-of-sight environment. Using this intuition, we use a simple yet novel geometric adjustment scheme to improve accuracy rather than trying to calibrate the model based on highly varying RSSI values.For example, Figure14 shows one example of an exception case where the distance estimation from three iBeacons results in three RSSI-coverage distance circles (circles drawn by the estimated distance as radii for trilateration) without any intersection; one circle is completely enclosed by the biggest circle, and a third circle is completely outside of the biggest one. In this case, standard trilateration calculation is not possible. However, our intuition is that the distance of the larger circle (larger distance from higher RSSI value) is closer to the estimation model, and the signals of the two smaller circles have been attenuated due to some reason such as obstacles. Based on this intuition, our approach is as follows. For each pair of circles (out of three pairs from three iBeacons), we first check whether [Case  1] two circles have no intersection points (upper figure of Figure 15) or whether [Case  2] one circle is completely enclosed by another circle (left figure of Figure 16). If neither is true, then there is nothing else to consider for that specific pair of RSSI-coverage distance circles.Figure 14
An example of possible exception scenario where trilateration calculation will fail due to high variation in RSSI reading, thus causing error.Figure 15
[Case  1] where two distance circles (circles representing the estimated distance using RSSI) from two iBeacons are nonintersecting because the sum of two distance estimations are smaller than the distance between the two iBeacons. This results in no intersection point for trilateration calculation. Thus, we gradually increase the sizes of the circles until they intersect.Figure 16
[Case  2] where a distance circle (a circle representing the estimated distance using RSSI) from one iBeacon is completely enclosed by another distance circle (from another iBeacon), resulting in no intersection point for trilateration calculation. In this case, we gradually increase the size of the inner circle until the two circles intersect.If a pair of circles have no intersection points (i.e., [Case  1]), we first increase the size of the smaller circle with an increment of 1 meter until there are two intersection points or up to the point where the two circles become the same sizes. If no intersection points are created even after two circles are of the same sizes, then we increase the size ofboth circles with an increment of 1 meter until there are two intersection points (c.f. Figure 15). Again, this adjustment comes from the assumption that the indoor RSSI levels are disrupted by obstacles, which make the RSSI levels degrade more rapidly.In the second case where, for a pair of circles, one circle is completely enclosed by another circle (i.e., [Case  2]), we increase the size of the smaller circle with an increment of 1 meter until there are two intersection points (c.f. Figure16). The resulting circles after the adjustments represent the“adjusted distances” from each iBeacon. Now, since all pairs of“adjusted circles” each have two intersection points, we can use these six intersection points to apply the trilateration and estimate the approximate position of the mobile device.Figures17 and 18 show the position estimation results from the two exception cases where the estimated distances from three iBeacons did not provide sufficient coverage for trilateration. After the geometric adjustment based on our prior observations, the resulting estimations were detected to be very close to the actual positions. As a final note, the entire position estimation process, including the geometric adjustment and trilateration, takes place at the server. The mobile device simply detects iBeacon signals during the period of classes for the student, sends the list of iBeacon advertisement data to the server, and queries for attendance check. Thus, there is practically no computation burden on the mobile device, and this leads to minimizing the energy usage as well.Figure 17
An example of position estimation from an exception case where the original distance circles (from distances estimated by RSSI) had two circles completely enclosed in a third circle.Figure 18
An example of position estimation from the exception case in Figure14 where the original distance circles (from distances estimated by RSSI) had one circle enclosed in another and a third circle is nonintersecting with the other two circles.


### 5.3. Evaluation

We have evaluated our automatic attendance checker system with the help of four undergraduate students attending classes in three classrooms. While this case study was done in a limited scale due to challenges in getting individual consent for accessing students personal information, the system reported no false reports (neither false positive nor false negatives for attendance) for our student volunteers during the course of 1 month. We plan to scale the experiment to a larger number of students and classes in the future.


## 5.1. System Architecture

Figure12 shows the overview of our system architecture. Three iBeacons are deployed in each classroom with unique identification numbers (major-minor pair) for each iBeacon, and the relativex-y coordinate of each classroom is preconfigured. We developed an Android application for our system, which receives beacon signals in the background and communicates with the web/DB server over the Internet for attendance checking without user intervention. The server maintains all the necessary information to compute and confirm attendance in the database. The recorded attendance data can be viewed on our system’s website by the faculty and staff members as well as on the students’ mobile devices.Figure 12
Overall system architecture of our iBeacon-based automatic attendance checker system.Specifically, we used an Oracle DB to maintain information regarding students, professors, classes, time tables, and, most importantly, deployed iBeacons including theirx-y coordinates (relative, within each classroom) and identification numbers. This information is relatively static in the sense that student information changes only when they join and login for the first time, and class/time-table information changes only at the beginning of each semester for which we use web-crawling to automatically populate from the university website. To store the actual attendance information (the class, date, time, andx-y coordinate within classroom) for each student, we used the MongoDB to handle the frequently updated data. Figure 13 shows our database structure.Figure 13
Databased structure in our iBeacon-based automatic attendance checker system server.Using the aforementioned system, the automatic attendance check process operates as follows. When a student enters a classroom, the smartphone application will receive beacon advertisements from three or more iBeacons (there may be signals from nearby classrooms). At this point, the application sends the list of identification numbers (UUID, major/minor values [3]) and RSSI readings from the iBeacons to the server and queries the server for verification of attendance. Given this information, the server will first check the classroom information of each iBeacon and validates it against the classroom at which the student should be attending at the given time instance. If the classroom information indicates that the student is in a wrong classroom or if there are only two or less number of beacons detected from the target classroom, then the server returns FALSE for attendance. If no beacon is detected, attendance is FALSE by default. For all other cases, the server uses the relativex-y coordinates (within the target classroom) of the iBeacons to estimate a position of the mobile device and checks whether the device is within the boundaries of the classroom. If so, the server returns TRUE for attendance and records it in the database. This process is repeated periodically so that attendance can be checked during the class as well. This is to account for students who are a few minutes late, as well as those students who leave early during class. However, to reduce the unnecessary power consumption from the use of BLE for the duration when a student does not have a class to attend, her time-table can be locally cached on the mobile device to enable attendance checking only when needed.Note that thex-y coordinates stored in the database are only relative andlocal to the target classroom. This is in contrast to other indoor positioning systems where globalx-y coordinate within the entire target area (e.g., whole floor of the building to map) is required and is made possible given that we maintain preknowledge on which classroom a student should be at a given time. This greatly simplifies the system architecture not only in terms of estimating the position of the mobile device, but also in terms of iBeacon deployment, replacement, and reconfiguration. In other words, if systems are mostly concerned for a small geographical region, iBeacon placements can be independently (and better) customized and optimized. We provide detailed descriptions on such calibration procedures in the following section.


## 5.2. Geometric Adjustment for Improved Accuracy

The main challenge in using iBeacon signals for accurate indoor positioning is the variability of RSSI readings and their sensitivity to environment changes such as obstacles or user handling of the mobile device. Our findings earlier show that RSSI values can drop significantly when a beacon signal is received behind an obstacle, and the amount of signal attenuation varies depending on the obstacle types (e.g., window, wooden/metal door, walls, etc.). Furthermore, the height of the mobile device from the ground also affects the RSSI (height of the iBeacon also introduces a high impact, but iBeacons are usually wall-mounted and its height is fixed in typical scenarios). More significantly, the signal attenuation due to holding the mobile device tightly in users’ hands (which happens often) can be as much as 30 dBm. Such a high variation is a significant challenge when using trilateration for position estimation. However, we see one commonality from the aforementioned cases; the signal attenuates (RSSI is lower than the model for a given distance), and it is extremely rare to see higher RSSI than the (best-case) line-of-sight environment. Using this intuition, we use a simple yet novel geometric adjustment scheme to improve accuracy rather than trying to calibrate the model based on highly varying RSSI values.For example, Figure14 shows one example of an exception case where the distance estimation from three iBeacons results in three RSSI-coverage distance circles (circles drawn by the estimated distance as radii for trilateration) without any intersection; one circle is completely enclosed by the biggest circle, and a third circle is completely outside of the biggest one. In this case, standard trilateration calculation is not possible. However, our intuition is that the distance of the larger circle (larger distance from higher RSSI value) is closer to the estimation model, and the signals of the two smaller circles have been attenuated due to some reason such as obstacles. Based on this intuition, our approach is as follows. For each pair of circles (out of three pairs from three iBeacons), we first check whether [Case  1] two circles have no intersection points (upper figure of Figure 15) or whether [Case  2] one circle is completely enclosed by another circle (left figure of Figure 16). If neither is true, then there is nothing else to consider for that specific pair of RSSI-coverage distance circles.Figure 14
An example of possible exception scenario where trilateration calculation will fail due to high variation in RSSI reading, thus causing error.Figure 15
[Case  1] where two distance circles (circles representing the estimated distance using RSSI) from two iBeacons are nonintersecting because the sum of two distance estimations are smaller than the distance between the two iBeacons. This results in no intersection point for trilateration calculation. Thus, we gradually increase the sizes of the circles until they intersect.Figure 16
[Case  2] where a distance circle (a circle representing the estimated distance using RSSI) from one iBeacon is completely enclosed by another distance circle (from another iBeacon), resulting in no intersection point for trilateration calculation. In this case, we gradually increase the size of the inner circle until the two circles intersect.If a pair of circles have no intersection points (i.e., [Case  1]), we first increase the size of the smaller circle with an increment of 1 meter until there are two intersection points or up to the point where the two circles become the same sizes. If no intersection points are created even after two circles are of the same sizes, then we increase the size ofboth circles with an increment of 1 meter until there are two intersection points (c.f. Figure 15). Again, this adjustment comes from the assumption that the indoor RSSI levels are disrupted by obstacles, which make the RSSI levels degrade more rapidly.In the second case where, for a pair of circles, one circle is completely enclosed by another circle (i.e., [Case  2]), we increase the size of the smaller circle with an increment of 1 meter until there are two intersection points (c.f. Figure16). The resulting circles after the adjustments represent the“adjusted distances” from each iBeacon. Now, since all pairs of“adjusted circles” each have two intersection points, we can use these six intersection points to apply the trilateration and estimate the approximate position of the mobile device.Figures17 and 18 show the position estimation results from the two exception cases where the estimated distances from three iBeacons did not provide sufficient coverage for trilateration. After the geometric adjustment based on our prior observations, the resulting estimations were detected to be very close to the actual positions. As a final note, the entire position estimation process, including the geometric adjustment and trilateration, takes place at the server. The mobile device simply detects iBeacon signals during the period of classes for the student, sends the list of iBeacon advertisement data to the server, and queries for attendance check. Thus, there is practically no computation burden on the mobile device, and this leads to minimizing the energy usage as well.Figure 17
An example of position estimation from an exception case where the original distance circles (from distances estimated by RSSI) had two circles completely enclosed in a third circle.Figure 18
An example of position estimation from the exception case in Figure14 where the original distance circles (from distances estimated by RSSI) had one circle enclosed in another and a third circle is nonintersecting with the other two circles.


## 5.3. Evaluation

We have evaluated our automatic attendance checker system with the help of four undergraduate students attending classes in three classrooms. While this case study was done in a limited scale due to challenges in getting individual consent for accessing students personal information, the system reported no false reports (neither false positive nor false negatives for attendance) for our student volunteers during the course of 1 month. We plan to scale the experiment to a larger number of students and classes in the future.


## 6. Related Work

There are several pieces of prior work that proposes applications and services using iBeacon devices. The work in [9] uses iBeacons for tracking luggage at the airport, and the work in [10] provides interactive experience to visitors in museums. iBeacon has been used for path planning in emergency guiding system[11] and also for tracking patients in emergency rooms [12]. Furthermore, the work in [13] proposes an indoor route guidance system, and the work in [15, 16] uses iBeacons for occupancy detection within buildings. These applications all use proximity-based on RSSI as the source of information rather than trying to pinpoint the exact and absolute location of the mobile device. There are also a number of prior works that focus on using iBeacon devices for precise indoor positioning [6, 7, 12, 23, 24]. However, none of these efforts provide an in-depth and extensive measurement study of iBeacon RSSI measurements and its variability with different environmental factors.The work in [30] implements an Android application that collects statistics of RSSI values from nearby iBeacons and provides some measurement results but only at a fixed distance. The work in [5] provides some measurement data regarding the transmission power and reception ratio along with the estimated distance, and the work in [31] attempts to calibrate the distance estimation model using measurement data and perform error analysis. However, none of these works provide extensive and comprehensive measurement data in the dimensions of several different types of iBeacons, mobile devices software platforms, transmission power configurations, indoor/outdoor comparisons, and WiFi interference impacts and with several different types of controlled yet practical obstacles. Furthermore, we combine the experiences from the RSSI measurements to design a well-suited and practically applicable system and propose a case study application for automatic attendance checking, which uses localized trilateration techniques along with geometric adjustments to limit the scope of error due to RSSI variability and meet the target accuracy.


## 7. Conclusion

The original goal of this research was to develop an improved indoor positioning system using iBeacon technologies. However, after numerous and extensive experiments, we realized that the signal variation was too high to retrieve accurate distance estimation for designing a reliable and robust localization system. Instead we decided to report on this variation and inaccuracy to clarify the misunderstanding caused by numerous sugar-coated news articles on how accurate iBeacon technology can be. Our finding shows that iBeacon RSSI values (and the corresponding signal propagation model to estimate the distance) vary significantly across iBeacon vendors, mobile device platforms, deployment height of the device, indoor/outdoor environmental factors, and obstacles. It is obvious that the accuracy and efficiency of location estimation depend heavily on the accuracy of the measured RSSI measurements and the model used to estimate the distance, not to mention the surrounding environmental factors. We believe that our work provides evidence on the challenges for designing an indoor localization system using commercial-off-the-shelf (COTS) iBeacons devices and dismantles the misunderstanding of its overestimated accuracy. Furthermore, based on the observations made in this work, our future work is to find a way to approach these errors differently and develop an iBeacon-based system that is resilient and robust to such RSSI dynamics.



---

*Source: 8367638-2016-10-24.xml*