特許 6346329 ダウンローディング及びストリーミングをサポートするパケットの伝送装置及び受信装置

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

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

(11)【特許番号】6346329

(24)【登録日】2018年6月1日

(45)【発行日】2018年6月20日

(54)【発明の名称】ダウンローディング及びストリーミングをサポートするパケットの伝送装置及び受信装置

(51)【国際特許分類】

   H04L 12/951 20130101AFI20180611BHJP

【ＦＩ】

   H04L12/951

【請求項の数】2

【全頁数】30

(21)【出願番号】特願2017-42254(P2017-42254)

(22)【出願日】2017年3月6日

(62)【分割の表示】特願2016-20212(P2016-20212)の分割

【原出願日】2014年7月25日

(65)【公開番号】特開2017-108458(P2017-108458A)

(43)【公開日】2017年6月15日

【審査請求日】2017年3月27日

(31)【優先権主張番号】61/859,015

(32)【優先日】2013年7月26日

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

(31)【優先権主張番号】61/896,570

(32)【優先日】2013年10月28日

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

(31)【優先権主張番号】14/178,212

(32)【優先日】2014年2月11日

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

(73)【特許権者】

【識別番号】503447036

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

(74)【代理人】

【識別番号】100121382

【弁理士】

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

(72)【発明者】

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

(72)【発明者】

【氏名】イメド・ブアジジ

【審査官】 宮島 郁美

(56)【参考文献】

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

【文献】 特開２００２−２８１４５６（ＪＰ，Ａ）

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

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

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

Ｈ０４Ｌ１２／００−１２／２６，１２／５０−１２／９５５

Ｈ０４Ｎ７／１０−７／５６，１９／００−２１／８５８

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

【請求項1】

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

【請求項2】

前記トランスポートパケットは、少なくとも一つのサブデータユニットを含む、請求項１に記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【0003】

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

【発明の概要】

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

【0004】

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

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

【0005】

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

【0006】

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

【0007】

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

【0008】

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

【0009】

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

【図面の簡単な説明】

【0010】

【図1】本開示の多様な実施形態が実現できる送信システムの一例を示している図面である。

【図2】本開示の多様な実施形態によるＭＭＴパッケージと、該ＭＭＴパッケージの論理構造とを示している図面である。

【図3】本開示の実施形態による異なるアセットからＭＰＵの提示のための提示情報ドキュメント（presentation information document）により提供されるタイミングの一例を示している図面である。

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

【図5】本開示の多様な実施形態による同期型（timed）メディアフラグメントユニット（ＭＦＵ）ヘッダについての例示的な構造を示している図面である。

【図6】本開示の多様な実施形態による非同期型（non-timed）ＭＦＵヘッダについての例示的な構造を示している図面である。

【図7】本開示の多様な実施形態によるシグナリングメッセージヘッダについての例示的な構造を示している図面である。

【図8】本開示の多様な実施形態によるＧＦＤモードパケット構造についての例示的な構造を示している図面である。

【図9】本開示の多様な実施形態によるＭＭＴパケットについての例示的な構造を示している図面である。

【図10】本開示の多様な実施形態によるヘッダ拡張についての例示的な構造を示している図面である。

【図11】本開示の多様な実施形態による同期型メディアデータのパケット化の例示的なダイアグラムを示している図面である。

【図12】本開示の多様な実施形態による非同期型メディアデータのパケット化の例示的なダイアグラムを示している図面である。

【図13】本開示の多様な実施形態による受信エンティティにおけるトランスポートパケットを処理するプロセスを示している図面である。

【図14】本開示の多様な実施形態による送信エンティティにおけるトランスポートパケットを生成するプロセスを示している図面である。

【図15】本開示の多様な実施形態が実現できる電子デバイスの例を示している図面である。

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

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

【表1】

【0040】

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

【0041】

【表2】

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

【表3】

【0057】

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

【0058】

【表4】

【0059】

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

【0060】

【表5】

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

【表6】

【0072】

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

【0073】

【表7】

【0074】

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

【0075】

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

【0076】

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

【0077】

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

【0078】

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

【0079】

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

【0080】

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

【0081】

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

【0082】

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

【0083】

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

【0084】

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

【0085】

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

【0086】

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

【0087】

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

【0088】

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

【0089】

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

【0090】

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

【0091】

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

【0092】

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

【0093】

【表8】

【0094】

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

【0095】

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

【0096】

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

【0097】

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

【0098】

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

【0099】

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

【0100】

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

【0101】

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

【0102】

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

【0103】

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

【0104】

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

【0105】

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

【0106】

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

【0107】

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

【0108】

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

【0109】

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

【0110】

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

【0111】

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

【0112】

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

【0113】

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

【0114】

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

【0115】

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

【0116】

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

【符号の説明】

【0117】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】