네트워크 시뮬레이션 공방

"서브넷 경계를 넘어서는 WLAN 노드간의 통신(1) - BSS ID"에서 설명한 방법을 이동하는 WLAN 단말에 적용하면 다음 그림처럼 서로 다른 서브넷에 속한 AP들간을 로밍하는 시나리오도 만들 수 있다. Subnet1에 속한 AP 노드와 STA 노드의 BSS ID는 1, Subnet2에 속한 AP 노드의 BSS ID는 2로 설정하였으며, STA 노드의 Roaming Capability를 Enabled로 변경하였다. 트래픽은 "서브넷 경계를 넘어서는 WLAN 노드간의 통신(1) - BSS ID"에서와 동일하게 STA 노드에서 Server 노드를 향해 전달하도록 설정하였다(1,024bytes 패킷을 0.1sec 간격으로 UDP를 통해 전송).

STA 노드는 Subnet1 내의 AP 노드를 통해 Server 노드로 트래픽을 전달하다가 이동하여 Subnet2 내의 AP 노드로 로밍하여 트래픽을 계속 전달한다. 이를 확인하기 위해서 Subnet1에서 Router로 Subnet2에서 Router로, Router에서 Server로 전달되는 트래픽을 살펴보면 다음 그림과 같다.

"서브넷 경계를 넘어서는 WLAN 노드간의 통신(1) - BSS ID"에서 살펴본 것처럼, 서로 다른 서브넷에 배치되어 있는 WLAN 노드들간에도 서브넷 경계를 넘어서 통신이 가능하다. 단, 이 때 Simulation Attributes의 WLAN Transmission Candidacy 항목이 다음 그림처럼 "Objects Across Entire Network"로 설정되어 있어야만 한다.
만약 이 항목이 "Objects in Same Subnet"으로 설정되어 있으면, BSS ID를 수동으로 맞추어 주더라도 서로 다른 서브넷에 배치되어 있는 WLAN 노드들간에는 통신이 이루어지지 않는다. 기본값은 "Object Across Entire Network"이므로, 사용자가 별도로 변경한 경우가 아니라면 특별히 신경쓸 필요는 없다.

Riverbed(OPNET) Modeler WLAN 모델은 같은 서브넷 내에 있는 노드간에만 통신이 가능하다고 안내되어 있다. 하지만, 이는 정확하지 않은 것이며, 실제로는 WLAN 노드들간에 서브넷 경계를 넘어서(Ex: 서브넷 안에 위치한 AP 노드와 서브넷 밖에 위치한 STA 노드간) 통신이 가능하다. 단, 동일한 서브넷 내에 배치되어 있지 않은 WLAN 노드들간에는 BSS ID에 대한 Auto Assign 기능을 이용할 수 없으므로 사용자가 직접 BSS ID를 설정해 주어야만 한다(약간의 편법을 사용하면 이 경우에도 Auto Assign 기능을 적용할 수 있기는 하나 권장할만한 수준은 아니다).

다음은 통신을 원하는 WLAN 노드들이 서브넷 경계를 넘어서 배치되는 2가지 경우에 대한 예이다.

1) AP 노드는 서브넷 내부에, STA 노드는 서브넷 외부에 배치

AP 노드는 Subnet1 서브넷 내부에 배치되어 있으며, STA 노드에서 발생시킨 트래픽의 목적지가 되는 Server
노드와 AP 노드는 Ethernet 링크로 연결되어 있다. STA 노드는 서브넷 외부에 배치되어 있으며 Server 노드를 향해 트래픽(1024bytes 패킷을 0.1sec 간격으로 UDP를 통해 전송)을 발생시킨다. 시뮬레이션 결과를 살펴보면 다음 그림처럼 STA 노드에서 발생된 트래픽이 Subnet1의 AP 노드로 잘 전달되고 있음을 확인할 수 있다.

2) AP 노드와 STA 노드가 각각 서로 다른 서브넷에 위치

