스레드 대. ZigBee(IoT 엔지니어용)

Thread와 ZigBee는 매우 유사합니다.

그러나 두 네트워크를 비교할 때 고려해야 할 몇 가지 차이점과 고려 사항이 있습니다. 아래에 정리했습니다.

쓰레드 대. ZigBee:주요 차이점 및 고려 사항

네트워크 레이어

Thread는 Nest(Google), Samsung 및 보다 전통적인 방식으로 노드를 처리하고자 하는 여러 실리콘 공급업체에 의해 시작되었습니다. 각 노드에 IP 주소를 제공하는 6LoWPAN을 사용합니다. 클라우드가 말하는 주소는 에지 라우터로 이동한 다음 해당 IP 주소를 통해 노드로 바로 보낼 수 있습니다.

ZigBee도 ZigBee IP로 이를 시도했지만 큰 시장 견인력을 얻지 못했습니다. ZigBee 노드를 처리하는 또 다른 방법은 클라우드 및 네트워크에 연결하는 에지 라우터를 사용하는 것입니다. 주소가 입력되면 에지 라우터는 연결된 노드와 특정 메시지를 번역하는 방법을 알기 위해 일종의 인텔리전스를 가져야 합니다. 클라우드 애플리케이션을 설계하는 경우 비 IP ZigBee 네트워크로 인해 노드와의 통신을 처리하기가 더 어려울 수 있습니다.

애플리케이션 레이어

ZigBee는 애플리케이션이 인터페이스에 인터페이스하고 그 내에서 작동하는 방법을 지시하는 애플리케이션 계층을 만들었습니다. 조명을 작동하는 ZigBee Light Link와 같은 다른 ZigBee 응용 프로그램에 연결할 응용 프로그램을 생성하는 경우 이것은 명백한 선택입니다. 그러나 이 애플리케이션 계층에는 결함이 없는 것이 아니며 종종 크고 성가신 것으로 간주됩니다.

스레드는 응용 프로그램 계층을 정의하지 않으므로 네트워크의 장치가 상호 작용하는 방법을 정의하지 않습니다. 장치 및 엔드 노드와 통신하는 일반적인 방법을 제공하므로 앞뒤로 통신할 수 있지만 메시지는 ZigBee에서와 같이 정의되지 않습니다. 여러 응용 프로그램과 통신할 수 있는 일반적인 기능이 필요한 경우 스레드를 사용할 수 있습니다.

인증 절차

무언가를 ZigBee 호환 가능으로 인증하려면 ZigBee Alliance를 거쳐야 하고, Thread 호환 가능하다고 인증하려면 Thread Group을 거쳐야 합니다. 둘 다 관련 수수료가 있으며 어느 프로세스가 더 쉽고 더 관련이 있는지 말할 수 없습니다. 하지만 애플리케이션을 위한 네트워크를 선택하기 전에 인증 프로세스의 모든 부분을 고려해야 합니다.

소프트웨어 스택

쓰레드는 깨끗하고 부풀려지지 않은 소프트웨어 스택으로 찬사를 받았습니다(아래 그림 참조).

ZigBee용 소프트웨어 스택은 더 크고 복잡하므로 대기 시간 문제가 있는 것으로 알려져 있으며 잠재적으로 더 많은 전력을 소비할 수 있습니다. 이는 또한 더 많은 메모리를 사용하므로 더 큰 마이크로컨트롤러가 필요할 수 있음을 의미합니다(따라서 비용 증가).

결론

결국 사용하게 되는 네트워크는 필요한 용도로 요약될 것입니다. ZigBee는 스마트 조명 및 에너지 분야에서 매우 잘 해냈지만 다른 분야에서는 어려움을 겪었습니다. Thread는 더 젊은 네트워크이지만 Google과 삼성의 지원을 받으면 큰 추진력을 얻을 수 있습니다. Thread 또는 ZigBee에 대해 더 궁금한 사항이 있으면 기꺼이 답변해 드리겠습니다. @LinkLabsInc를 트윗하거나 한 줄 남겨주세요.