JP5535498B2 - 送信装置及び伝送方法 - Google Patents

Description

本発明は、インターネット・プロトコル（ＩＰ）ネットワークでデータを伝送するデータ・トランスポート・コンテナに関する。データ・トランスポート・コンテナは、少なくとも２つの異なる種類のデータを、ギガビット・イーサネット（登録商標）（登録商標）のＲＴＰ−ＵＤＰ−ＩＰ巨大パケットとして、同時に伝送することに特に関与する。例えば、２種類のデータは、加入者局のネットワークで送信される単一の送信元により生成される。

さらに、本発明は、それぞれデータ・トランスポート・コンテナを送信する送信元装置及び受信する宛先装置に関する。

少なくとも、本発明は、ギガビット・イーサネット（登録商標）のＲＴＰ―ＵＤＰ−ＩＰ巨大パケットとして生成された異なる種類のデータを伝送する方法に関する。上述の装置の両方は、上述の方法で用いられる。

本章では読者に、以下に記載され及び／又は請求される本発明の種々の態様に関連し得る技術の種々の態様を紹介する。この記載は読者に背景情報を提供し、本発明の種々の態様を一層理解するために有用であろう。したがって、理解されるべき点は、これらの記述がこの観点から読まれるべきであり、従来技術の承認ではないことである。

ギガビット・イーサネット（登録商標）（ＧｉｇＥ）は、ネットワークの進化の新たな段階として急速に有名になり、受け入れられている。比較的低価格、高速、且つ今日の事実上の業界標準である１００Ｍｂｐｓ高速イーサネット（登録商標）と相互運用可能であるのは、一握りのＧｉｇＥだけである。多くのネットワークの立案者がＧｉｇＥを採用するのは時間の問題である。

ギガビット・イーサネット（登録商標）は１０／１００Ｍｂｐｓと相互運用可能であるが、熟慮を要するある重要な相違点がある。最も重要な相違点の１つは、最大伝送ユニット又はＭＴＵのいかなる標準規格も存在しないことである。１０及び１００Ｍｂｐｓネットワークの標準化された１５００バイトのＭＴＵは、全く標準化されていないものに置き換えられてしまう。ギガビット・イーサネット（登録商標）のパケットは、ネットワーク・ベンダーの対応するいかなるサイズであってもよく、１５００バイトから１６０００バイト以上まで変化する。ベンダーは、標準的に対応する最大フレーム・サイズを約９０００バイト程度に制限する構成機器製造業者により制約を受けている。

所謂、巨大パケットの利益は顕著であり、巨大パケットは、１５００バイトより小さいパケットを用いる場合に比べ、今日のネットワークでアクセス可能帯域幅を２倍以上にする。しかしながら、幾つかの難点が隠されている。標準ＭＴＵが存在しないので、ＭＴＵは１００Ｍｂｐｓからギガビットへの移行の障害になる。例えば、ブラック・ホールのような種々の形式のＭＴＵ衝突は、ネットワークの性能を壊滅的に低下させてしまう。

特大のパケットを末端ホストへ送信し、中間インターフェースから戻ってくるメッセージを受信することにより、送信側ホストは、特定の末端ホストへの経路ＭＴＵを発見でき、それに応じて自身のトラフィック・パターンを調整できる。適切に設定されていない場合、又はメッセージがレイヤー３インターフェースで無差別に遮断される場合、必要なメッセージは送信元インターフェースへの経路を見付けることができない。これらの装置は、ブラック・ホールと称される。

用語「巨大」は、通常、１０／１００Ｍｂｐｓイーサネット（登録商標）規格よりも大きないかなるネットワーク・ユニット（フレーム、パケット、ＭＴＵ）にも用いられる。１０／１００Ｍｂｐｓイーサネット（登録商標）規格のレイヤー３（パケット及びＭＴＵ）では、標準サイズは１５００バイトである。巨大パケットは、１００ＭｂｐｓとＧｉｇＥとの間の明らかな相違点の１つである。

しかしながら、ギガビット・イーサネット（登録商標）規格は規定された最大伝送ユニット（ＭＴＵ）を有しないという問題が浮上する。ＭＴＵは、レイヤー３のパラメータであり、このパラメータはネットワークで許可される最大パケット・サイズを制御する。１０及び１００Ｍｂｐｓイーサネット（登録商標）では、規格（ＲＦＣ８９４、８９５）は、最大のＭＴＵを１５００バイトに明示的に規定し、殆ど全てのイーサネット（登録商標）・インターフェース・カードが当該規格に従っている。

