네트워크 시뮬레이션 공방

"WiFi 모델에서의 통신 가능 거리(5) - MAC Throughput(1)"에서는 802.11b 11Mbps 환경에서 237Bytes 크기의 MAC 사용자 패킷을 전송할 때, MAC 사용자 계층의 패킷 전달률 관점에서 최대 통신 가능 거리는 어디까지인지를 살펴보았다. 이번에는 동일한 크기(237Bytes)의 MAC 사용자 패킷을 802.11g 24Mbps 환경에서 전송할 때, MAC 사용자 계층의 패킷 전달률 관점에서 최대 통신 가능 거리는 어디까지인지를 살펴보기로 하자.
Riverbed(OPNET) WiFi 모델에서 802.11g 24Mbps로 데이터 전송시 사용되는 MCS 레벨은 QAM16 1/2이며("WiFi MCS 레벨 (17.5 PL6 버전)" 참조), Processing Gain은 MCS 레벨에 의한 -3.01dB와 OFDM에 의한 2.28dB이다("WiFi MCS 레벨 프로세싱 게인 (17.5 PL6 버전)" 참조). Riverbed(OPNET)에서 사용하는 QAM16 1/2 MCS의 BER 커브는 다음 그림과 같다.

237Bytes의 MAC SDU 패킷을 전송할 때 송신 포트에서 내보내는 패킷의 크기는 237Bytes(MAC SDU 패킷) + 28Bytes(MAC 오버헤드) + 23.67usec * 24Mbps(PLCP 오버헤드) / 8 = 336Bytes(2,688bits)이다. (PLCP 오버헤드 계산에 대해서는 "WLAN PLCP 오버헤드 크기" 및 "WiFi에서의 throughput (5) - 802.11g 최대 throughput" 참조) MAC에서의 최대 전송 횟수는 기본값인 7이 적용된다.
이상의 정보로부터 BER별 MAC 사용자 패킷 전달률(Throughput)과 최대거리(distance)를 계산해보면 다음과 같이 예상할 수 있다.

- BER이 1.2x10^-4 일 때: MAC 사용자 패킷 전달률 99.99%, 이 때의 SNR은 9.53dB이므로 최대 거리는 약 788M.
- BER이 4.1x10^-4 일 때: MAC 사용자 패킷 전달률 93.92%, 이 때의 SNR은 9.03dB이므로 최대 거리는 약 834M.
- BER이 7.9x10^-4 일 때: MAC 사용자 패킷 전달률 59.26%, 이 때의 SNR은 8.73dB이므로 최대 거리는 약 864M.
- BER이 3.9x10^-3 일 때: MAC 사용자 패킷 전달률 0.02%, 이 때의 SNR은 7.93dB이므로 최대 거리는 약 947M.

이제 시뮬레이션을 통해 이 예측을 확인해 보자. 2대의 WLAN 터미널 스테이션 노드를 배치하고, Physical Characteristics은 "Extended Rate PHY (802.11g)"로, Data Rate (bps)는 "24Mbps"로 설정한다. 트래픽은 237Bytes 크기의 패킷을 1초마다 발생시켜 다른 WLAN 터미널 스테이션 노드로 전송하도록 설정하였다. 788M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 99.99%)과는 미세한 차이가 있는 결과(전달률 100%)이나, 오차범위 내로 볼 수 있다.

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

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

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

RREQ_RATELIMIT는 해당 노드에서의 초당 RREQ 메시지 생성 횟수를 제한하기 위하여 사용되며, Riverbed(OPNET) Modeler AODV 모델도 다음 그림처럼 RREQ_RATELIMIT 값을 지정하기 위한 속성 항목을 제공한다.

하지만, Riverbed(OPNET) Modeler AODV 모델에서 이 속성값은 실제로 시뮬레이션시에 사용되지 않으며, 결과에 아무런 영향을 미치지 않는다. 기본값은 10.

OSPF Model에서 실제로 Hello 메시지가 전송되는 간격은 Hello Inteval 값과 정확히 일치하지 않는다("Hello Interval" 참조). 다음은 이를 확인하기 위하여 "Hello Interval" 예제에서 실제로 Hello 메시지가 송신된 간격을 표로 정리한 것이다.

