네트워크 시뮬레이션 공방

DL-MAP 메시지는 wimax_mgmt_map 패킷의 Management Message Type 필드를 WIMAX_MGMT_DL_MAP 타입으로 설정하여 전송된다. 그런데, 다음 그림에서 보여지듯이 wimax_mgmt_map 패킷에는 실제 DL-MAP IE를 저장하기 위한 필드가 없다. "WiMAX 모델(44) - 프레임 구조"에서 설명한 바와 같이 DL-MAP IE 정보는 BS 내부에서만 사용되며, SS로 보내지는 DL-MAP 메시지에서는 단순히 DL-MAP IE 정보의 크기만이 반영된다.

DL-MAP 정보는 WimaxT_Map 구조체의 type 필드를 DL로 설정하여 사용하며, 각 DL-MAP IE들은 해쉬 테이블에 저장/관리된다. 해쉬 테이블에서 각 IE를 구별하는 키로는 Basic CID와 purpose(Ex: WimaxC_Data, WimaxC_Harq_Data, WimaxC_Harq_Retransmit_Data)를 조합한 값이 사용된다. DL-burst의 좌표값에 대한 정보는 dementions_ptr 포인터에 의해 가리켜지는데, DL에서는 WimaxT_IE_Dim_Type2 구조체가 사용된다.

"WiMAX 모델(44) - 프레임 구조"에서 언급하였듯이, UL-burst들은 1차원적으로 배치되므로 가로축을 따라서 먼저 채워지고, 가로축이 모두 채워지면 다음 세로축으로 넘어가서 배치된다. 다음 그림은 이를 좀더 상세하게 표현한 것이다.

UL-burst는 UL 서브프레임의 좌측 상단에서부터 시작하여 가로로(Horizontal) 배치된다. 역시 자원이 할당되

는 단위는 slot이다. 자원을 할당하는 규칙은 다음과 같다.
1) UL 서브프레임 상단의 subchannel부터 왼쪽에서 시작하여 오른쪽으로 배치한다. 만약 해당 subchannel에 제어 영역(Contention region이나 Fast Feedback region)이 있다면, 제어영역을 건너뛰고 배치한다.
2) UL 서브프레임의 오른쪽 끝에 도달하면 다음 세로축의 subchannel로 이동하여 역시 왼쪽에서부터 차례대로 배치한다.

TMM(Terrain Modeling Module)은 지형에 의한 경로 손실을 OPNET에서 시뮬레이션할 수 있는 기능을 제공한다. TMM을 사용하기 위해서는 대상 지역에 대한 지형정보(DTED 혹은 USGS DEM)가 필요한데, 이러한 지형정보를 OPNET에서 자체적으로 제공하지는 않는다.
DTED Level 0는 정밀도가 떨어지기는 하지만, 파일을 인터넷에서 쉽게 다운로드 받을 수 있다. 다음 그림은 한반도 지역에 대한 DTED Level 0를 적용한 결과이다.

"WiMAX 모델(44) - 프레임 구조"에서 언급하였듯이, DL-burst들은 직사각형(rectangular) 형태를 가지며 세로축을 따라서 먼저 채워지고, 세로축이 모두 채워지면 다음 가로축으로 넘어가서 배치된다. 다음 그림은 이를 좀더 상세하게 표현한 것이다.

DL-burst는 DL 서브프레임의 좌측 상단에서부터 시작하여 세로로(Vertical) 배치된다. 이 때 자원이 할당되는 단위는 slot이다. (앞에서 설명한 바 있드시, quantum은 slot과 동일한 크기 영역을 가리키는 것이므로 여기에서는 두 용어를 필요에 따라 같이 사용한다) 자원을 할당하는 규칙은 다음과 같다.
1) 현재의 열(column)에 남아있는 자원이 burst를 배치하는데 필요한 자원이상이면, 현재의 위치에서부터 시작하여 burst를 배치한다.
2) 현재의 열(column)에 남아있는 자원이 burst를 배치하는데 필요한 자원보다 작으면, 다음 가로축의 첫번째 subchannel로 이동하여 burst를 배치한다.
3) 현재의 위치가 첫번째 subchannel이고 현재의 열(column)에 남아있는 자원이 burst를 배치하는데 필요한 자원보다 작으면, column 전체를 여러개 사용하는 직사각형 형태로 버스트를 배치한다.

