네트워크 시뮬레이션 공방

Erceg은 NLOS 환경에서의 pathloss 모델로서 다음과 같은 수식에 의해서 계산된다. Terrain Type에 따라 A(Hilly/Moderate-to-Heavy Tree Density), B(Hilly/Light Tree Density or Flat/Moderate-to-Heavy Tree Density), C(Flat/Light Tree Density)로 구분되며, 각 경우에 따른 계수값은 다음 그림과 같다.

Frequency 보정 항목(PLf)과 Antenna Height 모정 항목(PLh)은 원래의 Erceg 모델[2]이 1.9GHz 주파수 대역을 사용하고 단말 안테나가 2미터 높이에 위치한 경우를 가정한 것이기 때문에, 그 차이를 보정하기 위한 것이다.
이 pathloss 수식은 shadow fading을 포함하며, shadow fading 값은 GUI를 통해 설정된 표준편차 값을 이용하여 시뮬레이션 수행시에 랜덤하게 생성된다.
Erceg 모델의 입력값과 출력값을 개념적으로 살펴보면, 거리, 주파수, 기지국 높이, 단말 높이, 지형 종류를 입력받아서 shadow fading을 포함하는 pathloss 값을 결과값으로 출력한다.

[1] V. Erceg, etal., "Channel Models for Fixed Wireless Applications," IEEE 802.16.3c-01/29r4, July 2001.
[2] V. Erceg, et al., "An empirically based path loss model for wireless channels in suburban environments," IEEE JSAC, vol. 17, no. 7, July 1999, pp. 1205-1211.

UDP는 분할(segmentaiton) 및 재조립(reassembly) 기능을 제공하지 않으므로, UDP 패킷 크기를 초과하는 크기의 데이터는 전달할 수 없다. OPNET에도 이러한 UDP의 특성이 모델링되어 있어서, 일정 크기 이상의 데이터 패킷이 UDP로 전달되면, 패킷을 전송하지 않고 폐기한다. 따라서, 이 특성을 정확하게 이해하지 못하면, 사용자가 설정한 트래픽이 실제로는 시뮬레이션에 영향을 미치지 않을 수도 있으므로 주의하여야 한다.
다음 그림은 표준[1]에 정의된 UDP 패킷 구조를 나타낸 것이며, 2Bytes의 Length 필드로 표현할 수 있는 UDP 패킷의 최대 크기는 65,535Bytes이다. 따라서, UDP 패킷 헤더 8Bytes를 제외하면, UDP 페이로드의 최대 크기는 65,527Bytes가 된다.

Custom Application을 이용하면 다음 그림과 같이 Transport Protocol을 UDP로 손쉽게 변경할 수 있다(Custom Application을 이용하여 트래픽을 설정하는 방법은 "OPNET 기초다지기" 3.2.2절 예제 참조).

다음 그림은 Custom Application을 이용하여 65,527Bytes와 65,528Bytes 크기의 데이터 패킷을 0.1sec 간격으로 발생시켜 UDP를 통해 전송하려고 하였을 때 UDP 계층을 거쳐 전달되는 트래픽을 측정한 것이다. 65,527Bytes 크기의 데이터 패킷을 발생시켰을 때에는 트래픽이 잘 전달되는 반면, 65,528Bytes 크기의 데이터 패킷을 발생시켰을 때에는 트래픽이 전혀 전달되지 않는 것을 확인할 수 있다.

이렇게 사용자가 설정해준 트래픽이 실제로는 네트워크로 전혀 전달되지 않고 UDP 계층에서 폐기되지만, 이는 UDP의 정상적인 동작이므로 시뮬레이션 수행시 에러 메시지는 발생하지 않는다. 다만, 패킷 폐기시 WARNING 메시지를 남겨주므로, Log Viewer를 통해 확인할 수 있다.

[1] RFC 768, "User Datagram Protocol," IETF, 1980.

지난 8월18일자(2014년)로 Riverbed Modeler 18.0 버전이 발표되었습니다(이전 버전에 관한 내용은 "OPNET Modeler 17.5 PL6 발표" 참조). "OPNET? OPNET Modeler? Riverbed Modeler?"에서 우려하였던 것처럼 OPNET Modeler라는 이름이 아니라 Riverbed Modeler라는 이름으로 발표되었으며, 버전 뒤에 따라붙던 PL(Patch Level) 표기도 사라졌습니다. 배포되는 방식도 기존처럼 Modeler, 모델 라이브러리, 사용자 매뉴얼이 별도의 파일로 나뉘어지지 않고, 하나의 파일로 통합되어서 제공됩니다.

Release note를 통해 변경 사항을 살펴보았습니다. 먼저 명칭 변경과 더불어서 제품 구조에도 큰 변화가 있는데, 그중 중요하다고 생각되는 항목은 다음 두가지 입니다.