しかし、現在の実装では、ＧｉｇＥのデータ伝送性能は、ＭＴＵに大きく依存する。最近の研究は、巨大パケットにより、殆どのホストが、１５００バイトより小さいパケットの場合よりも遙かに高い伝送レートでデータを送信できることを示している。この状況では、異なる送信元により生成された巨大パケットをＲＴＰパケットに多重する必要がある。

従来、ヘッダーのオーバーヘッドを縮小するため、又は複数ユーザーのデータを単一のＲＴＰセッションで伝送する目的で複数のユーザー・データを単一のＲＴＰパケットに包含させるために、複数のパケットを単一のＲＴＰパケットに纏めることが良く知られている。しかし、これらの既存のＲＴＰ多重化方法は、全て標準のパケットのＲＴＰアプリケーションに基づく。これらの方法は、ビデオ・データ、音声データ、又はメタデータのような異なる種類のデータがイーサネット（登録商標）の巨大パケットで伝送される場合に使用することができない。

例えばＨｉＰｅｒＮｅｔカメラのような最近の用途は、ＤＰＸ形式のビデオ、ビデオ・コンテンツとの時間的関係を維持しているＡＩＦＦ音声信号、ＡＩＦＦ音声としても提供され、ビデオ・コンテンツとの時間的関係のないインターコム音声、及び少なくともメタデータのような異なる種類のデータを有する種々の出力ストリームを生成する。これら全ての出力ストリームは、イーサネット（登録商標）のＩＰ−ＵＤＰ−ＲＴＰ巨大パケットとして生成される。

本発明の目的の１つは、高速ＩＰネットワークでイーサネット（登録商標）のＩＰ−ＵＤＰ−ＲＴＰ巨大パケットとして生成された、異なる種類に属するこれらのデータを同時に送信することである。

開示される実施例の範囲と対応する特定の態様を以下に説明する。理解されるべき点は、これらの態様が単に読者に、本発明が取り得る特定の形式の概要を提供するために提示されること、及びこれらの態様が本発明の範囲を制限しないことである。実際に、本発明は以下に記載されない種々の態様を包含し得る。

本発明が解決する技術的課題は、高速ＩＰネットワークで生成された巨大パケットとして生成された異なる種類のデータを同時に送信することである。

したがって、本発明は、第１の態様によると、高速インターネット・プロトコルのネットワークでｎ個の異なる種類のデータを伝送するためのデータ・トランスポート・コンテナに関する。ｎは２以上の数である。データはイーサネット（登録商標）巨大パケットとして生成される。データ・トランスポート・コンテナはインターネット・プロトコル・パケットである。

本発明によると、データ伝送は、インターネット・プロトコル多重化論理ブロックのシーケンスを有し、各論理ブロックは各種類のデータに対応するｎ個のインターネット・プロトコル物理パケットの組み合わせを有し、各インターネット・プロトコル物理パケットは、当該物理パケットが有するデータの種類に依存する所定数のイーサネット（登録商標）巨大パケットを有する。

本発明は、第２の態様によると、本発明によるデータ・トランスポート・コンテナを高速インターネット・プロトコル・ネットワークで送信する送信元装置Ｓ＿ＤＥＶに関する。データ・トランスポート・コンテナは、ｎ個の異なる種類のデータを有する。ｎは２以上の数である。各種類のデータは、イーサネット（登録商標）巨大パケットとして生成される。

本発明によると、送信元装置は、
−単一の種類のデータを有する所定数のイーサネット（登録商標）巨大パケットを、対応する種類のインターネット・プロトコル物理パケットに統合する手段、
−各種類のデータに対応するｎ個のインターネット・プロトコル物理パケットを、インターネット・プロトコル多重化論理ブロックに結合する手段、
−インターネット・プロトコル多重化論理ブロックを有するストリームをネットワークで伝送する手段、を有する。

本発明は、第３の態様によると、本発明によるデータ・トランスポート・コンテナを受信する宛先装置Ｄ＿ＤＥＶに関する。データ・トランスポート・コンテナは、ｎ個の異なる種類のデータを有する。ｎは２以上の数である。各種類のデータは、イーサネット（登録商標）巨大パケットとして生成される。

