네트워크 시뮬레이션 공방

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

Initial ranging이 끝나고 나면 Periodic ranging이 수행된다. 다음 그림은 OPNET WiMAX 모델에서 제공하는 Periodic ranging 절차이다. "WiMAX 모델(75) - Initial Ranging"에서 설명한 것처럼 단말의 프레임 동기가 기지국과
일치하도록 타이밍을 조정하는 절차가 OPNET WiMAX 모델에서는 수행되지 않으며, periodic ranging 절차에서 수행하는 주된 조절 기능도 역시 전력제어이다.

Initial ranging이 완료된 후 T4 타이머가 설정되는데, 이 T4 타이머는 Periodic ranging이 시작되어야 하는 시간을 알려준다. 단말은 T4 타이머가 만료되면, Periodic Ranging 코드 세트에 해당하는 CDMA 코드를 가지는 CDMA 메시지를 선택된 기지국으로 전송하여 periodic ranging 절차를 시작한다. (이 때 CDMA 메시지는 periodic ranging & BR을 위한 자원영역을 사용하여 보내지는데, 이 영역의 위치는 UL-MAP을 통해 기지국으로부터 알려진다.) 메시지를 수신한 기지국은 RNG-RSP 메시지로 응답하는데, 만약 수신 파워가 허용범위 밖이라면 Continue 상태로 응답하여 송신 파워의 조정을 지시하고, 허용범위 이내라면 Success 상태로 응답한다. 단말이 Contiunue 상태의 RNG-RSP 메시지를 받으면, 송신 파워를 조정하여 다시 CDMA 메시지를 기지국으로 전송한다. 단말이 Success 상태의 RNG-RSP 메시지를 받으면, Periodic Ranging 절차를 완료하고, 다음번 Periodic Ranging을 위해서 T4 타이머를 재설정한다.
이러한 과정을 wimax_ss_control 프로세스 모델의 State diagram에서 추적해보면, 다음 그림과 같은 천이 과정을 따른다.

서로 다른 CDMA 코드가 수신된 경우에도, 기지국에서 동시에 검출해낼 수 있는 CDMA 코드 수는 한정적일 수 있다. 예를 들어, Initial Ranging용으로 할당된 CDMA 코드 수가 8개이고, 7개의 단말이 서로 다른 코드를 동시에 전송했을 경우를 생각해 볼 수 있다. 이론적으로는 모두 다른 코드이므로 검출에 문제가 없어야 하겠지만, 실제 디코더의 검출 능력이 4개라면 3개의 코드는 검출되지 않을 것이다. (몇 개가 검출될 것인지는 장비 성능에 따라 다를 것이다.)
OPNET WiMAX 모델에는 이러한 부분이 반영되어 있지 않으며, 코드만 다르면 모두 검출된다. 다르게 말하자면 동시 검출 코드의 수에 제약이 없는 (그렇다고 해도 할당된 CDMA 코드의 수보다 많은 코드가 검출되지는 않을 것이다) 디코더가 사용되고 있다고 볼 수 있다.

OPNET에서 제공하는 정규분포(normal distribution) 함수는 2 개의 인수를 사용한다. 첫 번째 인수는 평균(mean)이며, 두 번째 인수는 분산(variance)이다. OPNET에 정의된 정규분포를 이용하여 noraml(0, 0.2), normal(0, 1.0), normal(0, 5.0), normal(-2, 0.5) 경우에 대한 PDF를 그려보면 다음과 같다. 위키피디아에서 설명하고 있는 정규분포(http://en.wikipedia.org/wiki/Normal_distribution)의 PDF 결과와 정확히 일치하는 것을 알 수 있다.

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

특정 소스와 목적지간에 백그라운드 트래픽을 ip_traffic_flow 디맨드 모델을 이용하여 간단히 모의하는 방법을 "Background Traffic의 영향(4) - Demand Model"에서 살펴본 바 있다. 이 때 "Traffic Mix" 속성을 All Background로 설정하였었는데, "Traffix Mix" 속성이 시뮬레이션 결과에 어떤 영향을 미치는지 살펴보겠다.
여기에서 백그라운드 트래픽이라는 표현에 대해서 약간의 혼란이 발생할 수 있으므로, 먼저 백그라운드 트래픽에 대한 정의를 짚어보고자 한다. OPNET 시뮬레이션에서 백그라운드 트래픽은 두가지 의미로 사용될 수 있는데, 하나는 주된 관찰 대상인가의 여부에 관한 것이고, 다른 하나는 트래픽을 만들어내는 방법에 관한 것이다.

1) 관찰 대상이 아니라는 의미의 백그라운드 트래픽: 특정 어플리케이션 트래픽의 품질이나 네트워크 장비의 동작 특성을 분석할때, 네트워크에 부가되어 있는 트래픽의 크기에 따라 결과가 달라질 수 있다. 이때, 관찰 대상이 되는 트래픽은 아니지만, 네트워크를 의도한 상태로 만들어주기 위해서 부가하는 트래픽을 의미한다. 이러한 의미로 사용되는 경우가 더 많으며, OPNET에 한정되는 표현은 아니다.

