네트워크 시뮬레이션 공방

BS는 요청된 서비스 플로우에 대한 수락제어(Admission control) 기능을 수행한다. 서비스 플로우 생성 요청을 허가할 것인지의 여부에 대한 판단은 스케줄링 타입에 따라서 다른 기준으로 이루어지기는 하나, 대역폭(Bandwidth)만이 고려된다. 기준이 되는 대역폭은 bps단위이며, 여기에 MAC 오버헤드와 MCS 레벨을 반영하여 필요한 자원의 크기(Symbols/Frame)를 구한다. 필요한 자원의 크기가 현재 남아있는 자원의 크기보다 작으면 서비스 플로우 생성 요청은 허가되고, 그렇지 않으면 거절된다. 이 과정을 그림으로 표현해보면 다음과 같다.

각 스케줄링 타입별로 판단 기준이 되는 대역폭은 다음과 같다.
1) UGS: Maximum Sustained Traffic Rate
2) ertPS: UGS와 동일
3) rtPS: Minimum Reserved Traffic Rate. UL 플로우일 경우, Maximum Sustained Traffic Rate를 고려한 폴링 오버헤드 추가.
4) nrtPS: Minimum Reserved Trafffic Rate. UL 플로우일 경우, Minimum Reserved Traffic Rate를 고려한 폴링 오버헤드 추가.
5) BE: 항상 허가됨. 즉, 기준 대역폭이 0 이라고 볼 수 있음.

한 가지 주의하여야 할 사항은, rtPS와 nrtPS에 대한 폴링 오버헤드가 서로 다르다는 것이다. 소스 코드를 살펴보면 이 부분이 좀 헷갈리게 되어 있는데, rtPS는 Maximum Sustained Traffic Rate를 기준으로 폴링 오버 헤드를 계산하고 nrtPS는 Minimum Reserved Traffic Rate를 기준으로 폴링 오버헤드를 계산하는 것이 맞다.

"WiMAX 모델(30) - SS 스케줄러"에서 살펴본 것처럼 OPNET WiMAX 모델은 SS에서 별도의 스케줄링 알고리즘을 사용하지 않고, BS에서 대역폭을 승인해줄 때 판단한 정보를 그대로 사용한다. 즉, 형식적으로는 GPSS(Grants per Subscriber Station) 방식의 BW 할당을 하지만, 실제적으로는 GPC(Grants per Connection) 방식으로 동작하는 것이다.
현재의 WiMAX 표준[1]에 따르면, BW 요청은 각각의 개별적인 connection에 대해서 이루어지지만, BW 할당은 (Basic CID를 사용하여) 단말단위로 이루어지므로 GPSS 방식이다. 단말에서의 스케줄링 동작에 대한 부분은 표준에서 정의하지 않는데, 이는 단말 업체의 구현 영역이기 때문이다.
따라서, OPNET WiMAX 모델의 BW 할당과 SS 스케줄러는 형식적으로 표준을 준수하고 있다. 물론, BS의 판단 정보를 그대로 알아낼 수 있는 방법이 실제로는 없으므로, OPNET WiMAX 모델의 SS 스케줄러와 동일한 특성을 가지는 실제 시스템을 구현하는 것은 불가능할 것으로 생각된다. 하지만, 스케줄링 알고리즘은 표준에서 규정하는 부분이 아니므로, 이러한 스케줄링 알고리즘의 사용은 표준을 준수하는가의 여부와는 상관없는 것이다.
다음 그림은 표준과 OPNET WiMAX 모델을 단말에 대한 BW 할당과 단말에서의 스케줄링 방법 관점에서 비교한 것이다.

[1] IEEE 802.16-2009, "Air Interface for Broadband Wireless Access Systems", 2009

지난 6월12일에 OPNET Modeler 17.1 PL2 버전이 발표되었습니다(이전 버전에 관한 내용은 "OPNET Modeler 17.1 PL1 발표" 참조). 별도의 공지가 없어서 새 버전이 나온 줄도 모르고 있었는데, 2012년 6월12일자로 17.1 PL2가 나왔었네요.
User Forum에는 별도의 공지가 없었고, Release note를 통해 변경 사항을 살펴보았습니다. 모델 마이너 업데이트에 대한 내용이 대부분이며, 다음과 같습니다.

