이 보고서는 사물 인터넷을 위한 표준 프로토콜 스택 연구에 대한 최근까지 연구 현황을 소개하고, 심층적으로 분석된 내용을 제공함에 초점을 둔다. 전개 방법에서는 통신 최하위 계층인 물리 계층부터 최상위 어플리케이션 계층을 위한 표준 프로토콜의 원리 및 동작을 상세히 설명하고, 현재까지 수행된 표준 연구를 통한 교훈들을 함축적으로 제시하였다.

글: 전세일  / Instituto de Telecomunicacoes
자료협약 및 제공: KOSEN(한민족과학기술자 네트워크) / www.kosen21.org


전력 물리 계층—IEEE 802.  15.4-2006

저전력 라디오 하드웨어

라디오는 디지털화된 정보를 전자기화된 신호로 변환되어 공기 중으로 전달된다. 이 때, 신호 전송에는 전력이 필요하며, 공기 중에서 가장 작은 신호로 보낼 수 있는 전력을 전력 민감성(Sensit ivity)라고 한다.

여러 센서 디바이스를 가지고 수행된 연구 결과를 보면 센서 모트가 데이터를 수신하지 않는 유휴 상태의 전류 소비가 데이터를 수신할 때의 전력 소모와 같다는 것을 확인된다. 따라서 시스템의 에너지 효율성 제고를 위해서는 전체적인 라디오의 의무 사이클을 줄여 라디오 자체에 전류 흐름을 차단시키는 차원의 연구가 요구된다.


IEEE 802.15.4-2006의 물리 계층 기술

저전력 라디오 기술 중 주목할 만한 표준 기술은 IEEE 802.15.4로서, 물리 계층과 링크 계층의 프로토콜을 상세화한다. IEEE 802.15.4 물리 계층은 에너지 효율성과 신호 도달 범위, 데이터 전송율 등을 볼 때 빌딩 크기의 네트워크에 맞춰져 있다.

현재 표준은 다중 물리 계층을 정의하고 있으며, 전 세계에서 가장 폭넓게 사용되는 주파수 대역은 2.4~2.485GHz 비면허 대역으로 정의되어 있다. 변조 방식은 QPSK을 사용하며, 16개의 주파수 채널이 2.405GHz와 2.480GHz 사이의 5MHz의 간격을 두고 배치된다.


전력 절약을 위한 링크 계층— IEEE 802.15.4E

IEEE 802.15.4는 MAC 프로토콜을 정의하며, 라디오와 직접적으로 상호작용을 수행하는 계층이다. 해당 계층의 기술은 MAC 헤더의 포맷과 모트(mote) 간 통신 방법을 규정하고 있으며, 특히 MAC 계층은 네트워크 내에 조정을 담당하는 모트와 직접 통신을 담당하도록 스타 토폴로지에 맞게 설계되었다.
 
이는 저전력 다중 홉 네트워킹을 고려한 것으로, 전력 면에서 큰 힘을 갖는 조정 모트에 데이터를 전달하도록 함으로서 오랜 시간 의무 사이클을 유지하며 데이터를 중계할 수 있고 다중 홉 라우팅에서의 데이터 손실을 상당히 줄일 수 있다.
 

슬롯 프레임 구조

TSCH는 동기화된 채널 호핑의 약자로 2010년 이후 IEEE 802.15.4e 표준의 한 부분이다. TSCH에서는 모트가 슬롯 프레임 구조를 가지고 동기화된다. 슬롯 프레임은 시간이 감에 따라 반복되는 슬롯들의 그룹으로서 모트가 각 슬롯의 스케줄마다 무엇을 해야 하는지를 알려준다. 수면 슬롯에서는 모트는 라디오 동작을 완전히 끔으로써 에너지 소모를 완벽히 차단하며, 활동 슬롯에서는 스케줄링에 의해 어떤 이웃 모트가 데이터를 수신하고, 전송하는지가 정의된다.
 

스케줄링

IEEE 802.15.4e는 MAC 계층이 어떻게 스케줄을 수행하는지를 정의하며, 다만 어떻게 스케줄이 만들어지는지는 정의하지 않는다. 스케줄링은 중앙화된 방식과 분산화된 방식으로 나누어지며, 이를 간략히 정리하면 다음과 같다.

•중앙화된 접근: 중앙화된 접근 방식에서는 관리자 모트가 존재하며, 이는 네트워크 스케줄의 생성과 관리를 담당한다. 이에 따라 모든 모트들은 관리자 및 관리자가 관리하는 다른 모트들에 대한 정보를 주기적으로 업데이트한다. 관리자는 이웃 정보들을 확인하고, 이를 통해 연결성 그래프를 작성, 슬롯을 각 모트들에게 할당하고 스케줄화하여 모트들에게 알리게 된다. 모트들은 배포된 스케줄을 따라 동작과 수면을 반복하게 되며, 연결성 그래프에서 변화가 있을 경우 관리자는 수정된 스케줄을 업데이트하고 재배포한다.

•분산화된 접근: 분산화된 접근 방식에서는 모트 스스로가 지역적으로 스케줄링을 결정한다. 네트워크가 이동하는 경우나 모트가 선택할 수 있는 게이트웨이가 많은 경우 이러한 접근은 적합하지 않다. 만약 모트들이 서로 데이터를 전송하려 할 때는 자원 예약 프로토콜이나 다중 프로토콜 라벨 스위칭 프로토콜들과 같은 예약 프로토콜을 활용하는 방식이 참조될 수 있으나 이러한 접근 방식은 아직까지 풀어야 할 많은 문제점들을 가지고 있다.



동기화

디바이스 간 동기화는 슬롯 프레임 기반의 네트워크 내의 이웃 노드들 간의 연결성 유지를 위해 반드시 필요한 요소이다. 그러나 IEEE 802.15.4e에서는 TSCH 애플리케이션을 위해 비콘(beaco n)이 전송되지 않기 때문에, 디바이스 간 동기화를 허용하는 가능한 방법으로는 응답 기반의 동기화와 프레임 기반 동기화가 고려될 수 있다.

전자의 경우, 수신자가 예측한 프레임의 도착 시간과 실제 프레임의 도착 시간의 차이를 계산하고, 이 정보를 송신자에게 응답으로 보내는 방식이다. 이는 송신자 모트로 하여금 수신자의 시간과 동기화되도록 하는 데 반해, 후자의 경우 수신자가 계산한 시간 차이를 송신자에게 전달하지 않고 차이만큼의 시간을 조정한다. 이는 수신자 모트로 하여금 송신자의 시간에 동기화되도록 한다.


채널 호핑

IEEE 802.15.4.e TSCH MAC 기술은 시간 슬롯화된 액세스에 채널 호핑 기술을 추가하였다. 채널 호핑은 신호 간섭과 다중 경로 페이딩 효과를 낮추는 데 효과적이며, 다양한 주파수의 사용이 증가할 때 많은 모트들이 동시에 서로 다른 채널 옵셋(channel offset)을 가지고 데이터 전송이 가능하여 궁극적인 데이터 전송률을 높일 수 있다.
 

네트워크 형성

TSCH에서의 네트워크 형성은 두 가지 요소인 '광고하기'와 '참여하기' 기능을 포함한다. 즉 새로운 디바이스가 네트워크에 참여하고자 할 때 먼저 광고 명령 프레임을 수신한다. 새로운 모트들은 '참여 요청' 명령 프레임을 광고 디바이스에 전송하며, 이는 다시 네트워크 관리자에게 라우팅된다.

다만 분산화된 관리 시스템에서는 각 요청 메시지들이 지역적으로 처리된다. 새로운 모트가 네트워크에서 받아들여지면, 광고자는 새로운 모트와 다른 기존의 모트들 간의 슬롯 프레임과 링크에 새로운 모트를 추가하여 활성화시킨다.
 
 

인터넷에 연결하기 - IETF 6LowWPAN

인터넷에서의 패킷 전달은 소스와 목적지 간의 연결된 네트워크를 통해 이루어지며, 각 전달 네트워크의 링크 계층 기술을 고려할 때 "IP-over-X" 라는 형식으로 어떻게 IP 패킷을 전달하는지에 대한 정의가 요구된다.

이러한 역할을 수행하는 통신 계층을 종종 '적응 계층'이라는 말로 부른다. IoT에 맞는 링크 계층 기술 구현을 위해 IETF에서는 2007년 6LoWPAN 워킹 그룹을 형성하여 IEEE 802.15.4 네트워크에서 IPv6 패킷 전송을 위한 표준 작업을 수행해오고 있다.

6LoWPAN에 의해 규정되는 네트워크 환경은 작은 패킷 사이즈, 다른 길이를 갖는 주소의 지원, 작은 대역폭, 스타 및 메시 토폴로지, 배터리로 공급되는 디바이스, 적은 비용, 다수의 디바이스, 네트워크 환경의 불안정성, 통신 인터페이스가 꺼져 있을 때 높은 유휴 시간들이며, 이러한 요구 사항들에 맞는 적응 링크 기술은 IPv6 도입과는 다소 맞지 않는 부분이 있다.

즉, IPv6는 기본적 MTU 크기가 1280바이트이며, 패킷 분활화를 지원하지 않고, 패킷 헤더 크기만 40바이트를 차지하기 때문에 저전력 전송에 적합하게 설계된 IEEE 802.15.4 프레임과는 잘 맞지 않는다.

그러함에도 불구하고 오랜 기간의 연구 노력을 통해 표준 프로토콜의 제정에 이르게 되었다. 추가적인 이슈로는 IPv6 주소 자동 설정, 공유 네트워크에서의 링크 계층 서브넷 브로드캐스트 지원, 라우팅 및 관리 오버헤드 줄이기, 경량화된 애플리케이션 프로토콜의 채택, 보안 메커니즘의 지원 및 무결성 제공, 디바이스 자동 운용, 키 관리 등 괄목한 만한 표준 프로토콜의 제정에 대한 결과가 이어져왔다.
 

6LoWPAN 프레임 포맷

IPv6 패킷 관리를 위해 링크 계층 포워딩과 분할화를 지원하는 6LoWPAN은 IPv6와 IEEE 802.15.4 MAC 계층 사이에 적응 계층으로 존재한다.

IPv6 헤더와 'Next Header' 부분은 압축되며, 중복적인 정보는 다른 계층들로부터 추론되어 억제된다. 6LoWPAN에서 사용되는 헤더는 4가지가 있으며 첫 번째로 'NO 6LoWPAN' 헤더는6LoWPAN과 부합하지 않는 패킷을 규정한다.
 
'Dispatch' 헤더는 IPv6 헤더를 압축하거나 링크 계층 멀티캐스트/브로드캐스트를 관리하기 위해 사용된다. 'Mesh Addressing' 헤더는 IEEE 802.15.4 프레임이 링크 계층에서 포워딩되도록 하여 단일 홉의 무선 센서 네트워크를 다중 홉 네트워크로 바꾸도록 하는 데 사용된다.

마지막으로 'Fragmen-tation' 헤더는 데이터그램이 단일 IEEE 802.15. 4 프레임 크기와 맞지 않을 때 분할 처리되도록 하는 데 사용된다. 두 디바이스 간의 패킷 전달 시 항상 직접적인 도달성을 담보할 수 없기에 중간 노드를 거쳐 패킷을 전달하는 경우 Mesh Addressing 헤더를 사용한다. 패킷 분할화를 위한 Fragment 헤더는 Mesh Addressing 혹은 Broadcast 헤더를 따라야 한다.
 

헤더 압축

WPAN에서 IPv6 헤더 필드는 송신자의 직접적인 요청 없이도 헤더의 적절한 처리가 이루어져야 하며, 이를 위해 필요한 데이터 페이로드의 길이는 MAC 프레임 길이나 분할화 헤더 내의 데이터그램 크기로부터 유추될 수 있다.

6LoWPAN에서의 헤더 압축을 위한 인코딩 기법으로는 6LOW PAN_IPHC, LOWPA N_NHC가 있다. 전자는 공유 환경에서 지역, 전역, 멀티캐스트 IPv6 주소의 효과적인 압축을 수행하는 데 반해, 후자는 IPv6의 Next Header 필드를 압축하는 데 사용된다.
 
 

라우팅 - IETF ROLL

6LoWPAN을 위한 라우팅 이슈는 저전력 손실 라디오 링크에서 배터리로 공급되는 노드들, 다중 홉의 메시 토폴로지, 이동성으로 인해 빈번하게 변화하는 토폴로지 환경으로부터 기인한다. IETF ROLL 워킹 그룹에서는 오랜 노력 끝에 저전력 손실 네트워크를 위한 라우팅 프로토콜인 RPL 표준 기술 제정 완료에 이르렀다.
 
RPL은 서로 다른 링크 계층을 지원하여 집/빌딩 및 산업 환경 내에서도 지원이 가능하다. RPL에 의한 노드 간의 연결은 다중 홉 경로를 통해 루트 디바이스의 여러 집합으로 형성되며, 이들은 데이터 수집 및 네트워크 환경 변화에 대한 조정 역할을 수행한다.

라우팅 연결 구성을 위해 링크 비용, 노드 속성 및 상태 정보, 목적 기능들을 고려하여 목적 지향적인 방향성 비순환적인 그래프(DODAG)가 만들어지며, 이는 DODAG ID로 구별된다. 토폴로지 구성은 랭킹 메트릭에 기반하여 이루어지며, 이를 위해 목적 기능(Objective Function)에 의해 각 노드와 참조되는 루트 노드와의 거리에 참조된다. RPL은 서로 다른 트래픽과 시그널링 정보를 아우를 수 있다.

즉, 다중점-대-점(MP2P) 트래픽은 대부분의 저전력 손실 네트워크(LLN) 애플리케이션에서 발생되며, 인터넷 LLN 게이트웨이 혹은 사설 IP 네트워크로의 코어로 전달된다. 이와 반대로, 점-대-다중점(P2MP) 데이터는 DODAG 루트에서 목적지 노드로 메시지를 전달하는 등의 용도로 사용되며, 점-대-점(P2P) 트래픽은 같은 LLN에 속한 두 디바이스 간 데이터 통신을 위해 일반적으로 이용된다. RPL은 MP2P와 P2P 플로우와 P2MP와 P2P 플로우 지원을 위해 상향식 경로와 하향식 경로의 발견이 요구된다.


RPL 토폴로지 형성

RPL 토폴로지의 형성은 단일 DODAG에 의해 하나의 루트를 갖고 만들어질 수 있으며, 복잡하게는 여러 개의 서로 조정되지 않은 DODAG를 이용하여 독립적인 루트들에 의해 만들어질 수 있다. 혹은 단일 DODAG를 포함하나 가상의 루트를 통해 만들어지는 방법이 있다. 세 번째 방식의 장점은 부모 집합 선택에 있어 특별한 제약 사항을 갖지 않는다는 것이다.

이러한 여러 종류의 토폴로지들의 형성은 RPL 정보 전파 메커니즘에 의존하여 노드들의 최소한의 설정만을 할 수 있게끔 하며, 노드들이 자동적으로 동작되도록 하는 기능을 갖는다. DODAG 정보 옵션(DIO) 메시지는 순위 정보와 목적 기능, ID와 같은 정보들을 포함하여 주기마다 각 노드들에 의해 DODAG 형성을 위해 멀티캐스트 방식으로 전달된다.

RPL 프로토콜 상세에 따르면, 네트워크 형성 및 관리 동작을 구현하기 위해서는 모든 노드들은 DIO 메시지를 주고받을 수 있고, 자신들의 순위 정보를 받은 DIO 정보에 기반하여 계산할 수 있어야 하며, DODAG에 가입하고 DODAG 내의 가능한 부모들의 집합을 선택할 수 있어야 한다.

DIO 메시지를 받은 노드는 새로운 DODAG를 가입하거나 기존의 DODAG를 유지 또는 새롭게 가능한 라우팅 루프를 감지하기 위해 해당 정보를 사용한다.
 

RPL 제어 메시지와 매트릭

RPL 제어 메시지는 ICMPv6 패킷 속에 캡슐화된다. 코드 필드는 제어 메시지의 종류를 나타내며, RPL 메시지 헤더를 나타내는 기본 필드가 사용된다.

각 RPL 메시지는 메시지 자체의 통합성과 보호, 비밀성과 지연 특징 등을 제공하는 다양한 안전 방안을 가지고 있다. 네트워크 조건 변화에 따른 토폴로지에 적절하게 적응하는 메트릭과 관련해서, RPL에서는 노드 에너지, 홉 수, 링크 전송률, 지연 시간, 링크 안정성 등을 사용하며, 특별히 링크의 특성을 나타내는 링크 컬러(link color)를 활용, 어떤 경로로부터 특정 링크를 포함시키거나 배제시키는 데 사용된다.
 

목적 기능(Objective Function) 

목적 기능은 RPL에서 주요 메트릭과 제약 사항을 순위 정보로 바꾸는 역할을 담당, 네트워크 토폴로지를 최적화하기 위해 DODAG 루트로부터 노드 간의 거리를 모델링한다.

또한 목적 기능은 DODAG의 선택과 부모 노드로서 DODAG 내의 피어들의 수를 확인할 수 있게 해준다. 목적 기능이 한 노드에서 모든 인터페이스의 스캔을 통해 토폴로지 내의 링크 형성을 위해 적합한지 체크한 후, 모든 후보 이웃 노드들은 해당 노드들이 RPL 라우터로서 동작할 수 있는가를 평가한다.

이러한 예비적인 동작들은 모든 링크들 혹은 기본 목적 기능과의 호환성이 매칭되지 않는 노드들을 효과적으로 배제할 수 있게 한다. IETF에 의해 제안된 목적 기능들의 추가적인 설명은 다음과 같다.


목적 기능

목적 기능은 RPL DIO 헤더 내의 정보만을 요구하며, 노드 순위는 정규화된 스칼라 값, 순위 증가 값을 선호하는 부모 노드의 순위에 추가함으로써 얻어진다.
 

이력을 갖는 최소 순위 목적 기능(Minimum Rank Objective Function with Hysteresis)

RPL 라우팅은 경로 설정 및 유지에 있어 가장 적은 경로 비용을 발견하도록 설계되어 있다. 이를 결정함에 있어 노드는 현재 경로 비용에서 임계치 값을 뺀 값이 새로운 경로 비용보다도 큰 경우 새로운 경로를 선택한다.
 
 

전송 계층과 상위 - IETF CoAP

IPv6 위에서 저전력 손실 네트워크는 NAT와 같은 어떤 기술적 지원 없이도 정보의 전송 및 라우팅이 가능하지만, 인터넷 망과의 완벽한 호환성을 위해서는 각 노드에서 동작하는 애플리케이션 코드로 하여금 적절한 처리의 수행을 요구하는 방식이 있을 수 있다. 또 한편으로는 HTTP와 같이 애플리케이션에 독립적으로 보내고자 하는 콘텐츠의 표현 및 상호 운용성을 가능케 하는 의미를 부여하는 방법이다.

이를 통해 사물 인터넷은 저전력 손실 네트워크가 기존의 애플리케이션에서의 코드 수정없이 상호 운용이 가능하도록 할 수 있다. 다만, 어플리케이션 프로토콜의 메타데이터는 압축 기술을 사용하여 패킷 오버헤드의 최소화를 이루는 과정이 요구된다.
 

저전력 손실 네트워크 위에서 전송

전송 계층은 단-대-단의 신뢰성 있는 인터넷 연결성을 제공하며, 트래픽 제어 및 혼잡 제어의 기능을 담당한다. 저전력 손실 네트워크를 위한 전송 계층 연구로는 많은 양의 제어 패킷을 줄이기 위해 캐싱을 사용하는 경량화된 TCP 구현 방안이 제안되었고, 동일한 목적으로 선택적 ACK를 전송하는 방법이 제시되었다. TCP는 단-대-단의 신뢰성을 담당하며, 이는 많은 에너지 소비를 유도하는 원인으로 작용한다.

이에 반해, UDP를 활용한 전송 방법은 신뢰성이 떨어지나 에너지 비용 면에서 좋은 효과가 있다. 따라서 이러한 특성을 감안하여 최적화하고자 하는 성능을 고려하여 IoT 애플리케이션의 환경의 목적에 부합한 전송 계층 프로토콜 선택이 요구된다.
 

응용 계층

저전력 손실 네트워크 환경에서는 다양한 프로토콜의 사용을 하기에는 맞지 않아 적절한 제한이 필요하며, 인터넷 애플리케이션의 대부분은 웹 인터페이스를 통해 이루어지는 것을 감안할 때 웹에서 지원되는 표현적인 상태 전이 구조(Representational State Transfer Architecture)에 순응하는 애플리케이션 계층의 호환성이 요구된다.

따라서HTTP 그대로는 사용이 어렵고 적응화된 방안이 요구되는데, 이러한 문제에 착안하여 IETF CORE 워킹 그룹은 Constrained RESTful Environments의 약자로 제한적인 환경에서 Restful 구조를 지원하기 위한 프로토콜의 상세 방안을 제한적인 애플리케이션 프로토콜 CoAP이라는 이름으로 정의하고 있다.

CoAP이 제공하는 구체적인 특징은 다음과 같다. HTTP와 CoAP 간의 직접적인 맵핑 혹은 프록시를 사용한 상태를 기억하지 않는 stateless 방식의 HTTP를 정의하며, 신뢰성 있는 유니캐스트, 멀티캐스트를 UDP 프로토콜을 이용하여 지원한다. 또한 중요한 특징으로 비동기 메시지 교환을 수행하며, 적은 헤더 오버헤드로 데이터 전달이 가능하다.
 
CoAP 구조는 2가지 계층으로 다시 나뉘어, 신뢰성 보장을 담당하는 메시지 계층과 요청과 응답에 대한 맵핑을 담당하는 요청/응답 계층이 있다.


메시지 계층

•승인 가능한(Confirmable): 응답을 요구하는 메시지로서, 확인 메시지에 담기거나 비동기 방식으로 전송될 수 있다. 만약 이 메시지가 처리되지 않는 경우에는 리셋 메시지에 전송된다.

•비승인 가능한(Non-Confirmable): 확인이나 응답도 요구되지 않는 메시지에 사용된다.

•확인(Acknowledgment): Confirmable 메시지의 수신을 승인하는 데 사용된다. 이 메시지 또한 Confirmable 메시지에 대한 응답에 함께 담겨 전송될 수 있다.

•리셋(Reset): Confirmable 메시지가 처리되지 않는 경우에 사용된다.


추가적으로, 멀티캐스트 메시지의 경우에는 항상 Non-Confirmable 메시지로만 지원된다.
 

요청/응답 계층

CoAP 요청과 응답은 메소드 코드(method code) 혹은 응답 코드를 포함하여 전달되며, 토큰 옵션이 사용되어 요청 메시지에 대한 응답을 잘 구분하도록 설계하였다.

CoAP은 비신뢰적인 전송 위에서 구현되기 때문에 CoAP 메시지의 도착 순서가 뒤바뀌거나 전송 중간에 손실될 수 있기 때문에 애플리케이션 레벨에서 신뢰성 제공을 위한 방안의 구현이 요구된다. 이러한 신뢰성 제공을 위한 방법으로는 confirmable 메시지를 위한 Exponential back-off 방법을 이용한 stop-and-wait 재전송 방안이 있다.
 

CoAP 프레임

CoAP 메시지는 2진 포맷으로 인코딩되며, 타입-길이-값(TLV) 포맷을 따라 헤더가 고정된 크기를 가지고 만들어진다. 프레임 내에 정의된 필드는 버전, 6.3.1에서 정의된 메시지 타입, 옵션 헤더의 수를 나타내는 옵션 카운트(option count), 메세지의 종류를 나타내는 코드, 요청과 응답 메세지의 매칭을 구분하기 위한 메시지 ID, 옵션, 페이로드 데이터로 구성된다.
 

CoAP 기본 메소드

CoAP에서 제공되는 요청 메소드는 GET, POST, PUT, DELETE가 있으며, 응답 메소드로는 Succ ess, Client Error, Internal Server Error가 정의된다. GET은 요청 URI에 의해 정의되는 자원에 대응한 정보를 가져오기 위한 메소드로 POST도 동일한 목적으로 사용되나, GET은 POST에 비해 안정적인 동작 구현을 지원하고 POST 메소드는 목적하는 자원의 업데이트를 유도한다는 데 차이점이 있다.
 

캐싱과 프록싱

애플리케이션 계층에서 캐싱과 프록싱 수행의 목적은 제한적인 환경에서의 대역폭을 절약하고, 지연 시간을 줄여 전체적으로 저전력 손실 네트워크의 데이터 전달 능력을 향상시키는 데 있다. 캐싱은 응답 용도에 사용되며, 응답 코드에 캐싱이 가능함이 정의된다. 최대-수명(Maximu m-Age) 옵션을 사용하여 얼마 동안 응답 캐쉬가 관리될지를 명시한다. CoAP 프록시는 요청 전달이 잘 이루어질 수 없는 경우 혹은 캐시를 이용하여 응답을 해야 하는 경우에 사용된다.
 

CoAP URIs

CoAP URI는 HTTP URI와 매우 유사한 특징을 갖는다. "coap" URI는 CoAP 자원과 자원들을 위치시키기 위한 방법들을 나타낸다.
 

응용 계층 프로토콜 맵핑

CoAP은 HTTP의 몇몇 기능들이 구현되어 HTTP와 직접적인 맵핑이 가능하다. 또한 CoAP은 세션 초기화 프로토콜인 SIP, 확장 가능한 메세징 및 상태 프로토콜인 XMPP와도 맵핑이 가능하다.

CoAP 맵핑은 CoAP 클라이언트로 하여금 HTTP 서버의 자원에 접근할 수 있도록 하며, 이는 CoAP 요청 메시지에 Proxy-Uri 옵션을 활용하여 "http" URI를 넣고 CoAp-HTTP 프록시로 보내거나 혹은 Proxy-Uri 옵션 없이 CoAP 요청을 CoAP과 HTTP를 맵핑하는 역방향 프록시(reverse proxy)에 전달하는 방법이 있다.

이와는 반대로, HTTP 클라이언트가 CoAP 서버의 자원에 접근할 수 도 있다. 구체적으로는, HTTP 요청 메세지의 Request-Line에 "coap" URI를 넣어서 HTTP-CoAP 프록시에 보내거나 HTTP 요청을 HTTP와 CoAP을 맵핑하는 역방향 프록시에 보내도록 하는 방법이 있다.
 
 

맺음말 

본 분석 자료는 사물들의 인터넷을 위한 핵심적인 표준 요소 기술들을 설명함에 있어 물리 계층, 링크 계층 및 라우팅, 전송, 어플리케이션 계층 등 모든 통신 계층에서의 요구 사항과 그에 대한 표준 상세를 체계적으로 기술하였다.

인터넷의 활용은 과거 정보 접근에서, 현재 인포테인먼트(Infotainment)의 수단을 넘어 다양한 사물들에게까지 연결성 제공을 통한 새로운 가치 창조를 목표로 '사물 인터넷'이라는 이름으로 그 활용의 진화를 계속하고 있다.

사물 인터넷 기술을 위한 확장 및 최적화 기술에 대한 표준은 앞으로도 지속적으로 이루어질 것으로 보이나, 사물 인터넷을 가능케 하는 기본적인 기술은 현재까지 진행되어온 각 계층에서의 표준 기술들이 그 핵심의 근간을 이룰 것으로 예상된다.

현재 사물 인터넷 기술을 이용한 활발한 응용이 산업 및 비즈니스 영역에서 나타나고 있으며, 이를 통한 생산력 향상과 함께 비즈니스 영역의 응용 방안에 대한 새로운 패러다임이 제시되고 있다. 유럽 내 발행된 보고서에 따르면 앞으로의 사물 인터넷 시장은 그 규모가 360억 달러에 이를 것으로 예측됨에 따라 앞으로도 오랫동안 연구 분야를 큰 축을 차지할 것으로 예상된다.
 

 

 


참고문헌

[1] M. R. Palattella, et al. "Standardized Protocol Stack for the Internet of (Important) Things," IEEE Communications Surveys & Tutorials 2013, vol. 15, no. 3, pp. 1389-1406
[2] N. Kushalnagar, G. Montenegro, and C. Schumacher, IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals, RFC 4919, IETF RFC 4919, August 2007.
[3] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J. P. Vasseur, and R. Alexander, RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks, RFC 6550, IETF RFC 6550, March 2012.
[4] Z. Shelby, K. Hartke, C. Bormann, and B. Frank, Constrained Application Protocol (CoAP), IETF CoRE Working Group, February 2011.


이 기사를 공유합니다
저작권자 © 테크월드뉴스 무단전재 및 재배포 금지