Lorawan-stack: 최종 장치 생성을 위한 마법사 사용

장치 형태의 현재 구현의 주요 문제는 모든 것이 함께 결합된다는 것입니다. 이로 인해

1. 복잡하고 긴 유효성 검사 스키마
2. 스택 구성을 기반으로 특정 필드를 비활성화하는 간단한 방법 없음
3. 선택한 값에 따라 양식 필드/필드 제목을 변경하는 간단한 방법 없음
4. 일괄 생성/업데이트/삭제 및 생성 롤백 로직을 위한 js sdk의 불필요한 복잡성

장치 형태를 다단계 형태로 구현할 것을 제안합니다. 다음과 같이 보일 수 있습니다.

이러한 접근 방식은 위에서 언급한 모든 문제를 해결합니다.

1. 하나의 복잡한 스키마 대신 각 단계에 대해 작은 스키마를 정의합니다.
2. 특정 책임 있는 구성 요소를 스택에서 사용할 수 없는 경우 전체 단계를 비활성화하기만 하면 됩니다. 또한 설명/알림을 통해 사용자에게 이를 알릴 수 있습니다.
3. 이전에 제출한 값에 따라 각 단계를 조정합니다. 예를 들어 lorawan 버전 1.0.x 의 경우 Join EUI 레이블을 App EUI 로 변경합니다.
4. 일괄 요청이 필요하지 않습니다. 사용자는 다른 구성 요소에서 장치를 만드는 책임이 있습니다. 그러나 편의를 위해 일괄 삭제를 유지하고 싶을 수 있습니다.

편집 장치는 아코디언 스택으로 구현할 수 있습니다.

각 아코디언이 독립형 형태로 확장되는 곳.

장치 양식 외에도 신청서에 마법사를 사용하여 다음을 수행할 수 있습니다.

1. is에서 애플리케이션 생성
2. 응용 프로그램을 다음으로 연결

cc @kschiffer @johanstokking @htdvisser

특히 구성 요소에 대한 필드를 한 단계에서 함께 그룹화할 수 있는 경우에 좋습니다. 그렇게 하면 구성 요소를 사용할 수 없을 때 단계를 건너뛰거나 비활성화할 수 있습니다.

https://github.com/TheThingsNetwork/lorawan-stack/issues/1234 도 참조하십시오. JS를 사용할 수 있는 경우에도 사용자는 JS 필드를 건너뛸 수 있습니다.

나는 그러한 다이어그램을 생각해 냈습니다.

모든 노드는 단계입니다

• 점선 윤곽선이 있는 단계는 양식을 제출하지 않고 다음 단계를 위해 로컬 상태에 보관합니다.
• 다른 사람들은 제출 시 서버에 요청을 보냅니다.

복잡해 보이지만 현재 구현은 유효성 검사/제출/필드 마스크 생성 등과 관련하여 훨씬 더 큰 상태 공간을 가지고 있습니다.

다이어그램을 토론을 시작하기 위한 초기 제안으로 고려하십시오.

좋은 시작이라고 생각합니다.

• Join Server가 먼저 오면 흐름이 더 좋을 것입니다.
• 아직 진행하지 않은 중요한 사항은 장치 저장소 #263에 있는 장치 템플릿의 필드를 미리 채우는 것입니다. 프로덕션 배포 프로세스를 정말 단순화할 수 있다고 생각합니다.

그리고 몇 가지 작은 것들:

• DevEUI 는 ABP 장치에 대해 금지되지 않습니다(선택적으로 설정할 수 있음).
• LoRaWAN 1.0.x 장치에는 NwkKey 가 없고 AppKey 있습니다.
• FNwkSIntKey 를 NwkSKey 라고 합니다(사용자 쪽).
• Application Server는 NwkKey 또는 AppKey 를 받지 못합니다.

예, 좋은 시작입니다.

• Join Server가 먼저 오면 흐름이 더 좋을 것입니다.

나는 이것에 동의합니다. 활성화 모드가 OTAA이고 클러스터 JS가 활성화된 경우 JS 페이지에서 사용자는 루트 키를 입력하고 클러스터 JS에 저장할 수 있습니다. (해당 기능을 비활성화하면 클러스터에 JS가 활성화되지 않은 경우와 마찬가지로 NS가 JS 조회를 사용합니다.)

