JP2006229977A - インターネットプロトコルを用いたシリアルバスを介したデータ電送を実行するための方法及び当該方法を利用するための装置 - Google Patents

Abstract

【課題】埋め込みソフトウェア／ハードウェアアーキテクチャのＴＣＰ／ＵＤＰ／ＲＴＰ及びＩＰプロトコルレベルを分割し、ＴＣＰでなくＵＤＰ／ＲＴＰを介しリアルタイムストリーミングを実行するため、インターネットプロトコルを用いてシリアルバスを介しデータ伝送を実行する方法を提供すること。
【解決手段】本発明による装置は、シリアルバスのためのインタフェースと、前記リアルタイムクリティカルデータパケットを処理するハードウェア手段と、前記リアルタイム非クリティカルデータパケットを処理するソフトウェア手段と、前記リアルタイムクリティカルデータパケットを前記ハードウェア手段に、前記リアルタイム非クリティカルデータパケットを前記ソフトウェア手段にわたすフィルタユニットとから構成される。
【選択図】 図４

Description

本発明は、インターネットプロトコル（ＩＰ）を用いたシリアルバスを介したデータ通信を実行する技術分野に関する。より詳細には、本発明は、インターネットプロトコルを用いたシリアルバス上のリアルタイムストリーミングを実行する技術分野に関する。

インターネット上の映像ストリーミングについて、多数の高圧縮映像符号化技術が存在する。このような技術として、ＭＰＥＧ２やＭＰＥＧ４映像／音声符号化技術があげられる。他の技術としては、Ｈ．２６３、Ｈ．２６４、ＤＩＶＸ、Ｗｉｎｄｏｗｓ（登録商標） Ｍｅｄｉａ ９などがあげられる。これらの技術は、１００以上のファクタによる２５Ｈｚ＝１８４Ｍｂｉｔ／ｓでの３色カラーコンポーネントにおける８ビットの６４０×４８０画素による標準画質ストリームの圧縮を可能にし、これにより、ＤＳＬ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）モデムによるアナログ電話線を介した映像ストリーミングが可能となる。

映像チェーンの他方のエンドにおいては、すなわち、映像生成のエンドにおいては、排他的冗長性低減が利用されても、ほとんどの圧縮技術は許容されない。従って、より高いデータレートが、バスプロトコルを介したデータ通信に対してサポートされる必要がある。

約１．５Ｇｂｉｔ／ｓに対応するＨＤＳＤＩ（ＳＭＰＴＥ ２９２Ｍ）と呼ばれる業務用映像生成の分野では、１つのバス規格が存在する。また、将来的には、ますます高いレベルの高品位映像が生成され、より高いデータレートが求められる。例えば、２Ｋ映画映像では、１秒あたり２４フレームの３色カラーコンポーネントの１０ビットの１９２０×１０８０画素と音声及びメタデータにより、１．６Ｇｂｉｔ／ｓが必要となる。さらに、４Ｋ映画映像は、３８４０×２１６０の解像度が実現されようとしている。また、映画業界では、６Ｇｂｉｔ／ｓに対応する必要がある。

従ってスタジオでは、２Ｇｂｉｔ／ｓ以上のデータ伝送能力を提供するバス技術に基づく映像サーバ及びシンクのネットワークを構築することが望ましい。イーサネット（登録商標）バス技術が、これら高データレートに指定される。イーサネット（登録商標）には、１０００ＢＡＳＥ−ＳＸ、１０００ＢＡＳＥ−ＬＸ、１０００ＢＡＳＥ−ＣＸ、１０００ＢＡＳＥ−Ｔなどの１Ｇｂｉｔ／ｓデータレートを提供するいくつかの変形が存在する。さらに、光ファイバに基づく１０Ｇｂｉｔ／ｓデータレートを提供するイーサネット（登録商標）の変形が指定される。これらは、１０ＧＢＡＳＥ−ＬＸ４、１０ＧＢＡＳＥ−ＳＲ、−ＬＲ、−ＥＲ、１０ＧＢＡＳＥ−ＳＷ、−ＬＷ及び−ＥＷと呼ばれている。

