네트워크 시뮬레이션 공방

"OPNET 기초다지기" 3.4절의 이동 Node 무선랜 예제를 수행할 때, 시뮬레이션 결과가 교재와 달리 Hidden Node Problem에 의한 성능 저하가 제대로 관찰되지 않는 경우가 있다.

이는 본 예제에서 Transport 프로토콜로 UDP를 사용해야 하는데, 해당하는 설정과정이 교재에 빠져있어서 Transport 프로토콜로 TCP가 사용되어서 발생하는 현상이다. TCP를 사용할 경우 ACK 패킷과 flow control 알고리즘의 영향때문에 MAC 계층의 변화를 제대로 관찰할 수 없으며, Hidden Node Problem에 의한 MAC 계층의 성능 저하를 교재처럼 쉽게 관찰하기 위해서는 Transport 프로토콜로 UDP를 사용해야 한다.
Transport 계층 프로토콜은 "Applications" 노드의 "Custom" 테이블 편집창에서 변경할 수 있으며, 3.3절의 예제에 그 방법이 설명되어 있다.
Transport 프로토콜을 UDP로 설정하고 시뮬레이션을 수행하면 다음 그림과 같이 Hidden Node Problem에 의한 성능 저하를 잘 관찰할 수 있다.

조만간 출판 예정인 개정판에는 이 오류가 수정되어 있다.

"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

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

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

"OPNET 기초다지기" 5.2절의 수신 패킷의 크기 측정 예제를 수행할 때, 컴파일 도중 다음 그림과 같이 p_pk_nfd_size 함수 선언에 관한 오류(warning)가 발생한다.

에러 메시지를 좀 더 자세히 살펴보면 다음과 같다.
C:/OPNET/17.1.A/models/std/wireless_lan/wlan_mac.pr.c(4940) : warning C4013: 'p_pk_nfd_size' undefined; assuming extern returning int

이 에러는 교재 편집과정에서 op_pk_nfd_size 함수에 오타가 발생했기 때문이며, FB에 추가된 코드의 함수명을 'op_pk_nfd_size'로 수정해주면 해결된다.
조만간 출판 예정인 개정판에는 이 오류가 수정되어 있다.

"OPNET 기초다지기" 5.1절의 무선랜(802.11b) 성능 개선 예제를 수행할 때, 컴파일 도중 다음 그림과 같이 hld_ptr 변수 선언에 관한 오류가 발생한다.

에러 메시지를 좀 더 자세히 살펴보면 다음과 같다.
wlan_mac.pr.tmp.c
C:/OPNET/17.1.A/models/std/wireless_lan/wlan_mac.pr.c(7503) : error C2065: 'lanT_Hld_List_Elem' : undeclared identifier.
C:/OPNET/17.1.A/models/std/wireless_lan/wlan_mac.pr.c(7503) : error C2065: 'hld_ptr' : undeclared identifier.
...

이 에러는 교재 편집 과정에서 hld_ptr 변수의 타입에 오타가 있기 때문이며, 다음 그림과 같이 TV에 선언해주는 hld_ptr 변수의 타입을 'WlanT_Hld_List_Elem'으로 수정해주면 해결된다.

조만간 출판 예정인 개정판에는 이 오류가 수정되어 있다.

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