JP2014036442A - 複数のクライアントにマルチメディアデータを送信するための方法、システム及びネットワーク - Google Patents

Abstract

【課題】マルチメディアデータの体感品質向上を提供する。
【解決手段】マルチメディアデータはマルチメディアレートの異なる複数のフォーマットで記憶されており、マルチメディア品質とマルチメディアレートとの関係を表す、マルチメディアデータについてのユーティリティ情報と、ネットワーク１０２の状態とに基づいて、複数のクライアント１０４ａ、１０４ｂの各々について、マルチメディアデータについて利用可能なマルチメディアレートが決定される。所望のマルチメディアレートのマルチメディアデータを送信するためのクライアント要求１１４に応じて、要求元のクライアント１０４ａ、１０４ｂのために決定された利用可能なマルチメディアレートに従い、要求されたマルチメディアデータのフォーマットが選択され、選択されたフォーマットで要求元のクライアント１０４ａ、１０４ｂにマルチメディアデータが送られる。
【選択図】図５

Description

本発明は、ネットワークを通じて複数のクライアントにマルチメディアデータを提供する分野に関し、より具体的には、複数のクライアントにマルチメディアデータを送信するための方法、システム及びネットワークに関する。本発明の実施の形態は、無線又は有線のネットワークを通じて、ビデオデータを提供するサーバから複数のクライアントに該ビデオデータを提供するための手法に関する。

有線又は無線のネットワークにおいて、マルチメディアコンテンツを有するサーバから複数のクライアントデバイスへと豊富なマルチメディアコンテンツを確実かつ効率的に配信することに対する要求が益々高まっている。例えば、無線ネットワークにおける移動体の機能が向上し、無線ネットワークの能力が改善されたことで、移動体によるビデオの消費が大幅に増加した。最近になって、モバイルマルチメディアストリーミングに関し、動的適応型ＨＴＴＰストリーミング（Dynamic Adaptive Streaming over HTTP）（DASH。MPEG-DASH又は3GP-DASHとも呼ぶ（非特許文献１））が標準化された。この手法は、広く普及しているＨＴＴＰ（Hypertext Transfer Protocol）オーバＴＣＰ（Transmission Control Protocol）（プログレッシブダウンロード）のネットワーキングインフラストラクチャを再利用し、標準的なＨＴＴＰプロトコルと互換性のある、メディア表現、トランスポート及び動的ビットレート適応化を含む完全なストリーミングフレームワークを提供するものである。

最適なメディア配信にあたっては、ネットワークを通じてサーバからクライアントデバイスへとコンテンツを伝送することが依然として主なボトルネックである。例えば、最適なモバイルメディア配信にあたっては、非特許文献２に記載されているように無線リンクが依然としてボトルネックである。無線ネットワークの場合、携帯電話事業者は、ユーザの体感品質（quality of experience, ＱｏＥ）を最大化しつつ、少ないネットワークリソースを複数のクライアント間で割り当てなければならないという問題に直面する。有線のネットワークでは、最適なメディア配信にあたり、ネットワークトラフィックが問題となりうる。

図１は、移動体ネットワークのコアネットワークといったコアネットワーク１０２を通じて、ビデオサーバ１００がビデオクライアント１０４ａ及び１０４ｂにビデオデータを提供するための環境を示している。図１に示しているように、各ビデオクライアントは、それぞれの無線チャネル１０８ａ及び１０８ｂを通じて基地局（ｅＮＢ）１０６に接続する。この基地局１０６はビデオサーバ１００と同様、コアネットワーク１０２に接続されている。コアネットワーク１０２には、トラフィック管理ユニット１１０とトラフィックエンジニアリングユニット１１２とが設けられている。トラフィック管理ユニット１１０は例えばＱｏＥオプティマイザを有している。トラフィック管理ユニット１１０は基地局１０６から、基地局１０６とビデオクライアント１０４ａ及び１０４ｂの各々との間にある２つの無線チャネル１０８ａ及び１０８ｂの長期平均品質（long-term average quality）に関する情報を受信する。さらに、トラフィック管理ユニット１１０はビデオサーバから、マルチメディアコンテンツに関するユーティリティ情報を受信する。この情報には、サーバ１００に記憶されているビデオフォーマットの種々の表現に関するレート歪み（rate-distortion）の情報が含まれうる。

コアネットワーク１０２を通じてビデオサーバ１００（図１）がクライアントにビデオコンテンツを提供するための１つの既知の手法は、いわゆる、ＲＴＰ／ＵＤＰストリーミング手法（ＲＴＰ：Real-Time Transport Protocol，ＵＤＰ：User Datagram Protocol）である。図２は、サーバ１００とクライアント１０４ａとの間のこのストリーミング手法を示している。クライアントはビデオサーバ１００に対し、ある特定のビデオストリームを得るための要求１１４を出す。ビデオサーバは、符号１１６に示しているように、ＵＤＰにより、あるビデオビットレートを有するパケットストリームを提供する。ビデオサーバ１００からのデータは、コアネットワーク１０２により、トラフィックエンジニアリングユニット１１２を通じて送信される。トラフィックエンジニアリングユニットは、例えば適切なトランスコーディングアルゴリズムを適用することにより、又はコンテンツを意識した（content-aware）パケット破棄により、ビデオサーバからクライアントへデータを転送する際のレートシェーピングメカニズムを提供するものである。非特許文献３に記載されているように、従来のＲＴＰ又はＲＴＳＰストリーミングの場合には、ＱｏＥに基づいて、無線ネットワークを通じてリソースを割り当てることが提案されている。しかし、この手法は、例えばトランスコーディング又はコンテンツを意識したパケット破棄によって、ネットワーク内でのコンテンツ適応化が必要であることに起因して、コストがかかり、オーバーヘッドも伴う。

それゆえ、当該技術分野における別の既知の手法は、例えば、ＤＡＳＨプロトコルを用いた、いわゆる、「適応的ＨＴＴＰストリーミング（adaptive HTTP streaming）」であり、これは、同じコンテンツを複数のビットレートで符号化することによる特有の適応性を提供するものである。図３は、ＤＡＳＨビデオフォーマットに従ってビデオコンテンツを提供するための一例を示している。図３は例えば、図１のサーバ１００に記憶されるようなＤＡＳＨビデオフォーマットの一例である。このフォーマットによれば、多くの小さなファイルがサーバに記憶され、各々がある特定の品質におけるある特定の時間のビデオを含む。より具体的には、図３では、ビデオコンテンツは、３つの異なる品質すなわち品質１、品質２、品質３で記憶される。品質ごとに、３つのセグメントが示されており、各セグメントの長さは例えば２秒である。最も高い品質のセグメントのビデオレートは１．５Ｍｂｐｓであり、ファイルサイズは３Ｍｂである。最も低い品質の場合、ビデオレートは０．５Ｍｂｐｓであり、ファイルサイズは１Ｍｂである。中間の品質（品質２）では、２Ｍｂのファイルサイズで１Ｍｂｐｓのビデオレートを有する。

図４は、ＤＡＳＨプロトコルを利用したストリーミング技術の一例を示している。サーバ１００及びクライアント１０４ａを再び示しており、サーバは、図３に示したフォーマットに従って、マルチメディアコンテンツ又はビデオコンテンツを保持する。マルチメディアストリーミングプロセスの開始時に、ＤＡＳＨクライアント１０４ａはサーバ１００に対し、メディアプレゼンテーション記述（media presentation description, ＭＰＤ）のＵＲＬを含むＨＴＴＰ要求を送信する（Ａ１）ことにより、サーバにある所望のマルチメディアストリームのＭＰＤを要求する。サーバ１００は、ＭＰＤを含むＨＴＴＰ応答を返す（Ａ２）。ＭＰＤは、異なるセグメントのＵＲＬ及びマルチメディアフォーマットを含んだ、サーバ１００において利用可能なマルチメディアフォーマットの記述を有している。所望のマルチメディアフォーマットであるセグメントをダウンロードするために、ＤＡＳＨクライアント１０４ａは、サーバ１００にＨＴＴＰ要求を出す（Ｂ１ａ〜ＢＮａ）。ＨＴＴＰ要求は、所望の品質でサーバ１００に記憶されているマルチメディアセグメントのＵＲＬを含むものである。サーバ１００は、要求されたビデオセグメントファイルをクライアントに転送する（Ｂ１ｂ〜ＢＮｂ）。要求はＨＴＴＰ要求として送信され、セグメントはＨＴＴＰ応答として送られる。符号１１６に示しているように、ＨＴＴＰはＴＣＰ上で動作する。任意ではあるが、ＲＴＰ／ＵＤＰストリーミング手法の場合と同様、ＤＡＳＨセッションにおいても、サーバからクライアントにデータを転送する際のレートシェーピングメカニズムを提供するために、トラフィックエンジニアリング１１２を行うことができる。