간격이 계속 변화하며, 그 값이 10초(Hello Interval 속성 값)보다는 약간 큰 것을 알 수 있다. 이렇게 Hello 메시지 간격이 지정된 Hello Interval 값보다 큰 이유는 Riverbed(OPNET) Modeler OSPF Model에는 Hello Jitter 시간이 추가로 반영되어 있기 때문이다.
Hello Jitter 값을 17.5 PL6 버전("OPNET Modeler 17.5 PL6 발표" 참조)까지는 사용자가 변경할 수 없으며, 18.0 버전("Riverbed Modeler 18.0 발표" 참조)부터는 GUI를 통해 변경할 수 있다. 다음 그림은 Riverbed(OPNET) Modeler 18.7.0 버전("Riverbed Modeler 18.7.0 발표" 참조)에서 제공하는 Hello Jitter 설정창을 보인 것이다. 입력값은 Hello Interval에 대한 비율을 의미한다.

고정 할당 방식에서도 노드별로 슬롯 수를 다르게 할당할 수 있다. 즉, 전송량이 많은 노드에는 슬롯을 많이 할당해주고, 전송량이 작은 노드에는 적게 할당해줄 수 있다. "TDMA 예제(1) - 균등 고정 할당"의 예제에서 STA_3 노드에는 필요한 양보다 작은 수의 슬롯이 할당되었기 때문에, STA_3 노드에서 STA_4 노드로 향하는 트래픽이 제대로 전달되지 못했다. STA_3 노드에 더 많은 슬롯을 할당해주어 이 문제를 해결할 수 있음을 확인해보기로 하자. 다음 그림은 이를 확인하기 위한 TDMA 예제망 구조를 보인 것이며, "TDMA 예제(1) - 균등 고정 할당"의 예제망 구조와 동일하다.

TDMA 프로파일로는 Default를 사용하였으며, 이 때 사용할 수 있는 44개의 데이터 슬롯을 STA_1 노드에 11개, STA_2 노드에 8개, STA_3 노드에 14개, STA_4 노드에 11로 나누어 할당하였다. Default TDMA 프로파일일 경우, 프레임("TDMA 프레임 구조" 참조) 길이는 100ms이고 슬롯당 데이터 전송량은 200Bytes이므로 14개의 슬롯을 할당받은 STA_3 노드의 최대 전송량은 224Kbps(= 200 Bytes * 8 bits/byte * 14 slots/frame * 1 / 0.1 frames/sec)이다. STA_3 노드에서 STA_4 노드로 향하는 트래픽의 양은 200Kbps이므로, 이번에는 STA_4 노드로 모두 전달될 것이다.
시뮬레이션을 수행한 후, 각 노드에서 할당받은 프레임당 슬롯수를 살펴보면 다음 그림과 같다. 설정해준 것처럼 STA_1 노드와 STA_4 노드가 11개, STA_2 노드가 8개, STA_3 노드가 14개의 슬롯을 매 프레임 할당받은 것을 알 수 있다.

STA_1 노드에서 STA_2 노드로 향한 트래픽의 송수신량을 살펴보면 다음 그림과 같다. STA_1 노드에서 발생한 트래픽이 STA_2 노드로 모두 전달되었음을 보여준다.

STA_3 노드에서 STA_4 노드로 향한 트래픽의 송수신량을 살펴보면 다음 그림과 같다. STA_3 노드에서 발생한 트래픽(200Kbps)도 STA_4 노드로 모두 전달되었음을 보여준다.

쿼드런트의 계층개념은 "GRP 쿼드런트 레벨"에서 살펴보았다. 여기에서는 예제를 통해 이를 확인해보기로 하자. 예제를 위한 시험망은 "GRP 쿼드런트 예제"의 예제망을 확장하여 사용하였다.

"GRP 쿼드런트 예제"에서 언급하였듯이, 쿼드런트는 좌표계를 기준으로 결정되므로, 시나리오상의 노드 배치를 보고 쿼드런트의 경계를 직접 파악하기는 매우 어렵다. STA_1, STA_8, STA_12, STA_16 노드에 구성된 목적지 테이블 정보로부터 각 노드에서 사용한 쿼드런트를 파악해보면 다음 그림과 같다.

쿼드런트가 "GRP 쿼드런트 레벨"에서 설명한 것처럼 계층적으로 적용되고 있음을 확인할 수 있다. 즉, 대상 노드들의 위치에 따라 하위 레벨 쿼드런트와 상위 레벨 쿼드런트가 사용되고 있으며, 상위 레벨 쿼드런트는 하위 레벨 쿼드런트 4개에 해당하는 면적을 가지고 있다.

