(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】2019524008
(43)【公表日】20190829
(54)【発明の名称】レートペーシングのためにバッファを管理する装置及び方法
(51)【国際特許分類】
   H04N 21/238 20110101AFI20190802BHJP
   H04N 21/24 20110101ALI20190802BHJP
   H04N 21/438 20110101ALI20190802BHJP
   H04N 21/6373 20110101ALI20190802BHJP
   H04L 13/08 20060101ALI20190802BHJP
【FI】
   !H04N21/238
   !H04N21/24
   !H04N21/438
   !H04N21/6373
   !H04L13/08
【審査請求】未請求
【予備審査請求】未請求
【全頁数】30
(21)【出願番号】2018561237
(86)(22)【出願日】20170523
(85)【翻訳文提出日】20181121
(86)【国際出願番号】KR2017005339
(87)【国際公開番号】WO2017204525
(87)【国際公開日】20171130
(31)【優先権主張番号】62/340,826
(32)【優先日】20160524
(33)【優先権主張国】US
(31)【優先権主張番号】15/415,840
(32)【優先日】20170125
(33)【優先権主張国】US
(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,ST,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DJ,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KH,KN,KP,KR,KW,KZ,LA,LC,LK,LR,LS,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ
(71)【出願人】
【識別番号】503447036
【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド
【住所又は居所】大韓民国・16677・キョンギ−ド・スウォン−シ・ヨントン−ク・サムスン−ロ・129
(74)【代理人】
【識別番号】100121382
【弁理士】
【氏名又は名称】山下 託嗣
(72)【発明者】
【氏名】リム,ヨン−クウォン
【住所又は居所】アメリカ合衆国,94043 カリフォルニア,マウンテン ビュー,クライド アベニュー,665
【テーマコード(参考)】
5C164
5K034
【Fターム(参考)】
5C164GA03
5C164SB21P
5C164SB41P
5C164TB33P
5C164UB21P
5C164UB41S
5C164YA21
5C164YA24
5K034CC02
5K034DD01
5K034HH32
5K034HH42
5K034MM08
(57)【要約】
本発明は、レートペーシングのためにバッファを管理する方法、デコーダ、及びサーバを提供する。上記デコーダは、メモリと、信号を送信及び受信するように構成される送受信機と、メモリ及び送受信機に動作可能に接続される処理回路とを含む。上記処理回路は、サーバからデコーダのペーシングバッファに対するドレインレートを示す除去レートメッセージを受信し、ドレインレートに従ってペーシングバッファからデコーダの復号化バッファへ受信されたパケットを提供する。
【特許請求の範囲】
【請求項1】
レートペーシングのためにバッファを管理するデコーダであって、
メモリと、
信号を送信及び受信するように構成される送受信機と、
前記メモリ及び前記送受信機に動作可能に接続される処理回路と、を含み、
前記処理回路は、
サーバから前記デコーダのペーシングバッファに対するドレインレートを示す除去レートメッセージを受信し、
前記ドレインレートに従って前記ペーシングバッファから前記デコーダの復号化バッファへ受信されたパケットを提供するように構成されることを特徴とするデコーダ。
【請求項2】
前記処理回路は、
前記ペーシングバッファの状態情報を有する状態フィードバックメッセージを前記サーバに送信するようにさらに構成されることを特徴とする請求項1に記載のデコーダ。
【請求項3】
前記ペーシングバッファの前記状態情報は、
前記ペーシングバッファにバッファリングされたパケットの量と、
前記ペーシングバッファにバッファリングされたパケットの目標量と、
サブフローにおいて最後に受信されたパケットのシーケンス番号と、
前記ペーシングバッファの使用可能な空き領域の量と、
を含むことを特徴とする請求項2に記載のデコーダ。
【請求項4】
前記処理回路は、
前記サーバから前記状態フィードバックメッセージの送信を構成するための測定構成メッセージを受信するようにさらに構成されることを特徴とする請求項2に記載のデコーダ。
【請求項5】
前記測定構成メッセージは、前記デコーダが前記ペーシングバッファの前記状態フィードバックメッセージを送信するためのリクエストを含むことを特徴とする請求項4に記載のデコーダ。
【請求項6】
前記測定構成メッセージは、前記デコーダが前記ペーシングバッファの前記状態フィードバックメッセージを送信する頻度を含むことを特徴とする請求項4に記載のデコーダ。
【請求項7】
前記処理回路は、
前記ペーシングバッファがいっぱいになったときに、充填状態フィードバックメッセージを前記サーバに送信するようにさらに構成されることを特徴とする請求項2に記載のデコーダ。
【請求項8】
前記処理回路は、
前記充填状態フィードバックメッセージが送信された以後にパケットの量がしきい値未満に減少する場合に前記状態フィードバックメッセージを前記サーバに送信するようにさらに構成されることを特徴とする請求項7に記載のデコーダ。
【請求項9】
デコーダにおけるレートペーシングのためにバッファを管理するサーバであって、
メモリと、
信号を送信及び受信するように構成される送受信機と、
前記メモリ及び前記送受信機に動作可能に接続される一つ以上のプロセッサと、を含み、
前記一つ以上のプロセッサは、
前記デコーダのペーシングバッファに対するドレインレートを示す除去レートメッセージを前記デコーダに送信し、
状態フィードバックメッセージの送信を構成するために測定構成メッセージを前記デコーダに送信するように構成され、
前記ドレインレートは、受信されたパケットが前記デコーダの前記ペーシングバッファから前記デコーダの復号化バッファへ提供されるレートであることを特徴とするサーバ。
【請求項10】
前記一つ以上のプロセッサは、前記デコーダから前記ペーシングバッファの状態情報を含む前記状態フィードバックメッセージを受信するようにさらに構成され、
前記ペーシングバッファの前記状態情報は、
前記ペーシングバッファにバッファリングされるパケットの量と、
前記ペーシングバッファにバッファリングされるパケットの目標量と、
サブフローにおいて最後に受信されたパケットのシーケンス番号と、
前記ペーシングバッファの使用可能な空き領域の量と、
を含むことを特徴とする請求項9に記載のサーバ。
【請求項11】
前記測定構成メッセージは、前記デコーダが前記ペーシングバッファの前記状態フィードバックメッセージを送信するためのリクエストを含むことを特徴とする請求項9に記載のサーバ。
【請求項12】
前記測定構成メッセージは、前記デコーダが前記ペーシングバッファの前記状態フィードバックメッセージを送信する頻度を含むことを特徴とする請求項9に記載のサーバ。
【請求項13】
請求項1乃至請求項8のいずれか1項に記載のデコーダで実行されることを特徴とする方法。
【請求項14】
請求項9乃至請求項12のいずれか1項に記載のサーバで実行されることを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、一般的に伝送システムにおけるメディアデータ配信に関し、より詳細にはレートペーシング(rate pacing)のためにバッファを管理する装置及び方法に関する。
【背景技術】
【0002】
MPEG(Moving Picture Experts Group)メディアトランスポート(MMT)は、異種インターネットプロトコル(IP)ネットワーク環境を通じてマルチメディアサービス用で符号化されたメディアデータを配信するための技術を規定するデジタルコンテナ標準又はフォーマットである。配信される符号化されたメディアデータは、指定された時間に同期化した復号化及び特定データ単位の表現を要請する視聴覚メディアデータ、すなわち時間設定型データ、及びサービスコンテキスト又はユーザーによる相互作用に基づいて任意の時間で復号化され提示される他のタイプのデータ、すなわち非時間設定型データの両方を含む。
【0003】
MMTは、符号化されたメディアデータがリアルタイムトランスポートプロトコル(RTP)、伝送制御プロトコル(TCP)、ユーザーデータグラムプロトコル(UDP)のようなIPを用いてパケットベースの伝送ネットワークを介して配信されるという仮定の下で設計される。また、MMTは、多様な伝送環境の特性を考慮して設計される。例えば、各パケットの送信エンティティから受信エンティティへの配信のエンドツーエンド遅延が常に一定であるとは限らず、基本ネットワークプロバイダは、メディアデータからシグナリングメッセージを区別する方法を提供しなければならない。したがって、MMTメディアデータ伝送において改善された標準が必要である。
【発明の概要】
【発明が解決しようとする課題】
【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】本発明の多様な実施形態によるMMTメディアデータ伝送環境におけるMMTプロトコル入/出力を示すブロック構成図である。
【図5】本発明の多様な実施形態による受信器の挙動(behavior)をシミュレーションするための受信器バッファモデルを示すブロック構成図である。
【図6】本発明の多様な実施形態によるモバイルビデオ配信のためのレートペーシングを使用する例示的な実現を示す図である。
【図7】本発明の多様な実施形態によるペーシングバッファを有する仮想受信器バッファモデル(HRBM)を示す図である。
【図8】本発明の一実施形態による伝送システムにおける送信エンティティを動作するためのプロセスを示す図である。
【図9】本発明の一実施形態による伝送システムにおける受信エンティティを動作するためのプロセスを示す図である。
【発明を実施するための形態】
【0011】
以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
【0012】
後述される図1〜図9及び、本発明の原理を説明するために使用される多様な実施形態は、単にその実施例を示すものに過ぎず、本発明の範囲を限定するものとして捉えてはならない。本発明の原理が適切に配列されたシステム又はデバイスで実現できることは、当該技術分野で通常の知識を有する者には明らかである。
【0013】
MMT符号化及びメディア伝送は、次の文献及び標準説明に論議されている。“ISO/IEC JTC1/SC29/WG11,High efficiency coding and media delivery in heterogeneous environments-Part1:moving picture experts group(MPEG) media transport(MMT),July2012”この文献は、その全内容が本明細書中に参照として組み込まれている。異種IPネットワーク環境を通じて符号化されたメディアデータを効率的かつ効果的に伝送するために、MMTは、次のような機能、すなわちマッシュアップ(mash-up)アプリケーションのための多様なコンポーネントからなるコンテンツを構成する論理モデル、パケット化及び適応のような伝送階層処理のために符号化されたメディアデータに関する情報を搬送するデータ構造、ハイブリッド伝送を含む伝送制御プロトコル(TCP)又はユーザーデータグラムプロトコル(UDP)を通じて使用される特定タイプのメディア又は符号化方法に関係なくメディアコンテンツを配信するパケット化方法及びパケット構造、メディアコンテンツの表示及び伝送を管理するためのシグナリングメッセージのフォーマット、及びクロス階層通信を容易にするために階層間に交換される情報のフォーマットを提供する。
【0014】
MMTは、カプセル化、伝送、及びシグナリングを含む3つの機能領域を定義する。カプセル化機能領域は、MMTコンプライアントエンティティにより処理されるメディアコンテンツ、MMTパッケージ、及びフォーマットデータユニットの論理構造を定義する。MMTパッケージは、適応的伝送に必要な情報を提供するためにメディアコンテンツとメディアコンテンツとの関係を含むコンポーネントを指定する。データユニットのフォーマットは、符号化されたメディアをカプセル化して伝送プロトコルのペイロードとして格納又は搬送し、格納と搬送との間で容易に変換されるように定義される。配信機能領域は、ペイロードのアプリケーション階層プロトコル及びフォーマットを定義する。アプリケーション階層プロトコルは、マルチメディア伝送のための従来のアプリケーション階層プロトコルに比べてMMTパッケージの伝送のために多重化を含む強化された特徴を提供する。ペイロードフォーマットは、特定のメディアタイプ又は符号化方法に関係なく符号化されたメディアデータを搬送するように定義される。シグナリング機能領域は、MMTパッケージの伝送及び消費を管理するためのメッセージのフォーマットを定義する。消費管理のためのメッセージは、MMTパッケージの構造をシグナリングするために使用され、配信管理のためのメッセージは、ペイロードフォーマットの構造とプロトコル構成をシグナリングするために使用される。
【0015】
MMTは、オーディオ、ビデオ、及び他の静的コンテンツ、例えばウィジェット、ファイルのような持続的なマルチメディア伝送のための新たなフレームワークを定義する。MMTは、受信エンティティにMMTパッケージを伝送するためのプロトコル(すなわち、MMTP)を特定する。MMTPは、プロトコルヘッダーの一部としてMMTPパッケージの伝送時間をシグナリングする。この時間は、受信エンティティが各着信(incoming)MMTパケットの伝送時間及び受信時間を検査することで、デジッタリングの実行を可能にする。
【0016】
本発明の実施形態では、メディアデータの受信のための環境条件が、伝送経路、伝送フォーマット、受信装置のタイプにより異なり、その結果、伝送と配信との間で遅延(例えば、エンドツーエンド遅延)を招くことを認識する。例えば、異なる伝送メディア(例えば、無線データ通信(LTE、HSPA、3G、WiFiなど)、物理的メディア(例えば、有線、ケーブル、イーサネット(登録商標)、光ファイバなど)、衛星ブロードキャストなど)は、異なる関連伝送遅延を有する。本発明の実施形態では、伝送遅延以外に、他のソースがジッタを起こすことを認識する。例えば、FEC(Forward Error correction)復号化は、損失パケットの回復を可能にする追加遅延を挿入し、これは、十分なソース及びパリティパケットの受信を必要とする。遅延のもう一つの原因は、伝送中に実行される可能性のあるデータインターリービングである。また、本発明の実施形態では、受信装置コンポーネントも遅延に影響を与えることを認識する。メモリがより大きく、処理速度がより速いコンピュータのような装置は、メモリがより小さく、処理速度がより遅いセットトップボックスのような他の装置より少ない遅延を有する。
【0017】
本発明の実施形態において、ブロードキャスト環境のような特定環境では、送信から受信エンティティでMMT処理スタックを離れるまで、それぞれの伝送されたパケットがポイントツーマルチポイント伝送システムにわたって同一の遅延を経験する固定したエンドツーエンド遅延を有することが重要であることを認識する。例えば、本発明の実施形態では、同一のプログラムを受信するすべてのクライアントが装置、プロトコル、又は伝送メディア実現に関係なく同一の時間で同一のコンテンツを提示することを提供し、あるいはこれを保証することが重要であることを認識する。また、受信器のハードウェア実現を可能にするために、本発明の実施形態は、固定したパケット伝送遅延を保証するために必要なメモリ空間上の上限が提供される必要があると認識する。ネットワークの特性及びサービス設定により、MMTパケットは、広範囲なジッタにさらされ、その結果、異なるバッファ要求事項が発生する。例えば、大きいソースブロックでFEC保護を提供し、インターネットを介して搬送されるサービスは、FEC保護なしに管理されたブロードキャストを通じて搬送されるサービスより多くのバッファリングが要求される。
【0018】
そのため、ジッタ量の変動が非常に大きく、あるいはジッタの最大量をMMT送信エンティティに知らせることができない場合、現在のMMTP HRBMは、効率的な解決策であり得ない。この場合、MMT送信エンティティは、HRBMを含むことなく、その最大使用可能な帯域幅にパケットを単に伝送するようになり、それによってMMT受信エンティティが消費前にある程度の時間でデータをバッファリングし、パケットが時間内に受信されない場合には最初にバッファリングされたデータが消費される。
【0019】
したがって、本発明の実施形態では、ペーシングバッファのレベルを効率的に管理するために、MMT送信エンティティ及びMMT受信エンティティにメッセージを提供し、ペーシング及びシグナリングする方法及び装置を提供する。
【0020】
図1は、本発明の多様な実施形態が実現される伝送システム100の一例を示す。図示の実施形態では、システム100は、送信エンティティ101、ネットワーク105、受信エンティティ110〜116、基地局(BS)102、BS103、及び他の類似した基地局又は中継局のような無線伝送ポイント(例えば、進化したノードB(eNB)、ノードB)を含む。送信エンティティ101は、例えばインターネット、メディアブロードキャストネットワーク、又はIPベースの通信システムであるネットワーク105を介して基地局102及び基地局103と通信している。受信エンティティ110〜116は、ネットワーク105及び/又は基地局102及び103を通じて送信エンティティ101と通信している。
【0021】
基地局102は、そのカバレッジ領域120内の第1の複数の受信エンティティ(例えば、ユーザー端末、移動電話、移動局、及び加入局)にネットワーク105への無線アクセスを提供する。第1の複数の受信エンティティは、中小企業(SB)に位置するユーザー端末111、大企業(E)に位置するユーザー端末112、WiFiホットスポット(HS)に位置するユーザー端末113、第1の住居地域(R)に位置するユーザー端末114、第2の住居地域(R)に位置するユーザー端末115、及びセルラー電話、無線通信可能なラップトップ、無線通信可能なPDA、タブレットコンピュータのようなモバイル装置(M)であるユーザー端末116を含む。
【0022】
基地局103は、そのカバレッジ領域125内の第2の複数のユーザー端末にネットワーク105への無線アクセスを提供する。第2の複数のユーザー端末は、ユーザー端末115及びユーザー端末116を含む。例示的な実施形態において、基地局101-103は、OFDM又はOFDMA技術を用いて相互に及びユーザー端末111〜116と通信することができる。
【0023】
図1では6個のユーザー端末のみを示したが、システム100は、追加的なユーザー端末に対する無線広帯域及びネットワークアクセスを提供できる。ユーザー端末115及びユーザー端末116は、カバレッジ領域120及びカバレッジ領域125のエッジに位置する。ユーザー端末115及びユーザー端末116は、それぞれ基地局102及び基地局103の両方と通信し、当業者に公知されているように、ハンドオフモードで動作すると言える。
【0024】
ユーザー端末111〜116は、ネットワーク105を介して音声、データ、ビデオ、ビデオ会議、及び/又は他の広帯域サービスにアクセスする。例示的な一実施形態では、ユーザー端末111〜116のうちの一つ以上は、WiFi WLANのアクセスポイント(AP)に関連される。ユーザー端末116は、無線可能なラップトップコンピュータ、PDA(Personal Data Assistant)、ノートブック、携帯用装置、又は他の無線可能な装置を含む複数の移動装置のうちのいずれか一つである。ユーザー端末114及び115は、例えば無線可能な個人用コンピュータ(PC)、ラップトップコンピュータ、ゲートウェイ、又は他の装置である。
【0025】
図2及び図3は、本発明によるコンピュータシステム内の例示的な装置を示す。特に、図2は例示的なサーバ200を示し、図3は例示的なクライアント装置300を示す。サーバ200は、図1の送信エンティティ101、基地局102、又は基地局103を示し、クライアント装置300は、図1の受信エンティティ110、ユーザー端末111〜116のうちの一つ以上を示す。
【0026】
図2に示すように、サーバ200は、一つ以上のプロセッサ210、少なくとも一つの記憶装置215、少なくとも一つの通信インターフェース220、及び少なくとも一つのI/Oユニット225間の通信をサポートするバスシステム205を含む。
【0027】
プロセッサ210は、メモリ230にローディングされる命令を実行する。プロセッサ210は、任意の適切な個数及びタイプのプロセッサ又は他の装置を任意の適切な配列で含むことができる。例示的なタイプのプロセッサ210は、マイクロプロセッサ、マイクロ制御器、デジタル信号プロセッサ、フィールドプログラマブルゲートアレイ、特定用途向け集積回路、及び離散回路を含む。プロセッサ210は、レートペーシングのためにバッファを管理するように構成される。
【0028】
メモリ230及び永続ストレージ235は、情報(例えば、データ、プログラムコード、及び/又は一時的又は永久的基盤の他の適切な情報)を格納し、容易に検索可能な任意の構造を示す記憶装置215の例である。メモリ230は、ランダムアクセスメモリ又は任意の他の適切な揮発性又は不揮発性格納装置を示す。永続ストレージ235は、読み出し専用メモリ、ハードドライブ、フラッシュメモリ、又は光学ディスクのようなデータの長期的な格納をサポートする一つ以上のコンポーネント又は装置を含むことができる。
【0029】
通信インターフェース220は、他のシステム又は装置との通信をサポートする。例えば、通信インターフェース220は、ネットワーク102を介して通信を容易にするネットワークインターフェースカード又は無線送受信機を含む。通信インターフェース220は、任意の適した物理的又は無線通信リンクを通じる通信をサポートできる。
【0030】
I/Oユニット225は、データの入力及び出力を許容する。例えば、I/Oユニット225は、キーボード、マウス、キーパッド、タッチスクリーン、又は他の適切な入力装置を通じるユーザー入力のための接続を提供できる。I/Oユニット225は、出力をディスプレイ、プリンタ、又は他の適切な出力装置に送信する。
【0031】
このような実施形態において、サーバ200は、以下により詳細に説明するように、受信エンティティ110又はユーザー端末111〜116でのレートペーシングのためのバッファ管理を提供する装置を実現する。図2は、図1の送信エンティティ101、基地局103、又は基地局102を示すことを説明したが、同一の又は類似した構造が受信エンティティ110、ユーザー端末111〜116のうち一つ以上に使用されることに留意しなければならない。例えば、ラップトップ又はデスクトップコンピュータが図2の図示と同一の構造又は類似した構造を有する。
【0032】
図3に示すように、受信エンティティ110又はUE111〜116のようなクライアント装置300は、アンテナ305、無線周波数(RF)送受信機310、送信(TX)処理回路315、マイクロホン320、及び受信(RX)処理回路325を含む。クライアント装置300は、スピーカ330、一つ以上のプロセッサ340、入/出力(I/O)インターフェース(IF)345、タッチスクリーン350、ディスプレイ355、及びメモリ360を含む。メモリ360は、基本オペレーティングシステム(OS)プログラム361及び一つ以上のアプリケーション363を含む。
【0033】
RF送受信機310は、アンテナ305からシステムの他のコンポーネントにより送信された着信(incoming)RF信号を受信する。RF送受信機310は、着信RF信号をダウンコンバートして中間周波数(IF)又はベースバンド信号を生成する。IF又はベースバンド信号は、このベースバンド又はIF信号をフィルターリング、復号化、及び/又はデジタル化することによって処理されたベースバンド信号を生成するRX処理回路325に送信される。RX処理回路325は、処理されたベースバンド信号を(例えば、音声データのために)スピーカ330に送信するか、あるいは(Webブラウジングデータのような)追加処理のためにプロセッサ340に送信する。
【0034】
TX処理回路315は、マイクロホン320からアナログ又はデジタルデータを受信し、あるいはプロセッサ340から他の発信(outgoing)ベースバンドデータ(例えば、Webデータ、eメール、又は双方向ビデオゲームデータ)を受信する。TX処理回路315は、出力ベースバンドデータを符号化、多重化、及び/又はデジタル化し、処理されたベースバンド又はIF信号を生成する。RF送受信機310は、TX処理回路315から出力処理されたベースバンド又はIF信号を受信し、そのベースバンド又はIF信号を、アンテナ305を通じて送信されるRF信号にアップコンバートする。
【0035】
プロセッサ340は、一つ以上のプロセッサ又は他の処理装置を含むことができ、クライアント装置300の全体動作を制御するためにメモリ360に格納された基本OSプログラム361を実行できる。例えば、プロセッサ340は、よく知られている原理によってRF送受信機310、RX処理回路325、及びTX処理回路315による順方向チャンネル信号の受信及び逆方向チャンネル信号の送信を制御する。一部実施形態において、プロセッサ340は、少なくとも一つのマイクロプロセッサ又はマイクロ制御器を含む。
【0036】
また、プロセッサ340は、メモリ360に常駐するプログラム及び他のプロセスを実行し、例えばレートペーシングのためにバッファを管理する動作を実行することができる。プロセッサ340は、実行プロセスによるリクエストによってメモリ360の内部又は外部にデータを移動させる。一部実施形態では、プロセッサ340は、外部装置又はオペレータから受信された信号に応答して又はOSプログラム361に基づいてアプリケーション363を実行するように構成される。プロセッサ340は、他のデバイス、例えばラップトップコンピュータ及びハンドヘルドコンピュータへの接続能力をクライアント装置300に提供するI/Oインターフェース345にカップリングされる。I/Oインターフェース345は、このような付属品とプロセッサ340との間の通信経路である。
【0037】
プロセッサ340は、タッチスクリーン350及びディスプレイ355にもカップリングされる。クライアント装置300のオペレータは、タッチスクリーン350を用いてデータをクライアント装置300に入力できる。ディスプレイ355は、例えばWebサイトからのテキスト及び/又は少なくとも限定されたグラフィックをレンダリングする液晶ディスプレイ又は他のディスプレイでありうる。
【0038】
メモリ360は、プロセッサ340にカップリングされる。メモリ360の一部は、ランダムアクセスメモリ(RAM)を含み、メモリ360の他の一部はフラッシュメモリ又は他の読み出し専用メモリ(ROM)を含むことができる。
【0039】
以下により詳細に説明されるように、この例示的な実施形態において、クライアント装置300は、ネットワーク105を介して送信エンティティ101、基地局102、又は基地局103と着信呼(incoming call)を開始又は受信する装置を実現する。図2及び図3がコンピュータシステム内の装置に関する実施形態を示すが、多様な変更が図2及び図3に対してなされることができる。例えば、図2及び図3の多様なコンポーネントが結合され、さらに細分化され、あるいは省略され、追加コンポーネントが特定の必要事項に従って付加される。特定の例として、プロセッサ340は、複数のプロセッサ、例えば一つ以上の中央処理装置(CPU)及び一つ以上のグラフィック処理装置(GPU)に分割される。さらに、図3が移動電話又はスマートフォンで構成されたクライアント装置300を示したが、クライアント装置は、他のタイプの移動又は停止装置として動作するように構成される。さらに、コンピュータ及び通信ネットワークと同様に、クライアント装置及びサーバは、多様な構成で提供され、図2及び図3は、任意の特定クライアント装置又はサーバに本発明を限定するものではない。
【0040】
図4は、本発明の多様な実施形態によるMMTメディアデータ伝送環境400におけるMMTプロトコル入/出力を示すブロック構成図である。一実施形態において、送信エンティティ405は、MMTPによって伝送媒体を通じて受信エンティティ410にメディアデータを送信する。メディアデータ415は、MMTPによって送信エンティティ405で処理される。例えば、送信エンティティ405は、メディアデータに対するMMTパッケージカプセル化、符号化、配信、及びシグナリングをMMT処理ユニット(MPU)及びMMTフラグメント化ユニット(MFU)415(例えば、MPUのフラグメント)として実行する。その次に、処理されたメディアデータは、MMTPによって処理(例えば、デカプセル化、復号化)するために受信エンティティ410に(例えば、パケットとして)送信される。その後、受信エンティティ410で処理されたメディアデータは、メディアデータの配信を完了したユーザーにプレゼンテーションするためにMPU及び/又はMFUとして上位階層プログラミング(例えば、メディアプレーヤーのようなアプリケーション階層プログラム)に伝送される。
【0041】
図5は、本発明の多様な実施形態により送信器側で受信器の挙動をシミュレーションし、バッファ遅延及びサイズ要求事項を推定するための受信器バッファモデル500を示すブロック構成図である。本発明の多様な実施形態において、メディア−伝送サーバ(又は他のMMT認識ノード)のような送信エンティティ405は、ポイントツーマルチポイント伝送システムにおいて、メディアデータ伝送のための固定したエンドツーエンド遅延を計算、決定、及び/又は識別する。例えば、送信エンティティ405は、モデル500を用いて、受信エンティティ410の受信器における受信制約上でのパケットストリーム上で実行されたメディアデータ処理の効果を決定できる。例えば、送信エンティティ405は、このモデルを用いて必要なバッファリング遅延及び必要なバッファサイズを決定し、この情報をメディアデータを受信するエンティティに伝える。
【0042】
この実施形態において、FEC復号化バッファ505は、FEC復号化に関連した遅延及び/又はバッファサイズ要請事項を推定するためのモデルである。FEC復号化は、チャンネル誤りから回復するのに下位階層伝送では十分でなく、あるいはネットワーク停滞によってパケット損失又は過度な遅延が発生する複数のアプリケーションで一般的である。FEC復号化を実行するために、受信エンティティ410は、十分なソース(“S”)及びリペアデータ(“P”パリティデータ)がFEC復号化の実行のために利用可能であるまで着信パケットが格納されているバッファを使用する。
【0043】
一実施形態において、送信エンティティ405は、FEC復号化バッファ505のモデルを使用し、FEC復号化に関連した遅延を推定するために受信エンティティ410がFEC復号化に関して実行する動作を決定する。言い換えれば、送信エンティティ405は、FEC復号化バッファ505のモデルを使用し、FEC復号化遅延を推定するために受信エンティティ410により実行される動作を予測する。このような送信エンティティ405によるFEC復号化バッファ505のモデリングは、FEC復号化バッファ505が初期段階には空いているとの仮定で始まる。次に、受信エンティティ410は、伝送タイムスタンプtsを有するそれぞれの着信パケットiに対して、buffer_occupancy+packet_size<max_buffer_sizeである場合、FEC復号化バッファ505を用いてパケットiをバッファリングする。そうでない場合、受信エンティティ410は、バッファモデルに適合しないものとしてパケットiを廃棄する。その後に、受信エンティティ410は、FECがパケットiに適用されるか否かを判定する。FECがパケットiに適用される場合、受信エンティティ410は、パケットiが属するソースブロックjを決定し、ソースブロックjの第1のパケットの挿入時間tを決定し、時間t+FEC_buffer_timeでソースブロックjのすべてのパケットをデジッタバッファに移動させ(FEC訂正後、必要に応じて)、リペアパケットを廃棄する。送信エンティティ405は、FEC復号化が試みられるまで、ソースブロックの第1のパケットの受信からFEC復号化に必要なバッファ時間としてFEC_buffer_timeを利用する。この時間は、一般的にFECブロックサイズに基づいて計算される。
【0044】
デジッタバッファ510は、パケットのデジッタリング、すなわちパケットの遅延ジッタの除去に関連する遅延及び/又はバッファサイズ要求事項を推定するために送信エンティティにより使用されるモデルである。デジッタバッファは、最後にMMTPパケットがソースからMMTPプロトコルスタックの出力に固定した伝送遅延を経験することを保証することで、最大伝送遅延を仮定する。受信エンティティ410は、最大伝送遅延より大きい伝送遅延を経験するデータユニットを非常に遅いものとして廃棄する。
【0045】
送信エンティティ405によるデジッタバッファ510のモデリングは、デジッタバッファが初期段階では空いているとの仮定で始まる。その後、受信エンティティ410は、パケットが到着するときにMMTPパケットをデジッタバッファ510に挿入する。その次に、受信エンティティ410は、時間ts+ΔでMMTPパケットを除去し、ここでtsはMMTPパケットの伝送タイムスタンプであり、Δはメディアデータに対してシグナリングされる固定したエンドツーエンド遅延である。デジッタリングが適用された後に、正確に到着した(又はFEC/再伝送を通じて回復された)すべてのMMTPパケットは、同一のエンドツーエンド遅延を経験するようになる。
【0046】
MMTPデカプセル化バッファ515は、出力を上位階層に伝達する前にMMTP処理に関連する遅延及び/又はバッファサイズ要求事項を推定するために送信エンティティにより使用されるモデルである。MMTPプロセッサの出力は、MFUペイロード(低遅延動作で)、完全なムービーフラグメント、又は完全なMPUでありうる。MPUは、これらのサイズに従って、より小さいパケットにフラグメント化され、あるいはより大きいパケットにアグリゲートされる。MMTP処理の一部として、デカプセル化(MMTPパケット及びペイロードヘッダの除去)及び任意の必要なデフラグメント化/デアグリゲーションが実行される。この手順では、MPUが複数のMMTPパケットにフラグメント化される場合、アセンブリを実行するためにデカプセル化遅延と呼ばれるいくつかのバッファリング遅延を必要とする。しかしながら、この実施形態において、デカプセル化遅延は、固定したエンドツーエンド遅延の一部として考慮されず、符号化されたメディア階層による消費のためのMPUの使用可能性は、デカプセル化遅延に関係なく、MPUを複数のMMTPパケットにフラグメント化するエンティティにより保証される。
【0047】
MMTP HRBMは、MMT送信エンティティがMMT受信エンティティのバッファ状態を正確に管理可能にする。MMTP HRBMを使用することによって、基本伝送ネットワークにジッタが多い場合にも、メディアサービスのシームレスな低遅延消費が保証される。その動作のために、MMTP HRBMは、基本伝送ネットワークの全般的な固定したエンドツーエンド遅延を、予めMMT送信エンティティに知らせるための一つのパラメータを要求する。図1に示すように、MMTP HRBMは、3個のバッファで構成され、固定したエンドツーエンド遅延、FEC作動及び基本伝送ネットワークの帯域幅変動によるジッタにより引き起こされる遅延の2つの要因が存在する。FEC作動による遅延量がMMTP送信エンティティにより決定されることを考慮すれば、固定したエンドツーエンド遅延の量をわかることは、基本伝送ネットワークのジッタの最大量をわかることを意味する。
【0048】
したがって、ジッタ量の変動が非常に大きいか、あるいはジッタの最大量がMMT送信エンティティに知らされない場合には、現在のMMTP HRBMは効率的な解決策ではない。この場合に、MMT送信エンティティは、HRBMを包含せず、その最大使用可能な帯域幅でパケットを単に配信するようになり、それによってMMT受信エンティティが消費前の所定時間でデータをバッファリングし、パケットが時間内に受信されない場合に最初にバッファリングされたデータを消費することができる。
【0049】
図5は送信器側で受信器の挙動をシミュレーションするための受信器バッファモデル500の一例を示したが、多様な変更が図5に対してなされてもよい。例えば、図5の多様なコンポーネントが結合され、さらに細分化され、又は省略されることができ、追加コンポーネントが特定の必要によって付加されうる。
【0050】
図6は、本発明の多様な実施形態によるモバイルビデオ伝送のためのレートペーシングを使用する例示的な実現(600)を示す。
【0051】
ペーシングは、バッファ状態及び再生に基づいてストリーミングビット率を調整することによって、プッシュ伝送システムにおいてクライアント側で浪費されるデータを減少させる技術である。図6の左側部分は、MMTP送信エンティティがメディア消費より大きい帯域幅でデータを配信し、それによって過度な量のバッファリングされたデータ605がMMT受信エンティティに格納される場合の一例を示す。モバイル環境のためのISO/IEC23008-1AMD2MMT改善で論議されたように、多くの場合において、ユーザーが終了するまでビデオを見ないことで、このような過度なデータが実際には消費されず、つまり、リソースが浪費される。このようなリソースの浪費を最小化するために、ペーシング方法は、図6の右側に示すように適用される。MMT受信エンティティは、MMT送信エンティティが送信帯域幅を制御可能にするためにクライアントでバッファリングされたデータ量610をMMT送信エンティティに通知する。
【0052】
図6がモバイルビデオ伝送のためのレートペーシングを使用する例示的な実現(600)の一例を示したが、多様な変更が図6に対してなされる。例えば、図6の多様なコンポーネントが結合され、より細分化され、又は省略され、追加コンポーネントが特定の必要事項によって付加されうる。
【0053】
図7は、本発明の多様な実施形態によるペーシングバッファを有する仮想受信器バッファモデル(HRBM)700を示す。HRBMは、MMTPペーシングバッファ705、FEC復号化バッファ710、デジッタバッファ715、及びMMTPデカプセル化バッファ720を含む。FEC復号化バッファ710、デジッタバッファ715、及びMMTPデカプセル化バッファ720は、図5に示したFEC復号化バッファ505、デジッタバッファ510、及びMMTPデカプセル化バッファ515と類似に機能する。
【0054】
ペーシングバッファ705を組み込むことを考慮して、MMTP HRBM700の固定したエンドツーエンド遅延の値は、FEC動作により寄与する遅延の値に設定される。それぞれのMMTPパケットは、任意の追加処理以前に、受信エンティティ410により決定される特定時間でペーシングバッファ705に格納される。各MMTPパケットを格納する時間の量は、受信エンティティ410により決定され、それによってペーシングバッファに格納されたMMTPパケットの量をペーシングバッファ状態フィードバック(PSF)メッセージのtarget_pacing_buffer_level値に維持し、復号化バッファ710に対するパケットの伝送レートをペーシングバッファ除去レート(PRR)メッセージのpacing_buffer_removal_rate値に維持する。FEC復号化バッファ710に配信される各MMTPパケットのタイムスタンプフィールドの値は、パケットがペーシングバッファ705に格納される時間の量だけ増加する。
【0055】
PRRメッセージは、ペーシングバッファ705のドレインレートに関する情報を提供する。PRRメッセージを送信エンティティ405に伝送することによってペーシングバッファ705が使用される場合、PRRメッセージがシグナリングされる。PRRメッセージがシグナリングされると、MMT受信エンティティ410は、メッセージで特定されたレートでペーシングバッファ705内のパケットをFEC復号化バッファ710に伝送する。次の<表1>は、PRRメッセージ構文を示す。
【0056】
【表1】
message_idフィールドは、PRRメッセージの識別子を示す。バージョンフィールドは、PRRメッセージのバージョンを示す。MMT受信エンティティ410は、このフィールドを用いて受信されたPRRメッセージのバージョンを検証する。長さフィールドは、次のフィールドの第1のバイトからPRRメッセージの最後のバイトまでカウントする、典型的にはバイト単位のPRRメッセージの長さを示す。‘0’の値は、長さフィールドで有効でない。pacing_buffer_removal_rateフィールドは、ペーシングバッファ705からFEC復号化バッファ710にMMTPパケットを配信するためのドレインレートを示す。
【0057】
MMTPペーシングバッファ705のサイズ及び各MMTPパケットがMMTPペーシングバッファ705に格納される時間の量はMMT受信エンティティ410により決定されるので、MMT受信エンティティ410は、送信エンティティ405によりリクエストされる場合、送信エンティティ405によりリクエストされた頻度でPSFメッセージを送信エンティティ405に送信する。MMT受信エンティティ410は、MMTPペーシングバッファレベルの状態を追跡し、各MMTPパケットが送信される時間を決定することによって、MMTPペーシングバッファ705に格納される超過データの量を制御する。次の<表2>は、PSFメッセージの構文を示す。
【0058】
【表2】
message_idフィールドは、PSFメッセージの識別子を含む。例えば、message_idフィールドは、16ビットの長さを有する。バージョンフィールドは、PSFメッセージのバージョンを示す。受信エンティティ410は、このフィールドを使用して受信されたメッセージのバージョンをチェックする。例えば、バージョンフィールドは、8ビットの長さを有する。長さフィールドは、次のフィールドの第1のバイトからPSFメッセージの最後のバイトまでカウントする、典型的にはバイト単位のPSFメッセージの長さを示す。このフィールドの長さは、16ビットであり、‘0’の値はこのフィールドに有効でない。current_pacing_buffer_levelは、ペーシングバッファ705に現在バッファリングされたMMTPパケットの量を、MMT送信エンティティ405に指示する。target_pacing_buffer_levelは、ペーシングバッファ705にバッファリングされるMMTPパケットの目標量を、送信エンティティ405に指示する。送信エンティティ405は、この目標量を達成するためにMMTPパケットの伝送に割り当てられる帯域幅を調整する。last_receivedフィールドは、特定のMMTPサブフローにおいて最後に受信されたMMTPパケットシーケンス番号を、送信エンティティ405に指示する。pacing_buffer_free_spaceフィールドは、ペーシングバッファ705の利用可能な空間の量を、バイト単位で送信エンティティに指示する。
【0059】
測定構成メッセージが送信エンティティ405から受信エンティティ410に伝送されることによって、ペーシングバッファの状態を報告するPSFメッセージのリクエストが指示される。また、測定構成メッセージは、PSFメッセージを送信するための頻度を受信エンティティ405に示すことができる。PSF報告に対するリクエストを示すフラグは“0000 0000 0000 1000”として定義される。このフラグが1に設定される場合、現在の再生状態に関するPSFメッセージを送信エンティティ405に送信することが受信エンティティ410に要請される。
【0060】
図7が本発明の多様な実施形態によるペーシングバッファを有する仮想受信器バッファモデル(HRBM)700の一例を示したが、多様な変更が図7に対してなされることができる。例えば、図7の多様なコンポーネントが結合され、あるいはより細分化され、又は省略され、追加コンポーネントが特定の必要事項によって付加されうる。
【0061】
図8は、本発明の実施形態による伝送システムにおける送信エンティティを動作させるプロセスを示すフローチャートである。例えば、図8に示すプロセスは、図2のサーバ200又は図4の送信エンティティ405により実行される。このプロセスは、図1の送信エンティティ101により実現される。
【0062】
ステップ805において、送信エンティティ405は、受信エンティティ405内のペーシングバッファに対するドレインレートを決定する。受信エンティティ410は、パケットの量又はビデオの時間量に基づいてペーシングバッファのサイズを決定する。ドレインレートは、例えばビデオのサイズ、バッファのサイズ、データストリームのレートに従って決定される。特定の実施形態では、ペーシングバッファの使用が受信エンティティ410によりシグナリングされる。
【0063】
ステップ810において、送信エンティティ405は、ペーシングバッファを示す信号の受信に応答して、デコーダのペーシングバッファのドレインレートを示すPRRメッセージを送信する。PRRメッセージは、パケットがFECデコーダ710に伝送されるドレインレートを受信エンティティ410に指示する。
【0064】
ステップ815において、送信エンティティ405は、PSFメッセージを構成するための測定構成メッセージを送信する。測定構成メッセージは、受信エンティティ410にPSFメッセージを送信することを指示するか、又は、PSFメッセージを送信するための頻度を送信することを指示する。特定の環境で、この構成メッセージは、所定の時間又は要因(factor)で伝送される初期メッセージを示す。例えば、測定構成メッセージは、ペーシングバッファが特定のパーセントまで満されたときに、PSFメッセージの伝送を開始するように指示する。さらに、測定構成メッセージは、受信エンティティ410が特定のしきい値に基づいてメッセージを送信するように指示できる。例えば、受信エンティティは、ペーシングバッファ705がいっぱいになったときにPSFメッセージを送信するように指示されるか、あるいは、送信エンティティがPSFメッセージを受信したときにペーシングバッファが満たさせることを示すしきい値までペーシングバッファ705が満たされたときにPSFメッセージを送信するように指示される。また、受信エンティティ410は、ペーシングバッファが空いていることを示すPSFを送信するように指示されるか、あるいは、送信エンティティ405がPSFを受信したときにペーシングバッファ705が空いていることを示すしきい値までペーシングバッファが満たされているときにPSFメッセージを送信するように指示される。他の実施形態において、ペーシングバッファ705がいっぱいになることを示すPSFメッセージが送信されることを指示した後に、ペーシングバッファ705がしきい値以下に落ちたときにPSFメッセージが送信される。例えば、このしきい値は、バッファがビデオを遅延させないことを保証するために50〜75%でありうる。
【0065】
ステップ820において、送信エンティティ405は、デコーダからPSFメッセージを受信する。送信エンティティ405は、現在のペーシングバッファレベル、目標ペーシングバッファレベル、最後に受信されたパケット及び空きバッファ領域を含むPSFに含まれた情報に基づいてデータのストリームを制御する。
【0066】
図9は、本発明の一実施形態による伝送システムにおける受信エンティティを動作させるプロセスを示すフローチャートである。例えば、図9に示すプロセスは、図3のクライアント装置又は図4の受信エンティティ410により実行される。また、このプロセスは、図1の受信エンティティ110により実現される。
【0067】
ステップ905において、受信エンティティ410は、送信エンティティ405に信号を伝送し、受信エンティティ410におけるペーシングバッファの使用がペーシングバッファ705のドレインレートを決定することを示す。特定の実施形態において、受信エンティティ410は、パケットの量又はビデオの時間量に基づいてペーシングバッファのサイズを決定することができる。ドレインレートは、例えば、ビデオのサイズ、バッファのサイズ、及びデータストリームのレートに基づいて決定される。
【0068】
ステップ910において、受信エンティティ410は、ペーシングバッファのドレインレートを示すPRRメッセージを送信エンティティ405に受信する。PRRメッセージは、パケットがFECデコーダ710に送信されるドレインレートを受信エンティティ405に指示する。
【0069】
ステップ915において、受信エンティティ410は、測定構成メッセージを受信する。測定構成メッセージは、PSFメッセージを送信すること、又は、PSFメッセージを送信するための頻度を送信することを受信エンティティ405に指示する。特定環境で、この測定構成メッセージは、特定時間又は要因で伝送される初期メッセージを示すことができる。例えば、測定構成メッセージは、ペーシングバッファが特定パーセントまで満たされたときに、PSFメッセージの伝送を開始するように指示する。測定構成メッセージは、受信エンティティ410が特定のしきい値に基づいてメッセージを送信することを指示する。例えば、受信エンティティは、ペーシングバッファ705がいっぱいになったときにPSFメッセージを送信するように指示するか、あるいは、送信エンティティがPSFメッセージを受信したときにペーシングバッファが満たされることを示すしきい値までペーシングバッファが満たされたときにPSFメッセージを送信するように指示する。また、受信エンティティ410は、ペーシングバッファが空いていることを示すPSFを送信するように指示されるか、あるいは、送信エンティティ405がPSFを受信したときにペーシングバッファ705が空いていることを示すしきい値までペーシングバッファが満たされているときにPSFメッセージを送信するように指示される。他の実施形態において、ペーシングバッファ705がいっぱいになることを示すPSFメッセージが送信されることを指示した後に、ペーシングバッファ705がしきい値以下に落ちたときに、PSFメッセージが送信される。例えば、このしきい値は、バッファがビデオを遅延させないことを保証するために50〜75%でありうる。
【0070】
ステップ920において、受信エンティティ410は、ペーシングバッファ705をモニタリングする。受信された測定構成メッセージによって、受信エンティティ410は、ペーシングバッファ705の現在の状態をモニタリング又はチェックする。ペーシングバッファの状態は、現在のペーシングバッファにバッファリングされたパケット量、ペーシングバッファにバッファリングされるパケットの目標量、サブフローにおいて最後に受信されたパケットのシーケンス番号、及びペーシングバッファの使用可能な空き領域の量を含む。
【0071】
ステップ925において、受信エンティティ410は、PSFメッセージを送信エンティティ405に伝送する。PSFメッセージは、送信エンティティ405から受信された構成メッセージで提供される情報に基づいて送信される。受信エンティティ410は、送信エンティティ405がデータ伝送を調整する必要があるが、測定構成メッセージにより指示されない場合に、PSFメッセージを伝送できる。例えば、この測定構成メッセージは、PSFメッセージを伝送する頻度のみを示し、スケジューリングされたPSFメッセージの間にペーシングバッファがいっぱいになることを示すことができる。受信エンティティ410は、送信エンティティ405が構成メッセージ内にこのPSFメッセージを要求しなくても、ペーシングバッファがいっぱいになることを示すために、この場合、特定のPSFメッセージを伝送できる。
【0072】
図8及び図9は、それぞれ伝送システムにおけるエンティティを送信及び受信するためのプロセスの例を示したが、これら図に対して多様な変更がなされることができる。例えば、一連のステップとして示したが、各図の多様なステップは重なるか、並列的に発生するか、異なる順序で発生するか、あるいは数回発生することができる。
【0073】
本発明の例示的な実施形態では、MMTPがメディアデータ伝送に適した一般のプロトコルを提供することにより、既存の伝送プロトコルを改善し代替するように開発されたことを認識する。MMTPは、リアルタイムストリーミングのようなリアルタイム低遅延アプリケーションだけでなく遅延許容アプリケーションも解決する。MMTPプロトコルが受信器を通じて一貫して動作し、クライアントにより必要なバッファ空間を利用可能にするために、本発明の実施形態はレートペーシングのためにバッファを管理し、必要なバッファ空間を推定し、この情報を送信エンティティにシグナリングする方法及び装置を提供する。この機能は、受信クライアントがハードウェア(例えば、セットトップボックス)で実現されるブロードキャスト受信器において特に重要である。
【0074】
以上、本発明の実施形態について図面を参照しながら詳細に説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の技術的範囲から逸脱しない範囲内で多様に変更実施することが可能である。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【手続補正書】
【提出日】20181203
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
メディア伝送システムにおける伝送装置を作動させるための方法であって、
受信装置のペーシングバッファからデコーディングバッファにパケットを伝送する速度(rate)に対する情報を含むペーシングバッファメッセージを形成するステップと、
前記ペーシングバッファメッセージを前記受信装置に伝送するステップと、
前記ペーシングバッファの状態に対する情報を含むペーシングバッファフィードバックメッセージを前記受信装置から受信するステップと、及び
前記ペーシングバッファフィードバックメッセージに基づいて前記受信装置にメディアデータのパケットを伝送するステップと、を含む、
伝送装置を作動させるための方法。
【請求項2】
前記ペーシングバッファの状態に対する情報は、前記ペーシングバッファにバッファされたパケットの量に対する情報を含む、
請求項1に記載の伝送装置を作動させるための方法。
【請求項3】
前記ペーシングバッファの状態に対する情報は、前記ペーシングバッファにバッファされたパケットのターゲット量に対する情報を含む、
請求項1に記載の伝送装置を作動させるための方法。
【請求項4】
前記ペーシングバッファフィードバックメッセージに基づいて前記受信装置に前 記メディアデータの前記パケットを伝送するステップは、
前記ペーシングバッファにバッファされた前記パケットの前記ターゲット量に対する情報に基づいて、前記メディアデータの前記パケットの伝送のために割り当てられた帯域幅を調整するステップを含む、
請求項3に記載の伝送装置を作動させるための方法。
【請求項5】
前記ペーシングバッファの状態に対する情報は、前記ペーシングバッファの利用可能な空間の量に対する情報を含む、
請求項1に記載の伝送装置を作動させるための方法。
【請求項6】
前記受信装置は、前記ペーシングバッファメッセージに基づいて前記パケットを前記ペーシングバッファから前記デコーディングバッファに伝達する、
請求項1に記載の伝送装置を作動させるための方法。
【請求項7】
前記ペーシングバッファの状態に対する情報は、最後に受信されたパケットのシーケンス番号に対する情報を含む、
請求項1に記載の伝送装置を作動させるための方法。
【請求項8】
メディア伝送システムにおける受信装置を作動させるための方法であって、
前記受信装置のペーシングバッファの状態に対する情報を含むペーシングバッファフィードバックメッセージを形成するステップと、
前記ペーシングバッファフィードバックメッセージを送信装置に伝送するステップと、
前記受信装置の前記ペーシングバッファからデコーディングバッファにパケットを伝送する速度(rate)に対する情報を含むペーシングバッファメッセージを受信するステップと、及び
前記ペーシングバッファメッセージに基づいて、前記パケットを前記ペーシングバッファから前記デコーディングバッファに伝達するステップと、を含む、
受信装置を作動させるための方法。
【請求項9】
前記ペーシングバッファの状態に対する情報は、前記ペーシングバッファにバッファされたパケットの量に対する情報を含む、
請求項8に記載の受信装置を作動させるための方法。
【請求項10】
前記ペーシングバッファの状態に対する情報は、前記ペーシングバッファにバッファされたパケットのターゲット量に対する情報を含む、
請求項8に記載の受信装置を作動させるための方法。
【請求項11】
前記受信装置は、前記ペーシングバッファフィードバックメッセージに基づいて前記受信装置にメディアデータのパケットを伝送する、
請求項8に記載の受信装置を作動させるための方法。
【請求項12】
前記受信装置は、
前記ペーシングバッファにバッファされた前記パケットの前記ターゲット量に対する情報に基づいて、メディアデータのパケットの伝送のために割り当てられた帯域幅を調整することによって、
前記受信装置に前記メディアデータの前記パケットを伝送する、
請求項10に記載の受信装置を作動させるための方法。
【請求項13】
前記ペーシングバッファの状態に対する情報は、前記ペーシングバッファの利用可能な空間の量に対する情報を含む、
請求項8に記載の受信装置を作動させるための方法。
【請求項14】
前記ペーシングバッファの状態に対する情報は、最後に受信されたパケットのシーケンス番号に対する情報を含む、
請求項8に記載の受信装置を作動させるための方法。
【手続補正2】
【補正対象書類名】明細書
【補正対象項目名】0005
【補正方法】変更
【補正の内容】
【0005】
上記目的を達成するために、本発明の一態様によれば、レートペーシングのためにバッファを管理するデコーダが提供される。上記デコーダは、メモリと、信号を送信及び受信するように構成される送受信機と、メモリ及び送受信機に動作可能に接続される処理回路とを含む。上記処理回路は、サーバからデコーダのペーシングバッファに対するドレインレートを示す除去レートメッセージをサーバから受信し、ドレインレートに従ってペーシングバッファからデコーダの復号化バッファへ受信されたパケットを提供する。
【手続補正3】
【補正対象書類名】明細書
【補正対象項目名】0006
【補正方法】変更
【補正の内容】
【0006】
本発明の他の態様によれば、レートペーシングのためにバッファを管理するデコード方法が提供される。この方法は、デコーダのペーシングバッファのドレインレートを示す除去レートメッセージをサーバから受信するステップを有する。また、この方法は、ドレインレートに従ってペーシングバッファからデコーダのデコーディングバッファにパケットを提供することを含む。
【手続補正4】
【補正対象書類名】明細書
【補正対象項目名】0020
【補正方法】変更
【補正の内容】
【0020】
図1は、本発明の多様な実施形態が実現される伝送システム100の一例を示す。図示の実施形態では、システム100は、送信エンティティ101、ネットワーク105、受信エンティティ110、基地局(BS)102、BS103、及び他の類似した基地局又は中継局のような無線伝送ポイント(例えば、進化したノードB(eNB)、ノードB)を含む。送信エンティティ101は、例えばインターネット、メディアブロードキャストネットワーク、又はIPベースの通信システムであるネットワーク105を介して基地局102及び基地局103と通信している。受信エンティティ110は、ネットワーク105及び/又は基地局102及び103を通じて送信エンティティ101と通信している。受信エンティティ110は、ユーザー端末111〜116を含むことができる。
【手続補正5】
【補正対象書類名】明細書
【補正対象項目名】0022
【補正方法】変更
【補正の内容】
【0022】
基地局103は、そのカバレッジ領域125内の第2の複数のユーザー端末にネットワーク105への無線アクセスを提供する。第2の複数のユーザー端末は、ユーザー端末115及びユーザー端末116を含む。施形態において、基地局101-103は、OFDM又はOFDMA技術を用いて相互に及びユーザー端末111〜116と通信することができる。
【手続補正6】
【補正対象書類名】明細書
【補正対象項目名】0024
【補正方法】変更
【補正の内容】
【0024】
ユーザー端末111〜116は、ネットワーク105を介して音声、データ、ビデオ、ビデオ会議、及び/又は他の広帯域サービスにアクセスする。実施形態では、ユーザー端末111〜116のうちの一つ以上は、WiFi WLANのアクセスポイント(AP)に関連される。ユーザー端末116は、無線可能なラップトップコンピュータ、PDA(Personal Data Assistant)、ノートブック、携帯用装置、又は他の無線可能な装置を含む複数の移動装置のうちのいずれか一つである。ユーザー端末114及び115は、例えば無線可能な個人用コンピュータ(PC)、ラップトップコンピュータ、ゲートウェイ、又は他の装置である。
【手続補正7】
【補正対象書類名】明細書
【補正対象項目名】0025
【補正方法】変更
【補正の内容】
【0025】
図2及び図3は、本発明によるコンピュータシステム内の例示的な装置を示す。特に、図2は例示的なサーバ200を示し、図3は例示的なクライアント装置300を示す。サーバ200は、図1の送信エンティティ101、基地局102、又は基地局103を示し、クライアント装置300は、図1の一つ以上のユーザー端末111〜116を含む受信エンティティ110を示す。
【手続補正8】
【補正対象書類名】明細書
【補正対象項目名】0029
【補正方法】変更
【補正の内容】
【0029】
通信インターフェース220は、他のシステム又は装置との通信をサポートする。例えば、通信インターフェース220は、ネットワーク105を介して通信を容易にするネットワークインターフェースカード又は無線送受信機を含む。通信インターフェース220は、任意の適した物理的又は無線通信リンクを通じる通信をサポートできる。
【手続補正9】
【補正対象書類名】明細書
【補正対象項目名】0031
【補正方法】変更
【補正の内容】
【0031】
このような実施形態において、サーバ200は、以下により詳細に説明するように、受信エンティティ110又はユーザー端末111〜116でのレートペーシングのためのバッファ管理を提供する装置を実現する。図2は、図1の送信エンティティ101、基地局103、又は基地局102を示すことを説明したが、同一の又は類似した構造が一つ以上のユーザー端末111〜116を含む受信エンティティ110に使用されることに留意しなければならない。例えば、ラップトップ又はデスクトップコンピュータが図2の図示と同一の構造又は類似した構造を有する。
【手続補正10】
【補正対象書類名】明細書
【補正対象項目名】0032
【補正方法】変更
【補正の内容】
【0032】
図3に示すように、受信エンティティ110又はUE111〜116のようなクライアント装置300は、アンテナ305、無線周波数(RF)送受信機310、送信(TX)処理回路315、マイクロホン320、及び受信(RX)処理回路325を含む。クライアント装置300は、スピーカ330、一つ以上のプロセッサ340、入/出力(I/O)インターフェース(IF)345、キーパッド350、ディスプレイ355、及びメモリ360を含む。メモリ360は、基本オペレーティングシステム(OS)プログラム361及び一つ以上のアプリケーション363を含む。
【手続補正11】
【補正対象書類名】明細書
【補正対象項目名】0037
【補正方法】変更
【補正の内容】
【0037】
プロセッサ340は、キーパッド350及びディスプレイ355にもカップリングされる。クライアント装置300のオペレータは、キーパッド350を用いてデータをクライアント装置300に入力できる。ディスプレイ355は、例えばWebサイトからのテキスト及び/又は少なくとも限定されたグラフィックをレンダリングする液晶ディスプレイ又は他のディスプレイでありうる。
【手続補正12】
【補正対象書類名】明細書
【補正対象項目名】0044
【補正方法】変更
【補正の内容】
【0044】
デジッタバッファ510は、パケットのデジッタリング、すなわちパケットの遅延ジッタの除去に関連する遅延及び/又はバッファサイズ要求事項を推定するために送信エンティティ405により使用されるモデルである。デジッタバッファ510は、最後にMMTPパケットがソースからMMTPプロトコルスタックの出力に固定した伝送遅延を経験することを保証することで、最大伝送遅延を仮定する。受信エンティティ410は、最大伝送遅延より大きい伝送遅延を経験するデータユニットを非常に遅いものとして廃棄する。
【手続補正13】
【補正対象書類名】明細書
【補正対象項目名】0046
【補正方法】変更
【補正の内容】
【0046】
MMTPデカプセル化バッファ515は、出力を上位階層に伝達する前にMMTP処理に関連する遅延及び/又はバッファサイズ要求事項を推定するために送信エンティティ405により使用されるモデルである。MMTPプロセッサの出力は、MFUペイロード(低遅延動作で)、完全なムービーフラグメント、又は完全なMPUでありうる。MPUは、これらのサイズに従って、より小さいパケットにフラグメント化され、あるいはより大きいパケットにアグリゲートされる。MMTP処理の一部として、デカプセル化(MMTPパケット及びペイロードヘッダの除去)及び任意の必要なデフラグメント化/デアグリゲーションが実行される。この手順では、MPUが複数のMMTPパケットにフラグメント化される場合、アセンブリを実行するためにデカプセル化遅延と呼ばれるいくつかのバッファリング遅延を必要とする。しかしながら、この実施形態において、デカプセル化遅延は、固定したエンドツーエンド遅延の一部として考慮されず、符号化されたメディア階層による消費のためのMPUの使用可能性は、デカプセル化遅延に関係なく、MPUを複数のMMTPパケットにフラグメント化するエンティティにより保証される。
【手続補正14】
【補正対象書類名】明細書
【補正対象項目名】0047
【補正方法】変更
【補正の内容】
【0047】
MMTP HRBMは、MMT送信エンティティがMMT受信エンティティのバッファ状態を正確に管理可能にする。MMTP HRBMを使用することによって、基本伝送ネットワークにジッタが多い場合にも、メディアサービスのシームレスな低遅延消費が保証される。その動作のために、MMTP HRBMは、基本伝送ネットワークの全般的な固定したエンドツーエンド遅延を、予めMMT送信エンティティに知らせるための一つのパラメータを要求する。図に示すように、MMTP HRBMは、3個のバッファで構成され、固定したエンドツーエンド遅延、FEC作動及び基本伝送ネットワークの帯域幅変動によるジッタにより引き起こされる遅延の2つの要因が存在する。FEC作動による遅延量がMMTP送信エンティティにより決定されることを考慮すれば、固定したエンドツーエンド遅延の量をわかることは、基本伝送ネットワークのジッタの最大量をわかることを意味する。
【手続補正15】
【補正対象書類名】明細書
【補正対象項目名】0053
【補正方法】変更
【補正の内容】
【0053】
図7は、本発明の多様な実施形態によるペーシングバッファを有する仮想受信器バッファモデル(HRBM)700を示す。HRBM700は、MMTPペーシングバッファ705、FEC復号化バッファ710、デジッタバッファ715、及びMMTPデカプセル化バッファ720を含む。FEC復号化バッファ710、デジッタバッファ715、及びMMTPデカプセル化バッファ720は、図5に示したFEC復号化バッファ505、デジッタバッファ510、及びMMTPデカプセル化バッファ515と類似に機能する。
【手続補正16】
【補正対象書類名】明細書
【補正対象項目名】0059
【補正方法】変更
【補正の内容】
【0059】
測定構成メッセージが送信エンティティ405から受信エンティティ410に伝送されることによって、ペーシングバッファの状態を報告するPSFメッセージのリクエストが指示される。また、測定構成メッセージは、PSFメッセージを送信するための頻度を受信エンティティ410に示すことができる。PSF報告に対するリクエストを示すフラグは"0000 0000 0000 1000"として定義される。このフラグが1に設定される場合、現在の再生状態に関するPSFメッセージを送信エンティティ405に送信することが受信エンティティ410に要請される。
【手続補正17】
【補正対象書類名】明細書
【補正対象項目名】0062
【補正方法】変更
【補正の内容】
【0062】
ステップ805において、送信エンティティ405は、受信エンティティ410内のペーシングバッファに対するドレインレートを決定する。受信エンティティ410は、パケットの量又はビデオの時間量に基づいてペーシングバッファのサイズを決定する。ドレインレートは、例えばビデオのサイズ、バッファのサイズ、データストリームのレートに従って決定される。特定の実施形態では、ペーシングバッファの使用が受信エンティティ410によりシグナリングされる。
【手続補正18】
【補正対象書類名】明細書
【補正対象項目名】0063
【補正方法】変更
【補正の内容】
【0063】
ステップ810において、送信エンティティ405は、ペーシングバッファを示す信号の受信に応答して、デコーダのペーシングバッファのドレインレートを示すPRRメッセージを送信する。PRRメッセージは、パケットがFEC復号化バッファ710に伝送されるドレインレートを受信エンティティ410に指示する。
【手続補正19】
【補正対象書類名】明細書
【補正対象項目名】0066
【補正方法】変更
【補正の内容】
【0066】
図9は、本発明の一実施形態による伝送システムにおける受信エンティティを動作させるプロセスを示すフローチャートである。例えば、図9に示すプロセスは、図3のクライアント装置300又は図4の受信エンティティ410により実行される。また、このプロセスは、図1の受信エンティティ110により実現される。
【手続補正20】
【補正対象書類名】明細書
【補正対象項目名】0068
【補正方法】変更
【補正の内容】
【0068】
ステップ910において、受信エンティティ410は、ペーシングバッファのドレインレートを示すPRRメッセージを送信エンティティ405に受信する。PRRメッセージは、パケットがFEC復号化バッファ710に送信されるドレインレートを受信エンティティ410に指示する。
【手続補正21】
【補正対象書類名】明細書
【補正対象項目名】0069
【補正方法】変更
【補正の内容】
【0069】
ステップ915において、受信エンティティ410は、測定構成メッセージを受信する。測定構成メッセージは、PSFメッセージを送信すること、又は、PSFメッセージを送信するための頻度を送信することを受信エンティティ410に指示する。特定環境で、この測定構成メッセージは、特定時間又は要因で伝送される初期メッセージを示すことができる。例えば、測定構成メッセージは、ペーシングバッファが特定パーセントまで満たされたときに、PSFメッセージの伝送を開始するように指示する。測定構成メッセージは、受信エンティティ410が特定のしきい値に基づいてメッセージを送信することを指示する。例えば、受信エンティティは、ペーシングバッファ705がいっぱいになったときにPSFメッセージを送信するように指示するか、あるいは、送信エンティティがPSFメッセージを受信したときにペーシングバッファが満たされることを示すしきい値までペーシングバッファが満たされたときにPSFメッセージを送信するように指示する。また、受信エンティティ410は、ペーシングバッファが空いていることを示すPSFを送信するように指示されるか、あるいは、送信エンティティ405がPSFを受信したときにペーシングバッファ705が空いていることを示すしきい値までペーシングバッファが満たされているときにPSFメッセージを送信するように指示される。他の実施形態において、ペーシングバッファ705がいっぱいになることを示すPSFメッセージが送信されることを指示した後に、ペーシングバッファ705がしきい値以下に落ちたときに、PSFメッセージが送信される。例えば、このしきい値は、バッファがビデオを遅延させないことを保証するために50〜75%でありうる。
【手続補正22】
【補正対象書類名】明細書
【補正対象項目名】0073
【補正方法】変更
【補正の内容】
【0073】
本発明の実施形態では、MMTPがメディアデータ伝送に適した一般のプロトコルを提供することにより、既存の伝送プロトコルを改善し代替するように開発されたことを認識する。MMTPは、リアルタイムストリーミングのようなリアルタイム低遅延アプリケーションだけでなく遅延許容アプリケーションも解決する。MMTPプロトコルが受信器を通じて一貫して動作し、クライアントにより必要なバッファ空間を利用可能にするために、本発明の実施形態はレートペーシングのためにバッファを管理し、必要なバッファ空間を推定し、この情報を送信エンティティにシグナリングする方法及び装置を提供する。この機能は、受信クライアントがハードウェア(例えば、セットトップボックス)で実現されるブロードキャスト受信器において特に重要である。


【国際調査報告】