Characteristic: What It Is, Data Types, and Reading Values

What Is a Characteristic in BLE?

A Characteristic is a GATT protocol attribute that contains a value and metadata. In BLE architecture, data is not transferred directly between devices but through reading and writing characteristic values of a service. If a service is a folder, then a Characteristic is a file inside that folder.

Each Characteristic consists of three components: declaration, value, and descriptors. The declaration contains the characteristic's UUID and its properties. The value is the actual data transferred between Central and Peripheral. Descriptors provide additional configuration.

According to the Bluetooth Core Specification 5.4 (2023), all data exchanges in BLE occur through operations on characteristics. Even standard profiles such as Heart Rate Profile or Battery Service are built on a set of characteristics with predefined UUIDs. This ensures compatibility of devices from different manufacturers without prior configuration.

It is important for developers to understand: each Characteristic can support different property combinations. One characteristic may be read-only, another for writing, a third for notifications. The correct choice of properties determines the use case and power consumption of the device.

Characteristic Properties and Permissions

Properties of a characteristic define which operations are allowed on it. This is a byte mask where each bit enables or disables a specific operation. The main properties are listed below.

Permissions are the access level at the GATT server layer. Unlike properties, which are declared in the characteristic declaration, permissions are checked on each operation. They may include encryption and authentication requirements.

Standard Bluetooth SIG Characteristics

Bluetooth SIG has specified over 500 standard characteristics that cover most common BLE use cases. Using standard UUIDs ensures that any receiving device correctly interprets the data without prior configuration.

Here are the most commonly used standard characteristics:

If an existing standard characteristic covers your task, use it. This simplifies Bluetooth certification and improves ecosystem compatibility. Create custom characteristics only for unique data not in the SIG registry.

How to Create a Characteristic in iOS and Android

Creating a characteristic is done on the Peripheral side — the device that provides data. Let us look at implementations on iOS (Swift) and Android (Java).

iOS: CBMutableCharacteristic

Core Bluetooth provides the CBMutableCharacteristic class for creating a characteristic with a UUID, properties, and initial value.

import CoreBluetooth

let characteristicUUID = CBUUID("2A19") // Battery Level characteristic

let characteristic = CBMutableCharacteristic(
    type: characteristicUUID,
    properties: [.read, .notify],
    value: nil,
    permissions: [.readable]
)

// Update value on change
let batteryData = Data([batteryLevel]) // uint8
peripheralManager.updateValue(
    batteryData,
    for: characteristic,
    onSubscribedCentrals: nil
)

Android: BluetoothGattCharacteristic

On Android, a characteristic is created using BluetoothGattCharacteristic with a UUID, properties, and permissions.

import android.bluetooth.*;

UUID charUuid = UUID.fromString("00002A19-0000-1000-8000-00805F9B34FB");

BluetoothGattCharacteristic characteristic =
    new BluetoothGattCharacteristic(
        charUuid,
        BluetoothGattCharacteristic.PROPERTY_READ
            | BluetoothGattCharacteristic.PROPERTY_NOTIFY,
        BluetoothGattCharacteristic.PERMISSION_READ
    );

// Set the value
characteristic.setValue(batteryLevel, BluetoothGattCharacteristic.FORMAT_UINT8, 0);
gattServer.notifyCharacteristicChanged(device, characteristic, false);

Reading, Writing, and Notifications

Operations on a Characteristic fall into three types: read, write, and notify/indicate. The choice depends on the scenario: data on demand is read, commands are written, streaming data subscribes to notifications.

Read — Central sends a request to read the characteristic value. Peripheral responds with the current value. The operation is synchronous and requires an explicit request from each side. Used for data that rarely changes: firmware version, serial number, settings.

Write — Central sends data to Peripheral. There are two modes: Write with Response (confirmation from Peripheral) and Write Without Response (no confirmation). Write with Response guarantees delivery — Peripheral sends confirmation after writing. Write Without Response is faster but does not guarantee delivery.

Notify and Indicate — Peripheral initiates data transmission to Central. With Notify, data is sent without confirmation — if Central fails to receive the packet, it is lost. With Indicate, Central sends confirmation (PDU level), ensuring delivery. Indicate is slower but more reliable. To subscribe to notifications, Central writes the value 0x0001 to the CCCD (Client Characteristic Configuration Descriptor).

MTU and Data Transfer Size

MTU (Maximum Transmission Unit) defines the maximum size of a single BLE data packet. By default, the MTU is 23 bytes, of which 3 bytes are the header — payload (ATT payload) equals 20 bytes. This is sufficient for most sensor data but not enough for file transfers or large configurations.

Bluetooth Core Specification 5.4 supports MTU negotiation — Central and Peripheral can agree on a larger packet size of up to 517 bytes. The process works as follows: Central sends an MTU Exchange request with its proposed MTU; Peripheral responds with its MTU; the smaller of the two values is used.

// iOS requests MTU on connect
// Max MTU in iOS is 185 bytes
func peripheral(
    _ peripheral: CBPeripheral,
    didDiscoverServices error: Error?
) {
    // Request MTU for specific peripheral
    peripheral.maximumWriteValueLength(for: .withResponse)
}

According to Bluetooth SIG (2023), increasing the MTU from 23 to 185 bytes reduces data transmission overhead by up to 80% due to fewer packets. For applications transmitting high-frequency readings (e.g., ECG or accelerometer), MTU increase is critical for stream stability.