KR100240628B1 - 다자간 멀티미디어 통신에서의 흐름제어 방법 - Google Patents

Abstract

본 발명은 기존의 전송 프로토콜을 대체하기 위한 방법에 관한 것으로, 특히 다자간 멀티미디어 통신에서의 흐름제어 방법에 관한 것이다.

일반적으로 컴퓨터 통신의 흐름제어 방법으로 윈도우 기반 흐름제어 방식과 흐름속도율 기반 흐름제어 방식이 있으나, 이러한 방식들은 송신자와 수신자가 1:1로 연결된 상태에서의 흐름제어 방식이다. 이러한 방식들은 최근 향상되고 있는 전송망의 초고속화와 더불어, 다지점과 다자간의 화상회의등에서 필요한 전송 프로토콜의 흐름제어 방식으로 사용하기에는 적합하지 않은 문제점이 있다.

상술한 문제점을 해결하기 위한 본 본 발명은 윈도우 기반 메카니즘을 기본으로 하고, 흐름속도율 기반 메카니즘을 흐름제어에 병행하여 사용하므로써 다-대-다로 구성된 호스트들의 버퍼영역, 네트워크의 충돌 관리에 사용하며, 데이터의 흐름이 모든 수신자들에서 동일한 수준이 유지되도록 한다.

Description

다자간 멀티미디어 통신에서의 흐름제어 방법

본 발명은 멀티미디어 통신에서 다지점 다자간에 데이터를 전송할 때 송신자와 다수의 수신자들간의 신뢰성있는 데이터 전송 방법에 관한 것으로, 특히 전송 프로토콜의 여러가지 기능중 송신자와 수신자들간의 데이터 처리, 통신 속도 및 상호간의 데이터 저장을 효율적으로 수행하기 위한 버퍼링등 여러 흐름제어 파라미터들을 고려하여 상호간에 신뢰성있는 멀티미디어 통신의 효율을 극대화하기 위한 다자간 멀티미디어 통신에서의 흐름제어 방법에 관한 것이다.

멀티미디어 환경에서 다자간의 통신에 참여하는 사용자는 소스(sources)와 수신자(receivers)로 구성되며, 소스는 자신의 식별자를 가지고 있다. 하나의 소스가 다수의 수신자들과 통신을 시작하기 위해서는 멀티캐스트 그룹을 생성한 후, 수신자들과 데이터를 주고 받게된다.

다지점 다목적지에 존재하는 시스템들간에 멀티미디어 정보를 신뢰성있게 전달하는 방법에는 두가지 접근 방식이 있다. 하나는, 홉바이홉(Hop-by-Hop)으로 라우터등과 같이 네트워크 중간에 여러개가 존재하는 노드들이 포함하여 구성된 통신과 그 신뢰도를 고려한 통신방식과, 다른 하나는 중간 노드들을 고려하지 않고 단-대-단(end-to-end: 예를들어, 소스와 목적지)으로 구성된 네트워크에서 다중화된 멀티미디어 정보를 신뢰성있게 배달하는 방법이다.

이들 접근 방식은 각각 장단점이 있다. Hop-by-hop은 소스(Source)측에서 확인 메시지(ACKnowledge: 이하 ACK라 함) 폭주 문제를 피할 수 있기 때문에 좋지만, 각 중간 노드들은 다음번의 노드에게 데이터를 배달하는 책임을 져야하기 때문에, Hop-by-Hop에서는 재전송과 응답을 반드시 실시하여야 하며, 따라서 각 중간 노드의 상태에 대한 정보가 수시로 필요하고, 이는 곧 멀티캐스트 라우터가 필요하기 때문에 시스템에 사용하는 전송 프로토콜에서는 채택하기가 어렵다.

단-대-단(end-to-end)은 전통적인 OSI 통신모델을 따르며 채택은 쉽지만, 멀티미디어 환경에서 다지점에 존재하는 시스템에서는 흐름제어 과정이 복잡하다.

일반적으로 컴퓨터 통신에서는 데이터 송신측과 수신측간의 처리 속도 및 이를 저장하는 버퍼 크기가 시스템마다 서로 다르다. 이러한 불일치는 송신측의 처리 속도가 수신측의 처리 속도보다 빠를 경우 또는 수신측의 버퍼 크기가 송신측의 버퍼 크기보다 작은 경우에 발생하는 것으로, 수신측에 폭주현상이 발생하여 버퍼 오버플로워(buffer overflow)에 의한 데이터의 손실이 발생하기 때문이다. 흐름제어는 이러한 버퍼 오버플로워를 방지하며 데이터의 손실과 폭주를 방지하고 조절하는 기능을 수행한다. 컴퓨터 통신의 흐름제어에서는 이러한 손실들을 방지하기 위해 윈도우 기반 흐름제어 방식(window-based flow control method)과 속도흐름율 기반 흐름제어 방식(rate-based flow control method)등의 연구가 선행되었다.

