네트워크 시뮬레이션 공방

OPNET WiMAX 모델에서 사용하는 MAC connection의 종류는 다음과 같이 구분해 볼 수 있다(분류와 명칭은 필자의 생각에 의한 것이다). 이중에서 Service flow connection과 Control connection은 사용자의 설정에 의해서 생성되며, 다른 connection들은 사용자의 설정과는 상관없이 자동적으로 생성된다.
- Default flow connection
- Service flow connection
- Control connection
- Broadcast connection
- Initial ranging connection
Default flow connection은 사용자가 Service flow connection을 정의하지 않았거나, 패킷의 특징과 일치하는 Service flow connection이 없을 경우에 패킷을 전달하기 위해서 사용된다. DL/UL 구간에 각각 한개씩 생성되며, BE 타입의 스케줄러가 적용된다.
Service flow connection은 사용자 설정에 의해서 생성되며, 역시 사용자가 정의해준 Classifier 규칙에 맞는 패킷들을 전달하는데 사용된다.
Control connection은 제어/관리 메시지를 전달하기 위해서 사용되는 것으로, Basic connection과 Primary management connection 두 가지 종류가 있다.
Broadcast connection은 브로드캐스트 메시지를 전달하기 위한 것인데, DL 구간과 UL 구간 connection의 설정 과정이 서로 다르다. UL broadcast connection은 DSA 메시지 교환에 의해서 설정되지만, DL broadcast connection은 별도의 DSA 메시지 교환과정없이 내부적으로 설정된다.
Initial ranging connection은 BS와 SS에서 ranging 처리과정동안 사용되는 것으로 initial ranging이 끝나면 periodic ranging에서도 사용된다.

OPNET WiMAX 모델에도 많은 수의 매크로가 사용되고 있지만, global_efficiency_on은 소스 코드를 분석할 때 자주 만나게 되는 특히 중요한 매크로이다. 왜냐하면, WiMAX MAC에서 패킷을 PHY로 내려보내고자 할 때 다음과 같이 global_efficiency_on 값이 참인지 아닌지에 따라서 처리하는 과정이 양분되는 경우가 많기 때문이다.

if(global_efficiency_on)
  {
  ...
  }
else
  {
  ...
  }

global_efficiency_on 매크로는 wimax_support.h 파일에 다음과 같이 선언되어 있다.
#define global_efficiency_on  (global_efficiency_level == WIMAXC_EFFICIENCY_ENABLED)

global_efficiency_level 변수는 wimax_support.ex.c 파일에 정의되어 있는 int 타입의 전역변수로서, WiMAX_Config 노드의 "Efficiency Mode"에 설정된 값을 반영한다. "Efficiency Mode"에는 "Efficiency Enabled", "Framing Module Enabled", "Physical Layer Enabled", "Mobility and Ranging Enabled" 4가지 모드가 설정 가능한데, global_efficiency_on 매크로가 참이 되는 경우는 "Efficiency Mode" 속성이 "Efficiency Enabled"로 설정되었을 때이다. 즉, OPNET WiMAX MAC의 세부적인 동작은 DL/UL 프레임을 반영할 때와 반영하지 않을 때로 구분되는 경우가 많은 것이다.
앞으로의 OPNET WiMAX 모델 분석은 "Efficiency Mode" 속성의 설정이 "Mobility and Ranging Enabled"인 경우를
기준으로 한다. 다시 말해서, 별도의 설명이 없으면 global_efficiency_on 매크로의 값이 거짓인 경우에 대해서 분석한 것이다.

oms_mux_demux_mac_interface 프로세스 모델은 3섹터 BS 노드에서 3개의 WiMAX MAC을 하나의 IP 모듈에 연결시키기위하여 사용된다. 엄밀히 얘기하자면, oms_mux_demux_mac_interface 프로세스 모델은 WiMAX 모델만을 위한 것은 아니다. 하지만, WiMAX 모델을 개발하는 과정에서 같이 개발된 것으로 생각되며, WiMAX 이외의 다른
곳에서 사용되는 것은 아직 보지못했다.

프로세스 모델의 구조는 상당히 간단하다. 상위 계층으로부터 패킷이 도락하면 appl layer arrival 스테이트로 천이하며, 패킷의 최종 목적지 노드가 위치한 섹터를 담당하는 WiMAX MAC으로 패킷을 전달한다. 만약 브로드캐스트 패킷이면, 패킷을 복사하여 3개의 WiMAX MAC으로 모두 전달한다.
하위 계층으로부터 패킷이 도착하면 mac layer arrival 스테이트로 천이하며, 상위 계층으로 패킷을 전달한다.
MAC_MUX_DEMUX_CMD 이벤트는 wimax_bs_control 프로세스에서 보내는 remote interrupt에 의해서 발생된다.
wimax_bs_control 프로세스는 자신이 담당하는 섹터에 새로운 MS가 들어오거나 나갈 때, 이를 oms_mux_demux_mac_interface 프로세스에 알려주어 MUX/DEMUX 테이블이 갱신될 수 있도록 해준다. (oms_mux_demux_user_position_update/remove() 함수 이용)

