JP2011186797A - データ通信装置及び方法 - Google Patents

Abstract

【課題】データ通信の高速化及び信頼性向上を低コストに実現する。
【解決手段】データ通信装置１０は、複数のネットワークを介してフレームの送受信を行う通信部１１、１２と、前記通信部が前記複数のネットワークのいずれを介して受信フレームを受信したかを示す第１識別子及び／又は前記通信部が前記複数のネットワークのいずれを介して送信フレームを送信するかを示す第２識別子を記憶する記憶部１６と、前記受信フレームに対するプロトコル処理を行って前記第１識別子を記憶部１６に書き込み、記憶部１６から前記第２識別子を読み出して前記送信フレームに対するプロトコル処理を行うハードウェアプロトコル処理部１３と、前記送信フレームに対するプロトコル処理を行って前記第２識別子を記憶部１６に書き込み、記憶部１６から前記第１識別子を読み出して前記受信フレームに対するプロトコルの処理を行うソフトウェアプロトコル処理部１４と、を備える。
【選択図】図１

Description

本発明は、データ通信装置及び方法に関するものである。

インターネット通信では、ＴＣＰ／ＩＰ（Transmission Control Protocol/ Internet Protocol）が広く用いられている。ＴＣＰ／ＩＰの受信処理や送信処理は、ＣＰＵ（Central Processing Unit）で動作するソフトウェアによって実行されていたが、近年の著しいネットワーク速度の進歩に伴い、ソフトウェアにおける処理負荷が大きくなっていた。

専用ハードウェアによりＴＣＰ／ＩＰプロトコル処理を行い、ＣＰＵにおけるＴＣＰ／ＩＰのプロトコル処理を軽減し、通信処理の高速化を実現するデータ受信装置が提案されている（例えば特許文献１参照）。

このようなデータ受信装置は、リピータ、ブリッジ、スイッチングハブ、ルータなどの機器を介してネットワークに接続されるため、これらの機器が故障した場合の対策が必要となる。特に、産業用機器や社会インフラでの利用においては、これらの機器の故障によって通信路に障害をきたすことは深刻な問題となる。そのため、例えば、それぞれ異なる機器に接続される複数の通信路を用意することで、信頼性を向上させている。

通信の高速化を実現しながら、信頼性を向上させる通信装置として、ハードウェアオフロードエンジンを有するＮＩＣ（Network Interface Card）を複数備え、１つのＮＩＣが故障した場合に、別のＮＩＣにフェイルオーバーさせる通信装置が提案されている（例えば特許文献２参照）。

しかし、このような通信装置では、ハードウェアオフロードエンジンを有するＮＩＣを、通信路の数と同じ数設ける必要があり、コストが増大するという問題があった。

特開２００６−３１１４５号公報 特開２００８−２９５０４１号公報

本発明は、データ通信の高速化及び信頼性向上を低コストに実現できるデータ通信装置及び方法を提供することを目的とする。

本発明の一態様によるデータ通信装置は、複数のネットワークを介してフレームの送受信を行う通信部と、前記通信部が前記複数のネットワークのいずれを介して受信フレームを受信したかを示す第１識別子、又は前記通信部が前記複数のネットワークのいずれを介して送信フレームを送信するかを示す第２識別子を記憶する第１記憶部と、前記受信フレームに対するネットワークプロトコルの処理をハードウェア処理で行って前記第１識別子を前記第１記憶部に書き込み、前記第１記憶部から前記第２識別子を読み出して前記送信フレームに対するネットワークプロトコルの処理をハードウェア処理で行う第１処理部と、前記送信フレームに対するネットワークプロトコルの処理をソフトウェア処理で行って前記第２識別子を前記第１記憶部に書き込み、前記第１記憶部から前記第１識別子を読み出して前記受信フレームに対するネットワークプロトコルの処理をソフトウェア処理で行う第２処理部と、を備えるものである。

本発明によれば、データ通信の高速化及び信頼性向上を低コストに実現できる。

本発明の第１の実施形態に係るデータ通信装置の概略構成図である。 同第１の実施形態に係るデータ通信装置による受信処理を説明するフローチャートである。 同第１の実施形態に係るデータ通信装置による送信処理を説明するフローチャートである。 同第１の実施形態に係るデータ通信システムの概略構成図である。 ＴＯＥの構成の一例を示すブロック図である。 変形例によるデータ通信装置の概略構成図である。 本発明の第２の実施形態に係るデータ通信システムの概略構成図である。 本発明の第３の実施形態に係るデータ通信システムの概略構成図である。 ＵＯＥの構成の一例を示すブロック図である。 ＵＯＥによる受信処理を説明するフローチャートである。 本発明の第４の実施形態に係るデータ通信装置の概略構成図である。 同第４の実施形態に係るデータ通信装置による受信処理を説明するフローチャートである。 同第４の実施形態に係るデータ通信装置による送信処理を説明するフローチャートである。 同第４の実施形態に係るデータ通信システムの概略構成図である。

以下、本発明の実施の形態を図面に基づいて説明する。

（第１の実施形態）図１に本発明の第１の実施形態に係るデータ通信装置の概略構成を示す。なお、以下の説明では、各プロトコルが扱うデータの単位を、データリンク層についてはフレーム、ネットワーク層についてはパケット、トランスポート層のＴＣＰについてはセグメント、トランスポート層のＵＤＰについてはデータグラムと呼ぶ。

データ通信装置１０は、通信部（例えば、メディアアクセス制御等）１１、１２、ハードウェアプロトコル処理部１３、ソフトウェアプロトコル処理部１４、セッション情報記憶部１５、及びフレーム情報記憶部１６を備える。

通信部１１、１２はそれぞれ異なるネットワークに接続され、ネットワークからのフレーム受信及びネットワークへのフレーム送信を行う。ここで、ネットワークとは、上位層のプロトコルにＴＣＰ／ＩＰを使用できるネットワークであり、例えば、有線の規格であるギガビットＥｔｈｅｒｎｅｔ（登録商標）、１０ギガビットＥｔｈｅｒｎｅｔ、４０ギガビットＥｔｈｅｒｎｅｔ、１００ギガビットＥｔｈｅｒｎｅｔなどのＥｔｈｅｒｎｅｔ規格やＩＥＥＥ８０２．１１ｂ／ｇ／ａ／ｎで規定される無線ネットワークや、有線と無線が混在するネットワーク等である。

ハードウェアプロトコル処理部１３は、ネットワークプロトコル処理（例えば、ＴＣＰ／ＩＰのプロトコル処理）を行う専用ハードウェアであり、アプリケーション２０との間でデータの転送を行う。ハードウェアプロトコル処理部１３は、ＴＯＥ（TCP/IP Offload Engine）によって実現され、Ｅｔｈｅｒｎｅｔの処理機能と、ルーティング機能を除くＩＰｖ４（Internet Protocol Version 4）の処理機能と、ＴＣＰのデータ処理機能を有する。

ここで、Ｅｔｈｅｒｎｅｔの処理とは、Ｅｔｈｅｒｎｅｔの受信処理および送信処理をいう。Ｅｔｈｅｒｎｅｔの受信処理は、受信したＥｔｈｅｒｎｅｔフレームのＦＣＳ（Frame Check Sequence）の検算処理と、Ｅｔｈｅｒｎｅｔヘッダの宛先ＭＡＣアドレスの解析処理、送信元ＭＡＣアドレスの解析処理、上位層プロトコルを示すタイプの解析処理を含む。また、Ｅｔｈｅｒｎｅｔの送信処理は、Ｅｔｈｅｒｎｅｔヘッダの宛先ＭＡＣアドレスの設定、送信元ＭＡＣアドレスの設定、上位層プロトコルを示すタイプの設定、ＦＣＳの計算を含む。

また、ＩＰｖ４の処理は、ＩＰｖ４の受信処理とＩＰｖ４の送信処理をいう。ＩＰｖ４の受信処理は、ＩＰｖ４ヘッダのチェックサムの検算処理と、ＩＰｖ４ヘッダのバージョン、ヘッダ長、サービスタイプ、パケット長、識別子、コントロールフラグ、フラグメントオフセット、生存時間、プロトコル番号、送信元ＩＰアドレス、及び宛先ＩＰアドレスの解析と、フラグメントしたパケットのリアセンブル処理とを含む。また、ＩＰｖ４の送信処理は、ＩＰｖ４ヘッダのバージョン、ヘッダ長、サービスタイプ、パケット長、識別子、コントロールフラグ、フラグメントオフセット、生存時間、プロトコル番号、送信元ＩＰアドレス、宛先ＩＰアドレスの設定と、ＩＰｖ４ヘッダのチェックサム計算と、フラグメンテーションの処理とを含む。

ＴＣＰのデータ処理は、ＴＣＰの受信処理とＴＣＰの送信処理をいう。ＴＣＰの受信処理では、ＴＣＰヘッダの送信元ポート番号、宛先ポート番号、シーケンス番号、確認応答番号、データオフセット、コントロールフラグ、ウィンドウサイズ、及び緊急ポインタの解析と、ＴＣＰのチェックサムの検算とが行われ、既にセッションが確立している場合は、セグメントを結合してアプリケーションにデータを転送し、必要に応じて確認応答セグメントを作成して送信する。

ＴＣＰのデータ送信処理では、既にセッションが確立している場合に、必要に応じてセグメントを分割し、ＴＣＰヘッダの送信元ポート番号、宛先ポート番号、シーケンス番号、確認応答番号、データオフセット、コントロールフラグ、ウィンドウサイズ、及び緊急ポインタの設定、ＴＣＰのチェックサム計算、セグメント分割／結合処理、確認応答セグメントの送信処理が行われる。

ソフトウェアプロトコル処理部１４は、ネットワークプロトコル処理をＣＰＵ（Central Processing Unit）上で動作するソフトウェアによって実現され、ＡＲＰ（Address Resolution Protocol）処理機能、ルーティング処理機能、及びＴＣＰのセッション管理処理機能を有する。

ここで、ＡＲＰの処理機能とは、ＡＲＰの受信処理とＡＲＰの送信処理をいう。

ＡＲＰの受信処理では、ＡＲＰヘッダのハードウェアアドレスフォーマット、プロトコルアドレスフォーマット、ハードウェアアドレス長、プロトコルアドレス長、オペレーション、送信元ＭＡＣアドレス、送信元ＩＰアドレス、ターゲットＭＡＣアドレス、ターゲットＩＰアドレスのフィールドが解析され、必要に応じて応答パケットが作成される。

ＡＲＰの送信処理では、ＡＲＰヘッダのハードウェアアドレスフォーマット、プロトコルアドレスフォーマット、ハードウェアアドレス長、プロトコルアドレス長、オペレーション、送信元ＭＡＣアドレス、送信元ＩＰアドレス、ターゲットＭＡＣアドレス、及びターゲットＩＰアドレスのフィールドが設定される。

ルーティング処理機能は、宛先ＩＰアドレスと通信部１１、１２のインタフェースとの対応関係を保持するルーティングテーブルを管理し、宛先ＩＰアドレスに向けてパケットを送信する場合に、このテーブルを参照して、出力を行う通信部１１、１２のインタフェースを決定する機能である。