イーサネット（登録商標）物理層を介した映像ストリーミングが、業務用映像制作に利用される可能性はますます高くなっている。また、各種プロトコルレイヤを有するスタック／ドライバが各種オペレーティングシステム（ＯＳ）に搭載されているため、この映像ストリーミングに対してＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）、ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）などの既にインストールされている上位レイヤを利用することが望まれる。これにより、既存の（ｏｆｆ ｔｈｅ ｓｈｅｌｆ）多数のソフトウェアツールが映像ストリームを抽出／表示又は格納／記録するため、ＴＣＰ／ＵＤＰ及びＩＰプロトコルをサポートするという効果が得られる。

ＩＰを介した映像ストリーミングのための既知のアプリケーションの大部分は、ソフトウェアベースのものである。リアルタイムストリーミングを実現するため、プリケーションを実行するプロセッサのパフォーマンスは、極めて高いものである必要がある。ＩＰパケットを処理するためのプロセッサの割込み応答時間は、イーサネット（登録商標）の物理的スピードレベル（１０００ＢＡＳＥＴ、１０ＧｂｉｔＥｔｈｅｒｎｅｔ（登録商標）（１０ＧｂＥ））の上昇に従ってより望まれるようになっている。１０ＧｂＥのＩＰパケットの処理について、現在のプロセッサは、必要とされるパフォーマンスを提供することができない。次の上位プロトコルレイヤ、特にＴＣＰを考慮すると、プロセッサは十分なパフォーマンスを有していない。

上記問題点を解決するため、本発明の課題は、埋め込みソフトウェア／ハードウェアアーキテクチャのＴＣＰ／ＵＤＰ／ＲＴＰ及びＩＰプロトコルレベルを分割し、ＴＣＰでなくＵＤＰ／ＲＴＰを介しリアルタイムストリーミングを実行するため、インターネットプロトコルを用いてシリアルバスを介しデータ伝送を実行する方法を提供することである。本提案では、タイムクリティカルＲＴＰ／ＵＤＰ／ＩＰプロトコルは、ハードウェアにより完全にサポートされ、非タイムクリティカルＴＣＰ／（ＵＤＰ）／ＩＰレベルは、埋め込みマイクロプロセッサ上でソフトウェアにより実現される。同様に、本発明は、リアルタイムストリーミングがＲＴＰの代わりに、ファイルシステムのプロシージャコールにより実行される場合に、プロトコルレベルを分割する技術に関する。

本発明による方法に用いられる装置について、当該装置がリアルタイムクリティカルデータパケットを処理するハードウェア手段と、リアルタイム非クリティカルデータパケットを処理するソフトウェア手段と、リアルタイムクリティカルデータパケットをハードウェア手段に、リアルタイム非クリティカルデータパケットをソフトウェア手段にわたすデマルチプレクサに関するフィルタ手段とを有する場合に効果的である。

さらなる効果的な実施例が、各従属クレームから明らかである。

インターネット技術が用いられる場合、フィルタアルゴリズムが次の３つの決定を行うことが特に効果的である。
１．ＩＰデータパケットが、リアルタイムクリティカルに処理される。
２．ＩＰデータパケットが、リアルタイム非クリティカルに処理される。
３．ＩＰデータパケットが、ブロックされるか、あるいは処理されない。

フィルタリング手段のための判断基準は、ＴＣＰ／ＵＤＰ／ＩＰパケットヘッダの解析により得られる。この判定は、
１．入力ＩＰデータパケットのＩＰソースアドレス、
２．入力ＩＰデータパケットのＩＰデスティネーションアドレス、
３．入力ＩＰデータパケットの「プロトコル」―フィールドのエントリ、
４．入力ＴＣＰ／ＵＤＰデータパケットのソースポート番号
５．入力ＴＣＰ／ＵＤＰデータパケットのデスティネーションポート番号、
６．入力ＴＣＰ／ＵＤＰデータパケットのリモートプロシージャコールファンクション（プログラム番号及びプロシージャ番号）、
に依存させるようにしてもよい。

このようにして、フィルタ判定に応じて、適切な処理段階にデータパケットをわたすデマルチプレクサが利用可能である。

一般に、上記フィルタ判定１）及び２）は、予見されない入力データパケットの処理をブロックするか、あるいは、「ビジー」をアクノリッジするなど、簡単な方法によりソフトウェアによりリアルタイム非クリティカルとしてアクノリッジするのに利用される。こでは、データパケットヘッダの一意的なＩＰソースアドレス及びＩＰデスティネーションアドレスに従って実行される。

