WiMAX 모델에서 사용하는 단말 노드 모델의 구조는 다음 그림과 같으며, WiMAX MAC 프로세스 모델과 파이프라인 스테이지를 사용한다는 것 외에는 일반적인 노드 모델의 구조와 동일하다. OPNET 사용자들이 이미 잘 알고 있듯이 OPNET에서는 일반적으로 별도의 PHY 프로세스 모델을 사용하지 않으며, PHY 기능의 대부분은 파이프라인 스테이지에서 구현된다. 하지만, 파이프라인 스테이지에서 구현하기에는 곤란한 일부 PHY 기능의 경우 MAC 프로세스 모델에서 구현되는데, 이는 WiMAX 모델의 경우에도 마찬가지이다. 아래 그림에서 MAC과 PHY 계층 기능을 구분하여 선을 그어 놓기는 했지만, 실제 구현 과정에서 일부 PHY 기능은 MAC 계층에 통합되어져 있다고 보아야 할 것이다.


섹터 구분이 없는 기지국의 경우 노드 모델의 기본적인 구조는 단말 노드와 다르지 않으며, 섹터 구분이 있는 기지국 모델의 경우 다음 그림과 같이 MAC과 ARP 사이에 추가적인 인터페이스 모델이 붙어 있다. 하지만, 이 인터페이스 모듈이 하는 일은 단순히 패킷을 해당하는 섹터를 담당하는 MAC으로 넘겨주는 역활만이며, 실질적인 MAC 계층 기능과는 관련이 없다. (팔레트의 wimax 노드 모델 그룹에서는 보이지 않지만 추가적인 인터페이스 모델없이 WiMAX MAC마다 별도의 ARP 모듈을 가지고 있는 노드 모델이 있는데, 이는 초창기에 사용되던 모델이다)


3섹터 기지국의 경우, 3개의 안테나가 각각의 섹터를 서비스하도록 설정되어져 있으며 이는 노드 모델 좌측의 Physical Layout에서 다음 그림과 같이 확인할 수 있다.


위 그림에서 보여지듯이, 각각의 안테나는 x축을 기준으로 60도, 180도, 300도 방향을 지향하고 있으므로 3 섹터가 담당하는 지역은 x축을 기준으로 각각 0~120도, 120~240도, 240~360도 방향의 지역이다. 각 섹터의 안테나는 약 160도를 커버하는 안테나 모델을 사용하고 있으므로 실제로 각 섹터는 이웃 섹터와 약 40도씩 중첩된다.
Posted by 신상헌
,

OPNET WiMAX 모델에서 제공하는 노드 모델의 종류는 다음과 같다(16.0 PL6 기준).
- wimax_3sector_bs_atm2_ethernet2_slip4_wlan_router
- wimax_3sector_bs_atm2_ethernet2_slip4_wlan_router_adv
- wimax_bs_atm8_ethernet8_fr8_slip8_router
- wimax_bs_ethernet4_slip4_router
- wimax_bs_ethernet4_slip4_router_adv
- wimax_bs_router_adv
- wimax_rs_station
- wimax_rs_station_adv
- wimax_ss_ethernet_slip_wlan_router
- wimax_ss_ethernet_slip_wlan_router_adv
- wimax_ss_server
- wimax_ss_server_adv
- wimax_ss_wkstn
- wimax_ss_wkstn_adv
- wimax_ss_wlan_router
- wimax_ss_wlan_router_adv

하지만, 노드의 역활에 따라 분류하면 기지국(BS)과 단말(SS), 그리고 중계국(RS)의 3가지 타입으로 구분할 수 있다. ASN Gateway를 위한 별도의 노드 모델은 제공하지 않으며, 일반적인 라우터 모델을 ASN Gateway로 사용한다.

Posted by 신상헌
,

