Tag: BT5.4

Periodic Advertising with Responses (PAwR)
The major new function list 4 key operation as below：

• Periodic Advertising with Responses (PAwR)
  PAwR is a new Bluetooth Low Energy (LE) logical transport that provides a way to perform energy efficient, bi-directional, communication in a large-scale one-to-many topology.
• Encrypted Advertising Data
  This new feature provides a standardized approach to the secure broadcasting of data in advertising packets.
• LE GATT Security Levels Characteristic
  Devices may now indicate the security mode and level required for all their GATT functionality to be available using a new GATT characteristic called LE GATT Security Levels.
• Advertising Coding Selection
  The Host can now specify which of two supported long range coding options are used with LE extended advertising.

Background

The Bluetooth Core Specification defines several concepts that collectively constitute the Bluetooth

data transport architecture. Among these concepts are the Physical Transport, Physical Channel,

Physical Link, Logical Link, and Logical Transport. Certain combinations and configurations are

defined for use in support of different application types, each with particular characteristics relating

to properties such as topology, timing, reliability, power, and channel use. The terms operational

mode or mode of operation are sometimes used informally to refer to the various data transport

architecture configurations.

Advertising Modes and Basic Properties

Specific combinations of these properties are defined together with the circumstances in which

they may be used, in the Bluetooth Core Specification. The selected combination is indicated by the

type(s) of PDU transmitted or by the value of a field called AdvMode, which is present in some PDU

types. Examples of defined combinations include connectable undirected advertising and connectable

and scannable advertising.

Advertising Modes and Basic Properties

Advertising is a form of connectionless communication that, depending on how it is performed, has

various properties that affect the behaviors of the advertising device and other devices that receive

its transmitted advertising packets.

• connectable vs. non-connectable

Connectable advertising means that a scanning device may respond to a received advertising packet by transmitting a request to form a connection with the advertising device.

• scannable vs non-scannable

Scannable advertising means scanning devices may respond to an advertising packet by transmitting a scan request, asking for more application data from the advertiser.

• directed vs. non-directed

When performing directed advertising, packets are addressed to a specific scanning device and will be ignored by other devices. Non-directed advertising packets are not addressed to a specific device and may be processed by any scanning device.

• Irregular vs. fixed interval periodic

Advertising can be performed with a precise transmission schedule, and this is known as periodic advertising. Other forms of advertising operate to an irregular schedule. A random delay value between 0 and 10 ms is added to a fixed advertising interval to perturb advertising events in time.

Legacy Advertising

When performing legacy advertising, identical copies of legacy advertising packets are transmitted

on up to three primary advertising channels, one channel at a time and in some pseudorandom

sequence.

The transmission of legacy advertising packets takes place during advertising events. The scheduling

of advertising events is primarily controlled by a link layer timing parameter, advInterval. But

advertising events are made slightly irregular, so persistent collisions with other advertising devices

are avoided. This is achieved by assigning a parameter known as advDelay, a pseudo-random value in

the range of 0 – 10ms, and adding it to the fixed advInterval so that advertising events are perturbed

in time. Below figure illustrates this.

Legacy advertising packets can contain application data in the AdvData field, but scan request packets cannot. Therefore the direction of packet transmissions can be bidirectional, but the transfer of application data using advertising and scan response PDUs is a strictly one-way capability.

Extended Advertising

This use of extended advertising is referred to here as irregular extended advertising.

The LE Periodic Advertising Broadcast (PADVB) logical transport is another form of extended

advertising but is designated a distinct logical transport because it uses regular, fixed-rate timing for

event and packet transmission scheduling.

Irregular extended advertising and periodic advertising both use the 37 general-purpose channels and

the three primary advertising channels.

Irregular Extended Advertising

Irregular extended advertising is comparable with legacy advertising in that some extended

advertising PDU types are only ever transmitted on the primary advertising channels. Their

transmission scheduling is irregular due to the addition of the random advDelay value in the range

of 0 to 10 ms in calculating advertising event times. It differs from legacy advertising in a number of

ways including that distinct PDU types are used. Some of these PDU types are transmitted only on

the primary advertising channels, but may be linked by a pointer field called AuxPtr to others that

are transmitted only on the secondary advertising channels. Larger payloads may be handled by

fragmenting the data and transmitting it in multiple PDUs linked together or chained using AuxPtr in

