[정보💡] Matter over Thread의 문제점 2편: 스레드와 매터의 부조화

[스싱마스터(stmaster)]

매터 오버 스레드의 문제점2:

스레드 스택과 매터의 long idle time 사이에서 벌어지는 폴링 타임아웃 제한의 부조화와 물리적인 충돌

IoT 제품이라면 기기가 아무 일도 하지 않을 때의 대기 전력을 최대한 줄여야함. 그러기 위해 IoT제품은 비동기 통신이라는 방식을 채택하고 있음.

비동기 통신은 데이터가 필요할 때만 잠시 깨어나 데이터를 보내고 다시 잠드는 방식의 통신으로, 데이터를 푸시하고 바로 슬립 모드로 들어가기 때문에 mcu와 통신 모듈을 깨워둘 필요가 없고, 서로의 상태를 업데이트하지 않아도 통신이 됨. 그 이유는 IoT기기에서 만들어진 이벤트를 허브의 큐나 브로커에 던져놓으면 그 이후는 허브가 알아서 처리하기 때문임.

허브 안의 추상화계층이 네트워크에서 복잡한부분을 따로 처리하기 때문에, IoT제품과 허브 사이의 네트워크 세션은 단순해지고 느슨한 커플링을 구현할 수 있음.

IoT 제품은 대부분의 시간에 슬립에 빠져있음. 이것은 배터리 수명이 몇 달에서 몇 년으로 늘리는 핵심임. 그래서 딥슬립 상태를 얼마나 오래, 그리고 깊게 유지하는가에 배터리 수명이 달려있음. 그리고 매터 제품은 딥슬립에 빠질 수 없음.

매터는 그동안 딥슬립을 지원하지 않고 15초마다 강제폴링을 해왔던 흑역사가 있고 개인적으로 매터가 IoT에 부적합하다고 여긴 부분이었음. 그러다가 1.4 판올림에서 그동안의 불만을 들어서 그런지 몰라도, 기존의 15초 안에 강제폴링을 short idle time으로, 그 이상의 폴링을 long idle time으로 icd 클러스터를 2가지로 분리했음. long idle time은 단방향 리포팅에 초점을 맞춰서 허브로부터 실시간 컨트롤을 불가능하게 만들어 응답성을 거세시키고 센서가 허브로 일방적으로 리포팅을 쏴주는것에 특화된 icd임.

여기서 long idle time은 IoT 기기의 인터벌 시간을 정의하는 IdleModeInterval에서 최대 18시간까지의 폴링 주기를 허용하는 노력을 했음.

그러나 이건 어디까지나 매터 오버 스레드에서 정의할수있는 최대 데이터일뿐이지, 실제로 이렇게 활용하기 어려워서 이론상으로 정의할 수 있는 데이터에 불과함.

그 이유는 matter over thread의 데이터링크 계층인 스레드스택에서 이를 뒷받침하지 못하는 기술적인 한계가 있기 때문임.

스레드 보더라우터는 기본 설정으로 240초의 타임아웃 값을 가짐. 그래서 스레드 기기가 240초 이상 보더 라우터와 통신하지 않으면 연결이 끊긴 것으로 간주하고 허브에서 탈락됨. 그래서 슬립이 5분을 넘기고 깨어난 matter over thread기기는 허브가 만든 네트워크에 조인을 거부당하게 됨

이 문제는 매터가 등장하기 전부터 유명했던 스레드 프로토콜의 문제였음. 슬립모드에 빠진 스레드 디바이스는 그동안 허브에 리조인을 거부당해서 네트워크에서 탈락해왔던 유구한 역사가 있었음.

스레드가 이렇게 정의되어있는 것은 스레드의 간접 트랜젝션을 구현하는 mac계층에서 ieee 802.15.4 표준을 그대로 따르기 때문임.

매터 오버 스레드에서 이를 무시하고 18시간같은 시간을 설정하면, 스레드스택에서는 해당 장치가 네트워크를 오프라인이 된 것으로 간주하여 ip주소를 캐시에서 지워버림.

문제는 매터가 ipv6을 기반으로 만들어져 ip주소를 등록하고 갱신해야함. 이때 ip주소를 잃어버리면 패킷 손실이 발생함.

