네트워크 시뮬레이션 공방

지난 2월 12일자로 OPNET Modeler 17.5 PL6 버전이 발표되었습니다(이전 버전에 관한 내용은 "OPNET Modeler 17.5 PL5 발표" 참조). Release notes는 2013년 12월 20일자로 되어있기는 하지만, 2월말에 확인했을 때에도 공개되어 있지 않았으므로 Release 기준일은 2014년 2월12일이 맞을 듯하고 홈페이지에는 지난 주에 올라온 것으로 보입니다. 요즘 종종 그렇듯이 새 버전에 대한 공지는 없었습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 모델 및 Modeler에 대한 마이너 업데이트 내용이 대부분이며, 중요한 사항은 다음과 같습니다.

- LTE Model Enhancements
- WLAN Model Enhancements
- Cyber Effects Model

LTE 모델에서는 LTE PHY Profile의 TDD Channel Index 속성 기본값이 "Index:3 UL/DL 3:7"로 변경되었습니다. 이전 버전에서의 기본값은 "Index:2 UL/DL 1:4"이였습니다. 그리고, eNodeB의 PUCCH Configuration 속성이 재구성되었다고 합니다.
WLAN 모델에서는 몇 가지 변조 방식에 대한 BER 커브가 새로 추가되었습니다. 추가된 변조 방식은 BPSK 1/2, BPSK 3/4, QPSK 1/2, QPSK 3/4, 16-QAM 1/2, 16-QAM 3/4, 64-QAM 2/3, 64-QAM 3/4, 64-QAM 5/6 입니다. 사실 정확히 말하자면 BPSK, QPSK, 16-QAM, 64-QAM 변조 방식에서 코딩률(Coding Rate) 변화(1/2, 2/3, 3/4, 5/6)에 따른 BER 커브가 새로 추가된 것입니다. 기본의 WLAN 모델에서도 BPSK, QPSK, 16-QAM, 64-QAM 변조 방식에 대한 BER 커브는 제공되고 있었는데, 코딩률 별로는 구분되지 못했습니다. 이 제약사항이 해결된 것입니다.
Cyber Effects는 사이버 공격과 방어 효과에 대한 것입니다. 새로운 모델이 만들어진 것은 아니고 기존의 IP 모델이 Cyber Effects를 제공할 수 있도록 수정되었다고 합니다.
이외에도 여러가지 추가/변경된 사항들이 있지만, 현재 관심이 가는 내용이 아니라서 생략합니다.

"분포함수(1) - 정규분포"에서 살펴보았듯이, OPNET에서 제공하는 분포함수는 이론적 정의와 일치하는 결과를 제공한다. 그런데, ip32_cloud 노드 모델의 Pakcet Latency 속성을 이용하여 네트워크 지터를 발생("네트워크 Jitter(1) - VoIP 실험을 위한 네트워크 Jitter 설정" 참조)시키고 측정해보면 상당한 차이가 나는 경우가 있다. 다음 그림은 normal(0.01, 0.005) 분포를 적용하였을 때 분포함수에서 발생한 결과값과 ip32_cloud 노드 모델을 통해 측정된 Packet Latency 결과값을 비교하여 나타낸 것인데, 두 결과값이 상당한 차이를 보여준다.

이러한 차이가 발생하는 원인은 선행 패킷의 전송지연시간이 후속 패킷의 Latency에 영향을 미치는 패킷 통신망의 특성때문이다. 이를 확인해보기 위해서 선행 패킷의 전송지연이 후속 패킷의 Latency에 영향을 미치지 않도록 코드를 수정하고 실험해본 결과는 다음 그림과 같다.
분포함수에서 발생한 결과값과 Packet Latency 결과값이 잘 일치하는 것을 확인할 수 있다.

