KR20080068024A

KR20080068024A - 다자간 오디오-비디오 컨퍼런싱을 위한 애플리케이션-레벨라우팅 프로토콜의 방법, 컨퍼런싱 엔진 및 시스템

Info

Publication number: KR20080068024A
Application number: KR1020087009374A
Authority: KR
Inventors: 총 루오; 지앙 리
Original assignee: 마이크로소프트 코포레이션
Priority date: 2005-10-19
Filing date: 2006-10-17
Publication date: 2008-07-22
Also published as: EP1938515B1; WO2007047696A2; EP1938515A2; US8243630B2; EP1938515A4; WO2007047696A3; US20070086366A1; KR101278843B1; CN101292467A; CN101292467B

Abstract

다자간 오디오-비디오컨퍼런싱을 위한 애플리케이션-레벨 라우팅 프로토콜을 구현하는 시스템(114) 및 방법(500)이 설명된다. 일 구현예에서는, 애플리케이션-레벨 퍼-스트림(per-stream) 라우팅 기술(202)은 네트워크상에서 호스트된 컨퍼런스 멤버들 간의 오디오 데이터와 비디오 데이터를 독립적으로 제어한다. 상이한 오디오 애플리케이션-레벨 멀티캐스트(ALM) 트리(220)는 각각의 멤버에 의해 생성되고, 데이터 전달 경로의 최단-경로-우선 선택(232)에 따라 동적으로 업데이트되며, 비디오컨퍼런스의 다른 멤버들에게 오디오 데이터를 보내는데 사용된다. 유사하게, 상이한 비디오 ALM 트리들(218)은 각각의 멤버에 의해 생성되고, 데이터 전달 경로의 가장 넓은-경로-우선 선택(228)에 따라 동적으로 업데이트되며, 비디오컨퍼런스의 다른 멤버들에게 비디오 데이터를 보내는데 사용된다. 각각의 멤버에 대해 독립된 오디오 및 비디오 ALM 트리는 IP 멀티캐스트가 가능한 네트워크의 세그먼트 내에서 IP 멀티캐스트(222)를 활용할 수 있다.

비디오컨퍼런스, IP 멀티캐스트, 애플리케이션-레벨 멀티캐스트(ALM) 트리, 퍼-스트림 라우팅, 최단-경로-우선(SPF) 전달 루트, 가장 넓은-경로-우선(BPF) 전달 루트

Description

다자간 오디오-비디오 컨퍼런싱을 위한 애플리케이션-레벨 라우팅 프로토콜의 방법, 컨퍼런싱 엔진 및 시스템{APPLICATION-LEVEL ROUTING PROTOCOL FOR MULTIPARTY AUDIO-VIDEO CONFERENCING}

다자간 비디오컨퍼런스에서의 미디어 전송은 다수의 일대다(one-to-many) 의미론에 의해 특징지어진다. 이 일대다 데이터 전달을 제공하는 기본 메커니즘 중 하나는 IP 멀티캐스트이다. 그러나, IP 멀티캐스트는 멀티캐스트 지원을 제공하기 위해 하드웨어에 의존한다. 멀티캐스트 가능 라우터의 고르지 않은 배치(spotty deployment)는 많은 멀티포인트 통신 애플리케이션이 실패하게 만들었다. 개발자는 일대다 통신을 실현하기 위해 "다중 유니캐스트(multiple unicast)"로 전환하여 개발해왔다. 그러나, 다중 유니캐스트에도 또한 몇몇 문제가 있다. 임의의 물리적 링크 상에서 단 하나의 패킷만을 보장하는 IP 멀티캐스트와는 달리, 다중 유니캐스트는 소스에서 데이터를 복제하여, "라스트 마일(last mile)"(이 활용에서는 퍼스트 마일)을 심한 병목(bottleneck)으로 만든다. 다중 유니캐스트는 또한, 고속의 T1 회선, 케이블 모뎀, 및 ADSL에서부터 저속의 다이얼업 접속에 이르기까지, 인터넷상의 접속은 이종적(heterogeneous)이기 때문에, 다자간 비디오컨퍼런스에 가장 부적격한 멤버를 수용하는 작업량을 제한하는 것은 불가능하다.

각종 애플리케이션을 위해 설계된 애플리케이션-레벨 멀티캐스트(ALM) 시스 템의 쇄도(surge)가 존재해왔다. 그러나, 상이한 인터넷 애플리케이션은 그것들의 대역폭, 대기시간 및 확장성에 대해 상이한 요건을 갖는다. 표 1은 4가지 전형적인 인터넷 애플리케이션의 비교를 제공한다. 표 1에 도시된 바와 같이, 비디오컨퍼런싱은 나머지 3가지 애플리케이션보다 낮은 확장성 요건을 갖지만, 그보다 넓은 대역폭을 요구하고 대기시간에 더욱 민감하다. 따라서, 표 1에 리스팅된 다른 애플리케이션에서 작동하는 ALM 시스템은 비디오컨퍼런싱 애플리케이션에 직접 적용할 수 없다.

인터넷 애플리케이션의 특성

애플리케이션	대역폭	대기시간	확장성
인터넷 컨텐트 배포	중간	낮음	큼
피어투피어 미디어 스트리밍	높음	중간	큼
낮은 대역폭 데이터 스트리밍	낮음	낮음	큼
다자간 비디오컨퍼런싱	높음	높음	작음

4 가지의 종래의 ALM 프로토콜 설계는 종래의 비디오컨퍼런싱 애플리케이션의 영역을 나타낸다. 우선, "엔드 시스템 멀티캐스트(End System Multicast)"가, NARADA라고 불리는, 완전 분산 프로토콜을 제공한다. NARADA는 멀티캐스트 트리를 구축하는 데에 메시-우선 전략을 채용한다: 엔드 시스템은 풍부하게 접속된 그래프(메시)로 자가 조직(self-organize)되는데, 이 그래프(메시)의 꼭대기에는, 거리 벡터 프로토콜에 기초하여 데이터 전달 트리가 생성된다. NARADA의 주요 단점은 동일한 메시 위에 다수의 전달 트리를 구축한 결과를 고려하지 않는다는 점이다. 거리 벡터 프로토콜에서 사용된 라우팅 메트릭 만이 엔드-투-엔드(end-to-end) 지연이기 때문에, NARADA는 각 링크의 대역폭 활용에 대한 어떤 제어도 갖지 않는다. 결과적으로, 짧은 링크는 참여 멤버들이 다수인 경우에 쉽게 혼잡해질 수 있다.

NARADA와는 달리, ALMI는 중앙화된 프로토콜이다. 각각의 ALMI 세션은 세션 제어기를 갖는데, 이는 멤버 등록 및 멀티캐스트 트리 생성을 담당한다. ALMI는 다수의 데이터 소스를 고려하고, 라우팅을 다루기 위해 공유된 트리를 사용한다. 공유된 트리는 엔드-투-엔드 측정(즉, 세션 멤버에 의해 수집되는 라운드 트립 지연(round trip delays))에 기초하여 최소 스패닝 트리(MST: minimum spanning tree)로 형성된다. 비록 총 트리 비용면에서는 ALMI 트리의 효율성이 IP 멀티캐스트 트리의 효율성에 근접하더라도, ALMI 트리의 엔드-투-엔드 전달 지연은 훨씬 더 길다. 또한, 내부 노드와 리프 노드의 네트워크 로드는 다수의 데이터 소스가 존재하는 경우에는 상당히 상이하다. ALMI는 NARADA처럼 대역폭 활용을 제어하지 않으므로, 내부 노드는 컨퍼런스 크기가 증가하면 오버로드될 수 있다.