OPNET은 2005년부터 WiMAX (IEEE802.16e) 모델을 개발하여 제공하기 시작하였으며, 최근까지 지속적으로 업데이트해왔다(OPNET Modeler 16.0 PL4 발표). 초창기의 OPNET WiMAX 모델은 제공되지 않는 기능도 많았고, 실제 시스템의 특성을 제대로 반영하지 못하는 부분들이 많아서 실무에 사용하기에는 어려움이 많았다. 하지만, 그 동안의 지속적인 업데이트를 통해 이제는 쓸만한(?) WiMAX 모델을 제공하고 있다. 물론, 16e의 경우 현재는 장비 개발이 거의 끝나버려서 시기적으로 너무 늦어버린 느낌이 있지만 말이다.
"OPNET 중급입문"에서도 언급한 바 있듯이, WiBro는 기술적으로 802.16e Mobile WiMAX의 서브셋으로 볼 수 있으므로 OPNET WiMAX 모델의 파라메터를 조정하면 WiBro의 기능도 대부분 시뮬레이션이 가능하다. 여기에서는 OPNET WiMAX 모델의 구조와 특성을 살펴보고, IEEE802.16e 표준을 잘 반영하고 있는지 분석해보고자 한다. (상당히 긴 연재물이 될 것으로 예상된다.)
먼저, 현재의 OPNET 최신 버전(16.0 PL6)에서 제공하는 WiMAX 모델의 대표적인 기능은 다음과 같다.

MAC
 - IP convergence sub-layer (classifiers)
 - Per service flow state (queues)
 - ARQ
 - Bandwidth request and allocation
 - Framing
 - Ranging
 - Mobility, Scanning and Handover
 - Link Adaptation
 - Power Management
 - HARQ
 - MMR(802.16j)
PHY
 - TDD
 - OFDMA(DL-FUSC/PUSC, UL-PUSC), SOFDMA
 - Path loss
 - Co-channel interference
 - Multi-path fading
 - MIMO (STC)

OPNET 모델에서 TDD를 PHY 기능으로 분류해야 하는지는 애매한 측면이 있다. TDD를 가능하게 하는 주요 요소는 Frame 구성과 전송 timing 인데, OPNET 모델에서 이 기능들은 모두 MAC 프로세스 모델에서 구현되기 때문이다. 하지만, 일반적으로 TDD를 PHY 기능으로 볼 때가 많으며 OPNET사에서도 PHY 기능으로 분류하고 있기때문에
여기에서도 PHY 기능으로 분류하였다.
HARQ는 일반적으로 1.5계층 기능으로 분류되고, OPNET 모델에서도 MAC 프로세스 모델과 파이프라인 스테이지에 분산되어 구현되므로 정확히 어느 계층의 기능이라고 분류하기는 어렵다. 개인적으로는 OPNET 모델에서 HARQ 기능의 주요한 부분은 파이프라인 스테이지에서 더 많이 수행된다고 보지만, OPNET사에서는 MAC 기능으로 분류하고 있기 때문에 여기에서도 MAC 기능으로 분류하였다.
각 항목 기능들의 세세한 특징은 이후의 포스트에서 하나씩 살펴보기로 하겠다.

Posted by 신상헌
,
Custom Application을 사용할 때, Task 설정 단계에서의 REQ/RESP와 결과확인창의 Requesting/Responding의 관계가 혼란스러울 때가 있다. 이들 간의 관계를 명확하게 파악하지 못하면, 정상적으로 수행된 시뮬레이션에 문제가 있다고 판단하거나 정상적으로 수행되지 못한 시뮬레이션에 문제가 없는 것으로 판단 할 수가 있기때문에 주의가 필요하다.
다음 그림과 같이 Client와 Server 노드로 이루어진 네트워크를 예로 들어 살펴보자.

Task Config를 이용하여 Custom Application을 설정하는데, 먼저 Source 노드에서 Destination 노드로 1,000Bytes 크기의 패킷을 1sec마다 전송하도록 하고, 이 패킷들에 대한 응답으로 500Bytes 크기의 패킷을 Destination 노드에서 Source 노드로 전송하도록 다음 그림과 같이 설정한다. (이를 1번 Custom Traffic으로 부르자) 만들어진 Custom Traffic Profile을 Client 노드에 적용해주고, Dest으로 Server 노드를 지정해 준다.

결과 수집항목 설정창에서 "Requesting Custom Application" 항목과 "Responding Custom Application" 항목을 모두 선택하고 시뮬레이션을 수행한 후 살펴보면, 다음 그림과 같이 Client 노드에는 "Requesting Custom Application" 항목 결과만이, 그리고 Server 노드에는 "Responding Custom Application" 항목 결과만이 수집되어 있는 것을 볼 수 있다.