certain PDU types.

Periodic Advertising (PADVB)

When the periodic advertising (PADVB) logical transport is used, the broadcasting device transmits

packets to a fixed interval, deterministic schedule, and Observer devices can discover the Broadcaster’s transmission schedule and synchronize their scanning to it. This can be accomplished

by acquiring information from the SyncInfo field within an AUX_ADV_IND PDU or by using a

procedure called Periodic Advertising Sync Transfer (PAST).

PAST involves a device passing periodic advertising synchronization parameter values over an LEACL

connection to the Observer. The device passing these details may be the Broadcaster itself or

a third device that acquires the synchronization parameters by scanning for AUX_ADV_IND PDUs

transmitted by the Broadcaster. The procedure avoids the need for the Observer, which may be a

small, power-constrained device, to scan for synchronization data itself, a potentially

expensive operation.

By precisely synchronizing with the Broadcaster’s transmission schedule, the Observer can scan in

the most energy-efficient way.

Periodic advertising involves multiple extended advertising PDU types and all 40 radio channels,

as depicted in Figure below picture. Here we see ADV_EXT_IND PDUs transmitted on the primary advertising channel, with AuxPtr pointing to an associated AUX_ADV_IND PDU transmitted on the secondary channels. This PDU contains the SyncInfo field which contains information that allows an Observer to synchronize its scanning with the periodic transmission of AUX_SYNC_IND PDUs. Note that the

Observer only needs to receive one ADV_EXT_IND PDU to be able to acquire the periodic advertising

synchronization data in the SyncInfo field of a AUX_ADV_IND PDU. Once this has been achieved, it

can proceed to only scan for AUX_SYNC_IND PDUs

AUX_SYNC_IND PDU

The AUX_SYNC_IND advertising PDU type is transmitted at fixed intervals. It is not possible for

Observers to respond to PADVB periodic advertising PDUs and hence this logical transport only

supports unidirectional communication of application data.

Comparing Legacy Advertising and Extended Advertising

Below table summarize some of the important differences between legacy advertising and

extended advertising.

About Periodic Advertising with Responses (PAwR)

Overview

PAwR is similar to periodic advertising (PADVB) in several ways:

• PADVB allows application data to be transmitted by one device (the Broadcaster) to one or

more receiving devices (the Observers), forming a one-to-many communication topology. The

same is true of PAwR.

• PAwR and PADVB both use a connectionless communication method.
• Transmission of advertising packets is periodic with a fixed interval and no random

perturbation of the schedule in both cases.

• Observers can establish the periodic transmission schedule used by the Broadcaster from

AUX_ADV_IND PDUs or by using the Periodic Advertising Sync Transfer (PAST) procedure.

PAwR differs from PADVB as follows:

• PADVB supports the unidirectional communication of data from a Broadcaster to Observers

only. PAwR Observers can transmit response packets back to the Broadcaster. PAwR provides

a bidirectional, connectionless communication mechanism.

• Synchronization information for periodic advertising without responses (PADVB) is contained

within the Sync Info field of AUX_ADV_IND PDUs. Synchronization information for periodic

advertising with responses (PAwR) is contained within the SyncInfo field and in the ACAD field

of AUX_ADV_IND PDUs.

• The PADVB Broadcaster schedules transmissions within advertising events. The PAwR

Broadcaster schedules transmissions in a series of events and subevents, and Observers

are expected to have synchronized in such a way as to listen during a specific subevent or

subevents only.

• The PAwR Broadcaster may use a transmission time slot to send a connection request (AUX_

CONNECT_REQ) to a specific device and establish an LE-ACL connection with it. PADVB

does not have this capability.

• With periodic advertising without responses (PADVB), application data tends to only change

from time to time. PAwR is designed with the expectation that application data will

change frequently.

• With PADVB, the same application data is delivered to all Observer devices synchronized to

the same advertising set. With PAwR, different data can be delivered to each Observer device

or set of Observer devices.

• Support for the Periodic Advertising Sync Transfer (PAST) procedure is optional with PADVB

but mandatory with PAwR.

Benefits

Bidirectional Connectionless Communication

PAwR supports the bidirectional exchange of application data using connectionless communication,

which was not previously possible with Bluetooth LE.

Scalability

