OPNET WLAN 모델에서 DSSS(Direct sequence spread spectrum) 방식을 사용할 경우 WLAN 프레임의 크기가 우리의 예상보다 훨씬 큰 크기를 가지는 것처럼 보이는 현상이 있으며, 이는 OPNET WLAN 모델을 정확하게 이해하지 못한 사용자들을 종종 혼란에 빠트리곤 한다. 현상을 살펴보기 위해서 다음 그림과 같이 wlan_wkstn 노드 모델과 wlan_server 노드 모델을 이용하여 2개의 노드로 이루어진 시험망을 구성하고, STA1 노드에서 STA2 노드로
전송되는 트래픽을 Custom Application으로 설정해준다. 시뮬레이션 결과의 분석을 간편하게 하기위해서 1,000bytes 크기의 패킷을 1초 간격으로 생성시키며, Transport Protocol로는 UDP를 사용하도록 한다.
wlan_wkstn 노드 모델의 기본 설정값은 802.11b에 해당하는 DSSS, 11Mbps이므로 별도의 설정없이 그대로 사용하여도 된다. 시뮬레이션을 수행하고, STA1 노드 MAC에서의 Load(bits/sec)와 Data Traffic Sent(bits/sec) 항목의 결과를 살펴보면 다음 그림과 같이 상당한 차이가 나는 것을 볼 수 있다. 즉, Load는 8,224bps인데 비해, Data Traffic Sent는 10,560bps나 된다. 우리는 1초마다 1개의 패킷이 발생되도록 설정하였으므로, MAC으로 내려오는 패킷(즉, IP 패킷)의 크기를 8,224bits, WLAN에서 전송된 패킷(즉, PLCP 오버헤드를 포함하는 PHY 프레임)의 크기를 10,560bits로 보아도 무방하며, 그 차이는 2,336bits(292bytes)나 된다.
이렇게 큰 차이가 나는 원인은 무엇이며, 그것은 타당한 것일까? 이를 분석하기 위해서, 일반적으로 예상되는 IP 패킷의 크기와 PHY 프레임의 크기를 살펴보도록 하자. 먼저 예상되는 IP 패킷의 크기를 계산해보면 20bytes(IP Header) + 8bytes(UDP Header) + 1,000bytes(Application Traffic) = 1,028bytes(8,224bits)이며 이는 시뮬레이션 결과와 일치한다.
다음으로, 예상되는 PHY 프레임의 크기를 계산해보면 24bytes(PLCP overhead) + 28bytes(MAC overhead) + 1,028bytes(IP 패킷) = 1,080bytes(8,640bits)이며, 이는 시뮬레이션 결과와 일치하지 않는다. 이렇게 시뮬레이션 결과가 예상치와 차이가 나는 이유는 OPNET이 802.11 WLAN을 모델링하는 과정에서 사용한 접근방법을 고려하지 않고 계산하였기 떄문이다. DSSS 방식의 WLAN에서 PLCP 오버헤드(preamble + header)는 24bytes(192bits)가 맞다. 하지만, 이 오버헤드는 PLCP SDU(즉 MAC 프레임)의 전송 속도와는 상관없이 항상 1Mbps의 속도로 전송된다. 따라서, PLCP 오버헤드의 transmission delay는 192bits/1Mbps = 192us이다.
그런데, WLAN의 wlan_txdel 파이프라인 스테이지를 살펴보면 패킷의 transmission delay를 계산할 때 이러한 PLCP 오허베드 부분의 전송율은 고려하지 않고 다음 그림과 같이 단순히 전체 패킷 크기를 데이터 전송율로 나눠주는 방법을 사용하는 것을 알 수 있다.
따라서, 이러한 차이를 보정해주지 않으면 WLAN 패킷의 transmission delay에 오류가 발생하게 되므로, 보정을 위해서 WLAN 패킷 전송시 PLCP 오버헤드 시간만큼 패킷 크기를 증가시켜서 전송해주는 방법을 사용하고 있으며, 다음 그림은 wlan_mac 프로세서 모델의 wlan_prepare_frame_to_send() 함수에 사용된 PLCP 오버헤드 설정 부분의 한가지 예를 나타낸 것이다.
WLANC_DEFAULT_PLCP_OVERHEAD는 최소 크기의 PLCP 오버헤드를 정의한 것으로 57bits 이다. 이 크기는 다음 그림과 같이 wlan_mac 패킷에 기본으로 이미 포함되어 있으므로 PLCP 오버헤드를 제외한 MAC 프레임의 크기를 구하기 위해서는 wlan_mac 패킷의 크기에서 WLANC_DEFAULT_PLCP_OVERHEAD 크기만큼을 빼주어야 한다.
(사실, 이 계산은 11b에서는 불필요한 것이다)
PLCP_OVERHEAD_DATA() 함수는 데이터 프레임의 PLCP 오버헤드를 계산하기 위한 매크로 함수로 다음 그림과 같이 정의되어 있다. 현재 우리는 DSSS 방식의 802.11b를 시험하고 있으므로, plcp_overhead_data에 저장된 값이 PLCP 오버헤드로 사용된다.
DSSS 방식일 때의 plcp_overhead_data 값은 다음 그림과 같이 지정되며, WLANC_PLCP_OVERHEAD_DSSS_LONG은 192E-06으로 정의되어 있다.
따라서 total_plcp_overhead의 값은 192us가 되며, 이를 11Mbps의 동작속도에 해당하는 데이터크기로 환산하면 192us * 11Mbps = 2,112bits이다. PLCP 오버헤드의 전체 크기가 11Mbps * 192us = 2,112bits(264bytes)인 것처럼 보이는 것은 이 때문이다.
그런데, 앞에서 언급한 바와 같이 wlan_mac 패킷에는 이미
WLANC_DEFAULT_PLCP_OVERHEAD 크기만큼의 PLCP 오버헤드가 포함되어 있으므로, PLCP 오버헤드 시간만큼의 증가분을 정확히 구하기 위해서는 total_plcp_overhead * operational_speed 결과에서
WLNAC_DEFAULT_PLCP_OVERHEAD를 빼주어야만 한다. 따라서 bulk_size = 2,112bits - 57bits = 2,055bits가
되며, 이 크기만큼 wlan_mac 패킷의 크기를 증가시켜서 전송하면 transmission delay 계산상의 문제가 없어지게 된다. op_pk_bulk_set() 함수는 패킷의 크기를 원하는 크기만큼 임의로 증감시킬때 사용하는 함수이다.
이제 physical layer에서 전송되는 패킷의 전체 크기를 다시 계산해보면, 264bytes(PLCP 오버헤드) + 28bytes(MAC 오버헤드) + 1,028bytes(IP 패킷) = 1,320bytes(10,560bits)가 된다. 이는 시뮬레이션 결과와 일치한다. 요약하자면, 실제로 전송된 트래픽량은 1,080bytes이지만, 전송에 사용된 시간은 11Mbps를 기준으로 생각하였을 때, 1,320bytes를 전송할 수 있는 시간이 사용되었다고 볼 수 있을 것이다.