global_perm_data[][] 행렬은 모든 Zone type과 FFT 사이즈에 대한 서브캐리어와 서브채널간 매핑 정보와 주파수 중첩에 대한 정보(overlap matrix)를 저장하기 위한 공간이다.
global_perm_data 행렬의 각 멤버는 CochannelT_zone_perm_data 구조체이며, 이 구조체의 subchannel_map_pointer_array 멤버에 permutation base 별 서브캐리어와 서브채널간 매핑 정보가 저장된다. subchannel_map_pointer_array 행렬의 멤버는 CochannelT_subchannel_map_pointer_array 구조체이며, 이 구조체의 subcarr_to_sub_chan_map 멤버에 해당 permutation base를 사용했을 때 각 서브캐리어가 어느 서브채널에 의해서 사용되는지의 정보가 기록된다. 서브캐리어와 서브채널간 맵핑은 표준[1]에서 정의한 규칙에 따라 각 zone type(DLFUSC, DLPUSC, ULPUSC) 별로 따로 계산된다.
CochannelT_zone_perm_data 구조체의 cum_overlap_pointer_matrix 멤버는 동일한 zone type을 사용하는 섹터들간의 주파수 중첩 정보를 위한 것이며, "WiMAX 모델(120) - Subcarrier overlap matrix"에서 설명한 subcarrier overlap matrix가 cumulative matrix 형태로 저장된다. 이러한 중첩 발생이 가능한 경우의 수는 permutation base의 갯수의 제곱이다.
CochannelT_zone_perm_data 구조체의 cum_overlap_non_data_array 멤버는 서로 다른 zone type을 사용하는 섹터들간의 주파수 중첩 정보를 위한 것이다.

 

 

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

 

Posted by 신상헌
,

Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 Selective Acknowlegment(SACK) 적용 여부를 설정할 수 있는 속성을 제공한다.

 


이 속성에서 선택 가능한 값은 Enabled, Disabled, Passive이다. Passive로 설정되면 상대방(client)에서 SACK 사용을 먼저 요청하는 경우에만 SACK을 사용한다. 즉, Passive는 Server 노드에서만 의미가 있으며, Client 노드가 Passive로 설정되면 Disabled로 설정된 것과 동일하다. 기본값은 17.1 버전까지는 "Disabled", 17.5 버전에서는 "Enabled"이다.

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

TCP ECN Capability(1) - 파라미터 설정  (0) 2015.07.02
TCP SACK(2) - 예제  (0) 2015.06.17
TCP Slow Start 초기값  (0) 2015.05.14
TCP Delayed ACK(3) - Timer Tick  (0) 2015.04.22
TCP Delayed ACK(2) - 예제  (0) 2015.04.17
Posted by 신상헌
,

Riverbed Modeler(OPNET) TCP 모델은 다음 그림처럼 사용자가 Slow Start에서 사용될 Congestion Window의 초기값을 설정할 수 있는 기능을 제공한다.

 


이 속성값은 MSS("TCP MSS" 참조)의 배수를 의미하며, 선택 가능한 값은 1, 2, 4, As defined in RFC-2414 이다. "As defined in RFC-2414"가 선택되면 RFC 2414[1]에 정의되어 있는 다음 수식에 따라 Congestion Window의 초기값을 계산한다.

 

initial window = min (4*MSS, max (2*MSS, 4380 bytes))  (1)

 

RFC 2414[1]는 RFC 3390[2]으로 대체되었지만, initial window 계산 공식에는 변화가 없다.

 

[1] RFC 2414, "Increasing TCP's Initial Window", IETF, Sep. 1998.
[2] RFC 3390, "Increasing TCP's Initial Window", IETF, Oct. 2002.

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

TCP SACK(2) - 예제  (0) 2015.06.17
TCP SACK(1)- 파라미터 설정  (0) 2015.05.22
TCP Delayed ACK(3) - Timer Tick  (0) 2015.04.22
TCP Delayed ACK(2) - 예제  (0) 2015.04.17
TCP Delayed ACK(1) - 파라미터 설정  (0) 2015.04.01
Posted by 신상헌
,

RIP에서 라우팅 테이블을 구성할 때 사용되는 Metric은 네트워크(또는 홉)의 비용(cost)이다[1, 2]. CISCO사의 제품에서는 홉 카운트를 cost로 사용하며[3], Riverbed Modeler(OPNET)의 RIP 모델 역시 이와 동일한 방식을 사용한다.
다음 그림은 Riverbed Modeler(OPNET)에서 제공하는 인터페이스별 RIP Cost 설정창을 보인 것이다. 1 ~ 16 범위의 정수값을 입력할 수 있다.

 


[1] RFC 1058, "Routing Information Protocol", IETF, June. 1988.
[2] http://docwiki.cisco.com/wiki/Routing_Information_Protocol
[3] http://www.cisco.com/c/en/us/td/docs/ios/12_2/ip/configuration/guide/fipr_c/1cfrip.html#wp1000992

Posted by 신상헌
,

다음 그림은 동일한 토폴로지상에 배치된 두 단말사이의 라우팅 경로를 비교하여 나타낸 것이다. 그런데, 사용된 모델 및 파라미터가 모두 동일한데도 불구하고, 두 시나리오에서 선정된 라우팅 경로가 서로 다른 것을 알 수 있다.

 


왜 이런 차이가 발생한 것일까? 그 이유는 두 시나리오에서 토폴로지를 그릴 때, 라우터의 배치 순서가 달랐기 때문이다. 시나리오1에서는 R2를 R3보다 먼저 배치하였고, 시나리오2에서는 R3를 R2보다 먼저 배치하였다. 먼저 배치되었다고 해서 라우팅 경로가 항상 해당 라우터 쪽으로 설정되는 것은 아니다. 다만, 라우팅 프로토콜이 동일한 시간에 동작한다면 먼저 생성(instancing)된 라우터의 라우팅 프로토콜 메시지가 먼저 발생하고(동일한 시간에 발생한 event들도 발생 순서에 따라 처리되는 것은 discrete event simulation의 특성이다), 이웃 라우터에도 먼저 도착하여 처리되므로 동일한 비용을 가지는 경로 들중에서는 우선적으로 선택되는 것이다.

Posted by 신상헌
,

TCP의 Delayed ACK Mechanism이 Segment/Clock Based 방식이고 데이터가 계속 수신되고 있는 상태라면 ACK 메시지는 대부분 Segment 기반으로 (즉, Maximum ACK Segments에 도달하여) 발생되지만, Clock 기반으로 (즉, Maximum ACK Delay에 도달하여) 발생되는 경우도 있다.
실제로 "TCP Delayed ACK(2) - 예제"에서의 결과에서도 200.4초에 송신된 ACK는 Clock 기반으로 발생된 (즉, Maximum ACK Delay에 도달하여 수신 세그먼트 1개에 대한 응답만으로 구성된) 것이다. 단순하게 생각하면 Maximum ACK Delay 시간(200ms)보다 훨씬 짧은 간격(약 100ms)으로 데이터가 계속 수신되고 있으므로, 모든 ACK는 Maximum ACK Segments에 의해 발생되어야 할 것 같은데 왜 이런 현상이 발생한 것일까?
그 이유는 Delayed ACK을 위한 타임아웃 설정은 데이터 패킷 수신 시점을 기준으로 이루어지는 것이 아니라, Maximum ACK Delay 시간 단위(tick)로 이루어지기 때문이다. 따라서, 데이터 패킷을 계속 수신중이라 할지라도 마지막 ACK 송신후 수신된 데이터 패킷의 수가 Maximum ACK Segments에 도달하지 않은 상태(즉, ACK를 보내지 않은 데이터 패킷이 있는 상태)에서 Maximum ACK Delay에 의한 타임아웃 시각에 도달하는 경우가 발생할 수도 있는 것이다.

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

TCP SACK(1)- 파라미터 설정  (0) 2015.05.22
TCP Slow Start 초기값  (0) 2015.05.14
TCP Delayed ACK(2) - 예제  (0) 2015.04.17
TCP Delayed ACK(1) - 파라미터 설정  (0) 2015.04.01
TCP Window Advertisement(2) - 예제  (0) 2015.03.23
Posted by 신상헌
,

"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개의 점이 중복하여 찍혀진 것이다).

 

Posted by 신상헌
,

"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로 계산된다.

Posted by 신상헌
,

지난 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) > Release notes' 카테고리의 다른 글

Riverbed Modeler 18.5.1 발표  (1) 2016.05.02
Riverbed Modeler 18.5.0 발표  (0) 2015.12.02
Riverbed Modeler 18.0.2 발표  (1) 2015.01.05
Riverbed Modeler 18.0.1 발표  (1) 2014.10.15
Riverbed Modeler 18.0 발표  (4) 2014.08.29
Posted by 신상헌
,

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 수.

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

TCP Delayed ACK(3) - Timer Tick  (0) 2015.04.22
TCP Delayed ACK(2) - 예제  (0) 2015.04.17
TCP Window Advertisement(2) - 예제  (0) 2015.03.23
TCP Window Advertisement(1) - 파라미터 설정  (0) 2015.03.01
TCP Receive Buffer  (0) 2015.02.22
Posted by 신상헌
,