스레드에서 정의하는 타임아웃 설정이 매터의 long idle time을 커버할 수 없는 이 상황에서, 매터 오버 스레드는 스레드 스택에 정의된 타임아웃을 컨트롤할 능력이 없음. 그 이유는 매터 오버 스레드가 애플리케이션 레이어의 클러스터를 정의할 능력은 되지만, 데이터링크까지 모두 정의하는 것은 아니기 때문임

따라서 매터 오버 스레드에는 long idle time에서 정의한대로 딥슬립을 실행할 수 없는 물리적인 한계가 존재함. long idle time의 존재는 매터 오버 스레드의 슬립 스테이트를 유연하게 적용할 수 있게 만들었지만, 그것은 현실적으로 제한 범위 안에 있음

결국 매터 1.4가 제시한 18시간의 long idle time은 희망사항일 뿐임. 그것은 하부 레이어인 스레드의 물리적 제약을 넘어서지 못하기 때문에 폴링 주기를 억지로 짧게 유지해야 하는 모순적인 딜레마에 빠지는 것임.

한편 zigbee는 네트워크 레이어부터 애플리케이션 레이어까지 전부 정의된 풀스택 프로토콜인 만큼 이러한 문제로부터 자유로움

nxp의 Zigbee 3.0 Stack User Guide를 살펴보면

지그비가 정의하는 eZedTimeout 파라미터에서 정의할 수 있는 시간은 10초부터 16384분까지 설정할 수 있음. 16384분을 시간으로 계산해보면 11일 9시간 44분임. 물론 스마트홈에서 리포팅을 최대로 설정할 멍청이는 없겠지만, 지그비에서는 리포팅을 유동적으로 설정이 가능하고 딥슬립이 안정적으로 구현됨.

이 것은 지그비가 네트워크 레이어부터 애플리케이션 레이어까지의 전 계층을 한꺼번에 정의할 수 있기 때문임. 그래서 클러스터에서 정의한 딥슬립 정책이 커널에서까지 동일한 설계 철학 아래 통합되어 있음.

매터는 그렇지 못함. 매터는 6lowpan/coap를 기반으로 하는 ipv6환경의 클러스터를 구현하는 스레드의 수많은 애플리케이션 표준 중에 하나에 불과하며, 스레드의 timeout이나 mac 동작 방식을 재정의할 수 없음. 매터가 long idle time의 도입으로 저전력 설계를 위한 개선을 시도했지만 이건 하부 레이어의 물리적 제약을 넘어서는 해법은 아님.

따라서 long idle time을 극단적으로 길게 설정하더라도 하부 레이어인 스레드가 이를 허용하지 않기 때문에 결과적으로 깊은 딥슬립을 전제로 한 long idle time의 초저전력 설계와 리얼타임으로 리포팅되는 스레드 네트워크의 설계가 하나의 IoT기기 안에서 충돌하는 모순적인 상황이 벌어지고 있음

이렇게 매터의 문제점인 스레드 스택과 매터의 long idle time 사이에서 벌어지는 폴링 타임아웃 제한의 부조화와 물리적인 충돌에 대해 알아봤음

다음 매터의 문제점은 심한 전력낭비로 인한 에너지 소모와 줄어드는 배터리 라이프임.

그것은 다음 글에서 자세히 설명하겠음

[스싱붕이 1(211.107)]

스레드 Time out랑 매터 LIT이 따로노는건 ㄹㅇ 병신같네

[익명(page7888)]

[스싱붕이 3(211.177)]

쓰레드를 버리지 않으면 매터의 미래가 없다

[스싱붕이 5(125.130)]

처음부터 끝까지 같은회사에서 만드는건줄알았네ㅋㅋ 아니었구나

[스싱붕이 6(223.56)]

스마트홈 센서류 알아보는 사람들은 분명히 프로토콜에 대한 정보도 찾아볼텐데 하부에서부터 엇박자 나는 매터는 너무 암템내가 난다. 배터리도 더 적게가고 일반적으로 더 비싼거 생각하면 물음표가 띄워지는듯.