The 22% overhead in 4.0 means that for every 27 bytes the radio sends, only about 21 bytes is your actual data. In 4.2, the same 6 bytes of overhead is spread across 251 bytes, so 98% of what goes over the air is your real data. This is a big win for battery life and transfer speed.

Once a BLE device ships and is deployed in the field — inside a building, on a factory floor, in a patient’s home — the manufacturer may need to push a software update. Sending the new firmware over the air (OTA) is far more convenient than physically collecting every device.

With 27-byte packets, the radio must stay on for the entire duration of the transfer — which could be several minutes depending on firmware size. Every extra minute the radio stays powered on costs battery. With 251-byte packets, the same firmware transfers in a fraction of the time, the radio shuts off sooner, and the battery lasts much longer.

A secondary benefit: packets are only sent at connection intervals, and there is dead time (silence) between intervals. The more packets are required to complete a transfer, the more of these dead-time gaps are needed, stretching the total transfer time further. Bigger packets reduce the number of intervals needed, shrinking the total active time.

A common BLE use case is a sensor tag that continuously records data and then uploads it in bulk. Consider a wearable health monitor that records body temperature and heart rate every minute throughout a full day — that is 1,440 readings. Even at just 4 bytes per reading, you need to transfer about 5.7 KB of log data.

With 27-byte packets you need over 200 individual packets to upload this. With 251-byte packets you need only about 23. The difference in upload time and energy is dramatic, especially for a device running on a coin cell battery.

When data is too large to fit in a single packet, the transmitter must break it into multiple fragments. The receiver must collect all fragments and reassemble them into the original data. This fragmentation and reassembly has a cost beyond just extra packets:

• Processing time: The CPU must run fragmentation and reassembly logic, consuming power for each operation.
• Connection interval gaps: BLE only sends packets at scheduled connection intervals. Between intervals the radio is off. The more fragments you have, the more intervals you need, and the longer the total transfer stretches across time.
• Radio stays on longer: The device remains powered and active across all those intervals, draining the battery more than a single large packet would.

Larger packets reduce or eliminate fragmentation for most real-world data transfers, making the device both faster and more power-efficient at the same time.

When the link layer sends data, the raw payload does not go straight to the radio antenna. It passes through three processing steps in sequence. On the receiving side the same three steps are applied in reverse order. Understanding this pipeline is important because the order of these steps was deliberately chosen to save power — and BLE’s order is different from classic Bluetooth.

Encryption is performed first on the transmit side. It is not always applied — only when the host has specifically requested an encrypted connection (for example, after pairing with a key exchange). If encryption is not enabled, this step is simply skipped and the raw payload moves on to CRC generation.

BLE uses AES-128 in CCM mode (Counter with CBC-MAC). The result is an encrypted payload plus the 4-byte MIC (Message Integrity Check) appended to it. On the receive side, decryption is the last step — after the CRC check has already passed.

/* Checking if a BLE connection is encrypted via BlueZ HCI */
/* After pairing, the host gets an Encryption Change event */

/* Listen for HCI Encryption Change event (event code 0x08) */
/* From BlueZ hci.h: */
typedef struct {
    uint8_t  status;    /* 0x00 = success                       */
    uint16_t handle;    /* connection handle                    */
    uint8_t  encrypt;   /* 0x00 = off, 0x01 = AES-128 CCM on   */
} __attribute__((packed)) evt_encrypt_change;

/* Using bluetoothctl to initiate pairing (triggers encryption): */
/* bluetoothctl                                                   */
/* [bluetooth]# pair AA:BB:CC:DD:EE:FF                           */
/* [bluetooth]# Pairing successful                               */
/* Connection is now encrypted with AES-128                      */

After encryption, the 24-bit CRC is computed over the encrypted payload. The CRC travels with the packet. On the receive side, after dewhitening, the CRC is recomputed and compared against the transmitted value. If they match, the packet is good. If not, it is dropped immediately without even attempting decryption.

Why does BLE do CRC after encryption (not before)? This is a deliberate reversal from classic BR/EDR. In BR/EDR, CRC is computed before encryption, so on the receive side you must decrypt first and then CRC-check. BLE flips this — CRC is computed on the encrypted data, so you can CRC-check before decrypting. This gives three power-saving advantages explained below.

The final step before transmission is whitening. The purpose is to avoid long runs of the same bit — for example 00000000000 or 11111111111 — in the transmitted data. If the radio sends a long run of identical bits, the receiver’s synchronisation circuit (which uses bit transitions to stay locked to the timing) can lose lock and misread subsequent bits.

Whitening works by XOR-ing the data with a whitening word — a pseudo-random sequence generated from the channel index. XOR-ing with a random-looking sequence breaks up any long runs without permanently changing the data. The receiver uses the exact same whitening word to XOR again, which perfectly reverses the process and recovers the original data.

/* BLE data whitening — LFSR-based scrambling */
/* The whitening sequence is generated from the RF channel index */
/* From BlueZ net/bluetooth/ble_core.c concept: */

/* Channel index is loaded as initial value of a 7-bit LFSR */
/* The LFSR polynomial is: x^7 + x^4 + 1                    */
void ble_whiten(uint8_t *data, int len, uint8_t channel_idx)
{
    /* Initialise 7-bit LFSR with channel index (bit 6 always 1) */
    uint8_t sr = (channel_idx & 0x3F) | 0x40;

    for (int i = 0; i < len; i++) {
        uint8_t byte = data[i];
        for (int b = 0; b < 8; b++) {
            int out_bit  = sr & 1;       /* output bit        */
            int feedback = out_bit ^ ((sr >> 3) & 1); /* taps */
            sr = (sr >> 1) | (feedback << 6);
            byte ^= (out_bit << b);      /* XOR with data bit */
        }
        data[i] = byte;
    }
    /* Note: dewhitening uses the SAME function with the SAME key */
    /* XOR is self-inverse: (A XOR K) XOR K = A                  */
}

In BR/EDR the order is: CRC → Encrypt → Transmit on the send side, and Receive → Decrypt → CRC check on the receive side. BLE reverses the CRC and encryption steps. This might seem like a small detail, but it produces three concrete power-saving benefits: