네트워크 시뮬레이션 공방

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 모델의 이해)

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

WiMAX 장비들간의 상호 호환을 위한 기본 profile 설정이나, IOT 시험, 네트워크 구조, 응용 서비스등에 관한 표준은 WiMAX Forum에서 정의하고 있으며, 다음의 사이트에서 무료로 다운로드 받을 수 있다.
http://www.wimaxforum.org/

Draft 단계의 문서들이나 논의중인 내용들은 WiMAX forum의 멤버가 되어야만 볼 수 있다.

어제(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"

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 매크로의 값이 거짓인 경우에 대해서 분석한 것이다.

IEEE 802 표준문서들중 상당 부분은 다음의 사이트에서 무료로 다운로드 받을 수 있다. (공인된지 6개월이 지난 문서들이다)
http://standards.ieee.org/about/get/

이곳에 없는 표준문서나 Draft 단계의 문서들은 유료로 구입하거나 해당 그룹의 멤버가 되어야만 볼 수 있다.