JP6526289B2 - ダウンローディング及びストリーミングをサポートするパケットの送信装置 - Google Patents

Description

本発明は、メディアデータ送信に関し、より詳しくは、ダウンローディング及びストリ
ーミングの両方をサポートするパケット送信プロトコルに関する。

ＭＰＥＧ（Moving Picture Experts Group）メディアトランスポート（ＭＰＥＧ media
transport：ＭＭＴ）は、異種ＩＰ（Internet Protocol）ネットワーク環境を通じてマ
ルチメディアサービスについてのコード化されたメディアデータの伝送のための技術を規
定するデジタルコンテナ標準又はフォーマットである。伝送されてコード化されたメディ
アデータは、指定された時間で、同期化されたデコーディングと、データの特定のユニッ
トの提示（presentation）を要求する視聴覚メディアデータ、即ち、同期型データ（time
d data）と、前記ユーザによるサービスのコンテキスト又は相互作用（interaction）に
基づいて、任意の時間でデコードし、提示されるデータの他のタイプ、即ち非同期型デー
タ（non-timed data）の両方を含む。

新しいパケット化モード、一般ファイル伝送（Generic File Delivery：ＧＦＤ）モー
ドが、前記ＭＭＴ伝送機能へ導入されている。しかし、ＭＭＰＴへの前記モードの統合と
、既存のペイロードモードとの統合は、最適化されていなかった。従って、メディアデー
タ送信のための装置及び方法が必要である。

本発明は、ダウンローディング及びストリーミングをサポートできるパケット送信プロ
トコルを用いて、トランスポートパケットを生成し、処理する方法及び装置を提供する。

本発明の一態様によると、送信エンティティによりトランスポートパケットを生成する
方法が提供される。この方法は、パケットヘッダと、ペイロードヘッダと、ペイロードと
を含ために、トランスポートパケットを生成する過程と、ここで、前記パケットヘッダは
、複数のペイロードタイプのうちの一つを示すフィールド内に、ペイロードタイプの識別
子を含み、前記複数のペイロードタイプは、ダウンロードモードの第１ペイロードタイプ
と、ストリーミングモードの第２ペイロードタイプとを含み、前記トランスポートパケッ
トを送信する過程とを含む。

本発明の他の態様によると、トランスポートパケットを生成できる送信エンティティ内
の装置が提供される。この装置は、パケットヘッダと、ペイロードヘッダと、ペイロード
とを含ために、トランスポートパケットを生成するプロセッシング回路と、ここで、前記
パケットヘッダは、複数のペイロードタイプのうちの一つを示すフィールド内に、ペイロ
ードタイプの識別子を含み、前記複数のペイロードタイプは、ダウンロードモードの第１
ペイロードタイプと、ストリーミングモードの第２ペイロードタイプとを含み、前記トラ
ンスポートパケットを送信する送信器とを含む。

本発明のまた他の態様によると、受信エンティティによりトランスポートパケットを処
理する方法が提供される。この方法は、パケットヘッダと、ペイロードヘッダと、ペイロ
ードとを含ために、トランスポートパケットを受信する過程と、ここで、前記パケットヘ
ッダは、複数のペイロードタイプのうちの一つを示すフィールド内に、ペイロードタイプ
の識別子を含み、前記複数のペイロードタイプは、ダウンロードモードの第１ペイロード
タイプと、ストリーミングモードの第２ペイロードタイプとを含み、前記パケットヘッダ
及び前記ペイロードヘッダにより、前記ペイロードを処理する過程とを含む。

本発明のまた更なる他の態様によると、トランスポートパケットを処理することができ
る受信エンティティ内の装置が提供される。この装置は、パケットヘッダと、ペイロード
ヘッダと、ペイロードとを含むために、トランスポートパケットを受信する受信器と、こ
こで、前記パケットヘッダは、複数のペイロードタイプのうちの一つを示すフィールド内
に、ペイロードタイプの識別子を含み、前記複数のペイロードタイプは、ダウンロードモ
ードの第１ペイロードタイプと、ストリーミングモードの第２ペイロードタイプとを含み
、前記パケットヘッダ及び前記ペイロードヘッダにより前記ペイロードを処理するプロセ
ッシング回路とを含む。

下記の詳細な説明を記載する前に、本明細書を通じて用いられる特定の単語及び構文を
定義することが有益となるはずである。用語「含む（include）)及び「含む（comprise）
)と、これらによる派生語とは、限定されずに包含を意味する。用語「又は（or）」は、
包括的であり、「及び／又は」を意味する。構文「〜と関連した（associated with）)及
び「〜と関連した（associated therewith）」と、これらによる派生語は、含む（includ
e）、〜内に含まれる（be included within）、相互に連結する（interconnect with）、
包含する（contain）、〜内に包含される（be contained within）、〜に連結する又は〜
と連結する（connect to or with）、〜と連結する又は〜に連結する（couple to or wit
h）、〜と通信可能である（be communicable with）、〜と協調する（cooperate with）
、交互配置する（interleave）、並置する（juxtapose）、〜に最も近い（be proximate
to）、〜に結合する又は〜と結合される（be bound to or with）、有する（have）、所
有する（have a property of）などのようなことを意味し、前記用語「制御器」は、少な
くとも一つの動作を制御する制御する任意のデバイス、システム、又はこれらの一部を意
味し、このようなデバイスは、ハードウェア、ファームウェア（firmware）又はソフトウ
ェア、又はこれらの少なくとも二つの一部の組み合わせで実現され得る。特定の制御器と
関連した機能は、集中化されるか、或いは分散されても良く、局部的であるか、遠隔的で
あってもよいことに留意すべきである。特定の単語及び構文についての定義は、本明細書
の全般に渡って提供され、当該技術分野における当業者は、大部分の場合でなくても、前
記のような定義が、従来だけでなく、前記のように定義された単語及び構文の未来の使用
にも適用されることを理解すべきである。

本開示の多様な実施形態が実現できる送信システムの一例を示している図面である。 本開示の多様な実施形態によるＭＭＴパッケージと、該ＭＭＴパッケージの論理構造とを示している図面である。 本開示の実施形態による異なるアセットからＭＰＵの提示のための提示情報ドキュメント（presentation information document）により提供されるタイミングの一例を示している図面である。 本開示の多様な実施形態によるストリーミングモードペイロードヘッダについての例示的な構造を示している図面である。 本開示の多様な実施形態による同期型（timed）メディアフラグメントユニット（ＭＦＵ）ヘッダについての例示的な構造を示している図面である。 本開示の多様な実施形態による非同期型（non-timed）ＭＦＵヘッダについての例示的な構造を示している図面である。 本開示の多様な実施形態によるシグナリングメッセージヘッダについての例示的な構造を示している図面である。 本開示の多様な実施形態によるＧＦＤモードパケット構造についての例示的な構造を示している図面である。 本開示の多様な実施形態によるＭＭＴパケットについての例示的な構造を示している図面である。 本開示の多様な実施形態によるヘッダ拡張についての例示的な構造を示している図面である。 本開示の多様な実施形態による同期型メディアデータのパケット化の例示的なダイアグラムを示している図面である。 本開示の多様な実施形態による非同期型メディアデータのパケット化の例示的なダイアグラムを示している図面である。 本開示の多様な実施形態による受信エンティティにおけるトランスポートパケットを処理するプロセスを示している図面である。 本開示の多様な実施形態による送信エンティティにおけるトランスポートパケットを生成するプロセスを示している図面である。 本開示の多様な実施形態が実現できる電子デバイスの例を示している図面である。

以下で説明する図１〜図１５と、本明細書における本開示の基本原則を説明するために
用いられる多様な実施形態とは、単に例示するだけのものであり、本開示の範囲を制限す
る方式として理解してはいけない。当該技術分野における当業者であれば、本開示の基本
原則が、適切に配列されたシステム又はデバイスにおいて実現できることを理解すべきで
ある。

ＭＭＴコーディング及びメディア伝送は、ここで完全に説明されるように、本開示に含
まれる、以下の文献及び標準技術、MPEG-H Systems、Text of ISO／IEC 2nd CD 23008-1
MPEG Media Transportに論議される。ＭＭＴは、カプセル化（encapsulation）と、伝送
（delivery）と、シグナリング（signaling）とを含む３個の機能領域を定める。カプセ
ル化機能領域は、ＭＭＴコンプライアントエンティティ（MMT compliant entity）により
処理される、メディアコンテンツと、ＭＭＴパッケージと、フォーマットデータユニット
との論理構造を規定する。ＭＭＴパッケージは、メディアコンテンツと、適応的な伝送が
必要となる情報を提供するメディアコンテンツ間の関係とを含む構成要素を指定する。デ
ータユニットのフォーマットは、前記コード化されたメディアを伝送プロトコルのペイロ
ードとして格納されるか、或いは運ばれるようにカプセル化し、格納と運搬との間で変換
しやすくなるように定義される。伝送機能領域は、アプリケーション階層プロトコルと、
ペイロードのフォーマットとを定める。アプリケーション階層プロトコルは、マルチメデ
ィアの伝送のための通常のアプリケーション階層プロトコルと比べて、ＭＭＴパッケージ
の伝送のために、多重化（multiplexing）を含む向上した特徴を提供する。ペイロードフ
ォーマットは、特定のメディアタイプ又は符号化方式に不可知（agnostic）のコード化さ
れたメディアデータを運搬するために定められる。シグナリング機能領域は、ＭＭＴパッ
ケージの伝送及び消費を管理するために、メッセージのフォーマットを定める。消費管理
のためのメッセージは、ＭＭＴパッケージの構造をシグナルするために用いられ、伝送管
理のためのメッセージは、ペイロードフォーマットの構造及びプロトコルの構成をシグナ
ルするために用いられる。

ＭＭＴは、オーディオ、ビデオのような時間連続のマルチメディア及びウィジェット、
ファイルなどのような他の固定コンテンツ（static content）の伝送のための新しいフレ
ームワークを定める。ＭＭＴは、ＭＭＴパッケージを受信エンティティへ伝送するための
プロトコル（即ち、ＭＭＴＰ）を規定する。ＭＭＴＰは、前記プロトコルヘッダの一部と
して、ＭＭＴＰパッケージの送信時間をシグナルする。このような時間は、受信エンティ
ティが、各入力ＭＭＴパケットの送信時間及び受信時間を検査することにより、デジッタ
（de-jittering）を行うことを可能とする。

本開示の実施形態は、新しいパケット化モード、ＧＦＤモードが、ＭＭＴ伝送機能に導
入されたことを認識する。ＧＦＤは、任意の一般ファイルの送信を可能にする。本開示の
実施形態は、現在ＭＭＴが、４個の他のパケット化モード、メディアプロセッシングユニ
ット（media processing unit：ＭＰＵ）モード、ＭＰＵフラグメントモード、シグナリ
ングメッセージモード、及び前方エラー訂正（forward error correction：ＦＥＣ）モー
ドを定めることを認識する。ＭＰＵモードは、完全なＭＰＵを伝送し、トランスポート階
層に分割（fragmentation）を委ねる。ＭＰＵフラグメントモードは、ＭＰＵ伝送のため
に最適化され、メディア認識方式（media-aware manner）でパケット化が行われて、ＭＰ
Ｕフラグメントタイプ及び特性に関して受信クライアントに知らせる。ＦＥＣモード及び
シグナリングモードは、それぞれＦＥＣリペアパケット（FEC repair packet）及びシグ
ナリングメッセージを伝送するためのものである。ここで、ＦＥＣリペアパケットは、一
つ以上の損失ソースパケットを復元するために用いられるＦＥＣリペアフローのセグメン
ト化セットを運ぶ。

本開示の実施形態は、全体のＭＰＵが、何のメディア認識パケット化もなく、オブジェ
クト（object）として伝送されるため、ＭＰＵモードがＧＦＤモードのサブケース（sub-
case）として看做されてもよいことを認識する。ＭＰＵに関する情報は、ＧＦＤモードに
おけるオブジェクトのメタデータの一部として完全に伝送されることができる。従って、
本開示の実施形態は、明確性のために、ＭＰＵモードを除去し、ＭＰＵフラグメントモー
ドを、ＭＰＵモードと新たに命名することを提供する。結果的に、ＭＰＵは、ＧＦＤモー
ドを用いて、一般オブジェクトとして伝送されてもよく、又はＭＰＵモードを用いて、独
立的なフラグメントの集合として伝送されてもよい。

本開示の実施形態は、現在パケットのペイロードフォーマットが、複数個の階層を介し
て分割されることを認識する。主なペイロードヘッダが、各ペイロードフォーマットに必
要であり、ＭＭＴＰプロトコルヘッダに一対一のマッピングを有する。本開示の実施形態
は、一般ペイロードヘッダを、ＭＭＴＰプロトコルヘッダと併合し、ペイロードタイプに
よって、残りのペイロードヘッダを生成することを認識する。例えば、分割及び集合（ag
gregation）は、また一部のペイロードタイプ、例えば、ＦＥＣ及びＧＦＤが、集合及び
分割を必要としないため、ペイロードタイプに依存している。本開示の実施形態は、また
シグナリングメッセージ及びアップデートの容易な識別を可能とするメッセージのシグナ
リングのためのペイロードタイプを提供する。また、前記ペイロードフォーマットは、シ
グナリングメッセージの集合及び分割を可能とする。

図１は、本開示の多様な実施形態が実現できる送信システム１００の一例を示している
図面である。図示した実施形態において、無線システム１００は、送信エンティティ１０
１と、ネットワーク１０５と、受信エンティティ１１０〜１１６と、基地局（ＢＳ）１０
２、基地局（ＢＳ）１０３、及び他の類似の基地局或いは中継局（図示せず）のような無
線送信点（例えば、ｅＮＢ（Evolved Node B）、ノードＢ）とを含む。送信エンティティ
１０１は、例えば、インターネット、メディアブロードキャストネットワーク、或いはＩ
Ｐ基盤の通信システムであってもよいネットワーク１０５を通じて、基地局１０２及び基
地局１０３と通信している。受信エンティティ１１０〜１１６は、ネットワーク１０５及
び／又は基地局１０２、１０３を介して、送信エンティティ１０１と通信している。例え
ば、受信エンティティ１１０〜１１６は、送信エンティティ１０１からダウンローディン
グ及びストリーミングのために、メディアデータを受信する。多様な実施形態において、
本開示の教示により、送信エンティティ１０１は、ＭＭＴＰパケットを生成及び送信して
もよく、一つ以上の受信エンティティ１１０〜１１６は、前記ＭＭＴＰパケットを受信及
び処理してもよい。

基地局１０２は、基地局１０２のカバレッジ領域（coverage area）１２０内で、複数
の第１受信エンティティ（例えば、ユーザ端末、携帯電話、移動局、加入者ステーション
）に、ネットワーク１０５に対する無線アクセス（基地局１０１を介して）を提供する。
複数の第１受信エンティティは、スモールビジネス（small business：ＳＢ）に位置付け
られるユーザ端末１１１と、エンタープライズ（enterprise：Ｅ）に位置付けられるユー
ザ端末１１２と、ワイファイ（WiFi）ホットスポット（hotspot：ＨＳ）に位置付けられ
るユーザ端末１１３と、第１レジデンス（residence：Ｒ）に位置付けられるユーザ端末
１１４と、第２レジデンス（residence：Ｒ）に位置付けられるユーザ端末１１５と、携
帯電話、無線通信可能なラップトップ、無線通信可能なＰＤＡ、タブレットＰＣ（tablet
computer）などのようなモバイルデバイス（Ｍ）であり得るユーザ端末１１６とを含む
。

基地局１０３は、基地局１０３のカバレッジ領域１２５内で、複数の第２ユーザ端末に
、ネットワーク１０５に対する無線アクセスを提供する。複数の第２ユーザ端末は、ユー
ザ端末１１５と、ユーザ端末１１６とを含む。一実施形態において、基地局１０１〜１０
３は、ＯＦＤＭ技術或いはＯＦＤＭＡ技術を用いて、互いに通信してもよく、ユーザ端末
１１１〜１１６と通信してもよい。

図１には、６個のユーザ端末のみが示されているが、システム１００は、追加のユーザ
端末に無線広帯域及びネットワークアクセスを提供できることが分かる。ユーザ端末１１
５及びユーザ端末１１６は、カバレッジ領域１２０及びカバレッジ領域１２５の両方の境
界（edge）に位置する。ユーザ端末１１５及びユーザ端末１１６は、それぞれ基地局１０
２及び基地局１０３の両方と通信し、当該技術分野における当業者に知られているように
、ハンドオフモード（handoff mode）で操作してもよい。

ユーザ端末１１１〜１１６は、ネットワーク１０５を通じて、メディアデータ音声、デ
ータ、ビデオ、ビデオ会議、及び/又は他のサービスをアクセスすることができる。一実
施形態において、一つ以上のユーザ端末１１１〜１１６は、WiFi WLANのアクセスポイン
ト（access point：ＡＰ）と関連付けられ得る。ユーザ端末１１６は、無線可能なラップ
トップコンピュータ、個人用データアシスタント、ノートパソコン（notebook）、携帯用
デバイス、又は他の無線可能なデバイスを含む、多数のモバイルデバイスのうちのいずれ
かであってもよい。ユーザ端末１１４、１１５は、例えば、無線可能なパソナールコンピ
ュータ（ＰＣ）、ラップトップ、ゲートウェイ（gateway）、又は他のデバイスであって
もよい。

図２は、本開示の多様な実施形態によるＭＭＴパッケージ２００及び該ＭＭＴパッケー
ジ２００の論理構造を示している図面である。図２を参照すると、ＭＭＴパッケージ２０
０は、一つ以上の提示情報ドキュメント（presentation information document）２０５
と、関連するトランスポート特性２１５を有してもよい一つ以上のアセット２１０とを含
む。アセット２１０は、同一のアセット識別子（identification：ＩＤ）を共有する一つ
以上のメディアプロセッシングユニット（ＭＰＵ）２２０の集合である。アセット２１０
は、オーディオ或いはビデオ、又はウェブページ（web page）のような符号化メディアデ
ータを含む。前記メディアデータは、同期型又は非同期型であり得る。

提示情報（ＰＩ）ドキュメント２０５は、消費のためのアセット２１０のうち、空間及
び時間関係を特定する情報を含む。ハイパーテキストマークアップ言語（hypertext mark
up language：ＨＴＭＬ）と、構成情報（composition information：ＣＩ）ドキュメント
との組合せが、ＰＩドキュメント２０５の例である。また、ＰＩドキュメント２０５は、
パッケージ２００に含まれているアセット２１０の伝送順序を決めるために用いられても
よい。ＰＩドキュメント２０５は、一つ以上のメッセージとして、又は完全なドキュメン
トとして伝送される。放送伝送の場合において、サービス提供者は、提示情報ドキュメン
ト２０５を連続的に循環し、循環が行われる周波数を決める。

アセット２１０は、マルチメディア提示を組み立てるために用いられるマルチメディア
データである。前述のように、アセット２１０は、符号化されたメディアデータを運ぶた
めに、同一のアセットＩＤを共有するＭＰＵを論理的にグルップ化したものである。アセ
ット２１０の符号化されたメディアデータは、同期型データ又は非同期型データとなり得
る。同期型データは、内在するタイムライン（timeline）を有し、指定時間でデータユニ
ットの同期化された復号化及び提示を要求できる符号化されたメディアデータである。非
同期型データは、サービスのコンテキスト又はユーザの指示に基づいて、任意の時間で復
号化することができる他のタイプのデータである。

単一アセット２１０のＭＰＵ２２０は、同期型又は非同期型メディアを有する。同期型
メディアデータを運搬する同一のアセット２１０の２個のＭＰＵ２２０は、これらの提示
時間にオーバーラップできない。提示の指示がない場合、同一のアセット２１０のＭＰＵ
２２０は、これらのシーケンス番号によって順次にプレイバック（play back）してもよ
い。ＭＭＴ受信エンティティの提示エンジンにより個別的に消費できるメディアデータの
タイプは、個別アセット２１０として考慮してもよい。個別アセット２１０として考慮で
きるメディアデータタイプの例は、オーディオ、ビデオ、又はウェブページメディアデー
タタイプである。

ＭＰＵ２２０は、ＭＭＴエンティティにより処理し、他のＭＰＵ２２０から独立的に提
示エンジンにより消費してもよいメディアデータアイテムである。ＭＭＴエンティティに
よるＭＰＵ２２０の処理は、カプセル化/脱カプセル化（decapsulation）及びパケット化
/逆パケット化（depacketization）を含む。ＭＰＵ２２０の消費は、メディア処理（例え
ば、符号化/復号化）及び提示を含む。パケット化の目的のために、ＭＰＵ２２０は、ア
クセスユニット（ＡＵ）より小さくてもよいデータユニットに分割され得る。ＭＰＵのシ
ンタックス（syntax）及びセマンティックス（semantics）は、前記ＭＰＵに運搬される
メディアデータのタイプに依存しない。

ＭＰＵ２２０は、他の標準、例えば、ＭＰＥＧ−４ ＡＶＣ（advanced video coding
）又はＭＰＥＧ−２ ＴＳ（transport stream）によってフォーマット化されたデータの
一部を含んでもよい。アセット識別子（asset_id「Ｙ」を有するアセットに依存するasse
t_id「Ｘ」を有するアセットの場合、asset_id「Ｘ」を有するアセットのｍ番目のＭＰＵ
と、asset_id「Ｙ」を有するアセットのｎ番目のＭＰＵとは、「ｍ」が「ｎ」と同一でな
い時にはいつも、即ち、asset_id「Ｘ」を有するアセットのｍ番目のＭＰＵに含まれてい
るサンプルは、asset_id「Ｙ」を有するアセットのｎ番目のＭＰＵのサンプルの境界によ
り定められる時間間隔内に存在しない時にはいつも、オーバーラップしない。

追加的に、セグメントインデックス（segment index：「sidx」）ボックスが存在する
場合「sidx」ボックスにより定められるメディア間隔は、オーバーラップされない、即ち
、ＭＰＵに含まれているk番目のメディア間隔（「sidx」boxにより定められる）に含まれ
ているメディアサンプルが、「ｋ」と異なる「ｊ」について、ｊ番目のメディア時間間隔
（前記「sidx」ボックスにより定められる）のサンプル境界により定められる時間間隔の
内に存在しない。「sidx」ボックスが存在しない場合、ＭＰＵメタデータなしで、asset_
id「Ｙ」を有するアセットのＭＰＵのｊ番目のＭＰＵと、 asset_id「Ｘ」を有するアセ
ットのＭＰＵのｊ番目のＭＰＵとの間の連接（concatenation）は、有効なＭＰＵを招く
。「sidx」ボックスが存在する場合、asset_id「Ｙ」を有するアセットのｊ番目のＭＰＵ
のｋ番目のメディア間隔（「sidx」ボックスにより定められる）と、asset_id「Ｙ」を有
するＭＰＵのメタデータに従うasset_id「Ｘ」を有するアセットのｊ番目のＭＰＵのｋ番
目のメディア間隔（「sidx」ボックスにより定められる）との連接は、有効なＭＰＵを招
く。

単一ＭＰＵは、整数のＡＵ或いは非同期型データを含む。即ち、同期型データの場合、
単一ＡＵは、複数のＭＰＵに分割されない。非同期型データの場合、単一ＭＰＵは、提示
エンジンにより消費される、一つ以上の非同期型アイテムを含む。ＭＰＵは、関連のasse
t_id及びシーケンス番号により識別される。

同期型メディアを含むＭＰＵは、ここで参考に含まれる、ＩＳＯ／ＩＥＣ１４４９６−
１２のAnnexIに規定されたように、少なくとも一つのストリームアクセスポイント（ＳＡ
Ｐ）を含む。ＭＰＵの第１アクセスユニットは、ＭＭＴエンティティによる処理のための
ＳＡＰである。同期型メディアの場合、ＭＰＵペイロードにおける第１ＡＵの復号化順序
が「０」であることを意味する。他の標準によりフォーマット化されたデータを含むＭＰ
Ｕの場合、ＭＰＵペイロードはそのようなフォーマットの処理に必要な情報で開示する。
例えば、ＭＰＵがビデオデータを含む場合、ＭＰＵペイロードは、一つ以上のピクチャー
群と、これらの処理に要求されるデコーダ構成情報とを含む。他の例において、ＭＰＵが
ＭＰＥＧ−２ ＴＳパケットを含む場合、MPU ＭＰＵペイロードは、残り又は後続のＴＳ
パケットのためのプログラム関連テーブル（ＰＡＴ)プログラムマップテーブル（ＰＭＴ)
を含むＴＳパケットで開始し得る。同期型メディアデータの場合、各ＡＵの提示期間、復
号化順序、及び提示順序が、ＭＰＵメタデータの一部としてシグナルされる。前記ＭＰＵ
は、初期提示時間を有さない。ＭＰＵにおける第１ＡＵの提示時間は、ＰＩドキュメント
により記述される。前記ＰＩドキュメントは、各ＭＰＵの初期提示時間を特定する情報を
含む。

図３は、本開示の実施形態による異なるアセットからＭＰＵの提示についてのＰＩドキ
ュメントにより提供されるタイミング（timing）の一例を示している図面である。図３を
参照すると、ＰＩドキュメントは、ＭＭＴ受信エンティティが、アセット＃１及びアセッ
ト＃２のＭＰＵ＃１を同時に提示することを指定する。以後のポイントにおいて、アセッ
ト＃３からのＭＰＵ＃１が提示されるとスケジュールされる。最後に、アセット＃１及び
アセット＃２のＭＰＵ＃２が、同期化されて提示される。ＭＰＵについて指定された提示
時間は、ＭＰＵの第１ＡＵの提示時間を定める。非同期型メディアデータを含むＭＰＵは
、１個のデータアイテムをエントリポイント（entry point）として指定することができ
る。

ＭＦＵは、トランスポートの目的のために、ＭＰＵのメディア認識分割を可能とする。
これは、ＭＭＴ送信エンティティが、受信側での消費を考慮して、ＭＰＵの分割を行うこ
とを許容する。ＭＦＵは、同期型メディアデータに対して、ＡＵより小さくてもよいメデ
ィアデータユニットを含み、前記含まれたメディアデータは、メディアデコーダにより処
理してもよい。ＭＦＵは、前記運搬されるメディアデータの境界で情報を含むＭＦＵヘッ
ダを含む。ＭＦＵのシンタックス及びセメンティックスは、ＭＦＵに運搬されるメディア
データのタイプとは独立的である。ＭＦＵのサイズが、リンク階層フレーム（link layer
frame）のサイズより大きい場合、ＭＦＵは、複数のリンク階層フレームに分割されても
よい。ＭＦＵは、符号化されたメディアフォーマットに依存しない方式で、単一ＡＵ内の
ＭＦＵ同士間の関係情報のみならず、同一のＭＰＵにおいて一つのＭＦＵを他のＭＦＵと
区別する識別子を含む。単一ＡＵに含まれているＭＦＵ同士間の従属関係は、複数のＭＦ
Ｕの相対的優先順位として説明される。前記情報は、向上した伝送のために、下位伝送階
層（underlying delivery layer）により使われることができる。例えば、伝送階層は、
廃棄可能な複数のＭＦＵの伝送をスキップ（skip）して、特定の環境、例えば、ネットワ
ークの特定のリンク上の不十分な帯域幅の下で、ＱｏＳ（Quality of Service）をサポー
トすることができる。

本開示の多様な実施形態によると、ＭＭＴペイロードは、ＭＭＴプロトコル（MMT prot
ocol：ＭＭＴＰ）を用いて、アセットと、一般オブジェクトと、ＭＭＴパッケージの消費
のための他の情報とを、パケット化及び運搬するために用いられる一般ペイロードである
。ＭＭＴペイロードは、複数のＭＰＵと、一般オブジェクトと、シグナリングメッセージ
とをパケット化するために用いられてもよい。ＭＭＴペイロードは、複数のＭＰＵのフラ
グメントと、一つ以上のシグナリングメッセージと、一つ以上の一般オブジェクト（完全
なＭＰＵを含む）と、一つ以上のリペアシンボルなどを運搬することができる。前記ペイ
ロードのタイプは、下記の図９でより具体的に説明する、前記ＭＭＴＰパケットヘッダに
含まれているタイプ（又はオブジェクトタイプ）フィールドにより指示される。各ペイロ
ードタイプにつき、タイプ特定のペイロードヘッダのみならず、伝送のための単一データ
ユニットが定められる。例えば、ＭＰＵ（例えば、ＭＦＵ）のフラグメントは、ＭＭＴペ
イロードが、ＭＰＵフラグメントを運搬するとき、単一データユニットとして考慮される
。ＭＭＴプロトコルは、同一のデータタイプを有する複数のデータユニットを、単一ペイ
ロードに集合することができる。また、ＭＭＴプロトコルは、単一データユニットを多数
のパケットに分割することができる。

ＭＭＴペイロードは、ペイロードヘッダ及びペイロードデータから構成される。一部の
データタイプは、単一データユニットが、多数のフラグメントに分割されるか、又はデー
タユニットの集合が、単一パケットに伝送される場合での分割及び集合を許容することが
できる。各データユニットは、ペイロードのタイプに応じて、各データユニット固有のペ
イロードヘッダを有してもよい。ペイロードタイプ特定のヘッダを要求しないタイプにつ
いて、何のペイロードタイプヘッダも存在せず、ペイロードデータは、ＭＭＴＰヘッダに
従う。ＭＭＴＰパケットの一部フィールドは、ペイロードタイプに基づいて別に解釈され
る。このようなフィールドのセマンティックスは、使用時のペイロードタイプにより定め
られる。

図４は、本開示の多様な実施形態によるストリーミングモードペイロードヘッダ４００
についての例示的な構造を示している図面である。

ＭＭＴプロトコルを用いるＭＰＵのＭＭＴ受信器への伝送は、大きなＭＰＵの伝送を可
能とするために、送信器及び受信器の各々において生じるパケット化及び逆パケット化の
手続きを要求する。ＭＰＵ伝送モードは、ＭＰＵの多様なサイズ変化を可能とするパケッ
ト化及び集合のために、完全なＭＰＵ又は独立的な伝送データユニットである単一ＭＰＵ
の特定のサブパート（subpart）を考慮する。ＭＭＴＰペイロードフォーマットのストリ
ーミングモード（例えば、ＭＰＵモード）は、単一伝送データユニットを多数のＭＭＴＰ
ペイロードに分割して、大きなサイズを有するＭＰＵの伝送をサポートできるようにする
。また、ストリーミングモードは、同一のタイプを有する多数の伝送データユニットの単
一ＭＭＴＰペイロードへの集合を許容して、より小さいデータユニットを供給する。パケ
ット化手続きは、ＭＰＵが分割される場合、ＭＰＵを各ＭＭＴＰパケットに伝送されるＭ
ＭＴＰペイロードの集合に変換してもよい。受信エンティティで、逆パケット化が行われ
て、元のＭＰＵデータを復元する。

ペイロードタイプ０ｘ００において、ＭＰＵは、トランスポート階層が、伝送されるフ
ラグメントの属性及び優先順位を識別することを許容するメディア認識方式で分割される
。ＭＰＵのフラグメントは、例えば、ＭＰＵメタデータ、又はムービーフラグメントメタ
データ、ＭＦＵ、又は非同期型データアイテム（non-timed data item）となってもよい
。このストリーミングモードは、またシグナリングメッセージの伝送又は復元シンボルの
ために用いられる。

図４を参照すると、ストリーミングモードペイロードヘッダ４００のセマンティックス
と、ストリーミングモードペイロードヘッダ４００の各フィールドの長さは、以下のよう
に提供される。長さフィールド４０２は、１６ビットの長さを有し、このフィールドを含
む全体ペイロードのサイズを示す、伝送データユニットタイプ（DU_type）フィールド４
０４が、５ビットの長さであり、例えば、下記の表１により提供されるような、ペイロー
ドの伝送データユニットタイプを示す。

ストリーミングモードペイロードヘッダ４００のフィールドと連続して、aggregation_
flag（Ａ）フィールド４０６は、１ビッドの長さであり、「１」と設定される場合、１個
以上の伝送データユニットが、分割指示子（fragmentation indicator）f_iフィールド４
０８が無視されるペイロードに存在することを示す。f_iフィールド４０８は、２ビット
の長さであり、分割識別子が、例えば、下記の表２に示されているようなペイロードに含
まれているデータユニットの分割についての情報を含むことを示す。

f_iフィールド４０８の値は、前記フィールド「Ａ」の値が「１」の場合、「００」と
設定されてもよい。

ストリーミングモードペイロードヘッダ４００のフィールドと連続して、カウンタ（co
unter）フィールド４１０は、１６ビットであり、aggregation_flagが「０」と設定され
る場合、ＭＭＴペイロードに連続する同一の伝送データユニットのフラグメントを含むペ
イロードの個数を示し、aggregation_flagが「１」と設定される場合、ペイロードに集合
されている伝送データユニットの個数を示す。DU_lengthフィールド４１２は、１６ビッ
トの長さを有し、DU_lengthフィールド４１２の次のデータの長さを示す。aggregation_f
lagが「０」と設定される場合、DU_lengthフィールド４１２は存在できない。aggregatio
n_flagが「１」と設定される場合、DU_lengthフィールド４１２は、集合されたデータユ
ニット各々の先に、「counter」フィールド４１０の値ほど現れ得る。DU_Headerフィール
ド４１４は、データユニットのヘッダであり、データユニットのヘッダは、以下でより具
体的に説明する、伝送データユニットのタイプに依存する。aggregation_flagが「１」と
設定される場合、DU_Headerフィールド４１４は、集合された伝送データユニット各々の
先に、「counter」フィールド４１０の値ほど現れ得る。aggregation_flagが「０」と設
定される場合、DU_Headerフィールド４１４は、「f_i」フィールド４０８の値が「０１」
の場合、現れ得る。