NARADA 및 ALMI와는 달리, "다중-전송기 3D 비디오컨퍼런싱(multi-sender 3D video conferencing)"에서 사용되는 프로토콜은 비디오컨퍼런싱 애플리케이션 내의 다중-전송기 요건을 명확하게 다룬다. 이 기술은 소프트 가입 요청(스트림에 대한 신청)을 관리하기 위해 더블-알고리즘 접근법을 사용한다. 저작권자가 지적한 바와 같이, 이 프로토콜의 핵심 단점은 네트워크 조건에 관련되는 그 프로토콜의 정적 특성이다. 예를 들면, 비디오컨퍼런스의 모든 멤버들은 데이터 스트림에 대해 동일한 정적 비트율을 갖는 것으로 가정한다.

DIGIMETRO는 완전 분산 방식으로 다수의 소스-특정 전달 트리를 구축한다. DIGIMETRO는 동일한 세션에서 다수의 데이터 소스를 갖는 결과를 고려하여, 차선의 성능을 달성하기 위해 2단계 프로세스를 채용한다. 이전의 작업에 대비되는 DIGIMETRO의 주요 장점은 동적으로 변동되는 네트워크 파라미터 하에서 멀티캐스트 트리가 구성 및 개량되어서, 상이한 데이터 소스들로 하여금 상이한 스트림 비트율을 갖도록 허용한다는 점이다. 다자간 비디오컨퍼런싱 시스템 DIGIPARTY는 DIGIMETRO를 사용하여 구현되었다.

실제 네트워크상에서 현존하는 ALM 프로토콜에는 몇 가지 단점이 존재한다. 우선, DIGIMETRO와 다중-전송기 3D 비디오컨퍼런싱 양쪽 모두는 대역폭 병목이 언제나 퍼스트 마일에서 일어난다고 가정하지만, LAN 사용자에게는 꼭 그렇지만은 않다. 둘째로, NARADA 및 ALMI는 대략적인 팬-아웃(fan-out) 범위를 부여함으로써 대역폭 활용을 단지 제한할 뿐, 아웃바운드(outbond) 링크들을 몇 번이나 사용할지는 제어하지 못한다. ALMI를 제외한, 상술한 나머지 3가지의 참조는 소스-특정 멀티캐스트 트리를 구축하여 특정 대역폭 제약 하에서 지연 성능을 최적화한다. 그러나 그것들은 로컬 대역폭 리소스를 공격적으로 소모해버리는 경향이 있고, 다중 유니캐스트가 되려는 강한 경향도 갖고 있다. 상술한 ALM 프로토콜 중 어떤 것도 LAN에서 항상 사용가능한 IP 멀티캐스트를 사용하지 않는다. 필요한 것은 비디오컨퍼런싱의 요구에 보다 특화하여 맞춤제작된 ALM 스키마이다.

다자간 오디오-비디오 컨퍼런싱을 위한 애플리케이션-레벨 라우팅 프로토콜을 구현하는 시스템 및 방법이 설명된다. 일 구현예에서는, 애플리케이션-레벨 퍼-스트림(per-stream) 라우팅 기술은 네트워크상에서 호스팅된 컨퍼런스 멤버들 간의 오디오 데이터와 비디오 데이터를 개별적으로 제어한다. 상이한 오디오 애플리케이션-레벨 멀티캐스트(ALM) 트리는 각각의 멤버에 의해 생성되고, 데이터 전달 경로의 최단-경로-우선 선택(shortest-path-first selection)에 따라 동적으로 업데이트되며, 비디오컨퍼런스의 다른 멤버들에게 오디오 데이터를 보내는데 사용된다. 유사하게, 상이한 비디오 ALM 트리는 각각의 멤버에 의해 생성되고, 데이터 전달 경로의 가장 넓은-경로-우선 선택(broadest-path-first selection)에 따라 동적으로 업데이트되며, 비디오컨퍼런스의 다른 멤버들에게 비디오 데이터를 보내는데 사용된다. 각각의 멤버에 대해 개별화된 오디오 및 비디오 ALM 트리는 IP 멀티캐스트가 가능한 네트워크의 세그먼트 내에서 IP 멀티캐스트를 활용할 수 있다.

본 설명은 아래의 실시예에서 더 설명될 컨셉의 선택을 단순화된 형태로 소개하기 위해 제공된 것이다. 본 설명은 청구된 요지의 핵심 피쳐 또는 필수 피쳐들을 식별하거나, 청구된 요지의 범위를 한정하기 위한 목적으로 사용되기 위한 것은 아니다.

도 1은 예시적인 애플리케이션-레벨 라우팅 프로토콜을 사용하는 예시적인 오디오-비디오 컨퍼런싱 시스템의 도면.

도 2는 예시적인 ALM 컨퍼런싱 엔진의 블록도.

도 3은 예시적인 애플리케이션-레벨 라우팅 프로토콜에서의 예시적인 IP 멀티캐스트 통합의 도면.

도 4는 예시적인 IP 멀티캐스트 통합을 위한 예시적인 노드 클러스터링의 도면.

도 5는 예시적인 퍼-스트림 라우팅 제어 프로세스의 흐름도.

본원에 설명된 것은 오디오-비디오 컨퍼런싱(이상, "비디오컨퍼런싱")을 위해 효과적인 일대다 데이터 전달을 할 수 있는 예시적인 애플리케이션-레벨 멀티캐스트(ALM) 프로토콜을 사용하는 시스템 및 방법이다. ALM은 라우팅 및 패킷 중복과 같은, 기능성에 관련된 멀티캐스트를 애플리케이션 계층에 푸시하여, 기저의 하드웨어의 작업을 독립적으로 한다. 본원에 설명된 예시적인 ALM 라우팅 프로토콜은 다수의 소스-특정 트리를 구축하여 보다 나은 지연 성능을 달성하고 내부의 노드에서의 병목을 회피한다. 멀티캐스트 트리 계산에서 지연 성능만을 최적화하는 현존하는 ALM 프로토콜과는 달리, 본 예시적인 ALM 라우팅 프로토콜은 지연-민감성 오디오 데이터와 대역폭-집약적 비디오 데이터를 구별하고, 또한 오디오 및 비디오를 위한 각각의 멀티캐스트 트리를 구축하는 데에 상이한 최적화 메트릭을 사용한다.

일 실시예에서는, 예시적인 ALM 라우팅 프로토콜은 비디오 배포를 위해 가장 넓은-경로-우선(broadest-path-first; BPF) 라우팅을 사용하는데, 이는 네트워크 리소스 활용 및 로드 밸런싱 양쪽 면에서 최단-경로-우선(shortest-path-first; SPF) 라우팅보다 나은 성능을 달성하기 때문이다. 비록 IP 멀티캐스트가 인터넷을 통해 간헐적으로만 활용(deployed)된다고 해도, 예시적인 ALM 라우팅 프로토콜은 네트워크의 일부분에서 IP 멀티캐스트가 가능한 경우에 IP 멀티캐스트를 최대한 활용한다. 예시적인 ALM 라우팅 프로토콜은 개선된 엔드-투-엔드 지연 성능을 제공하는 동시에 네트워크 리소스 사용량을 상당히 감소시킨다.

