네트워크 시뮬레이션 공방

"TCP 재전송(8) - Duplicate ACK"의 시나리오에서 STA 노드에서 송신한 TCP Segment Ack Number와 수신된 TCP Segment Sequence Number를 관찰하면 수신 Segment 2개마다 1개의 Ack가 송신된 것을 볼 수 있는데, 이는 STA 노드의 Maximum ACK Segments 속성의 값이 2로 설정되어 있기 때문이다("TCP Delayed ACK(1) - 파라미터 설정" 참조). 이 시나리오에서는 Server 노드에서 STA 노드로 데이터가 계속 보내지고 있는 상태이기 때문에 Maximum ACK Delay (sec) 속성값에 의한 영향은 거의 관찰되지 않는다.

또한, 이 결과에서 확인할 수 있듯이 패킷 손실로 인하여 중복된 Ack Number를 송신할 때에는 Delayed ACK가 적용되지 않는다(200.07초에 표시된 Sent Segment Ack Number는 실제로는 동일한 값을 가지는 5개의 점이 중복하여 찍혀진 것이다).

"WiMAX 모델(118) - Burst 단위의 동일 채널 간섭 계산"에서 설명한 것처럼, 두 기지국 Burst간의 간섭 정도를 계산할 때는 각 기지국별 Subcarrier-to-subchannel 매핑 정보를 이용하여 간섭이 일어나는 두 기지국 채널들간 subcarrier 중첩여부를 계산해 두고, 이 정보를 이용하여 다수의 채널들로 구성된 Burst간의 간섭 정도를 판단한다.
다음 그림은 1024 FFT OFDMA DL-PUSC를 사용하는 기지국에서 계산된 이웃 기지국(또는 섹터)와 sub-carrier overlap matrix의 예를 보인 것이다. 동일한 1024 FFT OFDMA DL-PUSC 방식을 사용하는 경우라 할지라도 Permutation base가 다르면 subchannel별 subcarrier 할당이 서로 달라지므로, 서로 다른 subchannel간에도 subcarrier 중첩이 발생한다. (즉, PHY Profile이 동일하고 Permutation Base까지 같으면, 같은 subchannel간에만 subcarrier 중첩이 있으며, 다른 subchannel간에는 중첩이 발생하지 않는다.)

위의 그림에서 섹터-1의 subchannel 7은 (간섭을 일으키는) 섹터-2의 subchannel 5와 1개의 subcarrier가 중첩되며, 섹터-1의 subchannel 8은 섹터-2의 subchannel 6과 3개의 subcarrier가 중첩됨을 알 수 있다. 만약 섹터-1에서 subchannel 7 ~ 11을 사용하는 Burst가 섹터-2의 subchannel 5 ~ 7을 사용하는 burst와 중첩된다면, subcarrier로 볼 때 (1+1+1+1+3+2+2+1+2+1+1+1+1+1+1)=20개가 중첩된 것이다.
1024 FFT OFDMA DL-PUSC에서 하나의 subchannel은 24개의 subcarrier를 가지므로 대상 subcarrier의 수는 3 * 24 = 72개이다. 따라서 섹터-1 burst가 겪는 간섭 신호의 크기는 섹터-2 burst 송신 출력의 20 / 72로 계산된다.

지난 4월2일자로 Riverbed Modeler 18.0.3 버전이 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.0.2 발표" 참조).
Release note에 따르면 ZigBee 모델에 대한 기능 개선과 버그 수정(LTE 모델 관련 3건)이 변경된 사항입니다. ZigBee 모델 개선 사항은 다음과 같습니다.

- Applicaiton layer enhancements
- Packet fragmentation and re-assembly
- Link status reporting and asymmetric link avoidance in mesh routing
- Frequency agility
- ZigBee IP gateway
- Support for ASES encryption

Applicaiton layer enhancements는 ZigBee 네트워크를 통해 전송된 패킷된에 대한 어플리케이션 계층 Ack를 사용할 수 있게 되었다는 것입니다. Packet fragmentation and re-assembly 역시 어플리케이션 계층에 대한 것으로 패킷 분할과 재조립이 이제 지원된다는 것입니다. Link status reporting and asymmetric link avoidance in mesh routing은 품질이 좋은 링크를 경로 선정에 사용할 수 있도록 링크 비용에 대한 정보를 이웃 노드들과 교환하는 기능이 ZigBee 라우터/코디네이터 노드에서 지원된다는 것입니다.
Frequency agility는 현재의 무선 채널이 혼잡할 경우 새로운 채널로 자동으로 옴겨가는 기능입니다. ZigBee IP gateway는 ZigBee 노드와 IP 네트워크간의 통신을 위해 새로 추가된 2개의 노드 타입에 대한 것입니다. Support for ASES encryption는 AES-128과 유사한 암호화/인증 메커니즘인 CCM을 ZigBee 어플리케이션 계층과 네트워크 계층에서 사용할 수 있게 되었다는 것입니다.
이외에 ZigBee 모델의 일부 속성의 기본값과 결과 수집항목의 기록 방식이 변경되었다고 합니다.

