네트워크 시뮬레이션 공방

"OPNET 기초다지기" 3.5절의 TCP 예제를 수행해보면 Slow start 구간에서 결과 그래프가 지수적으로 증가하지 않고 다음 그림처럼 선형적으로 증가하는 것을 볼 수 있다.

이렇게 논리적으로 예측된 결과와 OPNET 시뮬레이션 결과값 사이의 차이를 이해하는 것은 네트워크 시뮬레이션에 대한 감각을 익히는데 대단히 중요하다(비단 OPNET에만 한정되는 사항은 아니다). 논리적으로 예측한 결과값을 얻을 수 있도록 시뮬레이션 조건을 설정해주고, 다시 OPNET 시뮬레이션 결과값을 논리적 해석과 연결시키는 이러한 부분이야 말로 OPNET 사용에 있어서 가장 핵심적인 부분이라고 필자는 생각한다.

3.5절의 TCP 예제에서 CWND(Congestion Window)의 크기가 선형적인 증가폭을 보여주는 원인은 3가지인데, 1) 네트워크 환경 조건과, 2) TCP 파라메터 설정, 3) 결과 그래프 표시방법의 차이이다. 즉, 교재의 TCP 예제에서도 CWND 크기는 지수함수적인 방법으로 증가하고 있지만, 이 3가지 조건이 잘 맞지않은 관계로 예쁜 지수 함수로 보이지 못하고, 마치 직선인 것처럼 (찌그러져서) 보인 것이다.
다음 그림은 3.5절의 예제에서 몇 가지 설정사항만을 변경하여 다시 시뮬레이션한 결과이다. (빨간색 점과 녹색선은 이해를 돕기위하여 필자가 그려 넣어준 것이다) 동일한 소스 코드를 통한 시뮬레이션 결과이지만, 적합한 네트워크 환경 조건 및 TCP 파라메터 설정을 통해 CWND가 지수함수적 패턴으로 증가하는 현상을 잘 보여주고 있다.

여기에서 한 가지 주목해야할 사실은, 적절한 시뮬레이션 조건을 설정해준다 할지라도 시뮬레이션 결과 그래프는 논리적인 분석 그래프 모습과는 좀 다를 수 있다는 것이다. 위의 그림에서 녹색선은 (네트워크 서적에서 흔히 보여주는) 이론적인 예측 그래프이며, 빨간색 점은 (마지막 점을 제외하고) 이 녹색 그래프를 그리는데 사용된 CWND 값이다. 즉, 우리가 논리적인 예측을 할 때에는 모든 CWND 값을 사용한 것이 아니라, 일정 주기 간격으로 CWND 값을 샘플링하여 사용한 것이다. 더욱이, 엄밀하게 말해서 그 샘플링 간격이 일정하지도 않다. (위의 그림에서 빨간색 점의 x축(시간) 간격은 일정하지 않다. 뒤로 갈수록 길어진다.) 따라서, 기계적으로 CWND 값을 수집하는 경우(이는 실장비의 값을 측정하는 경우에도 마찬가지이다)에는 논리적인 분석처럼 예쁜 지수함수 그래프를 얻을 수 없다.

WiFi 인터페이스를 사용하는 노드들간의 기본적인 통신 가능거리에 대해서는 "WiFi 모델에서의 통신 가능 거리"에서, 확산이득과 Reception threshold의 영향에 대해서는 "WiFi 모델에서의 통신 가능 거리(2)"에서 살펴본 바 있다. 그런데, WiFi에서의 통신 가능거리에 영향을 미치는 또 하나의 중요한 요소로 propagation delay가 있다.
표준[1]에 의하면 노드들간의 propagation delay는 1usec 이내이어야 하며, 무선신호의 전파 속도를 3x10^8 m/sec라고 가정했을 때 300미터에 해당한다(1x10^-6 sec * 3x10^8 m/sec = 300m). 이러한 특성은 OPNET에도 반영되어 있으며, WLAN의 파이프라인 스테이지에는 송신기와 수신기 사이의 거리가 300미터 이내인지를 검사하는 부분이 구현되어 있다.
한가지 주의하여야 할 점은, 송수신기 사이의 거리가 300미터를 넘는다고 할지라도 패킷을 전달하지 않는 것은 아니라는 것이다. 패킷 전달은 정상적으로 이루어지며, maximum propagation delay를 초과하는 상황이 발생하였다는 것을 DES 로그로 남길 뿐이다. 이전의 실험에서 1Km이상의 거리를 가지는 WiFi 노드들간에 통신이 가능했던 것은 이 때문이다.

실제 장비의 경우 수신된 프레임이 300미터 보다 멀리 떨어진 노드에서 보내져온 것인지(정확히는 propagation delay가 1usec를 초과하는지)를 정확히 알 수 있는 방법이 없으므로, 수신된 패킷을 최대한 처리하는 이러한 동작구조는 실제 시스템의 특성을 잘 반영한 것이라고 생각된다. 물론, 실제 환경에서라면 300미터 이상 멀어지기도 전에 SNR의 저하로 인하여 통신이 되지 않는 경우가 대부분일 것이다. 하지만, 이는 propagation delay와는 별개의 문제이며, 여기에서는 SNR이 충분히 유지되는 상황에서의 얘기이다.
WiFi 노드들간의 거리가 300미터를 초과하는 상황이 발생하는 시나리오의 경우 DES 로그를 살펴보면 다음과 같이 " Distance Limit Exceeded" Warning 메시지를 볼 수 있으며, 어느 노드 사이에 발생한 문제인지를 확인할 수 있다.

