Advertising ใน BLE: คืออะไร รูปแบบแพ็กเก็ต และกลไกการโฆษณา

Advertising ใน BLE คืออะไร

Advertising (การโฆษณา) เป็นกระบวนการส่งแพ็กเก็ตข้อมูลสั้น ๆ เป็นระยะ ซึ่งอุปกรณ์ BLE ใช้ประกาศการมีอยู่และความพร้อมใช้งานของตน แตกต่างจาก Bluetooth แบบคลาสสิกที่การตรวจพบอุปกรณ์ใช้เวลาเป็นวินาที การโฆษณา BLE ช่วยให้ตรวจพบอุปกรณ์ได้ในระดับมิลลิวินาทีในขณะที่ใช้พลังงานน้อยที่สุด

สถาปัตยกรรม BLE แบ่งอุปกรณ์ออกเป็นสองบทบาท: Peripheral (โฆษณา) และ Central (สแกน) Peripheral ส่งแพ็กเก็ตโฆษณา ในขณะที่ Central สแกนคลื่นและตัดสินใจว่าจะเชื่อมต่อหรือไม่ โมเดลที่ไม่สมมาตรนี้เป็นข้อได้เปรียบหลักของ BLE: อุปกรณ์ที่โฆษณาจะใช้พลังงานเฉพาะในการส่งแพ็กเก็ตสั้น ๆ เท่านั้น ไม่ใช่การฟังคลื่นอย่างต่อเนื่อง

กระบวนการโฆษณาประกอบด้วยสามขั้นตอน: advertising event (การส่งแพ็กเก็ตบนทั้งสามช่องสัญญาณ) scan request/response (การแลกเปลี่ยนเพิ่มเติมกับ Central) และ connection request (การเริ่มต้นการเชื่อมต่อโดย Central) แต่ละขั้นตอนถูกจัดการโดย Bluetooth Controller ในระดับ Link Layer

ช่องสัญญาณโฆษณาและวัตถุประสงค์

BLE ใช้ 40 ช่องสัญญาณ ในย่านความถี่ 2.4 GHz โดยที่ 37 (2402 MHz), 38 (2426 MHz) และ 39 (2480 MHz) สงวนไว้สำหรับการโฆษณาโดยเฉพาะ สามช่องสัญญาณเป็นการประนีประนอมระหว่างความน่าเชื่อถือในการตรวจพบและปริมาณงาน: หนึ่งช่องสัญญาณอาจถูกครอบครองโดย Wi-Fi หรือสัญญาณรบกวนอื่น ๆ แต่อุปกรณ์จะถูกตรวจพบบนอีกสองช่องสัญญาณที่เหลือ

ช่องสัญญาณ 37 อยู่ใกล้กับช่องสัญญาณ Wi-Fi 1, ช่องสัญญาณ 39 อยู่ใกล้กับช่องสัญญาณ Wi-Fi 6 และช่องสัญญาณ 38 อยู่ระหว่างทั้งสองในบริเวณที่มีสัญญาณรบกวนน้อยที่สุด การเลือกสามช่องสัญญาณ ช่วยให้มั่นใจว่าอุปกรณ์จะถูกตรวจพบแม้ในสภาพแวดล้อมคลื่นวิทยุที่หนาแน่น — ตัวอย่างเช่น ในห้างสรรพสินค้าที่มีจุดเข้าใช้งาน Wi-Fi หลายสิบจุด

Peripheral ส่งแพ็กเก็ตโฆษณาตามลำดับบนทั้งสามช่องสัญญาณ — เรียกว่า advertising event อุปกรณ์กลางจะสแกนครั้งละหนึ่งช่องสัญญาณ โดยสลับไปมาระหว่างกันตามอัลกอริทึมที่ implemented ใน Bluetooth Controller ความน่าจะเป็นในการตรวจพบภายในหนึ่ง advertising event เมื่อไม่มีการชนกันนั้นใกล้เคียง 100%

ประเภทของแพ็กเก็ตโฆษณา

Bluetooth Core Specification กำหนด PDU การโฆษณาหลายประเภท (Protocol Data Unit) แต่ละประเภทมีวัตถุประสงค์ของตนเอง ประเภทหลักคือ: ADV_IND (connectable undirected advertising) — การโฆษณามาตรฐานที่สามารถเชื่อมต่อได้, ADV_NONCONN_IND (non-connectable undirected advertising) — การโฆษณาเท่านั้นโดยไม่มีการเชื่อมต่อ, ADV_SCAN_IND (scannable undirected advertising) — รองรับคำขอสแกน, ADV_DIRECT_IND (directed advertising) — การโฆษณาสำหรับ Central เฉพาะ

