다음 그림은 표준[1]에서 정의하고 있는 initial ranging 절차인데([1]의 Table 182 및 Figure J.9 참조), "WiMAX 모델(75) - Initial Ranging"에서 설명한 OPNET WiMAX 모델에 구현된 절차는 이와 일치한다.

 


Initial Ranging에 사용되는 WIMAX_CID_INITIAL_RNG는 wimax_support.h 파일에 0으로 선언되어 있으며, 이는 표준[1]에서 Ranging CID는 0x0000을 사용하도록 정의한 것([1]의 Table 558 참조)과 일치한다.

 

[1] IEEE 802.16-2009, "Air Interface for Broadband Wireless Access Systems", 2009

 

Posted by 신상헌
,

특정 링크에 걸리는 백그라운드 트래픽을 링크 모델의 "Traffic Load(bps)" 속성을 이용하여 손쉽게 모의하는 방법은 "Background Traffic의 영향"에서 살펴보았다. 이번에는 특정 소스와 목적지간에 백그라운드 트래픽을 ip_traffic_flow 디맨드 모델을 이용하여  간단히 모의하는 방법을 살펴보기로 하겠다.
사용할 예제망의 토폴로지는 다음과 같다. "Background Traffic의 영향"에서 사용한 것과 동일한 토폴로지에서 Called_party 노드와 Calling_1 노드간을 ip_traffic_flow 디맨드 모델로 연결한 것이다.

 


이 예제망에서 백그라운드 트래픽은 모든 링크에 흐르게 될 것이다. 설정할 트래픽 양은 GW_1 노드와 ISP_backbone 노드 사이의 링크(DS3) 용량 대비 30%, 50%, 70%이다. ip_traffic_flow의 "Traffic (bits/second)" 속성을 Edit 모드로 선택하여 300sec에서 400sec 사이에 트래픽이 발생하도록 설정해 주었다. 이때 트래픽의 크기는 %가 아닌 bps로 설정되어야 한다. 이 예제에서는 DS3급(44.736Mbps) 링크를 사용하였으므로, 30%, 50%, 70%에 맞추어 13,420,800bps, 22,368,000bps, 31,315,200bps를 설정해 주었다. 다음 그림은 이 과정을 보인 것이다. 이 때 "Traffic Mix" 속성이 All Background로 설정되어 있음을 확인하여야 한다. ("Traffix Mix" 속성의 사용법과 그 영향은 별도의 글에서 다룰 것이다.)

 


이제 각 설정별 시나리오에 대한 시뮬레이션을 수행하고 결과를 비교해보도록 하자. 모든 링크에 대해서 백그라운드 트래픽이 잘 걸렸는지 확인하기 위해서, ISP_backbone 노드와  GW_1 노드 사이, GW_2 노드와 ISP_backbone 노드 사이 링크의 throughput을 살펴보도록 한다. 다음 그림은 우리가 설정해준 크기대로 백그라운드 트래픽이 잘 걸렸음을 보여준다.

 

 

Posted by 신상헌
,

VoIP에 사용되는 코덱들의 최대 MOS 값은 얼마이며, OPNET의 결과값은 이론적인 값과 잘 일치하는지를 살펴보기로 하자. ITU-T P.830 절차에 따른 각 코덱별 MOS 측정 결과가 1997년에 발표된 바 있으며[1], CISCO에서 발표한 결과도 이와 동일하다[2]. 이중에서 요즘 인터넷 전화에서 많이 사용되는 G.711, G.723.1, G.729 코덱의 MOS 값을 정리해 보면 다음과 같다(G.723.1에 대한 결과는 [2]에서만 제공).

 


OPNET의 VoIP 코덱별 최대 MOS 값을 살펴보면, 다음 그림과 같다. (G.711: 4.32, G.723.1: 3.60, G.729: 3.88)

 

[1, 2]에서 발표된 결과와 비교해보면, OPNET은 G.711에서는 약 0.22 높은 값을, G.723.1에서는 약 0.05 낮은 값을, G.729에서는 약 0.04 낮은 값을 보여준다. OPNET의 MOS 결과값은 ITU-T E-model[3]에 의해서 계산되는 것이므로("OPNET 중급입문" 5장 VoIP Application  및 "VoIP MOS 계산" 참조), 실제 측정값과 차이가 있다고 해서 OPNET의 결과값이 잘못되었다고 할 수는 없다. 하지만, ITU-T P.830 절차에 따라 실측한다는 것은 현실적으로 거의 불가능하기에 ITU-T E-model을 사용하는 경우가 많은데, ITU-T E-model 방식에 의한 MOS 결과값과 실측값 사이에는 약간의 차이가 있을 수 있다는 점을 염두에 둘 필요는 있을 것이다.

 