- Flow Analysis가 Modeler로부터 제외됨
- ODK가 Modeler의 표준 기능으로 포함됨

Flow Analysis 기능은 이번 버전부터 Modeler에서 제거되었고, SteelCentral NetPlanner(예전의 OPNET Network Planner)를 통해서만 사용할 수 있게 되었습니다. Flow Analysis 기능은 Modeler의 기본 기능인 DES 시뮬레이션과는 성격이 다르기때문에 이러한 분리가 논리적으로는 맞는 것 같기는 합니다만, Modeler 사용자 입장에서는 매우 번거롭게 되었기 때문에 상당히 아쉬운 부분입니다.
ODK(OPNET Development Kit)는 기존에는 별도의 추가 모듈로 제공되는 기능이었는데, 이번 버전부터는 기본 기능으로 제공된다고 합니다. 사용자 입장에서는 환영할 일이네요. (OPNET 이라는 명칭이 모두 Riverbed로 변경되어 사라졌는데, 특이하게 ODK에서만 남아있네요)

다음으로 모델 및 Modeler에 대한 중요 업데이트 사항은 다음과 같습니다.

- WLAN : 802.11p WAVE Support
- WLAN : Hybrid Coordination Function (HCF) Enabled by Default
- LTE : Uplink Power Control
- MANET : Simplified Multicast Forwarding
- TMM : Urban Propagation Module
- SITL : Support for Parallel Simulations

WLAN 모델에서는 802.11p WAVE 방식에 대한 지원이 추가되었습니다. NS-3와 비교해보면 많이 늦은 편이긴 합니다만, 지금이라도 지원된다고 하니 다행스러운 일입니다. 그리고, WLAN 모델의 HCF Parameters 속성 기본값이 "Default"로 변경되었습니다(이전의 기본값은 "Not Supported"). 즉, WLAN의 QoS 기능이 이제 기본적으로 활성화된다는 의미이며, 기존 버전에서 사용하던 시나리오를 가져와서 사용하는 경우에는 주의해야할 것 같습니다.   
LTE 모델에서는 Uplink Power Control 기능을 사용할 수 있게 되었습니다.
MANET 모델에서는 IP 멀티캐스트 패킷을 효율적으로 전달할 수 있도록 중복되는 패킷을 검출하고 제거하는 SMF(Simplified Mulicast Forwarding) 기능이 추가되었다고 합니다.
TMM 모듈에서는 다양한 소재의 물체로 구성된 복잡한 3D 가상 환경에서의 무선 전파 효과를 모델링할 수 있는 Urban Propagation Module이 추가되었습니다. 지원되는 주파수 대역은 900MHz ~ 100GHz입니다.
SITL 모듈에서는 paralled simulation kernel에 대한 지원이 추가되었습니다. 이에 따라 패킷 변환 작업을 별도의 쓰레드에서 수행할 수 있게 되었으며, SITL에서의 시뮬레이션 수행 속도가 개선되었다고 합니다.
이외에도 여러가지 추가/변경된 사항들이 있지만, 현재 관심이 가는 내용이 아니라서 생략합니다.

OPNET WiMAX 모델은 TMM(Terrain Modeling Module)을 사용하지 않을 경우에 대하여 다음의 4가지 pathloss 모델을 별도로 제공한다.

- Free Space
- Suburban Fixed (Erceg)
- Outdoor to indoor and Pedestrian Environment
- Vehicular Environment

Free Space 모델은 LOS 환경에 대한 것으로 pathloss는 다음의 식으로 계산된다.

Suburban Fixed (Erceg) 모델은 NLOS 환경에 대한 것으로 IEEE Erceg 모델[1]에서 기술하는 pathloss를 적용하는 것이며, 다시 Terrain Type에 따라 A, B, C로 구분된다. 이 pathloss 수식은 shadow fading을 포함한다[2].

Outdoor to indoor and Pedestrian Environment 모델은 NLOS 환경에 대한 것으로 ITU-R M.1225[3]에 정의된 Outdoor to indoor and pedestrian test environment에서 기술하는 pathloss를 적용하는 것이다. 이 모델은 shadow fading에 대한 조건을 포함한다.

Vehicular Environment 모델은 NLOS 환경에 대한 것으로 역시 ITU-R M.1225[3]에 정의된 Vehicular test environment에서 기술하는 pathloss를 적용하는 것이다. 이 모델 역시 shadow fading에 대한 조건을 포함한다.

[1] V. Erceg, etal., "Channel Models for Fixed Wireless Applications," IEEE 802.16.3c-01/29r4, July 2001.
[2] V. Erceg, et al., "An empirically based path loss model for wireless channels in suburban environments," IEEE JSAC, vol. 17, no. 7, July 1999, pp. 1205-1211.
[3] ITU-R Recommendation M.1225, "Guidelines for evaluation of radio transmission technologies for IMT-2000," 1997.

