IoT protocol CoAP 메시지 구조(Message Format) 요약 정리

 CoAP(Constrained Application Protocol)는 제한된 환경에서 M2M(Machine To Machine) 요구사항을 충족하는 웹 프로토콜이며, 이런 특성으로 인해 IoT를 위한 프로토콜로 각광받고 있다고 한다. 본 포스트에서는 이러한 CoAP의 메시지 구조에 대해 알아봤으며, 앞으로 CoAP에 관한 더 많은 포스트를 게재할 예정이다.

CoAP는 RFC 7252에 정의 되어있다.


CoAP (Constrained Application Protocol)

CoAP의 상호 작용 모델은 HTTP의 클라이언트/서버 모델과 유사하다. 

그림 1.

CoAP의 메시지는 각 EndPoint간 UDP를 통해 전송된다.

그림 2.



CoAP Message Format

그림 3. CoAP Message Format

CoAP의 메시지 형식은 위 그림과 같다. 


- Var

CoAP 버전을 의미한다. 값은 0b01이다.

- T (Type)

메시지의 형식을 나타낸다.

  • Confirmable(CON): 0 , ack를 요구하는 메시지
  • Non-confirmable(NON): 1 , ack를 요구하지 않는 메시지
  • Acknowledgement(ACK): 2 , CON 메시지에 대한 응답 메시지
  • Rest(RST): 3 , 메시지가 수신되었으나 올바르게 처리하기 위한 내용이 누락되었음을 나타내는 메시지

메시지의 타입은 아래와 같은 형태의 메시지에 사용된다. Empty 메시지는 일반적인 경우 CON형식은 사용되지 않으나, RST메시지를 유도하기 위해서만 사용된다.

그림 4.


- TKL (Token Length)

Token field의 길이 정보로 값은 0~8 bytes가 사용된다. 9~15는 추후 사용이 예약되어 있으며 현재는 사용하면 안 된다.


- Code 

총 8 bits이며, 3 bits의 class와 5bits의 details로 나눠 있다. 

class는 다음과 같다.

  • Request : 0
  • Success response : 2
  • Client error response : 4
  • Server error response : 5

0.00은 empty message를 의미한다.  상세한 내용은 다음 포스트에서 다룰 예정이다. 


- Message ID

메시지 중복 탐지 및 ACK/RST 형식 메시지를 CON/NON 형식으로 매칭하는데 사용된다. 

Message ID는 CON/NON 메시지를 보내는 쪽에서 생성되며, ACK/RST 응답 메시지를 송신할 때 수신된 Message ID를 사용해야 한다. Message ID는 EXCHANGE_LIFETIME내에서 중복되어서는 안 된다.

그림 5. CoAP 파라미터
EXCHANGE_LIFETIME 내에 동일한 Message ID를 가진 CON 메시지를 수신(전송 오류 등의 원인으로)할 수도 있다. 이 경우 Receiver는 메시의 요청이나 응답을 한 번만 처리해야한다. NON_LIFETIME내에 동일한 Message ID를 가진 중복된 NON 메시지를 수신한 경우에도 중복된 메시지를 묵살하고, 메시지의 요청이나 응답을 한 번만 처리해야한다. 


- Token

Token 필드의 길이는 TKL의 값에 의해 정해진다. Token은 request와 response를 일치시키는데 사용된다. 모든 request에는 client가 생성한 token이 있으며, 서버는 요청 결과를 응답할 때 이 token을 반드시 반향해야 한다. Token은 동시 요청을 구별하기 위한 "request ID"라고 할 수 있다.

그림 6. 즉각적인 메시지 요청/응답

또한 아래 그림과 같이 시간을 두고 요청에 대한 응답을 보내는 경우 Token 값 0x73을 이용해 request와 response를 매칭할 수 있다. 


그림 7. 시차를 둔 메시지 요청/응답

- Option

그림 8. Option format

Option Delta : 이전 Option 번화와 이번 Option 번호화의 차이를 나타낸다.

  • 0~12 - option delta를 나타낸다.
  • 13 - 8 bits extended option delta 필드가 있다는 것을 의미하며, 확장 필드에는 option delta - 13 값이 들어간다. 
  • 14 - 16 bits extended option delta 필드가 있다는 것을 의미하며, 확장 필드에는 option delta - 269 값이 들어간다.
  • 15 - payload marker용으로 예약되어 있으며, 사용해서는 안 된다. 

Option Length: Option Value의 길이를 나타낸다.

  • 0~12 - Option value 길이
  • 13 - 8 bits extended option length 필드가 있다는 것을 의미하며, 확장 필드에는 option length - 13 값이 들어간다.
  • 14 - 16 bits extended option length 필드가 있다는 것을 의미하며, 확장 필드에는 option length - 269 값이 들어간다.
  • 15 - 사용해서는 안 된다.

Option Value: 다음과 같은 option value 형식이 있다. 

  • empty: 길이가 0으로 비어 있다.
  • opaque: opaque 배열.
  • uint: 네트웍 바이트 오더로 음수가 아닌 정수 데이터.
  • string: utf-8 문자열


- 0xff (payload marker)

payload marker는 option의 끝과 payload의 시작을 의미한다. 하지만, option 뒤에 또 다른 새로운 option의 시작을 의미하기도 한다. payload marker가 없으면 payload가 없음을 의미한다. 


- Payload

 request/response에 따라 특정 데이터가 들어간다. 위 그림 6에서와 같이 요청에서는 payload에 'temperature'가 응답에서는 '22.5 C'의 데이터가 들어간다.
payload는 옵션이며 길이는 payload marker에서 UDP datagram의 끝까지의 길이를 사용하여 계산해야 한다. 




관련 포스트

IoT Protocol CoAP 메시지 요청/응답 모델 내용 정리

댓글

댓글 쓰기

이 블로그의 인기 게시물

쉽게 설명한 파티클 필터(particle filter) 동작 원리와 예제

이미지
파티클 필터(particle filter)는 칼만 필터(kalman filter) 와 마찬가지로 노이즈가 있는 환경에서 측정된 데이터를 필터를 사용해 실제 위치를 추정하는 도구다. 파티클 필터(particle filter)는 보통 가우시안 분포가 아닌 측정 데이터를 다루기 위해 사용된다고 한다. 물론 가우시안 분포의 데이터에서 사용하지 말라는 건 아니다.  본 포스트에서는 파티클 필터(particle filter)의 어려운 수학적인 내용은 제하고, 쉽게 예를 들며 필터의 동작원리에 대해 알아보았다. 파티클 필터(particle filter)에 대해 검색해 보면 아래와 같은 그림을 많이 보게 된다. 아래 그림은 파티클 필터의 estimation cycle을 도식화한 것이다. <’Real-Time Tracking of Multiple Moving Objects Using Particle Filters and Probabilistic Data Association’ original scientific paper 中> 위 그림의 검은색 원들은 particle을 의미한다. 이 particle에는 보통 위치 데이터와 weight가 포함된다. 검은색 원이 큰 것이 있고 작은 것이 있는 이유는 weight가 크고 작음을 의마한다. typedef struct _particle_t {    int x;    int y;    float weight; }particle_t; 노이즈가 있는 환경에서 레이저 센서나 레이더등을 이용하여 물체의 위치를 측정할 때를 가정해 순서대로 이 필터가 동작하는 과정에 대해 알아 보겠다. (순서는 위 그림과 조금 다르다) 1. 초기 상태 측정 범위안에 랜덤 혹은 일정한 간경으로 particle을 뿌려 놓는다. 이 떄 particle의 weight는 모두 0으로 한다.   for(i
자세한 내용 보기

아두이노(arduino) 심박센서 (heart rate sensor) 심박수 측정 example code

이미지
하드 정리 중 예전에 만든 아두이노에서 심박센서를 사용하여 심박수 측정하는 소스 코드가 있어, 이를 블로그 글로 남긴다. 인터넷 쇼핑몰에서 쉽게 구할 수 있는 저렴함 센서가 사용 되었으며, 연결은 아래 그림과 같이 연결 되었다.      심박센서의 하트 부위에 손가락을 올려 놓고, 아날로그 A0값을 읽으면 심박의 움직임에 따라 A0값이 변하는 동작이 간단한 센서이다. 아래 그림의 왼쪽은 일정 시간 간격 마다 A0값을 읽어 시리얼 플로터로 본 심박에 따른 데이터이고, 오른쪽은 평균 필터를 사용해 노이즈를 제거한 후 시리얼 플로터로 본 데이터이다.   심박수는 수집된 데이터에서 threshold를 넘는 peak들의 시간 간격을 측정하여 계산한다.  peak위치를 찾는 방법은 여러 가지 방법이 있으나, 소스에 구현된 방법은 신호의 기울기가 +에서 0또는 -로 바뀌는 위치를 peak으로 선정하도록 하였다. 심장이 t시간동안 N회 뛰는 경우 심박수는 heart rate bpm = (N/t)*60 을 표현 할 수 있다.   threshold는 데이터를 보고 임의로 정했으며, 측정 데이터에 따라 자동으로 정하고 싶을 때는 cfar 같은 방법을 사용하면 된다.  소스는 아래와 같다. #define heartbit_adc_threshold      511 #define meanfilter_size             5 #define heartbit_tick_buffer_size   10 #define measure_buffer_size       3 float meanfilter[meanfilter_size] = {0,};
자세한 내용 보기

간단한 cfar 알고리즘에 대해

이미지
Constant False Alarm Rate (CFAR)은 기본적으로 테스트하고자 하는 위치의 cell과 주변 cell의 관계를 보고 테스트 cell이 Target 인지 아닌지를 구분하는 알고리즘이다. 주변 cell과의 관계를 어떤 방식으로 비교하는가에 따라 여러가지 알고리즘이 존재한다. CA-CFAR, GO-CFAR, SO-CFAR, OS-CFAR, VI-CFAR, OSVI-CFAR등이 있다. 이 많은 알고리즘 중 간단하고 기본적인 CA-CFAR과 OS-CFAR에 대해 알아보자. CA-CFAR (Cell Average CFAR)   CA-CFAR의 원리는 위 그림과 같다. 좌우의 Reference Cell의 평균에 Scale Factor T를 곱하고, ADT (Average Decision Threshold)를 합하여 CUT가 타겟인지 아닌지를 구분한다. ADT는 신호의 white noise를 고려하기 위해 더해준다. Scale Factor T와 ADT는 아래와 같은 공식으로 사용할 수 있다. 사용하려는 시스템에 따라 공식은 달라질 수도 있다.   Pfa는 False Alarm 발생 확률을 나타내고, M과N는각 좌우의 Reference Cell의 개수를 나타낸다. OS-CFAR (Order Static CFAR)   OS-CFAR의 원리는 위 그림과 같다. 좌우의 reference cell중 K번째 큰 값의 cell을 Reference Cell의 대표 값으로 정해 CUT가 타겟인지 아닌지를 구분한다. 보통 전제 reference cell의 크기 순에서 (3*N)/4 번째 cell이 성능이 좋다고 알려져 있다. CFAR 사용 예 아래 사진은 위 두 cfar을 사용한 예다. 파란색은 신호이며, 붉은 색은 char을 사용해 만든 threshold이다. 이 threshold보다 큰 값의 신호가 있는 위치에 실제 Target이 있다고 볼 수 있
자세한 내용 보기

base64 인코딩 디코딩 예제 c 소스

이미지
본 글은 base64 encoder/decoder예제 c 소스 코드를 싣고 있다. BASE64 BASE64는 일련의 데이터를 64종류" ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ "의 문자만을 이용하여 표현하도록 하는 부호화 방식이다. Base64는 인터넷 이메일 프로토콜이나 http url등에서 사용된다.  부호화 과정은 아래와 같다. 문자 : Hello Hex 코드 : 0x48 0x65 0x6c 0x6c 0x6f 8bits bin 코드: 01001000 01100101 01101100 01101100 01101111 8비트 단위의 문자를 6비트 단위로 분리한다. 6bits bin 코드 : 010010  000110  010101  101100  011011  000110  1111  00  ‘=’ 6비트 2진 코드 값은 BASE64 코드 테이블의 인덱스이고 각 인덱스의 문자로 base64 부호화 한다. 마지막 모자라는 비트는 0으로 채우며, 4글자 단위로 부호화 하기 때문에 4글자가 안되면 ‘=’기호를 사용해 4글자를 맞춘다. Base64 코드 : aGVsbG8= Base64 Encoder source code Base64 인코더 소스는 아래와 같다. 위의 부호화 예대로 text데이터를 받아 6bit 단위로 나누어 base64 코드 테이블에 맞춰 부호화를 진행한다. static const char base64code_ascii[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"; int text2base64_size(const char *text) { int len = strlen(te
자세한 내용 보기

바로 프로젝트 적용 가능한 FIR Filter (low/high/band pass filter )를 c나 python으로 만들기

이미지
 band pass filter 코드가 필요해 인터넷을 검색을 해봤지만, 쓸 만한 코드와 자료가 별로 없어 그냥 만들어 쓰기로 했다. 필요한 공식은 위키피디아에 나와있다. https://en.wikipedia.org/wiki/Finite_impulse_response 1. filter 크기 FIR filter를 만들 때 filter의 크기(tpas의 크기)를 결정할 때 도움될 수식이 있다.   N=A㏈Fs / 22*Δf A㏈ : 감쇄될 db Fs : Sampling Frequency Δf : frequency bandwidth 출처 :  https://www.allaboutcircuits.com/technical-articles/design-of-fir-filters-design-octave-matlab/ def estimatefilterlen(fl,fh,fs,db):     N = int(np.round(db * fs / (22 * (fh-fl)))-1)     return N 2. Low Pass Filter [ python code ] def lowpassfilter(f,fs,N):     taps = np.zeros(N)          fc = f / fs     omega = 2*np.pi*fc     middle = int(N/2)     for i in range(N):         if i == middle:             taps[i] = 2*fc         else:             taps[i] = np.sin(omega*(i-middle))/(np.pi*(i-middle))              return taps [ c code ] #ifndef PI #define PI 3.14159265358979323846 #endif
자세한 내용 보기