OFDMA 방식의 Ranging에서는 CDMA 코드 전송이 필요한데, OPNET WiAMX 모델에서는 CDMA 코드도 역시 패킷 형태로 전달된다. CDMA 코드 정보는 "CDMA Code" 필드에 실리는데, 실제 Binary 코드 값이 아닌 CDMA 코드에 대한 index 값이 사용된다. 각 목적별로 사용되는 CDMA 코드값의 범위는 각 기지국에서 WimaxT_CDMA_Range 구조체 타입의 codeset 배열에 의해서 관리된다. 이 코드값의 갯수는 기지국 attribute에서 설정할 수 있으며, 범위는 0 ~ 256 이다.
다음 그림은 CDMA 코드 전송에 사용되는 "wimax_cdma" 패킷 포맷과 여기에 실리는 CDMA 코드값의 범위를 나타낸 것이다.

표준[1]에서 정의하고 있는 Contention-based CDMA BR 절차는 "WiMAX 모델(85) - BR ranging"에서 설명한 OPNET WiMAX 모델 절차와 대부분 일치한다.

BR ranging에 사용되는 WIMAX_CID_CDMA_BWR는 wimax_support.h 파일에 -41로 선언되어 있으며, 이는 표준[1]에서는 찾아볼 수 없는 것이다. (표준에 따른 CDMA Allocation IE 할당시에는 CID가 필요하지 않다)
초창기 OPNET WiMAX 모델(Release 5까지)의 경우, Contention-based CDMA BR 절차가 생략되어 있어서 표준과는 크게 다르다는 문제가 있었다. 즉, BW 요청을 위한 CDMA 코드를 전송하는 과정없이, Contention 방식의 BW 요청 영역을 이용하여 바로 대역폭 요청 메시지를 전송했던 것이다. 다음 그림은 Release 5에서의 BR ranging 절차를 나타낸 것이다.

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

특정 소스와 목적지간에 백그라운드 트래픽을 ip_traffic_flow 디맨드 모델을 이용하여 간단히 모의하는 방법은 "Background Traffic의 영향(4) - Demand Model"에서 살펴보았다. 특정 소스와 목적지간에 백그라운드 트래픽을 모의하는 또 다른 방법은 Application Model을 사용하는 것이다.
Application Model은 일반적으로 Explicit Traffic을 발생시키기 위해 사용된다. 그런데, voice와 video conferencing 모델은 Traffic Mix 속성을 제공하고 있으며, 이 속성값을 조정하면 Background Traffic을 발생시키는데 사용할 수 있다(Traffic Mix 속성의 사용법은 "Background Traffic의 영향(5) - Traffic Mix"에서 설명한 것과 동일하다). 다음 그림은 Video Conferencing Application Model의  Traffic Mix 속성을 보인 것이다.

다음 그림은 "Background Traffic의 영향(4) - Demand Model"에서 사용한 네트워크 토폴로지에 Video Conferencing Application Model을 적용하고, Explicit Traffic을 사용하였을 때와 Background Traffic을 사용하였을 때 링크에서 측정된 트래픽 발생량을 나타낸 것이다. Background Traffic을 사용하였을 때도 Explicit Traffic과 동일한 크기의 트래픽이 발생한 것을 확인할 수 있다.

그런데, Application Model의 Traffic Mix 속성을 사용하여 백그라운드 트래픽을 발생시킬 때 한가지 주의해야 할 점은 Background 방식으로 발생된 트래픽의 경우 노드에서는 관측되지 않는 다는 것이다.

앞에서 살펴본 것처럼 링크에서는 Application Model의 Traffic Mix 속성을 사용하여 Background Traffic으로 발생된 트래픽도 잘 정상적으로 관측되지만, 노드에서는 Background Traffic 분량만큼을 제외한 트래픽(즉 Explicit Traffic 분량)만이 관측된다. 다음 그림은 Application Model의 Traffic Mix 속성값이 All Explicit, 50%, All Background 일 때, 노드의 MAC단에서 측정된 트래픽 부하를 나타낸 것이다.