버스트 매핑은 단방향으로만 진행되며, 중간에 건너뛰어진 자원은 다시 사용되지 않고 버려진다.

OPNET WiMAX 모델의 quantum(WiMAX 모델(46) - Allocation quantum 참조)은 표준[1]의 slot과 대응된다. Slot은 DL/UL, FUSC/PUSC 여부에 따라 다음과 같이 크기가 달라진다.
- DL FUSC : one subchannel x one symbols
- DL PUSC : one subchannel x two symbols
- UL PUSC : one subchannel x three symbols

따라서, quantum과 slot은 같은 크기를 가진다는 것을 알 수 있다. 하지만, slot은 그 자체가 하나의 기본 단위로써 사용되는데 반해서, quantum은 quantum 하나의 크기에 들어갈 수 있는 symbol 수를 값으로 가진다는 점에서 다르다.
quantum 값을 계산할 때 필요한 subchannel당 subcarrier 수는 [1]에 정의되어져 있으며 계산으로 구할 수도 있다. ([1]의 8.4.6 OFDMA subcarrier allocation 참조) 예를 들어, PUSC DL 일 때 subchannel당 sucarrier 수는 24이다.
data rate(bits/symbol)는 해당 변조기법을 사용할 때 한 symbol이 표현하는 비트수로써, [1]의 modulation order에 해당한다. [1]에서 modulation order는 다음과 같이 정의된다.
- QPSK   : 2
- 16-QAM : 4
- 64-QAM : 6

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

ex) PUSC 방식의 DL일 때, quantum은 24 x 2 = 48 symbol의 값을 가진다. 이 quantum이 전송할 수 있는 데이터 양을 각 변조방식에 따라 계산해보면 다음과 같다.
- QPSK 1/2   : 48symbols x 2bits/symbol x 1/2 = 48 bits = 6Bytes
- 16-QAM 3/4 : 48symbols x 4bits/symbol x 3/4 = 144 bits = 18Bytes
- 64-QAM 3/4 : 48symbols x 6bits/symbol x 3/4 = 216 bits = 27Bytes

"네트워크 Jitter(1) - VoIP 실험을 위한 네트워크 Jitter 설정"에서 설명한 것처럼 ip32_cloud 노드 모델의 Packet Latency (secs) 속성을 이용하여 망 전체에서 발생하는 Jitter를 넣어주는 방법을 사용할 때, 고려할 수 있는 유용한 Jitter 분포 모델 중 한가지는 laplace 분포이다.
다음 그림은 평균 = 45ms, scale = 3.9ms의 laplace 분포로 발생된 latency의 PDF를 나타낸 것이다.

VoIP 시뮬레이션을 할 때 Jitter는 VoIP 서비스의 품질(ex: MOS)에 큰 영향을 미치는 중요한 요소이다. 대상 통신망 구조와 트래픽을 모두 모델링하여 시뮬레이션에 반영하고 시뮬레이션 과정에서 Jitter가 자연스럽게 발생하도록 하는 방법도 생각해볼 수 있겠지만, 이는 망 구조나 트래픽 정보 수집에 대한 어려움을 차치하고서라도 시뮬레이션 수행시간이 너무나도 오래 걸릴 수 있기 때문에 실제로 사용하기는 매우 곤란하다.
따라서, 많은 경우에 있어 (ip32_cloud 노드 모델의 Performance Metrics-->Packet Latency (secs) 속성같은) 강제적인 방법으로 망 전체에서 발생하는 Jitter를 넣어주는 방법을 사용하기도 한다.

OPNET WiMAX 모델은 자원 할당을 위한 최소 단위로써 quantum이라는 정의를 사용하고 있다. 따라서, 자원은 quantum 단위로 할당되며, quantum보다 작은 크기의 자원은 할당될 수 없다. OFDMA 방식에서 quantum은 subchannel당 subcarrier 수와 quantum당 symbol 수의 곱으로 정의된다. (즉, 1 subch x quantum symbols이다) Quantum당 symbol의 수는 DL/UL, PUSC/FUSC 여부에 따라 달라진다. 다음 그림은 이를 표현한 것이다.

