네트워크 시뮬레이션 공방

Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 Maximum Segment Size(MSS)를 설정할 수 있는 기능을 제공한다.

사용자가 직접 임의의 크기를 지정해 주거나 MAC 종류별로 사전에 정의된 값을 선택할 수 있으며, 사전에
값이 정의되어 있어 선택 가능한 항목은 다음과 같다. 기본값은 "Auto-Assigned" 이다.

- Auto-Assigned
- 536
- ATM
- Ethernet
- FDDI
- Frame Relay
- Token Ring (4Mbps)
- Token Ring (16Mbps)
- WLAN

기본 정의된 MSS 값은 해당 인터페이스별 MTU 값에서 40바이트만큼 작은 값에 해당한다.

Fast Retransmit 후에 Slow Start를 수행하지 않고, 바로 Congestion avoidance 상태에서 전송을 계속하여 전송 능력을 향상시키는 방법을 Fast Recovery라고 한다("OPNET 기초다지기" 참조). OPNET에서의 Fast Retransmit/Fast Recovery 파라미터 설정 방법은 17.5 버전("OPNET Modeler 17.5 PL3 발표" 참조)부터는 변경되어서, 17.1 버전까지의 설정방법과 17.5 버전부터의 설정 방법에서 차이가 있다.
다음 그림은 OPNET 16.0 버전에서 제공하는 Fast Recovery 관련 속성 설정창을 보인 것이다(17.1 버전 까지 동일).

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

- Version/Flavor : TCP의 특색을 표현하는 용도이며, 시뮬레이션에는 아무런 영향을 미치지 않는다. 기본값은 "Unspecified".
- Fast Recovery : Fast Recovery 알고리즘의 적용 여부 및 적용되는 Fast Recovery 방식. Disabled, Reno, New Reno 중에서 선택 가능하다. 기본값은 Reno 이다.

다음 그림은 OPNET 17.5 버전에서 제공하는 Fast Retransmit/Fast Recovery 관련 속성 설정창을 보인 것이다.

- Flavor : TCP의 특색을 지정하는 용도이며, 시뮬레이션에 영향을 미친다. Unset, Standard, Tahoe, Reno, New Reno, CUBIC 중에서 선택되며, Tahoe, Reno, New Reno, CUBIC인 경우에 Fast Retransmit/Fast Recovery 알고리즘이 적용된다. 기본값은 New Reno이다.

즉, 17.1 버전까지는 Fast Retransmit 적용 여부("TCP 재전송(7) - Fast Retransmit 파라미터 설정" 참조)와는 별개로, Fast Recovery 적용 여부 및 방식 선택이 가능했다. 이는 시뮬레이션 관점에서는 매우 높은 자유도를 제공하는 것이만, 관련 사항들을 정확히 알지 못하는 초보자들에게는 혼란을 주는 특성이었다. 17.5 버전부터 Fast Retransmit/Fast Recovery 설정 방식이 변경된 것은, 자유도를 일부 제한하고서라도 이러한 사용자 혼란을 막기 위한 것으로 보인다.

동일 채널 간섭(Co-channel interference)은 인접 기지국에서 사용하는 동일 주파수 채널 신호에 의해서 간섭이 발생하는 것인데, OPNET WiMAX 모델에도 반영되어 있다. 다음 그림은 OPNET WiMAX 모델에 적용된 동일 채널 간섭의 개념을 보인 것이다.

같은 셀(정확히는 섹터) 내에서 발생하는 신호는 동일 채널 간섭에서 고려하지 않으며, 다른 셀에서 발생한 신호만을 동일 채널 간섭 대상 신호로 간주한다. 즉, WiMAX에서 사용하는 OFDMA 방식에서는 기지국이 중첩되지 않는 자원(주파수/시간)을 할당해주므로, 같은 기지국의 통제에 의해서 발생하는 신호는 주파수/시간이 중복되지 않을 것이기 때문이다.
따라서, 동일 채널 간섭을 일으키는 대상 패킷을 기지국과 단말의 입장으로 구분하여 보면 다음과 같다.

- 기지국: 다른 기지국에 속해있는 단말(Cell ID가 다른)로부터 수신되는 패킷
- 단말: 다른 기지국(Cell ID가 다른)으로부터 수신되는 패킷

지난 12월17일자로 Riverbed Modeler 18.0.2 버전이 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.0.1 발표" 참조).
Release note에 따르면 기능상에 주요 변화는 없으며, 버그 수정(LTE 모델 관련 2건)과 release notes 호출메뉴 삭제가 변경된 사항입니다. (Riverbed Modeler로 바뀌더니, 이런 사소한 사항으로도 버전 업 발표를 하는군요...)
그리고, 18.0.1 버전의 변경사항도 이번 release note에 설명되었네요. 역시나 버그 수정(LTE 3건, WiMAX 1건, 기타 3건)이 전부입니다.

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

