آشنایی با Duty Cycle، نرخ کدگذاری و ساختار بسته‌ها در پروتکل Lora

چرخه کاری (Duty Cycle)

در بخش قبلی به بررسی Spreading Factors و ADR در LoRaWAN پرداختیم. اصطلاح Duty Cycle نشون میده که یک منبع یا کانال چه بخشی از زمان رو در حال استفاده هست. برای مثال، اگه یک دستگاه روی یک کانال در بازه‌ای ۱۰ واحد زمانی کار کنه و توی این مدت فقط ۲ واحد زمانی واقعاً در حال ارسال باشه، یعنی این دستگاه Duty Cycle برابر با ۲۰٪ داره.

وقتی فقط یک کانال داریم، محاسبه Duty Cycle خیلی ساده‌ست. مثلاً اگر دستگاه ۲ واحد زمانی از هر ۱۰ واحد رو روی اون کانال ارسال کنه، Duty Cycle میشه ۲۰٪.

اما وقتی چند کانال وارد بازی میشن، ماجرا یکم پیچیده‌تر میشه. فرض کن دستگاه به‌جای یک کانال، روی ۳ کانال مختلف داده بفرسته. توی هر کانال همچنان ۲ واحد زمانی از هر ۱۰ واحد اشغال میشه (پس برای هر کانال Duty Cycle همون ۲۰٪ باقی می‌مونه). اما اگه همه کانال‌ها رو با هم در نظر بگیریم، دستگاه در مجموع ۶ واحد زمانی از هر ۱۰ واحد در حال ارسال بوده. یعنی حالا Duty Cycle کل دستگاه ۶۰٪ میشه.

به زبان ساده، با اضافه شدن کانال‌های بیشتر، دستگاه می‌تونه مدت بیشتری در کل زمان فعال باشه، حتی اگر محدودیت Duty Cycle روی هر کانال جداگانه رعایت شده باشه.

توی برنامه فرکانسی اروپا، کانال‌ها به چند زیرباند (Sub-band) تقسیم شدن. اینجا وقتی می‌خوای Duty Cycle رو حساب کنی، باید هم کانال‌ها و هم زیرباندها رو در نظر بگیری.

فرض کن همون مثالی که قبل داشتیم رو ادامه بدیم: یک دستگاه روی ۳ کانال مختلف ارسال می‌کنه و هر کانال همچنان ۲۰٪ Duty Cycle داره. در مجموع دستگاه باز هم ۶۰٪ Duty Cycle خواهد داشت. اما حالا اگه این ۳ کانال توی ۲ زیرباند مختلف باشن، تصویر دقیق‌تر میشه:

• Band 1 فقط ۲ واحد زمانی از هر ۱۰ واحد در حال استفاده بوده → یعنی ۲۰٪ Duty Cycle.
• Band 2 اما ۴ واحد زمانی از هر ۱۰ واحد مشغول بوده → یعنی ۴۰٪ Duty Cycle.

به این ترتیب می‌بینی که محدودیت‌ها فقط روی تک‌تک کانال‌ها اعمال نمیشن، بلکه روی زیرباندها هم حساب جداگانه دارن. این موضوع توی اروپا خیلی مهمه، چون قوانین دقیقاً مشخص کردن هر زیرباند چه سقفی برای Duty Cycle می‌تونه داشته باشه.

حداکثر چرخه کاری (Maximum Duty Cycle)

در بسیاری از کشورها Duty Cycle دستگاه‌های رادیویی توسط دولت یا سازمان‌های مقررات‌گذار محدود میشه. معمول‌ترین محدودیت هم ۱٪ هست، یعنی دستگاه فقط مجازه ۱٪ از کل زمان رو روی یک کانال خاص در حال ارسال باشه. البته همیشه باید قوانین محلی رو بررسی کنی، چون ممکنه شرایط متفاوت باشه.

در اروپا، این محدودیت‌ها طبق استاندارد ETSI EN300.220-2 V3.2.1 (2018-06) و به‌طور مشخص در بخش 4.3.3 تعریف شدن. این استاندارد زیرباندها و حداکثر Duty Cycle مجازشون رو این‌طور مشخص کرده:

• K (863 – 865 MHz): حداکثر 0.1%
• L (865 – 868 MHz): حداکثر 1%
• M (868 – 868.6 MHz): حداکثر 1%
• N (868.7 – 869.2 MHz): حداکثر 0.1%
• P (869.4 – 869.65 MHz): حداکثر 10%
• Q (869.7 – 870 MHz): حداکثر 1%

علاوه بر این، خود مشخصات LoRaWAN هم محدودیت Duty Cycle برای فرکانس‌های Join تعریف کرده. این همون کانال‌هایی هستن که همه دستگاه‌های LoRaWAN برای فعال‌سازی از راه دور (OTAA) ازشون استفاده می‌کنن. در بیشتر مناطق دنیا، Duty Cycle این فرکانس‌ها هم روی ۱٪ تنظیم شده.