위에서 소개된 2가지 피쳐 - 대역폭-집약적 비디오 데이터를 위한 데이터 전달 경로를 계산하기 위해 BPF를 사용하기, 및 IP 멀티캐스트 가능한 네트워크가 존재하는 경우에 그것을 사용하기 - 를 구현하는 것 이외에도 예시적인 ALM 라우팅 프로토콜은 또한 예시적인 퍼-스트림 라우팅 제어 프로토콜을 구현한다.

예시적인 시스템

도 1은 위에서 소개된 예시적인 ALM 라우팅 프로토콜이 사용될 수 있는 예시적인 비디오컨퍼런싱 시스템(100)을 도시한다. 비디오컨퍼런스에 참여하는 다수의 컴퓨팅 장치(즉, 102, 104, 106, 108, 110, 112)가, 인터넷 또는 기타 네트워크를 통해 서로 통신상으로 결합돼 있다. 비디오컨퍼런스에 참여하는 컴퓨팅 장치(예컨대, 102)는 "엔드 시스템(end system)", "참가자", "멤버", "멤버 노드", "소스", "소스 노드", 등으로 다양하게 불린다. 비디오컨퍼런스에 참여하는(또는 참여하도록 결합된) 컴퓨팅 장치(예컨대, 102)는 본원에서 정황에 따라 "소스", "멤버", 또는 "멤버 소스"로 불릴 것이다.

일반적인 구현예에서, 각각의 비디오컨퍼런스 멤버(예컨대, 102)는 인터넷에 직접 결합되거나, 또는 인터넷에 접속되는 LAN을 통하여 인터넷에 간접적으로 결합된다. 라우터들, 스위치들 등일 수 있는 각종 네트워크 노드들은, 또한 도 1에 도시되어 비디오컨퍼런싱 데이터를 라우팅하기 위한 멀티캐스트 트리가 구성되어 있 는 조직을 보여준다. 각각의 멤버(예컨대, 102)는 또한 비디오컨퍼런싱 시스템(100) 내의 노드로 간주된다.

예시적인 비디오컨퍼런싱 시스템(100)에서, 비디오컨퍼런스(예컨대, 102, 104, 106, 108, 110, 112)에 참여하는 각각의 멤버(102)는 예시적인 컨퍼런싱 엔진(예컨대, 114, 116, 118, 120, 122, 및 124)을 포함한다. 예를 들어, 소스(102)는 예시적인 컨퍼런싱 엔진(114)을 포함한다.

각각의 예시적인 컨퍼런싱 엔진(114, 116, 118, 120, 122, 124)은 비디오 ALM 트리(각각, 126, 130, 134, 138, 142, 146) 및 오디오 ALM 트리(각각, 128, 132, 136, 140, 144, 148) 양쪽 모두를 생성한다. 예를 들면, 예시적인 컨퍼런싱 엔진(114)을 포함하는 소스(102)는 비디오 ALM 트리(126) 및 오디오 ALM 트리(128) 양쪽 모두를 생성한다. 각각의 예시적인 컨퍼런싱 엔진(예컨대, 114)은 네트워크상의 상태 변화에 응답하여 자신의 비디오 ALM 트리(126) 및 자신의 오디오 ALM 트리(128)를 동적으로 재계산하고, 비디오컨퍼런스 내에서 변화하고, 및/또는 이웃하는 멤버의 멀티캐스트 트리에서 변화한다. 다시 말해, 비디오컨퍼런스의 각 참가자는 오디오 및 비디오에 대한 두 개의 ALM 트리로 이루어진 자신 소유의 세트를 생성하고, 전체 비디오컨퍼런스에 연관된 모든 멀티캐스트 트리는 안정된 상태로부터의 이탈에 응답하여 그리고 서로간의 변화(즉, 다른 멀티캐스트 트리에서의 변화)에 응답하여 동적으로 업데이트된다.

예시적인 ALM 라우팅 프로토콜은 따라서 다중-전송기 데이터 전달을 위해 하나의 다중 스패닝 트리(MST) 대신에 다수의 소스-특정 트리를 사용한다. 정의에 의해, MST는 최적의 네트워크 리소스 사용량을 갖는데, 이는

로 정의되고, 여기서 L은 멀티캐스트 트리의 링크의 개수, d_i는 링크 i의 지연, s_i는 링크 i의 스트레스이다. 그러나, N개의 멤버를 갖는 다자간 비디오컨퍼런스에서, N-1개의 에지에서의 모든 미디어 트래픽은 이러한 에지들에게 큰 네트워크 로드를 가져온다. 각각의 노드에게 요구되는 업링크 대역폭은 N(d-1)+1로 계산될 수 있는데, 여기서 d는 MST 내의 노드의 아웃-바운드 정도이다. 임의의 내부 노드(d>1)에 대해, 요구되는 업링크 대역폭의 크기는 O(N) 정도임을 알 수 있는데, 여기서 O는 계산상의 복잡도를 나타낸다.

예시적인 ALM 라우팅 프로토콜의 다수의 소스-특정 트리는, 한편, N(N-1)/2 링크의 최대값으로 네트워크 로드를 분산하여, 그로 인해 임의의 단일한 링크상의 스트레스를 상당히 감소시킨다. 비록 다수의 오버레이 링크가 네트워크 계층 내에서 동일한 병목을 공유할 수 있더라도, 예시적인 ALM 라우팅 프로토콜은 이러한 상황을 회피하도록 양호하게 설계된다.

예시적인 엔진

도 2는 도 1의 예시적인 컨퍼렁싱 엔진(114)을 보다 자세히 도시한다. 예시적인 컨퍼런싱 엔진(114)의 도시된 컨피규레이션은 개요를 위해 단지 하나의 예시적 배치를 제공하기 위한 것이다. 도시된 컴포넌트들의 많은 다른 배치, 또는 유사한 컴포넌트들이 본 요지의 범위 내에서 가능하다. 이러한 예시적인 컨퍼런싱 엔진(114)은 하드웨어, 소프트웨어, 또는 하드웨어, 소프트웨어, 펌웨어 등의 조합 에서 실행될 수 있다.

일 구현예에서, 예시적인 컨퍼런싱 엔진(114)은 퍼-스트림 라우팅 제어기(202), ALM 트리 생성기(204), 링크 상태 엔진(206), 트리 공유 엔진(208), 및 오디오/비디오 트랜시버(210)를 포함한다.

퍼-스트림 라우팅 제어기(202)는 접속 네고시에이터(212), 대역폭 네고시에이터(214), 및 리소스 예약 엔진(216)을 더 포함할 수 있다.

