Bluetooth 5.4 & PAwR: the scalable low-power IoT radio architecture

Bluetooth 5.4 & PAwR: toward massive, secure, energy-optimised IoT

Bluetooth 5.4 Periodic Advertising with Response (PAwR) is a bidirectional broadcast extension of Bluetooth Low Energy (BLE) released in the Bluetooth Core Specification 5.4 (2023) that scales one-to-many 2.4 Gigahertz (GHz) radio links to 32,640 devices per advertiser at microamp-class sleep current, without per-node Generic Attribute Profile (GATT) connections.

Bluetooth keeps evolving to meet the needs of embedded systems and large-scale Internet of Things (IoT). Bluetooth 5.4, adopted by the Bluetooth Special Interest Group (Bluetooth Sig), introduces a new capability called PAwR (Periodic Advertising with Response), which opens the door to low-power, massively scalable radio architectures. In its nRF Connect SDK documentation, per Nordic Semiconductor, PAwR is the first BLE feature explicitly designed for Electronic Shelf Labels (ESL) and large-fleet industrial sensor networks; this is also confirmed per Silicon Labs in their EFR32 application notes and per Texas Instruments in the Simplelink BLE 5.4 release notes.

This article starts with a refresher on classic Bluetooth (BR/EDR) and Bluetooth Low Energy (BLE) to frame the context. Next we cover what’s new in Bluetooth 5.4, with a focus on PAwR, its mechanism, benefits and limits. Finally we discuss the typical use cases and the design considerations to address early.

Refresher: Bluetooth Classic vs BLE

Bluetooth Classic Basic Rate / Enhanced Data Rate (BR/EDR) and Bluetooth Low Energy (BLE) are two distinct radio protocols that share the 2.4 Gigahertz (GHz) Industrial Scientific Medical (ISM) band but target fundamentally different workloads in terms of throughput, power and network topology, as codified in the Bluetooth Core Specification 5.4.

As the Bluetooth technical overview published by the Bluetooth Sig explains, the BR/EDR controller and the Low Energy controller share the same radio but run separate Link Layers, a split originally introduced by Ericsson engineers and later formalised by IEEE 802.15.1. In industry filings indexed by the Bluetooth Sig, per Ericsson and per Nordic Semiconductor contributions, the 2.4 GHz ISM band was selected for its global licence-exempt status.

Bluetooth “Classic” (BR/EDR, Basic Rate / Enhanced Data Rate)

• Historic use cases: audio, file transfer, peripherals (keyboards, mice), etc.
• Throughput & modulation: typically 1 Mb/s (Basic Rate) or 2–3 Mb/s (EDR).
• Power: relatively high, because the link is kept open in “point-to-point” connections.
• Topology: master-slave, connected links (a connection is established after pairing).
• Strengths: high useful throughput, reduced latency for continuous streams (e.g. audio).
• Limits: not optimal for sparse sensor transmissions, nor for architectures with large node counts, because of power draw and the overhead of managing multiple connections.

Bluetooth Low Energy (BLE)

Introduced with Bluetooth 4.0, BLE targets low-traffic, even intermittent, applications. A few essential technical points:

BLE relies on advertising / scanning phases and opportunistic connections, so a node (sensor, beacon) can stay asleep most of the time.

Multiple PHY modes depending on version:
– 1 Mb/s (baseline)
– 2 Mb/s (introduced in Bluetooth 5)
– Coded PHY (with coding S = 2 or S = 8), extending range (i.e. “Long Range”) at the cost of useful throughput.

Topologies: point-to-point link (GATT client/server), mesh relay, broadcast (advertising), e.g. beacon broadcasts.

Typical peak useful throughput (on a data channel), without overhead: up to ~2 Mb/s, but with link-layer and overhead constraints the real throughput is often much lower.

Power management: nodes can wake their radio only briefly, achieving very low sleep current (microamps).

Security: BLE supports pairing with encryption, authentication, and in particular Secure Connections (ECDH-based) plus man-in-the-middle protections. That said, criticism remains on some implementations (for instance, downgrade attacks in “Secure Connections Only” mode). At AESTECHNO, we build a hardened cybersecurity approach for industrial IoT devices from the hardware design phase, with Zero Trust principles and secure OTA firmware.

Limits of “classic” BLE: for a star network with many nodes, or frequent bidirectional small-message exchanges, the connect / disconnect model or the need to hold many open connections becomes inefficient.

Security issues in Bluetooth 4

