Lorawan-stack: استخدم المعالج لإنشاء الأجهزة الطرفية

المشكلة الرئيسية في التنفيذ الحالي لشكل الجهاز هي أن كل شيء مرتبط ببعضه البعض. هذه تسبب

1. مخطط التحقق المعقد والطويل
2. لا توجد طريقة مباشرة لتعطيل بعض الحقول بناءً على تكوين المكدس
3. لا توجد طريقة مباشرة لتغيير حقول النموذج / عناوين الحقول وفقًا للقيم المحددة
4. التعقيد غير الضروري في js sdk للإنشاء / التحديث / الحذف المجمّع وكذلك إنشاء منطق التراجع

أقترح تنفيذ نموذج الجهاز باعتباره نموذجًا متعدد الخطوات. يمكن أن يبدو هذا كالتالي:

هذا النهج يعالج جميع القضايا المذكورة أعلاه:

1. بدلاً من مخطط واحد معقد ، نحدد مخططًا صغيرًا لكل خطوة.
2. ما عليك سوى تعطيل الخطوة بأكملها إذا لم يتوفر مكون معين صالح في المكدس. علاوة على ذلك ، يمكننا إبلاغ المستخدم بهذا من خلال الوصف / الإخطار.
3. قم بتكييف كل خطوة بناءً على القيم التي تم إرسالها مسبقًا. على سبيل المثال ، قم بتغيير التصنيف Join EUI إلى App EUI لإصدار lorawan 1.0.x .
4. لا حاجة للطلبات المجمعة. يصبح المستخدم مسؤولاً عن إنشاء جهاز بمكونات مختلفة. ومع ذلك ، قد نرغب في الاحتفاظ بالحذف المجمّع للراحة.

يمكن تنفيذ أجهزة التحرير ككومة من الأكورديونات:

حيث يتمدد كل أكورديون بشكل مستقل.

إلى جانب نموذج الجهاز ، يمكننا استخدام المعالج لاستمارة الطلب أيضًا من أجل:

1. قم بإنشاء التطبيق في ملف
2. اربط التطبيق بـ as

cckschifferjohanstokkinghtdvisser _ _

يبدو هذا جيدًا بالنسبة لي ، خاصةً إذا كان بإمكاننا تجميع حقول المكونات معًا في خطوة. بهذه الطريقة ، يمكننا ببساطة تخطي / تعطيل الخطوات عندما لا يتوفر أحد المكونات.

الرجوع إلى https://github.com/TheThingsNetwork/lorawan-stack/issues/1234 أيضًا ؛ حتى في حالة توفر JS ، يمكن للمستخدم تخطي حقول JS.

لقد توصلت إلى مثل هذا الرسم التخطيطي:

كل عقدة هي خطوة

• الخطوات ذات المخطط التفصيلي المنقط لا ترسل النموذج ولكن احتفظ بها في الحالة المحلية للخطوات التالية.
• يرسل آخرون طلبات إلى الخادم عند التقديم.

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

اعتبر الرسم البياني بمثابة اقتراح أولي لبدء المناقشة.

أعتقد أن هذه بداية جيدة.

• ربما يكون التدفق أفضل إذا جاء خادم الانضمام أولاً.
• من الأمور المهمة التي لم نحرز أي تقدم بشأنها حتى الآن هو الملء المسبق للحقول من قوالب الجهاز في مستودع الجهاز رقم 263. أعتقد أن هذا يمكن أن يبسط بالفعل عملية نشر الإنتاج.

وبعض الأشياء الصغيرة:

• لا يُمنع A DevEUI لأجهزة ABP (يمكن تعيينه اختياريًا)
• لا تحتوي أجهزة LoRaWAN 1.0.x على NwkKey ، فقط AppKey
• FNwkSIntKey يسمى NwkSKey (تجاه المستخدم)
• لا يحصل خادم التطبيق على NwkKey أو AppKey

نعم ، بداية رائعة.

• ربما يكون التدفق أفضل إذا جاء خادم الانضمام أولاً.

أنا أتفق مع هذا. إذا كان وضع التنشيط هو OTAA وتم تمكين المجموعة JS ، فيحصل المستخدمون على صفحة JS على خيار إدخال مفاتيح الجذر وتخزينها على المجموعة JS. (إذا قاموا بتعطيل ذلك ، يستخدم NS بحث JS ، تمامًا كما هو الحال عند عدم تمكين JS في المجموعة)

• "وضع التنشيط" في الحمولة - في الرسم التخطيطي الخاص بك يتوافق بالفعل مع حقلين - multicast bool و supports_join bool . هناك 3 خيارات ممكنة ، لأن multicast && supports_join غير صالح.
• frequency_plan -> frequency_plan_id

• resets_f_cnt اختياري ، false افتراضيًا.

• يجب تقديم FNwkSIntKey كـ NwkKey فقط لـ <1.1

• FNwkSIntKey مفقود في إعدادات ABP NS لـ> = 1.1
• الأجهزة multicast تحتاج فقط AppSKey - NS لا تحتاج إلى أي مفاتيح للأجهزة multicast لتعمل ، فقط AS

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

ربما يكون التدفق أفضل إذا جاء خادم الانضمام أولاً.

لماذا ا؟

من الأمور المهمة التي لم نحرز أي تقدم بشأنها حتى الآن هو الملء المسبق للحقول من قوالب الجهاز في مستودع الجهاز رقم 263. أعتقد أن هذا يمكن أن يبسط بالفعل عملية نشر الإنتاج.

بالنسبة لي يبدو خارج نطاق هذه المسألة

لا يُحظر استخدام DevEUI لأجهزة ABP (يمكن ضبطه اختياريًا)

هل نريد ضبطه لأجهزة ABP أيضًا؟ أود أن أقول أنه كلما قل عدد الحقول التي لدينا ، كان ذلك أفضل. ومع ذلك ، فمن الضروري أن نضيفه.

يسمى FNwkSIntKey NwkSKey (تجاه المستخدم)

لذا يجب أن تكون التسمية NwkSKey لكل من 1.0.x و 1.1.x؟ إليك ما لدينا من أجهزة الصراف الآلي في وحدة التحكم:

