The packet division by setting of ATT_MTU and DLE？

[Yoko]

Hello,

We try to use "ATT_MTU" and "Data length extension (DLE)" to expand a packet in S132 SDK 14.0.0. When we set "ATT_MTU" > "DLE", please tell me what happens?

We thought data was sent by 1 packet when I set "ATT_MTU"=158 and "DLE"= 137. But, I confirmed the packet was divided when I set "ATT_MTU"=158 and "DLE"= 137. Additionally, division of a packet doesn't occur anytime.

We checked consumption current from an oscilloscope. The data was sent by 2 packets. But the packet interval of this data is very short. And the data was sent by 1 packet at receiving side.

1.Why does division of a packet occur?

2.The 2nd packets is empty?

[Ulrich Myhre]

The maximum length of a logical ATT PDU is ATT_MTU long (so for HVN, the actual data payload is ATT_MTU-3 long due to handle + opcode).

The maximum length of an on-air PDU is DLE_LEN long. Since 4 bytes are used for the L2CAP header (length + channel identificator), you should set DLE to be ATT_MTU+4.

In your setup, MTU is 158 and DLE is 137. For an HVN or write command, that will be divided into two PDUs as follows:

PDU #1: L2CAP Header (4) | ATT Header (3) | ATT payload (130)
PDU #2: ATT payload (28)

So you get some saving with high ATT_MTU by not sending multiple headers, but by increasing the DLE length it should be sent as one PDU.

[Adrian Eggenberger]

Hi Ulrich

If I understand this correctly an optimal throughput in both directions can be reached by using GATT Characteristics with a variable length and send data by using GATT Notifications or GATT Write Commands with a length of the DLE length - 7. Is this correct?

[Ulrich Myhre]

The DLE Length must be at least ATT_MTU + 4. Then any ATT payload will be sent as a single PDU. The length of the data you send cannot exceed (ATT_MTU - ATT_Header), as the API call will fail. ATT_Header size depends on the PDU type, and can be seen in the Bluetooth Spec. It's 3 bytes for HVN/HVI, Write Command and Write Request, but 5 for Prepare Write Request.

[Adrian Eggenberger]

Ok. So far I understand. I've created an example with two nRF52 DK's to test this features, but I've two issues. The establish of the connection works properly and the DLE seams also to be fine. It results in 251Bytes and 2120us in both directions.

1. In the direction from peripheral (GATTS) to central I'm sending notifications with a length of 244 Bytes. The Softdevice confirms the call of sd_ble_gatts_hvx but if I check on the central side only 20 bytes are in every notification. I've also checked this with sniffer and the ATT packets contain only 20 bytes.
2. In the other direction the situation is even worse. Calling the function sd_ble_gattc_write to initiate a command write with a length of 244 bytes failes with error code NRF_ERROR_DATA_SIZE.

I've no clue what's going wrong. I've tested this with S132 4.0.4 and S132 5.0.0 with the same result on both.

[Ulrich Myhre]

Stupid question maybe, but are you also initiating an ATT MTU exchange before this? Are you giving a proper length to the hvx call? (Should be agreed MTU size minus 3). It sounds like your hvx call is still just requesting to notify about 20 bytes, and the other side is doing it correctly, but the ATT MTU exchange prodecure has not yet completed.