• "활성화 모드"는 페이로드에 있습니다. 다이어그램에서 실제로 multicast bool 및 supports_join bool 2개의 필드에 해당합니다. multicast && supports_join 가 유효하지 않기 때문에 3가지 가능한 옵션이 있습니다.
• frequency_plan -> frequency_plan_id

• resets_f_cnt 는 선택 사항이며 기본적으로 false 입니다.

• FNwkSIntKey 는 <1.1에 대해서만 NwkKey 로 표시되어야 합니다.

• FNwkSIntKey >= 1.1에 대한 ABP NS 설정에서 누락됨
• multicast 장치에는 AppSKey 만 필요 - NS는 multicast 장치가 작동하는 데 키가 필요하지 않으며 AS만 가능

@htdvisser

Join Server가 먼저 오면 흐름이 더 좋을 것입니다.

왜요?

아직 진행하지 않은 중요한 사항은 장치 저장소 #263에 있는 장치 템플릿의 필드를 미리 채우는 것입니다. 프로덕션 배포 프로세스를 정말 단순화할 수 있다고 생각합니다.

나를 위해 그것은이 문제의 범위를 벗어난 것 같습니다

DevEUI는 ABP 장치에 대해 금지되지 않습니다(선택적으로 설정할 수 있음).

ABP 장치에도 설정하시겠습니까? 필드가 적을수록 좋습니다. 그러나 필요한 경우 추가할 수 있습니다.

FNwkSIntKey는 NwkSKey라고 합니다(사용자 쪽).

따라서 레이블은 1.0.x 및 1.1.x 모두에 대해 NwkSKey 여야 합니까? 콘솔에 atm이 있는 것은 다음과 같습니다.

• LoRaWAN 1.0.x 장치에는 NwkKey가 없고 AppKey만 있습니다.
• 응용 프로그램 서버가 NwkKey 또는 AppKey를 가져오지 않습니다.

고정 👌

@johanstokking

활성화 모드가 OTAA이고 클러스터 JS가 활성화된 경우 JS 페이지에서 사용자는 루트 키를 입력하고 클러스터 JS에 저장할 수 있습니다. (해당 기능을 비활성화하면 클러스터에 JS가 활성화되지 않은 경우와 마찬가지로 NS가 JS 조회를 사용합니다.)

따라서 사용자가 서버에 가입 제출 단계를 건너뛸 수 있도록 허용하는 것뿐입니까? js에 대한 요청이 전혀 없습니까?

https://github.com/TheThingsNetwork/lorawan-stack/issues/1134 와 관련하여 이 필드가 다이어그램에서 어디에 속하는지 지정할 수도 있습니까?

@rvolosatovs

활성화 모드"는 페이로드에 있습니다. 다이어그램에서 실제로 2개의 필드(멀티캐스트 bool 및 support_join bool)에 해당합니다. 멀티캐스트 && support_join이 유효하지 않기 때문에 3가지 가능한 옵션이 있습니다.

다시 한번 확인하기 위해:

1. supports_join=true - 오타
2. supports_join=false - ABP
3. multicast=true && **no** supports_join - 멀티캐스트
   이 올바른지?

resets_f_cnt는 선택 사항이며 기본적으로 false입니다.

아직은 유저들에게 보여주기에는 괜찮다고 생각합니다. 사용자가 멀티캐스트 장치에 대해 설정하도록 허용해야 합니까?

FNwkSIntKey는 <1.1에 대해서만 NwkKey로 표시되어야 합니다.

NwkSKey 하시는 건가요?

frequency_plan -> frequency_plan_id
>= 1.1에 대한 ABP NS 설정에서 FNwkSIntKey가 누락되었습니다.

고정 👌

업데이트된 다이어그램:

@htdvisser

Join Server가 먼저 오면 흐름이 더 좋을 것입니다.

왜요?

네, 이것으로 다시 돌아오겠습니다. 키를 입력하기 전에 MAC 버전을 입력하는 것이 더 합리적이라고 생각합니다. 그래서 저는 현재의 흐름을 지지합니다. MAC 버전이 입력되면(NS가 활성화된 경우) 1.1.x이므로 NwkKey 를 요청할 필요가 없습니다.

