Advertising در BLE: چیست، فرمت‌های بسته و مکانیزم‌های تبلیغات

Advertising در BLE چیست؟

Advertising (تبلیغات) — فرآیند ارسال دوره‌ای بسته‌های کوتاه داده است که به وسیله آن دستگاه BLE حضور و در دسترس بودن خود را اعلام می‌کند. بر خلاف Bluetooth کلاسیک که جستجوی دستگاه‌ها ثانیه‌ها طول می‌کشد، BLE advertising امکان کشف دستگاه را در میلی‌ثانیه‌ها با حداقل مصرف انرژی فراهم می‌کند.

معماری BLE دستگاه‌ها را به دو نقش تقسیم می‌کند: Peripheral (تبلیغ می‌کند) و Central (اسکن می‌کند). Peripheral بسته‌های advertising را ارسال می‌کند و Central کانال را اسکن کرده و درباره اتصال تصمیم می‌گیرد. این مدل نامتقارن مزیت کلیدی BLE است: دستگاه تبلیغ‌کننده انرژی را فقط برای ارسال بسته‌های کوتاه صرف می‌کند، نه برای گوش دادن مداوم به کانال.

فرآیند advertising از سه مرحله تشکیل شده است: advertising event (ارسال بسته در هر سه کانال)، scan request/response (تبادل اختیاری با Central) و connection request (شروع اتصال توسط Central). هر مرحله توسط Bluetooth Controller در سطح Link Layer مدیریت می‌شود.

کانال‌های تبلیغاتی و کاربرد آنها

BLE از 40 کانال در باند 2.4 گیگاهرتز استفاده می‌کند که 37 (2402 مگاهرتز)، 38 (2426 مگاهرتز) و 39 (2480 مگاهرتز) منحصراً برای advertising اختصاص داده شده‌اند. سه کانال سازشی بین قابلیت اطمینان کشف و پهنای باند است: یک کانال ممکن است توسط Wi-Fi یا تداخل‌های دیگر اشغال شود، اما دستگاه در دو کانال دیگر کشف خواهد شد.

کانال 37 در کنار کانال Wi-Fi 1، کانال 39 در کنار کانال Wi-Fi 6، و کانال 38 بین آنها در منطقه حداقل تداخل قرار دارد. انتخاب سه کانال تضمین می‌کند که دستگاه حتی در شرایط تراکم رادیویی بالا — مثلاً در مرکز خرید با ده‌ها نقطه دسترسی Wi-Fi — کشف شود.

Peripheral بسته advertising را به صورت متوالی در هر سه کانال ارسال می‌کند — این advertising event نامیده می‌شود. دستگاه مرکزی هر بار یک کانال را اسکن می‌کند و طبق الگوریتم پیاده‌سازی شده در Bluetooth Controller بین آنها جابجا می‌شود. احتمال کشف در طول یک advertising event در صورت عدم برخورد نزدیک به 100% است.

انواع بسته‌های تبلیغاتی

Bluetooth Core Specification چندین نوع advertising PDU (Protocol Data Unit) را تعریف می‌کند که هر کدام کاربرد خاص خود را دارند. انواع اصلی: ADV_IND (connectable undirected advertising) — تبلیغات استاندارد با قابلیت اتصال، ADV_NONCONN_IND (non-connectable undirected advertising) — فقط تبلیغات بدون اتصال، ADV_SCAN_IND (scannable undirected advertising) — از scan request پشتیبانی می‌کند، ADV_DIRECT_IND (directed advertising) — تبلیغات برای Central خاص.

ADV_IND — رایج‌ترین نوع که در اکثر دستگاه‌های BLE استفاده می‌شود. پس از دریافت ADV_IND، Central می‌تواند connection request ارسال کرده و اتصال برقرار کند. ADV_NONCONN_IND توسط بیکن‌ها (Beacon) استفاده می‌شود: دستگاه تبلیغ می‌کند اما درخواست‌های اتصال را نمی‌پذیرد — فقط ارسال یک‌طرفه داده.