- LTE Model Enhancements
- TCP Model Enhancements
- Node Model Enhancements
- ADT Analysis Enhancements
- Licensing Changes for Simulations with Multiple Runs

 LTE 모델에서는 Jammer 노드 모델을 LTE에서도 사용할 수 있게 되었으며, TDD Profile의 기본 주파수가 "2300 MHz (band 40 - China)"로 변경되었습니다.
 TCP 모델에서는 Receive Window Size에 대한 "Auto-Tuning" 설정(Window Vista 등의 OS에서 지원)이 가능하게 되었으며, Minimum Available Bandwidth 속성이 새롭게 추가되었습니다. 이 새로운 속성은 두 종단 사이에 위치한 병목구간 링크에 대한 대역폭을 설정해주기 위한 것이며, Receive Window Size 속성이 "Auto-Tuning"으로 설정되었을 때 사용됩니다.
 Node Model Enhancements는 Single-Band Jammer 노드 모델에 "Jammer Bandwidth Usage Percentage" 속성과 "Jammer Transmission Band Position" 속성이 추가되었다는 것입니다. 이 두 속성은 Jammer 가 동작 대역폭을 얼마만큼 사용하는 지와, 동작 대역폭의 전체를 사용하지 않을 경우에 Jammer 전송 대역폭의 위치를 설정하기 위한 것이라고 합니다.
Licensing Changes for Simulation with Multiple Runs는 (LTE나 WiMAX 같은) 특정 모델/모듈의 라이센스는 하나만 있어도 여러 개의 시뮬레이션을 동시에 실행할 수 있도록 변경된 것입니다. 이전에는 실행하는 시뮬레이션 갯수만큼 해당 모델/모듈의 라이센스도 필요했었습니다. 사용자 입장에서는 참 편리해졌습니다만, OPNET사에서 이렇게 수정해준 것은 정말 의외입니다. 해당 모델/모듈들의 판매가 꽤나 줄어들 것 같은데 말입니다. 단, 이 변경사항은 TIREM, 3DNV Visualizer, SITL, HLA에는 해당하지 않는다고 합니다.
ADT Analysis Enhancements는 AppTransaction Xpert로 데이터를 보내는 기능에 관한 것인데, 관심사항이 아니라서 생략합니다.

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 정도의 결과를 보여주며, 이는 앞에서 예측한 값과 일치하는 것이다.

SS는 BS에서 승인해준 대역폭 정보를 각 Service flow (또는 connection) 별로 어떻게 나누어서 사용할지를 다시 내부적으로 스케줄링한다. 이 때, OPNET WiMAX 모델은 SS에서 별도의 스케줄링 알고리즘을 사용하지 않고, BS에서 대역폭을 승인해줄 때 판단한 정보를 그대로 사용한다. 실장비에서라면 이러한 방식으로 동작하는 것이 불가능하겠지만, 시뮬레이션에서는 결과에 어떠한 영향도 미치지 않고 BS의 정보를 SS로 보내줄 수 있으므로 이러한 방식의 동작이 가능하다. 다음 그림은 이러한 SS 스케줄러의 동작 구조를 나타낸 것이다.

"WiMAX 모델(26) - UL 구간의 데이터 패킷 전송"에서 살펴본 것처럼, OPNET WiMAX 모델은 Polling, Request, Grant, Contention based CDMA BR 절차를 지원하며 UL 스케줄링 서비스의 종류에 따라 서로 다른 절차들이 사용된다. 이는 표준[1]에서 설명하고 있는 Bandwidth allocation and request mechanisms 절차와 비교했을 때에도 별다른 차이가 없는 것이다.
실제 시스템과 비교하였을 때, OPNET WiMAX 모델의 CDMA 코드 검출 능력은 조금 비현실적인 부분이라고 보여진다. 실제 시스템에서는 서로 다른 코드라고 할지라도 한번에 검출가능한 코드의 갯수는 제한적인 반면, OPNET WiMAX 모델에는 그러한 제한이 없기 때문이다.
[1] IEEE 802.16-2009, "Air Interface for Broadband Wireless Access Systems", 2009

"OPNET 기초다지기" 3.5절의 TCP 예제를 수행해보면 Slow start 구간에서 결과 그래프가 지수적으로 증가하지 않고 다음 그림처럼 선형적으로 증가하는 것을 볼 수 있다.