ALM 트리 생성기(204)는 퍼-스트림 라우팅 제어기(202)로부터의 입력에 응답하여 현재의 오디오 및 비디오 ALM 트리를 재계산 및/또는 리컨피규어한다. ALM 트리 생성기(204)는 비디오 ALM 트리 생성기(218), 오디오 ALM 트리 생성기(220), IP 멀티캐스트-가능 네트워크 통합기(222), 클러스터 엔진(224), 및 링크 상태 통합기(226)를 더 포함할 수 있다. 비디오 ALM 트리 생성기(218)는 가장 넓은-경로-우선(BPF) 최적화기(228) 및 최단 경로 선택기(230)를 포함할 수 있다. 오디오 ALM 트리 생성기(220)는 최단-경로-우선(SPF) 최적화기(232) 및 대역폭 선택기(234)를 더 포함할 수 있다. 링크 상태 통합기(226)는 대역폭 분석기(236), 지연 분석기(238), 신뢰성 분석기(240), 및 지터 분석기(242)를 더 포함할 수 있다.

나머지 컴포넌트들에 관하여, 링크 상태 엔진(206)은 이웃 노드 프로브 엔진(244), 링크 상태 컴파일러(246), 및 링크 상태 전파기(248)를 더 포함할 수 있다. 트리 공유 엔진은 토폴로지 수신기(250) 및 토폴로지 전파기(252)를 더 포함할 수 있다. 오디오/비디오 트랜시버(210)는 오디오 버퍼(254) 및 비디오 버퍼(256)를 더 포함할 수 있다.

인터넷상에서의 링크 상태 라우팅과 유사한 기술을 또한 사용하는 일 구현예에서는, 각각의 예시적인 컨퍼런싱 엔진(114)의 이웃 노드 프로브 엔진(244)이 그것의 이웃 소스를 주기적으로 프로브하고, 링크 상태 컴파일러(246)가 이 링크 상태 정보를 수집한다. 각각의 멤버 소스(예컨대, 102)의 링크 상태 전파기(248)는 그러면 링크 상태 정보를 다른 멤버 소스(예컨대, 104, 106, 108, 110, 112)에 전파하여, 각각의 멤버 소스(예컨대, 102)는 자신의 비디오 및 오디오 ALM 트리를, 기저의 네트워크를 포함하는 비디오컨퍼런싱 시스템(100)을 위한 완전 상황(status) 데이터에 기초하여 재계산할 수 있다. 링크 상태 라우팅과 구별하여, 단순히 링크를 업 또는 다운으로 표시하는 것은 예시적인 ALM 라우팅 프로토콜에서 충분치 못하다. 예를 들면, 멀티캐스트 트리를 생성할 때, 링크 상태 통합기(226)는 대역폭 분석기(236), 지연 분석기(238), 신뢰성 분석기(240), 및 지터 분석기(242) 등과 같은, 현재의 멀티캐스트 트리의 생성으로 진행하는 다수의 인자를 분석하는 컴포넌트를 갖는다.

통상적으로, 비록 ALM 프로토콜이 지연 및 대역폭 조건 양쪽 모두를 고려한다 해도, 지연 조건 만이 종래의 트리 최적화에서 우선적으로 고려되는 반면에, 대역폭은 제약으로서 거의 눈에 띄지 않는다. 반면에, 예시적인 컨퍼런싱 엔진(114)은, 비디오 데이터를 전달하는 데에 대역폭이 보다 중요한, 비디오컨퍼런싱 애플리케이션에서 메트릭도 중요한 것으로 간주한다. 예시적인 컨퍼런싱 엔진(114)은 오디오와 비디오 데이터를 구별하여, 그것들의 멀티캐스트 트리 계산에서 서로 다른 최적화 메트릭을 사용한다.

오디오 데이터의 경우에는, 오디오 ALM 트리 생성기(220)가 대역폭 제약하에서 엔드-투-엔드 지연 성능을 최적화한다. 전처리단계에서는, 대역폭 선택기(234)는 이용가능한 대역폭이 오디오 비트율보다 작은 링크를 제거한다. 그러면, 최단-경로-우선(SPF) 최적화기(232)는, 일 구현예에서 원본 Dijkstra의 알고리즘에 대한 확장인 오디오 ALM 트리(128)를 계산하기 위해 최단-경로-우선(SPF) 라우팅 알고리즘을 적용한다.

비디오 데이터의 경우에는, 대역폭 집약적 비디오 데이터를 위한 비디오 ALM 트리(126)를 구축하기 위해, 비디오 ALM 트리 생성기(218)가 주요 최적화 조건으로서 대역폭 조건을 취한다. 일 구현예에서는, 가장 넓은-경로-우선(BPF) 최적화기(228)가 아래의 표 2에 있는 예시적인 BPF 알고리즘을 사용하는데, 이는 소정의 소스(예컨대, 102 등)에서 모든 목적지까지의 가장 넓은 경로를 계산한다.

일 구현예에서, 2가지 경로가 유사한 이용가능 대역폭을 갖는 경우에는, 최단 경로 선택기(230)가, 예를 들면, 상술한 표 2에 있는 BPF 알고리즘의 일부를 사용함으로써, 둘 중에 더 짧은 경로를 선택할 수 있다. 비록 비디오 데이터상에 지연시간 요건의 특정 정도가 있다 해도, 비디오에 BPF 라우팅을 사용하는 것은 SPF 라우팅을 사용하는 것보다 더 나은 시스템 성능을 낳는다. 그 결과에 대한 원인은 다양하다. 예를 들면, 대부분의 경우에, 데이터를 엔드-투-엔드로부터 직접 보내는 것은 하나 이상의 중간 노드를 사용하여 데이터를 중계(relay)하는 것보다 적은 대기시간을 낳는다. 따라서, SPF 알고리즘이 있는 경우에는 SPF 알고리즘이 항상 소스로부터 직접 링크를 픽업한다. 그러나, 이 전략은 로컬 대역폭을 지나치게 공격적으로 소모해 버린다. 따라서, 비디오 데이터를 위해 SPF를 사용하는 종래의 기술은 대역폭 활용의 균형을 맞추기 위해 통상적으로 복잡한 개량 프로세스를 거쳐야만 한다.

라운드 트립 시간의 변동 δ가 1/(1-L)에 비례하여 변화한다고(여기서 L은 현재 네트워크 로드임) 제안하는 대기 이론(queuing theory) 때문에 비디오 ALM 트리(126)를 생성하기 위한 가장 넓은-경로-우선(BPF) 최적화기(228)는 또한, 종래의 기술보다 뛰어나다. 대역폭-집약적 비디오 스트림을 보다 넓은 경로에 삽입하는 것은 네트워크 로드 L에서 보다 적은 영향력을 가지므로, 전송 대기시간의 보다 적은 변동을 도입한다.

그러면 또한, 대역폭과 대기시간은 독립적이지 않다. 상당한 대역폭을 갖는 링크는 보통 매우 큰 전송 대기시간을 갖지는 않는다. 다시 말해, 대기시간이 표 2에서와 같은 예시적인 BPF 라우팅 알고리즘에 대한 입력이 아니더라도, 이는 내재적 방식으로 결과에 영향을 준다.

한편, 오디오 ALM 트리 생성기(220)는 최단-경로-우선(SPF) 최적화기(232)를 계속 사용하여, 즉, SPF 알고리즘을 사용하여 몇 가지 원인에 대해 오디오 ALM 트리(128)를 컴퓨팅할 수 있다. 우선, 오디오 스트림의 비트율은 상대적으로 작다(보통 초당 약 10에서 20 킬로비트(Kbps)임). 이 비트율은 네트워크 로드에 거의 무시해도 좋을 만큼의 영향을 준다. 따라서, 오디오 스트림을 비록 좁은 링크에 삽입하더라도 일반적으로는 대기시간 변동의 눈에 띄는 증가를 유도하지는 않을 것이다.

