JP5961174B2 - メディア記述配信のための方法およびデバイス - Google Patents

Description

本発明は、メディア記述配信のための方法に関する。本発明を実施するデバイスおよびソフトウェアプログラムについても記述する。

インターネットや移動電話網のような通信網の重要な適用分野として、サーバからクライアントへのメディア配信がある。メディアとは、例えば音声および動画であってもよい。

ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ベースのネットワークにおけるメディア配信は、さまざまなトランスポートプロトコルを使用する可能性がある。通常は、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）上のＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）が、リアルタイムストリーミングおよびパケットベースのストリーミングに用いられるか、あるいは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）上のＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）が、大半は後で利用するためだがライブストリーミング用としても、ファイル全体のダウンロードに用いられるか、そのいずれかである。ＲＴＰでは、クライアントによって測定される利用可能なビットレートへの動的な適応が可能である。ＲＴＰおよび関連の制御プロトコルであるＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）の欠点は、それに特化した、かつ一層複雑な、サーバソフトウェアが必要だということであり、一方でＨＴＴＰは、広く活用されていて、かつ安価な、ＨＴＴＰサーバソフトウェアを利用することができる。最近策定されたＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ ＨＴＴＰ Ｓｔｒｅａｍｉｎｇ）は、両方の手法の利点を組み合わせることを目指している。ＤＡＳＨは、３ＧＰＰ（第三世代パートナシッププロジェクト）技術仕様（ＴＳ）２６．２３４ｖ９．４．０ Ｔｒａｎｓｐａｒｅｎｔ ｅｎｄ−ｔｏ−ｅｎｄ Ｐａｃｋｅｔ−Ｓｗｉｔｃｈｅｄ Ｓｔｒｅａｍｉｎｇ Ｓｅｒｖｉｃｅ（ＰＳＳ）の中で標準化されており、ＯＩＰＦ（Ｏｐｅｎ ＩＰＴＶ Ｆｏｒｕｍ）やＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）でも採用され、少しずつ適用が拡大されている。

ＤＡＳＨでは、コンテンツ（本明細書ではメディアとも言う）は一般に、多様なビットレートに対応する、多様なバージョンで符号化されている。例えば、コンテンツが、動画トラックと音声トラックとを備えた動画である場合、動画トラックは、それぞれが異なるビットレートを持つ３つのバージョンで符号化され、音声トラックは、高品質ステレオとモノバージョンとで符号化されることがあるだろう。各バージョンは、さらに、数秒間の持続時間を持つセグメントに分割される。例えば、動画バージョンは、それぞれが１０秒間の持続時間を持つ多くの連続したセグメントに分割することができる。それらのセグメントは、ＭＰＥＧ−４ファイルフォーマットに従って、あるいはＭＰＥＧ−２トランスポートストリームフォーマットに従って、フォーマットされてもよい。

動画トラックおよび音声トラックの実際の送信は、クライアントがセグメントの逐次ダウンロードを開始することによって行われる。この手順の中でクライアントは、標準的なＨＴＴＰ要求を用いて１つのセグメントをダウンロードし、それをアンパックし、復号し、レンダリングし、次いで、その次のセグメントについても同じことを行い、以下、その他のセグメントについても同様に行う。クライアントは、利用可能な品質バージョンについての知識や、メディア記述、すなわち、いわゆるＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）による経時的なセグメント分割についての知識を有している。３ＧＰＰ ＴＳ２６．２３４、ＯＩＰＦ、およびＭＰＥＧの中に定義されているＭＰＤフォーマットは、メディアを記述するための適切な情報と属性とを含んだ、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で符号化されたファイルである。ＭＰＤは、ＤＡＳＨベースのメディア配信を開始するためにクライアントへ送信される最初のリソースである。言い換えれば、ＭＰＤの目的は、或る特定のコンテンツのメディアセグメントをフェッチして再生するために、クライアントに位置情報およびタイミング情報を与えることである。

ＭＰＤは、Ｐｅｒｉｏｄ（時間枠）、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ（表現）、およびＳｅｇｍｅｎｔ（セグメント）という、３つの主な要素で構成されている。図１１に示すように、「時間枠」の要素は、ＭＰＤの最も外側の部分である。時間枠は、典型的には、連続して再生されるメディアの大きい断片である。時間枠の内側では、コンテンツについて複数の異なる符号化が行われることがある。時間枠に入っている選択肢はそれぞれ、「表現」と呼ばれる。これらの選択的な「表現」は、例えば、異なるビットレート、フレームレートあるいは動画解像度を有することがある。最後に、それぞれの「表現」は、一連のセグメントをメディアのリンクによって、例えばＨＴＴＰ ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）によって、記述する。これらのＵＲＬは、（プレイリストに似た）「表現」の中に明示的に記述されるかまたはテンプレート構造を通して記述され、それによってクライアントは、表現の各セグメントについての有効なＵＲＬを導き出すことができる。コンテンツのプレイリストまたは広告挿入の機能性は、異なるコンテンツの時間枠をつなぐことによって、容易に達成することができる。

各セグメントは、送信用として用いられているネットワークの現行の運用条件の下で利用可能な最大速度でダウンロードされ、クライアントは、自分が経験しているダウンロード速度を監視する。経験しているダウンロード速度に基づいて、クライアントは、利用可能な品質バージョンのうちで最も適切なものを選択する。セグメント毎に、これは異なるバージョンであってもよく、クライアントは、現在の運用条件に応じて異なる品質をダウンロードすることができ、それゆえ、属性「適応型」ＨＴＴＰストリーミングが行われる。図１は、この原則を図示したものであり、コンテンツアイテムの適応型ＨＴＴＰストリーミングについてのさまざまなメディア表現を再生時間の関数として示している。図１の３つの表現、すなわち、「表現１」、「表現２」および「表現３」は、それぞれ、コンテンツアイテム、すなわちストリーム、の高ビットレート表現、中ビットレート表現、低ビットレート表現、に対応してもよい。表現と表現との間のスムーズな切り換えが可能であるように、さまざまな表現のストリームセグメント（１つのセグメントを「Ｓｅｇ．」と略すことがある）についての再生時間の開始と終了とは一致する。図１の縦軸は、さまざまなストリーム表現のデータサイズ、例えば、それらのビットレートを示す。クライアントの実装によっては、ストリームを視聴する時に品質の過度の変動を避けるために、例えばヒステリシスを含めて、表現と表現との間の切換えのための選択手順を強化することが可能である。

ＤＡＳＨセッションの進行の過程で、ＨＴＴＰサーバにおいてＭＰＤが更新されることがある。特に、ライブストリーミングの場合、ＭＰＤは、通常、例えば、他のコンテンツアイテム、例えば広告、をメディア表現に追加するために、定期的に更新される。具体的には、「時間枠」、「表現」、「セグメント」のうちの少なくとも１つが変更されて、ＭＰＤが更新されることがある。例えば、更新されたＭＰＤでは、以前のＭＰＤには含まれていなかった（今後レンダリングされることになる）新規／追加セグメントが含まれていたり、クライアントによってすでにレンダリングされたはずの古いメディアセグメントが削除されていたりすることがある。また、更新によって、利用可能なメディア品質の数、例えばメディアのビットレートが修正されることもある。

更新されたＭＰＤを入手するには、クライアントは、ＨＴＴＰ要求をＨＴＴＰサーバに送信し、ＨＴＴＰ応答によって現行のＭＰＤを入手する必要がある。ＭＰＤの更新について適切に情報を得るため、ＵＥは、ＨＴＴＰ要求を頻繁にＨＴＴＰサーバに送信することがあり、すなわち、ＨＴＴＰ要求が、ＭＰＤの更新の頻度より高い頻度で送信されることがある。この場合、ＭＰＤは、すべてのＨＴＴＰ要求について更新されるのではないため、ＨＴＴＰサーバは、すでに以前にＵＥに配信済であるＭＰＤを含むＨＴＴＰ応答を使って、一度だけでなく二度以上応答することさえある。それゆえＵＥとＨＴＴＰサーバとの間のリソースを浪費する不要なＨＴＴＰ要求−応答が、何度も交換される。これは、伝送経路に移動通信網の無線リンクが含まれている場合に、特に有害である。

