Lorawan-stack: تكوين طبقة MAC للجهاز في وحدة التحكم

تم إنشاؤها على ٢٥ فبراير ٢٠٢٠  ·  9تعليقات  ·  مصدر: TheThingsNetwork/lorawan-stack

ملخص

يجب أن تكون طبقة MAC الخاصة بالجهاز قابلة للتكوين من وحدة التحكم.
يستبدل https://github.com/TheThingsNetwork/lorawan-stack/issues/1378

لماذا نحتاج هذا؟

  • إنشاء / تحديث جهاز من الفئة ب من وحدة التحكم
  • إنشاء / تحديث الأجهزة الطرفية باستخدام إعدادات طبقة MAC غير الافتراضية (مثل The Things Uno)

ما هو موجود بالفعل؟ ماذا ترى الآن؟

CLI هو الوسيلة الوحيدة لتكوين طبقة MAC للجهاز

ما المفقود؟ ماذا تريد ان ترى؟

دعم لتكوين جميع الحقول MACSettings .

قائمة أولويات المجال
متوسط
  • جميع الاجهزة

    • [x] rx2_data_rate_index
    • [x] rx2_frequency
    • [x] factory_preset_frequencies
  • خاص بالفئة A (يُعرف أيضًا باسم جميع الأجهزة غير متعددة البث)

    • [x] rx1_delay
    • [x] rx1_data_rate_offset
    • [x] resets_f_cnt
  • فئة ب محددة

    • [x] ping_slot_periodicity
متوسط
  • خاص بالفئة A (يُعرف أيضًا باسم جميع الأجهزة غير متعددة البث)

    • [] max_duty_cycle
    • [x] supports_32_bit_f_cnt
    • [] use_adr
    • [] status_time_periodicity
    • [] status_count_periodicity
  • فئة ب محددة

    • [] ping_slot_data_rate_index
    • [x] ping_slot_frequency
    • [] beacon_frequency
قليل
  • خاص بالفئة A (يُعرف أيضًا باسم جميع الأجهزة غير متعددة البث)

    • [] adr_margin
    • [] desired_rx1_delay
    • [] desired_rx1_data_rate_offset
    • [] desired_rx2_data_rate_index
    • [] desired_rx2_frequency
    • [] desired_max_duty_cycle
    • [] desired_adr_ack_limit_exponent
    • [] desired_adr_ack_delay_exponent
  • فئة ب محددة

    • غير متعدد

      • [] class_b_timeout

      • [] desired_ping_slot_data_rate_index

      • [] desired_ping_slot_frequency

      • [] desired_beacon_frequency

  • فئة C محددة

    • غير متعدد

      • [] class_c_timeout

ملاحظة: قد تكون بعض هذه الإعدادات قابلة للتكوين بالفعل (على سبيل المثال ، عناصر FCnt) ، يرجى تحديث مربعات الاختيار وفقًا لذلك والتحقق من أن هذه الإعدادات هي أماكن في الأماكن الصحيحة (أي أنها غير متوفرة لأجهزة البث المتعدد)

أعتقد أن الإعدادات الخاصة بالفئتين B و C يجب أن تكون متاحة لجميع الأجهزة ، حتى بالنسبة للأجهزة التي SupportsClass{B,C} سعرها false . بهذه الطريقة يمكن للمستخدمين (مؤقتًا) تعطيل / تمكين عملية الفئة B / C كلما لزم الأمر والاحتفاظ بالإعدادات المحددة.

يجب أن تكون الإعدادات الخاصة بالفئة A متاحة فقط للأجهزة غير ذات البث المتعدد.

كيف تقترح تنفيذ هذا؟

أضف جميع الحقول من MACSettings https://github.com/TheThingsNetwork/lorawan-stack/blob/74c9da9a9e07a31d7103eabcd3440f9c80c24ea1/api/end_device.proto#L190 -L284 كحقول لتكوين طبقة الشبكة. يجب أن تكون هذه الحقول قابلة للتكوين في جميع الأوقات ، أي عند الإنشاء والتحديث.

استخدم التعليقات من البروتو للوصف.

هل يمكنك القيام بذلك بنفسك وإرسال طلب سحب؟

bafonins سيتعامل معها

console compaapi documentation uweb

ال 9 كومينتر

