Choosing UUID, Major, Minor and Eddystone-UID For Beacons

The id in the beacon advertising data can be formatted as either an Apple iBeacon id (UUID, major and minor) or Google’s Eddystone-UID. Unique ids are often used in computing to uniquely identify things. The idea is that the very large combination of (hex) digits is such that if you select a random unique id then it's very unlikely someone else has selected the same id.

If you want to generate a random UUID then just make one up. It has the format:

3ce2ef69-4414-469d-9d55-3ec7fcc38520

Where the each digit is hex. i.e. Has a Value of 0 to 9 or a to f.

Alternatively, you can use an online generator such as that provided by uuidgenerator or the OS X command line with the uuidgen utility. You use the respective manufacturer's configuration app to configure the UUID. Before entering the UUID, identify the app's UUID format in particular whether it's upper case, lower case and with or without dashes. You might need to adapt the above generated UUID accordingly.

iBeacons also have a major and a minor value that each have a range between 1 and 65535. How you arrange to use of UUID, major and minor is totally up to you. You also don't need to register them anywhere. Apple recommends your organisation use just one UUID across all locations and use the major for different towns/buildings and the minor for areas within those places. However, we have seen clients use multiple UUIDs at one place and also use different UUIDs for development and release. At the very least, make sure you don't use any documentation example or default beacon UUID values to avoid conflicts.

Bear in mind that the iOS app Region API relies on defining up to 20 regions to be monitored in background. A region can be a UUID or a UUID+Major or one beacon (UUID+Major+Minor). This is defined in the particular iOS app that's looking for beacons. If you use more than 20 regions you won't be able to monitor them all. Also, in background, a user needs to leave a region for at least 30 secs before that region will be triggered again. Another complication for background occurs when adjacent beacons' wireless coverage overlaps and the app needs to know the user has moved from one to the other. The beacons must be in different regions so the UUID/Major/Minor planning needs to ensure the regions don't overlap. Alternatively, this is sometimes solved by reducing each beacon's power such that the wireless coverage doesn't overlap but this still requires the user not to be within the region for at least 30 secs which usually isn't expected. The preceeding discussion is for background region monitoring. When in foreground, the iOS app can use the ranging API to differentiate between the beacons.

If you can, using the same or similar UUIDs makes it a lot easier to cut/paste/change values without having to type them all in fully each time into phone or web UIs. Make sure when entering the UUID into an app or web interface that you specify the right case (upper or lower case) and whether or not to use the dashes.

The Eddystone UID data has Namespace e.g 8b0ca750095477cb3e77 and Instance (e.g. 123456789abc) parts. The Namespace is intended to uniquely identify your company and the Instance identifies the beacon within your company. The Eddystone spec recommends you create the Namespace from either a SHA-1 hash of a fully-qualified (internet) domain name that you own or an elided (iBeacon) UUID.

For the SHA-1 option convert your domain name, without www, with an online tool such as the one at Waraxe IT Security and use the first 20 characters as the Namespace.

The other method is well described by Google:

"Generate a version 4 UUID then remove bytes 5 - 10 (inclusive). For example: from this UUID: 8b0ca750-e7a7-4e14-bd99-095477cb3e77 remove these bytes: e7a7-4e14-bd99. This produces the following namespace: 8b0ca750095477cb3e77."

You will get a different Namespace either way and that's intentional/expected.

The 6-byte instance (12 hex digits) value is up to however you choose to define, based on your places and areas within places.