WiFi 모델에서의 통신 가능 거리

Riverbed Modeler(OPNET)/WLAN Model 2010. 10. 17. 11:14

OPNET에서 WiFi 인터페이스를 사용하는 노드들간의 통신 가능거리는 얼마인지에 대한 질문을 받은 적이 여러번 있다. 이 질문에 대한 정확한 답을 주는 것은 대단히 어려운데, 왜냐하면 통신 가능 거리는 매우 많은 요소들(ex: 주파수, 송신출력, 송/수신 안테나 이득, 지형 모델, path-loss 모델, interference, 변조방식, BER 커브...)에 의해서 영향을 받고 변화하기 때문이다. 즉, 사용자가 설정해주는 조건에 따라 그때그때 달라지는 것이다.
여기에서는 (아마도 대학교 연구실에서 많이 사용하리라고 생각되는) OPNET WLAN 노드 모델의 기본 설정을 그대로 사용하고, 지형모델(TMM)을 적용하지 않았으며, 아무런 interference 신호도 존재하지 않을 경우로 한정지어서 WiFi 인터페이스를 사용하는 노드들간의 통신 가능 거리가 얼마인지 살펴보도록 하겠다.

통신가능 거리는 BER을 기준으로 생각해볼 수 있는데, 원하는 서비스를 제공하기 위해서 요구되는 BER을 만족시킬 수 있는 최대거리라고 할 수 있다. 서비스 종류 및 사용되는 에러 복구 기법들에 따라 요구되는 BER은 달라지겠지만, 여기에서는 10^-4을 허용 BER 기준으로 보고 통신 가능 거리를 구해보도록 하자. OPNET WiFi 모델에서 "Data Rate (bps)"의 기본값은 11Mbps이며, 이 때 사용되는 모듈레이션 방식은 CCK(Complete code keying)이다. 다음은 OPNET에서 사용하는 11Mbps CCK 방식에서의 BER 커브인데, 10^-4이하의 BER 조건을 만족하는 가장 큰 값은 SNR이 7.25dB일 때 BER이 0.000081인 경우이다. 따라서, BER을 10^-4이하로 유지하기 위해서는 수신 신호의 SNR이 7.25dB이상이 되도록 유지해야만 한다는 것을 알 수 있다.


SNR은 노이즈에 대한 수신신호의 강도인데, 지금 우리는 아무런 interference 신호도 존재하지 않는 경우를 다루고 있으므로 노이즈는 백그라운드 노이즈만이 존재한다. 백그라운드 노이즈는 dra_bkgnoise 스테이지에서 계산되는데, 수신 노드의 위치와 상관없이 항상 일정하다.
22MHz 대역폭을 사용하는 WiFi에서 계산된 백그라운드 노이즈 값은 8.7980419999*10^-14 watt이다. 따라서, 수신 노드에서 7.25dB의 SNR을 가지기 위한 수신 신호의 강도가 4.67074*10^-13 watt임을 다음과 같이 계산할 수 있다.

송신 노드에서는 5mW의 출력으로 신호를 내보내며, 이 신호는 별도의 path-loss 없이 자유공간(Free Space)에서의 기본 전파 손실만을 겪는다. 이러한 기본적인 path-loss는 wlan_power 파이프라인 스테이지에서 반영되는데, 다음과 같은 계산된다.

이를 수식으로 표현해보면 다음과 같으며, dBm이 아닌 Watt단위의 계산을 위해서 log를 취하지 않았음에 유의하기 바란다.

수신 신호의 파워는 다음과 같이 계산되는데, 송신 안테나 이득과 수신 안테나 이득은 반영되지 않는 상태이므로 1이다. 따라서, 수신 신호 파워는 단순히 송신 출력에 자유 공간에서의 전파손실을 곱하는 형태로 계산된다.

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

계산 결과로부터 10^-4의 BER을 만족하는 통신가능 거리는 1,024M임을 알 수 있으며, 시뮬레이션을 통해서도 동일한 결과를 확인할 수 있다. 물론, 이것이 1025M부터는 통신이 전혀 이루어지지 않는다는 의미는 아님에 주의하기 바란다. BER <= 10^-4을 만족하는 최대 거리가 1024M라는 것이며, 그 이상의 거리에서도 신호 전달은 이루어지지만 에러율(BER)이 우리가 정한 기준을 만족시키지 못한다는 것이다.

저작자표시 비영리 변경금지

'Riverbed Modeler(OPNET) > WLAN Model' 카테고리의 다른 글

