네트워크 시뮬레이션 공방

Fragmentation은 SDU를 분할하여 여러 MAC PDU에 나눠담아 전송하는 것이며, OPNET WiMAX 모델 또한 이 기능을 지원한다. "WiMAX 모델(21) - MAC 데이타 평면: 송신측"에서 설명한 것처럼 전송할 패킷을 저장하기 위한 관(conduit)이 CID별로 존재하며, 상위 계층에서 내려온 패킷은 일단 SDU 버퍼에 저장된다. 대역폭을 할당받아 전송을 수행하는 시점에, SDU 버퍼에 있는 패킷은 분할(fragmentation) 버퍼로 옴겨진다. 만약 할당받은 대역폭이 한개의 SDU 전체를 전송하기에 부족하면 분할(fragmentation)되어 일부만 전송되고, 남은 부분은 다음 번에 대역폭이 할당되었을 때 전송된다.

"WiMAX 모델(62) - MAC PDU 구조"에서 살펴본 것처럼 wimax_mac_pdu 패킷에는 FSH(Fragmentation subheader)를 위한 필드가 존재하지 않으며, FSH 크기만이 CRC 필드와 같이 반영되어 설정된다. FSH 크기(MAC_NE_FRAG_SUBHEADER_BITS)는 wimax_support.h 파일에 8비트로 정의되어 있다. 이는 Extended Type이 아닐 경우의 FSH 필드에 대해서 표준[1]에서 정의한 크기이다([1]의 Table 19 참조).

[1] IEEE 802.16-2009, "Air Interface for Broadband Wireless Access Systems", 2009.

Concatenation은 다음 그림과 같이 MAC PDU를 연속적으로 배치하여 하나의 버스트를 구성하는 것이다.

"WiMAX 모델(38) - BS 스케줄러 병합 승인"에서 설명한 OPNET WiMAX 모델 스케줄러의 병합(amalgamation) 기능은 이러한 concatenation에 해당한다고 볼 수 있다. 즉, 동일한 단말에 대한 승인들을 모아서 한개의 IE 정보를 만든다는 것은, 하나의 버스트내에서 여러 MAC PDU를 전달하라는 지시이기 때문이다. 따라서, 직접 MAC PDU를 전송하는 부분에는 concatenation에 대한 별도의 코드가 없지만, 병합(amalgamation)된 승인 정보를 받으면 실제로는 concatenation 방식에 의한 전송이 일어난다고 봐야 한다.

"OPNET 중급입문"에서 설명하였듯이, OPNET은 E-Model에 기반한 MOS 측정 기능을 14.0 버전부터 제공한다. E-Model은 패킷 손실과 지연시간 등의 정보로부터 MOS를 계산해내는 방법으로 ITU-T에 의해서 표준화되었다[1]. OPNET에 구현된 MOS 계산 기능은 E-Model에 기반한 것이기는 하지만, 구체적인 계산 과정은 R.G. Cole과 J.H. Rosenbluth가 제시한 방식을 사용한다. R.G. Cole과 J.H. Rosenbluth에 따르면 E-Model에 필요한 R factor는 다음 수식에 의해서 계산될 수 있다(파라미터 값 변경없이 기본값을 사용했을 때)[2].

여기에서 d는 end-to-end packet delay, e는 packet loss rate이다. G1/G2/G3는 음성 코덱에 의해 결정되는 상수값이며, G.711 코덱과 G.729a 코덱에 대한 값은 다음과 같다.

OPNET에서 R factor는 다음 수식을 통해 계산된다(파라미터 값 변경없이 기본값을 사용했을 때).

여기에서 d와 e, G1/G2/G3는 (Eq. 1)에 사용된 것과 동일하다.
즉, OPNET에서의 MOS 계산 방식은 R.G. Cole과 J.H. Rosenbluth가 제시한 방식을 따른다.

[1] ITU-T G.107, "The E-model, A Computation Model for Use in Transmission Planning," 2011.
[2] R.G. Cole and J.H. Rosenbluth, "Voice Over IP Performance Monitoring", Computer Communication Review, a publication of ACM SIGCOMM, volume 31, number 2, April 2001.

DTED Level 0 데이터는 공개되어 있으므로 쉽게 구할 수 있기는 하지만, 해상도가 낮아서 활용 가치는 그리 높지 않다. 한반도에 대한 예를 통해 DTED Level 0가 어느 정도 유용한지 한번 확인해 보자. 다음 그림은 한반도 지역에 대한 DTED Level 0 지형정보를 적용한 것이다.

수원 광교산에서 성남 남한산성간의 지형을 확인해보기 위해서, Topology-->Terrain-->View Terrain Profile 메뉴를 실행한 후 광교산 시루봉과 남한산성 수어장대에 해당하는 좌표를 차례로 클릭한다.

두 지점의 좌표값은 다음과 같다.