윈도우 기반 흐름제어 방식은 송신측과 수신측에서 데이터를 전송하고 수신할 수 있는 데이터의 양을 정하는 방식으로, 일정하게 윈도우를 고정하는 방식과 수신측이 송신측에서 보낸 데이터의 순서 번호를 응답하면, 송신측이 그 응답을 해석하여 적당하게 윈도우를 조정하는 스라이딩 윈도우 흐름제어 방식을 사용한다. 이러한 방식들은 기존의 컴퓨터통신 방식으로, 송신자와 수신자가 하나의 연결을 통해 일정한 윈도우를 정하여 데이터를 송수신하는 환경에서는 사용하기에 무리가 없다. 그러나, 한 개의 송신자와 다수의 수신자 또는 몇 개의 송신자와 다수의 수신자들간에 연결을 설정하고 데이터를 송신하는 환경에서는, 이들간의 데이터의 양과 흐름에 관련된 파라미터들을 계산하여 윈도우를 결정하기에는 많은 과부하가 요구되고, 최대 크기 윈도우에 대한 전송 시간이 왕복 지연 시간(Round Trip Delay: 이하 RTD라 함)보다는 커야 정상적인 운용이 가능하다는 전제 조건을 만족시키기 위해 커다란 윈도우를 필요로 한다. 또한, 초기에 커다란 윈도우를 사용하므로써 폭주, 패킷 손실등을 발생시켜 지속적인 응답(Acknowledge) 패킷을 필요로 하게 된다. 지속적인 응답 패킷을 필요로 하면 항상 일정한 상태를 유지하기 위한 피드백이 요구되어 네트워크에 부하를 증가시켜 많은 전송이 추가적으로 불필요하게 발생하는 단점이 있다.

속도흐름율 기반 흐름제어 방식은 송신측에서 데이터 전송 속도를 정하는 방식으로써, 송신측에서 전송하는 데이터의 전송 속도를 조절하기 위한 패킷 크기, 한번의 전송에 보낼수 있는 패킷의 갯수(burst), 일정한 기간동안 보낼수 있는 버스트등의 파라미터들을 수신측과 상호 교환한다. 일반적으로 이 방식은 소프트웨어로 구현하기 어렵고, 네트워크에서 제공되는 디폴트 파라미터들을 데이터 송수신전에 미리 알아야하며 이들에 대한 정확한 파라미터가 요구되는 단점이 있다.

상기에서 기술한 바와 같은 방식들은 송신자와 수신자가 1:1로 연결된 상태에서의 흐름제어 방식이다. 이러한 방식들은 최근 향상되고 있는 전송망의 초고속화와 더불어, 다지점과 다자간의 화상회의등에서 필요한 전송 프로토콜의 흐름제어 방식으로 사용하기에는 적합하지 않으므로 멀티미디어 정보의 다양화와 대용량화 되어가는 정보통신 환경에 맞는 새로운 흐름제어 방식을 개발할 필요가 있다.

본 발명은 멀티미디어 통신 환경의 다지점 다자간 상호 통신에서 데이터를 신뢰성있게 전송하고, 다자간 통신에서 발생하는 통신 부하를 감소시키며, 또한 전송 프로토콜의 유한 상태 장치(Finite State Machine; FSM)를 시스템에서 구동시켜 운영체제의 측면에서 볼 때 상태 천이기를 운영하기 위해 상하위 레벨의 호스트에게 간단하고 통일된 방법을 제공하는데 그 목적이 있다.

상술한 목적을 달성하기 위한 본 발명은 통신그룹에서 가장 긴 왕복시간을 가진 수신자의 값으로 타이머를 조절한 소스에서 다수의 수신자에게 메시지를 전송하는 제 1 단계와, 상기 메시지를 수신한 다수의 수신자에게 상기 소스에서 확인 메시지 전송을 요구하여 상기 다수의 수신자로부터 확인 메시지를 수신하지 못할 경우 상기 제 1 단계로 천이하는 제 2 단계와, 상기 다수의 수신자로부터 확인 메시지를 수신할 경우 댐핑 기법을 사용하여 확인 메시지를 수신하였는지를 검사하는 제 3 단계와, 상기 제 3 단계의 검사 결과 확인 메시지를 수신하지 못하였을 경우 상기 제 3 단계를 반복하는 제 4 단계와, 상기 제 3 단계의 검사 결과 확인 메시지를 추출하였을 경우 타임스탬프하고 왕복시간을 산출하여 상기 타이머를 조정한 후 윈도우를 이동하는 제 5 단계와, 상기 윈도우 이동후에 소스가 소극적 확인 메시지를 수신하였는지를 검사하여 소극적 확인 메시지를 수신하였을 경우 타이머를 확장하고, 상기 소극적 확인 메시지를 수신하지 못하였을 경우 타이머 기간내에 수신한 소극적 확인 메시지 수가 정해진 문턱값을 초과하였는지를 검사하는 제 6 단계와, 상기 제 6 단계의 검사 결과 정해진 문턱값을 초과하였을 경우 윈도우를 감소시키고, 정해진 문턱값을 초과하지 않고 타이머 간격내에 적은 수의 소극적 확인 메시지를 수신하는 경우 윈도우를 증가시켜 타이머 값을 주기적으로 재조정하는 제 7 단계와, 상기 타이머 값을 주기적으로 재조정하지 않았을 경우 상기 제 5 단계로 천이하는 제 8 단계와, 상기 타이머 값을 주기적으로 재조정한 후, 상기 타이머를 확장한 후, 그리고 상기 윈도우를 감소시킨 후 데이터를 계속 전송하여 더 이상 전송할 데이터가 있을 경우 상기 제 5 단계로 천이하고, 더 이상 전송할 데이터가 없을 경우 종료하는 제 9 단계를 포함하여 이루어진 것을 특징으로 한다.