WiFi에서의 throughput(2) - 802.11b TCP throughput  (0) 2012.09.08
WiFi에서의 throughput(1) - 802.11b 최대 throughput  (2) 2012.07.22
WiFi 모델에서의 통신 가능거리(3)  (0) 2012.05.16
WLAN PLCP 오버헤드 크기  (0) 2011.01.16
WiFi 모델에서의 통신 가능 거리(2)  (0) 2011.01.02
Posted by 신상헌
,

Visual Studio 2008을 위한 환경 변수 설정

Riverbed Modeler(OPNET)/HowTo 2010. 10. 2. 09:43

32비트 윈도우에서 Visual Studio 2008을 컴파일러로 사용하기 위한 환경 변수 설정. (OPNET 14.5 PL0 버전부터
Visual Studio 2008을 지원한다)

DevEnvDir=C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE

Framework35Version=v3.5

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

FrameworkVersion=v2.0.50727

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

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

LIBPATH=
C:\WINDOWS\Microsoft.NET\Framework\v3.5;
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;
C:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;
C:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;

PATH=
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE;
C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN;
C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools;
C:\WINDOWS\Microsoft.NET\Framework\v3.5;
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;
C:\Program Files\Microsoft Visual Studio 9.0\VC\VCPackages;
C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin;

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

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

VSINSTALLDIR=
C:\Program Files\Microsoft Visual Studio 9.0

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

저작자표시 비영리 변경금지

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

두번째 한글 OPNET 교재가 출판되었습니다.  (2) 2010.12.01
OPNET, 윈도우즈 2000에 대한 지원 중단  (0) 2010.11.01
결과 그래프 모습의 차이 - Values per statistic  (0) 2010.08.08
허브간의 연결  (0) 2010.07.27
Proto-C란?  (0) 2010.06.07
Posted by 신상헌
,

Route redistribution - 서로 다른 라우팅 프로토콜간의 연결

Riverbed Modeler(OPNET)/IP Model 2010. 9. 1. 00:12
OPNET에서는 RIP, OSPF, IS-IS, IGRP, EIGRP, static의 라우팅 프로토콜을 지원하며, 서브네트워크마다 서로 다른 라우팅 프로토콜을 사용하도록 설정하는 것도 가능하다. 다음은 구간에 따라 RIP와 OSPF를 각각 사용하는 방법을 보이기 위한 예제망을 구성한 것이다. (사용한 노드모델은 ethernet_wkstn, ethernet_server, ethernet4_slip8_gtwy이다)

OPNET에서는 RIP이 기본 라우팅 프로토콜로 설정되므로, 예제망과 같은 토폴로지 구성후 RIP을 사용하는 좌측부분은 수정할 필요가 없으며, 우측 부분만 OSPF를 사용하도록 변경해 준다. 라우팅 프로토콜의 변경을 위해서 GW_3 노드와 GW_4 노드 사이의 링크와 GW_4 노드와 Called_party 노드 사이의 링크를 선택한 상태에서 Protococols-->IP-->Routing-->Configure Routing Protocols... 메뉴를 실행하고, 팝업창에서 다음과 같이 RIP을 해제하고 OSPF를 선택해준다. 이 방법  대신 GW_4 노드의 속성 편집창에서 IP-->IP Routing Parameters-->Interface Information-->IFx-->Routing Protocols(s) 항목을 OSPF로 직접 변경해주어도 된다. (하지만, 직접 변경을 위해서는 각 링크가 연결된 포트를 일일히 확인해야 하고, 포트마다 따로 변경작업을 해주어야 하므로 번거롭다.)