本発明の実施例は、ストリーミングのためネットワーク層を使用するということである。ここでは、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）とＲＴＳＰ（Ｒｅａｌ−ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）が、ＵＤＰ／ＩＰと共に利用される。ここでは、ストリームはリアルタイム非クリティカルにＲＴＳＰにより制御され、データパケットは、リアルタイムクリティカルにＲＴＰによりストリーミングされる。あるいは、ＵＤＰ／ＩＰレイヤ及びＲＴＰレイヤは、ハードウェアアクセラレートされる必要があり、ＲＴＳＰはソフトウェア処理によりサポートすることができる。このため、フィルタ判定３）、４）及び５）が、各自の「プロトコル」フィールドの一意的エントリ、ＴＣＰ／ＵＤＰパケットのソースポート番号、ＴＣＰ／ＵＤＰパケットのデスティネーションポート番号によって、リアルタイム動作のためハードウェア処理されるべきデータパケットを決定するのに利用される。他のすべてのデータは、リアルタイム非クリティカルであり、ソフトウェアにより処理可能である。

ファイルシステムがネットワークにおけるデータアクセスを制御するのに利用される本発明の実施例では、ファイルシステムは、各タスクを実行するため実現されるいくつかのプロシージャを有する。この場合、ネットワークステーションは、プロシージャコールをハードウェア手段又はソフトウェア手段にわたすため、リアルタイムクリティカルプロシージャコールとリアルタイム非クリティカルプロシージャコールを分離するプロシージャフィルタを有することが効果的である。

このため、フィルタ判定６）が、プロシージャ「ＲＥＡＤ」と「ＷＲＩＴＥ」に従ってリアルタイムクリティカルデータパケットを決定し、それらをハードウェアにより処理するのに利用される。「ｃｒｅａｔｅ＿ｆｉｌｅ」などのプロシージャによる他のすべてのデータパケットは、ソフトウェアによりリアルタイム非クリティカルに処理することが可能である。

ソフトウェアに依存する現在知られている手段と比較して、本実施例は、リアルタイムクリティカルプロシージャとリアルタイム非クリティカルプロシージャとを区別することにより、記憶装置などへのアクセスのための必要とされるデータスループットレートを保証する。

本発明によると、ネットワークを介するなどの記憶装置とのタイムクリティカルデータストリームは、ハードウェアにより実現されるデータパスによりアクセラレートされる２Ｇｂｉｔ／ｓ以上のスループットスピードにより動作可能である。

本発明は、既存のＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ）が実現されている場合に特に有用である。

図１において、参照番号１０は、業務用ビデオカメラを示す。このカメラは、イーサネット（登録商標）バス接続１３を介し記憶装置１２と接続されている。圧縮されていない映像ストリーミングがバス接続を介し実行されるとき、１０００ＢＡＳＥ−ｘｙや１０ＧＢＡＳＥ−ｘｙなどのイーサネット（登録商標）変形の１つが利用される。これらイーサネット（登録商標）変形は、光ファイバや銅線ケーブルに基づくバス技術を有する。記憶装置は、毎秒２ギガビット以上の音声／映像データを記録することができる。

図２は、データ通信の周知のＯＳＩ／ＩＳＯ参照モデルを示す。各レイヤについて、どの具体的技術が本例において利用されているか記されている。物理層ＰＨＬは、イーサネット（登録商標）物理層である。データリンク層は、イーサネット（登録商標）ＭＡＣレイヤである。ネットワーク層ＮＬを実現するのに、インターネットプロトコル（ＩＰ）が利用される。トランスポート層のレベルでは、ＵＤＰ／ＴＣＰプロトコルが実現される。より上位のレイヤであるセッション層ＳＬ及びプレゼンテーション層ＰＲＬは、本例では指定されていない。アプリケーション層ＡＬは、ネットワークファイルシステム（ＮＦＳ）ではＲＴＰ、ＲＴＳＰ及びＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）により表されている。