도 1은 소스와 수신자간의 데이터 흐름 측정을 위한 RTD 샘플링(Sampling) 처리도.

도 2는 본 발명이 적용되는 멀티미디어 통신 시스템에서의 프로토콜 상하위 구조도.

도 3은 본 발명에 따른 다자간 멀티미디어 통신에서 소스와 수신자간의 데이터 흐름도.

＜도면의 주요 부분에 대한 부호 설명＞

11 : 전송 프로토콜 12 : 응용 인터페이스

13 : 커널 14 : 네트워크

15 : 공용 버퍼 16 : 큐

17 : 포맷 수단 18 : 전송 프로토콜 시스템 인터페이스

19 : 분해 수단 20 : 연결 관리 수단

21 : 흐름제어 수단 22 : 에러제어 수단

23 : 유한 상태 장치 24 : 타이머

25 : 버퍼 관리 수단

본 발명에서는 화상회의, 협동작업등 멀티미디어 응용분야를 위한 신뢰성있는 멀티캐스트 트랜스포트 서비스를 제공하기 위해 인터넷 프로토콜(Internet Protocol: 이하 IP) 멀티캐스팅(multicasting) 상에서의 다자간 통신을 위한 트랜스포트 프로토콜의 흐름제어 방식을 제안한다. IP-멀티캐스팅, 인터넷 그룹 관리 프로토콜(Internet Group Management Protocol; IGMP)과 같이 본 발명에서 제안된 전송 프로토콜의 흐름제어 방식에서는 그룹 멤버쉽과 하트비트(heartbeat)의 그룹정보에 대한 취약성을 정의하기 위해 수신자 지향(Receiver-oriented)의 형태를 갖는다. 본 발명에서 제안하는 그룹 멤버쉽 정보의 분산 특성은 확장성(scalability) 보장으로써, 이는 다자간 그룹통신을 실현하기 위한 요구사항중 중요한 하나의 요소이며, 제안된 흐름제어 방식에서의 데이터 흐름은 이를 기반으로 모든 수신자들에게 동일한 수준을 유지하는 방법을 사용한다.

본 발명에서 사용하는 흐름제어 방식은 다-대-다(many-to-many) 버퍼영역, 네트워크의 혼잡 및 충돌(congestion) 관리에 사용하고, 데이터 전송파라미터는 수신자와 소스의 입력을 근거로 조정한다. 단-대-단(end-to-end 또는 peer-to-peer)인 전통적인 흐름제어 방식(유니캐스트 프로토콜)에서는 수신자에서 소스로 필요한 데이터를 입력하는 방식을 사용한다. 그러나, 다수의 수신자(멀티캐스팅 프로토콜)가 존재하는 측면에서 살펴보면, 여러 수신자에서 동시에 단일 소스로의 정보 피드백은 소스에서 과부하를 초래하게 된다. 본 발명에서는 데이터 흐름이 모든 수신자에게 동일한 수준을 유지되도록 한다. 그러므로, 제일 큰 RTD를 갖는 윈도우 기반 (window-based) 메카니즘을 기본 메카니즘으로 하여 흐름속도율 기반(rate-based) 메카니즘을 사용하여 초기화값을 다이나믹하게 조절하는 흐름 제어방식을 병행하여 사용한다.

이하, 첨부된 도면을 참조하여 본 발명을 상세히 설명하기로 한다.

도 1은 소스와 수신자간의 데이터 흐름 측정을 위한 RTD 샘플링(Sampling) 처리 흐름도이다. 흐름제어 알고리즘은 제한적인 단-대-단(end-to-end) 호스트의 버퍼 스페이스와 혼잡한 네트워크에서의 데이터 흐름을 관리하는데 사용된다. 도 1에서는 다-대-다 환경을 단-대-단의 형태로 가정하여 간략하게 표현하였는데, 본 발명에서는 데이터의 흐름이 모든 수신자들에게 동일한 레벨이 유지되도록 한다. 그러므로, 초기에 전송 프로토콜은 흐름제어를 위해 커다란 RTD를 갖는 윈도우 기반(window-based) 메카니즘을 사용하고 데이터 전송 파라미터인 소스(송신자)와 수신자의 입력 파라미터들을 조절하는 속도흐름율 기반(rate-based)을 타이머에 의해 수시로 조절하여 윈도우 값을 점진적으로 줄여 나간다.