اصلاح خطا (Forward Error Correction) و نرخ کدگذاری (Code Rate)

یکی از روش‌هایی که LoRa برای بالا بردن قابلیت اطمینان استفاده می‌کنه، چیزی به اسم Forward Error Correction (FEC) هست. ایده‌اش خیلی ساده‌ست: قبل از ارسال داده، چند بیت اضافی به عنوان بیت‌های افزونه (Redundant Bits) به پیام اضافه میشه. وقتی پیام در مسیر به خاطر نویز یا تداخل خراب بشه (مثلاً بعضی بیت‌ها از 0 به 1 یا از 1 به 0 تغییر کنن)، گیرنده می‌تونه با استفاده از همین بیت‌ها خطا رو شناسایی و حتی اصلاح کنه.

حالا اینجاست که مفهوم Code Rate وارد میشه. Code Rate نشون میده چند درصد از بیت‌هایی که ارسال می‌شن واقعاً اطلاعات اصلی هستن و چند درصدشون بیت‌های افزونه برای خطایابی. در LoRaWAN چهار نرخ کدگذاری استاندارد وجود داره:

• 4/5
• 4/6
• 5/7
• 4/8

به عنوان مثال، وقتی Code Rate برابر با 5/7 باشه، یعنی به ازای هر ۵ بیت اطلاعات واقعی، کُدر در مجموع ۷ بیت تولید می‌کنه. پس ۲ بیت از این ۷ بیت صرفاً افزونه هستن برای تصحیح خطا.

به زبان ساده: هرچی Code Rate پایین‌تر باشه (مثلاً 4/8)، بیت‌های افزونه بیشتری اضافه میشه و در نتیجه ارتباط مقاوم‌تر در برابر خطا میشه ولی نرخ داده کمتر میشه. و هرچی Code Rate بالاتر باشه (مثلاً 4/5)، نرخ داده بیشتر میشه اما مقاومت در برابر خطا کمتر خواهد بود.

قالب بسته در لایه فیزیکی LoRa

LoRa برای انتقال داده از دو نوع قالب بسته (Packet Format) استفاده می‌کنه: Explicit و Implicit.

در حالت Explicit، بسته LoRa شامل اجزای زیر میشه:

• Preamble: برای همگام‌سازی (Sync) گیرنده با فرستنده استفاده میشه. طبق سند LoRaWAN Regional Parameters، طول Preamble باید ۸ سمبل باشه. اما فرستنده‌ی رادیویی به‌طور خودکار ۴.۲۵ سمبل دیگه بهش اضافه می‌کنه و در نهایت طول Preamble برابر ۱۲.۲۵ سمبل میشه.
• PHDR (Physical Header): یک بخش اختیاری که فقط در حالت Explicit وجود داره و اطلاعاتی مثل اندازه Payload و CRC رو نگه می‌داره.
• PHDR_CRC (Header CRC): یک فیلد اختیاری دیگه که کد خطایابی برای تشخیص و اصلاح خطا در هدر رو فراهم می‌کنه.

فیلدهای PHDR و PHDR_CRC با Coding Rate = 4/8 رمزگذاری میشن.

• PHYPayload: این قسمت کل فریم تولید شده توسط لایه MAC رو شامل میشه. حداکثر اندازه Payload بسته به نرخ داده (DR) و قوانین منطقه‌ای متفاوته.
• CRC: یک فیلد اختیاری برای تشخیص خطا در Payload پیام‌های uplink.

فیلدهای PHYPayload و CRC با یکی از Code rate های (۴/۵، ۴/۶، ۴/۷ یا ۴/۸) رمزگذاری میشن. کل فریم هم در نهایت با یکی از Spreading Factorها (SF = 7 تا 12) ارسال میشه.

به این ترتیب، ساختار لایه فیزیکی LoRa طوری طراحی شده که هم انعطاف‌پذیری داشته باشه (با CRC اختیاری و هدر قابل تنظیم) و هم قابلیت اطمینان بالا برای ارتباط‌های IoT.

در حالت Implicit، هدر (Header) از بسته حذف میشه. دلیلش اینه که اندازه Payload و همین‌طور نرخ کدگذاری (Coding Rate) از قبل مشخص یا ثابت هستن، پس نیازی به فرستادن هدر اضافی برای توضیح این اطلاعات وجود نداره.

یک نمونه مهم از استفاده حالت Implicit در LoRa، بیکن‌ها (Beacons) هستن. گیت‌وی‌ها از همین قالب بسته استفاده می‌کنن تا اطلاعات همگام‌سازی زمانی (Time Synchronization) رو برای دستگاه‌ ارسال کنن. چون ساختار پیام از قبل معلومه، حذف هدر باعث میشه بسته کوتاه‌تر و ساده‌تر بشه.

به طور خلاصه:

• Explicit Mode → شامل هدر هست، وقتی که اندازه Payload یا نرخ کدگذاری متغیره.
• Implicit Mode → بدون هدر، وقتی که اندازه Payload و نرخ کدگذاری از قبل مشخصه.

منابع