네트워크 시뮬레이션 공방

다음 그림은 표준[1]과 OPNET WiMAX 모델 MOB_NBR-ADV 메시지 구조를 비교하여 나타낸 것이다([1]의 Table 144 참조). MOB_NBR-ADV 메시지 필드중에서 OPNET WiMAX 모델의 wimax_mgmt_mob_nbr_adv 패킷 포맷에 실제로 표현되는 부분은 녹색으로 표시된 부분들이며, OPNET WiMAX 모델에서는 MAC PDU에 해당하는 부분(MAC Header, CRC)도 wimax_mgmt_mob_nbr_adv 패킷 포맷에 포함되어 있다.

OPNET WiMAX 모델에서 Neighbor 한개당 정보양은 DCD_settings 54비트와 UCD_settings 96비트를 포함하여 272비트로 정의되는데, 이는 표준[1]에 정의된 MOB_NBR-ADV 메시지 필드들중 몇가지 옵션 필드들을 포함한 크기로 생각된다.
Neighbor에 대한 정보 필드 구성은 표준과는 완전히 다르며, 해당 BS 정보 구조체에 대한 포인터만 가지고 있다. 시뮬레이션에서는 이 포인터를 통해 대상 BS의 모든 정보를 읽어올 수 있으므로 동작상에는 아무런 문제가 없다.

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

OPNET 2-D Animation Viewer 기능을 이용하여 패킷 전송 애니메이션을 관찰하는 방법에 대해서는 "패킷 전송 애니메이션 보기"에서 살펴보았다. 그런데, 이 방법은 유선망에서만 사용할 수 있으며, 무선망에서는 아무런 결과도 관찰되지 않는다.
그러면, WiFi와 같은 무선망에서는 패킷 전송 애니메이션을 볼 수 없는 것일까? 이러한 요구는 OPNET Debugger의 Show Animation 기능을 이용하여 어느 정도 만족시킬 수 있다.
다음 그림은 WiFi 단말간의 패킷 전송 애니메이션을 보기위한 예제망 구조를 나타낸 것이다.

가장 간단한 패킷 전달 애니메이션을 보기 위해서, "패킷 전송 애니메이션 보기"에서와 마찬가지로 트래픽은 Source 노드에서 Dest 노드로 전달하는 단방향 UDP 트래픽을 Custom Traffic으로 설정하였다.
OPNET Debugger의 Show Animation 기능을 이용하여 이 시나리오에 대한 패킷 전달 애니메이션을 살펴보면 다음 영상과 같다.

Source 노드에서 가까이에 위치한 Dest 노드로는 패킷(애니메이션에서 표시되는 패킷은 WLAN 프레임이다)이 전달되지만, 먼 거리에 위치한 Dest_2 노드로는 패킷이 전달되지 않는 것을 다음 그림처럼 쉽게 확인할 수 있다.

Debugger 모드에서 관찰한 애니메이션 결과는 2D Animation Viewer 때와는 달리 별도의 파일로 저장되지 않으므로 애니메이션을 보기위해서는 항상 시뮬레이션을 새로 수행시켜야만 한다.

시뮬레이션을 수행하다보면, 언제 어디서 어디로 패킷이 전송되는지를 애니메이션으로 확인해보고 싶을 때가 있다. (애니메이션이 꼭 데모 관점에서만 필요한 것은 아니다. 디버깅 관점에서도 애니메이션 결과를 보는 것이 편리할 때가 있다.) 이럴 때 선택할 수 있는 가장 간단한 방법은 OPNET에서 제공하는 2D Animation 기능을 이용하는 것이다.
다음 그림은 Ethernet 단말간의 패킷 전송 애니메이션을 보기위한 예제망 구조를 나타낸 것이다.

