GRP는 목적지 노드까지 전달 가능한 것으로 확인된 경로를 사용하여 다음 홉을 결정하는 것이 아니라, 쿼드런트("GRP 쿼드런트" 및 "GRP 쿼드런트 레벨" 참조) 개념을 기반으로 가장 거리가 짧을 것으로 예상되는 경로상에 위치한 노드를 다음 홉으로 사용한다. 따라서, 데이터 패킷을 전달받은 중간 노드에서 실제로는 목적지 노드로 전달할 경로가 존재하지 않거나, 적절한 경로를 찾을 수 없는 경우도 발생한다. 이런 경우에 데이터 패킷을 폐기하지 않고 다른 경로를 찾도록 하는 기능이 Backtrack이다. GRP의 Backtrack 기능은 노드 속성편집창에서 활성화/비활성화 여부를 설정할 수 있다.
ICMP 패킷 역시 다른 IP 패킷과 동일하게 목적지 검사("IP 패킷 목적지 검사" 참조)와 TTL 처리("IP 패킷 TTL 처리" 참조) 절차를 거친다. IP 패킷 목적지를 검사한 결과 해당 노드가 목적지이고 IP 패킷의 프로토콜 타입이 ICMP이면, 해당 IP 패킷은 ICMP 패킷을 담당하는 프로세스로 전달된다. 다름 그림은 이러한 ICMP 패킷에 대한 처리 절차를 나타낸 것이다.
"라우팅 테이블과 포워딩 테이블"에서 설명한 것처럼, Riverbed(OPNET) Modeler에서 라우팅 테이블과 포워딩 테이블은 (비록 비슷한 정보가 저장된다 할지라도) 구분된다. 두 테이블의 유사점과 차이점을 "RIP 라우팅 예제"에서 사용한 예제망을 통해 확인해 보기로 하자.
이 예제망에 실제로 할당된 IP주소 내역은 다음과 같다.
시뮬레이션을 수행한 후, R1 노드에서 구성된 라우팅 테이블과 포워딩 테이블을 비교하여 살펴보면 다음 그림과 같다. ("RIP 라우팅 예제"에서는 아래의 포워딩 테이블을 라우팅 테이블 정보를 살펴보기위해서 사용하였지만, 정확하게 말하자면 포워딩 테이블이다).
정보의 항목 수에서는 조금 차이가 있지만, 저장되어 있는 정보의 내용은 동일한 것을 알 수 있다. 또한, 일반적인 예상(?)과는 달리, 포워딩 테이블이 라우팅 테이블보다 더 많은 정보 항목으로 구성되어 있음도 확인할 수 있다.
다음 그림은 수신 버크 크기 자동 조정 기능이 실제로 잘 동작 하는지를 확인하기 위하여 "TCP Window Scaling(1) - LFN에서의 동작"에서 사용한 시나리오를 수정한 시험망 토폴로지를 나타낸 것이다. STA 노드에서 Discarder_1 노드로 향하는 링크의 전송속도를 512K, DS1, OC3로 변경해가며 시뮬레이션을 수행하였으며, 이는 "TCP Receive Buffer(2) - Auto-Tuning"에서 살펴본 것처럼, 수신 버퍼 크기가 BDP(Bandwidth Delay Product) 크기에 의해 결정되기 때문이다.
시뮬레이션을 수행한 후, Server 노드에서 측정된 Remote Receive Window Size (bytes) 결과 항목의 값을 살펴보면 다음 그림과 같다.
150초 무렵에 데이터 전송이 시작된 후, 수신측(STA 노드)의 버퍼 크기가 점차 증가하는 모습을 명확히 확인할 수 있다. 또한, 수신측(STA 노드)의 BDP가 클수록 수신 버퍼 크기의 최대값도 크다는 것도 알 수 있다.
"WiFi 모델에서의 통신 가능 거리(5) - MAC Throughput(1)"에서는 802.11b 11Mbps 환경에서 237Bytes 크기의 MAC 사용자 패킷을 전송할 때, MAC 사용자 계층의 패킷 전달률 관점에서 최대 통신 가능 거리는 어디까지인지를 살펴보았다. 이번에는 동일한 크기(237Bytes)의 MAC 사용자 패킷을 802.11g 24Mbps 환경에서 전송할 때, MAC 사용자 계층의 패킷 전달률 관점에서 최대 통신 가능 거리는 어디까지인지를 살펴보기로 하자. Riverbed(OPNET) WiFi 모델에서 802.11g 24Mbps로 데이터 전송시 사용되는 MCS 레벨은 QAM16 1/2이며("WiFi MCS 레벨 (17.5 PL6 버전)" 참조), Processing Gain은 MCS 레벨에 의한 -3.01dB와 OFDM에 의한 2.28dB이다("WiFi MCS 레벨 프로세싱 게인 (17.5 PL6 버전)" 참조). Riverbed(OPNET)에서 사용하는 QAM16 1/2 MCS의 BER 커브는 다음 그림과 같다.
237Bytes의 MAC SDU 패킷을 전송할 때 송신 포트에서 내보내는 패킷의 크기는 237Bytes(MAC SDU 패킷) + 28Bytes(MAC 오버헤드) + 23.67usec * 24Mbps(PLCP 오버헤드) / 8 = 336Bytes(2,688bits)이다. (PLCP 오버헤드 계산에 대해서는 "WLAN PLCP 오버헤드 크기" 및 "WiFi에서의 throughput (5) - 802.11g 최대 throughput" 참조) MAC에서의 최대 전송 횟수는 기본값인 7이 적용된다. 이상의 정보로부터 BER별 MAC 사용자 패킷 전달률(Throughput)과 최대거리(distance)를 계산해보면 다음과 같이 예상할 수 있다.
- BER이 1.2x10^-4 일 때: MAC 사용자 패킷 전달률 99.99%, 이 때의 SNR은 9.53dB이므로 최대 거리는 약 788M. - BER이 4.1x10^-4 일 때: MAC 사용자 패킷 전달률 93.92%, 이 때의 SNR은 9.03dB이므로 최대 거리는 약 834M. - BER이 7.9x10^-4 일 때: MAC 사용자 패킷 전달률 59.26%, 이 때의 SNR은 8.73dB이므로 최대 거리는 약 864M. - BER이 3.9x10^-3 일 때: MAC 사용자 패킷 전달률 0.02%, 이 때의 SNR은 7.93dB이므로 최대 거리는 약 947M.
이제 시뮬레이션을 통해 이 예측을 확인해 보자. 2대의 WLAN 터미널 스테이션 노드를 배치하고, Physical Characteristics은 "Extended Rate PHY (802.11g)"로, Data Rate (bps)는 "24Mbps"로 설정한다. 트래픽은 237Bytes 크기의 패킷을 1초마다 발생시켜 다른 WLAN 터미널 스테이션 노드로 전송하도록 설정하였다. 788M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 99.99%)과는 미세한 차이가 있는 결과(전달률 100%)이나, 오차범위 내로 볼 수 있다.
다음으로 834M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 93.92%)과는 미세한 차이가 있는 결과(전달률 약 93.25%)이나, 오차범위 내로 볼 수 있다.
다음으로 864M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 59.26%)과는 미세한 차이가 있는 결과(전달률 약 57.50%)이나, 오차범위 내로 볼 수 있다.
다음으로 947M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 예측(전달률 0.02%)과는 미세한 차이가 있는 결과(전달률 약 0.25%)이나, 오차범위 내로 볼 수 있다.
OSPF Model에서 실제로 Hello 메시지가 전송되는 간격은 Hello Inteval 값과 정확히 일치하지 않는다("Hello Interval" 참조). 다음은 이를 확인하기 위하여 "Hello Interval" 예제에서 실제로 Hello 메시지가 송신된 간격을 표로 정리한 것이다.
간격이 계속 변화하며, 그 값이 10초(Hello Interval 속성 값)보다는 약간 큰 것을 알 수 있다. 이렇게 Hello 메시지 간격이 지정된 Hello Interval 값보다 큰 이유는 Riverbed(OPNET) Modeler OSPF Model에는 Hello Jitter 시간이 추가로 반영되어 있기 때문이다. Hello Jitter 값을 17.5 PL6 버전("OPNET Modeler 17.5 PL6 발표" 참조)까지는 사용자가 변경할 수 없으며, 18.0 버전("Riverbed Modeler 18.0 발표" 참조)부터는 GUI를 통해 변경할 수 있다. 다음 그림은 Riverbed(OPNET) Modeler 18.7.0 버전("Riverbed Modeler 18.7.0 발표" 참조)에서 제공하는 Hello Jitter 설정창을 보인 것이다. 입력값은 Hello Interval에 대한 비율을 의미한다.
고정 할당 방식에서도 노드별로 슬롯 수를 다르게 할당할 수 있다. 즉, 전송량이 많은 노드에는 슬롯을 많이 할당해주고, 전송량이 작은 노드에는 적게 할당해줄 수 있다. "TDMA 예제(1) - 균등 고정 할당"의 예제에서 STA_3 노드에는 필요한 양보다 작은 수의 슬롯이 할당되었기 때문에, STA_3 노드에서 STA_4 노드로 향하는 트래픽이 제대로 전달되지 못했다. STA_3 노드에 더 많은 슬롯을 할당해주어 이 문제를 해결할 수 있음을 확인해보기로 하자. 다음 그림은 이를 확인하기 위한 TDMA 예제망 구조를 보인 것이며, "TDMA 예제(1) - 균등 고정 할당"의 예제망 구조와 동일하다.
TDMA 프로파일로는 Default를 사용하였으며, 이 때 사용할 수 있는 44개의 데이터 슬롯을 STA_1 노드에 11개, STA_2 노드에 8개, STA_3 노드에 14개, STA_4 노드에 11로 나누어 할당하였다. Default TDMA 프로파일일 경우, 프레임("TDMA 프레임 구조" 참조) 길이는 100ms이고 슬롯당 데이터 전송량은 200Bytes이므로 14개의 슬롯을 할당받은 STA_3 노드의 최대 전송량은 224Kbps(= 200 Bytes * 8 bits/byte * 14 slots/frame * 1 / 0.1 frames/sec)이다. STA_3 노드에서 STA_4 노드로 향하는 트래픽의 양은 200Kbps이므로, 이번에는 STA_4 노드로 모두 전달될 것이다. 시뮬레이션을 수행한 후, 각 노드에서 할당받은 프레임당 슬롯수를 살펴보면 다음 그림과 같다. 설정해준 것처럼 STA_1 노드와 STA_4 노드가 11개, STA_2 노드가 8개, STA_3 노드가 14개의 슬롯을 매 프레임 할당받은 것을 알 수 있다.
STA_1 노드에서 STA_2 노드로 향한 트래픽의 송수신량을 살펴보면 다음 그림과 같다. STA_1 노드에서 발생한 트래픽이 STA_2 노드로 모두 전달되었음을 보여준다.
STA_3 노드에서 STA_4 노드로 향한 트래픽의 송수신량을 살펴보면 다음 그림과 같다. STA_3 노드에서 발생한 트래픽(200Kbps)도 STA_4 노드로 모두 전달되었음을 보여준다.
쿼드런트의 계층개념은 "GRP 쿼드런트 레벨"에서 살펴보았다. 여기에서는 예제를 통해 이를 확인해보기로 하자. 예제를 위한 시험망은 "GRP 쿼드런트 예제"의 예제망을 확장하여 사용하였다.
"GRP 쿼드런트 예제"에서 언급하였듯이, 쿼드런트는 좌표계를 기준으로 결정되므로, 시나리오상의 노드 배치를 보고 쿼드런트의 경계를 직접 파악하기는 매우 어렵다. STA_1, STA_8, STA_12, STA_16 노드에 구성된 목적지 테이블 정보로부터 각 노드에서 사용한 쿼드런트를 파악해보면 다음 그림과 같다.
쿼드런트가 "GRP 쿼드런트 레벨"에서 설명한 것처럼 계층적으로 적용되고 있음을 확인할 수 있다. 즉, 대상 노드들의 위치에 따라 하위 레벨 쿼드런트와 상위 레벨 쿼드런트가 사용되고 있으며, 상위 레벨 쿼드런트는 하위 레벨 쿼드런트 4개에 해당하는 면적을 가지고 있다.