AP 노드는 Subnet1 서브넷에 배치되어 있으며, STA 노드에서 발생시킨 트래픽의 목적지가 되는 Server 노드와 AP 노드는 Ethernet 링크로 연결되어 있다. STA 노드는 Subnet2 서브넷에 배치되어 있으며 Server 노드를 향해 트래픽을 발생시킨다. 시뮬레이션 결과를 살펴보면 다음 그림처럼 Subnet2의 STA 노드에서 발생된 트래픽이 Subnet1의 AP 노드로 잘 전달되어 있음을 확인할 수 있다.

"WiFi에서의 throughput (5) - 802.11g 최대 throughput"에서 도출한 35.91Mbps의 throughput은 매우 특수한 조건을 가정한 것이며, 일반적으로는 이런 조건에 맞는 환경에서 사용하지 않는다. 이번에는 조금 더 실제 사용환경과 가까운 조건, 즉 대다수의 어플리케이션들이 Transport 프로토콜로 사용하는 TCP를 적용하였을 때 802.11g(54Mbps)에서의 MAC 계층 최대 데이터 전송율을 살펴보기로 한다. 최대 전송율을 구하기 위해서, 여전히 무선환경이 완벽한 상태(BER = 0)에서, 두 개의 무선랜 단말만을 고려한다. 또한, Fragmentation이나 RTS/CTS 메시지를 사용하지 않으며, Propagation delay를 반영하지 않는다.
FTP 데이터를 전송하는데 필요한 오버헤드를 IP 패킷 레벨에서 계산해보면 TCP DATA 패킷과 TCP ACK 패킷, 그리고 이 TCP 패킷들에 대한 DIFS/SIFS, Backoff, MAC DATA/ACK 프레임 오버헤드의 합이며, TCP 전송시 최대 크기인 1,500Bytes 길이의 IP 패킷을 전송할 때의 오버헤드 비율을 계산하면 약 50.45%이다. 따라서 MAC 계층에서 기대되는 전송율(throughput)은 54Mbps * 49.55% = 26.76Mbps이다(충돌이 없다고 가정했을 경우).
이 시뮬레이션을 위해서 "WiFi에서의 throughput(4) - 802.11a TCP throughput"에서 작성한 시나리오를 조금 수정하여 사용한다. 801.11g WLAN을 사용하기 위해서 STA와 AP 노드의 Wireless LAN-->Wireless LAN Parameters-->Physical Characteristics 항목을 "Extended Rate PHY (802.11g)"로 Wireless LAN-->Wireless LAN Parameters-->Data Rate (bps) 항목을 "54Mbps"로 설정한다.이제 시뮬레이션을 수행하고 AP에서 측정된 WLAN MAC throughput을 살펴보면 다음 그림과 같이 약간의 편차가 있기는 하지만, 평균적으로 약 25.2Mbps 정도의 결과를 보여주며, 이는 앞에서 예측한 값과 거의 일치하는 것이다.

802.11a에서의 결과값(25.67Mbps, "WiFi에서의 throughput (4) - 802.11a TCP throughput" 참조)보다 조금 낮은 이유는 11g에서 동작 절차가 조금 바뀜에 따라 충돌로 판단하는 경우가 증가하였기 때문이다(즉, 재전송이 증가한다). 코드를 살펴보았을 때, 동작 구조에는 이상이 없으므로 이러한 현상을 OPNET의 버그로 단순히 취급하기는 어렵다. 하지만, 논리적으로 분석하였을 때 11a와 11g의 평균 전송율은 동일해야 하므로, 버그성(?)으로 봐야 할 것 같다.

