네트워크 시뮬레이션 공방

ITU-T 표준문서들중 상당 부분은 다음의 사이트에서 무료로 다운로드 받을 수 있다. (현재 "in-force" 상태인 문서들이다.)
http://www.itu.int/rec/T-REC/e

마찬가지로, ITU-R 표준문서들은 다음의 사이트에서 무료로 다운로드 받을 수 있다.
http://www.itu.int/pub/R-REC/en

"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의 평균 전송율은 동일해야 하므로, 버그성(?)으로 봐야 할 것 같다.

데이터 전송시에 대역폭 요청 메시지를 덧붙여서 전송하는 것을 Piggyback BR이라고 하며, OPNET WiMAX 모델에서도 이를 지원한다. Piggybacked BR 정보가 전달되는 구조는 다음 그림과 같다.

MAC PDU의 "MAC Header" 필드에 실리는 WimaxT_Mac_Header_Fields 구조체에는 piggy_back_bw_req 변수가 포함되어 있으며, 여기에 piggyback 방식으로 요청할 BW 크기를 저장하여 전달한다. 또한 type 변수에 piggyback BR을 위한 서브헤더가 포함되었음을 반영하고, MAC PDU 전체 크기에도 서브헤더 크기를 추가한다. 단, 실제로 별도의 서브헤더가 생성되어 전달되지는 않는다.

다음 그림은 표준[1]의 ARQ 재전송 동작 예를 나타낸 것이다([1]의 Figure 48 참조). SDU(상위계층 패킷)은 분할(fragmentation)되거나 packing되어 MAC PDU에 담겨질 수 있으며, 재전송시 재정열(rearrangement)되어 전송될 수 있다.

OPNET WiMAX 모델 ARQ에서도 MAC PDU 구성시 SDU 분할과 packing을 지원한다. 하지만, 재정열은 지원하지 않는다. 즉, 재전송은 항상 처음 전송했던 MAC PDU와 동일한 단위로 진행된다. 재정열을 지원하지 않는 주된 이유는 "WiMAX 모델(69) - ARQ 기능"에서 설명하였듯이 송신측 ARQ 버퍼에 MAC PDU 단위로 패킷이 저장되어있기때문인 것으로 생각된다. (물론, MAC PDU 정보를 가공하면 ARQ 블럭별로 재정열하는 것도 가능하지만, 현재에는 구현되어 있지 않다.) 재정열은 송신측에서 결정하는 정책 사항이므로, 재정열을 지원하지 않는다고해서 표준을 위반하는 것은 아니다.

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

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 정도의 전송율이 감소하는 것이다.

"VoIP 호 설정 절차(1) - No Signaling"에서 살펴본 것처럼, OPNET은 VoIP 호 설정(Call Setup)을 위한 시그날링 프로토콜로 SIP도 지원한다. 다음 그림은 "OPNET 중급입문"의 예제를 수정하여 SIP를 적용한 것으로, VoIP 교환기 역활을 수행하는 SIP 서버가 추가되었다.

VoIP 속성 편집창에서 Signaling 프로토콜을  살펴보면 다음 그림과 같이 SIP로 적용되어 있어야 한다.

시뮬레이션 수행후 결과를 살펴보면, SIP_Server 노드에서 Active Calls에 대한 결과값으 볼 수 있으며, VoIP Call의 설정과 종료 시점에 SIP_Server 노드에 송수신 트래픽(SIP 시그날링 메시지)이 발생함을 확인할 수 있다.

OPNET WiMAX 모델에서는 서비스 플로우 단위별로 ARQ 기능 적용을 조절할 수 있다. ARQ는 슬라이딩 윈도우 방식으로 동작하며, Ack 타입은 Cumulative, Selective Bitmap, Selective Block Sequence를 지원한다. 다음 그림은 WiMAX 모델에서의 ARQ 동작 구조를 나타낸 것이다.

송신측의 ARQ 버퍼에는 송신한 MAC PDU의 사본이 윈도우 크기만큼 저장되어 있다가, Feedback 메시지로부터 성공적인 전달이 확인되면 삭제된다. Feedback 메시지로부터 재전송이 요구되면, 저장되어 있던 MAC PDU를 복사하여 전송한다.
수신측의 ARQ 버퍼에는 수신된 MAC SDU가 저장되어 있다가, 누락된 sequence number 없이 수신된 것이 확인되면 상위 계층으로 전달된다. 다음 그림은 이러한 ARQ 동작을 지원하는 자료구조를 나타낸 것이다.