wimax_rs_control 프로세스 모델은 wimax_mac 프로세스의 차일드 프로세스로서, RS 노드의 제어 메시지 처리 및 relay 기능을 담당한다. 즉, 해당 노드가 RS일때만 wimax_rs_control 프로세스가 차일드 프로세스로 생성되는 것이다.

현재(16.0 PL6)의 RS 노드는 transparent relay in cetralized mode 방식으로만 동작하며, UL 구간의 relay만이 이루어진다. MAP에 대한 디코딩은 wimax_rs_control 프로세스에서 수행하지 않으며, wimax_ss_control 프로세스로부터 디코딩된 MAP 정보를 넘겨받아서 사용한다(RS 노드에는 wimax_ss_contrl 프로세스도 같이 생성된다).
wait_for_ss 스테이트는 wimax_ss_control 프로세스에 의한 initial ranging 절차가 끝나기를 기다리는 단계이며, initial ranging이 완료되면 receive_mode 스테이트로 이동한다. 이후, 프로파일에 정의된 주기에 따라 receive_mode 스테이트와 transmit_mode 스테이트간을 오고가며 relay 기능을 수행한다.

wimax_ss_control 프로세스 모델은 wimax_mac 프로세스의 차일드 프로세스로서, SS 노드의 제어 메시지 처리 및 MAP 디코딩, BS 탐색, 연결 설정/해제 등의 관리 기능을 담당한다. 즉, 해당 노드가 SS 또는 RS 일때만 wimax_ss_control 프로세스가 차일드 프로세스로 생성되는 것이다.

wimax_ss_control 프로세스 모델은 스테이트 다이어그램이 대단히 복잡하게 되어 있는데, 이는 SS에서 수행되어야하는 기능이 많은 탓도 있겠지만 실은 wimax_ss_control 프로세스 모델이 개발된 과정과도 큰 관련이 있다(아마도, 단일 프로세스 모델로서는 OPNET을 통털어 가장 복잡한 범주에 들 것이다. 하지만, 소스 코드의 양을 비교해보면 복잡하기 그지없어 보이는 wimax_ss_control 프로세스 모델이 11,000 라인정도인데 비하여, 아주 단순한 구조를 가지고 있는 wimax_bs_control 프로세스 모델은 21,000 라인이나 된다). WiMAX 모델은 여러가지 기능들이 몇차례의 단계를 거쳐서 개발되었는데(이는 현재에도 Simulation Efficiency와 관련이 깊다). wimax_ss_control 프로세스 모델의 경우 초기 단계에서 이후의 기능 확장을 충분히 고려하여 설계하지 못한 듯 하다.
이 탓에 초기에는 아주 단순한 구조로만 되어 있던 프로세스 모델이었지만, 이후에 기능이 추가될 때마다 스테이트도 계속 늘어나서 현재와 같이 매우 복잡한 구조가 되어버렸다. 실제로 다음 그림의 초기 wimax_ss_control 프로세스 모델을 살펴보면, wimax_bs_control 프로세스 만큼이나 아주 단순한 구조로 설계되어 있는 것을 볼 수 있다.

wimax_ss_control 프로세스 모델의 스테이트들은 Initial Ranging, Connected, Scanning/Handover, Power Saving의 4가지 기능영역으로 크게 나눌 수 있으며, 프로세스 모델에서 각각 보라색, 녹색, 노락색, 하늘색으로 표시되어 있다. Initial Ranging 영역에서는 연결할 새로운 BS를 선택하고 initial ranging을 통해 Basic Connection을 수립하는 기능을 수행한다. Connected 영역에서는 UL-MAP에 대한 디코딩과 periodic ranging, 그리고 제어 패킷들에 대한 처리를 수행한다. Scannning/Handover 영역에서는 주변 BS들에 대한 scanning과 target BS 결정, 그리고 Handover 메시지 송수신 기능을 수행한다. Power Saving 영역에서는 장시간 데이터 송/수신이 없는 단말의 에너지 소모를 줄이기 위해서 sleep과 listen 기능을 수행한다.

얼마전에 OPNET Modeler 16.1 버전이 발표되었다. ("OPNET Modeler 16.1 PL1 발표" 참조) 하지만, 새 버전에는 WiMAX 모델에 대한 변경이 미미한 것으로 보여진다. 그래서, 여기에서는 기존에 분석중이었던 16.0 PL6 버전을 기준으로 분석을 계속하겠다. 

