11.4. Рекламування та сканування¶

Два BLE-пристрої, що ніколи раніше не зустрічалися, спершу повинні знайти один одного. Мережа вирішує це, видаючи кожному пристрою адресу зі спільного пулу та дозволяючи будь-якій стороні дістатись до іншої через маршрутизатори. У BLE немає маршрутизаторів, немає спільного пулу і – між більшістю пар пристроїв – жодних попередніх стосунків. Generic Access Profile (GAP) вирішує виявлення за допомогою патерну «широкомовлення і прослуховування». Одна сторона рекламує – вона передає короткий пакет на трьох рекламних каналах з регулярним інтервалом, описуючи себе. Інша сторона сканує – вона прослуховує ті самі три канали в очікуванні таких пакетів.

GAP визначає чотири ролі на основі цього патерну, кожна з яких є конкретною комбінацією рекламування та прослуховування.

11.4.1. Чотири ролі GAP¶

A two-by-two matrix. Rows are labelled "advertises" and "does not advertise". Columns are labelled "accepts connections" and "does not accept connections". The four cells contain the role names: Peripheral, Broadcaster, Central, Observer. — Чотири ролі GAP. Вертикальна вісь – чи рекламує пристрій; горизонтальна – чи приймає (або ініціює) з’єднання.¶

Peripheral рекламує пакети зі змістом «Я тут і ти можеш підключитись до мене». Коли інший пристрій відкриває з’єднання, peripheral припиняє рекламування та починає обробляти GATT-запити. Пульсометри, термометри та більшість камер-датчиків виконують роль peripheral.
Central сканує peripheral-пристрої, обирає один і ініціює з’єднання. Після підключення він діє як GATT-клієнт. Телефони, ноутбуки та камери, що виконують роль збирачів даних, є central.
Broadcaster рекламує, але ніколи не приймає з’єднання. Його рекламний пакет і є даними – немає нічого, до чого підключатися. iBeacon та більшість маяків присутності в магазинах є broadcaster.
Observer сканує ті рекламні пакети та зчитує їхній вміст, теж ніколи не підключаючись. Камера, що прослуховує маяки поблизу та реагує на почуте, є observer.

Один пристрій може одночасно виконувати кілька ролей – камера може бути peripheral, що публікує власний стан, і central, що підключається до сусіднього датчика. Радіо мультиплексує роботу.

11.4.2. Що містить рекламний пакет¶

Рекламний пакет невеликий: 31 байт корисного навантаження, або 62, якщо рекламодавець також публікує scan response, який сканери можуть запросити на льоту. Корисне навантаження – це список коротких типізованих полів:

Прапори. Можливість підключення, загальний / обмежений режим виявлення.
Локальна назва. Коротка, зручна для читання рядок – ім’я, яке операційна система телефону або ноутбука відображає у меню Bluetooth.
UUID сервісів. Список ідентифікаторів GATT-сервісів, які розміщує пристрій, щоб сканер міг розпізнати відповідні peripheral-пристрої без попереднього підключення. Пульсометр рекламує 0x180D – стандартний UUID сервісу Heart-Rate – і застосунок пульсометра на телефоні вже з цього розуміє, що пристрій варто підключити.
Зовнішній вигляд. 16-бітне значення зі списку призначених номерів Bluetooth (датчик, загальні медіа, загальний годинник, …) – підказка central щодо того, що відображати.
Специфічні для виробника дані. Довільні байти з префіксом ідентифікатора компанії. iBeacon використовує це поле для UUID, major та minor; власні застосунки можуть поміщати сюди будь-що.

Рекламні пакети обмежені. Ліміт у 31 байт робить вибір того, що включати, справжнім дизайнерським рішенням – довга зручна для читання назва може легко не залишити місця для UUID сервісів. API aioble.advertise() приймає кожен з них як іменований аргумент і збирає байти за вас, автоматично переповнюючись у scan response, якщо основний пакет заповнений.

11.4.3. Активне та пасивне сканування¶

Сканер може працювати в пасивному режимі, де він прослуховує рекламні пакети та розбирає те, що надходить, або в активному, де він також надсилає scan request кожному рекламодавцю та розбирає scan response, що повертається.

Пасивне сканування бачить лише початковий рекламний пакет (до 31 байта). Активне подвоює це – scan response є ще 31 байтом, який peripheral може використати для полів, що не вмістились. Активне сканування також потребує більше енергії з обох сторін, оскільки сканер передає і рекламодавець передає додатковий пакет, тому це – вибір, а не типовий режим.

