13 CoAP

13. CoAP

차를 갖고 계신 분이라면, 누구나 한 번 쯤 주차할 공간을 찾지 못해 주차장을 빙빙 돌던 경험이 있으실 것입니다. 이런 불편함을 보완할 수 있는 방법은 없을까요? 여기 사물인터넷을 이용한 주차장이 있습니다. 다른 주차장과 별 다를 바 없이 평범해 보이는 이곳 주차장에는 특별한 비밀이 있습니다.먼저, 주차를 하기 위해 주차장 입구에  들어서면, 주차 가능한 빈 공간을 안내하는 전광판을 만날 수 있습니다.전광판에는 몇 번째 열에 얼만큼의 빈 공간이 있는지를 표시해 줄 뿐 아니라, 그 위치까지 정확하게 표시하고 있어, 사용자는 주차할 공간을 미리 확인할 수 있습니다.

또한 전광판은 차량 이동이 많아 혼잡하거나 빈 공간이 없을 경우에도 미리 알려주어 다른 공간으로 주차를 유도합니다. 그리고 이 모든 것을 스마트폰 앱을 통해서 확인 할 수 있습니다.

어떻게 이런 것이 가능할까요?

비밀은 바로 클러스터 헤드와 립 노드에 있었습니다. 바닥에 설치된 립 노드는 자동차의 여부를 센싱하여 데이터를 클러스터 헤드에 전송합니다.

이렇게 모여진 데이터는 다시 관리센터에 전송되어 주차장의 상태를 실시간으로 모니터링 할 수 있는 것입니다.

이렇게 장치 사이에 데이터를 원활히 주고받기 위해서는 통신 규약, 즉 프로토콜이 필요합니다.

이 주차장의 센서는 CoAP 프로토콜을 사용하여 다른 장치와 소통하고 있는데, 립 센서와 같이 자원 제한적인 임베디드 장치를 기존의 웹 서버와 호환할 수 있도록 변환해주는 역할을 하는 것입니다. 이번 시간에는 이러한 CoAP 프로토콜에 대해 살펴보도록 하겠습니다.

CoAP의 소개

1. CoAP 개념

CoAP의 소개

CoAP의 개념에 대해 학습해보도록 하겠습니다. CoAP는 Constrained Application Protocol의 약자로, 제한적인 애플리케이션 프로토콜이라는 뜻입니다. 간단한 전자 기기들의 인터넷 통신을 지원하기 위해 만든 프로토콜로, 저전력 센서, 스위치, 밸브 등의 기기를 표준적인 인터넷 환경에서 제어하기 위한 목적으로 만들어졌습니다. 무선 센서 네트워크(WSN : Wireless Sensor Network) 노드들처럼 제한된 자원의 인터넷 연결을 지원하고, 사물통신 시나리오에 요구를 충족하면서 REST 적합하게 설계되어 MQTT와 같이 RAM, ROM 메모리가 적은 마이컴에 적합합니다.

또한 HTTP와 비슷한 메시지 구조를 가지고 있어서, HTTP와도 효과적으로 연결되며, UDP 멀티캐스트(Multicast)를 지원, 사물인터넷과 M2M 디바이스같은 환경에서 오버헤드를 줄일 수 있다는 특징을 지닙니다. CoAP는 웹을 이용해서 클라이언트와 기기를 연결한다는 관점에서 WoT, 즉 Web of Things Protocol 프로토콜이라고 부르기도 합니다. 로컬네트워크에서 각 기기들은 CoAP로 서로 연결됩니다.인터넷을 통해서 클라이언트와 연결하려면 프록시를 거쳐야 합니다. 프록시는 캐싱을 이용하여 네트워크의 효율을 높이는 역할을 합니다. 또한 Server와 CoAP로 직접 연결할 수 있습니다.

CoAP가 제공하는 구체적인 특징은 다음과 같습니다. RESTful 프로토콜로, HTTP을 기반으로 REST 아키텍처를 적용할 수 있습니다. 동기, 비동기 메시지 교환을 모두 지원하며, 제약조건이 많은 단말이나 네트워크를 고려하여 신뢰성 있는 유니캐스트, 멀티캐스트를 UDP 프로토콜을 이용하여 지원합니다. 그리고 간단하게 파싱할 수 있는 헤더로, 적은 헤더 오버헤드로도 데이터 전달이 가능합니다.

