Bluetooth i BLE: co to jest, różnica między Classic a Low Energy i jak działa

Czym są Bluetooth i BLE?

Bluetooth — to standard bezprzewodowej sieci osobistej (WPAN) działający w paśmie ISM 2,4 GHz i przeznaczony do łączności między urządzeniami w odległości do 100 metrów. Specyfikacja IEEE 802.15.1 określa warstwę fizyczną i MAC, a stos Bluetooth SIG definiuje profile wyższego poziomu dla konkretnych scenariuszy: zestawów słuchawkowych (HSP), przesyłania plików (OPP), wprowadzania danych z klawiatury (HID).

Standard został podzielony na dwie gałęzie od wersji 4.0 (2010): Bluetooth Classic (BR/EDR — Basic Rate / Enhanced Data Rate) i Bluetooth Low Energy (BLE, wcześniej Bluetooth Smart). Classic jest przeznaczony do ciągłych strumieni — połączeń audio, muzyki, plików. BLE został stworzony dla aplikacji, w których dane są przesyłane krótkimi pakietami z przerwami rzędu dziesiątek sekund lub minut — pulsometry, znaczniki, czujniki temperatury.

Według Bluetooth SIG (2025), 99% nowych smartfonów obsługuje obie wersje, a ekosystem BLE obejmuje ponad 15 typów profili od Blood Pressure po Environmental Sensing.

Bluetooth Classic vs BLE: porównanie

Wybór między Classic a BLE zależy od scenariusza: do strumieniowego przesyłania audio nadaje się tylko Classic, do odczytu czujnika raz na godzinę — tylko BLE. BR/EDR wykorzystuje 79 kanałów z krokiem 1 MHz i adaptacyjną modulację częstotliwości (AFH), zapewniając odporność na zakłócenia Wi-Fi.

BLE 5.x dodał LE Coded PHY w celu zwiększenia zasięgu do 1 km (na otwartym terenie) oraz LE Audio z kodekiem LC3 — nowa wersja stopniowo zaciera granicę między Classic a BLE w scenariuszach audio.

Architektura BLE: Controller, Host i Application

Stos BLE jest podzielony na trzy warstwy: Controller (warstwa fizyczna i łācza), Host (L2CAP, ATT, GATT, Security Manager) i Application (implementacja profilu w aplikacji). Takie rozdzielenie pozwala producentowi układu zaimplementować Controller w firmware, a programiście aplikacji mobilnej — pracować tylko z abstrakcjami GATT.

Link Layer (LL) zarządza czasem nadawania: urządzenie przełącza się między stanami Standby, Advertising, Scanning, Initiating i Connection. W stanie Connected Central i Peripheral uzgadniają connection interval — częstotliwość wymiany pakietów danych. Typowy interwał wynosi 7,5–1000 ms; im częstsza wymiana, tym większa przepustowość i wyższe zużycie energii.

Security Manager (SM) implementuje szyfrowanie AES-128 z wymianą kluczy przez protokół pairing. Wyróżnia się trzy tryby: Just Works (bez wprowadzania PIN), Passkey Entry (6-cyfrowy kod na ekranie) i OOB (NFC lub QR). W przypadku urządzeń noszonych zwykle używa się Just Works, a w medycznych — OOB z dodatkową weryfikacją.

Według Bluetooth Core Specification 5.4 (2023), czas nawiązania bezpiecznego połączenia w trybie LE Secure Connections nie przekracza 300 ms przy connection interval równym 30 ms.

Profil GATT: usługi, charakterystyki i deskryptory

Protokół ATT (Attribute Protocol) — podstawowy model transportowy, w którym serwer (urządzenie peryferyjne) przechowuje atrybuty, a klient (smartfon) je odczytuje lub zapisuje. GATT (Generic Attribute Profile) nadbudowuje nad ATT hierarchię: Service → Characteristic → Descriptor.

Każda usługa to logiczna grupa charakterystyk opisująca jedną funkcję urządzenia: Heart Rate Service (UUID 0x180D) zawiera charakterystykę Heart Rate Measurement (UUID 0x2A37) z Descriptor Client Characteristic Configuration (0x2902) zarządzającym powiadomieniami. Programista aplikacji mobilnej pobiera listę usług przez discoverServices(), następnie znajduje potrzebną charakterystykę po UUID i subskrybuje powiadomienia.

BLE używa 16-bitowych UUID dla standaryzowanych usług Bluetooth SIG i 128-bitowych UUID dla niestandardowych usług producenta. Na przykład etui-śledzik może zdefiniować usługę A000-… z charakterystyką do przesyłania poziomu naładowania własnej baterii.

Przykład pracy z GATT w 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("Tętno: $heartRate ud/min")
    }
}

W przykładzie aplikacja znajduje usługę Heart Rate po standardowym UUID Bluetooth SIG, pobiera charakterystykę pomiaru pulsu i subskrybuje jej powiadomienia — przy każdej zmianie pulsu urządzenie peryferyjne wysyła dane bez jawnego żądania ze strony Central.

Advertising, skanowanie i nawiązywanie połączenia

Advertising — kluczowy mechanizm BLE, w którym urządzenie Peripheral okresowo wysyła pakiety rozgłoszeniowe (advertising PDUs) na trzech głównych kanałach (37, 38, 39). Urządzenie centralne skanuje te kanały, odbiera dane advertisingowe i może zainicjować połączenie.

Pakiet advertisingowy zawiera do 31 bajtów użytecznego ładunku: flagi, TX power level, nazwę lokalną, UUID usług, dane producenta. To wystarcza do przesyłania odczytów z czujnika bez nawiązywania połączenia — tryb Connectionless (typ Broadcaster). Do ciągłego przesyłania danych (np. temperatury co minutę) używa się połączenia z connection interval do 1000 ms.

Na platformie mobilnej skanowanie uruchamia się przez startScan() (Android) lub scanForPeripherals() (iOS). Filtrowanie po UUID usługi pozwala nie marnować energii na przetwarzanie wszystkich widocznych urządzeń — aplikacja otrzymuje callback tylko dla interesujących ją znaczników lub czujników.

Przykład skanowania urządzeń BLE w 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("Znaleziono urządzenie: \(name)")
        }
    }
}

Po wykryciu urządzenia Central wywołuje connect(), przekazując obiekt CBPeripheral. Parametry połączenia (interval, latency, supervision timeout) są uzgadniane na poziomie Link Layer — programista nie zarządza nimi bezpośrednio, ale może wpływać przez requestConnectionPriority na Androidzie.

Bluetooth LE w tworzeniu aplikacji mobilnych: Core Bluetooth i android.bluetooth

Obie platformy mobilne udostępniają natywne API do pracy z BLE. Core Bluetooth (iOS) używa podejścia delegowanego: menedżer centralny inicjuje operacje, a obiekt peryferyjny informuje o wynikach przez metody delegowane. android.bluetooth (Android) jest zbudowany na interfejsach callback i obsługuje równoległe operacje GATT z wieloma urządzeniami.

Kluczowe różnice między platformami:

• iOS — obsługuje do 7 równoczesnych połączeń; tryb tła BLE wymaga wpisu UIBackgroundModes = bluetooth-central; po wyjściu z tła system może opóźnić callbacki o kilka minut
• Android — nie ma stałego limitu połączeń (ograniczenie pamięciowe); wymaga uprawnień BLUETOOTH_SCAN i BLUETOOTH_CONNECT (Android 12+); foreground service jest niezbędny do niezawodnego skanowania w tle
• Flutter — pakiet flutter_blue_plus abstrahuje platformowe API za pomocą jednolitego interfejsu Dart: kod do skanowania i operacji GATT jest identyczny na obu platformach

Według testów Bluetooth SIG (2024), czas połączenia BLE smartfona z opaską fitness wynosi średnio 150–300 ms na Androidzie i 100–250 ms na iOS — różnica wynika z polityk zarządzania modułem radiowym.

Przykład podłączenia BLE w 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;
      }
    }
  }
}

Programista Flutter otrzymuje jednolity interfejs API, pod którym flutter_blue_plus tłumaczy wywołania na natywne android.bluetooth lub Core Bluetooth. Takie podejście skraca czas tworzenia aplikacji do pracy z peryferiami BLE na obu platformach.