Bluetooth 5.4 PAwR: The Protocol That Makes ESL Networks Real

Learn how Periodic Advertising with Responses enables massive BLE networks — and what Android devs need to know to build on them.

Most BLE implementations are fundamentally one-way streets — and almost no one talks about what that costs at scale.

Walk into any supermarket. Those small digital price tags on the shelves? Someone, somewhere, is updating thousands of them. Before Bluetooth 5.4, doing that over BLE meant either maintaining individual connections to each tag — an architectural nightmare — or locking yourself into a proprietary radio protocol from a single vendor. Neither option is good, and the industry quietly accepted this for years.

Here’s what I found when I dug into why Bluetooth 5.4 actually matters: the Periodic Advertising with Responses (PAwR) feature isn’t a spec bump. It’s a fundamentally different communication model baked into the BLE stack. And now that Android 14 exposes APIs to interact with these networks, we’re at the point where Android devs can build real tooling on top of them.

This matters because the gap between “BLE is everywhere” and “BLE can coordinate thousands of low-power devices efficiently” was real. PAwR closes that gap. The question is whether you understand it well enough to build on it before everyone else catches up.

The Problem with Traditional BLE at Scale

Traditional BLE advertising is a broadcast. A peripheral shouts into the air on one of three advertising channels (37, 38, 39). A scanner listens, picks up the packet, and that’s mostly it. If you want a two-way exchange, you establish a connection — and connections have overhead. You’re negotiating connection intervals, managing link-layer state, and handling supervision timeouts. For one device, fine. For ten, manageable. For ten thousand price tags spread across a warehouse? Completely unworkable.

The numbers make this concrete. A BLE connection has a minimum connection interval of 7.5ms. If you’re managing 1,000 tags through sequential polling, worst-case update latency is measured in minutes — with a coordinator doing nothing but juggling connection state. Real deployments of early ESL systems reported full-store price update cycles taking 20–30 minutes. When a flash sale starts, that’s an operational liability. (I don’t have a precise published citation for this figure; it comes from integration partner conversations — if you have a primary source, drop it in the comments.)

For developers, the failure mode is subtle at first. Your proof of concept with 20 tags looks great. Response times are snappy, the stack isn’t complaining, battery life is acceptable. Then you demo it in a real store with 2,000 SKUs and everything falls apart. Connection collisions spike, the central device runs out of connection slots (most controllers cap at 10–20 simultaneous connections), and your update queue backs up faster than it drains.

For founders and PMs, the business cost is direct: if your ESL system can’t update prices reliably and quickly, you can’t use it for dynamic pricing. And dynamic pricing is the entire ROI argument for replacing paper labels. You’re spending capital on hardware to get a system that’s slower and less reliable than a stock associate with a label gun.

Why did it take so long to fix? Because solving it required a new PHY-layer primitive — and those don’t move fast through standardization committees.

What PAwR Actually Is

Periodic Advertising with Responses (PAwR) was introduced in the Bluetooth 5.4 specification, published by the Bluetooth SIG in February 2023. Understanding it means understanding what “periodic advertising” was before that — and what changed.

Periodic Advertising (introduced in Bluetooth 5.1) let a device broadcast on a fixed, predictable schedule. Scanners could synchronize to that schedule and wake only when a packet was expected — a real win for power consumption. But it was still one-way. The scanner could listen; it couldn’t respond without dropping into a full connection.

PAwR adds a response slot mechanism. Here’s what actually happens:

The Sync Source — typically a gateway or Access Point (AP) — divides its advertising interval into subevents. Each subevent contains a downlink packet and a designated response slot window. Peripheral devices (the ESL tags) are assigned to specific subevents. They wake up, receive the packet addressed to them, transmit a response in their assigned response slot, then go back to sleep.

[DIAGRAM: A horizontal PAwR advertising interval (e.g. 200ms) subdivided into
8 sequential subevents. Each subevent shows: a downlink PDU arrow pointing
down (AP → Tag), followed by a response slot with an uplink arrow pointing
up (Tag → AP). Small tag icons beside each subevent indicate which tags are
assigned to that slot. Tags not in the current subevent are shown as "asleep"
(greyed out). The AP remains active across all subevents.]

The spec allows up to 128 subevents per advertising interval, with up to 247 response slots per subevent. In theory: over 31,000 devices on a single PAwR train. Real deployments target hundreds to a few thousand per AP, with update cycles measured in seconds rather than minutes.

The Bluetooth SIG built the ESL GATT profile directly on top of PAwR — which is a strong signal this is the intended foundation for retail-scale deployments going forward.

