特許 6560413 ネットワーク資源を管理する装置及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6560413

(24)【登録日】2019年7月26日

(45)【発行日】2019年8月14日

(54)【発明の名称】ネットワーク資源を管理する装置及び方法

(51)【国際特許分類】

   H04W 72/08 20090101AFI20190805BHJP

   H04W 72/04 20090101ALI20190805BHJP

   H04W 4/06 20090101ALI20190805BHJP

【ＦＩ】

   H04W72/08

   H04W72/04 110

   H04W4/06 171

【請求項の数】18

【全頁数】78

(21)【出願番号】特願2018-137313(P2018-137313)

(22)【出願日】2018年7月23日

(62)【分割の表示】特願2017-229751(P2017-229751)の分割

【原出願日】2012年10月22日

(65)【公開番号】特開2018-198433(P2018-198433A)

(43)【公開日】2018年12月13日

【審査請求日】2018年7月23日

(31)【優先権主張番号】61/550,126

(32)【優先日】2011年10月21日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】500341779

【氏名又は名称】フラウンホーファー−ゲゼルシャフト・ツール・フェルデルング・デル・アンゲヴァンテン・フォルシュング・アインゲトラーゲネル・フェライン

(74)【代理人】

【識別番号】100085497

【弁理士】

【氏名又は名称】筒井 秀隆

(72)【発明者】

【氏名】シール，トーマス

(72)【発明者】

【氏名】ヴィルス，トーマス

(72)【発明者】

【氏名】ハウスタイン，トーマス

(72)【発明者】

【氏名】サンチェス，ヤーゴ

【審査官】 望月 章俊

(56)【参考文献】

【文献】 特開２００７−６４７６（ＪＰ，Ａ）

【文献】 特開２００３−２０４５７５（ＪＰ，Ａ）

【文献】 特開２０１１−８２８０８（ＪＰ，Ａ）

【文献】 特開２００５−１４２８０８（ＪＰ，Ａ）

【文献】 特表２００６−５２１０３５（ＪＰ，Ａ）

【文献】 特表２００７−５２０９０５（ＪＰ，Ａ）

【文献】 欧州特許出願公開第１２９８９３１（ＥＰ，Ａ２）

【文献】 国際公開第２０１１／０１５２４３（ＷＯ，Ａ１）

【文献】 国際公開第２０１１／０８７４４９（ＷＯ，Ａ１）

【文献】 Telefon AB LM Ericsson, ST-Ericsson SA，IMS based Adaptive HTTP Streaming， 3GPP TSG-SA WG4#61 S4-100783，２０１０年１１月

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｗ４／００−Ｈ０４Ｗ９９／００

Ｈ０４Ｂ７／２４−Ｈ０４Ｂ７／２６

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

サーバーとクライアントとの一方がユーザー装置の１つで動作している状態で、前記サーバーから前記クライアントへとネットワーク資源を介して転送されたメディアコンテンツに関連するメディアコンテンツ記述に依存して、前記ネットワーク資源を前記ユーザー装置に対して割り当てるよう構成されたマイクロプロセッサまたはプログラムされたコンピュータを備える、ネットワーク資源を管理する装置であって、
前記装置はさらに、
前記メディアコンテンツ記述が、前記ネットワーク資源を介して前記クライアントによって現在ダウンロードされている前記メディアコンテンツのバージョンよりも低い最小帯域幅を持つ前記メディアコンテンツのバージョンの利用可能性を示すかどうかを、検査するよう構成され、前記装置は、前記低い最小帯域幅を持つバージョンが存在するか否かに依存して、前記ユーザー装置に対する前記ネットワーク資源の割り当てを実行するよう構成され、
前記低い最小帯域幅を持つバージョンが存在するか否かに依存した前記ユーザー装置に対する前記ネットワーク資源の割り当ては、前記低い最小帯域幅を持つ前記バージョンが存在するときには、前記低い最小帯域幅を持つバージョンが存在しないときと比較して、１つのユーザー装置に対して割り当てられる前記ネットワーク資源が低くなるように、構成されている、
ネットワーク資源を管理する装置。

【請求項2】

サーバーとクライアントとの一方がユーザー装置の１つで動作している状態で、前記サーバーから前記クライアントへとネットワーク資源を介して転送されたメディアコンテンツに関連するメディアコンテンツ記述に依存して、前記ネットワーク資源を前記ユーザー装置に対して割り当てるよう構成されたマイクロプロセッサまたはプログラムされたコンピュータを備える、ネットワーク資源を管理する装置であって、
前記装置はさらに、
前記メディアコンテンツ記述が、前記ネットワーク資源を介して前記クライアントによって現在ダウンロードされている前記メディアコンテンツのバージョンよりも高い最小帯域幅を持つ前記メディアコンテンツのバージョンの利用可能性を示すかどうかを、検査するよう構成され、前記装置は、前記高い最小帯域幅を持つバージョンが存在するか否かに依存して、前記ネットワーク資源を前記ユーザー装置に対して割り当てるよう構成され、
前記高い最小帯域幅を持つバージョンが存在するか否かに依存した前記ユーザー装置に対する前記ネットワーク資源の割り当ては、前記高い最小帯域幅を持つ前記バージョンが存在するときには、前記高い最小帯域幅を持つバージョンが存在しないときと比較して、１つのユーザー装置に対して割り当てられる前記ネットワーク資源が高くなるように、構成されている、
ネットワーク資源を管理する装置。

【請求項3】

前記装置は、前記メディアコンテンツ記述に依存してダウンリンク・ネットワーク資源を前記ユーザー装置に対して割り当てるよう構成されており、前記クライアントが前記ユーザー装置の１つで動作している、請求項１又は２に記載の装置。

【請求項4】

前記装置は、前記メディアコンテンツ記述に依存してアップリンク・ネットワーク資源を前記ユーザー装置に対して割り当てるよう構成されており、前記サーバーが前記ユーザー装置の１つで動作している、請求項１又は２に記載の装置。

【請求項5】

前記メディアコンテンツ記述を得るために、前記サーバーから前記クライアントへのデータトラフィックを調査するよう構成されている、請求項１又は２に記載の装置。

【請求項6】

前記ユーザー装置から前記メディアコンテンツ記述を受信するよう構成されている、請求項１又は２に記載の装置。

【請求項7】

前記メディアコンテンツ記述は、前記クライアントへストリーミングされるために前記サーバーで利用可能なメディアコンテンツの各バージョンについて、前記メディアコンテンツの各バージョンの品質尺度および最小帯域幅を含んでいる、請求項１又は２に記載の装置。

【請求項8】

前記ユーザー装置に対する前記ネットワーク資源の割り当てを、
−前記ネットワーク資源が割り当てられるべき前記ユーザー装置の数、
−前記ユーザー装置とサードパーティとの間で前記ネットワーク資源を介して交換されるべき通信データの種類、
−前記ユーザー装置に割り当てられたユーザーのプロファイルであって、前記ユーザー装置の中での優先順位を定義しているプロファイル、
−前記ユーザー装置からのチャネル品質フィードバック、
−前記ユーザー装置からのチャネルレート要求、
の内の１つ又は複数に基づいて実行するよう構成される、請求項１又は２に記載の装置。

【請求項9】

前記ユーザー装置に対して前記ネットワーク資源を割り当てる際に、前記メディアコンテンツ記述に依存して、
−サブキャリア、
−時間スロット、
−少なくとも１つの基地局セルの空間的カバー範囲、
の内の１つ又は複数を調整するよう構成される、請求項１又は２に記載の装置。

【請求項10】

前記ネットワーク資源が割り当てられる２つ以上の前記ユーザー装置のクライアントが、前記ネットワーク資源を介して個々のメディアコンテンツを現在ダウンロードしている場合に、個々のサーバーから個々のクライアントへと前記ネットワーク資源を介して転送されている個々のメディアコンテンツを記述する個々のメディアコンテンツ記述に依存して、前記クライアントの各メディアコンテンツの前記バージョンの品質尺度と最小帯域幅とに少なくとも依存する費用関数が最適化されるように、前記２つ以上の前記ユーザー装置に対する前記ネットワーク資源の割り当てを実行するよう構成されている、
請求項１又は２に記載の装置。

【請求項11】

前記クライアントの受信されたメディア・スループットについてスループット尺度を決定し、前記決定されたスループット尺度から、前記メディアコンテンツ記述からメディアコンテンツのどのバージョンが前記ネットワーク資源を介して前記クライアントによって現在ダウンロードされているかについて予測するよう構成されている、
請求項１又は２に記載の装置。

【請求項12】

前記クライアントの受信されたメディア・スループットについてスループット尺度を決定し、前記決定されたスループット尺度に応じて前記割り当てを実行するよう構成されている、
請求項１又は２に記載の装置。

【請求項13】

割り当てられたネットワーク資源帯域幅を前記スループット尺度として使用し、
前記ユーザー装置からの品質フィードバックの評価を用いて、前記割り当てられたネットワーク資源帯域幅から前記スループット尺度を推定し、又は
前記ユーザー装置から前記スループット尺度を受け取る、
の１つを実行するよう構成される、請求項１１に記載の装置。

【請求項14】

前記クライアントから前記サーバーへのメディア要求を検査することにより、前記メディアコンテンツ記述から、前記ネットワーク資源を介して前記クライアントにより現在ダウンロードされている前記メディアコンテンツのバージョンを決定するようさらに構成されている、
請求項１又は２に記載の装置。

【請求項15】

前記ネットワーク資源の需要が減少した場合に、前記クライアントによって要求された前記メディアコンテンツのバージョンの履歴を記録し、さらにその履歴を使用して、前記クライアントに割り当てられるネットワーク資源の量を増加させることを決定するよう構成されている。
請求項２に記載の装置。

【請求項16】

ネットワーク資源を管理する方法であって、
サーバーとクライアントとのうちの１つがユーザー装置の１つで動作している状態で、前記サーバーから前記クライアントへとネットワーク資源を介して転送されるメディアコンテンツに関連するメディアコンテンツ記述に依存して、前記ネットワーク資源を前記ユーザー装置に対して割り当てるステップと、
前記メディアコンテンツ記述が、前記クライアントによって前記ネットワーク資源を介して現在ダウンロードされている前記メディアコンテンツのバージョンよりも低い最小帯域幅を持つ前記メディアコンテンツのバージョンの利用可能性を示すかどうかを、検査するステップであって、前記ネットワーク資源の前記ユーザー装置に対する割り当ては、前記低い最小帯域幅を持つバージョンが存在するか否かに依存して実行される、ステップと、
前記低い最小帯域幅を持つバージョンが存在するか否かに依存した前記ユーザー装置に対する前記ネットワーク資源の割り当てを、前記低い最小帯域幅を持つ前記バージョンが存在するときには、前記低い最小帯域幅を持つバージョンが存在しないときと比較して、１つのユーザー装置に対して割り当てられる前記ネットワーク資源が低くなるように、実行するステップと、
を有するネットワーク資源を管理する方法。

【請求項17】

ネットワーク資源を管理する方法であって、
サーバーとクライアントとのうちの１つがユーザー装置の１つで動作している状態で、前記サーバーから前記クライアントへとネットワーク資源を介して転送されるメディアコンテンツに関連するメディアコンテンツ記述に依存して、前記ネットワーク資源を前記ユーザー装置に対して割り当てるステップと、
前記メディアコンテンツ記述が、前記クライアントによって前記ネットワーク資源を介して現在ダウンロードされている前記メディアコンテンツのバージョンよりも高い最小帯域幅を持つ前記メディアコンテンツのバージョンの利用可能性を示すかどうかを、検査するステップであって、前記ネットワーク資源の前記ユーザー装置に対する割り当ては、前記高い最小帯域幅を持つバージョンが存在するか否かに依存して実行されるステップと、
前記高い最小帯域幅を持つバージョンが存在するか否かに依存した前記ユーザー装置に対する前記ネットワーク資源の割り当てを、前記高い最小帯域幅を持つ前記バージョンが存在するときには、前記高い最小帯域幅を持つバージョンが存在しないときと比較して、１つのユーザー装置に対して割り当てられる前記ネットワーク資源が高くなるように、実行するステップと、
を有するネットワーク資源を管理する方法。

【請求項18】

コンピュータ上で作動されたとき、請求項１６又は１７に記載の方法を実行するためのプログラムコードを有するコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は無線ネットワークにおけるネットワーク無線情報資源（リソース）管理のような資源管理に関する。

【背景技術】

【0002】

近年、インターネットを通じたマルチメディアの配信は急激に増加しており、ネットワーク内における帯域幅の主要な消費者となってきた。このような増加と並行して、モバイルネットワークにおける大いなる進歩により、３ＧＰＰの高速ダウンリンク・パケットアクセス(ＨＳＤＰＡ)や、発展しつつある長期進化版（ＬＴＥ）ネットワークなどの、高速アクセスネットワークが出現した。

【0003】

モバイルネットワークにおける発展とともに、ＩＰサービスは、日々の生活の中で至る所に存在する事実となるよう期待されている。近年の研究によると、マルチメディア・コンテンツの消費、特にビデオストリーミングは、増大し続けると考えられており（非特許文献１を参照）、これはモバイルネットワークの進化の結果とも考えられる。事実、非特許文献２によれば、モバイルネットワークにおけるデータトラフィックの約５０％はビデオデータであり、２０１５年までに世界中の移動データトラフィックの３分の２がビデオになると予測されている。

【0004】

ＨＴＴＰストリーミングは、最近の数年内に登場した前途有望なマルチメディア・アプリケーションの内の１つであり、市場による受け入れが想定外に良好なものである。この点については、様々な標準化団体、例えばＭＰＥＧ（非特許文献３を参照）及び３ＧＰＰ（非特許文献４を参照）や、又は独占ソリューションであるＩＩＳスムーズ・ストリーミング（非特許文献５を参照）及びＨＴＴＰライブ・ストリーミング（非特許文献６を参照）などによって実行されている、適応的ＨＴＴＰストリーミングに関する標準化活動からも明らかである。

【0005】

メディア・ストリーミングは、ＲＴＰ／ＵＤＰと、その低い待ち時間ゆえに事前に関連付けられてきたが、メディア配信に関してＨＴＴＰ／ＴＣＰに依存することは、過酷な遅延制限を考慮しなくてよいシナリオにおいては、非常に貴重なソリューションとなることが分ってきた。なぜなら、ＲＴＰ／ＵＤＰでは典型的な、ＮＡＴ及びファイアウォール内を横断する問題が存在しないからである。

【0006】

ＨＴＴＰを介するダイナミック適応ストリーミング(ＤＡＳＨ）（非特許文献３を参照）は登場しつつあるＭＰＥＧ標準であり、ＨＴＴＰを用いたマルチメディア配信のためのフォーマットを定義するものである。それは基本的に２つの構成要素からなる。即ち、ダウンロードされるべきメディアのフォーマットと、ダウンロードされるべきメディアの記述とである。現存する独占ソリューションは、類似の手法に基づいている。

【0007】

メディアフォーマットは、基本的にセグメントと呼ばれるビデオの典型的には小さな時間区間の中で構築されており、それらセグメントは、連続的にダウンロードされた場合にメディアの連続的な表現を可能にする。さらに、通常、メディアの様々なビットレートにおける様々な表現（例えばエンコード）がサーバーにおいて利用可能であるため、ユーザー主導の適応、即ち検知されたネットワーク・スループットに基づいてユーザーが表現を選択できる適応が可能となっている。異なる時間区間についての異なる表現のセグメントをダウンロードすることが許可されているため、結果的に、以下に記載するメディア・プレゼンテーション記述(ＭＰＤ）内に提示された全ての切り替え制限が遵守される場合には、完全に再生可能なメディアとなるであろう。

【0008】

ＤＡＳＨにおいて、フォーマットの記述はＭＰＤによって与えられる。ＭＰＤはＸＭＬドキュメントであり、データと、特にサーバーにおいて利用可能なセグメントとを記述する。ＭＰＤを使用することで、クライアントは、彼らのネットワーク・スループット又は彼らの条件に適合する要求を作成するために必要な情報を入手できる。

【0009】

ＤＡＳＨにおいて、クライアントは適応を実行する責任がある。ユーザーの利益と機器能力とネットワークの現在の状態とに基づいて、ＤＡＳＨのクライアントは、ＭＰＤ内に記述された表現であって、クライアントの要件／能力に最も適合する表現を選択しなければならない。ＤＡＳＨアーキテクチャの一例を図１に示す。

【0010】

図１から分かるように、ＤＡＳＨの環境に参加しているエンティティは、ＤＡＳＨサーバー１０であって、それぞれのＤＡＳＨクライアント１２に対して配信されるべきそのメディアコンテンツをあるＤＡＳＨコンテンツ準備ステージ１４から受信するサーバー１０と、ＤＡＳＨクライアント１２自身と、「ＨＴＴＰキャッシュ(Cache)」と示されるネットワーク１６を介してＤＡＳＨサーバー１０とＤＡＳＨクライアント１２とを相互に接続するネットワークと、である。図３に示すように、ＤＡＳＨクライアントがＤＡＳＨサーバー１０からメディア・プレゼンテーション記述ＭＰＤ１８を受信する場合、ＤＡＳＨクライアントは、テレビ装置、コンピュータ又はその他の適切なユーザー端末上で作動してもよく、そのＭＰＤ１８は、ＤＡＳＨコンテンツ準備ステージ１４によってメディアコンテンツのバージョンとともに生成されていたものであって、ＤＡＳＨサーバー１０において利用可能なメディアコンテンツの種々のバージョンを記述するよう生成されたものである。

【0011】

図２は、ＤＡＳＨ標準「ＩＳＯ／ＩＥＣ ２３００９−１」からのエンティティを使用するＬＴＥネットワークにおけるＤＡＳＨの展開アーキテクチャの現状技術を示す。白色のボックスはＤＡＳＨのシステムを表し、影付きのボックスはＬＴＥのシステムを表す。より詳細には、ＤＡＳＨのインフラストラクチャをＬＴＥネットワークへと伝送する際に、ＤＡＳＨクライアント１２は、ＬＴＥ基地局２０と無線チャネル２２とユーザーエンティティ（ユーザー装置）２４との連鎖を介してＨＴＴＰキャッシュ１６へと接続されることが示されており、また、無線資源管理部２６は基地局２０に含まれており、ユーザーエンティティ２４は携帯電話やその他などの移動端末であってもよく、そこでは、ＤＡＳＨクライアント１２が例えばそのユーザーエンティティのプロセッサ上で実行するソフトウエアの形態で作動していてもよい。ＤＡＳＨクライアント１２とＬＴＥｅＮＢ（ＬＴＥに対応した基地局機器)２０とは、メディア・プレゼンテーション記述（ＭＰＤ１８）に対するアクセスを有すると推定される。ＭＰＤ１８は、ユーザー１２に対するストリーミング・サービスを提供するのに十分な、サーバー１０にあるビデオ表現に関する情報を、ユーザーが要求するセグメントによって、ＴＣＰ／ＩＰを伝送プロトコルとして使用しながら、ＨＴＴＰサーバー１０から供給する。最初に、ＤＡＳＨクライアント１２はＨＴＴＰサーバー１０に対してＨＴＴＰゲット要求を伝送する。ＨＴＴＰハンドシェーク（初期接続）の後で、サーバー１０とクライアント１２との間のＴＣＰトンネルが確立する。このＴＣＰトンネルは、基底にある物理的なトランスポートレイヤに関してはトランスペアレントである。ＭＰＤ１８によって供給される情報に依存して、ＤＡＳＨクライアント１２は、包含されたメディアデータを適切に逆多重化、復号化及びレンダリングするために十分な情報を得る。

【0012】

図２で説明するシナリオに含まれる問題は、ＤＡＳＨクライアント１２の通常の挙動である。即ち、各ＤＡＳＨクライアント１２が、各サーバー１０に存在するメディアコンテンツのバージョンのうちそのユーザーに対して現時点で割り当てられた通信資源において、即ち無線資源管理部２６によって各ＤＡＳＨクライアント１２のユーザーエンティティ２４に対して割り当てられた通信資源において、最高の品質及び／又は情報コンテンツを有するバージョンを供給するよう求めることである。「最高の」品質／情報コンテンツとは、最大空間解像度、最大数のビュー、最大幅深度などを有するものであってもよく、その結果、最も高い帯域幅を必要とする。換言すれば、各ＤＡＳＨクライアント１２は、基地局２６の利用可能な無線資源を最大限に使用しようとするものであり、基地局と無線資源管理部２６とはそれぞれ、各ユーザーエンティティの各ＤＡＳＨクライアントが取得したいと欲する、メディアコンテンツの利用可能なより高レベルのバージョンのうちの１つを得るための、割り当てられた通信資源を増大させようとする絶え間ない要求に対処しなければならない。当然ながら、このことは、ユーザーエンティティに対する無線通信資源の次善的な分配を招くことになり、その場合、分配又はスケジューリングは、現在のチャネル状態と個々のユーザーエンティティ２４に割り当てられたユーザープロファイルとに基づいて実行される。

【先行技術文献】

【非特許文献】

【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】ＤＡＳＨアーキテクチャの一例のブロック図である。

【図2】ＬＴＥネットワーク内のＤＡＳＨに関する現在の展開アーキテクチャを示すブロック図であり、実線で描かれた白色のボックスはＤＡＳＨの標準で指定された装置を示し、破線で描かれた白色のボックスは概念的又はトランスペアレントである。

【図3】無線資源管理部を含む例示的な無線資源環境のブロック図であり、本発明に係る無線資源管理部の種々の実施形態を、これに基づいて説明する図である。

【図4】メディアレート対瞬時レート対セグメント・ダウンロードレートを示すグラフである。

【図5】図３の無線資源管理部の第１実施例の可能性のある一構成を示す図である。

【図6】無線資源管理部を含む他の例示的な無線資源環境のブロック図であり、本発明に係る無線資源管理部の種々の実施形態を説明する図である。

【図7】無線資源管理部を含むユーザーエンティティのブロック図であり、本発明に係る無線資源管理部の種々の実施形態を説明する図である。

【図8】図６の無線資源管理部の一実施例の可能性のある一構成を示す図である。

【図9】図３及び図６の無線資源管理部の一実施例の可能性のある一構成を示す図である。

【図10】図７の実施形態における使用に適切なクライアントの可能性のある一構成を示す図である。

【図11】図１０の資源管理部を含む例示的な無線資源環境のブロック図である。

【図12】図３又は図６に係る資源管理部を含む他の例示的な無線資源環境のブロック図である。

【図13】クライアントとサーバーとの間のデータ経路の一部の可能性のある一構成を示し、クライアントの可能な一構成を含むブロック図である。

【図14】一方のユーザーエンティティにおいてサーバーが作動し、他方のユーザーエンティティにおいて対応するクライアントが動作するようなシナリオにおいて実行される、一実施形態に従う一連のステップを示す。

【図15】クライアントが動作するユーザーエンティティの資源管理部がＭＰＤ解析の無線資源管理部の負担を軽減させるようなシナリオにおいて実行される、一連のステップを示す。

【図16】アップリンク（上り回線）通信資源を割り当てる無線資源管理部を含む例示的な無線資源環境の一実施形態に従うブロック図である。

【図17】他の実施形態に係る無線資源管理部のシステムを示す。

【発明を実施するための形態】

【0018】

図３は本願に係る無線資源管理部の第１の実施形態を示す。図３の無線資源管理部は、全体的には参照符号３０で示され、基地局３２の通信資源をユーザーエンティティに対して割り当てるよう構成されており、ユーザーエンティティの１つが符号３４を用いて代表的に示される。ユーザーエンティティ３４は、例えば携帯電話、ラップトップ又はその他の移動端末であるが、静止したデバイスであってもよい。ユーザーエンティティ３４は、基地局３２と、１つ又は複数のアンテナ（図示せず）を介する無線チャネル３６を通して通信することができる。基地局３２は、通信データ、即ちダウンリンク（下り回線）データ及びアップリンクデータの、チャネル３６上への多重化を適切に管理することができ、また、１つ又は複数のアンテナ（図示せず）を有することができる。特に、基地局３２は、様々なユーザーエンティティ３４のためのダウンリンクデータを、基地局３２により出力される伝送信号上に適切に多重化できる。この目的で、種々の多重化方式が使用可能である。例えば、基地局３２は、ＯＦＤＭ、特にＬＴＥを使用しても良い。いずれの場合にも、基地局３２は、ユーザーエンティティ３４を含むユーザーエンティティに対し、通信チャネルの通信資源を時間的に変化する方法で分配又は割り当てることができるため、ユーザーエンティティに対する基地局３２の通信資源の割り当て、即ち特にスケジューリングと呼ばれる割り当てを、現在の資源状態に対して適応させることができる。例えば基地局３２は、そのスケジューリングを実行するために、以下のパラメータの任意の組合せを用いてもよい。
１）基地局３２によってサービス提供されるユーザーエンティティの数、即ち基地局３２における登録を行ったユーザーエンティティ３４の数であり、従って、それらの間で基地局の通信資源が分配されるべきユーザーエンティティ３４の数。
２）個々のユーザーエンティティと交換されるべき通信データの種類であって、その通信データの種類は、例えばスピーチ信号のようなリアルタイム（低遅延）メディアデータを、ＨＴＴＰの要求されたデータやその他から区別するものである。
３）サービス提供されるユーザーエンティティに割り当てられるユーザープロファイルであって、それらプロファイルは、例えばダウンリンク及び／又はアップリンクのために、異なる最大ビットレート及び／又は最小ビットレートが割り当てられるか、又は、ユーザーエンティティ間の優先順位を定義するものであり、その場合、ＲＲＭ（無線資源管理部）３０は、通信資源を割り当てるに際し、より高位の優先順位を持つユーザーエンティティをより低位の優先順位を持つユーザーエンティティよりも優先させる。
４）ユーザーエンティティからのチャネル品質フィードバックであって、ユーザーの現在の受信品質状態、即ち、基地局３２を一方とし、サービス提供される個々のユーザーエンティティ３４を他方とするチャネルの品質を示しており、基地局３２は、例えばユーザーエンティティからのそれぞれのチャネルフィードバック信号によってチャネル品質を測定する。
５）ユーザーエンティティからのチャネルレート要求であって、ユーザーエンティティが更なる帯域幅の割り当てを希望していることを示す。

【0019】

２つ以上の基地局３２と３８とが１つのユーザーエンティティにサービス提供する場合、上述の数は、ある範囲内のユーザーエンティティに対して現在サービス提供している、又は少なくともサービス提供のために利用可能である、全ての基地局によってサービス提供されるユーザーエンティティの数に関係する。通信資源の割り当てを決定する際には、これら基地局間の相互作用も考慮されてよい。そのようなシナリオにおいては、ＲＲＭ３０によってアグリゲートされたサブキャリアのような情報、又は、ＲＲＭ３０によって導出されたセル間のハンドオ−バー(受渡し）のようなユーザーエンティティ３４についての情報は、更に基地局３２と３８との間で共有されることができ、また、より高いレベルのＲＲＭ３０によって収集されかつ使用されてもよい。

【0020】

基地局３２は、ユーザーエンティティに対して通信資源を異なるように割り当てるために、異なる選択肢／パラメータを有していてもよい。この点は、ダウンリンクとアップリンクの両方の通信に関して当てはまる。例えば基地局３２は、以下の設定の任意の組合せによってスケジューリングを構成できる。
１）サービス提供されるユーザーエンティティに対する、ＯＦＤＭサブキャリアのようなサブキャリアの関連付け。典型的には、ＬＴＥにおいて使用されるサブキャリアの最大数は、２０ＭＨｚの帯域幅である。当然ながら、この点は変更可能である。先進ＬＴＥ（LTE-Advanced）と呼ばれるＬＴＥの後継版については、２０ＭＨｚから１００ＭＨｚまでの多数のキャリアが審議中となっている。これはキャリア・アグリゲーションと呼ばれている。つまり、サブキャリアはまた、アグリゲートされたサブキャリアであってもよい。
２）サービス提供されるユーザーエンティティに対する時間スロットの割り当て又は分配。
３）基地局セルの空間的カバー範囲(spatial coverage)であって、その中ではユーザーエンティティが基地局３２と通信可能であるべき範囲であり、この空間的カバー範囲は、例えばＭＩＭＯ技術を使用して変更し得るものである。
４）個々のサブキャリアの変調コンステレーション(modulation constellations)に対する関連付け。

【0021】

上述の設定選択肢のいずれかによってスケジューリングを構成しない場合には、基地局３２は、それぞれの伝送特性を使用しないか、又は、代わりに固定的な設定を使用してもよい。例えば、基地局３２は、ダウンリンク内で時分割多重化を使用しなくてもよく、アップリンク内で時分割多重化を使用しなくてもよく、又は、それぞれの時分割多重化が時間に亘って固定化されていてもよい。同様のことが、サブキャリアの割り当てを含む、周波数分割多重化のＭＩＭＯ機能に関しても当てはまる。

【0022】

いずれの場合でも、割り当てられた通信資源に依存して、各ユーザーエンティティ３４はダウンリンクとアップリンクとの両方に関し効率的な伝送帯域幅を得ることができる。

【0023】

軽微な点であるが、図３の無線資源管理部３０は、基地局３２に含まれてもよく、その一部であってもよく、又は収容されていてもよい点に注意すべきである。しかしながら、無線資源管理部３０はまた、基地局３２から物理的に分離して配置されてもよい。特に、無線資源管理部３０は、所定の基地局と特別に関連付けられていないこともあり得る。むしろ無線資源管理部３０は、より多数のユーザーエンティティに対する無線資源管理を実行でき、結果として、２つ以上の基地局からなるセルをもたらすこともできる。例えば、図３は任意の他の基地局３８を示し、その通信資源もまた任意ではあるが、無線資源管理部３０によって制御されていてもよい。特に、基地局３２及び３８と無線資源管理部３０とが一緒になり、無線ネットワークを形成して、２つ以上の基地局によるサービス提供をユーザーエンティティが同時に受けられるようにすることも可能である。つまり、両方の基地局セルの重複範囲内に現時点で存在しているユーザーエンティティは、無線資源管理部３０によってそれに対して割り当てられた両方の基地局の通信資源を有することができる。従って、その場合、ユーザーエンティティ３４の事実上利用可能な通信帯域幅は、サービス提供している基地局３２と３８との各々によって提供された、又は割り当てられた、有効帯域幅の合計となるであろう。当然ながら、サービス提供している基地局の数は増大し得る。

【0024】

いずれの場合でも、これまで説明したように、無線資源管理部３０の機能に係る問題は、ユーザーエンティティ３４のようなユーザーエンティティの内の１つにおいて動作しているクライアント４０が、サーバー４２からできるだけ高度な情報コンテンツレベルを有するバージョンのメディアコンテンツを取得したいと欲することである。クライアントは、例えば、ブラウザのようなユーザーエンティティのオペレーティングシステム上で実行しているアプリケーションであってもよく、ＶｏＩＰ（ＩＰを用いる音声通信)アプリケーション又は同様のものでもよいが、他の可能性も同じく存在する。次に、サーバーは、コンピュータのようなホスト上で実行しているＶｏＩＰアプリケーション又はメディアコンテンツ・サーバーのようなプログラムであってもよく、他の移動ユーザーエンティティ、ワークステーション又はネットワークであってもよい。

【0025】

例えば、ユーザーエンティティ３４のクライアント４０がサーバー４２からメディアコンテンツ４４をダウンロードしたいと欲しており、また、このメディアコンテンツ４４がサーバー４２においてメディア・プレゼンテーション記述４６によって記述された種々のバージョンで利用可能であり、そのメディア・プレゼンテーション記述がサーバー４２からクライアント４０にとって利用可能でもあると想定する。メディアコンテンツ４４の種々のバージョンは、以下のパラメータの内の任意の部分集合の組合せにおいて異なっていてもよい。
１）空間解像度
２）時間解像度
３）ビューの数
４）ビット深度
５）信号対雑音比
６）オーディオチャネルの数

【0026】

つまり、メディアコンテンツ４４はビデオであってもよい。クライアント４０がサーバー４２からメディアコンテンツ４４を取得するときに用いるデータトラフィックは、少なくとも無線資源管理部３０によって調査可能であり、その様子は点線４８によって示されているが、サーバー４２とクライアント４０との間のデータトラフィックは、基地局３２、又は基地局３２及び３８、をそれぞれ経由するものであり、その場合、データトラフィックのコンテンツは、矢印５０で示すように、無線資源管理部３０によって検査し得るものである。代わりに、データトラフィックは、破線の矢印５２で示すように、無線資源管理部３０を経由してもよく、この場合、無線資源管理部３０は、クライアント４０とサーバー４２との間のデータトラフィックの一部分を検査するだけでなく、当該部分に対してインターセプトし又は影響を与えることも可能である。

【0027】

データトラフィックは、ＨＴＴＰなどの任意の適切なプロトコルを使用してもよい。根底にある伝送プロトコルは、ＴＣＰ又はＵＤＰであってもよい。

【0028】

しかしながら、本発明の実施形態の説明はＨＴＴＰストリーミングに焦点を当てているが、データ伝送そのものは、例えばＲＴＰ［ＩＥＴＦ ＲＦＣ ３５５０］を介するように様々に適用されてもよい。従って、１つのセッションにおけるメディアの記述は、ＳＤＰ［ＩＥＴＦ ＲＦＣ ４５６６］(セッション記述プロトコル)ファイルによって与えられる。そのようなＳＤＰファイルは、本願では「ＭＤＰ」として認識されるべきであり、そこから選択されるべき様々な符号化パラメータのような様々なメディア特性を記述することを可能にするものである。

【0029】

メディアコンテンツ４４の種々のバージョンがメディアコンテンツ４４の異なる量の情報を伝達するという事実に起因して、これらのバージョン間では、クライアント４０においてそれぞれのバージョンを中断することなく再生するために必要な必要最小要求伝送帯域幅に関し、順位付けが可能となる。

【0030】

通常、クライアント４０は、ユーザーに対してメディアコンテンツ４４に関する可能な限り最高の情報を提供できるバージョンを供給するよう構成される。可能な限り最高のバージョンとは、ユーザーエンティティ３４において利用可能なディスプレイ及びラウドスピーカ、メディアプレーヤ又は復号器などのユーザーエンティティ３４により利用可能な機器を用いて、ユーザーに対して提供し得る範囲内の１つのバージョンとして定義されてもよい。更に正確に言えば、図３には示していないが、ユーザーエンティティ３４は、メディアコンテンツ４４のフレームシーケンスを表示するためのディスプレイと、そのフレームシーケンスに随伴されていた最適なオーディオ信号を再生するための１つ又は複数のラウドスピーカと、を含んでもよい。後者の場合には、クライアント４０はユーザーに対し、例えばユーザーエンティティ３４のディスプレイによって再現可能な最高の空間解像度を提供するメディアコンテンツ４４のバージョンを供給するよう試みてもよい。

【0031】

最後に、クライアント４０は、例えばＨＴＴＰ要求などによってメディアコンテンツ４４の所望のバージョンをサーバー４２から要求する。ユーザーに供給されるべきバージョンについてクライアント４０が決定できるようにするため、クライアント４０は、サーバー４２からクライアント４０へのデータトラフィック内でメディア・プレゼンテーション記述４６の提供を受ける。例えば、クライアント４０は、メディアコンテンツ４４のメディア・プレゼンテーション記述４６をサーバー４２から要求し、サーバー４２はこれに応じてメディア・プレゼンテーション記述４６をクライアント４０へと送信する。上述したようにメディア・プレゼンテーション記述４６は、クライアント４０に対して、サーバー４２において利用可能なメディアコンテンツ４４のバージョンとそれらバージョンの必要最小要求伝送帯域幅とを示す。そこで、クライアント４０は、無線資源管理部３０によってユーザーエンティティ３４へと提供又は割り当てられた現在の利用可能な有効帯域幅を評価して、通常は最高レベルのバージョンを選択し、その結果として、ビデオ無線資源管理部３０によって提供される有効帯域幅よりも低いか又は同等レベル範囲内の最高の最小要求伝送帯域幅を求めることになる。

【0032】

しかしながら、本願明細書の導入部において説明したように、ユーザーエンティティにおいて動作している全てのクライアント４０がユーザーに対してそれぞれのメディアコンテンツの最大帯域幅のバージョンを提供したいと欲するので、基地局３２の通信資源に課せられる逼迫度(strain)が高まってしまう。但し、例えばもしクライアント４０がその要求バージョンレベルを低くすれば、その逼迫度はそれ程高くなくなるはずである。

【0033】

そこで図３の実施形態によれば、無線資源管理部３０は、ユーザーエンティティ３４を含むユーザーエンティティに対し、各サーバー４２から各ユーザーエンティティ３４において動作している各クライアント４０に向かうデータトラフィックの中のメディア・プレゼンテーション記述４６に依存して、基地局３２の通信資源を割り当てるよう構成されている。以下の説明からさらに明確になるように、そのようなＭＰＤ４６に対する依存性を用いてＲＲＭによって割り当てられる通信資源は、特にアップリンク及び／又はダウンリンクの通信資源に関係してもよく、それらアップリンク及び／又はダウンリンクの通信資源は、全体の通信資源の主要な部分を代表するものであり、またＴＣＰの肯定応答（acknowledgment)フィードバック・ループ又は上述の品質フィードバックなどの制御信号を含んでいてもよい。

【0034】

更に詳細には、無線資源管理部３０は、サーバー４２からクライアント４０へのデータトラフィック内でビデオコンテンツ４４の様々な帯域幅を有するバージョンを記述するメディア・プレゼンテーション記述４６を検査し、更に、ユーザーエンティティ３４が含まれる複数のユーザーエンティティに対して基地局３２の通信資源を割り当てるときに、メディア・プレゼンテーション記述によって提供された情報を他の入力パラメータと共に考慮する。

【0035】

例えば、サービス提供されるべきユーザーエンティティ３４の数が多いために、もし現在、通信資源に対して高い逼迫度が課せられている場合には、無線資源管理部３０は、クライアント４０によってサーバー４２から現在要求されているメディアコンテンツ４４のバージョンがクライアント４０に対して現時点で利用できないと決定してもよく、従って、ユーザーエンティティ３４に割り当てられる通信資源の量を削減し、結果的に、ユーザーエンティティ３４に提供される有効帯域幅を事実上減少させてもよい。換言すれば、無線資源管理部３０は次のような決定をしてもよい。即ち、高い逼迫状況においては、基地局３２の通信資源に対して高い逼迫度が掛かっている間に少なくとも一時的には、メディアコンテンツ４４のより高いレベルのバージョンからそのより低いレベルのバージョンへと、クライアント４０が切り替わるべきであるという決定である。勿論、ＲＲＭ３０はそのようなより低い帯域幅バージョンの存在を事前にチェックしてもよい。当然ながら、クライアントは、例えばセル内のクライアントによって見られるビデオ品質を最適化するためなどの理由によって、より高い帯域幅を有するバージョンを取得して最小の受け入れ可能なビデオ品質又は情報量を取得してもよい。換言すれば、ＲＲＭ３０は、セル・スループットを最適化することだけを目標にして、通信資源をクライアントに対して割り当てる必要はない。むしろＲＲＭ３０は、セル内の全てのクライアントのためのビデオ品質を考慮にいれてもよい。更に換言すれば、勿論、クライアントが最高品質を公然と求めてくる場合もある。そのようなクライアントの例は、以下に説明するような自動切替えモードのクライアントである。

【0036】

他の視点から見ると、無線資源管理部３０は、通信資源が割り当てられるべき２つ以上のユーザーエンティティ３４のクライアント４０が、少なくとも１つの基地局３２を介してそれぞれのメディアコンテンツ４４を現在ダウンロード中である場合には、それら２つ以上のユーザーエンティティ３４に対する通信資源の割り当てを以下のように実行してもよい。即ち、サーバーとクライアントとからなる各ペア間の各データトラフィック内にある各メディア・プレゼンテーション記述４６に依存して、費用関数が最適化されるように実行してもよく、その費用関数とは、少なくともクライアントの各メディアコンテンツ４４についてのバージョンの品質尺度(quality measure)と最小帯域幅とに依存している。更に詳細には、最適化されるべき費用関数が、複数のクライアントの各メディアコンテンツ４４についての複数のバージョンに亘って決定される、全体的な帯域幅と全体的な品質尺度との間の妥協点を形成してもよい。このような最適化の結果として、クライアントが元来適用されていたものよりも低い品質のメディアコンテンツのバージョンのための帯域幅を割り当てられる可能性があり、同様に、クライアントが元来適用されていたものよりも高い品質のメディアコンテンツのバージョンのための帯域幅を割り当てられる可能性もある。個々のメディアコンテンツのバージョンについての「品質尺度」は、区間スケールされる必要がない。@qualityRankingによって提供される順位スケール(ordinal scale)でも十分となり得る。つまり、順位スケールだけが個々のメディアコンテンツに関係する場合もあり得る。順位性(ordinality)は、全てのクライアント４０の全てのメディアコンテンツの間で有効である必要はない。しかし、追加的な情報が最適化費用関数の中に含まれる可能性があり、その情報とは例えばそれぞれのメディアコンテンツの符号化の複雑性の値、即ちメディアコンテンツの平均レート／歪みの尺度に関する値などである。この符号化の複雑性の値は、非常に粗いものでもよい。例えば、以下に説明する@contentCharacteristicもそのような特性であり得る。このような情報の全ては、それぞれのクライアントによって要求されたそれぞれのメディアコンテンツのメディア・プレゼンテーション記述４６の中に含まれてもよい。

【0037】

更に、無線資源管理部３０は、クライアント４０によって要求されたメディアコンテンツ４４のバージョン履歴を記録し、基地局３０の通信資源についての逼迫度が再び低減した段階で、その履歴を使用してそれぞれのクライアント４０に対してより高い量の通信資源を再度割り当てるようにしてもよい。

【0038】

クライアント４０は、次に無線資源管理部３０によって供給された現在の有効帯域幅を評価することにより、以下のことを実現させてもよい。即ち、割り当てられる通信資源量を低くするとＲＲＭ３０が決定した場合、現時点で要求されてダウンロードされているメディアコンテンツ４４のバージョンは、中断を含む状態でのみユーザーに対して提供可能となるということである。換言すれば、ユーザーに対してメディアコンテンツ４４を再生しつつあるメディアプレーヤのメディアバッファが、無線通信経路３６を介して利用可能な伝送帯域幅の減少によって空になりつつあることに、クライアント４０は気付くであろう。この状況に対して、クライアント４０はその希望どおりに自由に反応できるが、クライアント４０の合理的な選択肢の１つは、クライアントがサーバー４２に対して要求を送信して、メディアコンテンツ４４のより低いバージョン、即ちメディアコンテンツ４４の現時点でダウンロードされたバージョンと比べてより低い必要最小伝送帯域幅と関連するバージョンを要求することである。

【0039】

要約すると、図３の実施形態に従えば、無線資源管理部３０はスケジューリングを実行するが、その際に、上述した利用可能な資源、ユーザーエンティティのフィードバックによって示されたチャネル品質、関連するユーザーエンティティからの資源要求の数、ユーザーエンティティ間の優先順序などに対する依存性に加え、サーバーとそれぞれのユーザーエンティティにおいて動作しているクライアントとの各ペアの間に延びるデータトラフィックの中のメディア・プレゼンテーション記述４６にも依存して実行する。

【0040】

図３の実施形態に関しては、クライアント３０は、例えばユーザーエンティティ・プロセッサ上で実行しているソフトウエアを表していてもよいことに留意すべきである。代替的に、クライアントは、ハードウエア又はプログラム可能なハードウエア内に構成されてもよい。

【0041】

従って、図３は、サーバー４２からユーザーエンティティ３２の内の１つにおいて動作しているクライアント４０へのデータトラフィック内のメディア・プレゼンテーション記述４６に依存して、基地局３２の通信資源をユーザーエンティティ３４に対して割り当てるよう構成された、無線資源管理部を表している。

【0042】

以下に、図３の可能な構成例を説明する。この可能な構成例に従えば、クライアント３０は、ＨＴＴＰを用いたビデオストリーミングを使用して、サーバー４２からメディアコンテンツ４４を取得する。特に、ＨＴＴＰを用いたビデオストリーミングに使用される根底にある伝送プロトコルは、ＴＣＰ［ＲＦＣ ７９３］でもよい。

【0043】

事実、本明細書で指摘する事項は、以下に説明する特性を共有する全てのプロトコルについて有効である。本明細書で考慮対象となるプロトコルは、ＴＣＰのために使用される、ＡＣＫ（肯定応答）／ＮＡＣＫ（Negative-acknowledgement：否定応答）又はＳＡＣＫ(Selective-acknowledgement:選択的応答）などの任意の他のタイプの応答受領に基づいた輻輳制御機構を有する接続指向のプロトコルである。１つの可能性として、これらのプロトコルは、輻輳制御機構のスループット適応の結果と並行して、パケット損失に対処するための追加的な再伝送機構を使用してもよい。そのようなプロトコルの一例として、ＨＴＴＰを介するビデオストリーミングのために使用される根底の伝送プロトコルがＴＣＰ［ＲＦＣ ７９３］である場合を挙げることができる。ＴＣＰは信頼性を提供するよう強化された特徴を有するストリーミング・データの伝達を提供するものであり、その特徴は、例えば肯定応答メッセージ（ＡＣＫ）と、例えばスロースタートを用いた輻輳制御、輻輳回避、高速再伝送及び高速回復などのフロー制御機構と、を使用するものである。フロー制御は、送信機に対してどれくらい多くのバイトが内部バッファのオーバーフローなしに受信され得るかを示す。関連するメディアとステータス・レートは、図４と表１とに示されている。図４に示すように、パケット損失は受信されたＴＣＰスループットに対して影響を与え、同様のことが上述した特徴を有する他のいずれのプロトコルに対しても予想される。更に、下記の式は、パケット損失（ｐ）とラウンドトリップタイム(ＲＴＴ）と最大伝送ユニット(ＭＴＵ）（非特許文献１８を参照）とに基づいて、ＴＣＰスループットの非常に良好な推定を示すものである。このように、伝送におけるネットワークレイヤ・パケット損失を追跡することは、無線資源管理部が基地局３２の通信資源を適切に割り当て得るようにするための非常に効果的な技術である。従って、基地局３２は、損失無線フレーム／ＭＡＣレイヤ・パケットデータユニット、より高いレイヤのＭＴＵサイズ、無線資源管理部３０のＭＡＣバッファ１００（図１３を参照）におけるＴＣＰパケット損失などの、ＰＨＹレイヤ情報を用いて、例えばＴＣＰに関するトランスポートレイヤなどのより高いネットワークレイヤ上の実際のパケット損失レートを導出してもよい。

【0044】

【数1】

【0045】

【表1】

【0046】

例えば図３に関し、無線資源管理部３が、メディアコンテンツのＭＰＤ４６のうちのどのバージョンをクライアント４０が現在ダウンロード中であるかをチェックする方法として、種々の可能性を有している。例えばＲＲＭ３０は、基地局３２を介してクライアント４４によって現在ダウンロードされつつあるメディアコンテンツ４４のバージョンを、クライアント４０からサーバー４２へのメディア要求を検査することによって決定してもよい。しかし、ＲＲＭ３０におけるより少ない追跡作業を用いたより簡素な処理が次の場合に達成し得る。即ち、ＲＲＭ３０がクライアントの受信されたメディア・スループットに関するスループット尺度を決定し、その決定されたスループット尺度に基づいて、メディアコンテンツ４４のメディア・プレゼンテーション記述４６のうちのどのバージョンが、少なくとも１つの基地局３２を介して現時点でクライアント４０によってダウンロードされているかを予測する場合である。スループット尺度としては、割り当てられた帯域幅自身が使用されてもよい。代替的に、ＲＲＭ３０は、上述したように、それぞれのユーザーエンティティに対して元来割り当てられた帯域幅から見た、それぞれのクライアント４０の実際に受信されたメディアコンテンツ帯域幅のずれ／減少を、それぞれのユーザーエンティティ３４から基地局３２へと送信された品質フィードバックを評価することで、推定してもよい。更に代替的には、ユーザーエンティティの追加的な機能によって、ＲＲＭ３０に対し、実際に受信されたメディアコンテンツ・スループットレートについての情報が与えられてもよい。

【0047】

上述の説明では、無線資源管理部がサーバー４２からクライアント４０へのデータトラフィックを調査して、メディア・プレゼンテーション記述４６を取得すると想定していたが、それに代えて、このオーバーヘッドは、ユーザーエンティティ内のあるエンティティであって、ユーザーエンティティの送受信ステージとクライアントとの間（例えば図７を参照）のエンティティなどに置き換えられてもよい。つまり、この調査はユーザーエンティティ内の調査ステージによって行われてもよい。その調査ステージは、ＭＰＤ３０か、その抜粋など少なくともその一部か、又はＭＰＤの一部から導出されたパラメータの集合を、ＲＲＭ３０へと（逆）転送してもよく、その場合、抜粋又はパラメータの集合はメディアコンテンツを記述するために十分であり、そのバージョンはサーバー３２において利用可能であってもよい。従って、ユーザーエンティティ３４は、上述のように無線資源基地局３２と通信するよう構成されてもよく、またその場所でクライアント４０が動作可能であってもよい。しかしその場合、ユーザーエンティティ３４はサーバー４２からクライアント４０へのデータトラフィックを調査するよう構成されてもよく、それにより、データトラフィックからメディア・プレゼンテーション記述４６を導出して、そのメディア・プレゼンテーション記述を少なくとも部分的に無線資源管理部３０へと転送してもよい。後段で説明するが、ユーザーエンティティは、クライアント４０の代わりにその場所で動作するサーバーを有していてもよい。しかしその場合、ＲＭは同様に作動している。即ち、そのサーバーからそのユーザーエンティティ以外のいずれかのクライアントへのデータトラフィックを調査することで、ＭＰＤを導出している。

【0048】

更に、次に説明する図３の構成においては、クライアント４０とサーバー４２とは、サーバー４２からクライアント４０へとメディアコンテンツをストリーミングするために、ＤＡＳＨを使用してもよい。ＤＡＳＨは、メディア・プレゼンテーション記述に関する所定の構造又はシンタックスを定義する。ＤＡＳＨによれば、ＭＰＤは、ＤＡＳＨクライアントとＤＡＳＨのＨＴＴＰサーバーとの間の論理的チャネルを設定するために必要なパラメータを特定するために、タグを使用する。タグは、文字Ｏを用いて印付けされた任意のタグであってもよく、又は、文字Ｍを用いて印付けされた必須のタグであってもよい。

【0049】

図３の実施形態を構成する場合、ＭＰＥＧ ＤＡＳＨ標準（ＩＳＯ／ＩＥＣ ２３００９−１）（非特許文献３を参照）から取られたＭＰＤタグの組合せが使用されてもよい。

【0050】

特に、必須の@bandwidthタグが考慮対象となってもよく、その@bandwidthタグは@minBufferTimeタグに依存しているため、その場合、この@minBufferTimeタグも準必須となる。

【0051】

ＭＰＤが構築され得るタグは、以下の表２に示すタグを含む。

【0052】

【表2-1】

【0053】

【表2-2】

【0054】

【表2-3】

【0055】

【表2-4】

【0056】

【表2-5】

【0057】

つまり、図３のＭＰＤ４６は、各利用可能な バージョン（表現）に関し、@bandwidth、@minBufferTime、及び任意ではあるが@qualityRankingを有してもよい。

【0058】

上記から分かるように、ＭＰＤ４６は、１つのバージョン毎にこれらパラメータの最初の２つ、即ち@bandwidthと@minBufferTimeとだけを含んでもよい。

【0059】

ＭＰＤの一例を下記のリスト１に示す。この例は、例えばＤＡＳＨ標準（非特許文献３を参照）でプロファイル属性によって識別されたような特定のプロファイルに対応していてもよい。メディア・プレゼンテーション時間は３２５６秒で特定され、最小のバッファ時間は１．２秒である。２つの表現のセグメントのＵＲＬ（統一資源ロケータ）は次のように与えられる。１つの表現は６４ＫＢ又は３２ＫＢの帯域幅を要求し、また、そのセグメントのＵＲＬが、各表現のそれぞれのSegmentList要素に含まれる二者択一のBaseURLとSegmentURLとの内の連鎖状の１つによって作成される。セグメントの持続時間は、SegmentList要素内の持続時間属性によって与えられる。

【0060】

【表A】

【0061】

更に、以下により詳細に説明する図３の実施形態の構成は、ＬＴＥシステム内に埋め込まれてもよい。つまり、基地局３２又は基地局３２及び３８と、無線資源管理部３０とが、ＬＴＥシステムの一部であってもよい。

【0062】

ＬＴＥに関しては、様々な改善が導入されてきた。多入力多出力（ＭＩＭＯ）強化と組合せられた直交周波数分割多重アクセス（ＯＦＤＭＡ）への進展と、回路スイッチからパケットスイッチ・ネットワークへの移行の結果、２×２／４×４のＭＩＭＯを有するＬＴＥ Ｒｅｌ．８について、１５０／３００Ｍｂｐｓまでのピークスループットを達成するモバイルネットワークがもたらされた。ＬＴＥの重要な達成点の１つは、ＩＴＵ−Ｒ（非特許文献１５を参照）の待ち時間条件(latency requirements)、即ち制御プレーン上では５０ｍｓを下回り、ユーザープレーン上では５ｍｓを下回る遅延を持つという、終端間の低遅延通信にとって不可欠な条件を満足させたことである。

【0063】

ＬＴＥは高速再伝送メカニズムを実現する。即ち、自動繰返し要求(ＡＲＱ）及びハイブリッドＡＲＱ（ＨＡＲＱ）機構を、物理（ＰＨＹ）レイヤと、メディアアクセス制御（ＭＡＣ）レイヤとにおいて達成し、受信機における高速リオーダーリングを要求する。このため、リオーダーバッファリングによって追加的なジッターと遅延とが導入される可能性があり、その結果、リアルタイムＴＣＰサービスに関し、特にＨＴＴＰ／ＴＣＰビデオサービスが識別されず、最大限のサービスとしてオーバー・ザ・トップを実行する場合、パーフォーマンスが劣化する恐れがある。ＬＴＥにおけるハンドオーバー期間中のＴＣＰパーフォーマンスは、非特許文献１２において評価されており、そこでは、特別なパケット転送技術とパケットリオーダーリングが、高度なＴＣＰパーフォーマンスを達成するために必要であることが示されている。

【0064】

加えて、ＬＴＥは、基地局即ち進化型ＮｏｄｅＢ（ｅＮＢ）における非集中的なスケジューリングと、多数ユーザーの無線資源管理（ＲＲＭ）とを導入する。非集中的な手法は、ＨＴＴＰ／ＴＣＰライブストリーミングなど種々のトラフィックサービスに関する終端間(end-to-end)のＱｏＳ（サービス品質）を実現させるために、ＱｏＳサポートを伴う、新たなロバスト性のあるクロスレイヤ・スケジューリング・アルゴリズムの設計を必要とする。

【0065】

ＲＲＭエンティティ、即ち無線資源管理部３０は、無線資源管理の責任を担い、その管理は、短期間の時間フレーム上でＵＥ即ちユーザーエンティティ３４に対して資源を割り当てる、スケジューリングとも呼ばれる作業を含むと共に、長期の資源割り当ても含み、この資源割り当ては、より長い時間フレーム上での作業であり、例えばＵＥフィードバック、ユーザーサービスデマンドなどの種々のパラメータに依存する作業である。割り当てられるべき資源は、ＭＩＭＯ ＯＦＤＭＡに基づいたＬＴＥにおいて使用されている、時間、周波数、空間−グリッドから取得される。資源の量は、使用されるべきＬＴＥパラメータ帯域幅、ＦＤＤ又はＴＤＤモード、及びＭＩＭＯモードに依存する。

【0066】

ＤＡＳＨをメディアコンテンツのストリーミングに使用しながら、無線資源管理部３０をＬＴＥシステム内に埋め込む状態で、図３の実施形態を構成した場合の結果を図５に示す。図３に示された構成要素の機能を、図５に示す実施形態がどのように構成するかを理解し易くするために、図３の参照符号を図５でも再使用しており、図３に関して上述したこれら構成要素の説明は、図５についても同様に適用されるべきである。これは、ＲＲＭ３０が基地局３２の内部に物理的に含まれる必要がないことも意味する。他方では、図３において対応する参照符号がなかった部分については、図２の参照符号も図５内で再使用されている。従って、基地局３２を超えるデータトラフィック部分に関しては、データトラフィックは、インターネットなどのＨＤＴＰキャッシュ１６を介して通じるように、クライアント４０がサーバー４２に対して通信可能に接続されている。更に、ＤＡＳＨコンテンツ準備ステージ１４が示され、ここからメディア・プレゼンテーション記述４６のコンテンツが由来してもよい。

【0067】

図５の実施形態の動作例のモードを説明する場合、それらはＬＴＥを介するＤＡＳＨを用いた無線資源管理と呼ばれてもよい。メディアコンテンツのバージョンの可能な表現として、ＶＣが使用されてもよい。図５の実施形態は図３の実施形態に従っているため、図５のＲＲＭ３０の機能は、クライアントに対してより効率的に無線資源を割り当てるために、受動的な信号伝達を実現する。

【0068】

特に、ＤＡＳＨクライアント４０はビデオセグメントについてのＨＴＴＰ要求をサーバー４２に送信する。ＲＲＭユニット３０は、その特定のユーザー又はクライアント４０によって要求されたＭＰＤ４６を、ディープ・パケット・インスペクション５０を用いて検査する。ＭＰＤ４６内で定義された@bandwidthと@minBufferTimeタグとに依存して、スケジューラと長期ＲＲＭ３０とは、所与の@minBufferTimeに関して要求された帯域幅を実現する。しかし、ＬＴＥのＰＨＹデータパイプが要求された帯域幅をサポートしていない場合には、ＲＲＭ３０は自動的に、ＭＰＤ４６又は‘sidx’-Ｂｏｘ及びＭＰＤの内部のメディアコンテンツのＡＶＣビデオセグメントについて特定された次に低い帯域幅を保証するよう試みる。ＤＡＳＨクライアント４０は、ＬＴＥのＲＲＭ３０のデータレート制限に従い、例えばＨＴＴＰゲット５２を、ＭＰＤ４６内のリストに挙げられたより低いレート要求を有するサービスへと送信することで、そのＨＴＴＰゲット要求５２を調整する。

【0069】

これにより以下の事項が保証される。
１．ＨＴＴＰビデオストリームの保証付きサービス配信
２．できるだけ多数の資源を得ようと試みる所与のユーザーに対して資源を過度に供給することを防止する。
３．上記２により、所与の時間-周波数-空間グリッドに関し、ＬＴＥセル内の他のユーザーのために資源を節約することが可能となる。このため、ＩＰスループットにおける変動が減少し、従って、種々のトラフィックミックスを多数のユーザーへと円滑に配信することが可能となる。
４．ＴＣＰはＬＴＥシステムによって割り当てられたデータレートへと最適に適応するであろう。

【0070】

セルラーシステム内の無線資源は同じｅＮＢに接続された全てのユーザー間で共有されるため、１つのユーザーに対して割り当てられた資源量は、他のユーザーに対してどれだけ多くの資源が利用可能であるかに関して影響を与える可能性がある。従って、ＲＲＭ３０は、たとえあるユーザーが非常に良好なチャネル状態を有していた場合でも、他のユーザーをサポートすることを優先させた結果、そのユーザーに対する資源量を減少させることを選択できる。ビットレートとコンテンツの特性（コンテンツのタイプ、例えば映画、ニュース、スポーツなど）又は@qualityRankingを考慮して、セル内の全てのユーザーに亘る全体的なビデオ品質の最適化が実行され得る。

【0071】

トリックモード（例えば早送り、高速巻戻し、ジャンプなど）の使用は、クライアント４０により要求されるチャンクのシーケンスによって、ＲＲＭ３０により識別され得る。トリックモードの使用後、ＤＰＩによる@minBufferTime／新たなバッファリング検出のために、クライアントは新たなリバッファリングを実行しなければならない。ＤＰＩとは、深層パケット検査(Deep Packet Inspection)を表している。これは、基地局スケジューラがＩＰパケットのコンテンツを調査し、そのような調査に基づいてスケジューラの決定を行うことを意味している。伝統的に、ＩＳＯ-ＯＳＩモデルにより提案されているように、ＲＲＭはＭＡＣレイヤ上で動作し、ＩＰレイヤを調査することはない。

【0072】

図５に関して詳細に説明された図３の実施形態の上述の構成に関し、注意すべき点として、その中で図３の実施形態を図５が具体化するような種々の態様は、図３に対して個別に置き換えられてもよいという点である。例えば、データトラフィックに対するＴＣＰの使用や、管理部３０、基地局３２及びユーザーエンティティ３４のそれぞれの機能を定義するためのＬＴＥシステムの使用や、ＭＰＤ４６のコンテンツとサーバー４２及びクライアント４０の機能とを少なくとも部分的に定義するＤＡＳＨストリーミングフレームワークなどについて、これがあてはまる。

【0073】

図３から図５に示す実施形態によれば、ビデオ資源管理部３０は、図５内で「Ｒ」で示すように、個々のユーザーエンティティ及びそれらのクライアント４０に対し、直接的にレート割り当てを指図しており、これはサーバー４２からクライアント４０へのデータトラフィック内のメディア・プレゼンテーション記述の評価に基づいて、基地局３２の通信資源を各ユーザーエンティティへと割り当てるものである。以下に説明する実施形態によれば、資源管理部３０のこの機能は任意である。

【0074】

図６は本発明の更なる実施形態に従う無線資源管理部を示す。上述したように、図３と図６との中に共通する構成要素の機能及び相互接続に関しては、図３についての説明が図６にもあてはまる。つまり、無線資源管理部３０は、ユーザーエンティティ３４に対して、基地局３２の通信資源を上述の通りに割り当てる。但し、メディア・プレゼンテーション記述４６に対するこの割り当ての依存性が、この場合には任意である。更に、図６の実施形態によれば、無線資源管理部３０は、クライアント４０とサーバー４２との間のデータトラフィックが無線資源管理部３０を介して流れるように配置されており、その結果、無線資源管理部３０がこのデータトラフィックに対して以下のような影響を与えることになる。

【0075】

特に図６の実施形態によれば、無線資源管理部３０は、追加的に即ち図３に関して上述した機能に加えて、メディアコンテンツ４４の異なる帯域幅の複数のバージョンを記述しているメディア・プレゼンテーション記述４６を、サーバー４２からユーザーエンティティ３４において動作しているクライアント４０へと流れるデータトラフィック内で検査し、同時に、メディアコンテンツ４４の所望のバージョンを要求するメディア要求６０であって、クライアント４０からサーバー４２へと送られるメディア要求６０も検査するよう構成されている。これら両方の検査に基づいて、資源管理部３０は、少なくとも要求６０を送信したユーザーエンティティ３４に関し、現在の資源状態を記述している情報に依存して、及び、ユーザーエンティティ３４に対して送信されたメディア・プレゼンテーション記述に依存して、以下の事項を決定する。（１）サーバー４２に対してメディア要求６０を（無修正で）転送する。又は、その代わり（２）クライアント４０に送信されるメディアコンテンツ４４の所望のバージョンをメディア要求６０がもたらさないようにする。例えば、無線資源管理部３０は、（２）のような状態を次の２つの方法で引き起こしてもよい。（２ａ）修正済みのメディア要求がメディアコンテンツ４４のより少ない帯域幅のバージョンを要求するように、メディア要求６０を修正する。又は、（２ｂ）メディア要求４４をインターセプトし、利用不可の応答(non-availability response)をサーバー４２からユーザーエンティティ３４又はクライアント４０へと返送するように、サーバー４２に対してエミュレート又は指令する。代替的に、低い帯域幅についての応答がＲＲＭ３０によって実行されてもよく、又は、クライアントに対してその要求を適性に変更するよう指令する任意の他のフィードバックがサーバーによって実行されてもよい。

【0076】

これは以下のことを意味する。即ち、図３について上述したように、無線資源管理部３０は現在の資源状態情報に対するアクセスを有する。特に無線資源管理部３０は、ユーザーエンティティ３４に関してだけでなく、全てのユーザーエンティティに関して、この現在の資源状態情報に対するアクセスを有する。この情報に基づいて、無線資源管理部３０は、基地局３２の通信資源に課せられている現在の逼迫度を知り、またユーザーエンティティ３４にとって利用可能な通信資源について知る。更に、無線資源管理部３０は、メディア・プレゼンテーション記述４６に対してもアクセスを有しかつそれを検査し、無線資源管理部３０は、ユーザーエンティティ３４側のクライアント４０がダウンロードを求めるメディアコンテンツ４４の代替的なバージョンについても知る。

【0077】

全体的な情報、即ち現在の資源状態の情報とメディア・プレゼンテーション記述４６とに基づいて、無線資源管理部３０は、基地局３２が直面する現在の負荷が、サーバー４２に対してメディア要求６０を無修正バージョンで単に転送することを正当化できる程度に十分低いかどうかを決定することができる。しかしながら、現在の資源状態の情報とメディア・プレゼンテーション記述とに基づいて、無線資源管理部３０が、メディアコンテンツ４４の現在要求されているバージョンに必要な帯域幅の部分が他のユーザーエンティティから転送されるべきでないと決定した場合、例えば、残りの帯域幅が、他のユーザーエンティティのクライアントの要求するメディアコンテンツの最低の帯域幅のバージョンを彼らに供給するためには十分でない場合には、無線資源管理部３０は、修正済みのメディア要求がより低い帯域幅のバージョンを要求するように、メディアメディア要求６０を修正するよう決定する。従って、サーバー４２は、この修正済みの要求に対し、より低い帯域幅バージョンをクライアント４０へと送信することで応答し、それによってこのような場合の処理が可能となる訳であるが、その要求への応答は、実際にはより低い帯域幅バージョンに対する要求への応答と同じとなる。例えば、より低い帯域幅バージョンは、メディアコンテンツ４４の元来所望されたバージョンと比べ、単に所定のメディアストリーム部分を省略した点だけが異なっており、そのような省略は、そのメディアコンテンツを再生する役割を担うユーザーエンティティ３４側のメディア復号器に悪影響を与えることがない。つまり、より低い帯域幅バージョンは、スケーラブルなメディアコンテンツのより低い情報レベルであってもよく、又は、より低い帯域幅バージョンは、同じ符号化方式を使用して符号化された他のメディアファイルであってもよい。

【0078】

メディア要求６０を修正する代わりに、サーバー４２がメディア要求６０をインターセプトしてサーバー４２からクライアント４０に対して利用不可の応答を返送するように、サーバー４２に対してエミュレート又は指令することも可能である。どちらの場合でもクライアント４０はサーバー４２からの応答を受信し、その応答により、メディア・プレゼンテーション記述４６内に示されたものであるが、所望のバージョンはサーバーにおいて利用可能でないことが分る。クライアント４０はこの応答に対してどのように反応してもよいが、反応の１つの合理的な方法は、クライアント４０が新たな要求を有する別の要求をサーバー４２に対して新たに送信することを含んでもよい。その新たな要求とは、メディアコンテンツ４４のより低い帯域幅バージョンをサーバー４２から要求するものであり、これにより、上述したメディア要求を修正する場合の結果と同じ状況、即ちサーバー４２がクライアント４０に対してより低い帯域幅バージョンを返送する状況へと効率的に行き着くことになる。

【0079】

このように、上述した決定の選択肢（１）〜（２ｂ）の間における無線資源管理部の決定の中に含まれ得る第１ステップは、メディアコンテンツ４４のいずれかの利用可能なより低い帯域幅バージョンが存在するかどうかについてチェックすることである。このチェックは、メディア・プレゼンテーション記述４６に基づいて実行される。第２ステップは、上述の選択肢（２ａ）〜（２ｂ）が適切かどうかについて、現在の資源状態情報をチェックすることを含み得る。

【0080】

図６の実施形態の更なる拡張又は抽出を、以下に図７に関して説明する。図７は、ユーザーエンティティ３４の一実施例を更に詳細に示す。以下に図７に関して説明する実施形態によれば、追加的な無線資源管理部の機能、即ちメディア要求６０の転送、修正及び／又はインターセプトなどの処理に関係する機能が、無線資源管理部３０から、サーバー４２とクライアント４０との間のデータトラフィックに沿って、ユーザーエンティティドメイン３４へと置換されており、特にユーザーエンティティ伝送ステージ７０とクライアント４０との間のいずれかの場所に置かれている。しかしながら、これは単なる一例であって、このような機能はまた、他の場所に配置された別のエンティティによっても達成し得ることに留意すべきである。

【0081】

特に、図７に示すユーザーエンティティ３４は、１つ又は複数のアンテナ７２と、送受信ステージ７０と、資源管理部７４と、クライアント４０と、メディア再生部７６と、例えばディスプレイ７８及び１つ又は複数のスピーカ８０のようなユーザーに対してメディアを実際に提示するハードウエアと、を含む。これら全ての構成要素は、上述した順序で相互に直列接続されている。伝送ステージ７０は、それぞれのデータ経路が、クライアント４０により代表されるような後続又はより高いレイヤのアプリケーションに対してトランスペアレントとなるように、基地局３２との通信を実行する役割を担う。送受信ステージ７０は、例えば、ＯＦＤＭ（逆）多重化、時間分割（逆）多重化、基地局３２への受信品質フィードバック、チャネル推定及びその他の、（逆）多重化を実行する。更に、送受信ステージ７０は、それぞれのユーザーエンティティ３４に割り当てられるべき帯域幅の増加を要求する、基地局３２への要求を送信することができ、その場合、そのような要求の送信は、例えばクライアント４０などの後続のモジュールのいずれかによってトリガーされる。送受信ステージ７０は、ハードウエア又はハードウエアの組合せ、プログラム可能なハードウエア及び／又はソフトウエア、又はそれらの何らかの組合せの中で構成されてもよい。

【0082】

資源管理部７４は、送受信ステージ７０とクライアント４０との間に接続されており、従って、上述した修正に関する無線資源管理部の機能を実行することができる。即ち、送受信ステージ７０とアンテナ７２とのそれぞれによって表わされた無線インターフェイスを介した、クライアント４０からサーバー４２へのメディア要求を転送及び／又はインターセプトする機能を実行できる。つまり、資源管理部７４は、送受信ステージ７０を介して現在の資源状態情報にアクセスできる。特に、送受信ステージ７０は、資源管理部７４に対し、無線資源管理部３０（図６を参照）による各ユーザーエンティティに対する通信資源の現在の割り当てから結果的に得られる現在の利用可能な伝送レートについて、情報を与えることができる。更に、資源管理部７４は、サーバー４２からクライアント４０へのデータトラフィック内のメディア・プレゼンテーション記述４６を検査することができる。クライアント４０からサーバー４２へのメディア要求６０を検査することにより、資源管理部７４は、図６に関して説明した決定と同じ決定を実行することができる。即ち、メディア要求の転送に関する上述した決定選択肢の間での決定であり、又は代替的に、メディア要求を修正するか、或いはメディア要求をインターセプトするとともにサーバー４２に対して利用不可の応答を返送するようエミュレート若しくは指令する決定である。当然ながら、資源管理部７４は単に、無線資源管理部３０と比較して現在の資源状態情報の適切な部分集合に対するアクセスを有するだけである。しかしながら、資源管理部７４は、メディアコンテンツ４４のバージョンであって、基地局３２でのフルの資源状況を考慮した場合に、他のユーザーのサーバー基地局３２に関して公平でない、又は、頻繁にストリーミング可能でないようなバージョンを、要求するクライアント４０を忌避してもよい。

【0083】

図６と図７の実施形態に関し、資源管理部３０と７４とは、それぞれ、（１）及び（２）、又は、（１）及び（３）の選択肢の間で、単に切り替えるよう構成されてもよい。更に、資源管理部７４に関しては、この資源管理部が、現在の資源状態情報の一部として、無線資源管理部３０によってユーザーエンティティ３４へと送信された長期通信資源保証を利用するよう構成されてもよいことに留意されたい。

【0084】

このように、図６と図７とは、メディアコンテンツ４４の異なる帯域幅のバージョンを記述するメディア・プレゼンテーション記述４６を、サーバー４２からユーザーエンティティ３４において動作しているクライアント４０へのデータトラフィック内で検査し、また、メディアコンテンツ４４の所望のバージョンを要求するクライアント４０からサーバー４２へのメディア要求６０を検査し、更に、現在の資源状態情報とメディア・プレゼンテーション記述４６とに依存して、（１）メディア要求６０をサーバーへと転送するか、又はそれに代えて（２）修正済みのメディア要求がメディアコンテンツ４４のより少ない帯域幅のバージョンを要求するように、メディア要求６０を修正するか、又は、メディア要求６０をインターセプトして、利用不可の応答をサーバー４２からクライアント４０へと返送するように、サーバー４２に対してエミュレート又は指令することを決定する、資源管理部を開示している。

【0085】

図３〜図５に関して説明した実施形態と類似して、以下に図６と図７の実施形態の可能な構成について説明する。つまり、これら可能な実施形態は、無線通信システムがＬＴＥシステムであり、メディアコンテンツのストリーミングがＤＡＳＨを使用すると想定している。図３との関連における図５の説明方法と同様に、図８は先に使用された参照符号を再使用し、従って、図６及び図７の構成要素の機能についての説明は、図８内で同じ参照符号を有する構成要素に対しても同様に適用されるべきである。

【0086】

ＤＡＳＨとの組合せにおいて、ＬＴＥ ＲＲＭ３０は、接続された全てのＵＥによって要求されたＭＰＤ４６を検査することができる。所与のＵＥが良好な無線チャネルを有しており、高い帯域幅の要求６０を発信する場合、ＬＴＥ ＲＲＭ３０は、所謂ステータスコード注入(injection)と呼ばれるステータスコード・トリガーを送信することができ、その結果、ＨＴＴＰ ＤＡＳＨサーバー４２がＷ３ＣのＨＴＴＰステータスコード８０を送信して、この帯域幅が利用不可であることを示すことができる。可能性のあるＷ３Ｃ ＨＴＴＰステータスコードを後段でリスト掲載する。このように、ＬＴＥ ＲＲＭ３０は、ＵＥ３４に直接的に信号伝達することなく、ＵＥ３４に対してより低いデータレートを要求するよう強制することができる。これにより、信号伝達のために使用される資源を節約でき、その代わりにそれら資源がデータ用に使用可能となる。例えば、これらの資源は他のＵＥ３４のためにスケジューリングされ得る。ＵＥのＴＣＰ／ＩＰサービスは、割り当てられたレートに対しｅＮＢ ＲＲＭアルゴリズムによって自動的に適応するが、そのアルゴリズムはＭＰＤ@bandwidth tagから引き出すことができる。

【0087】

ｅＮＢ ＲＲＭユニット３０は、あるＵＥ３４によって要求されたＭＰＤ４６を検査する。加えて、ユニット３０は、図８に図示しない移動性管理エンティティ（ＭＭＥ）から情報を引き出してもよい。ユーザープロファイル、例えば移動速度、ハンドオーバー統計及び所望のＭＰＤに基づいて、ＲＲＭエンティティ３０は、Ｗ３Ｃ ＨＴＴＰステータスコードを介する間接的な信号伝達８０を用いて、より高い又は低いビデオ品質を強制することができる（例えばhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlを参照されたい）。

【0088】

図８に関する上述の説明においては、サーバー４２において利用可能なメディアコンテンツ４４のバージョンが別々に利用可能であること、即ち、異なる情報コンテンツにおいては非スケーラブルなバージョンであることが想定されていた。しかし、上述の図８の説明は、他の場合に対しても容易に当てはめることができる。即ち、メディアコンテンツ４４の利用可能な様々な帯域幅のバージョンが１つのメディアストリームの形態で利用可能となっており、そのメディアストリームがＳＶＣ又はＭＶＣストリームなどのスケーラブルな方法で符号化されている場合である。この場合には、図８の無線資源管理部３０の動作のモードは以下のように記述されてもよい。

【0089】

ＬＴＥ ＲＲＭエンティティ３０は、特定のユーザーによって要求されたＭＰＤ４６をディープ・パケット・インスペクション５０を使用して検査する。利用可能な無線資源に依存して、ＬＴＥスケジューラ３０は、所与のユーザーによって要求された帯域幅の量を評価する。その要求された帯域幅が、所与のＳＶＣ又はＭＶＣレイヤにとって利用可能な帯域幅を超える場合には、ＬＴＥ ＲＲＭエンティティ３０は、そのユーザー４０に対してＷ３Ｃ ＨＴＴＰステータスコードを送信するように、ＨＴＴＰ ＤＡＳＨサーバー４２をトリガーすることができる。ＤＡＳＨクライアント４０内のＳＶＣ／ＭＶＣ復号器７０は、そのエラー・ステータスコードを受信して、より少ない帯域幅を必要とするより低いＳＶＣ又はＭＶＣレイヤを自動的に要求し、結果的にＬＴＥシステム上の無線資源を節約する。

【0090】

所与のユーザーの劣悪なチャネル品質、又は資源を要求している他のユーザーの総数に起因して、無線資源は制限されることがあり得る。ＬＴＥ ＲＲＭ３０は、良好なチャネル品質を有するユーザーに対し資源を提供してもらうよう強制し、その資源を、低いチャネル品質で我慢しているユーザーに対して割り当てることができる。

【0091】

ＬＴＥ ＲＲＭ３０内の優先順位ポリシーに依存しながら、ＲＲＭ３０はＭＰＤ４６を使用して、Ｗ３Ｃ ＨＴＴＰステータスコード８０をトリガーすることにより、より高位のＳＶＣ／ＭＶＣレイヤのＨＴＴＰ要求を許可する前に、最下位のＳＶＣ／ＭＶＣレイヤ、即ちベースレイヤをサービス配信することを保証することができる。

【0092】

ＨＴＴＰ ＤＡＳＨサーバー４２は、以下のＷ３Ｃ ＨＴＴＰステータスコードの内の１つを送信してもよい。
・４０４ Not Found （発見されない）
・４６６ Streaming Rate Exceeded (tbs. in RFC) (ストリーミングレート超過）（ＲＦＣ内のtbs）
・５０３ Service Unavailable （サービス利用不可）
・５０９ Bandwidth Limit Exceeded （帯域幅限度超過）

【0093】

本願の次の実施形態を説明する前に挙げるべき注意点は、図７に示すユーザーエンティティ３４の全体的な構造は、一般的に、資源管理部７４を除けば他の全ての実施形態に対しても適用可能であることである。メディア再生部７６は、サーバー４２から受信されたメディアコンテンツ４４を復号化できるメディア復号器であってもよい。クライアント４０とメディア再生部７６とは、相互接続されて、相互に通信可能であってもよい。メディア再生部は、クライアント４０内に部分的に統合されることさえ可能である。

【0094】

図３〜図５の実施形態によれば、個々のユーザーエンティティに割り当てられた通信資源、特に、割り当てそのものがメディア・プレゼンテーション記述の検査結果に依存して適応されていた。その後に示した図６〜図８の実施形態によれば、クライアントとサーバーとの間のデータトラフィックの一部分であって、クライアントからサーバーへと送信されたメディア要求に関連する部分は、基地局の通信資源のより効率的な活用を行うため、又は基地局の通信資源のユーザーエンティティに対するより公平な配分を得るために、何らかの影響を受けている。両方の実施形態によれば、無線資源管理部３０はまた、以下に説明する構成例に従い、物理レイヤ上のＬＴＥ閉ループフィードバックも考慮することができる。つまり、以下に示す構成可能な例は図５と図８とに示す構成例を更に詳細に説明することを意図している。つまり、本発明の構成可能な例によれば、無線資源管理部（ＲＲＭ）スケジューラ３０は、ＬＴＥの物理レイヤからのＬＴＥ閉ループフィードバックを考慮して、ＬＴＥ ＥＭＢ３２において、ＤＡＳＨクライアントに対してどのビデオ表現又はメディアコンテンツ４４のバージョンが最も適しているかを決定する。また、図３に示す実施形態と図５に示す構成によれば、資源管理部３０は、それぞれの表現が提供されているそれぞれのクライアント４０に対して通信資源を適切に割り当てることにより、最も適切な表現又はバージョンのダウンロードを間接的に取得したいと試みている。他方、図６に示す実施形態と図８に示す構成によれば、無線資源管理部３０は、上述したような方法でクライアントのメディア要求に対して適切な影響を与えることにより、クライアントによる最適な表現のダウンロードを達成しようと試みている。

【0095】

ＲＲＭユニット３０は、（Ｈ２６４／）ＳＶＣレイヤのメディアコンテンツ４４のＡＶＣセグメントの異なる表現の間で選択を行う場合や、（Ｈ２６４／）ＭＶＣにおいて２Ｄ又は３Ｄのビデオ配信を行うかを決定する場合に、例えばＬＴＥ閉ループフィードバックを考慮に入れる。ＬＴＥ ｅＮＢのＲＲＭ３０がＭＰＤ４６を検査することで、図３及び図５の場合には、特別なビデオセグメントに対して特定されたパラメータへとＲＲＭパラメータを調整してもよく、図６及び図８の場合には、ＨＴＴＰゲット要求に対して影響を与えてもよい。

【0096】

ＵＥ４０は、所謂チャネル品質フィードバック（ＣＱＩ）と呼ばれる無線チャネルの品質尺度と、（表３に示すような）ビデオバッファのバッファレベルとを、ｅＮＢのＲＲＭエンティティ３０に対して信号伝達してもよい。周期的又は非周期的な時間ベースで、ピーク対平均値比（ＰＡＲ）、例えばピーク対平均レート比（ＰＡＲＲ）のインジケータを送信することで、フィードバック情報を削減させてもよい。この情報によって、ｅＮＢのＲＲＭエンティティ３０は、ＨＴＴＰストリーミング・サービスに関するバッファ認識を有する状態で、多数ユーザーのスケジューリングを実行できる。

【0097】

ＰＡＲ及び／又はＰＡＲＲの計算に使用されるべき物理レイヤ（ＰＨＹ）データのチャネル品質尺度は、ＬＴＥ標準内で定義された以下のパラメータの１つ又は任意の組合せを含んでもよい。
・ＣＱＩ：チャネル品質インジケータ(Channel Quality Indication)
・ＲＩ：ランクインジケータ(Rank Indicator)
・ＰＨＹレイヤデータレート(PHY layer data rate)
・ＰＨＹレイヤ遅延及びジッター(PHY layer delay and jitter)
・ＲＳＲＰ：参照信号受信パワー(Reference Signal Received Power)
・ＲＳＳＩ：受信信号強度インジケータ(Received Signal Strength Indicator)
・ＲＳＲＱ：参照信号受信品質(Reference Signal Receive Quality)

【0098】

ここで、ＲＳＲＱは次式により定義される。

【0099】

ＲＳＲＱ＝Ｎ×ＲＳＲＰ／ＲＳＳＩ
ここで、ＮはＲＳＳＩ値が測定された資源ブロックの数である。

【0100】

上述した構成の詳細から明らかなように、図３と図６との無線資源管理部３０は、クライアントのユーザーエンティティから基地局に対してそれぞれ送信された物理レイヤ上の閉ループフィードバックを利用することができる。つまり、送信者側のシステムは、クロスレイヤ情報に基づいてビデオ送信を向上させることができるが、他方、受信者側は、クロスレイヤ・インターフェイスを何も必要としないことになる。更に、ＲＲＭは、チャネルに基づいて、１つ又は複数のクライアントに対して、そのビデオ品質を向上させるために、更にどれだけ大きい帯域幅を割り当てることができるかを推定できる。

【0101】

例えば、図３と図６とに示すＲＲＭ３０は、ユーザーエンティティに割り当てられる平均帯域幅を決定し、更に、その決定された平均帯域幅から、各クライアント４４によって、メディアコンテンツ４４のメディア・プレゼンテーション記述４６の内のどのバージョンが現在ダウンロードされているかについて予測するよう構成されてもよい。これにより、クライアントの状態を発見する簡素な方法が形成できる。各クライアントについて、ＲＲＭ３０は単に、各クライアント４０が受信している平均帯域幅を識別し、更にその結果から、どのメディアレートをそれが選択し得たかを予測するだけでよい。

【0102】

更に、上述したように、無線資源管理部３０が、メディアバッファリング状態情報、即ちそれぞれのユーザーエンティティにおいて動作しているクライアントのバッファリング状態を示す情報を導出するよう試みることも可能である。換言すれば、無線資源管理部３０は、ユーザーエンティティ３４の受信状態に関する情報を利用して、それぞれのユーザーエンティティが、効果的かつ正確に、割り当てられた帯域幅を実際に受信することができるかどうかという点について確認することができる。この情報を使用して、無線資源管理部３０は、最小帯域幅情報を考慮することでユーザーエンティティにおいて動作しているクライアントのバッファリング状態をエミュレートでき、その最小帯域幅情報は、上述したように無線資源管理部３０にとってはメディア・プレゼンテーション記述４６からアクセス可能である。このような方法で、無線資源管理部３０は、ユーザーエンティティ３４上で実行しているクライアント４０のバッファリング状態をエミュレート又はシミュレートすることができ、更に、そこからクライアントの挙動やクライアントの優先度を推論することができる。例えば、シミュレーションの結果、バッファがメディアデータ不足であることが分かるクライアント４０に対しては、シミュレーションの結果、バッファがフルであることが分かるクライアント４０よりも、高い優先度が与えられてもよい。

【0103】

当然ながら、上述したようにバッファリング状態をシミュレートする可能性、又はクライアント４０とそれぞれのサーバーとの間のデータトラフィックからメディアバッファリング状態情報を導出する可能性は、演算的にはかなり複雑であり、得られる正確さは低くなり得る。

【0104】

このように、図３の実施形態は拡張可能であってもよく、その方法は、無線資源管理部３０がまた、（現在の資源状態情報に加えて）メディア・プレゼンテーション記述４６に依存するだけでなく、それぞれ１つ又は複数のクライアント４０が動作している各ユーザーエンティティからのチャネル品質フィードバックから導出されるメディアバッファリング状態情報にも依存して、基地局３２の通信資源をユーザーエンティティに対して割り当てるよう構成されてもよい。特に、導出されたメディアバッファリング状態情報は、各ユーザーエンティティ３４の推定された有効ビットレートを使用して満たされかつメディア・プレゼンテーション記述４６内に示されたプレゼンテーション帯域幅においてエンターされた各ユーザーエンティティクライアント４０のバッファをシミュレートする、上述のようなシミュレーションによって導出されたものであってもよい。

【0105】

勿論、図６の無線資源管理部３０についても同様のことが言える。つまり、ユーザーエンティティクライアント４０のメディア要求の影響に関する決定を行うために、シミュレーションの結果が無線資源管理部３０によって使用されてもよい。

【0106】

更に、図７の実施形態もまた上述の意味で拡張されてもよい。つまり、図７の資源管理部７４は、現在の資源状態情報を使用して、クライアントのメディアバッファ状態をシミュレートし、その結果に応じて、無線通信コミュニティの一部として、２つの貪欲なクライアント４０から基地局通信資源を保護するよう行動してもよい。

【0107】

しかし、上述したように、クライアントのバッファリング状態の「シミュレーション」は高い不確実性を有する項目である。従って、図３と図６との実施形態に修正を加え、無線資源管理部３０は、ユーザーエンティティクライアントのバッファリング状態を導出又はシミュレートする必要がなく、その代わり、クライアント４０からのデータトラフィック内の明示的なメディアバッファリング状態情報を利用するようにしてもよい。クライアント４０からサーバー４２へのデータトラフィック内のメディア・プレゼンテーション記述４６とメディアバッファリング状態情報とに基づいて、無線資源管理部３０は、さらに正確なバッファリング状態推定に基づくさらに正確な通信資源割り当てを実行することもできる。クライアント４０からのデータトラフィック内のメディアバッファリング状態情報において、後者は、現在のメディアバッファリング状態、即ち現在のメディアバッファの充満レベル(fill level)を明示的に示してもよい。具体的な構成の可能性については、以下に更に詳細に説明する。

【0108】

一方で、別の実施形態に従えば、図３の無線資源管理部３０は、クライアント４０からのデータトラフィック内のメディアバッファリング状態情報には依存するが、メディア・プレゼンテーション記述４６には依存しないで、ユーザーエンティティに対する基地局３２の通信資源の割り当てを実行してもよい。複数のユーザーエンティティクライアント４０のメディアバッファリング状態を単に調査するだけで、無線資源管理部３０が、ユーザーエンティティに対する利用可能な基地局通信資源のより公平な分配を実行できるようにすることも可能である。

【0109】

このように、図３は、ユーザーエンティティの内の１つにおいて動作しているクライアントのメディアバッファリング状態情報に依存して、ユーザーエンティティ３４に対して基地局３２の通信資源を割り当てるよう構成された無線資源管理部３０に関連していてもよい。ユーザーエンティティに対する通信資源の割り当ては、基地局（３２）の通信資源が適切な割合で割り当てられるべきユーザーエンティティ３４の数や、ユーザーエンティティと基地局との間で交換されるべき通信データの種類などのような、上述した可能性の１つ又は複数に基づいて実行されてもよい。更に、ユーザーエンティティへの通信資源の割り当てに際し、上述した設定はメディアバッファリング状態情報、即ちサブキャリア、時間スロット、及び基地局セルの空間的カバー範囲の内の１つ又は複数に基づいて調整され得る。上述したように、メディアバッファリング状態情報は、クライアント４０からサーバー４２へのデータトラフィック内における明示的な信号伝達から抽出されることもでき、又は、ユーザーエンティティ３４から基地局３２へのチャネル品質フィードバックに基づいて、ユーザーエンティティのバッファリング状態をシミュレートすることで導出されてもよい。

【0110】

このようにシミュレートする可能性はまた、図６及び図７の実施形態にも関連する。即ち、現在の資源状態情報とメディア・プレゼンテーション記述４６とを使用する代わりに、図６と図８の無線資源管理部３０と資源管理部７４とは、それぞれ、クライアント４０からのデータトラフィック内のメディアバッファリング状態情報に依存して、メディア要求６０の取り扱い方法に関する決定を実行するよう構成されてもよい。

【0111】

従って上述した実施形態は、次のような資源管理部を開示していると言える。即ち、サーバー４２からユーザーエンティティ３４において動作しているクライアント４０へのデータトラフィック内で、メディアコンテンツ４４の様々な帯域幅のバージョンを記述しているメディア・プレゼンテーション記述４６を検査し、メディアコンテンツ４４の所望のバージョンを要求しているクライアント４０からサーバー４２へのメディア要求６０を検査し、クライアント４０からメディアバッファリング状態情報を受信し、更に、そのメディアバッファリング状態情報とメディア・プレゼンテーション記述４６とに依存して以下の事項を決定する。（１）メディア要求６０をサーバーへと転送する。又は代替的に（２）修正済みのメディア要求がメディアコンテンツ４４のより少ない帯域幅のバージョンを要求するように、メディア要求６０を修正するか、若しくは、メディア要求６０をインターセプトし、利用不可の応答をサーバー４２からクライアント４０へと返送するように、サーバー４２に対してエミュレート又は指令する。

【0112】

図３、図６及び図７の代替的な説明として、上述された実施形態に関する可能な構成を以下に説明する。この更に詳細な構成は、「オーバー・ザ・トップ（ＯＴＴ）閉ループフィードバックを用いるＬＴＥを介したＤＡＳＨ」と呼ばれてもよい。このような構成の可能性に従えば、クライアントのBufferLevelは、オーバー・ザ・トップの直接的なクライアントフィードバック、例えば表３に定義されるBufferLevelのような品質尺度を使用するＬＴＥシステムのＤＰＩスケジューラ３０において、より詳細に追跡される。

【0113】

【表3】

【0114】

結果として得られる可能性のある構成を図９に示す。図９の構成を図５の構成の可能性と比較すると、図５の構成がユーザーエンティティ３４からＲＲＭ３０へのＬＴＥフィードバック９０によって拡張されていることが明らかである。ここで、後者、即ちＲＲＭ３０は、ＬＴＥフィードバック、即ちユーザーエンティティ３４からのチャネル品質フィードバックを使用して、より良好な通信資源レート割り当てＲを実行する。

【0115】

以下に、上述の実施形態に関し、この実施形態のクライアント４０についての幾つかの構成の詳細を説明する。上述したように、クライアントの挙動はそれぞれのクライアントイシュアによって自由に設定され得るものであり、上述した実施形態では、クライアントの挙動の説明に関して多くを語ってこなかった。しかし、上述の実施形態の完全な理解を促進するために、可能性のあるクライアントの挙動をクライアントがＤＡＳＨクライアントであると仮定して、以下に説明する。

【0116】

ＤＡＳＨは、「ＩＳＯ／ＩＥＣ ２３００９−１」に定義されているように、クライアント主導の適応技術であり、一方ではクライアントの挙動を特定せず、様々な構成に対する完全な自由度を認めている。しかしながら、クライアントによって報告されるＭＰＤとＱＭとは、そこからクライアントの挙動を予測できるような幾つかの重要な情報を含む。この重要な情報は、以下のような信号伝達を含む。
・@minBufferTime
・@bandwidth
・十分なデータが利用可能である場合には、ＴＣＰスループットとしてクライアントにより測定可能な、割り当てられたＬＴＥクライアントレートを暗示する。
・意図されたプレイアウト遅延／潜在的な停止(outages)に依存して、クライアントがＴＣＰスループットに適応する。
・クライアントによって報告されたＱＭ
・ビットストリーム切り替えフラグ

【0117】

ＤＡＳＨクライアントの目的は、ストリーミングされるコンテンツを、その機器の特徴に基づいてサポート可能な最高の品質で連続的に再生することである。連続的に再生するためには、クライアント側にあるバッファは、いかなる場合でも空になってはならない。ＭＰＤ内の@minBufferTimeは、クライアントに対し次のような約束をする。即ち、セッションの開始時に所定量のデータがクライアントのバッファに蓄積された場合、少なくとも@bandwidth内で示された値のような高いレートでクライアントがダウンロードするときには、クライアントは@bandwidthを有するよう信号伝達されたビデオバージョンを再生できるという約束である。従って、クライアントは、ビデオの再生を開始する前に少なくとも所定量のデータをプリバッファすることが期待されており、更に、クライアントのバッファ充満度における変化が、@minBufferTimeと比較したバッファ充満度の大きさに基づいて発生した場合には、異なる@bandwidthを有するビデオの異なるバージョンへと切り替えるよう期待されている。クライアントのバッファ充満度は基地局にとって未知であり、例えばトリックモードが使用されているときにはそれを推定することが困難又は不正確となる可能性があるため、ユーザーからのＱＭ報告（特に上述したＱＭ）がユーザー挙動を予測する上で有益なツールとなり得る。

【0118】

更に、ＤＡＳＨクライアントは、図１０に示すように２つの構成要素へとロジカリーに分割される。即ち、図７に示したようなＤＡＳＨアクセスクライアント４０ａとＭＰＥＧメディアエンジン４０ｂとの２つである。
・ＤＡＳＨアクセスクライアント４０ａ：このエンティティは、ＭＰＤ４６を解析し、スケジューリング・アルゴリズムを実行し、更に、フォーマット９２においてメディア６４をＭＰＥＧメディアエンジン４０ｂへと受け渡す役割を担う。
・ＭＰＥＧメディアエンジン４０ｂ：このエンティティは、メディアデータ９２を処理する役割、即ち復号化、再構築その他を担う。

【0119】

上述した図７の説明を参照すれば、ユーザーエンティティ及び／又はクライアントの上述した好都合な機能のいずれかを利用する、強化されたＤＡＳＨクライアントを構成するための、以下に記載する２つの可能な選択肢が存在することが分る。
・クロスレイヤＤＡＳＨアクセスクライアントを有する。このクロスレイヤ・アクセスクライアントは、物理レイヤから測定値を取得し、更なる可能性として、ＬＴＥネットワークからの追加的な信号伝達を受け取る場合もある。この追加的な情報を使用して、チャネルの更に良好な推定と強化された適応スケジューリングとが実行され得る。
・しかし、典型的には、既に実装されたＤＡＳＨクライアントが想定され、その場合、例えばブラウザ内でＤＡＳＨクライアントを実装する場合などのように、例えばクライアントバッファレベル又は所与の量のデータ内でダウンロードするために必要とされる時間などを監視することにより、より高度なレイヤで適応が発生する。この場合、１つの可能性は、その適応を管理する外部の「メディア管理部」要素（図８及び図９を参照）を持つことである。しかし、上述した管理部と同様に、ＤＡＳＨクライアントはこの点を認識しないであろう。このような「重複した」ＤＡＳＨアクセスクライアント（即ちＤＡＳＨアクセスクライアントもまた適応を実行すること）を回避するために、追加的な信号伝達がＭＰＤレベルにおいて必要となる。即ち、例えば@automaticSwitchingなどのように、ＤＡＳＨアクセスクライアントに対し、ＤＡＳＨクライアントの外、即ち受信装置内で「資源管理部」７４によって適応が実行されることを示す新たな属性が追加されてもよい。途中にあるサーバー又は何らかの装置がビデオのプロファイルに合わせてビデオレートを調整し、選択され且つ要求された表現に従ってレベルを調整する可能性があり、結果的にクライアントはいかなるメディアレート調整もすべきでないことをＭＰＤ内に含まれる@automaticSwitchingがクライアントに対して報せる。

【0120】

第２の場合、即ち「資源管理部」を有する場合を図１１に示す。図１１から分かるように、資源管理部７４は、上述のような資源管理部として動作するために、クライアント／サーバー・データトラフィックよりも低位のＯＳＩレイヤにおいてデータ１００を使用する。

【0121】

特に資源管理部７４は、メディアの適応及び要求を実行するか、又は、ＤＰＩも更に実行するか若しくはユーザーの要求を修正することなどが可能である。更に「メディア管理部」は、より高位のレイヤの情報だけが使用される通常のＤＡＳＨクライアントにおいて行われ得たであろう適応よりも高度な適応を実行するために、物理レイヤ情報及び資源割り当てについてＲＲＭと幾つかの追加的な信号メッセージを交換することもできる。

【0122】

図６と図７の実施形態、及びそれらに対応する図８などの構成に関して留意すべきことは、これらの図に記載された実施形態は別の方法で実現されてもよく、その結果としてもたらされる代替的な実施形態に従えば、より良好な資源管理を行うために、メディア要求の影響がメディア記述プレゼンテーションの影響によって置換されてもよい。しかしながら、これらの図に関する上述の機能と以下に記載する機能との組み合せも使用可能である。

【0123】

特に上述した図６の代替的な実施形態によれば、無線資源管理部３０は、ユーザーエンティティ３４において動作しているクライアントからサーバー４２へのメディア・プレゼンテーション記述要求を検査するよう構成されており、そのメディア・プレゼンテーション記述要求は、サーバー４２からメディア・プレゼンテーション記述４６を要求するものである。資源管理部３０は、次に、サーバー４２からクライアント４０へのデータトラフィック内のメディア・プレゼンテーション記述４６を検査して、現在の資源状態情報とメディア・プレゼンテーション記述４６とに基づき、以下の選択肢の中のいずれを使用すべきかを決定する。（１）メディア・プレゼンテーション記述要求への回答として、メディア・プレゼンテーション記述４６をクライアント４０に転送する。即ち、メディア・プレゼンテーション記述４６を無修正のままにする。又は、（２）メディア・プレゼンテーション記述４６をインターセプトし、メディアコンテンツ４４の様々な帯域幅のバージョンの適切な部分集合だけを記述するようにメディア・プレゼンテーション記述４６を削減し、メディア・プレゼンテーション記述要求への回答として、その削減されたメディア・プレゼンテーション記述４６をクライアント４０へと送信する。ここでも、無線資源管理部３０はクライアント４０に対し、メディアコンテンツの要求されたバージョンをそのより低い帯域幅バージョンへと変更するよう直接的に指令することはないが、しかし、クライアント４０が、メディアコンテンツ４４に対する更なるメディア要求を変更して、メディア・プレゼンテーション記述４６の削減に応じたより低い帯域幅バージョンを参照するようになることが十分予想される。

【0124】

ここで再度確認するが、上述した機能は、ユーザーエンティティから見て基地局の向こう側にある無線資源管理部３０のために利用可能であるだけではなく、ユーザーエンティティ自身の内部にある図７の資源管理部７４のためにも利用可能である。図７に関して上述した可能な構成の詳細はまた、図６と図７とで示した上述の代替的実施形態のそれぞれに対しても適用可能である。

【0125】

図６と図７とはまた、資源管理部を開示しており、その資源管理部は、ユーザーエンティティ３４において動作しているクライアント４０からサーバー４２へのメディア・プレゼンテーション記述要求を検査するよう構成されており、そのメディア・プレゼンテーション記述要求は、サーバー４２からメディア・プレゼンテーション記述４６を要求するものであり、メディア・プレゼンテーション記述４６はメディアコンテンツ４４の異なる帯域幅を持つ複数のバージョンを記述するものである。資源管理部は次に、サーバー４２からクライアント４０へのデータトラフィック内のメディア・プレゼンテーション記述４６を検査して、現在の資源状態情報とメディア・プレゼンテーション記述４６とに基づき、以下の選択肢の中のいずれを使用すべきかを決定するよう構成されている。即ち、（１）メディア・プレゼンテーション記述要求への回答として、メディア・プレゼンテーション記述４６をクライアント４０に転送する。又は、（２）メディア・プレゼンテーション記述４６をインターセプトし、それを修正する。

【0126】

例えば、上述のインターセプトと修正とは、メディアコンテンツ４４の異なる帯域幅からなる複数のバージョンの適切な部分集合だけを記述するように、メディア・プレゼンテーション記述４６を削減し、メディア・プレゼンテーション記述要求への回答としてその削減されたメディア・プレゼンテーション記述をクライアント４０へと送信する、資源管理部を含んでも良い。また、ＭＰＤ４６に対し、クライアント４０へのフィードバックとして使用されるべき情報を追加することも可能である。すなわち、例えば以下に説明する明示的なバッファ状態情報などの品質尺度をサーバー３２の代わりにＲＲＭ３０へと送信するようクライアント４０に指令するため、又は以下に詳細に説明するようにユニキャストからマルチキャストへのプロトコルの変更を指示するため、又は、中間にある資源管理部自身がクライアント４０によって要求されたメディア４４の調整を実行する可能性があり、クライアント４０はレートを調整すべきでないことをクライアント４０に対して報せるため、などである。当然ながら、プロトコル変更の指示は、指示されたプロトコル変更に対応するプロトコル変換(protocol translation)をＲＲＭ３０が実行するか、又はサーバー３２など別の構成要素に実行させることによって、実現されてもよい。

【0127】

メディア要求に影響を与える場合として、資源管理部は、メディア・プレゼンテーション記述４６の中で、メディアコンテンツ４４の所望のバージョンとして関連するより低い最小帯域幅を持つメディアコンテンツ４４のバージョンを識別するために、メディア・プレゼンテーション記述４６を検査してもよく、より低い最小帯域幅が関連付けられたバージョンが存在する場合には、資源管理部は現在の資源状態情報に依存して前記決定を実行する。資源管理部は、無線資源管理部であってもよく、更に、クライアントが動作しているユーザーエンティティを含む複数のユーザーエンティティに対する基地局の通信資源の割り当てを実行してもよい。しかしながら、資源管理部は代替的に、ユーザーエンティティ内におけるその送受信ステージ７０とクライアント４０との間に配置されてもよく、その場合、資源管理部は現在の資源状態情報を送受信ステージ７０から取得してもよい。更に、資源管理部は、現在の資源状態情報に含まれるユーザーエンティティから基地局へのチャネル品質フィードバックに基づいて、ユーザーエンティティのバッファリング状態をシミュレートしてもよく、かつユーザーエンティティのバッファリング状態に依存して前記決定を実行してもよい。

【0128】

次に、上述した実施形態に関する可能な構成について詳細に説明するが、これらの詳細は、ＤＡＳＨプッシュサービスの形態を持つメディアデータのストリーミングを実現させる可能性に関するものである。

【0129】

ＬＴＥを介するＤＡＳＨサービスは、所謂プッシュサービスによって強化されることができる。例えば図１２を参照されたい。可能性のある２つの手法が存在する。
１．ＨＴＴＰサーバー・プッシュ(Server Push)
・ＤＡＳＨクライアント４６はＨＴＴＰサーバー４２に接続し、サーバー４２はＴＣＰ／サービス・ハンドシェーク及びトンネル・セットアップを実行する。
・サーバー４２は、次にＤＡＳＨクライアント４０に対してビデオデータをプッシュする。
２．ＬＴＥプロキシ・プッシュ(Proxy Push)
・ＤＡＳＨクライアント４０は、ＴＣＰ／サービス・ハンドシェーク及びトンネル・セットアップを実行するＬＴＥ ｅＮＢ内のＬＴＥプロキシサーバーに接続する。
・ＬＴＥ ＲＲＭエンティティ３０は、ＨＴＴＰゲットを使用して、ＨＴＴＰサーバー４２からビデオデータ表現をリトリーブする。
・ＬＴＥ ＲＲＭ３０は、ＤＡＳＨクライアント１２に対してビデオデータをプッシュする。

【0130】

プッシュ情報は、プッシュ表現を照会するものであり、ＭＰＤ内で特定されてもよい。ＳＶＣ又はＭＶＣの場合には、この情報はＤＡＳＨクライアントに対してプッシュされるべきレイヤを含んでもよい。ここで、ＭＰＤ４６は、無線資源の使用が他のユーザーに対しても最適化されるように、ｅＮＢ ＲＲＭ３０に対し、潜在的なレート切換えについて情報を与える。例えばＬＴＥプロキシ・プッシュの場合、ＬＴＥ ＲＲＭ３０は、他のユーザーのために資源を節約する目的で、より低い品質とより低いレート要件を有するサービスをプッシュすることを決定することができる。

【0131】

換言すれば、基地局は、上述した全ての実施形態において、プロキシ・プッシュ処理を実行するためのサイトとしての役割を担うことができる。更に正確には、無線資源管理部もそのようなサイトとしての役割を担うことができる。

【0132】

図６の実施形態の更なる代替的な説明を試みる。ここで、以下の代替的な説明においては、次の点を理解すべきである。即ち、以下に説明する無線資源管理部の機能は、無線資源管理部３０がクライアントとサーバーとの間のデータトラフィックに影響を与えるという、上述した無線資源管理部の空間的機能を置換するものでもよく、又は、無線資源管理部３０の追加的な機能を表すものでもよいという点である。

【0133】

いずれの場合でも、以下に説明する実施形態によれば、図６の無線資源管理部３０は、ユーザーエンティティ３４に対して基地局３２の通信資源を割り当てるほかに、複数のユーザーエンティティ３４において動作しているクライアント４０と１つ又は複数のサーバー４２との間のデータトラフィックを調査するよう構成され、その目的は、そのデータトラフィック内に共通のメディアコンテンツに関連するメディア・プレゼンテーション記述４６が存在するか否かについてチェックするためである。次に、そのチェックに基づいて無線資源管理部は以下の決定を下す。即ち、（１）クライアント４０に対し、メディアコンテンツ４４のユニキャストバージョンのほかに、共通のメディアコンテンツのマルチキャストバージョンを提供する。又は、（２）共通のメディアコンテンツ４４をダウンロードしているクライアント４０に対し、ユニキャスト・プロトコルからマルチキャスト・プロトコルへのプロトコル変更を起こさせる。

【0134】

しかし、上述した機能はまた、基地局の通信資源をユーザーエンティティに割り当てる役割を担う図６の無線資源管理部３０から見て外部の又は分離された無線資源管理部の中で実行されてもよい。クライアントとサーバーとの間のデータトラフィックの調査と、クライアントの中の２つ以上によってそれぞれのメディア・プレゼンテーション記述要求を介して共通して注文されたメディア・プレゼンテーション記述があるか否かについてのチェックとは、割り当て処理から独立して実行されてもよい。それぞれのクライアント４０が受信するバージョンをユニキャストバージョンから同一コンテンツのマルチキャストバージョンへと切り替えることの結果を考慮すると、結果的に得られる利点は容易に理解できるものである。このようなクライアントのために必要なビットレートが単に１つのストリーミングへと縮約され得るという事実から、上述の切り替えにより、他のクライアントのためにより多くの利用可能なビットレートがもたらされることが分る。

【0135】

上段では選択肢（１）と（２）とを挙げたが、言うまでもなく、本発明に係る無線資源管理部が選択肢の両方を実行するよう実際に構成されている又は実行可能である、と理解されるべきではない。むしろ無線資源管理部は、チェックの結果に基づいて、（１）又は（２）のいずれの選択肢がトリガーされるべきであるか否かを決定する。更に詳細には、１つ又は複数のサーバーから複数のクライアントの内の異なる各クライアントへのデータトラフィック内に共通のメディアコンテンツ４４に関連するメディア・プレゼンテーション記述がない場合には、無線資源管理部は、クライアント４０とサーバー４２との間のデータトラフィックを無変更のままにおいておく。この場合、無線資源管理部は選択肢（１）も選択肢（２）も実行しない。更に詳細には、データトラフィックのいずれかを操作することが多くのビットレート節約につながらない場合には、無線資源管理部は、それぞれのデータトラフィックを無変更のままにおいておく。しかし、複数のユーザーが、サッカーの試合又は何らかの他のライブニュースなどのようなライブストリーミングにそれぞれ切り替えるよう決定する場合を想像されたい。この場合、これら全てのクライアントに対するユニキャスト・ストリーミングからマルチキャスト・ストリーミングへと切り替え可能であることは望ましいと考えられる。第１の選択肢に従えば、データトラフィック内で重複したメディア・プレゼンテーション記述が現れている場合には、メディアライブストリーミングに関する１つのメディア・プレゼンテーション記述を各メディア・プレゼンテーション記述要求を介して要求した複数のクライアント４０に対して、無線資源管理部がメディア・プレゼンテーション記述を操作するよう構成されている。その修正により、元来のメディア・プレゼンテーション記述は、メディアコンテンツ４４のユニキャストバージョンが利用可能であることの他に、又はその代わりに、マルチキャストバージョンだけが利用可能となるように変更される。従って、少なくともこれらの新たに加入してきたクライアント４０は、マルチキャストバージョンを考慮するか、又は考慮せざるを得ないであろう。第２の選択肢に従えば、データトラフィック内で重複するメディア・プレゼンテーション記述が現れている場合、無線資源管理部３０は、例えば共通のメディアコンテンツ４４を要求しているクライアントからのそれぞれのメディア要求を変化させて、ユニキャストバージョンの要求からマルチキャストバージョンの要求へと変更させるよう構成されてもよい。他の代替的な修正方法もまた可能である。

【0136】

図６はまた無線資源管理部を開示しており、その無線資源管理部は、複数のユーザーエンティティ３４において動作している複数のクライアント４０と１つ又は複数のサーバー３２との間のデータトラフィックを検査し、その１つ又は複数のサーバー３２から複数のクライアント４０の内の異なるクライアントへのデータトラフィック内に、共通のメディアコンテンツ４４に関連しているメディア・プレゼンテーション記述が存在するか否かをチェックし、更に無線資源管理部は、そのチェックに基づいて、複数のクライアント４０に対し共通のメディアコンテンツ４４のマルチキャストバージョンをそのメディアコンテンツ４４のユニキャストバージョンとは別に提供するか、又は、無線資源管理部は、そのチェックに基づいて、共通のメディアコンテンツをダウンロードしつつある複数のクライアント４０に対しユニキャスト・プロトコルからマルチキャスト・プロトコルへのプロトコルの変更を行わせる。この無線資源管理部はまた、ユーザーエンティティ３４に対する基地局３２の通信資源の割り当ての役割を担うことも可能である。上述した実施形態は、他のいずれの実施形態と組み合わせることもできる。

【0137】

上述した実施形態の更に具体的な構成を以下に説明する。この具体的な構成によれば、ＤＡＳＨのユニキャストとブロードキャスト／マルチキャストとの切り替えが実現される。上述したように、このような切り替えはライブサービスに関してセルの使用を減少させるために有利である。ここで注意すべきは、上述の実施形態は、１つ又は複数の共通の基地局３２と関連している、又はそれらに固定されているユーザーについて考慮する場合にだけ、使用可能となるだけではないことである。むしろ、無線ネットワークは全体的に、その全てのセル及び基地局自身を相互接続しているバックボーン（幹線）を含め、ユニキャスト・プロトコルを使用するメディアコンテンツ・ストリーミングを要求している過剰に多数のクライアントによって不注意に逼迫させられることが多く、そのストリーミングは代替的に、マルチキャスト・プロトコルによってもまた実行され得ることが多い。

【0138】

このように、基地局／ＬＴＥネットワークは、ユニキャスト・ユーザーに対してライブサービスを配信するが、サービスに対するユーザー要求の数が増大する場合には、サービスは、バックボーンと移動ネットワーク・インフラストラクチャの無線リンクとに対するデータレート需要を低減させるため、マルチキャスト／ブロードキャストのサービスへと切り替えられるべきである。
・例えばＨＴＴＰからＦＬＵＴＥ（ＵＤＰを介するブロードキャストファイル・ダウンロード・プロトコル）への切替え。

【0139】

ユーザーはＨＴＴＰサービスに対するデータサービスを要求する。Ｈｔｔｐサーバーは、ＦＬＵＴＥプロトコルを介してＨＴＴＰゲット要求をリターンする。
<RedundantURL>http://cdn1.example.com/</RedundantURL>
<RedundantURL>flute://cdn2.example.com/session-description.sdp</RedundantURL>

【0140】

例えばセッション記述プロトコルSDP [IETF RFC 4566]におけるＦＬＵＴＥ(File Delivery over Unidirectional Transport:単方向トランスポートを用いたファイル配信)セッションの記述に対するリンクを含む「Redundant URL」としてのＭＰＤ内の指示に基づいて、プロトコル変更が適用されてもよい。Redundant ＵＲＬは、ＨＴＴＰからＦＬＵＴＥへのプロトコル変更などのような、代替的な伝送特性を有する代替的なメディアロケーションを示す。更に、プロトコル変更は、ユニキャストからマルチキャストアドレスへの資源位置の変更をも含んでもよい。

【0141】

図３と図６及び対応する構成例に関して再度明確に注意すべき点として、１つのユーザーエンティティが現時点において２つ以上の基地局３２によってサービス提供され得るという点が挙げられる。つまり、ユーザーエンティティは、ＲＲＭスケジューラがそのためにＲＲＭを実行する基地局とは異なる基地局を介して、ＭＰＤを受信することが可能である。ＭＰＤを受信するために、端末は基本的なＩＰ接続性を必要とし、この場合、例えばＬＴＥのＲＲＭユニットを使用するＬＴＥなどの無線システムを介して確立される。従って、ＭＰＤを受信するために、ＵＥはＲＲＭによっていくらかの資源を割り当てられる必要がある。現在のＬＴＥ Ｒｅｌ.８／９においては、端末は、（例えば１０又は２０Ｍｈｚの帯域幅を有する２．６ＧＨｚなどの所定の周波数上で動作する）単一の基地局であって、特有のセル識別子(Cell-ID)を有する基地局に接続される。この場合、ＵＥは、基底にあるＬＴＥネットワークを使用してＭＰＤをゲットできるだけである。次のステップでは、マルチバンド技術が既存のＬＴＥと共に使用可能である。マルチバンドとは、例えば８００ＭＨｚで動作している１つの基地局と、２．６ＧＨｚで動作している別の基地局とを有する状態を意味する。各々の基地局がそれ自身のセルＩＤを有しているので、１つの端末は同時に両方の基地局へと接続され得る。そのため、１つの端末が２つ以上のＩＰエントリポイントを有することができ、この例では２つのエントリポイントを有するが、１つの基地局をＭＰＤをリトリーブするために使用し、他の１つを実際にデータをリトリーブするために使用できる。この場合、その端末は両方のＲＲＭユニットを独立して利用することもできる。これはまた、他の技術へと拡張することもでき、例えばＭＰＤを配信させるためにＬＴＥを使用して、データをゲットするためにＷｉｆｉを使用するなどである。このようなマルチバンドの手法は、クライアント内のある種の情報を必要とする場合があり、それにより、現在のネットワーク負荷又はチャネル品質などに基づいて、どの技術を使用すべきかを判断する。

【0142】

クライアント４０に関連付けられたバッファ状態をシミュレーションする上述の説明に関し、シミュレートされたバッファ状態は、ユーザーエンティティ３４の内部ではない他の場所に位置する別のバッファであってもよい点に留意すべきである。例えばシミュレートされたバッファリング状態は、実際にはユーザーエンティティの送受信ステージ内のＭＡＣレイヤバッファに関連するものであってもよい。例えば、送受信ステージ７０内の上述したＭＡＣレイヤバッファの一例、即ちバッファ１００を示す、図１３を参照されたい。バッファ１００はまた、基地局３２内に位置していてもよい。換言すれば、図１３はクライアント４０の可能な構成を含む、クライアント４０とサーバー３２との間のデータ経路の一部の可能な構成を示す。上述した全ての図とは異なり、図１３は更に、ＭＡＣレイヤバッファ１００などのようなＭＡＣレイヤエンティティ、即ちクライアント４０に対しては反対側、即ちＲＲＭ３０の向こう側に位置するネットワークバッファを示す。ユーザーエンティティの送受信ステージ７０に対応する基地局の送受信ステージ１０２もまた、完全を期すために示されている。送受信ステージ７０もまた、とりわけ他のＭＡＣレイヤバッファなどのようなＭＡＣレイヤエンティティを含むが、しかし、図１３では示されていない。ここで、図３のＲＲＭ３０もまた、ユーザーエンティティのバッファ状態をシミュレートするために、後者のバッファをクライアント４０に対するキャッシュされたメディアコンテンツの量に関して監視することができる点に注意すべきである。

【0143】

更に注意すべき点として、上述した機能に対して追加的又は代替的に、図７又は図１３のＲＭ７４は、図３のＲＲＭ３０の作業であって、ＭＰＤを導出する目的でサーバーとクライアントとの間のデータトラフィックを調査する作業を軽減させることができる。このように、資源管理部７４は、メディア・プレゼンテーション記述を完全に解析し検査して、それを、特定のＨＴＴＰストリーミングセッションなどのような要求されたメディアサービスに関してクライアントによってサポートされている潜在的なビットレート・オペレーションポイントを含む、部分集合のメディア・プレゼンテーション記述だけへと変換する(translate)ために、使用されてもよい。つまり、変換されたメディア・プレゼンテーション記述は、それぞれのサーバーにおいて利用可能なメディアコンテンツ４４のバージョンの不完全な記述、即ち、図３に関して上述した説明の意味においてはある種のメディア・プレゼンテーション記述を表現していてもよい。上述したように、個々のバージョンの情報密度の間の順位、即ちそれぞれのバージョンの品質の非常に粗い測定値だけが、変換済みのメディア・プレゼンテーション記述内で信号伝達されてもよい。代替的に、上述したように、各バージョンに関し、ユーザーに対してそれぞれのバージョンを提供するために必要な最小帯域幅が、変換済みのメディア・プレゼンテーション記述内で、各関連するメディアコンテンツ・バージョン、即ちユーザーエンティティの機器に従ってユーザーエンティティにおいてユーザーに対して提供可能であるメディアコンテンツ・バージョンに関し、信号伝達されてもよい。この変換済みＭＰＤは、次に、例えばＰＨＹ／ＭＡＣレイヤ上で無線資源管理部３０へと転送されてもよく、その目的は、無線資源管理部がこれらのビットレート・オペレーションポイントを使用して、その制御下にある特定のクライアントと他のクライアントに対する更なるスケジューリングと無線資源割り当て決定とを行わせるためであってもよい。適応性を可能にするビデオサービス、即ちそれぞれのビットレート・オペレーションポイントをサポートできるサービスのタイプが、非特許文献１９に定義されるようなサービス品質(Quality of Service)パラメータ信号を使用して示されてもよい。従って、サービスの特性を指示するために、「適応的非対話型ビデオ(Adaptive Non-Conversational Video)」及び「適応的ビデオ(Adaptive Video)」などの新たなトラフィッククラスが表６に追加されてもよい。これらの新たなクラスは、無線資源管理部における資源割り当てのためにそこから選択されるべきレートの集合の指示、即ち変換済みＭＰＤの指示を、更に要求する可能性がある。最小の保証付きビットレート(ＧＢＲ）の信号化は、サービスのための最小レート及び／又は他の有意なオペレーションポイントの信号化を許可するよう拡張される必要がある。最小ビットレートが関する限り、変換済みのメディア・プレゼンテーション記述は、この最小ビットレートを、ＴＣＰレベルなど高位のＯＳＩデータトラフィックレベル、又はより低位のあるＯＳＩレイヤレベルにおいて測定されるビットレートに関して、例えば基地局又は無線資源管理部３０によって割り当てられるべき最小ビットレートに関して、指示してもよいことに留意すべきである。実際に割り当てられ伝送されるビットレートと、メディアコンテンツの伝送において実際に有効なビットレートと、の間の不一致についての上述した考察を参照されたい。その場合の不一致は、例えばパケット損失及びＮＡＣＫ又はＡＣＫに基づく再伝送に由来するものである。

【0144】

上述したように、実際のメディア・プレゼンテーション記述４６から導出された変換済みメディア・プレゼンテーション記述の、ユーザーエンティティ３４内にある資源管理部７４による伝送は、上述した「適応的非対話型通信」などのような、それぞれユーザーエンティティと基地局との間で交換されるべき新たなタイプ又は種類の通信データを導入することと、この新たな通信データタイプ、即ちこの専用のベアラ（dedicated bearer)の活性化のプロトコルプロセス内で変換済みＭＰＤを伝送することにより、ＬＴＥなどいずれかの既存の無線資源ネットワークへと統合されることが可能である。図１５は、この可能な統合の実例をより詳細に示す。ここでは例示的にＬＴＥを無線資源ネットワークの代表例として使用しているが、しかし原則的に、図１５の実施形態は他の無線資源ネットワークへと容易に転換され得る。特に、図１５は、そのような例示的ベアラ、即ち「適応的非対話型通信」を作成し、変換済みメディア・プレゼンテーション記述を無線資源管理部３０へと伝送する中で実行される連続的なステップを示している。特に図１５は、これら全てのステップを、時間軸１１０に沿った時間的順序で、以下により詳細に説明するそれぞれのブロック及び関係する矢印によって示すものである。これらブロック及び関係する矢印は、それぞれのステップに関係するそれぞれのエンティティに亘って延びるように、水平方向に示されており、それらエンティティとは、データトラフィックチェーンのエンティティであって、ユーザーエンティティ４０と、基地局３２と、無線資源管理部３０と、移動性管理エンティティ１１２と、パケットゲートウェイ１１４と、メディアサーバー４２とである。上述したように、移動性管理エンティティ１１２はまた、無線資源ネットワークの全ての基地局と接続されており、少なくとも部分的には、無線資源管理部３０と同じハードウエア上に実装されることも可能である。また上述したように、移動性管理エンティティ１１２は、ユーザーの支払い準備口座からの引き落としなどのユーザーのアクセスデータを管理する役割や、ユーザーのプロファイルを管理する役割を担い、そのプロファイルは、それぞれのユーザーに対して割り当て可能な最大帯域幅などのような所定のユーザーの権利や、所定の通信データタイプ／種類に対する制限などを示すものである。更に、移動性管理エンティティ１１２は、１つの基地局セルから他の基地局セルへと移動するユーザーエンティティのハンドオーバー（受け渡し）を処理する役割を担うこともできる。パケットゲートウェイ１１４は、エンティティ４０と３２と３０と１１２とが属している無線資源ネットワークを、外部即ちインターネット又はその他へとインターフェイスさせる役割を担う。無線資源管理部３０と移動性管理エンティティ１１２とを１つのユニットへとまとめる可能な統合を、破線１１６によって例示的に示す。ここで、点線１１８は、無線資源管理部３０が基地局３２の内部に配置され得るという可能性を示す。

【0145】

図１５から分かるように、ユーザーエンティティ４０が、例えばインターネットに対する低複雑性のアクセスを実行するなどの無線資源ネットワークを介した最小タスクを実行できるように、ユーザーエンティティ４０は既に無線資源ネットワークと接続されており、デフォルトベアラ(default bearer)は既に活性化されている、ということが推定される。接続とデフォルトベアラの活性化とのステップは１１６で示す。より詳細には、ユーザーエンティティのドメインが関係する限り、ステップ１１６は、送受信ステージ７０によって実行される。次に、ユーザー又はユーザーエンティティ３４におけるクライアント４０は、ＭＰＤ要求１１８を、本件の例ではデフォルトベアラセッションを使用して、メディアサーバー４２に対して送信する。メディアサーバー４２はステップ１２０においてＭＰＤを返送し、ステップ１２２では、ユーザーエンティティ３４内の資源管理部７４がこのＭＰＤを解析して、上述したようにステップ１２０のＭＰＤを変換済みＭＰＤへと変換する。次に、専用ベアラ活性化、例えば「適応的非対話型通信」の活性化などがステップ１２４においてトリガーされる。例えばトリガー１２４は、メディアコンテンツを要求しているユーザーエンティティ３４のユーザー又はその場所にいるクライアント４０によって、引き起こされていた可能性もあり、そのメディアコンテンツは、ステップ１２２において解析されたＭＰＤが言及したものであってもよい。トリガー１２４に応答して、資源管理部７４と送受信ステージ７０とが協働し、ベアラ資源割り当て要求(bearer resource allocation request)をステップ１２６において基地局３２へと送信する。基地局３２は、その指令を受けて、ステップ１２８において、それぞれの割り当て要求を無線資源管理部３０と移動性管理エンティティ１１２とに対してそれぞれ転送する。割り当て要求は、例えば以下により詳細に説明するシンタックスを使用する、上述の変換済みメディア・プレゼンテーション記述を含む。次に、移動性管理エンティティ１１２は、パケットゲートウェイ１１４に対し、ステップ１３０においてベアラ資源コマンド(Bearer Resource Command)を使用してそれぞれのベアラ資源が作成されるべきであると伝達する。この場合、作成そのものはステップ１３２において実行される。従って、ステップ１２８以降は、変換されたメディア・プレゼンテーション記述のコンテンツは無線資源管理部３０にとって既知となる。しかし、専用ベアラの活性化は未だ確認されていない。従って、移動性管理エンティティ１１２は、ステップ１３４において専用ベアラ活性化要求を基地局３２に対して送信することにより、別の肯定応答ルーチン(acknowledgment routine)を開始する。基地局３２は、ステップ１３６において、この専用ベアラ活性化要求をユーザー３４へ、特に送受信部７０へと転送する。次に、ステップ１４０において、送受信ステージ７０は基地局３２に対して専用ベアラ活性化要求の受領を信号伝達し、次に、基地局はステップ１４２において、無線資源管理部３０と移動性管理エンティティ１１２とに対して同様の伝達を行う。その時以来、無線資源管理部３０は、ステップ１２０から１２８までを介して資源管理部７４から資源管理部３０へと信号伝達された変換済みのメディア・プレゼンテーション記述を使用して、上述した無線資源の割り当て、即ちスケジューリングを実行することが可能となる。このようにして、ユーザーエンティティ３４におけるクライアント４０とメディアサーバー４２との間のメディア伝送セッション１４４は、基地局３２と無線資源ネットワークとによってサービス提供される全てのユーザーエンティティに対するそれぞれの無線資源割り当てを考慮する上で効率的といえる方法で、無線資源管理部３０によって制御されてもよい。

【0146】

図１５に関して注意すべき点は、一般的に、専用の無線ベアラをセットアップする方法として２つの可能性があることである。第１の可能性は、クライアント主導である。この場合、ＵＥ３４は、図１５に示すように、デフォルトベアラを介してインターネットに対して接続されている。クライアント４０によって以前に発信されたＭＰＤ要求１１８への応答１２０に基づいて、ユーザーエンティティのＲＭ７４は、対応するＭＰＤファイルを受信して検査し、専用の無線ベアラをしかるべくトリガー（１２４）する。この作業は、移動性管理エンティティ１１２（ＭＭＥ）に対してＥＳＭベアラ資源割り当て要求を送信（１２６）して、専用ベアラ活性化をトリガーすることによって実行される（非特許文献２０の第８．３．８章を参照）。このメッセージ１２６は、サービス情報の要求された進化型パケットシステム（evolved packet system:ＥＰＳ）品質、即ち変換済みＭＰＤを定義するある情報要素（ＩＥ）を含む。

【0147】

可能性のある他の方法は、ネットワーク主導である。この場合、Ｐ-ＧＷ（パケットゲートウェイ）１１４が、要求されたＱｏＳベアラをハンドオーバー処理の間に保持するために必要な無線ベアラのセットアップをトリガーする。両方の場合に、ＥＳＭ活性化専用ベアラ要求(EMS Activate Dedicated Bearer Request)メッセージ（非特許文献２０の第８．３．３章を参照）が送信されて、このメッセージは、後段に記載する表に示すサービス情報のＥＰＳ品質（非特許文献２０の第９．９．４．３章を参照）を含む。この表は、（非特許文献２０と比較して）拡張又は修正されており、最小のみ及び代替的なより高いビットレートを有する保証付きビットレート（ＧＢＲ with minimum only and alternative higher-bitrates)と、代替的ビットレートを有する非保証のビットレート（Non-ＧＢＲ with alternative bit rates)とのための信号伝達、即ち変換済みＭＰＤを含む。図１５に示すように、ＵＥが専用ベアラをトリガーする場合には、ＭＰＤ内で見つかる代替的ビットレートなどの情報要素を、ＵＥが提供することになる。ネットワークが専用ベアラをトリガーする場合には、代替的ビットレートと変換済みＭＰＤとは、それぞれ、ハンドオーバーの場合には対応するＰ-ＧＷによって提供され、又はＭＰＤを検査した後で資源管理部（７４）から提供されることになる。従って、Ｐ-ＧＷはＲＲＭに対し、ＭＰＤの位置又はそのコンテンツについて情報提供する必要がある。非特許文献２０において、他のメッセージ、即ちベアラ資源修正要求(Bearer Resource Modification request) (第８．３．１０章を参照）と、活性化デフォルトＥＰＳベアラ要求(Activate default EPS Bearer request) (第８．３．６章を参照）とはまた、表３に記載のサービス情報メッセージのＥＰＳ品質も含み、上述の代替的ビットレートを提供するために使用されてもよい。

【0148】

【表3】

【0149】

１つの可能性として、表４に示すように更なるオクテットを追加することが挙げられる。保証付きビットレートにおいて示されたレートは、最低品質／最低情報密度の領域などについて保証されるべき最小帯域幅に対応してもよく、他方、ダウンリンク及びアップリンクのための代替的ビットレートは、元のＭＰＤ４６内で見られるようにダウンロードのために利用可能なビットレートを記述してもよい。代替的ビットレートのフィールドは、ＱＣＩフィールドの値に依存して存在する。例えば表５に定義される新たなＱＣＩ値が使用される場合には、ダウンリンク又はアップリンクのための代替的ビットレートが存在しなければならない。このメカニズムにより、後方互換性が可能になる。ＱＣＩの値が理解されない場合には、保証付きのビットレートが存在するか否かに依存して、別のＧＢＲ又はnon-ＧＢＲ（非保証のビットレート）ＱＣＩが選択される。

【0150】

【表4】

【0151】

他の可能性として、サービス情報メッセージのＥＰＳ品質に対して追加的メッセージを追加することが考えられ、それらは、サービス情報メッセージのＥＰＳ品質が使用される上述のメッセージに対して追加されるであろう（ＥＳＭベアラ資源割り当て要求、ＥＳＭ活性化専用ベアラ要求、ベアラ資源修正要求、活性化デフォルトＥＰＳベアラ要求）。これにより、サービスメッセージのＥＰＳ品質をそのままにすることが可能になり得る。拡張のコンテンツは、表５に記載のようであってもよい。この場合、保証付きビットレート値は、サービス情報メッセージのＥＰＳ品質内にあると考えられるべきであるが、しかし、ＱＣＩ値は拡張メッセージによって書き換えられ得る。代替的ビットレートもまた、この拡張メッセージ内で記述され得る。

【0152】

【表5】

【0153】

図１５に示すように、ＭＭＥ１１２は、サービスに関する所与のＱｏＳを有するベアラをセットアップするために、コアネットワークの他の構成要素、即ちＳ-ＧＷ及びＰ−ＧＷ１１４とメッセージを交換しなければならない。Ｓ-ＧＷは、基地局(ｅＮＢ)と他のＥＰＣ(Evolved Packet Core)エンティティ、例えばＰ−ＧＷとの間のゲートウェイである。Ｐ−ＧＷ（及び時にはＰＤＮ−ＧＷ＝パケットデータ・ネットワーク・ゲートウェイと呼ばれることもある)は、ＥＰＣとインターネット／バックボーンとの間のインターフェイスである。ゆえに、ＬＴＥネットワーク内の全てのデータは、UE (terminal) <-> eNB <-> S-GW <-> P-GW <-> Internet / Backboneからのルートを有している。

【0154】

更なるメッセージの交換には、ＭＭＥからＳ−ＧＷへ、及びＳ−ＧＷからＰ−ＧＷへのＧＴＰ−Ｃベアラ資源コマンド（非特許文献２１の第７．２．５章を参照）と、Ｐ−ＧＷ１１４からＳ−ＧＷへ、及びＳ−ＧＷからＭＭＥ１１２へのＧＴＰ−Ｃクリエト・ベアラ要求(非特許文献２１の第７．２．３章を参照）と、Ｅ−ＲＡＢセットアップ要求／応答（非特許文献２２の第８．２．１．１章及び第８．２．１．２章を参照）であって、無線資源管理部３０に対し、提供されるべきＱｏＳ特性について報せるデータが含まれる。上述したこれらのメッセージは、表４及び表５に示す拡張に従って拡張されなければならない。例えば、ＧＴＰ−Ｃベアラ資源コマンドに対しては、非特許文献２１の第８．１６章に記載のＦｌｏｗ ＱｏＳ ＩＥが、本願の例えば表６に示すように定義された代替的ビットレートを用いて拡張されるべきである。ＧＴＰ−Ｃクリエト・ベアラ要求に対しては、非特許文献２１の第８．１５章に記載のＦｌｏｗ ＱｏＳ ＩＥが、本願の例えば表７に示すように定義された代替的ビットレートを用いて拡張されるべきである。Ｅ−ＲＡＢセットアップ要求に対しては、ＭＭＥ１１２は、非特許文献２２の第９．２．１．１５章に記載のＥ−ＲＡＢレベルＱｏＳパラメータ内の取り決められた代替的ビットレート(negotiated Alternative bit rates)を挿入すべきである。この目的で、Ｅ−ＲＡＢ Ｌｅｖｅｌ ＱｏＳは、以前に定義された追加的な代替的ビットレートを追加して、例えば表８及び表９に示すように、拡張されるべきである。

【0155】

【表6】

【0156】

【表7】

【0157】

【表8】

【0158】

【表8】

【0159】

上述した処理と同様に、ハンドオーバーは、非特許文献２３に説明されるようにeNodeBによって開始されてもよい。そのような場合、（同じＱｏＳ特性を有する）ベアラセットアップ又はベアラメンテナンスは、ＭＭＥにより開始されず、又はＥＳＭベアラ資源割り当て要求を送信しているＰ−ＧＷによっても開始されず、むしろ非特許文献２４の３ＧＰＰ内で定義されたＸ２インターフェイス内で実行される。そのような場合、前段で提案された、代替的ビットレートを有する拡張されたシンタックスが、適切なメッセージ内に含まれていなければならない。具体的には、インターフェイスＸ２に関してHANDOVER REQUESTメッセージが定義されており（非特許文献２３の第９．１．１．１章を参照）、これはＥ−ＲＡＢレベルＱｏＳパラメータＩＥ／グループ名を含む。このＩＥは非特許文献２３の第９．２．９章に定義されており、表８に示すように拡張されるべきである。このメッセージのシンタックスは、上述したＥ−ＲＡＢセットアップ要求と同一であってもよい。

【0160】

更に、上述した機能に対して追加的又は代替的に、資源管理部７４は、より高いレベルのＴＣＰセッションにより見られるような実際の受信されたスループットを、無線資源管理部３０に対する情報として転送してもよく、その目的は、無線資源管理部３０が、その制御下にある特定のクライアント及び他のクライアントのための更なるスケジューリング及び無線資源割り当て決定のために、実際の結果的なアプリケーション・スループットを識別できるようにするためである。さらに一般的には、クライアント４０がその上で動作可能なユーザーエンティティが無線資源基地局３２と通信するために存在してもよく、その場合、ユーザーエンティティ３４は、クライアント４０によってサーバー４２からリトリーブされたメディアコンテンツの実際に受信されたメディアコンテンツ・スループット又はバッファ状態を決定し、さらに、その決定されたメディアコンテンツ・スループット又はバッファ状態を、無線資源管理部３０に対して情報提供するよう構成されてもよい。その決定は、ユーザーエンティティ内でそれぞれの作業を担う資源管理部７４に対してクライアント４０がそれぞれの情報を送信することを含んでもよい。

【0161】

図３〜図５の実施形態に関して注意すべき点として、上述した説明は、主としてダウンリンクの場合、即ち無線資源管理部がダウンリンク通信資源をユーザーエンティティ３４へと割り当てるものであったが、しかし、上述の実施形態はまたアップリンクの場合にも当てはまるという点が挙げられる。より一般的な視点から見ると、例えば図３〜図５、及び通信資源の割り当てが実行される無線資源管理部３０の機能に関する他の全ての実施形態において、無線資源管理部は、より一般的には、少なくとも１つの基地局３２の通信資源、即ちダウンリンク及び／又はアップリンク通信資源を、サーバーからクライアントへのデータトラフィック内のメディア・プレゼンテーション記述に依存して、ユーザーエンティティ３４に対して割り当てを実行してもよく、その場合、サーバー及びクライアントの一方がユーザーエンティティ３４の１つにおいて動作しており、但し、この一方はクライアントである必要はない。この点に関しては以下により詳細に説明する。例えば図１６を参照されたい。小さな注意点として、サーバーとクライアントとの両方が１つの共通のユーザーエンティティにおいて動作していてもよい点をあげておく。従って、「サーバー及びクライアントの内の一方」とは、「少なくとも一方」として理解されるべきである。

【0162】

図１６は、クライアント４０とサーバー４２とが入れ替わっている点を除き図３に対応する。即ち、サーバー４２がユーザーエンティティ３４において動作し、他方、クライアント４０がユーザーエンティティ３４から見て基地局３２の向こう側に位置している。図７に示すようなユーザーエンティティの可能な内部構造のより詳細な説明を考慮するとき、サーバー３２は、図７におけるクライアント４０と置き換えられるものとして理解されてもよい。これは以下のことを意味する。即ち、無線資源管理部３０は、サーバー４２と４０との間のデータトラフィックを調査する。特に、無線資源管理部３０は、そこからメディア・プレゼンテーション記述４６を調査してもよい。その調査に基づき、無線資源管理部３０は、基地局３２のアップリンク通信資源をユーザーエンティティに対して割り当ててもよく、それらユーザーエンティティの中には、サーバー４２が動作するユーザーエンティティ３４が含まれる。原則的に、資源管理部３０の潜在的な挙動に関する上述した全ての説明には変化がない。つまり、資源管理部３０はまたクライアント４０からサーバー４２へのメディア要求を調査して記録し、その評価やその他に依存してアップリンク通信資源の割り当てを実行してもよい。

【0163】

図３〜図５の実施形態を一方とし、図１６の実施形態を他方とする場合の一致点に関する説明は、両方について有効である。即ち、図３〜図５の実施形態の上述した拡張であって、無線資源管理部３０の機能の一部がＲＲＭ３０からサーバー４２と送受信ステージ７０との間に位置する（例えば図７を参照）資源管理部７４へと移された場合を考慮するときにも、有効である。つまり、以下の点は図１６の実施形態の場合でも当てはまる。即ち、資源管理部７４は、ユーザーエンティティ３４の場所にあるサーバー４２とクライアント４０との間のデータトラフィックを調査する作業について、ＲＲＭ３０の作業を緩和するよう構成されてもよい。つまり、その場合でも、即ちサーバー４２がユーザーエンティティ３４上で実行している場合でも、アップリンク帯域幅の資源は同様に管理され得る。具体的には、資源管理部７４が無線資源管理部３０に対し、ビットレートの選択可能な代替即ち変換済みのＭＰＤを示し、ＲＲＭ３０は、その変換済みＭＰＤを使用して、それに基づくアップリンク資源割り当てを実行してもよい。資源管理部７４は、アップリンクのための代替的ビットレートを、上述したＥＳＭメッセージ即ち表４内で示したようなサービスメッセージの拡張されたＥＰＳ品質を含むメッセージ内で示してもよい。

【0164】

例えば図１４を参照されたい。図１４は、その左側において、図１５において時間軸１１０を用いた場合と同様のフロー図を示し、ブロック内で示されたそれぞれのステップと関連する各エンティティを水平方向に各エンティティを分散させることにより差別化し、また、それぞれのブロックに関連する矢印によってそれぞれのステップがどのエンティティの間において行われるかを示している。図１４の右側には、図１５の実施形態、即ちクライアントがユーザーエンティティの場所にいる場合が再度示されている。左側には、サーバー４２がユーザーエンティティ３４において動作する場合が示される。事実、１つのユーザーエンティティにおいて動作しているクライアントと、他のユーザーエンティティにおいて動作しているサーバーとは、１つのペアを形成して、その間にメディアコンテンツが伝送されてもよい。そのような状態は、例えばビデオ会議であって、ユーザーエンティティ３４’の場所で動作しているサーバーが、ユーザーエンティティ３４''の場所で動作しているクライアントに対し、ユーザーエンティティ３４’の場所で例えばユーザーエンティティのそれぞれのカメラによって捕捉されたビデオ会議の参加者に関するビデオを送信する場合などに発生する可能性がある。しかし、他の場合でも同様に発生可能である。例えば、クライアントが誰か他のユーザーエンティティ３４’の場所にあるメディアサーバーからのファイルをダウンロードすることもあり得る。その場合、ユーザーエンティティ３４’におけるサーバーを一方とし、ユーザーエンティティ３４''におけるクライアントを他方とする、二者間のデータトラフィック内に参加しているエンティティは、図１４で左から右へと進む方向で順番に列挙すれば、ユーザーエンティティ３４’と、ユーザーエンティティ３４’が現時点で接続している基地局３２’と、基地局３２’の通信資源を割り当てる役割を担う無線資源管理部３０’と、基地局３２’及び無線資源管理部３０’が属している無線資源ネットワークを制御する役割を担う移動性管理エンティティ１１２’と、同じ無線資源ネットワークに属しているパケットゲートウェイ１１４’と、クライアント３４''が接続されている基地局３２''が属している無線資源ネットワークに属するパケットゲートウェイ１１４''及び移動性管理エンティティ１１２''と、基地局３２''の通信資源を割り当てる役割を担う無線資源管理部３０''と、基地局３２''自身と、ユーザーエンティティ３４''とである。図１４に示すように、ユーザーエンティティ３４''がステップ１１６において接続とデフォルトベアラ活性化をするのと同様に、ユーザーエンティティ３４''は、ステップ１１６’において、接続とデフォルトベアラ活性化を実行してもよい。図１５について上述したように、ユーザーエンティティ３４''上に位置しているクライアントは、ステップ１１８において、ユーザーエンティティ３４’に位置するサーバーに対してＭＰＤ要求を送信してもよく、次に、ユーザーエンティティ３４’が、ステップ１２０において、ユーザーエンティティ３４''に対し、ＭＰＤを返送してもよい。次に、ステップ１２２において、ユーザーエンティティ３４''に位置する資源管理部７４は、ＭＰＤを解析して、上述のステップ１２６からステップ１４２の説明に沿って専用ベアラの活性化を引き起し、次に、資源管理部３０は、その時クライアントとサーバーとの間に存在するメディア伝送セッション１４４内でユーザーエンティティ３４''の資源管理部７４によって転送された変換済みのＭＰＤに従って基地局３２''のダウンリンク通信資源を割り当てる。アップリンクドメイン側でも、同様のステップが実行される。図１５に関して上述したステップ１２６からステップ１４２までと同様に、ユーザーエンティティ３４’の場所にあるサーバー４２は、専用ベアラの活性化を引き起こす。即ちここでは、適応的な対話型または非対話型の通信タイプセッションである。次に、メディア伝送セッション１４４内で、無線資源管理部３０’は、基地局３２’のアップリンク資源を、ユーザーエンティティ３４’にあるサーバーによってベアラ資源割り当て要求１２６内で転送された変換済みメディア・プレゼンテーション記述に従って、割り当てる。

【0165】

図１４は、サーバーとクライアントとの両方がそれぞれの無線資源ネットワークに接続されたユーザーエンティティ上に位置している場合を単に例示的に示したに過ぎないことに言及しておく。図１４の例は、クライアントがユーザーエンティティの場所で動作しておらず、例えば定置のコンピュータにおいて動作している場合にも容易に転換可能である。しかも、上述のシナリオは、１つの共通の無線資源ネットワーク内であってもよく、また、ＲＲＭ’とＲＲＭ''及び／又はＭＭＥ’とＭＭＥ''とが同一であるような場合にも起こり得ることに留意すべきである。

【0166】

ところで、上述した全ての実施形態に関し、メディアコンテンツ４４が存在するサーバーは、メディア・プレゼンテーション記述を提供するためのサーバーとして作動しているエンティティから分離されてもよいことに留意すべきである。より一般的には、ＭＰＤ４６は、メディアコンテンツ４４を提供しているサーバー自身とは別のエンティティ又はサーバーから発生してもよい。このような可能性は、例えば図１４内では点線を用いて矢印の起点と目標点とがステップ１２０とステップ１１８とにそれぞれ対応するように示される。特にこの潜在的なＭＰＤソースは、点線を用いて符号１５０を付して示されている。しかし、このエキストラのＭＰＤソース１５０の場合には、無線資源管理部３０’は、資源管理部７４から変換済みのメディア・プレゼンテーション記述に関する情報を得ることができる。しかしこの場合には、資源管理部７４は、ユーザーエンティティ３４''の場所にあるクライアントとユーザーエンティティ３４’の場所にあるサーバーとの間のデータトラフィックを検査する代わりに、ユーザーエンティティ３４’の場所にあるサーバーに対し、ユーザーエンティティ３４''の場所にある資源管理部７４に対して変換済みメディア・プレゼンテーション記述を供給するよう指示することができる。

【0167】

換言すれば、図１４内の左側にあるユーザーエンティティ３４はメディアサーバーとしてセットされ、右側にあるユーザーエンティティ３４はクライアント４０としてセットされる。ＭＰＤはクライアントによりＭＰＤソース１５０から要求されるが、そのＭＰＤソースはネットワーク内のいずれのサーバーでもよい（１つの特別な場合は、ＭＰＤを有するサーバーがユーザーエンティティ３４’の場所にあるメディアサーバーである場合になる）。メディアサーバーは、ＭＰＤにおいて公表されているメディアの特性を知っているので、メディアサーバーはこの情報を上述したＥＳＭメッセージ内で代替的ビットレートを示すために使用し、更に、ベアラを設定し、そのベアラにとってはアップリンクビットレートが特別に重要となる（サーバーはデータをアップロードする必要がある）。しかし、クライアントは受信されたＭＰＤを解析する必要があり、またベアラ割り当てに関する記述された情報を使用する。このとき、ダウンリンクビットレートが特別な重要性を持っている（クライアント４０はデータをダウンロードする必要がある）。しかしながら、ＴＣＰが使用される可能性があるので、アップリンクビットレートがクライアントにとって重要であるのと同様に、ダウンリンクビットレートもまたサーバーにとって重要である。

【0168】

特別な場合として、例えば対話型のシナリオにおいて、ユーザーエンティティ３４の各々がメディアサーバーとそこで動作しているクライアントとを同時に有する場合が挙げられる。この場合には、両方のユーザーエンティティ３４がメディア・プレゼンテーション記述（例えばＭＰＤ又はＳＤＰ）を要求してもよく、更に、アップリンク及びダウンリンクのための代替的ビットレートを記述するためにこの情報を使用することもでき、その記述は、それぞれのサーバーにおいて提供されるメディア特性に基づき、またクライアント４０として受信すると想定されるメディア特性にも基づいている。

【0169】

ユーザーエンティティ３４がメディアサーバーとクライアントとを同時に有する、そのようなシナリオにおいては、２つの異なるeNodeBが対話に参加している異なるユーザーエンティティ３４を回線制御することも起こり得る。eNodeBの各々のために動作し、ユーザーエンティティ３４を回線制御している無線資源管理部３０は、異なるユーザーについてのエアインタフェイス(air interfaces)の各々を最適化しながら独立して動作する。そのようなシナリオの課題は、１つのユーザーエンティティ３４のエアインタフェイスが他のユーザーエンティティ３４の無線資源の最適化のために考慮されないことである。従って、次善的な決定が行われる可能性がある。例えば、１つのユーザーエンティティ３４からアップロードされるデータ量が、その１つ目のユーザーエンティティ３４が交信している他のユーザーエンティティ３４においてダウンロード可能なデータ量よりも多い場合には、ユーザーエンティティ３４と協働している無線資源管理部３０において、「ダウンロード問題」を用いて幾つかのデータが削除されるであろう。１つの解決策は、非特許文献２３のＸ２インターフェイスに定義されたメッセージを拡張し、且つ、ＭＰＤ又はＳＤＰに定義された情報に基づいてユーザーの各々について保証されるであろう資源についての具体的な情報を提供するメッセージを追加することである。そのような方法で、両方のeNBが、本願を通じて定義されたＳＤＰ又はＭＰＤの中の情報を考慮しながら、協働的な資源割り当てを実行する。新たなメッセージは、例えばUE RESOURCE STATUS REPORTでもよく、表９、表１０及び表１１に示された資源割り当てＩＥを含んでもよい。

【0170】

直前で示した実施形態は、これから説明する意味におけるメディア知識がない状態での協働的な資源割り当てを開示するものである。つまり、例えば図３を参照されたい。図３は、単一の無線資源管理部３０を示しているが、しかし上述したように、複数の無線資源管理部から成る１つのシステムが１つの無線システムを形成してもよく、その場合、全ての無線資源管理部３０が以下のような意味において相互に独立して動作してもよい。即ち、各無線資源管理部３０が、その少なくとも１つの基地局３２の通信資源を、その基地局３２の到達範囲内にあるユーザーエンティティ３４に対して最適化を通じて割り当て、その割り当てが、上述したユーザーエンティティ３４からの品質フィードバックや、サービス提供を受けるユーザーエンティティ３４の数など、無線資源管理部自身の単数又は複数の基地局３２に亘って伝送されている情報だけに基づいていてもよい。上述した説明を参照されたい。つまり、各ＲＲＭは互いに独立してそのスケジューリングを実行する。しかし、そのスケジューリングの独立性には、この実施形態に従えば以下のような意味で風穴を開けることができる。即ち、ＲＲＭは、そのＵＥに対するそれらの現在の無線資源配分についての情報を、他のＲＲＭが使用できるように外部に向かって配信してもよい。直前で示した実施形態においては、メディア・プレゼンテーション記述内に存在する情報があったとしても、無線資源管理部が必ずしもその情報を活用する必要はない。しかし、これから説明する実施形態においては、独立して動作している複数の無線資源管理部３０が、偶然にもそこで動作しているクライアントとサーバーとの通信ペアを有する複数のユーザーエンティティに対して、不適合な通信資源を誤って割り当てることを回避し得る。これは以下のようにして達成される。

【0171】

特に無線資源管理部が、ユーザーエンティティ３４の内の１つにおいて動作しているサーバー又はクライアントに向かうデータトラフィック、又は無線資源管理部同士の間で交信される何らかの制御メッセージを調査して、サーバーとクライアントとの他方に現時点で割り当てられている保証付き通信資源、又はサーバーとクライアントとの他方のバッファ状態についての情報を得る。現在の無線資源管理部３０によってサービス提供されているユーザーエンティティ３４上で動作しているサーバーの場合には、このサーバーのバッファ状態は、例えば出力バッファ状態、即ち出力バッファの充満レベルを形成してもよい。このレベルは、例えばライブストリーミング又はビデオ会議の場合に有意義であり得る。ユーザーエンティティ３４上で動作しているクライアント４０の場合には、バッファ状態は、クライアントの入力バッファの充満レベルとなるであろう。ここで強調しておくが、この実施形態によれば、無線資源管理部３０（図３を参照）は、他の無線資源管理部３０によってサービス提供されているサーバー又はクライアントに関するこの情報を取得する。単に、クライアント／サーバーのペアの片方がその無線資源管理部３０自身によるサービス提供を受けているユーザーエンティティ３４上で動作しているだけである。この実施形態によれば、無線資源管理部３０は、別の場所でサービス提供されているユーザーエンティティ上で動作しているクライアント／サーバーの他方に関するこの情報を使用して、ユーザーエンティティ３４がサービス提供されている少なくとも１つの基地局３２の通信資源の割り当てを実行する。この方法により、例えばクライアント／サーバーの片方のバッファ状態が高い場合、又はクライアント／サーバーの片方が動作している外部のユーザーエンティティに現在割り当てられた保証付き通信資源が低い場合であっても、無線資源管理部３０がいずれかのユーザーエンティティ３４に対して不必要に多い通信資源を割り当てることを防止することができる。

【0172】

この点を明らかにするため、複数の無線資源管理部を含むシステムを示す図１７を参照されたい。ＬＴＥの枠組みにおいては、ＲＲＭが上述のeNodeBを形成してもよい。無線資源管理部の内の１つが例示的に参照番号３０で示され、他の１つが３０’で示されている。２つの管理部だけを示したという事実は、単に例示的である。両方の管理部３０と３０’とは、少なくとも１つの基地局３２と３２’との各通信資源をそれぞれに割り当てる。割り当て又はスケジューリングは、互いに独立して実行されるが、ここで説明する制御信号又はデータトラフィック挿入(insertion)を含む相互作用は別である。

【0173】

図１７には、無線資源管理部３０に属する基地局３２から１つのユーザーエンティティ３４がサービス提供されるよう例示的に示されており、無線資源管理部３０’に属する基地局３２’から他のユーザーエンティティ３４’がサービス提供されるよう示されている。ユーザーエンティティ３４上ではクライアント４０が動作し、ユーザーエンティティ３４’上ではサーバー４２が動作するように例示的に示される。両ユーザーエンティティは、図１７の破線で示されたデータトラフィックによって互いに通信可能である。データトラフィックは、遠隔通信タイプ、ダウンロードタイプまたはその他であってもよい。図３に関して上述したように、無線資源管理部３０と３０’とがそのデータトラフィックによって通信される必要はない。両方の無線資源管理部３０と３０’とが単にデータトラフィックに対してアクセスでき、そのデータトラフィックを調査及び検査できれば十分である。

【0174】

ＲＲＭ３０と３０’との間の最適化ミスを防止する目的で、これらＲＲＭは、現在のＵＥバッファ状態と他のそれぞれのＲＲＭに対して現在保証されているビットレートとに関して、互いに情報伝達する。

【0175】

第１の選択肢によれば、両方のＲＲＭは互いに不可知のままでもよい。サーバー又はクライアントが例えばインターネット内の無線システムの外部でサービス提供される場合でも、最適化ミスが防止できるように、それぞれの情報はクライアント／サーバー・データストリーム内へと挿入される。

【0176】

無線資源管理部３０’は、例えばクライアント４０が動作しているユーザーエンティティ３４に現在割り当てられている保証付き通信資源、又はこのクライアント４０のバッファ状態についての情報を得るために、サーバー３２からクライアント４０へと向かうデータトラフィックを調査することができる。この方法により、例えばクライアント４０のバッファ状態が既に高い場合や、又はユーザーエンティティ３４に対して現在割り当てられている保証付き通信資源が低い場合であっても、無線資源管理部３０’はサーバー４２のために過大な通信資源を費やすのを避けることができる。他方、無線資源管理部３０は、ユーザーエンティティ３４’に現在割り当てられている保証付き情報資源又はサーバー４２のバッファ状態についての情報を得るために、クライアント４０からサーバー４２に向かうデータトラフィックを調査することができる。

【0177】

同様の方法で、無線資源管理部３０は、この情報を用いて、例えばサーバー４２のバッファ状態が充満レベルの空状態に近づいた場合や、ユーザーエンティティ３４’に対して現在割り当てられている保証付き通信資源が低い場合であっても、ユーザーエンティティ３４に対して過大な通信資源を割り当てることを回避することができる。

【0178】

上述したように、保証付きの通信資源とは、無線資源管理部３０と３０’とがその単数又は複数の基地局３２の通信資源をそのサービス提供を受ける複数のユーザーエンティティ３４に対して割り当てる中で、決定できる何かであってもよい。つまり、無線資源管理部３０と３０’とは、それぞれ保証付きの通信資源をユーザーエンティティ３４と３４’とに対し、何らかの時間区間の単位で、例えば３〜１０秒の時間区間などの単位で割り当ててもよい。無線資源管理部３０と３０’とはまた、それらの時間区間内で通信資源を割り当てる際に、保証付き通信資源に従わなければならない。無線資源管理部３０と３０’とは、保証付き通信資源を時間区間を通じて固定的に使用するか、又は、単に保証付きの通信資源によって課せられた制限内において、ユーザーエンティティに対する通信資源の割り当てを変化させる。

【0179】

外部の無線資源管理部のドメインからのバッファ状態又は保証付き通信資源の情報が、どのようにしてデータトラフィックを介してクライアント／サーバーの片方にサービス提供している無線資源管理部の無線資源管理部ドメインの中に侵入するかという方法については、異なる可能性が存在する。例えば無線資源管理部３０と３０’とは、そのサービス提供されているユーザーエンティティに割り当てられた保証付きの通信資源についての情報を、そのサービス提供されているユーザーエンティティ上で実行しているクライアント４０又はサーバー４２からのデータトラフィック内に挿入するよう構成されてもよい。例えば無線資源管理部３０’は、サーバー４２からクライアント４０へのデータストリームの中にユーザーエンティティ３４’に割り当てられた保証付き通信資源に関する情報を挿入することができ、他方、無線資源管理部３０は、クライアント４０からサーバー４２へのデータトラフィックの中にユーザーエンティティ３４に割り当てられた保証付き通信資源に関する情報を挿入することができる。更に、その挿入は必ずしも無線資源管理部３０及び３０’自身によって実行されるべきものでもない。既に前述の実施例に関して上述したように、そのような挿入はまた、ユーザーエンティティ３４及び３４’それぞれの上で実行している資源管理部７４によっても実行され得る。その場合、無線資源管理部３０と３０’とは、それぞれユーザーエンティティ３４と３４’に対し、保証付き通信資源について即ち無線資源管理部３０と３０’とが関わるユーザーエンティティ３４と３４’とに割り当てられた保証付き通信資源についての情報を伝達し、さらに、この情報は無線資源管理部の代わりに上述の挿入を実行する資源管理部７４によって調査及び検査されてもよい。

【0180】

第２の選択肢によれば、ＲＲＭ３０と３０’との両方は、それら自身によるサービスを受けているＵＥに関する現在のＵＥバッファ状態及び現在の保証付きビットレートについての情報を、互いに他のＲＲＭに対して制御信号１９９を介して提供し合う。ＬＴＥのアーキテクチャの中で、例えばそのような制御信号は、制御信号交換の経路をしかるべく案内するオペレータとして例えばＨＳＳを使用しながら、例えばＸ２インターフェイスやＳ−ＧＷなどを介して、ＲＲＭ同士の間で交換されてもよい。この実施形態によれば、無線資源管理部３０と３０’とは、例えば次のようなステップを実行してもよい。即ち、（１）無線資源管理部３０と３０’自身によってサービス提供されているユーザーエンティティ上で動作しているクライアントが、即時の伝送セッション、即ちこのクライアント又はサーバーを含むメディア伝送セッションの開始をセットアップすることを求めていることを認識する。（２）メディア伝送セッションがセットアップされる片方、即ちサーバー又はクライアントが、無線システムの他の何らかのＲＲＭによってサービス提供されていないかどうかをチェックする。（３）その答えがイエスである場合には、メディア伝送セッションに制御信号１９９を付帯させる。制御信号のための経路は、例えばＨＳＳを介して案内される。例えば、無線資源管理部３０は無線資源管理部３０’に対し、制御信号１９９を介してクライアントのバッファ状態の情報を与え、無線資源管理部３０はこの情報を、上述のようにユーザーエンティティ３４内における資源管理部７４からのシミュレーション又はフィードバックにより獲得していてもよい。又は、無線資源管理部３０は無線資源管理部３０’に対し、制御信号１９９を介して、ユーザーエンティティ３４に割り当てられた保証付き無線資源についての情報を与えてもよい。無線資源管理部３０’もまた同様のことをメディア伝送セッションの間に逆方向で実行してもよい。つまり、無線資源管理部３０’は無線資源管理部３０に対し、制御信号１９９を介して、サーバーのバッファ状態及び／又はユーザーエンティティ３４’のための保証付き無線資源についての情報を与えてもよい。

【0181】

当然ながら、直上で述べた実施形態はまた、上段で説明した実施例のいずれとも組み合わせることができる。例えば、無線資源管理部自身によるサービス提供を受けているユーザーエンティティ上で動作している、クライアント又はサーバーのバッファ状態が通信資源の割り当てを実行するための無線資源管理部によって使用されるような実施形態が考慮対象である限り、この点は正しい。

【0182】

表９は、非特許文献２３の第９．２．１３章のメッセージタイプ表を以下のように拡張する。

【表9】

【0183】

表１０は、ＵＥ資源ステータス報告のシンタックスを示す。

【表10】

【0184】

表１１は、ＵＥの割り当てられた資源情報ＩＥのシンタックスを示す。

【表11】

【0185】

代替的に、ＳＤＰ又はＭＰＤに基づく（メディア特性に基づく）種々のビットレートが、以下の表に示す最大サポートビットレートと共に提供されてもよい。

【表11】

【0186】

表６：標準化されたＱＣＩ特性［ｃｐ．１９］

【表6-1】

【0187】

【表6-2】

【0188】

これまで説明したように、上述の実施形態は、特にソフトエウア、ハードウエア、プログラム可能なハードウエアなどのクライアントであって、無線資源基地局３２を用いた通信のためにユーザーエンティティ３４上で動作可能なクライアントを開示しており、そのクライアント４０は、サーバー４２からメディア・プレゼンテーション記述及びメディアコンテンツ４４をリトリーブし、メディア・プレゼンテーション記述４６はメディアコンテンツ４４の異なる帯域幅からなる複数のバージョンを記述しており、クライアントはまた、基地局３２の通信資源をユーザーエンティティへと割り当てる役割を担う無線資源管理部３０からの信号伝達を通じて、ノーマルモードからスレーブモードへと切替可能であり、クライアントは、ノーマルモードにおいては、ユーザーエンティティに割り当てられた通信資源に基づいてクライアントにより決定されたバージョンでメディアコンテンツ４４をサーバー４２から要求し、スレーブモードにおいては、ユーザーエンティティに割り当てられた通信資源とは無関係にクライアントにより決定されたバージョンでメディアコンテンツ４４をサーバー４２から要求する。クライアントはさらに、ノーマルモードでは、ユーザーエンティティに割り当てられた通信資源とメディアコンテンツのバッファ状態とに基づいてクライアントにより決定されたバージョンのメディアコンテンツ４４をサーバー４２から要求してもよい。さらにまた、クライアントは、スレーブモードでは、メディア・プレゼンテーション記述４６内の異なる帯域幅から成る複数のバージョンの内の最も高い帯域幅バージョンに対応するバージョンのメディアコンテンツ４４を連続的にサーバー４２から要求してもよい。つまり、クライアントの挙動は、例えばＭＰＤ内の@automaticSwitchingインジケータによって制御することができ、クライアントは、選択されたセグメントのビットレートに対して途中にある装置がセル資源を最適化するよう途中で調整を加える可能性があるため、クライアントがビットレートの変化に対して自分で反応すべきでない、と情報伝達されてもよい。

【0189】

これまで装置を説明する文脈で幾つかの態様を示してきたが、これらの態様は対応する方法の説明でもあることは明らかであり、そのブロック又は装置が方法ステップ又は方法ステップの特徴に対応することは明らかである。同様に、方法ステップを説明する文脈で示した態様もまた、対応する装置の対応するブロックもしくは項目又は特徴を表している。方法ステップの幾つか又は全ては、例えばマイクロプロセッサ、プログラム可能なコンピュータ、又は電子回路等のハードウエア装置により（を使用して）実行されても良い。幾つかの実施形態においては、最も重要な方法ステップの内の１つ又は複数のステップはそのような装置によって実行されても良い。

【0190】

所定の構成要件にも依るが、本発明の実施形態は、ハードウエア又はソフトウエアにおいて実装可能である。この実装は、その中に格納される電子的に読み取り可能な制御信号を有し、本発明の各方法が実行されるようにプログラム可能なコンピュータシステムと協働する（又は協働可能な）、デジタル記憶媒体、例えばフレキシブルディスク，ＤＶＤ，ブルーレイ，ＣＤ，ＲＯＭ，ＰＲＯＭ，ＥＰＲＯＭ，ＥＥＰＲＯＭ，フラッシュメモリなどを使用して実行することができる。従って、そのデジタル記憶媒体はコンピュータ読み取り可能であっても良い。

【0191】

本発明に従う幾つかの実施形態は、上述した方法の１つを実行するようプログラム可能なコンピュータシステムと協働可能で、電子的に読み取り可能な制御信号を有するデータキャリアを含んでも良い。

【0192】

一般的に、本発明の実施例は、プログラムコードを有するコンピュータプログラム製品として実装することができ、このプログラムコードは当該コンピュータプログラム製品がコンピュータ上で作動するときに、本発明の方法の一つを実行するよう作動できる。そのプログラムコードは例えば機械読み取り可能なキャリアに記憶されても良い。

【0193】

他の実施形態は、上述した方法の１つを実行するための、機械読み取り可能なキャリアに記憶されたコンピュータプログラムを含む。

【0194】

換言すれば、本発明の方法のある実施形態は、そのコンピュータプログラムがコンピュータ上で作動するときに、上述した方法の１つを実行するためのプログラムコードを有する、コンピュータプログラムである。

【0195】

本発明の他の実施形態は、上述した方法の１つを実行するために記録されたコンピュータプログラムを含む、データキャリア（又はデジタル記憶媒体又はコンピュータ読み取り可能な媒体）である。データキャリア、デジタル記憶媒体又は記録された媒体は、典型的には有形であり、及び／又は非一時的である。

【0196】

本発明の他の実施形態は、上述した方法の１つを実行するためのコンピュータプログラムを表現するデータストリーム又は信号列である。そのデータストリーム又は信号列は、例えばインターネットを介するデータ通信接続を介して伝送されるように構成されても良い。

【0197】

他の実施形態は、上述した方法の１つを実行するように構成又は適応された、例えばコンピュータ又はプログラム可能な論理デバイスのような処理手段を含む。

【0198】

他の実施形態は、上述した方法の１つを実行するためのコンピュータプログラムがインストールされたコンピュータを含む。

【0199】

本発明によるさらなる実施形態は、本明細書に記載の方法のうちの１つを実行するためのコンピュータプログラムを受信機へと（例えば、電子的または光学的に）転送するよう構成された装置またはシステムを含む。受信機は、例えばコンピュータ、携帯デバイス、メモリデバイス、などであってよい。装置またはシステムは、例えばコンピュータプログラムを受信機へと転送するためのファイルサーバを備えることができる。

【0200】

幾つかの実施形態においては、（例えば書換え可能ゲートアレイのような）プログラム可能な論理デバイスは、上述した方法の幾つか又は全ての機能を実行するために使用されても良い。幾つかの実施形態では、書換え可能ゲートアレイは、上述した方法の１つを実行するためにマイクロプロセッサと協働しても良い。一般的に、そのような方法は、好適には任意のハードウエア装置によって実行される。

【0201】

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

【0202】

−略語と記号のリスト−

【表B】

【0203】

［請求項１］
サーバー（４２）からクライアント（４０）へのデータトラフィックの中で転送されるメディアコンテンツ（４４）に関連するメディア・プレゼンテーション記述（４６）に依存して、少なくとも１つの基地局（３２）の通信資源を複数のユーザーエンティティ（３４）へと割り当てる無線資源管理装置であって、前記サーバー（４２）と前記クライアント（４０）との一方が前記ユーザーエンティティ（３２）の１つで動作している、無線資源管理装置。
［請求項２］
請求項１に記載の無線資源管理装置であって、前記メディア・プレゼンテーション記述（４６）に依存して、前記少なくとも１つの基地局（３２）のダウンリンク通信資源を前記ユーザーエンティティ（３４）に対して割り当てるよう構成されており、前記クライアントが前記ユーザーエンティティ（３２）の１つで動作している、無線資源管理装置。
［請求項３］
請求項１に記載の無線資源管理装置であって、前記メディア・プレゼンテーション記述（４６）に依存して、前記少なくとも１つの基地局（３２）のアップリンク通信資源を前記ユーザーエンティティ（３４）に対して割り当てるよう構成されており、前記サーバー（４２）が前記ユーザーエンティティの１つで動作している、無線資源管理装置。
［請求項４］
請求項１乃至３のいずれかに記載の無線資源管理装置であって、前記メディア・プレゼンテーション記述（４６）を得るために、前記サーバー（４２）から前記クライアント（４０）への前記データトラフィックを調査する、無線資源管理装置。
［請求項５］
請求項１乃至３のいずれかに記載の無線資源管理装置であって、前記ユーザーエンティティから前記メディア・プレゼンテーション記述（４６）を受信する、無線資源管理装置。
［請求項６］
請求項１乃至５のいずれかに記載の無線資源管理装置であって、前記メディア・プレゼンテーション記述が、前記サーバー（４２）から前記クライアント（４０）へのデータトラフィック内において転送されるべきメディアコンテンツ（４４）の各バージョンについて、前記メディアコンテンツ（４４）の前記バージョンの品質尺度と最小帯域幅とを含む、無線資源管理装置。
［請求項７］
請求項１乃至６のいずれかに記載の無線資源管理装置であって、前記メディア・プレゼンテーション記述（４６）を検査して、前記メディア・プレゼンテーション記述（４６）内で、前記少なくとも１つの基地局を介して前記クライアント（４４）によって現在ダウンロードされている前記メディアコンテンツ（４４）のバージョンよりも低い最小帯域幅を持つ前記メディアコンテンツ（４４）のバージョンを識別し、前記低い最小帯域幅を持つバージョンが存在するか否かに依存して、前記ユーザーエンティティに対する通信資源の割り当てを実行する、無線資源管理装置。
［請求項８］
請求項７に記載の無線資源管理装置であって、前記低い最小帯域幅を持つバージョンが存在するか否かに依存して、前記ユーザーエンティティに対する通信資源の割り当てを実行し、前記１つのユーザーエンティティに対して割り当てられる通信資源が、−前記無線資源管理装置が通信資源を割り当てる場合に依存する残りのパラメータの可能な状態の間では同じ確率に関係している場合−前記低い最小帯域幅を持つ前記バージョンが存在するときには、前記低い最小帯域幅を持つバージョンが存在しないときと比較して低くなるように構成されている、無線資源管理装置。
［請求項９］
請求項１乃至８のいずれかに記載の無線資源管理装置であって、前記メディア・プレゼンテーション記述（４６）を検査して、前記メディア・プレゼンテーション記述（４６）内で、前記少なくとも１つの基地局を介して前記クライアント（４４）によって現在ダウンロードされている前記メディアコンテンツ（４４）のバージョンよりも高い最小帯域幅を持つ前記メディアコンテンツ（４４）のバージョンを識別し、前記高い最小帯域幅を持つバージョンが存在するか否かに依存して、前記ユーザーエンティティに対する通信資源の割り当てを実行する、無線資源管理装置。
［請求項１０］
請求項１乃至８のいずれかに記載の無線資源管理装置であって、前記ユーザーエンティティに対する通信資源の割り当てを、
−前記少なくとも１つの基地局（３２）の通信資源が適切な割合で割り当てられるべきユーザーエンティティ（３４）の数、
−前記ユーザーエンティティと前記少なくとも１つの基地局との間で交換されるべき通信データの種類、
−前記ユーザーエンティティに割り当てられたユーザープロファイルであって、前記ユーザーエンティティ間の優先順位を定義するプロファイル、
−前記ユーザーエンティティからのチャネル品質フィードバック、
−前記ユーザーエンティティからのチャネルレート要求、
の内の１つ又は複数に基づいて実行する、無線資源管理装置。
［請求項１１］
請求項１乃至１０のいずれかに記載の無線資源管理装置であって、前記ユーザーエンティティに対して通信資源を割り当てる際に、前記メディア・プレゼンテーション記述（４６）に依存して、
−サブキャリア、
−時間スロット、
−前記少なくとも１つの基地局セルの空間的カバー範囲、
の内の１つ又は複数を調整する、無線資源管理装置。
［請求項１２］
請求項１乃至１１のいずれかに記載の無線資源管理装置であって、前記通信資源が割り当てられる２つ以上の前記ユーザーエンティティの前記クライアントが前記少なくとも１つの基地局を介してそれぞれのメディアコンテンツを現在ダウンロードしている場合に、それぞれのサーバー（４２）からそれぞれのクライアント（４０）へのデータトラフィック内にあるそれぞれのメディア・プレゼンテーション記述（４６）に依存して、前記クライアントの各メディアコンテンツ（４４）の前記バージョンの品質尺度と最小帯域幅とに少なくとも依存する費用関数が最適化されるように、前記２つ以上の前記ユーザーエンティティ（３４）に対する前記通信資源の割り当てを実行する、無線資源管理装置。
［請求項１３］
請求項１乃至１２のいずれかに記載の無線資源管理装置であって、前記クライアントの受信されたメディア・スループットについてスループット尺度を決定し、前記決定されたスループット尺度に基づいて、前記メディア・プレゼンテーション記述（４６）からメディアコンテンツ（４４）のどのバージョンが前記少なくとも１つの基地局（３２）を介して前記クライアント（４４）によって現在ダウンロードされているかを予測する、無線資源管理装置。
［請求項１４］
請求項１乃至１３のいずれかに記載の無線資源管理装置であって、前記クライアントの受信されたメディア・スループットについてスループット尺度を決定し、前記決定されたスループット尺度に基づいて前記割り当てを実行する、無線資源管理装置。
［請求項１５］
請求項１３又は１４に記載の無線資源管理装置であって、前記割り当てられた通信帯域幅を前記スループット尺度として使用するか、前記ユーザーエンティティ（３４）からの品質フィードバックの評価を通じて前記割り当てられた通信帯域幅から前記スループット尺度を推定するか、又は、前記ユーザーエンティティ（３４）から前記スループット尺度を受信する、無線資源管理装置。
［請求項１６］
請求項１乃至１５のいずれかに記載の無線資源管理装置であって、前記クライアント（４０）から前記サーバー（４２）へのメディア要求（６０）を検査することにより、前記メディア・プレゼンテーション記述（４６）からメディアコンテンツ（４４）のどのバージョンが、前記少なくとも１つの基地局（３２）を介して前記クライアント（４４）によって現在ダウンロードされているかを決定する、無線資源管理装置。
［請求項１７］
請求項１乃至１６のいずれかに記載の無線資源管理装置であって、前記クライアント（４０）によって要求されたメディアコンテンツのバージョンの履歴を記録し、前記少なくとも１つの基地局（３２）の通信資源における逼迫度が減少した場合に、前記履歴を使用して、前記クライアント（４０）に対して現在割り当てられている通信資源の量を増加させるように決定する、無線資源管理装置。
［請求項１８］
請求項１乃至１７のいずれかに記載の無線資源管理装置であって、前記ユーザーエンティティから前記少なくとも１つの基地局へのチャネル品質フィードバックに基づいてユーザーエンティティのバッファ状態をシミュレートするか、前記基地局（３２）の反対側もしくは前記基地局（３２）内部に位置するメディアコンテンツバッファ（１００）を監視するか、又は、前記クライアント（４０）から前記サーバー（４２）へのデータトラフィック内の明示的な信号伝達から前記バッファ状態を抽出し、前記基地局のダウンリンク通信資源が関係している場合に、前記バッファ状態に依存して前記割り当てを実行する、無線資源管理装置。
［請求項１９］
無線資源基地局（３２）と通信するユーザーエンティティであって、そのユーザーエンティティ上でクライアント（４０）又はサーバー（３２）が動作可能であり、前記ユーザーエンティティは、メディアコンテンツ（４４）の異なる帯域幅の複数のバージョンを記述するメディア・プレゼンテーション記述（４６）を導出するために、前記クライアント（４０）と前記サーバー（３２）との間のデータトラフィックを調査し、前記ユーザーエンティティが属している複数のユーザーエンティティに前記無線資源基地局（３２）の通信資源を割り当てる役割を担う無線資源管理装置（３０）に対して、前記メディア・プレゼンテーション記述を少なくとも部分的に転送する、ユーザーエンティティ。
［請求項２０］
請求項１９に記載のユーザーエンティティであって、前記データトラフィックが伝送されるＯＳＩレイヤよりも低いＯＳＩレイヤ内で前記転送を実行する、ユーザーエンティティ。
［請求項２１］
無線資源基地局（３２）と通信するユーザーエンティティであって、そのユーザーエンティティ上でクライアント（４０）が動作可能であり、前記ユーザーエンティティは、前記クライアントによってサーバー（４２）からリトリーブされたメディアコンテンツの受信済みのメディアコンテンツ・スループット又はバッファ状態を決定し、前記ユーザーエンティティに対して前記無線資源基地局（３２）の通信資源を割り当てる役割を担う無線資源管理装置（３０）に、前記決定されたメディアコンテンツ・スループット又はバッファ状態について通知する、ユーザーエンティティ。
［請求項２２］
請求項２１に記載のユーザーエンティティであって、前記メディアコンテンツ・リトリーブが伝送されるＯＳＩレイヤよりも低いＯＳＩレイヤ内で前記通知を実行する、ユーザーエンティティ。
［請求項２３］
無線資源基地局（３２）と通信するためにユーザーエンティティ（３４）上で動作可能なクライアントであって、前記クライアント（４０）はサーバー（４２）からメディア・プレゼンテーション記述とメディアコンテンツ（４４）とをリトリーブし、前記メディア・プレゼンテーション記述（４６）は前記メディアコンテンツ（４４）の異なる帯域幅のバージョンを記述するものであり、前記クライアントは、前記ユーザーエンティティに対して前記無線資源基地局（３２）の通信資源を割り当てる役割を担う無線資源管理装置（３０）からの信号伝達によって、ノーマルモードからスレーブモードへと切替可能であり、
前記ノーマルモードにおいては、前記ユーザーエンティティに割り当てられた通信資源に基づいて、前記クライアントにより決定されたバージョンにおける前記メディアコンテンツ（４４）を前記サーバー（４２）から要求し、前記スレーブモードにおいては、前記ユーザーエンティティに割り当てられた通信資源とは無関係に、前記クライアントにより決定されたバージョンにおける前記メディアコンテンツ（４４）を前記サーバー（４２）から要求する、クライアント。
［請求項２４］
請求項２３に記載のクライアントであって、前記ノーマルモードにおいて、前記ユーザーエンティティに割り当てられた通信資源と前記メディアコンテンツのバッファ状態とに基づいて、前記クライアントにより決定されたバージョンにおける前記メディアコンテンツ（４４）を前記サーバー（４２）から要求する、クライアント。
［請求項２５］
請求項２３又は２４に記載のクライアントであって、前記ノーマルモードにおいて、前記ユーザーエンティティに割り当てられた通信資源の量が減少している場合には、前記メディアコンテンツのバッファ状態に基づいて前記クライアントにより決定されたバージョンにおける前記メディアコンテンツ（４４）を、その決定されたバージョンが現在決定されているバージョンと比べて低い品質を持つバージョンへと変更されるように、前記サーバー（４２）から要求する、クライアント。
［請求項２６］
請求項２３乃至２５のいずれかに記載のクライアントであって、前記スレーブモードにおいて、前記メディア・プレゼンテーション記述（４６）の異なる帯域幅の複数のバージョンの中で最も高い帯域幅バージョンに対応するバージョンにおける前記メディアコンテンツ（４４）を前記サーバー（４２）から連続的に要求する、クライアント。
［請求項２７］
資源管理装置であって、
メディアコンテンツ（４４）の異なる帯域幅の複数のバージョンを記述しているメディア・プレゼンテーション記述（４６）を、サーバー（４２）からユーザーエンティティ（３４）上で動作しているクライアント（４０）へのデータトラフィック内で検査し、
前記メディアコンテンツ（４４）の所望のバージョンを要求する、前記クライアント（４０）から前記サーバー（４２）へのメディア要求（６０）を検査し、
現在の資源状態情報と前記メディア・プレゼンテーション記述（４６）とに依存して、
−前記サーバーに対し前記メディア要求（６０）を転送するか、又は、
−前記メディア要求（６０）が前記クライアント（４０）に送信されるべき前記メディアコンテンツ（４４）の前記所望のバージョンをもたらさない状態とするか、
を決定する、資源管理装置。
［請求項２８］
請求項２７に記載の資源管理装置において、修正済みのメディア要求が前記メディアコンテンツ（４４）のより少ない帯域幅のバージョンを要求する程度に前記メディア要求（６０）を修正するか、又は、前記メディア要求（６０）をインターセプトして、利用不可の応答を前記サーバー（４２）から前記クライアント（４０）へと返送するように、前記サーバー（４２）に対してエミュレート又は指令することで、前記所望のバージョンをもたらさない状態を実行する、資源管理装置。
［請求項２９］
請求項２７又は２８に記載の資源管理装置において、前記メディア・プレゼンテーション記述（４６）を検査し、それにより、前記メディア・プレゼンテーション記述（４６）の中で、前記メディアコンテンツ（４４）の所望のバージョンとして関連するより低い最小帯域幅を持つメディアコンテンツ（４４）のバージョンを識別し、もし前記より低い最小帯域幅を持つバージョンが存在する場合には、前記現在の資源状態情報に依存して前記決定を実行する、資源管理装置。
［請求項３０］
請求項２７乃至２９のいずれかに記載の資源管理装置であって、前記資源管理装置は無線資源管理装置であり、前記クライアントが動作している前記ユーザーエンティティが属する複数のユーザーエンティティに対して少なくとも１つの基地局の通信資源の割り当てを実行する、資源管理装置。
［請求項３１］
請求項２７乃至３０のいずれかに記載の資源管理装置であって、前記ユーザーエンティティ内の送受信ステージ（７０）と前記クライアント（４０）との間に配置され、前記現在の資源状態情報を前記送受信ステージ（７０）から取得する、資源管理装置。
［請求項３２］
請求項２７乃至３１のいずれかに記載の資源管理装置であって、前記ユーザーエンティティから前記基地局へのチャネル品質フィードバックに基づいてユーザーエンティティのバッファ状態をシミュレートし、前記チャネル品質フィードバックは前記現在の資源状態情報に含まれており、前記ユーザーエンティティのバッファ状態に依存して前記決定を実行する、資源管理装置。
［請求項３３］
資源管理装置であって、
メディアコンテンツ（４４）の異なる帯域幅の複数のバージョンを記述しているメディア・プレゼンテーション記述（４６）を、サーバー（４２）からユーザーエンティティ（３４）において動作しているクライアント（４０）へのデータトラフィック内で検査し、
前記メディアコンテンツ（４４）の所望のバージョンを要求する、前記クライアント（４０）から前記サーバー（４２）へのメディア要求（６０）を検査し、
前記ユーザーエンティティ（３４）から基地局（３２）へのチャネル品質フィードバックに基づいてシミュレートするか、前記基地局（３２）の反対側もしくは前記基地局（３２）の内部に位置するメディアコンテンツバッファ（１００）を監視するか、又は前記クライアント（４０）から前記サーバー（４２）へのデータトラフィック内での明示的な信号伝達から前記ユーザーエンティティのバッファ状態を抽出することにより、前記クライアントについてユーザーエンティティのバッファ状態を取得し、
前記ユーザーエンティティのバッファ状態と前記メディア・プレゼンテーション記述（４６）とに依存して、
−前記サーバーに対して前記メディア要求（６０）を転送するか、又は、
−前記メディア要求（６０）が前記クライアント（４０）に送信されるべき前記メディアコンテンツ（４４）の前記所望のバージョンをもたらさない状態とするか、
を決定する、資源管理装置。
［請求項３４］
請求項３３に記載の資源管理装置であって、修正済みのメディア要求が前記メディアコンテンツ（４４）のより少ない帯域幅のバージョンを要求する程度に前記メディア要求（６０）を修正するか、又は、前記メディア要求（６０）をインターセプトして、利用不可の応答を前記サーバー（４２）から前記クライアント（４０）へと返送するように、前記サーバー（４２）に対してエミュレート又は指令することで、前記所望のバージョンをもたらさない状態を実行する、資源管理装置。
［請求項３５］
請求項３３又は３４に記載の資源管理装置であって、現在の資源状態情報にも基づいて前記決定を実行する、資源管理装置。
［請求項３６］
請求項３５に記載の資源管理装置であって、前記メディア・プレゼンテーション記述（４６）を検査し、それにより、前記メディア・プレゼンテーション記述（４６）の中で、前記メディアコンテンツ（４４）の所望のバージョンとして関連するより低い最小帯域幅を持つメディアコンテンツ（４４）のバージョンを識別し、もし前記より低い最小帯域幅を持つバージョンが存在する場合には、前記現在の資源状態情報に依存して前記決定を実行する、資源管理装置。
［請求項３７］
請求項３３乃至３６のいずれかに記載の資源管理装置であって、前記資源管理装置は無線資源管理装置であり、前記クライアントが動作している前記ユーザーエンティティが属する複数のユーザーエンティティに対して、少なくとも１つの基地局の通信資源の割り当てを実行する、資源管理装置。
［請求項３８］
請求項３３乃至３７のいずれかに記載の資源管理装置であって、前記ユーザーエンティティ内の送受信ステージ（７０）と前記クライアント（４０）との間に配置され、前記現在の資源状態情報を前記送受信ステージ（７０）から取得する、資源管理装置。
［請求項３９］
請求項３３乃至３８のいずれかに記載の資源管理装置であって、前記ユーザーエンティティから前記基地局へのチャネル品質フィードバックに基づいてユーザーエンティティのバッファ状態をシミュレートし、前記チャネル品質フィードバックは前記現在の資源状態情報に含まれており、前記ユーザーエンティティのバッファ状態に依存して前記決定を実行する、資源管理装置。
［請求項４０］
資源管理装置であって、
ユーザーエンティティ（３４）において動作しているクライアント（４０）からサーバー（４２）へのメディア・プレゼンテーション記述要求を検査し、前記メディア・プレゼンテーション記述要求は前記サーバー（４２）からメディア・プレゼンテーション記述（４６）を要求するものであり、前記メディア・プレゼンテーション記述（４６）はメディアコンテンツ（４４）の異なる帯域幅の複数のバージョンを記述しており、
前記サーバー（４２）から前記クライアント（４０）へのデータトラフィック内の前記メディア・プレゼンテーション記述（４６）を検査し、
現在の資源状態情報と前記メディア・プレゼンテーション記述（４６）とに基づいて、
−前記メディア・プレゼンテーション記述要求への回答として、前記メディア・プレゼンテーション記述（４６）を前記クライアント（４０）に転送するか、又は、
−前記メディア・プレゼンテーション記述（４６）をインターセプトし、前記メディア・プレゼンテーション記述を修正するか、
を決定する、資源管理装置。
［請求項４１］
請求項４０に記載の資源管理装置であって、前記メディア・プレゼンテーション記述を修正する際に、前記メディアコンテンツ（４４）の平均帯域幅よりも高い帯域幅の１つ又は複数のバージョンを除去するか、又は除去した後で再挿入する、資源管理装置。
［請求項４２］
請求項４０に記載の資源管理装置であって、前記インターセプト及び修正を実行する際に、
−前記クライアント（４０）に対し、メディアバッファ状態情報に関する明示的な信号伝達を、前記サーバー（３２）の代わりに前記資源管理装置に対して送信するよう指令するため、
−ユニキャストからマルチキャスト・プロトコルへのプロトコル変更を指示するため、
−前記クライアント（４０）に対し、前記資源管理装置が前記メディアコンテンツ（４４）を調整する可能性があることを通知するため、
前記メディア・プレゼンテーション記述（４６）に対して情報を追加し、
前記情報が追加されたメディア・プレゼンテーション記述を、前記クライアント（４０）に対して前記メディア・プレゼンテーション記述要求への回答として送信し、
異なる帯域幅の前記メディアコンテンツ（４４）の複数のバージョンの適切な部分集合だけを記述するよう、前記メディア・プレゼンテーション記述（４６）を削減し、かつ、その削減されたメディア・プレゼンテーション記述を、前記クライアント（４０）に対して前記メディア・プレゼンテーション記述要求への回答として送信する、資源管理装置。
［請求項４３］
請求項４０乃至４２のいずれかに記載の資源管理装置であって、前記メディア・プレゼンテーション記述（４６）を検査し、それにより、前記メディア・プレゼンテーション記述（４６）の中で、前記メディアコンテンツ（４４）の所望のバージョンとして関連するより低い最小帯域幅を持つメディアコンテンツ（４４）のバージョンを識別し、もし前記より低い最小帯域幅を持つバージョンが存在する場合には、前記現在の資源状態情報に依存して前記決定を実行する、資源管理装置。
［請求項４４］
請求項４０乃至４３のいずれかに記載の資源管理装置であって、前記資源管理装置は無線資源管理装置であり、前記クライアントが動作している前記ユーザーエンティティが属する複数のユーザーエンティティに対して、少なくとも１つの基地局の通信資源の割り当てを実行する、資源管理装置。
［請求項４５］
請求項４０乃至４４のいずれかに記載の資源管理装置であって、前記ユーザーエンティティ内の送受信ステージ（７０）と前記クライアント（４０）との間に配置され、前記現在の資源状態情報を前記送受信ステージ（７０）から取得する、資源管理装置。
［請求項４６］
請求項４０乃至４５のいずれかに記載の資源管理装置であって、前記ユーザーエンティティから前記基地局へのチャネル品質フィードバックに基づいて前記クライアント（４０）に関連するバッファ状態をシミュレートし、前記チャネル品質フィードバックは前記現在の資源状態情報に含まれており、前記バッファ状態に依存して前記決定を実行する、資源管理装置。
［請求項４７］
複数のユーザーエンティティの１つにおいて動作しているクライアントのメディアバッファ状態情報に依存して、基地局（３２）の通信資源を前記ユーザーエンティティ（３４）に対して割り当てる、無線資源管理装置。
［請求項４８］
請求項４６に記載の無線資源管理装置であって、前記ユーザーエンティティに対する通信資源の割り当てを、
−前記基地局（３２）の通信資源が適切な割合で割り当てられるべき前記ユーザーエンティティ（３４）の数、
−前記ユーザーエンティティと前記基地局との間で交換されるべき通信データの種類、
−前記ユーザーエンティティに割り当てられたユーザープロファイルであって、前記ユーザーエンティティ間の優先順位を定義するプロファイル、
−前記ユーザーエンティティからのチャネル品質フィードバック、
−前記ユーザーエンティティからのチャネルレート要求、
の内の１つ又は複数に基づいて実行する、無線資源管理装置。
［請求項４９］
請求項４７に記載の無線資源管理装置であって、前記通信資源を前記ユーザーエンティティに対して割り当てる際に、前記メディアバッファ状態情報に依存して、
−サブキャリア、
−集約されたサブキャリア、
−時間スロット、
−前記基地局セルの空間的カバー範囲、
の内の１つ又は複数を調整する、無線資源管理装置。
［請求項５０］
請求項４６乃至４８のいずれかに記載の無線資源管理装置であって、前記クライアント（４０）から前記サーバー（４２）へのデータトラフィック内の明示的な信号伝達から前記メディアバッファ状態情報を抽出するか、又は、前記ユーザーエンティティ（３４）から前記基地局（３２）へのチャネル品質フィードバックに基づいて前記クライアント（４０）に関連するバッファ状態をシミュレートすることにより、前記メディアバッファ状態情報を導出する、無線資源管理装置。
［請求項５１］
無線資源管理装置であって、
ユーザーエンティティ（３４）において動作しているクライアント（４０）と１つ又は複数のサーバー（３２）との間のデータトラフィックを調査し、
前記１つ又は複数のサーバー（３２）から前記クライアント（４０）の内の異なるクライアントへの前記データトラフィックの中に、共通のメディアコンテンツ（４４）に関連するメディア・プレゼンテーション記述があるか否かをチェックし、
前記チェックに基づいて、前記メディアコンテンツ（４４）のユニキャストバージョンのほかに、前記共通のメディアコンテンツ（４４）のマルチキャストバージョンを前記クライアント（４０）に対して提供するか、又は、前記チェックに基づいて、前記共通のメディアコンテンツをダウンロードしているクライアント（４０）に対してユニキャスト・プロトコルからマルチキャスト・プロトコルへプロトコルを変更させる、無線資源管理装置。
［請求項５２］
請求項５０に無線資源管理装置であって、基地局の通信資源を前記ユーザーエンティティに対して割り当てる、無線資源管理装置。
［請求項５３］
少なくとも１つの基地局（３２）の通信資源を複数のユーザーエンティティ（３４）に対して割り当てる無線資源管理装置であって、
前記ユーザーエンティティの１つにおいて動作しているサーバー（４２）若しくはクライアント（４０）へのデータトラフィックを調査するか、又は、他の無線資源管理装置からの制御情報を調査することにより、
−前記サーバー（４２）と前記クライアント（４０）との他方が動作する外部ユーザーエンティティに現在割り当てられている保証付き通信資源と、
−前記サーバー（４２）と前記クライアント（４０）との他方のバッファ状態と、
に関する情報を取得し、
前記割り当てを前記取得された情報に基づいて実行する、無線資源管理装置。
［請求項５４］
請求項５２に記載の無線資源管理装置であって、前記ユーザーエンティティ（３４）に対して前記少なくとも１つの基地局（３２）の通信資源を割り当てる際に、前記ユーザーエンティティに対して保証付きの通信資源を時間区間の単位で割り当て、前記通信資源を前記時間区間内において割り当てる際に、前記保証付き通信資源に従うよう構成されている、無線資源管理装置。
［請求項５５］
請求項５３に記載の無線資源管理装置であって、
前記サーバー（４２）と前記クライアント（４０）との一方が動作しているユーザーエンティティに対して割り当てられた保証付き通信資源に関する情報を、前記ユーザーエンティティ（３２）の１つにおいて動作しているサーバー（４２）又はクライアント（４０）からのデータトラフィックの中に挿入する、無線資源管理装置。
［請求項５６］
請求項５２又は５３に記載の無線資源管理装置であって、
前記ユーザーエンティティの１つにおいて動作しているサーバー又はクライアントと、前記サーバーと前記クライアントとの他方と、の間のメディア伝送セッションのセットアップに応じて、前記サーバーと前記クライアントとの他方が、前記無線資源管理装置が属する無線システムの他のいずれかの無線資源管理装置によってサービス提供されている外部ユーザーエンティティ上で動作しているか否かをチェックし、
前記サーバーと前記クライアントとの他方が、前記無線システムの他のいずれかの無線資源管理装置によってサービス提供されている外部ユーザーエンティティ上で動作している場合には、
前記無線システムの前記他の無線資源管理装置に対し、
−前記ユーザーエンティティに対して現在割り当てられている保証付き通信資源と、
−前記サーバー（４２）と前記クライアント（４０）との一方のバッファ状態と、
を信号伝達する外向きの制御情報を送信し、
前記無線システムの前記他の無線資源管理装置からの、
−前記サーバー（４２）と前記クライアント（４０）との他方が動作している前記外部ユーザーエンティティに対して現在割り当てられている前記保証付き通信資源と、
−前記サーバー（４２）と前記クライアント（４０）との他方のバッファ状態と、
についての情報を信号伝達する内向きの制御情報を調査するよう構成されている、無線資源管理装置。
［請求項５７］
請求項５２乃至５５のいずれかに記載の無線資源管理装置であって、前記ユーザーエンティティに対する通信資源の割り当てを、
−前記少なくとも１つの基地局（３２）の通信資源が適切な割合で割り当てられるべきユーザーエンティティ（３４）の数、
−前記ユーザーエンティティと前記少なくとも１つの基地局との間で交換されるべき通信データの種類、
−前記ユーザーエンティティに割り当てられるユーザープロファイルであって、前記ユーザーエンティティ間の優先順位を定義するプロファイル、
−ユーザーエンティティからのチャネル品質フィードバック、
−ユーザーエンティティからのチャネルレート要求、
の内の１つ又は複数に基づいて実行する、無線資源管理装置。
［請求項５８］
請求項５２乃至５６のいずれかに記載の無線資源管理装置であって、前記ユーザーエンティティに対して通信資源を割り当てる際に、
−サブキャリア、
−時間スロット、
−前記少なくとも１つの基地局セルの空間的カバー範囲、
の内の１つ又は複数を調整する、無線資源管理装置。
［請求項５９］
請求項５２乃至５７のいずれかに記載の無線資源管理装置であって、前記取得された情報に基づいて、
前記サーバー（４２）と前記クライアント（４０）との他方のバッファ状態が増大している場合には、前記ユーザーエンティティに割り当てられる通信資源の量が減少するように、及び／又は、
前記外部ユーザーエンティティに対して現在割り当てられている前記保証付きの通信資源が減少している場合には、前記ユーザーエンティティに割り当てられる通信資源の量が減少するように、
前記割り当てを実行する、無線資源管理装置。
［請求項６０］
無線資源管理の方法であって、
サーバー（４２）からクライアント（４０）へのデータトラフィック内において転送されるメディアコンテンツ（４４）に関連するメディア・プレゼンテーション記述（４６）に依存して、少なくとも１つの基地局（３２）の通信資源を複数のユーザーエンティティ（３４）へと割り当てるステップを含み、前記サーバー（４２）と前記クライアント（４０）との一方が前記ユーザーエンティティ（３２）の１つで動作している、方法。
［請求項６１］
クライアント（４０）又はサーバー（３２）が動作可能であるユーザーエンティティ上で実行される方法であって、前記ユーザーエンティティは無線資源基地局（３２）と通信している、方法において、
メディアコンテンツ（４４）の異なる帯域幅の複数のバージョンを記述するメディア・プレゼンテーション記述（４６）を導出するために、前記クライアント（４０）と前記サーバー（３２）との間のデータトラフィックを調査するステップと、
前記ユーザーエンティティが属している複数のユーザーエンティティに対して前記無線資源基地局（３２）の通信資源を割り当てる役割を担う無線資源管理装置（３０）に対し、前記メディア・プレゼンテーション記述を少なくとも部分的に転送するステップと、
を含む方法。
［請求項６２］
クライアント（４０）が動作可能であるユーザーエンティティ上で実行される方法であって、前記ユーザーエンティティは無線資源基地局（３２）と通信している、方法において、
前記クライアントによってサーバー（４２）からリトリーブされたメディアコンテンツの受信されたメディアコンテンツ・スループット又はバッファ状態を決定するステップと、
前記ユーザーエンティティに対して前記無線資源基地局（３２）の通信資源を割り当てる役割を担う無線資源管理装置（３０）に対し、前記決定されたメディアコンテンツ・スループット又はバッファ状態について通知するステップと、
を含む方法。
［請求項６３］
メディアコンテンツ（４４）の異なる帯域幅の複数のバージョンを記述しているメディア・プレゼンテーション記述（４６）を、サーバー（４２）からユーザーエンティティ（３４）において動作しているクライアント（４０）へのデータトラフィック内で検査するステップと、
前記メディアコンテンツ（４４）の所望のバージョンを要求する、前記クライアント（４０）から前記サーバー（４２）へのメディア要求（６０）を検査するステップと、
現在の資源状態情報と前記メディア・プレゼンテーション記述（４６）とに依存して、
−前記サーバーに対して前記メディア要求（６０）を転送するか、又は、
−前記メディア要求（６０）が前記クライアント（４０）に送信されるべき前記メディアコンテンツ（４４）の前記所望のバージョンをもたらさない状態とするか、
を決定するステップと、
を含む方法。
［請求項６４］
メディアコンテンツ（４４）の異なる帯域幅の複数のバージョンを記述しているメディア・プレゼンテーション記述（４６）を、サーバー（４２）からユーザーエンティティ（３４）において動作しているクライアント（４０）へのデータトラフィック内で検査するステップと、
前記メディアコンテンツ（４４）の所望のバージョンを要求する、前記クライアント（４０）から前記サーバー（４２）へのメディア要求（６０）を検査するステップと、
前記ユーザーエンティティ（３４）から基地局（３２）へのチャネル品質フィードバックに基づいてシミュレートするか、前記基地局（３２）の反対側又は前記基地局（３２）の内部に位置するメディアコンテンツバッファ（１００）を監視するか、又は前記クライアント（４０）から前記サーバー（４２）へのデータトラフィック内での明示的な信号伝達から前記ユーザーエンティティのバッファ状態を抽出することにより、前記クライアントについてのユーザーエンティティのバッファ状態を取得するステップと、
前記ユーザーエンティティのバッファ状態と前記メディア・プレゼンテーション記述（４６）とに依存して、
−前記サーバーに対して前記メディア要求（６０）を転送するか、又は、
−前記メディア要求（６０）が前記クライアント（４０）に送信されるべき前記メディアコンテンツ（４４）の前記所望のバージョンをもたらさない状態とするか、
を決定するステップと、
を含む方法。
［請求項６５］
ユーザーエンティティ（３４）において動作しているクライアント（４０）からサーバー（４２）へのメディア・プレゼンテーション記述要求を検査するステップであって、前記メディア・プレゼンテーション記述要求は前記サーバー（４２）からメディア・プレゼンテーション記述（４６）を要求するものであり、前記メディア・プレゼンテーション記述（４６）はメディアコンテンツ（４４）の異なる帯域幅の複数のバージョンを記述するものである、ステップと、
前記サーバー（４２）から前記クライアント（４０）へのデータトラフィック内の前記メディア・プレゼンテーション記述（４６）を検査するステップと、
現在の資源状態情報と前記メディア・プレゼンテーション記述（４６）とに基づいて、
−前記メディア・プレゼンテーション記述要求への回答として、前記メディア・プレゼンテーション記述（４６）を前記クライアント（４０）に転送するか、又は、
−前記メディア・プレゼンテーション記述（４６）をインターセプトし、前記メディア・プレゼンテーション記述を修正するか、
を決定するステップと、
を含む方法。
［請求項６６］
無線資源管理の方法であって、
複数のユーザーエンティティ（３４）において動作している複数のクライアント（４０）と１つ又は複数のサーバー（３２）との間のデータトラフィックを調査するステップと、
前記１つ又は複数のサーバー（３２）から前記クライアント（４０）の内の異なるクライアントへの前記データトラフィックの中に、共通のメディアコンテンツ（４４）に関連するメディア・プレゼンテーション記述があるか否かをチェックするステップと、
前記チェックに基づいて、前記メディアコンテンツ（４４）のユニキャストバージョンのほかに、前記共通のメディアコンテンツ（４４）のマルチキャストバージョンを前記クライアント（４０）に対して提供するか、又は、前記チェックに基づいて、前記共通のメディアコンテンツをダウンロードしているクライアント（４０）に対してユニキャスト・プロトコルからマルチキャスト・プロトコルへのプロトコル変更を生じさせるステップと、
を含む方法。
［請求項６７］
少なくとも１つの基地局（３２）の通信資源を複数のユーザーエンティティ（３４）に対して割り当てる方法であって、
前記ユーザーエンティティの１つにおいて動作しているサーバー（４２）若しくはクライアント（４０）へのデータトラフィックを調査するか、又は、少なくとも１つの異なる基地局へ通信資源を割り当てる他の無線資源管理装置からの制御情報を調査することにより、
−前記サーバー（４２）と前記クライアント（４０）との他方が動作する外部ユーザーエンティティに現在割り当てられている保証付き通信資源と、
−前記サーバー（４２）と前記クライアント（４０）との他方のバッファ状態と、
に関する情報を取得するステップと、
前記割り当てを前記取得された情報に基づいて実行するステップと、
を含む方法。
［請求項６８］
コンピュータ上で作動されたとき、請求項５９乃至６６のいずれかに記載の方法を実行するためのプログラムコードを有するコンピュータプログラム。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】