Experimental Study of Synchronization Ratio Based on Location Update Interval in Wireless Ad Hoc Networks

무선 애드 혹 네트워크에서 패킷전송주기에 따른 동기화율 성능검증

Abstract

Algorithms for geographical routing and location update attract the researchers' interests in wireless ad hoc networks. Even though many various schemes have been proposed, most of them cause scalability problem in small groups of nodes. To defeat this problem, flooding algorithm is widely utilized due to low complexity. However, there is no previous research work to evaluate flooding algorithm through implementation instead of simulation. In this paper, we present implementation of flooding algorithm on Raspberry Pi and performance evaluation results.

Ⅰ. 서론

무선 애드 혹 네트워크는 기존의 인프라스트럭쳐의 도움 없이 노드들 간의 자율적 구성을 지원하는 네트워크로 재해 상황 및 신속한 네트워크 구축이 필요한 경우에 활용된다. 멀티 홉 통신을 사용하기 때문에 네트워크 토폴로지 관리 및 효율적인 라우팅 프로토콜에 관한 연구가 진행 중이며 최근 위치정보를 무선 애드 혹 네트워크에 적용하기 위한 방안들이 제안되고 있다. 대표적인 기술은 위치정보 기반의 라우팅 기술 [1]과 위치측위 기술 [2]이다.

해당 기술들은 각 노드들의 획득한 위치 정보를 다른 노드들에게 전달하고 이를 활용하므로 각 노드들의 위치정보를 교환하기 위한 방법이 필요하다. 예를 들어 위치정보 기반 라우팅의 경우 목적지의 위치정보가 계속해서 변경되는 경우 데이터 패킷의 원활한 전송을 위해서는 송신자에게 현재 목적지의 변경된 위치가 계속하여 전달되어야만 한다.

각 노드의 위치정보 공유란 특정 노드의 현재 위치를 알아내기 위한 기술로 정의된다. 기존 이동통신의 경우 위치정보 서버에서 각 노드의 위치 정보를 활용하는 방안을 사용하였으나 이동 애드 혹 네트워크에서는 각 노드들의 분산적 동작을 가정하고 있는 동시에 서버까지의 계속적인 경로 유지의 어려움으로 인하여 다른 방안들이 적용되고 있다. 대표적인 방법으로는 Quorum-Based Location Service [3]와 Grid Location Service [4]가 제안되었다. 하지만, 이러한 기술들은 위치 정보 업데이트 및 검색의 통신의 복잡도가 \(O(\sqrt{n})\)이고 구현의 복잡도는 매우 높기 때문은 문제가 있다.

반면, 네트워크의 규모가 작은 경우 앞선 기술보다는 단순 플러딩 메커니즘을 적용하여 각 노드의 위치 정보를 동기화 하는 방식 [5]이 제안되었다. 하지만, 이러한 플러딩 기반 위치 정보 갱신 알고리즘 [6, 7]의 경우 단순히 시뮬레이션을 통한 성능 검증만이 수행되었기 때문에 실제 네트워크에 적용 가능성에 관한 검증이 요구된다. 이는 시뮬레이션을 통한 실험의 경우 [8]에서 설명된 봐와 같이 실제 시스템의 정확한 동작들을 확인하거나 무선 모델의 복잡성을 표현하는데 한계가 있기 때문이다. 대표적 예로는 [9]에서 언급된 “communication grey zone”이다. 그러므로, 시뮬레이션 결과와 더불어 실제 구현을 통한 알고리즘의 검증이 추가로 요구된다.

이러한 요구에 따라 본 논문에서의 플러딩 기반 위치 정보 갱신 알고리즘의 구현을 위한 소프트웨어 구조 및 알고리즘을 제안한다. 제안된 알고리즘은 라즈베리 파이에 탑재하여 업데이트 주기 및 토폴로지 변화에 따른 위치정보 동기화율에 대한 성능을 검증한다.

Ⅱ. 관련연구

