OPNET은 2005년부터 WiMAX (IEEE802.16e) 모델을 개발하여 제공하기 시작하였으며, 최근까지 지속적으로 업데이트해왔다(OPNET Modeler 16.0 PL4 발표). 초창기의 OPNET WiMAX 모델은 제공되지 않는 기능도 많았고, 실제 시스템의 특성을 제대로 반영하지 못하는 부분들이 많아서 실무에 사용하기에는 어려움이 많았다. 하지만, 그 동안의 지속적인 업데이트를 통해 이제는 쓸만한(?) WiMAX 모델을 제공하고 있다. 물론, 16e의 경우 현재는 장비 개발이 거의 끝나버려서 시기적으로 너무 늦어버린 느낌이 있지만 말이다.
"OPNET 중급입문"에서도 언급한 바 있듯이, WiBro는 기술적으로 802.16e Mobile WiMAX의 서브셋으로 볼 수 있으므로 OPNET WiMAX 모델의 파라메터를 조정하면 WiBro의 기능도 대부분 시뮬레이션이 가능하다. 여기에서는 OPNET WiMAX 모델의 구조와 특성을 살펴보고, IEEE802.16e 표준을 잘 반영하고 있는지 분석해보고자 한다. (상당히 긴 연재물이 될 것으로 예상된다.)
먼저, 현재의 OPNET 최신 버전(16.0 PL6)에서 제공하는 WiMAX 모델의 대표적인 기능은 다음과 같다.

MAC
 - IP convergence sub-layer (classifiers)
 - Per service flow state (queues)
 - ARQ
 - Bandwidth request and allocation
 - Framing
 - Ranging
 - Mobility, Scanning and Handover
 - Link Adaptation
 - Power Management
 - HARQ
 - MMR(802.16j)
PHY
 - TDD
 - OFDMA(DL-FUSC/PUSC, UL-PUSC), SOFDMA
 - Path loss
 - Co-channel interference
 - Multi-path fading
 - MIMO (STC)

OPNET 모델에서 TDD를 PHY 기능으로 분류해야 하는지는 애매한 측면이 있다. TDD를 가능하게 하는 주요 요소는 Frame 구성과 전송 timing 인데, OPNET 모델에서 이 기능들은 모두 MAC 프로세스 모델에서 구현되기 때문이다. 하지만, 일반적으로 TDD를 PHY 기능으로 볼 때가 많으며 OPNET사에서도 PHY 기능으로 분류하고 있기때문에
여기에서도 PHY 기능으로 분류하였다.
HARQ는 일반적으로 1.5계층 기능으로 분류되고, OPNET 모델에서도 MAC 프로세스 모델과 파이프라인 스테이지에 분산되어 구현되므로 정확히 어느 계층의 기능이라고 분류하기는 어렵다. 개인적으로는 OPNET 모델에서 HARQ 기능의 주요한 부분은 파이프라인 스테이지에서 더 많이 수행된다고 보지만, OPNET사에서는 MAC 기능으로 분류하고 있기 때문에 여기에서도 MAC 기능으로 분류하였다.
각 항목 기능들의 세세한 특징은 이후의 포스트에서 하나씩 살펴보기로 하겠다.

Posted by 신상헌
,
Custom Application을 사용할 때, Task 설정 단계에서의 REQ/RESP와 결과확인창의 Requesting/Responding의 관계가 혼란스러울 때가 있다. 이들 간의 관계를 명확하게 파악하지 못하면, 정상적으로 수행된 시뮬레이션에 문제가 있다고 판단하거나 정상적으로 수행되지 못한 시뮬레이션에 문제가 없는 것으로 판단 할 수가 있기때문에 주의가 필요하다.
다음 그림과 같이 Client와 Server 노드로 이루어진 네트워크를 예로 들어 살펴보자.

Task Config를 이용하여 Custom Application을 설정하는데, 먼저 Source 노드에서 Destination 노드로 1,000Bytes 크기의 패킷을 1sec마다 전송하도록 하고, 이 패킷들에 대한 응답으로 500Bytes 크기의 패킷을 Destination 노드에서 Source 노드로 전송하도록 다음 그림과 같이 설정한다. (이를 1번 Custom Traffic으로 부르자) 만들어진 Custom Traffic Profile을 Client 노드에 적용해주고, Dest으로 Server 노드를 지정해 준다.

결과 수집항목 설정창에서 "Requesting Custom Application" 항목과 "Responding Custom Application" 항목을 모두 선택하고 시뮬레이션을 수행한 후 살펴보면, 다음 그림과 같이 Client 노드에는 "Requesting Custom Application" 항목 결과만이, 그리고 Server 노드에는 "Responding Custom Application" 항목 결과만이 수집되어 있는 것을 볼 수 있다.

