LE Audio EATT

EATT

<\/script>\n
'; }, get iframeSnippet() { const domain = '{ SITE_DOMAIN }'; const type = '{ embed_type }'; const slug = '{ embed_slug }'; return ''; }, get activeSnippet() { return this.method === 'script' ? this.scriptSnippet : this.iframeSnippet; }, copySnippet() { navigator.clipboard.writeText(this.activeSnippet).then(() => { this.copied = true; setTimeout(() => { this.copied = false; }, 2000); }); } }" @keydown.escape.window="open = false" @click.outside="open = false">

Embed This Widget

Theme


      
    

Widget powered by . Free, no account required.

Enhanced Attribute Protocol -- BLE 5.2 enhancement allowing multiple parallel ATT bearers for improved throughput.

Also known as: Enhanced ATT Enhanced Attribute Protocol

Enhanced Attribute Protocol (EATT)

ATT bearers for throughput." data-category="LE Audio">EATT (Enhanced Attribute Protocol) is a Bluetooth 5.2 enhancement that allows multiple parallel ATT bearers over a single BLE connection. Unlike the original ATT, which uses a single serial channel for all GATT operations, EATT enables concurrent transactions on separate L2CAP credit-based channels.

Why EATT Exists

With standard ATT, a single request-response transaction must complete before the next can begin. This creates head-of-line blocking: a slow GATT read blocks all other operations on the same connection. For LE Audio, where multiple services (ASCS, PACS, VCS, MCS) may need simultaneous configuration, this bottleneck introduces unacceptable latency.

EATT solves this by allowing multiple ATT bearers, each operating independently on its own L2CAP channel. A phone configuring stereo earbuds can simultaneously read audio capabilities, write stream configurations, and update volume -- all without blocking.

Protocol Details

EATT uses L2CAP Enhanced Credit Based Flow Control (ECBFC) channels. During connection setup, both devices negotiate the number of EATT bearers (typically 3-5). Each bearer has its own send/receive buffers and credit-based flow control, preventing one busy bearer from stalling another.

EATT requires an encrypted connection (Pairing with at least Unauthenticated encryption). This security requirement ensures that the additional L2CAP channels cannot be exploited by untrusted devices.

EATT vs ATT

Feature ATT EATT
Bearers per connection 1 Multiple (3-5 typical)
Concurrent transactions No Yes
L2CAP mode Fixed channel (CID 0x0004) ECBFC dynamic channels
Security requirement Optional Encrypted link required
Minimum Bluetooth version 4.0 5.2

Implementation Notes

EATT support is negotiated during the L2CAP connection setup phase. Both devices must support EATT for it to activate. On chips like the nRF5340 and nRF54L15, EATT is handled in the BLE host stack with no special hardware requirements beyond Bluetooth 5.2 compliance. Developers using the Zephyr RTOS BLE stack can enable EATT via Kconfig options.

Related Terms

Frequently Asked Questions

Our glossary covers 90+ BLE technical terms organized by category. Each term includes a definition, related terms, and links to relevant chips and guides.