VoIP 시뮬레이션을 할 때 Jitter는 VoIP 서비스의 품질(ex: MOS)에 큰 영향을 미치는 중요한 요소이다. 대상 통신망 구조와 트래픽을 모두 모델링하여 시뮬레이션에 반영하고 시뮬레이션 과정에서 Jitter가 자연스럽게 발생하도록 하는 방법도 생각해볼 수 있겠지만, 이는 망 구조나 트래픽 정보 수집에 대한 어려움을 차치하고서라도 시뮬레이션 수행시간이 너무나도 오래 걸릴 수 있기 때문에 실제로 사용하기는 매우 곤란하다.
따라서, 많은 경우에 있어 (ip32_cloud 노드 모델의 Performance Metrics-->Packet Latency (secs) 속성같은) 강제적인 방법으로 망 전체에서 발생하는 Jitter를 넣어주는 방법을 사용하기도 한다.

 

 

Posted by 신상헌
,

OPNET WiMAX 모델은 자원 할당을 위한 최소 단위로써 quantum이라는 정의를 사용하고 있다. 따라서, 자원은 quantum 단위로 할당되며, quantum보다 작은 크기의 자원은 할당될 수 없다. OFDMA 방식에서 quantum은 subchannel당 subcarrier 수와 quantum당 symbol 수의 곱으로 정의된다. (즉, 1 subch x quantum symbols이다) Quantum당 symbol의 수는 DL/UL, PUSC/FUSC 여부에 따라 달라진다. 다음 그림은 이를 표현한 것이다.

Bit 단위의 BW 요청은 변조방법과 코딩 레이트를 고려하여 symbol 단위로 변환된다. 이 symbol 단위의 요청 BW를 quantum으로 나누었다가 다시 quantum으로 곱해주면, 요청된 BW를 전송할 수 있는 quantum 단위의 자원 크기를 구할 수 있다. 단, quantum으로 나눌 때에는 결과값을 올림(ceil) 처리한다.

Posted by 신상헌
,

OFDMA 방식일 때 OPNET에서 사용하는 WiMAX 프레임의 구조는 다음 그림과 같다.

 


Preamble은 다른 burst들의 전송 시점을 계산하기 위해서 사용될 뿐이며, preamble 자체가 실제로 전송되지는 않는다.
DL-MAP은 PHY를 통해서 전송되기는 하지만, 실제로 DL-MAP IE 정보가 전달되지는 않는다. 단지 DL-MAP 크기만큼의 공간을 차지하는 dummy burst가 전송될 뿐이다. 실제 시스템이라면 DL-MAP의 정보를 이용해야만 이후에 따라오는 데이터 프레임들을 정상적으로 수신할 수 있지만, 시뮬레이션에서는 DL-MAP의 정보가 없더라도 데이터 프레임을 수신하는데 아무런 문제가 없다. 그래서, 구체적인 IE 정보를 담은 DL-MAP을 전송하는 대신, 해당 크기만을 가지는 burst를 전송하는 것이다. (DL-MAP을 아예 전송하지 않았었던 15.0 버전과 비교하면 DL-MAP 전송기능이 많이 보강된 것이다) UL-MAP은 실제 IE 정보를 포함하여 전송된다.
DL-MAP과 UL-MAP은 모두 수직축(Subchannel number)을 따라서 차례대로 채워져 나가는데, 수직축의 끝에 도달하면 다음 수평축(Symbol number)으로 넘어간다. 만약 배치된 DL-MAP이나 UL-MAP이 직사각형(rectangular)이 아닐 경우, 직사각형별로 분할(fragmentation)된다.
UL-MAP 이후에는 DL-burst가 배치된다. DL-burst들 역시 세로축을 따라서 먼저 채워지고, 세로축의 끝에 도달하면 다음 가로축으로 넘어간다. 각 DL-burst는 직사각형(rectangular) 형태를 가진다.
DL 구간이 끝나면 TTG 시간 간격이후 UL 구간이 시작된다. UL 구간에는 Initial & Handover Ranging 영역, Periodic & BWR Ranging 영역, Fast Feedback 영역이 배치되는데, 각각 정사각형의 모양을 가진다. 이러한 overhead 영역들의 크기는 사용자 설정에 따라 변경될 수 있지만, 영역의 시작지점은 고정적이다. 가로축으로 보았을 때 각 영역의 시작점은 UL 구간의 시작점이며, 세로축으로 보았을 때는 각 영역이 시작점부터 연속적으로 배치된다.
UL-burst는 DL-burst와 달리 가로축을 따라서 먼저 채워지고, 가로축의 끝에 도달하면 다음 세로축으로 넘어간다. 그런데, overhead 영역들은 가로축으로 서로 다른 길이를 가질 수 있으며, 또한 세로축의 끝까지 모두 채워지는 것도 아니다. 따라서, subchannel마다 다른 시작 symbol 시점에 맞추어서 구불구불(snaking)하게 UL-burst가 배치된다. UL 구간이 끝나고 나면, RTG 시간 간격 이후 다음 프레임이 시작된다.