비디오 데이터는 원격 컨퍼런싱의 사용자 경험을 개선시키는 것이지만, 오디오는 통신에 꼭 필수적인 것이다. 컨퍼런스 멤버가 충분한 대역폭을 갖지 않는 경우에는, 오디오 스트림만을 유지하고 불필요한 비디오는 끄는 것이 가능하다. 이러한 경우에, 최고속으로 오디오 스트림을 전송하는 것은 2-웨이 통신의 품질에 필수적이다.

컨퍼런스 멤버가 특정 소스(예컨대, 102)로부터의 오디오와 비디오 양쪽 모두를 요청하는 경우에는, 2가지 스트림 - 오디오와 비디오 - 이 수신기 측에서 동기화될 필요가 있다. 보다 큰 버퍼가, 전달되는 패킷의 보다 많은 변동 및 고장(out-of-order)을 견딜 수 있는 방식으로, 오디오 데이터가 오디오 버퍼(254)에 저장될 수 있으므로, 보다 빠른 채널로 오디오를 전송하는 것은 이득을 제공할 수 있다.

따라서, 예시적인 컨퍼런싱 엔진(114)은 비디오 ALM 트리(126) 제작을 위해 가장 넓은-경로-우선(BPF) 최적화기(228)를 사용하고, 오디오 ALM 트리(128) 제작을 위해서는 최단-경로-우선(SPF) 최적화기(232)를 사용 - 즉, 오디오 및 비디오 데이터를 라우팅하는 멀티캐스트 트리를 생성하기 위해 2가지 상이한 알고리즘을 사용함 - 한다. 일 구현예에서는, 예시적인 비디오 및 예시적인 오디오 라우팅 알고리즘 양쪽 모두는 원본 Djikstra의 알고리즘에 대한 확장이다. 예시적인 확장은 데이터 전달 효율성을 더 증가시키기 위해 가능한 한 많이 IP 멀티캐스트를 사용하려는 목적을 위한 것이다. IP 멀티캐스트는 물리적 링크에 중복 패킷이 없다고 보장하므로, 일대다 데이터 전달을 가능하게 하는 데 가장 효과적인 메커니즘이다. 그러나, 몇 가지 내재적 문제가 IP 멀티캐스트로 하여금 광범위하게 활용되는 것을 방해해왔다. 이러한 문제는 인프라 레벨에서 도입되는 복잡성, 범람하는 공격에 대한 취약성, 및 공개된 인터넷 환경에서의 열악한 확장성을 포함한다.

본원의 예시적인 ALM 라우팅 프로토콜은, 예시적인 ALM 라우팅 프로토콜이 기저의 하드웨어에 독립적으로 작동할 수 있는 IP 멀티캐스트보다 활용도가 높다. 그러나 이는, 예시적인 컨퍼런싱 엔진(114)이, 그것의 예시적인 ALM 라우팅 프로토콜에서, 이용가능한 IP 멀티캐스트를 이용하는 것을 방해하지는 못한다. IP 멀티캐스트가 아직 광범위하게 활용되지 못하고 있고, 앞으로도 계속 활용되지 못할지라도, LAN에서는 종종 이용이 가능하다.

도 3에 도시된 바와 같이, 다자간 비디오컨퍼런스에서, IP 멀티캐스트-가능 LAN으로부터의 둘 이상의 멤버가 특정 데이터 소스 "s"(302)로부터의 동일한 데이터를 요청하고 있는 경우에, s(302)는 멤버들(304) 중 하나에게 데이터의 일 복사본을 보내기만 하면 되고, 그러면 그 멤버는 IP 멀티캐스트를 통해 다른 모든 멤버들에게 데이터를 중계할 수 있다. s(203)의 대역폭이 4가지 이상의 업로드 링크를 허용한다고 가정하자. 그러면 일 실시예에서, 예시적인 컨퍼런싱 엔진(114)은 원본 Dijkstra의 알고리즘에 따라 다중 유니캐스트(306) 내의 데이터를 보낼 수 있다. 그러나 IP 멀티캐스트가 이용가능한 경우에는, 예시적인 컨퍼런싱 엔진(114)의 IP 멀티캐스트-가능 네트워크 통합기(222)는 IP 멀티캐스트를 이용함으로써, 그리고 가능하다면, 데이터를 보내기 위해 IP 멀티캐스트 트리 스키마를 이용함으로써 2개의 긴 전송 링크(308, 310)를 회피할 수 있다.

IP 멀티캐스트 트리 스키마를 생성시키기 위해, IP 멀티캐스트-가능 네트워크 통합기(222)는 원본 Dijkstra의 알고리즘에 대한 확장을 만든다. 이 확장의 일례가 이하에서 설명될 것이다. 단순함을 위해, 최단-경로-우선(SPF) 최적화기(232)에 의해 사용될 수 있는 SPF 알고리즘에 대한 예시적인 확장만이 설명된다. 표 2에 있는 예시적인 BPF 알고리즘과 같은, 가장 넓은-경로-우선(BPF) 최적화기(228)에 의해 사용될 예시적인 BPF 알고리즘에 약간의 변경만을 가한 유사한 확장이 적용될 수 있다.

IP 멀티캐스트-가능 네트워크 통합기(222) 및 클러스터 엔진(224)이, 현재의 멀티캐스트 트리를 고려하여 IP 멀티캐스트를 포함하도록(가능한 경우) 구현하는 프로세스는, 다음과 같이 정의될 수 있다.

우선, 주어진 파라미터들 (V, E, C, δ, 및 s), (V, E)이 방향 그래프를 정의하는데, 여기서 s∈V는 소스 노드(예컨대, 102)이다. 항 δ()는 비용 함수를 정의하는데, 여기서 E 내의 각각의 에지 e=(u, v)는 음이 아닌 비용 δ(u, v)를 갖는다. 클러스터 엔진(224)은 IP 멀티캐스트-가능 LAN(또는 클러스터)인 C를 발견한다. u,v∈c_i δ(u, v)=0이면, C={c_i}이고 c_i={v_i}이다. IP 멀티캐스트-가능 네트워크 통합기(222)는 임의의 클러스터 c∈C를 만족하는 s에서 뻗어나오는 최단 경로 트리 T를 발견하고: s

c인 경우에는, T에 단 하나의 에지 e=(u, v)가 존재하는데, 여기서 u

c이고 v∈c이며, s∈c인 경우에는, T에 e=(u, v)가 존재하지 않는데, 여기서 u

c이고 v∈c이다.

일 구현예에서, IP 멀티캐스트-가능 네트워크 통합기(222)는 3-단계 프로세스에 의해 IP 멀티캐스트 기능을 포함한다. 첫째, 도 4에 도시된 바와 같이, 동일한 IP 멀티캐스트-가능 LAN 클러스터 내의 모든 노드들이 하나의 클러스터 노드로 간주되고; 그 다음에, 클러스터 노드들을 갖는 그래프에 원본 Dijkstra의 알고리즘이 적용되고; 그 후, 마지막으로, 클러스터 노드들은 통상의 노드들로 반전되고 멀티캐스트 트리를 생성하는데 필요한 에지들이 추가된다. IP 멀티캐스트-가능 네트워크 통합기(222)와 클러스터 엔진(224)에 의해 구현되는 이 프로세스는 이하에서 보다 자세히 설명될 것이다.

