JP2018507660A - デジタルコンテンツのアダプティブ仮想ブロードキャスティングのための方法およびシステム - Google Patents

Abstract

本発明の仮想ブロードキャストシステムは、下層のネットワーク内での構成要素の相互接続における頻繁に変化する輻輳レベルの予想に基づき動的に再構成されるオーバーレイネットワークに沿ったノード間でのデジタルコンテンツのルーティングを最適化する。多数の同時ユーザーに対してインターネットを介してストリーミングビデオを配信する状況で、本発明は、ディープラーニング技術を使用して、これらのＡＳＮピアリングポイントを経由する輻輳レベルを予想し、これらの予想に基づき、動的に再構成されるオーバーレイネットワークに沿ったビデオコンテンツのルーティングを最適化することで、輻輳したＡＳＮピアリングポイントの限られた容量を効率的に使用する。仮想ブロードキャストシステムは、予定されていないならびに予定されたイベントを取り扱い、ライブでならびに事前録画されたイベントをストリーミングし、多数の同時視聴者の間で一貫したＱｏＥを維持する高いスケーラブルを有する態様で、最小の遅延を伴うリアルタイムにこれらのイベントをストリーミングする。【選択図】図１

Description

関連出願の相互参照
この出願は、２０１４年１２月２６日に出願されたシリアル番号６２／０９６,９３８の米国仮出願に基づく優先権を主張し、それの開示内容は、参照によりその全内容が本明細書に完全に記載されているものとして組み入れられる。

本発明は、概して、下層ネットワークのノード間でデジタルコンテンツを伝達するオーバーレイネットワークアーキテクチャに関し、より詳細には、下層ネットワーク内での構成要素の相互接続における、頻繁に変化する輻輳のレベルの予想に基づき動的に再構成されたオーバーレイネットワークに沿ったノード間でのデジタルコンテンツのルーティングを最適化する仮想ブロードキャストシステムに関する。
関連技術の説明
ネットワーク輻輳

有線および無線ネットワークのトラフィックは飛躍的に拡大し続けているため、ネットワーク内の構成要素間の共有リンクあるいは相互接続の有限の容量は、よりますます現実的な課題に直結し、問題を起こしている。さらに、ネットワークのトラフィックの増減に応じて、これらの共有リンクにおける輻輳のレベルは動的となり、大きな変動性を伴うため、かかる輻輳をどのようなときにでも測定することは難しく、短期的であっても予測することは特に難しい。

この問題は、人口が増加している地域における共有道路と高速道路での交差点での交通渋滞の問題にいくらか類似している。既存のＧＰＳナビゲーションや交通制御システムは、これらの交差点における現在の渋滞を測定して、個々の運転手がこのような渋滞を回避するための最適な経路を計算するが、特定の運転手のために事前に最適な経路を予想するそれらの能力は、交通渋滞の動的な性質により阻まれる。

ネットフリックスのような単一の企業がピーク時のインターネットトラフィックの３分の１を占める場合には、インターネットを介してデジタル情報（特に大量のリニアデータ）を同時に配信する企業は、インターネットの輻輳のますます変動する性質になにかしら対応しなければならない。同様に、モバイル音声やデータ使用が増加するにつれて、規制されたＲＦスペクトルの限られた可用性は、高帯域のモバイルアプリケーションを開発する企業にとって特に懸念される。

多数の同時ユーザーに対してインターネットを介してストリーミングビデオを配信する状況において、本発明の特定の応用がここに説明されるが、ネットワークの構成要素間の共有リンクの容量の制限が、デジタルフォーマット（例えば、音声、画像、三次元模型等）に変換されるいかなる形式の情報のルーティングを制約する、他の多くの状況に対して、本発明の原理を等しく適応できる。本発明の他の潜在的な用途には、例えばＶｏＩＰ、企業のビデオ会議、仮想現実、マルチプレーヤーゲーミングおよび様々な他の帯域幅を必要とするアプリケーション（任意の特定の時点で、下層ネットワーク内の共有リンクの輻輳のレベルに関して）が含まれる。

以下でより詳細に説明するように、本発明は、インターネットのような下層ネットワーク内での構成要素のリンクにおける制限された容量あるいは「ネットワーク輻輳」の問題を「治す」のではなく、代わりに、それらのリンク間のネットワークトラフィックを監視して分析することで、制限された容量を効率的に使用し、それらのリンクの輻輳レベルの予想に基づき動的に再構成されたオーバーレイネットワークのノード間でのデジタルコンテンツのルーティングを最適化する。
ビデオストリーミングイベント

インターネットおよびＩＰに基づくルーティングの出現以来、インターネットを介してビデオをストリーミングする多くのアプローチが現れた。相対的な長所および短所を議論する前に、一歩離れて、対処する問題を検討することが有用である。インターネットを介してビデオコンテンツを配信するには、それをキャプチャーしてデジタル化する必要がある。我々は、「ライブ」でキャプチャーされて（あるいは、デジタル的に生成されて）インターネットを介して配信された「イベント」としてビデオコンテンツを特徴付けることができる。ここで、ビデオイベントには、ビデオおよび音声の両方ならびに関連するメタデータのキャプチャーおよび生成を含む。

ビデオイベントは予定されていても、予定されていなくてもよい。例えば「スーパーボール」は、それが発生する時間が予め分かっているという点で、予定されたイベントであるのに対して、他のイベント（例えば、自然災害、幼児の第一歩あるいはビデオオンデマンド−「ＶＯＤ」）は、事前の兆候がほとんどあるいは全く無く発生する点で、予定されていない。

他の形式のファイルが（例えば、ＦＴＰあるいはファイル転送プロトコルを介して）転送されたときに、ビデオコンテンツは、インターネットを介して配信される前に、デジタル化されたビデオを生成するために全体としてキャプチャーされてもよい。しかしながら、このような「ファイル転送」アプローチは、受信者のビデオコンテンツの視聴（再生）に遅延を強いる。すなわち、受信者は、ビデオコンテンツの視聴の前に、ファイル全体が転送されるのを待たなければならない。デジタル化されたビデオのファイルサイズが比較的大きい場合には、この遅延は重要な意味を持ちうる。

そのため、ビデオコンテンツはしばしばユーザーに「ストリーミング」され、コンテンツの送信中に、ユーザーはコンテンツを継続的に受信して視聴することができる。基本的に、受信に伴ってそれらの視聴を開始できるユーザーに配信される「ビデオセグメント」（長さが１〜１０秒）あるいは小さいファイルの順序付けられた直線的な流れに、ビデオコンテンツは分割される。遅延あるいはジッターのないビデオコンテンツの連続的なストリーミングを視聴するためには、各ビデオセグメントは、一定間隔、例えば１秒あたり３０フレーム（ｆｐｓ）で再生されなければならない。ただし、先のセグメントの再生が終わる前に各セグメントが受信されるならば、ビデオセグメントが一定間隔で受信される必要はない。

イベントが予定されるか予定されないかにかかわらず、イベント発生後の任意の時間にストリーミングするために、「ライブ」（すなわち、イベント発生時）あるいは「事前録画」でストリーミングできる。例えば、スーパーボールは、イベント発生時にキャプチャーされてライブでストリーミングされ、あるいは後のストリーミングのために事前録画される。

最終的に、イベントが予定されているか予定されていないかにかかわらず、また、事前録画されたか発生時にライブでストリーミングされているかにかかわらず、（送信者から受信者へのほぼ感知できない遅延を伴った）「リアルタイム」で、あるいは数秒または数分もの間「遅れて」ストリーミングすることができる。例えば、リアルタイムではなくインターネットを介してストリーミングされるテレビ番組（例えば、野球ゲーム）の視聴者は、互いに異なる時間、あるいはケーブルまたは衛星を介して放送された同じ番組を観る視聴者と異なる時間に、ストリーミングされたイベントを経験するかもしれない。ネットワーク中心のメトリック（例えば、ルーターや他のネットワーク資源に起因したパケット遅延、パケット損失あるいはジッター）に基づくパフォーマンスの尺度である「サービスの質」（ＱｏＳ）とは対照的な、ユーザーの「経験の質」（ＱｏＥ）、すなわちユーザー中心あるいはアプリケーションレベルの品質観を、かかる遅延（特に数秒以上の場合）は減少させるかもしれない。

例えば、視聴者が同じイベントを異なる時間に経験するという事実のため、（ジッターやビデオアーティファクトは完全に別として）、視聴者間の社会的交流は制限されるかもしれない。ブロードキャストラジオあるいはテレビからソーシャルメディアや他のインターネットサービスに至るまで、携帯電話やデスクトップおよびラップトップコンピューターを介して、ならびに絶えず進化する消費者電子機器の分野を介してアクセス可能であり、非常に多くの異なる方法で、（予定されたあるいは予定されていない）非常に多くのイベントがリアルタイムで通信される今日では、これは特に問題となる。

そのため、一貫したＱｏＥを視聴者に提供するためには、予定されていないおよび予定されたイベントを扱い、ライブあるいは事前録画のイベントをストリーミングし、および最小の遅延でリアルタイムにこれらのイベントをストリーミングすることが、ビデオストリーミングシステムにとっては望ましい。さらに、ストリーミングビデオイベントの同時視聴者の数が増大すると、一貫したＱｏＥを維持することは厄介な問題となる。そのため、スケーラビリティは、このようなシステムの重要な設計目標となる。

ビデオストリーミング技術の近年の進歩にもかかわらず、インターネットの基盤のその場その場の歴史的な進化は、いまだにインターネットに基づくビデオストリーミングに重大な障害をもたらし、それらのうち重要なのは、ＱｏＳの非一貫性であり、インターネットにおける時間および場所で、予測困難なネットワーク輻輳をもたらす。本発明の重要な目的は、ストリーミングビデオイベントの視聴者にとって一貫したＱｏＥを維持することであるが、結局のところ排除できないインターネットでのネットワーク輻輳によって、この目的は制約される。
下層インターネットアーキテクチャ

ＡＲＰＡＮＥＴ（インターネットプロトコルスイートあるいはＴＣＰ／ＩＰを実行する最も初期のパケットスイッチングネットワーク）に始まり、より後のＮＳＦＮＥＴでは、インターネットの「バックボーン」は、制御を分散化して所望の目的地に情報を到達させるための代替の通信（ルーティング）経路を提供することで、信頼性あるいは「復元力」を提供する冗長な「ネットワークのネットワーク」（すなわち、インターネット）に設計されている。しかしながら、ルーターおよび他の共有ネットワーク資源の間の異なる経路を進むパケットについて、一貫性のあるＱｏＳあるいはＱｏＥをインターネットにおいて維持することは、極めて難しい問題のままである。

インターネットのバックボーンが進化して民営化されると、伝統的なバックボーンネットワークと長距離電話会社により所有されるそれらの間で、冗長性と重複が生じた。顧客に直接、あるいは他のより小規模な「インターネットサービスプロバイダー」（ＩＳＰ）ネットワークを介してデータを提供する大規模な「パブリック」ネットワークと、それら自身の間でのみデータを通信し、あるいは大規模なＩＳＰの間でのコンジットとして機能し、顧客に直接はデータを提供しない大規模な「プライベート」バックボーンネットワークとを、この明細書の目的のために区別する。いずれの場合でも、これら大規模なパブリックおよびプライベートネットワークは、複数の光ファイバーケーブルを束ねてネットワーク容量を増大させる光ファイバー幹線を介して相互に接続される「ファイバーリング」として一般に実装される。

ルーティングの目的のために、最も重いネットワークトラフィック（例えば、大規模ＩＳＰおよびプライベートバックボーンネットワーク）を伝送する最も大規模なネットワークプロバイダーには、「自律システム」（ＡＳ）として知られているＩＰルーティングプレフィックスのブロックが割り当てられ、それぞれには「自律システム番号」（ＡＳＮ）が割り当てられる。これらの企業が所有する大規模なファイバーリングのそれぞれをＡＳＮと称する。近年ＡＳＮの数は、１５年前の約５０００のＡＳＮから現在の世界中の５０，０００を超えるＡＳＮにまで飛躍的に増加している。上述したように、多くの大規模ネットワークプロバイダーは、顧客へのサービスは行わないもののそれらが所有する「パブリックＡＳＮ」あるいは他が所有するそれに接続されうるバックボーンファイバーリングネットワーク（すなわち、プライベートＡＳＮ）も所有している。

異なる企業がＡＳＮを所有するため、彼らは、ＡＳＮおよびグローバルインターネット全体を通じたインターネットトラフィックのルーティンを容易にするために、互いに契約を結ぶ。各ＡＳＮは、他のＡＳＮのアクセスを制御するために、しばしば「ピアリングポイント」と称される一群のルーターを利用し、ボーダーゲートウェイプロトコルあるいはＢＧＰとして知られるルーティングプロトコルを採用する。任意のＡＳＮは、複数の異なるＡＳＮに接続するために、複数のピアリングポイントを採用する。相互接続されたＡＳＮは地理的に隣接していても遠く離れていてもよく、（例えば、国あるは海を跨いで）長距離に渡る長いファイバー幹を介して接続される。パブリックＡＳＮは、「プライベートＡＳＮ」あるいはバックボーンネットワークを介してもまた接続されてもよい。

ＡＳＮ内およびＡＳＮ間でＱｏＳを監視することは極めて難しい。大規模ネットワークプロバイダーは、自社のＡＳＮ（動的輻輳メトリックを含む）内のルーティングおよびパフォーマンスの情報の多くをプロプライエタリとして保持する。ＴＣＰ／ＩＰのＢＧＰへの接続が確立されると、（現行のＢＰＧバージョン４の）「オープンメッセージフォーマット」は特定の情報の「データダンプ」を提供するが、このメカニズムは現実的な問題としてあまり有用でない。多くのＢＧＰルーターがオープンメッセージフォーマットをサポートしておらず、他は単純にそれを消す。情報は通常５分古く、インターネットにおいて輻輳レベルが変化する頻度を考えると、それは比較的長い時間である。

このような大量のインターネットトラフィックは、ＡＳＮを相互に接続する比較的高帯域幅のピアリングポイントを横断して流れるため、ＡＳＮ内の「ラストマイル」問題（すなわち、エンドユーザーと彼らの「ゲートウェイ」ＩＳＰとの間の比較的低帯域幅の有線および無線の接続における輻輳）とは別に、これらのピアリングポイントは、どんなときにおいても、しばしば重要な「ボトルネック」あるいはインターネットでの輻輳の多くのソースとなる。

例えば、ＡＳＮピアリングポイントを横断するトラフィックロードが増大すると、ピアリングポイントの各側のＡＳＮのルーターが輻輳を起こす。換言すれば、ＲＡＭ、ＣＰＵおよび他の容量の限られた共有資源の高い利用率を経験する。これらの資源に対する要求の増大は、これらのピアリングポイントを横断するパフォーマンス（例えば、ビットレート）を低下させ、結果的にデータパケットの損失を招くかもしれない。インターネット全体でのネットワークトラフィックは集中管理されないので、どんなときにおいても、インターネットで頻繁に変化する「ピアリングポイント輻輳」の程度を予想することは難しい。

ＡＳＮ内あるいは間での一貫性のあるＱｏＳを保証できないと、ストリーミングビデオイベントの視聴者に対して一貫性のあるＱｏＥを維持することは非常に難しくなる。インターネットを介してビデオをストリーミングするシステムは、特に多くのインターネットトラフィックが流れるＡＳＮピアリングポイントにおいて共有ルーターの輻輳の程度が常に変化し、信頼性が低くなる。この問題は、インターネットおよび特にこれらのＡＳＮピアリングポイントを介して多数の同時視聴者に対してビデオをストリーミングするとき悪化する。
既存のビデオストリーミングアプローチ

（インターネットの上の）オーバーレイネットワークトポロジーを生成し、これらのオーバーレイネットワークに沿ったネットワークノード間でビデオコンテンツを送信するための異なる技術を特徴付けて区別するために採用された無数の専門用語を伴って、過去数十年において、インターネットを介してビデオをストリーミングする様々なアプローチが進化している。異なるアプローチの比較において、ＧＰＳナビゲーションとの類似性に単純に戻って、例えば、距離、速度、輻輳（通常は、異なる経路に沿ったルーティングにより対処される）任意の２個の点あるいはノード間を移動するために求められる時間に影響する因子を考慮することは有用である。

インターネットでパケットをルーティングする状況では、パケットは光に近いスピードで移動するため、距離（あるいは、地理的な近接度）は直接には関係しない。しかしながら、速度は、経路に沿って遭遇する停止や道路上の防塞の数、あるいはこの状況では、２個のノード間における中間ルーターにおいて遭遇するホップ数による影響を受ける。このように、２個のノードは、物理的近接度に関わらず、それらが比較的少数のホップ数だけ離れている場合、互いに近接していると言える。２個のノード間の経路に沿った中間ノードでの輻輳は、全体の移動時間に影響し、例えば２個のノード間の経路を決定するオーバーレイネットワークを動的に再構成して、動的にトラフィックを再ルーティンすることで対処できる。以下に説明するように、これらの要因は、インターネット上でビデオをストリーミングする異なるアプローチ間の主要な違いを示すのに役に立つ。

インターネット外でビデオを配信する最も一般的な方法は、例えば専用ケーブルあるいは衛星インフラストラクチャーを介して、「起点」から全ての目的地の視聴者に同時にビデオストリーム（例えばテレビ番組）を「ブロードキャスト」することである。全てのネットワークノードに情報をブロードキャストするために、ＬＡＮにおいてネットワークハブを用いることができるが、インターネットを介してスイッチおよびルーターを横断してビデオセグメントのパケットをブロードキャストすることは、非実用的で非効率的である。ほとんどのネットワークユーザーは、ビデオコンテンツの任意のチャネルを視聴することには関心がなく、他のルーターにビデオセグメントをブロードキャストするルーターがすぐに圧倒されるため、起点付近で大量の輻輳が発生する。いつでもチャネルに加わることができる多くの同時視聴者に対して、インターネット上で単一の起点からビデオコンテンツのチャネルを配信するには、ブロードキャストソリューションは単純に適さない。