가장 간단한 패킷 전달 애니메이션을 보기 위해서, 트래픽은 Source 노드에서 Dest 노드로 전달하는 단방향 UDP 트래픽(즉, Dest 노드에서 Source 노드로는 어떠한 패킷도 전달되지 않는다)을 Custom Traffic으로 설정하였다.
OPNET의 2-D Animation Viewer 기능을 이용하여 이 시나리오에 대한 패킷 전달 애니메이션을 살펴보면 다음 영상과 같다.

Source 노드에서 Dest 노드로 패킷(애니메이션에서 표시되는 패킷은 Ethernet 프레임이다)이 순차적으로 전달되고 있는 것을 다음 그림처럼 쉽게 확인할 수 있다.

MOB_NBR-ADV 메시지는 주변 BS들에 대한 정보를 MS에게 알려주어 Handover를 지원하기 위한 것으로 OPNET WiMAX 모델에서도 사용된다. 다음 그림은 OPNET WiMAX 모델에서의 MOB_NBR-ADV 메시지가 전송되는 절차를 나타낸 것이다.

시뮬레이션이 시작되면 각 BS는 주변의 BS들중에서 자신과 같은 이웃그룹에 속하는 BS들을 파악하여 Neighobr Advertisement를 위한 BS 목록 정보를 구성해둔다. (BS가 어떤 이웃그룹에 속할지의 여부는 각 BS에서 설정해줄 수 있으며, 하나의 BS가 여러 개의 이웃그룹에 속할 수도 있다) 만약 해당하는 BS들의 수가 많다면, 거리가 가까운 BS들을 우선적으로 선택하여 목록을 구성한다.

MOB_NBR-ADV 메시지는 BS로부터 주기적으로 브로드캐스팅되며 그 주기는 BS의 "Neighbor Advertisement Interval" 속성을 통해 변경 가능한데, 기본값은 10 프레임이다.
MOB_NBR-ADV 메시지 전송에는 "wimax_mgmt_mob_nbr_adv" 패킷이 사용되며, 사전에 구성되어 있던 Neighbor Advertisement를 위한 BS 목록 정보가 "Neighbor list 필드에 실려서 전달된다.

Ranging을 위한 CDMA 코드는 144비트의 길이를 가지도록 표준[1]에 정의되어 있으며, 이는 OPNET WiMAX 모델 "wimax_cdma" 패킷의 "CDMA Code" 필드 크기와 일치한다. 하지만, 표준[1]에서는 PRBS(Pseudo-random binary sequence) 발생기를 통해 생성된 144비트 길이의 바이너리 코드를 사용하도록 되어있는 반면, OPNET에서는 실제 코드를 발생시키지 않고 코드값을 구분하는 index만을 사용한다. (시뮬레이션에서는 이런 방법을 사용하여도 별다른 문제가 없다)
다음 그림은 표준[1]의 PRBS 발생기 구조와 발생되는 코드의 종류를 나타낸 것이다.

표준[1][2]에서 각 용도별 CDMA 코드의 수는 UCD에 의해서 단말로 알려지며, 각 용도별 CDMA 코드의 수는 0 ~ 255이다. ([1][2]의 Table 571 참조) OPNET에서는 기지국 attribute로 설정된 각 용도별 CDMA 코드의 수를 단말이 직접 읽어가며, 이러한 방식을 취한 것은 OPNET WiMAX 모델에는 UCD가 구현되어 있지 않기 때문으로 생각된다. OPNET에서의 각 용도별 CDMA 코드수의 범위는 0 ~ 256으로 표준과 1만큼 차이나는데, 코딩상의 버그라고 생각된다.

모든 CDMA 코드 갯수를 더한 총 갯수는 256개 이하여야 하며, OPNET에서도 WIMAXC_MAX_CDMA_NUMBER 값을 이용하여 이를 점검한다(단, CDMA 총 갯수가 256을 초과하더라도 경고 메시지만이 출력되고 시뮬레이션은 계속 진행된다).

[1] IEEE 802.16-2009, "Air Interface for Broadband Wireless Access Systems", 2009
[2] IEEE 802.16j-2009, "Air Interface for Broadband Wireless Access Systems Amendment 1: Multihop Relay Specification", 2009

