네트워크 시뮬레이션 공방

완성된 UL-MAP IE 정보는 다음 그림과 같은 구조를 가진다.

"WiMAX 모델(55) - UL-MAP 메시지 구조"에서 설명한 바와 같이, UL-MAP IE들은 WimaxT_Map 구조체의 해쉬테이블에 저장된다. 해쉬 테이블에서 각 IE를 구별하는 키로는 Basic CID와 purpose(Ex: WimaxC_Data, WimaxC_Harq_Data, WimaxC_Haraq_Retransmit_Data)를 조합한 값이 사용된다. OFDMA UL에서 버스트는 선형적으로 배치되므로 이 IE들은 WimaxC_IE_Type3를 dimention_type 값으로 가진다. UL에서는 Basic CID와 purpose가 동일한 승인에 대해서 하나의 IE만이 존재한다.
여기까지의 정보는 각 단말로 전송되는 버스트의 위치를 단말에게 알려주는 UL-MAP을 구성하기 위해서 필요한 정보들이며, WiMAX 표준과 관련있는 부분이다. 하지만, void 타입의 extra_info_ptr 변수에 저장되는 정보는 해당 버스트가 각각의 서비스 플로우에 의해서 어떻게 사용될 것인지에 대한 것을 단말에게 알려주기 위한 정보들이며, 표준과는 관련이 없다. (동일한 WimaxT_IE 구조체의 extra_info_ptr 변수가 DL-MAP과는 다른 용도로 사용됨에 유의해야 한다) "WiMAX 모델(32) - SS 스케줄러 (표준과의 비교)"에서 설명한 것처럼 BS는 SS 단위로 BW 승인 정보를 내려준다(GPSS 방식).
따라서, 여러 서비스 플로우들로부터의 BW 요청에 대한 승인이 하나의 IE로 나타나며, 이 때 각 서비스 플로우별 요청/승인에 대한 정보는 WimaxT_IE 구조체의 extra_info_ptr 변수에 저장된다. WimaxT_IE 구조체의 extra_info_ptr 변수는 각각의 서비스 플로우별 승인에 대한 정보를 담고 있는 IE들의 리스트이며, IE들은 역시 WimaxC_IE_Type3를 dimention_type 값으로 가진다. 각각의 서비스 플로우별 승인은 기본적으로 CID에 관계없이 BW 요청 별로 하나씩 별개의 IE로 존재한다. 하지만, HARQ 데이터 전송인 경우(purpose == WimaxC_Harq_Data), 하나의 IE로 병합(amalgamate)시킨다. 이 때 IE의 갯수는 증가하지 않지만, UL-MAP의 크기는 subburst IE만큼 증가한다.

"WiMAX 모델(57) - DL-MAP IE 정보"에서 설명한 것처럼 OFDMA DL에서는 Type2 IE 내부에 Type4 IE가 사용될 수 있으며, 이를 좀 더 자세하게 표현해보면 다음 그림과 같다.

Type2 IE는 정사각형(rectangular)의 버스트 배치를 표현하기 위해서 사용된다. 정사각형 버스트는 여러 서비스 플로우에서 발생하는 MAC PDU들이 합쳐져서 구성될 수도 있는데, 이러한 서비스 플로우별 MAC PDU를 위한 자원 할당을 표현하는 것이 Type4 IE이다.

완성된 DL-MAP IE 정보는 다음 그림과 같은 구조를 가진다.

"WiMAX 모델(53) - DL-MAP 메시지 구조"에서 살펴본 바와 같이, DL-MAP IE들은 WimaxT_Map 구조체의 해쉬 테이블에 저장된다. 해쉬 테이블에서 각 IE를 구별하는 키로는 Basic CID와 purpose(Ex: WimaxC_Data, WimaxC_Harq_Data, WimaxC_Harq_Retransmit_Data)를 조합한 값이 사용된다. OFDMA DL에서 버스트는 정사각형 형태로 배치되므로 이 IE들은 WimaxC_IE_Type2를 dimesion_type 값으로 가진다. Basic CID와 purpose가 동일하더라도 병합(amalgamate)시켜서 자원을 할당하지 않는 경우가 있는데, 이 때에는 별도로 분리된 IE가 존재하게 된다.
이런 경우에 사용되는 것이 WimaxT_IE 구조체의 extra_info_ptr 변수이며, 동일한 Basic CID와 purpose를 가지지만 별도로 존재하는 IE 정보를 가리키게 된다. 만약, 동일한 Basic CID와 purpose를 가지는 IE가 더 이상 존재하지 않으면 extra_info_ptr 변수는 NULL 값을 가진다. (동일한 키값을 가지는 IE는 여러 개 존재할 수 있으며, extra_info_ptr 변수는 각각 다음번 IE 정보를 가리키게 된다)
여기까지의 정보는 각 단말로 전송되는 버스트의 위치를 단말에게 알려주는 DL-MAP을 구성하기 위해서 필요한 정보들이며(비록 현재의 모델에서는 DL-MAP 정보를 실제로 단말로 전송하지 않지만), WiMAX 표준과 관련있는 부분들이다. 하지만, WimaxT_Request_Element 구조체에 저장되는 정보는 해당 버스트가 각각의 서비스 플로우에 의해서 어떻게 사용될 것인지에 대한 것을 wimax_bs_control 프로세스 모델에서 wimax_mac 프로세스 모델로 알려주기 위한 정보들이며, 표준과는 관련이 없다. "WiMAX 모델(38) - BS 스케줄러 병합 승인"에서 설명한 것처럼 OPNET WiMAX 모델은 같은 단말로 향하는 트래픽을 가능한 병합(amalgamate)시켜서 하나의 버스트로 전송한다. 따라서,
여러 서비스 플로우들로부터의 BW 요청에 대한 승인이 하나의 IE로 나타날 수 있으며, 이 때 각 서비스 플로우별 요청/승인에 대한 정보는 WimaxT_Request_Element 구조체의 extra_info_ptr 변수에 저장된다. WimaxT_Request_Element 구조체의 extra_info_ptr 변수는 각각의 서비스 플로우별 요청/승인에 대한 정보를 담고있는 IE들의 리스트이다. 단, 서비스 플로우별 자원 할당은 정사각형 형태를 가질 필요가 없으므로 이 때의 IE들은 WimaxC_IE_Type4를 demension_type 값으로 가진다. 여러 서비스 플로우들로 향하는 트래픽이 병합된 것이 아닌 경우에는 한 개의 Type4 IE가 포함된 리스트가 사용된다.

