1. Enhanced ATT (EATT) feature

Enhanced ATT is a Bluetooth® Low Energy 5.2 standard feature: it is implemented for STM32WB and STM32WBA.
Whereas the original unenhanced attribute protocol operates in a sequential manner, the enhanced attribute protocol provides a way to perform concurrent/parallel transactions between a Bluetooth® Low Energy client and a server and potentially reduce the latency of operations in some applications.

For example, this is useful on a smartphone where multiple applications may be interfacing with a Bluetooth® Low Energy device.
By using EATT, an application’s attribute transaction would not be blocked while another application’s ATT transaction is in progress, essentially allowing different applications to interact with a Bluetooth® Low Energy device in parallel and potentially reducing latency.

1.1. Enhanced attribute protocol (EATT) new capabilities

• EATT modifies the sequential transaction model, making concurrent ATT transactions possible when conducted over distinct enhanced ATT bearers.
• EATT uses the L2CAP enhanced connection-oriented channels mode. This L2CAP mode provides flow control so that EATT can be regarded as reliable.
• MTU values at the ATT layer and L2CAP layer have been made independently configurable, and this may reduce the latency experienced by some applications that share the Bluetooth® Low Energy stack with other applications.

Bluetooth® Low Energy enhanced attribute protocol
Connectivity:connectivity L2cap.png

1.2. Changes introduced in Bluetooth® Low Energy stack by the introduction of EATT

If EATT is enabled, at GATT initialization, two new characteristics are added to the GATT service:

A new characteristic called Server Supported Features has been defined and must be included in the generic attribute profile service if EATT is supported by the server.
Bit 0 of the first octet of the value of this characteristic set to 1 means that EATT is supported.
A GATT client can determine whether or not the server supports EATT by reading this characteristic.

Server Supported Features (for "EATT Supported")

And the Client Supported Features characteristic that has been defined with the following values.
Bits of the characteristic’s value indicate support for certain features.

  • Bit 1 indicates whether or not the enhanced ATT bearer is supported by the client.
  • Bit 2 indicates whether or not a new ATT PDU called multiple handle value notifications is supported.

The client must write an appropriate value to this characteristic to inform the server of the features it supports.