Posted by 신상헌
,

향후에는 OPNET Modeler 제품에서 Red Hat Enterprise Linux(RHEL) 4와 Fedora Linux 6에 대한 지원이 이루어지지 않을 것이라는 발표가 지난 12월 6일에 있었습니다. 다만, 이는 Linux OS 자체에 대한 지원이 중단된다는 의미가 아니며, 해당 버전의 Linux에 대한 지원을 중단한다는 것입니다. 얼마전에 발표되었던 OPNET Modeler 17.5 버전("OPNET Modeler 17.5 PL3 발표" 참조)에서는 RHEL 4, 5, 6 버전과 Fedora Linux 6 버전의 Linux를 지원하고 있습니다. 따라서, 17.5 버전이 RHEL 4와 Fedora 6를 지원하는 마지막 버전이 될 것이라고 합니다.
국내에서는 Linux 환경에서 OPNET을 사용하는 사용자가 매우 적은 것으로 알고 있어서, 큰 영향은 없을 것 같기는 합니다.

Posted by 신상헌
,

OPNET 버전간의 호환성 문제에 관한 또다른 간단한 예는 VoIP 성능 분석에 관한 것이다. 가장 대표적인 VoIP 성능지표인 MOS 측정에 있어, 16.0 이전 버전에 의한 결과와 16.1 이후 버전에 의한 결과는 동일한 시나리오라 할지라도 큰 차이를 보인다. 다음 그림은 "OPNET 중급입문" 5.5절의 VoIP_example_delay 시나리오를 15.0 버전과 16.1 버전에서 각각 실행하여 그 결과를 비교한 것이다. ("OPNET 중급입문"의 모든 예제는 15.0 PL3 버전을 기준으로 작성되었다.)

 

 


MOS 결과값이 이렇게 큰 차이를 보이는 이유는 무엇일까? 그 이유는 바로 VoIP에 사용되는 Jitter Buffer(OPNET에서는 Playout Delay로 표현, Jitter Buffer에 대해서는 이후에 별도의 글에서 다룰 것이다)의 기본값이 변경되었기 때문이다. 즉, 16.0 버전까지의 Jitter Buffer 기본값이 200ms였는데, 16.1 버전에서 40ms로 변경되었다. 따라서, Jitter Buffer의 크기를 사용자가 직접 설정해주지 않았다면, 16.0 이전 버전에 의한 결과와 16.1 이후 버전에 의한 MOS 결과값은 차이가 나는 것이 당연하다. ("OPNET 중급입문" 5장 예제의 MOS 결과가 일반적인 상황과 비교하여 전반적으로 낮게 보여지는 것도 이 때문이다.) 15.0 버전에서도 Jitter Buffer의 크기를 직접 40ms로 설정하고 시뮬레이션을 수행하면, 다음 그림과 같이 16.1 버전과 동일한 MOS 결과 값이 나오는 것을 확인할 수 있다.

 

 

 

 

 

Posted by 신상헌
,

지난 11월5일에 OPNET Modeler 17.5 PL3 버전이 발표되었습니다(이전 버전에 관한 내용은 "OPNET Modeler 17.1 PL2 발표" 참조). 17.1 PL2 때도 그러더니, 이번에도 아무런 공지가 없어서 새 버전이 나온 줄 모르고 있었네요.
Release note를 통해 변경 사항을 살펴보았습니다. 모델 및 Modeler 마이너 업데이트에 대한 내용이 대부분입니다만, 눈여겨 볼만한 내용도 몇가지 포함되어 있네요. 중요 업데이트 사항은 다음과 같습니다.
- LTE Model Enhancements
- TCP Model Enhancements
- Wireless LAN Model Enhancements
- Standard Applications Model Enhancements
- Advanced Wireless Package
- Using Multiple Processors for Simulation Runs
- ODB Enhancements

 

