Transmission optimization for application-level multicast
37 claims: 23 independent, 14 dependent
- 1データのマルチキャストを最適化する分散型のシステムであって、 マルチキャストビデオ会議における 複数のビデオ会議メンバー を有し、 前記複数のビデオ会議メンバーの各々は、 ビデオ会議データを 他の ビデオ会議メンバーに対し通信ネットワークを介して通信するデータソース であり 、 当該データソースは前記複数のビデオ会議メンバーの完全なメンバリストを維持し、 前記複数のビデオ会議メンバーの各々は、 ローカルのGreedyアルゴリズムで生成されるマルチキャストツリーであって、前記データソースにより制御および維持されるマルチキャストツリーを生成し、 前記データソースから新たにビデオ会議データを受け取るメンバーまでのビデオデータの最小の伝送遅延を判定することにより、前記新たにビデオ会議データを受け取るメンバーを前記マルチキャストツリーに追加し、前記新たにビデオ会議データを受信するメンバーのための帯域幅が利用できない場合に前記新たにビデオ会議データを受信するメンバーを前記マルチキャストツリーに追加する要求を前記帯域幅が利用可能になるまで保留する ように構成され、 前記複数のビデオ会議メンバーの各々は、最適化ロジックを備え、前記最適化ロジックは、 前記データソースから前記ビデオ会議メンバーの各々までのエンド・ツー・エンド伝送遅延を判定し、 前記データソースと前記ビデオ会議メンバーの各々との間で利用可能な帯域幅を判定し、 前記ビデオ会議メンバーの各々に対応するエンド・ツー・エンド伝送遅延および利用可能な帯域幅にしたがって、前記データソースのデータ通信構成を最適化するように構成され たこ とを特徴とす るシ ステム。
- 2前記エンド・ツー・エンド伝送遅延および利用可能な帯域幅に基づいて前記データソースのデータ通信構成を最適化することは、前記マルチキャストビデオ会議内のデータソースのデータ通信構成をリファインすることを含み、 前記リファインすることは、イントラ・ツリーリファインメントを行い、前記マルチキャストツリーのノードを当該マルチキャストツリー内で新しい親ノードに再構成し、応答して当該新しい親ノードの子ノードを再構成することを含む、ことを特徴とする請求項1に記載のシステム。
- 3前記最適化ロジックは、さらに 前記ビデオ会議メンバーの各々の間のエンド・ツー・エンド伝送遅延を判定し、かつ 前記ビデオ会議メンバーの各々の間で利用可能な帯域幅を判定するように構成されること を特徴とする請求項1に記載 のシ ステム。
- 4前記マルチキャストツリーは、 前記データソースをルートノードとして含み、前記データソースに対する前記ビデオ会議メンバーのデータ通信構成を表 すこ とを特徴とする請求項1に記載 のシ ステム。
- 5前記最適化ロジックは、前記データソースに備わっていることを特徴とする請求項1に記載 のシ ステム。
- 6前記マルチキャストツリーは、 前記データソースに対する前記ビデオ会議メンバーのデータ通信構成を表 し 、 前記最適化ロジックは、さらに 前記マルチキャストツリーをリファインし、前記データソースのデータ通信構成を最適化するように構成された ことを特徴とする請求項1に記載 のシ ステム。
- 7前記マルチキャストツリーは、 前記データソースをルートノードとして含み、前記データソースに対する前記ビデオ会議メンバーのデータ通信構成を表 し 、 前記最適化ロジックは、さらに 前記マルチキャストツリーをリファインし、前記データソースのオーディオデータ通信を最適化するように構成された ことを特徴とする請求項1に記載 のシ ステム。
- 8前記マルチキャストツリーは、 前記データソースをルートノードとして含み、前記データソースに対する前記ビデオ会議メンバーのデータ通信構成を表 し 、 前記最適化ロジックは、さらに 前記ビデオ会議メンバーの各々が前記データソースからビデオ会議データを受信することを申し込むとき、マルチキャストツリーを生成するように構成された ことを特徴とする請求項1に記載 のシ ステム。
- 9前記マルチキャストツリーは、 前記データソースをルートノードとして含み、前記データソースに対する前記ビデオ会議メンバーのデータ通信構成を表 し 、 前記最適化ロジックは、さらに 前記ビデオ会議メンバーの各々が前記データソースからビデオ会議データを受信することを申し込むとき、マルチキャストツリーを生成し、前記マルチキャストツリーをリファインし、前記データソースのデータ通信構成を最適化するように構成された ことを特徴とする請求項1に記載 のシ ステム。
- 10前記マルチキャストツリーは、 前記データソースをルートノードとして含み、前記データソースに対する前記ビデオ会議メンバーのデータ通信構成を表 し 、 前記最適化ロジックは、さらに 前記マルチキャストツリーにおいて前記ビデオ会議メンバーを表すノードがビデオ会議データを受信するのに用いる通信リンクを再構成するように構成された ことを特徴とする請求項1に記載 のシ ステム。
- 11請求項1に記載のビデオ会議のデータソースであって、 前記最適化ロジックは、ビデオ会議メンバーに対して、対応するマルチキャストツリーをリファインし、追加の帯域幅を利用可能にして、前記マルチキャストツリーをリファインすることができるように最適化要求を起動するように構成され、 前記リファインすることは、イントラ・ツリーリファインメントを行うことであり、ビデオ会議の他のデータソースのマルチキャストツリーを用い、前記データソースのマルチキャストツリーのノードを再構成することを含む、ことを特徴とするデータソース。
- 12前記最適化ロジックは、さらに 前記ビデオ会議 の データソースと前記ビデオ会議 の メンバーの各々との間で利用可能な帯域幅を判定し、 前記ビデオ会議 の メンバーの各々に対応する前記利用可能な帯域幅にしたがって前記マルチキャストツリーをリファインして前記ビデオ会議 の データソースのデータ通信構成をさらに最適化するように構成された ことを特徴とする請求項 11 に記載 のデ ータソース。
- 13前記最適化ロジックは、さらに 前記マルチキャストツリーをリファインし、前記ビデオ会議 の データソースのオーディオデータ通信を最適化するように構成された ことを特徴とする請求項 11 に記載 のデ ータソース。
- 14前記最適化ロジックは、さらに 前記ビデオ会議メンバーの各々が前記ビデオ会議 の データソースから前記ビデオおよびオーディオのデータを受信することを申し込むとき、 前記 マルチキャストツリーを生成するように構成された ことを特徴とする請求項 11 に記載 のデ ータソース。
- 15前記最適化ロジックは、さらに 前記マルチキャストツリーにおいてビデオ会議 の メンバーを表すノードが、前記ビデオおよびオーディオのデータを受信するために使用する通信リンクを再構成するように構成された ことを特徴とする請求項 11 に記載 のデ ータソース。
- 16前記最適化ロジックは、さらに ビデオ会議 の メンバーに対して、対応するマルチキャストツリーにおける通信リンクを再構成して、前記マルチキャストツリーにおける通信リンクを再構成することができるようにする最適化要求を起動、するように構成された ことを特徴とする請求項 11 に記載 のデ ータソース。
- 17マルチキャストビデオ会議の複数のビデオ会議メンバーの各々が実行する方法であって、 データソースと、ビデオ会議の間に前記データソースからビデオおよびオーディオのデータを受信するビデオ会議メンバーのデータ通信構成を表すマルチキャストツリーを生成するステップ であって、ここで前記ビデオ会議メンバーの各々は前記ビデオ会議における前記データソースでありビデオ会議データ受信者であり、前記マルチキャストツリーはローカルのGreedyアルゴリズムで生成され、前記データソースによって維持および制御される、ステップ と、 前記データソースから、当該データソースからビデオおよびオーディオのデータを受信する新たなビデオ会議データ受信者までの最小伝送遅延を判定することにより、前記新たなビデオ会議データ受信者を前記マルチキャストツリーに追加するステップと、 前記新たなビデオ会議データ受信者を前記マルチキャストツリーに追加する要求を帯域幅が利用可能になるまで保留するステップであって、ここで、前記新たなビデオ会議データ受信者は、前記データソースからの前記ビデオおよびオーディオのデータの双方を通信する帯域幅が利用可能になるまで保留されている間に、前記ビデオソースからオーディオのデータを受信する、ステップと、 前記データソースから前記ビデオ会議メンバーの各々までのエンド・ツー・エンド伝送遅延を判定するステップと、 前記ビデオ会議メンバーの各々に対応する前記エンド・ツー・エンド伝送遅延にしたがって、前記マルチキャストツリーをリファインし、前記ビデオ会議における前記データソースの前記データ通信構成を最適化するステップと を備えたことを特徴とする方法。
- 18前記ビデオ会議メンバーの各々の間のエンド・ツー・エンド伝送遅延を判定するステップをさらに備えたことを特徴とする請求項17に記載の方法。
- 19前記データソースと前記ビデオ会議メンバーの各々の間で利用可能な帯域幅を判定するステップと、 前記ビデオ会議メンバーの各々に対応する前記利用可能な帯域幅にしたがって、前記マルチキャストツリーをリファインし、前記データソースの前記データ通信構成をさらに最適化するステップと をさらに備えたことを特徴とする請求項17に記載の方法。
- 20前記ビデオ会議メンバーの各々の間で利用可能な帯域幅を判定するステップをさらに備えたことを特徴とする請求項17に記載の方法。
- 21前記マルチキャストツリーをリファインするステップは、 前記マルチキャストツリーをリファインし、前記ビデオ会議の間、前記データソースのオーディオデータ通信を最適化するステップを含むことを特徴とする請求項17に記載の方法。
- 22前記データソースと前記ビデオ会議メンバーの各々との間で利用可能な帯域幅を判定するステップと、 前記ビデオ会議メンバーの各々に対応する前記利用可能な帯域幅にしたがって、前記マルチキャストツリーをリファインし、前記ビデオ会議の間、前記データソースのオーディオデータ通信を最適化するステップと をさらに備えたことを特徴とする請求項17に記載の方法。
- 23前記マルチキャストツリーを生成するステップは、前記データソースを前記マルチキャストツリーのルートノードとし、前記ビデオ会議メンバーを前記マルチキャストツリーのノードとして含む前記マルチキャストツリーを生成するステップを含み、 前記マルチキャストツリーをリファインするステップは、前記マルチキャストツリーにおいてビデオ会議メンバーを表すノードが前記ビデオおよびオーディオのデータを受信するために使用する通信リンクを再構成するステップを含む ことを特徴とする請求項17に記載の方法。
- 24前記データソースが前記マルチキャストツリーをリファインすることができるように、ビデオ会議メンバーに対して、対応するマルチキャストツリーをリファインし追加の帯域幅を利用可能にするように最適化要求を起動するステップをさらに備えたことを特徴とする請求項17に記載の方法。
- 25前記データソースが前記マルチキャストツリーを再構築できるように、ビデオ会議メンバーに対して、対応するマルチキャストツリーにおける通信リンクを再構成するように最適化要求を起動するステップをさらに備えたことを特徴とする請求項17に記載の方法。
- 26実行されると、ビデオ会議メンバーに対し請求項17に記載の方法を実行することを指示する、コンピュータ実行可能命令を備えたことを特徴とする1つまたは複数のコンピュータ可読 記憶 媒体。
- 27命令が実行されると、ビデオ会議のデータソースに対し、 前記ビデオ会議の前記データソースをルートノードとして含み、前記ビデオ会議のメンバーがビデオおよびオーディオのデータを前記ビデオ会議の前記データソースから受信するための使用するデータ通信構成を表すマルチキャストツリーを ローカルのGreedyアルゴリズムを介して 生成するステップ であって、前記ビデオ会議のメンバーの各々はマルチキャストビデオ会議において前記データソースであり、前記マルチキャストツリーは、複数のビデオ会議メンバーを有する前記マルチキャストビデオ会議における前記データソースによって維持および制御され、前記電気データ通信構成により前記マルチキャストビデオ会議の他のデータソースまたは他のビデオ会議メンバーは前記ビデオ会議のデータソースからビデオおよびオーディオのデータを受信し、前記マルチキャストツリーは新たなビデオ会議メンバーを追加するように構成されている、ステップ と、 前記ビデオ会議の前記データソースから、前記ビデオ会議の前記メンバーの各々までの、エンド・ツー・エンド伝送遅延を判定するステップと、 前記ビデオ会議の前記データソースと前記ビデオ会議の前記メンバーの各々との間で利用可能な帯域幅を判定するステップと、 前記ビデオ会議の前記メンバーの各々に対応する前記エンド・ツー・エンド伝送遅延および利用可能な帯域幅にしたがって、前記マルチキャストツリーをリファインして、前記ビデオ会議における前記ビデオ会議のデータソースの前記データ通信構成を最適化するステップと を命令するコンピュータ実行可能命令を備えた 1つまたは複数のコンピュータ可読記憶媒体であって、 前記エンド・ツー・エンド伝送遅延および利用可能な帯域幅に基づいてリファインすることは、イントラ・ツリーリファインメントを行い、前記マルチキャストツリーのノードを当該マルチキャストツリー内で新しい親ノードに再構成し、応答して当該新しい親ノードの子ノードを再構成することを含み、ここで各ノードは前記ビデオ会議メンバーに対応する、 ことを特徴とする1つまたは複数のコンピュータ可読 記憶 媒体。
- 28命令が実行されると、前記ビデオ会議の前記データソースに対し、 前記マルチキャストツリーをリファインして、前記ビデオ会議における前記ビデオ会議の前記データソースのオーディオデータ通信を最適化するステップ を命令するコンピュータ実行可能命令をさらに備えたことを特徴とする請求項 27 に記載の1つまたは複数のコンピュータ可読記憶媒体。
- 29命令が実行されると、前記ビデオ会議の前記データソースに対し、 前記ビデオ会議の前記メンバーをマルチキャストツリーにおけるルートノードのノードとして含むマルチキャストツリーを生成するステップと、 前記マルチキャストツリーにおける前記ビデオ会議の前記メンバーを表すノードが前記ビデオおよびオーディオのデータを受信するために使用する通信リンクを再構成するステップとを命令するコンピュータ実行可能命令をさらに備えたことを特徴とする請求項 27 に記載の1つまたは複数のコンピュータ可読 記憶 媒体。
- 30命令が実行されると、前記ビデオ会議の前記データソースに対し、 前記ビデオ会議の前記データソースが前記マルチキャストツリーをリファインすることができるように、前記ビデオ会議の前記メンバーに対して、対応するマルチキャストツリーをリファインして追加の帯域幅を利用可能にするように最適化要求を起動するステップ を命令するコンピュータ実行可能命令をさらに備えたことを特徴とする請求項 27 に記載の1つまたは複数のコンピュータ可読 記憶 媒体。
- 31命令が実行されると、前記ビデオ会議の前記データソースに対し、 前記ビデオ会議の前記データソースが前記マルチキャストツリーにおける通信リンクを再構成することができるように、前記ビデオ会議の前記メンバーに対して、対応するマルチキャストツリーにおける通信リンクを再構成するように最適化要求を起動するステップ、を命令するコンピュータ実行可能命令をさらに備えたことを特徴とする請求項 27 に記載の1つまたは複数のコンピュータ可読 記憶 媒体。
- 32ビデオ会議のメンバーとして構成されるデータ受信者に対してビデオ会議データを通信する手段 であって、前記ビデオ会議のメンバーの各々はデータソースである、手段 と、 前記データ受信者のそれぞれから追加のビデオ会議データを受信する手段と、 前記ビデオ会議の前記データソースおよび前記データ受信者のデータ通信構成を表すマルチキャストツリーを ローカルのGreedyアルゴリズムで 生成する手段 であって、前記マルチキャストツリーは前記データソースによって維持され制御される、手段 と、 新たなデータ受信者を追加する要求を、帯域幅が利用可能になるまで保留する手段と、 前記データソースから前記データ受信者の各々までのエンド・ツー・エンド伝送遅延を判定する手段と、 前記データ受信者の各々に対応する前記エンド・ツー・エンド伝送遅延にしたがって、前記マルチキャストツリーをリファインして、前記ビデオ会議における前記データソースの前記データ通信構成を最適化する手段 であって、前記リファインすることは、イントラ・ツリーリファインメントを行うことであり、ビデオ会議の他のデータソースのマルチキャストツリーを用い、前記データソースのマルチキャストツリーのノードを再構成することを含む、手段 と を備えたことを特徴とするデータソース。
- 33前記データソースと前記データ受信者の各々との間で利用可能な帯域幅を判定する手段と、 前記データ受信者の各々に対応する前記利用可能な帯域幅にしたがって、前記マルチキャストツリーをリファインして 、前 記データソースの 前記 データ通信構成をさらに最適化する手段と をさらに備えたことを特徴とする請求項 32 に記載のデータソース。
- 34前記マルチキャストツリーをリファインして、前記データソースのオーディオデータ通信を最適化する手段をさらに備えたことを特徴とする請求項 32 に記載のデータソース。
- 35前記データソースを前記マルチキャストツリーのルートノードとし、前記データ受信者を前記マルチキャストツリーのノードとして含むマルチキャストツリーを生成する手段と、 前記マルチキャストツリーにおいて前記データ受信者を表すノードが前記ビデオ会議のデータを受信するために使用する通信リンクを再構成する手段と をさらに備えたことを特徴とする請求項 32 に記載のデータソース。
- 36前記データソースが前記マルチキャストツリーをリファインすることができるように、前記データ受信者に対して、対応するマルチキャストツリーをリファインして追加の帯域幅を利用可能にするように最適化要求を起動する手段をさらに備えたことを特徴とする請求項 32 に記載のデータソース。
- 37前記データソースが前記マルチキャストツリーにおける通信リンクを再構成することができるように、前記データ受信者に対して、対応するマルチキャストツリーにおける通信リンクを再構成するように最適化要求を起動する手段をさらに備えたことを特徴とする請求項 32 に記載のデータソース。
Independent claims37
71 paragraphs, as filed
The present invention relates to data communication for multi-party video conferencing, and more specifically to transmission optimization for application-level multicast.
The Internet has become an integral part of our daily lives and is often used as an electronic form of communication via email, instant messenger services, and similar text-based communication technologies. In addition, the demand for real-time, multi-party audio and video conferencing continues to grow, including for distance learning courses, telemedicine, other international business needs, and similar multicast video conferencing applications.
<p> In contrast to one-to-many content delivery systems, small-scale video conferencing applications typically run in a few-logarithmic semantics with up to 10 participants. Members of these video conferences, where any member may attend or leave the video conference and members may invite others to the video conference at any time, are subject to sudden changes. Each participant in a multicast video conference is a data source for video and audio data, and each participant is a data receiver for video and audio data from another participant.</p><p> Each participant in a video conference produces at least a video and audio media stream. Both use a lot of bandwidth. However, most Internet users have limited bandwidth connections that they use to communicate and receive video and audio data. In addition, video conferencing participants may have a wide variety of Internet connections such as dial-up, DSL, cable modems, and LAN connections. Continuous to provide optimal service to all participants in real-time, multicast video conferencing, especially when many participants have different bandwidths and different end-to-end communication delay times. There is demand.</p>
<p> Here, transmission optimization for application-level multicast will be described.</p><p> In one embodiment, a multicast tree is created for each attendee in the video conference. The multicast tree represents the data communication configuration of the data source and other members of the video conference. The other members are data recipients who receive video and audio from the data source. Determine the end-to-end transmission delay between any two members of a video conference and determine the bandwidth available between any two members of the video conference .. One or more multicast trees, each corresponding to one data source, are refined according to the end-to-end transmission delay and available bandwidth for a particular data source, and the data from that data source in a video conferencing. Optimize the communication configuration.</p>
The same numbers are used throughout the drawing to represent similar features and components.
Transmission optimization for application-level multicast is a distributed protocol, where video conferencing members are logically equal and each member controls their own multicast session during the video conferencing. Multicast sessions associated with a particular data source that is a video conferencing member are represented by a multicast tree, and each data source maintains a complete member list and manages its own multicast tree. The multicast tree is source-specific and represents the data communication configuration of video conferencing members for a particular data source.
Transmission optimization for application-level multicast provides real-time, multi-party video conferencing, especially emergency video conferencing with a small number of members. The end-to-end transmission delay from the data source (ie, the video conferencing member) to another video conferencing member is determined, as is the available bandwidth between the data source and another video conferencing member. To. Each of the multicast trees for each data source can then be refined according to the end-to-end transmission delay and available bandwidth for each video conferencing member.
The system and method aspects disclosed for transmission optimization for application-level multicast can be implemented in a number of different computing systems, environments, and / or configurations, but transmission optimization for application-level multicast. Examples of are described within the context of the following exemplary system architecture.
FIG. 1 illustrates an exemplary video conferencing system 100, each containing multiple data sources 102 (1N) implemented to communicate video conferencing data as members of a video conferencing. Each data source 102 provides video conferencing data, such as video and audio, about the video conferencing over communication network 104 and / or local network 106 (eg, data sources 102 (1) and 102 (2) are "local" to each other. Multicast to all of the other data sources 102 via).
Each data source 102 (1 to N) produces video conferencing data for communication to another data source, whereas each data source 102 (1 to N) is all of another data source. Or it is a data receiver of video conference data from many. Therefore, here, each data source 102 (1 to N) is also referred to as a data receiver 102 (1 to N), respectively. For example, the data source 102 (1) communicates the video conferencing data 108 (A) to the data receivers 102 (3 to N)) via the communication network 104 and transfers the video conferencing data 108 (B) to the local network 106. Communicates to data receiver 102 (2) via. Similarly, the data source 102 (4) communicates the video conference data 110 to all other data receivers 102 (1-3, ... N). Although not shown, each data source 102 (2-3, and N) is a video conferencing member communicating video conferencing data to each of all other data recipients.
The communication network 104 combines each of the data sources 102 (1 to N) to communicate with each other, by any data communication medium, an Internet Protocol (IP) connection, or a communication system having any protocol and / or messaging format. Can be implemented. For example, the communication network 104 can be implemented as a local area network (LAN), a wide area network (WAN), a public network such as the Internet, and / or a combination thereof. Although not shown, communication between devices in the video conferencing system 100 can also be realized through wired networks, radio frequency signals, over-air broadcasts, satellite communications, and the like. Transmission optimization for application-level multicast adapts to various data bit rates such as 28.8Kbps, 56Kbps, 128Kbps to communicate video conferencing data between video conferencing data sources 102 (1 to N). be able to.
Each of the data sources 102 (1 to N) is any form of computing system, electronic system with any number and combination of different components, as described with reference to the computing device 802 shown in FIG. , And / or may be implemented as a video conferencing system. For example, each of the data sources 102 (1N) contains an optimization logic 112 that performs transmission optimization for application-level multicast (only one example for data source 102 (2) is shown).
Optimization logic 112 for data source 102 generates a source-specific multicast tree 114. This source-specific multicast tree 114 includes the data source as a root node and represents a data communication configuration for another video conferencing member (ie, data receiver) data source. As will be described later with reference to FIGS. 2-6, the multicast tree can include the data receiver as a child node to the root node (ie, the data source), and the multicast tree is configured with multiple layers of nodes. can do. For example, in the multicast tree 114, the data source 102 (2) can communicate video and audio data to the data receiver 102 (4) via the data receiver 102 (3).
The optimization logic 112 (2) of data source 102 (1 to N) can determine the end-to-end transmission delay from data source 102 (2) to each data receiver, and any two. The end-to-end transmission delay between video conferencing members can be determined. In addition, the optimization logic 112 can determine the bandwidth available between the data source 102 (2) and each data receiver, and can be used between any two video conferencing members. The bandwidth that can be determined can be determined. For example, the data source 102 (4) communicates the video conference data 110 to the data receiver 102 (1) and also to the data receiver 102 (3) via the data receiver 102 (1). Between the data source 102 (4) and the data receiver 102 (1), between the data source 102 (4) and the data receiver 102 (3), and between the data receiver 102 (1) and the data receiver 102 ( The network dynamics to and from 3) can be determined (eg, end-to-end transmission delay and available bandwidth).
The optimization logic for a particular data source 102 then refines each multicast tree for data source 102 based on the end-to-end transmission delay and available bandwidth for each data receiver, and that data. Optimize the data communication configuration of source 102. Each data source 102 (1 to N) of the video conferencing system 100 implements a version of their optimization logic 112 to optimize the data communication configuration of each data source and also for video conferencing video conferencing data communication. It also optimizes overall performance.
Figures 2A-2D show configuration options for a multicast session when a new member 202 joins a video conference and submits a request to receive video conference data from a particular data source 204, as the multicast tree 200. Represent. A multicast session is represented by a multicast tree for a particular data source in a video conference. The multicast tree is first constructed by the local Greedy algorithm and then refined as described in the Transmission Optimization example for application-level multicast. Multicast trees are built and refined based on end-to-end transmission delays and available bandwidth between data sources and each data receiver.
FIG. 2A shows a multicast tree 200 that includes data source 204 as the root node and represents the data communication configuration for data sources 204 of data receivers 206 (A) and 206 (B) from the perspective of data source 204. Data source 204 communicates video conferencing data, such as video and audio data, to data recipients 206 (A) and 206 (B) during the video conferencing. For example, data source 204 represents data source 102 (1) in the video conferencing system 100 shown in FIG. 1, and data recipients 206 (A) and 206 (B) are data recipients 102 (2) and 102 (respectively). It can be said that it represents 3). Similar to the multicast tree 200, which represents a multicast session from the perspective of the data source 204, each of the data receivers 206 (A) and 206 (B) is when the data receiver transmits its own video and audio data. It can be represented using a multicast tree that shows the data communication configuration.
The new member 202 submits to the data source 204 a participation request 208 to join the video conference as a data receiver of the video conference from the data source 204. Upon receiving the join request 208, the data source 204 adds the new member 202 to the multicast tree 200. A new member 202 has been added to allow video conferencing data to be received from data source 204 based on one of the multicast trees shown in Figures 2B-2D.
FIG. 2B shows a multicast tree 210 for a multicast session associated with data source 204 when a new member 202 is added to data source 204 as data receiver 206 (C) using a direct communication link. When the data source 204 has sufficient bandwidth to accommodate a direct connection, the new member 202 is functionally linked to the root node of the multicast tree 210 (eg, the data source 204). When a new member 202 cannot be added to the multicast tree 210 using a direct communication link to the data source 204 as shown in FIG. 2B, the new member 202 is shown in the multicast tree 212 shown in FIG. 2C or in FIG. 2D. It can be added to the multicast tree 214.
Figure 2C relates to data source 204 when a new member 202 is added as data receiver 206 (C) over a communication link via a configured data receiver without changing the existing communication link. Shows the multicast tree 212 for the multicast sessions that have been made. For example, the new member 202 has been added as data receiver 206 (C) over a communication link via data receiver 206 (A). Existing communication links from data source 204 to data recipients 206 (A) and 206 (B) remain unchanged in this representation of the multicast session.
Figure 2D shows a multicast tree for a multicast session associated with data source 204 when a new member 202 is added as data recipient 206 (C) and an existing (s) communication link is reconfigured. Indicates 214. For example, the new member 202 is added as data receiver 206 (C) and replaces data receiver 206 (B) which has a direct communication link to data source 204. At this time, the data receiver 206 (B) is configured via a communication link via the data receiver 206 (C).
As mentioned above, the multicast tree is built on the end-to-end transmission delay and bandwidth measurements between the data source and each data receiver. The new member 202 is the data receiver of the multicast tree configurations 210, 212, 214 that is farthest from the data source 204 (for example, new data receiver 206 (C) in configuration 212 or data receiver 206 (B) in configuration 214). Can be added as data receiver 206 (C) for configurations that give the minimum transmission delay to transmit video conferencing data up to. In addition, when adding new members, the optimization costs can be determined or associated with each of the multicast tree configurations 210, 212, 214, respectively.
For example, a multicast tree 210 (FIG. 2B) has a shorter end-to-end transmission delay from data source 204 to data receiver 206 (C) (ie, data source 204 directly feeds video conferencing data). It communicates with the data receiver 206 (C)), which is more suitable than the multicast tree 212 (Fig. 2C). However, the configuration of the multicast tree 212 may be chosen if the optimization cost does not exceed the implementation-specific threshold. In addition, the multicast tree 212 (FIG. 2C) is more preferred than the multicast tree 214 (FIG. 2D) in terms of system stability because the existing communication links to the data receivers 206 (A) and 206 (B) are unchanged.
When a new member submits a join request 208 to join a video conference, the bandwidth and / if none of the video conference members in the multicast tree 200 has the bandwidth available for the addition of the new member 202. Alternatively, join request 208 can be queued in the queue until configuration options are available. In addition, the data source 204 can distinguish between video and audio data streams and enroll new members who receive only audio data until additional bandwidth is available. While video enhances video conferencing participation, audio is needed to communicate with participants when hosting video conferencing. The data source 204 can distinguish between video and audio data streams by constructing separate multicast trees for different video and audio data streams. In addition, the data source 204 can modify the existing communication link with the data receiver to provide additional bandwidth to meet the participation request from the new member 202.
Initially, the multicast tree for each data source may show the consequences of disproportionate bandwidth utilization among video conferencing members in video conferencing. In addition, each multicast session may change abruptly as network dynamics fluctuate while video conferencing members sign up for and unsubscribe from the video conferencing and disconnect from the video conferencing. In this way, refine the multicast tree for the data source based on end-to-end transmission delay and available bandwidth to optimize performance and avoid incorporating recognizable jitter into video conferencing.
Various techniques for multicast tree refinement include the regular multicast tree refinement described below with reference to FIGS. 3A-3D, the intra-multicast tree refinement described below with reference to FIGS. 4A and 4B, and the figure. Includes intermulticast tree refinements described below with reference to 5A and 5B and Figures 6A and 6B.
Figures 3A-3D show an example of regular multicast tree refinement for video conferencing members in an example of transmission optimization for application-level multicast. In FIG. 3A, the multicast tree 300 represents a multicast session associated with a video conferencing member identified as data source 302 (A) communicating video conferencing data to data receiver 302 (B). In this example, the data source 302 (A) has a bandwidth capacity capable of communicating video and audio data to only one data receiver 302 (B). When a new video conferencing member, Data Recipient 302 (C), submits a join request to Data Source 302 (A), Data Source 302 (A) holds Data Recipient 302 (C) on hold. FIG. 3B shows that the bandwidth capacity of data source 302 (A) is increased so that data source 302 (A) can communicate video and audio to both data recipients 302 (B) and (C). Shows the regular refinement of the multicast tree 300 when becomes.
FIG. 3C shows another example of a multicast tree 304 representing a multicast session associated with a video conferencing member shown as data source 306 (A) communicating video conferencing data to data recipient 306 (B). In this example, the data source 302 (A) has a bandwidth capacity capable of communicating video and audio data to only one data receiver 306 (B). However, data source 306 (A) may communicate video and audio data to a second data receiver 306 (C), which also communicates video and audio data to only one data receiver. Communication can be performed via a communication link via the first data receiver 306 (B) having a possible bandwidth capacity.
In this example, there is an end-to-end transmission delay of 500 ms (milliseconds), or latency, to communicate video conference data from the data source 306 (A) to the data receiver 306 (B). In addition, there is an end-to-end transmission delay of 500 ms (milliseconds) for communicating video conferencing data from data receiver 306 (B) to data receiver 306 (C). The total delay from data source 306 (A) to data receiver 306 (C) is 1000ms (ie 1 second), but we refined the multicast tree 304 of data source 306 (A) to end-to-end 1000ms. The transmission delay can be improved.
In Figure 3D, the bandwidth of data source 306 (A) is increased so that data source 306 (A) can communicate video conferencing data directly to both data recipients 306 (B) and 306 (C). Here is the regular refinement of the multicast tree 304 when it becomes. In addition, video conferencing members 306 (A) and 306 (C) are local to the same communication network (eg, within the same domain), so between the data source 306 (A) and the data receiver 306 (C). The end-to-end transmission delay is only 20ms. Therefore, the overall end-to-end transmission delay for data source 306 (A) was reduced by 500 ms (ie, from 1000 ms to 500 ms). The 20ms and 500ms end-to-end transmission delays are merely exemplary and schematic, and are described here in a number of examples to illustrate various multicast tree refinements and improvements in video conferencing communications.
Although not shown, an alternative to the refinement of multicast tree 304 is that data source 306 (A) communicates video conferencing data to data receiver 306 (C), which in turn transfers that video conferencing data to data receiver 306 (B). ) To communicate with the data distribution configuration. Since the data source 306 (A) and the data receiver 306 (C) are in the same domain, the end-to-end transmission delay from the data source 306 (A) to the data receiver 306 (C) is 20 ms. The overall end-to-end transmission delay for data source 306 (A) remains 480ms (ie, 1000ms), while the end-to-end transmission delay from data receivers 306 (C) to 306 (B) remains at 500ms. Will decrease (from to 520ms). This is an example of an intra-multicast tree refinement described further with reference to Figures 4A and 4B. For intra-multicast tree refinement, the existing communication link is reconfigured, as is the case when the data receivers 306 (B) and 306 (C) are switched in the refinement of the multicast tree 304.
End-to-end transmission delays and available bandwidth between conference members are not unchanged during a video conference. Therefore, during video conferencing, two metrics are measured periodically to optimize video conferencing data communication. Each data source can determine the available bandwidth of a communication connection to another video conferencing member using the Packet-Pair method for determining the available bandwidth of the data source. Each data source can also probe another video conferencing member to determine the end-to-end transmission delay between that data source and another video conferencing member.
In one embodiment, the data source can generate a probe message every 5 seconds to determine the end-to-end transmission delay between the data source and another video conferencing member. Probe messages can also help detect communication problems with other video conferencing members. If a video conferencing member does not respond to the probe message within the implementation-specific specified time, the data source can determine that the video conferencing member has a network communication failure.
Figures 4A and 4B show an example of intra-multicast tree refinement of video conferencing members in an example of application-level multicast transmission optimization. In FIG. 4A, the multicast tree 400 represents a multicast session associated with a video conferencing member identified as data source 402 (A) communicating video conferencing data to multiple data recipients. In this example, data source 402 (A) has bandwidth to communicate video and audio data to three data receivers 402 (B), 402 (C), 402 (D). In addition, the data receivers 402 (B) and 402 (C) each have bandwidth capacity to communicate video and audio data to additional data receivers. The data receiver 402 (E) has a bandwidth capacity capable of supporting only one data receiver 402 (E) from the data source 402 (A) for video and audio data (data receiver 402 (B)). Receive via a communication link via.
In this example, 500 ms end-to-end transmission to communicate video conferencing data from the data source 402 (A) to each of the data receivers 402 (B), 402 (C), 402 (D). There is a delay. In addition, there is an end-to-end transmission delay of 500 ms for communicating video conferencing data from the data receiver 402 (B) to the data receiver 402 (E).
Assume that data source 402 (A) and data receiver 402 (E) are connected within the same domain so that the end-to-end transmission delay between these two video conferencing members is only 20 ms. .. Similarly, data recipients 402 (B), 402 (C), 402 (D) are connected within a local communication network and end-to-end transmission between any two of the three video conferencing members. The delay is assumed to be only 20ms.
Figure 4B shows the intra-multicast tree 400 (Figure 4A) generating a multicast tree 404 (Figure 4B) refined to take advantage of shorter end-to-end transmission delays (eg 20ms is shorter than 500ms). It is a figure which shows the tree refinement. In this example, the data receiver 402 (E) replaces the data receiver (D) having a direct communication link from the data source 402 (A). Thus, the data receiver 402 (D) is configured to receive video and audio data from the data source 402 (A) via a communication link via the data receiver 402 (C).
In the refined multicast tree 404, the end-to-end transmission delay between data sources 402 (A) and 402 (E) is only 20 ms. In addition, the end-to-end transmission delay between data receivers 402 (C) and 402 (D) is only 20 ms, so the overall end from data source 402 (A) to data receiver 402 (D). The two-end transmission delay is 520ms. Thus, the overall end-to-end transmission delay for a multicast tree 404 is reduced by 480ms (ie, from 1000ms for ABE in multicast tree 400 to 520ms for ACD in multicast tree 404).
Although not shown, an alternative to the refinement of a multicast tree 404 is data configured to receive video conferencing data from data source 402 (A) over a communication link via data receiver 402 (B). Recipient 402 (D) can be included. Since the data receivers 402 (B) and 402 (D) are connected within the local communication network as described above, the overall end-to-end transmission delay for the multicast tree 404 is still 520 ms (ie, the multicast tree 404). 520ms of ABD in. In practice, the data receiver 402 (D) actually determines whether the end-to-end transmission delay of the data receiver 402 (B) or the data receiver (C) can provide the optimum communication performance. This can be configured to receive video conferencing data via a communication link via data receiver 402 (B) or data receiver (C).
The intra-multicast tree refinement shown in Figures 4A and 4B is shown in Figures 3A-3D in that the intra-multicast tree refinement reconfigures the data receiver and the existing communication link to reduce the end-to-end transmission delay. Different from the regular refinement shown. For example, in a multicast tree 404, the data receiver 402 (E) is replaced by the data receiver 402 (D) and the existing communication link is modified to achieve better video conferencing performance.
Figures 5A and 5B show an example of intermulticast tree refinement for video conferencing members in an example of transmission optimization for application-level multicast. In FIG. 5A, video conferencing 500 includes multicast 502, which represents a multicast session from the perspective of a video conferencing member identified as a data source 504 (A) that communicates video conferencing data to several data recipients. .. Video conferencing 500 also includes multicast 506, which represents a multicast session from the perspective of the video conferencing member identified as the data source 504 (C) communicating with the data receiver.
In this example, data source 504 (A) has bandwidth capable of communicating video and audio data to two data receivers 504 (B) and 504 (C) in the multicast tree 502. .. In addition, the data receiver 504 (B) has bandwidth capacity that allows video and audio data to be communicated from the data source 504 (A) to the additional data receiver 504 (D). The data source 504 (C) in the multicast tree 506 has a bandwidth capacity capable of communicating video conference data to two data receivers 504 (D) and 504 (E). As mentioned above, the data source is sometimes referred to as the data receiver, so in this example, the data source 504 (C) in the multicast tree 506 is also the data receiver 504 (C) in the multicast tree 502.
In this example, the data source 504 (A) and the data recipients 504 (C), 504 (D) and 504 (E) should have an end-to-end transmission delay of only 20 ms between any video conferencing member. Are connected within the same network domain. The data receiver 504 (B) connects to the video conference over different networks so that the end-to-end transmission delay between the data receiver 504 (B) and the other video conference members is 500 ms. Has been done. Therefore, there is a delay of 1000 ms from the data source 504 (A) to the data receiver 504 (D) via the communication link via the data receiver 504 (B).
To enhance the performance of the video conferencing 500 and minimize the overall end-to-end transmission delay of 1000ms in the multicast tree 502, the data source 504 (A) is the data source 504 (C) of the multicast tree 506. ), Submit the optimization request 508. In response to optimization request 508, data source 504 (C) can reconfigure multicast tree 506 so that data source 504 (A) can reconfigure multicast tree 502.
FIG. 5B shows the intermulticast tree refinement of the multicast tree 502 that generates the refined multicast tree 510 and the intermulticast tree refinement of the multicast tree 506 that generates the refined multicast tree 512 in video conferencing 500. Is. In the refined multicast tree 512, the data receiver 504 (E) receives video and audio data from the data source 504 (C) over a communication link via the data receiver 504 (D). In the refined multicast tree 510, the data receiver 504 (D) receives video and audio data from the data source 504 (A) over a communication link via the data receiver 504 (C). .. The overall end-to-end transmission delay of the multicast tree 512 is increased by 20ms up to 40ms, while the multicast tree 510 is improved by only 500ms (ie, from 1000ms for ABD to 500ms for AB).
Figures 6A and 6B show another example of intermulticast tree refinement for video conferencing members in one embodiment of transmission optimization for application-level multicast. In FIG. 6A, the video conferencing 600 includes a multicast tree 602 representing a multicast session from the perspective of the video conferencing member identified as the data source 604 (A) communicating the video conferencing data to several data recipients. There is. The video conferencing 600 also includes a multicast tree 606 representing a multicast session from the perspective of data source 604 (C), which also communicates video and audio data to the data source 604 ( From the point of view of B), it includes a multicast tree 608 representing a multicast session.
In this example, data source 604 (A) has bandwidth capacity capable of communicating video and audio data to two data receivers 604 (B) and 604 (C). In addition, the data receiver 604 (B) has bandwidth that allows video and audio data to be communicated from the data source 604 (A) to the additional data receiver 604 (D). The data source 604 (B) has a bandwidth capacity capable of communicating video and audio data to the data receivers 604 (D) and 604 (E). In addition, the data receiver 604 (C) has bandwidth that allows video and audio data to be communicated from the data source 604 (B) to the additional data receiver 604 (A). As mentioned above, the data source is sometimes referred to as the data receiver, so in this example, the data source 604 (A) in the multicast tree 602 is also the data receiver 604 (A) in the multicast tree 608. In addition, the data source 604 (C) in the multicast tree 606 is also the data receiver 604 (C) in the multicast trees 602 and 608.
In this example, the video conferencing members 604 (A), 604 (C), 604 (D) and 604 (E) will also have an end-to-end transmission delay of only 20ms between any two video conferencing members. Are connected within the same network domain. The data receiver 604 (B) and the video conference 600 over different networks so that the end-to-end transmission delay between the data receiver 604 (B) and the other video conference members is 500 ms. It is connected. Therefore, there is a delay of 1000 ms from the data source 604 (A) to the data receiver 604 (D) via the communication link via the data receiver 604 (B).
To enhance the performance of the video conferencing 600 and minimize the overall end-to-end transmission delay of 1000ms in the multicast tree 602, the data source 604 (A) is the data source 604 (C) of the multicast tree 606. ), Submit the optimization request 610. Data source 604 (C) forwards optimization request 612 to data source 604 (B) because the multicast tree 606 cannot be reconfigured in response to optimization request 610. Multicast tree 608 is reconfigured so that multicast tree 602 can be reconfigured in response to forwarded optimization request 612.
Figure 6B shows the intermulticast tree refinement of multicast tree 602, which produces refined multicast tree 614, and the intermulticast tree refinement of multicast tree 608, which produces refined multicast tree 616, in video conferencing 600. It is a figure. In the refined multicast tree 616, data receiver 604 (A) receives video and audio data from data source 604 (B) over a communication link via data receiver 604 (E). In the refined multicast tree 614, data receiver 604 (D) receives video and audio data from data source 604 (A) over a communication link via data receiver 604 (C). Even though the 520ms overall end-to-end transmission delay for multicast tree 616 has not changed, multicast tree 614 has been improved by only 500ms (ie, from 1000ms for ABD to 500ms for AB).
A method for transmission optimization for application-level multicast, such as the exemplary method 700 described with reference to FIG. 7, is described as the general context of computer executable instructions. In general, computer-executable instructions include routines, programs, objects, components, data structures, procedures, modules, functions, etc. that perform specific functions or perform specific abstract data types. .. This method can also be implemented in a distributed computing environment in which functions are performed by remote processing devices connected through a communication network. In a distributed computing environment, computer-executable instructions can be placed on both local and remote computer storage media, including memory storage devices.
Figure 7 shows an exemplary method 700 for transmission optimization for application-level multicast. The order in which this method is described is not intended to be construed as limiting, and any number of blocks of the method described can be combined in any order to carry out this method. Moreover, this method can be performed with any suitable hardware, software, firmware, or a combination thereof.
At block 702, generate a multicast tree for each data source member of the video conference. The data source's multicast tree represents the data communication configuration of the data source and the video conferencing members who receive video and audio data from that data source during the video conferencing. For example, the optimization logic 112 (Figure 1) includes the data source 102 (2) as the root node of the multicast tree 114, and the data recipients 102 (1), 102 (3), 102 (4), and 102 (N). ) As a child node in the multicast tree 114 to generate a multicast tree 114.
At block 704, the end-to-end transmission delay from each data source to each of the video conferencing members is determined. For example, the optimization logic 112 of data source 102 generates a probe message every 5 seconds to end between the data source and another member of the video conferencing that receives video and audio data from that data source. -Two-end transmission delay can be determined. At block 706, determine the bandwidth available between each data source and each of the video conferencing members. For example, the optimization logic 112 of data source 102 uses the Packet-Pair method to determine the available bandwidth between a data source for video conferencing data and a data receiver to make a communication connection to another video conferencing member. Determine the available bandwidth of.
At block 708, refine one or more multicast trees corresponding to video conferencing members based on the end-to-end transmission delay determined between each data source and each video conferencing member. At block 710, refine one or more multicast trees for each video conferencing member based on the bandwidth available for each data source and each video conferencing member.
For example, the optimization logic 112 for a particular data source refines the associated multicast tree to optimize the data communication configuration of the data source in video conferencing. Refining the multicast tree can include reconfiguring the communication links used by child nodes representing video conferencing members in the multicast tree to receive video and audio data. In addition, one or more multicast trees can be refined to optimize audio data communications for video conferencing. Multicast tree refinement also refines the corresponding multicast tree to make additional bandwidth available so that the first data source can refine the associated multicast tree. An optimization request for a data source may include invoking the first data source.
FIG. 8 shows various components of an exemplary computing device 800 that can be implemented as any one of multiple data sources 102 (1N) in the exemplary video conferencing system 100 shown in FIG. .. The computing system 800 includes a computing device 802 in which any number of examples can be implemented using a number of different general purpose or dedicated computing system environments or configurations. Known computing systems, environments and / or configurations that can be implemented in an exemplary computing system include personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, and settop boxes. , Programmable home appliances, network PCs, digital video recorders (DVRs) and playback devices, game consoles, distributed computing environments including, but not limited to, any of the systems or devices described above.
The computing device 802 is one or more media content inputs, including an Internet Protocol (IP) input, where media content is received over an IP-based network (eg, the communication network 104 shown in Figure 1). including. The media content input 804 also includes a tuner capable of receiving television signals in tune with various frequencies or channels when the computing device 802 is embodied as, for example, a set-top box or digital video recorder. The media content input 804 is one or more processors 806 (eg, any microprocessor, controller, etc.) that process various instructions to control the operation of the computing device 802 and communicate with other electronic or computing devices. Also includes.
The computing device 802 is implemented with one or more memory components 808. Examples of memory component 808 include random access memory (RAM), non-volatile memory (eg, any one or more read-only memory (ROM), flash memory, EPROM, EEPROM, etc.) and disk storage. included. Disk storage can include any form of magnetic or optical storage, such as a hard disk drive, recordable and / or rewritable compact disc (CD), DVD, DVD + RW, and the like. The memory component 808 comprises a data storage mechanism and various information and / or data such as received media content, software applications, and any other type of information and data related to the behavior of the computing device 802. Remember.
The operating system 810, browser application 812, and video conferencing application 814 are all maintained as software applications using the non-volatile memory component 808 and run on the processor (s) 806. The browser application 812 provides a user interface through which users can interact and browse the web (eg, the World Wide Web) over the Internet. The video conferencing application 814 facilitates video and audio conferencing communication and provides a user interface through which video conferencing members can interact with the data source 102 in the video conferencing system 100 shown in FIG. ..
In this example, the optimization logic 816 is also software that runs on the processor (s) to implement transmission optimization for application-level multicast using the non-volatile memory component 808. It is retained as a wear application. The optimization logic 816 is an example of the optimization logic 112 shown in FIG. 1 for the data source 102 (2). As mentioned above, the optimization logic 816 for a particular data source (eg, optimization logic 112) generates a source-specific multicast tree for the data source in the video conferencing and between any two video conferencing members. Determine network dynamics (eg, end-to-end transmission delay and available bandwidth). The optimization logic 816 for a particular data source then refines each multicast tree based on the end-to-end transmission delay and available bandwidth for each data receiver of the video conferencing data. Optimize the data communication configuration for that data source.
Although the optimization logic 816 is illustrated and described as a single application, the optimization logic 816 is implemented as several component applications that are distributed and each perform one or more functions in an exemplary computing system 800. can do. Further, the optimization logic 816 may be implemented on a device other than the computing device 802. In this case, another device is also configured to communicate with the computing device 802 in the computing system 800.
As used herein, the term "logic" (eg, optimization logic 816) refers to hardware, firmware, or hardware implemented to perform logical operations related to an embodiment of an anonymous alias. It can also refer to software, or a combination thereof. Logic can also include any supporting circuit that is used to accomplish a given task, including supportive non-logical operation. Logic may also include, for example, analog circuits, memory components, input / output (I / O) circuits, interface circuits, power supply / regulation circuits, and the like.
The computing device 802 further includes (s) communication interfaces 818 and modem 820. The communication interface (s) 818 is any one or any of a serial and / or parallel interface, a wireless interface, any type of network interface, and any other type of communication interface. It can be implemented by multiple devices. With a wireless interface, the computing device 802 can send a control input command and other information to a remote control device or another infrared (IR), 802.11, Bluetooth, or similar RF input device. It can be received from the input device.
The network interface provides a connection between the computing device 802 and the communication network 104, thereby providing another electronic device and computing device connected to the communication network 104 (eg, each data source 102 (1 to N)). )) Communicates configuration information as well as audio and video data to the computing device 802. Similarly, serial and / or parallel interfaces provide a direct data communication path between a computing device 802 and another electronic or computing device. Modem 820 facilitates computing device 802 to communicate with another electronic or computing device over traditional telephone lines, DSL connections, cables, and / or other types of connections. Also, although not shown, the computing device 802 is a user input device and other such as a keyboard, mouse, pointing device, and / or other mechanism for interacting with the computing device 802 to enter information. Also includes an input device.
The computing device 802 also includes a content processor 822, which can include a video decoder and / or an additional processor that receives, processes, and decodes media content and displays the data. The computing device 802 also includes an audio and / or video input / output device 824, which processes and displays audio and video to the audio rendering and / or display device 826, or processes and displays audio and video. / Or provide it to other devices that render audio, video in another way to present the data. Also, the audio and / or video input / output device 824 receives audio and video input from the camera device 828, facilitating the opening of a video conference. Video and audio signals are delivered from compute device 802 to display device 826 and from camera device 828 to compute device 802: RF (radio frequency) link, S-video link, composite video link, component video link, analog. Communicated via an audio connection or similar communication link.
Although shown separately, some of the components of computing device 802 may be implemented in application-specific integrated circuits (ASICs). In addition, a system bus (not shown) typically connects various components within computing device 802. The system bus can be any one or more of several types of bus structures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports (AGPs), or local buses that utilize any of the various bus architectures. Can be implemented as.
Although examples of transmission optimization for application-level multicast have been described in structural features and / or methods in specific terminology, the appended claims gist does not necessarily describe the particular features or methods. It should be understood that it is not limited to. Rather, the unique features or methods are disclosed as an example of the implementation of transmission optimization for application-level multicast.
<figref num="1">FIG. 5 illustrates various components of an exemplary video conferencing system that can implement transmission optimization embodiments for application-level multicast.</figref><figref num="2A">It is a figure which shows the multicast tree composition about the multicast session of the data source in the example video conferencing system shown in FIG.</figref><figref num="2B">It is a figure which shows the multicast tree composition about the multicast session of the data source in the example video conferencing system shown in FIG.</figref><figref num="2C">It is a figure which shows the multicast tree composition about the multicast session of the data source in the example video conferencing system shown in FIG.</figref><figref num="2D">It is a figure which shows the multicast tree composition about the multicast session of the data source in the example video conferencing system shown in FIG.</figref><figref num="3A">FIG. 5 illustrates an example of regular multicast tree refinement for video conferencing members in the implementation of transmission optimization for application level multicast.</figref><figref num="3B">FIG. 5 illustrates an example of regular multicast tree refinement for video conferencing members in the implementation of transmission optimization for application level multicast.</figref><figref num="3C">FIG. 5 illustrates an example of regular multicast tree refinement for video conferencing members in the implementation of transmission optimization for application level multicast.</figref><figref num="3D">FIG. 5 illustrates an example of regular multicast tree refinement for video conferencing members in the implementation of transmission optimization for application level multicast.</figref><figref num="4A">FIG. 5 illustrates an example of Ntra-Multicast Etree Refinement for video conferencing members in the implementation of transmission optimization for application-level multicast.</figref><figref num="4B">FIG. 5 illustrates an example of Ntra-Multicast Etree Refinement for video conferencing members in the implementation of transmission optimization for application-level multicast.</figref><figref num="5A">FIG. 5 illustrates an example of intermulticast tree refinement for video conferencing members in performing transmission optimization for application-level multicast.</figref><figref num="5B">FIG. 5 illustrates an example of intermulticast tree refinement for video conferencing members in performing transmission optimization for application-level multicast.</figref><figref num="6A">FIG. 5 illustrates another example of intermulticast tree refinement for video conferencing members in the implementation of transmission optimization for application-level multicast.</figref><figref num="6B">FIG. 5 illustrates another example of intermulticast tree refinement for video conferencing members in the implementation of transmission optimization for application-level multicast.</figref><figref num="7">FIG. 5 is a flow diagram illustrating an exemplary method in a transmission optimization embodiment for application-level multicast.</figref><figref num="8">FIG. 5 illustrates various components of an exemplary computing device that can be implemented as any one of a plurality of data sources and / or data receivers in the exemplary video conferencing system shown in FIG. ..</figref>
Code description
102 (1 ~ N) data source 104 Communication network 106 Local network 108 (A, B), 110 Video conferencing data 112 Optimization logic 114 Multicast tree
17 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17
Every citation, both waysCites: the store holds 0 of 1
| Reference | Relation |
|---|---|
| 情報処理学会第66回全国大会 2W-7 | Non-patent |
| 信学技報 IN2002-43 | Non-patent |
| IEEE Network,Vol.17 No.1,p46-51 | Non-patent |
| 3rd USENIX Symposium on Internet Technologies and Systems,2001年 3月26日,URL,http://www.usenix.org/publications/library/proceedings/usits01/shi.html | Non-patent |
| Fourth Symposium on Operating Systems Design and Implementation,2000年10月24日,URL,http://www.usenix.org/publications/library/proceedings/osdi2000/jannotti.html | Non-patent |
| 信学技報 NS2003-28 | Non-patent |
8 members in 4 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 10912488 | United States of America | – | |
| 91248804 | United States of America | A | |
| 91248804 | United States of America | A | |
| 2004912488 | – | – | – |
| US20040912488 | – | – | – |
Members8
| Document | Office | Kind | |
|---|---|---|---|
| EP1624632A1 | European Patent Office (EPO) | A1 | |
| US2006029092A1 | United States of America | A1 | |
| JP2006050639A | Japan | A | |
| US7760659B2 | United States of America | B2 | |
| JP4721809B2This record | Japan | B2 | |
| EP1624632B1 | European Patent Office (EPO) | B1 | |
| AT527786T | Austria | T | |
| ATE527786T1 | Austria | T1 |
22 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313113S111 | S111 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 4721809
- Publication, DOCDB
- 4721809
- Publication, EPODOC
- JP4721809B
- Application
- 226976
- Application, DOCDB
- 2005226976
- Application, EPODOC
- JP20050226976
Titles2
- Japanese
- アプリケーションレベルのマルチキャストのための伝送最適化
- English
- Transmission optimization for application-level multicast
Classification
- CPC, 13
- H04L65/403
- H04L12/1827
- H04L12/185
- H04L12/1886
- H04L45/12
- H04L45/16
- H04L45/48
- H04M3/567
- H04M7/006
- H04M2203/5009
- H04N7/152
- H04L65/4046
- H04L65/1101
- IPC, 1
- H04L12 56