또 하나의 큰 특징은 HTTP와 CoAP를 변환하는 것이 고려되어 만들어졌기 때문에 서로 쉽게 변환할 수 있게 되어 있습니다.MQTT와 CoAP 프로토콜을 비교해보면 다음과 같습니다

2. CoAP 전송계층

CoAP의 전송계층을 살펴보도록 하겠습니다. 인터넷에서 일반적으로 사용하는 스택이 왼편이고 오른쪽이 CoAP를 이용한 사물인터넷 스택입니다.

CoAP 프로토콜의 전송계층은 UDP와 애플리케이션 사이에 위치하며, 두 가지 레이어로 정의됨을 알 수 있습니다.

한 가지는 요청과 응답에 대한 맵핑을 담당하는 요청/응답 계층으로  GET, PUT, DELETE, POST 메소드를 이용한 REST 모델을 사용합니다.

다른 부분은 신뢰성 보장을 담당하는 메시지 계층으로, CON, ACK, NON, RCT 네 가지 방식의 메시지 타입이 있습니다.

CoAP는 UDP를 기반으로 합니다. UDP의 특징은 TCP가 데이터의 전달을 보증하는 것과 달리 전달을 보증하지는 않습니다. 따라서 주로 브로드캐스팅 방식이 활용됩니다.   

요청/응답 계층은 요청과 응답에 대한 매핑을 담당합니다. CoAP 요청과 응답은 메소드 코드(Method Code) 혹은 응답 코드를 포함하여 전달되며, 토큰 옵션이 사용되어 요청 메시지에 대한 응답을 잘 구분하도록 설계되었습니다. CoAP은 비신뢰적인 전송 위에서 구현되기 때문에 CoAP 메시지의 도착 순서가 뒤바뀌거나 전송 중간에 손실될 수 있습니다.

그러므로 애플리케이션 레벨에서 신뢰성 제공을 위한 방안의 구현이 요구됩니다.

이러한 신뢰성 제공을 위한 방법으로는 Confirmable 메시지를 위한 Exponential Back-off 방법을 이용한 Stop-and-wait 재전송 방안이 있습니다.

메시지 계층을 살펴보도록 하겠습니다. 먼저 CON은 Confirmable 메시지로 응답을 요구하는 메시지입니다.

확인 메시지에 담기거나 비동기 방식으로 전송하고 데이터 송수신 시 잃어버린 데이터가 있을 때 알림을 줍니다. 만약 이 메시지가 처리되지 않는 경우에는 리셋 메시지에 전송되는 방식입니다. NON은 Non-confirmable 메시지를 뜻합니다. UDP 방식의 메시지로, 확인이나 응답도 요구되지 않는 메시지에 사용합니다. ACT는 Acknowledgement, 즉 응답 메시지 입니다. Confirmable 메시지의 수신을 승인하는 데 사용되며, Confirmable 메시지에 대한 응답에 함께 담겨 전송될 수 있습니다.RCT는 Reset으로 Confirmable 메시지가 처리되지 않는 경우에 사용됩니다. 데이터가 수신되었지만 약간의 데이터 상실이 있을 때 보내지는 프로토콜로 시간의 제약이 존재하므로 구현 시 특정 시간 이내에 보내져야 합니다.

CoAP 프레임 구성

1. 베이스 헤더

CoAP 프레임 구성

CoAP의 프레임 구성을 살펴보도록 하겠습니다.

CoAP 메시지는 2진 포맷으로 인코딩되며, 타입-길이-값(TLV) 포맷을 따라 헤더가 고정된 크기를 가지고 만들어진다. 프레임 내에 정의된 필드를 살펴보면, 베이스 헤더는 버전, 메시지 타입, 토큰의 길이를 나타내는 토큰 길이, 메시지의 종류를 나타내는 코드, 요청과 응답 메시지의 매칭을 구분하기 위한 메시지 ID로구성됩니다. 그 외에는 토큰, 헤더 옵션, 마커와 페이로드 데이터로 구성됩니다.CoAP 메시지 형식은 32비트 즉 4바이트의 짧은 헤더를 사용합니다. 헤드의 각 필드를 정의하자면, 먼저 버전은 CoAP의 버전을 나타내며, T는 메시지 타입을 뜻합니다.