PAwR offers a more scalable way to create a one-to-many topology capable of bidirectional

application data communication than a collection of LE-ACL connections. It is common for no more

than a handful of concurrent LE-ACL connections to be supported by a Central device3 , whereas

bidirectional communication with thousands of devices is possible using PAwR.

Energy Efficiency

Synchronization between the Broadcaster and each Observer takes place at subevent level, meaning

that Observers only scan during a small subset of all Broadcaster transmissions. The subevent

synchronization process involves application logic, so packets received will usually contain data of

relevance to the Observer. This energy-efficient approach means Observer devices could run off

batteries for several years. Section 1.2.3.6 Battery Life illustrates.

Flexible Topologies and Receiver Concurrency

PaWR offers flexibility in terms of the topologies supported. When a PAwR Broadcaster transmits a

packet, it does so in a subevent. The packet is received by all devices synchronized to that subevent,

and this may be a single device, a subset of the complete set of the Observer devices, or all such

devices, depending on the application-layer rules for subevent synchronization.

With PADVB, each advertising set forms a one-to-many topology, and all devices synchronized to an

advertising set receive data at each broadcast.

Applications

PAwR is well-suited to applications that need to send and receive messages between a central hub

device and a large number of other devices in a network. Messages could contain commands or

sensor data values, or other data, as defined by the application layer. The Electronic Shelf Label (ESL)

profile uses PAwR to transport messages containing commands and responses and serves as a good

example of PAwR in use.

PAwR is not intended to be used for products that require a real-time messaging capability. As will

be explained in the Technical Highlights section, PAwR works by periodically transmitting a series of

packets, one after the other in specific time slots known as subevents. Devices are configured so that

they listen during certain subevents only and therefore it is common for there be a delay between

the start of a use case which delivers commands or data to devices across the network, and the

transmission time slot for each device arising. Consequently, a noticeable elapsed time will

sometimes be experienced when sending messages to multiple, unrelated devices. The elapsed time

will vary in magnitude from milliseconds to tens of seconds, depending on details of the use case and

system configuration.

By way of contrast, Bluetooth mesh networking also makes use of a system of messaging for

commands and sensor data. However, Bluetooth mesh offers a near to real-time messaging solution,

with messages sent and responded to more or less immediately. To achieve this though, mesh

devices perform passive scanning with a duty cycle as close to 100 percent as possible and this has

consequences for energy consumption. PAwR devices such as electronic shelf labels operate to a low

duty cycle and therefore perform well in terms of energy efficiency.

Technical Highlights

Events, Sub-events, and Response Slots

Understanding how PAwR partitions and uses time is key to understanding this logical transport.

As with other advertising modes, activity takes place in events which in the case of PAwR are known

as Periodic advertising with responses events (PAwR events). These events occur at fixed intervals,

with no random perturbation in scheduling. An event starts every periodic advertising interval ms.

Each PAwR event consists of several subevents, and it is during subevents that advertising packets

are transmitted. The Host configures the number of subevents per event up to a maximum of 128. A

subevent starts every periodic advertising subevent interval ms. The Host configures the number of

subevents per event and the periodic advertising subevent interval using a Host Controller Interface

(HCI) command called HCI_LE_Set_Periodic_Advertising_Parameters V2 (or later).

See Figure：

In each subevent, the Broadcaster transmits one packet, which usually contains an AUX_SYNC_

SUBEVENT_IND PDU but may instead contain an AUX_CONNECT_REQ PDU. After a delay, known

as the Periodic Advertising Response Slot Delay, a series of time slots are reserved within the same

subevent for receiving responses from Observer devices. Responses to AUX_SYNC_SUBEVENT_IND

PDUs are sent in AUX_SYNC_SUBEVENT_RSP PDUs. The Host configures the number of response

slots required by the HCI command HCI_LE_Set_Periodic_Advertising_Parameters. Figure 6

illustrates the structure of a PAwR subevent.

Channel Selection

Channel selection is accomplished using Channel Selection Algorithm #2, and takes place at each

periodic advertising subevent. Responses to PDUs transmitted in a subevent use the same channel.

This includes AUX_SYNC_SUBEVENT_RSP PDUs sent in response to a AUX_SYNC_SUBEVENT_IND

PDU and AUX_CONNECT_RSP PDUs which are sent in response to AUX_CONNECT_REQ PDUs.