ＴＣＰのセッション管理処理は、ＴＣＰのセッション確立やセッション切断を行うＲＳＴフラグ、ＳＹＮフラグ、ＦＩＮフラグ等を含んだセグメントや、これらセグメントに対する応答セグメントのＴＣＰヘッダ解析処理や、ＴＣＰヘッダ設定処理を含む。

セッション情報記憶部１５は、ＴＣＰセッション情報を記憶する。そのため、ハードウェアプロトコル処理部１３とソフトウェアプロトコル処理部１４との間で、ＴＣＰセッション情報を共有することができる。ここで、ＴＣＰセッション情報とは、自装置側のＩＰアドレス及びポート番号と、相手装置側のＩＰアドレス及びポート番号とによって識別されるコネクション情報である。ＴＣＰセッション情報は、ハードウェアプロトコル処理部１３及びソフトウェアプロトコル処理部１４が協調してＴＣＰ処理を行う上で必要な、シーケンス番号、ウィンドウサイズ、ＭＡＣアドレス、セッションがどのネットワークに属するか示す識別情報などを含む。

フレーム情報記憶部１６は、受信フレームや送信フレームに関する情報を記憶する。ハードウェアプロトコル処理部１３及びソフトウェアプロトコル処理部１４の一方がフレーム情報記憶部１６に情報を書き込み、他方が当該情報を読み出すことで、ハードウェアプロトコル処理部１３とソフトウェアプロトコル処理部１４との間で、受信フレームや送信フレームに関する情報を伝達することができる。

セッション情報記憶部１５及びフレーム情報記憶部１６は、バスを介してハードウェアプロトコル処理部（ＴＯＥ）１３及びソフトウェアプロトコル処理部（ＣＰＵ）１４に接続される共有メモリにより実現できる。

次に、データ通信装置１０による受信処理を図２に示すフローチャートを用いて説明する。

（ステップＳ１０１）通信部１１、１２が、ネットワークからフレームを受信する。

（ステップＳ１０２）ハードウェアプロトコル処理部１３が、受信フレームのＥｔｈｅｒｎｅｔの受信処理、ＩＰｖ４の受信処理、及びＴＣＰの受信データ処理を行う。

（ステップＳ１０３）受信フレームがＴＣＰセグメントであり、かつ、既にセッション確立中のＴＣＰデータセグメントであるか否か判定される。受信フレームがＴＣＰセグメントであり、かつ、既にセッション確立中のＴＣＰデータセグメントである場合はステップＳ１０４に進み、それ以外の場合はステップＳ１０５に進む。

（ステップＳ１０４）ハードウェアプロトコル処理部１３が、アプリケーション２０にデータを転送する。

（ステップＳ１０５）ハードウェアプロトコル処理部１３が、受信フレームが通信部１１、１２のどちらのインタフェースにより受信されたかを示す識別子を、ソフトウェアプロトコル処理部１４に通知する。具体的には、ハードウェアプロトコル処理部１３が、前記識別子をフレーム情報記憶部１６に書き込み、ソフトウェアプロトコル処理部１４が、当該識別子をフレーム情報記憶部１６から読み出す。

（ステップＳ１０６）ソフトウェアプロトコル処理部１４が受信フレームのＴＣＰ／ＩＰ処理を行う。

（ステップＳ１０７）受信フレームが自ら送信したＳＹＮフラグを含むＴＣＰセグメントへの応答セグメントであり、処理の結果、セッションが確立した場合はステップＳ１０８に進む。受信フレームが上記以外のＴＣＰセグメントや、ＡＲＰパケット等であり、セッションが確立しなかった場合は、処理を完了する。

（ステップＳ１０８）ソフトウェアプロトコル処理部１４が、フレーム情報記憶部１６からそのセッションがどのネットワークに属するか、すなわち、どの通信部のインタフェースに属するかを読み出し、セッション情報記憶部１５に書き込む。

続いて、データ通信装置１０による送信処理を図３に示すフローチャートを用いて説明する。

（ステップＳ２０１）ハードウェアプロトコル処理部１３が、セッション情報記憶部１５に記憶されている情報を参照して、送信データがセッション確立中のＴＣＰデータであるか否か判断する。セッション確立中のＴＣＰデータの場合はステップＳ２０２に進む。送信データが、セッション確立中のＴＣＰデータでなく、ＡＲＰパケットや、ＴＣＰのセッション確立のためのＳＹＮフラグなどの含まれるＴＣＰセグメントであった場合は、ステップＳ２０３に進む。

（ステップＳ２０２）ハードウェアプロトコル処理部１３が、セッション情報記憶部１５から、セッションの属する通信部のインタフェースを示す識別子を取得する。

（ステップＳ２０３）ソフトウェアプロトコル処理部１４がハードウェアプロトコル処理部１３で処理されなかったプロトコルのＴＣＰ／ＩＰ処理を行う。

（ステップＳ２０４）ソフトウェアプロトコル処理部１４は、ルーティング処理機能を有しており、送信先のＩＰアドレスがどのネットワークセグメントに送信するべきものか、すなわち、どの通信部のインタフェースから送信するべきかを調べる。そして、ソフトウェアプロトコル処理部１４は、データ送信を行う通信部のインタフェースを示す識別子を、ハードウェアプロトコル処理部１３に通知する。具体的には、ソフトウェアプロトコル処理部１４が、前記識別子をフレーム情報記憶部１６に書き込み、ハードウェアプロトコル処理部１３が、当該識別子をフレーム情報記憶部１６から読み出す。

（ステップＳ２０５）ハードウェアプロトコル処理部１３が、ＴＣＰの送信データ処理、ＩＰｖ４の送信処理、及びＥｔｈｅｒｎｅｔの送信処理を行う。ソフトウェアプロトコル処理部１４でプロトコル処理が行われている場合、ハードウェアプロトコル処理部１３は、ソフトウェアプロトコル処理部１３により処理されなかった送信フレームのＴＣＰ／ＩＰ処理を行う。

（ステップＳ２０６）通信部１１又は１２が、フレームを相手装置へ送信する。

図４に本実施形態に係るデータ通信装置を用いたデータ通信システムの概略構成を示す。このデータ通信システムは、ビデオカメラ２１、エンコーダ２２、フラッシュメモリ２３、データ通信装置１１０、２１０、スイッチングハブ３１及び３２を備える。本システムでは、ビデオカメラ２１で撮影した映像をエンコーダ２２がエンコードし、エンコード後の映像データをデータ通信装置１１０が、複数（ここでは２つ）の通信路を介してデータ通信装置２１０に送信し、データ通信装置２１０が受信した映像データをフラッシュメモリ２３に記録する。各通信路にはスイッチングハブ３１、３２が設けられている。

データ通信装置１１０、２１０は、図１に示すデータ通信装置１０と同様のものである。データ通信装置１１０は、通信部１１に対応するＭＡＣ１１１、通信部１２に対応するＭＡＣ１１２、ハードウェアプロトコル処理部１３に対応するＴＯＥ１１３、及びソフトウェアプロトコル処理部１４に対応するＣＰＵ１１４を備える。また、データ通信装置１１０は、図１に示すデータ通信装置１０におけるセッション情報記憶部１５及びフレーム情報記憶部１６に対応する構成要素を備えるが、図４では示していない。

また、データ通信装置２１０は、通信部１１に対応するＭＡＣ２１１、通信部１２に対応するＭＡＣ２１２、ハードウェアプロトコル処理部１３に対応するＴＯＥ２１３、及びソフトウェアプロトコル処理部１４に対応するＣＰＵ２１４を備える。また、データ通信装置２１０は、図１に示すデータ通信装置１０におけるセッション情報記憶部１５及びフレーム情報記憶部１６に対応する構成要素を備えるが、図４では示していない。

エンコーダ２２は、ＴＯＥ１１３及びＣＰＵ１１４とバスを介して接続される。ＴＯＥ１１３は、異なるハードウェアで構成されるＭＡＣ１１１、１１２を介して、スイッチングハブ３１、３２とＥｔｈｅｒｎｅｔで接続されている。

エンコーダ２２は、SMPTE-259Mで定められるSD-SDI(Standard Definition Serial Digital Interface)規格やSMPTE-292Mで定められるHD-SDI(High Definition Serial Digital Interface)規格の入力端子を備えており、ビデオカメラ２１から出力されたSD-SDI信号またはHD-SDI信号をMPEG-2やH.264といった動画像符号化規格で符号化して、ＴＯＥ１１３に出力する。

フラッシュメモリ２３は、ＴＯＥ２１３及びＣＰＵ２１４とバスを介して接続される。ＴＯＥ２１３は、異なるハードウェアで構成されるＭＡＣ２１１、２１２を介して、スイッチングハブ３１、３２とＥｔｈｅｒｎｅｔで接続されている。

ＴＯＥ１１３は、２つのＭＡＣ１１１、１１２から受信したフレームをシリアライズして処理するハードウェア（シリアライザ）が搭載されている。同様に、ＴＯＥ２１３には、２つのＭＡＣ２１１、２１２から受信したフレームをシリアライズして処理するハードウェアが搭載されている。

また、図４に示すように、スイッチングハブ３１によって構成されるネットワークに割り当てられたアドレスを192.168.1.0/24、スイッチングハブ３２によって構成されるネットワークに割り当てられたアドレスを192.168.2.0/24、ＴＯＥ１１３のＭＡＣ１１１側に割り当てられたＩＰアドレスを192.168.1.1、ＭＡＣ１１２側に割り当てられたＩＰアドレスを192.168.2.1、ＴＯＥ２１３のＭＡＣ２１１側に割り当てられたＩＰアドレスを192.168.1.2、ＭＡＣ２１２側に割り当てられたＩＰアドレスを192.168.2.2とする。

本システムでは、ＴＣＰを用いてエンコーダ２２から出力された映像ストリームをフラッシュメモリ２３に送信する。まず、ＴＣＰによる転送をおこなうために、エンコーダ２２側からＴＣＰのセッション確立を行う。セッション確立を行うためには、事前に転送相手（ＴＯＥ２１３）のＭＡＣ（Media Access Control）アドレスを取得する必要がある。

ＣＰＵ１１４上で動作するソフトウェアは、転送相手のＭＡＣアドレスを取得するため、まず、相手のＩＰアドレスである192.168.1.2に対するＭＡＣアドレスを解決するためのＡＲＰ要求パケットの送信処理を行う。フレームを出力できるＭＡＣは２つあるが、ここで解決しようとしているＩＰアドレスは、ＭＡＣ１１１の属するネットワークに存在することがわかるので、ＣＰＵ１１４は、ディスクリプタを用いて、ＴＯＥ１１３に対し、Ｅｔｈｅｒｎｅｔの送信処理を行い、ＭＡＣ１１１を介してフレームを送信するよう指示する。なお、わからない場合はＭＡＣ１１１およびＭＡＣ１１２の両方からフレームを送信してもよい。

