네트워크 시뮬레이션 공방

"TCP Window Advertisement(1) - 파라미터 설정"에서 살펴본 것처럼 "Receive Buffer Usage Threshold (of RCV BUFF)" 속성의 기본값은 0.0 이며, 항상 수신 버퍼 크기 전체가 수신 가능 윈도우 크기로 사용된다. "TCP Window Scaling(3) - 예제"의 시나리오에서 TCP Conneciton-->Remote Receive Window Size (bytes) 결과를 Server 노드에서 관찰하면 Receive Window가 항상 일정한 것은 이 때문이다.

이는 Window XP나 Window 7과 같은 현재의 일반적인 운영체계에서는 맞지 않다. 다음은 Wireshark를 이용하여 64,512바이트의 수신 버퍼를 사용하는 Windows XP 시스템에서 내보내는 Advertisement Window 값을 관찰한 것이다. 수신 버퍼 전체 크기가 항상 Advertisement Window 값으로 사용되지는 않는다는 것을 확인할 수 있다.

Advertisement Window 크기에 변화를 주기위해서 다음과 같이 STA 노드의 "Receive Buffer Usage Threshold (of RCV BUFF)" 속성값을 변경한다. (여기에서 0.1은 예를 들기 위해 임의의 값을 선택한 것이며, 대상 시스템에 따라 값이 달라질 수 있다.)

시뮬레이션을 수행한 후, Receive Buffer Usage Threshold가 0.0인 경우와 0.1인 경우에 대해 Server 노드에서 수신된 수신 가능 윈도우 크기를 살펴보면 다음과 같다. 수신 가능 윈도우 크기가 59,095 ~ 65,535바이트로 시간에 따라 변화하였음을 확인할 수 있다.

Riverbed Modeler(OPNET) SITL 모듈을 사용하면 Riverbed Modeler(OPNET) 시뮬레이터와 실세계 장비를 연결하는 SITL 게이트웨이 노드(sitl_virtual_gateway_to_real_world)에서는 시뮬레이션 패킷과 실세계 패킷 간의 변환이 일어난다. 이 때 OPNET 17.5 PL5 버전("OPNET Modeler 17.5 PL5 발표" 참조)을 기준으로 SITL에서 패킷 변환이 지원되는 프로토콜 및 관련된 Riverbed Modeler(OPNET) 패킷 포맷은 다음과 같다. IPv6, ICMPv6, IGMPv2, WLAN 프로토콜에 대한 지원은 15.0 PL0 버전에서, BGP 프로토콜에 대한 지원은 17.1 PL1 버전("OPNET Modeler 17.1 PL1 발표" 참조)에서 추가된 것이다.

- Ethernet : ethernet_v2
- ARP : arp_v2
- IPv4 : ip_dgram_v4
- IPv6 : ip_dgram_v6
- ICMPv4/v6 : ip_icmp_echo
- IGMPv2 : ip_igmp
- TCP : tcp_seg_v2
- UDP : udp_dgram_v2
- RIPv1/v2 : rip_message2
- OSPFv2 : ospf_hello_v2, ospf_dbase_desc_v2, ospf_ls_request_v2, ospf_ls_update_v2, ospf_ls_ack_v2
- BGP : bgp_keepalive_packet, bgp_notification_packet, bgp_open_packet, bgp_update_packet
- WLAN : wlan_mac

이외에 SITL에서 패킷 변환을 지원하지 않는 프로토콜 패킷에 대한 전달이 요구되는 경우에는 unformatted 패킷을 사용하여 변환되지 않은 형태로 전달한다.

"ptime"은 SDP atribute중 하나로써, 한개의 RTP 패킷에 담겨있는 미디어 정보의 재생시간을 의미한다[1, 2]. 그런데, Riverbed Modeler(OPNET)의 SIP 모델에는 ptime 설정에 관련된 속성항목이 없으므로, Riverbed Modeler(OPNET)에서는 ptime을 직접 설정해줄 수 없다.
따라서, ptime에 관련된 시뮬레이션 수행시에는 일부 제약 사항이 발생한다(Ex: 송/수신자간의 ptime 협상과정 진행에 관련된 사항들은 시뮬레이션 할 수 없음). 하지만, RTP 패킷에 실리는 정보의 양을 지정하기 위한 속성항목들을 별도로 제공하고 있으므로, 설정된 ptime 값에 의한 효과를 시뮬레이션할 때에는 문제가 없다(Ex: ptime에 따른 트래픽 발생량이나 MOS 변화는 시뮬레이션 가능).

