Context is king: Using indoor-location technology for new visitor experiences

Kyle Jaebker, Indianapolis Museum of Art, USA, Gray Bowman, Indianapolis Museum of Art, USA

Abstract

Keywords: mobile, indoor location, context, analytics

1. Introduction

As smartphones have become more advanced and more prevalent in our society, the possible applications for these devices have increased exponentially. These new applications are often all about context and providing that to the user. The Global Positioning System (GPS) has allowed location context to be established when a user has access to the sky. While this method of gathering location information is suitable for outdoor environments, indoor-location awareness has taken a longer road to maturation. From Wi-Fi implementations to Visible Light Communications (VLC) to Bluetooth Low Energy (BLE), technology is starting to become cost-effective and robust enough to handle indoor-location applications.

The Indianapolis Museum of Art (IMA), with support from the Institute of Museums and Library Services (IMLS), is undertaking a research project to evaluate the capabilities of BLE for providing location context indoors. The IMA is investigating the feasibility of two applications for indoor-location awareness, providing the user with contextually aware data and providing the museum with analytics about the user.

Part one of the grant has utilized the TAP mobile platform (http://tapintomuseums.org). Using this tour platform, the IMA has started work with beacons to provide indoor-location context for app users. This technology allows the app to determine, at a minimum, the room a user is currently in, giving the app the ability to provide information relevant to the user’s location. Small devices called beacons can transmit a low-power Bluetooth signal that can be picked up by smartphones. Potential applications include gallery tours, additional collection-based information, and games.

Part two of the grant is focused on collecting analytic data about our visitors and users. This practice has been widely accepted for use on websites, at retail transactions, and at resorts like Disney World. This data helps institutions plan for traffic flow and to better serve their visitors. Using the same BLE technology, the IMA is investigating the collection of data as users move from one gallery to the next. Using an opt-in approach, our users will have the ability to decline this analytics collection.

2. A little background on Bluetooth

Ericsson invented Bluetooth in 1994. Utilizing the same radio frequency band (2.4GHz) as many communication technologies, this wireless technology was conceived to enable the transfer of data over a short distance, while consuming low amounts of power. Today the Bluetooth specification is managed by the Bluetooth Special Interest Group (SIG) with more than 25,000 member companies (Bluetooth, 2015a). This group publishes the standard and guides the future for Bluetooth technology.

With the advent of mobile phones, use of Bluetooth has increased rapidly. With applications ranging from wireless audio playback to wireless headset connections for hands-free calling, portable device manufacturers have embraced the Bluetooth standard. Today you can find Bluetooth technology in almost every mobile phone and computer sold.

Bluetooth devices can communicate with one another after being “paired.” For example, a Bluetooth headset can pair with a smartphone. When a device is set to be “Discoverable,” it will transmit the name of the device along with information about the type of services the Bluetooth connection will allow. Once the pairing has occurred, the devices can reestablish the connection when they are near each other. The specified minimum range for Bluetooth is 10 meters, but this can vary widely based on the chipsets and power of the devices used (Bluetooth, 2015b).

In 2010 the Bluetooth SIG introduced Bluetooth v4.0. This release brought with it the new protocol termed Bluetooth Low Energy (BLE), also known as Bluetooth Smart. This protocol offered Bluetooth capability while using very little energy, allowing for smaller devices and the ability to operate on a coin-cell battery (i.e., watch batteries). This protocol led directly to the advent of the Bluetooth Beacon that is making indoor-location-aware projects possible.

Beacons and iBeacon

Soon after the BLE standard was adopted, Bluetooth beacons leaped onto the scene. These devices, popularized by Apple with the marketing name iBeacon, are small devices that consume little power and transmit a Bluetooth signal. The signal transmitted by these devices can be detected by smartphones and utilized to trigger actions within apps.

Each beacon transmits three pieces of identifiable information: a universally unique identifier (UUID) and major and minor values. When setting up beacons, it is important to think about how you will utilize these identifiers. The standard way to think about beacon identifiers is like a set of concentric circles where the outermost ring is the UUID (figure 1), the middle ring is the major, and the inner-most ring is the minor. For example, in a deployment of beacons in a museum with one building and one beacon per room, the following convention would make sense:

Figure 1: beacon identifier structure

•  All beacons have the same UUID (i.e., 14b108cd-d3fb-4145-8723-334a76cc19e2)
• The beacons on each floor would use the same major number (i.e., Floor 1: 100, Floor 2: 200)
• Each beacon would have a distinct minor number (i.e., 1, 2, 3, 4, etc.)

Depending on the manufacturer, some beacon identifiers are customizable, while others are randomized and tied to cloud services for security. Due to the open nature of the signal broadcasting from a beacon, spoofing or cloning beacon identifiers is fairly easy (Young, 2014). Depending on the application and its use of beacons, the added security of cloud-based beacon identifiers is a necessary feature. For the purposes of this paper, standard beacon identifiers will be used to avoid the necessity of implementing the required software development kits (SDK) for each manufacturer’s beacons.

3. Choosing a beacon

Due to the low cost of producing beacons, there are many manufacturers to choose from. This allows for flexibility when determining what will work best for any given deployment, but also makes it difficult to know which will work best. When determining which beacons to use, the following areas are worth considering:

1. Battery Life: how long will they last on the installed batteries? If the beacon installation is on the ceiling or other hard-to-reach areas, having to change the batteries often provides difficult.
2. Size and appearance: many beacons are quite small; some are larger to accommodate larger batteries. Some beacons have bright colors; others are white. Depending on beacon placement, this can be important for giving the installation a clean appearance hidden from users.
3. Security: do the beacons require a specific SDK to utilize them? Having beacons that utilize cloud-based solutions for rotating the identifiers is an added security layer that requires the use of the beacon manufacturer SDK. This can make it difficult to add beacons from multiple manufacturers to an existing deployment/app.
4. Build quality: From building custom beacons to buying polished products, the build quality varies widely. Ensuring a product is well made can lead to better results for users.
5. Software support: To configure and deploy beacons, vendor software is a requirement. Having a robust management platform can ease deployments and assist in long-term management of the beacon installation.

To find a suitable beacon for use inside the IMA, three different types were purchased: from Estimote, Roximity, and Gimbal.

Estimote beacons

The Estimote beacons are probably the most widely used beacons. These beacons run on a cell battery and are shaped like small rocks with bright colors. The beacons offer a great deal of customization, with configurable UUID and major and minor values. There is also the ability to adjust the broadcasting power and advertising interval, which can help save battery life (or hurt it). All of the customization can be done from the Estimote iOS/Android app. These beacons also contain a temperature sensor and accelerometer, but you will have to use the Estimote SDK to access that data.

Overall, the build quality and configurability of Estimote beacons is very high. Estimote is actively adding new features to its software/hardware, which is a good sign for longevity of the company. For many use-cases, these beacons are a great fit; the only concerning factor is battery life. Without changing any of the default configurations, the three Estimote beacons tested lasted about six months before needing new batteries.

Roximity beacons

The Roximity Model X is a larger beacon that promises up to five years of battery life. These beacons are about the size of four AA batteries (they contain three) and are enclosed in a white case. The casing is designed to work indoors or outdoors, which is a nice feature; the one caveat is that there is no way to open it for replacing batteries without cutting/prying the plastic apart. When it comes to beacon configuration, the Roximity beacons are as locked down as possible. For security, the Roximity beacons utilize cloud management to prevent cloning, spoofing, and hacking. This security level requires Roximity SDK to use the beacons.

The two dominant features of the Roximity platform are battery life and security. Overall, the build quality is not on par with the other beacons tested; the seal around the base of each beacon has visible signs of glue and gaps that could potentially let in moisture. Due to the requirement of using the SDK, outside of the Roximity testing app, we did not utilize these beacons in the software developed.

Gimbal beacons

The Gimbal Proximity Beacon 21 is a larger beacon that operates off of four AA batteries. Each beacon can be configured through a combination of the online management interface and the Gimbal app. This allows for setting the UUID and major and minor values, as well as the broadcasting power and the antenna type (directional or omnidirectional). In addition to the standard beacon features, features include a temperature sensor (requires SDK for use), an on/off switch, an LED indicator for battery and configuration feedback, and the ability to have a directional antenna. The expected battery life is eighteen months, and the batteries can be easily replaced.

The build quality of the Gimbal beacons is superb, with the clamshell enclosure easily opening for battery replacement and powering the beacon on/off. The beacons are rated for indoor and outdoor use. Overall, these beacons are well built and offer a breadth of customization and management features.

Testing beacons

Figure 2: testing beacons

To help determine which beacons to purchase at the IMA, a number of tests were run on the Estimote and Gimbal beacons. The tests utilized the TAP iOS application and the TAP content management system (CMS) reporting capabilities. All beacons were tested using the default settings provided by the manufacturer. The only configuration that was changed prior to the testing was the UUID and major and minor values. The first test placed one beacon from each manufacturer at different distances to gather signal strength, proximity, and accuracy (figure 2). An iPhone 6+ was used to run the TAP app and was set on the table as well. Data was collected for two minutes at distances of 3.66 meters, 3 meters, 2 meters, 1 meter, 0.5 meters, and 0 meters. The second test repeated the same procedure as above, except the iPhone was held in hand instead of being placed on the table, simulating a more real-world use-case.

Figure 3: beacon Test 1 accuracy

Figure 4: beacon Test 2 accuracy

To note, the accuracy is shown in meters. Apple states that the accuracy reading should not be used to determine distance. These charts (figures 3 and 4) are best suited to look at variances and not exact measures. Also, Estimote beacons actually failed to report any data on a number of occasions, while the Gimbal beacons produced data throughout the tests. In addition to this, the variance of the readings for the Gimbal beacons in both proximity and accuracy were much smaller.

Figure 5: Test 1 data summary

Figure 6: Test 2 data summary

For both rounds of tests, the proximity readings for the Gimbal beacons were closer to expected values than the Estimote beacons. The RSSI (signal strength) readings were more consistent from the Gimbal beacons as well. Based on the findings of these tests and continued monitoring of battery life, it appears the Gimbal beacons will work well for use at the IMA.

4. Implementing beacon monitoring and ranging for iOS

There are many tutorials and articles about how to implement iBeacon functionality for iOS (e.g., King, 2014). This section will give a broad overview to provide context within this paper.

With the release of iOS 7 in 2013, Apple released a set of CoreLocation (https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CoreLocation_Framework/) APIs to provide applications with the ability to range and monitor for regions (containing beacons). A region in iOS parlance is defined by a combination of beacon UUID and major and minor values. Any combination of values can be utilized depending on the desired beacon implementation; the only required value is the UUID. One thing to consider when defining regions is that Apple only allows monitoring of twenty regions per app.

Monitoring of regions can provide an app with two main data points: entry and exit. When an app user enters or exits a region, the application gets notified and can perform an action. Based on how the application is built, these events can be triggered while the app is running or not running using background location services. When exiting a region, there is approximately a 20-second delay before being triggered. This is to ensure that a user has left the region and not quickly reentered. With region monitoring enabled in the background, it is possible to have your application icon show on the lock screen when a user enters a region. This feature allows a user to go straight into the app instead of having to find the app and launch it.

Ranging of regions is the second way to utilize beacons within an iOS app. When an app starts ranging for a region, it will get notified every second if it has encountered any beacons within the specified regions. Each beacon that it has observed contains the identifying information (UUID, major, minor) along with proximity, accuracy, and an RSSI. The RSSI is signal strength (in decibels) received from the beacon. Proximity provides a relative distance from the device to the beacon. The three possible proximities are immediate, near, and far. If two beacons are reporting the same proximity, the accuracy can be used to determine which is closer. The accuracy is measured in meters from the beacon, but is not supposed to be used as an exact measurement due to possible fluctuations in the RF signal.

All location-based services require permission from the user to be enabled. iOS provides two different levels of permission: while app is in use and always. Each app can provide a message to be displayed to the user explaining why location will be used. It is important to make this very clear up front, because once a user has disabled location services, it will be difficult to get them to change that setting. Pre-prompting, explanation dialogs, and other means can help to encourage users to tap yes (Mulligan, 2014). When determining what level of permission is required, ensure that an app really needs access to location all of the time before going with that level of access. Ensure there is enough value add for the increased access and that your user will understand the need for that access.

Utilizing both region monitoring and ranging gives iOS applications a lot of power in utilizing beacons and offers many possibilities for new experiences.

Providing indoor context with beacons and TAP

To get up and running quickly and provide some added functionality to an existing platform, the IMA decided to leverage TAP (http://tapintomuseums.org). TAP is a mobile-tour platform that includes an iOS app and a web-based tour authoring system. In TAP, a tour consists of a number of stops that can contain many assets, including images, video, and audio. To integrate beacons with TAP would require changes to the tour-authoring system and the iOS app.

Beacons in TAP CMS

The TAP authoring system is built on the open-source content management system Drupal. The original TAP modules were built with extensibility in mind, so plugging in beacon support was an easy process. Each beacon needs to be registered with TAP so that it can be tied to one or many stops within a tour. A beacon configuration screen (figure 7) was developed that allows tour administrators to enter each beacon along with the required identifying information (UUID, major, minor). The beacon configuration was built to allow for any type of beacon configuration: whether an implementation has ten beacons or one hundred, the system can accommodate those needs.

Figure 7: TAP beacon configuration

Next, the ability to add a beacon (or multiple beacons) to a stop was added (figure 8). This allows a stop to have location context. For instance, if a room had one beacon in it, that beacon would be applied to all stops in that room, allowing the user to see content relating to that room or the objects in it.

Figure 8: TAP stop with beacon

TourML and beacons (the glue)

To transfer the newly configured beacon data along with all of the tour information into the TAP iOS app, TourML (http://tourml.org) is utilized. TourML is an xml schema developed for structuring content for tours. When a tour is output from the TAP CMS into TourML, all of the beacons that are being utilized in the tour are exported with all of the identifying information (figure 9).

Figure 9: TourML with beacon data

Each beacon is linked to the stops in the TourML file to allow the app to register those connections (figure 10).

Figure 10: TourML for stop with beacon data

In having the entire dataset well organized, the iOS app is now ready to create an interface for the users to use the new location context.

TAP iOS and beacons

Apple has made the utilization of beacons a rather straightforward process. Adding it to the TAP iOS app required the implementation of the CoreLocation APIs and some new views to give the user new beacon-aware capabilities. For this project, the IMA decided not to utilize beacon manufacturer-specific software development kits. Because TAP is an open-source platform, locking in with a single manufacturer is the wrong direction for the future of the software.

The traditional navigation within the TAP iOS app was based on three different access methods: a keypad, a list of stops, and a map view (utilizing GPS). The first screen added to TAP was a stop listing navigation view that sorted the stops by the proximity to the user. This was named “Near Me” in the tab bar seen below (figure 11).

Figure 11: TAP stops nearby

This view receives updated proximity data from the beacons every second. During testing, the view was updating as quickly as the data was received. Due to the inconsistencies in the data, stops would jump from near to far, which made it difficult for a user to interact with the stop listing. For this type of view, it was determined that buffering the data was required to make it a useful experience. Adding in a delay to the view so that it was only updated every five seconds slowed the jumping data and made the interaction possible. With more testing, this update delay can be fine-tuned for optimum usage.

When deploying beacons, its good to know how your application is able to see them as a user moves throughout a space. To assist with beacon placement and testing, an additional view was added to the Near Me view to see this data (figure 12).

Figure 12: TAP beacon debug

This view displays each beacon and its current proximity, accuracy, and RSSI. These values can help determine if a beacon is placed in an optimal location for your usage. The data is updated in real time as the device receives it.

During our testing of the “Near Me” view, we found that the immediate proximity was rarely triggered. The immediate proximity is triggered in the range of 0 to 20 centimeters, and for our beacon placements, this was not triggered unless we explicitly tried to make it happen.

This led to an additional interaction developed for TAP where a user would “tap” a beacon, and it would automatically navigate to the stop associated with that beacon. Deploying beacons in this scenario requires a one-to-one mapping of beacon to stop. Otherwise there is no way to determine which stop to load. The other logistical concern is beacon placement; a user must have their phone very close to the beacon. Because of this, beacons must be placed in an accessible location that does not impact the object.

These applications are just a start to the beacon possibilities within TAP, and the IMA Lab team is already thinking of new possibilities.

Figure 13: testing beacons in the gallery

5. Collecting user analytics

The second part of the IMLS grant is to determine if useful analytics could be gleaned from the beacons and the users of TAP. The TAP app already utilizes Google Analytics to collect usage data but does not contain any beacon-level reporting capabilities. To get the level of reporting capabilities desired, it was determined that adding the functionality into the TAP CMS would give the most flexibility.

Integrating beacon analytics into the TAP CMS required the development of two new API endpoints to receive analytic data. The first endpoint captures beacon events. This endpoint allows for the collection of the following data points:

• Event type: Entered Region, Exited Region, Ranged.
• Mobile-device ID: a unique device ID provided by Apple. It is unique per device and per application. No personally identifiable information is included.
• Beacons: all beacons currently seen by the device are transmitted, including the proximity, accuracy, and RSSI.
• Timestamp: generated on the device. This allows for batch sending of events while maintaining time accuracy.

This data is stored in the TAP CMS, and a reporting structure was built to help analyze the data. Along with a standard table view of the data, a number of charts are generated, along with helpful filters to dive into the data (figure 14).

Figure 14: TAP beacon reporting

The charts included are:

• Number of Devices per Event: a breakdown of how many devices have triggered each type of event
• Number of Devices per Beacon: the number of unique devices seen by each beacon
• Number of Ranges by Proximity: the number of times each range (or proximity) was detected
• Devices over Time: the number of devices seen for a given time period

Along with the default view of the charts, a user can filter the results by a specific beacon and a specific date range. These charts give a view of how the beacons are performing and how many users are interacting with them.

The second API endpoint created is used to capture content events. Like Google Analytics, this collects information about the content in the app. By collecting this data in the TAP CMS, it becomes easier to merge beacon event data with the content event data. This endpoint collects the following information:

• Event: The type of event completed by the user
• Mobile-device ID: Same as the above request, the ID provided by Apple
• Stop ID: the ID of the stop where the event occurred
• Timestamp: sent from the device to allow for batch sending of events

The reporting for this data is done through an additional screen within the TAP CMS. In addition to the overall reporting view, a new tab is added to each stop to show its analytics (figure 15).

The reporting contains a table view of the data and the following charts:

• Number of Devices per Event: the number of unique devices that have triggered an event
• Number of Devices per Stop: the number of unique devices that have triggered an event for a specific stop

Figure 15: TAP content reports

Utilizing these charts and reports is a start in determining how users are interacting with beacons and the content associated with them. Continued efforts will be made to join these two datasets to give TAP authors a better picture of how visitors are interacting with the content in the app.

6. Conclusion

Beacons hold promise for indoor proximity. Utilizing beacons in gallery, library, archive, and museum settings can provide unique features that would have cost significantly more to implement even three years ago. As technology continues to evolve, true indoor positioning may be possible, but at this time, the beacon technology is best suited for applications that require a sense of proximity and not an exact location. The IMA’s first application will utilize beacons to determine room-level accuracy, providing users with a short list of content that is near them. With the open-source project TAP utilizing beacon technology and the minimal cost of beacons, indoor proximity with mobile tours (and many other applications) is now a real possibility for all museums.

References

Apple, Inc. (2013). “Core Location Framework Reference.” iOS Developer Library. Last updated September 18, 2013. Consulted January 12, 2015. Available https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CoreLocation_Framework/

Bluetooth. (2015a). “Introduction to Membership.” Consulted January 15, 2015. Available https://www.bluetooth.org/en-us/members/introduction-to-membership

Bluetooth. (2015b). “Basics.” Consulted January 15, 2015. Available http://www.bluetooth.com/Pages/Basics.aspx

King, Nevan. (2014). “Core Location Manager Changes in iOS 8.” Consulted January 16, 2015. Available http://nevan.net/2014/09/core-location-manager-changes-in-ios-8/

Mulligan, Brenden. (2014). “The right way to ask users for iOS permissions.” TechCrunch. April 4. Consulted January 12, 2015. Available http://techcrunch.com/2014/04/04/the-right-way-to-ask-users-for-ios-permissions/

Wagner, Chris. (2014). “Developing iOS 7 Applications with iBeacons Tutorial.” Ray Wenderlich. April 22. Consulted January 16, 2015. Available http://www.raywenderlich.com/66584/ios7-ibeacons-tutorial

Young, David G. (2014). “How to prevent spoofing of iBeacons.” StackExchange. Consulted January 16, 2015. Available http://stackoverflow.com/questions/21955246/how-to-prevent-spoofing-of-ibeacons