他方、ＵＥが、ＭＰＤ更新のためのＨＴＴＰ要求をあまり送信しない場合、すなわち、ＭＰＤ更新の頻度より低い頻度で送信する場合、ＵＥは、長い間、すなわち、ＭＰＤ更新と、更新されたＭＰＤを含む次のＨＴＴＰ応答との間の時間、ＭＰＤ更新を行わない可能性がある。その間に、ＵＥのバッファの中のメディアセグメントがなくなってしまう可能性があり、従って、メディア再生が中断される。

マルチメディア通信におけるもう１つの傾向は、マルチメディアセッションの開始と制御のためにＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ：ＩＰマルチメディアサブシステム）を利用することである。３ＧＰＰの中には、ＩＭＳ制御によるＲＴＰストリーミングのためだけではなく、ＩＭＳ制御によるＨＴＴＰプログレッシブダウンロードのためにも標準化されたソリューションが、３ＧＰＰ ＴＳ２６．２３７Ｖ９．３．０（２０１０−０６）の中に「ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ（ＩＭＳ）ｂａｓｅｄ Ｐａｃｋｅｔ Ｓｗｉｔｃｈ Ｓｔｒｅａｍｉｎｇ（ＰＳＳ）ａｎｄ Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ（ＭＢＭＳ）Ｕｓｅｒ Ｓｅｒｖｉｃｅ；Ｐｒｏｔｏｃｏｌｓ」という題名で定義されている。これらのソリューションは、課金、認証またはＱｏＳ（サービス品質）予約のような、ＩＭＳによって提供される標準化された機能によって恩恵を受ける。

図２は、３ＧＰＰ ＴＳ２６．２３７に定義されているＩＭＳ制御によるＨＴＴＰプログレッシブダウンロードの場合のさまざまなシグナリングのステップを示す図である。セッションは、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）情報を含んだＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ＩＮＶＩＴＥメッセージで開始される。ダウンロード用のＨＴＴＰ ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）が、ユーザ装置（ＵＥ）すなわちクライアントに、ＳＩＰ ２００ＯＫメッセージを介して配信される。加えて、ＨＴＴＰプログレッシブダウンロードセッションのためのＱｏＳ予約が行われてもよい。プログレッシブダウンロード自体は、ＵＥによってＨＴＴＰサーバに対するＨＴＴＰ ＧＥＴコマンドを使って開始され、ＨＴＴＰサーバは、その返信として、要求されたコンテンツファイルと共に応答する。詳細には、以下のステップが行われる。

１．ＵＥが、ＳＤＰオファーを含めてＳＩＰ ＩＮＶＩＴＥをＩＭ ＣＮサブシステムに送信することによって、プログレッシブダウンロードセッションを開始する。
２．ＩＭ ＣＮサブシステムが、ＳＩＰ ＩＮＶＩＴＥメッセージをＳＣＦに転送する。３．ＳＣＦが、要求されたコンテンツについてのユーザの権利を検証し、ＨＴＴＰ／ＳＩＰアダプタを選択し、そして、ＳＩＰ ＩＮＶＩＴＥメッセージをＨＴＴＰ／ＳＩＰアダプタに転送する。
４．ＨＴＴＰ／ＳＩＰアダプタが、ＨＴＴＰサーバを選択し、ＵＥのＩＰアドレスを含めて、ＨＴＴＰ ＰＯＳＴメッセージをＨＴＴＰサーバに送信する。
５．ＨＴＴＰサーバが、ＨＴＴＰ ２００ＯＫ応答を使ってＨＴＴＰ／ＳＩＰアダプタに応答する。
６．ＨＴＴＰ／ＳＩＰアダプタが、要求されたコンテンツファイルのダウンロードＵＲＬをＳＤＰ応答の中に含めて、ＳＩＰ ２００ＯＫ応答をＳＣＦに送信する。
７．ＳＣＦが、ＳＩＰ ２００ＯＫをＩＭ ＣＮサブシステムに転送する。
８．ＩＭ ＣＮサブシステムが、ＳＩＰ ２００ＯＫをＵＥに転送する。
９．ＵＥが、ＳＩＰ ２００ＯＫメッセージから取得されたＵＲＬにＨＴＴＰ要求を送信する。
１０．ＨＴＴＰサーバが、ＨＴＴＰ応答の中でコンテンツファイルをＵＥに配信する。

明らかに、３ＧＰＰ ＴＳ２６．２３７ｖ９．３．０に従ったＩＭＳ制御によるＨＴＴＰプログレッシブダウンロードは、コンテンツファイルの配信に適用されるが、ＭＰＤのようなメディアプレゼンテーションの配信には適用されない。

本発明の目的は、メディアストリームのメディア記述をクライアントへ提供するための改良された方法、対応するデバイス、コンピュータプログラム、およびシステムを提供することである。
第１の態様によれば、メディアストリームのメディア記述をクライアントに提供する方法が提供される。前記クライアントが、メディア記述配信サービスに加入させられる。前記メディア記述配信サービスは、メディア記述配信規則を有する。メディア記述配信の要求がメディアサーバへ送信され、前記メディアサーバからメディア記述が受信される。前記受信したメディア記述が前記メディア記述配信規則に適合していることが検証される。前記検証が肯定であった場合、前記クライアントに対する前記メディア記述の配信が開始される。

一実施形態によれば、前記方法は、前記クライアントを前記メディア記述配信サービスに加入させる前記ステップのための加入要求を受信するステップを備えてもよい。

別の実施形態によれば、前記加入要求は、前記クライアントのアドレスと、前記メディア記述配信サービスを示すもの（例えば、ＭＰＤ更新イベント）と、どのメディアを配信すべきかと、のうちの少なくとも１つを指定してもよい。

別の実施形態によれば、前記メディア記述の前記配信は、前記受信したメディア記述を前記クライアントへ送信することを含んでもよい。

別の実施形態によれば、前記メディア記述の前記配信は、前記クライアントが前記メディアサーバから前記メディア記述を取得できるようにする情報を前記クライアントへ送信することを含んでもよい。前記クライアントが前記メディア記述を取得できるようにするそのような情報の例は、メディア記述の識別子（例えば、メディア記述のユニフォームリソースインジケータ（ＵＲＩ））であってもよい。

別の実施形態によれば、前記メディア記述配信規則は、少なくとも１つの事前定義されたコンテンツ要件を指定してもよく、前記検証するステップにおいて、前記受信したメディア記述の内容が前記事前定義されたコンテンツ要件と比較される。説明のために、メディア記述配信規則の以下の例が提供されてもよい。これは、前記受信したメディア記述が空の場合、または、開始時刻を指定するだけであってメディアリンクを含まない場合、このメディア記述は前記クライアントへ配信されないというものである。

別の実施形態によれば、前記メディア記述配信規則は、少なくとも２つのメディア記述の関係に関わってもよく、前記検証するステップにおいて、前記受信したメディア記述は、前記少なくとも２つのメディア記述のうちの１つであってもよい。例えば、前記メディア記述配信管理デバイスにおいて格納される、マスターメディア記述があってもよい。前記受信したメディア記述は、前記受信したメディア記述が前記マスターメディア記述に適合するか否かを検証するために、前記格納されているマスターメディア記述と比較されてもよい。前記メディア記述配信規則は、前記マスターメディア記述に適合する受信したメディア記述だけを配信するように指定してもよい。以下の２つの実施形態において更なる例が説明される。