[1] M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description Protocol," RFC 4566, IETF, Jul. 2006.
[2] S. Casner, "Media Type Registration of RTP Payload Formats," RFC 4855, IETF, Feb. 2007

OPNET WiMAX 모델에서 동일 채널 간섭(Co-channel interference)은 Burst 단위로 계산되며, 이 Burst는 OPNET에서 패킷으로 표현된다. (Burst가 패킷으로 어떻게 표현되는지에 대해서는 "WiMAX 모델(59) - IE Type4에서의 sub-burst 분할"과 "WiMAX 모델(61) - UL-MAP IE 정보"참조) OPNET WiMAX Burst는 주파수 자원에 대한 할당정보(subchnl_start, subchnl_count)를 가지고 있으며, 이 정보를 이용하여 동일 주파수 대역을 사용하는 이웃 기지국(섹터) Burst와의 간섭 정도를 계산한다. 이 때, 동일 주파수 대역을 사용한다고 하더라도, Permutation Type과 Permutation Base에 따라 각 채널(Sub-channel)에서 사용하는 서브 캐리어(Sub-carrier)는 서로 상이할 수 있다. 따라서, 각 기지국별 Subcarrier-to-subchannel 매핑 정보를 이용하여 간섭이 일어나는 두 기지국 채널들간 subcarrier 중첩여부를 계산하고, 이 정보를 이용하여 다수의 채널들로 구성된 Burst간의 간섭 정도를 계산한다.

"TCP Receive Buffer"에서 살펴본 것처럼 Riverbed Modeler(OPNET) TCP 모델은 사용자가 수신 버퍼 크기를 설정할 수 있는 속성들을 제공한다. 이 때 수신 버퍼와 관련하여 Riverbed Modeler(OPNET) TCP 모델에서 제공하는 속성이 한 가지 더 있는데, 바로 "Receive Buffer Usage Threshold (of RCV BUFF)"이다.

"Receive Buffer Usage Threshold (of RCV BUFF)" 속성 값은 상위(응용) 계층으로 데이터를 넘겨주는 기준 비율을 의미한다. 0.0 ~ 1.0 범위의 값으로 설정할 수 있으며, 수신 버퍼에 쌓인 데이터가 이 비율에 도달하면 이 비율에 해당하는 크기의 데이터는 즉시 상위 계층으로 넘겨준다고 가정된다.
따라서, 송신측에게 알려줄 수신 가능 윈도우(Advertisement Window) 크기는 "TCP Receive Buffer"에서 산출된 수신 버퍼 크기와 이 ""Receive Buffer Usage Threshold (of RCV BUFF)" 비율에 의해 시뮬레이션 시간동안 지속적으로 재계산된다. 기본값은 0.0이며, 항상 수신 버퍼 크기 전체가 수신 가능 윈도우 크기로 사용된다.

수신 버퍼(Receive Buffer)는 TCP 흐름제어를 위한 RWIN 값으로 사용되며, Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 수신 버퍼를 설정할 수 있는 속성들을 제공한다.

각 속성항목의 용도는 다음과 같다.

- Receive Buffer (bytes) : 수신 버퍼 크기. 수신 버퍼 크기를 직접 명시하는 방법외에 Default로 설정할 수도 있다. Default로 설정되어 있으면, MSS("TCP MSS" 참조)의 4배로 계산된다. 17.1 PL2 버전 이상에서는 Auto-Tuning으로 설정하는 것도 가능하다("OPNET Modeler 17.1 PL2 발표" 참조).
- Receive Buffer Adjustment : 수신 버퍼 크기를 MSS의 배수로 조정할 것인지의 여부를 지정. None, Windows Based, Solaris Based 세 가지가 선택 가능하다. None이면 수신 버퍼 크기를 조정하지 않고 사용한다. Windows Based이면 MSS의 짝수배로 조정한다. Solaris Based이면 MSS의 배수로만 조정한다.

"Receive Buffer Usage Threshold (of RCV BUFF)" 항목은 송신측에 알려줄 수신 가능 윈도우(Advertisement Window) 계산에 관련된 것이므로 이후의 글에서 다시 자세히 살펴보겠다.