다음의 View Terrain Profile 창에서 왼쪽이 광교산 시루봉, 오른쪽이 남한산성 수어장대에 해당한다. 광교산 시루봉의 실제 해발고도는 581m이지만, DTED Level 0 지도를 통해서는 400m를 조금 넘는 높이로 표시된다. 남한산성 수어장대의 경우에도 실제 해발고도는 498m이지만, DTED Level 0 지도를 통해서는 400m 미만으로 표시된다.

DTED Level 0의 해상도는 30 arc second로서 약 1Km에 해당한다. 산악지형에서는 거리가 1Km 떨어지면 고도는 수백m 차이가 발생할 수도 있으므로, 위 예제와 같은 오차가 발생하는 것은 피할 수 없는 현상일 것이다. 따라서, DTED Level 0 지형정보를 이용하여 시뮬레이션을 할 경우, 지형에 의한 효과를 어느 정도 반영하는 것은 가능하지만, 해당 지역의 정확한 지형 효과를 반영한 시뮬레이션 결과라고 얘기하기는 어렵다.

다음 그림은 표준[1]의 MAC PDU 구조와 MAC Header 구조를 나타낸 것이다([1]의 Figure 20과 Table 3 참조). MAC 헤더의 필드중에서 OPNET WiMAX 모델의 MAC PDU로 실제 표현되는 부분은 녹색으로 표시된 부분들뿐이다.

"WiMAX 모델(62) - MAC PDU 구조"에서 살펴본 것처럼 OPNET WiMAX 모델에서 사용하는 wimax_mac_pdu 패킷 포맷에서는 CRC 필드가 없다. 하지만, CRC가 적용되는 연결의 경우 CRC 필드의 크기(WIMAX_MAC_CRC32_OVERHEAD_BITS)는 패킷 크기 설정에 반영되며 그 크기는 wimax_support.h 파일에 32비트(4바이트)로 정의되어 있다.

[1] IEEE 802.16-2009, "Air Interface for Broadband Wireless Access Systems", 2009

OPNET WiMAX 모델에서 사용하는 MAC PDU 구조는 wimax_mac_pdu 패킷에 다음 그림과 같이 정의되어 있다.

"MAC Header" 필드에는 wimax_support.h 파일에 정의되어 있는 WimaxT_Mac_Header_Fields 타입의 구조체가 담긴다.
"Header Type" 필드와 "CID" 필드는 원래 MAC 헤더에 포함되어 있는 정보인데, 코드 처리상의 편의를 위해서 크기가 0인 별도의 필드로 빼놓은 것이다. "MAC SDU" 필드에는 상위 계층에서 내려온 사용자 데이터가 담기는데, 분할(fragemntation)되거나 패킹(packing)될 수 있다. "Packet Role" 필드는 이 패킷이 제어용인지 사용자 데이터 전달용
인지를 구분하기 위해서 사용되며, "harq information" 필드는 HARQ가 적용될 경우에 관련된 정보를 알려주기 위해서 사용된다.

OPNET에서 VoIP 호 설정(Call Setup)에 사용되는 시그날링 프로토콜은 None, SIP, H.323의 3가지이다. 이 중에서 None은 시그날링 메시지를 네트워크를 통해 교환하는 과정없이 호 설정을 하는 것으로서 시뮬레이션상에서만 가능한 방법이다. VoIP 교환기를 배치할 필요가 없고 네트워크상에서의 시그날링 메시지 손실을 신경쓰지 않아도 되기때문에, VoIP 데이터 트래픽 자체만을 OPNET에서 시뮬레이션하는 것이 목적인 경우에 흔히 사용된다.
"OPNET 중급입문" 5장의 VoIP 예제도 이 방법을 사용한 것이며, 다음 그림과 같이 VoIP 속성 편집창에서 Signaling 프로토콜이 None으로 적용되어 있음을 확인할 수 있다.

"OPNET 기초다지기"에서 설명하였듯이, 32비트 윈도우에서 Visual Studio .NET 2003을 컴파일러로 사용하기 위한 환경 변수 설정은 다음과 같다.

======================================================================
INCLUDE:
C:\Program Files\Microsoft Visual Studio .NET\Vc7\atlmfc\include;
C:\Program Files\Microsoft Visual Studio .NET\Vc7\include;
C:\Program Files\Microsoft Visual Studio .NET\Vc7\PlatformSDK\Include;
C:\Program Files\Microsoft Visual Studio .NET\SDK\v1.1\include

LIB:
C:\Program Files\Microsoft Visual Studio .NET\Vc7\atlmfc\lib;
C:\Program Files\Microsoft Visual Studio .NET\Vc7\lib;
C:\Program Files\Microsoft Visual Studio .NET\Vc7\PlatformSDK\Lib;
C:\Program Files\Microsoft Visual Studio .NET\SDK\v1.1\Lib