Client 노드의 "Requesting Custom Application" 아래에 속한 "Traffic Sent(bytes/sec)" 항목과 "Traffic Received(bytes/sec)" 항목의 결과를 살펴보면 다음 그림과 같다. 즉, Task Config에서 Source로 지정되어 있는 노드에서는 "REQ/RESP Pattern"에 해당하는 트래픽이 모두 "Requesting Custom Application" 결과로 보여지는 것이다.

다음으로 Source 노드에서 Destination 노드로 1,000Bytes 크기의 패킷을 한번 전송하도록 하고(일종의 서비스 요청이라고 볼 수 있다), 이 패킷에 대한 응답으로 1,000Bytes 크기의 패킷을 1초마다 Destination 노드에서 Source 노드로 전송하도록 다음 그림과 같이 설정한다. (이를 2번 Custom Traffic으로 부르자)
만들어진 Custom Traffic Profile을 Client 노드에 적용해주고, Dest으로 Server 노드를 지정해 준다.

이제 다시 시뮬레이션을 수행한 후 살펴보면, 다음 그림과 같이 Client 노드와 Server 노드에 모두 "Requesting Custom Application" 항목 결과와 "Responding Custom Application" 항목 결과가 수집되어 있는 것을 볼 수 있다.

Client 노드의 "Requesting Custom Application" 아래에 속한 "Traffic Sent(bytes/sec)" 항목과 "Responding Custom Application" 아래에 속한 "Traffic Received(bytes/sec)" 항목의 결과를 살펴보면 다음 그림과 같다. 즉, Task COnfig에서 Source로 지정되어 있는 노드에서는 설정된 트래픽이 "Requesting Custom Application" 결과로 보여지며, Destination으로 지정되어 있는 노드에서는 설정된 트래픽이 "Responding Custom Application으로 보여진다.

결론적으로 요약하자면,
1) 해당 트래픽이 Task Config에서 REQ(Source->Dest Traffic)에 해당하는지 RESP(Dest->Source Traffic)에 해당하는지의 여부와 상관없이 Source로 지정되어 있는 노드에서는 설정된 트래픽이 모두 "Requesting Custom Application" 결과로 보여지며, Destination으로 지정되어 있는 노드에서는 "Respoding Custom Application"결과로 보여진다.
2) "Requesting Custom Application" 또는 "Responding Custom Application" 아래에서 "Traffic Sent(bytes/sec)"로 표현될지 "Traffic Received(bytes/sec)"로 표현될지의 여부는 REQ에 해당하는 설정인지 RESP에 해당하는 설정인지에 따라 결정된다.
Posted by 신상헌
,

32비트 버전 OPNET의 경우 2GBytes 이상의 메모리를 사용할 수 없기 때문에 대규모 망을 시뮬레이션할 때 문제가 발생할 수도 있다. 물론 이는 OPNET의 문제가 아니라 하나의 어플리케이션은 최대 2GBytes까지의 메모리만 (가상 메모리를 포함하더라도) 사용할 수 있도록 허용하는 32비트 윈도우의 문제이다.
따라서, 2GBytes 이상의 메모리가 요구되는 대규모망을 시뮬레이션할 때에는 64비트 OS상에서 64비트 버전의 OPNET을 사용해야 한다.
64비트 윈도우에서 Visual Studio 2008을 컴파일러로 사용하기 위한 환경 변수 설정은 다음과 같다.

Framework35Version=v3.5

FrameworkDir=C:\WINDOWS\Microsoft.NET\Framework64

FrameworkVersion=v2.0.50727

INCLUDE=
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ATLMFC\INCLUDE;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include;

LIB=
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB\amd64;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\LIB\amd64;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\lib\x64;

LIBPATH=
C:\WINDOWS\Microsoft.NET\Framework64\v3.5;
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB\amd64;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\LIB\amd64;

Path=
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64;
C:\WINDOWS\Microsoft.NET\Framework64\v3.5;
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\VCPackages;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE;
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\x64;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin

VCINSTALLDIR=
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC

VS90COMNTOOLS=
C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\

VSINSTALLDIR=
C:\Program Files (x86)\Microsoft Visual Studio 9.0

