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로 전송한다.

 

 

 

Posted by 신상헌
,

데이터 패킷에 대한 송/수신 처리는 모두 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는 아직까지 실제로 사용되지는 않는다.

Posted by 신상헌
,

"WiMAX 모델 MAC 데이터 평면: 송신측"과 "WiMAX 모델 MAC 데이터 평면: 수신측"에서 살펴본 것처럼, OPNET WiMAX 모델은 IP 계층에서 내려온 패킷에 대해 매핑되는 CID 별로 분류하는 기능, CID별 큐잉기능, 전송 대역폭을 확보한 후 PHY 계층을 통한 전송 기능, PHY 계층을 통해 수신된 패킷에 대한 IP 계층으로의 전달기능을 제공한다.
MAC 데이터 평면의 이러한 기능 구조는 표준[1]에서 설명하고 있는 Classification and CID mapping 구조와 비교했을 때에도 거의 동일한 것이다. (하지만, PHS 기능은 OPNET에서 사용되지 않는다)


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

Posted by 신상헌
,
송신측과 비교하면 수신측의 구조는 매우 간단한데, WiMAX 모델 MAC에서 수신측의 Data plane 구조를 개념적으로 그려보면 다음과 같다.


PHY 계층에서 수신된 패킷은 송신측과는 달리 전송 대역폭을 확보하기 위해서 CID별로 큐에서 대기하는 과정을 거칠 필요없이 reassembly 과정만을 거쳐 IP 계층으로 전달된다.
Posted by 신상헌
,

WiMAX 모델 MAC에서 송신측의 Data plane 구조를 개념적으로 그려보면 다음과 같다.


IP 계층에서 내려온 패킷은 service class와 목적지 MAC 주소를 기준으로하여 매핑되는 CID를 찾고, 해당하는
CID 큐에 패킷을 저장한다. 만약, 매핑되는 CID를 찾을 수 없다면 패킷을 바로 폐기한다. CID 큐는 "WiMAX 모델(13) - Connections"와 "WiMAX 모델(16) - Service flow 생성"에서 설정한 것처럼 사용자가 정의한 내용에 따라 DSA 메시지 교환을 통한 service flow 생성과정에서 함께 만들어진다.
각각의 CID 큐에 저장되어 있던 패킷은 전송 대역폭을 확보하면 connection에 fragmentation, ARQ, HARQ가 적용되는지의 여부에 따라 필요한 segmentation 과정을 거친후 PHY 계층을 통해 BS/SS로 전송된다.