위치정보 갱신 알고리즘에 관한 최신연구는 앞서 설명된 기술들을 확장하여 특정 네트워크에 적용시키는데 초점이 맞추어져 있다. 특히, 차량 애드 혹 네트워크에 적용을 위한 연구가 활발하게 이루어지고 있으며 대표적인 연구로는 [10, 11]이 있다. [10]에서는 계층적 지도를 이용하여 지역을 셀과 세그먼트로 나누고 목적지 노드에 대한 위치 정보를 가지고 있는 위치 서버를 검색하는 방안을 제안하였다. [11]에서 제안된 방법의 경우 각 노드는 주기적으로 자신의 위치 정보를 보낸다. 또한, 위치 서버 역할을 수행하는 Road Side Unit (RSU)는 해당 노드의 위치정보를 유지하고 다른 RSU와 공유한다. 하지만, 이러한 방법은 대규모 네트워크에 적합한 방안으로 소규모 네트워크를 위한 메커니즘이 요구된다.

소규모 플러딩 기반 위치 정보 갱신 알고리즘의 기본동작은 그림 1과 같다. 그림에서 알 수 있듯이 각 노드는 정해져 있는 위치 정보 갱신 주기에 따라 자신의 위치 정보를 습득하고 이를 네트워크를 통하여 전송한다. 이 때 목적지 주소는 브로드캐스트 주소를 사용한다. 브로드캐스트 주소를 받은 이웃 노드는 패킷의 시퀀스 번호를 확인하여 이 패킷을 이미 받았는지를 확인한다. 만약 패킷의 시퀀스 번호가 자신의 테이블에 있는 번호에 비하여 같거나 적은 경우 패킷은 이미 받은 것으로 간주되어 버려진다. 그렇지 않으면 패킷의 정보는 노드의 위치 정보 테이블에 저장되는 동시에 해당 패킷은 다시 인터페이스를 통하여 전송된다. 그림 1에서 각 노드들이 전송하는 패킷의 예를 보여주고 있으며 N1이 보낸 패킷을 N2가 받게 되는 경우 위치 정보 테이블의 엔트리가 변경되는 과정을 보여주고 있다.

그림 1. 플러딩 기반 위치 정보 갱신 과정

Fig. 1 Procedure to update location information

제안된 알고리즘과 앞에서 언급한 [3], [4], [11]과의 비교는 표 1과 같다. 표 1과 같이 플러딩 기반의 제안된 기법의 경우 모든 노드의 데이터를 모든 노드에게 전달하는 all-for-all을 지원하며 강건성과 구현복잡도 측면에 강점이 있으나 복잡도 측면에서의 약점으로 인하여 소규모 네트워크에 적합하다.

 표 1. 알고리즘 비교

Table 1. Comparison of algorithms

Ⅲ. 위치 정보 갱신 알고리즘 구현

1. 소프트웨어 구조

제안된 알고리즘의 동작을 위하여 각 노드들은 그림 2와 같은 구조를 가진다. 각 쓰레드에 대한 설명은 표 2와 같다.

 

그림 2. 소프트웨어 구조

Fig. 2 Software architecture

 표 2. 정의된 쓰레드 설명

Table 2. Description of threads

2. 자료 구조

제안된 알고리즘에서 사용된 자료구조는 패킷의 저장을 위한 큐와 위치정보를 관리하는 위치정보 테이블이다. 버퍼는 원형 큐를 사용하여 구성하였으며 이는 모든 쓰레드에서 공유하게 된다. 모든 패킷의 생성 및 수신시 일단 버퍼에 저장되며 버퍼는 FIFO 큐로 운영된다. 데이터 송신 쓰레드에서는 큐의 카운터를 조사하여 만약 이 값이 0보다 큰 경우 맨 앞에 저장되어 있는 패킷을 다시 브로드캐스트한다.

각 노드의 위치정보를 관리하기 위한 위치 테이블의 경우 아래와 같이 정의되며 각 노드의 주소와 시퀀스 번호를 포함하고 있다. 또한, 테이블의 경우 데이터의 검색과 업데이트를 위하여 연결리스트형태로 유지된다.

struct Table {     uint16_t x;     uint16_t y;     uint16_t z;     uint32_t address;     uint32_t sequence; }

각 노드는 플러딩으로 전송된 패킷을 수신한 경우 각 패킷의 정보에 따라 위치정보 테이블을 업데이트 한다. 업데이트를 위한 흐름도는 그림 3과 같다.

그림 3. 위치정보 업데이트 흐름도

Fig. 3 Flow chart for update location information

3. 위치정보 업데이트