OSPF Model에서 Hello 메시지("OSPF 메시지(2) - Hello 패킷 정보 확인" 참조)가 전송되는 간격은 기본적으로 "Hello Interval (sec)" 속성에 의해 지정된다. "Hello Interval (sec)"의 기본값은 10(초)이다.

실제로 Hello 메시지가 이 시간 간격마다 전송되는 것을 예제를 통해 확인해보자. 다음 그림은 "OSPF DR(5) - 메시지 Encapsulation"에서 사용한 시험망의 R1 노드에서 전송하는 Hello 메시지 간격을 살펴본 것이다.

예상했던 것처럼 Hello 메시지가 약 10초마다 송신되고 있는 것을 볼 수 있다. (하지만, 그 간격이 정확히 10초는 아닌데, 그 이유에 대해서는 이후의 글에서 다시 살펴보겠다.)

Riverbed Modeler 18.9.0 버전이 지난 2월15일자로 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.8.0 발표" 참조). 이번에도 공지가 없어서 배포된 줄도 몰랐네요.
Release notes를 통해 변경 사항을 살펴보았습니다. 모델 업데이트는 3가지입니다.

- VLAN Model Enhancement - IEEE 802.1ah Support
- WLAN Model Enhancement - IEEE 802.11s Support
- TCP Model Enahcement - MPTCP IPv6 Support

VLAN 모델 개선 사항은 Provider Backbone Bridged Networks(IEEE 802.1ah)에 대한 지원입니다. 18.8.0 버전에서 VLAN 모델에 대한 업데이트가 시작되면서 향후 추가 구현이 예고("Riverbed Modeler 18.8.0 발표" 참조)되었던 부분들이 있었는데, Provider Backbone Bridged Networks(PBBNs)은 후속 버전에서 바로 반영되었네요.
WLAN 모델 개선 사항은 Mesh networking(IEEE 802.11s)에 대한 지원입니다. 요즘 무선랜 Mesh 기능이 많이 사용되는 추세인데, Riverbed Modeler에서도 이제 지원되네요. 11a, 11b, 11e, 11g, 11p, 11n, 11ac 기술에 적용되었다고 합니다.
TCP 모델에 대한 개선 사항은 MPTCP의 IPv6 지원입니다. MPTCP 자체는 18.7.1 버전("Riverbed Modeler 18.7.1 발표" 참조)에서 구현된 기능이고, 이제는 IPv6에서도 사용할 수 있게 되었다는 것입니다.

그 외에 버그 수정사항 4건중 1건으로 ICMP 모델에서 생성된 ping 패킷이 SITL 사용시 실제 패킷으로 제대로 변환되지 않는 문제가 수정되었다고 합니다. 나머지는 버그 수정사항 3건은 특별히 관심이 가는 내용이 아니라서 생략합니다.

어플리케이션 타이밍("어플리케이션 사용 패턴(1) - 파라미터 설정" 참조)을 조절하여 하나의 어플리케이션이 프로파일내에서 일정 시간 간격으로 반복 실행되도록 만들수 있음은 "어플리케이션 사용 패턴(3) - 어플리케이션 반복 예제"에서 살펴보았다.
어플리케이션 반복 실행을 설정할 때 주의해야할 또 하나의 사항은 Repetition Pattern이다. Repetition Pattern 속성 항목에는 Serial 또는 Concurrent를 설정해줄 수 있다("어플리케이션 사용 패턴(1) - 파라미터 설정" 참조).

"어플리케이션 사용 패턴(3) - 어플리케이션 반복 예제"에서 보인 결과들은 Repetition Pattern을 Serial로 설정했을 때의 결과이다.

다음은 어플리케이션 타이밍의 Duration은 200초, Inter-repetition Time은 300초이고 Repetition Pattern은 Serial일 때, Client로 노드로 전송되는 트래픽을 다시 보인 것이다.

반복되는 어플리케이션 실행(세션)이 이전 실행이 종료된후 300초의 Inter-repetition Time을 가지고 순차적으로 실행되는 것을 알 수 있다.
다음은 타이밍의 Duration은 200초, Inter-repetition Time은 300초이고 Repetition Pattern은 Concurrent일 때, Client로 노드로 전송되는 트래픽을 다시 보인 것이다.

반복되는 세션이 이전 세션의 실행 시작과 동시에 300초의 Inter-repetition Time을 가지고 실행되는 것을 알 수 있다.