ディスクリプタは、ＴＯＥ１１３（ハードウェアプロトコル処理部１３）とＣＰＵ１１４（ソフトウェアプロトコル処理部１４）とで情報を伝達するためのインタフェースである。１つのディスクリプタのエントリは、固定長のDESCRIPTOR_TYPE、NETWORK_ID、BUFFER_ADDRESS、及びPROCESS_DONEのフィールドにより構成され、このエントリが共有メモリ上に複数配列で配置されリングバッファを形成している。ソフトウェアプロトコル処理部１４及びハードウェアプロトコル処理部１３の一方が、処理させたいディスクリプタのエントリ番号を他方の処理部に通知することで、情報の伝達を行うことができる。このディスクリプタにより、高速に動作するハードウェアプロトコル処理部１３からソフトウェアプロトコル処理部１４への指示をバッファすることもできる。

DESCRIPTOR_TYPEは、ＣＰＵからＴＯＥに対するフレーム送信指示に使われるか、又はＴＯＥからＣＰＵに対するフレーム受信指示に使われるかを示す。DESCRIPTOR_TYPEが、ＣＰＵからＴＯＥに対するフレーム送信指示の場合は、ＣＰＵが、NETWORK_IDにフレームを送信するＭＡＣの識別子を格納し、BUFFER_ADDRESSに送信フレームが記憶されている共有メモリのアドレスを格納し、PROCESS_DONEにはＣＰＵで処理が完了しているプロトコルの情報を格納する。

一方、DESCRIPTOR_TYPEが、ＴＯＥからＣＰＵに対するフレーム受信指示の場合は、ＴＯＥが、NETWORK_IDにフレームを受信したネットワークの識別子を格納し、BUFFER_ADDRESSに受信フレームが記憶されている共有メモリのアドレスを格納し、PROCESS_DONEにＴＯＥで処理が完了しているプロトコルの情報を格納する。

ＣＰＵ１１３がＡＲＰ要求パケットを送信する場合は、ＣＰＵ１１４により、ディスクリプタのDESCRIPTOR_TYPEに送信指示を示す値が格納され、NETWORK_IDにＭＡＣ１１２の属するネットワークを示す情報が格納され、BUFFER_ADDRESSに送信フレームが記憶されている共有メモリのアドレスが格納され、PROCESS_DONEにＡＲＰの処理が完了していることを示す情報が格納されている。

このようにＭＡＣ１１１から送信されたＡＲＰ要求パケットは、スイッチングハブ３１を経由して、ＭＡＣ２１１に受信される。ＴＯＥ２１３は、ＭＡＣ２１１が受信したフレームに対してＥｔｈｅｒｎｅｔの受信処理を行い、上位層プロトコルであるＡＲＰを処理するため、ディスクリプタを用いて、ＣＰＵ２１４に対して受信フレームに関する情報を伝達する。この場合、DESCRIPTOR_TYPEには受信指示を示す値が格納され、NETWORK_IDにはＭＡＣ２１１の属するネットワークを示す値が格納され、BUFFER_ADDRESSには受信フレームが記憶されている共有メモリのアドレスが格納され、PROCESS_DONEにはＥｔｈｅｒｎｅｔの処理が完了していることを示す情報が格納される。

ＣＰＵ２１４上で動作するソフトウェアは、ディスクリプタから得られた受信フレームのＡＲＰの受信処理を行い、このＡＲＰ要求に応えるため、ＡＲＰの送信処理によりＡＲＰ応答パケットを生成する。そして、ＣＰＵ２１４は、ディスクリプタを用いて、ＴＯＥ２１３に対し、Ｅｔｈｅｒｎｅｔ処理した後に、フレームを受信したネットワークを介してＡＲＰ応答パケットを送信するよう指示する。

この時、DESCRIPTOR_TYPEには送信指示を示す値が格納され、NETWORK_IDにはＡＲＰ要求パケットを受信したネットワークインタフェースであるＭＡＣ２１１を示す識別子が格納され、BUFFER_ADDRESSにはＣＰＵ２１４で生成されたＡＲＰ応答パケットが記憶されている共有メモリのアドレスが格納され、PROCESS_DONEにはＡＲＰの処理が完了したことを示す情報が格納される。これにより、ＴＯＥ２１３でＥｔｈｅｒｎｅｔの送信処理が行われ、ＭＡＣ２１１を介してＡＲＰ応答パケットが送信される。

ＴＯＥ１１３は、スイッチングハブ３１及びＭＡＣ１１１を介してフレーム（ＡＲＰ応答パケット）を受信すると、Ｅｔｈｅｒｎｅｔの受信処理を行い、ディスクリプタを用いて、ＣＰＵ１１４に受信処理を行うように指示する。ＣＰＵ１１４は、このＡＲＰ応答パケットを受信処理し、フラッシュメモリ２３に接続されているＴＯＥ２１３のＭＡＣ２１１側に付与されているＩＰアドレスに対応するＭＡＣアドレスを取得する。

このように、フレーム毎に、そのフレームを受信したネットワーク、又はフレームを送信するネットワークを、ＣＰＵ１１４、２１４とＴＯＥ１１３、２１３との間で通知することで、複数のＭＡＣと接続された１つのＴＯＥを用いて通信を行うことが可能となる。

上記のようにして得られたＭＡＣアドレスを用いて、192.168.1.1と192.168.1.2との間でセッションを確立するため、ＣＰＵ１１４上で動作するソフトウェアから、ＳＹＮフラグを含むＴＣＰセッション確立要求セグメントが、ＴＯＥ１１３及びＭＡＣ１１１を介して送信される。スイッチングハブ３１を介してＭＡＣ２１１に到達したＴＣＰセッション確立セグメントは、ＭＡＣ２１１によりフレームの受信処理が行われ、ＴＯＥ２１３によりＥｔｈｅｒｎｅｔの受信処理、ＩＰｖ４の受信処理、ＴＣＰのデータ受信処理が行われる。

そして、ＴＯＥ２１３が、ディスクリプタを用いて、受信フレームの情報をＣＰＵ２１４に通知する。ＣＰＵ２１４は、ＴＣＰのＳＹＮフラグを含むセグメントのＴＣＰヘッダ解析処理を行う。ＣＰＵ２１４は、そのＳＹＮフラグを含むセグメントが受け入れ可能な場合、ＳＹＮフラグとＡＣＫフラグを含むセグメントを生成し、ディスクリプタを用いてＴＯＥ２１３に送信フレームの情報を伝達する。ＴＯＥ２１３は、ＴＣＰデータ処理、ＩＰｖ４処理、Ｅｔｈｅｒｎｅｔ処理を行い、ＭＡＣ２１１を介してフレームを送信する。

ＳＹＮフラグ及びＡＣＫフラグを含むセグメントは、スイッチングハブ３１を介してＭＡＣ１１１で受信され、フレームの受信処理が行われる。受信フレームは、ＴＯＥ１１３によりＥｔｈｅｒｎｅｔの受信処理、ＩＰｖ４の受信処理、ＴＣＰの受信データ処理が行われる。そして、ＴＯＥ１１３が、ディスクリプタを用いて、受信フレームの情報をＣＰＵ１１４に通知する。ＣＰＵ１１４は、ＳＹＮフラグ及びＡＣＫフラグを含んだセグメントのＴＣＰヘッダ解析受信処理を行う。このセグメントが受け入れ可能でありセッションが確立されれば、ＣＰＵ１１４は、データ通信装置１１０内のセッション情報記憶部１５（図４には示さず）に、ディスクリプタに設定されているNETWORK_IDを、セッションの属するネットワークとして記録する。

さらに、ＣＰＵ１１４は、ＡＣＫフラグを含むＴＣＰセグメントを生成し、ＴＯＥ１１３及びＭＡＣ１１１を介して、フレームを送出する。このフレームがスイッチングハブ３１及びＭＡＣ２１１を介してＴＯＥ２１３で受信処理され、ディスクリプタでＣＰＵ２１４にフレームの情報が伝達される。ＣＰＵ２１４においてセッションの確立処理が行われると、ＣＰＵ２１４は、データ通信装置２１０内のセッション情報記憶部１５（図４には示さず）に、ディスクリプタに設定されているNETWORK_IDを、セッションの属するネットワークとして記録する。

同様に、ＣＰＵ１１４上で動作するソフトウェアにより、ＡＲＰを用いて、192.168.2.2に対応するＭＡＣアドレスを解決し、192.168.2.1と192.168.2.2との間でＴＣＰのセッション確立を行う。

なお、同様の方法により、エンコーダ２２側からではなく、フラッシュメモリ２３側からＴＣＰのセッション確立を行ってもよい。

上述のように、エンコーダ２２とフラッシュメモリ２３との間で２つのセッションを確立したら、エンコーダ２２は、ビデオカメラ２１からの入力データをエンコードする。ＴＯＥ１１３は、エンコーダ２２の出力データを、２つのセッションを用いてＴＣＰにより送信する。２つのセッションでは同一のデータが送信される。

ＴＯＥ１１３は、読み出したデータをＭＴＵ（Maximum Transfer Unit）から求めたＭＳＳ（Maximum Segment Size）以下の値にセグメント分割してＴＣＰの送信処理、ＩＰｖ４の送信処理、Ｅｔｈｅｒｎｅｔの送信処理を行う。なお、ＭＳＳは、ＴＣＰのオプションによりスリーウェイハンドシェイク時に伝達し合ったＭＳＳの値を用いてもよいし、Path MTU Discoveryにより求めてもよい。

送信処理を行う場合、ＴＣＰセグメントをどのネットワークから送信するかを決定する必要がある。ＴＣＰセグメントは、セッション情報記憶部１５に記憶されているセッションの属するＭＡＣから出力する。

このように、ＴＯＥ１１３が、フレーム毎ではなく、それよりも大きなデータ送信の単位で、エンコーダ２２からデータを読み出し、セッション情報からセッションの属するＭＡＣの識別子を用いて送信を行うことにより、ＣＰＵ１１４からフレーム毎に出力するネットワークを指示する必要なく、送信速度を高速化することができる。また、ＣＰＵ１１４の処理負荷を低減できる。図５に、ＴＯＥ１１３の構成の一例を示す。ＴＯＥ１１３は、送信要求受付部１２１、送信キュー部１２２、１２３、送信指示部１２４、フレーム生成部１２５、及び送信先選択部１２６を有する。

送信要求受付部１２１は、ＣＰＵ１１４やフラッシュメモリ２３からデータ送信要求を受け付ける。送信キュー部１２２、１２３は、通信部１１１、１１２のインタフェースに対応して複数設けられ、それぞれ対応する通信部から送信するデータ送信要求をキューイングする。

送信指示部１２４は、送信キュー部１２２、１２３にキューイングされた送信要求を取り出し、その要求に基づき送信指示を出力する。フレーム生成部１２５は、送信指示に基づいて送信フレームを生成する。送信先選択部１２６は、生成された送信フレームを、送出先の通信部に対応して設けられたフレームバッファ部１３１、１３２に格納する。フレームバッファ部１３１、１３２は、通信部１１１、１１２の前段に設けられ、送信先選択部１２６から出力されたフレームをバッファリングする。

送信指示部１２４は、フレームバッファ部１３１、１３２のバッファ可能な残り容量が所定のサイズを上回っているか確認し、上回っているものと上回ってないものとがある場合、上回っているものに対応する送信キュー部１２２、１２３から優先的に送信要求を取り出す。

ここで、所定のサイズとは、現在、送信指示部１２４が処理している送信要求によって生成されるフレームを遅延無く格納するために十分な容量である。これは、送信指示部１２４とフレーム生成部１２５との間、又はフレーム生成部１２５と送信先選択部１２６との間にバッファがある場合、そのバッファに保持されているフレームを先に格納する必要があるため、最低限、これらの合計のサイズがフレームバッファ部の残り容量に必要とされる。

特に、ＴＣＰのようにデータ全体のチェックサムを計算してヘッダに格納する場合、データより計算結果を先に送信する必要があるため、フレーム全体を一旦保持するバッファが途中で必要となる。このような場合は、現在、送信指示部１２４が処理している送信要求によって生成されるフレームのサイズに加え、チェックサム計算用のバッファに格納されているフレームのサイズがさらに必要となる。

このような送信要求の優先的な選択を行わないと、残り容量の少ないフレームバッファ部１３１、１３２にフレームを渡した場合、フレームバッファ部１３１、１３２の容量が空くまで、少なくとも送信先選択部１２６が待ち続けることになり、その間は、他方のＭＡＣ１１１、１１２からの送信ができなくなる。これは、一方に障害が発生したときに、他方からも送信が出来なくなることを意味し、複数の通信路で通信を行う利点を失う。ＴＯＥ１１３を、図５に示すような構成にすることで、このような問題を解決することができる。

上述のようにしてＭＡＣ１１１、１１２から送信されたＴＣＰデータセグメントは、それぞれスイッチングハブ３２、３１を経由して、ＭＡＣ２１１、２１２で受信され、ＴＯＥ２１３により受信処理され、セッション毎にフラッシュメモリ２３の別の記憶領域に書き込まれる。データの転送がすべて完了すると、データ通信装置１１０及び２１０がＦＩＮフラグを含むセグメントを送信し、ＴＣＰのセッション終了処理を行う。セッション終了が受け入れられるとセッション情報記憶部１５内のセッション情報は破棄される。

セッション終了処理後、通信路に障害が発生せず、どちらのセッションのストリームもすべて損失なくフラッシュメモリ２３に書き込まれた場合は、いずれか一方のストリームが破棄される。一方、通信路を構成する機器が故障した場合には、正常に受信されたストリームを残し、故障が発生した側のストリームが破棄される。

なお、通信路に障害が発生した場合、ＴＯＥ１１３から送信ができず、エンコーダ２２内のバッファがオーバーフローするため、フラッシュメモリ２３に書き込まれたストリームのうち、ファイルサイズの大きい方を正常に受信できたストリームと判断してもよい。

このように、本実施形態に係るデータ通信装置によれば、１つのＴＯＥ（ハードウェアオフロードエンジン）で複数の通信路を介した通信を行うことができるため、通信路での機器の故障が発生した場合にも、高速かつ損失なく映像ストリームを伝送することが可能となる。また、通信路の数だけＴＯＥを設ける必要がないため、コストを低減できる。従って、データ通信の高速化及び信頼性向上を低コストに実現できる。

上記第１の実施形態では、データ通信装置１０の通信部が複数のハードウェアによって構成される、すなわち、データ通信装置１０が２つの通信部１１、１２を備える構成について説明した。しかし、２つのネットワークの通信速度の合計が１つの通信部で処理できる範囲であれば、図６に示すように、データ通信装置１０に通信部を１つだけ設け、ＭＩＩ（Media Independent Interface）、ＧＭＩＩ（Gigabit Media Independent Interface）、ＸＧＭＩＩ（10Gigabit Media Independent Interface）等の複数のインタフェースに分岐させるハードウェアを搭載するようにしてもよい。なお、この場合は、受信したフレームをシリアライズする処理はハードウェアプロトコル処理部１３ではなく、通信部で行ってもよい。

上記第１の実施形態において、ＴＯＥ２１３が、フラッシュメモリ２３から読み出したデータを送信することもできる。

（第２の実施形態）図７に、本発明の第２の実施形態に係るデータ通信システムの概略構成を示す。本システムは、ビデオカメラ２１で撮影された映像データを複数の通信路を介して送信し、データ通信装置２１０が受信した映像データをフラッシュメモリ２３に記憶するシステムである。データ通信装置２１０は、図１に示す上記第１の実施形態に係るデータ通信装置１０、図４に示すデータ通信装置２１０と同様の構成である。図７において、図４に示す第１の実施形態と同一部分には同一符号を付して説明を省略する。

エンコーダ４１、４２は、ビデオカメラ２１から入力されたSD-SDI信号やHD-SDI信号をMPEG-2やH.264といった動画像符号化規格に符号化する。エンコーダ４１は、ＣＰＵ４３及びＴＯＥ４４に接続され、ＭＡＣ４５を介してスイッチングハブ３１とＥｔｈｅｒｎｅｔで接続されている。エンコーダ４２も同様に、ＣＰＵ４６及びＴＯＥ４７に接続され、ＭＡＣ４８を介してスイッチングハブ３１とＥｔｈｅｒｎｅｔで接続されている。ＴＯＥ４４、４７は、上記第１の実施形態と異なり、１つの通信路を介した通信を行うものである。

スイッチングハブ３１によって構成されるネットワークのアドレスは192.168.1.0/24であり、スイッチングハブ３２によって構成されるネットワークのアドレスは192.168.2.0/24であり、ＴＯＥ４４には192.168.1.1、ＴＯＥ４７には192.168.2.1、ＴＯＥ２１３のＭＡＣ２１１側には192.168.1.2、ＴＯＥ２１３のＭＡＣ２１２側には192.168.2.2とＩＰアドレスが割り当てられている。

ビデオカメラ２１で撮影され、エンコーダ４１、４２にて符号化された２つの映像ストリームは、それぞれ異なるスイッチングハブ３１、３２を介して伝送され、フラッシュメモリ２３に書き込まれる。ビデオカメラ２１からの入力信号は同一のものであるが、エンコーダ４１、４２による符号化結果は、同一のエンコーダを用いても異なることがあるため、それぞれのストリームを異なるＴＣＰコネクションで送信する。

まず、ＴＣＰによる転送をおこなうために、エンコーダ４１側とエンコーダ４２側から192.168.1.2と192.168.2.2に対するＡＲＰによるＭＡＣアドレスの解決と、ＴＣＰのセッション確立を行う。これは上記第１の実施形態と同様に、ディスクリプタとセッション情報を用いた方法で行われる。

エンコーダ４１とフラッシュメモリ２３との間でのＴＣＰセッション及びエンコーダ４２とフラッシュメモリ２３との間でのＴＣＰセッションが確立した後、エンコーダ４１及びエンコーダ４２からのデータ出力を開始し、ＴＣＰによるデータ送信を行う。

エンコーダ４１側のＴＯＥ４４でＴＣＰの送信処理、ＩＰｖ４の送信処理、Ｅｔｈｅｒｎｅｔの送信処理が行われ、ＭＡＣ４５から送信されたＴＣＰデータセグメントは、スイッチングハブ３１を介してＭＡＣ２１１で受信される。ＭＡＣ２１１でフレームの受信処理が行われ、ＴＯＥ２１３でＥｔｈｅｒｎｅｔの受信処理、ＩＰｖ４の受信処理、ＴＣＰの受信処理が行われ、フラッシュメモリ２３にデータが書き込まれる。

エンコーダ４２側のＴＯＥ４７でＴＣＰの送信処理、ＩＰｖ４の送信処理、Ｅｔｈｅｒｎｅｔの送信処理が行われ、ＭＡＣ４８から送信されたＴＣＰデータセグメントは、スイッチングハブ３２を介して、ＭＡＣ２１２で受信される。ＭＡＣ２１２でフレームの受信処理が行われ、ＴＯＥ２１３でＥｔｈｅｒｎｅｔの受信処理、ＩＰｖ４の受信処理、ＴＣＰの受信処理が行われ、フラッシュメモリ２３にデータが書き込まれる。

データの転送がすべて完了すると、エンコーダ４１、４２側及びフラッシュメモリ２３側からＦＩＮフラグを含むセグメントが送信され、ＴＣＰのセッション終了処理が行われる。セッション終了が受け入れられると、セッション情報記憶部１５内のセッション情報は破棄される。

セッション終了処理後、通信路に障害が発生せず、どちらのセッションのストリームもすべて損失なくフラッシュメモリ２３に書き込まれた場合には、いずれか一方のストリームが破棄される。一方、通信路を構成する機器が故障した場合には、正常に受信されたストリームを残し、故障が発生した側のストリームが破棄される。

また、動画像のタイムスタンプから、異なるセッションから損失した部分を補完し合い、ストリームを復元してもよい。また、同一のストリームが異なるセッションで送られる場合には、ストリームの先頭からの位置を計算し、損失した部分を補完してもよい。

このように、本実施形態では、２つのエンコーダ４１、４２を用いて冗長化を行い、エンコーダや通信路での機器の故障が発生した場合にも、データを損失させる可能性をさらに低減し、高速に映像ストリームを伝送することが可能となる。従って、データ通信の信頼性をさらに向上させることができる。

（第３の実施形態）図８に、本発明の第３の実施形態に係るデータ通信システムの概略構成を示す。本システムは、フラッシュメモリ５１に蓄積されているMPEG-2やH.264などの規格により動画像符号化された映像ストリームをデータ通信装置３１０が取り出して送信し、データ通信装置４１０が受信し、デコーダ５２がデコードして出力するシステムである。

データ通信装置３１０、４１０は、図１に示すデータ通信装置１０に対応する。データ通信装置３１０、４１０と、データ通信装置１０を比較すると、ＭＡＣ３１１、３１２、４１１、４１２は、通信部１１、１２と同様の構成になっている。また、データ通信装置３１０、４１０に設けられるフレーム情報記憶部（図示せず）は、図１に示すフレーム情報記憶部１６と同様の構成である。一方、図１に示すデータ通信装置１０のハードウェアプロトコル処理部１３、ソフトウェアプロトコル処理部１４、及びセッション情報記憶部１５に対応するデータ通信装置３１０、４１０内の構成要素は、その構成や動作が異なる。

本実施形態において、ハードウェアプロトコル処理部１３は、ＵＯＥ（UDP/IP Offload Engine）３１３、４１３によって実現され、Ｅｔｈｅｒｎｅｔの処理機能と、ルーティング機能を除くＩＰｖ４の処理機能と、ＵＤＰのデータ処理機能と、ＵＤＰのペイロードに格納されるユーザ定義プロトコルの処理機能とを有する。

Ｅｔｈｅｒｎｅｔの処理機能とＩＰｖ４の処理機能は上記第１の実施形態と同様である。ＵＤＰのデータ処理機能は、ＵＤＰのデータ受信処理と、ＵＤＰのデータ送信処理をいう。ＵＤＰのデータ受信処理では、ＵＤＰヘッダの宛先ポート番号、送信元ポート番号、パケット長の解析、及びＵＤＰのチェックサム計算が行われる。ＵＤＰのデータ送信処理では、ＵＤＰヘッダの宛先ポート番号、送信元ポート番号、パケット長の設定と、ＵＤＰのチェックサム計算とが行われる。

