네트워크 시뮬레이션 공방

Handover는 MS의 이동에 따라 현재의 BS(serving BS)보다 더 신호강도가 좋은 BS가 발견되면 해당 BS (target BS)로 연결을 바꾸는 것이며, OPNET WiMAX 모델에서도 지원한다. 다음 그림은 OPNET WiMAX 모델에서의 (MS 요청에 의한) Handover 절차를 나타낸 것이다.

Scanning 과정에서 serving BS보다 더 신호강도가 좋은 target BS가 발견되면, serving BS로 MOB_MSHO-REQ 메시지를 보내서 Handover를 시작한다. Serving BS는 MOB_MSHO-REQ에 대한 응답으로 MOB_BSHO-RSP 메시지를 MS로 전송한다. (ASN-GW를 사용하는 경우라면 이 사이에 HO_Req 메시지를 target BS로 전송하고 HO_Rsp 메시지를 응답받는 과정이 필요하다. 이 경우에 대해서는 이후에 다시 다루도록 하겠다.) MS가 MOB_BSHO-RSP 메시지를 수신하면 MOB_HO-IND 메시지를 serving BS로 최종적으로 전송한 후, target BS에 대한 initial ranging 절차를 시작한다.
이러한 과정을 wimax_ss_control 프로세스 모델의 State diagram에서 추적해보면, 다음 그림과 같은 천이 과정을 따른다.

다음 그림은 표준[1]에서 정의하고 있는 관계(association)을 맺지 않는 Neighbor BS Scanning 절차중 MS 요청에 의한 경우인데([1]의 FIgure D.1, Figure D.3 참조), "WiMAX 모델(94) - Neighbor BS Scanning"에서 설명한 OPNET WiMAX 모델에 구현된 절차는 이와 일치한다. (BS 요청에 의한 Neighbor BS Scanning 절차도 표준과 동일하게 OPNET WiMAX 모델에서 지원된다)

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

SITL 게이트웨이를 포함하는 시나리오 수행시 다음 그림과 같이 bufferoverflowu.lib 파일을 찾을 수 없다는 에러가 발생하는 경우가 있다.

여기에서 에러의 원인에 대한 주요한 메시지는 다음과 같다.

----
Errors reported by the binder program follow
(these messages have been saved in (C:\Users\opnet\op_admin\tmp\bind_err_7972):
LINK : fatal error LNK1104: 'bufferoverflowu.lib' 파일을 열 수 없습니다.

이 에러는 bufferoverflowu.lib 라이브러리 파일을 무시하도록 Common Network Repositories Flags를 설정하면 해결된다.

OPNET Voice Application에서 사용하는 Jitter의 의미와 계산방법은 "Delay Variation과 Jitter의 차이"에서 살펴본 바 있다. 그러면 Jitter 값이 어느 정도의 범위를 가지는 지에 대해서 조금 더 살펴보도록 하자.
다음 그림은 ip32_cloud 노드 모델을 이용하여 normal(0.01, 0.005) 분포("분포 함수(1) - 정규분포" 참조)의 Packet Latency를 발생시켰을 때("네트워크 Jitter(1) - VoIP 실험을 위한 네트워크 Jitter 설정" 참조), G.711 코덱을 사용하는 단말의 Voice Application단에서 측정된 Jitter를 나타낸 것이다(Frame Size : 10msec, Voice Frames per Packet: 2).

이 실험의 경우, Jitter이 범위가 -20ms ~ 260ms 범위를 가지는 것을 볼 수 있다. normal(0.01, 0.005) 분포를 사용하였을 때 IP 패킷이 약 300ms 정도까지의 지연시간을 가지는 것을 고려하면("네트워크 지터(4) - Packet Latency 측정" 참조), 약 260ms까지의 Jitter를 가지는 것은 자연스럽다.
그런데, Jitter 값의 음수 범위는 왜 정확히 -20ms까지인 것일까? 이는 실험에서 사용된 VoIP 코덱의 프레임 크기 및 IP 패킷당 프레임수와 관련이 있다. 앞의 실험에서는 G.711 코덱을 사용하였으므로 2개의 10ms 프레임을 하나의 IP 패킷(정확히는 RTP 패킷)에 담아 전송하도록 하였다. 따라서, 송신측에서 IP 패킷간의 간격은 20ms이며, 패킷별 지연시간의 변동으로 인해서 수신측에 패킷이 동시에 도착할 경우 Jitter는 -20ms가 된다. Voice 패킷은 순서대로 재생되므로 Jiiter 값의 음수 범위는 -20ms까지로 제한 된다. 다음 그림은 지터가 음수값을 가지는 경우의 송/수신 시간 관계를 나타낸 것이다.

Scanning은 HO를 하기전에 주변 기지국(BS)들로부터의 수신신호 강도를 측정하는 것이며, OPNET WiMAX 모델에서도 사용된다. 다음 그림은 OPNET WiMAX 모델에서의 (MS 요청에 의한) Scanning 절차를 나타낸 것이다.

MS에 수신된 신호의 SNR이 기준값 이하로 떨어지면 MOB_SCN-REQ 메시지를 전송하여 Scaning 절차를 시작한다. (BS에 의해서 Scanning이 시작되는 경우라면 MOB_SCN-REQ 메시지는 생략된다) MOB_SCN-REQ 메시지를 수신한 BS는 MOB_SCN-RSP 메시지를 통해 언제부터 얼마 동안의 시간동안 Scanning을 수행할 것인지를 MS에게 알려준다.
MOB_SCN-RSP 메시지를 수신한 MS는 지정된 시간(offset_M 시간이후)부터 주변 BS들로부터 수신되는 신호의 SNR을 (DL-MAP이 수신될 때마다) 측정한다. 주변 BS들의 목록은 MOB_NBR-ADV 메시지("WiMAX 모델(91) - Neighbor Advertisement" 참조)를 통해 알려진 것을 사용한다.
이러한 과정을 wimax_ss_control 프로세스 모델("WiMAX 모델(9) - wimax_ss_control 프로세스 모델" 참조)의 State diagram에서 추적해보면, 다음 그림과 같은 천이 과정을 따른다.

다음 그림은 표준[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