단계 1은 (V', E, δ')을 발생시키는 단계이다:

·v∈c이면, v는 V'의 c로 교환됨.

·비용 함수가 다음과 같이 변화함:

단계 2는 오리지널 Dijkstra의 알고리즘을 사용하여 (V', E, δ')상의 최단 경로 트리 T'를 계산하는 단계이다.

단계 3은 T=φ로부터 시작하여 T'으로부터 T를 발생시키는 단계이다. 각각의 에지 (x, y)∈T'에 대하여:

·x∈V ＆ y∈V 이면, T <- T∪(x, y)

·x∈C ＆ y∈V 이면, T <- T∪(u, y), 여기서

·x∈V ＆ y∈C 이면, T <- T∪(x, v)∪(v, w_i), 여기서

·x∈C ＆ y∈C 이면, T <- T∪(u, v)∪(v, w_i), 여기서

표 3은 클러스터를 사용하고, 가능한 IP 멀티캐스트를 사용하는 능력을 멀티캐스트 트리의 계산으로 통합하는, 위에서 설명된 예시적인 ALM 라우팅의 일 구현예를 도시한다.

클러스터를 사용하는 예시적인 라우팅을 나타내는 슈도 코드

예시적인 컨퍼런싱 엔진(114)은 또한 예시적인 제어 프로토콜을 사용한다. 퍼-스트림 라우팅 제어기(202)는 ALM 트리를 계산 및 유지하기 위해 분산 스키마를 사용한다. 따라서, 각각의 멤버 소스(예컨대, 102)는 자신이 소유한 스트림들에 대해 오디오 및 비디오 ALM 트리들(126, 128)을 계산하는 것을 담당한다. 트리 공유 엔진(208)은 위에서 소개한 토폴로지 전파기(252)를 포함하여 업데이트된 트리의 토폴로지를 모든 현재 신청자의 토폴로지 수신기(250)에 전달하므로 그 수신기들은 동일한 방향으로 스트림들을 라우팅할 수 있다.

종래의 ALM 프로토콜들은 일반적으로, 이용가능한 대역폭 활용에 대한 임의의 제어를 갖지 않는다. 대신에, 그 프로토콜들은 최상의 전달을 제공하기 위해 기저의 네트워크에 의존한다. 그러나, 예시적인 비디오컨퍼런싱 시스템(100) 내의 두 참여 멤버 소스(예컨대, 102, 104) 사이의 대역폭은 대략적으로 측정될 수 있고, 대역폭 네고시에이터(214)는 다수의 전송기에 대한 메커니즘을 제공하여 전송 링크의 오버로드를 방지한다.

일 구현예에서, 대역폭 네고시에이터(214)는 회로-스위치 통신 네트워크와 유사한 기술을 사용한다. 회로-스위치 및 패킷-스위치는 통신 네트워크의 2가지 기본 타입이다. 이러한 두 타입들의 정례는 PSTN(public switched telephone network)과 인터넷이다. 패킷-스위칭은 다중 통신으로 하여금 네트워크 리소스를 공유하도록 허용하여, 회로-스위치 네트워크에 비하여 비용을 낮게 유지할 수 있다. 한편, 패킷-스위칭은 회로-스위칭이 하는 것처럼 보장된 데이터 경로를 제공할 수는 없다. 접속 네고시에이터(212)와 리소스 예약 엔진(216)은 회로-스위치 네트워크에서 생성된 것과 유사한 전용 데이터 전달 경로를 네고시에이팅하고, 그 후에 오디오 및 비디오 ALM 트리(126, 128)는 생성 또는 재계산되어 그 주의 깊게 계산된 데이터 루트를 지정한다. 따라서, 예시적인 컨퍼런싱 엔진(114)은 비디오 및 오디오 ALM 트리들(126, 128)의 생성 및 동적 재계산 시에 인터넷에서 사용되는 퍼-패킷 라우팅 대신에 퍼-스트림 라우팅 제어기(202)를 사용한다.

예시적인 방법

도 5는 예를 들면, 예시적인 컨퍼런싱 엔진(114)에 의해 사용될 수 있는 예시적인 퍼-스트림 제어 프로세스(500)를 도시한다. 흐름도에서, 동작들은 개개의 블록 및 아이콘들로 요약된다. 예시적인 프로세스(500)의 일부분은 하드웨어, 소프트웨어, 또는 양쪽의 조합, 예컨대, 예시적인 컨퍼런싱 엔진(114)의 컴포넌트들에 의해 수행될 수 있다.

블록(502)에서, 비디오컨퍼런스 데이터 라우팅 프로세스는 안정된 상태인데, 이때 비디오컨퍼런스의 각각의 참여 멤버인 "소스"는 예시적인 최단-경로-우선 라우팅 프로토콜에 따라 최적화된 예시적인 오디오 ALM 트리 및 예시적인 가장 넓은-경로-우선 라우팅 프로토콜에 따라 최적화된 예시적인 비디오 ALM 트리 양쪽 모두를 사용하여 비디오컨퍼런스의 멤버들의 서브세트로 오디오 및 비디오 데이터를 보낸다.

블록(504)에서, 다음의 이벤트 중 하나가 일어날 수 있다: 대역폭 및/또는 지연 변경이 업데이트 메시지로서 감지되거나 수신될 수 있음; 소스들 중 하나(즉, 비디오컨퍼런스 사용자)는 스트림에 대해 취소 또는 신청할 수 있음; 또는 업데이트 메시지로서 비트율 변경이 수신될 수 있음.

일 구현예에서, "사이트 A"와 같은, 각각의 소스는 주기적인 링크 상황 업데이트를 수신한다. 매 10초 마다, 예를 들면, 각각의 멤버 소스는 그것의 업데이트된 링크 상황을 다른 모든 멤버 소스들에게 방송할 수 있다. 이러한 업데이트 메시지를 수신하면, 각각의 소스가 ALM 트리를 평가하여 그것들의 스트림에 대해 재계산할 수 있다. 대부분의 경우, 기저의 네트워크 내에 어떤 갑작스러운 변화도 없을 때는 ALM 트리가 변화하지 않는다.

하나 이상의 멤버 소스들이 비디오컨퍼런스 동안에 스트림을 신청 또는 취소(예컨대, 멤버 소스가 뮤트 버튼을 누름으로써 오디오 스트림에 취소함)하는 경우에는, 유래된 멤버 노드(예컨대, 사이트 A)는, 신청/취소 요청을 수신한다. 멤버 소스는 비디오컨퍼런스 중 임의의 시각에 임의의 스트림을 신청하거나 취소할 수 있다. 이러한 신청 상황의 변화는 데이더 전달 루트에 영향을 미치는데 이 루트에서 비-신청자가 리프 노드인 경우, 즉, 다른 멤버 소스들에게 스트림을 전파하기 위해 의존되지 않는 멤버 소스인 경우에 그들은 멀티캐스트 트리로부터 트리밍된다.