ユーザ定義プロトコルの処理は、ユーザ定義プロトコルの受信処理、及びユーザ定義プロトコルの送信処理をいう。ユーザ定義プロトコルの受信処理では、後述するフォーマットで定義されるユーザ定義プロトコルのシーケンス番号が解析され、シーケンス番号と対応付けてチェックサムの正しいデータがアプリケーションに転送される。ユーザ定義プロトコルの送信処理では、アプリケーションから指定されたデータが必要に応じて分割され、分割されたデータ毎にシーケンス番号が設定される。

ソフトウェアプロトコル処理部１４（ＣＰＵ３１４、４１４）は、ＣＰＵ上で動作するソフトウェアによって実現され、ＡＲＰ処理機能、ルーティング処理機能、及びＵＤＰのセッション管理処理機能を有する。ＵＤＰのセッション管理処理機能とは、アプリケーションからポートをオープンした場合にセッション情報を生成し、アプリケーションからポートをクローズした場合にセッション情報を破棄する機能である。なお、ソフトウェアプロトコル処理部１４は、ポートをオープンし、セッション情報を生成する際に、宛先のＩＰアドレスから、セッションがどのＭＡＣに属するかを示す識別子を設定する。

セッション情報記憶部１５（図８には示さず）は、ＵＤＰセッション情報を記憶し、ハードウェアプロトコル処理部１３とソフトウェアプロトコル処理部１４との間でのＵＤＰセッション情報の共有機能を提供する。ここで、ＵＤＰのセッション情報とは、自装置側のＩＰアドレスとポート番号、相手装置側のＩＰアドレスとポート番号、セッションがどのＭＡＣのインタフェースに属するかを示す識別子などを含む。

本実施形態に係るデータ通信装置の受信処理では、まず通信部１１、１２による受信処理により、ネットワークからフレームを受信する。次に、ハードウェアプロトコル処理部１３が受信したフレームのＥｔｈｅｒｎｅｔの受信処理、ＩＰｖ４の受信処理およびＵＤＰのデータ受信処理を行う。ここで、受信フレームがＵＤＰデータグラムであり、既にセッションが確立中であれば、ハードウェアプロトコル処理部１３によりアプリケーションにデータが転送される。

一方、セッション確立中のＵＤＰデータグラム以外であれば、ハードウェアプロトコル処理部１３からソフトウェアプロトコル処理部１４に受信フレームがどの通信部のインタフェースから受信したかを示す識別子を通知し、ソフトウェアプロトコル処理部１４により受信フレームの処理が行われる。

本実施形態に係るデータ通信装置の送信処理では、まず送信しようとするデータがセッション確立中のデータであるか否か判断される。セッション確立中のデータであった場合、セッション情報記憶部からセッションの属する通信部のインタフェースの識別子が取得され、ハードウェアプロトコル処理部１３によってユーザ定義プロトコルの送信処理、ＵＤＰのデータ送信処理、ＩＰｖ４の送信処理、及びＥｔｈｅｒｎｅｔの送信処理が行われ、通信部によってフレームが相手装置へと出力される。

一方、送信データがセッション確立中のＵＤＰデータでなく、ＡＲＰパケットであった場合には、ソフトウェアプロトコル処理部１４によりＡＲＰの送信プロトコル処理が行われる。ソフトウェアプロトコル処理部１４は、ルーティング処理機能を有しているので、送信しようとしているＩＰアドレスがどのネットワークセグメントに送信するべきものかを調べ、対応する通信部のインタフェースを示す識別子をハードウェアプロトコル処理部１３に通知する。次に、ハードウェアプロトコル処理部１３は、送信フレームのプロトコル処理を行い、通信部によりフレームをネットワークに送信する。

本実施形態に係るデータ通信システムでは、フラッシュメモリ５１は、ＵＯＥ３１３及びＣＰＵ３１４にバスを介して接続されており、ＵＯＥ３１３は２つのＭＡＣ３１１、３１２にバスを介して接続されている。ＭＡＣ３１１、３１２はそれぞれスイッチングハブ３１、３２とＥｔｈｅｒｎｅｔで接続されている。

デコーダ５２は、ＵＯＥ４１３及びＣＰＵ４１４にバスを介して接続されており、ＵＯＥ４１３は２つのＭＡＣ４１１、４１２にバスを介して接続されている。ＭＡＣ４１１、４１２はそれぞれスイッチングハブ３１、３２とＥｔｈｅｒｎｅｔで接続されている。

スイッチングハブ３１によって構成されるネットワークのアドレスは192.168.1.0/24であり、スイッチングハブ３２によって構成されるネットワークのアドレスは192.168.2.0/24であり、ＵＯＥ３１３のＭＡＣ３１１側には192.168.1.1、ＵＯＥ３１３のＭＡＣ３１２側には192.168.2.1、ＵＯＥ４１３のＭＡＣ４１１側には192.168.1.2、ＵＯＥ４１３のＭＡＣ４１２側には192.168.2.2とＩＰアドレスが割り当てられている。

本システムでは、ＵＯＥ３１３とＵＯＥ４１３との間で、192.168.1.1と192.168.1.2との間における１つのセッション、192.168.2.1と192.168.2.2との間における１つのセッションの合計２つのセッションが確立され、ＵＯＥ３１３からＵＯＥ４１３に対してＵＤＰデータグラムが伝送される。なお、本システムにおいては、同一のデータを送るセッションの識別はＵＯＥ４１３のＵＤＰポート番号が同一か否かで判断される。

ＵＯＥ３１３からＵＤＰデータグラムの送信を開始する前に、ＵＤＰデータグラムの受信を行うために、ＣＰＵ４１４でのポートをオープンし、セッション情報の作成を行い、セッションを確立状態にする。一方、ＵＯＥ３１３ではＵＯＥ４１３のＩＰアドレス192.168.1.2及び192.168.2.2のＭＡＣアドレスの解決を行う必要があるが、これは上記第１の実施形態と同様に、ＡＲＰを用いて解決する。次に、ＣＰＵ３１４でもポートをオープンし、セッション情報の作成を行う。この際、セッション情報に含まれるセッションの属するネットワークを、ＣＰＵ３１４のルーティング機能を用いて指定する。

ＵＯＥ３１３とＵＯＥ４１３でセッションを確立状態にしたら、２つのセッションを用いた伝送を開始する。フラッシュメモリ５１から読み出された映像ストリームは、ＵＯＥ３１３により高速にＵＤＰ処理され、ＭＡＣ３１１、スイッチングハブ３１、ＭＡＣ４１１（192.168.1.1と192.168.1.2）を介した通信路と、ＭＡＣ３１２、スイッチングハブ３２、ＭＡＣ４１２（192.168.2.1と192.168.2.2）を介した通信路の２つの通信路を介して、ＵＯＥ４１３に送信される。

ＵＯＥ３１３からＵＯＥ４１３に対して送信されるフレームのフォーマットは、先頭から、Ｅｔｈｅｒｎｅｔヘッダ、ＩＰｖ４ヘッダ、ＵＤＰヘッダ、シーケンス番号、データという構成になっている。シーケンス番号は３２ビットの固定長であり、以降は映像データという構成になっている。

ＵＯＥ３１３では、フラッシュメモリ５１から読み出したデータを、ＣＰＵ３１４などからセッション情報記憶部を介して指示されたＭＴＵを超えないサイズに分割し、それぞれにシーケンス番号を付加する。そして、そのシーケンス番号と分割したデータをペイロードとして、ＵＤＰのデータ送信処理、ＩＰｖ４の送信処理、Ｅｔｈｅｒｎｅｔの送信処理を行って、セッション情報記憶部をから読み出したセッションの属するＭＡＣに出力する。

この時に設定する宛先ＩＰアドレスおよび宛先ＭＡＣアドレスは、セッション情報記憶部から読み出され、ＭＡＣ３１１から送信されるフレームには、ＭＡＣ４１１のＩＰアドレス及びＭＡＣアドレスが設定され、ＭＡＣ３１２から送信されるフレームには、ＭＡＣ４１２のＩＰアドレス及びＭＡＣアドレスが設定される。

このようにすることで、フレームの送信毎にＣＰＵ３１４が送信するＭＡＣを指定することなく、セッション情報記憶部からＵＯＥ３１３がフレームを送信するＭＡＣの識別子を読み出して送信処理を行うことが可能となる。

ＵＯＥ３１３およびＵＯＥ４１３では、ＵＤＰデータグラムの宛先のポート番号によってセッションを識別し、同一の宛先ポート番号であれば同一のセッションと判別する。このため、２つのセッションのＵＤＰヘッダの宛先ポート番号には、同一のポート番号が指定される。なお、ＵＯＥ３１３は、デコーダ５２のバッファがアンダーフローしないように、一定の間隔でフラッシュメモリ５１からデータを読み出して送信する必要がある。

図９にＵＯＥ３１３の構成の一例を示す。ＵＯＥ３１３は、データ送信要求を受け付ける送信要求受付部３２１と、受け付けた送信要求をキューイングする送信キュー部３２２と、キューイングされた送信要求に基づき送信フレームを生成するフレーム生成部３２４と、送信を各通信部に渡すフレーム送信部３２５を備える。フレーム送信部３２５が、複数のＭＡＣ（通信部）３１１、３１２のうち、送信フレームを受け付け可能なＭＡＣにのみフレームを渡している間に、フレーム生成部３２４が、送信キュー部３２２へ新たにキューイングされた送信要求に基づき、新たな送信フレームを生成したとき、送信指示部３２３が、フレーム送信部３２５に対して送信中フレームの破棄を指示する。フレーム送信部３２５は、送信中フレームを破棄して、フレーム生成部３２４により生成された新たなフレームの送信を開始する。

本実施形態に係るデータ通信装置を適用しない従来のデータ通信装置では、フレーム生成部が複製して生成した各フレームを、通信部へ渡し始めると、それらのフレームの送出が完了するまで、これを継続する必要がある。このような構成では、フレーム送信部が１つ乃至複数の通信部へフレームを渡せない状況が継続すると、フレーム生成部による次のフレーム生成を停止せざるを得なくなり、結果として後続のフレームの送出が滞る。

一方、本実施形態に係るデータ通信装置は、フレーム生成部３２４によって次に送信すべきフレームの生成が完了した場合、送信指示部３２３は、フレーム送信部３２５に対して、通信部３１１、３１２に渡しているフレームの送出を中断させると共に、次に送信すべきフレームの送出を開始させる。

送信指示部３２３はフレーム送信部３２５による各フレームの送出時間を監視し、送信制限時間を超えた時に、フレーム送信部３２５に対して、フレームの送出を中断させると共に、次に送信すべきフレームの送出を開始させるようにしてもよい。

このようにデータ通信装置を構成することで、通信路が輻輳してスイッチングハブからＰａｕｓｅフレームを受けた場合や、スイッチングハブの故障やケーブルの断線などによりＭＡＣのリンクがダウンした場合など、フレーム送信部３２５が１つ乃至複数の通信部へフレームを渡せない状況に陥っても、それを破棄して次に送信すべきフレームを渡せるようになり、各フレームを滞りなく送出し続けることが可能となる。

一方、受信処理を行うＵＯＥ４１３では、２つのセッションで受信したデータを管理するため、セッション情報から参照できる形で、受信状態ビットマップを共有メモリに記憶する。受信状態ビットマップは、受信したシーケンス番号毎に、受信完了していれば１、受信未完了であれば０が設定される。全シーケンス番号のビットマップは正常受信未完了を意味する０で初期化されている。