図５は、本開示の多様な実施形態による同期型-メディアＭＦＵヘッダ５００について
の例示的な構造を示している図面である。同期型-メディアＭＦＵヘッダ５００は、同期
型メディアデータについての、図４のDU_header４１４に含まれているような伝送データ
ユニットヘッダの一例である。

図５を参照すると、同期型-メディアＭＦＵヘッダ５００の各フィールドのセマンティ
ックス及び長さは、以下のように提供される。movie_fragment_sequence_numberフィール
ド５０２は、３２ビットの長さであり、ＭＦＵのメディアデータが属するムービーフラグ
メントのシーケンス番号を含む。sample_numberフィールド５０４は、３２ビットの長さ
であり、ＭＦＵのメディアデータについてのサンプルのサンプル番号を含む。offsetフィ
ールド５０６は、１６ビットの長さであり、基準サンプル（referenced sample）内に当
該ＭＦＵのメディアデータのオフセット（offset）を含む。subsample_priorityフィール
ド５０８は、８ビットの長さであり、同一のＭＰＵの他のメディアデータと比べて、当該
ＭＦＵにより運搬されるメディアデータの優先順位を提供する。例えば、subsample_prio
rityの値は、０と４５５との間にあってもよく、より高い優先順位を示すより高い値を有
してもよい。追加的に、dependency_counterフィールド５１０は、８ビットの長さであり
、当該ＭＦＵに含まれているメディアデータで、そのメディア処理に依存するデータユニ
ットの個数を示す。

図６は、本開示の多様な実施形態による非同期型ＭＦＵヘッダ６００についての例示的
な構造を示している図面である。非同期型ＭＦＵヘッダ６００は、非同期型メディアデー
タについての、図４のDU_header４１４に含まれているような伝送データユニットヘッダ
の一例である。

図６を参照すると、非同期型ＭＦＵヘッダ６００の各フィールドの前記セマンティック
ス及び長さは、以下のように提供される。item_IDフィールド６０２は、３２ビットの長
さであり、当該ＭＦＵの一部として運搬されるアイテムの識別子を含む。ファイルタイプ
（ＦＴ）０及び１について、追加的なＤＵヘッダが使われることができない。ＭＭＴＰヘ
ッダのオブジェクト識別子フィールドは、データユニットが抽出されるＭＰＵのMPU_sequ
ence_numberに設定されてもよい。ランダムアクセスポイント（random access point：Ｒ
ＡＰ）フラグは、ＦＴ値０及び１のデータユニットをマークするために設定されてもよく
、同期型メディアの場合において、同期サンプル又は当該フラグメントを含むＭＦＵ、及
び非同期型ＭＰＵの基本アイテムについて設定されてもよい。

図７は、本開示の多様な実施形態によるシグナリングメッセージヘッダ７００について
の例示的な構造を示している図面である。シグナリングメッセージヘッダ７００は、シグ
ナリングメッセージについての、図４のDU_header４１４に含まれているような伝送デー
タユニットヘッダの一例である。

図７を参照すると、シグナリングメッセージヘッダ７００の各フィールドのセマンティ
ックス及び長さは、以下のように提供される。message_idフィールド７０２は、１６ビッ
トの長さであり、シグナリングメッセージのタイプを示す。バージョンフィールドは、８
ビットの長さであり、シグナリングメッセージのバージョン番号を示す。予約（reserved
：ＲＥＳ）フィールドは、８ビットの長さであり、将来の使用のために予約され、０と設
定されてもよい。

ＭＭＴＰは、また一般ファイル及びアセットの伝送をサポートし、ペイロードタイプ１
を用いる。一般アセットは、論理的にグルップ化し、アプリケーション、例えば、ＤＡＳ
Ｈ（Segments of a Dynamic Adaptive Streaming over HTTP）リ提示、ＭＰＵのシーケン
スなどについて一部共通性を共有する一つ以上のファイルから構成される。

ＧＦＤペイロードタイプモードにおいて、一般アセットは、ＧＦＤペイロードタイプを
用いてＭＭＴＰを通じて伝送される。ＧＦＤは、以下で一般アセットコンテンツ及び伝送
特性を説明するために論議されるＧＦＤセッション記述（session description）を要求
する。本開示の実施形態は、ＭＭＴＰプロトコルを通じてＧＦＤセッションの成立を提供
する。ＭＭＴＰ内で伝送される場合、ＧＦＤセッションは、正確に１個のpacket_idフロ
ー（flow）上にマップされてもよい。

ＧＦＤセッション内で伝送される各ファイルは、トランスポート伝送情報の関連を要求
する。これは、転送長（transfer length）のような情報を含むが、これに限定されない
。ＧＦＤセッション内で伝送される各ファイルは、また前記ファイルの名称、識別子及び
/又は位置と、メディアタイプと、ファイルのサイズと、ファイルの符号化と、ファイル
のメッセージダイジェストのような関連のコンテンツ特定のパラメータを有してもよい。
ここで、参考までに含まれる、ＩＥＴＦ ＲＦＣ２６１６に規定されているようなＨＴＴ
Ｐ／１．１プロトコルに合わせて、一つの一般アセット内の各ファイルは、エンティティ
体（entity-body）、即ち、伝送されたファイルについてのメタ情報を割り当てられる。
ＧＦＤ動作の追加的な具体事項は、以下で説明する。ＧＦＤセッションに伝送されるファ
イルは、例えば、プロキシキャッシュ（proxy cache）を通じて、又は他の手段によりア
プリケーションに有用するようにされるべきである。その後、各オブジェクトは、前記Ｇ
ＦＤセッションを通じて伝送される。

受信器が、ＧＦＤセッションを成立できる前に、受信器は、例えば、セッションアクセ
ス情報と、ＧＦＤセッション情報のような、十分な情報を獲得する必要があり得る。ＧＦ
Ｄセッションについてのセッションアクセス情報は、ＭＭＴで動作する場合、ここで参考
までに含まれている２３００８−１に定められている。ＧＦＤセッション情報は、以下で
より具体的に説明する。ＧＦＤセッション記述は、ＲＦＣ４５６６に定義されているよう
なセッション記述プロトコル（Session Description Protocol：ＳＤＰ）、ＲＦＣ３０２
３に定義されているようなＸＭＬメタデータ、又はＲＦＣ２６１６に定義されているよう
なＨＴＴＰ／ＭＩＭＥヘッダなどのような形態で存在することができ、これらのＲＦＣ標
準ドキュメントは、ここで参考として明確に援用する。

ＧＦＤセッション情報：ＧＦＤプロトコルは、ファイルを伝送する。ＧＦＤモードにお
いて、各ファイルには、送信オブジェクト識別子（Transmission Object Identifier：Ｔ
ＯＩ）パラメータと、コードポイント（code point：ＣＰ）パラメータが割り当てられる
。ＴＯＩパラメータは、オブジェクトがＧＦＤセッションの範囲内で固有の識別子と関連
付けられることを提供する。各オブジェクトは、コードポイントと関連付けられる。コー
ドポイントは、特定のオブジェクト及びオブジェクト伝送特性を要約する。同一のＴＯＩ
を有するパケットは、前記コードポイントで同一の値を有してもよい。

ＧＦＤテーブルは、コードポイントのリストを提供する。各コードポイントには、コー
ドポイント値が動的に割り当てられる。前記ＧＦＤテーブルのセマンティックスは、下記
の表３に提供されている。

コードポイントは、当該コードポイントシグナリングと共に伝送されるオブジェクトの
最大の伝送長さを含んでもよい。また、コードポイントは、次のような情報、オブジェク
トの実際の伝送長さと、ここで参考に含まれるＲＦＣ２６１６の７．１節に定義されてい
るようなエンティティヘッダに存在してもよい情報と、存在する場合ＴＯＩ及びpacket_i
dパラメータを用いて以下で説明するようなコンテンツ−位置−テンプレート（content-l
ocation-template）と、 例えばコンテンツがどのようにパッケージ化されるかといった
コンテンツについての特定の情報などのうちのいずれかを含んでもよい。ＴＯＩ及びpack
et_idは、各ＴＯＩ及びpacket_idについてのコンテンツ-位置を生成するために用いられ
てもよい。上記のようなテンプレートが存在する場合、コンテンツ‐位置テンプレートに
ついて以下で説明するような処理を用いて、コンテンツ‐位置を生成してもよく、ＵＲＩ
の値は、エンティティ-ヘッダに含まれているコンテンツ‐位置フィールドとして取扱っ
てもよい。一つのセッション内で、多くて２５６個のコードポイントが定められてもよい
。コードポイントの定義は、ＧＦＤセッション記述において動的に設定されてもよい。コ
ードポイントについてのセマンティックスの一例が、下記の表４に提供されている。

コードポイントは、@contentLocationTemplate属性を含んでもよい。@contentLocation
Template属性の値は、下記の表５にリストされているような識別子のうちの一つ以上を含
んでもよい。各ＵＲＬにおいて、表５からの識別子は、表５に定義されているような交替
（substitution）パラメータに置換されてもよい。識別子マッチングは、大文字、小文字
の区別をする（case-sensitive）。ＵＲＬが、有効な識別子を含まないunescaped＄シン
ボルを含む場合、ＵＲＬ形成の結果は、定義されない。識別子のフォーマットは、下記の
表５に指定されている。

各識別子は、プロトタイプ（prototype）：「％０[width]ｄ」の後に「＄」文字内にサ
フィックスされ得る。「width」パラメータは、プリントされる文字の最小個数を提供す
る符合なし整数（unsigned integer）である。プリントされる値が、この数より小さい場
合、前記結果は、０とパディング（padding）される。前記結果がより大きくても、当該
値は、切捨て（truncate）できない。@contentLocationTemplateは、交替プロセスのアプ
リケーションが有効なＵＲＩを招くことができるように記述され得る。識別子の外部のス
トリング（string）は、ここで参考までに含まれる、ＲＦＣ３９８６によるＵＲＬ内で許
容される文字のみを含むことができる。

ＧＦＤオペレーション（GFD operation）：ＭＭＴＰのＧＦＤモードは、レギュラーフ
ァイル（regular file）を伝送する。レギュラーファイルを伝送する場合、オブジェクト
は、ファイルを示す。ＧＦＤセッション記述に定義されているコードポイントが、エンテ
ィティヘッダフィールドを、或いは生成できるエンティティヘッダフィールドを含む場合
、このようなエンティティヘッダフィールドは全て、前記伝送されたファイルに適用され
得る。

図８は、本開示の多様な実施形態によるＧＦＤモードパケット構造８００についての例
示的な構造を示している図面である。ＭＭＴＰを用いて送信されたペイロードパケット８
００は、図８に示しているように、ＧＦＤペイロードヘッダ８０２〜８１８と、ＧＦＤペ
イロード８２０とを含む。一部の特別な場合において、ＧＦＤ送信器は、何のペイロード
も含まないパケットを生成する必要があり得る。これは、例えば、セッションの終了（en
d）をシグナルするために要求され得る。ＧＦＤペイロードヘッダ８０２〜８１８は、可
変的なサイズを有する。ＧＦＤペイロードヘッダ８０２〜８１８において、全ての整数フ
ィールドは、「big-endian」或いは「network order」フォーマット、即ち、最上位バイ
ト（most significant byte）（オクテット）先の「big-endian」或いは「network order
」フォーマットで運搬する。「padding」或いは「reserved」（r）と指定されたビットは
、送信器により０と設定され、受信器により無視される。別途に説明しない限り、このよ
うな例における数値常数は、十進法の形態である（ベース１０）。

図８を参照すると、ＧＦＤモードパケット構造８００の各フィールドのセマンティック
ス及び長さは、以下のように提供される。長さフィールド８０２は、１６ビットを含み、
このフィールドを含む全体ペイロードのサイズを示す。Ｓフィールド８０４は、１ビット
の長さであり、ＴＯＩフィールドに含まれている全体３２ビットワード（word）の個数を
示す（ＴＯＩフィールドは、長さフィールド８０２において、３２＊Ｓ＋１６＊Ｈビット
であり、例えば、その長さは、０ビットであるか、１６ビットであるか、３２ビットであ
るか、又は４８ビットである）。Ｈフィールド８０６は、１ビットの長さであり、start_
offsetとＴＯＩフィールドとの集合の長さが、３２ビットの倍数であることを保証する間
、ＴＯＩフィールドの長さが、ハーフワード（１６ビット）の倍数となるように許容する
。Ｌフィールド８０８は、１ビットの長さであり、これが、このオブジェクトについて最
後の伝送パケットであるか否かの可否を示す。Ｂフィールド８１０は、１ビットの長さで
あり、このパケットが前記オブジェクトの最終バイトを含んでいるか否かの可否を示す。
コードポイント（ＣＰ）フィールド８１２は、８ビットの長さであり、パケットペイロー
ドに関する情報を伝送する前記パケットペイロードデコーダに伝送される不透明の識別子
（opaque identifier）を含む。コードポイントと、前記実際のコーデックとの間のマッ
ピングは、セッションベース別に定められ、前記セッション記述情報の一部として帯域外
（out-of-band）通信が行われる。オブジェクトメタデータ（Ｍ）フィールド８１４は、
１ビットの長さであり、このフラグは、前記オブジェクトメタデータが、ペイロードの一
部を提供したか否かを示す。1と設定される場合、ペイロードは、ＭＩＭＥエンティティ
であり、ここで、ヘッダは、少なくとも前記コンテンツタイプ及び前記コンテンツ位置ヘ
ッダを含んでもよい。予約されたフィールド（ＲＥＳ）は、３ビットの長さであり、０に
設定される。start_offsetフィールド８１８（16+32*O+16*H）は、オブジェクトに含まれ
ている現在のペイロードデータの位置を示す。ＧＦＤペイロードフィールド８２０は、Ｇ
ＦＤペイロードを含む。

オブジェクト識別子は、伝送中の一般オブジェクトの固有の識別子と設定され得る。オ
ブジェクト識別子と、オブジェクト情報（ＵＲＬ及びＭＩＭＥタイプのような）との間の
マッピングは、明示的に（explicitly）又は黙示的に（implicitly）行われてもよい。例
えば、ＤＡＳＨセグメントのシーケンスは、オブジェクト識別子として前記セグメントイ
ンデックスを使ってもよく、packet_idとして数表現識別子（numerical representation
identifier）を使ってもよい。また、このようなマッピングは、シグナリングメッセージ
を用いて行われてもよい。

ＧＦＤペイロード８２０につき、オブジェクトのバイトは、オブジェクトの伝送長さで
あるＴを用いて、バイト０が前記オブジェクトの開始であり、バイトＴ−１が、オブジェ
クトの最終バイトとなるように参照される。ＭＭＴＰパケットのペイロードにおいて運搬
されるデータは、バイトＸの開始から始まり、バイトＸ＋Ｙの開始で終了される前記オブ
ジェクトの連続的な部分から構成され、ここで、Ｘは、ＧＦＤパケットヘッダに含まれて
いるstart_offsetフィールドの値であり、Ｙはバイトで表現されるペイロードの長さであ
る。Ｙはパケットで運搬できないが、フレーミング（framing）は、下位トランスポート
プロトコルにより提供され得る。

ＭＭＴプロトコル（ＭＭＴＰ）は、ＭＭＴパッケージを効率よく、かつ信頼性よく伝送
するために設計されるアプリケーション階層トランスポートプロトコルである。ＭＭＴＰ
は、同期型及び非同期型メディアデータの両方の伝送のために用いることができる。ＭＭ
ＴＰは、多様なタイプのコード化されたメディアデータから構成されるコンテンツを伝送
するために必須的な、メディア多重化と、ネットワークジッター（network jitter）計算
のようないくつかの特徴をサポートする。ＭＭＴＰは、既存のプロトコル、例えば、ＵＤ
Ｐ（User Datagram Protocol）及びＩＰの上位（top）で実行されてもよい。本開示にお
いて、ＭＭＴペイロードフォーマット以外に、フォーマット化されたデータの特定の運搬
が要求される。単一ＭＭＴＰパケットは、正確に一つのＭＭＴペイロードを運搬し得る。
ＭＭＴＰは、送信エンティティが、輻輳制御（congestion control）を行うことを仮定し
、従って輻輳制御機能は、この詳細な説明に指定されない。これは、ＭＭＴＰがＵＤＰ／
ＩＰの上位で実行され、多様なアプリケーションにより用いられるために、この機能は、
送信エンティティの実現に負かされる。

ＭＭＴＰは、単一ＭＭＴパケットフローを通じて、異なるアセットの多重化をサポート
する。ＭＭＴＰは、大きな遅延を招くか、又は大きなバッファを必要とせず、異なるタイ
プのメディアデータ間の同期化を助けるように受信エンティティでの消費順序通り、多数
のタイプのデータを伝送する。また、ＭＭＴＰは、単一パケットフロー内のメディアデー
タと、シグナリングメッセージとの多重化をサポートする。単一ＭＭＴペイロードは、専
ら１個のＭＭＴパケットのみで運搬されてもよい。

ＭＭＴプロトコルは、２個のパケット化モード、ＧＦＤモード及びＭＰＵモードを定め
る。ＧＦＤモード（例えば、ダウンロードモード）は、伝送されるペイロードのサイズに
基づいて、メディアデータをパケット化するモードを定め、ＭＰＵモード（例えば、スト
リーミングモード）は、ペイロードで運搬されるデータのタイプに基づいてメディアデー
タをパケット化するモードを定める。ＭＭＴプロトコルは、単一伝送セッションにおいて
、２個の異なるモードを有するパケットの混合された使用をサポートする。ＭＭＴパケッ
トの単一パケットフローは、２個のタイプを有するペイロードから任意に構成されること
ができる。ＭＭＴＰは、データストリームについての常数遅延が成就できるように、下位
伝送ネットワークにより挿入されるジッターを、計算及び除去する構造及び定義を提供す
る。パケットヘッダに含まれているタイムスタンプフィールドを用いることにより、ジッ
ターは、何の追加的なシグナリング情報及びプロトコルを要求せず、正確に計算すること
ができる。

図９は、本開示の多様な実施形態によるＭＭＴＰパケット９００についての例示的な構
造を示している図面である。図９を参照すると、ＭＭＴＰパケット９００の各フィールド
のセマンティックス及び長さは、以下のように提供される。バージョン（Ｖ）フィールド
９０２は、２ビットの長さであり、前記プロトコルのバージョン番号を示す。このフィー
ルド９０２は、この明細書に応じて「００」と設定されてもよい。タイプフィールド（オ
ブジェクトタイプ）９０４は、６ビットである。このフィールド９０４は、ペイロードタ
イプ、即ち、モードを示す。一例において、ペイロードタイプ値の少なくとも一つは、下
記の表６に提供される。各ペイロードタイプの分割及び集合指示データユニットは、下記
の表６に提供されている。

ＭＭＴＰパケット９００の各フィールドのセマンティックス及び長さと連続して、FEC_
type（ＦＥＣ）フィールド９０６は、２ビットの長さであり、ＭＭＴパケットを保護する
ために用いられるＦＥＣ方式のタイプを示す。このフィールド９０６についての値及び関
連の記述の一例は、下記の表７にリストされている。

ＭＭＴＰパケット９００の各フィールドのセマンティックス及び長さと連続して、予約
（ＲＥＳ）フィールド９０８は、３ビットの長さであり、将来の使用のために予約されて
いる。packet_counter_flag（C）フィールド９１０は、１ビットの長さであり、「１」は
、packet_counterフィールドが存在することを示す。RAP_flag（Ｒ）フィールド９１２は
、１ビットの長さであり、「１」と設定される場合、ペイロードは、当該データタイプの
データストリームに対するランダムアクセスポイントを含むことを示す。extension_flag
（Ｘ）フィールド９１４は、１ビットの長さであり、「１」は、header_extensionフィー
ルドが存在することを示す。最終の（Ｌ）フィールド９１６は、１ビットの長さであり、
「１」は、object_identifierフィールドの値と同一の値を有するパケットの最終のパケ
ットを示す。packet_idフィールド９１８は、１６ビットの長さであり、他のアセットか
ら一つのアセットのパケットを区分するために、各アセットに割り当てられる整数値を含
む。別途の値が、シグナリングメッセージ及びＦＥＣリペアフローに割り当てられる。pa
cket_idは、伝送セッションの有効時間の間、同一のＭＭＴ送信エンティティにより伝送
される全てのＭＭＴフローについて固有である。packet_idとasset_idとの間のマッピン
グは、シグナリングメッセージの一部として、ＭＭＴパッケージ表によりシグナルされる
。ＡＬ−ＦＥＣ（Application Layer - Forward Error Correction）につき、packet_id
とＦＥＣリペアフローとの間のマッピングが、ＡＬ−ＦＥＣメッセージに提供される。pa
cket_idは、同一のＭＭＴ送信エンティティにより伝送される全てのＭＭＴパケットフロ
ーについて固有である。

ＭＭＴＰパケット９００の各フィールドのセマンティックス及び長さと連続して、obje
ct_identifierフィールド９２０は、３２ビットの長さであり、現在のペイロードから抽
出されるアプリケーション階層オブジェクトの識別子を含む。このフィールド９２０の正
確なセマンティックス及び使用は、ペイロードのタイプに依存し得る。packet_sequence_
numberフィールド９２２は、３２ビットの長さであり、packet_idによる範囲を有し、各
ＭＭＴパケットについて１ずつ増える任意の値から始る整数値を含む。この値は、最大値
に達した後、「０」に戻る。タイムスタンプフィールド９２４は、３２ビットの長さであ
り、ＭＭＴパケット伝送のタイムインスタンス（time instance）を指定する。ＮＴＰ時
間は、ここで参考までに含まれるＩＥＴＦ ＲＦＣ５９０５ ＮＴＰバージョン４の６節
の「short-format」のように指定されたタイムスタンプにおいて用いられる。このタイム
スタンプは、ＭＭＴパケットの第１ビットで前記時間を指定する。packet_counterフィー
ルド９２６は、３２ビットの長さであり、ＭＭＴパケットをカウントする整数値を含む。
この値は、ＭＭＴパケットの送信により増加され、packet_idと異なる。packet_counter
フィールド９２６は、送信される各ＭＭＴパケットについて１ずつ増える任意の値から開
始される。packet_counterフィールド９２６の値は、最大値の後、「０」に戻る。

extension_headerフィールド９２８は、ユーザ定義情報（user-defined information）
を含む。ヘッダ拡張メカニズム（header extension mechanism）は、ペイロードフォーマ
ットについての独自の拡張のために、ペイロードフォーマットヘッダで運搬される追加情
報を要求するアプリケーション及びメディアタイプを可能とする。ヘッダ拡張メカニズム
は、ＭＭＴペイロードの正確な処理に影響を及ぼさず、廃棄してもよい方式で設計される
。extension_headerフィールド９２８に含まれている拡張ヘッダは、図１０に示している
ようなフォーマットを含んでもよく、図１０は、本開示の多様な実施形態によるヘッダ拡
張１０００についての例示的な構造を示す。

ＭＭＴＰパケット９００の各フィールドのセマンティックス及び長さと連続して、ペイ
ロードデータフィールド９３０は、ペイロードデータを含み、ソースＦＥＣペイロードＩ
Ｄフィールド９３２は、２ビットの長さであり、ＦＥＣタイプの値が「１」と設定される
場合にのみ用いられてもよい。ＦＥＣtype＝１を有するＭＭＴパケットは、ＡＬ−ＦＥＣ
保護のために用いられてもよく、ＡＬ−ＦＥＣ保護の後に、このフィールドは、前記ＭＭ
Ｔパケットに追加されてもよい。

かかる実施形態において、本開示は、分割された伝送についてのＭＰＵの特定の部分の
指示を可能とする２個の階層と、ＭＭＴＰについて統一された構造を提供する。第１階層
において、ペイロードタイプ（例えば、ダウンロードモード、ストリーミングモード、Ｇ
ＰＵモード、ＭＰＵモード）は、前記ＭＭＴＰヘッダに含まれているタイプ（又はオブジ
ェクトタイプ）フィールドによりシグナルされる。第２階層において、伝送データユニッ
トタイプは、前記ＭＰＵモードペイロードヘッダに含まれているDU_typeフィールドによ
りシグナルされる。従って、本開示の実施形態は、ＭＭＴＰ内で前記ＧＰＵモードとＭＰ
Ｕモードとを統合することにより、同一のプロトコルにおいて、ダウンローディングとス
トリーミングとの両方をサポートする送信プロトコルを提供する。

図１１は、本開示の多様な実施形態による同期型メディアデータのパケット化の例示的
なダイアグラム１１００を示している図面である。同期型メディアを含むＭＰＵのパケッ
ト化は、ＭＰＵフォーマット認識及び／又はＭＰＵフォーマット不可知論（agnostic）モ
ードで行われてもよい。ＭＰＵフォーマット不可知論モードにおいて、ＭＰＵは、ＧＦＤ
を用いて前記下位伝送ネットワークのＭＴＵのサイズによって、同一のサイズ（サイズが
異なる最終のデータユニットは除く）又は予め定められたサイズのデータユニットにパケ
ット化される。即ち、ＭＰＵフォーマット不可知論モードのパケット化は、当該パケット
において運搬されるデータのサイズを考慮するのみである。ＭＭＴＰパケットヘッダにつ
いてのタイプフィールドは、パケット化が、フォーマット不可知論モードであることを示
すために０ｘ００と設定される。

ＭＰＵフォーマット認識モードにおいて、パケット化手続きは、ＭＰＵにおける異なる
タイプのデータの境界を考慮して、ＭＰＵモードを用いてパケットを生成する。生成され
たパケットは、ＭＰＵメタデータ、ムービーフラグメントメタデータ、又はＭＦＵの伝送
データユニットを運搬する。前記結果、生成されたパケットは、２個以上の異なるタイプ
の伝送データユニットを運搬できない。ＭＰＵメタデータの伝送データユニットには、DU
_type０ｘ０１が割り当てられる。ＭＰＵメタデータは、「ftyp」ボックスと、「mmpu」
ボックスと、「moov」ボックス及び全体ＭＰＵに適用される他のボックスを含む。「ftyp
」ボックスは、ファイルのタイプを含み、「mmpu」ボックスは、ＭＰＵの構成を含み、「
moov」ボックスは、コーデック構成情報を含む。ムービーフラグメントメタデータの伝送
データユニットは、「moof」ボックス及び「mdat」ボックスヘッダ（どのようなメディア
データも排除される）から構成され、ムービーフラグメントメタデータの伝送データユニ
ットには、DU_type０ｘ０２が割り当てられる。「mdat」ボックスは、メディアデータを
含み、メディアデータの情報を制御し、「moof」ボックスは、当該メディアデータのヘッ
ダ情報を含む。メディアデータ、ＭＰＵのmdatボックスのＭＦＵは、その後、フォーマッ
ト認識方式で、ＭＦＵの多数の伝送データユニットに分割される。例えば、これは、ＭＭ
Ｔヒントトラック（hint track）の援助により行われ得る。ＭＦＵは、１)メディアデー
タのみ、２）シーケンス番号を有するメディアデータと、３）一部制御情報を有するメデ
ィアデータとを含む。各ＭＦＵは、ＭＦＵヘッダの先に追加され、ＭＦＵヘッダは、前記
シンタックス及びセマンティックスを有する。ＭＦＵヘッダの次に、前記ＭＦＵのメディ
アデータが位置する。

図１２は、本開示の多様な実施形態による非同期型メディアデータのパケット化の例示
的なダイアグラム１２００を示している図面である。非同期型メディアデータのパケット
化は、また２個の異なるモードで行われてもよい。ＭＰＵフォーマット不可知論モードに
おいて、ＭＰＵは、ＧＦＤモードを用いて前記下位伝送ネットワークのＭＴＵのサイズに
よって、同一のサイズ（そのサイズが異なってもよい最終のデータユニットを除く）又は
予め定められたサイズの伝送データユニットにパケット化される。ＭＭＴＰパケットのタ
イプフィールドは、０ｘ００と設定されて、前記パケット化が、一般的であることを示す
。フォーマット不可知論モードにおいて、ＭＰＵは、ＭＰＵモードを用いてＭＰＵメタデ
ータ又はＭＦＵの伝送データユニットを含むパケットにパケット化される。ＭＰＵメタデ
ータは、前記「ftyp」ボックスと、前記「moov」ボックスと、前記「meta」ボックスと、
全体ＭＰＵに適用される他のボックスを含む。ＭＦＵの各伝送データユニットは、非同期
型メディアの単一アイテムを含む。そしてから、非同期型メディアの各アイテムは、ＭＦ
Ｕを生成するために用いられる。ＭＦＵは、ＭＦＵヘッダ及び非同期型ＭＦＵデータから
構成される。

逆パケット化手続きは、ＭＭＴ受信器で行われて、前記送信されたＭＰＵを獲得する。
逆パケット化手続きは、必要とされるアプリケーションに基づいて、次のようなモード、
ＭＰＵモードと、フラグメントモードと、メディアユニットモードとのうちの一つにおい
て動作することができる。ＭＰＵモードにおいて、逆ペイロード化器（depayloadizer）
は、ＭＰＵをアプリケーションにフォーワーディングする前に全体ＭＰＵを再生成する。
このモードは、時間が重要でない伝送（non-time critical delivery）について適切であ
り、即ち、ＣＩにより指示されるようなＭＰＵの提示時間は、ＭＰＵの伝送時間より十分
に後である。フラグメントモードにおいて、逆ペイロード化器は、フラグメントメタデー
タ及びメディアサンプルを有する「mdat」ボックスを含む完全なフラグメントを、アプリ
ケーションにフォーワーディングする前に再生成する。このモードは、非同期型メディア
に適用されない。このモードは、遅延時間費用（delivery time budget）が制限されてい
るが、完全なフラグメントを復元するには十分な遅延に敏感なアプリケーション（delay-
sensitive application）に適切である。メディアユニットモードにおいて、逆ペイロー
ド化器は、可能な限り速やかにメディアユニットを抽出して、前記アプリケーションにフ
ォーワーディングする。このモードは、非常に低い遅延メディアアプリケーションに適切
である。このモードにおいて、前記ＭＰＵの復元は、要求されない。フラグメントメディ
アデータの処理は、要求されないが、再同期化のために行われてもよい。このモードは、
メディアユニットが生成された後、生成してもよい前記フラグメントメタデータの順序か
ら外れた伝送を容認する。このモードは、同期型及び非同期型メディアの両方に対して適
用される。

ＭＦＵシーケンス番号を使って、受信器は、欠けているパケット（missing packet）を
検出し、ＦＥＣ又はＡＲＱのようなエラー訂正手続きを適用して、欠けているパケットを
復元することができる。ペイロードタイプは、送信器がアプリケーションについてのペイ
ロードの重要性を決定し、適切なエラー耐性測定値（error resilience measure）を適用
するために用いられてもよい。

各ＧＦＤ伝送セッションは、与えられたセッションについて局部的な（local）ＧＦＤ
Ｔを有してもよい。ＧＦＤセッション内において伝送されるが、ＧＦＤＴで説明されない
ファイルは、ＧＦＤ伝送セッションに属する「ファイル」と考慮されない。マッピングさ
れていないコードポイントと共に受信されるオブジェクトは、ＧＦＤ受信器により無視さ
れるべきである。

ＧＦＤセッションにおけるファイルは、例えば、ここで参考までに含まれる、ＩＳＯ／
ＩＥＣ２３００９−１に定義されているように、構成情報ドキュメント又はメディア提示
記述において、アプリケーションに提供されなければならず、ＧＦＤオブジェクトとして
、ＭＭＴＰを用いて伝送されるファイルを示してもよい。前記ファイルは、コンテンツ位
置から提供されるか、又は導き出される、ＧＦＤセッション記述のインバンド（in-band
）で又は一部として提供されるＵＲＩを通じて参照となり得る。特定の場合、前記ファイ
ルは、前記アプリケーションで有用性開始時間（availability start time）を有する。
この場合、ＧＦＤセッションは、前記ファイルを伝送して、オブジェクトの最終のパケッ
トが伝送されて、アプリケーションに知られているような有用性開始時間で、受信器にお
いて最も最近に有用であることができようにする。ＧＦＤモードを通じて伝送されるアプ
リケーションは、ＧＦＤセッション内でファイルを送信する時、追加的であり、より厳格
な要求事項を導入することができる。

セッション内で、送信器（例えば、送信エンティティ１０１）は、セッション内で一連
のパケットを送信する。いくつかのオブジェクトは、同一のＧＦＤセッション内で伝送し
てもよい。一つ以上のオブジェクトが、セッション内で伝送される場合、送信器は、ＴＯ
Ｉフィールドを用いてもよい。このようなシナリオにおいて、各オブジェクトは、セッシ
ョン内の固有のＴＯＩを用いて識別してもよく、送信器は、同一のオブジェクトに対して
存在する全てのパケットについて当該ＴＯＩを用いてもよい。セッションに運搬されるＴ
ＯＩとファイルとの間のマッピングは、エンティティモード伝送が適用される場合、エン
ティティヘッダフィールドにおいてのみならず、ＧＦＤセッション記述において説明され
る。

