(57)【特許請求の範囲】
【請求項１】
ネットワーク上のネットワークノードが動的適応ストリーミングハイパーテキスト転送プロトコル（ＤＡＳＨ）クライアントデバイスに情報を提供する方法であって、
表現（representation）がキャッシュされることによる前記表現の使用可能性に対する情報を含むメッセージを前記ＤＡＳＨクライアントデバイスのために生成するステップと、
前記ＤＡＳＨクライアントデバイスに前記メッセージを送信するステップと、
を有することを特徴とする方法。
【請求項２】
前記ＤＡＳＨクライアントデバイスにストリーミングされるメディアに対するメディアプレゼンテーション記述（ＭＰＤ）ファイルを受信するステップと、
少なくとも前記ＭＰＤファイルに基づいてレート適応の動作を変更するか否かを判定するステップと、
をさらに有することを特徴とする請求項１に記載の方法。
【請求項３】
前記メッセージは、レート適応動作を変更し、前記表現が少なくとも一時的に使用不可能であることを前記メッセージが示すと、前記ＤＡＳＨクライアントデバイスが前記表現を他の表現にスイッチングすることを特徴とする請求項１に記載の方法。
【請求項４】
前記メッセージは、前記ＤＡＳＨクライアントデバイスがストリーミングすることを選ぶ表現に対する情報を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記ＤＡＳＨクライアントデバイスのために割り当てられた帯域幅関連情報を含むメッセージを生成するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記メッセージは、第１の通信チャネルを用いて送信され、前記表現の使用可能性に対する情報は、前記ＤＡＳＨクライアントデバイスが前記表現を受信した第２の通信チャネルを通して前記表現が使用可能であることを示すことを特徴とする請求項１に記載の方法。
【請求項７】
前記メッセージを１つ以上のＤＡＳＨセグメントに挿入するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項８】
動的適応ストリーミングハイパーテキスト転送プロトコル（ＤＡＳＨ）クライアントデバイスに情報を提供するためのネットワーク上のネットワークノードの装置であって、
表現（representation）がキャッシュされることによる前記表現の使用可能性に対する情報を含むメッセージを前記ＤＡＳＨクライアントデバイスのために生成するように構成される制御部と、
前記ＤＡＳＨクライアントデバイスに前記メッセージを送信するように構成される通信部と、
を有することを特徴とする装置。
【請求項９】
請求項２乃至請求項７のうちのいずれか１つに従って動作するように適応されることを特徴とする請求項８に記載の装置。
【請求項１０】
動的適応ストリーミングハイパーテキスト転送プロトコル（ＤＡＳＨ）クライアントデバイスの装置であって、
メッセージを受信するように構成される通信部と、
前記メッセージに基づいて、表現（representation）がキャッシュされることによる前記表現の使用可能性を決定するように構成される制御部と
を有することを特徴とする装置。
【請求項１１】
前記制御部は、前記メッセージをＤＡＳＨイベントとして識別するように構成されることを特徴とする請求項１０に記載の装置。
【請求項１２】
前記制御部は、前記メッセージから、前記表現が少なくとも一時的に使用不可能であることを示すかを判定し、前記表現を他の表現にスイッチングするように構成されることを特徴とする請求項１０に記載の装置。
【請求項１３】
前記制御部は、前記メッセージから、ストリーミングすることを優先する表現を決定するように構成されることを特徴とする請求項１０に記載の装置。
【請求項１４】
前記制御部は、前記メッセージから、前記装置のために割り当てられた帯域幅を決定するように構成されることを特徴とする請求項１０に記載の装置。
【請求項１５】
前記通信部は、１つ以上のＤＡＳＨセグメントを通して前記メッセージを受信するように構成されることを特徴とする請求項１０に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、一般的に、メディアストリーミングに関し、より詳細には、メディアストリーミングネットワーク内のクライアントのレート適応（rate adaptation）の動作を制御するものに関する。
【背景技術】
【０００２】
最近のメディアストリーミングの発展は、様々な理由で転送プロトコルとしてハイパーテキスト転送プロトコル（ＨＴＴＰ）を使うのに好都合であった。ＨＴＴＰプロトコルスタックは、存在するほぼすべてのプラットフォーム上に幅広く設けられる。ＨＴＴＰを使用してストリーミングサービスを開始することは、特別なハードウェア又はソフトウェアを必要とせず、オープンソースのアパッチ（Apache）ウェブサーバのような現存する既製品サービスを用いて行うことができる。また、ＨＴＴＰの使用は、既存のコンテンツ配信ネットワーク（ＣＤＮ）インフラを再使用するという利益を有する。さらに、ＨＴＴＰの広範囲な使用により、リアルタイム転送プロトコル（ＲＴＰ）のような他のプロトコルならば遭遇するネットワークアドレス変換（ＮＡＴ）の通過及びファイアウォールの問題がＨＴＴＰでは本質的に解消されている。
【０００３】
幾つかの適応ＨＴＴＰストリーミングソリューションがここ数年の間に開発されてきた。格段な１つのソリューションがＭＰＥＧ（Moving Pictures Experts Group）及び３ＧＰＰ（3rdGeneration Partnership Project）により標準化されたＨＴＴＰに対する動的適応ストリーミング（Dynamic Adaptive Streaming over HTTP：以下、ＤＡＳＨと称する）と呼ばれる。ＤＡＳＨは、装置がインターネットのようなネットワークを通したメディアコンテンツの高品質ストリーミングを可能とするように動作させる技術標準のセットである。ＤＡＳＨは、メディアデータ配信のためのフォーマットだけでなく、メディアプレゼンテーションディスクリプション（Media Presentation Description：ＭＰＤ）と呼ばれるマニフェスト（manifest）ファイルのシンタックス（syntax）及びセマンティックス（semantics）から始める手順を定義する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本開示の実施形態は、ＤＡＳＨクライアントのレート適応を制御するための方法及び装置を提供することにある。
【課題を解決するための手段】
【０００５】
上記のような目的を達成するために、１つの例示的な実施形態において、ＤＡＳＨクライアントのレート適応を変更するための方法が提供される。この方法は、１つ以上のＤＡＳＨクライアント装置のレート適応動作を変更する信号を生成するステップを含む。また、この方法は、この１つ以上のＤＡＳＨクライアント装置にこの信号を送信するステップを含む。
【０００６】
他の例示的な実施形態において、ＤＡＳＨクライアントのレート適応を変更するための装置が提供される。この装置は、通信部及び制御部を含む。この制御部は、１つ以上のＤＡＳＨクライアント装置のレート適応動作を変更するための信号を生成するように構成される。この通信部は、この１つ以上のＤＡＳＨクライアント装置にこの信号を送信するように構成される。
【０００７】
また他の例示的な実施形態において、ＤＡＳＨクライアントのレート適応のための方法が提供される。この方法は、ＤＡＳＨクライアント装置で信号を受信するステップを含む。また、この方法は、この信号に基づいて、ＤＡＳＨクライアント装置のレート適応の動作を変更するか否かを決定するステップを含む。
【０００８】
もう１つの例示的な実施形態において、ＤＡＳＨクライアントのレート適応のための装置が提供される。この装置は、通信部及び制御部を有するＤＡＳＨクライアント装置を含む。通信部は、信号を受信するように構成される。制御部は、この信号に基づいて、ＤＡＳＨクライアント装置のレート適応の動作を変更するか否かを決定するように構成される。
【０００９】
本発明を詳細に説明するのに先立って、本明細書の全般にわたって使用される特定の単語及び語句の定義を説明することが好ましい。“接続（結合）する”という語句だけではなく、その派生語は、２以上の構成要素が相互に物理的な接触状態にあるか否か、それら間の任意の直接的であるか又は間接的な通信を称する。“送信する”、“受信する”、及び“通信する”という用語だけでなく、その派生語は、直接的または間接的な通信のすべてを含む 。“含む”及び “備える”という語句だけではなく、その派生語は、限定ではなく、包含を意味する。“又は”という用語は、“及び／又は”の意味を包含する。“関連した”及び“それと関連した”という語句だけではなく、その派生語句は、“含む”、“含まれる”、“相互に連結する”、“包含する”、“包含される”、“連結する”、“結合する”、“疎通する”、“協力する”、“挿入する”、“並置する”、“近接する”、“属する”、“有する”、及び“特性を有する”、“関係を有する”などを意味する。“少なくとも１つの”という語句は、項目のリストとともに使用される時に、リストされた項目の中の１つ以上の相互に異なる組み合わせが使用されてもよく、そのリスト内の１つの項目だけが必要とされてもよいことを意味する。例えば、“Ａ、Ｂ、及びＣの中の少なくとも１つ”は、次のような組み合わせの中のいずれか１つを含む：Ａ、Ｂ、Ｃ、Ａ及びＢ、Ａ及びＣ、Ｂ及びＣ、並びに、Ａ及びＢ及びＣ。
【００１０】
さらに、以下に記述される様々な機能は、１つ以上のコンピュータプログラムにより具現化されるか又はサポートされてもよく、そのプログラムの各々は、コンピュータ読み取り可能なプログラムコードで構成されてもよく、コンピュータ読み取り可能な媒体で実施されてもよい。“アプリケーション”及び“プログラム”という用語は、１つ以上のコンピュータプログラム、ソフトウェアコンポーネント、命令語セット、手順、関数、オブジェクト、クラス、インスタンス、関連データ、又は適合したコンピュータ読み取り可能なプログラムコードの実現に適合したそれらの一部を称する。“コンピュータ読み取り可能なプログラムコード”という語句は、ソースコード、オブジェクトコード、及び実行コードを含むすべてのタイプのコンピュータコードを含む。“コンピュータ読み取り可能な媒体”という語句は、読出し専用メモリ（read only memory：ＲＯＭ）、ランダムアクセスメモリ（random access memory：ＲＡＭ）、ハードディスクドライブ、コンパクト・ディスク（ＣＤ）、ディジタルビデオディスク（ＤＶＤ）、又は任意の他のタイプのメモリのように、コンピュータによりアクセスできるすべてのタイプの媒体を含む。“非一時的”なコンピュータ読み取り可能な媒体は、一時的な電気又は他の信号を転送する有線、無線、光学、又は他の通信リンクを除外する。非一時的なコンピュータ読み取り可能な媒体は、データが永続的に記憶されることができる媒体、及び再記録可能な光学ディスクや削除可能なメモリ装置のようにデータを記憶し、後で上書きできる媒体を含む。
【００１１】
他の所定の単語及び語句に対する定義がこの特許文書の全体にわたって提供される。当業者は、大部分の場合ではなくても多くの場合に、そのような定義がそのように定義された単語及び語句の前だけでなく後の使用にも適用されてもよいことが分かる。
【００１２】
本開示及びその長所に対するより完全な理解のために、同一の参照符号は、同一の構成要素を示す添付された図面と関連してなされた下記の説明を参照する。
【図面の簡単な説明】
【００１３】
【図１】本開示によるメッセージを送信する例示的な無線システムを示す図である。
【図２】本開示による例示的な送信経路を示す図である。
【図３】本開示による例示的な受信経路を示す図である。
【図４】本開示による例示的なメディアプレゼンテーション記述（ＭＰＤ）ファイルの構造を示す図である。
【図５】本開示によるセグメント化されたＩＳＯＢＭＦＦ基盤コンテンツの例を示す図である。
【図６】本開示によるＤＡＳＨクライアントのレート適応を制御する例示的なプロセスを示す図である。
【図７】本開示によるＤＡＳＨクライアントのレート適応のための例示的なプロセスを示す図である。
【図８】本開示の様々な実施形態を具現化することができる例示的なノードを示す図である。
【発明を実施するための形態】
【００１４】
下記で議論する図１乃至図８、及び本特許文書の開示の原理を説明するために使用される様々な実施形態は、例示としてのみ提供され、開示の範囲を制限するいかなる方法としても理解されてはならない。当業者であれば、本開示の原理が適切に用意された任意のシステム又は装置で実現することができるものであることは自明である。
【００１５】
以下に記述される様々な構成は、無線通信システムにおいて、ＯＦＤＭ又はＯＦＤＭＡ通信技術の使用を通して具現化することができる。しかしながら、このような構成についての内容は、他の実施形態を具現化することができる方式に対する物理的又は構造的な限界を含むことを意味するものではない。本開示の他の実施形態は、適切な任意の通信技術を用いて適切に用意された任意の通信システムで実装されてもよい。
【００１６】
図１は、本開示によるメッセージを送信する例示的な無線システム１００を示す図である。図示した実施形態において、システム１００は、サーバ１０１、クライアント１１０乃至１１６、及びクライアント１１０乃至１１６にサーバ１０１を接続するネットワーク１３０を含む。サーバ１０１は、アパッチ（Apache）サーバ、ＨＴＴＰサーバ、又は他のタイプのメディアコンテンツプロバイダのようなメディアサーバを表すものであってもよい。ネットワーク１３０は、インターネット、メディア放送ネットワーク、ＩＰ基盤通信システム、又は適切な他のネットワークを表すものであってもよく、サーバ１０１をクライアント１１０乃至１１６に接続する様々な中間ノードを含むか又はそのノードに接続することができる。中間ノードは、無線送信ポイントを含んでもよい。具体的な例は、ｅＮｏｄｅＢ１０２及び１０３又は他の基地局、ネットワークサービスプロバイダノード、ゲートウェイ、中間サーバ（会社又は機関サーバ）、中継局、又はアクセスポイントを含んでもよい。クライアント１１０乃至１１６は、ネットワーク１３０及び中間ノードを通してサーバ１０１と通信する。例えば、クライアント１１０乃至１１６は、本開示の教示に従ってＨＴＴＰに対する動的適応ストリーミング（Dynamic Adaptive Streaming over HTTP：以下、ＤＡＳＨと称する）標準及びプロトコルを用いてサーバ１０１からストリーミングされたメディアデータを受信することができる。１つのサーバ１０１が図示されているが、そのような複数のサーバがシステム１００内に存在してもよい。また、中間ノードは、有線中間ノード１０５を含んでもよい。
【００１７】
例示的な無線通信の実施形態によると、ｅＮＢ１０２は、ｅＮＢ１０２のカバレッジエリア１２０内にある第１の複数のユーザ装置（ＵＥｓ）にネットワーク１３０に対する無線広帯域アクセスを提供する。第１の複数のＵＥは、スモールビジネス（ＳＢ）内に位置できるＵＥ１１１、企業体（Ｅ）内に位置できるＵＥ１１２、ＷｉＦｉホットスポット（ＨＳ）内に位置できるＵＥ１１３、第１のレジダンス（Ｒ）内に位置できるＵＥ１１４、第２のレジダンス（Ｒ）内に位置できるＵＥ１１５、及びセルフォン、無線ラップトップ、無線ＰＤＡなどのようなモバイル装置（Ｍ）であるＵＥ１１６を含む。ｅＮＢ１０３は、ｅＮＢ１０３のカバレッジエリア１２５内にある第２の複数のＵＥにネットワーク１３０に対する無線広帯域アクセスを提供する。第２の複数のＵＥは、ＵＥ１１５及びＵＥ１１６を含む。例示的な実施形態において、ｅＮＢ１０２及び１０３は、ＯＦＤＭ又はＯＦＤＭＡ技術を用いて、相互に及びＵＥ１１１乃至１１６と通信できる。
【００１８】
６個のＵＥだけが図１に示されているが、システム１００は、付加的なＵＥに無線広帯域アクセスを提供してもよい。また、ＵＥ１１５及び１１６は、２つのカバレッジエリア１２０及び１２５の境界上に存在する。したがって、ＵＥ１１５及びＵＥ１１６のそれぞれは、ｅＮＢ１０２及び１０３のすべてと通信でき、当業者に知られているように、ハンドオフモードで動作するといわれている。
【００１９】
ネットワークタイプによっては、“ｅＮｏｄｅＢ”又は“ｅＮＢ”の代わりに、“基地局”又は“アクセスポイント”のようによく知られている他の用語が使用されてもよい。説明の便宜を図るために、用語“ｅＮｏｄｅＢ”又は“ｅＮＢ”は、遠隔端末に対する無線アクセスを提供するネットワークインフラ構成要素を称し、この特許文書内で使用されてもよい。また、他のネットワークタイプにより、“ユーザ装置”又は“ＵＥ”、“移動局”、“加入者局”、“遠隔端末”、“無線端末”、又は“ユーザ装置”のようなよく知られている他の用語が使用されてもよい。説明の便宜のために、“ユーザ装置”及び“ＵＥ”という用語は、本特許文書において、ＵＥが移動装置（例えば、移動電話又はスマートフォン）とみなされるか又は一般的に固定装置（例えば、デスクトップコンピュータ又は自動販売機）とみなされるかにかかわらず、無線でｅＮＢをアクセスする遠隔無線装置を称するために使用される。
【００２０】
クライアント１１０乃至１１６は、音声、データ、ビデオ、ビデオ会議、及び／又は他の広帯域サービスを、ネットワーク１３０を通してアクセスできる。例示的な実施形態において、クライアント１１０乃至１１６の中の１つ以上は、ＷｉＦｉ  ＷＬＡＮのアクセスポイント（ＡＰ）と関連づけられてもよい。
【００２１】
図２は、本開示による例示的な送信経路２００を示す図である。一部の実施形態において、送信経路２００は、ＯＦＤＭＡ通信のために使用されてもよい。図３は、本開示による例示的な受信経路３００を示す図である。また、一部の実施形態において、受信経路３００は、ＯＦＤＭＡ通信のために使用されてもよい。
【００２２】
図２及び図３において、ダウンリンク通信のために、送信経路２００は、ｅＮＢ（例えば、ｅＮＢ１０２）で実装されてもよく、受信経路３００は、ＵＥ（例えば、ＵＥ１１６）で実装されてもよい。アップリンク通信のために、受信経路３００は、ｅＮＢ（例えば、ｅＮＢ１０２）で実装されてもよく、送信経路２００は、ＵＥ（例えば、ＵＥ１１６）で実装されてもよい。
【００２３】
送信経路２００は、チャネル符号化及び変調ブロック２０５、直列−並列（Ｓ−ｔｏ−Ｐ）ブロック２１０、サイズＮの逆高速フーリエ変換（ＩＦＦＴ）ブロック２１５、並列−直列（Ｐ−ｔｏ−Ｓ）ブロック２２０、サイクリックプレフィックス（cyclic prefix）付加ブロック２２５、及びアップコンバータ（ＵＣ）２３０を含む。受信経路２５０は、ダウンコンバータ（ＤＣ）２５５、サイクリックプレフィックス除去ブロック２６０、直列−並列（Ｓ−ｔｏ−Ｐ）ブロック２６５、サイズＮの高速フーリエ変換（ＦＦＴ）ブロック２７０、並列−直列（Ｐ−ｔｏ−Ｓ）ブロック２７５、及びチャネル復号化及び復調ブロック２８０を含む。
【００２４】
送信経路２００において、チャネル符号化及び変調ブロック２０５は、情報ビットのセットを受信し、符号化（例えば、低密度パリティ検査（ＬＤＰＣ）符号化）を適用し、入力ビットを変調することにより（例えば、ＱＰＳＫ（Quadrature Phase Shift Keying）又はＱＡＭ（Quadrature Amplitude Modulation）を使用して）、周波数ドメイン変調シンボルのシーケンスを生成する。直列−並列ブロック２１０は、ＮがｅＮＢ１０２及びＵＥ１１６に使用されるＩＦＦＴ／ＦＦＴサイズであるとき、Ｎ個の並列シンボルストリームを生成するために、直列変調されたシンボルを並列データに変換（例えば、デマルチプレキシング）する。サイズＮのＩＦＦＴブロック２１５は、Ｎ個の並列シンボルストリームにＩＦＦＴ演算を実行し、時間ドメイン出力信号を生成する。並列−直列ブロック２２０は、直列時間ドメイン信号を生成するために、サイズＮであるＩＦＦＴブロック２１５から並列時間ドメイン出力シンボルを変換（例えば、マルチプレキシング）する。サイクリックプレフィックス付加ブロック２２５は、時間ドメイン信号にサイクリックプレフィックスを挿入する。アップコンバータ２３０は、サイクリックプレフィックス付加ブロック２２５の出力を、無線チャネルを通した送信のためのＲＦ周波数に変調（例えば、アップコンバート）する。また、この信号は、ＲＦ周波数に変換する前に基底帯域でフィルタリングされてもよい。
【００２５】
ｅＮＢ１０２から送信されたＲＦ信号は、無線チャネルを通過した後にＵＥ１１６に到達し、ｅＮＢ１０２での動作とは反対の動作がＵＥ１１６で実行される。ダウンコンバータ２５５は、受信された信号を基底帯域周波数にダウンコンバートし、サイクリックプレフィックス除去ブロック２６０は、サイクリックプレフィックスを除去することにより直列時間ドメイン基底帯域信号を生成する。直列−並列ブロック２６５は、時間ドメイン基底帯域信号を並列時間ドメイン信号に変換する。サイズＮのＦＦＴブロック２７０は、ＦＦＴアルゴリズムを実行してＮ個の並列周波数ドメイン信号を生成する。並列−直列ブロック２７５は、並列周波数ドメイン信号を変調されたデータシンボルのシーケンスに変換する。チャネル復号化及び復調ブロック２８０は、変調されたシンボルの復調及びデコーディングすることにより、元来の入力データストリームを復旧する。
【００２６】
図２及び図３の構成要素のそれぞれは、ハードウェアだけを使用するか、又はハードウェア及びソフトウェア／ファームウェアの組み合わせを用いて実装されてもよい。特定の例として、図２及び図３の構成要素のうちの少なくとも一部は、ソフトウェアを通して実装されてもよく、他の構成要素は、構成可能なハードウェア又はソフトウェアと構成可能なハードウェアとの組み合わせを通して実装されてもよい。例えば、ＦＦＴブロック２７０及びＩＦＦＴブロック２１５は、構成可能なソフトウェアアルゴリズムとして実装されてもよい。ここで、サイズＮの値は、実装方法に従って変更されてもよい。
【００２７】
また、ＦＦＴ及びＩＦＦＴを使用すると記述されているが、これは、例示のためのものであり、本開示の範囲を限定するものと解釈されてはいけない。離散フーリエ変換（Discrete Fourier Transform：ＤＦＴ）及び逆離散フーリエ変換（ＩＤＦＴ）関数のような他のタイプの変換が使用されてもよい。ＤＦＴ及びＩＤＦＴ関数において、変数Ｎの値は、任意の整数（例えば、１、２、３、４など）であってもよく、ＦＦＴ及びＩＦＦＴ関数において、変数Ｎの値は、２のべき乗である任意の整数（例えば、１、２、４、８、１６など）であってもよいと認識できる。
【００２８】
図４は、本開示による例示的なメディアプレゼンテーション記述（ＭＰＤ）ファイル４００の構造を示す図である。ＤＡＳＨにおいて、ＭＰＤファイル４００は、受信者又はエンドユーザのコンテンツ選択を助けるために、プレゼンテーションのメディアデータをどのようにアクセスするか、及び異なるコンテンツ成分に対するアノテーションをどのように提供するかを説明するマニフェストファイルである。
【００２９】
図４に示すように、ＭＰＤファイル４００は、連続的な時間期間（time period）４１０ａ乃至４１０ｎのセットに分けられるメディアプレゼンテーション４０５を記述する。それぞれの時間（period）４１０ａ乃至４１０ｎは、適応セット（adaptation set）４１５ａ乃至４１５ｎとして定義されるメディア構成要素のセットを含む。特定の構成要素に対して、適応セット４１５ａ乃至４１５ｎは、表現（representation）４２０ａ乃至４２０ｎのセットを含んでもよく、表現の各々は、同一のメディア構成要素に対する（異なるビットレート、コーデック、又はフォーマットを通した）異なるエンコーディングであってもよい。それぞれの表現４２０ａ乃至４２０ｎは、個別にフェッチされストリーミングされてもよい。メディアストリーミングを簡素化するために、それぞれの表現４２０ａ乃至４２０ｎは、１つ以上のメディアセグメント４２５ａ乃至４２５ｎに分割されてもよい。ＭＰＤファイル４００内の表現４２０ａ乃至４２０ｎは、コンテンツ成分（例えば、ビットレート、コーデック、又はフォーマット）に対するその特定のエンコーディングの特徴を説明する。また、表現４２０ａ乃至４２０ｎは、そのコンテンツ表現のそれぞれのセグメント４２５ａ乃至４２５ｎに対するアクセス情報を提供する。ＭＰＤファイル４００は、そのセグメントがＨＴＴＰ  ＵＲＬ（uniform resource locator）、及びオプションとして参照されたリソース内のバイト範囲を用いてアクセス可能であると仮定する。ＭＰＤファイル４００内のそれぞれのＵＲＬを有するそれぞれの単一のセグメントを参照することを避けるためのテンプレート構造が提供される。また、セグメント４２５ａ乃至４２５ｎは、インデックス１から始めてそれぞれの後続セグメントに対して１ずつ増加するものでインデキシングされてもよい。
【００３０】
ＤＡＳＨは、少なくとも２つの異なるメディアデータフォーマットを定義し、１つは、ＩＳＯＢＭＦＦ（International Organization for Standardization Base Media File Format）に基づいて定義し、他の１つは、ＭＰＥＧ−２トランスポートシステム（Ｍ２ＴＳ）に基づいて定義する。
【００３１】
図５は、本開示によるセグメント化されたＩＳＯＢＭＦＦ基盤コンテンツの例を示す図である。ＩＳＯＢＭＦＦ基盤フォーマットにおいて、ＤＡＳＨ表現（representation）は、ファイルのメディアデータがフラグメント単位で提供されることを意味するフラグメント化される（分割される）特徴を有する柔軟なＩＳＯＢＭＦＦファイルである。フラグメント化は、ストリーミング応用例において重要な低い遅延動作と関連して利点を有する。
【００３２】
図５に示すように、ＩＳＯＢＭＦＦ基盤フォーマットのメディアセグメント５００は、（ｓｔｙｐボックス５０５において）セグメントタイプを用いて識別され、（各ｍｏｏｆ５１０及びｍｄａｔボックス５１５において）１つ以上のムービー（movie）フラグメント及び関連メディアデータを含む。ｍｏｏｆボックス５１０は、メディアフラグメントに対するメタデータ及び探索（seeking）情報を含み、ｍｄａｔボックス５１５は、メディアフラグメント（例えば、オーディオ又はビデオフレーム）を含む。メディアセグメントのアクセス及びナビゲーションを簡素化するために、その特定のセグメント５００のランダムアクセスポイント（ＲＡＰｓ）及びムービーフラグメントをインデキシングするセグメントインデックスが（ｓｉｄｘボックス５２０を通して）提供される。このようなインデキシングは、クライアントが適応セット内で任意の表現スイッチングを実行できるようにしつつ、シームレスのユーザエクスペリエンス、正確なメディア同期、及び連続的な再生を保持するのに特に有用である。
【００３３】
上述したように、ＤＡＳＨに定義される他の１つのフォーマットは、Ｍ２ＴＳに基づき、このとき、ＭＰＥＧ−２基本ストリームが１つの表現（representation）に対応する。使用可能な表現がメインＭ２ＴＳにマルチプレキシングされる。ＭＰＥＧ−２  ＴＳの配信を簡素化するためにセグメント化が実行されてもよい。
【００３４】
本開示の実施形態は、適応ＨＴＴＰストリーミングソリューションとプログレッシブ（progressive）ダウンロードとの違いが、適応ＨＴＴＰストリーミングソリューションが輻輳状況及びスループット変動に応じて、それらのビットレートを適応させることができることにある点であることを認める。プログレッシブダウンロードのとき、コンテンツの単一の表現を含むメディアファイルがクライアントによりダウンロードされる。プログレッシブダウンロードに対して様々なエンコーディングが存在し得るが、適切なコンテンツ及び選択メカニズムも提供されておらず、これは、セッションの開始のときに、外部メカニズム（例えば、ユーザ選択）を通したコンテンツの適切な表現に対する選択を制限する。
【００３５】
本開示の実施形態は、ＤＡＳＨにおいて、コンテンツのそれぞれのメディアコンポーネントが適応セットの一部として提供されると認識する。適応セットは、同一のコンテンツに対する１つ以上の表現を含み、ＤＡＳＨクライアントは、ストリーミングセッションの任意の時点でその中の１つを選択できる。ＤＡＳＨクライアントは、全般的なスループットバジェット内で適合な表現へのスイッチングによりネットワーク状態に適応する。本開示の実施形態は、ＤＡＳＨレート適応がクライアント主導的であるが、そのようなレート適応の正確度は、ＤＡＳＨクライアントが選択した動作ポイントの個数を調節するプレゼンテーションオーサー（例えば、メディアサーバ及び／又はネットワーク）により管理されると認識する。
【００３６】
ＤＡＳＨクライアントは、ＤＡＳＨクライアントの１つ以上のメディアバッファのレベル及びスループットをモニタリングし、表現をスイッチングするか否かを決定し、スイッチングすることを決定した場合には、どの表現を選択するかを決定する。例えば、ＤＡＳＨクライアントは、使用可能なスループットが、メディアセグメントがダウンロードされている表現により要求される帯域幅より低いか、同一であるか、又は高いかに対する指標として、“セグメントデューレーションに対するセグメントダウンロード時間”の比率を使用できる。１．０より高い値は、ＤＡＳＨクライアントがメディアセグメントをダウンロードするのに、そのメディアセグメントにより提供されるメディアの量より多い時間がかかることを示す。これは、メディア受信レートがメディア消費レートより低くてメディアバッファを消耗（drain）させるはずであるという将来の再生問題の可能性を示す。それに従って、ＤＡＳＨクライアントは、より低い帯域幅要件を有する表現にスイッチングすることを選択する。
【００３７】
ＤＡＳＨは、コンテンツプロバイダが提供する表現の間のスイッチングを通したレート適応を実行するためにクライアントに依存する。しかしながら、モバイルオペレータが運営するもののような中間ノードは、普通、ネットワーク使用効率性を増進させるためにコアネットワーク内の特定のセル又は領域の短期又は長期的な負担に対処するように既存の接続のビットレートを調整しなければならない。このような問題を解消するためには、２タイプの異なるアプローチが提案される。１番目のアプローチでは、中間ノードは、ＤＡＳＨセッションの転送制御プロトコル／インターネットプロトコル（Transport Control Protocol/Internet Protocol：ＴＣＰ／ＩＰ）パケットを運搬するフローのパケットを遅延させるか又はドロップさせることにより接続の帯域幅を絞ることができる。その結果、ＴＣＰは、送信レートを使用可能なスループットに調整し、ＤＡＳＨクライアントは、将来その減少した帯域幅に基づくスイッチングを通して調整する。このようなアプローチでは、最適に達しないことがあり、こそれが損失パケットを復旧するための再送信を強制し、接続を絞ること（スロットリング）と関連した管理オーバーヘッドを増加させるためである。
【００３８】
２番目のアプローチでは、中間ノードは、マニフェストファイル（ＭＰＤファイル４００）に対するリクエストをインターセプトし、より高い帯域幅を必要とする表現を除去することによりＭＰＤファイルを再編集（re-author）する。しかしながら、このアプローチは、幾つかの短所を有する。例えば、ＭＰＤファイルを再編集することは、ＭＰＤファイルのオーサーリングにおいて２つのソースを利用することとなるため、ＭＰＤアップデートタイムラインを混同させる。オンデマンド（on-demand）サービスに対して、元来のＭＰＤファイルがそのＭＰＤファイルに対する何のアップデートも予見できないために、ＤＡＳＨクライアントは、ＭＰＤファイルに対するアップデートを探索しないのであろう。また、中間ノードがＭＰＤファイルをパースしリオーサーしなければならないため、このプロセッシングの複雑性も著しい。
【００３９】
したがって、本開示の実施形態は、ＤＡＳＨクライアント１１０乃至１１６でのレート適応の手順を制御するための方法及び装置を提供する。本開示の実施形態は、ＤＡＳＨイベントフレームワークを使用し、ＤＡＳＨクライアントでのレート適応の手順を制御するか又は変更するための一連のレート制御イベント又は信号を定義する。
【００４０】
ＭＰＤファイルを発行した後に、サーバ１０１、ネットワーク１３０、又は中間ノード（例えば、ノード１０５）は、所定の表現を選ぶ。例えば、ネットワーク１３０は、メディアコンテンツの所定の表現のコピーを有するキャッシュを有する。ネットワーク１３０は、ネットワーク効率性及び輻輳減少のためにクライアント１１０乃至１１６がキャッシングされた表現を使用することを選ぶことができ、また、これは、（例えば、待機時間の減少において）クライアントに有利である。他の例では、ネットワーク１３０又はサーバ１０１のオペレータは、リソース混雑度を検出し、ＤＡＳＨクライアント１１０乃至１１６がより低い帯域幅表現の使用を希望してもよい。もう１つの例では、選択された表現のセットは、eＭＢＭＳ（enhanced multimedia broadcast multicast service）を通して配信されてもよく、ネットワーク１３０又はサーバ１０１のオペレータは、ＤＡＳＨクライアントへのｅＭＢＭＳ配信を選んでもよい。サーバ１０１、ネットワーク１３０、又は中間ノード１０５の表現の選択に影響を及ぼす要因の更なる例には、バッファサイズ、サーバ状態、及び優先ＵＲＬが含まれる。
【００４１】
様々な実施形態において、サーバ１０１又は中間ノード１０５は、ＤＡＳＨクライアント１１０乃至１１６をレート適応させるためのイベントを挿入するか又は信号を送信する。例示的な実施形態では、中間ノード１０５は、１つ以上のＤＡＳＨセグメントの一部として制御信号をインターセプトして含み、及び／又はその信号をＤＡＳＨイベントとして提供してもよい。他の例示的な実施形態において、中間ノード１０５は、ＤＡＳＨクライアントがＭＰＤファイル又はメディアコンテンツを受信する通信チャネルとは離れている通信チャネルを通して制御信号を送信してもよい。様々な例において、制御信号は、特定の表現が、帯域幅の使用可能性、サーバ状態、又はバッファ制限のような理由で、一時的に使用不可能であることを示してもよい。他の例において、制御信号は、特定の表現のキャッシュコピー使用可能性又は帯域幅の利用などの理由で、より消費に好まれることを示してもよい。もう１つの例において、制御信号は、クライアントに表現を配信するために現在使用されているチャネル又はネットワークとは異なるチャネル又はネットワークを通して特定の表現がが現在使用可能であることを示してもよい。
【００４２】
例示的な実施形態において、レート制御信号を配信するためのイベントが定義される。“urn:mpeg:dash:control:2013”のようなスキームＵＲＩがこのような目的のために定義される。それぞれのレート制御メッセージは、１つの値を含み、付加的な情報を含んでもよい。以下の表１は、可能な制御信号、制御信号のセマンティックス、及び制御信号により示されるコンテンツのセットについて記述したものである。
【００４３】
【表１】
0006598769.tif 000002
【００４４】
例示的な実施形態において、次のようなメッセージ構造を使用するＤＡＳＨ仕様ＩＳＯ／ＩＥＣ  ２３００９−１補正案１（ここには、その全体が参照の形態で含まれる）に従ってイベントメッセージが定義される。
【００４５】
aligned(8) class EventMessageBox extends FullBox(‘emsg’, version = 0, flags = 0){
string scheme_id_uri;
string value;
unsigned int(32) timescale;
unsigned int(32) presentation_time_delta;
unsigned int(32) event_duration;
unsigned int(32) id;
unsigned int(8) message_data[];
}
図６は、本開示に従ってＤＡＳＨクライアントのレート適応を制御する例示的なプロセスを示す図である。説明の便宜のために、図６で説明するプロセスは、図１のサーバ１０１又は任意の中間ノード（例えば、ｅＮＢ１０２、ｅＮＢ１０３、又はノード１０５）により実行される。
【００４６】
プロセスは、ノードがＭＰＤファイルをインターセプトし（ステップ６０５）、そのＭＰＤファイルを分析すること（ステップ６１０）から開始する。例えば、このステップの一部として、中間ノード１０５は、ＭＰＤファイルを受信し、ＭＰＤファイルから、どの表現がクライアント１１０乃至１１６にストリーミング可能となっているかを判定する。サーバ１０１がレート適応制御に影響を及ぼす場合には、サーバ１０１が何のＭＰＤファイルをインターセプトしてパースする必要もなく、使用可能な表現を知っているために、ステップ６０５乃至６１０は、実行されないことがある。
【００４７】
ノードは、クライアントのレート適応を制御するか否かを決定する（ステップ６１５）。例えば、このステップの一部として、サーバ１０１及び／又は中間ノード１０５は、所定の表現が使用不可能であるか、所定の表現を選ばないか、又は選ぶかを決定できる。これは、ストリーミングセッションに対する帯域幅バジェット目標に基づく。ここで、帯域幅バジェット目標は、ネットワーク状態、キャッシュコピー使用可能性、サーバ又はバッファ状態、又は他のあるいは付加的要因に基づく。
【００４８】
ノードがクライアントレート適応を制御しないことに決定した場合に、プロセスは、終了する。しかしながら、ノードがクライアントのレート適応を制御することに決定する時に、ノードは、イベントメッセージを生成し（ステップ６２０）、そのイベントメッセージを１つ以上のＤＡＳＨセグメントに挿入できる（ステップ６２５）。例えば、このようなステップの一部として、ノードは、表１に示すフォーマット及びコンテンツに従ってイベントメッセージを生成する。イベントメッセージは、ＤＡＳＨイベントであってもよい。制御信号が個別に送信される実施形態において、ステップ６２０は、実行されないことがあり、ノードは、生成されたイベントメッセージをレート制御信号としてクライアントに送信する。
【００４９】
ステップ６２５において、イベントメッセージを送信する時に、プロセスは、終了する。ノードは、ＭＰＤ送信、ネットワーク状態を継続してモニタリングし、及び／又は、表現選択との適合を決定し（変更されたネットワーク状態などに基づいて）、及び／又は、付加的な制御信号を送信するか否かを決定するためにネットワークを通してストリーミングされる表現をモニタリングする。
【００５０】
図７は、本開示によるＤＡＳＨクライアントのレート適応のための例示的なプロセスを示す図である。説明の便宜のために、図７で説明するプロセスは、図１のＤＡＳＨクライアント１１０により実行される。
【００５１】
プロセスは、クライアント１１０がセグメントを受信し（ステップ７０５）、そのセグメントをパーシングする（ステップ７１０）ことから始まる。例えば、このステップの一部として、クライアント１１０は、メディアセグメントを受信する。クライアント１１０は、制御信号が受信されるか否かを判定する（ステップ７１５）。例えば、このステップの一部として、クライアント１１０は、制御信号が受信されたセグメント内にＤＡＳＨイベント制御メッセージとして存在するか否かを判定する。制御信号が別に送信される実施形態において、クライアント１１０は、メディアセグメントとは別に制御信号を受信し、任意のメディアセグメントの受信の前又は後にレート制御メッセージが受信されるか否かを判定する。他の例において、クライアント１１０は、サーバ１０１により生成されたＭＰＤファイルのようなＭＰＤファイルの一部として制御信号を受信する。
【００５２】
クライアント１１０がレート制御信号を受信しない場合に、クライアントは、継続してメディアセグメントを受信しつつメディアコンテンツをストリーミングする。しかしながら、クライアント１１０が制御信号を受信する場合に、クライアント１１０は、制御信号に基づいてターゲット表現を決定する（ステップ７２０）。例えば、このステップの一部として、制御信号は、ターゲット表現を特定する。他の例において、制御信号は、現在使用不可能なターゲット表現を特定し、クライアント１１０は、残りの使用可能な表現からターゲット表現を決定する。もう１つの例において、制御信号は、帯域幅バジェットを特定し、クライアント１１０は、特定された帯域幅バジェットを満足させるターゲット表現を決定する。
【００５３】
クライアントは、すでにターゲット表現を使用していない場合に、そのターゲット表現にスイッチングする（ステップ７２５）。例えば、このステップの一部として、制御信号により示されるサーバ／ネットワーク制約事項／優先事項（preferences）の適用の後に、１つ以上のターゲット表現が使用可能である場合に、クライアント１１０は、制御信号に含まれた情報及びクライアント装置に関する可能な情報に基づいてターゲット表現を選択する。クライアント装置に関する情報は、バッファ／帯域幅容量、優先されるコーデック、及びメディア品質／ネットワーク活用の好みを含む。選択された表現をすでに使用していない場合には、クライアント１１０は、選択された表現にスイッチングする。例示的な実施形態において、イベント制御メッセージは、指示された表現を使用するためにイベントタイムスタンプを含み、クライアント１１０は、メディアコンテンツストリーミングの時の妨害などを避けるために、タイムスタンプに示された時間以前に示された表現にスイッチングする。クライアントは、メディアコンテンツの円滑且つ効率的なストリーミングのためにレート調整を実行する時に、制御信号及びネットワーク状態を継続してモニタリングする。
【００５４】
図６と図７とは異なるプロセスの例を示しているが、図６及び７には、様々な変形がなされてもよい。例えば、一連のステップが図示されているが、それぞれの図面で様々なステップが重複して実行されるか、並列に実行されるか、異なる順序で実行されるか、又は複数回実行されてもよい。
【００５５】
本開示の実施形態は、アップストリーム（サーバ及びネットワーク）ノードが表現の選択を提案できるようにすることにより、ＤＡＳＨクライアントとネットワークノードとの間で効率的且つすっきりとした通信を可能にする。クライアントがそのような提案に従うことが要求されることもあり、要求されないこともある。ネットワークは、ＭＰＤファイルと干渉せず、ＤＡＳＨクライアントに特定の表現に対する好み（preference）を示すことができる。また、本開示の実施形態は、メディアストリーミングの時に、相互に有利な動作を選択するために、ネットワークとクライアントとの間で効率的且つ合理的な協調を可能にする。
【００５６】
図８は、本開示の様々な実施形態を具現化することができる例示的なノード８００を示す図である。ここに示すノード８００は、図１のサーバ１０１、ｅＮＢ１０２及び１０３、中間ノード１０５、及び／又はクライアント１１０乃至１１６の１つの例示的な実装例を示したものであってもよい。
【００５７】
この例において、ノード８００は、制御部８０４、メモリ８０６、永続的記憶部８０８、通信部８１０、入力／出力（Ｉ／Ｏ）部８１２、及びディスプレー８１４を含む。制御部８０４は、少なくとも１つの動作を制御する任意の装置、システム、又はその一部を意味し、そのような装置は、ハードウェア、又はハードウェア及びファームウェア及び／又はソフトウェアの組み合わせの形態で実装されてもよい。例えば、制御部８０４は、ハードウェア処理部、処理回路、メディアコーディング及び／又はデコーディングハードウェア及び／又はソフトウェア、及び／又はノード８００の動作を制御するように構成されたソフトウェアプログラムを含んでもよい。特定の例として、制御部８０４は、メモリ８０６内にローディングされるソフトウェア命令語を処理する。制御部８０４は、特定の実装例に従って、複数のプロセッサ、マルチプロセッサコア、又は任意の他のタイプのプロセッサを含んでもよい。また、制御部８０４は、単一のチップ上にメインプロセッサが２次プロセッサとともに存在する複数の異種プロセッサシステムを用いて実装されてもよい。他の例において、制御部８０４は、同一のタイプの複数のプロセッサを含む対称型マルチプロセッサシステムを含んでもよい。
【００５８】
メモリ８０６及び永続的記憶部８０８は、記憶装置８１６の例である。記憶装置は、一時的に、及び／又は、永久的に、データと、関数形式のプログラムコードと、他の適切な情報との一部または全部のような情報を記憶することができるハードウェアの一部である。例えば、メモリ８０６は、ランダムアクセスメモリ（random access memory：ＲＡＭ）又は、任意の他の適切な揮発性又は不揮発性記憶装置であってもよい。永続的記憶部８０８は、ハードドライブ、フラッシュメモリ、光ディスク、又は上述したもののある組み合わせのような１つ以上の構成要素又は素子を含んでもよい。永続的記憶部８０８により使用されるメディアは、着脱可能でもあってもよい。例えば、着脱可能なハードドライブは、永続的記憶部８０８のために使用されてもよい。
【００５９】
通信部８１０は、他のデータ処理システム又は装置との通信を提供する。例えば、通信部８１０は、無線（セルラー、ＷｉＦｉなど）送信器、受信器、及び／又は送受信器、ネットワークインターフェースカード、及び／又は、有体通信媒体又は無線通信媒体を通した通信の送受信を行うための任意の他の適切なハードウェアを含んでもよい。通信部８１０は、有体通信リンク及び／又は無線通信リンクの使用を通して通信を提供してもよい。
【００６０】
入出力部８１２は、ノード８００の一部、または接続可能な他の装置とのデータ入出力を可能とする。例えば、入出力部８１２は、タッチユーザ入力を受信するタッチパネル、オーディオ入力を受信するマイクロフォン、オーディオ出力を提供するスピーカ、及び／又はハプティック出力を提供するモータを含む。入出力部８１２は、ノード８００のユーザへのメディアデータの提供及び配信を行うためのユーザインターフェースの一例である。他の例において、入出力部８１２は、キーボード、マウス、外部スピーカ、外部マイクロフォン、及び／又は、他の適切な入出力装置を通してユーザ入力のための接続を提供してもよい。また、入出力部８１２は、プリンタへの出力を送信する。ディスプレー８１４は、情報をユーザに表示するメカニズムを提供し、ノード８００のユーザへのメディアデータの提供及び配信を行うためのユーザインターフェースの一例である。
【００６１】
オペレーティングシステムのためのプログラムコード、アプリケーション、又は他のプログラムが、制御部８０４と通信状態にある記憶装置８１６内に設けられてもよい。一部の実施形態において、プログラムコードは、永続的記憶部８０８上で、関数形式で存在する。このような命令語が制御部８０４による処理のためにメモリ８０６内にローディングされる。異なる実施形態のプロセスは、メモリ８０６に位置するコンピュータ実行命令語を用いて制御部８０４により実行されてもよい。例えば、制御部８０４は、上述したモジュール及び／又は装置のうちの１つ以上に対するプロセスを実行してもよい。
【００６２】
本開示は、例示的な実施形態とともに説明されたが、様々な変更及び修正が当業者に提案されてもよい。本開示は、そのような変更及び修正が特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきものである。
【図１】
0006598769.tif 000003
【図２】
0006598769.tif 000004
【図３】
0006598769.tif 000005
【図４】
0006598769.tif 000006
【図５】
0006598769.tif 000007
【図６】
0006598769.tif 000008
【図７】
0006598769.tif 000009
【図８】
0006598769.tif 000010