Peripheral — دستگاهی در معماری Bluetooth Low Energy است که سرویسهای خود را از طریق بستههای advertising تبلیغ میکند و منتظر اتصال از Central میماند. در اکوسیستم IoT، Peripheral معمولاً دستگاهی با مصرف انرژی محدود است: سنسور دما، لامپ هوشمند، دستبند تناسب اندام، بیکن (Beacon). Bluetooth Core Specification 5.4 (2023) پروتکل تبلیغات را تعریف میکند: Peripheral به صورت دورهای بستههای advertising حاوی نام دستگاه، لیست سرویسها و دادههای کاربر را ارسال میکند و Central این بستهها را اسکن کرده و تصمیم میگیرد که آیا متصل شود یا خیر. پس از برقراری اتصال، Peripheral به عنوان سرور GATT عمل میکند و سرویسها و ویژگیهایی برای خواندن و نوشتن ارائه میدهد.
نکات کلیدی
Peripheral — یک دستگاه BLE است که سرور GATT را پیادهسازی میکند و قابلیتهای خود را از طریق کانالهای advertising تبلیغ میکند. برخلاف Central که فعالانه به دنبال دستگاهها میگردد، Peripheral به صورت غیرفعال منتظر اتصال میماند. این یک مدل نامتقارن است که برای بهرهوری انرژی دستگاههای با باتری بهینهسازی شده است.
Peripheral میتواند در چندین حالت باشد: advertising (تبلیغات)، connected (متصل به Central)، sleeping (خواب با تبلیغات غیرفعال). در حالت advertising، Peripheral به صورت دورهای بستههای کوتاه داده ارسال میکند و حداقل انرژی مصرف میکند. پس از اتصال، Peripheral به حالت connected میرود و مطابق با connection interval توافقشده با Central تبادل داده میکند.
طبق Bluetooth Core Specification 5.4 (2023)، دستگاه میتواند به صورت پویا بین نقشهای Peripheral و Central جابجا شود، اما در هر لحظه برای یک اتصال نقش ثابت است. سناریوی معمول: سنسور IoT دائماً در نقش Peripheral کار میکند و گوشی هوشمند به عنوان Central اتصال را مدیریت میکند.
برای توسعهدهنده مهم است که بداند: Peripheral تعیین میکند کدام سرویسها و ویژگیها در دسترس هستند و دسترسی به آنها را مدیریت میکند. ساختار سرور GATT روی Peripheral مشخص میکند که Central چه دادههایی را میتواند بخواند و چه دستوراتی را میتواند بنویسد.
Advertising (تبلیغات) — مکانیزمی است که Peripheral به وسیله آن حضور خود را اعلام میکند. Peripheral بستههای advertising را در سه کانال اختصاصی (۳۷، ۳۸، ۳۹) با فاصله زمانی ۲۰ میلیثانیه تا ۱۰.۲۴ ثانیه ارسال میکند. هر بسته تبلیغاتی حاوی اطلاعات ثابت است و میتواند دادههای اختیاری را نیز شامل شود.
دو نوع بسته تبلیغاتی وجود دارد: advertising PDU (بسته اصلی) و scan response PDU (پاسخ به درخواست Central). بسته اصلی شامل فیلدهای اجباری است: نوع بسته، آدرس فرستنده، دادهها. اگر Central درخواست اسکن (scan request) ارسال کند، Peripheral با یک بسته اضافی حاوی اطلاعات کاملتر — مثلاً نام کامل دستگاه — پاسخ میدهد.
پارامترهای advertising بر سرعت کشف و مصرف انرژی تأثیر میگذارند. Advertising interval — زمان بین ارسال بستهها. هرچه فاصله کوتاهتر باشد، Central سریعتر دستگاه را کشف میکند، اما Peripheral انرژی بیشتری مصرف میکند. فاصله توصیهشده: ۱۰۰–۱۰۰۰ میلیثانیه برای اکثر دستگاهها.
| پارامتر | محدوده | تأثیر | توصیه |
|---|---|---|---|
| Advertising Interval | ۲۰ ms – ۱۰.۲۴ s | سرعت کشف، انرژی | ۱۰۰–۱۰۰۰ ms برای تعادل |
| Advertising Channels | ۳۷، ۳۸، ۳۹ | قابلیت اطمینان کشف | هر ۳ کانال الزامی |
| Tx Power | −۲۰ – +۱۰ dBm | محدوده، تداخل | ۰ dBm برای داخل ساختمان، +۴ dBm برای بیرون |
| Advertising Timeout | ۰ – ۱۸۰ ثانیه | مدت تبلیغات | ۰ (بینهایت) برای بیکنها |
بسته تبلیغاتی BLE محدودیت ۳۱ بایت برای advertising PDU و ۳۱ بایت دیگر برای scan response دارد. در داخل بسته، دادهها در قالب AD Structure (Advertising Data Structure) سازماندهی میشوند: هر فیلد دارای نوع (۱ بایت)، طول (۱ بایت) و مقدار است.
پرکاربردترین AD Type: Flags (0x01) — حالتهای اتصال و کشف، Local Name (0x08 یا 0x09) — نام دستگاه، Service UUID List (0x02–0x07) — لیست UUID سرویسها، Manufacturer Specific Data (0xFF) — دادههای سازنده. بستهبندی صحیح دادهها در یک بسته ۳۱ بایتی وظیفه مهم توسعهدهنده دستگاههای تعبیهشده است.
برای دستگاههایی که نیاز به ارسال دادههای بیشتری دارند، extended advertising (BLE 5.0+) وجود دارد که اندازه بسته تبلیغاتی را به ۲۵۱ بایت افزایش میدهد و انواع بستههای جدیدی اضافه میکند. Extended advertising همچنین از کانالهای کدگذاریشده (coded PHY) برای افزایش برد تا ۱ کیلومتر در فضای باز پشتیبانی میکند.
هنگام طراحی بسته تبلیغاتی در نظر بگیرید: هرچه دادههای بیشتری در بسته advertising باشد، احتمال برخورد با دستگاههای دیگر بیشتر است. برای کشف سریع، توصیه میشود فقط دادههای حیاتی (Service UUID) را در advertising PDU و دادههای اضافی را در scan response قرار دهید.
سرور GATT روی Peripheral شامل تمام سرویسها و ویژگیهایی است که Central میتواند کشف کرده و با آنها تعامل داشته باشد. پس از اتصال، Central سرویسها (discover services) و سپس ویژگیها (discover characteristics) را کشف کرده و از طریق پروتکل GATT با آنها تعامل میکند.
Peripheral به عنوان سرور GATT باید درخواستهای Central را به درستی پردازش کند: خواندن (read request)، نوشتن (write request)، اعلانها (notification) و اعلانهای تأییدشده (indication). هر درخواست از جدول GATT عبور میکند، جایی که به هر ویژگی (سرویس، مشخصه، توصیفگر) یک Handle — آدرس ۱۶ بیتی — اختصاص دارد.
توسعهدهنده Peripheral حقوق دسترسی به هر ویژگی را تعیین میکند: فقط خواندن، فقط نوشتن، خواندن و نوشتن، با رمزنگاری یا بدون آن. برای دادههای محرمانه (اطلاعات شخصی، پارامترهای پزشکی) توصیه میشود که نیاز به رمزنگاری از طریق MITM Protection اعمال شود.
CBPeripheralManager — کلاس Core Bluetooth برای پیادهسازی نقش Peripheral در iOS است. این کلاس سرور GATT را مدیریت میکند، سرویسها و ویژگیها را منتشر میکند و درخواستهای Central را پردازش میکند. برخلاف CBCentralManager، CBPeripheralManager اسکن نمیکند — فقط تبلیغ کرده و اتصالات را مدیریت میکند.
مراحل اصلی پیادهسازی Peripheral در iOS: مقداردهی اولیه CBPeripheralManager، افزودن سرویسها از طریق add، شروع تبلیغات از طریق startAdvertising، پردازش درخواستهای Central از طریق نماینده CBPeripheralManagerDelegate.
import CoreBluetooth
class BLEPeripheralManager: NSObject, CBPeripheralManagerDelegate {
private var peripheralManager: CBPeripheralManager!
func startAdvertising() {
let advertisementData: [String: Any] = [
CBAdvertisementDataLocalNameKey: "BLE Sensor",
CBAdvertisementDataServiceUUIDsKey: [
CBUUID("180F")
]
]
peripheralManager.startAdvertising(advertisementData)
}
func peripheralManagerDidUpdateState(
_ peripheral: CBPeripheralManager
) {
if peripheral.state == .poweredOn {
startAdvertising()
}
}
}
iOS به Peripheral اجازه میدهد در حالت پسزمینه با وجود کلید bluetooth-peripheral در Background Modes کار کند. در پسزمینه، iOS میتواند با مجموعه محدودی از دادهها تبلیغ کرده و اتصالات را مدیریت کند. برای تبلیغات طولانی (بیش از ۱۸۰ ثانیه) از گزینه CBAdvertisementDataWaitForResponseFromCentral برای صرفهجویی در انرژی استفاده کنید.
Android BluetoothLeAdvertiser را برای کار در نقش Peripheral (از API 21) ارائه میدهد. این API امکان شروع تبلیغات با پارامترهای قابل تنظیم را فراهم میکند: قدرت فرستنده، فاصله تبلیغات، دادههای بسته. Android همچنین از extended advertising (BLE 5.0) در دستگاههای سازگار پشتیبانی میکند.
import android.bluetooth.le.*;
private BluetoothLeAdvertiser advertiser;
public void startPeripheral() {
BluetoothAdapter adapter =
BluetoothAdapter.getDefaultAdapter();
advertiser = adapter.getBluetoothLeAdvertiser();
AdvertiseData data = new AdvertiseData.Builder()
.setIncludeDeviceName(true)
.addServiceUuid(
new ParcelUuid(
UUID.fromString("0000180F-0000-1000-8000-00805F9B34FB")
)
)
.build();
AdvertiseSettings settings = new AdvertiseSettings.Builder()
.setAdvertiseMode(AdvertiseSettings.ADVERTISE_MODE_LOW_POWER)
.setTxPowerLevel(AdvertiseSettings.ADVERTISE_TX_POWER_MEDIUM)
.build();
advertiser.startAdvertising(
settings, data, advertiseCallback
);
}
در Android، پشتیبانی از Peripheral به سازنده و نسخه سیستمعامل بستگی دارد. همه دستگاهها از BluetoothLeAdvertiser پشتیبانی نمیکنند — از طریق adapter.isMultipleAdvertisementSupported() بررسی کنید. از Android 10، برای کار در نقش Peripheral مجوز BLUETOOTH_ADVERTISE و همچنین درخواست زمان اجرا برای برنامههای با target SDK 31+ مورد نیاز است.
بهرهوری انرژی — مزیت کلیدی BLE است و Peripheral نقش اصلی را در این زمینه ایفا میکند. دستگاه میتواند بیش از یک سال با باتری CR2032 (۲۲۰ میلیآمپر ساعت) به لطف مصرف بهینه انرژی کار کند. Peripheral بیشتر وقت خود را در حالت خواب با تبلیغات غیرفعال میگذراند و فقط برای ارسال بسته تبلیغاتی یا پردازش درخواست Central بیدار میشود.
مصرف انرژی Peripheral در حالتهای مختلف: حالت خواب (deep sleep) — ۱–۵ µA، idle با تایمر فعال — ۱۰–۵۰ µA، advertising — ۵–۱۵ میلیآمپر (در زمان ارسال بسته)، connected — ۵–۱۰ میلیآمپر (در زمان رویداد اتصال). با advertising interval ۱۰۰۰ میلیثانیه و مدت بسته ۴ میلیثانیه، جریان متوسط حدود ۵۰–۱۰۰ µA است.
طبق Texas Instruments Application Report (SWRA478, 2024)، بهینهسازی advertising interval از ۱۰۰ ms به ۱۰۰۰ ms میانگین مصرف انرژی را ۹۰٪ کاهش میدهد. صرفهجویی اضافی با استفاده از slave latency (رد کردن رویدادهای اتصال)، کاهش Tx Power در فواصل کوتاه و غیرفعال کردن تبلیغات پس از اتصال (connectable advertising) حاصل میشود.
سؤالات متداول
بله، از طریق مکانیزم اعلانها (Notify/Indicate). اگرچه آغازگر اتصال همیشه Central است، پس از اتصال Peripheral میتواند دادهها را از طریق اعلانهای GATT بدون درخواست صریح از Central ارسال کند. برای این کار، Central باید از قبل از طریق CCCD اشتراکگذاری کند.
مدت تبلیغات توسط مشخصات محدود نشده است، اما در عمل توسط انرژی باتری محدود میشود. در iOS، Peripheral میتواند در پسزمینه حداکثر ۱۸۰ ثانیه در هر جلسه بدون تنظیمات اضافی تبلیغ کند. در Android، تبلیغات میتواند نامحدود کار کند، اما زمان کار مستقل را به طور قابل توجهی کاهش میدهد.
Advertising interval را افزایش دهید (توصیه میشود ۵۰۰–۱۰۰۰ ms)، از slave latency برای رد کردن رویدادهای اتصال استفاده کنید، تبلیغات را پس از اتصال غیرفعال کنید و حداقل Tx Power کافی برای ارتباط پایدار در فاصله مورد نظر را انتخاب کنید.
Non-connectable advertising — حالتی است که Peripheral تبلیغ میکند اما درخواستهای اتصال را نمیپذیرد. برای بیکنهایی استفاده میشود که فقط داده ارسال میکنند (مثلاً شناسه فروشگاه) بدون برقراری ارتباط دوطرفه. نسبت به connectable advertising در مصرف انرژی صرفهجویی میکند.
در ۳۱ بایت میتوان گنجاند: پرچمها (۳ بایت)، نام دستگاه (تا ۲۸ بایت به صورت خلاصه)، لیست UUID سرویسها (۲–۱۶ بایت برای هر UUID)، دادههای سازنده (تا ۲۶ بایت). استراتژی بهینه — قرار دادن UUID سرویسها در advertising PDU برای فیلتر کردن و نام کامل را در scan response.
خلاصه
ما یک اپلیکیشن موبایل به صورت کلید در دست توسعه خواهیم داد
IT Sectr از سال 2017 برنامههای iOS و Android را برای استارتاپها و کسبوکارها ایجاد میکند. ما به شما مشاوره میدهیم و بهترین راهحل را پیشنهاد خواهیم کرد.
همچنین بخوانید