別の実施形態によれば、別のメディア記述が受信されてもよく、前記別のメディア記述は、前記少なくとも２つのメディア記述のうちの２番目のものであってもよい。

別の実施形態によれば、前記別のメディア記述は、前記メディア記述と比べて時間的に早くに受信されてもよく、前記メディア記述配信規則は、前記メディア記述が前記別のメディア記述の更新である場合にのみ前記メディア記述が送信されるということを指定してもよい。

別の実施形態によれば、前記別のメディア記述は、メディア記述配信の別の要求を前記メディアサーバに対して送信したことに応えて受信されてもよい。例えば、これは、プルベースの要求−応答メカニズムを介して１以上の（別の）メディア記述を受信するためであってもよい。或いは、１以上の（別の）メディア記述は、プッシュベースのメカニズムを介して受信されてもよい。すなわち、メディア記述は、各（別の）メディア記述を明示的に要求する必要無しに、前記メディア記述配信管理デバイスにおいて受信されるべく、前記メディアサーバからプッシュされる。

別の実施形態によれば、前記クライアントへ送信される、前記メディア記述と、前記クライアントが前記メディア記述を取得できるようにする前記情報と、のうちの少なくとも一方は、第１のトランスポートプロトコルに従って通信されてもよく、前記メディアサーバへ送信されるメディア記述配信の前記要求と、前記メディアサーバから受信される前記メディア記述と、のうちの少なくとも一方は、第２のトランスポートプロトコルに従って通信されてもよい。

別の実施形態によれば、メディア記述配信の前記別の要求と、前記メディアサーバから受信される前記別のメディア記述と、のうちの少なくとも一方は、前記第２のトランスポートプロトコルに従って通信されてもよい。

別の実施形態によれば、前記加入要求は、前記第１のトランスポートプロトコルに従って通信されてもよい。

別の実施形態によれば、前記第１のトランスポートプロトコルは、セッション開始プロトコル（ＳＩＰ）であってもよい。

別の実施形態によれば、前記第２のトランスポートプロトコルは、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）であってもよい。

第２の態様によれば、メディアストリームのメディア記述をクライアントに提供する方法が提供され、前記クライアントをメディア記述配信サービスに加入させる加入要求がメディア記述配信管理デバイスへ送信され、前記メディア記述が前記メディア記述配信管理デバイスから受信される。

第３の態様によれば、メディアストリームのメディア記述をクライアントに提供する方法が提供され、前記クライアントをメディア記述配信サービスに加入させる加入要求がメディア記述配信管理デバイスへ送信され、前記クライアントがメディアサーバから前記メディア記述を取得できるようにする情報が前記メディア記述配信管理デバイスから受信される。前記受信した情報に従い、前記メディア記述を取得する要求が前記メディアサーバへ送信され、前記メディア記述が前記メディアサーバから受信される。例えば、前記受信した情報は、取得すべき前記メディア記述の識別情報（例えば、ＭＰＤ ＵＲＩ）を含んでいてもよく、前記識別情報は、前記メディア記述を取得するために前記メディアサーバへ送信される前記要求の中に含めることができる。前記メディアサーバは、こうして、前記メディア識別子を特定し、これを前記クライアントへ送信することができる。

一実施形態によれば、前記加入要求は、前記クライアントのアドレスと、前記メディア記述配信サービスを示すものと、どのメディアを配信すべきかと、のうちの少なくとも１つを指定してもよい。

別の実施形態によれば、前記加入要求は、第１のトランスポートプロトコルに従って通信されてもよく、前記メディア記述を取得する前記要求と、前記メディアサーバから受信される前記メディア記述と、のうちの少なくとも一方は、第２のトランスポートプロトコルに従って通信されてもよい。

別の実施形態によれば、前記第１のトランスポートプロトコルは、セッション開始プロトコル（ＳＩＰ）であってもよい。

別の実施形態によれば、前記第２のトランスポートプロトコルは、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）であってもよい。

第４の態様によれば、前記第１の態様および／またはその各実施形態のいずれかに記載の方法の各ステップを実行するように構成されたメディア記述配信管理デバイスが提供される。

一実施形態によれば、前記メディア記述配信管理デバイスは、少なくとも１つの受信ユニットと、少なくとも１つの送信ユニットと、処理ユニットと、を備えてもよい。前記メディア記述配信管理デバイスは、典型的には、ストレージユニットを更に備える。

第５の態様によれば、前記第２または第３の態様および／またはその各実施形態のいずれかに記載の方法の各ステップを実行するように構成されたクライアントデバイスが提供される。

一実施形態によれば、前記クライアントデバイスは、少なくとも１つの受信ユニットと、少なくとも１つの送信ユニットと、処理ユニットと、を備えてもよい。前記クライアントデバイスは、典型的には、ストレージユニットを更に備える。

第６の態様によれば、前述のメディア記述配信管理デバイスと、前述のクライアントデバイスと、メディアサーバと、を備えるシステムが提供される。

本発明は、メディア記述配信管理デバイス及びクライアントデバイスにおいて動作させられた時に前述の（単数又は複数の）方法を実施するためのソフトウェアコード部分を含んだ（単数又は複数の）コンピュータプログラムにも関する。前記（単数又は複数の）コンピュータプログラムは、コンピュータ可読媒体に格納可能である。前記コンピュータ可読媒体は、各（単数又は複数の）デバイスの中の永続的なメモリ又は書き換え可能なメモリであってもよいし、外部に配置されていてもよい。前記（単数又は複数の）コンピュータプログラムは、例えば、信号シーケンスとしてケーブル又は無線リンクを介して前記各（単数又は複数の）デバイスへ伝送されてもよい。

第７の態様によれば、メディア記述配信管理デバイスの処理ユニットにロード可能なコンピュータプログラムが提供される。前記コンピュータプログラムは、前記処理ユニットによって処理されると、前記第１の態様および／またはその各実施形態のいずれかに記載の方法の各ステップを実行するように構成されたコードを含む。

第８の態様によれば、クライアントデバイスの処理ユニットにロード可能なコンピュータプログラムが提供される。前記コンピュータプログラムは、前記処理ユニットによって処理されると、前記第２または第３の態様および／またはその各実施形態のいずれかに記載の方法の各ステップを実行するように構成されたコードを含む。

本発明に関する、前述の、及びその他の、目的、特徴、及び利点は、添付の図面に示される実施形態に関する以下の詳細な説明において、一層明らかになるであろう。

メディアストリームのメディア表現を示す図である。 ＩＭＳ制御によるＨＴＴＰダウンロードのシグナリング図を示す。 メディア記述配信管理デバイスにおいて行なわれる、メディアストリームのメディア記述をクライアントに提供するための方法を示すフロー図を示す。 クライアントデバイスにおいて行なわれる、メディアストリームのメディア記述をクライアントに提供するための２つの方法を示すフロー図を示す。 本発明の第１の実施形態によるシグナリング図を示す。 本発明の第２の実施形態によるシグナリング図を示す。 本発明の第３の実施形態によるシグナリング図を示す。 本発明の第４の実施形態によるシグナリング図を示す。 メディア記述配信管理デバイスの一実施形態を示す図である。 クライアントデバイスの一実施形態を示す図である。 メディア記述の一実施形態を示す図である。

以下で、メディアストリームのメディア記述をクライアントに提供するための方法およびデバイスについて、より詳細に記述する。

図３で分かるとおり、クライアントが、メディア記述配信規則を備えたメディア記述配信サービスに加入する（３００）。メディア記述配信のための要求が、メディアサーバに送信され（３１０）、メディアサーバからメディア記述が受信される（３２０）。受信されたメディア記述がメディア記述配信規則に適合することが検証される（３４０）。検証が肯定された（「イエス」）場合、クライアントに対するメディア記述の配信が開始される（３５０）。検証が肯定されなかった（「ノー」）場合、メディア記述の配信は開始されないことがある（３６０）。