아직 진행하지 않은 중요한 사항은 장치 저장소 #263에 있는 장치 템플릿의 필드를 미리 채우는 것입니다. 프로덕션 배포 프로세스를 정말 단순화할 수 있다고 생각합니다.

나를 위해 그것은이 문제의 범위를 벗어난 것 같습니다

그것은 실제로 범위 밖입니다.

DevEUI는 ABP 장치에 대해 금지되지 않습니다(선택적으로 설정할 수 있음).

ABP 장치에도 설정하시겠습니까? 필드가 적을수록 좋습니다. 그러나 필요한 경우 추가할 수 있습니다.

예, 선택적으로 요청하고 싶습니다. 최종 장치에 대한 식별 정보가 많을수록 좋습니다. 상태 저장 수동 로밍에도 필요합니다. 사용자가 DevEUI를 입력하도록 강제하지 않는 이유는 DevEUI가 없는 경우 사용자가 가짜 값을 입력하는 것을 원하지 않기 때문입니다.

FNwkSIntKey는 NwkSKey라고 합니다(사용자 쪽).

따라서 레이블은 1.0.x 및 1.1.x 모두에 대해 NwkSKey 여야 합니까? 콘솔에 atm이 있는 것은 다음과 같습니다.

1.0.x의 경우 NwkSKey $이고 1.1.x의 경우 FNwkSIntKey 입니다.

활성화 모드가 OTAA이고 클러스터 JS가 활성화된 경우 JS 페이지에서 사용자는 루트 키를 입력하고 클러스터 JS에 저장할 수 있습니다. (해당 기능을 비활성화하면 클러스터에 JS가 활성화되지 않은 경우와 마찬가지로 NS가 JS 조회를 사용합니다.)

따라서 사용자가 서버에 가입 제출 단계를 건너뛸 수 있도록 허용하는 것뿐입니까? js에 대한 요청이 전혀 없습니까?

물론.

예는 Semtech Join Server를 사용하는 Semtech의 모뎀을 갖춘 장치입니다. 이 경우 EUI만 알면 됩니다.

#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는 선택 사항이며 기본적으로 false입니다.

아직은 유저들에게 보여주기에는 괜찮다고 생각합니다. 사용자가 멀티캐스트 장치에 대해 설정하도록 허용해야 합니까?

아니요, 이것은 멀티캐스트용이 아닙니다. resets_f_cnt 는 업링크를 의미하지만 멀티캐스트에는 업링크가 없습니다.

FNwkSIntKey는 <1.1에 대해서만 NwkKey로 표시되어야 합니다.

NwkSKey 하시는 건가요?

실제로 NwkSKey 이어야 합니다.

@bafonins 는 @johanstokking 의 답변을 참조하십시오.
multicast 관련 - 장치 주소도 필요합니다.

• https://github.com/TheThingsNetwork/lorawan-stack/issues/1134 에서 필드를 추가했습니다.
• abp/multicast 장치에 DevEUI 추가됨
• 멀티캐스트 장치에 Device Address 추가됨
  

multicast 장치 네트워크 서버 설정에서 장치 주소가 여전히 누락됨

멀티캐스트 장치 네트워크 서버 설정에서 장치 주소가 여전히 누락됨

업데이트됨 👌

멀티캐스트는 1.0.x 및 1.1.x일 수 있습니다. 세션 정보( DevAddr 및 키)를 입력하는 것은 ABP와 멀티캐스트에서 동일합니다.

또한 resets_join_nonces 는 JS에서 1.1.x로 설정할 수 있습니다.

장치 생성을 분할하는 것은 확실히 필요하며 흐름과 구현을 백엔드 요구 사항에 더 가깝게 만드는 동시에 사용자의 복잡성을 줄이는 좋은 방법입니다.

내가 본 몇 가지 생각과 도전:

• 전체 흐름을 중단하는 기능을 추가하여 이미 생성된 모든 레지스트리 항목을 삭제해야 합니다.
  
  
  
  • 마찬가지로 이전 단계로 이동하려면 양식을 "업데이트 모드"로 설정해야 합니다(IS를 제외하고 끝점이 동일하므로 비교적 쉬워야 함).
  
  
