Peripheral — що це, роль у BLE та як рекламує сервіси

Що таке Peripheral у BLE?

Peripheral — це пристрій BLE, який реалізує GATT-сервер та рекламує свої можливості через advertising-канали. На відміну від Central, який активно шукає пристрої, Peripheral пасивно очікує підключення. Це асиметрична модель, оптимізована для енергоефективності пристроїв з батарейним живленням.

Peripheral може перебувати в кількох режимах: advertising (реклама), connected (підключений до Central), sleeping (сон з вимкненою рекламою). У режимі advertising Peripheral періодично надсилає короткі пакети даних, споживаючи при цьому мінімальну енергію. Після підключення Peripheral переходить у connected mode, де обмінюється даними з Central відповідно до узгодженого connection interval.

За даними Bluetooth Core Specification 5.4 (2023), пристрій може динамічно перемикатися між ролями Peripheral та Central, але в кожен момент часу для одного з'єднання роль фіксована. Типовий сценарій: IoT-датчик постійно працює в ролі Peripheral, а смартфон керує підключенням як Central.

Розробнику важливо розуміти: Peripheral визначає, які сервіси та характеристики доступні, та керує доступом до них. Структура GATT-сервера на Peripheral визначає, які дані може читати Central та які команди може записувати.

Процес реклами (Advertising)

Advertising (реклама) — це механізм, за допомогою якого Peripheral повідомляє про свою присутність. Peripheral надсилає advertising-пакети на трьох виділених каналах (37, 38, 39) з інтервалом від 20 мс до 10.24 секунд. Кожен рекламний пакет містить фіксовану інформацію та може включати опціональні дані.

Існує два типи рекламних пакетів: advertising PDU (основний пакет) та scan response PDU (відповідь на запит Central). Основний пакет містить обов'язкові поля: тип пакета, адресу відправника, дані. Якщо Central надсилає scan request, Peripheral відповідає додатковим пакетом з більш повною інформацією — наприклад, повним ім'ям пристрою.

Параметри advertising впливають на швидкість виявлення та енергоспоживання. Advertising interval — час між надсиланням пакетів. Чим коротший інтервал, тим швидше Central виявить пристрій, але тим більше енергії споживає Peripheral. Рекомендований інтервал: 100–1000 мс для більшості пристроїв.

Структура рекламного пакета

Рекламний пакет BLE має обмеження в 31 байт для advertising PDU та ще 31 байт для scan response. Усередині пакета дані організовані у форматі AD Structure (Advertising Data Structure): кожне поле має тип (1 байт), довжину (1 байт) та значення.

Найбільш часто використовувані AD Type: Flags (0x01) — режими підключення та виявлення, Local Name (0x08 або 0x09) — ім'я пристрою, Service UUID List (0x02–0x07) — список UUID сервісів, Manufacturer Specific Data (0xFF) — дані виробника. Правильне пакування даних у 31-байтний пакет — важливе завдання розробника вбудованих пристроїв.

Для пристроїв, яким потрібно передати більше даних, існує extended advertising (BLE 5.0+), який збільшує розмір рекламного пакета до 251 байта та додає нові типи пакетів. Extended advertising також підтримує канали з кодуванням (coded PHY) для збільшення дальності до 1 км на відкритій місцевості.

При проектуванні рекламного пакета враховуйте: чим більше даних в advertising-пакеті, тим вища ймовірність колізії з іншими пристроями. Для швидкого виявлення рекомендується розміщувати лише критичні дані (Service UUID) в advertising PDU, а додаткові дані — в scan response.

Peripheral як GATT-сервер

GATT-сервер на Peripheral містить всі сервіси та характеристики, які Central може виявити та з якими може взаємодіяти. Після підключення Central виявляє сервіси (discover services), потім характеристики (discover characteristics) та взаємодіє з ними через GATT-протокол.

Peripheral як GATT-сервер повинен коректно обробляти запити від Central: читання (read request), запис (write request), сповіщення (notification) та підтверджені сповіщення (indication). Кожен запит проходить через GATT-таблицю, де кожному атрибуту (сервісу, характеристиці, дескриптору) відповідає Handle — 16-бітна адреса.

Розробник Peripheral визначає права доступу до кожного атрибута: лише читання, лише запис, читання та запис, з шифруванням або без. Для конфіденційних даних (персональна інформація, медичні показники) рекомендується включати вимогу шифрування через MITM Protection.

Peripheral в iOS: CBPeripheralManager

CBPeripheralManager — клас Core Bluetooth для реалізації ролі Peripheral на iOS. Він керує GATT-сервером, публікує сервіси та характеристики, обробляє запити від Central. На відміну від CBCentralManager, CBPeripheralManager не сканує — він лише рекламує та обслуговує підключення.

Основні кроки реалізації Peripheral на iOS: ініціалізація CBPeripheralManager, додавання сервісів через add, запуск реклами через startAdvertising, обробка запитів від Central через делегат 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 дозволяє Peripheral працювати в фоновому режимі за наявності ключа bluetooth-peripheral в Background Modes. У фоні iOS може рекламуватися з обмеженим набором даних та обслуговувати підключення. Для тривалої реклами (більше 180 секунд) використовуйте опцію CBAdvertisementDataWaitForResponseFromCentral для економії енергії.

Peripheral в Android: BluetoothLeAdvertiser

Android надає BluetoothLeAdvertiser для роботи в ролі Peripheral (починаючи з API 21). API дозволяє запускати рекламу з настроюваними параметрами: потужність передавача, інтервал реклами, дані пакета. Android також підтримує extended advertising (BLE 5.0) на сумісних пристроях.

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
    );
}

На Android підтримка Peripheral залежить від виробника та версії ОС. Не всі пристрої підтримують BluetoothLeAdvertiser — перевіряйте через adapter.isMultipleAdvertisementSupported(). Починаючи з Android 10, для роботи в ролі Peripheral потрібен дозвіл BLUETOOTH_ADVERTISE, а також runtime-запит для додатків з target SDK 31+.

Енергоефективність Peripheral

Енергоефективність — ключова перевага BLE, і Peripheral відіграє в цьому головну роль. Пристрій може працювати від батарейки CR2032 (220 мАг) більше року завдяки оптимізованому енергоспоживанню. Більшу частину часу Peripheral проводить у режимі сну з вимкненою рекламою, прокидаючись лише для надсилання рекламного пакета або обробки запиту від Central.

Енергоспоживання Peripheral в різних режимах: режим сну (deep sleep) — 1–5 мкА, idle з увімкненим таймером — 10–50 мкА, advertising — 5–15 мА (на час надсилання пакета), connected — 5–10 мА (на час connection event). При advertising interval 1000 мс та тривалості пакета 4 мс, середній струм становить близько 50–100 мкА.

За даними Texas Instruments Application Report (SWRA478, 2024), оптимізація advertising interval з 100 мс до 1000 мс знижує середнє енергоспоживання на 90%. Додаткова економія досягається використанням slave latency (пропуск connection events), зменшенням Tx Power при коротких відстанях та вимкненням реклами після підключення (connectable advertising).