티스토리 뷰

오늘 이야기는 gateway없이 인터넷에 직접 연결되는 IOT 무선 기기의 메모리 고려 사항에 대한 것이다.


IOT(Internet Of Things)라고 하는 것은 한마디로 하면 Sensor Device + Networking + Cloud 라고 할 수 있다. 

Device의 사양을 저전력, 저가, 초소형으로 고려하는 경우에는 보통은 인터넷에 직접 연결하는 방식이 아니라 gateway를 통하여 연결하는 방식을 사용한다. Device와 gateway의 연결은 BluetoothZigbeeZ-WaveThreadLoRa , 802.15.4 등의 가벼운 무선 프로토콜을 이용하여 연결하고, gateway에서 데이타를 인터넷으로 전달하게 된다. 


하지만 제품에 따라서는 device가 직접 cloud나 다른 internet 장치에 연결을 하려는 경우도 있다. 이 경우에는 위의 제품과 같이 배터리로 수개월 또는 수년간 사용하는 것은 불가능 하겠지만,  저가, 초소형화는 제품의 고려 사항이 될 수도 있다. 이 경우 네트워크 인터페이스는 ethernet, 802.11 Wi-Fi, LTE 등이 있다.


이 경우를 위한 Wi-Fi(wpa supplicant), TCP/IP 가 있는 솔루션으로는 아직까지는 Cypress(Broadcom) WICED 가 유일해 보인다. Ethernet 인 경우에는 좀더 많은 솔루션을 찾을 수는 있을 것이다. 


아래 예는 WICED(3.1.2)를 이용하여 MQTT를 이용하여 연결한 프로젝트의 static memory 사용량이다. 

Module

Flash

Static RAM

App

22,894

8,173

base64

517

0

DHCP_Server

1,517

132

DNS

1,364

44

Host MCU-family library

18,134

2,561

HTTP_client

196

0

Interrupt Vectors

424

0

libc

35,551

3,140

Malloc_debug

556

24

MQTT

4,044

4

Networking

4,553

16,494

NetX

34,158

56

Packet Buffers

0

22,414

platform

1,416

176

RAM Initialisation

2,988

0

Ring_Buffer

92

0

SPI_Flash_Library

636

0

Startup Stack & Link Script fill

40

15

Supplicant - BESL

90,363

516

ThreadX

9,164

396

WICED

3,729

844

WWD

13,928

1,127

TOTAL(bytes)

243,276

56,116


위의 정보는 링크 시 각 모듈의 text, data, bss 를 기준으로 계산한 것으로 결과를 보면 대부분의 ram 사용이 network과 송수신 버퍼용 이다. 이외에 Wi-Fi FW image 약 200KB와 각 thread의 stack 및 동적으로 할당하는 메모리가 필요하다. 어림 짐작으로 계산해보면 flash 450KB, ram 80KB 정도면 얼추 될듯 하다. 이정도면 WICED에서 사용 가능한 STM32 series 중 internal flash 512KB, static ram 128KB 를 선정해서 사용하면 될 것이다.


작은 기기라도 보안은 주요 고려 대상이다. 초기 설계부터 이를 고려하여 설계를 하였다면 UDP 기반 프로토콜(예를 들어 CoAP)에 DTLS(Datagram TLS)를 사용하였을 것이고 이런 방법은 mbed나 zephyr 등의 다른 RTOS 환경에서도 제공한다. 

하지만 위 WICED 예처럼 TCP기반의 MQTT를 사용한다면 SSL/TLS를 위한 추가 메모리가 더 필요하게 된다. 위 모듈에서 Supplicant - BESL 가 Wi-FI wpa supplicant와 SSL/TLS를 위한 라이브러리 이다. 이 부분을 보면 여러 암호화, 인증서 관리 등으로 rom영역(text + data)이 크지만 ram 사용은 516bytes 밖에 되지 않는다. 물론 실제로 돌려보면 이 BESL 모듈은 추가적인 동적할당과 thread stack을 사용하게 된다. 이 부분이 실제로 IOT 기기가 동작할때 메모리 부족 문제를 가져올수 있다. 


문제는 TLS Record Protocol 라는 하위 layer를 통하여 전송하게 된다는 것이다. 암호화도 이 단위로 되므로 수신측에서 암호를 푸는 것도 record block 전체를 받은 후가 된다. 즉, record block 만큼 들어올 때 까지 fragmentation buffer에 저장을 해야 한다는 것이다. 표준에서 정의하는 최대 record size는 2^14(16,384 bytes)로 작은 메모리를 가진 IOT 기기에서는 부담스러운 크기이고, 이 부분이 SSL/TLS 연결시 negotiation되는 것이 아니다. 보통은 TLS proxy나 http server에서 초기 설정으로 결정되거나 보내는 data 량에 따라서 동적으로 변경된다. 만일 단말에서 TLS 두 채널을 열어서 사용한다면 이 fragmentation buffer는 2배로 늘어날 수 있다.

이것 이외에도 SSL/TLS를 사용하게 되면 WICED의 경우 thread stack도 추가적으로 늘어나게 되고, WICED 3.1.x에서는 record block 수신을 위한 fragmentation buffer 할당이 malloc으로 동적으로 할당을 하게 되어 연속된 heap 공간이 없으면 여유 메모리가 있지만 에러가 날 수 있다. 


물론 이 가정은 server에서 client로 내려오는 데이타가 많은 경우에만 해당될 것이다. 보통의 경우는 작은 크기의 데이타가 오가기 때문에 이와 같이 큰 record block이 사용 되지는 않을 것이다. 하지만 upgrade나 FPGA를 위한 image 다운로드 등의 경우에는 문제가 될 소지가 있다. 해결방법은 서버의 설정을 조정해서 max record size를 wifi MTU size보다 작도록 제한을 하는 것이다. WICED의 경우를 한정한다면 BESL 모듈은 binary라 수정을 할 수 없지만 아래 memory allocation 모듈은 수정이 가능하므로 이를 동적할당이 아닌 고정된 메모리 영역을 이용하도록 하는 것도 검토해 볼 수는 있을 것이다. 


이같이 조금은 무거운 IOT 기기를 고려한다면 메모리 문제에 대해서 충분한 고민을 하여야 할 것이다. 


저작자 표시
신고
댓글
댓글쓰기 폼