"VoIP MOS 계산"에서 설명하였듯이, 전달지연(Delay)은 MOS를 결정하는 중요한 요소이다. 그러면, 전달지연이 MOS에 어떠한 영향을 미치는지 조금 더 자세하게 살펴보도록 하자. 다음 그림은 VoIP 트래픽이 흘러가는 네트워크의 패킷 전달지연을 80 ~ 580ms 범위에서 변화시켰을 때, MOS 값 변화에 대한 Riverbed Modeler(OPNET) 시뮬레이션 결과를 나타낸 것이다.

전달 지연이 증가하여도 초기에는 MOS 값은 크게 감소하지 않는다. 하지만, 나중에는 전달지연의 증가에 따라 MOS가 급격히 감소한다. 즉, 전달지연이 작을 때(약 150ms 이하)에는 전달지연이 MOS에 크게 영향을 미치지 않지만, 전달지연이 클 때(약 150ms 이상)에는 전달지연에 따라 MOS가 크게 영향을 받는다. 이러한 경향은 패킷 손실률의 경우("MOS와 패킷 손실률의 관계" 참조)와는 확연히 다른 것이다.

"SITL 사용시 NetBIOS 트래픽 처리"에서 설명한 것처럼 SITL 시뮬레이션 수행시에 Riverbed Modeler(OPNET)에서 처리할 수 없는 패킷이 실세계 장비로부터 유입되면 에러를 발생시키며, NetBIOS 패킷은 이러한 문제를 일으키는 대표적인 사례 이다.
Riverbed Modeler(OPNET)에서 처리할 수 없는 실세계 트래픽 문제를 해결하는 한가지 방법은 SITL 패킷 필터를 사용하여 해당 패킷들이 Riverbed Modeler(OPNET)으로 유입되지 않도록 차단하는 것이다. 그런데, 이 방법의 경우 문제를 일으키는 패킷들을 일일히 SITL 패킷 필터에 정의해주어야 한다는 불편함이 있다. 즉, NetBIOS 트래픽처럼 문제를 일으키는 패킷들이 있다면, 해당 패킷의 특성을 분석해서 SITL 패킷 필터에 추가해 주어야 한다.
이러한 불편함 없이 Riverbed Modeler(OPNET)에서 처리할 수 없는 실세계 트래픽 문제를 해결하는 또 다른 방법은 해당 패킷들이 수신되면 폐기하도록 Riverbed Modeler(OPNET) 프로세스 모델을 수정하는 것이다. Riverbed Modeler(OPNET)에서 처리할 수 없는 실세계 트래픽들 중에서도 실제로 문제를 일으키는 트래픽들은 대부분 UDP를 사용하는 브로드캐스트 트래픽이다. 따라서, UDP 프로세스 모델에 수신된 패킷들 중 Riverbed Modeler(OPNET)에서 정상적으로 처리할 수 없는 패킷들만 미리 골라서 폐기시키는 기능을 추가해주면 시뮬레이션이 중단되는 에러를 근본적으로 해결할 수 있다.

물론 완벽한 해결을 위해서라면 TCP 프로세스 모델에도 동일한 기능을 추가해주어야 한다. 하지만, 브로드캐스트 트래픽은 일반적으로 TCP를 사용하지 않으므로, 사용자가 의도적으로 발생시키지 않으면 Riverbed Modeler(OPNET) 시나리오 상의 노드를 목적지로 하는 TCP 트래픽이 있는 경우는 거의 없다.

"WiMAX 모델(114) - 동일 채널 간섭"에서 살펴본 것처럼, OPNET WiMAX 모델에는 다른 기지국(섹터)로부터 발생되는 신호에 대한 동일 채널 간섭(Co-channel interference)이 반영되어 있다. 이 때, 시뮬레이터 구현상의 편의를 위하여 몇 가지 사항들을 가정하고 있으며, 이 외의 경우에 대해서는 처리해주지 않는다. 즉, OPNET WiMAX 모델의 제한점이라고 할 수 있다.