LTE 모델에서는 Connectd Mode에서 Discontinuous Reception (DRX) 동작을 사용할 수 있게 되었으며, Deivce Creator에서 LTE를 지원하게 되었다고 합니다. 그리고, Multipath 채널 모델을 Downlink와 Uplink로 구분하여 적용하게 되었습니다.
TCP 모델에서는 TCP CUBIC 방식에 대한 지원이 추가되었습니다. Attribute 측면에서는 TCP 동작 방식을 결정하기 위한 "Flavor" 속성이 추가되고, 대신 "Fast Retransmit" 속성과 "Fast Recovery" 속성이 삭제되었습니다.
WLAN 모델의 개선 사항은 802.11n에 관한 것으로 A-MSDU와 A-MPDU의 전송이 가능해졌습니다. Block-ACK 부분에 대한 개선도 포함되어 있는데, A-MSDU와 A-MPDU의 사용에 따른 것으로 추측됩니다.
표준 어플리케이션 모델에서는 P2P File Sharing과 Mobile User에 대한 어플리케이션 정의가 추가되었습니다. 향후에 유용하게 쓰일 수 있는 부분일 것 같습니다. 그리고, Voice Encoder Scheme에 AMR 오디오 코텍이 추가되었습니다.
Advanced Wireless 패키지는 무선 노드 모델을 새로 만들거나 기존 모델의 PHY를 수정할 때 사용할수 있도록 추가된 것인데, 실제로 어떤 API들로 구성되어 있는지를 자세히 살펴볼 필요가 있을 것 같습니다.
Using Multiple Processors for Simulation Runs는 기존의 distributed simulation 기능을 좀더 사용하기 편하게 변경한 것입니다. Multiple run이 필요한 시나리오를 multi-core 시스템에서 실행시킬때, 사용할 core의 수를 간편하게 지정할 수 있게 되었다고 합니다.
ODB Enhancements에서는 Wireless 디버깅을 도와주기 위한 Wireless Xmit Tabbed Page가 ODB 창에 추가되었다는 점이 눈에 띄네요.
 
이외에도 여러가지 추가/변경된 사항들이 있지만, 현재 관심이 가는 내용이 아니라서 생략합니다.

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

OPNET Modeler 17.5 PL5 발표  (0) 2013.08.16
OPNET Modeler 17.5 PL4 발표  (0) 2013.05.23
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
Posted by 신상헌
,

DL/UL-MAP 생성에는 스케줄러를 거쳐 생성된 승인(grant) 정보뿐만 아니라, TTG / RTG / Preamble / Subchannel
수 / Symbol 수등과 같이 프레임 구조에 대한 정보와 Ranging region등과 같이 프레임마다 반복되는 오버헤드에 대한 승인 정보도 사용된다.
MAP 생성절차는 스케줄링과 동일한 절차로 진행된다. 하지만, 스케줄링이 되었다고 해서 MAP이 완전하게 생성된 것은 아니므로, 스케줄링 후 MAP 생성 완료를 위해서는 IE들에 대한 부가적이 조정이 필요하다. DL/UL-MAP이 생성되는 절차를 요약해보면 다음 그림과 같다.

 

 

Posted by 신상헌
,

OPNET WiMAX 모델에서 스케줄링은 UL, DL 순서로 진행되며, UL/DL 내에서는 다시 UGS/ertPS, rtPS/nrtPS, BE의 순서로 진행된다. 이 순서를 그림으로 표현하면 다음과 같다.

 


UL 구간을 먼저 스케줄링 하는 이유는 UL-MAP이 DL 구간으로 전송되기 때문이다. 즉, UL-MAP의 크기가 결정되어야만 DL 구간의 가용 자원량이 결정되고, DL-MAP 구성도 가능해진다. UL에서의 스케줄링은 UGS/ertPS, rtPS/nrtPS, BE 서비스 플로우의 순으로 이루어지는데, UL 구간의 자원이 모두 소진되면 더 이상의 스케줄링을 중단하고 DL 구간의 스케줄링 절차로 넘어간다. UL에서는 BW 요청이 하나씩 승인처리될때마다 승인에 대한 병합(amalgamation)이 따라서 수행된다.
DL에서의 스케줄링도 UGS/ertPS, rtPS/nrtPS, BE 서비스 플로우의 순으로 이루어진다. 하지만, DL에서는 스테이징 버퍼가 사용되므로, 이전 프레임에서 실제로 전송되지 못하고 스테이징 버퍼에 남아있는 BW 요청이 있으면 가장 먼저 처리해준다. DL에서는 BW 요청에 대한 승인 처리를 하기전에, 이번 프레임에서 전송할 것으로 예상되는 BW 요청들을 뽑아서 스테이징 버퍼에 저장해두는 과정을 거치며, 이 때 병합(amalgamation)이 이루어진다. 즉, BW 요청들에 대한 병합이 이루어진후에 승인 처리가 일어나는 것이다. rtPS/nrtPS 서비스 플로우와 BE 서비스 플로우에 대한 BW 요청들은 스테이징 버퍼에 함께 저장되었다가 승인처리된다.

