BLE Advertising Analysis

Problems such as “I cannot scan the device,” “the name appears only sometimes,” and “my filters seem to do nothing” are often not caused by having too many advertising fields. The real problem is that the observed object was never layered correctly in the first place. The advertising stage is usually where three things get mixed together:

• The over-the-air Advertising PDU (Protocol Data Unit)
• The AD Structure inside AdvData / ScanRspData
• The actual stages of “discoverable,” “connectable,” and “ready for application data”

If those layers are not separated, packet captures, advertising layout, and scan results all get harder to interpret.

This article uses the common engineering context of Bluetooth Core Specification 4.2. It focuses on Legacy Advertising, scan responses, address semantics, scan-side observations, and debugging decisions. It does not cover Extended Advertising, periodic advertising, BLE 5.x PHY combinations, or platform-specific scan APIs.

What Advertising Actually Solves

Advertising is not just “sending a short introduction.” In protocol and debugging terms, it does two more basic things:

• Gives the scanner an entry point for discovery
• Gives the initiator an entry point for connection setup

From an engineering perspective, the advertising stage is the pre-connection entry layer. It answers these questions:

• Is the device currently visible?
• Is it advertising only, or also scannable and connectable?
• Which information must go into the primary advertisement, and which can wait for the scan response?
• Does the address and name the scanner sees really belong to the device you think it does?

The main flow is short:

Advertiser sends ADV_* advertising packets
-> Scanner receives them
-> Optional SCAN_REQ
-> Advertiser optionally returns SCAN_RSP
-> If connection is allowed, Initiator sends CONNECT_REQ
-> Both sides leave advertising state and enter connection state

The key boundaries are:

• Advertising is about being seen and offering a connection entry, not about application traffic
• ADV_IND / SCAN_RSP / CONNECT_REQ are Link Layer PDU types, not application data formats
• Seeing a device name, UUID, or manufacturer data only means the advertising payload was received, not that the link is already established

What Happens on the Air

BLE uses 40 channels:

• 37, 38, 39 are advertising channels
• 0 to 36 are data channels

Advertising only happens on the three advertising channels. That choice has a direct engineering value:

• Scanners only need to listen to a small set of entry channels
• The advertising stage solves discovery first and does not consume full data channels yet
• Once connected, the link can move to data channels for stable exchange

A typical advertising event looks like this:

During one Advertising Event
Advertiser sends the same advertising PDU on 37 / 38 / 39 in order
After the event, it waits for the Advertising Interval
Then the next Advertising Event begins

If a SCAN_REQ or CONNECT_REQ arrives in the middle, the current event can be extended with scan response or connection setup actions, so captures are not always a neat three-packet sequence.

Keep two points in mind:

• Seeing sparse advertising does not necessarily mean the device is broken; the scan window may simply miss it
• Seeing a device name does not mean the peer can connect; check the advertising type first

Advertising Type Determines What Others Can Do

The common Legacy Advertising PDU types are:

Two request/response types usually go with them:

• SCAN_REQ: the scanner asks for more data
• SCAN_RSP: the advertiser returns the extra data

Two common misunderstandings are worth calling out.

First, advertising does not automatically mean connectable:

• ADV_NONCONN_IND is explicitly non-connectable
• ADV_SCAN_IND is scannable but still not connectable
• Only connectable advertising types can lead to CONNECT_REQ

Second, a scan response does not mean connection is close:

• SCAN_RSP only means the advertiser is willing to expose more data
• It is a different action chain from connection establishment
• Being able to answer a scan request does not mean a connection will be accepted

For most devices, starting from ADV_IND is the safest default. Use directed or pure broadcasting modes only when the scenario is clear.

Advertising Data and Advertising Packets Are Not the Same Thing

This layer is often mixed up.

On the air, what gets sent is an Advertising Channel PDU, whose payload may contain:

• AdvA: advertiser address
• TargetA: target address for directed advertising
• AdvData: advertising data
• ScanRspData: scan response data

Inside AdvData / ScanRspData, the format is another layer:

Length | AD Type | AD Data
Length | AD Type | AD Data
...

So at least three layers must be separated:

• ADV_IND / SCAN_RSP are PDU types
• AdvData / ScanRspData are payload areas inside those PDUs
• AD Structure is the field encoding inside the advertising payload

If a tool shows both “PDU Type” and “Complete Local Name,” those are not the same layer. The first is a Link Layer action; the second is just one AD Type inside the payload.

What the 31-Byte Limit Really Means

In Legacy Advertising:

• AdvData can be at most 31 bytes
• ScanRspData can be at most 31 bytes

That limit applies to the advertising payload, not to the whole packet and not to “all information the device can ever expose.” The right design choice is not to stuff everything in, but to prioritize.

A practical split is:

• Put the minimum discovery and filtering information in the primary advertisement
• Put extra and display-oriented information in the scan response

Typical primary-advertisement fields are:

• Flags
• Key service UUIDs
• A short device name
• The minimum manufacturer data needed for scanning filters

Typical scan-response fields are:

• Complete device name
• Extra service data
• TX Power
• Longer manufacturer-specific fields

A conservative rule is:

• If the scanner must rely on a field for first-pass filtering, do not hide it only in ScanRspData
• If a field is mostly for display or extra explanation, move it to the scan response first

Otherwise different platforms will show different results, because some only read primary advertising while others actively scan to fill in the name.

Common AD Types and Their Meaning

The point is not to memorize every AD Type, but to focus on the common high-frequency ones:

A few common mistakes:

• The device name is not always in the primary advertisement; it may be in ScanRspData
• Manufacturer data is not an unlimited free-form packet; it still competes for 31 bytes
• A UUID in advertising only means the device is announcing that service line; it does not mean all attribute access is ready after connection

If you are designing an advertising format, answer these three questions first:

1. What should the scanner know on the first sighting?
2. Which fields are only for display and can be dropped without hurting discovery or connection?
3. Which fields must stay stable across platforms and tools?

Why Addresses Often Confuse Debugging

Many “it worked yesterday but the address changed today” problems are about address semantics, not advertising content.

The first address in the packet is AdvA, but it may not be a permanent device identity. Common address types include:

• Public Device Address
• Random Static Address
• Resolvable Private Address (RPA)
• Non-resolvable Private Address

This directly affects scanning and debugging:

• If the device uses RPA, the address you captured now may be different in ten minutes
• If a tool or script filters by a fixed address, it may think the device disappeared
• If you only remember the name and ignore the address type, you may mix several identical names together

For advertising debugging, always confirm at least these things:

• What address type is in use
• Whether the same device is expected to rotate its address
• Whether the scanner is filtering on a fixed address that cannot survive rotation

What to Check First

Do not start with every field name. Start with the high-value checks:

1. Check whether the advertising type matches the scenario.
2. Check whether the scan-side information is placed in the right area.
3. Check whether the advertising interval and scan timing actually overlap.

More concretely:

• Is it connectable or not?
• Is it scannable or not?
• Is the device meant to be a beacon, a reconnect target, or a normal peripheral?
• Is the name in the primary advertisement or only in the scan response?
• Is the filtering UUID exposed where the scanner can actually see it?
• Is the device using a random address that changes under you?
• Are the advertising interval and scan window overlapping reliably?
• Is the device visible only intermittently because the scan window is too small?
• Is the environment noisy enough that sparse advertising appears missing?

Takeaways

If you want a normal connectable BLE peripheral that phones or gateways can discover and connect to easily, the default shape is usually:

• Use ADV_IND as the advertising type
• Keep the primary advertisement to the minimum set of filterable information
• Put the full name or extended information into the scan response
• Do not force business payloads into the advertising stage

You can think of it as this division of labor:

Primary advertising says “show me first, and tell me whether I am worth connecting to”
Scan response says “if you ask one more time, I will tell you more”
Actual business reads and writes belong in GATT after the connection

The benefits are:

• Advertising is more stable and more compatible
• The 31-byte space is not wasted on nonessential data
• You can filter before connection, but you are not trying to turn advertising into a tiny data bus

If your design needs business data in the advertising stage, such as a beacon or state-broadcast device, you should still first confirm:

• Does this data really not need a connection?
• Are the fields short enough and versionable enough?
• Can the scanner tolerate loss, duplication, and unstable ordering?

What to Check in Captures and Logs

When you debug advertising issues, these are the first things worth confirming:

1. Whether ADV_* advertisements appear consistently
2. Whether the current advertising type allows scanning or connection
3. What AdvData and ScanRspData actually contain
4. Whether the device name, UUID, and manufacturer data are placed in the wrong area
5. Whether the current address type changes
6. Whether the scanner really sent SCAN_REQ
7. If connection fails, whether CONNECT_REQ ever appeared

If you split the symptoms this way, you can map them to the table below:

Boundaries with Related Topics

Advertising only solves discovery and connection entry. The following topics should still be split apart:

• The full chain of advertising, scanning, connection setup, roles, and connection parameters: see GAP
• How packets are sent and received after connection, why retransmission happens, and why throughput changes: see Link Layer / PHY
• How service discovery, reads/writes, and notifications are organized after connection: see GATT/ATT
• Why address privacy, pairing, bonding, and permissions affect access: see SMP

If you mix these layers together, it becomes very easy to call “cannot scan,” “cannot connect,” “cannot read,” and “pairing failed” the same generic “Bluetooth problem.”

References and Further Reading

Bluetooth Core Specification

• Bluetooth Core Specification
  • Vol 6, Part B: Link Layer Specification
    • Section 2.3: Physical channels
    • Section 2.3.1: Advertising channel index
    • Section 4.4.2: Advertising physical channel PDU
  • Vol 3, Part C: Generic Access Profile
• Official entry: https://www.bluetooth.com/specifications/specs/

Further Reading

• BLE Architecture Overview: return to the full protocol stack, role boundaries, and a unified debugging entry point
• BLE GAP Analysis: return to the main line of advertising, scanning, connection setup, address, and connection parameters
• BLE Link Layer / PHY: continue with how advertising ends, how connection events start, ACK/retransmission, and hopping
• BLE GATT/ATT Analysis: continue with how service discovery, reads/writes, and notifications are organized after connection