図３ａは、映像ストリームの一部を伝送するイーサネット（登録商標）パケットのフォーマットを示す。映像データを含むピュアペイロードデータが、図面上部に示される。上から２番目のレベルは、ＲＴＰヘッダと最上位レベルのペイロードデータを示す。上から３番目のレベルは、ＲＴＰヘッダの前にＵＤＰヘッダを追加したＲＴＰヘッダとペイロードデータを示す。第２レベルは、ＵＤＰヘッダの前にＩＰヘッダを有する第３レベルのパケットの拡張を示す。図３の下部では、イーサネット（登録商標）パケットのデータフィールドにおいてペイロードデータ、ＩＰ−、ＵＤＰ−、ＲＴＰ−ヘッダ及びイーサネット（登録商標）ヘッダアップフロントを有する完全なイーサネット（登録商標）パケットが示される。

図３ｂは、ＲＴＰレイヤがＮＦＳのＲＰＣコールとやりとりする実施例のためのイーサネット（登録商標）パケットの対応するフォーマットを示す。

図４は、本発明による装置のソフト及びハードウェアアーキテクチャのブロック図を示す。すべてのリアルタイムクリティカル及び非クリティカルイーサネット（登録商標）データパケットが、１０ギガビットイーサネット（登録商標）媒体２０などを介し装置に到着する。参照番号２１は、イーサネット（登録商標）物理層を示す。ハードウェアにより実現される当該レイヤの後、パケットはイーサネット（登録商標）ＭＡＣハードウェア層に入る。ここで、当該装置に対してＭＡＣ識別番号フィルタリングが実行される。イーサネット（登録商標）ＭＡＣハードウェア層２２の上位には、いくつかのＦＩＦＯメモリ２３が、時間に関してイーサネット（登録商標）バス２０から装置を切断するよう配置される。受信ＲＸ−及び送信ＴＸ−ＤＭＡマシーン２４及び３３は、上位プロトコルレイヤに対しＦＩＦＯメモリ２３をそれぞれ充填することにより読み込む。

ユニット２５は、受信パスのためのＩＰ−ヘッダ、上位層ヘッダフィルタ、データパケットデマルチプレクサ、及び送信パスの場合には、データパケットマルチプレクサである。ここで、特定ポート上の所定の特定ソース／デスティネーションＩＰアドレスＩＤ＝ｘｙを有するリアルタイムクリティカルデータパケット、及び特定のリモートプロシージャの呼び出しによるファイルシステムネットワーキングのため、それはフィルタリングされる。フィルタリングに必要なすべての情報は、パケットヘッダに見つけることができる。従って、このユニットは、パケット内の各ヘッダを評価するのに必要となる。ＩＰ ＩＤは図３に示されるようなＩＰヘッダに与えられ、ＵＤＰポートは図３に示され得ようなＵＤＰヘッダに見つけられる。特定されるリアルタイムクリティカルＵＤＰパケットは、ハードウェアベースＩＰ復号化ユニット２６に提供される。次の処理段階は、ハードウェアベースＵＤＰ処理ユニット２７である。ＵＤＰレイヤの上位には、アプリケーション層３０が配置される。当該レイヤの一部は、専用のハードウェア手段により実現される。それは、ＲＴＰプロトコル用のハードウェアである。リアルタイムストリーミングがＮＦＳリモートプロシージャ呼び出しにより行われる場合、ハードウェア２８は、ＲＰＣフォーマットをサポートする。この場合、フィルタユニット２５は、ＵＤＰパケットのプログラム番号とプロシージャ番号の影響を受ける。

ユニット２５は、ＴＣＰ又はＵＤＰポートのタイム非クリティカルパケットを、これに応じたソース／デスティネーションＩＰ ＩＤ（図５では、＝ｘｙ）によりフィルタリングする。これらのパケットは、埋め込みプロセッサ３１による処理のため、ＲＡＭ３２に一時的に格納される。ここでは、ソフトウェアがＴＣＰ／（ＵＤＰ）／ＩＰプロトコル層を実現する。処理時間は、上述のリアルタイムクリティカルパケットのデータパスを介するよりかなり遅くなる。パケットの処理後、必要に応じて、アプリケーションパケットマルチプレクサ（図示せず）において、それらはタイムクリティカルパケットストリームにより多重化することができ、アプリケーション層３０に提供することができる。対象アプリケーションは、リアルタイム非クリティカルパケットと共に高速に到来するリアルタイムクリティカルパケットのマージされたストリームを最終的に実行する。

