JP6612313B2 - メディアストリーム伝送のためのセッション制御 - Google Patents

Description

本発明はメディアストリームの伝送を制御するための方法に関する。本発明を実施する装置及びソフトウェアプログラムも記載される。

インターネット又は移動体電話ネットワークのような伝送ネットワークの１つの重要な用途は、サーバからクライアントへのメディア配信である。メディアは例えばオーディオやビデオでありうる。

ＩＰ（インターネットプロトコル）ベースのネットワークにおけるメディア配信は様々なトランスポートプロトコルを用いうる。伝統的に、リアルタイムストリーミング及びパケットベースのストリーミングにＵＤＰ（ユーザデータグラムプロトコル）上のＲＴＰ（リアルタイムトランスポートプロトコル）が用いられるか、ファイル全体のダウンロードにＴＣＰ（トランスミッション制御プロトコル）上のＨＴＴＰ（ハイパーテキストトランスファープロトコル）が用いられるかのいずれかであり、ＨＴＴＰの大半は後での利用のためであるが、生のストリーミングのためでもある。ＲＴＰは、クライアントによって測定された利用可能なビットレートへの動的適応を可能にする。ＲＴＰ及び関連する制御プロトコルであるＲＴＳＰ（リアルタイムストリーミングプロトコル）の欠点は専用の複雑なサーバソフトウェアが必要なことであるのに対して、ＨＴＴＰは幅広く使用されている廉価なＨＴＴＰサーバソフトウェアを用いうる。最近開発されたアダプティブＨＴＴＰストリーミング（ＡＨＳ）は、両アプローチの利点を組み合わせることを目的とする。ＡＨＳは３ＧＰＰ（第３世代パートナシッププロジェクト）で標準化され、オープンＩＰＴＶフォーラム（ＯＩＰＦ）でも採用され、わずかに拡張されている。ＭＰＥＧ（ムービングピクチャエキスパートグループ）もＡＨＳに関して作業を行っている。

ＡＨＳでは、コンテンツは様々なバージョンで符号化され、通常は様々なビットレートに対応する。コンテンツが例えばビデオトラック及びオーディオトラックを有するビデオであるならば、ビデオトラックは互いに異なるビットレートを有する３つのバージョンで符号化されえ、オーディオトラックは高品質ステレオバージョン及びモノラルバージョンで符号化されうる。各バージョンはさらに、数秒間のセグメントに分割される。例えば、ビデオバージョンは、それぞれが１０秒間である連続した多くのセグメントに分割されうる。セグメントは、ＭＥＰＧ４ファイル形式に従ってフォーマットされてもよいし、ＭＰＥＧ２トランスポートストリーム形式に従ってフォーマットされてもよい。

ビデオトラック及びオーディオトラックの実際の伝送は、クライアントにより開始されるセグメントごとのダウンロードによって実行される。この手続きでは、クライアントは標準ＨＴＴＰリクエストを用いてセグメントをダウンロードし、これをアンパックし、復号し、レンダリングし、その後、次のセグメントなどにも同じことを行う。クライアントは利用可能な品質バージョンに関する知識と、いわゆるメディアプレゼンテーション記述（ＭＰＤ）であるメディア記述による時間を通じたセグメント分離（separation）に関する知識を有する。３ＧＰＰ及びＯＩＰＦにおいて規定されるＭＰＤフォーマットはメディアを記述する適切な情報及び属性を含むＸＭＬ（拡張可能なマーク付け言語）符号化ファイルである。ＭＰＤは、ＡＨＳベースのメディア配信を開始するためにクライアントへ送信される最初のリソースである。３ＧＰＰで特定されるようなＭＰＤは、様々な利用可能な品質と、これらがどのようにセグメントに編成されるかに関する情報を含む。

各セグメントは、伝送に用いられるネットワークの現在の動作状況の下で利用可能な最大速度でダウンロードされ、クライアントは自身が経験するダウンロード速度を監視する。経験したダウンロード速度に基づいて、クライアントは利用可能な品質バージョンのうち最も適切なものを選択する。セグメントごとに、これは異なるバージョンであってもよく、クライアントは現在の動作状況に依存して様々な品質をダウンロードでき、それ故、属性「アダプティブ」ＨＴＴＰストリーミングである。図１は原理を図示し、再生時間の関数としてコンテンツアイテムのアダプティブＨＴＴＰストリーミングのための様々なメディア表現を示す。図１の３つの表現はそれぞれ、コンテンツアイテム、すなわちストリームの高ビットレート表現、中ビットレート表現及び低ビットレート表現に対応する。表現間の滑らかな切り替えが可能なように、相異なる表現のストリームセグメントについての再生時間の最初と最後とが一致する。図１の縦軸は様々なストリーム表現のデータサイズ、例えばこれらのビットレートを示す。クライアントの実装に依存して、ストリームを見たり聞いたりする場合に過度な品質のばらつきを避けるために、例えばヒステリシスを含む表現間の切替のための高度な選択手続きが可能である。

マルチメディア通信における別の傾向は、マルチメディアセッションの開始・制御にＩＰマルチメディアサブシステム（ＩＭＳ）を使用することである。３ＧＰＰでは、ＩＭＳ制御のＲＴＰストリーミングだけでなく、ＩＭＳ制御のＨＴＴＰプログレッシブダウンロードについて標準化されたソリューションが、ＩＰメディアサブシステム（ＩＭＳ）ベースのパケット交換ストリーミング（ＰＳＳ）及びマルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）ユーザサービス；プロトコルという名称で３ＧＰＰ ＴＳ２６．２３７Ｖ９．３．０（２０１０年６月）に規定されている。これらのソリューションは、課金、認証又はＱｏＳ（サービス品質）予約のようなＩＭＳにより提供される標準機能の利益を受ける。

図２は、３ＧＰＰ ＴＳ２６．２３７に規定されるようなＩＭＳ制御のＨＴＴＰプログレッシブダウンロードの場合の様々なシグナリングステップを示す。セッションは、ＳＤＰ（セッション記述プロトコル）情報を含むＳＩＰ（セッション開始プロトコル）ＩＮＶＩＴＥメッセージで始まる。ダウンロードのためのＨＴＴＰ ＵＲＬ（ユニフォームリソースロケータ）が、ＳＩＰ ２００ ＯＫメッセージを介して、ユーザ機器（ＵＥ）、すなわちクライアントへ配信される。さらに、ＨＴＴＰプログレッシブダウンロードセッションのためのＱｏＳ予約が実行されてもよい。プログレッシブダウンロード自体はＨＴＴＰサーバへのＨＴＴＰ ＧＥＴコマンドを用いてＵＥによって開始され、ＨＴＴＰサーバはそれに対して、要求されたコンテンツファイルで応答する。より詳細には、以下のステップが実行される。
１．ＵＥは、ＳＤＰオファーを含む、ＩＭ ＣＮサブシステムへのＳＩＰ ＩＮＶＩＴＥを送信することによって、プログレッシブダウンロードを開始する。
２．ＩＭ ＣＮサブシステムは、ＳＩＰ ＩＮＶＩＴＥメッセージをＳＣＦへ転送する。
３．ＳＣＦは、要求されたコンテンツへのユーザ権利を検証し、ＨＴＴＰ／ＳＩＰアダプタを選択し、ＳＩＰ ＩＮＶＩＴＥメッセージをＨＴＴＰ／ＳＩＰアダプタへ転送する。
４．ＨＴＴＰ／ＳＩＰアダプタはＨＴＴＰサーバを選択し、ＨＴＴＰサーバへ、ＵＥのＩＰアドレスを含むＨＴＴＰ ＰＯＳＴメッセージを送信する。
５．ＨＴＴＰサーバは、ＨＴＴＰ ２００ ＯＫレスポンスでＨＴＴＰ／ＳＩＰアダプタに答える。
６．ＨＴＴＰ／ＳＩＰアダプタは、要求されたコンテンツファイルのダウンロードＵＲＬをＳＤＰレスポンス内に含むＳＩＰ ２００ ＯＫアンサをＳＣＦへ送信する。
７．ＳＣＦはＳＩＰ ２００ ＯＫをＩＭ ＣＮサブシステムへ転送する。
８．ＩＭ ＣＮサブシステムはＳＩＰ ２００ ＯＫをＵＥへ転送する。
９．ＵＥは、ＳＩＰ ２００ ＯＫメッセージから取得されたＵＲＬへＨＴＴＰリクエストを送信する。
１０．ＨＴＴＰサーバはＵＥへのＨＴＴＰレスポンスにおいてコンテンツファイルを配信する。