802.11g 무선랜을 사용하는 경우에 있어 실제 데이터 전송율의 최대치는 어느 정도일까? "WiFi에서의 throughput (1) - 802.11b 최대 throughput"과 "WiFi에서의 throughput(3) - 802.11a 최대 throughput"에서 사용했던 것과 동일한 방법을 적용하여 54Mbps의 802.11g를 사용하는 경우(즉, ERP-OFDM을 사용하는 경우)에, MAC 계층에서의 최대 데이터 전송율을 예측하고 시뮬레이션을 통해 확인해보도록 한다.
IP 패킷 하나를 전송하는데 필요한 오버헤드는 DIFS/SIFS, Backoff, DATA/ACK 프레임 오버헤드의 합이며, WLAN에서의 MTU 크기인 2,304Bytes 길이의 IP 패킷을 전송할 때의 오버헤드 비율을 계산하면 약 33.5%이다(11a와 유사하다). 따라서 MAC 계층에서 기대되는 전송율(throughput)은 54Mbps * 66.5% = 35.91Mbps이다. 이 수치는 매우 특수한 조건을 가정한 경우에 한정된 것이며, 일반적으로는 이런 조건에 맞는 환경에서 사용할 일이 거의 없을 것이다.
이제 시뮬레이션을 통해 이 예측을 확인해 보자. "WiFi에서의 throughput (3) - 802.11a 최대 throughput"에서 작성한 시나리오를 조금 수정하여 사용한다. 801.11g WLAN을 사용하기 위해서 STA와 AP 노드의 Wireless LAN-->Wireless LAN Parameters-->Physical Characteristics 항목을 "Extended Rate PHY (802.11g)"로 Wireless LAN-->Wireless LAN Parameters-->Data Rate (bps) 항목을 "54Mbps"로 설정한다. 이제 시뮬레이션을 수행하고 AP에서 측정된 WLAN MAC throughput을 살펴보면 다음 그림과 같이 약간의 편차가 있기는 하지만 평균적으로 35.89Mbps 정도의 결과를 보여주며, 이는 앞에서 예측한 값과 일치하는 것이다.

802.11g에서 한가지 더 고려해야하는 사항은 Beacon의 영향이다. 11g에서는 11a보다 큰 크기의 Beacon 메시지가 1Mbps의 매우 느린 속도로 전송되므로, Beacon 오버헤드 또한 무시하기 어려운 수준이 된다. Beacon interval을 20ms로 설정하고 시뮬레이션을 수행해보면 34.5Mbps의 전송율을 보여준다. 즉 Beacon 오버헤드에 의해서 1.39Mbps 정도의 전송율이 감소하는 것이다.

"WiFi에서의 throughput (3) - 802.11a 최대 throughput"에서 도출한 35.91Mbps의 throughput은 매우 특수한 조건을 가정한 것이며, 일반적으로는 이런 조건에 맞는 환경에서 사용하지 않는다. 이번에는 조금 더 실제 사용환경과 가까운 조건, 즉 대다수의 어플리케이션들이 Transport 프로토콜로 사용하는 TCP를 적용하였을 때 802.11a(54Mbps)에서의 MAC 계층 최대 데이터 전송율을 살펴보기로 한다. 최대 전송율을 구하기 위해서, 여전히 무선환경이 완벽한 상태(BER = 0)에서, 두 개의 무선랜 단말만을 고려한다. 또한, Fragmentation이나 RTS/CTS 메시지를 사용하지 않으며, Propagation delay를 반영하지 않는다.
FTP 데이터를 전송하는데 필요한 오버헤드를 IP 패킷 레벨에서 계산해보면 TCP DATA 패킷과 TCP ACK 패킷, 그리고 이 TCP 패킷들에 대한 DIFS/SIFS, Backoff, MAC DATA/ACK 프레임 오버헤드의 합이며, TCP 전송시 최대 크기인 1,500Bytes 길이의 IP 패킷을 전송할 때의 오버헤드 비율을 계산하면 약 50.45%이다. 따라서 MAC 계층에서 기대되는 전송율(throughput)은 54Mbps * 49.55% = 26.76Mbps이다(충돌이 없다고 가정했을 경우).
이 시뮬레이션을 위해서 "WiFi에서의 throughput(2) - 802.11b TCP throughput"에서 작성한 시나리오를 조금 수정하여 사용한다. FTP 트래픽을 증가시키기 위해서 FTP 설정의 "File Size (bytes)" 속성 항목값을 "constant(100000000)"로 변경한다.

