• State Not Answered
  • Replies 5 replies
  • Subscribers 25 subscribers
  • Views 157 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 289796
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs

Supported L2CAP modes in SoftDevice

user95905

Hi,

I'm trying to understand which of the BT L2CAP modes are supported for a BT LE Controller. BT Core 5.3 supports these modes of operation:

  • 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

From this post on TI forum, I can see that support for "Basic L2CAP Mode" and "LE Credit Based Flow Control Mode" should be possible for a BT LE Controller. Looking at the S113 API for the L2CAP (in documentation of sd_ble_l2cap_ch_setup()) shows that only "LE Credit Based Flow Control Mode" is currently supported.

Which of the L2CAP modes are by definition not supported on top of a BT LE Controller? And which one are supported by the S113?

Thanks,

Louis

Parents Reply Children
  • 0 in reply to user26071

    Hi Edvin,

    Thanks for you quick reply.

    We want to achieve a reliable transmission of big data packet (e.g.: 16kB) with the best possible through-output by relying as much as possible on Bluetooth standard. L2CAP Le Credit Based Flow Control mode provides only packets receipt acknowledgement. Using another L2CAP mode with packet fragmentation/reassembly should allow to not have to define a custom fragmentation/reassembly protocol on top of BLE.

    However, I didn't found a clear description on the BT Core specification if such a configuration is even possible.

  • 0 in reply to user95905

    That is not the softdevice supports, at least. I see that there are some questions regarding this on DevZone from time to time, but most of them are from a time where you had very low throughput on BLE.

    What sort of transfer speed are you looking for? Using standard BLE services characteristics can give you up to ~1.3Mbps of payload under ideal conditions. 

    I see that there are a few functions related to L2Cap, which you can find on Infocenter. But I don't see how this would allow you to not define a custom fragmentation/reassembly protocol. (You wouldn't have to do it on top of BLE, but there is no file transfer protocol in L2CAP either).

    Whether you are able to use L2CAP also depends on what your connected device is. Is it another nRF chip, or is it a phone/pc?

    BR,

    Edvin

  • 0 in reply to user26071

    Thanks for the extra clarifications.

    Indeed, the L2CAP API provided by the Softdevice only provides access to the  "LE Credit Based Flow Control Mode", which doesn't help for packed fragmentation/reassembly.

    > What sort of transfer speed are you looking for?

    We don't have a specific target yet, just experimenting on how better can a L2CAP oriented connection be.

    > Whether you are able to use L2CAP also depends on what your connected device is. Is it another nRF chip, or is it a phone/pc?

    The peer device would be an iOS or Android phone. Which of the nRF chip/ phone-pc option won't be possible?

    Regards,

    Louis

  • 0 in reply to user95905
    loumay said:

    The peer device would be an iOS or Android phone. Which of the nRF chip/ phone-pc option won't be possible?

    That depends on the bluetooth stack running on the connected device, how much or whether the stack gives access to the L2CAP layer. Whether it actually is that much faster I am not sure either. 

    I would say that unless you are on the very limit of the speed, I would go with normal BLE, which is easier, and more widely supported. 

    Other than that, the functions from the link in the previous reply is the only L2CAP layer that is exposed to the application. 

Related
Terms of service