Bluetooth Stack Implementation Considerations (Windows Embedded CE 6.0)
1/6/2010
The following are some implementation considerations you should keep in mind:
- Only one Bluetooth controller is supported.
- L2CAP links over unreliable channels are not supported. See the note on isochronous channels below. Flush timeout is not supported by L2CAP, upper layers are supposed to fail the connection when Flush Timeout is non-default, or it should negotiate it down to default.
- L2CAP does not support dynamic reconfiguration. Dynamic reconfiguration allows the system to enter CONFIG mode when a connection has already been opened. There is no appropriate way to reasonably communicate the change or handle this state using Winsock APIs.
Note on isochronous channels and unreliable Baseband connections.
Isochronous channels are unreliable data channels when packets are dropped because they cannot be delivered within a certain time interval. They are typically used for audio and video data transmissions. Isochronous transfers in Bluetooth are implemented over ACL (asynchronous channels), and not SCO (synchronous channels) because ACL has a bigger data throughput. SCO channels are limited to 56Kbps.
Typically, a baseband connection over Bluetooth is reliable. An ACL link is responsible for repeating the message until it is acknowledged, and failing the connection if the acknowledgement does not arrive within the configured time.
However, it also allows specifying a flush timeout, in which packets that have not been delivered are flushed. Undelivered packets are flushed by the Bluetooth controller. However, information returned by the controller on flush does not allow the determination of which data packet has been flushed; therefore, requiring the application to add its own checks. This allows implementation of isochronous communications over Bluetooth.
This introduces the following problems. An asynchronous baseband connection is shared by all logical connections between two devices, multiplexed by L2CAP, and at a higher layer, again, by RFCOMM.
L2CAP does not introduce any protection against data loss, deferring it to an application, even though it protects its own packets by implementing a request-response scheme with transaction IDs. The L2CAP also does not expose any failure to deliver data packet to the user application. This forces all upper layer protocols to be prepared to run over an unreliable link.
However, RFCOMM explicitly cannot function in an unreliable setting because it defines only the basic option of TS7.10. There is no windowing or error recovery on RFCOMM, no user data protection, and it cannot be deferred to the application because the data is streamed. The basic option also defines that the link MUST be failed in case of any command packet loss, which it does protect against. This, therefore, precludes baseband links sharing between isochronous transmissions and practically any other user data.
The only option left for implementing isochronous channels is establishing and managing a baseband link by creating a custom stack layer that is hosted on top of the HCI.
This stack cannot be a generic incoming connection handler. It must allow incoming connections only from well-known Bluetooth addresses, or device classes.
A baseband connection established by this layer will be owned the layer. Because there is only one baseband connection between two devices, all layers above and including the L2CAP stack is disabled by this connection for the duration of the physical connection.