네트워크 시뮬레이션 공방

OPNET WiMAX 모델에서는 ASN-GW를 위한 별도의 노드 모델을 제공하지 않으며, 일반적인 라우터 모델을 ASN-GW로 사용한다. 하지만, 단순히 라우터를 BS에 연결한다고 해서 ASN-GW로 동작하는 것은 아니며 BS와 ASN-GW로 사용할 라우터 사이에 터널링을 설정해 주어야 한다. BS에 반드시 ASN-GW가 연결될 필요는 없다.

다음 그림은 표준[1]에서 정의하고 있는 MS-initiated HO 절차(Figure J.3 참조)이며, "WiMAX 모델(97) - Handover"에서 설명한 OPNET WiMAX 모델에 구현된 절차는 MS-initiated HO와 일치한다. BS-initiated HO(Figure J.4참조)는 OPNET WiMAX 모델에서 지원하지 않는다.

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

"TCP Window Scaling(1) - LFN에서의 동작"에서 살펴본 것처럼 TCP Window Scale option을 사용하면 TCP의 전송율을 크게 증가시킬 수 있다. 하지만, 이러한 성능 개선은 LFN[1]인 경우에 나타나며, LFN이 아닌 곳에서는 TCP Window Scaling option을 사용하더라도 TCP 전송률은 개선되지 않는다.
LFN이 아닌 곳에서 TCP Window Scale option이 미치는 영향을 살펴보기 위해서, "TCP Window Scaling(1) - LFN에서의 동작"에서 사용한 시나리오들의 RTT가 0ms가 되도록 변경한다.
다음은 수정된 시나리오(즉, LFN이 아닌 망)에서 Window Scaling 속성을 사용하였을 때와 사용하지 않았을 때의 전송률(throughput)을 비교한 것이다.

Server 노드에서 STA 노드로 전달되는 트래픽 전송률에 아무런 차이가 없으며, 두 경우 모두 링크의 최대 전송 속도(45Mbps)를 모두 사용하고 있는 것을 알 수 있다. 이는 Window Scaling 기능에 문제가 있어서가 아니라, RTT(Round Trip Time)가 너무 작아서 16비트로 표현되는 윈도우 크기로도 링크의 최대 전송 속도(45Mbps)에 해당하는 성능을 TCP가 낼 수 있었기 때문이다.
실제로 이 경우에도 Window Scaling 기능이 잘 동작하고 있음은 다음 그림과 같이 CWND(Congestion Window) 크기를 통해 확인할 수 있다. "TCP Window Scaling(1) - LFN에서의 동작"에서와 마찬가지로 Window Scaling을 사용하지 않았을 경우 CWND는 작은 값을 가지는 반면, Window Scaling을 사용하는 경우 CWND는 매우 큰 값을 가지는 것을 볼 수 있다.

따라서, LFN이 아닌 경우에는 Window Scaling option을 사용하더라도 TCP 전송율의 개선은 기대할 수 없다.

[1] RFC 1323, "TCP Extensions for High Performance," IETF, 1992.

"OPNET 시뮬레이션 공방"에서 다루는 OPNET은 정확히는 OPNET Modeler를 의미합니다. OPNET사의 제품군에는 Modeler외에도 IT Guru, SP Guru나 APM이 있었습니다만, 회사 설립 초기에 Modeler를 주력으로 성장했기때문에 OPNET Modeler는 OPNET으로 통칭되었습니다. 이 블로그 이름을 "OPNET Modeler 시뮬레이션 공방"이 아니라 "OPNET 시뮬레이션 공방"으로 지은 이유도 이 때문이었습니다.
OPNET사는 2년전에 Riverbed사에 매각되었습니다만("OPNET, 리버베드에 인수됨" 참조), 그 이후로도 OPNET이라는 이름에는 변동이 없었고, OPNET Modeler에 대한 업데이트는 계속 이루어져왔습니다("OPNET Modeler/Release notes" 참조),
그런데, 최근 OPNET 이라는 명칭이 변경될 것 같다는 느낌이 듭니다. 다음은 Riverbed사 홈페이지의 제품 소개 화면을 오늘 캡춰한 것인데, Riverbed Modeler로만 소개되어 있을뿐 OPNET이라는 단어는 어디에도 없습니다.

OPNET이라는 단어가 사라진 Modeler 소개, 굉장히 낯서네요. 다음번 버전이 나와봐야 확실해질 것 같습니다만, 어쩌면 블로그 이름도 변경해야 할지도 모르겠네요. (하지만, "Riverbed Modeler"는 임팩트가 너무 약하군요)

OPNET TCP 모델에서는 Window Scale Option[1] 기능을 "Window Scaling"이라는 이름의 속성으로 제공한다. 다음 그림은 OPNET의 Window Scaling 속성 설정창을 보인 것이다.