• 내가 보는 한 가지 문제는 Application Server 단계가 매우 얕고(나중에 변경될 가능성이 있습니까?) 거기에 페이로드 형식 옵션을 추가하는 것 또한 장치를 생성하는 동안 사용자의 요구와 일치하지 않는다는 것입니다.
  
  
  
  • 솔루션은 둘 다 매우 간단하고 상호 의존적이지 않다는 점을 감안할 때 AS 및 JS 단계를 병합하는 것일 수 있습니다. 나는 이것이 구성 요소에 의한 분리에 반대된다는 것을 알고 있지만 이것이 합리적인 추상화로 전체 흐름을 단순화할 것이라고 생각합니다. 특히 단계 내에서 각 스택 구성 요소에 대한 연결을 통신하지 않는다는 점을 감안할 때.
  
  
• 스택 구성에 따라 마법사를 위한 안티 패턴인 하나 또는 두 개의 단계만 있는 마법사로 끝날 수 있습니다.
  
  
  
  • 단 한 단계의 경우 마법사 측면을 간단히 숨기거나 제거할 수 있습니다.
  
  
  • 2단계로 문제를 안고 살아야 한다고 생각합니다 🤷‍♂
  
  
• 마법사 솔루션이 사용자 스토리에 대한 _완료 시간_을 상당히 증가시킨다는 점을 고려해야 합니다.
  
  
  
  • 이것은 많은 장치를 손으로 만들어야 하는 상황에서 문제가 될 수 있지만 이 사용 사례에 대한 일괄 생성 기능을 소개하고 CLI/스크립팅도 이러한 상황에 도움이 될 수 있습니다.
  
  
  • 그래도 V2 콘솔 장치 생성과의 차이점과 사용자가 이 변경 사항을 인식하는 방식을 고려하십시오.
  
  
• 일반 설정에 해당하는 "분할 편집" 솔루션이 마음에 듭니다.
• 흐름도는 매우 유용하며 계속 업데이트해야 합니다 👍

일괄 생성/업데이트/삭제 및 생성 롤백 로직을 위한 js sdk의 불필요한 복잡성

장치 요청을 분할 및 병합하기 위한 SDK의 기능은 이 경우에 사용하지 않더라도 여전히 꽤 가치가 있다고 생각합니다.

멀티캐스트 장치용 @johanstokking NS는 MIC 계산을 위해 1.1의 SNwkSIntKey 만 필요합니다. FNwkSIntKey 및 NwkSEncKey , 실제로는 IMO를 설정할 수 없습니다.

• 전체 흐름을 중단하는 기능을 추가하여 이미 생성된 모든 레지스트리 항목을 삭제해야 합니다.
  
  
  
  • 마찬가지로 이전 단계로 이동하려면 양식을 "업데이트 모드"로 설정해야 합니다(IS를 제외하고 끝점이 동일하므로 비교적 쉬워야 함).
  
  

마침 을 누르기 전에 무언가를 만들어야 한다고 생각하지 않습니다. 마법사에서 앞뒤로 이동하고 브라우저 창을 닫아도 장치가 반쯤 생성되어서는 안 됩니다.

• 내가 보는 한 가지 문제는 Application Server 단계가 매우 얕고(나중에 변경될 가능성이 있습니까?) 거기에 페이로드 형식 옵션을 추가하는 것 또한 장치를 생성하는 동안 사용자의 요구와 일치하지 않는다는 것입니다.

여기에 응용 프로그램 패키지에 대한 구성을 추가합니다(예: 원격 멀티캐스트 설정, 조각화된 데이터 블록 전송, Semtech 모뎀 옵션 등). 그래서 예, 지금은 얕지만 확장될 것입니다.

• 솔루션은 둘 다 매우 간단하고 상호 의존적이지 않다는 점을 감안할 때 AS 및 JS 단계를 병합하는 것일 수 있습니다. 나는 이것이 구성 요소에 의한 분리에 반대된다는 것을 알고 있지만 이것이 합리적인 추상화로 전체 흐름을 단순화할 것이라고 생각합니다. 특히 단계 내에서 각 스택 구성 요소에 대한 연결을 통신하지 않는다는 점을 감안할 때.