В API aioble active=True у aioble.scan() перемикає режим, і кожен ScanResult надає комбіновані adv_data та resp_data, а також допоміжні методи, як result.name() та result.services(), що приховують розбір байтів.

Примітка

Атрибути adv_data та resp_data – це необроблені рекламні та scan-response корисні навантаження (bytes). Допоміжні методи – name(), services(), manufacturer() – охоплюють поширені стандартні поля і є правильним вибором у 99% випадків. Звертайтеся до необроблених байтів лише коли потрібне поле виробника, яке допоміжні методи не розбирають (URL Eddystone, UUID/major/minor iBeacon, власні типи рекламування). Розмітка байтів – стандартна TLV: кожне поле – це length, type, value....

11.4.4. Інтервал рекламування¶

Частота широкомовлення peripheral – це компроміс між споживанням та затримкою виявлення. Пакети, що надсилаються кожні 20 мс, майже миттєво помічаються сканером, але навантажують радіо та розряджають акумулятор; пакети раз на секунду майже не споживають енергії, але змушують сканер довше помічати пристрій.

interval_us у aioble.advertise() встановлює інтервал у мікросекундах:

20 000–100 000 мкс (20 мс – 100 мс) – швидке зв’язування, застосунок очікує швидкої відповіді, пристрій підключений до мережі.
250 000–1 000 000 мкс (250 мс – 1 с) – розумний типовий інтервал для периферійного пристрою на акумуляторі, що хоче бути виявленим без зайвого споживання заряду.
Понад 1 000 000 мкс – повільне фонове широкомовлення, маяки, що надсилають оновлення позиції кожні кілька секунд.

Сторона сканера має власні параметри – aioble.scan() приймає interval_us та window_us (як часто сканер вмикає радіо і як довго прослуховує щоразу). Типові значення цілком підходять; єдина поширена зміна – встановити обидва однаковими для безперервного сканування, коли витрата заряду не є проблемою.

11.4.5. Безз’єднувальні патерни – broadcaster та observer¶

Сторінки Робота у ролі периферійного пристрою та Робота в ролі central розглядають з’єднувальну форму API – де peripheral приймає з’єднання і обидві сторони обмінюються даними через GATT. Інша форма – безз’єднувальна: broadcaster передає корисне навантаження у вигляді рекламного пакету, і будь-який observer в зоні досяжності може прочитати його, не підключаючись. Маяки, датчики присутності та односторонній телеметрій – все це тут.

Broadcaster – це aioble.advertise() з connectable=False. Специфічні для виробника дані несуть корисне навантаження:

import aioble
import asyncio
import struct

_COMPANY_ID = const(0xFFFF)                # 0xFFFF is "no specific vendor"

async def beacon():
    seq = 0
    while True:
        seq = (seq + 1) & 0xFFFF
        payload = struct.pack("<H", seq)
        await aioble.advertise(
            interval_us=500000,
            connectable=False,
            name="openmv-beacon",
            manufacturer=(_COMPANY_ID, payload),
            timeout_ms=1000,                # one cycle, then loop
        )

asyncio.run(beacon())

Ключове слово timeout_ms завершує виклик advertise через секунду; зовнішній цикл повторно викликає його з наступним порядковим номером, щоб слухачі бачили свіжі дані. Прапор connectable=False робить рекламування стилю broadcaster – камера не відповідатиме на запит підключення, навіть якщо він надійде.

Observer – це відповідний сканер лише для читання. Він виконує aioble.scan() нескінченно, розбирає вхідні рекламні пакети та ніколи не викликає connect()

import aioble
import asyncio

_COMPANY_ID = const(0xFFFF)

async def watch():
    async with aioble.scan(duration_ms=0, active=False) as scanner:
        async for result in scanner:
            for company, data in result.manufacturer(filter=_COMPANY_ID):
                print(result.device.addr_hex(),
                      "rssi", result.rssi, "data", data)

asyncio.run(watch())

duration_ms=0 сканує до виходу з менеджера контексту; active=False тримає власне радіо observer мовчазним (без запитів scan-response) для мінімального споживання. Аргумент filter= у manufacturer() відкидає кожен рекламний пакет, що не відповідає ідентифікатору компанії, тому цикл спрацьовує лише на трафік broadcaster.

11.4.6. Від виявлення до з’єднання¶

Щойно central обирає peripheral для спілкування, він припиняє прослуховування, надсилає запит на з’єднання на рекламному каналі, який peripheral використав останнього разу, і обидві сторони переходять на стрибкоподібні канали даних канального рівня. Peripheral, як правило, в цей момент припиняє рекламування. Те, що відбувається далі – параметри з’єднання, виявлення GATT, час існування посилання – описано на сторінці З’єднання.