本発明によると、宛先装置は、
−各種類のデータに対応するイーサネット（登録商標）巨大パケットを復元するために、受信したストリームをフィルタリングする手段、を有する。

本発明は、第４の態様によると、高速インターネット・プロトコルのネットワークでｎ個の異なる種類のデータを伝送する方法に関する。ｎは２以上の数である。各種類のデータは、イーサネット（登録商標）巨大パケットとして生成される。

本発明によると、方法は、
−単一の種類のデータを有する所定数のイーサネット（登録商標）巨大パケットを、対応する種類のインターネット・プロトコル物理パケットに統合する段階、
−各種類のデータに対応するｎ個のインターネット・プロトコル物理パケットを、インターネット・プロトコル多重化論理ブロックに結合する段階、
−インターネット・プロトコル多重化論理ブロックを有するストリームをネットワークで伝送する段階、
−ストリームを受信する段階、
−各種類のデータに対応するイーサネット（登録商標）巨大パケットを復元するために、受信したストリームをフィルタリングする段階、を有する。

本発明の実施例は、以下の文章及び添付の図面を参照して説明される。

本発明による、高速ＩＰネットワークで異なる種類のデータを結合して伝送する方法の概略である。 専門のカメラにより生成された異なる種類のデータである。 ＩＰ多重化論理ブロックの構造の例である。 イーサネット（登録商標）ＩＰ−ＵＤＰ−ＲＴＰパケットのカプセル化の例である。 イーサネット（登録商標）・オーバーＩＰのカプセル化の例である。 ＩＰヘッダーである。 ＵＤＰヘッダーである。 ＤＰＸオーバーＲＴＰのカプセル化である。 ビデオ・パケットのみのストリームのＤＰＸフォーマットの構造である。 ＤＰＸヘッダー・ペイロードを有するイーサネット（登録商標）巨大パケットである。 ＤＰＸビデオ・ライン・ペイロードを有するイーサネット（登録商標）巨大パケットである。 ＡＩＦＦファイルの構造である。 ＡＩＦＦファイル・オーバーＲＴＰのカプセル化である。 ＡＩＦＦチャンク専用のＲＴＰのカプセル化である。 ＡＩＦＦチャンク・ペイロードを有するイーサネット（登録商標）・パケットである。 データ・トランスポート・コンテナ内の多重化レイアウトである。

専門的用途のためのカメラは、以下の出力ストリームを、イーサネット（登録商標）ＩＰ−ＵＤＰ−ＲＴＰの巨大パケットとして生成する。
−ＤＰＸビデオ。
−ビデオ・コンテンツと時間的関係を維持しているＡＩＦＦ音声。
−ビデオ・コンテンツと時間的関係のない、ＡＩＦＦ音声としても提供されるインターコム音声。
−（適用可能な場合に）ビデオ・カメラにより生成されるメタデータ・パケット。

メタデータ・ストリームは、カメラにより生成されたメタデータ、又は（任意のウェブ・サーバーにより生成されたメタデータのような）外部メタデータを有する。これらのコンテンツは、カメラ・ストリーム・コンテンツに関連し、後の編集のために有用である。

これら全てのデータを結合して遠隔の装置へ高速で伝送する必要がある。この必要を満たすための方法は、これらのデータを高速ＩＰネットワークで伝送することである。

図１は、本発明の、ｎ個の異なる種類のデータを高速インターネット・プロトコル・ネットワークで伝送する方法を示す。

送信側で、送信元装置Ｓ＿ＤＥＶは、カメラにより生成された全ての異なるストリームをパケットに結合し、全てのパケットを単一の物理ＩＰ伝送リンクを用いて伝送する。

図２に示されるように、チャネル多重化のみがＩＰパケット層で行われる。これは、異なるメディアにより生成された全ての元のＩＰ−ＵＤＰ−ＲＴＰパケットが変更されないことを意味する。

受信側で、宛先装置Ｄ＿ＤＥＶは、ＩＰパケットをフィルタリングし、関連するスタンドアロン処理又は記憶装置へ転送する。ＩＰトランスポート・ストリームは、伝送用パイプラインと考えられるので、当該パイプライン内の物理的なデータ・フローは単一の次元を有する。各プログラムのタイミング同期を維持しながら、１以上のプログラムのトランスポート・ストリーム・パケットを、単一の統一ビット・ストリームに交互に配置する処理は、「ＩＰ多重化」として知られている。ＩＰ多重化処理は、物理的に一次元のパイプライン内に、仮想的に複数のサブパイプラインを作成するようなものである。