그림 3에서 볼 수 있듯이 패킷을 수신한 노드는 해당 패킷이 자신이 보낸 것인지를 확인한다. 이는 패킷의 송신자주소와 자신의 주소를 비교로 이루어진다. 만약 자신의 주소가 아니면 패킷의 송신자주소가 테이블에 존재하는지를 확인하게 된다. 만약 해당되는 엔트리가 존재하는 패킷의 시퀀스 번호를 확인하여 만약 저장되어 있는 시퀀스 번호가 작은 경우 해당 엔트리를 갱신한다. 그렇지 않은 경우 새로운 엔트리가 추가된다.

Ⅳ. 위치정보 업데이트를 위한 플러딩 알고리즘 구현

앞선 설명된 플러딩 알고리즘은 C언어를 이용하여 구현되었으며 패킷 생성, 패킷 수신 및 송신에 관련된 함수들로 구성된다. 알고리즘을 개발 및 테스트를 위한 환경은 그림 4와 같다. 알고리즘 구현 개발 작업은 개발 PC에서 C언어를 사용해 개발됐으며 완성된 소스 코드는 FTP를 통해 테스트 노드들에 전송한다. 테스트 노드들은 gcc 컴파일러를 이용하여 소스코드를 컴파일한다. 플러딩 알고리즘의 동작 확인을 위하여 Wireshark를 사용하였다. 측정된 동기화율 데이터를 모니터링 노드에 전송하기 위한 FTP 서버와 모니터링 노드에서 원격으로 접근 할 수 있도록 SSH 서버를 활용하였다. 모니터링 노드는 SSH를 통해 테스트 노드에 원격 접속하여 플러딩 모듈을 실행한다. 추가적으로 플러딩 실행 중이나 실행이 종료 된 후 모든 테스트 노드들의 패킷 및 네트워크 연결 상태에 대한 데이터를 FTP를 통해 수집한다. 각 노드는 라즈베리파이3 B+를 사용하였고 운영체제는 커널 4.14를 이용하는 라즈비안을 이용하였다.

그림 4. 개발 및 테스트 환경 구성도

Fig. 4 Development and test environment

1. 위치정보를 포함한 패킷 생성

GPS를 통한 위치정보 획득 후 이를 전송하기 위한 함수의 호출은 그림 5와 같다. 먼저 패킷이 생성되면 이를 큐에 삽입한다. 패킷 송신 쓰레드는 공유된 큐를 검사한 후 패킷이 존재하는 경우 이를 소켓을 통하여 전송한다. pkt_generaotor()는 주어진 TIME_INTERVAL에 따라 패킷 생성하고 sleep()함수를 포함한다. 또한, 플러딩에 의한 네트워크 혼잡을 방지하기 위하여 이전의 위치와 현재의 위치의 변화가 작은 경우 패킷을 생성하지 않는다.

그림 5. 패킷 생성을 위한 함수 호출

Fig. 5 Function calls to generate packet

2. 패킷 송신

패킷의 송신은 큐에 패킷이 존재하는 경우 발생하며 초기화된 소켓을 통하여 큐에 있는 패킷을 전송하는 구조로 그림 6과 같다.

그림 6. 패킷 송신을 위한 함수 호출

Fig. 6 Function calls to send packet

3. 패킷 수신

패킷이 수신된 경우 송신과 마찬가지로 초기화된 쓰레드를 통하여 패킷을 수신하고 이를 recv_pkt_hander에게 전송한다. 전송된 위치정보에 대한 업데이트 및 재전송이 수행되며 이를 위한 흐름도는 그림 7과 같다.

그림 7. 패킷 송신을 위한 함수 호출

Fig. 7 Function calls to receive packet

recv_pkt_handler에서는 수신된 패킷의 주소를 확인한 후 테이블을 검색하여 만약 해당 주소의 정보가 존재하는 경우 업데이트하고 그렇지 않은 경우 새로 추가한다. 이를 위한 함수 구현은 다음과 같다.

void recv_pkt_handler(Broadcast_PKT *pkt, ReceiveQu eue *queue, location_table *lt) {       lc_table * target_t = NULL;       if(pkt->orig_addr != inet_addr(inet_ntoa(((struct           sockaddr_in *)&ifr.ifr_addr)->sin_addr)) &&              pkt->orig_addr != inet_addr("0.0.0.0"))      {  ①     target_t = lc_table_find(lt, pkt->orig_addr);            if(target_t != NULL) {                 if(pkt->orig_seqno > target_t->orig_seqno)                {  ②              lc_table_update(lt,target_t,                             pkt->orig_seqno, pkt->lox,                             pkt->loy,pkt->loz);                             EnqueueRecive(queue, pkt)                }            }            else { ③            lc_table_insert(lt, pkt);                 EnqueueRecive(queue, pkt);          }      }  }

