네트워크 시뮬레이션 공방

OPNET WiMAX 모델에서는 접수된 BW 요청들중에서 동일한 단말에 대한 (즉, 같은 Basic CID를 사용하는) 건들을 병합(amalgamate)하여 하나의 승인으로 처리한다. 그리고, 이러한 병합(amalgamation) 과정에서 동일한 CID를 사용하는 BW 요청들은 하나의 요청인 것처럼 완전히 융합(merge)되어 처리된다. 이는 MAP 오버헤드를 최소화하여 DL 전송율(throughput)을 향상시키 위한 것이다. 이 때 DL과 UL은 서로 다른 병합 절차를 사용한다. DL에서는 BW 요청들을 먼저 병합(amalgamate)한 후에 BW 승인 처리를 한다. DL에서는 병합된 burst의 배치 순서에 따라서도 MAP 오버헤드가 달라질 수 있기 때문이다. BW 승인 처리에 앞서 BW 요청들을 병합하기 위해서는 스테이징 버퍼가 사용된다. DL에서의 병합 개념은 다음 그림과 같다.

UL에서는 병합된 burst의 배치 순서가 변하더라도 MAP 오버헤드는 동일하므로, BW 승인처리를 먼저하고 병합처리를 나중에 해준다. 따라서, DL과는 달리 스테이징 버퍼가 사용되지 않는다. (엄밀히 얘기하자면, 스테이징 버퍼의 일부를 사용하기는 하지만, 병합처리를 위해서가 아니라 단순히 BW 요청정보를 저장하기 위해서만 사용한다) UL에서는 동일한 CID를 사용하는 BW 요청들에 대한 융합(merge) 처리가 HARQ 데이터에 대해서만 일어나며, HARQ 재전송이나 일단 데이터/제어 메시지 전송에는 적용되지 않는다. UL에서의 병합 개념은 다음 그림과 같다.

BS 스케줄러의 동작에 대한 부분은 표준에서 정의하지 않으며, 기지국 업체의 구현 영역이다. OPNET WiMAX 모델의 스케줄러는 OPNET사에서 구현한 것이며, 특정 업체 장비의 특성을 반영한 것이 아니다. (사실, 스케줄링 알고리즘은 기지국 업체의 핵심 경쟁력에 속하는 사항이라, 공개되기는 어려울 것이라고 생각한다.) OPNET WiMAX 모델에서 BS 스케줄러는 동일한 스케줄링 타입을 가지는 서비스 플로우들간에 적용되는 부분과 서로 다른 스케줄링 타입들간에 적용되는 부분의 2단계로 구성되어 있으며, 이를 구조적으로 표현해보면 다음 그림과 같다.

UGS와 ertPS는 동일하게 취급되며, 서비스 플로우별로 구분하지 않고 하나의 큐를 사용한다. 큐가 하나밖에 없고, 큐의 선두에 저장된 BW 요청부터 차례대로 서비스되므로 FIFO라고 볼 수 있다. UL 구간에서는 rtPS/nrtPS를 위한 polling도 이 큐를 통하여 처리된다. rtPS와 nrtPS는 동일하게 취급되며, 서비스 플로우별로 별도의 큐를 사용한다. 서비스 플로우들간의 스케줄링을 위해서는 MDRR(Modified Deficit Round Robin)이 사용된다. 이 MDRR 방식은 시스코 라우터에 사용되는 것과는 조금 다른데, 이후에 별도로 설명하도록 하겠다. BE는 서비스 플로우별로 별도의 큐를 사용하며, 서비스 플로우들간의 스케줄링은 RR 방식으로 처리된다. 서로 다른 스케줄링 타입들간(UGS/ertPS와 rtPS/nrtPS 그리고 BE간)의 스케줄링에는 PQ(Priority Queue)가 사용된다. 즉, UGS/ertPS가 제일 먼저 처리되고 UGS/ertPS 큐가 비었을 경우에만 rtPS/nrtPS로 넘어간다. 이어서, rtPS/nrtPS가 다 처리되고 큐가 비었을 경우에만 BE로 넘어간다. 이러한 처리 중간에 자원이 고갈되면 하위 순위에 대해서는 더이상 스케줄링되지 않는다.

"OPNET 기초다지기" 3.2절의 간섭이 있는 무선랜 예제를 수행할 때, 16.1 버전을 사용할 경우 다음 그림과 같이 에러가 발생하는 문제가 있다.

이 에러는 16.1 버전에서만 발생하며, 16.0 버전이나 17.1 버전에서는 발생하지 않는다. 이는 WLAN 모델 업데이트 과정(16.1 버전에서 802.11n 기능이 추가되었다.)에서의 버그라고 보여지며, 다음에 설명하는 방법으로 해결할 수 있다. wlan_mac 프로세스 모델을 열고 FB에서 wlan_physical_layer_data_arrival() 함수를 찾는다(16.1.A PL1 버전에서는
3758 라인에서 시작한다). 함수 시작 부준에 있는 수신된 프레임에서 PHY 정보를 읽어내는 코드(원래는 3804 ~ 3806 라인에 위치)를 찾아서, Jammer가 발생시킨 패킷이 아닌 경우에만 동작하도록 바로 위의 if 조건문 다음의 실행문 위치로 이동시킨다. 다시 wlan_mac 프로세스 모델을 컴파일하고, 시뮬레이션을 실행시키면 에러가 발생하지 않을 것이다.

조만간 출판 예정인 개정판에는 이 오류가 수정되어 있다.

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

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