(57)【要約】      （修正有）【課題】ＴＣＰ送信処理全体の遅延時間を低減する通信方法、通信装置及びプログラムを提供する。【解決手段】通信装置は、入力された送信データに対してＴＣＰおよびＩＰに関する処理を行う処理手段と、処理手段により処理された送信データを含む送信フレームを他の通信装置に送信する通信インタフェースと、通信装置と他の通信装置との間の通信に関する第１の情報および通信インタフェースに関する第２の情報に基づいて、処理手段に一度に入力する送信データのサイズを決定する決定手段と、を有する。【選択図】図２
2018142853.tif 000002
【特許請求の範囲】
【請求項１】
通信装置であって、
入力された送信データに対してＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）およびＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）に関する処理を行う処理手段と、
前記処理手段により処理された送信データを含む送信フレームを他の通信装置へ送信する通信インタフェースと、
前記通信装置と前記他の通信装置との間の通信に関する第１の情報、および、前記通信インタフェースに関する第２の情報に基づいて、前記処理手段に一度に入力する送信データのサイズを決定する決定手段と、
を有することを特徴とする通信装置。
【請求項２】
前記通信インタフェースから送信された前記送信フレームに対する確認応答フレームを前記他の通信装置から受信する受信手段を更に有し、
前記第１の情報は、前記受信手段により受信した前記確認応答フレームに含まれるＴＣＰウィンドウサイズに基づく情報を含むことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記第２の情報は、前記通信インタフェースが前記送信フレームを送信する際のフレームアグリゲーション機能の利用状態に基づく情報を含むことを特徴とする請求項１または２に記載の通信装置。
【請求項４】
前記利用状態とは、前記通信インタフェースのフレームアグリゲーション機能の有効もしくは無効、または、フレームアグリゲーションのモードの情報であることを特徴とする請求項３に記載の通信装置。
【請求項５】
前記モードの情報とは、前記通信インタフェースが前記送信フレームを送信する際に、Ａ−ＭＳＤＵ（Ａｇｇｒｅｇａｔｉｏｎ  ＭＡＣ  Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）又はＡ−ＭＰＤＵ（Ａｇｇｒｅｇａｔｉｏｎ  ＭＡＣ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）のいずれのモードを利用するかを示す情報であることを特徴とする請求項４に記載の通信装置。
【請求項６】
前記第２の情報は、前記利用状態と、通信プロトコルオーバーヘッドサイズとに基づく情報を含むことを特徴とする請求項３から５のいずれか１項に記載の通信装置。
【請求項７】
前記通信プロトコルオーバーヘッドサイズには、ＴＣＰヘッダサイズ、ＩＰヘッダサイズ、ＭＡＣヘッダサイズ、フレームチェックシーケンスサイズの少なくとも一つを含むことを特徴とする請求項６に記載の通信装置。
【請求項８】
前記第２の情報は、前記通信インタフェースが有する内部バッファの空き容量に基づく情報を含むことを特徴とする請求項１から７のいずれか１項に記載の通信装置。
【請求項９】
前記第２の情報は、前記利用状態と、前記通信インタフェースが有する内部バッファの空き容量とに基づく値の情報であることを特徴とする請求項３から８のいずれか１項に記載の通信装置。
【請求項１０】
前記決定手段は、ＴＣＰウィンドウサイズよりも小さいサイズであって、ＴＣＰ最大セグメントサイズの倍数となるサイズを、前記処理手段に一度に入力する送信データのサイズとして決定することを特徴とする請求項１から９のいずれか１項に記載の通信装置。
【請求項１１】
前記決定手段は、ＴＣＰウィンドウサイズと前記通信インタフェースが有する内部バッファの空き容量のうち、小さいサイズであって、ＴＣＰ最大セグメントサイズの倍数となるサイズを、前記処理手段に一度に入力する送信データのサイズとして決定することを特徴とする請求項１から１０のいずれか１項に記載の通信装置。
【請求項１２】
前記決定手段は、ＴＣＰウィンドウサイズと、前記通信インタフェースが有する内部バッファの空き容量と、前記通信インタフェースが前記送信フレームを送信する際のフレームアグリゲーション機能の利用状態とに基づくサイズと、のうち最も小さいサイズであって、ＴＣＰ最大セグメントサイズの倍数となるサイズを、前記処理手段に一度に入力する送信データのサイズとして決定することを特徴とする請求項１から１１のいずれか１項に記載の通信装置。
【請求項１３】
入力された送信データに対してＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）およびＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）に関する処理を行う処理手段と、
前記処理手段において処理された送信データを含む送信フレームを他の通信装置へ送信する通信インタフェースを有する通信装置の制御方法であって、
前記通信装置と前記他の通信装置との間の通信に関する第１の情報、および、前記通信インタフェースに関する第２の情報に基づいて、前記処理手段に一度に入力する送信データのサイズを決定する決定工程を有することを特徴とする制御方法。
【請求項１４】
コンピュータを請求項１から１１のいずれか１項に記載の通信装置として動作させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＴＣＰ／ＩＰ処理を行う装置に関する。
【背景技術】
【０００２】
インターネット通信では、主要なプロトコルとして、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）が広く普及している。ＴＣＰ通信による送信側では、受信側が通知するウィンドウサイズ分の送信データを、確認応答を待たずに送信することができる。ＴＣＰウィンドウサイズは通常６４ＫＢｙｔｅｓだが、ＴＣＰウィンドウスケールオプション（特許文献１）を利用すると６４ＫＢｙｔｅｓを超えるＴＣＰウィンドウサイズがサポートされる。
【０００３】
また、無線ＬＡＮプロトコルとしてＩＥＥＥ８０２．１１ｎやＩＥＥＥ８０２．１１ａｃ等が広く普及している。これらのプロトコルでは、データリンク層にて同一の宛先のフレームを連結して送信することでスループットを向上させるフレームアグリゲーションを採用している。フレームアグリゲーションには、ＭＡＣヘッダより後ろのデータフレームを連結するＡ−ＭＳＤＵ方式と、ＭＡＣヘッダも含めたＭＡＣフレームを連結するＡ−ＭＰＤＵ方式が規定されている。それぞれのプロトコルでは、連結可能なデータの最大値が規定されており、Ａ−ＭＳＤＵは８ＫＢｙｔｅｓ、Ａ−ＭＰＤＵは６４ＫＢｙｔｅｓとなっている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平９−９７２２３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＴＣＰ／ＩＰスタックやＴＣＰ／ＩＰプロトコル処理を行うハードウェアにおいて、ＴＣＰウィンドウサイズ分のデータサイズを、一度に送信処理することがある。その際、ＴＣＰウィンドウスケールオプションを利用すると、通信インタフェースの制限、例えば無線通信プロトコルのフレームアグリゲーションのデータ連結最大値や内部バッファ空き容量等、を超えることが容易に発生し得る。
【０００６】
フレームアグリゲーションに対応している無線通信インタフェースのフレームアグリゲーションのデータ連結最大値や内部バッファ空き容量を超えるフレームデータを入力すると、一回の無線データ送信では入力フレームデータの送信は完了しない。一回の無線データ送信でフレームデータの送信が完了しないと、フレームデータを入力するＴＣＰ／ＩＰスタック、又はＴＣＰ／ＩＰプロトコル処理を行うハードウェアは無線通信プロトコルの受信応答を受ける時間も含めて待ち時間が発生する。これにより、ＴＣＰ送信処理全体の並列性が損なわれ、冗長な遅延が発生してしまうという課題がある。
【０００７】
上記課題を鑑み、ＴＣＰ送信処理全体の遅延時間を低減させることを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を鑑み、本発明の通信装置は、入力された送信データに対してＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）およびＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）に関する処理を行う処理手段と、前記処理手段により処理された送信データを含む送信フレームを他の通信装置へ送信する通信インタフェースと、前記通信装置と前記他の通信装置との間の通信に関する第１の情報、および、前記通信インタフェースに関する第２の情報に基づいて、前記処理手段に一度に入力する送信データのサイズを決定する決定手段と、を有する。
【発明の効果】
【０００９】
本発明によれば、ＴＣＰ送信処理全体の遅延時間を低減させることが可能となる。
【図面の簡単な説明】
【００１０】
【図１】実施形態１における通信装置のハードウェア構成例
【図２】実施形態１における通信装置に搭載されるソフトウェアモジュール構成例
【図３】実施形態１における入力送信データサイズ決定フローチャート
【図４】実施形態１における通信インタフェース制限サイズ決定フローチャート
【図５】実施形態２における通信装置のハードウェア構成例
【図６】実施形態２における通信装置に搭載されるソフトウェアモジュール構成例とセグメント分割／通信ヘッダ生成ハードウェア構成例
【図７】実施形態２における入力送信データサイズ決定フローチャート
【発明を実施するための形態】
【００１１】
以下、添付の図面を参照して、本発明をその実施形態の一例に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
【００１２】
＜実施形態１＞
実施形態１において、通信装置１００は不図示の受信装置（他の通信装置）と、ＴＣＰ／ＩＰプロトコルに準拠したデータ通信を行う。ここで、ＴＣＰはＴｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌの略であり、ＩＰはＩｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌの略である。
【００１３】
図１に、通信装置１００のハードウェア構成を示す。システムバス１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１０２やＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１０３、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１０４等を接続し、各種データの転送経路となる。ＣＰＵ１０２は、各ハードウェア構成部を統括的に制御し、通信装置１００全体を制御する。ＲＯＭ１０３は、ＣＰＵ１０２で実行される制御プログラム等を格納している。
【００１４】
ＲＡＭ１０４は、ＣＰＵ１０２の主メモリ、ワークエリア等として機能し、プログラムやデータを一時記憶する。ＲＡＭ１０４は、不図示のアプリケーションデータを格納するアプリケーションバッファやパケットデータ等を格納するネットワークバッファ等を有する。ＭＡＣ１０５はＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）層とＰＨＹ（物理）層に対応する通信処理を行う通信部である。本実施形態ではＭＡＣ１０５がＩＥＥＥ８０２．１１シリーズに準拠した無線通信（Ｗｉ−Ｆｉ通信）を行う無線ＬＡＮモジュールであるものとして説明するが、これに限らない。例えば、Ｅｔｈｅｒｎｅｔ（登録商標）に準拠した有線通信を行う有線ＬＡＮモジュールであってもよい。ネットワーク１０７は、ＥｔｈｅｒｎｅｔやＷｉ−Ｆｉ通信等のＩＰ通信が可能なネットワークである。なお、ＬＡＮは、Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋの略である。
【００１５】
図２は、通信装置１００が実現するソフトウェアモジュール２００の内部構成を示すソフトウェアブロック図である。ソフトウェアモジュール２００は、ＲＯＭ１０３に格納された制御プログラムをＣＰＵ１０２で実行することにより実現される。
【００１６】
アプリケーション２０１は、ユーザアプリケーションを指す。アプリケーション２０１は、通信装置１００の通信相手となる不図示の受信装置に送信する任意のサイズのアプリケーションデータをＴＣＰ／ＩＰスタック２０２に入力する。ＴＣＰ／ＩＰスタック２０２には、フレームデータ入力部２０３、フレームデータ分割部２０４、ＴＣＰ／ＩＰプロトコル処理部２０５、セッション管理部２０６、および、通信インタフェース管理部２０７が含まれる。
【００１７】
フレームデータ入力部２０３は、セッション管理部２０６で管理されるＴＣＰウィンドウサイズと、通信インタフェース管理部２０７で管理される通信インタフェース制限サイズから、フレームデータ分割部２０４へ一度に入力する送信データサイズを決定する。一度に入力する送信データサイズの決定方法の詳細については後述する。
【００１８】
フレームデータ分割部２０４では、入力された送信データをＴＣＰ最大セグメントサイズ（ＴＣＰ  Ｍａｘｉｍｕｍ  Ｓｅｇｍｅｎｔ  Ｓｉｚｅ）以下のサイズの単位に分割する。フレームデータ分割部２０４により分割された送信データの各々は、ＴＣＰフレームのペイロード、いわゆる、ＴＣＰセグメントとなる。
【００１９】
ＴＣＰ／ＩＰプロトコル処理部２０５では、分割されたＴＣＰセグメントに対応するＴＣＰヘッダやＩＰヘッダの生成と、それに伴うチェックサム計算等の処理を行い、送信フレームを生成する。ＴＣＰ／ＩＰプロトコル処理部２０５は、生成した送信フレームを通信インタフェースドライバ２０８に入力する。
【００２０】
通信インタフェースドライバ２０８は、通信インタフェース２０９のドライバソフトウェアであり、ＴＣＰ／ＩＰスタック２０２と通信インタフェース２０９との間でデータや情報のやり取りを担う。通信インタフェース２０９は、外部のネットワーク１０７と直接通信するハードウェアであり、フレームデータを保持するための内部バッファ２１０を有する。
【００２１】
通信装置１００は、通信インタフェース２０９を介して受信装置に、ＴＣＰ／ＩＰに準拠した送信フレームを送信する。そして通信装置１００は、通信インタフェース２０９を介して、受信装置から当該送信フレームに対する確認応答フレーム（ＴＣＰに準拠したＡＣＫ）を受信する。ここで、確認応答フレームには通信装置１００と受信装置との間のＴＣＰセッションにおけるＴＣＰウィンドウサイズが含まれる。
【００２２】
受信装置から確認応答フレームを受信すると、通信インタフェースドライバ２０８は、受信した確認応答フレームをセッション管理部２０６へ受け渡す。セッション管理部２０６では、通信インタフェースドライバ２０８から受け取った確認応答フレームからＴＣＰセッションのＴＣＰウィンドウサイズを取得し、管理する。
【００２３】
通信インタフェース管理部２０７では、通信インタフェースドライバ２０８から受け取った通信インタフェース情報、例えば、内部バッファ２１０の空き容量やフレームアグリゲーションのモード等の情報から通信インタフェース制限サイズを算出し、管理する。通信インタフェース制限サイズの算出方法の詳細については後述する。
【００２４】
図３は、フレームデータ入力部２０３における入力送信データサイズの決定方法を含めた、送信データのフレームデータ分割部２０４への送信データ入力方法を示すフローチャートである。
【００２５】
図３に、通信装置１００が受信装置へデータを送信する場合に、ＲＯＭ１０３に記憶されたプログラムをＣＰＵ１０２が読み出し、それを実行することで実現される処理の流れのフローチャートを示す。
【００２６】
なお、図３に示すフローチャートの少なくとも一部をハードウェアにより実現してもよい。ハードウェアにより実現する場合、例えば、所定のコンパイラを用いることで、各ステップを実現するためのプログラムからＦＰＧＡ上に自動的に専用回路を生成すればよい。ＦＰＧＡとは、Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙの略である。また、ＦＰＧＡと同様にしてＧａｔｅ  Ａｒｒａｙ回路を形成し、ハードウェアとして実現するようにしてもよい。また、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）により実現するようにしてもよい。
【００２７】
Ｓ３０１において、フレームデータ入力部２０３は、アプリケーション２０１からアプリケーションデータを受け取る。ここで受け取ったアプリケーションデータの総サイズをＳとする。
【００２８】
次にＳ３０２において、フレームデータ入力部２０３は、セッション管理部２０６で管理されるＴＣＰウィンドウサイズを取得する。ここで取得したＴＣＰウィンドウサイズをＷとする。
【００２９】
次にＳ３０３において、フレームデータ入力部２０３は、通信インタフェース管理部２０７で管理される通信インタフェース制限サイズを取得する。ここで取得した通信インタフェース制限サイズをＲとする。
【００３０】
そして、Ｓ３０４において、フレームデータ入力部２０３は、入力送信データサイズを決定する。フレームデータ入力部２０３は、アプリケーションデータ総サイズＳ、ＴＣＰウィンドウサイズＷ、通信インタフェース制限サイズＲの中の最小値以下で、ＴＣＰ最大セグメントサイズ（ＭＳＳ）の倍数となる最大値を、入力送信データサイズｉとして設定する。なお、アプリケーションデータ総サイズＳ、ＴＣＰウィンドウサイズＷ、通信インタフェース制限サイズＲの中の最小値がＴＣＰ最大セグメントサイズに満たない場合（ｍｉｎ（Ｓ，Ｗ，Ｒ）＜ＭＳＳ）、入力送信データサイズｉとして、当該最小値を設定する。
【００３１】
ＴＣＰ最大セグメントサイズは、通信装置１００と受信装置との間で、３ＷａｙＨａｎｄＳｈａｋｅによりＴＣＰセッションを確立する際に決定され、ＲＡＭ１０４に記憶される。ここでは、フレームデータ入力部２０３は、入力送信データサイズを決定する際に、ＲＡＭ１０４からＴＣＰ最大セグメントサイズを読み出すことで取得する。
【００３２】
また、決定方法はこれに限らず、例えば、ＴＣＰ最大セグメントサイズの倍数は考慮しなくてもよい。この場合は、フレームデータ入力部２０３は、アプリケーションデータ総サイズＳ、ＴＣＰウィンドウサイズＷ、通信インタフェース制限サイズＲの中の最小値を、入力送信データサイズｉとする。
【００３３】
Ｓ３０５において、フレームデータ入力部２０３は、入力送信データサイズｉの単位でフレームデータ分割部２０４に送信データを入力する。そして、送信データを入力する毎に、アプリケーションデータサイズＳを更新する（Ｓ：＝Ｓ−ｉ）。即ち、Ｓはフレームデータ分割部２０４へ未入力のアプリケーションデータサイズ（残存アプリケーションデータサイズ）を示す。
【００３４】
Ｓ３０６において、フレームデータ入力部２０３は、全アプリケーションデータがフレームデータ分割部２０４に入力済（Ｓ＝＝０）かどうかを確認し、入力済であれば（Ｓ３０６のＹｅｓ）図３に示す処理を終了する。一方、未入力のアプリケーションデータが残っていればＳ３０７に移行する。
【００３５】
Ｓ３０７において、フレームデータ入力部２０３は、アプリケーションデータの再入力が可能になるまで待機する。ここでは、フレームデータ分割部２０４へ入力された送信データの全てが送信済となった場合に、フレームデータ入力部２０３は、アプリケーションデータをフレームデータ分割部２０４へ再入力することが可能になったと判定する。なお、送信済みとは、通信インタフェース２０９が当該データを送信し終えた場合である。なお、これに代えて、ＴＣＰ／ＩＰスタック２０２が当該データを通信インタフェース２０９へ送信し終えた場合であてもよい。アプリケーションデータの再入力が可能となると、Ｓ３０２に移行する。
【００３６】
図４は、通信インタフェース管理部２０７における通信インタフェース制限サイズの算出方法を示すフローチャートである。当該フローチャートは、フレームデータ入力部２０３がアプリケーション２０１からデータを受け取った際に開始される。また、通信インタフェース２０９から所定の割り込みが入った際に開始されるようにしてもよい。所定の割り込みとは、例えば、データの送信完了通知（内部バッファ２１０の空き容量が変わる）や、アグリゲーション設定の変更通知である。
【００３７】
なお、当該フローチャートは、ＲＯＭ１０３に記憶されたプログラムをＣＰＵ１０２が読み出し、それを実行することで実現される。
【００３８】
Ｓ４００において、通信インタフェース管理部２０７は、通信インタフェース２０９の通信インタフェース情報を通信インタフェースドライバ２０８経由で取得する。
【００３９】
Ｓ４０１において、通信インタフェース管理部２０７は、フレームアグリゲーション機能の利用状態、即ち、フレームアグリゲーションが有効かどうかを判定する。なお、フレームアグリゲーションの有効、もしくは、無効は、通信インタフェース２０９が通信状況（エラーレートや受信信号強度等）に基づいて設定される。そして、これを通信インタフェース管理部２０７が管理することによって、フレームアグリゲーションが有効かどうかを判定することができる。
【００４０】
判定の結果、フレームアグリゲーションが有効である場合はＳ４０２に移行し、無効である場合はＳ４０５に移行する。
【００４１】
Ｓ４０２において、通信インタフェース管理部２０７は、フレームアグリゲーションモードがＡ−ＭＳＤＵ又はＡ−ＭＰＤＵのどちらかを判定する。ここで、Ａ−ＭＳＤＵとはＡｇｇｒｅｇａｔｉｏｎ  ＭＡＣ  Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔの略である。また、Ａ−ＭＰＤＵとはＡｇｇｒｅｇａｔｉｏｎ  ＭＡＣ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔの略である。いずれを用いるかは、予め設定されていても良いし、通信状況等に基づいて切り替えてもよい。なお、装置としてデータ送信用には、いずれか１つのみをサポートしている場合には、本ステップを省略し、サポートしているモードのフローに進むようにしてもよい。その場合、他方のモードのみに対応するフローは省略してよく、装置として当該フローに対応する動作を実行できる必要はない。
【００４２】
Ａ−ＭＳＤＵの場合はＳ４０３に移行し、Ａ−ＭＰＤＵの場合はＳ４０４に移行する。
【００４３】
Ｓ４０３において、通信インタフェース管理部２０７は、Ａ−ＭＳＤＵの通信インタフェースプロトコル制限サイズＰを算出する。具体的には、Ａ−ＭＳＤＵにおいて、受信応答（ＡＣＫ）を待たずに一度に送信できるパケットの連結サイズである８ＫＢｙｔｅｓから、通信プロトコルオーバーヘッドサイズの合計にフレーム数を掛けたサイズを差し引いた値を算出する。そして、この算出した値を、通信インタフェースプロトコル制限サイズＰとする。なお、Ｓ４０３における通信プロトコルオーバーヘッドサイズとは、ＴＣＰヘッダサイズとＩＰヘッダサイズの合計値である。また、ＡＣＫとはＡｃｋｎｏｗｌｅｄｇｅｍｅｎｔの略である。
【００４４】
ここで、フレーム数は、ＴＣＰ最大セグメントサイズとＴＣＰヘッダサイズとＩＰヘッダサイズを合計したサイズのＩＰパケットが８ＫＢｙｔｅｓ以内で最も多くなる数をフレーム数とする。その後、Ｓ４０５に移行する。
【００４５】
Ｓ４０４において、通信インタフェース管理部２０７は、Ａ−ＭＰＤＵの通信インタフェースプロトコル制限サイズＰを算出する。即ち、Ａ−ＭＰＤＵにおいて、受信応答を待たずに一度に送信できるパケットの連結サイズである６４ＫＢｙｔｅｓから、通信プロトコルオーバーヘッドサイズの合計にフレーム数を掛けたサイズを差し引いた値を算出する。そして、この算出した値を、通信インタフェースプロトコル制限サイズＰとする。なお、Ｓ４０４における通信プロトコルオーバーヘッドサイズとは、ＭＡＣヘッダサイズ、フレームチェックシーケンスサイズ、ＴＣＰヘッダサイズとＩＰヘッダサイズの合計値である。
【００４６】
また、フレーム数は、最大セグメントサイズとＴＣＰヘッダサイズとＩＰヘッダサイズを合計したサイズのＩＰパケットが６４ＫＢｙｔｅｓからＭＡＣヘッダサイズとフレームチェックシーケンスサイズを差し引いた値以内で最も多くなる数をフレーム数とする。その後、Ｓ４０５に移行する。
【００４７】
Ｓ４０５において、通信インタフェース管理部２０７は、内部バッファ空き容量Ｂを取得する。
【００４８】
Ｓ４０６において、通信インタフェース管理部２０７は、通信インタフェース制限サイズＲを算出する。通信インタフェース制限サイズＲは、フレームアグリゲーションが有効の場合は、通信インタフェースプロトコル制限サイズＰと内部バッファ空き容量Ｂの小さい方が設定される。フレームアグリゲーションが無効の場合は、内部バッファ空き容量Ｂが通信インタフェース制限サイズＲとしてそのまま設定される。
【００４９】
本実施形態では、通信インタフェースの内部バッファ空き容量、フレームアグリゲーションサイズを両方とも考慮して入力送信データサイズを決定しているが、どちらかでもよい。また、無線通信プロトコルをＩＥＥＥ８０２．１１ｎとして説明したが、その他の無線通信プロトコルや有線通信プロトコルでもよい。また、通信インタフェース制限サイズを毎回算出するようにしているが、フレームアグリゲーションの有効／無効やフレームアグリゲーションモードが静的に決定される場合は予め固定値として設定してもよい。
【００５０】
このように、ＴＣＰウィンドウサイズ、通信インタフェース２０９のアグリゲーションの利用状況、および、内部バッファ２１０の空き容量に基づいて、ＴＣＰ／ＩＰスタック２０２に一度に入力する送信データのサイズを決定する。これにより、複数のＴＣＰコネクションが張られ、ＴＣＰ／ＩＰスタック２０２が並列処理を行う必要がある場合であっても、ＴＣＰ送信処理全体の効率的な並列性を維持することができる。即ち、１つのＴＣＰコネクションのための送信処理の待ち時間により、ＴＣＰ／ＩＰスタック２０２が他のＴＣＰコネクション処理ができなくなる時間を低減することができる。
【００５１】
なお、複数のＴＣＰコネクションが張られた場合に、上述の実施形態を実行し、１つのＴＣＰコネクションのみが張られている場合には、上述の実施形態を実行しないようにしてもよい。この場合、入力送信データサイズは、ＴＣＰウィンドウサイズとして決定され、Ｓ３０１で受け取ったアプリケーションデータの全てが一度にＴＣＰ／ＩＰスタック２０２へ入力される。このような切り替え処理を行うことにより、ＴＣＰコネクション数に応じた柔軟な制御を行うことができる。
【００５２】
＜実施形態２＞
実施形態１では、フレームデータ分割処理やフレーム生成処理をソフトウェアモジュールで実施した。実施形態２では、フレームデータ分割処理やＴＣＰ／ＩＰヘッダ生成処理、フレーム生成処理を含めたＴＣＰ／ＩＰプロトコル処理の一部を別のハードウェアで実施する。
【００５３】
図５は、本実施形態における通信装置１００のハードウェア構成例を示すブロック図である。セグメント分割／通信ヘッダ生成ハードウェア５００は、実施形態１においてソフトウェアで実行していたフレームデータ分割処理やＴＣＰ／ＩＰヘッダ生成処理、フレーム生成処理を実施するハードウェアである。その他のハードウェア構成については、実施形態１と同様であるため説明は省略する。
【００５４】
図６は、本実施形態における通信装置１００が搭載するソフトウェアモジュール２００の内部構成とセグメント分割／通信ヘッダ生成ハードウェア５００の内部構成を含むブロック図である。
【００５５】
ＴＣＰ／ＩＰスタック２０２におけるフレームデータ入力部６０１では、アプリケーション２０１から受け取ったアプリケーションデータからセグメント分割／通信ヘッダ生成ハードウェア５００に入力する入力送信データサイズを決定する。入力送信データサイズは、セッション管理部２０６で管理されるＴＣＰウィンドウサイズと、通信インタフェース管理部２０７で管理される通信インタフェース制限サイズ、内部バッファ５０１の空き容量から決定する。入力送信データサイズの決定方法の詳細については後述する。決定した入力送信データサイズの送信データをセグメント分割／通信ヘッダ生成ハードウェア５００に入力する。ＴＣＰ／ＩＰプロトコル処理部６０２では、ＴＣＰヘッダやＩＰヘッダの生成に必要となるシーケンス番号やタイムスタンプ、ポート番号等の情報又はそれらの情報を格納した雛形ヘッダを生成し、セグメント分割／通信ヘッダ生成ハードウェア５００に入力する。セグメント分割／通信ヘッダ生成ハードウェアドライバ６０３は、セグメント分割／通信ヘッダ生成ハードウェア５００のドライバであり、フレームデータ入力部６０１やＴＣＰ／ＩＰプロトコル処理部６０２とのデータ交換やハードウェアへの制御を仲介する。
【００５６】
セグメント分割／通信ヘッダ生成ハードウェア５００は、内部バッファ５０１、フレームデータ分割部５０２、ＴＣＰ／ＩＰヘッダ生成部５０３、フレーム生成部５０４で構成される。内部バッファ５０１は、フレームデータ入力部６０１から入力された送信データを一時保存するためのバッファである。フレームデータ分割部５０２では、内部バッファ５０１に保存された送信データをＴＣＰ最大セグメントサイズ以下の単位でＴＣＰセグメントとして分割する。ＴＣＰ／ＩＰヘッダ生成部５０３では、ＴＣＰ／ＩＰプロトコル処理部６０２から入力されたＴＣＰ／ＩＰヘッダ情報からＴＣＰ／ＩＰヘッダを生成する。具体的には、分割したＴＣＰセグメントサイズに応じたシーケンス番号の算出や分割したＴＣＰセグメントを含めたチェックサム計算等を行い、ＴＣＰヘッダ及びＩＰヘッダを生成する。フレーム生成部５０４では、フレームデータ分割部５０２で分割されたＴＣＰセグメントと、ＴＣＰ／ＩＰヘッダ生成部５０３で生成されたＴＣＰ／ＩＰヘッダを結合して送信フレームを生成する。生成した送信フレームは、通信インタフェース２０９の内部バッファ２１０に入力される。送信フレームの入力制御は、通信インタフェースドライバ２０８により行われてもよい。
【００５７】
その他の構成については、実施形態１と同様であるため、説明は省略する。
【００５８】
図７は、フレームデータ入力部６０１における入力送信データサイズの決定方法を含めた、送信データのセグメント分割／通信ヘッダ生成ハードウェア５００への送信データ入力方法を示すフローチャートである。当該フローチャートは、通信装置１００が受信装置へデータを送信する場合に、ＲＯＭ１０３に記憶されたプログラムをＣＰＵ１０２が読み出し、それを実行することで実現される。
【００５９】
Ｓ７０１において、フレームデータ入力部６０１は、アプリケーション２０１からアプリケーションデータを受け取り、受け取ったアプリケーションデータの総サイズをＳとする。
【００６０】
Ｓ７０２において、フレームデータ入力部６０１は、セグメント分割／通信ヘッダ生成ハードウェア５００の内部バッファ５０１の空き容量を取得し、取得した内部バッファ空き容量サイズをＢとする。
【００６１】
Ｓ７０３において、フレームデータ入力部６０１は、セッション管理部２０６で管理されるＴＣＰウィンドウサイズを取得し、取得したＴＣＰウィンドウサイズをＷとする。
【００６２】
Ｓ７０４において、フレームデータ入力部６０１は、通信インタフェース管理部２０７で管理される通信インタフェース制限サイズを取得し、取得した通信インタフェース制限サイズをＲとする。
【００６３】
Ｓ７０５において、フレームデータ入力部６０１は、入力送信データサイズを決定する。入力送信データサイズｉは、アプリケーションデータ総サイズＳ、内部バッファ空き容量Ｂ、ＴＣＰウィンドウサイズＷ、通信インタフェース制限サイズＲの中の最小値以下で、ＴＣＰ最大セグメントサイズの倍数となる最大値を設定する。ここで、アプリケーションデータ総サイズＳ、ＴＣＰウィンドウサイズＷ、通信インタフェース制限サイズＲの中の最小値がＴＣＰ最大セグメントサイズに満たない場合、入力送信データサイズｉとして当該最小値を設定する。なお、決定方法はこれに限らず、例えば、ＴＣＰ最大セグメントサイズの倍数は考慮しなくてもよい。
【００６４】
Ｓ７０６において、フレームデータ入力部６０１は、セグメント分割／通信ヘッダ生成ハードウェアドライバ６０３経由でセグメント分割／通信ヘッダ生成ハードウェア５００に送信データを入力する。そして、フレームデータ入力部６０１は、アプリケーションデータサイズＳを更新する（Ｓ：＝Ｓ−ｉ）。
【００６５】
Ｓ７０７において、フレームデータ入力部６０１は、全アプリケーションデータが入力済（Ｓ＝＝０）かどうかを確認し、入力済であれば終了する。未入力のアプリケーションデータが残っていればＳ７０８に移行する。
【００６６】
Ｓ７０８において、フレームデータ入力部６０１は、アプリケーションデータの再入力が可能になるまで待機する。アプリケーションデータが再入力可能かどうかは、例えばセグメント分割／通信ヘッダ生成ハードウェア５００の内部バッファ５０１の空き容量が十分にある場合や、入力した送信データが全て送信済となった場合等が考えられる。アプリケーションデータの再入力が可能となると、Ｓ７０２に移行する。
【００６７】
通信インタフェース管理部２０７における通信インタフェース制限サイズの算出方法は、実施形態１と同様であるため、説明は省略する。
【００６８】
本実施形態では、セグメント分割処理及び通信ヘッダ生成処理を行うハードウェアを含む構成で説明したが、セグメント分割処理又は通信ヘッダ生成処理のどちらか一方の処理だけを行うハードウェアでも良いし、別の処理を行うハードウェアでもよい。
【００６９】
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００７０】
１００  通信装置
１０１  システムバス
１０７  ネットワーク
【図１】
2018142853.tif 000003
【図２】
2018142853.tif 000004
【図３】
2018142853.tif 000005
【図４】
2018142853.tif 000006
【図５】
2018142853.tif 000007
【図６】
2018142853.tif 000008
【図７】
2018142853.tif 000009