The iBeacon Protocol - Building Applications with iBeacon (2015)

Building Applications with iBeacon (2015)

Chapter 2. The iBeacon Protocol

iBeacons are transmit-only devices. They work by periodically transmitting numerical identifiers that are mapped into actions by an application on a mobile device. As a result, the “protocol” that they use is simple and is basically a vehicle to deliver numerical identifiers to nearby clients.

Translating those numbers into concrete action requires building an app for mobile devices. The simplicity of the protocol hides the big challenge, which is that application developers and user experience designers need to figure out how to make applications interact more tightly with the physical world.

Bluetooth Basics of an iBeacon

The iBeacon advertising function is transmit-only. Many iBeacon devices will implement a Bluetooth receiver for monitoring and configuration functions, but the protocol itself is transmit-only.

In the jargon of the Bluetooth specification, an iBeacon is a broadcaster, a type of device that is specific to Bluetooth Low Energy. Broadcasters transmit periodic advertising packets, which contain information used by the receivers. iBeacon advertising packets are designed to be transmitted, but receivers do not need to respond to them.9 In effect, iBeacon advertising packets are thrown out into the air, and receivers can act on them (or not).


iBeacons send advertising packets. When a device receives an advertising packet, it results in the creation of an advertisement event at the receiver. Sometimes, advertising packets and events are also referred to generically as advertisements.

In effect, an iBeacon advertising packet says to the world, “Hello, I’m here, and my name is…” The difference is that the “name” in an iBeacon hello consists of three numerical identifiers:

Universal Unique Identifier (UUID) (128 bits)

Roughly speaking, the UUID transmitted by an iBeacon is a 128-bit identifier that uniquely identifies the organization the beacon belongs to. When iBeacons are used by, say, a chain of stores, the UUID will indicate the beacon is run by the company.

Major number (16 bits)

The Bluetooth and iBeacon specifications place no structure on the use of the major and minor numbers, but there is a hierarchy in the APIs used. The major number is used to identify major groups of beacons owned by one entity. In the example of a chain of stores, the major number will typically be used for all the beacons within one particular store.

Minor number (16 bits)

The minor number is used to identify the lowest level of the hierarchy within a set of beacons. Returning to the example of a chain of stores, the minor number will be used for individual beacons within a single store location, perhaps to identify a product on display.

Proximity estimation uses the received signal power of a frame at the receiver, a number called the received signal strength indication (RSSI). RSSI is not transmitted in the advertising packet, because it is the power level of the signal when it reaches the receiver.

As far as data transmitted, the payload of an iBeacon consists of these three numbers. By far the most important, as well as most often misunderstood, is the UUID.

The Universal Unique Identifier

Many items in the Bluetooth specification use a UUID to identify unique elements. In iBeacons, the field called a UUID is most formally referred to as the proximity UUID, to distinguish it from any other UUIDs that might be in use by a Bluetooth device. The UUID is used to identify iBeacons that are under common management, and in effect, the UUID sits at the top level of the hierarchy of numbers.

Unlike other network protocols, such as 802.11, the UUID is not centrally managed to avoid conflicts. The Bluetooth protocol assumes that UUIDs are unique across all space and time. IEEE 802 networks, such as wireless LANs, have centralized assignment to guarantee uniqueness, but Bluetooth does not. With 128 bits to use in the identifier, it is likely that well-designed random number generators will choose unique numbers.

Most UUIDs are created by random number generators and will often incorporate the current time and an identifier of the generator (such as a MAC address). Many iBeacon configuration applications have a Generate button to generate a random UUID. Mac OS X has a command-line utility to generate UUIDs as well:

Matthew-Gasts-MacBook:~$ uuidgen


Advertising Interval

Although the Bluetooth specification allows many advertising intervals, the iBeacon specification fixes the advertising interval at 100 ms. Setting the advertising interval is a balance between preserving battery life in beacons with long advertising intervals, but having advertisements be frequent enough to enable services to be built with iBeacons.