OPNET에서 op_stat_write () 함수를 사용하여 시뮬레이션 결과값을 기록할 때, 바로 뒤에 '0' 값을 기록해주는 경우가 종종 있다. 이렇게 하는 것은 결과값을 해석하는데 상당히 큰 영향을 미칠 때가 있기 때문인데, 다수의 OPNET 사용자들이 그 차이를 잘 이해하지 못하고 있는 부분이기도 하다(덕분에 본인도 모르는 사이에 왜곡된 시뮬레이션 결과를 발표한 분들도 제법 있을 것으로 생각된다).
다음은 "OPNET 기초다지기"의 ARQ 예제에서 작성한 arq_sender 프로세스 모델의 Rcv_HL_Packet 스테이트의 일부분인데, 역시 send_pkt_sthandle Statistic handle에 결과값을 기록한 뒤에 즉시 '0'값을 기록해주는 것을 볼 수 있다.

왜 이렇게 '0'값을 같이 기록해주는 것일까? 대부분의 경우에 있어 그 이유는 bucket 방식의 캡춰 모드에서 시간당 결과값을 보다 정확하게 파악하기 위해서이다. 물론, 캡춰 모드와는 상관없이 '0'값을 같이 기록해줄 수도 있지만, 그렇게 사용하는 경우는 극히 드물다(결과 수집을 위한 캡춰 모드에 대해서는 이후에 별도의 글에서 다루도록 하겠다). 즉,  '0'값을 같이 기록해주는 것은 일반적으로 해당 결과(statistic)의 캡춰 모드가 bucket이고, bucket 모드는 sum/time인 경우이다.
다음 그림은 arq_sender 프로세서 모델의 send_pkt_sthandle Statistic handle에 '0'값을 같이 기록하지 않도록 수정한뒤, '0'값을 같이 기록되는 Traffic Generator 모듈의 Tranffic Sent (packet/sec) 결과값과 비교한 것이다. '0'값을 같이 기록하지 않는 arq_sender의 경우 순간순간의 정확한 값(빨간 선)을 보여주지 못하고 좀 더 평균화된 값(파란 선)을 보여주는 것을 알 수 있다.

이러한 차이는 하나의 statistic value가 표현하는 시간 간격을 축소시키면 더 확연하게 나타난다. 다음 그림은 위와 동일한 트래픽이 발생하는 경우에 대해서 하나의 statistic value가 1초의 시간 간격을 나타내도록 설정했을 때의 결과이다. '0'값을 같이 기록하지 않는 arq_sender의 경우(파란선) 순간순간의 정확한 값(빨간 선)을 전혀 나타내지 못하는 것을 알 수 있다.

지금까지 살펴본 것처럼  bucket 방식의 캡춰 모드에서 시간당 결과값을 보다 정확하게 파악하기 위해서는 '0' 값을 같이 기록해주는 것이 필요하다. 하지만, 일부 상황에서는 '0'값을 같이 기록한 결과값이 해석하기에 더 혼란스러운 경우도 있으므로 사용시 주의하여야 한다.

UL 구간에서 전달할 메시지(사용자 데이터 또는 제어 메시지)가 있을 때, 확보된 대역폭이 없으면 대역폭을 요청하기 위해서 BR ranging이 사용될 수 있다. BR ranging 절차는 "WiMAX 모델(26) - UL 구간의 데이터 패킷 전송"에서 설명한 내용중 BE connection을 위한 contention 방식의 BW 요청절차에 해당한다.
Contention 방식의 BW 요청을 위한 자원 정보는 매 프레임마다 UL-MAP을 통해서 SS들에게 알려지며, 이 때 전송할 데이터가 있으면 SS는 BW 요청을 위한 CDMA 코드를 BS로 보낸다. BS는 수신된 CDMA 코드에 대해서 CDMA Allocation IE로 응답하며, 단말은 CDMA Allocation IE로 할당된 BW 요청 대역폭을 이용하여 대역폭 요청 메시지를 전송한다. 이 요청이 성공적으로 BS에게 전달되고 BW 자원이 할당되면, UL-MAP을 통해 SS에게 알려지고, SS는 할당된 BW를 이용하여 데이터를 BS로 전송한다.

다음 그림은 표준[1]에서 정의하고 있는 periodic ranging 절차인데([1]의 Table 183 참조), "WiMAX 모델(82) - Periodic ranging"에서 설명한 OPNET WiMAX 모델 기능은 이와 일치한다.

