Bluetooth at BLE: ano ito, pagkakaiba ng Classic at Low Energy at kung paano ito gumagana

Ano ang Bluetooth at BLE?

Bluetooth — ay isang wireless personal area network (WPAN) standard na gumagana sa ISM 2.4 GHz band at idinisenyo para sa komunikasyon sa pagitan ng mga device hanggang 100 metro. Ang IEEE 802.15.1 specification ay tumutukoy sa physical at MAC layer, at ang Bluetooth SIG stack ay tumutukoy sa higher-level profiles para sa mga partikular na scenario: audio headsets (HSP), file transfer (OPP), keyboard input (HID).

Ang standard ay nahati sa dalawang sangay mula noong bersyon 4.0 (2010): Bluetooth Classic (BR/EDR) at Bluetooth Low Energy (BLE, dating Bluetooth Smart). Ang Classic ay para sa tuluy-tuloy na stream — audio calls, musika, mga file. Ang BLE ay ginawa para sa mga application kung saan ang data ay ipinapadala sa maikling packet na may pahinga ng sampung segundo o minuto — pulse meter, tag, temperature sensor.

Ayon sa Bluetooth SIG (2025), 99% ng mga bagong smartphone ay sumusuporta sa parehong bersyon, at ang BLE ecosystem ay may kasamang higit sa 15 uri ng profile mula Blood Pressure hanggang Environmental Sensing.

Bluetooth Classic vs BLE: paghahambing na mga katangian

Ang pagpili sa pagitan ng Classic at BLE ay depende sa scenario: para sa audio streaming ay angkop lamang ang Classic, para sa pagbabasa ng sensor isang beses bawat oras — tanging BLE. BR/EDR ay gumagamit ng 79 na channel na may step na 1 MHz at adaptive frequency modulation (AFH), na nagbibigay ng resistensya sa Wi-Fi interference.

Ang BLE 5.x ay nagdagdag ng LE Coded PHY para sa pagtaas ng range hanggang 1 km (sa open area) at LE Audio na may LC3 codec — ang bagong bersyon ay unti-unting binubura ang hangganan sa pagitan ng Classic at BLE sa audio scenarios.

Arkitektura ng BLE: Controller, Host at Application

Ang BLE stack ay nahahati sa tatlong layer: Controller (physical at link layer), Host (L2CAP, ATT, GATT, Security Manager) at Application (implementation ng profile sa application). Ang paghahati na ito ay nagpapahintulot sa chip manufacturer na i-implement ang Controller sa firmware, at sa mobile app developer — na magtrabaho lamang sa GATT abstractions.

Link Layer (LL) ay namamahala ng oras ng pag-broadcast: ang device ay lumilipat sa pagitan ng Standby, Advertising, Scanning, Initiating at Connection states. Sa Connected state, ang Central at Peripheral ay nag-aayos ng connection interval — dalas ng pagpapalitan ng data packet. Karaniwang interval ay 7.5–1000 ms; mas madalas ang pagpapalitan, mas mataas ang bandwidth at konsumo ng kuryente.

Security Manager (SM) ay nag-i-implement ng AES-128 encryption na may key exchange sa pamamagitan ng pairing protocol. Tatlong mode: Just Works (walang PIN), Passkey Entry (6-digit code sa screen) at OOB (NFC o QR). Para sa wearable devices karaniwang ginagamit ang Just Works, para sa medical — OOB na may karagdagang verification.

Ayon sa Bluetooth Core Specification 5.4 (2023), ang oras ng paggawa ng secure na koneksyon sa LE Secure Connections mode ay hindi lalampas sa 300 ms sa connection interval na 30 ms.

GATT Profile: mga serbisyo, katangian at descriptor

Ang ATT (Attribute Protocol) — pangunahing modelo ng transportasyon kung saan ang server (peripheral device) ay nag-iimbak ng attributes, at ang client (smartphone) ay nagbabasa o nagsusulat ng mga ito. Ang GATT (Generic Attribute Profile) ay nagtatayo ng hierarchy sa ibabaw ng ATT: Service → Characteristic → Descriptor.

Ang bawat serbisyo ay lohikal na grupo ng mga katangian na naglalarawan ng isang function ng device: Heart Rate Service (UUID 0x180D) ay naglalaman ng Heart Rate Measurement characteristic (UUID 0x2A37) na may Descriptor Client Characteristic Configuration (0x2902) na namamahala ng mga notification. Ang mobile app developer ay kumukuha ng listahan ng mga serbisyo sa pamamagitan ng discoverServices(), pagkatapos ay hinahanap ang gustong characteristic sa pamamagitan ng UUID at nag-subscribe sa mga notification.

Ang BLE ay gumagamit ng 16-bit na UUID para sa standardized Bluetooth SIG services at 128-bit na UUID para sa custom services ng manufacturer. Halimbawa, ang isang tracker case ay maaaring mag-define ng serbisyo A000-… na may characteristic para sa pagpapadala ng charge level ng sarili nitong baterya.

Halimbawa ng pagtatrabaho sa GATT sa Kotlin (Android)

private val gattCallback = object BluetoothGattCallback() {
    override fun onServicesDiscovered(
        gatt: BluetoothGatt, status: Int
    ) {
        val service = gatt.getService(UUID.fromString("0000180d-0000-1000-8000-00805f9b34fb"))
        val char = service?.getCharacteristic(
            UUID.fromString("00002a37-0000-1000-8000-00805f9b34fb")
        )
        gatt.setCharacteristicNotification(char, true)
    }

    override fun onCharacteristicChanged(
        gatt: BluetoothGatt, char: BluetoothGattCharacteristic
    ) {
        val heartRate = char.getIntValue(BluetoothGattCharacteristic.FORMAT_UINT8, 1)
        updateUi("Pulso: $heartRate bpm")
    }
}