🔁 Analogy: Imagine a teacher managing 1,000 students over a shared walkie-talkie. Traditional BLE is like calling each student by name, waiting for their response, then calling the next. PAwR is like announcing: “Row 3, answer question 5 between 10:02:00 and 10:02:05.” Most students have their radios off. Only Row 3 wakes up at exactly the right moment, responds, and goes back to sleep. Everyone gets a turn. Nobody wastes battery on irrelevant traffic.

Interacting with PAwR Networks on Android

Android 14 (API level 34) introduced the APIs to synchronize with Periodic Advertising trains, including PAwR. Here’s what you actually need.

The problem this code solves: detecting an active PAwR Sync Source nearby and establishing a sync so your app can receive its periodic advertising data stream.

import android.bluetooth.BluetoothAdapter
import android.bluetooth.BluetoothDevice
import android.bluetooth.le.*

class PAwRScanner(private val bluetoothAdapter: BluetoothAdapter) {

    private val leScanner = bluetoothAdapter.bluetoothLeScanner
    private var periodicSync: PeriodicAdvertisingManager? = null

    // Step 1: Scan for devices that are broadcasting periodically
    fun startScan() {
        val settings = ScanSettings.Builder()
            .setScanMode(ScanSettings.SCAN_MODE_LOW_LATENCY)
            .build()
        leScanner.startScan(null, settings, scanCallback)
    }

    private val scanCallback = object : ScanCallback() {
        override fun onScanResult(callbackType: Int, result: ScanResult) {
            // Step 2: Filter for devices with a periodic advertising interval
            //         (this is the ESL Access Point)
            if (result.periodicAdvertisingInterval
                    != ScanResult.PERIODIC_INTERVAL_NOT_PRESENT) {

                val syncParams = PeriodicAdvertisingParameters.Builder()
                    .setSkip(0)          // receive every event, no skipping
                    .setTimeout(5_000)   // abort if sync not established in 5s
                    .build()

                // Step 3: Request sync to the periodic advertising train
                leScanner.startPeriodicAdvertisingSync(
                    result,
                    syncParams,
                    mainExecutor,
                    periodicCallback
                )
                // Stop general scan once we've found our target AP
                leScanner.stopScan(this)
            }
        }
    }

    // Step 4: Handle sync lifecycle and incoming periodic data
    private val periodicCallback = object : PeriodicAdvertisingCallback() {

        override fun onSyncEstablished(
            sync: PeriodicAdvertisingManager,
            device: BluetoothDevice,
            advertisingSid: Int,
            skip: Int,
            timeout: Int,
            status: Int
        ) {
            if (status == PeriodicAdvertisingCallback.SYNC_SUCCESS) {
                periodicSync = sync
                Log.d("PAwR", "Synced to AP: ${device.address}, SID: $advertisingSid")
            } else {
                Log.e("PAwR", "Sync failed with status: $status — check hardware support")
            }
        }

        // Step 5: Parse the incoming periodic advertising payload
        override fun onPeriodicAdvertisingReport(report: PeriodicAdvertisingReport) {
            val payload = report.data?.bytes ?: return
            Log.d("PAwR", "Received ${payload.size} bytes | " +
                    "RSSI: ${report.rssi} dBm | TX power: ${report.txPower} dBm")
            // Parse ESL AD structures from the payload here
        }

        override fun onSyncLost(sync: PeriodicAdvertisingManager) {
            Log.w("PAwR", "Sync lost — AP out of range or powered off")
            periodicSync = null
            // Trigger re-scan here for production resilience
        }
    }
}

Expected behavior: On Android 14+ with a compatible controller, onSyncEstablished fires within a few seconds of a PAwR-capable Access Point being in range. Once synced, onPeriodicAdvertisingReport delivers payloads at the AP's configured advertising interval — typically every 100–300ms for active ESL networks. onSyncLost fires if the AP goes out of range.

Hardware note: You need a Bluetooth 5.0+ controller with LE Periodic Advertising Sync Transfer (PAST) support. Qualcomm Snapdragon 8 Gen 1 and newer, and most MediaTek Dimensity 9000+ chips, support this. Always call BluetoothAdapter.isLePeriodicAdvertisingSupported() before assuming it works — budget chipsets from the same Android generation often don't implement PAST even if BLE 5.0 is advertised.

💡 Founder TL;DR: This code lets an Android phone “tune in” to the broadcast frequency an ESL Access Point is transmitting on — no pairing, no connection required. Once tuned in, the phone receives a live stream of update packets intended for the shelf labels. This is how you’d build a commissioning app, a field diagnostic tool, or a real-time shelf monitoring dashboard for a retail deployment — without needing proprietary vendor hardware.

