Bluetooth and BLE: What It Is, Difference Between Classic and Low Energy, and How It Works

What Is Bluetooth and BLE?

Bluetooth is a wireless personal area network (WPAN) standard operating in the 2.4 GHz ISM band, designed for device communication at distances of up to 100 meters. The IEEE 802.15.1 specification defines the physical and MAC layers, while the Bluetooth SIG stack defines upper-level profiles for specific scenarios: audio headsets (HSP), file transfer (OPP), keyboard input (HID).

The standard split into two branches since version 4.0 (2010): Bluetooth Classic (BR/EDR — Basic Rate / Enhanced Data Rate) and Bluetooth Low Energy (BLE, formerly Bluetooth Smart). Classic is designed for continuous streams — audio calls, music, files. BLE was created for applications where data is transmitted in short packets with pauses of tens of seconds or minutes — heart rate monitors, tags, temperature sensors.

According to Bluetooth SIG (2025), 99% of new smartphones support both versions, and the BLE ecosystem includes more than 15 profile types from Blood Pressure to Environmental Sensing.

Bluetooth Classic vs BLE: Comparison

The choice between Classic and BLE depends on the scenario: for audio streaming only Classic is suitable, for polling a sensor once an hour — only BLE. BR/EDR uses 79 channels with 1 MHz spacing and adaptive frequency hopping (AFH), providing resistance to Wi-Fi interference.

BLE 5.x added LE Coded PHY for increased range up to 1 km (in open areas) and LE Audio with LC3 codec — the new version is gradually blurring the boundary between Classic and BLE for audio scenarios.

BLE Architecture: Controller, Host and Application

The BLE stack is divided into three layers: Controller (physical and link layers), Host (L2CAP, ATT, GATT, Security Manager), and Application (profile implementation in the app). This separation allows the chip manufacturer to implement the Controller in firmware, while the mobile app developer works only with GATT abstractions.

The Link Layer (LL) manages air time: the device switches between Standby, Advertising, Scanning, Initiating, and Connection states. In the Connected state, Central and Peripheral agree on a connection interval — the frequency at which they exchange data packets. A typical interval is 7.5–1000 ms; the more frequent the exchange, the higher the throughput and greater the power consumption.

The Security Manager (SM) implements AES-128 encryption with key exchange through the pairing protocol. There are three modes: Just Works (no PIN entry), Passkey Entry (6-digit code on screen), and OOB (NFC or QR). For wearable devices, Just Works is typically used; for medical devices, OOB with additional verification is used.

According to the Bluetooth Core Specification 5.4 (2023), the secure connection setup time in LE Secure Connections mode does not exceed 300 ms at a connection interval of 30 ms.

GATT Profile: Services, Characteristics and Descriptors

The ATT (Attribute Protocol) is the basic transport model where the server (peripheral device) stores attributes and the client (smartphone) reads or writes them. GATT (Generic Attribute Profile) builds a hierarchy on top of ATT: Service → Characteristic → Descriptor.

Each service is a logical group of characteristics describing one device function: Heart Rate Service (UUID 0x180D) contains the Heart Rate Measurement characteristic (UUID 0x2A37) with a Client Characteristic Configuration Descriptor (0x2902) that controls notifications. A mobile app developer gets the list of services through discoverServices(), then finds the required characteristic by UUID and subscribes to notifications.

BLE uses 16-bit UUIDs for standardized Bluetooth SIG services and 128-bit UUIDs for custom manufacturer services. For example, a tracker case can define a service A000-… with a characteristic for transmitting its battery charge level.

Example of working with GATT in Kotlin (Android)

private val gattCallback = object BluetoothGattCallback() {
    override fun onServicesDiscovered(
        gatt: BluetoothGatt, status: Int
    ) {
        val service = gatt.getService(UUID.fromString("0000180d-0000-1000-8000-00805f9b34fb"))
        val char = service?.getCharacteristic(
            UUID.fromString("00002a37-0000-1000-8000-00805f9b34fb")
        )
        gatt.setCharacteristicNotification(char, true)
    }

    override fun onCharacteristicChanged(
        gatt: BluetoothGatt, char: BluetoothGattCharacteristic
    ) {
        val heartRate = char.getIntValue(BluetoothGattCharacteristic.FORMAT_UINT8, 1)
        updateUi("Pulse: $heartRate bpm")
    }
}