==========================================================================================
wimax_bs_control 프로세스 모델은 wimax_mac 프로세스의 차일드 프로세스로서, BS 노드의 제어 메시지 처리 및 MAP 생성 등의 관리 기능을 담당한다. 즉, 해당 노드가 BS 일때만 wimax_bs_control 프로세스가 차일드  프로세스로 생성되는 것이다.

외부로부터 wimax_bs_control 프로세스로 전달되는 패킷은 모두 제어 메시지이므로, CONTROL_PACKET에 의한 천이가 발생하고 제어 메시지 종류에 따라 처리해준다. DSA-REQ 메시지인 경우에는 연결 수락 여부를 결정하는 Admission control이 수행되고, BWR 메시지인 경우에는 UL구간 BW 할당 절차를 수행한다. 패킷이 도착하지 않았더라도 ASN 시그날링이 도착한 경우에는 CONTROL_PACKET 천이가 발생한다.
외부로부터의 인터럽트가 발생하였지만 패킷이 없는 경우는 BS에서 DL구간 BW를 요청하는 것이므로, BW 할당 절차를 수행한다. WIMAXC_BWR_SELF_ARRIVAL 코드를 가지는 셀프 인터럽트가 발생한 경우는 제어 메시지 전달을
위한 DL구간 BW가 필요한 것이므로, 역시 BW 할당 절차를 수행한다.
wimax_bs_control 프로세스는 MAP 생성을 위한 셀프 인터럽트를 주기적으로 발생시키며, 이 이벤트에 따라 DL/UL-MAP을 생성하여 wimax_mac 프로세스로 넘겨준다.

wimax_mac 프로세스 모델은 WiMAX MAC에서 루트 프로세스이며 BS와 SS, 그리고 RS에서 공통적으로 사용된다.

상위 계층(IP)에서 MAC으로 내려온 패킷과 하위 계층(PHY)에서 수신된 패킷은 모두 일단 이곳을 거쳐서 처리된다. 상위 계층에서 내려온 패킷은 모두 데이터 패킷이며, 하위 계층에서 수신된 패킷은 데이터 패킷과 제어 패킷이 섞여 있다. 사용자 데이터일 경우 이 프로세스 모델에서 직접 처리한고, 제어 패킷일 경우 차일드 프로세스에서 처리될 수 있도록 패킷을 넘겨준다.
tx_schedule 스테이트로의 천이는 SS에서 UL-MAP을 수신하였을 때나 BS에서 DL-MAP 정보를 생성하였을 때, 해당 차일드 프로세스가 알려주는 이벤트에 의해서 발생한다. tx_schedule 스테이트에서는 이렇게 전달받은 승인(grant) 정보들을 이용하여 데이터 패킷이나 제어 패킷에 대한 전송을 op_pk_deliver_delayed() 함수를 통해서 미리 예약해서 전송한다.

WiMAX 모델에서 사용하는 단말 노드 모델의 구조는 다음 그림과 같으며, WiMAX MAC 프로세스 모델과 파이프라인 스테이지를 사용한다는 것 외에는 일반적인 노드 모델의 구조와 동일하다. OPNET 사용자들이 이미 잘 알고 있듯이 OPNET에서는 일반적으로 별도의 PHY 프로세스 모델을 사용하지 않으며, PHY 기능의 대부분은 파이프라인 스테이지에서 구현된다. 하지만, 파이프라인 스테이지에서 구현하기에는 곤란한 일부 PHY 기능의 경우 MAC 프로세스 모델에서 구현되는데, 이는 WiMAX 모델의 경우에도 마찬가지이다. 아래 그림에서 MAC과 PHY 계층 기능을 구분하여 선을 그어 놓기는 했지만, 실제 구현 과정에서 일부 PHY 기능은 MAC 계층에 통합되어져 있다고 보아야 할 것이다.

섹터 구분이 없는 기지국의 경우 노드 모델의 기본적인 구조는 단말 노드와 다르지 않으며, 섹터 구분이 있는 기지국 모델의 경우 다음 그림과 같이 MAC과 ARP 사이에 추가적인 인터페이스 모델이 붙어 있다. 하지만, 이 인터페이스 모듈이 하는 일은 단순히 패킷을 해당하는 섹터를 담당하는 MAC으로 넘겨주는 역활만이며, 실질적인 MAC 계층 기능과는 관련이 없다. (팔레트의 wimax 노드 모델 그룹에서는 보이지 않지만 추가적인 인터페이스 모델없이 WiMAX MAC마다 별도의 ARP 모듈을 가지고 있는 노드 모델이 있는데, 이는 초창기에 사용되던 모델이다)

3섹터 기지국의 경우, 3개의 안테나가 각각의 섹터를 서비스하도록 설정되어져 있으며 이는 노드 모델 좌측의 Physical Layout에서 다음 그림과 같이 확인할 수 있다.

