L2CAP SDU Length

[Torsten Robitzki]

L2CAP connection oriented channels can be used to transfer frames of up to 65533 bytes. L2CAP is a record oriented protocol. When receiving L2CAP data, using the softdevice API, we can pass smaller buffers to the SD, using sd_ble_l2cap_ch_rx() and get notified when data arrives. That's perfectly fine for stream oriented protocols.

Is there a way, I can get the information about the frame size of the current frame (not just the segment), that is received? The background of my question is: I would like to implement a record oriented protocol over l2cap. So I need to know, where a frame starts. I could probably add some framing on my own, but this seems unnecessary as all required information is already there.

kind regards,

Torsten

[Kenneth]

I can see from the event that only a pointer to the buffer and a length is passed to the application, so you must handle this in some other way yes. I believe maybe the L2CAP packet only have 4 bytes overhead (length + channel ID), so likely the data you request is not available over-air.

[Torsten Robitzki]

I'm quite sure, the information (frame boundaries) are available over-air, because the spec says so ;-) Maybe, if this information is not made available by the softdevice, is there a chance that I could request that information as a feature request toward the softdevice? (in theory, an event denoting the frame start and frame size would be sufficient, I think)

[Torsten Robitzki]

UpUp :-)

[ovrebekk]

Hi Torsten

Sorry for the slow response. Kenneth is currently out in vacation, and I will handle your case in the mean time. 

Which part of the spec are you referring to?
Figure 3.6 in vol 3, part A, chapter 3.4?

If I understand correctly you want to assemble a larger packet manually by adding up smaller transfers over the air?

The ble_app_ots example in the SDK should work more or less the same way, I don't know if you have had a look at that?
The object transfer service is essentially designed to send files or records over an L2CAP COC channel, so it sounds relevant to what you are trying to do. 

Also, are you sure that using L2CAP COC is needed in the first place?
When using larger MTU's and attribute sizes the overhead when using standard GATT services over L2CAP COC is very small. 

Best regards
Torbjørn

[Torsten Robitzki]

Hello Torbjørn,
yes, in Vol. 3, 3.4 there is one figure that describes the frame layout of L2CAP connection-oriented channel SDUs (in Version 5.2. of the spec, it’s figure 3.12, but I think we are talking about the same here).

Sorry, I think I’ve missed, that there is already the "Total SDU length, in bytes.“ in the ble_l2cap_evt_ch_rx_t. This is exactly what I need to find the start / end of an SDU.

And yes, I totally agree with you, that in a perfect world, there should be nearly no use for L2CAP. However, in reality a lot of BLE controller stacks (like the ones from Apple) give no back pressure when writing to a characteristic, but just silently drop data and more important, don’t let you fully utilize a connection event.

I’m implementing a BLE SWD debug probe. It’s possible to upload with more than 80 kByte/s, using L2CAP. Currently I use some kind of OTS control point procedures, to write commands to the probe and use the L2CAP channel to send the data that belongs to the commands. Using this schema, it takes a whole connection event just to transfer the control point request. So I would like to prepend the control point request to the data SDU. This requires me to recognize the start of a SDU on the receiving side.

Thanks for your support!

Torsten