以下では、このような仮想サブパイプラインを、巨大パケットを用いて単一の物理パイプライン内に実現する、可能な方法を説明する。

物理的には、物理パイプライン内には、１つのトランスポート・ストリームのパイプライン・リンクのみが存在し、サブパイプラインは存在しない。仮想サブパイプラインは、一次元のトランスポート・ストリーム・パイプライン内でのサブストリーム多重化を通じて実現されなければならない。このような多重化を行うために、トランスポート・ストリームは、図３に示すような多重化論理ブロックのシーケンスを有する。各ブロックは、現在の物理パイプライン内の全仮想サブパイプラインの最小ストリーム単位を意味する。

図３の各ＩＰ多重化論理ブロックは、ＩＰ物理パケットを有する。ＩＰ物理パケットは、ビデオ、音声、インターコム及び他のデータの多重化されたトランスポート・パケットである。本例では、ビデオ、音声及びインターコムのストリームは、実時間トランスポート・パケットなので、それらのストリームのために多重化論理ブロック内の固定ビットが予約されている。さらに、多重化論理ブロック内には、カメラが生成したメタデータ・パケット及び外部パケットのような非実時間パケットのためのビットがある。

本発明のデータ・トランスポート・コンテナは、ｎ個の異なる種類のデータを高速インターネット・プロトコル・ネットワークで伝送するために用いられる。

有利なことに、ｎは２に等しく、第１の種類のデータは送信元により生成されたＤＰＸビデオ・コンテンツであり、第２の種類のデータは送信元により生成されたＡＩＦＦ音声信号である。ＡＩＦＦ音声信号は、ビデオ・コンテンツと時間的関係を維持している。

有利なことに、ｎは３に等しく、第１の種類のデータは送信元により生成されたＤＰＸビデオ・コンテンツであり、第２の種類のデータは送信元により生成されたＡＩＦＦ音声信号である。ＡＩＦＦ音声信号は、ビデオ・コンテンツと時間的関係を維持している。第３の種類のデータは、ＡＩＦＦ音声信号として提示され、ビデオ・コンテンツと時間的関係のないインターコム音声信号である。

有利なことに、ｎは４に等しく、第１の種類のデータは送信元により生成されたＤＰＸビデオ・コンテンツであり、第２の種類のデータは送信元により生成されたＡＩＦＦ音声信号である。ＡＩＦＦ音声信号は、ビデオ・コンテンツと時間的関係を維持している。第３の種類のデータは、ＡＩＦＦ音声信号として提示され、ビデオ・コンテンツと時間的関係のないインターコム音声信号である。第４の種類のデータは、メタデータである。

例として、先ず、ＤＰＸフォーマット専用のＲＴＰカプセル化を説明する。次に、ＡＩＦＦフォーマット専用のＲＴＰカプセル化を説明する。そして、多重化段階を説明する。

［ビデオ・パケットのカプセル化］
図３は、多重化ブロックのデータ構造を示す。多重化論理ブロックは、ビデオ部、音声部、インターコム部、及びメタデータ部を有する。ソースの各部分は、ソース・ストリームの最小多重ユニット（ＭＭＵ）である１つのＩＰパケット又はＩＰパケットのグループを有する。ＭＭＵは、各ソース・パケットの最小伝送可能ユニットであり一緒に送信されなければならない１つのＩＰパケット又はＩＰパケットのグループである。ＭＭＵの構造は、現在のアプリケーションのバッファの制限に適合する。各ソース・ストリームのＭＭＵのデータ構造を以下に説明する。

図４は、パケットのデータ構造を示す。例として考えるアプリケーションでは、データはＤＰＸデータ、ＡＩＦＦデータである。

図５、６、７は、イーサネット（登録商標）、ＩＰ、ＵＤＰフォーマットの関連するヘッダー及びカプセル化データ構造を示す。これらのデータ構造に示されるように、イーサネット（登録商標）のヘッダーは１４バイトを有し、イーサネット（登録商標）・トレイラは４バイトであり、標準のＩＰヘッダーは２０バイトであり、ＵＤＰヘッダーは８バイトである。