• لا تحتوي أجهزة LoRaWAN 1.0.x على NwkKey ، فقط AppKey
• لا يحصل خادم التطبيق على NwkKey أو AppKey

ثابت 👌

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

إذا كان وضع التنشيط هو OTAA وتم تمكين المجموعة JS ، فيحصل المستخدمون على صفحة JS على خيار إدخال مفاتيح الجذر وتخزينها على المجموعة JS. (إذا قاموا بتعطيل ذلك ، يستخدم NS بحث JS ، تمامًا كما هو الحال عند عدم تمكين JS في المجموعة).

إذن هذه مجرد مسألة السماح للمستخدمين بتخطي خطوة إرسال خادم الانضمام؟ لا توجد طلبات لشبيبة على الإطلاق؟

بخصوص https://github.com/TheThingsNetwork/lorawan-stack/issues/1134 ، هل يمكنك أيضًا تحديد مكان هذه الحقول في الرسم التخطيطي؟

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

وضع التنشيط "في الحمولة - في الرسم التخطيطي الخاص بك يتوافق بالفعل مع حقلين - منطقي متعدد البث ويدعم منطقي الدعم. هناك 3 خيارات ممكنة ، نظرًا لأن الإرسال المتعدد && support_join غير صالح.

فقط للتوضيح:

1. supports_join=true - أوتا
2. supports_join=false - ABP
3. multicast=true && **no** supports_join - إرسال متعدد
   هل هذا صحيح؟

resets_f_cnt اختياري ، خطأ افتراضيًا.

أعتقد أنه لا يزال من الجيد إظهارها للمستخدمين. هل ينبغي السماح للمستخدمين بضبطه لأجهزة البث المتعدد؟

يجب تقديم FNwkSIntKey على أنه NwkKey فقط لـ <1.1

تقصد NwkSKey ؟

frequency_plan -> frequency_plan_id
FNwkSIntKey مفقود في إعدادات ABP NS لـ> = 1.1

ثابت 👌

الرسم التخطيطي المحدث:

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

ربما يكون التدفق أفضل إذا جاء خادم الانضمام أولاً.

لماذا ا؟

نعم ، سأعود إلى هذا ؛ أعتقد أنه من المنطقي إدخال إصدارات MAC قبل إدخال المفاتيح. لذلك أنا أدعم التدفق الحالي. إذا تم إدخال إصدار MAC (عند تمكين NS) ، فلن نضطر إلى طلب NwkKey لأن هذا 1.1.x.

من الأمور المهمة التي لم نحرز أي تقدم بشأنها حتى الآن هو الملء المسبق للحقول من قوالب الجهاز في مستودع الجهاز رقم 263. أعتقد أن هذا يمكن أن يبسط بالفعل عملية نشر الإنتاج.

بالنسبة لي يبدو خارج نطاق هذه المسألة

إنه خارج النطاق بالفعل.

لا يُحظر استخدام DevEUI لأجهزة ABP (يمكن ضبطه اختياريًا)

هل نريد ضبطه لأجهزة ABP أيضًا؟ أود أن أقول أنه كلما قل عدد الحقول التي لدينا ، كان ذلك أفضل. ومع ذلك ، فمن الضروري أن نضيفه.

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

يسمى FNwkSIntKey NwkSKey (تجاه المستخدم)

لذا يجب أن تكون التسمية NwkSKey لكلٍّ من 1.0.x و 1.1.x؟ إليك ما لدينا من أجهزة الصراف الآلي في وحدة التحكم:

إنه NwkSKey لـ 1.0.x و FNwkSIntKey لـ 1.1.x.

إذا كان وضع التنشيط هو OTAA وتم تمكين المجموعة JS ، فيحصل المستخدمون على صفحة JS على خيار إدخال مفاتيح الجذر وتخزينها على المجموعة JS. (إذا قاموا بتعطيل ذلك ، يستخدم NS بحث JS ، تمامًا كما هو الحال عند عدم تمكين JS في المجموعة).

إذن هذه مجرد مسألة السماح للمستخدمين بتخطي خطوة إرسال خادم الانضمام؟ لا توجد طلبات لشبيبة على الإطلاق؟

في الواقع.

مثال على ذلك جهاز يتميز بمودم Semtech الذي يستخدم Semtech Join Server. نحتاج فقط إلى معرفة EUIs في هذه الحالة.

فيما يتعلق بالرقم 1134 ، هل يمكنك أيضًا تحديد مكان هذه الحقول في الرسم التخطيطي؟

إنهم ينتمون إلى خطوة JS ؛ هذه الحقول لتذهب إلى JS ، إذا تم تمكين JS في الكتلة وإذا كان المستخدم يريد توفير الأجهزة على JS.

هذه الحقول اختيارية.

فقط للتوضيح:

1. supports_join=true - أوتا
2. supports_join=false - ABP
3. multicast=true && **no** supports_join - إرسال متعدد
   هل هذا صحيح؟

بشكل صارم:

1. أوتا: supports_join
2. ABP: !supports_join && !multicast
3. الإرسال المتعدد: multicast

غير صالح هو supports_join && multicast ، لكن هذا (أو يجب التحقق منه) في NS.

resets_f_cnt اختياري ، خطأ افتراضيًا.

أعتقد أنه لا يزال من الجيد إظهارها للمستخدمين. هل ينبغي السماح للمستخدمين بضبطه لأجهزة البث المتعدد؟

لا ، هذا ليس للبث المتعدد. يشير resets_f_cnt إلى الوصلة الصاعدة ، ولكن لا يوجد ارتباط في الإرسال المتعدد.

يجب تقديم FNwkSIntKey على أنه NwkKey فقط لـ <1.1

تقصد NwkSKey ؟

يجب أن يكون NwkSKey بالفعل.

bafonins يرجى الاطلاع على إجابة johanstokking .
فيما يتعلق بـ multicast - مطلوب عنوان الجهاز أيضًا

• تمت إضافة الحقول من https://github.com/TheThingsNetwork/lorawan-stack/issues/1134
• تمت إضافة DevEUI لأجهزة abp / البث المتعدد
• تمت إضافة Device Address لأجهزة البث المتعدد
  