801.11a WLAN을 사용하기 위해서 STA와 AP 노드의 Wireless LAN-->Wireless LAN Parameters-->Physical Characteristics 항목을 "OFDM (802.11a)"로 Wireless LAN-->Wireless LAN Parameters-->Data Rate (bps) 항목을 "54Mbps"로 설정한다.이제 시뮬레이션을 수행하고 AP에서 측정된 WLAN MAC throughput을 살펴보면 다음 그림과 같이 약간의 편차가 있기는 하지만, 평균적으로 약 25.65Mbps 정도의 결과를 보여주며, 이는 앞에서 예측한 값과 거의 일치하는 것이다.

802.11a 무선랜을 사용하는 경우에 있어 실제 데이터 전송율의 최대치는 어느 정도일까? "WiFi에서의 throughput (1) - 802.11b 최대 throughput"에서 사용했던 것과 동일한 방법을 적용하여 802.11a(54Mbps)를 사용하는 경우에, MAC 계층에서의 최대 데이터 전송율을 예측하고 시뮬레이션을 통해 확인해보도록 한다.
IP 패킷 하나를 전송하는데 필요한 오버헤드는 DIFS/SIFS, Backoff, DATA/ACK 프레임 오버헤드의 합이며, WLAN에서의 MTU 크기인 2,304Bytes 길이의 IP 패킷을 전송할 때의 오버헤드 비율을 계산하면 약 33.5%이다. 따라서 MAC 계층에서 기대되는 전송율(throughput)은 54Mbps * 66.5% = 35.91Mbps이다. 이 수치는 매우 특수한 조건을 가정한 경우에 한정된 것이며, 일반적으로는 이런 조건에 맞는 환경에서 사용할 일이 거의 없을 것이다.
이제 시뮬레이션을 통해 이 예측을 확인해 보자. "WiFi에서의 throughput(1) - 802.11b 최대 throughput"에서 작성한 시나리오를 조금 수정하여 사용한다. 트래픽을 증가시키기 위해서 Task Config에서 Source-->Dest Traffic 설정의 Interrequest Time(seconds)를 "constant(0.0004)"로 변경한다. 801.11a WLAN을 사용하기 위해서 STA와 AP 노드의 Wireless LAN-->Wireless LAN Parameters-->Physical Characteristics 항목을 "OFDM (802.11a)"로 Wireless LAN-->Wireless LAN Parameters-->Data Rate (bps) 항목을 "54Mbps"로 설정한다. 이제 시뮬레이션을 수행하고 AP에서 측정된 WLAN MAC throughput을 살펴보면 다음 그림과 같이 약간의 편차가 있기는 하지만 평균적으로 35.89Mbps 정도의 결과를 보여주며, 이는 앞에서 예측한 값과 일치하는 것이다.

시뮬레이션을 수행한 후 Result Browser 창의 wlan_port_rx_0_0.channel[0]->radio receiver->bit error rate 항목을 살펴보면 다음 그림과 같이 BER에 대한 결과가 기록된 것을 확인할 수 있다.

그런데, 이 BER 결과값은 우리가 일반적으로 생각하는 BER과는 조금 다른 의미이므로 값을 해석할 때 주의할 필요가 있다. WLAN 모델에서 BER이 사용되는 단계는 다음과 같이 4단계로 구분해볼 수 있다.
1) Modulation Curve
2) OPC_TDA_RA_BER 속성값
3) OPC_TDA_RA_ACTUAL_BER 속성값
4) wlan_port_rx_0_0.channel[0]->radio receiver->bit error rate 결과값

