BLOG POST
چیست؟ (LoRaWAN) لوراون A منظور از کلاس

مقدمه
یک شبکه مبتنی بر LoraWAN از دستگاه‌های نهایی (End-Devices)، دروازه‌ها (Gateways)، سرور شبکه (Network Server) و سرورهای برنامه (Application servers) تشکیل شده است. دستگاه‌های پایانی (End-Devices) داده‌ها را به Gatewayها ارسال می‌کنند که اصطلاحاً به این عمل Uplinks گفته می‌شود، Gatewayها داده‌های دریافت شده را به سرور شبکه (Network Server) و در صورت نیاز داده‌ها را به سمت سرور برنامه (Application Server) انتقال می‌دهد.

مقاله مربوط به کلاس ای لوراون - Uplink_Transmission
شکل ۱: انتقال Uplink


علاوه بر این، سرور شبکه (Network Server) می‌تواند پیام‌های مربوط به مدیریت شبکه یا پیغام‌های سمت سرور برنامه (Application Server) را از طریق Gatewayها به دستگاه‌های نهایی (End-Devices) ارسال کند که اصطلاحاً به آن Downlinks گفته می‌شود.

مقاله مربوط به کلاس ای لوراون - Downlink_Transmission
شکل ۲: انتقال Downlink


 پس اگر دیتایی را ارسال کنیم به آن Uplink یا UploadLink و درصورتی‌که دیتایی دریافت کنیم به آن Downlink یا DownloadLink می‌گوییم، در حال حاضر که شما مشغول مطالعه این مطلب هستید، کل تصاویر و محتوای این صفحه وب را از سرور دریافت کرده‌اید پس Downlink صورت‌گرفته است.
دستگاه‌های نهایی در یک شبکه LoraWAN دارای سه کلاس هستند: کلاس A، کلاس B و کلاس C. درحالی‌که تمام دستگاه‌های نهایی مثل سنسورها و محرک‌ها و ... قادر به ارسال Uplinkها به میل خود و در هرزمانی هستند، کلاس‌های B, A و C دستگاه‌های نهایی، تعیین‌کننده این هستند که چه زمانی می‌تواند Downlinkها را دریافت کنند. به زبان ساده‌تر تمام دستگاه‌ها پایانی هر زمانی می‌توانند پیام‌ها را به سمت سرور ارسال کنند ولی نحوهٔ دریافت پیغام از سمت سرور توسط کلاس‌های دستگاه نهایی مشخص می‌شود. کلاس همچنین بهره‌وری انرژی یک دستگاه را تعیین می‌کند. هرچه انرژی مصرفی یک دستگاه کمتر باشد عمر باتری بیشتر خواهد بود.
تمام دستگاه‌های نهایی باید از ارتباطات "Aloha" کلاس A پشتیبانی کنند. دستگاه‌های نهایی کلاس A بیشتر وقت خود را در حالت خواب سپری می‌کنند. ازآنجاکه LoraWAN یک پروتکل "شکاف‌دار" (Slotted) نیست، دستگاه‌های نهایی می‌توانند هر زمانی که تغییری در خواندن سنسور یا زمانی که یک تایمر شروع به کار می‌کند، با سرور شبکه ارتباط برقرار کنند. در واقع، آن‌ها می‌توانند از خواب بیدار شوند و هر لحظه با سرور صحبت کنند. بعد از اینکه دستگاه یک uplink را ارسال می‌کند، قبل از اینکه به خواب برگردد، برای دریافت پیام از شبکه یک و دو ثانیه که به آن پنجره دریافت یا receive windows گفته می‌شود به حالت "گوش‌دادن" فرومی‌رود. چون دستگاه‌های پایانی کلاس A بیشتر در حالت خواب هستند، بیش‌ترین بهره‌وری انرژی را دارند و عمر باطری طولانی‌تری نسبت به کلاس B و C دارند.
در مقابل کلاس B را داریم که به‌جای انتظار برای مشاهده تغییرات محیط توسط سنسورها و یا تایمر، با یک برنامه زمان‌بندی‌شده بیدار می‌شود و یک پنجره دریافت باز می‌کنند تا پیام‌های Downlink را دریافت کنند. یک سیگنال beacon انتقال‌یافته توسط شبکه، به دستگاه‌های پایانی این اجازه را می‌دهد که ساعت داخلی خودشان را با ساعت سرور شبکه (Network Server) هماهنگ کنند. در واقع چون دستگاه‌های کلاس B رو یک برنامهٔ زمان‌بندی‌شده کار می‌کنند پس نیاز هست که هم سرور شبکه و هم دستگاه‌های انتهایی از یک ساعت هماهنگ استفاده کنند یعنی اگر ساعت سرور شبکه 12:05:24 باشد ساعت دستگاه پایانی هم می‌بایست 12:05:24 را نمایش دهد.
در نهایت، دستگاه‌های نهایی کلاس C را داریم که از واژه "Continuous " گرفته شده است پس می‌توان توقع داشت که این دستگاه برخلاف کلاس‌های A و B به خواب فرو نروند. آن‌ها به طور مداوم به پیام‌های downlink شبکه گوش می‌دهند، مگر آنکه داده یا پیغامی توسط حسگر به سرور منتقل شود. یعنی سنسورها و محرک‌ها (actuators) کلاس C همیشه پنجره دریافت را باز می‌گذراند تا از سمت سرور شبکه LoRa داده یا پیغامی مخابره بشود این پنجره فقط زمانی بسته می‌شود که دستگاه‌های انتهای کلاس C بخواهند یک Uplink ارسال کنند. این دستگاه‌ها چون به حالت خواب نمی‌روند انرژی بیشتری مصرف می‌کنند و معمولاً به‌جای استفاده از باتری به یک منبع انرژی ثابت نیاز دارند. حالا من از شما خواننده عزیز یک سؤال دارم فرض کنید که ما قصد داریم سیستم‌های روشنایی یک خیابان را هوشمند کنیم یعنی هر لحظه قادر باشیم چراغ‌ها را خاموش یا روشن کنیم؟ شما برای پیاده‌سازی چنین پروژه‌ای چه کلاسی را برای دستگاه‌های انتهای انتخاب می‌کند؟
- چون چراغ هر لحظه باید فرمان‌های روشن و خاموش شدن را از کاربر بگیرد و اینکه منبع برق در دسترس وجود دارد (چون چراغ به برق وصل می‌باشد پس انشعاب برق برای دستگاه پایانی کاری ندارد و یک منبع انرژی همیشگی است) پس بهترین کلاس برای پیاده‌سازی چنین سناریویی استفاده از دستگاه‌های انتهایی کلاس C می‌باشد.

مقاله مربوط به کلاس ای لوراون - Energy_Consumption
 شکل ۳: مقایسه مصرف انرژی باتوجه‌به کلاس دستگاه

 در این مقاله، نگاهی عمیق به دستگاه‌های نهایی کلاس A می‌اندازیم.

درک دستگاه‌های پایانی از نوع کلاس A
 پروتکل LoraWAN متکی بر شبکه‌ای از نوع Aloha است. دستگاه‌های انتهایی در این نوع شبکه، مجاز به انتقال پیام و داده به‌صورت اختیاری هستند و هر زمان بخواهند می‌توانند داده‌ای را به سمت سرور ارسال کنند.  
ویژگی کلیدی و مهم کلاس A این است که ارتباط تنها توسط دستگاه نهایی آغاز می‌شود.
پیغام‌های Downlink از سمت سرور شبکه تا زمانی که پیام uplink از دستگاه نهایی دریافت و پنجره دریافت (Rx) باز شود، در صف قرار می‌گیرند. در واقع تا زمانی که دستگاه از خواب بیدار نشود و پیغامی را ارسال نکند پیغامی هم از طرف سرور دریافت نخواهد کرد. فرض کنید که ما قصد داریم تنظیمات یک سنسور حرارتی کلاس A را عوض کنیم و کاری کنیم که سنسورها پیغام اخطار حرارتی را به‌جای دمای 70 درجه در دمای 80 درجه ارسال کنند خوب ما در واقع یک پیام Downlink از سمت سرور برای تغییر دمای سنسور از 70 به 80 ارسال می‌کنیم ولی زمانی تنظیمات اعمال می‌شود که حداقل یک‌بار سنسور کار کند و پیغامی را ارسال کند که در نتیجه این عمل یک پنجره دریافت باز شود و تازه در آن زمان تنظیمات اعمال می‌شود. پس توجه کنید این طراحی به طور خاص برای کاربردهایی که به ارتباط Downlink نیاز دارند، طراحی شده است. احساس می‌کنم مثالی که زدم خیلی پیچیده بود این موضوع را با یک مثال ساده‌تر بیان می‌کنم: فرض کنید که دوست شما مسئول بردن زباله‌ها به بیرون منزل رأس ساعت 8 است یعنی در زندگی هیچ کاری به‌جز بردن زباله‌ها رأس ساعت 8 ندارد و در بقیه زمان‌ها خواب است. مسلماً وقتی دوست شما خواب است نمی‌توانید به او بگویید که زباله‌ها را ازاین‌به‌بعد ساعت 9 بیرون ببرد. بلکه باید ساعت 8 طبق معمول بیدار شود زباله‌ها را بیرون بگذارد و قبل از اینکه به خواب برود او را در جریان قرار دهید که از این به بعد باید زباله‌ها را رأس ساعت 9 بیرون بگذارد.


دریافت پنجره‌ها (Receive Windows)
به دنبال ارتباط uplink یک دستگاه نهایی از نوع کلاس A یک پنجره دریافت کوتاه (‏Rx1) باز می‌کند و اگر هیچ ارتباط downlink ای از سمت سرور در طول باز شدن پنجره دریافت نکند، پنجره دریافت دوم (‏Rx2) باز می‌شود. زمان شروع Rx1 پس از زمان ثابتی پس از پایان انتقال uplink آغاز می‌شود.
به طور معمول، این تأخیر یک ثانیه است، بااین‌حال این مدت‌زمان قابل تغییر است. معمولاً Rx2 دو ثانیه بعد از پایان انتقال uplink شروع می‌شود که آن هم قابل تنظیم است. نمودارهای زیر حالت پنجره دریافت در حالت‌های مختلف را نشان می‌دهد.

مقاله مربوط به کلاس ای لوراون - Nothing_Received
شکل ۴: هیچ چیزی دریافت نمی‌شود.

مقاله مربوط به کلاس ای لوراون - RX1_Window
شکل ۵: بسته دریافت‌شده در پنجره Rx1

مقاله مربوط به کلاس ای لوراون - RX2_Window
شکل ۶: بسته دریافت‌شده در پنجره Rx2


 تأخیر پیش‌فرض برای Rx1 (‏RECEIVE _ DELAY1۱) یک پارامتر شبکه است که در سند پارامترهای منطقه‌ای LoraWAN از اتحاد Lora یافت می‌شود. تأخیر پیش‌فرض ممکن است منطقه‌ای باشد (هر منطقه جغرافیایی قوانین مربوط به خود را دارد)، و می‌تواند توسط اپراتور شبکه از طریق دستور مک RxTimingSetupReq تغییر یابد. ولی این تأخیر معمولاً یه مدت یک ثانیه است. سپس دستگاه نهایی یک ثانیه بعد از بسته شدن Rx1 منتظر می‌ماند و سپس پنجره Rx2 را باز می‌کند باز شدن پنجره دوم با این فرمول محاسبه می‌شود:


RECEIVE_DELAY2 = RECEIVE_DELAY1 + 1 Secound



فرکانس‌های انتقال و نرخ‌های داده (Transmission Frequencies and Data Rates)
فرکانس مورداستفاده برای Rx1 تابعی از فرکانس uplink است. نرخ داده‌ای که استفاده می‌کند تابعی از نرخ داده‌ای است که برای انتقال از uplink استفاده می‌شود. ارتباط پیش‌فرض بین فرکانس Uplink و فرکانس Downlink مربوط به Rx1 همچنین نرخ داده، در سند پارامترهای منطقه‌ای LoraWAN مشخص شده است. پارامترهای پیش‌فرض می‌توانند از راه دور توسط اپراتور شبکه با استفاده از دستورها LoraWAN MAC مربوطه دوباره پیکربندی شوند.
Rx2 از فرکانس و نرخ داده‌ای استفاده می‌کند که می‌تواند با استفاده از دستور MAC پیکربندی شود. البته تنظیمات به طور پیش‌فرض بر اساس منطقه جغرافیایی خاص صورت می‌گیرد که در هر جا متفاوت است مثلاً این پیش‌فرض‌ها در اروپا و چین متفاوت است.


دستورهای MAC

باتوجه‌به Rx1، افست بین نرخ داده انتقال uplink (‏Tx) ‏و نرخ داده downlink را می‌توان با استفاده از فیلد Rx1DRoffset در RxParamSetupReq در تنظیمات MAC پیکربندی کرد.
همچنین برای پیکربندی نرخ داده Rx2، از دستور مک RxParamSetupReq استفاده می‌کنیم.
دستور مک DiChannelReq به شبکه این امکان را می‌دهد تا یک فرکانس downlink متفاوت را با پنجره Rx1 اختصاص دهد. این فرمان برای تمام مناطقی که از دستور مک NewChannelReq پشتیبانی می‌کنند، کار می‌کند. برای مثال، همان‌طور که در سند پارامترهای منطقه‌ای LoraWAN توضیح داده شد، DiChannelReq در اتحادیه اروپا و چین کاربرد دارد، اما در ایالات متحده یا استرالیا کاربرد ندارد.


مشخصه انرژی در کلاس A
 مدت‌زمان هر پنجره دریافت می‌بایست حداقل به‌اندازه زمان موردنیاز فرستنده و گیرنده دستگاه پایانی برای تشخیص مؤثر preambleهای downlink  باشد، اگر دستگاه یک preamble downlink را در طول این زمان شناسایی کند، گیرنده رادیویی تا زمانی که داده downlink دریافت نشود، بسته نخواهد شد.
Preamble: برای همگام نگه‌داشتن گیرنده با جریان داده‌های ورودی استفاده می‌شود. در واقع preamble مکانیزم در زدن خانه را دارد یک سیگنال مشخصی را ارسال می‌کند که گیرنده یا فرستنده متوجه شوند یک دیتا قرار است ارسال بشود.
اگر یک downlink در طول Rx1 شناسایی و دمدوله بشود (پس از بررسی جامعیت پیام و آدرس که به‌اختصار MIC گفته می‌شود) و مشخص بشود که دستگاه نهایی آن پیام را با موفقیت دریافت کرده، دستگاه انتهایی پنجره دریافت Rx2 را به‌منظور کاهش مصرف انرژی باز نمی‌کند. در واقع وقتی یک پیام Uplink از طرف یک دستگاه انتهایی مثل سنسور به سمت سرور ارسال می‌شود یک پنجره Rx1 باز می‌شود و منتظر دریافت پیام از طرف سرور (Uplink) می‌ماند وقتی پیغام به سمت دستگاه پایانی مخابره شد، یک سری عملیات روی آن داده‌ها صورت می‌گیرد که مشخص بشود که آیا آن داده‌های ارسال شده و آدرس آن درست هستند یا خیر؟ اگر پیام ارسال شده از gateway به دستگاه پایانی درست باشد، دستگاه پایانی چون پیغام را دریافت کرده دلیل برای بازکردن پنجرهٔ دریافت دوم (Rx2) نمی‌بیند و به خواب می‌رود و همین عمر باعث می‌شود که در مصرف انرژی صرفه‌جویی شود. بااین‌حال، اگر دستگاه نهایی یک پیام downlink را در طول Rx1 دریافت نکند، به بازکردن Rx2 طبق برنامه ادامه خواهد داد. اگه چیزی از طرف سرور به دستگاه پایانی ارسال نشود، هنوز هم پنجره پذیرش خودش را باز نگه می‌دارد در حدی که متوجه بشود و تشخیص بدهد که یک Preamble وجود دارد یا خیر؟ این پنجره حداقل برای ۵.۱ میلی‌ثانیه (‏ms)‏در نرخ داده SF۷ و حداکثر 164 میلی‌ثانیه در نرخ داده SF12 بازمی‌ماند تا preamble را دریافت کند از سوی دیگر، اگر در SF۷، یک downlink به سمت دستگاه پایانی بیاید، کم‌تر از ۱۰۰ میلی‌ثانیه یا یک ثانیه طول می‌کشد تا پیام دمدوله بشود. در SF۱۲ این زمان بیش از دو ثانیه طول خواهد کشید.

مقاله مربوط به کلاس ای لوراون - SF


توجه: SF مخفف Spreading Factor می‌باشد و مقداری بین 7 الی 12 دارید هر چه SF کمتر باشد داده‌ها در رنج کمتر و با تأخیر کمتر و payload (حجم داده) بزرگ‌تر ارسال می‌شود و هرچه SF بیشتر باشد به همان نسبت برد سیگنال بیشتر می‌شود ولی تأخیر و payload کوچک‌تر می‌شود.

مقاله مربوط به کلاس ای لوراون - Wake_Up_Times
شکل ۷: Uplinks، Downlinks و Wake - up Times برای رادیوهای SX۱۲۶x


هدررفتن انرژی مربوط به پنجره Rx1 و Rx2 زمانی که هیچ پیام downlink شناسایی نشود در مقایسه با انرژی موردنیاز برای انتقال uplink قابل‌چشم‌پوشی است.


توپولوژی شبکه LoraWAN
شکل ۸ توپولوژی شبکه LoraWAN را نشان می‌دهد. تفاوت کلیدی بین رویکرد LoraWAN و دیگر فن آوری ها این است که دستگاه‌های نهایی که با یک شبکه لورا pair یا جفت شدن منحصراً به یک دروازه یا gateway متصل نیستند. در عوض، دستگاه‌های نهایی سیگنال‌های خود را به تمام gatewayهای آن محدوده ارسال می‌کند. هر یک از دروازه‌های دریافتی، پکت های داده را به سرور شبکه ارسال می‌کند، و سپس سرور شبکه (Network Server) پیام‌های تکراری را حذف و یک نسخه واحد از آن را به سرور برنامه (Application Server) ارسال می‌کند. به این مثال توجه کنید: فرض کنید که یک سنسور سنجش حرارت را در مکانی قرار داده‌ایم که به‌محض افزایش حرارت محیط یک پیغام را به سمت سرور ارسال می‌کند اطلاعات از طریق gateway به سمت سرور ارسال می‌شود، همان‌طور که گفته شد هر دستگاه پایانی متصل به شبکه اطلاعات را به تمام gatewayها ارسال می‌کند یعنی اگر 3 دروازه در نزدیکی سنسور داشته باشیم هر سه gateway پیغام سنسور را دریافت می‌کند و 3 پیغام به سرور فرستاده می‌شود وظیفهٔ سرور این است که پیغام‌های تکراری را حذف کند و پیام را به سمت سرور اپلیکیشن ارسال کند.

مقاله مربوط به کلاس ای لوراون - Topology
شکل ۸: توپولوژی شبکه LoraWAN

این توپولوژی چندین مزیت دارد:
  - هیچ برنامه‌ریزی شبکه‌ای پیچیده‌ای موردنیاز نیست. این معماری اجازه می‌دهد هر زمانی و در هرجایی هر تعداد gateway را به شبکه اضافه کرد.
  - چون gatewayهای متعدد، بسته داده یکسانی را در طول هر Uplink دریافت می‌کنند بنابراین ارسال دقیق پیام قوی‌تر صورت می‌گیرد که به آن Uplink Spatial diversity گفته می‌شود.
  - نیازی به برنامه‌ریزی فرکانس‌های مختلف برای هر gateway نیست، همچنین نیازی به تخصیص مجدد فرکانس‌ها، هنگامی‌که تعداد gatewayها تغییر می‌کند، نیست. تمام gatewayها دائماً به تمام فرکانس‌های شبکه گوش می‌دهند.
  - باتوجه‌به این واقعیت که هر gateway می‌تواند پیام‌ها را از هر وسیله‌ای دریافت کند، دستگاه‌های تلفن همراه می‌توانند با توان مصرفی کم‌کار می‌کنند. این بدان معنی است که شبکهٔ LoRaWAN برخلاف شبکه‌های سلولار با دستگاه‌های در حال حرکت مشکلی ندارد و حتی متوجه حرکت آن دستگاه نمی‌شود و به‌سادگی uplinks را از gatewayهای نزدیک به مکان فعلی دستگاه دریافت می‌کند.