別の「マルチキャスト」アプローチは、インターネットを介して所定のノードのグループに対して各ビデオセグメントを同時に起点からストリーミングすることを含む。このアプローチは、インターネットを介した大規模なビデオ配信には同様に実用的ではない。さらに、マルチキャスト機能を備える専用のルーター等の特別なインフラストラクチャーが必要となり、大規模な商用利用にはやはり非現実的であり、極めて高価である。

ブロードキャストおよびマルチキャストの技術とは対照的に、ビデオストリーミングに対する「ユニキャスト」アプローチは、（例えば定義された目的地ノードのＩＰアドレスとのＴＣＰ／ＩＰ接続を確立することによって）、起点から単一の目的地ノードに対するビデオセグメントの送信を含む。しかしながら、各視聴ノードに同時に大量のユニキャストパケットを配信することは、起点あるいはその近傍のルーターをすぐに圧倒し、そのような多数の同時送信を処理するための十分な帯域幅を提供する膨大な費用は言うまでもなく、上述した多くの理由により一貫したＱｏＳを達成できない。

（ネットフリックスやユーチューブのような）いくつかのＶＯＤ企業は、一般的に高価な「エッジサーバー」インフラストラクチャーに頼ったこのユニキャストアプローチの変種を採用している。（「コンテンツ配信ネットワーク」あるいはＣＤＮと称されることのある）このアプローチは、インターネットに多数の物理的なサーバーを配備し、ビデオコンテンツの各チャネルのコピーを各サーバーに配信する。その結果、視聴ノードは、（ネットワーク上で近接した−視聴ノードから比較的少数のホップだけ離れた）近くのサーバーから所望のビデオコンテンツを受信できる。

各エッジサーバーは通常、相当な帯域幅と演算能力を備えており、別個のビデオコンテンツソースを本質的に構成し、そこから近傍の視聴ノードが任意の時点（「オンデマンド」）でビデオコンテンツの任意のチャネルを得ることができる。物理的なインフラストラクチャーを加えるこのアプローチは、（一般道路におけるより少ない旋回と最小の時間で）多くの人々を人気の目的地に到達可能とするために追加の高速道路や出口ランプを建設するのと多少類似する。

異なるユーザーは通常、任意の時点で異なるビデオチャネルを見ることを望むが、ＶＯＤシステムは、多数の同時視聴者に特定のビデオイベント（例えば人気のテレビシリーズの最終話）をストリーミングしなければならない「ピーク」需要時間に時折直面し、それは最大のストリーミングビデオ企業のインフラストラクチャーですら圧倒し、あるいは、（例えば需要のピークでないより普段の期間に）しばしば使われない高価なインフラストラクチャーを配備するといった非効率な「最悪のケース」の結果と少なくともなる。代替のＶＯＤソリューションは、（例えば米国特許公開公報２００８／００５９６３１で議論されているように）、ネットワークノード自体の間でビデオコンテンツを複製して配信することで、高価なエッジサーバーインフラストラクチャーの必要を回避しようとしている。

高価なエッジサーバーインフラストラクチャーの有無に拘わらず、これらのＶＯＤソリューションは、ビデオコンテンツの近くのソースを確保するために予め知られたコンテンツをインターネット上の「プレシーディング」エッジサーバーあるいは視聴ノードに全て頼るため、予定されていないビデオイベントに対するＱｏＳの問題に対処しない。予定されていないライブイベントをストリーミングするためには、これら全てのエッジサーバーあるいは視聴ノードに対してビデオコンテンツをリアルタイムに同時配信する必要があり、これらのＶＯＤシステムのいずれによっても対処されない問題である。

より最近では、特定のユニキャストベースのビデオストリーミングの規格（例えば「ＷｅｂＲＴＣ」）が、プラグインを必要とせずにデスクトップおよびモバイルウェブブラウザの間で「ポイント・トゥ・ポイント」のビデオのストリーミングを容易にするために進化している。多くの既存のスマートフォンは、デスクトップおよびラップトップコンピューターと同様に、ブラウザ・トゥ・ブラウザでのビデオストリーミングをサポートするＷｅｂＲＴＣライブラリや、視聴ノードがその帯域幅およびＣＰＵの容量をリアルタイムに検出できる「アダプティブストリーミング」ライブラリを含み、これらのメトリックにおける変化に対応するためにより低いあるいはより高い「ビットレート」を自動的に要求する。

アダプティブストリーミングの実装には、アップルの「ＨＴＴＰライブストリーミング」（ＨＬＳ）、マイクロソフトの「スムーズストリーミング」および「ＭＰＥＧ−ＤＡＳＨ」ＩＳＯ規格等がある。典型的なポイント・トゥ・ポイントビデオストリーミングのシナリオでは、受信ノードは、次の（例えば、次の８個の）ビデオセグメントの利用可能な各ビットレートのバージョンの位置を含む「マニフェストファイル」をＨＴＴＰサーバーから定期的に要求する。例えば、各ビデオセグメントがその解像度に関わらず本質的に同じ時間に配信されるように異なるストリーミングビットレート（帯域幅）を要求する、異なる「ビデオソリューション」を反映して、各ビデオセグメントは、１０８０ｐ、７２０ｐおよび４８０ｐバージョンで利用可能であるかもしれない。

（ＷｅｂＲＴＣをサポートするウェブブラウザにおける）標準的なＨＴＭＬ５ビデオプレーヤーは通常、ビデオコンテンツの再生を開始する前に３個のビデオセグメントをバッファーする。それらは、現在のマニフェストファイルを使用して、各ビデオセグメントについてＨＴＴＰサーバーにＨＴＴＰリクエストを送信する。次に、送信ノードは、受信ノードのウェブブラウザで再生するためのＷｅｂＲＴＣ規格に従って、各ビデオセグメントを（小さな「チャンク」で）受信ノードに「プッシュ」する。受信ノードがアダプティブストリーミングの実装をサポートし、最近のビデオセグメントを受信するために必要な時間が大幅に増加あるいは減少していると判断すると、マニフェストファイル内の選択肢の中から、より低いあるいはより高いビットレートのビデオセグメントの要求を自動的に開始する。言い換えれば、要求されるビデオセグメントの解像度を変化させることで、実際の帯域幅に経時的に適応する。

ビデオのフレームの解像度は、その幅×高さ（例えば、１９２０×１０８０あるいは１０８０ｐ）あるいはフレーム内の画素数の尺度であるのに対して、その「ビットレート」は、送信者から受信者に送信される「ビット／秒」（ｂｐｓ）の数を示す。例えば、１０８０ｐの解像度のビデオの３０フレームが毎秒配信され（３０「フレーム／秒」あるいはｆｐｓ）、各色画素が２４ビットを含むなら（２４「ビット／画素」あるいは２４ｂｐｐ）、ビットレートは略１．５Ｔｂｐｓ（１，４９２，９９２，０００ｂｐｓ、すなわち１，４９２，９９２，０００＝（１９２０×１０８０「画素／フレーム」あるいはｐｐｆ）×（２４ｂｐｐ）×（３０ｆｐｓ）となる。

標準的なビデオコーデックは、より低い実効ビットレート（例えば、３Ｍｂｐｓ）を生じるために、圧縮（例えば、ＭＰＥＧ２圧縮）や他のビデオ符号化技術を使用する。上の観点からすると、「ビットレート」および「解像度」は、より高いあるいはより低い解像度のビデオのフレームを提供することで実効ビットレートを増加あるいは減少させることができる点で、高い相関を有する。したがって、本明細書では、これらの用語をいくぶん交換可能に使用する。

ＷｅｂＲＴＣおよびアダプティブストリーミングの規格は、事実上全てのスマートフォンのユーザーがライブビデオイベントをキャプチャーしてストリーミングすることを可能にし、また、他の個々のスマートフォンユーザーからビデオコンテンツの配列をホスティングする大企業に至るまで、インターネットを介した別の起点から発信されるストリーミングチャネルに、このようなユーザーが参加することを可能にする。しかしながら、これらの規格は、ポイント・トゥー・ポイントビデオストリーミング用に設計されており、インターネット上の多数の同時視聴者にビデオチャネルをストリーミングする「ビデオ配信」問題に対処しない。

この問題に対処するために、いくつかのビデオストリーミング企業（例えば、ストリームルート）は、ビデオコンテンツを一の視聴ノードから他に中継する「ピア・トゥ・ピア」（Ｐ２Ｐ）あるいはメッシュネットワークトポロジーを典型的に含むアプローチを採用している（時折「ピアキャスティング」と称される）。ビデオストリーミングの状況では、これらの用語は、視聴ノードから他へ分散させる形態でストリーミングビデオコンテンツを中継可能とするインターネット上に構築されたオーバーレイネットワークを示すのに、交換可能に使用される。しかしながら、多数の同時視聴者へのストリーミングビデオの配信は、Ｐ２Ｐあるいはメッシュネットワークトポロジーの非ストリーミング用途、例えばファイル転送あるいはファイル共有アプリケーションと区別されるべきである。

Ｐ２Ｐビデオストリーミングシステムは、単一の起点から多数の同時ユーザーへインターネットを介してビデオコンテンツのチャネルを配信する。このようなシステムは、その分散された性質が（例えば、他のノードを介してコンテンツをルーティングすることで）個々の障害点からの回復を容易にする点で、回復力とスケーラビリティの両方を有する傾向があり、より多くのノードがネットワークに追加されるにつれて（すなわち、より多くのより良いルーティング「中継」オプションが利用可能になるにつれて）、その信頼性とパフォーマンスは実際に改善される。

新たなノードが追加され、あるいは既存のノードがチャネルを離れる（視聴を停止する）と、Ｐ２Ｐビデオストリーミングシステムは、オーバーレイネットワークのトポロジーをある程度動的に再構成しなければならない。すなわち、新しいノードを収容するために、ネットワークのノード間のルーティング経路の少なくとも一部を変更する必要がある。例えば、新たなノードが追加されると、そこからビデオコンテンツを受信する（そこにビデオコンテンツを中継する）近くの既存のノードを選択する目的で、その地理的な位置が考慮されうる。

しかしながら、単にそれらの地理的な近接度に基づいて「ピア」ノードを選択すると、例えばそれらが異なるＡＳＮに存在する場合、それらは互いに比較的「遠く」（ネットワークでは近接していない）かもしれない。結果として、それらの間のトラフィックは、１個または複数の潜在的に輻輳しているピアリングポイントを通過するかもしれない。例えば、地理的な近接度が近い２個のノードの間の実際の待ち時間は、それらの各ノードと地理的に離れたノードとの間の待ち時間の合計を超えるかもしれない。この現象は、ＡＳＮピアリングポイントを介してオーバーレイネットワークのノード間でデジタルコンテンツを配信するＢＧＰルーティングに頼ることの欠点を示す「三角不等式違反」（ＴＩＶ）と称されることがある。

既存のＰ２Ｐビデオストリーミングシステムに伴うこの問題の１つの理由は、インターネットの下層アーキテクチャとそれらが「互換性」を有するように構築されていないことにある。インターネット上に構築された全てのオーバーレイネットワークトポロジーは、（新たなあるいは消滅するノードはさておき）上述した無数のＱｏＳ問題等、多くの崩壊あるいは障害ポイントの対象となる。特にＡＳＮピアリングポイントでのインターネットの下層のＱｏＳの変動性に対処しないことで、このようなシステムは一貫したＱｏＥをユーザーに提供するにあたり大きな障害に直面する。

したがって、（ＧＰＳナビゲーションシステム）のような既存のＰ２Ｐビデオストリーミングシステムは、ピアの中継ノードを選択するために（ネットワークの近接度ではなく）地理的な近接度に依存し、輻輳が生じた「事実の後」にのみトラフィックを再ルーティングする。さらに、同時ユーザーへのリニアデータのリアルタイムのストリーミングは、コンテンツが各ノードに「同時に」到着しなければならないという、ＧＰＳナビゲーションシステムには見られない追加の制約を課す。（より高速の経路を提供するための高速道路や出口ランプの建設に類似した）エッジサーバーや他の物理的なインフラストラクチャーのアプローチは高価であるとともに、予定されていないイベントや特定のイベントの高い同時使用の問題に適切に対処できない。

したがって、上述の欠陥に対処して、一貫したＱｏＥをクライアントノードに提供するためにオーバーレイネットワークを生成して動的に変更するにあたって、インターネットの下層のアーキテクチャ（特に多くのインターネットトラフィックが流れるＡＳＮピアリングポイント）を考慮に入れたデジタルコンテンツ配信システムが求められている。

本発明によれば、（１）構成要素のうちの１個（例えばＡＳＮ）内の各ノードの位置を含む、下層のネットワークの構成要素（例えば、ＡＳＮとそれらを相互接続するピアリングポイント）を相互接続する共有リンクのマップを維持し、（２）下層のネットワーク（インターネット）上に構築された１個あるいは複数のオーバーレイネットワークに沿って、それらの共有リンク（ＡＳＮピアリングポイント）を横断するノード間のネットワークトラフィックを監視することでメトリックを生成し、（３）メトリックとマップを経時的に分析して、共有リンク（ＡＳＮピアリグポイント）の容量の時間変化を反映した輻輳レベルを予想し、（４）予想された輻輳レベルに基づいてオーバーレイネットワークのトポロジーを動的に再構成して、オーバーレイネットワークに沿ったクライアントノード間のデジタルコンテンツの最適な経路を生成することで、下層のネットワーク（例えばインターネット）のノードのユーザーに一貫したＱｏＥを提供するデジタルコンテンツ配信システムに関して、新規の方法およびアーキテクチャの様々な実施形態が開示される。

本明細書では、本発明の「仮想ブロードキャスト」システムの特定の実施形態は、（エッジサーバーや他の高価な物理的なインフラストラクチャーの必要性を回避しつつ）、異なる時間にチャネルに参加する可能性のある潜在的な多くの同時視聴者に対して単一の起点からリアルタイムでストリーミングされるビデオコンテンツの１個あるいは複数のチャネルの視聴者の間で一貫したＱｏＥを提供するという状況において説明される。より詳細に後述するように、同時ユーザーへリニアコンテンツをユニキャストストリーミングするという状況において、「仮想ブロードキャスト」という用語を使用する。ユーザーの観点から見ると、ユニキャストストリーミングがコンテンツをルーティングするために使用されているにもかかわらず、コンテンツを同時に受信するという点で、コンテンツはそれらに「ブロードキャスト」される。本発明の他の実施形態は、ネットワークの構成要素間の共有リンクの容量が限られているために、デジタルフォーマットに変換可能なあらゆるタイプの情報のルーティングが制約されるという多くの他の状況において、当業者にとって明らかである。

本明細書の目的のために、多数の異なるチャネルを同時に受信する単一のノードは、それぞれが単一のチャネルで定義された別々のオーバーレイネットワーク上の別個のノードと見なすことができる。ＶＯＤの状況では、特定の番組のそれぞれ個別の「表示」は、それ自身の視聴ノードのネットワークを有する別個のチャネルと見なすことができる。

インターネットのＱｏＳの変動性にさらされるインターネット上に構築されたオーバーレイネットワークに実装されているにもかかわらず、本発明のシステムは、予定されていないおよび予定されたイベントを扱い、ライブおよび事前録画されたイベントをストリーミングし、多数の同時ユーザーの間で一貫したＱｏＥを維持する高いスケーラブルを有する方法で最小の遅延を伴うリアルタイムでこれらのイベントをストリーミングすることができる。同時ユーザーの数（特に、任意のＡＳＮ内での）が増加するにつれて、システムのパフォーマンスおよびユーザーのＱｏＥは実際に向上する。

クライアント−サーバーアーキテクチャがサーバー側のルーティングの決定を集中化するために使用される。ビデオコンテンツの分散ストリーミング配信は、動的に再構成可能なＰ２Ｐオーバーレイネットワークを介して行われ、各ビデオチャネルの視聴ノードの間でビデオコンテンツを中継（すなわち「プッシュ」）することが可能となる。クライアントノードは、（ほとんどのデスクトップおよびモバイルウェブブラウザに組み込まれた）標準のＨＴＭＬ５ビデオプレーヤーを使用してビデオを表示あるいは再生し、（ジャバスクリプトのような）カスタムエンベデッドコードを頼って、ビデオセグメントの受信処理、これらのビデオセグメントの他のノードへの中継ならびに様々なパフォーマンスメトリックの監視といった追加的な機能を実装する。他の実施形態では、そのような機能の一部あるいは全部がカスタムアプリケーションあるいはモバイルアプリケーションに統合される。

本発明のシステムは、デスクトップとモバイルウェブブラウザの間の「ポイント・トゥ・ポイント」ビデオストリーミングを容易にし、より低いあるいはより高いビットレートのビデオセグメントを自動的に要求することでノードの帯域幅における変化に適応する。一の実施形態では、仮想ブロードキャストシステムは、ＷｅｂＲＴＣおよびアダプティブストリーミング規格（ＨＬＳ、ＭＰＥＧ−ＤＡＳＨあるいはスムーズストリーミングのような）を含むユニキャスト規格を使用して、ウェブブラウザのプラグインを必要とせずにビデオストリーミングを容易にし、ノードが帯域幅やＣＰＵの容量といったそれらのパフォーマンス能力を検出できるようにする。

