In classic Bluetooth, every device must have both a transmitter and a receiver. This is fine for devices like phones and laptops that genuinely need to both send and receive data. But many IoT sensor devices only ever need to send data — they never need to receive anything at all.

A weighing scale, for example, just measures weight and sends it to your phone. The scale never needs to receive any data back. In classic Bluetooth that scale would still have to include a full receiver circuit, which means more silicon, more cost, and more power drain — all for hardware the device will never use.

BLE makes transmitter and receiver each optional. A device can implement:

A TX-only device has roughly half the radio silicon of a full device. Less silicon means lower manufacturing cost, smaller physical size, and less current draw — directly extending battery life.

Classic Bluetooth supports SCO (Synchronous Connection-Oriented) and eSCO (Enhanced SCO) link types specifically for real-time voice calls. These are the reason your classic Bluetooth headset can transmit your voice continuously and in sync with the other end of the call.

Implementing SCO/eSCO adds significant complexity. The protocol needs guaranteed time slots, specific error handling for voice data, and synchronisation mechanisms that keep both ends in lockstep. All of this requires memory, logic, and power.

BLE is simply not designed for voice calls. Its target devices — sensors, monitors, beacons — have no need to transmit continuous audio streams. Removing SCO/eSCO entirely strips away a large chunk of protocol complexity and the power that complexity consumes. If a product needs Bluetooth voice calling it should use classic Bluetooth, not BLE.

In classic Bluetooth, a piconet is a group of devices where one acts as master and up to 7 others act as slaves. A scatternet is when a device participates in multiple piconets simultaneously — acting as a slave in one and a master in another, bridging them together.

Scatternet support adds real complexity. A device in multiple piconets needs to manage multiple timing schedules, hop between different frequency sequences, and handle role transitions — all of which requires a significantly more complex link layer state machine and more memory to track all the state.

BLE removes scatternet support entirely. A BLE device participates in only one piconet at a time. This dramatically simplifies the link layer implementation. And — importantly — it imposes no practical restriction, because a BLE piconet has no hard limit on the number of slaves. While classic Bluetooth limits a piconet to 7 active slaves, BLE allows as many slaves as the master’s hardware resources can support.

Classic Bluetooth allows a Master and Slave to swap roles after a connection is established — the Slave can request to become the Master and vice versa. This flexibility was useful in some BR/EDR scenarios but it added real complexity: the link layer needed to handle all the state transitions and timing renegotiation that a role switch required.

BLE removes role switching completely. When a BLE connection is made, the device that initiates the connection becomes the Central (Master) and the device that accepts the connection becomes the Peripheral (Slave). These roles are fixed for the lifetime of that connection.

This is not a problem in practice because in BLE there is always a clear and natural role assignment: the phone is always the Central and the sensor is always the Peripheral. Nobody needs to swap. Removing role switch simplifies the link layer state machine significantly and removes a class of bugs and edge cases that classic Bluetooth implementations had to handle.

In classic Bluetooth, maintaining a connection requires constant effort. Even when there is absolutely no user data to exchange, the master device continuously sends POLL packets to each slave, and the slaves respond with NULL packets just to confirm they are still alive and in sync. This keep-alive chatter happens every few hundred milliseconds without pause.

This continuous exchange burns battery on both ends. Classic Bluetooth does have sniff mode to reduce polling frequency, but it still requires periodic exchanges.

BLE takes a different approach. Once a connection is established, the two devices share timing, frequency hopping, and access address parameters. As long as the link layer remains synchronised on these parameters, the devices are considered “connected” — even without exchanging any packets. There is no polling traffic. Devices simply stay quiet until they have real data to exchange.

This is like two people agreeing to call each other at exactly 9am every morning. If nobody has news, the call does not happen — but the agreement is still in place. They are still “in contact” without burning time talking about nothing.

Classic Bluetooth defined special low-power modes: sniff mode (the device wakes up periodically to check for incoming data) and park mode (the device disconnects from the active piconet but stays synchronised). These modes were a retrofit — power-saving features bolted onto a protocol that was not designed with power in mind from the start.

BLE does not need these modes because the entire connection model is already designed around minimal activity. The default BLE behaviour — connect briefly, exchange data, disconnect — achieves better power savings than sniff mode ever could. There is no idle state that needs to be made more efficient because there is no idle state at all. The device simply turns off.

Key insight: Classic Bluetooth added power-saving modes on top of a high-power protocol. BLE started with power saving as the fundamental design constraint and never needed a separate mode for it.

