Part 1 of our Quick Beacon Deployment Guide
This is the first of a series of articles about what factors you’ll want to take into account when planning your Beacon deployment.
In this “How To” series you will learn:
In this first part, we’ll discuss your Beacon ID strategy. Where you will learn about what IDs and regions are, and how you need to take these into account when planning your Beacon deployment.
We’ll also run through the options available for configuring your Beacon IDs.
The proximity UUID (Universally Unique IDentifier, UUID for short), Major, and Minor parameters – together make up your iBeacon’s unique identifier, and are the key components of all advertising packets continually transmitted by your iBeacons.
Deciding how to configure these parameters is a key consideration when thinking about your beacon deployment. They’ll affect your beacons’ range and lifespan and help you organize your deployment.
The purpose of the proximity UUID is to distinguish beacons in your network from all other beacons in networks outside your control. When you receive your beacons, they will all have a common proximity UUID set, which will look something like:
It is the UUID that all of Kontakt.io’s iBeacons sell come with. Since you want to distinguish you beacon fleet from other Kontakt.io’s customers, it’s recommended to change it to a custom string.
Major and Minor are unsigned integer values between 1 and 65535.
Major values are intended to identify and distinguish a group—for example all beacons on a certain floor or room in your venue could be assigned a unique Major value.
Minor values are intended to identify and distinguish an individual—for example distinguishing specific beacons within a group of beacons assigned a Major value.
So an individual iBeacon identifier could look like:
Eddystone’s unique identifier is made up of Namespace and Instance.
Namespace serves a similar purpose as Proximity UUID does in iBeacon, and by default at Kontakt.io, it looks like this:
Instance is Eddystone’s counterpart of iBeacon’s Major, or both Major and Minor mixed up together. By default, it’s a randomly generated hexadecimal number, which means it contains digits (0-9) and characters (a-f).
An iOS application monitors regions, and a region can be one or more beacons. In case of iBeacons, a region may be specified using one of the following methods:
If we assign a single proximity UUID to many locations, our application can monitor all these locations simultaneously. This can have a big impact in reducing the complexity of your application.
When it comes to Eddystone, there are no regions in this format’s anatomy but you can artificially create ones using our iOS SDK. You can filter your Eddystones based on their Namespace, Instance, or a specific URL. By the way, the SDK will also help your app “understand” that a certain Eddystone is actually a beacon (normally, iOS treats Eddystone as any other Bluetooth device. In order to act properly, it needs a “translator”, and our SDK does that for you).
Android treats iBeacons and Eddystones the same, and it doesn’t have a built-in region functionality. If you need a kind of regions, you can filter your beacons using our Android SDK.
Ok, so we covered the basics. How might that affect our beacon deployment strategy?
Let’s look at a museum group as an example, which has a network of four Museums in distinct physical locations.
Beacons are deployed to give visitors a rich interactive experience when they enter any of our Museums, and they provide users with information about individual collections as they approach each exhibit.
In our Museum Group example, we have assigned a single UUID to the group. A user’s device can monitor our four physical locations using this single UUID. Our application ‘knows’ when the user has entered (or left) any of the museums in the group and notify the user appropriately just by referencing the UUID.
The Major field, tells us which Museum the user is currently in so your application can act accordingly – for example by offering event suggestions, maps, audio guides, or other content.
The Minor field can be used to identify entire collections within the Museum, or the individual exhibits within the collection. Your application can use this level of granularity to provide tailored information for the exhibit, a more detailed gallery map, or perhaps an audio guide through the entire exhibit.
For a deployment of Eddystone beacons, our network would look like this:
In this case, all beacons in our Museum Group have one Namespace. Since there’s no Minor field, we use Instance to distinguish specific beacons at specific museums.