Beacon Strategy Guide - UUID, Major, Minor

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:

1.  The best way to configure your Beacon Identifiers (UUID, Major, and Minor)
2. Optimizing Transmission Power, Interval Value, and Range
3. Physically locate, test, and calibrate your Beacons
4. Create background notifications, and use our Administrator App

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.

Table of contents:

• iBeacon identifiers – UUID, Major and Minor
• Eddystone identifiers—Namespace, Instance
• Beacon identity and regions
• Beacon identifiers in practice
• Points to consider for your beacon deployment

iBeacon identifiers – UUID, Major and Minor

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.

Proximity UUID

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:
f7826da6-4fa2-4e98-8024-bc5b71e0893e
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 values

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 identifiers—Namespace, Instance

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:
f7826da6bc5b71e0893e
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).

Beacon identity and regions

Regions on iOS

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:

• a single UUID,
• UUID and Major
• UUID, Major, and Minor

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).

Regions on Android

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.

Beacon identifiers in practice

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.

iBeacon

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.

Eddystone

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.

Points to consider for your beacon deployment

• Your Proximity UUID/Namespace ID should generally be the same for all beacons for your organisation.
• Depending on your the granularity of your needs, you could also (using our example) have each museum assigned with its own UUID/Namespace. Just remember that UUIDs are meant to identify all the beacons you own, or at least very large groups of them.
• A region can be defined by proximity UUID only, a UUID plus Major value, a UUID plus Major and Minor values. You can select the level of granularity you need, depending on how many venues, beacons, and groups of beacons within specific venues you have.
• Your app is going to be notified when a user enters or leaves a region, so ask yourself at what level you’ll need such notifications. We recommend using your Major values to define your regions.
• Remember that once you have detected that the user has entered a region, and focused their attention with a notification, your application can start ranging all beacons in the region and provide detailed information back to the user.