At the time BLE was standardised (Bluetooth 4.0, 2010), there were already billions of classic Bluetooth devices in active use. Virtually every smartphone, laptop, tablet, and PC shipped with Bluetooth. The BLE designers understood that any new technology that broke existing compatibility would be rejected by the industry.

BLE is designed so that a dual-mode device (which supports both BR/EDR and BLE) is fully backward compatible with all existing classic Bluetooth devices. A phone that upgrades to Bluetooth 4.0 can still pair with the Bluetooth 2.1 headset that the user has been using for years — nothing breaks. At the same time, the phone gains the new ability to communicate with BLE sensors and beacons.

This compatibility is not accidental — it required careful engineering decisions:

• The BLE radio operates in the same 2.4 GHz ISM band as BR/EDR but uses different channels and modulation, so the two radios do not interfere with each other.
• Dual-mode devices share one Bluetooth device address for both radios, so other devices see one unified “Bluetooth device” not two separate ones.
• Protocol layers like L2CAP, HCI, and GAP are shared and extended — not replaced — in dual-mode implementations, reducing the engineering work for manufacturers.

Like classic Bluetooth, BLE uses a layered protocol stack. Each layer has a specific job. Data flows up the stack on the receiving side and down the stack on the sending side. The key difference from classic Bluetooth is the addition of the ATT and GATT layers, which replace the complex profile-specific protocols used in BR/EDR with a single unified data model.

The introduction of ATT (Attribute Protocol) and GATT (Generic Attribute Profile) is the most significant architectural change compared to classic Bluetooth. In classic Bluetooth, every profile (A2DP, HFP, OPP, etc.) defines its own complete protocol behaviour from scratch. This leads to huge amounts of repeated code across profiles.

In BLE, ATT defines a simple data model: the device is a server that holds a list of attributes. Each attribute has a type (UUID), a handle (index), permissions, and a value. GATT builds on ATT and organises attributes into Services and Characteristics. All BLE profiles sit on top of GATT and just define which services and characteristics they use — the heavy lifting is already done.

/* BlueZ GATT - reading a characteristic value from a BLE peripheral */
/* This is equivalent to using gatttool on command line: */
/* gatttool -b 00:1A:7D:DA:71:13 --char-read -a 0x0025 */

/* From BlueZ gatt.h — GATT characteristic structure */
struct gatt_characteristic {
    uint16_t handle;          /* attribute handle in server's table */
    uint16_t value_handle;    /* handle of the value attribute */
    uint8_t  properties;      /* READ, WRITE, NOTIFY flags */
    bt_uuid_t uuid;           /* standard or vendor-specific UUID */
};

/* GATT characteristic properties (flags in the 'properties' byte) */
#define GATT_CHR_PROP_BROADCAST    0x01  /* can broadcast value */
#define GATT_CHR_PROP_READ         0x02  /* can read value      */
#define GATT_CHR_PROP_WRITE_NO_RSP 0x04  /* write without ack   */
#define GATT_CHR_PROP_WRITE        0x08  /* write with ack      */
#define GATT_CHR_PROP_NOTIFY       0x10  /* server can push updates */
#define GATT_CHR_PROP_INDICATE     0x20  /* server push + ack   */

Understanding how the three configurations relate to each other is important for anyone working on Bluetooth products. The dual mode architecture is not simply a concatenation of the two stacks — several layers are shared, which reduces the total implementation effort.

In dual mode implementations, the shared layers (HCI, L2CAP, GAP) reduce total code size. Manufacturers who already have a working BR/EDR stack only need to add the BLE-specific layers on top, rather than building a completely separate stack.

This is the definitive reference table from the chapter. Every row is followed by a brief explanation so students understand not just what the difference is but why it exists.

/* BLE Security — checking encryption state via BlueZ HCI */
/* AES-128 encryption is negotiated during the pairing/bonding process */

/* The Security Manager handles:
   - Pairing:  establishing a shared key between two devices
   - Bonding:  storing that key so reconnection is faster
   - Encryption: using AES-128 to encrypt all data PDUs */

/* From BlueZ hci.h — encryption change event */
typedef struct {
    uint8_t  status;           /* 0x00 = success */
    uint16_t handle;           /* connection handle */
    uint8_t  encrypt;          /* 0x00=off, 0x01=on (AES-128 CCM) */
} __attribute__((packed)) evt_encrypt_change;

/* To enable encryption on a BLE connection using bluetoothctl: */
/* bluetoothctl                                                  */
/* [bluetooth]# pair 00:1A:7D:DA:71:13                          */
/* Pairing successful                                            */
/* [bluetooth]# trust 00:1A:7D:DA:71:13                         */
/* Link is now encrypted with AES-128                           */

This chapter covered the complete fundamentals of Bluetooth Low Energy. Here is a consolidated summary of every key concept:

BLE offers two major benefits: it extends the Bluetooth ecosystem by being backward compatible in dual-mode devices, and it enables an entirely new category of product — ones that run for years on tiny batteries. The next chapters will go deeper into each protocol layer, explaining exactly how the link layer, L2CAP, ATT, GATT, and the Security Manager each work to deliver on these promises.