(57)【要約】【課題】ピアのそれぞれが交代して音声のミキシング、圧縮、およびその圧縮音声の再配信を行う、サーバレスピアツーピア（Ｐ２Ｐ）マルチパーティリアルタイム音声通信システムを提供すること。【解決手段】入力音声ストリームがフレームに区分または分割される。各フレームにおいて、１つのピアノードが選択され、音声をミキシングしてネットワーク内の残りのピアに再配信する。あるピアによってミキシングおよび再配信されるフレーム数は、そのピアの利用可能な資源（アップロード帯域幅または計算能力など）に比例する。Ｐ２Ｐ音声通信システムおよび方法は、ピアの負担を柔軟に均衡させて、より多くの資源を有するピアがより少ない資源を有するピアを支援できるようにする。これによって、Ｐ２Ｐ音声通信システムおよび方法は、高性能なサーバまたはピアを必要とすることなく、マルチパーティ音声通信セッションを実行することが可能となる。【選択図】図４
2006268844.tif 000002
【特許請求の範囲】
【請求項１】
ピアツーピアコンピュータネットワーク内のピアノードを使用する、マルチパーティリアルタイム通信セッションの方法であって、
入力ストリームを複数のフレームに区分することと、
各フレームを、ピアノードがそのピアノードの利用可能な資源に比例する数のフレームを受け取るように、前記ピアノードに割り当てることと、
前記複数のフレームの処理を、前記ピアノードの少なくとも一部の間で交代させて、マルチパーティリアルタイム通信セッションを提供することと
を含むことを特徴とする方法。
【請求項２】
前記複数のフレームの処理を交代させることは、前記入力ストリームの少なくとも一部を、ラウンドロビン方式でミキシングおよび再配信することをさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記入力ストリームは、（ａ）音声コンテンツを含む到着音声ストリーム、（ｂ）音声コンテンツを含む到着マイクロフォン信号、の少なくとも一方であって、前記音声コンテンツをミキシングおよび再配信することをさらに含むことを特徴とする請求項２に記載の方法。
【請求項４】
ミキシングすることは、
（ａ）前記到着音声ストリームをエントロピーデコードおよび逆量子化してエンコード音声係数パケットを生成すること、（ｂ）前記到着マイクロフォン信号を音声係数ブロックに変換すること、のいずれかを実行することと、
前記音声係数パケットとブロックを結合して、あるフレームに対する前記係数パケットとブロックの組合せである、合成係数ブロックを生成することと
をさらに含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記合成係数ブロックを量子化することと、
前記量子化合成係数ブロックをリエンコードしてミックス音声パケットを生成することと
をさらに含むことを特徴とする請求項４に記載の方法。
【請求項６】
前記ミックス音声パケットをデコードすることと、
前記デコードミックス音声パケットを逆量子化してミックス変換係数を得ることと、
前記ミックス変換係数に逆変換を適用してミックス音声コンテンツを含む音声ストリームを生成することと
をさらに含むことを特徴とする請求項５に記載の方法。
【請求項７】
前記音声ストリームおよびマイクロフォン信号が送られるあるピアノードを除き、ピアノードのそれぞれからの音声コンテンツを、ミキシングおよび再配信することをさらに含むことを特徴とする請求項３に記載の方法。
【請求項８】
（ａ）音声コンテンツを含む前記到着音声ストリーム、（ｂ）音声コンテンツを含む前記到着マイクロフォン信号、の少なくとも一方をミキシングおよび再配信することと、
エコーを低減するために、各ピアノードに、ミックス音声コンテンツからそれ自体の音声コンテンツを差し引かせることと
をさらに含むことを特徴とする請求項３に記載の方法。
【請求項９】
完全接続メッシュを形成するピアノード群としてクリークを定義することと、
前記クリークがマルチパーティリアルタイム通信セッションにおいてスーパーゲートウェイノードとしての役割を果たすように、前記クリークを配置することと
をさらに含むことを特徴とする請求項１の記載の方法。
【請求項１０】
完全接続メッシュを形成するピアノード群としてクリークを定義することと、
前記クリークが、マルチパーティリアルタイム通信セッションにおいてクライアントノードとして作用する追加ノードを有するスタートポロジにおいて、スーパーサーバとしての役割を果たすように、前記クリークを配置し、それによってクライアントノードがミキシングタスクを免除されるようにすることと
をさらに含むことを特徴とする請求項１の記載の方法。
【請求項１１】
請求項１に記載のコンピュータ実施方法を実行するためのコンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
【請求項１２】
ピアツーピアコンピュータネットワークにおいて、それぞれが音声ストリームを有するピアノード間で、マルチパーティリアルタイム音声通信セッションを行うためのコンピュータ実施処理であって、
前記ピアノードのそれぞれからの音声ストリームを音声パケットに分割するためのパケット分割ステップと、
前記ピアノードのそれぞれからの、ある時刻からの音声パケットを結合して、その時刻のミックス音声パケットを生成する、音声ミキシングステップと、
前記ピアノードの少なくとも一部が、音声ミキシングおよび再配信を交代して実行するように、交代方式で前記ピアノードのそれぞれに、ミックス音声パケットの音声ミキシングと前記ミックス音声パケットの再配信を割り当てる交代ステップと
を含むことを特徴とするコンピュータ実施処理。
【請求項１３】
前記ピアノードの少なくとも一部の間で、ラウンドロビン方式で、音声ミキシングと再配信を交代させることをさらに含むことを特徴とする請求項１２に記載のコンピュータ実施処理。
【請求項１４】
前記音声ミキシングステップは、
エントロピーエンコーダを使用して音声パケットをエンコードしてエントロピーエンコード音声パケットを生成することと、
パケットバイパケット方式で、前記エントロピーエンコード音声パケットをミキシングすることと
をさらに含むことを特徴とする請求項１３に記載のコンピュータ実施処理。
【請求項１５】
前記ある時刻において前記ピアノードのそれぞれからエントロピーエンコード音声パケットを選択することと、
前記選択された音声パケットをエントロピーデコードおよび逆量子化して、前記選択された音声パケットのそれぞれに対応する係数ブロックを生成することと、
前記係数ブロックを結合して、前記ある時刻における前記ピアノードのそれぞれに対する合成係数ブロックを生成することと、
前記合成係数ブロックを量子化およびエントロピーリエンコードしてミックス音声パケットを作成することと
をさらに含むことを特徴とする請求項１４に記載のコンピュータ実施処理。
【請求項１６】
受信ピアノードにおいて、前記ミックス音声パケットをエントロピーデコードおよび逆量子化してミックス変換係数を取得することと、
前記ミックス変換係数を逆変形離散コサイン変換して音声コンテンツを回復すること
をさらに含むことを特徴とする請求項１２に記載のコンピュータ実施処理。
【請求項１７】
前記音声コンテンツは、ミキシングおよび再配信を実行中のソースピアノードを除くピアノードのそれぞれからの音声コンテンツをさらに含むことを特徴とする請求項１６に記載のコンピュータ実施処理。
【請求項１８】
前記音声コンテンツは、前記ピアノードのそれぞれからの音声コンテンツを含むコンピュータ実施処理であって、前記ピアノードのそれぞれに、それ自体の音声コンテンツを差し引かせることをさらに含むことを特徴とする請求項１６に記載のコンピュータ実施処理。
【請求項１９】
前記ピアノードを完全接続してクリークを定義することと、
前記クリークが、（ａ）前記クリーク外のその他のノードと相互作用するスーパーゲートウェイノード、（ｂ）前記クリークが、前記クリーク外のクライアントノードと相互作用する、スターネットワークトポロジにおけるサーバの役割にあるようなスーパーサーバ、の内の１つとして挙動するように、ネットワークトポロジを構成することと
をさらに含むことを特徴とする請求項１２に記載のコンピュータ実施処理。
【請求項２０】
ピアツーピアネットワーク内のピアノード間のマルチパーティリアルタイム音声通信セッションに参加するためのピアツーピア音声通信システムであって、
音声コンテンツを有する入力音声ストリームを、複数の音声フレームに区分する音声パケットモジュールと、
特定のフレームにおいて、前記ピアノードのそれぞれからの前記音声フレームのミキシングを実行して、前記複数の音声フレームのそれぞれにおいてミックス音声パケットを作成する音声ミキサと、
音声ミキシングおよび前記ミックス音声コンテンツの再配信を、一時に１つずつ、前記ピアノードのそれぞれにラウンドロビン方式で割り当てる、ラウンドロビン処理技法と、
前記再配信されたミックス音声コンテンツをデコードして、音声通信セッションのための音声を取得する音声デコーダと
を含むことを特徴とするピアツーピア音声通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には、コンピュータネットワーキングに関し、より具体的には、サーバレスピアツーピア（Ｐ２Ｐ）マルチパーティリアルタイム音声通信システムおよび方法であって、ピアのそれぞれが、交代して音声をミキシングし、圧縮した音声を再配信（ｒｅｄｅｌｉｖｅｒｉｎｇ）するとともに、あるピアによってミキシングおよび再配信される音声フレーム数が、そのピアの利用可能な資源（アップロード帯域幅または計算能力など）に比例する、システムおよび方法に関する。
【背景技術】
【０００２】
マルチパーティ音声通信システムは、一群の人がリアルタイム音声通信セッションに参加することを可能にする。さらに、このシステムは、多数の人が同時に話すことを可能にする。（音声キャプチャ、音響エコーキャンセレーション（ＡＥＣ）、自動ゲインコントロール（ＡＧＣ）、および音声／通話圧縮などの）ツーパーティ音声通信システムの音声構成要素に加えて、マルチパーティ音声通信システムには、音声ミキシングおよびネットワーク配信における固有の課題がある。
【０００３】
一例として、ｎ個のピアコンピュータ（またはピア）が、起こりうる複数の同時話者とのマルチパーティ音声通信セッションに参加していることを仮定する。さらに、音声の各ストリームは、ｂｗの帯域幅を必要とすると仮定する。マルチパーティ音声通信システムは、様々なトポロジおよびミキシング方策を用いて形成することができる。普及しているトポロジの１つは、図１Ａに示すような、スタートポロジである。高性能の中央サーバＳは、すべてのピア（ｔ１、ｔ２、ｔ３、ｔ４、およびｔ５）からの音声ストリームを受信し、この音声ストリームをミキシングし、そしてミキシングおよびリエンコード（ｒｅ−ｅｎｃｏｄｅ）された音声をすべてのピアに返す。
【０００４】
スタートポロジの利点は、各パーティが、ツーパーティ通信システムのハードウェアと同じハードウェアを使用し、したがって変更を必要としないことである。マルチパーティ通信セッションをサポートするためには、サーバだけを再設計すればよい。結果的に、スタートポロジは、商業用マルチパーティ通信のソリューションとして一般的に選択されている。そのようなシステムの１つが、非特許文献１に記載されている。スタートポロジの主たる欠点は、サーバＳ上に大きな演算と帯域の負担がかかることである。サーバＳは、ｎ個のストリームの圧縮音声（ｎ・ｂｗのダウンロード帯域幅）を受信し、それらをデコード、ミキシング、リエンコードして、ミキシングした音声をｎ個のピア（ｎ・ｂｗのアップロード帯域幅）に返す必要がある。
【０００５】
第２の一般的なトポロジは、図１Ｂに示すような、完全接続ユニキャスト（ｕｎｉｃａｓｔ）ネットワークである。完全接続ネットワークにおいては、すべてのピアがネットワーク内の他のすべてのピアに接続されている。この種のトポロジの一例について、非特許文献２で考察されている。このトポロジにおいては、ピア（ｔ１、ｔ２、ｔ３、ｔ４、およびｔ５）は、いかなる音声ミキシングも再配信も実行しない。その代わりに、それぞれの話者は、単に、圧縮音声を他のすべてのピアに送信する。そのようなトポロジでは、それぞれのピアは、音声を残りのピアに送信するのに（ｎ−１）・ｂｗのアップロード帯域幅を必要とするとともに、入力音声を受信するのに、最大（ｎ−１）・ｂｗのダウンロード帯域幅を必要とする。このトポロジの１つの欠点は、ネットワークトラフィックの大幅な増加であり、このことは、それぞれのピアおよびネットワーク全体に大きな負担を与える。
【０００６】
第３の可能なトポロジは、汎用グラフ（ｇｅｎｅｒｉｃ  ｇｒａｐｈ）であり、これはエンドシステムミキシングを使用する。この種のトポロジの一例が、図１Ｃに示されており、また非特許文献３に記載されている。図１Ｃに示すように、この例において、ピアａ、ｂ、ｆおよびｇは葉ノード（ｌｅａｆ  ｎｏｄｅ）であり、いかなるミキシング演算も実行しない。ピアｃ、ｄおよびｅは、ゲートウェイノードとしての役割を果たし、このゲートウェイノードは、近傍のピアのために音声をミキシングして再配信する。一般に、ｍ個の隣接ノードがあれば、音声を受信して再配信するのに、ｍ・ｂｗのアップロードおよびダウンロード帯域幅を必要とする。ｍは通常はｎよりもずっと小さいので、このトポロジの設計は、大規模会議セッションにうまく対応することができる。しかしながら、このトポロジの欠点は、ゲートウェイノードに対する負担が大きくなる可能性があることである。別の欠点は、ゲートウェイの連鎖が長くなると、音声配信の待ち時間が長くなることである。さらに別の欠点は、配信の連鎖に沿って、音声の同期がずれる可能性もあることである。
【０００７】
音声通信セッションにおけるトラフィックをさらに低減するネットワークレベルのソリューションの１つは、ＩＰマルチキャストによるものである。ＩＰマルチキャストにおいては、ソースから伝送される単一パケットが、そのソースをルートとする配送木（ｄｉｓｔｒｉｂｕｔｉｏｎ  ｔｒｅｅ）に沿った、ルータ群において複製される。このようにして、コンテンツが任意の数の受信者に配信される。例えば、図１Ａに示すスタートポロジにおいて、ピアはユニキャストを経由してサーバに圧縮音声を送信することもできる。しかしながら、サーバＳは、ミキシングおよびリエンコードした音声をｎ個のピアにマルチキャストして返すことができる。そのようなシステムのサンプル実現形態は非特許文献４に記載されている。サーバＳのアップロード帯域幅はｂｗに縮小される。
【０００８】
しかしながら、ＩＰマルチキャストの１つの欠点は、サーバのダウンロード帯域幅に対する要求条件が、ｎ・ｂｗで一定のままとなることである。図１Ｂに示す、完全接続ネットワークにおいて、それぞれの話者は、ネットワークの他のすべてのピアに圧縮音声をマルチキャストすることもできる。ここでも、完全接続ネットワークに対する、ＩＰマルチキャストの欠点は、ピアのアップロード帯域幅がｂｗに縮小されるのに対して、ピアのダウンロード帯域幅は、（ｎ−１）・ｂｗで一定のままであることである。ＩＰマルチキャストの別の欠点は、とりわけ、ドメイン間ルーティングプロトコル、ＩＳＰビジネスモデル（課金モデル）、配送木に沿った輻輳制御（ｃｏｎｇｅｓｔｉｏｎ  ｃｏｎｔｒｏｌ）、およびセキュリティなどの問題が理由で、その展開が実世界においては遅いことである。その結果として、ある限られた大学／企業サブネットおよび（インターネット２などの）ネットワークテストベッドを除いて、固有ＩＰマルチキャストのサポートは広く普及していない。ネットワークレベルのマルチキャストサービスの展開におけるこれらの問題のために、今日のインターネットにおける大部分のトラフィックは、ユニキャストベースであり、それによって２つのコンピュータが互いに直接話し合う。
【０００９】
Ｐ２Ｐネットワークによるファイル転送のための１対多数コンテンツ配布のシステムおよび方法の１種が、２００４年７月７日付出願、Ｊ．Ｌｉ、Ｐ．ＣｈｏｕおよびＣ．Ｚｈａｎｇの「Efficient One-to-Many Content Distribution in a Peer-to-Peer Computer Network」という名称の米国特許出願第１０／８８７，４０６に記載されている。しかしながら、その研究では、１対多数ファイル転送および配布を含むが、音声通信セッションは、多数対多数配布を要する。さらに、その研究では、ＴＣＰ／ＩＰキューを広範囲に使用している。しかしながら、キューの使用は音声会議には実際的ではなく、それはパケットがタイムリーに到着しなくてはならないからである。さらに、異なるソースからの音声がミキシングされる可能性があり、このために、音声配信は、音声通信応用において独特のものとなっている。
【００１０】
【非特許文献１】K. Singh, G. Nair, and H. Shulzrinne, "Centralized Conferencing Using SIP," Proceedings of the 2nd IP Technology Workshop, April 2001
【非特許文献２】J. Lennox and H. Shulzinne, "A protocol for reliable decentralized conferencing," Proceedings of the 13th international workshop on network and operating systems support for digital audio and video, (NOSS-DAV'2003), pp. 72-81, 2003, Monterey, California
【非特許文献３】M. Radenkovic, C. Greenhalgh, and S. Benford, "Deployment issues for multi-user audio support in CVEs," Proceedings ACM Symposium on virtual reality software and technology, pp. 179-185, 2002, Hong Kong, China
【非特許文献４】"ConferenceXP:wireless classrooms, collaboration and distance learning" at http://www.conferencexp.net/
【非特許文献５】Siren/G.722.1, "Coding at 24 and 32 kbits/s for hands-free operation in systems with low frame loss"
【非特許文献６】"MP3: The definitive Guide," Scot Hacker press
【非特許文献７】"Inside Windows（登録商標） Media," Microsoft Press
【発明の開示】
【発明が解決しようとする課題】
【００１１】
既存のマルチパーティ音声通信システムの欠点の１つは、ピアまたはサーバが果たすミキシングおよび再配信の役割が、ネットワークトポロジによって固定されていることである。既存音声通信システムの別の欠点は、音声ストリーム全体のミキシングを実行することである。したがって、必要とされるのは、ネットワーク資源を最も効率よく使用する、音声通信システムおよび方法である。さらに、必要とされるのは、上記のネットワークトポロジの欠点を回避するとともに、ピアが果たすミキシングおよび再配信の役割においてフレキシブルであるシステムおよび方法である。さらに、必要とされるのは、音声ストリーム全体ではなく、音声ストリームのフレームに対してミキシングを実施する、音声通信システムおよび方法である。さらに、必要とされるのは、キューの使用を回避して、ファイル転送技法の遅延問題を克服する、音声通信システムおよび方法である。
【課題を解決するための手段】
【００１２】
本明細書において開示する発明は、リアルタイムマルチパーティ音声通信セッションを最大効率で提供するピアツーピア（Ｐ２Ｐ）音声通信システムおよび方法を含む。Ｐ２Ｐネットワークは、各コンピュータが概して等価な能力と責任を有する種類のネットワークである。Ｐ２Ｐ音声通信システムおよび方法では、圧縮音声がパケットに区分され、そのパケットのそれぞれが、ミキシングと再配信のために単一ピアに送信される。あるピアによってミキシングおよび再配信されるパケット数は、そのピアの利用可能な資源に比例する。これらの資源には、アップロード帯域幅を含めてもよい。あるいは、資源には、計算能力を含めることもできる。Ｐ２Ｐ音声通信システムおよび方法は、マルチパーティ音声通信セッションにおいて要求される帯域幅を低減する。さらに、Ｐ２Ｐ音声通信システムおよび方法では、音声サービス負担とピアアップロード帯域幅を均衡させて、Ｐ２Ｐネットワーク内のすべての参加ピア間でマルチパーティ通信セッションのコストを再分配する。これによって、Ｐ２Ｐ音声通信システムおよび方法では、高性能のサーバまたはピアを必要とすることなく、マルチパーティ音声通信セッションを実施することが可能となる。
【００１３】
ミキシングおよび再配信がネットワークトポロジに基づいている従来技法とは異なり、本明細書に開示するＰ２Ｐ音声通信システムおよび方法では、圧縮音声をパケットまたはフレームに分割（ｓｐｌｉｔ）または区分（ｄｉｖｉｄｅ）して、それぞれのピアに交代で音声パケットのミキシングおよび再配信を行わせる。Ｐ２Ｐ音声通信システムおよび方法では、ピアのネットワーク帯域幅負荷を柔軟に均衡させることによって、より多くの資源を有するピアが少ない資源を有するピアを支援できるようになる。さらにＰ２Ｐ音声通信システムおよび方法では、音声ミキシングにより、マルチパーティリアルタイム音声通信システムセッションを行うのに必要な帯域幅が減少する。
【００１４】
本発明は、以下の説明と本発明の態様を示す添付の図面とを参照することによってより詳細に理解されるであろう。一例として本発明の原理を図示する添付の図面を合わせると、以下に示す本発明の詳細の説明から、その他の特徴および利点は明白になるであろう。
【００１５】
図面を参照するが、これらの図面では、同じ参照番号は全体を通して対応する部分を表わしている。
【発明を実施するための最良の形態】
【００１６】
本発明の以下の説明において、添付の図面を参照するが、それらは本発明の一部を形成するものであり、それには、一例として、それによって本発明を実施することができる特定の例を示してある。ここで理解すべきことは、本発明の範囲から逸脱することなく、その他の実施形態も利用することが可能であり、また構造的変更も行うことができることである。
【００１７】
Ｉ．序文
ピアツーピア（Ｐ２Ｐ）コンピュータネットワークにおける現行の１対多数配布技法は、コンテンツをソースノードからピアノードに直接送るよりも、より効率的であるが、これらの技法は、ネットワークにおける最も効率的なコンテンツ配布を達成することができない。これにはいくつかの要因がある。１つの要因は、これらの技法には、ピアノード間の帯域幅の差を適切に説明してそれに適応するものが１つもないことである。別の要因は、これらの技法では、コンテンツを配布するときに、ネットワーク上のすべてのピアノードの帯域幅能力を完全に利用することができないことである。
【００１８】
本明細書において説明する、Ｐ２Ｐ音声通信システムおよび方法は、マルチパーティ音声通信セッションを実行するための新規な解決策である。Ｐ２Ｐ音声通信システムおよび方法の重要な特徴は、音声ミキシングおよび音声の再配信の作業が、ミューチュアルキャストクリーク（ＭｕｔｕａｌＣａｓｔ  ｃｌｉｑｕｅ）内のピア間で交代して行われることである。ミューチュアルキャストクリークは、完全接続メッシュを形成する、少数のピアノードを含む。音声ミキシングを変換ドメイン上でフレームバイフレーム方式で実行することができるという、波形コード化音声（ｗａｖｅｆｏｒｍ  ｃｏｄｅｄ  ａｕｄｉｏ）の固有の特性を使用して、このＰ２Ｐ音声通信システムおよび方法では、参加ピア間でミキシングおよび再配信のタスクを交代させる。これによって、ネットワーク帯域幅と計算負荷を共有することができる。このようにして、Ｐ２Ｐ音声通信システムおよび方法では、高性能のサーバなしに、マルチパーティ音声通信セッションを行うことができる。
【００１９】
ＩＩ．全体概要
図２は、本明細書において開示するＰ２Ｐ音声通信システムおよび方法の例証的実施形態を示すブロック図である。ここで留意すべきことは、図２は、Ｐ２Ｐ音声通信システムを実施して使用することのできる、いくつかの方法の内の１つにすぎないことである。
【００２０】
図２を参照すると、完全接続ピアツーピア（Ｐ２Ｐ）ネットワーク２００が、この例証的実施形態に示してある。Ｐ２Ｐ音声通信システムおよび方法を実行するＰ２Ｐネットワーク２００は、ミューチュアルキャストクリークとも呼ばれる。図２に示すこの例証的実施形態において、ミューチュアルキャストクリーク２００は、３つのピアノード、すなわちピアノード（１）、ピアノード（２）、およびピアノード（３）を含む。ピアノード（１）、（２）、（３）は、矢印で示すように完全接続されている。ピアノード（１）、（２）、（３）のそれぞれは、Ｐ２Ｐ音声通信システムおよび方法を含む。
【００２１】
図３は、図２に示すようなピアノードのそれぞれに含まれるＰ２Ｐ音声通信システム３００の一般的な例証的実現形態を示す詳細ブロック図である。図３を参照すると、一般に、Ｐ２Ｐ音声通信システム３００は、各ピアからのネットワーク音声およびローカルピアからのマイクロフォン入力を受信し、その音声をミキシングして、ミックス音声をピアノードならびにローカルピアに出力する。そのローカルピアノードは、そのミックス音声をミキシングして再配信する。ピアノードの少なくとも一部は、ラウンドロビン（ｒｏｕｎｄ  ｒｏｂｉｎ）方式で、ミキシングおよび再配信を交代で実行する。
【００２２】
具体的には、図３はローカルピアノード（図示せず）上のＰ２Ｐ音声通信システム３００を示す。このＰ２ＰネットワークにＮ個のピアノードがあると仮定する。システム３００への入力には、ピア（１）３１０からピア（Ｎ）３１５までの、ネットワーク音声が含まれる。図３における省略符号は、ピアノードのすべては図示していないことを示している。さらに、マイクロフォンストリーム３２０も、システム３００への入力である。マイクロフォンストリーム３２０は、ローカルピア上の１つまたは複数のマイクロフォンからのものである。Ｐ２Ｐ音声通信システム３００は、入力音声をフレームまたはパケットに区分して、パケットのそれぞれをあるフレームにおいてミキシングする音声ミキサ３３０を含む。
【００２３】
ピア（１）３１０からのエンコードネットワーク音声は、エントロピーデコード（ｅｎｔｒｏｐｙ  ｄｅｃｏｄｉｎｇ）および逆量子化（１）３４０を実行することによって処理される。以下に詳細を説明するように、これによってピア（１）３１０からのエンコードネットワーク音声が部分的にデコードされて、ＭＤＣＴ変換係数のブロックが生成される。同様に、それぞれのピアからピア（Ｎ）３１５へのエンコードネットワーク音声は、エントロピーデコードおよび逆量子化（Ｎ）３４５を実行することによって処理される。ここでも、図３における省略記号は、エントロピーデコードおよび逆量子化のすべては図示されていないことを示す。マイクロフォンストリームは、変形離散コサイン変換（ＭＤＣＴ：ｍｏｄｉｆｉｅｄ  ｄｉｓｃｒｅｔｅ  ｃｏｓｉｎｅ  ｔｒａｎｓｆｏｒｍ）モジュール３５０を使用して処理されて、ＭＤＣＴ変換係数が生成される。
【００２４】
音声ミキサは、ピア（１）から（Ｎ）までのネットワーク音声からの音声コンテンツおよびマイクロフォンストリーム３２０をミキシングするのに使用される。これによってミックス音声パケットが生成される。このミックス音声コンテンツは、ピア（１）３６０へのミックス音声として、ピア（Ｎ）へのミックス音声として、および、省略記号で示すように、その他のピアに対するミックス音声として再配信される。
【００２５】
ピア（１）からピア（Ｎ）の配信されたネットワーク音声は、ローカル再生のためにもミキシングされる。次いで、（ローカル入力が他のピアによってミキシングされている場合には）ローカルマイクロフォン入力コンテンツを引いたミックス音声が、逆ＭＤＣＴモジュール３７０に送り込まれる。これによって、ネットワークピアの音声コンテンツが回復されて、スピーカ３８０を介して再生することが可能となる。
【００２６】
ここで留意すべきことは、その他のピアからの音声は、Ｐ２Ｐネットワーク上で伝送される前にエンコードされることである。さらに、ミックス音声コンテンツがピアノードによって受信されると、そのピアは、ミックス音声をデコードして、音声通信セッションに関連する音声を回復する。したがって、ピアノードのそれぞれが、音声ミキサ３３０を包含する。さらに、音声ミキサ３３０は、複数の音声エンコーダおよび音声デコーダ構成要素をさらに包含する。いつどのように、これらの構成要素のそれぞれを使用するかは、任意の時間にピアが行っている処理によって決まる。例えば、ローカルピアがミキシングおよび再配信を実行しているときには、音声ミキサ３３０は、ミューチュアルキャストクリーク内の各ピアから１フレームのエンコード音声を受け取り、部分デコードを実行し、音声をミキシングして、部分エンコードを実行し、１フレームのミックス音声を各ネットワークピアに送る。そのローカルピアがクライアントピアとなり、ミキシングおよび再配信が別のピアに割り当てられるときには、音声ミキサ３３０は、単に１フレームのエンコードマイクロフォンストリーム入力を、ミキシングを担当するピアに送り、ミキシングピアから１フレームを受け取り、デコード演算を実行し、ローカルにミックス音声を再生する。Ｐ２Ｐ音声通信システムおよび方法が使用するラウンドロビン方式は、ローカルピアノードの機能を順繰りで迅速に変更するので、構成要素間の必要なスイッチングは迅速に行われる。音声ミキサ３３０、音声エンコーダ、音声デコーダの詳細を以下に説明する。
【００２７】
ＩＩＩ．動作の概要
図３に示すＰ２Ｐ音声通信システム３００の動作について、次に説明する。図４は、図３に示すＰ２Ｐ音声通信システム３００の一般的動作を示す一般的フロー図である。一般に、本Ｐ２Ｐ音声通信方法は、入力音声ストリームをフレームまたはパケットに区分して、フレームの処理を、Ｐ２Ｐネットワーク内のピアノードの間で交代させて行う。より具体的には、本方法は、入力音声ストリームを複数のフレーム（ボックス４００）に区分することから始まる。次に、Ｐ２Ｐネットワーク内のピアノードの１つが選択される（ボックス４１０）。
【００２８】
選択されたピアノードは、その選択されたノードの利用可能な資源に比例するフレームを処理するように割り当てられる（ボックス４２０）。言い換えると、大量の資源を有するピアノードには、より多数のフレームが割り当てられるのに対して、少量の資源を有するピアノードには、より少数のフレームが割り当てられる。各ピアノードは、交代してフレームを処理する。処理には、入力音声ストリーム内の音声コンテンツのミキシングおよびピアノードへの音声の再配信が含まれる。すなわち、選択されたピアノードは、音声フレームのミキシングを実行して、ミックス音声フレームをＰ２Ｐネットワーク内のその他のピアノードに再配信する。フレーム処理は、ピアノード間で交代して行われる（ボックス４３０）。好ましい実施形態では、この交代は、各ノードに順番が回るように、ラウンドロビン方式または方法で実行される。
【００２９】
ＩＶ．動作の詳細および実用例
図３および図４に示すＰ２Ｐ音声通信システムおよび方法の動作の詳細についてここで考察する。本明細書に開示するＰ２Ｐ音声通信システムおよび方法をより詳細に理解するために、例証的な実用例の動作の詳細を提示する。ここで留意すべきことは、この実用例は、Ｐ２Ｐ音声通信システムおよび方法を実現することのできる１つの方法にすぎないことである。
【００３０】
音声コンテンツ
（波形コード化音声のミキシング）
この実用例においては、Ｐ２Ｐ音声通信システムおよび方法の音声は、波形コーデックを用いてエンコードされている。そのような波形コーデックに非特許文献５がある。代替コーデックとしては非特許文献６がある。さらなる代替コーデックとしては、ウィンドウズ（登録商標）メディアオーディオ（Ｗｉｎｄｏｗｓ（登録商標）  Ｍｅｄｉａ  Ａｕｄｉｏ）（非特許文献７）がある。図５は、本実用例において使用される音声エンコーダ５００の動作の詳細ブロック／フロー図である。
【００３１】
図５を参照すると、音声波形を含む音声入力５１０は、最初に、フレームに分割または区分される。この実用例において、各フレームの長さは、約２０ミリ秒（ｍｓ）であった。ここで留意すべきことは、フレーム間に５０％の重複があるために、全アルゴリズム遅延は４０ｍｓであり、フレームのそれの２倍であることである。しかしながら、それぞれの量子化およびエントロピーコード化されたフレーム係数の長さは、依然として２０ｍｓである。次に、各フレームは、変形離散コサイン変換（ＭＤＣＴ）モジュール５２０によって係数ブロック（Ｃｉ，ｊ）に変換される。添え字ｉはピアを示し、添え字ｊはフレーム番号を示す。すなわち、図５において、係数ブロックＣｉ，１はｉ番目のピアの第１フレームを、係数ブロックＣｉ，２はｉ番目のピアの第２フレームを示す。次に、係数ブロックは、量子化器５３０に送られて、量子化される。次いで、この量子化係数ブロックは、エントロピーエンコーダ５４０によって、パケットｐｉ，ｊにエントロピーエンコード（ｅｎｔｒｏｐｙ  ｅｎｃｏｄｅｄ）される。図５において、エンコードパケットＰｉ，１およびＰｉ，２は、ｉ番目のピアの第１および第２のフレームに対するエンコードパケットを示す。
【００３２】
ＭＤＣＴは線形演算であるので、波形コード化音声は、変換ドメインにおいてのミキシングができるだけでなく、フレーム毎にミキシングすることもできる。図６は、この実用例において使用される音声ミキサ６００の動作の詳細ブロック／フロー図である。図６に、２つの圧縮音声パケットからなる、あるフレームのミキシングを示してある。一般に、音声ミキサ６００は、あるフレームの圧縮音声パケットをデコードして係数ブロックを得て、係数ブロックを結合し、ブロックをリエンコードし、１フレームの音声に対する単一の圧縮音声パケットを得る。Ｐ２Ｐ音声通信システムおよび方法の音声ミキシング技法では、現行の音声会議システムにおいて行われるように、入力音声ストリーム全体についてのミキシング演算を実行するのではなく、音声のフレームをミキシングする。
【００３３】
特に、この実用例においては、エントロピーデコーダ（１）６１０および逆量子化器（１）６２０を使用して、圧縮音声パケットＰ１，ｊがデコードされて、あるピアに対する係数ブロックが得られる。同様に、エントロピーデコーダ（２）６３０および逆量子化器（２）６４０を使用して、圧縮音声パケットＰ２、ｊがデコードされて、別のピアに対する係数ブロックを得られる。結果として得られる係数は、ＭＤＣＴ変換係数である。これらのＭＤＣＴ変換係数は、結合モジュール６５０を使用して、結合モジュール６５０中の「＋」記号で表わすように互いに加算されるか、または結合される。ここで留意すべきことは、図６には音声に対して「＋」記号を示してあるが、結合は、減算（マイナス符号「−」）としても加算（プラス符号「＋」）としてもよく、エンコード音声に対する聴覚上の差異はないということである。次に、結果として得られる係数ブロックは、ミキシング量子化器６６０を使用して量子化されて、それからミキシングエントロピーエンコーダ６７０を使用してエントロピーリエンコードされる。これによって、ミックス音声パケットＰ１，ｊ＋Ｐ２、ｊを含む、フレームが生成される。このミキシング工程中に、その他のいずれのフレームの音声パケットにも、アクセスはなかった。
【００３４】
図７は、この実用例において使用される音声デコーダ７００の動作の詳細ブロック／フロー図である。受信器において、ミキシングされたパケットは、正常にデコードされた。図７を参照すると、ミックス音声パケットＰ１，ｊ＋Ｐ２、ｊは、音声デコーダ７００に入力された。各フレームは、エントロピーデコーダ（３）７１０によって、次いで逆量子化器（３）７２０によって処理された。これによって、ミキシングされたＭＤＣＴ変換係数、Ｃ１，１＋Ｃ２，１およびＣ１，２＋Ｃ２，２が生成された。次に、ミキシングされたＭＤＣＴ変換係数は、逆ＭＤＣＴモジュール７３０を使用して処理された。結果として得られた出力は、ピア１およびピア２からの、ミックス音声波形（音声１＋音声２）７４０であった。
【００３５】
（音声コンテンツのラウンドロビン式交代ミキシングおよび再配信）
この実用例における別の構成要素は、ラウンドロビン方式による音声コンテンツの交代ミキシングと再配信であった。言い換えると、ピアのそれぞれが、交代で音声コンテンツをミキシングおよび再配信した。この実用例においては、完全接続メッシュを形成する少数のピアノードからなる、ミューチュアルキャストクリークを使用した。波形コード化音声コンテンツは、フレームバイフレーム方式でミキシングすることができるという特性を使用して、Ｐ２Ｐ音声会議システムおよび方法では、ミキシングおよび再配信演算がピア間で交代で行われた。これによって、最も効率的な方法で、帯域幅および計算負荷が適当に配分されることが確実になった。好ましい実施形態では、この交代は、ラウンドロビン方式および／または方法で行われ、それによって各ピアノードが交代して音声をミキシングして再配信した。
【００３６】
図８は、この実用例において使用された、３つのピアノード（１、２および３）に対する音声ミキシングセッションを示す。音声ミキシングスケジュールを図８の下部に示してある。この音声ミキシングスケジュールを参照すると、ピアノード１、２、３は、それぞれ、フレーム３ｋ、３ｋ＋１、３ｋ＋２において音声ミキシングおよび再配信を担当した。すなわち、１番目のフレームにおいて、ピア２が音声パケットのミキシングおよび再配信を行った。図８に示すように、ピア２がミキシングおよび再配信を担当している間、ピア１およびピア３は、それらのエンコード音声Ｐ１，１およびＰ３，１をピア２に送った。次いで、入力音声パケットは、エントロピーデコードおよび逆量子化を経て、ＭＤＣＴ係数Ｃ１，１およびＣ３，１に戻された。次いで、ピア２は、それ自体の係数Ｃ２，１を加えた。次いで、ミックス音声は、ピア１およびピア３に送り返された。
【００３７】
エコーを回避するために、ソース音声はミキシングせずに、送り返された。言い換えると、図８を参照すると、ピア２は、係数Ｃ１，１およびＣ２，１を加算して、この係数の合計を量子化およびエントロピーエンコードした。次いで、ピア２はミックスパケットＰ１，１＋Ｐ２，１をピア３に送り返した。同様に、ミックスパケットＰ３，１＋Ｐ２，１はピア２によってピア１に送られた。目的地において、異なるピアからのミックス音声パケットは、ソートされ、エントロピーデコードされ、再生のために、逆量子化および逆ＭＤＣＴ変換された。
【００３８】
再び、図８のミキシングスケジュールを参照すると、第２フレームにおいて、ピア３がミキシングの役割についた。ピア１およびピア２は、２番目のフレームにおけるそれらの圧縮音声パケットＰ１，２およびＰ２，２をピア３に送った。次いで、ピア３は入力音声パケットを、それ自体の係数Ｃ３，２とミキシングした。次いで、ピア３は、ミックスパケットＰ３，２＋Ｐ２，２をピア１に送り、ミックスパケットＰ３，２＋Ｐ１，２をピア２に送った。
【００３９】
図８に示すように、３番目のフレームにおいて、ピアノード１がミキシングノードとなり、以下同様であった。ミキシングおよび再配信のタスクをタイムシェアリングすることによって、ミキシングの帯域幅および計算コストは、ピアのそれぞれの間に分配される。その結果として、サーバを必要とすることなく、１群の低性能のピアによって、マルチパーティ音声通信セッションを行うことができる。
【００４０】
Ｐ２Ｐ音声通信システムおよび方法では、ミューチュアルキャストクリークはｎ個のノードからなる。各ピアノードは、２（ｎ−１）個のパケットをｎフレーム毎に送受信する。その中で、（ｎ−１）個のパケットは、それがミキシング演算を実行しないｎ−１個のフレームの間に送受信される。さらに、（ｎ−１）個のパケットが、それがミキシングおよび再配信の演算を実行する間に、送受信される。したがって、アップロード／ダウンロードに必要な帯域幅は、（２−２／ｎ）・ｂｗである。また、平均して、（２−２／ｎ）個のストリームの音声が各ピアによってデコード、リエンコードされるということも計算することができる。ミキシングの間に、ピアは、（ｎ−１）回のエントロピーデコードおよび逆量子化の演算、および（ｎ−１）回の前方量子化およびエントロピーエンコードの演算を実行する。
【００４１】
再配信されたミックス音声パケットに含まれるコンテンツに関して、少なくとも２つの可能性がある。好ましい一実施形態においては、ミックス音声パケットは、ソース（または選択された）ピアノードの音声コンテンツは含まない。言い換えると、交代音声ミキシング技法は、あるピアのソース音声をミキシングせず、かつ送り返さないことを含む。一代替実施形態においては、ミックス音声パケットは、ピアノードのそれぞれからの音声コンテンツを含み、そのミックス音声パケットからそれ自体の音声コンテンツを差し引くのは、各ピアに任されている。例えば、ミックス音声は、フレームｊに対してパケット（ｍｊ＝ｐ１，ｊ＋ｐ２，ｊ＋ｐ３，ｊ）を含む。次いで、同じミックス音声がすべてのピアに返送される。エコーを低減または除去するために、各ピアには、そのミックス音声からそれ自体の音声を差し引く責任がある。例えば、ピアｉはｍｊからｐｉ，ｊを差し引き、それは加算の代わりに減算によるミキシング演算である。この代替実施形態の利点は、ピアは、ミキシング中に一回の前方量子化およびエントロピーエンコード演算を実行する必要があるだけであることである。さらに、ＩＰマルチキャストがすべてのピア間でサポートされている場合には、ミキシングピアは、ミックスパケットを残りのピアにマルチキャストすることができる。この代替実施形態の欠点は、ミックス音声は、量子化してエントロピーエンコードする必要があるために、ミックスパケットｍｊ内の構成音声ｐｉ，ｊが、ピアｉが保持する音声ｐｉ，ｊと異なることである。したがって、残留エコーが残る可能性がある。この残留エコーは、ピアの数の増加および／またはミックス音声のコーディングビットレートの減少とともにより明白になる。したがって、この残留エコー問題のため、音声パケットのすべてをミックスしない実施形態が好ましい。
【００４２】
ミキシングタスクの割り付け
Ｐ２Ｐ音声通信システムおよび方法は、音声のミキシングおよび再配信のタスクをフレームバイフレーム方式で割り付ける。このようにして、Ｐ２Ｐ音声通信システムおよび方法は、より多くの資源を有するピアにより多くのミキシングタスクを、より少ない資源を有するピアにより少ないミキシングタスクを割り当てる。Ｐ２Ｐ音声通信システムおよび方法において、最も重要な資源と考えられるのは、ピアのアップロード帯域幅である。普及が進むネットワークにおいては、Ｐ２Ｐネットワークの全アップロード帯域幅は、全ダウンロード帯域幅よりもはるかに小さい。このことは、ケーブルモデムおよびＡＤＳＬネットワークのエンドユーザノードにおいて特に当てはまり、これらのエンドユーザノードに対しては、アップロード帯域幅とダウンロード帯域幅との釣合いがダウンロード帯域幅の方に非対称に偏っている。大学／企業ネットワークのユーザノードに対してさえ、ユーザがアップロード帯域幅に上限を設けるために、ダウンロード帯域幅は、利用可能なアップロード帯域幅よりも大きい可能性がある。したがって、より高い利用可能帯域幅を有するピアに、より多くのミキシングおよび再配信タスクを割り付け、より低いアップロード帯域幅を有するピアにより少ないタスクを割り付けるのが有利である。
【００４３】
Ｐ２Ｐ音声通信システムおよび方法が考慮する第２の資源は、ピアのピークアップロード帯域幅（または物理リンク帯域幅）である。ミキシングの間に、Ｐ２Ｐ音声通信システムおよび方法のピアは、（ｎ−１）個のパケットを受信し、（ｎ−１）個のピアに送信する。Ｐ２Ｐ音声通信システムにおけるピアのトラフィック特性は、バースト性（ｂｕｒｓｔｙ）である。より高速の物理リンクを有するピアに、または比較的多くのトークンバケット（ｔｏｋｅｎ  ｂｕｃｋｅｔ）を有するルータに接続されているピアに、より多くのミキシングおよび再配信タスクを割り当てて、パケットを複数のピアに送ることにより生じる遅延を低減することができるようにするのが有効である。
【００４４】
通常、ピアのダウンロード帯域幅および計算資源はボトルネックではない。それでも、Ｐ２Ｐ音声通信システムおよび方法は、このことも割り付けにおいて考慮に入れることもできる。ここで留意すべきことは、低速または低性能のノードが、より少ないパケットを配信することを許容すると、それらのノードは、より高速で高性能のノードの寄生虫（ｌｅｅｃｈ）となることである。そのような寄生挙動を許容するかどうかは、良好な音声通信性能と寄与の公平性との間の設計選択である。
【００４５】
遅延
ここで、Ｐ２Ｐ音声通信システムおよび方法の最大遅延を計算して、提示する。ピアノードｉとｊとの間のネットワーク伝送遅延をｄｉ，ｊとする。ミキシング演算で生ずる遅延は無視できると仮定して、ピアｋによってミキシングされた音声フレームを受け取るためのピアｉでの遅延の量は次式となる。
【００４６】
【数１】
2006268844.tif 000003
【００４７】
ピアｉでの最大遅延は次のように計算される。
【００４８】
【数２】
2006268844.tif 000004
【００４９】
それに対して、Ｐ２Ｐ音声通信システムおよび方法の最大遅延は、
【００５０】
【数３】
2006268844.tif 000005
【００５１】
であり、これは、ミューチュアルキャストクリークにおける最も遠いピア対のネットワーク遅延の２倍である。
【００５２】
Ｖ．スーパーゲートウェイおよびスーパーサーバ
Ｐ２Ｐ音声通信システムのミューチュアルキャストクリークは、１組の完全接続されたピアノードによって形成されなければならない。上述のように、遅延は、クリークが大きくなるほど増大する。したがって、ミューチュアルキャストクリーク内のノード数は、大きすぎないことが理想的である。合理的な数としては、３から７の間である。しかしながら、ミューチュアルキャストクリークは、スーパーゲートウェイまたはスーパーサーバとしての役割を果たし、したがって、本明細書に記載したＰ２Ｐ音声通信システムおよび方法のすべての機能を保持しながら、より大規模なネットワークにおいて機能することができる。
【００５３】
スーパーゲートウェイノード
Ｐ２Ｐ音声通信システムは、スーパーゲートウェイノードとして機能することができる。これによって、ミューチュアルキャストクリークは、大規模マルチパーティ通信セッションにおいて、「スーパー」ゲートウェイノードとしての役割を果たすことができる。この場合に、残りのノードは、汎用グラフ（ｇｅｎｅｒｉｃ  ｇｒａｐｈ）を形成して、エンドシステムミキシングを使用する。図９は、汎用マルチパーティ通信セッションにおけるゲートウェイノードとしての役割を果たすＰ２Ｐ音声通信システムおよび方法のミューチュアルキャストクリークの例証的例を示す。この構成は、多数のピアノードを有するマルチパーティ通信セッションであって、少数の近接するノードが完全接続されてマルチキャストクリークを形成するものに特に適している。
【００５４】
図９の例証的例に示すように、ノードａ、ｂ、ｃによって形成されるミューチュアルキャストクリーク９００は、ノードｄ、ｅ、ｆ、ｇ、ｉに対する「スーパー」ゲートウェイノードとしての役割を果たす。ミューチュアルキャストクリーク９００内の各ピアノードは、取り付けられたノードに対してゲートウェイとしての役割を果たす。例えば、ピアノードａは、マルチキャストクリーク９００の外側の２つのノードｄ、ｅに取り付けられている。すなわち、ミューチュアルキャストクリーク９００において、ノードａは、ｄおよびｅの音声をそれ自体の音声と併合して、結合音声（ａ＋ｄ＋ｅ）を、Ｐ２Ｐ音声通信システムおよび方法を使用して、ノードｂ、ｃに配信する。ノードａがミューチュアルキャストクリーク９００のためにミキシングを行っているフレームにおいて、結合音声（ａ＋ｄ＋ｅ）が、ノードｂからの入力とミックスされて（音声ｂ＋ｉ）、ノードｃに送られる。同様に、結合音声（ａ＋ｄ＋ｅ）は、ノードｃからの入力とミックスされて（音声ｃ＋ｆ＋ｇ＋ｈ）、ノードｂに送られる。ノードａは、また、ノードｂ、ｃからの入力をミックスして、それをそれ自体と結合し、
ｍ＝ａ＋ｂ＋ｉ＋ｃ＋ｆ＋ｇ＋ｈ                                      （４）
ｍ＋ｄをノードｅに送り、ｍ＋ｅをノードｄに送る。
【００５５】
ノードａがミキシングしていないフレームにおいて、結合音声（ａ＋ｄ＋ｅ）は、その時点のミキシングノード（ｂまたはｃ）に送信される。また、ノードａは、ノードｂ、ｃからのミックス入力も受信し、それらをそれ自体のものと結合してミックスフレームｍを形成し、ノードｅにｍ＋ｄを送信し、ノードｄにｍ＋ｅを送信する。
【００５６】
スーパーサーバ
Ｐ２Ｐ音声通信システムは、スーパーサーバとして機能することもできる。この場合に、残りのノードは、スタートポロジにおけるクライアントノードであり、ミューチュアルキャストクリークは、最低２つのノードで構成することができる。図１０は、ミューチュアルキャストクリークの、スタートポロジを有するマルチパーティ通信セッションにおける、スーパーサーバとしての例証的例を示す。
【００５７】
図１０に示すように、ピアノードａ、ｂは、２ノードミューチュアルキャストクリーク１０００を形成し、これは、残りのクライアントノードｃ、ｄ、ｅ、ｆ、ｇに対してスーパーサーバとしての役割を果たす。ミューチュアルキャストクリーク１０００内のピアノードは、また完全接続メッシュを形成する。さらに、外側の各クライアントノードは、ミューチュアルキャストクリーク１０００内のすべてのピアノードに接続されている。この構成は、分担してサーバとしての役割をする、いくつかの高性能ブロードバンドノードが存在する、（４から１６の間などの）小規模〜中規模のネットワークにより適している。
【００５８】
この構成に伴う別のシナリオは、ネットワークアドレス変換機構（ＮＡＴ：ｎｅｔｗｏｒｋ  ａｄｄｒｅｓｓ  ｔｒａｎｓｌａｔｏｒ）またはファイヤウォールがあるときに発生する。具体的には、クライアントノードは、ＮＡＴ／ファイヤウォールの背後に置くことができる。これらは、インターネットに直接的に接続されたノード、言い換えると、ミューチュアルキャストクリーク１０００のノードに接続することができる。しかしながら、それらは互いに接続することはできない。そのようなネットワークのミキシングおよび再配信演算は、上述のＰ２Ｐ音声通信システムおよび方法に非常に類似している。唯一の差は、この実施形態においては、クラアントノードは、ミキシングおよび再配信のタスクから免除されていることである。各フレームにおいて、ミューチュアルキャストクリーク１０００の１つのピアは、ミューチュアルキャストクリーク１０００の内側および外側の両方における、残りのピアのために音声パケットをミキシングして再配信する。
【００５９】
ＶＩ．帯域幅および計算負荷解析
この章においては、Ｐ２Ｐ音声通信システムおよび方法を使用する、異なる音声通信セッションシナリオの帯域幅要件を計算して、Ｐ２Ｐ音声通信システムおよび方法を使用しないシナリオと比較する。最初に、ｎパーティ通信セッションを考える。すべてのピアの帯域幅が等しい場合に、Ｐ２Ｐ音声通信システムおよび方法は、それぞれすべてのピアノードに対して、（２−２／ｎ）・ｂｗのアップロード／ダウンロード帯域幅を必要とする。特に、３ノードミューチュアルキャストクリークに対して、必要な帯域幅は１．３４ｂｗである。スタートポロジ、または汎用グラフを用いるマルチパーティ通信セッションを行うために、同じ３ノード通信セッションは、少なくとも２ｂｗの帯域幅のノードを必要とする。すなわち、Ｐ２Ｐ音声通信システムおよび方法は、すべてのピアノードがより少ない資源しか有さない場合でも、マルチパーティ通信セッションを実施することができる。
【００６０】
第２に、ミューチュアルキャストクリークが、大規模グラフにおいてスーパーゲートウェイとして働く場合を考える。ゲートウェイノードが、ｍ個のノードに接続されているとする。通常、ゲートウェイノードは、音声トラフィックをミキシングして再配信するのに、ｍ・ｂｗのアップロードおよびダウンロード帯域幅を必要とする。ゲートウェイノードをｎノードミューチュアルキャストクリークで置換し、ｍ／ｎノードが各ノードに取り付けられていると仮定することによって、各ノードのアップロード／ダウンロード帯域幅要件は、このスーパーゲートウェイにおいては、以下のように低減される：
【００６１】
【数４】
2006268844.tif 000006
【００６２】
一例として、ｍ＝６およびｎ＝３とする。この場合に、Ｐ２Ｐ音声通信システムおよび方法は、帯域幅要件を、６ｂｗから３．３４ｂｗへと低減する。ミューチュアルキャストクリークの、スーパーゲートウェイとしての使用は、また、ゲートウェイノードの帯域幅要件を低下させることができる。
【００６３】
最後に、ミューチュアルキャストクリークをスーパーサーバとして使用する場合を考える。ここでも、ｍ個のクライアントがあると仮定する。Ｐ２Ｐ音声通信システムおよび方法を使用しないと、サーバは、ｍ個のクライアントにサービスを提供するのに、ｍ・ｂｗのアップロードおよびダウンロード帯域幅を必要とする。しかしながら、Ｐ２Ｐ音声通信システムおよび方法ならびにｎ個のノードのミューチュアルキャストクリークを使用する場合に、ここでも、平均で、ミューチュアルキャストクリーク内の各ピアノードは、
【００６４】
【数５】
2006268844.tif 000007
【００６５】
のアップロード／ダウンロード帯域幅を必要とするだけであると計算される。一例として、ｍ＝５およびｎ＝２とする。Ｐ２Ｐ音声通信システムおよび方法は、サーバノードの帯域幅要件を、５ｂｗから３．５ｂｗへと低減する。ここで、ミューチュアルキャストは、ピアの計算負荷、スーパーゲートウェイノードおよびスーパーサーバノードを同じ割合で低減することは、容易に推論できる。
【００６６】
ＶＩＩ．例証的動作環境
Ｐ２Ｐ音声通信システムおよび方法は、計算機環境内および計算機装置上で動作するように設計されている。Ｐ２Ｐ音声通信システムおよび方法が動作する計算機環境について考察する。以下の考察は、Ｐ２Ｐ音声通信システムおよび方法を実装することのできる、適当な計算機環境の簡潔な、一般的記述を行うものである。
【００６７】
図１１は、図３および図４に示したＰ２Ｐ音声通信システムおよび方法を実装することのできる適当な計算機システム環境の例を示している。この計算機システム環境１１００は、適当な計算機システム環境の一例にすぎず、本発明の使用または機能に対するいかなる限定も示唆するものではない。また、計算機環境１１００は、この例証的動作環境１１００に示す構成要素のいずれかまたはそれらの組合せに関して、何らかの依存性または要件を有すると解釈すべきではない。
【００６８】
Ｐ２Ｐ音声通信システムおよび方法は、その他多数の汎用または専用の計算機システム環境または構成とともに動作することができる。Ｐ２Ｐ音声通信システムおよび方法に使用するのに適するよく知られている計算機システム、環境、および／または構成の例としては、それに限定はされないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド、ラップトップもしくはモバイルコンピュータ、またはセルフォンやＰＤＡなどの通信デバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス（ｓｅｔ  ｔｏｐ  ｂｏｘｅｓ）、プログラム可能家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスの任意のものを含む分散型計算機環境、その他が挙げられる。
【００６９】
Ｐ２Ｐ音声通信システムおよび方法は、プログラムモジュールなどの、コンピュータによって実行されているコンピュータ実行可能命令の一般的文脈で説明することができる。一般に、プログラムモジュールとしては、特定のタスクを実行するか、または特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、その他が挙げられる。Ｐ２Ｐ音声通信システムおよび方法は、通信ネットワークによってリンクされたリモート処理装置によってタスクが実行される、分散型計算機環境において実施することもできる。分散型計算機環境においては、プログラムモジュールは、メモリ記憶装置を含む、ローカルおよびリモートのコンピュータ記憶媒体の両方に配置することができる。図１１を参照すると、Ｐ２Ｐ音声通信システムおよび方法を実施するための例証的システムには、コンピュータ１１１０の形態の汎用計算機装置が含まれる。図１１に示すピアノードは、コンピュータ１１１０の例である。
【００７０】
コンピュータ１１１０の構成要素としては、それに限定はされないが、処理ユニット１１２０、システムメモリ１１３０、およびシステムメモリを含む様々なシステム構成要素を処理ユニット１１２０に結合する、システムバス１１２１を含めることができる。システムバス１１２１は、メモリバスもしくはメモリコントローラ、周辺バス、および様々なバスアーキテクチャの任意のものを使用するローカルバスを含む、いくつかの種類のバス構造の任意のものとすることができる。一例であり、限定ではないが、そのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｉａｌ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびＭｅｚｚａｎｉｎｅバスとも呼ばれる、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスがある。
【００７１】
コンピュータ１１１０は、通常、様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１１０がアクセス可能であり、揮発性および不揮発性媒体、移動型および固定型媒体の両方を含む、任意の利用可能な媒体とすることができる。一例であって、限定ではないが、コンピュータ可読媒体には、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体としては、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータなどの情報を記憶するために、任意の方法または技術で実現される、揮発性および不揮発性、移動型および固定型の媒体が挙げられる。
【００７２】
コンピュータ記憶媒体としては、それに限定はされないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくはその他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（デジタルバーサタイルディスク）もしくはその他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくはその他の磁気記憶装置、または所望の情報を記憶するのに使用可能であるとともにコンピュータ１１１０によるアクセスが可能である、その他任意の媒体を挙げることができる。通信媒体は、通常、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを、搬送波または他のトランスポート機構などの変調されたデータ信号内に具体化し、通信媒体には、すべての情報配布媒体が含まれる。
【００７３】
ここで、「変調データ信号（ｍｏｄｕｌａｔｅｄ  ｄａｔａ  ｓｉｇｎａｌ）」という用語は、信号内に情報をエンコードするように、その１つまたは複数の特性を設定または変更した信号を意味する。一例であり、限定ではないが、通信媒体としては、有線ネットワークまたは直接線接続（ｄｉｒｅｃｔ−ｗｉｒｅｄ  ｃｏｎｎｅｃｔｉｏｎ）、および音響、ＲＦ、赤外線およびその他の無線媒体などの無線媒体を挙げることができる。上記の任意のものの組合せも、コンピュータ可読媒体の範囲に含めるべきである。
【００７４】
システムメモリ１１３０には、読取り専用メモリ（ＲＯＭ）１１３１およびランダムアクセスメモリ（ＲＡＭ）１１３２などの、揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体が含まれる。例えば起動時に、コンピュータ１１１０内の要素間で情報を転送するのを助ける、基本ルーチンを含む、基本入出力システム１１３３（ＢＩＯＳ）は、通常、ＲＯＭ１１３１に記憶される。ＲＡＭ１１３２は、通常、データおよび／またはプログラムモジュールを含み、それらは、処理ユニット１１２０に対して直接アクセス可能であり、かつ／またはその上で動作している。一例であって、限定ではなく、図１１には、オペレーティングシステム１１３４、アプリケーションプログラム１１３５、その他のプログラムモジュール１１３６、およびプログラムデータ１１３７を示してある。
【００７５】
コンピュータ１１１０には、その他の移動型／固定型、揮発性／不揮発性コンピュータ記憶媒体を含めることができる。一例としてだけであるが、図１１には、固定型、不揮発性磁気媒体の読取り／書込みを行うハードディスクドライブ１１４１、移動型、不揮発性磁気ディスク１１５２の読取り／書込みを行う磁気ディスクドライブ１１５１、ＣＤＲＯＭまたはその他の光学媒体などの移動型、不揮発性光学ディスク１１５６の読取り／書込みを行う光学ディスクドライブ１１５５を示してある。
【００７６】
例証的動作環境において使用することのできる、その他の移動型／固定型、揮発性／不揮発性コンピュータ記憶媒体としては、それに限定はされないが、磁気テープカセット、フラッシュメモリカード、ＤＶＤ、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、その他が挙げられる。ハードディスクドライブ１１４１は、通常、インターフェース１１４０などの固定型メモリインターフェースを介してシステムバス１１２１に接続されており、磁気ディスクドライブ１１５１および光学ディスクドライブ１１５５は、通常、インターフェース１１５０などの、移動型メモリインターフェースによってシステムバス１１２１に接続されている。
【００７７】
上述して図１１に示した、ドライブ類およびそれに関連するコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュールおよびコンピュータ１１１０用のその他のデータを記憶する。図１１には、例えば、ハードディスクドライブ１１４１は、オペレーティングシステム１１４４、アプリケーションプログラム１１４５、その他のプログラムモジュール１１４６、およびプログラムデータ１１４７を記憶する状態で示してある。ここで留意すべきことは、これらの構成要素は、オペレーティングシステム１１３４、アプリケーションプログラム１１３５、その他のプログラムモジュール１１３６、およびプログラムデータ１１３７と同じでも、異なってもよいことである。オペレーティングシステム１１４４、アプリケーションプログラム１１４５、その他のプログラムモジュール１１４６、およびプログラムデータ１１４７には、それらが少なくとも異なるコピーであることを示すために、ここでは異なる番号を与えてある。ユーザは、キーボード１１６２および一般にマウスと呼ばれるポインティングデバイス１１６１、トラックボールまたはタッチパッドなどの入力装置を介して、コマンドおよび情報をコンピュータ１１１０に入力することができる。
【００７８】
その他の入力装置（図示せず）としては、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナー、無線受信器、またはテレビジョンもしくはビデオ受信機、その他を挙げることができる。これらおよびその他の入力装置は、システムバス１１２１に結合されているユーザ入力インターフェース１１６０を介して、処理ユニット１１２０に接続されることが多いが、例えば、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）などの、その他のインターフェースおよびバス構造によって接続することもできる。モニタ１１９１またはその他の種類のディスプレイ装置も、ビデオインターフェース１１９０などのインターフェースを経由してシステムバス１１２１に接続される。モニタに加えて、コンピュータには、スピーカ１１９７およびプリンタ１１９６などのその他の周辺出力装置を含めてもよく、これらは出力周辺インターフェース１１９５を介して接続することができる。
【００７９】
コンピュータ１１１０は、リモートコンピュータ（複数を含む）１１８０などの、１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作可能である。リモートコンピュータ１１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたはその他の共通ネットワークノードとしてもよく、図１１にはメモリ記憶装置１１８１だけを示してあるが、通常は、コンピュータ１１１０に関して記述した要素の多数または全部を含む。図１１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１１７１およびワイドエリアネットワーク（ＷＡＮ）１１７３を含むが、その他のネットワークを含めることもできる。そのようなネットワーク環境は、オフィス、企業内コンピュータネットワーク、イントラネットおよびインターネットにおいて普及している。
【００８０】
ＬＡＮネットワーク化環境において使用される場合には、コンピュータ１１１０は、ネットワークインターフェースまたはアダプタ１１７０を介して、ＬＡＮ１１７１に接続される。ＷＡＮネットワーク化環境において使用される場合には、コンピュータ１１１０は、通常、モデム１１７２またはインターネットなどのＷＡＮ１１７３上での通信を確立するための、その他の手段を含む。モデム１１７２は、内部式でも外部式でもよく、ユーザ入力インターフェース１１６０、またはその他の適当な機構を経由してシステムバス１１２１に接続することができる。ネットワーク化環境において、コンピュータ１１１０に関して図示されたプログラムモジュールまたはその一部を、リモート記憶装置に格納することもできる。限定ではなく一例として、図１１には、メモリ装置１１８１上に常駐するものとしてリモートアプリケーションプログラム１１８５を示してある。ここで、図示したネットワーク接続は、例証的なものであり、コンピュータ間の通信リンクを確立するためのその他の手段を使用することができることに気づくであろう。
【００８１】
上記の本発明の説明は、例証と説明のために提示したものである。それは網羅的とするものでも、開示した厳密な形態に本発明を限定するものでもない。上記の教示に照らせば、多くの修正形態および変形形態が可能である。本発明の範囲は、上記の発明の詳細な説明によってではなく、添付の特許請求の範囲によって限定することを意図するものである。
【図面の簡単な説明】
【００８２】
【図１Ａ】スタートポロジを有するコンピュータネットワークを示すブロック図である。
【図１Ｂ】完全接続ユニキャストトポロジを有するコンピュータネットワークを示すブロック図である。
【図１Ｃ】エンドシステムミキシングを使用する汎用グラフトポロジを有するコンピュータネットワークを示すブロック図である。
【図２】本明細書で開示するＰ２Ｐ音声通信システムおよび方法の例証的実現形態を示すブロック図である。
【図３】図２に示すようなピアノードのそれぞれに収納されている、Ｐ２Ｐ音声通信システムの汎用の例証的実現形態を示す、詳細ブロック図である。
【図４】図３に示すＰ２Ｐ音声通信システムの一般的動作を示す、全体フロー図である。
【図５】この実用例において使用される、音声エンコーダの動作の詳細ブロック／フロー図である。
【図６】この実用例において使用される、図３に示す音声ミキサの動作の詳細ブロック／フロー図である。
【図７】この実用例において使用される、音声デコーダの動作の詳細ブロック／フロー図である。
【図８】この実用例において使用される、３つのピアノード（１、２および３）に対する、図６に示す音声ミキサの動作を示す図である。
【図９】汎用マルチパーティ会議グラフにおいてゲートウェイノードとして働く、Ｐ２Ｐ音声通信システムおよび方法のミューチュアルキャストクリークの例証的例を示す図である。
【図１０】スタートポロジを備えるマルチパーティ通信セッションにおいてスーパーサーバとして働く、Ｐ２Ｐ音声通信システムおよび方法のミューチュアルキャストの例証的例を示す図である。
【図１１】図３および図４に示すＰ２Ｐ音声通信システムおよび方法を実装することのできる、適当な計算機システム環境の例を示す図である。
【図１Ａ】
2006268844.tif 000008
【図１Ｂ】
2006268844.tif 000009
【図１Ｃ】
2006268844.tif 000010
【図２】
2006268844.tif 000011
【図３】
2006268844.tif 000012
【図４】
2006268844.tif 000013
【図５】
2006268844.tif 000014
【図６】
2006268844.tif 000015
【図７】
2006268844.tif 000016
【図８】
2006268844.tif 000017
【図９】
2006268844.tif 000018
【図１０】
2006268844.tif 000019
【図１１】
2006268844.tif 000020