우리의 미래를 위해 나는 그것들을 따로 보관하는 것이 좋습니다. 또한 이들을 결합하면 이미 복잡한 흐름에 복잡성을 추가하는 구성 요소 가용성에 따라 해당 페이지의 렌더링 항목이 만들어집니다.

• 스택 구성에 따라 마법사를 위한 안티 패턴인 하나 또는 두 개의 단계만 있는 마법사로 끝날 수 있습니다.

  • 단 한 단계의 경우 마법사 측면을 간단히 숨기거나 제거할 수 있습니다.
  • 2단계로 문제를 안고 살아야 한다고 생각합니다 🤷‍♂

• 마법사 솔루션이 사용자 스토리에 대한 _완료 시간_을 상당히 증가시킨다는 점을 고려해야 합니다.

  • 이것은 많은 장치를 손으로 만들어야 하는 상황에서 문제가 될 수 있지만 이 사용 사례에 대한 일괄 생성 기능을 소개하고 CLI/스크립팅도 이러한 상황에 도움이 될 수 있습니다.
  • 그래도 V2 콘솔 장치 생성과의 차이점과 사용자가 이 변경 사항을 인식하는 방식을 고려하십시오.

구성 요소의 분리와 유연한 배포 시나리오는 V2와 비교하여 주요 변경 사항 중 하나이므로 이것이 V3 콘솔에서 효과적이라는 것은 전적으로 의미가 있습니다.

실제로 많은 양의 장치를 만들려면 어쨌든 API와 CLI를 사용해야 합니다.

한 단계가 있는 시나리오는 없으며 항상 최소 두 단계입니다.

페이지 대신 탭을 렌더링하는 것은 어떻습니까? 그렇게 하면 여전히 한 페이지이지만 단계별로 앞뒤로 이동하지 않고도 쉽게 액세스할 수 있습니다.

@johanstokking

마침을 누르기 전에 무언가를 만들어야 한다고 생각하지 않습니다.

마지막 단계에서만 실제 요청을 하면 3-4 요청을 하게 됩니다. 다른 구성 요소에서 반환된 오류를 어떻게 처리합니까? 이를 처리하고 오류가 발생한 단계/재설정 저장소 등으로 사용자를 안내합니다. 복잡하다. 이것이 내가 모든 단계에서 값을 제출하는 것을 제안하는 이유입니다. 모든 연속적인 단계는 제출된 값이 유효한 것으로 의존할 수 있기 때문입니다.

마법사에서 앞뒤로 이동하고 브라우저 창을 닫아도 장치가 반쯤 생성되어서는 안 됩니다.

나는 사용자가 마법사에서 데이터를 편집하는 것을 허용하는 것에 반대합니다(제출로 이어지는 단계에 대해). Mb, 단일 구성 요소에 저장된 선택적 필드만(다른 구성 요소에는 필요하지 않음) name , description . 그렇지 않으면 이것을 처리하는 것이 상당히 복잡해집니다.

@kschiffer

스택 구성에 따라 마법사를 위한 안티 패턴인 하나 또는 두 개의 단계만 있는 마법사로 끝날 수 있습니다.

글쎄, 우리는 대체 솔루션에 열려 있습니다. 어떤 제안?

마지막 단계에서만 실제 요청을 하면 3-4 요청을 하게 됩니다. 다른 구성 요소에서 반환된 오류를 어떻게 처리합니까? 이를 처리하고 오류가 발생한 단계/재설정 저장소 등으로 사용자를 안내합니다. 복잡하다. 이것이 내가 모든 단계에서 값을 제출하는 것을 제안하는 이유입니다. 모든 연속적인 단계는 제출된 값이 유효한 것으로 의존할 수 있기 때문입니다.

좋아요. 콘솔이 ER에 있지만 해당 단계가 실패했거나 사용자가 탭 등을 닫았기 때문에 JS/NS/AS에서 찾을 수 없는 장치를 처리할 수 있는 한 괜찮습니다.

