Advertising (reklama) — to mechanizm w Bluetooth Low Energy, za pomocą którego urządzenie Peripheral informuje o swojej obecności, przesyłając krótkie pakiety danych na trzech wydzielonych kanałach (37, 38, 39). Bluetooth Core Specification 5.4 (2023) definiuje dwa typy reklamy: connectable — urządzenie jest gotowe do połączenia, i non-connectable — używane przez beacon’y (Beacon), które tylko przesyłają dane bez nawiązywania dwustronnego połączenia. Parametry reklamy — interwał od 20 ms do 10.24 s, moc nadajnika od -20 do +10 dBm i typ pakietu — bezpośrednio wpływają na szybkość wykrycia urządzenia i jego zużycie energii, co jest krytycznie ważne przy opracowywaniu urządzeń IoT zasilanych bateryjnie.
Najważniejsze
Advertising (reklama) — to proces okresowego przesyłania krótkich pakietów danych, za pomocą którego urządzenie BLE informuje o swojej obecności i dostępności. W przeciwieństwie do klasycznego Bluetooth, gdzie wyszukiwanie urządzeń zajmuje sekundy, BLE advertising pozwala wykryć urządzenie w milisekundach, zużywając przy tym minimalną energię.
Architektura BLE dzieli urządzenia na dwie role: Peripheral (reklamuje się) i Central (skanuje). Peripheral wysyła pakiety advertisingowe, a Central skanuje kanał i podejmuje decyzję o połączeniu. Ten asymetryczny model to kluczowa zaleta BLE: urządzenie reklamujące zużywa energię tylko na wysyłanie krótkich pakietów, a nie na ciągłe nasłuchiwanie kanału.
Proces advertising składa się z trzech etapów: advertising event (wysłanie pakietu na wszystkich trzech kanałach), scan request/response (opcjonalna wymiana z Central) i connection request (inicjacja połączenia przez Central). Każdy etap jest zarządzany przez Bluetooth Controller na poziomie Link Layer.
BLE wykorzystuje 40 kanałów w paśmie 2.4 GHz, z których 37 (2402 MHz), 38 (2426 MHz) i 39 (2480 MHz) są wydzielone wyłącznie do advertising. Trzy kanały to kompromis między niezawodnością wykrywania a przepustowością: jeden kanał może być zajęty przez Wi-Fi lub inne zakłócenia, ale urządzenie zostanie wykryte na dwóch pozostałych.
Kanał 37 znajduje się obok kanału Wi-Fi 1, kanał 39 — obok kanału Wi-Fi 6, a kanał 38 znajduje się między nimi, w strefie minimalnych zakłóceń. Wybór trzech kanałów gwarantuje, że urządzenie zostanie wykryte nawet w warunkach gęstej atmosfery radiowej — na przykład w centrum handlowym z dziesiątkami punktów dostępu Wi-Fi.
Peripheral wysyła pakiet advertisingowy sekwencyjnie na wszystkich trzech kanałach — nazywa się to advertising event. Urządzenie centralne skanuje po jednym kanale na raz, przełączając się między nimi zgodnie z algorytmem zaimplementowanym w Bluetooth Controller. Prawdopodobieństwo wykrycia podczas jednego advertising event przy braku kolizji wynosi blisko 100%.
Bluetooth Core Specification definiuje kilka typów advertising PDU (Protocol Data Unit), każdy z własnym przeznaczeniem. Główne typy: ADV_IND (connectable undirected advertising) — standardowa reklama z możliwością połączenia, ADV_NONCONN_IND (non-connectable undirected advertising) — tylko reklama bez połączenia, ADV_SCAN_IND (scannable undirected advertising) — obsługuje scan request, ADV_DIRECT_IND (directed advertising) — reklama dla konkretnego Central.
ADV_IND — najpopularniejszy typ, używany w większości urządzeń BLE. Po otrzymaniu ADV_IND Central może wysłać connection request i nawiązać połączenie. ADV_NONCONN_IND jest używany przez beacon’y (Beacon): urządzenie się reklamuje, ale nie przyjmuje zapytań o połączenie — tylko jednokierunkowa transmisja danych.
| Typ PDU | Opis | Połączenie | Scan response |
|---|---|---|---|
| ADV_IND | Standardowa reklama | Tak | Tak |
| ADV_DIRECT_IND | Reklama dla konkretnego Central | Tak | Nie |
| ADV_NONCONN_IND | Bez połączenia (beacony) | Nie | Nie |
| ADV_SCAN_IND | Z obsługą skanowania | Tak | Tak |
| ADV_EXT_IND | Extended advertising (BLE 5.0) | Tak | Tak |
ADV_DIRECT_IND zawiera adres docelowego Central, co pozwala szybko nawiązać połączenie bez oczekiwania na skanowanie. Używany, gdy urządzenia już „znają” się nawzajem — na przykład po ponownym podłączeniu do wcześniej sparowanego smartfona. Ten typ zmniejsza zużycie energii, ponieważ nie wymaga reklamy na wszystkich kanałach.
Advertising interval — to czas między kolejnymi advertising events. Specyfikacja dopuszcza interwał od 20 ms do 10.24 s z krokiem 0.625 ms. Rzeczywisty interwał jest obliczany jako suma wartości stałej i losowego opóźnienia (0–10 ms), co zmniejsza prawdopodobieństwo kolizji między wieloma reklamującymi się urządzeniami.
Wybór interwału to balans między szybkością wykrycia a zużyciem energii. Przy interwale 20 ms urządzenie zostanie wykryte w ciągu 20–30 ms, ale średni prąd wyniesie około 1–2 mA. Przy interwale 1000 ms — wykrycie zajmie do 1 sekundy, ale średni prąd spadnie do 50–100 μA. Dla większości urządzeń IoT zalecany interwał to 200–1000 ms.
Według danych Texas Instruments Application Report SWRA478 (2024), zwiększenie advertising interval ze 100 ms do 1000 ms zmniejsza zużycie energii o 90%. Jeśli urządzenie nie wymaga natychmiastowego wykrycia (na przykład czujnik temperatury przesyłający dane raz na minutę), optymalny interwał to 1000–2000 ms.
Dodatkowy parametr — advertising timeout — maksymalny czas, przez który urządzenie się reklamuje. W iOS Peripheral automatycznie wyłącza reklamę po 180 sekundach w trybie tła. W Androidzie nie ma takiego ograniczenia, ale producenci mogą dodawać własne limity.
Scan Response — to dodatkowy pakiet danych (do 31 bajtów), który Peripheral wysyła w odpowiedzi na scan request od Central. Scan request jest wysyłany przez Central po otrzymaniu pakietu advertisingowego, jeśli potrzebuje więcej informacji przed połączeniem. Scan Response nie wymaga dodatkowej reklamy — jest wysyłany tylko na żądanie, oszczędzając kanał.
Typowy podział danych: w advertising PDU (31 bajtów) umieszczane są flagi (3 bajty), UUID usług (2–16 bajtów) i dane producenta (pozostałe bajty). W scan response przesyłana jest pełna nazwa urządzenia (do 28 bajtów) oraz dodatkowe UUID lub TX Power Level. Taki podział pozwala Central szybko filtrować urządzenia po UUID bez odczytywania scan response.
Projektując pakiet advertisingowy, należy uwzględnić: jeśli wszystkie 31 bajtów jest zajętych w advertising PDU, Central nie będzie mógł określić, czy urządzenie obsługuje scan response. Zaleca się pozostawienie przynajmniej 3–5 bajtów wolnych w advertising PDU na oznaczenie możliwości scan response.
Extended Advertising (BLE 5.0) — to rozszerzenie mechanizmu reklamy, które zwiększa rozmiar pakietu advertisingowego z 31 do 251 bajtów i dodaje nowe typy pakietów. Extended Advertising obsługuje również coded PHY do zwiększenia zasięgu łączności do 1 km na otwartym terenie oraz reklamę okresową (Periodic Advertising) do synchronizacji wielu Central.
Główne nowości: ADV_EXT_IND — extended advertising PDU, który może przesyłać do 251 bajtów danych w jednym pakiecie. Extended Advertising wykorzystuje kanały podstawowe (37, 38, 39) tylko do wskazania, na którym kanale wtórnym (0–36) przesyłane są pełne dane. Zmniejsza to obciążenie kanałów reklamowych i zwiększa ogólną przepustowość systemu.
Periodic Advertising — dodatkowy mechanizm, w którym Peripheral wysyła dane na kanałach wtórnych ze stałym interwałem, a Central może zsynchronizować się z tą sekwencją. Używany do usług wymagających regularnej aktualizacji danych — na przykład transmisja audio lub odczyty czujników w czasie rzeczywistym.
| Parametr | Standard BLE | Extended BLE 5.0 |
|---|---|---|
| Maks. rozmiar pakietu | 31 bajtów | 251 bajtów |
| Kanały | Tylko 37, 38, 39 | + wtórne 0–36 |
| Zasięg | Do 100 m | Do 1000 m (coded PHY) |
| Prędkość | 1 Mbps | 125 kbps – 2 Mbps |
| Periodic | Nie | Tak |
iOS (Core Bluetooth) udostępnia CBPeripheralManager do zarządzania reklamą. Parametry advertising ustawia się poprzez słownik advertisementData z kluczami CBAdvertisementDataLocalNameKey (nazwa urządzenia), CBAdvertisementDataServiceUUIDsKey (UUID usług), CBAdvertisementDataTxPowerLevelKey (moc). iOS automatycznie zarządza advertising interval i nie pozwala na ręczne ustawienie.
import CoreBluetooth
class AdvertiserManager: NSObject, CBPeripheralManagerDelegate {
private var peripheralManager: CBPeripheralManager!
func startBLEAdvertising() {
let data: [String: Any] = [
CBAdvertisementDataLocalNameKey: "BLE Beacon",
CBAdvertisementDataServiceUUIDsKey: [
CBUUID("180F")
],
CBAdvertisementDataIsConnectable: true
]
peripheralManager.startAdvertising(data)
}
}
Android (BluetoothLeAdvertiser) zapewnia bardziej szczegółową kontrolę. Dostępne są: AdvertiseSettings — ustawienia trybu (LOW_POWER, BALANCED, LOW_LATENCY), mocy nadajnika i interwału; AdvertiseData — dane pakietu. Android obsługuje extended advertising (BLE 5.0) na zgodnych urządzeniach, ale udział takich urządzeń na rynku wynosi około 30–40%.
BluetoothLeAdvertiser advertiser =
BluetoothAdapter.getDefaultAdapter()
.getBluetoothLeAdvertiser();
AdvertiseSettings settings = new AdvertiseSettings.Builder()
.setAdvertiseMode(
AdvertiseSettings.ADVERTISE_MODE_LOW_POWER
)
.setTxPowerLevel(
AdvertiseSettings.ADVERTISE_TX_POWER_MEDIUM
)
.build();
AdvertiseData data = new AdvertiseData.Builder()
.setIncludeDeviceName(true)
.addServiceUuid(new ParcelUuid(
UUID.fromString(
"0000180F-0000-1000-8000-00805F9B34FB"
)
))
.build();
advertiser.startAdvertising(
settings, data, advertiseCallback
);
Przy opracowywaniu międzyplatformowej aplikacji BLE należy uwzględnić różnice: iOS nie pozwala bezpośrednio zarządzać advertising interval, ale gwarantuje stabilne działanie na wszystkich urządzeniach; Android zapewnia pełną kontrolę, ale fragmentacja wersji i producentów może prowadzić do niekompatybilności. Zaleca się testowanie advertising na rzeczywistych urządzeniach obu platform.
Często zadawane pytania
Connectable advertising (ADV_IND) pozwala Central nawiązać dwustronne połączenie z urządzeniem. Non-connectable (ADV_NONCONN_IND) — tylko jednokierunkowa transmisja danych, używana przez beacon’y (Beacon) do nadawania identyfikatora bez możliwości połączenia.
Standardowy pakiet advertisingowy — 31 bajtów, scan response — kolejne 31 bajtów. Extended Advertising (BLE 5.0+) zwiększa limit do 251 bajtów dzięki wykorzystaniu kanałów wtórnych do transmisji danych.
Dla większości urządzeń IoT zaleca się 500–1000 ms. Jeśli wymagane jest szybkie wykrycie (na przykład do podłączenia słuchawek) — 20–50 ms. Dla czujników z rzadkim przesyłaniem danych — 1000–2000 ms w celu oszczędzania energii.
Trzy kanały (37, 38, 39) to kompromis między niezawodnością wykrycia a przepustowością. Jeden kanał może być zajęty przez Wi-Fi, ale urządzenie zostanie wykryte na dwóch pozostałych. Kanał 38 znajduje się w strefie minimalnych zakłóceń między kanałami Wi-Fi.
Advertising to główny konsument energii w BLE. Przy interwale 1000 ms średni prąd wynosi 50–100 μA, co pozwala urządzeniu pracować rok na baterii CR2032. Przy interwale 20 ms prąd wzrasta do 1–2 mA, skracając czas pracy do kilku tygodni.
Podsumowanie
Opracujemy aplikację mobilną pod klucz
IT Sectr tworzy aplikacje na iOS i Androida dla startupów i firm od 2017 roku. Doradzimy Ci i zaproponujemy najlepsze rozwiązanie.
Przeczytaj również