서로 다른 라우팅 프로토콜을 연결해서 사용하는 경우에는 실제 라우터에서와 동일하게 redistribution 설정이 필요한데, 이는 RIP 구간의 라우팅 정보가 OSPF 구간으로도 알려지고 또한 반대로 OSPF 구간의 라우팅 정보가 RIP 구간으로도 알려주지도록 하기 위해서이다. RIP과 OSPF가 만나는 GW_3  노드의 속성 편집창을 열고, OSPF를 위해서 IP Routing Protocols-->OSPF Parameters-->Processes-->1-->Process Parameters-->Redistribution 항목의 값을 Enabled로 변경한다. 마찬가지로 RIP을 위해서는 IP Routing Protocols-->RIP Parameters-->Process Parameters-->IPv4 - Any-->Process Parameters-->Redistribution 항목의 값을 Enabled로 변경한다. 논리적으로 이러한 설정만으로도 Redistribution이 잘 동작해야 할 것으로 생각된다. 하지만, RIP을 OSPF와 연결하는 경우에는 (일종의 버그인 것으로 의심되는데,) 이러한 기본 설정만으로는 정상적으로 동작하지 않는다. 이를 해결하기 위하여 RIP의 Redistribution 항목 하위에 있는 Dafault Metric 항목의 값을 1로 변경한다.
앞의 예제망 그림처럼 Redistribution 설정이 되었음을 그림으로 확인하고 싶다면, View-->Visualize Protocol Configuration-->IP Routing Protocols-->IPv4 Routing Protocols 메뉴를 이용하면 된다.
라우팅 프로토콜이 원하는대로 동작하여 라우팅 테이블이 잘 구성되었음을 확인하기 위해서, 라우팅 테이블을 저장하도록 설정(Protocols-->IP-->Routing-->Export Routing Tables... 메뉴를 실행하고, 팝업 창에서 All nodes 선택)하고 시뮬레이션을 수행한다. Results Browser 창에서 DES Run(1) Tables 탭으로 이동한 후, Object Tables-->Logical Network-->GW_1-->Performance-->IP Forwarding Table at End of Simulation 항목을 선택하여 GW_1 노드에서 RIP이 구성한 라우팅 테이블을 살펴본다.
5개의 서브네트워크에 대한 라우팅 경로가 모두 구성된 것을 볼 수 있다. (이 예제망에는 라우터로 연결된 5개의 링크가 있으므로, 5개의 서브네트워크가 만들어진다.)

마찬가지로 GW_4 노드에서 OSPF가 구성한 라우팅 테이블을 살펴보아도 5개의 서브네트워크에 대한 라우팅 경로가 모두 구성된 것을 볼 수 있다.

참고로, 이 예제에서 실제로 할당된 IP주소 내역은 다음과 같다.
저작자표시 비영리 변경금지

'Riverbed Modeler(OPNET) > IP Model' 카테고리의 다른 글

다중경로 라우팅(2) - 라우팅 테이블  (0) 2016.06.08
다중경로 라우팅(1) - ECMP  (0) 2016.04.07
IP 트래픽 부하 정보  (0) 2016.02.22
라우터 배치 순서와 라우팅 경로 선정  (0) 2015.05.01
PPP 링크에서의 패킷 크기  (0) 2014.07.27
Posted by 신상헌
,

OPNET Modeler 16.0 PL4 발표

Riverbed Modeler(OPNET)/Release notes 2010. 8. 17. 22:19
오늘(2010년 8월17일) OPNET Modeler 16.0 PL4 버전이 발표되었습니다(이전 버전에 관한 내용은 "OPNET Modeler 16.0.A PL1 발표" 참조). 일종의 마이너 업그레이드인지라 특별한 변경은 없을 것이라고 생각했는데, LTE 모델은 상당한 변화가 있는 모양입니다. 먼저, User Forum에 올라온 안내에는 다음과 같이 3DNV의 새로운 버전(3.0)에 대한 안내만 있습니다.

- Higher quality graphics 
- Rich content: more realistic representation of human figures, and dynamic visualization of vegetation and weather effects

Higher quality graphics가 상당히 중요한 항목인 것 같기는 합니다만, 개발자의 입장에서는 그다지 흥미가 생기지 않는군요. Release note를 살펴보니, 세부적인 기능변화보다는 Compatibility 부분이 눈에 띄입니다. Modeler 16.0 PL4 버전에서는 3DNV 3.0 버전만이 사용가능하며 3DNV 2.x 버전은 사용할 수 없다고 합니다. 또한 몇가지 결과 파일들의 호환에 문제가 있는 모양입니다.

공지에는 없지만, Release note에 중요한 모델관련 변경사항들이 있습니다. 역시 요즘 주된 업데이트 대상은 LTE인 듯 합니다. LTE 모델의 변경내용은 다음과 같습니다.
- Support for Physical Layer
- Support for Hybrid Automatic Retransmission Request (HARQ)
- Support for Radio Link Control (RLC) Acknowledged Mode
- New Node Models
- New Report Available