各イベントは、複数の動的に再構成可能なオーバーレイネットワークを介して、同時ユーザーへの各チャネルの「起点」配信のための中央「仮想ブロードキャストサーバー」に提供される。イベントは、仮想ブロードキャストサーバーに完全なファイルとして転送されたものでも、ライブでストリーミングされたものでも、事実上あらゆるソース（ＣＤＮを含む）から取得できる。ＷｅｂＲＴＣを用いた実施形態では、オーバーレイネットワークを介したユーザーへのシーケンス配信のために、ＷｅｂＲＴＣを実装したスマートフォンを持つあらゆるユーザーは、仮想ブロードキャストサーバーに対して事前録画されたビデオイベントをアップロードし、あるいはイベントをライブでキャプチャーしてそれらをアップロードできる（仮想ブロードキャストサーバーからストリーミングされた他のチャネルを視聴できるのと同様に）。

一の実施形態では、仮想ブロードキャストサーバーは、インターネット上に構築された動的に再構成可能なオーバーレイネットワークを介してビデオセグメントが配信される各チャネルへの起点として機能する「ＰＯＩコンテンツサーバー」を含む。ビデオセグメントは、ビデオイベントの元の発行者によって決定された固定されたサイズを通常有する（例えば１〜１０秒）。ビデオセグメントは、クライアントノードによって視聴され、オーバーレイネットワークにより定義された経路に沿ってノードからノードへ「プッシュ」される（すなわち、ＷｅｂＲＴＣ規格に従って個々の固定サイズの「チャンク」として中継される）。一の実施形態では、各ビデオセグメントは、ＭＰＥＧ２転送プロトコルに沿ってストリーミングする際に最大の効率を得るために、ＵＤＰデータグラム「パケット」のサイズに一致するように６４ＫＢのチャンクに分割される。

ビデオセグメントはほとんどの場合で各クライアントノードに効率的にプッシュされるが、一の実施形態では、クライアントノードは、ビデオセグメントの全てのチャンクが時間内に到着していないことを検出し、現在のマニフェストファイルを利用してＰＯＩコンテンツサーバー（すなわち、フォールバック供給位置として）からビデオセグメントを要求できる。

各ノードは、ＰＯＩコンテンツサーバーによって利用可能にされたチャネルへの参加を求めるため、ノードは、そのノードが存在する特定のＡＳＮを決定する（別の実施形態では、仮想ブロードキャストサーバーの助けにより）。仮想ブロードキャストサーバーは、（ＡＳＮおよびそれらの様々なピアリングポイントの相互接続を含む）インターネットの動的な「ＡＳＮ相互接続マップ」および様々な監視されたパフォーマンスメトリックと共に、「ＡＳＮ」位置情報を利用し、これらのＡＳＮピアリングポイントでの輻輳レベルの予想に基づき動的に再構成されるオーバーレイネットワークの間でのチャネルコンテンツのルーティングを最適化する。別の実施形態では、仮想ブロードキャストサーバーはこのプロセスを支援するため、そのＡＳＮ位置に加えて、各ノードの地理的な位置も利用する。

一の実施形態では、オーバーレイネットワークのトポロジーは、視聴ノード間でのビデオセグメントのルーティング経路を定義し、チャネルの各ビデオセグメントのために（全体的にあるいは部分的に）動的に再構成される。別の実施形態では、それらは、ビデオセグメントの各チャンクのために（全体的にあるいは部分的に）動的に再構成される。このようにして、インターネットのアーキテクチャは、（ＡＳＮピアリングポイントでの予想される輻輳レベルと同様に）、ビデオチャネルの各ビデオセグメントの最適なルーティング経路を決定する際に考慮される。別の実施形態では、オーバーレイネットワークに沿った一部あるいは全部の経路がビデオセグメントを時間内に配信することができる場合（そのような経路が最適でなくても）、所定の輻輳閾値が満たされるか、他の十分に重要な問題が特定されるまでは、そのような経路は再構成されない。

一の実施形態では、クライアントノードは、例えば（ＡＳＮピアリングポイントでの輻輳を含む）インターネットを介したラストワンマイル問題およびＱｏＳ問題、ならびに仮想ブロードキャストシステム自体の１個あるいは複数のチャネルの同時視聴者の数に起因した輻輳に関連したパフォーマンスの問題を監視する。それらは、インターネットおよびＡＳＮを介して指定されたサイトにコンタクトするのに必要な時間を監視するとともに、他のノードにビデオセグメントを中継するのに必要な時間を監視する。クライアントに監視されたメトリックは、動的なルーティング決定を行う際に使用するために仮想ブロードキャストサーバーに伝達される。一の実施形態では、仮想ブロードキャストサーバーは、標準的なウェブソケットプロトコルを介してクライアントノードと通信する「シグナリングサーバー」を含む。

クライアントノードは、ユーザーがビデオイベントをキャプチャーしてそれをリアルタイムで仮想ブロードキャストサーバーにアップロードすることを可能とする「アップロード部」をオプションで含む。あらゆるクライアントノードから仮想ブロードキャストサーバーへのパスは複数のＡＳＮを通過する可能性があるため、ビデオイベントのストリーミングを容易にし、中間ルーターでパケットが遅延あるいはブロックされるのを避けるために、カスタム「シャワーイング」プロトコルが用いられる。一の実施形態では、ユーザーの検索に基づきスプラッシュを特定して、それ以外の形ではＰＯＩコンテンツサーバーを介して利用できないトレンドイベントをインターネットからストリームして視聴する能力をユーザーに与える仮想ブロードキャストサーバー上の「スプラッシュ抽出」サーチエンジンを介して、クライアントノードは、トレンドイベント（本明細書では「スプラッシュ」と称する）を検索して視聴することもできる。

チャンネルへの参加を要求すると、ノードは、それらの中継能力、すなわちそれらの接続タイプ（例えば、３Ｇあるいは４Ｇセルラー、ＷｉＦｉ、ＬＡＮ等）ならびにそれらのＣＰＵ、オペレーティングシステム、ブラウザおよびメモリーの構成や、経時的に監視される他の固定および可変のパフォーマンスメトリックを含む種々の要素から推定される信頼できる「アップストリーム帯域幅」に基づき、仮想ブロードキャストサーバーによって分類される。一の実施形態では、ノードは、それらの相対的な中継能力に基づき３つのレベルに分類される。最低レベルのノード（「Ｃ」ノード）はビデオセグメントを視聴できるが、他のノードにそれらを中継できない。中間レベルのノード（「Ｂ」ノード）は、ＡＳＮ内においてビデオセグメントの視聴と中継の両方を実行できる。最高レベルのノード（「Ａ」ノード）は、ＡＳＮ内およびＡＳＮ間で、ビデオセグメントの視聴と他のＡノードへの中継とを実行できる。

別の実施形態では、例えば監視されたパフォーマンスメトリックや、所定の分類のより多くのあるいはより少ない中継ノードに対するシステムの現在のニーズに基づいて、ノードの分類は動的に変更できる。さらに、ビデオセグメントを中継するためにＡＳＮ内に十分なＡノードが存在する場合、Ｂノードとして扱われるものの（例えば、既存のＡノードがチャネルを離れる場合に）必要に応じてＡモードに昇格できる「Ｂ：Ａ」ノードに、Ａノードを指定できる。一の実施形態では、個々のノードが（良い方あるいは悪い方への）パフォーマンスの大きな変化を示す場合、ノードを（例えば、ＢノードからＣノードへあるいはその逆に）再分類し、問題が解決されると、最初の分類に戻すことができる。

別の実施形態では、クライアントノードは、それらが複数の他のノードとの間でビデオセグメントのチャンクを中継および受信できるように、（例えば、それらの能力やクライアントパフォーマンスメトリックに基づき）複数の「スロット」に割り当てられる。この実施形態では、クライアントノードは、１個の「供給」ノードのみからビデオセグメントを受信するが、そのビデオセグメントを複数の他のクライアントノードに「供給」あるいは中継することができる。同じＡＳＮ内のＡノードに中継するための４個と、他のＡＳＮ内のＡノードに、すなわちＡＳＮピアリングポイントを経由して、中継するための４個の最大８個の中継スロットに、Ａノードは割り当てられる。Ｂ：ＡおよびＢノードは、それらのＡＳＮ内の他のクライアントノード（例えば、他のＢ：Ａ、ＢおよびＣノード等）に中継するための最大８個のスロットに割り当てられる。別の実施形態では、クライアントノードは、（例えば、複数の受信スロットの間でチャンクを切り替えることで）、複数の他のクライアントノードによる「供給」を受けてもよい。この技術は、より高いパフォーマンスが要求される高いビットレート（例えば４Ｋ）のビデオストリームに採用できる。

別の実施形態では、特定のノードは（それらの能力およびクライアントパフォーマンスメトリックに基づき）、単一の供給ノードからビデオセグメントの複数の解像度を受信できる（あるいは、代替の実施形態では、異なる供給ノードから異なる解像度を受信できる）。これらのノードのアップストリーム帯域幅が十分な場合、それらは、「ポリキャスティング」ノードと見なされ、必要な程度にまで、１個あるいは複数の指定されたノードにビデオセグメントのこれら複数の解像度を中継あるいは供給できる。

オーバーレイネットワークの動的な再構成を容易にするために、仮想ブロードキャストサーバーは、パフォーマンスメトリックを継続的に分析してＡＳＮピアリングポイントを経由する輻輳のレベルを予想する、すなわち将来の短い時間（例えば１分）におけるＡＳＮピアリングポイントの輻輳レベルを予想する「ディープマッパー」ディープラーニングエンジンを採用する。一の実施形態では、例えばＡＳＮ内の一のＡノードと別のＡＳＮ内のＡノードのようなＡノードの間の潜在的なＡＳＮ間の各経路に対して、予想された「輻輳値」が生成される。別の実施形態では、輻輳値は、Ａノードの各ペアの間の最適な経路のために予想された輻輳レベルを反映する。

一の実施形態では、仮想ブロードキャストサーバーは「オーバーレイネットワーク生成部」を使用して、例えばＡＳＮ内でおよびＡＳＮを横断して一のノードから別のノードにプッシュされるビデオセグメントの最適な経路を決定する等、ＡＳＮ間およびＡＳＮ内の両方のオーバーレイネットワークを生成して（全体的あるいは部分的に）動的に再構成する。この実施形態では、オーバーレイネットワーク生成部は、各ノードが使用できる利用可能なスロットの数と、各ノードが受信あるいは中継できる解像度の数を考慮する。

オーバーレイネットワーク生成部は、Ａノードのトポロジーを表すＡＳＮ間「仮想データトランク」オーバーレイネットワークを（ディープマッパーの支援を受けて）生成して動的に再構成する。言い換えれば、それは、Ａノードと、ＡＳＮ内および（特に）ＡＳＮ間における、すなわち潜在的に輻輳するＡＳＮピアリングポイントを介した、これらのＡノード間でビデオセグメントが進むリンクあるいはルーティング経路を表す。

仮想データトランクは、（例えば、現在のマニフェストファイルを使用する）近くのＰＯＩコンテンツサーバーから各ビデオセグメントを要求するように指示されたＡノードのセットや、それぞれがそのビデオセグメントをプッシュするＡノードのセット等を、（ＡＳＮ内およびＡＳＮ間の両方で）識別する。その結果、そのビデオセグメントは、視聴ノードを含む全てのＡＳＮに渡って拡散される。各視聴ノードに到達するために、セグメントは、視聴ノードが存在しない中間プライベートバックボーンを移動することもできる。

オーバーレイネットワーク生成部は、ＡＳＮ内のＡノードからそのＡＳＮ内のＢ：Ａ、ＢおよびＣノードにビデオセグメントを中継するＡＳＮ内「スワーム」オーバーレイネットワークを１個あるいは複数生成することもできる。これらスワームオーバーレイネットワークは、各ビデオセグメントに対して（あるいは、代替の実施形態ではビデオセグメントの各チャンクに対して）、（全体的にあるいは部分的に）動的に再構成されてもよい。一の実施形態では、ＡＳＮ内の各スワームオーバーレイネットワークは、そのスワーム階層内のノード間でビデオセグメントを受信、視聴および中継（Ｃノードは除く）を行うＢ：Ａ、ＢおよびＣノードの階層的なトポロジーを（ＡＳＮ内のＡノードに関して）表す。

このように、本発明の仮想ブロードキャストシステムおよび方法は、ネットワークトラフィックを監視して分析することでＡＳＮピアリングポイントや輻輳の他の主要ポイントでの有限の容量を効率的に使用し、これら主要輻輳ポイントでの輻輳レベルの予想に基づき動的に再構成される仮想データトランクおよびスワームオーバーレイネットワークのノード間でデジタルコンテンツのルーティングを最適化し、これによって、システムユーザー間の一貫したＱｏＥを維持する。

インターネット上で動的に再構成される本発明のオーバーレイネットワークの一の実施形態を示すグラフ。

本発明のクライアントストリーミングビデオ装置の主要なクライアント側の構成要素の一の実施形態を示すブロック図。

本発明の仮想ブロードキャストサーバーの主要なサーバー側の構成要素の一の実施形態を示すブロック図。

本発明の動的なビデオストリーミングプロセスの一の実施形態を示すフローチャート。

本発明のシステムおよび方法の詳細な実施形態は、添付の図に示され、以下に説明される。最初に本発明は、図面を参照して以下に説明する特定の実施形態に限定されないことに留意されたい。

上述したように、本明細書では、本発明の特定のアプリケーションが、インターネットを介して多数の同時ユーザーにストリーミングビデオを配信する状況で説明されるが、本発明の原理は、ネットワークの構成要素間の共有リンクの有限の容量がデジタルコンテンツのいかなるタイプのルーティングを制約する他の多くの状況において等しく適用できる。

インターネットを介してストリーミングビデオを配信する状況においても、本明細書で記載されるクライアントノードとサーバーの構成要素の間の機能の割り当ては、設計のトレードオフの結果であり、この機能の多くは、本発明の精神から逸脱することなく、クライアント側およびサーバー側の構成要素を再割り当てできる。同様に、クライアント側の機能は、単一のモジュラー構成要素に割り当てたり、複数の異なる構成要素にまたがったりすることができ、１個あるいは複数のスタンドアローンのアプリケーション、モバイルアプリケーション、スタンドアプリケーションとモバイルアプリケーション、ジャバスクリプト、他のスクリプティングあるいはプログラミング言語との組み合わせとして実装できる。さらに、サーバー側の構成要素は、単一のハードウェアサーバーに、あるいは複数の異なるサーバーをまたがって実装することができる。このような機能は、単一のソフトウェアモジュールに統合し、あるいは１個あるいは複数のサーバーに渡って分散された異なるソフトウェアモジュールに割り当ててもよい。

最後に、標準的なプロトコルおよびライブラリ（例えば、ＨＴＴＰ、ＷｅｂＳｏｃｋｅｔ，ＷｅｂＲＴＣ、ＳＴＵＮおよび種々のアダプティブストリーミング規格）を用いたこれらの実施形態では、これらの標準的なプロトコルおよびライブラリの一部あるいは全部により提供される機能は、本発明の精神から逸脱することなく、他の規格あるいはプロプライエタリの実装に置き換えることができる。
オーバーレイネットワーク

図１はインターネット上にマッピングされた本発明のオーバーレイネットワーク１００の一の実施形態を示すグラフである。インターネットはそれ自体無数の異なる方法で図示できるが、図１はピアリングポイント１２０を介して相互に接続された、１セットのＡＳＮ１１０ファイバーリングとしてインターネットを示す。任意の時点で特定のビデオチャネルを視聴している個々のクライアントノードが、各ＡＳＮ１１０内に示されている。図１には示されていないが、複数のチャネル、したがって複数セットのオーバーレイネットワーク１００が（一の実施形態において）同時にアクティブとなることができる。

上述のように、仮想データトランクオーバーレイネットワークは、ＡＳＮ１１０内（直接の接続）およびＡＳＮ１００間（すなわち、ピアリングポイント１２０を介した）の両方で、Ａノード１３０間の相互接続１７５を表す。バックボーンコネクター１９５は、商用ノードを含まないプライベートＡＳＮ（不図示）を介して、２個のＡＳＮの間のＡノードの相互接続を示すが、単に２個のパブリックＡＳＮ１１０を相互接続するだけである。例えば、バックボーンコネクター１９５は、ＡＳＮ１１０−ｆ内のＡノードとＡＳＮ１１０−ｅ内のＡノード１３０との接続が示されている。このシナリオでは、２個のＡノード１３０の間のトラフィックは、複数の「プライベート」ピアリングポイント１２０（あるいは、プライベートＡＳＮを用いた他のプロプライエタリ接続）を通過するかもしれない。

上述のように、一の実施形態では、２個の異なるプライベートＡＳＮ１１０のＡノード１３０の間の（すなわち、ピアリングポイント１２０を介した）接続１７５の場合と同様に、このような接続のパフォーマンスはエンドポイント（すなわち、２個のＡノード１３０）においてのみ監視できる。同じＡＳＮ内の２個のＡノード１３０の間の接続１７５に沿ったトラフィックは、潜在的に輻輳したピアリングポイント１２０を横切らないので、ＡＳＮ１１０間のトラフィックよりも相対的に高速である可能性が高い。バックグラウンドコネクター１９５とＡノード１３０への／からの接続１７５は、一方向への矢印で示されているが、図１に示される全てのクライアントノード間で二方向への接続がサポートされている事実にかかわらず、これらは現在の一方向へのルーティングパスのみを反映したものである。

