Advertising Data ใน BLE: คืออะไร โครงสร้างและประเภทข้อมูล
Advertising Data คือข้อมูลที่มีโครงสร้างซึ่งอุปกรณ์ BLE ส่งในแพ็กเก็ตโฆษณาเพื่อระบุตัวตนและบริการของตน Bluetooth Core Specification 5.4 (2023) กำหนดรูปแบบ AD Structure: แต่ละองค์ประกอบประกอบด้วยความยาว (1 ไบต์), ประเภท (1 ไบต์) และค่า (สูงสุด 29 ไบต์) ข้อกำหนดอธิบายประเภท AD มากกว่า 30 ประเภท — ตั้งแต่ Flags และ Local Name ไปจนถึง Service UUID และ Manufacturer Specific Data การบรรจุ advertising data ที่ถูกต้องมีความสำคัญต่อความเข้ากันได้ของอุปกรณ์กับ iOS, Android และแพลตฟอร์มอื่น ๆ และยังกำหนดความเร็วในการค้นหาและประสิทธิภาพการใช้พลังงานของการโฆษณา
ประเด็นสำคัญ
- AD Structure คือรูปแบบข้อมูลในแพ็กเก็ตโฆษณา BLE: ความยาว (1 ไบต์), ประเภท (1 ไบต์), ค่า (สูงสุด 29 ไบต์)
- แพ็กเก็ตโฆษณาถูกจำกัดที่ 31 ไบต์, scan response ให้อีก 31 ไบต์สำหรับข้อมูลเพิ่มเติม
- Flags (0x01) เป็นประเภท AD ที่จำเป็นซึ่งกำหนดโหมด LE Limited Discoverable และ BR/EDR Not Supported
- Service UUID ถูกส่งในรูปแบบย่อ (2 ไบต์) หรือแบบเต็ม (16 ไบต์)
- Manufacturer Specific Data (0xFF) เป็น ประเภทที่ยืดหยุ่น สำหรับข้อมูลที่กำหนดเองของผู้ผลิต
Advertising Data คืออะไร?
Advertising Data คือชุดฟิลด์ที่มีโครงสร้างซึ่งอุปกรณ์ BLE ส่งในแพ็กเก็ตโฆษณาเพื่อระบุตัวตนและอธิบายความสามารถของตน Central สแกนคลื่นอากาศ อ่านข้อมูลนี้ และตัดสินใจ: เชื่อมต่อกับอุปกรณ์ ไม่สนใจ หรือขอข้อมูลเพิ่มเติมผ่าน Scan Response
ข้อมูลถูกจัดระเบียบตามหลักการ TLV (Type-Length-Value): แต่ละองค์ประกอบ AD ประกอบด้วยสามฟิลด์ Length (1 ไบต์) คือความยาวของ Value + Type (นั่นคือความยาวรวมขององค์ประกอบลบ 1 ไบต์สำหรับ Length) Type (1 ไบต์) คือตัวระบุประเภทข้อมูลจาก Bluetooth Assigned Numbers Value (N ไบต์) คือเนื้อหาขึ้นอยู่กับประเภท
แพ็กเก็ตโฆษณามาตรฐานสามารถบรรจุข้อมูล AD ได้สูงสุด 31 ไบต์ หากไม่เพียงพอ จะใช้ Scan Response (อีก 31 ไบต์) หรือ Extended Advertising (BLE 5.0, สูงสุด 251 ไบต์) ไบต์แรกของแพ็กเก็ตโฆษณาสงวนไว้สำหรับส่วนหัว PDU และที่อยู่อุปกรณ์ — ข้อมูลเพย์โหลด AD เริ่มต้นที่ออฟเซ็ต
รูปแบบ AD Structure
แต่ละองค์ประกอบ AD ในแพ็กเก็ตโฆษณาเริ่มต้นด้วยฟิลด์ Length (1 ไบต์) ค่า Length ระบุจำนวนไบต์ที่ตามหลัง Length — นั่นคือ Type + Value ตัวอย่างเช่น องค์ประกอบที่มี Length=3 หมายความว่าหลัง Length มี 1 ไบต์ Type และ 2 ไบต์ Value แพ็กเก็ตสิ้นสุดเมื่อผลรวมความยาวขององค์ประกอบทั้งหมดถึงขนาดข้อมูลโฆษณา
| ฟิลด์ | ขนาด | คำอธิบาย |
|---|---|---|
| Length | 1 ไบต์ | ความยาวของ Type + Value (ไม่รวม Length) |
| Type (AD Type) | 1 ไบต์ | ตัวระบุประเภทข้อมูลจาก Bluetooth SIG |
| Value | 0–29 ไบต์ | ข้อมูลของประเภทที่ระบุ |
ตัวแยกวิเคราะห์ Central อ่านลำดับขององค์ประกอบ AD โดยเริ่มจากไบต์แรกหลังจากส่วนหัว ถ้า Length=0 องค์ประกอบจะถูกข้ามไปและตัวแยกวิเคราะห์จะไปยังไบต์ถัดไป ประเภท AD ที่ซ้ำกัน (หลายองค์ประกอบที่มี Type เดียวกันในแพ็กเก็ตเดียว) อนุญาตให้มีได้ แต่ Central อาจประมวลผลเฉพาะองค์ประกอบแรกหรือสุดท้ายขึ้นอยู่กับการใช้งานสแต็ก
กฎสำคัญ: ผลรวมของ Length(+1) ทั้งหมดในแพ็กเก็ตต้องไม่เกินขนาดข้อมูลโฆษณา (31 ไบต์สำหรับ advertising PDU) หากข้อมูลไม่พอ ต้องกำหนดลำดับความสำคัญ — ประเภท AD ใดที่จำเป็นสำหรับการค้นหาเบื้องต้นและประเภทใดที่สามารถย้ายไปยัง Scan Response
Flags (0x01): ประเภท AD ที่จำเป็น
Flags (AD Type 0x01) เป็นองค์ประกอบที่จำเป็นในแพ็กเก็ตโฆษณาของอุปกรณ์ BLE ทุกเครื่อง ใช้พื้นที่ 3 ไบต์: Length (0x02), Type (0x01), Value (1 ไบต์ของบิตแฟล็ก) แฟล็กกำหนดโหมดการค้นหาและความสามารถของอุปกรณ์ Core Specification แนะนำให้รวม Flags ในทุกแพ็กเก็ตโฆษณา
แฟล็กหลัก: LE Limited Discoverable Mode (บิต 0) — อุปกรณ์สามารถค้นพบได้ในเวลาจำกัด LE General Discoverable Mode (บิต 1) — อุปกรณ์สามารถค้นพบได้ตลอดเวลา BR/EDR Not Supported (บิต 2) — อุปกรณ์รองรับเฉพาะ LE Simultaneous LE and BR/EDR (บิต 3) — รองรับทั้งสองโหมด สำหรับอุปกรณ์ BLE ล้วน ๆ การรวมกัน LE General Discoverable + BR/EDR Not Supported เป็นสิ่งจำเป็น
ค่า Flags ที่ไม่ถูกต้องเป็นสาเหตุหนึ่งที่พบบ่อยที่ทำให้อุปกรณ์ไม่ถูกตรวจพบบน iOS หรือ Android ตัวอย่างเช่น หากไม่ได้ตั้งค่าแฟล็ก BR/EDR Not Supported iOS อาจพยายามเชื่อมต่อผ่าน Bluetooth แบบคลาสสิกแทน BLE ตรวจสอบค่า Flags เมื่อดีบักแพ็กเก็ตโฆษณาด้วยเครื่องวิเคราะห์ Bluetooth (nRF Connect, Wireshark)
Local Name: ชื่ออุปกรณ์
Local Name (AD Type 0x08 หรือ 0x09) คือชื่อที่แสดงของอุปกรณ์ BLE Type 0x08 (Shortened Local Name) คือชื่อย่อ ใช้เมื่อชื่อเต็มไม่พอในแพ็กเก็ตโฆษณา Type 0x09 (Complete Local Name) คือชื่อเต็มของอุปกรณ์ ความยาวชื่อสูงสุดคือ 248 ไบต์ แต่ในแพ็กเก็ตโฆษณามาตรฐานมีให้ใช้ไม่เกิน 28 ไบต์
หากชื่ออุปกรณ์เกินพื้นที่ว่างในแพ็กเก็ตโฆษณา แนะนำให้วางชื่อย่อใน advertising PDU (ประเภท 0x08) และชื่อเต็มใน Scan Response (ประเภท 0x09) iOS แสดงชื่อจากแพ็กเก็ตโฆษณาระหว่างการสแกน ในขณะที่ชื่อเต็มจะพร้อมใช้งานหลังจากการเชื่อมต่อหรือ Scan Response
เมื่อเลือกชื่ออุปกรณ์ โปรดทราบว่าชื่อที่ยาวเกินไปกินพื้นที่ซึ่งอาจใช้สำหรับ Service UUID หรือข้อมูลสำคัญอื่น ๆ ความยาวชื่อที่แนะนำคือ 8–16 อักขระ หลีกเลี่ยงอักขระที่ไม่ได้มาตรฐานและช่องว่าง — สแต็ก BLE บางตัวอาจจัดการได้ไม่ถูกต้อง
Service UUID: การระบุบริการ
Service UUID (AD Type 0x02–0x07) เป็นหนึ่งในประเภท AD ที่สำคัญที่สุด ช่วยให้ Central ระบุบริการที่อุปกรณ์ให้บริการโดยไม่ต้องเชื่อมต่อ Bluetooth SIG กำหนดรูปแบบการส่ง UUID หลายแบบขึ้นอยู่กับขนาด: 0x02 (Incomplete 16-bit), 0x03 (Complete 16-bit), 0x04 (Incomplete 32-bit), 0x05 (Complete 32-bit), 0x06 (Incomplete 128-bit), 0x07 (Complete 128-bit)
UUID 16 บิต (2 ไบต์) สำหรับบริการ Bluetooth SIG มาตรฐาน เช่น 0x180F (Battery Service), 0x180A (Device Information) UUID 128 บิต (16 ไบต์) สำหรับบริการที่กำหนดเองโดยนักพัฒนา UUID 16 บิตใช้พื้นที่เพียง 4 ไบต์ใน AD (Length + Type + 2 ไบต์ UUID) ในขณะที่ UUID 128 บิตใช้ 18 ไบต์ หากต้องส่ง UUID ที่กำหนดเองหลายรายการในแพ็กเก็ตเดียว อาจไม่พอใน 31 ไบต์
แนะนำให้ใช้ประเภท Incomplete (0x02/0x04/0x06) หากไม่ได้ส่ง UUID ทั้งหมดของอุปกรณ์ มีเพียงที่สำคัญที่สุดสำหรับการกรอง รายการ UUID ทั้งหมดจะถูกส่งผ่าน Scan Response หรือ GATT Discovery หลังการเชื่อมต่อ ซึ่งช่วยประหยัดพื้นที่ในแพ็กเก็ตโฆษณาสำหรับประเภท AD อื่น ๆ
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) เป็นประเภท AD ที่ยืดหยุ่นที่สุด ออกแบบมาเพื่อส่งข้อมูลที่กำหนดเองของผู้ผลิต 2 ไบต์แรกของ Value คือ Company Identifier Code ที่กำหนดโดย Bluetooth SIG (เช่น 0x004C สำหรับ Apple, 0x0075 สำหรับ Samsung) ไบต์ที่เหลือเป็นข้อมูลตามอำเภอใจในรูปแบบที่ผู้ผลิตกำหนด
Apple ใช้ Manufacturer Data สำหรับ iBeacon: Company ID (0x004C), ประเภท Beacon (0x0215), UUID (16 ไบต์), Major (2 ไบต์), Minor (2 ไบต์), TX Power (1 ไบต์) Google ใช้รูปแบบคล้ายกันสำหรับ Eddystone ผู้ผลิตอุปกรณ์ IoT มักวางค่าอ่านเซ็นเซอร์หรือสถานะอุปกรณ์ใน Manufacturer Data
js
// Parse Manufacturer Specific Data on Central
function parseManufacturerData(data) {
const view = new DataView(data.buffer);
// Company Identifier Code (first 2 bytes)
const companyId = view.getUint16(0, true);
// Check for Apple iBeacon
if (companyId === 0x004C) {
return parseIBeacon(view);
}
return null;
}เมื่อใช้ Manufacturer Data สิ่งสำคัญคือต้องปฏิบัติตาม ข้อจำกัดด้านขนาด: 31 ไบต์สำหรับแพ็กเก็ตโฆษณาทั้งหมดลบประเภท AD ที่จำเป็น สำหรับ Apple iBeacon แพ็กเก็ตทั้งหมดใช้พื้นที่ 30 ไบต์ เหลือพื้นที่สำหรับ Flags เท่านั้น (3 ไบต์) สำหรับ Eddystone — สูงสุด 31 ไบต์ รูปแบบที่กำหนดเองขนาดกะทัดรัดสามารถรวมอุณหภูมิ ความชื้น หรือความดันใน 4–8 ไบต์
กลยุทธ์การบรรจุข้อมูล
การบรรจุ advertising data ที่ถูกต้อง คือศิลปะการวางข้อมูลที่มีประโยชน์สูงสุดในพื้นที่จำกัด 31 ไบต์ กลยุทธ์ขึ้นอยู่กับวัตถุประสงค์ของอุปกรณ์: บีคอนต้องการตัวระบุ เซ็นเซอร์ IoT ต้องการค่าอ่าน เครื่องติดตามฟิตเนสต้องการชื่อและ UUID ของบริการ หลักการทั่วไป: ยิ่ง Central ต้องตัดสินใจเร็วเท่าไร ข้อมูลใน advertising PDU ก็ยิ่งสำคัญมากขึ้นเท่านั้น
กลยุทธ์ที่แนะนำ: advertising PDU (31 ไบต์แรก) — Flags (3 ไบต์) + Service UUID 16 บิตหนึ่งรายการ (4 ไบต์) + ชื่อย่อ (สูงสุด 12 อักขระ = 14 ไบต์) + Manufacturer Data (สูงสุด 10 ไบต์) Scan Response (31 ไบต์ที่สอง) — ชื่อเต็ม (ส่วนที่เหลือ) + Service UUID เพิ่มเติม + TX Power Level (3 ไบต์) การกระจายนี้ช่วยให้ Central กรองอุปกรณ์ตาม UUID ได้อย่างรวดเร็ว
| ลำดับความสำคัญ | ประเภท AD | ขนาด | วางใน |
|---|---|---|---|
| 1 (จำเป็น) | Flags (0x01) | 3 ไบต์ | Advertising PDU |
| 2 (การกรอง) | Service UUID (0x02–0x03) | 4+ ไบต์ | Advertising PDU |
| 3 (การระบุ) | Local Name (0x08–0x09) | 2+ ไบต์ | Advertising PDU (ย่อ) |
| 4 (เพิ่มเติม) | TX Power Level (0x0A) | 3 ไบต์ | Scan Response |
| 5 (กำหนดเอง) | Manufacturer Data (0xFF) | 4+ ไบต์ | Advertising PDU / Scan Response |
| 6 (ข้อมูลเต็ม) | UUID ที่เหลือ | ตามขนาด | Scan Response |
การดีบัก advertising data เป็นขั้นตอนบังคับในการพัฒนาอุปกรณ์ BLE ใช้ nRF Connect (Nordic Semiconductor) หรือ Wireshark กับเครื่องวิเคราะห์ Bluetooth เพื่อดูข้อมูลดิบของแพ็กเก็ต ตรวจสอบว่าประเภท AD ทั้งหมดมี Length ที่ถูกต้อง ผลรวมความยาวไม่เกิน 31 ไบต์ และ Flags ถูกตั้งค่าอย่างถูกต้องสำหรับกรณีการใช้งานของคุณ
คำถามที่พบบ่อย
เกิดอะไรขึ้นถ้าผลรวมขององค์ประกอบ AD เกิน 31 ไบต์?
สแต็ก Bluetooth Controller จะทิ้งข้อมูลที่เกินขีดจำกัดหรือไม่ส่งแพ็กเก็ต ตรวจสอบความยาวรวม ขององค์ประกอบ AD เมื่อประกอบแพ็กเก็ตโฆษณา หากข้อมูลไม่พอ ให้ย้ายส่วนหนึ่งไปยัง Scan Response หรือใช้ Extended Advertising (BLE 5.0) ด้วยขีดจำกัด 251 ไบต์
สามารถส่งค่าอ่านเซ็นเซอร์ในแพ็กเก็ตโฆษณาได้หรือไม่?
ได้ ผ่าน Manufacturer Specific Data (0xFF) บรรจุค่าอ่านใน 4–8 ไบต์: ตัวอย่างเช่น อุณหภูมิ (2 ไบต์ในรูปแบบ fixed-point), ความชื้น (2 ไบต์), แรงดันแบตเตอรี่ (2 ไบต์) วิธีการนี้ช่วยให้ Central อ่านข้อมูลได้โดยไม่ต้องเชื่อมต่อ ประหยัดพลังงาน
ควรใช้ประเภท AD ใดสำหรับบริการที่กำหนดเอง?
สำหรับบริการที่กำหนดเอง ให้ใช้ UUID 128 บิต (AD Type 0x06–0x07) ถ้า UUID ไม่พอใน advertising PDU (16 ไบต์ต่อ UUID) ให้ย้ายไปยัง Scan Response หรือใช้รูปแบบย่อ Incomplete (0x06) เพื่อระบุเฉพาะ UUID หนึ่งหรือสองรายการแรก
อะไรคือความแตกต่างระหว่างประเภท Complete และ Incomplete ของ Service UUID?
Complete — ในแพ็กเก็ตมีรายการ UUID บริการทั้งหมดของอุปกรณ์ Incomplete — เพียงส่วนหนึ่งของ UUID (โดยปกติคือที่สำคัญที่สุด) Central ไม่สามารถพึ่งพา Incomplete เป็นรายการทั้งหมดได้ แต่ใช้สำหรับการกรองอย่างรวดเร็ว รายการทั้งหมดพร้อมใช้งานหลัง GATT Discovery
ทำไม iOS ถึงไม่เห็นอุปกรณ์ BLE ของฉัน?
สาเหตุทั่วไปคือ Flags (0x01) ไม่ถูกต้อง ตรวจสอบให้แน่ใจว่าบิต BR/EDR Not Support ได้รับการตั้งค่าแล้ว สาเหตุที่สองคือไม่มี Service UUID ในแพ็กเก็ตโฆษณา (iOS กรองตาม UUID) สาเหตุที่สามคืออุปกรณ์โฆษณาน้อยเกินไป (iOS คาดหวังช่วงเวลาไม่เกิน 1000 มิลลิวินาที)
สรุป
- Advertising Data คือข้อมูลที่มีโครงสร้างในรูปแบบ AD Structure (Length-Type-Value) ที่ส่งในแพ็กเก็ตโฆษณา BLE
- แพ็กเก็ตโฆษณามาตรฐานบรรจุข้อมูลได้สูงสุด 31 ไบต์ Scan Response ให้อีก 31 ไบต์สำหรับข้อมูลเพิ่มเติม
- Flags (0x01) เป็นประเภท AD ที่จำเป็นซึ่งกำหนดโหมดการค้นหา BR/EDR Not Supported เป็นสิ่งจำเป็นสำหรับอุปกรณ์ BLE
- Service UUID ถูกส่งในรูปแบบ 16 บิต (2 ไบต์) หรือ 128 บิต (16 ไบต์) แบบ Complete หรือ Incomplete ขึ้นอยู่กับพื้นที่ว่าง
- Manufacturer Specific Data (0xFF) เป็นประเภทที่ยืดหยุ่นสำหรับข้อมูลที่กำหนดเอง ใช้ในบีคอน iBeacon, Eddystone และอุปกรณ์ IoT
- กลยุทธ์การบรรจุ: ประเภท AD ที่จำเป็น (Flags, Service UUID, ชื่อย่อ) ใน advertising PDU; ส่วนเพิ่มเติมใน Scan Response
- ดีบัก advertising data โดยใช้ nRF Connect หรือ Wireshark — ขั้นตอนการพัฒนาที่จำเป็นเพื่อตรวจสอบโครงสร้าง AD ที่ถูกต้อง
เราจะพัฒนาแอปพลิเคชันบนมือถือแบบครบวงจร
IT Sectr สร้างแอปพลิเคชัน iOS และ Android สำหรับสตาร์ทอัพและธุรกิจตั้งแต่ปี 2017 เราจะให้คำแนะนำและเสนอวิธีแก้ปัญหาที่ดีที่สุดแก่คุณ
อ่านเพิ่มเติม