나는 사용자가 마법사에서 데이터를 편집하는 것을 허용하는 것에 반대합니다(제출로 이어지는 단계에 대해). Mb, 단일 구성 요소에 저장된 선택적 필드만(다른 구성 요소에는 필요하지 않음) name , description . 그렇지 않으면 이것을 처리하는 것이 상당히 복잡해집니다.

무슨 뜻이에요?

예를 들어 AS는 필드가 필요하지 않으며 장치가 존재하기만 하면 됩니다. 따라서 AS가 있는 경우 사용자가 AS에 대한 값을 입력하지 않더라도 AS에 (빈) 장치를 생성해야 합니다.

무슨 뜻이에요?

죄송합니다. 이것은 @kschiffer 제안에 대한 것이었습니다.

마찬가지로 이전 단계로 이동하려면 양식을 "업데이트 모드"로 설정해야 합니다(IS를 제외하고 끝점이 동일하므로 비교적 쉬워야 함).

마법사에서 앞뒤로 이동하고 브라우저 창을 닫아도 장치가 반쯤 생성되어서는 안 됩니다.

나는 이것을 미래의 개선이라고 생각합니다. 지금은 완료되지 않은 흐름에 대해 사용자에게 알림을 표시할 수 있습니다. 나중에 사용자는 일반 설정 페이지에서 장치를 편집/삭제할 수 있습니다.

글쎄, 우리는 대체 솔루션에 열려 있습니다. 어떤 제안?

글쎄, 나는 이 특정한 상황의 _edge-casiness_를 감안할 때 이 문제를 가지고 사는 것이 괜찮다고 생각합니다. 귀하의 표현은 제안된 솔루션 없이 우려 사항을 말해서는 안 된다고 제안하지만, 즉시 찾을 수 없는 경우 다른 사람들에게 몇 가지를 제안할 기회를 주고 싶습니다.

나는 사용자가 마법사에서 데이터를 편집하는 것을 허용하는 것에 반대합니다(제출로 이어지는 단계에 대해). Mb, 단일 구성 요소에 저장된 선택적 필드만(다른 구성 요소에는 필요하지 않음) name , description . 그렇지 않으면 이것을 처리하는 것이 상당히 복잡해집니다.

이것은 마법사 패턴에 대한 모범 사례를 다시 위반합니다. 사용자는 특히 상호 의존적인 경우 이전 필드를 수정하거나 단순히 검사하기를 원할 것입니다. 처음에는 이 기능을 포함하지 않아도 되지만 결국에는 추가되어야 합니다(예: 문제에서 추적).

그렇지 않으면 이것을 처리하는 것이 상당히 복잡해집니다.

일반적으로 복잡한 프론트엔드 로직을 구현해야 하는 필요성이 UX에 대한 우리의 약속에 영향을 미쳐서는 안 됩니다.

나는 이것을 미래의 개선이라고 생각합니다. 지금은 완료되지 않은 흐름에 대해 사용자에게 알림을 표시할 수 있습니다. 나중에 사용자는 일반 설정 페이지에서 장치를 편집/삭제할 수 있습니다.

우리가 궁극적으로 이것을 향상시킬 것이기 때문에 최적은 아니지만 나에게는 수용 가능합니다.

오프라인에서 논의한 대로 초기 제안은 다음과 같습니다.

디바이스 생성

1. 일반 설정
   
   
   
   • 필드
     
     
     
     
     
     • ids
     
     
     
     • 옵션 name
     
     
     
     • 옵션 description
     
     
     
     • 옵션 attributes
     
     
     
     • 필수 활성화 모드: OTAA, ABP 또는 멀티캐스트
     
     
     
     • 클러스터의 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 또는 멀티캐스트인 경우 필드
     
     
     
     • 클러스터의 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에서는 (아직) 설정되지 않은 청구된 장치입니다.
• 이전에 구축: ER 및 JS에만 있는 장치의 LoRaWAN 및 애플리케이션 설정을 설정합니다(즉, NS 및 AS에 설정).
• lorawan_version 및 lorawan_phy_version 변경(제약 조건 변경)
• "외부 JS" 옵션 변경 즉, 기존 장치가 있지만 cluster-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만 보나요 아니면 ER의 NS/AS/JS 주소도 보나요?
• 예를 들어 "external JS"를 true 로 변경할 때 또는 NS에서 장치 상태를 재설정할 때 개별 NS/AS/JS 등록을 삭제할 수 있으면 좋을 것 같습니다.

