Why is BLE 4.2 faster than BLE 4.1

Question

I've read the tech spec and I am trying to understand why BLE 4.2 is faster than BLE 4.1?

Can we send a larger packet size than 20 bytes or is the connection interval faster?

I am trying to understand what makes BLE 4.2 faster.

Answer 1

The only thing in Bluetooth 4.2 which gives higher throughout compared to earlier is the length extension of the link layer. It makes it possible to send data pdus with a length of 251 bytes instead of 27 bytes which was the limit before. Previously it meant a large overhead if you sent multiple packets due to header sizes and the time required between an rx and tx packet and again from tx to rx. The data itself is sent with 1 MBit/s over the air.

Note that both sides need to support this new feature and the new max length must be negotiated between the devices before it can be used.

Here I will explain a typical connection event while a central writes multiple GATT Write command packets of 20 bytes each. Since the transfer rate is 1 MBit/s over the air, it takes 1 μs per bit to be transferred. The link layer headers and footers are in total 80 bits, consisting of the following: 1 byte preamble + 4 access address (stuff to identify the packet to the correct destination). 1 byte containing flow/ack and data type. 1 byte containing length of packet. Then comes the data followed by a 3 byte CRC checksum. A user data packet itself is wrapped in an ATT packet (3 byte header with opcode and ATT handle) which is in turn wrapped in an L2CAP packet (2 byte channel ID and 2 byte length). So the 20 byte large packet has now became 37 bytes that is sent over the air. Over the air, master and slave alternates between sending and receiving. So if master sends many data packets but slave has nothing to send, the slave must still respond with an empty packet with 80 bits of header. Also, between all packets, there must be a radio silence for 150 μs in order to give the radios time to switch between RX and TX. So a connection event of 4 packets filled with 20 bytes of user data each looks like the following: 1. Master -> Slave: 296 μs 1st packet 2. Silence 150 μs 3. Slave -> Master: 80 μs empty packet 4. Silence 150 μs 5. Master -> Slave: 296 μs 2nd packet 6. Silence 150 μs 7. Slave -> Master: 80 μs empty packet 8. Silence 150 μs 9. Master -> Slave: 296 μs 3rd packet 10. Silence 150 μs 11. Slave -> Master: 80 μs empty packet 12. Silence 150 μs 13. Master -> Slave: 296 μs 4th packet 14. Silence 150 μs 15. Slave -> Master: 80 μs empty packet All this adds up to 2554 μs

With the new packet length extension we can send the same 80 bytes in one packet (still overhead of 17 bytes header + CRC) = 97 bytes = 776 bits.

1. Master -> Slave: 776 μs packet 2. Silence 150 μs 3. Slave -> Master: 80 μs empty packet

This adds up to only 1006 μs, more than twice as fast as before! The radio is now available to serve connection events from another connection.

As you see, the throughput is increased. But for this new feature to be useful, you need to make sure you fill up your connection event with packets. You can of course send the same amount of data during one connection event faster but if you just idle the rest of the time before the next connection event you don't really send the data faster.