Timeout이 발생하지 않았을 때의 Retransmission Timeout(RTO) 값 계산에 대한 OPNET에서의 구현 방식은 초기 표준[1]을 기본으로 하고, Roud Trip Time(RTT) 값 계산 과정은 Jacobson이 제시한 방식[2, 3]을 따른 것이다. (따라서, 최신 표준[6]에서 설명된 절차와는 약간 차이가 있다.)
즉, OPNET에서 사용하고 있는 RTO 및 Smoothed RTT(SRTT) 계산 절차는 다음과 같다(RTO 계산을 위한 상수값들을 변경하지 않고 "TCP 재전송(1) - RTO 파라미터 설정"에서 설명한 기본값을 사용하였을 때).

여기에서 LBOUND는 "TCP 재전송(1) - RTO 파라미터 설정"에서 살펴본 Minimum RTO 속성값이며, UBOUND는 Maximum RTO 속성값이다.
일반적인 통신망에서 RTT는 수백ms 이내이며, RTTVAR은 RTT보다 훨씬 작은 값을 가진다. 따라서, 대부분의 경우 RTO는 LBOUND에 의해서 결정된다.

[1] RFC 793, "Transmission Control Protocol," IETF, Sep. 1981.
[2] Jacobson V., "Congestion Avoidance and Control," In Proceeding of SIGCOMM '88, ACM, Aug. 1988.
[3] Jacobson V. and M. Karels, "Congestion avoidance and control," LBNL, Nov. 1988.
[4] RFC 1122, "Requirements for Internet Hosts - Communication Layers," IETF, Oct. 1989.
[5] RFC 2988, "Computing TCP's Retransmission Timer," IETF, Nov. 2000.
[6] RFC 6298, "Computing TCP's Retransmission Timer," IETF, Jun. 2011.
[7] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols," In Proceeding of SIGCOMM '87, ACM, Aug. 1987.

Timeout에 의한 TCP 재전송에는 RTO 값이 사용된다. 다음 그림은 OPNET에서 제공하는 RTO 값 계산관련 속성 설정창을 보인 것이다.

각 속성 항목의 용도는 다음과 같다.

- Initial RTO (sec) : RTO 초기값, 기본값은 3초.
- Minimum RTO (sec) : RTO 최소값, 기본값은 1초.
- Maximum RTO (sec) : RTO 최대값, 기본값은 64초.
- RTT Gain : Smoothed RTT(SRTT) 계산을 위한 gain, 기본값은 0.125 이다.
- Deviation Gain : RTT 분산(RTTVAR) 계산을 위한 gain, 기본값은 0.25 이다.
- RTT Deviation Coefficient : RTO 계산시 RTT 분산(RTTVAR) 반영을 위한 계수, 기본값은 4 이다.
- Timer Granularity (sec) : RTT 측정시의 시간 정밀도, 기본값은 0.5초.
- Karn's Algorithm : Karn 알고리즘 적용 여부, 기본값은 Enabled.

다음의 그림은 OPNET WiMAX 모델에서 제공하는 PHY 파이프라인 스테이지 모델의 구조를 기능별 블럭으로 개념적으로 구분하여 나타낸 것으로, 파이프라인 스테이지 코드를 분석하기전에 살펴보면 많은 도움이 된다.

WiMAX 모델의 PHY 기능은 크게 Pathloss, Co-channel interference, Multipath fading의 3가지 블럭으로 나누어진다. Pathloss는 송신자와 수신자 사이에서 발생하는 신호 감쇄로서 IEEE Erceg 모델과 ITU Vehicular/Pedestrian 모델, 그리고 Free Space 모델을 지원한다. 또한 pathloss에는 shadow fading도 포함된다.
Co-channel interference는 동일한 주파수(Sub-carrier)를 사용하는 burst간의 충돌에 의한 신호감쇄로서, 시간/주파수가 얼마나 중첩되는냐에 따라 계산된다.
Multipath fading은 신호가 여러 경로로 수신되는 과정에서 그 합성 신호의 강도가 시공간적으로 변하는 현상이며, 주기적으로 multipath 채널 모델에 따라 그 영향이 새로 계산된다.

