[AI Readability Summary] BASS is the key control service in the LE Audio broadcast receive path. It handles remote scan delegation, broadcast source management, and state synchronization. Its main purpose is to offload continuous scanning and synchronization work from power-constrained devices. Keywords: LE Audio, BASS, GATT.
The technical specification snapshot defines the baseline
| Parameter | Description |
|---|---|
| Protocol Name | Broadcast Audio Scan Service (BASS) |
| Ecosystem | Bluetooth LE Audio |
| Primary Language | Protocol specification / GATT data model |
| Runtime Foundation | Bluetooth Core 5.2+ |
| Transport Bearer | ATT / EATT |
| Service Type | Standalone GATT Primary Service |
| Core Dependencies | GATT, ATT, EATT, PA, PAST, BIG, BIS |
| Source Popularity | The original article shows approximately 184 views, 6 likes, and 4 bookmarks |
BASS acts as the control hub of the LE Audio broadcast receive path
BASS does not carry audio data directly. Instead, it answers four control-plane questions: who scans, which broadcast source gets discovered, how synchronization happens, and how status gets reported back. Its core goal is to offload power-intensive scanning tasks from constrained devices.
In hearing aids, TWS earbuds, portable receivers, and similar products, devices are usually not well suited for long-running active scanning. Through Remote Scanning and PAST, BASS separates broadcast source discovery from synchronization parameter delivery, balancing power efficiency with usability.
The protocol role of BASS can be understood like this
The Broadcast Assistant scans for broadcast sources
↓
It writes source information to the receiving device through BASS
↓
The receiving device synchronizes based on PA / BIG / BIS information
↓
It reports status changes back through NotificationsThis flow highlights the core responsibility of BASS: managing broadcast sources rather than transporting audio frames themselves.
Compliance requirements determine whether a device is truly compatible
The first principle of BASS is not feature richness but behavioral consistency. Mandatory capabilities defined by the specification must be implemented exactly as specified. Optional capabilities may be omitted, but once implemented, vendors must not redefine parameter formats, state machines, or interaction semantics.
This rule determines whether cross-vendor interoperability actually works. A device may implement only the minimum capability set, but it must not create a protocol variant. For example, if control operations such as Add Source, Modify Source, or Set Broadcast_Code are implemented, they must follow the defined field layout and result semantics.
You can use the following compliance check during development
bool bass_feature_is_compliant(bool implemented, bool spec_required) {
if (spec_required && !implemented) {
return false; // Missing a mandatory capability, so the implementation is non-compliant
}
return true; // Optional capabilities may be left unimplemented
}The key point of this example is simple: the foundation of BASS is specification consistency, not arbitrary customization.
The BASS service and transport design stays minimal and independent
BASS is defined as a standalone GATT primary service with no additional service dependencies. This design lowers the integration barrier. Vendors do not need to implement a complex upper-layer service stack before adding broadcast scan control to an existing product.
At the transport layer, BASS is compatible with both ATT and EATT. If a device only needs basic control and state synchronization, ATT is sufficient. If the system requires stronger notification reliability, better concurrency, or more stable long-data transfers, EATT is a better fit.
The choice between ATT and EATT should center on reliability
ATT : Simple, low resource usage, suitable for basic scenarios
EATT : Supports enhanced concurrency and more reliable attribute interactions, suitable for high-reliability notification scenariosThis means devices used in medical, hearing-assistance, or other state-sensitive scenarios are more likely to require EATT support.
Bluetooth Core 5.2 and later is the hardware prerequisite for BASS
BASS is not an isolated protocol. It depends on the lower-layer capabilities introduced by LE Audio. Bluetooth Core 5.2 and later provides the essential mechanisms behind PA, PAST, BIG, and BIS. Without these building blocks, BASS becomes only an empty control interface.
From an engineering perspective, this directly constrains chipset selection. If the controller or protocol stack does not support the required 5.2+ features, exposing the GATT service alone still cannot deliver real broadcast synchronization and reception.
GATT subprocedures are the minimum threshold for BASS interoperability
Because BASS is built on GATT, both client and server must support a baseline set of interaction procedures. Mandatory items in the specification include Write Characteristic Value, Write Without Response, Notifications, Read Characteristic Descriptors, and Write Characteristic Descriptors.
If the server supports Add Source, it must also support Write Long Characteristic Value. The reason is straightforward: broadcast source parameters can exceed the minimum ATT MTU, so long writes are required to transfer the full payload reliably.
AI Visual Insight: This figure shows how BASS GATT subprocedure requirements are classified when carried over non-enhanced ATT, usually as a list of mandatory and conditional items. Developers can use it to verify coverage for characteristic writes, notifications, descriptor reads and writes, and long writes, then determine whether the client and server meet the minimum interoperability baseline.
A typical subscription-and-write sequence looks like this
def enable_bass_notification(client, cccd_handle, control_point, payload):
client.read_descriptor(cccd_handle) # Read the descriptor to confirm it is configurable
client.write_descriptor(cccd_handle, b'\x01\x00') # Enable notifications
client.write_char(control_point, payload, response=True) # Send the control commandThis code summarizes the two most common steps in BASS: subscribe to state notifications first, then send a control command.
Application error codes unify cross-device error handling semantics
BASS defines two dedicated ATT application error codes. 0x80 means Opcode Not Supported, which indicates that the client wrote an opcode the server does not support. 0x81 means Invalid Source_ID, which indicates that the specified broadcast source does not exist.
These two error codes are returned only for write operations with response. If the client uses Write Without Response, the server may ignore an invalid operation directly. This design balances the needs of both low latency and explicit feedback.
AI Visual Insight: This figure highlights the mapping between BASS-specific error codes and their trigger conditions, usually alongside a control point write scenario or Source_ID validation flow. Its value lies in helping developers quickly trace link failures back to one of two root causes: an unsupported opcode or a non-existent broadcast source.
Little-endian ordering is a mandatory byte rule for BASS parsing
All multi-byte fields in BASS use LSO first, which means little-endian byte order. When developers parse fields such as Source_ID, PA_Interval, bitmaps, or broadcast keys, they must always process the lowest byte first.
Byte-order mistakes are often the most subtle and the most destructive. In mild cases, field values become corrupted. In severe cases, the implementation may use the wrong key, synchronize to the wrong target, or select the wrong BIS, ultimately producing symptoms such as “connected but no audio” or abnormal status reports.
A little-endian parsing example
uint16_t read_le16(const uint8_t *buf) {
return (uint16_t)buf[0] | ((uint16_t)buf[1] << 8); // Combine a 16-bit value in little-endian order
}This function restores a common two-byte BASS field from a buffer into an integer correctly.
Specification terminology directly affects implementation decisions
When reading the BASS specification, you cannot treat shall, must, should, may, and can as interchangeable. shall indicates a mandatory requirement, should indicates a recommended practice, and may indicates an optional capability. Many implementation mistakes ultimately come from treating recommendations as mandatory requirements or treating mandatory requirements as optional.
You must also distinguish RFU from Prohibited. RFU means Reserved for Future Use. Senders should set these bits or fields to , and receivers typically ignore them. Prohibited means explicitly forbidden. A sender must not use such values, and a receiver should ignore the corresponding data structure or packet.
AI Visual Insight: This figure typically summarizes protocol keywords and the handling rules for RFU and Prohibited values, helping developers internalize the idea that specification language defines behavioral constraints. For implementers, this kind of visual is often more useful than plain text during code reviews and compatibility testing.
Core terminology connects the complete BASS workflow
The key BASS terms include BIG, BIS, PA, PAST, Remote Scanning, and SyncInfo. These are not isolated concepts. They form a complete causal chain: the client scans for a broadcast source, obtains PA information, passes synchronization parameters to the server through PAST, the server synchronizes to the BIG, and then receives the BIS audio stream.
To truly understand BASS, you need more than acronym memorization. You need to understand the ordering and dependency relationship among these terms in the end-to-end path. The value of BASS is that it standardizes this sequence into an interaction model that is delegable, configurable, and observable.
AI Visual Insight: This figure shows the BASS terminology family and its hierarchy, typically placing BIG/BIS, PA/PAST, and Remote Scanning in the same semantic map. It helps developers move from memorizing isolated acronyms to modeling the full broadcast synchronization path.
AI Visual Insight: This figure serves as a converged view of the BASS workflow, usually emphasizing the dependency chain from scan delegation and synchronization parameter transfer to final broadcast stream reception. It is well suited for understanding the relationship between state transitions and control point operations.
Developers should prioritize interoperability boundaries over isolated features
Common BASS issues do not appear only in whether a feature exists. They also appear at the boundaries: whether long writes are supported, whether notifications are subscribed correctly, whether error codes are returned only for writes with response, whether RFU values are rejected incorrectly, and whether byte order stays consistent.
If you need to prioritize testing, start by validating the full set of control point operations. Next, validate the Source_ID lifecycle. Finally, cover EATT and long characteristic value scenarios. This order will expose interoperability problems the fastest.
FAQ provides structured answers to recurring implementation questions
1. Why does Add Source require long writes?
Because broadcast source information can include the device address, Broadcast_ID, synchronization parameters, and metadata, the payload can easily exceed the minimum ATT MTU. If Add Source is supported, Write Long Characteristic Value must also be supported.
2. When should you prioritize EATT?
You should prioritize EATT when the device requires higher notification reliability, concurrent attribute operations, or more stable large-payload writes. Typical examples include medical hearing devices and high-reliability broadcast receivers.
3. What is the easiest implementation mistake to make with RFU and Prohibited?
The most common mistake is treating RFU as an illegal value and rejecting it directly. In practice, RFU exists for future extension, so the receiver should usually ignore it. Prohibited values are the ones that are explicitly forbidden, must not be sent, and should not be processed further when received.
Core summary: This article systematically reconstructs the foundational BASS specification in LE Audio, covering compliance, transport dependencies, GATT subprocedures, error codes, little-endian rules, RFU/Prohibited handling, and core terminology to help developers quickly build a protocol-level understanding of broadcast audio scanning and synchronization.