BLE L2CAP layer - segmentation vs fragmentation

Question

I have two questions for you, guys:

1. What is the difference between segmentation + reasembly and fragmentation + recombination in BLE L2CAP? After some research, I am not able to understand it.
2. Where can I find some theory about L2CAP in BLE excluding hard-written BL core specification?

Answer 1

To begin, note that L2CAP is originally an important part of Bluetooth Classic. L2CAP for Bluetooth Classic supports a wide range of functionality, such as connection requests, reliable packet transmission, unreliable packet transmission, retransmission, flow control, channel multiplexing, packet fragmenting, various signalling etc.

When BLE was created, channel multiplexing (for SMP and GATT) was needed, as well as a way to fragment packets when transporting over HCI and Link Layer. The easiest decision seems to have been to "shoehorn" BLE into the L2CAP specification.

This means that 95% of the L2CAP is irrelevant and not valid for BLE. It can also be very hard to read the L2CAP specification when only considering BLE, since it is not always clear if a particular section refers to only Bluetooth Classic, only BLE, or both.

That said, Fragmentation & Recombination is used in both Bluetooth Classic and BLE and refers to how an L2CAP frame must be split up into smaller fragments to fit packet length constraints at lower layers. Lower layers for BLE are HCI and Link Layer.

An L2CAP frame always contains a 4-byte header containing a 2-byte length and a 2-byte channel id. When splitting up a frame into multiple fragments, additional bits in the lower layer packet header indicate if a packet is the start of a new frame or a continuation of the previous frame. For every connection, all fragments belonging to a particular frame must be sent in sequence over the lower layer, i.e. it is not allowed to interleave GATT fragments of a frame with SMP fragments of a frame. This is due to there is no extra indication in continuation packets which frame this fragment belongs, so it must always be assumed the previous one. For Link Layer, this information is kept in the LLID field of the Link Layer data packet header. There are three possible settings:

1. LL Data PDU: Continuation fragment of an L2CAP message, or an Empty PDU.
2. LL Data PDU: Start of an L2CAP message or a complete L2CAP message with no fragmentation.
3. LL Control PDU.

LL Control PDUs implement the Link Layer control protocol and are unrelated to L2CAP. These packets are not sent directly over HCI.

The HCI layer similarly uses something called packet boundary flag. The HCI packet header for data packets includes the connection handle and the packet boundary flag.

Either the controller or the host can recombine L2CAP fragments. While of course mandatory for the host, it is optional for the controller. Recombination is simply done by accumulating fragments until the total length equals the length according to the header. This means that the start/continuation header is actually redundant in BLE since BLE only uses reliable transfers, but can still serve as a way of detecting boundary errors.

A controller that supports LE Data Length extension, can as an example receive multiple small fragments from the host over HCI and recombine these into one big Link Layer packet. A controller might also receive a large L2CAP packet from the host and then split it into multiple fragments to be sent over the Link Layer, if the remote device does not support the LE Data Length extension.

Now to Segmentation & Reassembly. This is a term used in Bluetooth Classic to be able to support large packets, and multiplexing these with other packets.

One problem with Fragmentation & Recombination is that a large packet will be sent in one chunk, reserving the whole link while this packet is being transmitted, since all fragments from one frame must be sent in sequence. L2CAP therefore uses the term SDU "service data unit" to describe a higher layer (large) packet. This packet can be "segmented" into several smaller L2CAP I-Frames which are then sent as usual, potentially using Fragmentation & Recombination, if needed. The previous problem is now solved since I-Frames from one SDU can be interleaved with I-Frames from another SDU. The L2CAP receiver host will then "reassemble" I-Frames into the original SDU. There can therefore exist multiple pending incoming incomplete SDUs.

In Bluetooth 4.2, Bluetooth L2CAP Connection oriented channels were created as an additional way to send data apart from GATT. This is a brand new section in L2CAP, but borrowing ideas from Bluetooth classic. The idea is again to be able to interleave large packets (SDUs) from different channels. A flow control mechanism is also implemented. Just as in Bluetooth classic, each SDU is split up into multiple frames, this time called K-frames. Every K-frame contains the channel identifier, so the receiver knows to which pending SDU this frame belongs. Note though, that if you read the specification carefully, you will see that this time this mechanism is not called Segmentation & Reassembly. It is not called anything at all, in fact. The Segmentation & Reassembly terminology is explicitly only defined for the various Bluetooth Classic modes, even though the principle is the same for BLE L2CAP CoCs.

I hope what I've written above suffices for L2CAP theory for BLE. Otherwise the best I can recommend is the Bluetooth core specification. But if you read the L2CAP chapter, try to identify first if the section you are reading has the word "LE" in it, as otherwise it might not be relevant. If it contains "BR/EDR", it is probably not relevant.

Answer 2

BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part A] page 140

...

Segmentation and Reassembly operations are only used in Enhanced Retransmission mode, Streaming mode, Retransmission mode, and Flow Control mode.

Thus Segmentation and Reassembly isn't used in BLE l2cap.

Answer 3

BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part A page 1031

2.4 MODES OF OPERATION L2CAP channels may operate in one of several different modes as selected for each L2CAP channel. The modes are: • Basic L2CAP Mode • Flow Control Mode • Retransmission Mode • Enhanced Retransmission Mode • Streaming Mode • LE Credit Based Flow Control Mode • Enhanced Credit Based Flow Control Mode

BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part A page 1032

LE Credit Based Flow Control Mode is used for LE L2CAP connection-oriented channels for flow control using a credit based scheme for L2CAP data (i.e. not signaling packets).

BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part A page 1131

Segmentation and Reassembly operations are only used in Enhanced Retransmission mode, Streaming mode, Retransmission mode, and Flow Control mode.

I don't read too new newspapers)) I think 5.2 is new enough?

In addition, I must note that real implementations, for example from TI, Infineon (Cypress), fully confirm this, i.e. meet the specification.

Do not thank.))