Peripheral — ano ito, papel sa BLE at paano nag-a-anunsyo ng mga serbisyo

Ano ang Peripheral sa BLE?

Peripheral — ay isang BLE device na nagpapatupad ng GATT server at nag-a-anunsyo ng mga kakayahan nito sa pamamagitan ng advertising channels. Hindi tulad ng Central na aktibong naghahanap ng mga device, ang Peripheral ay passive na naghihintay ng koneksyon. Ito ay isang asymmetric na modelo, na na-optimize para sa energy efficiency ng mga device na pinapagana ng baterya.

Ang Peripheral ay maaaring nasa ilang mga mode: advertising (pag-a-anunsyo), connected (konektado sa Central), sleeping (tulog na naka-off ang pag-a-anunsyo). Sa advertising mode, pana-panahong nagpapadala ang Peripheral ng mga maikling data packet na may minimal na konsumo ng kuryente. Pagkatapos ng koneksyon, lumipat ang Peripheral sa connected mode, kung saan nakikipagpalitan ito ng data sa Central ayon sa napagkasunduang connection interval.

Ayon sa Bluetooth Core Specification 5.4 (2023), ang isang device ay maaaring dynamic na lumipat sa pagitan ng mga papel na Peripheral at Central, ngunit sa bawat sandali, para sa isang koneksyon, ang papel ay nakapirmi. Karaniwang senaryo: ang IoT sensor ay patuloy na gumagana sa papel na Peripheral, at ang smartphone ay namamahala ng koneksyon bilang Central.

Mahalaga para sa developer na maunawaan: tinutukoy ng Peripheral kung aling mga serbisyo at katangian ang available at namamahala ng access sa mga ito. Ang istraktura ng GATT server sa Peripheral ay tumutukoy kung anong data ang maaaring basahin ng Central at kung anong mga utos ang maaaring isulat nito.

Proseso ng Pag-a-anunsyo (Advertising)

Advertising (pag-a-anunsyo) — ay ang mekanismo kung saan inaanunsyo ng Peripheral ang presensya nito. Nagpapadala ang Peripheral ng advertising packets sa tatlong nakalaang channel (37, 38, 39) na may interval mula 20 ms hanggang 10.24 segundo. Ang bawat advertising packet ay naglalaman ng nakapirming impormasyon at maaaring magsama ng opsyonal na data.

May dalawang uri ng advertising packets: advertising PDU (pangunahing packet) at scan response PDU (tugon sa kahilingan ng Central). Ang pangunahing packet ay naglalaman ng mga mandatoryong field: uri ng packet, address ng nagpadala, data. Kung magpapadala ang Central ng scan request, tutugon ang Peripheral ng karagdagang packet na may mas kumpletong impormasyon — halimbawa, buong pangalan ng device.

Ang mga parameter ng advertising ay nakakaapekto sa bilis ng pagtuklas at konsumo ng kuryente. Advertising interval — oras sa pagitan ng pagpapadala ng mga packet. Kung mas maikli ang interval, mas mabilis na matutuklasan ng Central ang device, ngunit mas maraming kuryente ang kinokonsumo ng Peripheral. Inirerekomendang interval: 100–1000 ms para sa karamihan ng mga device.

Istraktura ng Advertising Packet

Ang BLE advertising packet ay may limitasyon na 31 bytes para sa advertising PDU at karagdagang 31 bytes para sa scan response. Sa loob ng packet, ang data ay nakaayos sa AD Structure (Advertising Data Structure) na format: bawat field ay may uri (1 byte), haba (1 byte), at halaga.

Ang pinakamadalas na ginagamit na AD Type: Flags (0x01) — mga mode ng koneksyon at pagtuklas, Local Name (0x08 o 0x09) — pangalan ng device, Service UUID List (0x02–0x07) — listahan ng UUID ng mga serbisyo, Manufacturer Specific Data (0xFF) — data ng manufacturer. Ang tamang pag-empake ng data sa isang 31-byte packet ay isang mahalagang gawain para sa developer ng embedded devices.

Para sa mga device na kailangang magpadala ng mas maraming data, mayroong extended advertising (BLE 5.0+), na nagpapataas ng laki ng advertising packet sa 251 bytes at nagdaragdag ng mga bagong uri ng packet. Sinusuportahan din ng extended advertising ang mga naka-code na channel (coded PHY) para palawakin ang saklaw hanggang 1 km sa bukas na lugar.

Sa pagdisenyo ng advertising packet, isaalang-alang: mas maraming data sa advertising packet, mas mataas ang posibilidad ng banggaan sa iba pang mga device. Para sa mabilis na pagtuklas, inirerekomenda na ilagay lamang ang kritikal na data (Service UUID) sa advertising PDU, at ang karagdagang data — sa scan response.

Peripheral bilang GATT Server