[1] Perkins M.E., Evans K. Pascal D., Thorpe L.A. "Characterizing the subjective performance of the ITU-T 8 kb/s speech coding algorithm-ITU-T G.729," IEEE Communications Magazine, vol. 35, no. 9, pp.74-81, Sep 1997.
[2] http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a00800b6710.shtml#mos
[3] ITU-T G.107, "The E-model, A Computation Model for Use in Transmission Planning," 2011.

'Riverbed Modeler(OPNET) > VoIP Model' 카테고리의 다른 글

MOS와 패킷 손실률의 관계  (0) 2014.12.22
VoIP에서의 Jitter 값 범위  (0) 2014.05.08
VoIP 호 설정 절차(2) - SIP  (0) 2013.09.10
VoIP MOS 계산시 delay 이중 반영 현상  (0) 2013.08.12
VoIP MOS 계산  (0) 2013.07.22
Posted by 신상헌
,

Initial ranging은 단말이 새로운 기지국에 접속하는 과정중 가장 초기에 수행되며, OPNET WiMAX 모델도 이를 지원한다. 하지만, 일반적으로 ranging의 첫번째 목적으로 언급되는 타이밍을 조정(단말의 프레임 동기가 기지국과 일치하도록)하는 절차가 OPNET WiMAX 모델에서는 수행되지 않는데, 이는 항상 모든 노드와의 동기가 일치한다고 가정한 것이라고 볼 수 있다. (이러한 가정을 한 이유는 시뮬레이션에서는 모든 노드의 동기가 일치한다고 가정하는 것이 매우 쉽기도 하거니와, 별도의 동기화 기능을 구현하는데 관심이 없었기 때문이라고 추측된다) 그래서, OPNET WiMAX 모델의 Initial ranging 절차에서 수행되는 주된 조절 기능은 전력제어이다.
다음 그림은 OPNET WiMAX 모델에서 제공하는 Initial ranging 절차이다.

 

Initial ranging은 단말에서 기지국을 선택한 후, Initial Ranging code 세트에 해당하는 CDMA 코드를 가지는 CDMA 메시지를 선택된 기지국으로 전송하면서 시작된다. 메시지를 수신한 기지국은 RNG-RSP 메시지로 응답하는데, 만약 수신 파워가 혀용범위 밖이라면 Continue 상태로 응답하여 송신 파워의 조정을 지시하고, 허용 범위이내라면 Success 상태로 응답한다(이 때에는 CDMA Alloc IE가 이어서 단말에게 전달된다). 단말이 Continue 상태의 RNG-RSP 메시지를 받으면, 송신 파워를 조정하여 다시 CDMA 메시지를 기지국으로 전송한다.
단말이 Success 상태의 RNG-RSP 메시지를 받으면, RNG-REQ 메시지를 전송한다. 이 때 RNG-REQ 메시지는 CDMA Alloc IE에서 할당해준 자원(symbol, subchannel)을 사용한다. RNG-REQ 메시지를 수신한 기지국은 Basic CID를 할당하고, 이를 RNG-RSP 메시지를 통해 단말에게 알려준다. Basic CID를 할당받은 단말은, Initial Ranging 절차를 완료하고, Periodic Ranging을 시작한다.
이러한 과정을 wimax_ss_control 프로세스 모델의 State diagram에서 추적해보면, 다음 그림과 같은 천이 과정을 따른다.

 

 

Posted by 신상헌
,

Piggyback Request(PBR)은 Grant management subheader(GMSH)에 실려서 전송된다. 다음 그림은 GMSH를 포함한 MAC PDU의 예를 표현한 것이다. (표준[1]의 Table 20 및 Figure 46 참조)

 


"WiMAX 모델(72) - Piggybacked BR"에서 설명하였듯이, OPNET WiMAX 모델에서는 GMSH가 실제로 전송되지 않으며 Generic MAC Header(GMH)를 통해서 정보가 전달된다. 대신 GMSH 크기는 GMH에 포함되어 있지 않으며, 별도의 설정을 통해 MAC PDU 크기에 반영된다. GMSH 크기 WIMAXC_MAC_SUBHEADER_GRANT_MGMT_SIZE_BITS는 wimax_support.h 파일에 16비트로 정의되어 있으며, 이는 표준[1]과 일치한다.

 

[1] IEEE 802.16-2009, "Air Interface for Broadband Wireless Access Systems", 2009

 

Posted by 신상헌
,

