Simulation for sensor network packet routing protocols based on distributed-event

2.1 무선센서네트워크 라우팅프로토콜 개발동향

이동성과 편리성이 증대됨에 따라 무선통신기술의 개발은 나날이 가속화되고 있다. 이런 동향에 맞추어 기기의 성능과 사용자의 요구에 따라 여러 가지 기술들이 연구되고 제품에 적용되어 실제생활에 많이 이용되고 있는 상황이다. 이 가운데 유선망을 필요로 하지 않는 수많은 무선 Ad-hoc 멀티홉 라우팅 알고리즘이 연구되고 개발되어 왔다. 이러한 망들은 이동성을 가지며 스스로 망을 구성하고 관리할 수 있는 기술수준까지 도달했다.

반면, 상기한 무선 Ad-hoc망보다 좀 더 많은 제약사항과 특징을 가지는 무선센서네트워크에 적합한 라우팅 알고리즘의 개발은 최근 들어 활발히 진행되고 있는 시점이다. 현재 제안된 알고리즘 중 대표적인 것은 AODV(Ad-hoc On-Demand Distance Vector)[5], DSR(Dynamic Source Routing)[6], DSDV(Destination Sequenced Distance Vector)[7] 및 Direct Diffusion[8]을 들 수 있다. 상기한 알고리즘을 기반으로 무선센서네트워크 환경에 적합하도록 다양한 측면의 연구가 진행되어 오고 있다. AODV와 DSDV는 특정지점으로의 유니케스트 라우팅을 위한 디자인으로 TinyOS에 맞게끔 Intel Oregon에서 구현하였고[9] Direct Diffusion은 UCLA CENS(Center for Embedded Network Sensing)에서 구현하여 Tiny Diffusion 2.0버전으로 공개하고 있다. 이 논문에서는 최근 무선센서네트워크에서 가장 활발한 개발움직임이 진행되는 플랫폼인 UC Berkeley를 중심으로 하는 Mote 하드웨어 플랫폼과 Mote 하드웨어에 포팅이 용이한 TinyOS버전으로 구현된 응용코드인 기본 Surge와 Tiny Diffusion을 이용하여 시뮬레이션 환경을 구축하고 모델을 생성하여 시뮬레이션을 수행하였다.

2.2 센서네트워크 모델링과 시뮬레이션 기술동향

센서네트워크뿐만 아니라 대부분의 산업기술개발에 있어서 그 가치와 효율을 판명하기 위해 많은 노력, 비용 및 시간이 소요됨은 당연하다. 이러한 맹점들을 극복하기 위해 많은 사람들이 현실에 가까운 가상환경을 구축하여 개발하고자 하는 목표기술의 시뮬레이션을 수행하고 직․간접적으로 분석 및 평가하여 개선사항을 도출한 후 현장에 적용한다. 시뮬레이션을 위한 모델링 기술은 상당히 오래전부터 연구되어왔으며 학문적 위치를 갖추고 있다. 이는 현실세계를 수학적으로 변형하여 많은 과학기술개발에 이용되어왔기 때문일 것이다. 이를 토대로 센서네트워크에서의 환경인자나 하드웨어 및 소프트웨어 모델을 추출하여 다양한 방법으로 시뮬레이션을 수행하고 있다. 기존센서네트워크 시뮬레이터의 대부분이 단일 모델을 지원하는 상황에서 다양하고 목적에 맞는 시뮬레이션을 수행하기에는 많은 어려움이 있었다. 그러나 최근 들어 이기종간의 시뮬레이션을 수행할 수 있는 시뮬레이터들이 계속해서 개발되고 있다. TinyOS기반에서 가장 많이 사용되는 시뮬레이터는 TOSSIM이다. TOSSIM은 nesC기반의 언어로 작성된 Mote target코드를 PC상에서 단일네트워크의 인터럽트레벨 분산이벤트기반 시뮬레이션 수행을 가능하게끔 해준다[2][4]. 그러므로 단일기종 또는 단일네트워크 시뮬레이션의 제한을 해결하기 위해 SensorSim, OPNET, OMNET++, J-Sim, Prowler, Em*, EmTOS, TinyViz 등 무선센서네트워크를 위한 시뮬레이션플랫폼 개발이 다양하게 수행되고 있으나, 각각 제한적인 이용으로 폭넓은 응용에 적용하기는 어려운 실정이다[4]. 상기한 여러 제한사항을 해결하면서 확장성이 용이한 시뮬레이터로 조사한 것은 Ptolemy II기반의 VIPTOS이다. 오픈소스기반의 시뮬레이터로 임베디드 시스템개발 플랫폼을 포함한 각종 프로그래밍 언어지원과 다양한 도메인을 내포하고 관련 연구기관이 산재해 있으므로 많은 발전을 거듭해왔으며, 리눅스 형태와 같이 향후 발전 가능성이 높은 플랫폼이다[4].