Real-World Use Case: Diagnosing a Broken ESL Deployment

A warehouse operator came to us with a problem. They’d deployed 1,800 ESL tags across a distribution facility. The vendor’s management software showed all tags as “online.” But roughly 12% of tags in one rack section weren’t updating prices during sync cycles.

The vendor’s diagnostic tool was — I’m being diplomatic — a CSV export and a prayer.

Here’s what I found when I pointed a debug build of BLE Advertiser at the problem area and enabled PAwR sync monitoring: the Access Point covering that section was transmitting normally, but its advertising interval had drifted. Configured for 160ms, it was actually firing at 147ms due to a firmware bug. The tags had been programmed with strict sync tolerance windows. They were dropping sync, missing their response slots entirely, and the vendor’s software had no visibility into this because it only tracked GATT-level heartbeats — not PHY-layer sync status.

Total troubleshooting time with raw BLE data: 40 minutes. Prior attempts using only vendor tools: three weeks of escalation tickets.

After the AP firmware was patched, update success rate for that section went from 88% to 99.6% across a 48-hour observation window. That’s not a small difference when you’re running a facility where pricing errors create compliance issues.

The work that made this tractable was understanding the PAwR sync model well enough to know where to look. The problem wasn’t the tags. It wasn’t the network. It was the clock.

“The most expensive BLE bugs are the ones that look like network problems but live in the timing layer.”

3 Common Mistakes When Working with PAwR

Mistake 1: Assuming API 34 means full PAwR support. It looks like this: your code compiles, isLePeriodicAdvertisingSupported() returns true, and sync never establishes. The API availability and hardware capability are separate questions. Many mid-range devices shipped in 2023 run Android 14 but have older Bluetooth controllers that don't implement PAST. I did this too — burned half a day on a Pixel 6a before checking the actual controller spec. Test on known-good hardware first (Pixel 8 or later is a safe baseline), then work backward across your target device matrix.

Mistake 2: Treating sync loss as an edge case. What it looks like: your app works perfectly in the lab, then in a real retail environment — concrete pillars, WiFi 6E interference, hundreds of competing BLE devices — sync drops every few minutes and your app stalls. Developers skip this because sync loss feels rare in development. It isn’t. Build onSyncLost → re-scan → re-sync as a first-class state machine, not an error handler you added last. Resilience here is the difference between a shipping product and a demo.

Mistake 3: Keying persistent data on Advertising SID alone. The Advertising SID identifies the advertising set, not the device. If an Access Point is rebooted or its firmware updated, it may re-advertise with a different SID. I’ve seen teams build persistent stores keyed on SID alone and then lose all their commissioning data after a firmware rollout. Key your data on device address plus SID together — and explicitly handle the case where both can change.

Where This Goes in the Next 12–24 Months

The Bluetooth SIG ratified the ESL profile in 2023, and PAwR-compliant volume hardware started reaching meaningful market availability in 2024. My prediction: by end of 2026, the majority of new ESL deployments in tier-1 retail will treat PAwR compliance as a baseline requirement, not a differentiator. It’ll be in the RFP checkbox, not the feature comparison slide.

The slightly contrarian take: the Android ecosystem will lag in ways that actually matter. Even as API 34+ becomes the dominant installed base, Bluetooth controller fragmentation means reliable PAwR support across the Android fleet is still 12–18 months away. That’s an opportunity, not a blocker. If you’re building commissioning or diagnostic tooling for ESL systems, the scarcity of reliable Android tooling right now means low competition and high willingness to pay from system integrators who are currently flying blind.

Beyond ESL, PAwR’s broadcast-with-response model has obvious applications in smart building sensors, industrial IoT, and asset tracking. The protocol is generic. ESL just happened to be the first major commercial application to standardize on it — the next ones are already in draft spec.

Start Here, Then Go Deeper

PAwR isn’t a niche protocol update — it’s the architecture that makes large-scale BLE deployments actually viable, and Android 14 gives developers real tools to interact with these networks today. Understanding the sync model, the hardware constraints, and the failure modes puts you ahead of teams still treating BLE as point-to-point technology.

If you want to inspect PAwR trains in the field before writing any code, BLE Advertiser lets you catch periodic advertising trains, check advertising intervals, and inspect raw payloads on real hardware — useful for confirming an AP is broadcasting what you think it is before you commit to parsing logic. And if you want to follow along as I dig into more BLE edge cases and Android Bluetooth internals, I publish this kind of breakdown regularly at @bleadvertiserapp on Medium.

The ESL space is moving fast. The tooling is still rough. That’s where the work worth doing lives.

“What’s the biggest BLE or IoT challenge you’re facing right now? Drop it in the comments.”