(57)【要約】      （修正有）【課題】メディアコンテンツを複数のネットワークパケットに変換し、超低遅延が必要な用途に有用なメディアコンテンツ変換機を提供する。【解決手段】メディアコンテンツ変換器２０は、論理回路と、ヘッダ生成器７６と、マルチプレクサ８０とを含む。論理回路は、メディアコンテンツを区切って、ネットワークパケット用のペイロードにするように構成される。ヘッダ生成器は、所定のヘッダフォーマットに従って複数のヘッダフィールドにデータを追加することにより、ネットワークパケット用のパケットヘッダを生成する。マルチプレクサは、ヘッダ生成器からの生成パケットヘッダを論理回路からの対応するペイロードと組み合わせることにより、通信ネットワークを通じた送信のために、ネットワークパケットのシーケンスをストリーミングするように構成される。【選択図】図１
0003231391.tif 000002
【実用新案登録請求の範囲】
【請求項１】
メディアコンテンツをネットワークパケットに変換するメディアコンテンツ変換器であって、
前記メディアコンテンツを区切って、前記ネットワークパケット用のペイロードにするように構成された論理回路と、
所定のヘッダフォーマットに従って複数のヘッダフィールドにデータを追加することにより、前記ネットワークパケットのパケットヘッダを生成するように構成されたヘッダ生成器と、
前記ヘッダ生成器からの生成された前記パケットヘッダを前記論理回路からの対応する前記ペイロードと組み合わせることにより、通信ネットワークを通じた送信のために、前記ネットワークパケットのシーケンスをストリーミングするように構成されたマルチプレクサと
を備える変換器。
【請求項２】
前記ヘッダ生成器は、前記ネットワークパケットの前記シーケンス全体で値が一定のヘッダフィールドを前記ヘッダフォーマットで識別し、生成された前記ヘッダの対応する前記ヘッダフィールドに一定の前記値を挿入するように構成される、請求項１に記載の変換器。
【請求項３】
前記ヘッダ生成器は、前記メディアコンテンツが前記変換器で受信される前に、一定の前記値を挿入するように構成される、請求項２に記載の変換器。
【請求項４】
前記ヘッダ生成器は、連続したネットワークパケットにおいて、規則に従って値がインクリメントされるインクリメントヘッダフィールドを前記ヘッダフォーマットで識別し、前記規則に従って前記インクリメントヘッダフィールドの前記値をインクリメントし、生成された前記ヘッダの対応する前記インクリメントヘッダフィールドにインクリメントされた前記値を挿入するように構成される、請求項１に記載の変換器。
【請求項５】
前記ヘッダ生成器は、値が計算される計算ヘッダフィールドを前記ヘッダフォーマットで識別し、前記計算ヘッダフィールドの前記値を計算し、前記ヘッダを生成するときに、計算された前記値を前記計算ヘッダフィールドに挿入するように構成される、請求項１に記載の変換器。
【請求項６】
前記ヘッダ生成器は１つ又は複数のハードウェアレジスタを有し、前記ハードウェアレジスタは、生成されている現在のパケットのヘッダのヘッダフィールド用の数値を指定するビットパターンを保持するように構成される、請求項１から５のいずれかに記載の変換器。
【請求項７】
前記論理回路は、前記現在のパケットの前記ヘッダを前記ハードウェアレジスタから送信するよう前記マルチプレクサを切り替え、次いで、前記現在のパケットのペイロードを送信するよう前記マルチプレクサを切り替えるように構成される、請求項6に記載の変換器。
【請求項８】
前記ヘッダ生成器は、前記ハードウェアレジスタ内の、連続したネットワークパケットの間の、前記ヘッダフィールドの前記値のうちの１つ又は複数を更新するように構成される、請求項6に記載の変換器。
【請求項９】
前記変換器はさらに、２つ又はそれより多くの異なる所定のヘッダフォーマットの中から、前記ヘッダフォーマットを選択し、選択された前記ヘッダフォーマットを前記ヘッダ生成器に供給するように構成されたヘッダフォーマットセレクタを備える、請求項1から5のいずれかに記載の変換器。
【請求項１０】
前記論理回路と、前記ヘッダ生成器と、前記マルチプレクサとはハードウェア実装される、請求項1から5のいずれかに記載の変換器。
【請求項１１】
メディアコンテンツをネットワークパケットに変換する方法であって、前記方法は、
前記メディアコンテンツを区切って、前記ネットワークパケット用のペイロードにする段階と、
所定のヘッダフォーマットに従って複数のヘッダフィールドにデータを追加することにより、前記ネットワークパケットのパケットヘッダを生成する段階と、
生成された前記パケットヘッダを対応する前記ペイロードと組み合わせることにより、通信ネットワークを通じた送信のために、前記ネットワークパケットのシーケンスを生成する段階と
を含む、方法。
【請求項１２】
前記パケットヘッダを生成する段階は、前記ネットワークパケットの前記シーケンス全体で値が一定のヘッダフィールドを前記ヘッダフォーマットで識別し、生成された前記ヘッダの対応する前記ヘッダフィールドに一定の前記値を挿入する段階を含む、請求項１１に記載の方法。
【請求項１３】
一定の前記値を挿入する段階は、前記メディアコンテンツを受信する前に行われる、請求項１２に記載の方法。
【請求項１４】
前記パケットヘッダを生成する段階は、連続したネットワークパケットにおいて、規則に従って値がインクリメントされるインクリメントヘッダフィールドを前記ヘッダフォーマットで識別し、前記規則に従って前記インクリメントヘッダフィールドの前記値をインクリメントし、生成された前記ヘッダの対応する前記インクリメントヘッダフィールドにインクリメントされた前記値を挿入する段階を含む、請求項１１に記載の方法。
【請求項１５】
前記パケットヘッダを生成する段階は、値が計算される計算ヘッダフィールドを前記ヘッダフォーマットで識別し、前記計算ヘッダフィールドの前記値を計算し、前記ヘッダを生成するときに、計算された前記値を前記計算ヘッダフィールドに挿入する段階を含む、請求項１１に記載の方法。
【請求項１６】
前記パケットヘッダを生成する段階は、生成されている現在のパケットのヘッダのヘッダフィールド用の数値を指定するビットパターンを、１つ又は複数のハードウェアレジスタに保持する段階を含む、請求項１１から１５のいずれかに記載の方法。
【請求項１７】
前記パケットヘッダを生成する段階は、前記現在のパケットの前記ヘッダを前記ハードウェアレジスタから送信するようマルチプレクサを切り替え、次いで、前記現在のパケットのペイロードを送信するよう前記マルチプレクサを切り替える段階を含む、請求項１６に記載の方法。
【請求項１８】
前記パケットヘッダを生成する段階は、前記ハードウェアレジスタ内の、連続したネットワークパケット間の、前記ヘッダフィールドの前記値のうちの１つ又は複数を更新する段階を含む、請求項１６に記載の方法。
【請求項１９】
前記方法はさらに、２つ又はそれより多くの異なる所定のヘッダフォーマットの中から、前記ヘッダフォーマットを選択する段階を含む、請求項１１から１５のいずれかに記載の方法。
【考案の詳細な説明】
【技術分野】
【０００１】
［関連出願の相互参照］
本願は、２０１８年５月８日出願の「メディアツーイーサネット（登録商標）フレームパッケージング用の低遅延パイプライン（Ｌｏｗ−Ｌａｔｅｎｃｙ  Ｐｉｐｅｌｉｎｅ  ｆｏｒ  Ｍｅｄｉａ−Ｔｏ−Ｅｔｈｅｒｎｅｔ（登録商標）  Ｆｒａｍｅ  Ｐａｃｋａｇｉｎｇ）」と題する米国特許出願第１５／９７３，５７２号と、２０１８年３月２９日出願の米国仮特許出願第６２／６５０，１８７号とに基づく優先権を主張する。
【０００２】
本開示は概して、ネットワーク通信に関し、特に、メディアコンテンツを複数のネットワークパケットに変換する方法及びシステムに関する。
【背景技術】
【０００３】
様々な電子システムが、例えばイーサネットネットワークなどのパケットネットワークを通じて、メディアコンテンツの送信に関与している。例えば、自動車通信システムが、ビデオカメラで取得された映像コンテンツ、及び／又は、速度センサ、加速度計、音声センサ、赤外線センサ、レーダーセンサ、超音波センサ、及び距離測定器などの様々な他のセンサで取得された他のメディアコンテンツを、車載コンピュータに転送するためのローカルエリアネットワーク（ＬＡＮ）を用いてよい。
【０００４】
上記説明は、この分野における関連技術の一般概要として示されており、上記説明が包含する情報のうちのいずれかが本特許出願に対する先行技術を構成することを認めるものと解釈されるべきではない。
【考案の概要】
【０００５】
本明細書で説明される一実施形態が、メディアを複数のイーサネットパケットに変換する変換パイプラインを提供する。変換パイプラインは、メディア入力段、パケット化器、イーサネットメディアアクセス制御（ＭＡＣ）エンジン、及びイーサネット物理層（ＰＨＹ）インタフェースを含む。メディア入力段は、メディアコンテンツを搬送するメディアフレームのシーケンスをメディアソースから受信するように構成される。パケット化器は、ヘッダを生成して、メディアフレームの一部を対応する生成されたヘッダに付加することにより、メディアフレームをイーサネットパケットのシーケンスに変換するように構成され、パケット化器には、第１のメディアフレームがメディアソースから完全に受信される前に、第１の生成されたヘッダに第１のメディアフレームの第１の部分を付加することが含まれる。イーサネットＭＡＣエンジンは、第１のメディアフレームがメディアソースから完全に受信される前に、連続した構成単位として第１のイーサネットパケットの出力を開始するように構成され、第１のイーサネットパケットは、第１のヘッダと第１のメディアフレームの第１の部分に対応するペイロードビットとを含む。イーサネットＰＨＹインタフェースは、ネットワークを通じてイーサネットパケットのシーケンスを送信するように構成される。
【０００６】
いくつかの実施形態において、パケット化器は、メディアフレームの受信と同時にヘッダを生成するように構成されたヘッダ生成器と、ヘッダとメディアコンテンツを含むそれぞれのペイロードとをインターリーブして、複合出力ストリーミングを形成するように構成されたマルチプレクサ（ＭＵＸ）とを含む。いくつかの実施形態において、パケット化器は、メディアフレームのシーケンス内のフレームマーカーを検出し、当該フレームマーカーに従って、メディアコンテンツを区切って、連続したイーサネットパケット用の連続したペイロードにするように構成された論理回路を含む。一実施形態において、パケット化器は、複数のフレームマーカーのうちの１つを有するイーサネットパケットのペイロードのそれぞれを開始するように構成される。
【０００７】
いくつかの実施形態において、変換パイプラインは弾性バッファを含み、弾性バッファは、メディア入力段とパケット化器との間のクロック速度の差を補償するように構成される。一実施形態において、弾性バッファのバッファサイズは、単一のメディアフレームより小さい。開示された一実施形態において、変換パイプラインは、単一のメディアフレームの持続時間より短いエンドツーエンド遅延を提供するように構成された１つ又は複数のバッファを含む。
【０００８】
様々な例示的実施形態において、メディアコンテンツは、映像データ、音声データ、速度データ、加速度データ、赤外線データ、レーダーデータ、ライダーデータ、超音波画像データ、距離測定器データ、近接データ、及び衝突防止データのうちの１つ又は複数を含む。一実施形態において、メディア入力段は、メディアフレームを受信することに加えて、センサから入力値を受信するように構成され、パケット化器は、メディアソースからのメディアフレームと、センサからの入力値との両方を、イーサネットパケットのシーケンスに変換するように構成される。
【０００９】
本明細書で説明される一実施形態に従って、ハードウェア実装された変換パイプラインでメディアを複数のイーサネットパケットに変換する方法がさらに提供される。本方法は、メディアコンテンツを搬送するメディアフレームのシーケンスをメディアソースから受信する段階を含む。これらのメディアフレームは、ヘッダを生成して、対応する生成されたヘッダにメディアフレームの一部を付加することにより、イーサネットパケットのシーケンスに変換される。この変換には、第１のメディアフレームがメディアソースから完全に受信される前に、第１の生成されたヘッダに第１のメディアフレームの第１の部分を付加することが含まれる。第１のイーサネットパケットを連続した構成単位として出力する段階は、第１のメディアフレームがメディアソースから完全に受信される前に開始する。第１のイーサネットパケットは、第１のヘッダと第１のメディアフレームの第１の部分に対応するペイロードビットとを含む。変換パイプラインで生じたイーサネットパケットのシーケンスは、物理層（ＰＨＹ）インタフェースを通じてネットワークに送信される。
【００１０】
本明細書で説明される一実施形態に従って、メディアコンテンツを複数のネットワークパケットに変換するメディアコンテンツ変換器がさらに提供される。この変換器は、論理回路、ヘッダ生成器、及びマルチプレクサを含む。論理回路は、メディアコンテンツを区切って、ネットワークパケット用のペイロードにするように構成される。ヘッダ生成器は、所定のヘッダフォーマットに従って複数のヘッダフィールドにデータを追加することにより、ネットワークパケット用のパケットヘッダを生成するように構成される。マルチプレクサは、ヘッダ生成器からの生成パケットヘッダを論理回路からの対応するペイロードと組み合わせることにより、通信ネットワークを通じた送信のために、ネットワークパケットのシーケンスをストリーミングするように構成される。
【００１１】
いくつかの実施形態において、ヘッダ生成器は、ネットワークパケットのシーケンス全体で値が一定のヘッダフィールドをヘッダフォーマットで識別し、生成されたヘッダの対応するヘッダフィールドに、この一定値を挿入するように構成される。例示的な一実施形態において、ヘッダ生成器は、メディアコンテンツが変換器で受信される前に、一定値を挿入するように構成される。
【００１２】
いくつかの実施形態では、ヘッダ生成器は、連続したネットワークパケットにおいて、規則に従って値がインクリメントされるインクリメントヘッダフィールドをヘッダフォーマットで識別し、当該規則に従ってインクリメントヘッダフィールドの値をインクリメントし、生成されたヘッダの対応するインクリメントヘッダフィールドにインクリメントされた値を挿入するように構成される。いくつかの実施形態において、ヘッダ生成器は、値が計算される計算ヘッダフィールドをヘッダフォーマットで識別し、計算ヘッダフィールドの値を計算し、ヘッダを生成するときに、計算された値を計算ヘッダフィールドに挿入するように構成される。
【００１３】
いくつかの実施形態において、ヘッダ生成器は、１つ又は複数のハードウェアレジスタを含み、これらのハードウェアレジスタは、生成されている現在のパケットのヘッダのヘッダフィールド用の数値を指定するビットパターンを保持するように構成される。一実施形態において、論理回路は、現在のパケットのヘッダをハードウェアレジスタから送信するようマルチプレクサを切り替え、次いで、現在のパケットのペイロードを送信するようマルチプレクサを切り替えるように構成される。一実施形態において、ヘッダ生成器は、ハードウェアレジスタ内の、連続したネットワークパケット間の、ヘッダフィールドの値のうちの１つ又は複数を更新するように構成される。
【００１４】
開示された一実施形態において、変換器はさらに、２つ又はそれより多くの異なる所定のヘッダフォーマットから特定のヘッダフォーマットを選択し、選択されたヘッダフォーマットをヘッダ生成器に供給するように構成されたヘッダフォーマットセレクタを含む。一実施形態において、論理回路、ヘッダ生成器、及びマルチプレクサは、ハードウェア実装される。
【００１５】
本明細書で説明される一実施形態に従って、メディアコンテンツを複数のネットワークパケットに変換する方法も提供される。本方法は、メディアコンテンツを区切って、ネットワークパケット用のペイロードにする段階を含む。所定のヘッダフォーマットに従って、複数のヘッダフィールドにデータを追加することにより、複数のパケットヘッダがネットワークパケット用に生成される。生成パケットヘッダを対応するペイロードと組み合わせることにより、ネットワークパケットシーケンスが、通信ネットワークを通じた送信のために生成される。
【００１６】
本開示は、次に挙げる図面と併せて、本開示の実施形態についての以下の詳細な説明から、より十分に理解されるであろう。
【図面の簡単な説明】
【００１７】
【図１】本明細書で説明される一実施形態に従って、メディア／イーサネット変換器を概略的に示すブロック図である。
【００１８】
【図２】本明細書で説明される一実施形態に従って、図１のメディア／イーサネット変換器に用いられるパケット化器を概略的に示すブロック図である。
【００１９】
【図３】本明細書で説明される一実施形態に従って、メディア／イーサネット変換の方法を概略的に示すフロー図である。
【００２０】
【図４】本明細書で説明される一実施形態に従って、パケット生成の方法を概略的に示すフロー図である。
【００２１】
【図５】本明細書で説明される一実施形態に従って、あるパケットの例示的なヘッダフォーマットを示す図である。
【考案を実施するための形態】
【００２２】
本明細書で説明される実施形態によって、メディアコンテンツを複数のネットワーク通信パケットに変換する方法及び装置の改善が提供される。開示される技術は特に、超低遅延が必要とされる用途に有用である。そのような用途の１つの例が自動車システムであり、当該システムでは、映像コンテンツ（及び／又は様々なセンサの出力）が、複数のイーサネットパケットに変換されて、車両の中央コンピュータに送信される。しかしながら、本明細書で説明される技術は様々な他の用途にも有用であり、これらの用途は必ずしも遅延に敏感なわけではない。
【００２３】
以下に続く説明では、いくつかの場所において、単なる例として、主に映像コンテンツに言及する。しかしながら、他の好適なタイプのセンサ及び他の好適なタイプのデータが、本明細書で説明されるコンポーネント及び機能を有する装置によって扱われ、また適切に用いられ、以下に続くこの説明及び実用新案登録請求の範囲で論じられ、そのようなセンサ及びデータには、限定されるものではないが、速度センサ及び速度データ、加速度計及び加速度データ、音声センサ及び音声データ、赤外線センサ及び赤外線データ、レーダーセンサ及びレーダーデータ、ライダーセンサ及びライダーデータ、超音波センサ及び超音波データ、距離測定器及び近接データ、並びに衝突防止画像処理および衝突防止画像データなどが含まれることが具体的に意図されている。
【００２４】
以下に続く説明では、いくつかの場所において、メディアフレームのシーケンスに供給される未処理メディアコンテンツに主に言及する。しかしながら、必ずしもフレーム化されてなく、必ずしもメディアではない他の好適なタイプのデータ、例えば、１つ又は複数のセンサにより供給されるストリーミングメディア又は散発的データが、本明細書で説明されるコンポーネント及び機能を有する装置によって扱われ、また適切に用いられ、以下に続くこの説明及び実用新案登録請求の範囲で論じられることが、具体的に意図されている。
【００２５】
いくつかの実施形態において、開示される技術はメディア／イーサネット変換器によって実行され、当該変換器は完全にハードウェアで実装された変換パイプラインを含む。変換パイプラインは、メディア入力段を含み、イーサネット段が後に続く。メディア入力段は、未処理映像コンテンツを搬送するメディアフレームのシーケンスをメディアソース（例えば、ビデオカメラ）から受信するように構成される。イーサネット段はパケット化器を有し、パケット化器は、メディアフレームを、イーサネット又は他の好適なデータネットワーク規格に準拠したデータパケットのシーケンスに変換するように構成される。以下に続く説明では、例として主にイーサネットに言及するが、イーサネットという用語が任意の好適な現在又は将来のパケットベースのデータネットワークを包含することが具体的に意図されている。
【００２６】
いくつかの実施形態において、パケット化器は、オンザフライで、フレームをメモリに書き込むことも、続いてフレームをメモリから読み出すこともなく、イーサネットパケットが形成されているときに、イーサネットヘッダを生成することにより、且つメディアフレームの一部をイーサネットヘッダに付加することにより、メディアフレームを複数のイーサネットパケットに変換する。イーサネットパケットのシーケンスは、イーサネットネットワーク（例えば、車載ローカルエリアネットワーク（ＬＡＮ））を通じて、イーサネット物理層（ＰＨＹ）インタフェースが後に続くイーサネットメディアアクセス制御（ＭＡＣ）エンジンによって送信される。
【００２７】
メディア／イーサネット変換器は通常、例えば、ホストシステムとの通信のために、一般的な管理及び構成及び／又は他の非リアルタイムタスクのために、中央演算処理装置（ＣＰＵ）又は好適なソフトウェアを実行する他の好適なプロセッサを有する。しかしながら、変換パイプライン（「データパス」）は、ハードウェアで完全に実装される。さらに、データパスは、一実施形態において、いかなるダイレクトメモリアクセス（ＤＭＡ）処理も割り込みも伴わない。したがって、開示されたメディア／イーサネット変換プロセスは、非常に低遅延であることが特徴である。
【００２８】
例えば、パケット化器は通常、映像フレームがメディア入力段によって完全に受信される前に、映像フレームの一部を対応するパケットヘッダに付加する。同様に、イーサネットＭＡＣエンジンは通常、映像フレームに属するペイロードビットを含むイーサネットパケットを、この映像フレームがメディア入力段によって完全に受信される前に出力し始める。
【００２９】
データバッファリングが、変換パイプラインに用いられる場合、フレーム全体のバッチ処理に用いるのではなく、パイプラインの異なる段の間のクロック速度の差を補償するのに用いられる。そのようなものとして、変換パイプラインでのデータバッファリングは、ほんの何分の１かの映像フレームに限定され、一般的である。
【００３０】
画素などのデータをメディア入力段に入力してから、対応するペイロードビットをイーサネットＰＨＹインタフェースにより出力するまでの、変換パイプラインのエンドツーエンド遅延が、映像フレームなどのメディアフレームを完全に受信するのに必要な持続時間よりずっと短くなるように設計されている限りは、一実施形態において、バッファが変換パイプラインに配置され、メディアフレームの受信と、パイプラインがメディアフレームをイーサネットパケットに変換するのに必要な時間とを同期させる。これらのバッファは、パケットが変換パイプラインから出力される前に、パケットに挿入されるメディアが完全に受信されていなかったために、パイプラインが止まるかもしれない又は不完全なパケットを出力するかもしれない欠乏状態を防ぐ大きさに作られている。
【００３１】
本明細書で説明されるいくつかの実施形態において、パケット化器はヘッダ生成器を有し、ヘッダ生成器は、所定のヘッダフォーマットに従い、１つ又は複数の構成可能なハードウェアレジスタ（「ヘッダテンプレート」と呼ばれる）を用いてオンザフライでパケットヘッダを生成する。ヘッダフォーマットは、様々なヘッダフィールド、例えばビットパターンの形で指定される。
【００３２】
いくつかの実施形態において、ヘッダフォーマットは、ヘッダフィールドのタイプ及び／又は数値を指定する。ヘッダフィールドのタイプの例には、（ｉ）パケットシーケンス全体で値が一定である「一定」フィールド、（ｉｉ）規則に従って、連続したパケットにおいて値がインクリメントされる「インクリメント」フィールド、及び（ｉｉｉ）それぞれのパケットのペイロードの少なくとも一部にわたって値が計算される「計算」フィールドが含まれる。ヘッダ生成器は、特定のパケット用のヘッダを生成すると、ヘッダフォーマットで指定されるフィールドのタイプに従ってフィールドごとに値を計算する。
【００３３】
いくつかの実施形態において、ヘッダフォーマットは、例えば、メディア／イーサネット変換器の製造時に、一組の所定のヘッダフォーマットから選択される。この特徴により、例えば、同じメディア／イーサネット変換器が、異なる通信プロトコルを用い且つ異なるヘッダフォーマットを必要とする異なるホストシステムで動作することが可能になる。
【００３４】
メディア／イーサネット変換器の例示的な実装例、及び関連する方法が、以下で詳細に記述され且つ説明される。
【００３５】
図１は、本明細書で説明される一実施形態に従って、メディア／イーサネット変換器２０を概略的に示すブロック図である。本例では、メディア／イーサネット変換器２０が自動車両の安全又は自動推進サブシステムの一部として配置されており、カメラ又は他のセンサにより取得された映像又は他のセンサデータをイーサネットフレームに変換するのに用いられる。代替的に、同様のメディア／イーサネット変換器が、他のタイプのホストシステム及び用途に用いられ得る。
【００３６】
図１の実施形態では、メディア／イーサネット変換器２０が、メディア入力段２４、イーサネット段２８、及びイーサネット物理層（ＰＨＹ）段３２を含むハードウェア実装された変換パイプラインを有する。この変換パイプラインは、未処理メディアフレームのシーケンスを受信し、ペイロードがメディアコンテンツを搬送するイーサネットパケットのシーケンスを出力する。中央演算処理装置（ＣＰＵ）３６が、一実施形態において、変換パイプラインの様々な要素を管理し且つ構成する。ＣＰＵ３６は通常、ホストシステムとの通信、及びメディア／イーサネット変換のリアルタイムデータパス上にはない様々な他の機能を担う。
【００３７】
一実施形態において、メディア／イーサネット変換器２０は、メモリ３８（通常は、ランダムアクセスメモリ（ＲＡＭ））を有する。メモリ３８は、例えば、ＣＰＵ３６が好適な情報を格納するのに用いられる。メモリ３８は通常、変換パイプラインに接続されず、変換パイプラインによりアクセスされることもない。本明細書で説明されたように、変換パイプラインは、メモリとの間でメディアフレームの書き込みも読み出しも行うことなく、メディアフレームをイーサネットパケットに変換する。
【００３８】
一実施形態において、メディア入力段２４は、センサインタフェース４０、マルチプレクサ（ＭＵＸ）４４、メディア／弾性バッファ（メディア／ｅｂｕｆ）変換器４８、メディアエンコーダ５２、及びＭＵＸ５６を含む。センサインタフェース４０は、センサに接続して、未処理メディアフレームのシーケンスを受信するように構成される。本例では、センサは、画像センサ（例えば、ビデオカメラ）を含み、メディアフレームは、未処理映像フレームを含む。しかしながら、他の実施形態では、センサは任意の他の好適なセンサを含む。
【００３９】
この文脈において、「未処理」という用語は、映像が圧縮されていないことを意味するので、各画素は、シーケンス内の他の画素及び／又は他の映像イメージとは無関係に、それぞれの数値で表される。任意の好適な映像フォーマットを用いることができる。例示的な映像フォーマットには、例えば、限定されるものではないが、ＲＡＷ８、ＲＡＷ１０、ＲＡＷ１２、ＲＡＷ１４、ＲＧＢ８８８、ＲＧＢ６５６、ＹＵＶ４４４、ＹＵＶ４２２、ＹＵＶ４２０、及びＹＵＶ４１１が含まれる。そのようなフォーマットは互いに異なり、例えば、画素深度（画素当たりのビット数）及び／又はクロマサンプリングレートが異なる。センサインタフェース４０は、任意の好適なカメラインタフェース又は複数のインタフェース、例えば、限定されるものではないが、水平／垂直同期（ＨＳＹＮＣ／ＶＳＹＮＣ）を有する様々な並列インタフェース、ＭＩＰＩのＣＳＩ−２、ＭＩＰＩのＣＳＩ−３、又は任意の他のインタフェースなどをサポートしてよい。開示された技術は、未処理映像に限定されず、任意の映像フォーマットに適用可能である。さらに、開示された技術は映像に限定されず、上述したように、様々な他のタイプのメディアに適用可能である。
【００４０】
様々な実施形態において、センサインタフェース４０は、直列ビットストリーム又は並列ワードストリームとして映像を受信する。ＭＵＸ４４は、状況に応じて、映像フレームをメディア／ｅｂｕｆ変換器４８又はメディアエンコーダ５２に経路設定する。通常、メディアエンコーダ５２は、映像がメディア／イーサネット変換器から出て行く前に圧縮される場合に用いられる。メディア／ｅｂｕｆ変換器４８は、そうでない場合、すなわち、未処理映像が圧縮されずに送信される場合に用いられる。
【００４１】
通常、メディア／ｅｂｕｆ変換器４８は、いくつかの可能性のあるフォーマットのうちの１つに準拠する受信メディアを、イーサネット段２８の弾性バッファ（ｅｂｕｆ）６０の入力部において期待される固定フォーマットに変換するように構成される。メディア／ｅｂｕｆ変換器４８は通常、センサ固有の入力インタフェースを有する。未処理映像の場合、例えば、入力インタフェースは、８ビット、１０ビット、１２ビット、又は１６ビットの画素データに、垂直同期情報及び水平同期情報（例えば、ｖ＿ｓｙｎｃ、ｈ＿ｂｌａｎｋ）を規定する側波帯信号を加えたものを含んでよい。同期情報は、各映像フレームの開始及び終了、並びにフレーム内の各映像ラインの開始及び終了を定める。この同期情報も、画素データに符号化されてよい。
【００４２】
いくつかの実施形態において、メディア／ｅｂｕｆ変換器４８の出力がｅｂｕｆ６０に供給される。ｅｂｕｆ６０の入力におけるフォーマットは、通常、センサに依存しない。一実施形態において、ｅｂｕｆ６０への入力は、３２ビットデータに、４ビットのバイト有効情報及び４ビットの側波帯情報を足したものを含む。側波帯情報によって、映像フレーム、映像ライン、及び／又は映像単位の開始及び終了などのイベントが信号で伝えられる。メディア／ｅｂｕｆ変換器４８は、受信画素情報を収集し、入力側波帯信号又は画素データから同期情報を（入力インタフェースプロトコルに応じて）得て、ｅｂｕｆ６０が期待するように、バイト有効情報及び４ビットの側波帯情報が付けられた３２ビットグループにデータを構築する。映像／ｅｂｕｆ変換器４８は通常、用途及びセンサタイプに固有である。メディア／ｅｂｕｆ変換器４８の出力は通常、用途及びセンサタイプに関係なく、同じフォーマットを有する。したがって、イーサネット段２８及びそのコンポーネントの設計は、センサ及びメディアタイプとは関係ない。
【００４３】
メディアエンコーダ５２又はメディア／ｅｂｕｆ変換器４８の出力は、メディア入力段２４の出力としてＭＵＸ５６を介して供給される。ＭＵＸ５６の制御が、以下の図２で詳細に取り上げられる。一実施形態において、メディア入力段２４は、映像フレーム間の境界又はメディアフレーム内の他の好適な境界で映像ストリームを解析し、フレーム開始（ＳＯＦ）マーカー及びフレーム終了（ＥＯＦ）マーカーなどの好適なフレームマーカーを挿入する。他の実施形態では、例えば、フレーム化されていないメディア（例えば、ストリーミングメディア、又はセンサからの散発的データ）をパケット化する場合、任意の他の好適な方式が、メディア又はデータを解析してパケットにするのに用いられ得る。
【００４４】
映像に適用可能な映像フォーマットがネットワーク抽象化層ユニット（ＮＡＬＵ）をＨ．２６４圧縮映像などに含む場合、フレームマーカーは、ＮＡＬＵ開始（ＳＯＮ）マーカー及びＮＡＬＵ終了（ＥＯＮ）マーカーを含んでよい。圧縮後に、映像フレーム及びＮＡＬＵは、可変長を有する。１５００バイトまでのイーサネットパケットは通常、完全な映像フレームを搬送するには小さすぎる。未処理（非圧縮）映像の場合、イーサネットパケットは通常、１つの映像ライン又は何分の１かのラインを搬送する。そのような実施形態では、ＳＯＮ／ＥＯＮマーカーが、ライン開始／ライン終了のインジケーションとしての機能を果たす。Ｈ．２６４圧縮映像の場合、例えば、メディアエンコーダ５２が通常、１つのイーサネットパケットに収まるサイズのＮＡＬＵを作り出すように構成される。これらの実施形態では、ＳＯＮ／ＥＯＮマーカーが、ＮＡＬＵ開始及びＮＡＬＵ終了のインジケーションとしての機能を果たす。
【００４５】
いくつかの実施形態において、センサインタフェース４０は、イーサネットパケットに変換するために、１つ又は複数の他のセンサからメディアコンテンツを、映像フレームに対して代替的に又は追加的に受信する。例示的なセンサタイプ及びコンテンツには、限定されることはないが、速度センサ及び速度データ、加速度計及び加速度データ、音声センサ及び音声データ、赤外線センサ及び赤外線データ、レーダーセンサ及びレーダーデータ、ライダーセンサ及びライダーデータ、超音波センサ及び超音波データ、並びに距離測定器及び衝突防止データや用途にあるような近接データなどが含まれる。
【００４６】
いくつかの実施形態において、メディア入力段２４は、メディア／イーサネット変換器２０の残りの部分とは別に、例えば、スタンドアロンの半導体ダイ又はスタンドアロンデバイスに実装される。追加的に又は代替的に、いくつかの実施形態では、イーサネット段２８は、メディア入力段２４及び／又はＣＰＵ３６から分離したスタンドアロンのダイに実装される。一実施形態において、メディア入力段２４、イーサネット段２８、及びＣＰＵ３６は、一体化パッケージに一緒にパッケージ化されるか、又は回路基板にそれぞれ配置されて共に結合される。代替実施形態において、メディア入力段２４、イーサネット段２８、及びＣＰＵ３６は、分離したモジュールとして形成され、同じ集積回路基板に配置される。
【００４７】
そのような実装例によって、例えば、メディア／イーサネット変換器２０がモジュール式に製造されて、例えば、イーサネット段２８は同じだが異なるバリエーションのメディア入力段２４を用いて、異なるホストシステムに適合させることが可能になる。異なるバリエーションのメディア入力段２４は、例えば、サポートするセンサタイプ及び／又はメディアフォーマットの点で互いに異なってよい。
【００４８】
メディア入力段２４からの（本例の映像コンテンツにおける）メディアコンテンツは、イーサネット段２８に供給される。いくつかの実施形態において、イーサネット段２８は、弾性バッファ（ｅｂｕｆ）６０、パケット化器６４、及びイーサネットメディアアクセス制御（ＭＡＣ）エンジン８４を含む。
【００４９】
弾性バッファ（ｅｂｕｆ）６０は、メディア入力段２４により供給される映像ストリーム（使われていればフレームマーカーを含む）をバッファリングする。ｅｂｕｆ６０は、レートのばらつきと、メディア入力段２４の出力のバーストとを補償する。メディア入力段２４の出力でバーストが生じるのは、例えば、映像がメディアエンコーダ５２によって符号化されているときであり、メディアエンコーダは通常、コードワード間に休止期間を設けて、一度に１つのコードワードを出力する。ｅｂｕｆ６０のサイズは通常、何分の１かの映像フレームと同等である。
【００５０】
いくつかの実施形態において、弾性バッファ６０のサイズは通常、メディア入力段２４（そのクロックは通常、センサの画素クロックと同期している）とイーサネット段２８（そのクロック速度は通常、ネットワーク速度（例えば、１Ｇｂ／ｓ又は１００Ｍｂ／ｓ）に依存している）との間のクロック速度の差に関する最悪の推定から導かれる。
【００５１】
パケット化器６４は、以下で詳細に説明されるように、メディアフレームのシーケンスをイーサネットパケットのシーケンスに変換する。本開示の全体にわたり且つ実用新案登録請求の範囲において、「フレーム」と「パケット」という用語の間の区別は明確に行われる。「フレーム」という用語は、メディア／イーサネット変換器２０に入るメディア（例えば、映像）のメディアプロトコルの構造データ単位のことを指す。「パケット」という用語は、データネットワークを通じた通信に用いられるネットワーク通信プロトコル（例えば、イーサネット）の構造データ単位のことを指す。
【００５２】
図１の例では、パケット化器６４は、先入れ先出し式送信メモリ（ＴＸ  ＦＩＦＯ）６８と、ヘッダフォーマットセレクタ７２と、ヘッダ生成器７６と、ＭＵＸ８０とを有する。パケット化器６４の内部構造のさらなる態様が、図２で取り上げられる。パケット化器６４の処理が、以下でさらに詳細に説明される。
【００５３】
パケット化器６４により作り出されるイーサネットパケットは、イーサネットプロトコルのＭＡＣ層及びＰＨＹ層をそれぞれ実行する、イーサネットＭＡＣエンジン８４及びイーサネットＰＨＹインタフェース３２によって、イーサネットネットワーク（図には示されていない）を通じて送信される。上述したように、ＭＡＣエンジン８４は通常、特定の映像フレームに属するペイロードビットを含むイーサネットパケットのカプセル化及び出力を、この映像フレームがメディア入力段２４によって完全に受信される前に開始する。イーサネットパケットは、ネットワークを通じて、任意の好適な宛先（例えば、車両の中央コンピュータ）に送信されてよい。
【００５４】
図２は、本明細書で説明される一実施形態に従って、図１のメディア／イーサネット変換器２０に用いられるパケット化器６４の内部構造を概略的に示すブロック図である。この図は、ＴＸ  ＦＩＦＯ６８を取り囲む補助論理回路に注目している。一般的に言えば、ＴＸ  ＦＩＦＯ６８は、パケットのペイロードとして（場合によっては、関連するメタデータと共に）送信されることになるメディアコンテンツをバッファリングするのに用いられ、補助論理回路は、パケット用のヘッダを生成するための処理及び計算を行う。
【００５５】
図２の例では、パケット化器６４の補助論理回路は、ペイロードチェックサム計算モジュール８８、ヘッダテンプレートモジュール９２、パケットカウンタ９６、ＴＸパケットステートマシン（ＳＭ）１００、及びＴＸ読み出しＳＭ１０４を有する。図１に示すヘッダフォーマットセレクタ７２及びヘッダ生成器７６は、分かりやすくするために、この図には示されていない。ペイロードチェックサム計算モジュール８８及びヘッダテンプレート９２は通常、ヘッダ生成器７６の一部である。
【００５６】
ペイロードチェックサム計算モジュール８８は、現在のイーサネットパケットのペイロード全体に適用可能なチェックサムを計算する。ヘッダテンプレートモジュール９２（単に「ヘッダテンプレート」とも呼ばれる）は、現在のイーサネットパケットのヘッダフィールド値を、例えば１つ又は複数のハードウェアレジスタのビットパターンフォーマットに保持する。パケットカウンタ９６は、送信を待っているイーサネットペイロードの数を数える。０より大きいカウンタ値は、少なくとも１つのイーサネットパケットのペイロードが完成し、ＴＸ  ＦＩＦＯ６８において送信準備が整っていることを意味する。通常、ＴＸパケットＳＭ１００は、ペイロードがＴＸ  ＦＩＦＯ６８に完全に書き込まれたときに、カウンタ９６をインクリメントし、ＴＸ読み出しＳＭ１０４は、ペイロードがＭＵＸ８０を介して完全にストリーミングされたときに、カウンタ９６をデクリメントする。
【００５７】
一実施形態において、ＴＸパケットＳＭ１００の制御下で、映像コンテンツはｅｂｕｆ６０からＴＸ  ＦＩＦＯ６８に書き込まれる。ＳＭ１００も、映像ストリームを複数のイーサネットパケットに分割する。ＳＭ１００は映像ストリームをスキャンして、フレームマーカー、ラインマーカー、及び／又はＮＡＬＵマーカー（例えば、ＳＯＦ、ＥＯＦ、ＳＯＮ、ＥＯＮ）を検索する。フレームマーカーに基づいて、ＳＭ１００は、それぞれのイーサネットパケットのペイロードになるように、フレームマーカー間に映像コンテンツの一部を割り当てる。
【００５８】
通常、単一の映像フレームが、いくつかのイーサネットパケット全体に広がる複数の部分に分割されることに留意されたい。ＳＭ１００は、例えば、パケット送信に用いられるＴＣＰ又はＵＤＰなどの伝送プロトコルに従って、得られるパケットペイロードが最大伝送単位（Ｍａｘｉｍｕｍ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｕｎｉｔ：ＭＴＵ）サイズより小さい又はそれに等しいパケットを作り出すように、各部分のサイズを制限する。さらに、一実施形態において、ＳＭ１００は、新たなイーサネットパケットにおいて、新たな各映像フレーム、ライン、又はＮＡＬＵを開始する。ＳＭ１００は通常、ＴＸ  ＦＩＦＯ６８において、パケット終了（ＥＯＰ）マーカーを映像ストリームに挿入することによって、ペイロードの終了に印をつける。
【００５９】
例示的な実装例において、特定のパケットのペイロードがＭＴＵサイズに達し、ＥＯＦにもＥＯＮにも出くわすことがなかった場合、ＳＭ１００は現在のペイロードを終了し、「フラグメンテーション」フラグを設定する。ＳＭ１００は通常、ＴＸ  ＦＩＦＯ６８において、フラグメンテーションフラグを映像ストリームに挿入する。フラグメンテーションフラグは通常、ＴＸ読み出しＳＭ１０４によってＴＸ  ＦＩＦＯ６８から読み出され、ヘッダテンプレート９２に書き込まれる。ＳＭ１００は、映像ストリームのＥＯＦ又はＥＯＮの識別に応答して、現在のイーサネットパケットのペイロードも終了するので、次の映像フレーム、ライン、又はＮＡＬＵが、新たなイーサネットパケットで始まる。
【００６０】
一実施形態において、ＳＭ１００は、ペイロードチェックサム計算モジュール８８も制御する。ＳＭ１００は、ｅｂｕｆ６０からの映像コンテンツをペイロードチェックサム計算モジュール８８に書き込み、並行して、映像コンテンツをＴＸ  ＦＩＦＯ６８に書き込む。イーサネットパケットごとに、ＳＭ１００は、チェックサム計算機８８がペイロードチェックサムの計算を終えるまで待ち、その後、ＴＸ  ＦＩＦＯ６８において、チェックサム値を映像ストリームに挿入する。チェックサム値は通常、ＴＸ読み出しＳＭ１０４によってＴＸ  ＦＩＦＯ６８から抽出され、ヘッダテンプレート９２に書き込まれるので、ヘッダテンプレート９２に従って、チェックサム値がパケットヘッダに追加される。
【００６１】
一実施形態において、ＴＸ  ＳＭ１００は、イーサネットパケットごとにタイムスタンプ値も生成し、当該タイムスタンプ値をＴＸ  ＦＩＦＯ６８において映像ストリームに挿入する。任意の好適なトリガが、タイムスタンプを生成するのに用いられ得る。タイムスタンプ値は通常、ＴＸ読み出しＳＭ１０４によってＴＸ  ＦＩＦＯ６８から抽出されて、ヘッダテンプレート９２に書き込まれる。通常、ＳＭ１００はペイロード長もＴＸ  ＦＩＦＯ６８において映像ストリームに書き込み、当該ペイロード長は、ＳＭ１０４によって抽出されてヘッダテンプレートに書き込まれる。
【００６２】
一実施形態において、ＴＸ  ＳＭ１００は、ヘッダフィールド値（タイムスタンプ、ペイロードチェックサム、ペイロード長）を、ＴＸ  ＦＩＦＯ６８において映像ストリームに挿入される専用ワードで書き込む。上記の処理が完了すると、ＴＸパケットＳＭ１００は、パケットカウンタ９６をインクリメントして、別のペイロードが送信の準備を整えていることを示す。
【００６３】
ＴＸ読み出しＳＭ１０４は通常、イーサネットパケットごとに、ペイロードデータ及び関連するヘッダフィールド値（タイムスタンプ、ペイロードチェックサム、ペイロード長）をＴＸ  ＦＩＦＯ６８から読み出し、ヘッダテンプレート９２を更新し、ＭＵＸ８０を介してヘッダ及びペイロードをイーサネットＭＡＣエンジン８４に送信することを担う。したがって、ＴＸ読み出しＳＭ１０４は、ＭＵＸ５６を選択的に制御して、ヘッダ入力とペイロード入力とを交互に行うセレクタとしての機能を果たすことで、完全なイーサネットパケットを生成する。
【００６４】
一実施形態において、パケットカウンタ９６がゼロ以外の値である（少なくとも１つのペイロードがＴＸ  ＦＩＦＯ６８において準備できていることを意味する）と検出したことに応答して、ＴＸ  ＳＭ１０４は、次のイーサネットパケットの処理を開始するようトリガされる。具体的には、一実施形態において、ＳＭ１０４は次に、ＴＸ  ＦＩＦＯ６８からのヘッダフィールド値（タイムスタンプ、ペイロードチェックサム、ペイロード長）を含む専用ワードを読み出し、これらの値をヘッダテンプレート９２に追加する。ヘッダテンプレート内のチェックサムフィールドを更新する前に、ＳＭ１０４は通常、イーサネットパケットの最終チェックサム値を、ＳＭ１００により供給されるペイロードチェックサムと、場合によっては当該パケットの１つ又は複数の追加の部分的チェックサム値とに基づいて計算する。
【００６５】
いくつかの実施形態において、最終チェックサム値は、（ｉ）一定値ヘッダフィールドの部分的チェックサム（これは一定であり、ヘッダテンプレートの初期設定時に一度計算される）と、（ｉｉ）可変ヘッダフィールドの値の部分的チェックサム（タイムスタンプとヘッダ長から計算されたパケット長とに加えてペイロード長を含み、これらは、ペイロードがＴＸ  ＦＩＦＯ６８に完全に書き込まれる前には入手できない）と、（ｉｉｉ）ペイロードの部分的チェックサムとの合計である。最終チェックサムの計算は通常、例えば、クロックサイクルごとに１６ビットを累積することにより、いくつかのクロックサイクルを要する。
【００６６】
現在のイーサネットパケットがメディア／イーサネット変換器２０から出て行く準備ができている場合、ＳＭ１０４は通常、例えばＭＵＸ８０にヘッダテンプレート９２を選択するよう信号で伝えることにより、パケットのヘッダをヘッダテンプレート９２から送信させる。ヘッダを送信した後に、ＴＸ  ＳＭ１０４は、ＭＵＸ８０にＴＸ  ＦＩＦＯ６８を選択するよう信号で伝え、続いて、ペイロードをＴＸ  ＦＩＦＯからＭＵＸ８０を介して送信し始める。ペイロードのストリーミングは、ＥＯＰマーカーに達するまで続く（ＥＯＰマーカーは、ＴＸ  ＦＩＦＯ６８においてＴＸ  ＳＭ１００により映像ストリームに挿入されたものである）。パケット送信が完了すると、ＴＸ  ＳＭ１０４はパケットカウンタ９６をデクリメントする。一実施形態において、ＳＭ１０４は、パケット送信が完了すると、次のパケットの特定のヘッダフィールド（例えば、フラグメンテーションオフセット又はシーケンス番号）を更新するなどの追加の処置も行う。
【００６７】
図１及び図２に示すように、メディア／イーサネット変換器２０及びそのコンポーネント（メディア入力段２４、及びパケット化器６４を含むイーサネット段２８など）の構成は、単に分かりやすくするために示されている例示的な構成である。代替実施形態では、任意の他の好適な構成が用いられ得る。開示された技術の理解に必須ではない要素は、分かりやすくするために図から省略されている。
【００６８】
メディア／イーサネット変換器２０の様々な要素は、ハードワイヤードロジック又はプログラマブルロジックを用いるなど、専用のハードウェア又はファームウェアを用いて、例えば、特定用途向け集積回路（ＡＳＩＣ）又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）に実装されてよい。弾性バッファ６０及びＴＸ  ＦＩＦＯ６８は、任意の好適なタイプのメモリ（例えば、ランダムアクセスメモリ（ＲＡＭ））を有してよい。
【００６９】
通常、ＣＰＵ３６は、本明細書で説明された機能（例えば、ホストシステムとの通信、一般的な管理、及び／又はリアルタイムで若しくはワイヤスピードで行う必要が必ずしもない他のタスク）を実行するようソフトウェアでプログラムされている汎用プロセッサを有する。ソフトウェアは、ネットワークを通じて電子的形態でプロセッサにダウンロードされてよく、例えば、代替的に又は追加的に、非一時的な有形の媒体（磁気メモリ、光メモリ、又は電子的メモリなど）に供給及び／又は格納されてもよい。
【００７０】
図３は、本明細書で説明される一実施形態に従って、メディア／イーサネット変換の方法を概略的に示すフロー図である。本方法は、センサインタフェース４０が未処理映像を画像センサから受信する入力処理１１０から始まる。メディア入力段２４は、任意選択で、未処理映像コンテンツを符号化する。メディア入力段２４は、弾性バッファリング処理１１４において、映像コンテンツをｅｂｕｆ６０にバッファリングするために出力する。
【００７１】
解析処理１１８において、パケット化器６４は、それぞれのイーサネットパケットのペイロードとしての機能を果たすために映像の一部を割り当てる。パケット生成処理１２２において、パケット化器６４は、イーサネットパケットのヘッダを生成する。送信処理１２６において、パケット化器６４は、イーサネットパケットのヘッダ及びペイロードを、ＭＡＣエンジン８４及びＰＨＹインタフェース３２に向けてストリーミングする。
【００７２】
いくつかの実施形態において、メディア／イーサネット変換器２０は、様々なプロトコルのパケットヘッダフォーマットを選択的にサポートするように構成可能である。ヘッダフォーマット及び／又はコンテンツが互いに異なるイーサネットベースのヘッダタイプには、例えば、イーサネットＭＡＣヘッダ、ＩＰｖ４ヘッダ、ＩＰｖ６ヘッダ、ユーザデータグラムプロトコル（ＵＤＰ）ヘッダ、リアルタイムプロトコル（ＲＴＰ）ヘッダ、未処理映像フォーマット（ＲＶＦ）のＲＴＰヘッダ、オーディオビデオトランスポートプロトコル（ＡＶＴＰ）ヘッダ、ＲＶＦのＡＶＴＰヘッダ、モーションＪＰＥＧ（ＭＪＰＥＧ）ヘッダ、及び／又は他の好適なイーサネット若しくは他のプロトコルに準拠した他のヘッダが含まれる。
【００７３】
各ヘッダフォーマットは、特定のヘッダフィールド構成（例えば、タイプ、定義、ヘッダ内の位置、サイズ、及び場合によっては各ヘッダフィールドの数値）を指定する。例えば、異なるヘッダフォーマットが、そのような任意のパラメータにおいて互いに異なってもよい。様々な実施形態において、メディア／イーサネット変換器２０は、パケットヘッダフォーマットの任意の好適なサブセットを、例えば、単一のフォーマットからあらゆるフォーマットまでサポートする。ＣＰＵ３６は通常、メディア／イーサネット変換器２０によりサポートされる（１つ又は複数の）ヘッダフォーマットの定義を保持し、変換に用いられるヘッダフォーマットを有するパケット化器６４を構成する。
【００７４】
通常、ヘッダフォーマットの選択及び構成は、通常運転時ではなく、オフラインで行われる。そのような実施形態において、ＣＰＵ３６は、適切なヘッダフォーマットをヘッダフォーマットセレクタ７２にオフラインで（例えば、初期設定の際に、製造時に、又は製造後の検査時に）供給する。一実施形態において、この方式では、既定のホストシステムで動作する既定のメディア／イーサネット変換器２０が同じヘッダフォーマットを常に用いることになるが、同じタイプの異なるメディア／イーサネット変換器が、異なるヘッダフォーマットを必要とする様々なホストシステムに取り付けられて動作することができる。しかしながら、代替実施形態において、ＣＰＵ３６は、任意の好適な時間に（例えば、ホストシステムの通常運転時に）ヘッダフォーマットセレクタ７２に命令して、サポートされる複数のフォーマットの中から異なるヘッダフォーマットに切り替えてよい。
【００７５】
いずれの場合にも、ヘッダフォーマットセレクタ７２は、用いられる選択されたヘッダフォーマットを有するヘッダ生成器７６を構成する。ヘッダ生成器７６は、選択されたヘッダフォーマットに従って、イーサネットパケットのヘッダを生成する。上述したように、（図２に示す）ヘッダテンプレート９２は、パケット化器６４がイーサネットパケットごとに当該パケットのヘッダフィールドの数値を追加する１つ又は複数のハードウェアレジスタを有する。完全に追加されると、パケット化器６４は、対応するパケットペイロードが後に続くヘッダテンプレート９２のコンテンツをストリーミングする。
【００７６】
いくつかの実施形態において、ヘッダフォーマットの定義は、２つ又はそれより多くの異なるタイプのヘッダフィールドを区別する。これらの実施形態において、ヘッダ生成器７６に供給されるヘッダフォーマットは、各ヘッダフィールドのタイプを指定する。現在のイーサネットパケットのヘッダを生成するためにヘッダテンプレート９２を追加すると、ヘッダ生成器７６は、フィールドのタイプごとに別々に数値を計算する。
【００７７】
例示的な一実施形態において、ヘッダフォーマットは、ヘッダフィールドを以下のタイプに分類する。
【００７８】
「一定」型フィールド。「一定」型フィールドの数値は、イーサネットパケットのシーケンス全体にわたってヘッダ生成器７６により一定に維持される。「一定」型フィールドの例には、いくつか名前を挙げると、ＩＰバージョン、並びに送信元及び宛先のＭＡＣアドレス及びＩＰアドレスがある。いくつかの実施形態において、「一定」型フィールドの数値は、メディアコンテンツが受信される前に、例えば、ヘッダフォーマットが選択されて初期化されるオフライン時に、ヘッダテンプレート９２に設定される。
【００７９】
「インクリメント」型フィールド。「インクリメント」型フィールドの数値は、規則に従って、あるパケットから次のパケットへとヘッダ生成器７６によってインクリメントされる。当該規則も、ヘッダフォーマットに指定される。いくつかの実施形態において、必ずではないが、当該規則は、あるパケットから次のパケットへと数値が１だけ増加することを規定する。「インクリメント」型フィールドの例には、シーケンス番号がある。いくつかの実施形態において、「インクリメント」型フィールドの数値は、このパケットのペイロードが完全に利用可能になる前に、例えば、前のヘッダが送信されて、ヘッダテンプレート９２が修正可能になるとすぐに、ヘッダテンプレート９２に設定される。
【００８０】
「計算」型フィールド。「計算」型フィールドの数値は、所定の方式で（例えば、数式で）ヘッダ生成器７６により計算される。いくつかの実施形態において、必ずではないが、ヘッダ生成器７６は、それぞれのパケットのペイロードの少なくとも一部にわたって、「計算」型フィールドの数値を計算する。「計算」型フィールドの例には、チェックサムフィールド及び長さ（例えば、バイト数）フィールドがある。
【００８１】
いくつかの実施形態において、ヘッダ生成器７６は、必ずしも「インクリメント」型フィールドをパケットごとに１だけインクリメントしない。例えば、映像ラインが単一のパケットに収まらない場合、ヘッダ内の映像ライン番号フィールドが、２つ又は３つのパケットごとにのみ、１だけインクリメントされてよい。別の例として、映像フレーム番号フィールドが、当該映像フレームの最後のパケットの後で、インクリメントされてよい。ヘッダは、複数のパケット全体に広がる映像ラインのシーケンス番号も有してよく、当該シーケンス番号は、第１のパケットのラインごとに０にリセットされ、次のパケットの同じラインでインクリメントされる。
【００８２】
いくつかの実施形態において、ヘッダ生成器７６は、必ずしもペイロード全体で「計算」型フィールドを計算しない。いくつかの「計算」型フィールドは、ペイロードに全く依存しなくてもよい。１つの例は、タイムスタンプフィールドであり、ヘッダ生成器７６は、サンプリングされた高精度タイムプロトコル（Ｐｒｅｃｉｓｉｏｎ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ：ＰＴＰ）タイマ値に構成可能なオフセットを追加することにより、このフィールドを計算する。別の例が、複数のパケット全体に広がる映像ラインの「フラグメンテーションオフセット」フィールド値である。ヘッダ生成器７６は、同じ映像ラインの前のパケットのバイト数を合計することによって、そのようなフィールドを計算する。
【００８３】
計算ヘッダフィールドの別の例が、特定のイベントを示すフラグ（単一ビットフィールド）である。例えば、映像フレームの最後のパケットを示すフラグが、フレーム終了のインジケーションとライン終了のインジケーションとの一致に基づいて、ヘッダ生成器７６により計算されてよい。別の例として、ＡＶＴＰヘッダ内の「タイムスタンプ有効」（ＴＶ）フィールドが、全てのパケットに対して、又は構成レジスタにより選択される方式に従って特定のパケットに対してだけ１に設定されてよい（例えば、映像フレームの最初又は最後のパケットに対してだけＴＶ＝１）。さらに別の例として、ハードウェア機構が、エラーが検出された際に、パケットヘッダにエラーフラグを設定してよい。
【００８４】
上記に列挙されたヘッダフィールド及びヘッダフィールドタイプは、単に例として示されている。代替実施形態において、ヘッダフォーマットおよびヘッダ生成器７６は、任意の他の好適なフィールド及び／又はヘッダフィールドのタイプをサポートする。ヘッダフォーマットの事例が、ヘッダフィールドの様々なヘッダフィールドタイプへの分類を説明しながら以下の図５に示される。
【００８５】
いくつかの実施形態において、ヘッダ生成器７６は、ヘッダテンプレート９２のレジスタ内の特定のフィールドの数値を、（ｉ）ヘッダテンプレートのレジスタから既存の数値を読み出し、（ｉｉ）その既存の数値に対して何らかの計算を行い、更新値を生成し、（ｉｉｉ）更新された数値をヘッダテンプレートのレジスタに書き込むことによって設定する。例えば、「インクリメント」型フィールド、及び複数のイーサネットパケットにわたるデータに対して計算されるチェックサムなどのいくつかの「計算」型フィールドでも、そのような更新が行われる。ヘッダ生成器７６は、前のパケットのヘッダが送信された後であればいつでも、連続したイーサネットパケットの送信間で、この更新を行ってよい。
【００８６】
図４は、本明細書で説明される一実施形態に従って、パケット生成の方法を概略的に示すフロー図である。本方法は、ヘッダ生成器７６が適用可能なヘッダフォーマットをヘッダフォーマットセレクタ７２から取得する、フォーマット初期設定処理１３０から始まる。
【００８７】
値計算処理１３４において、ヘッダ生成器７６は、生成されている現在のイーサネットヘッダのヘッダフィールドに挿入される数値を計算する。上述したように、ヘッダ生成器７６は、ヘッダフォーマット内の１つ又は複数の「一定」型フィールド、「インクリメント」型フィールド、及び／又は「計算」型フィールドを識別し、そのタイプに基づいてヘッダフィールドごとに数値を計算する。
【００８８】
例えば、ヘッダフォーマットの任意の「一定」型フィールドの場合、ヘッダ生成器７６は、一定フィールド計算副処理１３８で、全てのパケットに対して同じ一定値を維持する。ヘッダフォーマットの任意の「インクリメント」型フィールドの場合、ヘッダ生成器７６は、規則に従って、インクリメントフィールド計算副処理１４２で、前のパケットの値に対して数値をインクリメントする。ヘッダフォーマットの任意の「計算」型フィールドの場合、ヘッダ生成器７６は、計算フィールド計算副処理１４６で数値を計算する。
【００８９】
ヘッダテンプレート追加処理１５０において、ヘッダ生成器７６は、ヘッダテンプレート９２のハードウェアレジスタに上記の処理１３４で計算された数値を追加する。送信処理１５４において、パケット化器６４は、イーサネットパケットのヘッダ及びペイロードを、ＭＡＣエンジン８４及びＰＨＹインタフェース３２に向けてストリーミングする。
【００９０】
図５は、本明細書で説明される一実施形態に従って、パケット１６０の例示的なヘッダフォーマットを示す図である。本例において、パケット１６０のヘッダは、ＭＡＣヘッダ１６４、その後に続くＩＰｖ４ヘッダ１６８、ＵＤＰヘッダ１７２、及びＡＶＴＰヘッダ１７６を含む。ＭＡＣヘッダ１６４はレイヤ２に対応し、他のヘッダは、例えば、レイヤ３、レイヤ４、及び／又はレイヤ５といった上位層に対応する。パケットヘッダの後に続くのは、パケットペイロードである。
【００９１】
パケット１６０のパケットヘッダ内の各「一定」型フィールドには、「ＣＯＮＳＴ」又は「Ｃ」と印がつけられている。各「インクリメント」型フィールドには、「ＩＮＣ」と印がつけられている。各「計算」型フィールドには、「ＣＡＬＣ」と印がつけられている。フラグ（「計算」型フィールドの特別ケースとみなされる）には、「Ｆ」と印がつけられている。
【００９２】
図を見て分かるように、ＭＡＣヘッダ１６４全体は「一定」型である。一方、ＩＰｖ４ヘッダ１６８は、全てのタイプのフィールドを含む。例えば、「ｖｅｒ」フィールドは、ＩＰバージョンを指定するので、一定である。「ｔｏｔａｌ＿ｌｅｎ」フィールドは、ペイロード長及びプロトコル選択から計算される「計算」型フィールドである。「ｉｐ＿ｉｄ」フィールドは、パケットごとに１だけインクリメントされる「インクリメント」型フィールドである。「ｆｌａｇｓ」フラグメンテーションオフセット（「ｆｒａｇ＿ｏｆｆｓ」）フィールドの分類は、ＩＰフラグメンテーションがサポートされているかどうかに依存する。サポートされている場合、これらのフィールドはパケットごとに計算される。サポートされていない場合、これらのフィールドは一定である。
【００９３】
ＵＤＰヘッダ１７２は、「一定」型フィールド及び「計算」型フィールドを両方とも含む。例えば、「ｕｄｐ＿ｌｅｎｇｔｈ」フィールドは、プロトコル選択により設定されるペイロード長及びヘッダ長に基づいて、パケットごとに計算される。ＡＶＴＰヘッダ１７６は、全てのタイプのフィールドを含む。例えば、「ｓｅｑｕｅｎｃｅ＿ｎｕｍ」フィールドは、パケットごとに１だけインクリメントされる「インクリメント」型フィールドである。「ａｖｔｐ＿ｔｉｍｅｓｔａｍｐ」は、計算又はサンプリングされた高精度タイムプロトコル（ＰＴＰ）タイマ値を含む「計算」型フィールドである。「ｓｔｒｅａｍ＿ｄａｔａ＿ｌｅｎｇｔｈ」は、ペイロード長から計算される「計算」型フィールドである。「ｉ＿ｓｅｑ＿ｎｕｍ」フィールド及び「ｌｉｎｅ＿ｎｕｍｂｅｒ」フィールドは、「インクリメント」型フィールドである。
【００９４】
図５に示すパケットヘッダフォーマットは、様々なタイプのパケットヘッダフィールドの用法を説明するために、単に例として示されている。代替実施形態では、任意の他の好適なパケットヘッダフォーマットが用いられ得る。
【００９５】
本明細書で説明される実施形態は主に、自動車のネットワーキング用途に対処するが、本明細書で説明される方法及びシステムは、監視用途又は偵察用途のライブビデオストリーミング、ビデオスクリーンへのライブビデオ及びオーディオのブロードキャスト、コンサートイベント又はパブリックビューイングイベント用の、ステージ上の動きとスクリーンの映像との間の遅延を低減させたパブリックアナウンスメント（ＰＡ）機器、又は任意の他の好適な用途といった他の用途にも用いられ得る。
【００９６】
上述した実施形態は例として引用されていること、且つ本考案は前述の部分に詳しく示され説明された事項に限定されないことに留意されたい。むしろ、本考案の範囲には、前述の部分に説明された様々な特徴の組み合わせ及び部分的組み合わせの両方、並びに前述の説明を読むと当業者には思い当たる、先行技術には開示されていない、それらの組み合わせ及び部分的組み合わせの変形例及び修正例が含まれる。参照により本特許出願に組み込まれる文献は、本願の不可欠な部分とみなされることになる。ただし、本明細書に明示的又は暗示的になされた定義と矛盾する形で、任意の用語がこれらの組み込まれた文献に定義されている限りにおいては、本明細書の定義だけが考慮されるべきである。
【図１】
0003231391.tif 000003
【図２】
0003231391.tif 000004
【図３】
0003231391.tif 000005
【図４】
0003231391.tif 000006
【図５】
0003231391.tif 000007
【手続補正書】
【提出日】令和2年7月29日(2020.7.29)
【手続補正１】
【補正対象書類名】実用新案登録請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【実用新案登録請求の範囲】
【請求項１】
メディアコンテンツをネットワークパケットに変換するメディアコンテンツ変換器であって、前記メディアコンテンツ変換器は、
前記メディアコンテンツを区切って、前記ネットワークパケット用のペイロードにするように構成された論理回路と、
ヘッダ生成器であって、
所定のヘッダフォーマットに従って、（ｉ）値が前記ネットワークパケットのシーケンス全体にわたって一定である１つ又は複数の一定ヘッダフィールドと、（ｉｉ）連続したネットワークパケットにおいて値がインクリメントされる１つ又は複数のインクリメントヘッダフィールドと、（ｉｉｉ）値がパケットごとに計算される１つ又は複数の計算ヘッダフィールドとが含まれるヘッダフィールドのタイプを区別し、
前記タイプに応じて、前記１つ又は複数の一定ヘッダフィールドと、前記１つ又は複数のインクリメントヘッダフィールドと、前記１つ又は複数の計算ヘッダフィールドとに前記値を設定し、
前記ヘッダフィールドに設定した前記値を追加する
ことにより、前記ネットワークパケット用のパケットヘッダを生成するように構成された、ヘッダ生成器と、
前記ヘッダ生成器からの生成された前記パケットヘッダを前記論理回路からの対応する前記ペイロードと組み合わせることにより、通信ネットワークを通じた送信のために、前記ネットワークパケットのシーケンスをストリーミングするように構成されたマルチプレクサと
を備える、メディアコンテンツ変換器。
【請求項２】
前記ヘッダ生成器は、前記メディアコンテンツが前記メディアコンテンツ変換器で受信される前に、前記１つ又は複数の一定ヘッダフィールドの前記値を追加するように構成される、請求項１に記載のメディアコンテンツ変換器。
【請求項３】
前記ヘッダ生成器は、インクリメントヘッダフィールドの前記値が、連続したネットワークパケットにおいて、規則に従ってインクリメントされることを前記ヘッダフォーマットで識別し、前記規則に従って前記インクリメントヘッダフィールドの前記値をインクリメントし、生成された前記パケットヘッダの対応する前記インクリメントヘッダフィールドにインクリメントされた前記値を挿入するように構成される、請求項１に記載のメディアコンテンツ変換器。
【請求項４】
前記ヘッダ生成器は、計算ヘッダフィールドの前記値を計算し、前記パケットヘッダを生成するときに、計算された前記値を前記計算ヘッダフィールドに挿入するように構成される、請求項１に記載のメディアコンテンツ変換器。
【請求項５】
前記ヘッダ生成器は１つ又は複数のハードウェアレジスタを有し、前記１つ又は複数のハードウェアレジスタは、生成されている現在のパケットのヘッダのヘッダフィールド用の数値を指定するビットパターンを保持するように構成される、請求項１から４のいずれか一項に記載のメディアコンテンツ変換器。
【請求項６】
前記論理回路は、前記現在のパケットの前記ヘッダを前記１つ又は複数のハードウェアレジスタから送信するよう前記マルチプレクサを切り替え、次いで、前記現在のパケットのペイロードを送信するよう前記マルチプレクサを切り替えるように構成される、請求項５に記載のメディアコンテンツ変換器。
【請求項７】
前記ヘッダ生成器は、前記１つ又は複数のハードウェアレジスタ内の、連続したネットワークパケット間の、前記ヘッダフィールドの前記値のうちの１つ又は複数を更新するように構成される、請求項５に記載のメディアコンテンツ変換器。
【請求項８】
前記メディアコンテンツ変換器はさらに、２つ又はそれより多くの異なる所定のヘッダフォーマットから前記ヘッダフォーマットを選択し、選択された前記ヘッダフォーマットを前記ヘッダ生成器に供給するように構成されたヘッダフォーマットセレクタを備える、請求項１から４のいずれか一項に記載のメディアコンテンツ変換器。
【請求項９】
前記論理回路と、前記ヘッダ生成器と、前記マルチプレクサとはハードウェア実装される、請求項１から４のいずれか一項に記載のメディアコンテンツ変換器。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００９６
【補正方法】変更
【補正の内容】
【００９６】
上述した実施形態は例として引用されていること、且つ本考案は前述の部分に詳しく示され説明された事項に限定されないことに留意されたい。むしろ、本考案の範囲には、前述の部分に説明された様々な特徴の組み合わせ及び部分的組み合わせの両方、並びに前述の説明を読むと当業者には思い当たる、先行技術には開示されていない、それらの組み合わせ及び部分的組み合わせの変形例及び修正例が含まれる。参照により本特許出願に組み込まれる文献は、本願の不可欠な部分とみなされることになる。ただし、本明細書に明示的又は暗示的になされた定義と矛盾する形で、任意の用語がこれらの組み込まれた文献に定義されている限りにおいては、本明細書の定義だけが考慮されるべきである。
（項目１）
メディアコンテンツをネットワークパケットに変換するメディアコンテンツ変換器であって、
上記メディアコンテンツを区切って、上記ネットワークパケット用のペイロードにするように構成された論理回路と、
所定のヘッダフォーマットに従って複数のヘッダフィールドにデータを追加することにより、上記ネットワークパケットのパケットヘッダを生成するように構成されたヘッダ生成器と、
上記ヘッダ生成器からの生成された上記パケットヘッダを上記論理回路からの対応する上記ペイロードと組み合わせることにより、通信ネットワークを通じた送信のために、上記ネットワークパケットのシーケンスをストリーミングするように構成されたマルチプレクサと
を備える変換器。
（項目２）
上記ヘッダ生成器は、上記ネットワークパケットの上記シーケンス全体で値が一定のヘッダフィールドを上記ヘッダフォーマットで識別し、生成された上記ヘッダの対応する上記ヘッダフィールドに一定の上記値を挿入するように構成される、項目１に記載の変換器。
（項目３）
上記ヘッダ生成器は、上記メディアコンテンツが上記変換器で受信される前に、一定の上記値を挿入するように構成される、項目２に記載の変換器。
（項目４）
上記ヘッダ生成器は、連続したネットワークパケットにおいて、規則に従って値がインクリメントされるインクリメントヘッダフィールドを上記ヘッダフォーマットで識別し、上記規則に従って上記インクリメントヘッダフィールドの上記値をインクリメントし、生成された上記ヘッダの対応する上記インクリメントヘッダフィールドにインクリメントされた上記値を挿入するように構成される、項目１に記載の変換器。
（項目５）
上記ヘッダ生成器は、値が計算される計算ヘッダフィールドを上記ヘッダフォーマットで識別し、上記計算ヘッダフィールドの上記値を計算し、上記ヘッダを生成するときに、計算された上記値を上記計算ヘッダフィールドに挿入するように構成される、項目１に記載の変換器。
（項目６）
上記ヘッダ生成器は１つ又は複数のハードウェアレジスタを有し、上記ハードウェアレジスタは、生成されている現在のパケットのヘッダのヘッダフィールド用の数値を指定するビットパターンを保持するように構成される、項目１から５のいずれかに記載の変換器。
（項目７）
上記論理回路は、上記現在のパケットの上記ヘッダを上記ハードウェアレジスタから送信するよう上記マルチプレクサを切り替え、次いで、上記現在のパケットのペイロードを送信するよう上記マルチプレクサを切り替えるように構成される、項目6に記載の変換器。
（項目８）
上記ヘッダ生成器は、上記ハードウェアレジスタ内の、連続したネットワークパケットの間の、上記ヘッダフィールドの上記値のうちの１つ又は複数を更新するように構成される、項目6に記載の変換器。
（項目９）
上記変換器はさらに、２つ又はそれより多くの異なる所定のヘッダフォーマットの中から、上記ヘッダフォーマットを選択し、選択された上記ヘッダフォーマットを上記ヘッダ生成器に供給するように構成されたヘッダフォーマットセレクタを備える、項目1から5のいずれかに記載の変換器。
（項目１０）
上記論理回路と、上記ヘッダ生成器と、上記マルチプレクサとはハードウェア実装される、項目1から5のいずれかに記載の変換器。
（項目１１）
メディアコンテンツをネットワークパケットに変換する方法であって、上記方法は、
上記メディアコンテンツを区切って、上記ネットワークパケット用のペイロードにする段階と、
所定のヘッダフォーマットに従って複数のヘッダフィールドにデータを追加することにより、上記ネットワークパケットのパケットヘッダを生成する段階と、
生成された上記パケットヘッダを対応する上記ペイロードと組み合わせることにより、通信ネットワークを通じた送信のために、上記ネットワークパケットのシーケンスを生成する段階と
を含む、方法。
（項目１２）
上記パケットヘッダを生成する段階は、上記ネットワークパケットの上記シーケンス全体で値が一定のヘッダフィールドを上記ヘッダフォーマットで識別し、生成された上記ヘッダの対応する上記ヘッダフィールドに一定の上記値を挿入する段階を含む、項目１１に記載の方法。
（項目１３）
一定の上記値を挿入する段階は、上記メディアコンテンツを受信する前に行われる、項目１２に記載の方法。
（項目１４）
上記パケットヘッダを生成する段階は、連続したネットワークパケットにおいて、規則に従って値がインクリメントされるインクリメントヘッダフィールドを上記ヘッダフォーマットで識別し、上記規則に従って上記インクリメントヘッダフィールドの上記値をインクリメントし、生成された上記ヘッダの対応する上記インクリメントヘッダフィールドにインクリメントされた上記値を挿入する段階を含む、項目１１に記載の方法。
（項目１５）
上記パケットヘッダを生成する段階は、値が計算される計算ヘッダフィールドを上記ヘッダフォーマットで識別し、上記計算ヘッダフィールドの上記値を計算し、上記ヘッダを生成するときに、計算された上記値を上記計算ヘッダフィールドに挿入する段階を含む、項目１１に記載の方法。
（項目１６）
上記パケットヘッダを生成する段階は、生成されている現在のパケットのヘッダのヘッダフィールド用の数値を指定するビットパターンを、１つ又は複数のハードウェアレジスタに保持する段階を含む、項目１１から１５のいずれかに記載の方法。
（項目１７）
上記パケットヘッダを生成する段階は、上記現在のパケットの上記ヘッダを上記ハードウェアレジスタから送信するようマルチプレクサを切り替え、次いで、上記現在のパケットのペイロードを送信するよう上記マルチプレクサを切り替える段階を含む、項目１６に記載の方法。
（項目１８）
上記パケットヘッダを生成する段階は、上記ハードウェアレジスタ内の、連続したネットワークパケット間の、上記ヘッダフィールドの上記値のうちの１つ又は複数を更新する段階を含む、項目１６に記載の方法。
（項目１９）
上記方法はさらに、２つ又はそれより多くの異なる所定のヘッダフォーマットの中から、上記ヘッダフォーマットを選択する段階を含む、項目１１から１５のいずれかに記載の方法。