JP6501265B2 - クライアントデバイスにオーディオビジュアルコンテンツを配信するためのシステム及び方法 - Google Patents

Description

本発明は、一般に、クライアントデバイスにオーディオビジュアルコンテンツを配信することに関し、相互接続デバイスが、オーディオビジュアルコンテンツを提供するように適合された装置が接続されている第１のネットワークを、クライアントデバイスが接続されている第２のネットワークに相互接続する。

アダプティブビットレートストリーミング（ＡＢＳ）は、コンピュータネットワークを介してマルチメディアをストリーミングする際に使用される１つの一般的なＨＴＴＰストリーミング技術であり、ＨＴＴＰ（規範文書ＲＦＣ２６１６に規定される「ハイパーテキスト転送プロトコル」）に基づくメディアストリーミング通信プロトコルである、Ａｐｐｌｅ社によって開発されたＨＬＳ（「ＨＴＴＰライブストリーミング」）が１つの特定の実装である。ＨＬＳは、全体的なＡＶストリームを一連の小さなＨＴＴＰベースのファイルダウンロードに分けることによって動作し、これらのファイルダウンロードの各々は、潜在的に無限のトランスポートストリーム全体のうちの１つの短いチャンクを含む。ストリームの再生時には、このＡＶストリームを復号するクライアントデバイスが、同じ素材を含む様々なビットレートで符号化された複数の異なるストリームから選択を行って、利用可能なネットワークリソース及び／又はクライアントデバイスの処理リソースにストリーミングセッションを適合させることができる。クライアントデバイスは、ストリーミングセッションの開始時に、Ｍ３Ｕ又はｍ３ｕ８というファイル拡張子が付いたテキストファイルの形のプレイリストをダウンロードする。このテキストファイルは、関連するＡＶコンテンツに利用できる様々なストリームのためのメタデータを含む。それぞれのビットレートに対応する様々なストリームは、レイヤとも呼ばれる。

Ｍｉｃｒｏｓｏｆｔ社が提供するＨＴＴＰベースの統合メディア配信プラットフォームであるインターネットインフォメーションサービス（ＩＩＳ）メディアサービスの一機能であるスムーズストリーミングによっても同様のＡＢＳ法が実施される。ＨＬＳでは、ＡＶストリームを、プレイリストファイルで補完されたチャンクを含む複数のファイルに区切るが、これに対して、スムーズストリーミングは、関連するレイヤを示す記述子とＡＶコンテンツ内の参照時間とを各々が含むファイル片に区切られた単一のＡＶファイルに依拠する。しかしながら、プロトコルの原則及び利点は同等である。

同様に、Ａｄｏｂｅ Ｓｙｓｔｅｍｓ社のＨＴＴＰダイナミックストリーミング（ＨＤＳ）、並びにＨＤＳ、ＨＬＳ及びスムーズストリーミングに関連するマルチメディアストリーミング技術である、動画専門グループによって開発されたＭＰＥＧ ＤＡＳＨと呼ばれるダイナミックアダプティブストリーミングオーバーＨＴＴＰを検討することもできる。

ＨＴＴＰは、ＴＣＰ（規範文書ＲＦＣ７９３によって規定される「伝送制御プロトコル」）に依拠することによってファイアウォールの通過を可能にするとともにデータの完全性を保証するので、ＨＴＴＰベースのストリーミング技術は非常に便利である。しかしながら、ＡＢＳの状況におけるＨＴＴＰのユニキャスト性は、コンテンツデリバリネットワーク（ＣＤＮ）のオペレータに対し、ライブストリーミングにＡＢＳを採用することを妨げるという大規模なスケーラビリティ問題を引き起こす。さらに、ＴＣＰがレイテンシをもたらす可能性もあり、データ転送中の接続ロスは、ユーザの立場から見た体感品質（ＱｏＥ）に強い影響を与える。

ライブストリーミングのためにＡＢＳをスケーラブルに実行するには、数多くのユーザが同時に同じチャネルを視聴する結果、数多くのユニキャストセッションが同時に生じることによって引き起こされるスケーラビリティ問題をネットワークサービスのオペレータが解決する必要がある。

注目すべきは、オーディオビジュアルコンテンツを搬送するストリームのビットレートが適応的なものであれ又は固定的なものであれ、このような問題が、ユニキャストセッションに基づくオーディオビジュアルコンテンツ配信という一般的な状況で生じる点である。

より一般的に言えば、問題が生じるのは、ＣＤＮオペレータがＣＤＮにおいて新たなインフラ又はサービスを提供し、又は提供しようと考えているにも関わらず、クライアントデバイスが既存の機構に依拠している時である。通常、クライアントデバイスは、ＣＤＮオペレータ以外の団体によって開発されたものであるため、これらの新たなインフラ及び／又はサービスを採用するようにクライアントデバイスをアップグレードすることは設定が困難となり得る。実際に、ゲートウェイとは異なり、このようなクライアントデバイスは、例えばＣＤＮオペレータとは関係のない企業によって開発された、スマートフォン、タブレット、ＰＣ（パーソナルコンピュータ）ゲーム機、コネクテッドＴＶなどにおいて動作するアプリケーションソフトウェアであり、また市場には多くのアプリケーション又はプレーヤが存在しており、従って全てのアプリケーション又はプレーヤがこれらの新たなインフラ又はサービスに対応できるようにするにはコストのかかる統合及び検証過程が必要になる。

第１の態様によれば、このような新たなインフラ又はサービスは、ＣＤＮを背景とした既存のコンテンツ配信機構のユニキャスト性に関連する上述のスケーラビリティ問題をクライアントデバイスにとって透過的な形で克服することを目的とする。

第２の態様によれば、このような新たなインフラ又はサービスは、ユーザの立場から見て改善されたＱｏＥを、クライアントデバイスにとって透過的な形で提供することを目的とする。例えば、このような新たなインフラ又はサービスは、ＡＶコンテンツの配信中における接続ロスによるＱｏＥへの影響を克服することを目的とする。

上述した先行技術の短所を克服することが望ましい。

具体的には、オーディオビジュアルコンテンツ配信の状況において新たなインフラ又はサービスの導入を可能にする解決策をクライアントデバイスにとって透過的な形で提供することが望ましい。

さらに、オーディオビジュアルコンテンツ配信の状況においてネットワーク帯域幅消費の削減を可能にする解決策をクライアントデバイスにとって透過的な形で提供することが望ましい。

アダプティブビットレートストリーミングというさらなる状況においてネットワーク帯域幅消費の削減を可能にする解決策をクライアントデバイスにとって透過的な形で提供することがさらに望ましい。

さらに、ユーザの立場から見たＱｏＥの向上を可能にする解決策をクライアントデバイスにとって透過的な形で提供することが望ましい。

オーディオビジュアルコンテンツの配信において示唆されるデバイスの処理リソース消費の制限を可能にする解決策を提供することがさらに望ましい。

このため、本発明は、クライアントデバイスにオーディオビジュアルコンテンツを配信する方法に関し、相互接続デバイスが、オーディオビジュアルコンテンツを提供するように適合された装置が接続されている第１のネットワークを、クライアントデバイスが接続されている第２のネットワークに相互接続する。この方法では、上記装置が、オーディオビジュアルコンテンツを受け取るための第１の要求をクライアントデバイスから受け取るステップと、相互接続デバイス内に実装されているエージェントに向けてクライアントデバイスをリダイレクトするリダイレクトメッセージをクライアントデバイスに送信するステップとを実行する。さらに、この方法では、エージェントが、オーディオビジュアルコンテンツを受け取るための第２の要求をクライアントデバイスから受け取るステップと、この第２の要求に応答して、上記装置とクライアントデバイスとの間の中継器として動作するステップとを実行する。

相互接続デバイス内のエージェントに向けたリダイレクトを行うことにより、新たなインフラ又はサービスの採用が容易になるとともに、クライアントデバイスにとって透過的に行われる。実際に、例えばホームゲートウェイなどの相互接続デバイスは、クライアントデバイスとは違って一般にオペレータによって管理されているので、一般にＣＤＮオペレータにとっては、必要時にこのような相互接続デバイスのアップグレードを行うことの方がクライアントデバイスをアップグレードするよりも容易である。

特定の特徴によれば、上記第１及び第２の要求は、オーディオビジュアルコンテンツをユニキャストストリームの形で受け取るための要求であり、上記装置は、オーディオビジュアルコンテンツをライブストリーミングで提供するように適合され、上記装置は、オーディオビジュアルコンテンツが上記装置によって少なくとも１つのマルチキャストストリームの形で利用可能になっている時にリダイレクトメッセージをクライアントデバイスに送信し、上記エージェントは、中継器として動作する時に、上記少なくとも１つのマルチキャストストリームに参加するステップと、少なくとも１つのマルチキャストストリームの形で受け取ったデータをユニキャストストリームの形のデータに変換するステップとを実行する。

従って、第１のネットワークの帯域幅消費が削減され、相互接続デバイスの処理リソースの消費が制限される。実際に、エージェントは、第１のネットワーク全体にわたるマルチキャスト送信をセットアップする恩恵を確実にクライアントデバイスが受けるようにするために数多くのメッセージ交換をスヌープする必要がないので、処理リソースの消費が制限される。

特定の特徴によれば、リダイレクトメッセージは、少なくとも１つのマルチキャストアドレスと、少なくとも１つの関連ポートとを通知するパラメータを含み、オーディオビジュアルコンテンツをユニキャストストリームの形で受け取るための要求は、少なくとも１つのマルチキャストアドレスと、少なくとも１つの関連ポートとを通知する上記パラメータを含む。さらに、この方法では、上記エージェントが、少なくとも１つのマルチキャストアドレス及び少なくとも１つの関連ポートに対応する少なくとも１つのマルチキャストストリームに参加する。

従って、この方法は、上記装置の効果的な場所及び実装に関わらず、フレキシブルかつスケーラブルである。

特定の特徴によれば、リダイレクトメッセージは、少なくとも１つのマルチキャストストリームの形のオーディオビジュアルコンテンツに利用可能になっているレイヤの数量を通知するパラメータを含み、オーディオビジュアルコンテンツをユニキャストストリームの形で受け取るための要求は、レイヤの数量を通知する上記パラメータを含む。さらに、上記エージェントは、上記レイヤの数量に応じて、少なくとも１つのマルチキャストアドレス及び／又は少なくとも１つの関連ポートを決定する。

従って、第１のネットワーク全体にわたるマルチキャスト送信と、アダプティブビットレートストリーミングの原理とが、オーディオビジュアルコンテンツの配信のために共存することができる。

特定の特徴によれば、リダイレクトメッセージは、１つのマルチキャストアドレス及び１つの関連ポートを通知するとともに上記レイヤの数量を通知するパラメータを含み、オーディオビジュアルコンテンツをユニキャストストリームの形で受け取るための要求は、上記１つのマルチキャストアドレス及び上記１つの関連ポートを通知するとともに上記レイヤの数量を通知する上記パラメータを含む。さらに、上記エージェントは、上記要求に含まれる上記レイヤの数量、並びに上記１つのマルチキャストアドレス及び上記１つの関連ポートに応じて、レイヤ毎に１つのマルチキャストアドレスと、１つの関連ポートとを決定する。

特定の特徴によれば、リダイレクトメッセージは、１つのマルチキャストアドレス及び１つの関連ポートを通知するとともに上記レイヤの数量を通知するパラメータを含み、オーディオビジュアルコンテンツをユニキャストストリームの形で受け取るための要求は、上記１つのマルチキャストアドレス及び上記１つの関連ポートを通知するとともに上記レイヤの数量を通知する上記パラメータを含む。さらに、上記エージェントは、上記要求に含まれる上記レイヤの数量、並びに上記１つのマルチキャストアドレス及び上記１つの関連ポートに応じて、全てのレイヤのための１つのマルチキャストアドレスと、レイヤ毎に１つの関連ポートとを決定する。

従って、前述の２つの特定の特徴により、リダイレクトメッセージに含めるデータ量を制限できるようになる。

特定の特徴によれば、少なくとも１つのマルチキャストストリームの形のオーディオビジュアルコンテンツに複数のレイヤが利用可能になっており、上記装置は、ハイパーテキスト転送プロトコルライブストリーミングを用いてオーディオビジュアルコンテンツを提供するように適合され、リダイレクトメッセージは、オーディオビジュアルコンテンツのためのプレイリストに関連するユニフォームリソースロケータを表すパラメータを含み、オーディオビジュアルコンテンツをユニキャストストリームの形で受け取るための要求は、ユニフォームリソースロケータを表す上記パラメータを含む。さらに、上記エージェントは、上記ユニフォームリソースロケータに基づいて上記プレイリストを要求するステップと、上記プレイリストを受け取るステップと、上記プレイリストに解析動作を行って、各レイヤに関連する１つのプレイリストを決定するステップと、各参加したマルチキャストストリームから１つのレイヤプレイリストを受け取るステップと、上記受け取った（単複の）プレイリストをクライアントデバイスに送信するステップと、１つのレイヤに関連するプレイリストを指示する要求、又は１つのレイヤに関連するプレイリストのファイルを指示する要求をクライアントデバイスから受け取るステップと、１つのレイヤに関連する上記指示されたプレイリスト又は上記指示されたファイルに応じてマルチキャストストリームを選択するステップとを実行する。

従って、ＨＬＳの状況において、第１のネットワークの帯域幅消費が削減され、相互接続デバイスの処理リソース消費が制限される。

特定の特徴によれば、少なくとも１つのマルチキャストストリームの形のオーディオビジュアルコンテンツに複数のレイヤが利用可能になっており、エージェントは、１つのレイヤに対応する１つのマルチキャストストリームに参加しており、上記エージェントは、クライアントデバイスが上記１つのレイヤから別のレイヤへの切り替えを行う必要性を検出するステップと、上記別のレイヤに対応するマルチキャストストリームに参加するステップと、上記１つのレイヤに対応するマルチキャストストリームから離脱するステップとを実行する。

従って、帯域幅消費とシステムの応答性との間のトレードオフが発見され、第１のネットワークに関する帯域幅消費が改善される。

特定の特徴によれば、少なくとも１つのマルチキャストストリームの形のオーディオビジュアルコンテンツに複数のレイヤが利用可能になっており、エージェントは、１つのレイヤ及び別のレイヤにそれぞれ対応する少なくとも２つのマルチキャストストリームに参加しており、上記エージェントは、クライアントデバイスがレイヤ間で切り替えを行う必要性を検出するステップと、上記検出された必要性に応じて、上記少なくとも２つのマルチキャストストリームのうちの一方のマルチキャストストリームからのデータを選択するステップとを実行する。

従って、帯域幅消費とシステムの応答性との間のトレードオフが発見され、応答性が改善される。

特定の特徴によれば、上記第１及び第２の要求は、オーディオビジュアルコンテンツをユニキャストストリームの形で受け取るための要求であり、上記装置は、複数のソースによってオーディオビジュアルコンテンツが利用可能になっている時にクライアントデバイスにリダイレクトメッセージを送信し、上記エージェントは、中継器として動作する際に、上記オーディオビジュアルコンテンツを上記複数のソースに要求するステップと、上記複数のソースから受け取ったデータからユニキャストストリームを再現するステップとを実行する。

従って、クライアントデバイスを使用するユーザの立場から見たＱｏＥが向上する一方で、相互接続デバイスの処理リソース消費が制限され、及び／又は第１のネットワークのロードバランシングが改善される。

特定の特徴によれば、リダイレクトメッセージは、オーディオビジュアルコンテンツがどのソースから利用可能になっているかを通知するパラメータを含み、オーディオビジュアルコンテンツをユニキャストストリームの形で受け取るための要求は、上記パラメータを含む。

従って、この方法は、上記複数のソースの効果的な場所及び実装に関わらずフレキシブルかつスケーラブルである。

特定の特徴によれば、上記相互接続デバイスはホームゲートウェイであり、上記複数のソースは、上記装置のサーバ及び／又は他のホームゲートウェイである。

従って、ロードバランシングをさらに改善することができる。

特定の特徴によれば、リダイレクトメッセージは、オーディオビジュアルコンテンツの一時的な再配置を指示する。

従って、クライアントデバイスが、後でオーディオビジュアルコンテンツを取得しようと試みた時に再び確実に上記装置にコンタクトできるようになる。従って、上記装置は、オーディオビジュアルコンテンツが依然として少なくとも１つのマルチキャストストリームの形で利用可能になっているかどうかをチェックすることができる。

本発明は、クライアントデバイスにオーディオビジュアルコンテンツを配信するためのシステムにも関し、このシステムは、上記オーディオビジュアルコンテンツを提供するように適合された装置と、この装置が接続されることを目的とする第１のネットワークを、クライアントデバイスが接続されている第２のネットワークに相互接続することを目的とする相互接続デバイスとを備える。さらに、このシステムでは、上記装置が、オーディオビジュアルコンテンツを受け取るための第１の要求を受け取る手段と、相互接続デバイス内に実装されているエージェントに向けてクライアントデバイスをリダイレクトすることを目的とするリダイレクトメッセージを送信する手段とを有する。さらに、このシステムでは、上記エージェントが、オーディオビジュアルコンテンツを受け取るための第２の要求を受け取る手段と、この第２の要求に応答して、上記装置とクライアントデバイスとの間の中継器として動作する手段とを有する。

本発明は、通信ネットワークからダウンロードすることができ、及び／又は処理装置によって読み取ることができる媒体に記憶することができるコンピュータプログラムにも関する。このコンピュータプログラムは、プロセッサによって実行された時に上述の方法を実施させるための命令を含む。本発明は、このようなコンピュータプログラムを含むコンピュータプログラムを記憶する情報記憶手段にも関する。

上述のシステム及びコンピュータプログラムに関連する特徴及び利点は、対応する上述の方法に関連して説明した特徴及び利点と同じものであり、ここでは説明を繰り返さない。

本発明の特徴は、添付図面を参照しながら行う以下の実施形態例の説明を読むことによってさらに明らかになるであろう。

本発明による第１のシステムを概略的に示す図である。 本発明による第２のシステムを概略的に示す図である。 本発明によるシステムのデバイスアーキテクチャを概略的に示す図である。 本発明によるオーディオビジュアルコンテンツ配信アルゴリズムを概略的に示す図である。 本発明による、マルチキャストの状況におけるオーディオビジュアルコンテンツ配信アルゴリズムを概略的に示す図である。 本発明による、ＨＬＳマルチキャストの状況におけるオーディオビジュアルコンテンツ配信アルゴリズムを概略的に示す図である。 本発明による、マルチソースの状況におけるオーディオビジュアルコンテンツ配信アルゴリズムを概略的に示す図である。

オーディオビジュアルコンテンツ配信の状況において、処理リソースの消費を制限しながらクライアントデバイスが新たなＣＤＮインフラ又はサービスから恩恵を受けられるようにするために、オーディオビジュアルコンテンツを提供する装置宛てのリダイレクト要求を、この装置が接続されているネットワークと、クライアントデバイスが接続されているネットワークとを相互接続するネットワーク相互接続デバイス内に存在するエージェントにリダイレクトすることを提案する。このエージェントは、これに応答して、装置と、オーディオビジュアルコンテンツ配信の対象である少なくとも１つのクライアントデバイスとの間の中継器として動作する。要求をリダイレクトすることにより、相互接続デバイスを介して転送されるメッセージをエージェントがスヌープする必要なくこの目的を達成することができ、これにより相互接続デバイスの処理リソース消費が制限される。パフォーマンスの向上以外にも、提案するエージェントの障害がネットワーク相互接続デバイスの他のサービスに影響を及ぼすことはないと考えられ、このことは、相互接続デバイスを介して転送されるメッセージをエージェントがスヌープする必要がある場合には当てはまらない。相互接続デバイスがホームゲートウェイであると考えた場合、このようなスヌーピングを行うエージェントに障害が生じると、ブロードバンド接続がシャットダウンされてしまう。この場合、加入者は、ボイスオーバーＩＰ、データ及びテレビなどの異なる重要サービスの喪失を被る必要性が生じる。さらに、提案するエージェントは、ネットワーク相互接続デバイスを通過する全てのトラフィックを傍受するわけではないので、プライバシー／機密性の問題は生じないと考えられる。

図１Ａに、本発明による第１のシステムを概略的に示す。このシステムは、第１のネットワーク１１０と第２のネットワーク１２０を相互接続するように適合されたホームゲートウェイなどのネットワーク相互接続デバイス１０１を含む。システムは、ＣＤＮを通じてオーディオビジュアル（ＡＶ）コンテンツの記述を入手できるウェブサイトを提供するポータルサーバをさらに含む。システムは、ウェブサイトを介して記述されるＡＶコンテンツにアクセスしてさらにユーザに表示できるようにするＣＤＮサーバ１１２をさらに含む。ＣＤＮサーバ１１２は、要求時にＡＶコンテンツをユニキャストで配信するように適合される。ＣＤＮサーバ１１２は、上述したＡＶコンテンツの記述において、上記ＡＶコンテンツを提供する装置として参照される。システムは、上記ＡＶコンテンツの一部又は全部をマルチキャストで配信するように適合されたマルチキャストサーバ１１３などの追加サーバをさらに含むことができる。ポータルサーバ１１１、ＣＤＮサーバ１１２及び上記追加サーバは、第１のネットワーク１１０に接続される。

なお、ポータルサーバ１１１、ＣＤＮサーバ１１２及び上記追加サーバは、単一のハードウェアプラットフォーム上に実装される機能に対応することができる。換言すれば、ポータルサーバ１１１、ＣＤＮサーバ１１２及びマルチキャストサーバ１１３は、第１のネットワーク１１０に接続されてクライアントデバイスにＡＶコンテンツを提供するように適合された装置を構成する。

好ましい実施形態では、ＣＤＮサーバ１１２が、ＨＬＳを用いてＡＶコンテンツを配信するように適合され、従ってＡＢＳの実装を可能にする。しかしながら、ＣＤＮサーバ１１２が、スムーズストリーミング、ＨＤＳ又はＭＰＥＧ ＤＡＳＨを用いてＡＶコンテンツを配信するように適合されている場合にも同じ原理が当てはまる。

１つの実施形態では、マルチキャストサーバ１１３が、ＵＤＰ（規範文書ＲＦＣ７６８によって規定される「ユーザデータグラムプロトコル」）上のＲＴＰ（規範文書ＲＦＣ３５５０によって規定される「リアルタイムトランスポートプロトコル」）を用いて、上記ＡＶコンテンツのうちの少なくとも１つのＡＶコンテンツを配信するように適合される。

ネットワーク相互接続デバイス１０１が第１のネットワーク１１０と第２のネットワーク１２０を相互接続することにより、第２のネットワーク１２０に接続されたクライアントデバイス１２１は、このネットワーク相互接続デバイス１０１を介して、ポータルサーバ１１１、ＣＤＮサーバ１１２及び上記追加サーバによって提供されるサービスにアクセスできるようになる。ネットワーク相互接続デバイス１０１は、ＣＤＮ装置とクライアントデバイス１２１の間の中継器として動作するエージェント１０２を含む。エージェント１０２及びＣＤＮ装置の動作については、以下で図３〜図６に関連して詳細に説明する。

図１Ｂに、本発明による第２のシステムを概略的に示す。図１Ｂのシステムは、マルチキャストサーバ１１３が複数のＡＶサーバ１１４、１１５に置き換わっている点を除き、図１Ａのシステムと同様のものである。各ＡＶサーバは、潜在的に異なるビットレート、すなわちレイヤでＡＶコンテンツの少なくとも一部を配信することができる。ＡＶサーバ１１４、１１５は、全体として見れば完全なＡＶコンテンツを提供するように適合されるが、各ＡＶサーバ１１４、１１５は、ＡＶコンテンツの一部、又はＣＤＮにおいて利用できるＡＶコンテンツのためのレイヤのサブセットのみを提供できればよい。第１の例によれば、ＡＶサーバ１１４がＡＶコンテンツを低解像度で提供し、ＡＶサーバ１１５がＡＶコンテンツを高解像度で提供することができる。第２の例によれば、ＡＶサーバ１１４が各ＡＶコンテンツの一部を提供し、ＡＶサーバ１１５が各ＡＶコンテンツの残り部分を提供することができる。第３の例によれば、各ＡＶサーバ１１４、１１５が全てのＡＶコンテンツを低解像度及び高解像度で提供することができる。ＡＶサーバ１１４、１１５は、ＡＶコンテンツの配信中におけるユーザの立場から見たＱｏＥを向上させるために、及び／又は第１のネットワーク１１０におけるロードバランシングを改善するために併用することができる。

図１Ａ及び図１Ｂには、システムの動作中に行われるデータ交換を表す矢印を実線及び点線で示しているが、これについては以下で図３、図４及び図６に関連して詳細に説明する。

図２に、ネットワーク相互接続デバイス１０１、及び／又はポータルサーバ１１１、及び／又はＣＤＮサーバ１１２、及び／又はマルチキャストサーバ１１３、及び／又はＡＶサーバ１１４、１１５のアーキテクチャを概略的に示す。図２を、ネットワーク相互接続デバイス１０１に関して説明しているものとして検討する。

図示のアーキテクチャによれば、ネットワーク相互接続デバイス１０１は、プロセッサ、マイクロプロセッサ、マイクロコントローラ又はＣＰＵ（中央処理装置）２００と、ＲＡＭ（ランダムアクセスメモリ）２０１と、ＲＯＭ（リードオンリメモリ）２０２と、ＨＤＤ（ハードディスクドライブ）２０３、又は記憶手段に記憶された情報を読み取るようになっている他のいずれかのデバイスと、第１の通信インターフェイス２０４と、第２の通信インターフェイス２０５とを含み、これらは通信バス２１０によって相互接続される。

第１の通信インターフェイス２０４は、ネットワーク相互接続デバイス１０１を第１のネットワーク１１０に接続できるようにする。第２の通信インターフェイス２０５は、ネットワーク相互接続デバイス１０１を第２のネットワーク１２０に接続できるようにする。なお、ポータルサーバ１１１、ＣＤＮサーバ１１２又はマルチキャストサーバ１１３については、関連するサーバを第１のネットワーク１１０に接続するための通信インターフェイスを１つだけ実装していればよい。

ＣＰＵ２００は、ＲＯＭ２０２、又はＨＤＤ２０３などの外部メモリからＲＡＭ２０１にロードされた命令を実行することができる。ＣＰＵ２００は、ネットワーク相互接続デバイス１０１の電源投入後にＲＡＭ２０１から命令を読み取って実行することができる。これらの命令は、以下で図３及び図４に関連して説明する、ネットワーク相互接続デバイス１０１によって実行されるステップをＣＰＵ２００に実行させる１つのコンピュータプログラムを形成する。なお、これらのステップは、ＰＣ、ＤＳＰ（デジタルシグナルプロセッサ）又はマイクロコントローラなどのプログラム可能なコンピュータ機械による命令又はプログラムセットの実行によってソフトウェアの形で実装することも、或いは、機械、又はＦＰＧＡ（フィールドプログラマブルゲートアレイ）又はＡＳＩＣ（特定用途向け集積回路）などの専用コンポーネントによってハードウェアの形で実装することもできる。

図３に、図１Ａ又は図１Ｂのシステムによって実施されるＡＶコンテンツ配信のためのアルゴリズムを概略的に示す。

ステップ３０１において、クライアントデバイス１２１が、ＣＤＮを介して利用可能になっているＡＶコンテンツの記述をポータルサーバ１１１がクライアントデバイス１２１に提供するように要求する。この要求は、上記ＡＶコンテンツの記述を参照するＵＲＬ（「ユニフォームリソースロケータ」）へのユニキャストＨＴＴＰ要求の形で行われることが好ましい。この要求は、クライアントデバイス１２１により、ネットワーク相互接続デバイス１０１を介してポータルサーバ１１１に送信される。

次のステップ３０２において、ポータルサーバ１１１は、ステップ３０１で送信された要求に応答して、ＣＤＮを介して利用可能になっているＡＶコンテンツの記述を送信する。この応答は、ポータルサーバ１１１により、ネットワーク相互接続デバイス１０１を介してクライアントデバイス１２１に送信される。この記述は、上記ＡＶコンテンツのリストと、それぞれのＡＶコンテンツをＣＤＮサーバ１１２から取得できるそれぞれのＵＲＬとを含む。この記述は、それぞれのＡＶコンテンツから抽出された画像のサムネイル、又は上記それぞれのＡＶコンテンツを表す画像のサムネイルをさらに含むことができ、これによってクライアントデバイス１２１は、これらのサムネイルから構築されたタイルをグラフィックユーザインターフェイスに表示できるようになる。

ステップ３０１及び３０２の実行に関連するメッセージ交換については、図１Ａに矢印１３１で、図１Ｂに矢印１４１で示している。

次のステップ３０３において、クライアントデバイス１２１は、利用可能なＡＶコンテンツのリストのうちの１つのＡＶコンテンツの選択をユーザからユーザインターフェイスを介して取得する。

なお、より一般的な実施形態では、ステップ３０１及び３０２を実行することなくＡＶコンテンツの選択を自動的に実行することができる。例えば、クライアントデバイス１２１は、ＣＤＮサーバ１１２によって提供されたＡＶコンテンツを示すＵＲＬを電子メールなどのメッセージで受け取る。

次のステップ３０４において、クライアントデバイス１２１は、選択されたＡＶコンテンツをＣＤＮサーバ１１２に要求する。この要求は、ｍ３ｕ８の拡張子が付いたプレイリストファイルを参照するＨＴＴＰ ＧＥＴメッセージの形であることが好ましい。

次のステップ３０５において、ＣＤＮサーバ１１２は、そのＡＶコンテンツが、クライアントデバイス１２１が対応していないと予想される新たなインフラ又はサービスに関連するものであるかどうかをチェックする。

選択されたＡＶコンテンツが新たなインフラ又はサービスに関連する場合には、ステップ３０７を実行する。その他の場合には、ステップ３０６を実行する。

ステップ３０６において、ＣＤＮサーバ１１２は、ネットワーク相互接続デバイス１０１を介して、選択されたＡＶコンテンツをクライアントデバイス１２１に提供する。ＡＶコンテンツは、ＨＬＳ技術を用いて、すなわちこのＡＶコンテンツを表すトランスポートストリームのチャンクを各々が含む一連の小さなＨＴＴＰベースのファイルダウンロードの形でＣＤＮサーバ１１２によって配信されることが好ましい。このダウンロードは、ユニキャストＨＴＴＰ要求応答に基づいて行われる。その後、アルゴリズムは終了する。

ステップ３０７において、ＣＤＮサーバ１１２は、ＩＰ（規範文書ＲＦＣ７９１によって規定される「インターネットプロトコル」）アドレスとポートのＴＣＰ連結によって識別される別の場所にクライアントデバイス１２１をリダイレクトする旨を示すリダイレクトメッセージをクライアントデバイス１２１に送信する。このＩＰアドレスとポートのＴＣＰ連結は、相互接続デバイス１０１のエージェント１０２によって管理される。

このリダイレクトメッセージは、オーディオビジュアルコンテンツの一時的再配置を示すことが好ましい。要求されたリソースが一時的に別の場所に存在する旨を示すことにより、クライアントデバイス１２１は、後でこのＡＶコンテンツを取得しようと試みた時に、再び確実にＣＤＮサーバ１１２にコンタクトできるようになる。従って、ＣＤＮサーバ１１２は、クライアントデバイス１２１が対応していないと予想される新たなインフラ又はサービスが依然としてそのＡＶコンテンツに関連しているかどうかをチェックすることができる。

ステップ３０４、３０６及び３０７の実行に関連するメッセージ交換については、図１Ａに矢印１３２で、図１Ｂに矢印１４２で示している。

次のステップ３０８において、クライアントデバイス１２１は、リダイレクトメッセージを受け取ると、このリダイレクトメッセージに示されているＩＰアドレスとポートのＴＣＰ連結に向けた接続要求を生成する。この要求は、リダイレクトメッセージ内に提供されるパラメータを含む。

このステップ３０８の実行に関連するメッセージの送信については、図１Ａに矢印１３３で、図１Ｂに矢印１４３で示している。

次のステップ３０９において、エージェント１０２は、ＣＤＮ装置とクライアントデバイス１２１の間の中継器として機能する。従って、クライアントデバイス１２１は、あたかもＣＤＮサーバ１１２とやりとりしているかのようにエージェント１０２とやりとりし、エージェント１０２は、新たなインフラ又はサービスの実装を可能にする。

第１の実施形態によれば、この新たなインフラ又は新たなサービスは、ＣＤＮネットワーク全体を通じたライブストリーミングの形でＡＶコンテンツのマルチキャスト送信を実装することに関連する。この実施形態については、以下で図４に関連して詳細に説明する。第２の実施形態によれば、新たなインフラ又は新たなサービスは、エージェント１０２がＡＶコンテンツを取り出せる複数のソースを実装することに関連する。この実施形態については、以下で図６に関連して詳細に説明する。

図４に、マルチキャストサーバ１１３が作動している図１Ａのシステムによって実施されるＡＶコンテンツ配信のためのアルゴリズムを概略的に示す。このアルゴリズムでは、クライアントデバイスが、第１のネットワーク１００における帯域幅消費の削減を目的とする新たなＣＤＮインフラ又はサービスから恩恵を受けることができる。

このアルゴリズムは、図３に関連して上述したステップ３０１〜３０４とそれぞれ同じものであるステップ４０１〜４０４から開始するが、ＣＤＮを介して利用可能になっているＡＶコンテンツの記述が、ライブストリーミングとして利用可能なＡＶコンテンツのみをリストしている点が異なる。

次のステップ４０５において、ＣＤＮサーバ１１２は、ＡＶコンテンツがマルチキャストサーバ１１３からのマルチキャストの形で利用可能であるかどうかをチェックする。第１の例によれば、ＣＤＮサーバ１１２は、マルチキャストサーバ１１３からのマルチキャストの形でライブストリーミングとして利用可能なＡＶコンテンツの所定のリストを記憶する。第２の例によれば、マルチキャストストリーミングの形で利用可能な全てのＡＶコンテンツがそれぞれの一意の識別子に関連付けられており、ＣＤＮサーバ１１２は、選択されたＡＶコンテンツの一意の識別子をマルチキャストサーバ１１３に提供し、マルチキャストサーバ１１３は、識別されたＡＶコンテンツのためのマルチキャスト送信が既にセットアップされているかどうか、又はマルチキャストサーバ１１３がこのようなマルチキャスト送信のセットアップ能力を有しているかどうかを示す応答を送信する。

選択されたＡＶコンテンツがマルチキャストの形で利用可能になっている場合には、ステップ４０７を実行する。その他の場合には、ステップ４０６を実行する。

ステップ４０６において、ＣＤＮサーバ１１２は、ネットワーク相互接続デバイス１０１を介して、選択されたＡＶコンテンツをクライアントデバイス１２１にユニキャストの形で提供する。

ステップ４０７において、ＣＤＮサーバ１１２は、ステップ３０７に関連して上述したように、クライアントデバイス１２１を別の場所にリダイレクトする旨を示すリダイレクトメッセージをクライアントデバイス１２１に送信する。

リダイレクトメッセージは、以下の形をとることができる。
３０７ ＴＥＭＰＯＲＡＲＹ ＲＥＤＩＲＥＣＴ
ｌｏｃａｔｉｏｎ：１９２．１６８．０．１：５０００？２２５．１０．１１．１２：１０００＆ＮｂＬａｙｅｒｓ＝３
この場合、
− ３０７ ＴＥＭＰＯＲＡＲＹ ＲＥＤＩＲＥＣＴは、要求されたリソースが一時的に別の場所に存在し、リダイレクションは時折変更されることがあるので、クライアントデバイス１２１は将来的な要求に前回のＵＲＬを使用し続けるべきである旨を示すＨＴＴＰコードに対応し、
− ｌｏｃａｔｉｏｎ：１９２．１６８．０．１：５０００は一時的なリソースの場所を示し、１９２．１６８．０．１はエージェント１０２のＩＰアドレスであり、５０００はクライアントデバイス１２１が接続を行うべきＴＣＰポートであり、
− ？はパラメータが後続することを示し、
− ２２５．１０．１１．１２：１０００＆ＮｂＬａｙｅｒｓ＝３は、エージェント１０２によって必要とされる上記パラメータであり、２２５．１０．１１．１２は、要求されたＡＶコンテンツを表すマルチキャストストリームのためのＩＰマルチキャストアドレスであり、１０００は、エージェント１０２がリスンすべきＵＤＰポートであり、「ＮｂＬａｙｅｒｓ＝３」は、要求されたＡＶコンテンツに利用できるレイヤの数量を示す。

なお、パラメータＮｂＬａｙｅｒｓの値を示すことは、ＡＢＳの場合にのみ、さらにはレイヤの数量がエージェント１０２によって事前に知られていない場合にのみ有用である。

次のステップ４０８において、クライアントデバイス１２１は、リダイレクトメッセージを受け取ると、このリダイレクトメッセージに示されているＩＰアドレスとポートのＴＣＰ連結に向けた接続要求を生成する。この要求は、リダイレクトメッセージ内に提供されるパラメータを含む。

次のステップ４０９において、エージェント１０２は、クライアントデバイス１２１から受け取った要求内にポート及びアドレスが指定されているマルチキャストストリームに参加する。次に、エージェント１０２は、マルチキャストサーバ１１３からマルチキャストストリームを受け取る。マルチキャストストリームへの参加は、専用のＩＧＭＰ（規範文書ＲＦＣ３３７６によって規定される「インターネットグループ管理プロトコル」）メッセージを用いて行われることが好ましい。

選択されたＡＶコンテンツをマルチキャストの形でデータ送信することについては、図１Ａに矢印１３４で示している。

次のステップ４１０において、エージェント１０２は、マルチキャストからユニキャストへの変換を行う。エージェント１０２は、受け取ったマルチキャストパケットから、クライアントデバイス１２１によって送信された要求に対するそれぞれのユニキャスト応答を生成する。実際には、クライアントデバイス１２１は、選択されたＡＶコンテンツを取得するために、選択されたＡＶコンテンツを断片毎に取得する要求をエージェント１０２に対して生成する。エージェント１０２は、マルチキャストサーバ１１３から受け取ったマルチキャストストリームのＡＶデータを用いて上記要求に対する応答を生成する。

選択されたＡＶコンテンツをユニキャストの形でデータ送信することについては、図１Ａに矢印１３５で示している。

特定の実施形態によれば、マルチキャストサーバ１１３により、選択されたＡＶコンテンツの配信に複数のレイヤが利用可能になっており、リダイレクトメッセージは、マルチキャストアドレスと関連ポートの連結をレイヤ毎に含む。この結果、エージェント１０２は、選択されたＡＶコンテンツのためのマルチキャストストリームのいずれか又は全てに参加することができる。

別の特定の実施形態によれば、マルチキャストサーバ１１３により、選択されたＡＶコンテンツの配信に複数のレイヤが利用可能になっており、リダイレクトメッセージは、マルチキャストアドレス及び関連ポートを含まない。この場合、いずれかのマルチキャストストリームのためのマルチキャストアドレス及び関連ポートがエージェント１０２によって事前に認知されている。例えば、このようなマルチキャストアドレス及び関連ポートは事前に定められ、或いはＣＤＮサーバ１１２により、選択されたＡＶコンテンツの一意の識別子に関連する専用メッセージの形で相互接続デバイス１０１に送信されて、リダイレクトメッセージがこの一意の識別子を含むようになる。

さらに別の特定の実施形態によれば、マルチキャストサーバ１１３により、選択されたＡＶコンテンツの配信に複数のレイヤが利用可能になっており、エージェント１０２は、選択されたＡＶコンテンツのためのリダイレクトメッセージに示されているレイヤの数量に応じて、（単複の）マルチキャストストリームに参加するための少なくとも１つのマルチキャストアドレス及び／又は少なくとも１つの関連ポートを決定する。例えば、リダイレクトメッセージに１つのレイヤのためのマルチキャストアドレスが含まれている場合、エージェント１０２は、この含まれているマルチキャストアドレスを所定の方法で修正することにより、別のレイヤのための別のマルチキャストアドレスを決定することができる。一例として、リダイレクトメッセージが、１つのレイヤに対応する２２５．１０．１１．１２というマルチキャストアドレスを含む場合、エージェント１０２は、このアドレスを１単位だけ増分することにより、別のレイヤに対応する２２５．１０．１１．１３というマルチキャストアドレスが取得されると認識する。パラメータＮｂＬａｙｅｒｓの値は、どのアドレスまで増分を行うことができるかを示すことができる。関連ポートにも同じ原理が当てはまる。一例として、リダイレクトメッセージが１つのレイヤに対応するポート１０００を含む場合、エージェント１０２は、このポートを１単位だけ増分することにより、別のレイヤに対応するポート１００１が取得されると認識する。これらの例から、全てのレイヤのための１つのマルチキャストアドレスと、レイヤ毎に１つの関連ポートとを使用することも、又はレイヤ毎に１つのマルチキャストアドレスと、レイヤ毎に１つの関連ポートとを使用することも、又はレイヤ毎に１つのマルチキャストアドレスと、全てのレイヤのための１つの関連ポートとを使用することもできるということが分かる。

図５に、マルチキャストＨＬＳの状況においてエージェント１０２によって実行されるステップ４０８〜４１０を概略的に詳述する。

ステップ４０１において、エージェント１０２は、選択されたＡＶコンテンツに利用できる様々なストリームのプレイリストを取得するための要求をクライアントデバイス１２１から受け取る。この要求は、ステップ４０８において受け取られるものであり、従って潜在的にリダイレクトメッセージからのパラメータを含んでいる。

次のステップ５０２において、エージェント１０２は、ＣＤＮサーバ１１２に上記プレイリストを要求し、これを行うために使用されるＵＲＬはエージェント１０２によって事前に認知されており、又はリダイレクトメッセージ内にパラメータとして提供される。少なくともリダイレクトメッセージは、上記ユニフォームリソースロケータを表すパラメータを含む。次のステップ５０３において、エージェント１０２は、「ｌｏｗ．ｍ３ｕ８」、「ｍｅｄｉｕｍ．ｍ３ｕ８」及び「ｈｉｇｈ．ｍ３ｕ８」などのレイヤプレイリストを参照するプレイリストをＣＤＮサーバ１１２からレイヤ毎に１つ受け取る。

次のステップ５０４において、エージェント１０２は、ＣＤＮサーバ１１２によって提供されたプレイリストを解析して、各レイヤに適用可能なプレイリスト、従って関連するマルチキャストストリームの決定に適用可能なプレイリストを決定する。

次のステップ５０５において、エージェント１０２は、ＣＤＮサーバ１１２から受け取ったプレイリストをクライアントデバイス１２１に送信する。

次のステップ５０６において、クライアントデバイス１２１が、例えば「ｌｏｗ．ｍ３ｕ８」などのレイヤプレイリストを要求すると、エージェント１０２は、ステップ４０９の参加動作を行う。エージェント１０２は、ＣＤＮサーバ１１２から受け取ったプレイリスト内の、クライアントデバイス１２１によって要求されたレイヤプレイリストの位置を用いて、どの（単複の）マルチキャストストリームに参加すべきかを決定することができる。

次のステップ５０７において、エージェント１０２は、参加動作に応答して、例えば「ｌｏｗ．ｍ３ｕ８」などの関連するレイヤのレイヤプレイリストとＡＶデータとを含む（単複の）マルチキャストストリームをマルチキャストサーバ１１３から受け取り始める。

次のステップ５０８において、エージェント１０２は、この（単複の）マルチキャストストリームに含まれている（単複の）レイヤプレイリストを解析して、考慮するレイヤのＡＶストリームを構成する全てのファイルの識別子を決定する。

次のステップ５０９において、エージェント１０２は、（単複の）マルチキャストストリームに含まれている（単複の）レイヤプレイリストをクライアントデバイス１２１に送信する。この時、クライアントデバイス１２１は、上述したように、選択されたＡＶコンテンツを断片毎に取得するための要求をエージェント１０２に対して生成すると予想される。エージェント１０２は、これに応答して、ステップ４１０のマルチキャストからユニキャストへの変換を行う。

クライアントデバイス１２１は、別のレイヤに切り替える必要性を検出した場合、次のステップ５１０において、例えば「ｍｅｄｉｕｍ．ｍ３ｕ８」などの関連するプレイリストを取得するための要求を送信する。この結果、エージェント１０２は、クライアントデバイス１２１によって要求された上記別のプレイリストに応じてマルチキャストストリームを選択するようになる。クライアントデバイス１２１は、全てのレイヤプレイリストを認知すると、上記ファイルの識別子を用いて、いずれかのレイヤプレイリストからのファイルダウンロードを要求することができる。エージェント１０２は、これらのレイヤプレイリストに対して事前に行った解析動作の結果、上記ファイルの上記識別子に応じてマルチキャストストリームを選択することができる。

変換されたストリームデータがクライアントデバイス１２１に送信されると、アルゴリズムはステップ５０６を繰り返し、クライアントデバイス１２１は再びプレイリストを要求する。実際に、ＨＬＳでのライブストリーミングという状況では、プレイリストが時間とともに進化し、すなわち期限を過ぎたチャンクが除去されて新たなチャンクが追加される。エージェント１０２は、クライアントデバイス１２１に最新のプレイリストを提供し、レイヤ間の切り替えを行う必要がある時にのみ別のマルチキャストストリームを選択する。

スムーズストリーミングの状況では、クライアントデバイス１２１からの要求が、関連するレイヤ及び要求されたＡＶファイル断片の時間基準を示すので、実装はさらに単純である。

上記の図５に関連する説明から、クライアントデバイス１２１は、１つのレイヤから別のレイヤに切り替える必要性の検出を担っていると理解することができる。

別の特定の実施形態によれば、マルチキャストサーバ１１３により、選択されたＡＶコンテンツの配信に複数のレイヤが利用可能になっており、エージェント１０２が、１つのレイヤに対応する１つのマルチキャストストリームに参加しており、このエージェント１０２が、クライアントデバイス１２１が上記１つのレイヤから別のレイヤへの切り替えを行う必要性を検出する。この時、エージェント１０２は、上記別のレイヤに対応するマルチキャストストリームに参加して、上記１つのレイヤに対応するマルチキャストストリームから離脱する。マルチキャストストリームからの離脱は、専用のＩＧＭＰメッセージを用いて行われることが好ましい。従って、エージェント１０２は、１つのレイヤから別のレイヤへの切り替えを行うために複数のマルチキャストストリームに同時に、又はほんの短い期間にわたって参加する必要があるという状況にはない。

さらに別の特定の実施形態によれば、マルチキャストサーバ１１３により、選択されたＡＶコンテンツの配信に複数のレイヤが利用可能になっており、エージェント１０２が、１つのレイヤと別のレイヤとにそれぞれ対応する少なくとも２つのマルチキャストストリームに参加しており、このエージェント１０２が、クライアントデバイス１２１が上記１つのレイヤから別のレイヤへの切り替えを行う必要性を検出する。この時、エージェント１０２は、上記検出された必要性に応じて、上記少なくとも２つのマルチキャストストリームのうちの一方のマルチキャストストリームからのデータを選択する。すなわち、エージェント１０２は、両マルチキャストストリームからのデータを受け取り、クライアントデバイス１２１にユニキャストの形で提供するのに適したデータを内部的に選択する。

さらに別の特定の実施形態によれば、クライアントデバイス１２１が１つのレイヤから別のレイヤへの切り替えを行う必要性を検出することが、例えば第１のネットワーク１１０のトラフィック負荷をモニタすることに基づいて、エージェント１０２によって単独で行われる。別の方法は、マルチキャストサーバ１１３が、このような切り替えを行う必要性があることをエージェント１０２に知らせることである。

図６に、ＡＶサーバ１１４、１１５が作動している図１Ｂのシステムによって実施されるＡＶコンテンツ配信のためのアルゴリズムを概略的に示す。このアルゴリズムでは、クライアントデバイスが、ユーザの立場から見たＱｏＥを向上させること、及び／又は第１のネットワーク１００のロードバランシングを改善することを目的とする新たなＣＤＮインフラ又はサービスから恩恵を受けることができる。

このアルゴリズムは、図３に関連して上述したステップ３０１〜３０４とそれぞれ同じものであるステップ６０１〜６０４から開始する。ＣＤＮを介して利用可能になっているＡＶコンテンツの記述は、ライブストリーミング及び／又はＶＯＤ（ビデオ・オン・デマンド）として利用可能なＡＶコンテンツをリストする。

次のステップ６０５において、ＣＤＮサーバ１１２は、ＡＶコンテンツが複数のソースから利用可能であるかどうかをチェックする。第１の例によれば、ＣＤＮサーバ１１２は、ＡＶコンテンツを利用できるソースの所定のリストを記憶する。第２の例によれば、全てのＡＶコンテンツがそれぞれの一意の識別子に関連付けられており、ＣＤＮサーバ１１２は、選択されたＡＶコンテンツの一意の識別子をＡＶサーバ１１４、１１５に提供し、ＡＶサーバ１１４、１１５は、この識別されたＡＶコンテンツがＡＶサーバ１１４、１１５によって少なくとも部分的に記憶されているかどうかを示す応答を送信する。

選択されたＡＶコンテンツが複数のソースから利用可能になっている場合には、ステップ６０７を実行する。その他の場合には、ステップ６０６を実行する。

ステップ６０６において、ＣＤＮサーバ１１２は、ネットワーク相互接続デバイス１０１を介して、選択されたＡＶコンテンツをユニキャストの形でクライアントデバイス１２１に提供する。

ステップ６０７において、ＣＤＮサーバ１１２は、ステップ３０７に関連して上述したように、クライアントデバイス１２１を別の場所にリダイレクトする旨を示すリダイレクトメッセージをクライアントデバイス１２１に送信する。このリダイレクトメッセージは、選択されたＡＶコンテンツをエージェント１０２が要求できる各ソースを表すＵＲＬの指示をさらに含むことができる。このリダイレクトメッセージは、選択されたＡＶコンテンツのどのチャンクを各ソースが記憶しているかについての指示をさらに含むことができる。これらの指示は、エージェント１０２において事前に定めることもできる。

ステップ６０８において、クライアントデバイス１２１は、リダイレクトメッセージを受け取ると、このリダイレクトメッセージに示されているＩＰアドレスとポートのＴＣＰ連結に向けた接続要求を生成する。この要求は、リダイレクトメッセージ内に提供されるパラメータを含む。

次のステップ６０９において、エージェント１０２は、選択されたＡＶコンテンツを複数のソースに要求してこれを受け取る。複数のソースに同じチャンクを要求すると、チャンクを取得するための全体的なレイテンシが減少し、これによってＡＶデータの不足、従ってＡＶアーチファクトが回避されるので、ＱｏＥを向上させることができる。さらに、ＡＶデータの配信中における、ホストとも呼ばれる１つのソースとの接続ロスによるＱｏＥに対する影響を克服できるようになる。それぞれの異なるソースに異なるチャンクを要求すると、ＣＤＮネットワークのロードバランシングを改善することができる。

選択されたＡＶコンテンツの断片をエージェント１０２が受け取れるようにするためのやりとりについては、図１Ｂに矢印１４４、１４５で示している。

次のステップ６１０において、エージェント１０２は、選択されたＡＶコンテンツを再現し、これをクライアントデバイス１２１にユニキャストの形で送信する。

選択されたＡＶコンテンツをユニキャストの形でデータ送信することについては、図１Ｂに矢印１３５で示している。

特定の実施形態によれば、選択されたＡＶコンテンツに対して複数のレイヤを利用可能にすることができる。ＨＬＳの状況では、エージェント１０２が、関連するプレイリストをＣＤＮサーバ１１２に要求し、これを行うために使用されるＵＲＬはエージェント１０２によって事前に認知されており、又はリダイレクトメッセージ内にパラメータとして提供される。上記プレイリストの１つ又はそれ以上は、ＡＶサーバ１１４、１１５から取得することもできる。

別の特定の実施形態によれば、ＶＯＤの状況において、相互接続デバイス１０１がホームゲートウェイであり、エージェント１０２が、他のホームゲートウェイである複数のソースからＡＶコンテンツを取得する。上記他のホームゲートウェイは、ＡＶコンテンツの少なくとも一部にアクセスすることができ、このＡＶコンテンツの少なくとも一部は、上記他のホームゲートウェイ、又は上記他のホームゲートウェイによってインターネットに相互接続されたローカルエリアネットワーク上に存在する別の記憶装置によって記憶することができる。上記ＡＶコンテンツが、上記他のホームゲートウェイによってインターネットに相互接続されているローカルエリアネットワーク上に存在するクライアントデバイスのユーザのために事前にダウンロードされている場合、上記他のホームゲートウェイはこのＡＶコンテンツにアクセスすることができる。ＣＤＮサーバ１１２は、ＡＶコンテンツをどこで取得できるかについてエージェント１０２に知らせるために、ＡＶコンテンツをダウンロードする際に経由するホームゲートウェイを追跡することができる。このような特定の実施形態では、ＣＤＮのロードバランシングをさらに改善することができる。

１０１ ネットワーク相互接続デバイス
１０２ エージェント
１１０ 第１のネットワーク
１１１ ポータルサーバ
１１２ ＣＤＮサーバ
１１３ マルチキャストサーバ
１１４、１１５ ＡＶサーバ
１２０ 第２のネットワーク
１２１ クライアントデバイス
１３１ メッセージ交換
１３２ メッセージ交換
１３３ メッセージ送信
１３４ ＡＶコンテンツのデータ送信（マルチキャスト）
１３５ ＡＶコンテンツのデータ送信（ユニキャスト）

Claims (9)

1. クライアントデバイスにオーディオビジュアルコンテンツを配信する方法であって、相互接続デバイスが、前記オーディオビジュアルコンテンツを提供するように適合された装置が接続されている第１のネットワークを、前記クライアントデバイスが接続されている第２のネットワークに相互接続し、前記装置は、
   − 前記クライアントデバイスから、前記オーディオビジュアルコンテンツを受け取るための第１の要求を受け取ることと、
   − 前記オーディオビジュアルコンテンツの一時的な再配置を指示するリダイレクトメッセージであって、前記相互接続デバイス内に実装されているエージェントに向けて前記クライアントデバイスをリダイレクトするリダイレクトメッセージを前記クライアントデバイスに送信することと、
   を実行し、前記エージェントは、
   − 前記クライアントデバイスから、前記オーディオビジュアルコンテンツを受け取るための第２の要求を受け取ることと、
   − 前記第２の要求に応答して、前記装置と前記クライアントデバイスとの間の中継器として動作することと、
   を実行し、
   前記リダイレクトメッセージが前記オーディオビジュアルコンテンツの一時的な再配置を指示することにより、前記クライアントデバイスが後で前記オーディオビジュアルコンテンツを取得しようと試みたとき、前記クライアントデバイスが再び前記装置にコンタクトし、
   前記第１及び第２の要求は、前記オーディオビジュアルコンテンツをユニキャストストリームの形で受け取るための要求であり、前記装置は、前記オーディオビジュアルコンテンツをライブストリーミングで提供するように適合され、前記装置は、前記オーディオビジュアルコンテンツが前記装置によって少なくとも１つのマルチキャストストリームの形で利用可能になっている時に前記リダイレクトメッセージを前記クライアントデバイスに送信し、前記エージェントは、中継器として動作する際に、
   − 前記少なくとも１つのマルチキャストストリームに参加することと、
   − 前記少なくとも１つのマルチキャストストリームの形で受け取ったデータを、前記ユニキャストストリームの形のデータに変換することと、
   を実行する、
   ことを特徴とする方法。
2. − 前記リダイレクトメッセージは、少なくとも１つのマルチキャストアドレスと、少なくとも１つの関連ポートとを通知するパラメータを含み、
   − 前記オーディオビジュアルコンテンツを前記ユニキャストストリームの形で受け取るための前記要求は、前記少なくとも１つのマルチキャストアドレスと、前記少なくとも１つの関連ポートとを通知する前記パラメータを含み、
   − 前記エージェントは、前記少なくとも１つのマルチキャストアドレス及び前記少なくとも１つの関連ポートに対応する少なくとも１つのマルチキャストストリームに参加する、
   ことを特徴とする請求項１に記載の方法。
3. − 前記リダイレクトメッセージは、前記少なくとも１つのマルチキャストストリームの形の前記オーディオビジュアルコンテンツに利用可能になっているレイヤの数量を通知するパラメータを含み、
   − 前記オーディオビジュアルコンテンツを前記ユニキャストストリームの形で受け取るための前記要求は、前記レイヤの数量を通知する前記パラメータを含み、
   − 前記エージェントは、前記レイヤの数量に応じて、少なくとも１つのマルチキャストアドレス及び／又は少なくとも１つの関連ポートを決定する、
   ことを特徴とする請求項１又は２に記載の方法。
4. − 前記リダイレクトメッセージは、１つのマルチキャストアドレス及び１つの関連ポートを通知するとともに前記レイヤの数量を通知するパラメータを含み、
   − 前記オーディオビジュアルコンテンツを前記ユニキャストストリームの形で受け取るための前記要求は、前記１つのマルチキャストアドレス及び前記１つの関連ポートを通知するとともに前記レイヤの数量を通知する前記パラメータを含み、
   − 前記エージェントは、前記要求に含まれる前記レイヤの数量、並びに前記１つのマルチキャストアドレス及び前記１つの関連ポートに応じて、レイヤ毎に１つのマルチキャストアドレスと、１つの関連ポートとを決定する、
   ことを特徴とする請求項３に記載の方法。
5. − 前記リダイレクトメッセージは、１つのマルチキャストアドレス及び１つの関連ポートを通知するとともに前記レイヤの数量を通知するパラメータを含み、
   − 前記オーディオビジュアルコンテンツを前記ユニキャストストリームの形で受け取るための前記要求は、前記１つのマルチキャストアドレス及び前記１つの関連ポートを通知するとともに前記レイヤの数量を通知する前記パラメータを含み、
   − 前記エージェントは、前記要求に含まれる前記レイヤの数量、並びに前記１つのマルチキャストアドレス及び前記１つの関連ポートに応じて、全てのレイヤのための１つのマルチキャストアドレスと、レイヤ毎に１つの関連ポートとを決定する、
   ことを特徴とする請求項３に記載の方法。
6. 前記少なくとも１つのマルチキャストストリームの形の前記オーディオビジュアルコンテンツに複数のレイヤが利用可能になっており、前記装置は、ハイパーテキスト転送プロトコルライブストリーミングを用いて前記オーディオビジュアルコンテンツを提供するように適合され、
   − 前記リダイレクトメッセージは、前記オーディオビジュアルコンテンツのためのプレイリストに関連するユニフォームリソースロケータを表すパラメータを含み、
   − 前記オーディオビジュアルコンテンツを前記ユニキャストストリームの形で受け取るための前記要求は、前記ユニフォームリソースロケータを表す前記パラメータを含み、 前記エージェントは、
   − 前記ユニフォームリソースロケータに基づいて前記プレイリストを要求することと、
   − 前記プレイリストを受け取ることと、
   − 前記プレイリストに解析動作を行って、各レイヤに関連する１つのプレイリストを決定することと、
   − 各参加したマルチキャストストリームから１つのレイヤプレイリストを受け取ることと、
   − 前記受け取った（単複の）プレイリストを前記クライアントデバイスに送信することと、
   − 前記クライアントデバイスから、１つのレイヤに関連するプレイリストを指示する要求、又は１つのレイヤに関連するプレイリストのファイルを指示する要求を受け取ることと、
   − 前記１つのレイヤに関連する前記指示されたプレイリスト又は前記指示されたファイルに応じてマルチキャストストリームを選択することと、
   を実行する、
   ことを特徴とする請求項１から５のいずれかに記載の方法。
7. 前記少なくとも１つのマルチキャストストリームの形の前記オーディオビジュアルコンテンツに複数のレイヤが利用可能になっており、前記エージェントは、１つのレイヤに対応する１つのマルチキャストストリームに参加しており、前記エージェントは、
   − 前記クライアントデバイスが前記１つのレイヤから別のレイヤへの切り替えを行う必要性を検出することと、
   − 前記別のレイヤに対応するマルチキャストストリームに参加することと、
   − 前記１つのレイヤに対応する前記マルチキャストストリームから離脱することと、を実行する、
   ことを特徴とする請求項１から５のいずれかに記載の方法。
8. 前記少なくとも１つのマルチキャストストリームの形の前記オーディオビジュアルコンテンツに複数のレイヤが利用可能になっており、前記エージェントは、１つのレイヤ及び別のレイヤにそれぞれ対応する少なくとも２つのマルチキャストストリームに参加しており、前記エージェントは、
   − 前記クライアントデバイスがレイヤ間で切り替えを行う必要性を検出することと、 − 前記検出された必要性に応じて、前記少なくとも２つのマルチキャストストリームのうちの一方のマルチキャストストリームからのデータを選択することと、
   を実行する、
   ことを特徴とする請求項１から５のいずれかに記載の方法。
9. クライアントデバイスにオーディオビジュアルコンテンツを配信するためのシステムであって、前記オーディオビジュアルコンテンツを提供するように適合された装置と、該装置が接続されることを目的とする第１のネットワークを、前記クライアントデバイスが接続されている第２のネットワークに相互接続することを目的とする相互接続デバイスとを備え、前記装置は、
   − 前記オーディオビジュアルコンテンツを受け取るための第１の要求を受け取る手段と、
   − 前記オーディオビジュアルコンテンツの一時的な再配置を指示するリダイレクトメッセージであって、前記相互接続デバイス内に実装されているエージェントに向けて前記クライアントデバイスをリダイレクトすることを目的とするリダイレクトメッセージを送信する手段と、
   を有し、前記エージェントは、
   − 前記オーディオビジュアルコンテンツを受け取るための第２の要求を受け取る手段と、
   − 前記第２の要求に応答して、前記装置と前記クライアントデバイスとの間の中継器として動作する手段と、
   を有し、
   前記リダイレクトメッセージが前記オーディオビジュアルコンテンツの一時的な再配置を指示することにより、前記クライアントデバイスが後で前記オーディオビジュアルコンテンツを取得しようと試みたとき、前記クライアントデバイスが再び前記装置にコンタクトし、
   前記第１及び第２の要求は、前記オーディオビジュアルコンテンツをユニキャストストリームの形で受け取るための要求であり、前記装置は、前記オーディオビジュアルコンテンツをライブストリーミングで提供するように適合され、前記装置は、前記オーディオビジュアルコンテンツが前記装置によって少なくとも１つのマルチキャストストリームの形で利用可能になっている時に前記リダイレクトメッセージを前記クライアントデバイスに送信し、前記エージェントは、中継器として動作する際に、
   − 前記少なくとも１つのマルチキャストストリームに参加することと、
   − 前記少なくとも１つのマルチキャストストリームの形で受け取ったデータを、前記ユニキャストストリームの形のデータに変換することと、
   を実行する、
   ことを特徴とするシステム。

Images