Client 노드의 "Requesting Custom Application" 아래에 속한 "Traffic Sent(bytes/sec)" 항목과 "Traffic Received(bytes/sec)" 항목의 결과를 살펴보면 다음 그림과 같다. 즉, Task Config에서 Source로 지정되어 있는 노드에서는 "REQ/RESP Pattern"에 해당하는 트래픽이 모두 "Requesting Custom Application" 결과로 보여지는 것이다.

다음으로 Source 노드에서 Destination 노드로 1,000Bytes 크기의 패킷을 한번 전송하도록 하고(일종의 서비스 요청이라고 볼 수 있다), 이 패킷에 대한 응답으로 1,000Bytes 크기의 패킷을 1초마다 Destination 노드에서 Source 노드로 전송하도록 다음 그림과 같이 설정한다. (이를 2번 Custom Traffic으로 부르자)
만들어진 Custom Traffic Profile을 Client 노드에 적용해주고, Dest으로 Server 노드를 지정해 준다.

이제 다시 시뮬레이션을 수행한 후 살펴보면, 다음 그림과 같이 Client 노드와 Server 노드에 모두 "Requesting Custom Application" 항목 결과와 "Responding Custom Application" 항목 결과가 수집되어 있는 것을 볼 수 있다.

Client 노드의 "Requesting Custom Application" 아래에 속한 "Traffic Sent(bytes/sec)" 항목과 "Responding Custom Application" 아래에 속한 "Traffic Received(bytes/sec)" 항목의 결과를 살펴보면 다음 그림과 같다. 즉, Task COnfig에서 Source로 지정되어 있는 노드에서는 설정된 트래픽이 "Requesting Custom Application" 결과로 보여지며, Destination으로 지정되어 있는 노드에서는 설정된 트래픽이 "Responding Custom Application으로 보여진다.

결론적으로 요약하자면,
1) 해당 트래픽이 Task Config에서 REQ(Source->Dest Traffic)에 해당하는지 RESP(Dest->Source Traffic)에 해당하는지의 여부와 상관없이 Source로 지정되어 있는 노드에서는 설정된 트래픽이 모두 "Requesting Custom Application" 결과로 보여지며, Destination으로 지정되어 있는 노드에서는 "Respoding Custom Application"결과로 보여진다.
2) "Requesting Custom Application" 또는 "Responding Custom Application" 아래에서 "Traffic Sent(bytes/sec)"로 표현될지 "Traffic Received(bytes/sec)"로 표현될지의 여부는 REQ에 해당하는 설정인지 RESP에 해당하는 설정인지에 따라 결정된다.
Posted by 신상헌
,

32비트 버전 OPNET의 경우 2GBytes 이상의 메모리를 사용할 수 없기 때문에 대규모 망을 시뮬레이션할 때 문제가 발생할 수도 있다. 물론 이는 OPNET의 문제가 아니라 하나의 어플리케이션은 최대 2GBytes까지의 메모리만 (가상 메모리를 포함하더라도) 사용할 수 있도록 허용하는 32비트 윈도우의 문제이다.
따라서, 2GBytes 이상의 메모리가 요구되는 대규모망을 시뮬레이션할 때에는 64비트 OS상에서 64비트 버전의 OPNET을 사용해야 한다.
64비트 윈도우에서 Visual Studio 2008을 컴파일러로 사용하기 위한 환경 변수 설정은 다음과 같다.

Framework35Version=v3.5

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

FrameworkVersion=v2.0.50727

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

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

LIBPATH=
C:\WINDOWS\Microsoft.NET\Framework64\v3.5;
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB\amd64;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\LIB\amd64;

Path=
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64;
C:\WINDOWS\Microsoft.NET\Framework64\v3.5;
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\VCPackages;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\x64;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin

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

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

VSINSTALLDIR=
C:\Program Files (x86)\Microsoft Visual Studio 9.0

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


그런데, 64비트 컴파일러를 설치하기 위해서는 다음 그림과 같이 Visual Studio 2008 설치 과정에서 x64 옵션을 선택해주어야만 한다. 그렇지 않으면, 64비트 윈도우 환경이라 할지라도 64비트 컴파일러가 설치되지 않아서 64비트로 컴파일이 이루어지지 않는 문제가 발생한다. (이 문제의 원인을 찾아내느라 고생하신 엠에이의 박성우씨에게 감사드립니다)

Posted by 신상헌
,