ＵＯＥ３１３からＭＡＣ３１１、３１２を介して送信されたフレームは、スイッチングハブ３１、３２を介してＭＡＣ４１１、４１２に伝送され、フレームの受信処理が行われる。２つのＭＡＣ４１１、４１２で受信されたフレームは、ＵＯＥ４１３でシリアライズされ、プロトコル処理が行われる。

図１０に示すフローチャートを用いて、ＵＯＥ４１３で行われる受信処理を説明する。

（ステップＳ３０１）ＩＰｖ４の受信処理およびチェックサム計算を除くＵＤＰのデータ受信処理が行われ、ＵＤＰのペイロードデータグラムからユーザ定義プロトコルのシーケンス番号とデータが取得される。取得されたシーケンス番号に対応する受信状態ビットマップが読み出され、その値が受信完了を表す１であればステップＳ３０５に進む。一方、読み出された値が受信未完了を表す０であれば、ステップＳ３０２に進む。

（ステップＳ３０２）ＵＯＥ４１３は、受信したデータをメモリ（図示せず）に書き込む。

（ステップＳ３０３）ＵＯＥ４１３は、ＵＤＰのチェックサムを計算する。チェックサムが正しい場合はステップＳ３０４に進み、正しくない場合はシーケンス番号に対応するデータの受信状態を変化させず、受信未完了を表す０のままにしておく。

（ステップＳ３０４）ＵＯＥ４１３は、受信データのシーケンス番号に対応する受信状態ビットマップを、受信完了を表わす１に設定する。

（ステップＳ３０５）ＵＯＥ４１３は受信したデータグラムを破棄する。

これにより、一方の通信路にてパケットロスや障害などが発生した場合にも、他方の通信路からチェックサムの正しいデータグラムが受信できれば、正常にデータを受信することが可能となる。

このように、本実施形態に係るデータ通信装置によれば、１つのＵＯＥ（ハードウェアオフロードエンジン）を用いて複数の通信路でデータを高速に伝送することが可能となる。フラッシュメモリ５１から読み出した同一のデータを、ＵＤＰを用いて２つのセッションで伝送することで、通信路に障害が発生した場合や、通信路においてロスが発生した場合にも、２つあるインタフェースのうち、少なくともいずれか一方でチェックサムの正しいＵＤＰデータグラムが受信できればデータを受信することが可能となる。

また、通信路の数だけＵＯＥを設ける必要がないため、コストを低減できる。従って、データ通信の高速化及び信頼性向上を低コストに実現できる。

なお、パケットロスなどの損失を補償するために、フラッシュメモリ５１から読みだしたストリームに対して、ＬＤＰＣ（Low Density Parity Check）符号や、リードソロモン符号、ターボ符号などの誤り訂正符号を付加して送信し、デコーダ５２に出力する前段で誤り訂正処理を行ってもよい。

また、ＵＯＥに対してＭＡＣを２つ接続する例を示したが、信頼性を向上させるため、ＭＡＣを３つ以上に増やしてもよい。また、セッション数を３つ以上に増やして通信を行ってもよい。

また、本実施形態では、ＵＤＰデータグラムの宛先ポート番号を用いて同一セッションか否かの判定を行ったが、これは、送信元のポート番号やＩＰアドレスを用いて行ってもよいし、宛先のＩＰアドレスを用いて行ってもよいし、ＵＤＰのペイロードにセッション識別子を設けて行ってもよい。

また、本実施形態では、相手端末のＭＡＣアドレスをＡＲＰによって解決したが、これは予め固定的にＭＡＣアドレスを割り振っておき、この値を用いて通信してもよい。

（第４の実施形態）図１１に、本発明の第４の実施形態に係るデータ通信装置６０の概略構成を示す。データ通信装置６０は、通信部６１、６２、ハードウェアプロトコル処理部６３、６４、ソフトウェアプロトコル処理部６５、セッション情報記憶部６６、及びフレーム情報記憶部６７を備える。

通信部６１、６２、ソフトウェアプロトコル処理部６５は、図１に示す上記第１の実施形態における通信部１１、１２、ソフトウェアプロトコル処理部１４と同様のものである。

ハードウェアプロトコル処理部６３、６４は、ＴＯＥ（TCP/IP Offload Engine）によって実現され、Ｅｔｈｅｒｎｅｔの処理機能と、ルーティング機能を除くＩＰｖ４の処理機能と、ＴＣＰのデータ処理機能と、を有する。ハードウェアプロトコル処理部６３、６４は、設定されていない宛先ＭＡＣアドレスと宛先ＩＰアドレスのユニキャストパケットを受信するとそのパケットを破棄する。

セッション情報記憶部６６は、ＴＣＰセッション情報を記憶し、ハードウェアプロトコル処理部６３、６４とソフトウェアプロトコル処理部６５との間でＴＣＰセッション情報が共有できるようにする。ここで、ＴＣＰのセッション情報とは、自装置側のＩＰアドレスとポート番号、相手装置側のＩＰアドレスとポート番号によって識別されるコネクション情報であり、ハードウェアプロトコル処理部６３、６４とソフトウェアプロトコル処理部６５が協調してＴＣＰ処理を行う上で必要な、シーケンス番号やウィンドウサイズ、ＭＡＣアドレス、セッションがどのネットワークに属するか示す識別情報などが含まれる。

フレーム情報記憶部６７は、受信フレームや送信フレームに関する情報を記憶する。

セッション情報記憶部６６やフレーム情報記憶部６７は、ＴＯＥ及びＣＰＵにバスを介して接続される共有メモリにより実現される。

次に、データ通信装置６０の受信処理を図１２に示すフローチャートを用いて説明する。

（ステップＳ４０１）通信部６１、６２による受信処理により、ネットワークからフレームが受信される。

（ステップＳ４０２）ハードウェアプロトコル処理部６３、６４が、受信フレームのＥｔｈｅｒｎｅｔの受信処理、ＩＰｖ４の受信処理およびＴＣＰの受信データ処理を行う。

（ステップＳ４０３）受信フレームが既にセッション確立中のＴＣＰデータセグメントの場合はステップＳ４０４に進み、セッション確立中のＴＣＰデータセグメント以外の場合はステップＳ４０５に進む。

（ステップＳ４０４）ハードウェアプロトコル処理部６３、６４がアプリケーション７０にデータを転送する。

（ステップＳ４０５）ハードウェアプロトコル処理部６３、６４が、ソフトウェアプロトコル処理部６５に、どのハードウェアプロトコル処理部が受信フレームの処理を行ったか、及びどの通信部のインタフェースがフレームを受信したかを示す識別子をフレーム情報記憶部を介して通知する。

（ステップＳ４０６）ソフトウェアプロトコル処理部６５が受信フレームの処理を行う。

（ステップＳ４０７）ソフトウェアプロトコル処理部６５が処理した受信フレームが自分が送信したＳＹＮフラグを含むＴＣＰセグメントに対する応答セグメントで、処理の結果セッションが確立した場合はステップＳ４０８に進み、受信フレームが上記以外のＴＣＰセグメントや、ＡＲＰパケットなどで、セッションが確立しなかった場合は処理を完了する。

（ステップＳ４０８）セッション情報記憶部６６に、そのセッションがどのネットワークに属するか、すなわち、プロトコル処理を行うハードウェアプロトコル処理部及び送受信を行う通信部のインタフェースを示す識別情報が記憶される。

続いて、データ通信装置６０の送信処理を図１３に示すフローチャートを用いて説明する。

（ステップＳ５０１）送信しようとするデータがセッション確立中のデータであるか否か判定される。セッション確立中のＴＣＰデータである場合はステップＳ５０２に進み、送信データがセッション確立中のＴＣＰデータでなく、ＡＲＰパケットや、ＴＣＰのセッション確立のためのＳＹＮフラグの含まれるＴＣＰセグメントであった場合はステップＳ５０３に進む。

（ステップＳ５０２）セッション情報記憶部６６から、プロトコル処理を行うハードウェアプロトコル処理部１３を示す識別子及び送信処理を行う通信部のインタフェースを示す識別子が取得される。

（ステップＳ５０３）ソフトウェアプロトコル処理部６５がＴＣＰ／ＩＰ処理を行う。

（ステップＳ５０４）ソフトウェアプロトコル処理部６５は、ルーティング機能を有しているので、送信しようとしているＩＰアドレスがどのネットワークセグメントに送信するべきものかを調べ、その通信部のインタフェースを示す識別子を該当するハードウェアプロトコル処理部に通知する。

（ステップＳ５０５）ハードウェアプロトコル処理部６３又は６４が、ＴＣＰのデータ送信処理、ＩＰｖ４の送信処理およびＥｔｈｅｒｎｅｔの送信処理を行う。ソフトウェアプロトコル処理部６５でプロトコル処理が行われている場合、ハードウェアプロトコル処理部６３又は６４は、ソフトウェアプロトコル処理部６５により処理されなかった送信フレームのＴＣＰ／ＩＰ処理を行う。プロトコル処理が完了したら取得または指示されたメディアアクセス処理部にフレームを出力する。

（ステップＳ５０６）通信部６１又は６２が、送信フレームを相手装置へ出力する。

図１４に、本実施形態に係るデータ通信装置を用いたデータ通信システムの概略構成を示す。このデータ通信システムは、ビデオカメラ２１、エンコーダ２２、フラッシュメモリ２３、データ通信装置５６０、６６０、スイッチングハブ３１及び３２を備える。本システムでは、ビデオカメラ２１で撮影した映像をエンコーダ２２がエンコードし、エンコード後の映像データをデータ通信装置５６０が、複数（ここでは２つ）のスイッチングハブを介してデータ通信装置６６０に送信し、データ通信装置６６０が受信した映像データをフラッシュメモリ２３に記録する。各通信路にはスイッチングハブ３１、３２が設けられている。

データ通信装置５６０、６６０は、図１１に示すデータ通信装置６０と同様のものである。データ通信装置５６０は、通信部６１、６２に対応するＭＡＣ５６１、５６２、ハードウェアプロトコル処理部６３、６４に対応するＴＯＥ５６３、５６４、及びソフトウェアプロトコル処理部６５に対応するＣＰＵ５６５を備える。また、データ通信装置５６０は、図１１に示すデータ通信装置６０におけるセッション情報記憶部６６及びフレーム情報記憶部６７に対応する構成要素を備えるが、図１４では示していない。

また、データ通信装置６６０は、通信部６１、６２に対応するＭＡＣ６６１、６６２、ハードウェアプロトコル処理部６３、６４に対応するＴＯＥ６６３、６６４、及びソフトウェアプロトコル処理部６５に対応するＣＰＵ６６５を備える。また、データ通信装置６６０は、図１１に示すデータ通信装置６０におけるセッション情報記憶部６６及びフレーム情報記憶部６７に対応する構成要素を備えるが、図１４では示していない。