図８は、ＤＰＸフォーマット専用のＲＴＰのカプセル化を示す。この場合には、標準のＲＴＰヘッダー（１２バイト）の次にＤＰＸペイロード・ヘッダー（１２バイト）がある。ＲＴＰパケットは、同一のタイムスタンプを有するＤＰＸフレームを有する。ＲＴＰ毎に１つのＤＰＸフレームのデータのみが許可される。

ＳＭＰＴＥ２６８Ｍ−２００３で規定されるように、各ＤＰＸファイルは４つのセクションを有する。最初の３つのセクションは、ヘッダー情報である。４番目のセクションはビデオ・データを有する。通常、３番目のセクションは、ユーザーが定義するデータを有し、カスタマイズしたメタデータ情報のための拡張領域を提供する。この３番目のセクションは、例として挙げるアプリケーションで用いられない。このアプリケーションでは、ビデオ情報をＤＰＸパケット内の全てのメタデータと結合しないが、２つの別個のストリームを作成することを提案する。１つのストリームは、全体のヘッダー情報及びビデオ情報のみを有するＤＰＸパケットを有する。また、メタデータは、別のメタデータのみのストリーム内に読み込まれる。

標準的なビデオ・フレームが１９２０＊１０８０ピクセルであり、各ピクセルが３６ビット毎に符号化される場合を検討する。したがって、ビデオ・フレームの重みは、１９２０＊１０８０＊３６ビット、又は７４６４９６００ビット、又は９．３３１２Ｍバイトで表現される。ＤＰＸビデオ・ストリームは、ＤＰＸヘッダーを有するビデオ・データのみを有する。ＤＰＸヘッダーは、ヘッダー情報である２つのセクション、空の３番目のセクション、及びビデオ・フレームを有する４番目のセクションを有する。図９に示される例では、３番目のセクションは現れない。

上述のヘッダー構造を検討する。イーサネット（登録商標）巨大パケット（ＭＴＵ：９０１８バイト）がＤＰＸビデオを伝送するために用いられる場合、図１０に示されるＤＰＸビデオのカプセル化データ構造が生成される。

イーサネット（登録商標）巨大パケットを用い、ＩＰ−ＵＤＰ−ＲＴＰ−ＤＰＸパケットを伝送する場合、最大の利用可能なＤＰＸペイロード・データは８９４８バイトである。ビデオＤＰＸパケット（図１１）を伝送するために、元のＤＰＸパケット（９．３３１２Ｍバイト）を、一連の小さいイーサネット（登録商標）巨大パケット（９０１８バイト）に分割しなければならない。簡易なフィルタリングのため、図９に示されるＤＰＸヘッダーのデータは、図１１に示されるような１つの別個の巨大パケットで伝送される。ＤＰＸヘッダーの巨大パケットの合計サイズは、２１１８バイトである。

ビデオ・フレームの各ビデオ・ラインを単一の巨大パケットにパケット化することが選択される。各ビデオ・ラインは、１９２０＊３６ビット、又は８６４０バイトである。図１２に示されるように、ビデオ・フレームの全体は、１０８０個のパケットに読み込まれる。ＤＰＸビデオ・ラインの巨大パケットの合計サイズは、８７１０バイトである。上述の説明によると、ＤＰＸビデオ・フレームは１０８１個のイーサネット（登録商標）巨大パケットとして伝送される。最初に伝送されたパケットは、ＤＰＸヘッダー・ペイロード（２１１８バイト）を有する。更に１０８０個の伝送パケットは、ＤＰＸビデオ・ライン・ペイロード（各８７１０バイト）を有する。

有利なことに、第１の種類のデータに対応する巨大パケットの集合の中で、１つの巨大パケットがＤＰＸヘッダーを有する。

［音声パケットのカプセル化］
音声交換ファイル・フォーマット（ＡＩＦＦ）規格は、ＲＴＰにする前にサンプル音声チャネルを格納するために用いられる。図１３に示されるように、ＡＩＦＦファイルは、異なる種類のチャンクを有する。ヘッダー・コンテンツ、共通チャンク・サイズ、及び音声記録チャンクが定められている。音声データ・チャンク・サイズは、伝送されるパケットのサイズに依存する。

