Enhanced ATT
The Enhanced ATT protocol allows concurrent transactions to be handled by the stack. The sequential transaction rule still exists when EATT is used, but its scope is now defined as being per instance of the Enhanced ATT Bearer. EATT transactions might execute in parallel if they are supported by distinct L2CAP channels, which use the Enhanced Credit Based Flow Control Mode (that is, distinct Enhanced ATT Bearers).
When using an Enhanced ATT Bearer, ATT MTU and L2CAP MTU are independently configurable and may be reconfigured during a connection. An increase to the MTU is allowed but reducing its size is not. Allowing MTU to be increased without needing to reestablish the connection has an advantage. It eliminates the risk of a second application using the stack, being unable to continue, due to the previously negotiated MTU being too small.
Enhanced ATT bearers are identified through Bearer Ids. Enhanced ATT Bearer Ids are assigned internally and have a valid range between 1 and 251. The Unenhanced ATT bearer is always available for a connected peer device and has the BearerId 0.
EATT Credits management
Credits for the L2CAP channels used by Enhanced ATT bearers may be managed internally if the autoCreditsMgmt parameter is set to TRUE in the **Gap\_EattConnectionRequest** or **Gap\_EattConnectionAccept** function call. Otherwise, the application is responsible for credits management.
If the application chooses to manage the credits of the L2CAP channels used as Enhanced ATT bearers, it should use the following function to send credits for a specified bearer to a peer device:
bleResult_t **Gap\_EattSendCredits**
(
deviceId_t deviceId,
bearerId_t bearerId,
uint16_t credits
);
If the local credits or peer credits of the L2CAP channel used by an Enhanced ATT bearer reaches 0, agConnEvtEattBearerStatusNotification_c connection event is updated with a status value ofgEnhancedBearerSuspendedNoLocalCredits_c, or gEnhancedBearerNoPeerCredits_c respectively.
Parent topic:Enhanced ATT
EATT Connection establishment
In order to take advantage of the Enhanced ATT features, first a number of Enhanced Bearers should be opened for a connected peer device. For this, the function below may be used to create up to five Enhanced ATT bearers at a time:
bleResult_t Gap_EattConnectionRequest
(
deviceId_t deviceId,
uint16_t mtu,
uint8_t cBearers,
uint16_t initialCredits,
bool_t autoCreditsMgmt
);
The mtu parameter specifies the MTU for all the bearers to be established.
The cBearers parameter is used to specify the number of Enhanced ATT bearers to be opened, and should have a value between 1 and 5. The initialCredits parameter specifies the initial number of credits of the L2CAP credit based channels used as Enhanced ATT bearers.
The autoCreditsMgmt parameter is used to tell the Bluetooth LE Host Stack if it should manage L2CAP channel credits automatically. If set to TRUE the Bluetooth LE Host Stack automatically sends credits to a peer device when exhausted in chunks of initialCredits.
For example, to establish two Enhanced ATT bearers with a peer device the application may call the Gap_EattConnectionRequest as shown below:
bleResult_t result = **Gap\_EattConnectionRequest**(peerDeviceId,
64U,
2U,
3U,
TRUE);
if (gBleSuccess_c != result)
{
/* Treat error */
}
If an EATT Connection Request is received from a peer device it would be signaled through the gConnEvtEattConnectionRequest_c connection event of type gapEattConnectionRequest_t sent to the connection callback. The application should handle this event by calling Gap_EattConnectionAccept. The example below shows how an application may accept an incoming EATT Connection Request with the same MTU as requested by the peer device.
case gConnEvtEattConnectionRequest_c:
{
gapEattConnectionRequest_t *pEattConnectionReq = &pConnectionEvent->eventData.eattConnectionRequest;
bleResult_t result = **Gap\_EattConnectionAccept**(peerDeviceId,
TRUE,
pEattConnectionReq->mtu,
3U,
TRUE);
if (gBleSuccess_c != result)
{
/* Treat error */
}
}
break;
In case the localMtu specified when accepting a connection differs from the MTU requested by the peer device, the minimum of the two would become the MTU of the Enhanced Bearers.
After the **Gap\_EattConnectionRequest** or **Gap\_EattConnectionAccept** is called, for the result the application should wait for the gConnEvtEattConnectionComplete_c connection event of type gapEattConnectionComplete_t shown below:
typedef struct {
l2caLeCbConnectionRequestResult_t status;
uint16_t mtu;
uint8_t cBearers;
bearerId_t aBearerIds[gGapEattMaxBearers];
} gapEattConnectionComplete_t;
If successful, the aBearerIds array contains the bearer ids, for the Enhanced ATT bearers established. These ids may be used with the GATT Enhanced APIs in order to trigger GATT procedures over Enhanced ATT bearers.
Parent topic:Enhanced ATT
EATT Bearer reconfiguration
One of the advantages of Enhanced ATT bearers over the Unenhanced ATT bearer is the ability to increase the MTU multiple times. To reconfigure the MTU and/or MPS of existing Enhanced ATT bearers, the **Gap\_EattReconfigureRequest** should be used. If a mps value of 0 is given, the maximum available MPS value for that channel is used.
For example, in order to reconfigure the MTU of two bearers from 64 to 128 the application may call **Gap\_EattReconfigureRequest** as shown below:
bleResult_t result = gBleSuccess_c;
bearerId_t aBearerIds[2] = {1U, 2U};
result = **Gap\_EattReconfigureRequest**(peerDeviceId,
128U,
0U,
2U,
aBearerIds);
if (gBleSuccess_c != result)
{
/* Treat error */
}
The application should monitor the gConnEvtEattChannelReconfigureResponse_c connection event of type gapEattReconfigureResponse_t for the result.
The procedure triggered by ******Gap\_EattReconfigureRequest** updates only the local MTU. The ATT_MTU for Enhanced ATT bearers is the minimum of the MTU values of the two devices.
Parent topic:Enhanced ATT
EATT Bearer disconnection
Individual Enhanced ATT bearers can be disconnected by calling the Gap_EattDisconnect API as shown below:
bleResult_t result = gBleSuccess_c;
result = Gap_EattDisconnect(peerDeviceId, bearerId);
if (gBleSuccess_c != result)
{
/* Treat error */
}
The application should look for a connection event of type gEnhancedBearerDisconnected_c in the connection callback.
Parent topic:Enhanced ATT
Parent topic:Generic Access Profile (GAP) Layer