멤버 소스(또는 피드백 모듈) 중 하나에서의 사용자가 스트림의 품질을 변경하기로 결정한 경우에는, 사이트 A가 비트율 변경 메시지를 수신한다. 다시 말해, 멤버가, 비디오컨퍼런스 중에 멤버 소유의 미디어 스트림의 품질을 바꿀 수 있다. 예를 들면, 사용자가, 비디오컨퍼런스 동안에 사진을 전자-앨범에 업로드하기 위해 비디오 비트율을 줄이기 원할 수 있다. 피드백 모듈은 또한 현재의 네트워크 리소스가 모든 신청하는 멤버 소스들을 특정한 서비스 품질(QoS) 레벨로 처리할 수 없는 경우에도 스트림 비트율이 감소할 것을 요청할 수 있다.

블록(506)에서, 블록(504)에 관하여 위에서 리스팅된 이들 이벤트 중 임의의 것이 일어나는 경우에는, 소스(이 예에서는 사이트 A)는 리-라우팅 평가를 수행하는데, 즉, 데이터 전달의 효율성을 유지하거나 증가시키기 위해 오디오 및/또는 비디오 ALM 트리가 재계산되어야할 지의 여부를 결정한다.

블록(508)에서, 예를 들면, ALM 트리 생성기(204)를 사용하여 ALM 트리(들)이 재계산하는 것으로 인해, 데이터 전달 루트가 변경되는 경우에는, 블록(510)에서 새로운 토폴로지가 멀티캐스트 트리의 내부 노드들로 전달된다.

블록(512)에서, 새로 계산된 ALM 트리가 이전의 트리와 상이한 루트를 도출(따라서 멤버 소스인 사이트 A가 블록(510)에서 새로운 토폴로지를 모든 참여 멤버 소스들에 보냄)한 경우에는, 멤버 소스인 사이트 A는, 중계 노드(존재한다면)로부터의 승인을 기다린다.

블록(514)에서, 모든 중계 노드들이 새로운 토폴로지를 수용한 후에, 데이터 소스는 블록(502)에서 안정 상태로 되돌아간다.

블록(516)에서는, 그러나, 다른 데이터 소스가 그 리소스를 막 점유한 경우에 발생할 수 있는, 임의의 중계 노드가 새로운 토폴로지를 거절하는 경우, 데이터 리소스(사이트 A)는 가장 최신의 링크 상태 정보를 사용하여 새로운 루트를 달성하는, 멀티캐스트 트리를 또 한번 재계산하고, 블록(510)에서처럼, 새로운 토폴로지를 다른 멤버 소스에 다시 보내는 시도를 한다.

결론

상술한 요지는 하드웨어, 소프트웨어, 펌웨어 등, 또는 그것들의 조합에 구현될 수 있다. 특정 구현예에서, 본 요지는, 프로그램 모듈과 같이, 컴퓨팅 장치 또는 통신 장치에 의해 실행되고 있는 컴퓨터-실행가능 명령어의 일반적인 맥락에서 설명될 수 있다. 일반적으로, 프로그램 모듈은 루틴, 프로그램, 개체, 컴포넌트, 데이터 구조 등, 특정 작업을 수행하거나 특정한 추상 데이터 타입을 구현하는 것을 포함한다. 본 요지는 또한 통신 네트워크를 통해 링크되는 원격 처리 장치에 의해 무선 통신을 통하여 작업이 수행되는 분산 통신 환경에서 수행될 수 있다. 무선 네트워크에서, 프로그램 모듈은 메모리 저장 장치를 포함하는 로컬 및 원격 통신 장치 저장 매체 양쪽 모두에 위치될 수 있다.

상술한 논의는 다자간 오디오-비디오 컨퍼런싱을 위한 예시적인 애플리케이션-레벨 라우팅 프로토콜을 설명한다. 비록 본 요지가 구조적 피쳐 및/또는 방법론적 액트에 특정하는 언어로 설명되었지만, 첨부된 청구항에 정의되어 있는 본 요지는 특정 피처 또는 상술한 액트들에 반드시 제한되지는 않는다는 점을 이해해야 하겠다. 대신에, 상술한 특정 피쳐들 및 액트들은 청구항을 구현하는 예시적인 유형으로서 개시된다.

Claims

비디오컨퍼런스 오디오 데이터를 다자간 비디오컨퍼런스의 멤버들에게 라우팅하기 위한 오디오 ALM(Application-level multicast) 트리(220)를 생성하는 단계(204); 및

비디오컨퍼런스 비디오 데이터를 상기 멤버들에게 라우팅하기 위한 비디오 ALM 트리(218)를 생성하는 단계(204);

를 포함하는 방법.
제1항에 있어서, 상기 생성하는 단계는 다자간 비디오컨퍼런스의 각각의 멤버를 위한 오디오 ALM 트리와 비디오 ALM 트리 양쪽 모두를 생성하는 단계를 더 포함하고, 각각의 오디오 ALM 트리는 오디오 데이터를 일 멤버로부터 다른 멤버들에게 라우팅하고 각각의 비디오 ALM 트리는 비디오 데이터를 일 멤버로부터 다른 멤버들에게 라우팅하는 방법.
제2항에 있어서, 상기 ALM 트리를 생성하는 단계는 상기 비디오컨퍼런스의 멤버들 간의 각각의 데이터 스트림을 위한 고정된 루트를 지정하기 위해 상기 오디오 ALM 트리 및 상기 비디오 ALM 트리를 생성하는 단계를 포함하는 방법.
제2항에 있어서, 상기 생성하는 단계는 데이터 전달 루트의 최단-경로-우 선(shortest-path-first; SPF) 선택(232)에 따라 각각의 오디오 ALM 트리를 생성하는 단계, 및 데이터 전달 루트의 가장 넓은-경로-우선(broadest-path-first; BPF) 선택(228)에 따라 각각의 비디오 ALM 트리를 생성하는 단계를 더 포함하는 방법.
제4항에 있어서, 상기 오디오 ALM 트리를 생성하는 단계는 오디오 비트율보다 작은 이용가능 대역폭을 갖는 데이터 링크를 제거하는 단계(234)를 더 포함하는 방법.
제4항에 있어서, 상기 비디오 ALM 트리를 생성하는 단계는, 동등한 대역폭을 갖는 데이터 링크들 중에서 선택하는 경우에, 최단 경로를 갖는 데이터 링크를 선택하는 단계(230)를 더 포함하는 방법.
제4항에 있어서, 상기 최단-경로-우선(SPF) 전달 루트를 통해 수신된 상기 오디오 데이터를 버퍼링하여(254) 상기 가장 넓은-경로-우선(BPF) 전달 루트를 통해 수신된 상기 비디오 데이터와 동기화시키는 단계를 더 포함하는 방법.
제2항에 있어서, 상기 비디오컨퍼런스를 호스팅하는 네트워크의 적어도 일 부분의 링크 상태 파라미터(226)의 변동에 응답하여 상기 멤버들 중 하나의 상기 오디오 ALM 트리 또는 상기 비디오 ALM 트리를 재계산하는 단계(204)를 더 포함하는 방법.
제8항에 있어서, 상기 재계산하는 단계(204)는 링크 상태 파라미터의 변동에 응답하여 수행되고, 상기 링크 상태 파라미터는 대역폭의 변화(236), 대기시간의 변화(238), 데이터 스트림에 대한 멤버 신청의 변화(244), 비트율의 변화(246), 신뢰성의 변화(240), 또는 지터의 변화(242) 중 하나를 포함하는 방법.
제2항에 있어서, 상기 다른 멤버들 중 하나로부터 오디오 ALM 트리의 재계산된 토폴로지(510) 또는 비디오 ALM 트리의 재계산된 토폴로지(510)를 수신하는 것에 응답하여 상기 멤버들 중 하나의 상기 오디오 ALM 트리 또는 상기 비디오 ALM 트리를 재계산하는 단계(204)를 더 포함하는 방법.
제2항에 있어서, 상기 비디오컨퍼런스를 호스팅하는 상기 네트워크의 적어도 일부분의 링크 상태 파라미터(226)의 변동에 응답하여 상기 비디오컨퍼런스의 상기 멤버의 상기 오디오 ALM 트리 모두와 상기 비디오 ALM 트리 모두를 재계산하는 단계(204)를 더 포함하는 방법.
제2항에 있어서, 재계산된 오디오 ALM 트리 토폴로지 또는 재계산된 비디오 ALM 트리 토폴로지를 상기 비디오컨퍼런스의 다른 멤버에 전파하는 단계를 더 포함하는 방법.
제2항에 있어서, 오디오 ALM 트리 또는 비디오 ALM 트리를 업데이트하기 위해 상기 비디오컨퍼런스의 이웃하는 멤버들의 링크 상태 특성을 프로브하는 단계(244)를 더 포함하는 방법.
제1항에 있어서, 다중 유니캐스트를 사용하여 상기 오디오 및 상기 비디오 데이터를 소정의 멤버로부터 다른 멤버들에게 라우팅(202)하기 위해 상기 오디오 및 비디오 ALM 트리를 생성하는 단계를 더 포함하는 방법.
제1항에 있어서,