図３及び図４を参照して説明した上記の手法は、非特許文献４において概説されているように、２つ以上のクライアントが共有リンク上のリソースに関して競合する際に、一貫性がなく不公平な挙動を示すため不都合である。実際に、非特許文献５においては、良好なストリーミング性能を確保するために、ＴＣＰの帯域幅をマルチメディアレートの２倍にすべきであるとの結論に達している。例えば、限られた無線スペクトルでは、このようなオーバープロビジョニングが可能ではない場合があるため、個々のユーザの状態及びマルチメディア特性に適応したリソース管理方法も考える必要がある。

ＤＡＳＨプロトコルは、適応的ＨＴＴＰストリーミングのためのプレゼンテーション及びセグメントのフォーマットを定義するが（図３）、その制御はその標準規格の一部ではない。例えば、非特許文献６及び７に記載されているように、適応的ＨＴＴＰビデオ配信におけるユーザの知覚を高めるために、種々のレート適応化の手法が提案されている。しかし、これらの手法は、ネットワークリソースを共有する他のＤＡＳＨユーザへの影響を更に考慮することはなく、単一のユーザの適応的ＨＴＴＰストリーミングを最適化する傾向がある。実際、マルチアクセスＤＡＳＨストリーミングの問題は、これまでほとんど検討されていない。適応的ＨＴＴＰメディア配信は、エンドツーエンドのサーバ及びクライアントの視点から主に研究されてきたが、ネットワーク、例えば移動体ネットワークは、ブラックボックスとして取り扱われている（非特許文献２及び８を参照）。マルチユーザＨＴＴＰストリーミングに関する幾つかの刊行物の中でも、非特許文献９は、ラストホップ（last-hop）無線リンクにおいてＨＴＴＰ／ＴＣＰによるビデオ送信を適応化するためのフェアスケジューラ（fair scheduler）（ＲＲ）を検討している。非特許文献１０では、複数のクライアントにわたる適応的ＨＴＴＰビデオ配信のためのネットワーク管理が検討されている。しかし、目標ビットレートは、全てのユーザの利用可能な帯域幅の推定値に基づいて、ネットワークによって決定される（例えば、図４を参照）。非特許文献１１は、住居用ゲートウェイにおける簡易な帯域幅シェーピングのポリシによって、競合するクライアント間の適応的ＨＴＴＰの体感（experience）を改善できることを示している。

T. Stockhammer. Dynamic adaptive streaming over http - standards and design principles. Proc. MMSys 2011, San Jose, California, USA, Feb. 2011. K. Ma, R. Bartos, S. Bhatia, and R. Nair. Mobile video delivery with http. IEEE Communications Magazine, 49(4), 166:175, April 2011. S. Thakolsri, S. Khan, E. Steinbach, and W. Kellerer. QoE-driven cross-layer optimization for high speed downlink packet access. Journal of Communications, 4(9), 669:680, Oct. 2009. S. Akhshabi, A. C. Begen, and C. Dovrolis. An experimental evaluation of rate-adaptation algorithms in adaptive streaming over http. Proc. MMSys 2011, San Jose, California, USA, Feb. 2011. B. Wang, J. Kurose, P. Shenoy, and D. Towsley. Multimedia streaming via TCP: An analytic performance study. ACM Trans. Multimedia Comput. Commun. Appl., May 2008. L. D. Cicco, S. Mascolo, and V. Palmisano. Feedback control for adaptive live video streaming. Proc. MMsys 2011, San Jose, California, USA, Feb. 2011. D. Havey, R. Chertov, and K. Almeroth. Receiver driven rate adaptation for wireless multimedia applications. Proc. MMSys 2012, Chapel Hill, North Carolina, USA, Feb. 2012. A. Begen, T. Akgul, and M. Baugher. Watching video over the web: Part 2: Applications, standardization, and open issues. IEEE Internet Computing, 15(3), 59:63, May-June 2011. W. Pu, Z. Zou, and C. W. Chen. New TCP video streaming proxy design for last-hop wireless networks. Proc. IEEE ICIP 2011, Brussels, Belgium, Sept. 2011. K. Ma and R. Bartos. Http live streaming bandwidth management using intelligent segment selection. Proc. IEEE Globecom 2011, Texas, USA, Dec. 2011. R. HOUDAILLE and S. GOUACHE. Shaping http adaptive streams for a better user experience. Proc. MMSys 2012, Chapel Hill, North Carolina, USA, Feb. 2012. 3GPP TR 36.942. Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Frequency (RF) system scenarios. Jan. 2011. S. Thakolsri, W. Kellerer, and E. Steinbach. QoE-Based Cross-Layer Optimization of Wireless Video with Unperceivable Temporal Video Quality Fluctuation. IEEE International Conference on Communications (ICC), June 2011.

本発明の背景にある目的は、ネットワークを通じて複数のクライアントにマルチメディアコンテンツを送信するための改善された手法を提供することである。

上記目的は、請求項１に記載の方法、請求項１３に記載のシステム、請求項１４に記載のネットワークによって達成される。

本発明の実施の形態によれば、ネットワークを通じて複数のクライアントにマルチメディアデータを送信するための方法が提供される。マルチメディアデータは、マルチメディアレートの異なる複数のフォーマットで記憶されている。そして、本方法は、マルチメディア品質とマルチメディアレートとの関係を記述する、マルチメディアデータのためのユーティリティ情報と、前記ネットワークの状態とに基づいて、前記複数のクライアントのそれぞれについて、前記マルチメディアデータについて利用可能なマルチメディアレートを決定するステップと、所望のマルチメディアレートを有するマルチメディアデータを送信するためのクライアント要求に応じて、要求元のクライアントについて決定された利用可能なマルチメディアレートに従って、要求されているマルチメディアデータのフォーマットを選択するとともに、その選択されたフォーマットで前記マルチメディアデータを要求元のクライアントに送信するステップとを含む。

実施の形態によれば、上記方法は、前記要求から前記所望のマルチメディアレートを決定するステップを更に含む。そして、選択するとともに送信する前記ステップは、記憶されている、要求されたマルチメディアデータの複数の異なるマルチメディアレートから、前記利用可能なマルチメディアレートのうちの１つに最も合うマルチメディアレートを選択するステップを含む。

実施の形態によれば、オプティマイザ及びプロキシサーバが提供される。
オプティマイザはユーティリティ情報とネットワーク状態についての情報とを受信し、利用可能なマルチメディアレートを決定し、利用可能なマルチメディアレートをプロキシサーバに提供する。プロキシサーバは、マルチメディアデータを記憶している送信元とクライアントとの間の利用可能なフォーマットの最初のやり取りを解析することによって、利用可能なフォーマットについて把握する。ストリーミングプロセス時に、プロキシサーバは要求を受信し、フォーマットを選択し、要求を解析し、選択されたフォーマットに基づいて要求を変更し、変更された要求を、マルチメディアデータを記憶している送信元に送信する。
あるいは、オプティマイザは、利用可能なフォーマットのリストと、ユーティリティ情報及びネットワーク状態についての情報とをプロキシから受信し、利用可能なマルチメディアレートを決定し、フォーマットを選択し、選択されたフォーマットをプロキシサーバに提供する。プロキシサーバは、マルチメディアデータを記憶している送信元とクライアントとの間の利用可能なフォーマットの最初のやり取りを解析することによって、利用可能なフォーマットについて把握し、このフォーマットリストをオプティマイザに転送する。ストリーミングプロセス時に、プロキシサーバは要求を受信し、要求を解析し、受信した、選択されたフォーマットに基づいて要求を変更し、変更された要求を、マルチメディアデータを記憶している送信元に送信する。

要求を変更することには、利用可能なマルチメディアレートのうちの選択されたマルチメディアレートに基づいて、その要求を書き換えることが含まれうる。マルチメディアデータを送信するための要求はＵＲＬなどのロケータを含むことができる。該ロケータは所望のマルチメディアレートにおいて符号化されている前記マルチメディアデータに関連付けられる。この場合、要求を変更するステップは、ロケータを変更して、前記利用可能なマルチメディアレートのうちの１つにおいて符号化されている前記マルチメディアデータを保持するファイルに関連付けられているロケータと一致させるようにするステップを含むことができる。前記プロキシサーバは前記ネットワーク内に設けるか、又は前記クライアントのうちの幾つか若しくは全てに設けることができる。前記プロキシサーバが１つ以上のクライアントに設けられる場合には、前記利用可能なマルチメディアレートは、前記クライアントにあるプロキシサーバに伝達される。

更なる実施の形態によれば、前記要求及び前記利用可能なマルチメディアレートは、前記マルチメディアデータの送信元に送信される。送信元は受信した利用可能なマルチメディアレートのうちの１つに従って、前記マルチメディアデータのフォーマットを選択し、その選択されたフォーマットにおいて、要求されたマルチメディアデータを送信する。

更なる実施の形態によれば、選択されたマルチメディアレートに基づいて、前記ネットワークを通じて、前記要求されたマルチメディアデータを、要求しているクライアントに送信するための帯域幅を割り当てるステップが更に含まれる。

更なる実施の形態によれば、前記利用可能なマルチメディアレートは、送信セッションにおいて繰り返し決定され、前記ネットワークの状態の変化が考慮される。

更なる実施の形態によれば、前記マルチメディアデータは複数のセグメントを含む。各セグメントは前記メディアデータのある特定の時間を含み、前記要求は前記クライアントに送信されるセグメントを特定する。

更なる実施の形態によれば、ネットワークは有線ネットワーク又は無線ネットワークである。ネットワーク状態には、ネットワークの混雑（congestion）の状態又はネットワーク内の無線の状態が含まれる。

更なる実施の形態によれば、前記マルチメディアデータはＤＡＳＨプロトコルに従って提供され、ＨＴＴＰに従って前記クライアントに送信される。

更なる実施の形態によれば、マルチメディアデータはビデオデータを含む。

更なる実施の形態によれば、ユーティリティ情報は各マルチメディアフォーマットについてのレート歪み（rate-distortion）の情報を含む。

更なる実施の形態によれば、送信セッションにおいて、クライアントは所定の基準に従って別の所望のマルチメディアレートを選択する。この所定の基準には、クライアントにおいて利用可能なリソース及びクライアントにおけるバッファの状態が含まれうる。

更なる実施の形態によれば、クライアントは要求の変更を認識し、将来の要求に際して所望のマルチメディアレートを決定するときに、その変更を考慮する。

一実施の形態によれば、前記複数のクライアントのそれぞれについて、前記マルチメディアデータのための利用可能なマルチメディアレートを決定するステップには、マルチメディア品質とマルチメディアレートとの関係を表す、前記マルチメディアデータのためのユーティリティ情報と、前記ネットワークの状態とに基づいて、前記ネットワーク内に設けられかつ前記ユーティリティ情報と前記ネットワーク状態についての情報とを受信するオプティマイザが、基地局又はネットワークに接続されることによって共通のネットワークリソースを共有する複数のクライアントの各々について、前記マルチメディアデータについて利用可能なマルチメディアレートをともに決定するステップが含まれる。前記利用可能なマルチメディアレートは、所与のネットワーク状態において、前記マルチメディアデータの送信元において利用可能であり、かつ前記ユーティリティ情報に含まれるマルチメディアフォーマットのうちのどのマルチメディアフォーマットを各クライアントに提供することができるかを表すものである。

本発明の実施の形態によれば、本発明の実施の形態による方法をコンピュータに実行させるための、機械可読媒体に記憶される命令を含む非一時的（non-transitory）なコンピュータプログラム製品が提供される。

本発明の実施の形態によれば、ネットワークを通じて複数のクライアントにマルチメディアデータを送信するためのシステムが提供される。マルチメディアデータはマルチメディアレートの異なる複数のフォーマットで記憶されている。本システムは、本発明の実施の形態に従って動作する。

本発明の実施の形態によれば、複数のクライアントにマルチメディアデータを送信するためのネットワークが提供される。前記マルチメディアデータはマルチメディアレートの異なる複数のフォーマットで記憶されている。本ネットワークは、マルチメディア品質とマルチメディアレートとの関係を表す、前記マルチメディアデータについてのユーティリティ情報と、該ネットワークの状態とに基づいて、前記複数のクライアントの各々について、前記マルチメディアデータのための利用可能なマルチメディアレートを決定するオプティマイザと、所望のマルチメディアレートを有する前記マルチメディアデータを送信するためのクライアント要求と、前記オプティマイザから前記利用可能なマルチメディアレートとを受信し、記憶されている、要求されたマルチメディアデータの複数の異なるマルチメディアレートから、前記利用可能なマルチメディアレートのうちの１つに最も合うマルチメディアレートを選択し、利用可能なマルチメディアレートのうちの該選択されたマルチメディアレートに基づいて、前記要求を変更し、前記マルチメディアデータを記憶しているサーバが前記マルチメディアデータを前記選択されたフォーマットで要求元のクライアントに送信できるために、変更された要求を該サーバに送信するプロキシサーバとを備えている。

本願における発明者らは、上記の従来技術の手法を詳細に検討し、これらの従来技術の手法の全てが複数のパラメータを考慮しているものの、従来技術の手法のいずれもメディアコンテンツ情報を利用していないことを見いだした。この結果に基づいて、本発明の実施の形態は、無線又は有線のネットワークにおいて、実施形態に従って動的適応型ＨＴＴＰストリーミング（dynamic adaptive streaming of HTTP, ＤＡＳＨ）を用いて、ユーザ満足度を改善するための新たなメカニズムを提供するものである。実施形態によれば、ＤＡＳＨクライアントの体感品質を高めるためにＤＡＳＨプロキシサーバが用いられる。レート適応化のロジックがＤＡＳＨクライアント又はＤＡＳＨサーバでローカルに実行される従来のＤＡＳＨ手法とは異なり、本発明の実施の形態によれば、クライアント要求を傍受し、ＱｏＥオプティマイザからの入力に基づいてクライアント要求を書き換える役割を担うＤＡＳＨプロキシサーバが提供される。

したがって、本発明の実施の形態によれば、無線又は有線のネットワークにおいて複数のクライアントに対する適応的ＨＴＴＰメディア配信を最適化する、ＤＡＳＨのためのＱｏＥによるリソース割当てが提供される。このネットワークは、ＤＡＳＨプロキシサーバにおいてクライアント要求を書き換えることによって、最適化されたリソースに対するアプリケーション層のレート適応化を行う。そのため、本発明の実施の形態は、クライアント要求を書き換えることにより、ネットワークリソースをユーザの体感品質及び適応的ＨＴＴＰストリーミングに適合させるという利点を考慮したものとなっている。

本発明の実施の形態は、ネットワーク内のユーザの知覚品質を改善し、無線ネットワーク内の無線リソースの利用効率を高め、ユーザ満足度を改善し、顧客からの苦情を防ぎ、既存のＱｏＥメディア配信フレームワークと互換性があるため、有利である。

本発明の実施形態を、添付の図面を参照して説明する。

コアネットワークを通じてビデオサーバからビデオクライアントにビデオデータを提供するための環境の概略図である。 サーバとクライアントとの間のＲＴＰ／ＵＤＰストリーミング手法の概略図である。 例えば図１のサーバに記憶されるようなＤＡＳＨビデオフォーマットの一例を示す図である。 ＤＡＳＨプロトコルを利用するストリーミング技術の一例を示す図である。 サーバからＤＡＳＨクライアントにマルチメディアコンテンツを提供又は送信するための本発明の一実施形態の概略図である。 無線移動体ネットワークとの関連において本発明の更なる実施形態を示す概略図である。 図６に関して言及した手法を更に詳細に示す概略図であり、一実施形態によるプロアクティブ型プロキシ手法のブロック図である。 図６に関して言及した手法を更に詳細に示す概略図であり、別の実施形態によるプロアクティブ型プロキシ手法のブロック図である。 図６に関して言及した手法を更に詳細に示す概略図であり、一実施形態によるプロアクティブ型サーバ手法のブロック図である。 シミュレーションパラメータをまとめた表である。 ３５回のシミュレーション実行にわたって平均化された種々の手法の平均オピニオン評点（mean opinion score, ＭＯＳ）のグラフである。 ３５回のシミュレーションにわたって平均化された４つの方式の個々の性能を示す図である。 ＱｏＥオプティマイザにユーティリティ情報を与えるための実施形態を示し、ユーティリティ情報がデータベースから取得される一実施形態を示す図である。 ＱｏＥオプティマイザにユーティリティ情報を与えるための実施形態を示し、ユーティリティ情報がＭＰＤに含まれる一実施形態を示す図である。 ＱｏＥオプティマイザにユーティリティ情報を与えるための実施形態を示し、ユーティリティ情報がサーバから取得される一実施形態を示す図である。

複数の実施形態によれば、有線又は無線のネットワークにおいて複数のクライアントに対する適応的ＨＴＴＰメディア配信を最適化するＱｏＥによるマルチアクセスＤＡＳＨが提供される。適応的ＨＴＴＰストリーミング機能は本質的に、半分散化（semi-decentralized）されており、すなわち（ａ）クライアントがストリーミングのデータレートを推定するための役割を担い、セグメントの決定を行い、（ｂ）ＱｏＥオプティマイザが全体的なリソースの割当てを行う。

本発明の実施形態は、クライアント要求を書き換えることによって、適応的ＨＴＴＰストリーミングにおいてネットワークリソースをユーザが知覚する品質に適応させるという利点を考慮した手法を示すものである。スループットの変動に適応した、単一のＤＡＳＨストリームのためのレート適応化方式とは異なり、本発明の実施形態に基づくＱｏＥによるマルチユーザのレート適応化手法は、ストリームコンテンツによってレート歪みの特性が異なるものと仮定して、ユーザが体感する品質への影響を直接的に考慮する。本発明の実施形態によれば、ユーザが知覚する品質を考慮することによって、限られたネットワークリソースの利用を最適化できるようになる。さらに、無線チャネルの状態の動的な変化に起因してサービス品質が大きく変化することも防ぐことができる。

図５は、サーバ１００からＤＡＳＨクライアント１０４にマルチメディアコンテンツを提供又は送信するための本発明の一実施形態を示している。クライアント１０４は無線チャネル１０８を通じて基地局１０６に接続されており、基地局１０６とＤＡＳＨサーバ１００とはコアネットワーク１０２を通じて接続されている。本発明の実施形態によれば、トラフィック管理ユニット１１０は、クライアントごとに最適なマルチメディアレートを見いだすために設けられたＱｏＥオプティマイザ１１１を備えている。この情報はトラフィックエンジニアリングユニット１１２に転送される。トラフィックエンジニアリングユニット１１２は、クライアント要求を書き換えるとともに、要求されたＭＰＤをＱｏＥオプティマイザ１１０に送信するために設けられたＤＡＳＨプロキシサーバ１２０を有している。トラフィックエンジニアリングユニット１１２は、マルチメディアデータがサーバからクライアントに送信される際の帯域幅を制限するために設けられたレートシェーパを更に有している。ＱｏＥオプティマイザ１１１は、基地局１０６とＤＡＳＨクライアントとの間のチャネル１０８に関する情報を基地局から受信し、プロキシサーバ１２０からＭＰＤを受信するとともに、ＤＡＳＨサーバ１００に記憶されている種々の表現又はフォーマットについてのレート歪み（rate-distortion）情報といったユーティリティ情報をＤＡＳＨサーバ１００から受信する。トラフィック管理ユニット１１０に提供されるチャネル情報は、ネットワークの状態を記述したものである。ユーティリティ情報は、ビデオ品質などのマルチメディア品質と、サーバ１００に記憶されているようなビデオレートなどのマルチメディアレート（図３も参照）との関係、例えばレート歪みを記述したものである。この情報に基づいて、ＱｏＥオプティマイザ１１１は、基地局１０６又はコアネットワーク１０２に接続されうる複数のクライアント１０４のそれぞれについて、マルチメディアデータについて利用可能なマルチメディアレートを決定する。すなわち、所与のネットワーク状態において、サーバにて利用可能かつＭＰＤに含まれるマルチメディアフォーマット（図３を参照）のうち、どのマルチメディアフォーマットをクライアント１０４ａ及び１０４ｂの各々に提供できるかが決定される。この情報すなわち決定されたマルチメディアフォーマットは、トラフィックエンジニアリングユニット１１２に提供され、ＤＡＳＨプロキシサーバ１２０によって利用される。

例えば、ＤＡＳＨクライアント１０４ａが、所望の品質における特定のビデオセグメントを含む要求１１４を出すという状況を考えると、この要求１１４は、基地局１０６を通じて、ＤＡＳＨクライアント１０４ａからトラフィックエンジニアリングユニット１１２へと転送され、ＤＡＳＨプロキシサーバ１２０に提供される。ＤＡＳＨプロキシサーバはその要求１１４を評価し、その要求から、要求されたセグメントのマルチメディアレートを決定する。所望のマルチメディアレートが、ＤＡＳＨクライアント１０４ａについてＱｏＥオプティマイザ１１１が決定したマルチメディアレートに対応していないと判断された場合には、ＤＡＳＨプロキシサーバは、元のマルチメディアレートを、決定されたマルチメディアレートに置き換えることにより要求１１４を書き換え、変更された要求１１４’をサーバ１００に送る。変更された要求に含まれている情報に基づいて、サーバ１００は、符号１１６に示すように、決定されたマルチメディアレートを有するセグメントをクライアントに提供する。

例えば、図５においてその状況を考えると、チャネル情報とユーティリティ情報とを考慮して、ＱｏＥオプティマイザ１１１が、クライアント１０４ａについてのマルチメディアレートが１Ｍｂｐｓ（図３）であり、クライアント１０４ｂについてのマルチメディアレートが０．５Ｍｂｐｓ（図３）であると判断したと仮定し、さらに、ＤＡＳＨクライアントが１．５Ｍｂｐｓのマルチメディアレートを有するセグメントを得るための要求を出すもの（符号１１４）と仮定すると、本発明の実施形態は以下のように動作する。ＤＡＳＨプロキシサーバは、１．５Ｍｂｐｓのマルチメディアレートを有するセグメントを得るための要求を受信し（符号１１４）、このレートはＱｏＥオプティマイザ１１１によりクライアント１０４ａに関連付けられたレート（１Ｍｂｐｓ）と異なると判断される。そのため、プロキシサーバはクライアント要求を書き換え、要求されたセグメントのマルチメディアレートがこの時点では１Ｍｂｐｓに留まるものとなるように、変更された要求１１４’を生成する。要求１１４が品質１（ビデオレート１．５Ｍｂｐｓ）を有するセグメント１を得るための要求を含んでいたとすると、ＤＡＳＨサーバは、変更された要求１１４’を考慮し、クライアント１０４ａに対し経路１１６を通じて品質２（１Ｍｂｐｓ）に留まるセグメント１を転送することになる。

要求１１４において示されているマルチメディアレートが、決定されたマルチメディアレートよりも小さい場合には、変更された要求１１４’は、元のマルチメディアレートよりも大きなマルチメディアレートを有することができる。

図５には、２つのＤＡＳＨクライアントを有する無線環境を示しているが、本発明の実施形態に係る上記の手法は、３つ以上のクライアントを有する環境にも適用可能であることは明らかである。また、この手法は無線ネットワークには限定されず、むしろ、この手法は有線ネットワークにおいても用いることができることに留意されたい。その場合、ネットワークに（有線リンクを通じて）直接的に接続されている複数のクライアントからビデオコンテンツを要求される場合がある。ＱｏＥオプティマイザ１１１から提供される情報には、例えば１つの経路上で全てのＤＡＳＨビデオストリームに関して利用可能な全帯域幅といった、ＤＡＳＨサーバとＤＡＳＨクライアントとの間の１つ以上の取りうる経路についての情報などのネットワーク状態についての情報が含まれうる。そして、これらの状態に基づいて、ＤＡＳＨクライアントごとに最適なマルチメディアレートが決定され、プロキシサーバ１２０により上記のように利用される。

従来の手法と比べて、図５を参照して既に説明した本発明の実施形態は、より迅速なアプリケーション層のレート（ビデオ品質）の適応化と、ネットワーク状況に応じたビデオ品質のより直接的な制御とを可能にする。ＱｏＥオプティマイザ１１１からプロキシサーバ１２０に提供されるビデオレートを、ネットワークの状態の変化に応じて適応させるか又は変更することができるようにすべく、ネットワーク状態の変化を考慮するために、上記の手法は繰り返し、例えば送信セッション中に繰り返し実行できることに留意されたい。例えば、セッションの開始時には、ＤＡＳＨクライアント１０４に対して小さなビデオレートのみを利用可能とすることができるが、クライアントと基地局との間のチャネルは改善することができ、送信セッションにわたってクライアントのための利用可能な全体のレートを高めることができる。利用可能なレートが変化すると、高い品質を有するセグメントをクライアントに提供できるようにビデオレートが高められる。

図５は、ＤＡＳＨプロキシサーバ１２０がトラフィックエンジニアリングユニット１１２の一部である一実施形態を示しているが、本発明はそのような実施形態には限定されない。むしろ、各ＤＡＳＨクライアント１０４ａ、１０４ｂに、ＤＡＳＨプロキシサーバ１２０の機能を有するユニットを設けることもできる。この場合、ＱｏＥオプティマイザ１１１によって決定されたビデオレートは、ＱｏＥオプティマイザ１１１から各ＤＡＳＨクライアントに伝達されることにより、クライアント要求に応じて変更された要求をクライアント自体が容易に生成することができる。実施形態によっては、クライアントは、自らが送出した要求において、コアネットワーク１０２内でプロキシサーバ１２０によって行われた変更を把握できるようにするアルゴリズムを実行する。ＤＡＳＨクライアントは、将来の要求に関して、要求するビデオフォーマットを決定する際にこれらの変更を考慮する。一実施形態によれば、ＤＡＳＨクライアントにおいて実行されるアルゴリズムは、ＤＡＳＨサーバ１００から受信したビデオフォーマットを認識し、要求されたフォーマットと受信されたフォーマットとの間に違いがあるか否かを判断し、その情報に基づいて、要求されたフォーマットについて行われた変更が、将来の要求に関して、サーバ１００から受信したセグメントを通じて伝達された新たなフォーマットを使用することになると判断する。他の実施形態では、プロキシサーバは、変更されたビデオレートを、要求しているクライアントに対し伝達によって返送することができる。

図６は、無線移動体ネットワークとの関連において本発明の別の実施形態を示している。図５において既に示したエンティティには同じ参照符号を付している。図６にはＬＴＥコアネットワーク１０２を示しており、ＤＡＳＨクライアント１０４ａ及び１０４ｂに無線接続を提供する基地局１０６を有している。ＤＡＳＨサーバ１００はＬＴＥコアネットワーク１０２に接続されており、ＬＴＥコアネットワーク１０２は、図５に関して既に説明したＱｏＥオプティマイザ１１１と上記プロキシサーバ１２０とを有している。本発明の別の実施形態によれば、プロキシサーバは設けられず、ＱｏＥオプティマイザ１１１によって決定されたレートがＤＡＳＨサーバに提供され、ＤＡＳＨサーバは、クライアントごとに受信したレート情報に基づいて、かつコアネットワーク１０２を通じて受信した要求１１４に基づいて、適応化されたレートに従ってビデオコンテンツを提供するために、ブロック１２２に示しているようなレートの適応化を行う。

図６に示すシナリオでは、複数の移動クライアント１０４ａ、１０４ｂが、ＬＴＥコアネットワーク１０２を通じて、異なるＤＡＳＨコンテンツを同時にダウンストリーミングする。ＤＡＳＨサーバ１００においては、各コンテンツのユーティリティ情報が決定され、メディアプレゼンテーション記述（ＭＰＤ）に追加される。ユーティリティ情報は、例えば、表現の最初のセグメントにおいて、又はＭＰＤの表現におけるセグメントごとに伝達することができ、実施形態によれば、ＤＡＳＨサーバ１００に記憶されているビデオコンテンツの種々のフォーマット又は表現（図３）のためのレート歪みの情報を与えるものである。移動体ネットワークにおいて、ＱｏＥオプティマイザ１１１は、種々のＤＡＳＨクライアントについてのユーティリティ情報及びチャネル情報を含むＭＰＤを収集し、最適なマルチメディアレートを決定する。第１の実施形態（図５）によれば、プロキシサーバ１２０を設けることによってプロアクティブ型（proactive）ネットワーク手法が用いられ、プロキシサーバ１２０は、クライアントからのＨＴＴＰ要求１１４を解析し、ＱｏＥの最適化の結果に一致するＭＰＤのマルチメディア又はビデオのレートを変更する。図６に関して示した第２の実施形態、すなわちプロアクティブ型サーバ手法によれば、ＤＡＳＨサーバ１００は、ＱｏＥオプティマイザ１１１から受信したフィードバックに従って、要求しているクライアントのためのマルチメディア又はビデオのレートを事前に適応化させる。

図５及び図６を参照して既に説明した実施形態などの実施形態によれば、オプティマイザ１１１はネットワーク１０２内に設けられ、ユーティリティ情報とネットワーク状態についての情報とを受信する。オプティマイザは、基地局１０６又はネットワーク１０２に接続されることにより共通のネットワークリソースを共有する複数のクライアント１０４ａ、１０４ｂの各々につき、マルチメディアデータについて、利用できるマルチメディアレートをともに決定する。

いずれの実施形態の場合も、帯域幅シェーパ１２４（図６を参照）を設け、決定されたマルチメディアレートに基づいて、要求元のクライアントへネットワークを通じてマルチメディアデータを送信するための帯域幅を制限することができ、かつ必要なリソースを割り当てることができる。

図７は、図６を参照して述べた手法を更に詳細に表している。図７（ａ）は、一実施形態によるプロアクティブ型プロキシ手法のブロック図であり、図７（ｂ）は別の実施形態によるプロアクティブ型プロキシ手法のブロック図であり、図７（ｃ）は、一実施形態によるプロアクティブ型サーバ手法のブロック図である。図５及び図６を参照して既に説明したエンティティには同じ参照符号を付している。

図７（ａ）は、コアネットワーク（図示せず）を通じてサーバ１００に接続されているＤＡＳＨクライアント１０４ａを示している。コアネットワークは、図５を参照して既に説明したプロキシサーバ１２０とＱｏＥオプティマイザ１１１とを有している。マルチメディアストリーミングプロセスの開始時に、ＤＡＳＨクライアント１０４ａは、サーバ１００にＨＴＴＰ要求１１４ａを送信することによって、サーバから所望のマルチメディアストリームのメディアプレゼンテーション記述（media presentation description, ＭＰＤ）を要求する。要求１１４ａは、ＭＰＤのＵＲＬを含んでいる。サーバ１００は、プロキシサーバ１２０を通じて、クライアント１０４ａにＨＴＴＰ応答１１６ａを返送する。このＨＴＴＰ応答は、要求されたＭＰＤを含んでいる。ＭＰＤは、種々のセグメントのためのＵＲＬ及びマルチメディアフォーマットを含む、サーバ１００において利用可能なマルチメディアフォーマットの記述を含みうる。ＱｏＥオプティマイザ１１１は、プロキシサーバ１２０から、ユーティリティ情報を含むＭＰＤを受信することができる。ストリーミングの開始時及びその最中に、ＱｏＥオプティマイザは別のネットワーク要素（図示せず）から定期的にネットワーク状態についての情報、例えば移動体ネットワーク内のｅＮＢからチャネル状態についての情報を受信する。この情報と、ユーティリティ情報と、存在する場合には利用可能なマルチメディアフォーマットとに基づいて、ＱｏＥオプティマイザは利用可能なマルチメディアレートを定期的に決定し、それをプロキシサーバ１２０に提供する。プロキシサーバ１２０は、マルチメディアデータを記憶しているサーバ１００とクライアント１０４ａとの間の利用可能なフォーマットの初期のやり取りを解析することによって利用可能なフォーマットを把握する。また、ＱｏＥオプティマイザ１１１は、図４を参照して既に説明したように、サーバ１００からクライアント１０４ａにデータを転送する際にレートシェーピングメカニズムを提供するリソースシェーパ１２４すなわち帯域幅シェーパに、可能な帯域幅の制限についての情報も提供することができる。ストリーミング時に、所望のマルチメディアフォーマットでセグメントをダウンロードするために、ＤＡＳＨクライアント１０４ａはサーバ１００に要求１１４ｂを出す。ＨＴＴＰ要求は、所望の品質でサーバ１００に記憶されているマルチメディアセグメントのＵＲＬを含んでいる。プロキシサーバ１２０は、クライアント１０４ａから要求１１４ｂを受信し、オプティマイザから取得した利用可能なマルチメディアレートの最新の情報に従ってフォーマットを選択する。プロキシサーバ１２０は要求１１４ｂを解析し、必要に応じて、選択されたフォーマットに基づいて要求を変更し、変更された要求１１４ｂ’又は変更されていない要求１１４ｂをサーバ１００に送信する。それに応じて、サーバ１００はプロキシサーバ１２０を通じてクライアント１０４ａに、要求されたセグメントを含むＨＴＴＰ応答１１６ｂを送信する。

図７（ｂ）は、コアネットワーク（図示せず）を通じてサーバ１００に接続されるＤＡＳＨクライアント１０４ａを示している。コアネットワークは、図５を参照して既に説明したプロキシサーバ１２０とＱｏＥオプティマイザ１１１とを有している。図７（ｂ）は図７（ａ）を参照して説明した手法に類似しているが、本実施形態によれば、ＱｏＥオプティマイザ１１１が上述の情報を受信し、利用可能なマルチメディアレートを決定し、フォーマットを選択し、選択されたフォーマットをプロキシサーバ１２０に提供する点が異なる。プロキシサーバ１２０は、要求１１４ａを受信し、その要求を解析し、（ＱｏＥオプティマイザ１１１から受信した）選択されたフォーマットを指し示すものとなるようにその要求を書き換えることによって、その要求を変更し、変更された要求１１４ｂをサーバ１００に送信する。

図７（ｃ）は、コアネットワーク（図示せず）を通じてサーバ１００に直接的に接続されているＤＡＳＨクライアント１０４ａを示している。コアネットワークは、図５を参照して既に説明したＱｏＥオプティマイザ１１１を有している。マルチメディアストリーミングプロセスの開始時に、ＤＡＳＨクライアント１０４ａは、サーバ１００にＨＴＴＰ要求１１４ａを送信することによって、サーバから所望のマルチメディアストリームのメディアプレゼンテーション記述（media presentation description, ＭＰＤ）を要求する。要求１１４ａは、ＭＰＤのＵＲＬを含んでいる。サーバ１００は、クライアント１０４ａにＨＴＴＰ応答１１６ａを返送する。このＨＴＴＰ応答は、要求されたＭＰＤを含んでいる。ＭＰＤは、種々のセグメントのためのＵＲＬ及びマルチメディアフォーマットを含む、サーバ１００において利用可能なマルチメディアフォーマットの記述を含みうる。ＱｏＥオプティマイザ１１１は、ユーティリティ情報とネットワーク状態についての情報とを収集し、サーバ１００提供される利用可能なマルチメディアレートを決定する。また、ＱｏＥオプティマイザ１１１は、図４を参照して既に説明したように、サーバ１００からクライアント１０４ａにデータを転送する際にレートシェーピングメカニズムを提供するリソースシェーパ１２４すなわち帯域幅シェーパに、可能な帯域幅の制限についての情報も提供することができる。ストリーミング時に、所望のマルチメディアフォーマットにてセグメントをダウンロードするために、ＤＡＳＨクライアント１０４ａはサーバ１００に要求１１４ｂを出す。ＨＴＴＰ要求は、所望の品質にてサーバ１００に記憶されているマルチメディアセグメントのＵＲＬを含んでいる。それに応じて、サーバ１００はクライアント１０４ａに、要求されたセグメントを含むＨＴＴＰ応答１１６ｂを送信する。サーバ１００は、ＱｏＥオプティマイザ１１１から受信したフィードバックに従って、クライアント１０４ａのマルチメディアフォーマットを適応させて、データ転送レートも制限する。

以下、本発明の実施形態による手法を、単にリアクティブ型（reactive）の手法、及びいかなる適応化も行わない手法と比較する。より具体的には、プロアクティブ型ネットワーク手法（図５に示した第１の実施形態）と、プロアクティブ型サーバ手法（図６に示した第２の実施形態）と、リアクティブ型の手法とを比較する。リアクティブ型の手法では、クライアントは、ＱｏＥ最適化の結果に基づいて帯域幅シェーパにより割り当てられた利用可能な帯域幅を測定し、適切なレートを有するマルチメディアフォーマットの決定及び要求にあたってその帯域幅の測定値を使用する。従来のＤＡＳＨストリーミング手法との比較も行う。従来の手法では、ストリーミングのレート及び利用可能なリソースがそれぞれクライアント及びＬＴＥスケジューラによって決定される。いま言及したばかりの４つの方式を、ＬＴＥシステムのダウンリンクの場合に比較し、１１個の表現に符号化された種々のＤＡＳＨコンテンツを要求する８個のクライアントを対象とする。シミュレーションにおいて、マイクロソフトスムースストリーミングクライアント（Microsoft smooth streaming client）（非特許文献４）を用いる。図８は、シミュレーションパラメータをまとめた表である。

図９は、３５回のシミュレーションの平均を取った、種々の手法の平均オピニオン評点（mean opinion score, ＭＯＳ）のグラフである。全てのユーザのＭＯＳを２０秒から６０秒まで測定した。ＱｏＥ−サーバ手法（第２の実施形態）は、全てのユーザが最適なレートにおいてストリーミングしているため、最適な性能を示している。ＱｏＥ−プロキシ手法（第１の実施形態）の場合のＭＯＳは、離散した一組のビットレートのみが利用可能であるため、ＱｏＥ−サーバ手法に比べて低下している。いずれの手法もプロアクティブ型最適化に対応しており、各クライアントのマルチメディアフォーマットと対応する伝送レートとは、ＱｏＥオプティマイザ１１１によって決定される。リアクティブ型ストリーミングは、最適化されていないＤＡＳＨ最適化（ｎｏｎ−ｏｐｔ）に比べて、知覚されるビデオ品質を改善している。リアクティブ型の場合のＭＯＳも、クライアントがスループットの変化に遅れて反応し、必ずしも最良の表現レベルに収束するとは限らないので、プロアクティブ型手法に比べて低下している。ＱｏＥリアクティブ型方式及びｎｏｎ−ｏｐｔ方式の場合、マルチメディアフォーマットはクライアントによってのみ決定される。ＱｏＥ−リアクティブ型方式、ＱｏＥ−プロキシ方式及びＱｏＥ−サーバ方式は、ｎｏｎ−ｏｐｔ方式に比べて、ＭＯＳの尺度に関してそれぞれ０．２、０．３６及び０．５７だけ平均ユーザ満足度を改善している。

図１０は、３５回のシミュレーションの平均を取った、４つの方式の個々の性能を示している。ｎｏｎ−ｏｐｔ方式は、要求が厳しくないユーザの場合に良好な性能をもたらすが、バス、海岸、港のような要求が厳しいユーザの場合には不十分であることがわかる。その一方で、ＱｏＥに基づく方式は、全体的なユーザ満足度が最大となるように、ユーザにリソースを割り当てる。この結果、要求が厳しくないビデオの場合のＭＯＳを維持しつつ、要求が厳しいユーザの場合の知覚されるビデオ品質を大きく向上させる。

本発明の上記実施形態について、ビデオコンテンツを要求するクライアントを有する無線ネットワークとの関連で説明してきた。しかし、本発明は有線の環境、すなわち、ネットワークのそれぞれのラインを通じてサーバに接続されるクライアントにも同じく適用できることに留意されたい。その際、上記のように、クライアントごとに利用可能なレートは、有線ネットワーク内の特定の状態から決定される。また、本発明はビデオコンテンツには限定されず、それどころか、サーバからクライアントに送信されることになるあらゆる種類のマルチメディアデータに適用できる。このマルチメディアデータには、ビデオデータ、画像データ、オーディオデータ等が含まれうる。

さらに、上記の実施形態では、オプティマイザとプロキシサーバをネットワーク内の別々のエンティティとして示していることに留意されたい。更に別の実施形態によれば、オプティマイザ及びプロキシサーバは共通のエンティティ、例えばオプティマイザ及びプロキシサーバの両方の機能を実行する共通のコンピュータ又はサーバによって実現することができる。

図１１は、ＱｏＥオプティマイザにユーティリティ情報を提供するための実施形態を示している。図１１（ａ）は、ユーティリティ情報をデータベースから取得する一実施形態を示している。図１１（ｂ）は、ユーティリティ情報がＭＰＤに含まれる一実施形態を示している。図１１（ｃ）は、ユーティリティ情報をサーバから取得する一実施形態を示している。

図１１（ａ）は、サーバ１００と、クライアント１０４ａと、プロキシサーバ１２０と、ＱｏＥオプティマイザ１１１とを概略的に示したブロック図である。さらに、ユーティリティ情報を保持するデータベース１２６を示している。この実施形態によれば、クライアント１０４ａは、ＭＰＤのＵＲＬを含むＨＴＴＰ要求をサーバへ送信することによって、サーバから所望のマルチメディアストリームのメディアプレゼンテーション記述（ＭＰＤ）を要求する。サーバ１００は、種々のセグメントのためのＵＲＬ及びマルチメディアフォーマットを含む、サーバにおいて利用可能なマルチメディアフォーマットの記述、例えばビデオ名を含んだＭＰＤを返送する。プロキシサーバ１２０はＭＰＤを受信し、ビデオ名を導き出し、それをオプティマイザ１１１に転送する。オプティマイザ１１１は、受信したビデオ名に基づいて、データベース１２６に問い合わせ、クライアント１０４ａによって要求されているビデオのためのユーティリティ情報を受信する。

図１１（ｂ）の実施形態によれば、サーバは、クライアント１０４ａからの要求に応じて、データベース１２６に問い合わせ、要求されたＭＰＤについてのユーティリティ情報を検索する。サーバ１００は、ユーティリティ情報を含むものとなるようにＭＰＤを変更する。変更されたＭＰＤは、その後、プロキシサーバ１２０を通じて、クライアント１００及びＱｏＥオプティマイザ１１１へと送信される。

図１１（ｃ）の実施形態によれば、サーバ１００は、クライアント１０４ａからの要求に応じて、データベース１２６に問い合わせ、要求されたＭＰＤについてのユーティリティ情報を検索する。サーバ１００は、ユーティリティ情報をオプティマイザに直接的に転送する。上記の全ての実施形態において、ユーティリティ情報はデータベース１２６に記憶することができ、ＭＰＤ内に存在するようなマルチメディアコンテンツの名前又はＵＲＬによりアクセスすることができる。

幾つかの態様を装置との関連で説明してきたが、これらの態様は、対応する方法の記述も表していることは明らかであり、この対応する方法では、ブロック又はデバイスが、方法ステップ又は方法ステップの特徴に対応する。同様に、方法ステップとの関連で説明した態様も、対応する装置の対応するブロック又は項目又は特徴の記述を表している。

或る特定の実施態様要件に依拠して、本発明の実施形態はハードウェア又はソフトウェアにおいて実施することができる。実施態様は、電子的に読取り可能な制御信号が記憶されたデジタル記憶媒体、例えばフロッピーディスク、ＤＶＤ、ＣＤ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、又はフラッシュメモリを用いて実行することができ、それらは、それぞれの方法が実行されるようにプログラム可能なコンピュータシステムと連携する（又は連携可能である）。

本発明による幾つかの実施形態は、本明細書に記載される方法のうちの１つが実行されるように、プログラム可能なコンピュータシステムと連携することができる電子的に読取り可能な制御信号を有する非一時的（non-transitory）なデータキャリアを含む。

概して、本発明の実施形態は、プログラムコードを有するコンピュータプログラム製品として実装することができる。該プログラムコードは、コンピュータプログラム製品がコンピュータ上で実行されると、方法のうちの１つを実行するように動作可能である。プログラムコードは、例えば機械可読キャリア上に記憶することができる。

他の実施形態は、機械可読キャリア上に記憶された、本明細書に記載された方法のうちの１つを実行するコンピュータプログラムを含む。

したがって、換言すれば、本発明の方法の一実施形態は、コンピュータプログラムがコンピュータ上で実行されるときに本明細書に記載された方法のうちの１つを実行するためのプログラムコードを有するコンピュータプログラムである。

したがって、本発明の方法の更なる実施形態は、データキャリア（又はデジタル記憶媒体若しくはコンピュータ可読媒体）であって、該データキャリア上に記録された、本明細書に記載された方法のうちの１つを実行するためのコンピュータプログラムを含む、データキャリアである。

したがって、本発明の方法の更なる実施形態は、本明細書に記載された方法のうちの１つを実行するコンピュータプログラムを表すデータストリーム又は信号シーケンスである。データストリーム又は信号シーケンスは、例えば、データ通信接続を介して、例えばインターネットを介して転送されるように構成することができる。

更なる実施形態は、本明細書に記載された方法のうちの１つを実行するように構成又は適合された処理手段、例えばコンピュータ又はプログラム可能な論理デバイスを含む。

更なる実施形態は、本明細書に記載された方法のうちの１つを実行するためのコンピュータプログラムがインストールされたコンピュータを含む。

幾つかの実施形態では、プログラム可能な論理デバイス（例えばフィールドプログラマブルゲートアレイ）を用いて、本明細書に記載された方法の機能のうちの幾つか又は全てを実行することができる。幾つかの実施形態では、フィールドプログラマブルゲートアレイは、本明細書に記載された方法のうちの１つを実行するためにマイクロプロセッサと連携することができる。概して、本方法は任意のハードウェア装置によって実行されることが好ましい。

上述した実施形態は、単に本発明の原理を説明するものである。本明細書において記載される構成及び詳細の変更及び変形は当業者には明らかであることが理解される。したがって、添付の特許請求の範囲によってのみ限定され、本明細書における実施形態の説明及び説明のために提示した特定の具体例によって限定されるものではないことが意図される。

Claims (15)

