네트워크 시뮬레이션 공방

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

"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.

OPNET 15.0 버전에서 MPLS 기능을 사용할 때, Traffic Mapping Configuration 설정을 위한 Interface Binding Specification 다이얼로그 박스가 다음 그림과 같이 비정상적으로 표시되는 문제가 있다. 또한, 14.5, 11.5, 10.5에도 동일한 현상이 발생하는 것으로 보인다.

원래 이 설정창은 다음 그림과 같이 모양으로 표시되어서 사용자가 원하는 인터페이스를 지정해줄 수 있어야 하는 것인데, 창 크기 조절이 막혀있어서 필요한 설정을 전혀 할 수 없는 상태로 나타난다는 점에서 심각한 문제이다. (그동안 OPNET의 MPLS 기능을 이용해서 시뮬레이션했던 논문들은 어떻게 작성된 것인지 좀 의아해지는 부분이다)

이 문제에 대한 OPNET사의 공식적인 답변은 버그가 수정되어 있는 16.0 이상의 버전을 사용하라는 것이다. 하지만, 16.0 이상의 버전을 사용할 수 없는 상황이라면 이 답변은 아무런 도움이 되지 않는다. 15.0 버전을 비롯한 예전 버전에 적용될 수 있는 한가지 비공식적인 해결책은 ODK로 해당 다이얼로그 박스 정보를 수정하여 사용하는 것이다.

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" 필드에 저장되어서 전달된다.

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 값이 설정된다.

OPNET 17.1 버전부터는 MS Visual C++ 6.0을 사용할 수 없게 되었네요. (17.1 버전 발표에 관한 내용은 "OPNET Modeler 17.1 PL1 발표" 참조) MSVC 6.0을 지금까지 계속 사용해왔었는데, 17.1에서 시뮬레이션이 정상적으로 실행되지 않아서 OPNET사에 문의해본 결과 지원되지 않는다고 합니다. 17.1에서 MSVC 6.0 사용시 다음과 같은 에러가 발생합니다.
=============================================================================
<<< Recoverable Error >>>
Object repository construction failed
due to errors encountered by the binder program (bind_so_msvc)