도시된 바와 같이 소스는 특정 수신자의 소극적 확인 메시지(Negative ACKnowledge: 이하 NACK)을 수신하여 RTD 샘플을 계산한다. 소스는 제일 열악한 N개의 수신자(N=5)를 위한 RTD를 계산하고, 소스가 NACK을 수신할 때마다 이를 개선한다. 열악한 경우의 RTT 계산은 RTD_max로 표시한다. RTD를 위한 초기값 산정은 지시(indication)가 있는 제일 큰수(large number)로 정하며, 이는 실질적인 (Actual) RTD 샘플에는 아직 도달하지 않은 것이다. 소스는 NACK을 수신할 때 열악한 N개의 수신자에 대한 산출값을 개선하고, RTD 산정이 실질적인 샘플(actual sample)값에 아직 도달하지 않았다는 것을 나타낸다. 소스가 NACK을 전혀 수신하지 못하는 경우에는 망의 단절 및 시스템의 중단등 잠정적인 문제를 갖는 것으로 보고 응용계층에 이를 통보한다.

도 2는 전송 프로토콜이 시스템 내부에 탑재된 상태를 나타낸 것으로, 전송 프로토콜이 들어있는 상태 처리기내의 흐름제어(Flow Control)를 담당하는 부분을 나타내고 있다.

도시된 바와 같이 전송 프로토콜(11)이 중심에 위치하고, 상위측에는 응용 인터페이스(Application Interface: 이하 API라 함)(12)와 연결되고, 하위측에는 커널(13)을 통해 네트워크(14)와 연결된다.

응용계층은 API(12)와 통신하기 위해 공용 버퍼(shared buffer)(15)를 사용하여 큐 리스트(Queue List)를 구성하고, 구성된 큐 리스트를 프로토콜(11)의 큐(16)로 전송한다. 프로토콜 내부에서는 상태 처리기에 의한 통신 절차를 수행하고 포맷(Format) 수단(17)에서 전송할 데이터 패킷을 포맷하여 전송 프로토콜 시스템 인터페이스(TP System Interface)(18)로 보낸다. 전송 프로토콜 시스템 인터페이스(18)의 포맷화된 데이터 패킷은 커널(13)을 통해 네트워크(14)로 전송된다. 네트워크(14)로 전송된 포맷화된 데이터 패킷은 IP-멀티캐스트로 여러 수신자들에게 전송된다. 수신자측에서는 이들 포맷화된 데이터 패킷을 분해(Paese) 수단(19)에서 분해한 후 상위의 전송 프로토콜로 올려 보내면 프로토콜 내부에서는 연결 관리 수단(Connection management)(20), 흐름제어 수단(Flow Control)(21), 에러제어 수단(Error Control)(22), 타이머(Timers)(24), 버퍼 관리 수단(Buffer Management)(25)등 상태처리에 따르는 절차를 수행한 후에 큐 리스트(Queue List)를 만들어 큐(16)를 통해 응용계층으로 전달되는 구조로 구성되어 있다. 연결 관리 수단(Connection management)(20), 흐름제어 수단(Flow Control)(21), 에러제어 수단(Error Control)(22)은 유한 상태 장치(Finite State Machine; FSM)(23)를 구성한다.

연결 설정을 하기 위한 전 단계의 절차로서 시스템 내부에서는 단계적으로 응용 계층에서 프로토콜 내부로 이어지는 순서인 API를 3가지 절차로 수행한다.

프로토콜의 초기화는 응용 계층으로부터 멀티캐스트 어드레스와 포트 넘버를 가져와서 프로토콜을 시동한다. 또한 응용 계층은 소스를 확인하기 위한 단일(unique) ID를 제공한다. 읽기와 쓰기의 순서는 데이터를 교환하기 위해 응용 계층과 API간에 공용 버퍼(shared buffer)를 사용한다. API 쓰기 절차는 응용계층 버퍼로부터 전송 프로토콜의 버퍼로 데이터를 복사한다. 흐름제어 방식은 타이머 및 버퍼링과 많은 연관 관계를 갖는다.

도 3은 본 발명에 따른 다자간 멀티미디어 통신에서 소스와 수신자간의 흐름제어 방법을 설명하기 위한 흐름도이다.

흐름제어 탐색방식은 윈도우(WINSIZE)와 타이머(WTIMER)를 사용하여 WINSIZE(= data bytes)를 WTIMER(timer interval) 동안 전송하며, 프로토콜 알고리즘이 윈도우와 타이머의 간격을 다이나믹하게 조정한다.

소스는 WTIMER를 통신그룹에서 가장 긴 RTT를 가진 수신자의 값으로 선정하고 WTIMER를 조절하여 그 값을 늘이거나 줄여서 근사치의 값을 산출한 후 수신자에게 메시지를 송신한다(301).

여기서, 소스는 WTIMER를 결정하기 위해 수신자가 보내는 하트비트를 사용하며, 전체 수신자의 정보를 이용하여 가장 늦은 수신자를 결정하고, 데이터 전송률은 가장 늦은 수신자가 만족하는 수준에서 유지한다. 그리고 특정 수신자의 NACK을 수신할 경우 RTD 샘플을 계산하는데, 이 계산 방법은 이후 상세히 설명한다.