PHY 부분에 있어서 Pathloss model로는 Macrocell suburban based on COST231 Hata Urban model, Macrocell burban based on COST231 Hata Urban model, Microcell urban based on COST231 Walfish-Ikegami, ITU pedestrian and vehicular, Erceg suburban fixed가 제공된다고 합니다. Shadow 페이딩은 normal distribution model이 지원되며, Multipath 페이딩에 있어서는 ITU Pedestrian A and B, ITU Vehicular A and B가 제공된다고 합니다. WiMAX 모델의 경우를 생각해보면 PHY쪽의 지원이 굉장히 빨리 이루어진 것으로 생각됩니다.
HARQ는 IR 타입이 DL/UL 모두 지원된다고 하네요. LTE에서 HARQ 지원에 대한 언급을 본 것은 처음인 것 같은데, IR부터 지원하는 것은 조금 의외입니다. 구현하기는 CC 타입이 더 쉬웠을 것 같은데 말입니다.
그리고, RLC에서 Acknowledged Mode가 지원된다고 합니다.

WiMAX 모델의 변경 내용은, Control message들도 이제 PHY해서 전달된다는 점과, DSA-ACK 메시지가 추가되었다는 점입니다. 제어 메시지의 지연이나 소실은 시뮬레이션 결과에 상당한 영향을 줄 수 있으므로, 의미있는 개선이라고 생각됩니다. DSA-ACK의 경우, 사실 시뮬레이션 결과에 그다지 영향을 미치는 사항은 아닙니다만, DSA-REQ와 DSA-RSP 메시지는 있는데 DSA-ACK만 없어서 그동안 상당히 의아하게 생각하고 있었는데, 잘못되어 있었다는 것을 이제 알아챈 모양입니다.

이외에도 몇 가지 수정된 사항이 있지만, 특별히 관심가는 내용이 없어서 생략합니다.
저작자표시 비영리 변경금지

'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 PL6 발표  (0) 2010.11.09
OPNET Modeler 16.0.A PL1 발표  (0) 2010.01.03
Posted by 신상헌
,

결과 그래프 모습의 차이 - Values per statistic

Riverbed Modeler(OPNET)/HowTo 2010. 8. 8. 23:15
하나의 시나리오에서 네트워크 파라미터의 변경이 전혀없이 생성된 결과 그래프들인데도 불구하고, 실행할 때마다 그 값이 달라지는 경우가 종종 있다. (물론 시뮬레이션 seed값이 다른 경우라면 이는 당연할 것이며, 여기에서는 동일한 seed 값이 사용된 경우를 얘기한다) 이 경우, OPNET에 익숙하지 않은 사용자들은 당황하거나, 심지어는 OPNET 시뮬레이션 결과를 불신하는 상황이 벌어지기도 한다.
하지만, 이는 OPNET에서 결과값을 기록하는 방식을 정확히 이해하지 못하는 데서 발생하는 오해(?)로서, 시뮬레이션이 잘못된 것이 전혀 아니다. 즉, 시뮬레이션의 실제 결과값은 동일하지만, 이 결과값들을 가공하여 사용자에게 보여주는 과정에서 마치 다른 결과값들인 것처럼 보여지는 경우가 있는 것이다. 어떤 관점에서 보면, 결과값을 사용자에게 보여주는 방법에 있어서 너무 다양한 수단을 제공하기 때문에 발생하는 문제라고 할 수 있다.
그 예로서, 아래의 두 결과 그래프를 비교해보도록 하자. 첫번째 그래프는 VoIP_example 시나리오  (조만간 출판될 "OPNET 중급입문" 교재에 소개되어 있다)에서 Calling_1 노드의 Voice Application -->Traffic Received (bytes/sec) 항목을 그린 것이며(10분동안 수행된다), 두번째 그래프는 동일한 시나리오를 5분동안만 수행하고 동일한 항목의 결과를 그린 것이다.


두 개의 결과값이 다르게 보이는 것을 확인할 수 있을 것이다. 동일한 시뮬레이션인데도 불구하고 왜 결과값이 달라보이는 것일까? 그 이유는 역설적이지만 두 시뮬레이션에서 동일한 "Values per statistic" 속성값이 사용되었기 때문이다. Values per statistic 속성은 하나의 결과항목(statistic)을 위해서 몇 개의 값(value point)을 기록할 것인가를 지정하는 것으로, 시뮬레이션 수행시 Configuration/Run DES 창에서 설정할 수 있으며 기본값은 100이다.