OPNET에서는 PPP(Point-to-point protocol)를 위한 별도의 프로세스 모델을 제공하지 않지만, IP 관련 프로세스 모델에서 PPP 기능을 함께 제공한다. 따라서 PPP 링크의 경우 ip 프로세서 모듈에 직접 연결된 point-to-point 송/수신 포트에 접속된다. (point-to-point tx/rx 포트와 point-to-point 링크 모델은 PPP만을 위한 것만이 아님에 유의할 필요가 있다)
또한, PPP를 위한 별도의 패킷 포맷 역시 사용되지 않으며, 단지 PPP 프레임 오버헤드에 해당하는 크기만큼이 IP 패킷 크기에 추가로 적용될 뿐이다. 적용되는 PPP 프레임 오버헤드 크기는 7Bytes이다. 즉, PPP 링크로 전송되는 IP 패킷의 경우 7Bytes(56bits)만큼 패킷의 크기가 증가되어져 사용된다. 다음 그림은 표준[1, 2]에 정의된 PPP 프레임 구조를 나타낸 것이며, 7Bytes는 PPP 프레임 오버헤드의 최소 크기이다. (인터넷상에는 PPP 프레임의 오버헤드가 8Bytes 고정으로 표현된 자료가 많은데, 이는 정확하지 않은 것이다)

다음 그림은 20ms마다 200Bytes 크기의 패킷이 IP 계층에서 발생하였을 때, PPP 링크 모델을 통해 전달되는 트래픽의 크기를 측정한 것이다(비교를 위하여 IP 계층에서 발생된 트래픽의 크기를 함께 나타내었다). 측정된 트래픽의 크기가 82.8Kbps이므로, 개별 패킷의 크기는 82,800 bits/sec * 20 ms / 8 bits/Byte = 207Bytes이다. 즉, PPP 링크를 위한 오버헤드 크기만큼 증가되어져 있는 것이다.

[1] RFC 1661, "The Point-to-Point Protocol (PPP)," IETF, 1994.
[2] RFC 1662, "PPP in HDLC-like Framing," IETF, 1994.

TCP Window Scale option을 사용하면 TCP의 전송률을 크게 증가시킬 수 있음은 "TCP Window Scaling(1) - LFN에서의 동작"에서 살펴보았으며, LFN이 아닌 경우에는 Window Sccaling option을 사용하더라도 TCP 전송률의 개선은 기대할 수 없음을 "TCP Window Scaling(2) - LFN이 아닌 경우의 동작"에서 살펴보았다. 이번에는 Window Scale option을 사용하였을 때 이론적으로 예상되는 성능과 시뮬레이션 결과가 잘 일치하는지를 살펴보기로 한다.
1.544Mbps 대역폭과 513ms의 RTT를 가지는 전송 링크에서 Window Scaling 기능이 적용되지 않는 TCP를 사용할 경우 이론적인 최대 전송율은 1.02Mbps이며, 1.5Mbps의 전송율을 내기 위해서는 100,860바이트의 Window가 필요하다[1, 2].
시뮬레이션을 통해 이 예측을 확인해 보자. "TCP Window Scaling(1) - LFN에서의 동작"에서 사용한 시나리오들에서 대역폭은 DS1(1.544Mbps)로, RTT는 513ms가 되도록 변경한다.
다음은 [1]의 예제에 맞추어 수정된 시나리오에서 Window Scaling 속성을 사용하였을 때와 사용하지 않았을  때의 전송률(throughput)을 비교한 것이다.

Window Scaling을 사용하지 않았을 때는 최대 전송률이 약 1Mbps이고 Window Scaling을 사용하면 1.5Mbps임을 확인할 수 있으며, 이는 이론적인 예측과 일치하는 것이다.

[1] http://en.wikipedia.org/wiki/Window_scaling
[2] http://nenunena.tistory.com/149

SITL 시뮬레이션을 위한 sitl_virtual_gateway_to_real_world 노드 모델은 사용자가 설정할 수 있는 몇가지 속성들을 제공하는데, 그 중 한 가지가 "Incoming Packet Filter String" Attribute이다.

Incoming Packet Filter String 속성은 해당 시뮬레이션에 필요하지 않은 패킷들을 차단하고 필요한 패킷들만을 시뮬레이션에 사용하기 위한 것이며, 필터 기술 방식은 BPF(Berkely Packet Filter) 문법을 따른다.
BPF 문법은 TcpDump[1], WinPCap[2], Wireshark[3] 등에서도 사용되고 있으므로, 해당 도구의 매뉴얼을 참고하여도 된다. 다음은 TcpDump, WinPCap, Wireshark의 필터링 문법에 대한 설명 페이지 이다.

- http://www.tcpdump.org/tcpdump_man.html
- http://www.winpcap.org/docs/docs_412/html/group__language.html
- http://wiki.wireshark.org/CaptureFilters

한가지 주의해야할 사항은 Wireshark의 경우 2 종류의 필터(Capture Filter와 Display Filter)가 사용되고 있으며, 이중 Capture FIlter만이 BPF 문법을 사용한다. 즉, Display Filter에 사용되는 표현은 SITL 패킷 필터에 사용할 수 없다.

[1] http://www.tcpdump.org/
[2] http://www.winpcap.org/
[3] http://www.wireshark.org/