Bluetooth 5 For Advertisements: Everything need to know

Bluetooth Low Energy uses 40 different frequency channels (PHY channels), separated by 2 MHz. Three (3) of these channels are called Primary Advertisement channels, while the remaining 37 channels are used for Secondary Advertisements as well as Data channels for transfers during a connection. Advertisements are used by devices to broadcast data and info for other observer devices to discover and process. It allows the device to broadcast this information for multiple devices to discover without a connection between the observers and broadcaster.

Advertisements always start with advertisement packets sent on the 3 primary channels (or a subset of these channels). Extra information can then be offloaded to the Secondary advertisement channels to allow for more data to be broadcast. There’s also an additional mode called Periodic Advertisement that allows a scanner or observer to be synchronized with the advertisements sent continuously by the broadcaster.

The two main categories of advertisements are:

1. Legacy Advertisements (same advertisements from the previous versions of Bluetooth Low Energy 4.0, 4.1, 4.2 and also exist in 5.0). They include the following types of PDU (Protocol Data Unit):
   1. ADV_IND
   2. ADV_DIRECT_IND
   3. ADV_NONCONN_IND
   4. ADV_SCAN_IND
2. Extended Advertisements (introduced in Bluetooth 5). These can be utilized for sending more data than the legacy advertisements allow. They can also be used to initiate Periodic Advertisements. Extended Advertisements can only be discovered by devices that support this feature. They include the following types of PDU (Protocol Data Unit):
   1. ADV_EXT_IND
   2. AUX_ADV_IND
   3. AUX_SYNC_IND
   4. AUX_CHAIN_IND

To better understand the different advertising PDUs and which PHY is allowed for each, we refer to the spec (Volume 6, Part B, Section 2.3):

This table lays out the PHYs can be used for each of the Advertising PDU Types. You will notice that all the legacy advertisement PDUs we listed can only be sent on the original LE 1M PHY, and that the only Primary Advertisement PDU that can be sent on anything other than the 1M PHY is the ADV_EXT_IND (which is the only case where one of the new PHYs can be used on the primary advertising channels). All others are Secondary Advertising packets and can be sent on any of the three PHYs.

To better understand where each of these PDU types is used, let’s look at another table from the Bluetooth 5.0 Spec (Volume 6, Part B, Section 4.4.2, Table 4.1):

You’ll notice that the only Advertising Event that does not allow ADV_EXT_IND is the Connectable and Scannable Undirected Event. For this advertising event type, ADV_INT is the only type allowed.

A few notes about the two types of advertising channels:

Primary advertisement channels

• Set of 3 fixed PHY channels (channels 37, 38 & 39)
• Divided into advertising events where each event can occur on each of the 3 advertising PHY channels (or a subset)
• Consecutive events start with the first advertising PHY channel (e.g. if advertisements start with channel 37, then each event will start with an advertisement packet sent on channel 37)
• Events occur at regular intervals
• Some advertising devices allow scan requests or connection requests on the same advertising PHY channel
• The advertising device can send a scan response packet on the same advertising PHY channel within the same advertising event

Secondary advertisement channels

• Set of 37 fixed PHY channels (same as the data channels used during a connection – channels 0-36)
• Not part of the advertisement event, but rather part of the extended advertisement event
• Begin at the same time as the advertisement event on the primary channel and end with the last packet on the secondary channel
• Used to offload data that would otherwise exist on the primary channel
• They are called “auxiliary packets”
• An advertisement packet on the primary channel contains the PHY channel and the offset to the start time of the extended advertisement packet
• Secondary advertisement channel can use any LE PHY (Uncoded 1M PHY, Uncoded 2M PHY, or Coded S=8 or S=2 PHY)
• All advertising packets in the secondary channel should use the same PHY

Extended Advertisements are a way to advertise more (offloaded) data than what’s allowed with Legacy Advertisements. Offloading is accomplished by first advertising on the primary channel that points to an auxiliary packet on the secondary channel.

Note: Since non-Bluetooth 5 devices will not be able to discover extended advertisements, it is recommended that advertisers also use an advertising set with legacy advertising PDUs for older scanning devices to be able to discover the end device.

Advertising sets are used to send out different types of advertising events simultaneously. Each advertisement set will have different advertisement parameters such as advertising PDU type, advertising interval, and PHY.

When advertising on the LE Uncoded 1M PHY:

• Scan requests and responses can take place on the same PHY channel as the original advertisement or be offloaded to the secondary channel.
• In some cases when advertising on the Uncoded PHY, connection requests and responses are offloaded to the secondary channel.

When advertising on the LE Coded PHY:

• Scan requests, scan responses, connection requests, and connection responses ARE ALWAYS offloaded to the secondary channel.

Periodic Advertisements

Another feature of Bluetooth 5 Extended Advertisements is Periodic Advertisements. These are used for broadcasting packets to devices at a set period between two unconnected devices, meaning that more than one device can listen and tune in on these periodic advertisements. They consist of advertisements sent at a fixed interval with the advertisement data changing from time to time.

The way this is accomplished is as follows (from the spec Volume 6, Part B, Section 4.4.2.3):

