マルチキャスト・ネットワークにおけるＳＣＴＰのためのプロトコル・ブースタ
トラフィック・オプティマイザは、マルチキャスト・ネットワークを介したサーバと複数のクライアントのうちの少なくとも１つのクライアントとの間のユニキャスト・プロトコルを使用するデータ・パケットの通信を容易にする。トラフィック・オプティマイザは、通信プロセッサとパケット・プロセッサとを含む。通信プロセッサは、アソシエーション・データを含むデータとデータ・パケットとの両方をサーバからユニキャスト・プロトコルを使用して受信する。アソシエーション・データは、サーバのＩＰアドレスと通信のために利用可能な複数のクライアントのうちの少なくとも１つのＩＰアドレスとを含む。パケット・プロセッサは、データ・パケットの分析に応じてデータ転送を最適化するためにデータ・パケットを処理し、処理されたデータ・パケットを、受信されたＩＰアドレスの各々で複数のクライアントのうちの少なくとも１つに、ユニキャスト・プロトコルを使用してマルチキャスト・ネットワークを介して転送する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の構成は、標準的なプロトコルではないコンポーネントを使用したマルチリンク／マルチパス・ネットワーキング環境においてストリーム制御送信プロトコル（Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＣＴＰ））およびストリーム制御送信プロトコル−部分信頼性（Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ−Ｐａｒｔｉａｌ Ｒｅｌｉａｂｉｌｉｔｙ（ＳＣＴＰ−ＰＲ））を用いたシステムのためのマルチキャスト・サポートを提供する。
【背景技術】
【０００２】
ＳＣＴＰは、インターネット・エンジニアリング・タスク・フォース（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ））によって標準化された信頼性のあるトランスポート・プロトコルである。ＳＣＴＰは、ＩＥＴＦ ＲＦＣ４９６０「ストリーム制御送信プロトコル」、さらに、Ｓ．Ｆｕ氏やおよびＭ．Ａｔｉｑｕｚｚａｍａｎ氏による「ＳＣＴＰ：研究、製品および技術課題における最先端技術」と題された文献（ＩＥＥＥ通信マガジン、２００４年、４月）において記載されているようなマルチストリーミングやマルチホーミングなどの各機能をサポートしている。ＳＣＴＰ−ＰＲは、ＳＣＴＰの拡張であり、上位レイヤー・プロトコルに対する部分信頼性を有するデータ送信サービスを提供するようにＳＣＴＰの実施を可能にする。
【０００３】
Ｆ．Ｙｏｎｇ氏、Ｗ．Ｃｈｅｅ氏、およびＳ．Ｒａｍａｄａｓｓ氏による「Ｍ−ＳＣＴＰ： トランスポート層マルチキャスティング・プロトコル」と題された文献（ＮａＣＳＰＣ（Ｎａｔｉｏｎａｌ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ Ｐｏｓｔｇｒａｄｕａｔｅ Ｃｏｌｌｏｑｕｉｕｍ）、２００５年）においては、マルチキャストＳＣＴＰ（Ｍ−ＳＣＴＰ）を利用するスキームについて記載されている。このスキームは、ＳＣＴＰサーバとそのＳＣＴＰクライアントとの間にＭ−ＳＣＴＰサーバ・スタックを追加する。サーバ・スタックは、マルチキャスト・サービスの各リソースを管理し、マルチキャスト・メンバーシップを制御する。しかしながら、このスキームは、繰り返してユニキャスト・プロトコル・メッセージの送信を使用することによってマルチキャスト機能を達成する。換言すれば、データ・パケットを複製し、複数回のユニキャスト・プロトコル・メッセージ送信を使用して、複製したデータ・パケットを各クライアントに対して個別に送信することで、サーバ・スタックによってマルチキャストが実現される。従って、このスキームは、帯域幅の効率が低いことやシステムのスケーラビリティが良好でないことから派生する問題を解決するものではない。
【０００４】
マルチキャスト・サポートをＳＣＴＰに追加するスキームが存在する。このスキームにおいては、複数のアソシエーションからなる１対多のスタイルのＳＣＴＰソケットがサーバ側で開いている。各アソシエーションは、２つのエンド・ポイントを有し、ユニキャスト機能を有するマルチキャスト・ネットワークにおいて、これらのエンド・ポイントのうちの一方は、サーバ側にあり、他方は、各クライアント側にある。さらに、各アソシエーションは、マルチキャスト・ネットワーク・リンクに対応するパスと、ユニキャスト・ネットワーク・リンクに対応する他のパスを含む。ＳＣＴＰソケットの複数のアソシエーションにおけるマルチキャスト・パスは、同一のマルチキャストＩＰアドレス、さらに、トランスポート・ポート・アドレスを共有する。従って、サーバは、データ・パケットの１つのコピーを送信することが可能であるが、マルチキャストを介してクライアントの全てに到達することができる。結果として、高い帯域幅効率を達成することができ、このスキームを用いるシステムは、マルチキャスト・ネットワークにおいて、クライアントの数が増加していても、良好に対応することができるであろう。
【０００５】
しかしながら、上述したスキームは、プロトコルに対して特定の変更がなされることを必要とする。例えば、サーバ側で、ソケット内の複数のアソシエーションに亘って、データ・パケットの１つのコピーのみが共有されたマルチキャスト・パス上に送信されるように、ＳＣＴＰプロトコルが変更されなければならない。プロトコルに対する変更が制限されているアプリケーションにおいては、これによりスキームの動作が妨げられることがある。さらに、マルチキャスト・パスが共有されていることから、全てのクライアントがデータ・パケットの同一のセットを受信するため、全てのクライアントが同一のＳＣＴＰポート・アドレスを有することが必要となる。ポート・アドレスを占有するクライアントは、マルチキャスト・データ・パケットを受信するために同一のポート・アドレスを使用できないことがある。本発明の構成は、上述したスキームがＳＣＴＰプロトコルまたはＳＣＴＰ−ＰＲプロトコルへの明示的な変更なしに動作することを可能にする。
【発明の概要】
【０００６】
トラフィック・オプティマイザは、マルチキャスト・ネットワークを介した、サーバと複数のクライアントのうちの少なくとも１つとの間のユニキャスト・プロトコルを使用したデータ・パケットの通信を容易にする。トラフィック・オプティマイザは、通信プロセッサとパケット・プロセッサとを含む。通信プロセッサは、アソシエーション・データを含むデータおよびデータ・パケットの両方をサーバからユニキャスト・プロトコルを使用して受信する。アソシエーション・データは、サーバのＩＰアドレスと通信のために利用可能な複数のクライアントのうちの少なくとも１つのＩＰアドレスとを含む。パケット・プロセッサは、データ・パケットの分析に応じてデータ転送を最適化するためにデータ・パケットを処理し、処理されたデータ・パケットを、受信されたＩＰアドレスの各々で複数のクライアントのうちの少なくとも１つに、ユニキャスト・プロトコルを使用してマルチキャスト・ネットワークを介して転送する。
【０００７】
ユニキャスト・プロトコルは、ＳＣＴＰおよびＳＣＴＰ−ＰＲのうちの一方とすることができる。本装置は、処理されたデータ・パケットを転送するために、パケット・プロセッサがアクセスするアソシエーション・データを格納するＩＰアドレス・リポジトリをさらに含んでもよい。
【０００８】
本装置は、データ・パケットが処理される前に、予期された数のデータ・パケットが受信されるまで、受信されたデータ・パケットをバッファリングするパケット・バッファをさらに含んでもよい。本装置は、バッファリングされたデータ・パケットを分析して必要な処理のタイプを判定するパケット分析器をさらに含んでいてもよい。
【０００９】
どのデータ・パケットが余分であるかを判定することによってバッファリングされたデータ・パケットが分析され、パケット・プロセッサは、余分であるデータ・パケットを除去することによってデータ・パケットを処理してもよい。
【００１０】
どのデータ・パケットがデータの最も完全なセットを保持するかを判定することによって、バッファリングされたデータ・パケットがさらに分析されてもよく、パケット・プロセッサは、データ・パケットの実質的に完全なセットをコンパイルすることによって、データ・パケットを処理してもよい。
【００１１】
クライアントは、サーバに対し、マルチキャスト・ネットワークからデータ・パケットが適切に受信されていることを示す受領確認、さらに、パケットが遅延しているかどうかを含む情報を送信してもよい。
【００１２】
トラフィック・オプティマイザは、マルチキャスト・ネットワークを介してクライアントがデータ・パケットを受信した後、パケットが遅延していることを示すインジケーションに基づいて、サーバからアソシエーションの特定のＩＰアドレスへの或るデータ・パケットの送信をスキップするインストラクションを受信してもよい。
【００１３】
さらに、マルチキャスト・ネットワークを介してクライアントがデータ・パケットを受信した後、特定のＩＰアドレスに大幅なパケット遅延が生じていると判定された場合に、トラフィック・オプティマイザは、アソシエーションからＩＰアドレスを除去するというサーバからのインストラクションを受信してもよい。
【００１４】
方法は、トラフィック・オプティマイザにより、マルチキャスト・ネットワークを介したサーバと複数のクライアントのうちの少なくとも１つとの間のユニキャスト・プロトコルを使用した、データ・パケットの通信を容易にする。アソシエーション・データを含むデータとデータ・パケットとの両方がサーバからユニキャスト・プロトコルを使用して受信される。アソシエーション・データは、サーバのＩＰアドレスと通信のために利用可能な複数のクライアントのうちの少なくとも１つのＩＰアドレスとを含む。データ・パケットの分析に応じてデータ転送を最適化するために分析されたデータ・パケットが処理される。処理されたデータ・パケットは、受信されたＩＰアドレスの各々で複数のクライアントのうちの少なくとも１つに、ユニキャスト・プロトコルを使用してマルチキャスト・ネットワークを介して転送される。
【００１５】
本方法は、予期された数のデータ・パケットが受信されるまで、受信されたデータ・パケットをバッファリングするステップと、バッファリングされたデータ・パケットを分析して必要な処理のタイプを判定するステップとをさらに含むようにしてもよい。
【００１６】
どのデータ・パケットが余分であるかを判定することによって分析を行ってもよく、さらに、余分であるデータ・パケットを除去することによって処理を行ってもよい。
【００１７】
どのデータ・パケットがデータの最も完全なセットを保持するかを判定することによって分析を行ってもよく、さらに、データ・パケットの概ね完全なセットをコンパイルすることによって処理を行ってもよい。
【００１８】
本方法は、クライアントにより、サーバに対し、マルチキャスト・ネットワークからデータ・パケットが適切に受信されていることを示す受領確認、さらに、パケットが遅延しているかどうかを含む情報を送信するステップをさらに含むようにしてもよい。
【００１９】
本方法は、マルチキャスト・ネットワークを介してクライアントがデータ・パケットを受信した後、パケットが遅延していることを示すインジケーションに基づいて、サーバからアソシエーションの特定のＩＰアドレスに対する或るデータ・パケットの送信をスキップするステップをさらに含むようにしてもよい。
【００２０】
本方法は、さらに、マルチキャスト・ネットワークを介してクライアントがデータ・パケットを受信した後、特定のＩＰアドレスに大幅なパケット遅延が生じていると判定された場合に、アソシエーションからＩＰアドレスを除去するステップをさらに含むようにしてもよい。
【００２１】
本方法のユニキャスト・プロトコルは、ＳＣＴＰおよびＳＣＴＰ−ＰＲのうちの一方とすることができる。
【００２２】
本構成の追加的な特徴事項および利点は、添付図面を参照して、以下の例示的な各実施の形態の詳細な説明を読むことによって明らかになるであろう。
【図面の簡単な説明】
【００２３】
【図１】本発明の構成に従ったユニキャスト・ネットワークおよびマルチキャスト・ネットワークの双方に亘る同時マルチパス送信のためのＳＣＴＰをサポートするシステムの例を示す図である。
【図２】本発明の構成に従って、トラフィック・オプティマイザと、どのようにデータが処理、送信されるかを示す図である。
【図３】本発明の構成に従って、データ送信における効率を改良するためにトラフィック・オプティマイザによって使用される処理を説明するフロー図を示す。
【図４】本発明の構成に従って、データ送信における効率化を改良するためにトラフィック・オプティマイザによって使用される別の処理を説明するフロー図を示す。
【発明を実施するための形態】
【００２４】
本明細書において開示される本発明の構成は、マルチキャスト・ブロードキャストをＳＣＴＰ、ＳＣＴＰ−ＰＲ、または、ＴＣＰをサポート可能なシステムに適用できるようにするスキームを提供する。図１は、マルチキャスト・ネットワークを使用してＳＣＴＰおよびＳＣＴＰ−ＰＲに適用することができるプロトコル・ブースティング・スキームの実施態様を示している。図１において、サーバ１０は、リクエストを行っているクライアントに対して選択的に配信可能な記憶媒体に格納されたコンテンツを含む。このコンテンツは、後述するような、サーバ１０とクライアントとの間のアソシエーションを表すデータと、対応するアソシエーションに基づいて特定のクライアントに送信されるデータ・パケットを含むことがある。図１において、ユニキャスト・リンクは、一対のリンクを使用した双方向通信を表す間隔の狭い一対の実線のリンクとして示されている。破線の一方向リンクは、マルチキャスト・リンクを示している。図１における各三角および四角は、ＳＣＴＰアソシエーションを示している。具体的には、各三角は、ＳＣＴＰのアソシエーションＡを表し、各四角は、ＳＣＴＰのアソシエーションＢを表す。図１の特定の例において、アソシエーションＡ２４は、サーバ１０とクライアントＡ装置１２との間のアソシエーションに関する。アソシエーションＢ２６は、サーバ１０とクライアントＢ装置１４との間のアソシエーションに関する。
【００２５】
図１において、例示的なクライアントが、クライアント１２、１４、１６として示されている。これらは、それぞれ、クライアントＡ、Ｂ、Ｃを表す。図１は、３つのクライアントを描いているが、システムは、３つのクライアントとの動作に限定されるものではなく、１つでも、複数でも、どのような数のクライアントもサポートできる。個々のクライアント１２、１４、１６は、サーバ１０とのデータ・パケットを交換するために使用される幾つかのＩＰアドレスを含むことがある。個々のクライアントのＩＰアドレスは、サーバ１０のＩＰアドレスとの通信パスを作成するために使用されて、個々のクライアントとサーバ１０との間でデータ・パケットを容易に交換できるようにする。サーバ１０は、複数のアクセス・ネットワークを介して個々のクライアントとの通信パスを形成することもある。例えば、図１に示すように、サーバ１０は、ユニキャスト・アクセス・ネットワーク１８、マルチキャスト・アクセス・ネットワーク２０および２２との通信パスを形成することができる。これらのユニキャスト・アクセス・ネットワーク１８、マルチキャスト・アクセス・ネットワーク２０および２２は、それぞれ、３世代パートナーシップ・プロジェクト（３ｒｄ ｇｅｎｅｒａｔｉｏｎ ｐａｒｔｎｅｒｓｈｉｐ ｐｒｏｊｅｃｔ（３ＧＰＰ））・ユニキャスト・ネットワーク、３ＧＰＰマルチメディア・ブロードキャストおよびマルチキャスト・サービス（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ ａｎｄ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅｓ（ＭＢＭＳ）・ネットワークおよびディジタル・ビデオ放送−ハンドヘルド（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ − Ｈａｎｄｈｅｌｄ（ＤＶＢ−Ｈ））・ネットワークに対応する。図１は、３つのアクセス・ネットワークを示しているが、システムは、３つのアクセス・ネットワークとの動作に限定されるものではなく、サーバ１０と、ユニキャストおよびマルチキャストのいずれかのデータ送信をサポートする１つ或いは複数のアクセス・ネットワークとの間の接続パスをサポートすることがある。ユニキャスト・アクセス・ネットワーク１８は、サーバ１０と各クライアントとの間の双方向のアップリンクおよびダウンリンクを用いたユニキャスト通信サポート機能を提供する。マルチキャスト・アクセス・ネットワーク２０およびマルチキャスト・アクセス・ネットワーク２２は、双方とも、マルチキャスト・ネットワークであり、一方向のダウンリンクのみをサポートする。結果として、マルチキャスト・アクセス・ネットワーク２０および２２を介した各クライアント１２、１４、または、１６からサーバ１０へのフィードバック・チャンネルは利用可能ではない。クライアント１２、１４、および１６もまた、複数のネットワーク・インターフェースを備えていてもよく、複数の異なるタイプの通信ネットワークを介して遠隔システムと接続可能であってもよい。具体的には、クライアント１２および１４は、上述したアクセス・ネットワークのうちの３つ全てを介して遠隔システムに接続可能であり、ユニキャスト双方向のリンクおよびマルチキャスト一方向のリンクの両方を有することが可能である。その一方で、クライアント１６は、マルチキャスト・アクセス・ネットワーク２０および２２を介して遠隔システムに接続するのみ可能である。結果として、クライアント１６は、マルチキャスト一方向リンクのみをサポートする。
【００２６】
クライアントは、例えば、データ・ファイルを処理し、アプリケーションを実行し、データの送受信やデータの処理のインストラクションのためにサーバと通信する機能を有するコンピュータまたはモバイル装置を含むハードウエア装置である。
【００２７】
クライアントは、特定の機能を行えるように、サーバからのデータ・コンテンツまたはその他のコンテンツを必要とすることがある。例えば、クライアントは、ユーザのためにデータを適切に処理および表示できるように、サーバから特定のデータを受信しなければならないオーディオ／ビデオ装置である。従って、データ送信を容易にするために、クライアントとサーバとの間のアソシエーションが必要である。
【００２８】
以下の各段落において、ＳＣＴＰのアソシエーション作成の例を説明する。上述したクライアント１２は、サーバ１０に対するユニキャスト・アップリンクを有する。このユニキャスト・アップリングは、サーバ１０に対してＳＣＴＰ接続リクエストを行うために使用される。この接続リクエストは、潜在的に、標準的な４ウェイハンドシェイク手順を使用してＳＣＴＰのアソシエーションを作成することにつながり、さらに、これを以下において詳細に説明する。
【００２９】
アソシエーションは、２つのエンド・ポイント間の接続として規定することができる。例えば、クライアント１２とサーバ１０との間のアソシエーションは、クライアント１２に対応する様々なＩＰアドレスとサーバ１０に対応する様々なＩＰアドレスとの間の通信パスを表す。従って、アソシエーションは、様々なＩＰアドレスに位置する各システム間の通信パスを表す。アソシエーションは、さらに、マルチキャスト・ネットワーク内の特定のマルチキャスト・パスに配信される特定のデータ・パケットを表すデータを含む。さらに、アソシエーションは、データの送信のためにサーバに関連付けられていないクライアントのＩＰアドレスを示すために使用されるデータを含む。このデータは、どのようにデータ・パケットが送信されるかを判定する際にアクセス・ネットワークによって使用される。
【００３０】
サーバ１０と通信するリクエストを開始するために、クライアント１２は、サーバ１０に対するユニキャスト・アップリンクを介してＳＣＴＰにおいて規定されているようなＩＮＩＴチャンクを表すデータを送信する。ＩＮＩＴチャンクは、クライアント１２が接続されている通信パスに対応する全てのＩＰアドレスを含み、並びに、クライアント１２でのマルチキャスト受信の確認を表すデータを含む。サーバ１０は、識別されたパスのうちのいずれが通信のためにサーバ１０にとって利用可能であるかを、対応するＩＰアドレスをＩＮＩＴ ＡＣＫチャンクを表すデータに含めることによって確認する。ＳＣＴＰにおいて規定されているような、ＩＮＩＴ ＡＣＫを表すデータ、チャンクは、サーバ１０によって、ユニキャスト通信を用いるアクセス・ネットワーク、例えば、ユニキャスト・アクセス・ネットワーク１８を介してクライアン１２に送信される。ＩＮＩＴ ＡＣＫチャンクを表すデータがクライアント１２によって受信されると、クライアント１２は、クライアント側のＳＣＴＰアソシエーションのために送信制御ブロック（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｂｌｏｃｋ（ＴＣＢ））を表すデータを生成する。ＴＣＢは、アソシエーションを識別するために、ＳＣＴＰによって使用されるバッファ・サイズ、最大送信単位（ｍａｘｉｍｕｍ ｔｒａｎｓｍｉｓｓｉｏｎ ｕｎｉｔ（ＭＴＵ））データ、およびシーケンス番号などの情報を含む。次に、クライアント１２は、ＳＣＴＰにおいて規定されるＣＯＯＫＩＥ ＥＣＨＯチャンクを表すデータを用いてサーバ１０に応答する。サーバ１０がＣＯＯＫＩＥ ＥＣＨＯチャンクを表すデータを受信すると、サーバ１０は、サーバ側のＳＣＴＰアソシエーションのために自己のＴＣＢを表すデータを生成し、クライアント１２に送信される、ＳＣＴＰにおいて規定されているような、ＣＯＯＫＩＥ ＡＣＫチャンクを表すデータを用いて応答する。これにより、４ウェイハンドシェイク手順が完了し、図１におけるアソシエーションＡ２４で示される、サーバ１０とクライアント１２との間のＳＣＴＰアソシエーションが確立する。
【００３１】
ＳＣＴＰアソシエーション・セットアップの別の例は、クライアント１２の代わりにサーバ１０が通信を開始することを除き、上述した４ウェイハンドシェイク手順と同じものを含む。サーバ１０は、マルチキャスト・ネットワーク・パスを介してＩＮＩＴチャンクを表すデータを周期的にクライアント１２（または追加的なクライアント）に送信する。ＩＮＩＴチャンクは、サーバ１０が接続されたネットワーク・パスに対応する全てのＩＰアドレスを含む。サーバ１０とのＳＣＴＰ接続を有することに関心を有する、ユニキャスト・アップリンクをサポートするクライアントとして、例えば、クライアント１２として、ＩＮＩＴ ＡＣＫ チャンクを表すデータを含む応答がサーバ１０に送信される。クライアント１２は、マルチキャスト通信のための対応するＩＰアドレス、さらに、クライアント１２によって使用されるユニキャスト通信のためのＩＰアドレスをＩＮＩＴ ＡＣＫチャンクを表すデータに含めることによって、マルチキャスト受信機能を確認する。サーバ１０がＩＮＩＴ ＡＣＫチャンクを表すデータを受信すると、サーバ１０は、クライアント１２に送信されるＣＯＯＫＩＥ ＥＣＨＯチャンクを表すデータを用いて応答する。サーバ１０は、さらに、クライアント１２とのＳＴＣＰアソシエーションのためにサーバ側でＴＣＢを表すデータを生成する。クライアント１２がＣＯＯＫＩＥ ＥＣＨＯチャンクを表すデータを受信すると、クライアント１２は、サーバ１０にＣＯＯＫＩＥ ＡＣＫチャンクを表すデータを送信し、クライアント側のＳＣＴＰアソシエーションのためにＴＣＢを表すデータを生成する。このタイプのアソシエーションは、さらに、図１において、アソシエーションＡ２４として表されよう。
【００３２】
サーバ１０が後続するＳＣＴＰアソシエーション・リクエストを別のクライアント、例えば、クライアント１４から受信すると、追加的なＳＣＴＰ、例えば、図１に示されたアソシエーションＢ２６をセットアップするために、上記に概略説明したものと同じ手順を行うことができる。複数のアソシエーションがセットアップされることがあり、これらのアソシエーションは、１対多のＳＣＴＰソケットに属してもよく、複数の１対１のＳＣＴＰソケットに属してもよい。具体的には、複数のＳＣＴＰアソシエーションは、１つのＳＣＴＰトランスポート・ポート・アドレスを共有してもよく、その代わりに、各アソシエーションは、自己のポート・アドレスを有してもよい。
【００３３】
ユニキャスト・フィードバック機能が無く、マルチキャスト受信機能のみをサポートするクライアント、例えばクライアント１６など、については、ＳＣＴＰアソシエーションをクライアントとサーバ１０との間でセットアップすることができない。しかしながら、サーバ１０とクライアント１２および１４などのクライアントとの間でデータ・パケットがＳＣＴＰアソシエーションを用いて配信されると、これらのクライアントは、特定のデータ・パケットがマルチキャスト・アクセス・ネットワークを介してクライアント１６に送信されることを指定することがある。この本発明の構成においては、クライアント１６は、マルチキャスト・ネットワークからの情報を受信できるだけの受動的な受信機として表すことができる。具体的には、クライアント１２および／または１４は、特定のリクエストをサーバ１０に送信することにより、特定のデータ・パケットを、データのリクエストおよび受信のためにクライアント１２、１４、および１６がサービスの利用契約をしているマルチキャスト・アクセス・ネットワーク２０および２２に送信することがある。クライアント１６は、マルチキャスト・アクセス・ネットワーク２０、２２からデータを受信可能である。アソシエーション・データに応答して、サーバ１０は、各データ・パケットが送信される送信先ネットワークを決定する。
【００３４】
ＳＣＴＰアソシエーションがサーバ１０と各々のクライアント１２、１４、１６との間で確立されると、データ交換をサーバ１０とクライアントとの間で開始できる。図１に示されるように、サーバ１０は、複数のクライアントとの複数のＳＣＴＰアソシエーションを設定できる。各アソシエーションは、サーバ１０とクライアント１２、１４、および１６との通信リンクを表すマルチキャスト・パスを含む。ＳＣＴＰアソシエーションが設定されると、サーバ１０は、ＳＣＴＰを使用して、対応するアソシエーションを使用する各クライアントに対し、データ・パケットを送信することができる。サーバ１０は、ＳＣＴＰを用いてクライアント１２および１４と通信するため、サーバ１０は、リクエストされたデータ・パケットの複数のコピーをマルチキャスト・アクセス・ネットワーク２０および２２に送信する。しかしながら、この結果、帯域幅の効率が低下する。この問題を取り扱うために、本発明の構成は、ＳＣＴＰに関わる非効率を最小限にし、マルチキャスト・アクセス・ネットワーク２０および２２の効率性を活用する、ＳＣＴＰの領域外のトラフィック・オプティマイザ・モジュール２８および３０を追加することにより、マルチキャスト・ネットワーク・パスのマルチキャスト機能を向上させる。図１は、サーバ１０に結合された２つのトラフィック・オプティマイザ２８および３０を示している。サーバ１０と、クライアントによってアクセス可能な各々のマルチキャスト・アクセス・ネットワーク２０および２２との間にＭＢＳのためのトラフィック・オプティマイザ２８、または、ＤＶＢ−Ｈのためのトラフィック・オプティマイザ３０が接続されている。
【００３５】
図１に示されたトラフィック・オプティマイザ・モジュール２８および３０は、ネットワークのトラフィックを軽減するために存在する。本発明の構成においては、トラフィック・オプティマイザは、さらに、マルチキャスト・ネットワークを介して、データ・アソシエーションを使用して、サーバからクライアントにデータ・パケットを容易に送信できるようにする機能を有する。さらに、トラフィック・オプティマイザは、サーバから受信したデータを処理して、ネットワークのリソースが最も効率的となる方法で、確実に正しいデータが適切なクライアントに送信されるようにする。例えば、特定のクライアントが大きな帯域幅を使用するヘビー・ユーザである場合、または、一般的に、ネットワーク内でトラフィックの混雑が存在する場合には、確実に帯域幅が相応に使用され、割り当てられるようにするため、トラフィック・オプティマイザは、受信したデータ・パケットを処理し、さらに、ネットワークの状況を監視することがある。
【００３６】
図２は、例示的なトラフィック・オプティマイザ２８内部の各コンポーネントを示すブロック図である。通信プロセッサ２０８は、クライアントのために意図されたアソシエーション・データおよびデータ・パケットをサーバ１０から受信する。通信プロセッサ２０８は、ＩＰアドレス・リポジトリ２１０に結合される。このＩＰアドレス・リポジトリ２１０は、通信パスを確立するために使用されるサーバ１０およびクライアント１２、１４、１６のＩＰアドレスを含むアソシエーション情報を受信し、格納するコンピュータ化された記憶媒体を含むことがある。トラフィック・オプティマイザ２８が正確なクライアントＩＰアドレスに対してデータを適切にルーティングできるようにするために、ＩＰアドレスを表すアソシエーション・データが格納される。ＩＰアドレス・リポジトリ２１０は、トラフィック・オプティマイザ２８に対し、データ・パケットの発信元および送信先についての情報を提供する。さらに、パケット・バッファ２２０は、通信プロセッサ２０８に結合され、サーバ１０からのデータ・パケットを受信し、分析されるデータ・パケットの量が十分になるまで、データ・パケットを格納する。受信され、格納されたデータ・パケットは、クライアント１２および１４のいずれかによってリクエストされたコンテンツに対応する。必要な数のデータ・パケットが受信されると、パケット・バッファ２２０に結合されたパケット分析器２３０は、パケット・バッファ２２０からの記憶されたデータ・パケットを構文解析し（ｐａｒｓｅ）、そのパケットを分析してデータ・パケットの最も完全なセットを特定するか、同一のデータの余分なコピーを見つける。パケット分析器２３０は、記憶されたデータ・パケットのシーケンス番号と比較するために、データ・パケットのシーケンス番号のリスト、またはデータ・パケットに関連付けられたポインタのリストを使用することによって分析および識別を行う。これらのデータ・パケットは、クライアント１２および／または１４によってサーバ１０からリクエストされたデータを表す。
【００３７】
パケット・プロセッサ２４０は、パケット分析器２３０に結合されており、パケット分析器２３０からの分析されたデータ・パケットとその分析結果を受信する。これにより、パケット・プロセッサ２４０は、クライアントに対してデータ・パケットの最も完全なセットを送信するか、同一のデータの余分なコピーを除去してデータの１つのコピーのみを送信することができる。余分なコピーの全ては、ドロップされて破棄され、その一方で、データの１つのコピーがマルチキャスト・アクセス・ネットワークへの送信のために保持される。結果として、複数のクライアントのために複数のデータ・パケットの代わりにデータ・パケットの１つのコピーのみが送信されるため、使用される帯域幅が少なくなる。さらに、ネットワーク混雑や接続障害が生じたりしている場合では、データ・パケットの最も完全なセットが、送信におけるデータや効率の損失がより確実に最小であるように送信される。パケット・プロセッサ２４０によって送信されるデータ・パケットが、確実に正しいクライアントに送信されるように、パケット・プロセッサ２４０は、クライアントとサーバ１０間の様々なアソシエーションのＩＰアドレスを含むＩＰアドレス・リポジトリ２１０にも結合されている。
【００３８】
具体的には、パケット・プロセッサ２４０は、ＩＰアドレス・リポジトリ２１０にクエリーを行って、どの特定のクライアントまたはアクセス・ネットワークのＩＰアドレスが特定のデータ・パケットを受信することになるかを表すデータを用いて応答する。以下の各段落は、図１に描かれたクライアント１２、１４、１６、サーバ１０、および、ネットワーク１８、２０、および２２とのトラフィック・オプティマイザ２８の相互接続に関連したトラフィック・オプティマイザ２８の機能に関する更なる詳細な説明を提供するものである。
【００３９】
図３は、サーバ１０から各々のクライアントへのデータ・パケットの送信効率を向上させるためにトラフィック・オプティマイザ２８によって行われる各ステップのフローチャートを示す。この処理は、ステップ３１０で開始し、このステップ３１０で、トラフィック・オプティマイザ２８は、データ・パケットが送信される場所および方法を識別する特定のクライアント／サーバのアソシエーションからＩＰアドレスを取得する。ステップ３２０において、トラフィック・オプティマイザ２８は、サーバ１０からデータ・パケットを受信する。受信されたデータ・パケットは、全て、クライアントの特定の送信先ＩＰアドレスと、データ・パケットの送信先を示す対応するアソシエーション情報にリンクされている。ステップ３３０において、トラフィック・オプティマイザ２８は、サーバ１０によって送信された受信パケットのバッファリングを行う。サーバ１０は、マルチキャスト・ネットワークにおいて、全てのクライアントに同一のデータ・パケットを送信しなければならないため、個々のアソシエーションに対応するトラフィック・オプティマイザ２８がサーバ１０から受信するデータ・パケットは同一となる。結果として、ステップ３４０において、トラフィック・オプティマイザ２８は、データ・パケットを分析して同一のデータの余分なコピーを特定することができる。次に、ステップ３５０において、トラフィック・オプティマイザ２８は、同一のデータの余分なコピーを除去するために、分析されたデータを処理し、データ・パケットの１つのコピーのみが送信先ネットワークに転送されるようにする。ステップ３６０は、送信先クライアントのＩＰアドレスを含むアソシエーション・データと共にデータ・パケットの１つのコピーを含む処理されたデータを配信するトラフィック・オプティマイザ２８に関わる。このデータは送信先ネットワークに転送され、この送信先ネットワークは１つのネットワーク、全てのネットワークまたは、ネットワーク１８、２０、および２２を含むことがある。最終的には、送信先ネットワークは、クライアントの送信先ＩＰアドレスを含むアソシエーション・データに基づいて特定のクライアントにデータ・パケットを送信する役目を担う。
【００４０】
トラフィック・オプティマイザ２８の各ステップは、代替的には、サーバ１０の内部、例えば、ネットワーク層での処理として実行される。具体的には、トラフィック・オプティマイザ２８の各機能は、スタンドアロンなモジュールとしてではなく、代わりに、サーバ１０内で実施されることがある。トラフィック・オプティマイザ３０は図１に示されている追加のトラフィック・オプティマイザであり、ＤＶＢ−Ｈネットワーク２２を通じた通信の役目を担うトラフィック・オプティマイザ３０は、上述したトラフィック・オプティマイザ２８と同様に動作する。
【００４１】
クライアント１２および１４は、マルチキャスト・ネットワーク・パスを通じて配信された共通のデータ・パケットを受信してもよい。図１に示されているような追加的なユニキャスト・パスを有するクライアント、具体的には、クライアント１２および１４は、図１に示されたユニキャスト・ダウンリンクを介してサーバ１０からの追加のデータ・パケットを受信できることがある。ユニキャスト・パスを有する各クライアントは、複数の異なるデータ・パケットがマルチキャストを介して送信される代わりに、自己のユニキャスト・ダウンリンクを介して送信されるようにするために、特定のリクエストをサーバ１０に対して行うことができる。追加のデータ・パケットは、様々な理由でユニキャスト・ダウンリンクを介して送信されることがある。特定のデータは、特定のクライアントに特化していることもあれば、マルチキャスト・ネットワークの状態が良好でない場合には、特定のデータがユニキャストを介して送信されることが必要となることがある。
【００４２】
さらに、クライアント１２および１４は、ユニキャスト・アップリンクを介してサーバ１０に対し、マルチキャスト・パスを含み、アソシエーションにおける全てのパスために、選択的な受領確認（Ｓｅｌｅｃｔｉｖｅ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ（ＳＡＣＫ））を送信できる。ＳＡＣＫは、パケットが受信された旨の受領確認である。クライアントがＳＡＣＫを送信すると、クライアントは、受領確認により、特定のアソシエーションに対応するＩＰアドレスに対するサービスを提供可能であり、データの送受信に参加可能であることを確認する。
【００４３】
マルチキャスト・ネットワークにおいて、各クライアントの受信状態が異なることがあるため、さらに、データ・パケット損失の量がＳＡＣＫ内で報告される。従って、ＳＡＣＫは、さらに、複数のＳＣＴＰアソシエーションからのフィードバックとしての役目を果たす。パケット損失の量は、各アソシエーションの受ける受信障害のレベルが異なるため、複数の異なるアソシエーションについての複数の異なるＩＰアドレス間で異なる。受信障害は、特に、良好でないデータ受信状態によってデータの破損が起こることの多い無線通信ネットワークにおいて発生する。結果として、サーバ１０は、マルチキャスト・リンクを介して送信に失敗したデータ・パケットの再送信を、ユニキャストをサポートする個々のクライアントに対してユニキャスト・ダウンリンクを介して行い、接続およびデータ・パケットの復元を容易にできるようにする。これにより、マルチキャスト・リンクに遅延が生じている場合や、マルチキャスト・リンクが実行可能な選択肢ではない場合にも、クライアントが意図したデータを受信できるようにする安全機構を有するシステムを提供する。マルチキャスト・リンク内でデータの損失が生じたことをクライアントが検出すると、クライアントは、自己のユニキャスト・リンクを使用してサーバ１０にフィードバックを送信してユニキャスト・リンクを介してサーバに消失したデータを再送信するようにリクエストすることができる。
【００４４】
しかしながら、ＳＣＴＰトラフィックの混雑を制御する機構により、サーバ１０は、複数の特定の時点で、複数の異なるアソシエーションのための複数の異なるデータ・レートで、データ・パケットを送信することがある。図４は、複数の異なるアソシエーションに対応する複数の異なるＩＰアドレスに対して複数の異なるレートでサーバによってデータ・パケットが送信される場合にデータ・パケット送信を最適化するためにトラフィック・オプティマイザによって行われる各ステップのフローチャートを示す。結果として、複数のアソシエーションのための複数の異なるデータ・パケットは、複数の異なる時点にトラフィック・オプティマイザ２８に到達することがある。従って、トラフィック・オプティマイザ２８は、データ・パケットを分類して、確実に特定のデータ・パケットが正しいクライアントに到達し、これらのデータ・パケットが可能な限り完全となるようにする。この処理は、ステップ４１０で開始し、このステップ４１０で、トラフィック・オプティマイザ２８は、アクセス・ネットワークを介して送信されるデータ・パケットのための対応するアソシエーションから送信先ＩＰアドレスを取得する。ステップ４２０において、トラフィック・オプティマイザ２８は、様々なクライアントに対する意図した送信先を有するサーバ１０からデータ・パケットを、各々の対応するアソシエーションからのＩＰアドレスに基づいて受信する。ステップ４３０において、トラフィック・オプティマイザ２８は、受信したデータ・パケットをキャッシュする。次に、ステップ４４０において、キャッシュされたデータ・パケットが分析されて各クライアントによってリクエストされたコンテンツに対応するパケットの最も完全なセットを見つける。データ・パケットの不完全なセットは分析され、その後、ステップ４５０において、データ・パケットの実質的に完全な、または、完全なセットを形成するように、コンパイルされる。データ・パケットのシーケンス番号は、格納されたデータ・パケットのシーケンス番号と比較して、データ・パケットのセットが完全であるか、特定の部分を消失しているかを判定するために分析がなされる。ステップ４６０において、特定のクライアントに対する送信のために、実質的に完全な、または、完全なパケットのセットが送信先のマルチキャスト・ネットワークに転送される。
【００４５】
本発明の構成について記載した上述の各段落の内容は、ＳＣＴＰ−ＰＲを使用したシステムにも適用可能である。さらに、ＳＣＴＰ−ＰＲを使用したシステムにおいては、サーバ１０は、アソシエーションの特定のＩＰアドレスに、同一のアソシエーションの他のＩＰアドレスと比較して大量の遅延が発生する場合には、マルチキャスト・リンクを介した特定のデータ・パケットの送信をスキップすることができる。これにより、アソシエーションの特定のＩＰアドレスについて遅延の生じているマルチキャスト・リンクは、他のＩＰアドレスに既に送信済みのデータ・パケットに追いつくことができるようになる。特定のリンクが他のリンクと比較して損失が大きい場合には、良好な接続を有するリンクを介して送信されるデータ・パケットにデータ送信の遅延が生ずる。全てのデータ・パケットが、クライアントによって完全に受信されることが必要ではないため、サーバ１０は、どのデータ・パケットが遅延の生じているリンクを介して送信されているかを判定することができ、このようなデータ・パケットの送信を適切にスキップすることができる。この処理は、クライアントに対して透過性である。クライアントは、さらに、特定のマルチキャスト・リンクにおける過剰なパケット損失を報告することができる。過剰なパケット損失を表すデータを受信すると、サーバ１０は、特定のマルチキャスト・リンクを使用するＩＰアドレスをその対応するアソシエーションから除去してクライアントの他のＩＰアドレスに対するデータ送信の遅延を防止することができる。
【００４６】
例示的な実施形態の観点から構成を説明したが、このような例示的な実施形態に限定されるものではない。むしろ、付随する請求項は、本構成に均等な範囲および領域を逸脱することなく、本構成の他の変形例および実施形態を含むように解釈されるべきである。本開示内容は、本明細書に記載された各実施形態の適用例、改変例を全て包含するように意図されている。
【技術分野】
【０００１】
本発明の構成は、標準的なプロトコルではないコンポーネントを使用したマルチリンク／マルチパス・ネットワーキング環境においてストリーム制御送信プロトコル（Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＣＴＰ））およびストリーム制御送信プロトコル−部分信頼性（Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ−Ｐａｒｔｉａｌ Ｒｅｌｉａｂｉｌｉｔｙ（ＳＣＴＰ−ＰＲ））を用いたシステムのためのマルチキャスト・サポートを提供する。
【背景技術】
【０００２】
ＳＣＴＰは、インターネット・エンジニアリング・タスク・フォース（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ））によって標準化された信頼性のあるトランスポート・プロトコルである。ＳＣＴＰは、ＩＥＴＦ ＲＦＣ４９６０「ストリーム制御送信プロトコル」、さらに、Ｓ．Ｆｕ氏やおよびＭ．Ａｔｉｑｕｚｚａｍａｎ氏による「ＳＣＴＰ：研究、製品および技術課題における最先端技術」と題された文献（ＩＥＥＥ通信マガジン、２００４年、４月）において記載されているようなマルチストリーミングやマルチホーミングなどの各機能をサポートしている。ＳＣＴＰ−ＰＲは、ＳＣＴＰの拡張であり、上位レイヤー・プロトコルに対する部分信頼性を有するデータ送信サービスを提供するようにＳＣＴＰの実施を可能にする。
【０００３】
Ｆ．Ｙｏｎｇ氏、Ｗ．Ｃｈｅｅ氏、およびＳ．Ｒａｍａｄａｓｓ氏による「Ｍ−ＳＣＴＰ： トランスポート層マルチキャスティング・プロトコル」と題された文献（ＮａＣＳＰＣ（Ｎａｔｉｏｎａｌ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ Ｐｏｓｔｇｒａｄｕａｔｅ Ｃｏｌｌｏｑｕｉｕｍ）、２００５年）においては、マルチキャストＳＣＴＰ（Ｍ−ＳＣＴＰ）を利用するスキームについて記載されている。このスキームは、ＳＣＴＰサーバとそのＳＣＴＰクライアントとの間にＭ−ＳＣＴＰサーバ・スタックを追加する。サーバ・スタックは、マルチキャスト・サービスの各リソースを管理し、マルチキャスト・メンバーシップを制御する。しかしながら、このスキームは、繰り返してユニキャスト・プロトコル・メッセージの送信を使用することによってマルチキャスト機能を達成する。換言すれば、データ・パケットを複製し、複数回のユニキャスト・プロトコル・メッセージ送信を使用して、複製したデータ・パケットを各クライアントに対して個別に送信することで、サーバ・スタックによってマルチキャストが実現される。従って、このスキームは、帯域幅の効率が低いことやシステムのスケーラビリティが良好でないことから派生する問題を解決するものではない。
【０００４】
マルチキャスト・サポートをＳＣＴＰに追加するスキームが存在する。このスキームにおいては、複数のアソシエーションからなる１対多のスタイルのＳＣＴＰソケットがサーバ側で開いている。各アソシエーションは、２つのエンド・ポイントを有し、ユニキャスト機能を有するマルチキャスト・ネットワークにおいて、これらのエンド・ポイントのうちの一方は、サーバ側にあり、他方は、各クライアント側にある。さらに、各アソシエーションは、マルチキャスト・ネットワーク・リンクに対応するパスと、ユニキャスト・ネットワーク・リンクに対応する他のパスを含む。ＳＣＴＰソケットの複数のアソシエーションにおけるマルチキャスト・パスは、同一のマルチキャストＩＰアドレス、さらに、トランスポート・ポート・アドレスを共有する。従って、サーバは、データ・パケットの１つのコピーを送信することが可能であるが、マルチキャストを介してクライアントの全てに到達することができる。結果として、高い帯域幅効率を達成することができ、このスキームを用いるシステムは、マルチキャスト・ネットワークにおいて、クライアントの数が増加していても、良好に対応することができるであろう。
【０００５】
しかしながら、上述したスキームは、プロトコルに対して特定の変更がなされることを必要とする。例えば、サーバ側で、ソケット内の複数のアソシエーションに亘って、データ・パケットの１つのコピーのみが共有されたマルチキャスト・パス上に送信されるように、ＳＣＴＰプロトコルが変更されなければならない。プロトコルに対する変更が制限されているアプリケーションにおいては、これによりスキームの動作が妨げられることがある。さらに、マルチキャスト・パスが共有されていることから、全てのクライアントがデータ・パケットの同一のセットを受信するため、全てのクライアントが同一のＳＣＴＰポート・アドレスを有することが必要となる。ポート・アドレスを占有するクライアントは、マルチキャスト・データ・パケットを受信するために同一のポート・アドレスを使用できないことがある。本発明の構成は、上述したスキームがＳＣＴＰプロトコルまたはＳＣＴＰ−ＰＲプロトコルへの明示的な変更なしに動作することを可能にする。
【発明の概要】
【０００６】
トラフィック・オプティマイザは、マルチキャスト・ネットワークを介した、サーバと複数のクライアントのうちの少なくとも１つとの間のユニキャスト・プロトコルを使用したデータ・パケットの通信を容易にする。トラフィック・オプティマイザは、通信プロセッサとパケット・プロセッサとを含む。通信プロセッサは、アソシエーション・データを含むデータおよびデータ・パケットの両方をサーバからユニキャスト・プロトコルを使用して受信する。アソシエーション・データは、サーバのＩＰアドレスと通信のために利用可能な複数のクライアントのうちの少なくとも１つのＩＰアドレスとを含む。パケット・プロセッサは、データ・パケットの分析に応じてデータ転送を最適化するためにデータ・パケットを処理し、処理されたデータ・パケットを、受信されたＩＰアドレスの各々で複数のクライアントのうちの少なくとも１つに、ユニキャスト・プロトコルを使用してマルチキャスト・ネットワークを介して転送する。
【０００７】
ユニキャスト・プロトコルは、ＳＣＴＰおよびＳＣＴＰ−ＰＲのうちの一方とすることができる。本装置は、処理されたデータ・パケットを転送するために、パケット・プロセッサがアクセスするアソシエーション・データを格納するＩＰアドレス・リポジトリをさらに含んでもよい。
【０００８】
本装置は、データ・パケットが処理される前に、予期された数のデータ・パケットが受信されるまで、受信されたデータ・パケットをバッファリングするパケット・バッファをさらに含んでもよい。本装置は、バッファリングされたデータ・パケットを分析して必要な処理のタイプを判定するパケット分析器をさらに含んでいてもよい。
【０００９】
どのデータ・パケットが余分であるかを判定することによってバッファリングされたデータ・パケットが分析され、パケット・プロセッサは、余分であるデータ・パケットを除去することによってデータ・パケットを処理してもよい。
【００１０】
どのデータ・パケットがデータの最も完全なセットを保持するかを判定することによって、バッファリングされたデータ・パケットがさらに分析されてもよく、パケット・プロセッサは、データ・パケットの実質的に完全なセットをコンパイルすることによって、データ・パケットを処理してもよい。
【００１１】
クライアントは、サーバに対し、マルチキャスト・ネットワークからデータ・パケットが適切に受信されていることを示す受領確認、さらに、パケットが遅延しているかどうかを含む情報を送信してもよい。
【００１２】
トラフィック・オプティマイザは、マルチキャスト・ネットワークを介してクライアントがデータ・パケットを受信した後、パケットが遅延していることを示すインジケーションに基づいて、サーバからアソシエーションの特定のＩＰアドレスへの或るデータ・パケットの送信をスキップするインストラクションを受信してもよい。
【００１３】
さらに、マルチキャスト・ネットワークを介してクライアントがデータ・パケットを受信した後、特定のＩＰアドレスに大幅なパケット遅延が生じていると判定された場合に、トラフィック・オプティマイザは、アソシエーションからＩＰアドレスを除去するというサーバからのインストラクションを受信してもよい。
【００１４】
方法は、トラフィック・オプティマイザにより、マルチキャスト・ネットワークを介したサーバと複数のクライアントのうちの少なくとも１つとの間のユニキャスト・プロトコルを使用した、データ・パケットの通信を容易にする。アソシエーション・データを含むデータとデータ・パケットとの両方がサーバからユニキャスト・プロトコルを使用して受信される。アソシエーション・データは、サーバのＩＰアドレスと通信のために利用可能な複数のクライアントのうちの少なくとも１つのＩＰアドレスとを含む。データ・パケットの分析に応じてデータ転送を最適化するために分析されたデータ・パケットが処理される。処理されたデータ・パケットは、受信されたＩＰアドレスの各々で複数のクライアントのうちの少なくとも１つに、ユニキャスト・プロトコルを使用してマルチキャスト・ネットワークを介して転送される。
【００１５】
本方法は、予期された数のデータ・パケットが受信されるまで、受信されたデータ・パケットをバッファリングするステップと、バッファリングされたデータ・パケットを分析して必要な処理のタイプを判定するステップとをさらに含むようにしてもよい。
【００１６】
どのデータ・パケットが余分であるかを判定することによって分析を行ってもよく、さらに、余分であるデータ・パケットを除去することによって処理を行ってもよい。
【００１７】
どのデータ・パケットがデータの最も完全なセットを保持するかを判定することによって分析を行ってもよく、さらに、データ・パケットの概ね完全なセットをコンパイルすることによって処理を行ってもよい。
【００１８】
本方法は、クライアントにより、サーバに対し、マルチキャスト・ネットワークからデータ・パケットが適切に受信されていることを示す受領確認、さらに、パケットが遅延しているかどうかを含む情報を送信するステップをさらに含むようにしてもよい。
【００１９】
本方法は、マルチキャスト・ネットワークを介してクライアントがデータ・パケットを受信した後、パケットが遅延していることを示すインジケーションに基づいて、サーバからアソシエーションの特定のＩＰアドレスに対する或るデータ・パケットの送信をスキップするステップをさらに含むようにしてもよい。
【００２０】
本方法は、さらに、マルチキャスト・ネットワークを介してクライアントがデータ・パケットを受信した後、特定のＩＰアドレスに大幅なパケット遅延が生じていると判定された場合に、アソシエーションからＩＰアドレスを除去するステップをさらに含むようにしてもよい。
【００２１】
本方法のユニキャスト・プロトコルは、ＳＣＴＰおよびＳＣＴＰ−ＰＲのうちの一方とすることができる。
【００２２】
本構成の追加的な特徴事項および利点は、添付図面を参照して、以下の例示的な各実施の形態の詳細な説明を読むことによって明らかになるであろう。
【図面の簡単な説明】
【００２３】
【図１】本発明の構成に従ったユニキャスト・ネットワークおよびマルチキャスト・ネットワークの双方に亘る同時マルチパス送信のためのＳＣＴＰをサポートするシステムの例を示す図である。
【図２】本発明の構成に従って、トラフィック・オプティマイザと、どのようにデータが処理、送信されるかを示す図である。
【図３】本発明の構成に従って、データ送信における効率を改良するためにトラフィック・オプティマイザによって使用される処理を説明するフロー図を示す。
【図４】本発明の構成に従って、データ送信における効率化を改良するためにトラフィック・オプティマイザによって使用される別の処理を説明するフロー図を示す。
【発明を実施するための形態】
【００２４】
本明細書において開示される本発明の構成は、マルチキャスト・ブロードキャストをＳＣＴＰ、ＳＣＴＰ−ＰＲ、または、ＴＣＰをサポート可能なシステムに適用できるようにするスキームを提供する。図１は、マルチキャスト・ネットワークを使用してＳＣＴＰおよびＳＣＴＰ−ＰＲに適用することができるプロトコル・ブースティング・スキームの実施態様を示している。図１において、サーバ１０は、リクエストを行っているクライアントに対して選択的に配信可能な記憶媒体に格納されたコンテンツを含む。このコンテンツは、後述するような、サーバ１０とクライアントとの間のアソシエーションを表すデータと、対応するアソシエーションに基づいて特定のクライアントに送信されるデータ・パケットを含むことがある。図１において、ユニキャスト・リンクは、一対のリンクを使用した双方向通信を表す間隔の狭い一対の実線のリンクとして示されている。破線の一方向リンクは、マルチキャスト・リンクを示している。図１における各三角および四角は、ＳＣＴＰアソシエーションを示している。具体的には、各三角は、ＳＣＴＰのアソシエーションＡを表し、各四角は、ＳＣＴＰのアソシエーションＢを表す。図１の特定の例において、アソシエーションＡ２４は、サーバ１０とクライアントＡ装置１２との間のアソシエーションに関する。アソシエーションＢ２６は、サーバ１０とクライアントＢ装置１４との間のアソシエーションに関する。
【００２５】
図１において、例示的なクライアントが、クライアント１２、１４、１６として示されている。これらは、それぞれ、クライアントＡ、Ｂ、Ｃを表す。図１は、３つのクライアントを描いているが、システムは、３つのクライアントとの動作に限定されるものではなく、１つでも、複数でも、どのような数のクライアントもサポートできる。個々のクライアント１２、１４、１６は、サーバ１０とのデータ・パケットを交換するために使用される幾つかのＩＰアドレスを含むことがある。個々のクライアントのＩＰアドレスは、サーバ１０のＩＰアドレスとの通信パスを作成するために使用されて、個々のクライアントとサーバ１０との間でデータ・パケットを容易に交換できるようにする。サーバ１０は、複数のアクセス・ネットワークを介して個々のクライアントとの通信パスを形成することもある。例えば、図１に示すように、サーバ１０は、ユニキャスト・アクセス・ネットワーク１８、マルチキャスト・アクセス・ネットワーク２０および２２との通信パスを形成することができる。これらのユニキャスト・アクセス・ネットワーク１８、マルチキャスト・アクセス・ネットワーク２０および２２は、それぞれ、３世代パートナーシップ・プロジェクト（３ｒｄ ｇｅｎｅｒａｔｉｏｎ ｐａｒｔｎｅｒｓｈｉｐ ｐｒｏｊｅｃｔ（３ＧＰＰ））・ユニキャスト・ネットワーク、３ＧＰＰマルチメディア・ブロードキャストおよびマルチキャスト・サービス（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ ａｎｄ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅｓ（ＭＢＭＳ）・ネットワークおよびディジタル・ビデオ放送−ハンドヘルド（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｉｎｇ − Ｈａｎｄｈｅｌｄ（ＤＶＢ−Ｈ））・ネットワークに対応する。図１は、３つのアクセス・ネットワークを示しているが、システムは、３つのアクセス・ネットワークとの動作に限定されるものではなく、サーバ１０と、ユニキャストおよびマルチキャストのいずれかのデータ送信をサポートする１つ或いは複数のアクセス・ネットワークとの間の接続パスをサポートすることがある。ユニキャスト・アクセス・ネットワーク１８は、サーバ１０と各クライアントとの間の双方向のアップリンクおよびダウンリンクを用いたユニキャスト通信サポート機能を提供する。マルチキャスト・アクセス・ネットワーク２０およびマルチキャスト・アクセス・ネットワーク２２は、双方とも、マルチキャスト・ネットワークであり、一方向のダウンリンクのみをサポートする。結果として、マルチキャスト・アクセス・ネットワーク２０および２２を介した各クライアント１２、１４、または、１６からサーバ１０へのフィードバック・チャンネルは利用可能ではない。クライアント１２、１４、および１６もまた、複数のネットワーク・インターフェースを備えていてもよく、複数の異なるタイプの通信ネットワークを介して遠隔システムと接続可能であってもよい。具体的には、クライアント１２および１４は、上述したアクセス・ネットワークのうちの３つ全てを介して遠隔システムに接続可能であり、ユニキャスト双方向のリンクおよびマルチキャスト一方向のリンクの両方を有することが可能である。その一方で、クライアント１６は、マルチキャスト・アクセス・ネットワーク２０および２２を介して遠隔システムに接続するのみ可能である。結果として、クライアント１６は、マルチキャスト一方向リンクのみをサポートする。
【００２６】
クライアントは、例えば、データ・ファイルを処理し、アプリケーションを実行し、データの送受信やデータの処理のインストラクションのためにサーバと通信する機能を有するコンピュータまたはモバイル装置を含むハードウエア装置である。
【００２７】
クライアントは、特定の機能を行えるように、サーバからのデータ・コンテンツまたはその他のコンテンツを必要とすることがある。例えば、クライアントは、ユーザのためにデータを適切に処理および表示できるように、サーバから特定のデータを受信しなければならないオーディオ／ビデオ装置である。従って、データ送信を容易にするために、クライアントとサーバとの間のアソシエーションが必要である。
【００２８】
以下の各段落において、ＳＣＴＰのアソシエーション作成の例を説明する。上述したクライアント１２は、サーバ１０に対するユニキャスト・アップリンクを有する。このユニキャスト・アップリングは、サーバ１０に対してＳＣＴＰ接続リクエストを行うために使用される。この接続リクエストは、潜在的に、標準的な４ウェイハンドシェイク手順を使用してＳＣＴＰのアソシエーションを作成することにつながり、さらに、これを以下において詳細に説明する。
【００２９】
アソシエーションは、２つのエンド・ポイント間の接続として規定することができる。例えば、クライアント１２とサーバ１０との間のアソシエーションは、クライアント１２に対応する様々なＩＰアドレスとサーバ１０に対応する様々なＩＰアドレスとの間の通信パスを表す。従って、アソシエーションは、様々なＩＰアドレスに位置する各システム間の通信パスを表す。アソシエーションは、さらに、マルチキャスト・ネットワーク内の特定のマルチキャスト・パスに配信される特定のデータ・パケットを表すデータを含む。さらに、アソシエーションは、データの送信のためにサーバに関連付けられていないクライアントのＩＰアドレスを示すために使用されるデータを含む。このデータは、どのようにデータ・パケットが送信されるかを判定する際にアクセス・ネットワークによって使用される。
【００３０】
サーバ１０と通信するリクエストを開始するために、クライアント１２は、サーバ１０に対するユニキャスト・アップリンクを介してＳＣＴＰにおいて規定されているようなＩＮＩＴチャンクを表すデータを送信する。ＩＮＩＴチャンクは、クライアント１２が接続されている通信パスに対応する全てのＩＰアドレスを含み、並びに、クライアント１２でのマルチキャスト受信の確認を表すデータを含む。サーバ１０は、識別されたパスのうちのいずれが通信のためにサーバ１０にとって利用可能であるかを、対応するＩＰアドレスをＩＮＩＴ ＡＣＫチャンクを表すデータに含めることによって確認する。ＳＣＴＰにおいて規定されているような、ＩＮＩＴ ＡＣＫを表すデータ、チャンクは、サーバ１０によって、ユニキャスト通信を用いるアクセス・ネットワーク、例えば、ユニキャスト・アクセス・ネットワーク１８を介してクライアン１２に送信される。ＩＮＩＴ ＡＣＫチャンクを表すデータがクライアント１２によって受信されると、クライアント１２は、クライアント側のＳＣＴＰアソシエーションのために送信制御ブロック（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｂｌｏｃｋ（ＴＣＢ））を表すデータを生成する。ＴＣＢは、アソシエーションを識別するために、ＳＣＴＰによって使用されるバッファ・サイズ、最大送信単位（ｍａｘｉｍｕｍ ｔｒａｎｓｍｉｓｓｉｏｎ ｕｎｉｔ（ＭＴＵ））データ、およびシーケンス番号などの情報を含む。次に、クライアント１２は、ＳＣＴＰにおいて規定されるＣＯＯＫＩＥ ＥＣＨＯチャンクを表すデータを用いてサーバ１０に応答する。サーバ１０がＣＯＯＫＩＥ ＥＣＨＯチャンクを表すデータを受信すると、サーバ１０は、サーバ側のＳＣＴＰアソシエーションのために自己のＴＣＢを表すデータを生成し、クライアント１２に送信される、ＳＣＴＰにおいて規定されているような、ＣＯＯＫＩＥ ＡＣＫチャンクを表すデータを用いて応答する。これにより、４ウェイハンドシェイク手順が完了し、図１におけるアソシエーションＡ２４で示される、サーバ１０とクライアント１２との間のＳＣＴＰアソシエーションが確立する。
【００３１】
ＳＣＴＰアソシエーション・セットアップの別の例は、クライアント１２の代わりにサーバ１０が通信を開始することを除き、上述した４ウェイハンドシェイク手順と同じものを含む。サーバ１０は、マルチキャスト・ネットワーク・パスを介してＩＮＩＴチャンクを表すデータを周期的にクライアント１２（または追加的なクライアント）に送信する。ＩＮＩＴチャンクは、サーバ１０が接続されたネットワーク・パスに対応する全てのＩＰアドレスを含む。サーバ１０とのＳＣＴＰ接続を有することに関心を有する、ユニキャスト・アップリンクをサポートするクライアントとして、例えば、クライアント１２として、ＩＮＩＴ ＡＣＫ チャンクを表すデータを含む応答がサーバ１０に送信される。クライアント１２は、マルチキャスト通信のための対応するＩＰアドレス、さらに、クライアント１２によって使用されるユニキャスト通信のためのＩＰアドレスをＩＮＩＴ ＡＣＫチャンクを表すデータに含めることによって、マルチキャスト受信機能を確認する。サーバ１０がＩＮＩＴ ＡＣＫチャンクを表すデータを受信すると、サーバ１０は、クライアント１２に送信されるＣＯＯＫＩＥ ＥＣＨＯチャンクを表すデータを用いて応答する。サーバ１０は、さらに、クライアント１２とのＳＴＣＰアソシエーションのためにサーバ側でＴＣＢを表すデータを生成する。クライアント１２がＣＯＯＫＩＥ ＥＣＨＯチャンクを表すデータを受信すると、クライアント１２は、サーバ１０にＣＯＯＫＩＥ ＡＣＫチャンクを表すデータを送信し、クライアント側のＳＣＴＰアソシエーションのためにＴＣＢを表すデータを生成する。このタイプのアソシエーションは、さらに、図１において、アソシエーションＡ２４として表されよう。
【００３２】
サーバ１０が後続するＳＣＴＰアソシエーション・リクエストを別のクライアント、例えば、クライアント１４から受信すると、追加的なＳＣＴＰ、例えば、図１に示されたアソシエーションＢ２６をセットアップするために、上記に概略説明したものと同じ手順を行うことができる。複数のアソシエーションがセットアップされることがあり、これらのアソシエーションは、１対多のＳＣＴＰソケットに属してもよく、複数の１対１のＳＣＴＰソケットに属してもよい。具体的には、複数のＳＣＴＰアソシエーションは、１つのＳＣＴＰトランスポート・ポート・アドレスを共有してもよく、その代わりに、各アソシエーションは、自己のポート・アドレスを有してもよい。
【００３３】
ユニキャスト・フィードバック機能が無く、マルチキャスト受信機能のみをサポートするクライアント、例えばクライアント１６など、については、ＳＣＴＰアソシエーションをクライアントとサーバ１０との間でセットアップすることができない。しかしながら、サーバ１０とクライアント１２および１４などのクライアントとの間でデータ・パケットがＳＣＴＰアソシエーションを用いて配信されると、これらのクライアントは、特定のデータ・パケットがマルチキャスト・アクセス・ネットワークを介してクライアント１６に送信されることを指定することがある。この本発明の構成においては、クライアント１６は、マルチキャスト・ネットワークからの情報を受信できるだけの受動的な受信機として表すことができる。具体的には、クライアント１２および／または１４は、特定のリクエストをサーバ１０に送信することにより、特定のデータ・パケットを、データのリクエストおよび受信のためにクライアント１２、１４、および１６がサービスの利用契約をしているマルチキャスト・アクセス・ネットワーク２０および２２に送信することがある。クライアント１６は、マルチキャスト・アクセス・ネットワーク２０、２２からデータを受信可能である。アソシエーション・データに応答して、サーバ１０は、各データ・パケットが送信される送信先ネットワークを決定する。
【００３４】
ＳＣＴＰアソシエーションがサーバ１０と各々のクライアント１２、１４、１６との間で確立されると、データ交換をサーバ１０とクライアントとの間で開始できる。図１に示されるように、サーバ１０は、複数のクライアントとの複数のＳＣＴＰアソシエーションを設定できる。各アソシエーションは、サーバ１０とクライアント１２、１４、および１６との通信リンクを表すマルチキャスト・パスを含む。ＳＣＴＰアソシエーションが設定されると、サーバ１０は、ＳＣＴＰを使用して、対応するアソシエーションを使用する各クライアントに対し、データ・パケットを送信することができる。サーバ１０は、ＳＣＴＰを用いてクライアント１２および１４と通信するため、サーバ１０は、リクエストされたデータ・パケットの複数のコピーをマルチキャスト・アクセス・ネットワーク２０および２２に送信する。しかしながら、この結果、帯域幅の効率が低下する。この問題を取り扱うために、本発明の構成は、ＳＣＴＰに関わる非効率を最小限にし、マルチキャスト・アクセス・ネットワーク２０および２２の効率性を活用する、ＳＣＴＰの領域外のトラフィック・オプティマイザ・モジュール２８および３０を追加することにより、マルチキャスト・ネットワーク・パスのマルチキャスト機能を向上させる。図１は、サーバ１０に結合された２つのトラフィック・オプティマイザ２８および３０を示している。サーバ１０と、クライアントによってアクセス可能な各々のマルチキャスト・アクセス・ネットワーク２０および２２との間にＭＢＳのためのトラフィック・オプティマイザ２８、または、ＤＶＢ−Ｈのためのトラフィック・オプティマイザ３０が接続されている。
【００３５】
図１に示されたトラフィック・オプティマイザ・モジュール２８および３０は、ネットワークのトラフィックを軽減するために存在する。本発明の構成においては、トラフィック・オプティマイザは、さらに、マルチキャスト・ネットワークを介して、データ・アソシエーションを使用して、サーバからクライアントにデータ・パケットを容易に送信できるようにする機能を有する。さらに、トラフィック・オプティマイザは、サーバから受信したデータを処理して、ネットワークのリソースが最も効率的となる方法で、確実に正しいデータが適切なクライアントに送信されるようにする。例えば、特定のクライアントが大きな帯域幅を使用するヘビー・ユーザである場合、または、一般的に、ネットワーク内でトラフィックの混雑が存在する場合には、確実に帯域幅が相応に使用され、割り当てられるようにするため、トラフィック・オプティマイザは、受信したデータ・パケットを処理し、さらに、ネットワークの状況を監視することがある。
【００３６】
図２は、例示的なトラフィック・オプティマイザ２８内部の各コンポーネントを示すブロック図である。通信プロセッサ２０８は、クライアントのために意図されたアソシエーション・データおよびデータ・パケットをサーバ１０から受信する。通信プロセッサ２０８は、ＩＰアドレス・リポジトリ２１０に結合される。このＩＰアドレス・リポジトリ２１０は、通信パスを確立するために使用されるサーバ１０およびクライアント１２、１４、１６のＩＰアドレスを含むアソシエーション情報を受信し、格納するコンピュータ化された記憶媒体を含むことがある。トラフィック・オプティマイザ２８が正確なクライアントＩＰアドレスに対してデータを適切にルーティングできるようにするために、ＩＰアドレスを表すアソシエーション・データが格納される。ＩＰアドレス・リポジトリ２１０は、トラフィック・オプティマイザ２８に対し、データ・パケットの発信元および送信先についての情報を提供する。さらに、パケット・バッファ２２０は、通信プロセッサ２０８に結合され、サーバ１０からのデータ・パケットを受信し、分析されるデータ・パケットの量が十分になるまで、データ・パケットを格納する。受信され、格納されたデータ・パケットは、クライアント１２および１４のいずれかによってリクエストされたコンテンツに対応する。必要な数のデータ・パケットが受信されると、パケット・バッファ２２０に結合されたパケット分析器２３０は、パケット・バッファ２２０からの記憶されたデータ・パケットを構文解析し（ｐａｒｓｅ）、そのパケットを分析してデータ・パケットの最も完全なセットを特定するか、同一のデータの余分なコピーを見つける。パケット分析器２３０は、記憶されたデータ・パケットのシーケンス番号と比較するために、データ・パケットのシーケンス番号のリスト、またはデータ・パケットに関連付けられたポインタのリストを使用することによって分析および識別を行う。これらのデータ・パケットは、クライアント１２および／または１４によってサーバ１０からリクエストされたデータを表す。
【００３７】
パケット・プロセッサ２４０は、パケット分析器２３０に結合されており、パケット分析器２３０からの分析されたデータ・パケットとその分析結果を受信する。これにより、パケット・プロセッサ２４０は、クライアントに対してデータ・パケットの最も完全なセットを送信するか、同一のデータの余分なコピーを除去してデータの１つのコピーのみを送信することができる。余分なコピーの全ては、ドロップされて破棄され、その一方で、データの１つのコピーがマルチキャスト・アクセス・ネットワークへの送信のために保持される。結果として、複数のクライアントのために複数のデータ・パケットの代わりにデータ・パケットの１つのコピーのみが送信されるため、使用される帯域幅が少なくなる。さらに、ネットワーク混雑や接続障害が生じたりしている場合では、データ・パケットの最も完全なセットが、送信におけるデータや効率の損失がより確実に最小であるように送信される。パケット・プロセッサ２４０によって送信されるデータ・パケットが、確実に正しいクライアントに送信されるように、パケット・プロセッサ２４０は、クライアントとサーバ１０間の様々なアソシエーションのＩＰアドレスを含むＩＰアドレス・リポジトリ２１０にも結合されている。
【００３８】
具体的には、パケット・プロセッサ２４０は、ＩＰアドレス・リポジトリ２１０にクエリーを行って、どの特定のクライアントまたはアクセス・ネットワークのＩＰアドレスが特定のデータ・パケットを受信することになるかを表すデータを用いて応答する。以下の各段落は、図１に描かれたクライアント１２、１４、１６、サーバ１０、および、ネットワーク１８、２０、および２２とのトラフィック・オプティマイザ２８の相互接続に関連したトラフィック・オプティマイザ２８の機能に関する更なる詳細な説明を提供するものである。
【００３９】
図３は、サーバ１０から各々のクライアントへのデータ・パケットの送信効率を向上させるためにトラフィック・オプティマイザ２８によって行われる各ステップのフローチャートを示す。この処理は、ステップ３１０で開始し、このステップ３１０で、トラフィック・オプティマイザ２８は、データ・パケットが送信される場所および方法を識別する特定のクライアント／サーバのアソシエーションからＩＰアドレスを取得する。ステップ３２０において、トラフィック・オプティマイザ２８は、サーバ１０からデータ・パケットを受信する。受信されたデータ・パケットは、全て、クライアントの特定の送信先ＩＰアドレスと、データ・パケットの送信先を示す対応するアソシエーション情報にリンクされている。ステップ３３０において、トラフィック・オプティマイザ２８は、サーバ１０によって送信された受信パケットのバッファリングを行う。サーバ１０は、マルチキャスト・ネットワークにおいて、全てのクライアントに同一のデータ・パケットを送信しなければならないため、個々のアソシエーションに対応するトラフィック・オプティマイザ２８がサーバ１０から受信するデータ・パケットは同一となる。結果として、ステップ３４０において、トラフィック・オプティマイザ２８は、データ・パケットを分析して同一のデータの余分なコピーを特定することができる。次に、ステップ３５０において、トラフィック・オプティマイザ２８は、同一のデータの余分なコピーを除去するために、分析されたデータを処理し、データ・パケットの１つのコピーのみが送信先ネットワークに転送されるようにする。ステップ３６０は、送信先クライアントのＩＰアドレスを含むアソシエーション・データと共にデータ・パケットの１つのコピーを含む処理されたデータを配信するトラフィック・オプティマイザ２８に関わる。このデータは送信先ネットワークに転送され、この送信先ネットワークは１つのネットワーク、全てのネットワークまたは、ネットワーク１８、２０、および２２を含むことがある。最終的には、送信先ネットワークは、クライアントの送信先ＩＰアドレスを含むアソシエーション・データに基づいて特定のクライアントにデータ・パケットを送信する役目を担う。
【００４０】
トラフィック・オプティマイザ２８の各ステップは、代替的には、サーバ１０の内部、例えば、ネットワーク層での処理として実行される。具体的には、トラフィック・オプティマイザ２８の各機能は、スタンドアロンなモジュールとしてではなく、代わりに、サーバ１０内で実施されることがある。トラフィック・オプティマイザ３０は図１に示されている追加のトラフィック・オプティマイザであり、ＤＶＢ−Ｈネットワーク２２を通じた通信の役目を担うトラフィック・オプティマイザ３０は、上述したトラフィック・オプティマイザ２８と同様に動作する。
【００４１】
クライアント１２および１４は、マルチキャスト・ネットワーク・パスを通じて配信された共通のデータ・パケットを受信してもよい。図１に示されているような追加的なユニキャスト・パスを有するクライアント、具体的には、クライアント１２および１４は、図１に示されたユニキャスト・ダウンリンクを介してサーバ１０からの追加のデータ・パケットを受信できることがある。ユニキャスト・パスを有する各クライアントは、複数の異なるデータ・パケットがマルチキャストを介して送信される代わりに、自己のユニキャスト・ダウンリンクを介して送信されるようにするために、特定のリクエストをサーバ１０に対して行うことができる。追加のデータ・パケットは、様々な理由でユニキャスト・ダウンリンクを介して送信されることがある。特定のデータは、特定のクライアントに特化していることもあれば、マルチキャスト・ネットワークの状態が良好でない場合には、特定のデータがユニキャストを介して送信されることが必要となることがある。
【００４２】
さらに、クライアント１２および１４は、ユニキャスト・アップリンクを介してサーバ１０に対し、マルチキャスト・パスを含み、アソシエーションにおける全てのパスために、選択的な受領確認（Ｓｅｌｅｃｔｉｖｅ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ（ＳＡＣＫ））を送信できる。ＳＡＣＫは、パケットが受信された旨の受領確認である。クライアントがＳＡＣＫを送信すると、クライアントは、受領確認により、特定のアソシエーションに対応するＩＰアドレスに対するサービスを提供可能であり、データの送受信に参加可能であることを確認する。
【００４３】
マルチキャスト・ネットワークにおいて、各クライアントの受信状態が異なることがあるため、さらに、データ・パケット損失の量がＳＡＣＫ内で報告される。従って、ＳＡＣＫは、さらに、複数のＳＣＴＰアソシエーションからのフィードバックとしての役目を果たす。パケット損失の量は、各アソシエーションの受ける受信障害のレベルが異なるため、複数の異なるアソシエーションについての複数の異なるＩＰアドレス間で異なる。受信障害は、特に、良好でないデータ受信状態によってデータの破損が起こることの多い無線通信ネットワークにおいて発生する。結果として、サーバ１０は、マルチキャスト・リンクを介して送信に失敗したデータ・パケットの再送信を、ユニキャストをサポートする個々のクライアントに対してユニキャスト・ダウンリンクを介して行い、接続およびデータ・パケットの復元を容易にできるようにする。これにより、マルチキャスト・リンクに遅延が生じている場合や、マルチキャスト・リンクが実行可能な選択肢ではない場合にも、クライアントが意図したデータを受信できるようにする安全機構を有するシステムを提供する。マルチキャスト・リンク内でデータの損失が生じたことをクライアントが検出すると、クライアントは、自己のユニキャスト・リンクを使用してサーバ１０にフィードバックを送信してユニキャスト・リンクを介してサーバに消失したデータを再送信するようにリクエストすることができる。
【００４４】
しかしながら、ＳＣＴＰトラフィックの混雑を制御する機構により、サーバ１０は、複数の特定の時点で、複数の異なるアソシエーションのための複数の異なるデータ・レートで、データ・パケットを送信することがある。図４は、複数の異なるアソシエーションに対応する複数の異なるＩＰアドレスに対して複数の異なるレートでサーバによってデータ・パケットが送信される場合にデータ・パケット送信を最適化するためにトラフィック・オプティマイザによって行われる各ステップのフローチャートを示す。結果として、複数のアソシエーションのための複数の異なるデータ・パケットは、複数の異なる時点にトラフィック・オプティマイザ２８に到達することがある。従って、トラフィック・オプティマイザ２８は、データ・パケットを分類して、確実に特定のデータ・パケットが正しいクライアントに到達し、これらのデータ・パケットが可能な限り完全となるようにする。この処理は、ステップ４１０で開始し、このステップ４１０で、トラフィック・オプティマイザ２８は、アクセス・ネットワークを介して送信されるデータ・パケットのための対応するアソシエーションから送信先ＩＰアドレスを取得する。ステップ４２０において、トラフィック・オプティマイザ２８は、様々なクライアントに対する意図した送信先を有するサーバ１０からデータ・パケットを、各々の対応するアソシエーションからのＩＰアドレスに基づいて受信する。ステップ４３０において、トラフィック・オプティマイザ２８は、受信したデータ・パケットをキャッシュする。次に、ステップ４４０において、キャッシュされたデータ・パケットが分析されて各クライアントによってリクエストされたコンテンツに対応するパケットの最も完全なセットを見つける。データ・パケットの不完全なセットは分析され、その後、ステップ４５０において、データ・パケットの実質的に完全な、または、完全なセットを形成するように、コンパイルされる。データ・パケットのシーケンス番号は、格納されたデータ・パケットのシーケンス番号と比較して、データ・パケットのセットが完全であるか、特定の部分を消失しているかを判定するために分析がなされる。ステップ４６０において、特定のクライアントに対する送信のために、実質的に完全な、または、完全なパケットのセットが送信先のマルチキャスト・ネットワークに転送される。
【００４５】
本発明の構成について記載した上述の各段落の内容は、ＳＣＴＰ−ＰＲを使用したシステムにも適用可能である。さらに、ＳＣＴＰ−ＰＲを使用したシステムにおいては、サーバ１０は、アソシエーションの特定のＩＰアドレスに、同一のアソシエーションの他のＩＰアドレスと比較して大量の遅延が発生する場合には、マルチキャスト・リンクを介した特定のデータ・パケットの送信をスキップすることができる。これにより、アソシエーションの特定のＩＰアドレスについて遅延の生じているマルチキャスト・リンクは、他のＩＰアドレスに既に送信済みのデータ・パケットに追いつくことができるようになる。特定のリンクが他のリンクと比較して損失が大きい場合には、良好な接続を有するリンクを介して送信されるデータ・パケットにデータ送信の遅延が生ずる。全てのデータ・パケットが、クライアントによって完全に受信されることが必要ではないため、サーバ１０は、どのデータ・パケットが遅延の生じているリンクを介して送信されているかを判定することができ、このようなデータ・パケットの送信を適切にスキップすることができる。この処理は、クライアントに対して透過性である。クライアントは、さらに、特定のマルチキャスト・リンクにおける過剰なパケット損失を報告することができる。過剰なパケット損失を表すデータを受信すると、サーバ１０は、特定のマルチキャスト・リンクを使用するＩＰアドレスをその対応するアソシエーションから除去してクライアントの他のＩＰアドレスに対するデータ送信の遅延を防止することができる。
【００４６】
例示的な実施形態の観点から構成を説明したが、このような例示的な実施形態に限定されるものではない。むしろ、付随する請求項は、本構成に均等な範囲および領域を逸脱することなく、本構成の他の変形例および実施形態を含むように解釈されるべきである。本開示内容は、本明細書に記載された各実施形態の適用例、改変例を全て包含するように意図されている。
【特許請求の範囲】
【請求項１】
マルチキャスト・ネットワークを介したサーバと複数のクライアントのうちの少なくとも１つのクライアントとの間のユニキャスト・プロトコルを使用するデータ・パケットの通信を容易にするトラフィック・オプティマイザであって、
アソシエーション・データを含むデータと前記データ・パケットとの両方を前記サーバから前記ユニキャスト・プロトコルを使用して受信する通信プロセッサであって、該アソシエーション・データが、該サーバのＩＰアドレスと通信のために利用可能な複数のクライアントのうちの少なくとも１つのクライアントのＩＰアドレスとを含む、前記通信プロセッサと、
前記データ・パケットの分析に応じてデータ転送を最適化するために前記データ・パケットを処理し、処理されたデータ・パケットを、前記受信したＩＰアドレスの各々における複数のクライアントのうちの少なくとも１つのクライアントに、ユニキャスト・プロトコルを使用してマルチキャスト・ネットワークを介して転送するパケット・プロセッサと、
を備える、前記トラフィック・オプティマイザ。
【請求項２】
前記ユニキャスト・プロトコルは、ＳＣＴＰおよびＳＣＴＰ−ＰＲのうちの一方である、請求項１に記載の装置。
【請求項３】
前記処理されたデータ・パケットを転送するために、前記パケット・プロセッサによるアクセスのための前記アソシエーション・データを格納するＩＰアドレス・リポジトリをさらに備える、請求項１に記載の装置。
【請求項４】
前記データ・パケットが処理される前に、予期された数のデータ・パケットが受信されるまで、前記受信したデータ・パケットをバッファリングするパケット・バッファをさらに備える、請求項１に記載の装置。
【請求項５】
必要な処理のタイプを判定するために、前記バッファリングされたデータ・パケットを分析するパケット分析器をさらに備える、請求項４に記載の装置。
【請求項６】
どのデータ・パケットが余分であるかを判定することによって前記バッファリングされたデータ・パケットが分析され、前記パケット・プロセッサは、余分であるデータ・パケットを除去することによって前記データ・パケットを処理する、請求項５に記載の装置。
【請求項７】
どのデータ・パケットがデータの最も完全なセットを保持するかを判定することによって前記バッファリングされたデータ・パケットが分析され、前記パケット・プロセッサは、データ・パケットの実質的に完全なセットをコンパイルすることによって前記データ・パケットを処理する、請求項５に記載の装置。
【請求項８】
クライアントは、前記サーバに対して、マルチキャスト・ネットワークからデータ・パケットが適切に受信されていることを示す受領確認と、パケットが遅延しているかどうかを含む情報とを送信する、請求項１に記載の装置。
【請求項９】
前記トラフィック・オプティマイザは、クライアントが前記マルチキャスト・ネットワークを介して前記データ・パケットを受信した後、パケットが遅延していることを示すインジケーションに基づいて、前記サーバからアソシエーションの特定のＩＰアドレスへの或るデータ・パケットの送信をスキップするインストラクションを受信する、請求項８に記載の装置。
【請求項１０】
前記トラフィック・オプティマイザは、クライアントが前記マルチキャスト・ネットワークを介して前記データ・パケットを受信した後、特定のＩＰアドレスに大幅なパケット遅延が生じていると判定された場合に、前記サーバからインストラクションを受信してアソシエーションからＩＰアドレスを除去する、請求項８に記載の装置。
【請求項１１】
トラフィック・オプティマイザにより、マルチキャスト・ネットワークを介したサーバと複数のクライアントのうちの少なくとも１つのクライアントとの間のユニキャスト・プロトコルを使用するデータ・パケットの通信を容易にする方法であって、
アソシエーション・データを含むデータと前記データ・パケットとの両方を前記サーバから前記ユニキャスト・プロトコルを使用して受信するステップであって、該アソシエーション・データが、該サーバのＩＰアドレスと通信のために利用可能な複数のクライアントのうちの少なくとも１つのクライアントのＩＰアドレスとを含む、前記受信するステップと、
前記データ・パケットの分析に応じてデータ転送を最適化するために前記分析されたデータ・パケットを処理するステップと、
前記処理されたデータ・パケットを、受信したＩＰアドレスの各々における複数のクライアントのうちの少なくとも１つのクライアントに、ユニキャスト・プロトコルを使用してマルチキャスト・ネットワークを介して転送するステップと、
を含む、前記方法。
【請求項１２】
予期された数のデータ・パケットが受信されるまで、前記受信したデータ・パケットをバッファリングするステップをさらに含む、請求項１１に記載の方法。
【請求項１３】
必要な処理のタイプを判定するために、前記バッファリングされたデータ・パケットを分析するステップをさらに含む、請求項１２に記載の方法。
【請求項１４】
どのデータ・パケットが余分であるかを判定することによって分析が行われ、余分であるデータ・パケットを除去することによって処理が行われる、請求項１３に記載の方法。
【請求項１５】
どのデータ・パケットがデータの最も完全なセットを保持するかを判定することによって分析が行われ、データ・パケットの実質的に完全なセットをコンパイルすることによって処理が行われる、請求項１３に記載の方法。
【請求項１６】
クライアントにより、前記サーバに対して、マルチキャスト・ネットワークからデータ・パケットが適切に受信されていることを示す受領確認と、パケットが遅延しているかどうかを含む情報とを送信するステップをさらに含む、請求項１１に記載の方法。
【請求項１７】
クライアントが前記マルチキャスト・ネットワークを介して前記データ・パケットを受信した後、パケットが遅延していることを示すインジケーションに基づいて、前記サーバからアソシエーションの特定のＩＰアドレスへの或るデータ・パケットの送信をスキップするステップをさらに含む、請求項１６に記載の方法。
【請求項１８】
クライアントが前記マルチキャスト・ネットワークを介して前記データ・パケットを受信した後、特定のＩＰアドレスに大幅なパケット遅延が生じていると判定された場合に、アソシエーションからＩＰアドレスを除去するステップをさらに含む、請求項１６に記載の方法。
【請求項１９】
前記ユニキャスト・プロトコルは、ＳＣＴＰおよびＳＣＴＰ−ＰＲのうちの一方である、請求項１１に記載の方法。
【請求項１】
マルチキャスト・ネットワークを介したサーバと複数のクライアントのうちの少なくとも１つのクライアントとの間のユニキャスト・プロトコルを使用するデータ・パケットの通信を容易にするトラフィック・オプティマイザであって、
アソシエーション・データを含むデータと前記データ・パケットとの両方を前記サーバから前記ユニキャスト・プロトコルを使用して受信する通信プロセッサであって、該アソシエーション・データが、該サーバのＩＰアドレスと通信のために利用可能な複数のクライアントのうちの少なくとも１つのクライアントのＩＰアドレスとを含む、前記通信プロセッサと、
前記データ・パケットの分析に応じてデータ転送を最適化するために前記データ・パケットを処理し、処理されたデータ・パケットを、前記受信したＩＰアドレスの各々における複数のクライアントのうちの少なくとも１つのクライアントに、ユニキャスト・プロトコルを使用してマルチキャスト・ネットワークを介して転送するパケット・プロセッサと、
を備える、前記トラフィック・オプティマイザ。
【請求項２】
前記ユニキャスト・プロトコルは、ＳＣＴＰおよびＳＣＴＰ−ＰＲのうちの一方である、請求項１に記載の装置。
【請求項３】
前記処理されたデータ・パケットを転送するために、前記パケット・プロセッサによるアクセスのための前記アソシエーション・データを格納するＩＰアドレス・リポジトリをさらに備える、請求項１に記載の装置。
【請求項４】
前記データ・パケットが処理される前に、予期された数のデータ・パケットが受信されるまで、前記受信したデータ・パケットをバッファリングするパケット・バッファをさらに備える、請求項１に記載の装置。
【請求項５】
必要な処理のタイプを判定するために、前記バッファリングされたデータ・パケットを分析するパケット分析器をさらに備える、請求項４に記載の装置。
【請求項６】
どのデータ・パケットが余分であるかを判定することによって前記バッファリングされたデータ・パケットが分析され、前記パケット・プロセッサは、余分であるデータ・パケットを除去することによって前記データ・パケットを処理する、請求項５に記載の装置。
【請求項７】
どのデータ・パケットがデータの最も完全なセットを保持するかを判定することによって前記バッファリングされたデータ・パケットが分析され、前記パケット・プロセッサは、データ・パケットの実質的に完全なセットをコンパイルすることによって前記データ・パケットを処理する、請求項５に記載の装置。
【請求項８】
クライアントは、前記サーバに対して、マルチキャスト・ネットワークからデータ・パケットが適切に受信されていることを示す受領確認と、パケットが遅延しているかどうかを含む情報とを送信する、請求項１に記載の装置。
【請求項９】
前記トラフィック・オプティマイザは、クライアントが前記マルチキャスト・ネットワークを介して前記データ・パケットを受信した後、パケットが遅延していることを示すインジケーションに基づいて、前記サーバからアソシエーションの特定のＩＰアドレスへの或るデータ・パケットの送信をスキップするインストラクションを受信する、請求項８に記載の装置。
【請求項１０】
前記トラフィック・オプティマイザは、クライアントが前記マルチキャスト・ネットワークを介して前記データ・パケットを受信した後、特定のＩＰアドレスに大幅なパケット遅延が生じていると判定された場合に、前記サーバからインストラクションを受信してアソシエーションからＩＰアドレスを除去する、請求項８に記載の装置。
【請求項１１】
トラフィック・オプティマイザにより、マルチキャスト・ネットワークを介したサーバと複数のクライアントのうちの少なくとも１つのクライアントとの間のユニキャスト・プロトコルを使用するデータ・パケットの通信を容易にする方法であって、
アソシエーション・データを含むデータと前記データ・パケットとの両方を前記サーバから前記ユニキャスト・プロトコルを使用して受信するステップであって、該アソシエーション・データが、該サーバのＩＰアドレスと通信のために利用可能な複数のクライアントのうちの少なくとも１つのクライアントのＩＰアドレスとを含む、前記受信するステップと、
前記データ・パケットの分析に応じてデータ転送を最適化するために前記分析されたデータ・パケットを処理するステップと、
前記処理されたデータ・パケットを、受信したＩＰアドレスの各々における複数のクライアントのうちの少なくとも１つのクライアントに、ユニキャスト・プロトコルを使用してマルチキャスト・ネットワークを介して転送するステップと、
を含む、前記方法。
【請求項１２】
予期された数のデータ・パケットが受信されるまで、前記受信したデータ・パケットをバッファリングするステップをさらに含む、請求項１１に記載の方法。
【請求項１３】
必要な処理のタイプを判定するために、前記バッファリングされたデータ・パケットを分析するステップをさらに含む、請求項１２に記載の方法。
【請求項１４】
どのデータ・パケットが余分であるかを判定することによって分析が行われ、余分であるデータ・パケットを除去することによって処理が行われる、請求項１３に記載の方法。
【請求項１５】
どのデータ・パケットがデータの最も完全なセットを保持するかを判定することによって分析が行われ、データ・パケットの実質的に完全なセットをコンパイルすることによって処理が行われる、請求項１３に記載の方法。
【請求項１６】
クライアントにより、前記サーバに対して、マルチキャスト・ネットワークからデータ・パケットが適切に受信されていることを示す受領確認と、パケットが遅延しているかどうかを含む情報とを送信するステップをさらに含む、請求項１１に記載の方法。
【請求項１７】
クライアントが前記マルチキャスト・ネットワークを介して前記データ・パケットを受信した後、パケットが遅延していることを示すインジケーションに基づいて、前記サーバからアソシエーションの特定のＩＰアドレスへの或るデータ・パケットの送信をスキップするステップをさらに含む、請求項１６に記載の方法。
【請求項１８】
クライアントが前記マルチキャスト・ネットワークを介して前記データ・パケットを受信した後、特定のＩＰアドレスに大幅なパケット遅延が生じていると判定された場合に、アソシエーションからＩＰアドレスを除去するステップをさらに含む、請求項１６に記載の方法。
【請求項１９】
前記ユニキャスト・プロトコルは、ＳＣＴＰおよびＳＣＴＰ−ＰＲのうちの一方である、請求項１１に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２０１３−５１３９９６（Ｐ２０１３−５１３９９６Ａ）
【公表日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願番号】特願２０１２−５４３０５６（Ｐ２０１２−５４３０５６）
【出願日】平成２１年１２月１０日（２００９．１２．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００９／００６４９０
【国際公開番号】ＷＯ２０１１／０７１４７４
【国際公開日】平成２３年６月１６日（２０１１．６．１６）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
【公表日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願日】平成２１年１２月１０日（２００９．１２．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００９／００６４９０
【国際公開番号】ＷＯ２０１１／０７１４７４
【国際公開日】平成２３年６月１６日（２０１１．６．１６）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
[ Back to top ]