Synchronizing

The process of synchronizing provides the Observer device with the information it needs to efficiently

scan for and receive relevant packets transmitted by the advertising device. In the case of PAwR,

there are three aspects to this:

The Observer needs to know how often periodic advertising with responses events will occur

and when the next such event will occur. This information is provided in a parameter called the

periodic advertising interval and a calculated value known as syncPacketWindowOffset.

The Observer needs information about subevents, including how often they occur and

how many subevents each periodic advertising with responses event accommodates. It also

needs to know certain details relating to the time slots within each subevent reserved for

the transmission of responses. This information is contained within parameters known as

Subevent_Interval, Num_Subevents, Response_Slot_Delay, Response_Slot_Spacing, and

Num_Response_Slots.

Finally, an Observer needs to know which subevent number it should scan for, which

particular response slot it should use, and the access address to use in response

packets transmitted.

Having acquired the event timing information described in (1) and the subevents information in (2),

the Observer has a complete description of the timing parameters and structure of the events and

subevents of the PAwR advertising train. But it is only when it has the information in (3) that it can

schedule its scanning such that it receives only those packets that are expected to contain data of

relevance and can schedule the transmission of response packets.

A) and (2) are dealt with by the PAwR logical transport, as defined in the Bluetooth Core Specification.

There is a choice of two procedures that may be used to obtain this level of synchronization

information. The two procedures are covered in this paper in sections 1.2.3.3.2 Scanning for Periodic

Advertising Synchronization Information and 1.2.3.3.3 Periodic Advertising Sync Transfer (PAST).

B) must be addressed by the application layer and may be defined in an applicable Bluetooth profile

specification. This is covered in section 1.2.3.3.4 Subevent Synchronization and Response

Slot Allocation.

Scanning for Periodic Advertising Synchronization Information

PAwR and PADVB each use a similar procedure for acquiring periodic advertising synchronization

information by scanning. With both PAwR and PADVB, an Observer scans for AUX_ADV_IND packets transmitted on the secondary advertising channels. These PDUs are pointed to by the channel index, offset and PHY information in the AuxPtr field in ADV_EXT_IND PDUs that are transmitted on the primary channels.

AUX_ADV_IND includes the SyncInfo field, which contains the periodic advertising interval value and

some data items from which to calculate a variable called syncPacketWindowOffset. Having acquired

these two values, the Observer can calculate when periodic advertising with responses events will

occur, per (1) in 1.2.3.3.1 General.

PAwR also requires information about subevents and response slots, per (2) in 1.2.3.3.1 General, before it can complete the synchronization procedure. This information is to be found in the same AUX_ ADV_IND PDU from which the periodic advertising interval was obtained but in a new AD type called Periodic Advertising Response Timing Information. The new AD type is transmitted in the Additional Controller Advertising Information (ACAD) field of the AUX_ADV_IND PDU. See below Table.

Periodic Advertising Sync Transfer (PAST)

When using the PAST procedure, sometimes the device passing the synchronization parameters

over the connection will first acquire it by scanning on behalf of the other device. In the case of

PAwR, however, support for PAST is mandatory and so the PAwR Broadcaster can pass the required

synchronization data over an LE ACL connection to the Observer. If this approach is taken, no

scanning for AUX_ADV_IND PDUs is necessary by either device.

The same data items presented in Table 3 are passed over the LE ACL connection in a new PDU type

called LL_PERIODIC_SYNC_WR_IND.

Subevent Synchronization and Response Slot Allocation

Subevent synchronization is concerned with indicating to an Observer device the subevent it should

perform scanning for. One or more Observer devices may be synchronized to the same subevent. An

individual Observer may be synchronized to receive during one or more subevents.

In addition, for an Observer to be able to send a response PDU, it must have some basis for

determining which subevent response slot to use.

Both of these concerns are the responsibility of the application layer. Section 1.2.4 Electronic Shelf

Labels and PAwR explains how the Electronic Shelf Label profile deals with these concerns

by example.

As Table shows, PAwR’s key strengths include the fact that application data communication is bidirectional, flexibility is provided in the choices of topology and receiver concurrency available, and the number of devices that can be communicated with from one Broadcaster is very large (i.e., thousands of devices).

Electronic Shelf Labels and PAwR

Overview of the Electronic Shelf Label Profile