"WiFi에서의 throughput (5) - 802.11g 최대 throughput"에서 도출한 35.91Mbps의 throughput은 매우 특수한 조건을 가정한 것이며, 일반적으로는 이런 조건에 맞는 환경에서 사용하지 않는다. 이번에는 조금 더 실제 사용환경과 가까운 조건, 즉 대다수의 어플리케이션들이 Transport 프로토콜로 사용하는 TCP를 적용하였을 때 802.11g(54Mbps)에서의 MAC 계층 최대 데이터 전송율을 살펴보기로 한다. 최대 전송율을 구하기 위해서, 여전히 무선환경이 완벽한 상태(BER = 0)에서, 두 개의 무선랜 단말만을 고려한다. 또한, Fragmentation이나 RTS/CTS 메시지를 사용하지 않으며, Propagation delay를 반영하지 않는다.
FTP 데이터를 전송하는데 필요한 오버헤드를 IP 패킷 레벨에서 계산해보면 TCP DATA 패킷과 TCP ACK 패킷, 그리고 이 TCP 패킷들에 대한 DIFS/SIFS, Backoff, MAC DATA/ACK 프레임 오버헤드의 합이며, TCP 전송시 최대 크기인 1,500Bytes 길이의 IP 패킷을 전송할 때의 오버헤드 비율을 계산하면 약 50.45%이다. 따라서 MAC 계층에서 기대되는 전송율(throughput)은 54Mbps * 49.55% = 26.76Mbps이다(충돌이 없다고 가정했을 경우).
이 시뮬레이션을 위해서 "WiFi에서의 throughput(4) - 802.11a TCP throughput"에서 작성한 시나리오를 조금 수정하여 사용한다. 801.11g WLAN을 사용하기 위해서 STA와 AP 노드의 Wireless LAN-->Wireless LAN Parameters-->Physical Characteristics 항목을 "Extended Rate PHY (802.11g)"로 Wireless LAN-->Wireless LAN Parameters-->Data Rate (bps) 항목을 "54Mbps"로 설정한다.이제 시뮬레이션을 수행하고 AP에서 측정된 WLAN MAC throughput을 살펴보면 다음 그림과 같이 약간의 편차가 있기는 하지만, 평균적으로 약 25.2Mbps 정도의 결과를 보여주며, 이는 앞에서 예측한 값과 거의 일치하는 것이다.

 


802.11a에서의 결과값(25.67Mbps, "WiFi에서의 throughput (4) - 802.11a TCP throughput" 참조)보다 조금 낮은 이유는 11g에서 동작 절차가 조금 바뀜에 따라 충돌로 판단하는 경우가 증가하였기 때문이다(즉, 재전송이 증가한다). 코드를 살펴보았을 때, 동작 구조에는 이상이 없으므로 이러한 현상을 OPNET의 버그로 단순히 취급하기는 어렵다. 하지만, 논리적으로 분석하였을 때 11a와 11g의 평균 전송율은 동일해야 하므로, 버그성(?)으로 봐야 할 것 같다.

 

Posted by 신상헌
,

데이터 전송시에 대역폭 요청 메시지를 덧붙여서 전송하는 것을 Piggyback BR이라고 하며, OPNET WiMAX 모델에서도 이를 지원한다. Piggybacked BR 정보가 전달되는 구조는 다음 그림과 같다.

 


MAC PDU의 "MAC Header" 필드에 실리는 WimaxT_Mac_Header_Fields 구조체에는 piggy_back_bw_req 변수가 포함되어 있으며, 여기에 piggyback 방식으로 요청할 BW 크기를 저장하여 전달한다. 또한 type 변수에 piggyback BR을 위한 서브헤더가 포함되었음을 반영하고, MAC PDU 전체 크기에도 서브헤더 크기를 추가한다. 단, 실제로 별도의 서브헤더가 생성되어 전달되지는 않는다.

Posted by 신상헌
,

다음 그림은 표준[1]의 ARQ 재전송 동작 예를 나타낸 것이다([1]의 Figure 48 참조). SDU(상위계층 패킷)은 분할(fragmentation)되거나 packing되어 MAC PDU에 담겨질 수 있으며, 재전송시 재정열(rearrangement)되어 전송될 수 있다.

 


OPNET WiMAX 모델 ARQ에서도 MAC PDU 구성시 SDU 분할과 packing을 지원한다. 하지만, 재정열은 지원하지 않는다. 즉, 재전송은 항상 처음 전송했던 MAC PDU와 동일한 단위로 진행된다. 재정열을 지원하지 않는 주된 이유는 "WiMAX 모델(69) - ARQ 기능"에서 설명하였듯이 송신측 ARQ 버퍼에 MAC PDU 단위로 패킷이 저장되어있기때문인 것으로 생각된다. (물론, MAC PDU 정보를 가공하면 ARQ 블럭별로 재정열하는 것도 가능하지만, 현재에는 구현되어 있지 않다.) 재정열은 송신측에서 결정하는 정책 사항이므로, 재정열을 지원하지 않는다고해서 표준을 위반하는 것은 아니다.

 