لا يزال عنوان الجهاز مفقودًا من إعدادات خادم الشبكة multicast device

لا يزال عنوان الجهاز مفقودًا من إعدادات خادم الشبكة الخاصة بجهاز الإرسال المتعدد

تم التحديث 👌

يمكن أن يكون البث المتعدد 1.0.x و 1.1.x. إدخال معلومات الجلسة ( DevAddr and keys) هو نفسه بالنسبة إلى الإرسال المتعدد كما في ABP.

يمكن أيضًا تعيين resets_join_nonces في JS بـ 1.1.x

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

بعض الأفكار والتحديات التي أراها:

• يجب أن نضيف وظائف لإجهاض التدفق بالكامل ، مما يؤدي إلى حذف أي إدخالات تسجيل تم إنشاؤها بالفعل.
  
  
  
  • وبالمثل ، فإن الانتقال إلى الخطوة السابقة يحتاج إلى وضع النموذج في "وضع التحديث" (يجب أن يكون سهلاً نسبيًا لأن نقاط النهاية هي نفسها ، باستثناء IS)
  
  
• إحدى المشكلات التي أراها هي أن خطوة خادم التطبيق ضحلة جدًا (هل من المحتمل أن يتغير هذا لاحقًا؟) وإضافة خيارات تنسيق الحمولة هناك أيضًا لا تتماشى مع احتياجات المستخدم أثناء إنشاء الجهاز.
  
  
  
  • قد يكون الحل هو دمج خطوة AS و JS نظرًا لأن كلاهما واضح ومباشر ولا يعتمدان على بعضهما البعض. أدرك أن هذا يتعارض مع الفصل حسب المكون ، لكنني أعتقد أن هذا من شأنه أن يبسط التدفق بأكمله بتجريد معقول. خاصة وأننا لا ننقل أي اتصال بمكونات المكدس المعنية ضمن الخطوات.
  
  
• اعتمادًا على تكوين المكدس ، قد ينتهي بنا الأمر بمعالج يحتوي على خطوة أو خطوتين فقط ، وهو نمط مضاد للمعالجات.
  
  
  
  • في حالة خطوة واحدة فقط ، يمكننا ببساطة إخفاء / إزالة جانب المعالج
  
  
  • لخطوتين ، أعتقد أننا يجب أن نتعايش مع المشكلة 🤷‍♂
  
  
• يجب أن يؤخذ في الاعتبار أن حل المعالج سيزيد من _وقت_الإكمال_ لقصة المستخدم قليلاً
  
  
  
  • قد يصبح هذا مشكلة في المواقف التي يلزم فيها إنشاء الكثير من الأجهزة يدويًا ، على الرغم من أننا سنقدم ميزات إنشاء الدُفعات لحالة الاستخدام هذه ويمكن أن يساعد CLI / البرمجة النصية في مثل هذه المواقف أيضًا
  
  
  • ومع ذلك ، ضع في اعتبارك الاختلاف مع إنشاء جهاز وحدة التحكم V2 وكيف يمكن للمستخدمين إدراك هذا التغيير
  
  
• يعجبني حل "التحرير المقسم" المقابل للإعدادات العامة
• مخطط التدفق مفيد للغاية ويجب علينا تحديثه باستمرار 👍

التعقيد غير الضروري في js sdk للإنشاء / التحديث / الحذف المجمّع وكذلك إنشاء منطق التراجع

أعتقد أن الوظيفة الموجودة في SDK لتقسيم طلبات الجهاز ودمجها لا تزال ذات قيمة كبيرة ، حتى لو لم نستخدمها في هذه الحالة

johanstokking لأجهزة البث المتعدد يحتاج NS فقط إلى SNwkSIntKey في 1.1 لحساب MIC. في الواقع ، لا ينبغي السماح لـ FNwkSIntKey و NwkSEncKey بتعيين IMO.

• يجب أن نضيف وظائف لإجهاض التدفق بالكامل ، مما يؤدي إلى حذف أي إدخالات تسجيل تم إنشاؤها بالفعل.
  
  
  
  • وبالمثل ، فإن الانتقال إلى الخطوة السابقة يحتاج إلى وضع النموذج في "وضع التحديث" (يجب أن يكون سهلاً نسبيًا لأن نقاط النهاية هي نفسها ، باستثناء IS)
  
  

لا أعتقد أننا يجب أن نصنع أي شيء قبل أن نضغط على Finish أو شيء من هذا القبيل. لا ينبغي أن يؤدي التنقل ذهابًا وإيابًا في المعالج وإغلاق نافذة المتصفح إلى إنشاء نصف أجهزة.

• إحدى المشكلات التي أراها هي أن خطوة خادم التطبيق ضحلة جدًا (هل من المحتمل أن يتغير هذا لاحقًا؟) وإضافة خيارات تنسيق الحمولة هناك أيضًا لا تتماشى مع احتياجات المستخدم أثناء إنشاء الجهاز.

سنضيف التكوين لحزم التطبيق هنا (على سبيل المثال ، إعداد البث المتعدد عن بعد ، نقل كتلة البيانات المجزأة ، خيارات مودم Semtech ، إلخ). لذا نعم ، إنها ضحلة الآن ولكنها ستمتد.

• قد يكون الحل هو دمج خطوة AS و JS نظرًا لأن كلاهما واضح ومباشر ولا يعتمدان على بعضهما البعض. أدرك أن هذا يتعارض مع الفصل حسب المكون ، لكنني أعتقد أن هذا من شأنه أن يبسط التدفق بأكمله بتجريد معقول. خاصة وأننا لا ننقل أي اتصال بمكونات المكدس المعنية ضمن الخطوات.

من أجل أنفسنا في المستقبل ، أوصي بإبقائهم منفصلين. كما أن دمجها يجعل عرض الأشياء على تلك الصفحات مشروطًا بتوفر المكون الذي يضيف تعقيدًا إلى تدفق معقد بالفعل.

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

  • في حالة خطوة واحدة فقط ، يمكننا ببساطة إخفاء / إزالة جانب المعالج
  • لخطوتين ، أعتقد أننا يجب أن نتعايش مع المشكلة 🤷‍♂