1. あるマルチメディアデータの送信元（１００）がネットワーク（１０２）を通じて複数のクライアント（１０４ａ、１０４ｂ）へ該マルチメディアデータを送信するための方法であって、前記マルチメディアデータはマルチメディアレートが異なる複数のフォーマットにより記憶されており、
   マルチメディア品質とマルチメディアレートとの関係を表す、前記マルチメディアデータに関するユーティリティ情報と、前記ネットワーク（１０２）の状態とに基づいて、前記ネットワーク（１０２）内に設けられかつ前記ユーティリティ情報と前記ネットワークの状態に関する情報とを受信するオプティマイザ（１１１）が、基地局（１０６）又は前記ネットワーク（１０２）に接続する前記複数のクライアント（１０４ａ、１０４ｂ）の各々について、前記マルチメディアデータに関して利用可能なマルチメディアレートを決定するステップであって、前記利用可能なマルチメディアレートは、前記ネットワークの所与の状態において、前記マルチメディアデータの送信元（１００）において利用可能であり、かつ前記ユーティリティ情報に含まれるマルチメディアフォーマットのうちのどのマルチメディアフォーマットを各クライアント（１０４ａ、１０４ｂ）に提供することできるかを表すものである、ステップと、
   所望のマルチメディアレートを有するマルチメディアデータを送信するためのクライアント要求（１１４）に応じて、その要求元のクライアント（１０４ａ、１０４ｂ）について前記オプティマイザ（１１１）が決定した前記利用可能なマルチメディアレートに基づいて、要求されたマルチメディアデータのフォーマットを選択するとともに、該選択されたフォーマットにより前記マルチメディアデータを前記要求元のクライアント（１０４ａ、１０４ｂ）へ送信するステップと
   を含む方法。
2. 前記要求（１１４）から前記所望のマルチメディアレートを決定するステップを更に含み、
   選択するとともに送信する前記ステップが、記憶されている、要求された前記マルチメディアデータの複数の異なるマルチメディアレートから、前記利用可能なマルチメディアレートのうちの１つに最も合うマルチメディアレートを選択するステップを含むものである、請求項１に記載の方法。
3. 前記ネットワーク（１０２）がプロキシサーバ（１２０）を備えており、
   前記オプティマイザ（１１１）が、前記利用可能なマルチメディアレートを前記プロキシサーバ（１２０）に提供し、該プロキシサーバ（１２０）が、前記要求（１１４）を受信し、フォーマットを選択し、前記要求（１１４）を解析し、選択された前記フォーマットに基づいて前記要求（１１４）を変更し、変更された要求（１１４’）を前記マルチメディアデータの送信元（１００）へ送信するか、又は、
   前記オプティマイザ（１１１）が更にフォーマットを選択するとともに、選択された該フォーマットを前記プロキシサーバ（１２０）に提供し、該プロキシサーバ（１２０）が、前記要求（１１４）を受信し、該要求（１１４）を解析し、受信した、選択されたフォーマットに基づいて前記要求（１１４）を変更し、変更された要求（１１４’）を前記マルチメディアデータの送信元（１００）へ送信する、請求項２に記載の方法。
4. マルチメディアデータを送信するための前記要求（１１４）が、ＵＲＬなどのロケータを含み、該ロケータは前記所望のマルチメディアレートにおいて符号化されているマルチメディアデータと関連付けられているものであり、
   前記要求（１１４）の変更が、ロケータを変更して、前記利用可能なマルチメディアレートのうちの１つにより符号化されたマルチメディアデータに関連付けられているロケータと合うようにすることを含む、請求項３に記載の方法。
5. 前記プロキシサーバ（１２０）が前記ネットワーク（１０２）に設けられるか、又は前記クライアント（１０４ａ、１０４ｂ）のうちの幾つか若しくは全てに設けられ、
   前記プロキシサーバが１つ以上の前記クライアント（１０４ａ、１０４ｂ）に設けられる場合には、前記利用可能なマルチメディアレートが、前記クライアント（１０４ａ、１０４ｂ）の前記プロキシサーバに伝達される、請求項３又は４に記載の方法。
6. 前記要求（１１４）と前記利用可能なマルチメディアレートとが、マルチメディアデータの前記送信元（１００）に送信され、
   該送信元（１００）が、受信した前記利用可能なマルチメディアレートのうちの１つに基づいて前記マルチメディアデータのフォーマットを選択し、選択した該フォーマットにより、要求されたマルチメディアデータを送信する、請求項１に記載の方法。
7. 選択されたマルチメディアレートに基づいて、要求されたマルチメディアデータを、前記ネットワーク（１０２）を通じて前記要求元のクライアント（１０４ａ、１０４ｂ）に送信するための帯域幅を割り当てるステップを更に含む請求項１〜６のいずれか一項に記載の方法。
8. 前記利用可能なマルチメディアレートは、前記ネットワーク（１０２）の状態の変化を考慮するために、送信セッションにおいて繰り返し決定されるものであり、
   前記マルチメディアデータは複数のセグメントを含み、各セグメントは前記メディアデータのうちのある特定の時間を含むものであり、
   前記要求（１１４）は、前記クライアント（１０４ａ、１０４ｂ）に送信されるセグメントを特定するものである、請求項１〜７のいずれか一項に記載の方法。
9. 前記ネットワーク（１０２）が有線ネットワーク又は無線ネットワークであり、前記ネットワークの状態が、前記ネットワーク（１０２）の混雑の状態又は前記ネットワーク（１０２）の無線の状態を含むものである、請求項１〜８のいずれか一項に記載の方法。
10. 前記マルチメディアデータはＤＡＳＨプロトコルに基づいて提供され、ＨＴＴＰに基づいて前記クライアント（１０４ａ、１０４ｂ）に送信され、
    送信セッションにおいて、クライアント（１０４ａ、１０４ｂ）が所定の基準に従って別の所望のマルチメディアレートを選択し、
    送信セッションにおいて、クライアント（１０４ａ、１０４ｂ）が所定の基準に従って別の所望のマルチメディアレートを選択する、請求項１〜９のいずれか一項に記載の方法。
11. 前記クライアント（１０４ａ、１０４ｂ）が前記要求（１１４）における変更を認識し、将来の要求（１１４）にあたり所望のマルチメディアレートを決定する際に該変更を考慮するものである、請求項１〜１０のいずれか一項に記載の方法。
12. 請求項１〜１１のいずれか一項に記載の方法をコンピュータに実行させるための、機械可読媒体に記憶される命令を含む非一時的なコンピュータプログラム製品。
13. ネットワーク（１０２）を介して複数のクライアント（１０４ａ、１０４ｂ）にマルチメディアデータを送信するためのシステムであって、前記マルチメディアデータはマルチメディアレートの異なる複数のフォーマットにより記憶されており、請求項１〜１１のいずれか一項に記載の方法に基づいて動作するシステム。
14. 複数のクライアント（１０４ａ、１０４ｂ）にマルチメディアデータを送信するためのネットワーク（１０２）であって、前記マルチメディアデータはマルチメディアレートの異なる複数のフォーマットにより記憶されており、
    マルチメディア品質とマルチメディアレートとの関係を表す、前記マルチメディアデータについてのユーティリティ情報と、前記ネットワーク（１０２）の状態とに基づいて、前記複数のクライアント（１０４ａ、１０４ｂ）の各々について、前記マルチメディアデータについての利用可能なマルチメディアレートを決定するオプティマイザと、
    所望のマルチメディアレートを有するマルチメディアデータを送信するためにクライアント（１０４ａ、１０４ｂ）から要求（１１４）を受信するとともに、前記オプティマイザから前記利用可能なマルチメディアレートを受信し、記憶されている、要求されたマルチメディアデータの複数の異なるマルチメディアレートから、前記利用可能なマルチメディアレートのうちの１つに最も合うマルチメディアレートを選択し、前記利用可能なマルチメディアレートのうちの選択されたマルチメディアレートに基づいて前記要求（１１４）を変更し、前記マルチメディアデータを記憶しているサーバ（１００）が、前記マルチメディアデータを選択されたフォーマットにより要求元のクライアント（１０４ａ、１０４ｂ）に送信できるようにするために、変更された要求（１１４’）を該サーバ（１００）に送信するプロキシサーバ（１２０）と
    を備えたネットワーク（１０２）。
15. 前記サーバ（１００）から前記クライアント（１０４ａ、１０４ｂ）へとマルチメディアデータのセグメントが送信される帯域幅を、前記オプティマイザから伝達される帯域幅に制限するレートシェーパを更に備えた請求項１４に記載のネットワーク（１０２）。

Images