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 के माध्यम से कनेक्ट करने का प्रयास कर सकता है। 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).
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 बाइट Bluetooth SIG द्वारा निर्दिष्ट Company Identifier Code हैं (उदाहरण के लिए, 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 प्रकार है जो खोज मोड को परिभाषित करता है। 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, संक्षिप्त नाम) advertising PDU में, अतिरिक्त Scan Response में।
- nRF Connect या Wireshark का उपयोग करके advertising data को डीबग करना — सही AD संरचना की पुष्टि के लिए एक अनिवार्य विकास चरण।
हम एक मोबाइल एप्लिकेशन टर्नकी विकसित करेंगे
IT Sectr 2017 से स्टार्टअप और व्यवसायों के लिए iOS और Android एप्लिकेशन बनाता है। हम आपको सलाह देंगे और सर्वोत्तम समाधान प्रस्तावित करेंगे।
यह भी पढ़ें