해당 코드에서 ①은 먼저 송신자의 IP주소를 이용하여 테이블에서 해당 엔트리가 존재하는지 확인한다. 만약 해당 엔트리가 존재하게 되면 현재의 시퀀스 번호와 테이블의 시퀀스 번호를 비교한다. 만약 현재 패킷의 시퀀스 번호가 더 큰 경우 해당 위치 정보를 테이블에 업데이트하고 다른 노드로의 플러딩을 위하여 큐에 삽입되며 이는 코드 ②와 같다. 만약 테이블에 엔트리가 존재하지 않는 첫 번째 데이터의 경우에는 테이블 업데이트 대신에 삽입이 이루어지고 해당 패킷은 다음 홉으로의 플러딩을 위하여 삽입된다. 이러한 동작은 ③에 구현되었다.

Ⅴ. 성능 검증

구현된 플러딩 알고리즘의 성능 검증을 위하여 두 가지 시나리오를 이용하여 실험하였다. 첫 번째는 세 개 노드의 선형 구조이고 두 번째는 네 개 노드의 메쉬 구조이다.

IEEE 802.11b 무선랜의 전송범위를 150미터 내로 설정하였고 위치 정보 패킷은 2,000개를 생성하였다. 제안된 알고리즘에 사용된 버퍼의 크기는 20개의 패킷들을 저장할 수 있다. 성능 검증은 소켓 버퍼 크기를 변화시키면서 해당 시나리오에서 패킷 전송주기에 따른 동기화율을 측정하였다. 동기화율은 하나의 노드에서 전송된 위치정보가 다른 노드들에게 순서에 맞게 얼마나 정확하게 갱신되었는지를 의미한다. 이를 위하여 각 노드의 위치정보 테이블이 순서대로 정확하게 갱신되는지를 퍼센트로 표시하였다. 만약 자신이 가지고 있는 시퀀스 번호와 패킷의 시퀀스 번호가 연속적이지 않은 경우 동기화가 이루어지지 않은 것으로 판단한다. 소켓 버퍼 크기는 최소 값 (MIN, 2,240바이트), 디폴트 값 (Default, 163,840바이트), 그리고 최대 값 (MAX, 327,680바이트)를 설정하였고 위치정보 업데이트 주기는 0.001, 0.1,  0.5, 1초로 설정하였다.

추가적으로 시뮬레이션과 실제 구현에 따른 성능 차이점을 확인하게 위하여 OPNET Modeler 18.7버전을 사용한 성능평가 결과도 제시하였다. 시뮬레이션에서 버퍼는 네트워크 계층의 송수신 버퍼를 사용하였고 관련 파라미터들은 실제 구현 실험과 동일하게 설정하였다.

1. 실험결과 (실내에서의 세 개의 노드)

세 개의 노드를 이용한 실험환경 구축은 그림 8과 같으며 각 노드간은 선형구조를 가진다. 그림 8의 실험환경에서 중간노드인 N2와 종단노드인 N1에서의 동기화율을 측정하였다. N2노드의 경우 N1과 N3로부터의 패킷의 전달 뿐만 아니라 자신의 패킷 또한 처리되어야 하므로 종단노드와 중간노드를 서로 분리하여 분석하는 것이 적합하다.

그림 8. 세 개의 노드를 이용한 실험환경

Fig. 8 Testbed with three nodes

그림 9와 그림 10의 비교를 통하여 동기화율은 패킷의 업데이트 주기와 매우 밀접한 연관을 가짐을 확인 가능하다. 즉, 매우 짧은 0.01초의 업데이트 경우 중간/종단 노드에서 모두 낮은 동기화율이 측정되었다. 또한, 소켓 버퍼의 크기가 작을수록 보다 낮은 동기화율이 측정되었다. 이는 버퍼의 크기가 패킷의 손실에 영향을 주고 있음을 보여준다. 또한, 패킷의 업데이트 주기가 짧은 경우 버퍼에 의한 패킷 손실이 추가로 발생함으로써 무선 환경에서의 보다 많은 패킷의 손실이 발생하게 되고 결국 동기화율이 낮아진다.

