特許 6976276 レートペーシングのためにバッファを管理する装置及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6976276

(24)【登録日】2021年11月11日

(45)【発行日】2021年12月8日

(54)【発明の名称】レートペーシングのためにバッファを管理する装置及び方法

(51)【国際特許分類】

   H04N 21/238 20110101AFI20211125BHJP

   H04N 21/24 20110101ALI20211125BHJP

   H04N 21/438 20110101ALI20211125BHJP

   H04N 21/6373 20110101ALI20211125BHJP

   H04L 13/08 20060101ALI20211125BHJP

【ＦＩ】

   H04N21/238

   H04N21/24

   H04N21/438

   H04N21/6373

   H04L13/08

【請求項の数】12

【全頁数】20

(21)【出願番号】特願2018-561237(P2018-561237)

(86)(22)【出願日】2017年5月23日

(65)【公表番号】特表2019-524008(P2019-524008A)

(43)【公表日】2019年8月29日

(86)【国際出願番号】KR2017005339

(87)【国際公開番号】WO2017204525

(87)【国際公開日】20171130

【審査請求日】2020年1月22日

(31)【優先権主張番号】62/340,826

(32)【優先日】2016年5月24日

(33)【優先権主張国】US

(31)【優先権主張番号】15/415,840

(32)【優先日】2017年1月25日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】503447036

【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド

(74)【代理人】

【識別番号】100121382

【弁理士】

【氏名又は名称】山下 託嗣

(72)【発明者】

【氏名】リム，ヨン−クウォン

【審査官】 鈴木 順三

(56)【参考文献】

【文献】 米国特許出願公開第２００７／０１３３４０５（ＵＳ，Ａ１）

【文献】 国際公開第２００６／０１３６１８（ＷＯ，Ａ１）

【文献】 米国特許出願公開第２００６／０２８２５６６（ＵＳ，Ａ１）

【文献】 Digital Video Broadcasting(DVB)；DVB specification for data broadcasting，ETSI EN 301 192，V1.6.1，ETSI，2015年08月，pp. 71 - 72

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ ２１／００ − ２１／８５８

Ｈ０４Ｌ １３／００ − １３／１８

(57)【特許請求の範囲】

【請求項1】

メディア伝送システムにおける伝送装置を作動させるための方法であって、
受信装置のペーシングバッファからデコーディングバッファにパケットを伝送する速度(rate)に対する情報を含むペーシングバッファメッセージを形成するステップと、
前記ペーシングバッファメッセージを前記受信装置に伝送するステップと、
前記ペーシングバッファの状態に対する情報を含むペーシングバッファフィードバックメッセージを前記受信装置から受信するステップと、及び
前記ペーシングバッファフィードバックメッセージに基づいて前記受信装置にメディアデータのパケットを伝送するステップと、を含み、
前記ペーシングバッファの状態に対する情報は、前記ペーシングバッファにバッファされたパケットのターゲット量に対する情報を含み、
前記ペーシングバッファフィードバックメッセージは、
前記ペーシングバッファフィードバックメッセージの識別子（ＩＤ）を示す情報、および、
前記ペーシングバッファフィードバックメッセージのバージョンを示す情報をさらに含む、
伝送装置を作動させるための方法。

【請求項2】

前記ペーシングバッファの状態に対する情報は、前記ペーシングバッファにバッファされたパケットの量に対する情報を含む、
請求項１に記載の伝送装置を作動させるための方法。

【請求項3】

前記ペーシングバッファフィードバックメッセージに基づいて前記受信装置に前記メディアデータの前記パケットを伝送するステップは、
前記ペーシングバッファにバッファされた前記パケットの前記ターゲット量に対する情報に基づいて、前記メディアデータの前記パケットの伝送のために割り当てられた帯域幅を調整するステップを含む、
請求項１に記載の伝送装置を作動させるための方法。

【請求項4】

前記ペーシングバッファの状態に対する情報は、前記ペーシングバッファの利用可能な空間の量に対する情報を含む、
請求項１に記載の伝送装置を作動させるための方法。

【請求項5】

前記受信装置は、前記ペーシングバッファメッセージに基づいて前記パケットを前記ペーシングバッファから前記デコーディングバッファに伝達する、
請求項１に記載の伝送装置を作動させるための方法。

【請求項6】

前記ペーシングバッファの状態に対する情報は、最後に受信されたパケットのシーケンス番号に対する情報を含む、
請求項１に記載の伝送装置を作動させるための方法。

【請求項7】

メディア伝送システムにおける受信装置を作動させるための方法であって、
前記受信装置のペーシングバッファの状態に対する情報を含むペーシングバッファフィードバックメッセージを形成するステップと、
前記ペーシングバッファフィードバックメッセージを送信装置に伝送するステップと、
前記受信装置の前記ペーシングバッファからデコーディングバッファにパケットを伝送する速度(rate)に対する情報を含むペーシングバッファメッセージを受信するステップと、及び
前記ペーシングバッファメッセージに基づいて、前記パケットを前記ペーシングバッファから前記デコーディングバッファに伝達するステップと、を含み、
前記ペーシングバッファの状態に対する情報は、前記ペーシングバッファにバッファされたパケットのターゲット量に対する情報を含み、
前記ペーシングバッファフィードバックメッセージは、
前記ペーシングバッファフィードバックメッセージの識別子（ＩＤ）を示す情報、および、
前記ペーシングバッファフィードバックメッセージのバージョンを示す情報をさらに含む、
受信装置を作動させるための方法。

【請求項8】

前記ペーシングバッファの状態に対する情報は、前記ペーシングバッファにバッファされたパケットの量に対する情報を含む、
請求項７に記載の受信装置を作動させるための方法。

【請求項9】

前記送信装置は、前記ペーシングバッファフィードバックメッセージに基づいて前記受信装置にメディアデータのパケットを伝送する、
請求項７に記載の受信装置を作動させるための方法。

【請求項10】

前記送信装置は、
前記ペーシングバッファにバッファされた前記パケットの前記ターゲット量に対する情報に基づいて、メディアデータのパケットの伝送のために割り当てられた帯域幅を調整することによって、
前記受信装置に前記メディアデータの前記パケットを伝送する、
請求項７に記載の受信装置を作動させるための方法。

【請求項11】

前記ペーシングバッファの状態に対する情報は、前記ペーシングバッファの利用可能な空間の量に対する情報を含む、
請求項７に記載の受信装置を作動させるための方法。

【請求項12】

前記ペーシングバッファの状態に対する情報は、最後に受信されたパケットのシーケンス番号に対する情報を含む、
請求項７に記載の受信装置を作動させるための方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一般的に伝送システムにおけるメディアデータ配信に関し、より詳細にはレートペーシング(ｒａｔｅ ｐａｃｉｎｇ)のためにバッファを管理する装置及び方法に関する。

【背景技術】

【0002】

ＭＰＥＧ(Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ)メディアトランスポート(ＭＭＴ）は、異種インターネットプロトコル(ＩＰ)ネットワーク環境を通じてマルチメディアサービス用で符号化されたメディアデータを配信するための技術を規定するデジタルコンテナ標準又はフォーマットである。配信される符号化されたメディアデータは、指定された時間に同期化した復号化及び特定データ単位の表現を要請する視聴覚メディアデータ、すなわち時間設定型データ、及びサービスコンテキスト又はユーザーによる相互作用に基づいて任意の時間で復号化され提示される他のタイプのデータ、すなわち非時間設定型データの両方を含む。

【0003】

ＭＭＴは、符号化されたメディアデータがリアルタイムトランスポートプロトコル(ＲＴＰ)、伝送制御プロトコル(ＴＣＰ)、ユーザーデータグラムプロトコル(ＵＤＰ)のようなＩＰを用いてパケットベースの伝送ネットワークを介して配信されるという仮定の下で設計される。また、ＭＭＴは、多様な伝送環境の特性を考慮して設計される。例えば、各パケットの送信エンティティから受信エンティティへの配信のエンドツーエンド遅延が常に一定であるとは限らず、基本ネットワークプロバイダは、メディアデータからシグナリングメッセージを区別する方法を提供しなければならない。したがって、ＭＭＴメディアデータ伝送において改善された標準が必要である。

【発明の概要】

【発明が解決しようとする課題】

【0004】

したがって、本発明は上記した従来技術の問題点に鑑みてなされたものであって、その目的は、伝送システムにおいてメディアデータの配信を制御するためのデコーダ、デコード方法、及びサーバを提供することにある。

【課題を解決するための手段】

【0005】

上記目的を達成するために、本発明の一態様によれば、レートペーシングのためにバッファを管理するデコーダが提供される。上記デコーダは、メモリと、信号を送信及び受信するように構成される送受信機と、メモリ及び送受信機に動作可能に接続される処理回路とを含む。上記処理回路は、サーバからデコーダのペーシングバッファに対するドレインレートを示す除去レートメッセージをサーバから受信し、ドレインレートに従ってペーシングバッファからデコーダの復号化バッファへ受信されたパケットを提供する。

【0006】

本発明の他の態様によれば、レートペーシングのためにバッファを管理するデコード方法が提供される。この方法は、デコーダのペーシングバッファのドレインレートを示す除去レートメッセージをサーバから受信するステップを有する。また、この方法は、ドレインレートに従ってペーシングバッファからデコーダのデコーディングバッファにパケットを提供することを含む。

【0007】

本発明の他の態様によれば、デコーダにおけるレートペーシングのためにバッファを管理するサーバが提供される。このサーバは、メモリ、信号を送信及び受信するように構成された送受信機、及びメモリ及び送受信機に動作可能に接続される一つ以上のプロセッサを含む。

【0008】

本発明の詳細な説明に先立ち、本明細書の全般で使われる用語や語句を定義する。「〜含む(include)」、「〜からなる(comprise)」だけでなく、それらの派生語は限定のない包含を意味する。「又は(or)」は及び/又は(and/or)を含み、「〜に関連する(associated with)」、「それに関連する(associated therewith)」及びそれらの派生語句は、包含する(include)、含まれる(be included within)、受容される(be contained within)、連結する(connect to or with)、接続する(couple to or with)、通信する(be communication with)、協力する(cooperate with)、相互配置する(interleave)、並置する(juxtapose)、近接する(be approximate to)、結合する(be bound to or with)、所有する(have)、性質の所有をする(have a property of)、又は類以(the like)を意味し、「制御器(controller)」は少なくとも一つの動作を制御する装置、システム、又はその部分を意味し、そのような装置は、ハードウェア、ファームウェア、ソフトウェア、又はこれらのうちの少なくとも二つの組み合わせで実現することができる。特定の制御器に関連する機能は、集中しているか、あるいは近距離、又は遠距離に分散されることもある。特定の用語及び語句は本明細書の全体で使用されるが、当業者は多くの場合に上述したような定義が過去だけでなく未来の使用にも適用されることを理解しなければならない。

【0009】

本発明のより完全な理解及びそれに従う多くの利点は、添付された図面との結合を考慮すれば、後述する詳細な説明を参照してより容易に理解でき、上記図で同一の参照シンボルは同一又は類似した構成要素を示す。

【図面の簡単な説明】

【0010】

【図1】本発明の多様な実施形態が実現される伝送システムの一例を示す図である。

【図2】本発明の多様な実施形態によるコンピュータシステムの例示的な装置を示す図である。

【図3】本発明の多様な実施形態によるコンピュータシステムの例示的な装置を示す図である。

【図4】本発明の多様な実施形態によるＭＭＴメディアデータ伝送環境におけるＭＭＴプロトコル入/出力を示すブロック構成図である。

【図5】本発明の多様な実施形態による受信器の挙動(ｂｅｈａｖｉｏｒ)をシミュレーションするための受信器バッファモデルを示すブロック構成図である。

【図6】本発明の多様な実施形態によるモバイルビデオ配信のためのレートペーシングを使用する例示的な実現を示す図である。

【図7】本発明の多様な実施形態によるペーシングバッファを有する仮想受信器バッファモデル(ＨＲＢＭ）を示す図である。

【図8】本発明の一実施形態による伝送システムにおける送信エンティティを動作するためのプロセスを示す図である。

【図9】本発明の一実施形態による伝送システムにおける受信エンティティを動作するためのプロセスを示す図である。

【発明を実施するための形態】

【0011】

以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。

【0012】

後述される図１〜図９及び、本発明の原理を説明するために使用される多様な実施形態は、単にその実施例を示すものに過ぎず、本発明の範囲を限定するものとして捉えてはならない。本発明の原理が適切に配列されたシステム又はデバイスで実現できることは、当該技術分野で通常の知識を有する者には明らかである。

【0013】

ＭＭＴ符号化及びメディア伝送は、次の文献及び標準説明に論議されている。“ＩＳＯ/ＩＥＣ ＪＴＣ１/ＳＣ２９/ＷＧ１１，Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｃｏｄｉｎｇ ａｎｄ ｍｅｄｉａ ｄｅｌｉｖｅｒｙ ｉｎ ｈｅｔｅｒｏｇｅｎｅｏｕｓ ｅｎｖｉｒｏｎｍｅｎｔｓ-Ｐａｒｔ１：ｍｏｖｉｎｇ ｐｉｃｔｕｒｅ ｅｘｐｅｒｔｓ ｇｒｏｕｐ(ＭＰＥＧ) ｍｅｄｉａ ｔｒａｎｓｐｏｒｔ(ＭＭＴ)，Ｊｕｌｙ２０１２”この文献は、その全内容が本明細書中に参照として組み込まれている。異種ＩＰネットワーク環境を通じて符号化されたメディアデータを効率的かつ効果的に伝送するために、ＭＭＴは、次のような機能、すなわちマッシュアップ(ｍａｓｈ-ｕｐ)アプリケーションのための多様なコンポーネントからなるコンテンツを構成する論理モデル、パケット化及び適応のような伝送階層処理のために符号化されたメディアデータに関する情報を搬送するデータ構造、ハイブリッド伝送を含む伝送制御プロトコル(ＴＣＰ)又はユーザーデータグラムプロトコル(ＵＤＰ)を通じて使用される特定タイプのメディア又は符号化方法に関係なくメディアコンテンツを配信するパケット化方法及びパケット構造、メディアコンテンツの表示及び伝送を管理するためのシグナリングメッセージのフォーマット、及びクロス階層通信を容易にするために階層間に交換される情報のフォーマットを提供する。

【0014】

ＭＭＴは、カプセル化、伝送、及びシグナリングを含む３つの機能領域を定義する。カプセル化機能領域は、ＭＭＴコンプライアントエンティティにより処理されるメディアコンテンツ、ＭＭＴパッケージ、及びフォーマットデータユニットの論理構造を定義する。ＭＭＴパッケージは、適応的伝送に必要な情報を提供するためにメディアコンテンツとメディアコンテンツとの関係を含むコンポーネントを指定する。データユニットのフォーマットは、符号化されたメディアをカプセル化して伝送プロトコルのペイロードとして格納又は搬送し、格納と搬送との間で容易に変換されるように定義される。配信機能領域は、ペイロードのアプリケーション階層プロトコル及びフォーマットを定義する。アプリケーション階層プロトコルは、マルチメディア伝送のための従来のアプリケーション階層プロトコルに比べてＭＭＴパッケージの伝送のために多重化を含む強化された特徴を提供する。ペイロードフォーマットは、特定のメディアタイプ又は符号化方法に関係なく符号化されたメディアデータを搬送するように定義される。シグナリング機能領域は、ＭＭＴパッケージの伝送及び消費を管理するためのメッセージのフォーマットを定義する。消費管理のためのメッセージは、ＭＭＴパッケージの構造をシグナリングするために使用され、配信管理のためのメッセージは、ペイロードフォーマットの構造とプロトコル構成をシグナリングするために使用される。

【0015】

ＭＭＴは、オーディオ、ビデオ、及び他の静的コンテンツ、例えばウィジェット、ファイルのような持続的なマルチメディア伝送のための新たなフレームワークを定義する。ＭＭＴは、受信エンティティにＭＭＴパッケージを伝送するためのプロトコル(すなわち、ＭＭＴＰ）を特定する。ＭＭＴＰは、プロトコルヘッダーの一部としてＭＭＴＰパッケージの伝送時間をシグナリングする。この時間は、受信エンティティが各着信(ｉｎｃｏｍｉｎｇ)ＭＭＴパケットの伝送時間及び受信時間を検査することで、デジッタリングの実行を可能にする。

【0016】

本発明の実施形態では、メディアデータの受信のための環境条件が、伝送経路、伝送フォーマット、受信装置のタイプにより異なり、その結果、伝送と配信との間で遅延(例えば、エンドツーエンド遅延）を招くことを認識する。例えば、異なる伝送メディア(例えば、無線データ通信(ＬＴＥ、ＨＳＰＡ、３Ｇ、ＷｉＦｉなど)、物理的メディア(例えば、有線、ケーブル、イーサネット（登録商標）、光ファイバなど)、衛星ブロードキャストなど）は、異なる関連伝送遅延を有する。本発明の実施形態では、伝送遅延以外に、他のソースがジッタを起こすことを認識する。例えば、ＦＥＣ(Ｆｏｒｗａｒｄ Ｅｒｒｏｒ ｃｏｒｒｅｃｔｉｏｎ)復号化は、損失パケットの回復を可能にする追加遅延を挿入し、これは、十分なソース及びパリティパケットの受信を必要とする。遅延のもう一つの原因は、伝送中に実行される可能性のあるデータインターリービングである。また、本発明の実施形態では、受信装置コンポーネントも遅延に影響を与えることを認識する。メモリがより大きく、処理速度がより速いコンピュータのような装置は、メモリがより小さく、処理速度がより遅いセットトップボックスのような他の装置より少ない遅延を有する。

【0017】

本発明の実施形態において、ブロードキャスト環境のような特定環境では、送信から受信エンティティでＭＭＴ処理スタックを離れるまで、それぞれの伝送されたパケットがポイントツーマルチポイント伝送システムにわたって同一の遅延を経験する固定したエンドツーエンド遅延を有することが重要であることを認識する。例えば、本発明の実施形態では、同一のプログラムを受信するすべてのクライアントが装置、プロトコル、又は伝送メディア実現に関係なく同一の時間で同一のコンテンツを提示することを提供し、あるいはこれを保証することが重要であることを認識する。また、受信器のハードウェア実現を可能にするために、本発明の実施形態は、固定したパケット伝送遅延を保証するために必要なメモリ空間上の上限が提供される必要があると認識する。ネットワークの特性及びサービス設定により、ＭＭＴパケットは、広範囲なジッタにさらされ、その結果、異なるバッファ要求事項が発生する。例えば、大きいソースブロックでＦＥＣ保護を提供し、インターネットを介して搬送されるサービスは、ＦＥＣ保護なしに管理されたブロードキャストを通じて搬送されるサービスより多くのバッファリングが要求される。

【0018】

そのため、ジッタ量の変動が非常に大きく、あるいはジッタの最大量をＭＭＴ送信エンティティに知らせることができない場合、現在のＭＭＴＰ ＨＲＢＭは、効率的な解決策であり得ない。この場合、ＭＭＴ送信エンティティは、ＨＲＢＭを含むことなく、その最大使用可能な帯域幅にパケットを単に伝送するようになり、それによってＭＭＴ受信エンティティが消費前にある程度の時間でデータをバッファリングし、パケットが時間内に受信されない場合には最初にバッファリングされたデータが消費される。

【0019】

したがって、本発明の実施形態では、ペーシングバッファのレベルを効率的に管理するために、ＭＭＴ送信エンティティ及びＭＭＴ受信エンティティにメッセージを提供し、ペーシング及びシグナリングする方法及び装置を提供する。

【0020】

図１は、本発明の多様な実施形態が実現される伝送システム１００の一例を示す。図示の実施形態では、システム１００は、送信エンティティ１０１、ネットワーク１０５、受信エンティティ１１０、基地局(ＢＳ）１０２、ＢＳ１０３、及び他の類似した基地局又は中継局のような無線伝送ポイント(例えば、進化したノードＢ(ｅＮＢ)、ノードＢ）を含む。送信エンティティ１０１は、例えばインターネット、メディアブロードキャストネットワーク、又はＩＰベースの通信システムであるネットワーク１０５を介して基地局１０２及び基地局１０３と通信している。受信エンティティ１１０は、ネットワーク１０５及び/又は基地局１０２及び１０３を通じて送信エンティティ１０１と通信している。受信エンティティ１１０は、ユーザー端末１１１〜１１６を含むことができる。

【0021】

基地局１０２は、そのカバレッジ領域１２０内の第１の複数の受信エンティティ(例えば、ユーザー端末、移動電話、移動局、及び加入局)にネットワーク１０５への無線アクセスを提供する。第１の複数の受信エンティティは、中小企業(ＳＢ)に位置するユーザー端末１１１、大企業(Ｅ)に位置するユーザー端末１１２、ＷｉＦｉホットスポット(ＨＳ）に位置するユーザー端末１１３、第１の住居地域(Ｒ)に位置するユーザー端末１１４、第２の住居地域(Ｒ)に位置するユーザー端末１１５、及びセルラー電話、無線通信可能なラップトップ、無線通信可能なＰＤＡ、タブレットコンピュータのようなモバイル装置(Ｍ)であるユーザー端末１１６を含む。

【0022】

基地局１０３は、そのカバレッジ領域１２５内の第２の複数のユーザー端末にネットワーク１０５への無線アクセスを提供する。第２の複数のユーザー端末は、ユーザー端末１１５及びユーザー端末１１６を含む。実施形態において、基地局１０１-１０３は、ＯＦＤＭ又はＯＦＤＭＡ技術を用いて相互に及びユーザー端末１１１〜１１６と通信することができる。

【0023】

図１では６個のユーザー端末のみを示したが、システム１００は、追加的なユーザー端末に対する無線広帯域及びネットワークアクセスを提供できる。ユーザー端末１１５及びユーザー端末１１６は、カバレッジ領域１２０及びカバレッジ領域１２５のエッジに位置する。ユーザー端末１１５及びユーザー端末１１６は、それぞれ基地局１０２及び基地局１０３の両方と通信し、当業者に公知されているように、ハンドオフモードで動作すると言える。

【0024】

ユーザー端末１１１〜１１６は、ネットワーク１０５を介して音声、データ、ビデオ、ビデオ会議、及び/又は他の広帯域サービスにアクセスする。一実施形態では、ユーザー端末１１１〜１１６のうちの一つ以上は、ＷｉＦｉ ＷＬＡＮのアクセスポイント(ＡＰ)に関連される。ユーザー端末１１６は、無線可能なラップトップコンピュータ、ＰＤＡ(Ｐｅｒｓｏｎａｌ Ｄａｔａ Ａｓｓｉｓｔａｎｔ)、ノートブック、携帯用装置、又は他の無線可能な装置を含む複数の移動装置のうちのいずれか一つである。ユーザー端末１１４及び１１５は、例えば無線可能な個人用コンピュータ(ＰＣ)、ラップトップコンピュータ、ゲートウェイ、又は他の装置である。

【0025】

図２及び図３は、本発明によるコンピュータシステム内の例示的な装置を示す。特に、図２は例示的なサーバ２００を示し、図３は例示的なクライアント装置３００を示す。サーバ２００は、図１の送信エンティティ１０１、基地局１０２、又は基地局１０３を示し、クライアント装置３００は、図１の一つ以上のユーザー端末１１１〜１１６を含む受信エンティティ１１０を示す。

【0026】

図２に示すように、サーバ２００は、一つ以上のプロセッサ２１０、少なくとも一つの記憶装置２１５、少なくとも一つの通信インターフェース２２０、及び少なくとも一つのＩ／Ｏユニット２２５間の通信をサポートするバスシステム２０５を含む。

【0027】

プロセッサ２１０は、メモリ２３０にローディングされる命令を実行する。プロセッサ２１０は、任意の適切な個数及びタイプのプロセッサ又は他の装置を任意の適切な配列で含むことができる。例示的なタイプのプロセッサ２１０は、マイクロプロセッサ、マイクロ制御器、デジタル信号プロセッサ、フィールドプログラマブルゲートアレイ、特定用途向け集積回路、及び離散回路を含む。プロセッサ２１０は、レートペーシングのためにバッファを管理するように構成される。

【0028】

メモリ２３０及び永続ストレージ２３５は、情報(例えば、データ、プログラムコード、及び/又は一時的又は永久的基盤の他の適切な情報)を格納し、容易に検索可能な任意の構造を示す記憶装置２１５の例である。メモリ２３０は、ランダムアクセスメモリ又は任意の他の適切な揮発性又は不揮発性格納装置を示す。永続ストレージ２３５は、読み出し専用メモリ、ハードドライブ、フラッシュメモリ、又は光学ディスクのようなデータの長期的な格納をサポートする一つ以上のコンポーネント又は装置を含むことができる。

【0029】

通信インターフェース２２０は、他のシステム又は装置との通信をサポートする。例えば、通信インターフェース２２０は、ネットワーク１０５を介して通信を容易にするネットワークインターフェースカード又は無線送受信機を含む。通信インターフェース２２０は、任意の適した物理的又は無線通信リンクを通じる通信をサポートできる。

【0030】

Ｉ／Ｏユニット２２５は、データの入力及び出力を許容する。例えば、Ｉ／Ｏユニット２２５は、キーボード、マウス、キーパッド、タッチスクリーン、又は他の適切な入力装置を通じるユーザー入力のための接続を提供できる。Ｉ／Ｏユニット２２５は、出力をディスプレイ、プリンタ、又は他の適切な出力装置に送信する。

【0031】

このような実施形態において、サーバ２００は、以下により詳細に説明するように、受信エンティティ１１０又はユーザー端末１１１〜１１６でのレートペーシングのためのバッファ管理を提供する装置を実現する。図２は、図１の送信エンティティ１０１、基地局１０３、又は基地局１０２を示すことを説明したが、同一の又は類似した構造が一つ以上のユーザー端末１１１〜１１６を含む受信エンティティ１１０に使用されることに留意しなければならない。例えば、ラップトップ又はデスクトップコンピュータが図２の図示と同一の構造又は類似した構造を有する。

【0032】

図３に示すように、受信エンティティ１１０又はＵＥ１１１〜１１６のようなクライアント装置３００は、アンテナ３０５、無線周波数(ＲＦ)送受信機３１０、送信(ＴＸ)処理回路３１５、マイクロホン３２０、及び受信(ＲＸ)処理回路３２５を含む。クライアント装置３００は、スピーカ３３０、一つ以上のプロセッサ３４０、入／出力(Ｉ／Ｏ)インターフェース(ＩＦ)３４５、キーパッド３５０、ディスプレイ３５５、及びメモリ３６０を含む。メモリ３６０は、基本オペレーティングシステム(ＯＳ)プログラム３６１及び一つ以上のアプリケーション３６３を含む。

【0033】

ＲＦ送受信機３１０は、アンテナ３０５からシステムの他のコンポーネントにより送信された着信(ｉｎｃｏｍｉｎｇ)ＲＦ信号を受信する。ＲＦ送受信機３１０は、着信ＲＦ信号をダウンコンバートして中間周波数(ＩＦ)又はベースバンド信号を生成する。ＩＦ又はベースバンド信号は、このベースバンド又はＩＦ信号をフィルターリング、復号化、及び/又はデジタル化することによって処理されたベースバンド信号を生成するＲＸ処理回路３２５に送信される。ＲＸ処理回路３２５は、処理されたベースバンド信号を(例えば、音声データのために)スピーカ３３０に送信するか、あるいは(Ｗｅｂブラウジングデータのような)追加処理のためにプロセッサ３４０に送信する。

【0034】

ＴＸ処理回路３１５は、マイクロホン３２０からアナログ又はデジタルデータを受信し、あるいはプロセッサ３４０から他の発信（ｏｕｔｇｏｉｎｇ)ベースバンドデータ(例えば、Ｗｅｂデータ、ｅメール、又は双方向ビデオゲームデータ)を受信する。ＴＸ処理回路３１５は、出力ベースバンドデータを符号化、多重化、及び／又はデジタル化し、処理されたベースバンド又はＩＦ信号を生成する。ＲＦ送受信機３１０は、ＴＸ処理回路３１５から出力処理されたベースバンド又はＩＦ信号を受信し、そのベースバンド又はＩＦ信号を、アンテナ３０５を通じて送信されるＲＦ信号にアップコンバートする。

【0035】

プロセッサ３４０は、一つ以上のプロセッサ又は他の処理装置を含むことができ、クライアント装置３００の全体動作を制御するためにメモリ３６０に格納された基本ＯＳプログラム３６１を実行できる。例えば、プロセッサ３４０は、よく知られている原理によってＲＦ送受信機３１０、ＲＸ処理回路３２５、及びＴＸ処理回路３１５による順方向チャンネル信号の受信及び逆方向チャンネル信号の送信を制御する。一部実施形態において、プロセッサ３４０は、少なくとも一つのマイクロプロセッサ又はマイクロ制御器を含む。

【0036】

また、プロセッサ３４０は、メモリ３６０に常駐するプログラム及び他のプロセスを実行し、例えばレートペーシングのためにバッファを管理する動作を実行することができる。プロセッサ３４０は、実行プロセスによるリクエストによってメモリ３６０の内部又は外部にデータを移動させる。一部実施形態では、プロセッサ３４０は、外部装置又はオペレータから受信された信号に応答して又はＯＳプログラム３６１に基づいてアプリケーション３６３を実行するように構成される。プロセッサ３４０は、他のデバイス、例えばラップトップコンピュータ及びハンドヘルドコンピュータへの接続能力をクライアント装置３００に提供するＩ／Ｏインターフェース３４５にカップリングされる。Ｉ／Ｏインターフェース３４５は、このような付属品とプロセッサ３４０との間の通信経路である。

【0037】

プロセッサ３４０は、キーパッド３５０及びディスプレイ３５５にもカップリングされる。クライアント装置３００のオペレータは、キーパッド３５０を用いてデータをクライアント装置３００に入力できる。ディスプレイ３５５は、例えばＷｅｂサイトからのテキスト及び/又は少なくとも限定されたグラフィックをレンダリングする液晶ディスプレイ又は他のディスプレイでありうる。

【0038】

メモリ３６０は、プロセッサ３４０にカップリングされる。メモリ３６０の一部は、ランダムアクセスメモリ(ＲＡＭ)を含み、メモリ３６０の他の一部はフラッシュメモリ又は他の読み出し専用メモリ(ＲＯＭ)を含むことができる。

【0039】

以下により詳細に説明されるように、この例示的な実施形態において、クライアント装置３００は、ネットワーク１０５を介して送信エンティティ１０１、基地局１０２、又は基地局１０３と着信呼(ｉｎｃｏｍｉｎｇ ｃａｌｌ)を開始又は受信する装置を実現する。図２及び図３がコンピュータシステム内の装置に関する実施形態を示すが、多様な変更が図２及び図３に対してなされることができる。例えば、図２及び図３の多様なコンポーネントが結合され、さらに細分化され、あるいは省略され、追加コンポーネントが特定の必要事項に従って付加される。特定の例として、プロセッサ３４０は、複数のプロセッサ、例えば一つ以上の中央処理装置(ＣＰＵ)及び一つ以上のグラフィック処理装置(ＧＰＵ）に分割される。さらに、図３が移動電話又はスマートフォンで構成されたクライアント装置３００を示したが、クライアント装置は、他のタイプの移動又は停止装置として動作するように構成される。さらに、コンピュータ及び通信ネットワークと同様に、クライアント装置及びサーバは、多様な構成で提供され、図２及び図３は、任意の特定クライアント装置又はサーバに本発明を限定するものではない。

【0040】

図４は、本発明の多様な実施形態によるＭＭＴメディアデータ伝送環境４００におけるＭＭＴプロトコル入／出力を示すブロック構成図である。一実施形態において、送信エンティティ４０５は、ＭＭＴＰによって伝送媒体を通じて受信エンティティ４１０にメディアデータを送信する。メディアデータ４１５は、ＭＭＴＰによって送信エンティティ４０５で処理される。例えば、送信エンティティ４０５は、メディアデータに対するＭＭＴパッケージカプセル化、符号化、配信、及びシグナリングをＭＭＴ処理ユニット(ＭＰＵ)及びＭＭＴフラグメント化ユニット(ＭＦＵ)４１５(例えば、ＭＰＵのフラグメント)として実行する。その次に、処理されたメディアデータは、ＭＭＴＰによって処理(例えば、デカプセル化、復号化)するために受信エンティティ４１０に(例えば、パケットとして)送信される。その後、受信エンティティ４１０で処理されたメディアデータは、メディアデータの配信を完了したユーザーにプレゼンテーションするためにＭＰＵ及び/又はＭＦＵとして上位階層プログラミング(例えば、メディアプレーヤーのようなアプリケーション階層プログラム)に伝送される。

【0041】

図５は、本発明の多様な実施形態により送信器側で受信器の挙動をシミュレーションし、バッファ遅延及びサイズ要求事項を推定するための受信器バッファモデル５００を示すブロック構成図である。本発明の多様な実施形態において、メディア−伝送サーバ(又は他のＭＭＴ認識ノード)のような送信エンティティ４０５は、ポイントツーマルチポイント伝送システムにおいて、メディアデータ伝送のための固定したエンドツーエンド遅延を計算、決定、及び/又は識別する。例えば、送信エンティティ４０５は、モデル５００を用いて、受信エンティティ４１０の受信器における受信制約上でのパケットストリーム上で実行されたメディアデータ処理の効果を決定できる。例えば、送信エンティティ４０５は、このモデルを用いて必要なバッファリング遅延及び必要なバッファサイズを決定し、この情報をメディアデータを受信するエンティティに伝える。

【0042】

この実施形態において、ＦＥＣ復号化バッファ５０５は、ＦＥＣ復号化に関連した遅延及び／又はバッファサイズ要請事項を推定するためのモデルである。ＦＥＣ復号化は、チャンネル誤りから回復するのに下位階層伝送では十分でなく、あるいはネットワーク停滞によってパケット損失又は過度な遅延が発生する複数のアプリケーションで一般的である。ＦＥＣ復号化を実行するために、受信エンティティ４１０は、十分なソース(“Ｓ”)及びリペアデータ(“Ｐ”パリティデータ)がＦＥＣ復号化の実行のために利用可能であるまで着信パケットが格納されているバッファを使用する。

【0043】

一実施形態において、送信エンティティ４０５は、ＦＥＣ復号化バッファ５０５のモデルを使用し、ＦＥＣ復号化に関連した遅延を推定するために受信エンティティ４１０がＦＥＣ復号化に関して実行する動作を決定する。言い換えれば、送信エンティティ４０５は、ＦＥＣ復号化バッファ５０５のモデルを使用し、ＦＥＣ復号化遅延を推定するために受信エンティティ４１０により実行される動作を予測する。このような送信エンティティ４０５によるＦＥＣ復号化バッファ５０５のモデリングは、ＦＥＣ復号化バッファ５０５が初期段階には空いているとの仮定で始まる。次に、受信エンティティ４１０は、伝送タイムスタンプｔ_sを有するそれぞれの着信パケットｉに対して、ｂｕｆｆｅｒ＿ｏｃｃｕｐａｎｃｙ＋ｐａｃｋｅｔ＿ｓｉｚｅ＜ｍａｘ＿ｂｕｆｆｅｒ＿ｓｉｚｅである場合、ＦＥＣ復号化バッファ５０５を用いてパケットｉをバッファリングする。そうでない場合、受信エンティティ４１０は、バッファモデルに適合しないものとしてパケットｉを廃棄する。その後に、受信エンティティ４１０は、ＦＥＣがパケットｉに適用されるか否かを判定する。ＦＥＣがパケットｉに適用される場合、受信エンティティ４１０は、パケットｉが属するソースブロックｊを決定し、ソースブロックｊの第１のパケットの挿入時間ｔを決定し、時間ｔ＋ＦＥＣ＿ｂｕｆｆｅｒ＿ｔｉｍｅでソースブロックｊのすべてのパケットをデジッタバッファに移動させ(ＦＥＣ訂正後、必要に応じて)、リペアパケットを廃棄する。送信エンティティ４０５は、ＦＥＣ復号化が試みられるまで、ソースブロックの第１のパケットの受信からＦＥＣ復号化に必要なバッファ時間としてＦＥＣ＿ｂｕｆｆｅｒ＿ｔｉｍｅを利用する。この時間は、一般的にＦＥＣブロックサイズに基づいて計算される。

【0044】

デジッタバッファ５１０は、パケットのデジッタリング、すなわちパケットの遅延ジッタの除去に関連する遅延及び／又はバッファサイズ要求事項を推定するために送信エンティティ４０５により使用されるモデルである。デジッタバッファ５１０は、最後にＭＭＴＰパケットがソースからＭＭＴＰプロトコルスタックの出力に固定した伝送遅延を経験することを保証することで、最大伝送遅延を仮定する。受信エンティティ４１０は、最大伝送遅延より大きい伝送遅延を経験するデータユニットを非常に遅いものとして廃棄する。

【0045】

送信エンティティ４０５によるデジッタバッファ５１０のモデリングは、デジッタバッファが初期段階では空いているとの仮定で始まる。その後、受信エンティティ４１０は、パケットが到着するときにＭＭＴＰパケットをデジッタバッファ５１０に挿入する。その次に、受信エンティティ４１０は、時間ｔ_s＋ΔでＭＭＴＰパケットを除去し、ここでｔ_sはＭＭＴＰパケットの伝送タイムスタンプであり、Δはメディアデータに対してシグナリングされる固定したエンドツーエンド遅延である。デジッタリングが適用された後に、正確に到着した(又はＦＥＣ/再伝送を通じて回復された)すべてのＭＭＴＰパケットは、同一のエンドツーエンド遅延を経験するようになる。

【0046】

ＭＭＴＰデカプセル化バッファ５１５は、出力を上位階層に伝達する前にＭＭＴＰ処理に関連する遅延及び/又はバッファサイズ要求事項を推定するために送信エンティティ４０５により使用されるモデルである。ＭＭＴＰプロセッサの出力は、ＭＦＵペイロード(低遅延動作で)、完全なムービーフラグメント、又は完全なＭＰＵでありうる。ＭＰＵは、これらのサイズに従って、より小さいパケットにフラグメント化され、あるいはより大きいパケットにアグリゲートされる。ＭＭＴＰ処理の一部として、デカプセル化(ＭＭＴＰパケット及びペイロードヘッダの除去)及び任意の必要なデフラグメント化／デアグリゲーションが実行される。この手順では、ＭＰＵが複数のＭＭＴＰパケットにフラグメント化される場合、アセンブリを実行するためにデカプセル化遅延と呼ばれるいくつかのバッファリング遅延を必要とする。しかしながら、この実施形態において、デカプセル化遅延は、固定したエンドツーエンド遅延の一部として考慮されず、符号化されたメディア階層による消費のためのＭＰＵの使用可能性は、デカプセル化遅延に関係なく、ＭＰＵを複数のＭＭＴＰパケットにフラグメント化するエンティティにより保証される。

【0047】

ＭＭＴＰ ＨＲＢＭは、ＭＭＴ送信エンティティがＭＭＴ受信エンティティのバッファ状態を正確に管理可能にする。ＭＭＴＰ ＨＲＢＭを使用することによって、基本伝送ネットワークにジッタが多い場合にも、メディアサービスのシームレスな低遅延消費が保証される。その動作のために、ＭＭＴＰ ＨＲＢＭは、基本伝送ネットワークの全般的な固定したエンドツーエンド遅延を、予めＭＭＴ送信エンティティに知らせるための一つのパラメータを要求する。図５に示すように、ＭＭＴＰ ＨＲＢＭは、３個のバッファで構成され、固定したエンドツーエンド遅延、ＦＥＣ作動及び基本伝送ネットワークの帯域幅変動によるジッタにより引き起こされる遅延の２つの要因が存在する。ＦＥＣ作動による遅延量がＭＭＴＰ送信エンティティにより決定されることを考慮すれば、固定したエンドツーエンド遅延の量をわかることは、基本伝送ネットワークのジッタの最大量をわかることを意味する。

【0048】

したがって、ジッタ量の変動が非常に大きいか、あるいはジッタの最大量がＭＭＴ送信エンティティに知らされない場合には、現在のＭＭＴＰ ＨＲＢＭは効率的な解決策ではない。この場合に、ＭＭＴ送信エンティティは、ＨＲＢＭを包含せず、その最大使用可能な帯域幅でパケットを単に配信するようになり、それによってＭＭＴ受信エンティティが消費前の所定時間でデータをバッファリングし、パケットが時間内に受信されない場合に最初にバッファリングされたデータを消費することができる。

【0049】

図５は送信器側で受信器の挙動をシミュレーションするための受信器バッファモデル５００の一例を示したが、多様な変更が図５に対してなされてもよい。例えば、図５の多様なコンポーネントが結合され、さらに細分化され、又は省略されることができ、追加コンポーネントが特定の必要によって付加されうる。

【0050】

図６は、本発明の多様な実施形態によるモバイルビデオ伝送のためのレートペーシングを使用する例示的な実現(６００）を示す。

【0051】

ペーシングは、バッファ状態及び再生に基づいてストリーミングビット率を調整することによって、プッシュ伝送システムにおいてクライアント側で浪費されるデータを減少させる技術である。図６の左側部分は、ＭＭＴＰ送信エンティティがメディア消費より大きい帯域幅でデータを配信し、それによって過度な量のバッファリングされたデータ６０５がＭＭＴ受信エンティティに格納される場合の一例を示す。モバイル環境のためのＩＳＯ/ＩＥＣ２３００８-１ＡＭＤ２ＭＭＴ改善で論議されたように、多くの場合において、ユーザーが終了するまでビデオを見ないことで、このような過度なデータが実際には消費されず、つまり、リソースが浪費される。このようなリソースの浪費を最小化するために、ペーシング方法は、図６の右側に示すように適用される。ＭＭＴ受信エンティティは、ＭＭＴ送信エンティティが送信帯域幅を制御可能にするためにクライアントでバッファリングされたデータ量６１０をＭＭＴ送信エンティティに通知する。

【0052】

図６がモバイルビデオ伝送のためのレートペーシングを使用する例示的な実現(６００）の一例を示したが、多様な変更が図６に対してなされる。例えば、図６の多様なコンポーネントが結合され、より細分化され、又は省略され、追加コンポーネントが特定の必要事項によって付加されうる。

【0053】

図７は、本発明の多様な実施形態によるペーシングバッファを有する仮想受信器バッファモデル(ＨＲＢＭ)７００を示す。ＨＲＢＭ７００は、ＭＭＴＰペーシングバッファ７０５、ＦＥＣ復号化バッファ７１０、デジッタバッファ７１５、及びＭＭＴＰデカプセル化バッファ７２０を含む。ＦＥＣ復号化バッファ７１０、デジッタバッファ７１５、及びＭＭＴＰデカプセル化バッファ７２０は、図５に示したＦＥＣ復号化バッファ５０５、デジッタバッファ５１０、及びＭＭＴＰデカプセル化バッファ５１５と類似に機能する。

【0054】

ペーシングバッファ７０５を組み込むことを考慮して、ＭＭＴＰ ＨＲＢＭ７００の固定したエンドツーエンド遅延の値は、ＦＥＣ動作により寄与する遅延の値に設定される。それぞれのＭＭＴＰパケットは、任意の追加処理以前に、受信エンティティ４１０により決定される特定時間でペーシングバッファ７０５に格納される。各ＭＭＴＰパケットを格納する時間の量は、受信エンティティ４１０により決定され、それによってペーシングバッファに格納されたＭＭＴＰパケットの量をペーシングバッファ状態フィードバック(ＰＳＦ)メッセージのｔａｒｇｅｔ＿ｐａｃｉｎｇ＿ｂｕｆｆｅｒ＿ｌｅｖｅｌ値に維持し、復号化バッファ７１０に対するパケットの伝送レートをペーシングバッファ除去レート(ＰＲＲ)メッセージのｐａｃｉｎｇ＿ｂｕｆｆｅｒ＿ｒｅｍｏｖａｌ＿ｒａｔｅ値に維持する。ＦＥＣ復号化バッファ７１０に配信される各ＭＭＴＰパケットのタイムスタンプフィールドの値は、パケットがペーシングバッファ７０５に格納される時間の量だけ増加する。

【0055】

ＰＲＲメッセージは、ペーシングバッファ７０５のドレインレートに関する情報を提供する。ＰＲＲメッセージを送信エンティティ４０５に伝送することによってペーシングバッファ７０５が使用される場合、ＰＲＲメッセージがシグナリングされる。ＰＲＲメッセージがシグナリングされると、ＭＭＴ受信エンティティ４１０は、メッセージで特定されたレートでペーシングバッファ７０５内のパケットをＦＥＣ復号化バッファ７１０に伝送する。次の＜表１＞は、ＰＲＲメッセージ構文を示す。

【0056】

【表1】

ｍｅｓｓａｇｅ＿ｉｄフィールドは、ＰＲＲメッセージの識別子を示す。バージョンフィールドは、ＰＲＲメッセージのバージョンを示す。ＭＭＴ受信エンティティ４１０は、このフィールドを用いて受信されたＰＲＲメッセージのバージョンを検証する。長さフィールドは、次のフィールドの第１のバイトからＰＲＲメッセージの最後のバイトまでカウントする、典型的にはバイト単位のＰＲＲメッセージの長さを示す。‘０’の値は、長さフィールドで有効でない。ｐａｃｉｎｇ＿ｂｕｆｆｅｒ＿ｒｅｍｏｖａｌ＿ｒａｔｅフィールドは、ペーシングバッファ７０５からＦＥＣ復号化バッファ７１０にＭＭＴＰパケットを配信するためのドレインレートを示す。

【0057】

ＭＭＴＰペーシングバッファ７０５のサイズ及び各ＭＭＴＰパケットがＭＭＴＰペーシングバッファ７０５に格納される時間の量はＭＭＴ受信エンティティ４１０により決定されるので、ＭＭＴ受信エンティティ４１０は、送信エンティティ４０５によりリクエストされる場合、送信エンティティ４０５によりリクエストされた頻度でＰＳＦメッセージを送信エンティティ４０５に送信する。ＭＭＴ受信エンティティ４１０は、ＭＭＴＰペーシングバッファレベルの状態を追跡し、各ＭＭＴＰパケットが送信される時間を決定することによって、ＭＭＴＰペーシングバッファ７０５に格納される超過データの量を制御する。次の＜表２＞は、ＰＳＦメッセージの構文を示す。

【0058】

【表2】

ｍｅｓｓａｇｅ＿ｉｄフィールドは、ＰＳＦメッセージの識別子を含む。例えば、ｍｅｓｓａｇｅ＿ｉｄフィールドは、１６ビットの長さを有する。バージョンフィールドは、ＰＳＦメッセージのバージョンを示す。受信エンティティ４１０は、このフィールドを使用して受信されたメッセージのバージョンをチェックする。例えば、バージョンフィールドは、８ビットの長さを有する。長さフィールドは、次のフィールドの第１のバイトからＰＳＦメッセージの最後のバイトまでカウントする、典型的にはバイト単位のＰＳＦメッセージの長さを示す。このフィールドの長さは、１６ビットであり、‘０’の値はこのフィールドに有効でない。ｃｕｒｒｅｎｔ＿ｐａｃｉｎｇ＿ｂｕｆｆｅｒ＿ｌｅｖｅｌは、ペーシングバッファ７０５に現在バッファリングされたＭＭＴＰパケットの量を、ＭＭＴ送信エンティティ４０５に指示する。ｔａｒｇｅｔ＿ｐａｃｉｎｇ＿ｂｕｆｆｅｒ＿ｌｅｖｅｌは、ペーシングバッファ７０５にバッファリングされるＭＭＴＰパケットの目標量を、送信エンティティ４０５に指示する。送信エンティティ４０５は、この目標量を達成するためにＭＭＴＰパケットの伝送に割り当てられる帯域幅を調整する。ｌａｓｔ＿ｒｅｃｅｉｖｅｄフィールドは、特定のＭＭＴＰサブフローにおいて最後に受信されたＭＭＴＰパケットシーケンス番号を、送信エンティティ４０５に指示する。ｐａｃｉｎｇ＿ｂｕｆｆｅｒ＿ｆｒｅｅ＿ｓｐａｃｅフィールドは、ペーシングバッファ７０５の利用可能な空間の量を、バイト単位で送信エンティティに指示する。

【0059】

測定構成メッセージが送信エンティティ４０５から受信エンティティ４１０に伝送されることによって、ペーシングバッファの状態を報告するＰＳＦメッセージのリクエストが指示される。また、測定構成メッセージは、ＰＳＦメッセージを送信するための頻度を受信エンティティ４１０に示すことができる。ＰＳＦ報告に対するリクエストを示すフラグは"００００ ００００ ００００ １０００"として定義される。このフラグが１に設定される場合、現在の再生状態に関するＰＳＦメッセージを送信エンティティ４０５に送信することが受信エンティティ４１０に要請される。

【0060】

図７が本発明の多様な実施形態によるペーシングバッファを有する仮想受信器バッファモデル(ＨＲＢＭ)７００の一例を示したが、多様な変更が図７に対してなされることができる。例えば、図７の多様なコンポーネントが結合され、あるいはより細分化され、又は省略され、追加コンポーネントが特定の必要事項によって付加されうる。

【0061】

図８は、本発明の実施形態による伝送システムにおける送信エンティティを動作させるプロセスを示すフローチャートである。例えば、図８に示すプロセスは、図２のサーバ２００又は図４の送信エンティティ４０５により実行される。このプロセスは、図１の送信エンティティ１０１により実現される。

【0062】

ステップ８０５において、送信エンティティ４０５は、受信エンティティ４１０内のペーシングバッファに対するドレインレートを決定する。受信エンティティ４１０は、パケットの量又はビデオの時間量に基づいてペーシングバッファのサイズを決定する。ドレインレートは、例えばビデオのサイズ、バッファのサイズ、データストリームのレートに従って決定される。特定の実施形態では、ペーシングバッファの使用が受信エンティティ４１０によりシグナリングされる。

【0063】

ステップ８１０において、送信エンティティ４０５は、ペーシングバッファを示す信号の受信に応答して、デコーダのペーシングバッファのドレインレートを示すＰＲＲメッセージを送信する。ＰＲＲメッセージは、パケットがＦＥＣ復号化バッファ７１０に伝送されるドレインレートを受信エンティティ４１０に指示する。

【0064】

ステップ８１５において、送信エンティティ４０５は、ＰＳＦメッセージを構成するための測定構成メッセージを送信する。測定構成メッセージは、受信エンティティ４１０にＰＳＦメッセージを送信することを指示するか、又は、ＰＳＦメッセージを送信するための頻度を送信することを指示する。特定の環境で、この構成メッセージは、所定の時間又は要因(ｆａｃｔｏｒ)で伝送される初期メッセージを示す。例えば、測定構成メッセージは、ペーシングバッファが特定のパーセントまで満されたときに、ＰＳＦメッセージの伝送を開始するように指示する。さらに、測定構成メッセージは、受信エンティティ４１０が特定のしきい値に基づいてメッセージを送信するように指示できる。例えば、受信エンティティは、ペーシングバッファ７０５がいっぱいになったときにＰＳＦメッセージを送信するように指示されるか、あるいは、送信エンティティがＰＳＦメッセージを受信したときにペーシングバッファが満たさせることを示すしきい値までペーシングバッファ７０５が満たされたときにＰＳＦメッセージを送信するように指示される。また、受信エンティティ４１０は、ペーシングバッファが空いていることを示すＰＳＦを送信するように指示されるか、あるいは、送信エンティティ４０５がＰＳＦを受信したときにペーシングバッファ７０５が空いていることを示すしきい値までペーシングバッファが満たされているときにＰＳＦメッセージを送信するように指示される。他の実施形態において、ペーシングバッファ７０５がいっぱいになることを示すＰＳＦメッセージが送信されることを指示した後に、ペーシングバッファ７０５がしきい値以下に落ちたときにＰＳＦメッセージが送信される。例えば、このしきい値は、バッファがビデオを遅延させないことを保証するために５０〜７５％でありうる。

【0065】

ステップ８２０において、送信エンティティ４０５は、デコーダからＰＳＦメッセージを受信する。送信エンティティ４０５は、現在のペーシングバッファレベル、目標ペーシングバッファレベル、最後に受信されたパケット及び空きバッファ領域を含むＰＳＦに含まれた情報に基づいてデータのストリームを制御する。

【0066】

図９は、本発明の一実施形態による伝送システムにおける受信エンティティを動作させるプロセスを示すフローチャートである。例えば、図９に示すプロセスは、図３のクライアント装置３００又は図４の受信エンティティ４１０により実行される。また、このプロセスは、図１の受信エンティティ１１０により実現される。

【0067】

ステップ９０５において、受信エンティティ４１０は、送信エンティティ４０５に信号を伝送し、受信エンティティ４１０におけるペーシングバッファの使用がペーシングバッファ７０５のドレインレートを決定することを示す。特定の実施形態において、受信エンティティ４１０は、パケットの量又はビデオの時間量に基づいてペーシングバッファのサイズを決定することができる。ドレインレートは、例えば、ビデオのサイズ、バッファのサイズ、及びデータストリームのレートに基づいて決定される。

【0068】

ステップ９１０において、受信エンティティ４１０は、ペーシングバッファのドレインレートを示すＰＲＲメッセージを送信エンティティ４０５に受信する。ＰＲＲメッセージは、パケットがＦＥＣ復号化バッファ７１０に送信されるドレインレートを受信エンティティ４１０に指示する。

【0069】

ステップ９１５において、受信エンティティ４１０は、測定構成メッセージを受信する。測定構成メッセージは、ＰＳＦメッセージを送信すること、又は、ＰＳＦメッセージを送信するための頻度を送信することを受信エンティティ４１０に指示する。特定環境で、この測定構成メッセージは、特定時間又は要因で伝送される初期メッセージを示すことができる。例えば、測定構成メッセージは、ペーシングバッファが特定パーセントまで満たされたときに、ＰＳＦメッセージの伝送を開始するように指示する。測定構成メッセージは、受信エンティティ４１０が特定のしきい値に基づいてメッセージを送信することを指示する。例えば、受信エンティティは、ペーシングバッファ７０５がいっぱいになったときにＰＳＦメッセージを送信するように指示するか、あるいは、送信エンティティがＰＳＦメッセージを受信したときにペーシングバッファが満たされることを示すしきい値までペーシングバッファが満たされたときにＰＳＦメッセージを送信するように指示する。また、受信エンティティ４１０は、ペーシングバッファが空いていることを示すＰＳＦを送信するように指示されるか、あるいは、送信エンティティ４０５がＰＳＦを受信したときにペーシングバッファ７０５が空いていることを示すしきい値までペーシングバッファが満たされているときにＰＳＦメッセージを送信するように指示される。他の実施形態において、ペーシングバッファ７０５がいっぱいになることを示すＰＳＦメッセージが送信されることを指示した後に、ペーシングバッファ７０５がしきい値以下に落ちたときに、ＰＳＦメッセージが送信される。例えば、このしきい値は、バッファがビデオを遅延させないことを保証するために５０〜７５％でありうる。

【0070】

ステップ９２０において、受信エンティティ４１０は、ペーシングバッファ７０５をモニタリングする。受信された測定構成メッセージによって、受信エンティティ４１０は、ペーシングバッファ７０５の現在の状態をモニタリング又はチェックする。ペーシングバッファの状態は、現在のペーシングバッファにバッファリングされたパケット量、ペーシングバッファにバッファリングされるパケットの目標量、サブフローにおいて最後に受信されたパケットのシーケンス番号、及びペーシングバッファの使用可能な空き領域の量を含む。

【0071】

ステップ９２５において、受信エンティティ４１０は、ＰＳＦメッセージを送信エンティティ４０５に伝送する。ＰＳＦメッセージは、送信エンティティ４０５から受信された構成メッセージで提供される情報に基づいて送信される。受信エンティティ４１０は、送信エンティティ４０５がデータ伝送を調整する必要があるが、測定構成メッセージにより指示されない場合に、ＰＳＦメッセージを伝送できる。例えば、この測定構成メッセージは、ＰＳＦメッセージを伝送する頻度のみを示し、スケジューリングされたＰＳＦメッセージの間にペーシングバッファがいっぱいになることを示すことができる。受信エンティティ４１０は、送信エンティティ４０５が構成メッセージ内にこのＰＳＦメッセージを要求しなくても、ペーシングバッファがいっぱいになることを示すために、この場合、特定のＰＳＦメッセージを伝送できる。

【0072】

図８及び図９は、それぞれ伝送システムにおけるエンティティを送信及び受信するためのプロセスの例を示したが、これら図に対して多様な変更がなされることができる。例えば、一連のステップとして示したが、各図の多様なステップは重なるか、並列的に発生するか、異なる順序で発生するか、あるいは数回発生することができる。

【0073】

本発明の実施形態では、ＭＭＴＰがメディアデータ伝送に適した一般のプロトコルを提供することにより、既存の伝送プロトコルを改善し代替するように開発されたことを認識する。ＭＭＴＰは、リアルタイムストリーミングのようなリアルタイム低遅延アプリケーションだけでなく遅延許容アプリケーションも解決する。ＭＭＴＰプロトコルが受信器を通じて一貫して動作し、クライアントにより必要なバッファ空間を利用可能にするために、本発明の実施形態はレートペーシングのためにバッファを管理し、必要なバッファ空間を推定し、この情報を送信エンティティにシグナリングする方法及び装置を提供する。この機能は、受信クライアントがハードウェア(例えば、セットトップボックス）で実現されるブロードキャスト受信器において特に重要である。

【0074】

以上、本発明の実施形態について図面を参照しながら詳細に説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の技術的範囲から逸脱しない範囲内で多様に変更実施することが可能である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】