Google Beacon platform consists of the following three components,

1. Beacon device.
2. Eddystone format.
3. Proximity beacon API.

Beacon device

Beacon devices send one-way Bluetooth low energy(BLE) signals. These devices send data as Bluetooth beacon frames. With Eddystone, one beacon can send different frames in an interleaved fashion.

Eddystone format

Eddystone is an open beacon format developed by Google. The Eddystone specification defines several BLE frames as proximity beacon messages. Eddystone Beacon works with both iOS and Android devices. In the case of iOS devices, the only limitation is that Eddystone works only when the application is in the foreground. So app suggestion or region monitoring features will not work with the Eddystone beacon. Although an app can be made to work with both iBeacon and Eddystone using features of both beacon formats.

Eddystone frame types

Eddystone supports three types of frame

1. Eddystone-UID This packet type is used for the identification of the beacon, composed of 10 bytes namespace and 6 bytes instance. Namespace can be used to identify a class of beacons and instance can be used to identify individual beacons in a class.
2. Eddystone-URL This packet contains a URL. This way the Eddystone device can push contextual URLs to the client. The client can choose to perform different actions with these URLs. So for this capability, beacons can be used to implement a physical web.
3. Eddystone-TLMThese packets are used to broadcast various telemetry information about the beacon itself such as battery voltage, device temperature, and counts of broadcast packets.

Proximity Beacon API

Google Proximity Beacon API is a cloud service that provides additional capabilities. The Proximity Beacon API allows the admin app to register beacons and add attachments (very small arbitrary data) specific to one beacon or a set of beacons. Attachments can be up to 1024 bytes long. When a particular beacon or a set of beacons are detected by the user end mobile app, the attachment can be served to the app by preferably Nearby API. Attachments received by an app will appear as individual messages but not grouped by beacon to the user`s mobile. Nearby messages also de-duplicate attachments.

The admin app can also delete, and list attachments associated with beacons.

The diagnostic component of the Proximity Beacon API is used to monitor the health of the registered beacon.

Nearby API

Nearby API is a publish-subscribe API, that lets you pass small binary payloads between internet-connected devices. Nearby uses a combination of Bluetooth, BLE, Wi-Fi, and an ultrasonic modem to communicate a unique-in-time pairing code between devices. The server facilitates the message exchange between devices that detect the same pairing code. In the case of beacons, the user’s mobile app gets the attachments when a particular beacon is detected as a Nearby message.

Example Use Case of Beacons and Attachments

A retail store can have multiple sections on multiple floors. The store can deploy beacons for each floor with multiple attachments and for each section with multiple attachments. The user`s mobile will get de-duplicated messages illustrated below,

Brief Steps of Implementation

An organization implementing the beacon infrastructure needs,

1. Beacon devices.
2. An Admin app is used by the organization.
3. The mobile app is used by the customers of the organization.
4. The API infrastructure of Google.

Create project at console.developers.google.com

1. Create a project.
2. Add and enable APIS (Proximity Beacon API, Google Maps SDK for iOS, Google Places API for iOS) in the APIs and auth section.
3. Generate OAuth 2.0 client ID for each client app(including the admin app). The clients need to call the APIs with the proper OAuth token in the Authorization Header of the HTTP requests.

Beacon Management By Admin App

To use a beacon, you have to register it with Google Beacon Registry using proximity API. Beacons are registered with their advertised ID. The JSON representation of the advertised ID consists of a type of beacon (EDDYSTONE, IBEACON, ALTBEACON) and the actual id of the beacon(represented as Base64 string). Also, you can associate a place ID (a unique ID that identifies a place in Google places database and map) with the beacon while registering.

Google Beacon Registry generates a beacon name(in this case “beacons/3! 1b4cba0cdfc24d7385b7952305398286”) and returns the JSON beacon structure.

Admin app performs several other beacon management jobs e.g. activating a beacon(a user can observe the beacon), deactivating a beacon(no user can observe the beacon), updating a beacon, and decommissioning a beacon, using separate proximity APIs.

Attachment Management By Admin App

Admin app creates attachment using proximity API, say for the beacon named “beacons/3! 1b4cba0cdfc24d7385b7952305398286” by sending the following request. The `namespacedType` is of the form {namespaceName}/{Type} where `namespaceName` is fixed for a project, and can be queried by a separate request to the server, please check the documentation. {Type} can be any string, depending upon the business logic.

The server returns an attachment with a name (“beacons/ 3!1b4cba0cdfc24d7385b7952305398286/ attachments/ 55a4a9a4-1d5f-470a-b9d5-8555d1a1851b”) assigned to it. Google Beacon Platform code-4

Admin app can also list, and delete attachments by using separate proximity APIs.

Beacon Detection By Mobile App

To use the Nearby Messages APIs,

1. Add Nearby Messages API to the beacon project created at earlier stage at console.developers.google.com
2. Generate an API for iOS Devices
3. Install the API in your iOS mobile project using CocoaPods.

References

1. Google Beacon Platform

1. Proximity Beacon API

1. Nearby Messages API

Code Samples By Google

Author: Sujal Ghosh