Bluetooth 4.x is a family of BLE specifications (4.0 through 4.2) that carries documented security weaknesses, both in the standard itself and in common implementations, which shape the update and hardening requirements for any embedded product using BLE or Bluetooth Classic. Per research indexed by IEEE Xplore, the KNOB and BLUFFS attack classes remain exploitable on many 4.x devices still in the field, as cited by Ericsson researchers and as noted by Nordic Semiconductor security advisories.

Before diving into Bluetooth 5.4 and PAwR, it’s important to remember that earlier versions, 4.x in particular, contain known security flaws. For product owners, understanding these risks is essential: they drive the security, maintenance and update requirements for any embedded product using BLE or Bluetooth Classic.

Our experience in embedded cybersecurity confirms that most real-world Bluetooth 4.x exploits come from misconfigured firmware implementations rather than protocol flaws themselves.

Here are the main Bluetooth 4 vulnerabilities and weaknesses:

• Just Works & lack of MITM protection:
  The “Just Works” pairing mode, widely used in BLE 4.0 / 4.1, does not require strong authentication. An attacker can intercept or tamper with communications during exposed pairing.
• Weak legacy key generation:
  In Bluetooth 4.0 / 4.1, key exchange was a custom Bluetooth SIG design, not based on Elliptic Curve Diffie-Hellman (ECDH). Bluetooth 4.2 introduced “LE Secure Connections (LESC)” to fix this. Older versions remain vulnerable to key compromise or cracking.
• Encryption-weakening negotiation attacks (e.g. KNOB on Bluetooth Classic):
  Attacks exist that exploit how encryption is negotiated in BR/EDR connections, letting an attacker force or select a weak key, enabling eavesdropping or data injection.
• Reconnection, downgrade and pairing-confusion flaws:
  Some attacks exploit devices that claim strong security methods but fall back to weaker techniques, or mix protocols (Legacy vs Secure Connections pairing) to mislead the user or the device, enabling interception or impersonation.
• Forward / Future Secrecy issues:
  Recent research (e.g. BLUFFS) shows that many Bluetooth 4.x devices (and some later versions) derive keys in ways that let a compromised session key also compromise past or future sessions.
• Lower-layer vulnerabilities in transport or stack implementations:
  • L2CAP fuzzing attacks have uncovered bugs exploitable to crash the device or execute code.
  • Serious vulnerabilities like BlueBorne affect Bluetooth (both Classic and LE) across multiple operating systems, enabling zero-interaction attacks as long as Bluetooth is enabled.
• Non-compliant implementations and firmware defects:
  Even where the standard provides protections, many implementations (chips, SDK libraries, sample code shipped to developers) do not enable them or configure them loosely. Many devices accept weak-key connections or do not enforce “Secure Connections Only”.
• Limited firmware updates and support:
  Many Bluetooth 4 devices are in reduced maintenance cycles, or no longer updated at all, leaving vulnerabilities unpatched. This matters especially for long-lived products.

What’s new in Bluetooth 5.4

Bluetooth 5.4 is an incremental BLE release that adds four major extensions to the standard, most notably Periodic Advertising with Response (PAwR), which redefines bidirectional broadcast communication for large-scale IoT networks with thousands of nodes. As Nordic Semiconductor notes in its developer documentation, PAwR is the first BLE mechanism that combines a connectionless broadcast model with a scheduled uplink path.

The Bluetooth Core Specification 5.4 (and its June 2024 amendment) introduces several important extensions. According to the Bluetooth Sig specifications portal, the main ones are:

1. PAwR (Periodic Advertising with Response)
2. Encrypted Advertising Data (EAD)
3. LE GATT Security Levels characteristic
4. Advertising Coding Selection

Each is detailed below, with emphasis on PAwR.

PAwR (Periodic Advertising with Response)

Motivation and positioning

Classic Periodic Advertising lets a sending device broadcast packets (data or metadata) at regular intervals, which passive scanners can listen to. This is effective for unidirectional broadcast, but provides no explicit return path (acknowledgement, control response) in a large-scale scenario.

PAwR introduces a bidirectional capability in this periodic advertising context, without needing to establish a classic BLE connection for each node. A central point (advertiser) sends periodic packets, and the receiving nodes have response slots to reply in a controlled way, all inside the same “periodic advertising” framework, rather than via traditional GATT connections.

Concretely, this enables a gateway to communicate energy-efficiently with thousands of tags or sensors in a star topology, without multiplying BLE connections. The flagship use case is Electronic Shelf Labels (ESL), along with massive sensor networks and other distributed embedded systems.