그리고, 소스는 데이터 패킷을 송신한 후 현재의 시간을 타임스탬프하고, 수신자의 데이터 패킷 수신에 이상이 발생하였을 경우 에러 수정과 흐름제어를 위한 재전송 요구에 대비하기 위해 자신의 버퍼에 데이터 패킷을 저장한다. 이러한 과정은 이후에 상세히 설명한다.

또한, 실제적인 패킷의 전송을 알아보기 위해 세션의 공칭율을 계산하는데, 이것도 이후에 상세히 설명한다.

소스는 메시지를 송신한 후 초기 산출에서 수신자에게 첫 번째 메시지에 대한 명확한 ACK(explicit ACK)을 요구한다(302). 수신자로부터 ACK이 없을 경우 단계 (301)로 천이한다. 이 루틴은 리모트 호스트를 위한 RTD를 계산하고, RTD_max 리스트를 개선한다. 모든 엔트리가 폐기되었으면, 마지막 엔트리는 새로운 엔트리가 더해질 때까지 기다린다.

수신자로부터 ACK이 있을 경우 댐핑(damping) 기법을 사용하여 하나의 ACK을 추출하였는지 검사한다(303). 단계 (303)의 검사 결과 하나의 ACK을 추출하지 못하였을 경우 댐핑 기법을 사용하여 하나의 ACK을 추출한 후(304) 단계 (303)을 재검사한다. 이때, 소스는 응답을 하나만 수신하여 통신 트래픽 부하를 줄이는 것이 바람직하기 때문에 여러 수신자들로부터 동시에 오는 ACK을 단일 ACK으로 줄이기 위해 댐핑(damping) 메카니즘을 사용한다.

단계 (303)의 검사 결과 하나의 ACK을 추출하였을 경우 타임스탬프하고 RTT를 산출하여 WTIMER를 조정한 후 윈도우를 이동한다(305). RTT는 첫 번째 메시지를 송신한 후 산출하며, 그 응답에 대한 수신 시간을 근거로 하여 WTIMER를 조정한다.

단계 (305)를 수행한 후 윈도우 이동후에 소스가 NACK을 수신하였는지를 검사하여(306) 윈도우 이동후에 소스가 NACK를 수신하였을 경우 타이머를 확장한다(307). 이것은 타이머 소멸후에 NACK이 오는 경우로서, 타이머가 RTD보다 짧다는 뜻이다.

단계 (306)의 검사 결과 윈도우 이동후에 소스가 NACK을 수신하지 못하였을 경우 타이머 기간내에 수신한 NACK 수가 정해진 문턱값(threshold)를 초과하였는지를 검사한다(308). 검사 결과 정해진 문턱값을 초과하였을 경우에는, 송신한 패킷이 많다는 것을 의미하므로 WINSIZE를 감소시킨다(309).

단계 (308)의 검사 결과 정해진 문턱값을 초과하지 않고 WTIMER 간격내에 적은 수의 NACKs를 수신하는 경우에는, NACKs수가 문턱값(threshold)을 넘을때 까지 WINSIZE를 점차 증가시켜, WTIMER 값을 주기적으로 다이나믹하게 재조정한다(310). 이는 그룹 멤버쉽이 연결기간(connection lifetime)을 초과할 수 있기 때문이다. WTIMER 값은 NACKs의 수신 또는 명확한 요청(explicit request)을 근거로 계산한다. 단계 (310)을 수행하기 위해 RTD 계산, 타임스탬프 및 세션의 공칭률 계산 방법이 사용되며, 이에 대한 상세한 설명은 이후에 하기로 한다.

단계 (310)을 수행하지 않았을 경우 단계 (305)로 천이하여 단계 (305)로 천이하고 단계 (310), 단계 (307) 및 단계 (309)를 수행한 후 데이터를 계속해서 수신자에게 전송한다(311). 그리고 전송할 데이터가 더 이상 없을 경우(312) 종료하고 그렇지 않을 경우 단계 (305)로 천이한다.

단계 (311)을 수행하는 과정에서 타임스탬프 및 버퍼를 사용한다.

본 발명에서는 윈도우 기반(window-based) 메카니즘을 기반으로 하여 흐름속도율 기반(flow rate-based) 메카니즘을 흐름 제어에 병행하여 사용하는데, 상술한 도 3의 흐름도에서 버퍼관리, RTD 계산, 타임스탬프, 세션의 공칭률 및 불연속 값(α)이 선택적으로 사용된다.

1. 버퍼관리 방법

버퍼관리 구조는 소스에서 불필요한 버퍼를 해제하는 것이다. 이러한 폐영역 회수(garbage collection) 메카니즘은 일정한 시간 간격마다 규칙적으로 발생하며(10T 간격의 비율로 발생), 버퍼가 80%에 도달하면 가동(trigger)된다. 이러한 경우, 응용계층은 버퍼가 차기 시작하는 동안에는 패킷 송신율을 낮추어 메시지를 보낸다.

