Advertising Data در BLE: ساختار و انواع داده
Advertising Data — دادههای ساختاریافتهای هستند که دستگاه BLE برای شناسایی خود و سرویسهایش در بستههای تبلیغاتی ارسال میکند. Bluetooth Core Specification 5.4 (2023) قالب AD Structure را تعریف میکند: هر عنصر شامل طول (1 بایت)، نوع (1 بایت) و مقدار (تا 29 بایت) است. این مشخصات در مجموع بیش از 30 نوع AD را توصیف میکند — از 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 بایت) — محتوا بسته به نوع.
بسته تبلیغاتی استاندارد میتواند تا 31 بایت داده AD داشته باشد. اگر این کافی نباشد، از 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 بایت برای 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 ممکن است به جای BLE از طریق بلوتوث کلاسیک متصل شود. مقدار Flags را هنگام اشکالزدایی بسته تبلیغاتی با تحلیلگر بلوتوث (nRF Connect، Wireshark) بررسی کنید.
Local Name: نام دستگاه
Local Name (AD Type 0x08 یا 0x09) — نام نمایشی دستگاه BLE. نوع 0x08 (Shortened Local Name) — نام کوتاهشده، زمانی استفاده میشود که نام کامل در بسته تبلیغاتی جا نشود. نوع 0x09 (Complete Local Name) — نام کامل دستگاه. حداکثر طول نام 248 بایت است، اما در بسته تبلیغاتی استاندارد بیش از 28 بایت در دسترس نیست.
اگر نام دستگاه از فضای موجود در بسته تبلیغاتی فراتر رود، توصیه میشود: نام کوتاهشده را در 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).
16-bit UUID (2 بایت) — سرویسهای استاندارد Bluetooth SIG، مثلاً 0x180F (Battery Service)، 0x180A (Device Information). 128-bit UUID (16 بایت) — سرویسهای سفارشی که توسط توسعهدهنده تعریف میشوند. 16-bit UUID تنها 4 بایت در AD (Length + Type + 2 بایت UUID) و 128-bit — 18 بایت اشغال میکند. اگر در یک بسته نیاز به ارسال چندین UUID سفارشی باشد، ممکن است در 31 بایت جا نشوند.
توصیه میشود اگر همه UUIDهای دستگاه ارسال نمیشوند و فقط مهمترین آنها برای فیلتر کردن منتقل میشوند، از نوع Incomplete (0x02/0x04/0x06) استفاده کنید. فهرست کامل 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
// تجزیه Manufacturer Specific Data در Central
function parseManufacturerData(data) {
const view = new DataView(data.buffer);
// کد شناسایی شرکت (2 بایت اول)
const companyId = view.getUint16(0, true);
// بررسی 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 باید سریعتر تصمیم بگیرد، دادههای حیاتیتری باید در PDU تبلیغاتی باشند.
استراتژی توصیهشده: PDU تبلیغاتی (31 بایت اول) — Flags (3 بایت) + یک 16-bit Service UUID (4 بایت) + نام کوتاه (تا 12 کاراکتر = 14 بایت) + Manufacturer Data (تا 10 بایت). Scan Response (31 بایت دوم) — نام کامل (باقیمانده) + Service UUID اضافی + TX Power Level (3 بایت). این تقسیمبندی به Central اجازه میدهد دستگاهها را بر اساس UUID به سرعت فیلتر کند.
| اولویت | نوع AD | اندازه | قرار دادن در |
|---|---|---|---|
| 1 (اجباری) | Flags (0x01) | 3 بایت | PDU تبلیغاتی |
| 2 (فیلتر کردن) | Service UUID (0x02–0x03) | 4+ بایت | PDU تبلیغاتی |
| 3 (شناسایی) | Local Name (0x08–0x09) | 2+ بایت | PDU تبلیغاتی (کوتاهشده) |
| 4 (اضافی) | TX Power Level (0x0A) | 3 بایت | Scan Response |
| 5 (سفارشی) | Manufacturer Data (0xFF) | 4+ بایت | PDU تبلیغاتی / Scan Response |
| 6 (داده کامل) | سایر UUIDها | بر اساس اندازه | Scan Response |
اشکالزدایی advertising data — مرحله اجباری توسعه دستگاه BLE. از nRF Connect (Nordic Semiconductor) یا Wireshark با تحلیلگر بلوتوث برای مشاهده دادههای خام بسته استفاده کنید. بررسی کنید که همه انواع 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 استفاده کنیم؟
برای سرویسهای سفارشی از 128-bit UUID (AD Type 0x06–0x07) استفاده کنید. اگر UUID در 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 Supported تنظیم شده است. دلیل دوم — عدم وجود Service UUID در بسته تبلیغاتی (iOS بر اساس UUID فیلتر میکند). دلیل سوم — دستگاه خیلی به ندرت تبلیغ میکند (iOS انتظار فاصله حداکثر 1000 میلیثانیه را دارد).
خلاصه
- Advertising Data — دادههای ساختاریافته در قالب AD Structure (Length-Type-Value) که در بستههای تبلیغاتی BLE ارسال میشوند.
- بسته تبلیغاتی استاندارد تا 31 بایت داده جا میدهد، Scan Response — 31 بایت دیگر برای اطلاعات اضافی.
- Flags (0x01) — نوع AD اجباری که حالتهای شناسایی را تعیین میکند. برای دستگاههای BLE، BR/EDR Not Supported اجباری است.
- Service UUID در قالب 16-bit (2 بایت) یا 128-bit (16 بایت)، Complete یا Incomplete — بسته به فضای موجود ارسال میشود.
- Manufacturer Specific Data (0xFF) — نوع انعطافپذیر برای دادههای سفارشی که در بیکنهای iBeacon، Eddystone و دستگاههای IoT استفاده میشود.
- استراتژی بستهبندی: انواع AD اجباری (Flags, Service UUID, نام کوتاه) — در PDU تبلیغاتی، موارد اضافی — در Scan Response.
- اشکالزدایی advertising data از طریق nRF Connect یا Wireshark — مرحله اجباری توسعه برای بررسی صحت ساختار AD.
ما یک اپلیکیشن موبایل به صورت کلید در دست توسعه خواهیم داد
IT Sectr از سال 2017 برنامههای iOS و Android را برای استارتاپها و کسبوکارها ایجاد میکند. ما به شما مشاوره میدهیم و بهترین راهحل را پیشنهاد خواهیم کرد.
همچنین بخوانید