As you can see from the figure above, the primary advertisement channel is used to transmit the ADV_EXT_IND PDU type which holds information (Time offset, PHY…etc) that can be used to find the AUX_ADV_IND PDU packet. That packet, in turn, contains the SyncInfo field which defines the data needed to synchronize to the periodic advertisement packets (AUX_SYNC_IND and AUX_CHAIN_IND) in a way similar to how connections are formed (channel map, hop sequence, which PHY…etc).

Therefore, a scanner can target an advertising device by first discovering the advertisement event on the primary channel, and then tuning into the appropriate secondary channel and timing based on information sent in the primary advertisement packet.

An example of Extended Advertisements (on nRF52 Series) and sniffing using Ellisys Bluetooth Tracker

We will go through an example of implementing Bluetooth 5 Extended Advertisements using the nRF52840 Preview Development Kit and show the packets as captured by the Ellisys Bluetooth Tracker sniffer.

This example will be based on the nRF52840 Preview Development Kit (PDK) by Nordic Semiconductor. If you haven’t set up your development environment for this development kit, then follow my Complete nRF52 Mac Development Tutorial. In this example, however, I’ll be using the experimental Blinky peripheral app example provided by the nRF SDK.

In order to implement Bluetooth 5 features on the nRF52840 PDK, you will need to do the following:

1. Make sure you start with the latest SDK version (in my case, 13.1.0, available here).
2. Update to use a SoftDevice release with version >= 5.0.0-3.alpha (available here).
3. Update the linker file to support the new SoftDevice (since the current version of the SDK v13.1.0 does not include this SoftDevice release yet).
4. Update the Makefile to use the new SoftDevice image when flashing the target.
5. Modify an example program to implement Bluetooth 5 features (in our case, we are implementing the Extended Advertisement feature).
6. Flash the target device with the SoftDevice (version >= 5.0.0-3.alpha).
7. Flash the target device with the compiled application.
8. You will need another device that supports Bluetooth 5 Extended Advertisements to discover and listen to the advertisements sent by the target (you can either use a Bluetooth 5 sniffer or another development Kit configured as a scanner/observer).

Let’s go over each step in detail.

Steps 1-4: Update the SDK and the SoftDevice

I recommend you make a copy of the SDK and make this change in the copy so you don’t end up breaking other applications you’ve developed that rely on older SoftDevice releases. In my case, I started with the example app labeled “experimental_ble_app_blinky” under the examples/ble_peripheral folder of the nRF5 SDK.

Download the latest SoftDevice version 5.0.0-3.alpha or greater available here. You can follow the migration document that’s included in the release to update your application to use the new SoftDevice release. Here are the steps to take:

• Extract the downloaded file to a known location
• Navigate to the folder labeled s140_nrf52840_5.0.0-3.alpha_API and copy and overwrite the contents of the folder named include to the folder located at components/softdevice/s140/headers
• Create a project using the example experimental_ble_app_blinky in NetBeans (or any other IDE of choice). You can follow my tutorial on Setting up your Mac Development environment for nRF52.
• Navigate to the folder components/softdevice/s140/hex and copy the file s140_nrf52840_5.0.0-3.alpha_softdevice.hex from the SoftDevice folder you download
• Navigate to the experimental_ble_app_blinky/pca10056/s140/armgcc/ folder and edit the file Makefile to reflect the changes below. The file is updated to flash the device with the new SoftDevice version instead of the older one.

• Update the file experimental_ble_app_blinky/pca10056/s140/armgcc/experimental_ble_app_blinky_gcc_nrf52.ld to reflect the following changes below. This change is meant to accommodate the update of the SoftDevice which takes more space in Flash and thus pushing out the application to start from the address at 0x24000.

Step 5: Modify an example program to implement Bluetooth 5 features

• Update experimental_ble_app_blinky‘s main.c to reflect the following:

This example showcases the following advertisement configuration:

• Enables Extended Advertisements via:

• Configures the Primary Advertisement to use the LE 1M PHY:

• Configures the Secondary Advertisement to use the LE 2M PHY:

• You can modify the Primary PHY to use the LE 1M PHY instead (per the spec and Table that’s shown above – you cannot use LE 2M PHY)
• You can modify the Secondary PHY to use any of the three PHYs (LE 1M PHY, LE 2M PHY, or LE Coded PHY)
• The advertisement data will be broadcast and sent over the extended advertisement packets. In this case, it will include the Name and the LBS_UUID_SERVICE (LED Button Service Server).

Steps 6 & 7: Flashing the SoftDevice and Application firmware

Follow my tutorial on Setting up your Mac Development environment for nRF52.

Step 8: Use a sniffer or another Bluetooth 5 device to capture advertisements

Here’s a video tutorial showing the different advertisement settings and how they appear when captured by the Ellisys Tracker.

From the Ellisys Tracker sniffer capture:

Unfortunately, the nRF5x SDK and SoftDevice (as of July 2017) does not yet support advertisement packets to contain data larger than 31 bytes, so the name here is cut off, even though we specified it as a Complete Local Name instead of a Shortened Local Name (the API shortened it for us).