• يجب أن يؤخذ في الاعتبار أن حل المعالج سيزيد من _وقت_الإكمال_ لقصة المستخدم قليلاً

  • قد يصبح هذا مشكلة في المواقف التي يلزم فيها إنشاء الكثير من الأجهزة يدويًا ، على الرغم من أننا سنقدم ميزات إنشاء الدُفعات لحالة الاستخدام هذه ويمكن أن يساعد CLI / البرمجة النصية في مثل هذه المواقف أيضًا
  • ومع ذلك ، ضع في اعتبارك الاختلاف مع إنشاء جهاز وحدة التحكم V2 وكيف يمكن للمستخدمين إدراك هذا التغيير

يعد فصل المكونات وسيناريوهات النشر المرنة أحد التغييرات الرئيسية مقارنةً بـ V2 ، لذلك فمن المنطقي تمامًا أن هذا فعال في وحدة التحكم V3.

في الواقع ، لإنشاء كميات كبيرة من الأجهزة ، يجب على الأشخاص استخدام واجهات برمجة التطبيقات (API) و CLI على أي حال.

لا يوجد سيناريو بخطوة واحدة ، فهو دائمًا خطوتان على الأقل.

ماذا عن تقديم علامات التبويب بدلاً من الصفحات؟ بهذه الطريقة تظل صفحة واحدة ولكن يمكن الوصول إلى الأشياء بسهولة دون الانتقال ذهابًا وإيابًا في خطوات.

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

لا أعتقد أننا يجب أن نصنع أي شيء قبل أن نضغط على Finish أو شيء من هذا القبيل.

إذا قدمنا ​​الطلب الفعلي في الخطوة الأخيرة فقط ، فهذا يعني أننا سنقدم 3-4 طلبات. كيف نتعامل مع الأخطاء التي ترجعها المكونات المختلفة؟ التعامل مع هذا ، وتوجيه المستخدم إلى الخطوة الخطأ / إعادة تعيين المتجر / إلخ. معقد. لهذا السبب أقترح إرسال القيم في كل خطوة ، لأن كل خطوة متتالية يمكن أن تعتمد على القيم المقدمة باعتبارها صالحة.

لا ينبغي أن يؤدي التنقل ذهابًا وإيابًا في المعالج وإغلاق نافذة المتصفح إلى إنشاء نصف أجهزة.

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

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

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

حسنًا ، نحن منفتحون على الحلول البديلة. أي مقترحات؟

إذا قدمنا ​​الطلب الفعلي في الخطوة الأخيرة فقط ، فهذا يعني أننا سنقدم 3-4 طلبات. كيف نتعامل مع الأخطاء التي ترجعها المكونات المختلفة؟ التعامل مع هذا ، وتوجيه المستخدم إلى الخطوة الخطأ / إعادة تعيين المتجر / إلخ. معقد. لهذا السبب أقترح إرسال القيم في كل خطوة ، لأن كل خطوة متتالية يمكن أن تعتمد على القيم المقدمة باعتبارها صالحة.

نعم. لا بأس بذلك ، طالما أن وحدة التحكم يمكنها التعامل مع الأجهزة الموجودة في التقارير الإلكترونية ولكن لا يمكن العثور عليها في JS / NS / AS بسبب فشل هذه الخطوة أو قيام المستخدم بإغلاق علامة التبويب أو شيء من هذا القبيل.

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

ماذا تقصد؟

لاحظ أن AS ، على سبيل المثال ، لا يحتاج إلى أي حقول ، إنه يحتاج فقط إلى وجود الجهاز. لذلك إذا كان AS موجودًا ، حتى إذا لم يقم المستخدم بإدخال أي قيم لـ AS ، فلا يزال يتعين عليه إنشاء جهاز (فارغ) في AS.

ماذا تقصد؟

آسف. كان هذا تجاه اقتراح kschiffer :

وبالمثل ، فإن الانتقال إلى الخطوة السابقة يحتاج إلى وضع النموذج في "وضع التحديث" (يجب أن يكون سهلاً نسبيًا لأن نقاط النهاية هي نفسها ، باستثناء IS)

لا ينبغي أن يؤدي التنقل ذهابًا وإيابًا في المعالج وإغلاق نافذة المتصفح إلى إنشاء نصف أجهزة.

سأعتبر هذا بمثابة تحسين مستقبلي. في الوقت الحالي ، يمكننا فقط إظهار إشعار للمستخدم بشأن التدفق غير المكتمل. لاحقًا ، يمكن للمستخدم تعديل / حذف الجهاز في صفحة الإعدادات العامة.

حسنًا ، نحن منفتحون على الحلول البديلة. أي مقترحات؟

حسنًا ، أعتقد أنه نظرًا لخطورة هذا الموقف بالذات ، فلا بأس من التعايش مع هذه المشكلة. تشير صياغتك إلى أنه لا ينبغي أن أذكر المخاوف بدون حلول مقترحة ، لكني أحب أن أعطي للآخرين الفرصة للتوصل إلى بعضها إذا لم أجد أيًا منها على الفور.

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

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

وإلا فإن التعامل مع هذا الأمر يصبح معقدًا للغاية.

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

سأعتبر هذا بمثابة تحسين مستقبلي. في الوقت الحالي ، يمكننا فقط إظهار إشعار للمستخدم بشأن التدفق غير المكتمل. لاحقًا ، يمكن للمستخدم تعديل / حذف الجهاز في صفحة الإعدادات العامة.

ليس الأمر الأمثل ولكنه مقبول بالنسبة لي ، طالما أننا سنعزز ذلك في النهاية.

كما تمت مناقشته في وضع عدم الاتصال ، إليك الاقتراح الأولي ؛

إنشاء الجهاز

