IoT에서의 다중프로토콜 다중대역 커넥티비티

  • 2017년 06월호
  • 톰 패넬(Tom Pannell), IoT 제품 마케팅 시니어 디렉터, 실리콘랩스




우리는 자연스럽게 생활의 모든 측면에서 각종 기기나 시스템을 제어할 수 있기를 기대한다. 

집안이나 사무실 안으로 들어갈 때는 스위치를 사용해서 전등을 제어할 수 있기를 바란다. 집을 나설 때는 보안 경보를 켜고 문을 잠근다. 이러한 많은 시스템이 이미 설치되어 있고 인프라의 한 부분을 이루고 있다.

그런데 이제 IoT의 등장으로 우리의 기대는 한 차원 높아지고 있다. 이제 우리는 집안의 온도를 스마트폰을 통해서 원격적으로 모니터링하고 조절할 수 있기를 바란다. 사무실 빌딩이 사람이 없을 때는 알아서 조명을 끔으로써 효율적으로 에너지를 절약할 수 있기를 바란다. 또 사무실에 사람이 있을 때는 사무실이 스스로 알아서 주변을 쾌적하고 안전하게 만들어주기를 기대한다.

갈수록 더 연결된 세상을 실현하도록 하기 위해서 눈에 띄지 않는 곳에까지 무수히 많은 IoT 디바이스와 시스템들이 구축되고 있다. 집안, 사무실, 공장, 도심 인프라를 비롯한 모든 곳에 무선 보안 시스템, 출입 카드, 점유 센서, 원격 온도 센서 같은 많은 커넥티드 디바이스들이 설치되고 있다.

IoT를 이루는 복잡한 유선 및 무선 센서 네트워크는 수십 년 전부터 개발되고 구축되어 왔다. 이러한 센서 네트워크를 교체하기 위해서는 많은 비용이 들어간다. 그런데 이제 다중프로토콜 기술이 등장함으로써 새로운 무선 센서 노드를 훨씬 더 수월하게 구축할 수 있게 되었다.

이 기술은 단일의 시스템온칩(SoC) 디바이스로 저전력 블루투스(BLE), 지그비(ZigBee), 쓰레드(Thread) 같은 다중의 무선 프로토콜을 지원할 수 있는 것을 말한다. 이 기술은 서브 기가헤르츠(Sub-Gigahertz) 대역에서부터 2.4 GHz까지 다중의 주파수 대역을 지원할 수 있다.

그런데 IoT 인프라는 레거시 시스템을 기반으로 하고 있으므로, 기존에 구축되어 있는 인프라로 새로운 802.15.4 무선 기술을 추가하기가 까다롭다는 점을 고려해야 한다. 게다가 레거시 시스템을 지원하는 것만이 문제가 아니다. 많은 경우에 비슷한 커넥티비티 요구를 처리하기 위해서 복수의 경쟁적인 프로토콜 표준들이 사용됨으로 인한 복잡성 또한 고려해야 한다.

IoT 노드 

거대한 거미줄처럼 연결되어 있는 센서 네트워크에 대해서 이해해야 할 첫 번째 기초적인 것은 센서들이 마이크로컨트롤러(MCU)와 특정한 타입의 센싱 장치들로 이뤄졌다는 것이다. 이 둘이 함께 작동해서 아날로그로 되어 있는 주변 환경을 디지털 패킷으로 변환한다. 

디지털화를 한 다음에는 데이터를 클라우드로 보내서 추가적인 프로세싱을 할 수 있다. 이때 전송 방식으로 흔히 선택하는 것이 무선이다. 무선 센서 데이터 패킷은 대체적으로 크기가 작으며, 무선 노드 자체가 크기, 비용, 전력 면에서 효율적이어야 한다. 과거에는 이러한 커넥티비티를 달성하기 위해서 많은 업체들이 서브 기가헤르츠 무선 주파수와 배터리 수명 극대화를 위해서 경량 무선 프로토콜을 사용하였다.

기존 방식들은 너무 전력 소모적이거나 원하는 거리까지 도달하지 못했기 때문에 많은 업체들이 할 수 없이 자체적인 프로토콜을 개발해야만 했다. 하지만 지금은 지그비, 쓰레드, 저전력 블루투스(BLE)를 비롯해서 개발자들이 사용할 수 있는 견고하고 전력 효율적인 표준들이 많이 나와 있다.

IoT 디바이스 디자이너가 당면한 과제는 어떻게 하면 BOM 비용과 복잡성을 최소화하면서 단일 제품으로 이러한 모든 무선 표준을 지원할 수 있게 하느냐는 것이다. IoT로 사용될 수 있는 모든 가능한 무선 표준을 지원하는 전문적인 디자인을 설계할 수 있는 자원이나 시간적 여유를 갖고 있는 디바이스 업체는 많지 않다.

다중프로토콜 다중대역 SoC는 개발자들을 위해서 바로 이와 같은 딜레마를 해결한다. 하나의 고도로 통합적인 디바이스로 고유기술 서브 기가헤르츠 주파수와 2.4 GHz 대역의 표준 기반 프로토콜들을 모두 지원하기 때문이다. 다중프로토콜 다중대역 SoC는 무선 트랜시버를 통해서 2개의 무선 경로를 제공한다. 하나는 서브 기가헤르츠 용이고, 다른 하나는 2.4 GHz 전송용이다. 이러한 통합적인 무선 아키텍처를 사용함으로써 IoT 개발자들이 현장에서 다양한 애플리케이션에 따라서 유연성을 가능하게 한다.

그러면 무선 SoC로 통합되는 통상적인 다중대역 트랜시버의 신호 체인을 살펴보자. 무선 트랜시버의 어떤 장치들은 공유되고, 어떤 장치들은 각기 별도이다. 예를 들어서 RF 부분은 각기 다른 주파수 요구를 처리하기 위해서 각기 별도의 장치들을 사용해야 한다. 하지만 모뎀(변조기, 복조기, 그리고 일부 암호화 하드웨어로 이루어짐)은 양쪽 무선 프론트엔드가 공유할 수 있다.

이와 같은 무선 아키텍처는 다중프로토콜 다중대역 SoC 디자인을 위해서 극히 최적화되고 일관되고 경제성 뛰어난 해결책을 제공한다. 각기 다른 프로토콜 스택이 모뎀을 공유해서 다양한 통신 표준을 구현할 수 있다. 또한 RF 부분들 간에 모뎀을 다중화해서 패킷을 수신 및 전송할 수 있다.

이러한 공유 아키텍처는 소프트웨어 개발을 하기에도 수월하다. 무선 기능들에 대해서 공통적인 인터페이스를 제공하기 때문이다. 그러므로 개발자가 각기 다른 프로토콜 스택 간에 공유할 수 있는 무선 구성 층을 구현할 수 있다.

다중프로토콜 다중대역 시스템을 구현하기 위해서 필요한 소프트웨어는 복잡하다. 무선 프로토콜 스택은 효율적이어야 하고 다양한 하드웨어 제품들이 조합된 위에서 실행되어야 한다. 또한 실시간 운영체제(RTOS)를 사용해서 멀티쓰레드 환경으로 작동해야 한다. 다중프로토콜 애플리케이션에서는 스택들이 부담이나 비효율을 초래하지 않으면서 서로 간에나 개별적으로나 매끄럽게 작동해야 한다. 2개 스택을 공유 하드웨어를 사용해서 동일 SoC로 실행할 때는 구현 시에 네트워크 무결성을 유지하도록 고려해야 한다. 이것은 복잡한 일이다.

다중프로토콜/다중대역 시스템은 〈표 1〉에서 보는 것과 같은 방식들을 사용할 수 있다. ‘프로그래머블’ 다중프로토콜 커넥티비티가 구현하기가 가장 쉽다. 엔지니어링 책임자들이 많은 부분에서 코드를 재사용할 수 있으며, 여러 최종 제품에 걸쳐서 단일 디바이스를 사용할 수 있으므로 효율을 높일 수 있다.

엔지니어들은 지그비, 쓰레드, BLE, 또는 고유기술 프로토콜을 실행하기 위한 단일 SoC 디바이스를 선택할 수 있다. 그런 다음 생산 단계에 가서 그 제품으로 블루투스를 실행할지 아니면 서브 기가헤르츠를 실행할 지를 결정할 수 있다. 그러므로 제조업체들이 비용적 위험성을 최소화하면서 생산 시에 최대의 유연성이 가능하다.

‘전환식(Swtiched)’ 다중프로토콜(그림 1)은 최종 고객을 위한 가치 제안이 뛰어나다. 이 방식은, 예를 들어서 현장에서 설치하는 사람이 스마트폰 앱을 통해서 제품 프로비저닝이나 캘리브레이션을 할 수 있다. 이 방식은 특히 쓰레드나 지그비 노드를 설치할 때 유용하다. 

다양한 네트워크에 걸쳐서 프로비저닝을 하는 것은 어려울 수 있다. 전환식 다중프로토콜 방식은 이 작업을 단순화한다. IoT 제품이 처음에는 BLE를 사용하다가 나중에는 메시 네트워킹(Mesh Networking)을 하기 위해서 다른 프로토콜로 프로비저닝을 하고 전환을 할 수 있기 때문이다. 전환식 다중프로토콜이 동적 다중프로토콜에 비해 장점은, 더 적은 디바이스 자원을 필요로 한다는 것이다. 다중의 무선 디바이스들 간에 다중의 프로토콜을 저장하고 실행할 필요가 없기 때문이다.

 

▲ 그림 1. 전환식 다중프로토콜 방식은 커넥티드 디바이스가 현장에 이미 설치되어 있을 때라도 새로운 펌웨어 이미지를 부트로드를 해서 무선 프로토콜을 변경할 수 있다. 예를 들어서 이 기법은 스마트폰 커넥티비티를 사용해서 저전력 블루투스에서 지그비, 쓰레드, 여타 무선 네트워크로 전환할 수 있다.

‘동적(Dynamic)’ 다중프로토콜(그림 2)은 물리 자원들을 시분할을 하는 방법으로 하나의 SoC로 2개(혹은 그 이상의) 프로토콜을 지원할 수 있다. 동적 다중프로토콜은 플래시 메모리 같은 디바이스 자원을 더 많이 사용하며 소프트웨어 아키텍처가 좀더 복잡하다. 또한 상이한 프로토콜들 간에 무선 자원을 동적으로 공유하기 위해서 신중하게 설계된 무선 디자인을 필요로 한다.

동적 다중프로토콜 방식은 더 많은 하드웨어 자원을 사용하기는 하나, 이것을 상쇄할 수 있는 이점들을 제공한다. 많은 경우에 동적 다중프로토콜 기법은 디자인 복잡성과 전반적인 시스템 비용을 적어도 50% 낮출 수 있다. 이것은 2개 혹은 그 이상의 IC에 분산 규칙 엔진과 상이한 스택 아키텍처를 사용하는 것이 아니라 하나의 SoC 디바이스만 사용하기 때문이다. 단일 다중프로토콜 SoC에 견고한 RTOS, 잘 설계된 무선 스택, 로컬 애플리케이션을 결합함으로써 다중의 커넥티비티 모드를 필요로 하는 IoT 디자인을 손쉽게 구현할 수 있다.


그림 2. 동적 다중프로토콜 커넥티비티를 사용해서 단일 무선으로 3개 통신 스택을 실행하는 예. 시분할 메커니즘을 사용해서 프로토콜들 간에 무선을 공유할 수 있다. 이러한 동적 방식을 사용함으로써 저전력 블루투스와 여타 무선 프로토콜을 함께 사용할 수 있다. 이 예에서는 보통은 지그비로 실행되다가 규칙적으로 블루투스 비콘 기능을 사용하고 있다.
 

‘동시적(Concurrent)’ 다중프로토콜은 쓰레드와 지그비 네트워크의 게이트웨이 디자인에 사용하기에 유리하다. 프로토콜과 무선 구성이 유사하기 때문에 많은 소프트웨어 및 하드웨어 자원을 그대로 재사용할 수 있기 때문이다. 예를 들어서 쓰레드와 지그비는 동일한 PHY 및 MAC 층을 공유하므로 트랜시버를 재구성해야 하는 필요성을 최소화한다.

또한 쓰레드와 지그비는 통신 스택의 더 상위에서 일부 요소들을 공유하므로 자원 공유를 더 효율적이고 관리하기 쉽게 만든다. 그러므로 디바이스로 더 소형의 메모리 풋프린트를 사용할 수 있으므로 최종 제품의 비용을 낮출 수 있다.

다중프로토콜 솔루션은 앞으로 더 많이 필요할 것 

현재로서 소수의 SoC 회사들만 고도로 통합적인 SoC와 최적화된 소프트웨어를 포함하는 다중프로토콜 제품을 제공한다. 다중프로토콜 무선 디자인의 복잡성을 간소화하기 위한 개발 툴을 제공하는 회사는 더 적다. 그러므로 현장에서 시스템으로 스택들이 서로 매끄럽게 작동하도록 하는 것이 어려운 작업이다.

게다가 더 어려운 점은 무선 설계 팀이 전 세계에 흩어져 있고 설계 목표가 서로 다를 수 있으며, 서로 다른 사업부 소속일 수 있다는 점이다. 다중의 스택이 서로 다른 회사의 것이거나 서로 다른 진영의 것일 때는 전력과 메모리 제약 이내에서 신뢰할 수 있는 시스템을 달성하기가 만만치 않게 어려울 것이다.

CPU 사이클과 메모리 자원을 낭비하지 않기 위해서는 프로토콜들이 제약적인 시스템으로 하드웨어를 효율적으로 사용해야 한다. 특히 프로토콜 스택 간에 전환하는 것을 효율적으로 처리해야 한다. 그렇지 않으면 충돌이 발생하거나 에너지가 낭비될 수 있다. CPU 사이클을 낭비하는 것은 곧바로 배터리 수명에 해로운 영향을 미친다. 또한 스택 자체가 어떠한 비효율이 있으면 더 많은 메모리를 필요로 할 수 있으며, 그러면 시스템 비용을 높일 것이다. 그러므로 성공적인 애플리케이션을 달성하기 위해서는 개발자들이 디바이스 하드웨어(SoC 또는 모듈), 무선 스케줄러, 스택, RTOS를 비롯한 모든 요소들을 신중하게 고려해야 한다.

다중프로토콜 다중대역 솔루션의 필요성은 갈수록 더 높아질 것이다. 어떠한 한 무선 프로토콜이 모든 IoT 애플리케이션을 두루 충족하지 못하기 때문이다. 세상은 갈수록 더 연결성이 높아지고 있으며, IoT의 모든 측면의 다양한 요구를 충족하기 위해서 커넥티드 디바이스와 임베디드 소프트웨어는 점점 더 복잡해지고 있기 때문이다.  

<저작권자(c)스마트앤컴퍼니. 무단전재-재배포금지>

본 기사의 전문은 PDF문서로 제공합니다. (로그인필요)
다운로드한 PDF문서를 웹사이트, 카페, 블로그등을 통해 재배포하는 것을 금합니다. (비상업적 용도 포함)
 PDF 원문보기

  • 100자평 쓰기
  • 로그인

태그 검색
본문 검색
TOP