네트워크 시뮬레이션 공방

OPNET WiMAX 모델에서는 서비스 플로우 단위별로 ARQ 기능 적용을 조절할 수 있다. ARQ는 슬라이딩 윈도우 방식으로 동작하며, Ack 타입은 Cumulative, Selective Bitmap, Selective Block Sequence를 지원한다. 다음 그림은 WiMAX 모델에서의 ARQ 동작 구조를 나타낸 것이다.

송신측의 ARQ 버퍼에는 송신한 MAC PDU의 사본이 윈도우 크기만큼 저장되어 있다가, Feedback 메시지로부터 성공적인 전달이 확인되면 삭제된다. Feedback 메시지로부터 재전송이 요구되면, 저장되어 있던 MAC PDU를 복사하여 전송한다.
수신측의 ARQ 버퍼에는 수신된 MAC SDU가 저장되어 있다가, 누락된 sequence number 없이 수신된 것이 확인되면 상위 계층으로 전달된다. 다음 그림은 이러한 ARQ 동작을 지원하는 자료구조를 나타낸 것이다.

Packing은 다수 개의 SDU 또는 SDU fragment들을 하나의 MAC SDU로 구성하여 전송하는 것이며, OPNET WiMAX 모델 또한 이 기능을 지원한다. "WiMAX 모델(21) - MAC 데이타 평면: 송신측"과 "WiMAX 모델(65) - Fragmentation 기능"에서 설명한 것처럼 전송할 패킷을 저장하기 위한 관(conduit)이 CID별로 존재하며, 상위 계층에서 내려온 패킷은 일단 SDU 버퍼에 저장된다. 만약 할당받은 대역폭이 한 개 이상의 SDU를 전송할 수 있는 크기이면 packing되어 여러 개의 SDU가 한 개의 MAC PDU로 만들어져 전송된다. Packing하는 과정에서 대역폭이 부족하면 마지막 SDU는 분할(fragmentation)된다.

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

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

어제(8월 15일) OPNET Modeler 17.5 PL5 버전이 발표되었습니다(이전 버전에 관한 내용은 "OPNET Modeler 17.5 PL4 발표" 참조). Release notes는 6월 27일자로 되어있기는 한데, 그 동안 본적이 없어서 어제 발표가 맞을 듯 합니다. 요즘 종종 그렇듯이 새 버전에 대한 공지는 없었습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 모델 및 Modeler에 대한 마이너 업데이트 내용이 대부분이며, 중요한 사항은 다음과 같습니다.

- PNNI Model Licensing Change
- IPv6 Path MTU Discovery
- Huawei Device Support

PNNI(Private Network-Network Interface) 모델이 이번 버전부터 Standard 모델 라이브러리에 포함되었다고 합니다. OPNET PNNI 모델은 Specialized 모델 중의 하나로 별도의 라이센스를 구매해야만 했었는데, 이제는 추가 라이센스 없이 사용이 가능해졌습니다.
IPv6 모델의 개선 사항은 Path MTU Discovery 기능 지원입니다. IPv6는 IPv4와 달리 소스 노드를 제외한 라우터에서는 fragmentation을 수행하지 않는 대신 Path MTU Discovery 기능을 통해 소스 노드가 MTU를 적정 크기로 조정할 수 있도록 합니다. 이 Path MTU Discovery 기능이 이번 버전에 구현되었다고 합니다.
프로젝트 에디터에서는 Huawei사의 장비들에 대한 노드 모델이 Object Palette에서 제공된다고 합니다. 이는 Huawei사의 제품들이 그만큼 시장에서 많이 사용된다는 반증이고 생각되어 상당히 놀랍습니다.
이외에도 여러가지 추가/변경된 사항들이 있지만, 현재 관심이 가는 내용이 아니라서 생략합니다.

OPNET 16.1 버전에서 MOS 계산시 delay가 중복하여 반영되는 문제가 있다(15.0, 16.0 버전에서도 동일한 문제가 있는 것을 확인하였으며, 17.1, 17.5 버전에서도 해결되지 않은 것으로 보여진다). 즉, packetization delay와 compression/decompression delay가 중복하여 반영되는 문제가 발생한다.
또한 이 delay 값들은 무시할만한 수준이 아니어서 최종 MOS 값에도 영향을 미친다.

이러한 문제에 대해서 OPNET사에 문의한 결과 오류로 확인되었으며, 이후 발표될 버전에서는 수정하기로 하였다. (SPR-176998: "Packetization, compression, decompression, and dejitter buffer delays are double-counted in MOS value computation of VoIP application traffic." 참조)

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가 적용될 경우에 관련된 정보를 알려주기 위해서 사용된다.