In the example, the app finds the Heart Rate service by the standard Bluetooth SIG UUID, gets the heart rate measurement characteristic, and subscribes to its notifications — whenever the heart rate changes, the peripheral device sends data without an explicit request from the Central.

Advertising, Scanning and Connection Setup

Advertising is a key BLE mechanism where a Peripheral device periodically broadcasts advertising PDUs on three primary channels (37, 38, 39). The central device scans these channels, receives advertising data, and can initiate a connection.

An advertising packet contains up to 31 bytes of payload: flags, TX power level, local name, service UUIDs, manufacturer-specific data. This is enough to transmit sensor readings without establishing a connection — Connectionless mode (Broadcaster type). For continuous data transmission (e.g., temperature once per minute), a connection with a connection interval of up to 1000 ms is used.

On mobile platforms, scanning is started via startScan() (Android) or scanForPeripherals() (iOS). Filtering by service UUID saves energy by not processing all visible devices — the app receives a callback only for relevant tags or sensors.

Example of scanning BLE devices in Swift (iOS)

import CoreBluetooth

class ScannerViewController: UIViewController {
    private var centralManager: CBCentralManager!

    override func viewDidLoad() {
        centralManager = CBCentralManager(
            delegate: self, queue: nil
        )
    }

    func centralManagerDidUpdateState(central: CBCentralManager) {
        if central.state == .poweredOn {
            centralManager.scanForPeripherals(
                withServices: nil, options: nil
            )
        }
    }

    func centralManager(
        central: CBCentralManager,
        didDiscover peripheral: CBPeripheral,
        advertisementData: [String : Any],
        rssi RSSI: NSNumber
    ) {
        if let name = advertisementData[CBAdvertisementDataLocalNameKey] {
            print("Device found: \(name)")
        }
    }
}

After discovering a device, the Central calls connect(), passing the CBPeripheral object. Connection parameters (interval, latency, supervision timeout) are negotiated at the Link Layer level — the developer does not manage them directly but can influence them via requestConnectionPriority on Android.

Bluetooth LE in Mobile Development: Core Bluetooth and android.bluetooth

Both mobile platforms provide native APIs for working with BLE. Core Bluetooth (iOS) uses a delegate approach: the central manager initiates operations, and the peripheral object reports results through delegate methods. android.bluetooth (Android) is built on callback interfaces and supports parallel GATT operations with multiple devices.

Key differences between the platforms:

• iOS — supports up to 7 simultaneous connections; background BLE mode requires UIBackgroundModes = bluetooth-central; after leaving the foreground, the system may delay callbacks by several minutes
• Android — no fixed connection limit (limited by memory); requires BLUETOOTH_SCAN and BLUETOOTH_CONNECT permissions (Android 12+); a foreground service is needed for reliable background scanning
• Flutter — the flutter_blue_plus package abstracts platform APIs with a unified Dart interface: code for scanning and GATT operations is identical on both platforms

According to Bluetooth SIG tests (2024), the BLE connection time between a smartphone and a fitness tracker averages 150–300 ms on Android and 100–250 ms on iOS — the difference is due to radio module management policies.

Example of BLE connection in Dart (Flutter)

import 'package:flutter_blue_plus/flutter_blue_plus.dart';

class BleService {
  final FlutterBluePlus fbp = FlutterBluePlus();

  Future<void> scanAndConnect(String deviceName) async {
    await fbp.startScan(timeout: Duration(seconds: 15));

    await for (final result in fbp.scanResults) {
      if (result.device.advName == deviceName) {
        await fbp.stopScan();
        await result.device.connect();
        break;
      }
    }
  }
}

A Flutter developer gets a unified API interface, under the hood flutter_blue_plus translates calls to native android.bluetooth or Core Bluetooth. This approach reduces app development time for working with BLE peripherals on both platforms.