図４の上の部分で分かるとおり、クライアントをメディア記述配信サービスに加入させるための加入要求が、メディア記述配信管理デバイスに送信される（４００）。メディア記述配信管理デバイスから、メディア記述を受信することができる（４１０）。ステップ４１０の代わりに、図４の下の部分に示すように、クライアントがメディア記述をメディアサーバから取得できるようにする情報が、メディア記述配信管理デバイスから受信され（４２０）、受信された情報に従ってメディア記述を取得するための要求が、メディアサーバに送信され（４３０）、そして、メディア記述が、メディアサーバから受信されてもよい（４４０）。

メディア記述は、背景技術のセクションにあるように定義され、（メディアプレゼンテーション記述またはＭＰＤとも表され）てもよく、例えば、メディアストリームを記述してもよい（メディアストリームは、さまざまな利用可能なメディアストリーム品質と、利用可能な品質のうちの少なくとも１つに従ってメディアストリームを取得する可能性という点で、複数の連続したストリーム要素を含んでいてもよい）。さらにメディア記述は、クライアントにおけるメディアストリームの処理をサポートするための情報、例えば、フェッチされてクライアントで再生されることになるセグメントの選択肢、を含んでいてもよい。

しかし、メディア記述の実施形態の中には、不完全だと思われるもの、例えば、メディアサーバにメディアセグメントを要求するのに必要なメディアリンクを含んでいないものもあるだろう。例えば、そのようなメディア記述は、空であるかまたは、開始時刻だけは定義しているが１つ以上のメディアリンクが欠けていることもありうる。

そのような不完全なメディア記述を除外するため、クライアントが加入しているメディア記述配信サービスのメディア記述配信規則が設けられてもよい。例えば、データファイルが、メディアサーバからメディア記述として受信されてもよいが、例えば、所定のコンテンツ要件に適合しているメディアファイルだけがクライアントに配信されなければならないことを指定する、メディア記述配信規則に適合しないことが検証されてもよい。そのようなコンテンツ要件の一例は、少なくとも１つのメディアリンクが存在していなければならないという指定であってもよい。このような除外されたメディア記述は、クライアントに送信されないため、メッセージを減らすことになる。さらに、検証の中で、受信されたメディア記述が、以前に受信されたメディア記述と比べて更新であるかどうかを分析し、更新されていないメディア記述の送信を抑制して、それ以上のメッセージが通信経路上でクライアントに送信されることを減らしてもよい。

典型的には、メディア記述配信サービスへの加入は、クライアントから受信した加入要求によって行われる。加入要求は、典型的には、メディア記述が配信されるクライアントのアドレスを配信の中で指定する。また、加入要求は、メディア記述配信サービスを示すもの（インジケーション）を含んでいてもよく、メディア記述配信規則の明示的な指定を伴っていてもよいし、伴っていなくてもよい。例えば、規則は、サービスに加入する時に暗示的に設定されてもよいし、クライアントによって入力または調整されてメディア記述配信管理デバイスに実装されてもよく、すなわち、規則は、メディア配信サービスのクライアントおよび／またはサービスプロバイダによって設定されてよい。さらに、加入要求は、どのメディア記述またはどのメディア記述の集合が配信されることになるのかを指定してもよい。しかし、メディアサーバがメディア記述を取得できるようにするため、メディア記述配信管理デバイスは、メディアサーバに送信されるメディア記述要求の中に含めるメディア記述識別子を判定するように構成されてもよい。その代わりに、または、それに加えて、メディア記述配信管理デバイスは、クライアント識別子をメディアサーバに送信してもよく、メディアサーバは、メディア記述をクライアント毎に、例えば、１つのメディア記述をクライアント毎および時間単位毎に管理してもよい。所与のクライアントについて、要求された時刻になると、対応するメディア記述が、メディアサーバからメディア記述配信管理デバイスに送信される。例えば、ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージは、クライアントのアドレスを「ｆｒｏｍ」ヘッダの中に含んでいてもよい。さらに、ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージは、ＭＰＤ更新だけがクライアントデバイスに配信されなければならないというメディア記述配信規則を含んだメディア記述配信サービスの一例として、例えばＭＰＤ更新のような、イベントの指定を含んでいてもよい。さらに、ＳＩＰ ＩＮＶＩＴＥのユーザ部分の中に、または別個のＳＩＰメッセージの中に、配信されることになる少なくとも１つのＭＰＤについての識別子が含まれていてもよい。このＭＰＤ識別子は、後でメディアサーバにＭＰＤを要求するのに用いられるのと必ずしも同一ではない。受信されたＭＰＤ識別子に基づいて、メディア記述配信管理デバイスがメディアサーバを識別してもよい。その代わりに、またはそれに加えて、例えば、クライアント毎に、さらなるメディアサーバ識別メカニズムがあってもよいし、あるいは、メディア記述配信管理デバイス毎に、１つだけメディアサーバがあってもよいだろう。

先に述べた識別子、サービスおよび規則の通信および処理の代わりに、またはそれらに加えて、これらが、オペレータによる維持管理を介して設定されたり管理されたりするように構成されてもよく、例えばクライアントが、そのように加入してもよい。

図５に、クライアント５００、ＭＤ（ｍｅｄｉａ ｄｅｓｃｒｉｐｔｉｏｎ：メディア記述）配信マネージャ５１０、およびメディアサーバ５２０を、各デバイス間で通信されるメッセージＳＲ５０、ＭＤＤ５１、ＭＤＤ５２、Ｑ５１−Ｑ５７、Ｒ５１−Ｒ５７、および、各デバイスで行われるプロセスＳ５０、Ａ５１−Ａ５７と共に示す。任意（オプション）であるメッセージＳＲ５０、Ｑ５２−Ｑ５７については、点線で示す。クライアント５００が、例えば、加入要求ＳＲ５０の受信によってトリガされたＭＤ配信マネージャ５１０において、メディア記述配信サービスに加入する（Ｓ５０）。メディア記述のための要求Ｑ５１が、ＭＤ配信マネージャ５１０からメディアサーバ５２０に送信され、応答Ｒ５１の中で、第１のメディア記述ＭＤ１が戻される。第１のメディア記述ＭＤ１が、メディア記述配信サービスのメディア記述配信規則を適用することによって分析される（Ａ５１）。規則は、所定のメディア記述コンテンツ要件に適合する、最初に受信されたメディア記述が、クライアントに送信されなければならないということを指定してもよい。分析の中で、受信されたメディア記述ＭＤ１が、この規則に適合することが検証される。その結果、メディア記述ＭＤ１が、例えば、メディア記述ＭＤ１を含むメッセージＭＤＤ５１をクライアントに送信することによって、クライアント５００に配信される。続いて、ＭＤ配信マネージャ５１０は、メディア記述ＭＤ１を含んでいる別のメッセージＲ５２−Ｒ５４と、メディア記述ＭＤ１の更新であるメディア記述ＭＤ２を含んでいる別のメッセージＲ５５−Ｒ５７とを受信してもよい。別のメッセージＲ５２−Ｒ５７は、図のように別の要求Ｑ５２−Ｑ５７によってトリガされてもよいし、あるいは、プッシュサービスが、例えば、図のようにメディア記述を含んでいるメッセージＲ５２−Ｒ５７を（定期的に）送信するようにメディアサーバ５２０をトリガしてもよい。本実施形態によれば、分析プロセスＡ５２−Ａ５７において適用されることになるメディア記述配信サービスのメディア記述配信規則は、２つのメディア記述の関係に関わり、後で受信された各メディア記述と、それに対応する、前に受信されたメディア記述とを比較すること、例えば、メッセージＲ５２を介して受信されたＭＤ１と、メッセージＲ５１を介して受信されたＭＤ１とを比較すること、などによって、後で受信された各メディア記述が分析される（Ａ５２−Ａ５７）ということを指定する規則を伴う。後で受信されたメディア記述が、前に受信されたメディア記述の更新として検証されなかった場合、後で受信されたメディア記述は、クライアント５００に送信されないであろう（それは、更新の場合に、更新は送信されるであろうと指定することと同等の定義であり、すなわち、後で受信されたメディア記述が、前に受信されたメディア記述の更新として検証された場合、後で受信されたメディア記述は、クライアント５００に送信される。）現在の例によれば、メッセージＲ５２−Ｒ５４はそれぞれ、第１のメディア記述を含んでおり、分析Ａ５２−Ａ５４の結果としてどのメディア記述もクライアントに送信されない。メッセージＲ５５は、第１のメディア記述（ＭＤ１）の更新である第２のメディア記述（ＭＤ２）を含んでいる。更新のメディア記述配信規則を、メッセージＲ５４を介して、および、メッセージＲ５５を介して受信されたメディア記述に適用すると、後で受信されたメディア記述は変更された、すなわち、これは第１のメディア記述ＭＤ１の更新であるということが判定される。その結果、後で受信されたメディア記述ＭＤ２は、例えばメッセージＭＤＤ５２を介して、クライアント５００に配信される。以下のメッセージＲ５６およびＲ５７はそれぞれ、前に受信されたメディア記述ＭＤ２を含んでいるため、それらはいずれも、Ｒ５５を介して最初に受信されたＭＤ２の更新ではないことが、プロセスＡ５６およびＡ５７においてそれぞれ認識される。それゆえ、メッセージＲ５６およびＲ５７を介して受信されたメディア記述ＭＤ２は、クライアント５００に配信されない。

図６は、本発明の第２の実施形態による別のシグナリング図である。図６は、メッセージＲ５１を介して受信された第１のメディア記述ＭＤ１’が、例えば、メディア記述が、空であるか、またはリンクが不足しているか、または事前に定義されたコンテンツ要件からそれ以外のかたちで逸脱しているため、事前に定義されたメディア記述コンテンツ要件に適合しないと判定されるという点で図５と異なる。その結果、第１の分析Ａ５１の後、第１のメディア記述ＭＤ’は、クライアント５００に送信されない。メッセージＲ５１に続いてメッセージＲ５２−Ｒ５４を介して受信されたすべてのメディア記述は、事前に定義された要件に適合することもなく、更新となることもなく、すなわち、メディア記述ＭＤ１’の配信は、事前に定義されたコンテンツ要件に基づくメディア記述配信規則によって、および／または、先に受信されたメディア記述と後で受信されたメディア記述との比較に基づく更新の検証に基づくメディア記述配信規則によって、抑制することができる。メッセージＲ５５を介して受信されたメディア記述ＭＤ２は、両方の規則に適合しており、従ってクライアント５００に配信される。

本発明はさらに、ＩＭＳ制御のインフラストラクチャにおけるＭＰＤ配信のための手順において、特に、ＭＰＤ更新をクライアントに提供するために実施されてもよい。ＨＴＴＰサーバに対するＭＰＤ更新のための（頻繁な）定期的なポーリング要求が、ＨＴＴＰ／ＳＩＰアダプタによって行われてもよい。そのようにして、ＨＴＴＰ／ＳＩＰアダプタは、常に現行のＭＰＤに追いついた状態(up-to-date)である。次いでＵＥは、「ＭＰＤ Ｕｐｄａｔｅ」イベントについてのセッションの開始時にＨＴＴＰ／ＳＩＰアダプタに対して加入することができる。その後、ＨＴＴＰ／ＳＩＰアダプタは、ＭＰＤが更新されるとすぐにＵＥに通知することができる。通知メッセージは、更新されたＭＰＤと、更新されたＭＰＤをフェッチするためのＭＰＤ ＵＲＩとのいずれか一方を含んでいてもよい。

ＩＭＳ制御のインフラストラクチャにおいてメッセージフローの中に含まれる要素には、例えばクライアントの一例として移動電話などのＵＥ（ユーザ装置）と、ＩＭ ＣＮサブシステム（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｃｏｒｅ Ｎｅｔｗｏｒｋ）と、ＳＣＦ（Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）と、プロトコル変換機能性を持つメディア配信サーバをホストするデバイスの一例として（あるいは、別の言い方をすれば、プロトコル変換機能性を持つメディア記述配信管理デバイスの一例として）ＨＴＴＰ／ＳＩＰアダプタと、メディアサーバの一例としてＨＴＴＰサーバとがある。ＩＭ ＣＮサブシステムおよびＳＣＦは、標準的なＩＭＳコンポーネントであってもよく、通常、本発明を実装する場合には、影響を受けない。

本発明の中で記述する諸特徴から恩恵を得るには、ＵＥは、好ましくは、本明細書で説明した諸特徴を実装しなければならない。さらに、ＨＴＴＰ／ＳＩＰアダプタおよび（少なくとも１つの）ＨＴＴＰサーバは、典型的には、本明細書に記述した方法を実装する場合に拡張されてもよい。例えば、ＭＰＤおよびさまざまなメディア品質が、さまざまなサーバを介して分散される場合、２つ以上のＨＴＴＰサーバが用いられてもよい。さらに、単純なＨＴＴＰサーバの代わりに、ＣＤＮ（Ｃｏｎｔｅｎｔ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｎｅｔｗｏｒｋ）全体が用いられてもよい。しかし、これらの分散型の実施形態は、スタンドアロンデバイスであってもよいし、あるいは、接続可能な複数のデバイスの集合、すなわちシステムであってもよいが、いずれも、「メディアサーバ」という用語で呼ばれうる。従って、ＨＴＴＰ／ＳＩＰアダプタおよびＨＴＴＰサーバは、同一のハードウェア上の、あるいは単一のソフトウェアの中の、コンポーネントとして実装されてもよい。この場合、２つのコンポーネントの間のインタフェースは、異なる可能性があり、すなわち、ＨＴＴＰベースでない可能性がある（その場合、ＳＩＰ／ＨＴＴＰアダプタの文字通りの意味は、このＳＩＰ／「ＨＴＴＰ」アダプタとＨＴＴＰサーバとの間にはＨＴＴＰインタフェースが存在しないかもしれないので、誤解を招くかもしれない。）これらの２つのデバイスの間の非ＨＴＴＰインタフェースの一例は、例えば、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の呼び出し(call)に基づいていてもよい。

発明者らは、背景のセクションの中に記述され、図２に示したＩＭＳ制御のＨＴＴＰプログレッシブダウンロードは、ＭＰＤをＵＥにトランスポートする可能性を提供しうることを解明した。ＵＥは、ＳＩＰ ＩＮＶＩＴＥ（図２のメッセージ１−３）をＨＴＴＰ／ＳＩＰサーバに送信することによってＭＰＤの配信を要求してもよく、ＨＴＴＰ／ＳＩＰサーバは、今度はＭＰＤを（メッセージ４を介して）ＨＴＴＰサーバに要求する。ＨＴＴＰサーバは、要求されたＭＰＤを含むＨＴＴＰ ＰＯＳＴ（メッセージ５）を返し、それは、その後、ＳＩＰ ２００ＯＫ（メッセージ６−８）を介してＵＥに転送される。代替的なＭＰＤ配信として、ＭＰＤではなくＭＰＤ ＵＲＩが、ＨＴＴＰサーバからメッセージ５−８を介してＵＥに送信されてもよく、ＵＥは、その後、ＭＰＤ ＵＲＩを含むＨＴＴＰ ＧＥＴ（メッセージ９）をＨＴＴＰサーバに送信することによってＭＰＤの配信を要求することができる。ＨＴＴＰサーバは、所望のＭＰＤを含むＨＴＴＰ Ｒｅｓｐｏｎｓｅによって応答してもよい。ＭＰＤを受信すると、ＵＥは、ＨＴＴＰサーバでＤＡＳＨセッションを開始し、それに応じて、受信されたセグメントを処理することができる。

ＤＡＳＨセッションの進行の過程で、ＭＰＤがＨＴＴＰサーバにおいて更新される可能性がある。新規のＳＩＰ ＩＮＶＩＴＥはそれぞれ、新たなセッションを常に開始させるのだから、ＵＥは、ＭＰＤ更新についての情報を取得することを目的として、上記のパラグラフで説明した方法を繰り返し適用することはできない。しかし、すでに上記で説明したようにＨＴＴＰサーバとのＨＴＴＰ−要求−応答を介してＭＰＤ更新を要求することは、前に記述したように、問題である。

従って、発明者らは、特にＭＰＤ更新については、公知のＩＭＳ制御によるＨＴＴＰプログレッシブダウンロードは、以下の実施形態の中で示すとおり、本発明による大幅な修正なくしては、まだ適用できないことを解明した。

次に、ＩＭＳ制御によるＤＡＳＨについて１つ以上のＭＰＤをＵＥに提供するためのシグナルフローの一例を示す図７を参照しよう。

セッションを開始するため、ＵＥは、ＳＩＰ ＩＮＶＩＴＥ（ステップ１−３）をＳＩＰ／ＨＴＴＰアダプタに送信する。

ＳＩＰ／ＨＴＴＰアダプタとＨＴＴＰサーバとが、２つの別個のエンティティである場合、ＳＩＰ／ＨＴＴＰアダプタは、ＨＴＴＰ要求、例えば、ＰＯＳＴ要求またはＧＥＴ要求を、最初のＭＰＤに対するＵＲＬおよび／または最初のＭＰＤ自体を取得するために、ＨＴＴＰサーバに発信する（ステップ４＆５）。ＨＴＴＰ応答（ステップ５）の一部として、ＨＴＴＰサーバは、適切なポーリング間隔（例えば１０秒毎にポーリングする）についての情報をＳＩＰ／ＨＴＴＰアダプタに送信する。

ＭＰＤ ＵＲＬまたはＭＰＤ自体を含むＳＩＰ ２００ＯＫが、ＵＥに送信される（ステップ６−８）。

ＭＰＤが受信された場合、ＨＴＴＰサーバからメディアセグメントをフェッチすることによって、ＤＡＳＨが直接起動されてもよい（ステップ８ｃ）。ＭＰＤ ＵＲＬが受信された場合、ＤＡＳＨセッションが起動される（ステップ８ｃ）前に、ＭＰＤがＨＴＴＰ要求／応答を介してフェッチされる（ステップ８ａ＆８ｂ）。

ステップ８でＳＩＰ ２００ＯＫメッセージを受信した後、ＵＥは、ＳＩＰ ＳＵＢＳＣＲＩＢＥをＳＩＰ／ＨＴＴＰアダプタに向けて発信する（ステップ９−１１）。このメッセージと共に、ＵＥは、イベント「ＭＰＤ Ｕｐｄａｔｅ」に、すなわち、更新されたＭＰＤだけがＵＥに提供されることになることを指定するメディア記述配信規則を備えたメディア記述配信サービスに加入する。

ステップ１２−１４は、その加入を確認する、ＳＩＰ／ＨＴＴＰアダプタからＵＥへのＳＩＰ ２００ＯＫメッセージを含んでいる。

ここで、ＳＩＰ／ＨＴＴＰアダプタは、例えば１０秒毎に、ＨＴＴＰサーバに向かって、ＨＴＴＰ要求、例えばＰＯＳＴ要求またはＧＥＴ要求を発信することによって、ＭＰＤの更新についてポーリングしている。ＨＴＴＰサーバは、要求されたＭＰＤを含むＨＴＴＰ ２００ＯＫを使って応答する（ステップ１６）。ＭＰＤに変化がない場合、ステップ１５＆１６が数回続けて行われる。ＨＴＴＰ要求の時間間隔は、事前に交渉されるＳＩＰ／ＨＴＴＰアダプタとＨＴＴＰアダプタとの間のポーリング間隔によって、例えば１０秒毎のように決められる。

ＭＰＤが変更されたことをＳＩＰ／ＨＴＴＰアダプタが認識した場合、ＳＩＰ ＮＯＴＩＦＹメッセージがＵＥに送信される（ステップ１７−１９）。ＳＩＰ ＮＯＴＩＦＹは、更新されたＭＰＤ自体と、更新されたＭＰＤのＵＲＬとのいずれか一方を含んでいる。受信した後、ＵＥは、ＳＩＰ ２００ＯＫをＳＩＰ／ＨＴＴＰアダプタに発信する（ステップ２０−２２）。

更新されたＭＰＤのＵＲＬが受信された場合、ＵＥは、ＨＴＴＰを介して更新されたＭＰＤをフェッチする（ステップ２２ａ＆２２ｂ）。

ＤＡＳＨセッションは、更新されたＭＰＤの中のメディアセグメントを前述のようにフェッチすることによって継続される（図示せず）。

図７では、ＳＩＰ Ｓｕｂｓｃｒｉｂｅメッセージ（９−１１）が、ＤＡＳＨセッションの開始の（だいぶ）前にＳＩＰ／ＨＴＴＰアダプタにも送信されてよい。これによって、クライアントが、一種のコンテンツ発行イベントに加入できるようになるであろう。最初は、ＭＰＤは空であるかまたは今後の開始時刻を示しているかもしれないが、ＭＰＤがメディアリンクを含むとすぐに、ＵＥは、（ＭＰＤまたはＭＰＤのＵＲＬを含めて）ＳＩＰ ＮＯＴＩＦＹメッセージを入手するであろう。この場合、ＳＩＰ ＮＯＴＩＦＹを受信した後、ＵＥは、上述のようにプロセスを開始し、ステップ９は、すでに以前に実行されたのだから、中止することができる。図８に一例を示すが、すなわち、メッセージ１１が受信された後、ＳＩＰ ｉｎｖｉｔｅメッセージ（図８には図示せず）がＨＴＴＰ／ＳＩＰアダプタに送信されてＤＡＳＨセッションが開始され、メッセージ１４ａおよび１４ｂを介して受信されることになるＭＰＤが適用される連続的なメディア要素が受信されてもよい。メッセージ１４ａとＳＩＰ Ｉｎｖｉｔｅメッセージとは、同時に送信されてもよいし、あるいは、その他の方法で時間的に相関されてもよく、それによってＭＰＤとメディアストリームとが同時に受信されて同期し、こうしてＵＥにおけるＭＰＤに基づくメディアストリーム処理が最適化される。

別の実施形態によれば、ＨＴＴＰ／ＳＩＰアダプタは、図７のステップ４および５または１５および１６、あるいは、図８のステップ７および８の中で、その他のメカニズムまたは追加のメカニズムを利用してもよい。ＭＰＤ変更のための更新の定期的なポーリングの代わりに、ＨＴＴＰ／ＳＩＰアダプタは、ＨＴＴＰサーバによって提供される可能性があるプッシュメカニズムを利用してもよい。また、このプッシュサービスは、プッシュアグリゲータとして動作しうる別のノードまたはサービスによって提供される可能性もあるだろう。これによって、ＳＩＰ／ＨＴＴＰアダプタとＵＥとの間のリンクにかかる負荷だけでなく、ＳＩＰ／ＨＴＴＰアダプタとＨＴＴＰサーバとの間のそれも低減するであろう。このリンク上でプッシュを用いることは、ＭＰＤ更新の頻度が分からない場合に、特に有利である。

次に、メディア記述配信管理デバイス９１０およびクライアントデバイス１０００の実施形態をそれぞれ示す図９および図１０を参照しよう。

典型的には、メディア記述配信管理デバイス９１０は、クライアントとは受信ユニットＲｘ９１および送信ユニットＴｘ９１を介して通信し、メディアサーバとは受信ユニットＲｘ９２および送信ユニットＴｘ９２を介して通信するようになっており、特に、クライアントとの通信が第１のトランスポートプロトコル（例えばＳＩＰ）に従って行われ、かつ、メディアサーバとの通信が第１のプロトコルとは異なる第２のトランスポートプロトコル（例えばＨＴＴＰ）に従って行われる場合にそうである。しかし、クライアントおよびメディアサーバとの通信は同一のプロトコルを介して行われるけれども、別個の受信ユニットおよび送信ユニットを用いるような実装もあるかもしれない。あるいは、例えば、さまざまなトランスポートプロトコルに従って通信できる送信ユニットまたは受信ユニットの場合、単一の受信ユニットまたは単一の送信ユニットが、メディアサーバとクライアントデバイス１０００とのどちらとも通信できるような実装もあるかもしれない。この場合、一組の受信ユニットおよび送信ユニットだけが、例えば受信ユニットＲｘ９１および送信ユニットＴｘ９１だけが、クライアントとの通信用だけでなくメディアサーバとの通信用にも用いられ、他方の組の受信ユニットと送信ユニットとは、その時の例によれば受信ユニットＲｘ９２および送信ユニットＴｘ９２であろうが、必要ないであろう。別個のユニットとして描かれているが、送信ユニットと受信ユニットとは、１つのトランシーバユニットとして実施されてもよい。

メディア記述配信管理デバイス９１０の一実施形態によれば、処理ユニットＰ９は、クライアントをメディア記述配信サービスに加入させるように構成されてもよく、ここでは、このメディア記述配信サービスはメディア記述配信規則を含んでいる。送信ユニットＴｘ９２は、メディア記述配信のための要求をメディアサーバに送信するように構成されてもよい。受信ユニットＲｘ９２は、メディア記述をメディアサーバから受信するように構成されてもよい。処理ユニットＰ９は、受信されたメディア記述がメディア記述配信規則に適合することを検証するように構成されてもよい。処理ユニットＰ９は、検証が肯定されたと判定した場合、例えばメディア記述または、クライアントがメディア記述をメディアサーバから取得できるようにする情報を、送信ユニットＴｘ９１または送信ユニットＴｘ９２を介してクライアントに送信することによって、クライアントに対するメディア記述の配信を開始する。本方法の別のステップが、関係するユニットによって行われてもよく、例えば加入要求が受信ユニットＲｘ９１を介して受信されてもよいし、受信された（別の）メディア記述がストレージユニットＳ９の中に格納されてもよい。

より早い時刻に受信された別のメディア記述が、メディア記述配信管理デバイス９１０のストレージユニットに格納されてもよい。後になってメディア記述が受信された時、その別のメディア記述をストレージユニットから検索することができる。両方のメディア記述は、メディア記述配信管理デバイス９１０の処理ユニットに入力され、メディア記述配信規則に従って、対応する検証が行われる。すなわち、後に受信されたメディア記述は先に受信された別のメディア記述の更新であるかどうかが検証され、後に受信されたメディア記述は更新であると判定された場合、クライアントへの配信が開始される。

典型的には、クライアントデバイス１０００は、受信ユニットＲｘ１０１と送信ユニットＴｘ１０１とを介して、例えば、メディア記述に加入（サブスクライブ）してこれをメディア記述配信管理デバイス９１０から受信するために、メディア記述配信管理デバイス９１０と通信する。メディアサーバとの通信が、同じ受信ユニットＲｘ１０１および送信ユニットＴｘ１０１を介して行われてもよいし、および／または、受信ユニットＲｘ１０２および送信ユニットＴｘ１０２を介して行われてもよい。後者の選択肢は、特に、メディア記述配信管理デバイス９１０との通信が第１のトランスポートプロトコルに従って行われ、かつ、メディアサーバとの通信が第２のトランスポートプロトコルに従って行われる場合に、適用可能である。

しかし、メディア記述配信管理デバイス９１０およびメディアサーバとの通信は同一のプロトコルを介して行われるけれども、別個の受信ユニットおよび送信ユニットを用いるような実装もあるかもしれない。あるいは、例えば、さまざまなトランスポートプロトコルに従って通信できる送信ユニットまたは受信ユニットの場合、単一の受信ユニットまたは単一の送信ユニットが、メディアサーバとメディア記述配信管理デバイス９１０とのどちらとも通信できるような実装もあるかもしれない。この場合、一組の受信ユニットおよび送信ユニットだけが、例えば受信ユニットＲｘ９１および送信ユニットＴｘ９１だけが、メディアサーバとの通信用だけでなくメディア記述配信管理デバイスとの通信用にも用いられ、他方の組の受信ユニットと送信ユニットとは、その時の例によれば受信ユニットＲｘ１０２および送信ユニットＴｘ１０２であろうが、必要ないであろう。別個のユニットとして描かれているが、送信ユニットと受信ユニットとは、１つのトランシーバユニットとして実施されてもよい。

クライアントデバイス１０００の一実施形態によれば、送信ユニットＴｘ１０１は、クライアントをメディア配信サービスに加入させるための加入要求をメディア記述配信管理デバイス９１０に送信するように構成されてもよい。受信ユニットＲｘ１０１は、メディア記述をメディア記述配信管理デバイス９１０から受信するように構成されてもよい。前に記述した受信の代わりに、受信ユニットＲｘ１０１は、クライアントがメディア記述をメディアサーバから取得できるようにする情報をメディア記述配信管理デバイス９１０から受信するように構成されてもよい。送信ユニット（Ｔｘ１０１または）Ｔｘ１０２は、受信された情報に従ってメディア記述を取得するための要求をメディアサーバに送信するように構成されてもよいし、受信ユニット（Ｒｘ１０１または）Ｒｘ１０２は、メディア記述をメディアサーバから受信するように構成されてもよい。

本方法の別のステップが、関係するユニットによって行われてもよく、例えば、受信されたメディア記述がストレージユニットＳ１０の中に格納されてもよい。メディアサーバおよびメディア記述配信管理デバイス９１０と通信するのに、異なるトランスポートプロトコルが用いられる場合、クライアントがメディア記述を取得できるようにするために受信された情報は、処理ユニットＰ１０によって第１のトランスポートプロトコルによる１つのフォーマットから第２のプロトコルによるもう１つのフォーマットへと変換されてもよい。別のプロトコル変換プロセスが、処理ユニットＰ１０によって行われてもよい。

本発明は、特にクライアントとメディアサーバとの間の、シグナリングのオーバヘッドの大幅な減少を実現する。本発明はさらに、メディア記述更新の場合にクライアントへの迅速な通知を実現すると共に、更新されたコンテンツと、および／または、メディアサーバに関する更新された品質と、および／または、例えば、更新されたＭＰＤがより高品質でのメディア表現を指示する場合にＩＭ ＣＮサブシステムにおいてより高速の送信ビットレートのベアラを予約するための、電気通信システムの別のコンポーネントという点に関して、更新されたメディアストリームを要求するためのクライアントによる反応の迅速化をも実現する。

Claims (28)

1. メディアストリームのメディア記述をクライアント（５００，１０００）に提供する、メディア記述配信管理デバイスにより実行される方法であって、
   前記クライアント（５００，１０００）を、メディア記述配信規則を有するメディア記述配信サービスに加入させるステップ（３００）と、
   前記加入させるステップ（３００）に基づき、メディア記述配信の要求をメディアサーバ（５２０）へ送信するステップ（３１０）と、
   前記メディアサーバ（５２０）からメディア記述を受信するステップ（３２０）と、
   前記受信したメディア記述が前記メディア記述配信規則に適合していることを検証するステップ（３４０）と、
   前記検証が肯定であった場合、前記クライアント（５００，１０００）に対する前記メディア記述の配信を開始するステップ（３５０）と、
   を備えることを特徴とする方法。
