L2CAP Connection-Oriented Channel (CoC) - how is it different then HVX?

[Dave_couling]

Hi all,

I was recently asked about using L2CAP Connection-Oriented Channel (CoC) to increase thru-put of a project.  This must be a gap in my knowledge as L2CAP was always just a layer in the Stack, not a specific feature.  I can't really find much documentation on how CoC works or how its different from regular HVX calls.   It seems to suggest that the Channels are fixed, but I assume thats a virtual channel not the physical Connection RF channels.  When/why would you use L2CAP Connection-Oriented Channel (CoC) and does it have higher throughput than Notification+MTU+DLE based data pipeline?

Regards

DC

[ovrebekk]

Hi 

Communicating over L2CAP COC channels basically means you are bypassing the host protocol (GATT in the case of BLE) and communicating with the link layer directly, which does remove some of the overhead. 

That being said, the overhead of running GATT if you use data length extension is very small, as the only impact of GATT is a 3 byte header at the start of every packet. If you maximize the data length you can send 244 user bytes in each packet, while with a L2CAP COC packet you should be able to send 247 bytes of user data in each packet. 

My recommendation would be to stick to normal GATT unless you have a very good reason to go for an L2CAP COC solution. As I mentioned the difference in throughput will be small, and if you utilize extended data length and the 2M PHY you should be able to achieve in excess of 1.3Mbps over a normal BLE GATT connection. 

Best regards
Torbjørn