[1] IEEE 802.16-2009, "Air Interface for Broadband Wireless Access Systems", 2009

Posted by 신상헌
,

802.11g 무선랜을 사용하는 경우에 있어 실제 데이터 전송율의 최대치는 어느 정도일까? "WiFi에서의 throughput (1) - 802.11b 최대 throughput"과 "WiFi에서의 throughput(3) - 802.11a 최대 throughput"에서 사용했던 것과 동일한 방법을 적용하여 54Mbps의 802.11g를 사용하는 경우(즉, ERP-OFDM을 사용하는 경우)에, MAC 계층에서의 최대 데이터 전송율을 예측하고 시뮬레이션을 통해 확인해보도록 한다.
IP 패킷 하나를 전송하는데 필요한 오버헤드는 DIFS/SIFS, Backoff, DATA/ACK 프레임 오버헤드의 합이며, WLAN에서의 MTU 크기인 2,304Bytes 길이의 IP 패킷을 전송할 때의 오버헤드 비율을 계산하면 약 33.5%이다(11a와 유사하다). 따라서 MAC 계층에서 기대되는 전송율(throughput)은 54Mbps * 66.5% = 35.91Mbps이다. 이 수치는 매우 특수한 조건을 가정한 경우에 한정된 것이며, 일반적으로는 이런 조건에 맞는 환경에서 사용할 일이 거의 없을 것이다.
이제 시뮬레이션을 통해 이 예측을 확인해 보자. "WiFi에서의 throughput (3) - 802.11a 최대 throughput"에서 작성한 시나리오를 조금 수정하여 사용한다. 801.11g WLAN을 사용하기 위해서 STA와 AP 노드의 Wireless LAN-->Wireless LAN Parameters-->Physical Characteristics 항목을 "Extended Rate PHY (802.11g)"로 Wireless LAN-->Wireless LAN Parameters-->Data Rate (bps) 항목을 "54Mbps"로 설정한다. 이제 시뮬레이션을 수행하고 AP에서 측정된 WLAN MAC throughput을 살펴보면 다음 그림과 같이 약간의 편차가 있기는 하지만 평균적으로 35.89Mbps 정도의 결과를 보여주며, 이는 앞에서 예측한 값과 일치하는 것이다.

 


802.11g에서 한가지 더 고려해야하는 사항은 Beacon의 영향이다. 11g에서는 11a보다 큰 크기의 Beacon 메시지가 1Mbps의 매우 느린 속도로 전송되므로, Beacon 오버헤드 또한 무시하기 어려운 수준이 된다. Beacon interval을 20ms로 설정하고 시뮬레이션을 수행해보면 34.5Mbps의 전송율을 보여준다. 즉 Beacon 오버헤드에 의해서 1.39Mbps 정도의 전송율이 감소하는 것이다.

Posted by 신상헌
,

"VoIP 호 설정 절차(1) - No Signaling"에서 살펴본 것처럼, OPNET은 VoIP 호 설정(Call Setup)을 위한 시그날링 프로토콜로 SIP도 지원한다. 다음 그림은 "OPNET 중급입문"의 예제를 수정하여 SIP를 적용한 것으로, VoIP 교환기 역활을 수행하는 SIP 서버가 추가되었다.

 



VoIP 속성 편집창에서 Signaling 프로토콜을  살펴보면 다음 그림과 같이 SIP로 적용되어 있어야 한다.

 

시뮬레이션 수행후 결과를 살펴보면, SIP_Server 노드에서 Active Calls에 대한 결과값으 볼 수 있으며, VoIP Call의 설정과 종료 시점에 SIP_Server 노드에 송수신 트래픽(SIP 시그날링 메시지)이 발생함을 확인할 수 있다.

 

'Riverbed Modeler(OPNET) > VoIP Model' 카테고리의 다른 글

VoIP에서의 Jitter 값 범위  (0) 2014.05.08
VoIP 코덱별 최대 MOS 값  (0) 2013.11.07
VoIP MOS 계산시 delay 이중 반영 현상  (0) 2013.08.12
VoIP MOS 계산  (0) 2013.07.22
VoIP 호 설정 절차(1) - No Signaling  (0) 2013.06.15
Posted by 신상헌
,