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