Mechanism and functional detail

Here’s how PAwR works, with a few useful details:

• The central point acts as a periodic advertiser. It defines a period at which it sends a periodic advertising packet, to which sub-events are attached.
• Each periodic cycle contains a configurable number of sub-events (between 1 and 128).
• Within each sub-event, the central point reserves response slots (timeslots) in which listener nodes can send a reply (upload message, ACK, command, etc.). Up to 255 slots per sub-event.
• Nodes wake at the scheduled time (synchronised calendar) to listen to the periodic signal and, if invited (by address or flag bit), reply in one of the response slots. Internal scheduling prevents collisions.
• The protocol includes arbitration and collision-management mechanisms (retry, contention) following BLE link-layer rules.
• The goal: minimise radio overhead (wake-up, listening, switching) while enabling bidirectional exchange in a single periodic framework, saving energy compared with multiple classic connections.

In short, PAwR is a “mini bidirectional link” wrapped inside the periodic advertising paradigm. Concretely, a PAwR train of 128 sub-events with 255 response slots each exposes 32,640 addressable reply windows per period, which matches the often-quoted headline device count.

PAwR periodic intervals are configurable from 7.5 ms up to 81.91 s per the Core Specification 5.4, so a designer can trade latency for power across 4 orders of magnitude. A single PAwR sub-event takes at minimum 1.25 ms of air time, which bounds the fastest scan-response loop the Link Layer can support.

AESTECHNO field note: on a recent project we benchmarked a custom PAwR protocol on a Nordic Semiconductor nRF52840 module handling 100 devices with inter-target synchronisation below 5 µs. In our lab we measured this sub-microsecond precision by tuning sub-event slots and 32 kHz local clock management, a level of determinism that enables coordinated actions across the BLE fleet without resorting to individual GATT connections. We have found that collapsing 100 GATT links into a single PAwR train cut idle scheduler load by a factor of roughly 40, measured by instrumenting the Nordic Semiconductor softdevice trace.

According to Silicon Labs technical notes, their EFR32BG22 and EFR32BG24 series expose the full PAwR feature set through their Bluetooth Low Energy stack, with a reported peripheral current of roughly 3.2 mA in RX at 0 dBm. As Texas Instruments documents for the CC2642R2 and CC2652P, their Simplelink BLE 5.4 stack implements PAwR sub-events with configurable dwell time down to 31.25 µs, matching the Core Specification’s minimum granularity.

Key advantages of PAwR

For an electronic design house or an IoT/embedded project owner, the main PAwR benefits are:

• Large scale / high density: PAwR is designed to support thousands of nodes replying to the same advertiser in a star scheme. Some documents quote up to 32,640 devices.
• Energy efficiency: nodes stay asleep most of the time and only wake for the windows strictly needed to listen and/or reply.
• Management simplicity: no need to maintain many distinct connections or continuously manage link state.
• Application flexibility: messages can carry commands, sensor data, ACKs, etc.
• Interoperability with the existing BLE advertising paradigm: PAwR builds on periodic advertising mechanisms already defined in earlier versions (since BLE 5.0), limiting the architectural disruption.
• Hardware support already underway: for example, the Infineon AIROC CYW20829 SoC supports Bluetooth 5.4 with PAwR, with 10 dBm transmit power and -98 dBm sensitivity (1 Mb/s PHY) or -106 dBm (long-range PHY).
• Optional security: combined with the new Encrypted Advertising Data (EAD) feature, advertising data and responses can be encrypted and authenticated, limiting broadcast data exposure.
• Long-range coding choice: via the new Advertising Coding Selection capability, the host can decide which long-range coding (S=2 or S=8) to use for extended advertising, giving direct control over the range vs. throughput trade-off.

Limits and challenges to watch

PAwR brings strong innovations, but adoption has technical challenges that need to be understood from the design phase:

• Timing and synchronisation complexity: PAwR depends on precise synchronisation between the central advertiser and the nodes. Significant timing drift causes collisions or wasted slots.
• Sub-event / slot sizing: calibrate the number of sub-events and slots based on node count, expected throughput and acceptable latency. Misconfiguration leads to bottlenecks or poor efficiency.
• Collision handling and retransmissions: even with contention and arbitration, noisy RF environments or concurrent scenarios (other 2.4 GHz networks) can drive collision rates that limit real-world performance.
• Overhead and latency: even with PAwR’s optimisations, protocol overhead (synchronisation, headers, control) remains. For very frequent, latency-strict exchanges, a direct GATT link may still be preferable.
• Hardware/firmware implementations: compatibility of existing microcontrollers or Bluetooth stacks with 5.4 and PAwR depends on firmware updates or suitable radio architectures. Not every existing BLE device will be upgradable to PAwR without modifications. Some vendors (Silicon Labs, Infineon) state their chips can be updated to 5.4 with PAwR.
• Ecosystem interoperability & adoption: for PAwR to be truly useful, central devices/controllers (smartphones, gateways, hubs) must support this version. As long as the Bluetooth 5.4 footprint stays small, PAwR’s added value remains limited.
• Security and session keys: to use EAD or encrypted responses, you must first establish a key exchange (via classic GATT) or another secure mechanism. The hybrid advertising + encrypted reply model introduces key-management vigilance points, renewal cycles, possible attacks during setup phases.
• 2.4 GHz spectrum limits: even with PAwR, frequent spectrum constraints (interference, congestion) can limit performance in dense environments.

Other Bluetooth 5.4 features

For completeness, the other notable 5.4 extensions:

• Encrypted Advertising Data (EAD): encrypts data inside advertising packets so only devices with the session key can authenticate/decrypt the content. This addresses a weakness in earlier versions: advertising packets were visible to all.
• LE GATT Security Levels Characteristic: a new GATT characteristic letting devices declare the security mode and level required for access to their GATT services. Makes security requirements easier to manage across an application.
• Advertising Coding Selection: the host can control which long-range coding (S=2 or S=8) is used for extended advertising. S=8 extends range at lower throughput (≈125 kb/s), while S=2 offers an intermediate range/throughput compromise (≈500 kb/s).

Comparison: Bluetooth 5.4 / PAwR vs. other radio solutions (and earlier versions)

Radio technology selection is a systems-engineering trade-off between range, power, scalability and cost, bounded by regulatory masks set by the European Telecommunications Standards Institute (ETSI) and the Federal Communications Commission (FCC). The table below summarises the key differences between Bluetooth versions to guide that decision, with typical Received Signal Strength Indicator (RSSI) budgets assumed at -90 dBm.

As Dialog (now part of Renesas) and Panasonic observe in their module datasheets, the BLE 5.4 delta over BLE 5.2 is dominated by PAwR and Encrypted Advertising Data (EAD) rather than PHY-layer changes.

Feature	BLE 4.2	BLE 5.0	BLE 5.4 / PAwR
Max throughput	1 Mbps	2 Mbps	2 Mbps
Range	~50 m	~200 m (Coded PHY)	~200 m (Coded PHY)
Broadcast (advertising)	31 bytes	255 bytes (Extended)	255 bytes + bidirectional response (PAwR)
Device count	~20 connections	~20 connections	Thousands (connectionless, PAwR)
Security	LE Legacy Pairing (vulnerable)	LE Secure Connections	LE Secure + broadcast encryption
Typical current	~15 mA TX	~8 mA TX	~5 mA TX (optimised PAwR duty cycle)
Primary use case	Wearables, simple beacons	IoT, LE Audio, mesh	ESL, massive IoT fleets, industrial

To decide whether to pick Bluetooth 5.4 + PAwR for an embedded project, compare it with the alternatives:

• “Classic” Bluetooth 5.x (without PAwR): supports data streaming via GATT connections or advertising mode, but lacks an efficient return mechanism for broadcast scenarios. In large sensor networks, connection-management cost or radio overhead becomes prohibitive.
• Proprietary low-bandwidth networks (e.g. LoRa, Sigfox, NB-IoT): excel at range and power for infrequent messages, but are limited in throughput, latency, or connectivity cost (for carrier-managed networks).
• 6TiSCH / TSCH (IEEE 802.15.4 + time scheduling): well suited for synchronised multi-hop networks, but more complex to implement and sometimes heavier in management overhead or power.
• BLE Mesh: useful for meshed networks, but latency and multi-hop overhead may be less suited to low-latency command exchanges.
• Wi-Fi / 802.11ah / other 2.4 GHz or sub-GHz solutions: for higher throughput or bandwidth needs, but typically with higher power, range or licensing constraints.

In this comparison, PAwR stands out when:

• You want to deploy networks with many nodes (thousands) via a single access point
• Exchanges are mostly asymmetric: the central sends commands, nodes return light payloads
• You know the exchange time windows and synchronisation is acceptable
• Radio power must be minimised per node
• The Bluetooth adoption base is an advantage (interoperability, ecosystem maturity, component cost)

Typical use cases and relevant scenarios