Client Supported Features (for "Enhanced ATT bearer" and "Multiple Handle Value Notifications)

New GATT information is stored in NVM:

Client Supported Features (for "Enhanced ATT bearer" and "Multiple Handle Value Notifications")

1.3. GATT commands and events supporting the enhancement

In the same principle as GATT commands, the GATT events referring to a specific EATT bearer return the value 0xEA00 | channel_index for the Connection_Handle parameter.
For more information regarding GATT commands and events over EATT refer to PM0271: [1] Guidelines for Bluetooth® Low Energy stack programming on STM32WB/STM32WBA MCUs.

1.4. Flag configuration on STM32WB and STM32WBA

To enable the EATT feature on STM32WB set the CFG_BLE_OPTIONS_ENHANCED_EATT value to SHCI_C2_BLE_INIT_OPTIONS_ENHANCED_ATT_SUPPORTED using the STM32CubeMX interface. This feature is available only with the "Full extended Bluetooth® LE stack" (stm32wb5x_BLE_Stack_full_extended_fw.bin).

Enable EATT feature with STM32CubeMX for STM32WB
connectivity EATT MX interface.png

To enable the EATT feature on STM32WBA, set the BLE_OPTIONS_ENHANCED_ATT value to "Enhanced ATTribute is supported" using the STM32CubeMX interface. This feature is available only with the "Full Bluetooth® LE stack" (stm32wba_ble_stack_full.a).

Enable EATT feature with STM32CubeMX for STM32WBA
connectivity GATT EATT WBA CMX.png

1.5. How to implement on STM32WB and STM32WBA applications

1. Set the flag to support the EATT feature.

2. Set the variable CFG_BLE_NUM_LINK. The number of EATT bearers is equal to CFG_BLE_NUM_LINK + 4.
The Channel_Number parameter in the aci_l2cap_coc_connect command corresponds to the number of "bearers" we want to establish.

3. Create a GAP connection.

4. Perform a pairing, this is mandatory as EATT requires the link to be encrypted.

5. Establish a Connection Oriented Channel (COC) over the Bluetooth® Low Energy link with SPSM = 0x0027 using the following command:



This command sends a Credit Based Connection Request packet on the specified connection.
tBleStatus aci_l2cap_coc_connect( uint16_t Connection_handle, uint16_t SPSM, uint16_t MTU, uint16_t MPS, uint16_t Initial_credits, uint8_t Channel_number );
[in] Connection_handle
Type: uint16_t
Description: Specifies the ATT bearer for which the command applies
[in] SPSM
Type: uint16_t
Description: Simplified Protocol/Service Multiplexer. Is equal to 0x0027 in case of EATT.
[in] MTU
Type: uint16_t
Description: Maximum Transmission Unit.
[in] MPS
Type: uint16_t
Description: Maximum payload size (in octets).
[in] Initial_credits
Type: uint16_t
Description: Number of K-frames that can be received on the created channel(s) by the L2CAP layer entity sending this packet.
[in] Channel_number
Type: uint8_t
Description: Number of channels to be created. If this parameter is set to 0, it requests the creation of one LE credit based connection-oriented channel. Otherwise, it requests the creation of one or more enhanced credit based connection-oriented channels.
Return value
[out] command status
Type: uint8_t
Events generated

6. On both sides, once the channel is opened, the aci_gatt_eatt_bearer_event is received to confirm the creation of the EATT bearer, one aci_gatt_eatt_bearer_event is received for each channel.

On the central side, Channel_Index (in ACI_GATT_EATT_BEARER_EVENT) is included between 0x00 and 0x1F.

On the peripheral side, Channel_Index (in ACI_GATT_EATT_BEARER_EVENT) is included between 0x20 and 0x3F.

To address separately each bearer:
The connection handle to apply is between 0xEA00 and 0xEA1F for the central.

The connection handle to apply is between 0xEA20 and 0xEA3F for the peripheral.

2. Example of EATT feature including 2 bearers and data exchange

2.1. Advertising data

At startup, the EATT server application starts advertising.
Data advertised are composed as follows:

EATT server advertising packet
Description Length AD type Value
Device name 8 0x09 EATT_XX (XX: last byte of BD address)
Manufacturer data 15 0xFF See table below
Flags 2 0x01 0x06
(GeneralDiscoverable, BrEdrNotSupported)

Manufacturer data are encoded following STMicroelectronics BlueST-SDK v2 as described below:

STMicroelectronics manufacturer advertising data
Byte index 0 1 2-3 4 5 6 7 8 9 10-15
Function Length Manufacturer ID Company BlueST-SDK version Device ID Firmware ID Option 1 Option 2 Option 3 Device address
Value 0x0F 0xFF 0x0030 STMicro 0x02 0x8B Nucleo-WBA 0xE1 - EATT Server 0x00 0x00 0x00 0x08E12Axxxx

2.2. On-board buttons configuration

Button configuration for Bluetooth® Low Energy enhanced ATT application on Nucleo-WBA55CG boards
Application Condition B1 click B1 long press B2 click B2 long press B3 click B3 long press

EATT server

Idle - / Clear security database / - /
Connected Starts/Stops notification on Bearer1 & Bearer2 -


Idle Starts scan then connects, discovers service/characteristics / Clear security database / - /
Connected Starts/Stops write data on Bearer1 & Bearer2 -

2.3. EATT links and data exchange

Bluetooth® Low Energy and COC link establishment with EATT (SPSM=0x0027)
Connectivity EATT Link.png

GATT data exchange
Connectivity EATT write notif.png

3. References