소스는 데이터 패킷을 일단 송신한 후 수신자의 데이터 패킷 수신에 이상이 발생하였을 경우, 에러 수정과 흐름제어를 위한 재전송 요구에 대비하기 위해 자신의 버퍼에 데이터 패킷을 저장한다.

버퍼 관리 구조는 이를 처리하기 위한 방법으로서 버퍼 스페이스가 급속하게 차오르면 프로토콜을 제어하여 데이터 패킷의 흐름을 조정하며, 이를 위한 감시 메카니즘을 갖는다.

일단 송신된 데이터 패킷은 재전송 대비를 위한 저장을 위해 버퍼 관리자에게 전달한다. 이 데이터 패킷에는 타임스탬프를 부여하여 송신측은 송신한 시간, 그리고 수신측은 수신한 시간을 확인하는데 사용한다.

일정한 시간이 경과하면 데이터 패킷에 부착된 타이머가 가동되어 시간이 경과된 데이터를 버퍼에서 지우게 되는데 이렇게 폐기된 데이터(expired data)는 폐영역 회수(garbage collection) 메카니즘을 이용하여 버퍼에서 제거한다. 즉, 폐영역 회수(garbage collection)는 타이머에 의해 일정한 시간 간격을 갖고 시행되며, 프로토콜이 데이터 패킷을 송신 또는 수신시에 동작한다. 현재 동작하는 프로토콜은 송수신자 양방향간(peer-to-peer)에는 재전송을 하지않고, 송신자가 수신자에게 재전송하는 방법을 사용하여 오버헤드를 피한다.

상술한 버퍼 관리는 3가지 메카니즘으로 구성된다.

첫 번째 메카니즘은 연속적으로 전송되어 오는 데이터 패킷의 시퀀스 넘버를 검출하여 그들간의 갭을 찾는 것으로, 갭이 검출된 경우 수신측에서 NACK을 보내면 송신측은 선택적 재전송(selective retransmission) 방법을 사용하여 이 부분을 재전송한다. 폐영역 회수(garbage collection) 메카니즘은 버퍼 스페이스 사용을 최적화하기 위해 시퀀스 넘버간의 갭을 검출한다.

두 번째 메카니즘은 데이터 패킷들의 시퀀스 넘버간에 갭을 허용하지 않는 방법이며, 데이터가 버퍼안에 들어갈 때마다 폐영역 회수(garbage collection) 메카니즘을 호출하여 버퍼에서 제일 오래된 데이터를 삭제한다. 버퍼에서는 데이터를 삭제하기 위해 현재의 시간(current time)과 데이터 패킷에 부착된 타임 스탬프를 서로 비교한다. 타이머 값이 미리 정해진 문턱값(threshhold) 값을 초과하면 데이터를 삭제한다.

세 번째 메카니즘은 두번째와 유사하지만 차이점은 폐영역 회수(garbage collection) 메카니즘을 새로운 데이터를 저장하기 위해 버퍼 스페이스가 필요할 때만 제거하도록 가동시킨다.

시간마다 프로토콜은 버퍼 관리자를 호출하여 데이터 패킷을 버퍼에 저장한다. 버퍼 관리자는 버퍼 스페이스를 감시하여 항상 버퍼의 저장력을 항상 남겨두도록 한다. 잔여 버퍼 스페이스가 20% 이하로 저장력이 떨어지면, 프로토콜은 데이터의 흐름을 느리게 하기 위해 흐름제어 메카니즘을 가동시킨다.

2. RTD 계산 방법

소스는 수신자가 보내는 하트비트(heartbeat)를 사용하여 WTIMER를 결정한다. 전체 수신자들의 정보를 이용하여 가장 늦은 수신자를 결정하며, 데이터 전송율은 가장 늦은 수신자가 만족하는 수준에서 유지한다.

소스는 특정 수신자의 NACK을 수신할 때 RTD 샘플을 계산한다. 특정 수신자를 위한 RTD는 수학식 1과 같이 계산된다.

소스는 열악한 N개의 수신자(N=5)를 위한 RTD를 산정(estimate)하고, 소스가 NACK을 수신할 때마다 이를 개선한다. 열악한 경우의 RTT 산정(estimate)은 RTD_max로 표시한다. RTD를 위한 초기산정은 지시(indication)가 있는 제일 큰수(large number)로 정하며, 이는 실질적인 RTD 샘플에는 아직 도달하지 않은 것이다.

소스는 NACK을 수신할 때 열악한 N개의 수신자에 대한 산정을 개선하고, RTD 산정(estimate)이 실질적인 샘플(actual sample)에 아직 도달하지 않았다는 것을 나타낸다. 소스가 NACK을 전혀 수신하지 못하는 경우에는 망의 단절 및 시스템의 중단등 잠정적인 문제를 갖는 것으로 보고 응용계층에 이를 통보한다.

3. 타임스탬프(timestamp) 사용방법