일반 물건:

• _"외부 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 는 멀티캐스트에 적용할 수 없습니다.

@rvolosatovs

#579(댓글) 에는 NS에 필요한 모든 것이 이미 포함되어 있다고 생각합니다.

모든 mac_settings 는 멀티캐스트가 아닌 모든 장치에 대해 설정할 수 있어야 한다고 생각합니다.
멀티캐스트 장치의 경우 다음 사항만 의미가 있습니다.

이 문제의 문제점 중 하나는 댓글에 묻힌 정보의 양입니다.

올바른 위치에 필드를 _정확히_ 추가할 수 있습니까? 제 전체 글머리 기호 목록을 복사해도 괜찮으므로 최종 버전이 나올 때까지 점진적으로 작업합니다.

@htdvisser

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만 보나요 아니면 ER의 NS/AS/JS 주소도 보나요?

주소 세트가 있는 경우에만 404를 얻을 수 있습니다. 그렇지 않으면 얻을 수 없습니다. 둘 다 "해당 레지스트리에 없음"으로 해석해야 합니다. IS 및 AS/NS/JS에서 생성이 동시에 발생하지 않고 사용자가 콘솔에서 생성된 불일치를 복구할 수 있어야 하기 때문에 여기에서 오류를 범할 수 없습니다.

• 예를 들어 "external JS"를 true 로 변경할 때 또는 NS에서 장치 상태를 재설정할 때 개별 NS/AS/JS 등록을 삭제할 수 있으면 좋을 것 같습니다.

그래 나중에 하자

• _"외부 JS는 JS가 NS와 동일한 클러스터에 있지 않은 곳입니다."_: "join_server_address가 콘솔 구성의 JS 주소와 동일하지 않습니다"와 같아야 한다고 생각합니다.

네, 실제로 확인하는 방법입니다. join_server_address 도 interop을 사용하여 비어 있을 수 있습니다.

@bafonins 아직 그래프 소스가 있나요?
이미 그것을 구성하는 데 많은 작업이 들어갔기 때문에 명확한 표현을 위해 완성되도록 업데이트해야 한다고 생각합니다.
여기에서 토론을 복잡하게 하지 않도록 NS 부분을 오프라인으로 업데이트하는 작업도 할 수 있습니다.

가능한 모든 NS 필드로 그래프를 업데이트했습니다.
빨간색으로 표시된 필드는 필수 항목입니다.

@rvolosatovs 는 장치를 만들고 업데이트할 때 콘솔에 표시할 흐름과 필드를 정의하는 것을 목표로 합니다.

이와 같이,