WindowsSdkDir=
C:\Program Files\Microsoft SDKs\Windows\v6.0A\


그런데, 64비트 컴파일러를 설치하기 위해서는 다음 그림과 같이 Visual Studio 2008 설치 과정에서 x64 옵션을 선택해주어야만 한다. 그렇지 않으면, 64비트 윈도우 환경이라 할지라도 64비트 컴파일러가 설치되지 않아서 64비트로 컴파일이 이루어지지 않는 문제가 발생한다. (이 문제의 원인을 찾아내느라 고생하신 엠에이의 박성우씨에게 감사드립니다)

Posted by 신상헌
,

OPNET WLAN 모델에서 DSSS(Direct sequence spread spectrum) 방식을 사용할 경우 WLAN 프레임의 크기가 우리의 예상보다 훨씬 큰 크기를 가지는 것처럼 보이는 현상이 있으며, 이는 OPNET WLAN 모델을 정확하게 이해하지 못한 사용자들을 종종 혼란에 빠트리곤 한다. 현상을 살펴보기 위해서 다음 그림과 같이 wlan_wkstn 노드 모델과 wlan_server 노드 모델을 이용하여 2개의 노드로 이루어진 시험망을 구성하고, STA1 노드에서 STA2 노드로
전송되는 트래픽을 Custom Application으로 설정해준다. 시뮬레이션 결과의 분석을 간편하게 하기위해서 1,000bytes 크기의 패킷을 1초 간격으로 생성시키며, Transport Protocol로는 UDP를 사용하도록 한다.


wlan_wkstn 노드 모델의 기본 설정값은 802.11b에 해당하는 DSSS, 11Mbps이므로 별도의 설정없이 그대로 사용하여도 된다. 시뮬레이션을 수행하고, STA1 노드 MAC에서의 Load(bits/sec)와 Data Traffic Sent(bits/sec) 항목의 결과를 살펴보면 다음 그림과 같이 상당한 차이가 나는 것을 볼 수 있다. 즉, Load는 8,224bps인데 비해, Data Traffic Sent는 10,560bps나 된다. 우리는 1초마다 1개의 패킷이 발생되도록 설정하였으므로, MAC으로 내려오는 패킷(즉, IP 패킷)의 크기를 8,224bits, WLAN에서 전송된 패킷(즉, PLCP 오버헤드를 포함하는 PHY 프레임)의 크기를 10,560bits로 보아도 무방하며, 그 차이는 2,336bits(292bytes)나 된다.

이렇게 큰 차이가 나는 원인은 무엇이며, 그것은 타당한 것일까? 이를 분석하기 위해서, 일반적으로 예상되는 IP 패킷의 크기와 PHY 프레임의 크기를 살펴보도록 하자. 먼저 예상되는 IP 패킷의 크기를 계산해보면 20bytes(IP Header) + 8bytes(UDP Header) + 1,000bytes(Application Traffic) = 1,028bytes(8,224bits)이며 이는 시뮬레이션 결과와 일치한다.
다음으로, 예상되는 PHY 프레임의 크기를 계산해보면 24bytes(PLCP overhead) + 28bytes(MAC overhead) + 1,028bytes(IP 패킷) = 1,080bytes(8,640bits)이며, 이는 시뮬레이션 결과와 일치하지 않는다. 이렇게 시뮬레이션 결과가 예상치와 차이가 나는 이유는 OPNET이 802.11 WLAN을 모델링하는 과정에서 사용한 접근방법을 고려하지 않고 계산하였기 떄문이다. DSSS 방식의 WLAN에서 PLCP 오버헤드(preamble + header)는 24bytes(192bits)가 맞다. 하지만, 이 오버헤드는 PLCP SDU(즉 MAC 프레임)의 전송 속도와는 상관없이 항상 1Mbps의 속도로 전송된다. 따라서, PLCP 오버헤드의 transmission delay는 192bits/1Mbps = 192us이다.

그런데, WLAN의 wlan_txdel 파이프라인 스테이지를 살펴보면 패킷의 transmission delay를 계산할 때 이러한 PLCP 오허베드 부분의 전송율은 고려하지 않고 다음 그림과 같이 단순히 전체 패킷 크기를 데이터 전송율로 나눠주는 방법을 사용하는 것을 알 수 있다.

