Advertising Data sa BLE: istraktura at mga uri ng data
Advertising Data — ay mga nakaayos na data na ipinapadala ng BLE device sa mga advertisement packet upang kilalanin ang sarili at mga serbisyo nito. Bluetooth Core Specification 5.4 (2023) ay tumutukoy sa format ng AD Structure: bawat elemento ay naglalaman ng haba (1 byte), uri (1 byte), at halaga (hanggang 29 bytes). Ang spec ay naglalarawan ng higit sa 30 uri ng AD — mula Flags at Local Name hanggang Service UUID at Manufacturer Specific Data. Ang tamang pag-pack ng advertising data ay kritikal para sa compatibility ng device sa iOS, Android at iba pang platform, at tinutukoy ang bilis ng detection at energy efficiency ng advertisement.
Mga pangunahing punto
- AD Structure — format ng data sa BLE advertisement packet: haba (1 byte), uri (1 byte), halaga (hanggang 29 bytes).
- Ang advertisement packet ay limitado sa 31 bytes, scan response — 31 bytes pa para sa karagdagang data.
- Flags (0x01) — mandatoryong uri ng AD na tumutukoy sa mga mode na LE Limited Discoverable at BR/EDR Not Supported.
- Ang Service UUID ay ipinapadala sa pinaikling (2 bytes) o kumpletong (16 bytes) format.
- Manufacturer Specific Data (0xFF) — flexible na uri para sa anumang custom na data ng manufacturer.
Ano ang Advertising Data?
Advertising Data — ay isang nakaayos na set ng mga field na ipinapadala ng BLE device sa mga advertisement packet upang kilalanin at ilarawan ang mga kakayahan nito. Ang Central, sa pag-scan ng channel, ay binabasa ang mga data na ito at gumagawa ng desisyon: kumonekta sa device, huwag pansinin ito, o humiling ng karagdagang impormasyon sa pamamagitan ng Scan Response.
Ang data ay nakaayos ayon sa prinsipyo ng TLV (Type-Length-Value): bawat AD element ay binubuo ng tatlong field. Length (1 byte) — haba ng Value + Type (ibig sabihin, kabuuang haba ng element minus 1 byte para sa Length). Type (1 byte) — identifier ng uri ng data mula sa Bluetooth Assigned Numbers. Value (N bytes) — nilalaman depende sa uri.
Ang standard na advertisement packet ay maaaring maglaman ng hanggang 31 bytes ng AD data. Kung hindi ito sapat, ginagamit ang Scan Response (31 bytes pa) o Extended Advertising (BLE 5.0, hanggang 251 bytes). Ang mga unang byte ng advertisement packet ay nakalaan para sa PDU header at address ng device — ang AD payload ay nagsisimula sa isang offset.
Format ng AD Structure
Bawat AD element sa advertisement packet ay nagsisimula sa field na Length (1 byte). Ang halaga ng Length ay nagpapahiwatig ng bilang ng mga byte pagkatapos ng Length — i.e. Type + Value. Halimbawa, ang element na may Length=3 ay nangangahulugan na pagkatapos ng Length ay may 1 byte Type at 2 bytes Value. Nagtatapos ang packet kapag ang kabuuan ng haba ng lahat ng element ay umabot sa laki ng advertisement data.
| Field | Laki | Deskripsyon |
|---|---|---|
| Length | 1 byte | Haba ng Type + Value (hindi kasama ang Length) |
| Type (AD Type) | 1 byte | Identifier ng uri ng data ayon sa Bluetooth SIG |
| Value | 0–29 bytes | Data ng isang partikular na uri |
Ang parser ng Central ay bumabasa ng sequence ng mga AD element simula sa unang byte pagkatapos ng header. Kung Length=0, ang element ay hindi pinapansin at ang parser ay lumipat sa susunod na byte. Mga duplicate na uri ng AD — maraming element na may parehong Type sa isang packet — ay pinapayagan, ngunit ang Central ay maaaring magproseso lamang ng una o huli depende sa implementation ng stack.
Mahalagang patakaran: ang kabuuan ng lahat ng Length(+1) sa packet ay hindi dapat lumampas sa laki ng advertisement data (31 bytes para sa advertisement PDU). Kung hindi kasya ang data, kailangang mag-prioritize — aling mga uri ng AD ang kritikal para sa primary detection at alin ang maaaring ilipat sa Scan Response.
Flags (0x01): mandatoryong uri ng AD
Flags (AD Type 0x01) — mandatoryong elemento sa advertisement packet ng bawat BLE device. Sumasakop ito ng 3 bytes: Length (0x02), Type (0x01), Value (1 byte ng bit flags). Tinutukoy ng flags ang mga mode ng detection at kakayahan ng device. Inirerekomenda ng Core Specification na isama ang Flags sa bawat advertisement packet.
Pangunahing flags: LE Limited Discoverable Mode (bit 0) — device ay makikita para sa limitadong oras, LE General Discoverable Mode (bit 1) — device ay permanenteng makikita, BR/EDR Not Supported (bit 2) — device ay sumusuporta lamang sa LE, Simultaneous LE and BR/EDR (bit 3) — suporta para sa parehong mode. Para sa purong BLE device, mandatoryong kumbinasyon: LE General Discoverable + BR/EDR Not Supported.
Ang maling halaga ng Flags ay isa sa mga karaniwang dahilan kung bakit hindi nakikita ang device sa iOS o Android. Halimbawa, kung ang flag na BR/EDR Not Supported ay hindi nakatakda, maaaring subukan ng iOS na kumonekta sa pamamagitan ng classic Bluetooth sa halip na BLE. Suriin ang halaga ng Flags kapag nagde-debug ng advertisement packet gamit ang Bluetooth analyzer (nRF Connect, Wireshark).
Local Name: pangalan ng device
Local Name (AD Type 0x08 o 0x09) — ang ipinapakitang pangalan ng BLE device. Uri 0x08 (Shortened Local Name) — pinaikling pangalan, ginagamit kapag ang buong pangalan ay hindi kasya sa advertisement packet. Uri 0x09 (Complete Local Name) — buong pangalan ng device. Ang maximum na haba ng pangalan ay 248 bytes, ngunit sa standard na advertisement packet ay hindi hihigit sa 28 bytes ang available.
Kung ang pangalan ng device ay lumampas sa available na espasyo sa advertisement packet, inirerekomenda: ilagay ang pinaikling pangalan sa advertisement PDU (uri 0x08), at ang buong pangalan sa Scan Response (uri 0x09). Ipinapakita ng iOS ang pangalan mula sa advertisement packet kapag nag-scan, at ang buong pangalan ay magiging available pagkatapos ng koneksyon o Scan Response.
Kapag pumipili ng pangalan ng device, isaalang-alang: ang sobrang haba na pangalan ay kumukuha ng espasyo na maaaring gamitin para sa Service UUID o iba pang mahalagang data. Inirerekomendang haba ng pangalan ay 8–16 karakter. Iwasan ang mga hindi standard na karakter at espasyo — maaaring hindi ito ma-proseso nang tama ng ilang BLE stack.
Service UUID: pagkilala sa mga serbisyo
Service UUID (AD Type 0x02–0x07) — isa sa pinakamahalagang uri ng AD, na nagpapahintulot sa Central na matukoy kung anong mga serbisyo ang ibinibigay ng device nang hindi kumokonekta dito. Tinutukoy ng Bluetooth SIG ang ilang format ng pagpapadala ng UUID depende sa laki: 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 bytes) — standard na serbisyo ng Bluetooth SIG, halimbawa 0x180F (Battery Service), 0x180A (Device Information). 128-bit UUID (16 bytes) — custom na serbisyo na tinutukoy ng developer. Ang 16-bit UUID ay sumasakop lamang ng 4 bytes sa AD (Length + Type + 2 bytes UUID), at 128-bit — 18 bytes. Kung kailangang magpadala ng maraming custom na UUID sa isang packet, maaaring hindi sila magkasya sa 31 bytes.
Inirerekomenda na gamitin ang uri na Incomplete (0x02/0x04/0x06) kung hindi lahat ng UUID ng device ay ipinapadala, kundi ang pinakamahalaga lamang para sa pag-filter. Ang buong listahan ng UUID ay ipinapadala sa pamamagitan ng Scan Response o GATT Discovery pagkatapos ng koneksyon. Ito ay nakakatipid ng espasyo sa advertisement packet para sa iba pang uri ng AD.
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) — ang pinaka-flexible na uri ng AD, na idinisenyo para sa pagpapadala ng custom na data ng manufacturer. Ang unang 2 bytes ng Value ay Company Identifier Code, na itinalaga ng Bluetooth SIG (halimbawa, 0x004C para sa Apple, 0x0075 para sa Samsung). Ang natitirang bytes ay arbitraryong data sa format na tinukoy ng manufacturer.
Ginagamit ng Apple ang Manufacturer Data para sa iBeacon: Company ID (0x004C), uri ng Beacon (0x0215), UUID (16 bytes), Major (2 bytes), Minor (2 bytes), TX Power (1 byte). Gumagamit ang Google ng katulad na format para sa Eddystone. Ang mga manufacturer ng IoT device ay madalas na naglalagay ng mga pagbabasa ng sensor o estado ng device sa Manufacturer Data.
js
// I-parse ang Manufacturer Specific Data sa Central
function parseManufacturerData(data) {
const view = new DataView(data.buffer);
// Company Identifier Code (unang 2 bytes)
const companyId = view.getUint16(0, true);
// Suriin ang Apple iBeacon
if (companyId === 0x004C) {
return parseIBeacon(view);
}
return null;
}Kapag gumagamit ng Manufacturer Data, mahalagang sundin ang limitasyon sa laki: 31 bytes para sa buong advertisement packet minus mandatoryong uri ng AD. Para sa Apple iBeacon, ang buong packet ay sumasakop ng 30 bytes, nag-iiwan ng espasyo para lamang sa Flags (3 bytes). Para sa Eddystone — hanggang 31 bytes. Ang mga compact na custom na format ay maaaring magsama ng temperatura, halumigmig, o presyon sa 4–8 bytes.
Estratehiya sa pag-pack ng data
Ang tamang pag-pack ng advertising data — ay ang sining ng paglalagay ng maximum na kapaki-pakinabang na impormasyon sa limitadong espasyo na 31 bytes. Ang estratehiya ay depende sa layunin ng device: ang beacon ay nangangailangan ng identifier, ang IoT sensor ay nangangailangan ng pagbabasa, ang fitness tracker ay nangangailangan ng pangalan at UUID ng mga serbisyo. Pangkalahatang prinsipyo: mas mabilis na kailangang gumawa ng desisyon ang Central, mas kritikal na data ang dapat nasa advertisement PDU.
Inirerekomendang estratehiya: advertisement PDU (unang 31 bytes) — Flags (3 bytes) + isang 16-bit Service UUID (4 bytes) + pinaikling pangalan (hanggang 12 karakter = 14 bytes) + Manufacturer Data (hanggang 10 bytes). Scan Response (pangalawang 31 bytes) — buong pangalan (natitira) + karagdagang Service UUID + TX Power Level (3 bytes). Ang paghahati na ito ay nagpapahintulot sa Central na mabilis na i-filter ang mga device ayon sa UUID.
| Priyoridad | Uri ng AD | Laki | Ilagay sa |
|---|---|---|---|
| 1 (mandatoryo) | Flags (0x01) | 3 bytes | Advertisement PDU |
| 2 (pag-filter) | Service UUID (0x02–0x03) | 4+ bytes | Advertisement PDU |
| 3 (pagkilala) | Local Name (0x08–0x09) | 2+ bytes | Advertisement PDU (pinaikli) |
| 4 (karagdagang) | TX Power Level (0x0A) | 3 bytes | Scan Response |
| 5 (custom) | Manufacturer Data (0xFF) | 4+ bytes | Advertisement PDU / Scan Response |
| 6 (buong data) | Iba pang UUID | Ayon sa laki | Scan Response |
Ang pag-debug ng advertising data ay isang mandatoryong yugto ng pag-develop ng BLE device. Gamitin ang nRF Connect (Nordic Semiconductor) o Wireshark na may Bluetooth analyzer upang tingnan ang raw data ng packet. Suriin na ang lahat ng uri ng AD ay may tamang Length, na ang kabuuan ng mga haba ay hindi lalampas sa 31 bytes, at ang Flags ay nakatakda nang tama para sa iyong senaryo ng paggamit.
Mga madalas itanong
Ano ang mangyayari kung ang kabuuan ng mga AD element ay lumampas sa 31 bytes?
Ang Bluetooth Controller stack ay tatanggihan ang data na lumalampas sa limitasyon o hindi magpapadala ng packet. Suriin ang kabuuang haba ng mga AD element kapag binubuo ang advertisement packet. Kung hindi kasya ang data — ilipat ang bahagi sa Scan Response o gamitin ang Extended Advertising (BLE 5.0) na may limit na 251 bytes.
Maaari bang magpadala ng mga pagbabasa ng sensor sa advertisement packet?
Oo, sa pamamagitan ng Manufacturer Specific Data (0xFF). I-pack ang mga pagbabasa sa 4–8 bytes: halimbawa, temperatura (2 bytes sa fixed-point format), halumigmig (2 bytes), boltahe ng baterya (2 bytes). Ang approach na ito ay nagpapahintulot sa Central na magbasa ng data nang walang koneksyon, nakakatipid ng enerhiya.
Anong uri ng AD ang gagamitin para sa custom na serbisyo?
Para sa custom na serbisyo, gamitin ang 128-bit UUID (AD Type 0x06–0x07). Kung ang UUID ay hindi kasya sa advertisement PDU (16 bytes para sa isang UUID), ilipat ito sa Scan Response o gamitin ang pinaikling format na Incomplete (0x06) upang ipakita lamang ang una o dalawang UUID.
Ano ang pagkakaiba ng Complete at Incomplete na uri ng Service UUID?
Complete — sa packet ay nakalista ang lahat ng UUID ng mga serbisyo ng device. Incomplete — bahagi lamang ng UUID (karaniwan ang pinakamahalaga). Hindi maaaring umasa ang Central sa Incomplete bilang kumpletong listahan, ngunit ginagamit ito para sa mabilis na pag-filter. Ang buong listahan ay available pagkatapos ng GATT Discovery.
Bakit hindi nakikita ng iOS ang aking BLE device?
Karaniwang dahilan — maling Flags (0x01). Tiyakin na ang bit BR/EDR Not Supported ay nakatakda. Pangalawang dahilan — kawalan ng Service UUID sa advertisement packet (nag-fi-filter ang iOS ayon sa UUID). Pangatlo — ang device ay nag-a-advertise nang napakabihirang (inaasahan ng iOS ang interval na hindi hihigit sa 1000 ms).
Buod
- Advertising Data — nakaayos na data sa AD Structure format (Length-Type-Value), na ipinapadala sa mga BLE advertisement packet.
- Ang standard na advertisement packet ay naglalaman ng hanggang 31 bytes ng data, Scan Response — 31 bytes pa para sa karagdagang impormasyon.
- Flags (0x01) — mandatoryong uri ng AD na tumutukoy sa mga mode ng detection. Para sa BLE device, mandatory ang BR/EDR Not Supported.
- Ang Service UUID ay ipinapadala sa 16-bit (2 bytes) o 128-bit (16 bytes) na format, Complete o Incomplete — depende sa available na espasyo.
- Manufacturer Specific Data (0xFF) — flexible na uri para sa custom na data, ginagamit sa iBeacon, Eddystone beacon, at IoT device.
- Estratehiya sa pag-pack: mandatoryong uri ng AD (Flags, Service UUID, pinaikling pangalan) — sa advertisement PDU, karagdagang — sa Scan Response.
- Ang pag-debug ng advertising data sa pamamagitan ng nRF Connect o Wireshark — mandatoryong yugto ng pag-develop upang suriin ang tamang AD structure.
Gagawa kami ng mobile application na turnkey
Gumagawa ang IT Sectr ng mga iOS at Android application para sa mga startup at negosyo mula noong 2017. Magpapayo kami sa iyo at magmumungkahi ng pinakamahusay na solusyon.
Basahin din