(57)【特許請求の範囲】
【請求項１】
メディアデータの送信システムにおける送信エンティティを動作させる方法であって、
前記メディアデータの受信エンティティへの送信と関連した推定された遅延を示す固定された遅延を識別するステップと、
前記受信エンティティのための必要バッファサイズを前記固定された遅延、前記受信エンティティへの送信経路に対する最小送信遅延、そして前記メディアデータの送信と関連したビットレート情報に基づいて推定するステップと、
前記必要バッファサイズを前記受信エンティティに送信するステップとを有し、
前記必要バッファサイズは、前記固定された遅延から前記最小送信遅延を引いて前記固定された遅延と前記最小送信遅延との差異値を計算し、前記計算された差異値と前記メディアデータの送信と関連した最大ビットレートとの積を使用して推定される、
送信エンティティを動作させる方法。
【請求項２】
前記送信エンティティは、前記固定された遅延及び前記必要バッファサイズの調整が必要であるか否かを確認する、請求項１に記載の送信エンティティを動作させる方法。
【請求項３】
前記固定された遅延は、
送信エンティティから前記受信エンティティまでの前記送信経路と関連した最大送信遅延を含み、
フォワードエラー訂正（ＦＥＣ）が前記メディアデータの送信に適用された場合、ＦＥＣバッファリング遅延をさらに含む、請求項１に記載の送信エンティティを動作させる方法。
【請求項４】
メディアデータの送信システムにおける送信エンティティの装置であって、
前記メディアデータの受信エンティティへの送信と関連した推定された遅延を示す固定された遅延を識別し、前記受信エンティティのための必要バッファサイズを前記固定された遅延、前記受信エンティティへの送信経路に対する最小送信遅延、そして前記メディアデータの送信と関連したビットレート情報に基づいて推定するように構成される制御器と、
前記必要バッファサイズを前記受信エンティティに送信するように構成される送信器と
を有し、
前記必要バッファサイズは、前記固定された遅延から前記最小送信遅延を引いて前記固定された遅延と前記最小送信遅延との差異値を計算し、前記計算された差異値と前記メディアデータの送信と関連した最大ビットレートとの積を使用して推定される、
送信エンティティの装置。
【請求項５】
前記送信エンティティの装置は、前記固定された遅延及び前記必要バッファサイズの調整が必要であるか否かを確認する、請求項４に記載の送信エンティティの装置。
【請求項６】
前記固定された遅延は、
送信エンティティから前記受信エンティティまでの前記送信経路と関連した最大送信遅延を含み、
フォワードエラー訂正（ＦＥＣ）が前記メディアデータの送信に適用された場合、ＦＥＣバッファリング遅延をさらに含む、請求項４に記載の送信エンティティの装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、一般的に、送信システムでのメディアデータの配信に関し、特に、メディアデータの配信及び提示を制御する方法及び装置に関するものである。
【背景技術】
【０００２】
ムービングピクチャーエクスパーツグループ（Moving Picture Experts Group：ＭＰＥＧ）メディアトランスポート（ＭＭＴ）は、異種インターネットプロトコル（ＩＰ）ネットワーク環境を通したマルチメディアサービスのために符号化されたメディアデータの配信のための技術を特定するディジタルコンテナ標準又はフォーマットである。配信されて符号化されたメディアデータは、指定された時間のデータ、すなわち、タイム（timed）データの特定のユニットの同期化されたデコーディング及び提示（presentation）を必要とする視聴覚メディアデータ、及びユーザによるサービスのコンテキスト又は相互作用（interaction）に基づいて、任意の時間でデコーディングされ提示される他のタイプのデータ、すなわち、非タイム（non-timed）データのすべてを含む。
【０００３】
ＭＭＴは、符号化されたメディアデータが実時間トランスポートプロトコル（RealTime Transport Protocol：ＲＴＰ）、送信制御プロトコル（Transmission Control Protocol：ＴＣＰ）、及びユーザデータグラムプロトコル（User Datagram Protocol：ＵＤＰ）などのようなインターネットプロトコル（ＩＰ）を用いてパケット基盤配信ネットワークを通して配信されるという仮定の下で考案されたものである。また、ＭＭＴは、異なる配信環境の特徴を考慮して考案される。例えば、送信エンティティから受信エンティティへの各パケットの配信に対するエンドツーエンド遅延が常に一定ではないことがあり、基本ネットワークプロバイダは、メディアデータからシグナリングメッセージを識別する方法を提供しなければならない。したがって、ＭＭＴメディアデータ配信の改善した標準が必要とされる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明は、上述した課題もしくは不都合な点を解決し、少なくとも以下に示す優位性を提供する。すなわち、本発明の目的は、送信システムにおけるメディアデータの配信を制御するための方法及び装置を提供することにある。
【課題を解決するための手段】
【０００５】
上記のような目的を達成するために、本発明の一態様によれば、送信システム内の送信エンティティを動作させる方法が提供される。上記方法は、送信システム内のメディアデータの送信と関連して固定された遅延を識別するステップを含む。また、上記方法は、メディアデータがアプリケーションレイヤ構成要素に伝達されるか又は受信エンティティのユーザに提示される送信の後の時間長さに対する要件として固定された遅延に関する情報を送信するステップを含む。
【０００６】
本発明の別の態様によれば、送信システム内の受信エンティティを動作させる方法が提供される。上記方法は、メディアデータ及びメディアデータと関連した固定された遅延に関する情報を受信するステップを含む。また、上記方法は、固定された遅延に関する情報から、メディアデータがアプリケーションレイヤ構成要素に伝達されるか又はユーザに提示される送信の後の時間長さに対する要件を識別するステップを含む。
【０００７】
本発明のまた別の態様によれば、送信システム内の送信エンティティの装置が提供される。上記装置は、送信システム内のメディアデータの送信と関連した固定された遅延を識別するように構成される制御器を含む。また、上記装置は、メディアデータがアプリケーションレイヤ構成要素に伝達されるか又は受信エンティティのユーザに提示される送信の後の時間長さに対する要件として固定された遅延に関する情報を送信するように構成される送信器を含む。
【０００８】
本発明のさらに別の態様によれば、送信システム内の受信エンティティの装置が提供される。上記装置は、メディアデータ及びメディアデータと関連した固定された遅延に関する情報を受信するように構成される受信器を含む。また、上記装置は、固定された遅延に関する情報から、メディアデータがアプリケーションレイヤ構成要素に伝達されるか又はユーザに提示される送信の後の時間長さに対する要件を識別するように構成される制御器を含む。
【０００９】
本発明を詳細に説明するのに先立って、本明細書の全般にわたって使用される特定の単語及び語句の定義を説明することが好ましい。“含む”及び “備える”という語句だけではなく、その派生語は、限定ではなく、包含を意味する。“又は”という用語は、“及び／又は”の意味を包含する。“関連した”及び“それと関連した”という語句だけではなく、その派生語句は、“含む”、“含まれる”、“相互に連結する”、“包含する”、“包含される”、“連結する”、“結合する”、“疎通する”、“協力する”、“相互配置する”、“並置する”、“近接する”、“接する”、“有する”、及び“特性を有する”などを意味することができる。制御部は、少なくとも１つの動作を制御する装置、システム又はその部分を意味するもので、ハードウェア、ファームウェア、ソフトウェア、又は、それらのうちの少なくとも２つ以上の組合せで実現することができる。特定の制御部に関連する機能は、集中しているか、あるいは近距離、または遠距離に分散されることもあることに留意すべきである。特定の単語及び語句に関するこのような定義は、本明細書の全般にわたって規定されるもので、当業者には、大部分の場合ではなくても、多くの場合において、このような定義がそのように定義された単語及び語句の先行使用にはもちろん、将来の使用にも適用されるものであることが自明である。
【００１０】
本発明とそれによって存在するより完全な理解と、それに従う多くの利点のより完全な理解は容易に明らかになり、添付された図面との結合を考慮すれば、後述する詳細な説明を参照してよりよく理解できる。図面中、同一の参照符号は、同一であるか又は類似した構成要素を示す。
【図面の簡単な説明】
【００１１】
【図１】本開示の様々な実施形態が具現されることができる送信システムの例を示す図である。
【図２】本開示の様々な実施形態に従ってＭＭＴメディアデータ送信環境内のＭＭＴプロトコル入出力の構成を示すブロック図である。
【図３】本開示の様々な実施形態に従って送信側で受信器の動作をシミュレーションし、バッファ遅延及びサイズ要件を推定するための受信器バッファモデルの構成を示すブロック図である。
【図４】本開示の様々な実施形態に従って図３のＭＭＴＰカプセル解除（de-capsulation）バッファ内のＭＭＴＰパケット処理のためのタイミング図である。
【図５】本開示の例示的な実施形態に従って送信システム内の送信エンティティを動作させるプロセスを示す図である。
【図６】本開示の例示的な実施形態に従って送信システム内の受信エンティティを動作させるプロセスを示す図である。
【図７】本開示の様々な実施形態が具現されることができる例示的な電子装置を示す図である。
【発明を実施するための形態】
【００１２】
下記で論議される図１乃至図７及び本明細書で本発明の原理を記述するのに使用される様々な実施形態は、ただ例示的なものであって、本発明の範囲を限定するものと解釈すべきではない。当業者であれば、本発明の原理が適切に配置されたシステム又は装置で具現することができるものであることは自明である。
【００１３】
ＭＭＴ符号化及びメディア配信が以下の文書及び標準化内容を通して論議される：ＩＳＯ／ＩＥＣ  ＪＴＣ  １／ＳＣ２９／ＷＧ１１、異種環境での高効率符号化及びメディア配信−部分１：本明細書にすべて記述されたもののように本開示に含まれる２０１２年７月ＭＰＥＧメディア配信（ＭＭＴ）。異種ＩＰネットワーク環境を通して符号化されたメディアデータの効率的であり効果的な配信のために、ＭＭＴは、マッシュアップ（mash-up）応用例のための様々な構成要素でなされたコンテンツを構成するための論理的モデル；パケット化及び適応化のように、配信レイヤ処理のために符号化されたメディアデータに関する情報を搬送するデータの構造；ハイブリッド配信を含んで、ＴＣＰ又はＵＤＰを通して使用される特定のタイプのメディア又は符号化方法に関係ないメディアコンテンツを配信するためのパケット化方法及びパケット構造；メディアコンテンツの提示及び配信を管理するためのシグナリングメッセージのフォーマット；メディアコンテンツの提示及び配信を管理するためのシグナリングメッセージのフォーマット；クロスレイヤ通信を容易にするためにレイヤにわたって交換されるべき情報のフォーマットを提供する。
【００１４】
ＭＭＴは、カプセル化、配信、及びシグナリングを含む３個の機能領域を規定する。カプセル化機能領域は、メディアコンテンツの論理的構造、ＭＭＴパッケージ、及びＭＭＴコンプライアントエンティティにより処理されるデータユニットのフォーマットを規定する。ＭＭＴパッケージは、メディアコンテンツ及び適応的な配信に必要とされる情報を提供するためのメディアコンテンツ間の関係を含む構成要素を特定する。データユニットのフォーマットは、配信プロトコルのペイロードとして保存されるか又は搬送され、記憶及び搬送間で容易に転換されるように符号化されたメディアをカプセル化するように規定される。配信機能領域は、ペイロードのフォーマット及びアプリケーションレイヤプロトコルを規定する。アプリケーションレイヤプロトコルは、マルチメディアの配信のための従来のアプリケーションレイヤプロトコルに比べて、ＭＭＴパッケージの配信のために多重化を含む改善した特性を提供する。ペイロードフォーマットは、特定のメディアタイプ又はエンコーディング方法に関係ない符号化されたメディアデータを搬送するために定義される。シグナリング機能領域は、ＭＭＴパッケージの配信及び消費を管理するためのメッセージのフォーマットを定義する。消費管理のためのメッセージは、ＭＭＴパッケージの構造をシグナリングするために使用され、配信管理のためのメッセージは、ペイロードフォーマットの構造及びプロトコルの構成をシグナリングするために使用される。
【００１５】
ＭＭＴは、オーディオ、ビデオ、及びウィジェット、ファイルなどのような他の静的コンテンツ（static content）のような時間連続のマルチメディアの配信のための新たなフレームワークを規定する。ＭＭＴは、受信エンティティへのＭＭＴパッケージの配信のためのプロトコル（すなわち、ＭＭＴＰ）を特定する。ＭＭＴＰは、プロトコルヘッダの一部として、ＭＭＴＰパッケージの送信時間をシグナリングする。このような時間は、受信エンティティが各入力ＭＭＴパケットの送信時間及び受信時間を検査することにより、デジッタ（de-jittering）を実行することができるようにする。
【００１６】
本開示の実施形態は、メディアデータの受信のための環境条件が送信経路、送信フォーマット、及び送信と受信（例えば、エンドツーエンド遅延）との間の遅延をもたらす受信装置のタイプに基づいて異なり得る。例えば、異なる送信メディア（例えば、無線データ通信（ＬＴＥ、ＨＳＰＡ、３Ｇ、ＷｉＦｉなど）、物理メディア（例えば、有線、ケーブル、イーサネット(登録商標)、光ファイバーなど）、衛星放送など）は、異なる関連送信遅延を有する。本開示の実施形態は、送信遅延に加えて、他の原因がジッタを引き起こすことがあることを認識する。例えば、フォワードエラー訂正（ＦＥＣ）デコーディングは、追加遅延を挿入することにより十分なソース及びパリティパケットの受信を要求する欠落したパケットの復旧を可能にする。もう１つの遅延の原因は、送信の間に実行されたこともあるデータインタリービングによるものであり得る。また、本開示の実施形態は、受信装置構成要素も遅延に影響を与え得ると認識する。多くのメモリ及びより速い処理機能を有するコンピュータのような装置は、より少ないメモリ及びより遅い処理能力を有するセットトップボックスのような他の装置より少ない遅延を有する。
【００１７】
本開示の実施形態は、放送環境のような所定の環境において、送信されるパケットごとに送信から受信エンティティでのＭＭＴ処理スタックを離れるまでポイントツーマルチポイント（point-to-multipoint：ＰＭＰ）送信システムにわたって同一の遅延を経験する固定されたエンドツーエンド遅延を有することが重要であると認識する。例えば、本開示の実施形態は、同一のプログラムを受信するすべてのクライアントが装置、プロトコル、又は送信メディア実現に関係なく、同一の時間で同一のコンテンツを提示するように提供するか又は保証することが重要であると認識する。また、受信器のハードウェア実現を可能にするために、本開示の実施形態は、固定されたパケット遅延を保証するために要求されるメモリ空間の上限値が提供されるべきと認識する。ネットワークの特性及びサービスの設定により、ＭＭＴパケットは、広範囲なジッタに露出し、これは、異るバッファ条件の要求につながる。例えば、大きいソースブロックに対してＦＥＣ保護を提供し、インターネットを通して搬送されるサービスは、管理されるブロードキャストを通してＦＥＣ保護なしに搬送されるサービスより多いバッファリングを必要とする。
【００１８】
したがって、本開示の実施形態は、固定されたエンドツーエンド遅延及び入力されるＭＭＴパケットのバッファリングのための限定されたメモリ要件の提供、実施、及び／又は保証を行うための方法及び装置を提供する。また、本開示の実施形態は、バッファ要件及び固定された遅延を受信エンティティにシグナリングするためのツールを提供する。
【００１９】
図１は、本開示の様々な実施形態が具現されることができる送信システム１００の例を示す図である。図示する実施形態において、システム１００は、送信エンティティ１０１と、ネットワーク１０５と、受信エンティティ１１０〜１１６と、基地局（ＢＳ）１０２、基地局（ＢＳ）１０３、及び他の類似した基地局又は中継局（図示せず）のような無線送信ポイント（例えば、ｅＮＢ（Evolved Node B）、ノードＢ）とを含む。送信エンティティ１０１は、例えば、インターネット、メディアブロードキャストネットワーク、或いはＩＰ基盤の通信システムであり得るネットワーク１０５を通して基地局１０２及び基地局１０３と通信している。受信エンティティ１１０〜１１６は、ネットワーク１０５及び／又は基地局１０２及び１０３を通して送信エンティティ１０１と通信している。
【００２０】
基地局１０２は、基地局１０２のカバレッジ領域（coverage area）１２０内の複数の第１の受信エンティティ（例えば、ユーザ端末、携帯電話、移動局、加入者局）に、ネットワーク１０５に対する無線アクセスを提供する。複数の第１の受信エンティティは、スモールビジネス（small business：ＳＢ）に位置付けられるユーザ端末１１１と、エンタープライズ（enterprise：Ｅ）に位置付けられるユーザ端末１１２と、ＷｉＦｉ（登録商標）ホットスポット（hotspot：ＨＳ）に位置付けられるユーザ端末１１３と、第１レジデンス（residence：Ｒ）に位置付けられるユーザ端末１１４と、第２レジデンス（residence：Ｒ）に位置付けられるユーザ端末１１５と、携帯電話、無線通信可能なラップトップ、無線通信可能なＰＤＡ、タブレットＰＣ（tablet computer）などのようなモバイルデバイス（Ｍ）であり得るユーザ端末１１６とを含む。
【００２１】
基地局１０３は、基地局１０３のカバレッジ領域１２５内にある複数の第２ユーザ端末に、ネットワーク１０５に対する無線アクセスを提供する。複数の第２のユーザ端末は、ユーザ端末１１５及びユーザ端末１１６を含む。例示的な実施形態において、基地局１０１〜１０３は、ＯＦＤＭ技術又はＯＦＤＭＡ技術を用いて、相互に通信してもよく、ユーザ端末１１１〜１１６と通信してもよい。
【００２２】
図１には、６個のユーザ端末のみが示されているが、システム１００は、追加のユーザ端末に無線広帯域及びネットワークアクセスを提供することを理解すべきである。ユーザ端末１１５及びユーザ端末１１６は、カバレッジ領域１２０及びカバレッジ領域１２５の両方の境界（edge）に位置する。ユーザ端末１１５及びユーザ端末１１６は、それぞれ基地局１０２及び基地局１０３の両方と通信し、当該技術分野における当業者に知られているように、ハンドオフモード（handoff mode）で動作してもよい。
【００２３】
ユーザ端末１１１〜１１６は、ネットワーク１０５を通して、音声、データ、ビデオ、ビデオ会議、及び／又は他の放送サービスをアクセスする。一実施形態において、ユーザ端末１１１〜１１６の中の１つ以上は、ＷｉＦｉ  ＷＬＡＮのアクセスポイント（access point：ＡＰ）と関連付けられ得る。ユーザ端末１１６は、無線可能なラップトップコンピュータ、個人用データアシスタント、ノートパソコン（notebook）、携帯用デバイス、又は他の無線可能なデバイスを含む、複数のモバイルデバイスのうちのいずれかであってもよい。ユーザ端末１１４及び１１５は、例えば、無線可能なパソナールコンピュータ（ＰＣ）、ラップトップコンピュータ、ゲートウェイ（gateway）、又は他のデバイスであってもよい。
【００２４】
図２は、本開示の様々な実施形態に従ってＭＭＴメディアデータ送信環境２００内のＭＭＴプロトコル入出力の構成を示すブロック図である。図示する実施形態において、送信エンティティ２０５は、ＭＭＴＰに従って送信媒体を通して受信エンティティ２１０にメディアデータを送信する。メディアデータ２１５は、ＭＭＴＰに従って送信エンティティ２０５で処理される。例えば、送信エンティティ２０５は、ＭＭＴ処理ユニット（ＭＰＵｓ）及びＭＭＴフラグメンテーションユニット（ＭＦＵｓ）２１５（例えば、ＭＰＵのフラグメント）としてのメディアデータに対してＭＭＴパッケージカプセル化、符号化、配信、及びシグナリングを実行する。その後に、この処理されたメディアデータは、ＭＭＴＰに従う処理（例えば、カプセル化解除、デコーディングなど）のために受信エンティティ２１０に（例えば、パケットとして）送信される。その後に、受信エンティティ２１０で処理されたメディアデータは、メディアデータの配信を完了するユーザに提示するために複数のＭＰＵ及び／又はＭＦＵとして上位レイヤプログラミング（例えば、メディアプレーヤのようなアプリケーションレイヤプログラム）に伝達される。
【００２５】
図３は、本開示の様々な実施形態に従って送信側で受信器の動作をシミュレーションし、バッファ遅延及びサイズ要件を推定するための受信器バッファモデル３００の構成を示すブロック図である。本開示の様々な実施形態において、メディア配信サーバ（又は他のＭＭＴアウェアノード）のような送信エンティティ２０５は、ポイントツーマルチポイント送信システムにおけるメディアデータ配信のための固定されたエンドツーエンド遅延の計算、判定、及び／又は識別を行う。例えば、送信エンティティ２０５は、モデル３００を活用して受信エンティティ２１０の受信器での受信制約上でパケットストリームに対して実行されるメディアデータ処理の影響を判定する。例えば、送信エンティティ２０５は、このモデルを活用して、必要とされるバッファリング遅延及び必要とされるバッファサイズを判定することにより、この情報をメディアデータを受信するエンティティに送信する。
【００２６】
図示する例において、ＦＥＣデコーディングバッファ３０５は、ＦＥＣデコーディングと関連した遅延及び／又はバッファサイズ要件を推定するためのモデルである。ＦＥＣデコーディングは、下位レイヤ送信がチャネルエラーから復旧するのに充分でないことがある多くのアプリケーションレイヤで、ネットワーク輻輳がパケットドロップ又は過度な遅延を引き起こし得る時に一般的である。ＦＥＣデコーディングを実行するために、受信エンティティ２１０は、十分なソース（“Ｓ”）及びリペアデータ（“Ｐ”パリティデータ）がＦＥＣデコーディングを実行するために使用可能であるまで入力されるパケットが記憶されるバッファを使用する。
【００２７】
図示する例において、送信エンティティ２０５は、ＦＥＣデコーディングと関連した遅延を推定するためにＦＥＣデコーディングに関して受信エンティティ２１０が取るアクションを判定するためにＦＥＣデコーディングバッファ３０５のモデルを使用する。言い換えれば、送信エンティティ２０５は、ＦＥＣデコーディングバッファ３０５のモデルを用いて、ＦＥＣデコーディング遅延を推定するために受信エンティティ２１０が取るアクションを予測する。このような送信エンティティ２０５によるＦＥＣデコーディングバッファ３０５のモデリングは、ＦＥＣデコーディングバッファ３０５が初期には空いているという推定から開始される。次いで、送信タイムスタンプｔｓを有する各入力パケットｉに対して、受信エンティティ２１０は、buffer_occupancy（バッファ占有）＋packet_size（パケットサイズ）＜max_buffer_size（最大バッファサイズ）である場合に、ＦＥＣデコーディングバッファ３０５を使用してパケットｉをバッファリングする。他方、受信エンティティ２１０は、パケットｉをバッファモデルと符合しないものとして廃棄する。その後に、受信エンティティ２１０は、ＦＥＣがパケットｉに適用されるか否かを判定する。ＦＥＣがパケットｉに適用される場合に、受信エンティティ２１０は、パケットｉが属しているソースブロックｊを決定し、time t+FEC_buffer_timeでソースブロックｊの第１のパケットの挿入時間ｔがソースブロックｊのすべてのパケットを（必要であれば、ＦＥＣ訂正の後に）デジッタバッファ（de-jitter buffer）に移動することを決定し、リペアパケットを廃棄する。送信エンティティ２０５は、ソースブロックの１番目のパケットの受信からＦＥＣデコーディングが試みられるまでＦＥＣデコーディングのために必要とされるバッファ時間としてFEC_buffer_timeを活用する。この時間は、通常、ＦＥＣブロックサイズに基づいて計算される。
【００２８】
デジッタバッファ３１０は、パケットのデジッタリング（de-jittering）、すなわち、パケットの遅延ジッタの除去と関連した遅延及び／又はバッファサイズ要件を推定するために送信エンティティにより使用されるモデルである。デジッタバッファは、最終的に、最大送信遅延を前提にし、ＭＭＴＰパケットがソースからＭＭＴＰプロトコルスタックの出力まで固定された送信遅延を経験することを保証する。受信エンティティ２１０は、最大送信遅延より大きい送信遅延を経験するデータユニットを非常に遅いものと廃棄する。
【００２９】
このような送信エンティティ２０５によるデジッタバッファ３１０のモデリングは、デジッタバッファ３０５が初期には空いているという推定から開始される。その後に、受信エンティティ２１０は、ＭＭＴＰパケットが到着する時にそのパケットをデジッタバッファ３１０に挿入する。その後に、受信エンティティ２１０は、時間ｔｓ＋ΔでのＭＭＴＰパケットを除去し、ここで、ｔｓは、ＭＭＴＰパケットの送信タイムスタンプであり、Δは、メディアデータに対してシグナリングされる固定されたエンドツーエンド遅延である。デジッタリングが適用された後に、正確に到着した（又はＦＥＣ／再送信を通して復旧された）すべてのＭＭＴＰパケットは、同一のエンドツーエンド遅延を経験した。
【００３０】
ＭＭＴＰカプセル解除バッファ３１５は、その出力を上位レイヤに伝達する前にＭＭＴＰ処理と関連して遅延及び／又はバッファサイズ要件を推定するために送信エンティティにより使用されるモデルである。前記ＭＭＴＰ処理の出力は、ＭＦＵペイロード（低い遅延動作において）、完全な映画フラグメント、又は完全なＭＰＵであり得る。ＭＰＵは、それらのサイズにより、より小さなパケットに分割されるか又はより大きなパケットに集約され得る。その後に、カプセル解除（ＭＭＴＰパケット及びペイロードヘッダの除去）及びそのパケットの任意の要求された分割解除（de-fragmentation）／集約解除（de-aggregation）は、ＭＭＴＰ処理の一部として実行される。このような手順は、ＭＰＵが複数のＭＭＴＰパケットに分割される時に組立てを実行するためには、カプセル解除遅延と呼ばれる若干のバッファリング遅延を必要とする。しかしながら、このような例示的な実施形態において、カプセル解除遅延は、固定されたエンドツーエンド遅延の一部として考慮されないはずであり、符号化されたメディアレイヤにより消費されるＭＰＵの使用可能性は、カプセル解除遅延に無関係に、そのＭＰＵを複数のＭＭＴＰパケットに分割するエンティティにより保証されることができる。
【００３１】
図４は、本開示の様々な実施形態によりＭＭＴＰカプセル解除（de-capsulation）バッファ３１５内のＭＭＴＰパケット処理のためのタイミング図４００を示す図である。タイミング図４００は、ＭＭＴＰパケットが処理され、上位レイヤに出力される時に時間によるＭＭＴＰカプセル解除バッファ３１５でのバッファレベルの一例である。例えば、タイミング図４００は、ＭＭＴＰパケット処理と関連したバッファ要件を推定する例である。
【００３２】
送信エンティティ２０５によるＭＭＴＰカプセル解除バッファ３１５のモデリングは、ＭＭＴＰカプセル解除バッファが初期には空いているという推定から開始される。受信エンティティ２１０は、デジッタリングが実行された後に、ＭＭＴＰパケットをＭＭＴＰカプセル解除バッファ３１５に挿入する。集約されたペイロードを搬送するＭＭＴＰパケットに対して、受信エンティティ２１０は、パケット及びペイロードヘッダを除去し、その集約を個別のＭＰＵに分割する。分割されたペイロードを搬送するＭＭＴＰパケットに対して、受信エンティティ２１０は、対応するすべてのフラグメントが正確に受信されるまで、あるいは分割された同一のＭＰＵに属していないパケットが受信されるまで、ＭＭＴＰカプセル解除バッファ３１５にそのパケットを保管する。ＭＰＵのすべてのフラグメントが受信される場合に（例えば、時間４０５又は時間４１０で）、受信エンティティ２１０は、ＭＭＴＰパケット及びペイロードヘッダの除去、再組み立て（reassemble）を行った後に、再構成されたＭＰＵを上位レイヤに転送する。他方、ＭＰＵの一部のフラグメントが受信されない場合には、受信エンティティ２１０は、完全でないＭＰＵのフラグメントを廃棄する。
【００３３】
このような受信器バッファモデル３００に基づいて、送信エンティティ２０５は、送信スケジュール、バッファサイズ、及びバッファリング遅延Δを判定し、ターゲット経路での最大配信遅延を推定して、いかなるパケットも欠落しないように縮小及び／又は保証を行うことができる。送信エンティティ２０５は、設定されたしきい値以下の送信遅延を経験するパケットの提供、及び／又はそのようなパケットがポイントツーマルチポイント送信システムにわたって一定の遅延の後に、クライアントバッファがアンダーフロー又はオーバーフローされないようにし、上位レイヤに出力されることができるように保証する。
【００３４】
メディアデータに対して要求されたバッファサイズ及び固定されたエンドツーエンド遅延を判定した後に、送信エンティティ２０５は、このような情報を受信エンティティ２１０に送信する。例えば、送信エンティティ２０５は、このような情報を送信と受信エンティティとの間のシグナリングプロトコルを使用して受信エンティティ２１０に送信する。様々な実施形態において、送信エンティティ２０５は、選択されたエンドツーエンド遅延及びバッファサイズが整列され、バッファアンダーラン（under-runs）又はオーバラン（overruns）を起こさないことを検証するために受信器バッファモデル３００を連続的に運営する。受信側で、固定された遅延に対するシグナリングは、それぞれのデータユニットが上位レイヤに転送される前に、シグナリングされた固定されたエンドツーエンド遅延を経験するようにバッファリングを実行することを受信エンティティ２１０に指示する。送信と受信エンティティとの間のクロックが同期するという仮定の下に、受信エンティティ２１０は、送信タイムスタンプ及びシグナリングされた固定されたエンドツーエンド遅延に基づいてデータの出力時間を計算できる。
【００３５】
一部の実施形態において、送信エンティティ２０５は、セッションディスクリプションプロトコル（ＳＤＰ）ファイルのようなセッションディスクリプションファイルを用いてシグナリングを実行する。ＳＤＰにおいて、メディアセッションは、ＭＭＴＰプロトコルを使用して配信されるものと説明される。メディアセッションは、固定されたエンドツーエンド遅延及び／又は要求されたバッファサイズを含む。以下に述べられる表１は、固定されたエンドツーエンド遅延及びバッファサイズ要件をシグナリングするＳＤＰファイルのメディアセッション記述の一例を示す。
【００３６】
【表１】
0006516674.tif 000002
【００３７】
他の実施形態において、固定されたエンドツーエンド遅延及びバッファサイズ要件のシグナリングは、ＭＭＴＰシグナリング関数を用いて実行される。そのような実施形態において、情報を搬送するための新たなシグナリングメッセージが考案される。
【００３８】
このような例において、バッファサイズは、バイト単位で与えられ、固定されたエンドツーエンド遅延は、ミリ秒単位で与えられる。他の実施形態において、送信エンティティ２０５は、特別のシグナリングメッセージタイプが定義されるか又は情報が既存のシグナリングメッセージに含まれるＭＭＴＰシグナリングメッセージを使用してシグナリングを実行する。
【００３９】
固定された遅延を判定するにあたり、送信エンティティ２０５は、受信器への送信経路で最大期待及び許容できる送信遅延を推定する。ＦＥＣが使用される場合に、送信エンティティ２０５は、ＦＥＣデコーディングが損失されたＭＭＴＰパケットを復旧するのに要求される状況において、ソースブロックを組み立てるのに必要とされる時間（例えば、上記で論議されたFEC_buffer_time）をカバーするＦＥＣバッファリング遅延を付加する。追加で、送信エンティティ２０５は、パケットの分割により誘発され得る任意の遅延を付加する。送信エンティティ２０５は、その結果によるＭＭＴＰ配信遅延の推定を固定されたエンドツーエンド遅延としてシグナリングする。固定されたエンドツーエンド遅延を推定する一例は、以下に述べられる数式１により与えられる。
【００４０】
【数１】
0006516674.tif 000003
【００４１】
様々な実施形態において、結果的なバッファ要件を推定するために、送信エンティティ２０５は、固定されたエンドツーエンド遅延を使用し、データが送信エンティティ２０５によりバッファリングされなければならないと推定された最大時間長さとして受信器への送信経路に対する最小送信遅延を減算する。その後に、送信エンティティ２０５は、バッファサイズ要件を計算されたバッファリングデータデュレーションにより乗算されるＭＭＴＰストリームの最大ビットレートとして推定する。固定されたエンドツーエンド遅延を推定する一例は、以下に述べられる数式２により与えられる。
【００４２】
【数２】
0006516674.tif 000004
【００４３】
ここで説明された様々な実施形態は、ＭＭＴデータ通信を論議したが、本開示の様々な実施形態がＭＭＴ通信に限定されるのではないことに留意すべきである。例えば、固定された遅延及びバッファサイズ判定は、本開示の原理に従って任意の適切なタイプのデータ又はメディアコンテンツ配信及び／又は任意の適切なタイプの送信システムにも適用される。
【００４４】
図５は、本開示の例示的な実施形態に従って送信システム内の送信エンティティを動作させるプロセスを示す図である。例えば、図５に示すプロセスは、図２の送信エンティティ２０５により実行される。また、このプロセスは、図１の送信エンティティ１０１により実施される。
【００４５】
このプロセスは、ステップ５０５において、送信エンティティがメディアデータの送信と関連した固定された遅延を識別するもので開始する。例えば、ステップ５０５において、送信エンティティは、様々な装置に様々な通信媒体を通して時間に敏感なコンテンツを配信するポイントツーマルチポイント送信システム内のメディアサーバであり得る。このような遅延を識別するために、送信エンティティは、その遅延を推定するか、又は他のソースから予め計算されるか又は標準化された遅延を識別する。一例において、送信エンティティは、送信エンティティからマルチポイント送信システム内の１つ以上の受信エンティティへの送信経路（例えば、無線、イーサネット(登録商標)、衛星放送など）と関連した送信遅延を推定する。例えば、送信遅延は、マルチポイント送信システム内の受信エンティティの各々と関連した送信メディア及び装置タイプに基づく最大送信遅延に対する推定値であり得る。また、送信エンティティは、受信エンティティでメディアデータに対して受信されたパケットの処理と関連したバッファリング遅延を推定する。その後に、送信エンティティは、送信遅延及びバッファリング遅延に基づいて固定された遅延を計算する。
【００４６】
ステップ５１０において、送信エンティティは、受信エンティティのためのバッファサイズ要件を判定する。例えば、ステップ５１０において、送信エンティティは、データが受信エンティティによりバッファリングされなければならない時間の予想程度を固定された遅延から最小送信遅延を引いたものと判定する。その後に、送信エンティティは、メディアデータと関連したこのようなバッファリング時間の程度及びビットレートに基づいてバッファサイズ要件を計算する。
【００４７】
その後に、送信エンティティは、ステップ５１５において、固定された遅延及びバッファサイズ要件に関する情報を送信する。例えば、ステップ５１５において、送信エンティティは、メディアデータの送信とは個別であるメッセージを通して、又はメディアデータの送信に先行されるか又は付加されるメタデータを通してバッファサイズ要件をシグナリングする。これらの例において、固定された遅延は、メディアデータが受信エンティティのユーザに提供される送信の後の時間長さの要件である。言い換えれば、固定された遅延は、送信エンティティがメディアデータを、ユーザへのメディアデータの究極的な提示のための上位レイヤプログラムに伝達するのに許容される時間である。これらの例において、送信エンティティは、送信メディア又は受信装置タイプに関係なく、ポイントツーマルチポイント送信環境に存在し得る複数の受信装置の間でほぼ正確に同一の時間にメディアデータのディスプレイの提供及び／又は保証を行う。
【００４８】
図６は、本開示の例示的な実施形態に従って送信システム内の受信エンティティを動作させるプロセスを示す図である。例えば、図６に示すプロセスは、図２の受信エンティティ２１０により実施される。また、このプロセスは、図１の受信エンティティ１１０により実施される。
【００４９】
このプロセスは、ステップ６０５において、受信エンティティがメディアデータ及びメディアデータと関連した固定された遅延に関する情報を受信するものから開始する。例えば、ステップ６０５において、受信エンティティは、メディアデータとともに、又はメディアデータに先立ってこの情報を受信する。
【００５０】
受信エンティティは、ステップ６１０において、メディアデータがユーザに提示される送信の後の時間の長さに対する要件を識別する。例えば、ステップ６１０において、受信エンティティは、ユーザへの受信されたメディアデータの究極的な提示のためにいつ上位レイヤに伝達するかを判定するための時間の長さとして固定された遅延を使用する。
【００５１】
その後に、受信エンティティは、ステップ６１５において、バッファにメディアデータと関連した受信データを記憶する。例えば、ステップ６１５において、受信エンティティは、受信されたデータと関連した送信タイムスタンプから固定された遅延を加えた時間が経過するまで、受信したメディアデータを記憶する。その後に、受信エンティティは、ステップ６２０において、現在の時間が送信タイムスタンプで固定された遅延を加えたものであるか否かを判定する。現在の時間が送信タイムスタンプに固定された遅延を加えたものより小さい場合に、送信エンティティは、後の提示及び配信のためにメディアデータを継続してバッファリングする。現在の時間が送信タイムスタンプに固定された遅延を加えたものより大きい場合に、送信エンティティは、そのデータがあまり遅く受信されたものと廃棄する。
【００５２】
しかしながら、現在の時間が送信タイムスタンプに固定された遅延を加えたものに対応する場合に、受信エンティティは、ステップ６２５において、受信されたデータをユーザインターフェースを通してユーザに提供し、その後にこのプロセスが終了する。例えば、ステップ６２５において、受信エンティティは、メディアデータをユーザに提示するためにそのメディアデータをアプリケーションレイヤプログラムに伝達する。これらの例において、受信エンティティは、ポイントツーマルチポイント送信環境に存在し得る他の受信エンティティの間でほぼ正確に同一の時間にメディアデータが受信エンティティでディスプレイされることを保証するようにメディアデータの固定された遅延の識別及び追従を行う。
【００５３】
図５及び図６がそれぞれ送信システム内の送信及び受信エンティティのためのプロセスの例を示すが、様々な変形が、図５及び図６についてなされることができることは、当然である。例えば、一連のステップが図示されるが、各図での様々なステップが、オーバーラップ（overlap）されてもよく、並列に生じてもよく、異なる順序で生じてもよく、又は数回生じてもよいことは、当然である。
【００５４】
図７は、本開示の様々な実施形態が実施される例示的な電子装置７００を示す図である。このような例において、電子装置７００は、制御部７０４、メモリ７０６、永久記憶部７０８、通信部７１０、入出力（Ｉ／Ｏ）部７１２、及びディスプレイ７１４を含む。これらの例において、電子装置７００は、図１の送信エンティティ１０１及び／又は受信エンティティ１１０〜１１６の１つの具現例である。また、電子装置７００は、図２の送信エンティティ２０５及び／又は受信エンティティ２０１の一例である。
【００５５】
制御部７０４は、少なくとも１つの動作を制御する任意の装置、システム、又はその一部である。このような装置は、ハードウェア、ファームウェア、又はソフトウェア、又はこれらの少なくとも２つの組み合せで実現することができる。例えば、制御部７０４は、電子デバイス７００の動作を制御するように構成されたハードウェア処理部及び／又はソフトウェアプログラムを含んでもよい。例えば、制御部７０４は、メモリ７０６にローディングすることができるソフトウェアに対する命令語を処理する。制御部７０４は、特定の具現例に基づいて、複数のプロセッサ、マルチプロセッサコア、又は他のタイプのプロセッサを含んでもよい。また、制御部７０４は、単一チップにおいて、メインプロセッサが補助プロセッサとともに存在する、複数の異種プロセッサシステムを用いて実現することができる。他の実施例において、制御部７０４は、同一のタイプの複数のプロセッサを含む対称形のマルチプロセッサシステムを含んでもよい。
【００５６】
メモリ７０６及び永久記憶部７０８は、記憶装置７１６の例である。記憶装置は、例えば、非限定的にデータ、関数形式のプログラムコード、及び／又は一時及び／又は永久的な他の適切な情報のような、これに限定されない情報を記憶することができるハードウェアの一部である。これらの例において、メモリ７０６は、例えば、ランダムアクセスメモリ又は他の適切な揮発性又は非揮発性記憶装置であり得る。例えば、永久記憶部７０８は、１つ以上の構成要素又は素子を含んでもよい。永久記憶部７０８は、ハードドライブ、フラッシュメモリ、光ディスク、又は上述したハードドライブ、フラッシュメモリ、光ディスクの一部の組合せであってもよい。また、永久記憶部７０８により使用される媒体は、着脱可能である。例えば、着脱可能なハードドライブは、永久記憶部７０８のために用いられてもよい。
【００５７】
通信部７１０は、他のデータ処理システム又は装置との通信を提供する。これらの例において、通信部７１０は、無線（セルラー、ＷｉＦｉなど）送信器、受信器及び／又は送信器、ネットワークインターフェースカード、及び／又は物理又は無線通信媒体を通して通信の送信及び／又は受信を行うための任意の他の適切なハードウェアを含んでもよい。通信部７１０は、物理通信リンク又は無線通信リンク、あるいは、すべての通信リンクの使用を通して通信を提供することができる。
【００５８】
入出力部７１２は、電子装置７００に接続されるか又はその一部であり得る他の装置とのデータの入出力を許容する。例えば、入出力部７１２は、タッチユーザ入力を受信するタッチパネル、オーディオ入力を受信するマイクロフォン、オーディオ出力を提供するスピーカ、及び／又はハプティック出力（haptic output）を提供するモータを含んでもよい。入出力部７１２は、電子装置７００のユーザにメディアデータ（例えば、オーディオデータ）の提供及び配信のためのユーザインターフェースの一例である。他の例において、入出力部７１２は、キーボード、マウス、外部スピーカ、外部マイクロフォン及び／又は任意の他の適切な入出力装置を通してユーザ入力のための接続を提供する。また、入出力部７１２は、プリンタに出力を送信する。ディスプレイ７１４は、情報をユーザにディスプレイするメカニズムを提供し、電子装置７００のユーザにメディアデータ（例えば、イメージ及び／又はビデオデータ）の提供及び配信のためのユーザインターフェースの一例である。
【００５９】
オペレーティングシステムのためのプログラムコード、アプリケーション、又は他のプログラムは、制御部７０４と通信状態にある記憶装置７１６に位置する。一部の実施形態において、プログラムコードは、永久記憶部７０８上に関数形式で存在する。これらの命令語は、制御部７０４による処理のためにメモリ７０６にローディングすることができる。異なる実施形態のプロセスは、メモリ７０６に位置するコンピュータ実施命令語（computer-implemented instruction）を用いて制御部７０４により行われてもよい。例えば、制御部７０４は、上述したモジュール及び／又は装置の中の１つ以上に対するプロセスを行ってもよい。
【００６０】
一部の実施形態において、上述した様々な機能は、コンピュータ読み取り可能なプログラムコードから形成され、コンピュータ読み取り可能な媒体で実施されるコンピュータプログラム製品により実施されるか又はサポートされる。コンピュータプログラム製品についてのプログラムコードは、選択的に着脱可能なコンピュータ読み取り可能な記憶装置上で関数形式で位置し、制御部７０４による処理のために電子装置７００にローディングされるか又は伝送される。一部の例示的な実施形態において、プログラムコードは、電子装置７００内での使用のために、ネットワークを通して他の装置又はデータ処理システムから永久記憶部７０８にダウンロードされる。例えば、サーバデータ処理システム内のコンピュータ読み取り可能な記憶媒体に記憶されているプログラムコードは、ネットワークを通してサーバから電子装置７００にダウンロードされる。プログラムコードを提供するデータ処理システムは、サーバコンピュータ、クライアントコンピュータ、又はプログラムコードの記憶及び送信を実行できる一部の他の装置であってもよい。
【００６１】
本開示の実施形態は、メディアデータの配信に適合した一般的なプロトコルを提供することにより、ＭＭＴＰが既存の転送プロトコルを改善し置き換えるために開発されたことを認識する。ＭＭＴＰは、ライブストリーミングのような実時間低い遅延応用例だけでなく遅延許容応用例を扱う。ＭＭＴＰプロトコルが受信器上で一貫して動作し、必要なバッファ空間がクライアントにより使用可能であるように保証するために、本開示の実施形態は、エンドツーエンド遅延を判定し、必要なバッファ空間を推定し、このような情報を受信器にシグナリングするための方法及び装置を提供する。このような機能は、受信クライアントがハードウェア（例えば、セットトップボックス）で実現される放送受信器に対して特に重要である。
【００６２】
本開示は、例示的な実施形態とともに説明されたが、様々な変形及び修正が可能であることは、当該技術分野における当業者には明らかである。本開示は、添付の特許請求の範囲内で上記のような変形及び修正を含む。
【符号の説明】
【００６３】
１００  送信システム
１０１  送信エンティティ
１０２、１０３  基地局（ＢＳ）
１０５  ネットワーク
１１０〜１１６  受信エンティティ
１２０、１２５  カバレッジ領域
【図１】
0006516674.tif 000005
【図２】
0006516674.tif 000006
【図３】
0006516674.tif 000007
【図４】
0006516674.tif 000008
【図５】
0006516674.tif 000009
【図６】
0006516674.tif 000010
【図７】
0006516674.tif 000011