PATH:
C:\Program Files\Microsoft Visual Studio .NET\Common7\IDE;
C:\Program Files\Microsoft Visual Studio .NET\VC7\BIN;
C:\Program Files\Microsoft Visual Studio .NET\Common7\Tools;
C:\Program Files\Microsoft Visual Studio .NET\Common7\Tools\bin;
C:\Program Files\Microsoft Visual Studio .NET\SDK\v1.1\bin;
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;

DevEnvDir:
C:\Program Files\Microsoft Visual Studio .NET\Common7\IDE

MSVCDir:
C:\Program Files\Microsoft Visual Studio .NET\Vc7

VCINSTALLDIR:
C:\Program Files\Microsoft Visual Studio .NET

VSINSTALLDIR:
C:\Program Files\Microsoft Visual Studio .NET\Common7\IDE
======================================================================

그런데, 경우에 따라서는  Visual Studio .NET 2003이 설치된 경로가 "\Program Files\Microsoft Visual Studio .NET\"이 아니라 "\Program Files\Microsoft Visual Studio .NET 2003\"으로 되어 있는 경우도 있다. 이럴 때에는 다음과 같이 Visual Studio .NET 2003이 설치된 경로대로 변경해서 설정해주면 된다.

======================================================================
INCLUDE:
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\include;
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include;
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include;
C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include

LIB:
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\lib;
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib;
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Lib;
C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib

PATH:
C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE;
C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN;
C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools;
C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\bin;
C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\bin;
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322;

DevEnvDir:
C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE

MSVCDir:
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7

VCINSTALLDIR:
C:\Program Files\Microsoft Visual Studio .NET 2003

VSINSTALLDIR:
C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE
======================================================================

요즘 Visual Studio .NET 2003을 사용하는 사람이 많지는 않겠지만, 몇일전까지 Visutal C++ 6.0을 사용했던 본인도 있었으니까...

완성된 UL-MAP IE 정보는 다음 그림과 같은 구조를 가진다.

"WiMAX 모델(55) - UL-MAP 메시지 구조"에서 설명한 바와 같이, UL-MAP IE들은 WimaxT_Map 구조체의 해쉬테이블에 저장된다. 해쉬 테이블에서 각 IE를 구별하는 키로는 Basic CID와 purpose(Ex: WimaxC_Data, WimaxC_Harq_Data, WimaxC_Haraq_Retransmit_Data)를 조합한 값이 사용된다. OFDMA UL에서 버스트는 선형적으로 배치되므로 이 IE들은 WimaxC_IE_Type3를 dimention_type 값으로 가진다. UL에서는 Basic CID와 purpose가 동일한 승인에 대해서 하나의 IE만이 존재한다.
여기까지의 정보는 각 단말로 전송되는 버스트의 위치를 단말에게 알려주는 UL-MAP을 구성하기 위해서 필요한 정보들이며, WiMAX 표준과 관련있는 부분이다. 하지만, void 타입의 extra_info_ptr 변수에 저장되는 정보는 해당 버스트가 각각의 서비스 플로우에 의해서 어떻게 사용될 것인지에 대한 것을 단말에게 알려주기 위한 정보들이며, 표준과는 관련이 없다. (동일한 WimaxT_IE 구조체의 extra_info_ptr 변수가 DL-MAP과는 다른 용도로 사용됨에 유의해야 한다) "WiMAX 모델(32) - SS 스케줄러 (표준과의 비교)"에서 설명한 것처럼 BS는 SS 단위로 BW 승인 정보를 내려준다(GPSS 방식).
따라서, 여러 서비스 플로우들로부터의 BW 요청에 대한 승인이 하나의 IE로 나타나며, 이 때 각 서비스 플로우별 요청/승인에 대한 정보는 WimaxT_IE 구조체의 extra_info_ptr 변수에 저장된다. WimaxT_IE 구조체의 extra_info_ptr 변수는 각각의 서비스 플로우별 승인에 대한 정보를 담고 있는 IE들의 리스트이며, IE들은 역시 WimaxC_IE_Type3를 dimention_type 값으로 가진다. 각각의 서비스 플로우별 승인은 기본적으로 CID에 관계없이 BW 요청 별로 하나씩 별개의 IE로 존재한다. 하지만, HARQ 데이터 전송인 경우(purpose == WimaxC_Harq_Data), 하나의 IE로 병합(amalgamate)시킨다. 이 때 IE의 갯수는 증가하지 않지만, UL-MAP의 크기는 subburst IE만큼 증가한다.

"WiMAX 모델(57) - DL-MAP IE 정보"에서 설명한 것처럼 OFDMA DL에서는 Type2 IE 내부에 Type4 IE가 사용될 수 있으며, 이를 좀 더 자세하게 표현해보면 다음 그림과 같다.

Type2 IE는 정사각형(rectangular)의 버스트 배치를 표현하기 위해서 사용된다. 정사각형 버스트는 여러 서비스 플로우에서 발생하는 MAC PDU들이 합쳐져서 구성될 수도 있는데, 이러한 서비스 플로우별 MAC PDU를 위한 자원 할당을 표현하는 것이 Type4 IE이다.