Ⅰ. 서 론
네트워크 시뮬레이터는 크게 오픈소스 기반의 NS-3[1]와 상용 소프트웨어인 Riverbed Modeler(舊 OPNET Modeler)[2]가 널리 이용된다. NS-3와 Riverbed Modeler 모두 패킷 수준의 이산 사건 시뮬레이터(Discrete Event Simulator)이기 때문에 복잡한 통신 프로토콜과 대규모의 네트워크를 설계하기에 적합하다. 그 중 Riverbed Modeler의 경우, 실제 상용 제품의 상당수가 Model 라이브러리로 제공이 되기 때문에 실환경을 모의하기에 보다 용이한 특징을 가지고 있다. 또한, Riverbed Modeler는 네트워크 각 계층의 프로토콜 및 각종 동작을 스테이트 다이어그램(state diagram)을 기반으로 직관적으로 모델링 할 수 있기 때문에, 네트워크 시뮬레이터로서 신뢰성을 인정받고 있다. 따라서, 우리나라뿐만 아니라 미국 등 여러 나라의 금융 네트워크[3], 물인터넷[4], 국방 무기 체계[5] 통신 분야의 모델링, 네트워크의 설계 및 성능 분석에 광범위하게 활용되고 있다.
Riverbed Modeler에서의 MANET(Mobile Ad-Hoc Network) 라우팅 프로토콜은 IP 계층 프로세서의 한 종류인 manet_mgr 프로세서에 의해 관리되어 구현된다. 따라서, 라우팅 프로토콜의 인식 및 처리하는 부분은 IP 계층 프로세서 및 IP 관련 외부 소스 파일과 깊게 얽혀 있다. 이러한 조건 하에서 새로운 라우팅 프로토콜을 구현하여 추가하거나 기존의 라우팅 프로토콜을 수정하는 작업은 관련된 모든 부분을 식별하여 새 프로토콜에 맞게 추가 및 변경해 주어야 한다. 이러한 작업은 Riverbed Modeler 사용에 익숙하지 않은 사용자로 하여금 누락이나 잘못된 수정으로 인한 전체 라우팅 프로토콜의 이상 동작을 초래할 수 있다. 해당 문제점을 극복하기 위하여, 기존의 라우팅 프로세서를 기반으로 최소한으로 내부 동작을 변형하고 차이점을 추가하는 방법들이 제안되었다.[6-8] 하지만, 이 방법들 역시 기존의 라우팅 프로세서를 활용하기 때문에 사용자가 프로세서의 상당 부분을 이해하여야 이용이 가능한 실정이다.
본 논문에서는 이러한 라우팅 프로토콜 추가의 실무적 어려움을 제한적이나마 TDMA(Time Division Multiple Access) 기반 하에서 줄일 수 있는 MANET 라우팅 프로토콜 프레임을 제공한다. 제공하는 TDMA 기반의 MANET 라우팅 프로토콜 프레임워크는 TDMA 기반에 한정되어 있지만 Riverbed Modeler의 복잡한 IP 계층의 프로세서 및 외부 소스 파일을 완전히 배제하고 순수 제안하는 라우팅 프로토콜만을 이산 사건 시뮬레이팅하기 위한 최적의 환경을 뒷받침한다. 제안하는 라우팅 프로토콜이 IP 계층을 통해 타 네트워크와 연결되어 이에 따른 성능분석이 필요한 것이 아니라면 Riverbed Modeler의 복잡한 IP 계층 프로세서 및 외부 소스 파일을 이용할 필요는 없다. 제공하는 라우팅 프로토콜 프레임워크는 응용 패킷이 생성/파괴 되는 상위 단부터 최종 송/수신이 이루어지는 PHY 계층까지 구현이 되어 있고 MAC 계층의 최소한의 추가/수정과 필요한 패킷 구조의 수정으로 새로운 라우팅 프로토콜을 모의해볼 수 있도록 지원하며, 기존 Riverbed 모듈을 활용한 라우팅 프로토콜의 추가/수정 과정의 실수에서 발생할 수 있는 오류를 줄여 주는데 큰 역할을 할 수 있다.
논문의 구성은 다음과 같다. 2장에서는 구현된 라우팅 프로토콜 프레임워크와 시뮬레이터의 특성에 대하여 살펴보고, 3장에서는 제안하는 프레임워크와 Riverbed 내 내장된 프레임워크의 차이점을 분석한다. 4장에서는 제안하는 프레임워크를 실제 예제를 통하여 검증해 본다. 마지막 5장에서 본 논문의 결론을 맺는다.
Ⅱ. 시뮬레이터 구성
2.1 통신 프레임 구조
제안하는 라우팅 프로토콜 프레임은 TDMA기반의 MANET을 구현하기 위해 제어 슬롯과 데이터 슬롯으로 구분되는 시간 프레임 구조를 제공한다. 프레임의 길이는 망이 적용될 환경(채널 변화 주기, 최대 홉수 등)을 반영하여 결정할 수 있다. 결정된 프레임 길이에서 선두는 제어 슬롯을 위해 고정되며 노드의 총 개수만큼 할당된다. N개의 노드가 존재하면 프레임의 선두에는 N개의 제어 슬롯이 할당된다(그림 1). 제어 슬롯의 길이의 결정은 제어 패킷에 담길 정보의 양과 PHY 계층의 설계와 관련이 있다. 제어 패킷은 일반적으로 안정적인 전송을 위해 가장 낮은 MCS level로 전송이 된다. 프레임의 나머지 구간은 데이터 패킷을 위해 할당이 되며 총 M개의 데이터 슬롯이 할당될 수 있다. 데이터 슬롯은 실제 데이터 트래픽이 전달되는 슬롯이고 자원할당 정보에 따라 MCS level을 가변하여 이용된다.
통신 프레임 구조 (Communication frame structure.)
제어 패킷에는 망의 토폴로지 정보, 자원할당 정보, 전역 채널품질 정보가 실리게 된다. 망의 토폴로지 정보와 자원할당 정보는 NC(Network Controller) 역할을 수행하는 노드가 계산하여 최초로 제어 패킷에 실어 전파를 하고 그 외의 노드들은 해당 내용을 복사하여 자신의 제어 패킷에 실어 전파한다. 각 노드가 동일한 전역 채널품질 정보를 통해 동일한 망의 토폴로지 및 자원할당 정보를 구할 수 있지만, 망의 동기화 및 계산 부하를 줄이기 위해 NC가 계산하여 전파하는 방식을 취하도록 했다. 전역 채널품질 정보는 각 노드들이 인접한 이웃 노드들의 제어 패킷을 우선 수신하여 이웃 채널품질 정보를 획득한 뒤 이를 제어 패킷의 전역 채널품질 정보의 일부에 갱신하여 연속적으로 전송하는 방식으로 완성된다. 수 프레임이 지나면 NC는 모든 노드들의 이웃 채널 품질이 기록된 전역 채널 품질 정보를 획득할 수 있다. 노드들의 이동성이 큰 환경이면, NC가 전역 채널 품질 정보를 획득하는 시간과 현재 채널 품질 정보 사이에 이격이 발생할 수 있다. 따라서, 채널 정보 교환이 빠르게 이루어지기 위해 적절한 프레임 길이의 설계가 필요하다.
2.2 노드의 설계
설계한 Riverbed Modeler의 노드 종류는 단일 노드(Node.nd)로 구성된다. 바꿔말하면, 시뮬레이션을 위해 생성되는 모든 노드는 동일한 Node.nd를 통해 생성된다. 노드의 이름을 MSx, BSx 등으로 설정하면 해당 노드의 세 번째부터 오는 x 숫자를 자신의 index로 인식하게 설계하였다. 그리고, 만약 자신의 index가 0이면 NC로 동작하고 나머지는 일반 노드로 동작한다. 노드가 NC로 동작할 경우, 망의 토폴로지와 자원할당을 계산하여 전파하는 역할을 수행한다. 일반 노드는 NC로부터 전파된 망의 토폴로지와 자원할당을 이용하여 데이터를 송/수신한다.
Node.nd의 Processor 구성은 상위부터 APP_Main.ps, Intra_Main.ps, Intra_Control.ps, MAC_Main.ps, MAC_Control.ps, PHY_Main.ps, Transmitter.ps, Receiver.ps, Antenna.ps로 총 9개로 구성된다 (그림 2).
Node.nd의 Processor 다이어그램 (Processor diagram of Node.nd)
2.2.1 APP_Main Processor
APP_Main.ps는 데이터 패킷의 생성/송신 및 수신/파괴와 통신 성능 분석(패킷의 지연시간, 패킷의 손실률)의 기능을 갖는다. 생성된 데이터 패킷은 APP Header를 붙여 APP_PDU 패킷으로 Intra_Main.ps로 전달 된다. APP Header는 AppCode, AppSour, AppDest, quality of service(QoS), sequence number(SN), length로 구성된다. AppCode는 총 2 bit로 구성되며 음성, 전문, 위치, 영상을 구분한다. AppSour와 AppDest은 총 12 bit로 각 위치의 bit는 노드 index를 의미한다. 예를 들어, AppSour=0001 0000 0000은 8번 노드가 송신자라는 의미이고 AppDest=0000 0000 1111은 0, 1, 2, 3번 노드가 수신자라는 뜻이다. QoS는 총 2 bit로 해당 트래픽의 우선 순위를 나타낸다. 그리고, 수신된 데이터 패킷은 총 2 bytes의 SN을 통해 정렬하여 복원한다. length는 헤더 뒤의 payload의 길이를 의미하여 총 2 bytes를 차지한다.
2.2.2 Intra_Main Processor
Intra_main.ps의 경우, 크게 3가지의 역할을 하는 프로세서이다. 첫 번째로 MAC_Main으로부터 전달되는 Intra_PDU 패킷을 분류한다. Intra_PDU를해석하여 제어 패킷이 수신되었을 경우, 이를 INTRA_CONTROL 내부 패킷으로 변환하여 Intra_Control.ps에 전달한다. 반면에, 데이터 패킷이 수신되었고, App_PDU 헤더의 AppSour, AppDest의 해석을 통해 이것이 본 수신 노드의 데이터 패킷이면 Intra_PDU의 Header를 제거하여 APP_Main.ps로 올려 최종 수신/파괴를 수행하게 한다, 예를 들어, AppSour에 1번 노드가 있고 AppDest에 2번 노드가 있을 때, 수신노드가 2번 이면 최종 수신하는 식이다. 중계해야 할 패킷으로 판단하기 위해서는 Intra PDU 헤더의 TxNode와 RxNode 필드도 같이 보아야 한다. 예를들어, AppSour에 1번 노드가 있고 AppDest에 4번노드가 있을 때 수신노드가 3번이라고 가정하자. 이때, 수신노드가 가진 토폴로지 정보를 통해서 자신의 부모 노드가 Intra_PDU 헤더의 TxNode와 같고, RxNode가 자신이라면, TxNode를 자신의 숫자로 고치고 AppDest 2번에 전달이 가능한 토폴로지 내 다음 중계노드를 RxNode에 기입하여 MAC_Main.ps에 전달하여 다음 중계를 이어가는 방식이다. 둘째, Intra_Control.ps로부터 제어 메시지의 해석결과(토폴로지)가 수신되면 이를 기반으로 중계를 위한 내부 테이블 업데이트를 수행한다. 앞서, 중계를 판단할 때 사용한 토폴로지가 이것이다. 마지막으로, Intra_Control.ps로부터 생성된 제어 패킷을 전달 받을 경우 이를 MAC_Main.ps에 넘기는 역할을 수행한다.
2.2.3 MAC_Main Processor
MAC_Main.ps은 Intra_Main.ps로부터 전달되는 패킷을 각 종류에 맞는 큐에 저장을 한 뒤, 현 송신하려는 채널의 품질에 따라 AMC(Adaptive Modulation and Coding)를 이용하여, MCS Level을 조절하고 이에 맞게 MAC_PDU를 생성하여 PHY_Main.ps에 전달하는 역할을 수행한다. MAC_PDU의 길이는 PHY의 구현에 의존한다. OFDM Symbol의 개수와 carrier 주파수의 개수 등에 의해 한 슬롯 당 보낼 수 있는 데이터량을 구할 수 있다. 예를 들어, Symbol당 50 bytes를 보내도록 설계가 되어 있고, 슬롯당 5개의 symbol이 존재하면 총 250 bytes의 MAC_PDU를 생성할 수 있다. MAC 헤더의 길이 20 bytes를 제외한다면, 총 230 bytes를 실을 수 있고, 이 230 bytes를 채우기 위해, 각 데이터의 큐를 우선순위로 조회한다. 데이터의 우선 순위가 음성>전문>위치>영상이라면 먼저 음성 큐에서 Intra_PDU를 꺼내어 sub MAC header를 붙여 MAC_PDU의 payload에 넣는다. 위의 우선 순위로 payload를 채우다가, 꺼낸 Intra_PDU의 크기가 payload의 남은 공간을 넘어설 경우, fragmentation을 수행한다. sub MAC 헤더의 길이를 제외한 보낼 수 있는 만큼만 잘라서 MAC_PDU를 최종 완성하고 패킷의 나머지 부분은 해당 데이터 큐의 선두에 재삽입된다. fragmentation 된 정보는 sub MAC 헤더에 입력된다. 본 패킷이 fragmentation 된 몇 번째 패킷인지, 혹은 마지막 패킷인지가, frag_ID와 frag_end에 표시되어 수신단에서는 이를 통해 fragmentation 된 패킷들을 모아 본 패킷을 복원할 수 있다. 복원된 패킷은 Intra_Main.ps에 전달된다. MAC_Main.ps가 MAC_PDU 패킷을 PHY_Main.ps에 전달하는 시점은 MAC_Control.ps의 MAC_Control 패킷을 통해서 이뤄진다. MAC_Control.ps는 제어 패킷을 통해 공유된 자원할당 정보를 토대로 현 프레임 내 데이터 슬롯의 송신 노드가 무엇인지, MCS 레벨이 어떤 것인지 판별할 수 있고, 본 노드가 송신 노드라면 MAC_PDU 패킷을 생성하여 PHY_Main.ps에 전달하여 송신한다. 반면, 자신이 송신 노드가 아니라면 PHY_Main에 MCS 레벨만을 전달하여 PHY_Main의 MCS 레벨 조절을 통해 타 노드로부터 전송되는 패킷을 수신할 수 있도록 한다. 이외에도, PHY_Main.ps으로부터 PHY_AMC 패킷으로 보고되는, 본 노드를 수신점으로 하는 각 노드들과의 채널 품질 (SNR dB값)을 MAC_Control.ps을 통해 MAC_Report의 형태로 Intra_Control.ps로 전달한다. Intra_Control.ps는 측정된 채널 품질 정보를 토대로 제어 패킷의 전역 채널 품질 정보를 완성한다.
2.2.4 PHY_Main Processor
PHY_Main.ps는송신할MAC_PDU를PHY_PDU로 변환하여 Transmitter.ps를 통해 송신하거나 PHY_PDU를 수신하여 MAC_PDU로 전환하여 MAC_Main.ps로 전달한다. 또한, Receiver.ps로 부터오는 SNR 측정 통계 정보를 토대로 채널의 품질을 PHY_AMC 패킷으로 전달한다.
2.2.5 Intra_Control Processor
Intra_Control.ps는 제어 패킷의 생성을 담당한다. 제어 패킷에는 토폴로지 정보와 자원할당 정보가 담기는데 NC가 이를 계산하여 방송하기 위해서는, 각 노드가 하위단으로부터 전달받은 MAC_Report 패킷의 채널 품질 정보를 이용한다. MAC_Report 패킷을 통해 본 노드의 주변 노드들과의 채널 품질 정보를 파악하고, 타 노드로부터 전송된 제어 패킷으로부터 그 외 노드들 기준의 채널 품질 정보를 파악할 수 있다. 제어 패킷의 전역 채널 품질 정보에, 본 노드의 최근 채널 품질 정보만을 업데이트하여 업데이트된 채널의 SN만을 증가시켜 재전송하면, 이러한 절차가 각 노드에서 반복되어 수행되고 난 뒤 NC 노드는 전역 채널 품질 정보를 획득할 수 있게 된다. 이를 통해, 토폴로지와 자원할당을 계산하는 방법은 다양하다. 본 논문에서는 토폴로지와 자원할당의 방법을 제안하지는 않는다. 계산된 토폴로지는 각 노드의 부모 노드가 무엇인지를 제어 패킷에 기입하여 전달된다. 자원할당 정보는 앞서 언급했듯이 각 데이터 슬롯의 송신 노드가 무엇인지, 그리고 해당 슬롯의 송신 MCS 레벨은 어떤 것 인지를 테이블의 형태로 만들어 제어 패킷을 통해 전달한다.
2.2.6 MAC_Control Processor
NC가 아닌 노드들은 제어 패킷을 통해 토폴로지와 자원할당 정보를 전달받고 이를 MAC_Control.ps로 인터럽트 테이블을 전달한다 (INTRA_INTERRUPT 패킷). MAC_Control.ps는 해당 테이블을 토대로 프레임 내 데이터 슬롯의 타이밍(인터럽트)가 오면 MAC_Main에 MAC_Control 패킷을 보내어 해당 타이밍에 송/수신을 가능토록 한다.
2.2.7 Transmitter/Receiver/Antenna Processor
Transmitter.ps와 Receiver.ps는 송/수신기 관련 특징을 품은 processor로써, noise figure channel(data rate, bandwidth, frequency, processing gain), modulation, margin 등 Riverbed가 지원하는 일반적인 송수신 변수들을 설정할 수 있다.
Antenna.ps는 Riverbed가 지원하는 기본 processor로써 다양한 안테나 패턴과 오리엔테이션을 설정하는 processor이다.
2.2.8 Header Files
전체 시뮬레이션의 변수와 결과를 관리하기 위해 헤더 파일들을 두고 이를 각 프로세서의 모듈에서 include하는 것이 편리하다. 본 프레임워크에서는 전체 시뮬레이터의 시스템 파라미터를 관장하는 Environments.h을 두어, 디버깅을 위한 모니터링용 LOG를 on/off할 수 있는 파라미터를 설정할 수 있도록 하고, 전체 노드의 개수 및 다중 트래픽의 모델링, 프레임의 길이 및 심볼 길이, 헤더 사이즈, MCS 비트 심볼사이즈 등을 설정할 수 있도록 하였다. 또한 각 트래픽의 송신 및 수신 노드 설정도 가능하도록 하였다. 나머지 하나인, Variable.h에서는 결과 도시와 관련된 전역 변수들을 선언하였다.
Ⅲ. Riverbed 내장 MANET 프레임워크와의 비교
제안하는 MANET 프레임워크와 Riverbed 내 기존 MANET 프레임워크의 차이를 비교하여 표 1에 나타내었다. Riverbed 내에서 제공하는 MANET 프레임워크는 총 16개의 프로세서들로 구성이 되고 전체 코드의 길이를 합산하면 약 20만 줄에 육박한다. 이중 IP 프로토콜과 관련된 프로세서들이 약 15만 줄로 큰 비율을 차지하며, 해당 프레임워크의 모든 연결관계를 모두 파악하여 추가/수정하기 어려운 실정이다. 개발한 라우팅 알고리즘을 구현하여 테스트를 할 때, 타 상위 장치들과의 IP 프로토콜 기반 데이터 교환을 가정하지 않는다면, IP 프로토콜 관련 프로세서들은 고려하지 않아도 된다. 제안하는 프레임워크는 사용자 설계 트래픽 모드, TDMA 기반 자원 할당 구조, 제어 패킷, 데이터 패킷, AMC 등을 모두 지원할 수 있고 상대적으로 구현에 필요한 코드의 수가 짧아 개발한 라우팅 알고리즘을 추가/수정하여 시뮬레이션하기 보다 용이하다.
제안 MANET 프레임워크와 기존 MANET 프레임워크의 비교 (Comparison between a proposed MANET framework and a built-in MANET framework)
Ⅳ. 시뮬레이터 수행 예제 결과
제안하는 MANET 프레임워크의 정상 동작을 확인하기 위하여 예제를 산정하여 시뮬레이션을 수행하였다. 시뮬레이션을 위해 총 12개의 노드를 그림 3과 같이 배치하였다. 해당 배치에서 0번 노드와 1번 노드, 1번 노드와 2 번 노드의 간격은 1 km로 하였고, 2번 노드와 3~11번 노드의 간격은 1 km에 180도 범위 내에서 3~11번 노드를 상호 등간격으로 설정하였다. 각 노드의 전송 전력은 27 dBm이고 채널의 경로 손실 모델로는 Okumura-Hata suburban 모델을 사용하였다. 신호의 중심 주파수는 2.4 Ghz이고 대역폭 4MHz로 송수신하며, 제어 슬롯 하나당 총 10개의 OFDM 심볼, 데이터 슬롯 하나당 총 12개의 OFDM 심볼을 배치하였다. 심볼 하나당 데이터량은 표 2과 같고 프레임의 자세한 설계는 표 3에 요약하였다. 해당 값들은 Environments.h 에 저장한다. MCS 레벨에는 QPSK 1/2, 16QAM 1/2, 64QAM 1/2, 64QAM 2/3, 64QAM 5/6의 SNR vs BER 커브가 적용되었다.
(그림 4)의 Topology List가 생성된 실제 토폴로지 (Topology based on topology list of Fig. 4)
데이터 트래픽으로는 음성, 전문, 위치, 영상 총 4가지를 산정하였으며, 음성은 25 ms를 주기로 40Bytes 길의 패킷이, 위치은 15 bytes씩 1 s 마다 생성이 되도록 하였다. 영상은 33 ms 마다 1000~1500bytes씩 균등한 확률 분포로 패킷을 발생시켰다. 전문의 경우는, 평균을 60 s로 갖는 exponential 랜덤변수로 발생 주기를 설정하였고, 한 주기 간격당 500bytes의 패킷이 발생하도록 하였다. 그밖에, tree 구조의 라우팅 알고리즘 형성으로는 다익스트라 알고리즘을 사용하였다. 각 데이터 슬롯 별 송신 노드와 트래픽 종류의 할당 방법은 예제의 편의를 위해 임의 선택 되어지도록 하였다. 사용자는 해당 함수를 수정하여, 제안하는 라우팅 및 자원할당 알고리즘을 모의해볼 수 있으며, 필요하다면 제공하는 패킷의 헤더를 수정하여 함수에 필요한 정보를 확장할 수 있다.
MCS 레벨 별 OFDM 심볼당 데이터량 (MCS level v.s. data size per OFDM symbol)
시뮬레이션 완료 후 결과는 Text로 확인할 수 있도록 하였으며, Riverbed 내의 시뮬레이션 콘솔창을 통해서도 이를 확인할 수 있다. Text 파일 또한 생성되며 결과 파일이 생성되는 경로와 파일 이름은 APP_Main.ps 내의 Show_Result state 내에서 수정이 가능하도록 하였다.
Simulation Console 내 전역 채널 품질 정보 디스플레이 (노드 0) (Global channel state information display (Node 0) in the simulation console)
그림 4에 노드 0이 지니고 있는 전역 채널 품질 정보를 표시하였다. 세로 행은 송신 노드 가로 열은 수신 노드를 나타낸다. 총 12 x 12로 각 링크간 채널의 품질을 SNR dB scale로 표기한다. 다만, 여기서 dB값이 음수값(-)가 나오지 않는 이유는 채널 품질을 측정하는 방식 때문이다. Riverbed 내 Receiver.ps는 공중을 통해 전송되는 패킷을 패킷으로 인식하기 위한 최소 SNR 크기를 요구한다. 이 값이 현재 0이 되도록 설정되었기 때문에 실제 SNR이 음수값인 패킷도 Receiver.ps에 입력은 되나 무시가 되기 때문에, 채널 측정 값으로 PHY_Main.ps로 전송이 되지않고 전역 채널 품질 정보 내 최소 값이 0으로 표시되는 것이다.
시뮬레이션 콘솔 내 토폴로지와 자원할당 정보 (노드 0) (Topology and resource allocation information display (Node 0) in the simulation console)
그림 5에는 노드 0이 가지고 있는 토폴로지와 자원 할당 정보의 결과가 표시되어있다. Topology List 하단의 12개의 숫자는 각각 노드 0~11의 부모 노드의 숫자를 의미한다. 여기서 숫자 100은 부모 노드가 존재하지 않고 해당 노드가 본 토폴로지의 Root(NC)라는 뜻으로 사용된다. 다익스트라 알고리즘을 통해, 그림 5의 채널 하에서 현재 노드 0은 NC, 노드 1은 노드 0에, 노드 2은 노드 1에, 나머지 노드들은 노드 2에 연결된 토폴로가 형성된 것을 확인할 수 있다 (그림 3). Frame Allocation(자원할당 정보)은 각 슬롯의 용도(Beacon, Voice, Video), 송신노드 및 MCS level로 자원할당 정보를 표시한다. 총 12+78=90개의 슬롯이 존재하고 선두 12개는 제어 패킷으로 각 노드에 MCS로 할당된 것을 확인할 수 있다. 그 다음에는 데이터 슬롯들이 할당이 되고 있는데 송신 노드와 전송 트래픽은 임의로 선택 되어지고 송신 MCS 레벨은 모두 1로 통일된 것을 볼 수 있다. 노드가 움직이지 않아 해당 토폴로지가 변하지 않는다면 노드들은 해당 자원 할당 정보만을 이용해 자신의 데이터를 송신한다.
시뮬레이션 결과 파일 최하단부에는 데이터 트래픽 종류별 성능지표가 표기된다. 그림 6에서는 이를 일부분 발췌했다. 영상 트래픽의 성능지표를 먼저 확인을 할 수 있는데, 송신 노드가 9이고 이를 수신한 노드들이 열로 구분되어 있으며, 몇 개의 패킷을 받았는지에 따라서 패킷 전송 성공률(1-패킷 전송 손실률)과 지연시간(최대, 최소, 평균)의 통계가 행으로 나타나있다. 하단으로 스크롤을 내리면 위치, 음성, 전문 순으로 동일한 성능지표를 확인할 수 있다. 지연시간의 경우, APP_Main.ps로 패킷이 수신이 되면, 해당 패킷을 열어 오리지날 APP 트래픽 패킷을 복원한 뒤 이를 완료한 시간과 해당 패킷이 생성된 시간을 빼 계산을 하고 이를 variable.h내 전역 변수(rx_delay)에 모두 저장하여 평균과 최대, 최소를 구한 것이다. 해당 성능 지표는 제공하는 프레임워크에서 기본적으로 구현한 것이고, APP_Main.ps과 variable.h의 수정을 통해 관찰하고자 하는 성능지표를 확장할 수 있다.
트래픽 속성 별 성능 지표 (Performance metric for each traffic)
Ⅴ. 결 론
본 논문에서는 Riverbed Modeler의 라우팅 알고리즘을 추가/수정하기 힘든 점을 극복하기 위해 수정이 용이한 TDMA 기반의 라우팅 프로토콜 프레임워크를 제안하였다. 제안하는 라우팅 프로토콜 프레임워크는 IP 프로토콜 등 타프로세서와 연관되는 프로세서 없이 설계/개발되었기 때문에 새로운 라우팅 프로토콜을 최소한의 수정으로 추가하여 성능분석 모의할 수 있도록 구성되었다. 라우팅 프로토콜 프레임워크를 이용하여 라우팅 프로토콜을 수정하는 경우, 수정해야 하는 부분은 라우팅 알고리즘과 일부 패킷의 헤더 정보 뿐이다. 본 논문에서는 프레임워크의 구조에 대한 상세한 설명을 통해 이용자들이 추가/수정을 쉽도록 하였으며, 또한 다익스트라 라우팅 프로토콜을 제안한 프레임워크를 이용하여 구현하여, 기본적인 성능지표들을 얻어 라우팅 프로토콜 프레임워크가 타당하게 설계 되었음을 확인하였다. 본 라우팅 프레임워크를 이용하여 추후 라우팅 프로토콜 시뮬레이션에 이용하면 개발기간을 크게 단축시킬 수 있을 것으로 기대된다.