두 시뮬레이션에서 동일하게 100개의 값만을 최종적으로 기록하므로, 10분(600sec)동안 시뮬레이션을 한 경우에는 600sec/100 = 6sec 간격으로 데이터를 기록하고 5분(300sec)동안 시뮬레이션을 한 경우에는 300sec/100 = 3sec 간격으로 데이터를 기록하게 된다. 기록되는 데이터는 시간에 대한 평균값이므로, 설령 동일한 시각의 기록이라 할지라도 기록 간격이 다르면 서로 다른 값으로 보여지게 된다.
다음의 결과는 이러한 매커니즘을 확인하기 위한 것이다. 첫번째 그래프는 Values per statistic 값을 100으로 두고 5분동안 수행한 것이며, 두번째 그래프는 Values per statistic 값을 200으로 변경하고 10분동안 수행한 것이다. 따라서, 두 시뮬레이션에서 데이터를 기록하는 간격은 동일하게 3sec이다. 5분까지의 결과만을 살펴보았을 때, 두 시뮬레이션의 결과가 완벽하게 일치하는 것을 확인할 수 있다.


이렇게 시뮬레이션 수행시간에 따라 결과 그래프가 달라지는 현상을 피하고 싶다면, 해당 결과항목(statistic probe)의 capture mode를 수정하여 데이터 기록 주기를 일정하게 고정시켜주면 된다. 단, 이 상태에서 긴 수행시간에 대해서 시뮬레이션을 수행할 경우, 기록되는 데이터 양의 증가로 인해 결과 프래프를 표현하는데 불편함이 발생할 수 있으니 주의하기 바란다.
다음의 결과 그래프는 동일한 시뮬레이션 결과에 대해서 데이터 기록 간격을 서로 달리하여 결과를 수집하여 그 차이를 비교해본 것이다. 즉, 세 시뮬레이션에서 실제로 발생한 raw data는 모두 같지만, 결과 데이터를 기록하는 간격이 6sec(600sec/100), 3sec(600sec/200), 1sec(매 1초마다 기록하도록 고정)로 다를 뿐이다.

저작자표시 비영리 변경금지

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

OPNET, 윈도우즈 2000에 대한 지원 중단  (0) 2010.11.01
Visual Studio 2008을 위한 환경 변수 설정  (0) 2010.10.02
허브간의 연결  (0) 2010.07.27
Proto-C란?  (0) 2010.06.07
노드의 위치정보 획득시 주의사항  (0) 2010.01.17
Posted by 신상헌
,

허브간의 연결

Riverbed Modeler(OPNET)/HowTo 2010. 7. 27. 22:01

단말의 수가 많은 세그먼트에서 실제 네트워크 구성시, 이더넷 허브를 데이지 체인(daisy chain) 형태로 연결하여 사용하는 경우가 있다. 즉, 허브에 허브를 연결하여 연결 가능한 포트수를 늘리는 것으로, 허브의 포트수가 부족한 경우에 많은 포트수를 가지는 새로운 장비를 구입할 필요없이 기존의 허브를 활용하여 문제를 해결할 수 있으므로, 상당히 유용한 방법이며 종종 사용된다.
이러한 구성이 OPNET에서도 가능할까? 아쉽게도 이렇게 허브를 연속적으로 연결하는 구성은 OPNET에서 지원되지 않는다. 즉, OPNET의 이더넷 허브 모델은 자신이 다른 허브와 직접 연결되지 않는다고 가정하고 만들어졌기 때문에, 허브에 허브를 연결하고 시뮬레이션을 수행하면 다음과 같은 에러 메시지를 보여주고 시뮬레이션이 중단된다.



이러한 에러메시지가 출력되는 직접적인 이유는 이덧넷 허브 노드 모델에 사용되는 etherent_hub_v2 프로세스 모델의 init 스테이트에서 연결된 주변 노드들을 검사하고 만약 허브와 연결되어 있으면 시뮬레이션을 중단시키기 때문이다.
init 스테이트의 Exit 블럭을 살펴보면 168라인에 다음과 같은 코드가 있다. 이웃 노드에 등록된 프로세스들을 살펴보고 "protocol" 속성값으로 "eth_hub"를 가진 프로세스가 있으면, 에러 메시지를 출력하고 시뮬레이션을 종료(ethernet_hub_concat_log_wirte() 함수)시키는 것이다.

