반응형

FireChat이라는 모바일 앱은 스마트폰들이 블루투스와 Wi-Fi P2P 기술을 이용해서 통신망 인프라스트럭쳐(3G, 4G/LTE, Wi-Fi 액세스 포인트 등) 없이도 서로 연결된 기기들끼리 메세지를 주고받을 수 있게 도와준다.


FireChat은 홍콩에서 한창 시위가 진행될 때 갑자기 유명해졌는데, 그 당시에 좁은 지역에 사람들이 집중적으로 모여들면서 셀룰러 망이 감당할 수 있는 수준을 넘어서면서 통신이 잘 되지 않자 시위대 구성원들 사이에 인프라 없이 서로 통신하기 위해 설치하기 시작하면서 단기간에 50만 다운로드를 기록했다.


Wired 기사 [1]에 의하면, FireChat의 개발사인 OpenGarden에서 필리핀 지역에 메쉬 네트워크를 실현하기 위해 노력하고 있다.


그런데 전통적인 무선 메쉬 네트워크(Wireless Mesh Network; WMN)의 개념에서는 어딘가에 고정적으로 설치되는 메쉬 라우터(mesh router)가 필요하다. 기존의 AP와 비슷하면서 AP들 사이에 무선 링크가 존재하는 것이 차이점이다.

그런데 태풍 때문에 재난상황이 자주 발생한다는 필리핀 도시 지역에 고정된 메쉬 라우터를 설치한다면, 셀룰러 망과 같은 인프라가 망가질 때 메쉬 라우터도 함께 망가질 가능성이 높을 텐데 어떻게 메쉬 네트워크를 구현하는 것일까?


알고 보니, 일부 사람들이 GreenStone이라고 부르는 중개기를 들고 다니면서 메쉬 네트워크를 유지하는 개념이라고 한다.


(GreenStone, image from TechInAsia [2])


GreenStone은 현재 필리핀의 Makati 지역에서 시범적으로 운영되고 있는 듯 하다.


ISM 대역의 블루투스 라디오를 쓰고 주변의 FireChat 앱에서 발생하는 메세지를 모아 뒀다가, 이동하면서 새롭게 연결된 FireChat 사용자들에게 저장된 메세지를 전달하는 역할을 갖는다.

이것은 어떤 의미에서 보면 "지연 허용 네트워크(Delay-tolerant Network; DTN)"에 더 가깝다. 메세지가 마치 물리적인 편지와 같이, 실시간으로 즉시 전달될 수는 없더라도 언젠가 당사자(destination node)를 만나게 되면 비로소 전달되게 하는 기술이다.


홍콩 시위대들이 FireChat을 사용할 때에는 밀집되어 있는 수많은 사용자들이 인프라 없이 메세지를 서로 전달하는 것(일종의 flooding)이 강조되었다면, GreenStone은 밀집되어 있지는 않지만 도시 전역에 퍼져 있는 FireChat 사용자들이 시간이 좀 걸리더라도 서로 메세지를 교환할 수 있도록 하는 데 초점을 맞추고 있다.

DTN 기술은 처음 소개된 이래로 지금까지 꾸준히 연구자들의 주목을 받아 왔지만, 항상 실제로 어디에 쓰이는지에 대해서 의문점이 따라다녔었다. 그런데 필리핀에서 메쉬 네트워크와 DTN이 결합된 듯한 형태로 실제 사용 예가 나타나는 것은 고무적인 일이다.


OpenGarden 사는 통신사의 입장에서는 눈엣가시 같은 존재감을 점점 나타내고 있지만, 사용자들의 입장에서는 안정적인 성능(QoS 같은 것)을 포기하는 대신 무료로 주변과 통신할 수 있는 기회를 제공하는 고마운 대상이 될 수 있다. (항상 그렇다는 것은 아니다. 특히 우리나라처럼 셀룰러 망이 지나치게 잘 되어 있는 곳에서는 굳이 이런 느리고 불안정한 메세징 앱을 쓰려고 하지 않을 테니까.)

하지만 적어도 스마트폰에 기본적으로 내장된 ISM 대역의 라디오 기술을 이용해서, 가끔 통신망 인프라 없이 직접 무선 라디오를 가지고 필요한 사람들과 통신이 가능하게 해 주는 것은 중/장기적으로 사용자에게 좋은 영향을 끼칠 수 있다.


분명히 내 눈앞에 있는 전자기기가 내 스마트폰과 마찬가지로 와이파이/블루투스를 내장하고 있는데, 그냥 서로 직접 얘기하게 만들어서 원하는 일을 할 수는 없을까? 이 질문에 대한 여러 해답 중의 하나가 OpenGarden의 사례가 될 것으로 기대한다.




<참고자료>

[1] https://www.wired.com/2015/10/giant-network-for-free-messaging/

[2] https://www.techinasia.com/firechat-messaging-app-disaster-tool




반응형
블로그 이미지

Bryan_

,
반응형

OS: Ubuntu 14.04 (amd64)

ns-3 version: 3.26



ns-3를 설치하는 과정에서 Visualizer (PyViz)도 활성화시키려면 python 관련 패키지들 몇개를 미리 설치해야 하는데, ns-3 공식 안내 페이지 [1]에 나온 대로 설치를 시도하면 python-gnomedesktop 패키지를 설치할 수 없다고 나온다.