エンコーダ２２は、ＴＯＥ５６３、５６４、ＣＰＵ５６５にバスを介して接続される。エンコーダ２２は、ビデオカメラから出力されたSD-SDI信号またはHD-SDI信号をMPEG-2やH.264といった動画像符号化規格で符号化して、ＴＯＥ５６３、５６４に出力する。ＴＯＥ５６３は、異なるハードウェアで構成されるＭＡＣ５６１、５６２を介して、スイッチングハブ３１、３２とＥｔｈｅｒｎｅｔで接続されている。同様に、ＴＯＥ５６４は、ＭＡＣ５６１、５６２を介して、スイッチングハブ３１、３２とＥｔｈｅｒｎｅｔで接続されている。なお、ＴＯＥ５６３及び５６４には、２つのＭＡＣ５６１、５６２から受信したフレームをシリアライズして処理するハードウェアが搭載されている。

フラッシュメモリ２３は、ＴＯＥ６６３、６６４、ＣＰＵ６６５にバスを介して接続される。ＴＯＥ６６３は、異なるハードウェアで構成されるＭＡＣ６６１、６６２を介して、スイッチングハブ３１、３２とＥｔｈｅｒｎｅｔで接続されている。同様に、ＴＯＥ６６４は、ＭＡＣ６６１、６６２を介して、スイッチングハブ３１、３２とＥｔｈｅｒｎｅｔで接続されている。なお、ＴＯＥ６６３及び６６４には、２つのＭＡＣ６６１、６６２から受信したフレームをシリアライズして処理するハードウェアが搭載されている。

図１４に示すように、スイッチングハブ３１によって構成されるネットワークのアドレスを192.168.1.0/24と192.168.3.0/24、スイッチングハブ３２によって構成されるネットワークのアドレスを192.168.2.0/24と192.168.4.0/24とする。また、ＴＯＥ５６３のＭＡＣ５６１側には192.168.1.1を、ＴＯＥ５６３のＭＡＣ５６２側には192.168.2.1を、ＴＯＥ５６４のＭＡＣ５６１側には192.168.3.1、ＴＯＥ５６４のＭＡＣ５６２側には192.168.4.1とＩＰアドレスを割り当てる。また、ＴＯＥ６６３のＭＡＣ６６１側には192.168.1.2、ＴＯＥ６６３のＭＡＣ６６２側には192.168.2.2、ＴＯＥ６６４のＭＡＣ６６１側には192.168.3.2、ＴＯＥ６６４のＭＡＣ６６２側には192.168.4.2とＩＰアドレスを割り当てる。

本システムでは、ＴＣＰを用いてエンコーダ２２から出力された映像ストリームをフラッシュメモリ２３に送信する。まず、ＴＣＰによる転送をおこなうために、エンコーダ２２側からＴＣＰのセッション確立を行う。セッション確立を行うためには、事前に相手のＭＡＣ(Media Access Control)アドレスを取得する必要がある。

相手のＭＡＣアドレスを取得するために、まずＣＰＵ５６５上で動作するソフトウェアにより、相手のＩＰアドレスである192.168.1.2に対するＭＡＣアドレスを解決するためのＡＲＰ要求パケットの生成処理を行う。フレームを出力できるＭＡＣは２つあるが、今回解決しようとしているＩＰアドレスは、ＭＡＣ５６１の属するネットワークに存在することがわかるので、ＣＰＵ５６５はディスクリプタを用いて、ＴＯＥ５６３に対して、Ｅｔｈｅｒｎｅｔの送信処理を行い、ＭＡＣ５６１を介してフレームを送信するよう指示する。わからない場合は接続される全てのＭＡＣから出力してもよい。

本実施形態におけるディスクリプタは、上記第１の実施形態で説明したディスクリプタと同様に、DESCRIPTOR_TYPE、NETWORK_ID、BUFFER_ADDRESS、及びPROCESS_DONEのフィールドにより構成されるが、NETWORK_IDに指定される内容が異なる。DESCRIPTOR_TYPEがＣＰＵからＴＯＥに対する送信指示の場合は、ＣＰＵが、NETWORK_IDにフレームを送信するネットワークの識別子としてＭＡＣとＴＯＥの識別子を指定する。一方、DESCRIPTOR_TYPEがＴＯＥからＣＰＵに対するフレーム受信指示の場合は、ＴＯＥが、NETWORK_IDに、フレームを受信したネットワークの識別子としてＭＡＣとＴＯＥの識別子を格納する。

ＣＰＵ５６５からＡＲＰ要求パケットの送信を行う場合には、ディスクリプタのDESCRIPTOR_TYPEには、送信指示を示す値が格納され、NETWORK_IDにはＭＡＣ５６１とＴＯＥ５６３の識別子が格納され、BUFFER_ADDRESSには送信するフレームの格納されている共有メモリのアドレスが格納され、PROCESS_DONEにはＡＲＰの処理が完了していることを示す情報が格納される。

このようにＣＰＵ５６５から送信されたＡＲＰ要求パケットは、スイッチングハブ３１を経由してＭＡＣ６６１により受信される。ＭＡＣ６６１が受信したフレームに対して、ＴＯＥ６６３がＥｔｈｅｒｎｅｔの受信処理を行う。ＴＯＥ６６３は、上位層プロトコルであるＡＲＰを処理するため、ディスクリプタを用いて、受信フレームに関する情報をＣＰＵ６６５に伝達する。この場合、DESCRIPTOR_TYPEには受信指示を示す値が格納され、NETWORK_IDにはＭＡＣ６６１とＴＯＥ６６３を示す識別子が格納され、BUFFER_ADDRESSには受信フレームの格納されている共有メモリのアドレスが格納され、PROCESS_DONEにはＥｔｈｅｒｎｅｔの処理が完了していることを示す情報が格納される。

ＣＰＵ６６５上で動作するソフトウェアは、ディスクリプタから得られた受信フレームのＡＲＰの受信処理を行い、ＡＲＰ応答パケットを生成する。そして、ＣＰＵ６６５は、ディスクリプタを用いて、ＴＯＥ６６３に、フレームを受信したネットワークを介してＡＲＰ応答パケットを送信するよう指示する。この際、DESCRIPTOR_TYPEには送信指示を示す値が格納され、NETWORK_IDにはＡＲＰ要求パケットを受信したネットワークであるＭＡＣ６６１とＴＯＥ６６３を示す識別子が格納され、BUFFER_ADDRESSにはＣＰＵ６６５が生成したＡＲＰ応答パケットを格納した共有メモリのアドレスが指定される。指示を受けたＴＯＥ６６３は、Ｅｔｈｅｒｎｅｔの送信処理を行った後、ＭＡＣ６６１を介してフレームを送信する。これにより、ＴＯＥ６６３とＭＡＣ６６１を介してＡＲＰ応答パケットが送信される。

スイッチングハブ３１及びＭＡＣ５６１を介してフレーム（ＡＲＰ応答パケット）を受信したＴＯＥ５６３は、Ｅｔｈｅｒｎｅｔの受信処理を行った後、ディスクリプタを用いて、ＣＰＵ５６５に受信処理を行うように指示する。ＴＯＥ５６４でも同じフレームが受信されるが、受信するように設定されているＩＰアドレスとＭＡＣアドレスではないため、フレームは破棄される。ＣＰＵ５６５が、このＡＲＰ応答パケットを受信することにより、ＴＯＥ６６３のＭＡＣ６６１側に付与されているＩＰアドレスに対応するＭＡＣアドレスを取得できる。

このように、フレーム毎にそのフレームを受信したネットワークまたは、フレームを送信するネットワークをＣＰＵとＴＯＥとの間で通知することで、複数のＭＡＣと接続された複数のＴＯＥを用いて通信を行うことが可能となる。

上述の方法で得られたＭＡＣアドレスを用いて、192.168.1.1と192.168.1.2との間でセッションを確立するため、ＣＰＵ５６５上で動作するソフトウェアが、ＳＹＮフラグを含むＴＣＰセッション確立要求セグメントをＴＯＥ５６３およびＭＡＣ５６１を介して送信する。

スイッチングハブ３１を介してＭＡＣ６６１に到達したＴＣＰセッション確立要求セグメントは、ＭＡＣ６６１によりフレームの受信処理、ＴＯＥ６６３によりＥｔｈｅｒｎｅｔの受信処理、ＩＰｖ４の受信処理、ＴＣＰの受信データ処理が行われる。ＴＯＥ６６３は、ディスクリプタを用いて、受信フレームの情報をＣＰＵ６６５に通知する。ＣＰＵ６６５は、ＴＣＰのＳＹＮフラグを含むセグメントの処理を行う。ＣＰＵ６６５は、そのＳＹＮフラグを含むセグメントが受け入れ可能な場合、ＳＹＮフラグとＡＣＫフラグを含むセグメントを生成して、ディスクリプタを用いて、ＴＯＥ６６３に送信フレームの情報を伝達する。

ＴＯＥ６６３は、ＴＣＰの送信データ処理、ＩＰｖ４の送信処理、Ｅｔｈｅｒｎｅｔの送信処理を行い、ＭＡＣ６６１を介してフレームを送信する。ＳＹＮフラグとＡＣＫフラグを含むセグメントは、スイッチングハブ３１を介してＭＡＣ５６１に受信される。ＭＡＣ５６１で受信されたフレームは、ＴＯＥ５６３により、Ｅｔｈｅｒｎｅｔの受信処理、ＩＰｖ４の受信処理、ＴＣＰの受信データ処理が行われ、ＣＰＵ５６５によりＳＹＮフラグとＡＣＫフラグを含んだセグメントの受信処理が行われる。このセグメントが受け入れ可能であれば、ＣＰＵ５６５はセッション情報を作成してセッションを確立させ、セッション情報記憶部（図示せず）に、フレームを受信したディスクリプタに設定されているNETWORK_IDをセッションの属するネットワークとして記録する。

ＣＰＵ５６５は、ＡＣＫフラグを含むＴＣＰセグメントを生成し、ＴＯＥ５６３およびＭＡＣ５６１を介して、フレームを送出する。このフレームがスイッチングハブ３１とＭＡＣ６６１を介してＴＯＥ６６３で受信処理される。ＴＯＥ６６３は、ディスクリプタを用いてＣＰＵ６６５にフレームの情報を伝達する。ＣＰＵ６６５は、セッションの確立処理を行うと、セッション情報記憶部（図示せず）に、フレームを受信したディスクリプタに設定されているNETWORK_IDをセッションの属するネットワークとして記録する。

192.168.2.1から192.168.2.2、192.168.3.1から192.168.3.2 、192.168.4.1から192.168.4.2についても同様にして、ＣＰＵ５６５上で動作するソフトウェアがＡＲＰを用いてＭＡＣアドレスを解決し、ＴＣＰのセッション確立を行う。なお、エンコーダ２２側からではなく、フラッシュメモリ２３側からＴＣＰのセッション確立を行ってもよい。

上述のように、エンコーダ２２とフラッシュメモリ２３との間で４つのセッションを確立したら、エンコーダ２２がビデオカメラ２１からの入力をエンコードする。エンコーダ２２の出力データに対して、ＴＯＥ５６３から２つのセッション、ＴＯＥ５６４から２つのセッションの合計４セッションで、ＴＣＰによる送信処理を開始する。