Packing은 다수 개의 SDU 또는 SDU fragment들을 하나의 MAC SDU로 구성하여 전송하는 것이며, OPNET WiMAX 모델 또한 이 기능을 지원한다. "WiMAX 모델(21) - MAC 데이타 평면: 송신측"과 "WiMAX 모델(65) - Fragmentation 기능"에서 설명한 것처럼 전송할 패킷을 저장하기 위한 관(conduit)이 CID별로 존재하며, 상위 계층에서 내려온 패킷은 일단 SDU 버퍼에 저장된다. 만약 할당받은 대역폭이 한 개 이상의 SDU를 전송할 수 있는 크기이면 packing되어 여러 개의 SDU가 한 개의 MAC PDU로 만들어져 전송된다. Packing하는 과정에서 대역폭이 부족하면 마지막 SDU는 분할(fragmentation)된다.

"WiMAX 모델(62) - MAC PDU 구조"에서 살펴본 것처럼 wimax_mac_pdu 패킷에는 PSH(Packing subheader)를 위한 필드가 존재하지 않으며, PSH 크기만이 CRC 필드와 같이 반영되어 설정된다. PSH 크기(MAC_NE_PACK_SUBHEADER_BITS)는 wimax_support.h 파일에 16비트로 정의되어 있다. 이는 Extended Type이 아닐 경우의 PSH 필드에 대해서 표준[1]에서 정의한 크기이다([1]의 Table 22 참조).

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

어제(8월 15일) OPNET Modeler 17.5 PL5 버전이 발표되었습니다(이전 버전에 관한 내용은 "OPNET Modeler 17.5 PL4 발표" 참조). Release notes는 6월 27일자로 되어있기는 한데, 그 동안 본적이 없어서 어제 발표가 맞을 듯 합니다. 요즘 종종 그렇듯이 새 버전에 대한 공지는 없었습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 모델 및 Modeler에 대한 마이너 업데이트 내용이 대부분이며, 중요한 사항은 다음과 같습니다.

- PNNI Model Licensing Change
- IPv6 Path MTU Discovery
- Huawei Device Support

PNNI(Private Network-Network Interface) 모델이 이번 버전부터 Standard 모델 라이브러리에 포함되었다고 합니다. OPNET PNNI 모델은 Specialized 모델 중의 하나로 별도의 라이센스를 구매해야만 했었는데, 이제는 추가 라이센스 없이 사용이 가능해졌습니다.
IPv6 모델의 개선 사항은 Path MTU Discovery 기능 지원입니다. IPv6는 IPv4와 달리 소스 노드를 제외한 라우터에서는 fragmentation을 수행하지 않는 대신 Path MTU Discovery 기능을 통해 소스 노드가 MTU를 적정 크기로 조정할 수 있도록 합니다. 이 Path MTU Discovery 기능이 이번 버전에 구현되었다고 합니다.
프로젝트 에디터에서는 Huawei사의 장비들에 대한 노드 모델이 Object Palette에서 제공된다고 합니다. 이는 Huawei사의 제품들이 그만큼 시장에서 많이 사용된다는 반증이고 생각되어 상당히 놀랍습니다.
이외에도 여러가지 추가/변경된 사항들이 있지만, 현재 관심이 가는 내용이 아니라서 생략합니다.

OPNET 16.1 버전에서 MOS 계산시 delay가 중복하여 반영되는 문제가 있다(15.0, 16.0 버전에서도 동일한 문제가 있는 것을 확인하였으며, 17.1, 17.5 버전에서도 해결되지 않은 것으로 보여진다). 즉, packetization delay와 compression/decompression delay가 중복하여 반영되는 문제가 발생한다.
또한 이 delay 값들은 무시할만한 수준이 아니어서 최종 MOS 값에도 영향을 미친다.

이러한 문제에 대해서 OPNET사에 문의한 결과 오류로 확인되었으며, 이후 발표될 버전에서는 수정하기로 하였다. (SPR-176998: "Packetization, compression, decompression, and dejitter buffer delays are double-counted in MOS value computation of VoIP application traffic." 참조)