패킷을 송신한 후, 소스는 패킷에 현재의 시간을 타임스탬프하고, 재전송을 위해 버퍼에 패킷을 저장한다. 소스는 이 패킷에 대한 재전송 요구가 수신되면, 타임스탬프에 현재의 시간을 기록하여 사용할 때마다 이를 개선하는데, 이 타임스탬프는 소스에서 버퍼 해제시에 종료한다. 특히, 그 현재시간에서 타임스탬프를 뺀 기간이 수학식 2와 같으면 패킷을 해제한다. Go-back-N 재전송 구조가 채택될 때에는 소스 패킷에서 시퀀스만 해제한다.

현재시간-타임스탬프=β × RTD_―max

흐름제어 메카니즘의 신뢰성과 효율을 보장하기 위해 다중(multiple) 타이머를 사용한다. 프로토콜은 정연된 리스트(ordered list) 구조를 사용하여 타이머를 구현한다. 프로토콜에 의해 새로운 타이머가 요구되면, 타이머 관리자는 타이머의 타임 기간을 타이머가 폐기 예정인 실시간 사선(realtime deadline)으로 변환한다. 이 실시간(realtime) 값은 타이머와 콜백(Call-Back; CB) 함수(function)가 결합함에 따른, 타임 값들에 의해 정연된 리스트(ordered list)로 삽입된다.

타이머가 비지않은 리스트(unempty list)를 보면, 리스트에서 첫 번째 타임값을 읽고 실시간 사선(realtime deadline)에서 폐기하기 위해 타이머를 세트한다. 타이머가 폐기될 때 콜백 함수(call back function)를 호출한다. 관리자가 다음 타이머를 스타트하기 전, 현재 실시간(current realtime)이 리스트에서 다음 실시간 사선(next realtime deadline)을 통과하였다면 이를 체크한다. 이러한 경우, 관리자는 리스트내의 엘리먼트와 결합된 콜백 함수(call-back function)를 호출한다. 이러한 처리는 관리자가 사선(deadline)에 도달하지 않은 엘리먼트에 도달할 때까지 계속 실시한다. 이 사선(deadline)은 다음 타이머를 세트할 때 사용한다. 만약 새로운 타이머가 리스트의 상부(head)에 들어가면, 현재(current) 타이머는 정지하고, 새로운 상부(new head) 엘리먼트내에 지시된 사선(deadline)을 가진 새로운 타이머가 스타트한다. 이들 타이머 관리 메카니즘은 다중 타이머로 관리하며, 또한 프로토콜 엔진상의 과부하를 현저하게 줄인다.

4. 세션의 공칭율(nominal rate(r)) 계산

세션의 공칭율을 계산하기 위해 먼저 소스에서의 총 패킷 버퍼의 수(B)를 계산하면 수학식 3에 의해서 구해진다.

B = r × β × RTD_―max

그러므로, 세션의 공칭율(r)은 수학식 4에 의해 구해진다.

이때, 소스의 실제적인 전송은 수학식 5와 같이 계산된다.

T는 소스율(source rate)을 요구한 상태에서 입도 준위(granularity level)로 표시한다. 소스율(R)의 구현 방법은 타이머 크기(timer length)를 T로 세트하고, 적어도 (T x R) 패킷이 타이머 종료시까지 전송되는 것을 체크한다. 타이머 종료에 따라 다시 T를 세트한다.

5. 불연속 값(α) 사용방법

소스가 T 간격동안 패킷을 송신한 후 수학식 2에 의해 타이머 크기를 세트한다. 소스는 5개의 가장 최근의 NACKs의 시퀀스 넘버의 리스트를 유지한다.

1) NACK 수신에 따라, 소스는 가장 최근 NACKs의 리스트를 개선한다. 연속 시퀀스 넘버에 두 개의 NACK이 있을 때는 타이머를 폐기하고, 최근 NACK의 리스트를 지우고 α를 수학식 6과 같이 감소시킨다.

2) 소스는 연속 시퀀스 넘버에서 2 NACK를 수신하지 않으므로 타이머가 종료되면, α는 수학식 7과 같이 증가한다. 이 루틴은 현재의 제한된 값을 증가시키는 기능을 갖는다.

어떤 경우에도, T 간격의 패킷 송신후에는 타이머를 수학식 2에 의해 다시 세트한다. 상기 구조는 혼잡(congestion)을 방지하는 데는 좋으나, 소스로부터 패킷 송신율을 증가시키는데는 느리다. 이 문제를 해결하기 위해 다중 타이머(multiple timer)를 사용한다.

상술한 바와 같이 본 발명에 의한 알고리즘은 컴퓨터통신의 전송 프로토콜에 사용하여 다자간의 신뢰성있는 멀티미디어 데이터의 흐름제어를 가능하게 하고, 전송지연 및 전송망 부담을 최소화시켜 다자간 협동작업에 필요한 멀티미디어 정보를 신뢰성있게 전송할 수 있다.

Claims (7)