"WiFi 모델에서의 통신 가능 거리(5) - MAC Throughput(1)"에서는 802.11b 11Mbps 환경에서 237Bytes 크기의 MAC 사용자 패킷을 전송할 때, MAC 사용자 계층의 패킷 전달률 관점에서 최대 통신 가능 거리는 어디까지인지를 살펴보았다. 이번에는 동일한 환경(802.11b 11Mbps)에서 1,500Bytes 크기의 MAC 사용자 패킷을 전송할 때, MAC 사용자 계층의 패킷 전달률 관점에서 최대 통신 가능 거리는 어디까지인지를 살펴보기로 하자.
동일한 환경이므로 변조방식(CCK11)과 프로세싱 게인(0dB)은 기존의 분석과 동일하다. 1,500Bytes의 MAC SDU 패킷을 전송할 때 송신 포트에서 내보내는 패킷의 크기는 1,500Bytes(MAC SDU 패킷) + 28Bytes(MAC 오버헤드) + 192usec * 11Mbps(PLCP 오버헤드) / 8 = 1,792Bytes(14,336bits)이다. (PLCP 오버헤드 계산에 대해서는 "WLAN PLCP 오버헤드 크기" 참조) MAC에서의 최대 전송 횟수는 기본값인 7이 적용된다.

이상의 정보로부터 BER별 MAC 사용자 패킷 전달률(Throughput)과 최대거리(distance)를 계산해보면 다음과 같이 예상할 수 있다.
- BER이 2.2x10^-5 일 때: MAC 사용자 패킷 전달률 99.99%, 이 때의 SNR은 7.75dB이므로 최대 거리는 약 966M.
- BER이 8.1x10^-5 일 때: MAC 사용자 패킷 전달률 92.78%, 이 때의 SNR은 7.25dB이므로 최대 거리는 약 1,024M.
- BER이 1.4x10^-4 일 때: MAC 사용자 패킷 전달률 63.58%, 이 때의 SNR은 7.0dB이므로 최대 거리는 약 1,053M.
- BER이 7.8x10^-4 일 때: MAC 사용자 패킷 전달률 0.01%, 이 때의 SNR은 6.25dB이므로 최대 거리는 약 1,149M.

이제 시뮬레이션을 통해 이 예측을 확인해 보자. 2대의 WLAN 터미널 스테이션 노드를 배치하고, Physical Characteristics은 "Direct Sequence"로, Data Rate (bps)는 "11Mbps"로 설정한다. 트래픽은 1,500Bytes 크기의 패킷을 1초마다 발생시켜 다른 WLAN 터미널 스테이션 노드로 전송하도록 설정하였다.
966M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 99.99%)과는 미세한 차이가 있는 결과(전달률 100%)이나, 오차범위 내로 볼 수 있다.

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

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

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

종단 노드간에 다중경로(Multi-Path)가 존재하는 경우, 라우팅에서 유용하게 활용될 수 있음을 "다중경로 라우팅(1) - ECMP"와 "다중경로 라우팅(7) - UCMP"에서 살펴보았다. 그러면, 특정 링크 구간에 복수개의 링크가 존재하는 경우, 즉 다중링크(Multi-Link)도 라우팅에서 유용하게 활용될 수 있는지 확인해보기로 하자. 다음 그림은 "OSPF 라우팅 예제"에서 사용한 시나리오를 수정하여 작성한 시험망의 구조를 나타낸 것이다. 다중링크를 구성하기 위하여, R1 노드와 R2 노드간을 기존 링크와 동일한 대역폭의 링크로 추가 연결하였다.

시뮬레이션을 수행한 후 R1 노드에서 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다. "OSPF 라우팅 예제"에서의 결과와는 달리 R2 - R4 네트워크로 향하는 경로가 2개이며, 두 경로의 차이점은 R2 노드와 연결된 포트가 다른 것임(즉, 다중링크가 사용되고 있음)을 알 수 있다.

다중링크의 각 링크가 OSPF 라우팅 테이블에서 구분되어 인식되므로, 다중링크는 기존의 일반적인 다중경로와 동일하게 트래픽 부하를 분산시키는데 사용될 수 있다("다중경로 라우팅(1) - ECMP" 참조).
만약, 라우팅 프로토콜로 RIP가 사용되면, 다중링크의 각 링크가 라우팅 테이블에서 구분되어 인식될 수 없으므로 다중링크는 트래픽 부하를 분산시키는데 사용될 수 없다. 또한, OSPF가 사용되는 경우에도 다중링크의 대역폭이 서로 다르면 다중링크를 제대로 사용할 수 없다.