네트워크 시뮬레이션 공방

Riverbed Modeler 18.10.0 버전이 지난 4월29일자로 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.9.0 발표" 참조). Release notes에는 4월21일자로 되어 있고 홈페이지에는 4월29일자로 되어있는데, 4월28일에 홈페이지를 확인했을 때는 없었으므로 4월29일이 맞는 것 같습니다. 아쉽게도, 이번에도 메일 공지가 없었습니다.
Release notes를 통해 변경 사항을 살펴보았습니다.

18.10.0 버전에서는 드디어 지원 컴파일러가 변경되었다는 점이 가장 중요해보입니다. Riverbed(OPNET) Modeler는 2021년에 발표된 18.9.0 버전에서조차 MS Visual Studio 2013 이하 버전만을 지원하고, MS Visual Studio 2015는 지원하지 않았습니다("Riverbed(OPNET) Modeler 18.x 버전에서의 컴파일러 선택 유의사항" 및 "Visual Studio Community 2013 설치" 참조). 이때문에 Riverbed(OPNET) Modeler 사용에 많은 불편함이 있었고, 최근에는 Visual Studio Community 2013 버전 사용을 위한 인증이 되지 않는(인터넷 익스플로러 지원 종료 이슈 때문인 것으로 짐작되는) 현상도 발생하여 Riverbed(OPNET) Modeler 사용 환경 구축에 어려움이 많았습니다.
다행히 이번 18.10.0 부터는 이러한 불편함이 드디어 해소되었습니다. 지원되는 Windows 컴파일러는 MS Visual Studio 2015, 2017, 2019, 2022 버전이며, Community 버전도 가능합니다.

모델 업데이트는 2가지입니다.

- WLAN Model Enhancements - Configurable Reserved Buffer Size Capacity for Access Category Transmission Queues
- OSPF Model Enhancements - A new utility for configuring OSPFv3 area information

Wireless LAN 모델 개선 사항은 AC별 전송 큐 크기에 대한 예약 기법이 적용된다는 것이며, "Buffer Size Sharing Scheme" 파라미터와 "Buffer Size Share (%)" 파라미터가 추가되었다고 합니다. 그리고, 기존에 예고되었던 것처럼("Riverbed Modeler 18.8.0 발표" 참조) 구식이 되어버 IR PHY, FHSS PHY 기능이 제거되었습니다.
OSPF 모델 개선 사항은 OSPFv3 영역 정보 설정을 위한 새로운 도구가 Project Editor의 Protocols 메뉴에 추가되었다는 것입니다.

그 외에 버그 수정사항 5건도 있습니다만, 특별히 관심이 가는 내용이 아니라서 생략합니다.

"WiFi 모델에서의 통신 가능 거리(7) - MAC Throughput(3)"에서는 802.11g 24Mbps 환경에서 237Bytes 크기의 MAC 사용자 패킷을 전송할 때, MAC 사용자 계층의 패킷 전달률 관점에서 최대 통신 가능 거리는 어디까지인지를 살펴보았다. 이번에는 동일한 환경(802.11g 24Mbps)에서 1,500Bytes 크기의 MAC 사용자 패킷을 전송할 때, MAC 사용자 계층의 패킷 전달률 관점에서 최대 통신 가능 거리는 어디까지인지를 살펴보기로 하자. 동일한 환경이므로 MCS 레벨(QAM16 1/2)과 프로세싱 게인(MCS gain: -3.01dB, OFDM gain: 2.28dB)은 기존의 분석과 동일하다.
1,500Bytes의 MAC SDU 패킷을 전송할 때 송신 포트에서 내보내는 패킷의 크기는 1,500Bytes(MAC SDU 패킷) + 28Bytes(MAC 오버헤드) + 22.67usec * 24Mbps(PLCP 오버헤드) / 8 = 1,596Bytes(12,768bits)이다. (PLCP 오버헤드 계산에 대해서는 "WLAN PLCP 오버헤드 크기" 및 "WiFi에서의 throughput (5) - 802.11g 최대 throughput" 참조) MAC에서의 최대 전송 횟수는 기본값인 7이 적용된다.