따라서, 이러한 차이를 보정해주지 않으면 WLAN 패킷의 transmission delay에 오류가 발생하게 되므로, 보정을 위해서 WLAN 패킷 전송시 PLCP 오버헤드 시간만큼 패킷 크기를 증가시켜서 전송해주는 방법을 사용하고 있으며, 다음 그림은 wlan_mac 프로세서 모델의 wlan_prepare_frame_to_send() 함수에 사용된 PLCP 오버헤드 설정 부분의 한가지 예를 나타낸 것이다.

WLANC_DEFAULT_PLCP_OVERHEAD는 최소 크기의 PLCP 오버헤드를 정의한 것으로 57bits 이다. 이 크기는 다음 그림과 같이 wlan_mac 패킷에 기본으로 이미 포함되어 있으므로 PLCP 오버헤드를 제외한 MAC 프레임의 크기를 구하기 위해서는 wlan_mac 패킷의 크기에서 WLANC_DEFAULT_PLCP_OVERHEAD 크기만큼을 빼주어야 한다.
(사실, 이 계산은 11b에서는 불필요한 것이다)

PLCP_OVERHEAD_DATA() 함수는 데이터 프레임의 PLCP 오버헤드를 계산하기 위한 매크로 함수로 다음 그림과 같이 정의되어 있다. 현재 우리는 DSSS 방식의 802.11b를 시험하고 있으므로, plcp_overhead_data에 저장된 값이 PLCP 오버헤드로 사용된다.

DSSS 방식일 때의 plcp_overhead_data 값은 다음 그림과 같이 지정되며, WLANC_PLCP_OVERHEAD_DSSS_LONG은 192E-06으로 정의되어 있다.

따라서 total_plcp_overhead의 값은 192us가 되며, 이를 11Mbps의 동작속도에 해당하는 데이터크기로 환산하면 192us * 11Mbps = 2,112bits이다. PLCP 오버헤드의 전체 크기가 11Mbps * 192us = 2,112bits(264bytes)인 것처럼 보이는 것은 이 때문이다.

그런데, 앞에서 언급한 바와 같이 wlan_mac 패킷에는 이미
WLANC_DEFAULT_PLCP_OVERHEAD 크기만큼의 PLCP 오버헤드가 포함되어 있으므로, PLCP 오버헤드 시간만큼의 증가분을 정확히 구하기 위해서는 total_plcp_overhead * operational_speed 결과에서
WLNAC_DEFAULT_PLCP_OVERHEAD를 빼주어야만 한다. 따라서 bulk_size = 2,112bits - 57bits = 2,055bits가
되며, 이 크기만큼 wlan_mac 패킷의 크기를 증가시켜서 전송하면 transmission delay 계산상의 문제가 없어지게 된다. op_pk_bulk_set() 함수는 패킷의 크기를 원하는 크기만큼 임의로 증감시킬때 사용하는 함수이다.

이제 physical layer에서 전송되는 패킷의 전체 크기를 다시 계산해보면, 264bytes(PLCP 오버헤드) + 28bytes(MAC 오버헤드) + 1,028bytes(IP 패킷) = 1,320bytes(10,560bits)가 된다. 이는 시뮬레이션 결과와 일치한다. 요약하자면, 실제로 전송된 트래픽량은 1,080bytes이지만, 전송에 사용된 시간은 11Mbps를 기준으로 생각하였을 때, 1,320bytes를 전송할 수 있는 시간이 사용되었다고 볼 수 있을 것이다.

