BLUETOOTH SPECIFICATION Version 4.

2 [Vol 6, Part B]
Link Layer Specification
2 AIR INTERFACE PACKETS
LE devices shall use the packets as defined:

The Link Layer has only one packet format used for both advertising channel
packets and data channel packets.

The Preamble is transmitted first, followed by the Access Address, followed by

the PDU followed by the CRC.
The shortest packet is 80 bits in length. The longest packet is 2120 bits in
length.

2.1.1 Preamble
-used in the receiver to perform frequency synchronization, symbol timing estimation,
and Automatic Gain Control (AGC) training.
Advertising channel packets shall have 10101010b as the preamble.
The data channel packet preamble is either 10101010b or 01010101b, depending on
the LSB of the Access Address. If the LSB of the Access Address is 1, the preamble
shall be 01010101b, otherwise the preamble shall be 10101010b.

2.1.2 Access Address

The Access Address for all advertising channel packets shall be
10001110100010011011111011010110b (0x8E89BED6).

2.1.3 PDU
When a packet is transmitted in an advertising physical channel, the PDU shall be the
Advertising Channel PDU as defined in Section 2.3. When a packet is transmitted in a
data physical channel, the PDU shall be the Data Channel PDU as defined in Section
2.4.
2.1.4 CRC
At the end of every Link Layer packet there is a 24-bit CRC. It shall be calculated over
the PDU. The CRC polynomial is defined in Section 3.1.1

2.3 ADVERTISING CHANNEL PDU

The advertising channel PDU has a 16-bit header and a variable size payload. Its
format is as shown in Figure 2.2.
The 16 bit Header field of the advertising channel PDU is as shown in Figure 2.3.
The Length field of the advertising channel PDU header indicates the payload
field length in octets. The valid range of the Length field shall be 6 to 37 octets

Custom Data:

Within advertising channel PDUs, Advertising Data from the Host may be
included in the Payload in some PDU Types. The format of this data is defined in
[Vol. 3] Part C, Section Appendix A.

2.3.1 Advertising PDUs

The following advertising channel PDU Types are called advertising PDUs and
are used in the specified events:

• ADV_IND: connectable undirected advertising event

• ADV_DIRECT_IND: connectable directed advertising event
• ADV_NONCONN_IND: non-connectable undirected advertising event
• ADV_SCAN_IND: scannable undirected advertising event

These PDUs are sent by the Link Layer in the Advertising State and
received by a Link Layer in the Scanning State or Initiating State.

2.3.1.1 ADV_IND
The ADV_IND PDU has the Payload as shown in Figure 2.4. The PDU shall be used in
connectable undirected advertising events. The TxAdd in the advertising channel PDU
header indicates whether the advertiser’s address in the AdvA field is public (TxAdd = 0)
or random (TxAdd = 1).

The Payload field consists of AdvA and AdvData fields. The AdvA field shall contain the
advertiser’s public or random device address as indicated by TxAdd. The AdvData field
may contain Advertising Data from the advertiser’s Host.

2.3.1.2 ADV_DIRECT_IND
The ADV_DIRECT_IND PDU has the Payload as shown in Figure 2.5. The
PDU shall be used in connectable directed advertising events. The TxAdd in
the advertising channel PDU header indicates whether the advertiser’s
address in the AdvA field is public (TxAdd = 0) or random (TxAdd = 1). The
RxAdd in the advertising channel PDU header indicates whether the initiator’s
address in the InitA field is public (RxAdd = 0) or random (RxAdd = 1).

The Payload field consists of AdvA and InitA fields. The AdvA field shall contain
the advertiser’s public or random device address as indicated by TxAdd. The InitA field
is the address of the device to which this PDU is addressed. The InitA field shall contain
the initiator’s public or random device address as indicated by RxAdd.

Note: This packet does not contain any Host data.

2.3.1.3 ADV_NONCONN_IND
The ADV_NONCONN_IND PDU has the Payload as shown in Figure 2.6. The
PDU shall be used in non-connectable undirected advertising events. The TxAdd
in the advertising channel PDU header indicates whether the advertiser’s
address in the AdvA field is public (TxAdd = 0) or random (TxAdd = 1).

The Payload field consists of AdvA and AdvData fields. The AdvA field shall
contain the advertiser’s public or random device address as indicated by
TxAdd. The AdvData field may contain Advertising Data from the advertiser’s
Host.