本発明の任意の２個のクライアントノードの間の全てのトラフィックは、パブリックインターネットを横断し、したがってＱｏＳに影響する様々な中間ルーター（不図示）を通過することに留意されたい。システムは、ＡＳＮ１１０内およびＡＳＮ１１０間の両方（したがって、１個あるいは複数のピアリングポイント１２０）のＱｏＳ効果を監視する。一の実施形態では、このようなＡＳＮ内およびＡＳＮ間のトラフィックが、（仮想ブロードキャストサーバーの方向の）各クライアントノードで監視され、（Ａノード１３０間の仮想データトランクオーバーレイネットワークと、ＡＳＮ１１０内の各Ａノード１３０からそのＡＳＮ内のＢ（Ｂ：Ａ）ノード１４０およびＣノード１５０へのスワームオーバーレイネットワークを含む）オーバーレイネットワーク１１０により表されたノードとルーティング経路の動的な再構成のために、仮想ブロードキャストサーバーに配信される。

図１はこれらのオーバーレイネットワーク１００の「現在の状態」が与えられた際に、クライアントノード間でビデオセグメントが進む様々なルーティング経路を示す。言い換えれば、それは、一の実施形態において、各ビデオセグメントに対して（代替の実施形態では、ビデオセグメントの各チャンクに対して）動的に再構成可能なこれらのオーバーレイネットワークの現在のトポロジーを示す。いずれの特定のビデオセグメントについても、オーバーレイネットワーク１００は（全体的にあるいは部分的に）再構成されても、されなくてもよく、この決定は、経時的に収集されたパフォーマンスメトリックに少なくとも部分的に依存する点に留意されたい。

ＡＳＮ１１０−ｃは、ＡＳＮ１１０−ｃ内あるいは（例えば、他の１個あるいは２個のＡＳＮ１１０を隔てた）近くに存在するＰＯＩコンテンツサーバー（不図示）がＨＴＴＰリクエストに応答して現在のビデオセグメントをＡノード１３０−ａに配信し、オーバーレイネットワーク１００に沿ったチャネルのビデオセグメントのストリーミングを開始するシナリオを示す。より詳細に後述するように、ＰＯＩコンテンツサーバーは基本的に、同一あるいは近くのＡＳＮ１１０の複数の要求するＡノード１３０に対して各ビデオセグメントを配信し、これらのＡノード１３０は次に、オーバーレイネットワーク１１０に沿って複数の他のノードにビデオセグメントをプッシュし、任意の時点においてクライアントノードに配信され、クライアントノードから中継されたビデオセグメントのチャンクの複数の同時コピーの「再配布」が実行される。

このシナリオでは、Ａノード１３０−ａは、２個の他のＡノード１３０にビデオセグメントを中継し、１個はＡＳＮ１１０−ｃ内で、もう１個はピアリングポイント１２０を介してＡＳＮ１１０−ａに至る。上述したように、仮想データトランクオーバーレイネットワークは、ビデオセグメントがＡＳＮ１１０内および間のＡノード１３０間で中継される際に、ビデオセグメントが進むルーティング経路を示す。したがって、このシナリオでは、ビデオセグメントは、ＡＳＮ１１０−ｃ内の複数のＡノード１３０の間で中継されるだけでなく、様々なピアリングポイント１２０を介してＡＳＮ１１０−ａから複数の直接に相互接続されたＡＳＮ（すなわち、１１０−ａ、１１０−ｄ、１１０−ｆ、１１０−ｇ）にも中継され、そこからさらに仮想データトランクオーバーレイネットワークの複数のホップを介して他のＡＳＮ１１０に中継される。

より詳細に後述するように、ＡＳＮ１１０内に求められるＡノード１３０の数は種々の要因、すなわち、そのＡＳＮ１１０内の他のクライアントの視聴ノードの数ならびに（それらの分類、空いているスロットの数および経時的に監視されたパフォーマンスメトリックにより決められる）それらの相対的な能力等に依存する。例えば、ＡＳＮ１１０−ｂ、１１０−ｆ、１１０−ｉおよび１１０−ｊは、それらは異なる数の供給する他のクライアントノードを有するが（ＡＳＮ１１０−ｆ内の単一の他のノードと、ＡＳＮ１１０−ｉの多くの他のノードと比較して）、それぞれ単一のＡノード１３０のみが示されている。

ノードの監視されたアップストリーム帯域幅は、直接供給するノードの数（すなわち、使用される発信スロットの数）を決定する重要な要素であるが、（例えばあるものから次へビデオセグメントを中継する）ＡＳＮ内のノードの「チェーン」の長さは、これらがどれくらい速く（典型的には１ミリ秒未満）達成されたかを考慮すると、ほとんど無関係であることを認識することは重要である。例えば、外部のＡＳＮ１１０（ＡＳＮ１１０−ｇおよびＡＳＮ１１０−ｈ）内の２個のＡノードならびにＡＳＮ１１０−ｉ内の２個のＢノード１３０に直接供給するＡＳＮ１１０−ｉ内の単一のＡノードは、４個の発信スロットを使用する（この実施形態では、比較的高い監視されたアップストリーム帯域幅を反映する）。さらに、ＡＳＮ−１１０ｉの単一のＡノードから間接的に供給されるＢノード１４０およびＣノード１５０の長いチェーンは、そのアップストリーム帯域幅を反映しない。

各ＡＳＮ１１０内で、１個あるいは複数のスワームオーバーレイネットワークが生成され（この実施形態では各ビデオセグメントに対して動的に再構成され）、そのスワームオーバーレイネットワーク内において、各Ａノード（すなわち、スワームオーバーレイネットワークの「ルート」ノード）から様々なＢ（およびＢ：Ａ）ノード１４０およびＣノード１５０にそのＡＳＮ１１０内のビデオセグメントを中継する。（ＡＳＮ１１０−ｈで２個のスワームオーバーレイネットワークが示されているのに比較して）１個のスワームオーバーレイネットワークのみがＡＳＮ１１０−ｃでは示されているが、各ＡＳＮ１１０内で生成されるスワームオーバーレイネットワーク（および各スワームオーバーレイネットワークの内部トポロジー）の数は、ＡＳＮ１１０内のクライアント視聴ノードの数、現在および過去のパフォーマンスメトリックおよび空いているスロットの数等の様々な要因に依存する。

上述の通り、ＡＳＮ１１０−ｂのＡノード１３０−ｂのようなクライアントノードは、複数の他のクライアントノードから（このケースでは、異なるＡＳＮ（１１０−ａおよび１１０−ｄ）の２個のＡノードから）ビデオセグメントを受信できる。一の実施形態では、より詳細に後述するように、これら２個の他の供給ノードは、パフォーマンス上の理由から、例えば継続的に輻輳レベルが監視されるピアリングポイント１２０をチャンクが横切ることから、Ａノード１３０−ｂへビデオセグメントのチャンクを交互に切り替えて送信する。別の実施形態では、例えば過去のパフォーマンスメトリックに基づくと（ピアリングポイント１２０の輻輳とは別にあるいは加えて）ノードへの供給の信頼性が疑わしい等の理由から、これは、冗長性の目的で行うことができる。

パフォーマンスメトリックを監視して、ビデオセグメントを中継して、オーバーレイネットワーク１００を動的に再構成する方法は、これらの方法を実装した主要なクライアント側（図２）およびサーバー側（図３）の機能的構成要素の議論に続いて、図４を参照しつつさらに詳細に検討される。
クライアントストリーミングビデオ装置

図２を参照すると、クライアント装置２００は、本発明のクライアントストリーミング装置の主要構成要素の一の実施形態を示す。クライアント装置２００は、デスクトップあるいはラップトップコンピューターならびにスマートフォン、他のモバイル装置あるいはストリーミングビデオのようなストーリミングコンテンツを扱うことができる実質的に任意の他の民生用電子機器として実装できる。クライアント装置２００は、特定の標準的なハードウェアおよびソフトウェア演算構成要素と、当業者に周知のＣＰＵ２１２、メモリー２１４、オペレーティングシステム２１６、ネットワークアダプター２１７、ディスプレイ２１８およびカメラ２１９を含む関連する周辺機器とを含む。クライアント装置２００は、これらの構成要素と周辺機器２１０を特定の標準ライブラリ２２０とともに使用してネットワークノードとなり、本発明の仮想的ブロードキャストシステムの他のネットワークノードとの間でストリーミングビデオコンテンツを受信し、表示し、中継する。

本発明は、装置間でのビデオコンテンツのストリーミングを容易にするために使用されるネットワークプロトコルや他の機能を実装した特定の標準ライブラリ２２０（ほとんどのスマートフォンおよび多くの他の演算装置に見られる）を活用する。例えば、ビデオコンテンツは、プラグインを必要とせずに、二人のスマートフォンユーザーの間でストリーミングされ、それらのモバイルウェブブラウザに表示される。標準ライブラリ２２０は、（ビデオコンテンツのストリーミングのためのブラウザ・トゥ・ブラウザ通信を容易にする）ＷｅｂＲＴＣ２２２ＡＰＩと、ＨＬＳ、ＭＰＥＧ−Ｄａｓｈおよびスムーズストリーミング等（クライアントの帯域幅およびＣＰＵの容量の変化のリアルタイムな検出に適応するためにストリーミングのビットレートを自動的に調整可能とする）種々のアダプティブストリーミング２２４実装と、（単一のＴＣＰ／ＩＰ接続を介した迅速な双方向クライアント‐サーバー通信を容易にする）ＷｅｂＳｏｃｋｅｔ２２６プロトコルと、（ウェブサーバーとクライアントウェブブラウザとの間の頻繁でない標準的な通信用の）ＨＴＴＰ２２８とを含む。

クライアント装置２００は、ストリーミングデジタルコンテンツを視聴あるいは再生するための標準プレーヤー２３２（一の実施形態では、標準ＨＴＭＬ５ウェブブラウザ２３０に統合された標準ビデオプレーヤー）を含む。別の実施形態では、標準プレーヤー２３２は、スタンドアローンのデスクトップアプリケーションあるいはスマートフォンアプリケーションに統合される。標準ＨＴＭＬ５ウェブブラウザを活用する一の利点は、標準ライブラリ２２０の多くがウェブブラウザで動作するように設計されているため、スタンドアローンのデスクトップアプリケーションあるいはスマートフォンアプリケーションを必要とするプラグインあるいは他のカスタム機能を必要としないことである。

さらに、ウェブブラウザは、（例えばクライアントブラウザプラグインを必要とせずにウェブページの一部として標準ウェブサーバーから配信される）標準的なウェブブラウザの機能を補うためにしばしば使用されるジャバスクリプトのようなクライアント側のスクリプト言語もサポートする。一の実施形態では、（通信部２７０、パフォーマンス監視部２４０、受信部２５０、中継部２６０およびアップロード部２８０を含む）クライアント装置２００の非標準的な主要構成要素はジャバスクリプトで実装され、コンテンツアレイ２５５はそのジャバスクリプトコードによって生成されて維持される。しかしながら、本発明の精神から逸脱することなく、これらの主要構成の一部あるいは全部は他のプログラミング言語およびスタンドアローンデスクトップアプリケーションあるいはスマートフォンアプリケーションにより実装できることに留意されたい。

標準ライブラリ２２０は、ビデオコンテンツを含むコンテンツの一般的なポイント・トゥ・ポイント（ユニキャスト）ストリーミングを容易にする。クライアント装置２００の非標準的な主要な構成要素は、本発明の仮想ブロードキャストシステムにより実装されたデジタルコンテンツデリバリーアーキテクチャのクライアント側の態様に対処する。一の実施形態では、ストリーミングプロトコルは、コンテンツのルーティングをクライアントサーバーアーキテクチャを介して集中化するＷｅｂＲＴＣ２２２の上に構築され、コンテンツ自身は、動的に再構成可能なＰ２Ｐオーバーレイネットワークを介して拡散される形で（ノードからノードにプッシュされて）ストリーミングされる。

例えばＥメール内やウェブページ上のリンクを介して、あるいはスタンドアローンデスクトップアプリケーションあるいはスマートフォンアプリケーション内から等の様々な異なる方法で、クライアント装置２００のユーザーは、１個あるいは複数のコンテンツのチャネルに最初に遭遇するかもしれない。一の実施形態では、仮想ブロードキャストサーバー３００は（図３を参照しつつより詳細に後述する）、標準ＨＴＭＬ５ウェブページをチャネルの選択を伴ってＨＴＭＬ５ウェブブラウザ２３０を配信する。この「チャネルウェブページ」は、シグナリングサーバー３３０ならびに（例えばＷｅｂＲＴＣ２２２およびアダプティブストリーミング２２４ライブラリを使用する）他のクライアントノードとの通信、ビデオセグメントのチャンクの受信、処理およびこのようなノードとの間の中継を含む、クライアント装置２００の非標準の構成要素の機能を実装するために、ＨＴＭＬ５ウェブブラウザ２３０によって解釈されるプロプライエタリジャバスクリプトコードを含む。

チャネルウェブページ内のチャネルリンクをクリックすると、ユーザーは、現在ストリーミングされている、あるいは別の実施形態では後の所定の時点（「参加リクエスト」）でストリーミングが開始されるビデオコンテンツの特定のチャネルに参加するために、リクエストを生成する。仮想ブロードキャストサーバー３００のシグナリングサーバー３３０は、通信部２７０を介したクライアント装置２００とのウェブソケット２２６接続の確立を試みることで、参加リクエストに応答する。図３を参照しつつより詳細に後述するように、クライアント装置２００がビデオコンテンツの受信および中継のために、仮想ブロードキャストサーバー３３０とのウェブソケット２２６接続および他のクライアント装置２００とのＷｅｂＲＴＣ２２２接続を確立できるように、仮想ブロードキャストサーバー３００は、（例えばＮＡＴファイアーウォールの背後にある）クライアント装置２００のパブリックＩＰアドレスを発見する「ＳＴＵＮ」３３２プロトコルを使用する。

ここで説明する実施形態では、クライアント装置２００は、任意の所定の時間に１個のビデオチャンネルにのみ参加する。他の実施形態では、クライアント装置２００は、本発明の精神から逸脱することなく、同時に複数のチャネルに参加できる。

クライアント装置２００は、シグナリングサーバー３３０との双方向通信のための接続部２７０を利用して、単一のＴＣＰ／ＩＰを開いたままメッセージの迅速な交換を容易にする。より詳細に後述するように、かかる通信は、（１）クライアント装置の能力（例えば、ＯＳ、ウェブブラウザおよび３Ｇ、４Ｇ、ＷｉＦｉ、ＬＡＮ等の接続タイプ）に関する初期情報を仮想ブロードキャストサーバー３００へ提供する（２）オーバーレイネットワーク１００を介したビデオセグメントの次のＷｅｂＲＴＣ２２２のノード間のストリーミングのためのクライアントノードの接続性の検証を仮想ブロードキャストサーバーに可能にする（３）（後述するようにパフォーマンス監視部２４０を介して取得された）リアルタイム動的監視情報を仮想ブロードキャストサーバー３００と交換するといったことを含む種々の目的のために使用される。

一の実施形態では、チャネルウェブページに含まれるこのジャバスクリプトコードはクライアント装置２００の能力を分析して、それが（ビデオセグメントを受信するがそれらを他のクライアントノードに中継しない）Ｃノードであるかどうかを判定し、この情報をシグナリングサーバー３３０に提供する。別の実施形態では、クライアント装置２００の特定の能力が仮想ブロードキャストサーバー３００に送信され、仮想ブロードキャストサーバー３００が、クライアント装置２００がＣノードであるかどうかを判定する。

このジャバスクリプトコードは、ＰＯＩコンテンツサーバー３８０との通信を容易にして、標準プレーヤー２３２による再生のための受信部２５０のビデオセグメントの受信を管理する。このプロセスは、事実上、標準ＷｅｂＲＴＣ２２２およびアダプティブストリーミング２２４の機能を活用する標準的なポイント・トゥ・ポイントビデオスストリーミングのシナリオの拡張である。

一の実施形態では、標準ウェブブラウザ２３０は、チャネルウェブページからプロプライエタリジャバスクリプトコードを解釈して、上述のように定期的にマニフェストファイルを要求する。このような標準ＨＴＴＰリクエストは、マニフェストファイルを提供するＰＯＩコンテンツサーバー３８０に向けられる。標準ウェブブラウザ２３０は、標準アダプティブストリーミング２２４ライブラリを活用して、上述のように、（例えば、帯域幅の変化が検出された時に）これらのビデオセグメントのより高いあるいはより低いビットレートのバージョン含むマニフェストファイル内の指定された場所からビデオセグメント自体を要求する。

各ビデオセグメントは、オーバーレイネットワーク１００の他の（供給）ノードからクライアント装置２００にプッシュされるため（クライアント装置２００がＨＴＴＰ「プル」リクエストを開始する必要性が無いため）、ビデオセグメントに対するこれらのリクエストは、プロプライエタリジャバスクリプトによってチャネルウェブページから傍受される。（より詳細に後述される）一の実施形態では、１個あるいは複数の初期ビデオセグメントがクライアント装置にプッシュされて、できるだけ早くビデオコンテンツの再生を開始できるように、仮想ブロードキャストサーバー３００は、参加リクエストが受信された直後にオーバーレイネットワーク１００に（したがってチャネルに）クライアント装置２００を追加する。

