네트워크 시뮬레이션 공방

Initial ranging이 끝나고 나면 Periodic ranging이 수행된다. 다음 그림은 OPNET WiMAX 모델에서 제공하는 Periodic ranging 절차이다. "WiMAX 모델(75) - Initial Ranging"에서 설명한 것처럼 단말의 프레임 동기가 기지국과
일치하도록 타이밍을 조정하는 절차가 OPNET WiMAX 모델에서는 수행되지 않으며, periodic ranging 절차에서 수행하는 주된 조절 기능도 역시 전력제어이다.

Initial ranging이 완료된 후 T4 타이머가 설정되는데, 이 T4 타이머는 Periodic ranging이 시작되어야 하는 시간을 알려준다. 단말은 T4 타이머가 만료되면, Periodic Ranging 코드 세트에 해당하는 CDMA 코드를 가지는 CDMA 메시지를 선택된 기지국으로 전송하여 periodic ranging 절차를 시작한다. (이 때 CDMA 메시지는 periodic ranging & BR을 위한 자원영역을 사용하여 보내지는데, 이 영역의 위치는 UL-MAP을 통해 기지국으로부터 알려진다.) 메시지를 수신한 기지국은 RNG-RSP 메시지로 응답하는데, 만약 수신 파워가 허용범위 밖이라면 Continue 상태로 응답하여 송신 파워의 조정을 지시하고, 허용범위 이내라면 Success 상태로 응답한다. 단말이 Contiunue 상태의 RNG-RSP 메시지를 받으면, 송신 파워를 조정하여 다시 CDMA 메시지를 기지국으로 전송한다. 단말이 Success 상태의 RNG-RSP 메시지를 받으면, Periodic Ranging 절차를 완료하고, 다음번 Periodic Ranging을 위해서 T4 타이머를 재설정한다.
이러한 과정을 wimax_ss_control 프로세스 모델의 State diagram에서 추적해보면, 다음 그림과 같은 천이 과정을 따른다.

서로 다른 CDMA 코드가 수신된 경우에도, 기지국에서 동시에 검출해낼 수 있는 CDMA 코드 수는 한정적일 수 있다. 예를 들어, Initial Ranging용으로 할당된 CDMA 코드 수가 8개이고, 7개의 단말이 서로 다른 코드를 동시에 전송했을 경우를 생각해 볼 수 있다. 이론적으로는 모두 다른 코드이므로 검출에 문제가 없어야 하겠지만, 실제 디코더의 검출 능력이 4개라면 3개의 코드는 검출되지 않을 것이다. (몇 개가 검출될 것인지는 장비 성능에 따라 다를 것이다.)
OPNET WiMAX 모델에는 이러한 부분이 반영되어 있지 않으며, 코드만 다르면 모두 검출된다. 다르게 말하자면 동시 검출 코드의 수에 제약이 없는 (그렇다고 해도 할당된 CDMA 코드의 수보다 많은 코드가 검출되지는 않을 것이다) 디코더가 사용되고 있다고 볼 수 있다.

OPNET에서 제공하는 정규분포(normal distribution) 함수는 2 개의 인수를 사용한다. 첫 번째 인수는 평균(mean)이며, 두 번째 인수는 분산(variance)이다. OPNET에 정의된 정규분포를 이용하여 noraml(0, 0.2), normal(0, 1.0), normal(0, 5.0), normal(-2, 0.5) 경우에 대한 PDF를 그려보면 다음과 같다. 위키피디아에서 설명하고 있는 정규분포(http://en.wikipedia.org/wiki/Normal_distribution)의 PDF 결과와 정확히 일치하는 것을 알 수 있다.

[1] http://en.wikipedia.org/wiki/Normal_distribution

특정 소스와 목적지간에 백그라운드 트래픽을 ip_traffic_flow 디맨드 모델을 이용하여 간단히 모의하는 방법을 "Background Traffic의 영향(4) - Demand Model"에서 살펴본 바 있다. 이 때 "Traffic Mix" 속성을 All Background로 설정하였었는데, "Traffix Mix" 속성이 시뮬레이션 결과에 어떤 영향을 미치는지 살펴보겠다.
여기에서 백그라운드 트래픽이라는 표현에 대해서 약간의 혼란이 발생할 수 있으므로, 먼저 백그라운드 트래픽에 대한 정의를 짚어보고자 한다. OPNET 시뮬레이션에서 백그라운드 트래픽은 두가지 의미로 사용될 수 있는데, 하나는 주된 관찰 대상인가의 여부에 관한 것이고, 다른 하나는 트래픽을 만들어내는 방법에 관한 것이다.

1) 관찰 대상이 아니라는 의미의 백그라운드 트래픽: 특정 어플리케이션 트래픽의 품질이나 네트워크 장비의 동작 특성을 분석할때, 네트워크에 부가되어 있는 트래픽의 크기에 따라 결과가 달라질 수 있다. 이때, 관찰 대상이 되는 트래픽은 아니지만, 네트워크를 의도한 상태로 만들어주기 위해서 부가하는 트래픽을 의미한다. 이러한 의미로 사용되는 경우가 더 많으며, OPNET에 한정되는 표현은 아니다.