이렇게 논리적으로 예측된 결과와 OPNET 시뮬레이션 결과값 사이의 차이를 이해하는 것은 네트워크 시뮬레이션에 대한 감각을 익히는데 대단히 중요하다(비단 OPNET에만 한정되는 사항은 아니다). 논리적으로 예측한 결과값을 얻을 수 있도록 시뮬레이션 조건을 설정해주고, 다시 OPNET 시뮬레이션 결과값을 논리적 해석과 연결시키는 이러한 부분이야 말로 OPNET 사용에 있어서 가장 핵심적인 부분이라고 필자는 생각한다.

3.5절의 TCP 예제에서 CWND(Congestion Window)의 크기가 선형적인 증가폭을 보여주는 원인은 3가지인데, 1) 네트워크 환경 조건과, 2) TCP 파라메터 설정, 3) 결과 그래프 표시방법의 차이이다. 즉, 교재의 TCP 예제에서도 CWND 크기는 지수함수적인 방법으로 증가하고 있지만, 이 3가지 조건이 잘 맞지않은 관계로 예쁜 지수 함수로 보이지 못하고, 마치 직선인 것처럼 (찌그러져서) 보인 것이다.
다음 그림은 3.5절의 예제에서 몇 가지 설정사항만을 변경하여 다시 시뮬레이션한 결과이다. (빨간색 점과 녹색선은 이해를 돕기위하여 필자가 그려 넣어준 것이다) 동일한 소스 코드를 통한 시뮬레이션 결과이지만, 적합한 네트워크 환경 조건 및 TCP 파라메터 설정을 통해 CWND가 지수함수적 패턴으로 증가하는 현상을 잘 보여주고 있다.

여기에서 한 가지 주목해야할 사실은, 적절한 시뮬레이션 조건을 설정해준다 할지라도 시뮬레이션 결과 그래프는 논리적인 분석 그래프 모습과는 좀 다를 수 있다는 것이다. 위의 그림에서 녹색선은 (네트워크 서적에서 흔히 보여주는) 이론적인 예측 그래프이며, 빨간색 점은 (마지막 점을 제외하고) 이 녹색 그래프를 그리는데 사용된 CWND 값이다. 즉, 우리가 논리적인 예측을 할 때에는 모든 CWND 값을 사용한 것이 아니라, 일정 주기 간격으로 CWND 값을 샘플링하여 사용한 것이다. 더욱이, 엄밀하게 말해서 그 샘플링 간격이 일정하지도 않다. (위의 그림에서 빨간색 점의 x축(시간) 간격은 일정하지 않다. 뒤로 갈수록 길어진다.) 따라서, 기계적으로 CWND 값을 수집하는 경우(이는 실장비의 값을 측정하는 경우에도 마찬가지이다)에는 논리적인 분석처럼 예쁜 지수함수 그래프를 얻을 수 없다.

WiFi 인터페이스를 사용하는 노드들간의 기본적인 통신 가능거리에 대해서는 "WiFi 모델에서의 통신 가능 거리"에서, 확산이득과 Reception threshold의 영향에 대해서는 "WiFi 모델에서의 통신 가능 거리(2)"에서 살펴본 바 있다. 그런데, WiFi에서의 통신 가능거리에 영향을 미치는 또 하나의 중요한 요소로 propagation delay가 있다.
표준[1]에 의하면 노드들간의 propagation delay는 1usec 이내이어야 하며, 무선신호의 전파 속도를 3x10^8 m/sec라고 가정했을 때 300미터에 해당한다(1x10^-6 sec * 3x10^8 m/sec = 300m). 이러한 특성은 OPNET에도 반영되어 있으며, WLAN의 파이프라인 스테이지에는 송신기와 수신기 사이의 거리가 300미터 이내인지를 검사하는 부분이 구현되어 있다.
한가지 주의하여야 할 점은, 송수신기 사이의 거리가 300미터를 넘는다고 할지라도 패킷을 전달하지 않는 것은 아니라는 것이다. 패킷 전달은 정상적으로 이루어지며, maximum propagation delay를 초과하는 상황이 발생하였다는 것을 DES 로그로 남길 뿐이다. 이전의 실험에서 1Km이상의 거리를 가지는 WiFi 노드들간에 통신이 가능했던 것은 이 때문이다.