Modulation curve와 OPC_TDA_RA_BER 속성값은 일반적으로 얘기하는 BER이다. 차이는 2단계에서 3단계로 넘어가는 과정에서 발생한다. 패킷에 발생하는 비트 에러를 계산하는 과정에서 해당 패킷에 발생한 비트 에러의 비율이 ECC threshold를 넘어서면 OPNET WLAN 모델은 그 패킷에는 더 이상의 비트 에러를 할당하지 않고 다음 단계로 넘어간다. (ECC threshold를 넘어서면 어차피 폐기될 것이므로, 시뮬레이션 수행시간을 줄이기 위한 것으로 생각된다.) 즉, OPC_TDA_RA_ACUTAL_BER 속성에 기록되는 값은 ECC threshold를 넘어서는 순간의 BER로서, 우리가 일반적으로 말하는 BER보다 작은 값인 경우가 많다(해당 패킷의 크기에 따라 OPC_TDA_RA_BER 값보다 작거나 클 수도 있다. 하지만, 모든 패킷에 대한 평균값은 OPC_TDA_RA_BER 값보다 작은 경우가 대부분이다). 그러므로, 위의 그림과 같이 wlan_port_rx_0_0. channel[0]->radio receiver->bit error rate 결과 그래프만을 보고 해당 시뮬레이션에 적용된 BER을 판단할 수는 없다.
위 그림의 결과 그래프를 그리는데 적용된 BER 조건(OPC_TDA_RA_BER 속성값)은 0.000081이며, wlan_port_rx_0_0.channel[0]->radio receiver->bit error rate 결과 그래프 값 0.000048보다 훨씬 크다. "WiFi 모델에서의 통신 가능 거리"에서 언급한 BER 역시 OPC_TDA_RA_BER 속성값을 의미하는 것이다.

"WiFi에서의 throughput(1) - 802.11b 최대 throughput"에서 도출한 7.2Mbps의 throughput은 매우 특수한 조건을 가정한 것이며, 일반적으로는 이런 조건에 맞는 환경에서 사용하지 않는다. 이번에는 조금 더 실제 사용환경과 가까운 조건, 즉 대다수의 어플리케이션들이 Transport 프로토콜로 사용하는 TCP를 적용하였을 때 802.11b(11Mbps)에서의 MAC 계층 최대 데이터 전송율을 살펴보기로 한다. 최대 전송율을 구하기 위해서, 여전히 무선환경이 완벽한 상태(BER = 0)에서, 두 개의 무선랜 단말만을 고려한다. 또한, Fragmentation이나 RTS/CTS 메시지를 사용하지 않으며, Propagation delay를 반영하지 않는다.

FTP 데이터를 전송하는데 필요한 오버헤드를 IP 패킷 레벨에서 계산해보면 TCP DATA 패킷과 TCP ACK 패킷, 그리고 이 TCP 패킷들에 대한 DIFS/SIFS, Backoff, MAC DATA/ACK 프레임 오버헤드의 합이며, TCP 전송시 최대 크기인 1,500Bytes 길이의 IP 패킷을 전송할 때의 오버헤드 비율을 계산하면 약 52.2%이다. 따라서 MAC 계층에서 기대되는 전송율(throughput)은 11Mbps * 47.8% = 5.26Mbps이다.
이 시뮬레이션을 위해서 "WiFi에서의 throughput(1) - 802.11b 최대 throughput"에서 작성한 시나리오를 조금 수정하여 사용한다. FTP 트래픽을 걸어주기 위해서 다음과 같은 FTP 설정을 가지는 Application을 정의하고, 이 Application을 사용하는 Profile을 단말(STA)에 적용해준다. (Command Mix (Get/Totoal): 0%, Inter-Request Time (seconds): constant(600), File Size (bytes): constant(50000000), Symbol Server Name: FTP Server)

FTP Application은 Transport Protocol로 TCP를 사용하므로 변경할 필요가 없다(사실 UDP로 변경할 수도 없다). 이제 시뮬레이션을 수행하고 AP에서 측정된 WLAN MAC throughput을 살펴보면 다음 그림과 같이 약간의 편차가 있기는 하지만, 평균적으로 약 5.1Mbps 정도의 결과를 보여주며, 이는 앞에서 예측한 값과 거의 일치하는 것이다.