그림 9. 중간노드 (N2)에서의 동기화율 비교

Fig. 9 Comparison of synchronization ratio in the intermediate node (N2)

그림 10. 종단노드 (N1)에서의 동기화율 비교

Fig. 10 Comparison of synchronization ratio in the end node (N1)

반면 패킷 업데이트 주기가 0.1초부터 1초 사이인 경우 주기에 따른 동기화율은 큰 차이가 없으며 중간노드와 종단노드와의 동기화율에서도 같은 현상이 측정되었다. 이러한 결과는 패킷의 손실이 버퍼의 오버플로우보다는 무선 통신으로 인한 충돌에 기인한다. 이는 중간노드에서 데이터의 수신이 완벽하지 않은 경우 플러딩이 이루어지 않기 때문에 중간노드와 종단노드간의 패킷 손실에 의한 동기화율 차이는 별로 없음을 의미한다. 하지만, 패킷의 전송주기가 짧은 경우 중간노드로부터 종단노드까지의 무선 링크상에서도 충돌에 의한 손실이 다수 발생하게 되므로 종단노드는 더 낮은 동기화율을 보인다.

버퍼 크기를 기본으로 설정한 경우 종단 노드 (N1)에서의 시뮬레이션과 실제 구현간의 동기화율 차이는 그림 11과 같다. 그림 11에서 알 수 있듯이 시뮬레이션과 실제 구현을 통한 동기화율은 대략 10%이상의 차이가 있으며 이러한 현상은 1) 전송주기에 보다 민감한 동기화율, 2) 실험보다 높은 동기화율로 요약될 수 있다. 즉, 시뮬레이션의 경우 실제 무선 환경의 변화를 정확하기 반영하지 못하므로 무선충돌에 의한 패킷의 손실은 매우 적다. 이는 패킷의 손실이 대부분 버퍼 오버플로우에 의한 것임을 알 수 있다. 따라서, 버퍼 오버플로우가 발생될 가능성이 적은 상대적으로 긴 1초의 전송주기의 경우 95%상의 동기화율이 측정되었다.

그림 11. 구현과 시뮬레이션에서의 종단노드 (N1)에서 동기화율 비교

Fig. 11 Comparison of synchronization ratio in the end node (N1) between implementation and simulation

2. 실험결과 (실외에서의 4개의 노드)

네 개의 노드를 이용한 시나리오는 메쉬구조로 기존과 달리 중간 노드가 두 개로 확장됨으로써 패킷 손실 시에도 다른 노드를 통한 플러딩이 가능하며 각각의 거리 200미터에서 262미터이다. 또한, 실내에서 다수의 장애물로 인한 가시거리의 확보의 어려움에 따른 성능 저하를 검증하고자 네 개 노드의 경우 개방된 넓은 평지에서 실험을 진행하였다. 토폴로지의 변경에 따른 전송 범위가 늘어난 것으로 제외하고는 다른 파라미터들은 모두 같도록 설정하였다.

그림 12과 그림 13은 개 노드 시나리오에서 버퍼크기 및 위치 정보 업데이트 주기별 동기화율을 보여주고 있다. 이를 통해서 기존의 세 개 노드 시나리오에 비하여 동기화율이 높아짐을 확인가능하다. 이는 앞에서도 설명한 . 바와 같이 패킷의 손실을 메쉬 형태에서는 다른 노드의 플러딩 패킷으로 복구하고 있기 때문이다.

그림 12. 중간노드 (N2)에서의 동기화율 비교

Fig. 12 Comparison of synchronization ratio in the intermediate node (N2)

그림 13. 종단노드 (N3)에서의 동기화율 비교

Fig. 13 Comparison of synchronization ratio in the end node (N3)

또한, 실내 세 개 노드 시나리오와 마찬가지로 버퍼의 크기는 동기화율에 큰 영향을 미치지 않는 반면 위치정보 업데이트 주기가 서로 간의 영향을 미침을 알 수 있다. 이는 무선 충돌이 낮은 동기화율의 가장 큰 원인이기 때문이다. 더욱이, 종단노드의 경우 업데이트 주기가 짧은 경우 동기화율간의 차이가 커지고 있음을 알 수 있다.