그리고, 지난 18.0.2 버전의 변경사항도 이번 release note에 추가로 설명되었습니다. LTE 모델에서 DRX in Conneted Mode에 대한 몇 가지 속성 및 동작이 변경되었다고 합니다. (DRX in Conneted Mode에 대해서는 "OPNET Modeler 17.5 PL3 발표" 참조)

Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 Delayed ACK를 설정할 수 있는 속성들을 제공한다.

- Delayed ACK Mechanism : Delayed ACK 발생 방식을 지정. Clock Based 방식과 Segment/Clock Based 방식이 선택 가능하다. 선택된 방식에 해당하는 기준을 넘어서면, 해당 방향으로 전송할 데이터가 없더라도 ACK 패킷을 전송한다. (해당 방향으로 전송할 데이터가 있으면 ACK는 piggyback 방식으로 전달된다) 즉, 데이터없이 전달되는 ACK이므로 dataless ACK라고도 한다.

- Maximum ACK Delay (sec) : ACK를 보내기 전에 기다리는 최대 지연 시간.

- Maximum ACK Segments : ACK를 보내기전에 기다리는 최대 수신 segment 수.

"TCP Window Advertisement(1) - 파라미터 설정"에서 살펴본 것처럼 "Receive Buffer Usage Threshold (of RCV BUFF)" 속성의 기본값은 0.0 이며, 항상 수신 버퍼 크기 전체가 수신 가능 윈도우 크기로 사용된다. "TCP Window Scaling(3) - 예제"의 시나리오에서 TCP Conneciton-->Remote Receive Window Size (bytes) 결과를 Server 노드에서 관찰하면 Receive Window가 항상 일정한 것은 이 때문이다.

이는 Window XP나 Window 7과 같은 현재의 일반적인 운영체계에서는 맞지 않다. 다음은 Wireshark를 이용하여 64,512바이트의 수신 버퍼를 사용하는 Windows XP 시스템에서 내보내는 Advertisement Window 값을 관찰한 것이다. 수신 버퍼 전체 크기가 항상 Advertisement Window 값으로 사용되지는 않는다는 것을 확인할 수 있다.

Advertisement Window 크기에 변화를 주기위해서 다음과 같이 STA 노드의 "Receive Buffer Usage Threshold (of RCV BUFF)" 속성값을 변경한다. (여기에서 0.1은 예를 들기 위해 임의의 값을 선택한 것이며, 대상 시스템에 따라 값이 달라질 수 있다.)

시뮬레이션을 수행한 후, Receive Buffer Usage Threshold가 0.0인 경우와 0.1인 경우에 대해 Server 노드에서 수신된 수신 가능 윈도우 크기를 살펴보면 다음과 같다. 수신 가능 윈도우 크기가 59,095 ~ 65,535바이트로 시간에 따라 변화하였음을 확인할 수 있다.

Riverbed Modeler(OPNET) SITL 모듈을 사용하면 Riverbed Modeler(OPNET) 시뮬레이터와 실세계 장비를 연결하는 SITL 게이트웨이 노드(sitl_virtual_gateway_to_real_world)에서는 시뮬레이션 패킷과 실세계 패킷 간의 변환이 일어난다. 이 때 OPNET 17.5 PL5 버전("OPNET Modeler 17.5 PL5 발표" 참조)을 기준으로 SITL에서 패킷 변환이 지원되는 프로토콜 및 관련된 Riverbed Modeler(OPNET) 패킷 포맷은 다음과 같다. IPv6, ICMPv6, IGMPv2, WLAN 프로토콜에 대한 지원은 15.0 PL0 버전에서, BGP 프로토콜에 대한 지원은 17.1 PL1 버전("OPNET Modeler 17.1 PL1 발표" 참조)에서 추가된 것이다.

- Ethernet : ethernet_v2
- ARP : arp_v2
- IPv4 : ip_dgram_v4
- IPv6 : ip_dgram_v6
- ICMPv4/v6 : ip_icmp_echo
- IGMPv2 : ip_igmp
- TCP : tcp_seg_v2
- UDP : udp_dgram_v2
- RIPv1/v2 : rip_message2
- OSPFv2 : ospf_hello_v2, ospf_dbase_desc_v2, ospf_ls_request_v2, ospf_ls_update_v2, ospf_ls_ack_v2
- BGP : bgp_keepalive_packet, bgp_notification_packet, bgp_open_packet, bgp_update_packet
- WLAN : wlan_mac

이외에 SITL에서 패킷 변환을 지원하지 않는 프로토콜 패킷에 대한 전달이 요구되는 경우에는 unformatted 패킷을 사용하여 변환되지 않은 형태로 전달한다.