Ang GATT server sa Peripheral ay naglalaman ng lahat ng mga serbisyo at katangian na maaaring matuklasan ng Central at makipag-ugnayan. Pagkatapos ng koneksyon, natutuklasan ng Central ang mga serbisyo (discover services), pagkatapos ang mga katangian (discover characteristics) at nakikipag-ugnayan sa kanila sa pamamagitan ng GATT protocol.

Ang Peripheral bilang GATT server ay dapat na wastong magproseso ng mga kahilingan mula sa Central: pagbasa (read request), pagsulat (write request), mga notipikasyon (notification) at kumpirmadong notipikasyon (indication). Ang bawat kahilingan ay dumadaan sa GATT table, kung saan ang bawat atributo (serbisyo, katangian, descriptor) ay may katumbas na Handle — isang 16-bit na address.

Tinutukoy ng developer ng Peripheral ang mga karapatan sa pag-access para sa bawat atributo: basa lang, sulat lang, basa at sulat, may o walang encryption. Para sa kumpidensyal na data (personal na impormasyon, mga parameter medikal) inirerekomenda na mangailangan ng encryption sa pamamagitan ng MITM Protection.

Peripheral sa iOS: CBPeripheralManager

CBPeripheralManager — ang Core Bluetooth class para sa pagpapatupad ng papel na Peripheral sa iOS. Pinamamahalaan nito ang GATT server, naglalathala ng mga serbisyo at katangian, at nagpoproseso ng mga kahilingan mula sa Central. Hindi tulad ng CBCentralManager, ang CBPeripheralManager ay hindi nag-scan — ito ay nag-a-anunsyo lamang at naglilingkod sa mga koneksyon.

Mga pangunahing hakbang sa pagpapatupad ng Peripheral sa iOS: pagsisimula ng CBPeripheralManager, pagdaragdag ng mga serbisyo sa pamamagitan ng add, pagsisimula ng pag-a-anunsyo sa pamamagitan ng startAdvertising, pagproseso ng mga kahilingan mula sa Central sa pamamagitan ng delegate na 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()
        }
    }
}

Pinapayagan ng iOS ang Peripheral na gumana sa background mode kapag naroroon ang bluetooth-peripheral key sa Background Modes. Sa background, ang iOS ay maaaring mag-anunsyo na may limitadong set ng data at maglingkod sa mga koneksyon. Para sa pangmatagalang pag-a-anunsyo (higit sa 180 segundo), gamitin ang opsyong CBAdvertisementDataWaitForResponseFromCentral para makatipid ng kuryente.

Peripheral sa Android: BluetoothLeAdvertiser

Android ay nagbibigay ng BluetoothLeAdvertiser para sa pagtatrabaho sa papel na Peripheral (mula API 21). Pinapayagan ng API na magsimula ng pag-a-anunsyo na may mga configurable na parameter: lakas ng transmitter, interval ng pag-a-anunsyo, data ng packet. Sinusuportahan din ng Android ang extended advertising (BLE 5.0) sa mga compatible na device.

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

Sa Android, ang suporta para sa Peripheral ay nakadepende sa manufacturer at bersyon ng OS. Hindi lahat ng device ay sumusuporta sa BluetoothLeAdvertiser — suriin sa pamamagitan ng adapter.isMultipleAdvertisementSupported(). Mula Android 10, para sa papel na Peripheral ay kinakailangan ang pahintulot na BLUETOOTH_ADVERTISE, pati na rin ang runtime request para sa mga app na may target SDK 31+.

Energy Efficiency ng Peripheral

Energy efficiency — ang pangunahing bentahe ng BLE, at ang Peripheral ay gumaganap ng pangunahing papel dito. Ang device ay maaaring gumana mula sa isang CR2032 na baterya (220 mAh) nang higit sa isang taon salamat sa na-optimize na konsumo ng kuryente. Ginugugol ng Peripheral ang karamihan ng oras nito sa sleep mode na naka-off ang pag-a-anunsyo, gumigising lamang upang magpadala ng advertising packet o magproseso ng kahilingan mula sa Central.

Ang konsumo ng kuryente ng Peripheral sa iba't ibang mode: sleep mode (deep sleep) — 1–5 µA, idle na may naka-on na timer — 10–50 µA, advertising — 5–15 mA (sa panahon ng pagpapadala ng packet), connected — 5–10 mA (sa panahon ng connection event). Sa advertising interval na 1000 ms at tagal ng packet na 4 ms, ang average na kasalukuyang ay mga 50–100 µA.

Ayon sa Texas Instruments Application Report (SWRA478, 2024), ang pag-optimize ng advertising interval mula 100 ms hanggang 1000 ms ay nagbabawas ng average na konsumo ng kuryente ng 90%. Ang karagdagang pagtitipid ay nakakamit sa pamamagitan ng paggamit ng slave latency (paglaktaw sa mga connection events), pagbawas ng Tx Power sa maikling distansya, at pag-off ng pag-a-anunsyo pagkatapos ng koneksyon (connectable advertising).