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 Sync Info 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.
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 SyncInfo 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 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.
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:
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.
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.
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
No comments:
Post a Comment