1) 간섭(interference)는 동일한 PHY Profile을 사용하는 기지국/단말들 사이의 경우에 대해서만 고려한다. 따라서, 조금이라도 다른 PHY Profile을 사용하는 기지국(섹터) 사이에는 동일 채널 간섭이 발생하지 않는 것으로 처리된다.
2) 기지국(섹터)들간의 서브 프레임 경계가 확실히 일치한다고 가정한다. 즉, DL 프레임은 DL 프레임끼리만, UL 프레임은 UL 프레임 끼리만 간섭이 발생하며, DL 프레임과 UL 프레임간에 간섭이 발생하는 경우는 고려하지 않는다.
3) DL 서브 프레임 내에서 Permutation Zone의 경계는 이웃 기지국(섹터)와 다를 수 있다. 이는 MAP에 사용되는 Zone과 데이터 전달에 사용되는 Zone이 서로 다른 Permutation Zone 방식을 사용할 수 있기 때문이다(이는 16.0 버전에서 변경된 기능으로, 15.0 버전 이전에서는 DL에도 한 개의 Permutation Zone만 사용될 수 있었다). UL에는 한 개의 Zone Type만 사용되므로 Zone의 경계가 이웃 기지국(섹터)와 항상 일치한다(기지국들간의 서브 프레임 경계가 정확히 일치한다고 가정하고 있으므로).

OPNET Modeler 16.1 버전은 2011년에 나왔으며, 주요 모델의 업데이트 내용은 당시에 살펴본 바 있습니다("OPNET Modeler 16.1 PL1 발표" 참조). 그런데, OPNET Modeler 16.1 버전에서는 이외에도 사용 환경상의 중요한 변화가 몇 가지 더 있었기에, 시간이 많이 지났지만 이 부분을 다시 한번 정리하고자 합니다.

1) 설치 디렉토리 변경 : 16.0 버전까지는 OPNET Modeler의 기본 설치 디렉토리가 "C:\Program Files\"이었는데(예: "C:\Program Files\OPNET\16.0.A"), 16.1 버전부터는 윈도우 Vista 이후의 윈도우 OS에 설치시 "C:\"로 변경되었습니다(예: "C:\OPNET\16.1.A"). 이는 사용자 권한 문제 때문인  것으로 생각됩니다. 윈도우 Vista나 윈도우 7에서는 UAC 기능때문에 "C:\Program Files\" 하나부의 파일에 접근시 관리자 권한이 필요하며, 이 때문에 OPNET 실행시 여러가지 문제를 일으켰기 때문입니다. 윈도우 XP에서는 계속 "C:\Program Files\"가 기본 설치 디렉토리로 사용됩니다.

2) OPNET 환경변수 설정파일 명칭 변경 : 16.0 버전까지는 OPNET 환경변수 파일명으로 "env_db버전명"이 사용되었는데(예: "env_db16.0"), 16.1 버전부터는 "opnet-버전명.prefs"로 변경되었습니다(예: "opnet-16-1.prefs"). 환경 변수 파일의 위치는 "사용자 계정\op_admin"으로 동일합니다.

3) MSVC 6.0 부분적 지원중단 : "OPNET Modeler 17.1 버전 Visual C/C++ 6.0 지원중단"에서 살펴본 것처럼, 16.1 버전의 LTE 모델에서는 MSVC 6.0을 지원하지 않습니다. MSVC 6.0을 사용하여 16.1 버전의 LTE 모델에 대한 컴파일을 시도하면 다음과 같은 에러들이 발생합니다.

=============================================================================================
C:/Program Files/OPNET/16.1.A/models/std/lte/lte_ue_as.pr.c(3414) : warning C4761: integral size mismatch in argument; conversion supplied
C:/Program Files/OPNET/16.1.A/models/std/lte/lte_ue_as.pr.c(7562) : warning C4761: integral size mismatch in argument; conversion supplied
C:/Program Files/OPNET/16.1.A/models/std/lte/lte_ue_as.pr.c(8357) : error C2520: conversion from unsigned __int64 to double not implemented, use signed __int64
C:/Program Files/OPNET/16.1.A/models/std/lte/lte_ue_as.pr.c(8359) : error C2520: conversion from unsigned __int64 to double not implemented, use signed __int64
C:/Program Files/OPNET/16.1.A/models/std/lte/lte_ue_as.pr.c(9153) : error C2520: conversion from unsigned __int64 to double not implemented, use signed __int64
C:/Program Files/OPNET/16.1.A/models/std/lte/lte_ue_as.pr.c(9222) : error C2520: conversion from unsigned __int64 to double not implemented, use signed __int64
=============================================================================================
17.1 버전부터는 MSVC 6.0을 전혀 사용할 수 없게 됩니다.