WiFi 무선랜을사용하는 경우에 있어 실제 데이터 전송율의 최대치는 어느 정도일까? "OPNET 기초다지기"에서 언급하였듯이, 우리가 흔히 언급하는 11Mbps(802.11b)나 54Mbps(802.11g)의 속도는 물리계층에서의 최고 전송속도이며 MAC 계층에서의 데이터 전달속도가 아니다. 따라서, MAC 계층에서의 실제 데이터 전송율을 측정해보면 11Mbps나 54Mbps보다 훨씬 낮은 속도가 기록된다. (물론, Application 계층에서 측정한 데이터 전송율은 이보다도 더 낮다. 하지만, 대개의 경우 MAC-PHY 구간의 차이보다는 작은 차이를 보이며, 분석하기도 쉽다.) 여기에서는 802.11b(11Mbps)를 사용하는 경우에, MAC 계층에서의 최대 데이터 전송율을 예측하고 시뮬레이션을 통해 확인해보도록 한다.
거의 대부분의 무선랜은 경쟁기반의 DCF 방식으로 사용된다. 이 때, MAC 데이터 전송율이 가장 높은 경우는 1) 전송 오류가 전혀 없는 상태(BER =0)에서, 2) Transport 프로토콜로 UDP를 사용하는 단방향 트래픽을 3) 하나의 무선랜 단말로부터 다른 무선랜 단말로 전달할 때이다. 또한, 4) Fragmentation이나 RTS/CTS 메시지를 사용하지 않아야 하며, 5) IP 패킷이 항상 WLAN에서의 MTU 크기를 가져야 한다. 왜냐하면, 이 조건에서는 전송 매체에 대한 경쟁이 실제적으로는 발생하지 않으며(따라서, 충돌도 전혀 발생하지 않는다), 제어 메시지에 의한 오버헤드가 최소화되기 때문이다.
IP 패킷 하나를 전송하는데 필요한 오버헤드는 DIFS/SIFS, Backoff, DATA/ACK 프레임 오버헤드의 합이며, WLAN에서의 MTU 크기인 2,304Bytes 길이의 IP 패킷을 전송할 때의 오버헤드 비율을 계산하면 약 34.6%이다. 따라서 MAC 계층에서 기대되는 전송율(throughput)은 11Mbps * 65.4% = 7.2Mbps이다. 이 수치는 매우 특수한 조건을 가정한 경우에 한정된 것이며, 일반적으로는 이런 조건에 맞는 환경에서 사용할 일이 거의 없을 것이다.
이제 시뮬레이션을 통해 이 예측을 확인해 보자. "OPNET 기초다지기"에서 사용한 "Disabled_RTS_Fragmentation" 시나리오를 조금 수정하여 사용한다. Task Config에서 Source-->Dest Traffic 설정의 Interrequest TIme(seconds)를 "constant(0.001)"로, Request Packet Size (bytes)를 "constatnt(2276)"으로 변경한다. 2,276Bytes로 설정하는 이유는 IP(20Bytes) + UDP(8Bytes) 오버헤드를 더해서 2,304Bytes를 맞추기 위해서이다. Application Config에서 이 Custom Application의 Transport Protocol을 UDP로 변경한다. 16.1 이상의 버전을 사용한다면, STA와 AP 노드의 Wireless LAN-->Wireless LAN Parameters-->Physical Characteristics 항목은 "Direct Sequence"로, Wireless LAN-->Wireless LAN Parameters-->Data Rate (bps)항목은 "11Mbps"로 설정되어 있는지 확인한다.이제 시뮬레이션을 수행하고 AP에서 측정된 WLAN MAC throughput을 살펴보면 다음 그림과 같이 약간의 편차가 있기는 하지만 평균적으로 7.2Mbps 정도의 결과를 보여주며, 이는 앞에서 예측한 값과 일치하는 것이다.