次に、他の方向、すなわち、図５に示される装置からデータを送信する方法の処理パスが説明される。再生装置（図示せず）などの接続された装置が対象となる装置の専用のソースＩＰ ＩＤによりＵＤＰを介しリアルタイムクリティカルデータを要求する場合、埋め込みプロセッサ３１は、所望のデータに対するリクエストをアプリケーション３０に送信する。当該データは、アプリケーション３０から図示されないアプリケーションパケットデマルチプレクサに提供される。当該ユニットは、データを直接ハードウェアＲＴＰ／ＲＰＣユニット２８、ＵＤＰユニット２７及びＩＰユニット２６にわたす。これらのユニットは、それぞれＲＴＰ／ＲＰＣ、ＵＤＰ及びＩＰパケット規格に従ってデータをフォーマット化する。その後、これらのパケットはパケットマルチプレクサ２５に提供され、データパケットの多重化されたストリームがハードウェアＴＸ−ＤＭＡユニット３３に送信される。次の処理ユニットはＦＩＦＯメモリ２３、イーサネット（登録商標）ハードウェアＭＡＣレイヤ２２、イーサネット（登録商標）物理層２１及び最後にイーサネット（登録商標）ケーブル２０である。

次に、同一方向のリアルタイム非クリティカルパケットの処理パスが説明される。接続されている装置（Ｗｉｎｄｏｗｓ（登録商標）／Ｌｉｎｕｘ ＰＣなど）が、対象装置からＦＴＰ／ＴＣＰを介しデータパケットをリクエストする場合、ＦＴＰ／ＴＣＰパケットリクエストが上述のように埋め込みプロセッサ３１により受信される。埋め込みプロセッサは、ＦＴＰコマンドを解釈し、所望のデータをアプリケーション３０に要求する。このデータは、アプリケーション３０からアプリケーションパケットデマルチプレクサに提供される。当該ユニットは、データをＲＡＭ３２に書き込む。埋め込みプロセッサ３１は、データからＴＣＰ／ＩＰパケットを構成し、ヘッダフィルタ及びデータパケットマルチプレクサユニット２５にデータパケットをＴＸ−ＤＭＡユニット３３に送信するよう要求する。次の処理ユニットは、ＦＩＦＯメモリ２３、イーサネット（登録商標）ＭＡＣレイヤハードウェアユニット２２、イーサネット（登録商標）物理層２１及び最後にイーサネット（登録商標）ケーブル２０である。

図５は、本発明の実施例のより詳細なブロック図を示す。図４と同一のコンポーネントには、同一の参照番号が利用される。これらのコンポーネントについては、再度の説明はされない。

受信及び送信パスが、個別に説明される。受信パスについて、高速到来するデータパケットは、時間でカップリングのため、ＦＩＦＯメモリユニット２３のＦＩＦＯメモリ４０に収集される。各種ハードウェアモジュールには設定ブロック４２が存在し、それはＦＩＦＯメモリブロックに設けられる。ＲＸデータパケットは、上述のフィルタアルゴリズムに従って、フィルタブロック２５のヘッダパーサブロック４３において処理される。リアルタイムクリティカルパケットは、リアルタイムプロトコルスタックのため、ハードウェアブロック６２のＴＸエンジン６３に直接提供される。リアルタイム非クリティカルパケットは、ＤＲＡＭタイミングとシステムタイミングとを切断するＦＩＦＯ４４に書き込みされる。ＦＩＦＯ４４からのパケットは、４チャネルＤＲＡＭコントロール４８を介しＤＲＡＭ３２に提供される。ここでは、これらのデータパケットは、プロセッサコアＰＰＣ４０５に基づくマイクロコントローラ３１により処理することができる。このプロセッサは、４チャネルＤＲＡＭコントローラ４８とそれのインタフェースポート５５を介し接続される。ＴＸエンジン６３は、リアルタイムプロトコルスタック６２のため、リアルタイムクリティカルデータパケットをハードウェア処理モジュールＭＡＣクライアント６５、ＩＰ２６及びＵＤＰ２７に提供している。これらのモジュールの内部で、各規格に従ってパケット評価が実行される。アプリケーションインタフェース６６は、ＲＴＰ又はＲＰＣ処理が特定のリアルタイムハードウェアモジュール２８において実行されるアプリケーションモジュール２９にリアルタイムクリティカルデータパケットを提供する。受信したイーサネット（登録商標）データパケットにより発信されるすべてのリアルタイム非クリティカルトピックスは、ＤＲＡＭ２４のリアルタイム非クリティカルイーサネット（登録商標）パケットの処理を担当するマイクロコントローラ３１と、アプリケーションインタフェース６１のアプリケーション処理のマイクロプロセッサコア６７との間で処理される。