以上で説明したようなＧＦＤヘッダが用いられることができる。ＧＦＤパケットヘッダ
は、前記セッションについて成立される情報についての設定を、受信器に通信するために
用いられてもよく、セッションの間、変わってもよいコードポイントフィールドを含む。
設定とコードポイント値との間のマッピングは、ＧＦＤセッション記述において通信され
る。

例えば、Ｔ＞０が、バイト単位のオブジェクトの伝送長さの場合、パケットのペイロー
ドに運搬されるデータは、前記オブジェクトの連続した部分から構成される。その後、Ｘ
＋Ｙが最大Ｔである限り、任意のＸ及び任意のＹ＞０につき、パケットが生成されてもよ
い。このような条件下で、次のことが保持され得る。（Ａ）パケットのペイロードに運搬
されるデータは、バイトＸ＋Ｙの開始を通じて、バイトＸから始まる前記オブジェクトの
連続的な部分から構成される。（Ｂ）ＧＦＤパケットヘッダに含まれているstart_offset
フィールドは、Ｘと設定されても良く、ペイロードデータは、送信するパケットに追加さ
れてもよい。（Ｃ）Ｘ＋ＹがＴと同一である場合、パケットヘッダフラグＢは、１と設定
してもよく、Ｘ＋ＹがＴと同一でない場合、パケットヘッダフラグＢは、０と設定しても
よい。

次のような例示的な手続きは、送信器が、オブジェクトを伝送して、start_offset及び
該当するペイロードデータを含むパケットを生成するように用いられてもよい。まず、送
信器は、バイトオフセットカウンタＸを０と設定する。その後、伝送される次のパケット
は、ペイロードのバイト長さを固定値Ｙと設定する。ここで、Ｙは、ａ）パケットペイロ
ードに対して適切であり（例えば、全体パケットサイズが、前記ＭＴＵを超過しないこと
を保証し、ｂ）ＸとＹの合計が最大Ｔであり、ｃ)前記パケットに含まれているペイロー
ドデータに対して適切である。次に、送信器は、以上で説明したような規則ａ−ｃによっ
てパケットを生成する。その後、Ｘ＋ＹがＴと同一である場合、送信器は、パケットヘッ
ダフラグＢを１と設定し、Ｘ＋ＹがＴと同一でない場合、送信器は、パケットヘッダフラ
グＢを０と設定し、Ｘ＝Ｘ＋Ｙに増やし、規則ａ−ｃによってパケットを生成するよう戻
る。

パケット伝送の順序は、任意的であってもよいが、送信器は、増加するstart_offset番
号を有する他の制約伝送（constraints delivery）が存在していない場合、伝送を行って
もよい。伝送長さは、データの以前のピース（piece）を送信する前に知られることはで
きない。この状況で、Ｔは、以後に決定されてもよい。しかし、以上で説明したような送
信プロセスに影響を及ぼさない。追加的なパケットが、以上で説明したような（Ａ）−（
Ｃ）形態の規則に従い送信できる。この場合、前記Ｂフラグは、オブジェクトの最終の部
分を含むパケットについてのみ設定してもよい。