물론, 단순히 이 부분의 코드를 삭제한다고 해서 데이지 체인으로 연결된 허브가 성공적으로 시뮬레이션 되지는 않는다. 이 부분에서 시뮬레이션을 종료시키는 이유는 데이지 체인 형태의 연결에 의한 문제인 경우, 이후의 코드에서 다른 원인에 의해서 발생하는 에러메시지와 구분되지 않아서 혼란을 주는 것을 예방하기 위해서이기 때문이다.
이러한 문제를 해결하는 방안은 충분한 포트수를 가지는 이더넷 허브 모델을 사용(256 포트를 가지는 모델을 기본으로 제공한다)하거나, 허브와 허브 사이에 브릿지나 스위치를 연결해주는 것이다.
시뮬레이션 관점에서 본다면, 한개의 허브에 수백개의 단말을 개별적으로 연결해야하는 경우는 극히 드물다. 왜냐하면 많은 수의 단말에 의한 전체적인 영향을 살펴보기 위해서라면, 한개의 LANs 노드 모델로 충분히 모델링이 가능하며 훨씬 간편하기 때문이다.

저작자표시 비영리 변경금지

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

OPNET, 윈도우즈 2000에 대한 지원 중단  (0) 2010.11.01
Visual Studio 2008을 위한 환경 변수 설정  (0) 2010.10.02
결과 그래프 모습의 차이 - Values per statistic  (0) 2010.08.08
Proto-C란?  (0) 2010.06.07
노드의 위치정보 획득시 주의사항  (0) 2010.01.17
Posted by 신상헌
,

Background Traffic의 영향

Riverbed Modeler(OPNET)/Traffic 2010. 6. 20. 21:59

인터넷망에서 사용자가 경험하는 서비스 품질은 백그라운드 트래픽(해당 사용자에 의해서 발생되는 패킷이외의 패킷들)에 의해서 많은 영향을 받는다. 즉, 동일한 망에서 서비스를 받는 경우에도 해당 경로상에 존재하는 백그라운드 트래픽의 양에 따라 사용자가 경험하는 서비스 품질이 달라지는 것이다. OPNET에서는 이러한 백그라운 트래픽을 간단하게 설정할 수 있는 몇 가지 방법을 제공하고 있는데, 그 중 한가지가 링크의 "Traffic Load" 속성을 이용하는 것이다. 이 속성을 이용하면 백그라운드 트래픽을 매우 쉽게 설정할 수 있을 뿐만 아니라, 시뮬레이션 수행시간에는 거의 영향을 미치지 않으면서 큰 백그라운드 트래픽에 의한 영향을 살펴볼 수 있다.
백그라운드 트래픽이 시뮬레이션 결과에 어떤 영향을 미치는지 예제를 통해 살펴보도록 하자. 사용할 예제망의 토폴로지는 다음과 같으며, Calling_1 노드와 Called_party 노드간에는 "Voice over IP Call (PCM Quality)" 어플리케이션을 설정해 주었다.


예제망에서 백그라운드 트래픽이 설정될 구간은 GW_1 노드와 ISP_backbone 노드 사이의 링크이며, 설정할 트래픽 양은 링크 용량 대비 30%, 50%, 70%이다. 링크의 "Traffic Information" 속성에 한개의 열(Row)을 추가하고, "Traffic Load (bps)" 속성을 Edit 모드로 선택하여 300sec에서 400sec 사이에 트래픽이 발생하도록 설정해 주었다. 이때 트래픽의 크기는 %가 아닌 bps로 설정되어야 한다. 이 예제에서는 DS3급(44.736Mbps) 링크를 사용하였으므로, 30%, 50%, 70%에 맞추어 13,420,800bps, 22,368,000bps, 31,315,200bps를 설정해 주었다. 다음 그림은 이 과정을 보인 것이다.


이제 각 설정별 시나리오에 대한 시뮬레이션을 수행하고 결과를 비교해보도록 하자. 먼저 백그라운드 트래픽이 잘 걸렸는지 확인하기 위해서, GW_1 노드와 ISP_backbone 노드 사이 링크의 throughput을 살펴보도록 한다. 다음 그림은 우리가 설정해준 크기대로 백그라운드 트래픽이 잘 걸렸음을 보여준다.


이제 Calling_1 노드에 수신된 패킷의 End-to-End Delay를 살펴보면, 백그라운드 트래픽이 높아질수록 delay 값이 증가하는 것을 다음과 같이 확인할 수 있다.


Delay가 증가하면 MOS는 떨어지게 되는데, 이 역시 다음과 같이 확인할 수 있다.


이상과 같이 백그라운드 트래픽을 링크에 간단하게 설정하는 방법과, 이러한 설정이 실제로 시뮬레이션 결과에 영향을 미친다는 것을 살펴보았다. 하지만, 여기에서 한가지 의문을 가질 수 있는데, 그것은 백그라운드 트래픽이 시뮬레이션 결과에 영향을 미치기는 하지만, 그 차이가 예상보다(?) 터무니없이 작다는 점이다. (이 예제에서 백그라운드 트래픽을 70%까지 증가시켰을 경우에도 백그라운드 트래픽이 전혀 없을 때와는 차이는 겨우 170usec 정도에 불과하다) 이 문제에 대해서는 다음 포스팅에서 다루어 보도록 하겠다.

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