이상의 정보로부터 BER별 MAC 사용자 패킷 전달률(Throughput)과 최대거리(distance)를 계산해보면 다음과 같이 예상할 수 있다.
- BER이 8.1x10^-6 일 때: MAC 사용자 패킷 전달률 100%, 이 때의 SNR은 10.63dB이므로 최대 거리는 약 694M.
- BER이 1.0x10^-4 일 때: MAC 사용자 패킷 전달률 89.89%, 이 때의 SNR은 9.63dB이므로 최대 거리는 약 779M.
- BER이 1.6x10^-4 일 때: MAC 사용자 패킷 전달률 60.93%, 이 때의 SNR은 9.43dB이므로 최대 거리는 약 797M.
- BER이 7.9x10^-4 일 때: MAC 사용자 패킷 전달률 0.03%, 이 때의 SNR은 8.73dB이므로 최대 거리는 약 864M.

이제 시뮬레이션을 통해 이 예측을 확인해 보자. 2대의 WLAN 터미널 스테이션 노드를 배치하고, Physical Characteristics은 "Extended Rate PHY (802.11g)"로, Data Rate (bps)는 "24Mbps"로 설정한다. 트래픽은 1,500Bytes 크기의 패킷을 1초마다 발생시켜 다른 WLAN 터미널 스테이션 노드로 전송하도록 설정하였다.

694M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 송수신량이 동일(전달률 100%)하며, 이는 앞의 예측과 일치한다.

다음으로  779M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 89.89%)과는 미세한 차이가 있는 결과(전달률 약 89.50%)이나, 오차범위 내로 볼 수 있다.

다음으로  797M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 60.93%)과는 미세한 차이가 있는 결과(전달률 약 58.50%)이나, 오차범위 내로 볼 수 있다.

다음으로  864M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 0.03%)과는 미세한 차이가 있는 결과(전달률 약 0.25%)이나, 오차범위 내로 볼 수 있다.

Riverbed(OPNET) Modeler OSPF 모델에서 제공하는 "Convergence Activity"와 "Convergence Duration"의 의미에 대해서는 "OSPF 수렴 시간 (1) - Convergence Duration"에서 살펴보았다. 이번에는 예제를 통해 실제 시뮬레이션에서 어떤 결과값이 측정되는지 살펴보기로 하자.
다음은 "OSPF 라우팅 예제"의 예제망에서 측정된 "Convergence Activity"와 "Convergence Duration" 결과값을 보인 것이다.

Convergence가 1번 기록되었는데, convergence activity는 6초대에 시작되어 51초대에 끝났으며 convergence duration은 약 45초로 기록된 것을 알 수 있다. 네트워크가 가동된 후 convergence가 1번만 기록되었으므로 네트워크 개통에서 기인한 OSPF 라우팅 테이블 갱신 완료에 걸린 시간(Convergence time)은 45초로 볼 수 있다.

다음은 "OSPF DR(1) - 라우터 상태"의 예제망에서 측정된 "Convergence Activity"와 "Convergence Duration" 결과값을 보인 것이다.

Convergence가 2번 기록되었는데, 첫번째 convergence acvitiy는 6초대에 시작되어 23초대에 끝났고 convergence duration은 약 17초로 기록되었다. 두번쨰 convergence acvitity는 46초대에 시작되어 64초대에 끝났으며, convergence duration은 약 18초로 기록되었다. 네트워크 개통 이후 추가적인 토폴로지 변경은 없으므로 네트워크 개통에서 기인한 OSPF 라우팅 테이블 갱신 완료에 걸린 시간(Convergence time)은 약 58초(6초 ~ 64초)로 보아야 한다. 23초 ~ 46초 구간은 OSPF 라우팅 테이블 갱신이 완료된 것은 아니지만, "일정 간격" 동안 convergence activity가 없는 상태이다.

OSPF Convergence time으로 각각 45초, 58초가 소요된 이유를 구체적으로 설명하는 것은 대단히 복잡한 작업이며, 라우터들간에 송수신된 메시지와 인터페이스 상태 변화등을 상세히 추적해야만 한다. (OSPF 라우터들간에 송수신된 메시지 순서와 메시지간 상관 관계에 대해서는 이후의 글에서 분석해 볼 예정이다.)

네트워크 토폴로지 변경 횟수가 동일하지만 예제망마다 convergence 기록 횟수가 다른 것은 네트워크 토폴로지의 차이와 convergence(일정 시간 간격 동안 라우팅 테이블 갱신이 없는 것) 도달 여부를 판단하는 "일정 시간" 기준값 때문이다.