Access Address

The next 32 bits of a packet are the access address. This can be one of two types:

• Advertising access address

• Data access address

The advertising access address is used when broadcasting data or when advertising,

scanning, or initiating connections. The data access address is used in a connection after a connection has been established between two devices.

When a controller wants to receive a packet, it always knows which access address it will be receiving. As the receiver is turned on and tuned into the correct frequency, the receiver will start to receive bits of data. Even if no other device is around transmitting at this time, the radio will pick up background radiation. Given simple probabilities of receiving pure random noise, the chance of receiving a sequence of bits that matches the preamble is fairly high; typically, once every few minutes for a low-energy device with its receiver constantly open. Therefore, the access address is used to reduce the probability of random noise causing a pseudo-packet to be received.

The Link Layer also doesn’t know when the other device will be transmitting packets, so it has to keep a copy of all the possible bits that have been received for the last 40μs and check each time a new bit is shifted into this register to see if this sequence of bits now matches the expected preamble and access address. This process is called correlation of the access address.

For advertising channels, the access address is a fixed value: 0x8E89BED6. In binary this is transmitted from left to right as the following:

01101011011111011001000101110001

This means that for an advertising packet the preamble would be 01010101. This value was chosen because it has excellent correlation properties. The fixed value means that any Bluetooth low energy device can correlate against this access address and know it is

receiving an advertising packet, even though it might never have received a packet from this specific device before.

For data channels, the access address is a different random number on each and every connection between two devices. This random number, however, must adhere to a number

of rules, primarily to ensure that the access address still has good whiteness.

As is explained in Section 7.2.2 on whitening, it is necessary to whiten radio

transmissions to ensure that receivers can be built as easily as possible. The most basic rule is that there cannot be more than six zeros or ones anywhere in the access address. The packet also has to be different from the advertising access address by at least 1 bit. Also, the access address cannot have any repeating patterns; each octet of the access address must be

different. There should be no more than 24 bit transitions, stopping the use of an alternating bit sequence. Finally, there must be at least 2 bit transitions in the last 6 bits, to ensure that just before the header starts that there are bit transitions, just in case the header whitens to a long sequence of bits.

Given the preceding rules, it can be shown that there are approximately 2³¹ possible uniquely valid random access addresses. Or in other words, it is possible to have

approximately 2 billion Bluetooth low energy devices within range of one another, talking at the same time. That was probably a slight design overkill, but remember Bluetooth low

energy has been designed for success. Another useful feature of this random access address for data channels is that an attacker cannot determine which two devices are in a connection by just receiving this access address. This ensures the privacy of devices during a

connection.

7.3.4. Header

The next part of a packet is the header. The contents of the header depends on whether the packet is an advertising packet or a data packet.

For the advertising packet (see Figure 7–10), the header includes the advertising packet type as well as some flag bits to specify whether the packet includes public or random

addresses. There are seven advertising packet types, each having a different payload format and a different behavior:

• ADV_IND—General advertising indication

• ADV_DIRECT_IND—Direct connection indication

• ADV_NONCONN_IND—Nonconnectable indication

• ADV_SCAN_IND—Scannable indication

• SCAN_REQ—Active scanning request

• SCAN_RSP—Active scanning response

• CONNECT_REQ—Connection request

Figure 7–10. The contents of an advertising packet header

Figure 7–11 illustrates the header for data packets, which includes bits to enable the reliable delivery of packets, manage low power, and route the payload into either the local controller or to the host.

Figure 7–11. The contents of a data packet header 7.3.5. Length

For advertising packets, the length field comprises 6 bits, with valid values from 6 to 37. For data packets, it’s 5 bits in length with valid values from 0 to 31. After the length field is the payload, which contains the same number of bytes of data as the value in the length field.

It might appear strange that the length field is a different length for advertising packets and data packets. The main reason for this is a design decision that accomodates 31 bytes of useful data in an advertising packet. However, an advertising packet’s payload also always includes a 6-octet address for the advertising device. Adding the 6 octets of this address with the 31 octets of useful advertising data resulted in a packet length of 37 octets, and thus the requirement for a 6-bit length field.

Data packets are much easier. The size of data packets is less critical; most data being transferred is just a few octets in length, and therefore an absolutely maximal-sized packet was never considered useful. It’s also interesting to note at this point that if the packet is encrypted, it includes a 4-octet message integrity check value, shortening the actual data in the payload to just 27 octets. To keep the design of the Link Layer as simple as possible, unencrypted packets are not allowed to be longer than this 27-octet limit; this reduces the complexity of buffering within the Link Layer.

7.3.6. Payload

The payload is the actual “real” data that is being transmitted. It could be advertising data about the device or service data that is being broadcast to devices in the local area. It could be additional active scan response data such as the device name and the services it

implements. It could be information required to establish a connection or to maintain the connection once it is established. It could also be the application data that is being transmitted from one device to another.