لقد انتهيت في الغالب من الحقول ذات الأولوية العالية لتكوين إعدادات MAC:


لقطات
ABP:

Screenshot 2020-03-29 at 17 41 50

الصف ب:

Screenshot 2020-03-29 at 17 44 00

أوتا:
Screenshot 2020-03-29 at 18 11 58

ومع ذلك ، من أجل إضافتها جميعًا والسماح للمستخدمين بالتسجيل ، على سبيل المثال ، The Things Uno عبر وحدة التحكم ، فإن الحقل mac_state.factory_preset_frequencies مفقود. لست متأكدًا من كيفية تمثيل ذلك بالضبط في واجهة المستخدم ، لدي حاليًا هذه الأفكار:

  1. كالتحديد المتعدد:
    Screenshot 2020-03-30 at 09 47 01

IMO ، مثل هذا المجال يجعل اختيار الترددات أمرًا سهلاً للغاية. بالإضافة إلى ذلك ، يمكننا تقديم ترددات المستخدم بناءً على frequency_plan_id للجهاز النهائي. ومع ذلك ، كما ذكر rvolosatovs أن المدخلات يمكن أن يكون لها قيم عشوائية ولا تعتمد بالضرورة على خطة التردد للجهاز النهائي.

بالإضافة إلى ذلك ، بالنسبة لهذا النهج ، سيكون من الرائع أن يكون لديك RPC لجلب الإعدادات المسبقة للترددات لكل نطاق.

  1. كمصفوفة من مدخلات الأرقام (على غرار الطريقة التي نسمح بها بإضافة رؤوس إلى عمليات تكامل الويب هوك):
    Screenshot 2020-03-30 at 11 06 13

هذا النهج أكثر مرونة ، ومع ذلك ، يستغرق المستخدم مزيدًا من الوقت لضبط المجال ، ويتطلب كتابة الترددات.

  1. كالتحديد المتعدد مع خيارات لإنشاء تسميات جديدة:

freqqs

في الأساس ، مزيج من 1 و 2.

تضمين التغريدة

أعتقد أن وجود القائمة (2) هو أوضح ما يكون ، حيث يوضح ذلك الترتيب. والنظام مهم.

يمكن أن تكون الترددات أي شيء بالفعل ، ولكن سيكون من المفيد جدًا إحضارها عبر خطة تردد موجودة.

إضافة compat/api لأننا قد نحتاج إلى NS rpc للحصول على خطة التردد.

أعتقد أن وجود القائمة (2) هو أوضح ما يكون ، حيث يوضح ذلك الترتيب. والنظام مهم.

يحافظ كلا المكونين المحددين (1) و (2) على الترتيب أيضًا.

يمكن أن تكون الترددات في الواقع أي شيء ،

مع (3) يمكن إضافة قيم تردد عشوائية أيضًا

أعتقد أن الحل (2) هو الأنظف أيضًا ، بينما (3) يبدو أجمل بالنسبة لكمية صغيرة من الترددات ، فإن وجود مضاعفات (على سبيل المثال 4 أو أكثر) سيبدو مشوشًا ويصعب تتبعه.
سيكون رائعًا إذا كان لدينا اقتراحات تردد لـ (2) في كل مربع نص (من خطة التردد المقترحة RPC) ، لذا نوع ما تراه في (3) ، ولكن لكل مربع نص

تم الانتهاء تقريبًا من التنفيذ ، ولكنك تريد الانتظار حتى يتم دمج https://github.com/TheThingsNetwork/lorawan-stack/issues/2605 قبل إجراء العلاقات العامة لإضافة اختبارات لمعالج الجهاز (بما في ذلك معالجة إعدادات mac)

ما هو الوضع هنا؟

johanstokking https://github.com/TheThingsNetwork/lorawan-stack/pull/3065 جاهز للمراجعة. لقد أضفت جميع الحقول ذات الأولوية العالية وبعض الحقول ذات الأولوية المتوسطة.

تغيير معلم هذه القضية ليس بعد ذلك. تمت إضافة جميع الحقول ذات الأولوية العالية مع بعض الحقول ذات الأولوية المتوسطة في https://github.com/TheThingsNetwork/lorawan-stack/pull/3065. سنعود إلى هذا لاحقًا إذا تمت إضافة أي حقول أخرى إلى وحدة التحكم.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات