사물 인터넷을 위한 새로운 커넥티드 디바이스를 개발하기 위해서는 이러한 디바이스와 메쉬 네트워크의 특성을 이해해야 한다. 디바이스 동작은 메시지 지연시간, 전력 소모, 배터리 수명 같은 특성들을 결정하며, 네트워크 동작은 엔드투엔드 메시지 지연시간, 전반적인 쓰루풋, 네트워크 확장성 등에 영향을 미친다. 그러므로 새로운 커넥티드 디바이스를 설계할 때 이러한 기본적인 동작을 이해하고 설계 사항들을 신중하게 고려해야 한다. 이 글에서는 디바이스 동작과 네트워크 동작이 주요 파라미터와 성능에 미치는 영향에 대해서 살펴본다.

수 천만대의 기기들이 데이터 속도가 느린 IEEE 802.15.4 무선 네트워크에 연결되어 사용되고 있다. 이 네트워크는 독자적인 점대점 방식에서부터 ZigBee 및 새로운 스레드 프로토콜과 같은 IP 기반 메쉬 네트워킹 스택에 이르기까지 다양한 프로토콜을 사용한다. 

IoT(사물 인터넷)를 위한 새로운 커넥티드 디바이스를 개발하기 위해서는 이러한 디바이스와 메쉬 네트워크의 특성을 이해해야 한다. 디바이스 동작은 메시지 지연시간, 전력 소모, 배터리 수명 같은 특성들을 결정하며, 네트워크 동작은 엔드투엔드(end-to-end) 메시지 지연시간, 전반적인 쓰루풋, (디바이스 성능을 유지하는 내에서의) 네트워크 확장성 등에 영향을 미친다. 

소프트웨어와 하드웨어의 상호작용 또한 구현에 따라서 달라질 수 있으며 배터리 동작수명 같은 주요 파라미터에 영향을 미친다.

그러므로 새로운 커넥티드 디바이스를 설계할 때 이러한 기본적인 동작을 이해하고 설계 사항들을 신중하게 고려해야 한다. 이러한 관점에서 이 글에서는 디바이스 동작과 네트워크 동작이 주요 파라미터와 성능에 미치는 영향에 대해서 살펴본다.

디바이스 동작

1. 임베디드 메쉬 IP 네트워크에서 디바이스 동작이 미치는 영향

IEEE 802.15.4를 기반으로 한 임베디드 메쉬 네트워크에서는 기본적으로 두 가지 타입의 디바이스가 사용된다. 첫째는 라우터로 사용되는 파워드 디바이스(powered device)이다. 이 디바이스는 메시지를 다른 디바이스들로 전달하기 위해서 리시버를 향상 켜둔다. 

두 번째 디바이스는 슬립 모드로 전환할 수 있는 단말 디바이스이다. 이 디바이스는 주로 슬립 모드로 있다가 메시지를 전송하거나 또는 자신에게로 전송되는 메시지가 있는지 네트워크로 확인할 때만 웨이크(wake) 상태가 된다.

네트워크의 동작은 라우터 디바이스의 성능에 의해서 결정된다. 배터리로 작동되는 디바이스를 설계하는 디자이너들에게 가장 중요한 문제는 단말 디바이스의 성능이다.

2. 단말 디바이스의 슬립-웨이크 사이클

IEEE 802.15.4의 기본적인 메커니즘이 이들 단말 디바이스의 동작을 결정한다. 첫째는 단말 디바이스가 데이터 폴링을 전송해서 페어런드(parent) 디바이스가 자신에게로 전송할 데이터를 가지고 있는지 묻는 것이다. 슬립 모드로 있는 단말 디바이스가 자신에게로 전송될 데이터가 있는지를 네트워크에 물을 때 가장 흔히 사용하는 방법이 데이터 폴링이다. 

두 번째 802.15.4 메시지는 데이터 패킷이다. 데이터 패킷이 들어오면 디바이스가 깨어나고, 데이터를 전송하고, 다시 슬립 모드가 된다. 그림 1은 이러한 디바이스의 웨이크-슬립 사이클을 보여준다.

▲ 그림 1. 웨이크-슬립 사이클 예

다음과 같은 다수의 요인들이 배터리 사용 디바이스의 전력 소모에 영향을 미친다.

• ‌동적 전류 및 슬립 전류(사용하는 하드웨어 디자인과 IC에 따라서 달라진다)

• ‌디바이스가 깨어나고 동작을 할 수 있게 준비하는 데 걸리는 시간(구현에 따라서 달라진다)

• ‌무선 전송에 걸리는 시간(패킷 크기에 따라서 달라진다)

• ‌확인응답(acknowledgement)을 기다리는 데 걸리는 시간(사양에 따라서 결정된다)

• 슬립 및 웨이크 타이밍(구현에 따라서 달라진다)

디바이스 디자이너는 이 중에서 몇 개의 요인들만 영향을 미칠 수 있다. 디자이너들은 통상적으로 슬립 및 웨이크 사이클 타이밍을 설정할 수 있다. 이 설정에 따라서 디바이스의 배터리 수명이 달라진다. 그런데 또 하드웨어와 소프트웨어의 상호작용이 이 슬립 및 웨이크 사이클의 효율을 결정하고 전반적인 배터리 수명에 중대하게 영향을 미친다.

임베디드 메쉬 IP 네트워크의 실행 결과

표 1은 Silicon Labs의 EM35x 무선 SoC와 최신 임베디드 메쉬 IP 스택인 Thread 프로토콜을 사용해서 실행한 두 가지 웨이크 및 슬립 동작의 측정 결과를 보여준다.

▲ 표 1. 웨이크 시간(단위 : ms)

최소 시간과 최대 시간 사이의 차이는 사용되지 않는 채널을 찾기 위한 시간 때문이다. 패킷 전송에서는 보안 프로세싱을 하고 있으나 데이터 폴링에서는 하고 있지 않다. 이들 동작 시의 전류 소모는 사용하는 무선 및 MCU 장치와 전류 프로파일(동적 및 슬립 전류)에 따라서 달라질 것이다. 

디바이스 웨이크 시간과 슬립 전류에 따른 영향

디바이스의 성능 평가는 실제 시스템 맥락에서 데이터를 투입하지 않고서는 별 의미가 없을 것이다.

새로운 디바이스를 개발하는 디자이너는 배터리 수명을 계산해야 한다. 그러기 위해서는 하드웨어와 소프트웨어의 상호작용을 고려해서 웨이크 및 슬립 시간 성능을 도출해야 한다.

디자이너들이 가장 흔히 하는 실수는 소프트웨어와 하드웨어의 상호작용이 웨이크 및 슬립 시간에 미치는 영향을 고려하지 않고서 단순히 디바이스들 간의 동적 및 슬립 전류만을 비교하는 것이다.

그림 2와 그림 3은 다른 모든 조건들을 고정시키고 웨이크 시간을 두 배로 했을 때와 슬립 전류를 두 배로 했을 때 배터리 수명에 어떻게 영향을 미치는지 보여준다. 그림 2에서 보는 바와 같이, 10초 같은 주기적 간격으로 폴링했을 때 웨이크 및 폴링 시간이 배터리 수명에 중대하게 영향을 미친다는 것을 알 수 있다.

▲ 그림 2. 웨이크 시간에 따른 배터리 수명

▲ 그림 3. 슬립 전류에 따른 배터리 수명

하지만 오늘날 MCU 디자인의 통상적인 슬립 전류는 배터리 수명에 그보다는 덜 영향을 미친다. 그러므로 디바이스 동작을 이해하고 배터리 수명을 예측하기 위해서 웨이크 시간이 왜 그렇게 중요한지를 알 수 있다.

네트워크 동작

네트워크 동작은 쓰루풋과 메시지 지연시간에 영향을 미친다. 지연시간과 쓰루풋은 일련의 홉(hop)에 걸쳐서 측정할 수 있다. 네트워크상에서 적정한 홉 수가 걸려서 트랜스미터에서 패킷을 전송하면 리시버에서 전송측으로 확인응답을 전송한다.

그림 4는 테스트 구성을 보여준다. 이 왕복 전송은 네트워크에서 디바이스 대 디바이스 동작을 근접하게 모사하기 위한 것이지, 디바이스가 스마트폰이나 클라우드 서비스와 통신할 때의 네트워크 성능을 측정하고자 하는 것이 아니다. 

▲ 그림 4. 테스트 토폴로지

각기 다른 패킷 페이로드에 따라서 네트워크 지연시간을 측정할 수 있다. 특정한 프로토콜 스택은 일련의 헤더들을 사용한다. 헤더는 패킷으로 오버헤드를 늘리지만 매체 액세스 제어(MAC), 네트워크 및 보안 서비스 등을 위해서 필요하다.

이러한 헤더가 패킷의 오버헤드를 소모하므로 디바이스 디자이너가 애플리케이션으로 적정한 페이로드를 결정해야 한다.

예를 들어서 여기서 사용하고 있는 Thread 임베디드 메쉬 IP 스택은 다음과 같은 헤더들을 포함한다.

• PHY 및 MAC 헤더(9바이트 + 2바이트 FCS)

• MAC 보안 헤더(6바이트 + 4바이트 MIC)

• 6LoWPAN 헤더(8바이트)

• UDP 헤더(6바이트)

이들 헤더는 127바이트의 802.15.4 패킷으로 35바이트의 오버헤드를 소모한다.

네트워크 지연시간

각기 다른 패킷 페이로드로 네트워크 지연시간을 측정함으로써 페이로드가 높아짐에 따라서 미치는 영향을 살펴볼 수 있다. 그림 5는 10바이트~250바이트 페이로드에 걸쳐서 1홉부터 7홉까지의 지연시간을 보여준다.

▲ 그림 5. 왕복 지연시간

1홉일 때 왕복 지연시간은 250바이트 페이로드일 때 82밀리초로 최대를 이룬다는 것을 알 수 있다. 7홉 네트워크일 때는 동일한 250바이트 페이로드로 244밀리초라는 것을 알 수 있다.

이 왕복 지연시간은 MAC 보안 프로세싱과 수신측에서 송신측으로 확인응답을 보내는 데 걸리는 시간을 포함한 것이다.

그림 5의 지연시간 그래프에서는 패킷에 따라서 구간을 구분할 수 있다는 것을 알 수 있다. 70바이트 페이로드에서 80바이트 페이로드 사이에 첫 번째 패킷 전환이 일어나고 있다는 것을 알 수 있다. 두 번째 패킷에서 세 번째 패킷으로 넘어가는 것은 140바이트 페이로드와 150바이트 페이로드 사이에서 일어나고 있다. 이것을 보면 추가적인 패킷을 처리할 때마다 지연시간이 어떻게 높아지는지를 알 수 있다.

네트워크 쓰루풋

네트워크 쓰루풋도 지연시간과 같은 테스트 구성을 사용하였다. 이 테스트로부터 최대 쓰루풋을 도출하였다.

이 쓰루풋은 초당 패킷으로 나타낼 수 있다. 그림 6은 10바이트 페이로드와 70바이트 페이로드를 사용해서 1홉부터 7홉까지일 때의 테스트 결과를 보여준다.

▲ 그림 6. 네트워크 쓰루풋

이 결과를 보면, 10바이트 페이로드로 1홉일 때 초당 54패킷으로 높았던 것이 70바이트 페이로드이면 초당 34패킷으로 떨어진다는 것을 알 수 있다. 7홉일 때는 두 경우 모두 초당 10패킷 부근으로 수렴된다는 것을 알 수 있다.

네트워크 테스트 요약

네트워크 테스트 결과를 보면 개발자가 IP 기반 메쉬 네트워크로 유지할 수 있는 쓰루풋 또는 초당 패킷을 예측할 수 있다는 것을 알 수 있다. 그러므로 네트워크를 얼마만큼 확장할 수 있고 각기 디바이스가 주기적으로 얼마만큼의 트래픽을 전송할 수 있을지를 결정할 수 있는 중요한 지표를 제공한다.

예를 들어서 어떤 디바이스가 상태 검사를 위해서 중앙 게이트웨이로 매 10초마다 50바이트 데이터를 전송해야 한다고 하자.

이 디바이스가 게이트웨이로부터 최대 3홉까지 될 수 있는 네트워크 안에 있는 것이라면, 테스트 결과에 따르면 3홉일 때 초당 18패킷을 유지할 수 있다는 것을 알 수 있다(50바이트 페이로드 사용). 그러면 데이터를 매 10초마다 전송한다면 이 메쉬 네트워크로 180개의 이러한 디바이스를 연결할 수 있다는 것을 알 수 있다.

사용자 요구

네트워크 및 디바이스 성능 데이터를 사용해서 시스템에 대한 사용자 요구에 대해서 예상 동작을 이해할 수 있다. 그러면 이 성능 데이터를 사용해서 어떻게 시스템 구성을 판단할 수 있을지 임베디드 메쉬 네트워크로 사용자 요구의 예를 들어서 살펴보자.

조명 같은 사용자 상호작용은 100밀리세컨드(millisecond) 안에 이루어져야 한다. 커넥티드 디바이스의 사용자 상호작용은 네트워크 성능을 판가름하는 중요한 요소이다. 만약 사용자가 기대하는 응답이 제때 일어나지 않으면 사용자는 버튼을 다시 누르게 될 것이다. 이 응답 시간이 100밀리세컨드 이내이면 허용 가능하지만, 그 이상이 걸리는 것은 허용될 수 없다. 

이 경우에 왕복 지연시간은 다소 혼란을 가져올 수 있다. 조명을 켜는 사용자 동작은 단방향 메시지를 사용하고 확인응답을 회신하지 않기 때문이다. 그렇기는 하더라도 이러한 테스트 결과는 여전히 동작을 예상할 수 있는 유용한 지표를 제공한다.

예를 들어서 페이로드를 100바이트 이내로 하면 4홉까지는 지연시간이 100 밀리세컨드 이내가 될 것임을 알 수 있다

(단, 다시 말하지만 이것은 메시지의 왕복 지연시간이다). 그러므로 이러한 사용자 요구를 충족하기에 적합할 것이다. 통상적인 홈 조명 네트워크는 4홉을 넘지 않고 메시지 페이로드는 100바이트가 안 될 것이기 때문이다.

통상적인 네트워크는 250개 디바이스로 확장할 수 있어야 한다. 메쉬 네트워크에 대한 이 요구사항은 게이트웨이 또는 경계 라우터를 추가할 때의 비용 때문에 비롯되는 것이다. 게이트웨이당 지원할 수 있는 디바이스 수가 적으면 전체 집안을 커버하기 위해서 더 많은 게이트웨이가 필요할 것이고 그만큼 비용이 높아질 것이기 때문이다.

하지만 이 확장성 요구를 판단하기는 단순하지 않다. 각기 디바이스가 특정한 메시지 패턴을 사용할 수 있고, 네트워크상에서 이들 메시지들이 어떻게 중복될 것인지도 고려해야 하기 때문이다. 네트워크 쓰루풋은 허용 가능한 메시지 패턴을 판단할 수 있는 수단을 제공한다. 예를 들어서 70바이트 페이로드이고 평균 3홉인 네트워크라면 이 네트워크는 초당 약 16패킷을 유지할 수 있을 것으로 예상할 수 있다. 이 네트워크로 250개 디바이스가 연결된다면 각기 디바이스가 매 15초 이내에 메시지를 전송해야 한다는 뜻이 된다. 그러면 시스템 디자이너가 이 네트워크로 예상되는 디바이스를 계산하고 어느 만큼의 주기로 메시지를 전송하는 것이 허용될 수 있을지를 판단할 수 있다. 예를 들어서 다음과 같은 트래픽 패턴을 사용한다고 가정하고 계산할 수 있다.

• 50개 도어 및 창문 보안 센서를 매 5초마다 상태 검사

• 50개 조명을 매 1분마다 상태 검사

• 30개 조명 스위치를 매 5분마다 상태 검사

• 10개 스마트 플러그가 매 2초마다 전력 소모 데이터 전송

이러한 140개 디바이스를 연결하는 구성은 초당 16패킷이 될 것이고 3홉 네트워크로 유지할 수 있을 것이다. 여기에다 디바이스를 더 추가할수록 네트워크 속도가 떨어질 것이다.

다양한 IoT 애플리케이션에 IP 메쉬 네트워크가 사용되고 있다. 여기에 이용하기 위한 디바이스를 설계할 때는 배터리 수명과 메시지 지연시간이 중요한 고려사항이다. 이 두 가지가 임베디드 또는 배터리 사용 디바이스에 IP 기반 네트워크를 사용하기를 꺼리게 만드는 이유가 된다. IP 메쉬 네트워크를 사용한 네트워크 쓰루풋 및 지연시간 데이터를 가지고서 사용하고자 하는 디바이스 및 시스템 파라미터가 어떻게 동작할지를 예측할 수 있다. 그럼으로써 Thread 같은 새로운 IEEE 802.15.4 프로토콜을 기반으로 한 임베디드 메쉬 네트워크로 커넥티드 디바이스를 성공적으로 설계하고 구축할 수 있을 것이다.

스킵 애쉬튼 (Skip Ashton) _ 실리콘랩스