送信のため、アプリケーション２９のマイクロプロセッサコア６７は、送信のため必要なすべてのモジュールを設定するマイクロコントローラ３１に送信リクエストを発信している。その後、アプリケーション２９は、ＲＴＰ／ＲＰＣモジュール２８及びアプリケーションインタフェース６１を介し、各リアルタイム規格に従ってデータパケットをフォーマット化するためのＵＤＰ２７、ＩＰ２６及びＭＡＣクライアント６５のハードウェアモジュールにそれぞれ「オンザフライ（ｏｎ−ｔｈｅ−ｆｌｙ）」にリアルタイムクリティカルデータパケットを提供する。ＲＸ−エンジン６４は、ＦＩＦＯ４５を介しスケジューリングされたデータパスマルチプレクサ４６にデータパケットを提供している。ここで、リアルタイムクリティカルデータパケットは、ＤＲＡＭ３２のマイクロコントローラ３１より提供されたリアルタイム非クリティカルデータパケットと合成され、ここで、これらのパケットはＤＲＡＭコントローラ４８によりフェッチされ、ＦＩＦＯ４７に提供される。その後、すべてのデータパケットは、タイムデカップリングのためＴＸ−ＦＩＦＯ４１に書き込まれ、イーサネット（登録商標）ＭＡＣ２２及びイーサネット（登録商標）物理層モジュール２１を介し光媒体又は銅媒体２０に送信される。

上述のＲＰＣトピックスに関して、本発明のさらなる実施例が図６を参照して説明される。

図４に示されるものと同様のデータ処理アーキテクチャは、オーディオ／ビジュアル（ＡＶ）システムなどのリアルタイムデータ処理用のアーキテクチャである。これらの領域のアプリケーションのすべてに対し、記憶装置への高速アクセスがキーとなる問題となる。ＰＣドメインのアプリケーションは高速データアクセスを有することに興味があるが、それらはまた記憶装置に関するデータセキュリティ（データ冗長性）に高い優先度を有している。従って、ＰＣドメインのデータアクセスの制御は、現状では依然としてリアルタイムに対応するものではなく、ソフトウェアにより実現される。

ＡＶリアルタイムドメインの新たなアプリケーションは、２Ｇｂｉｔ／ｓの持続的データスループットレートを求めているが、ソフトウェアによりこの高いデータスループットをサポートすることはもはや不可能である（インテリジェンスファイルシステム（ＦＳ）制御による）。

ネットワークにおけるファイルへのデータアクセスを管理するため、ＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ）と呼ばれるファイルシステムが存在する。ＮＦＳは、ＲＰＣ−、ＵＤＰ−及びＩＰ−レイヤスタックの上のネットワークにおいて利用されるＵＮＩＸ（登録商標）ベース擬似ファイルシステムであり、ＮＦＳは、一組のリモートプロシージャコールＲＰＣである。本発明の当該実施例では、ＮＦＳレイヤのプロシージャをソフトウェアによりサポートされるタスク及びハードウェアにより実現されるタスクに分割する機構を導入することが核となる。

ソフトウェア部分は、ＮＦＳプロシージャであるＲＥＡＤ及びＷＲＩＴＥを除き、ＧＥＴＡＴＴＲ、ＣＲＥＡＴＥ又はＲＥＭＯＶＥなどの「非リアルタイム」動作によりＮＦＳコントロールプロシージャを管理する（テーブル１を参照されたい）。

図６は、ＲＰＣフィルタリングの場合における図５のフィルタユニット２５の構成を示す。フィルタユニット２５は、ソフトウェアパスとハードウェアパスのための２つのテーブルを有する。これらのテーブルは、通過するプロシージャの名前を有する。ＮＦＳバージョン番号がこれらのテーブルをインデックス処理する。ＲＥＡＤ及びＷＲＩＴＥ（リアルタイムクリティカルデータストリームに基づくプロシージャ）の２つのプロシージャのみが、ＮＦＳレイヤのハードウェア部分を通過する。その他のものは、ＮＦＳレイヤのソフトウェアパスに転送される。