Posted by 신상헌
,
WiFi 인터페이스를 사용하는 노드들간의 기본적인 통신 가능거리에 대해서는 지난 글에서 살펴본 바 있다. (WiFi 노드들간의 통신거리)
하지만, 이미 설명했던 것처럼 통신 가능 거리는 매우 많은 요소들에 의해서 영향을 받는다. 여기에서는 이러한 요소들중 Data rate를 1Mbps로 변화시켰을 때 통신 가능거리에 어떠한 영향을 미치는 지에 대해서 좀 더 살펴보도록 하겠다. (실장비에서 Data rate를 낮추는 것은 H/W의 변경없이 S/W적으로 가능한 부분이며, OPNET에서 제공하는 MANET 예제들중 일부는 1Mbps의 Data rate를 적용하고 있다.)
송신 노드에서 신호를 내보내면, 이 신호는 Free Space에서의 기본 전파 손실을 겪고 수신 노드에 도착한다. 수신된 신호의 크기와 노이즈 신호의 크기를 비교하여 SNR이 계산되고, 이 SNR 값을 이용하여 해당하는 BER 커브로부터 BER이 구해진다. 그런데, wlan_ber 스테이지를 보면, BER 커브로부터 BER을 구하기전에 실제 SNR 값에 processing gain(확산 이득)을 더하여 effective SNR을 만드는 것을 알 수 있다.

Processing gain은 데이터 신호의 대역이 확산코드에 의해서 얼마나 넓게 확산되었는지를 나타내는 것으로 다음과 같이 계산된다. 여기에서 WLANC_11b_CHIP_RATE의 값은 11Mcps이다.

따라서, Data rate가 1Mbps일 때의 processing gain은 10.414dB이며, 이 processing gain이 더해진 SNR로부터 BER이 구해지므로 processing gain이 없을 때 보다 (즉, Data rate이 11Mbps일 때) 보다) 훨씬 낮은 BER을 가지게 된다. 이론적으로 실제 수신 신호의 SNR이 -3.164dBm만 되어도 effective SNR은 7.25dBm을 만족시킬 수 있는 것이다.
수신 노드에서 -3.164dBm의 SNR을 가지기 위한 수신 신호의 강도가 4.24606*10^-14 watt임을 다음과 같이 계산할 수 있다. (백그라운드 노이즈 값은 8.7980419999*10^-14 watt를 적용)

수신 신호가 4.24606*10^-14 (watt)가 되는 거리는 다음과 같이 계산할 수 있다. (WiFi 모델에서 중심 주파수는 2,401MHz + 22MHz/2 = 2,412MHz가 기본값으로 설정되어 있으므로, lambda = C / 2,412MHz = 0.124378109452736M이다)

즉, 3.4Km정도까지 10^-4의 BER을 만족시킨다고 생각할 수 있다. 하지만, 실제로 시뮬레이션을 수행해보면 이 정도 거리에서 통신이 전혀 이루어지지 않는 것을 볼 수 있는데, 이는 우리가 통신 가능 거리에 영향을 미치는 또다른 요소인 "Packet Reception-Power Threshold (dBm)"을 고려하지 않았기 때문이다.
wlan_power 스테이지를 살펴보면 다음과 같이 수신 신호의 파워가 기준치 이상인지를 검사하는 코드가 있다.

이때 사용되는 rx_power_thresh 값은 수신 노드의 "Packet Reception-Power Threshold (dBm)" 속성 값을 watt로 변환한 것이다. 해당 속성의 기본 값은 -95dBm이며, watt로 변환하면 (10^(-95/10))/1000 = 3.16288x10^-13 이다.
그러므로, 송신 노드에서 5mW의 출력으로 내보낸 신호가 3.16228x10^-13 watt(-95dBm)이 되는 거리 이상에서는 통신이 전혀 이루어지지 않는 것으로 처리된다. 이 거리는 다음과 같이 계산할 수 있다.

따라서, 1245M부터는 수신 신호의 강도가 Packet Reception-Power Threshold에 미달하여 통신이 이루어지지 않는 것이다. Data rate를 11Mbps에서 1Mbps로 낮춘 것에 비해서는 통신 가능 거리가 그리 크게 늘어나지 않았다고 하겠다. 특이한 점은 이 거리까지는 (processing gain 덕분에) 비트 에러가 거의 발생하지 않고 잘 통신이 되다가, 1,245M부터는 전혀 통신이 되지 않는다는 것이다. 이렇게 갑자기 통신이 전혀 되지 않는 뚜렷한 경계점이 나타나는 이유는, 수신된 무선 신호에 대한 처리여부가 Modulation 커브에서 구해진 비트에러의 발생에 의해서가 아니라 "Packet Reception-Power Threshold (dBm)"에 의해서 걸러지기 때문이다.
Posted by 신상헌
,

