Bluetooth protocol (RFCOMM, L2CAP and ACL)

Question

From what I've read from Bluetooth Essentials for Programmers, this books mentions some points that I dont quite understand.

RFCOMM is a reliable stream-based protocol. L2CAP is a packet-based protocol that can be configured with varying levels of reliability.

L2CAP actually serves as the transport protocol for RFCOMM, so every RFCOMM connection is actually encapsulated within an L2CAP connection.

This really confuses me since these two protocol are different types of protocols (one is stream based while the other is packet based). So based on its explanation, I have some questions in the following.

1. Since RFCOMM connection is encapsulated, then how serial port profile(SPP) can use RFCOMM connection? It should use L2CAP as well.

2. A2DP uses L2CAP connection. This means the same to me since L2CAP and RFCOMM are encapsulated within ACL connection, should this mean A2DP uses ACL connection? I know this is incorrect but how to explain this here.

Thanks for any explanation here.

Sievers

The site is for coders, not the type of questions you are asking here, they are not bad questions they just don't fit in SO. – Fatso

Thanks. I think these questions are also related to bluetooth programmers. It will be great if you can explain questions above. – Sievers

The encapsulation could be at the "device" driver level so it would be invisible to you, its like you never "created" an ethernet packet, but you still able to use TCP/IP natively, how come? same thing here, RFCOMM uses L2CAP, but doesn't mean you need to know L2CAP to use – Fatso

Ok, you mean the programmer only needs to create rfcomm and we dont have to know that RFCOMM is encapsulated in L2CAP. Thanks for your explanation. Bases on what you mentioned and what I've read from the book, I dont understand why RFCOMM needs to be encapsulated in L2CAP. Say SPP, this could purely use RFCOMM connection. What advantage in this encapsulation? – Sievers

Usually encapsulation is used when you don't want to hassle with something else, in this case they didn't want to hassle with the signalling issue, RFCOMM is used for Serial interface, so they didn't want to handle the signalling issue of Serial interfaces – Fatso

Hi, Can you reply in the answer part instead of adding comment here? So I can check your reply as the answer for this question. So you mean the basic design idea for the encapsulation is to help RFCOMM doesnt get any signal issue in this case. This is a good explanation but can you explain this in more detail way or provide me an example why the encapsulation is needed? Thanks a lot. – Sievers

RMFCOMM is not encapsulated in L2CAP AFAIK. RFMCOMM uses L2CAP for it's lower layer communication so it encapuslates L2CAP. – Doorn

Hey, @nrathaus sometimes playing cop backfires, based on the number of likes to the comment following yours above. Were it not for stack overflow I wouldn't have had such a prominent hit to my query about L2CAP, and I'm interested because I want to start coding for the bluetooth stack. So thanks to SO and thanks to Sam who posted the question. – Schiller

Answer 1

The encapsulation could be at the "device" driver level so it would be invisible to you, its like you never "created" an Ethernet packet, but you still able to use TCP/IP natively, how come? same thing here, RFCOMM uses L2CAP, but doesn't mean you need to know L2CAP to use.

Usually encapsulation is used when you don't want to hassle with something else, in this case they didn't want to hassle with the signalling issue, RFCOMM is used for Serial interface, so they didn't want to handle the signalling issue of Serial interfaces

Fatso

Hi, would you mind provide one more example about why the encapsulation is needed? Could you explain this in more detail way? Thanks. – Sievers

Nice answer @nrathaus. OOP encapsulates all all kinds of things and the class makes the mechanisms opaque. You could even have two objects of the same class communicating a protocol without ever seeing the underlying protocol in action but be able to to utilize a derived service. – Schiller