ソフトウェアにのみ依存する現在の既知の手段と比較して、提案される本発明は、リアルタイムクリティカルＮＦＳプロシージャとリアルタイム非クリティカルプロシージャとを区別することにより、記憶装置などへのアクセスのために必要とされる（高）データスループットレートを保証する。

本発明によると、ネットワークなどを介したＮＦＳ記憶装置とのタイムクリティカルデータストリームは、ハードウェアにより実現されるデータパスにより加速される２Ｇｂｉｔ／ｓ以上のスループット速度により動作することが可能となる。

上記実施例の各種変更が可能であり、列挙された請求項の範囲内に属するものである。

図１は、リアルタイム記憶装置に接続されたビデオカメラを示す。 図２は、データ通信のＯＳＩ／ＩＳＯ参照モデルの各レイヤを示す。 図３ａは、ＩＰ−、ＵＤＰ−及びＲＴＰ−ヘッダを含むイーサネット（登録商標）データパケットのパケットフォーマットを示す。 図３ｂは、ＩＰ−、ＵＤＰ−及びＲＰＣ−ヘッダを含むイーサネット（登録商標）データパケットのパケットフォーマットを示す。 図４は、本発明による装置のソフトウェア／ハードウェアブロック図である。 図５は、本発明による１０Ｇイーサネット（登録商標）のリアルタイム高速ストリーミングインタフェースのためのハードウェア／ソフトウェア実現形態を示す。 図６は、ＲＰＣプロトコルによるプロシージャフィルタの構成を示す。

符号の説明

１０ ビデオカメラ
１２ 記憶装置
１３ イーサネット（登録商標）バス接続
２１ イーサネット（登録商標）物理層
２２ ＭＡＣレイヤ
２３ ＦＩＦＯ
２４ ＲＸ−ＤＭＡ
２５ フィルタユニット
２６ ＩＰユニット
２７ ＵＤＰユニット
２８ ＲＴＰ／ＲＰＣユニット
３０ アプリケーション層
３１ 埋め込みプロセッサ
３２ ＲＡＭ
３３ ＴＸ−ＤＭＡユニット

Claims (7)

1. インターネットプロトコルを用いてシリアルバスを介し、リアルタイムクリティカル及び非クリティカルデータパケットを有するデータ伝送を実行する方法であって、
   前記リアルタイムクリティカルデータパケットは、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）及びＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）又はファイルシステムからのプロシージャコールの何れかに基づき伝送され、
   前記リアルタイム非クリティカルデータパケットは、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）及び／又はＵＤＰに基づき転送されることを特徴とする方法。
2. 請求項１記載の方法に用いられる装置であって、
   シリアルバスのためのインタフェースと、
   前記リアルタイムクリティカルデータパケットを処理するハードウェア手段と、
   前記リアルタイム非クリティカルデータパケットを処理するソフトウェア手段と、
   前記リアルタイムクリティカルデータパケットを前記ハードウェア手段に、前記リアルタイム非クリティカルデータパケットを前記ソフトウェア手段にわたすフィルタユニットと、
   から構成されることを特徴とする装置。
3. 請求項２記載の装置であって、
   前記フィルタユニットは、ソース又はデスティネーション装置のＩＰアドレス、データパケットのＩＰパケットタイプ及びポート番号に基づき、前記データパケットをフィルタリングする手段を有することを特徴とする装置。
4. 請求項３記載の装置であって、
   前記フィルタリングする手段は、前記データパケットがＵＤＰ及びファイルシステムからのプロシージャコールに基づき転送される場合、前記プロシージャコールのタイプに基づき前記フィルタリングを実行するプロシージャフィルタを有することを特徴とする装置。
5. 請求項４記載の装置であって、
   前記プロシージャフィルタは、前記ハードウェア手段にわたされるプロシージャコールのテーブルと、前記ソフトウェア手段にわたされるプロシージャコールのテーブルとを有することを特徴とする装置。
6. 請求項４記載の装置であって、
   前記ファイルシステムは、ＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ）であり、
   前記プロシージャコールは、リモートプロシージャコールであることを特徴とする装置。
7. 請求項５又は６記載の装置であって、
   前記ハードウェア手段にわたされる前記リモートプロシージャコールは、ＮＦＳ＿ＲＥＡＤ及びＮＦＳ＿ＷＲＩＴＥプロシージャコールであることを特徴とする装置。

Images