패킷 손실률이 증가하면 초기에는 MOS가 급격히 감소한다. 하지만, 나중에는 패킷 손실률이 증가하여도 MOS는 조금씩 감소한다. 즉, 패킷 손실률이 낮을 때(10% 이하)에는 패킷 손실률에 따라 MOS가 크게 영향을 받지만, 패킷 손실률이 높을 때(40% 이상)에는 패킷 손실률이 변화하여도 MOS가 받는 영향은 크지 않다.
본 실험에서 패킷 손실은 네트워크를 통해 전송되는 도중 발생하는 비트 에러를 통해 발생시킨 것이다. MOS 결과값을 BER(Bit Error Rate)와의 관계 측면에서 살펴보면 다음 그림과 같다.

BER이 MOS에 미치는 영향은 패킷 손실률이 MOS 미치는 영향과 비슷한 경향을 보여주며, 이는 논리적으로 쉽게 예측할 수 있는 결과이다. 다만, 패킷 손실률의 경우와 비교해보면, BER이 낮을 때에는 MOS에 좀더 급격한 변화를 발생시키며 BER이 높을 때에는 MOS에 좀더 완만한 변화를 발생시킨다.

TCP에서의 재전송은 Timeout과 중복(Duplicate) ACK의 두가지 요소에 의해서 제어되며, Riverbed Modeler(OPNET) TCP 모델 또한 이 두 가지 요소 기능을 모두 제공한다. Timeout에 의한 재전송은 "TCP 재전송(3) - Timeout"에서 살펴보았으며, 여기에서는 Duplicate ACK에 의한 재전송이 어떻게 수행되는지 살펴보기로 한다.
TCP 재전송 시험망을 다음 그림과 같은 토폴로지로 구성하고("TCP Window Scaling(1) - LFN에서의 동작"의 시험망 토폴로지 참조), Server 노드와 STA 노드 사이의 RTT는 100ms가 되도록 설정한다.

패킷 손실을 발생시키기 위해서 Packet Discard 노드의 Packet Discard Configuration 속성을 다음 그림과 같이 200초에 패킷 1개를 폐기하도록 설정한다.

STA 노드와 Server 노드의 TCP Window Scaling은 Disabled시킨다. Duplicate ACK에 의한 재전송이 수행되도록 하기위해서, Server 노드의 TCP Fast Retransmit는 Enabled로 설정되어 있는지 확인한다.
다음은 재전송이 일어났음을 확인하기 위해서 Server 노드에서 송신한 Retransmission Count와 Received Segment Ack Number를 보인 것이다.

200.12초의 재전송이 Duplicate ACK에 의한 것이며, 사용된 Duplicate ACK의 수는 3임을 다음 그림과 같이 Received Segment Ack Number를 보다 확대한 결과를 통해 확인할 수 있다.

재전송이 일어난 시점의 Duplicate ACK이 3개임을 확인할 수 있으며, 이는 Duplicate ACK Threshold 속성값이 3으로 설정되어 있기 때문이다.("TCP 재전송(7) - Fast Retransmit 파라미터 설정" 참조).
다음 그림은 Server 노드의 CWND 크기 변화를 보인 것이다. CWND 크기가 200초 무렵까지는 계속 증가하다가 패킷 손실을 200.12초에 Duplicate ACK에 의해 감지하면서 크게 낮아진 것을 확인할 수 있다.

Duplicate ACK에 의한 TCP 재전송을 Fast Retransmit라고 한다. OPNET에서의 Fast Retransmit/Fast Recovery 파라미터 설정 방법은 17.5 버전("OPNET Modeler 17.5 PL3 발표" 참조)부터는 변경되어서, 17.1 버전까지의 설정방법과 17.5 버전부터의 설정 방법에는 차이가 있다.
다음 그림은 OPNET 16.0 버전에서 제공하는 Fast Retransmit 관련 속성 설정창을 보인 것이다(17.1 버전까지 동일).

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

- Version/Flavor : TCP의 특색을 표현하는 용도이며, 시뮬레이션에는 아무런 영향을 미치지 않는다. 기본값은 "Unspecified".
- Fast Retransmit : Fast Retransmit 알고리즘의 적용 여부. 기본값은 "Enabled".
- Duplicate ACK Threshold : Fast Retransmit 알고리즘 적용시 재전송 수행을 위해 필요한 Duplicate ACK의 수, 기본값은 3.

다음 그림은 OPNET 17.5 버전에서 제공하는 Fast Retransmit 관련 속성 설정창을 보인 것이다.

- Flavor : TCP의 특색을 지정하는 용도이며, 시뮬레이션에 영향을 미친다. Unset, Standard, Tahoe, Reno, New Reno, CUBIC 중에서 선택되며, Tahoe, Reno, New Reno, CUBIC인 경우에 Fast Retransmit 알고리즘이 적용된다. 기본값은 "New Reno"이다.
- Duplicate ACK Threshold : Fast Retransmit 알고리즘 적용시 재전송 수행을 위해 필요한 Duplicate ACK의 수(17.1 이전 버전과 동일), 기본값은 3.