상기 비디오컨퍼런스를 호스팅하는 네트워크의 일부분에서 상기 IP 멀티캐스트가 가능한 경우에 인터넷 프로코콜(IP) 멀티캐스트(222)를 사용하여 오디오 및 비디오 데이터를 라우팅하기 위해 상기 오디오 및 비디오 ALM 트리를 생성하는 단계; 및

상기 IP 멀티캐스트가 가능하지 않은 상기 네트워크의 일부분에서 다중 유니캐스트를 사용하여 오디오 및 비디오 데이터를 라우팅(202)하기 위해 상기 오디오 및 비디오 ALM 트리를 생성하는 단계

를 포함하는 방법.
제15항에 있어서,

IP 멀티캐스트를 활용하는 상기 오디오 및 비디오 ALM 트리를 생성하는 단계 는,

단일한 클러스터 노드가 되는, 상기 네트워크의 각각의 IP 멀티캐스트-가능 LAN(local area network) 세그먼트 내에 멤버 노드들을 정의하는 단계(224);

Dijkstra의 알고리즘을 상기 네트워크의 그래프에 적용하는 단계(224) - 상기 그래프는 멤버 노드 및 상기 클러스터 노드들을 포함함 - ;

상기 클러스터 노드들을 멤버 노드들로 역전하는 단계(224); 및

상기 오디오 및 비디오 ALM 트리들를 완성하기 위해 상기 멤버 노드들 사이에 에지들을 추가하는 단계(224)

를 포함하는 방법.
컨퍼런싱 엔진으로서,

애플리케이션-레벨 퍼-스트림(application-level per-stream) 라우팅 제어기(202);

비디오 데이터를 비디오컨퍼런스의 멤버들에게 배포하기 위해, 상기 애플리케이션-레벨 퍼-스트림 라우팅 제어기(202)와 연관된 제1 애플리케이션-레벨 멀티캐스트(ALM) 트리(218) - 상기 제1 ALM 트리를 구성하기 위해 가장 넓은-경로-우선 선택 프로세스(228)는 고정된 데이터 전달 루트를 선택함 - ; 및

오디오 데이터를 상기 멤버들에게 배포하기 위해, 상기 애플리케이션-레벨 퍼-스트림 라우팅 제어기(202)와 연관된 제2 ALM 트리(220) - 상기 제2 ALM 트리를 구성하기 위해 최단-경로-우선 선택 프로세스(232)는 고정된 데이터 전달 루트를 선택함 -

를 포함하는 컨퍼런싱 엔진.
제17항에 있어서,

상기 애플리케이션-레벨 퍼-스트림 라우팅 제어기(202)와 연관된 IP 멀티캐스트 가능 네트워크 통합기(222) - IP 멀티캐스트가 상기 비디오컨퍼런스를 호스팅하는 네트워크의 하나 이상의 세그먼트에게 가능한 경우에는, 상기 오디오 및 비디오 ALM 트리들은, 상기 IP 멀티캐스트가 가능한 상기 네트워크의 일부분에서 IP 멀티캐스트를 통해 데이터를 배포하고, 상기 IP 멀티캐스트가 불가능한 상기 네트워크의 일부분에서는 다중 유니캐스트를 통해 상기 데이터를 배포하도록 구성됨 -

를 더 포함하는 컨퍼런싱 엔진.
제17항에 있어서,

ALM 트리 생성기(204) - 각각의 오디오 ALM 트리 및 각각의 비디오 ALM 트리는 링크 상태 파라미터(226)의 변동에 응답하거나 또는 상기 비디오컨퍼런스의 다른 멤버의 ALM 트리의 변화에 응답하여 재계산되고, 상기 링크 상태 파라미터는 대역폭의 변화(236), 대기시간의 변화(238), 데이터 스트림에 대한 멤버 신청의 변화(244), 비트율의 변화(246), 신뢰성의 변화(240), 또는 지터의 변화(242) 중 하나를 포함함 -

를 더 포함하는 컨퍼런싱 엔진.
비디오컨퍼런스를 호스팅하는 네트워크에 결합된 상기 비디오컨퍼런스의 참여 멤버들 간의 상기 비디오컨퍼런스의 오디오 데이터 및 비디오 데이터의 애플리케이션-레벨 퍼-스트림 라우팅 제어를 위한 수단(202);

데이터 전달 경로의 최단-경로-우선 선택(232)에 따라 제1 애플리케이션-레벨 멀티캐스트(ALM) 트리를 동적으로 업데이트하기 위한 수단(204) - 상기 제1 ALM 트리는 상기 비디오컨퍼런스의 일 멤버에게서 다른 멤버들에게 오디오 데이터를 보내는 데 사용됨 - ;

데이터 전달 경로의 가장 넓은-경로-우선 선택(228)에 따라 제2 애플리케이션-레벨 멀티캐스트(ALM) 트리를 동적으로 업데이트하기 위한 수단(204) - 상기 제2 ALM 트리는 상기 비디오컨퍼런스의 일 멤버에게서 다른 멤버들에게 비디오 데이터를 보내는 데 사용됨 - ; 및

IP 멀티캐스트가 가능한 상기 네트워크의 세그먼트에서 활용되는 IP 멀티캐스트(222)에 상기 제1 및 제2 애플리케이션-레벨 멀티캐스트(ALM) 트리를 동적으로 업데이트하기 위한 수단

을 포함하는 시스템.