Advertising i BLE: vad ar det, paketformat och reklammekanismer

Vad ar Advertising i BLE?

Advertising (reklam) — ar processen for periodisk overforing av korta datapaket genom vilken en BLE-enhet meddelar sin narvaro och tillganglighet. Till skillnad fran klassisk Bluetooth, dar sokning efter enheter tar sekunder, mojliggor BLE advertising detektering av enheten inom millisekunder med minimal energiforbrukning.

BLE-arkitekturen delar in enheter i tva roller: Peripheral (reklamerar) och Central (skannar). Peripheral skickar advertising-paket och Central skannar kanalen och beslutar om anslutning. Denna asymmetriska modell ar en viktig fordel med BLE: den reklamerande enheten forbrukar energi endast for att skicka korta paket, inte for kontinuerlig lyssning pa kanalen.

Reklamprocessen bestar av tre steg: advertising event (sanda paketet pa alla tre kanaler), scan request/response (valfritt utbyte med Central) och connection request (initiering av anslutning av Central). Varje steg hanteras av Bluetooth Controller pa Link Layer-niva.

Reklamkanaler och deras syfte

BLE anvander 40 kanaler i 2.4 GHz-bandet, varav 37 (2402 MHz), 38 (2426 MHz) och 39 (2480 MHz) ar exklusivt reserverade for advertising. Tre kanaler ar en kompromiss mellan detekteringspalltlighet och bandbredd: en kanal kan vara upptagen av Wi-Fi eller andra storningar, men enheten kommer att detekteras pa de andra tva.

Kanal 37 ligger bredvid Wi-Fi-kanal 1, kanal 39 — bredvid Wi-Fi-kanal 6, och kanal 38 ligger mellan dem i zonen med minimala storningar. Valet av tre kanaler garanterar att enheten kommer att detekteras aven under tat radiomiljo — till exempel i ett kopcentrum med dussintals Wi-Fi-atkomstpunkter.

Peripheral skickar advertising-paket sekventiellt pa alla tre kanaler — detta kallas advertising event. Den centrala enheten skannar en kanal i taget och vaxlar mellan dem enligt algoritmen implementerad i Bluetooth Controller. Sannolikheten for detektering under ett advertising event utan kollisioner ar nara 100%.

Typer av reklampaket

Bluetooth Core Specification definierar flera typer av advertising PDU (Protocol Data Unit), var och en med sitt eget syfte. Huvudtyper: ADV_IND (connectable undirected advertising) — standardreklam med anslutningsmojlighet, ADV_NONCONN_IND (non-connectable undirected advertising) — endast reklam utan anslutning, ADV_SCAN_IND (scannable undirected advertising) — stoder scan request, ADV_DIRECT_IND (directed advertising) — reklam for en specifik Central.

ADV_IND — den vanligaste typen, som anvands i de flesta BLE-enheter. Efter mottagning av ADV_IND kan Central skicka en connection request och etablera anslutning. ADV_NONCONN_IND anvands av fyrar (Beacon): enheten reklamerar men accepterar inte anslutningsbegaran — endast enkelriktad dataoverforing.

ADV_DIRECT_IND innehaller adressen till mal-Centralen, vilket mojliggor snabb anslutning utan att vanta pa skanning. Anvands nar enheter redan "kanner" varandra — till exempel efter ateranslutning till en tidigare parad smartphone. Denna typ minskar energiforbrukningen eftersom den inte kraver reklam pa alla kanaler.

Reklamintervall och energiforbrukning

Advertising interval — ar tiden mellan pa varandra foljande advertising events. Specifikationen tillater ett intervall fran 20 ms till 10.24 s med ett steg pa 0.625 ms. Det faktiska intervallet beraknas som summan av ett fast varde och en slumpmassig forsening (0–10 ms), vilket minskar sannolikheten for kollisioner mellan flera reklamerande enheter.

Valet av intervall ar en balans mellan detekteringshastighet och energiforbrukning. Vid 20 ms intervall kommer enheten att detekteras inom 20–30 ms, men medelstrommen blir cirka 1–2 mA. Vid 1000 ms intervall — detektering tar upp till 1 sekund, men medelstrommen sjunker till 50–100 µA. For de flesta IoT-enheter ar det rekommenderade intervallet 200–1000 ms.