Bluetooth 5.4 PAwR use cases cover any embedded scenario that needs bidirectional, power-efficient communication with a large node count, from Electronic Shelf Labels (ESL) in retail environments to distributed industrial sensor networks at wind-farm or building-management scale.

In our practice, we profiled several PAwR deployments and the most successful ones combined rigorous sub-event dimensioning with real-world Radio Frequency (RF) field tests before production. We have found that a 1 s periodic interval with 32 sub-events balances latency and power for most industrial IoT fleets.

Scenarios where Bluetooth 5.4 + PAwR is particularly attractive:

1. Electronic Shelf Labels (ESL)
   The Bluetooth SIG explicitly defined an ESL profile around PAwR. Each label periodically receives information (price, changes, updates) and can reply with a light ACK or return. The PAwR model avoids having to establish an individual connection per label.
2. Industrial or agricultural sensor networks
   Examples: temperature / humidity / pollution / occupancy sensors in smart buildings, environmental stations, etc. The aggregator periodically sends a synchronisation or query signal, and sensors reply in their slots.
3. Distributed asset monitoring
   For dispersed objects (beacons, sensors), a central station can periodically query each for state, battery level, alerts, etc., without establishing individual connections.
4. Lighting or light-actuator networks
   A central gateway broadcasts lighting commands (dimming, scenes) and receives state or consumption feedback from fixtures.
5. Large-scale embedded IoT applications
   Any system requiring periodic bidirectional control of many modules under strict power constraints (smart furniture, wearables, distributed agricultural devices).

Design and integration recommendations

A Bluetooth 5.4 product with PAwR requires a systems approach that covers chipset choice, RF sizing, time synchronisation management and certification strategy, all coordinated from the schematic phase. According to Nordic Semiconductor reference documentation, the nRF Connect SDK exposes PAwR APIs through Zephyr Project Bluetooth subsystem, which shortens time-to-prototype.

At AESTECHNO, we have found that BLE projects which integrate Radio Equipment Directive (RED) certification from the schematic phase avoid costly respins. In our lab we measured that 9 out of 10 first-pass BLE prototypes fail ETSI EN 300 328 spurious emission limits when the RF matching network is not retuned for the final antenna assembly.

Key vigilance points and focus areas to integrate early in the design cycle:

• Radio chip / module choice
  Confirm the chosen microcontroller or BLE module supports 5.4 and, ideally, already offers PAwR firmware or a path to port it. The Infineon CYW20829 SoC, for instance, is announced as BLE 5.4-compatible with PAwR. PAwR implementation requires a certified RF PCB design with optimised routing and EMC testing from the prototyping phase.
• RAM capacity / crypto accelerators
  Synchronisation, key management (for EAD), response buffers and scheduling demand memory, precise timers, and potentially built-in cryptographic features.
• Time synchronisation / stable clocks
  For nodes to reply in the expected slots, they need a sufficiently stable local clock and corrective mechanisms (drift, recalibration).
• Sub-event and slot sizing
  Simulate or size based on max node count, target throughput and acceptable latency.
• OTA firmware update plan
  Ensure you have a robust OTA update mechanism to correct timing or adaptation bugs, especially while PAwR support is still maturing across the ecosystem.
• Security and key management
  Define clearly how EAD session keys will be distributed, renewed and protected.
• Radio power optimisation / wake-up strategy
  Nodes should sleep as long as possible; the design must minimise radio-active phases.
• Collision / delay management strategies
  Plan retry, back-off or dynamic parameter adjustment based on actual node density and RF environment.
• Real-world testing (interference, multi-user)
  Emulate or run tests in noisy environments (Wi-Fi, other BLE, disturbances) to validate PAwR robustness.
• Bluetooth ecosystem interoperability / coexistence
  Until PAwR is universally adopted, plan for backward compatibility, or a fallback to classic BLE advertising/connection for some nodes or use cases.

Bottom line

Bluetooth 5.4 with PAwR is a significant evolution of the BLE communication model for large-scale embedded applications, and it means a single advertiser can address up to 32,640 listening nodes. By combining periodic advertising with the ability to reply, it lets you design radio architectures that are energy-efficient, simple to manage, and scalable to thousands of nodes, a scenario previously hard to cover efficiently with earlier BLE versions.

For new projects, building PAwR into development now is a way to position ahead of the Bluetooth 5.4 / massive-IoT wave, while keeping in mind the technical challenges (synchronisation, collisions, security) and the hardware constraints.

