Peripheral — what it is, role in BLE and how it advertises services

What is a Peripheral in BLE?

Peripheral is a BLE device that implements a GATT server and advertises its capabilities through advertising channels. Unlike a Central, which actively searches for devices, a Peripheral passively waits for connections. This is an asymmetric model optimized for energy efficiency of battery-powered devices.

Peripheral can be in several modes: advertising, connected (connected to a Central), sleeping (sleep with advertising disabled). In advertising mode, the Peripheral periodically sends short data packets while consuming minimal energy. After connection, the Peripheral switches to connected mode, where it exchanges data with the Central according to the negotiated connection interval.

According to Bluetooth Core Specification 5.4 (2023), a device can dynamically switch between Peripheral and Central roles, but at any given moment, the role is fixed for a single connection. A typical scenario: an IoT sensor constantly works as a Peripheral, while a smartphone manages the connection as a Central.

It is important for developers to understand: the Peripheral determines which services and characteristics are available and manages access to them. The GATT server structure on the Peripheral determines what data the Central can read and what commands it can write.

Advertising Process

Advertising is the mechanism by which a Peripheral announces its presence. The Peripheral sends advertising packets on three dedicated channels (37, 38, 39) with an interval from 20 ms to 10.24 seconds. Each advertising packet contains fixed information and may include optional data.

There are two types of advertising packets: advertising PDU (main packet) and scan response PDU (response to a Central request). The main packet contains mandatory fields: packet type, sender address, data. If a Central sends a scan request, the Peripheral responds with an additional packet containing more complete information — for example, the full device name.

Advertising parameters affect discovery speed and power consumption. Advertising interval is the time between packet transmissions. The shorter the interval, the faster the Central will discover the device, but the more power the Peripheral consumes. Recommended interval: 100–1000 ms for most devices.

Advertising Packet Structure

BLE advertising packet has a 31-byte limit for advertising PDU and an additional 31 bytes for scan response. Inside the packet, data is organized in AD Structure (Advertising Data Structure) format: each field has a type (1 byte), length (1 byte), and value.

The most commonly used AD Types: Flags (0x01) — connection and discovery modes, Local Name (0x08 or 0x09) — device name, Service UUID List (0x02–0x07) — list of service UUIDs, Manufacturer Specific Data (0xFF) — manufacturer data. Properly packing data into a 31-byte packet is an important task for embedded device developers.

For devices that need to transmit more data, extended advertising (BLE 5.0+) increases the advertising packet size to 251 bytes and adds new packet types. Extended advertising also supports coded PHY channels for increased range up to 1 km in open areas.

When designing an advertising packet, keep in mind: the more data in the advertising packet, the higher the probability of collision with other devices. For fast discovery, it is recommended to place only critical data (Service UUID) in the advertising PDU, and additional data in the scan response.

Peripheral as a GATT Server

GATT server on the Peripheral contains all services and characteristics that a Central can discover and interact with. After connection, the Central discovers services, then characteristics, and interacts with them through the GATT protocol.

Peripheral as a GATT server must correctly handle requests from the Central: read requests, write requests, notifications, and indications. Each request goes through the GATT table, where each attribute (service, characteristic, descriptor) corresponds to a Handle — a 16-bit address.

The Peripheral developer defines access permissions for each attribute: read-only, write-only, read and write, with or without encryption. For sensitive data (personal information, medical indicators), it is recommended to enable encryption requirements through MITM Protection.

Peripheral in iOS: CBPeripheralManager

CBPeripheralManager is a Core Bluetooth class for implementing the Peripheral role on iOS. It manages the GATT server, publishes services and characteristics, and handles requests from Centrals. Unlike CBCentralManager, CBPeripheralManager does not scan — it only advertises and services connections.

The main steps for implementing a Peripheral on iOS: initializing CBPeripheralManager, adding services via add, starting advertising via startAdvertising, handling requests from Centrals through the 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 allows the Peripheral to work in the background with the bluetooth-peripheral key in Background Modes. In the background, iOS can advertise with a limited set of data and service connections. For extended advertising (more than 180 seconds), use the CBAdvertisementDataWaitForResponseFromCentral option to save power.

Peripheral in Android: BluetoothLeAdvertiser

Android provides BluetoothLeAdvertiser for working in the Peripheral role (starting from API 21). The API allows starting advertising with configurable parameters: transmitter power, advertising interval, packet data. Android also supports extended advertising (BLE 5.0) on compatible devices.

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

On Android, Peripheral support depends on the manufacturer and OS version. Not all devices support BluetoothLeAdvertiser — check via adapter.isMultipleAdvertisementSupported(). Starting from Android 10, the BLUETOOTH_ADVERTISE permission is required for the Peripheral role, along with a runtime request for apps with target SDK 31+.

Peripheral Power Efficiency

Power efficiency is a key advantage of BLE, and the Peripheral plays a major role in this. A device can run on a CR2032 battery (220 mAh) for over a year thanks to optimized power consumption. Most of the time, the Peripheral stays in sleep mode with advertising disabled, waking up only to send an advertising packet or process a request from a Central.

Peripheral power consumption in different modes: sleep mode (deep sleep) — 1–5 µA, idle with timer enabled — 10–50 µA, advertising — 5–15 mA (during packet transmission), connected — 5–10 mA (during connection event). With an advertising interval of 1000 ms and packet duration of 4 ms, the average current is about 50–100 µA.

According to Texas Instruments Application Report (SWRA478, 2024), optimizing the advertising interval from 100 ms to 1000 ms reduces average power consumption by 90%. Additional savings are achieved through slave latency (skipping connection events), reducing Tx Power over short distances, and disabling advertising after connection (connectable advertising).