마지막으로 앞선 경우와 마찬가지로 중간노드에 비하여 종단노드는 더 높은 동기화율을 유지하고 있음을 알 수 있다. 하지만, 그림 9과 그림 12에서의 알 수 있듯이 중간노드의 경우 네 개 노드 토폴로지에서 좀 더 성능향상이 이루어진 반면 그림 10와 그림 13에서는 큰 차이가 발생하지 않는다. 이는 중간노드에서 종단노드로의 중복적 데이터 전송의 경우 중간노드에서의 중복적 전송에 의하여 충돌이 더욱 발생하기 때문이다.

마지막으로 그림 14는 네 개 노드 시나리오에서의 동기화율 비교 결과를 보여준다. 세 개 노드 시나리오와 마찬가지로 시뮬레이션이 실제 구현보다 더 높은 동기화율을 보였다. 시뮬레이션의 경우와는 달리 구현의 경우에는 전송주기와 동기화율의 특별한 비례관계가 존재하지 않는다. 이는 실제 무선 애드혹 네트워크 환경에서 발생하는 무선 채널 상태 변화가 시뮬레이션 환경에서는 반영되지 않았기 때문이다.

그림 14. 구현과 시뮬레이션에서의 종단노드 (N3)에서 동기화율 비교

Fig. 14 Comparison of synchronization ratio in the end node (N3) between implementation and simulation

3. 실험결과 분석

플러딩의 성능 평가 결과를 살펴보면 앞선 예와 같이 간단한 토폴로지를 설정한 경우 플러딩의 가장 큰 문제로 지적되었던 브로드캐스트 폭풍 (broadcast storm)으로 인한 성능저하는 크게 발견되지 않았다. 이는 패킷의 손실이 대부분 버퍼의 오버플로우가 아닌 무선 네트워크로 발생하며 이는 업데이트 패킷의 수를 결정하는 업데이트 주기와 밀접한 관계가 있음을 알 수 있다. 하지만, 노드의 개수가 늘어남에 따라 무선 충돌뿐만 아니라 버퍼에서의 손실 또한 급격히 증가될 것으로 예상된다.

토폴로지 관점에서 선형구조의 경우 플러딩의 장점인 중복 패킷에 따라 복구 기능을 사용할 수 없었다. 이를 메쉬구조로 변경한 추가적인 실험에서는 선형구조보다는 높은 동기화율을 확인할 수 있었다. 이는 플러딩 알고리즘에 따른 장점이라 할 수 있다.

한편, 기존의 연구결과와의 비교를 통하여 주기가 0.1 ~ 1초 사이로 설정된 경우 [12, 13]에서 언급한 봐와 같이 패킷 손실율에 따른 동기화율이 70~80%를 유지함으로써 구현된 소프트웨어가 시뮬레이션 결과와 비슷한 성능을 유지함을 알 수 있다. 시뮬레이션의 경우 현실적인 무선 환경을 제대로 반영하지 못하기 때문에 전송주기에 따른 트래픽 양에 따른 동기화율 차이가 발생하는 반면 실제 구현에 따른 실험의 경우 무선채널 상태의 변화에 영향을 받게 된다. 특히, 실험중 큐에 존재하는 패킷의 수는 대부분 2개 이하로 라즈베리파이상에서 확인한 프로세싱 및 큐잉 지연이 거의 존재하는 않는 반면 시뮬레이션에서는 이러한 지연이 상대적으로 설정된 값에 의존하게 되므로 이에 따른 패킷 손실이 발생한다.

추가적으로 새로운 위치정보를 정확하게 송신자 노드에게 전달함으로써 위치기반 라우팅 프로토콜의 패킷 전송률을 높일 수 있다. 따라서, 낮은 동기화율에 따른 성능 저하를 방지하기 위한 적절한 전송주기의 선택이 요구되며 동기화율 오류에 따른 위치 예측 및 추가적인 포워딩 기법이 추가적으로 필요하다.

Ⅵ. 결론

본 논문에서는 기존의 위치 정보 업데이트 알고리즘을 대체할 수 있도록 적은 노드수의 애드 혹 네트워크에서 적용 가능한 플러딩 기반 알고리즘을 제안하고 이를 실제 라즈베리 파이에 구현하여 성능을 평가하였다. 위치정보전송주기 및 토폴로지 따른 동기화율이 분석함으로써 성능을 검증하였다.

이 연구와 관련하여 제안된 방법을 기반으로 위치정보 라우팅 프로토콜의 성능 분석에 활용할 예정이다.