Background Traffic의 영향(5) - Traffic Mix  (0) 2013.12.04
Background Traffic의 영향(4) - Demand Model  (0) 2013.11.19
네트워크 Jitter(3) - Laplace 모델  (0) 2013.01.21
네트워크 Jitter(1) - VoIP 실험을 위한 네트워크 Jitter 설정  (0) 2013.01.14
Delay Variation과 Jitter의 차이  (1) 2010.05.09
Posted by 신상헌
,

Proto-C란?

Riverbed Modeler(OPNET)/HowTo 2010. 6. 7. 23:29
OPNET에서 사용하는 언어는 정확히 표현하자면 그냥 C가 아니라 "Proto-C"이다. Proto-C라는 별도의 명칭을 사용하는 이유는 OPNET에서는 일반적인 C/C++ 언어의 기능외에도, KP(Kernel Procedure)라고 불리우는 추가적인 함수들을 사용할 수 있으며, 프로토콜을 모델링할 때 그래픽 유저 인터페이스를 통해 STD(State Transition Diagram)를 표현하기 때문이다.
즉, Proto-C라고 해서 기존의 C/C++ 언어와 다른 문법을 사용하는 것은 아니며(이는 OPNET이 자체적인 컴파일러를 가지고 있지 않으며, Visual C++이나 gcc등의 범용 컴파일러를 불러와서 사용하는 것을 생각해보면 당연한 것이다), 통신망 모델링에서 공통적으로 사용되는 여러가지 편리한 함수 라이브러리들을 추가적으로 제공하고, GUI상에 그려진 스테이트 다이어그램을 자동으로 C 코드로 변환해주는 기능을 제공하는 것이다.

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

OPNET, 윈도우즈 2000에 대한 지원 중단  (0) 2010.11.01
Visual Studio 2008을 위한 환경 변수 설정  (0) 2010.10.02
결과 그래프 모습의 차이 - Values per statistic  (0) 2010.08.08
허브간의 연결  (0) 2010.07.27
노드의 위치정보 획득시 주의사항  (0) 2010.01.17
Posted by 신상헌
,

Delay Variation과 Jitter의 차이

Riverbed Modeler(OPNET)/Traffic 2010. 5. 9. 19:27
Voice Application의 Statistic 결과 항목들을 보면 다음 그림과 같이 "Packet Delay Variation" 항목과는 별도로 "Jitter (sec)" 항목도 있다.


일반적으로 Jitter는 패킷 전달 지연시간의 편차로 해석되기 때문에, 거의 동일한 의미로 해설될 수 있는 Packet Delay Variatioin 항목이 같이 있는 것은 사용자들에게 곧잘 혼란을 불러일으키고는 한다. 이 두 가지 값의 정확한 차이를 알아보도록 하자.
먼저 Packet Delay Variation의 (OPNET에서 사용하고 있는) 정의는 다음과 같다.
"Variance among end to end delays for voice packets received by this node. End to end delay for a voice packet is measured from the time it is created to the time it is received. "
실제로 delay variation 값은 gna_stat_variance_obtain() 함수에서 계산되는데, 해당 코드는 다음과 같다. (gna_support.ex.c 파일)
-----------------------------------------------------------------------------------
  mean_value = stat_data_ptr->sample_sum / stat_data_ptr->sample_count;
  variance_value = (stat_data_ptr->sample_sq_sum / stat_data_ptr->sample_count) -
   (mean_value * mean_value);
-----------------------------------------------------------------------------------
소스코드를 수식으로 변환하여 표현하면, 다음과 같다.


따라서, 소스코드와 Statistics 항목의 설명에서 명확하게 알 수 있듯이, 여기에서 variance가 의미하는 것은 일반적인 뜻인 '변화량'이 아니라 통계에서 사용하는 '분산'인 것이다.