$ sudo apt-get install python-dev python-pygraphviz python-kiwi python-pygoocanvas python-gnome2 python-gnomedesktop python-rsvg

Reading package lists... Done

Building dependency tree       

Reading state information... Done

E: Unable to locate package python-gnomedesktop



python-gnomedesktop 대신 python-gnome2-desktop-dev 를 설치하면 된다.


$ sudo apt-get install python-dev python-pygraphviz python-kiwi python-pygoocanvas python-gnome2 python-gnome2-desktop-dev python-rsvg



<참고자료>

[1] PyViz, https://www.nsnam.org/wiki/PyViz 

[2] http://stackoverflow.com/questions/36252495/unable-to-locate-package-python-gnomedesktop-installing-pyviz-in-ns3




반응형
블로그 이미지

Bryan_

,
반응형

라우팅 프로토콜에 대한 논문은 오래 전부터 지금까지 다양한 분야에 대해서 무지 많이 쏟아져 나오고 있고, 그 중에서 유난히 읽기 쉬우면서 성능도 괜찮은 논문들도 있고, 반면에 복잡한 수학적 개념을 적용한 어려운 논문들도 있다.


내가 target으로 보고 있는 환경이 무선 네트워크(특히 와이파이) 쪽인데, 이 쪽으로도 90년대 후반부터 라우팅 관련 논문이 매일같이 쏟아져 나오고 있다.

처음에는 AODV나 DSR처럼 간단명료한 구조와 변화무쌍한 환경에 대한 적응이 가능한 모바일 애드혹 네트워크(MANET) 라우팅 프로토콜 논문들과 그 파생 논문들을 보면서 놀랐던 기억이 있다. 왜냐하면 딱 들어맞지는 않더라도 "Simple is the best"를 잘 보여주는 프로토콜이었기 때문이다.

이어서 여러 개의 무선 네트워크 인터페이스를 쓰는 multi-radio routing protocol에서도 이렇게 간단하면서 준수한 성능을 보여 주는 기존의 single-radio routing 분야에 있는 DSR이나 AODV를 기반으로 해서 확장한 논문들이 인기가 많았던 것도 볼 수 있었다. (인용이 엄청났으니까)


이 때까지만 해도 나는 라우팅 프로토콜에 굳이 수학이 들어가지 않아도 간단한 프로토콜 구조만 잘 만들면 되는 줄로 크게 착각했었음을 이제서야 알게 되었다. 사실은 그렇게 간단한 최단경로 라우팅 프로토콜에서 각 노드가 맡는 역할이 그저 프로그래밍 차원에서 역할과 메세지 교환 로직만 구현해서 되는 것이 아니고, 그래프 이론에서 먼저 개념을 정립한 뒤에 프로그래밍 요구사항으로 도출된 것으로 봐야 한다.


시간이 지나면서 단순히 최단 경로(shortest path)를 찾는 것으로 응용 프로그램의 요구를 만족시킬 수 없는 경우를 해결하기 위해서 hop count가 아닌 다른 링크 품질(link quality metric)을 적용하는 사례가 생겨났다. 예를 들어, 그래프 형태로 보면 모든 링크는 단순히 임의의 두 노드 사이에 연결된 하나의 엣지(edge)이지만, 자세히 보면 패킷 전송 속도나 대역폭, 패킷이 유실될 확률과 같은 세부 특성이 다른 것이다.


앞서 언급한 잘 만들어진 간단한 구조의 유명한 라우팅 프로토콜들은 모두 hop count 기반이었고, 이것을 그외의 다른 링크 품질로 대체하기 시작하면서, 거의 대부분의 논문이 더 복잡한 수학이 되는 것을 볼 수 있었다. 결국 복잡한 수학적 표현은 불가피한 것인데, 나는 나도 모르게 속으로 "Simple is the best"를 엉뚱하게 적용하며 라우팅 프로토콜에서 쓰이는 복잡한 (사실 공부해 보면 인공지능 같은 요즘의 트렌드에 비하면 복잡한 것도 아니다) 수학을 기피해 왔었던 것 같다.


그리고 내가 해결하고자 하는 상황은 더이상 single-radio network도 아니고, hop count만 쓸 수도 없고, 응용 프로그램도 다양하기 때문에 라우팅 프로토콜을 프로그래밍 관점에서만 바라보고 간단하게 해 보려는 생각을 버려야 하겠다.

비록 응용 계층에서 작동하면서 커널 계층의 도구들을 활용하는 식으로 구현하기는 했지만, 실제로 라우팅 프로토콜을 바닥부터 설계하고 구현해 보니 수학적인 기반을 갖지 않고서는 실제로 라우팅 프로토콜이 경로 하나를 발견하는 데 필요한 여러 가지 의사결정 과정을 구현하는 가이드라인이 없어진다는 것도 알 수 있었다.


많이 늦어지긴 했고 비록 수학을 좋아하지는 않지만, 이제 와서 수학을 기피하면 학교를 그만두는 것이나 마찬가지이기에, 그리고 문제 상황을 수학적으로 모델링하는 연습을 지금 해 두지 않으면 나중에도 내가 내 문제를 주도적으로 해결할 수 없을 것이기 때문에 힘들지만 열심히 복잡한 수학적 개념을 "잘" 적용한 좋은 학회/저널 논문들을 다시 공부해야겠다.


반응형
블로그 이미지

Bryan_

,