پیام‌های تأیید نشده و تأیید نشده
پیام‌های دستگاه‌های نهایی به سرورهای شبکه (Network Servers) و برنامه‌های کاربردی (Application Servers) و بالعکس ممکن است تأیید شده یا تأیید نشده باشند.
هنگامی‌که یک دستگاه یک پیغام تأیید نشده را ارسال می‌کند، نیازی به تأیید (Acknowledgment) سرور ندارد. برای مثال، بیشتر اوقات یک سنسور تشخیص دود به‌منظور صحت کارکردش، uplinkهای تأیید نشده و دوره‌ای را از طریق gatewayهای نزدیک، به سرور شبکه ارسال می‌کند. gatewayها داده‌ها را دریافت می‌کند و آن را به سرور شبکه انتقال می‌دهد و سپس داده‌ها به سرور برنامه منتقل می‌شود. هنگام ارسال یک پیغام تأیید شده، دستگاه پایانی نیاز به تصدیق یا acknowledged دریافتی توسط سرور شبکه (Network Server) را دارد. بیایید دوباره برگردیم به سنسور تشخیص دود. زمانی که سنسور تشخیص‌دهنده دود چیزی را شناسایی می‌کند، به انتقال پیام‌های هشدار ادامه خواهد داد تا زمانی که هشدار از طرف سرور تأیید شود. یعنی سنسور تا زمانی که مطمئن شود پیغام به‌درستی ارسال شده به ارسال پیغام ادامه می‌دهد این تصدیق یا acknowledgement به سنسور دود اطلاع می‌دهد که کسی این هشدار را دریافت کرده است. ازآنجاکه downlinkهای شبکه یک منبع کمیاب هستند، باید کم مورداستفاده قرار گرفته شوند. پیام‌های تأیید شده می‌بایست فقط برای داده‌های حیاتی و مهم سنسور مورداستفاده قرار بگیرند

شکل ۹ یک سنسور دود را نشان می‌دهد که پیام‌های رمزگذاری شده و تأیید نشده را ارسال می‌کند (منظور پیکان‌های آبی‌رنگ سمت چپ می‌باشد که از دستگاه پایانی در پایین نمودار به سمت سرور برنامه در بالا توسط Uplink Heartbeat منتقل می‌شود) که دو دروازه آن را دریافت می‌کنند. gatewayها متادیتای رمزگذاری شده را به پیام‌ها اضافه می‌کند و سپس آن‌ها را به سرور شبکه ارسال می‌کند. سرور شبکه متادیتا را رمزگشایی می‌کند و پکت داده‌ها را به سرور برنامه ارسال می‌کند که رمزگشایی شود.
در حالت نارنجی، ما می‌بینیم که سنسور تشخیص دود یک هشدار ارسال می‌کند. بااین‌حال، اینها پیام‌های تأیید شده هستند، در دو مورد اول، هیچ‌گونه تصدیق دریافت نشده است، بنابراین دستگاه به پخش هشدار ادامه می‌دهد. در نهایت، پس از سومین انتقال هشدار همان‌طور که در شکل زیر نمایش‌داده‌شده است، سرور برنامه کاربردی (Application Server) یک تصدیق یا ack را از طریق سرور شبکه و مناسب‌ترین gateway به سنسور ارسال می‌کند.

مقاله مربوط به کلاس ای لوراون - Messaging

شکل ۹

Downlinks کارگزار برنامه (Application Server)
در مثال بعدی، سرور برنامه کاربردی سنسور تشخیص دود، قصد دارد داده‌هایی برای انتقال به یک سنسور سنجش دود خاص (‏دستگاه نهایی) که خواب است ارسال کند. بااین‌حال، ازآنجایی‌که سنسور تشخیص دود یک دستگاه کلاس A است و همان‌طور که بالا توضیح داده شد، سرور برنامه باید منتظر بماند تا سنسور دود از حالت خواب خارج شود و دیتایی را مخابره کند تا سرور قادر به ارسال دیتا به سمت سنسور باشد. برای سنسورهای تشخیص دود، این یک پیام دوره‌ای است (‏برای مثال، هر ۸ ساعت) که اطلاعات وضعیت سنسور همچون وضعیت باتری را به اشتراک می‌گذارد. دریافت این پیغام توسط دستگاه پایانی ممکن است، تأیید شده یا تأیید نشده باشد. نگاهی به شکل ۱۰ بیندازید. در اینجا، سرور برنامه اطلاعاتی برای ارسال به سنسور تشخیص‌دهنده دود دارد، اما دستگاه خواب است. سرور باید منتظر یک ارتباط uplink از سنسور باشد تا بتواند داده‌های خود را ارسال کند. به‌محض اینکه uplink دریافت می‌شود، سرور برنامه downlink را ارسال می‌کند یعنی داده‌ها و پیغام را به سمت سنسور ارسال می‌کند. در مورد یک پیام تأیید نشده ازاین‌دست، پس از دریافت downlink، سنسور دوباره به خواب می‌رود.

مقاله مربوط به کلاس ای لوراون - Application_Server
شکل ۱۰: Downlink سرور برنامه

 

 

 

 

 

 

 

 

 

ارسال پیغام

نظری ثبت نشده هنوز !