다음 그림은 표준[1]의 Compressed UL-MAP 메시지 구조를 나타낸 것이다([1]의 Table 432과 Table 376 참조). 이 중에서 OPNET WiMAX 모델의 UL-MAP 메시지로 실제 표현되는 부분은 녹색으로 표시된 부분들뿐이다.

DL-MAP 메시지의 기본 크기는 MAC_HEADER_SIZE_BITS와 WIMAXC_UL_MAP_DEADER_SIZE, 그리고 overhead regioin에 대한 IE들 크기의 합으로 설정된다. Overhead region에 대한 IE 크기는 raging region 수 x WIMAXC_IE_OFDMA_UL_CONTENTION_SIZE와 WIMAXC_IE_OFDMA_FAST_FEEDBACK_SIZE를 더한 것이다.
MAC_HEADER_SIZE_BITS는 48비트(6바이트)로 WIMAXC_UL_MAP_HEADER_SIZE는 48비트(6바이트)로 wimax_support.h에 정의되어 있다. UL-MAP 헤더 사이즈 48비트는 Compressed UL-MAP에서 패딩 비트가 필요하지 않을 때의 크기이다.
데이터 버스트를 위한 UL-MAP IE 하나의 크기(WIMAXC_IE_OFDMA_UL_DATA_SIZE)는 wimax_support.h 파일에 56비트로 정의되어 있는데, 이는 버그라고 생각된다. 왜냐하면, 데이터 버스트를 위한 IE(UIUC: 1 ~ 10)에서 사용되는

CID, UIUC, Duration, Repetition coding indication 필드 길이의 합은 32비트이기 때문이다.
Ranging region을 위한 UL-MAP IE 하나의 크기(WIMAXC_IE_OFDMA_UL_CONTENTION_SIZE)는 56비트로 정의되어 있는데,
이 또한 버그라고 생각된다. 왜냐하면, Ranging region을 위한 IE(UIUC: 12)에서 사용되는 CID, UIUC, OFDMA Symbl offset, Subchannel offset, No. OFDMA Symbols, No. Subchannels, Ranging Method, Dedicated ranging indicator 필드 길이의 합은 52비트이기 때문이다. (최신 표준문서에는 패딩 비트가 사용되지 않는다)
Fast Feedback regioin을 위한 UL-MAP IE 하나의 크기(WIMAXC_IE_OFDMA_FAST_FEEDBACK_SIZE)는 32비트로
정의되어 있는데, 이 또한 버그라고 생각된다. FAST-FEEDBACK_Allocation_IE()의 크기는 32비트가 맞지만, 이는 UL-MAP_IE()에 포함되어서 전송되어야 하므로 전체 크기는 52비트가 되어야 하기 때문이다.

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

UL-MAP 메시지는 wimax_mgmt_map 패킷의 Management Message Type 필드를 WIMAX_MGMT_UL_MAP 타입으로 설정하여 전송된다. UL-MAP IE 정보는 UL MAP 필드에 담겨서 SS로 전달된다.

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

다음 그림은 표준[1]의 Compressed DL-MAP 메시지 구조를 나타낸 것이다([1]의 Table 431과 Table 321 참조).
이 중에서 OPNET WiMAX 모델의 DL-MAP 메시지로 실제 표현되는 부분은 녹색으로 표시된 부분들뿐이다.

DL-MAP 메시지의 기본 크기는 MAC_HEADER_SIZE_BITS와 WIMAXC_DL_MAP_DEADER_SIZE의 합으로 설정되며, MAC_HEADER_SIZE_BITS는 48비트(6바이트)로 WIMAXC_DL_MAP_HEADER_SIZE는 88비트(11바이트)로 wimax_support.h에 정의되어 있다. DL-MAP 헤더 사이즈 88비트는 Compressed DL-MAP에서 패딩 비트가 필요하지 않을 때의 크기이다.
DL-MAP IE 하나의 크기(WIMAXC_IE_OFDMA_DL_DATA_SIZE)는 wimax_support.h 파일에 36비트로 정의되어 있으며, 이는 DIUC, OFDMA Symbol offset, Subchannel offset, Boosting, No. OFDMA Symbols, No. of Subchannels, Repetition Coding Indication 필드의 길이가 반영된 것이다.

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

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로 이동하여 역시 왼쪽에서부터 차례대로 배치한다.

"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