BLE میں Advertising Data: یہ کیا ہے، ڈھانچہ اور ڈیٹا کی اقسام
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) کا مجموعہ اشتہاری ڈیٹا کے سائز (advertising PDU کے لیے 31 بائٹ) سے تجاوز نہیں کرنا چاہیے۔ اگر ڈیٹا فٹ نہیں ہوتا تو ترجیحات طے کی جانی چاہئیں — کون سی 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 کے بجائے کلاسک Bluetooth کے ذریعے جڑنے کی کوشش کر سکتا ہے۔ Bluetooth تجزیہ کار (nRF Connect, Wireshark) کے ساتھ اشتہاری پیکٹ کو ڈیبگ کرتے وقت Flags قدر چیک کریں۔
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)۔
16-bit UUID (2 بائٹ) معیاری Bluetooth SIG خدمات کے لیے، مثلاً 0x180F (Battery Service)، 0x180A (Device Information)۔ 128-bit UUID (16 بائٹ) ڈویلپر کی طرف سے متعین کردہ حسب ضرورت خدمات کے لیے۔ 16-bit UUID AD میں صرف 4 بائٹ (Length + Type + 2 بائٹ UUID) لیتا ہے، جبکہ 128-bit UUID 18 بائٹ لیتا ہے۔ اگر ایک پیکٹ میں متعدد حسب ضرورت UUID منتقل کرنے کی ضرورت ہو تو وہ 31 بائٹ میں فٹ نہیں ہو سکتے۔
اگر آلہ کے تمام UUID منتقل نہیں کیے جا رہے، بلکہ صرف فلٹرنگ کے لیے سب سے اہم ہیں، تو Incomplete (0x02/0x04/0x06) قسم استعمال کرنے کی سفارش کی جاتی ہے۔ UUID کی مکمل فہرست کنکشن کے بعد Scan Response یا GATT Discovery کے ذریعے منتقل کی جاتی ہے۔ اس سے دیگر AD اقسام کے لیے اشتہاری پیکٹ میں جگہ بچتی ہے۔
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) سب سے لچکدار AD قسم ہے، جو کارخانہ دار کے حسب ضرورت ڈیٹا کو منتقل کرنے کے لیے ڈیزائن کیا گیا ہے۔ Value کے پہلے 2 بائٹ Company Identifier Code ہیں جو Bluetooth SIG کے ذریعے تفویض کیا گیا ہے (مثلاً Apple کے لیے 0x004C، Samsung کے لیے 0x0075)۔ باقی بائٹ کارخانہ دار کے متعین کردہ فارمیٹ میں صوابدیدی ڈیٹا ہیں۔
Apple iBeacon کے لیے Manufacturer Data استعمال کرتا ہے: 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 استعمال کرتے وقت سائز کی حد کا احترام کرنا ضروری ہے: لازمی AD اقسام کو چھوڑ کر پورے اشتہاری پیکٹ کے لیے 31 بائٹ۔ Apple iBeacon کے لیے، پورا پیکٹ 30 بائٹ لیتا ہے، صرف Flags (3 بائٹ) کے لیے جگہ چھوڑتا ہے۔ Eddystone کے لیے — 31 بائٹ تک۔ کمپیکٹ حسب ضرورت فارمیٹ 4–8 بائٹ میں درجہ حرارت، نمی یا دباؤ شامل کر سکتے ہیں۔
ڈیٹا پیکنگ کی حکمت عملی
advertising data کی صحیح پیکنگ 31 بائٹ کی محدود جگہ میں زیادہ سے زیادہ مفید معلومات رکھنے کا فن ہے۔ حکمت عملی آلہ کے مقصد پر منحصر ہے: بیکن کو ایک شناخت کنندہ کی ضرورت ہے، IoT سینسر کو ریڈنگ کی ضرورت ہے، فٹنس ٹریکر کو نام اور سروس UUID کی ضرورت ہے۔ عمومی اصول: Central جتنی تیزی سے فیصلہ کرے، advertising PDU میں ڈیٹا اتنا ہی اہم ہونا چاہیے۔
تجویز کردہ حکمت عملی: advertising 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 بائٹ | 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) یا Bluetooth تجزیہ کار کے ساتھ Wireshark استعمال کریں۔ چیک کریں کہ تمام AD اقسام کا Length درست ہے، لمبائی کا مجموعہ 31 بائٹ سے زیادہ نہیں ہے، اور Flags آپ کے استعمال کے منظر نامے کے لیے درست طریقے سے سیٹ ہیں۔
اکثر پوچھے گئے سوالات
اگر AD عناصر کا مجموعہ 31 بائٹ سے تجاوز کر جائے تو کیا ہوگا؟
Bluetooth Controller اسٹیک حد سے تجاوز کرنے والے ڈیٹا کو ضائع کر دے گا یا پیکٹ نہیں بھیجے گا۔ اشتہاری پیکٹ جمع کرتے وقت AD عناصر کی کل لمبائی چیک کریں۔ اگر ڈیٹا فٹ نہیں ہوتا تو کچھ حصہ Scan Response میں منتقل کریں یا 251 بائٹ کی حد کے ساتھ Extended Advertising (BLE 5.0) استعمال کریں۔
کیا سینسر ریڈنگ کو اشتہاری پیکٹ میں منتقل کیا جا سکتا ہے؟
ہاں، Manufacturer Specific Data (0xFF) کے ذریعے۔ ریڈنگ کو 4–8 بائٹ میں پیک کریں: مثال کے طور پر، درجہ حرارت (fixed-point فارمیٹ میں 2 بائٹ)، نمی (2 بائٹ)، بیٹری وولٹیج (2 بائٹ)۔ یہ طریقہ Central کو بغیر جڑے ڈیٹا پڑھنے کی اجازت دیتا ہے، توانائی بچاتا ہے۔
حسب ضرورت خدمات کے لیے کون سی AD قسم استعمال کروں؟
حسب ضرورت خدمات کے لیے، 128-bit UUID (AD Type 0x06–0x07) استعمال کریں۔ اگر UUID advertising PDU (فی UUID 16 بائٹ) میں فٹ نہیں ہوتا تو اسے Scan Response میں منتقل کریں یا صرف پہلے ایک یا دو UUID بتانے کے لیے Incomplete مختصر فارمیٹ (0x06) استعمال کریں۔
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 ms سے زیادہ کا وقفہ متوقع نہیں رکھتا)۔
خلاصہ
- Advertising Data AD Structure فارمیٹ (Length-Type-Value) میں ساختی ڈیٹا ہے، جو BLE اشتہاری پیکٹوں میں منتقل ہوتا ہے۔
- ایک معیاری اشتہاری پیکٹ میں 31 بائٹ تک ڈیٹا ہوتا ہے، Scan Response اضافی معلومات کے لیے مزید 31 بائٹ فراہم کرتا ہے۔
- Flags (0x01) ایک لازمی AD قسم ہے جو دریافت کے طریقوں کی وضاحت کرتی ہے۔ BR/EDR Not Supported BLE آلات کے لیے لازمی ہے۔
- Service UUID 16-bit (2 بائٹ) یا 128-bit (16 بائٹ) فارمیٹ میں، دستیاب جگہ کے مطابق Complete یا Incomplete میں منتقل ہوتا ہے۔
- Manufacturer Specific Data (0xFF) حسب ضرورت ڈیٹا کے لیے ایک لچکدار قسم ہے، جو iBeacon، Eddystone بیکن اور IoT آلات میں استعمال ہوتی ہے۔
- پیکنگ حکمت عملی: لازمی AD اقسام (Flags، Service UUID، مختصر نام) advertising PDU میں، اضافی Scan Response میں۔
- nRF Connect یا Wireshark کا استعمال کرتے ہوئے advertising data کو ڈیبگ کرنا — درست AD ڈھانچے کی تصدیق کے لیے ایک لازمی ترقیاتی مرحلہ۔
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں