대세는 CoAP?

Internet of Things 2011.01.31 00:31 Posted by 몽백작


우리가 웹 공간에서 HTTP라는 프로토콜로 데이터를 교환할 수 있는 것처럼 사물 인터넷(Internet of Things) 시대에는 우리 주변의 다양한 사물들도 CoAP(Constrained Application Protocol)이라는 프로토콜을 통해 우리와 소통하게 될 것이다. 그렇다면 왜 HTTP가 아닌 별도의 프로토콜이 필요할까? 그 이유는 바로 그 사물들의 특성 때문이다. 지능형 사물들은 비용상의 문제 또는 설치의 문제 등으로 인해 데스크탑, 랩탑, 혹은 스마트폰에서 주로 쓰는 속도가 굉장히 빠른 이더넷이나 Wi-Fi를 사용하지 않고 보통 값이 저렴한 (IEEE 802.15.4 같은) 무선 통신장치나 잡음이 굉장히 심한 (전력선 통신)같은 유선을 통해 통신하기 때문에 통신이 불안정한 단점이 있다. 또한 사물들은 일반적인 PC, 스마트폰에 비해 굉장히 느리고 메모리도 매우 작은 프로세서를 사용하기 때문에 TCP, HTTP 등은 무거울 수 있다.

이를 극복하기 위한 IETF의 노력은 세 워킹그룹들을 통해서 계속되어 왔다. 링크 계층 바로 위에서 IPv6 계층을 지원하는 6LoWPAN (IPv6 Low-power Wireless Personal Area Networks) 적응 계층과 이웃탐색 프로토콜을 표준화하는 6LoWPAN 워킹그룹, 제한된 환경에서 동작 가능한 IPv6 라우팅 프로토콜을 만드는 ROLL (Routing over Low-power Lossy networks) 워킹그룹, 그리고 가볍게 동작 가능한 RESTful 응용 프로토콜을 준비하는 CoRE (Constrained RESTful Environment) 워킹그룹이 그들이다.


그들 중 6LoWPAN 워킹그룹이 센서네트워크 붐으로 가장 일찍 관심을 받았으며 지난해에는 RPL (IPv6 Routing Protocol for LLNs)을 만든 ROLL 워킹그룹이 가장 많은 활동을 한 그룹이라고 할 수 있다. 하지만 2011년 새해 이후에는 작년에 만들어진 CoRE의 활동이 확연히 두드러진다. 위 스크린샷은 IETF 메일만 모아놓은 내 메일함인데 확실히 CoRE 워킹그룹에서 보내온 메일이 많은 것으로 보아 뜨끈뜨끈함을 알 수 있다.

이는 RPL의 표준화가 거의 마무리 단계에 있기 때문에 ROLL 워킹그룹이 많이 차분해진 탓도 있겠지만, CoRE 워킹그룹에서 지난 주에 CoAP의 새로운 드레프트를 릴리즈하는 등 이유에서 비롯된 것으로 생각된다. 이 정도 관심이면 RPL도 1~2년이 걸렸으니 CoAP 역시 올해 안으로 표준화가 되지 않을까 싶다. 우리나라도 이러한 추세를 지켜보고 새로운 시대를 열 준비를 해야 할 것이다.
신고

WSN을 연구한 2년

Internet of Things 2011.01.05 09:55 Posted by 몽백작

무선 센서 네트워크(Wireless Sensor Networks)라는 분야를 선택하고 공부한지 어느 덧 2년. 시간이 흘러 졸업과 새로운 시작을 동시에 앞둔 지금 2년전 내 선택에 대해서 다시 한번 생각해보게 된다. 나는 무엇을 했는가? WSN은 유망하리라던 내 예상은 옳았는가? 나는 후회하지 않는가? 등등 정리를 하고 넘어가야 새로운 시작을 잘 할 수 있을 것 같다.

WSN은 현재 진행형이다. 더 이상 새롭게 촉망받는 기술도 아니지만 그렇다고 다 죽은, 끝장난 기술도 아니다. 학계 동향이 그동안 어떻게 변해갔는지 간략히 정리해보면 다음과 같다.
  • 2000년 전후, WSN 등장과 함께 전 학계의 관심이 폭발적으로 증가
  • 이후 2006~2007년까지는 MAC 및 라우팅 프로토콜에 집중
  • 2008년 이후 상호운용성(interoperability) 중요성 대두로 IPv6 관심
  • 2009, 2010년 에너지 문제에 USN 적용 시도(스마트그리드) 중
나의 경우 무선 통신과 관련한 연구 주제가 거의 바닥을 보인 2009년에 석사생활을 시작했으니 사실 너무 늦은 시기에 시작하였다. 문제는 내공이 부족한 탓에 너무 늦었다는 것도 너무 늦게 알아버렸다는 점이다. 그래서 조금 고생을 했다. 연구할 주제가 없는 대학원생은 힘들고 서글프다는 점도 알게 되었다.

이런 상태에서 획기적인 전환점이 있었으니, 2009년 늦가을 WSN 분야의 메이저급 학회인 SenSys에 참가할 기회가 생긴 것이다. 그 학회에 다녀온 이후 어설프게 새로운 MAC, 라우팅 프로토콜을 만들어 봐야 완전 획기적이지 않은 이상 아무도 봐주지 않는 쓰잘데기 없는 일이란 걸 알게 되었다.

그래서 그쪽을 포기하고 무엇을 할지 고민고민하다가 손에 붙잡은 것이 IPv6 표준문서이다. 사실 USN에서 IP를 적용해보자는 큰 논의는 2008년 SenSys에서 있었다. 그 여파로 2009년 SenSys와 연합하여 열린 1회 BuildSys 워크샵에서 두어개 논문이 발표되었다. 나의 경우는 거꾸로 BuildSys의 논문 두 편을 보고 2008년 SenSys에서 발표된 Jonathan Hui의 'IP is Dead, Long-Live IP for Wireless Sensor Networks'를 접하게 되었다.

그의 논문의 주 내용은 그 동안 WSN 분야의 틀에 박힌 첫번째 가정인 'severe resource-constrained nodes(몹시 자원이 제한적인 노드들)'에서 IPv6를 가능하도록 만들었다는 것이다. 그의 논문은 단순한 구현 논문 수준에서 벗어나 IPv6 표준을 구현하되 그 동안 학계에서 제안되어 온 WSN 관련 기술들을 함께 적용했다는 데 의미가 있다고 할 수 있다. 또한 타당한 근거들과 함께 '이제 우리 다같이 IPv6를 하자'라고 말하는 듯한 느낌이 있었다. 그 전만 해도 나 역시도 IPv6를 8비트 마이크로컨트롤러에 구현하는 것은 미친 짓이라 여겼다. 설상 가능하다 하더라도 왜 해야 하는지에 대해 이유가 부족했다. 하지만 그 논문이 내 생각을 바꿔 놓았다. IPv6를 하는 이유는 충분했다. 그것은 바로 사람들이 쓰게 하기 위해서 였다.

어차피 딱히 할 일도 없었으니 나도 한번 해보기로 했다. 구현할 운영체제로는 당연히 NanoQplus를 선택했다. 이럴 때 직접 만들 수 있는 운영체제가 있다는 점은 참 행복한 일이다. 만약 직접 다루는 운영체제가 없다면 함부로 구현해야 겠다는 생각을 못했을 것이다. 그런 면에서 대학원으로 UST를 택한 것과 ETRI의 지금 팀에 들어온 것은 참 잘한 일인 것 같다.

의욕에 넘쳐서 덤벼들어서 6LoWPAN 적응 계층과 IPv6, ICMPv6, UDP 까지 작성해서 간단한 1홉 에코 서버, 클라이언트, 그리고 핑 프로그램 등 예제 프로그램을 만들기까지 거의 한 달이 걸렸다. 하지만 그것으로 끝이 아니었다. 인터넷 표준이라는 것은 시시각각 변하기 때문에 IETF의 메일링 리스트를 구독하여 그들의 주고 받는 대화를 항상 따라가야 했다. 새롭게 구현하고, 다듬고, 수정하는 과정을 수없이 반복해야 했다. 한번은 6LoWPAN용 이웃 탐색과 관련하여 IETF 표준화 회의 전후로 방향이 전면 수정되는 일도 있었다. 안타깝게도 거의다 구현을 완료했었는데 눈물을 머금고 갈아 엎어야 했던 기억도 있다.

쉽지 않은 시간이었지만 그 과정에서 국내 학회논문 2편과 해외 학회논문 1편이 나왔다. 나름 괜찮은 소득이었다. 마침내 한 학기가 남은 시점, 학위 논문의 주제는 그 동안 삽질해온 NanoQplus위에 IPv6, 6LoWPAN, 그리고 RPL 등 구현으로 택했다. 여기에 실험과 검증, 개선 등 과정을 통하여 결과를 낼 수 있었고 논문심사를 통과할 수 있었다. 석사 생활 2년중 방황으로 1년, 미친듯 코딩으로 1년을 보냈으니 나름 괜찮게 보낸 것이라 생각이 된다. 따라서 후회가 되진 않는다. 물론 절반을 방황하긴 했지만 그 방황의 시간이 있었기에 괜찮은 주제가 눈에 띄지 않았을까 싶다.

앞으로는 WSN이 어떻게 될까? 외국에서는 아직 발전 가능성이 있다고 하지만 국내에서는 시장이 없다고, 한심한 SI라고 지적한다. 시장은 어떤 기술이 정말 '쓸만해야' 열릴 수 있는 것 아닐까? 그런 면에서 WSN은 아직도 멀었다. 아직 쓸만하지 않다는 이야기다. 쓸만하지 않으니까 정부에서 진행한 시범 사업의 결과가 그저 '시범'의 수준에 머무르는 것이 아닐까? 시범의 수준에만 머무르니 수요가 없고, 수요가 없으니 하드웨어 장비는 비싸기만 하다. 그러니 어디 한 곳에 적용할라 치면 엄청난 비용이 필요하다. 이런 악순환을 깨야 시장이 열리지 않을까?

난 IPv6의 적용이 WSN을 쓸만한 기술로 만드는데 일조한다고 생각한다. 그런 면에서 내가 만든 구현체가 우수한지 우수하지 않은지를 떠나 나름 뿌듯하기는 하다. 다행히 제작년 이후 주목받은 스마트 그리드에서 WSN에 IPv6를 적용하는 것을 기본으로 정의하고 있으니 시간 낭비는 아니었다는 생각이 든다. 그리고 이 일을 한번 끝까지 진행해보고 싶다. 지금 이 생각이 단순히 욕심일까? 글쎄...ㅋ

신고

가장 많이 쓰이는 어플리케이션 프로토콜인 HTTP는 그동안 센서 노드에서 쓰기에는 많이 버거웠다. 아무리 6LoWPAN adaptation layer에서 헤더를 압축하고, 단편화를 해도 TCP위에 올라가는 HTTP는 사실 엄두가 나지 않았다. 물론, 최소한의 기능만을 구현한 가벼운 TCP들도 있긴 있지만, 무거움을 감수하고 구현한 것이고, TCP위의 HTTP는 센서 노드에 맞지 않다. 그래서 인터넷 표준을 만드는 표준화 단체인 IETF에서 새로운 Working Group을 만들었다.

이름하여 CoRE (Constrained RESTful Environments) !!
HTTP처럼 Request, Reply 식의 서비스 방식인 REST의 형태로 센서 노드의 응용 모델을 만드는 것을 목표로 하고 있다..

Zach Shelby가 쓴 드레프트(draft-shelby-core-coap-req-00)에서 CoRE WG에서 만들 CoAP (Constrained Application Protocol)의 요구사항들이 나와 있다.

  1. 제한된 코드 크기와 제한된 메모리 (64~256K flash, 4~12K RAM)하에서 돌아가야 한다.
  2. 프로토콜 오버헤드와 성능이 제한된 네트워크 (예, 6LoWPAN)에 최적화되어야 한다.
  3. 수면중인 노드들을 고려하여야 한다.
  4. 최근의 자원 요청에 대한 캐시를 지원하여야 한다.
  5. 제한된 노드들과 네트워크의 간단한 리소스들을 처리할 수 있어야 한다.
    1. 아키텍쳐는 리소스들을 처리하기 위해 push, pull 그리고 notify 방법들을 요구한다.
    2. CoAP은 장치의 리소스를 생성하고, 읽고, 갱신하고, 삭제할 수 있을 것이다.
  6. 장치에서 어떤 값 또는 이벤트가 이를 구독(subscribe)한 다른 장비로 발행(publish) 될 수 있어야 한다.
  7. CoAP에서 HTTP REST API로의 매핑을 정의하여야 한다.
    1. 특정 어플리케이션의 의존적이지 않을 것.
    2. 표준 프로토콜 응답 / 에러 코드들을 되도록 사용하여, 투명해야 (transparent) 한다.
  8. 장치 설명에 대한 광고(advertise)와 질의(query)를 위해 어떻게 CoAP을 사용할 것인지에 대한 정의가 필요하다.
    1. 장치에 대한 설명은 이름(URL)과 리소스들(URI)의 목록, 그리고 부가적인 이름과 식별자가 될 것.
    2. 이들을 명명하는 것은 다른 IETF 표준들과 일관성을 유지하여야 한다.
  9. 여러 장치들의 리소스들을 동시에 제어하기 위하여 장치들의 그룹에 보낼, 신뢰할 수 없는 (non-reliable) 멀티캐스트를 지원해야 한다.
  10. CoAP 핵심 기능은 UDP 위에서 잘 동작해야 하며, UDP는 CoAP 장치들에 구현되어야 한다.
    1. TCP위에서 큰 데이터 덩어리들의 전송은 옵션이다.
  11. UDP위의 응용 계층 메시지들은 믿을 수 있어야 한다.
  12. 지연 시간은 최소화 되어야 하며, 이상적인 메시지 교환은 하나의 request에 하나의 response 이다.
  13. 인터넷 미디어 타입과 전송 인코딩 타입이 지원되어야 한다.
  14. 프로토콜의 동작에 대한 관리 측면이 고려되어야 하며, 최소한 장치가 전원이 공급되고 있는지 아닌지는 알려주어야 한다.
개인적인 생각으로 정말 위의 요구조건들이 모두 충족되는 CoAP이 나온다면, 6LoWPAN이 지금보다 훨씬 쓸만해지지 않을까 하는 생각을 해본다.
그나저나 이걸로 하루하루 읽어야 할 메일링 리스트가 하나 추가된 셈.^^;;;
저작자 표시 비영리 동일 조건 변경 허락
신고

며칠전 HP Labs가 Internet of Things 기반 구축 사업에 뛰어 들었다는 소식이 나왔다.
이름하여, "Central Nervous System for the Earth (CeNSE)" 직역하면, 지구 중앙 신경 시스템!!

사실 요 근래에 미국, 유럽을 중심으로 계속해서 대두되고 있는 개념이 Internet of Things - 우리말로 사물통신망이다. 무선 센서 네트워크 (Wireless Sensor Networks) 기술들을 기반으로 작은 네트워크 센서 장치들에 IP 프로토콜을 올려 인터넷으로 연결하는 것이다. 어떤 기술이든, 그 기술의 우수성을 떠나서 항상 문제가 되는 것이 '과연 킬러앱 (Killer Application)이 있느냐'인데, 무선 센서 네크워크도 역시 그 질문에 있어서 자유롭게 답을 내릴 수 없었다. 환경 모니터링, 건물 / 시설물 모니터링 등등 다들 이야기하는 응용분야가 제한적이고, '돈'이 안되는 응용이 대부분이었다. 그런데, 그런 무선 센서 네트워크에 인터넷 프로토콜을 올린다면...?

개인적인 생각으로는 이러한 사물통신망이 현재 정체된 무선 센서 네트워크 분야에 할 일을 만들어 주지 않을까 하고 생각해본다. 과거 갇혀있던 센서 네트워크는 잘 갖춰진 인터넷과 만나면 그 가능성은 무궁무진해진다. 분명 어떤 응용이 새롭게 탄생할지도 모르는 것이고, 그 중 우리와 우리가 살고 있는 이 지구에 반드시 필요한 응용이 있을 수 있는 것이니까... 새롭게 등장하는 응용에 따라서 새롭게 요구되는 기술들도 많이 이슈화될 것으로 본다.

그러니... 다음주도... 내 할 일을 열심히 해야겠다. ^-^
저작자 표시
신고

6loWPAN을 공부하려면 당연히 IPv6 환경에서 공부해야 하는데, XP SP2는 기본적으로는 IPv6를 지원하지 않는다. 리눅스를 사용해야 하나 하던 찰나 IPv6 프로토콜을 적용하는 방법이 있어 찾아봤는데, 다음과 같이 설치하면 된다고 한다.

원문 : IPv6 for Microsoft Windows FAQ

Vista나 Server 2008에는 기본적으로 IPv6가 설치되어 있으나 XP SP2 이상에서는 다음과 같이 설치해야 한다. (98, Server 2000은 설치가 불가능하다. Server 2003이나 XP, SP1의 경우는 원문을 참고하기 바란다.)

사용자 삽입 이미지

먼저 네트워크 연결([네트워크 환경]-[속성])에 들어가서 로컬 영역 연결속성을 클릭한다.

사용자 삽입 이미지

설치 버튼을 클릭한다.

사용자 삽입 이미지

네트워크 구성 요소의 유형에서 프로토콜을 선택하고, 추가를 클릭한다.

사용자 삽입 이미지

설치할 네트워크 프로토콜에서 Microsoft TCP/IP version 6를 선택하고, 확인을 클릭한다.
이렇게 하면 일단 설치가 끝난다. 써놓고 보니까 간단하네...;;

사용자 삽입 이미지

커맨드 입력 콘솔에서 netsh interface ipv6 install 을 입력한다. IPv6가 설치되었는지 확인하는 명령어이다. 잘 설치가 되었다면 확인됨 이라고 나온다.

이제 내 컴퓨터의 IPv6 주소를 확인하자.
ipconfig를 치면 다음과 같이 내 컴퓨터의 IPv6 주소를 확인할 수 있다.

사용자 삽입 이미지

신고



 

티스토리 툴바