다음으로 Jitter의 (OPNET에서 사용하는 있는) 정의는 다음과 같다.
"If two consequetive packets leave the source node with time stamps t1 & t2 and are played back at the destination node at time t3 & t4, then:
jitter = (t4 - t3) - (t2 - t1)
Negative jitter indicates that the time difference between the packets at the destination node was less than that at the source node."
실제로 jitter 값은 gna_voice_called_mgr (또는 gna_voice_calling_mgr) 프로세스 모델에서 계산되는데, 해당 코드는 다음과 같다.
-------------------------------------------------------------------------------------
/* Compute the jitter */
jitter = (op_sim_time () - prev_pk_info_ptr->play_back_time) - (rtp_pk_info_ptr->time_stamp - prev_pk_info_ptr->time_stamp);
-------------------------------------------------------------------------------------

Statistic 항목의 설명과 동일하게 jitter = (현재시간 - 이전 패킷의 수신시간) - (패킷을 송신한 시간 - 이전 패킷을 송신한 시간)으로 계산되고 있음을 확인할 수 있다. 즉, Jitter는 연속된 두 패킷에서 송신 노드에서 보내질 때의 시간 간격과 수신노드에 도착할 때의 시간 간격의 차이를 의미하는 것이다.

시뮬레이션 결과를 살펴보면 다음과 같이 전혀 다른 값이 기록되어 있는 것을 확인할 수 있으며, 그 이유는 앞에서 설명한 것처럼 서로 계산하는 방식이 전혀 다르기 때문이다.

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

Background Traffic의 영향(5) - Traffic Mix  (0) 2013.12.04
Background Traffic의 영향(4) - Demand Model  (0) 2013.11.19
네트워크 Jitter(3) - Laplace 모델  (0) 2013.01.21
네트워크 Jitter(1) - VoIP 실험을 위한 네트워크 Jitter 설정  (0) 2013.01.14
Background Traffic의 영향  (0) 2010.06.20
Posted by 신상헌
,

노드의 위치정보 획득시 주의사항

Riverbed Modeler(OPNET)/HowTo 2010. 1. 17. 19:35

시뮬레이션을 하다보면, 노드의 위치정보를 사용해야하는 경우가 종종 발생한다. 특히, 무선망이나 이동성을 시험하는 경우에는 필수적이다. OPNET에서 노드의 위치정보를 획득할 수 있는 수단은 두가지이다.
1. op_ima_obj_pos_get(site_objid, lat_ptr, long_ptr, alt_ptr, x_ptr, y_ptr, z_ptr) 함수를 통해 지구중심좌표계(geocentric coordinate system) 상의 값을 구하는 방법.
2. op_ima_obj_attr_get_dbl(objid, attr_name, value_ptr) 함수를 통해 "x position"과 "y position" 값, 즉 평면상에서의 2D 좌표를 구하는 방법.

2번 방안의 경우 화면상의 표시와 쉽게 매칭되기 때문에, 이해하기 쉽다. 하지만, x/y 좌표를 구하기 위해서는 함수를 2번 호출해야한다는 번거로움(?)이 있다. 1번 방안의 경우 한번의 호출로 모든 좌표정보를 알아낼 수 있으며, 좀 더 멋있어(?) 보인다는 장점도 있다.
그런데, 1번 방안을 통해 알아낸 좌표값을 사용할 경우, latitude / longitude / altitude는 표현 자체가 완전히 다르므로 헷갈릴 일이 없지만, 뒷 부분의 x/y/z 좌표값을 혼동의 여지가 있으므로 사용에 주의할 필요가 있는데 여기에서 말하는 x/y/z 좌표값은 지표면을 기준으로 하는 값이 아니라는 점이다. 즉, 1번 방안을 통해 알아낸 x/y 좌표값과, 2번 방안을 통해 알아낸 x/y 좌표값은 서로 완전히 다른다. 그러므로, 사용하고자 하는 목적에 따라 두 방법 중 적절한 방법을 선택해서 사용해야만 한다.
일반적으로 1번 방안은 특정 서브네트워크에 대해서 지구상에서의 위치를 파악할 때 사용되고, 2번 방안은 서브네트워크안에서 노드들 사이의 (우리가 흔히 생각하는) 거리를 계산할 때 사용된다. 두 방안의 x/y 좌표값을 혼동해서 사용할 경우, 예상치 못한 엉뚱한 결과가 나올 수도 있으므로 주의할 필요가 있다.

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

OPNET, 윈도우즈 2000에 대한 지원 중단  (0) 2010.11.01
Visual Studio 2008을 위한 환경 변수 설정  (0) 2010.10.02
결과 그래프 모습의 차이 - Values per statistic  (0) 2010.08.08
허브간의 연결  (0) 2010.07.27
Proto-C란?  (0) 2010.06.07
Posted by 신상헌
,

티스토리툴바