Enligt Texas Instruments Application Report SWRA478 (2024), minskar okning av advertising intervallet fran 100 ms till 1000 ms energiforbrukningen med 90%. Om enheten inte kraver omedelbar detektering (till exempel en temperatursensor som skickar data en gang per minut), ar det optimala intervallet 1000–2000 ms.

En extra parameter — advertising timeout — den maximala tid som enheten reklamerar. I iOS stanger Peripheral automatiskt av reklamen efter 180 sekunder i bakgrundslage. I Android finns ingen sadan begransning, men tillverkare kan lagga till egna begransningar.

Scan Response: ytterligare data

Scan Response — ar ett extra datapaket (upp till 31 byte) som Peripheral skickar som svar pa en scan request fran Central. Scan request skickas av Central efter mottagning av advertising-paketet, om den behover mer information innan anslutning. Scan Response kraver ingen extra reklam — den skickas endast pa begaran, vilket sparar kanalen.

Typisk datafordelning: i advertising PDU (31 byte) placeras flaggor (3 byte), tjanste-UUID (2–16 byte) och tillverkar data (aterstaende byte). I scan response overfors enhetens fulla namn (upp till 28 byte) och extra UUID eller TX Power Level. Denna uppdelning gor att Central snabbt kan filtrera enheter efter UUID utan att lasa scan response.

Vid utformning av advertising-paket, notera: om alla 31 byte ar upptagna i advertising PDU, kommer Central inte att kunna avgora om enheten stoder scan response. Det rekommenderas att lamna minst 3–5 byte lediga i advertising PDU for att indikera scan response-formaga.

Extended Advertising i BLE 5.0

Extended Advertising (BLE 5.0) — ar en utokning av reklammekanismen som okar storleken pa advertising-paketet fran 31 till 251 byte och lagger till nya pakettyper. Extended Advertising stoder aven coded PHY for att oka kommunikationsrackvidden till 1 km pa oppet omrade och periodisk reklam (Periodic Advertising) for synkronisering av flera Central-enheter.

Huvudinnovationer: ADV_EXT_IND — extended advertising PDU som kan overfora upp till 251 byte data i ett enda paket. Extended Advertising anvander primara kanaler (37, 38, 39) endast for att indikera pa vilken sekundar kanal (0–36) som fullstandiga data overfors. Detta minskar belastningen pa reklamkanalerna och okar systemets totala bandbredd.

Periodic Advertising — en extra mekanism dar Peripheral skickar data pa sekundara kanaler med fast intervall, och Central kan synkronisera med denna sekvens. Anvands for tjanster som kraver regelbundna datauppdateringar — till exempel audiooverforing eller realtidsavlasningar av sensorer.

Konfigurera reklam i iOS och Android

iOS (Core Bluetooth) tillhandahaller CBPeripheralManager for hantering av reklam. Advertising-parameter stalls in via ordlistan advertisementData med nycklarna CBAdvertisementDataLocalNameKey (enhetens namn), CBAdvertisementDataServiceUUIDsKey (tjanste-UUID), CBAdvertisementDataTxPowerLevelKey (effekt). iOS hanterar automatiskt advertising interval och tillater inte manuell installning.

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) ger mer detaljerad kontroll. Tillgangliga: AdvertiseSettings — installning av lage (LOW_POWER, BALANCED, LOW_LATENCY), sandareffekt och intervall; AdvertiseData — paketdata. Android stoder extended advertising (BLE 5.0) pa kompatibla enheter, men andelen sadana enheter pa marknaden ar cirka 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
);

Vid utveckling av en plattformsoverskridande BLE-applikation, beakta skillnaderna: iOS tillater inte direkt kontroll av advertising interval, men garanterar stabil drift pa alla enheter; Android ger full kontroll, men fragmentering av versioner och tillverkare kan leda till inkompatibilitet. Det rekommenderas att testa advertising pa verkliga enheter fran bada plattformarna.