실제 장비의 경우 수신된 프레임이 300미터 보다 멀리 떨어진 노드에서 보내져온 것인지(정확히는 propagation delay가 1usec를 초과하는지)를 정확히 알 수 있는 방법이 없으므로, 수신된 패킷을 최대한 처리하는 이러한 동작구조는 실제 시스템의 특성을 잘 반영한 것이라고 생각된다. 물론, 실제 환경에서라면 300미터 이상 멀어지기도 전에 SNR의 저하로 인하여 통신이 되지 않는 경우가 대부분일 것이다. 하지만, 이는 propagation delay와는 별개의 문제이며, 여기에서는 SNR이 충분히 유지되는 상황에서의 얘기이다.
WiFi 노드들간의 거리가 300미터를 초과하는 상황이 발생하는 시나리오의 경우 DES 로그를 살펴보면 다음과 같이 " Distance Limit Exceeded" Warning 메시지를 볼 수 있으며, 어느 노드 사이에 발생한 문제인지를 확인할 수 있다.

[1] IEEE Std 802.11, "Wireless LAN MAC and PHY Specifications", IEEE, 2007.

SS가 BS로 데이터를 전달히기 위해서는 반드시 BS로부터 대역폭 자원을 할당받아야만 한다. 대역폭을 할당받는 절차는 3가지 경우로 구분해볼 수 있는데, 1) UGS 또는 ert-PS connection인 경우, 2) rt-PS 또는 nrt-PS connection인 경우, 3) BE connection인 경우이다.
UGS나 ert-PS connection인 경우의 데이터 전송 절차는 다음 그림과 같다. BW 요청은 SS에서 보내지지 않으며, BS에서 내부적으로 생성된다. 이 BW 요청에 의해서 BW 자원이 할당되면 UL-MAP을 통해 SS에게 알려지고, SS는 할당된 BW를 이용하여 데이터를 BS로 전송한다.

rt-PS나 nrt-PS connection인 경우의 데이터 전송 절차는 다음 그림과 같다. BS는 해당 SS에 대해서 주기적인 polling을 UL-MAP을 통해서 하며, 이 때 전송할 데이터가 있으면 SS는 BW 요청 메시지를 BS로 보낸다. 이 요청에 의해서 BW 자원이 할당되면 UL-MAP을 통해 SS에게 알려지고, SS는 할당된 BW를 이용하여 데이터를 BS로 전송한다.

BE connection인 경우의 데이터 전송 절차는 다음 그림과 같다. Contention 방식의 BW 요청을 위한 자원 정보는 매 프레임마다 UL-MAP을 통해서 SS들에게 알려지며, 이 때 전송할 데이터가 있으면 SS는 BW 요청 메시지를 BS로 보낸다. 이 요청이 성공적으로 BS에게 전달되고 BW 자원이 할당되면, UL-MAP을 통해 SS에게 알려지고, SS는 할당된 BW를 이용하여 데이터를 BS로 전송한다.

데이터 패킷에 대한 송/수신 처리는 모두 wimax_mac 프로세스 모델에서 이루어진다. 상위계층(구체적으로는 IP계층)으로부터 패킷이 도착하면 idle 스테이트로부터 hl_pk 스테이트로 천이가 일어난다. hl_pk 스테이트에서는 다음 그림과 같이 패킷을 분류하여 적합한 CID를 찾아내고, 찾아낸 CID에 해당하는 conduit에 패킷을 저장한다.

Conduit는 데이터 패킷을 저장하는 큐와 QoS 적용을 위한 Shaper, 요청할 BW 크기 정보 (또는 BW 요청을 위한 큐) 등으로 구성되어 있다. SS에서 rtPS, nrtPS, BE와 같이 BW 요청이 필요한 connection의 데이터 저장 큐에 패킷이 들어오면, 요청할 BW 크기 정보도 이에 맞추어 업데이트 된다. 업데이트된 BW 요청정보는 폴링이나 Contention 과정을 통해 BS로 전달되고, 이에 대한 BW 할당이 이루어지면 스케줄러의 제어를 통해 데이터 큐에 쌓여있던 패킷이 전송된다. BS에서는 요청할 BW 크기 정보가 따로 저장되지 않고, 즉시 wimax_bs_control 프로세스로 전달된다.
Shaper는 아직까지 실제로 사용되지는 않는다.