• mac_state.lorawan_version 변경을 허용해서는 안 됩니다.
• 지금은 CLI를 통해 mac_state.ping_slot_periodicity 를 할 수 있습니다.
• 사용자가 supports_class_b , supports_class_c 및 mac_state.device_class 를 설정하는 방법을 생각해 보십시오. 생성의 일부이고 업데이트의 일부이며 서로 어떤 관련이 있습니까?
• 개별 카운터를 변경해서는 안 됩니다. "reset frame counters" 버튼은 할 수 있습니다(afaik은 별도의 작업이 될 수 있습니다. V2 콘솔에서와 같이 카운터를 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 상태입니다.
귀하의 의견을 업데이트하겠습니다.

개별 카운터를 변경해서는 안 됩니다. "reset frame counters" 버튼은 할 수 있습니다(afaik은 V2 콘솔에서와 같이 카운터를 0으로 설정하는 별도의 작업일 수 있음)

ABP 및 멀티캐스트에 대한 다운링크 프레임 카운터를 설정할 수 있어야 합니다. 그렇지 않으면 NS가 다운링크를 보낼 수 없습니다.
업링크의 경우 프레임 카운터는 ABP의 보안 관점에서도 매우 유용합니다.

기기 업데이트

여기서는 기본적으로 마법사 단계를 탭으로 사용하는 탭 방식을 사용합니다.

@bafonins 의 첫 번째 의견에 나와 있는 것처럼 여기에서 아코디언 접근 방식을 사용하겠습니다.

수평 공간 문제가 줄어들고 Edit / Create 버튼으로 모드를 구분할 수 있습니다.

@rvolosatovs

ABP 및 멀티캐스트에 대한 다운링크 프레임 카운터를 설정할 수 있어야 합니다. 그렇지 않으면 NS가 다운링크를 보낼 수 없습니다.
업링크의 경우 프레임 카운터는 ABP의 보안 관점에서도 매우 유용합니다.

이것이 간단하다면 우리는 할 수 있습니다. 사실, 2/3개의 입력 상자는 특정 작업을 트리거하는 재설정 버튼보다 간단할 수 있습니다.

콘솔에 있어야 하는 것과 관련하여 모든 mac_state 은 아마도 CLI를 통해서만 설정 가능해야 하지만 기존 세션에 등록 중인 ABP/멀티캐스트 장치 및/또는 OTAA 장치에 대해 요구할 수 있습니다. 따라서 MAC 상태입니다.

이해 했어요. "이미 네트워크에 연결된 기존 ABP 장치"에서 "새 ABP 장치 및 재설정 ABP 장치"를 분리해야 한다고 생각합니다.

전자는 완전해야 하므로 mac_state.desired_parameters 가 아닌 일부 mac_state (즉, 공장 초기화 주파수, RX1 지연, RX2 설정 등)를 포함해야 합니다.

후자는 마이그레이션을 통해 수행해야 하며 나중에 콘솔에서 미세 조정 설정을 추가할 수 있습니다. 지금은 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에만 해당되지 않습니까?

@johanstokking

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 설정은 설계상 선택 사항입니다.
이것이 "필수"인 유일한 경우는 클래스 B 멀티캐스트 장치이며, 이는 클래스 B 작동 특성으로 인한 것입니다.
그 외에도 최상의 결과를 얻으려면 ABP에 factory_preset_frequencies 가 필요할 수 있지만 OTAA 장치가 해당 설정을 갖는 것을 방해하는 것은 없습니다.

모든 MAC 설정은 설계상 선택 사항입니다.
이것이 "필수"인 유일한 경우는 클래스 B 멀티캐스트 장치이며, 이는 클래스 B 작동 특성으로 인한 것입니다.

좋아요

그 외에도 최상의 결과를 얻으려면 ABP에 factory_preset_frequencies 가 필요할 수 있지만 OTAA 장치가 해당 설정을 갖는 것을 방해하는 것은 없습니다.

OTAA에는 효과가 없습니다. 기본 조인 주파수는 사양에 따라 필요하며 채널은 join-accept 및 MAC 명령을 통해 들어옵니다. OTAA 장치에 대한 사전 설정 주파수의 대역 외 구성이 있어서는 안 됩니다.

@bafonins 이 문제에 대한 상태 업데이트 및 타임라인을 제공할 수 있습니까?

app_s_key 및 skip_payload_crypto 의 경우 다음과 같습니다.

• AS는 최종 장치의 skip_payload_crypto 필드를 따릅니다. true 이면 AS는 페이로드 암호화 및 복호화를 수행하지 않습니다.
  
  
  
  • AS는 애플리케이션 수준에서도 skip_payload_crypto 를 받게 되며(페이로드 포맷터와 같은 링크를 통해) 최종 장치의 설정보다 우선 적용됩니다.
  
  
• AS에는 항상 app_s_key 가 있지만 래핑될 수 있습니다. 즉, session.keys.app_s_key.key 가 설정되지 않았습니다(그러나 encrypted_key 및 kek_label 가 설정됨).
  
  
  
  • AS에 KEK가 없는 경우, 즉 암호화된 키를 풀 수 없습니다. 자, 그 오류. 우리는 아마도 암호화된 app_s_key 를 클라이언트에게 있는 그대로 반환할 것입니다.
  
  
• 콘솔에서 skip_payload_crypto 가 true 로 설정되어 있으면(최종 장치 또는 애플리케이션 링크에서) app_s_key 를 사용하지 마십시오.