2) 트래픽 생성 방법으로서의 백그라운드 트래픽: OPNET에서만 사용되는 개념이다. OPNET에서 트래픽은 생성 방법에 따라 Explicit(or Discrete) Traffic과 Background Traffic으로 구분된다. Explicit Traffic은 개별 패킷을 직접 발생시켜 트래픽을 구성하는 것이고, Background Traffic은 개별 패킷 생성없이 링크 부하등의 계산에만 트래픽 특성을 반영시키는 것이다. Explicit Traffic 방식을 사용하면 좀 더 정밀한 결과를 얻을 수 있지만, 시뮬레이션 수행시간이 오래
걸린다. Background Traffic 방식을 사용하면 정밀도는 조금 낮아지지만, 시뮬레이션 수행시간을 크게 줄일 수 있다.

본 글은 관찰 대상이 아닌 트래픽(1번 의미)을 생성하는 구체적인 방법(2번 의미)에 관한 것이다. 따라서, 이글에서 지금부터 사용되는 백그라운드 트래픽(Background Traffic)은 2번의 의미로서 사용된 것이다.
"Traffic Mix" 속성은 사용자가 설정해준 트래픽 크기에서 실제로 개별 패킷 발생에 의한  Explicit Traffic의 비율이 얼마인가를 설정하는 것이다. 따라서, 0 (또는 All Background)이면 개별 패킷 생성이 전혀 없이 트래픽이 구성되고, 100 (또는 All Explicit)이면 전적으로 개별 패킷 생성에 의해서 트래픽이 구성된다. 사용자가 임의의 비율을 설정해주는 것도 가능하다.
이 때 유의하여야할 점 한가지는 Background Traffic을 발생시켰을 때와 Explicit Traffic을 발생시켰을 때, 네트워크에 부가되는 트래픽의 크기가 실제로는 조금 다르다는 것이다.
다음 그림은 "Background Traffic의 영향(4) - Demand Model"의 시나리오를 사용하여 Explicit Traffic을 발생시킨후, 그 결과를 Background Traffic인 경우와 비교한 결과이다.

Background Traffic을 사용한 경우보다 Explicit Traffic을 사용한 경우에 더 많은 트래픽이 발생한 것을 알 수 있다. 이러한 현상은 시뮬레이션 엔진이 각각의 트래픽을 취급하는 방법이 다르기 때문에 발행한 것이며, 원하는 트래픽을 정확한 크기로 발생시키기 위해서는 여러번의 시험을 통해 실제로 발생되는 트래픽 크기를 확인하는 것이 필요하다.

Ranging을 수행하는 과정에서 다른 단말과 충돌(Collision)이 발생할 수 있는데, CDMA 메시지(코드)가 충돌하는 경우와 MAC 메시지(RNG-REQ 또는 BW reqeust)가 충돌하는 경우이다.

두 가지 경우의 충돌에 대한 처리는 모두 WiMAX 파이프라인 스테이지에서 수행된다. CDMA 메시지가 충돌한 경우에 충돌한 두 CDMA 메시지의 코드가 동일하다면, 두 메시지의 수신파워를 한 메시지(먼저 수신되는 메시지)로 몰아주고 한 메시지(늦게 수신되는 메시지)의 수신파워는 0으로 만들어 버린다. 즉, 한개의 CDMA 메시지만이 실제로 전달된다. 충돌한 두 CDMA 메시지의 코드가 서로 다른 경우, 두 패킷간에는 아무런 interference도 발생하지 않는 것으로 처리된다.
MAC 메시지(RNG-REQ 또는 BW request)가 충돌하는 경우(이는 CDMA Alloc IE가 단말에 대해서가 아니라 CDMA 코드에 대해서 할당되기 때문에 발생한다), 두 메시지는 서로간에 interference로 작용하며 어느 메시지가 살아남을 것인지의 여부는 각 메시지의 SNR에 의해서 결정된다.

다음 그림은 표준[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

특정 링크에 걸리는 백그라운드 트래픽을 링크 모델의 "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을 살펴보도록 한다. 다음 그림은 우리가 설정해준 크기대로 백그라운드 트래픽이 잘 걸렸음을 보여준다.

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.

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에서 추적해보면, 다음 그림과 같은 천이 과정을 따른다.

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