0부터 3까지의 숫자를 사용하여 4가지 메시지 타입을 표현합니다. Confirmable은 0, Non-confirmable은 1, Acknowledgement은 2, 그리고 Reset은 3으로 나타냅니다. TKL은 Token Length, 즉 토큰의 길이로 0~8바이트의 가변 길이 토큰 필드입니다. 코드는 메시지의 종류를 나타내며, 메시지 ID는 요청과 응답 메시지의 매칭을 구분하기 위해 사용됩니다. CoAP 메시지 예를 살펴보도록 하겠습니다. 클라이언트가 온도를 묻는 요청, 즉 GET 메시지를 서버에 보냅니다. 이 때 전송되는 메시지는

HTTP처럼 텍스트로 보내지는 것이 아니라 헤더의 정해진 비트 정의에 따라서 인코딩 됩니다. 예를 들면 GET은 1로 메시지아이디는 0x7d34(16진수 칠디삼사)로 온도는 옵션 헤더의 길이가 11바이트로 되어 있습니다.

CoAP의 메소드 코드는 다음과 같습니다. GET은 현재 자원을 조회합니다. 보통 컬렉션 자원을 조회하게 되면 하위의 도큐먼트들의 목록과 아주 간단한 정보들을 가져오며, 도큐먼트 자원을 조회하게 되면 해당 도큐먼트에 대한 자세한 정보들을 가져옵니다. POST는, 현재 자원 보다 한 단계 아래에 자원 생성합니다. PUT은 현재 자원을 수정하며, DELETE는 현재 리소스를 삭제합니다.

클라이언트의 요청을 받은 서버는 응답으로 온도 값을 전송합니다. 메시지는 다음과 같습니다.  2.05는 메시지의 코드이며,  22.3의 온도라는 내용을 포함합니다. 응답 코드와 정의를 살펴보면, 다음과 같습니다. 내용을 확인해 보세요. 바이너리 프로토콜의 의미는 비트들로 의미를 표시하는 것입니다. CoAP는 저전력용 네트워크 프로토콜인데 이 때문에 부하를 최대한 줄여야 하는 조건이 존재합니다.

이 때문에 바이너리 헤더를 적용하여 네트워크 오버헤드를 최소화 시키는 것입니다. 클라이언트에서 요청하는 메시지 입니다.

Confirmable 메시지를 0x7d34로 보내는데, 내용은 GET 즉, 요청을 하는 것이며, 그 내용은 Temperature 온도라는 의미입니다.

이것은 사람이 읽을 수 있는형식으로 표시한 것이고 실제는 이렇게 비트들로 메시지를 파싱하여 소프트웨어가 처리합니다.

요청에 대한 응답 메시지도 코드화 되어 들어가 있음을 확인할 수 있습니다. CoAP의  URI에 대해 살펴보도록 하겠습니다.

URI는 자원을 아이디를 뜻하며, 표준에서 시작하여 이름을 붙이는 방식으로 자원의 위치를 나타냅니다. 웹에서 URL은 이름이나 주소 등의 역할을 하는 것입니다.

Universal Resource Identifier, 즉, 보편적인 자원 식별자라는 뜻의 URI는 URN과 URL을 합쳐서 부르는 말로,URN은 자원의 이름, URL은 자원의 위치를 표시합니다. URL은 Scheme, Authority, Port, Path, Query로 구성됩니다. CoAP 프로토콜에서도 자원을 유일하게 구분하는 주소를 이름으로 사용합니다. 자원은 자원에 접근하는 프로토콜 즉 http나 CoAP와 자원이 있는 호스트의 주소, 포트넘버 그리고 자원의 호스트내의 경로로 표시됩니다.

2. 옵션 헤더

