네트워크 시뮬레이션 공방

32비트 윈도우에서 Visual Studio 2008을 컴파일러로 사용하기 위한 환경 변수 설정. (OPNET 14.5 PL0 버전부터
Visual Studio 2008을 지원한다)

DevEnvDir=C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE

Framework35Version=v3.5

FrameworkDir=C:\WINDOWS\Microsoft.NET\Framework

FrameworkVersion=v2.0.50727

INCLUDE=
C:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\INCLUDE;
C:\Program Files\Microsoft Visual Studio 9.0\VC\INCLUDE;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include;

LIB=
C:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;
C:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\lib;

LIBPATH=
C:\WINDOWS\Microsoft.NET\Framework\v3.5;
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;
C:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;
C:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;

PATH=
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE;
C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN;
C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools;
C:\WINDOWS\Microsoft.NET\Framework\v3.5;
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;
C:\Program Files\Microsoft Visual Studio 9.0\VC\VCPackages;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin;

VCINSTALLDIR=
C:\Program Files\Microsoft Visual Studio 9.0\VC

VS90COMNTOOLS=
C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\

VSINSTALLDIR=
C:\Program Files\Microsoft Visual Studio 9.0

WindowsSdkDir=
C:\Program Files\Microsoft SDKs\Windows\v6.0A\

단말의 수가 많은 세그먼트에서 실제 네트워크 구성시, 이더넷 허브를 데이지 체인(daisy chain) 형태로 연결하여 사용하는 경우가 있다. 즉, 허브에 허브를 연결하여 연결 가능한 포트수를 늘리는 것으로, 허브의 포트수가 부족한 경우에 많은 포트수를 가지는 새로운 장비를 구입할 필요없이 기존의 허브를 활용하여 문제를 해결할 수 있으므로, 상당히 유용한 방법이며 종종 사용된다.
이러한 구성이 OPNET에서도 가능할까? 아쉽게도 이렇게 허브를 연속적으로 연결하는 구성은 OPNET에서 지원되지 않는다. 즉, OPNET의 이더넷 허브 모델은 자신이 다른 허브와 직접 연결되지 않는다고 가정하고 만들어졌기 때문에, 허브에 허브를 연결하고 시뮬레이션을 수행하면 다음과 같은 에러 메시지를 보여주고 시뮬레이션이 중단된다.

인터넷망에서 사용자가 경험하는 서비스 품질은 백그라운드 트래픽(해당 사용자에 의해서 발생되는 패킷이외의 패킷들)에 의해서 많은 영향을 받는다. 즉, 동일한 망에서 서비스를 받는 경우에도 해당 경로상에 존재하는 백그라운드 트래픽의 양에 따라 사용자가 경험하는 서비스 품질이 달라지는 것이다. OPNET에서는 이러한 백그라운 트래픽을 간단하게 설정할 수 있는 몇 가지 방법을 제공하고 있는데, 그 중 한가지가 링크의 "Traffic Load" 속성을 이용하는 것이다. 이 속성을 이용하면 백그라운드 트래픽을 매우 쉽게 설정할 수 있을 뿐만 아니라, 시뮬레이션 수행시간에는 거의 영향을 미치지 않으면서 큰 백그라운드 트래픽에 의한 영향을 살펴볼 수 있다.
백그라운드 트래픽이 시뮬레이션 결과에 어떤 영향을 미치는지 예제를 통해 살펴보도록 하자. 사용할 예제망의 토폴로지는 다음과 같으며, Calling_1 노드와 Called_party 노드간에는 "Voice over IP Call (PCM Quality)" 어플리케이션을 설정해 주었다.

따라서, 소스코드와 Statistics 항목의 설명에서 명확하게 알 수 있듯이, 여기에서 variance가 의미하는 것은 일반적인 뜻인 '변화량'이 아니라 통계에서 사용하는 '분산'인 것이다.

다음으로 Jitter의 (OPNET에서 사용하는 있는) 정의는 다음과 같다.
"If two consequetive packets leave the source node with time stamps t1 & t2 and are played back at the destination node at time t3 & t4, then:
jitter = (t4 - t3) - (t2 - t1)
Negative jitter indicates that the time difference between the packets at the destination node was less than that at the source node."
실제로 jitter 값은 gna_voice_called_mgr (또는 gna_voice_calling_mgr) 프로세스 모델에서 계산되는데, 해당 코드는 다음과 같다.
-------------------------------------------------------------------------------------
/* Compute the jitter */
jitter = (op_sim_time () - prev_pk_info_ptr->play_back_time) - (rtp_pk_info_ptr->time_stamp - prev_pk_info_ptr->time_stamp);
-------------------------------------------------------------------------------------

Statistic 항목의 설명과 동일하게 jitter = (현재시간 - 이전 패킷의 수신시간) - (패킷을 송신한 시간 - 이전 패킷을 송신한 시간)으로 계산되고 있음을 확인할 수 있다. 즉, Jitter는 연속된 두 패킷에서 송신 노드에서 보내질 때의 시간 간격과 수신노드에 도착할 때의 시간 간격의 차이를 의미하는 것이다.

시뮬레이션 결과를 살펴보면 다음과 같이 전혀 다른 값이 기록되어 있는 것을 확인할 수 있으며, 그 이유는 앞에서 설명한 것처럼 서로 계산하는 방식이 전혀 다르기 때문이다.

