特許第6254631号(P6254631)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェラインの特許一覧
<>
  • 特許6254631-情報資源管理概念 図000025
  • 特許6254631-情報資源管理概念 図000026
  • 特許6254631-情報資源管理概念 図000027
  • 特許6254631-情報資源管理概念 図000028
  • 特許6254631-情報資源管理概念 図000029
  • 特許6254631-情報資源管理概念 図000030
  • 特許6254631-情報資源管理概念 図000031
  • 特許6254631-情報資源管理概念 図000032
  • 特許6254631-情報資源管理概念 図000033
  • 特許6254631-情報資源管理概念 図000034
  • 特許6254631-情報資源管理概念 図000035
  • 特許6254631-情報資源管理概念 図000036
  • 特許6254631-情報資源管理概念 図000037
  • 特許6254631-情報資源管理概念 図000038
  • 特許6254631-情報資源管理概念 図000039
  • 特許6254631-情報資源管理概念 図000040
  • 特許6254631-情報資源管理概念 図000041
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6254631
(24)【登録日】2017年12月8日
(45)【発行日】2017年12月27日
(54)【発明の名称】情報資源管理概念
(51)【国際特許分類】
   H04W 4/06 20090101AFI20171218BHJP
   H04W 24/10 20090101ALI20171218BHJP
   H04W 72/04 20090101ALI20171218BHJP
   H04W 80/10 20090101ALI20171218BHJP
【FI】
   H04W4/06 171
   H04W24/10
   H04W72/04 130
   H04W80/10
【請求項の数】9
【全頁数】77
(21)【出願番号】特願2016-60223(P2016-60223)
(22)【出願日】2016年3月24日
(62)【分割の表示】特願2014-536283(P2014-536283)の分割
【原出願日】2012年10月22日
(65)【公開番号】特開2016-140101(P2016-140101A)
(43)【公開日】2016年8月4日
【審査請求日】2016年3月29日
(31)【優先権主張番号】61/550,126
(32)【優先日】2011年10月21日
(33)【優先権主張国】US
(73)【特許権者】
【識別番号】500341779
【氏名又は名称】フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン
(74)【代理人】
【識別番号】100085497
【弁理士】
【氏名又は名称】筒井 秀隆
(72)【発明者】
【氏名】シール,トーマス
(72)【発明者】
【氏名】ヴィルス,トーマス
(72)【発明者】
【氏名】ハウスタイン,トーマス
(72)【発明者】
【氏名】サンチェス,ヤーゴ
【審査官】 羽岡 さやか
(56)【参考文献】
【文献】 特開2011−082808(JP,A)
【文献】 特開2004−248160(JP,A)
【文献】 特開2005−142808(JP,A)
【文献】 特表2006−521035(JP,A)
【文献】 特開2007−006476(JP,A)
【文献】 特表2007−520905(JP,A)
【文献】 欧州特許出願公開第1298931(EP,A2)
【文献】 国際公開第2011/015243(WO,A1)
【文献】 国際公開第2011/087449(WO,A1)
【文献】 Telefon AB LM Ericsson, ST-Ericsson SA,IMS based Adaptive HTTP Streaming[online], 3GPP TSG-SA WG4#61 S4-100783,インターネット<URL:http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_61/Docs/S4-100783.zip>,2010年11月
(58)【調査した分野】(Int.Cl.,DB名)
H04W 4/00−99/00
3GPP TSG RAN WG1−4
SA WG1−4
CT WG1、4
(57)【特許請求の範囲】
【請求項1】
通信資源を用いて通信するユーザーエンティティであって、そのユーザーエンティティ上でクライアント(40)が動作可能であり、前記ユーザーエンティティは、
受信済みのメディアコンテンツ・スループット又は前記クライアントによってサーバー(42)からリトリーブされたメディアコンテンツをバッファリングするための前記クライアントのバッファの充満レベルを決定し、
前記サーバーから受信されたメディア・プレゼンテーション記述から、前記メディアコンテンツの異なる帯域幅の複数のバージョンを表すパラメータのセットを導出し、
前記ユーザーエンティティが属する複数のユーザーエンティティに対して前記通信資源を割り当てる役割を担う資源管理装置(30)に、前記決定されたメディアコンテンツ・スループット又は充満レベルと、前記パラメータのセットと、について通知する、
ユーザーエンティティ。
【請求項2】
請求項1に記載のユーザーエンティティであって、前記メディアコンテンツ・リトリーブが伝送されるOSIレイヤよりも低いOSIレイヤ内で前記通知を実行する、ユーザーエンティティ。
【請求項3】
通信資源をユーザーエンティティ(34)に対して割り当てる、資源管理装置であって、
前記ユーザーエンティティの1つで動作しているクライアント(40)からサーバー(42)へのデータトラフィック内の明示的な信号伝達から、前記クライアントにおけるメディアコンテンツをバッファリングするための充満レベルについての情報を抽出し、
前記ユーザーエンティティから、前記サーバーから前記クライアントへ送られたメディア・プレゼンテーション記述から導出され、かつ前記メディアコンテンツの異なる帯域幅の複数のバージョンを記述している、パラメータのセットを受信し、
前記パラメータのセットと前記充満レベルに関する情報とに依存して、前記通信資源を前記ユーザーエンティティ(34)に対して割り当てる、
資源管理装置。
【請求項4】
請求項3に記載の資源管理装置であって、前記ユーザーエンティティに対する通信資源の割り当てを、
−前記通信資源が適切な割合で割り当てられるべき前記ユーザーエンティティ(34)の数、
−前記ユーザーエンティティと基地局との間で交換されるべき通信データの種類、
−前記ユーザーエンティティに割り当てられたユーザープロファイルであって、前記ユーザーエンティティ間の優先順位を定義するプロファイル、
−前記ユーザーエンティティからのチャネル品質フィードバック、
−前記ユーザーエンティティからのチャネルレート要求、
の内の1つ又は複数に基づいて実行する、資源管理装置。
【請求項5】
請求項4に記載の資源管理装置であって、前記通信資源を前記ユーザーエンティティに対して割り当てる際に、前記充満レベルについての情報に依存して、
−サブキャリア、
−集約されたサブキャリア、
−時間スロット、
−前記基地局セルの空間的カバー範囲、
の内の1つ又は複数を調整する、資源管理装置。
【請求項6】
請求項3乃至5のいずれかに記載の資源管理装置であって、前記クライアント(40)から前記サーバー(42)へのデータトラフィック内の明示的な信号伝達から前記充満レベルについての情報を抽出するか、又は、前記ユーザーエンティティ(34)から基地局(32)へのチャネル品質フィードバックに基づいて前記クライアント(40)に関連する前記充満レベルをシミュレートすることにより、前記充満レベルについての情報を導出する、資源管理装置。
【請求項7】
クライアント(40)が動作可能であるユーザーエンティティ上で実行される方法であって、前記ユーザーエンティティは通信資源を用いて通信している、方法において、
受信済みのメディアコンテンツ・スループット又は前記クライアントによってサーバー(42)からリトリーブされたメディアコンテンツをバッファリングするための前記クライアントのバッファの充満レベルを決定するステップと、
前記サーバーから受信されたメディア・プレゼンテーション記述から、前記メディアコンテンツの異なる帯域幅の複数のバージョンを表すパラメータのセットを導出するステップと、
前記ユーザーエンティティが属する複数のユーザーエンティティに対して前記通信資源を割り当てる役割を担う資源管理装置(30)に対し、前記決定されたメディアコンテンツ・スループット又は充満レベルと、前記パラメータのセットと、について通知するステップと、
を含む方法。
【請求項8】
資源管理方法であって、
ユーザーエンティティの1つで動作しているクライアント(40)からサーバー(42)へのデータトラフィック内の明示的な信号伝達から、前記クライアントにおけるメディアコンテンツをバッファリングするための充満レベルについての情報を抽出するステップと、
前記ユーザーエンティティから、前記サーバーから前記クライアントへ送られたメディア・プレゼンテーション記述から導出され、かつ前記メディアコンテンツの異なる帯域幅の複数のバージョンを記述している、パラメータのセットを受信するステップと、
前記パラメータのセットと前記充満レベルに関する情報とに依存して、通信資源を前記ユーザーエンティティ(34)に対して割り当てるステップと、
を含む、資源管理方法。
【請求項9】
コンピュータ上で作動されたとき、請求項7又は8に記載の方法を実行するためのプログラムコードを有するコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は無線ネットワークにおけるネットワーク無線情報資源(リソース)管理のような資源管理に関する。
【背景技術】
【0002】
近年、インターネットを通じたマルチメディアの配信は急激に増加しており、ネットワーク内における帯域幅の主要な消費者となってきた。このような増加と並行して、モバイルネットワークにおける大いなる進歩により、3GPPの高速ダウンリンク・パケットアクセス(HSDPA)や、発展しつつある長期進化版(LTE)ネットワークなどの、高速アクセスネットワークが出現した。
【0003】
モバイルネットワークにおける発展とともに、IPサービスは、日々の生活の中で至る所に存在する事実となるよう期待されている。近年の研究によると、マルチメディア・コンテンツの消費、特にビデオストリーミングは、増大し続けると考えられており(非特許文献1を参照)、これはモバイルネットワークの進化の結果とも考えられる。事実、非特許文献2によれば、モバイルネットワークにおけるデータトラフィックの約50%はビデオデータであり、2015年までに世界中の移動データトラフィックの3分の2がビデオになると予測されている。
【0004】
HTTPストリーミングは、最近の数年内に登場した前途有望なマルチメディア・アプリケーションの内の1つであり、市場による受け入れが想定外に良好なものである。この点については、様々な標準化団体、例えばMPEG(非特許文献3を参照)及び3GPP(非特許文献4を参照)や、又は独占ソリューションであるIISスムーズ・ストリーミング(非特許文献5を参照)及びHTTPライブ・ストリーミング(非特許文献6を参照)などによって実行されている、適応的HTTPストリーミングに関する標準化活動からも明らかである。
【0005】
メディア・ストリーミングは、RTP/UDPと、その低い待ち時間ゆえに事前に関連付けられてきたが、メディア配信に関してHTTP/TCPに依存することは、過酷な遅延制限を考慮しなくてよいシナリオにおいては、非常に貴重なソリューションとなることが分ってきた。なぜなら、RTP/UDPでは典型的な、NAT及びファイアウォール内を横断する問題が存在しないからである。
【0006】
HTTPを介するダイナミック適応ストリーミング(DASH)(非特許文献3を参照)は登場しつつあるMPEG標準であり、HTTPを用いたマルチメディア配信のためのフォーマットを定義するものである。それは基本的に2つの構成要素からなる。即ち、ダウンロードされるべきメディアのフォーマットと、ダウンロードされるべきメディアの記述とである。現存する独占ソリューションは、類似の手法に基づいている。
【0007】
メディアフォーマットは、基本的にセグメントと呼ばれるビデオの典型的には小さな時間区間の中で構築されており、それらセグメントは、連続的にダウンロードされた場合にメディアの連続的な表現を可能にする。さらに、通常、メディアの様々なビットレートにおける様々な表現(例えばエンコード)がサーバーにおいて利用可能であるため、ユーザー主導の適応、即ち検知されたネットワーク・スループットに基づいてユーザーが表現を選択できる適応が可能となっている。異なる時間区間についての異なる表現のセグメントをダウンロードすることが許可されているため、結果的に、以下に記載するメディア・プレゼンテーション記述(MPD)内に提示された全ての切り替え制限が遵守される場合には、完全に再生可能なメディアとなるであろう。
【0008】
DASHにおいて、フォーマットの記述はMPDによって与えられる。MPDはXMLドキュメントであり、データと、特にサーバーにおいて利用可能なセグメントとを記述する。MPDを使用することで、クライアントは、彼らのネットワーク・スループット又は彼らの条件に適合する要求を作成するために必要な情報を入手できる。
【0009】
DASHにおいて、クライアントは適応を実行する責任がある。ユーザーの利益と機器能力とネットワークの現在の状態とに基づいて、DASHのクライアントは、MPD内に記述された表現であって、クライアントの要件/能力に最も適合する表現を選択しなければならない。DASHアーキテクチャの一例を図1に示す。
【0010】
図1から分かるように、DASHの環境に参加しているエンティティは、DASHサーバー10であって、それぞれのDASHクライアント12に対して配信されるべきそのメディアコンテンツをあるDASHコンテンツ準備ステージ14から受信するサーバー10と、DASHクライアント12自身と、「HTTPキャッシュ(Cache)」と示されるネットワーク16を介してDASHサーバー10とDASHクライアント12とを相互に接続するネットワークと、である。図3に示すように、DASHクライアントがDASHサーバー10からメディア・プレゼンテーション記述MPD18を受信する場合、DASHクライアントは、テレビ装置、コンピュータ又はその他の適切なユーザー端末上で作動してもよく、そのMPD18は、DASHコンテンツ準備ステージ14によってメディアコンテンツのバージョンとともに生成されていたものであって、DASHサーバー10において利用可能なメディアコンテンツの種々のバージョンを記述するよう生成されたものである。
【0011】
図2は、DASH標準「ISO/IEC 23009−1」からのエンティティを使用するLTEネットワークにおけるDASHの展開アーキテクチャの現状技術を示す。白色のボックスはDASHのシステムを表し、影付きのボックスはLTEのシステムを表す。より詳細には、DASHのインフラストラクチャをLTEネットワークへと伝送する際に、DASHクライアント12は、LTE基地局20と無線チャネル22とユーザーエンティティ24との連鎖を介してHTTPキャッシュ16へと接続されることが示されており、また、無線資源管理部26は基地局20に含まれており、ユーザーエンティティ24は携帯電話やその他などの移動端末であってもよく、そこでは、DASHクライアント12が例えばそのユーザーエンティティのプロセッサ上で実行するソフトウエアの形態で作動していてもよい。DASHクライアント12とLTEeNB(LTEに対応した基地局機器)20とは、メディア・プレゼンテーション記述(MPD18)に対するアクセスを有すると推定される。MPD18は、ユーザー12に対するストリーミング・サービスを提供するのに十分な、サーバー10にあるビデオ表現に関する情報を、ユーザーが要求するセグメントによって、TCP/IPを伝送プロトコルとして使用しながら、HTTPサーバー10から供給する。最初に、DASHクライアント12はHTTPサーバー10に対してHTTPゲット要求を伝送する。HTTPハンドシェーク(初期接続)の後で、サーバー10とクライアント12との間のTCPトンネルが確立する。このTCPトンネルは、基底にある物理的なトランスポートレイヤに関してはトランスペアレントである。MPD18によって供給される情報に依存して、DASHクライアント12は、包含されたメディアデータを適切に逆多重化、復号化及びレンダリングするために十分な情報を得る。
【0012】
図2で説明するシナリオに含まれる問題は、DASHクライアント12の通常の挙動である。即ち、各DASHクライアント12が、各サーバー10に存在するメディアコンテンツのバージョンのうちそのユーザーに対して現時点で割り当てられた通信資源において、即ち無線資源管理部26によって各DASHクライアント12のユーザーエンティティ24に対して割り当てられた通信資源において、最高の品質及び/又は情報コンテンツを有するバージョンを供給するよう求めることである。「最高の」品質/情報コンテンツとは、最大空間解像度、最大数のビュー、最大幅深度などを有するものであってもよく、その結果、最も高い帯域幅を必要とする。換言すれば、各DASHクライアント12は、基地局26の利用可能な無線資源を最大限に使用しようとするものであり、基地局と無線資源管理部26とはそれぞれ、各ユーザーエンティティの各DASHクライアントが取得したいと欲する、メディアコンテンツの利用可能なより高レベルのバージョンのうちの1つを得るための、割り当てられた通信資源を増大させようとする絶え間ない要求に対処しなければならない。当然ながら、このことは、ユーザーエンティティに対する無線通信資源の次善的な分配を招くことになり、その場合、分配又はスケジューリングは、現在のチャネル状態と個々のユーザーエンティティ24に割り当てられたユーザープロファイルとに基づいて実行される。
【先行技術文献】
【非特許文献】
【0013】
【非特許文献1】Cisco White Paper, “Cisco Visual Networking Index: Forecast and Methodology, 2009-2014,” June 2010.
【非特許文献2】Cisco White Paper, “Cisco Visual Networking Index: Global Mobile Data-Traffic Forecast Update,” 2010_2015.
【非特許文献3】Information technology _ Dynamic adaptive streaming over HTTP (DASH) _ Part 1, “Media presentation description and segment formats, ISO/IEC DIS 23009-1,” August 2011.
【非特許文献4】3GPP, “Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs (Release 9); 3GPP TS 26.234 V9.3.0 (2010-06): Adaptive HTTP Streaming”.
【非特許文献5】A. Zambelli, “”IIS smooth streaming technical overview”. Microsoft Corporation, 2009”
【非特許文献6】HTTP Live Streaming Architecture,“Technical report, Apple Inc.,”2010.
【非特許文献7】T. Wiegand, G. J. Sullivan, G. Bjontegaard and A. Luthra, “Overview of the H.264/AVC Video Coding Standard,” in IEEE Transactions on Circuits and Systems for Video Technology, 2003.
【非特許文献8】A. Tacz, A. Temesvary and N. Reider,“Handover Performance in 3GPP Long Term Evolution (LTE) Systems,” in Mobile and wireless Communications Summit, 2007.
【非特許文献9】T. Stockhammer, M. Walter and G. Liebl, “Optimized H. 264-Based Bitstream Switching for Wireless,” in ICME, 2005.
【非特許文献10】S. Sharma, D. Gillies and W. Feng, “On the Goodput of TCP NewReno in Mobile Networks,” in ICCCN, 2010.
【非特許文献11】H. Schwarz, D. Marpe and T. Wiegand, “Overview of the scalable video coding extension of the H.264/AVC standard,” in IEEE Transactions on Circuits and Systems for Video Technology, 2007.
【非特許文献12】T. Schierl, Y. Sanchez, R. Globisch, C. Hellge and T. Wiegand, “Priority-based Media Delivery using SVC with RTP and HTTP streaming,” in Springer Multimedia Tools and Application, September 2010
【非特許文献13】W. Mulder and T. Wirth, “Are we ready for the femtolution?,” in IEEE COMSOC MMTC E-letter, Sep. 2010.
【非特許文献14】ITU-R, Report M.2134, “Requirements related to technical performance for IMT-Advanced radio interface(s), Approved in Nov 2008”
【非特許文献15】3GPP, “Physical layer; General description (Release 8); 3GPP TS 25.201 V8.1.0 (2008-05): Adaptive HTTP Streaming”.
【非特許文献16】3GPP, “Evolved Universal Terrestrial Radio Access (E-UTRA) and evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description (Release 8); 3GPP TS 36.300 V8.12.0 (2010-03): Adaptive HTTP Streaming”.
【非特許文献17】Leekwijck, Y. Sanchez, T. Schierl, C. Hellge, T. Wiegand, D. Hong, D. De Vleeschauwer and W. Van, “iDASH: improved Dynamic Adaptive Streaming over HTTP using Scalable Video Coding,” in ACM Mmsys, 2011.
【非特許文献18】J. Mahdavi and S. Floyd. TCP-friendly unicast rate-based flow control. January, 1997
【非特許文献19】3GPP TS 23202, Policy and charging control architecture, Release 113GPP TS
【非特許文献20】24301,Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)
【非特許文献21】3GPP TS 29274, Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3
【非特許文献22】3GPP TS 36413, Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)
【非特許文献23】3GPP TS 36423, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 application protocol (X2AP) (Release 11)
【非特許文献24】3GPP TS 36420, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 general aspects and principles(Release 11)
【発明の概要】
【発明が解決しようとする課題】
【0014】
そこで、本発明の目的は、例えば最大数のユーザーを満足させるために利用可能な通信資源のより効率的な使用を可能にする資源管理概念を提供することである。
【課題を解決するための手段】
【0015】
この目的は、独立請求項に記載の要旨によって達成される。
【0016】
本発明の好適な実施形態を、以下に図面を参照しながら説明する。
【図面の簡単な説明】
【0017】
図1】DASHアーキテクチャの一例のブロック図である。
図2】LTEネットワーク内のDASHに関する現在の展開アーキテクチャを示すブロック図であり、実線で描かれた白色のボックスはDASHの標準で指定された装置を示し、破線で描かれた白色のボックスは概念的又はトランスペアレントである。
図3】無線資源管理部を含む例示的な無線資源環境のブロック図であり、本発明に係る無線資源管理部の種々の実施形態を、これに基づいて説明する図である。
図4】メディアレート対瞬時レート対セグメント・ダウンロードレートを示すグラフである。
図5図3の無線資源管理部の第1実施例の可能性のある一構成を示す図である。
図6】無線資源管理部を含む他の例示的な無線資源環境のブロック図であり、本発明に係る無線資源管理部の種々の実施形態を説明する図である。
図7】無線資源管理部を含むユーザーエンティティのブロック図であり、本発明に係る無線資源管理部の種々の実施形態を説明する図である。
図8図6の無線資源管理部の一実施例の可能性のある一構成を示す図である。
図9図3及び図6の無線資源管理部の一実施例の可能性のある一構成を示す図である。
図10図7の実施形態における使用に適切なクライアントの可能性のある一構成を示す図である。
図11図10の資源管理部を含む例示的な無線資源環境のブロック図である。
図12図3又は図6に係る資源管理部を含む他の例示的な無線資源環境のブロック図である。
図13】クライアントとサーバーとの間のデータ経路の一部の可能性のある一構成を示し、クライアントの可能な一構成を含むブロック図である。
図14】一方のユーザーエンティティにおいてサーバーが作動し、他方のユーザーエンティティにおいて対応するクライアントが動作するようなシナリオにおいて実行される、一実施形態に従う一連のステップを示す。
図15】クライアントが動作するユーザーエンティティの資源管理部がMPD解析の無線資源管理部の負担を軽減させるようなシナリオにおいて実行される、一連のステップを示す。
図16】アップリンク(上り回線)通信資源を割り当てる無線資源管理部を含む例示的な無線資源環境の一実施形態に従うブロック図である。
図17】他の実施形態に係る無線資源管理部のシステムを示す。
【発明を実施するための形態】
【0018】
図3は本願に係る無線資源管理部の第1の実施形態を示す。図3の無線資源管理部は、全体的には参照符号30で示され、基地局32の通信資源をユーザーエンティティに対して割り当てるよう構成されており、ユーザーエンティティの1つが符号34を用いて代表的に示される。ユーザーエンティティ34は、例えば携帯電話、ラップトップ又はその他の移動端末であるが、静止したデバイスであってもよい。ユーザーエンティティ34は、基地局32と、1つ又は複数のアンテナ(図示せず)を介する無線チャネル36を通して通信することができる。基地局32は、通信データ、即ちダウンリンク(下り回線)データ及びアップリンクデータの、チャネル36上への多重化を適切に管理することができ、また、1つ又は複数のアンテナ(図示せず)を有することができる。特に、基地局32は、様々なユーザーエンティティ34のためのダウンリンクデータを、基地局32により出力される伝送信号上に適切に多重化できる。この目的で、種々の多重化方式が使用可能である。例えば、基地局32は、OFDM、特にLTEを使用しても良い。いずれの場合にも、基地局32は、ユーザーエンティティ34を含むユーザーエンティティに対し、通信チャネルの通信資源を時間的に変化する方法で分配又は割り当てることができるため、ユーザーエンティティに対する基地局32の通信資源の割り当て、即ち特にスケジューリングと呼ばれる割り当てを、現在の資源状態に対して適応させることができる。例えば基地局32は、そのスケジューリングを実行するために、以下のパラメータの任意の組合せを用いてもよい。
1)基地局32によってサービス提供されるユーザーエンティティの数、即ち基地局32における登録を行ったユーザーエンティティ34の数であり、従って、それらの間で基地局の通信資源が分配されるべきユーザーエンティティ34の数。
2)個々のユーザーエンティティと交換されるべき通信データの種類であって、その通信データの種類は、例えばスピーチ信号のようなリアルタイム(低遅延)メディアデータを、HTTPの要求されたデータやその他から区別するものである。
3)サービス提供されるユーザーエンティティに割り当てられるユーザープロファイルであって、それらプロファイルは、例えばダウンリンク及び/又はアップリンクのために、異なる最大ビットレート及び/又は最小ビットレートが割り当てられるか、又は、ユーザーエンティティ間の優先順位を定義するものであり、その場合、RRM(無線資源管理部)30は、通信資源を割り当てるに際し、より高位の優先順位を持つユーザーエンティティをより低位の優先順位を持つユーザーエンティティよりも優先させる。
4)ユーザーエンティティからのチャネル品質フィードバックであって、ユーザーの現在の受信品質状態、即ち、基地局32を一方とし、サービス提供される個々のユーザーエンティティ34を他方とするチャネルの品質を示しており、基地局32は、例えばユーザーエンティティからのそれぞれのチャネルフィードバック信号によってチャネル品質を測定する。
5)ユーザーエンティティからのチャネルレート要求であって、ユーザーエンティティが更なる帯域幅の割り当てを希望していることを示す。
【0019】
2つ以上の基地局32と38とが1つのユーザーエンティティにサービス提供する場合、上述の数は、ある範囲内のユーザーエンティティに対して現在サービス提供している、又は少なくともサービス提供のために利用可能である、全ての基地局によってサービス提供されるユーザーエンティティの数に関係する。通信資源の割り当てを決定する際には、これら基地局間の相互作用も考慮されてよい。そのようなシナリオにおいては、RRM30によってアグリゲートされたサブキャリアのような情報、又は、RRM30によって導出されたセル間のハンドオ−バー(受渡し)のようなユーザーエンティティ34についての情報は、更に基地局32と38との間で共有されることができ、また、より高いレベルのRRM30によって収集されかつ使用されてもよい。
【0020】
基地局32は、ユーザーエンティティに対して通信資源を異なるように割り当てるために、異なる選択肢/パラメータを有していてもよい。この点は、ダウンリンクとアップリンクの両方の通信に関して当てはまる。例えば基地局32は、以下の設定の任意の組合せによってスケジューリングを構成できる。
1)サービス提供されるユーザーエンティティに対する、OFDMサブキャリアのようなサブキャリアの関連付け。典型的には、LTEにおいて使用されるサブキャリアの最大数は、20MHzの帯域幅である。当然ながら、この点は変更可能である。先進LTE(LTE-Advanced)と呼ばれるLTEの後継版については、20MHzから100MHzまでの多数のキャリアが審議中となっている。これはキャリア・アグリゲーションと呼ばれている。つまり、サブキャリアはまた、アグリゲートされたサブキャリアであってもよい。
2)サービス提供されるユーザーエンティティに対する時間スロットの割り当て又は分配。
3)基地局セルの空間的カバー範囲(spatial coverage)であって、その中ではユーザーエンティティが基地局32と通信可能であるべき範囲であり、この空間的カバー範囲は、例えばMIMO技術を使用して変更し得るものである。
4)個々のサブキャリアの変調コンステレーション(modulation constellations)に対する関連付け。
【0021】
上述の設定選択肢のいずれかによってスケジューリングを構成しない場合には、基地局32は、それぞれの伝送特性を使用しないか、又は、代わりに固定的な設定を使用してもよい。例えば、基地局32は、ダウンリンク内で時分割多重化を使用しなくてもよく、アップリンク内で時分割多重化を使用しなくてもよく、又は、それぞれの時分割多重化が時間に亘って固定化されていてもよい。同様のことが、サブキャリアの割り当てを含む、周波数分割多重化のMIMO機能に関しても当てはまる。
【0022】
いずれの場合でも、割り当てられた通信資源に依存して、各ユーザーエンティティ34はダウンリンクとアップリンクとの両方に関し効率的な伝送帯域幅を得ることができる。
【0023】
軽微な点であるが、図3の無線資源管理部30は、基地局32に含まれてもよく、その一部であってもよく、又は収容されていてもよい点に注意すべきである。しかしながら、無線資源管理部30はまた、基地局32から物理的に分離して配置されてもよい。特に、無線資源管理部30は、所定の基地局と特別に関連付けられていないこともあり得る。むしろ無線資源管理部30は、より多数のユーザーエンティティに対する無線資源管理を実行でき、結果として、2つ以上の基地局からなるセルをもたらすこともできる。例えば、図3は任意の他の基地局38を示し、その通信資源もまた任意ではあるが、無線資源管理部30によって制御されていてもよい。特に、基地局32及び38と無線資源管理部30とが一緒になり、無線ネットワークを形成して、2つ以上の基地局によるサービス提供をユーザーエンティティが同時に受けられるようにすることも可能である。つまり、両方の基地局セルの重複範囲内に現時点で存在しているユーザーエンティティは、無線資源管理部30によってそれに対して割り当てられた両方の基地局の通信資源を有することができる。従って、その場合、ユーザーエンティティ34の事実上利用可能な通信帯域幅は、サービス提供している基地局32と38との各々によって提供された、又は割り当てられた、有効帯域幅の合計となるであろう。当然ながら、サービス提供している基地局の数は増大し得る。
【0024】
いずれの場合でも、これまで説明したように、無線資源管理部30の機能に係る問題は、ユーザーエンティティ34のようなユーザーエンティティの内の1つにおいて動作しているクライアント40が、サーバー42からできるだけ高度な情報コンテンツレベルを有するバージョンのメディアコンテンツを取得したいと欲することである。クライアントは、例えば、ブラウザのようなユーザーエンティティのオペレーティングシステム上で実行しているアプリケーションであってもよく、VoIP(IPを用いる音声通信)アプリケーション又は同様のものでもよいが、他の可能性も同じく存在する。次に、サーバーは、コンピュータのようなホスト上で実行しているVoIPアプリケーション又はメディアコンテンツ・サーバーのようなプログラムであってもよく、他の移動ユーザーエンティティ、ワークステーション又はネットワークであってもよい。
【0025】
例えば、ユーザーエンティティ34のクライアント40がサーバー42からメディアコンテンツ44をダウンロードしたいと欲しており、また、このメディアコンテンツ44がサーバー42においてメディア・プレゼンテーション記述46によって記述された種々のバージョンで利用可能であり、そのメディア・プレゼンテーション記述がサーバー42からクライアント40にとって利用可能でもあると想定する。メディアコンテンツ44の種々のバージョンは、以下のパラメータの内の任意の部分集合の組合せにおいて異なっていてもよい。
1)空間解像度
2)時間解像度
3)ビューの数
4)ビット深度
5)信号対雑音比
6)オーディオチャネルの数
【0026】
つまり、メディアコンテンツ44はビデオであってもよい。クライアント40がサーバー42からメディアコンテンツ44を取得するときに用いるデータトラフィックは、少なくとも無線資源管理部30によって調査可能であり、その様子は点線48によって示されているが、サーバー42とクライアント40との間のデータトラフィックは、基地局32、又は基地局32及び38、をそれぞれ経由するものであり、その場合、データトラフィックのコンテンツは、矢印50で示すように、無線資源管理部30によって検査し得るものである。代わりに、データトラフィックは、破線の矢印52で示すように、無線資源管理部30を経由してもよく、この場合、無線資源管理部30は、クライアント40とサーバー42との間のデータトラフィックの一部分を検査するだけでなく、当該部分に対してインターセプトし又は影響を与えることも可能である。
【0027】
データトラフィックは、HTTPなどの任意の適切なプロトコルを使用してもよい。根底にある伝送プロトコルは、TCP又はUDPであってもよい。
【0028】
しかしながら、本発明の実施形態の説明はHTTPストリーミングに焦点を当てているが、データ伝送そのものは、例えばRTP[IETF RFC 3550]を介するように様々に適用されてもよい。従って、1つのセッションにおけるメディアの記述は、SDP[IETF RFC 4566](セッション記述プロトコル)ファイルによって与えられる。そのようなSDPファイルは、本願では「MDP」として認識されるべきであり、そこから選択されるべき様々な符号化パラメータのような様々なメディア特性を記述することを可能にするものである。
【0029】
メディアコンテンツ44の種々のバージョンがメディアコンテンツ44の異なる量の情報を伝達するという事実に起因して、これらのバージョン間では、クライアント40においてそれぞれのバージョンを中断することなく再生するために必要な必要最小要求伝送帯域幅に関し、順位付けが可能となる。
【0030】
通常、クライアント40は、ユーザーに対してメディアコンテンツ44に関する可能な限り最高の情報を提供できるバージョンを供給するよう構成される。可能な限り最高のバージョンとは、ユーザーエンティティ34において利用可能なディスプレイ及びラウドスピーカ、メディアプレーヤ又は復号器などのユーザーエンティティ34により利用可能な機器を用いて、ユーザーに対して提供し得る範囲内の1つのバージョンとして定義されてもよい。更に正確に言えば、図3には示していないが、ユーザーエンティティ34は、メディアコンテンツ44のフレームシーケンスを表示するためのディスプレイと、そのフレームシーケンスに随伴されていた最適なオーディオ信号を再生するための1つ又は複数のラウドスピーカと、を含んでもよい。後者の場合には、クライアント40はユーザーに対し、例えばユーザーエンティティ34のディスプレイによって再現可能な最高の空間解像度を提供するメディアコンテンツ44のバージョンを供給するよう試みてもよい。
【0031】
最後に、クライアント40は、例えばHTTP要求などによってメディアコンテンツ44の所望のバージョンをサーバー42から要求する。ユーザーに供給されるべきバージョンについてクライアント40が決定できるようにするため、クライアント40は、サーバー42からクライアント40へのデータトラフィック内でメディア・プレゼンテーション記述46の提供を受ける。例えば、クライアント40は、メディアコンテンツ44のメディア・プレゼンテーション記述46をサーバー42から要求し、サーバー42はこれに応じてメディア・プレゼンテーション記述46をクライアント40へと送信する。上述したようにメディア・プレゼンテーション記述46は、クライアント40に対して、サーバー42において利用可能なメディアコンテンツ44のバージョンとそれらバージョンの必要最小要求伝送帯域幅とを示す。そこで、クライアント40は、無線資源管理部30によってユーザーエンティティ34へと提供又は割り当てられた現在の利用可能な有効帯域幅を評価して、通常は最高レベルのバージョンを選択し、その結果として、ビデオ無線資源管理部30によって提供される有効帯域幅よりも低いか又は同等レベル範囲内の最高の最小要求伝送帯域幅を求めることになる。
【0032】
しかしながら、本願明細書の導入部において説明したように、ユーザーエンティティにおいて動作している全てのクライアント40がユーザーに対してそれぞれのメディアコンテンツの最大帯域幅のバージョンを提供したいと欲するので、基地局32の通信資源に課せられる逼迫度(strain)が高まってしまう。但し、例えばもしクライアント40がその要求バージョンレベルを低くすれば、その逼迫度はそれ程高くなくなるはずである。
【0033】
そこで図3の実施形態によれば、無線資源管理部30は、ユーザーエンティティ34を含むユーザーエンティティに対し、各サーバー42から各ユーザーエンティティ34において動作している各クライアント40に向かうデータトラフィックの中のメディア・プレゼンテーション記述46に依存して、基地局32の通信資源を割り当てるよう構成されている。以下の説明からさらに明確になるように、そのようなMPD46に対する依存性を用いてRRMによって割り当てられる通信資源は、特にアップリンク及び/又はダウンリンクの通信資源に関係してもよく、それらアップリンク及び/又はダウンリンクの通信資源は、全体の通信資源の主要な部分を代表するものであり、またTCPの肯定応答(acknowledgment)フィードバック・ループ又は上述の品質フィードバックなどの制御信号を含んでいてもよい。
【0034】
更に詳細には、無線資源管理部30は、サーバー42からクライアント40へのデータトラフィック内でビデオコンテンツ44の様々な帯域幅を有するバージョンを記述するメディア・プレゼンテーション記述46を検査し、更に、ユーザーエンティティ34が含まれる複数のユーザーエンティティに対して基地局32の通信資源を割り当てるときに、メディア・プレゼンテーション記述によって提供された情報を他の入力パラメータと共に考慮する。
【0035】
例えば、サービス提供されるべきユーザーエンティティ34の数が多いために、もし現在、通信資源に対して高い逼迫度が課せられている場合には、無線資源管理部30は、クライアント40によってサーバー42から現在要求されているメディアコンテンツ44のバージョンがクライアント40に対して現時点で利用できないと決定してもよく、従って、ユーザーエンティティ34に割り当てられる通信資源の量を削減し、結果的に、ユーザーエンティティ34に提供される有効帯域幅を事実上減少させてもよい。換言すれば、無線資源管理部30は次のような決定をしてもよい。即ち、高い逼迫状況においては、基地局32の通信資源に対して高い逼迫度が掛かっている間に少なくとも一時的には、メディアコンテンツ44のより高いレベルのバージョンからそのより低いレベルのバージョンへと、クライアント40が切り替わるべきであるという決定である。勿論、RRM30はそのようなより低い帯域幅バージョンの存在を事前にチェックしてもよい。当然ながら、クライアントは、例えばセル内のクライアントによって見られるビデオ品質を最適化するためなどの理由によって、より高い帯域幅を有するバージョンを取得して最小の受け入れ可能なビデオ品質又は情報量を取得してもよい。換言すれば、RRM30は、セル・スループットを最適化することだけを目標にして、通信資源をクライアントに対して割り当てる必要はない。むしろRRM30は、セル内の全てのクライアントのためのビデオ品質を考慮にいれてもよい。更に換言すれば、勿論、クライアントが最高品質を公然と求めてくる場合もある。そのようなクライアントの例は、以下に説明するような自動切替えモードのクライアントである。
【0036】
他の視点から見ると、無線資源管理部30は、通信資源が割り当てられるべき2つ以上のユーザーエンティティ34のクライアント40が、少なくとも1つの基地局32を介してそれぞれのメディアコンテンツ44を現在ダウンロード中である場合には、それら2つ以上のユーザーエンティティ34に対する通信資源の割り当てを以下のように実行してもよい。即ち、サーバーとクライアントとからなる各ペア間の各データトラフィック内にある各メディア・プレゼンテーション記述46に依存して、費用関数が最適化されるように実行してもよく、その費用関数とは、少なくともクライアントの各メディアコンテンツ44についてのバージョンの品質尺度(quality measure)と最小帯域幅とに依存している。更に詳細には、最適化されるべき費用関数が、複数のクライアントの各メディアコンテンツ44についての複数のバージョンに亘って決定される、全体的な帯域幅と全体的な品質尺度との間の妥協点を形成してもよい。このような最適化の結果として、クライアントが元来適用されていたものよりも低い品質のメディアコンテンツのバージョンのための帯域幅を割り当てられる可能性があり、同様に、クライアントが元来適用されていたものよりも高い品質のメディアコンテンツのバージョンのための帯域幅を割り当てられる可能性もある。個々のメディアコンテンツのバージョンについての「品質尺度」は、区間スケールされる必要がない。@qualityRankingによって提供される順位スケール(ordinal scale)でも十分となり得る。つまり、順位スケールだけが個々のメディアコンテンツに関係する場合もあり得る。順位性(ordinality)は、全てのクライアント40の全てのメディアコンテンツの間で有効である必要はない。しかし、追加的な情報が最適化費用関数の中に含まれる可能性があり、その情報とは例えばそれぞれのメディアコンテンツの符号化の複雑性の値、即ちメディアコンテンツの平均レート/歪みの尺度に関する値などである。この符号化の複雑性の値は、非常に粗いものでもよい。例えば、以下に説明する@contentCharacteristicもそのような特性であり得る。このような情報の全ては、それぞれのクライアントによって要求されたそれぞれのメディアコンテンツのメディア・プレゼンテーション記述46の中に含まれてもよい。
【0037】
更に、無線資源管理部30は、クライアント40によって要求されたメディアコンテンツ44のバージョン履歴を記録し、基地局30の通信資源についての逼迫度が再び低減した段階で、その履歴を使用してそれぞれのクライアント40に対してより高い量の通信資源を再度割り当てるようにしてもよい。
【0038】
クライアント40は、次に無線資源管理部30によって供給された現在の有効帯域幅を評価することにより、以下のことを実現させてもよい。即ち、割り当てられる通信資源量を低くするとRRM30が決定した場合、現時点で要求されてダウンロードされているメディアコンテンツ44のバージョンは、中断を含む状態でのみユーザーに対して提供可能となるということである。換言すれば、ユーザーに対してメディアコンテンツ44を再生しつつあるメディアプレーヤのメディアバッファが、無線通信経路36を介して利用可能な伝送帯域幅の減少によって空になりつつあることに、クライアント40は気付くであろう。この状況に対して、クライアント40はその希望どおりに自由に反応できるが、クライアント40の合理的な選択肢の1つは、クライアントがサーバー42に対して要求を送信して、メディアコンテンツ44のより低いバージョン、即ちメディアコンテンツ44の現時点でダウンロードされたバージョンと比べてより低い必要最小伝送帯域幅と関連するバージョンを要求することである。
【0039】
要約すると、図3の実施形態に従えば、無線資源管理部30はスケジューリングを実行するが、その際に、上述した利用可能な資源、ユーザーエンティティのフィードバックによって示されたチャネル品質、関連するユーザーエンティティからの資源要求の数、ユーザーエンティティ間の優先順序などに対する依存性に加え、サーバーとそれぞれのユーザーエンティティにおいて動作しているクライアントとの各ペアの間に延びるデータトラフィックの中のメディア・プレゼンテーション記述46にも依存して実行する。
【0040】
図3の実施形態に関しては、クライアント30は、例えばユーザーエンティティ・プロセッサ上で実行しているソフトウエアを表していてもよいことに留意すべきである。代替的に、クライアントは、ハードウエア又はプログラム可能なハードウエア内に構成されてもよい。
【0041】
従って、図3は、サーバー42からユーザーエンティティ32の内の1つにおいて動作しているクライアント40へのデータトラフィック内のメディア・プレゼンテーション記述46に依存して、基地局32の通信資源をユーザーエンティティ34に対して割り当てるよう構成された、無線資源管理部を表している。
【0042】
以下に、図3の可能な構成例を説明する。この可能な構成例に従えば、クライアント30は、HTTPを用いたビデオストリーミングを使用して、サーバー42からメディアコンテンツ44を取得する。特に、HTTPを用いたビデオストリーミングに使用される根底にある伝送プロトコルは、TCP[RFC 793]でもよい。
【0043】
事実、本明細書で指摘する事項は、以下に説明する特性を共有する全てのプロトコルについて有効である。本明細書で考慮対象となるプロトコルは、TCPのために使用される、ACK(肯定応答)/NACK(Negative-acknowledgement:否定応答)又はSACK(Selective-acknowledgement:選択的応答)などの任意の他のタイプの応答受領に基づいた輻輳制御機構を有する接続指向のプロトコルである。1つの可能性として、これらのプロトコルは、輻輳制御機構のスループット適応の結果と並行して、パケット損失に対処するための追加的な再伝送機構を使用してもよい。そのようなプロトコルの一例として、HTTPを介するビデオストリーミングのために使用される根底の伝送プロトコルがTCP[RFC 793]である場合を挙げることができる。TCPは信頼性を提供するよう強化された特徴を有するストリーミング・データの伝達を提供するものであり、その特徴は、例えば肯定応答メッセージ(ACK)と、例えばスロースタートを用いた輻輳制御、輻輳回避、高速再伝送及び高速回復などのフロー制御機構と、を使用するものである。フロー制御は、送信機に対してどれくらい多くのバイトが内部バッファのオーバーフローなしに受信され得るかを示す。関連するメディアとステータス・レートは、図4と表1とに示されている。図4に示すように、パケット損失は受信されたTCPスループットに対して影響を与え、同様のことが上述した特徴を有する他のいずれのプロトコルに対しても予想される。更に、下記の式は、パケット損失(p)とラウンドトリップタイム(RTT)と最大伝送ユニット(MTU)(非特許文献18を参照)とに基づいて、TCPスループットの非常に良好な推定を示すものである。このように、伝送におけるネットワークレイヤ・パケット損失を追跡することは、無線資源管理部が基地局32の通信資源を適切に割り当て得るようにするための非常に効果的な技術である。従って、基地局32は、損失無線フレーム/MACレイヤ・パケットデータユニット、より高いレイヤのMTUサイズ、無線資源管理部30のMACバッファ100(図13を参照)におけるTCPパケット損失などの、PHYレイヤ情報を用いて、例えばTCPに関するトランスポートレイヤなどのより高いネットワークレイヤ上の実際のパケット損失レートを導出してもよい。
【0044】
【数1】
【0045】
【表1】
【0046】
例えば図3に関し、無線資源管理部3が、メディアコンテンツのMPD46のうちのどのバージョンをクライアント40が現在ダウンロード中であるかをチェックする方法として、種々の可能性を有している。例えばRRM30は、基地局32を介してクライアント44によって現在ダウンロードされつつあるメディアコンテンツ44のバージョンを、クライアント40からサーバー42へのメディア要求を検査することによって決定してもよい。しかし、RRM30におけるより少ない追跡作業を用いたより簡素な処理が次の場合に達成し得る。即ち、RRM30がクライアントの受信されたメディア・スループットに関するスループット尺度を決定し、その決定されたスループット尺度に基づいて、メディアコンテンツ44のメディア・プレゼンテーション記述46のうちのどのバージョンが、少なくとも1つの基地局32を介して現時点でクライアント40によってダウンロードされているかを予測する場合である。スループット尺度としては、割り当てられた帯域幅自身が使用されてもよい。代替的に、RRM30は、上述したように、それぞれのユーザーエンティティに対して元来割り当てられた帯域幅から見た、それぞれのクライアント40の実際に受信されたメディアコンテンツ帯域幅のずれ/減少を、それぞれのユーザーエンティティ34から基地局32へと送信された品質フィードバックを評価することで、推定してもよい。更に代替的には、ユーザーエンティティの追加的な機能によって、RRM30に対し、実際に受信されたメディアコンテンツ・スループットレートについての情報が与えられてもよい。
【0047】
上述の説明では、無線資源管理部がサーバー42からクライアント40へのデータトラフィックを調査して、メディア・プレゼンテーション記述46を取得すると想定していたが、それに代えて、このオーバーヘッドは、ユーザーエンティティ内のあるエンティティであって、ユーザーエンティティの送受信ステージとクライアントとの間(例えば図7を参照)のエンティティなどに置き換えられてもよい。つまり、この調査はユーザーエンティティ内の調査ステージによって行われてもよい。その調査ステージは、MPD30か、その抜粋など少なくともその一部か、又はMPDの一部から導出されたパラメータの集合を、RRM30へと(逆)転送してもよく、その場合、抜粋又はパラメータの集合はメディアコンテンツを記述するために十分であり、そのバージョンはサーバー32において利用可能であってもよい。従って、ユーザーエンティティ34は、上述のように無線資源基地局32と通信するよう構成されてもよく、またその場所でクライアント40が動作可能であってもよい。しかしその場合、ユーザーエンティティ34はサーバー42からクライアント40へのデータトラフィックを調査するよう構成されてもよく、それにより、データトラフィックからメディア・プレゼンテーション記述46を導出して、そのメディア・プレゼンテーション記述を少なくとも部分的に無線資源管理部30へと転送してもよい。後段で説明するが、ユーザーエンティティは、クライアント40の代わりにその場所で動作するサーバーを有していてもよい。しかしその場合、RMは同様に作動している。即ち、そのサーバーからそのユーザーエンティティ以外のいずれかのクライアントへのデータトラフィックを調査することで、MPDを導出している。
【0048】
更に、次に説明する図3の構成においては、クライアント40とサーバー42とは、サーバー42からクライアント40へとメディアコンテンツをストリーミングするために、DASHを使用してもよい。DASHは、メディア・プレゼンテーション記述に関する所定の構造又はシンタックスを定義する。DASHによれば、MPDは、DASHクライアントとDASHのHTTPサーバーとの間の論理的チャネルを設定するために必要なパラメータを特定するために、タグを使用する。タグは、文字Oを用いて印付けされた任意のタグであってもよく、又は、文字Mを用いて印付けされた必須のタグであってもよい。
【0049】
図3の実施形態を構成する場合、MPEG DASH標準(ISO/IEC 23009−1)(非特許文献3を参照)から取られたMPDタグの組合せが使用されてもよい。
【0050】
特に、必須の@bandwidthタグが考慮対象となってもよく、その@bandwidthタグは@minBufferTimeタグに依存しているため、その場合、この@minBufferTimeタグも準必須となる。
【0051】
MPDが構築され得るタグは、以下の表2に示すタグを含む。
【0052】
【表2-1】
【0053】
【表2-2】
【0054】
【表2-3】
【0055】
【表2-4】
【0056】
【表2-5】
【0057】
つまり、図3のMPD46は、各利用可能な バージョン(表現)に関し、@bandwidth、@minBufferTime、及び任意ではあるが@qualityRankingを有してもよい。
【0058】
上記から分かるように、MPD46は、1つのバージョン毎にこれらパラメータの最初の2つ、即ち@bandwidthと@minBufferTimeとだけを含んでもよい。
【0059】
MPDの一例を下記のリスト1に示す。この例は、例えばDASH標準(非特許文献3を参照)でプロファイル属性によって識別されたような特定のプロファイルに対応していてもよい。メディア・プレゼンテーション時間は3256秒で特定され、最小のバッファ時間は1.2秒である。2つの表現のセグメントのURL(統一資源ロケータ)は次のように与えられる。1つの表現は64KB又は32KBの帯域幅を要求し、また、そのセグメントのURLが、各表現のそれぞれのSegmentList要素に含まれる二者択一のBaseURLとSegmentURLとの内の連鎖状の1つによって作成される。セグメントの持続時間は、SegmentList要素内の持続時間属性によって与えられる。
【0060】
【表A】
【0061】
更に、以下により詳細に説明する図3の実施形態の構成は、LTEシステム内に埋め込まれてもよい。つまり、基地局32又は基地局32及び38と、無線資源管理部30とが、LTEシステムの一部であってもよい。
【0062】
LTEに関しては、様々な改善が導入されてきた。多入力多出力(MIMO)強化と組合せられた直交周波数分割多重アクセス(OFDMA)への進展と、回路スイッチからパケットスイッチ・ネットワークへの移行の結果、2×2/4×4のMIMOを有するLTE Rel.8について、150/300Mbpsまでのピークスループットを達成するモバイルネットワークがもたらされた。LTEの重要な達成点の1つは、ITU−R(非特許文献15を参照)の待ち時間条件(latency requirements)、即ち制御プレーン上では50msを下回り、ユーザープレーン上では5msを下回る遅延を持つという、終端間の低遅延通信にとって不可欠な条件を満足させたことである。
【0063】
LTEは高速再伝送メカニズムを実現する。即ち、自動繰返し要求(ARQ)及びハイブリッドARQ(HARQ)機構を、物理(PHY)レイヤと、メディアアクセス制御(MAC)レイヤとにおいて達成し、受信機における高速リオーダーリングを要求する。このため、リオーダーバッファリングによって追加的なジッターと遅延とが導入される可能性があり、その結果、リアルタイムTCPサービスに関し、特にHTTP/TCPビデオサービスが識別されず、最大限のサービスとしてオーバー・ザ・トップを実行する場合、パーフォーマンスが劣化する恐れがある。LTEにおけるハンドオーバー期間中のTCPパーフォーマンスは、非特許文献12において評価されており、そこでは、特別なパケット転送技術とパケットリオーダーリングが、高度なTCPパーフォーマンスを達成するために必要であることが示されている。
【0064】
加えて、LTEは、基地局即ち進化型NodeB(eNB)における非集中的なスケジューリングと、多数ユーザーの無線資源管理(RRM)とを導入する。非集中的な手法は、HTTP/TCPライブストリーミングなど種々のトラフィックサービスに関する終端間(end-to-end)のQoS(サービス品質)を実現させるために、QoSサポートを伴う、新たなロバスト性のあるクロスレイヤ・スケジューリング・アルゴリズムの設計を必要とする。
【0065】
RRMエンティティ、即ち無線資源管理部30は、無線資源管理の責任を担い、その管理は、短期間の時間フレーム上でUE即ちユーザーエンティティ34に対して資源を割り当てる、スケジューリングとも呼ばれる作業を含むと共に、長期の資源割り当ても含み、この資源割り当ては、より長い時間フレーム上での作業であり、例えばUEフィードバック、ユーザーサービスデマンドなどの種々のパラメータに依存する作業である。割り当てられるべき資源は、MIMO OFDMAに基づいたLTEにおいて使用されている、時間、周波数、空間−グリッドから取得される。資源の量は、使用されるべきLTEパラメータ帯域幅、FDD又はTDDモード、及びMIMOモードに依存する。
【0066】
DASHをメディアコンテンツのストリーミングに使用しながら、無線資源管理部30をLTEシステム内に埋め込む状態で、図3の実施形態を構成した場合の結果を図5に示す。図3に示された構成要素の機能を、図5に示す実施形態がどのように構成するかを理解し易くするために、図3の参照符号を図5でも再使用しており、図3に関して上述したこれら構成要素の説明は、図5についても同様に適用されるべきである。これは、RRM30が基地局32の内部に物理的に含まれる必要がないことも意味する。他方では、図3において対応する参照符号がなかった部分については、図2の参照符号も図5内で再使用されている。従って、基地局32を超えるデータトラフィック部分に関しては、データトラフィックは、インターネットなどのHDTPキャッシュ16を介して通じるように、クライアント40がサーバー42に対して通信可能に接続されている。更に、DASHコンテンツ準備ステージ14が示され、ここからメディア・プレゼンテーション記述46のコンテンツが由来してもよい。
【0067】
図5の実施形態の動作例のモードを説明する場合、それらはLTEを介するDASHを用いた無線資源管理と呼ばれてもよい。メディアコンテンツのバージョンの可能な表現として、VCが使用されてもよい。図5の実施形態は図3の実施形態に従っているため、図5のRRM30の機能は、クライアントに対してより効率的に無線資源を割り当てるために、受動的な信号伝達を実現する。
【0068】
特に、DASHクライアント40はビデオセグメントについてのHTTP要求をサーバー42に送信する。RRMユニット30は、その特定のユーザー又はクライアント40によって要求されたMPD46を、ディープ・パケット・インスペクション50を用いて検査する。MPD46内で定義された@bandwidthと@minBufferTimeタグとに依存して、スケジューラと長期RRM30とは、所与の@minBufferTimeに関して要求された帯域幅を実現する。しかし、LTEのPHYデータパイプが要求された帯域幅をサポートしていない場合には、RRM30は自動的に、MPD46又は‘sidx’-Box及びMPDの内部のメディアコンテンツのAVCビデオセグメントについて特定された次に低い帯域幅を保証するよう試みる。DASHクライアント40は、LTEのRRM30のデータレート制限に従い、例えばHTTPゲット52を、MPD46内のリストに挙げられたより低いレート要求を有するサービスへと送信することで、そのHTTPゲット要求52を調整する。
【0069】
これにより以下の事項が保証される。
1.HTTPビデオストリームの保証付きサービス配信
2.できるだけ多数の資源を得ようと試みる所与のユーザーに対して資源を過度に供給することを防止する。
3.上記2により、所与の時間-周波数-空間グリッドに関し、LTEセル内の他のユーザーのために資源を節約することが可能となる。このため、IPスループットにおける変動が減少し、従って、種々のトラフィックミックスを多数のユーザーへと円滑に配信することが可能となる。
4.TCPはLTEシステムによって割り当てられたデータレートへと最適に適応するであろう。
【0070】
セルラーシステム内の無線資源は同じeNBに接続された全てのユーザー間で共有されるため、1つのユーザーに対して割り当てられた資源量は、他のユーザーに対してどれだけ多くの資源が利用可能であるかに関して影響を与える可能性がある。従って、RRM30は、たとえあるユーザーが非常に良好なチャネル状態を有していた場合でも、他のユーザーをサポートすることを優先させた結果、そのユーザーに対する資源量を減少させることを選択できる。ビットレートとコンテンツの特性(コンテンツのタイプ、例えば映画、ニュース、スポーツなど)又は@qualityRankingを考慮して、セル内の全てのユーザーに亘る全体的なビデオ品質の最適化が実行され得る。
【0071】
トリックモード(例えば早送り、高速巻戻し、ジャンプなど)の使用は、クライアント40により要求されるチャンクのシーケンスによって、RRM30により識別され得る。トリックモードの使用後、DPIによる@minBufferTime/新たなバッファリング検出のために、クライアントは新たなリバッファリングを実行しなければならない。DPIとは、深層パケット検査(Deep Packet Inspection)を表している。これは、基地局スケジューラがIPパケットのコンテンツを調査し、そのような調査に基づいてスケジューラの決定を行うことを意味している。伝統的に、ISO-OSIモデルにより提案されているように、RRMはMACレイヤ上で動作し、IPレイヤを調査することはない。
【0072】
図5に関して詳細に説明された図3の実施形態の上述の構成に関し、注意すべき点として、その中で図3の実施形態を図5が具体化するような種々の態様は、図3に対して個別に置き換えられてもよいという点である。例えば、データトラフィックに対するTCPの使用や、管理部30、基地局32及びユーザーエンティティ34のそれぞれの機能を定義するためのLTEシステムの使用や、MPD46のコンテンツとサーバー42及びクライアント40の機能とを少なくとも部分的に定義するDASHストリーミングフレームワークなどについて、これがあてはまる。
【0073】
図3から図5に示す実施形態によれば、ビデオ資源管理部30は、図5内で「R」で示すように、個々のユーザーエンティティ及びそれらのクライアント40に対し、直接的にレート割り当てを指図しており、これはサーバー42からクライアント40へのデータトラフィック内のメディア・プレゼンテーション記述の評価に基づいて、基地局32の通信資源を各ユーザーエンティティへと割り当てるものである。以下に説明する実施形態によれば、資源管理部30のこの機能は任意である。
【0074】
図6は本発明の更なる実施形態に従う無線資源管理部を示す。上述したように、図3図6との中に共通する構成要素の機能及び相互接続に関しては、図3についての説明が図6にもあてはまる。つまり、無線資源管理部30は、ユーザーエンティティ34に対して、基地局32の通信資源を上述の通りに割り当てる。但し、メディア・プレゼンテーション記述46に対するこの割り当ての依存性が、この場合には任意である。更に、図6の実施形態によれば、無線資源管理部30は、クライアント40とサーバー42との間のデータトラフィックが無線資源管理部30を介して流れるように配置されており、その結果、無線資源管理部30がこのデータトラフィックに対して以下のような影響を与えることになる。
【0075】
特に図6の実施形態によれば、無線資源管理部30は、追加的に即ち図3に関して上述した機能に加えて、メディアコンテンツ44の異なる帯域幅の複数のバージョンを記述しているメディア・プレゼンテーション記述46を、サーバー42からユーザーエンティティ34において動作しているクライアント40へと流れるデータトラフィック内で検査し、同時に、メディアコンテンツ44の所望のバージョンを要求するメディア要求60であって、クライアント40からサーバー42へと送られるメディア要求60も検査するよう構成されている。これら両方の検査に基づいて、資源管理部30は、少なくとも要求60を送信したユーザーエンティティ34に関し、現在の資源状態を記述している情報に依存して、及び、ユーザーエンティティ34に対して送信されたメディア・プレゼンテーション記述に依存して、以下の事項を決定する。(1)サーバー42に対してメディア要求60を(無修正で)転送する。又は、その代わり(2)クライアント40に送信されるメディアコンテンツ44の所望のバージョンをメディア要求60がもたらさないようにする。例えば、無線資源管理部30は、(2)のような状態を次の2つの方法で引き起こしてもよい。(2a)修正済みのメディア要求がメディアコンテンツ44のより少ない帯域幅のバージョンを要求するように、メディア要求60を修正する。又は、(2b)メディア要求44をインターセプトし、利用不可の応答(non-availability response)をサーバー42からユーザーエンティティ34又はクライアント40へと返送するように、サーバー42に対してエミュレート又は指令する。代替的に、低い帯域幅についての応答がRRM30によって実行されてもよく、又は、クライアントに対してその要求を適性に変更するよう指令する任意の他のフィードバックがサーバーによって実行されてもよい。
【0076】
これは以下のことを意味する。即ち、図3について上述したように、無線資源管理部30は現在の資源状態情報に対するアクセスを有する。特に無線資源管理部30は、ユーザーエンティティ34に関してだけでなく、全てのユーザーエンティティに関して、この現在の資源状態情報に対するアクセスを有する。この情報に基づいて、無線資源管理部30は、基地局32の通信資源に課せられている現在の逼迫度を知り、またユーザーエンティティ34にとって利用可能な通信資源について知る。更に、無線資源管理部30は、メディア・プレゼンテーション記述46に対してもアクセスを有しかつそれを検査し、無線資源管理部30は、ユーザーエンティティ34側のクライアント40がダウンロードを求めるメディアコンテンツ44の代替的なバージョンについても知る。
【0077】
全体的な情報、即ち現在の資源状態の情報とメディア・プレゼンテーション記述46とに基づいて、無線資源管理部30は、基地局32が直面する現在の負荷が、サーバー42に対してメディア要求60を無修正バージョンで単に転送することを正当化できる程度に十分低いかどうかを決定することができる。しかしながら、現在の資源状態の情報とメディア・プレゼンテーション記述とに基づいて、無線資源管理部30が、メディアコンテンツ44の現在要求されているバージョンに必要な帯域幅の部分が他のユーザーエンティティから転送されるべきでないと決定した場合、例えば、残りの帯域幅が、他のユーザーエンティティのクライアントの要求するメディアコンテンツの最低の帯域幅のバージョンを彼らに供給するためには十分でない場合には、無線資源管理部30は、修正済みのメディア要求がより低い帯域幅のバージョンを要求するように、メディアメディア要求60を修正するよう決定する。従って、サーバー42は、この修正済みの要求に対し、より低い帯域幅バージョンをクライアント40へと送信することで応答し、それによってこのような場合の処理が可能となる訳であるが、その要求への応答は、実際にはより低い帯域幅バージョンに対する要求への応答と同じとなる。例えば、より低い帯域幅バージョンは、メディアコンテンツ44の元来所望されたバージョンと比べ、単に所定のメディアストリーム部分を省略した点だけが異なっており、そのような省略は、そのメディアコンテンツを再生する役割を担うユーザーエンティティ34側のメディア復号器に悪影響を与えることがない。つまり、より低い帯域幅バージョンは、スケーラブルなメディアコンテンツのより低い情報レベルであってもよく、又は、より低い帯域幅バージョンは、同じ符号化方式を使用して符号化された他のメディアファイルであってもよい。
【0078】
メディア要求60を修正する代わりに、サーバー42がメディア要求60をインターセプトしてサーバー42からクライアント40に対して利用不可の応答を返送するように、サーバー42に対してエミュレート又は指令することも可能である。どちらの場合でもクライアント40はサーバー42からの応答を受信し、その応答により、メディア・プレゼンテーション記述46内に示されたものであるが、所望のバージョンはサーバーにおいて利用可能でないことが分る。クライアント40はこの応答に対してどのように反応してもよいが、反応の1つの合理的な方法は、クライアント40が新たな要求を有する別の要求をサーバー42に対して新たに送信することを含んでもよい。その新たな要求とは、メディアコンテンツ44のより低い帯域幅バージョンをサーバー42から要求するものであり、これにより、上述したメディア要求を修正する場合の結果と同じ状況、即ちサーバー42がクライアント40に対してより低い帯域幅バージョンを返送する状況へと効率的に行き着くことになる。
【0079】
このように、上述した決定の選択肢(1)〜(2b)の間における無線資源管理部の決定の中に含まれ得る第1ステップは、メディアコンテンツ44のいずれかの利用可能なより低い帯域幅バージョンが存在するかどうかについてチェックすることである。このチェックは、メディア・プレゼンテーション記述46に基づいて実行される。第2ステップは、上述の選択肢(2a)〜(2b)が適切かどうかについて、現在の資源状態情報をチェックすることを含み得る。
【0080】
図6の実施形態の更なる拡張又は抽出を、以下に図7に関して説明する。図7は、ユーザーエンティティ34の一実施例を更に詳細に示す。以下に図7に関して説明する実施形態によれば、追加的な無線資源管理部の機能、即ちメディア要求60の転送、修正及び/又はインターセプトなどの処理に関係する機能が、無線資源管理部30から、サーバー42とクライアント40との間のデータトラフィックに沿って、ユーザーエンティティドメイン34へと置換されており、特にユーザーエンティティ伝送ステージ70とクライアント40との間のいずれかの場所に置かれている。しかしながら、これは単なる一例であって、このような機能はまた、他の場所に配置された別のエンティティによっても達成し得ることに留意すべきである。
【0081】
特に、図7に示すユーザーエンティティ34は、1つ又は複数のアンテナ72と、送受信ステージ70と、資源管理部74と、クライアント40と、メディア再生部76と、例えばディスプレイ78及び1つ又は複数のスピーカ80のようなユーザーに対してメディアを実際に提示するハードウエアと、を含む。これら全ての構成要素は、上述した順序で相互に直列接続されている。伝送ステージ70は、それぞれのデータ経路が、クライアント40により代表されるような後続又はより高いレイヤのアプリケーションに対してトランスペアレントとなるように、基地局32との通信を実行する役割を担う。送受信ステージ70は、例えば、OFDM(逆)多重化、時間分割(逆)多重化、基地局32への受信品質フィードバック、チャネル推定及びその他の、(逆)多重化を実行する。更に、送受信ステージ70は、それぞれのユーザーエンティティ34に割り当てられるべき帯域幅の増加を要求する、基地局32への要求を送信することができ、その場合、そのような要求の送信は、例えばクライアント40などの後続のモジュールのいずれかによってトリガーされる。送受信ステージ70は、ハードウエア又はハードウエアの組合せ、プログラム可能なハードウエア及び/又はソフトウエア、又はそれらの何らかの組合せの中で構成されてもよい。
【0082】
資源管理部74は、送受信ステージ70とクライアント40との間に接続されており、従って、上述した修正に関する無線資源管理部の機能を実行することができる。即ち、送受信ステージ70とアンテナ72とのそれぞれによって表わされた無線インターフェイスを介した、クライアント40からサーバー42へのメディア要求を転送及び/又はインターセプトする機能を実行できる。つまり、資源管理部74は、送受信ステージ70を介して現在の資源状態情報にアクセスできる。特に、送受信ステージ70は、資源管理部74に対し、無線資源管理部30(図6を参照)による各ユーザーエンティティに対する通信資源の現在の割り当てから結果的に得られる現在の利用可能な伝送レートについて、情報を与えることができる。更に、資源管理部74は、サーバー42からクライアント40へのデータトラフィック内のメディア・プレゼンテーション記述46を検査することができる。クライアント40からサーバー42へのメディア要求60を検査することにより、資源管理部74は、図6に関して説明した決定と同じ決定を実行することができる。即ち、メディア要求の転送に関する上述した決定選択肢の間での決定であり、又は代替的に、メディア要求を修正するか、或いはメディア要求をインターセプトするとともにサーバー42に対して利用不可の応答を返送するようエミュレート若しくは指令する決定である。当然ながら、資源管理部74は単に、無線資源管理部30と比較して現在の資源状態情報の適切な部分集合に対するアクセスを有するだけである。しかしながら、資源管理部74は、メディアコンテンツ44のバージョンであって、基地局32でのフルの資源状況を考慮した場合に、他のユーザーのサーバー基地局32に関して公平でない、又は、頻繁にストリーミング可能でないようなバージョンを、要求するクライアント40を忌避してもよい。
【0083】
図6図7の実施形態に関し、資源管理部30と74とは、それぞれ、(1)及び(2)、又は、(1)及び(3)の選択肢の間で、単に切り替えるよう構成されてもよい。更に、資源管理部74に関しては、この資源管理部が、現在の資源状態情報の一部として、無線資源管理部30によってユーザーエンティティ34へと送信された長期通信資源保証を利用するよう構成されてもよいことに留意されたい。
【0084】
このように、図6図7とは、メディアコンテンツ44の異なる帯域幅のバージョンを記述するメディア・プレゼンテーション記述46を、サーバー42からユーザーエンティティ34において動作しているクライアント40へのデータトラフィック内で検査し、また、メディアコンテンツ44の所望のバージョンを要求するクライアント40からサーバー42へのメディア要求60を検査し、更に、現在の資源状態情報とメディア・プレゼンテーション記述46とに依存して、(1)メディア要求60をサーバーへと転送するか、又はそれに代えて(2)修正済みのメディア要求がメディアコンテンツ44のより少ない帯域幅のバージョンを要求するように、メディア要求60を修正するか、又は、メディア要求60をインターセプトして、利用不可の応答をサーバー42からクライアント40へと返送するように、サーバー42に対してエミュレート又は指令することを決定する、資源管理部を開示している。
【0085】
図3図5に関して説明した実施形態と類似して、以下に図6図7の実施形態の可能な構成について説明する。つまり、これら可能な実施形態は、無線通信システムがLTEシステムであり、メディアコンテンツのストリーミングがDASHを使用すると想定している。図3との関連における図5の説明方法と同様に、図8は先に使用された参照符号を再使用し、従って、図6及び図7の構成要素の機能についての説明は、図8内で同じ参照符号を有する構成要素に対しても同様に適用されるべきである。
【0086】
DASHとの組合せにおいて、LTE RRM30は、接続された全てのUEによって要求されたMPD46を検査することができる。所与のUEが良好な無線チャネルを有しており、高い帯域幅の要求60を発信する場合、LTE RRM30は、所謂ステータスコード注入(injection)と呼ばれるステータスコード・トリガーを送信することができ、その結果、HTTP DASHサーバー42がW3CのHTTPステータスコード80を送信して、この帯域幅が利用不可であることを示すことができる。可能性のあるW3C HTTPステータスコードを後段でリスト掲載する。このように、LTE RRM30は、UE34に直接的に信号伝達することなく、UE34に対してより低いデータレートを要求するよう強制することができる。これにより、信号伝達のために使用される資源を節約でき、その代わりにそれら資源がデータ用に使用可能となる。例えば、これらの資源は他のUE34のためにスケジューリングされ得る。UEのTCP/IPサービスは、割り当てられたレートに対しeNB RRMアルゴリズムによって自動的に適応するが、そのアルゴリズムはMPD@bandwidth tagから引き出すことができる。
【0087】
eNB RRMユニット30は、あるUE34によって要求されたMPD46を検査する。加えて、ユニット30は、図8に図示しない移動性管理エンティティ(MME)から情報を引き出してもよい。ユーザープロファイル、例えば移動速度、ハンドオーバー統計及び所望のMPDに基づいて、RRMエンティティ30は、W3C HTTPステータスコードを介する間接的な信号伝達80を用いて、より高い又は低いビデオ品質を強制することができる(例えばhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlを参照されたい)。
【0088】
図8に関する上述の説明においては、サーバー42において利用可能なメディアコンテンツ44のバージョンが別々に利用可能であること、即ち、異なる情報コンテンツにおいては非スケーラブルなバージョンであることが想定されていた。しかし、上述の図8の説明は、他の場合に対しても容易に当てはめることができる。即ち、メディアコンテンツ44の利用可能な様々な帯域幅のバージョンが1つのメディアストリームの形態で利用可能となっており、そのメディアストリームがSVC又はMVCストリームなどのスケーラブルな方法で符号化されている場合である。この場合には、図8の無線資源管理部30の動作のモードは以下のように記述されてもよい。
【0089】
LTE RRMエンティティ30は、特定のユーザーによって要求されたMPD46をディープ・パケット・インスペクション50を使用して検査する。利用可能な無線資源に依存して、LTEスケジューラ30は、所与のユーザーによって要求された帯域幅の量を評価する。その要求された帯域幅が、所与のSVC又はMVCレイヤにとって利用可能な帯域幅を超える場合には、LTE RRMエンティティ30は、そのユーザー40に対してW3C HTTPステータスコードを送信するように、HTTP DASHサーバー42をトリガーすることができる。DASHクライアント40内のSVC/MVC復号器70は、そのエラー・ステータスコードを受信して、より少ない帯域幅を必要とするより低いSVC又はMVCレイヤを自動的に要求し、結果的にLTEシステム上の無線資源を節約する。
【0090】
所与のユーザーの劣悪なチャネル品質、又は資源を要求している他のユーザーの総数に起因して、無線資源は制限されることがあり得る。LTE RRM30は、良好なチャネル品質を有するユーザーに対し資源を提供してもらうよう強制し、その資源を、低いチャネル品質で我慢しているユーザーに対して割り当てることができる。
【0091】
LTE RRM30内の優先順位ポリシーに依存しながら、RRM30はMPD46を使用して、W3C HTTPステータスコード80をトリガーすることにより、より高位のSVC/MVCレイヤのHTTP要求を許可する前に、最下位のSVC/MVCレイヤ、即ちベースレイヤをサービス配信することを保証することができる。
【0092】
HTTP DASHサーバー42は、以下のW3C HTTPステータスコードの内の1つを送信してもよい。
・404 Not Found (発見されない)
・466 Streaming Rate Exceeded (tbs. in RFC) (ストリーミングレート超過)(RFC内のtbs)
・503 Service Unavailable (サービス利用不可)
・509 Bandwidth Limit Exceeded (帯域幅限度超過)
【0093】
本願の次の実施形態を説明する前に挙げるべき注意点は、図7に示すユーザーエンティティ34の全体的な構造は、一般的に、資源管理部74を除けば他の全ての実施形態に対しても適用可能であることである。メディア再生部76は、サーバー42から受信されたメディアコンテンツ44を復号化できるメディア復号器であってもよい。クライアント40とメディア再生部76とは、相互接続されて、相互に通信可能であってもよい。メディア再生部は、クライアント40内に部分的に統合されることさえ可能である。
【0094】
図3図5の実施形態によれば、個々のユーザーエンティティに割り当てられた通信資源、特に、割り当てそのものがメディア・プレゼンテーション記述の検査結果に依存して適応されていた。その後に示した図6図8の実施形態によれば、クライアントとサーバーとの間のデータトラフィックの一部分であって、クライアントからサーバーへと送信されたメディア要求に関連する部分は、基地局の通信資源のより効率的な活用を行うため、又は基地局の通信資源のユーザーエンティティに対するより公平な配分を得るために、何らかの影響を受けている。両方の実施形態によれば、無線資源管理部30はまた、以下に説明する構成例に従い、物理レイヤ上のLTE閉ループフィードバックも考慮することができる。つまり、以下に示す構成可能な例は図5図8とに示す構成例を更に詳細に説明することを意図している。つまり、本発明の構成可能な例によれば、無線資源管理部(RRM)スケジューラ30は、LTEの物理レイヤからのLTE閉ループフィードバックを考慮して、LTE EMB32において、DASHクライアントに対してどのビデオ表現又はメディアコンテンツ44のバージョンが最も適しているかを決定する。また、図3に示す実施形態と図5に示す構成によれば、資源管理部30は、それぞれの表現が提供されているそれぞれのクライアント40に対して通信資源を適切に割り当てることにより、最も適切な表現又はバージョンのダウンロードを間接的に取得したいと試みている。他方、図6に示す実施形態と図8に示す構成によれば、無線資源管理部30は、上述したような方法でクライアントのメディア要求に対して適切な影響を与えることにより、クライアントによる最適な表現のダウンロードを達成しようと試みている。
【0095】
RRMユニット30は、(H264/)SVCレイヤのメディアコンテンツ44のAVCセグメントの異なる表現の間で選択を行う場合や、(H264/)MVCにおいて2D又は3Dのビデオ配信を行うかを決定する場合に、例えばLTE閉ループフィードバックを考慮に入れる。LTE eNBのRRM30がMPD46を検査することで、図3及び図5の場合には、特別なビデオセグメントに対して特定されたパラメータへとRRMパラメータを調整してもよく、図6及び図8の場合には、HTTPゲット要求に対して影響を与えてもよい。
【0096】
UE40は、所謂チャネル品質フィードバック(CQI)と呼ばれる無線チャネルの品質尺度と、(表3に示すような)ビデオバッファのバッファレベルとを、eNBのRRMエンティティ30に対して信号伝達してもよい。周期的又は非周期的な時間ベースで、ピーク対平均値比(PAR)、例えばピーク対平均レート比(PARR)のインジケータを送信することで、フィードバック情報を削減させてもよい。この情報によって、eNBのRRMエンティティ30は、HTTPストリーミング・サービスに関するバッファ認識を有する状態で、多数ユーザーのスケジューリングを実行できる。
【0097】
PAR及び/又はPARRの計算に使用されるべき物理レイヤ(PHY)データのチャネル品質尺度は、LTE標準内で定義された以下のパラメータの1つ又は任意の組合せを含んでもよい。
・CQI:チャネル品質インジケータ(Channel Quality Indication)
・RI:ランクインジケータ(Rank Indicator)
・PHYレイヤデータレート(PHY layer data rate)
・PHYレイヤ遅延及びジッター(PHY layer delay and jitter)
・RSRP:参照信号受信パワー(Reference Signal Received Power)
・RSSI:受信信号強度インジケータ(Received Signal Strength Indicator)
・RSRQ:参照信号受信品質(Reference Signal Receive Quality)
【0098】
ここで、RSRQは次式により定義される。
【0099】
RSRQ=N×RSRP/RSSI
ここで、NはRSSI値が測定された資源ブロックの数である。
【0100】
上述した構成の詳細から明らかなように、図3図6との無線資源管理部30は、クライアントのユーザーエンティティから基地局に対してそれぞれ送信された物理レイヤ上の閉ループフィードバックを利用することができる。つまり、送信者側のシステムは、クロスレイヤ情報に基づいてビデオ送信を向上させることができるが、他方、受信者側は、クロスレイヤ・インターフェイスを何も必要としないことになる。更に、RRMは、チャネルに基づいて、1つ又は複数のクライアントに対して、そのビデオ品質を向上させるために、更にどれだけ大きい帯域幅を割り当てることができるかを推定できる。
【0101】
例えば、図3図6とに示すRRM30は、ユーザーエンティティに割り当てられる平均帯域幅を決定し、更に、その決定された平均帯域幅から、各クライアント44によって、メディアコンテンツ44のメディア・プレゼンテーション記述46の内のどのバージョンが現在ダウンロードされているかについて予測するよう構成されてもよい。これにより、クライアントの状態を発見する簡素な方法が形成できる。各クライアントについて、RRM30は単に、各クライアント40が受信している平均帯域幅を識別し、更にその結果から、どのメディアレートをそれが選択し得たかを予測するだけでよい。
【0102】
更に、上述したように、無線資源管理部30が、メディアバッファリング状態情報、即ちそれぞれのユーザーエンティティにおいて動作しているクライアントのバッファリング状態を示す情報を導出するよう試みることも可能である。換言すれば、無線資源管理部30は、ユーザーエンティティ34の受信状態に関する情報を利用して、それぞれのユーザーエンティティが、効果的かつ正確に、割り当てられた帯域幅を実際に受信することができるかどうかという点について確認することができる。この情報を使用して、無線資源管理部30は、最小帯域幅情報を考慮することでユーザーエンティティにおいて動作しているクライアントのバッファリング状態をエミュレートでき、その最小帯域幅情報は、上述したように無線資源管理部30にとってはメディア・プレゼンテーション記述46からアクセス可能である。このような方法で、無線資源管理部30は、ユーザーエンティティ34上で実行しているクライアント40のバッファリング状態をエミュレート又はシミュレートすることができ、更に、そこからクライアントの挙動やクライアントの優先度を推論することができる。例えば、シミュレーションの結果、バッファがメディアデータ不足であることが分かるクライアント40に対しては、シミュレーションの結果、バッファがフルであることが分かるクライアント40よりも、高い優先度が与えられてもよい。
【0103】
当然ながら、上述したようにバッファリング状態をシミュレートする可能性、又はクライアント40とそれぞれのサーバーとの間のデータトラフィックからメディアバッファリング状態情報を導出する可能性は、演算的にはかなり複雑であり、得られる正確さは低くなり得る。
【0104】
このように、図3の実施形態は拡張可能であってもよく、その方法は、無線資源管理部30がまた、(現在の資源状態情報に加えて)メディア・プレゼンテーション記述46に依存するだけでなく、それぞれ1つ又は複数のクライアント40が動作している各ユーザーエンティティからのチャネル品質フィードバックから導出されるメディアバッファリング状態情報にも依存して、基地局32の通信資源をユーザーエンティティに対して割り当てるよう構成されてもよい。特に、導出されたメディアバッファリング状態情報は、各ユーザーエンティティ34の推定された有効ビットレートを使用して満たされかつメディア・プレゼンテーション記述46内に示されたプレゼンテーション帯域幅においてエンターされた各ユーザーエンティティクライアント40のバッファをシミュレートする、上述のようなシミュレーションによって導出されたものであってもよい。
【0105】
勿論、図6の無線資源管理部30についても同様のことが言える。つまり、ユーザーエンティティクライアント40のメディア要求の影響に関する決定を行うために、シミュレーションの結果が無線資源管理部30によって使用されてもよい。
【0106】
更に、図7の実施形態もまた上述の意味で拡張されてもよい。つまり、図7の資源管理部74は、現在の資源状態情報を使用して、クライアントのメディアバッファ状態をシミュレートし、その結果に応じて、無線通信コミュニティの一部として、2つの貪欲なクライアント40から基地局通信資源を保護するよう行動してもよい。
【0107】
しかし、上述したように、クライアントのバッファリング状態の「シミュレーション」は高い不確実性を有する項目である。従って、図3図6との実施形態に修正を加え、無線資源管理部30は、ユーザーエンティティクライアントのバッファリング状態を導出又はシミュレートする必要がなく、その代わり、クライアント40からのデータトラフィック内の明示的なメディアバッファリング状態情報を利用するようにしてもよい。クライアント40からサーバー42へのデータトラフィック内のメディア・プレゼンテーション記述46とメディアバッファリング状態情報とに基づいて、無線資源管理部30は、さらに正確なバッファリング状態推定に基づくさらに正確な通信資源割り当てを実行することもできる。クライアント40からのデータトラフィック内のメディアバッファリング状態情報において、後者は、現在のメディアバッファリング状態、即ち現在のメディアバッファの充満レベル(fill level)を明示的に示してもよい。具体的な構成の可能性については、以下に更に詳細に説明する。
【0108】
一方で、別の実施形態に従えば、図3の無線資源管理部30は、クライアント40からのデータトラフィック内のメディアバッファリング状態情報には依存するが、メディア・プレゼンテーション記述46には依存しないで、ユーザーエンティティに対する基地局32の通信資源の割り当てを実行してもよい。複数のユーザーエンティティクライアント40のメディアバッファリング状態を単に調査するだけで、無線資源管理部30が、ユーザーエンティティに対する利用可能な基地局通信資源のより公平な分配を実行できるようにすることも可能である。
【0109】
このように、図3は、ユーザーエンティティの内の1つにおいて動作しているクライアントのメディアバッファリング状態情報に依存して、ユーザーエンティティ34に対して基地局32の通信資源を割り当てるよう構成された無線資源管理部30に関連していてもよい。ユーザーエンティティに対する通信資源の割り当ては、基地局(32)の通信資源が適切な割合で割り当てられるべきユーザーエンティティ34の数や、ユーザーエンティティと基地局との間で交換されるべき通信データの種類などのような、上述した可能性の1つ又は複数に基づいて実行されてもよい。更に、ユーザーエンティティへの通信資源の割り当てに際し、上述した設定はメディアバッファリング状態情報、即ちサブキャリア、時間スロット、及び基地局セルの空間的カバー範囲の内の1つ又は複数に基づいて調整され得る。上述したように、メディアバッファリング状態情報は、クライアント40からサーバー42へのデータトラフィック内における明示的な信号伝達から抽出されることもでき、又は、ユーザーエンティティ34から基地局32へのチャネル品質フィードバックに基づいて、ユーザーエンティティのバッファリング状態をシミュレートすることで導出されてもよい。
【0110】
このようにシミュレートする可能性はまた、図6及び図7の実施形態にも関連する。即ち、現在の資源状態情報とメディア・プレゼンテーション記述46とを使用する代わりに、図6図8の無線資源管理部30と資源管理部74とは、それぞれ、クライアント40からのデータトラフィック内のメディアバッファリング状態情報に依存して、メディア要求60の取り扱い方法に関する決定を実行するよう構成されてもよい。
【0111】
従って上述した実施形態は、次のような資源管理部を開示していると言える。即ち、サーバー42からユーザーエンティティ34において動作しているクライアント40へのデータトラフィック内で、メディアコンテンツ44の様々な帯域幅のバージョンを記述しているメディア・プレゼンテーション記述46を検査し、メディアコンテンツ44の所望のバージョンを要求しているクライアント40からサーバー42へのメディア要求60を検査し、クライアント40からメディアバッファリング状態情報を受信し、更に、そのメディアバッファリング状態情報とメディア・プレゼンテーション記述46とに依存して以下の事項を決定する。(1)メディア要求60をサーバーへと転送する。又は代替的に(2)修正済みのメディア要求がメディアコンテンツ44のより少ない帯域幅のバージョンを要求するように、メディア要求60を修正するか、若しくは、メディア要求60をインターセプトし、利用不可の応答をサーバー42からクライアント40へと返送するように、サーバー42に対してエミュレート又は指令する。
【0112】
図3図6及び図7の代替的な説明として、上述された実施形態に関する可能な構成を以下に説明する。この更に詳細な構成は、「オーバー・ザ・トップ(OTT)閉ループフィードバックを用いるLTEを介したDASH」と呼ばれてもよい。このような構成の可能性に従えば、クライアントのBufferLevelは、オーバー・ザ・トップの直接的なクライアントフィードバック、例えば表3に定義されるBufferLevelのような品質尺度を使用するLTEシステムのDPIスケジューラ30において、より詳細に追跡される。
【0113】
【表3】
【0114】
結果として得られる可能性のある構成を図9に示す。図9の構成を図5の構成の可能性と比較すると、図5の構成がユーザーエンティティ34からRRM30へのLTEフィードバック90によって拡張されていることが明らかである。ここで、後者、即ちRRM30は、LTEフィードバック、即ちユーザーエンティティ34からのチャネル品質フィードバックを使用して、より良好な通信資源レート割り当てRを実行する。
【0115】
以下に、上述の実施形態に関し、この実施形態のクライアント40についての幾つかの構成の詳細を説明する。上述したように、クライアントの挙動はそれぞれのクライアントイシュアによって自由に設定され得るものであり、上述した実施形態では、クライアントの挙動の説明に関して多くを語ってこなかった。しかし、上述の実施形態の完全な理解を促進するために、可能性のあるクライアントの挙動をクライアントがDASHクライアントであると仮定して、以下に説明する。
【0116】
DASHは、「ISO/IEC 23009−1」に定義されているように、クライアント主導の適応技術であり、一方ではクライアントの挙動を特定せず、様々な構成に対する完全な自由度を認めている。しかしながら、クライアントによって報告されるMPDとQMとは、そこからクライアントの挙動を予測できるような幾つかの重要な情報を含む。この重要な情報は、以下のような信号伝達を含む。
・@minBufferTime
・@bandwidth
・十分なデータが利用可能である場合には、TCPスループットとしてクライアントにより測定可能な、割り当てられたLTEクライアントレートを暗示する。
・意図されたプレイアウト遅延/潜在的な停止(outages)に依存して、クライアントがTCPスループットに適応する。
・クライアントによって報告されたQM
・ビットストリーム切り替えフラグ
【0117】
DASHクライアントの目的は、ストリーミングされるコンテンツを、その機器の特徴に基づいてサポート可能な最高の品質で連続的に再生することである。連続的に再生するためには、クライアント側にあるバッファは、いかなる場合でも空になってはならない。MPD内の@minBufferTimeは、クライアントに対し次のような約束をする。即ち、セッションの開始時に所定量のデータがクライアントのバッファに蓄積された場合、少なくとも@bandwidth内で示された値のような高いレートでクライアントがダウンロードするときには、クライアントは@bandwidthを有するよう信号伝達されたビデオバージョンを再生できるという約束である。従って、クライアントは、ビデオの再生を開始する前に少なくとも所定量のデータをプリバッファすることが期待されており、更に、クライアントのバッファ充満度における変化が、@minBufferTimeと比較したバッファ充満度の大きさに基づいて発生した場合には、異なる@bandwidthを有するビデオの異なるバージョンへと切り替えるよう期待されている。クライアントのバッファ充満度は基地局にとって未知であり、例えばトリックモードが使用されているときにはそれを推定することが困難又は不正確となる可能性があるため、ユーザーからのQM報告(特に上述したQM)がユーザー挙動を予測する上で有益なツールとなり得る。
【0118】
更に、DASHクライアントは、図10に示すように2つの構成要素へとロジカリーに分割される。即ち、図7に示したようなDASHアクセスクライアント40aとMPEGメディアエンジン40bとの2つである。
・DASHアクセスクライアント40a:このエンティティは、MPD46を解析し、スケジューリング・アルゴリズムを実行し、更に、フォーマット92においてメディア64をMPEGメディアエンジン40bへと受け渡す役割を担う。
・MPEGメディアエンジン40b:このエンティティは、メディアデータ92を処理する役割、即ち復号化、再構築その他を担う。
【0119】
上述した図7の説明を参照すれば、ユーザーエンティティ及び/又はクライアントの上述した好都合な機能のいずれかを利用する、強化されたDASHクライアントを構成するための、以下に記載する2つの可能な選択肢が存在することが分る。
・クロスレイヤDASHアクセスクライアントを有する。このクロスレイヤ・アクセスクライアントは、物理レイヤから測定値を取得し、更なる可能性として、LTEネットワークからの追加的な信号伝達を受け取る場合もある。この追加的な情報を使用して、チャネルの更に良好な推定と強化された適応スケジューリングとが実行され得る。
・しかし、典型的には、既に実装されたDASHクライアントが想定され、その場合、例えばブラウザ内でDASHクライアントを実装する場合などのように、例えばクライアントバッファレベル又は所与の量のデータ内でダウンロードするために必要とされる時間などを監視することにより、より高度なレイヤで適応が発生する。この場合、1つの可能性は、その適応を管理する外部の「メディア管理部」要素(図8及び図9を参照)を持つことである。しかし、上述した管理部と同様に、DASHクライアントはこの点を認識しないであろう。このような「重複した」DASHアクセスクライアント(即ちDASHアクセスクライアントもまた適応を実行すること)を回避するために、追加的な信号伝達がMPDレベルにおいて必要となる。即ち、例えば@automaticSwitchingなどのように、DASHアクセスクライアントに対し、DASHクライアントの外、即ち受信装置内で「資源管理部」74によって適応が実行されることを示す新たな属性が追加されてもよい。途中にあるサーバー又は何らかの装置がビデオのプロファイルに合わせてビデオレートを調整し、選択され且つ要求された表現に従ってレベルを調整する可能性があり、結果的にクライアントはいかなるメディアレート調整もすべきでないことをMPD内に含まれる@automaticSwitchingがクライアントに対して報せる。
【0120】
第2の場合、即ち「資源管理部」を有する場合を図11に示す。図11から分かるように、資源管理部74は、上述のような資源管理部として動作するために、クライアント/サーバー・データトラフィックよりも低位のOSIレイヤにおいてデータ100を使用する。
【0121】
特に資源管理部74は、メディアの適応及び要求を実行するか、又は、DPIも更に実行するか若しくはユーザーの要求を修正することなどが可能である。更に「メディア管理部」は、より高位のレイヤの情報だけが使用される通常のDASHクライアントにおいて行われ得たであろう適応よりも高度な適応を実行するために、物理レイヤ情報及び資源割り当てについてRRMと幾つかの追加的な信号メッセージを交換することもできる。
【0122】
図6図7の実施形態、及びそれらに対応する図8などの構成に関して留意すべきことは、これらの図に記載された実施形態は別の方法で実現されてもよく、その結果としてもたらされる代替的な実施形態に従えば、より良好な資源管理を行うために、メディア要求の影響がメディア記述プレゼンテーションの影響によって置換されてもよい。しかしながら、これらの図に関する上述の機能と以下に記載する機能との組み合せも使用可能である。
【0123】
特に上述した図6の代替的な実施形態によれば、無線資源管理部30は、ユーザーエンティティ34において動作しているクライアントからサーバー42へのメディア・プレゼンテーション記述要求を検査するよう構成されており、そのメディア・プレゼンテーション記述要求は、サーバー42からメディア・プレゼンテーション記述46を要求するものである。資源管理部30は、次に、サーバー42からクライアント40へのデータトラフィック内のメディア・プレゼンテーション記述46を検査して、現在の資源状態情報とメディア・プレゼンテーション記述46とに基づき、以下の選択肢の中のいずれを使用すべきかを決定する。(1)メディア・プレゼンテーション記述要求への回答として、メディア・プレゼンテーション記述46をクライアント40に転送する。即ち、メディア・プレゼンテーション記述46を無修正のままにする。又は、(2)メディア・プレゼンテーション記述46をインターセプトし、メディアコンテンツ44の様々な帯域幅のバージョンの適切な部分集合だけを記述するようにメディア・プレゼンテーション記述46を削減し、メディア・プレゼンテーション記述要求への回答として、その削減されたメディア・プレゼンテーション記述46をクライアント40へと送信する。ここでも、無線資源管理部30はクライアント40に対し、メディアコンテンツの要求されたバージョンをそのより低い帯域幅バージョンへと変更するよう直接的に指令することはないが、しかし、クライアント40が、メディアコンテンツ44に対する更なるメディア要求を変更して、メディア・プレゼンテーション記述46の削減に応じたより低い帯域幅バージョンを参照するようになることが十分予想される。
【0124】
ここで再度確認するが、上述した機能は、ユーザーエンティティから見て基地局の向こう側にある無線資源管理部30のために利用可能であるだけではなく、ユーザーエンティティ自身の内部にある図7の資源管理部74のためにも利用可能である。図7に関して上述した可能な構成の詳細はまた、図6図7とで示した上述の代替的実施形態のそれぞれに対しても適用可能である。
【0125】
図6図7とはまた、資源管理部を開示しており、その資源管理部は、ユーザーエンティティ34において動作しているクライアント40からサーバー42へのメディア・プレゼンテーション記述要求を検査するよう構成されており、そのメディア・プレゼンテーション記述要求は、サーバー42からメディア・プレゼンテーション記述46を要求するものであり、メディア・プレゼンテーション記述46はメディアコンテンツ44の異なる帯域幅を持つ複数のバージョンを記述するものである。資源管理部は次に、サーバー42からクライアント40へのデータトラフィック内のメディア・プレゼンテーション記述46を検査して、現在の資源状態情報とメディア・プレゼンテーション記述46とに基づき、以下の選択肢の中のいずれを使用すべきかを決定するよう構成されている。即ち、(1)メディア・プレゼンテーション記述要求への回答として、メディア・プレゼンテーション記述46をクライアント40に転送する。又は、(2)メディア・プレゼンテーション記述46をインターセプトし、それを修正する。
【0126】
例えば、上述のインターセプトと修正とは、メディアコンテンツ44の異なる帯域幅からなる複数のバージョンの適切な部分集合だけを記述するように、メディア・プレゼンテーション記述46を削減し、メディア・プレゼンテーション記述要求への回答としてその削減されたメディア・プレゼンテーション記述をクライアント40へと送信する、資源管理部を含んでも良い。また、MPD46に対し、クライアント40へのフィードバックとして使用されるべき情報を追加することも可能である。すなわち、例えば以下に説明する明示的なバッファ状態情報などの品質尺度をサーバー32の代わりにRRM30へと送信するようクライアント40に指令するため、又は以下に詳細に説明するようにユニキャストからマルチキャストへのプロトコルの変更を指示するため、又は、中間にある資源管理部自身がクライアント40によって要求されたメディア44の調整を実行する可能性があり、クライアント40はレートを調整すべきでないことをクライアント40に対して報せるため、などである。当然ながら、プロトコル変更の指示は、指示されたプロトコル変更に対応するプロトコル変換(protocol translation)をRRM30が実行するか、又はサーバー32など別の構成要素に実行させることによって、実現されてもよい。
【0127】
メディア要求に影響を与える場合として、資源管理部は、メディア・プレゼンテーション記述46の中で、メディアコンテンツ44の所望のバージョンとして関連するより低い最小帯域幅を持つメディアコンテンツ44のバージョンを識別するために、メディア・プレゼンテーション記述46を検査してもよく、より低い最小帯域幅が関連付けられたバージョンが存在する場合には、資源管理部は現在の資源状態情報に依存して前記決定を実行する。資源管理部は、無線資源管理部であってもよく、更に、クライアントが動作しているユーザーエンティティを含む複数のユーザーエンティティに対する基地局の通信資源の割り当てを実行してもよい。しかしながら、資源管理部は代替的に、ユーザーエンティティ内におけるその送受信ステージ70とクライアント40との間に配置されてもよく、その場合、資源管理部は現在の資源状態情報を送受信ステージ70から取得してもよい。更に、資源管理部は、現在の資源状態情報に含まれるユーザーエンティティから基地局へのチャネル品質フィードバックに基づいて、ユーザーエンティティのバッファリング状態をシミュレートしてもよく、かつユーザーエンティティのバッファリング状態に依存して前記決定を実行してもよい。
【0128】
次に、上述した実施形態に関する可能な構成について詳細に説明するが、これらの詳細は、DASHプッシュサービスの形態を持つメディアデータのストリーミングを実現させる可能性に関するものである。
【0129】
LTEを介するDASHサービスは、所謂プッシュサービスによって強化されることができる。例えば図12を参照されたい。可能性のある2つの手法が存在する。
1.HTTPサーバー・プッシュ(Server Push)
・DASHクライアント46はHTTPサーバー42に接続し、サーバー42はTCP/サービス・ハンドシェーク及びトンネル・セットアップを実行する。
・サーバー42は、次にDASHクライアント40に対してビデオデータをプッシュする。
2.LTEプロキシ・プッシュ(Proxy Push)
・DASHクライアント40は、TCP/サービス・ハンドシェーク及びトンネル・セットアップを実行するLTE eNB内のLTEプロキシサーバーに接続する。
・LTE RRMエンティティ30は、HTTPゲットを使用して、HTTPサーバー42からビデオデータ表現をリトリーブする。
・LTE RRM30は、DASHクライアント12に対してビデオデータをプッシュする。
【0130】
プッシュ情報は、プッシュ表現を照会するものであり、MPD内で特定されてもよい。SVC又はMVCの場合には、この情報はDASHクライアントに対してプッシュされるべきレイヤを含んでもよい。ここで、MPD46は、無線資源の使用が他のユーザーに対しても最適化されるように、eNB RRM30に対し、潜在的なレート切換えについて情報を与える。例えばLTEプロキシ・プッシュの場合、LTE RRM30は、他のユーザーのために資源を節約する目的で、より低い品質とより低いレート要件を有するサービスをプッシュすることを決定することができる。
【0131】
換言すれば、基地局は、上述した全ての実施形態において、プロキシ・プッシュ処理を実行するためのサイトとしての役割を担うことができる。更に正確には、無線資源管理部もそのようなサイトとしての役割を担うことができる。
【0132】
図6の実施形態の更なる代替的な説明を試みる。ここで、以下の代替的な説明においては、次の点を理解すべきである。即ち、以下に説明する無線資源管理部の機能は、無線資源管理部30がクライアントとサーバーとの間のデータトラフィックに影響を与えるという、上述した無線資源管理部の空間的機能を置換するものでもよく、又は、無線資源管理部30の追加的な機能を表すものでもよいという点である。
【0133】
いずれの場合でも、以下に説明する実施形態によれば、図6の無線資源管理部30は、ユーザーエンティティ34に対して基地局32の通信資源を割り当てるほかに、複数のユーザーエンティティ34において動作しているクライアント40と1つ又は複数のサーバー42との間のデータトラフィックを調査するよう構成され、その目的は、そのデータトラフィック内に共通のメディアコンテンツに関連するメディア・プレゼンテーション記述46が存在するか否かについてチェックするためである。次に、そのチェックに基づいて無線資源管理部は以下の決定を下す。即ち、(1)クライアント40に対し、メディアコンテンツ44のユニキャストバージョンのほかに、共通のメディアコンテンツのマルチキャストバージョンを提供する。又は、(2)共通のメディアコンテンツ44をダウンロードしているクライアント40に対し、ユニキャスト・プロトコルからマルチキャスト・プロトコルへのプロトコル変更を起こさせる。
【0134】
しかし、上述した機能はまた、基地局の通信資源をユーザーエンティティに割り当てる役割を担う図6の無線資源管理部30から見て外部の又は分離された無線資源管理部の中で実行されてもよい。クライアントとサーバーとの間のデータトラフィックの調査と、クライアントの中の2つ以上によってそれぞれのメディア・プレゼンテーション記述要求を介して共通して注文されたメディア・プレゼンテーション記述があるか否かについてのチェックとは、割り当て処理から独立して実行されてもよい。それぞれのクライアント40が受信するバージョンをユニキャストバージョンから同一コンテンツのマルチキャストバージョンへと切り替えることの結果を考慮すると、結果的に得られる利点は容易に理解できるものである。このようなクライアントのために必要なビットレートが単に1つのストリーミングへと縮約され得るという事実から、上述の切り替えにより、他のクライアントのためにより多くの利用可能なビットレートがもたらされることが分る。
【0135】
上段では選択肢(1)と(2)とを挙げたが、言うまでもなく、本発明に係る無線資源管理部が選択肢の両方を実行するよう実際に構成されている又は実行可能である、と理解されるべきではない。むしろ無線資源管理部は、チェックの結果に基づいて、(1)又は(2)のいずれの選択肢がトリガーされるべきであるか否かを決定する。更に詳細には、1つ又は複数のサーバーから複数のクライアントの内の異なる各クライアントへのデータトラフィック内に共通のメディアコンテンツ44に関連するメディア・プレゼンテーション記述がない場合には、無線資源管理部は、クライアント40とサーバー42との間のデータトラフィックを無変更のままにおいておく。この場合、無線資源管理部は選択肢(1)も選択肢(2)も実行しない。更に詳細には、データトラフィックのいずれかを操作することが多くのビットレート節約につながらない場合には、無線資源管理部は、それぞれのデータトラフィックを無変更のままにおいておく。しかし、複数のユーザーが、サッカーの試合又は何らかの他のライブニュースなどのようなライブストリーミングにそれぞれ切り替えるよう決定する場合を想像されたい。この場合、これら全てのクライアントに対するユニキャスト・ストリーミングからマルチキャスト・ストリーミングへと切り替え可能であることは望ましいと考えられる。第1の選択肢に従えば、データトラフィック内で重複したメディア・プレゼンテーション記述が現れている場合には、メディアライブストリーミングに関する1つのメディア・プレゼンテーション記述を各メディア・プレゼンテーション記述要求を介して要求した複数のクライアント40に対して、無線資源管理部がメディア・プレゼンテーション記述を操作するよう構成されている。その修正により、元来のメディア・プレゼンテーション記述は、メディアコンテンツ44のユニキャストバージョンが利用可能であることの他に、又はその代わりに、マルチキャストバージョンだけが利用可能となるように変更される。従って、少なくともこれらの新たに加入してきたクライアント40は、マルチキャストバージョンを考慮するか、又は考慮せざるを得ないであろう。第2の選択肢に従えば、データトラフィック内で重複するメディア・プレゼンテーション記述が現れている場合、無線資源管理部30は、例えば共通のメディアコンテンツ44を要求しているクライアントからのそれぞれのメディア要求を変化させて、ユニキャストバージョンの要求からマルチキャストバージョンの要求へと変更させるよう構成されてもよい。他の代替的な修正方法もまた可能である。
【0136】
図6はまた無線資源管理部を開示しており、その無線資源管理部は、複数のユーザーエンティティ34において動作している複数のクライアント40と1つ又は複数のサーバー32との間のデータトラフィックを検査し、その1つ又は複数のサーバー32から複数のクライアント40の内の異なるクライアントへのデータトラフィック内に、共通のメディアコンテンツ44に関連しているメディア・プレゼンテーション記述が存在するか否かをチェックし、更に無線資源管理部は、そのチェックに基づいて、複数のクライアント40に対し共通のメディアコンテンツ44のマルチキャストバージョンをそのメディアコンテンツ44のユニキャストバージョンとは別に提供するか、又は、無線資源管理部は、そのチェックに基づいて、共通のメディアコンテンツをダウンロードしつつある複数のクライアント40に対しユニキャスト・プロトコルからマルチキャスト・プロトコルへのプロトコルの変更を行わせる。この無線資源管理部はまた、ユーザーエンティティ34に対する基地局32の通信資源の割り当ての役割を担うことも可能である。上述した実施形態は、他のいずれの実施形態と組み合わせることもできる。
【0137】
上述した実施形態の更に具体的な構成を以下に説明する。この具体的な構成によれば、DASHのユニキャストとブロードキャスト/マルチキャストとの切り替えが実現される。上述したように、このような切り替えはライブサービスに関してセルの使用を減少させるために有利である。ここで注意すべきは、上述の実施形態は、1つ又は複数の共通の基地局32と関連している、又はそれらに固定されているユーザーについて考慮する場合にだけ、使用可能となるだけではないことである。むしろ、無線ネットワークは全体的に、その全てのセル及び基地局自身を相互接続しているバックボーン(幹線)を含め、ユニキャスト・プロトコルを使用するメディアコンテンツ・ストリーミングを要求している過剰に多数のクライアントによって不注意に逼迫させられることが多く、そのストリーミングは代替的に、マルチキャスト・プロトコルによってもまた実行され得ることが多い。
【0138】
このように、基地局/LTEネットワークは、ユニキャスト・ユーザーに対してライブサービスを配信するが、サービスに対するユーザー要求の数が増大する場合には、サービスは、バックボーンと移動ネットワーク・インフラストラクチャの無線リンクとに対するデータレート需要を低減させるため、マルチキャスト/ブロードキャストのサービスへと切り替えられるべきである。
・例えばHTTPからFLUTE(UDPを介するブロードキャストファイル・ダウンロード・プロトコル)への切替え。
【0139】
ユーザーはHTTPサービスに対するデータサービスを要求する。Httpサーバーは、FLUTEプロトコルを介してHTTPゲット要求をリターンする。
<RedundantURL>http://cdn1.example.com/</RedundantURL>
<RedundantURL>flute://cdn2.example.com/session-description.sdp</RedundantURL>
【0140】
例えばセッション記述プロトコルSDP [IETF RFC 4566]におけるFLUTE(File Delivery over Unidirectional Transport:単方向トランスポートを用いたファイル配信)セッションの記述に対するリンクを含む「Redundant URL」としてのMPD内の指示に基づいて、プロトコル変更が適用されてもよい。Redundant URLは、HTTPからFLUTEへのプロトコル変更などのような、代替的な伝送特性を有する代替的なメディアロケーションを示す。更に、プロトコル変更は、ユニキャストからマルチキャストアドレスへの資源位置の変更をも含んでもよい。
【0141】
図3図6及び対応する構成例に関して再度明確に注意すべき点として、1つのユーザーエンティティが現時点において2つ以上の基地局32によってサービス提供され得るという点が挙げられる。つまり、ユーザーエンティティは、RRMスケジューラがそのためにRRMを実行する基地局とは異なる基地局を介して、MPDを受信することが可能である。MPDを受信するために、端末は基本的なIP接続性を必要とし、この場合、例えばLTEのRRMユニットを使用するLTEなどの無線システムを介して確立される。従って、MPDを受信するために、UEはRRMによっていくらかの資源を割り当てられる必要がある。現在のLTE Rel.8/9においては、端末は、(例えば10又は20Mhzの帯域幅を有する2.6GHzなどの所定の周波数上で動作する)単一の基地局であって、特有のセル識別子(Cell-ID)を有する基地局に接続される。この場合、UEは、基底にあるLTEネットワークを使用してMPDをゲットできるだけである。次のステップでは、マルチバンド技術が既存のLTEと共に使用可能である。マルチバンドとは、例えば800MHzで動作している1つの基地局と、2.6GHzで動作している別の基地局とを有する状態を意味する。各々の基地局がそれ自身のセルIDを有しているので、1つの端末は同時に両方の基地局へと接続され得る。そのため、1つの端末が2つ以上のIPエントリポイントを有することができ、この例では2つのエントリポイントを有するが、1つの基地局をMPDをリトリーブするために使用し、他の1つを実際にデータをリトリーブするために使用できる。この場合、その端末は両方のRRMユニットを独立して利用することもできる。これはまた、他の技術へと拡張することもでき、例えばMPDを配信させるためにLTEを使用して、データをゲットするためにWifiを使用するなどである。このようなマルチバンドの手法は、クライアント内のある種の情報を必要とする場合があり、それにより、現在のネットワーク負荷又はチャネル品質などに基づいて、どの技術を使用すべきかを判断する。
【0142】
クライアント40に関連付けられたバッファ状態をシミュレーションする上述の説明に関し、シミュレートされたバッファ状態は、ユーザーエンティティ34の内部ではない他の場所に位置する別のバッファであってもよい点に留意すべきである。例えばシミュレートされたバッファリング状態は、実際にはユーザーエンティティの送受信ステージ内のMACレイヤバッファに関連するものであってもよい。例えば、送受信ステージ70内の上述したMACレイヤバッファの一例、即ちバッファ100を示す、図13を参照されたい。バッファ100はまた、基地局32内に位置していてもよい。換言すれば、図13はクライアント40の可能な構成を含む、クライアント40とサーバー32との間のデータ経路の一部の可能な構成を示す。上述した全ての図とは異なり、図13は更に、MACレイヤバッファ100などのようなMACレイヤエンティティ、即ちクライアント40に対しては反対側、即ちRRM30の向こう側に位置するネットワークバッファを示す。ユーザーエンティティの送受信ステージ70に対応する基地局の送受信ステージ102もまた、完全を期すために示されている。送受信ステージ70もまた、とりわけ他のMACレイヤバッファなどのようなMACレイヤエンティティを含むが、しかし、図13では示されていない。ここで、図3のRRM30もまた、ユーザーエンティティのバッファ状態をシミュレートするために、後者のバッファをクライアント40に対するキャッシュされたメディアコンテンツの量に関して監視することができる点に注意すべきである。
【0143】
更に注意すべき点として、上述した機能に対して追加的又は代替的に、図7又は図13のRM74は、図3のRRM30の作業であって、MPDを導出する目的でサーバーとクライアントとの間のデータトラフィックを調査する作業を軽減させることができる。このように、資源管理部74は、メディア・プレゼンテーション記述を完全に解析し検査して、それを、特定のHTTPストリーミングセッションなどのような要求されたメディアサービスに関してクライアントによってサポートされている潜在的なビットレート・オペレーションポイントを含む、部分集合のメディア・プレゼンテーション記述だけへと変換する(translate)ために、使用されてもよい。つまり、変換されたメディア・プレゼンテーション記述は、それぞれのサーバーにおいて利用可能なメディアコンテンツ44のバージョンの不完全な記述、即ち、図3に関して上述した説明の意味においてはある種のメディア・プレゼンテーション記述を表現していてもよい。上述したように、個々のバージョンの情報密度の間の順位、即ちそれぞれのバージョンの品質の非常に粗い測定値だけが、変換済みのメディア・プレゼンテーション記述内で信号伝達されてもよい。代替的に、上述したように、各バージョンに関し、ユーザーに対してそれぞれのバージョンを提供するために必要な最小帯域幅が、変換済みのメディア・プレゼンテーション記述内で、各関連するメディアコンテンツ・バージョン、即ちユーザーエンティティの機器に従ってユーザーエンティティにおいてユーザーに対して提供可能であるメディアコンテンツ・バージョンに関し、信号伝達されてもよい。この変換済みMPDは、次に、例えばPHY/MACレイヤ上で無線資源管理部30へと転送されてもよく、その目的は、無線資源管理部がこれらのビットレート・オペレーションポイントを使用して、その制御下にある特定のクライアントと他のクライアントに対する更なるスケジューリングと無線資源割り当て決定とを行わせるためであってもよい。適応性を可能にするビデオサービス、即ちそれぞれのビットレート・オペレーションポイントをサポートできるサービスのタイプが、非特許文献19に定義されるようなサービス品質(Quality of Service)パラメータ信号を使用して示されてもよい。従って、サービスの特性を指示するために、「適応的非対話型ビデオ(Adaptive Non-Conversational Video)」及び「適応的ビデオ(Adaptive Video)」などの新たなトラフィッククラスが表6に追加されてもよい。これらの新たなクラスは、無線資源管理部における資源割り当てのためにそこから選択されるべきレートの集合の指示、即ち変換済みMPDの指示を、更に要求する可能性がある。最小の保証付きビットレート(GBR)の信号化は、サービスのための最小レート及び/又は他の有意なオペレーションポイントの信号化を許可するよう拡張される必要がある。最小ビットレートが関する限り、変換済みのメディア・プレゼンテーション記述は、この最小ビットレートを、TCPレベルなど高位のOSIデータトラフィックレベル、又はより低位のあるOSIレイヤレベルにおいて測定されるビットレートに関して、例えば基地局又は無線資源管理部30によって割り当てられるべき最小ビットレートに関して、指示してもよいことに留意すべきである。実際に割り当てられ伝送されるビットレートと、メディアコンテンツの伝送において実際に有効なビットレートと、の間の不一致についての上述した考察を参照されたい。その場合の不一致は、例えばパケット損失及びNACK又はACKに基づく再伝送に由来するものである。
【0144】
上述したように、実際のメディア・プレゼンテーション記述46から導出された変換済みメディア・プレゼンテーション記述の、ユーザーエンティティ34内にある資源管理部74による伝送は、上述した「適応的非対話型通信」などのような、それぞれユーザーエンティティと基地局との間で交換されるべき新たなタイプ又は種類の通信データを導入することと、この新たな通信データタイプ、即ちこの専用のベアラ(dedicated bearer)の活性化のプロトコルプロセス内で変換済みMPDを伝送することにより、LTEなどいずれかの既存の無線資源ネットワークへと統合されることが可能である。図15は、この可能な統合の実例をより詳細に示す。ここでは例示的にLTEを無線資源ネットワークの代表例として使用しているが、しかし原則的に、図15の実施形態は他の無線資源ネットワークへと容易に転換され得る。特に、図15は、そのような例示的ベアラ、即ち「適応的非対話型通信」を作成し、変換済みメディア・プレゼンテーション記述を無線資源管理部30へと伝送する中で実行される連続的なステップを示している。特に図15は、これら全てのステップを、時間軸110に沿った時間的順序で、以下により詳細に説明するそれぞれのブロック及び関係する矢印によって示すものである。これらブロック及び関係する矢印は、それぞれのステップに関係するそれぞれのエンティティに亘って延びるように、水平方向に示されており、それらエンティティとは、データトラフィックチェーンのエンティティであって、ユーザーエンティティ40と、基地局32と、無線資源管理部30と、移動性管理エンティティ112と、パケットゲートウェイ114と、メディアサーバー42とである。上述したように、移動性管理エンティティ112はまた、無線資源ネットワークの全ての基地局と接続されており、少なくとも部分的には、無線資源管理部30と同じハードウエア上に実装されることも可能である。また上述したように、移動性管理エンティティ112は、ユーザーの支払い準備口座からの引き落としなどのユーザーのアクセスデータを管理する役割や、ユーザーのプロファイルを管理する役割を担い、そのプロファイルは、それぞれのユーザーに対して割り当て可能な最大帯域幅などのような所定のユーザーの権利や、所定の通信データタイプ/種類に対する制限などを示すものである。更に、移動性管理エンティティ112は、1つの基地局セルから他の基地局セルへと移動するユーザーエンティティのハンドオーバー(受け渡し)を処理する役割を担うこともできる。パケットゲートウェイ114は、エンティティ40と32と30と112とが属している無線資源ネットワークを、外部即ちインターネット又はその他へとインターフェイスさせる役割を担う。無線資源管理部30と移動性管理エンティティ112とを1つのユニットへとまとめる可能な統合を、破線116によって例示的に示す。ここで、点線118は、無線資源管理部30が基地局32の内部に配置され得るという可能性を示す。
【0145】
図15から分かるように、ユーザーエンティティ40が、例えばインターネットに対する低複雑性のアクセスを実行するなどの無線資源ネットワークを介した最小タスクを実行できるように、ユーザーエンティティ40は既に無線資源ネットワークと接続されており、デフォルトベアラ(default bearer)は既に活性化されている、ということが推定される。接続とデフォルトベアラの活性化とのステップは116で示す。より詳細には、ユーザーエンティティのドメインが関係する限り、ステップ116は、送受信ステージ70によって実行される。次に、ユーザー又はユーザーエンティティ34におけるクライアント40は、MPD要求118を、本件の例ではデフォルトベアラセッションを使用して、メディアサーバー42に対して送信する。メディアサーバー42はステップ120においてMPDを返送し、ステップ122では、ユーザーエンティティ34内の資源管理部74がこのMPDを解析して、上述したようにステップ120のMPDを変換済みMPDへと変換する。次に、専用ベアラ活性化、例えば「適応的非対話型通信」の活性化などがステップ124においてトリガーされる。例えばトリガー124は、メディアコンテンツを要求しているユーザーエンティティ34のユーザー又はその場所にいるクライアント40によって、引き起こされていた可能性もあり、そのメディアコンテンツは、ステップ122において解析されたMPDが言及したものであってもよい。トリガー124に応答して、資源管理部74と送受信ステージ70とが協働し、ベアラ資源割り当て要求(bearer resource allocation request)をステップ126において基地局32へと送信する。基地局32は、その指令を受けて、ステップ128において、それぞれの割り当て要求を無線資源管理部30と移動性管理エンティティ112とに対してそれぞれ転送する。割り当て要求は、例えば以下により詳細に説明するシンタックスを使用する、上述の変換済みメディア・プレゼンテーション記述を含む。次に、移動性管理エンティティ112は、パケットゲートウェイ114に対し、ステップ130においてベアラ資源コマンド(Bearer Resource Command)を使用してそれぞれのベアラ資源が作成されるべきであると伝達する。この場合、作成そのものはステップ132において実行される。従って、ステップ128以降は、変換されたメディア・プレゼンテーション記述のコンテンツは無線資源管理部30にとって既知となる。しかし、専用ベアラの活性化は未だ確認されていない。従って、移動性管理エンティティ112は、ステップ134において専用ベアラ活性化要求を基地局32に対して送信することにより、別の肯定応答ルーチン(acknowledgment routine)を開始する。基地局32は、ステップ136において、この専用ベアラ活性化要求をユーザー34へ、特に送受信部70へと転送する。次に、ステップ140において、送受信ステージ70は基地局32に対して専用ベアラ活性化要求の受領を信号伝達し、次に、基地局はステップ142において、無線資源管理部30と移動性管理エンティティ112とに対して同様の伝達を行う。その時以来、無線資源管理部30は、ステップ120から128までを介して資源管理部74から資源管理部30へと信号伝達された変換済みのメディア・プレゼンテーション記述を使用して、上述した無線資源の割り当て、即ちスケジューリングを実行することが可能となる。このようにして、ユーザーエンティティ34におけるクライアント40とメディアサーバー42との間のメディア伝送セッション144は、基地局32と無線資源ネットワークとによってサービス提供される全てのユーザーエンティティに対するそれぞれの無線資源割り当てを考慮する上で効率的といえる方法で、無線資源管理部30によって制御されてもよい。
【0146】
図15に関して注意すべき点は、一般的に、専用の無線ベアラをセットアップする方法として2つの可能性があることである。第1の可能性は、クライアント主導である。この場合、UE34は、図15に示すように、デフォルトベアラを介してインターネットに対して接続されている。クライアント40によって以前に発信されたMPD要求118への応答120に基づいて、ユーザーエンティティのRM74は、対応するMPDファイルを受信して検査し、専用の無線ベアラをしかるべくトリガー(124)する。この作業は、移動性管理エンティティ112(MME)に対してESMベアラ資源割り当て要求を送信(126)して、専用ベアラ活性化をトリガーすることによって実行される(非特許文献20の第8.3.8章を参照)。このメッセージ126は、サービス情報の要求された進化型パケットシステム(evolved packet system:EPS)品質、即ち変換済みMPDを定義するある情報要素(IE)を含む。
【0147】
可能性のある他の方法は、ネットワーク主導である。この場合、P-GW(パケットゲートウェイ)114が、要求されたQoSベアラをハンドオーバー処理の間に保持するために必要な無線ベアラのセットアップをトリガーする。両方の場合に、ESM活性化専用ベアラ要求(EMS Activate Dedicated Bearer Request)メッセージ(非特許文献20の第8.3.3章を参照)が送信されて、このメッセージは、後段に記載する表に示すサービス情報のEPS品質(非特許文献20の第9.9.4.3章を参照)を含む。この表は、(非特許文献20と比較して)拡張又は修正されており、最小のみ及び代替的なより高いビットレートを有する保証付きビットレート(GBR with minimum only and alternative higher-bitrates)と、代替的ビットレートを有する非保証のビットレート(Non-GBR with alternative bit rates)とのための信号伝達、即ち変換済みMPDを含む。図15に示すように、UEが専用ベアラをトリガーする場合には、MPD内で見つかる代替的ビットレートなどの情報要素を、UEが提供することになる。ネットワークが専用ベアラをトリガーする場合には、代替的ビットレートと変換済みMPDとは、それぞれ、ハンドオーバーの場合には対応するP-GWによって提供され、又はMPDを検査した後で資源管理部(74)から提供されることになる。従って、P-GWはRRMに対し、MPDの位置又はそのコンテンツについて情報提供する必要がある。非特許文献20において、他のメッセージ、即ちベアラ資源修正要求(Bearer Resource Modification request) (第8.3.10章を参照)と、活性化デフォルトEPSベアラ要求(Activate default EPS Bearer request) (第8.3.6章を参照)とはまた、表3に記載のサービス情報メッセージのEPS品質も含み、上述の代替的ビットレートを提供するために使用されてもよい。
【0148】
【表3】
【0149】
1つの可能性として、表4に示すように更なるオクテットを追加することが挙げられる。保証付きビットレートにおいて示されたレートは、最低品質/最低情報密度の領域などについて保証されるべき最小帯域幅に対応してもよく、他方、ダウンリンク及びアップリンクのための代替的ビットレートは、元のMPD46内で見られるようにダウンロードのために利用可能なビットレートを記述してもよい。代替的ビットレートのフィールドは、QCIフィールドの値に依存して存在する。例えば表5に定義される新たなQCI値が使用される場合には、ダウンリンク又はアップリンクのための代替的ビットレートが存在しなければならない。このメカニズムにより、後方互換性が可能になる。QCIの値が理解されない場合には、保証付きのビットレートが存在するか否かに依存して、別のGBR又はnon-GBR(非保証のビットレート)QCIが選択される。
【0150】
【表4】
【0151】
他の可能性として、サービス情報メッセージのEPS品質に対して追加的メッセージを追加することが考えられ、それらは、サービス情報メッセージのEPS品質が使用される上述のメッセージに対して追加されるであろう(ESMベアラ資源割り当て要求、ESM活性化専用ベアラ要求、ベアラ資源修正要求、活性化デフォルトEPSベアラ要求)。これにより、サービスメッセージのEPS品質をそのままにすることが可能になり得る。拡張のコンテンツは、表5に記載のようであってもよい。この場合、保証付きビットレート値は、サービス情報メッセージのEPS品質内にあると考えられるべきであるが、しかし、QCI値は拡張メッセージによって書き換えられ得る。代替的ビットレートもまた、この拡張メッセージ内で記述され得る。
【0152】
【表5】
【0153】
図15に示すように、MME112は、サービスに関する所与のQoSを有するベアラをセットアップするために、コアネットワークの他の構成要素、即ちS-GW及びP−GW114とメッセージを交換しなければならない。S-GWは、基地局(eNB)と他のEPC(Evolved Packet Core)エンティティ、例えばP−GWとの間のゲートウェイである。P−GW(及び時にはPDN−GW=パケットデータ・ネットワーク・ゲートウェイと呼ばれることもある)は、EPCとインターネット/バックボーンとの間のインターフェイスである。ゆえに、LTEネットワーク内の全てのデータは、UE (terminal) <-> eNB <-> S-GW <-> P-GW <-> Internet / Backboneからのルートを有している。
【0154】
更なるメッセージの交換には、MMEからS−GWへ、及びS−GWからP−GWへのGTP−Cベアラ資源コマンド(非特許文献21の第7.2.5章を参照)と、P−GW114からS−GWへ、及びS−GWからMME112へのGTP−Cクリエト・ベアラ要求(非特許文献21の第7.2.3章を参照)と、E−RABセットアップ要求/応答(非特許文献22の第8.2.1.1章及び第8.2.1.2章を参照)であって、無線資源管理部30に対し、提供されるべきQoS特性について報せるデータが含まれる。上述したこれらのメッセージは、表4及び表5に示す拡張に従って拡張されなければならない。例えば、GTP−Cベアラ資源コマンドに対しては、非特許文献21の第8.16章に記載のFlow QoS IEが、本願の例えば表6に示すように定義された代替的ビットレートを用いて拡張されるべきである。GTP−Cクリエト・ベアラ要求に対しては、非特許文献21の第8.15章に記載のFlow QoS IEが、本願の例えば表7に示すように定義された代替的ビットレートを用いて拡張されるべきである。E−RABセットアップ要求に対しては、MME112は、非特許文献22の第9.2.1.15章に記載のE−RABレベルQoSパラメータ内の取り決められた代替的ビットレート(negotiated Alternative bit rates)を挿入すべきである。この目的で、E−RAB Level QoSは、以前に定義された追加的な代替的ビットレートを追加して、例えば表8及び表9に示すように、拡張されるべきである。
【0155】
【表6】
【0156】
【表7】
【0157】
【表8】
【0158】
【表8】
【0159】
上述した処理と同様に、ハンドオーバーは、非特許文献23に説明されるようにeNodeBによって開始されてもよい。そのような場合、(同じQoS特性を有する)ベアラセットアップ又はベアラメンテナンスは、MMEにより開始されず、又はESMベアラ資源割り当て要求を送信しているP−GWによっても開始されず、むしろ非特許文献24の3GPP内で定義されたX2インターフェイス内で実行される。そのような場合、前段で提案された、代替的ビットレートを有する拡張されたシンタックスが、適切なメッセージ内に含まれていなければならない。具体的には、インターフェイスX2に関してHANDOVER REQUESTメッセージが定義されており(非特許文献23の第9.1.1.1章を参照)、これはE−RABレベルQoSパラメータIE/グループ名を含む。このIEは非特許文献23の第9.2.9章に定義されており、表8に示すように拡張されるべきである。このメッセージのシンタックスは、上述したE−RABセットアップ要求と同一であってもよい。
【0160】
更に、上述した機能に対して追加的又は代替的に、資源管理部74は、より高いレベルのTCPセッションにより見られるような実際の受信されたスループットを、無線資源管理部30に対する情報として転送してもよく、その目的は、無線資源管理部30が、その制御下にある特定のクライアント及び他のクライアントのための更なるスケジューリング及び無線資源割り当て決定のために、実際の結果的なアプリケーション・スループットを識別できるようにするためである。さらに一般的には、クライアント40がその上で動作可能なユーザーエンティティが無線資源基地局32と通信するために存在してもよく、その場合、ユーザーエンティティ34は、クライアント40によってサーバー42からリトリーブされたメディアコンテンツの実際に受信されたメディアコンテンツ・スループット又はバッファ状態を決定し、さらに、その決定されたメディアコンテンツ・スループット又はバッファ状態を、無線資源管理部30に対して情報提供するよう構成されてもよい。その決定は、ユーザーエンティティ内でそれぞれの作業を担う資源管理部74に対してクライアント40がそれぞれの情報を送信することを含んでもよい。
【0161】
図3図5の実施形態に関して注意すべき点として、上述した説明は、主としてダウンリンクの場合、即ち無線資源管理部がダウンリンク通信資源をユーザーエンティティ34へと割り当てるものであったが、しかし、上述の実施形態はまたアップリンクの場合にも当てはまるという点が挙げられる。より一般的な視点から見ると、例えば図3図5、及び通信資源の割り当てが実行される無線資源管理部30の機能に関する他の全ての実施形態において、無線資源管理部は、より一般的には、少なくとも1つの基地局32の通信資源、即ちダウンリンク及び/又はアップリンク通信資源を、サーバーからクライアントへのデータトラフィック内のメディア・プレゼンテーション記述に依存して、ユーザーエンティティ34に対して割り当てを実行してもよく、その場合、サーバー及びクライアントの一方がユーザーエンティティ34の1つにおいて動作しており、但し、この一方はクライアントである必要はない。この点に関しては以下により詳細に説明する。例えば図16を参照されたい。小さな注意点として、サーバーとクライアントとの両方が1つの共通のユーザーエンティティにおいて動作していてもよい点をあげておく。従って、「サーバー及びクライアントの内の一方」とは、「少なくとも一方」として理解されるべきである。
【0162】
図16は、クライアント40とサーバー42とが入れ替わっている点を除き図3に対応する。即ち、サーバー42がユーザーエンティティ34において動作し、他方、クライアント40がユーザーエンティティ34から見て基地局32の向こう側に位置している。図7に示すようなユーザーエンティティの可能な内部構造のより詳細な説明を考慮するとき、サーバー32は、図7におけるクライアント40と置き換えられるものとして理解されてもよい。これは以下のことを意味する。即ち、無線資源管理部30は、サーバー42と40との間のデータトラフィックを調査する。特に、無線資源管理部30は、そこからメディア・プレゼンテーション記述46を調査してもよい。その調査に基づき、無線資源管理部30は、基地局32のアップリンク通信資源をユーザーエンティティに対して割り当ててもよく、それらユーザーエンティティの中には、サーバー42が動作するユーザーエンティティ34が含まれる。原則的に、資源管理部30の潜在的な挙動に関する上述した全ての説明には変化がない。つまり、資源管理部30はまたクライアント40からサーバー42へのメディア要求を調査して記録し、その評価やその他に依存してアップリンク通信資源の割り当てを実行してもよい。
【0163】
図3図5の実施形態を一方とし、図16の実施形態を他方とする場合の一致点に関する説明は、両方について有効である。即ち、図3図5の実施形態の上述した拡張であって、無線資源管理部30の機能の一部がRRM30からサーバー42と送受信ステージ70との間に位置する(例えば図7を参照)資源管理部74へと移された場合を考慮するときにも、有効である。つまり、以下の点は図16の実施形態の場合でも当てはまる。即ち、資源管理部74は、ユーザーエンティティ34の場所にあるサーバー42とクライアント40との間のデータトラフィックを調査する作業について、RRM30の作業を緩和するよう構成されてもよい。つまり、その場合でも、即ちサーバー42がユーザーエンティティ34上で実行している場合でも、アップリンク帯域幅の資源は同様に管理され得る。具体的には、資源管理部74が無線資源管理部30に対し、ビットレートの選択可能な代替即ち変換済みのMPDを示し、RRM30は、その変換済みMPDを使用して、それに基づくアップリンク資源割り当てを実行してもよい。資源管理部74は、アップリンクのための代替的ビットレートを、上述したESMメッセージ即ち表4内で示したようなサービスメッセージの拡張されたEPS品質を含むメッセージ内で示してもよい。
【0164】
例えば図14を参照されたい。図14は、その左側において、図15において時間軸110を用いた場合と同様のフロー図を示し、ブロック内で示されたそれぞれのステップと関連する各エンティティを水平方向に各エンティティを分散させることにより差別化し、また、それぞれのブロックに関連する矢印によってそれぞれのステップがどのエンティティの間において行われるかを示している。図14の右側には、図15の実施形態、即ちクライアントがユーザーエンティティの場所にいる場合が再度示されている。左側には、サーバー42がユーザーエンティティ34において動作する場合が示される。事実、1つのユーザーエンティティにおいて動作しているクライアントと、他のユーザーエンティティにおいて動作しているサーバーとは、1つのペアを形成して、その間にメディアコンテンツが伝送されてもよい。そのような状態は、例えばビデオ会議であって、ユーザーエンティティ34’の場所で動作しているサーバーが、ユーザーエンティティ34''の場所で動作しているクライアントに対し、ユーザーエンティティ34’の場所で例えばユーザーエンティティのそれぞれのカメラによって捕捉されたビデオ会議の参加者に関するビデオを送信する場合などに発生する可能性がある。しかし、他の場合でも同様に発生可能である。例えば、クライアントが誰か他のユーザーエンティティ34’の場所にあるメディアサーバーからのファイルをダウンロードすることもあり得る。その場合、ユーザーエンティティ34’におけるサーバーを一方とし、ユーザーエンティティ34''におけるクライアントを他方とする、二者間のデータトラフィック内に参加しているエンティティは、図14で左から右へと進む方向で順番に列挙すれば、ユーザーエンティティ34’と、ユーザーエンティティ34’が現時点で接続している基地局32’と、基地局32’の通信資源を割り当てる役割を担う無線資源管理部30’と、基地局32’及び無線資源管理部30’が属している無線資源ネットワークを制御する役割を担う移動性管理エンティティ112’と、同じ無線資源ネットワークに属しているパケットゲートウェイ114’と、クライアント34''が接続されている基地局32''が属している無線資源ネットワークに属するパケットゲートウェイ114''及び移動性管理エンティティ112''と、基地局32''の通信資源を割り当てる役割を担う無線資源管理部30''と、基地局32''自身と、ユーザーエンティティ34''とである。図14に示すように、ユーザーエンティティ34''がステップ116において接続とデフォルトベアラ活性化をするのと同様に、ユーザーエンティティ34''は、ステップ116’において、接続とデフォルトベアラ活性化を実行してもよい。図15について上述したように、ユーザーエンティティ34''上に位置しているクライアントは、ステップ118において、ユーザーエンティティ34’に位置するサーバーに対してMPD要求を送信してもよく、次に、ユーザーエンティティ34’が、ステップ120において、ユーザーエンティティ34''に対し、MPDを返送してもよい。次に、ステップ122において、ユーザーエンティティ34''に位置する資源管理部74は、MPDを解析して、上述のステップ126からステップ142の説明に沿って専用ベアラの活性化を引き起し、次に、資源管理部30は、その時クライアントとサーバーとの間に存在するメディア伝送セッション144内でユーザーエンティティ34''の資源管理部74によって転送された変換済みのMPDに従って基地局32''のダウンリンク通信資源を割り当てる。アップリンクドメイン側でも、同様のステップが実行される。図15に関して上述したステップ126からステップ142までと同様に、ユーザーエンティティ34’の場所にあるサーバー42は、専用ベアラの活性化を引き起こす。即ちここでは、適応的な対話型または非対話型の通信タイプセッションである。次に、メディア伝送セッション144内で、無線資源管理部30’は、基地局32’のアップリンク資源を、ユーザーエンティティ34’にあるサーバーによってベアラ資源割り当て要求126内で転送された変換済みメディア・プレゼンテーション記述に従って、割り当てる。
【0165】
図14は、サーバーとクライアントとの両方がそれぞれの無線資源ネットワークに接続されたユーザーエンティティ上に位置している場合を単に例示的に示したに過ぎないことに言及しておく。図14の例は、クライアントがユーザーエンティティの場所で動作しておらず、例えば定置のコンピュータにおいて動作している場合にも容易に転換可能である。しかも、上述のシナリオは、1つの共通の無線資源ネットワーク内であってもよく、また、RRM’とRRM''及び/又はMME’とMME''とが同一であるような場合にも起こり得ることに留意すべきである。
【0166】
ところで、上述した全ての実施形態に関し、メディアコンテンツ44が存在するサーバーは、メディア・プレゼンテーション記述を提供するためのサーバーとして作動しているエンティティから分離されてもよいことに留意すべきである。より一般的には、MPD46は、メディアコンテンツ44を提供しているサーバー自身とは別のエンティティ又はサーバーから発生してもよい。このような可能性は、例えば図14内では点線を用いて矢印の起点と目標点とがステップ120とステップ118とにそれぞれ対応するように示される。特にこの潜在的なMPDソースは、点線を用いて符号150を付して示されている。しかし、このエキストラのMPDソース150の場合には、無線資源管理部30’は、資源管理部74から変換済みのメディア・プレゼンテーション記述に関する情報を得ることができる。しかしこの場合には、資源管理部74は、ユーザーエンティティ34''の場所にあるクライアントとユーザーエンティティ34’の場所にあるサーバーとの間のデータトラフィックを検査する代わりに、ユーザーエンティティ34’の場所にあるサーバーに対し、ユーザーエンティティ34''の場所にある資源管理部74に対して変換済みメディア・プレゼンテーション記述を供給するよう指示することができる。
【0167】
換言すれば、図14内の左側にあるユーザーエンティティ34はメディアサーバーとしてセットされ、右側にあるユーザーエンティティ34はクライアント40としてセットされる。MPDはクライアントによりMPDソース150から要求されるが、そのMPDソースはネットワーク内のいずれのサーバーでもよい(1つの特別な場合は、MPDを有するサーバーがユーザーエンティティ34’の場所にあるメディアサーバーである場合になる)。メディアサーバーは、MPDにおいて公表されているメディアの特性を知っているので、メディアサーバーはこの情報を上述したESMメッセージ内で代替的ビットレートを示すために使用し、更に、ベアラを設定し、そのベアラにとってはアップリンクビットレートが特別に重要となる(サーバーはデータをアップロードする必要がある)。しかし、クライアントは受信されたMPDを解析する必要があり、またベアラ割り当てに関する記述された情報を使用する。このとき、ダウンリンクビットレートが特別な重要性を持っている(クライアント40はデータをダウンロードする必要がある)。しかしながら、TCPが使用される可能性があるので、アップリンクビットレートがクライアントにとって重要であるのと同様に、ダウンリンクビットレートもまたサーバーにとって重要である。
【0168】
特別な場合として、例えば対話型のシナリオにおいて、ユーザーエンティティ34の各々がメディアサーバーとそこで動作しているクライアントとを同時に有する場合が挙げられる。この場合には、両方のユーザーエンティティ34がメディア・プレゼンテーション記述(例えばMPD又はSDP)を要求してもよく、更に、アップリンク及びダウンリンクのための代替的ビットレートを記述するためにこの情報を使用することもでき、その記述は、それぞれのサーバーにおいて提供されるメディア特性に基づき、またクライアント40として受信すると想定されるメディア特性にも基づいている。
【0169】
ユーザーエンティティ34がメディアサーバーとクライアントとを同時に有する、そのようなシナリオにおいては、2つの異なるeNodeBが対話に参加している異なるユーザーエンティティ34を回線制御することも起こり得る。eNodeBの各々のために動作し、ユーザーエンティティ34を回線制御している無線資源管理部30は、異なるユーザーについてのエアインタフェイス(air interfaces)の各々を最適化しながら独立して動作する。そのようなシナリオの課題は、1つのユーザーエンティティ34のエアインタフェイスが他のユーザーエンティティ34の無線資源の最適化のために考慮されないことである。従って、次善的な決定が行われる可能性がある。例えば、1つのユーザーエンティティ34からアップロードされるデータ量が、その1つ目のユーザーエンティティ34が交信している他のユーザーエンティティ34においてダウンロード可能なデータ量よりも多い場合には、ユーザーエンティティ34と協働している無線資源管理部30において、「ダウンロード問題」を用いて幾つかのデータが削除されるであろう。1つの解決策は、非特許文献23のX2インターフェイスに定義されたメッセージを拡張し、且つ、MPD又はSDPに定義された情報に基づいてユーザーの各々について保証されるであろう資源についての具体的な情報を提供するメッセージを追加することである。そのような方法で、両方のeNBが、本願を通じて定義されたSDP又はMPDの中の情報を考慮しながら、協働的な資源割り当てを実行する。新たなメッセージは、例えばUE RESOURCE STATUS REPORTでもよく、表9、表10及び表11に示された資源割り当てIEを含んでもよい。
【0170】
直前で示した実施形態は、これから説明する意味におけるメディア知識がない状態での協働的な資源割り当てを開示するものである。つまり、例えば図3を参照されたい。図3は、単一の無線資源管理部30を示しているが、しかし上述したように、複数の無線資源管理部から成る1つのシステムが1つの無線システムを形成してもよく、その場合、全ての無線資源管理部30が以下のような意味において相互に独立して動作してもよい。即ち、各無線資源管理部30が、その少なくとも1つの基地局32の通信資源を、その基地局32の到達範囲内にあるユーザーエンティティ34に対して最適化を通じて割り当て、その割り当てが、上述したユーザーエンティティ34からの品質フィードバックや、サービス提供を受けるユーザーエンティティ34の数など、無線資源管理部自身の単数又は複数の基地局32に亘って伝送されている情報だけに基づいていてもよい。上述した説明を参照されたい。つまり、各RRMは互いに独立してそのスケジューリングを実行する。しかし、そのスケジューリングの独立性には、この実施形態に従えば以下のような意味で風穴を開けることができる。即ち、RRMは、そのUEに対するそれらの現在の無線資源配分についての情報を、他のRRMが使用できるように外部に向かって配信してもよい。直前で示した実施形態においては、メディア・プレゼンテーション記述内に存在する情報があったとしても、無線資源管理部が必ずしもその情報を活用する必要はない。しかし、これから説明する実施形態においては、独立して動作している複数の無線資源管理部30が、偶然にもそこで動作しているクライアントとサーバーとの通信ペアを有する複数のユーザーエンティティに対して、不適合な通信資源を誤って割り当てることを回避し得る。これは以下のようにして達成される。
【0171】
特に無線資源管理部が、ユーザーエンティティ34の内の1つにおいて動作しているサーバー又はクライアントに向かうデータトラフィック、又は無線資源管理部同士の間で交信される何らかの制御メッセージを調査して、サーバーとクライアントとの他方に現時点で割り当てられている保証付き通信資源、又はサーバーとクライアントとの他方のバッファ状態についての情報を得る。現在の無線資源管理部30によってサービス提供されているユーザーエンティティ34上で動作しているサーバーの場合には、このサーバーのバッファ状態は、例えば出力バッファ状態、即ち出力バッファの充満レベルを形成してもよい。このレベルは、例えばライブストリーミング又はビデオ会議の場合に有意義であり得る。ユーザーエンティティ34上で動作しているクライアント40の場合には、バッファ状態は、クライアントの入力バッファの充満レベルとなるであろう。ここで強調しておくが、この実施形態によれば、無線資源管理部30(図3を参照)は、他の無線資源管理部30によってサービス提供されているサーバー又はクライアントに関するこの情報を取得する。単に、クライアント/サーバーのペアの片方がその無線資源管理部30自身によるサービス提供を受けているユーザーエンティティ34上で動作しているだけである。この実施形態によれば、無線資源管理部30は、別の場所でサービス提供されているユーザーエンティティ上で動作しているクライアント/サーバーの他方に関するこの情報を使用して、ユーザーエンティティ34がサービス提供されている少なくとも1つの基地局32の通信資源の割り当てを実行する。この方法により、例えばクライアント/サーバーの片方のバッファ状態が高い場合、又はクライアント/サーバーの片方が動作している外部のユーザーエンティティに現在割り当てられた保証付き通信資源が低い場合であっても、無線資源管理部30がいずれかのユーザーエンティティ34に対して不必要に多い通信資源を割り当てることを防止することができる。
【0172】
この点を明らかにするため、複数の無線資源管理部を含むシステムを示す図17を参照されたい。LTEの枠組みにおいては、RRMが上述のeNodeBを形成してもよい。無線資源管理部の内の1つが例示的に参照番号30で示され、他の1つが30’で示されている。2つの管理部だけを示したという事実は、単に例示的である。両方の管理部30と30’とは、少なくとも1つの基地局32と32’との各通信資源をそれぞれに割り当てる。割り当て又はスケジューリングは、互いに独立して実行されるが、ここで説明する制御信号又はデータトラフィック挿入(insertion)を含む相互作用は別である。
【0173】
図17には、無線資源管理部30に属する基地局32から1つのユーザーエンティティ34がサービス提供されるよう例示的に示されており、無線資源管理部30’に属する基地局32’から他のユーザーエンティティ34’がサービス提供されるよう示されている。ユーザーエンティティ34上ではクライアント40が動作し、ユーザーエンティティ34’上ではサーバー42が動作するように例示的に示される。両ユーザーエンティティは、図17の破線で示されたデータトラフィックによって互いに通信可能である。データトラフィックは、遠隔通信タイプ、ダウンロードタイプまたはその他であってもよい。図3に関して上述したように、無線資源管理部30と30’とがそのデータトラフィックによって通信される必要はない。両方の無線資源管理部30と30’とが単にデータトラフィックに対してアクセスでき、そのデータトラフィックを調査及び検査できれば十分である。
【0174】
RRM30と30’との間の最適化ミスを防止する目的で、これらRRMは、現在のUEバッファ状態と他のそれぞれのRRMに対して現在保証されているビットレートとに関して、互いに情報伝達する。
【0175】
第1の選択肢によれば、両方のRRMは互いに不可知のままでもよい。サーバー又はクライアントが例えばインターネット内の無線システムの外部でサービス提供される場合でも、最適化ミスが防止できるように、それぞれの情報はクライアント/サーバー・データストリーム内へと挿入される。
【0176】
無線資源管理部30’は、例えばクライアント40が動作しているユーザーエンティティ34に現在割り当てられている保証付き通信資源、又はこのクライアント40のバッファ状態についての情報を得るために、サーバー32からクライアント40へと向かうデータトラフィックを調査することができる。この方法により、例えばクライアント40のバッファ状態が既に高い場合や、又はユーザーエンティティ34に対して現在割り当てられている保証付き通信資源が低い場合であっても、無線資源管理部30’はサーバー42のために過大な通信資源を費やすのを避けることができる。他方、無線資源管理部30は、ユーザーエンティティ34’に現在割り当てられている保証付き情報資源又はサーバー42のバッファ状態についての情報を得るために、クライアント40からサーバー42に向かうデータトラフィックを調査することができる。
【0177】
同様の方法で、無線資源管理部30は、この情報を用いて、例えばサーバー42のバッファ状態が充満レベルの空状態に近づいた場合や、ユーザーエンティティ34’に対して現在割り当てられている保証付き通信資源が低い場合であっても、ユーザーエンティティ34に対して過大な通信資源を割り当てることを回避することができる。
【0178】
上述したように、保証付きの通信資源とは、無線資源管理部30と30’とがその単数又は複数の基地局32の通信資源をそのサービス提供を受ける複数のユーザーエンティティ34に対して割り当てる中で、決定できる何かであってもよい。つまり、無線資源管理部30と30’とは、それぞれ保証付きの通信資源をユーザーエンティティ34と34’とに対し、何らかの時間区間の単位で、例えば3〜10秒の時間区間などの単位で割り当ててもよい。無線資源管理部30と30’とはまた、それらの時間区間内で通信資源を割り当てる際に、保証付き通信資源に従わなければならない。無線資源管理部30と30’とは、保証付き通信資源を時間区間を通じて固定的に使用するか、又は、単に保証付きの通信資源によって課せられた制限内において、ユーザーエンティティに対する通信資源の割り当てを変化させる。
【0179】
外部の無線資源管理部のドメインからのバッファ状態又は保証付き通信資源の情報が、どのようにしてデータトラフィックを介してクライアント/サーバーの片方にサービス提供している無線資源管理部の無線資源管理部ドメインの中に侵入するかという方法については、異なる可能性が存在する。例えば無線資源管理部30と30’とは、そのサービス提供されているユーザーエンティティに割り当てられた保証付きの通信資源についての情報を、そのサービス提供されているユーザーエンティティ上で実行しているクライアント40又はサーバー42からのデータトラフィック内に挿入するよう構成されてもよい。例えば無線資源管理部30’は、サーバー42からクライアント40へのデータストリームの中にユーザーエンティティ34’に割り当てられた保証付き通信資源に関する情報を挿入することができ、他方、無線資源管理部30は、クライアント40からサーバー42へのデータトラフィックの中にユーザーエンティティ34に割り当てられた保証付き通信資源に関する情報を挿入することができる。更に、その挿入は必ずしも無線資源管理部30及び30’自身によって実行されるべきものでもない。既に前述の実施例に関して上述したように、そのような挿入はまた、ユーザーエンティティ34及び34’それぞれの上で実行している資源管理部74によっても実行され得る。その場合、無線資源管理部30と30’とは、それぞれユーザーエンティティ34と34’に対し、保証付き通信資源について即ち無線資源管理部30と30’とが関わるユーザーエンティティ34と34’とに割り当てられた保証付き通信資源についての情報を伝達し、さらに、この情報は無線資源管理部の代わりに上述の挿入を実行する資源管理部74によって調査及び検査されてもよい。
【0180】
第2の選択肢によれば、RRM30と30’との両方は、それら自身によるサービスを受けているUEに関する現在のUEバッファ状態及び現在の保証付きビットレートについての情報を、互いに他のRRMに対して制御信号199を介して提供し合う。LTEのアーキテクチャの中で、例えばそのような制御信号は、制御信号交換の経路をしかるべく案内するオペレータとして例えばHSSを使用しながら、例えばX2インターフェイスやS−GWなどを介して、RRM同士の間で交換されてもよい。この実施形態によれば、無線資源管理部30と30’とは、例えば次のようなステップを実行してもよい。即ち、(1)無線資源管理部30と30’自身によってサービス提供されているユーザーエンティティ上で動作しているクライアントが、即時の伝送セッション、即ちこのクライアント又はサーバーを含むメディア伝送セッションの開始をセットアップすることを求めていることを認識する。(2)メディア伝送セッションがセットアップされる片方、即ちサーバー又はクライアントが、無線システムの他の何らかのRRMによってサービス提供されていないかどうかをチェックする。(3)その答えがイエスである場合には、メディア伝送セッションに制御信号199を付帯させる。制御信号のための経路は、例えばHSSを介して案内される。例えば、無線資源管理部30は無線資源管理部30’に対し、制御信号199を介してクライアントのバッファ状態の情報を与え、無線資源管理部30はこの情報を、上述のようにユーザーエンティティ34内における資源管理部74からのシミュレーション又はフィードバックにより獲得していてもよい。又は、無線資源管理部30は無線資源管理部30’に対し、制御信号199を介して、ユーザーエンティティ34に割り当てられた保証付き無線資源についての情報を与えてもよい。無線資源管理部30’もまた同様のことをメディア伝送セッションの間に逆方向で実行してもよい。つまり、無線資源管理部30’は無線資源管理部30に対し、制御信号199を介して、サーバーのバッファ状態及び/又はユーザーエンティティ34’のための保証付き無線資源についての情報を与えてもよい。
【0181】
当然ながら、直上で述べた実施形態はまた、上段で説明した実施例のいずれとも組み合わせることができる。例えば、無線資源管理部自身によるサービス提供を受けているユーザーエンティティ上で動作している、クライアント又はサーバーのバッファ状態が通信資源の割り当てを実行するための無線資源管理部によって使用されるような実施形態が考慮対象である限り、この点は正しい。
【0182】
表9は、非特許文献23の第9.2.13章のメッセージタイプ表を以下のように拡張する。
【表9】
【0183】
表10は、UE資源ステータス報告のシンタックスを示す。
【表10】
【0184】
表11は、UEの割り当てられた資源情報IEのシンタックスを示す。
【表11】
【0185】
代替的に、SDP又はMPDに基づく(メディア特性に基づく)種々のビットレートが、以下の表に示す最大サポートビットレートと共に提供されてもよい。
【表11】
【0186】
表6:標準化されたQCI特性[cp.19]
【表6-1】
【0187】
【表6-2】
【0188】
これまで説明したように、上述の実施形態は、特にソフトエウア、ハードウエア、プログラム可能なハードウエアなどのクライアントであって、無線資源基地局32を用いた通信のためにユーザーエンティティ34上で動作可能なクライアントを開示しており、そのクライアント40は、サーバー42からメディア・プレゼンテーション記述及びメディアコンテンツ44をリトリーブし、メディア・プレゼンテーション記述46はメディアコンテンツ44の異なる帯域幅からなる複数のバージョンを記述しており、クライアントはまた、基地局32の通信資源をユーザーエンティティへと割り当てる役割を担う無線資源管理部30からの信号伝達を通じて、ノーマルモードからスレーブモードへと切替可能であり、クライアントは、ノーマルモードにおいては、ユーザーエンティティに割り当てられた通信資源に基づいてクライアントにより決定されたバージョンでメディアコンテンツ44をサーバー42から要求し、スレーブモードにおいては、ユーザーエンティティに割り当てられた通信資源とは無関係にクライアントにより決定されたバージョンでメディアコンテンツ44をサーバー42から要求する。クライアントはさらに、ノーマルモードでは、ユーザーエンティティに割り当てられた通信資源とメディアコンテンツのバッファ状態とに基づいてクライアントにより決定されたバージョンのメディアコンテンツ44をサーバー42から要求してもよい。さらにまた、クライアントは、スレーブモードでは、メディア・プレゼンテーション記述46内の異なる帯域幅から成る複数のバージョンの内の最も高い帯域幅バージョンに対応するバージョンのメディアコンテンツ44を連続的にサーバー42から要求してもよい。つまり、クライアントの挙動は、例えばMPD内の@automaticSwitchingインジケータによって制御することができ、クライアントは、選択されたセグメントのビットレートに対して途中にある装置がセル資源を最適化するよう途中で調整を加える可能性があるため、クライアントがビットレートの変化に対して自分で反応すべきでない、と情報伝達されてもよい。
【0189】
これまで装置を説明する文脈で幾つかの態様を示してきたが、これらの態様は対応する方法の説明でもあることは明らかであり、そのブロック又は装置が方法ステップ又は方法ステップの特徴に対応することは明らかである。同様に、方法ステップを説明する文脈で示した態様もまた、対応する装置の対応するブロックもしくは項目又は特徴を表している。方法ステップの幾つか又は全ては、例えばマイクロプロセッサ、プログラム可能なコンピュータ、又は電子回路等のハードウエア装置により(を使用して)実行されても良い。幾つかの実施形態においては、最も重要な方法ステップの内の1つ又は複数のステップはそのような装置によって実行されても良い。
【0190】
所定の構成要件にも依るが、本発明の実施形態は、ハードウエア又はソフトウエアにおいて実装可能である。この実装は、その中に格納される電子的に読み取り可能な制御信号を有し、本発明の各方法が実行されるようにプログラム可能なコンピュータシステムと協働する(又は協働可能な)、デジタル記憶媒体、例えばフレキシブルディスク,DVD,ブルーレイ,CD,ROM,PROM,EPROM,EEPROM,フラッシュメモリなどを使用して実行することができる。従って、そのデジタル記憶媒体はコンピュータ読み取り可能であっても良い。
【0191】
本発明に従う幾つかの実施形態は、上述した方法の1つを実行するようプログラム可能なコンピュータシステムと協働可能で、電子的に読み取り可能な制御信号を有するデータキャリアを含んでも良い。
【0192】
一般的に、本発明の実施例は、プログラムコードを有するコンピュータプログラム製品として実装することができ、このプログラムコードは当該コンピュータプログラム製品がコンピュータ上で作動するときに、本発明の方法の一つを実行するよう作動できる。そのプログラムコードは例えば機械読み取り可能なキャリアに記憶されても良い。
【0193】
他の実施形態は、上述した方法の1つを実行するための、機械読み取り可能なキャリアに記憶されたコンピュータプログラムを含む。
【0194】
換言すれば、本発明の方法のある実施形態は、そのコンピュータプログラムがコンピュータ上で作動するときに、上述した方法の1つを実行するためのプログラムコードを有する、コンピュータプログラムである。
【0195】
本発明の他の実施形態は、上述した方法の1つを実行するために記録されたコンピュータプログラムを含む、データキャリア(又はデジタル記憶媒体又はコンピュータ読み取り可能な媒体)である。データキャリア、デジタル記憶媒体又は記録された媒体は、典型的には有形であり、及び/又は非一時的である。
【0196】
本発明の他の実施形態は、上述した方法の1つを実行するためのコンピュータプログラムを表現するデータストリーム又は信号列である。そのデータストリーム又は信号列は、例えばインターネットを介するデータ通信接続を介して伝送されるように構成されても良い。
【0197】
他の実施形態は、上述した方法の1つを実行するように構成又は適応された、例えばコンピュータ又はプログラム可能な論理デバイスのような処理手段を含む。
【0198】
他の実施形態は、上述した方法の1つを実行するためのコンピュータプログラムがインストールされたコンピュータを含む。
【0199】
本発明によるさらなる実施形態は、本明細書に記載の方法のうちの1つを実行するためのコンピュータプログラムを受信機へと(例えば、電子的または光学的に)転送するよう構成された装置またはシステムを含む。受信機は、例えばコンピュータ、携帯デバイス、メモリデバイス、などであってよい。装置またはシステムは、例えばコンピュータプログラムを受信機へと転送するためのファイルサーバを備えることができる。
【0200】
幾つかの実施形態においては、(例えば書換え可能ゲートアレイのような)プログラム可能な論理デバイスは、上述した方法の幾つか又は全ての機能を実行するために使用されても良い。幾つかの実施形態では、書換え可能ゲートアレイは、上述した方法の1つを実行するためにマイクロプロセッサと協働しても良い。一般的に、そのような方法は、好適には任意のハードウエア装置によって実行される。
【0201】
上述した実施形態は、本発明の原理を単に例示的に示したにすぎない。本明細書に記載した構成及び詳細について修正及び変更が可能であることは、当業者にとって明らかである。従って、本発明は、本明細書に実施形態の説明及び解説の目的で提示した具体的詳細によって限定されるものではなく、添付した特許請求の範囲によってのみ限定されるべきである。
【0202】
−略語と記号のリスト−
【表B】
【0203】
[請求項1]
サーバー(42)からクライアント(40)へのデータトラフィックの中で転送されるメディアコンテンツ(44)に関連するメディア・プレゼンテーション記述(46)に依存して、少なくとも1つの基地局(32)の通信資源を複数のユーザーエンティティ(34)へと割り当てる無線資源管理装置であって、前記サーバー(42)と前記クライアント(40)との一方が前記ユーザーエンティティ(32)の1つで動作している、無線資源管理装置。
[請求項2]
請求項1に記載の無線資源管理装置であって、前記メディア・プレゼンテーション記述(46)に依存して、前記少なくとも1つの基地局(32)のダウンリンク通信資源を前記ユーザーエンティティ(34)に対して割り当てるよう構成されており、前記クライアントが前記ユーザーエンティティ(32)の1つで動作している、無線資源管理装置。
[請求項3]
請求項1に記載の無線資源管理装置であって、前記メディア・プレゼンテーション記述(46)に依存して、前記少なくとも1つの基地局(32)のアップリンク通信資源を前記ユーザーエンティティ(34)に対して割り当てるよう構成されており、前記サーバー(42)が前記ユーザーエンティティの1つで動作している、無線資源管理装置。
[請求項4]
請求項1乃至3のいずれかに記載の無線資源管理装置であって、前記メディア・プレゼンテーション記述(46)を得るために、前記サーバー(42)から前記クライアント(40)への前記データトラフィックを調査する、無線資源管理装置。
[請求項5]
請求項1乃至3のいずれかに記載の無線資源管理装置であって、前記ユーザーエンティティから前記メディア・プレゼンテーション記述(46)を受信する、無線資源管理装置。
[請求項6]
請求項1乃至5のいずれかに記載の無線資源管理装置であって、前記メディア・プレゼンテーション記述が、前記サーバー(42)から前記クライアント(40)へのデータトラフィック内において転送されるべきメディアコンテンツ(44)の各バージョンについて、前記メディアコンテンツ(44)の前記バージョンの品質尺度と最小帯域幅とを含む、無線資源管理装置。
[請求項7]
請求項1乃至6のいずれかに記載の無線資源管理装置であって、前記メディア・プレゼンテーション記述(46)を検査して、前記メディア・プレゼンテーション記述(46)内で、前記少なくとも1つの基地局を介して前記クライアント(44)によって現在ダウンロードされている前記メディアコンテンツ(44)のバージョンよりも低い最小帯域幅を持つ前記メディアコンテンツ(44)のバージョンを識別し、前記低い最小帯域幅を持つバージョンが存在するか否かに依存して、前記ユーザーエンティティに対する通信資源の割り当てを実行する、無線資源管理装置。
[請求項8]
請求項7に記載の無線資源管理装置であって、前記低い最小帯域幅を持つバージョンが存在するか否かに依存して、前記ユーザーエンティティに対する通信資源の割り当てを実行し、前記1つのユーザーエンティティに対して割り当てられる通信資源が、−前記無線資源管理装置が通信資源を割り当てる場合に依存する残りのパラメータの可能な状態の間では同じ確率に関係している場合−前記低い最小帯域幅を持つ前記バージョンが存在するときには、前記低い最小帯域幅を持つバージョンが存在しないときと比較して低くなるように構成されている、無線資源管理装置。
[請求項9]
請求項1乃至8のいずれかに記載の無線資源管理装置であって、前記メディア・プレゼンテーション記述(46)を検査して、前記メディア・プレゼンテーション記述(46)内で、前記少なくとも1つの基地局を介して前記クライアント(44)によって現在ダウンロードされている前記メディアコンテンツ(44)のバージョンよりも高い最小帯域幅を持つ前記メディアコンテンツ(44)のバージョンを識別し、前記高い最小帯域幅を持つバージョンが存在するか否かに依存して、前記ユーザーエンティティに対する通信資源の割り当てを実行する、無線資源管理装置。
[請求項10]
請求項1乃至8のいずれかに記載の無線資源管理装置であって、前記ユーザーエンティティに対する通信資源の割り当てを、
−前記少なくとも1つの基地局(32)の通信資源が適切な割合で割り当てられるべきユーザーエンティティ(34)の数、
−前記ユーザーエンティティと前記少なくとも1つの基地局との間で交換されるべき通信データの種類、
−前記ユーザーエンティティに割り当てられたユーザープロファイルであって、前記ユーザーエンティティ間の優先順位を定義するプロファイル、
−前記ユーザーエンティティからのチャネル品質フィードバック、
−前記ユーザーエンティティからのチャネルレート要求、
の内の1つ又は複数に基づいて実行する、無線資源管理装置。
[請求項11]
請求項1乃至10のいずれかに記載の無線資源管理装置であって、前記ユーザーエンティティに対して通信資源を割り当てる際に、前記メディア・プレゼンテーション記述(46)に依存して、
−サブキャリア、
−時間スロット、
−前記少なくとも1つの基地局セルの空間的カバー範囲、
の内の1つ又は複数を調整する、無線資源管理装置。
[請求項12]
請求項1乃至11のいずれかに記載の無線資源管理装置であって、前記通信資源が割り当てられる2つ以上の前記ユーザーエンティティの前記クライアントが前記少なくとも1つの基地局を介してそれぞれのメディアコンテンツを現在ダウンロードしている場合に、それぞれのサーバー(42)からそれぞれのクライアント(40)へのデータトラフィック内にあるそれぞれのメディア・プレゼンテーション記述(46)に依存して、前記クライアントの各メディアコンテンツ(44)の前記バージョンの品質尺度と最小帯域幅とに少なくとも依存する費用関数が最適化されるように、前記2つ以上の前記ユーザーエンティティ(34)に対する前記通信資源の割り当てを実行する、無線資源管理装置。
[請求項13]
請求項1乃至12のいずれかに記載の無線資源管理装置であって、前記クライアントの受信されたメディア・スループットについてスループット尺度を決定し、前記決定されたスループット尺度に基づいて、前記メディア・プレゼンテーション記述(46)からメディアコンテンツ(44)のどのバージョンが前記少なくとも1つの基地局(32)を介して前記クライアント(44)によって現在ダウンロードされているかを予測する、無線資源管理装置。
[請求項14]
請求項1乃至13のいずれかに記載の無線資源管理装置であって、前記クライアントの受信されたメディア・スループットについてスループット尺度を決定し、前記決定されたスループット尺度に基づいて前記割り当てを実行する、無線資源管理装置。
[請求項15]
請求項13又は14に記載の無線資源管理装置であって、前記割り当てられた通信帯域幅を前記スループット尺度として使用するか、前記ユーザーエンティティ(34)からの品質フィードバックの評価を通じて前記割り当てられた通信帯域幅から前記スループット尺度を推定するか、又は、前記ユーザーエンティティ(34)から前記スループット尺度を受信する、無線資源管理装置。
[請求項16]
請求項1乃至15のいずれかに記載の無線資源管理装置であって、前記クライアント(40)から前記サーバー(42)へのメディア要求(60)を検査することにより、前記メディア・プレゼンテーション記述(46)からメディアコンテンツ(44)のどのバージョンが、前記少なくとも1つの基地局(32)を介して前記クライアント(44)によって現在ダウンロードされているかを決定する、無線資源管理装置。
[請求項17]
請求項1乃至16のいずれかに記載の無線資源管理装置であって、前記クライアント(40)によって要求されたメディアコンテンツのバージョンの履歴を記録し、前記少なくとも1つの基地局(32)の通信資源における逼迫度が減少した場合に、前記履歴を使用して、前記クライアント(40)に対して現在割り当てられている通信資源の量を増加させるように決定する、無線資源管理装置。
[請求項18]
請求項1乃至17のいずれかに記載の無線資源管理装置であって、前記ユーザーエンティティから前記少なくとも1つの基地局へのチャネル品質フィードバックに基づいてユーザーエンティティのバッファ状態をシミュレートするか、前記基地局(32)の反対側もしくは前記基地局(32)内部に位置するメディアコンテンツバッファ(100)を監視するか、又は、前記クライアント(40)から前記サーバー(42)へのデータトラフィック内の明示的な信号伝達から前記バッファ状態を抽出し、前記基地局のダウンリンク通信資源が関係している場合に、前記バッファ状態に依存して前記割り当てを実行する、無線資源管理装置。
[請求項19]
無線資源基地局(32)と通信するユーザーエンティティであって、そのユーザーエンティティ上でクライアント(40)又はサーバー(32)が動作可能であり、前記ユーザーエンティティは、メディアコンテンツ(44)の異なる帯域幅の複数のバージョンを記述するメディア・プレゼンテーション記述(46)を導出するために、前記クライアント(40)と前記サーバー(32)との間のデータトラフィックを調査し、前記ユーザーエンティティが属している複数のユーザーエンティティに前記無線資源基地局(32)の通信資源を割り当てる役割を担う無線資源管理装置(30)に対して、前記メディア・プレゼンテーション記述を少なくとも部分的に転送する、ユーザーエンティティ。
[請求項20]
請求項19に記載のユーザーエンティティであって、前記データトラフィックが伝送されるOSIレイヤよりも低いOSIレイヤ内で前記転送を実行する、ユーザーエンティティ。
[請求項21]
無線資源基地局(32)と通信するユーザーエンティティであって、そのユーザーエンティティ上でクライアント(40)が動作可能であり、前記ユーザーエンティティは、前記クライアントによってサーバー(42)からリトリーブされたメディアコンテンツの受信済みのメディアコンテンツ・スループット又はバッファ状態を決定し、前記ユーザーエンティティに対して前記無線資源基地局(32)の通信資源を割り当てる役割を担う無線資源管理装置(30)に、前記決定されたメディアコンテンツ・スループット又はバッファ状態について通知する、ユーザーエンティティ。
[請求項22]
請求項21に記載のユーザーエンティティであって、前記メディアコンテンツ・リトリーブが伝送されるOSIレイヤよりも低いOSIレイヤ内で前記通知を実行する、ユーザーエンティティ。
[請求項23]
無線資源基地局(32)と通信するためにユーザーエンティティ(34)上で動作可能なクライアントであって、前記クライアント(40)はサーバー(42)からメディア・プレゼンテーション記述とメディアコンテンツ(44)とをリトリーブし、前記メディア・プレゼンテーション記述(46)は前記メディアコンテンツ(44)の異なる帯域幅のバージョンを記述するものであり、前記クライアントは、前記ユーザーエンティティに対して前記無線資源基地局(32)の通信資源を割り当てる役割を担う無線資源管理装置(30)からの信号伝達によって、ノーマルモードからスレーブモードへと切替可能であり、
前記ノーマルモードにおいては、前記ユーザーエンティティに割り当てられた通信資源に基づいて、前記クライアントにより決定されたバージョンにおける前記メディアコンテンツ(44)を前記サーバー(42)から要求し、前記スレーブモードにおいては、前記ユーザーエンティティに割り当てられた通信資源とは無関係に、前記クライアントにより決定されたバージョンにおける前記メディアコンテンツ(44)を前記サーバー(42)から要求する、クライアント。
[請求項24]
請求項23に記載のクライアントであって、前記ノーマルモードにおいて、前記ユーザーエンティティに割り当てられた通信資源と前記メディアコンテンツのバッファ状態とに基づいて、前記クライアントにより決定されたバージョンにおける前記メディアコンテンツ(44)を前記サーバー(42)から要求する、クライアント。
[請求項25]
請求項23又は24に記載のクライアントであって、前記ノーマルモードにおいて、前記ユーザーエンティティに割り当てられた通信資源の量が減少している場合には、前記メディアコンテンツのバッファ状態に基づいて前記クライアントにより決定されたバージョンにおける前記メディアコンテンツ(44)を、その決定されたバージョンが現在決定されているバージョンと比べて低い品質を持つバージョンへと変更されるように、前記サーバー(42)から要求する、クライアント。
[請求項26]
請求項23乃至25のいずれかに記載のクライアントであって、前記スレーブモードにおいて、前記メディア・プレゼンテーション記述(46)の異なる帯域幅の複数のバージョンの中で最も高い帯域幅バージョンに対応するバージョンにおける前記メディアコンテンツ(44)を前記サーバー(42)から連続的に要求する、クライアント。
[請求項27]
資源管理装置であって、
メディアコンテンツ(44)の異なる帯域幅の複数のバージョンを記述しているメディア・プレゼンテーション記述(46)を、サーバー(42)からユーザーエンティティ(34)上で動作しているクライアント(40)へのデータトラフィック内で検査し、
前記メディアコンテンツ(44)の所望のバージョンを要求する、前記クライアント(40)から前記サーバー(42)へのメディア要求(60)を検査し、
現在の資源状態情報と前記メディア・プレゼンテーション記述(46)とに依存して、
−前記サーバーに対し前記メディア要求(60)を転送するか、又は、
−前記メディア要求(60)が前記クライアント(40)に送信されるべき前記メディアコンテンツ(44)の前記所望のバージョンをもたらさない状態とするか、
を決定する、資源管理装置。
[請求項28]
請求項27に記載の資源管理装置において、修正済みのメディア要求が前記メディアコンテンツ(44)のより少ない帯域幅のバージョンを要求する程度に前記メディア要求(60)を修正するか、又は、前記メディア要求(60)をインターセプトして、利用不可の応答を前記サーバー(42)から前記クライアント(40)へと返送するように、前記サーバー(42)に対してエミュレート又は指令することで、前記所望のバージョンをもたらさない状態を実行する、資源管理装置。
[請求項29]
請求項27又は28に記載の資源管理装置において、前記メディア・プレゼンテーション記述(46)を検査し、それにより、前記メディア・プレゼンテーション記述(46)の中で、前記メディアコンテンツ(44)の所望のバージョンとして関連するより低い最小帯域幅を持つメディアコンテンツ(44)のバージョンを識別し、もし前記より低い最小帯域幅を持つバージョンが存在する場合には、前記現在の資源状態情報に依存して前記決定を実行する、資源管理装置。
[請求項30]
請求項27乃至29のいずれかに記載の資源管理装置であって、前記資源管理装置は無線資源管理装置であり、前記クライアントが動作している前記ユーザーエンティティが属する複数のユーザーエンティティに対して少なくとも1つの基地局の通信資源の割り当てを実行する、資源管理装置。
[請求項31]
請求項27乃至30のいずれかに記載の資源管理装置であって、前記ユーザーエンティティ内の送受信ステージ(70)と前記クライアント(40)との間に配置され、前記現在の資源状態情報を前記送受信ステージ(70)から取得する、資源管理装置。
[請求項32]
請求項27乃至31のいずれかに記載の資源管理装置であって、前記ユーザーエンティティから前記基地局へのチャネル品質フィードバックに基づいてユーザーエンティティのバッファ状態をシミュレートし、前記チャネル品質フィードバックは前記現在の資源状態情報に含まれており、前記ユーザーエンティティのバッファ状態に依存して前記決定を実行する、資源管理装置。
[請求項33]
資源管理装置であって、
メディアコンテンツ(44)の異なる帯域幅の複数のバージョンを記述しているメディア・プレゼンテーション記述(46)を、サーバー(42)からユーザーエンティティ(34)において動作しているクライアント(40)へのデータトラフィック内で検査し、
前記メディアコンテンツ(44)の所望のバージョンを要求する、前記クライアント(40)から前記サーバー(42)へのメディア要求(60)を検査し、
前記ユーザーエンティティ(34)から基地局(32)へのチャネル品質フィードバックに基づいてシミュレートするか、前記基地局(32)の反対側もしくは前記基地局(32)の内部に位置するメディアコンテンツバッファ(100)を監視するか、又は前記クライアント(40)から前記サーバー(42)へのデータトラフィック内での明示的な信号伝達から前記ユーザーエンティティのバッファ状態を抽出することにより、前記クライアントについてユーザーエンティティのバッファ状態を取得し、
前記ユーザーエンティティのバッファ状態と前記メディア・プレゼンテーション記述(46)とに依存して、
−前記サーバーに対して前記メディア要求(60)を転送するか、又は、
−前記メディア要求(60)が前記クライアント(40)に送信されるべき前記メディアコンテンツ(44)の前記所望のバージョンをもたらさない状態とするか、
を決定する、資源管理装置。
[請求項34]
請求項33に記載の資源管理装置であって、修正済みのメディア要求が前記メディアコンテンツ(44)のより少ない帯域幅のバージョンを要求する程度に前記メディア要求(60)を修正するか、又は、前記メディア要求(60)をインターセプトして、利用不可の応答を前記サーバー(42)から前記クライアント(40)へと返送するように、前記サーバー(42)に対してエミュレート又は指令することで、前記所望のバージョンをもたらさない状態を実行する、資源管理装置。
[請求項35]
請求項33又は34に記載の資源管理装置であって、現在の資源状態情報にも基づいて前記決定を実行する、資源管理装置。
[請求項36]
請求項35に記載の資源管理装置であって、前記メディア・プレゼンテーション記述(46)を検査し、それにより、前記メディア・プレゼンテーション記述(46)の中で、前記メディアコンテンツ(44)の所望のバージョンとして関連するより低い最小帯域幅を持つメディアコンテンツ(44)のバージョンを識別し、もし前記より低い最小帯域幅を持つバージョンが存在する場合には、前記現在の資源状態情報に依存して前記決定を実行する、資源管理装置。
[請求項37]
請求項33乃至36のいずれかに記載の資源管理装置であって、前記資源管理装置は無線資源管理装置であり、前記クライアントが動作している前記ユーザーエンティティが属する複数のユーザーエンティティに対して、少なくとも1つの基地局の通信資源の割り当てを実行する、資源管理装置。
[請求項38]
請求項33乃至37のいずれかに記載の資源管理装置であって、前記ユーザーエンティティ内の送受信ステージ(70)と前記クライアント(40)との間に配置され、前記現在の資源状態情報を前記送受信ステージ(70)から取得する、資源管理装置。
[請求項39]
請求項33乃至38のいずれかに記載の資源管理装置であって、前記ユーザーエンティティから前記基地局へのチャネル品質フィードバックに基づいてユーザーエンティティのバッファ状態をシミュレートし、前記チャネル品質フィードバックは前記現在の資源状態情報に含まれており、前記ユーザーエンティティのバッファ状態に依存して前記決定を実行する、資源管理装置。
[請求項40]
資源管理装置であって、
ユーザーエンティティ(34)において動作しているクライアント(40)からサーバー(42)へのメディア・プレゼンテーション記述要求を検査し、前記メディア・プレゼンテーション記述要求は前記サーバー(42)からメディア・プレゼンテーション記述(46)を要求するものであり、前記メディア・プレゼンテーション記述(46)はメディアコンテンツ(44)の異なる帯域幅の複数のバージョンを記述しており、
前記サーバー(42)から前記クライアント(40)へのデータトラフィック内の前記メディア・プレゼンテーション記述(46)を検査し、
現在の資源状態情報と前記メディア・プレゼンテーション記述(46)とに基づいて、
−前記メディア・プレゼンテーション記述要求への回答として、前記メディア・プレゼンテーション記述(46)を前記クライアント(40)に転送するか、又は、
−前記メディア・プレゼンテーション記述(46)をインターセプトし、前記メディア・プレゼンテーション記述を修正するか、
を決定する、資源管理装置。
[請求項41]
請求項40に記載の資源管理装置であって、前記メディア・プレゼンテーション記述を修正する際に、前記メディアコンテンツ(44)の平均帯域幅よりも高い帯域幅の1つ又は複数のバージョンを除去するか、又は除去した後で再挿入する、資源管理装置。
[請求項42]
請求項40に記載の資源管理装置であって、前記インターセプト及び修正を実行する際に、
−前記クライアント(40)に対し、メディアバッファ状態情報に関する明示的な信号伝達を、前記サーバー(32)の代わりに前記資源管理装置に対して送信するよう指令するため、
−ユニキャストからマルチキャスト・プロトコルへのプロトコル変更を指示するため、
−前記クライアント(40)に対し、前記資源管理装置が前記メディアコンテンツ(44)を調整する可能性があることを通知するため、
前記メディア・プレゼンテーション記述(46)に対して情報を追加し、
前記情報が追加されたメディア・プレゼンテーション記述を、前記クライアント(40)に対して前記メディア・プレゼンテーション記述要求への回答として送信し、
異なる帯域幅の前記メディアコンテンツ(44)の複数のバージョンの適切な部分集合だけを記述するよう、前記メディア・プレゼンテーション記述(46)を削減し、かつ、その削減されたメディア・プレゼンテーション記述を、前記クライアント(40)に対して前記メディア・プレゼンテーション記述要求への回答として送信する、資源管理装置。
[請求項43]
請求項40乃至42のいずれかに記載の資源管理装置であって、前記メディア・プレゼンテーション記述(46)を検査し、それにより、前記メディア・プレゼンテーション記述(46)の中で、前記メディアコンテンツ(44)の所望のバージョンとして関連するより低い最小帯域幅を持つメディアコンテンツ(44)のバージョンを識別し、もし前記より低い最小帯域幅を持つバージョンが存在する場合には、前記現在の資源状態情報に依存して前記決定を実行する、資源管理装置。
[請求項44]
請求項40乃至43のいずれかに記載の資源管理装置であって、前記資源管理装置は無線資源管理装置であり、前記クライアントが動作している前記ユーザーエンティティが属する複数のユーザーエンティティに対して、少なくとも1つの基地局の通信資源の割り当てを実行する、資源管理装置。
[請求項45]
請求項40乃至44のいずれかに記載の資源管理装置であって、前記ユーザーエンティティ内の送受信ステージ(70)と前記クライアント(40)との間に配置され、前記現在の資源状態情報を前記送受信ステージ(70)から取得する、資源管理装置。
[請求項46]
請求項40乃至45のいずれかに記載の資源管理装置であって、前記ユーザーエンティティから前記基地局へのチャネル品質フィードバックに基づいて前記クライアント(40)に関連するバッファ状態をシミュレートし、前記チャネル品質フィードバックは前記現在の資源状態情報に含まれており、前記バッファ状態に依存して前記決定を実行する、資源管理装置。
[請求項47]
複数のユーザーエンティティの1つにおいて動作しているクライアントのメディアバッファ状態情報に依存して、基地局(32)の通信資源を前記ユーザーエンティティ(34)に対して割り当てる、無線資源管理装置。
[請求項48]
請求項46に記載の無線資源管理装置であって、前記ユーザーエンティティに対する通信資源の割り当てを、
−前記基地局(32)の通信資源が適切な割合で割り当てられるべき前記ユーザーエンティティ(34)の数、
−前記ユーザーエンティティと前記基地局との間で交換されるべき通信データの種類、
−前記ユーザーエンティティに割り当てられたユーザープロファイルであって、前記ユーザーエンティティ間の優先順位を定義するプロファイル、
−前記ユーザーエンティティからのチャネル品質フィードバック、
−前記ユーザーエンティティからのチャネルレート要求、
の内の1つ又は複数に基づいて実行する、無線資源管理装置。
[請求項49]
請求項47に記載の無線資源管理装置であって、前記通信資源を前記ユーザーエンティティに対して割り当てる際に、前記メディアバッファ状態情報に依存して、
−サブキャリア、
−集約されたサブキャリア、
−時間スロット、
−前記基地局セルの空間的カバー範囲、
の内の1つ又は複数を調整する、無線資源管理装置。
[請求項50]
請求項46乃至48のいずれかに記載の無線資源管理装置であって、前記クライアント(40)から前記サーバー(42)へのデータトラフィック内の明示的な信号伝達から前記メディアバッファ状態情報を抽出するか、又は、前記ユーザーエンティティ(34)から前記基地局(32)へのチャネル品質フィードバックに基づいて前記クライアント(40)に関連するバッファ状態をシミュレートすることにより、前記メディアバッファ状態情報を導出する、無線資源管理装置。
[請求項51]
無線資源管理装置であって、
ユーザーエンティティ(34)において動作しているクライアント(40)と1つ又は複数のサーバー(32)との間のデータトラフィックを調査し、
前記1つ又は複数のサーバー(32)から前記クライアント(40)の内の異なるクライアントへの前記データトラフィックの中に、共通のメディアコンテンツ(44)に関連するメディア・プレゼンテーション記述があるか否かをチェックし、
前記チェックに基づいて、前記メディアコンテンツ(44)のユニキャストバージョンのほかに、前記共通のメディアコンテンツ(44)のマルチキャストバージョンを前記クライアント(40)に対して提供するか、又は、前記チェックに基づいて、前記共通のメディアコンテンツをダウンロードしているクライアント(40)に対してユニキャスト・プロトコルからマルチキャスト・プロトコルへプロトコルを変更させる、無線資源管理装置。
[請求項52]
請求項50に無線資源管理装置であって、基地局の通信資源を前記ユーザーエンティティに対して割り当てる、無線資源管理装置。
[請求項53]
少なくとも1つの基地局(32)の通信資源を複数のユーザーエンティティ(34)に対して割り当てる無線資源管理装置であって、
前記ユーザーエンティティの1つにおいて動作しているサーバー(42)若しくはクライアント(40)へのデータトラフィックを調査するか、又は、他の無線資源管理装置からの制御情報を調査することにより、
−前記サーバー(42)と前記クライアント(40)との他方が動作する外部ユーザーエンティティに現在割り当てられている保証付き通信資源と、
−前記サーバー(42)と前記クライアント(40)との他方のバッファ状態と、
に関する情報を取得し、
前記割り当てを前記取得された情報に基づいて実行する、無線資源管理装置。
[請求項54]
請求項52に記載の無線資源管理装置であって、前記ユーザーエンティティ(34)に対して前記少なくとも1つの基地局(32)の通信資源を割り当てる際に、前記ユーザーエンティティに対して保証付きの通信資源を時間区間の単位で割り当て、前記通信資源を前記時間区間内において割り当てる際に、前記保証付き通信資源に従うよう構成されている、無線資源管理装置。
[請求項55]
請求項53に記載の無線資源管理装置であって、
前記サーバー(42)と前記クライアント(40)との一方が動作しているユーザーエンティティに対して割り当てられた保証付き通信資源に関する情報を、前記ユーザーエンティティ(32)の1つにおいて動作しているサーバー(42)又はクライアント(40)からのデータトラフィックの中に挿入する、無線資源管理装置。
[請求項56]
請求項52又は53に記載の無線資源管理装置であって、
前記ユーザーエンティティの1つにおいて動作しているサーバー又はクライアントと、前記サーバーと前記クライアントとの他方と、の間のメディア伝送セッションのセットアップに応じて、前記サーバーと前記クライアントとの他方が、前記無線資源管理装置が属する無線システムの他のいずれかの無線資源管理装置によってサービス提供されている外部ユーザーエンティティ上で動作しているか否かをチェックし、
前記サーバーと前記クライアントとの他方が、前記無線システムの他のいずれかの無線資源管理装置によってサービス提供されている外部ユーザーエンティティ上で動作している場合には、
前記無線システムの前記他の無線資源管理装置に対し、
−前記ユーザーエンティティに対して現在割り当てられている保証付き通信資源と、
−前記サーバー(42)と前記クライアント(40)との一方のバッファ状態と、
を信号伝達する外向きの制御情報を送信し、
前記無線システムの前記他の無線資源管理装置からの、
−前記サーバー(42)と前記クライアント(40)との他方が動作している前記外部ユーザーエンティティに対して現在割り当てられている前記保証付き通信資源と、
−前記サーバー(42)と前記クライアント(40)との他方のバッファ状態と、
についての情報を信号伝達する内向きの制御情報を調査するよう構成されている、無線資源管理装置。
[請求項57]
請求項52乃至55のいずれかに記載の無線資源管理装置であって、前記ユーザーエンティティに対する通信資源の割り当てを、
−前記少なくとも1つの基地局(32)の通信資源が適切な割合で割り当てられるべきユーザーエンティティ(34)の数、
−前記ユーザーエンティティと前記少なくとも1つの基地局との間で交換されるべき通信データの種類、
−前記ユーザーエンティティに割り当てられるユーザープロファイルであって、前記ユーザーエンティティ間の優先順位を定義するプロファイル、
−ユーザーエンティティからのチャネル品質フィードバック、
−ユーザーエンティティからのチャネルレート要求、
の内の1つ又は複数に基づいて実行する、無線資源管理装置。
[請求項58]
請求項52乃至56のいずれかに記載の無線資源管理装置であって、前記ユーザーエンティティに対して通信資源を割り当てる際に、
−サブキャリア、
−時間スロット、
−前記少なくとも1つの基地局セルの空間的カバー範囲、
の内の1つ又は複数を調整する、無線資源管理装置。
[請求項59]
請求項52乃至57のいずれかに記載の無線資源管理装置であって、前記取得された情報に基づいて、
前記サーバー(42)と前記クライアント(40)との他方のバッファ状態が増大している場合には、前記ユーザーエンティティに割り当てられる通信資源の量が減少するように、及び/又は、
前記外部ユーザーエンティティに対して現在割り当てられている前記保証付きの通信資源が減少している場合には、前記ユーザーエンティティに割り当てられる通信資源の量が減少するように、
前記割り当てを実行する、無線資源管理装置。
[請求項60]
無線資源管理の方法であって、
サーバー(42)からクライアント(40)へのデータトラフィック内において転送されるメディアコンテンツ(44)に関連するメディア・プレゼンテーション記述(46)に依存して、少なくとも1つの基地局(32)の通信資源を複数のユーザーエンティティ(34)へと割り当てるステップを含み、前記サーバー(42)と前記クライアント(40)との一方が前記ユーザーエンティティ(32)の1つで動作している、方法。
[請求項61]
クライアント(40)又はサーバー(32)が動作可能であるユーザーエンティティ上で実行される方法であって、前記ユーザーエンティティは無線資源基地局(32)と通信している、方法において、
メディアコンテンツ(44)の異なる帯域幅の複数のバージョンを記述するメディア・プレゼンテーション記述(46)を導出するために、前記クライアント(40)と前記サーバー(32)との間のデータトラフィックを調査するステップと、
前記ユーザーエンティティが属している複数のユーザーエンティティに対して前記無線資源基地局(32)の通信資源を割り当てる役割を担う無線資源管理装置(30)に対し、前記メディア・プレゼンテーション記述を少なくとも部分的に転送するステップと、
を含む方法。
[請求項62]
クライアント(40)が動作可能であるユーザーエンティティ上で実行される方法であって、前記ユーザーエンティティは無線資源基地局(32)と通信している、方法において、
前記クライアントによってサーバー(42)からリトリーブされたメディアコンテンツの受信されたメディアコンテンツ・スループット又はバッファ状態を決定するステップと、
前記ユーザーエンティティに対して前記無線資源基地局(32)の通信資源を割り当てる役割を担う無線資源管理装置(30)に対し、前記決定されたメディアコンテンツ・スループット又はバッファ状態について通知するステップと、
を含む方法。
[請求項63]
メディアコンテンツ(44)の異なる帯域幅の複数のバージョンを記述しているメディア・プレゼンテーション記述(46)を、サーバー(42)からユーザーエンティティ(34)において動作しているクライアント(40)へのデータトラフィック内で検査するステップと、
前記メディアコンテンツ(44)の所望のバージョンを要求する、前記クライアント(40)から前記サーバー(42)へのメディア要求(60)を検査するステップと、
現在の資源状態情報と前記メディア・プレゼンテーション記述(46)とに依存して、
−前記サーバーに対して前記メディア要求(60)を転送するか、又は、
−前記メディア要求(60)が前記クライアント(40)に送信されるべき前記メディアコンテンツ(44)の前記所望のバージョンをもたらさない状態とするか、
を決定するステップと、
を含む方法。
[請求項64]
メディアコンテンツ(44)の異なる帯域幅の複数のバージョンを記述しているメディア・プレゼンテーション記述(46)を、サーバー(42)からユーザーエンティティ(34)において動作しているクライアント(40)へのデータトラフィック内で検査するステップと、
前記メディアコンテンツ(44)の所望のバージョンを要求する、前記クライアント(40)から前記サーバー(42)へのメディア要求(60)を検査するステップと、
前記ユーザーエンティティ(34)から基地局(32)へのチャネル品質フィードバックに基づいてシミュレートするか、前記基地局(32)の反対側又は前記基地局(32)の内部に位置するメディアコンテンツバッファ(100)を監視するか、又は前記クライアント(40)から前記サーバー(42)へのデータトラフィック内での明示的な信号伝達から前記ユーザーエンティティのバッファ状態を抽出することにより、前記クライアントについてのユーザーエンティティのバッファ状態を取得するステップと、
前記ユーザーエンティティのバッファ状態と前記メディア・プレゼンテーション記述(46)とに依存して、
−前記サーバーに対して前記メディア要求(60)を転送するか、又は、
−前記メディア要求(60)が前記クライアント(40)に送信されるべき前記メディアコンテンツ(44)の前記所望のバージョンをもたらさない状態とするか、
を決定するステップと、
を含む方法。
[請求項65]
ユーザーエンティティ(34)において動作しているクライアント(40)からサーバー(42)へのメディア・プレゼンテーション記述要求を検査するステップであって、前記メディア・プレゼンテーション記述要求は前記サーバー(42)からメディア・プレゼンテーション記述(46)を要求するものであり、前記メディア・プレゼンテーション記述(46)はメディアコンテンツ(44)の異なる帯域幅の複数のバージョンを記述するものである、ステップと、
前記サーバー(42)から前記クライアント(40)へのデータトラフィック内の前記メディア・プレゼンテーション記述(46)を検査するステップと、
現在の資源状態情報と前記メディア・プレゼンテーション記述(46)とに基づいて、
−前記メディア・プレゼンテーション記述要求への回答として、前記メディア・プレゼンテーション記述(46)を前記クライアント(40)に転送するか、又は、
−前記メディア・プレゼンテーション記述(46)をインターセプトし、前記メディア・プレゼンテーション記述を修正するか、
を決定するステップと、
を含む方法。
[請求項66]
無線資源管理の方法であって、
複数のユーザーエンティティ(34)において動作している複数のクライアント(40)と1つ又は複数のサーバー(32)との間のデータトラフィックを調査するステップと、
前記1つ又は複数のサーバー(32)から前記クライアント(40)の内の異なるクライアントへの前記データトラフィックの中に、共通のメディアコンテンツ(44)に関連するメディア・プレゼンテーション記述があるか否かをチェックするステップと、
前記チェックに基づいて、前記メディアコンテンツ(44)のユニキャストバージョンのほかに、前記共通のメディアコンテンツ(44)のマルチキャストバージョンを前記クライアント(40)に対して提供するか、又は、前記チェックに基づいて、前記共通のメディアコンテンツをダウンロードしているクライアント(40)に対してユニキャスト・プロトコルからマルチキャスト・プロトコルへのプロトコル変更を生じさせるステップと、
を含む方法。
[請求項67]
少なくとも1つの基地局(32)の通信資源を複数のユーザーエンティティ(34)に対して割り当てる方法であって、
前記ユーザーエンティティの1つにおいて動作しているサーバー(42)若しくはクライアント(40)へのデータトラフィックを調査するか、又は、少なくとも1つの異なる基地局へ通信資源を割り当てる他の無線資源管理装置からの制御情報を調査することにより、
−前記サーバー(42)と前記クライアント(40)との他方が動作する外部ユーザーエンティティに現在割り当てられている保証付き通信資源と、
−前記サーバー(42)と前記クライアント(40)との他方のバッファ状態と、
に関する情報を取得するステップと、
前記割り当てを前記取得された情報に基づいて実行するステップと、
を含む方法。
[請求項68]
コンピュータ上で作動されたとき、請求項59乃至66のいずれかに記載の方法を実行するためのプログラムコードを有するコンピュータプログラム。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17