Advertising Data di BLE: struktur dan tipe data
Advertising Data — adalah data terstruktur yang dikirimkan perangkat BLE dalam paket iklan untuk mengidentifikasi dirinya dan layanannya. Bluetooth Core Specification 5.4 (2023) mendefinisikan format AD Structure: setiap elemen berisi panjang (1 byte), tipe (1 byte), dan nilai (hingga 29 byte). Spesifikasi ini menjelaskan lebih dari 30 tipe AD — dari Flags dan Local Name hingga Service UUID dan Manufacturer Specific Data. Pengemasan advertising data yang benar sangat penting untuk kompatibilitas perangkat dengan iOS, Android, dan platform lainnya, serta menentukan kecepatan deteksi dan efisiensi energi iklan.
Poin-poin utama
- AD Structure — format data dalam paket iklan BLE: panjang (1 byte), tipe (1 byte), nilai (hingga 29 byte).
- Paket iklan dibatasi 31 byte, scan response — 31 byte lagi untuk data tambahan.
- Flags (0x01) — tipe AD wajib yang menentukan mode LE Limited Discoverable dan BR/EDR Not Supported.
- Service UUID dikirim dalam format singkat (2 byte) atau lengkap (16 byte).
- Manufacturer Specific Data (0xFF) — tipe fleksibel untuk data kustom produsen apa pun.
Apa itu Advertising Data?
Advertising Data — adalah kumpulan field terstruktur yang dikirimkan perangkat BLE dalam paket iklan untuk mengidentifikasi dan mendeskripsikan kemampuannya. Central, dengan memindai saluran, membaca data ini dan mengambil keputusan: terhubung ke perangkat, mengabaikannya, atau meminta informasi tambahan melalui Scan Response.
Data diatur berdasarkan prinsip TLV (Type-Length-Value): setiap elemen AD terdiri dari tiga field. Length (1 byte) — panjang Value + Type (yaitu total panjang elemen dikurangi 1 byte untuk Length). Type (1 byte) — pengidentifikasi tipe data dari Bluetooth Assigned Numbers. Value (N byte) — konten tergantung pada tipe.
Paket iklan standar dapat berisi hingga 31 byte data AD. Jika ini tidak cukup, digunakan Scan Response (31 byte lagi) atau Extended Advertising (BLE 5.0, hingga 251 byte). Byte pertama dari paket iklan dicadangkan untuk header PDU dan alamat perangkat — muatan AD dimulai dari offset.
Format AD Structure
Setiap elemen AD dalam paket iklan dimulai dengan field Length (1 byte). Nilai Length menunjukkan jumlah byte setelah Length — yaitu Type + Value. Misalnya, elemen dengan Length=3 berarti setelah Length ada 1 byte Type dan 2 byte Value. Paket berakhir ketika jumlah panjang semua elemen mencapai ukuran data iklan.
| Field | Ukuran | Deskripsi |
|---|---|---|
| Length | 1 byte | Panjang Type + Value (tidak termasuk Length) |
| Type (AD Type) | 1 byte | Pengidentifikasi tipe data menurut Bluetooth SIG |
| Value | 0–29 byte | Data dari tipe tertentu |
Parser Central membaca urutan elemen AD mulai dari byte pertama setelah header. Jika Length=0, elemen diabaikan dan parser beralih ke byte berikutnya. Tipe AD duplikat — beberapa elemen dengan Type yang sama dalam satu paket — diizinkan, tetapi Central mungkin hanya memproses yang pertama atau terakhir tergantung pada implementasi stack.
Aturan penting: jumlah semua Length(+1) dalam paket tidak boleh melebihi ukuran data iklan (31 byte untuk PDU iklan). Jika data tidak muat, prioritas harus ditentukan — tipe AD mana yang penting untuk deteksi utama dan mana yang dapat dipindahkan ke Scan Response.
Flags (0x01): tipe AD wajib
Flags (AD Type 0x01) — elemen wajib dalam paket iklan setiap perangkat BLE. Berukuran 3 byte: Length (0x02), Type (0x01), Value (1 byte flag bit). Flag menentukan mode deteksi dan kemampuan perangkat. Core Specification merekomendasikan menyertakan Flags di setiap paket iklan.
Flag utama: LE Limited Discoverable Mode (bit 0) — perangkat dapat dideteksi untuk waktu terbatas, LE General Discoverable Mode (bit 1) — perangkat dapat dideteksi secara permanen, BR/EDR Not Supported (bit 2) — perangkat hanya mendukung LE, Simultaneous LE and BR/EDR (bit 3) — dukungan untuk kedua mode. Untuk perangkat BLE murni, kombinasi wajib: LE General Discoverable + BR/EDR Not Supported.
Nilai Flags yang salah adalah salah satu penyebab umum mengapa perangkat tidak terdeteksi di iOS atau Android. Misalnya, jika flag BR/EDR Not Supported tidak diatur, iOS mungkin mencoba terhubung melalui Bluetooth klasik alih-alih BLE. Periksa nilai Flags saat men-debug paket iklan dengan penganalisis Bluetooth (nRF Connect, Wireshark).
Local Name: nama perangkat
Local Name (AD Type 0x08 atau 0x09) — nama tampilan perangkat BLE. Tipe 0x08 (Shortened Local Name) — nama yang dipendekkan, digunakan ketika nama lengkap tidak muat dalam paket iklan. Tipe 0x09 (Complete Local Name) — nama lengkap perangkat. Panjang maksimum nama adalah 248 byte, tetapi dalam paket iklan standar tidak tersedia lebih dari 28 byte.
Jika nama perangkat melebihi ruang yang tersedia dalam paket iklan, disarankan: tempatkan nama yang dipendekkan di PDU iklan (tipe 0x08), dan nama lengkap di Scan Response (tipe 0x09). iOS menampilkan nama dari paket iklan saat memindai, dan nama lengkap tersedia setelah koneksi atau Scan Response.
Saat memilih nama perangkat, pertimbangkan: nama yang terlalu panjang memakan ruang yang bisa digunakan untuk Service UUID atau data penting lainnya. Panjang nama yang disarankan adalah 8–16 karakter. Hindari karakter non-standar dan spasi — beberapa stack BLE mungkin memprosesnya secara tidak benar.
Service UUID: identifikasi layanan
Service UUID (AD Type 0x02–0x07) — salah satu tipe AD terpenting, yang memungkinkan Central menentukan layanan apa yang disediakan perangkat tanpa terhubung dengannya. Bluetooth SIG mendefinisikan beberapa format transmisi UUID tergantung pada ukuran: 0x02 (Incomplete 16-bit), 0x03 (Complete 16-bit), 0x04 (Incomplete 32-bit), 0x05 (Complete 32-bit), 0x06 (Incomplete 128-bit), 0x07 (Complete 128-bit).
16-bit UUID (2 byte) — layanan standar Bluetooth SIG, misalnya 0x180F (Battery Service), 0x180A (Device Information). 128-bit UUID (16 byte) — layanan kustom yang ditentukan oleh pengembang. 16-bit UUID hanya memakan 4 byte di AD (Length + Type + 2 byte UUID), sedangkan 128-bit — 18 byte. Jika beberapa UUID kustom perlu dikirim dalam satu paket, mereka mungkin tidak muat dalam 31 byte.
Disarankan menggunakan tipe Incomplete (0x02/0x04/0x06) jika tidak semua UUID perangkat dikirim, tetapi hanya yang paling penting untuk penyaringan. Daftar lengkap UUID dikirim melalui Scan Response atau GATT Discovery setelah koneksi. Ini menghemat ruang dalam paket iklan untuk tipe AD lainnya.
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) — tipe AD yang paling fleksibel, dirancang untuk mengirimkan data kustom produsen. 2 byte pertama Value adalah Company Identifier Code, yang ditetapkan oleh Bluetooth SIG (misalnya, 0x004C untuk Apple, 0x0075 untuk Samsung). Byte sisanya adalah data arbitrer dalam format yang ditentukan oleh produsen.
Apple menggunakan Manufacturer Data untuk iBeacon: Company ID (0x004C), tipe Beacon (0x0215), UUID (16 byte), Major (2 byte), Minor (2 byte), TX Power (1 byte). Google menggunakan format serupa untuk Eddystone. Produsen perangkat IoT sering menempatkan pembacaan sensor atau status perangkat di Manufacturer Data.
js
// Parsing Manufacturer Specific Data di Central
function parseManufacturerData(data) {
const view = new DataView(data.buffer);
// Kode Identifikasi Perusahaan (2 byte pertama)
const companyId = view.getUint16(0, true);
// Periksa Apple iBeacon
if (companyId === 0x004C) {
return parseIBeacon(view);
}
return null;
}Saat menggunakan Manufacturer Data, penting untuk mematuhi batasan ukuran: 31 byte untuk seluruh paket iklan dikurangi tipe AD wajib. Untuk Apple iBeacon, seluruh paket memakan 30 byte, hanya menyisakan ruang untuk Flags (3 byte). Untuk Eddystone — hingga 31 byte. Format kustom yang ringkas dapat mencakup suhu, kelembapan, atau tekanan dalam 4–8 byte.
Strategi pengemasan data
Pengemasan advertising data yang benar — adalah seni menempatkan informasi berguna maksimal dalam ruang terbatas 31 byte. Strategi tergantung pada tujuan perangkat: beacon membutuhkan pengidentifikasi, sensor IoT membutuhkan pembacaan, pelacak kebugaran membutuhkan nama dan UUID layanan. Prinsip umum: semakin cepat Central harus mengambil keputusan, semakin kritis data yang harus ada di PDU iklan.
Strategi yang disarankan: PDU iklan (31 byte pertama) — Flags (3 byte) + satu 16-bit Service UUID (4 byte) + nama dipendekkan (hingga 12 karakter = 14 byte) + Manufacturer Data (hingga 10 byte). Scan Response (31 byte kedua) — nama lengkap (sisanya) + Service UUID tambahan + TX Power Level (3 byte). Pembagian ini memungkinkan Central menyaring perangkat dengan cepat berdasarkan UUID.
| Prioritas | Tipe AD | Ukuran | Tempatkan di |
|---|---|---|---|
| 1 (wajib) | Flags (0x01) | 3 byte | PDU iklan |
| 2 (penyaringan) | Service UUID (0x02–0x03) | 4+ byte | PDU iklan |
| 3 (identifikasi) | Local Name (0x08–0x09) | 2+ byte | PDU iklan (dipendekkan) |
| 4 (tambahan) | TX Power Level (0x0A) | 3 byte | Scan Response |
| 5 (kustom) | Manufacturer Data (0xFF) | 4+ byte | PDU iklan / Scan Response |
| 6 (data lengkap) | UUID lainnya | Sesuai ukuran | Scan Response |
Debugging advertising data adalah tahap wajib dalam pengembangan perangkat BLE. Gunakan nRF Connect (Nordic Semiconductor) atau Wireshark dengan penganalisis Bluetooth untuk melihat data mentah paket. Periksa apakah semua tipe AD memiliki Length yang benar, jumlah panjang tidak melebihi 31 byte, dan Flags diatur dengan benar untuk skenario penggunaan Anda.
Pertanyaan yang sering diajukan
Apa yang terjadi jika jumlah elemen AD melebihi 31 byte?
Stack Bluetooth Controller akan menolak data yang melebihi batas atau tidak mengirim paket. Periksa panjang total elemen AD saat menyusun paket iklan. Jika data tidak muat — pindahkan sebagian ke Scan Response atau gunakan Extended Advertising (BLE 5.0) dengan batas 251 byte.
Bisakah pembacaan sensor dikirim dalam paket iklan?
Ya, melalui Manufacturer Specific Data (0xFF). Kemas pembacaan dalam 4–8 byte: misalnya, suhu (2 byte dalam format fixed-point), kelembapan (2 byte), tegangan baterai (2 byte). Pendekatan ini memungkinkan Central membaca data tanpa koneksi, menghemat energi.
Tipe AD apa yang digunakan untuk layanan kustom?
Untuk layanan kustom, gunakan 128-bit UUID (AD Type 0x06–0x07). Jika UUID tidak muat di PDU iklan (16 byte untuk satu UUID), pindahkan ke Scan Response atau gunakan format Incomplete (0x06) yang dipendekkan untuk menunjukkan hanya satu atau dua UUID pertama.
Apa perbedaan antara tipe Complete dan Incomplete Service UUID?
Complete — dalam paket, semua UUID layanan perangkat terdaftar. Incomplete — hanya sebagian UUID (biasanya yang terpenting). Central tidak dapat mengandalkan Incomplete sebagai daftar lengkap, tetapi menggunakannya untuk penyaringan cepat. Daftar lengkap tersedia setelah GATT Discovery.
Mengapa iOS tidak melihat perangkat BLE saya?
Penyebab umum — Flags (0x01) yang salah. Pastikan bit BR/EDR Not Supported diatur. Penyebab kedua — tidak adanya Service UUID dalam paket iklan (iOS menyaring berdasarkan UUID). Ketiga — perangkat beriklan terlalu jarang (iOS mengharapkan interval tidak lebih dari 1000 ms).
Ringkasan
- Advertising Data — data terstruktur dalam format AD Structure (Length-Type-Value), dikirim dalam paket iklan BLE.
- Paket iklan standar menampung hingga 31 byte data, Scan Response — 31 byte lagi untuk informasi tambahan.
- Flags (0x01) — tipe AD wajib yang menentukan mode deteksi. Untuk perangkat BLE, BR/EDR Not Supported wajib.
- Service UUID dikirim dalam format 16-bit (2 byte) atau 128-bit (16 byte), Complete atau Incomplete — tergantung ruang yang tersedia.
- Manufacturer Specific Data (0xFF) — tipe fleksibel untuk data kustom, digunakan di beacon iBeacon, Eddystone, dan perangkat IoT.
- Strategi pengemasan: tipe AD wajib (Flags, Service UUID, nama dipendekkan) — di PDU iklan, tambahan — di Scan Response.
- Debugging advertising data melalui nRF Connect atau Wireshark — tahap pengembangan wajib untuk memeriksa kebenaran struktur AD.
Kami akan mengembangkan aplikasi seluler turnkey
IT Sectr membuat aplikasi iOS dan Android untuk startup dan bisnis sejak 2017. Kami akan memberi saran dan mengusulkan solusi terbaik.
Baca juga