3.1 시뮬레이션 환경구축

TOSSIM과 VIPTOS를 이용하여 무선센서네트워크 시뮬레이션을 위한 환경을 구축하기 위해서는 기본적으로 UNIX기반의 플랫폼이 필요하다. 기존의 Ptolemy II(version 5.0)는 윈도우즈 기반의 코드를 제공하지만, 새로 개발된 도메인인 VIPTOS(ver-sion 1.0-alpha)는 리눅스환경에서 실행하는 것을 기반으로 개발되었다[4]. VIPTOS를 이용하여 시뮬레이션을 수행하기 위해서는 Ptolemy II(version 6.0-develop)를 설치하고 TinyOS-1.x 최신버전을 설치해야한다. 설치 후 CVS업데이트를 통해 최신버전으로 유지해야 한다. 기본적으로 테스트된 리눅스 커널은 레드헷9 기준의 커널에 TinyOS의 TOSSIM과 VIPTOS 구동환경에 필요한 요소들을 설치하여야 한다. 환경구축 확인은 우선 TOSSIM이 정상동작하는 것을 확인하고 Ptolemy내의 JNI test 프로그램을 구동시켜 이상 유․무를 확인해야 한다. 다만, 현재 제공되는 VIPTOS 시뮬레이션 환경은 개발버전이기 때문에 완벽하게 지원되지 않을 수 있으며, 시뮬레이션 가능범위도 제한적일 수 있다. VIPTOS 개발팀에서도 라우팅 시뮬레이션을 완벽하게 지원하기 위해서 개발 진행 중으로 알려져 있다[4].

3.2 대상 라우팅 프로토콜 분석

3.2.1 Surge 응용의 프로토콜 분석

TinyOS를 이용한 가장 보편적인 응용프로그램인 Surge를 이용하여 기초 시뮬레이션을 수행하고자 하였다. Surge 응용은 기본 센서를 포함한 mote플랫폼에서 수집할 수 있는 센싱정보와 여러 인자를 포함하여 멀티홉라우팅을 구성하고 데이터를 수집하는 좋은 예로 들 수 있다. TinyOS 설치 후 별도의 수정 없이 Surge 응용을 컴파일하면 가장 기초적인 멀티홉라우팅 프로토콜을 이용하여 망을 구성하고 데이터를 송수신한다.

라우팅 방식은 단순 브로드케스트를 이용하여 홉을 결정하고 짧은 거리를 선택하여 망을 형성하는 형태이다. 메시지는 Tos msg를 기반으로Multihop 메시지 내에 Surge, RoutePacket, SurgeCmd와 Ident, Bcast 및 SimpleCmd 메시지를 지원한다. Surge에서 사용하는 멀티홉 라우터의 컴포넌트구조[10]는 Figure 1과 같다.

3.2.2 Tiny Diffusion 프로토콜 분석

Tiny Diffusion은 Direct Diffusion 라우팅 알고리즘을 TinyOS에 구현한 예이다. 모든 플랫폼에 대하여 구현하고 테스트되진 않았다. 현재 실행 가능한 예는 최신버전 Tinyos-1.x 설치경로의 contrib/tinydiff/apps/DiffTest- Nlist 이다. 구현된 프로토콜은 기본적인 Direct Diffusion알고리즘을 따르지만 내부적인 동작 프로토콜은 One Phase Pull방식으로 구현되었다.

Figure 1:

The engine of basic tinyOS multihop

Figure 2:

The engine of one phase pull tiny diffusion router

기본전송 알고리즘은 싱크(Sink)에서 Interest 메시지를 보내면 전송할 데이터가 있는 소스에서 데이터를 플러딩(Flooding)하면서 주변 노드에서 데이터를 포워딩(Forwarding)한다. 이때 경사가 생기면서 싱크에서 Reinforce를 소스측에 전달하면 가장 최적의 경로라고 판단하고 라우팅 테이블에 기록하는 방식이다. 이를 One Phase Pull 방식으로 구현한 컴포넌트 구조는 Figure 2에 나타내었다. 기본 전송방식에서 결정된 한 방향으로 만 데이터경로가 이루어지게끔 개선한 방식이다[11].전송하는 메시지는 Tos msg를 기반으로 Interest와 Data 메시지를 전송한다.

3.3 패킷레벨 시뮬레이션수행

3.3.1 시뮬레이션 모델생성