Bit 단위의 BW 요청은 변조방법과 코딩 레이트를 고려하여 symbol 단위로 변환된다. 이 symbol 단위의 요청 BW를 quantum으로 나누었다가 다시 quantum으로 곱해주면, 요청된 BW를 전송할 수 있는 quantum 단위의 자원 크기를 구할 수 있다. 단, quantum으로 나눌 때에는 결과값을 올림(ceil) 처리한다.

OFDMA 방식일 때 OPNET에서 사용하는 WiMAX 프레임의 구조는 다음 그림과 같다.

Preamble은 다른 burst들의 전송 시점을 계산하기 위해서 사용될 뿐이며, preamble 자체가 실제로 전송되지는 않는다.
DL-MAP은 PHY를 통해서 전송되기는 하지만, 실제로 DL-MAP IE 정보가 전달되지는 않는다. 단지 DL-MAP 크기만큼의 공간을 차지하는 dummy burst가 전송될 뿐이다. 실제 시스템이라면 DL-MAP의 정보를 이용해야만 이후에 따라오는 데이터 프레임들을 정상적으로 수신할 수 있지만, 시뮬레이션에서는 DL-MAP의 정보가 없더라도 데이터 프레임을 수신하는데 아무런 문제가 없다. 그래서, 구체적인 IE 정보를 담은 DL-MAP을 전송하는 대신, 해당 크기만을 가지는 burst를 전송하는 것이다. (DL-MAP을 아예 전송하지 않았었던 15.0 버전과 비교하면 DL-MAP 전송기능이 많이 보강된 것이다) UL-MAP은 실제 IE 정보를 포함하여 전송된다.
DL-MAP과 UL-MAP은 모두 수직축(Subchannel number)을 따라서 차례대로 채워져 나가는데, 수직축의 끝에 도달하면 다음 수평축(Symbol number)으로 넘어간다. 만약 배치된 DL-MAP이나 UL-MAP이 직사각형(rectangular)이 아닐 경우, 직사각형별로 분할(fragmentation)된다.
UL-MAP 이후에는 DL-burst가 배치된다. DL-burst들 역시 세로축을 따라서 먼저 채워지고, 세로축의 끝에 도달하면 다음 가로축으로 넘어간다. 각 DL-burst는 직사각형(rectangular) 형태를 가진다.
DL 구간이 끝나면 TTG 시간 간격이후 UL 구간이 시작된다. UL 구간에는 Initial & Handover Ranging 영역, Periodic & BWR Ranging 영역, Fast Feedback 영역이 배치되는데, 각각 정사각형의 모양을 가진다. 이러한 overhead 영역들의 크기는 사용자 설정에 따라 변경될 수 있지만, 영역의 시작지점은 고정적이다. 가로축으로 보았을 때 각 영역의 시작점은 UL 구간의 시작점이며, 세로축으로 보았을 때는 각 영역이 시작점부터 연속적으로 배치된다.
UL-burst는 DL-burst와 달리 가로축을 따라서 먼저 채워지고, 가로축의 끝에 도달하면 다음 세로축으로 넘어간다. 그런데, overhead 영역들은 가로축으로 서로 다른 길이를 가질 수 있으며, 또한 세로축의 끝까지 모두 채워지는 것도 아니다. 따라서, subchannel마다 다른 시작 symbol 시점에 맞추어서 구불구불(snaking)하게 UL-burst가 배치된다. UL 구간이 끝나고 나면, RTG 시간 간격 이후 다음 프레임이 시작된다.

향후에는 OPNET Modeler 제품에서 Red Hat Enterprise Linux(RHEL) 4와 Fedora Linux 6에 대한 지원이 이루어지지 않을 것이라는 발표가 지난 12월 6일에 있었습니다. 다만, 이는 Linux OS 자체에 대한 지원이 중단된다는 의미가 아니며, 해당 버전의 Linux에 대한 지원을 중단한다는 것입니다. 얼마전에 발표되었던 OPNET Modeler 17.5 버전("OPNET Modeler 17.5 PL3 발표" 참조)에서는 RHEL 4, 5, 6 버전과 Fedora Linux 6 버전의 Linux를 지원하고 있습니다. 따라서, 17.5 버전이 RHEL 4와 Fedora 6를 지원하는 마지막 버전이 될 것이라고 합니다.
국내에서는 Linux 환경에서 OPNET을 사용하는 사용자가 매우 적은 것으로 알고 있어서, 큰 영향은 없을 것 같기는 합니다.