네트워크 시뮬레이션 공방

"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을 전혀 사용할 수 없게 됩니다.

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에 의해 감지하면서 크게 낮아진 것을 확인할 수 있다.