HCI USB Bulk Serialization: Check Host and Controller Compatibility Before Migration

HCI USB Bulk Serialization is a transport-mode migration. It needs controller descriptor support, a compatible host driver, a controlled alternate-setting transition and packet dispatch that preserves the intended order. A Bluetooth version label or working legacy ACL traffic is insufficient evidence.

Applicability: Bluetooth Core 6.3, Volume 4 Part B USB transport. The SIG’s Core 6.2 feature overview explains the feature’s introduction; the normative procedure here is pinned to 6.3. This is a protocol-level compatibility and regression plan, not a claim that a particular OS release or controller implements the mode. No USB mode switch or ordering experiment was performed.

1. Inventory the actual legacy and serialized paths

Core 6.3 Part B distinguishes two modes. Legacy mode sends HCI commands through control, receives events through interrupt, uses bulk for ACL and uses isochronous endpoints for SCO. It does not define a mechanism for LE Isochronous Channel data.

Bulk Serialization carries all HCI packet types, including ISO, through the bulk endpoints. It remains optional; implementations must support legacy mode. Do not describe an existing vendor-specific ISO-over-USB path as this standardized mode merely because it also uses bulk transfers.

Record USB device and firmware identities, descriptors, interface numbers, endpoint addresses, selected alternate settings, host driver revision and relevant configuration. Distinguish the Bluetooth function’s first interface from USB interface number zero in a composite device.

The SIG’s feature overview identifies cross-endpoint data/event ordering as a motivation for serialization. Treat that as a transport problem to qualify, without promising that serialization fixes every host scheduling or application race.

2. Build the compatibility matrix from descriptors and code

The first interface’s default alternate setting zero contains bulk and interrupt endpoints. A controller supporting Bulk Serialization provides alternate setting one containing only bulk endpoints. The host selects that setting with a USB select-interface request.

Inspect descriptors rather than hard-coding example endpoint addresses from a specification table. For a composite device, identify the associated Bluetooth interfaces and ensure the request targets the correct interface.

Pin implementation evidence to a release or commit. A patch announcement, controller feature list or successful descriptor read does not establish that the shipping driver handles mode selection, suspend/resume and every required HCI packet type.

3. Respect the mode-switch restrictions

Core requires specific STALL behavior. In legacy mode, if the second interface has a nonzero alternate setting selected, the controller rejects an attempt to change the first interface’s alternate setting. Resolve that synchronous-data configuration through the owning driver before switching modes.

In Bulk Serialization mode, attempts to change the second interface’s alternate setting are rejected, because SCO traffic also uses bulk. HCI commands incorrectly sent through the control endpoint are rejected too.

These are protocol-visible compatibility checks, not generic USB permission failures. Preserve which request stalled, the active mode and both interfaces’ alternate settings. Do not respond by randomly retrying different endpoint routes.

Use one transport owner to stop new submissions, reconcile outstanding host requests and change routing at a defined boundary. The exact drain/cancellation sequence belongs to the selected driver. Keep callback storage alive until its supported completion boundary.

4. Retain pending controller packets across the transition

The controller must retain packets awaiting host retrieval when instructed to switch modes and make them available through the new endpoint or endpoints afterward. A mode switch is therefore not a specification-authorized way to discard pending events.

Design a hypothetical fixture in which the controller queues event E followed by data D while host retrieval is paused through a supported lab mechanism. Switch mode, resume retrieval and verify that the pending records are delivered through the new path without omission or duplicate host processing.

Track host requests that completed near the transition separately from packets still pending in the controller. Otherwise a duplicate can be blamed on retention when the host actually processed the same completed transfer twice.

Do not apply the retention rule to USB unplug, power loss or an unrelated controller reset. Those are different lifecycle events with different state-loss contracts.

5. Add the packet indicator at the correct boundary

Serialized mode prefixes each HCI packet with one type byte: command 0x01, ACL 0x02, synchronous 0x03, event 0x04 or ISO 0x05. All other indicator values are reserved. Validate direction, type-specific header length and declared payload length before dispatch.

The USB transport’s packet/transfer rule still matters: an HCI packet is contained in one USB transfer, which can consist of multiple USB transactions. Endpoint maximum packet size is not the maximum HCI packet size.

Do not import an arbitrary UART byte-stream assumption and silently concatenate unrelated HCI packets into one USB transfer. Likewise, a transfer spanning several USB transactions is not several application records. Record the actual driver request boundary and its complete received length.

For a hypothetical received event, the serialized transfer begins with 0x04 before the HCI event header. The legacy interrupt transfer carries the event without that serialization prefix. A decoder that keeps the old layout after switching mode can misinterpret the type byte as the event code.

6. Preserve order after the bulk endpoint

Serialization places controller-to-host HCI traffic on one bulk receive path, removing the legacy event-versus-data endpoint split. The host must still preserve the sequence through its own decoder and state updates.

In the E→D fixture, dispatching E to a slow worker and D to an independent fast worker can recreate an application-visible D-before-E race after transport delivery was correct. Record endpoint receipt order and host processing order separately.

Use a state-dependent regression case, such as data associated with a newly established connection. Establish the required controller emission order from that procedure, then verify that host connection state exists before dependent data is processed. Do not assume that every pair of unrelated HCI packets has a meaningful global order.

Keep HCI command and data flow control intact. Multiplexing packet types onto bulk does not turn controller buffer credits into unlimited capacity or make USB completion an application-delivery acknowledgment.

7. Qualify migration and fallback

1. Test legacy operation with a controller that lacks the alternate setting.
2. Test compatible selection and verify every required packet type uses the new bulk path.
3. Exercise the specified incompatible-interface and wrong-command-endpoint STALL cases in an isolated fixture.
4. Switch with pending controller packets and reconcile delivery exactly once.
5. Delay host event processing to expose downstream reordering independently of endpoint order.
6. Repeat suspend/resume, reconnect and supported fallback with descriptor/routing state revalidated.
7. Include ISO workload only when controller, host and application support is established; measure deadlines rather than assuming bulk has a universal latency guarantee.

Acceptance is a compatible mode, correct packet boundaries, preserved state-dependent order and explicit fallback behavior. Keep the descriptor snapshot, driver revision and transition trace with the release evidence so “USB works” does not hide an unqualified transport migration.