지난 2월 12일자로 OPNET Modeler 17.5 PL6 버전이 발표되었습니다(이전 버전에 관한 내용은 "OPNET Modeler 17.5 PL5 발표" 참조). Release notes는 2013년 12월 20일자로 되어있기는 하지만, 2월말에 확인했을 때에도 공개되어 있지 않았으므로 Release 기준일은 2014년 2월12일이 맞을 듯하고 홈페이지에는 지난 주에 올라온 것으로 보입니다. 요즘 종종 그렇듯이 새 버전에 대한 공지는 없었습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 모델 및 Modeler에 대한 마이너 업데이트 내용이 대부분이며, 중요한 사항은 다음과 같습니다.

- LTE Model Enhancements
- WLAN Model Enhancements
- Cyber Effects Model

LTE 모델에서는 LTE PHY Profile의 TDD Channel Index 속성 기본값이 "Index:3 UL/DL 3:7"로 변경되었습니다. 이전 버전에서의 기본값은 "Index:2 UL/DL 1:4"이였습니다. 그리고, eNodeB의 PUCCH Configuration 속성이 재구성되었다고 합니다.
WLAN 모델에서는 몇 가지 변조 방식에 대한 BER 커브가 새로 추가되었습니다. 추가된 변조 방식은 BPSK 1/2, BPSK 3/4, QPSK 1/2, QPSK 3/4, 16-QAM 1/2, 16-QAM 3/4, 64-QAM 2/3, 64-QAM 3/4, 64-QAM 5/6 입니다. 사실 정확히 말하자면 BPSK, QPSK, 16-QAM, 64-QAM 변조 방식에서 코딩률(Coding Rate) 변화(1/2, 2/3, 3/4, 5/6)에 따른 BER 커브가 새로 추가된 것입니다. 기본의 WLAN 모델에서도 BPSK, QPSK, 16-QAM, 64-QAM 변조 방식에 대한 BER 커브는 제공되고 있었는데, 코딩률 별로는 구분되지 못했습니다. 이 제약사항이 해결된 것입니다.
Cyber Effects는 사이버 공격과 방어 효과에 대한 것입니다. 새로운 모델이 만들어진 것은 아니고 기존의 IP 모델이 Cyber Effects를 제공할 수 있도록 수정되었다고 합니다.
이외에도 여러가지 추가/변경된 사항들이 있지만, 현재 관심이 가는 내용이 아니라서 생략합니다.

"분포함수(1) - 정규분포"에서 살펴보았듯이, OPNET에서 제공하는 분포함수는 이론적 정의와 일치하는 결과를 제공한다. 그런데, ip32_cloud 노드 모델의 Pakcet Latency 속성을 이용하여 네트워크 지터를 발생("네트워크 Jitter(1) - VoIP 실험을 위한 네트워크 Jitter 설정" 참조)시키고 측정해보면 상당한 차이가 나는 경우가 있다. 다음 그림은 normal(0.01, 0.005) 분포를 적용하였을 때 분포함수에서 발생한 결과값과 ip32_cloud 노드 모델을 통해 측정된 Packet Latency 결과값을 비교하여 나타낸 것인데, 두 결과값이 상당한 차이를 보여준다.

이러한 차이가 발생하는 원인은 선행 패킷의 전송지연시간이 후속 패킷의 Latency에 영향을 미치는 패킷 통신망의 특성때문이다. 이를 확인해보기 위해서 선행 패킷의 전송지연이 후속 패킷의 Latency에 영향을 미치지 않도록 코드를 수정하고 실험해본 결과는 다음 그림과 같다.
분포함수에서 발생한 결과값과 Packet Latency 결과값이 잘 일치하는 것을 확인할 수 있다.