Posted by 신상헌
,
"WiMAX 모델(16) - Service flow 생성"에서 살펴본 것처럼 OPNET WiMAX 모델은 DSA 메시지 교환에 의한 Dynamic service flow creation을 사용한다. 하지만, 모든 DSA-REQ 메시지는 SS에서 보내지므로 SS-initiated이며, DSA-REQ, DSA-RSP, DSA-ACK 메시지가 사용된다. DSA-ACK 메시지가 추가된 것은 아주 최근("OPNET Modeler
16.0 PL4 발표" 참조)의 일이다. 설정될 service flow는 사전에 결정되어 있으며, intial ranging이 끝나면 모든 service flow가 바로 생성된다. (핸드오버를 제외하면) 시뮬레이션 중간에 SF가 새로 만들어지거나 삭제되는 일은 없다. Servcie flow는 생성과정이나 삭제과정동안 외에는 항상 "activated" 상태이며, SF 생성과정은 connection 설정 과정을 포함한다.
IEEE 802.16 표준[1]("IEEE 802 표준문서 다운받기"에 언급된 사이트에서 구할 수 있다)에 따르면, WiMAX에서 SS-initiated 방식의 dynamci service lfow creation과정에서는 DSA-REQ, RSX-RVD, DSA-RSP, DSA-ACK 메시지가 사용되는데, OPNET에서는 DSX-RVD 메시지가 사용되지 않는다.


OPNET WiMAX 모델의 Service flow는 사전에 모두 계획되어지고 Network entry 과정에서 생성된다는 점에서, WiMAX Forum NWG 문서[2]("WiMAX Forum 표준문서 다운받기"에 언급된 사이트에서 구할 수 있다)에서 언급하는 Pre-provisioned service flow와 유사하다. 하지만, BS-initiated가 아닌 SS-initiated 방식이라는 점에서는 다르다.


[1] IEEE 802.16-2009, "Air Interface for Broadband Wireless Access Systems", 2009
[2] WiMAX Forum, "WiMAX Forum Network Architecture - Architecture Tenets, Reference Model and Reference Points, Base Specification - Release 1.6", 2010.
Posted by 신상헌
,

Service flow에 대한 정보는 WimaxT_Service_Flow 구조체에 저장되어서 관리된다. WimaxT_Service_Flow 구조체는 Admission control 결과를 관리하는 WimaxT_Admission_Element 구조체의 멤버로서 포함되며, WimaxT_Admission_Element 구조체들의 리스트는 UL/DL 여부에 따라 WimaxT_Data_Plane_Config 구조체의 ul_svc_flows_lptr 또는 dl_svc_flows_lptr 포인터에 저장된다 (WimaxT_Data_Plane_Config 구조체는 wimax_mac, wimax_ss_control, wimax_bs_control 프로세스 모델에 State varialbe인 data_plane_config_ptr로 선언되어 있다).
따라서, service flow 정보가 저장되는 데이터 구조를 전체적으로 그려보면 다음 그림과 같다. 관련된 모든 구조체에 대한 정의는 wimax_support.h 파일에 정의되어 있다.


이 WimaxT_Service_Flow 구조체에 저장된 Service flow에 대한 정보는 DSA-REQ/DSA-RSP 메시지 전달시에 "Service Flow Parameters" 필드에 저장되어서 전달된다.

Posted by 신상헌
,
Service flow 생성에 사용되는 DSA 메시지들의 구조를 살펴보자. 먼저 DSA-REQ 메시지에 해당하는 wimax_mgmt_dsa_req 패킷의 구조는 다음 그림과 같다.


"Management Message Type" 필드에서는 DSA-REQ 메시지임을 나타내기 위해서 WIMAX_MGMT_DSA_REQ 값이 설정된다. "Header Type" 필드는 원래 "MAC Header" 필드에 포함되는 정보이지만, 구현상의 편의를 위해서 별도의 필드로 끄집어 내어놓은 것이다. DSA 메시지의 경우 이 "Header Type" 필드의 값을 별도로 설정하는 과정없이 그냥 사용하는데, 이는 "Header Type" 필드의 기본값이 0으로 WIMAX_HT_GENERIC 정의와 같으므로, WIMAX_HT_GENERIC 타입의 MAC PDU라면 별도의 설정없이 사용하는 것이 가능하기 떄문이다. (하지만, 이는 사용자들을 혼란스럽게 하는 것으로 WIMAX_HT_GENERIC 일지라도 값을 설정하는 과정이 추가되어야 한다고 생각한다. 제어 메시지가 아닌 일반적인 데이터를 위한 MAC PDU의 경우 WIMAX_HT_GENERIC 타입으로 설정하는 과정이 있어서, 보다 이해하기 쉽다) "Service Flow Parameters" 필드는 생성을 요청하는 Service flow에 대한 정보를 가지고 있는 구조체를 저장하여 전달한다.

DSA-RSP 메시지에 해당하는 wimax_mgmt_dsa_rsp 패킷의 구조는 다음 그림과 같다. Call Admission control에 대한 결과를 저장하기 위한 "CC"(Confirmation Code) 필드가 추가되어 있는 것과 구현상의 편의를 위한 0비트 크기의 필드들이 없다는 점이 DSA-REQ 메시지와 다르다. "Management Message Type" 필드에는 DSA-RSP 메시지임을 나타내기 위해서 WIMAX_MGMT_DSA_RSP 값이 설정된다.


DSA-ACK 메시지에 해당하는 wimax_mgmt_dsa_ack 패킷의 구조는 다음 그림과 같다. 패킷의 구조는 wimax_mgmt_dsa_rsp 패킷과 비슷하지만, "Service Flow Paraemters" 필드는 없다. "Management Message Type" 필드는 DSA-ACK 메시지임을 나타내기 위해서 WIMAX_MGMT_DSA_ACK 값이 설정된다.

Posted by 신상헌
,
OPNET WiMAX 모델은 DSA 메시지 교환에 의한 Dynamic service flow creation을 사용하여 Service flow를 생성한다. DSA 메시지 교환을 통해 생성되는 Service flow는 UL/DL service flow, UL/DL default flow, UL broadcast flow이며, DSA-REQ 메시지는 항상 SS에서 시작된다(이는 OPNET WiMAX 모델의 경우 Service flow 설정이 SS의 파라메터로 정의되어 있는 것과 관련이 있는 것으로 생각된다). DSA 메시지 교환 절차는 다음 그림과 같다.


SS가 보낸 DSA-REQ 메시지를 BS가 수신하면 CAC(Call admission control) 과정을 거처, DSA-RSP 메시지가 응답으로 전송된다(CAC 기능 모듈의 내용에 대해서는 나중에 다시 살펴볼 것이다). 그러면, SS는 다시 DSA-ACK 메시지를 BS로 전송하고, Service flow 생성과정이 완료된다. Service flow를 변경하거나 삭제하는 절차는 제공하지 않는다. 즉, DSC/DSD 메시지는 사용되지 않는다.
Posted by 신상헌
,
"WiMAX 모델(13) - connections"에서 살펴본 것처럼, OPNET WiMAX 모델은 Control connection(Basic, Primary
management), Initial Ranging connection, Broadcast connection(DL broadcast, UL broadcast), Default flow connection, Service flow connection을 사용한다.
IEEE 802.16 표준[1]("IEEE802 표준문서 다운받기"에 언급된 사이트에서 구할 수 있다)에 따르면, WiMAX에서 사용하는 connection은 management connection과 transport connection으로 구분할 수 있으며, management connection은 Basic, Primary management, Secondary management, Initial ranging, Broadcast 등을 포함한다.
OPNET WiMAX 모델에서 사용하는 connection과 IEEE802.16 표준에서 설명하는 connection간의 관계를 매핑시켜보면 다음 그림과 같다. 표준의 Secondary management connection은 OPNET에서 사용되지 않는 반면, OPNET에서 기본적으로 설정되는 UL broadcast connection이 표준에는 없다. 다른 connection들은 OPNET WiMAX 모델과 표준의 내용이 일치한다.


[1] IEEE 802.16-2009, "Air Interface for Broadband Wireless Access Systems"
Posted by 신상헌
,