When BLE devices started appearing in stores, consumers faced a confusing situation. They could see “Bluetooth” logos on boxes but could not tell which products would actually work together. A classic Bluetooth headset and a BLE fitness tracker both say “Bluetooth” but they cannot communicate directly at all.

The Bluetooth SIG created two specific trademarks to fix this confusion and give consumers a clear visual signal of compatibility:

The third Smart Ready requirement explained: If you buy a new Bluetooth Smart glucose meter, you should be able to download an app on your Smart Ready smartphone to receive its data. The device does not need to be replaced — the phone gets new software. This requirement ensures Smart Ready devices stay compatible with future Smart devices through software updates.

Consider a hospital patient monitoring scenario. A patient at home has a BLE thermometer strapped to their arm. The mobile phone of a family member acts as the hub:

The phone streams music to the headset over classic Bluetooth at the same time as collecting temperature readings from the BLE thermometer. It then forwards those readings to the hospital server over the internet. One device, two simultaneous Bluetooth connections of different types, plus an internet connection.

A common misconception is that BLE is just “classic Bluetooth with the power turned down.” It is not. Achieving years of battery life from a coin cell is not something you can accomplish by optimising a few parameters in an existing radio stack.

Classic Bluetooth devices like a wireless keyboard or headset use larger batteries and need recharging every few days or weeks. To get to the “months to years” range requires completely different thinking at every level — the radio, the packet format, the connection process, the protocol stack, and even the application model. BLE rebuilds all of these from the ground up with power as the primary constraint, while still being robust, secure, and globally usable.

BLE uses the same 2.4 GHz ISM (Industrial, Scientific and Medical) band as classic Bluetooth. This band is free to use worldwide without a licence, which is why Bluetooth, Wi-Fi, ZigBee, and microwave ovens all operate in it. BLE uses frequency hopping to avoid being disrupted by the other technologies sharing this crowded band.

However, the way BLE uses the band is meaningfully different from classic Bluetooth:

The advertising channels are placed at 2402 MHz, 2426 MHz, and 2480 MHz — deliberately spread apart and positioned to avoid the three most-used Wi-Fi channels (1, 6, 11), which reduces interference significantly. Having only 3 channels for advertising is the key to BLE’s fast connection time, as explained next.

/* From BlueZ — BLE advertising channel frequencies (hci.h) */
/* BLE uses channels 37, 38, 39 for advertising */
#define LE_ADV_CHAN_37    2402  /* MHz */
#define LE_ADV_CHAN_38    2426  /* MHz */
#define LE_ADV_CHAN_39    2480  /* MHz */

/* Check which LE features are supported by your adapter */
/* Using hcitool in terminal: */
/* hcitool cmd 0x08 0x0003  (LE Read Local Supported Features) */

The single most important design decision in BLE is what could be called the “mostly off” principle. A BLE device is expected to have its radio powered down the overwhelming majority of the time, switching on only in brief moments when it actually has something to send.

This is a completely different operational model from classic Bluetooth, where a connected device stays active continuously — periodically waking up to exchange polling packets even when there is no real data to exchange.

The key metric that describes this behaviour is duty cycle — the ratio of time-on to total time. Classic Bluetooth devices have a high duty cycle. BLE devices have a duty cycle that is close to zero. This is not a side effect of BLE — it is a deliberate design target that drives every other design decision in the standard.

When a BLE device wakes up and needs to send data, it should be able to connect, transmit, and disconnect as quickly as possible — because every millisecond the radio is on costs battery life.

Classic Bluetooth uses 32 channels for its inquiry and paging (connection discovery) process. A scanning device has to hop through all 32 channels to find another device. With 32 channels to check, a typical connection takes around 20 milliseconds.

BLE uses only 3 dedicated advertising channels for device discovery and connection initiation. A scanner only needs to listen on 3 channels. This makes connections dramatically faster:

A 3-millisecond connection time means the complete cycle of connect → send data → disconnect takes only 3 to 4 milliseconds total. Compare this to a classic Bluetooth headset that may stay connected to a phone for several days, waking up every few hundred milliseconds in sniff mode to check for incoming data. That continuous wake-up cycle drains the headset battery even when nobody is talking.

With BLE the device stays completely asleep. When it has data, it wakes up, connects in 3 ms, sends in <1 ms, disconnects, and goes back to sleep. Total energy expenditure: negligible.

/* Starting a BLE scan with BlueZ from C code */
/* This is equivalent to running: sudo hcitool lescan */

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

/* Enable LE scanning on the adapter */
int enable_le_scan(int sock)
{
    /* scan_type: 0x01 = active scan (requests scan response)
                  0x00 = passive scan (listens only)
       interval and window in units of 0.625 ms
       filter_dup: 1 = filter duplicate advertisers */
    return hci_le_set_scan_parameters(sock,
        0x01,       /* scan type: active */
        htobs(0x0010), /* scan interval: 10ms */
        htobs(0x0010), /* scan window:   10ms */
        0x00,       /* own address: public */
        0x00,       /* filter: accept all */
        1000);      /* timeout ms */
}

Every feature in a protocol stack costs memory to implement, silicon area to build, and power to run. BLE’s designers made a deliberate decision to remove every feature that was not needed for the target use cases — short, infrequent data transfers between low-power sensors and hubs.

This is not a limitation due to technical inability. It is a carefully considered trade-off. By removing features that BLE devices will never need, the resulting stack is simpler, cheaper to build, requires less memory, and uses less power. The six key removals are covered in full detail in Part 3 of this series.

Each of these removals is explained in full detail in Part 3, with the exact power and complexity savings each one provides.