Bluetooth specifications are published by the Bluetooth SIG and are freely available to the public. iBeacons are based on version 4.0 of the Bluetooth specification. The iBeacon specification is made available to Apple developers.

iBeacon Advertising Packet Contents

iBeacons transmit advertising packets, shown in Figure 2-1.

Beacon Advertising Frame Format

Figure 2-1. iBeacon advertising packet format

Advertising packets always have the same length and are composed of a series of fixed fields. The latter part of the frame contains manufacturer-specific information defined by Apple. The main reason for defining a custom packet format is to improve the ranging capabilities of an iBeacon.

Advertising Header

The iBeacon advertising header contains four fields, which, in practice, are fixed for iBeacons:

Flags (3 bytes, 0x02-01-1A)

The Flags field is a length/type/value field. The first byte is a length indicator, which states that the Flags field has two additional bytes. The second byte describes the type, with a value of 1 indicating that the Value field contains flags. The Value field, which is the third byte, contains the flags themeselves. Most iBeacons report that they are capable of the general discovery mode and can use both low-energy and non-low-energy modes of operation. With those capabilities, the flag payload will be 1A.

Length (1 byte, 0x1A, decimal 26)

The remainder of the iBeacon advertising packet also has a length/type/value tuple. The Length field describes the length of the frame payload following this field. All iBeacon advertising packets are 30 bytes, but the Length field describes the length of the packet after three bytes of flags and the one-byte Length field for a total of 26.

Type (1 byte, 0xFF, decimal 256)

This value indicates the contents of the frame are manufacturer-specific data. The first two bytes contain the company identifier, and the company is free to define how to interpret the remaining fields. In the case of an iBeacon, the Company ID will be set to Apple. Part of the reason for maintaining a licensing system for use of the protocol is that every iBeacon uses Apple’s company ID, and Apple needs to ensure that devices implementing its ID are using it in the prescribed way.

Company ID (2 bytes, 0x004C)

Technically, this field is the start of the manufacturer-specific advertising payload. The Bluetooth specification requires that manufacturer-specific payloads begin with the company ID number. iBeacons start with Apple’s company ID number.10

As with most communications technologies, the header serves to introduce the payload, which immediately follows the end of the header.

iBeacon Payload

The payload is the workhorse of the iBeacon specification, and it contains the only fields in the entire advertisement that can be configured by the user. In addition to the three numerical fields, it also contains a calibration constant used in ranging.

These are the five fields in the iBeacon payload:

Beacon type (2 bytes, 0x02-15)

Apple has assigned a value for proximity beacons, which is used by all iBeacons. Some sources state that this is a two-byte field, with the first byte indicating a protocol identifier of 2 for iBeacon and the second byte indicating a length of 21 further bytes (15 in hex is 21 decimal).

Proximity UUID (16 bytes)

This field contains the UUID for the iBeacon. Typically, this will be set to the organization that owns the beacon. Not all beacon products allow this field to be set.

Major (2 bytes) and Minor (2 byte) numbers

These fields, each two bytes in length, contain the major or minor number that will be contained within the iBeacon’s broadcast.

Measured power (1 byte)

Implicit within the iBeacon protocol is the idea of ranging (identifying the distance a device is from a beacon, as discussed in “Ranging”). There may be slight variations in transmitter power, so an iBeacon is calibrated with a reference client. Measured power is set by holding a receiver one meter from the beacon and finding an average received signal strength. This field holds the measured power as a two’s complement.11 For example, a value of C5 indicates a measured power at one meter of –59 dBm.


Distance from an iBeacon is calculated by estimating the distance a signal must travel for it to fade to the level at which it is received, as adjusted by the calibration constant.

Although the iBeacon frame format is quite simple and has only a few variable parameters, those parameters are enough to support complex applications, as you will see in the next few chapters.

9 In the terminology of the Bluetooth specification, an iBeacon sends nonconnectable undirected advertising packets, which means that there is no attempt to establish any sort of connection between the iBeacon and any receivers.

10 The Bluetooth SIG provides a table of company identifiers within Bluetooth specifications.

11 Two’s complement is a common way of storing integers in computing.