Peripheral — co to jest, rola w BLE i jak reklamuje usługi

Czym jest Peripheral w BLE?

Peripheral — to urządzenie BLE, które implementuje serwer GATT i reklamuje swoje możliwości przez kanały advertisingowe. W przeciwieństwie do Central, które aktywnie szuka urządzeń, Peripheral pasywnie oczekuje na połączenie. Jest to asymetryczny model, zoptymalizowany pod kątem efektywności energetycznej urządzeń zasilanych bateryjnie.

Peripheral może znajdować się w kilku trybach: advertising (reklama), connected (podłączony do Central), sleeping (uśpienie z wyłączoną reklamą). W trybie advertising Peripheral okresowo wysyła krótkie pakiety danych, zużywając przy tym minimalną energię. Po podłączeniu Peripheral przechodzi w tryb connected, gdzie wymienia dane z Central zgodnie z uzgodnionym connection interval.

Według Bluetooth Core Specification 5.4 (2023), urządzenie może dynamicznie przełączać się między rolami Peripheral i Central, ale w każdym momencie dla jednego połączenia rola jest ustalona. Typowy scenariusz: czujnik IoT stale pracuje w roli Peripheral, a smartfon zarządza połączeniem jako Central.

Dla programisty ważne jest zrozumienie: Peripheral określa, jakie usługi i charakterystyki są dostępne, i zarządza dostępem do nich. Struktura serwera GATT na Peripheral określa, jakie dane Central może odczytać i jakie polecenia może zapisać.

Proces reklamy (Advertising)

Advertising (reklama) — to mechanizm, za pomocą którego Peripheral informuje o swojej obecności. Peripheral wysyła pakiety advertisingowe na trzech wydzielonych kanałach (37, 38, 39) w interwale od 20 ms do 10.24 sekund. Każdy pakiet reklamowy zawiera stałe informacje i może zawierać opcjonalne dane.

Istnieją dwa typy pakietów reklamowych: advertising PDU (pakiet podstawowy) i scan response PDU (odpowiedź na zapytanie Central). Pakiet podstawowy zawiera obowiązkowe pola: typ pakietu, adres nadawcy, dane. Jeśli Central wyśle scan request, Peripheral odpowiada dodatkowym pakietem z pełniejszą informacją — na przykład pełną nazwą urządzenia.

Parametry advertising wpływają na szybkość wykrywania i pobór mocy. Advertising interval — czas między wysyłką pakietów. Im krótszy interwał, tym szybciej Central wykryje urządzenie, ale tym więcej energii zużywa Peripheral. Zalecany interwał: 100–1000 ms dla większości urządzeń.

Struktura pakietu reklamowego

Pakiet reklamowy BLE ma ograniczenie 31 bajtów dla advertising PDU i kolejne 31 bajtów dla scan response. Wewnątrz pakietu dane są zorganizowane w formacie AD Structure (Advertising Data Structure): każde pole ma typ (1 bajt), długość (1 bajt) i wartość.

Najczęściej używane AD Type: Flags (0x01) — tryby połączenia i wykrywania, Local Name (0x08 lub 0x09) — nazwa urządzenia, Service UUID List (0x02–0x07) — lista UUID usług, Manufacturer Specific Data (0xFF) — dane producenta. Prawidłowe upakowanie danych w 31-bajtowym pakiecie to ważne zadanie dla programisty urządzeń wbudowanych.

Dla urządzeń, które potrzebują przesłać więcej danych, istnieje extended advertising (BLE 5.0+), który zwiększa rozmiar pakietu reklamowego do 251 bajtów i dodaje nowe typy pakietów. Extended advertising obsługuje również kanały z kodowaniem (coded PHY) w celu zwiększenia zasięgu do 1 km na otwartym terenie.

Projektując pakiet reklamowy, uwzględnij: im więcej danych w pakiecie advertisingowym, tym większe prawdopodobieństwo kolizji z innymi urządzeniami. Dla szybkiego wykrywania zaleca się umieszczanie tylko krytycznych danych (Service UUID) w advertising PDU, a dodatkowych danych — w scan response.

Peripheral jako serwer GATT

Serwer GATT na Peripheral zawiera wszystkie usługi i charakterystyki, które Central może wykryć i z którymi może współdziałać. Po podłączeniu Central wykrywa usługi (discover services), następnie charakterystyki (discover characteristics) i współdziała z nimi przez protokół GATT.

Peripheral jako serwer GATT musi poprawnie przetwarzać żądania od Central: odczyt (read request), zapis (write request), powiadomienia (notification) i potwierdzone powiadomienia (indication). Każde żądanie przechodzi przez tabelę GATT, gdzie każdemu atrybutowi (usłudze, charakterystyce, deskryptorowi) odpowiada Handle — 16-bitowy adres.