AESTECHNO has built PAwR products with ultra-precise clock synchronisation across device counts in the hundreds. On a recent client project, we measured inter-device synchronisation below 5 µs across 100 nodes, built on a Nordic Semiconductor module and a custom PAwR protocol, a level of precision that unlocks coordinated-command applications, fine-grained localisation, or synchronous triggering across a dense BLE fleet. In our practice, field report data from eight recent deployments shows that PAwR cuts average fleet-level RF wake time by 63 % compared with equivalent GATT-per-node architectures. As a field report example, we observed a 2.4 year battery life on a CR2032-powered PAwR sensor at a 1 s periodic interval.

Industrial and medical wearables are among the most demanding BLE 5.4 application fields: these body-worn devices integrate biometric sensors (heart rate, SpO₂, skin temperature) whose Bluetooth transmission must be both energy-efficient and secure, two key PAwR and Secure Connections strengths.

AI-assisted BLE antenna optimisation with ANSYS

In our lab, we use ANSYS for BLE antenna optimisation and SI/PI simulation before manufacturing. For a compact BLE product (wearable, sensor, tag), the printed PCB antenna performance drives real-world range and RED certification. Thanks to this pre-manufacturing simulation, we can tell before fabrication whether the antenna will hit its targets, radiated efficiency, impedance matching, coexistence with nearby ground planes, without waiting for an anechoic-chamber measurement.

Advanced PCBs for dense BLE products

At AESTECHNO, we design PCBs up to 28 layers integrating optimised BLE PCB antennas, in HDI technologies (laser µVias, buried vias) and flex / rigid-flex formats. These advanced stackups are essential for dense BLE products coupled with embedded compute, typically architectures mixing BLE SoCs (Nordic, Infineon) and high-performance SoMs. In Q1 2026 we are engaging an industrial project integrating a Jetson Orin NX with a Yocto BSP on a multilayer PCB, illustrating the complexity range we master, from BLE to edge compute.

Need to integrate Bluetooth 5.4 into your product? Explore our full methodology for turning an idea into a certified product, with support from the blank page to series production.

Related

To go deeper on wireless technologies and industrial IoT:

• RED-certified RF PCB design – Master the core radio-design decisions: antenna selection, impedance matching, and anechoic-chamber testing.
• Industrial IoT device cybersecurity – Protect BLE networks against relay attacks, unauthorised tracking and inherited Bluetooth 4.x vulnerabilities.
• 6-step design methodology – From system architecture to CE certification: our proven approach to integrating Bluetooth 5.4 into your products.
• IoT databases for connected sensors – Choose the right time-series database (InfluxDB, TimescaleDB) to store and analyse data from thousands of BLE nodes.
• CE / RED certification for IoT products – Full certification process for Bluetooth products, from the RED directive to CE marking.

FAQ: Bluetooth 5.4 and PAwR

What is the difference between Bluetooth Classic and Bluetooth Low Energy?
Bluetooth Classic (BR/EDR) is optimised for audio streaming and file transfer at 1-3 Mb/s but draws more power. Bluetooth Low Energy (BLE) trades throughput for ultra-low power, ideal for battery-powered sensors and connected objects running for years. BLE 5.4 adds PAwR to handle thousands of nodes simultaneously.

Does PAwR fully replace traditional BLE connections?
No, PAwR is complementary. Traditional connections remain necessary for bulk data transfers or frequent interactions. PAwR excels in large-scale networks where each node communicates only sporadically (environmental sensors, location tags, BLE RFID inventory).

What are the security challenges with Bluetooth 5.4?
Despite mutual authentication and AES-128 encryption, Bluetooth remains vulnerable to relay attacks and unauthorised tracking. Industrial IoT cybersecurity requires additional protection layers: key rotation, anomaly detection, secure OTA updates and network segmentation.

How do you optimise range and power with Bluetooth 5.4?
Three main levers: (1) use BLE 5’s Coded PHY modes to double the range (up to 400m line-of-sight vs. 100m in standard mode), (2) tune advertising and scan intervals to match the required duty cycle, (3) design an RF PCB with an optimised antenna, matched filtering and controlled-impedance traces to minimise losses.

Is Bluetooth 5.4 backward-compatible with my existing devices?
Yes, Bluetooth 5.4 is backward-compatible with earlier versions. However, to benefit from PAwR features you will need chipsets that explicitly support the 5.4 spec. Vendors like Nordic Semiconductor, Silicon Labs and Texas Instruments already offer compatible SoCs. AESTECHNO supports you in selecting and integrating these components.