CoAP 메시지 형식 중에서 옵션을 살펴보도록 하겠습니다.

옵션 헤더는 토큰과 페이로드 사이에 위치하며, 메시지에 포함될 수 있는 옵션을 정의합니다.

3. 메시지 시퀀스

메시지 시퀀스에 대해 알아보도록 하겠습니다. 먼저, 요청/응답 메시지 프로토콜은 그림과 같습니다.

클라이언트는 서버에 /light 자원을 요청합니다. 서버는 요청에 대한 응답에 해당하는 값을 전송합니다.

이 때, 0xaf5는 메시지 아이디로 요청메시지와 응답메시지를 연결해주는 역할을 합니다.

메시지 손실에 대한 처리를 살펴보면, 클라이언트가 메시지를 보냈으나, 서버의 응답이 없어서 시간초과 되는 경우, 다시 같은 메시지 아이디를 가진 메시지를 재전송합니다. 그리고 보낸 메시지 아이디에 대한 응답 메시지를  받아야 클라이언트는 통신을 종료합니다.

응답 분리에 대해 알아보도록 하겠습니다. 클라이언트에서 서버에 메시지를 보낸 뒤, 서버로부터 응답이 오래 걸릴 경우, 서버는 메시지의 내용없이 응답만 우선 보냅니다. 그리고 나중에 준비가 되면 같은 토큰 값으로 내용을 보냅니다. 그런 뒤, 클라이언트가 그에 대한 응답을 보내면 서버는 통신을 종료합니다.

캐싱에 대해 살펴보도록 하겠습니다. 캐싱은 프록시를 이용하여 네트워크의 효율을 높이는 작업입니다. 프록시란 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해 주는 컴퓨터나 응용 프로그램을 말하는데, 네트워크의 자원을 절약하며 절전모드의 노드를 지원하고

있습니다. CoAP은 경우에 따라 노드가 클라이언트, 서버, 프록시의 역할을 할 수 있습니다.

CoAP에서 프록시의 정의는 노드가 데이터 요청을 할 때 원래 응답을 해야 할 노드를 대신하여 이전에 캐시 된 내용을 토대로 대신 응답할 수 있는

노드를 이야기합니다. 프록시가 CoAP에서 필요한 이유는 모든 M2M 노드들은 임의의 시간에 응답을 줄 수 없는 휴면상태로 들어갈 수가 있는데, 이 경우 휴면 노드에 대한 자원 이벤트의 요청이 있을 경우, 프록시가 대신해서 캐시된 응답을 해줘야 하기 때문입니다. 캐싱은 응답 코드로 결정하며, 캐싱 모델은 응답 코드에 캐싱 가능성을 표시하고 있습니다.

신선도 모델은 Max-Age 옵션으로 캐시의 수명 수기를 결정합니다. 유효성 모델은 Etag옵션으로 유효성을

캐싱의 예를 살펴보면 다음 그림과 같이 나타낼 수 있습니다. CoAP 서버와 HTTP 클라이언트 사이에 프록시가 존재하는데, 클라이언트가 조명값을 요구하면 서버는 그에 대한 응답을 하고 프록시는 이를 클라이언트에게 전송합니다. 이때 프록시는 캐시를 저장해 두고 있다가, 클라이언트가 같은 요청을 할 때 저장된 캐시를 전송합니다.

옵저브는 서버에게 클라이언트가 자원의 상태를 알려줄 것을 요청하는 것입니다. 예를 들면, 다음 그림과 같이 나타낼 수 있습니다.  클라이언트가 서버 자원의 상태를 요청하면, 서버는 응답을 하는데,  자원에 변화가 생길 때마다 응답을 하는 것으로, 일종의 콜백 같은 효과가 있습니다. CoAP는 옵저버 옵션을 이용해서 관심있는 리소스를 등록할 수 있습니다.

옵저버로 정보를 읽기를 원한다면 옵저버와 토큰 값을 채워서 보내면 됩니다.

