Riot: IEEE802.15.4: 유해한 것으로 간주되는 HW 자동 ACK

대부분의 경우 이 관행은 해로울 수 있습니다.

현실적으로 말해서, 이것이 얼마나 자주 실제 피해를 야기합니까? MCU에서 실제로 삭제하는 동안 몇 퍼센트의 메시지가 확인됩니까?

수신 시 라디오가 TX 모드로 전환됨(#11256)

이 경우는 공유 수신/전송 버퍼 권한이 있는 라디오에만 해당됩니다. 따라서 at86rf2xx 클래스의 장치에만 영향을 미칩니다.

이것은 이상한 행동을 일으킬 수 있습니다 ...

이것이 문제를 일으키는 몇 가지 예가 있습니까?

따라서 Auto ACK를 선택 사항으로 남겨두고 소프트웨어에서 ACK 응답을 구현할 것을 제안합니다.

이에 대한 영향에 대한 수치가 있습니까? 플래시 크기/RAM 사용량뿐만 아니라 MCU가 더 오래 깨어나야 하므로 전력 사용량도 있습니다. 또한 프레임 수신과 ACK 타임아웃 사이에 시간이 얼마나 걸리고 라디오가 SPI를 통해 연결된 경우 소프트웨어에서 ACK를 처리하는 것이 현실적입니까?

더 안정적인 L2를 갖는 것 외에도

저는 이 주장에 대해 약간 회의적입니다(내 의견에서 아직 명확하지 않은 경우). L2 ack를 처리하는 것은 부드러운 실시간 사례이며(기한을 놓치면 서비스가 저하됨) 소프트웨어에서 처리하는 것은 RIOT의 실시간 행동.

일부 특정 MAC 계층에 대한 엄격한 요구 사항인 경우 소프트웨어 L2 ack에 신경 쓰지 않지만 여기 설명에서는 언급되지 않았습니다.

안녕하세요 @bergzand

현실적으로 말해서 이것이 얼마나 자주 실제 피해를 야기합니까? MCU에서 실제로 삭제하는 동안 몇 퍼센트의 메시지가 확인됩니까?

상위 계층의 경우 큰 문제가 아닙니다(일반적으로 최선의 노력이라고 생각하면).
그러나 일부 MAC 및 하위 MAC 계층(OpenThread, TSCH)에서는 ACK를 사용하여 이웃 정보를 업데이트합니다.

이 경우는 공유 수신/전송 버퍼 권한이 있는 라디오에만 해당됩니다. 따라서 at86rf2xx 클래스의 장치에만 영향을 미칩니다.

진실. 나는 이것이 일어날 수 있는 시나리오를 지적하고 있을 뿐입니다.

이것이 문제를 일으키는 몇 가지 예가 있습니까?

MAC 계층의 사용자에게 잘못된 정보를 제공하면(예: 메시 링크 설정) 링크 품질에 영향을 미칠 수 있습니다. RIOT에는 아직 그런 것이 없지만(이를 사용하는 스택은 이미 기능을 구현하고 있음을) 알고 있습니다.

이에 대한 영향에 대한 수치가 있습니까? 플래시 크기/RAM 사용량뿐 아니라 MCU가 더 오래 깨어나야 하므로 전력 사용량도 있습니다. 또한 프레임 수신과 ACK 타임아웃 사이에 시간이 얼마나 걸리며 SPI를 통해 라디오가 연결된 경우 소프트웨어에서 ACK를 처리하는 것이 현실적입니까?

불행히도. 구현되지 않았기 때문에 비교할 숫자가 없습니다. 자동 ACK가 있는 일부 테스트 분기만 있지만 더 자세히 테스트하지는 않았습니다.

저는 이 주장에 대해 약간 회의적입니다(내 의견에서 아직 명확하지 않은 경우). L2 ack을 처리하는 것은 부드러운 실시간 사례이며(기한을 놓치면 서비스가 저하됨) 소프트웨어에서 처리하는 것은 RIOT의 실시간 행동.

소프트웨어 ACK가 더 높은 하락을 보이는 경향이 있다는 Tiny OS의 정보가 있습니다(https://vs-git.informatik.uni-kl.de/engel/tinyos/blob/020c6a6d8cc542bf58ca6afb8b1bf24efbe381de/doc/txt/tep126.txt). 거짓 긍정이 없습니다.
AFAIK IEEE802.15.4는 하드 제약 조건에 대해 이야기하지 않습니다(시간 초과 값에 대해서만). ACK 패킷이 제 시간에 전달되지 않으면 손실된 것으로 간주됩니다. 그러나 이전에 말했듯이 OS가 소프트웨어 ACK로 얼마나 잘 작동하는지에 대한 정보가 없습니다. 몇 가지 벤치 마크가 있으면 흥미로울 것입니다.

일부 특정 MAC 계층에 대한 엄격한 요구 사항인 경우 소프트웨어 L2 ack에 신경 쓰지 않지만 여기 설명에서는 언급되지 않았습니다.

자동 ACK를 지원하지 않는 라디오와 하드웨어 가속기에서 사용할 수 없는 기능에 대해 소프트웨어 ACK를 구현해야 합니다(솔직히 Enhanced ACK를 지원하는 라디오는 알지 못합니다).
문제는 이것이 기본 구성에 대해 선택 사항입니까 아니면 필수 항목입니까? 앞서 설명했듯이 아이디어는 Auto ACK 지원을 제거하는 것이 아니라 L2를 더 잘 지원하는 것입니다. 원하는 경우 자동 ACK를 활성화할 수 있습니다(이것이 내가 https://github.com/RIOT-OS/RIOT/pull/11473에 라디오 캡을 추가할 것을 제안한 이유입니다).

어쩌면 내가 실수했지만 해결책은 간단해 보입니다.

• 우리는 (하드웨어 독립적인) ARQ를 구현합니다 -> 우리는 이 논의와 상관없이 그것을 원합니다.
• 하드웨어와 소프트웨어 구현의 성능(및 상호 운용성)을 비교합니다.
• 우리는 다른 플랫폼의 컴파일을 방해하지 않는 플랫폼별 기본 설정을 원합니다.

사이드 노드: @jia200x 가 강조한 문제에 직면한 적이 없다는 사실은 RIOT의 라디오 상단에 MAC 계층이 누락된 것과 관련이 있을 수 있습니다. 또한, 저전력 손실 라디오를 사용하면 어쨌든 특정 손실을 견딜 수 있습니다.

6TiSCH에 대한 소프트웨어 ACK는 얼마나 중요합니까? IIRC, OpenWSN은 소프트웨어 ACK를 부분적으로 사용하여 이웃 간의 링크 품질을 추적합니다.

6TiSCH에 대한 소프트웨어 ACK는 얼마나 중요합니까? IIRC, OpenWSN은 소프트웨어 ACK를 부분적으로 사용하여 이웃 간의 링크 품질을 추적합니다.

6TiSCH는 하드웨어 ACK에 대해 말하지 않지만 타이밍 정보를 전달하려면 향상된 ACK가 필요합니다. OpenWSN에서 이것은 pkg 자체에서 처리됩니다.

*그리고 내가 아는 하드웨어에서는 Enhanced ACK를 지원하지 않습니다.

또한 하드웨어 승인 기능의 문제는 경우에 따라 수신된 ACK 또는 재시도 횟수와 같은 관련 정보를 반드시 노출하지 않고도 메커니즘의 모든 책임을 진다는 것입니다. 6TiSCH를 사용하면 이러한 종류의 정보가 필요한 다른 셀의 프레임을 재전송할 수 있습니다. 따라서 OpenWSN은 제한된 무선 장치 기능 세트를 기반으로 하고 소프트웨어에서 다른 모든 MAC 구성 요소를 구현합니다.

이 문제는 최근 활동이 없었기 때문에 자동으로 오래된 것으로 표시되었습니다. 더 이상 활동이 없으면 폐쇄됩니다. 이 문제를 무시하도록 하려면 "상태: 부실하지 않음" 레이블로 표시하십시오. 귀하의 기여에 감사드립니다.