[1] IEEE Std 802.11, "Wireless LAN MAC and PHY Specifications", IEEE, 2007.

SS가 BS로 데이터를 전달히기 위해서는 반드시 BS로부터 대역폭 자원을 할당받아야만 한다. 대역폭을 할당받는 절차는 3가지 경우로 구분해볼 수 있는데, 1) UGS 또는 ert-PS connection인 경우, 2) rt-PS 또는 nrt-PS connection인 경우, 3) BE connection인 경우이다.
UGS나 ert-PS connection인 경우의 데이터 전송 절차는 다음 그림과 같다. BW 요청은 SS에서 보내지지 않으며, BS에서 내부적으로 생성된다. 이 BW 요청에 의해서 BW 자원이 할당되면 UL-MAP을 통해 SS에게 알려지고, SS는 할당된 BW를 이용하여 데이터를 BS로 전송한다.

rt-PS나 nrt-PS connection인 경우의 데이터 전송 절차는 다음 그림과 같다. BS는 해당 SS에 대해서 주기적인 polling을 UL-MAP을 통해서 하며, 이 때 전송할 데이터가 있으면 SS는 BW 요청 메시지를 BS로 보낸다. 이 요청에 의해서 BW 자원이 할당되면 UL-MAP을 통해 SS에게 알려지고, SS는 할당된 BW를 이용하여 데이터를 BS로 전송한다.

BE connection인 경우의 데이터 전송 절차는 다음 그림과 같다. Contention 방식의 BW 요청을 위한 자원 정보는 매 프레임마다 UL-MAP을 통해서 SS들에게 알려지며, 이 때 전송할 데이터가 있으면 SS는 BW 요청 메시지를 BS로 보낸다. 이 요청이 성공적으로 BS에게 전달되고 BW 자원이 할당되면, UL-MAP을 통해 SS에게 알려지고, SS는 할당된 BW를 이용하여 데이터를 BS로 전송한다.

데이터 패킷에 대한 송/수신 처리는 모두 wimax_mac 프로세스 모델에서 이루어진다. 상위계층(구체적으로는 IP계층)으로부터 패킷이 도착하면 idle 스테이트로부터 hl_pk 스테이트로 천이가 일어난다. hl_pk 스테이트에서는 다음 그림과 같이 패킷을 분류하여 적합한 CID를 찾아내고, 찾아낸 CID에 해당하는 conduit에 패킷을 저장한다.

Conduit는 데이터 패킷을 저장하는 큐와 QoS 적용을 위한 Shaper, 요청할 BW 크기 정보 (또는 BW 요청을 위한 큐) 등으로 구성되어 있다. SS에서 rtPS, nrtPS, BE와 같이 BW 요청이 필요한 connection의 데이터 저장 큐에 패킷이 들어오면, 요청할 BW 크기 정보도 이에 맞추어 업데이트 된다. 업데이트된 BW 요청정보는 폴링이나 Contention 과정을 통해 BS로 전달되고, 이에 대한 BW 할당이 이루어지면 스케줄러의 제어를 통해 데이터 큐에 쌓여있던 패킷이 전송된다. BS에서는 요청할 BW 크기 정보가 따로 저장되지 않고, 즉시 wimax_bs_control 프로세스로 전달된다.
Shaper는 아직까지 실제로 사용되지는 않는다.

"OPNET 기초다지기" 3.5절의 TCP 예제를 수행할 때, 15.0 이상의 버전을 사용할 경우 New Reno에 관한 결과가 시뮬레이션 결과가 교재와 달리 다음 그림처럼 Fast Recovery가 동작하지 않는 것처럼 보여지는 문제가 있다. (15.0 이후부터 현재의 최신 버전인 17.1까지 15.0, 16.0, 16.1, 17.1 버전 모두 동일한 현상을 보이고 있으며, 이는 15.0 버전에서의 TCP 모델 업데이트 때문인 것으로 생각된다.)

이 문제를 피해가기 위해서는 TCP 모델을 약간 수정해야만 한다. tcp_conn_v3 프로세스 모델의 FB를 열고, tcp_ack_check() 함수 선언을 찾는다. tcp_ack_check() 함수에서 New Reno 방식일 경우 호출되는 tcp_cwnd_stat_update() 함수(17.1 PL1 버전에서는 704 라인에 위치한다)를 주석처리하고, 그 아래쪽에서 New Reno 방식에 대한 Congestion window 업데이트가 수행되었음을 의미하는 플래그 설정(17.1 PL1 버전에서는 708 라인에 위치한다)을 역시 주석 처리한다. 프로세스 모델을 다시 컴파일하여 변경된 내용이 시뮬레이션에 적용되도록 해준다. 수정 후에 시뮬레이션 결과를 다시 살펴보면, 다음 그림처럼 New Reno에서도 Fast Recovery가 잘 동작하는 것을 확인할 수 있다.

조만간 출판 예정인 개정판에는 이 오류가 수정되어 있다.