BLE Extended Advertising Reports: Reassemble Data Before Trusting Device Discovery

Admit an extended-advertising record to device discovery only after the receiving layer has established that its data is complete and the application parser has validated the result. A recognizable name or service identifier in an early fragment is not evidence that the rest of the record arrived. A truncated report must not be repaired by appending bytes from a later advertisement.

This guide uses Zephyr v3.7.0 as a concrete, inspectable host implementation. It covers non-periodic LE extended-advertising reports and the boundary between raw HCI events and application scan callbacks. Controller firmware, supported PHYs and buffer configuration must be recorded separately. Other Zephyr revisions, mobile APIs and vendor stacks can expose different completeness behavior; inspect their exact contracts before transferring this procedure.

Identify the layer that owns assembly

First determine what the application receives: raw HCI report fragments, a vendor event containing status information, or a host callback after assembly. This avoids implementing a second assembler on top of an already assembled record. It also explains why a controller trace can contain fragments while the application sees no callback.

In Zephyr v3.7.0, the extended-report handler accumulates partial data before delivering an assembled result, drops controller-truncated data, and checks available assembly-buffer space. The same implementation explicitly does not support interleaved fragmented reports from different advertisers. Those are properties of this version, not universal Bluetooth limits. Inspect the tagged host scan implementation when diagnosing a missing result.

Keep traces at both boundaries during qualification. Record the controller report metadata, lengths and status, then the application callback’s metadata and length. The useful question is where a candidate was lost or rejected, not simply whether the device appeared in a user interface.

Interpret status before interpreting payload

The v3.7.0 HCI definitions extract data status from Event_Type bits 5 and 6. They name values 0, 1 and 2 as complete, partial and incomplete, respectively. In the matching host handler, partial means more data is expected, while incomplete represents a truncated result with no more data to come. Do not confuse a partial intermediate report with a terminal truncation.

• Complete without pending fragments: validate the standalone record.
• Partial with a consistent assembly context: retain bounded data and wait; do not publish a complete device record.
• Complete after partial data: finalize the corresponding assembly, then validate the whole record.
• Truncated: discard the candidate’s partial application data and record a reason.
• Unknown or malformed status: follow the supported interface’s error policy and reject admission rather than guessing completeness.

These admission rules are a proposed product policy. A diagnostic display may show that an advertiser was observed with incomplete data, but it should label that state explicitly and keep it separate from a validated discovery result.

Keep advertiser identity separate from record generation

The Zephyr implementation associates pending assembly with an advertiser address, including its type, and an advertising SID. Its HCI report structure also carries report properties and PHY information. That identifies useful context, but the SID should not be promoted into an application payload-version counter. The inspected HCI report structure does not expose an Advertising DID field.

For a custom raw-report pipeline, define which metadata must remain consistent and which layer provides the start and end boundaries. Separate advertising data from scan-response data. Do not join observations merely because they share a displayed device name, RSSI or a recently seen address. If a required identity field is unavailable or ambiguous, use a deliberately restricted policy instead of pretending the match is unique.

After a record completes, replacement is a new admission decision. Where an application requires several fields to change atomically, consider a payload schema version and generation identifier in the application format. Validate them after assembly. This is a design recommendation for your own protocol, not a Bluetooth requirement or a substitute for its report boundaries.

Define bounded memory and a clean failure path

Set a maximum accepted record size from the actual product format and receiving implementation. Record both the host assembly configuration and controller limits. Increasing the host buffer cannot recover bytes the controller has already discarded. Conversely, an adequate controller limit does not prove that the host can retain the whole result.

Specify what happens to pending data when scanning stops, the controller resets, a transport error occurs or a software-defined assembly deadline expires. Keep a rejected or timed-out generation from accepting an unexplained late tail. The exact reset mechanism belongs to the owning stack; a timeout in the application cannot safely rewrite hidden host assembly state.

At the application boundary, validate advertising-data field lengths before interpreting their contents, then validate the expected schema and required fields. The Zephyr v3.7.0 GAP API documents advertising-data structures and scan callback metadata. A buffer’s arrival is not itself proof that your product-specific format is meaningful or trustworthy.

Qualify with a fragment and parser test corpus

Use a controlled advertiser plus an HCI replay or injection harness appropriate to the host under test. Record which tests exercise radio reception and which exercise only parsing. The following proposed cases have not been executed on hardware:

1. A complete valid report should create one admitted record with byte-for-byte expected content.
2. The same content split at several fragment boundaries should produce the same admitted record and no early publication.
3. A partial sequence ending in truncation should produce no validated record and should increment the appropriate rejection counter.
4. A sequence exceeding the configured buffer should fail cleanly; the next independent valid report should still be usable.
5. Reports with inconsistent identity or report type should never create a mixed payload.
6. Two advertisers with fragmented data should expose any version-specific interleaving limitation rather than silently merging their bytes.
7. A complete report containing invalid application field lengths should fail parser validation even though transport completeness passed.
8. A scan restart or controller reset during assembly should not let an old prefix contaminate a new result.

Measure correctness with accepted bytes, rejection reasons and recovery state. A discovery-count total can hide a mixed-generation bug if the same number of records is still displayed.

Hypothetical example: a convincing prefix creates a false match

Imagine a hypothetical commissioning tool that accepts a product-family identifier from an early fragment. The remaining data contains a configuration generation and a compatibility field. Reception ends in truncation, but the interface already labels the device as compatible. A later advertisement supplies different data, and a careless cache combines the old prefix with the new tail.

The improved design keeps the observation pending until assembly and schema validation finish. A truncated observation may remain visible as incomplete, but it cannot authorize configuration. A later complete generation replaces it as a new record. This protects the meaning of discovery without claiming that extended advertising guarantees delivery or that advertising alone authenticates a device.