1. الاعدادات العامة
   
   
   
   • مجالات
     
     
     
     
     
     • ids
     
     
     
     • اختياري name
     
     
     
     • اختياري description
     
     
     
     • اختياري attributes
     
     
     
     • وضع التنشيط المطلوب: OTAA أو ABP أو Multicast
     
     
     
     • إذا كان NS في الكتلة
       
       
       
       
       
       
       
       • lorawan_version
       
       
       
       
       • lorawan_phy_version
       
       
       
       
     
     
     
   
   
   • هذه الخطوة تنشئ الجهاز في IS فقط. بهذه الطريقة ، نعلم أن المعرفات مجانية
   
   
   • يتم استخدام وضع التنشيط في حالة الجلسة
   
   
   • إذا لم يكن NS في المجموعة ، من أجل التبسيط في المعالج ، يمكنك استخدام أعلى الإصدارات المعروفة (أي الآن 1.1.0 و 1.1.0-A على التوالي) في حالة الجلسة
   
   

2. إعدادات LoRaWAN

   • إذا كان NS في الكتلة: الحقول
     
     
     
     • lorawan_version (مطلوب)
     
     
     • lorawan_phy_version (مطلوب)
     
     
     • تعيين supports_join إذا كان وضع التنشيط هو OTAA (مطلوب)
     
     
     • multicast اضبط إذا كان وضع التنشيط متعدد البث
     
     
     • supports_class_b
     
     
     • supports_class_c
     
     
     • frequency_plan_id (مطلوب)
     
     
     • mac_settings.supports_32_bit_f_cnt
     
     
     • mac_settings.factory_preset_frequencies
     
     
     • mac_settings.ping_slot_data_rate_index.value
     
     
     • mac_settings.ping_slot_frequency
     
     
     • mac_settings.ping_slot_periodicity.value
     
     
     • mac_settings.rx2_data_rate_index.value
     
     
     • min_frequency
     
     
     • max_frequency
     
     
   • إذا كان NS في المجموعة: الحقول إذا كان وضع التنشيط هو OTAA
     
     
     
     • خانة اختيار ما إذا كنت تريد استخدام JS خارجي (محدد افتراضيًا)
     
     
   • الحقول إذا كان وضع التنشيط هو ABP أو Multicast
     
     
     
     • إذا كان NS أو AS في المجموعة: session.dev_addr
     
     
     • إذا كان NS أو AS في الكتلة: أنشئ session.keys.session_key_id
     
     
     • إذا كان NS في الكتلة: session.keys.f_nwk_s_int_key.key - مطلوب
     
     
     • إذا كان NS في الكتلة: session.keys.s_nwk_s_int_key.key (إذا كان LW> = 1.1.0) - مطلوب
     
     
     • إذا كان NS في الكتلة: session.keys.nwk_s_enc_key.key (إذا كان LW> = 1.1.0) - مطلوب
     
     
     • إذا كان AS في المجموعة: session.keys.app_s_key.key - مطلوب
     
     
     • إذا كان NS في الكتلة: session.last_conf_f_cnt_down
     
     
     • إذا كان NS في الكتلة: session.last_n_f_cnt_down
     
     
   • إذا كان NS في المجموعة: الحقول إذا كان وضع التنشيط هو ABP
     
     
     
     • mac_settings.resets_f_cnt
     
     
   • إذا كان NS أو AS في المجموعة: الحقول إذا كان وضع التنشيط هو ABP
     
     
     
     • session.last_f_cnt_up - هذا مطلوب للأمان
     
     

   • إذا كان NS في المجموعة: الحقول إذا كان وضع التنشيط هو ABP أو OTAA

     • mac_settings.adr_margin
     • mac_settings.class_b_timeout
     • mac_settings.class_c_timeout
     • mac_settings.desired_adr_ack_delay_exponent.value
     • mac_settings.desired_adr_ack_limit_exponent.value
     • mac_settings.desired_max_duty_cycle.value
     • mac_settings.desired_rx1_data_rate_offset
     • mac_settings.desired_rx1_delay.value
     • mac_settings.desired_rx2_data_rate_index.value
     • mac_settings.desired_rx2_frequency
     • mac_settings.max_duty_cycle.value
     • mac_settings.rx1_data_rate_offset
     • mac_settings.rx1_delay.value
     • mac_settings.status_count_periodicity
     • mac_settings.status_time_periodicity
     • mac_settings.supports_32_bit_f_cnt
     • mac_settings.use_adr

   • يقوم هذا بتعيين الجهاز في NS و AS (إذا كان في المجموعة). إذا كان لدينا جهاز OTAA ، فليس لدينا أي شيء لضبطه في AS في هذه المرحلة ، لكنني ما زلت أقوم بالدعوة إلى الاتساق

3. إذا كان AS في الكتلة: إعدادات التطبيق
   
   
   
   • مجالات
     
     
     
     
     
     • payload_formatters
     
     
     
   
   
   • هذا يضبط الجهاز في AS
   
   
4. إذا كان JS في المجموعة وإذا كان OTAA وإذا لم يكن يستخدم JS خارجي: إعدادات الأمان
   
   
   
   • مجالات
     
     
     
     
     
     • توليد root_keys.root_key_id
     
     
     
     • root_keys.app_key.key
     
     
     
     • root_keys.nwk_key.key (إذا كان LW> = 1.1.0)
     
     
     
     • resets_join_nonces
     
     
     
     • home_net_id
     
     
     
     • network_server_kek_label
     
     
     
     • application_server_kek_label
     
     
     
     • application_server_id
     
     
     
   
   
   • هذا يضبط الجهاز في JS
   
   

تحديث الجهاز

هنا ، سأذهب مع نهج مبوب ، بشكل أساسي مع خطوات المعالج كعلامات تبويب.

المفتاح هنا هو ذلك ؛

• ids ، supports_join ، multicast للقراءة فقط
• يتم تقييم وضع التنشيط بهذا الترتيب:
  
  
  
  • OTAA: إذا لم يكن هناك NS في الكتلة ، أو إذا كان NS في الكتلة و NS يقول supports_join
  
  
  • ABP: يحتاج NS في الكتلة (ويكون مناسبًا فقط في هذه الحالة): !supports_join && !multicast
  
  
  • الإرسال المتعدد: يحتاج NS في الكتلة (ويكون مناسبًا فقط في هذه الحالة): !supports_join && multicast (على الرغم من أن multicast يجب أن يكون كافيًا)
  
  