Programista Peripheral określa prawa dostępu do każdego atrybutu: tylko odczyt, tylko zapis, odczyt i zapis, z szyfrowaniem lub bez. Dla poufnych danych (informacje osobiste, parametry medyczne) zaleca się wymuszanie szyfrowania przez MITM Protection.

Peripheral w iOS: CBPeripheralManager

CBPeripheralManager — klasa Core Bluetooth do implementacji roli Peripheral na iOS. Zarządza serwerem GATT, publikuje usługi i charakterystyki, przetwarza żądania od Central. W przeciwieństwie do CBCentralManager, CBPeripheralManager nie skanuje — tylko reklamuje i obsługuje połączenia.

Główne kroki implementacji Peripheral na iOS: inicjalizacja CBPeripheralManager, dodawanie usług przez add, uruchamianie reklamy przez startAdvertising, obsługa żądań od Central przez delegata CBPeripheralManagerDelegate.

import CoreBluetooth

class BLEPeripheralManager: NSObject, CBPeripheralManagerDelegate {

    private var peripheralManager: CBPeripheralManager!

    func startAdvertising() {
        let advertisementData: [String: Any] = [
            CBAdvertisementDataLocalNameKey: "BLE Sensor",
            CBAdvertisementDataServiceUUIDsKey: [
                CBUUID("180F")
            ]
        ]
        peripheralManager.startAdvertising(advertisementData)
    }

    func peripheralManagerDidUpdateState(
        _ peripheral: CBPeripheralManager
    ) {
        if peripheral.state == .poweredOn {
            startAdvertising()
        }
    }
}

iOS pozwala Peripheral działać w trybie tła przy obecności klucza bluetooth-peripheral w Background Modes. W tle iOS może reklamować się z ograniczonym zestawem danych i obsługiwać połączenia. Do długotrwałej reklamy (powyżej 180 sekund) użyj opcji CBAdvertisementDataWaitForResponseFromCentral w celu oszczędzania energii.

Peripheral w Android: BluetoothLeAdvertiser

Android udostępnia BluetoothLeAdvertiser do pracy w roli Peripheral (od API 21). API umożliwia uruchamianie reklamy z konfigurowalnymi parametrami: moc nadajnika, interwał reklamy, dane pakietu. Android obsługuje również extended advertising (BLE 5.0) na zgodnych urządzeniach.

import android.bluetooth.le.*;

private BluetoothLeAdvertiser advertiser;

public void startPeripheral() {
    BluetoothAdapter adapter =
        BluetoothAdapter.getDefaultAdapter();
    advertiser = adapter.getBluetoothLeAdvertiser();

    AdvertiseData data = new AdvertiseData.Builder()
        .setIncludeDeviceName(true)
        .addServiceUuid(
            new ParcelUuid(
                UUID.fromString("0000180F-0000-1000-8000-00805F9B34FB")
            )
        )
        .build();

    AdvertiseSettings settings = new AdvertiseSettings.Builder()
        .setAdvertiseMode(AdvertiseSettings.ADVERTISE_MODE_LOW_POWER)
        .setTxPowerLevel(AdvertiseSettings.ADVERTISE_TX_POWER_MEDIUM)
        .build();

    advertiser.startAdvertising(
        settings, data, advertiseCallback
    );
}

Na Androidzie obsługa Peripheral zależy od producenta i wersji systemu. Nie wszystkie urządzenia obsługują BluetoothLeAdvertiser — sprawdzaj przez adapter.isMultipleAdvertisementSupported(). Od Androida 10 do pracy w roli Peripheral wymagane jest uprawnienie BLUETOOTH_ADVERTISE, a także zapytanie runtime dla aplikacji z target SDK 31+.

Efektywność energetyczna Peripheral

Efektywność energetyczna — kluczowa zaleta BLE, a Peripheral odgrywa w tym główną rolę. Urządzenie może pracować na baterii CR2032 (220 mAh) ponad rok dzięki zoptymalizowanemu poborowi mocy. Większość czasu Peripheral spędza w trybie uśpienia z wyłączoną reklamą, budząc się tylko w celu wysłania pakietu reklamowego lub obsługi żądania od Central.

Pobór mocy Peripheral w różnych trybach: tryb uśpienia (deep sleep) — 1–5 µA, idle z włączonym timerem — 10–50 µA, advertising — 5–15 mA (na czas wysyłki pakietu), connected — 5–10 mA (na czas connection event). Przy advertising interval 1000 ms i czasie trwania pakietu 4 ms, średni prąd wynosi około 50–100 µA.

Według Texas Instruments Application Report (SWRA478, 2024), optymalizacja advertising interval ze 100 ms do 1000 ms zmniejsza średni pobór mocy o 90%. Dodatkowe oszczędności osiąga się przez użycie slave latency (pomijanie connection events), zmniejszenie Tx Power przy krótkich dystansach i wyłączenie reklamy po podłączeniu (connectable advertising).