図１３に示す例では、１チャンネルの音声サンプルをエンコードするために３バイトが用いられる。また、６個の音声チャンネルが用いられ、サンプル・フレームのサイズは１８バイトである。音声周波数は４８ｋＨｚであり、ビデオ・レートは２４フレーム毎秒である。１ビデオ・フレーム中に、２０００個の音声サンプル・フレームが生成される。これらの音声サンプル・フレームを、それぞれ等しいサイズの５個のパケットに分割する場合、各パケットは、４００個のサンプル・フレームを有する。１ビデオ・フレーム中に合計で３６ｋバイトの音声サンプル・フレームがあるので、各パケット内の音声ペイロードは、７．２ｋバイトに等しい。図１３に示したＡＩＦＦフォームによると、音声データ・チャンクは７２１６バイトであり、全ＡＩＦＦフォームは７２８６バイトである。

図１４は、ＡＩＦＦチャンク専用のＲＴＰのカプセル化を示す。この場合には、標準のＲＴＰヘッダー（１２バイト）の次にＡＩＦＦペイロード・ヘッダー（８バイト）がある。ＡＩＦＦチャンクは、新しいＲＴＰパケットから開始しなければならない。上述のＡＩＦＦフォームは、巨大イーサネット（登録商標）・パケット（ＭＴＵ９０１８バイト）でカプセル化される。

図１５は、イーサネット（登録商標）ＩＰ―ＵＤＰ−ＲＴＰ−ＡＩＦＦパケットの構造を示す。全パケット長は、７３５２バイトである。

［多重化］
ビデオ・パケット及び音声パケットの多重化を説明する。ＤＰＸファイルは分割され、イーサネット（登録商標）ＩＰ−ＵＤＰ−ＲＴＰパケットに埋め込まれる。ＤＰＸヘッダー（ユーザー定義データの部分を除く）は１つの別個の巨大パケットとして伝送される。その後、一式の１０８０個の巨大パケットが生成される。各巨大パケットは、ビデオ・フレームの１つのビデオ・ラインを有する。これらの１０８１個の巨大パケットは、ＤＰＸビデオ・ストリームの最小多重化ユニットに相当する。音声及びインターコムのソース・ストリームの最小多重化ユニットは、ＡＩＦＦフォーム・ペイロードを有する５個のイーサネット（登録商標）巨大パケットを有する。メタデータ及び外部データの場合には、最小多重化ユニットは、単一のイーサネット（登録商標）巨大ＩＰパケットを有する。

図１６は、トランスポート・ストリーム内の多重化論理ブロックの詳細な構造を示す。多重化ブロックの最初の部分は、メタデータ部である。メタデータ部は、巨大ＩＰメタデータ・パケットである。メタデータ部の最大サイズは９ｋＢである。メタデータ部のペイロードは、内部及び外部で生成された任意のメタデータである。大きいメタデータを単一の巨大パケットに完全に読み込むことができない場合、メタデータは分割され、次の多重化ブロックのメタデータ・パケットに読み込まれる。多重化ブロック内のメタデータ・パケットは任意である。メタデータが存在しない場合、メタデータ・パケットは省略される。

多重化ブロック内の２番目及び３番目の部分は、インターコム部及び音声部である。インターコム部は、５個のインターコム・パケットを有し、音声部は５個の音声パケットを有する。インターコム及び音声パケットは、両方とも巨大イーサネット（登録商標）ＩＰパケットである。巨大イーサネット（登録商標）ＩＰパケットは、７３５２バイトであり、ＡＩＦＦペイロードを有する。インターコム・パケットは任意であり、音声パケットは必須である。

４番目の部分（ビデオ部）で、１０８１個の巨大ビデオ・パケットが伝送される。多重化ブロックの平均サイズは、９．４８５Ｍバイトである。

図１６は、本発明によるデータ・トランスポート・コンテナの最終的なＩＰ多重化レイアウトを示す。このデータ・トランスポート・コンテナでは、ＩＰパケットとして提供されるソース・ストリーム又はパケットは、イーサネット（登録商標）ＩＰトランスポート・ストリームに多重化される。ＩＰトランスポート・ストリームは、ソース・パケットのグループの最小伝送ユニット、つまりビデオ最小多重化ユニット（ＭＭＵ）、音声ＭＭＵ、インターコムＭＭＵ、及びメタデータ／外部データＭＭＵの集合である一連の多重化論理ブロックを有する。各ソース信号のＭＭＵは、最小の伝送可能且つ読み出し可能な、ソース・ストリームのパケットである。各ＭＭＴは、各ＭＭＵのソース信号フォーマットの要件に従い設計される。

