(57)【特許請求の範囲】
【請求項１】
アダプティブＨＴＴＰストリーミングプレーヤにメディアコンテンツを提供する方法であって、
前記メディアコンテンツを要求する前記アダプティブＨＴＴＰストリーミングプレーヤから、ＨＴＴＰ要求を受信するステップ（Ｓ２１）と、
前記メディアコンテンツを、前記メディアコンテンツの表現に関する変更が行われない固定品質インタフェース上で入手可能なメディアコンテンツとして識別するステップ（Ｓ２２）と、
前記固定品質インタフェース上で提供される前記メディアコンテンツの表現プリファレンスインジケーションを判定するステップであって、前記表現プリファレンスインジケーションは前記メディアコンテンツの好適品質表現を示す、ステップ（Ｓ２３）と、
前記アダプティブＨＴＴＰストリーミングプレーヤに対して、前記固定品質インタフェース上で提供される前記メディアコンテンツを要求するために前記メディアコンテンツの前記好適品質表現を送信するように指示するために、前記表現プリファレンスインジケーションを前記アダプティブＨＴＴＰストリーミングプレーヤへシグナリングするステップ（Ｓ２４）と、
を備えることを特徴とする方法。
【請求項２】
前記識別するステップ（Ｓ２２）は、前記ＨＴＴＰ要求により受信されるメディアセグメントに対応するＳＤＰファイルを見つけるために、入手可能なＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）ファイルをチェックするステップを含む
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記識別するステップ（Ｓ２２）は、前記ＨＴＴＰ要求の中で受信されたコンテンツ識別子を評価するステップを含む
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記方法は、前記固定品質インタフェースを介した前記メディアコンテンツの提供が可能であるか否かをチェックするステップを更に備える
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記識別するステップ（Ｓ２２）は、固定品質の前記メディアコンテンツがキャッシュにおいて入手可能であるか否かを判定するステップを含む
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記判定するステップ（Ｓ２３）は、前記表現プリファレンスインジケーションを前記ＳＤＰファイルから導出するステップを含む
ことを特徴とする請求項２に記載の方法。
【請求項７】
前記判定するステップ（Ｓ２３）は、前記表現プリファレンスインジケーションをＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）ファイルから導出するステップを含む
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項８】
前記表現プリファレンスインジケーションは、数値又は文字列の表現である
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記表現プリファレンスインジケーションは、複数の表現のサブセットである
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項１０】
前記シグナリングするステップ（Ｓ２４）は、前記アダプティブＨＴＴＰストリーミングプレーヤに対する応答に、前記表現プリファレンスインジケーションを追加するステップを含む
ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
前記固定品質インタフェースは、ブロードキャストされるデータを提供するインタフェースである
ことを特徴とする請求項１に記載の方法。
【請求項１２】
前記固定品質インタフェースは、キャッシュに格納されるデータを提供するインタフェースである
ことを特徴とする請求項１に記載の方法。
【請求項１３】
アダプティブＨＴＴＰストリーミングプレーヤにおいてメディアコンテンツを提供する方法であって、
ＨＴＴＰエンティティに対して、前記メディアコンテンツの提供を求めるＨＴＴＰ要求（７１，１１０１）を送信するステップ（Ｓ３１）と、
前記ＨＴＴＰエンティティから、前記メディアコンテンツの表現に関する変更が行われない固定品質インタフェース上で提供される前記メディアコンテンツの表現プリファレンスインジケーションを受信する（７２，１１０７）ステップであって、前記表現プリファレンスインジケーションは前記メディアコンテンツの好適品質表現を示す、ステップ（Ｓ３２）と、
前記固定品質インタフェース上で提供される前記メディアコンテンツを要求するために、前記受信した表現プリファレンスインジケーションが示す前記好適品質表現を送信する（１１１０）ステップ（Ｓ３３）と、
を備えることを特徴とする方法。
【請求項１４】
前記ＨＴＴＰ要求（７１，１１０１）は、受信したＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）（６０１）ファイルに従う要求を含み、前記ＭＰＤファイルは、前記メディアコンテンツの提供を記述する
ことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記ＨＴＴＰエンティティから表現プリファレンスインジケーションを受信する前記ステップは、前記受信した表現プリファレンスインジケーションを継続的にチェックするステップを含む
ことを特徴とする請求項１３に記載の方法。
【請求項１６】
前記アダプティブＨＴＴＰストリーミングプレーヤは、前記表現プリファレンスインジケーションを受信すると、ユニキャストインタフェース上での提供データのリンク品質における何らかの変化の測定を停止する
ことを特徴とする請求項１３乃至１５のいずれか１項に記載の方法。
【請求項１７】
アダプティブＨＴＴＰストリーミングプレーヤに対してメディアコンテンツを提供するように構成されたＨＴＴＰエンティティデバイス（４１）であって、
前記メディアコンテンツを要求する前記アダプティブＨＴＴＰストリーミングプレーヤから、ＨＴＴＰ要求を受信するように構成された受信器（４６）と、
前記メディアコンテンツを、前記メディアコンテンツの表現に関する変更が行われない固定品質インタフェース（４２）上で提供されるメディアコンテンツとして識別するように構成された識別器（４４）と、
前記固定品質インタフェース（４２）上で提供される前記メディアコンテンツの表現プリファレンスインジケーションを判定するように構成されたプロセッサであって、前記表現プリファレンスインジケーションは前記メディアコンテンツの好適品質表現を示す、プロセッサ（４５）と、
前記アダプティブＨＴＴＰストリーミングプレーヤに対して、前記固定品質インタフェース上で提供される前記メディアコンテンツを要求するために前記メディアコンテンツの前記好適品質表現を送信するように指示するために、前記表現プリファレンスインジケーションを前記アダプティブＨＴＴＰストリーミングプレーヤへシグナリングするように構成された送信器（４７）と、
を備えることを特徴とするデバイス。
【請求項１８】
前記デバイスは、ブロードキャスト又はＩＰマルチキャストを介してメディアセグメントを受信するように構成されたブロードキャストインタフェース（７０８，８０７）を更に備える
ことを特徴とする請求項１７に記載のデバイス。
【請求項１９】
前記デバイスは、ユニキャストウェブサーバ（６１０，７０４，８０４，９０４，１０１４）からメディアコンテンツをフェッチするように構成されたユニキャストインタフェース（７０９，８０８）を更に備える
ことを特徴とする請求項１７又は１８に記載のデバイス。
【請求項２０】
前記デバイスは、固定データ品質を持つデータをキャッシュするように構成されたキャッシュ（６０５，７０３，８０３，９０３，１０１３）を更に備える
ことを特徴とする請求項１７、１８、又は１９に記載のデバイス。
【請求項２１】
メディアコンテンツを提供するように構成されたアダプティブＨＴＴＰストリーミングプレーヤデバイス（５１）であって、
ＨＴＴＰエンティティ（４１）に対して、前記メディアコンテンツの提供を求めるＨＴＴＰ要求を送信するように構成された送信器（５２）と、
前記ＨＴＴＰエンティティ（４１）から、前記メディアコンテンツの表現に関する変更が行われない固定品質インタフェース（４２）上で提供される前記メディアコンテンツの受信のために、表現プリファレンスインジケーションを受信するように構成された受信器であって、前記表現プリファレンスインジケーションは前記メディアコンテンツの好適品質表現を示す、受信器（５３）と、
前記固定品質インタフェース上で提供される前記メディアコンテンツを要求するために、前記受信した表現プリファレンスインジケーションが示す前記好適品質表現を送信するように構成されたプロセッサ（５４）と、
を備えることを特徴とするアダプティブＨＴＴＰストリーミングプレーヤデバイス。
【請求項２２】
メディアコンテンツを提供するように構成されたクライアントデバイスであって、
前記クライアントデバイスは、請求項２１に記載のアダプティブＨＴＴＰストリーミングプレーヤデバイスと、請求項１７に記載のＨＴＴＰエンティティデバイスと、を備える
ことを特徴とするクライアントデバイス。
【請求項２３】
前記アダプティブＨＴＴＰストリーミングプレーヤデバイスと前記ＨＴＴＰエンティティデバイスとは、同一デバイス上に配置されている
ことを特徴とする請求項２２に記載のクライアントデバイス。
【請求項２４】
前記アダプティブＨＴＴＰストリーミングプレーヤデバイスと前記ＨＴＴＰエンティティデバイスとは、別個のデバイス上に配置されている
ことを特徴とする請求項２２に記載のクライアントデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、マルチメディアサービスをユーザに提供するための技法に関する。詳細には、マルチメディアコンテンツを、アダプティブＨＴＴＰストリーミングプレーヤの一例であるＤＡＳＨプレーヤに送信するための技法を開示する。
【０００２】
本ソリューションは、メディアセグメントの送信を提供するブロードキャスト送信技法を用いて、ネットワークソリューションの範囲内で実施することができる。詳細には、本ソリューションは、メディアセグメントのｅＭＢＭＳ送信を用いたシナリオ、または、ＤＳＬアクセスシステムにおけるＩＰマルチキャスト（ＩＰＴＶ）のような、その他のブロードキャスト送信技法を用いたシナリオにおいて用いることができる。さらに、本ソリューションは、メディアコンテンツをキャッシュから提供する場合にも適用できる。
【背景技術】
【０００３】
ＤＡＳＨ（Ｄｙｎａｍｉｃ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ：ＨＴＴＰ上のダイナミック・アダプティブ・ストリーミング）は、アダプティブストリーミング技法であり、ＩＳＯ／ＩＥＣ２３００９−１：２０１２（Ｅ）、バージョン２．１ｃ２、「Ｄｙｎａｍｉｃ  ａｄａｐｔｉｖｅ  ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ（ＤＡＳＨ）−Ｐａｒｔ  １：Ｍｅｄｉａ  ｐｒｅｓｅｎｔａｔｉｏｎ  ｄｅｓｃｒｉｐｔｉｏｎ  ａｎｄ  ｓｅｇｍｅｎｔ  ｆｏｒｍａｔｓ（ＨＴＴＰ上のダイナミック・アダプティブ・ストリーミング、第１部、メディアプレゼンテーション記述およびセグメントフォーマット）」で開示されているように、現時点で利用可能なリンクのビットレートにメディアストリームを適合させるものである。
【０００４】
アダプティブＨＴＴＰストリーミング技法は、メディア品質を選択するクライアントに依存する。サーバまたはコンテンツプロバイダが、すべての利用可能な品質表現をいわゆるマニフェストファイルの中に記述するのだが、例えば、メディアのビットレートの違いやサーバから表現にアクセスするやり方に関して、メディアコンテンツの表現が異なる可能性がある。マニフェストファイルは、ストリーミングセッションの始めに少なくとも一度フェッチされ、セッション中に更新されることもある。ＭＰＤは、メディアセッションに属し且つ次のメディアセグメントをフェッチするのに用いられる、すべてのメディアセグメントのＵＲＩのリストまたはリストを生成する手段を備えている。アップルのＨＬＳの場合、マニフェストは、ｍ３ｕ８フォーマットのＰｌａｙｌｉｓｔファイルとしてフォーマットされている。３ＧＰＰ／ＭＰＥＧ  ＤＡＳＨの場合、マニフェストは、ＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ：メディアプレゼンテーション記述）と呼ばれるＸＭＬ構造をしている。
【０００５】
ＤＡＳＨは、クライアントによって制御されるアダプティブＨＴＴＰストリーミングプロトコルとして設計されている。すなわち、サーバが、一組の利用可能なメディア品質を、例えばＭＰＤの中に記述し、クライアントが、リンクのビットレートに応じて、リンクのビットレートに合致するメディア表現（すなわちメディアのビットレート）を選択するのである。一般にＤＡＳＨソリューションは、ＤＡＳＨサーバが、表現と呼ばれる異なったメディア品質を持つコンテンツを提供するように構成されることを含んでおり、クライアント側では、ＤＡＳＨクライアントが、異なった品質を持つメディアコンテンツを要求するように構成される。
【０００６】
アダプティブＨＴＴＰストリーミング技法の多くは、クライアントがサーバからメディアセグメントを連続的にフェッチすることを必要とする。メディアセグメントの中には、所定量のメディア時間（例えば１０秒のメディアデータ）が含まれている。特定のメディア表現のうちの個々のセグメントは、マニフェストに示される特定の時刻にサーバで利用可能となる。異なった品質表現のセグメントをダウンロードするためにクライアント側にＵＲＩを作成するやり方が、マニフェストに記述される。
【０００７】
図１は、ＤＡＳＨ環境においてセグメントをフェッチする原理を示す図である。ＤＡＳＨクライアントであるクライアントが、ＤＡＳＨサーバであるサーバと通信する。
【０００８】
ＨＴＴＰ  ＧＥＴ  ｍａｎｉｆｅｓｔ  ｆｉｌｅメッセージ１０の応答としてマニフェストファイルが受信されて処理され、見込まれる品質が判定される１１。次のステップ１２で、クライアントが、ＨＴＴＰ  ＧＥＴ  Ｓｅｇｍｅｎｔ＃１  ｆｒｏｍ  Ｌｏｗｅｓｔ  Ｑｕａｌｉｔｙで最低品質のデータを要求し、ダウンロード速度の測定が行われる１３。クライアントは、引き続き、１４でメディアセグメントを受信しながらリンクのビットレートを測定して、コンテンツデータの受信に適した品質を判定する。クライアントは、１５で表現を変更することが決定された場合、いつでも別の品質の表現に変更してよい。図１による実施形態では、１６でＨＴＴＰ  ＧＥＴ  Ｓｅｇｍｅｎｔ＃２  ｆｒｏｍ  Ｍｅｄｉｕｍ  Ｑｕａｌｉｔｙによって中位の品質のメディアデータを要求し、１７でダウンロードレートの測定を続けることが決定される。
【０００９】
現在、ｅＭＢＭＳ（ＬＴＥ  Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）のようなブロードキャストシステム上でＤＡＳＨメディアセグメントを配信することも可能である。セル内またはいずれかのブロードキャストエリア内のすべてのユーザが同一のビットストリーム品質を用いる場合、ブロードキャストは効率的である。これは、典型的には、単一の品質の表現だけがエリア内にブロードキャストされ、前記エリア内のクライアントは、その特定の品質を選択することを意味する。
【００１０】
従って、典型的には、特定の目標エリア内へは単一の表現だけがブロードキャストされるのであり、同じコンテンツストリームであっても、別のブロードキャストエリア内では別のビットレート制約を使って、言い換えれば、別の表現を使って、ブロードキャストされる。従って、同じサービスを、例えば市街地ではより高速のビットレートで、郊外ではより低速のビットレートでブロードキャストすることが可能である。
【００１１】
ＤＡＳＨプレーヤはコンテンツをブロードキャストまたはユニキャストを介して受信することができる。しかし、ＤＡＳＨプレーヤは、電話がブロードキャストカバレッジの中にあるのかユニキャストカバレッジの中にあるのかについての情報を持っていない。
【００１２】
ブロードキャストのシナリオでは、メディアセグメントは、ＤＡＳＨプレーヤに利用できるようにされる前に、まずｅＭＢＭＳクライアントによって受信されなければならない。これは、ユニキャスト表現に比べてブロードキャスト表現の不利点である。ＤＡＳＨプレーヤは、最初にブロードキャストＤＡＳＨセッションを受信する時に追加の遅延を受け入れることがありうる。しかし、ＤＡＳＨプレーヤには、ＵＥがブロードキャストカバレッジ内にいるのか否かが分からない。従って、電話がブロードキャストカバレッジ内にいない場合には、ＤＡＳＨプレーヤは、ただ単にブロードキャスト受信が不可能であることを見つけるために、まず、ブロードキャストの開始のためにこの追加の遅延を待つことが必要となる。
【００１３】
さらに、クライアントは、自分が表現をブロードキャストから受信しているのかユニキャストから受信しているのか分からないため、両方の受信について同様にダウンロード速度を測定する。中位の品質の表現がブロードキャストされている場合、良好なダウンロード速度を観察しているクライアントは、ブロードキャストされていないより高品質の表現に切り換えることを決める可能性がある。クライアントが切り換えた後には、セグメントは必然的にユニキャストを介して取り出されることとなり、その結果、その高品質の表現の非常に低速のダウンロード速度を経験する可能性があるため、体験の質だけでなくネットワーク負荷にも悪影響が及ぶ。
【００１４】
例えば測定実施に起因してかまたはブロードキャストされたデータの受信に起因して遅延が生じることによって、ユーザ側ではＱｕａｌｉｔｙ  ｏｆ  Ｅｘｐｅｒｉｅｎｃｅ（ＱｏＥ：体験の質）の低下が生じ、次いで、ＱｏＥの観点からは、クライアント側でのビデオの起動が、高速で実行されることになる可能性がある。
【発明の概要】
【００１５】
メディアデータを効率的にユーザに提供する技法の必要性がある。特に、提示されたデータの体験レベルを高める必要性がある。
【００１６】
本発明は、独立請求項の中で実施される。有利な実施形態を、従属請求項の中に記述する。
【００１７】
メディアコンテンツをアダプティブＨＴＴＰストリーミングプレーヤに提供するための方法によって、必要性が満たされる。方法は、メディアコンテンツを要求しているアダプティブＨＴＴＰストリーミングプレーヤからＨＴＴＰ要求を受信するステップを含む。次のステップでは、固定品質インタフェース上で入手可能なコンテンツとしてメディアコンテンツが識別され（Ｓ２２）、次いで、固定品質インタフェース上で提供されるコンテンツの表現プリファレンスインジケーションが判定される。判定された表現プリファレンスインジケーションが、アダプティブＨＴＴＰストリーミングプレーヤにシグナリングされる。
【００１８】
さらに、アダプティブＨＴＴＰストリーミングプレーヤの中で実現されるメディアコンテンツを提供するための方法によって、必要性が満たされる。前記ＨＴＴＰストリーミングプレーヤが、ＨＴＴＰエンティティに対して、メディアコンテンツの提供のＨＴＴＰ要求を送信する。要求への応答として、アダプティブＨＴＴＰストリーミングプレーヤは、固定品質インタフェース上で提供されるメディアコンテンツの表現プリファレンスインジケーションをＨＴＴＰエンティティから受信する。次に、受信された表現プリファレンスインジケーションが、固定品質インタフェース上で提供されるメディアコンテンツを要求するために使用される。
【００１９】
一実装では、メディアコンテンツをアダプティブＨＴＴＰストリーミングプレーヤに提供するように構成されたＨＴＴＰエンティティデバイスが提案される。前記ＨＴＴＰエンティティデバイスは、メディアコンテンツを要求しているＨＴＴＰストリーミングプレーヤからＨＴＴＰ要求を受信するように構成された受信器が存在する。さらに、固定品質インタフェース上で提供されるコンテンツとしてメディアコンテンツを識別するように構成された識別器を備えている。さらに、ＨＴＴＰエンティティデバイスは、固定品質インタフェース上で提供されるメディアコンテンツの表現プリファレンスインジケーションを判定するように構成されたプロセッサと、表現プリファレンスインジケーションをＨＴＴＰストリーミングプレーヤにシグナリングするように構成された送信器とを備えている。
【００２０】
別の実施形態では、メディアコンテンツを提供するように構成されたアダプティブＨＴＴＰストリーミングプレーヤデバイスが提供される。前記ＨＴＴＰストリーミングプレーヤデバイスは、メディアコンテンツの提供のＨＴＴＰ要求をＨＴＴＰエンティティへ送信するように構成された送信器を備えている。さらに、固定品質インタフェース上で提供されるメディアコンテンツを受信するため、ＨＴＴＰエンティティから表現プリファレンスインジケーションを受信するように構成された受信器と、固定品質インタフェース上で提供されるメディアコンテンツを要求するため、受信された表現プリファレンスインジケーションを使用するように構成されたプロセッサとが存在する。
【００２１】
別の実施形態では、アダプティブＨＴＴＰストリーミングプレーヤデバイスとＨＴＴＰエンティティとを備え、メディアコンテンツを提供するように構成されたクライアントデバイスが提案される。
【００２２】
また、各デバイスノードは、対応するノード内で行われることになる対応する方法に関して、請求されたすべてのステップを行うように構成される。
【図面の簡単な説明】
【００２３】
以下で本発明について、図面内に示す例示的な実施形態を参照しながら更に説明する。
【図１】アダプティブＨＴＴＰストリーミングクライアント上でセグメントをフェッチするための一実施形態を示す図である。
【図２】一実施形態によるプロキシエンティティにおける方法のフローチャートである。
【図３】一実施形態によるアダプティブＨＴＴＰストリーミングプレーヤにおける方法のフローチャートである。
【図４】一実施形態によるプロキシエンティティを略示する図である。
【図５】一実施形態によるアダプティブＨＴＴＰストリーミングプレーヤを略示する図である。
【図６】一実施形態による方法のシステムを示す図である。
【図７】一実施形態によるシステムを略示する図である。
【図８】一実施形態によるシステムを略示する図である。
【図９】一実施形態によるシステムを略示する図である。
【図１０】一実施形態によるシステムを略示する図である。
【図１１】一実施形態によるメッセージ交換を略示する図である。
【発明を実施するための形態】
【００２４】
以下の記述では、本発明の十分な理解を提供するために、限定ではなく説明を目的として、例えば具体的なネットワーク環境や通信標準等の特定の詳細が記述されている。当業者には明らかであろうが、本発明は、これらの特定の詳細から逸脱した他の実施形態において実施されうる。例えば、熟練した技術者であれば、本発明がＵＭＴＳ、ＧＳＭ（登録商標）またはＬＴＥネットワークのようないかなるワイヤレスネットワークを使っても実施されうることを理解するであろう。別の例として、本発明は、ＷＬＡＮシステムまたはＢｌｕｅｔｏｏｔｈ（登録商標）システムのような短距離ワイヤレスネットワークにおいて、あるいは、有線ネットワークにおいて、例えばＩＭＳネットワークのようないずれかのＩＰネットワークにおいても、実装されうる。
【００２５】
本発明は、いくつかの（ＴＶ）ブロードキャストネットワークを使って、あるいは、（ＴＶ）ブロードキャストネットワークとモバイルネットワークとを含むハイブリッドネットワーク、例えばＤＶＢ−Ｈ（Ｄｉｇｉｔａｌ  Ｖｉｄｅｏ  Ｂｒｏａｄｃａｓｔ−Ｈａｎｄｈｅｌｄｓ）と３ＧＰＰモバイルネットワークとを使って、実施することができる。基本的に、本発明は、ビデオコンテンツが配信されうるいずれかのネットワーク環境の範囲内で実施することができる。
【００２６】
メディアデータには、ビデオデータ、音声データ、またはいずれかの他の種類の（マルチ）メディアデータ、例えば、ビデオデータと音声データとの組み合わせ等が含まれうる。コンテンツは、モバイルＴＶまたはＩＰＴＶサービスのようなマルチメディアサービスの枠組みの範囲内で提供されてもよい。下記において、マルチメディアデータ、コンテンツ、コンテンツデータという用語は、類義語として用いられる。一般に、メディアセグメントには、例えばビデオクリップのような一連のメディアセグメントの形のメディアデータが含まれると言ってよいだろう。
【００２７】
ＨＴＴＰエンティティは、ＨＴＴＰプロキシ、ＨＴＴＰサーバ、ＨＴＴＰプロキシキャッシュ等のような、プロキシ機能性を提供するいずれかのデバイスであってもよいだろうが、ここではこれらの用語は、以下の記述の中で代替的に用いられる。下記において、ＨＴＴＰという用語が用いられる場合、それを何かの限定としてではなく、プロキシエンティティの見込まれる一実施形態と考えるべきである。さらに、下記において、拡張ＨＴＴＰプロキシもしくはサーバという用語は、ＨＴＴＰエンティティの一実施形態として用いられる。ＨＴＴＰエンティティは、本記述による機能性によって拡張される。
【００２８】
ＨＴＴＰストリーミングプレーヤとは、受信されたストリーミングデータをユーザに提供するように構成された、クライアント側のプレーヤである。一実施形態では、ＨＴＴＰストリーミングプレーヤはＤＡＳＨプレーヤであること、特に、ＭＰＥＧ−ＤＡＳＨプレーヤであることが提案される。好ましくは、ＨＴＴＰストリーミングプレーヤは、メディアデータもしくはメディアコンテンツの受信速度を利用可能な無線リンク速度に適合させるように構成されたアダプティブＨＴＴＰストリーミングプレーヤである。従って、アダプティブクライアントは、利用可能なデータ品質のために最適な送信ビットレートを見つけることを目的として、無線品質についての測定を行う。
【００２９】
その他のアダプティブＨＴＴＰストリーミングの枠組み、例えばＡｐｐｌｅ  ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇも同様にサポートされうる。
【００３０】
クライアントは、いずれかのエンドデバイスまたはユーザ装置であってもよいだろう。一実施形態では、クライアントは、ＤＡＳＨプレーヤおよびＨＴＴＰエンティティのようなアダプティブＨＴＴＰストリーミングプレーヤを備えており、それらはいずれも、例えばモバイル装置のような、同一のデバイスの中に位置している。別の実施形態では、ＨＴＴＰストリーミングプレーヤとＨＴＴＰエンティティとが、別個のデバイスの中に配置されることが提案される。ＨＴＴＰストリーミングプレーヤは、モバイル環境の中に位置していてもよく、ＨＴＴＰエンティティは、例えば（ホーム）ゲートウェイの中に置かれた、別個のプロキシエンティティの中に位置していてもよい。
【００３１】
固定品質インタフェースは、固定されたデータ品質を持つデータを提供するいずれかのインタフェースであってもよい。一実施形態では、例えばｅＭＢＭＳ上でブロードキャストされるデータを提供することが提案される。別の実施形態では、データが、好適な品質でキャッシュに格納される。ユニキャストインタフェースとは対照的に、前記データを受信する間に、メディアコンテンツの品質または表現に関する変更は行われない。従って、端末がブロードキャスト送信のカバレッジの範囲内にある場合かまたは要求されたデータがキャッシュされる場合には、アダプティブＨＴＴＰストリーミングプレーヤは、ブロードキャストまたはキャッシュ表現のセグメントを消費するのであって、ユニキャストインタフェース上で入手可能なメディアデータを受信する場合はそうである他の表現に変更するか否かという、測定を定期的に行う必要がないことが提案される。従って、固定品質インタフェースとは、クライアントが品質を決めるのではなくて、ネットワークが、セグメントを所与の固定品質で提供するか、あるいは、セグメントが、例えば他のストリーミングセッションから受信されたキャッシュであって固定品質で入手可能なキャッシュから入手可能であることを意味する。
【００３２】
要約すると、シナリオによっては、ＤＡＳＨプレーヤは、提示された好適な表現のうちでいくつかのサブセットだけを用いるべきであることが提案される。例えば、移動電話のＤＡＳＨプレーヤが、モバイルブロードキャストカバレッジの範囲内にある場合には、ＤＡＳＨプレーヤは、ブロードキャストされた表現（典型的には単一品質のみ）を選好しなければならないのであり、なぜなら、他の表現を用いると、データ送信中にデータの表現が変化するという事実を特徴とするユニキャストインタフェース上で入手可能なメディアデータの使用が強制され、ユニキャストインタフェース経由の不要な測定または送信につながる恐れがあるからである。
【００３３】
固定されたデータ品質で送信されるメディアデータを提供するための実施形態としてのブロードキャストの場合、クライアントはメディア表現を変更するべきでなく、クライアントは現行エリアでブロードキャストされているメディア品質を消費すべきであることが提案される。本明細書では、クライアントは、エリアに応じて異なった品質の表現を受信することが可能であることに言及することがある。すなわち、最終的に用いられる表現はユーザ装置の地理的位置に依存する可能性があり、例えば、ブロードキャスト受信が可能であるか否か、ブロードキャストにどの表現を用いるのかということに依存するのである。
【００３４】
ＩＥＴＦ  ＦＬＵＴＥプロトコル（ＲＦＣ３９２６）は、ブロードキャスト送信を介したファイル配信に使用される。ＦＬＵＴＥ配信セッションは、ＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）ファイルによって定義されており、このＳＤＰファイルは、ブロードキャストされるコンテンツの配信に必要なパラメータ、例えばＩＰマルチキャストアドレス、ＩＰバージョン（ＩＰｖ６またはＩＰｖ４）、受信ＵＤＰポート、ＦＬＵＴＥのようなプロトコル、発信者ＩＰアドレス等を含んでおり、また、クライアントがモバイルファイルブロードキャスト配信を受信できるようにするため、ＭＢＭＳ用のＴｅｍｐｏｒａｒｙ  Ｍｏｂｉｌｅ  Ｇｒｏｕｐ  Ｉｄｅｎｔｉｔｙ（ＴＭＧＩ）も含んでいる。
【００３５】
新たなサービスおよびアプリケーションが提供される場合には、対応するサービスアナウンス属性や記述ファイルが生成され、例えば、ユーザサービス記述（ＵＳＤ）または対応するセッション記述プロトコル（ＳＤＰ）あるいは対応するメディアプレゼンテーション記述（ＭＰＤ）が生成される。ＵＳＤファイルは、ＳＤＰおよびＭＰＤの親フラグメントであり、ＭＢＭＳ  Ｕｓｅｒ  Ｓｅｒｖｉｃｅｓ（３ＧＰＰ  ＴＳ２６．３４６Ｒｅｌ−１１）についての追加のサービスパラメータを含んでいる。
【００３６】
ＤＡＳＨは、マルチメディアデータの提供に用いられるプロトコルである。前記データは、ブロードキャスト送信の場合にＦＬＵＴＥを介して提供することができる。ＤＡＳＨプロトコルは、ＭＰＤファイルを定義するものであって、ＭＰＤファイルは、要求されてＤＡＳＨプレーヤに提供されることになるメディアコンテンツのセグメントＵＲＩ（または、一般に、セグメントを要求するやり方に関する情報）を含んでいる。
【００３７】
以下で、ＨＴＴＰエンティティで行われることになるステップと共にフローチャートを示す図２に関して、本発明の一実施形態を提示する。
【００３８】
ステップＳ２１でＨＴＴＰエンティティが、メディアコンテンツの提供に関するＨＴＴＰ要求を受信する。前記要求は、アダプティブＨＴＴＰストリーミングプレーヤから受信される。各ＨＴＴＰ要求は、その後のメディアセグメントをフェッチするためのメディアセグメントＵＲＩを含んでいる。
【００３９】
ステップＳ２２でＨＴＴＰエンティティが、アダプティブＨＴＴＰストリーミングプレーヤが要求しているコンテンツを、固定品質インタフェース上で入手可能なコンテンツとして識別する。これは、いずれかの適切かつ好適なやり方で実現することができる。
【００４０】
一実施形態では、ＨＴＴＰエンティティの中の利用可能なサービスアナウンス・フラグメント（ＳＤＰファイルを含む）を確認して、ＨＴＴＰ要求により受信されるメディアセグメントに対応するＳＤＰファイルを見つけることが提案される。要求の中のメディアセグメントＵＲＩは、そのＵＳＤおよび対応するＳＤＰおよびＭＰＤによって記述される、進行中のｅＭＢＭＳセッションに対応することがある。
【００４１】
本明細書では、ｅＭＢＭＳがデータのトランスポートにＩＰマルチキャストを使用することに留意されたい。ｅＭＢＭＳプロトコルは、モバイル環境に関して定義されている。しかし、固定接続のシナリオに関しては、受信器は、ＩＰマルチキャストストリーム経由でＦＬＵＴＥだけを受信する。次いで、恐らく、ＩＰマルチキャストストリームを受信するのに必要なパラメータを含む、サービスアナウンスを持つＳＤＰファイルだけが与えられる。
【００４２】
ＨＴＴＰ要求の中の要求ＵＲＩは、各セグメントおよび各表現によって変化する。ＵＲＩは、要求毎に異なり、その結果、ＵＲＩは異なったセグメント番号を含んでおり、それらが、セグメントの実行中のインデックスに起因して変化し、各ＵＲＩも、異なった品質表現を有する可能性がある。ＨＴＴＰエンティティは、対応するＳＤＰを、受信されたＵＲＩから導出することが提案される。ＳＤＰにより特徴付けられるセッションが固定インタフェース上で利用可能なのかどうかを見つけることを目的として、利用可能なサービス・アナウンス・ファイルへの対応する関連付けが行われる（例えば、受信されたＨＴＴＰ要求によるＵＲＩが、いずれかの利用可能なＭＰＤから生成されうるのかという確認）。
【００４３】
一実施形態では、好ましくはＨＴＴＰプロキシとアダプティブＨＴＴＰストリーミングプレーヤとが同じクライアントデバイスの中に位置している場合、ＨＴＴＰエンティティがＭＰＤファイルだけでなくＳＤＰファイルもセッションの開始時に、例えばサービスアナウンスを使って、受信することが提案される。また、サービスアナウンスは、前記ＭＰＤファイルとＳＤＰファイルとの間の関連付けも提供する。ＨＴＴＰエンティティは、ＭＰＤを入手するが、これは、ＭＢＭＳサービスについてＳＤＰとリンクされる。従って、ＨＴＴＰ要求を受信した時点で、ＨＴＴＰエンティティは、対応するＭＰＤが利用可能かどうかを、受信されたＵＲＩに基づいて確認し、その後次のステップで、対応するＳＤＰを見つける。
【００４４】
別の実施形態では、ＨＴＴＰ要求は、対応するＳＤＰファイルについてのコンテンツ識別子を含んでいてもよい。このソリューションは、ＨＴＴＰエンティティが別個のノードの中に、例えばゲートウェイの中に位置している場合に好適でありうる。コンテンツ識別子は、ＭＰＤファイルの中に含まれるかまたはＭＰＤファイルから導出されてもよい。例えば、コンテンツ識別子は、セッションの開始時に、提供されたＭＰＤメッセージの中に含まれていてもよく、ＵＲＩに加えて別のメディアセグメントを要求することによって、使用されることになる。コンテンツ識別子は、ＴＳ２６．２４７Ｒｅｌ−１１に定義されているようにＭＰＤ＠Ｉｄフィールドであってもよい。この場合、クライアントは、関連のＳＤＰファイルについてＨＴＴＰの中でコンテンツ識別子を明示的にシグナリングする。
【００４５】
ＤＡＳＨプレーヤは、特定のコンテンツ識別子をＨＴＴＰヘッダとして各ＨＴＴＰ要求に追加してもよい。メディアプレゼンテーションが公開され、前記識別子がメディアセッションの間不変である限り、コンテンツ識別子は、コンテンツについての一意のインジケーションであることが提案される。それに反して、ＨＴＴＰ要求の中の要求ＵＲＩは、各セグメントおよび各表現とともに変化する。コンテンツ識別子によって、ＨＴＴＰエンティティは、恐らく異なった品質の、そのコンテンツを別のかたちで受信する可能性を効率よく見つけることができる。本実施形態の利点は、提供されることになるメディアコンテンツを、ＨＴＴＰプロキシが早く認識できることであり、ＨＴＴＰエンティティがコンテンツ識別子に関してＨＴＴＰヘッダを確認することによって、対応するＳＤＰを最初に探さなくてもよいことになる。
【００４６】
従って、コンテンツを固定インタフェース上で利用可能なコンテンツとして識別するために、ＨＴＴＰエンティティが、ＳＤＰ、ＵＳＤまたはＭＰＤ（すなわち、サービス・アナウンス・フラグメンツ）を確認することによって、どのＳＤＰファイルがコンテンツ識別子と関連しているのかを調べることが提案される。
【００４７】
別の実施形態では、ＨＴＴＰエンティティは最初に、必要な対応するＳＤＰファイルを（場合によっては、他のサービス・アナウンス・ファイルとともに）、ＨＴＴＰ要求からの情報に基づいてサーバからダウンロードする必要がありうることが提案される。ＨＴＴＰエンティティは、コンテンツ識別子に基づいて、あるいはＵＲＩに基づいてＳＤＰファイル（および、受信を起動させるための他のフラグメント）を見つけることができ、従って、ＨＴＴＰプロキシは、ＳＤＰやＵＳＤのような必要なファイルをサーバからダウンロードできる可能性がある。
【００４８】
一実施形態では、固定品質インタフェース経由でのコンテンツデータの提供が可能かどうかを確認することが提案される。すなわち、最終的に用いられる表現は、例えばブロードキャスト受信が可能か否か、あるいはブロードキャストにどの表現を用いるかといった、ユーザ装置の地理的位置に依存する可能性がある。確認のステップは、現在位置においてｅＭＢＭＳの受信が可能かどうか確認することを含んでいてもよい。すなわち、デバイスによっては、またエンドデバイスの位置によっては、常にＭＢＭＳデータを受信できるとは限らない。また、ステップは、ＩＰマルチキャストストリームの受信が可能かどうか確認することを含んでいてもよい。ＳＤＰファイルは、ＩＰマルチキャストアドレスとＦＬＵＴＥのためのＵＤＰポートとを記述する。従って、ＦＬＵＴＥのためのアクティブなＵＤＰポートがＩＰマルチキャストアドレスと一緒に記述される場合には、ＩＰマルチキャストリンク経由でのコンテンツデータの受信は可能であり、しかも好適である。
【００４９】
別の実施形態では、識別するステップは、固定品質を備えたメディアコンテンツがキャッシュ内で入手可能かどうか判定することを含んでいる。データがキャッシュ内にある場合、ＨＴＴＰエンティティは、固定品質を有する入手可能なデータを取得して、データを要求するのに好適な品質として前記品質を使用することが提案される。ＨＴＴＰエンティティは、ＵＲＩを照合することによって、あるいはコンテンツ識別子を照合することによって、キャッシュ内のセグメントを見つけることができる。
【００５０】
ステップＳ２３では、ＨＴＴＰエンティティが、固定品質インタフェース上で提供されるコンテンツの表現プリファレンスインジケーションを判定する。これは、いずれかの適切かつ好適なやり方で実現されてよい。一実施形態では、ＳＤＰファイルから表現プリファレンスインジケーションを導出することが提案される。ＨＴＴＰエンティティがＳＤＰファイルにアクセスできる場合、ＨＴＴＰエンティティは、ＳＤＰファイルを取得して表現プリファレンスインジケータを導出することを選好してもよい。ＳＤＰファイルは、データ送信用に用いられる品質についてのインジケーションを含んでいてもよい。
【００５１】
あるいは、ＨＴＴＰエンティティは、表現プリファレンスインジケータの値を、ＭＢＭＳユーザサービス記述の中かまたは対応するＩＰマルチキャストサービスの中に含まれる、ＳＤＰファイル内のパラメータとして見つけてもよいのだから、ＳＤＰファイルのパラメータは、コンテンツ受信のためにＦＬＵＴＥセッションの中で記述されるＳＤＰパラメータの１つに値として加えられなければならないということになる。ｅＭＢＭＳ  ＵＳＤがＭＰＤを記述する場合、ブロードキャストされる表現もその中に含まれるのだから、好適な表現を導出するのは容易である。
【００５２】
別の実施形態では、ＨＴＴＰエンティティは、使用されるメディアコンテンツのＭＰＤにアクセスできてもよい。これは、ＨＴＴＰエンティティがＭＰＤファイルとＳＤＰファイルとの間の直接の関連付けを有する場合である。この場合、表現プリファレンスインジケータの値を、表現インジケータを含むＭＰＤから導出することが提案される。
【００５３】
また、判定ステップは、表現プリファレンスインジケーションの適切なプレゼンテーションの判定を含む。これは、好ましくは判定ステップＳ２３で行われてよいが、Ｓ２４のシグナリングより前のいずれかの適切な段階で行われてもよい。インジケーションは、いずれかの適切かつ好適なやり方でフォーマットされてよい。一実施形態では、品質のインジケーションについて、数値または文字列表現を使用することが提案される。また、インジケーションは、多数のプリファレンスインジケーションのうちのサブセットであってもよいだろう。例えば、ビデオの場合、データ品質のインジケーションは、音声データの場合とは異なることがある。
【００５４】
ステップＳ２４では、判定された表現プリファレンスインジケーションがＨＴＴＰストリーミングプレーヤへとシグナリングされて、アダプティブＨＴＴＰストリーミングプレーヤに測定を止めさせ、固定品質インタフェースを通して入手可能なコンテンツセグメントを要求させる。
【００５５】
任意で、プロキシ７０２は、プロキシがユニキャストを使用することをまったく望まない場合、４０４−ｆｉｌｅ−ｎｏｔ−ｆｏｕｎｄエラーヘッダを持つＨＴＴＰ応答エラーメッセージを提供する。
【００５６】
その後の手順では、固定品質インタフェースを通して提供されるセグメントを求めるその後の要求が受信され、応答としてＨＴＴＰストリーミングプレーヤに提供される。
【００５７】
表現プリファレンスインジケータは、いずれかの適切かつ好適なやり方で提供されてよい。一実施形態では、ＨＴＴＰ応答の中でＨＴＴＰヘッダとしてインジケーションを提供することが提案されるが、ここで、ヘッダ内には、所定の表現もしくは表現の一部分が含まれる。ＨＴＴＰエンティティは、これをいずれかのその後の応答に加えてもよい。表現プリファレンスインジケータは、１つ以上の表現をポイントしてもよい。音声とビデオとが別個の表現として提供される場合には、表現プリファレンスインジケーションが、両方の表現を直接または間接的にポイントしてもよい。
【００５８】
表現をポイントする代わりに、プリファレンスインジケータが、１つ以上の表現を含むアダプテーションのセットをポイントし、いわゆるアダプテーション・セット・プリファレンス・インジケータを形成してもよい。手順の観点からは、表現が示されていてもアダプテーションセットが示されていても、違いはない。
【００５９】
別の実施形態では、ある期間内では、その同じ期間内において表現が別の表現と機能的に同一でない限り、表現識別子が一意であることが提案される。従って、表現プリファレンスインジケータは、送信期間毎に変わることがあり、ここでその期間は、マニフェストファイルの中で定義される。ＨＴＴＰエンティティは、各応答メッセージに表現プリファレンスインジケータを加えることが好ましい。
【００６０】
以下で、アダプティブＨＴＴＰストリーミングプレーヤで行われることになるステップと共にフローチャートを示す図３に関して、本発明の一実施形態を提示する。
【００６１】
ステップＳ３１で、ＨＴＴＰストリーミングプレーヤが、メディアコンテンツの提供を求めるＨＴＴＰ要求をＨＴＴＰエンティティへ送信する。
【００６２】
従って、好適なソリューションでは、ＨＴＴＰ要求は、受信されたＭＰＤファイルによる要求を含んでおり、特に、次のメディアセグメントのＵＲＩを含んでいる。ＭＰＤセグメントのＵＲＩを持つＭＰＤファイルがＨＴＴＰストリーミングプレーヤに提供され、ブロードキャスト送信の場合、前記ＭＰＤファイルがブロードキャストされ、ユニキャスト接続の場合、前記ＭＰＤファイルが、以前に送信された対応する要求への応答として提供される。
【００６３】
ステップＳ３２では、ＨＴＴＰストリーミングプレーヤが、固定品質インタフェース上で提供されているコンテンツの受信のため、ＨＴＴＰエンティティから表現プリファレンスインジケーションを受信する。
【００６４】
表現プリファレンスインジケーションが、各ＨＴＴＰ応答に追加されるが、それは、進行中のストリーミングセッションの間に変化する可能性がある。例えば、電話が、ブロードキャストカバレッジに入ったり出たりすることがあるため、セッションの間にブロードキャスト受信が出来たり出来なかったりすることがありうる。また、ブロードキャスト送信は、いかなる時点でも始められたり終了されたりすることがある。従って、ＨＴＴＰストリーミングプレーヤは、ＨＴＴＰ応答の中の受信された表現プリファレンスを連続的に確認するべきである。
【００６５】
ステップＳ３３では、コンテンツを要求するため、受信された表現プリファレンスインジケーションが使用される。表現は、好適な表現であるとすでに判定されており、クライアントは、固定品質インタフェース上で入手可能な代替表現に切り換えるように指示される。従って、ＨＴＴＰストリーミングプレーヤは、表現プリファレンスインジケーションを受信した時点で、ユニキャストインタフェース上で提供されるデータのリンク品質における何らかの変化の測定を中止する。
【００６６】
図４は、上記の概念をＨＴＴＰエンティティ４１に実装するための例示的な構造を略示する図である。ＨＴＴＰエンティティ４１は、固定されたデータ品質を持つマルチメディアデータもしくはメディアコンテンツをＨＴＴＰストリーミングプレーヤに提供するように構成される。ＨＴＴＰエンティティ４１は、固定されたデータ品質を持つデータを受信するための固定品質インタフェース４２を備えている。好適な一実施形態では、前記インタフェースは、ブロードキャストもしくはＩＰマルチキャストを介してメディアセグメントを受信するように構成されたブロードキャストインタフェースである。しかし、この固定品質インタフェースは、キャッシュ内で入手可能であるデータを提供するようにも構成される。さらに、ユニキャストＨＴＴＰサーバからメディアコンテンツをフェッチするように構成されたユニキャストインタフェース４３も備えており、データ提供の間に変化する可変データ品質を持つデータをユニキャスト接続経由で受信する。
【００６７】
ＨＴＴＰエンティティは、メディアコンテンツを提供するためにＨＴＴＰストリーミングプレーヤからＨＴＴＰ要求を受信するように構成された受信器４６を備えている。また、ＨＴＴＰエンティティは、ＨＴＴＰストリーミングプレーヤが要求するコンテンツを、固定品質インタフェース上で提供されるコンテンツとして識別するように構成された識別器４４を備えている。また、ＨＴＴＰエンティティは、固定品質インタフェース上で提供されるコンテンツの表現プリファレンスインジケーションを判定するように構成されたプロセッサ４５を備えている。また、プロセッサは、ユニキャストインタフェース上で入手可能であり、かつ、好適であるとして、コンテンツを識別するように構成されている。
【００６８】
ＨＴＴＰエンティティは、メディアコンテンツを提供するためにＨＴＴＰストリーミングプレーヤからのＨＴＴＰ要求に応答し、かつ、表現プリファレンスインジケーションをＨＴＴＰストリーミングプレーヤにシグナリングするように構成された送信器４７を備えている。
【００６９】
図５は、上記の概念をアダプティブＨＴＴＰストリーミングプレーヤ５１に実装するための例示的な構造を略示する図である。前記ＨＴＴＰストリーミングプレーヤは、受信されたマルチメディアデータまたはメディアコンテンツをユーザに提示するように構成されている。ＨＴＴＰストリーミングプレーヤは、ＨＴＴＰエンティティに対してメディアコンテンツの提供のＨＴＴＰ要求を送信するように構成されたＨＴＴＰエンティティ送信器５２を備えている。また、ＨＴＴＰストリーミングプレーヤは、固定品質インタフェース上で提供されるコンテンツを受信するために、表現プリファレンスインジケーションをＨＴＴＰエンティティから受信するように構成されたＨＴＴＰエンティティ受信器５３を備えている。また、ＨＴＴＰストリーミングプレーヤは、受信された表現プリファレンスインジケーションをコンテンツを要求するために使用し、かつ、引き続きリンク速度の測定を制御するように構成されたプロセッサ５４を備えている。ＨＴＴＰストリーミングプレーヤは、固定のインタフェースまたはユニキャストインタフェース上でコンテンツが入手可能かどうかを知らないが、しかし、その後の要求については受信された表現プリファレンスインジケーションを使用する。
【００７０】
図６は、本発明の一実施形態を応用するシステムの一実施形態を描いた図である。
【００７１】
図６により、受信されたＤＡＳＨ  ＭＰＤ６０１を処理するクライアント６００が、ＨＴＴＰプロキシ／キャッシュ（ＨＴＴＰエンティティ）６０２と一般的なＤＡＳＨプレーヤ（ＨＴＴＰストリーミングプレーヤ）６０３とに細分化されることが提案される。ＤＡＳＨプレーヤは、ＤＡＳＨメディアストリームを記述するＭＰＤを受信する。ＭＰＤは、ユニキャストを介して、例えばブロードキャスト上の電子サービスガイド（Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ：ＥＳＧ）のようなサービス・アナウンス・チャネルを介して、あるいはいずれかの他の手段を介して、受信することができる。ＤＡＳＨプレーヤは、ＭＰＤを処理し、ＭＰＤ定義ランキングに従って第１の表現を選択する。ブロードキャスト受信器６０４（ＨＴＴＰプロキシの一部）が、例えばＦＬＵＴＥのようなブロードキャストプロトコルを処理して、ブロードキャストセグメント６０７の受信を管理する。また、ＨＴＴＰプロキシ／キャッシュ６０２は、セグメントキャッシュ６０５を実装してもよい。キャッシュ６０５は、ブロードキャスト受信器をセグメントのソースとして使用するが、ブロードキャスト受信器がセグメントをまったく提供しない場合にはユニキャストを使用することがある。ユニキャスト受信器６０６（ＨＴＴＰプロキシの一部）は、ＨＴＴＰ／Ｕｎｉｃａｓｔのようなユニキャストプロトコルを処理し、ユニキャストセグメント６０８の受信を管理する。ブロードキャストセグメントはＢＭ−ＳＣ６０９によって提供され、ユニキャストセグメントはＷＷＷウェブサーバ６１０によって提供される。従って、セグメントは、ライブエンコーダおよびセグメンタ６１１によって生成される。
【００７２】
図７は、本発明の一実施形態を導入するアーキテクチャを示す図である。
【００７３】
図７の実施形態におけるアーキテクチャは、ＤＡＳＨプレーヤ７０１を含んでいる。ＤＡＳＨプレーヤ７０１は、マニフェストファイルＭＰＤを処理しており、ＨＴＴＰ  ＧＥＴまたは、一般的に前記ＨＴＴＰ要求７１を用いて、所定の表現のメディアセグメントを要求するように構成されている。ＨＴＴＰエンティティの一例である拡張ＨＴＴＰプロキシ７０２は、要求された品質の表現のメディアセグメントをＨＴＴＰ応答７２の形で提供することによって、要求に応答する。拡張ＨＴＴＰプロキシ７０２は、所定の音声表現およびビデオ表現の明確な選好（プリファレンス）を、例えば表現のサブセットとして有する。選好は、受信のやり方によって確立されることが好ましい。拡張ＨＴＴＰプロキシは、ブロードキャストを介してコンテンツをブロードキャストサーバ７０５から受信してもよいし、キャッシュ７０３からのコンテンツを提供してもよい。これらの場合、コンテンツがブロードキャストを介してかまたはキャッシュから入手できる場合、前記コンテンツは好適とされるべきである。従って、これらの場合、拡張ＨＴＴＰプロキシ７０２は、表現の所定のサブセットを示す新たなインジケーションを、例えばＨＴＴＰヘッダとしてＨＴＴＰ応答７２に追加する。前記インジケーションは、例えばＳＤＰファイル７３から判定されることになる。ＤＡＳＨプレーヤ７０１が、ＨＴＴＰ応答と共にプリファレンスインジケーションを受信する場合には、ＤＡＳＨプレーヤは、それ自身の品質アダプテーションアルゴリズムを変えて、たとえより高い品質が可能にみえる場合であっても、好適な表現にとどまってもよい。例えば、ＭＰＤが、３つの異なる品質表現である低品質（ＬＱ）、中位品質（ＭＱ）、高品質（ＨＱ）を記述しているとする。ＤＡＳＨプレーヤ７０１は、ＬＱ表現を要求することを決定し、ＬＱ表現ＵＲＩを持つＨＴＴＰ要求７１をプロキシへ送信する。拡張ＨＴＴＰプロキシ７０２は、中位品質がブロードキャストを介して提供されているため、中位品質（ＭＱ）についての明確な選好を有する。従って、プロキシ７０２は、ＬＱセグメントを使ってＨＴＴＰ要求に応答し、ＭＱ表現を選好するというインジケーションをＨＴＴＰ応答７２に追加する。任意で、プロキシ７０２は、ユニキャストをまったく用いたくない場合、４０４−ｆｉｌｅ−ｎｏｔ−ｆｏｕｎｄエラーヘッダを持つＨＴＴＰ応答エラーメッセージを提供する。
【００７４】
ＨＴＴＰプロキシ７０２は、キャッシュ７０３と、ブロードキャスト受信インタフェース７０８と、ユニキャスト受信インタフェース７０９とを有する可能性がある。ブロードキャスト送信器７０５は、ＩＥＴＦ  ＦＬＵＴＥプロトコルを用いてメディアセグメントをブロードキャスト経由で送信し、例えば、ＩＰマルチキャストまたはｅＭＢＭＳを用いてポイント・ツー・マルチポイント配信が行われてもよい。ユニキャストが用いられる場合には、ユニキャストサーバＷＷＷ７０４からＨＴＴＰプロトコルを用いてメディアセグメントがフェッチされる。
【００７５】
ＤＡＳＨソース７０６が、メディアセグメントの形でＤＡＳＨメディアコンテンツをブロードキャスト送信器７０５およびユニキャストサーバ７０４に提供する。図１１では、アップロード／ＷｅｂＤＡＶを、コンテンツ提供の一例として示す。
【００７６】
ブロードキャスト送信器７０５は、ブロードキャストのためにサブセット（例えば中位品質の表現）だけを提供する。ユニキャストサーバは、より広範囲の品質表現（例えば、ＬＱ、ＭＱおよびＨＱ）を提供する。表現プリファレンスインジケーションが、各ＨＴＴＰ応答７２に追加されるが、それは、進行中のストリーミングセッションの間に変化する可能性がある。例えば、電話が、ブロードキャストカバレッジに入ったり出たりすることがあるため、セッションの間にブロードキャスト受信が出来たり出来なかったりすることがありうる。また、ブロードキャスト送信は、いかなる時点でも始められたり終了されたりすることがある。従って、ＤＡＳＨプレーヤは、ＨＴＴＰ応答の中の表現プリファレンスインジケータの存在および値を連続的に確認すべきである。
【００７７】
以下に、本発明を実装するアーキテクチャの一実施形態を、図８に関して提示する。
【００７８】
それによれば、ＨＴＴＰエンティティ８０２とＤＡＳＨプレーヤ８０１とが、例えば移動電話８００のような同一デバイス上に配置される。ＤＡＳＨプレーヤ８０１と拡張ＨＴＴＰプロキシ８０２との間のローカルループのインタフェース経由で、ＨＴＴＰプロトコル（図８のＨＴＴＰ要求、ＨＴＴＰ応答）が用いられる。拡張ＨＴＴＰプロキシ８０２は、例えばｅＭＢＭＳを用いてブロードキャストインタフェース８０７を介してブロードキャストを受信してもよい。ユニキャストは、ユニキャストインタフェース８０８経由で受信されることになる。さらに、両方のインタフェースが、同一のモデムまたはデバイスの範囲内で実現されうることが提案される。
【００７９】
残りの手順は、図６および図７に関して記述した手順と同様である。特に、３ＧＰＰ  ＢＭ−ＳＣ８０５は、ブロードキャスト送信器８０５として動作し、本実施形態において、モバイルブロードキャストと、ｅＭＢＭＳに基づきうるＬＴＥ／ＥＰＣシステムのようなＭＢＢシステムとを適用することによって、ＦＬＵＴＥプロトコルを用いてメディアセグメントを配信する。ユニキャストが用いられる場合には、メディアセグメントは、ユニキャストＨＴＴＰサーバ（ＷＷＷ）８０４からＨＴＴＰプロトコルを用いてフェッチされる。ＤＡＳＨソース８０６が、ＤＡＳＨメディアセグメントをブロードキャスト送信器８０５とユニキャストサーバ８０４とに提供する。また、固定品質を持つデータを提供するキャッシュ８０３があってもよい。
【００８０】
図９による別の実施形態では、ＤＡＳＨプレーヤ９０１と拡張ＨＴＴＰプロキシ９０２とが、別個のデバイスの中に配置される。例えば、ＤＡＳＨプレーヤ９０１は、セットトップボックス（ＳＴＢ）または電話またはタブレットまたはいずれかの他の適切なデバイス上に位置してもよい。拡張ＨＴＴＰプロキシ９０２は、ホームルータまたは３ＧＰＰ−Ｗｉｆｉゲートウェイまたはネットワーク・アタッチト・ストレージ（ＮＡＳ）のような（ホーム）ゲートウェイ上に配置されてもよい。また、ＨＴＴＰエンティティを、コンテンツ配信ネットワーク内かまたは、多数のエンドユーザにコンテンツを配信するように作用するコンテンツ配信ネットワーク（ＣＤＮ）サーバまたはプロキシ内に設置することが提案される。
【００８１】
図９に関する実施形態では、ＳＴＢが、例えばＷｉｆｉまたはケーブルを用いる（ホーム）ネットワークかまたはＨＴＴＰプロトコルをサポートするいずれかの適切なネットワークのような、いずれかの適切な接続を介して、ゲートウェイの中に位置するＨＴＴＰエンティティと通信してもよい。ゲートウェイは、ＩＰマルチキャストを用いてかまたはユニキャストを介してかいずれか一方によって、ＤＡＳＨメディアセグメントを受信してもよい。ゲートウェイの中のＨＴＴＰプロキシは、ゲートウェイがＤＳＬ接続を用いてアクセスネットワークに接続されている場合には、例えばＤＳＬネットワークのようなアクセスネットワークからＩＰマルチキャストを用いて受信されたこれらのメディアセグメントを選好するために、ＤＡＳＨプレーヤにプリファレンスを表明する。
【００８２】
残りの手順は、図６および図７に関して記述した手順と同様である。特に、ブロードキャスト送信器９０５は、例えば、固定接続を経由してマルチキャストデータを送信することによってＩＰＴＶ環境で用いられるＩＰマルチキャストを適用することによって、ＦＬＵＴＥプロトコルを用いてメディアセグメントを配信する。ユニキャストの場合、メディアセグメントが、ＨＴＴＰプロトコルを用いてユニキャストサーバ（ＷＷＷ）９０４からフェッチされる。ＤＡＳＨソース９０６が、ＤＡＳＨメディアセグメントをブロードキャスト送信器９０５およびユニキャストサーバ９０４に提供する。
【００８３】
図１０による別の実施形態では、キャッシュ１０１３の中に所定の品質表現をすでに有している拡張ＨＴＴＰプロキシエンティティ１０１１によって、表現プリファレンスインジケーションが提供される。従って、データは、固定されたデータ品質で提供される。言い換えると、好適な表現とは、キャッシュ１０１３から提供される表現なのである。ＤＡＳＨプレーヤはキャッシュされたセグメントを求める要求を用いるわけだから、選好を表明することによってキャッシュ１０１３は、キャッシュされたコンテンツの再使用率を高めることになる。言い換えると、キャッシュは、以前のストリーミングセッションからの１つの表現をキャッシュ内に有していて、別のクライアントが、そのコンテンツの別の品質をフェッチすることを要求する場合には、ＨＴＴＰエンティティは、クライアントに指示して、すでにキャッシュ内にある品質を好適なものとして使用させる。
【００８４】
ブロードキャストインタフェースが欠けているためにブロードキャストデータが受信できないという理由で、その実施形態ではブロードキャスト受信が利用できないということがありうる。
【００８５】
図１０による実施形態では、ＤＡＳＨプレーヤ１０１１と拡張ＨＴＴＰプロキシ１０１２とは、別個のノードに位置している。しかし、両方のエンティティが同一ノードに位置している場合にも、同様の処理が提案される。
【００８６】
ユニキャストの場合、メディアセグメントは、ＨＴＴＰプロトコルを用いてユニキャストサーバ（ＷＷＷ）１０１４からフェッチされる。ＤＡＳＨソース１０１５は、ＤＡＳＨメディアセグメントを前記ユニキャストサーバ１０１４に提供する。
【００８７】
以下に、図１１による別の実施形態を記述する。
【００８８】
図１１は、ＤＡＳＨプレーヤ１１１１と拡張ＨＴＴＰプロキシ１１１２とユニキャストサーバ１１１３との間のメッセージの交換を示す図である。
【００８９】
ステップ１１０１では、ＤＡＳＨプレーヤが、ＤＡＳＨメディアストリームを記述しているＭＰＤファイルを受信する。ＭＰＤは、ユニキャストを介して、ブロードキャスト上でサービス・アナウンス・チャネル（ａｋａ  Ｅｌｅｃｔｒｏｎｉｃ  Ｓｅｒｖｉｃｅ  Ｇｕｉｄｅ（ＥＳＧ））を介して、あるいはいずれかの他の手段を介して受信されてよい。ＤＡＳＨプレーヤは、ＭＰＤを処理し、ＭＰＤ定義のランキングに従って第１の表現を選択する。ＤＡＳＨプレーヤは、第１のメディアセグメントをフェッチし始める。ＵＲＩ＜ＬＱ−ＵＲＩ＃Ｘ＞は、ＵＲＩの一例であり、ここで＃Ｘは、典型的には、要求されたセグメントの数を示す整数である。
【００９０】
ＤＡＳＨプレーヤは、代替受信の可能性を判定する一方で、対応するＳＤＰに対する要求の割当てを容易にすることを目的として、コンテンツ識別子「Ｃｏｎｔｅｎｔ−ＩＤ」ＨＴＴＰヘッダを要求に追加してもよい。しかし、ヘッダは任意であって、省略されてもよく、例えば拡張ＨＴＴＰプロキシは、ＭＰＤファイルから導出されるセグメントＵＲＩ＜ＬＱ−ＵＲＩ＃Ｘ＞に基づいて、メディアストリームについてのＳＤＰファイルを識別してもよい。
【００９１】
ステップ１１０２では、拡張ＨＴＴＰプロキシが、ＨＴＴＰ要求を受信して、好適な表現を判定する。
【００９２】
一実施形態では、拡張ＨＴＴＰプロキシがＳＤＰファイルを有しない場合、拡張ＨＴＴＰプロキシは、必要なＳＤＰファイルまたはＵＳＤファイルのようないずれかの他の適切なファイルをネットワークからフェッチすることを試行してもよい。これは、ＤＡＳＨプレーヤからＨＴＴＰ要求と共に受信した情報に基づいてもよい。
【００９３】
別の実施形態である１１０２Ａｌｔ  Ａでは、拡張ＨＴＴＰプロキシがｅＭＢＭＳ対応デバイス上に配置される場合には、拡張ＨＴＴＰプロキシは、自分自身の構造の中でＳＤＰファイルを探索し、自分がｅＭＢＭＳを現在位置で受信できるかどうかを確認する。デバイスおよびエンドデバイスの位置によっては、ＭＢＭＳデータを常に受信できるとは限らない。通常、デバイスは、自分自身のチップセットの中でＭＢＭＳの受信を起動して、ストリームを受信できるかどうか調べる必要がある。ｅＭＢＭＳ受信が可能である場合には、拡張ＨＴＴＰプロキシは、ＳＤＰで記述されたＭＢＭＳベアラを見つけることを試行する。これは、ＭＣＣＨチャネル上でＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ  Ｍｏｂｉｌｅ  Ｇｒｏｕｐ  Ｉｄｅｎｔｉｔｙ）の利用可能性を確認することによって行われる。ＴＭＧＩは、ＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ／Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）ベアラサービスを一意に識別する。グローバルに一意である１つのＴＭＧＩが、ＭＢＭＳベアラサービス毎にＢＭ−ＳＣ（Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ−Ｓｅｒｖｉｃｅ  Ｃｅｎｔｅｒ）によって割り当てられる。ＭＣＣＨ上の制御プレーン情報は、ＭＢＭＳ固有であり、起動された（加入した）ＭＢＭＳサービスを持つセルの中のＵＥへ送信される。従って、ＨＴＴＰエンティティは、ＳＤＰに属しているＴＭＧＩを見つけた場合には、ＳＤＰを用いてブロードキャスト受信が可能だということが分かる。
【００９４】
別の実施形態である１１０２Ａｌｔ  Ｂでは、拡張ＨＴＴＰプロキシもしくはサーバが、ホームゲートウェイのようなゲートウェイ上に配置されるならば、この場合、拡張ＨＴＴＰプロキシは、自分自身の構造の中でＳＤＰファイルを探索し、自分がＩＰマルチキャストストリームを受信できるかどうかを確認する。ＳＤＰファイルには、ＩＰマルチキャストアドレスと、ＦＬＵＴＥ用のＵＤＰポートとが記述されている。コンテンツは、上記のように、ＤＳＬアクセスネットワーク内でマルチキャストされてもよい。従って、ＩＰマルチキャストアドレスと一緒に記述されているＦＬＵＴＥ用のアクティブなＵＤＰポートが存在する場合には、ＩＰマルチキャストリンク経由のコンテンツデータの受信は可能であり、好適とされるべきである。
【００９５】
従って、ＭＰＤファイルから導出された情報かまたはコンテンツ識別子かのいずれかを含みうる受信されたＨＴＴＰ要求に基づいて、対応するＳＤＰファイルが判定され、次のステップで、例えばブロードキャストまたはＩＰマルチキャストを介して受信された固定品質を持つデータが、受信でき、かつ可能であるかどうかが確認される。
【００９６】
別の実施形態である１１０２Ａｌｔ  Ｃでは、拡張ＨＴＴＰプロキシ／サーバがいずれかのゲートウェイまたはルータ上に配置される場合、要求されるメディアストリームのコンテンツが自分自身のキャッシュの中にあるかどうかを拡張ＨＴＴＰプロキシが調べることが提案される。この場合、前記データは、提供するのが好ましいとみなされる。
【００９７】
ステップ１１０３、Ａｌｔ  Ａでは、拡張ＨＴＴＰプロキシは、要求されたリソースを、Ｄａｓｈプレーヤから受信されたＵＲＩに従って発信元サーバ１１０４からフェッチして、それを前記ＤＡＳＨプレーヤへ転送する。図１１による実施形態では、ＤＡＳＨプレーヤは、ステップ１１０１のＨＴＴＰ  ＧＥＴ＜ＬＱ−ＵＲＩ＃Ｘ＜Ｃｏｎｔ−ＩＤ  Ｈｅａｄｅｒ＞で低品質ＬＱを要求した。要求の結果として、拡張ＨＴＴＰプロキシは、ＨＴＴＰ  ＧＥＴ＜ＬＱ−ＵＲＩ＃Ｘ＞１１０５を送信することによって、対応するメディアセグメントをユニキャストサーバ１１１３から要求する。その後、拡張ＨＴＴＰプロキシは、ＯＫ（ＬＱ−ＵＲＩ＃Ｘ）１１０６で低品質のデータを受信する。次に、ＤＡＳＨプレーヤも、拡張ＨＴＴＰプロキシから、ＯＫ（ＬＱ−ＵＲＩ＃Ｘ）１１０７で低品質ＬＱを受信する。加えて、表現プリファレンスインジケータ、この場合Ｐｒｅｆｅｒｅｎｃｅ−Ｉｎｄｉｃａｔｏｒ：Ｍｅｄｉｕｍ  Ｑｕａｌｉｔｙ（中位品質）が追加的に同封される。従って、プロキシがＩＰマルチキャストもしくはブロードキャストを介してコンテンツを受信できる場合には、拡張ＨＴＴＰプロキシは、表現プリファレンスインジケーションを応答であるＯＫ（ＬＱ−ＵＲＩ＃Ｘ）Ｐｒｅｆｅｒｅｎｃｅ−Ｉｎｄｉｃａｔｏｒ：Ｍｅｄｉｕｍ  Ｑｕａｌｉｔｙに追加する。拡張ＨＴＴＰプロキシは、これをその後のいずれの応答に追加してもよい。
【００９８】
ステップ１１０８、Ａｌｔ  Ｂでは、要求されたリソースをユニキャストを用いてフェッチすることを拡張ＨＴＴＰプロキシが望まない場合には、拡張ＨＴＴＰプロキシは、「４０４ｆｉｌｅ  ｎｏｔ  ｆｏｕｎｄ」エラーメッセージを使って応答し、エラーメッセージには表現プリファレンスインジケータ、この場合もＰｒｅｆｅｒｅｎｃｅ−Ｉｎｄｉｃａｔｏｒ：Ｍｅｄｉｕｍ  Ｑｕａｌｉｔｙ１１０９を追加することが提案される。このソリューションの場合、ＤＡＳＨプレーヤは、好適表現、この場合は中位、を使用するように強制される。
【００９９】
図１１に示していない別の代替的実施形態では、拡張ＨＴＴＰプロキシは、要求されたセグメントをキャッシュ内に有していてもよく、要求されたセグメントを表現プリファレンスと共にＤＡＳＨプレーヤ１１１１に提供する。
【０１００】
図１１のステップ１１１０では、ＤＡＳＨプレーヤは、拡張ＨＴＴＰプロキシがプリファレンス表現を提供できるように、表現プリファレンスインジケータに従ってその後のセグメントを要求する。好適なソリューションでは、ＤＡＳＨプレーヤは、デバイスがブロードキャストカバレッジ内にいる場合、ユニキャストを用いてメディアストリームをフェッチするのを中止することが提案される。拡張ＨＴＴＰプロキシは、表現プリファレンスインジケータを連続的に、ＤＡＳＨプレーヤに送信されるメッセージに追加する。この目的のため、拡張ＨＴＴＰプロキシは、ＩＰマルチキャストの受信条件またはブロードキャスト受信が変化するかどうかを、連続的に監視する。
【０１０１】
ＤＳＬアクセスシステム（ＩＰＴＶ）におけるＩＰマルチキャストでは、マルチメディアコンテンツを、非常に高品質な表現かまたはいずれかの固定品質の表現を選択した状態で、ある特定の一時に多くのセットトップボックスまたはホームゲートウェイデバイスに対して効率的に送信することができる。コンテンツは、いずれのホームデバイスからも利用できるようにされており、ＤＡＳＨクライアントは、好ましくは、ホームゲートウェイから入手可能なこれらのセグメントをフェッチすべきであって、オリジンサーバからそれ以外の表現をフェッチすべきではない。
【０１０２】
キャッシュを含むいずれかの配信システムでは、マルチメディアコンテンツを、非常に高品質な表現かまたはいずれかの固定品質の表現を選択した状態で、ある特定の一時に多くのエンドポイントに対して効率的に送信することができる。コンテンツは、配信チェーンの下流にあるいずれのデバイスからも、特にキャッシュおよびクライアントからは、利用できるようにされており、これらのキャッシュおよびクライアントは、好ましくは、キャッシュから入手可能なこれらのセグメントをフェッチすべきであって、オリジンサーバからそれ以外の表現をフェッチすべきではない。
【０１０３】
本発明をその好適実施形態に関して述べてきたが、この記述は例示的な目的に限られることは理解されるべきである。従って、本発明は、本明細書に添付される請求項の範囲によってのみ限定されることが意図されている。
【図１】
0006290885.tif 000002
【図２】
0006290885.tif 000003
【図３】
0006290885.tif 000004
【図４】
0006290885.tif 000005
【図５】
0006290885.tif 000006
【図６】
0006290885.tif 000007
【図７】
0006290885.tif 000008
【図８】
0006290885.tif 000009
【図９】
0006290885.tif 000010
【図１０】
0006290885.tif 000011
【図１１】
0006290885.tif 000012