시뮬레이션을 하다보면, 노드의 위치정보를 사용해야하는 경우가 종종 발생한다. 특히, 무선망이나 이동성을 시험하는 경우에는 필수적이다. OPNET에서 노드의 위치정보를 획득할 수 있는 수단은 두가지이다.
1. op_ima_obj_pos_get(site_objid, lat_ptr, long_ptr, alt_ptr, x_ptr, y_ptr, z_ptr) 함수를 통해 지구중심좌표계(geocentric coordinate system) 상의 값을 구하는 방법.
2. op_ima_obj_attr_get_dbl(objid, attr_name, value_ptr) 함수를 통해 "x position"과 "y position" 값, 즉 평면상에서의 2D 좌표를 구하는 방법.

2번 방안의 경우 화면상의 표시와 쉽게 매칭되기 때문에, 이해하기 쉽다. 하지만, x/y 좌표를 구하기 위해서는 함수를 2번 호출해야한다는 번거로움(?)이 있다. 1번 방안의 경우 한번의 호출로 모든 좌표정보를 알아낼 수 있으며, 좀 더 멋있어(?) 보인다는 장점도 있다.
그런데, 1번 방안을 통해 알아낸 좌표값을 사용할 경우, latitude / longitude / altitude는 표현 자체가 완전히 다르므로 헷갈릴 일이 없지만, 뒷 부분의 x/y/z 좌표값을 혼동의 여지가 있으므로 사용에 주의할 필요가 있는데 여기에서 말하는 x/y/z 좌표값은 지표면을 기준으로 하는 값이 아니라는 점이다. 즉, 1번 방안을 통해 알아낸 x/y 좌표값과, 2번 방안을 통해 알아낸 x/y 좌표값은 서로 완전히 다른다. 그러므로, 사용하고자 하는 목적에 따라 두 방법 중 적절한 방법을 선택해서 사용해야만 한다.
일반적으로 1번 방안은 특정 서브네트워크에 대해서 지구상에서의 위치를 파악할 때 사용되고, 2번 방안은 서브네트워크안에서 노드들 사이의 (우리가 흔히 생각하는) 거리를 계산할 때 사용된다. 두 방안의 x/y 좌표값을 혼동해서 사용할 경우, 예상치 못한 엉뚱한 결과가 나올 수도 있으므로 주의할 필요가 있다.

지난 연말(2009년 12월)에 Modeler 16.0.A 버전이 발표되었습니다. 요즘은 새롭게 추가되는 모델 feature에 큰 관심이 없던터라 바로 살펴보지는 않았었는데, 티스토리 블로그 오픈(?)을 기념하여 한번 살펴봅니다. 먼저, User forum에 올라온 주요 특징은 다음의 사항들입니다.

- New WiMAX model features
- Enhancements to the LTE model, including eNodeB uplink scheduler and enriched set of LTE statistics
- Support for modeling vendor-specific HAIPE device behavior in the HAIPE model


WiMAX나 LTE는 요즘 많은 관심을 받고있는 분야이니까 반가운 소식이기는 한데, 이 정보만으로는 뭐가 개선되었는지 알수가 없네요. Release note에서 관련된 항목들을 다시 살펴보았습니다. 먼저 WiMAX 모델,
- Partial Usage of Subchannels (PUSC)
- Multiple Input/Multiple Outout (MIMO)
- 802.16j
- IPv6 for WiMAX
- MAP over PHY support
- UL Burst Transmission delay

꽤나 의미있는 개선이 이루어진 것 같습니다. PUSC는 관심 사항이 아니라 패스. MIMO는 기존에 DL STC 2x1만 지원되던 것이 DL/UL STC 2x2까지로 확장되었네요. 그외에 receive diversity 1x2도 지원된다는데 이건 정확히 무엇을 의미하는 건지 애매하네요. 나중에 코드를 살펴봐야 할듯.
802.16j가 벌써 지원된다길래 내심 놀랐는데, 역시나 아직까지 기능상에 제약이 많네요. Centralized 모드에서 UL 링크에 대한 transparent operating만 지원된다고 합니다. 802.16j 기능이 구현되고 있다는 정도를 아는 선에서 만족해야할 듯.
IPv6 for WiMAX는 상당히 유용한 업데이트네요. WiMAX모델에서 IPv6가 동작하지 않는다는 사실은 그동안 아는 분들은 다 아시는 버그(?)였는데, 이제서야 고쳐진 모양입니다.
MAP over PHY는 이번 WiMAX 모델 업데이트에서 제일 중요한 사항일 것 같습니다. 그동안 OPNET WiMAX 모델의 치명적인 단점으로 늘 공격받던 사항이니까요. 많이 늦은 감이 있지만, 다행입니다.
UL burst transmission delay도 상당히 어이없던 모델 설계상의 문제였는데 이번 수정에 반영되었네요. UL MAP 에서 grant해준 resource는 실제로는 다음번 frame에 대한 것이니까요. 그래도 자존심이 있는지 무조건 한 프레임 뒤에 반영되도록 하지 않고, parameter로 변경가능하게만 해놨네요.

다음으로 LTE 모델,
- Increased data rates and high efficiency
- Increased signal range
- Increased spectrum flexibility
- Interoperability with legacy networks

이 설명만 보고는 여전히 어떤 사항들이 개선되었는지 구체적으로 파악할 수가 없네요. 어쩔 수 없이 소스 코드를 살펴봐야할 듯.

이외에도 여러가지 수정된 사항이 있지만, 특별히 관심가는 내용이 없어서 생략합니다.