本願明細書に開示された参考文献、請求項及び図面は、独立に又は任意の適切な組み合わせで提供されてもよい。特徴は、必要に応じてハードウェア、ソフトウェア又はそれらの組み合わせで実施されてもよい。本願明細書中の「実施例」の語は、当該実施例と関連して記載された特定の機能、構造又は特徴が本発明の少なくとも１つの実施例に含まれることを意味する。本願明細書を通じて各所に現れる「ある実施例では」の句は、必ずしも全て同一の実施例を参照するものではなく、又は他の実施例と相互排他的な実施例を分離若しくは置き換えるものではない。請求項内の参照符号は、単に説明のためであり、請求項の範囲を制限するものではない。

Claims (6)

1. ｎ個の異なる種類のデータを高速インターネット・プロトコル・ネットワークで伝送するためのデータ・トランスポート・コンテナを送信する装置であって、前記ｎは２以上の数であり、前記データはイーサネット（登録商標）巨大パケットとして生成され、
   前記データ・トランスポート・コンテナはインターネット・プロトコル・パケットであり、
   前記データ・トランスポート・コンテナは、
   連続するインターネット・プロトコル多重化論理ブロックを有し、
   各論理ブロックは各種類のデータに対応する前記ｎに等しい数のインターネット・プロトコル物理パケットの組み合わせを有し、
   各インターネット・プロトコル物理パケットは、該物理パケットが有する各種類のデータに依存する所定数のイーサネット（登録商標）巨大パケットを統合する、装置。
2. 前記ｎは２に等しく、
   第１の種類のデータは送信元により生成されたＤＰＸビデオ・コンテンツであり、
   第２の種類のデータは送信元により生成されたＡＩＦＦ音声信号であり、
   該ＡＩＦＦ音声信号は、ビデオ・コンテンツと時間的に同期している、
   請求項１に記載の装置。
3. 前記ｎは３に等しく、
   第１の種類のデータは送信元により生成されたＤＰＸビデオ・コンテンツであり、
   第２の種類のデータは送信元により生成されたＡＩＦＦ音声信号であり、
   該ＡＩＦＦ音声信号は、ビデオ・コンテンツと時間的に同期しており、
   第３の種類のデータは、ＡＩＦＦ音声信号として提示され、ビデオ・コンテンツと時間的に同期していないインターコム音声信号である、
   請求項１に記載の装置。
4. 前記ｎは４に等しく、
   第１の種類のデータは送信元により生成されたＤＰＸビデオ・コンテンツであり、
   第２の種類のデータは送信元により生成されたＡＩＦＦ音声信号であり、
   該ＡＩＦＦ音声信号は、ビデオ・コンテンツと時間的に同期しており、
   第３の種類のデータは、ＡＩＦＦ音声信号として提示され、ビデオ・コンテンツと時間的に同期していないインターコム音声信号であり、
   第４の種類のデータはメタデータである、
   請求項１に記載の装置。
5. 前記第１の種類のデータに対応する統合された巨大パケットの中で、１つの巨大パケットがＤＰＸヘッダーを有する、
   請求項２乃至４のいずれか一項に記載の装置。
6. ｎ個の異なる種類のデータを高速インターネット・プロトコル・ネットワークで伝送する方法であって、
   前記ｎは２以上の数であり、各種類のデータはイーサネット（登録商標）巨大パケットとして生成され、当該方法は、
   −単一の種類のデータを有する所定数のイーサネット（登録商標）巨大パケットを、対応する種類のインターネット・プロトコル物理パケットに統合するステップと、
   −各種類のデータに対応する前記ｎに等しい数のインターネット・プロトコル物理パケットを、インターネット・プロトコル多重化論理ブロックに結合するステップと、
   −前記インターネット・プロトコル多重化論理ブロックを有するストリームを前記ネットワークで伝送するステップと、
   −前記ストリームを受信するステップと、
   −各種類のデータに対応するイーサネット（登録商標）巨大パケットを復元するために、前記受信したストリームをフィルタリングするステップと、
   を含む方法。

Images