بعض حالات الاستخدام لدعم تحديث الأجهزة:

• يمكن أن تحتوي وحدة التحكم على NS و AS و JS في المجموعة ، ولكن قد لا يكون الجهاز في NS أو AS أو JS (تحصل وحدة التحكم على 404). هذه حالة صالحة ويجب أن تتعامل وحدة التحكم مع هذا الأمر. مثال على الحالة هو الجهاز الذي تمت المطالبة به ، والذي تم تعيين الجهاز في ER و JS ، ولكن ليس (حتى الآن) في NS و AS
• بناءً على السابق: قم بتعيين LoRaWAN وإعدادات التطبيق لجهاز موجود فقط في ER و JS (أي قم بتعيينه في NS و AS)
• تغيير lorawan_version و lorawan_phy_version (هذا يغير القيود)
• تغيير خيار "JS الخارجية" ؛ على سبيل المثال ، لنفترض أن لديك جهازًا موجودًا ولكنك تريد تكوين مفاتيح الجذر في الكتلة- JS. بعد ذلك ، قمت بإلغاء تحديد مربع الاختيار هذا ويجب أن يكون المستخدم قادرًا على تعيين مفاتيح الجذر في علامة التبويب إعدادات الأمان
• من خلال الاستيراد المجمع ، قد يتم إنشاء الجهاز على JS ولديه مفاتيح جذر ، لكنها غير مكشوفة. مثل اليوم ، يجب أن يكون المستخدم قادرًا على رؤية أن مفاتيح الجذر موجودة ( root_keys != nil ) لكنها غير مكشوفة ( root_keys.app_key == null إلخ). يجب أن يكون المستخدم قادرًا على ترك مفاتيح الجذر سليمة

الاشياء العامة

• للمفاتيح ، حقل إدخال أو إنشاء زر عشوائي
• الفرق بين JS الخارجية ومفاتيح الجذر غير المكشوفة ؛
  
  
  
  • JS الخارجية هو المكان الذي لا يكون فيه JS في نفس المجموعة مثل NS. يسمح هذا بإنشاء جهاز OTAA ولكن دون الحاجة إلى إدخال إعدادات الأمان ، حيث يتم تكوين المفاتيح في مكان آخر
  
  
  • مفاتيح الجذر غير المكشوفة هي مكان وجود الجهاز في JS المحلي للكتلة ، لكن JS لا يكشف مفاتيح الجذر. هذا للأمان ، أي في حالة العناصر الآمنة ، حيث يمكن لـ JS الوصول إلى مفاتيح الجذر ولكن لا يعرضها
  
  

أعتقد أن https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -525719408 يحتوي بالفعل على كل ما هو ضروري لـ NS.
أعتقد أن كل mac_settings يجب أن يكون متاحًا ليتم تعيينه لجميع الأجهزة غير ذات البث المتعدد.
بالنسبة لأجهزة البث المتعدد ، يكون ما يلي هو المعنى فقط:

• "mac_settings.factory_preset_frequencies"
• "mac_settings.ping_slot_data_rate_index.value"
• "mac_settings.ping_slot_frequency"
• "mac_settings.ping_slot_periodicity.value"
• "mac_settings.rx2_data_rate_index.value"
• "mac_settings.rx2_frequency"

ربما بعض الأشياء لتوضيح

خلق:

1. الاعدادات العامة
   أ. عندما نقوم بإنشاء الجهاز في ER ، لا نقوم بتعيين عناوين NS / AS / JS. هل نقوم بتحديث تسجيل ER عندما يتم تعيين الجهاز في تلك؟ ماذا لو كنا نستخدم JS خارجي؟
   ب. هل نقوم بتخزين وضع التنشيط في ER؟
   ج. هل نقوم بتخزين إصدارات phy / mac في ER؟
2. إعدادات LoRaWAN
   أ. ماذا عن supports_class_b ؟
3. إعدادات التطبيق
   أ. نعم ، قد يعني هذا أننا قمنا بتعيين الجهاز على AS مرتين

تحديث:

• وضع التنشيط: سيكون أسهل كثيرًا إذا قمنا بتخزينه في ER
• هل ننظر فقط إلى 404 أم أيضًا في عناوين NS / AS / JS في ER؟
• أعتقد أنه سيكون من الجيد أن تكون قادرًا على حذف تسجيل NS / AS / JS فردي على سبيل المثال عند تغيير "JS خارجي" إلى true ، أو إعادة تعيين حالة الجهاز في NS

الاشياء العامة:

• _ "JS الخارجية هو المكان الذي لا يكون فيه JS في نفس المجموعة مثل NS" _: أعتقد أن هذا يجب أن يكون شيئًا مثل "Join_server_address ليس هو نفسه عنوان JS في تهيئة وحدة التحكم"

إذا كنا نتحدث عن حقول المستوى الأعلى:
https://github.com/TheThingsNetwork/lorawan-stack/blob/375c82cc068bbadb72b887e25631f8f2dc03a366/api/end_device.proto#L395 -L418 ينتمي هذا الجزء بالكامل إلى NS (ولكن ليس كل هذه العناصر مطلوبة)

لا ينطبق m{in,ax}_frequency على البث المتعدد

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

أعتقد أن رقم 579 (تعليق) يحتوي بالفعل على كل ما هو ضروري لـ NS.

أعتقد أن كل mac_settings يجب أن يكون متاحًا ليتم تعيينه لجميع الأجهزة غير ذات البث المتعدد.
بالنسبة لأجهزة البث المتعدد ، يكون ما يلي هو المعنى فقط:

إحدى المشكلات المتعلقة بهذه المشكلة هي كمية المعلومات المدفونة في التعليقات.

هل يمكنك إضافة الحقول الصحيحة في الأماكن الصحيحة من فضلك؟ أنا بخير إذا قمت بنسخ قائمة النقاط الكاملة الخاصة بي ، لذلك نعمل بشكل متزايد على ذلك حتى يكون لدينا نسخة نهائية.

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

1. الاعدادات العامة
   أ. عندما نقوم بإنشاء الجهاز في ER ، لا نقوم بتعيين عناوين NS / AS / JS. هل نقوم بتحديث تسجيل ER عندما يتم تعيين الجهاز في تلك؟ ماذا لو كنا نستخدم JS خارجي؟