受信部２５０が各ビデオセグメントのチャンクを受信すると、ビデオセグメントの受信と再生および他のクライアントノードへのビデオセグメントの中継（クライアント装置２００がＣノードに指定されていない場合）を容易にするためにコンテンツアレイ２５５を生成する。受信部２５０は、標準プレーヤー２３２によって維持される３セグメントバッファーに供給される完全なビデオセグメントにチャンクをコンパイルする受信アレイ２５６を生成する。ビデオセグメントに対するＨＴＴＰリクエストが傍受されて、受信部２５０が完全なビデオセグメントが受信アレイ２５６に無いと判断した場合には、ビデオセグメントがマニフェストファイル（すなわち、ＰＯＩコンテンツサーバー３８０）により指定された代替（あるいはフォールバック）位置から要求される。標準プレーヤー２３２の観点からは、これは標準ＨＴＴＰリクエストに応答してビデオセグメントを受信し、ビデオセグメントがオーバーレイネットワーク１００を介してクライアント装置２００に実際にプッシュされていることには気付かない。

さらに、一の実施形態では、受信部２５０は、アダプティブストリーミング２２４ライブラリを活用して、クライアント装置２００が処理できるビットレートを（通信部２７０を介して）シグナリングサーバー３３０に通信する（標準プレーヤー２３２が通常の方法でマニフェストファイルを介してそのようなリクエストを行うかどうかにかかわらず）。例えば、クライアント装置２００が一時的な著しい帯域幅の低下を経験した場合（ビデオセグメントが必要となる前に受信アレイ２５６に到着しない結果となる）、それは、１個の（フォールバック）ビデオセグメントをＰＯＩコンテンツサーバー３８０から要求し、オーバーレイネットワーク１００を介して次の低解像度のビデオセグメントがプッシュされる。そのビットレートが正常に戻ったら、問題の発生前と同様に、高解像度のビデオセグメントがプッシュされる。

上述したように、一の実施形態では、仮想データトランクオーバーレイネットワーク（ＡＳＮ内およびＡＳＮ間のＡノード間）およびスワームオーバーレイネットワーク（ＡＳＮ内の各ＡノードからそのＡＳＮ内の他のノード）を含んで、仮想ブロードキャストサーバー３００は、各ビデオセグメントに対してオーバーレイネットワーク１００を動的に再構成する。クライアント装置２００が（ビデオセグメントを受信するが他のクライアントノードにこれらを中継しない）Ｃノードに分類されない限り、中継部２６０は、そのビデオセグメントを中継する１個あるいは複数のノードに関して、仮想ブロードキャスト３３０から（参加したビデオチャネルの各ビデオセグメントについて）命令を受信する。図１を参照して上述したように、クライアント装置２００がＡ、Ｂ：ＡあるいはＢノードであるかどうかにかかわらず、それは、複数の他のクライアントノードへのビデオセグメントを中継するように要求されることがある。

ビデオセグメントの長さ（例えば、１〜１０秒）は、アダプティブストリーミング２２４規格に従ってビデオコンテンツの発信元により定義される。中継部２６０は、（シグナリングプロトコルを要求しない）ＷｅｂＲＴＣ２２２の「ＲＴＣデータチャネル」コンポーネントに従ってチャンクをプッシュすることで、指定された目的地の各クライアントノードにビデオセグメントを中継する。

一の実施形態では、各ビデオセグメントは、ＭＰＥＧ２転送プロトコルを介してストリーミングされる際に最大の効率を得るために、ＵＤＰデータグラム（「パケット」）のサイズに一致するように６４ＫＢのチャンクに分割される。クライアント装置２００は、（ＷｅｂＲＴＣ２２２規格に従って必要に応じてＴＣＰに戻って）一度に１個のチャンクのＵＤＰ「パケット」を送受信する。例えば、１秒のビデオセグメントは、およそ６２５のチャンクを含む（約５０００Ｋｂｐｓを生成する１０８０ｐＨ２６４エンコーダーを想定）。

受信部２５０は各ビデオセグメントのチャンクを受信すると、これらのチャンクをコンパイルする受信アレイ２５６を生成して、完全なビデオセグメントを構築する。中継部２６０は、指定された目的地のクライアントノードに送信（中継）する目的で、これらのチャンクをコンパイルする中継アレイ２５７を生成する。このようにして、中継アレイ２５７は、ビデオセグメントの着信および発信チャンクに対するバッファーとして機能する。後述するように、パフォーマンス監視部２４０は、指定された目的地の各クライアントノードに全てのビデオセグメントをストリーミングするのに要する時間を追跡し、（オーバーレイネットワーク１００を動的に再構成するのに次に使用するために）その測定結果を仮想ブロードキャストサーバー３００に報告する。

一の実施形態では、受信クライアントノードは、クライアント装置２００のような単一の供給ノードからビデオセグメントを受信する。別の実施形態では、複数の潜在的な供給ノードが仮想ブロードキャストサーバー３００によって選択され、それらは相互間で通信を行って、（例えば、現在の帯域幅や他の監視されたパフォーマンス測定基準に基づいて）「上位２個」の候補を取り決めて、指定された受信クライアントノードに交互にチャンクを送信する。

別の実施形態では、各ビデオセグメントの複数の異なる解像度（例えば、１０８０ｐ、７２０ｐおよび４８０ｐ）がＡノードの間でプッシュされ、仮想ブロードキャストサーバー３００は、各スワームオーバーレイネットワークのルートのＡノードに、そのスワームオーバーレイネットワーク内の他のノードにプッシュするための解像度を指示する（例えば、後に詳述するように、これら他のノードの能力に基づいて）。

受信部２５０が再生のためのビデオセグメントのチャンクを受信し、中継部２６０が他の指定されたクライアントノードにこれらのチャンクをストリーミングしている間に、パフォーマンス監視部２４０は、仮想ブロードキャストサーバー３００から指示された種々の静的およびリアルタイムの動的なパフォーマンスメトリックを収集し、シグナリングサーバー３３０を介して仮想ブロードキャストサーバー３００にこのようなメトリックを継続的に返す。

上述のように、このようなメトリックは、次のビデオセグメントのルーティングを最適化するために、オーバーレイネットワーク１００を動的に再構成するのに仮想ブロードキャストサーバー３００によって使用される。特に、クライアントノードを分類および再分類して、ビデオセグメントを他のクライアントノードに中継するためのスロットを割り当ておよび割り当てを解除し、他のクライアントノードに受信および中継できるビデオセグメントの解像度を決定し、最終的には、オーバーレイネットワーク１００が動的に再構成された際のクライアントノード間のルーティング経路のサブセットを修正するために、パフォーマンスメトリックは使用される。仮想ブロードキャストサーバー３００によってこれらのパフォーマンスメトリックが使用される正確な方法は、図３を参照しつつより詳細に後述される。

オペレーティングシステム、ブラウザおよび接続（例えば、３Ｇあるいは４Ｇセルラー、ＷｉＦｉ、ＬＡＮ等）といった静的なパフォーマンスメトリックは、頻繁に変化する可能性が低く、（例えば、３Ｇから４Ｇへのセルラー接続の変更といったイベントの変化の場合にはそれらは報告されるが）、通常はクライアント装置２００による最初の参加リクエストの際にのみシグナリングサーバー３３０に報告される。

動的な情報は収集され、連続して（すなわち、収集されたときに）報告されるが、「オーバーヘッド」（これら動的なメトリックを監視してシグナリングサーバー３３０に報告する頻度）がビデオ自身の「ペイロード」あるいは配信のパフォーマンス（すなわち、クライアント装置２００へおよびクライアント装置２００からのチャンクのストリーミング）に影響しないことを保証するために、一の実施形態では様々なトレードオフが考慮される。一の実施形態では、このようなメトリックは、次のビデオセグメントに対してのみ使用され、別の実施形態では、現在のビデオセグメントの配信の間に、次の１個のチャンク（あるいは複数のチャンク）に対して変更を行うことができる。

一の実施形態では、２つのタイプの動的なパフォーマンスの監視が実行される。第１の方法は、クライアント装置２００が存在するＡＳＮ内およびＡＳＮ間の両方で、インターネット上の既知のサイト（例えば、ヤフーウェブサーバー、仮想ブロードキャストサーバー等）に対する「ピング」時間（あるいは、他の類似した測定値）を伴う。このようなメトリックは、個別には、クライアント装置２００のパフォーマンスについての洞察を提供し、集合的には、クライアント装置２００が存在するＡＳＮ内および特定のピアリングポイントを介したＡＳＮ間の両方のＱｏＳに対する追加の洞察を提供する。（Ａノード間の）仮想データトランクオーバーレイネットワークは、（ピアリングポイントでの輻輳のために）比較的大きな懸念事項であるが、ＡＳＮ内の輻輳も関連する（例えば、ＡＳＮ内のスワームオーバーレイネットワークの少なくとも１箇所あるいは複数個所の動的な再構成が必要な場合等）。

動的なパフォーマンスを監視する他のタイプは、１個のクライアントノードからもう１個へビデオセグメントを中継するのに要する合計時間を伴う。一の実施形態では、各ノード（Ｃノードは除く）は、指定された目的地のクライアントノードにビデオセグメントの最初のチャンクを送信したときの「開始」時間と、ビデオセグメントの最後のチャンクが受信されたときの「停止」時間（例えばＷｅｂＲＴＣ２２２規格は各パケットの検証を提供するので）とを記録する。パフォーマンス監視部２４０は、（それが送信した各ビデオセグメントについて）この合計時間をシグナリングサーバー３３０に送信する。このメトリックは、クライアント装置２００の個々のパフォーマンスに関する洞察のみならず、そのＡＳＮ内およびＡＳＮ間（例えば、クライアント装置２００がＡＳＮピアリングポイントを介して他のＡノードに供給するＡノードの場合）の両方の輻輳レベルに関する洞察も提供できる。

一の実施形態では、クライアント装置２００のユーザーは、ビデオコンテンツの発信元であってもよい。ほとんどの場合、このシナリオは、「いつでもどこでも」ビデオイベントのキャプチャーをユーザーに可能にする（カメラ２１９のような）スマートフォンカメラの品質が常に向上している結果である。しかしながら、スマートフォンと同様にデスクトップあるいはラップトップコンピューターのユーザーも、他のソースから事前録画されたビデオイベントを取得することができる。

問題は、クライアント装置２００が何らかの形でインターネットを介して仮想ブロードキャストサーバーにそのビデオコンテンツをストリーミングしなければならず、それは、複数のＡＳＮを跨いで離れた多くのホップとなる可能性がある。アップロード部２８０は、ＵＤＰパケットが中間のルーターにより遅延あるいはブロックされるのを防ぐために設計されたプロプライエタリ「シャワーイング」プロトコルによってこの問題に対処する。一の実施形態では、アップロード部２８０は、より限定されたクライアント側のジャバスクリプトの機能に頼るのではなく、専用のスマートフォンアプリケーションを介してクライアント装置２００に実装される。

このシャワーイングプロトコルを実装するために、アップロード部２８０は、仮想ブロードキャストサーバー３３０とＴＣＰ／ＩＰ接続を確立し、利用可能な最大のＩＰパケットサイズ（「Maximum Transmission Unit」あるいはＭＴＵ）を配信するためにＵＤＰ「バースト」を利用する。しかし、連続したＵＤＰストリーミングは（単一のルーターポートを経由して送信されたものでも、あるいは複数のルーターポート間での分散型であろうと）しばしば中間ルーターによって「サービス妨害」（ＤＯＳ）攻撃として検出され、ブロックされる。さらに、そのようなＵＤＰストリーミングは、（より一般的なＴＣＰパケットとは対照的に）ルーターが通常それらが受信されている間のみＵＤＰパケット用のメモリーを割り当てるため、ルーターの割り当てられたメモリー（例えばＦＩＦＯキュー）をオーバーフローさせる可能性がある。

これらの障害に対処するために、アップロード部２８０は、複数のポート（例えば、一の実施形態では６個のポート）にＵＤＰパケットを配信するだけでなく、ＤＯＳ攻撃として検出されないように個々のポートで送信されるパケットを遅延させる。一の実施形態では、各ポートでの遅延は、ＤＯＳ攻撃としての検出を避けるのに十分長く、ルーターが十分なメモリーを割り当てることを可能にするのに十分長いが、複数のＡＳＮに渡ってビデオセグメントを配信するのに十分な帯域幅を提供するのに十分短く、ＵＤＰストリーミングの最後として認識されるのを避けるのに十分短い（これは、ルーターがＵＤＰパケット用のメモリーの割り当てを停止し、実質的に捨て去る原因となる）。

アップロード部２８０がこのようにして仮想ブロードキャストサーバー３００に各ビデオセグメントを配信すると、仮想ブロードキャストサーバー３００は、より伝統的なＣＤＮから受信したかのように、オーバーレイネットワーク１００に沿ってこのビデオコンテンツを再配信するチャネルを生成する。別の実施形態では、仮想ブロードキャストサーバー３００は、それが現在のビデオセグメントがオーバーレイネットワーク１００に沿って時間内に到着しなかったクライアントノードに対するビデオセグメントのフォールバック起点ソースであるといった比較的稀なシナリオで、このプロプライエタリーシャワーイングプロトコルを使用する。
仮想ブロードキャストサーバー

図３は本発明の仮想ブロードキャストサーバー３００の主要なサーバー側の構成要素の一の実施形態を示す。上述のとおり、仮想ブロードキャストサーバー３００の構成要素は単一の物理的なハードウェアサーバー内に示されているが、本発明の精神から逸脱することなく、これらの構成要素の機能は、複数の異なる物理的なハードウェア装置および異なるソフトウェアモジュールの間で割り当てることができる。

仮想ブロードキャストサーバー３００は、例えば、ＣＰＵ３１２、メモリー３１４、オペレーティングシステム３１６、ネットワークアダプター３１７およびディスプレイ３１８といったほとんどのハードウェアサーバーに見られる標準ＨＷ／ＳＷ３１０のような特定の標準的な機能を含む。特定の実施形態では、仮想ブロードキャストサーバー３００は、（１）クライアントノードがビデオを他のクライアントノードと送受信して、仮想ブロードキャストサーバー３００との接続を確立できるように、ＮＡＴファイアーウォールの背後のクライアント装置２００のパブリックＩＰアドレスの発見を容易にするＳＴＵＮ３２２プロトコル（Session Traversal Utilities for NATs）（２）単一のＴＣＰ／ＩＰ接続を介した高速な双方向のクライアント−サーバー通信を容易にするＷｅｂＳｏｃｋｅｔ３２６プロトコル（３）標準ＨＴＭＬ５ウェブブラウザ２３０のようなクライアントウェブブラウザとの頻度の低い標準的な通信に使用されるＨＴＴＰ３２８を含む標準ライブラリ３２０も活用する。

仮想ブロードキャストサーバー３００は、クライアントノードから得られるパフォーマンスメトリックを継続的に分析し、オーバーレイネットワーク１００に沿ったこれらクライアントノードの間で配信されるビデオコンテンツのチャネルのためのルーティング経路を動的に再構成するものの、オーバーレイネットワーク１００上のクライアントノードではないため、ＷｅｂＲＴＣ２２２およびアダプティブストリーミング２２４規格をサポートする必要がない。

仮想ブロードキャストサーバー３００は、オーバーレイネットワーク１００、特に仮想データトランクオーバーレイネットワークの「チャネル発信元」の起点として機能する。一の実施形態では、ＰＯＩコンテンツサーバー３８０は、ビデオセグメントに対するＨＴＴＰリクエストを発行するために、（可能であれば好ましくはそのＡＳＮ内の）１個あるいは複数の近くのＡノードを指定する。これらのＡノードは、仮想データトランクオーバーレイネットワークのルートとして事実上機能し、各ビデオセグメントをＡＳＮ内およびＡＳＮ間で他のＡノードにプッシュし、最終的に各ＡＳＮ内のスワームオーバーレイネットワークを介して他のノードにプッシュする。

ＰＯＩコンテンツサーバー３８０を参照しつつより詳細に後述するように、このような「チャネル発信元」の機能は、ブラウザ・トゥ・ブラウザビデオストリーミングを対象とする標準ＷｅｂＲＴＣ２２２およびアダプティブストリーミング２２４ライブラリの使用を必要としない。上述のように、ＰＯＩコンテンツサーバー３８０は、オーバーレイネットワーク１００に沿って現在のビデオセグメントを時間内に受信していないクライアントノードのために、ビデオセグメントの臨時の代替（フォールバック）ソースとしても機能する。このようなクライアントノードは、ＨＴＴＰリクエストを発行し、ＰＯＩコンテンツサーバー３８０は、要求されたビデオセグメントをそれらに送信することで、これに応答する。

上述したように、ビデオコンテンツがアップロード部２８０を介してあるいはより伝統的なＣＤＮを介してクライアント装置２００から得られたかにかかわらず（また、それがリアルタイムで仮想ブロードキャストサーバー３００にストリーミングされたか、あるいは後のストリーミングのために予め提供されたかにかかわらず）、ＰＯＩコンテンツサーバー３８０は、全てのビデオチャネル（一の実施形態では）の起点として機能する。

チャネル管理部３８５は、各チャネルの設定および維持を担当し、ＰＯＩコンテンツサーバー３８０はクライアントノードへのチャネルとしてストリーミングするためのビデオコンテンツ自身を準備する。一の実施形態では、チャネル管理部３８５は、インターネットを介してＰＯＩコンテンツサーバー３８０により配信されるチャネルウェブページを生成して維持し、特定のチャネルに参加しようとするクライアント装置２００からの参加リクエストに応答する際に、シグナリングサーバー３３０によって使用する。

サポートの目的で、チャネル特有および地域特有の問題（例えば、特定の地理的領域から生じるサポートコール）に対処できるように、クライアント装置２００が問題を経験している個々の視聴者をサポートする「視聴者サポートコンソール」と、全てのビデオチャネルをライブで監視する「プレイアウトセンター」とがチャネル管理部３８５によって確立されて維持される。これらのサポート機能にならびにビデオセグメントの発信元（例えばＣＤＮ）にとって有用なデータを供給するために、チャネル管理部３８５によって「チャネル解析」のリアルタイムの監視も維持される。例えば、解析は、オーバーレイネットワーク１００に沿った各ビデオチャネルやネットワークノードの現在の状態、ならびにビデオビットレート、輻輳ポイント、ノード待ち時間等に関するラストマイルおよび他の問題に関するリアルタイムのメトリックを含む。

最終的に、「チャネル管理」の機能は、クライアント装置２００との通信を容易にするために必要な現在の情報を有するように（例えば、チャネルへの参加、クライアントに監視されたパフォーマンスメトリックの提供、ルーティングや中継対象についての解像度あるいはビットレートの変化等に関して）、ビデオチャネルやシグナリングサーバー３３０とのインターフェースを管理するために提供される。

図３に示す残りのサーバー側の機能は、スプラッシュ抽出部３９０を除いて、単純化のために、ビデオコンテンツの単一チャネルの状況で説明する。しかしながら、一の実施形態では、この機能は、複数のチャネルに対していつでも、そして種々のデジタルコンテンツに対して同時に実行されることに留意されたい。

クライアントノードがビデオチャネルにアクセスする前に、ビデオコンテンツはトランスコードされて、複数のより解像度の低いビデオセグメントのストリームが作成される。一の実施形態では、ＰＯＩコンテンツサーバー３８０は、クライアント装置２００内の標準ＨＴＭＬ５ウェブブラウザ２３０と通信できるＨＴＴＰ２２８サーバーとして実装される。頻繁な双方向通信（例えば、経路の変化やパフォーマンスデータ等の交換）のためにクライアント装置２００とのＷｅｂＳｏｃｋｅｔ２２５通信を確立するシグナリングサーバー３３０とは異なり、ＰＯＩコンテンツサーバー３８０は、マニフェストファイルや、オーバーレイネットワーク１１０を介して時間内に到達しなかった臨時のビデオセグメント等のために、標準ＨＴＭＬ５ウェブブラウザ２３０からの比較的まれなクライアントＨＴＰ２２８リクエストに応答する。

上述のように、ＰＯＩコンテンツサーバー３８０はまた、（仮想データトランクネットワークのルートにある、典型的にはＰＯＩコンテンツサーバー３８０として同じＡＳＮ内にある、あるいは１個あるいは２個のホップ以内にある）近くのＡノードからのビデオセグメントに対するＨＴＴＰリクエストに応答することで、より高い帯域幅のチャネル発信機能を実装するために、ＨＴＴＰ２２８プロトコルにも依存している。別の実施形態では、これらのビデオセグメントは、ＷｅｂＲＴＣ２２２およびアダプティブストリーミング２２４規格に従って、あるいは他のビデオストリーミング技術（上述のようにアップロード部２８０を使用したシャワーイングプロトコルを含む）を介して、これらのＡノードにプッシュされる。

一の実施形態では、ＰＯＩコンテンツサーバー３８０は、ビデオコンテンツを３つの異なる解像度（１０８０ｐ、７２０ｐおよび４８０ｐ）にトランスコードし、別の実施形態では、全てのビデオコンテンツのための単一の固定された解像度を含む、様々な他のより高いおよびより低い解像度（例えば、４Ｋ、３０ＶＲ、１８０ＶＲ、２４０ｐ等）がサポートされる。元のソースビデオがより低い解像度（例えば、７２０ｐ）で提供される場合、そのビデオチャネルに対しては、７２０ｐおよび４８０ｐの解像度のみがサポートできる。この機能は、（上述のように）クライアントノードによって開始されようと、クライアントパフォーマンスメトリックの解析に基づき仮想ブロードキャストサーバー３００によって開始されようとも、アダプティブビットレートストリーミングを容易にする。

一の実施形態では、ＰＯＩコンテンツサーバー３８０は、ＨＴＴＰリクエストに応答して、オーバーレイネットワーク１００に沿って各ビデオセグメントのプッシュを開始する１個あるいは複数の近傍のノード（通常はＡノード）に各ビデオセグメントの全ての利用可能なバージョン（例えば、３つの異なる解像度）を提供することで、チャネルを開始する。別の実施形態では、これらのノードは、全てのノードがアダプティブストリーミング２２４機能を活用できるように、全てのバージョンをＢノード（およびＢ：Ａノード）に中継して最終的にはＣノードに中継する。より詳細に後述するように、他のノードに複数の解像度を中継するノードは、ビデオセグメントのこれら複数のバージョンを、オーバーレイネットワーク１００を介して他のクライアントノードに「ポリキャスト」する。

ＰＯＩコンテンツサーバー３８０は、（ＨＴＴＰに応答して）１個あるいは複数の近傍のノードにビデオセグメントを提供することでチャネルを開始し、全てのクライアント視聴ノードは実質的に同時に各ビデオセグメントを受信して視聴する、すなわち、先のビデオセグメントの再生が終了する前に各ビデオセグメントがオーバーレイネットワーク１００を横断するという条件で、それらは全て同期している点に留意されたい。この実施形態では、クライアント装置２００は少なくとも３個のビデオセグメントをバッファーするため、このバッファーは、ビデオセグメントがときどき遅延する場合に、ある程度の「許容誤差」を提供する。さらに、別の実施形態では、ＰＯＩコンテンツサーバー３８０が最初にチャネルを「ブロードキャスト」する際に、チャネルの開始を遅らせて、追加のバッファリングを提供することができる。クライアント装置２００がフォールバックＰＯＩコンテンツサーバー３８０から直接ビデオセグメントを求めるリクエストを発行すると（例えば、ビデオセグメントがオーバーレイネットワーク１００を介して時間内に到着しないために）、ビデオセグメントが１個あるいは複数のＡＳＮを横切る場合には、そのバッファーが必要となることがある。

上述のように、ＰＯＩコンテンツサーバー３８０はまた、クライアント装置２００からのリクエストに応答して、マニフェストファイルを定期的に提供する。これらのマニフェストファイルは標準ＨＴＴＰ３２８プロトコルを介して配信されるが、それらは比較的小さくビデオセグメントよりもはるかに時間がかからない。一の実施形態では、各マニフェストファイルは、様々な利用可能なビットレートでの次の８個のビデオセグメントの位置を特定する。この実施形態では、ビデオセグメントがオーバーレイネットワーク１００を介して各クライアント装置２００にプッシュされるため、位置はＰＯＩコンテンツサーバー３８０上のフォールバック位置である。

ビデオコンテンツのチャネルがストリーミングする（ＰＯＩコンテンツサーバー３８０で開始する）ために準備されると、シグナリングサーバー３３０はクライアント装置２００からの参加リクエストを待つ。クライアント装置２００からそのチャネルに対する参加リクエストを受信すると、シグナリングサーバー３３０はＳＴＵＮ３２２プロトコルに頼って、そのクライアント装置２００に存在する可能性のある任意のＮＡＴファイアーウォールを介してＷｅｂＳｏｃｋｅｔ３２６接続を確立できることを保証する。さらに、クライアント装置２００のパブリックＩＰアドレスを識別することで、パブリンクＩＰアドレスを他のクライアントノードに提供できる（例えば、そのクライアント装置２００にビデオセグメントを中継するために）。

ＷｅｂＳｏｃｋｅｔ３２６接続が確立すると、クライアント装置２００は、一の実施形態では、クライアント装置２００がＣノードであるかどうか（例えば、この実施形態ではセルラー接続のために想定される）を含むその能力（例えば、ＯＳ、ウェブブラウザおよび３Ｇ、４Ｇ、ＷｉＦｉ、ＬＡＮ等の接続タイプ）に関する情報をシグナリングサーバー３３０に提供する。クライアント装置２００はまた、オーバーレイネットワーク１００にクライアント装置２００を追加するために後に使用されるそのＡＳＮ位置をシグナリングサーバー３３０に提供する。

一の実施形態では、シグナリングサーバー３３０は、チャネルのビデオコンテンツの再生をできるだけ早く開始できるように、（オーバーレイネットワーク１００を介して）１個あるいは複数の最初のビデオセグメントのクライアント装置２００への配信を優先する。このプロセスを開始するために、それはオーバーレイネットワーク生成部３５０に制御を移し、オーバーレイネットワーク生成部３５０は、（例えば、クライアント装置２００にビデオセグメントを中継するそのＡＳＮ内のＢノードを指示することで）、そのＡＳＮ内のスワームオーバーレイネットワークにクライアント装置２００を追加する。クライアント装置２００はまだ分類されておらず、他のクライアントノードにビデオセグメントを中継していなことに留意されたい。しかしながら、オーバーレイネットワーク１００の一部であることで、クライアント装置２００は、ビデオセグメントの受信およびチャネルのビデオコンテンツの再生を開始でき、その分類を容易にするクライアントパフォーマンスメトリックを収集できる。

次に、シグナリングサーバー３３０は、（ＷｅｂＳｏｃｋｅｔ３２６接続を介して）クライアント装置２００のアップストリームおよびダウンストリームの帯域幅を取得する。（シグナリングサーバー３３０がクライアント装置２００のＡＳＮ位置を知っていても）コネクションは複数のＡＳＮを通過する可能性があるので、このメトリックはあまり有用でないことに留意されたい。より関連性のあるメトリックは、クライアント装置２００とそれ自身のＡＳＮ内の他のクライアントノードとの間の通信に関係する。

（クライアント装置２００のパフォーマンス監視部２４０によって収集された）クライアントパフォーマンス情報をクライアント装置２００（および他のクライアントノード）から受信すると、シグナリングサーバー３３０は、後述するように、次のビデオセグメントのためにクライアントノードを動的に再分類してオーバーレイネットワーク１００を動的に再構成する際のオーバーレイネットワーク生成部３５０およびディープマッパー３６０による初期分析および次の利用のために、その情報をパフォーマンス追跡部３４０に転送する。パフォーマンス追跡部３４０は各クライアントノードのパフォーマンスを監視して、クライアントノードがまだ「生きている」かどうかを判定する。例えば、クライアント装置２００が接続を閉じてチャネルから離れている、あるいは閾時間内に「ピング」に応答しない場合は、（意図的であるか、ハードウェアあるいはソフトウェアの障害の結果であるかにかかわらず）それはチャネルを去ったと見なされる。パフォーマンス追跡部３４０はまた、履歴パフォーマンスデータベース３４５に記憶して、オーバーレイネットワーク生成部３５０およびディープマッパー３６０で使用するのに適切なフォーマットにクライアントパフォーマンスメトリックを変換する。

一の実施形態では、オーバーレイネットワーク生成部３５０はまた、ディープマッパー３６０の助けを借りて、現在および過去のクライアントパフォーマンスメトリック（履歴パフォーマンスデータベース３４５に維持される）を評価する連続的なプロセスを担当し、各ビデオセグメントについて動的に（１）クライアントノードを再分類し、（２）（ＡＳＮ内およびＡＳＮ間のＡノードの間でビデオセグメントを中継するための）仮想データトランクオーバーレイネットワークおよび（ＡＳＮ内の各Ａノードから、そのＡＳＮ内の特定の他のＢ：Ａ、ＢおよびＣノードにビデオセグメントを中継するための）スワームオーバーレイネットワークを含むオーバーレイネットワーク１００を生成して再構成することで、ルーティング経路を最適化する。オーバーレイネットワーク１００のトポロジーは、オーバーレイネットワーク生成部３７５およびディープマッパー３６０の使用のために、オーバーレイネットワークデータベース３７５に維持される。

新たに追加されたクライアント装置２００から受信されたパフォーマンスメトリックに関して、オーバーレイネットワーク生成部３５０は、クライアント装置２００を最初に分類するためにこれらのメトリックを利用する。一の実施形態では、このプロセスは、（単にそれらがチャネルに参加するときではなく）全てのビデオセグメントについてクライアントノードを潜在的に再分類するためにも使用される。クライアントノードは通常頻繁には再分類されないが、クライアントは、（例えば、家庭用のマイクロ波あるいは他の干渉からの）帯域幅の一時的な低下を経験することがある。また、（例えば、冗長性あるいはチャネルを離れるクライアントノードのために）より多くのＡノードが必要とされると、Ｂ：ＡノードはＡノードに昇格しうる。ＡＳＮ内あるいはＡＳＮ間で検出された他の問題は、特定のノードの再分類を要求する可能性がある。

オーバーレイネットワーク生成部３５０は、クライアント装置２００の着信および発信スロット（すなわち、ネットワークポート）に割り当てられ、他のクライアントノードからプッシュされたビデオセグメントのチャンクを（着信スロットを介して）受信して、ビデオセグメントのそれらのチャンクを（発信スロットを介して）他のクライアントノードに中継（プッシュ）できる。ＷｅｂＲＴＣ２２４規格は、着信および発信ポート（スロット）をサポートするが、一の実施形態では、（クライアント装置２００で再生可能なビデオコンテンツの質を最大化するために）単一の着信スロットだけが割り当てられ、（オーバーレイネットワーク１００に沿ったスループットを最大化して、クライアント装置２００と有限の帯域幅との接続を広範囲にサポートするために）最大８個の発信スロットが割り当てられる。上述のように、Ａノードは、ＡＳＮピアリングポイントを介して他のＡノードにビデオセグメントを中継するための４個の発信スロットと、そのＡＳＮ内の他のＡノードにビデオセグメントを中継するための４個の発信スロットとに割り当てられる。後述するように、与えられた時点で全ての割り当てられたスロットが必ずしも使用されるわけではない。

オーバーレイネットワーク生成部３５０は、クライアント装置２００のダウンストリームおよびアップストリームの帯域幅を分析して、分類プロセスを容易にする。上述のように、クライアント装置２００がセルラー接続（３Ｇ、４ＧさらにはＬＴＥ）を介して参加すると、それは、ビデオセグメントを中継するには信頼性が低すぎると自動的に見なされ、したがってＣノードに分類される。別の実施形態では、そのような自動分類は、特定のセルラー接続（例えば、３Ｇ）に限定されてもよいし、全く無くてもよい。

一の実施形態では、オーバーレイネットワーク生成部３５０は、（１）ＬＡＮ接続（例えば、１００／１００）（２）ファイバー接続（１００／５０）（３）ＡＤＳＬ接続（１００／２０）、ケーブル接続（１００／１０）およびＷｉＦｉ接続（大幅に異なる）を含むさらなる分類を容易にするため、典型的なダウンストリーム／アップストリーム帯域幅（Ｍｂｐｓ）のカテゴリーを使用する。この実施形態では、クライアント装置２００が既にＣノードであると見なされておらず、少なくとも５０Ｍｂｐｓのアップストリーム帯域幅を有する場合、それはＡノード（あるいは、ディープマッパー３６０がそのＡＳＮ内に追加のＡノードが必要ないことを示す場合はＢ：Ａ）に最初分類される。それ以外の場合には、それはＢノードに分類される。

後述するように、オーバーレイネットワーク生成部３５０は、（一の実施形態では）クライアント装置２００のアップストリーム帯域幅をさらに分析して、オーバーレイネットワーク１００を動的に再構成すべき範囲（もしあれば）を決定する前に、利用可能な発信スロットの数を計算する。また、クライアント装置２００が複数の解像度を受信および／またはポリキャストできる範囲も決定する。

一の実施形態では、クライアントノードの全ダウンストリーム帯域幅は、その単一の着信スロットに対して利用され、そのアップストリーム帯域幅の３分の１だけが、その発信スロットの間でビデオセグメントを中継するために使用される。ビデオセグメントの中継がＴＣＰ／ＩＰおよびクライアント装置２００が他のアプリケーションのために使う他の接続を妨げるおそれがあるため、全てのアップストリーム帯域幅を使用はしない。

オーバーレイネットワーク生成部３５０は、（たとえＣノードに分類されていても）クライアント装置２００のダウンストリーム帯域幅を分析して、単一の着信スロットを介してサポートできる解像度の数を決定する。例えば、１０８０ｐが３Ｍｂｐｓのビットレートを必要とし、７２０ｐが１．５Ｍｂｐｓのビットレートを必要とし、４８０ｐが５００Ｋｂｐｓのビットレートを必要とする場合、クライアント装置２００は、３個の全ての解像度をサポートするためには少なくとも５Ｍｂｐｓのダウンストリーム帯域幅を必要とし、１０８０ｐおよび７２０ｐをサポートするためには少なくとも４．５Ｍｂｐｓを必要とし、１０８０ｐのみをサポートするためには少なくとも３Ｍｂｐｓを必要とし７２０ｐおよび４８０ｐをサポートするためには２Ｍｂｐｓを必要とし、７２０ｐのみをサポートするためには１．５Ｍｂｐｓを必要とし、４８０ｐのみをサポートするためには少なくとも５００Ｋｂｐｓを必要とする。一の実施形態では、５００Ｋｂｐｓ未満のビットレートはサポートされない。別の実施形態では、より低い解像度がサポートされてもよく、他の技術（例えば、より大きな圧縮や異なるビデオフォーマット等）を用いて帯域幅の要求を軽減してもよい。

上述したように、一の実施形態では、Ａ、Ｂ：ＡおよびＢノードは、１個あるいは複数の発信スロットを介して他のノードに複数の解像度を中継できるポリキャスティングノードと見なすこともできる。これに関して、オーバーレイネットワーク生成部３５０は、クライアント装置２００のアップストリーム帯域幅を分析して、それが他のクライアントノードに中継できる解像度の数を決定する。

この実施形態では、クライアントノードはアップストリーム帯域幅の３分の１のみを使用できるため、クライアント装置２００は、３個全ての解像度をポリキャストするためには（発信スロットあたり）少なくとも１５Ｍｂｐｓのアップストリーム帯域幅を必要とし、１０８０ｐおよび７２０ｐをポリキャストするためには（発信スロットあたり）１３．５Ｍｂｐｓを必要とし、１０８０ｐのみを送信するためには（発信スロットあたり）９Ｍｂｐｓを必要とし、７２０ｐおよび４８０ｐをポリキャストするためには（発信スロットあたり）６Ｍｂｐｓを必要とし、７２０ｐのみを中継するためには（発信スロットあたり）４．５Ｍｂｐｓを必要とし、４８０ｐのみを中継するためには（発信スロットあたり）１．５Ｍｂｐｓを必要とする。

クライアント装置２００は、受信できない解像度は中継できない。さらに、後述するように、クライアント装置２００のポリキャスティング能力は、他のクライアントノードが複数の解像度を受信する能力と併せて考慮される。しかしながら、上述のように、クライアント装置２００は、その帯域幅の大きな変化を経験すると、ビデオセグメントのより低いあるいはより高い解像度のバージョンを要求するアダプティブストリーミング２２４実装を使用する。もし、ビデオセグメントの複数の異なる解像度を受信すると、それは受信した最高の解像度を単に再生する。

クライアント装置２００がＣノードでないと仮定すると、オーバーレイネットワーク生成部３５０は、そのアップストリーム帯域幅を分析するともに、それが複数の解像度をポリキャストできる範囲を考慮することで、利用可能な発信スロットの数を計算する。例えば、１００Ｍｂｐｓのアップストリーム帯域幅を有するＬＡＮ接続を伴うＡノードにクライアント装置２００が分類されている場合、それは、そのＡＳＮ内およびＡＳＮ間の両方でビデオセグメントをポリキャストするのに約６個の発信スロットのみを使用できる。この実施形態では、オーバーレイネットワーク生成部３５０は、ＡＳＮ間で他のＡノードにポリキャストを行うのに４個のスロットを割り当て（これらＡＳＮ間のスロットを優先し）、そのＡＳＮ内で他のＡノードにポリキャスティングを行うために２個の残りのスロットを置いておく。別の実施形態では、これらの割り当ては、もちろん本発明の精神から逸脱せずに変更できる。

同様に、１０Ｍｂｐｓのアップストリーム帯域幅を有するケーブル接続を伴うＢ：ＡあるいはＢノードにクライアント装置２００が分類されている場合、それは、７２０ｐおよび４８０ｐのポリキャストあるいは１０８０ｐのみの送信に、１個の発信スロットのみを使用できる。一の実施形態では、（ノードがその解像度を受信できる範囲で）より高品質の解像度が優先され、したがって、１個のスロットが１０８０ｐのみに割り当てられる。ここでもまた、これらの割り当ては、本発明の精神から逸脱せずに変更できる。

クライアント装置２００を分類して、利用可能なスロットの数を決定すると（複数の解像度のポリキャストを含む）、オーバーレイネットワーク生成部３５０は、オーバーレイネットワーク１００を動的に再構成してルーティング経路を最適化する範囲を決定し、クライアント装置２００がＡノードの場合、オーバーレイネットワーク生成部３５０は（より詳細に後述するように）、最初にＡノード間の各ＡＳＮ間の経路の輻輳レベルをディープマッパー３６０から取得して、クライアント装置２００を組み込むために仮想データトランクオーバーレイネットワークの少なくとも一部を動的に再構成する。

例えば、（各経路が「輻輳レベル」の重みを有する）重み付けされた経路のセットが与えられると、オーバーレイネットワーク生成部３５０は、標準的な経路検出技術を用いて、Ａノード間でビデオセグメントを配信するための最適な経路を決定する（例えば、ＧＰＳナビゲーションのルーティングに類似している）。ただし、例えばＡＳＮ内のＡノードへ中継するＡノード用の４個の発信スロットと、ＡＳＮピアリングポイントを経由してＡノードに中継するＡノード用の４個の発信スロットといった複数の中継スロットを用いることで、このプロセスは若干複雑になることに留意されたい。しかしながら、これは、Ａノードが１個の発信スロットのみを有する最も単純なケースのわずかな変更である。言い換えれば、オーバーレイネットワーク生成部３５０は、仮想データトランクオーバーレイネットワークの生成あるいは再構成の間に、空いている（未使用の）スロットの数を追跡し、未使用の空いているスロットがなくなると、特定のＡノードを中継元として割り当てるのを停止する。

クライアント装置２００がＢ：ＡあるいはＢノードの場合、オーバーレイネットワーク生成部３５０は、クライアント装置２００が存在するＡＳＮ内におけるＡＳＮ内スワームオーバーレイネットワークの一部あるいは全部を動的に再構成する。そのＡＳＮ内に複数のＡノードがある場合、お互いの間のそれらの経路は、仮想データトランクオーバーレイネットワークの一部として決定されることに留意されたい。一の実施形態では、（仮に十分なスロットが利用可能でも）、スワームオーバーレイネットワークを生成するのに１個のＡノードのみが使用され、別の実施形態では、他のノードは複数のＡノードの間で等しく割り当てられてもよく、あるいは相対的なアップストリーム帯域幅もしくは他のメトリックに基づいて分配されてもよい。

ＡＳＮ内の任意の特定のＡノード、残りのＢ、Ｂ：ＡおよびＣノードに関して、これらのノードは、それらの分類（すなわち、Ｂ：Ａ、次にＢ、次にＣ）に基づき最初ランク付けされ、次にそれらの相対的な帯域幅（すなわち、上述のような利用可能なスロットの数）に基づいてランク付けされる。この実施形態では、各ノードが単一の供給ノードしか持たない場合、スワームオーバーレイネットワークは階層的であることに留意されたい。他の実施形態では、同様の技術を非階層的な「メッシュ」スワームに用いることができる。

この階層的スワームの実施形態では、特定個数の利用可能な発信スロット（例えば、２個の発信スロット）を有するルートのＡノードからプロセスが始まる。これらのスロットは、階層の次のレベルにルーティングされる（例えば、利用可能なスロットの数が最も多い２個のＢ：Ａノード）。これらの経路が決定されると、これらのノードの利用可能な発信スロットが、利用可能なスロットの個数が最も多い残りのＢ：Ａノードにルーティングされる。このプロセスは、全ての経路が決定されるまで、階層を下向きに（Ｂノードを通り、最後にＣノード）に進む。

任意のクライアントノード（例えば、それぞれ単一の発信スロットを有する１００個のクライアントノード）の下のチェーンの長さは、ＡＳＮ内のノード間での中継が比較的高速（１ミリ秒以下）であることを考えると、比較的ほとんど問題にならないことに留意されたい。１秒のビデオセグメントが与えられても、何百ものノードのチェーンに対応できる（ＡＳＮ内のこのような多くのノードは複数の送信スロットをサポートするであろうことから、それらは稀であるが）。全てのノードをスワーム内に含めることができない場合（例えば、利用可能なスロットが無いＣノードおよびＢノードが未確認のままであった場合）、そのＡＳＮ内に空いているスロットを有する追加のノードが必要となり、これらは利用可能となるとともに割り当てられる。その間に、このようなノードは、ＰＯＩコンテンツサーバー３８０からのビデオセグメントを要求するように指示される。

ＡＳＮピアリングポイントを経由する輻輳レベルを（例えば、次の１分について）予想して定量化するディープマッパー３６０に移る前に、ＡＳＮピアリングポイントの輻輳の重要性を理解するためにＢＧＰルーティングプロトコルの限界を理解することは有益である。ＢＧＰルーターは、「ルーティング時間」に輻輳を判断し、予測能力を有さない。それらは、自身のルーターと、ＡＳＮピアリングポイントから「１ホップ離れた」待ち時間のみを認識する。それらは、複数のＡＳＮピアリングポイントを経由して複数ホップ離れているかもしれない任意の最終的な目的地へのホップ数や待ち時間を認識していない。複数のＡＳＮピアリングポイントの選択肢が与えられると、それらは本質的に、その時点で最も利用可能な帯域幅を有する１個（すなわち、空いているスロットと１ホップ離れた最短の待ち時間を有する１個）を選択する。

対照的に、ディープマッパー３６０は、インターネットの下層のアーキテクチャの知識を活用する。一の実施形態では、ディープマッパー３６０は、図１で概略的に示された、（ＡＳＮおよびそれらの様々なピアリングポイントの相互接続を含む）インターネットのＡＳＮ相互接続マップを維持する。このマップは頻繁には変化しないが、一の実施形態では、このような稀な変化を５分ごとにキャプチャーする。

しかしながら、これらのＡＳＮ上に構築されたオーバーレイネットワーク１００は、（例えば、上述のクライアント側の監視を介して）頻繁に分析され、仮想ブロードキャストサーバー３００によってビデオセグメントごとに（例えば、一の実施形態では毎秒）に再構成される可能性がある。しかしながら、実際には、オーバーレイネットワーク１００は、必要なときにのみ、例えば新たなノードが参加あるいはチャネルから離れるときのみならず、（現在情報および履歴パフォーマンスデータベース３４５に維持される履歴情報に基づき）重大な問題が検出されたときに、実際に修正される。

例えば、一の実施形態では、複数の固有の「輻輳閾値」が用いられる。特定のクライアント装置２００あるいはＡＳＮ内に比較的低い輻輳の閾値を最初に検出すると、オーバーレイネットワーク生成部３５０は、クライアント装置２００あるいはＡＳＮを単に「マーク」して、（例えば次のビデオセグメントで）問題が繰り返されるのを待つ。繰り返されれば、そのクライアントノード（あるいは、その「問題」のＡＳＮ内の全てのクライアントノード）に中継される次のセグメントの解像度（したがって、ビットレート）を低下させる。結果的に、問題が悪化した場合（例えば、より高い輻輳閾値を超える場合）、オーバーレイネットワーク１００の一部（例えば、ＡＳＮ内のサブセットＩＰレンジ）が動的に再構成される。最終的にＡＳＮ全体あるいはおそらく仮想データトランクオーバーレイネットワーク自体が動的な再構成を必要とする可能性がある。

いずれにしても、これらの輻輳閾値の目標は、ビデオセグメントの消失の要因となり、あるいはクライアントノードがＰＯＩコンテンツサーバー３８０のフォールバック位置からビデオセグメントを取得するのに頼る要因とさえなるより重大な問題に悪化する前に、先回りして問題を特定して修正することである。

インターネットのＡＳＮ相互接続マップおよびオーバーレイネットワーク１００上のノードのＡＳＮ位置の認識を維持し、これらのノードの現在および過去のパフォーマンスをリアルタイムで監視することで、ディープマッパー３６０は、任意のクライアントノードが遠くのクライアントノード（例えば、複数のＡＳＮピアリングポイントを経由して多くのホップ離れた）にビデオセグメントを不要に中継する可能性を最小化する。例えば、一の実施形態の最初の考慮すべき事柄として、仮想データトランクオーバーレイネットワークは、一のＡノードから、同一のＡＳＮ内あるいは単一のＡＳＮピアリングポイントを経由する近くのＡＳＮ内の他のＡノードにビデオセグメントを（可能であれば）ルーティングする傾向にある。

ただし、全てのホップが均等に作成されているわけではない。例えば、ディープマッパー３６０は、（履歴パフォーマンスデータベース３４５に維持されるクライアントパフォーマンスメトリックに基づいて）、「ＡＳＮ１」と「ＡＳＮ２」との間のピアリングポイントが輻輳していることを経時的に「学習」し、「ＡＳＮ１」から「ＡＳ３」を介して「ＡＳＮ２」に至る２ホップの経路が現在の１ホップの経路よりも実際に高速であると（あるいは、最近および過去の傾向に基づいて非常に近い将来高速になるであろうと）予測できる。ピアリングポイントを経由するＡノードの現在および過去の実際のパフォーマンスに基づいてピアリングポイントの輻輳を定量化することで、ディープマッパー３６０は、潜在的には全てのビデオセグメントについて、あるいは（固有の閾値に基づき）少なくともピアリングポイントの輻輳がそのような変更を必要とするときに、仮想データトランクオーバーレイネットワークのトポロジーの動的な再構成を容易にする。

一の実施形態では、ディープマッパー３６０は、（それらが同じＡＳＮに存在するか異なるＡＳＮに存在するかにかかわらず）、１が予想される短期間の輻輳の最小レベルであり、１０が最高である１から１０のスケールを用いて、Ａノードの各ペアについて輻輳を定量化する。上述のように、オーバーレイネットワーク生成部３５０は、この輻輳レベル「スコア」を用いて、Ａノード間の潜在的な異なる経路を比較して、最も効率的な経路（すなわち、「重み付けのホップ」が最も少ない経路）を決定する。その結果、ＰＯＩコンテンツサーバー３８０から（重み付けホップにおいて）最も「遠い」Ａノードは、ＰＯＩコンテンツサーバー３８０からそのようなＡノードに向けて仮想データトランクオーバーレイネットワークをビデオセグメントが横断するのに必要となる時間を最小にする。

一の実施形態では、Ａノードの各ペアについて、ディープマッパー３６０は一のＡノードから他への各経路について予測輻輳レベルスコアを生成し、次にＡノードのそのペアに対して適用される最低の輻輳レベルスコアを選択して、それをオーバーレイネットワーク３５０に返す。別の実施形態では、ディープマッパー３６０は、（一のＡノードから他への各経路について）平均値や中央値のような）これらの予測輻輳レベルスコアの異なる機能を生成する。

一の実施形態では、ディープマッパー３６０は、履歴パフォーマンスデータベース３４５に維持されるパフォーマンスメトリックを継続的に分析するディープラーニングエンジンであり、（例えば、１分後の）ＡＳＮピアリングポイントを経由する輻輳のレベルを予測する。任意のディープラーニングエンジンと同様に、ディープマッパー３６０は、ピアリングポイントを介するＡノード間のトラフィックに関して、複数の非線形変換を使用して、ＡＳＮピアリングポイントの動作をモデル化することに留意されたい。

上述のように、これらのピアリングポイントを横切るインターネットトラフィックの大部分を効果的に監視することはできないが、これらのピアリングポイントを介したＡノード間のＡＳＮ間のホップにおけるこれらのトラフィックが有する経時的影響のみである。より多くのパフォーマンスメトリックが得られるほど、このようなＡＳＮ間のホップに求められる時間をよりよく予測して、相対的輻輳レベルとして（例えば、この実施形態では監視されるが、通常輻輳が極めて少ないＡＳＮ内と比較して）定量化できる。

ピアリングポイントでの輻輳レベルは非常に動的であるので、このような予測は短期間でのみ正確である。しかしながら、この分析が継続的に行われ、次の１秒のビデオセグメントのために変更する可能性があるため、長期間において予想が正確であることは重要ではない。

一の実施形態では、ディープマッパー３６０は最初、非常に粗い情報（すなわち、クライアントパフォーマンスメトリックの多くが取得される前）に基づき、ＡＳＮピアリングポイントを定量化する。例えば、ＡＳＮが１０００個のピアリングポイントを有する場合、それは、６個のピアリングを持つ他のＡＳＮよりはるかに高速なバックボーンと見なすことができる。より多くのクライアントパフォーマンスメトリックが得られると、これらのＡＳＮピアリングポイントの輻輳レベルもより正確になる。別の実施形態では、複数の「学習ノード」が展開されて、新しいチャネルの「早い開始」が行われる。これらの学習ノードは、送信のみのノードでありビデオを視聴しないが、クライアントパフォーマンス情報を迅速に提供するためだけに展開されており、ディープマッパー３６０は、そうでない場合よりも早くてより正確な予測を開始できる。

さらに、一の実施形態では、ディープマッパー３６０は、ＡＳＮ内の輻輳も考慮しており、例えば、ＡＳＮ内の追加のＡノード、したがって追加のスワームオーバーレイネットワークの作成の必要性を提案できる。例えば、ＡＳＮ内の多くのクライアントノードが経時的にビデオセグメントの取得に徐々に長い時間を要するようになった場合、ディープマッパー３６０はそのＡＳＮをマークして、追加のＡノードが必要であることを示し、オーバーレイネットワーク生成部３６０は、１個あるいは複数のＢ：ＡノードをＡノードへと「昇格」させ、その結果、仮想データトランクオーバーレイネットワークを部分的に再構成し、ＡＳＮ内の新たなスワームオーバーレイネットワークを最終的に要求する。別の実施形態では、ディープマッパー３６０は、各ＡＳＮ内でディープラーニング技術を適用して、オーバーレイネットワーク生成部３５０がＡＳＮ内スワームオーバーレイネットワークを生成するのを支援する。

したがって、オーバーレイネットワーク生成部３５０およびディープマッパー３６０は、インターネットの下層のアーキテクチャ（ＡＳＮ相互接続マップ）およびこのアーキテクチャの上に重ねられたクライアントノードのＡＳＮ位置に基づき（オーバーレイネットワーク１００を介して）クライアントノード間で経路を確立するために協働して動作し、（例えば、複数のＡＳＮピアリングポイントを介した）不必要な遠い経路を介したビデオセグメントの中継を最小限に抑える。さらに、オーバーレイネットワーク生成部３５０およびディープマッパー３６０は、クライアント装置２００から取得されたクライアントパフォーマンスメトリックをリアルタイムに継続的に分析して、（しばしばＡＳＮピアリングポイントでの輻輳に起因する）重大な問題をこれらのメトリックが明らかにする場合にオーバーレイネットワーク１００を動的に再構成するために、協働して動作する。結果として、インターネットのＱｏＳの変動性を監視でき、（ディープマッパー３６０によって生成された予想された輻輳レベルに基づいて）そのような問題に対して「それらが起こる前に」動的に再ルーティングすることで、（特にＡＳＮピアリングポイントにおける）輻輳のクライアントノードへの影響を最小化できる。

一の実施形態では、仮想ブロードキャストサーバー３００は、トレンドのビデオイベント（スプラッシュ）を識別して、そのようなイベントのドメイン間で検索を行って、ＰＯＩコンテンツサーバー３８０からビデオチャネルとして所望のスプラッシュの結果を直ちにストリーミングすることをユーザーに可能とすることを目的とするスプラッシュ抽出部３９０サーチエンジンを含む（そのようなチャネルは他の形では仮想ブロードキャストサーバー３００から利用可能ではなかった）。

一の実施形態では、スプラッシュ抽出部３９０は、例えばＡＰＩを介して、ツィッター、ＲＳＳフィード、レディットおよび数万のオンラインマガジン等の複数のニュースソースから継続的にデータを収集する。平均して何千もの異なる「現在のイベント」がそのような情報ソースに毎時間現れる。スプラッシュ抽出部３９０は新規の自動化された方法を使用して、そのようなトレンドのイベント（スプラッシュ）を識別し、ＰＯＩコンテンツサーバー３８０を介して取得およびストリーミングが可能な関連するビデオを見つけて抽出する。

スプラッシュ抽出部３９０は、スプラッシュを検出するために「基準からの偏差」を識別する。例えば、ベースラインは（正規化されたデータを要せずに）例えば、ニュースソースのドメインの間において標準的なレーベンシュタイン比較アルゴリズムを用いることで開発される。平均して、特定の話題が実際にトレンドとなっている場合を除いて、同じ「話題」（すなわち、キーワードの集合）を短期間で議論するソースは数個以下である。その時点で（例えば、１５以上のソースが同じ話題を短期間に議論した時点で）、その話題が偏差、すなわちスプラッシュとして識別される。

スプラッシュ抽出部３９０は次に、一の実施形態では標準的なニューラルネットワーク技術を用いて、「スプラッシュ関連」記事から個別のキーワードを学習して予測することによって、これらのソースから「最重要」のキーワード（例えば、一の実施形態では４０個のキーワード）を抽出する。これらのキーワードは、（例えば、ニュース、スポーツ等として）分類され頻度によってランク付けされる。

スプラッシュ抽出部３９０は次に、これらのキーワードを使って、各スプラッシュに関連するビデオについてソーシャルメディアを検索し、これらの潜在的なスプラッシュビデオチャネルに関連する関連テキストに索引を付ける。ユーザーは、その索引を検索するか、スプラッシュビデオイベントの分類を単に参照することができる。（検索されたか参照されたかにかかわらず）結果を選択すると、ユーザーは所望のビデオを直ちにストリーミングできる。一の実施形態では、ユーザーは、ビデオの現在のソースに単純に接続され、別の実施形態では、ビデオは仮想ブロードキャストサーバー３００を介して取得されて、ＰＯＩコンテンツサーバーからストリーミングされる（多くの同時ユーザーが同じスプラッシュビデオチャネルを要求した場合に例えば有用である）。
動的ビデオストリーミングプロセス

本発明の仮想ブロードキャストシステムの主要なクライアント側およびサーバー側の構成要素について説明したが、図４のフローチャート４００はこれらの構成要素がどのように動的に相互作用するかを示す。言い換えれば、フローチャート４００は、そのような構成要素によって実施される本発明の動的ストリーミングプロセスの一の実施形態を示す。このプロセスの多くはイベント駆動型であり非線形であるので、フローチャート４００は、クライアント側とサーバー側の機能間の相互作用の観点からステップを示すことに留意されたい。

ステップ４０１は、アップロード部２８０（および上述）により実行されるプロセスを示し、ビデオイベントが、クライアントノード（例えば、クライアント装置２００上のスマートフォンカメラ２１９）によりキャプチャーされるか、またはデジタル的に生成されるか、または外部ソースから取得される。いずれにしても、クライアント（例えば、クライアント装置２００）は、そのビデオイベントのビデオセグメントを（ライブでキャプチャーされたか事前録画されたかにかかわらず）、仮想ブロードキャストサーバー３００にストリーミングする。

ビデオイベントが、クライアントから、あるいはより伝統的なＣＤＮから取得されるかにかかわらず（また、それらが事前録画されるかライブでストリーミングされるかにかかわらず）、上述のように仮想ブロードキャストサーバー３００はステップ４１０において、ＰＯＩコンテンツサーバー３８０からライブでストリーミングするために各ビデオチャネルを準備する。この時点で、一の実施形態では、チャネルのウェブページが生成されて、いずれは潜在的なクライアントノードに遭遇する。クライアント装置２００のユーザーが所望のチャネルをクリックすると、参加リクエストがクライアントの能力（オペレーティングシステム、ブラウザ、接続のタイプ等）とともにシグナリングサーバー３３０に送信される。あるいは、クライアント装置２００のユーザーは、（上述のように）トレンドのスプラッシュビデオイベントに遭遇し、ＰＯＩコンテンツサーバー３８０からビデオチャネルとしてストリーミングするために、そのビデオイベント（ステップ４１０）を選択することができる。

ステップ４１２では、シグナリングサーバー３３０は、（例えば、クライアントのパグリックＩＰアドレスを識別するＳＴＵＮ３２２プロトコルを用いて）チャネルに対するクライアントの接続性を検証し、次に、クライアントに存在する可能性のあるＮＡＴファイアーウォールを介してＷｅｂＳｏｃｋｅｔ３２６接続を確立し、その後に、そのクライアントにビデオセグメントを中継する他のクライアントノードにそのパブリックＩＰアドレスを提供する。シグナリングサーバー３３０は、オーバーレイネットワーク生成部３５０に制御を移し、オーバーレイネットワーク生成部３５０は、（未分類の）クライアントをノードとしてオーバーレイネットワーク１００に追加し、最初のビデオセグメントをそのクライアントにプッシュし（ステップ４１４）、ユーザーがビデオチャネルの視聴を直ちに開始できる（ステップ４１５）。

シグナリングサーバー３３０は、ステップ４１６において、クライアント装置２００をＡ、Ｂ：Ａ、ＢあるいはＣノードとして分類し、ステップ４３０において、オーバーレイネットワーク生成部３５０およびディープマッパー３６０を用いてＡＳＮ間（仮想データトランク）およびＡＳＮ内（スワーム）オーバーレイネットワーク１００を動的に再構成して、クライアント装置２００をネットワークトポロジーに組み込む。次に、シグナリングサーバー３３０は、クライアント装置２００へのビデオセグメントの中継を開始するために、関連経路情報を他のクライアントノードに提供する。

次に、ＰＯＩコンテンツサーバー３８０は、ステップ４３５において、近くのノード（通常はＡノード）からのＨＴＴＰリクエストに応答して、現在の（再構成された）オーバーレイネットワーク１００に沿ったビデオチャネルの起点としてこれらのノードにビデオセグメントをストリーミングし、各ビデオセグメントはクライアント装置２００まで中継されてクライアント装置２００により視聴されるまで、ノードからノードへと中継される。

クライアント装置２００は、チャネルの各ビデオセグメントを視聴するために（潜在的にはまた、ステップ４４０で他の指定されたクライアントノードにチャンクを中継するために）、ステップ４５０でチャンクを受信してそれらをコンパイルする間に、パフォーマンス監視部２４０に関して上述したように、ステップ４２５でそのパフォーマンスの監視も行い、クライアントパフォーマンスメトリックをシグナリングサーバー３３０に提供する。さらに、上述のように、ビデオセグメントは、オーバーレイネットワーク１００に沿ってクライアント装置２００にプッシュされているため、各ビデオセグメントが要求されると、これらの要求は、ステップ４５５において、（一の実施形態では、受信部２５０のクライアントジャバスクリプトコードによって）傍受される。ステップ４５５からステップ４２５への矢印は、ステップ４２５での監視プロセスが、ビデオセグメントのチャンクの受信、視聴および中継と並行する連続的なものであることを単に示す。

上述したように、ビデオセグメントが他のクライアントノードからクライアント装置２００にプッシュされている場合であっても、クライアント装置２００は、ＰＯＩコンテンツサーバー３８０からのマニフェストファイル（例えば、次の８個のビデオセグメントの位置を含む）に対するＨＴＴＰリクエストを定期的に開始する。時折、ビデオセグメントが時間内に到着しない場合、クライアント装置２００は、フォールバック位置としてＰＯＩコンテンツサーバー３８０から直接そのビデオセグメントを要求する。さらに、時折、アダプティブストリーミング２２４規格に従って、クライアント装置２００は、ＰＯＩコンテンスサーバー３８０に連絡して、（例えば、そのパフォーマンスレベルの変化を検出すると）、後続のビデオセグメントのために修正されたビットレートを要求する。しかしながら、上述のように、受信部２５０は、そのような必要性をより早期に検出し、オーバーレイネットワーク１００を介してそのような変更を実行するために仮想ブロードキャストサーバー３００に連絡して、より低いあるいはより高い解像度のビデオセグメントをクライアント装置２００に自動的にプッシュするように、供給クライアントノードに指示する（すなわち、そのリクエストに応答するのではなく）。

ステップ４５２では、ＰＯＩコンテンツサーバー３８０はそのようなＨＴＴＰリクエストに応答して、要求されたマニフェストファイルおよびフォールバックビデオセグメントをクライアント装置２００に配信する。上述のように、ビットレートの変更は、オーバーレイネットワーク１００を介して（ステップ４３０で）処理され、その結果、より低いあるいはより高い解像度のビデオセグメントがクライアント装置２００にプッシュされる。

ステップ４５４は、パフォーマンス追跡部３４０、オーバーレイネットワーク生成部３５０およびディープマッパー３６０により実行される（一の実施形態では各ビデオセグメントに対して実行され、詳細が上述されている）連続的なプロセスを包含する。このステップ４５４では、クライアントパフォーマンス情報が継続的に更新され、必要であれば、ステップ４３０で（ステップ４５４からステップ４３０の矢印に示されるように）、オーバーレイネットワーク１１０は動的に再構成され、新たなルーティング情報がシグナリングサーバー３３０を介して関連する中継ノードに提供される。

最後に、ステップ４６０で、スプラッシュ抽出部３９０は、上述のように、トレンドのスプラッシュビデオイベントを継続的に識別し、クライアント装置２００のユーザーはそれを閲覧あるいは検索し、続いて直ちに視聴するためにストリーミングすることができる。

添付の図面に示された特定の実施形態を参照しつつ、本発明を本明細書で説明してきた。本開示に照らして、本明細書で開示された概念の追加の実施形態が、当業者によって本発明の範囲内で想定され実施されうることを理解すべきである。

Claims (13)

1. 複数のアプリケーションＡＳＮおよびＡＳＮピアリングポイントを含むワイドエリアネットワーク上のノード間で同時にデジタルコンテンツをアダプティブにルーティングする仮想ブロードキャストシステムであって、前記ＡＳＮピアリングポイントは、それらＡＳＮピアリングポイントを経由するネットワークトラフィックが変動するのに応じて頻繁に変動する輻輳レベルを示し、前記仮想ブロードキャストシステムは、
   ＡＳＮおよびそれらを相互接続するピアリングポイントのマップと、ＡＳＮ内のノードの位置とを記憶するメモリーと、
   １個あるいは複数のオーバーレイネットワークに沿ったネットワークトラフィックについて、ＡＳＮピアリングポイントでの輻輳を含む、パフォーマンスメトリックを監視するパフォーマンス追跡部と、
   前記メトリックおよび前記マップを経時的に分析し、前記ＡＳＮピアリングポイントの経時的に変化する容量を反映した輻輳レベルを予想するディープラーニングエンジンと、
   ノード間でデータを配信するために、前記ワイドエリアネットワークを介してルーティング経路を定義するオーバーレイネットワークトポロジーを記憶するデータベースと、
   予想された輻輳レベルに基づいて前記オーバーレイネットワークトポロジーを動的に再構成して、前記オーバーレイネットワークに沿ったノード間でデジタルコンテンツをルーティングするための最適な経路を生成するオーバーレイネットワーク生成部と
   を備える仮想ブロードキャストシステム。
2. 請求項１に記載の仮想ブロードキャストシステムであって、
   前記オーバーレイネットワークは、ノードの中継能力を示すパフォーマンスメトリックに基づきノードを分類して、データセグメントを中継する能力を欠いたノードを第３クラスに割り当て、ＡＳＮ内でデータセグメントを中継する能力を有するノードを第２クラスに割り当て、ＡＳＮ内およびＡＳＮ間の両方でデータセグメントを中継する能力を有するノードを第１クラスに割り当て、
   前記オーバーレイネットワーク生成部は、デジタルコンテンツのチャンクの他のノードへの中継および他のノードからの受信をノードが実行できるように、ノードにスロットを割り当てる仮想ブロードキャストシステム。
3. 請求項１に記載の仮想ブロードキャストシステムであって、
   前記パフォーマンス追跡部はさらに、ノードのパフォーマンスメトリックを監視し、ディープラーニングエンジンおよびオーバーレイネットワーク生成部による使用のためにそれらを記憶する仮想ブロードキャストシステム。
4. 請求項１に記載の仮想ブロードキャストシステムであって、
   前記オーバーレイネットワークトポロジーは、第１クラスのノードと、ＡＳＮ内およびＡＳＮ間において第１クラスのノード間でビデオセグメントが進むルーティング経路とを示す１個あるいは複数のＡＳＮ間オーバーレイネットワークを備える仮想ブロードキャストシステム。
5. 請求項１に記載の仮想ブロードキャストシステムであって、
   前記オーバーレイネットワークトポロジーは、第１クラス内から第２および第３クラスのノードにビデオセグメントを中継する１個あるいは複数のＡＳＭ内オーバーレイネットワークを備える仮想ブロードキャストシステム。
6. 請求項３に記載の仮想ブロードキャスト方法であって、
   ノードのパフォーマンスメトリックは、既知のサイトに対するピング時間と、デジタルコンテンツセグメントを中継するための合計時間とを備える仮想ブロードキャスト方法。
7. 複数のアプリケーションＡＳＮおよびＡＳＮピアリングポイントを含むワイドエリアネットワーク上のノード間で同時にデジタルコンテンツをアダプティブにルーティングする仮想ブロードキャスト方法であって、前記ＡＳＮピアリングポイントは、それらＡＳＮピアリングポイントを経由するネットワークトラフィックが変動するのに応じて頻繁に変動する輻輳レベルを示し、前記仮想ブロードキャスト方法は、
   ＡＳＮおよびそれらを相互接続するピアリングポイントのマップと、ＡＳＮ内のノードの位置との維持と、
   ノード間でデータを配信するための、前記ワイドエリアネットワークを介したルーティング経路を定義するオーバーレイネットワークトポロジーの生成と、
   １個あるいは複数のオーバーレイネットワークに沿ったネットワークトラフィックについての、ＡＳＮピアリングポイントでの輻輳を含むパフォーマンスメトリックの監視と、
   ＡＳＮピアリングポイントの経時的に変化する容量を反映した輻輳レベルを予想するための、前記メトリックおよび前記マップの経時的な分析と、
   オーバーレイネットワークに沿ったノード間でのデジタルコンテンツのルーティングのための最適な経路を生成するための、輻輳レベルの予想に基づくオーバーレイネットワークトポロジーの動的な再構成と
   を備える仮想ブロードキャスト方法。
8. 請求項７に記載の仮想ブロードキャスト方法であって、
   １個あるいは複数のオーバーレイネットワークのトポロジーを生成する工程は、
   ノードの中継能力を示すパフォーマンスメトリックに基づきノードを分類して、データセグメントを中継する能力を欠いたノードを第３クラスに分類し、ＡＳＮ内でのデータセグメントの中継する能力を有するノードを第２クラスに分類し、ＡＳＮ内およびＡＳＮ間の両方でデータセグメントを中継する能力を有するノードを第１クラスに分類し、
   デジタルコンテンツのチャンクを、他のノードに中継するとともに他のノードから受信することをノードができるように、ノードにスロットを割り当てる
   工程を少なくとも含む仮想ブロードキャスト方法
9. 請求項４に記載の仮想ブロードキャスト方法であって
   １個あるいは複数のオーバーレイネットワークのトポロジーの生成はさらに、
   第１クラスのノードと、ＡＳＮ内およびＡＳＮ間において第１クラスのノード間でビデオセグメントが進むルーティング経路とを示す１個あるいは複数のＡＳＮ間オーバーレイネットワークの生成を備える仮想ブロードキャスト方法。
10. 請求項８に記載の仮想ブロードキャスト方法であって、
    １個あるいは複数のオーバーレイネットワークのトポロジーの生成はさらに、
    第１クラスから第２および第３クラスのノードにビデオセグメントを中継する１個あるいは複数のＡＳＭ内オーバーレイネットワークの生成を備える仮想ブロードキャスト方法。
11. 請求項７に記載の仮想ブロードキャスト方法であって、
    予め定義された輻輳閾値を超えると、オーバーレイネットワークが動的に再構成される仮想ブロードキャスト方法。
12. 請求項７に記載の仮想ブロードキャスト方法であって、
    ノードのパフォーマンスメトリックは、既知のサイトへのピングタイムと、デジタルコンテンツセグメントを中継するための合計時間とを備える仮想ブロードキャスト方法。
13. 請求項７に記載の仮想ブロードキャスト方法であって、
    ノードのパフォーマンスメトリックに基づくノードの分類は、それらの中継能力を決定するための、ノードのダウンストリームおよびアップストリーム帯域幅の分析を備える仮想ブロードキャスト方法。

Images