Periodic Advertising with Responses (PAWR) is a new feature in Bluetooth 5.4. It extends the periodic advertising protocol from Bluetooth 5.0. Periodic advertising, where a device sends broadcast data with deterministic timing, can now carry bidirectional communication. The receivers can transmit response payloads back to the broadcaster. With PAwR, it's possible now to build an ultra-large one-to-many bidirectional network running on extremely low power. There are many applications where one must manage hundreds or thousands of energy-constrained devices with bidirectional communication, for example, Electronic Shelf Labels (ESL), sensor networks, warehouse management, etc. Let's take a deep dive into this very interesting new technology.
Table of Contents
1. How PAwR works
1.1 Advertising types
Bluetooth 5.4 defined three main types of advertising on the logical transport layer: Advertising Broadcast (ADVB), Periodic Advertising Broadcast (PADVB), and Periodic Advertising with Responses (PAwR). These advertising protocols allow an advertiser to broadcast data to any number of scanners in the surrounding, limited only by the RF range of the advertiser.
Both the Bluetooth LE legacy advertising and Bluetooth LE extended advertising are categorized as ADVB. In these modes, the broadcasting is irregular, and data is sent on only one direction. The scanners, in most cases, need to have sufficient power supply because there is no time synchronization between the scanner and the broadcaster. In addition, there is a 0-10 ms random delay added to the advertising interval to avoid timing collision between advertisers. This requires a large RX window on the scanner and, as a result, draws more current consumption.
Different from ADVB, periodic advertising (PADVB) does regular and precise timing broadcasting. There is a time synchronization between the scanner and the advertiser. The 0-10ms random delay of ADVB is not used in PADVB. Because of this, the scanner only needs to listen for a very short, predictable period of time. It's possible to build a large one-to-many low-power network with periodic advertising, for example, audio broadcasting, direction finding, IoT networks, etc. However, what is missing is that the low-power scanners can only receive data and are not able to send data back to the advertiser.
PAwR was introduced to solve this problem. It allows the advertiser to send precise, regular broadcast data and, at the same time, allows the scanners to send response payload back to the advertiser. In addition, it provides a mechanism for the advertiser to establish Bluetooth (Bluetooth LE) connections with the scanners when higher throughput is needed.
1.2 Timing
Similar to other types of advertising, PAwR operates on an interval called periodic advertising interval. This occurs precisely at the exact interval with no random delay. At each PAwR event, there will be multiple subevents. This is different from PADVB, where there is only one periodic advertising packet per event. Importantly, a scanner, when synced to PAwR, will not listen to all subevents but only select subevent(s) that it's subscribed/synced to. Multiple scanners can be subscribed to the same subevent. This mean a scanner can subscribe to multiple subevents. There can be up to 128 subevents per advertising event.
Zooming in on one of the subevents, at the beginning of the event, there is a transmission packet from the advertiser. It can be either:
AUX_SYNC_SUBEVENT_IND- periodic advertising packet.AUX_CONNECT_REQ- connection request from the advertiser.
All scanners synchronized to this subevent scan this packet and process the payload. After the packet, there is a train of response slots for the scanners to send their responses back to the advertiser. There can be up to 256 response slots. Which scanner to send on which response slot is up to the application/profile to define. To avoid collision, only one scanner should respond in a response slot.
This is the R part of PAwR, the main difference from the normal periodic advertising. This allows the forming of an ultra-large bidirectional one-to-many network with very little power consumption. As you can find, a scanner/observer only need to wake up every periodic advertising interval to scan for the subevent transmission packet. If it has data for the advertiser, it can transmit in one of the response slots and sleep again. One single advertiser can serve a large number of scanners as not all of them need to transmit data back at the same time. The latency is low; it can be as low as the periodic advertising interval, which is in the range of 7.5ms to 81.91875s depending on the configuration of the advertiser.
The limitation here is the throughput. If a scanner needs to transfer or receive a large amount of data, it may be limited by the advertising interval. As mentioned above, the interval can be up to 81.91875s, and changing the advertising interval to a shorter one requires updating all the scanners to sync to the new interval. In most cases, this is non-practical.
A solution for this is to establish a Bluetooth LE connection between the scanner and the advertiser. PAwR supports connection establishment without doing the traditional ADVB. To initiate the connection, the advertiser sends a AUX_CONNECT_REQ packet in the subevent transmission packet instead of the AUX_SYNC_SUBEVENT_IND packet. Inside AUX_CONNECT_REQ is the address of the scanner and the connection parameters that the scanner should use to enter the Bluetooth LE connection. The scanner to be connected is expected to respond with a AUX_CONNECT_RSP. This response should be sent right after the AUX_CONNECT_REQ packet without waiting for one of the response slots. A Bluetooth LE connection will be established right after that. The advertiser will become the central, and the scanner will become the peripheral. They can communicate with higher throughput via this separated Bluetooth LE connection.
1.3 Synchronization
To be able to follow the periodic advertising and subscribe to the subevent, the scanner needs to have sync and PAwR information from the advertiser. The procedure of getting sync information is similar to normal periodic advertising PADVB. The scanner either gets the info by scanning for the extended advertising packets ADV_EXT_IND:
Or by establishing a connection and performing the Periodic Advertising Sync Transfer (PAST) procedure.
There are pros and cons of both methods. Scanning extended advertising packet ADV_EXT_IND doesn't require a connection, but it requires the scanner to be able to conduct a continuous scanning to catch the advertising packet.
In contrast, having a connection and receiving timing information with PAST would work with a scanner that has a limited power supply, as it only requires the scanner to do normal Bluetooth LE advertising. However, it makes the advertiser's radio scheduling more demanding as the advertiser would need to do both periodic advertising and scanning to establish Bluetooth LE connection. An advertiser can decide not to do ADV_EXT_IND and only do periodic advertising AUX_SYNC_SUBEVENT_IND. This is to reduce the workload on the advertiser. In that case, PAST is the only option for synchronizing the scanner.
Compared to PADVB, besides SyncInfo (periodic advertising interval, sync Packet Window Offset), there is some extra information exchanged specifically for PAwR:
- ACAD- Additional Controller Advertising Data:
- Response Access Address
- Number of subevents
- Subevent Interval
- Response slot delay
- Response slot spacing
You may find that the information about which subevent(s) or which response slot(s) the scanner should subscribe to is not defined in these procedures. It's up to the application/upper layers to decide how the scanner should get the information about subevent(s) and response slot(s) it should use. For example, configure response slots when doing PAST, or hardcode it with the scanner so that it automatically chooses the slot based on its own address.
2. PAwR Advantages and Limitations
2.1 Advantages
- Bidirectional communication in one-to-many topology. PAwR added one important missing piece to Bluetooth offering: large-scale bidirectional one-to-many network. Prior to Bluetooth 5.4, common Bluetooth network topologies are:
- One-to-one. One peripheral connects to one central.
- One-to-many, star network. One central can connect to several peripherals, however, the number of links is limited, usually less than 20 connections per central.
- One-to-many broadcast. One advertiser can broadcast data to many observers. The number of observers can be very large, however, data is only communicated in one direction, from the advertiser to the observer
- Many-to-many, mesh. A mesh network can offer a large-scale bidirectional network. However, it requires an infrastructure of backbone nodes that relay messages. These backbone nodes usually need main power. A connected mesh could be a solution, but it can be complex and rigid.
With PAwR, a one-to-many network with hundreds or thousands of nodes can be established with a simple synchronization procedure. One single advertiser can manage the task of sending and receiving data to and from thousands of devices. The highlight here is that this two-way communication is done in a synchronized way, without flooding or potential collision. - Advertising data can be changed frequently. PAwR allows the advertising data to be changed frequently. In particular, the host can control exactly which data packet will go to which advertising subevent. This is something not available for ADVB and PADVB. With ADVB and PADVB, you can update advertising data over time, but the data is sent repeatedly, and you have limited control over how the data can be updated while the advertising is ongoing. With PAwR, the controller requests the host (the application) to update the data on every advertising event. The application has the ability to update each of the subevent advertising packets in each advertising event.
- Advertiser can establish a Bluetooth LE connection to a scanner. This is used when the peers need to transfer large amounts of data when the limited throughput of PAwR is not sufficient, for example, when transmitting a display image to an ESL label. It is slightly different from a normal Bluetooth LE connection that instead of the scanner, it's the periodic advertiser dictates the connection establishment with a scanner. It chooses which scanner should be connected. This makes sense because this can avoid the situation when a large number of nodes advertising at the same time to get connected, creating congestion on the advertising channels. And it allows the advertiser to schedule the new connection to not collide with the ongoing PAwR activity.
- Low power operation but still can have relatively low latency. The power consumption of the scanner would be similar to what it is when holding a normal Bluetooth LE connection. This means ultra low power consumption. A device can run on a coin cell battery for years with the latency equal to the network's periodic advertising interval.
2.2 Limitations
- The network relies on one single advertiser acting as the gateway/access point. This means all nodes in the network must be in the range of the advertiser. It's possible to expand the network with multiple advertisers, but the spec doesn't define how such a network should be set up.
- The throughput is limited. An advertiser needs to serve a large number of nodes, and the data throughput is relatively low compared to a normal Bluetooth LE connection, depending on the advertising interval and the size of the response slot.
- There may not be enough response slots for each scanner. Multiple scanners can sync to the same subevent, and it's often the case that there isn't enough response slot for each node in the subevent. The application needs to define how the scanners should take turn sending data to the access point.
- The design of PAwR put most of the complexity on the advertiser/access point's side. The advertiser must be powerful enough to handle the PAwR advertising, connection handling, and nodes managing tasks at the same time.
- PAwR only handles the lower end of the stack. It doesn't specify advanced features for the network, such as flow control, packet acknowledgment, encryption, authentication etc. The upper layers have the responsibility to define such features customized for the application.
3. Implementation in nRF Connect SDK.
This section focuses on how to implement the PAwR application in nRF Connect SDK. There are two pairs of samples in nRF Connect SDK added in v2.4.0 that demonstrate PAwR. We will take a deeper dive into the code to understand how PAwR is implemented in these samples.
- Periodic Advertising with Responses (PAwR) Advertiser and Synchronization (periodic_adv_rsp & periodic_sync_rsp):
- The advertiser does periodic advertising and scanning for PAST advertisers. After establishing Bluetooth LE connection, it will send the PAST info and then the subevent info.
- The observer/scanner at the beginning will do advertising to get PAST info. After it's synced, it will receive the subevent info to know which subevent it should listen to.
- Periodic Advertising Connection Procedure - Initiator and Responder (periodic_adv_conn & periodic_sync_conn):
- The advertiser only does periodic advertising and doesn't do PAST.
- The observer/scanner scans for the extended advertising packet and sync. After syncing, it will send the address to the advertiser in the PAwR response so that the advertiser can establish a connection with
AUX_CONNECT_REQ. The information about the subevent is hardcoded.
3.1 Advertising
Let's have a closer look at how periodic advertising is set up in the periodic_adv_rsp sample:
Configurations:
#define NUM_RSP_SLOTS 5
#define NUM_SUBEVENTS 5
static const struct bt_le_per_adv_param per_adv_params = {
.interval_min = 0xFF,
.interval_max = 0xFF,
.options = 0,
.num_subevents = NUM_SUBEVENTS,
.subevent_interval = 0x30,
.response_slot_delay = 0x5,
.response_slot_spacing = 0x50,
.num_response_slots = NUM_RSP_SLOTS,
};
struct bt_le_ext_adv *pawr_adv;
static const struct bt_le_ext_adv_cb adv_cb = {
.pawr_data_request = request_cb,
.pawr_response = response_cb,
};
You will need to pay extra attention when configuring the subevent and response slot timing parameter.
- The advertising interval should be ≥ subevent_interval * NUM_SUBEVENTS.
- The subevent_interval should be ≥ response_slot_delay + response_slot_spacing*NUM_RSP_SLOT
Otherwise you will receive error 12 BT_HCI_ERR_INVALID_PARAM.
Setup and start advertising:
/* Create a non-connectable non-scannable advertising set */ bt_le_ext_adv_create(BT_LE_EXT_ADV_NCONN, &adv_cb, &pawr_adv); /* Set periodic advertising parameters */ bt_le_per_adv_set_param(pawr_adv, &per_adv_params); /* Enable Periodic Advertising */ bt_le_per_adv_start(pawr_adv); /* Start Periodic Advertising */ bt_le_ext_adv_start(pawr_adv, BT_LE_EXT_ADV_START_DEFAULT);
After bt_le_ext_adv_start(), the advertiser will do both extended advertising and PAwR. This includes the packets showed at figure 4: ADV_EXT_IND, AUX_ADV_IND, and AUX_SYNC_SUBEVENT_IND.
As mentioned in the last section. An advertiser can choose not to do extended advertising (ADV_EXT_IND & AUX_ADV_IND) and only do periodic advertising. This will help reduce the extra advertising activities on the advertiser so it can serve more connections/responses. To stop extended advertising you call bt_le_ext_adv_stop() after the periodic advertising started. This will not stop the periodic advertising. To stop periodic advertising you need to call bt_le_per_adv_stop().
Note: Most sniffers rely on the extended advertising's Syncinfo to follow the periodic advertising train. If you turn off extended advertising, the sniffer won't be able to find the periodic advertising packets.
There are 2 callbacks for the periodic advertiser:
pawr_data_request: called when there is a buffer available for the advertiser to update the content for the subevent data packet. Normally you will receive a callback for each subevent slot to update. In this example, the code simply increase the counter by one on each subevent.pawr_response: called when there is a response from one of the scanner on one of the subevent. In the example the scanner simply echo back what it receives in the subevent packet.
These are the main differences to normal advertising or periodic advertising. You can now control the payload for the exact advertising packet (subevent packet). And you can get response data from a scanner which you can't have with the scan request when you do other types of advertising.
3.2 Synchronization
For synchronizing, either extended advertising or PAST is needed. If you want to do PAST, you would need to scans for normal advertising to establish Bluetooth LE connection then do PAST. You would need to call bt_le_per_adv_set_info_transfer() after the connection is established. This will send the syncinfo and the PAwR info to the scanner.
In the periodic_adv_rsp sample, you can find a write command to send some proprietary data (sync_config) about subevent number and response slot number for the scanner. This is up to the application to decide how this should be done.
The following code is from periorid_adv_rsp. The advertiser stop scanning after the maximum number of synced device reached.
while (num_synced < MAX_SYNCS) {
err = bt_le_scan_start(BT_LE_SCAN_PASSIVE, device_found);
if (err) {
printk("Scanning failed to start (err %d)\n", err);
return 0;
}
printk("Scanning successfully started\n");
k_sem_take(&sem_connected, K_FOREVER);
err = bt_le_per_adv_set_info_transfer(pawr_adv, default_conn, 0);
if (err) {
printk("Failed to send PAST (err %d)\n", err);
goto disconnect;
}
printk("PAST sent\n");
discover_params.uuid = &pawr_char_uuid.uuid;
discover_params.func = discover_func;
discover_params.start_handle = BT_ATT_FIRST_ATTRIBUTE_HANDLE;
discover_params.end_handle = BT_ATT_LAST_ATTRIBUTE_HANDLE;
discover_params.type = BT_GATT_DISCOVER_CHARACTERISTIC;
err = bt_gatt_discover(default_conn, &discover_params);
if (err) {
printk("Discovery failed (err %d)\n", err);
goto disconnect;
}
printk("Discovery started\n");
err = k_sem_take(&sem_discovered, K_SECONDS(10));
if (err) {
printk("Timed out during GATT discovery\n");
goto disconnect;
}
sync_config.subevent = num_synced % NUM_SUBEVENTS;
sync_config.response_slot = num_synced / NUM_RSP_SLOTS;
num_synced++;
write_params.func = write_func;
write_params.handle = pawr_attr_handle;
write_params.offset = 0;
write_params.data = &sync_config;
write_params.length = sizeof(sync_config);
err = bt_gatt_write(default_conn, &write_params);
if (err) {
printk("Write failed (err %d)\n", err);
num_synced--;
goto disconnect;
}
printk("Write started\n");
err = k_sem_take(&sem_written, K_SECONDS(10));
if (err) {
printk("Timed out during GATT write\n");
num_synced--;
goto disconnect;
}
printk("PAwR config written to sync %d, disconnecting\n", num_synced - 1);
disconnect:
err = bt_conn_disconnect(default_conn, BT_HCI_ERR_REMOTE_USER_TERM_CONN);
if (err) {
return 0;
}
k_sem_take(&sem_disconnected, K_FOREVER);
}
The advertiser goes straight to disconnect after sending the transfer information. It doesn't know if the scanner has synced to the PAwR train or not. It can be improved by putting a delay before disconnecting or better have a response from the scanner before disconnect. You can find the delay added in the provided code at the end of this guide.
On the scanner's side, if you have a look at perioridc_sync_conn sample you can find how it register PAwR and scans for extended advertising packet that contain sync and PAwr information.
bt_le_scan_cb_register(&scan_callbacks);
bt_le_per_adv_sync_cb_register(&sync_callbacks);
err = bt_le_scan_start(BT_LE_SCAN_ACTIVE, NULL);
if (err) {
printk("failed (err %d)\n", err);
return 0;
}
Note that after you have captured the extended advertising packet you would need to create sync object so that the scanner can start following the periodic advertising packet. To create sync object you call bt_le_per_adv_sync_create(). This will allow you to receive the bt_le_per_adv_sync_cb.synced callback when the scanner synced to periodic advertising (not PAwR) :
static void sync_cb(struct bt_le_per_adv_sync *sync, struct bt_le_per_adv_sync_synced_info *info)
{
struct bt_le_per_adv_sync_subevent_params params;
uint8_t subevents[1];
char le_addr[BT_ADDR_LE_STR_LEN];
int err;
bt_addr_le_to_str(info->addr, le_addr, sizeof(le_addr));
printk("Synced to %s with %d subevents\n", le_addr, info->num_subevents);
params.properties = 0;
params.num_subevents = 1;
params.subevents = subevents;
subevents[0] = 0;
err = bt_le_per_adv_sync_subevent(sync, ¶ms);
if (err) {
printk("Failed to set subevents to sync to (err %d)\n", err);
}
k_sem_give(&sem_per_sync);
}
As you may find in the code, after syncing, if you want to receive the PAwR subevent packet, you need to call bt_le_per_adv_sync_subevent() to subscribe to a subevent(s). In this sample the subevent to subscribe to is hardcoded to subevent 0 and the response slot in this subevent is also hardcoded to 0 (see recv_cb function).
The sample sends the device's address to the advertiser and wait for a connection (connection v2 via AUX_CONNECT_REQ) from the advertiser. This is specific to this application. Call bt_le_per_adv_set_response_data() with the subevent and the response slot you want to send data with.
static void recv_cb(struct bt_le_per_adv_sync *sync,
const struct bt_le_per_adv_sync_recv_info *info, struct net_buf_simple *buf)
{
int err;
struct bt_le_oob oob;
char addr_str[BT_ADDR_LE_STR_LEN];
if (default_conn) {
/* Only respond with address if not already connected */
return;
}
if (buf && buf->len) {
/* Respond with own address for the advertiser to connect to */
net_buf_simple_reset(&rsp_buf);
rsp_params.request_event = info->periodic_event_counter;
rsp_params.request_subevent = info->subevent;
rsp_params.response_subevent = info->subevent;
rsp_params.response_slot = 0;
err = bt_le_oob_get_local(BT_ID_DEFAULT, &oob);
if (err) {
printk("Failed to get OOB data (err %d)\n", err);
return;
}
bt_addr_le_to_str(&oob.addr, addr_str, sizeof(addr_str));
printk("Responding with own addr: %s\n", addr_str);
net_buf_simple_add_u8(&rsp_buf, sizeof(bt_addr_le_t));
net_buf_simple_add_u8(&rsp_buf, BT_DATA_LE_BT_DEVICE_ADDRESS);
net_buf_simple_add_mem(&rsp_buf, &oob.addr.a, sizeof(oob.addr.a));
net_buf_simple_add_u8(&rsp_buf, oob.addr.type);
err = bt_le_per_adv_set_response_data(sync, &rsp_params, &rsp_buf);
if (err) {
printk("Failed to send response (err %d)\n", err);
}
} else if (buf) {
printk("Received empty indication: subevent %d\n", info->subevent);
} else {
printk("Failed to receive indication: subevent %d\n", info->subevent);
}
}
3.3 Connection v2
A PAwR advertiser can decide to connect to a synced scanner when it needs to communicate with the scanner at higher throughput or lower latency. To do that the advertiser needs to have the scanner device's address and the subevent that the scanner listens to. To establish the connection you need to call bt_conn_le_create_synced():
bt_addr_le_to_str(&peer, addr_str, sizeof(addr_str));
printk("Connecting to %s in subevent %d\n", addr_str, info->subevent);
synced_param.peer = &peer;
synced_param.subevent = info->subevent;
/* Choose same interval as PAwR advertiser to avoid scheduling conflicts */
conn_param.interval_min = SUBEVENT_INTERVAL;
conn_param.interval_max = SUBEVENT_INTERVAL;
/* Default values */
conn_param.latency = 0;
conn_param.timeout = 400;
err = bt_conn_le_create_synced(adv, &synced_param, &conn_param, &default_conn);
if (err) {
printk("Failed to initiate connection (err %d)", err);
}
There is no concept of scan timeout when you do connection v2, the result of the bt_conn_le_create_synced() command is returned in the next periodic advertising interval in the callback.
Note: It is suggested to choose the connection interval to be equal or multiple of the subevent interval. This would cause less scheduling config resulting in better throughput.
4. Low power consumption demo
Attached is slightly modified version of the periodic_adv_rsp & periodic_sync_rsp samples. The advertiser will scan and establish Bluetooth LE connection to send PAST information and subevent information. The scanner after synced to the advertiser will send data back on each advertising interval.
The main modification is to turn off UART logging on the scanner and adding more meaningful data in the response. The scanner would send back its internal temperature on each response slot. The advertiser is slightly changed to make it more robust with longer advertising interval. The main point of the code is to demonstrate the low power consumption of the scanner (the sensor) with varied periodic advertising intervals.
You can download the demo source code here (tested on nRF Connect SDK v2.5.0): 8562.PAwR_Demo.zip
When running the demo, on the advertiser side you will see the temperature report from each scanner:
Unchanged from the periodic_adv_rsp, the advertiser only supports one scanner per subevent. However it should be possible to modify the code to support more scanner per subevent or to increase the number of subevent. You will need to decide the logic on how the scanners in the same subevent should send response back; very often the number of response slot per subevent is smaller than the number of scanner.
Following are some power measurements on the scanner with different periodic advertising interval, varied from 100ms to 1s to 10s. This varies the latency of the scanner. The longer the latency the lower the power consumption.
80uA at 100ms intervals, 4 bytes response for each subevent.
15uA at 1s interval 4 bytes response each subevent.
7.3uA at 10s interval, 4 bytes response each subevent.
One can achieve very low power consumption at 15uA at a relatively low latency of 1s. We can do a rough calculation considering a CR2032 battery with 250mAh capacity. If we can utilize 70% of the capacity for Bluetooth LE, it would last 250mAh * 70% / 15uA = 12500 hours = 520 days
5. Summary
PAwR is an exciting new feature of Bluetooth LE. It enhanced the periodic advertising protocol and may open the door for Bluetooth LE technology in new business verticals. Many applications that were once not possible or too complex to build can now be done with Bluetooth LE and PAwR. We are excited to see how it will be implemented and ready to help you get this technology out to the market.
Further reading:
- What's new in Bluetooth v5.4: An overview
- Technical overview of Bluetooth v5.4 (from Bluetooth SIG)
- Recording of a lecture about PAwR and ESL profile (from Bluetooth SIG)
- Our range of products that support Bluetooth LE v5.4: Nordic Semiconductor Bluetooth Low Energy products
- Zephyr's Bluetooth samples: https://docs.zephyrproject.org/latest/samples/bluetooth/bluetooth.html
If you are new to nRF Connect SDK or to Bluetooth Low Energy, it's recommended to get started with our Developer Academy courses: nRF Connect fundamentals and Bluetooth LE fundamentals.
If you have further questions or issues with the demo or the content of the guide, please create a DevZone ticket with a link to this guide. We will try to avoid having long discussions or troubleshooting in the guide's comment section.