두 번째 OPNET 한글 교재를 드디어 정식으로 출판하였습니다. 제목은 "OPNET 중급입문"이고, 기본적인 OPNET 사용법을 알고 있는 분들을 위한 예제 실습 위주의 책입니다.
ISBN은 978-89-7283-903-3 이고, 오늘부터 교보문고에서 검색이 되네요.
http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788972839033&orderClick=LAG


첫 번째 OPNET 한글 교재인 "OPNET 기초다지기"가 2008년 1월에 나왔으니 거의 3년이 지났네요. 처음 계획은 2009년 상반기에 두 번째 교재를 내놓을 생각이었습니다만, 바쁜 직장생활과 공동작업 조율의 어려움, 그리고 편집 방향의 수정등으로 인하여 계획에서 1년이나 훌쩍 뒤쳐진 지금에서야 출판하게 되었습니다.

두 번째 교재 작업을 시작할때의 기획 의도는 중급자를 위한 OPNET 활용서를 만드는 것이었습니다. 그런데, 초보자도 쉽게 따라할 수 있는 실습예제 중심의 교재가 필요하는 의견이 여러차례 있어서 책 내용을 수정하다보니, 시간도 많이 걸렸거니와 중급자를 위한 활용서라기보다는 중급자가 되기위한 연습문제서가 되어 버렸습니다. 따라서, 어떤 측면에서는 지난번 "OPNET 기초다지기"보다도 학습하기에 더 쉬운 부분도 많으며, 교재의 제목이 "OPNET 중급입문"이라는 다소 어정쩡한 이름으로 결정된 것도 이 때문입니다. 그렇지만, 처음의 기획의도가 변경된 것에 대해서는 후회하지 않으며, 사용자들이 실제로 필요로 하는 부분을 반영하여 출판할 수 있었다는 것은 무척 다행스러운 일이라고 생각합니다.

OPNET 고급사용자를 위한 세번째 교재는 "OPNET 기초다지기"의 개정작업때문에 잠시 미루어질 것 같습니다. "OPNET 기초다지기"가 출판된지 거의 3년이 지나서 GUI나 사용법이 달라진 부분들이 있는데다가, 보완이 필요한 부분들이 여러 곳 발견되었기 때문입니다.

이 책이 국내의 OPNET 사용자들에게 많은 도움이 되기를 바랍니다.

                                                                                                               - 신상헌

Posted by 신상헌
,

지난 11월4일에 OPNET Modeler의 세번째 16.0 버전인 PL6가 발표되었습니다. (이전 버전에 관한 내용은 "OPNET Modeler 16.0 PL4 발표" 참조) 마이너 업그레이드인데도 불구하고 LTE 모델은 상당한 변화가 있는 모양입니다. 역시나, 최근의 주된 업데이트 대상은 LTE가 맞는 것 같습니다. 먼저 User Forum에 올라온 안내는 다음과 같습니다.

- LTE Specialized Model update, including the following significant features:
    Channel Quality Indicator (CQI) and rate adaptation
    Channel dependent scheduling
    Initial cell selection
    Energy consumption model
    Single-cell downlink broadcast
- TCP model extensions to support segmentation and re-assembly of real application packets
- Wireless Network Deployment Wizard enhancements to support LTE and TDMA network creation

각 변경사항을 Release notes를 통해 좀더 살펴보겠습니다.

CQI report가 지원됨에 따라 해당 링크의 BLER을 일정 수준으로 계속 유지시켜줄수 있는 link rate adaptation 기능이 제공된다고 합니다. 즉, UE가 보고해주는 채널 상태(CQI report)에 따라, 적용되는 MCS를 변경하는 것입니다. 이런 기능을 AMC라고 표현하는 경우가 많은 것 같은데, 굳이 link rate adaptation으로 표현한 이유가 궁금하네요. (LTE의 고집인가요?)

Channel dependent scheduling은 무선 채널의 현재 상태를 스케줄링시에 고려요소로 사용하는 것을 의미합니다. 일종의 Cross-layer scheduling이라고 불 수 있겠네요. 다만, release notes의 설명에 의하면 채널의 상태에 따라 리소스 할당량을 조절하는 기능은 고려되어 있지 않고, 각 단말이 사용하는 subband를 조절해주는 기능만이 반영되어 있는 것으로 보여집니다. WiMAX에서의 Band AMC와 유사한 기능이라고 볼 수 있을 것 같습니다. (Band AMC가 다른 통신 방식에서도 일반적으로 사용되는 명칭인지는 모르겠습니다)

Initial cell selection은 조금 의아합니다. UE가 eNodeB와 연결되기 위해서 수행되는 cell search, synchronization, measurement, selection 절차를 말하는 것 같은데, 이 기능이 이번에 추가된 거라면 기존에는 이 기능없이 어떻게 동작했었다는 것인지 좀 당황스럽네요.

Energy consumption model은 UE와 eNodeB가 소비한 전력을 측정해서 배터리의 수명을 예측해주는 기능을 말합니다. 전력 소모량을 측정하는 기능의 경우, 사용자들이 필요에 따라 구현해서 사용하는 경우는 봤어도 이렇게 정식 모듈에 구현되는 것은 보지 못했던 것 같아서 상당히 새롭게 느껴집니다.

Downlink broadcast and multicast는 말 그대로 multicast 혹은 broadcast 패킷이 EPC 노드에 도착했을 때, 모든 eNodeB 및 UE로 전달되는 기능을 말합니다. 물론 multicast 패킷의 경우 해당 multicast group에 속하지 않은 노드에서는 폐기됩니다.

TCP 모델의 확장은 OPNET이 TCP를 사용하는 실제 어플리케이션과 통신할 수 있도록 해주기위한 것입니다.
OPNET TCP 모델에 사용된 oms_sar 패키지에서 TCP 패킷 페이로드에 이미지나 텍스트와 같은 실제 데이터를 싣거나 다룰 수 있게 되었으며, SITL과 HLA를 사용하는 경우에 이러한 기능이 활용될 수 있다고 합니다. SITL에서 일반적으로 많이 쓰이는 Real-Sim-Real 형태의 구성에서는 OPNET의 TCP 모델과 실제 TCP 구현물이 통신할 일이 거의 없으므로, 새로운 기능은 주로 Real-Sim 형태의 구성을 위한 것으로 보입니다. (Real-Sim-Real 형태의 구성이 주로 사용됐던 것도, Real-Sim 형태의 구성이 실질적으로는 매우 어렵다는 이유가 큰 부분이었으므로 앞으로는 Sim-Real 형태에 대한 SITL 사용이 증가할 것 같습니다)
HLA의 경우, TCP 레벨에서 직접 HLA를 통해 외부 시뮬레이터와 연동시켜야하는 경우가 있을지 약간 의문이긴 합니다. 하지만 기술적으로는 충분히 적용 가능하리라고 생각됩니다.

Wireless Network Deploment Wizard를 사용하시는 분들이 많으신지 모르겠습니다만(사용되니까 계속 지원하고 있는 것이겠죠?), LTE와 TDMA도 이제 지원된다고 합니다. TDMA는 14.5 PL8 버전에서부터, LTE는 16.0 PL1 버전에서부터 정식으로 포함되었으므로, 가장 최근에 지원된 프로토콜들이라는 공통점이 있습니다.

이외에도 몇 가지 수정된 사항들이 있지만, 특별히 관심가는 내용이 아니라서 생략합니다.

'Riverbed Modeler(OPNET) > Release notes' 카테고리의 다른 글

OPNET Modeler 17.1 PL2 발표  (0) 2012.08.01
OPNET Modeler 17.1 PL1 발표  (0) 2011.10.23
OPNET Modeler 16.1 PL1 발표  (0) 2011.06.07
OPNET Modeler 16.0 PL4 발표  (0) 2010.08.17
OPNET Modeler 16.0.A PL1 발표  (0) 2010.01.03
Posted by 신상헌
,
지난 10월16일에 발표된 OPNET사의 공지에 의하면 앞으로는 Windows 2000을 지원하지 않을 예정이라고 한다. 따라서, 현재의 16.0 버전이 Windows 2000에서 사용할 수 있는 마지막 OPNET 버전이 될 것으로 보인다. (Modeler 및 IT Guru 모두 해당)
혹시라도 아직까지 Windows 2000을 사용하고 있던 사용자라면, 이제 OS를 업그레이드 할 시기가 된 것 같다.
Posted by 신상헌
,