Initial ranging에 사용되었던 WIMAX_CID_INITIAL_RNG은 Periodic Ranging에서도 동일하게 사용된다. 표준[1]에서 Ranging CID는 0x0000을 사용하도록 정의([1]의 Table 558 참조)되어 있으므로 이는 표준과 일치하는 것이다. (왜 OPNET 모델에서 Ranging CID의 명칭으로 WIMAX_CID_INITIAL_RNG을 사용해서 혼란의 소지를 만드는지 모르겠다. 그냥 WIMAX_CID_RNG 정도로 사용하는게 더 깔끔할 것이라고 생각한다.)

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

"Background Traffic의 영향(5) - Traffic Mix"에서 설명하였듯이, Explicit Traffic 방식을 사용하면 시뮬레이션 수행시간이 오래걸리지만 좀 더 정밀한 결과를 얻을 수 있고, Background Traffic 방식을 사용하면 시뮬레이션 수행시간을 크게 줄일 수 있지만, 정밀도는 조금 낮아진다.
그러면, 실제로 두 가지 방식을 적용하였을 때, 시뮬레이션 수행시간이 어느 정도 차이가 발생하는지 확인해 보자. "Background Traffic의 영향(5) - Traffix Mix"에서 사용한 두 시나리오를 동일한 PC(CPU: Intel Core2 Duo E8400 3.0GHz, RAM: 2GB, OS: Windows XP 32비트)에서 실행하였을 때, All Background 방식의 시나리오 에서는 18초가 소요되었으며 All Explicit 방식의 시나리오에서는 거의 10배인 2분 48초가 소요되었다. 이 시나리오들의 네트워크 토폴로지는 매우 작은 크기를 가지며 실험대상 시간(Duration)인 600초(10분)중 백그라운드 트래픽이 적용되는 구간은 100초에 불과 하다는 점을 고려하면, 이 차이는 대단히 큰 것이라고 볼 수 있다.
이제 시뮬레이션 결과에서는 어느 정도 차이가 발생하는지 확인해 보자. Calling_party 노드에서 측정된 MOS 값을 살펴보면 다음과 같다.

Explicit Traffic 방식의 시나리오에서는 평균값이 약 4.33600이며, 약 0.00002의 변동폭을 가진다. Background Traffic 방식의 시나리오에서는 평균값이 약 4.336035이며 약 0.000005의 변동폭을 가진다. 약간의 차이가 발생하기는 하지만, 매우 유사한 결과를 얻을 수 있다는 것을 확인할 수 있다.

물론, 이 차이가 측정하고자 하는 결과에 영향을 주지않는 수준의 작은 차이인가 아닌가는 시험 케이스에 따라서 실험자가 판단해야하는 문제이며, 항상 무시할 수 있는 수준이라고 장담할 수는 없다. 이 예제의 경우 Explicit Traffic을 사용했을 때와 Background Traffic을 사용했을 때의 결과값만을 비교하면 어느 정도 차이가 난다고 볼 수도 있지만, MOS 절대값의 범위가 1~5라는 점을 고려하면 소수점 5째자리에서의 차이는 무시할 수준이라고 볼 수 있다. (그런 점에서 이 예제는 Background Traffic 사용에 의한 정밀도 차이를 보여주기에 그리 좋은 예제는 아니다)

OPNET에서 제공하는 라플라스 분포(laplace distribution) 함수는 2 개의 인수를 사용한다. 첫 번째 인수는 평균(mean)이며, 두 번째 인수는 scale이다. OPNET에 정의된 라플라스 분포를 이용 하여 laplace(0, 1), laplace(0, 2), laplace(0, 4), laplace(-5, 4) 경우에 대한 PDF를 그려보면 다음과 같다. 위키피디아에서 설명하고 있는 라플라스 분포(http://en.wikipedia.org/wiki/Laplace_distribution)의 PDF 결과와 정확히 일치하는 것을 알 수 있다.

[1] http://en.wikipedia.org/wiki/Laplace_distribution