例えば３ＧＰＰ ＴＳ２６．２３４トランスポートエンドツーエンドパケット交換ストリーミングサービス（ＰＳＳ）、オープンＩＰＴＶフォーラム、リリース２仕様書、ＨＴＴＰアダプティブストリーミング、ドラフトＶ０．０６（２０１０年６月７日）や、マイクロソフトのスムースストリーミングやアップルストリーミング（Ｒ．パントス、ＨＴＴＰライブストリーミング、http://tools.ietf.org/html/draft-pantos-http-live-streaming-01を参照）のような独自のソリューションで特定される現在のＡＨＳコンセプトは、メディアパッケージング、メディア記述及びダウンロードメカニズムを特定するに過ぎない。これらのメカニズムをリソース又はＱｏＳ予約メカニズムと組み合わせるための関連は予見されない。よって、ＱｏＳ予約・制御が可能な管理システムにおいてさえも、ＡＨＳはベストエフォートで動作し、従って一般になおもアダプテーションを必要とするだろう。

本発明の目的は、メディアストリームの伝送を制御するための改良された方法及び対応する装置を提供することである。

提案される方法は、連続した複数のストリーム要素を有するメディアストリームに関する。本方法では、メディアストリームのメディア記述が取得される。メディア記述は複数のストリーム要素のうちの最初の要素を示す。最初の要素を求めるリクエストが送信される。セッションのためのセッション制御手続きも開始される。セッション制御手続きにおいて、メディアストリームがセッションに関連付けられる。セッションの制御ルールに従って複数のストリーム要素のうちの後続の要素の伝送が制御される。

連続した複数のストリーム要素を有するメディアストリームの伝送を制御するための方法は、メディアクライアントにおいても実行されうる。クライアントにおける本方法は、メディアストリームのメディア記述を取得するステップを有する。メディア記述は、複数のストリーム要素のうちの最初の要素を示す、メディアクライアントは、最初の要素を求めるリクエストを送信する。メディアクライアントはまた、メディアストリームの伝送のためのセッション制御手続きを開始する。

本発明によるメディアクライアントは、送信部及び受信部に結合される制御部を備える。制御部は、受信部へのメディアストリームの伝送を制御するように適合される。メディアストリームは連続した複数のストリーム要素を有する。制御部は、メディアストリームのメディア記述を取得するようにさらに適合される。メディア記述は、複数のストリーム要素のうちの最初の要素を示す。制御部は、送信部による最初の要素を求めるリクエストの送信を開始し、メディアストリームの伝送のためのセッション制御手続きを開始するように適合される。

有利なメディアサーバは、連続した複数のストリーム要素を有するメディアストリームの伝送を、クライアントからの複数のストリーム要素を求めるリクエストに応じて制御する制御部を有する。メディアサーバはまた、複数のストリーム要素を送信するように適合された送信部を有する。メディアサーバはさらに、複数のストリーム要素のうちの最初の要素を求めるリクエストであって、最初の要素を示すリクエストを受信するための受信部を有する。受信部はまた、メディアストリームの伝送のためのセッション制御手続きの結果を受信し、ストリーム要素のうちの後続の要素を求める別のリクエストを受信ように適合される。制御部は送信部及び受信部に結合され、セッション制御手続きの結果に基づいて後続の要素の送信を制御するように適合される。

メディアサーバにおける方法は、連続した複数のストリーム要素を有するメディアストリームの伝送を、クライアントからの複数のストリーム要素を求めるリクエストに応じて制御する。本方法は、複数のストリーム要素のうちの最初の要素を求めるリクエストを受信するステップを有する。リクエストは最初の要素を示す。示された最初の要素が送信される。別のステップで、メディアストリームの伝送のためのセッション制御手続きの結果が受信される。複数のストリーム要素のうちの後続の要素を求める別のリクエストを受信すると、セッション制御手続きの結果に基づいて後続の要素の送信が制御される。

有利な制御エンティティは、メディアサーバからの連続した複数のストリーム要素を有するメディアストリームの伝送のためのメディアクライアントとのセッション制御手続きを実行するのに適する。制御エンティティは、メディアストリームの伝送のためのセッション制御手続きのシグナリングを受信するための受信部を備える。制御部は、シグナリングを終了し、受信部に結合される。制御部はまた、メディアストリームをセッション制御手続きにおけるセッションに関連付けるように適合される。制御部は、セッションの制御ルールに従って複数のストリーム要素のうちの後続の要素の伝送の制御を開始する命令のための送信部に結合される。

制御エンティティにおける方法は、メディアサーバからの連続した複数のストリーム要素を有するメディアストリームの伝送のためのメディアクライアントとのセッション制御手続きのために実行される。本方法は、メディアストリームの伝送のためのセッション制御手続きのシグナリングを受信するステップを有する。シグナリングは終了され、メディアストリームはセッション制御手続きにおけるセッションに関連付けられる。セッションの制御ルールに従って、複数のストリーム要素のうちの後続の要素の伝送の制御を開始する命令が送信される。

メディアプロキシは、サーバからクライアントへメディア記述を転送するのに適する。メディアプロキシは、複数の表現記述を有するメディア記述をサーバから受信するための受信部を備える。各表現記述はメディアストリームの異なる表現を示す、制御部は、複数の表現記述のうちの少なくとも１つと、当該少なくとも１つの表現記述のメディアソースとをメディア記述から削除するか変更することによって、メディア記述を変更するように適合される。送信部は、変更されたメディア記述をクライアントへ送信するように適合される。

サーバからクライアントへメディア記述を転送するためのメディアプロキシにおける方法は、複数の表現記述を有するメディア記述を前記サーバから受信するステップを有する。各表現記述はメディアストリームの異なる表現を示す。複数の表現記述のうちの少なくとも１つと、当該少なくとも１つの表現記述のメディアソースとをメディア記述から削除するか変更することによって、メディア記述が変更される。変更されたメディア記述は前記クライアントへ送信される。

上述の方法はまた、例えば信号のシーケンスとして記述された、データ記憶媒体に格納されるか処理システム又は装置のメモリに読み込み可能でありうるプログラムとして実施されうる。

本発明の上述の目的・機能・利点又はその他の目的・機能・利点は添付の図面で説明される実施形態の以下の詳細な説明から一層明らかになるだろう。

メディアストリームのメディア表現を説明する図である。 ＩＭＳ制御のＨＴＴＰダウンロードのシグナリング図を示す。 提案される方法のフローチャートを示す。 提案される方法に適合されたメディアクライアントを示す図である。 提案される方法に適合されたメディアサーバを示す図である。 メディアサーバで実行される方法を示す図である。 提案される方法に適合された制御エンティティを示す図である。 制御エンティティで実行される方法を示す図である。 提案される方法に適合されたメディアプロキシを示す図である。 メディアプロキシで実行される方法を示す図である。 提案される方法の実施形態についてのシグナリング図を示す。

本方法は、連続した複数のストリーム要素を有するメディアストリームの伝送の制御に関する。本方法の第１実施形態が図３に示される。ストリーム要素は例えばＨＴＴＰストリーミングで用いられるもののような、例えばストリームセグメントでありうる。セグメントは様々な品質、例えば様々なメディア解像度で利用可能でありうる。ストリームは、例えばビデオトラック又はオーディオ伝送に関してもよく、様々なストリームは互いに関連付けられてもよく、例えばビデオトラックはオーディオトラックに関連付けられてもよい。ストリームは、ユーザにストリームをレンダリングするように適合された任意のユーザ機器、例えばパーソナルコンピュータや移動体電話機でありうるクライアントへ伝送されうる。