Posted by 신상헌
,

OPNET Technologies사가 Riverbed Technology에 팔렸다고 합니다.
http://www.ddaily.co.kr/news/news_view.php?uid=96948

 

OPNET사는 그동안 상당히 실적이 좋았던 터라, 매각은 의외의 소식이네요. 그리고, 매각 가격도 상당히 놀랍습니다. 오늘 환율이 1,092원이니까, 10억불이면 1조1천억원정도네요. OPNET사의 가치가 이렇게 높으리라고는 생각하지 못했습니다.
하여간, 앞으로 OPNET 제품이나 라이센스 정책에 어떤 변화가 있을지 흥미로워집니다.

Posted by 신상헌
,

OPNET을 사용하다보면 버전간의 호환성 문제로 고생하는 경우가 종종 발생한다. 모델을 수정/개발해서 사용하는 경우라면, 기존 버전에서는 문제가 없는 모델이 다른 버전에서는 컴파일 또는 실행 에러가 발생하여 시뮬레이션이 중단되는 문제가 있을 수 있다. OPNET 표준 모델을 사용하는 경우에도, 동일한 시나리오를 구성하였음에도 불구하고 시뮬레이션 결과가 크게 다른 현상이 발생할 수도 있다.
 이러한 문제의 원인은 대부분 OPNET의 버그때문이 아니라, OPNET에서 제공하는 프로토콜 모델이 계속 업데이트 되고 있기 때문이다(물론, 버그때문인 경우도 있기는 하다). 즉, OPNET 버전 업에 따라 프로토콜 기능수정, 사용하는 구조체/패킷 형식 변경, 프로세스/노드 모델 파라미터 변경등이 계속 이루어지고 있으며(이런 변경은 아무런 공지사항없이 이루어지는 경우도 많다), 변경사항을 정확히 확인하지 않고 다른 버전을 적용하면 전혀 예상치 못했던 문제가 발생할 수 있다. 특히, 네트워크 시뮬레이션의 특성("NLS와 SLS" 참조)상 여러 계층의 프로토콜이 함께 사용되기때문에, 관심 대상이 아닌 다른 프로토콜의 변화도 시뮬레이션 수행 과정에서 발생하는 오류나 결과에 큰 영향을 미칠 수 있다.
다음은 16.1 버전에서 잘 동작하던 시나리오를 15.0 버전에서 그대로 적용하였을 때 시뮬레이션 결과가 크게 달라져서 사용자를 당황시킨 한가지 예이다(모델을 수정/개발하는 경우와는 달리, 표준 모델을 사용하는 경우에는 상위 버전에서 사용하던 시나리오를 하위 버전에서 적용해보는 상황이 가끔씩 있다). 16.1 버전에서는 트래픽이 꾸준히 잘 전달되는 반면, 15.0 버전에서는 트래픽이 전달되지 않는 구간이 더 많은 것을 볼 수 있다.

 


이러한 문제가 발생하는 원인은 WLAN 프로토콜 Data rate의 Default 설정값이 15.0 버전에서는 802.11b 11Mbps인 반면, 16.1 버전에서는 802.11g 24Mbps로 변경되었기 때문이었다. 필자는 16.1 버전에서 WLAN 모델에 상당한 변화(새로운 기능의 추가, "OPNET Modeler 16.1 PL1 발표" 참조)가 있다는 것을 알고 있는 상황이었음에도 불구하고, WLAN이 이 시뮬레이션에서의 주된 관찰 대상이 아니었기 때문에 15.0 버전에서도 별다른 차이가 없을 것이라고 가볍게 생각하였다가 고생을 했던 것이다(이런 속도 변경은 트래픽 손실과는 별 관련이 없어 보이지만, 다른 프로토콜의 동작과 결부되면 이 예처럼 예상치 못한 결과를 초래하기도 한다).

Posted by 신상헌
,