ADV_IND เป็นประเภทที่พบมากที่สุดที่ใช้ในอุปกรณ์ BLE ส่วนใหญ่ เมื่อได้รับ ADV_IND, Central สามารถส่งคำขอเชื่อมต่อและสร้างการเชื่อมต่อได้ ADV_NONCONN_IND ใช้ในบีคอน (Beacon): อุปกรณ์โฆษณาแต่ไม่รับคำขอเชื่อมต่อ — ส่งข้อมูลทางเดียวเท่านั้น

ADV_DIRECT_IND มีที่อยู่ของ Central เป้าหมาย ทำให้สามารถสร้างการเชื่อมต่อได้อย่างรวดเร็วโดยไม่ต้องรอการสแกน ใช้เมื่ออุปกรณ์ “รู้จัก” กันแล้ว — ตัวอย่างเช่น หลังจากเชื่อมต่อใหม่กับสมาร์ทโฟนที่จับคู่ไว้ก่อนหน้านี้ ประเภทนี้ลดการใช้พลังงานเนื่องจากไม่ต้องโฆษณาบนทุกช่องสัญญาณ

ช่วงเวลาโฆษณาและการใช้พลังงาน

Advertising interval คือระยะเวลาระหว่าง advertising events ที่ต่อเนื่องกัน ข้อกำหนดอนุญาตช่วงเวลาตั้งแต่ 20 ms ถึง 10.24 s โดยมีขั้นละ 0.625 ms ช่วงเวลาจริงคำนวณจากผลรวมของค่าคงที่และการหน่วงเวลาแบบสุ่ม (0–10 ms) ซึ่งลดความน่าจะเป็นของการชนกันระหว่างอุปกรณ์โฆษณาหลายเครื่อง

การเลือกช่วงเวลาคือความสมดุลระหว่าง ความเร็วในการตรวจพบ และ การใช้พลังงาน ที่ช่วงเวลา 20 ms อุปกรณ์จะถูกตรวจพบภายใน 20–30 ms แต่กระแสไฟฟ้าเฉลี่ยจะอยู่ที่ประมาณ 1–2 mA ที่ช่วงเวลา 1000 ms การตรวจพบจะใช้เวลาถึง 1 วินาที แต่กระแสไฟฟ้าเฉลี่ยจะลดลงเหลือ 50–100 µA สำหรับอุปกรณ์ IoT ส่วนใหญ่ ช่วงเวลาที่แนะนำคือ 200–1000 ms

ตาม รายงาน Texas Instruments Application Report SWRA478 (2024) การเพิ่มช่วงเวลาโฆษณาจาก 100 ms เป็น 1000 ms ช่วยลดการใช้พลังงานลง 90% หากอุปกรณ์ไม่ต้องการการตรวจพบทันที (เช่น เซ็นเซอร์วัดอุณหภูมิที่ส่งข้อมูลนาทีละครั้ง) ช่วงเวลาที่เหมาะสมคือ 1000–2000 ms

พารามิเตอร์เพิ่มเติมคือ advertising timeout — เวลาสูงสุดที่อุปกรณ์โฆษณา ใน iOS, Peripheral จะหยุดโฆษณาโดยอัตโนมัติหลังจาก 180 วินาทีในพื้นหลัง ใน Android ไม่มีข้อจำกัดดังกล่าว แต่ผู้ผลิตอาจเพิ่มขีดจำกัดของตนเอง

Scan Response: ข้อมูลเพิ่มเติม

Scan Response คือแพ็กเก็ตข้อมูลเพิ่มเติม (สูงสุด 31 ไบต์) ที่ Peripheral ส่งเพื่อตอบสนองต่อคำขอสแกนจาก Central คำขอสแกนถูกส่งโดย Central หลังจากได้รับแพ็กเก็ตโฆษณาหากต้องการข้อมูลเพิ่มเติมก่อนการเชื่อมต่อ Scan Response ไม่ต้องการการโฆษณาเพิ่มเติม — จะส่งเมื่อมีการร้องขอเท่านั้น ช่วยประหยัดเวลาออกอากาศ

การกระจายข้อมูลโดยทั่วไป: advertising PDU (31 ไบต์) ประกอบด้วยแฟล็ก (3 ไบต์), UUID ของบริการ (2–16 ไบต์) และข้อมูลผู้ผลิต (ไบต์ที่เหลือ) Scan response บรรทุกชื่อเต็มของอุปกรณ์ (สูงสุด 28 ไบต์) และ UUID เพิ่มเติมหรือ TX Power Level การแยกนี้ช่วยให้ Central กรองอุปกรณ์ตาม UUID ได้อย่างรวดเร็วโดยไม่ต้องอ่าน scan response

เมื่อออกแบบแพ็กเก็ตโฆษณา โปรดทราบ: หากทั้ง 31 ไบต์ถูกใช้ใน advertising PDU, Central จะไม่สามารถระบุได้ว่าอุปกรณ์รองรับ scan response หรือไม่ แนะนำให้เว้นว่างอย่างน้อย 3–5 ไบต์ ใน advertising PDU เพื่อระบุความสามารถ scan response

Extended Advertising ใน BLE 5.0