2) 트래픽 생성 방법으로서의 백그라운드 트래픽: OPNET에서만 사용되는 개념이다. OPNET에서 트래픽은 생성 방법에 따라 Explicit(or Discrete) Traffic과 Background Traffic으로 구분된다. Explicit Traffic은 개별 패킷을 직접 발생시켜 트래픽을 구성하는 것이고, Background Traffic은 개별 패킷 생성없이 링크 부하등의 계산에만 트래픽 특성을 반영시키는 것이다. Explicit Traffic 방식을 사용하면 좀 더 정밀한 결과를 얻을 수 있지만, 시뮬레이션 수행시간이 오래
걸린다. Background Traffic 방식을 사용하면 정밀도는 조금 낮아지지만, 시뮬레이션 수행시간을 크게 줄일 수 있다.

본 글은 관찰 대상이 아닌 트래픽(1번 의미)을 생성하는 구체적인 방법(2번 의미)에 관한 것이다. 따라서, 이글에서 지금부터 사용되는 백그라운드 트래픽(Background Traffic)은 2번의 의미로서 사용된 것이다.
"Traffic Mix" 속성은 사용자가 설정해준 트래픽 크기에서 실제로 개별 패킷 발생에 의한  Explicit Traffic의 비율이 얼마인가를 설정하는 것이다. 따라서, 0 (또는 All Background)이면 개별 패킷 생성이 전혀 없이 트래픽이 구성되고, 100 (또는 All Explicit)이면 전적으로 개별 패킷 생성에 의해서 트래픽이 구성된다. 사용자가 임의의 비율을 설정해주는 것도 가능하다.
이 때 유의하여야할 점 한가지는 Background Traffic을 발생시켰을 때와 Explicit Traffic을 발생시켰을 때, 네트워크에 부가되는 트래픽의 크기가 실제로는 조금 다르다는 것이다.
다음 그림은 "Background Traffic의 영향(4) - Demand Model"의 시나리오를 사용하여 Explicit Traffic을 발생시킨후, 그 결과를 Background Traffic인 경우와 비교한 결과이다.

Background Traffic을 사용한 경우보다 Explicit Traffic을 사용한 경우에 더 많은 트래픽이 발생한 것을 알 수 있다. 이러한 현상은 시뮬레이션 엔진이 각각의 트래픽을 취급하는 방법이 다르기 때문에 발행한 것이며, 원하는 트래픽을 정확한 크기로 발생시키기 위해서는 여러번의 시험을 통해 실제로 발생되는 트래픽 크기를 확인하는 것이 필요하다.

Ranging을 수행하는 과정에서 다른 단말과 충돌(Collision)이 발생할 수 있는데, CDMA 메시지(코드)가 충돌하는 경우와 MAC 메시지(RNG-REQ 또는 BW reqeust)가 충돌하는 경우이다.

두 가지 경우의 충돌에 대한 처리는 모두 WiMAX 파이프라인 스테이지에서 수행된다. CDMA 메시지가 충돌한 경우에 충돌한 두 CDMA 메시지의 코드가 동일하다면, 두 메시지의 수신파워를 한 메시지(먼저 수신되는 메시지)로 몰아주고 한 메시지(늦게 수신되는 메시지)의 수신파워는 0으로 만들어 버린다. 즉, 한개의 CDMA 메시지만이 실제로 전달된다. 충돌한 두 CDMA 메시지의 코드가 서로 다른 경우, 두 패킷간에는 아무런 interference도 발생하지 않는 것으로 처리된다.
MAC 메시지(RNG-REQ 또는 BW request)가 충돌하는 경우(이는 CDMA Alloc IE가 단말에 대해서가 아니라 CDMA 코드에 대해서 할당되기 때문에 발생한다), 두 메시지는 서로간에 interference로 작용하며 어느 메시지가 살아남을 것인지의 여부는 각 메시지의 SNR에 의해서 결정된다.