BLE uses much shorter packets than classic Bluetooth. The maximum BLE packet payload in Bluetooth 4.0 is just 27 bytes. Classic Bluetooth supports packets up to 1021 bytes (in DH5 format). Bluetooth 4.2 raised the BLE maximum to 251 bytes, still far smaller than classic.

Shorter packets save power in two ways that students sometimes overlook:

For BLE use cases this size is more than sufficient. A heart rate reading is a single integer — maybe 2 bytes of data. A temperature reading is 4 bytes. A door sensor state is 1 bit. The 27-byte limit is never a constraint for the sensor applications BLE is designed for.

/* BLE packet structure in BlueZ (from hci.h) */
/* A BLE data PDU consists of: */
/* - 1 byte  : LLID (2 bits) + NESN (1) + SN (1) + MD (1) + RFU (3) */
/* - 1 byte  : Length field (payload length, 0-27 for BLE 4.0)       */
/* - 0-27    : Payload data                                           */
/* - 3 bytes : CRC (24-bit, stronger than BR/EDR 16-bit CRC)         */

/* Reading BLE advertising data with BlueZ: */
/* Each advertising report gives you the AD structures (payload)      */
typedef struct {
    uint8_t  evt_type;   /* event type (connectable, non-connectable) */
    uint8_t  bdaddr_type;/* public or random address */
    bdaddr_t bdaddr;     /* 6-byte Bluetooth address */
    uint8_t  length;     /* length of data[] below (max 31 bytes) */
    uint8_t  data[31];   /* advertising payload: flags, name, services */
} __attribute__((packed)) le_advertising_info;

Students often think of memory as a storage concern, not a power concern. But in embedded systems, memory directly affects power consumption in two ways:

• Silicon area: More memory = larger chip = higher manufacturing cost. For coin-cell devices, minimizing chip size is essential.
• Current for retention: SRAM (dynamic memory) needs a constant supply of current to hold its contents. Every byte of SRAM that is allocated and filled draws power continuously, even when the processor is idle. ROM and Flash do not have this problem — they hold their contents without needing power.

BLE uses four specific techniques to minimize its dynamic memory requirements:

BLE operates on a fundamental asymmetry: the peripheral (sensor) and the central (hub) have very different power situations, and the protocol should respect that difference.

Peripherals — sensors, monitors, beacons — have tiny batteries, limited processing power, and no ability to recharge frequently. The mobile phone or tablet acting as the central is charged every day and has a large battery. It makes no sense to optimise power consumption equally for both. The protocol should place the energy burden on the central and spare the peripheral as much as possible.

There is another important insight here about transmitting versus receiving. In radio physics, transmitting consumes less power than receiving. A receiver needs to keep its circuitry active and sensitive at all times to detect incoming signals. A transmitter just needs a brief burst of energy to send its packet.

BLE exploits this by designing peripherals to mostly transmit (advertise their data) while the central mostly receives (scans). This keeps the peripheral in the lower-power mode of operation. In the weighing scale example, the scale may not even have a receiver at all — it only transmits its weight measurement when you step on it.

/* Setting up BLE advertising from a peripheral device using BlueZ */
/* This is the low-level HCI command equivalent to hciconfig hci0 leadv */

#include <bluetooth/bluetooth.h>
#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>

int start_advertising(int hci_socket)
{
    le_set_advertising_parameters_cp adv_params;
    memset(&adv_params, 0, sizeof(adv_params));

    /* Advertise every 100ms — a reasonable balance of discoverability
       and power consumption (lower interval = more power, faster discovery) */
    adv_params.min_interval = htobs(0x00A0); /* 100ms */
    adv_params.max_interval = htobs(0x00A0); /* 100ms */
    adv_params.chan_map      = 0x07; /* use all 3 advertising channels */
    adv_params.filter_policy = 0x00; /* allow all devices to see us */

    /* Submit the command to the HCI layer */
    return hci_send_cmd(hci_socket,
                        OGF_LE_CTL,
                        OCF_LE_SET_ADVERTISING_PARAMETERS,
                        LE_SET_ADVERTISING_PARAMETERS_CP_SIZE,
                        &adv_params);
}

Once a BLE connection is established, the two devices share three critical parameters: the timing schedule (when to listen for packets), the frequency hopping sequence (which channel to use next), and the access address (the unique identifier that differentiates this connection from others sharing the air).

As long as both devices remain synchronised on these three parameters, they are considered “connected” — even if no packets have been exchanged for a while. Neither device needs to send anything just to prove the connection is still alive.

BLE does define a Connection Supervision Timeout — a maximum time interval that, if exceeded without any packet exchange, causes both devices to consider the connection lost and clean up their state. But this timeout is measured in seconds or tens of seconds, not milliseconds. It is a safety net, not a polling mechanism.