패킷레벨의 라우팅 시뮬레이션을 위한 Surge와 DiffTestNlist의 VIPTOS모델을 생성하였다. Surge의 경우 생성하는데 아무런 문제가 없었지만, DiffTestNlist의 경우 코드실행 플랫폼의 상이한 문제로 TinyOS와 VIPTOS에서 약간의 코드수정이 필요했다. 아직 현재까지는 VIPTOS와 TOSSIM이 모든 경우의 nesC코드와 플랫폼을 전부 지원할 수는 없고 시뮬레이션을 위한 해당 모델을 이용하여 컴파일 하고 수행하기 때문인 것으로 판단된다. 생성한 Surge의 컴포넌트 연결다이어그램은 Figure 3에 나타내었다. Figure 3을 통하여 생성된 모델은 VIPTOS에서 제공하는 MOML컨버터 유틸을 이용하여 자동생성 되며 nesC로 작성된 기본 코드들을 모두 nc2moml 유틸을 이용하여 <component name>.ncxml과 <component name>.moml 형태로 변환하며 ncc컴파일러로 코드의 이상유무가 점검된다. 이상이 있는 코드는 변환되지 않고 로그에 기록이 남게 되며 이상이 없을 경우 VIPTOS에서 사용가능한 라이브러리로 인식되며 시뮬레이션을 수행하기 위해선 ncapp2moml 유틸을 이용하여 변환하고 과정 또한 ncc컴파일러로 문법과 각기 필요한 컴포넌트 및 라이브러리의 점검이 수행된다.

Figure 3:

The model ofcreated surge simulation

Figure 4는 DiffTestNlist 응용코드를 nesC로 컴파일하여 생성한 컴포넌트 연결다이어그램이다. 전체연결 다이어그램은 방대하고 다른 컴포넌트들에서 사용되는 컴포넌트들로 구성되어 나타내지 않았다. 다이어그램에서 DiffTestNlistM은 가장 상위에서 OnePhasePullM과 연결되어 응용기능을 제공하는 형태이며, Surge와 같은 데이터 수집 등의 기능은 없는 상태이다. 즉, One Phase Pull이 구현된 가장 기본적인 Diffusion 알고리즘 기능을 수행하도록 구성되어 있음을 알 수 있다. 여기서 기존에 삽입되었던 RF Power Control 기능은 VIPTOS에서 아직은 지원이 되지 않으므로 제외하였다.

3.3.2 시뮬레이션 수행 및 결과

수행한 시뮬레이션은 선형 및 망형(Mesh)토폴로지를 대상으로 하였다. 시뮬레이션 시간은 시뮬레이터 자체 clock으로 1000time 동안이며 Time Resolution은 0.1E-6으로 수행하였다. 이는 시뮬레이션을 수행하는 컴퓨터 하드웨어에 독립적인 결과를 도출 할 수 있게끔 하기 위한 판단으로 설정한 것이다.

Figure 4:

The diagram of created DiffTestNlist component wiring

그램 시뮬레이션을 위한 메인프로그램 화면은 Figure 5에 나타내었다. 통신채널은 거리제한이있는 채널을 이용하였다. 거리는 시뮬레이터상 300으로 가운데 RF Signal Range와 일치한다. 즉, 좌표로 노드의 한 가운데서 부터 다른 노드의 한 가운데 좌표까지이다. 그 외에 두 채널은 Sound Source인 큰 원과 Photo Source인 작은 원에서 발생하는 각 신호를 전달하는 채널이다. 각 신호원은 함수를 이용하여 일정한 거리와 괘도를 순환하며 매 초마다 신호를 방출하게끔 구성하였다. 이 외의 제약조건은 설정하지 않았으며, 두 모델 모두 동일한 토폴로지로 시뮬레이션을 수행하였다. Surge응용은 Root를 제외하고 모든 노드가 같은 동작을 수행하고 Root 또한 같은 코드 내에서 아이디 설정만 해주면 Root로 동작하기 때문에 별다른 변경 없이 시뮬레이션을 수행하였으나 DiffTestNlist는 아직 코드가 완전하지 않다고 판단하여 데이터만 전송하는 Mote Model을 추가 생성하여 가장 Root와 먼 거리에 배치하여 진행하였다. 두 응용모두 Ack가 구현되지 않아 RTT측정이나 기타의 성능추출은 어려운 상황이어서 정해진 시간 내에 각기 기본적으로 구현된 Broadcast와 데이터 전송주기를 그대로 사용하여 송신하는 패킷을 분석하였다. Figure 6에 나타낸 노드내부구조와 마찬가지로 패킷의 데이터 분석 및 저장을 위해 각 통신포트에서 전달되는 패킷을 디스플레이 도구를 이용하여 수집하고 텍스트 파일로 저장하였다. 저장한 파일에 대해 Root노드는 수신패킷만 계산하고 그 외 노드들은 송신패킷만 계산하여 전체적인 통신량을 비교하였다. Figure 7의 결과에 나타난 것처럼 기본적인 설정에서 Surge가 당연히 많은 것을 알 수 있으며, 전체적인 노드간 패킷전송 수의 비례는 Surge의 경우 모든 노드가 유사하고 Root가 그 수의 약 2배를 수신하였으나 DiffTestNlist의 경우 4개의 노드는 나머지 노드의 송신량의 1/4 수준에 못 미치는 것으로 파악되었다.

Figure 5:

The Screen ofmesh topology simulation