أعتقد أنه يجب علينا تحديث العناوين عندما نقوم بتعيين الأجهزة في AS / NS / JS.

ب. هل نقوم بتخزين وضع التنشيط في ER؟

لا ، ليس لدينا مجال لذلك في الوقت الحالي ، ولسنا في حاجة إليه حقًا ويخلق مجالًا للتناقضات.

ج. هل نقوم بتخزين إصدارات phy / mac في ER؟

لا ، انظر وثائق API. مرة أخرى ، لا أرى الحاجة ويخلق مجالًا للتناقضات.

أ. ماذا عن supports_class_b ؟

نعم أعتقد أنه يجب علينا إضافة ذلك ، المعلق رقم 19. rvolosatovs يرجى تضمين هذا في نسخة محدثة إذا كان ذلك مناسبًا.

1. إعدادات التطبيق
   أ. نعم ، قد يعني هذا أننا قمنا بتعيين الجهاز على AS مرتين

نعم ، هذا لا يضر

تحديث:

• وضع التنشيط: سيكون أسهل كثيرًا إذا قمنا بتخزينه في ER

نعم ، لكني لست متأكدًا مما إذا كان ينبغي أن نذهب من أجل السهولة وما إذا كان ذلك ينطبق تمامًا. نحن بحاجة إلى توفيره في المسار الساخن.

أيضًا ، سيكون الأمر سهلاً فقط إذا تمكنا من البدء من سجل نظيف. ومع ذلك ، نحتاج إلى أن نكون متوافقين مع الإصدارات السابقة ، مع إضافة الاستدلال عندما لا يكون lorawan_version في ER ، وتقديم يحصل الشرطي من NS وما إلى ذلك.

• هل ننظر فقط إلى 404 أم أيضًا في عناوين NS / AS / JS في ER؟

لا يمكننا الحصول على 404 إلا إذا كان هناك عنوان معين ، وإلا فلن يكون هناك شيء يمكن الحصول عليه. يجب أن نفسر كلاهما على أنهما "ليس في ذلك السجل". لا يمكننا الخطأ هنا (كما فعلنا من قبل) ، بالضبط بسبب عدم حدوث الإنشاء في IS و AS / NS / JS في نفس الوقت ، ويجب أن يكون المستخدمون قادرين على استعادة التناقضات التي أنشأتها وحدة التحكم.

• أعتقد أنه سيكون من الجيد أن تكون قادرًا على حذف تسجيل NS / AS / JS فردي على سبيل المثال عند تغيير "JS خارجي" إلى true ، أو إعادة تعيين حالة الجهاز في NS

نعم ، لنفعل ذلك لاحقًا

• _ "JS الخارجية هو المكان الذي لا يكون فيه JS في نفس المجموعة مثل NS" _: أعتقد أن هذا يجب أن يكون شيئًا مثل "Join_server_address ليس هو نفسه عنوان JS في تهيئة وحدة التحكم"

نعم ، هذه بالفعل طريقة التحقق من ذلك. يمكن أن يكون join_server_address فارغًا أيضًا باستخدام interop.

bafonins ألا يزال لديك مصدر الرسم البياني؟
نظرًا لقيام الكثير من العمل ببناء ذلك بالفعل ، أعتقد أنه يجب علينا تحديث ذلك فقط لجعله مكتملًا للحصول على تمثيل واضح؟
يمكننا أيضًا العمل على تحديث جزء NS في وضع عدم الاتصال لعدم تشويش المناقشة هنا.

لقد قمت بتحديث الرسم البياني بجميع حقول NS الممكنة
الحقول باللون الأحمر إلزامية

rvolosatovs نحن نهدف إلى تحديد التدفق والحقول التي نقدمها في وحدة التحكم عند إنشاء الأجهزة وتحديثها.

كما،

• يجب ألا نسمح بتغيير mac_state.lorawan_version
• يمكننا عمل mac_state.ping_slot_periodicity من خلال CLI في الوقت الحالي
• يرجى التفكير في كيفية قيام المستخدم بتعيين supports_class_b و supports_class_c و mac_state.device_class ؛ وهو جزء من الإنشاء ، وهو جزء من التحديث ، كيف يرتبط أحدهما ببعضه البعض؟
• لا ينبغي أن نغير العدادات الفردية ؛ سيفعل زر "إعادة تعيين عدادات الإطارات" (والذي يمكن أن يكون afaik إجراءً منفصلاً ، كما هو الحال لدينا في V2 Console ، وهو ضبط العدادات على 0 )
• يجب أن نختار بعناية الإعدادات التي نريدها في وحدة التحكم وهي mac_settings و mac_state.desired_parameters ؛ htdvisser هل يمكنك التفكير هنا؟

لقد غيرت الترتيب في https://github.com/TheThingsNetwork/lorawan-stack/issues/579#issuecomment -553347858. الرجاء العمل بشكل متزايد على تلك القائمة.

هل يمكنك إضافة الحقول بالضبط في الأماكن الصحيحة من فضلك؟

لقد أجبت على هذا السؤال - أي لقد قدمت جميع الحقول التي يمكن تعيينها ويجب تعيينها على NS. أو على الأقل هكذا فهمت سؤالك.

فيما يتعلق بما يجب أن يكون في وحدة التحكم ، من المحتمل أن يكون كل شيء mac_state قابلاً للتعيين فقط من خلال CLI ، ومع ذلك قد نطلب ذلك لأجهزة ABP / البث المتعدد و / أو أجهزة OTAA ، التي يتم تسجيلها في جلسة حالية ، و ، ومن ثم دولة MAC.
سوف أقوم بتحديث تعليقك.

لا ينبغي أن نغير العدادات الفردية ؛ سيفعل زر "إعادة تعيين عدادات الإطارات" (والذي يمكن أن يكون afaik إجراءً منفصلاً ، كما هو الحال في V2 Console ، وهو ضبط العدادات على 0)