2.3.1.4 ADV_SCAN_IND
The ADV_SCAN_IND PDU has the Payload as shown in Figure 2.7. The PDU
shall be used in scannable undirected advertising events. The TxAdd in the
advertising channel PDU header indicates whether the advertiser’s address in
the AdvA field is public (TxAdd = 0) or random (TxAdd = 1).
The Payload field consists of AdvA and AdvData fields. The AdvA field shall
contain the advertiser’s public or random device address as indicated by
TxAdd. The AdvData field may contain Advertising Data from the advertiser’s
Host.

2.3.2 Scanning PDUs

The following advertising channel PDU Types are called scanning PDUs. They
are used in the following states:
• SCAN_REQ: sent by the Link Layer in the Scanning State, received by a
Link Layer in the Advertising State
• SCAN_RSP: sent by the Link Layer in the Advertising State, received by a
Link Layer in the Scanning State
2.3.2.1 SCAN_REQ
The SCAN_REQ PDU has the Payload as shown in Figure 2.8. The TxAdd in
the advertising channel PDU header indicates whether the scanner’s address
in the ScanA field is public (TxAdd = 0) or random (TxAdd = 1). The RxAdd in
the advertising channel PDU header indicates whether the advertiser’s
address in the AdvA field is public (RxAdd = 0) or random (RxAdd = 1).

The Payload field consists of ScanA and AdvA fields. The ScanA field shall
contain the scanner’s public or random device address as indicated by TxAdd.
The AdvA field is the address of the device to which this PDU is addressed.
The AdvA field shall contain the advertiser’s public or random device address
as indicated by RxAdd.
Note: This packet does not contain any Host Data.

2.3.2.2 SCAN_RSP
The SCAN_RSP PDU has a format as shown in Figure 2.9. The TxAdd in the
advertising channel PDU header indicates whether the advertiser’s address in
the AdvA field is public (TxAdd = 0) or random (TxAdd = 1). The Length field
indicates the size of the payload (AdvA and ScanRspData) in octets.

The Payload field consists of AdvA and ScanRspData fields. The AdvA field
shall contain the advertiser’s public or random device address as indicated by
TxAdd. The ScanRspData field may contain any data from the advertiser’s
Host.

2.3.3 Initiating PDUs

The following advertising channel PDU Type is called the initiating PDU:
• CONNECT_REQ

This PDU is sent by the Link Layer in the Initiating State and received by the
Link Layer in the Advertising State.

2.3.3.1 CONNECT_REQ
The CONNECT_REQ PDU has the Payload as shown in Figure 2.10. TxAdd in the
advertising channel PDU header indicates whether the initiator’s device address in the
InitA field is public (TxAdd = 0) or random (TxAdd = 1). The RxAdd in the advertising
channel PDU header indicates whether the advertiser’s device address in the AdvA field
is public (RxAdd = 0) or random (RxAdd = 1).
BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C]
11 ADVERTISING AND SCAN RESPONSE DATA
FORMAT
The format of Advertising data and Scan Response data is shown in Figure 11.1. The
data consists of a significant part and a non-significant part. The significant part
contains a sequence of AD structures. Each AD structure shall have a Length field of
one octet, which contains the Length value, and a Data field of Length octets. The first
octet of the Data field contains the AD type field. The content of the remaining Length -
1 octet in the Data field depends on the value of the AD type field and is called the AD
data. The non-significant part extends the Advertising and Scan Response data to 31
octets and shall contain all-zero octets.

Only the significant part of the Advertising or Scan Response data needs to be
sent over the air.

The Advertising and Scan Response data is sent in advertising events. The
Advertising Data is placed in the AdvData field of ADV_IND, ADV_NONCONN_IND,
and ADV_SCAN_IND packets. The Scan Response data is sent in the
ScanRspData field of SCAN_RSP packets.

/////////////////////////////////////////////////////////////////////////////////////////////
Creating BLE beacons using Raspberry Pi
File: D:\IOT\Projects\Beacons\bluetooth\3. Building Bluetooth beacons\1. Beacon
Smart Starter Kit\tutorial\RaspberryPi\RaspberryPiTutorial

1. Task 1 – Set up your Raspberry Pi with NOOBS

2. Task 2 – Install BlueZ onto the Raspberry Pi
3. Create the Beacon Profile in Bluetooth Developer Studio:
a. Set up a new Beacon profile
b. Create the Beacon custom service

Two options to place beacon data(UUID, Major, Minor)

Method A – Adding in beacon data to a service and its characteristics

properties

I think not a good way

Method B – Adding in beacon data to the GAP Settings

- Adding beacon data in advertising message.
- According to 4.x standard only 31 bytes are available for user-specific payload
- Those 31 bytes shall be arranged according to recommendations specified in
“Supplement to Bluetooth Core Specification | CSSv7, Part A”