ITU Vehicular는 NLOS 환경에서의 pathloss 모델로서 다음과 같은 수식에 의해서 계산된다.

이 수식은 ITU M.1225 표준문서[1]의 "vehicular"를 위한 pathloss 모델 수식과 정확히 동일하다. 이 pathloss 수식은 shadow fading을 포함하여, shadow fading 값은 GUI를 통해 설정된 표준편차 값을 이용하여 시뮬레이션 수행시에 랜덤하게 생성된다. Pathloss 모델로 "Vehicular"를 선택하면 표준편차 값은 10으로 자동 설정된다(변경도 가능하다).
ITU Vehicular 모델의 입력값과 출력값을 개념적으로 살펴보면, 거리, 주파수, 기지국 높이를 입력받아서 shadow fading을 포함하는 pathloss 값을 결과값으로 출력한다.

[1] ITU-R Recommendation M.1225, "Guidelines for evaluation of radio transmission technologies for IMT-2000," 1997.

Riverbed Modeler(OPNET) 시뮬레이션에서 IP 패킷들이 어떤 경로를 거쳐 전달되었는가를 다음의 방법들로 확인할 수 있다.
1) 라우터의 라우팅 테이블 확인(DES)
2) Demand Traffic Flow에 대한 라우팅 경로 표시(DES)
3) Demand Traffic Flow에 대한 라우팅 가능 경로 표시(Flow Analysis)
4) 두 노드간의 라우팅 가능 경로 표시(Flow Analysis)

라우터의 라우팅 테이블 확인은 DES 시뮬레이션 수행 후, 각 라우터의 IP Forwarding Table 정보를 보고 IP 패킷의 전달경로를 추론하는 방법이다. 가장 근본적인 방법으로 시뮬레이션에 사용한 트래픽의 종류에 상관없이 사용할 수 있다는 장점이 있다. 하지만, 개별 라우터에 기록된 Destination과 Next Hop Address 정보를 보고 사용자가 일일히 추적해야 하므로, 사용하기 어렵다는 단점이 있다. (특히, Auto Assign으로 IP 주소를 설정했을 경우 분석하기가 까다롭다.)

Demand Traffic Flow에 대한 라우팅 경로 표시는 DES 시뮬레이션 수행 후, ip_traffic_flow와 같은 Demand Traffic Flow에 선정된 라우팅 경로를 네트워크 토폴로지 상에 표시해주는 방법이다. 다음 그림처럼 라우팅 경로가 네트워크 토폴로지 상에 표시된다.

Demand Traffic Flow에 대한 라우팅 가능 경로 표시는 Flow Analysis 시뮬레이션 수행 후, ip_traffic_flow와 같은 Demand Traffic FLow에 선정 가능한 라우팅 경로들을 네트워크 토폴로지 상에 표시해주는 방법이다. 시뮬레이션에서 선택된 하나의 경로가 표시되는 것이 아니라, 선택 가능한 경로들이 표시되는 것이라는 점에 유의할 필요가 있다.

두 노드간의 라우팅 가능 경로 표시는 Flow Analysis 시뮬레이션 수행 후, 지정된 두 노드간에 선정 가능한 라우팅 경로들을 네트워크 토폴로지 상에 표시해주는 방법이다. 역시 시뮬레이션에서 선택된 하나의 경로가 표시되는 것이 아니라, 선택 가능한 경로들이 표시되는 것이라는 점에 유의할 필요가 있다.

OPNET Debugger를 사용하여 무선망에서 패킷 전송 애니메이션을 보는 방법에 대해서는 "무선망에서 패킷 전송 애니메이션 보기"에서 살펴보았다. 이 방법을 사용하면 이동중인 무선 노드와의 패킷 전송 애니메이션을 보는 것도 가능하다. (만약, 노드 이동에 대한 애니메이션만을 보고 싶다면 "패킷 전송 애니메이션 보기"에서 설명한 2-D Animation Viewer를 사용하여도 된다.)
다음 그림은 WiFi 단말간의 패킷 전송 애니메이션을 보기위한 예제망 구조를 나타낸 것이다.

무선 단말이 이동하여 거리가 멀어짐에 따라 패킷 전달이 이루어지지 못하는 과정을 관찰하기 위해서, Source 노드에서 Dest 노드로 전달하는 단방향 UDP 트래픽을 Custom Traffic으로 설정하였다.
OPNET Debugger의 Show Animation 기능을 이용하여 이 시나리오에 대한 패킷 전달 애니메이션을 살펴보면 다음 영상과 같다.

Source 노드와 거리가 가까울때에는 Dest 노드로 패킷이 전달되지만, Dest 노드가 이동하여 거리가 멀어지면 패킷이 전달되지 않는 것을 다음 그림처럼 쉽게 확인할 수 있다. Dest 노드가 더 이동하여 다시 Source 노드와의 거리가 가까워지면, 패킷 전달도 다시 이루어진다.