1. 통신그룹에서 가장 긴 왕복시간을 가진 수신자의 값으로 타이머를 조절한 소스에서 다수의 수신자에게 메시지를 전송하는 제 1 단계와,

   상기 메시지를 수신한 다수의 수신자에게 상기 소스에서 확인 메시지 전송을 요구하여 상기 다수의 수신자로부터 확인 메시지를 수신하지 못할 경우 상기 제 1 단계로 천이하는 제 2 단계와,

   상기 다수의 수신자로부터 확인 메시지를 수신할 경우 댐핑 기법을 사용하여 확인 메시지를 수신하였는지를 검사하는 제 3 단계와,

   상기 제 3 단계의 검사 결과 확인 메시지를 수신하지 못하였을 경우 상기 제 3 단계를 반복하는 제 4 단계와,

   상기 제 3 단계의 검사 결과 확인 메시지를 추출하였을 경우 타임스탬프하고 왕복시간을 산출하여 상기 타이머를 조정한 후 윈도우를 이동하는 제 5 단계와,

   상기 윈도우 이동후에 소스가 소극적 확인 메시지를 수신하였는지를 검사하여 소극적 확인 메시지를 수신하였을 경우 타이머를 확장하고, 상기 소극적 확인 메시지를 수신하지 못하였을 경우 타이머 기간내에 수신한 소극적 확인 메시지 수가 정해진 문턱값을 초과하였는지를 검사하는 제 6 단계와,

   상기 제 6 단계의 검사 결과 정해진 문턱값을 초과하였을 경우 윈도우를 감소시키고, 정해진 문턱값을 초과하지 않고 타이머 간격내에 적은 수의 소극적 확인 메시지를 수신하는 경우 윈도우를 증가시켜 타이머 값을 주기적으로 재조정하는 제 7 단계와,

   상기 타이머 값을 주기적으로 재조정하지 않았을 경우 상기 제 5 단계로 천이하는 제 8 단계와,

   상기 타이머 값을 주기적으로 재조정한 후, 상기 타이머를 확장한 후, 그리고 상기 윈도우를 감소시킨 후 데이터를 계속 전송하여 더 이상 전송할 데이터가 있을 경우 상기 제 5 단계로 천이하고, 더 이상 전송할 데이터가 없을 경우 종료하는 제 9 단계를 포함하여 이루어진 것을 특징으로 하는 다자간 멀티미디어 통신에서의 흐름제어 방법.
2. 제 1 항에 있어서, 상기 제 1 단계는 상기 소스에서 특정 수신자의 소극적 확인 메시지를 수신할 경우 왕복 지연 시간을 계산하여 가장 긴 왕복 시간을 가진 수신자의 값으로 타이머를 조정하는 단계와,

   상기 타이머를 조정한 소스에서 다수의 수신자에게 데이터 패킷을 송신한 후 상기 소스에서 현재 시간을 타임스탬프하고 버퍼에 데이터 패킷을 저장하는 단계와,

   상기 데이터 패킷을 전송한 후 실제적인 패킷의 전송율을 구하기 위해 세션의 공칭율을 계산하는 단계를 포함하여 이루어진 것을 특징으로 하는 다자간 멀티미디어 통신에서의 흐름제어 방법.
3. 제 2 항에 있어서, 상기 왕복 지연 시간은 하기식에 의해 산정되는 것을 특징으로 하는 다자간 멀티미디어 통신에서의 흐름제어 방법.

   새로 산정된 RTD = RTD 샘플×γ + 이전 산정된 RTD × (1-γ)

   여기서, RTD는 왕복 지연 시간, r은 0과 1사이의 값(1/2)
4. 제 2 항에 있어서, 상기 세션의 공칭율은 하기식에 의해 산출되는 것을 특징으로 하는 다자간 멀티미디어 통신에서의 흐름제어 방법.

   

   여기서, r은 세션의 공칭율, β는 패킷을 해제하기 위한 값, B는 소스에서의 총 패킷 버퍼의 수.
5. 제 2 항에 있어서, 상기 실제적인 패킷의 전송율은 하기식에 의해 산출되는 것을 특징으로 하는 다자간 멀티미디어 통신에서의 흐름제어 방법.

   rate R = (α × r)

   여기서, α는 불연속(discret) 값: 1/16, 2/16, 3/16,…, 15/16, 1.
6. 제 5 항에 있어서, 상기 불연속 값(α)은 연속 시퀀스 넘버에 두 개의 소극적 확인 메시지가 있을 때는 타이머를 폐기하고 최근 소극적 확인 메시지를 지우고 상기 불연속 값을 하기 식 1과 같이 감소시키고, 소스가 연속 시퀀스 넘버에서 두 개의 소극적 확인 메시지를 수신하지 않아 타이머가 종료되면 하기 식 2와 같이 증가시키는 것을 특징으로 하는 다자간 멀티미디어 통신에서의 흐름제어 방법.

   [식 1]

   

   [식 2]

   

   여기서, α는 불연속 값.
7. 제 1 항에 있어서, 상기 제 5 단계는 소스에서 수신자에게 메시지를 송신한 후 왕복시간을 산출하며, 상기 메시지의 응답에 대한 수신시간을 근거로 타이머를 조정하여 윈조우를 이동시키는 것을 특징으로 하는 다자간 멀티미디어 통신에서의 흐름제어 방법.

Images