ADV_DIRECT_IND حاوی آدرس Central هدف است که امکان برقراری سریع اتصال بدون انتظار برای اسکن را فراهم می‌کند. زمانی استفاده می‌شود که دستگاه‌ها همدیگر را «می‌شناسند» — مثلاً پس از اتصال مجدد به گوشی هوشمند جفت شده قبلی. این نوع مصرف انرژی را کاهش می‌دهد زیرا نیازی به تبلیغات در همه کانال‌ها ندارد.

بازه زمانی تبلیغات و مصرف انرژی

Advertising interval — زمان بین advertising event های متوالی است. مشخصات فنی بازه زمانی از 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)، افزایش advertising interval از 100 ms به 1000 ms مصرف انرژی را 90% کاهش می‌دهد. اگر دستگاه نیاز به کشف فوری ندارد (مثلاً سنسور دما که هر دقیقه داده ارسال می‌کند)، بازه بهینه 1000–2000 ms است.

پارامتر اضافی — advertising timeout — حداکثر زمانی است که دستگاه تبلیغ می‌کند. در iOS، Peripheral به طور خودکار تبلیغات را پس از 180 ثانیه در حالت پس‌زمینه غیرفعال می‌کند. در Android محدودیتی وجود ندارد اما تولیدکنندگان می‌توانند محدودیت‌های خود را اضافه کنند.

Scan Response: داده‌های اضافی

Scan Response — بسته داده اضافی (تا 31 بایت) است که Peripheral در پاسخ به scan request از Central ارسال می‌کند. Scan request توسط Central پس از دریافت بسته advertising ارسال می‌شود اگر قبل از اتصال به اطلاعات بیشتری نیاز داشته باشد. Scan Response نیاز به تبلیغات اضافی ندارد — فقط در صورت درخواست ارسال می‌شود و کانال را ذخیره می‌کند.

توزیع معمول داده: در advertising PDU (31 بایت) پرچم‌ها (3 بایت)، UUID سرویس‌ها (2–16 بایت) و داده‌های سازنده (بایت‌های باقی‌مانده) قرار می‌گیرند. در scan response نام کامل دستگاه (تا 28 بایت) و UUIDهای اضافی یا TX Power Level ارسال می‌شود. این تقسیم‌بندی به Central امکان می‌دهد دستگاه‌ها را بر اساس UUID بدون خواندن scan response سریع فیلتر کند.

هنگام طراحی بسته advertising توجه کنید: اگر تمام 31 بایت در advertising PDU پر شده باشد، Central نمی‌تواند تعیین کند که آیا دستگاه از scan response پشتیبانی می‌کند. توصیه می‌شود حداقل 3–5 بایت در advertising PDU برای نشان دادن قابلیت scan response خالی بگذارید.

Extended Advertising در BLE 5.0

Extended Advertising (BLE 5.0) — گسترش مکانیزم تبلیغات است که اندازه بسته advertising را از 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 را برای مدیریت تبلیغات فراهم می‌کند. پارامترهای advertising از طریق دیکشنری advertisementData با کلیدهای CBAdvertisementDataLocalNameKey (نام دستگاه)، CBAdvertisementDataServiceUUIDsKey (UUID سرویس‌ها)، CBAdvertisementDataTxPowerLevelKey (قدرت) تنظیم می‌شوند. iOS به طور خودکار advertising interval را مدیریت می‌کند و اجازه تنظیم دستی آن را نمی‌دهد.

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 اجازه کنترل مستقیم advertising interval را نمی‌دهد اما عملکرد پایدار در همه دستگاه‌ها را تضمین می‌کند؛ Android کنترل کامل را فراهم می‌کند اما تکه‌تکه شدن نسخه‌ها و تولیدکنندگان می‌تواند منجر به ناسازگاری شود. توصیه می‌شود advertising را روی دستگاه‌های واقعی هر دو پلتفرم آزمایش کنید.