なお、ＴＯＥ５６３、５６４は、図５に示すＴＯＥ１１３と同様の構成になっており、ＭＡＣ前段に設けられたフレームバッファ部の残り容量が所定のサイズを上回っているものに対応するデータ送信を優先的に行う。

上述のように送信されたＴＣＰデータセグメントは、ＴＯＥ６６３およびＴＯＥ６６４により受信処理され、セッション毎にフラッシュメモリ２３の別の記憶領域にデータが書き込まれる。データの転送がすべて完了すると、エンコーダ２２側およびフラッシュメモリ２３側からＦＩＮフラグを含むセグメントを送信し、ＴＣＰのセッション終了処理を行う。セッション終了が受け入れられると、セッション情報記憶部内のセッション情報は破棄される。

セッション終了処理後、フラッシュメモリ２３では、正常に受信された１つのストリームを残して、他のストリームが破棄される。なお、通信路に障害が発生した場合、ＴＯＥ５６３、５６４から送信ができず、エンコーダ２２内のバッファがオーバーフローするため、ファイルサイズの大きいストリームを正常に受信できたものと判定してもよい。

データ通信装置５６０、６６０はそれぞれ２つのＴＯＥを備えているため、一方のＴＯＥが故障した場合でも、他方のＴＯＥにより複数のネットワークを介して通信を行うことができる。

このように、本実施形態に係るデータ通信装置によれば、２つのＴＯＥと２つのＭＡＣを用いて４つのネットワークを介した通信を行うことにより、ＴＯＥの故障を保証しながら、高速かつ損失なく映像ストリームを伝送することが可能となる。また、ＭＡＣとＴＯＥがそれぞれ独立に接続され、２つの通信路によって伝送される場合よりも、各機器の故障に対する耐性を高めることが可能となる。また、通信路の数だけＴＯＥを設ける必要がないため、コストを低減できる。従って、データ通信の高速化及び信頼性向上を低コストに実現できる。

なお、本実施形態では２つのハードウェアオフロードエンジンと２つのＭＡＣで構成される例を示したが、それぞれ個数は２つに限定されず、複数のオフロードエンジンと複数のＭＡＣであれば、同様に信頼性を高めることが可能である。

また、本実施形態においては、１つのエンコーダから出力した映像ストリームを複数の通信路を介して伝送する例を示したが、エンコーダの数を増やして信頼性を高めてもよい。

なお、上記第１〜第４の実施形態におけるデータ通信装置のハードウェアプロトコル処理部１３、６３、６４は、ＴＣＰやＵＤＰのプロトコル以外にも、ＳＣＴＰ（Stream Control Transmission Protocol）、ＤＣＣＰ（Datagram Congestion Control Protocol）、ＲＴＰ（Real-time Transport Protocol）、ＩＰｖ６（Internet Protocol Version 6）などのプロトコルを備えてもよい。

また、上記実施形態ではデータ通信装置の通信路として、スイッチングハブを１台経由する例を示したが、通信路を複数のスイッチングハブで構成してもよいし、ルータを経由してもよい。また、ＭＡＣとスイッチングハブとの接続には、ＰＨＹを用いて接続してもよいし、ＳＧＭＩＩ（Serial Gigabit Media Independent Interface）などの規格により接続してもよい。

また、上記実施例では記憶媒体としてフラッシュメモリを用いる例をあげたが、これはハードディスクや磁気テープなどでもよい。

上述した実施形態で説明したデータ通信装置の少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、データ通信装置の少なくとも一部の機能を実現するプログラムをフレキシブルディスクやＣＤ−ＲＯＭ等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。

また、データ通信装置の少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。

なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

１０ データ通信装置
１１、１２ 通信部
１３ ハードウェアプロトコル処理部
１４ ソフトウェアプロトコル処理部
１５ セッション情報記憶部
１６ フレーム情報記憶部

Claims (12)

1. 複数のネットワークを介してフレームの送受信を行う通信部と、
   前記通信部が前記複数のネットワークのいずれを介して受信フレームを受信したかを示す第１識別子、又は前記通信部が前記複数のネットワークのいずれを介して送信フレームを送信するかを示す第２識別子を記憶する第１記憶部と、
   前記受信フレームに対するネットワークプロトコル処理をハードウェアで行って前記第１識別子を前記第１記憶部に書き込み、前記第１記憶部から前記第２識別子を読み出して前記送信フレームに対するネットワークプロトコル処理をハードウェアで行う第１処理部と、
   前記送信フレームに対するネットワークプロトコル処理をソフトウェアで行って前記第２識別子を前記第１記憶部に書き込み、前記第１記憶部から前記第１識別子を読み出して前記受信フレームに対するネットワークプロトコル処理をソフトウェアで行う第２処理部と、
   を備えるデータ通信装置。
2. 確立中のセッションを示すセッション情報及び前記セッションに対応するネットワークを示す第３識別子を記憶する第２記憶部をさらに備え、
   前記第１処理部は、前記セッション情報から前記送信フレームに対応するセッションが確立されているか否か判定し、確立されている場合は当該セッションに対応する前記第３識別子を前記第２記憶部から取得し、取得した前記第３識別子を用いて前記送信フレームに対しネットワークプロトコル処理を行うことを特徴とする請求項１に記載のデータ通信装置。
3. 前記第１処理部は、前記セッション情報から前記受信フレームに対応するセッションが確立されているか否か判定し、確立されていない場合、前記第１識別子を前記第１記憶部に書き込み、
   前記第２処理部は、前記第１記憶部から前記第１識別子を読み出して前記受信フレームに対するネットワークプロトコル処理を行い、処理の結果、セッションが確立した場合は、前記第１識別子を前記第２記憶部に書き込むことを特徴とする請求項２に記載のデータ通信装置。
4. 前記通信部は、シーケンス番号が付加された同一のデータを複数のネットワークを介して受信し、
   前記第１処理部は、前記シーケンス番号を解析し、どちらか一方のチェックサム計算の結果が正しいデータのみを受信処理することを特徴とする請求項１乃至３のいずれかに記載のデータ通信装置。
5. 前記通信部は、それぞれ異なるネットワークと送受信する複数の通信部からなり、
   前記第１識別子はフレームを受信した通信部を示す識別子であり、
   前記第２識別子はフレームを送信する通信部を示す識別子であることを特徴とする請求項１乃至４のいずれかに記載のデータ通信装置。
6. 前記通信部は、それぞれネットワークを介したフレームの送受信を行う複数のハードウェアを含むこと特徴とする請求項１乃至５のいずれかに記載のデータ通信装置。
7. 前記第１処理部は、
   前記第２処理部からデータ送信要求を受け付ける受付部と、
   前記通信部に含まれる前記複数のハードウェアの各々に対応して設けられ、それぞれ対応するハードウェアに対する前記データ送信要求をキューイングする複数の送信キュー部と、
   前記送信キュー部にキューイングされた前記データ送信要求を取り出し、前記データ送信要求に基づいて送信指示を出力する指示部と、
   前記送信指示に基づいて送信フレームを生成する生成部と、
   前記送信フレームを、送信を行う前記ハードウェアに対応して設けられたフレームバッファに渡す選択部と、
   を備え、
   前記指示部は、前記フレームバッファのバッファ可能な残り容量を確認し、前記残り容量が所定サイズ以上であるフレームバッファに対応する前記送信キュー部から前記データ送信要求を優先的に取り出すことを特徴とする請求項６に記載のデータ通信装置。
8. 前記第１処理部は、
   前記第２処理部からデータ送信要求を受け付ける受付部と、
   前記受付部が受け付けた前記データ送信要求をキューイングする送信キュー部と、
   前記送信キュー部にキューイングされた前記データ送信要求に基づいて送信フレームを生成する生成部と、
   前記送信フレームを前記通信部に含まれる複数のハードウェアに送信する送信部と、
   前記送信部が、前記複数のハードウェアのうち、前記送信フレームを受け付け可能なハードウェアにのみフレームを送信している間に、前記生成部が前記送信キュー部により新たにキューイングされたデータ送信要求に基づいて、新たな送信フレームを生成した場合、前記送信部に、送信中のフレームの破棄及び、前記新たな送信フレームの送信開始を指示する指示部と、
   を備える請求項６に記載のデータ通信装置。
9. 前記第１処理部は、
   前記第２処理部からデータ送信要求を受け付ける受付部と、
   前記受付部が受け付けた前記データ送信要求をキューイングする送信キュー部と、
   前記送信キュー部にキューイングされた前記データ送信要求に基づいて送信フレームを生成する生成部と、
   前記送信フレームを前記通信部に含まれる複数のハードウェアに送信する送信部と、
   前記送信部のフレーム送信時間を監視し、前記送信部が、前記送信フレームを受け付け可能なハードウェアにのみフレームを送信している間に、前記フレーム送信時間が所定時間を超えた場合、前記送信部に、送信中のフレームの破棄及び新たな送信フレームの送信開始を指示する指示部と、
   を備える請求項６に記載のデータ通信装置。
10. 前記第１処理部は、ネットワークプロトコル処理をハードウェアで行う複数のハードウェアプロトコル処理部から構成され、
    前記第１識別子はさらに受信フレームに対するネットワークプロトコル処理を行うハードウェアプロトコル処理部を示す識別子であり、
    前記第２識別子はさらに送信フレームに対するネットワークプロトコル処理を行うハードウェアプロトコル処理部を示す識別子であることを特徴とする請求項１乃至９のいずれか記載のデータ通信装置。
11. 通信部、第１記憶部、確立中のセッションを示すセッション情報を記憶する第２記憶部、第１処理部、及び第２処理部を有するデータ通信装置によるデータ通信方法であって、
    前記通信部が複数のネットワークのいずれかを介してフレームを受信するステップと、
    前記第１処理部が受信フレームに対しネットワークプロトコル処理をハードウェアで行うステップと、
    前記第１処理部が、前記セッション情報から前記受信フレームに対応するセッションが確立しているか否か判定するステップと、
    前記第１処理部が、前記受信フレームに対応するセッションが確立していない場合に、前記通信部が前記複数のネットワークのいずれを介して前記受信フレームを受信したかを示す第１識別子を前記第１記憶部に書き込むステップと、
    前記第２処理部が、前記第１記憶部から前記第１識別子を読み出し、前記受信フレームに対してネットワークプロトコル処理をソフトウェアで行うステップと、
    前記第２処理部が、前記ソフトウェアで行ったネットワークプロトコル処理の結果、セッションが確立した場合に、前記第１識別子を前記第２記憶部に書き込むステップと、
    を備えるデータ通信方法。
12. 前記第１処理部が、前記セッション情報から、送信データに対応するセッションが確立されているか否か判定するステップと、
    前記第２処理部が、前記セッションが確立されていない場合に、前記送信データに対してネットワークプロトコル処理をソフトウェアで行うステップと、
    前記第２処理部が、前記送信データを前記複数のネットワークのいずれを介して送信するかを示す第２識別子を前記第１記憶部に書き込むステップと、
    前記第１処理部が、前記第１記憶部から前記第２識別子を読み出し、前記送信フレームに対してネットワークプロトコル処理をハードウェア処理するステップと、
    前記通信部が前記第１処理部により処理された前記送信フレームを送信するステップと、
    を備える請求項１１に記載のデータ通信方法。

Images