네트워크 시뮬레이션 공방

인터넷망에서 사용자가 경험하는 서비스 품질은 백그라운드 트래픽(해당 사용자에 의해서 발생되는 패킷이외의 패킷들)에 의해서 많은 영향을 받는다. 즉, 동일한 망에서 서비스를 받는 경우에도 해당 경로상에 존재하는 백그라운드 트래픽의 양에 따라 사용자가 경험하는 서비스 품질이 달라지는 것이다. OPNET에서는 이러한 백그라운 트래픽을 간단하게 설정할 수 있는 몇 가지 방법을 제공하고 있는데, 그 중 한가지가 링크의 "Traffic Load" 속성을 이용하는 것이다. 이 속성을 이용하면 백그라운드 트래픽을 매우 쉽게 설정할 수 있을 뿐만 아니라, 시뮬레이션 수행시간에는 거의 영향을 미치지 않으면서 큰 백그라운드 트래픽에 의한 영향을 살펴볼 수 있다.
백그라운드 트래픽이 시뮬레이션 결과에 어떤 영향을 미치는지 예제를 통해 살펴보도록 하자. 사용할 예제망의 토폴로지는 다음과 같으며, Calling_1 노드와 Called_party 노드간에는 "Voice over IP Call (PCM Quality)" 어플리케이션을 설정해 주었다.

예제망에서 백그라운드 트래픽이 설정될 구간은 GW_1 노드와 ISP_backbone 노드 사이의 링크이며, 설정할 트래픽 양은 링크 용량 대비 30%, 50%, 70%이다. 링크의 "Traffic Information" 속성에 한개의 열(Row)을 추가하고, "Traffic Load (bps)" 속성을 Edit 모드로 선택하여 300sec에서 400sec 사이에 트래픽이 발생하도록 설정해 주었다. 이때 트래픽의 크기는 %가 아닌 bps로 설정되어야 한다. 이 예제에서는 DS3급(44.736Mbps) 링크를 사용하였으므로, 30%, 50%, 70%에 맞추어 13,420,800bps, 22,368,000bps, 31,315,200bps를 설정해 주었다. 다음 그림은 이 과정을 보인 것이다.

이제 각 설정별 시나리오에 대한 시뮬레이션을 수행하고 결과를 비교해보도록 하자. 먼저 백그라운드 트래픽이 잘 걸렸는지 확인하기 위해서, GW_1 노드와 ISP_backbone 노드 사이 링크의 throughput을 살펴보도록 한다. 다음 그림은 우리가 설정해준 크기대로 백그라운드 트래픽이 잘 걸렸음을 보여준다.

이제 Calling_1 노드에 수신된 패킷의 End-to-End Delay를 살펴보면, 백그라운드 트래픽이 높아질수록 delay 값이 증가하는 것을 다음과 같이 확인할 수 있다.

Delay가 증가하면 MOS는 떨어지게 되는데, 이 역시 다음과 같이 확인할 수 있다.

이상과 같이 백그라운드 트래픽을 링크에 간단하게 설정하는 방법과, 이러한 설정이 실제로 시뮬레이션 결과에 영향을 미친다는 것을 살펴보았다. 하지만, 여기에서 한가지 의문을 가질 수 있는데, 그것은 백그라운드 트래픽이 시뮬레이션 결과에 영향을 미치기는 하지만, 그 차이가 예상보다(?) 터무니없이 작다는 점이다. (이 예제에서 백그라운드 트래픽을 70%까지 증가시켰을 경우에도 백그라운드 트래픽이 전혀 없을 때와는 차이는 겨우 170usec 정도에 불과하다) 이 문제에 대해서는 다음 포스팅에서 다루어 보도록 하겠다.

Voice Application의 Statistic 결과 항목들을 보면 다음 그림과 같이 "Packet Delay Variation" 항목과는 별도로 "Jitter (sec)" 항목도 있다.

일반적으로 Jitter는 패킷 전달 지연시간의 편차로 해석되기 때문에, 거의 동일한 의미로 해설될 수 있는 Packet Delay Variatioin 항목이 같이 있는 것은 사용자들에게 곧잘 혼란을 불러일으키고는 한다. 이 두 가지 값의 정확한 차이를 알아보도록 하자.
먼저 Packet Delay Variation의 (OPNET에서 사용하고 있는) 정의는 다음과 같다.
"Variance among end to end delays for voice packets received by this node. End to end delay for a voice packet is measured from the time it is created to the time it is received. "
실제로 delay variation 값은 gna_stat_variance_obtain() 함수에서 계산되는데, 해당 코드는 다음과 같다. (gna_support.ex.c 파일)
-----------------------------------------------------------------------------------
  mean_value = stat_data_ptr->sample_sum / stat_data_ptr->sample_count;
  variance_value = (stat_data_ptr->sample_sq_sum / stat_data_ptr->sample_count) -
   (mean_value * mean_value);
-----------------------------------------------------------------------------------
소스코드를 수식으로 변환하여 표현하면, 다음과 같다.

따라서, 소스코드와 Statistics 항목의 설명에서 명확하게 알 수 있듯이, 여기에서 variance가 의미하는 것은 일반적인 뜻인 '변화량'이 아니라 통계에서 사용하는 '분산'인 것이다.

다음으로 Jitter의 (OPNET에서 사용하는 있는) 정의는 다음과 같다.
"If two consequetive packets leave the source node with time stamps t1 & t2 and are played back at the destination node at time t3 & t4, then:
jitter = (t4 - t3) - (t2 - t1)
Negative jitter indicates that the time difference between the packets at the destination node was less than that at the source node."
실제로 jitter 값은 gna_voice_called_mgr (또는 gna_voice_calling_mgr) 프로세스 모델에서 계산되는데, 해당 코드는 다음과 같다.
-------------------------------------------------------------------------------------
/* Compute the jitter */
jitter = (op_sim_time () - prev_pk_info_ptr->play_back_time) - (rtp_pk_info_ptr->time_stamp - prev_pk_info_ptr->time_stamp);
-------------------------------------------------------------------------------------

Statistic 항목의 설명과 동일하게 jitter = (현재시간 - 이전 패킷의 수신시간) - (패킷을 송신한 시간 - 이전 패킷을 송신한 시간)으로 계산되고 있음을 확인할 수 있다. 즉, Jitter는 연속된 두 패킷에서 송신 노드에서 보내질 때의 시간 간격과 수신노드에 도착할 때의 시간 간격의 차이를 의미하는 것이다.

시뮬레이션 결과를 살펴보면 다음과 같이 전혀 다른 값이 기록되어 있는 것을 확인할 수 있으며, 그 이유는 앞에서 설명한 것처럼 서로 계산하는 방식이 전혀 다르기 때문이다.