대량 전송은 자원의 값이 대량일 때 나누어 전송하는 방식입니다. 클라이언트는 분할된 데이터를 차례로 받을 것을 요청합니다.  그러면 서버는 4096바이트의 데이터를 1024 바이트씩 4개의 블록으로 나누어, 차례로 클라이언트에게 전송합니다. 클라이언트는 서버에게 자원의 리스트를 요청할 수 있습니다. 멀티캐스트 채널로 찾을려는 자원에 대한 정보를 뿌리는 것입니다. 화면처럼 자원 리스트로 요청 메시지를 보내면 서버는  자원의 리스트를 응답메시지를 피기백합니다.

주요 업체의 CoAP 구현 동향

많은 국내외 업체 및 기관들이 CoAP 프로토콜을 구현하고 시장에 진출하고 있습니다. 주요 업체를 대상으로 구현 동향을 살펴보기로 하겠습니다.

먼저, ARM 의 경우, 2013년부터 본격적으로 사물인터넷 시장에 뛰어들기 시작하였습니다. ARM의 사물인터넷 전략은 개방형 개발 플랫폼인 ARM mbed과 사물인터넷 표준 솔루션 등이 있으며, 여기에 자사의 하드웨어가

포함된 레퍼런스 플랫폼을 제공하고, 미들웨어 및 클라우드 서비스 기술이 포함된 소프트웨어 플랫폼 기술을 포함하고 있습니다. ARM은 센시노드 인수를 통해 사물인터넷 솔루션과 IETF CoAP을 포함한 국제 사물인터넷 표준화 활동에도 참여하여 자신들의 기술을 표준화에 반영하고 있으며, 자사의 솔루션에도 표준내용을 먼저 구현하여 기능을 넣고 있습니다.  

독일 브레멘(Bremen) 대학 TZI의 Carsten Bormann은 IETF CoAP 워킹그룹 좌장으로써 표준화에 주도적인 활동을 하고 있으며, CoAP 오픈 소스인 Libcoap 라이브러리를 개발하고 있습니다. 이처럼 TZI 는 학계 연구소 차원에서 표준화와 CoAP 및 사물인터넷 기술 보급에관심을 가지고 활동하고 있습니다.

스위스 취리히 연방 공과대학의 ETH에서는 CoAP 표준화 활동 및 사물인터넷 기술과 관련된 연구 및 구현을 진행하고 있으며, 비록 상용 제품은 없으나 수준 높은 CoAP 구현 소프트웨어 기술을 보유하고 있습니다.

iMinds는 벨기에의 산ㆍ학 협력 촉진을 통한 ICT 서비스 및 사업화 진흥을 위해 설립된 창업 컨설팅 및 투자 전문기관입니다. iMinds 또한 사물인터넷 및 CoAP 기술 구현에 참여하고 있습니다. 여기에서는 다양한 규모, 형태의 실제 네트워크 장비와 단말들을 구비해 놓고 ICT 솔루션이나 상품의 창업자를 돕기 위해 개발과 시험을 진행하고 있으며, 총 13개의 최신 트랜드 프로젝트를 수행하고 있습니다. 그 중 임베디드 서비스를 타깃으로 하는 창업자를 위해 CoAP 프로젝트를 구성하고 직접 구현하면서 플랫폼을 제공하고 있습니다.

국내에서도 대학교 및 ETRI를 중심으로 CoAP 을 구현하고 있습니다. ETRI는 소형 센서 노드 등 다양한

기기에 이식할 수 있도록 경량화된 CoAP 소프트웨어를 개발하여 중소기업 대상으로 기술이전을 진행 중입니다.

특히, ETRI CoAP는 IP 프로토콜 지원뿐만 아니라, 지그비 MAC/PHY, RS-485 와 같이 IP 프로토콜을 사용하기 어려운

통신 인터페이스를 지원하기 위한 유연한 구현 구조를 가지고 있으며, 기술이전을 통해 KT 빌딩관제 시스템과 스마트

강의실 구축 사업에 적용하는 등 CoAP 기술을 전파하고 관련 시장 활성화에 기여하고 있습니다. 그 밖의 많은

업체 및 기관들이 다양한 프로그래밍 언어와 플랫폼용으로 CoAP을 구현하고 있습니다.