Sa halimbawa, ang application ay nakakahanap ng Heart Rate service sa pamamagitan ng standard Bluetooth SIG UUID, kumukuha ng pulse measurement characteristic at nag-subscribe sa mga notification nito — sa bawat pagbabago ng pulso, ang peripheral device ay nagpapadala ng data nang walang tahasang kahilingan mula sa Central.

Advertising, pag-scan at paggawa ng koneksyon

Advertising — pangunahing mekanismo ng BLE kung saan ang Peripheral device ay pana-panahong nagpapadala ng broadcast packets (advertising PDUs) sa tatlong primary channel (37, 38, 39). Ang central device ay nag-scan ng mga channel na ito, tumatanggap ng advertising data at maaaring magpasimula ng koneksyon.

Ang advertising packet ay naglalaman ng hanggang 31 bytes ng kapaki-pakinabang na load: flags, TX power level, local name, UUID ng mga serbisyo, manufacturer-specific data. Ito ay sapat para sa pagpapadala ng sensor readings nang walang koneksyon — Connectionless mode (Broadcaster type). Para sa tuluy-tuloy na pagpapadala ng data (hal. temperatura bawat minuto) ay ginagamit ang koneksyon na may connection interval hanggang 1000 ms.

Sa mobile platform, ang pag-scan ay sinisimulan sa pamamagitan ng startScan() (Android) o scanForPeripherals() (iOS). Ang pag-filter sa pamamagitan ng service UUID ay nagtitipid ng enerhiya — ang application ay tumatanggap lamang ng callback para sa mga kawili-wiling tag o sensor.

Halimbawa ng pag-scan ng BLE device sa Swift (iOS)

import CoreBluetooth

class ScannerViewController: UIViewController {
    private var centralManager: CBCentralManager!

    override func viewDidLoad() {
        centralManager = CBCentralManager(
            delegate: self, queue: nil
        )
    }

    func centralManagerDidUpdateState(central: CBCentralManager) {
        if central.state == .poweredOn {
            centralManager.scanForPeripherals(
                withServices: nil, options: nil
            )
        }
    }

    func centralManager(
        central: CBCentralManager,
        didDiscover peripheral: CBPeripheral,
        advertisementData: [String : Any],
        rssi RSSI: NSNumber
    ) {
        if let name = advertisementData[CBAdvertisementDataLocalNameKey] {
            print("Nahanap na device: \(name)")
        }
    }
}

Pagkatapos matukoy ang device, ang Central ay tumatawag ng connect() na nagpapasa ng CBPeripheral object. Ang mga parameter ng koneksyon (interval, latency, supervision timeout) ay pinag-uusapan sa Link Layer level — ang developer ay hindi direktang namamahala sa mga ito, ngunit maaaring makaimpluwensya sa pamamagitan ng requestConnectionPriority sa Android.

Bluetooth LE sa mobile development: Core Bluetooth at android.bluetooth

Ang parehong mobile platform ay nagbibigay ng native API para sa pagtatrabaho sa BLE. Core Bluetooth (iOS) ay gumagamit ng delegate approach: ang central manager ay nagpapasimula ng mga operasyon, ang peripheral object ay nag-uulat ng mga resulta sa pamamagitan ng delegate methods. Ang android.bluetooth (Android) ay binuo sa callback interfaces at sumusuporta sa parallel GATT operations na may maramihang device.

Mga pangunahing pagkakaiba sa pagitan ng mga platform:

• iOS — sumusuporta hanggang 7 simultaneous na koneksyon; background mode BLE ay nangangailangan ng UIBackgroundModes = bluetooth-central; pagkatapos lumabas sa background, ang system ay maaaring mag-antala ng mga callback ng ilang minuto
• Android — walang fixed connection limit (memory limitasyon); nangangailangan ng BLUETOOTH_SCAN at BLUETOOTH_CONNECT permissions (Android 12+); foreground service ay kinakailangan para sa maaasahang pag-scan sa background
• Flutter — flutter_blue_plus package ay nag-aabstrak ng platform API sa pamamagitan ng pinag-isang Dart interface: code para sa pag-scan at GATT operations ay magkapareho sa parehong platform

Ayon sa Bluetooth SIG tests (2024), ang BLE connection time ng smartphone na may fitness bracelet ay average na 150–300 ms sa Android at 100–250 ms sa iOS — ang pagkakaiba ay dahil sa radio module management policies.

Halimbawa ng BLE connection sa Dart (Flutter)

import 'package:flutter_blue_plus/flutter_blue_plus.dart';

class BleService {
  final FlutterBluePlus fbp = FlutterBluePlus();

  Future<void> scanAndConnect(String deviceName) async {
    await fbp.startScan(timeout: Duration(seconds: 15));

    await for (final result in fbp.scanResults) {
      if (result.device.advName == deviceName) {
        await fbp.stopScan();
        await result.device.connect();
        break;
      }
    }
  }
}

Ang Flutter developer ay nakakakuha ng pinag-isang API interface, kung saan ang flutter_blue_plus ay nagsasalin ng mga tawag sa native android.bluetooth o Core Bluetooth. Ang approach na ito ay nagbabawas ng oras ng pag-develop ng application para sa pagtatrabaho sa BLE peripherals sa parehong platform.