本方法では、メディアストリームのメディア記述は、例えばクライアントによってダウンロードされたファイルから取得される（３２）。メディア記述はメディア要素のうちの最初の要素を、例えば最初の要素が利用可能となるＵＲＩのようなメディアソースとして示す。一般に、ストリームの各要素のためのソースが個別に伝送されなければならないことを回避するために、メディアソースは、クライアントにより要素へのＵＲＩを生成するためのテンプレートによって、例えばｎの関数としてストリームのｎ番目の要素のソースを生成するためのルールを提供することによって示されてもよい。本明細書の用語では、ストリーム要素のホストとなり（例えば、記憶し又は生成し）ストリーム要素を提供するプラットフォーム、例えばサーバ又はネットワークとは対照的に、メディアソースはストリーム要素の特定の起源を示す。従って、リクエストは、例えばＩＰアドレス及びポート番号でプラットフォームにアドレス指定されてもよく、例えばリクエストに含まれるＨＴＴＰ ＧＥＴメッセージの形式でメディアソースを含んでもよい。

メディアファイルはまた、ストリームの様々な表現のうちの１つ以上の記述、例えばビデオの様々な画像解像度の表示を含んでもよい。オプションとして、例えばストリームが様々な品質で又は様々なサーバから利用可能であり、クライアントがそのうちの１つを選択できるならば、最初の要素に対して複数のメディアソースが示される。最初のストリーム要素を求めるリクエストは、例えばクライアントによって、メディアソースから最初の要素を取得するためにプラットフォームへ送信される（３４）。

メディアストリームの伝送のためのセッション制御手続きも、例えばクライアント又はネットワークによって開始される（３６）。セッションは、クライアントと、例えばネットワークのポリシー制御要素によって行使されうる特定された伝送属性で伝送を実行するネットワークとの間の伝送コンテキストである。無線ネットワークでは、セッションは典型的にセッションを輸送する無線アクセスベアラに関連付けられる。セッション制御手続きはメディアストリームをセッションに関連付ける（３８）任意の手続きであってもよく、例えばストリームのためのセッション確立であってもよいし、メディアストリームがセッションに関連付けられている既存のセッションの変更であってもよい。関連付けはストリームが伝送されるセッションを特定する。

セッション制御手続きは、リクエストの送信の前に開始されてもよいし、リクエストの送信と同時に開始されてもよいし、リクエストの送信の後に開始されてもよい、実施形態では、セッション制御手続きの開始とリクエストとが本質的に同時に又は互いにわずかに前後して行われるならば有利である。従って、セッション制御手続きが終了する前にメディアストリーミングが開始されうる。

ストリーム要素のうちの後続の要素、すなわちセッション制御手続きの全部の結果又は一部の終結（conclusion）の後に送信されるストリーム要素の伝送は、その後、セッションの制御ルールに従って制御されうる（４０）。後続の要素は最初の要素の直後に続く必要はなく、例えばセッション制御手続きの実行時間及びストリーム要素の提示時間に依存して、両者の間に１つ以上の要素が存在する可能性がある。典型的に、制御は任意の後続のストリーム要素について実行される。少なくとも１つの制御ルールは、例えば、セッションについての特定のサービス品質、例えばビットレート、請求手続きの開始、又はユーザが対応する加入契約又は口座残高を欠いているならばセッションの遮断について規定しうる。制御はまた、ストリーミング処理の監視や、他のサービス、例えばストリームにバックグラウンド情報を提供するプッシュサービスや、例えばストリームされた映画のサウンドトラックを購入可能にする注文サービスとストリーミング処理との統合を含みうる。制御ルールに従う制御は、例えばゲートウェイにおいて、ストリーミングを伝送するポリシー行使ポイントによって実行されてもよく、ストリーム要素は例えば要素のパケットヘッダ内の要素におけるアドレス情報に基づいて識別されうる。

実施形態では、セッション制御手続きは、メディアストリームに関連付けられたセッション制御についてのソースを示すリソースロケータを取得するステップを有する。これにより、セッション制御のついてのソースとともにセッション制御手続きを開始するためのリクエストを対応するプラットフォームへ送信できる。リソースロケータはメディア記述に含まれてもよいし、メディア記述に関連付けられてもよく、例えばメディア記述と同じメッセージで送信される。これらの場合に、両者は同時に利用可能でありうる。

オプションとして、メディア記述は、セッション制御手続きにおけるセッションパラメータを特定する少なくとも１つの情報要素を有するか、これに関連付けられる。例えば、メディア記述又はメディア記述内の個別の表現は、ストリーム又はストリーム表現を伝送するために必要な帯域幅を示してもよい。パラメータは、その後、ストリームが関連付けられるセッションを確立又は変更するための要件として、例えばＳＤＰファイルにおいて特定されうる。

セッション制御手続きは、特にセッション制御手続きがクライアントによって開始されるならば、クライアントによりセッション制御手続きに対するセッション制御レスポンス、例えばＳＩＰ ２００ ＯＫメッセージを受信するステップを有しうる。その後、クライアントは、セッション制御レスポンスの受信に応じて、一般的に別のメディアソースを示すストリームの後続の要素又は要素群を求めるリクエストを送信してもよい。例えば、ストリームをセッションに関連付けた後に、別のソースから利用可能な、より高いストリーム品質が要求されうる。後続の要素を求めるリクエストが別のメディアソースを示すならば、これはまた、ポリシー制御のためのストリーム要素の識別を単純にしうる。別のメディアソースは、ストリーム要素の最初のソースと同じプラットフォーム、例えばサーバでホストされてもよいし、別のプラットフォームでホストされてもよい。

セッション制御手続きがクライアントによってセッション制御手続きについてのセッション制御レスポンスを受信するステップを有するならば、クライアントはまた、セッション制御レスポンスの受信に応じて、例えば上述の実施形態とは異なるステップの順番で、ストリームの最初の要素を求めるリクエストを送信してもよい。この場合に、ストリーミングセッションの開始は、記載された他の実施形態と比べて遅らされてもよいが、ストリームの先頭から適切なセッションが存在することが保証されうる。これは、事前の認可なしに受信されるべきではないコンテンツの最初の要素へのアクセスを回避できる。従って、最初のストリーム要素を求めるリクエストを送信するステップは、この実施形態では、セッション制御レスポンスの受信まで遅らされ、伝送を制御するステップは、後続の要素に関連するだけでなく、最初の要素の伝送も含みうる。この場合に、セッション制御手続きについてのセッション制御レスポンス、例えばＳＩＰ ２００ ＯＫメッセージを有するクライアントによってのみメディア記述が取得されることが可能であり、レスポンスはまた、後述される別の情報を含みうる。メディアストリームを識別する情報が、例えばクライアントにより提供されて、セッション制御手続きで取得されうることだけが必要である。

セッション制御レスポンスは、セッションを特定する１つ以上のパラメータを示しうる。これは例えば、セッションを処理又は監視することを可能にするセッション識別子でありうる。セッションを特定するパラメータはまた、セッション制御手続きがリソース予約を含むならば、許可されたサービス品質を示しうる。後続のストリーム要素についての別のメディアソースが、後続の要素のついての複数のメディアソースから選択されるならば、複数のものからの各メディアソースはセッションを特定する異なるパラメータに関連付けられうる。これにより、例えば、制御レスポンス内のパラメータに基づくダウンロードのための異なるストリーム品質又はプラットフォームの選択が可能になる。

セッション制御レスポンスはまた、例えばメディアソースのＵＲＩとして、又は複数のＵＲＩを生成するためのテンプレートとして、メディアソースの表示を含みうる。このように、制御レスポンスは、例えば請求を開始するために事前のセッション制御手続きなしに個別のソースの使用が許可されないならば、例えば関連付けられたソースなしにメディア記述に示されたメディア表現についてのソースを示しうる。

セッション制御レスポンスはまた、例えばメディアストリームの別の表現を有するメディア記述を含みうる。含まれるメディア記述が以前に受信したバージョンから更新されたならば、例えば、開始された請求又はクライアント加入契約のチェックに基づいて事前のセッション制御手続きによりストリームへのアクセスが一般的に許可された後に、高品質のビデオについて要求されたセッションパラメータを取得するためのセッションパラメータを変更するために、例えばＱｏＳ再交渉のような別のセッション制御手続きを、更新されたメディア記述の受信が引き起こすことが可能である。

セッションを特定するパラメータはまた、後続の要素を求めるリクエストに含まれうる。これにより、例えば、クライアントが別のメディアソースからのメディアにアクセスすること又はセッションについての制御エンティティからのメッセージにセッションを関連付けることが許可されることを認証することをセッション識別情報が可能にする。

別のメディアリソースとセッション制御のためのソースとの両方はセッションに固有であってもよく、すなわちこれらはセッションに関連付けられてもよい。例えば、別のメディアソースはセッション開始に応じて生成されてもよく、容易に推測できず、このセッションだけのためのアクセスを提供するように、無作為な又は擬似的に無作為な要素を含んでもよい。また、セッション制御についての個別のソースは、個別化されたメッセージ又はメディア記述で送信されてもよい。これにより、無許可のアクセス及びサービス妨害攻撃を回避できる。また、最初のメディアソースがメディア記述又は実施形態によってはセッションに固有であることも可能である。

別の実施形態では、メディア記述は複数の表現記述を含み、各表現記述はメディアソースの異なる表現及び関連付けられたメディアソースを示す。最初のメディアソースと別のメディアソースとの両方はその後、例えばメディアストリームの様々な品質レベルを取得するために、メディア記述に基づいて選択されうる。選択されたメディアソースはその後、最初の要素を求めるリクエスト又は後続の要素を求めるリクエストに含められうる。

クライアント、例えばＵＥは、連続した複数のストリーム要素を有するメディアストリームの伝送を制御するための方法を実行するように適合されうる。本方法に従って、クライアントは例えばリクエストに応じたメッセージで受信することによって、又は他の任意の方法によって、メディアストリームのメディア記述を取得する。メディア記述は、最初の要素が要求されうるＵＲＩのようなメディアソースとして、ストリーム要素のうちの最初の要素を示す。従って、クライアントはメディアソースからの最初のストリーム要素を求めるリクエストを、例えば関連付けられたプラットフォームへ送信する。クライアントはまた、メディアストリームの伝送のためのセッション制御手続きを開始する。最初のストリーム要素は、セッション制御手続きの終結、例えばセッション確立や、メディアストリームが関連付けられうるセッションの変更を待つことなく要求されてもよい。これに対応して、ストリーム制御の追加のオプションを提供しうるセッションの確立を待ちつつ、例えば所定のＱｏＳを処理しつつ、例えばベストエフォート品質を有する最初の伝送が迅速に実行されうる。これは特に、ストリーム再生を開始する際にユーザ体験を向上しうる。

上記の方法の側面を実行するように適合されたメディアクライアント４８が図４に示される。これは、送信部５２及び受信部５４に結合された制御部５０を備える。送信部５２及び受信部５４は、例えば送受信部の一部として、固定通信システム又は無線通信システムで無線伝送を送受信するように適合されうる。伝送は、例えばＨＴＴＰリクエスト及びＨＴＴＰレスポンスを有するＩＰパケットとして送信されうる。制御部５０は、例えばソフトウェアプログラムによって実施される制御ルーチンを実行する、メモリ５８を有する処理システム５６内に例えば実装されうる。

制御部５０は、連続した複数のストリーム要素６０を有するメディアストリームの伝送を制御し、メディアストリームのメディア記述６２を取得するように適合されうる。伝送制御は、受信部により開始された制御メッセージによって、特にメディアソースからストリーム要素を求めるリクエスト６６によって、実行されうる。メディア記述は例えばメディアソースとして、ストリーム要素のうちの最初の要素６４を示す。制御部５０はさらに、送信部５２による最初のストリーム要素を求めるリクエスト６６の送信を、例えばメディアソースをホストするプラットフォームへ送信することを開始し、メディアストリームの伝送のためのセッション制御手続きを開始するように適合される。

図示されるメディアクライアントはまた、受信したストリームをユーザへレンダリングするためにスクリーン７０又はスピーカ７２のようなハードウェアを備える。このために、クライアントは、処理システム５６に実装されてもよい再生ロジック７４を有する。再生ロジック７４は受信部５４からストリーム要素６０を受信し、スクリーン７０又はスピーカ７２による再生のためにこれらをアンパックし復号する。制御部５０はまた、再生のために必要な場合に１つ以上の別のストリーム要素６０を要求し、メディア記述６２内の情報及び受信したストリーム要素の監視されたデータレートに基づいてメディアストリームの表現を選択し、個別の表現について送信部５２によるリクエスト６６を開始するように適合される。データレートの監視は例えばストリーム要素のサイズを検出し、これらの伝送時間を測定することによって実行されうる。ＡＨＳの場合に、特定のリクエスト６６は図の要素ラベルで示されるような特定のストリーム要素６０に対応する。

上記の方法の側面を実行するように適合されたメディアサーバ８０が図５に示される。これは、クライアント、例えば図４に関して記載されたクライアントからのストリーム要素を求めるリクエスト８６に応じて連続した複数のストリーム要素８４を有するメディアストリームの伝送を制御するための制御部８２を備える。メディアサーバ８０は、クライアントへ向けてストリーム要素８４を送信するための送信部８８と、受信部９０とを備える。送信部及び受信部は、無線伝送に適合されてもよいし、有線伝送に適合されてもよい。受信部９０は、ストリーム要素のうちの最初の要素９２を求めるリクエスト８６を受信するように適合され、このリクエスト８６は例えばＵＲＩのようなメディアソースとして最初の要素９２を示す。受信部９０はまた、例えばメディアストリームを伝送するネットワークの制御エンティティから、メディアストリームの伝送のためのセッション制御手続きの結果を受信し、これを制御部８２に転送するように適合される。

受信部９０は、ストリーム要素のうちの後続する要素９４を求める別のリクエストを受信するようにさらに適合される。別のリクエストは、後続する要素の別のメディアソースをさらに有しうる。ＡＨＳの場合に、特定のリクエスト８６は、図の要素ラベルによって示されるような特定のストリーム要素８４に対応する。

制御部８２は送信部８８及び受信部９０に結合され、成功したセッション制御手続きの結果に基づいて後続するストリーム要素９４の送信を制御するように適合される。例えば、セッション制御手続きの確認が受信されるならば送信が実行されてもよく、確認が取得されないならば送信が遮断されてもよい。また、制御部８２が、結果に基づいてストリーム要素の特定の表現への、例えば高解像度ビデオのセグメントへのアクセスを許可又は遮断するか、要求されたものとは異なる表現、例えば低品質表現を返すことも可能である。複数の別のオプションが考えられる。

メディアサーバ８０は典型的に、メモリ９８に格納された情報に基づいて、又は別の受信部１０６を介して又は高位のプロトコルレイヤから受信した情報に基づいて、伝送のためにストリーム要素８４を符号化するストリーム生成部８６も備える。移動体電話のカメラ又はマイクロフォンで記録されたコンテンツをストリーミングする場合にメディアサーバ自体がユーザ機器である場合もある。

メディアサーバ８０の実施形態では、送信部８８は、メディアストリームのメディア記述１００をクライアントへ送信するように適合される。メディア記述１００の伝送は、図示されないクライアントからのリクエストによっても開始されうる。メディア記述１００は、ストリーム要素のうちの最初の要素９２のためのメディアソースを示し、場合によっては後続するストリーム要素９４の別のメディアソースも示す。

この実施形態では、処理部１０２は、それぞれがメディアストリームの異なる表現を示す複数の表現記述と、場合によっては関連付けられたメディアソースの表示とを有する最初のメディア記述を例えばメモリ９８から取得するように適合されうる。処理部１０２は、伝送のためのメディア記述１００を特定するために、最初のメディア記述から表現記述のうちの少なくとも１つを削除するようにさらに適合されうる。処理部はまた、表現記述を、例えばクライアントによる選択を回避する値に変更しうる。ソース表示が存在するならば、例えば高品質ソースを低品質ソースに置き換えるために、これが削除又は変更されうる。オプションとして、関連付けられたソースを入手せずに表現の存在に関して受信部が通知されるように、処理部は表現記述を維持しつつ、単にメディアソースを削除してもよい。同様に、関連付けられたソースを有する表現記述を単に削除する代わりに、削除された表現の代わりにタグが含められてもよく、タグは少なくとも１つの別の表現が利用可能であることをクライアントへ示す。このように、サーバは、セッション制御手続きの前に使用されうる変更されたメディア記述を生成しうる。処理部１０２は処理システム１０４の一部であってもよい。

図５ａは、クライアントからのストリーム要素を求めるリクエストに応じて連続した複数のストリーム要素を有するメディアストリームの伝送を制御するメディアサーバにおける対応する方法を示す。本方法は、ストリーム要素のうちの最初の要素を求めるリクエストを受信するステップ（１１０）で始まる。リクエストは、例えばストリーム要素を識別するメディアソースとして、最初の要素を示す。リクエストに応じて、最初の要素がクライアントへ向けて送信される（１１２）。本方法の任意の時点で、メディアストリームの伝送のためのセッション制御手続きの結果がメディアサーバにより受信される（１１４）。メディアサーバがストリーム要素のうちの後続する要素を求める別のリクエストを受信した場合に（１１６）、セッション制御手続きの結果に基づいて後続する要素の送信を制御しうる（１１８）。

図６はメディアサーバ、例えば上述のサーバから連続した複数のストリーム要素を有するメディアストリームの伝送のためにメディアクライアントとのセッションを制御するための制御エンティティ２００を示す。制御エンティティは例えばＨＴＴＰ／ＳＩＰアダプタとして実装されうる。制御エンティティ２００は、メディアストリームの伝送のためのセッション制御手続きのシグナリングメッセージ２０４、例えばＳＩＰメッセージを受信するための受信部２０２を備える。メッセージは例えば上述のメディアクライアントによって開始され、別のネットワーク要素によって転送される。別のネットワーク要素はセッション制御手続きからセッション関連情報を取得してもよく、それ故セッションに関連する制御動作を実行又は開始できる。

制御部２０６はシグナリングを終了する。すなわち、これはシグナリングのエンドポイントである。従って、これはシグナリングメッセージ２０４を処理し、送信部２１０によるレスポンス２０８の送信を開始しうる。このために、制御部２０６は受信部２０２及び送信部２１０に結合される。制御部２０６はさらに、メディアストリームをセッション制御手続きのセッションに関連付けるように適合される。例えば、制御部２０６はメディアストリームを伝送するために既存のセッションを選択してもよく、場合によってはこの目的のためにセッションパラメータを変更してもよく、または制御部はメディアストリームのための新たなセッションを確立してもよい。メモリ２１２は、セッションについての情報を格納し、読み出すことを可能にする。制御部は制御エンティティ２００の処理システム２１４内に実装されてもよい。

セッション制御手続きの結果に基づいて、制御部２０６は送信部２１８による命令２１６の送信を開始する。命令２１６は、セッションの制御ルールに従ってストリーム要素のうちの後続の要素の伝送の制御を開始し、メディアストリームを送信するメディアサーバへ、又はセッションのポリシー行使ポイントへ送信されうる。送信部２１８に対応する受信部２２０は、例えば命令２１６に対する確認２２２を受信することを可能にする。制御エンティティはまた、受信部２２０を介して情報を取得してもよく、この情報はクライアントへ送信されうるか、セッションパラメータ、例えばメディア記述又はメディアソースを規定するのに用いられうる。送信部２１８及び受信部２２０は、送信部２１０及び受信部２０２と同一であってもよいし、異なるエンティティであってもよく、これらは、場合によっては受信側に依存して異なるプロトコル、例えばＨＴＴＰを用いてもよい。送信部２１８及び受信部２２０はまた、命令が同一のプラットフォームで実装されるエンティティへ送信されるならば、装置の内部インタフェースに対応してもよい。

メディアサーバから連続した複数のストリーム要素を有するメディアストリームの伝送のためのメディアクライアントとのセッション制御手続きを実行するための制御エンティティにおける方法は、メディアストリームの伝送のためのセッション制御手続きのシグナリングを受信するステップ（２４０）で始まる。制御エンティティはシグナリングを終了し（２４２）、メディアストリームをセッション制御手続きにおけるセッションに関連付ける。セッション制御手続きに基づいて、制御エンティティは、セッションの制御ルールに従ってストリーム要素のうちの１つ以上の後続のストリームの伝送制御を開始又は変更する命令を送信する（２４４）。

サーバからクライアントへメディア記述を転送するためのメディアプロキシ２５０が図７に説明される。一般に、メディアプロキシはクライアントとサーバとの間の複数の他のメッセージ、リクエスト及びレスポンス、例えばストリーム要素及びストリーム要素を求めるリクエストも転送する。メディアプロキシ２５０は、複数の表現記述を有するメディア記述２５４をサーバから受信するための受信部２５２を備える。各表現記述はメディアストリームの異なる表現を示す。この例では、メディア記述２５４は、各表現について関連付けられたソースＳ１〜Ｓ３を有するメディアストリームの３つの表現Ｒ１〜Ｒ３の記述を有する。表現記述Ｒ４について示されるような、メディアソースを有しない表現の記述をメディア記述が有することも可能である。この場合に、クライアントは、表現の存在に関して通知されるが、ソースを取得する前に、例えばメディアストリームのセッションとの関連付けを行う別のステップを実行する必要がある。

処理システム２５８の一部であってもよい処理部２５６はメディア記述２５４から表現記述及び／又は関連付けられたソースの少なくとも１つを削除又は変更することによってメディア記述を変更するように適合される。この例では、例えばクライアントがアタッチされる無線ネットワークが、要求されるデータレートをサポートしないならば、関連付けられたソースＳ２と一緒に表現Ｒ２の記述が削除される。表現Ｒ３について、例えば必要なサービス品質を保証するためにメディアストリームに事前のセッションセットアップが必要ならば、又は表現のために請求が実行されるならば、ソースＳ３だけが削除される。例えばベストエフォートベアラを用いて再生が開始可能にするために、最初のソースがクライアントに利用可能であるように、ソースＳ１を有する表現Ｒ１はメディア記述に残る。メモリ２６０は、メディア記述を変更するために必要なデータを格納し、読み出すことを可能にする。

送信部２６２は、変更されたメディア記述２６４をクライアントへ向けて送信する。一般に、逆方向の対応する伝送を可能にするために送信部２６２に対して対応する受信部２６６が存在し、受信部２５２に対して送信部２６８が存在する。両方の送信部の機能が同じ物理装置によって実行されることが可能である。受信部についても同じことが当てはまる。

処理部２５６について記載されたメディア記述の変更のための処理はまた、他のエンティティ、例えばメディアサーバでも実行されうる。

サーバからクライアントへメディア記述を転送するためのメディアプロキシにおける方法は、メディア記述を受信するステップ（２８０）を有する。メディア記述はサーバから受信され、それぞれがメディアストリームの異なる表現を示す複数の表現記述を有する。メディアプロキシは、表現記述のうちの少なくとも１つと、当該少なくとも１つの表現記述のメディアソースとをメディア記述から削除又は変更することによってメディア記述を変更する（２８２）。最後に、変更されたメディア記述がクライアントへ向けて送信される（２８４）。

メディアクライアント、メディアサーバ、制御エンティティ及びメディアプロキシを含むグループのうちの任意のエンティティだけでなく、個別のエンティティで実行される各方法は、説明される任意の実施形態で用いられてもよく、それ故、各エンティティに関する方法の実施形態のこれらの側面を実施するように適合されうる。

提案される方法は、例えばアダプティブＨＴＴＰストリーミングについてのＩＭＳベースのＱｏＳ予約に用いられうる。この場合に、これは、ＳＩＰベースの制御シグナリングを有するアダプティブＨＴＴＰストリーミングを、ＩＭＳ制御の基盤と統合するコンセプトを特定し、ＱｏＳ、請求、認証などのＩＭＳ固有の機能をアダプティブＨＴＴＰストリーミングで可能にする。提案される統合は、ＩＭＳ非対応装置へのＡＨＳ後方互換性、高速サービスセットアップ及びサービス差別化を可能にする。統合はＩＭＳ制御情報、例えばＳＩＰ ＵＲＩ（ユニフォームリソース識別子）をＭＰＤに含めるというアイデアに基づく。

以下では、上記の一般的なコンセプトの一部を採用する実施形態の、より詳細な技術説明が、ＩＭＳ制御のＡＭＳの観点でなされる。クライアントが任意の手段、例えばＨＴＭＬ内のリンクとして、又はメッセージ内のリンクとして、メディアプレゼンテーション記述（ＭＰＤ）ファイルのＵＲＬを取得していると想定する。図８は影響するエンティティ、例えばノードの順次相互作用を説明する。

メッセージフローに関与するエンティティは、メディアクライアントの一例としてのユーザ機器（ＵＥ）、例えば移動体電話機と、例えばＵＥのモビリティを可能にする無線アクセスネットワークを有する移動体電話システムのコアネットワークでありうるＩＰマルチメディアコアネットワークサブシステム（ＩＭ ＣＮサブシステム）である。セッション制御機能（ＳＣＦ）は、サービスロジックと、このようなロジックの実行をサポートするために必要な機能とを提供し、これは例えばサービスへのアクセス又はメディア機能の選択を許可又は拒否するためにユーザのサービス加入契約をチェックするセッション開始中及びセッション変更中のサービス認可を含みうる。このような機能及びこれらの起動のルールは事業者の実装に従う。制御エンティティの一例としてのＨＴＴＰ／ＳＩＰアダプタはＳＩＰシグナリングを終了し、メディアサーバの一例としてメディアのストリーミングを実行するＨＴＴＰサーバと通信する。

説明される手続きの多くの実施形態では、ＩＭ ＣＮサブシステム及びＳＣＦは標準ＩＭＳコンポーネントでありえ、よって、メディア伝送を制御するためのルール及び要素を実装することによってのみ影響される。例えばＭＰＤ及び様々なメディア品質が様々なサーバを介して配布される場合に、２つ以上のＨＴＴＰサーバがメディアストリーミングに用いられてもよい。さらに、コンテンツ配布ネットワーク（ＣＤＮ）がＨＴＴＰサーバの代わりに用いられてもよい。ＨＴＴＰ／ＳＩＰアダプタ及びＨＴＴＰサーバは、同じハードウェア上のコンポーネントとして実装されてもよいし、単一のソフトウェア内で実装されさえしてもよい。この場合に、２つのコンポーネント間のインタフェースは図８に示される例とは異なっていてもよく、すなわちＨＴＴＰの基づかなくてもよい。その代わりに、インタフェースはＡＰＩ（アプリケーションプログラミングインタフェース）呼び出しに基づいてもよい。

図８の信号フローでは、ＵＥはＭＰＤ ＵＲＬ、すなわちＭＰＤを提供するＨＴＴＰサーバへＨＴＴＰリクエスト１０ａを実行する。ＨＴＴＰサーバは、すべての品質レベルについての、又は１つの実施形態としてネットワーク内のベストエフォート伝送に適すると考えられる品質レベルだけについての表現記述を含むＭＰＤで応答する。ＨＴＴＰレスポンス１０ｂにおいて返されるＭＰＤは、ＳＩＰ対応端末がＡＨＳセッションのためのセッションセットアップを要求することを可能にするＳＩＰ ＵＲＩを伴う。ＳＩＰ ＵＲＩは、例えば標準化された新たなＭＰＤ属性として含まれてもよく、既存のＭＰＤ要素内にパッケージされてもよく、ＨＴＴＰリクエストへのレスポンス１０ｂの一部、例えば複数のＨＴＴＰ又は他の要素を有するマルチパートレスポンスの一部であってもよい。

これらのステップに対していくつかのオプションが存在する。
・リクエスト１０ａは、ネットワーク内、例えばＩＭ ＣＮサブシステム内に位置しうるアプリケーション層ゲートウェイ（ＡＬＧ）によって代理されうる。ＡＬＧは例えばメディアプロキシのものであり、ＭＰＤファイルを求めるリクエストをスキャンし、表現を削除し、セッションのためのＱｏＳを要求するＳＩＰ ＵＲＩを追加しうる。
・ＭＰＤにＳＩＰ ＵＲＩを含める代わりに、これは別個の要素として含まれてもよく、レスポンス１０ｂのマルチパートメッセージで輸送されてもよい。
・ＭＰＤを含むレスポンス１０ｂはまた、後続のＳＩＰ ＩＮＶＩＴＥメッセージ１についてＳＤＰファイルを生成するためにＵＥが利用可能である追加の情報を含んでもよい。例えば、これはＳＤＰメディア部分又はＵＥがテンプレートの可変部分の完了の後に使用しうるＳＤＰテンプレートを構築するために用いられうるメディアに関する追加の情報であってもよい。このように、ＵＥは、ＳＤＰメディア部分を構築するために格納された情報及びルーチンを使用するか、ポート又はメディア形式のような記入されるべき特定の情報要素を含むリクエストに対するテンプレートを受信しうる。
・ＳＩＰ ＵＲＩをＭＰＤに含める代わりに、例えばリダイレクトによってＳＩＰ ＵＲＩに解決されうる別のタイプのＵＲＩ（例えば、ＨＴＴＰ ＵＲＬ）が含まれてもよい。

ステップ１０ｃで、ＩＭＳ対応ＵＥとＩＭＳ非対応ＵＥとの両方がＡＨＳセッションを開始する。これは、高速ストリーム起動時間を可能にし、例えばＩＭ ＣＮサブシステムへのデフォルトのベアラで、ベストエフォート接続を用いて行われうる。このように、後方互換性も可能であり、ＩＭＳ非対応ＵＥは提供されるＳＩＰ ＵＲＩを無視しうる。

ＩＭＳ対応である装置は、ＡＨＳセッション起動と並行して、ＳＩＰ ＩＮＶＩＴＥメッセージ１１〜１３をＳＩＰ／ＨＴＴＰアダプタへ送信する。ＩＮＶＩＴＥは以前に通信したＳＩＰ ＵＲＩを宛先とする。ＩＮＶＩＴＥメッセージはＳＤＰを含まないか、クライアントによって生成されたＳＤＰファイルを含むか、クライアントがレスポンス１０ｂにおけるＭＰＤアンサとともに受信していたかもしれない記入済みのＳＤＰテンプレートを含むかのいずれかである。

ＳＩＰ／ＨＴＴＰアダプタ及びＨＴＴＰサーバが２つの別個のエンティティであるならば、ＳＩＰ／ＨＴＴＰアダプタは、元のＭＰＤへのＵＲＬ及び／又はレスポンス１５で返された元のＭＰＤ自体を取得するためにＨＴＴＰサーバへＨＴＴＰリクエスト１４、例えばＰＯＳＴリクエスト又はＧＥＴリクエストを発行する。「元の」という用語は、レスポンス１０ｂに含まれるＭＰＤが表現の一部を削除されうるが、このＭＰＤがサーバで利用可能なメディア表現記述のフィルタされていないリストを有しうることを意味する。元のＭＰＤの情報に起因して、ＳＩＰ／ＨＴＴＰアダプタは、ステップ１０ｃで既に進行中のＡＨＳセッションに関する情報を含むＳＤＰを含むＳＩｐ ２００ ＯＫメッセージを発行できる。ＳＩＰ ２００ ＯＫメッセージはステップ１７、１８でＵＥへ転送される。例えば、ＵＥ、すなわちクライアントが様々なメディア品質へのアクセスを入手する場合に、ＳＩＰ ２００ ＯＫメッセージは、レスポンス１０ｂに含まれるＭＰＤと比較して１つ以上の追加のメディア表現を有しうる更新されたＭＰＤ ＵＲＩを含みうる。更新されたＭＰＤは元のＭＰＤであるか、例えばＳＩＰ／ＨＴＴＰアダプタ又はプロキシによって編集されたバージョンの何れかでありうる。

データの伝送中に、ＩＭ ＣＮは、オプションとしてベアラ更新を含むメディアセッションのための特定されたポリシー、例えばＱｏＳの行使を開始する。ＱｏＳ予約及びポリシー行使は、ポリシー・課金制御アーキテクチャという名称の３ＧＰＰ ＴＳ２３．２０３で規定された標準３ＧＰＰメカニズムを使用しうる。例えば、ＭＰＤからの情報やクライアントＩＰアドレス、ポートなどを使用して、対応するポリシー・課金制御（ＰＣＣ）ルールが作成されうる。ＰＣＣルールは、ゲートウェイのようなポリシー行使ポイントが、ＨＴＴＰストリーミングセッションに属するパケットを識別し優先することを可能にする。帯域幅合意を超えるパケットは輻輳を示すようにマークされてもよく、破棄されてもよい。例えばポリシー行使ポイントで詳細なパケット調査により識別されうるサーバに関係することによって、ＩＰアドレス又はポート以外の要素を考慮するＰＣＣルールは、ＨＴＴＰサーバがキャッシュ又は複数のロケーションからコンテンツがストリーミングされうるＣＤＮによって置き換わる場合に、説明されたメカニズムの使用を可能にする。

メディアストリーミングセッションのためのポリシー行使及びＱｏＳ提供の結果として、ストリーミングクライアントは、セッションに固有であるネットワークの動作状況、例えば観察されるダウンロード速度を観察する。従って、クライアントは、対応するシグナリングを必要としない伝送監視の既存のＡＨＳメカニズムを用いてネットワークにより提供される伝送状況に適合されうる。

ＵＥがメッセージ２００ ＯＫ １８を受信し、確立したＱｏＳを認識した後、これはオプションとしてＨＴＴＰリクエスト１９ａ及びレスポンス１９ｂでＭＰＤの更新についてＨＴＴＰサーバをチェックしてもよい。ＨＴＴＰサーバは、メッセージ１４で受信された情報に基づいて、又はメディアストリームのセッションとの関連付けの別の確認によって、更新を提供しうる。レスポンス１０ｂが高品質メディア表現を含まない場合に、ＵＥはこの段階で利用可能なＱｏＳに従ってすべての表現を有する更新されたＭＰＤを受信する。

ステップ２０で、ＡＨＳの適合アルゴリズムに基づいて、ＵＥは、任意の新たに利用可能な表現、例えば、より高い品質レベルに従って、要求されたメディア品質を適合しうる。このように、ネットワーク事業者は異なるユーザへのサービス差別化と、個別のメディア品質への要求されたＱｏＳとの両方を提供しうる。

ＩＭＳ非対応装置について、ステップ２０はメディア品質の更新なしに、ステップ１０ｃの後すぐに実行される。

手続きの別のオプションの機能及び実施形態が可能である。
・レスポンス１０ｂに応じて、帯域幅属性を含むが、＜InitialisationSegmentURL＞または＜sourceURL＞要素、すなわちメディアへのリンクのようなメディアソースを含まない、例えば特定のタグを通じて、又はより多くの表現を通じて、より多くの利用可能な品質レベルの表示が与えられてもよい。
・セッションについてのＳＤＰオファーは、ＵＥによって、又はＳＩＰ／ＨＴＴＰアダプタによって生成されうる。要求された情報、例えば送信者ＩＰアドレス及び受信者ＩＰアドレス、メディアトランスポートフォーマット及びポート、必要な帯域幅は、通信パス及びＭＰＤを通じて提供される。
・メッセージ１０ｂで、例えばサーバ又はプロキシによって、ＭＰＤからよりよい品質表現を削除することはオプションである。表現が削除されないならば、提案される手続きはサービス品質予約を可能にする。他の場合に、これは、所定のパッケージを予約したユーザ又はＩＭＳで提供される請求を介してこれを取得できるユーザの識別情報を有するクライアントについて、サービス差別化を可能にする。
・ＭＰＤで提供されるＵＲＩは、ＭＰＤ内の情報なしに容易にアクセスすることができないように、より高い品質層についてのＵＲＩを推測しづらくする個別の方法で、例えばユーザに個別化されて生成されうる。
・一部の場合に、ＩＰ ５タプル（IP-5-tuples）に基づくポリシー行使ポイントの単純なフィルタ、すなわちソースアドレス、ソースポート、宛先アドレス、宛先ポート及びプロトコル識別情報を含むグループからの少なくとも１つの要素に基づいてパケットを許可又は制限するフィルタは、ＱｏＳ行使、例えば、ＣＤＮからのコンテンツのストリーミングに適さない。このような場合に、ＰＣＣルールは他の情報を含んでもよい。例えば、ＨＴＴＰストリーミングセッションからパケットを識別するためのＱｏＳ行使ポイントにおける詳細なパケットの調査の間に用いられうるヘッダのようなＨＴＴＰ固有情報が含まれてもよい。
・ＨＴＴＰサーバは、成功したＳＩＰ ＩＮＶＩＴＥ手続きの表示を受信した後に、所定のメディア品質、すなわち特定の表現のストリームセグメントへのアクセスだけを許可してもよい。これをチェックするために、ＨＴＴＰサーバ、ＳＩＰ／ＨＴＴＰアダプタ及び／又はＩＭ ＣＮの間で追加の通信が存在してもよい。例えば、ＳＩＰ／ＨＴＴＰアダプタ又はＨＴＴＰサーバは、ＳＩＰ ＩＮＶＩＴＥの間にＵＥのＩＰアドレスを登録し、ＧＥＴリクエストのソースＩＰが登録済みのＵＥに属するならばステップ１０ａ、１９ａのようにＨＴＴＰ ＧＥＴリクエストをチェックしてもよい。

特定の実施形態に依存する利点は、リソース予約メカニズムの利用可能性から利益を受け、ＱｏＳ予約、制御、ＡＨＳに関連する能力を含む。集中型のソリューションはＩＭＳクライアントと非ＩＭＳクライアントとの両方をサポートできる。実施形態の利点はまた、以下を含みうる。
・ＩＭＳ ＱｏＳ確立のための遅延の場合でさえも、ストリーミングの高速セットアップ
・既存の標準ＡＨＳメカニズムへの後方互換性
・ＩＭＳを介したＱｏＳが用いられる場合に、よりよい品質を利用可能にすることによりサービス差別化対応
・ベストエフォート使用にどの品質レベルが利用可能であるべきかを決定を事業者の制御下に置く。これにより、現在の状況に起因するネットワーク使用の動的制御が可能になる。

上記の実施形態は本発明の目的を見事に達成する。しかしながら、特許請求の範囲のみによって限定される本発明の範囲から逸脱せずに、当業者が逸脱を行いうることが理解されるだろう。

Claims (17)

