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 এবং অন্যান্য প্ল্যাটফর্মের সাথে ডিভাইসের সামঞ্জস্যের জন্য গুরুত্বপূর্ণ, এবং আবিষ্কারের গতি ও বিজ্ঞাপনের শক্তি দক্ষতাও নির্ধারণ করে।
মূল পয়েন্ট
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 উপাদান বিজ্ঞাপন প্যাকেটে 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 টাইপ — একটি প্যাকেটে একই টাইপের একাধিক উপাদান — অনুমোদিত, কিন্তু Central স্ট্যাক বাস্তবায়নের উপর নির্ভর করে শুধুমাত্র প্রথম বা শেষটি প্রক্রিয়া করতে পারে।
একটি গুরুত্বপূর্ণ নিয়ম: প্যাকেটে সমস্ত Length(+1)-এর যোগফল বিজ্ঞাপন ডেটার আকারের (advertising PDU-এর জন্য 31 বাইট) বেশি হওয়া উচিত নয়। যদি ডেটা ফিট না হয়, তাহলে অগ্রাধিকার নির্ধারণ করতে হবে — কোন AD টাইপ প্রাথমিক আবিষ্কারের জন্য গুরুত্বপূর্ণ এবং কোনটি Scan Response-এ স্থানান্তর করা যেতে পারে।
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 (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 (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 (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-তে সেন্সর রিডিং বা ডিভাইসের অবস্থা রাখে।
// 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 সঠিকভাবে সেট করা আছে।
প্রায়শই জিজ্ঞাসিত প্রশ্ন
Bluetooth Controller স্ট্যাক সীমা অতিক্রমকারী ডেটা বাতিল করবে বা প্যাকেট পাঠাবে না। বিজ্ঞাপন প্যাকেট একত্রিত করার সময় AD উপাদানের মোট দৈর্ঘ্য পরীক্ষা করুন। যদি ডেটা ফিট না হয়, অংশ Scan Response-এ স্থানান্তর করুন বা 251 বাইট সীমা সহ Extended Advertising (BLE 5.0) ব্যবহার করুন।
হ্যাঁ, Manufacturer Specific Data (0xFF)-এর মাধ্যমে। রিডিং 4–8 বাইটে প্যাক করুন: উদাহরণস্বরূপ, তাপমাত্রা (fixed-point ফরম্যাটে 2 বাইট), আর্দ্রতা (2 বাইট), ব্যাটারি ভোল্টেজ (2 বাইট)। এই পদ্ধতি Central-কে সংযোগ ছাড়াই ডেটা পড়তে দেয়, শক্তি সাশ্রয় করে।
কাস্টম সেবার জন্য, 128-bit UUID (AD Type 0x06–0x07) ব্যবহার করুন। যদি UUID advertising PDU-তে (প্রতি UUID 16 বাইট) ফিট না হয়, এটি Scan Response-এ স্থানান্তর করুন বা শুধুমাত্র প্রথম এক বা দুটি UUID উল্লেখ করতে Incomplete সংক্ষিপ্ত ফরম্যাট (0x06) ব্যবহার করুন।
Complete — প্যাকেটে ডিভাইসের সমস্ত সেবা UUID তালিকাভুক্ত। Incomplete — শুধুমাত্র UUID-এর একটি অংশ (সাধারণত সবচেয়ে গুরুত্বপূর্ণ)। Central Incomplete-কে পূর্ণ তালিকা হিসেবে নির্ভর করতে পারে না, তবে দ্রুত ফিল্টারিং-এর জন্য এটি ব্যবহার করে। পূর্ণ তালিকা GATT Discovery-এর পরে উপলব্ধ।
একটি সাধারণ কারণ হল ভুল Flags (0x01)। নিশ্চিত করুন যে BR/EDR Not Supported বিট সেট করা আছে। দ্বিতীয় কারণ হল বিজ্ঞাপন প্যাকেটে Service UUID-এর অনুপস্থিতি (iOS UUID দ্বারা ফিল্টার করে)। তৃতীয় কারণ হল ডিভাইসটি খুব কমই বিজ্ঞাপন দিচ্ছে (iOS 1000 ms-এর বেশি ব্যবধান আশা করে না)।
সারসংক্ষেপ
আমরা একটি মোবাইল অ্যাপ্লিকেশন টার্নকি তৈরি করব
IT Sectr 2017 সাল থেকে স্টার্টআপ এবং ব্যবসার জন্য iOS এবং Android অ্যাপ্লিকেশন তৈরি করে। আমরা আপনাকে পরামর্শ দেব এবং সেরা সমাধান প্রস্তাব করব।
আরও পড়ুন