ＧＦＤセッション記述は、異なるコードポイント値により識別される一つ以上の多数の
コードポイントを含む。各パケットを受信する場合、受信器（例えば、一つ以上の受信エ
ンティティ１１０〜１１６）は、次のようなステップを進行してもよい。第１に、受信器
は、パケットヘッダを分析し、パケットヘッダが有効なヘッダであるかを確認する。パケ
ットヘッダが、有効でない場合、パケットは、さらに処理せず、廃棄してもよい。第２に
、受信器は、コードポイント値を分析し、ＧＦＤセッション記述がマッチングコードポイ
ントを含んでいるかを確認する。それが有効でない場合、パケットは、さらに処理せず、
廃棄してもよい。第３に、受信器は、パケットの残りの部分を処理し、パケットの残りの
部分の処理は、他のヘッダフィールドを適切に解釈し、source_offset及びペイロードデ
ータを用いて、次のように、当該オブジェクトを再構成することを含む。ａ）受信器は、
セッション情報と、存在する場合、ペイロードヘッダに運搬されるＴＯＩにより、受信さ
れたパケットが、どのようなオブジェクトから生成されたかを決定することができる。ｂ
）オブジェクトについての第１パケットが受信される場合、受信器は、オブジェクト送信
情報の一部として受信される最大伝送長さを用いて、オブジェクトの最大長さＴ´を決定
する。ｃ）受信器は、オブジェクトが要求できるＴ´バイトについての空間を割当る。ｄ
）受信器は、受信されたパケットの全体長さから、パケットヘッダの長さを減算してペイ
ロードの長さＹを演算する。ｅ）受信器は、受信されたオブジェクトシンボルを追跡（tr
ack）ために、偽（false）と初期化される全てのＴエントリー（entry）を有するBoolean
array RECEIVED[0..T'-1]を割り当てる。受信器は、いまだに偽（false）と設定されて
いる RECEIVEDに少なくとも一つのエントリーが存在する限り、又は前記アプリケーショ
ンが、このオブジェクトを放棄することと決定するまで、前記オブジェクトブロック（ob
ject block）についてパケットを持続的に受信する。ｆ）オブジェクト（前記第１パケッ
トを含む）に対して受信された各パケットについて、オブジェクトを復元することを助け
るために取られるステップは、以下の通りである。ｉ）ＸがパケットのＧＦＤパケットヘ
ッダに含まれているsource_offsetフィールドの値であり、受信されたパケットの全体長
さから、パケットヘッダ長さを減算することにより、計算された、Ｙがペイロードの長さ
であるとする。ｉｉ）受信器は、オブジェクトについて予約された空間内で適切な場所に
データを複写し、RECEIVED[X …X+Y-1] = trueと設定する。ｉｉｉ）全てのＴentries of
RECEIVEDが、真（true）である場合、受信器は、全体オブジェクトを復元する。ｇ）受
信器が、１と設定された前記Ｂフラグを受信すると、受信器は、オブジェクトの伝送長さ
Ｔを該当するパケットのＸ＋Ｙであると決定し、Boolean array RECEIVED[0..T'-1]を、R
ECEIVED[0..T-1]と調整することができる。

ＧＦＤコードポイント：ＧＦＤモードを用いて伝送されるファイルについての情報は、
asset_scheme_codeが、「GeneralFile」と設定される場合、ＭＰテーブルに指示される。
ＧＦＤモードを用いて伝送される一般オブジェクトは、packet_idにより識別されるＭＭ
ＴＰフローと共にグループ化されてもよい。ＧＦＤモードを用いて一般オブジェクトを運
搬するパケットは、ＭＭＴＰパケットヘッダタイプフィールドでタイプ１とマークされ得
る。ＧＦＤ表は、一つ又は多数のコードポイントを定める。コードポイント表は、下記の
表８に提供されている。

ここで説明する多様な実施形態は、ＭＭＴデータ通信について論議するが、本開示の多
様な実施形態は、ＭＭＴ通信のみに制限されることではないことに留意すべきである。例
えば、固定された遅延決定及びバッファサイズ決定は、本開示の原則に従い、適切なタイ
プのデータ、又はメディアコンテンツ伝送及び/又は適切なタイプの送信システムに適用
することができる。

図１３は、本開示の一実施形態による受信エンティティでトランスポートパケットを処
理するプロセスを示している図面である。例えば、図１３に示しているようなプロセスは
、図１の前記受信エンティティ１１０〜１１６の一部又は全てにより行われてもよい。ま
た、前記プロセスは、図１５の電子デバイス１５００により実現できる。

図１３を参照すると、前記プロセスは、受信エンティティが、トランスポートパケット
を受信することから始まる（ステップ１３０５）。そして、受信エンティティは、パケッ
トヘッダに含まれているペイロードタイプを示すフィールドからペイロードタイプを識別
する（ステップ１３１０）。例えば、ステップ１３１０において、受信エンティティは、
パケットヘッダを分析して、図９のフィールド９０４のような、オブジェクトタイプフィ
ールドに含まれている値を識別して、表６により該当するペイロードタイプを識別するこ
とができる。ペイロードタイプが一般モードの場合、受信エンティティは、一般モードペ
イロードデータを処理する（ステップ１３１５）。

ペイロードタイプが、ストリーミングモードの場合、受信エンティティは、ストリーミ
ングモードペイロードヘッダに含まれている伝送データユニットタイプを示すフィールド
から伝送データユニットタイプを識別する（ステップ１３２０）。例えば、ステップ１３
２０において、受信エンティティは、ＭＭＴペイロードに含まれているデータのタイプの
ようなトランスポートパケットに含まれているＤＵデータの伝送データユニットタイプを
識別することができる。

例えば、受信エンティティは、図４に示しているような、ストリーミングモードペイロ
ードヘッダを分析して、DU_typeフィールド４０４に含まれている値を識別して、表１に
よって前記伝送データユニットタイプを識別することができる。例えば、ＤＵデータは、
ＤＵタイプフィールドに含まれている値に基づいて、完全なＭＰＵ、ＭＰＵメタデータ、
ムービーフラグメントメタデータ、同期型ＭＦＵ、非同期型ＭＦＵ、シグナリングメッセ
ージ、又は復元シンボルのうちの一つを含んでもよい。

従って、受信エンティティは、ストリーミングモードペイロードヘッダに含まれている
分割指示子フィールドからトランスポートパケットに（複数の）ＭＦＵが存在するか否か
の可否についての情報を識別する（ステップ１３２５）。例えば、ステップ１３２５にお
いて、トランスポートパケットは、ＭＦＵとして配列されたＭＰＵの一つ以上のフラグメ
ントを含む。トランスポートパケットは、多数の伝送データユニットを含んでもよく、各
伝送データユニットは、ＤＵヘッダと、ＤＵデータとを含む。受信エンティティは、表２
による分割指示子フィールドに含まれている値に基づいて、ＤＵデータが、一つ以上の伝
送データユニットヘッダ及び完全の伝送データユニットと、伝送データユニットヘッダ及
び伝送データユニットの第１フラグメントと、第１部分でもなく、最終の部分でもない前
記伝送データユニットのフラグメント、又は前記伝送データユニットの最終のフラグメン
トを含むか否かの可否を決定することができる。

その後、受信エンティティは、ＤＵデータを処理する（ステップ１３３０）。例えば、
ステップ１３３０において、受信エンティティは、前記識別された伝送データユニットタ
イプによって、ＤＵデータを処理することができる。受信エンティティは、ＤＵデータを
処理及び復号化して、受信エンティティと関連付けられるユーザについてのユーザインタ
ーフェース（user interface）を通じて、メディアをディスプレイする。

図１４は、本開示の一実施形態による送信エンティティにおいて、トランスポートパケ
ットを生成するプロセスを示している図面である。例えば、図１４に示しているようなプ
ロセスは、図１の送信エンティティ１０１により行われてもよい。また、前記プロセスは
、図１５の電子デバイス１５００により実現できる。

図１４を参照すると、前記プロセスは、送信エンティティが、トランスポートパケット
を生成することから始まる（ステップ１４０５）。例えば、ステップ１４０５において、
送信エンティティは、ダウンローディング又はストリーミングデータを含むパケットを生
成することができる。送信エンティティは、多数の伝送データユニットを含んでもよく、
各伝送データユニットは、ＤＵヘッダと、ＤＵデータとを含む。

次に、送信エンティティは、トランスポートパケットについてのパケットヘッダに含ま
れているペイロードタイプを示すフィールドに、ペイロードタイプの識別子を含ませる（
ステップ１４１０）。例えば、ステップ１４１０において、送信エンティティは、表６で
のように、オブジェクトタイプに該当する値を、図９のフィールド９０４でのように、パ
ケットヘッダのタイプフィールドに含ませてもよい。

その後、送信エンティティは、ペイロードタイプが、ストリーミングモードペイロード
タイプであるか否かの可否を決定する（ステップ１４１５）。ペイロードタイプが、スト
リーミングモード以外のタイプである場合、例えば、一般（ＧＦＤ）モードの場合、送信
エンティティは、ペイロード時間によってトランスポートパケットを生成し、ステップ１
４３０へ進んで、前記生成されたトランスポートパケットを送信する。

しかし、ペイロードタイプが、ストリーミングモードペイロードタイプである場合、送
信エンティティは、ストリーミングモードペイロードヘッダに含まれている伝送データユ
ニットタイプを示すフィールドに、伝送データユニットタイプの識別子を含ませる（ステ
ップ１４２０）。例えば、ステップ１４２０において、送信エンティティは、パケットに
ついての伝送データユニットタイプによる値を、表１の伝送データユニットタイプによる
図４のストリーミングモードペイロードヘッダのDU_typeフィールド４０４により示され
ているような、ストリーミングモードペイロードヘッダに含まれているフィールドに含ま
せることができる。例えば、ＤＵタイプフィールドは、前記含まれている値に基づいて、
完全のＭＰＵ、ＭＰＵメタデータ、ムービーフラグメントメタデータ、同期型ＭＦＵ、非
同期型ＭＦＵ、シグナリングメッセージ又は復元シンボルのうちの一つを含むことを示す
ことができる。

従って、送信エンティティは、（複数の）ＭＦＵが、パケットに存在するか否かの可否
についての情報の識別子を、前記ストリーミングモードペイロードヘッダに含まれている
分割指示子フィールドに含ませる（ステップ１４２５）。例えば、ステップ１４２５にお
いて、トランスポートパケットは、ＭＦＵとして配列されたＭＰＵの一つ以上のフラグメ
ントを含む。送信エンティティは、表２による分割指示子フィールドに含まれている値に
基づいて、ＤＵデータが、一つ以上の伝送データユニットヘッダ及び完全の伝送データユ
ニットと、伝送データユニットヘッダ及び伝送データユニットの第１フラグメントと、第
１部分でもなく、最終の部分でもない伝送データユニットのフラグメント、又は伝送デー
タユニットの最終のフラグメントを含むことを示すことができる。

その後、送信エンティティは、前記生成されたトランスポートパケットを送信する（ス
テップ１４３０）。例えば、ステップ１４３０において、送信エンティティは、例えば、
図１３に示されているようなプロセスに応じて、トランスポートパケットを、受信及び処
理する受信エンティティに、前記トランスポートパケットを送信することができる。

図１３及び図１４が各々、送信エンティティ及び受信エンティティによるトランスポー
トパケットの処理及び生成についてのプロセスの一例を示していたとしても、多様な変形
が、図１３及び図１４についてなされることができることは、当然である。例えば、連続
的なステップが示されているが、各図面の多様なステップは、オーバーラップ（overlap
）されてもよく、並列に生じてもよく、異なる順序で生じてもよく、又は数回生じてもよ
いことは、当然である。

図１５は、本開示の多様な実施形態が実現することができる例の電子デバイス１５００
を示している図面である。図１５を参照すると、電子デバイス１５００は、制御部１５０
４と、メモリ１５０６と、永久格納部１５０８と、通信部１５１０と、入力／出力部 （Ｉ／Ｏ）１５１２と、ディスプレイ１５１４とを含む。この実施例において、電子デバイス１５００は、また図１の送信エンティティ１０１及び／又は受信エンティティ１１０との一例である。

制御部１５０４は、少なくとも一つの動作を制御するデバイス、システム、又はその一
部であり、前記デバイスは、ハードウェア、ファームウェア（firmware）又はソフトウェ
ア、又は前記ハードウェア、ファームウェア又はソフトウェアのうちの少なくとも二つの
組み合わせで実現することができる。例えば、制御部１５０４は、電子デバイス１５００
の動作を制御する、ハードウェアプロセッシングユニットと、プロセッシング回路と、メ
ディアコーディング及び/或いはデコーディングハードウェア及び／又はソフトウェア、
及／又はソフトウェアプログラムを含んでもよい。例えば、制御部１５０４は、メモリ１
５０６にローディングすることができるソフトウェアに対する命令語（instruction）を
処理する。制御部１５０４は、特定の実現に基づいて、多数のプロセッサーと、マルチプ
ロセッサーコア、又は一部他のタイプのプロセッサーを含んでもよい。また、制御部１５
０４は、メインプロセッサーが、単一チップにおいて、補助プロセッサーと共に存在する
、多数の異種プロセッサーシステムを用いて実現することができる。他の実施例において
、制御部１５０４は、同一のタイプの多数のプロセッサーを含む対称型多重プロセッサー
（symmetric multi-processor）システムを含んでもよい。

メモリ１５０６及び永久格納部１５０８は、格納デバイス１５１６の例である。格納デ
バイスは、臨時基盤及び／又は永久基盤で、情報、例えば、データと、機能的形態のプロ
グラムコード、及び／又は他の適切な情報のような、これに限定されない情報を格納する
ことができるハードウェアの一部である。このような例において、メモリ１５０６は、例
えば、ランダムアクセスメモリ又は他の適切な揮発性又は非揮発性格納デバイスとなり得
る。例えば、永久格納部１５０８は、一つ以上のコンポナント又はデバイスを含んでもよ
い。永久格納部１５０８は、ハードドライブ、フラッシュメモリ（flash memory）、光デ
ィスク、又は前記ハードドライブ、フラッシュメモリ、光ディスクの一部の組合せとなっ
てもよい。永久格納部１５０８により用いられるメディアは、除去可能である。例えば、
除去可能なハードドライブは、永久格納部１５０８のために用いられてもよい。

通信部１５１０は、他のデータ処理システム又はデバイスとの通信に提供する。このよ
うな例において、通信部１５１０は、無線（cellular、WiFiなど）送信器、受信器、及び
／又は送受信器、ネットワークインターフェースカード（network interface card）、及
び／又は物理又は無線通信媒体を通じて、通信を送信及び／又は受信する他の適切なハー
ドウェアを含んでもよい。通信ユニット１５１０は、物理通信リンク及び無線通信リンク
のうちの一つ又は全ての使用を通じて通信を提供することができる。

入力／出力部１５１２は、前記電子デバイス１５００又は前記電子デバイス１５００の
一部に連結できる他のデバイスとのデータ入力及び出力を許容する。例えば、入力／出力
部１５１２は、タッチユーザ入力を受信するタッチパネル、オーディオ入力を受信するマ
イクロフォン、オーディオ出力を提供するスピカ、及び／又は触覚出力（haptic output
）を提供するモータを含んでもよい。入力／出力部１５１２は、前記電子デバイス１５０
０のユーザに、メディアデータ（例えば、オーディオデータ）を提供及び伝送するユーザ
インターフェースの一例である。他の例において、入力／出力部１５１２は、キーボード
、マウス、外部スピカ、外部マイクロフォーン、及び／又は他の適切な入力／出力デバイ
スを通じて、ユーザ入力についての連結を提供することができる。また、入力／出力部１
５１２は、プリンターに出力を送信することができる。ディスプレイ１５１４は、ユーザ
に情報をディスプレイするメカニズムを提供し、電子デバイス１５００のユーザに、メデ
ィアデータ（例えば、イメージ及び／又はビデオデータ）を提供及び伝送するユーザイン
ターフェースの一例である。

動作システム、アプリケーション、又は他のプログラムについてのプログラムコードは
、格納デバイス１５１６に位置することができ、格納デバイス１５１６は、バスシステム
１５０２を通じて、制御部１５０４と通信している。一部の実施形態において、プログラ
ムコードは、永久格納部１５０８において機能的形態で存在する。このような命令語は、
制御部１５０４による処理のために、メモリ１５０６にローディングすることができる。
異なる実施形態のプロセスは、コンピュータ実施命令語（computer-implemented instruc
tion）を用いて、制御部１５０４により行われてもよく、前記コンピュータ‐実現命令語
は、メモリ１５０６に位置してもよい。例えば、制御部１５０４は、以上で説明したよう
なモジュール及び／又はデバイスのうちの一つについてのプロセスを行ってもよい。

一部の実施形態において、以上で説明したような多様な機能は、コンピュータ読取り可
能なプログラムコードから形成され、コンピュータ読取り可能な媒体で実施されるコンピ
ュータプログラム製品により実現又は支援される。前記コンピュータプログラム製品につ
いてのプログラムコードは、選択的に削除可能なコンピュータ読取り可能な格納デバイス
において機能的形態で位置することができ、制御部１５０４による処理のために、電子デ
バイス１５００にローディング又は伝送することができる。一部の実施形態において、前
記プログラムコードは、電子デバイス１５００内での使用のために、他のデバイス又はデ
ータ処理システムから、ネットワークを通じて永久格納デバイス１５０８にダウンロード
することができる。例えば、サーバデータ処理ステムに含まれているコンピュータ読取り
可能な格納媒体に格納されているプログラムコードは、ネットワークを通じて前記サーバ
から電子デバイス１５００にダウンロードできる。プログラムコードを提供する前記デー
タ処理システムは、サーバコンピュータ、クライアントコンピュータ、又はプログラムコ
ードを格納及び送信できる一部の他のデバイスとなってもよい。

一方、本開示は、実施形態について説明したが、多様な変形及び修正が可能であること
は、当該技術分野における当業者には明らかである。本開示は、添付の特許請求の範囲内
で、上記のような変形及び修正を含むことができる。

１５０４ 制御部
１５０６ メモリ
１５０８ 永久格納部
１５１０ 通信部
１５１２ 入力／出力部
１５１４ ディスプレイ
１５１６ 格納デバイス

Claims (2)

1. メディアコンテンツ送信装置であって、
   前記メディアコンテンツのメディアデータを少なくとも一つのサブデータユニットを含む少なくとも一つ以上のデータユニットで構成するプロセッサと、
   パケットヘッダと前記データユニットに基づいて生成されたデータを含むペイロードで構成されたトランスポートパケットを送信する送信器とを含み、
   前記パケットヘッダは、複数のペイロードタイプのうち前記ペイロード内に含まれる前記データのタイプを表す情報を含み、
   前記複数のペイロードタイプは、
   メディア認識方式(media-aware manner)で前記データユニットを分割することにより生成されたデータが、前記ペイロードに含まれることを知らせる第１ペイロードタイプと、
   シグナリングメッセージが、前記ペイロードに含まれることを知らせる第２ペイロードタイプと、
   を含む、装置。
2. 前記トランスポートパケットは、少なくとも一つのサブデータユニットを含む、請求項１に記載の装置。

Images