1. アダプティブＨＴＴＰストリーミングを利用し、連続した複数のＨＴＴＰストリーム要素（８４）を有するメディアストリームの伝送を制御するためのユーザ機器における方法であって、
   ‐前記複数のＨＴＴＰストリーム要素のうちの最初の要素（９２）を示す、前記メディアストリームのメディア記述（１００）を取得するステップ（３２）と、
   ‐前記最初の要素（９２）を求めるリクエストを送信するステップ（３４）と、
   ‐セッションの確立又はセッションの変更を開始するステップ（３６）とを有し、
   前記メディアストリームは前記メディアストリームの前記伝送を制御するための前記セッションに関連しており、
   前記最初の要素（９２）を求める前記リクエストを送信する前記ステップ（３４）は、前記セッションの前記確立又は前記セッションの前記変更の結論を待たずに実行されることを特徴とする方法。
2. 前記セッションの前記確立又は前記セッションの前記変更は、
   ‐前記メディアストリームに関連付けられたセッション制御のためのソースを示すリソースロケータを取得するステップと、
   ‐セッション制御のための前記ソースとともに前記セッションの前記確立又は前記セッションの前記変更を開始するためのリクエストを送信するステップとを含むことを特徴とする請求項１に記載の方法。
3. 前記メディア記述（１００）は、確立又は変更される前記セッションにおけるセッションパラメータを特定するための少なくとも１つの情報要素を含むか、当該少なくとも１つの情報要素に関連付けられることを特徴とする請求項１又は２に記載の方法。
4. 前記セッションの前記確立又は前記セッションの前記変更は、
   ‐前記セッションの前記確立又は前記セッションの前記変更の結論を受信するステップと、
   ‐前記セッションの前記確立又は前記セッションの前記変更の前記結論の受信に応じて、前記複数のＨＴＴＰストリーム要素のうちの後続の要素（９４）を求めるリクエストを送信するステップとを含むことを特徴とする請求項１乃至３の何れか１項に記載の方法。
5. セッション制御レスポンスは、前記セッションを特定するパラメータと、メディアソースの表示と、メディア記述とのうちの少なくとも１つを示すことを特徴とする請求項４に記載の方法。
6. 前記セッションの前記確立又は前記セッションの前記変更はリソース予約を含み、前記セッションを特定する前記パラメータは許可されたサービス品質を示すことを特徴とする請求項５に記載の方法。
7. 前記後続の要素のためのメディアソースは複数のメディアソースから選択され、前記複数のメディアソースの各メディアソースは前記セッションを特定する異なるパラメータに関連付けられることを特徴とする請求項５又は６に記載の方法。
8. 前記セッションを特定する前記パラメータは、前記後続の要素（９４）を求める前記リクエストに含まれることを特徴とする請求項５乃至７の何れか１項に記載の方法。
9. 前記メディア記述は複数の表現記述を含み、各表現記述は前記メディアストリームの異なる表現と、関連付けられたメディアソースとを示し、前記関連付けられたメディアソースの少なくとも１つは前記メディア記述に基づいて選択され、前記最初の要素（９２）を求める前記リクエストに含まれるか、前記後続の要素（９４）を求める前記リクエストに含まれることを特徴とする請求項４乃至８の何れか１項に記載の方法。
10. メディアソースとセッション制御のためのソースとのうちの少なくとも１つは前記セッションに固有であることを特徴とする請求項１乃至９の何れか１項に記載の方法。
11. 前記最初の要素（９２）を求める前記リクエストは前記セッションの前記確立又は前記セッションの前記変更の前記開始の前又は前記開始と同時に送信されることを特徴とする請求項１乃至１０の何れか１項に記載の方法。
12. 連続した複数のＨＴＴＰストリーム要素（８４）を有するメディアストリームの伝送を制御するための方法であって、
    ‐前記ユーザ機器（４８）によって実行される請求項１乃至１１の何れか１項に記載の方法と、
    ‐制御エンティティ（２４）によって、確立又は変更される前記セッションに前記メディアストリームを関連付けるステップ（３８）と、
    ‐ポリシー行使ポイントによって、前記セッションの制御ルールに従って前記複数のＨＴＴＰストリーム要素のうちの後続の要素（９４）の前記伝送を制御するステップ（４０）とを有することを特徴とする方法。
13. 制御部（５０）と、送信部（５２）と、受信部（５４）とを備え、前記制御部（５０）は前記送信部（５２）及び前記受信部（５４）に結合されているユーザ機器（４８）であって、
    前記制御部（５０）は、アダプティブＨＴＴＰストリーミングを利用し、連続した複数のＨＴＴＰストリーム要素（６０）を有するメディアストリームの前記受信部（５４）への伝送を制御するように適合され、
    前記制御部（５０）は、前記複数のＨＴＴＰストリーム要素（６０）のうちの最初の要素（６４）を示す、前記メディアストリームのメディア記述（６２）を取得するようにさらに適合され、
    前記制御部（５０）は、前記送信部（５２）による前記最初の要素（６４）を求めるリクエスト（６６）の送信を開始し、セッションの確立又はセッションの変更を開始するように適合され、前記メディアストリームは前記メディアストリームの前記伝送を制御するための前記セッションに関連しており、
    前記送信部（５２）は、前記セッションの前記確立又は前記セッションの前記変更の結論を待たずに前記最初の要素（９２）を求める前記リクエストを送信するように適合されることを特徴とするユーザ機器。
14. 前記ユーザ機器は、請求項１乃至１１の何れか１項に記載の方法を実行するように適合されていることを特徴とする請求項１３に記載のユーザ機器。
15. メディアサーバからの、アダプティブＨＴＴＰストリーミングを利用し、連続した複数のＨＴＴＰストリーム要素を有するメディアストリームの伝送を制御するためのユーザ機器とのセッションの確立又はセッションの変更のための制御エンティティ（２００）であって、
    前記メディアストリームの前記伝送を制御するためのセッションの確立又はセッションの変更を求めるリクエストを受信するための受信部（２０２）と、
    前記リクエストを終了するための制御部（２０６）であって、前記受信部（２０２）に結合されており、確立又は変更される前記セッションに前記メディアストリームを関連付ける（３８）ように適合された制御部（２０６）と、
    ポリシー行使ポイントへ命令を送信するために前記制御部（２０６）に結合されている送信部（２１８）とを備え、
    前記命令は、前記セッションの制御ルールに従って前記複数のＨＴＴＰストリーム要素のうちの後続の要素の前記伝送を制御する命令であり、
    前記ユーザ機器は、前記セッションの前記確立又は前記セッションの前記変更の結論を待たずに、前記複数のＨＴＴＰストリーム要素のうちの最初の要素（９２）を求めるリクエストを送信することを特徴とする制御エンティティ。
16. 前記制御エンティティは、請求項１乃至１１の何れか１項に記載の方法を実行するように適合されることを特徴とする請求項１５に記載の制御エンティティ。
17. メディアサーバからの、アダプティブＨＴＴＰストリーミングを利用し、連続した複数のＨＴＴＰストリーム要素を有するメディアストリームの伝送を制御するために、ユーザ機器とのセッションの確立又はセッションの変更を実行するための制御エンティティ（２００）における方法であって、
    前記メディアストリームの前記伝送を制御するためのセッションの確立又はセッションの変更を求めるリクエストを受信するステップ（２４０）と、
    前記リクエストを終了し（２４２）、確立又は変更される前記セッションに前記メディアストリームを関連付けるステップと、
    ポリシー行使ポイントに命令を送信するステップ（２４４）とを有し、
    前記命令は、前記セッションの制御ルールに従って前記複数のＨＴＴＰストリーム要素のうちの後続の要素の前記伝送を制御する命令であり、
    前記ユーザ機器は、前記セッションの前記確立又は前記セッションの前記変更の結論を待たずに、前記複数のＨＴＴＰストリーム要素のうちの最初の要素（９２）を求めるリクエストを送信することを特徴とする方法。

Images