위 그림에서 보여지듯이, 각각의 안테나는 x축을 기준으로 60도, 180도, 300도 방향을 지향하고 있으므로 3 섹터가 담당하는 지역은 x축을 기준으로 각각 0~120도, 120~240도, 240~360도 방향의 지역이다. 각 섹터의 안테나는 약 160도를 커버하는 안테나 모델을 사용하고 있으므로 실제로 각 섹터는 이웃 섹터와 약 40도씩 중첩된다.

OPNET WiMAX 모델에서 제공하는 노드 모델의 종류는 다음과 같다(16.0 PL6 기준).
- wimax_3sector_bs_atm2_ethernet2_slip4_wlan_router
- wimax_3sector_bs_atm2_ethernet2_slip4_wlan_router_adv
- wimax_bs_atm8_ethernet8_fr8_slip8_router
- wimax_bs_ethernet4_slip4_router
- wimax_bs_ethernet4_slip4_router_adv
- wimax_bs_router_adv
- wimax_rs_station
- wimax_rs_station_adv
- wimax_ss_ethernet_slip_wlan_router
- wimax_ss_ethernet_slip_wlan_router_adv
- wimax_ss_server
- wimax_ss_server_adv
- wimax_ss_wkstn
- wimax_ss_wkstn_adv
- wimax_ss_wlan_router
- wimax_ss_wlan_router_adv

하지만, 노드의 역활에 따라 분류하면 기지국(BS)과 단말(SS), 그리고 중계국(RS)의 3가지 타입으로 구분할 수 있다. ASN Gateway를 위한 별도의 노드 모델은 제공하지 않으며, 일반적인 라우터 모델을 ASN Gateway로 사용한다.

OPNET은 2005년부터 WiMAX (IEEE802.16e) 모델을 개발하여 제공하기 시작하였으며, 최근까지 지속적으로 업데이트해왔다(OPNET Modeler 16.0 PL4 발표). 초창기의 OPNET WiMAX 모델은 제공되지 않는 기능도 많았고, 실제 시스템의 특성을 제대로 반영하지 못하는 부분들이 많아서 실무에 사용하기에는 어려움이 많았다. 하지만, 그 동안의 지속적인 업데이트를 통해 이제는 쓸만한(?) WiMAX 모델을 제공하고 있다. 물론, 16e의 경우 현재는 장비 개발이 거의 끝나버려서 시기적으로 너무 늦어버린 느낌이 있지만 말이다.
"OPNET 중급입문"에서도 언급한 바 있듯이, WiBro는 기술적으로 802.16e Mobile WiMAX의 서브셋으로 볼 수 있으므로 OPNET WiMAX 모델의 파라메터를 조정하면 WiBro의 기능도 대부분 시뮬레이션이 가능하다. 여기에서는 OPNET WiMAX 모델의 구조와 특성을 살펴보고, IEEE802.16e 표준을 잘 반영하고 있는지 분석해보고자 한다. (상당히 긴 연재물이 될 것으로 예상된다.)
먼저, 현재의 OPNET 최신 버전(16.0 PL6)에서 제공하는 WiMAX 모델의 대표적인 기능은 다음과 같다.

MAC
 - IP convergence sub-layer (classifiers)
 - Per service flow state (queues)
 - ARQ
 - Bandwidth request and allocation
 - Framing
 - Ranging
 - Mobility, Scanning and Handover
 - Link Adaptation
 - Power Management
 - HARQ
 - MMR(802.16j)
PHY
 - TDD
 - OFDMA(DL-FUSC/PUSC, UL-PUSC), SOFDMA
 - Path loss
 - Co-channel interference
 - Multi-path fading
 - MIMO (STC)

OPNET 모델에서 TDD를 PHY 기능으로 분류해야 하는지는 애매한 측면이 있다. TDD를 가능하게 하는 주요 요소는 Frame 구성과 전송 timing 인데, OPNET 모델에서 이 기능들은 모두 MAC 프로세스 모델에서 구현되기 때문이다. 하지만, 일반적으로 TDD를 PHY 기능으로 볼 때가 많으며 OPNET사에서도 PHY 기능으로 분류하고 있기때문에
여기에서도 PHY 기능으로 분류하였다.
HARQ는 일반적으로 1.5계층 기능으로 분류되고, OPNET 모델에서도 MAC 프로세스 모델과 파이프라인 스테이지에 분산되어 구현되므로 정확히 어느 계층의 기능이라고 분류하기는 어렵다. 개인적으로는 OPNET 모델에서 HARQ 기능의 주요한 부분은 파이프라인 스테이지에서 더 많이 수행된다고 보지만, OPNET사에서는 MAC 기능으로 분류하고 있기 때문에 여기에서도 MAC 기능으로 분류하였다.
각 항목 기능들의 세세한 특징은 이후의 포스트에서 하나씩 살펴보기로 하겠다.