2. 前記クライアントを前記メディア記述配信サービスに加入させる前記ステップのための加入要求を受信するステップを備える
   ことを特徴とする請求項１に記載の方法。
3. 前記加入要求は、前記クライアントのアドレスと、前記メディア記述配信サービスを示すものと、どのメディアを配信すべきかと、のうちの少なくとも１つを指定する
   ことを特徴とする請求項２に記載の方法。
4. 前記メディア記述の前記配信は、前記受信したメディア記述を前記クライアントへ送信することを含む
   ことを特徴とする請求項２又は３に記載の方法。
5. 前記メディア記述の前記配信は、前記クライアントが前記メディアサーバから前記メディア記述を取得できるようにする情報を前記クライアントへ送信することを含む
   ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記メディア記述配信規則は、少なくとも１つの事前定義されたコンテンツ要件を指定し、
   前記検証するステップにおいて、前記受信したメディア記述の内容が前記事前定義されたコンテンツ要件と比較される
   ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
7. 前記メディア記述配信規則は、少なくとも２つのメディア記述の関係に関わり、
   前記検証するステップにおいて、前記受信したメディア記述は前記少なくとも２つのメディア記述のうちの１つである
   ことを特徴とする請求項４に記載の方法。
8. 別のメディア記述が受信され、
   前記別のメディア記述は、前記少なくとも２つのメディア記述のうちの２番目のものである
   ことを特徴とする請求項７に記載の方法。
9. 前記別のメディア記述は、前記メディア記述と比べて時間的に早くに受信され、
   前記メディア記述配信規則は、前記メディア記述が前記別のメディア記述の更新である場合にのみ前記メディア記述が送信されるということを指定する
   ことを特徴とする請求項８に記載の方法。
10. 前記別のメディア記述は、メディア記述配信の別の要求を前記メディアサーバに対して送信したことに応えて受信される
    ことを特徴とする請求項８又は９に記載の方法。
11. 前記クライアントへ送信される前記メディア記述は、第１のトランスポートプロトコルに従って通信され、
    前記メディアサーバへ送信されるメディア記述配信の前記要求と、前記メディアサーバから受信される前記メディア記述と、のうちの少なくとも一方は、第２のトランスポートプロトコルに従って通信される
    ことを特徴とする請求項１０に記載の方法。
12. メディア記述配信の前記別の要求と、前記メディアサーバから受信される前記別のメディア記述と、のうちの少なくとも一方は、前記第２のトランスポートプロトコルに従って通信される
    ことを特徴とする請求項１１に記載の方法。
13. 前記加入要求は、前記第１のトランスポートプロトコルに従って通信される
    ことを特徴とする請求項１１又は１２に記載の方法。
14. 前記第１のトランスポートプロトコルは、セッション開始プロトコル（ＳＩＰ）である ことを特徴とする請求項１１乃至１３のいずれか１項に記載の方法。
15. 前記第２のトランスポートプロトコルは、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）である
    ことを特徴とする請求項１１乃至１４のいずれか１項に記載の方法。
16. メディアストリームのメディア記述をクライアント（５００，１０００）に提供する、クライアント（５００，１０００）により実行される方法であって、
    前記クライアント（５００，１０００）をメディア記述配信サービスに加入させる加入要求をメディア記述配信管理デバイス（５１０，９１０）へ送信するステップ（４００）と、
    前記メディア記述配信管理デバイス（５１０，９１０）から前記メディア記述を受信するステップ（４１０）であって、当該メディア記述は、前記送信された加入要求に基づき、前記メディア記述配信管理デバイス（５１０，９１０）によってメディアサーバ（５２０）から要求される、ステップと、
    を備えることを特徴とする方法。
17. メディアストリームのメディア記述をクライアント（５００，１０００）に提供する、クライアント（５００，１０００）により実行される方法であって、
    前記クライアント（５００，１０００）を、メディア記述配信規則を有するメディア記述配信サービスに加入させる加入要求を、メディア記述配信管理デバイス（５１０，９１０）へ送信するステップ（４００）と、
    前記メディア記述配信管理デバイス（５１０，９１０）による、メディアサーバ（５２０）から受信した前記メディア記述が前記メディア記述配信規則に適合していることの検証が、肯定であった場合、前記メディア記述配信管理デバイス（５１０，９１０）から、前記クライアント（５００，１０００）が前記メディアサーバ（５２０）から前記メディア記述を取得できるようにする情報を受信するステップ（４２０）と、
    前記受信した情報に従い、前記メディア記述を取得する要求を前記メディアサーバ（５２０）へ送信するステップ（４３０）と、
    前記メディアサーバ（５２０）から前記メディア記述を受信するステップ（４４０）と、
    を備えることを特徴とする方法。
18. 前記加入要求は、前記クライアントのアドレスと、前記メディア記述配信サービスを示すものと、どのメディアを配信すべきかと、のうちの少なくとも１つを指定する
    ことを特徴とする請求項１６又は１７に記載の方法。
19. 前記加入要求は、第１のトランスポートプロトコルに従って通信され、
    前記メディア記述を取得する前記要求と、前記メディアサーバから受信される前記メディア記述と、のうちの少なくとも一方は、第２のトランスポートプロトコルに従って通信される
    ことを特徴とする請求項１６乃至１８のいずれか１項に記載の方法。
20. 前記第１のトランスポートプロトコルは、セッション開始プロトコル（ＳＩＰ）である ことを特徴とする請求項１９に記載の方法。
21. 前記第２のトランスポートプロトコルは、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）である
    ことを特徴とする請求項２０に記載の方法。
22. 請求項１乃至１５のいずれか１項に記載の方法の各ステップを実行するように構成されたメディア記述配信管理デバイス（５１０，９１０）。
23. 少なくとも１つの受信ユニット（Ｒｘ９１，Ｒｘ９２）と、少なくとも１つの送信ユニット（Ｔｘ９１，Ｔｘ９２）と、処理ユニット（Ｐ９）と、を備える
    ことを特徴とする請求項２２に記載のメディア記述配信管理デバイス。
24. 請求項１６乃至２１のいずれか１項に記載の方法の各ステップを実行するように構成されたクライアントデバイス（５００，１０００）。
25. 少なくとも１つの受信ユニット（Ｒｘ１０１，Ｒｘ１０２）と、少なくとも１つの送信ユニット（Ｔｘ１０１，Ｔｘ１０２）と、処理ユニット（Ｐ１０）と、を備える
    ことを特徴とする請求項２４に記載のクライアントデバイス。
26. 請求項２２又は２３に記載のメディア記述配信管理デバイス（５１０，９１０）と、請求項２４又は２５に記載のクライアントデバイス（５００，１０００）と、メディアサーバ（５２０）と、を備える
    ことを特徴とするシステム。
27. メディア記述配信管理デバイス（５１０，９１０）の処理ユニット（Ｐ９）にロード可能なコンピュータプログラムであって、
    前記処理ユニットによって処理されると、請求項１乃至１５のいずれか１項に記載の方法の各ステップを実行するように構成されたコードを含む
    ことを特徴とするコンピュータプログラム。
28. クライアントデバイス（５００，１０００）の処理ユニット（Ｐ１０）にロード可能なコンピュータプログラムであって、
    前記処理ユニットによって処理されると、請求項１６乃至２１のいずれか１項に記載の方法の各ステップを実行するように構成されたコードを含む
    ことを特徴とするコンピュータプログラム。

Images