نحن بحاجة إلى أن نكون قادرين على تعيين عدادات إطار الوصلة الهابطة لـ ABP والبث المتعدد - وإلا فلن يتمكن NS من إرسال روابط هابطة
بالنسبة إلى عدادات الإطارات للوصلة الصاعدة ، فهي مفيدة جدًا أيضًا من وجهة نظر الأمان لـ ABP

تحديث الجهاز

هنا ، سأذهب مع نهج مبوب ، بشكل أساسي مع خطوات المعالج كعلامات تبويب.

دعنا نستخدم نهج الأكورديون هنا ، كما هو موضح في التعليق الأول من bafonins :

سيعطينا عددًا أقل من المشكلات المتعلقة بالمساحة الأفقية ، ويسمح بتمييز الأوضاع باستخدام أزرار Edit / Create .

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

نحن بحاجة إلى أن نكون قادرين على تعيين عدادات إطار الوصلة الهابطة لـ ABP والبث المتعدد - وإلا فلن يتمكن NS من إرسال روابط هابطة
بالنسبة إلى عدادات الإطارات للوصلة الصاعدة ، فهي مفيدة جدًا أيضًا من وجهة نظر الأمان لـ ABP

إذا كان هذا بسيطًا يمكننا القيام به. في الواقع ، قد يكون اثنان / ثلاثة مربعات إدخال أبسط من زر إعادة الضبط الذي يؤدي إلى إجراء معين.

فيما يتعلق بما يجب أن يكون في وحدة التحكم ، من المحتمل أن يكون كل شيء mac_state قابلاً للتعيين فقط من خلال CLI ، ومع ذلك قد نطلب ذلك لأجهزة ABP / البث المتعدد و / أو أجهزة OTAA ، التي يتم تسجيلها في جلسة حالية ، و ، ومن ثم دولة MAC.

أفهم. أعتقد أنه يجب علينا فصل "أجهزة ABP الجديدة وإعادة تعيينها" عن "أجهزة ABP الموجودة بالفعل على الشبكة".

يجب أن يكون الأول مكتملاً ، لذا يجب أن يشتمل على بعض mac_state (أي ترددات إعادة ضبط المصنع ، وتأخير RX1 ، وإعدادات RX2 ، إلخ) ولكن ليس mac_state.desired_parameters .

يجب أن يتم هذا الأخير عن طريق الترحيل ويمكننا إضافة إعدادات الضبط لاحقًا في وحدة التحكم ؛ في الوقت الحالي يجب استخدام CLI.

شكرا للتحديث

إعدادات LoRaWAN

• إذا كان NS في الكتلة: الحقول
  
  
  
  • mac_settings.factory_preset_frequencies
  
  
  • mac_settings.ping_slot_data_rate_index.value
  
  
  • mac_settings.ping_slot_frequency
  
  
  • mac_settings.ping_slot_periodicity.value
  
  
  • mac_settings.rx2_data_rate_index.value
  
  

هل هذه ضرورية لـ OTAA؟ أليس هذا فقط لـ ABP و Multicast؟

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

إعدادات LoRaWAN

• إذا كان NS في الكتلة: الحقول
  
  
  
  • mac_settings.factory_preset_frequencies
  
  
  • mac_settings.ping_slot_data_rate_index.value
  
  
  • mac_settings.ping_slot_frequency
  
  
  • mac_settings.ping_slot_periodicity.value
  
  
  • mac_settings.rx2_data_rate_index.value
  
  

هل هذه ضرورية لـ OTAA؟ أليس هذا فقط لـ ABP و Multicast؟

جميع إعدادات MAC اختيارية حسب التصميم.
الحالة الوحيدة التي تكون فيها هذه الأجهزة "مطلوبة" هي أجهزة البث المتعدد من الفئة ب ، وذلك بسبب مواصفات عملية الفئة ب.
بصرف النظر عن ذلك ، من المحتمل أن يكون مطلوبًا لـ ABP factory_preset_frequencies للحصول على أفضل النتائج ، لكن لا شيء يمنع جهاز OTAA من الحصول على هذه المجموعة.

جميع إعدادات MAC اختيارية حسب التصميم.
الحالة الوحيدة التي تكون فيها هذه الأجهزة "مطلوبة" هي أجهزة البث المتعدد من الفئة ب ، وذلك بسبب مواصفات عملية الفئة ب.

نعم

بصرف النظر عن ذلك ، من المحتمل أن يكون factory_preset_frequencies مطلوبًا لـ ABP للحصول على أفضل النتائج ، لكن لا شيء يمنع جهاز OTAA من الحصول على هذه المجموعة.

إنه غير فعال بالنسبة لـ OTAA ؛ ترددات الانضمام الافتراضية مطلوبة حسب المواصفات ، وتأتي القنوات عبر أوامر قبول وقبول MAC. لا ينبغي أن يكون هناك تكوين خارج النطاق للترددات المحددة مسبقًا لأجهزة OTAA.

bafonins هل يمكنك إعطاء تحديث الحالة والجدول الزمني لهذه المشكلة؟

بالنسبة إلى app_s_key و skip_payload_crypto ، هذا هو الشيء ؛

• AS يحترم الحقل skip_payload_crypto للجهاز النهائي. إذا كان true ، لا يقوم AS بتشفير الحمولة النافعة وفك تشفيرها
  
  
  
  • سيحصل AS على skip_payload_crypto على مستوى التطبيق أيضًا (عبر Link ، مثل مُنسِّقات الحمولة) ، والتي لها الأسبقية على إعداد الجهاز النهائي
  
  
• من المحتمل أن يكون هناك دائمًا app_s_key في AS ، ولكن قد يتم تغليفه ، على سبيل المثال لم يتم تعيين session.keys.app_s_key.key (ولكن تم تعيين encrypted_key و kek_label )
  
  
  
  • عندما لا يحتوي AS على KEK ، أي لا يمكنه فك المفتاح المشفر. الآن ، تلك الأخطاء. من المحتمل أن نعيد app_s_key المشفر كما هو للعملاء
  
  
• في وحدة التحكم ، إذا تم تعيين skip_payload_crypto true (على رابط الجهاز أو التطبيق) ، فلا تهتم بـ app_s_key : قم بتعطيله ، لا تهتم