"ptime"은 SDP atribute중 하나로써, 한개의 RTP 패킷에 담겨있는 미디어 정보의 재생시간을 의미한다[1, 2]. 그런데, Riverbed Modeler(OPNET)의 SIP 모델에는 ptime 설정에 관련된 속성항목이 없으므로, Riverbed Modeler(OPNET)에서는 ptime을 직접 설정해줄 수 없다.
따라서, ptime에 관련된 시뮬레이션 수행시에는 일부 제약 사항이 발생한다(Ex: 송/수신자간의 ptime 협상과정 진행에 관련된 사항들은 시뮬레이션 할 수 없음). 하지만, RTP 패킷에 실리는 정보의 양을 지정하기 위한 속성항목들을 별도로 제공하고 있으므로, 설정된 ptime 값에 의한 효과를 시뮬레이션할 때에는 문제가 없다(Ex: ptime에 따른 트래픽 발생량이나 MOS 변화는 시뮬레이션 가능).

[1] M. Handley, V. Jacobson, C. Perkins, "SDP: Session Description Protocol," RFC 4566, IETF, Jul. 2006.
[2] S. Casner, "Media Type Registration of RTP Payload Formats," RFC 4855, IETF, Feb. 2007

OPNET WiMAX 모델에서 동일 채널 간섭(Co-channel interference)은 Burst 단위로 계산되며, 이 Burst는 OPNET에서 패킷으로 표현된다. (Burst가 패킷으로 어떻게 표현되는지에 대해서는 "WiMAX 모델(59) - IE Type4에서의 sub-burst 분할"과 "WiMAX 모델(61) - UL-MAP IE 정보"참조) OPNET WiMAX Burst는 주파수 자원에 대한 할당정보(subchnl_start, subchnl_count)를 가지고 있으며, 이 정보를 이용하여 동일 주파수 대역을 사용하는 이웃 기지국(섹터) Burst와의 간섭 정도를 계산한다. 이 때, 동일 주파수 대역을 사용한다고 하더라도, Permutation Type과 Permutation Base에 따라 각 채널(Sub-channel)에서 사용하는 서브 캐리어(Sub-carrier)는 서로 상이할 수 있다. 따라서, 각 기지국별 Subcarrier-to-subchannel 매핑 정보를 이용하여 간섭이 일어나는 두 기지국 채널들간 subcarrier 중첩여부를 계산하고, 이 정보를 이용하여 다수의 채널들로 구성된 Burst간의 간섭 정도를 계산한다.

"TCP Receive Buffer"에서 살펴본 것처럼 Riverbed Modeler(OPNET) TCP 모델은 사용자가 수신 버퍼 크기를 설정할 수 있는 속성들을 제공한다. 이 때 수신 버퍼와 관련하여 Riverbed Modeler(OPNET) TCP 모델에서 제공하는 속성이 한 가지 더 있는데, 바로 "Receive Buffer Usage Threshold (of RCV BUFF)"이다.

"Receive Buffer Usage Threshold (of RCV BUFF)" 속성 값은 상위(응용) 계층으로 데이터를 넘겨주는 기준 비율을 의미한다. 0.0 ~ 1.0 범위의 값으로 설정할 수 있으며, 수신 버퍼에 쌓인 데이터가 이 비율에 도달하면 이 비율에 해당하는 크기의 데이터는 즉시 상위 계층으로 넘겨준다고 가정된다.
따라서, 송신측에게 알려줄 수신 가능 윈도우(Advertisement Window) 크기는 "TCP Receive Buffer"에서 산출된 수신 버퍼 크기와 이 ""Receive Buffer Usage Threshold (of RCV BUFF)" 비율에 의해 시뮬레이션 시간동안 지속적으로 재계산된다. 기본값은 0.0이며, 항상 수신 버퍼 크기 전체가 수신 가능 윈도우 크기로 사용된다.

수신 버퍼(Receive Buffer)는 TCP 흐름제어를 위한 RWIN 값으로 사용되며, Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 수신 버퍼를 설정할 수 있는 속성들을 제공한다.

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

- Receive Buffer (bytes) : 수신 버퍼 크기. 수신 버퍼 크기를 직접 명시하는 방법외에 Default로 설정할 수도 있다. Default로 설정되어 있으면, MSS("TCP MSS" 참조)의 4배로 계산된다. 17.1 PL2 버전 이상에서는 Auto-Tuning으로 설정하는 것도 가능하다("OPNET Modeler 17.1 PL2 발표" 참조).
- Receive Buffer Adjustment : 수신 버퍼 크기를 MSS의 배수로 조정할 것인지의 여부를 지정. None, Windows Based, Solaris Based 세 가지가 선택 가능하다. None이면 수신 버퍼 크기를 조정하지 않고 사용한다. Windows Based이면 MSS의 짝수배로 조정한다. Solaris Based이면 MSS의 배수로만 조정한다.

"Receive Buffer Usage Threshold (of RCV BUFF)" 항목은 송신측에 알려줄 수신 가능 윈도우(Advertisement Window) 계산에 관련된 것이므로 이후의 글에서 다시 자세히 살펴보겠다.