Extended Advertising (BLE 5.0) เป็นส่วนขยายของกลไกการโฆษณาที่เพิ่มขนาดแพ็กเก็ตโฆษณาจาก 31 เป็น 251 ไบต์และเพิ่มประเภทแพ็กเก็ตใหม่ Extended Advertising ยังรองรับ coded PHY เพื่อขยายระยะทางการสื่อสารสูงสุด 1 กม. ในพื้นที่เปิด และการโฆษณาเป็นระยะ (Periodic Advertising) สำหรับการซิงโครไนซ์ Central หลายตัว

นวัตกรรมหลัก: ADV_EXT_IND — extended advertising PDU ที่สามารถส่งข้อมูลสูงสุด 251 ไบต์ในแพ็กเก็ตเดียว Extended Advertising ใช้ช่องสัญญาณหลัก (37, 38, 39) เพียงเพื่อระบุว่าช่องสัญญาณรองใด (0–36) ที่ส่งข้อมูลทั้งหมด ซึ่งช่วยลดภาระบนช่องสัญญาณโฆษณาและเพิ่มปริมาณงานโดยรวมของระบบ

Periodic Advertising เป็นกลไกเพิ่มเติมที่ Peripheral ส่งข้อมูลบนช่องสัญญาณรองในช่วงเวลาคงที่ และ Central สามารถซิงโครไนซ์กับลำดับนี้ได้ ใช้สำหรับบริการที่ต้องการอัปเดตข้อมูลเป็นประจำ — ตัวอย่างเช่น การสตรีมเสียงหรือการอ่านค่าเซ็นเซอร์แบบเรียลไทม์

การกำหนดค่าโฆษณาใน iOS และ Android

iOS (Core Bluetooth) มี CBPeripheralManager สำหรับจัดการการโฆษณา พารามิเตอร์โฆษณาถูกกำหนดผ่านพจนานุกรม advertisementData ด้วยคีย์ CBAdvertisementDataLocalNameKey (ชื่ออุปกรณ์), CBAdvertisementDataServiceUUIDsKey (UUID ของบริการ), CBAdvertisementDataTxPowerLevelKey (ระดับกำลัง) iOS จัดการช่วงเวลาโฆษณาโดยอัตโนมัติและไม่อนุญาตให้ตั้งค่าด้วยตนเอง

import CoreBluetooth

class AdvertiserManager: NSObject, CBPeripheralManagerDelegate {

    private var peripheralManager: CBPeripheralManager!

    func startBLEAdvertising() {
        let data: [String: Any] = [
            CBAdvertisementDataLocalNameKey: "BLE Beacon",
            CBAdvertisementDataServiceUUIDsKey: [
                CBUUID("180F")
            ],
            CBAdvertisementDataIsConnectable: true
        ]
        peripheralManager.startAdvertising(data)
    }
}

Android (BluetoothLeAdvertiser) ให้การควบคุมที่ละเอียดยิ่งขึ้น มีให้เลือก: AdvertiseSettings — การกำหนดค่าโหมด (LOW_POWER, BALANCED, LOW_LATENCY), กำลังส่งและช่วงเวลา; AdvertiseData — ข้อมูลแพ็กเก็ต Android รองรับ extended advertising (BLE 5.0) บนอุปกรณ์ที่เข้ากันได้ แต่ส่วนแบ่งของอุปกรณ์ดังกล่าวในตลาดอยู่ที่ประมาณ 30–40%

BluetoothLeAdvertiser advertiser =
    BluetoothAdapter.getDefaultAdapter()
    .getBluetoothLeAdvertiser();

AdvertiseSettings settings = new AdvertiseSettings.Builder()
    .setAdvertiseMode(
        AdvertiseSettings.ADVERTISE_MODE_LOW_POWER
    )
    .setTxPowerLevel(
        AdvertiseSettings.ADVERTISE_TX_POWER_MEDIUM
    )
    .build();

AdvertiseData data = new AdvertiseData.Builder()
    .setIncludeDeviceName(true)
    .addServiceUuid(new ParcelUuid(
        UUID.fromString(
            "0000180F-0000-1000-8000-00805F9B34FB"
        )
    ))
    .build();

advertiser.startAdvertising(
    settings, data, advertiseCallback
);

เมื่อพัฒนาแอปพลิเคชัน BLE ข้ามแพลตฟอร์ม ให้พิจารณาความแตกต่าง: iOS ไม่อนุญาตให้ควบคุมช่วงเวลาโฆษณาโดยตรง แต่รับประกันการทำงานที่เสถียรบนทุกอุปกรณ์; Android ให้การควบคุมอย่างเต็มที่ แต่การแยกส่วนของเวอร์ชันและผู้ผลิตอาจทำให้เกิดความไม่เข้ากันได้ แนะนำให้ ทดสอบการโฆษณา บนอุปกรณ์จริงของทั้งสองแพลตฟอร์ม