The ESL profile uses both PAwR and connection-oriented interactions to meet its complete set

of requirements. Images, for example, are written to devices over LE ACL connections. But most

commands and responses involve ESL messages transported using PAwR PDUs in subevents.

ESL uses a device addressing scheme which consists of an 8-bit ESL ID and a 7-bit Group ID. The ESL

ID is unique within the group of devices identified by a Group ID. Therefore a network of ESL devices

can include up to 128 groups, each with a maximum of 255 unique ESL devices that are members of

that group. In total, there may be 32,640 ESL devices in a network.

The ESL profile deals with subevent synchronization and response slot allocation as follows:

• The PAwR Broadcaster, known as an Access Point (AP) in the ESL profile specification, configures

electronic shelf label devices by writing to various GATT characteristics over an LE ACL

connection. The data written includes the assignment of an ESL Address consisting of an ESL ID

and a Group ID. Group is an ESL profile concept, but its value is also used to indicate the number of

the subevent during which the ESL device should scan.

• Response slot allocation happens dynamically. ESL devices receive an array of one or more

commands from the AP in PAwR AUX_SYNC_SUBEVENT_IND PDUs. All commands in a request

packet are addressed to the same ESL Group_ID. But each is addressed to a specific ESL in the

group using its ESL_ID5. The index of the command in the array, counting from 1 for the first

command, determines the response slot to be used. So, for example, having executed the 3rd

command in the request PDU’s array, response slot #3 will be used.

ESL and 1:1 Device Communication

As below figure shows the transmission of PDUs that occur when the AP issues a command addressed to a single electronic shelf label. The diagram illustrates how PAwR acts as a transport for ESL commands and responses, as defined by the profile.

The shelf label to which the ESL command is addressed is a member of ESL group 1. This means that

it is synchronized to PAwR subevent #1. The AP, therefore, formulates the ESL Payload, which can

include an array of one or more commands, each addressed to a specific ESL ID within that same

group, and transmits it as the payload of a PAwR AUX_SYNC_SUBEVENT_IND PDU during PAwR

subevent #1.

ESL and 1:m Device Communication

shows the transmission of PDUs that occur when the AP issues a command addressed to

several shelf labels, each of which is a member of ESL group #1. This is followed by transmitting a

single command addressed to a single device that belongs to ESL group #2.

The first ESL request contains three commands. The request targets three shelf labels belonging to

ESL group #0, so it is formatted and set as the payload of an AUX_SYNC_SUBEVENT_IND PDU and

transmitted in PAwR subevent #0.

All ESL shelf labels that are members of group #0 receive the PDU simultaneously since they are all

synchronized on PAwR subevent #0. The ESL command array contains commands addressed to those

shelf labels in the group that have ID #0, #1, and #n. These three devices process their respective

commands. The device with ID #0 responds with an AUX_SYNC_SUBEVENT_RSP PDU in response

slot 0. The device with ID #1 responds with an AUX_SYNC_SUBEVENT_RSP PDU in response slot 1.

Finally, the device with ID #n responds with an AUX_SYNC_SUBEVENT_RSP PDU in response slot

#2 since the command responded to was the third in the ESL command array. Other devices with

different IDs ignore the request.

Conclusion

Bluetooth Core Specification version 5.4 adds a significant new bidirectional connectionless

capability in PAwR and makes it possible to broadcast confidential data in advertising packets

securely. In addition to these considerable enhancements, applications that use GATT can now offer

a better user experience when dealing with attribute security requirements than before, and devices

can exercise control over an important parameter (S) when using the LE Coded PHY for extended

advertising.

Edited by Sales Manager: Mr. Neo Hsu

Raytac Corporation 勁達國際電子股份有限公司  A company of Abietec
Bluetooth & WiFi module maker based on Nordic nRF54, nRF53, nRF52, nRF7002 solution
BT5.4 &BT5.3 & BT5.2 & BT5.1 Qualified, FCC/IC/CE/Telec/KC/RCM/SRRC/NCC Pre-Certified. Bluetooth Solution: nRF54, nRF5340, nRF52840, nRF52833, nRF52832, nRF52820, nRF52811, nRF52810, nRF52805, nRF51822 WiFi Solution: nRF7002
www.raytac.com
email:service@raytac.com
Tel: +886.2.3234.020