iBeacon, Bluetooth BLE and fleet management

Question

From what I have understood, minor and major ids in beacons are used for segmentation (for instance, major for physical stores and minor for different locations within a given store).

Then, as a beacon does not deliver rich payload, I guess those ids will be exploited to deserve the adequate information to the user - and probably through webservices.

Finally, UUID are said to be for the whole fleet. From what I understand, an app (e.g for retail store) is likely to register for only one or a few UUID (generally one, more for complex architectures or overload of services).

At the application level, you can (1) range for beacons when the app is foreground (with catching capabilities for minor/major ids), and (2) detect region exit/entry (monitoringForRegion:) while in background + deliver UILocalNotification to wake up the app (going back to (1)).

Now lets deal with the end user. I think we can assume that the average one will not go through a whole retail store with the app in foreground in his hand, and is more likely to have it running in background. Consequently, case (2) will be the most common one. But as all emitters will share the same UUID and as the geolocation manager running in background is monitoring for region linked to UUID, didEnter and didExit regions delegate methods risk no to be triggered intelligently depending on the range/configuration of emitters. Finally, not all the indoor location-based advertising you wanted to broadcast to your customers will be received and catched. In fact, I fear that only the one when the customer will arrive at the store location will be systematically suggested (in a background mode context).

Am I missing something?

Answer 1

You are mostly right. The one thing you are missing is that you can monitor on 20 different regions simultaneously, and these regions can optionally include the major and/or the minor. So you could trigger many times in a (big) store by intelligently designing your iBeacon identifiers and region monitors.

Two caveats: in-region monitoring callbacks fire when the beacon first comes into range (about 50m). They are also not simultaneous. They can take up to 15 min on an iPhone 4S with the app in the background, although it is faster on an iPhone 5.

Answer 2

To phrase what David said a little differently:

You can define a beacon region using a UUID, a UUID and a major value, or a UUID + a major and a minor value.

If you define a region using just the UUID, any beacon with that UUID will trigger a didEnterRegion message, and the OS will treat all beacons with that UUID as part of the same region.

However, if you create a region with UUID+Major, or UUID+Major+Minor, only beacons matching those values will trigger a region notification. You can have 2 beacons with the same UUID and major value right next to each other and different minor values. If you've registered 2 different regions with specific UUID+Major+Minor value, you'll get independent enter/exit/ranging messages about each region. A third beacon with the same UUID and major value but a different minor value will not trigger enter/exit notifications.