그러면, Window Scaling이 적용되었을 때 실제로 성능 향상이 있는지 시뮬레이션을 통해 확인해보기로 하자. 다음 그림은 TCP Window Scaling 성능을 확인하기 위한 시험망 토폴로지이다.

ppp_wkstn 노드 모델(STA 노드)과 ppp_server 노드 모델(Server 노드), 그리고 Packet Discarder 노드 모델(Discarder_1, 2 노드)을 배치하고, 노드간을 단방향 ppp_adv 링크 모델을 사용하여 연결하였다. 링크의 전송 속도(data rate)는 DS3로 설정한다. (Discarder_1과 Discarder_2 노드는 이 시뮬레이션에서 실제로 사용되지는 않는다. 하지만, 이후의 TCP 파라미터 관련 시뮬레이션 결과들과의 비교를 쉽게 하기 위해서 이 시뮬레이션에서도 동일한 토폴로지로 구성하였다.) 링크 지연은 Server 노드와 STA 노드 사이의 RTT가 50ms가 되도록 설정한다. (이는 시험망을 LFN[1], 즉 "Long, Fat pipe Network"로 만들기 위해서이다.)

트래픽은 FTP를 사용하여 Server 노드에서 STA 노드로 50,000,000bytes 크기의 파일이 전달되도록 하였다. Window Scaling의 효과를 확인하기 위해서 STA 노드와 Server 노드의 TCP Window Scaling이 Disabled된 시나리오와 Enabled된 시나리오를 각각 저장하고, 시뮬레이션을 수행한다. (17.1 버전("OPNET Modeler 17.1 PL2 발표" 참조)까지는 Window Scaling 속성의 기본값이 Disabled였는데, 17.5 버전(OPNET Modeler 17.5 PL3 발표" 참조)부터 Enabled로 변경되었음에 유의하여야 한다.)

다음은 Window Scaling을 사용하면 TCP의 성능을 어떻게 개선시키는지 살펴보기 위해 Window Scaling 속성 사용 여부에 따른 전송율(throughput) 차이를 비교한 것이다.

Window Scaling을 사용하지 않았을 때는 최대 전송율이 불과 10Mbps 정도인 반면, Window Scaling을 사용하면 최대 전송율이 45Mbps로 크게 증가함을 확인할 수 있다. 또한, 전송율이 증가하므로 FTP 파일 전송에 걸리는 시간도 훨씬 짧아진다.
최대 전송율이 이렇게 증가한 것은 Window Scaling 사용에 따라 송/수신시에 사용하는 버퍼의 크기가 증가하였고, 이에 따라 Ack 없이 전송할 수 있는 데이터의 양이 증가하였기 때문이다. 이는 다음 그림과 같이 해당 TCP 연결의 Flight Size 결과를 통해 확인할 수 있다.

Window Scaling을 사용하지 않았을 때와 사용하였을 때의 CWND(Congestion Window) 크기를 비교해 보면 다음 그림과 같다. Window Scaling을 사용하지 않았을 경우 ssthresh 초기값으로 작은 수가 사용되므로 CWND 역시 작은 값을 가지는 반면, Window Scaling을 사용하는 경우 ssthresh 초기값으로 매우 큰 수가 사용되므로 CWND 역시 매우 큰 값을 가지는 것을 볼 수 있다.

[1] RFC 1323, "TCP Extensions for High Performance," IETF, 1992.

Handover는 MS의 이동에 따라 현재의 BS(serving BS)보다 더 신호강도가 좋은 BS가 발견되면 해당 BS (target BS)로 연결을 바꾸는 것이며, OPNET WiMAX 모델에서도 지원한다. 다음 그림은 OPNET WiMAX 모델에서의 (MS 요청에 의한) Handover 절차를 나타낸 것이다.

Scanning 과정에서 serving BS보다 더 신호강도가 좋은 target BS가 발견되면, serving BS로 MOB_MSHO-REQ 메시지를 보내서 Handover를 시작한다. Serving BS는 MOB_MSHO-REQ에 대한 응답으로 MOB_BSHO-RSP 메시지를 MS로 전송한다. (ASN-GW를 사용하는 경우라면 이 사이에 HO_Req 메시지를 target BS로 전송하고 HO_Rsp 메시지를 응답받는 과정이 필요하다. 이 경우에 대해서는 이후에 다시 다루도록 하겠다.) MS가 MOB_BSHO-RSP 메시지를 수신하면 MOB_HO-IND 메시지를 serving BS로 최종적으로 전송한 후, target BS에 대한 initial ranging 절차를 시작한다.
이러한 과정을 wimax_ss_control 프로세스 모델의 State diagram에서 추적해보면, 다음 그림과 같은 천이 과정을 따른다.

다음 그림은 표준[1]에서 정의하고 있는 관계(association)을 맺지 않는 Neighbor BS Scanning 절차중 MS 요청에 의한 경우인데([1]의 FIgure D.1, Figure D.3 참조), "WiMAX 모델(94) - Neighbor BS Scanning"에서 설명한 OPNET WiMAX 모델에 구현된 절차는 이와 일치한다. (BS 요청에 의한 Neighbor BS Scanning 절차도 표준과 동일하게 OPNET WiMAX 모델에서 지원된다)

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

SITL 게이트웨이를 포함하는 시나리오 수행시 다음 그림과 같이 bufferoverflowu.lib 파일을 찾을 수 없다는 에러가 발생하는 경우가 있다.

여기에서 에러의 원인에 대한 주요한 메시지는 다음과 같다.

----
Errors reported by the binder program follow
(these messages have been saved in (C:\Users\opnet\op_admin\tmp\bind_err_7972):
LINK : fatal error LNK1104: 'bufferoverflowu.lib' 파일을 열 수 없습니다.

이 에러는 bufferoverflowu.lib 라이브러리 파일을 무시하도록 Common Network Repositories Flags를 설정하면 해결된다.

OPNET Voice Application에서 사용하는 Jitter의 의미와 계산방법은 "Delay Variation과 Jitter의 차이"에서 살펴본 바 있다. 그러면 Jitter 값이 어느 정도의 범위를 가지는 지에 대해서 조금 더 살펴보도록 하자.
다음 그림은 ip32_cloud 노드 모델을 이용하여 normal(0.01, 0.005) 분포("분포 함수(1) - 정규분포" 참조)의 Packet Latency를 발생시켰을 때("네트워크 Jitter(1) - VoIP 실험을 위한 네트워크 Jitter 설정" 참조), G.711 코덱을 사용하는 단말의 Voice Application단에서 측정된 Jitter를 나타낸 것이다(Frame Size : 10msec, Voice Frames per Packet: 2).

이 실험의 경우, Jitter이 범위가 -20ms ~ 260ms 범위를 가지는 것을 볼 수 있다. normal(0.01, 0.005) 분포를 사용하였을 때 IP 패킷이 약 300ms 정도까지의 지연시간을 가지는 것을 고려하면("네트워크 지터(4) - Packet Latency 측정" 참조), 약 260ms까지의 Jitter를 가지는 것은 자연스럽다.
그런데, Jitter 값의 음수 범위는 왜 정확히 -20ms까지인 것일까? 이는 실험에서 사용된 VoIP 코덱의 프레임 크기 및 IP 패킷당 프레임수와 관련이 있다. 앞의 실험에서는 G.711 코덱을 사용하였으므로 2개의 10ms 프레임을 하나의 IP 패킷(정확히는 RTP 패킷)에 담아 전송하도록 하였다. 따라서, 송신측에서 IP 패킷간의 간격은 20ms이며, 패킷별 지연시간의 변동으로 인해서 수신측에 패킷이 동시에 도착할 경우 Jitter는 -20ms가 된다. Voice 패킷은 순서대로 재생되므로 Jiiter 값의 음수 범위는 -20ms까지로 제한 된다. 다음 그림은 지터가 음수값을 가지는 경우의 송/수신 시간 관계를 나타낸 것이다.

Scanning은 HO를 하기전에 주변 기지국(BS)들로부터의 수신신호 강도를 측정하는 것이며, OPNET WiMAX 모델에서도 사용된다. 다음 그림은 OPNET WiMAX 모델에서의 (MS 요청에 의한) Scanning 절차를 나타낸 것이다.

MS에 수신된 신호의 SNR이 기준값 이하로 떨어지면 MOB_SCN-REQ 메시지를 전송하여 Scaning 절차를 시작한다. (BS에 의해서 Scanning이 시작되는 경우라면 MOB_SCN-REQ 메시지는 생략된다) MOB_SCN-REQ 메시지를 수신한 BS는 MOB_SCN-RSP 메시지를 통해 언제부터 얼마 동안의 시간동안 Scanning을 수행할 것인지를 MS에게 알려준다.
MOB_SCN-RSP 메시지를 수신한 MS는 지정된 시간(offset_M 시간이후)부터 주변 BS들로부터 수신되는 신호의 SNR을 (DL-MAP이 수신될 때마다) 측정한다. 주변 BS들의 목록은 MOB_NBR-ADV 메시지("WiMAX 모델(91) - Neighbor Advertisement" 참조)를 통해 알려진 것을 사용한다.
이러한 과정을 wimax_ss_control 프로세스 모델("WiMAX 모델(9) - wimax_ss_control 프로세스 모델" 참조)의 State diagram에서 추적해보면, 다음 그림과 같은 천이 과정을 따른다.