Follow

Using Multiple In-Store Beacons

Introduction

Successfully using multiple beacons in store relies on satisfying some unique technical constraints in mobile platforms. This document provides a summary of the Plexure recommended approach. It is mainly targeted at iOS constraints, however the approach relies on a specific method of naming beacons, so ultimately has an impact on how Android apps manage beacons too.

The Challenge

The most effective way of notifying an app that it’s in range of a beacon is to register its beacon identifier with the device operating system, which then provides a callback when the device enters or exits the beacon range. This is an effective solution as the OS is optimised to use low amounts of power to detect beacons.

The challenge for iOS is there are only 20 slots available per app for registering locations, whether they be beacons or geofences.

In a large store implementation, it is possible to require more than 20 slots to register all in-store beacons. Not only this, but by doing so there are no slots left for registering geofences, which will compromise any geofence based features of the app.

In order to work within this constraint, a solution is required which allows the app to detect and act upon more than 20 beacons without needing to register all 20 beacons with the operating system.

The Solution

It is possible to register partial or ‘wildcard’ beacon identifiers with the OS such that the app is notified when any part of the identifier is detected.

For example, if the identifier of a beacon is

{“a6334534-4414-4b1a-8b21-f7822db09d41”, 23, 1}  

Then in order to be notified when the device is within range of any beacon with the UUID “a6334534-4414-4b1a-8b21-f7822db09d41” it can be registered with the OS thus:

{“a6334534-4414-4b1a-8b21-f7822db09d41”, *, *}  

This has the advantage of being able to install a large number beacons all sharing the same UUID and be notified as soon as the device is within range of any of them.

The disadvantage is that no other information apart from the UUID is provided in the callback triggered by the OS. This effectively means the app can be notified when in range of any beacon with a specific UUID, but the app will not be able to tell which specific beacon it is close to. This constraint means there is no way for the app to know which specific beacon it is close to, and therefore can’t undertake any beacon specific action such as displaying a message to the consumer.

Ranging for Beacons

To solve the issue with discovering the exact identity of the beacon the device is near to, the Plexure SDK uses ranging. This is a short duration operation where the OS is queried for all beacons nearby. This returns the full identifier of the beacon so that the app can take some action, and the Plexure platform can track beacon proximity, send push messages and so forth.

This means the flow for beacon detection is as such:

  1. Beacon UUID is registered in the OS using wildcards for major and minor.
  2. When the device is within any range of a beacon with the registered UUID, the app is notified
  3. The device then ranges briefly to read the full beacon address, including major and minor.
  4. Any beacon specific actions are taken (send information to Plexure platform to initiate a push message, collect location data and so forth)

However, this solution still has one major issue – if all the beacons have the same UUID, and their radio fields overlap each other, the OS will never fire a new beacon entry callback as the device moves between beacons, as to the OS, it is never leaving the registered region. This means only the first beacon entry will be detected and acted upon – any other beacon entries, if they’re too close, will not be detected.

If there are only a few beacons in store this is fine – each one can be registered in the OS with a different UUID.

However, for implementations with a large number of beacons – over 10 or even over 20 – a different approach is required, as using a different UUID per beacon will fill up all OS slots.

Introducing Colours

Considering the main issue detailed above is that beacons sharing the same UUID can’t overlap, the problem becomes one of beacon placement. Given the likely physical constraints with where beacons can be placed in store (e.g. close to power, or safe from theft or vandalism), and a relatively high amount of variation in beacon range due to environmental factors, an approach to arranging beacons must be used so that beacons sharing the same UUID do not have overlapping radio fields.

In order to make this easer to conceptualise, the Plexure approach is to group beacons sharing the same UUID into colours. For example:

Colour

Beacon Identifiers

Red

3dbf82f8-f551-40db-958d-5a0783c8351a, 193, 1

3dbf82f8-f551-40db-958d-5a0783c8351a, 193, 4

3dbf82f8-f551-40db-958d-5a0783c8351a, 193, 8

Green

6d917525-6b78-4305-a887-c92edd1a44e0, 193, 2

6d917525-6b78-4305-a887-c92edd1a44e0, 193, 5

6d917525-6b78-4305-a887-c92edd1a44e0, 193, 9

Blue

1b05f2e0-9c3b-4590-b069-f4827fd28308, 193, 3

1b05f2e0-9c3b-4590-b069-f4827fd28308, 193, 6

1b05f2e0-9c3b-4590-b069-f4827fd28308, 193, 10

 

Where the major number is a store identifier, and the minor number is a specific location within the store.

In order to arrange the beacons within the store in such a way that they are unlikely to overlap, the rule is to only place beacons of different colours close to each other.

For example:

With each beacon belonging to a different ‘colour’ overlapping beacon ranges are fine as the OS will send entry and exit notifications for all beacons.

For larger implementations this approach really comes into its own:

In this diagram we see the placement of 26 uniquely identifiable beacons while only using 3 slots in the OS location register.

Conclusion

Despite the 20 beacon and geofence slots limitation of the OS, it is possible to track large numbers of uniquely identifiable beacons using a combination of region monitoring and ranging. Using the concept of colours helps to simplify the underlying UUIDs allocated and reduces the chances of in-store implementations accidentally creating overlapping fields of beacons sharing the same UUID, thereby increasing the accuracy of tracking data and app notifications.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.