(57)【要約】  ストリーミングされるべきコンテンツ・クリップを受信するための源である第１のサーバを決定すること、ストリーミングされるべきコンテンツ・クリップを、選択された第１のサーバに要求すること、ストリーミングされるコンテンツ・クリップを、選択された第１のサーバから受信すること、ダウンロードされるべきコンテンツ・クリップを受信するための源であるピア・デバイスを決定すること、ダウンロードされるべきコンテンツ・クリップを要求して、ダウンロードされるコンテンツ・クリップを受信することを含む、無線ネットワークを介してコンテンツを受信するための方法および装置が説明される。第１のサーバはメッシュ・コンテンツ・サーバである。
2010538529.tif 000002
【特許請求の範囲】
【請求項１】
無線ネットワークを介してコンテンツを受信するための方法であって、
コンテンツ・クリップを受信するためにストリーミング元の第１のサーバを決定するステップと、
ストリーミングされるべき前記コンテンツ・クリップを、前記選択された第１のサーバに要求するステップと、
前記ストリーミングされるコンテンツ・クリップを、前記選択された第１のサーバから受信するステップと、
コンテンツ・クリップを受信するためにダウンロード元のピア・デバイスを決定するステップと、
ダウンロードされるべき前記コンテンツ・クリップを要求するステップと、
前記ダウンロードされるコンテンツ・クリップを受信するステップと、
を含む、前記方法。
【請求項２】
前記第１のサーバは、メッシュ・コンテンツ・サーバである請求項１に記載の方法。
【請求項３】
前記ピア・デバイスに関する情報を獲得するステップと、
前記ピア・デバイスを含むピア・ツー・ピア・ネットワークに加わるステップと、
をさらに含む、請求項１に記載の方法。
【請求項４】
前記ダウンロードされるコンテンツ・クリップが、期限より前に受信されたかどうかを判定するステップと、
前記期限より前に受信されなかった前記ダウンロードされるコンテンツ・クリップの欠落している部分のストリーミングを、前記メッシュ・コンテンツ・サーバに要求するステップと、
をさらに含む、請求項２に記載の方法。
【請求項５】
前記メッシュ・コンテンツ・サーバは、コンテンツ格納能力およびコンテンツ処理能力を有するメッシュ・アクセス・ポイントである、請求項２に記載の方法。
【請求項６】
前記メッシュ・コンテンツ・サーバは、メッシュ・アクセス・ポイントと並置される、請求項２に記載の方法。
【請求項７】
ストリーミングされるべきコンテンツ・クリップの数を計算するステップをさらに含む、請求項２に記載の方法。
【請求項８】
ストリーミングされるべき各コンテンツ・クリップに関する前記メッシュ・コンテンツ・サーバが異なる、請求項７に記載の方法。
【請求項９】
ストリーミングされるべきいくつかのコンテンツ・クリップに関する前記メッシュ・コンテンツ・サーバが異なる、請求項７に記載の方法。
【請求項１０】
前記ストリーミングされるコンテンツ・クリップの中の受信されるパケットは、順序どおりに受信される、請求項１に記載の方法。
【請求項１１】
前記ダウンロードされるコンテンツ・クリップの中の受信されるパケットは、順序が乱れて受信される、請求項１に記載の方法。
【請求項１２】
前記ダウンロードされる順序が乱れたコンテンツ・クリップの中の前記受信されるパケットは、バッファリングされる、請求項１１に記載の方法。
【請求項１３】
前記メッシュ・コンテンツ・サーバを決定する前記ステップは、
第２のサーバに要求メッセージを送信するステップと、
前記第２のサーバから、一次メッシュ・コンテンツ・サーバおよび二次メッシュ・コンテンツ・サーバについての情報を受信するステップと、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するステップと、
をさらに含む、請求項２に記載の方法。
【請求項１４】
前記第２のサーバは、メイン・サーバである、請求項１３に記載の方法。
【請求項１５】
前記メッシュ・コンテンツ・サーバを決定する前記ステップは、
第２のサーバに要求メッセージを送信するステップと、
前記第２のサーバから、候補メッシュ・コンテンツ・サーバのリストについての情報を受信するステップと、
各候補メッシュ・コンテンツ・サーバに至る終端間遅延を算出するステップと、
最小の終端間遅延に基づいて、一次メッシュ・コンテンツ・サーバを選択するステップと、
２番目に小さい終端間遅延に基づいて、二次メッシュ・コンテンツ・サーバを選択するステップと、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するステップと、
をさらに含む、請求項２に記載の方法。
【請求項１６】
前記第２のサーバは、メイン・サーバである、請求項１４に記載の方法。
【請求項１７】
前記メッシュ・コンテンツ・サーバを決定する前記ステップは、
前記無線ネットワークにわたってメッシュ・コンテンツ・サーバ要求メッセージを同時送信するステップと、
複数のメッシュ・コンテンツ・サーバから応答を受信するステップと、
前記要求側と前記応答するメッシュ・コンテンツ・サーバとの間の最低のホップ・カウントに基づいて、一次メッシュ・コンテンツ・サーバを選択するステップと、
前記要求側と前記応答するメッシュ・コンテンツ・サーバとの間の２番目に低いホップ・カウントに基づいて、二次メッシュ・コンテンツ・サーバを選択するステップと、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するステップと、
をさらに含む、請求項２に記載の方法。
【請求項１８】
前記メッシュ・コンテンツ・サーバを決定する前記ステップは、
前記無線ネットワークにわたってメッシュ・コンテンツ・サーバ要求メッセージを同時送信するステップと、
複数のメッシュ・コンテンツ・サーバから応答を受信するステップと、
前記要求側と前記応答するメッシュ・コンテンツ・サーバとの間の最良の経路に基づいて、一次メッシュ・コンテンツ・サーバを選択するステップと、
前記要求側と前記応答するメッシュ・コンテンツ・サーバとの間の次善の経路に基づいて、二次メッシュ・コンテンツ・サーバを選択するステップと、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するステップと、
をさらに含む、請求項２に記載の方法。
【請求項１９】
無線ネットワークを介してコンテンツを受信するためのデバイスであって、
ストリーミングされるべきコンテンツ・クリップを受信するための源である第１のサーバを決定するための手段と、
前記ストリーミングされるべきコンテンツ・クリップを、前記選択された第１のサーバに要求するための手段と、
前記ストリーミングされるコンテンツ・クリップを、前記選択された第１のサーバから受信するための手段と、
ダウンロードされるべきコンテンツ・クリップを受信するための源であるピア・デバイスを決定するための手段と、
前記ダウンロードされるべきコンテンツ・クリップを要求するための手段と、
前記ダウンロードされるコンテンツ・クリップを受信するための手段と、
を備える、前記デバイス。
【請求項２０】
前記第１のサーバは、メッシュ・コンテンツ・サーバである、請求項１９に記載のデバイス。
【請求項２１】
前記ピア・デバイスに関する情報を獲得するための手段と、
前記ピア・デバイスを含むピア・ツー・ピア・ネットワークに加わるための手段と、
をさらに備える、請求項１９に記載のデバイス。
【請求項２２】
前記ダウンロードされるコンテンツ・クリップが、期限より前に受信されたかどうかを判定するための手段と、
前記期限より前に受信されなかった前記ダウンロードされるコンテンツ・クリップの欠落している部分のストリーミングを、前記メッシュ・コンテンツ・サーバに要求するための手段と、
をさらに備える、請求項２０に記載のデバイス。
【請求項２３】
ストリーミングされるべきコンテンツ・クリップの数を計算するための手段をさらに備える、請求項２０に記載のデバイス。
【請求項２４】
前記メッシュ・コンテンツ・サーバと前記ピア・デバイスとが同一である、請求項２０に記載のデバイス。
【請求項２５】
ストリーミングされるべき各コンテンツ・クリップに関する前記メッシュ・コンテンツ・サーバが異なる、請求項２０に記載のデバイス。
【請求項２６】
ストリーミングされるべきいくつかのコンテンツ・クリップに関する前記メッシュ・コンテンツ・サーバが異なる、請求項２０に記載のデバイス。
【請求項２７】
前記ストリーミングされるコンテンツ・クリップの中の受信されるパケットは、順序どおりに受信される、請求項１９に記載のデバイス。
【請求項２８】
前記ダウンロードされるコンテンツ・クリップの中の受信されるパケットは、順序が乱れて受信される、請求項１９に記載のデバイス。
【請求項２９】
前記ダウンロードされる順序が乱れたコンテンツ・クリップの中の前記受信されるパケットは、バッファリングされる、請求項２８に記載のデバイス。
【請求項３０】
前記メッシュ・コンテンツ・サーバを決定するための前記手段は、
第２のサーバに要求メッセージを送信するための手段と、
前記第２のサーバから、一次メッシュ・コンテンツ・サーバおよび二次メッシュ・コンテンツ・サーバについての情報を受信するための手段と、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するための手段と、
をさらに備える、請求項２０に記載のデバイス。
【請求項３１】
前記第２のサーバは、メイン・サーバである、請求項３０に記載のデバイス。
【請求項３２】
前記メッシュ・コンテンツ・サーバを決定するための前記手段は、
第２のサーバに要求メッセージを送信するための手段と、
前記第２のサーバから、候補メッシュ・コンテンツ・サーバのリストについての情報を受信するための手段と、
各候補メッシュ・コンテンツ・サーバに至る終端間遅延を算出するための手段と、
最小の終端間遅延に基づいて、一次メッシュ・コンテンツ・サーバを選択するための手段と、
２番目に小さい終端間遅延に基づいて、二次メッシュ・コンテンツ・サーバを選択するための手段と、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するための手段と、
をさらに備える、請求項２０に記載のデバイス。
【請求項３３】
前記第２のサーバは、メイン・サーバである、請求項３２に記載のデバイス。
【請求項３４】
前記メッシュ・コンテンツ・サーバを決定するための前記手段は、
前記無線ネットワークにわたってメッシュ・コンテンツ・サーバ要求メッセージを同時送信するための手段と、
複数のメッシュ・コンテンツ・サーバから応答を受信するための手段と、
前記デバイスと前記応答するメッシュ・コンテンツ・サーバとの間の最低のホップ・カウントに基づいて、一次メッシュ・コンテンツ・サーバを選択するための手段と、
前記デバイスと前記応答するメッシュ・コンテンツ・サーバとの間の２番目に低いホップ・カウントに基づいて、二次メッシュ・コンテンツ・サーバを選択するための手段と、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するための手段と、
をさらに備える、請求項２０に記載のデバイス。
【請求項３５】
前記メッシュ・コンテンツ・サーバを決定するための前記手段は、
前記無線ネットワークにわたってメッシュ・コンテンツ・サーバ要求メッセージを同時送信するための手段と、
複数のメッシュ・コンテンツ・サーバから応答を受信するための手段と、
前記デバイスと前記応答するメッシュ・コンテンツ・サーバとの間の最良の経路に基づいて、一次メッシュ・コンテンツ・サーバを選択するための手段と、
前記デバイスと前記応答するメッシュ・コンテンツ・サーバとの間の次善の経路に基づいて、二次メッシュ・コンテンツ・サーバを選択するための手段と、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するための手段と、
をさらに備える、請求項２０に記載のデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線メッシュ・ネットワークに関し、詳細には、クライアント・デバイスに高品質コンテンツ・サービスを配信するためのインフラストラクチャ・マルチホップ無線メッシュ・ネットワークの使用に関する。
【背景技術】
【０００２】
従来、コンテンツは、コンテンツ・ソース・サーバから直接に、またはコンテンツ配信ネットワーク（ＣＤＮ）におけるエッジ・サーバを経由して間接的に、インターネットを介してエンド・ユーザにストリーミングされる。インターネットの縁端部に戦略的に配置された多くのエッジ・サーバを展開することにより、ＣＤＮアプローチは、ネットワークを介するトラフィックを減らし、ユーザの起動遅延を短くし、さらにユーザの視聴品質を向上させることができる。Ｐ２Ｐコンテンツ・ストリーミングが、低いサーバ・インフラストラクチャ・コストのため、代替として登場している。関与するユーザ／ピアのリソース（アップロード帯域幅、記憶スペース、処理能力など）を利用することにより、ピア・ツー・ピア・システムにおける利用可能なリソースは、ユーザ／ピアの数に比例して増加する。本明細書で使用される「／」は、同一の、または同様の動作または構成要素に関する代替の名前を表す。
【０００３】
Ｐ２Ｐアプリケーションは当初、ファイル共有のための手段として導入された。ＢｉｔＴｏｒｒｅｎｔやＫａＺａａなどのアプリケーションが、多数のユーザを引き付け、インターネットを介する大量のネットワーク・トラフィックの一因となった。また、Ｐ２Ｐファイル共有のための他の技術も開発されている。最近、コンテンツ・ストリーミング・サービスをサポートするＰ２Ｐ技術も、採用されている。しかし、Ｐ２Ｐストリーミングは、ユーザ体験を大きく低下させる可能性がある長い起動遅延時間や解約（チャーン）を誘導させる不安定性などの問題を経験する。さらに、Ｐ２Ｐストリーミング作業のほとんどは、有線ネットワーク状況において行われ、無線ネットワークの独特の特徴の影響を考慮していなかった。限られた帯域幅、共有される媒体に起因する信号干渉、およびマルチホップ・パス問題のため、バックホール無線メッシュ・ネットワーク（ＷＭＮ）におけるフローの数、および各フローによって得られるグッドプットは、限られている。グッドプットとは、受信者／クライアント・デバイス／エンド・デバイス／エンド・ユーザによって正しく受信される毎秒のビット数である。無線メッシュ・ネットワーク内で同一のコンテンツを共有するピアの数は、ネットワークの地理的サイズおよびピア母集団が限られているため、小さい可能性がある。無線メッシュ・ネットワーク内の各ピアが、有線のインターネットにおける他のピアと異なるコンテンツを共有する場合、ゲートウェイに関する重いトラフィック負荷がもたらされる。さらに、通信パスが、ゲートウェイとクライアントとの間に、またはメッシュ・ネットワーク内のピアの間で多数のホップを含む場合、通信パスは、特に、共有される媒体である無線媒体において、多くの無線ネットワーク帯域幅リソースを消費する。無線チャネル上の２つのノード間で伝送が行われる際、干渉範囲内の他のすべてのノードは、干渉のため、同一のチャネル上でデータを全く送信することができない。従来のＰ２Ｐストリーミング技術では、現行のインフラストラクチャＷＭＮにおいて適当な数のコンテンツ・フローに関してサービス品質（ＱｏＳ）を保証するのは困難である。
【０００４】
インターネット・ユーザにラストマイルのアクセシビリティを提供するようにＩＥＥＥ８０２．１１ベースのＷＭＮを展開することに大幅な進歩があった。その一方で、ＩＰネットワークを介するマルチメディア・コンテンツのストリーミングが、ますます普及してきている。ＷＭＮがますます展開され、ＷＭＮユーザの数が増加するとともに、無線メッシュ・ネットワークを介するマルチメディア・ストリーミングをサポートすることが、ますます重要になっている。
【０００５】
移動アドホック・ネットワークおよび無線メッシュ・ネットワークを介するコンテンツ・ストリーミングが研究されてきた。多重記述符号化や、単一のサーバから受信機に至るパス・ダイバーシティなどの様々なクライアント−サーバ技術が、コンテンツ・サービスの配信のため、および無線ネットワークを介してコンテンツを送信するために開発されてきた。無線ネットワーク特性、およびストリーミング・アプリケーションの厳密な要件を考慮して、単一のサーバからクライアント・デバイスに至るトランスポート効率を向上させるクロスレイヤ・アプローチも研究されてきた。しかし、そのようなクライアント−サーバ方法は、スケーリングがあまりうまく行かず、さらにサーバ（またはサーバが、有線のインターネット内にある場合、ゲートウェイ）周囲のトラフィック輻輳をもたらす可能性がある。
【０００６】
無線メッシュ・ネットワークにおいて、２つのノード間で確立されたパスは、いくつかの中継ノード／メッシュ・アクセス・ポイントを経由する可能性がある。無線媒体における自己干渉のため、パス容量は、ホップ・カウントが増加するにつれて減少する。さらに、大きいホップ・カウントは、自らのフロー伝送に悪影響を与える（自己干渉）とともに、確立された他の接続にも悪影響を与えて（クロス干渉）、全体的なシステム容量を低下させる無線信号干渉の確率を高める。しかし、ホップ・カウントは、パス品質を決定する唯一の要因ではない。無線リンクの品質は、受信される無線信号強度、パケットロス率、近辺のノードの間の競合、リンク・データレート、およびリンクにかかるトラフィック負荷に依存する。ＩＥＥＥ８０２．１１無線は、リンク品質に応じたマルチレート適応をサポートする。マルチホップの高レート・パスは、単一ホップの低レート・パスと比べて、より良いスループット、およびより短い遅延を実現することができる可能性がある。無線メッシュ・ネットワークを介してスケーラブルな高品質のメディア／コンテンツ・ストリーミング・サービスをどのように提供するかは、困難な問題である。
【発明の概要】
【０００７】
マルチホップ無線メッシュ・ネットワーク（ＷＭＮ）が、メトロ・エリア・インターネット・アクセス・ネットワーク、公衆安全ネットワーク、および過渡的ネットワークにおいて応用性を有する将来性のある技術として出現しつつある。以下の２つのタイプのメッシュ・ネットワークが、存在する。すなわち、クライアント−メッシュ・ネットワークおよびインフラストラクチャ−メッシュ・ネットワークである。クライアント−メッシュ・ネットワーク、つまり、アドホック・ネットワークは、インフラストラクチャが全く要求されずに、クライアント・デバイスによって形成される。クライアント−メッシュ・ネットワークにおいて、各ノードは、同一の役割を果たし、パケット・ルーティングおよびパケット転送に関与する。これに対して、インフラストラクチャＷＭＮは、ＭＡＰ（メッシュ・アクセス・ポイント）／ルータおよびクライアント・デバイスから成る。ＭＡＰは、マルチホップ無線メッシュ・バックホール・インフラストラクチャを形成するように無線リンクを介して互いに接続される。１つまたは複数のＭＡＰが、有線のインターネットに接続され、ゲートウェイと呼ばれる。一般に、ＭＡＰは、２つ以上の無線インタフェースを有する。１つの無線インタフェースは、クライアントのネットワーク・アクセスを目的とするアクセス・インタフェースである。第２の無線インタフェースは、ルーティングおよびデータ転送を目的とする中継インタフェースである。クライアント・デバイス（例えば、ラップトップ、デュアル・モード・スマートフォン、ＰＤＡ（パーソナル・デジタル・アシスタント）など）は、無線メッシュ・ネットワークにアクセスするために、自らを近辺のＭＡＰに関連付ける。クライアント・デバイス／エンド・デバイスは、パケット中継またはルーティング・プロセスに関与しない。クライアント・デバイスは、クライアント・デバイスが関連付けられたＭＡＰに（またはそのようなＭＡＰから）パケットを送信（または受信）する。ＷＭＮにおけるパケット配信は、バックホール・ルーティング・プロトコルを介してＭＡＰによって扱われる。
【０００８】
本発明は、インフラストラクチャ・マルチホップＷＭＮ（インフラストラクチャ・マルチホップ無線メッシュ・ネットワーク）を介して高品質コンテンツ・サービス、例えば、コンテンツ・ストリーミング・サービスおよびビデオ・オンデマンド・サービスを配信するための統一されたピア・ツー・ピア（Ｐ２Ｐ）キャッシュ（ＵＰＡＣ）フレームワークである。本明細書で使用されるコンテンツには、オーディオ、ビデオ、データ、情報、マルチメディアなどが含まれる。マルチホップ無線ネットワークにおいてコンテンツをストリーミングすることは、多くの課題、例えば、利用可能なパス帯域幅が変化すること、共有される媒体に起因する信号干渉、複数の中継ノードの影響などに直面する。インフラストラクチャＷＭＮの容量を増加させ、さらに高コンテンツ品質のストリーミング・サービスを確実にするために、本発明は、マルチホップ無線メッシュ・ネットワーク内の選択された無線メッシュ・アクセス・ポイント（ＭＡＰ）においてコンテンツをキャッシュする。さらに、サーバおよびネットワークに課せられる作業負荷を減らすことをベストエフォートで助けるように、ピアが使用される。ＵＰＡＣフレームワークは、コンテンツ配信ネットワーク・アプローチとピア・ツー・ピア・ネットワーキング・アプローチの両方の利点を有する。本発明のＵＰＡＣは、システム・パフォーマンスを最適化するための無線メッシュ・ネットワークにおけるサービス品質（ＱｏＳ）を意識したコンテンツ・サービスの特定の特性に合う。ＵＰＡＣにおいて、最適なコンテンツ品質を得るために、デバイスは、ＭＡＰコンテンツ・キャッシュ・サーバ、および他のピア・デバイスとピア・ツー・ピア関係を形成することができる。その一方で、デバイスは、ＭＡＰコンテンツ・キャッシュ・サーバとクライアント−サーバ関係を形成することもできる。さらに、クライアント・デバイスのためのサービング・キャッシュ・サーバ、およびそのサーバとそのクライアント・デバイスとの間の終端間経路を選択する方法が説明される。
【０００９】
ストリーミングされるべきコンテンツ・クリップを受信するための源である第１のサーバを決定すること、ストリーミングされるべきコンテンツ・クリップを、選択された第１のサーバに要求すること、ストリーミングされるコンテンツ・クリップを、選択された第１のサーバから受信すること、ダウンロードされるべきコンテンツ・クリップを受信するための源であるピア・デバイスを決定すること、ダウンロードされるべきコンテンツ・クリップを要求して、ダウンロードされるコンテンツ・クリップを受信することを含む、無線ネットワークを介してコンテンツを受信するための方法および装置が、説明される。第１のサーバは、メッシュ・コンテンツ・サーバである。
【００１０】
本発明は、添付の図面と併せて読まれて、以下の詳細な説明から理解されることが最善である。これらの図面は、以下に簡単に説明される以下の図を含む。
【図面の簡単な説明】
【００１１】
【図１】本発明の原理によるコンテンツ・サービス配信システムの概略図である。
【図２】クライアント・デバイス側からの統一されたピア・ツー・ピア（Ｐ２Ｐ）キャッシュ・サーバ（ＵＰＡＣ）コンテンツ・サービス・プロセスを示す流れ図である。
【図３】本発明の集中メッシュ・コンテンツ・サーバ選択方法を示す流れ図である。
【図４】終端間遅延を選択基準として使用する本発明のオーバーレイ・メッシュ・コンテンツ・サーバ選択方法を示す流れ図である。
【図５】ホップ・カウントを選択基準として使用する本発明の分散メッシュ・コンテンツ・サーバ選択方法を示す流れ図である。
【図６】ルーティング・メトリックを選択基準として使用する本発明の分散メッシュ・コンテンツ・サーバ選択方法を示す流れ図である。
【図７】本発明の原理によるメッシュ・コンテンツ・サーバを示すブロック図である。
【図８】本発明の原理によるクライアント・デバイスを示すブロック図である。
【発明を実施するための形態】
【００１２】
ＷＭＮにおけるインフラストラクチャとしてのＭＡＰ、ならびに処理能力およびストレージの進歩を所与として、本発明は、ビデオ／マルチメディア・サービスに関するシステム容量を増加させ、高いコンテンツ・サービス品質を確実にするため、選択された無線メッシュ・アクセス・ポイントにおいてコンテンツ（オーディオ・コンテンツ、ビデオ・コンテンツ、および／またはマルチメディア・コンテンツ）をキャッシュする、または無線メッシュ・ネットワーク内の選択されたＭＡＰと同じ場所にキャッシュ・サーバを配置する。さらに、本発明は、可能な場合、ネットワークにわたって作業負荷を分散させ、ソースとシンク／クライアント・デバイス／エンド・デバイスの間のパス上のリソース消費を減らすようにベストエフォートでピアを使用する。
【００１３】
本発明のアーキテクチャと既存のインターネットＣＤＮスキームの間の主な違いは、以下のとおりである。すなわち、
１．本発明におけるクライアント・デバイスは、ＭＡＰコンテンツ・キャッシュ・サーバ、および他のピア・デバイスとＰ２Ｐ関係を形成するとともに、ＭＡＰキャッシュ・サーバとクライアント−サーバ関係を形成することも同時にできる。
２．本発明のアーキテクチャにおけるＭＡＰコンテンツ・キャッシュ・サーバは、コンテンツ（オーディオ、ビデオ、および／またはマルチメディア）ストリーミングとＰ２Ｐデータ・ダウンロード／フェッチをともにサポートする。コンテンツ・ストリーミングとＰ２Ｐコンテンツ・フェッチに関してスケジューリング・スキームは、異なることに留意することが重要である。コンテンツ・ストリーミングは、ストリーミングされるコンテンツ／データの順序どおりの配信を要求する。Ｐ２Ｐコンテンツ・フェッチは、ピアの間で異なる配布ポリシーを使用することが可能である。配布ポリシーは、パケット配布の順序の選択を規定するポリシーである。例えば、配布される次のパケットは、ネットワークにおける最も稀なコンテンツ・ユニット、またはネットワークにおける最もよく要求されるコンテンツ・ユニット、あるいはパケット配布のための他の何らかの原則であることが可能である。
３．ネットワーク環境が異なる。インターネットにおいて、ボトルネックは、サーバまたはクライアントにおいて存在する。無線メッシュ・ネットワークにおいて、ボトルネックは、ネットワーク内に存在することが可能である。クライアント・デバイスのためのコンテンツ・セッションのサービス品質（ＱｏＳ）を最適化するようにキャッシュ・サーバを選択するためのスキームは、インターネットにおいてと、ＷＭＮにおいてとで異なる。本発明は、いくつかの代替のサーバ選択スキームを含む。
４．無線は、共有される媒体であり、このため、１つのコンテンツ・フローが、別のフローに干渉することが、この２つのフローが、異なるコンテンツ・キャッシュ・サーバを出所とし、同一の中間中継ノードを通過しない場合でさえ、可能である。本発明のサーバ選択スキームは、この効果を考慮に入れる。
５．パス品質は、ＷＭＮにおいて時とともに変化する。このことは、クライアント・デバイスが、サーバおよびパスを選択する際、および更新する際に、本発明において考慮に入れられる。
【００１４】
本発明は、インフラストラクチャＷＭＮを介するビデオ・オンデマンドやコンテンツ・ストリーミングなどの、高品質コンテンツ（オーディオ、ビデオ、マルチメディア）配信サービスのための統一されたピア・ツー・ピア（Ｐ２Ｐ）キャッシュ（ＵＰＡＣ）フレームワーク／アーキテクチャである。ＵＰＡＣは、複数のメッシュ・コンテンツ・サーバ、および複数のピア・ツー・ピア技術を使用する。「メッシュ・コンテンツ・サーバ」という用語は、限定することは意図しておらず、メッシュ・コンテンツ・サーバは、オーディオ・コンテンツ、ビデオ・コンテンツ、データ・コンテンツ、およびマルチメディア・コンテンツを含む任意の形態のコンテンツを配信することが可能である。コンテンツ・サービスのシステム容量を増加させ、さらに高いコンテンツ品質を確実にするために、コンテンツは、メッシュ・ネットワーク内の選択された無線メッシュ・アクセス・ポイントにおいてキャッシュされる。代替的に、コンテンツ・サーバは、無線メッシュ・ネットワーク内の選択されたＭＡＰと並置される。本明細書で使用されるメッシュ・コンテンツ・サーバとは、キャッシュを有するＭＡＰ、または並置されたコンテンツ・サーバを有するＭＡＰである。また、メッシュ・コンテンツ・サーバは、インターネットへのゲートウェイであることも可能である。ＵＰＡＣにおけるメッシュ・コンテンツ・サーバは、コンテンツ・サーバおよびピアという２つの役割を果たす。コンテンツ・サーバとして、メッシュ・コンテンツ・サーバは、要求に応じて、クライアント・デバイスにコンテンツをストリーミングすることができる。ピアとして、メッシュ・コンテンツ・サーバは、Ｐ２Ｐデータ・フェッチのためのピアである。メッシュ・コンテンツ・サーバは、ストリーミングおよびデータ・フェッチという２つのスケジューリング・スキームをサポートする。ストリーミングは、ストリーミングされるコンテンツ／データの順序どおりの配信を要求する。Ｐ２Ｐデータ・フェッチは、異なる配布ポリシー、例えば、ピアの間でデータ利用可能性を最大化する配布ポリシーを使用することが可能である。クライアント・デバイスは、メッシュにおいて利用可能である場合、サーバおよびネットワークに課せられるトラフィック負荷をさらに減らすようにベストエフォート・ピアの役割をする。コンテンツ・サービス品質を最適化するために、クライアント・デバイスは、メッシュ・コンテンツ・サーバ、および他のピア・デバイスとＰ２Ｐ関係を形成することができる。その一方で、クライアント・デバイスは、メッシュ・コンテンツ・サーバとクライアント−サーバ関係を確立することができる。
【００１５】
本明細書で使用されるＭＡＰという用語とメッシュ・コンテンツ・サーバという用語は、互換的に使用されることが可能である。しかし、前述したとおり、メッシュ・コンテンツ・サーバは、キャッシュを有するＭＡＰ、または並置されたコンテンツ・サーバを有するＭＡＰである。ゲートウェイ・メッシュ・コンテンツ・サーバは、キャッシュ、または並置されたコンテンツ・サーバを有する、インターネットなどの有線ネットワークへのゲートウェイである。ゲートウェイ・メッシュ・コンテンツ・サーバは、メッシュ・コンテンツ・サーバであり、さらにゲートウェイでもある。図１は、ＷＭＮを介するコンテンツ・サービス・システムを示す。コンテンツ・サービス・システムは、ＭＡＰ（メッシュ・アクセス・ポイント）、メッシュ・コンテンツ・サーバ、およびクライアント・デバイスを含む。ＭＡＰとメッシュ・コンテンツ・サーバは、無線リンクを介して互いに接続されて、無線メッシュ・マルチホップ・バックホール・インフラストラクチャを形成する。有線ネットワークに接続された１つまたは複数のＭＡＰが、ゲートウェイと呼ばれる。ＭＡＰとメッシュ・コンテンツ・サーバは、ルーティングおよびデータ転送に関与する。
【００１６】
具体的には、図１において、インターネット１０５が、ゲートウェイ・メッシュ・コンテンツ・サーバ１１０に接続され、サーバ１１０と通信状態にある。ゲートウェイ・メッシュ・コンテンツ・サーバ１１０は、並置されたコンテンツ・サーバを有するＭＡＰ１１５ａに接続される。また、１１５ｂおよび１１５ｃも、並置されたコンテンツ・サーバを有するＭＡＰである。また、ゲートウェイ・メッシュ・コンテンツ・サーバ１１０は、コンテンツ・キャッシュを有するＭＡＰ１２０ａにも接続され、ＭＡＰ１２０ａと通信状態にある。コンテンツ・キャッシュを有するＭＡＰ１２０ａとメッシュ・コンテンツ・サーバ１１５ａはともに、ＭＡＰ１２５ａに接続され、ＭＡＰ１２５ａと通信状態にある。また、１２５ｂ、１２５ｃ、および１２５ｄもＭＡＰである。クライアント・デバイス／エンド・デバイス１３０は、様々なＭＡＰ、および様々なメッシュ・コンテンツ・サーバに接続される。
【００１７】
ＭＡＰは、ネットワーク・アクセスおよびデータ中継という２種類の無線機能をサポートする。ネットワーク・アクセス機能は、クライアント・デバイス／エンド・デバイスにネットワーク・アクセスを提供する。中継機能は、マルチホップ無線メッシュ・バックホールを構築し、クライアント・デバイスのトラフィックを宛先に中継するために使用される。メッシュ・クライアント・デバイス／クライアント・デバイス（例えば、ラップトップ、ＰＤＡ、およびデュアル・モード・スマートフォンなど）が、無線メッシュ・ネットワークにアクセスするために近辺のＭＡＰに関連付けられる。このクライアント・デバイスは、パケット中継およびパケット・ルーティングに関与しない。このクライアント・デバイスは、このクライアント・デバイスが関連付けられたＭＡＰに（またはそのようなＭＡＰから）パケットを送信（または受信）する。パケット配信の残りの部分は、バックホール・ルーティング・プロトコルを介してＭＡＰによって扱われる。
【００１８】
ＵＰＡＣにおいて、元のコンテンツ・ソースであるメイン・コンテンツ・サーバが、存在するものと想定される。メイン・コンテンツ・サーバは、無線メッシュ・ネットワークの外部に存在してもよく、または、無線メッシュ・ネットワークの内部に存在してもよい。コンテンツは、オフピーク時配信などの機構および手段を介して、無線メッシュ・ネットワーク内に配置された本発明のメッシュ・コンテンツ・サーバに配信されるものとさらに想定される。メッシュ・コンテンツ・サーバは、キャッシュ機能を有する、またはコンテンツ・サーバと並置される。
【００１９】
メッシュ・コンテンツ・サーバは、各メッシュ・クライアントが、数ホップ内で少なくとも１つのメッシュ・コンテンツ・サーバにアクセスすることができるというポリシーに従って配置される。このことは、各メッシュ・コンテンツ・サーバが、近辺のクライアント・デバイスにコンテンツのいくつかの部分を供給するためであり、したがって、ホップ・カウントは、可能な限り小さくなければならない。このことは、単一無線ワイヤレス・メッシュ・ネットワークにおいて特に当てはまる。というのは、ホップ・カウントが、利用可能な帯域幅に大きな影響を与えるからである。このことは、無線メッシュ・ネットワークが、共有される媒体、例えば、ＩＥＥＥ８０２．１１ネットワークであるためである。共有される媒体において、フローは、ホップからホップへのデータの転送中に自らに干渉する可能性があり、さらに他の隣接するフローに干渉する可能性もある。このため、無線メッシュ・ネットワークにおけるパフォーマンスは、高い帯域幅、または短い待ち時間を要求する応用例に関して、２つまたは３つのホップを超えると、しばしば、低下する。
【００２０】
ＵＰＡＣにおいて、コンテンツ・ファイルは、クリップと呼ばれる複数の同一サイズのセグメントに分割される。クリップの開始の再生時刻から時間遅延Ｄを引いたものが、このクリップの期限として定義され、すなわち、クリップに関する期限は、クリップの開始の再生時刻より時間Ｄだけ前になる。Ｄは、ネットワーク伝送遅延および処理遅延と関係するパラメータである。各クリップに関して、クライアント・デバイスは、異なるメッシュ・コンテンツ・サーバ、および異なるピアを有することが可能である。クライアントは、各クリップを独立したファイルとして扱い、さらにクリップを、期限より前に元の順序で獲得する。大きいファイルをクリップに分割することによって、クライアント・デバイスは、動的なネットワーク条件およびピア・トポロジによりうまく適応することができる。異なるメッシュ・コンテンツ・サーバは、異なるコンテンツ、または同一のコンテンツの異なるクリップをキャッシュすることが可能である。各クリップに関して、クライアント・デバイスは、メイン・コンテンツ・サーバを介して集中スキームにおいて、または分散された仕方で、メッシュ・コンテンツ・サーバを発見する。次に、一次メッシュ・コンテンツ・サーバおよび二次メッシュ・コンテンツ・サーバが、選択される。
【００２１】
本発明のＵＰＡＣにおいて、トラッカー・モジュール（図示せず）も、存在する。Ｐ２Ｐトラッカー・モジュールは、ＭＡＰ、またはメッシュ・コンテンツ・サーバ、または完全に別個のデバイスであることが可能である。Ｐ２Ｐトラッカー・モジュールは、Ｐ２Ｐネットワーク・ディレクトリの集中ソースであり、さらにいずれのデバイスがいずれのコンテンツを有するかなどのディレクトリ情報を提供する。クライアント・デバイスは、Ｐ２Ｐフェッチが活性化されている場合、Ｐ２Ｐトラッカー・モジュールに要求を発行する。Ｐ２Ｐトラッカー・モジュールは、システム内のピア／ユーザのステータスを保持する。メッシュ・コンテンツ・サーバは、Ｐ２Ｐプロトコルを実行して、ピアの役割をすることもできることに留意されたい。Ｐ２Ｐトラッカー・モジュールは、クライアント・デバイスが要求しているのと同一のコンテンツを提供することができるピア／ユーザのセットについてクライアント・デバイスに知らせるフィードバック・メッセージを、クライアント・デバイスに送信する。次に、クライアント・デバイスは、選択されたピアとピア関係をセットアップして、データ／コンテンツをフェッチし、さらにデータ／コンテンツを自らに供給し、他のピアにも供給する。
【００２２】
各ピアが有することが可能なコンテンツ、ネットワーク・リソースおよび処理リソース、ならびに動的性質が限られているため、クライアント・デバイスが、他のピアからデータを時間内に得ることができるという保証は、全く存在しない。クライアント・デバイスは、１つまたは複数のメッシュ・コンテンツ・サーバからストリーミングされる最初のＮ個のコンテンツ・クリップ（Ｎ≧１）を要求して、クライアント・デバイスが所望するコンテンツ／データが利用可能であり、さらに起動遅延が最小限に抑えられることを確実にすることができる。クライアント・デバイスは、第１のクリップ（クリップｉ＝１）を、クライアント・デバイスの第１のクリップの指定された／選択された一次メッシュ・コンテンツ・サーバに要求する。一次メッシュ・コンテンツ・サーバが利用できなくなった場合、クライアント・デバイスは、クライアント・デバイスの指定された／選択された二次メッシュ・コンテンツ・サーバに第１のクリップを即時に要求する。次に、クライアント・デバイスは、第２のクリップ（クリップｉ＝２）を、クライアント・デバイスの第２のクリップの一次（あるいは一次が、利用できない、または不能である場合、二次）メッシュ・コンテンツ・サーバに要求する。このプロセスは、クリップｉ（ｉ＝Ｎ）が、クリップｉの一次（または二次）メッシュ・コンテンツ・サーバから受信されるまで続けられる。
【００２３】
その一方で、クライアント・デバイスは、他のコンテンツ・クリップ（ｉ＞Ｎ）を、クライアント・デバイスのピアに要求して、フェッチし、ピア・リソースを可能な限り多く使用しようと試みる。ＵＰＡＣにおける各クリップのＰ２Ｐデータ・フェッチに関して、クリップは、より小さいチャンク、つまり、サブクリップにさらに分割される。これらの小さいチャンクは、ピアの間で交換される（フェッチされる、または供給される）。クリップ内で、１つの例示的な配布ポリシーは、最も稀なデータ・チャンクが、ピアから最初にフェッチされることである。また、Ｐ２Ｐデータ・フェッチに関する他の配布ポリシーが使用されることも可能である。
【００２４】
クリップにおけるコンテンツ／データが、再生期限より前にピアからフェッチされ得ない場合、クライアント・デバイスは、クライアント・デバイスの一次メッシュ・コンテンツ・サーバから直接に、欠落しているデータを要求する。さらに、一次メッシュ・コンテンツ・サーバが利用できなくなった場合、クライアントは、クライアントの二次メッシュ・コンテンツ・サーバから、欠落しているデータを即時に要求する。一次メッシュ・コンテンツ・サーバ、または二次メッシュ・コンテンツ・サーバは、欠落しているコンテンツ／データを、コンテンツ／データの元の順序でクライアント・デバイスにストリーミングする。
【００２５】
一般に、メッシュ・コンテンツ・サーバは、３つの主要なタスクを有する。第１に、メッシュ・コンテンツ・サーバは、要求されたコンテンツの最初のＮ個のクリップを、要求側のクライアント・デバイスにストリーミングすることを担う。第２に、メッシュ・コンテンツ・サーバは、クリップの再生期限より前に、欠落しているデータに関する補完的ストリーミングをもたらす。第３に、メッシュ・コンテンツ・サーバは、コンテンツ／データに関するＰ２Ｐシードの役割をする。クライアント・デバイスが、コンテンツを要求する際、クライアント・デバイスは、ピアに至る経路を確立して、所望されるコンテンツを探し出すためにいくらかの時間を要する。リアルタイム・アプリケーションにおいて、長い起動遅延は、望ましくない。さらに、他のピアが、要求されるコンテンツ／データを有するという保証は全く存在せず、したがって、選択されたメッシュ・コンテンツ・サーバが、起動遅延を短くするように、コンテンツ／データの最初のＮ個のクリップを送信する。コンテンツの各クリップは、そのクリップの再生時間より前にフェッチされなければならない。クリップの再生期限に達すると、新たにダウンロードされたデータが期限切れである可能性があり、再生クリップのＰ２Ｐフェッチは、全く許可されない。補完的ストリーミングが、より少ない待ち時間で、コンテンツ／データを、コンテンツ／データの元の順序で提供するため、メッシュ・コンテンツ・サーバからの補完的ストリーミングが開始される。補完的ストリーミングは、クライアント・デバイスが、他のピアから時間内にフェッチされ得ないデータを得ることを補助する。
【００２６】
Ｐ２Ｐトラッカー・モジュールが、Ｐ２Ｐデータ・フェッチのために使用される。コンテンツ／コンテンツ・クリップに関するＰ２Ｐトラッカー・モジュールは、クライアント・デバイスによって前もって知られている。ピアのそれぞれは、Ｐ２Ｐトラッカー・モジュールに対して、そのピアのステータスを定期的に更新して、Ｐ２Ｐトラッカー・モジュールが、コンテンツ／コンテンツ・クリップに関してＰ２Ｐネットワーク内のピアに関する最も新しい／最新の情報を有するようにする。クライアント・デバイスが、コンテンツ／データ／クリップを要求すると、クライアント・デバイスはまず、Ｐ２Ｐトラッカー・モジュールと通信し、クライアント・デバイスが必要とする／所望するコンテンツをクライアント・デバイスが得るための源であるピアに関してＰ２Ｐトラッカー・モジュールに問い合わせる。次に、クライアント・デバイスは、Ｐ２Ｐトラッカー・モジュールによって供給されたリスト上のピアとＰ２Ｐ関係を確立する（または確立しようと試みる）。クライアント・デバイスは、ＭＡＰの１つに関連付けられるに過ぎず、インフラストラクチャＷＭＮ内のルーティングに関与しないことに留意されたい。クライアント・デバイスは、クライアント・デバイスが関連付けられたＭＡＰを介してピアにピア要求パケットを送信する。ＭＡＰが、ＭＡＰが関連付けられたクライアント・デバイスからピア要求パケット（または別のピアを宛先とする任意のパケット）を受信すると、ＭＡＰは、オンデマンドのまたは事前対応のルーティング・プロトコルおよびルーティング・メトリックを使用して、そのピア要求パケットの中の宛先アドレスに基づいて、クライアント・デバイスに代行して、そのピアに至る最良経路を発見し、確立し、維持する。
【００２７】
Ｐ２Ｐデータ・フェッチ・パフォーマンスを向上させるクロスレイヤ設計を円滑にするために、本発明のＵＰＡＣは、各ＭＡＰにおいてプロキシを実施する。ＭＡＰは、クライアント・デバイスのピアに至るパスコスト、およびそのピアが、要求側のクライアント・デバイスと同一のＭＡＰに関連付けられているかどうかについて、関連付けられたクライアント・デバイスに知らせる。したがって、クライアント・デバイスは、クライアント・デバイスがコンテンツを交換する目的で通信を確立することを所望する相手のピアのそれぞれに至るパスコスト情報を有する。クライアント・デバイスが、クライアント・デバイスと関連付けられたピアからデータをフェッチする際、クライアント・デバイスは、同一のＭＡＰに、またはより良好なパスコストに関連付けられているピアに、より高い優先順位を与える。
【００２８】
メッシュ・コンテンツ・サーバは、インフラストラクチャＷＭＮにおいてネットワーク容量を増加させ、さらにコンテンツ（オーディオ、ビデオ、および／またはマルチメディア）サービスに関するＱｏＳを向上させることに重要な役割を果たす。本発明において、以下のとおり、メッシュ・コンテンツ・サーバ発見およびメッシュ・コンテンツ・サーバ選択のためのいくつかのスキームが、存在する。
（１）サーバ負荷を選択メトリックとして使用する集中スキーム（集中負荷スキーム）。このスキームにおいて、クライアント・デバイスが、メイン・サーバに要求を送信する。メイン・サーバは、このクライアント・デバイスにサービスを提供すべき一次メッシュ・コンテンツ・サーバおよび二次メッシュ・コンテンツ・サーバを選択する。メイン・サーバは、選択されたメッシュ・コンテンツ・サーバについてクライアント・デバイスに知らせる。負荷の最も小さい、またはサービスを提供しているクライアント・デバイスの数が最も少ない２つのメッシュ・コンテンツ・サーバが、一次メッシュ・コンテンツ・サーバおよび二次メッシュ・コンテンツ・サーバとして、このクライアント・デバイスのために、それぞれ選択される。この機構は、クライアント・デバイスが、サーバ負荷、およびサーバに至るパス品質についての情報を有することは要求しない。しかし、この機構は、メッシュ・コンテンツ・サーバが、メッシュ・コンテンツ・サーバの負荷をメイン・サーバに定期的に報告することを要求する。
（２）終端間遅延を選択メトリックとして使用するオーバーレイ・スキーム（オーバーレイ遅延スキーム）。このスキームにおいて、メイン・サーバは、メイン・サーバがクライアント・デバイスから要求を受信した後、候補メッシュ・コンテンツ・サーバのリストをクライアント・デバイスに送信する。クライアント・デバイスは、プロービングパケットを使用して、各候補メッシュ・コンテンツ・サーバに至る終端間遅延を測定する。クライアント・デバイスは、最小遅延を有するメッシュ・コンテンツ・サーバを一次メッシュ・コンテンツ・サーバとして選択し、２番目に小さい終端間遅延を有するメッシュ・コンテンツ・サーバを二次メッシュ・コンテンツ・サーバとして選択する。
（３）ホップ・カウントを選択メトリックとして使用する分散スキーム（分散ＨｏｐＣｏｕｎｔスキーム）。このスキームにおいて、クライアント・デバイスは、コンテンツ・クリップを求めるメッシュ・コンテンツ・サーバ要求メッセージで無線メッシュ・ネットワークを溢れさせる。要求されたコンテンツ・クリップを有する各メッシュ・コンテンツ・サーバは、要求側のクライアント・デバイスにサーバ応答を送信する。クライアント・デバイスは、ＭＡＰに関連付けられ、ルーティングには関与しないことに留意されたい。しかし、基礎をなすルーティング・プロトコルを介して、メッシュ・コンテンツ・サーバは、メッシュ・コンテンツ・サーバから、要求側のクライアント・デバイスが関連付けられたＭＡＰに至るホップ・カウントを有する。メッシュ・コンテンツ・サーバと、クライアント・デバイスが関連付けられたＭＡＰとの間で利用可能な複数のパスが存在することも可能である。最小ホップ・カウントを有するパスだけが、ルーティング機構によって選択されて、使用される。各メッシュ・コンテンツ・サーバは、そのメッシュ・コンテンツ・サーバのルーティング層情報を使用し、クライアント・デバイスが関連付けられたＭＡＰに至るメッシュ・コンテンツ・サーバの最小ホップ・カウントを、サーバ応答の中でクライアント・デバイスに知らせる。クライアント・デバイスは、最小ホップ・カウントの最小値を有するメッシュ・コンテンツ・サーバを一次メッシュ・コンテンツ・サーバとして選択し、２番目に小さいホップ・カウントを有するメッシュ・コンテンツ・サーバを二次メッシュ・コンテンツ・サーバとして選択する。
（４）ルーティング・メトリックを選択メトリックとして使用する分散スキーム（分散ルーティング・メトリック・スキーム）。無線メッシュ・ネットワークは、ルーティング・メトリックを有するルーティング・プロトコルを実行することができる。例えば、予期される伝送時間（ＥＴＴ）が、１つのそのようなメッシュ・ルーティング・メトリックである。リンクＬに関するＥＴＴは、そのリンクを介してパケットを配信することに成功することに関する、予期されるＭＡＣ層持続時間として定義される。ＥＴＴＬ＝（１／１‐ｅＬ）＊ｓ／ｒＬであり、ただし、ｅＬは、パケット誤り率であり、ｒＬは、リンクＬの伝送レートであり、ｓは、パケット・サイズである。パスｐのコストは、単に、パス上のすべてのリンクのＥＴＴの合計である。ＥＴＴメトリックは、パスのパフォーマンスに対するパケットロスおよびリンク・データレートの影響を捕捉する。最小パスＥＴＴコストを有するパスが、ルーティング・プロトコルによって使用される。本発明の分散ＥＴＴメッシュ・サーバ選択スキームでは、メッシュ・サーバ選択のためにクロスレイヤ・アプローチが使用される。分散ＨｏｐＣｏｕｎｔスキームと同様に、クライアント・デバイスは、無線メッシュ・ネットワークにメッシュ・サーバ要求メッセージを溢れさせる。基礎をなすルーティング・プロトコルを介して、メッシュ・コンテンツ・サーバは、メッシュ・コンテンツ・サーバから、クライアント・デバイスが関連付けられたＭＡＰに至る最良のパスのパスＥＴＴコストを得る。最良のパスは、最小ＥＴＴパスコストを有するパスである。各メッシュ・コンテンツ・サーバは、そのメッシュ・コンテンツ・サーバのルーティング層情報を使用し、クライアント・デバイスが関連付けられたＭＡＰに至るメッシュ・コンテンツ・サーバの最良のパスのＥＴＴコストについて、メッシュ・サーバ応答の中でクライアント・デバイスに知らせる。次に、クライアント・デバイスは、パスＥＴＴコストの最小値を有するメッシュ・コンテンツ・サーバを一次メッシュ・コンテンツ・サーバとして選択し、２番目に小さいパスＥＴＴコストを有するメッシュ・コンテンツ・サーバを二次メッシュ・コンテンツ・サーバとして選択する。
【００２９】
図２は、クライアント・デバイス側からのＵＰＡＣ（統一されたＰ２Ｐ（ピア・ツー・ピア）−キャッシュ・サーバ）コンテンツ・サービス・プロセスの流れ図である。ステップ２０５で、クライアント・デバイスが、ストリーミングされる必要があるクリップの数、Ｎを推定する。次に、ステップ２１０で、クライアント・デバイスは、受信する最初のＮ個のクリップがある１つまたは複数のメッシュ・コンテンツ・サーバを発見して、選択する。ステップ２１５で、クライアント・デバイスは、選択されたメッシュ・コンテンツ・サーバからの最初のＮ個のクリップを要求する。ステップ２２０で、クライアント・デバイスは、選択されたメッシュ・コンテンツ・サーバから、要求されるＮ個のクリップを受信する。各クリップは、このプロセスがＮ回、繰り返されることが可能であるように、独立のファイルとして扱われる。ステップ２２５で、クリップ・カウンタが、Ｎより１つ大きい値に初期設定される。ステップ２３０で、コンテンツに関するすべてのクリップが受信されているかどうかを判定する試験が実行される。コンテンツに関するすべてのクリップが受信されている場合、プロセスは終了する。コンテンツに関するすべてのクリップが受信されてはいない場合、ステップ２３５で、次のクリップに関するメッシュ・コンテンツ・サーバが、探し出されて、選択される。ステップ２４０で、クライアント・デバイスは、次にクリップを有するピア・デバイスを探し出そうと試みる。ステップ２４５で、クライアント・デバイスは、次のクリップをダウンロードするために、Ｐ２Ｐネットワークに加わる（クライアント・デバイスが、既にＰ２Ｐネットワークのメンバではない場合）。ステップ２５０で、次のクリップを受信すべき時間が、期限を超えているかどうかを判定する試験が、実行される。期限を超えていない場合、ステップ２５５で、コンテンツ・クリップは、引き続きダウンロードされる。次に、ステップ２６０で、クリップ・ダウンロードが完了したかどうかを判定する試験が実行される。クリップ・ダウンロードが完了していない場合、プロセスは、ステップ２５０に戻る。クリップ・ダウンロードが完了している場合、ステップ２７５で、クリップ・カウンタがインクリメントされる。クリップ・ダウンロードに関する期限を超えている場合、ステップ２６５で、クリップ・ダウンロードから欠落しているデータ／コンテンツが存在するかどうかを判定する試験が実行される。欠落しているデータ／コンテンツが存在する場合、ステップ２７０で、クライアント・デバイスは、その欠落しているデータ／コンテンツをメッシュ・コンテンツ・サーバに要求する。欠落しているデータ／コンテンツが存在しない場合、ステップ２７５で、クリップ・カウンタがインクリメントされる。以上の例示的な実施形態は、アップカウンタを使用するが、デクリメントされるダウンカウンタなどの、他のカウンタが使用されることも可能であることに留意されたい。
【００３０】
図３は、本発明の集中メッシュ・コンテンツ・サーバ選択方法の流れ図である。集中メッシュ・コンテンツ・サーバ選択スキームは、メッシュ・コンテンツ・サーバを発見するいくつかの可能な方法の１つである。クライアント・デバイスによって使用されるスキームは、ネットワーク・トポロジ、メイン・サーバの利用可能性、メトリック情報の利用可能性などに依存する。ステップ３０５で、集中スキームにおいて、クライアント・デバイスが、一次メッシュ・コンテンツ・サーバおよび二次メッシュ・コンテンツ・サーバを割り当てる／指定するようメイン・サーバに要求する要求をメイン・サーバに送信する。メイン・サーバは、ネットワークにおける利用可能なメッシュ・コンテンツ・サーバの負荷に基づいて、一次メッシュ・コンテンツ・サーバおよび二次メッシュ・コンテンツ・サーバを割り当てる／指定する。クライアント・デバイスは、ステップ３１０で、この割り当てられた／指定されたメッシュ・コンテンツ・サーバをメイン・サーバから受信し、ステップ３１５で、この割り当てられた／指定されたメッシュ・コンテンツ・サーバと接続を確立しようと試みる。
【００３１】
図４は、終端間遅延を選択基準として使用する本発明のオーバーレイ・メッシュ・コンテンツ・サーバ選択方法の流れ図である。オーバーレイ・メッシュ・コンテンツ・サーバ選択スキームは、メッシュ・コンテンツ・サーバを発見するいくつかの可能な方法の１つである。クライアント・デバイスによって使用されるスキームは、ネットワーク・トポロジ、メイン・サーバの利用可能性、メトリック情報の利用可能性などに依存する。ステップ４０５で、オーバーレイ・スキームにおいて、クライアント・デバイスが、候補メッシュ・コンテンツ・サーバのリストに関する情報を提供するようメイン・サーバに要求する要求をメイン・サーバに送信する。ステップ４１０で、クライアント・デバイスは、メイン・サーバから、要求される情報を受信する。ステップ４１５で、クライアント・デバイスは、各候補メッシュ・コンテンツ・サーバに至る終端間遅延を算出する。次にステップ４２０で、クライアント・デバイスは、最小の終端間遅延に基づいて、一次メッシュ・コンテンツ・サーバを選択する。ステップ４２５で、クライアント・デバイスは、２番目に小さい終端間遅延に基づいて、二次メッシュ・コンテンツ・サーバを選択する。ステップ４３０で、クライアント・デバイスは、選択されたメッシュ・コンテンツ・サーバと接続を確立しようと試みる。
【００３２】
図５は、ホップ・カウントを選択基準として使用する本発明の分散メッシュ・コンテンツ・サーバ選択方法の流れ図である。ホップ・カウントを選択基準として使用する本発明の分散メッシュ・コンテンツ・サーバ選択方法は、メッシュ・コンテンツ・サーバを発見するいくつかの可能な方法の１つである。クライアント・デバイスによって使用されるこのスキームは、ネットワーク・トポロジ、メイン・サーバの利用可能性、メトリック情報の利用可能性などに依存する。ステップ５０５で、クライアント・デバイスは、無線メッシュ・ネットワークにわたってメッシュ・サーバ要求メッセージを同時送信する。このメッシュ・サーバ要求メッセージは、ホップ・カウント、コンテンツ利用可能性などを含む、無線メッシュ・ネットワーク内にあるメッシュ・コンテンツ・サーバについての情報を収集するために使用される。ステップ５１０で、クライアント・デバイスは、無線メッシュ・ネットワーク内の複数のメッシュ・コンテンツ・サーバから応答を受信する。ステップ５１５で、クライアント・デバイスは、メッシュ・コンテンツ・サーバが最小ホップ・カウントを有することに基づいて、一次メッシュ・コンテンツ・サーバを選択する。ステップ５２０で、クライアント・デバイスは、２番目に小さいホップ・カウントに基づいて、二次メッシュ・コンテンツ・サーバを選択する。ステップ５２５で、クライアント・デバイスは、選択されたメッシュ・コンテンツ・サーバと接続を確立しようと試みる。
【００３３】
図６は、ルーティング・メトリックを選択基準として使用する本発明の分散メッシュ・コンテンツ・サーバ選択方法の流れ図である。ルーティング・メトリックを選択基準として使用する本発明の分散メッシュ・コンテンツ・サーバ選択方法は、メッシュ・コンテンツ・サーバを発見するいくつかの可能な方法の１つである。クライアント・デバイスによって使用されるこのスキームは、ネットワーク・トポロジ、メイン・サーバの利用可能性、メトリック情報の利用可能性などに依存する。ステップ６０５で、クライアント・デバイスは、無線メッシュ・ネットワークにわたってメッシュ・サーバ要求メッセージを同時送信する。このメッシュ・サーバ要求メッセージは、ルーティング・メトリック、コンテンツ利用可能性などを含む、無線メッシュ・ネットワーク内にあるメッシュ・コンテンツ・サーバについての情報を収集するために使用される。ステップ６１０で、クライアント・デバイスは、無線メッシュ・ネットワーク内の複数のメッシュ・コンテンツ・サーバから応答を受信する。次にステップ６１５で、クライアント・デバイスは、メッシュ・コンテンツ・サーバが最良の経路を有することに基づいて、一次メッシュ・コンテンツ・サーバを選択する。ステップ６２０で、クライアント・デバイスは、次善の経路に基づいて、二次メッシュ・コンテンツ・サーバを選択する。ステップ６２５で、クライアント・デバイスは、選択されたメッシュ・コンテンツ・サーバと接続を確立しようと試みる。
【００３４】
前述したとおり、クライアント・デバイスは、動的なネットワーク条件に適応するように、コンテンツの各クリップを別個のファイルとして扱う。クライアント・デバイスは、各クリップに関する一次メッシュ・コンテンツ・サーバと二次メッシュ・コンテンツ・サーバを独立に発見し、選択する。各コンテンツ・クリップを供給している時間中、一次メッシュ・コンテンツ・サーバが利用できなくなった場合、クライアント・デバイスは、二次メッシュ・コンテンツ・サーバに切り換えて、コンテンツを獲得する。その一方で、クライアント・デバイスは、新たな二次メッシュ・コンテンツ・サーバを識別するよう、前述のスキームの１つを使用するサーバ発見−選択プロセスを再び開始する。
【００３５】
図７は、本発明のメッシュ・コンテンツ・サーバのブロック図である。メッシュ・コンテンツ・サーバは、キャッシュ、ストリーミング・サービス・モジュール、Ｐ２Ｐサービス・モジュール、および１つまたは複数の無線通信インタフェースを含む。１つの無線通信インタフェースは、クライアント・デバイスにネットワーク・アクセスを提供する。別の無線通信インタフェースは、他のメッシュ・コンテンツ・サーバ、ＭＡＰ、またはルータと一緒に無線メッシュ・バックホール・ネットワークに関与するために使用される。無線メッシュ・バックホール・ネットワークは、ルーティングおよびデータ転送を可能にする。コンテンツは、キャッシュ・ユニットの中にキャッシュされる。ストリーミング・サービス・モジュールは、クライアント・デバイスから要求を受信し、クライアント・デバイスにコンテンツをストリーミングする。Ｐ２Ｐサービス・モジュールは、他のメッシュ・コンテンツ・サーバおよびクライアント・デバイスと一緒にＰ２Ｐネットワーク化されたシステムを形成する。
【００３６】
図８は、本発明のクライアント・デバイスである。クライアント・デバイスは、Ｐ２Ｐサービス・モジュール、ストリーミング・クライアント・モジュール、バッファ、プレーヤ、および１つまたは複数のワイヤレス（無線）インタフェースを含む。クライアント・デバイスは、クライアント・デバイスの無線インタフェースを介してＭＡＰまたはメッシュ・コンテンツ・サーバに関連付けられる。Ｐ２Ｐサービス・モジュールは、データをフェッチする／提供するために、ピアの役割をする他のクライアント・デバイスおよびメッシュ・コンテンツ・サーバと一緒にＰ２Ｐネットワーク化されたシステムを形成する。ストリーミング・クライアント・モジュールは、メッシュ・コンテンツ・サーバから、ストリーミングされたデータを要求し、受信する。受信されたデータは、バッファの中に格納される。バッファの中のデータは、プレーヤによって表示され、さらにＰ２Ｐシステム内の他のピアによってフェッチされることが可能である。クライアント・デバイス（例えば、ラップトップ、デュアル・モード・スマートフォン、携帯情報端末器（ＰＤＡ）など）は、無線メッシュ・ネットワークにアクセスするために近辺のＭＡＰに関連付けられる。クライアント・デバイス／エンド・デバイスは、パケット中継プロセスまたはルーティング・プロセスには関与しない。クライアント・デバイスは、クライアント・デバイスが関連付けられたＭＡＰに（またはそのようなＭＡＰから）パケットを送信（または受信）する。パケット配信は、バックホール・ルーティング・プロトコルを介してＭＡＰによって扱われる。
【００３７】
本発明は、様々な形態のハードウェア、ソフトウェア、ファームウェア、専用プロセッサ、または以上の組み合わせにおいて実施されることが可能であることを理解されたい。好ましくは、本発明は、ハードウェアとソフトウェアの組み合わせとして実施される。さらに、ソフトウェアは、好ましくは、プログラム格納デバイス上に実体化されたアプリケーション・プログラムとして実施される。アプリケーション・プログラムは、任意の適切なアーキテクチャを含むマシンにアップロードされて、このマシンによって実行されることが可能である。好ましくは、マシンは、１つまたは複数の中央処理装置（ＣＰＵ）、ランダム・アクセス・メモリ（ＲＡＭ）、および入出力（Ｉ／Ｏ）インタフェースなどのハードウェアを有するコンピュータ・プラットフォーム上で実施される。また、このコンピュータ・プラットフォームは、オペレーティング・システムおよびマイクロ命令コードも含む。本明細書で説明される様々なプロセスおよび機能は、オペレーティング・システムを介して実行される、マイクロ命令コードの一部、またはアプリケーション・プログラムの一部（あるいは以上の組み合わせ）であることが可能である。さらに、追加のデータ格納デバイスや印刷デバイスなどの他の様々な周辺デバイスが、このコンピュータ・プラットフォームに接続されることも可能である。
【００３８】
添付の図に示される構成システム構成要素および方法ステップのいくつかは、好ましくは、ソフトウェアで実施されるため、システム構成要素（またはプロセス・ステップ）間の実際の接続は、本発明がプログラミングされる仕方に依存して、異なることが可能であることをさらに理解されたい。本明細書の教示を所与として、関連分野の業者は、本発明の以上の、または類似した実施形態または構成を企図することができる。
【符号の説明】
【００３９】
１０５  インターネット
１１０  ゲートウェイ・メッシュ・コンテンツ・サーバ
１１５ａ、１１５ｂ、１１５ｃ、１２０ａ、１２５ａ、１２５ｂ、１２５ｃ、１２５ｄ  メッシュ・アクセス・ポイント
１３０  クライアント・デバイス／エンド・デバイス
【図１】
2010538529.tif 000003
【図２】
2010538529.tif 000004
【図３】
2010538529.tif 000005
【図４】
2010538529.tif 000006
【図５】
2010538529.tif 000007
【図６】
2010538529.tif 000008
【図７】
2010538529.tif 000009
【図８】
2010538529.tif 000010
【手続補正書】
【提出日】平成22年7月30日(2010.7.30)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンテンツ・クリップを受信するためにストリーミング元の第１のサーバを決定するステップと、
ストリーミングされる前記コンテンツ・クリップを、前記選択された第１のサーバに要求するステップと、
前記ストリーミングされるコンテンツ・クリップを、前記選択された第１のサーバから受信するステップと、
コンテンツ・クリップを受信するためにダウンロード元のピア・デバイスを決定するステップと、
ダウンロードされる前記コンテンツ・クリップを要求するステップと、
前記ダウンロードされるコンテンツ・クリップを受信するステップと、
を含む、方法。
【請求項２】
前記第１のサーバは、メッシュ・コンテンツ・サーバである請求項１に記載の方法。
【請求項３】
前記ピア・デバイスに関する情報を獲得するステップと、
前記ピア・デバイスを含むピア・ツー・ピア・ネットワークに加わるステップと、
をさらに含む、請求項１に記載の方法。
【請求項４】
前記ダウンロードされるコンテンツ・クリップが、期限より前に受信されたかどうかを判定するステップと、
前記期限より前に受信されなかった前記ダウンロードされるコンテンツ・クリップの欠落している部分のストリーミングを、前記メッシュ・コンテンツ・サーバに要求するステップと、
をさらに含む、請求項２に記載の方法。
【請求項５】
前記メッシュ・コンテンツ・サーバは、コンテンツ格納能力およびコンテンツ処理能力を有するメッシュ・アクセス・ポイントである、請求項２に記載の方法。
【請求項６】
前記メッシュ・コンテンツ・サーバは、メッシュ・アクセス・ポイントと並置される、請求項２に記載の方法。
【請求項７】
ストリーミングされるコンテンツ・クリップの数を計算するステップをさらに含む、請求項２に記載の方法。
【請求項８】
ストリーミングされる各コンテンツ・クリップに関する前記メッシュ・コンテンツ・サーバが異なる、請求項７に記載の方法。
【請求項９】
ストリーミングされるいくつかのコンテンツ・クリップに関する前記メッシュ・コンテンツ・サーバが異なる、請求項７に記載の方法。
【請求項１０】
前記ストリーミングされるコンテンツ・クリップの中の受信されるパケットは、順序どおりに受信される、請求項１に記載の方法。
【請求項１１】
前記ダウンロードされるコンテンツ・クリップの中の受信されるパケットは、順序が乱れて受信される、請求項１に記載の方法。
【請求項１２】
前記ダウンロードされる順序が乱れたコンテンツ・クリップの中の前記受信されるパケットは、バッファリングされる、請求項１１に記載の方法。
【請求項１３】
前記メッシュ・コンテンツ・サーバを決定する前記ステップは、
第２のサーバに要求メッセージを送信するステップと、
前記第２のサーバから、一次メッシュ・コンテンツ・サーバおよび二次メッシュ・コンテンツ・サーバについての情報を受信するステップと、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するステップと、
をさらに含む、請求項２に記載の方法。
【請求項１４】
前記第２のサーバは、メイン・サーバである、請求項１３に記載の方法。
【請求項１５】
前記メッシュ・コンテンツ・サーバを決定する前記ステップは、
第２のサーバに要求メッセージを送信するステップと、
前記第２のサーバから、候補メッシュ・コンテンツ・サーバのリストについての情報を受信するステップと、
各候補メッシュ・コンテンツ・サーバに至る終端間遅延を算出するステップと、
最小の終端間遅延に基づいて、一次メッシュ・コンテンツ・サーバを選択するステップと、
２番目に小さい終端間遅延に基づいて、二次メッシュ・コンテンツ・サーバを選択するステップと、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するステップと、
をさらに含む、請求項２に記載の方法。
【請求項１６】
前記第２のサーバは、メイン・サーバである、請求項１４に記載の方法。
【請求項１７】
前記メッシュ・コンテンツ・サーバを決定する前記ステップは、
前記無線ネットワークにわたってメッシュ・コンテンツ・サーバ要求メッセージを同時送信するステップと、
複数のメッシュ・コンテンツ・サーバから応答を受信するステップと、
前記要求側と前記応答するメッシュ・コンテンツ・サーバとの間の最低のホップ・カウントに基づいて、一次メッシュ・コンテンツ・サーバを選択するステップと、
前記要求側と前記応答するメッシュ・コンテンツ・サーバとの間の２番目に低いホップ・カウントに基づいて、二次メッシュ・コンテンツ・サーバを選択するステップと、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するステップと、
をさらに含む、請求項２に記載の方法。
【請求項１８】
前記メッシュ・コンテンツ・サーバを決定する前記ステップは、
前記無線ネットワークにわたってメッシュ・コンテンツ・サーバ要求メッセージを同時送信するステップと、
複数のメッシュ・コンテンツ・サーバから応答を受信するステップと、
前記要求側と前記応答するメッシュ・コンテンツ・サーバとの間の最良の経路に基づいて、一次メッシュ・コンテンツ・サーバを選択するステップと、
前記要求側と前記応答するメッシュ・コンテンツ・サーバとの間の次善の経路に基づいて、二次メッシュ・コンテンツ・サーバを選択するステップと、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するステップと、
をさらに含む、請求項２に記載の方法。
【請求項１９】
コンテンツ・クリップを受信するためにストリーミング元の第１のサーバを決定するための手段と、
前記ストリーミングされるコンテンツ・クリップを、前記選択された第１のサーバに要求するための手段と、
前記ストリーミングされるコンテンツ・クリップを、前記選択された第１のサーバから受信するための手段と、
コンテンツ・クリップを受信するためにダウンロード元のピア・デバイスを決定するための手段と、
前記ダウンロードされるコンテンツ・クリップを要求するための手段と、
前記ダウンロードされるコンテンツ・クリップを受信するための手段と、
を備える、デバイス。
【請求項２０】
前記第１のサーバは、メッシュ・コンテンツ・サーバである、請求項１９に記載のデバイス。
【請求項２１】
前記ピア・デバイスに関する情報を獲得するための手段と、
前記ピア・デバイスを含むピア・ツー・ピア・ネットワークに加わるための手段と、
をさらに備える、請求項１９に記載のデバイス。
【請求項２２】
前記ダウンロードされるコンテンツ・クリップが、期限より前に受信されたかどうかを判定するための手段と、
前記期限より前に受信されなかった前記ダウンロードされるコンテンツ・クリップの欠落している部分のストリーミングを、前記メッシュ・コンテンツ・サーバに要求するための手段と、
をさらに備える、請求項２０に記載のデバイス。
【請求項２３】
ストリーミングされるコンテンツ・クリップの数を計算するための手段をさらに備える、請求項２０に記載のデバイス。
【請求項２４】
前記メッシュ・コンテンツ・サーバと前記ピア・デバイスとが同一である、請求項２０に記載のデバイス。
【請求項２５】
ストリーミングされる各コンテンツ・クリップに関する前記メッシュ・コンテンツ・サーバが異なる、請求項２０に記載のデバイス。
【請求項２６】
ストリーミングされるいくつかのコンテンツ・クリップに関する前記メッシュ・コンテンツ・サーバが異なる、請求項２０に記載のデバイス。
【請求項２７】
前記ストリーミングされるコンテンツ・クリップの中の受信されるパケットは、順序どおりに受信される、請求項１９に記載のデバイス。
【請求項２８】
前記ダウンロードされるコンテンツ・クリップの中の受信されるパケットは、順序が乱れて受信される、請求項１９に記載のデバイス。
【請求項２９】
前記ダウンロードされる順序が乱れたコンテンツ・クリップの中の前記受信されるパケットは、バッファリングされる、請求項２８に記載のデバイス。
【請求項３０】
前記メッシュ・コンテンツ・サーバを決定するための前記手段は、
第２のサーバに要求メッセージを送信するための手段と、
前記第２のサーバから、一次メッシュ・コンテンツ・サーバおよび二次メッシュ・コンテンツ・サーバについての情報を受信するための手段と、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するための手段と、
をさらに備える、請求項２０に記載のデバイス。
【請求項３１】
前記第２のサーバは、メイン・サーバである、請求項３０に記載のデバイス。
【請求項３２】
前記メッシュ・コンテンツ・サーバを決定するための前記手段は、
第２のサーバに要求メッセージを送信するための手段と、
前記第２のサーバから、候補メッシュ・コンテンツ・サーバのリストについての情報を受信するための手段と、
各候補メッシュ・コンテンツ・サーバに至る終端間遅延を算出するための手段と、
最小の終端間遅延に基づいて、一次メッシュ・コンテンツ・サーバを選択するための手段と、
２番目に小さい終端間遅延に基づいて、二次メッシュ・コンテンツ・サーバを選択するための手段と、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するための手段と、
をさらに備える、請求項２０に記載のデバイス。
【請求項３３】
前記第２のサーバは、メイン・サーバである、請求項３２に記載のデバイス。
【請求項３４】
前記メッシュ・コンテンツ・サーバを決定するための前記手段は、
前記無線ネットワークにわたってメッシュ・コンテンツ・サーバ要求メッセージを同時送信するための手段と、
複数のメッシュ・コンテンツ・サーバから応答を受信するための手段と、
前記デバイスと前記応答するメッシュ・コンテンツ・サーバとの間の最低のホップ・カウントに基づいて、一次メッシュ・コンテンツ・サーバを選択するための手段と、
前記デバイスと前記応答するメッシュ・コンテンツ・サーバとの間の２番目に低いホップ・カウントに基づいて、二次メッシュ・コンテンツ・サーバを選択するための手段と、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するための手段と、
をさらに備える、請求項２０に記載のデバイス。
【請求項３５】
前記メッシュ・コンテンツ・サーバを決定するための前記手段は、
前記無線ネットワークにわたってメッシュ・コンテンツ・サーバ要求メッセージを同時送信するための手段と、
複数のメッシュ・コンテンツ・サーバから応答を受信するための手段と、
前記デバイスと前記応答するメッシュ・コンテンツ・サーバとの間の最良の経路に基づいて、一次メッシュ・コンテンツ・サーバを選択するための手段と、
前記デバイスと前記応答するメッシュ・コンテンツ・サーバとの間の次善の経路に基づいて、二次メッシュ・コンテンツ・サーバを選択するための手段と、
前記一次メッシュ・コンテンツ・サーバおよび前記二次メッシュ・コンテンツ・サーバと接続を確立するための手段と、
をさらに備える、請求項２０に記載のデバイス。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００２８
【補正方法】変更
【補正の内容】
【００２８】
メッシュ・コンテンツ・サーバは、インフラストラクチャＷＭＮにおいてネットワーク容量を増加させ、さらにコンテンツ（オーディオ、ビデオ、および／またはマルチメディア）サービスに関するＱｏＳを向上させることに重要な役割を果たす。本発明において、以下のとおり、メッシュ・コンテンツ・サーバ発見およびメッシュ・コンテンツ・サーバ選択のためのいくつかのスキームが、存在する。
（１）サーバ負荷を選択メトリックとして使用する集中スキーム（集中負荷スキーム）。このスキームにおいて、クライアント・デバイスが、メイン・サーバに要求を送信する。メイン・サーバは、このクライアント・デバイスにサービスを提供すべき一次メッシュ・コンテンツ・サーバおよび二次メッシュ・コンテンツ・サーバを選択する。メイン・サーバは、選択されたメッシュ・コンテンツ・サーバについてクライアント・デバイスに知らせる。負荷の最も小さい、またはサービスを提供しているクライアント・デバイスの数が最も少ない２つのメッシュ・コンテンツ・サーバが、一次メッシュ・コンテンツ・サーバおよび二次メッシュ・コンテンツ・サーバとして、このクライアント・デバイスのために、それぞれ選択される。この機構は、クライアント・デバイスが、サーバ負荷、およびサーバに至るパス品質についての情報を有することは要求しない。しかし、この機構は、メッシュ・コンテンツ・サーバが、メッシュ・コンテンツ・サーバの負荷をメイン・サーバに定期的に報告することを要求する。
（２）終端間遅延を選択メトリックとして使用するオーバーレイ・スキーム（オーバーレイ遅延スキーム）。このスキームにおいて、メイン・サーバは、メイン・サーバがクライアント・デバイスから要求を受信した後、候補メッシュ・コンテンツ・サーバのリストをクライアント・デバイスに送信する。クライアント・デバイスは、プロービングパケットを使用して、各候補メッシュ・コンテンツ・サーバに至る終端間遅延を測定する。クライアント・デバイスは、最小遅延を有するメッシュ・コンテンツ・サーバを一次メッシュ・コンテンツ・サーバとして選択し、２番目に小さい終端間遅延を有するメッシュ・コンテンツ・サーバを二次メッシュ・コンテンツ・サーバとして選択する。
（３）ホップ・カウントを選択メトリックとして使用する分散スキーム（分散ＨｏｐＣｏｕｎｔスキーム）。このスキームにおいて、クライアント・デバイスは、コンテンツ・クリップを求めるメッシュ・コンテンツ・サーバ要求メッセージで無線メッシュ・ネットワークを溢れさせる。要求されたコンテンツ・クリップを有する各メッシュ・コンテンツ・サーバは、要求側のクライアント・デバイスにサーバ応答を送信する。クライアント・デバイスは、ＭＡＰに関連付けられ、ルーティングには関与しないことに留意されたい。しかし、基礎をなすルーティング・プロトコルを介して、メッシュ・コンテンツ・サーバは、メッシュ・コンテンツ・サーバから、要求側のクライアント・デバイスが関連付けられたＭＡＰに至るホップ・カウントを有する。メッシュ・コンテンツ・サーバと、クライアント・デバイスが関連付けられたＭＡＰとの間で利用可能な複数のパスが存在することも可能である。最小ホップ・カウントを有するパスだけが、ルーティング機構によって選択されて、使用される。各メッシュ・コンテンツ・サーバは、そのメッシュ・コンテンツ・サーバのルーティング層情報を使用し、クライアント・デバイスが関連付けられたＭＡＰに至るメッシュ・コンテンツ・サーバの最小ホップ・カウントを、サーバ応答の中でクライアント・デバイスに知らせる。クライアント・デバイスは、最小ホップ・カウントの最小値を有するメッシュ・コンテンツ・サーバを一次メッシュ・コンテンツ・サーバとして選択し、２番目に小さいホップ・カウントを有するメッシュ・コンテンツ・サーバを二次メッシュ・コンテンツ・サーバとして選択する。
（４）ルーティング・メトリックを選択メトリックとして使用する分散スキーム（分散ルーティング・メトリック・スキーム）。無線メッシュ・ネットワークは、ルーティング・メトリックを有するルーティング・プロトコルを実行することができる。例えば、予期される伝送時間（ＥＴＴ）が、１つのそのようなメッシュ・ルーティング・メトリックである。リンクＬに関するＥＴＴは、そのリンクを介してパケットを配信することに成功することに関する、予期されるＭＡＣ層持続時間として定義される。ＥＴＴＬ＝（１／（１‐ｅＬ））＊ｓ／ｒＬであり、ただし、ｅＬは、パケット誤り率であり、ｒＬは、リンクＬの伝送レートであり、ｓは、パケット・サイズである。パスｐのコストは、単に、パス上のすべてのリンクのＥＴＴの合計である。ＥＴＴメトリックは、パスのパフォーマンスに対するパケットロスおよびリンク・データレートの影響を捕捉する。最小パスＥＴＴコストを有するパスが、ルーティング・プロトコルによって使用される。本発明の分散ＥＴＴメッシュ・サーバ選択スキームでは、メッシュ・サーバ選択のためにクロスレイヤ・アプローチが使用される。分散ＨｏｐＣｏｕｎｔスキームと同様に、クライアント・デバイスは、無線メッシュ・ネットワークにメッシュ・サーバ要求メッセージを溢れさせる。基礎をなすルーティング・プロトコルを介して、メッシュ・コンテンツ・サーバは、メッシュ・コンテンツ・サーバから、クライアント・デバイスが関連付けられたＭＡＰに至る最良のパスのパスＥＴＴコストを得る。最良のパスは、最小ＥＴＴパスコストを有するパスである。各メッシュ・コンテンツ・サーバは、そのメッシュ・コンテンツ・サーバのルーティング層情報を使用し、クライアント・デバイスが関連付けられたＭＡＰに至るメッシュ・コンテンツ・サーバの最良のパスのＥＴＴコストについて、メッシュ・サーバ応答の中でクライアント・デバイスに知らせる。次に、クライアント・デバイスは、パスＥＴＴコストの最小値を有するメッシュ・コンテンツ・サーバを一次メッシュ・コンテンツ・サーバとして選択し、２番目に小さいパスＥＴＴコストを有するメッシュ・コンテンツ・サーバを二次メッシュ・コンテンツ・サーバとして選択する。
【国際調査報告】
2010538529.tif 000011
2010538529.tif 000012
2010538529.tif 000013