OFDMA 방식의 Ranging에서는 CDMA 코드 전송이 필요한데, OPNET WiAMX 모델에서는 CDMA 코드도 역시 패킷 형태로 전달된다. CDMA 코드 정보는 "CDMA Code" 필드에 실리는데, 실제 Binary 코드 값이 아닌 CDMA 코드에 대한 index 값이 사용된다. 각 목적별로 사용되는 CDMA 코드값의 범위는 각 기지국에서 WimaxT_CDMA_Range 구조체 타입의 codeset 배열에 의해서 관리된다. 이 코드값의 갯수는 기지국 attribute에서 설정할 수 있으며, 범위는 0 ~ 256 이다.
다음 그림은 CDMA 코드 전송에 사용되는 "wimax_cdma" 패킷 포맷과 여기에 실리는 CDMA 코드값의 범위를 나타낸 것이다.

표준[1]에서 정의하고 있는 Contention-based CDMA BR 절차는 "WiMAX 모델(85) - BR ranging"에서 설명한 OPNET WiMAX 모델 절차와 대부분 일치한다.

BR ranging에 사용되는 WIMAX_CID_CDMA_BWR는 wimax_support.h 파일에 -41로 선언되어 있으며, 이는 표준[1]에서는 찾아볼 수 없는 것이다. (표준에 따른 CDMA Allocation IE 할당시에는 CID가 필요하지 않다)
초창기 OPNET WiMAX 모델(Release 5까지)의 경우, Contention-based CDMA BR 절차가 생략되어 있어서 표준과는 크게 다르다는 문제가 있었다. 즉, BW 요청을 위한 CDMA 코드를 전송하는 과정없이, Contention 방식의 BW 요청 영역을 이용하여 바로 대역폭 요청 메시지를 전송했던 것이다. 다음 그림은 Release 5에서의 BR ranging 절차를 나타낸 것이다.

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

특정 소스와 목적지간에 백그라운드 트래픽을 ip_traffic_flow 디맨드 모델을 이용하여 간단히 모의하는 방법은 "Background Traffic의 영향(4) - Demand Model"에서 살펴보았다. 특정 소스와 목적지간에 백그라운드 트래픽을 모의하는 또 다른 방법은 Application Model을 사용하는 것이다.
Application Model은 일반적으로 Explicit Traffic을 발생시키기 위해 사용된다. 그런데, voice와 video conferencing 모델은 Traffic Mix 속성을 제공하고 있으며, 이 속성값을 조정하면 Background Traffic을 발생시키는데 사용할 수 있다(Traffic Mix 속성의 사용법은 "Background Traffic의 영향(5) - Traffic Mix"에서 설명한 것과 동일하다). 다음 그림은 Video Conferencing Application Model의  Traffic Mix 속성을 보인 것이다.

다음 그림은 "Background Traffic의 영향(4) - Demand Model"에서 사용한 네트워크 토폴로지에 Video Conferencing Application Model을 적용하고, Explicit Traffic을 사용하였을 때와 Background Traffic을 사용하였을 때 링크에서 측정된 트래픽 발생량을 나타낸 것이다. Background Traffic을 사용하였을 때도 Explicit Traffic과 동일한 크기의 트래픽이 발생한 것을 확인할 수 있다.

그런데, Application Model의 Traffic Mix 속성을 사용하여 백그라운드 트래픽을 발생시킬 때 한가지 주의해야 할 점은 Background 방식으로 발생된 트래픽의 경우 노드에서는 관측되지 않는 다는 것이다.

앞에서 살펴본 것처럼 링크에서는 Application Model의 Traffic Mix 속성을 사용하여 Background Traffic으로 발생된 트래픽도 잘 정상적으로 관측되지만, 노드에서는 Background Traffic 분량만큼을 제외한 트래픽(즉 Explicit Traffic 분량)만이 관측된다. 다음 그림은 Application Model의 Traffic Mix 속성값이 All Explicit, 50%, All Background 일 때, 노드의 MAC단에서 측정된 트래픽 부하를 나타낸 것이다.