----
Errors reported by the binder program follow
(these messages have been saved in (C:\Documents and Settings\stc\op_admin\tmp\bind_err_7696):
Creating library C:\Program Files\OPNET\17.1.A\models\std\example_networks\WLAN.project\WLAN-WLAN_interference_test.dev32.i0.nt.lib and object C:\Program Files\OPNET\17.1.A\models\std\example_networks\WLAN.project\WLAN-WLAN_interference_test.dev32.i0.nt.exp

LINK : fatal error LNK1000: unknown error; consult documentation for technical support options


----
<<< Program Abort >>>
Error encountered rebuilding repository -- unable to proceed
T (0), EV (-), MOD (NONE), PROC (sim_load_repos_load)
=============================================================================

Visual C++ 6.0을 아직도 사용하고 있는 사용자가 많지는 않겠지만, 굳이 지원을 중단해야만 하는 이유가 있었을까 하는 아쉬움이 드네요. 사실 Visual C++ 6.0에 대한 지원중단 징후는 이미 16.1에서부터 있었습니다. Visual C++ 6.0이 지원 compiler 목록에서 빠져있기도 했거니와, LTE 모델에서는 컴파일 에러가 발생했었습니다.
하지만, LTE 이외의 모델에서는 시뮬레이션까지 정상적으로 수행되었기 때문에, LTE를 적용하지 않는 경우에 대해서는 계속 사용할 수 있었습니다. 그런데, 17.1에서는 기본 모델들에 대해서도 Visual C++ 6.0으로는 시뮬레이션이 되지 않습니다(LTE 이외의 모델들에 대한 컴파일은 됩니다).
이제는 Visual C++ 6.0을 버려야할 때가 되었나 봅니다.

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 메시지는 사용되지 않는다.

새로운 일을 벌이다. 다음은 방위사업연구학회에서 공고한 교육일정.

===============================================================================================
제 목: 통신망 M&S 도구(OPNET)기반 최신통신기술(WiMAX, LTE) 시뮬레이션 방법 교육 (표준과 OPNET 모듈의 이해 중심의 과정)

시 간: 2011년 12월 2일 10시 - 18시 ( 1일 과정 )

장 소: 씨엔에이 강의장 로즈메리 실 (서울시 강남구 신사동 609 이소니프라자 501호)

참석대상자: 40명내외 (국과연 연구원, ETRI, 대학원생, 일반기업체 연구원 외)

강사진: Tutorial 1: 삼성탈레스 통신연구소 신상헌 박사 (WiMAX 표준과  OPNET WiMAX 모델의 이해)
           Tutorial 2: 영진전문대 정영철교수 (LTE 표준과 OPNET LTE 모델의 이해)

주 최: (사단법인) 한국방위사업연구학회

어제(2011년10월22일, 한국시간) OPNET Modeler 17.1 PL1 버전이 발표되었습니다(이전 버전에 관한 내용은 "OPNET Modeler 16.1 PL1 발표" 참조). 먼저 User Forum에 올라온 안내는 다음과 같습니다.

- New Web 2.0 analytical reporting framework for simulation results
- Enhancements to define, deploy, and manage node trajectories
- LTE TDD operation and MIMO antenna diversity
- 802.11n 20/40 MHz operation with enhanced channel sensing
- IGMP Snooping for IPv4 multicast traffic
- Support for TCP settings from additional operating systems such as iOS, Android, Windows Server 2008, Windows Vista, Mac OS, and FreeBSD
- New search functionality spanning code base, model attributes, and simulation statistics
- Productivity enhancements to OPNET Debugger (ODB) and Process Editor, such as suspend/resume tracing, and better UI to include external files
- SITL Communication with real BGP peers
- HLA 1516e and support for HLA on 64-bit machines

새로운 프로토콜 모델의 추가보다는 기존 기능의 개선이 주된 사항으로 보입니다. Release note를 통해 조금 더 자세히 살펴보았습니다.
LTE는 역시 꾸준하게 업데이트되고 있네요. TDD 방식이 지원되게 되었는데, 개인적인 예상보다는 상당히 빠른 것 같습니다. 현재 상용망 구축중인 LTE 장비들이 대부분 FDD 방식이라서 TDD는 당분간 지원되지 않을 것으로 생각했는데, 제 예상이 틀렸네요. MIMO는 DL: 1x2, 2x1, 2x2, 4x1, 4x2, UL: 1x2, 1x4 경우에 대해서 지원된다고 합니다.
WLAN 모델은 802.11n 40MHz 채널을 지원하게 되었네요. (802.11n 20MHz 채널은 16.1에서부터 지원하던 것입니다. 공지 사항만 보면 마치 20MHz 채널도 17.1에서 지원하게 된것처럼 보이기도 합니다만...) 그리고, WLAN와 ZigBee의 Co-existence 시뮬레이션이 가능해졌다고 합니다. 이를 위해서는 두 모듈간에 서로의 패킷에 대한 인식이 가능하고, 중복되는 주파수에 의한 interference가 반영되어져야 하는데, 이제 지원되는 모양입니다.
TCP 모델에 있어서는 몇가지 OS별 기본 프로파일이 추가되었다는 점을 강조하고 있는데, 해당 OS는 Windows Server 2003, Windows Vista, Windows Server 2008, Linux 2.6, FreeBSD 8.2, Mac OS X, iPhone, iPad, Andriod입니다. 하지만, OS별로 TCP 기능이 다른 것은 아니니, OS별 TCP 파라미터 기본 설정값을 파악해서 반영한 것일 겁니다. 엔지니어 관점에서는 크게 의미있는 부분은 아닙니다만, 마케팅시에는 유용하겠네요. 엔지니어 관점에서는 오히려 Duplicate SACK이 지원된다는 점이 더 중요할 것 같습니다.
ODB 기능과 UI가 개선되었다는데, 설명만 봐서는 피부에 와닫지 않는군요. 직접 사용해봐야 제대로 알 수 있는 부분일 것 같습니다.
Wireless 모듈에서 이동경로(trajectory) 관리에 대한 기능이 많이 개선된 것 같습니다. OPNET에서 제공하는 기능이 상대적으로 부족하다고 생각하던 부분이었던지라 개선되었다고 하니 다행입니다만, 아직 다른 툴들과의 연동에서는 부족한 것 같습니다. STK의 궤적정보는 가져와서 사용할 수 있다고 합니다.
TIREM 모듈에 있어서는 Fog level, Temperature, Rain Rate, Rain Height를 추가적인 파라메터로 사용할 수 있게 되었다고합니다. 상당히 중요한 부분인 것 같은데, 설명이 부족해서 현재로서는 더 이상의 사항을 파악하기 힘드네요.
SITL 모듈에 있어서는 실제 BGP Packet Payload에 대한 처리가 가능해져서 실제 라우터와의 BGP 정보 교환이 가능해졌다고 하네요. 
HLA 모듈이 64비트 윈도우에서 사용가능하게 되었다는 점은 꽤 중요한 사항으로 생각됩니다. (64비트 윈도우에서의
OPNET 설치에 관해서는 "64비트 버전의 OPNET을 위한 VIsual Stuido 2008 환경변수 설정 및 주의사항" 참조) MAK RTI와 pRTI 모두 지원된다고 합니다.

이외에도 여러가지 추가/변경된 사항들이 있지만, 현재 관심이 가는 내용이 아니라서 생략합니다.

"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"