[socket programming] IoT Network/Session layer protocol

개요

사물인터넷(IoT)과 유비쿼터스 컴퓨팅의 등장으로 무선센서네트워크(WSN)를 인터넷에 연결할 수 있는 프로토콜을 설계할 필요가 대두되었습니다. 현재 WSN을 IP 네트워크에 연결하기 위해 프록시 기반 방식과 센서 스택 기반 방식 두 가지 주요 접근법이 사용되고 있습니다. 프록시 기반 접근법에서는 싱크 노드가 센서 노드와 인터넷 간의 게이트웨이 역할을 합니다. 스택 기반 접근법에서는 IP 프로토콜이 각 노드에 구현되어 센서 네트워크 내에서 데이터 교환을 가능케 하며, 다른 IP 기반 네트워크와의 연결성도 제공합니다.

---

Network layer protocols

6LoWPAN

6LoWPAN은 표준 IEEE 802.15.4를 통해 IPv6를 사용할 수 있게 하는 데 중요한 역할을 합니다. 6LoWPAN은 IPv6 기능을 저전력 노드에 가져와 제한된 전력의 노드 간 연결을 가능케 합니다. 6LoWPAN은 IEEE 802.15.4 표준에 정의된 물리계층(PHY)과 매체접근제어(MAC) 계층 프로토콜을 하위 계층 프로토콜로 채택합니다. IPv6 프로토콜이 6LoWPAN의 네트워크 계층 프로토콜로 사용됩니다.

IPv6 네트워크 계층의 최대 전송 단위(MTU)가 IEEE 802.15.4의 MAC 계층과 호환되지 않기 때문에 네트워크 계층과 MAC 계층 사이에 적응 계층이 도입됩니다. 6LoWPAN은 네트워크의 게이트웨이 사용을 제거하여 데이터 전달에 소요되는 지연을 줄입니다. 스마트 미터링, 건강 모니터링, 추적 등의 실시간 모니터링 애플리케이션에 더 적합한 것으로 알려져 있습니다. Ethernet MAC에서 최대frame(packet) 크기가 1518 바이트인 반면 IEEE 802.15.4에서는 127 바이트.

 

6LoWPAN - Major functions

IPv6 및 UDP/ICMP 헤더 압축

IEEE 802.15.4 프레임의 최대 패킷 크기는 127바이트인 반면, IPv6 헤더 크기는 40바이트, 사용자 데이터그램 프로토콜(UDP) 및 인터넷 제어 메시지 프로토콜(ICMP) 헤더 크기는 모두 4바이트, 단편화 헤더는 5바이트의 오버헤드를 추가합니다. 압축 없이는 유효 페이로드를 효과적으로 전송할 수 없습니다. 6LoWPAN은 IPv6 패킷 헤더를 압축하여 오버헤드를 줄입니다. 이를 통해 제한된 대역폭과 전력을 가진 저전력 무선 네트워크에서 효율적인 패킷 전송이 가능

소스 주소와 목적지 주소는 각각 128비트입니다. 이를 2비트로 압축한다. 
HC2 인코딩에는 1비트가 사용됩니다. 이는 HC1 헤더 다음의 추가 압축 스키마를 나타냅니다.
완전히 압축되면 HC1 인코딩을 통해 IPv6 헤더가 2바이트로 줄어듭니다. 요약하면 링크-로컬 IPv6 주소의 경우 최대 40바이트의 IPv6 헤더를 단 2바이트로 압축할 수 있음을 보여줍니다. 

 

추가 설명
- 압축하지 않으면 IPv6 헤더가 40바이트이지만, 압축하면 2바이트로 표현 가능(링크 계층 주소에서 IPv6 주소 생성 가능)
- 다음 페이지에서 자세히 설명하고 있는데, Datagram size는 전체 페이로드 크기, Datagram tag는 단편화된 패킷들의 그룹을 식별, Datagram offset은 단편화된 패킷의 순서를 나타냄
- 64비트 주소 사용 시 17바이트임
- 비트 패턴이 11이면 단편화 헤더, 10이면 메시 헤더를 의미
- O=1이면 16비트 짧은 주소, O=0이면 64비트 EUI 주소를 사용

 

단편화 및 재조립

IEEE 802.15.4의 최대 프레임 크기는 127바이트인 반면, IPv6에서는 최대 전송 단위(MTU)가 1280바이트 이상입니다(IPv4 MTU는 프레임 내 데이터만 고려하여 1500바이트). 이 불일치는 적응 계층에서 처리됩니다. IPv6는 최대 전송 단위(MTU)가 최소 1280B여야 합니다. 반면에 IEEE 802.15.4의 표준 패킷 크기는 127B입니다. IEEE 802.15.4의 최대 프레임 크기는 127바이트로 제한되어 있기 때문에, 이보다 큰 IPv6 패킷은 여러 개의 프레임으로 나누어 전송

라우팅
멀티홉 전달을 지원하기 위해 링크 계층으로 전달

 

6LoWPAN - Functions

두 네트워크의 패킷 크기 적응
IPv6는 최대 전송 단위(MTU)가 최소 1280B여야 합니다. 반면에 IEEE 802.15.4의 표준 패킷 크기는 127B입니다. 
주소 결정
IPv6 노드에는 임의 길이의 네트워크 접두사를 통해 계층적으로 128비트 IP 주소가 할당됩니다. IEEE 802.15.4 장치는 IEEE 64비트 확장 주소 또는 PAN 내에서 고유한 16비트 주소(연결 이벤트 후)를 사용할 수 있습니다.
매개변수 최적화에 대한 서로 다른 초점
IPv6 노드는 높은 속도 달성을 목표로 합니다. TCP/IP의 TCP 커널과 같은 상위 계층에서 구현된 알고리즘과 프로토콜은 혼잡과 같은 일반적인 네트워크 문제를 처리하도록 최적화되어 있습니다. IEEE 802.15.4 규격 장치에서는 에너지 절약과 코드 크기 최적화가 최우선 과제입니다.
상호운용성 및 패킷 형식을 위한 적응 계층
IPv6 도메인과 IEEE 802.15.4 간 상호운용성을 허용하는 적응 메커니즘
6LoWPAN의 메시 토폴로지에 대한 라우팅 고려사항 및 프로토콜 - 2단계 문제
개인 영역 네트워크(PAN) 공간에서의 메시 라우팅
IPv6 도메인과 PAN 도메인 간 패킷의 라우팅 가능성
보안
IEEE 802.15.4 노드는 보안 모드 또는 비보안 모드로 작동할 수 있습니다.
6LoWPAN의 제한된 리소스 활용을 높이기 위해 UDP 프로토콜을 일반적으로 사용합니다. TCP는 선호되지 않습니다.

 

이러한 주요 기능들을 통해 6LoWPAN은 저전력 무선 네트워크에서 IPv6 프로토콜을 효과적으로 사용할 수 있도록 지원합니다. 패킷 압축과 단편화를 통해 제한된 자원을 효율적으로 활용하고, 주소 자동 설정을 통해 네트워크 관리를 간소화할 수 있습니다.

---

Session layer protocols

제가 번역해드리겠습니다:

MQTT

MQTT(Message Queuing Telemetry Transport)는 M2M(Machine to Machine) 통신을 위한 개방형 메시지 프로토콜로, 고지연 또는 제약 네트워크를 통해 서버나 작은 메시지 브로커로 원격 장치로부터 메시지 형태의 원격측정 데이터를 전송할 수 있게 해줍니다. 경량이며 단순한 장치 데이터 수집 솔루션을 제공하지만, MQTT 게시자와 구독자 간의 상호운용성은 부분적으로만 보장됩니다.

 

MQTT Concepts

MQTT (Message Queuing Telemetry Transport)는 제한된 환경에서 안정적인 통신을 위해 설계된 경량 메시징 프로토콜입니다. 특히 대역폭이 낮거나 지연이 크거나 신뢰할 수 없는 네트워크연결을 가진환경에서 사용됩니다. 

주제/구독: 메시지는 주제에 게시되며, 클라이언트는 주제 또는 관련 주제 집합을 구독할 수 있습니다.
게시/구독: 클라이언트는 주제를 구독하거나 주제에 게시할 수 있습니다.

서비스 품질 수준: MQTT에는 세 가지 QoS 수준이 있습니다:
   - 0 = 최대 한 번 (최선 노력, 확인 없음)
   - 1 = 최소 한 번 (확인됨, 확인 받지 못한 경우 재전송)
   - 2 = 정확히 한 번 [전송 요청(Publish), 전송 허가(Pubrec), 메시지(Pubrel), 확인(Pubcomp)]

 

유지된 메시지: 서버는 모든 구독자에게 메시지를 보낸 후에도 메시지를 유지합니다. 새 구독자는 유지된 메시지를 받습니다.
클린 세션 및 내구성 연결: 연결 설정 시 클린 세션 플래그는 연결 해제 시 모든 구독을 제거합니다. 그렇지 않으면 연결 해제 후에도 구독이 유지되며, 높은 QoS의 후속 메시지는 재연결 후 전달을 위해 저장됩니다.
유언장(will): 연결 시 클라이언트는 예기치 않은 연결 해제가 발생할 경우 게시해야 할 유언 또는 메시지가 있음을 알릴 수 있습니다. 클라이언트가 연결을 잃으면 알람이 울립니다.
주기적인 연결 유지 메시지: 클라이언트가 여전히 살아 있는 경우
주제 트리: 주제는 '/' 문자를 사용하여 트리로 구성됩니다. '#'은 모든 하위 레벨과 일치하고, '+'는 하나의 하위 레벨과만 일치합니다.

 

MQTT Publish/Subscribe

 

 

이 이미지는 MQTT(Message Queuing Telemetry Transport) 프로토콜의 publish-subscribe 메시징 패턴을 보여주고 있습니다.
MQTT에는 세 가지 주요 구성 요소가 있습니다:
1. Publisher (source): 데이터를 생성하고 특정 topic에 publish하는 엔티티입니다. 이 이미지에서 Publisher는 "Publish (topic, info)"를 Broker에게 보내고 있습니다.
2. Broker: 메시지를 라우팅하고 전달하는 중앙 통신 허브 역할을 합니다. Publisher로부터 메시지를 받아 해당 topic을 구독한 Subscriber에게 전달합니다.
3. Subscriber (sink): 특정 topic을 구독하고 해당 topic의 메시지를 수신하는 엔티티입니다. 이미지에서 Subscriber는 "Subscribe (topic)"을 Broker에 보내 topic을 구독합니다.

동작 과정은 다음과 같습니다:
1) Subscriber가 Broker에 구독 메시지를 보내 특정 topic을 구독합니다.
2) Publisher가 토픽 메시지를 Broker에 전송합니다.
3) Broker는 해당 topic을 구독한 Subscriber에게 토픽 메시지를 전달합니다.

이렇게 MQTT는 publish-subscribe 패턴을 통해 분산된 디바이스 간 메시징을 효율적으로 수행할 수 있습니다.

---

CoAP(Constrained Application Protocol)는 매우 단순한 전자 장치에서 사용되는 소프트웨어 프로토콜로, 이를 통해 장치들이 인터넷 상에서 통신할 수 있습니다.
- 단순한 저전력 전자 장치(예: 무선 센서)와 인터넷 기반 시스템 간의 연결을 지원하도록 설계되었습니다. 데이터 수집에 사용될 수 있습니다.

 

CoAP(Constrained Application Protocol) 트랜잭션
- CON(Confirmable)은 수신측이 승인 또는 재설정을 보내줄 것을 요청하는 메시지입니다. 
- NON(Non-confirmable)은 수신측에게 메시지 전송을 요청하지 않습니다.
- ACK(Acknowledgement)는 CON이 수신되었음을 알리며, 페이로드를 포함할 수 있습니다.
- RST(Reset)는 CON이 수신되었지만 컨텍스트 부족으로 처리할 수 없음을 나타냅니다.
또한 트랜잭션은 피어 간에 호출되며 트랜잭션 ID(TID)로 구분됩니다.

CoAP 메소드
- GET: 식별된 자원의 정보를 검색합니다.
- POST: 요청된 URI 하위에 새로운 자원을 생성합니다. 
- PUT: 식별된 URI의 자원을 업데이트합니다.
- DELETE: 식별된 URI의 자원을 삭제합니다.
CoAP는 URI로 자원을 식별하고, HTTP 메소드와 유사하며, HTTP 응답 코드의 부분집합을 사용합니다. 옵션은 HTTP 헤더와 비슷하지만 더 간결한 인코딩을 사용합니다.

CoAP 프로토콜 스택
- 애플리케이션 계층에서 CoAP 메소드가 동작하고, 
- 그 아래 CoAP 트랜잭션 계층이 있습니다. 
- 전송 계층에서는 UDP를 사용하고, 
- 네트워크 계층은 IPv6/RPL, 
- Adaptation 계층은 6LoWPAN,
- 링크 계층은 802.15.4를 각각 사용하고 있음을 나타내고 있습니다.

---

비교 

MQTT와 CoAP는 모두 IoT(사물 인터넷) 환경에서 널리 사용되는 프로토콜입니다. 두 프로토콜의 주요 차이점은 다음과 같습니다:
1. 전송 프로토콜:
   - MQTT: TCP/IP 위에서 동작하며, 신뢰할 수 있는 연결 지향적 프로토콜입니다.
   - CoAP: UDP 위에서 동작하며, 비연결 지향적이고 경량화된 프로토콜입니다.
2. 메시지 교환 패턴:
   - MQTT: 발행/구독(Publish/Subscribe) 모델을 사용하여 메시지를 전달합니다. 클라이언트는 특정 주제를 구독하고, 해당 주제에 대한 메시지를 수신합니다.
   - CoAP: 요청/응답(Request/Response) 모델을 사용하여 메시지를 교환합니다. 클라이언트는 서버에 요청을 보내고, 서버는 해당 요청에 대한 응답을 반환합니다.
3. 메시지 크기:
   - MQTT: 메시지 크기에 제한이 없으며, 대용량 데이터 전송에 적합합니다.
   - CoAP: 메시지 크기가 작아 경량화된 데이터 전송에 적합합니다. 일반적으로 UDP 패킷 크기 제한인 1500바이트 이내로 메시지를 전송합니다.
4. 보안:
   - MQTT: SSL/TLS를 사용하여 보안 연결을 설정할 수 있습니다.
   - CoAP: DTLS(Datagram Transport Layer Security)를 사용하여 보안 연결을 설정할 수 있습니다.
5. QoS(서비스 품질):
   - MQTT: 세 가지 QoS 수준(0, 1, 2)을 제공하여 메시지 전달 보장 수준을 선택할 수 있습니다.
   - CoAP: 확인 메시지(Confirmable Message)와 비확인 메시지(Non-confirmable Message)를 통해 신뢰성을 제공합니다.
6. 리소스 발견:
   - MQTT: 주제 기반의 메시지 전달에 초점을 맞추며, 리소스 발견 메커니즘을 직접 제공하지 않습니다.
   - CoAP: 내장된 리소스 발견 메커니즘을 제공하여 CoAP 서버에서 사용 가능한 리소스를 검색할 수 있습니다.
MQTT와 CoAP는 각각의 특징에 따라 다양한 IoT 애플리케이션에서 선택적으로 사용됩니다. MQTT는 대용량 데이터 전송과 발행/구독 모델이 필요한 경우에 적합하며, CoAP는 경량화된 데이터 전송과 요청/응답 모델이 필요한 경우에 적합합니다.