Bluetooth Serial Port Communication (SPP)

Question

We are working on an application that will use SPP (Serial Port Profile) over Bluetooth and the developers are debating using some type of protocol and packet delivery, versus just streaming the data without any form of ACK, sequence, or size information.

Does Bluetooth provide the guaranteed delivery and data integrity, so that we do not need the overhead of a packet protocol design?

Can we rely on just Bluetooth to ensure the data was delivered?

Fitting

This answer is in the context of Android but applies more generally to SPP. – Rifling

Thanks! That was helpful! :) – Fitting

Answer 1

Is delivery guaranteed?

The order of the delivery is guaranteed.
This is due to the acknowledgement/sequence numbering scheme built in to the lower-layers of bluetooth protocol. So at a lower layer a packet is re-transmitted until it is acknowledged.

Note that this is equivalent to stop and wait ARQ scheme. If it takes more than a timeout, then the connection is considered as lost (generally 30 seconds).

Is data integrity guaranteed?

Bluetooth 4.2 introduced BT secure connection. This includes a Message Integiry Check(MIC) with each transmitted packet and a MIC mismatch at the receiving end will trigger a re-transmission and a number of MIC mismatches might disconnect the connection.
So if you are not using Secure Connection feature, then integrity is not guaranteed.

There is a 16 bit CRC scheme used to protect data, but it is known that over long time period there is going to be CRC escapes (bit flips in such a way that CRC remains correct). But this is relatively rare and happens in a noisy environment. If your application requires very high data integrity then either use SecureConnection or introduce Application Level Integrity checks.

Note that SPP Profile in itself does not have any error/sequence checking, RFCOMM has a 8 bit FCS (Frame Check Sequence) which checks for header corruption. L2CAP streaming/Retransmission mode has an optional 16-bit FCS which covers L2CAP header and data. Note that the basic L2CAP mode does not have FCS at all.

If you have an option to enable L2CAP FCS then you have a 16bit CRC at lower-level + 16 bit FCS at the L2CAP layer + 8 bit FCS at RFCOMM level will provide a data integrity which is good enough for most applications. However as mentioned earlier if it is really critical then you need to introduce additional Application Level Integrity checks.

Snivel

Answer 2

In essence BT has its own safety mechanisms for transfer. However, and this is just as important - in order for YOU to know when data starts and ends you should use a packet type transmission, such as STX and ETX to delimit each packet.

There are dongles that adhere to the bad habit of repeating the last sent byte if there is a time lapse in the transmission, but they will stop when ETX or EOT in encountered.

And, for your system safety, you might as well include a checksum at the end of the packet. Then you are pretty sure.

Jointure