JP4612821B2 - 通信制御装置及び方法 - Google Patents

Description

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

パーソナルコンピュータ等でなくとも、機器を直接ネットワークに接続する機会や需要が高まっている。例として携帯端末、プリンタ、カメラ、コピー機、ディスプレイ、ビデオ機器、音響装置などがあげられる。これらの機器は比較的低価格・低処理能力のＣＰＵを搭載、又は全く搭載していない場合もあり、その様な機器資源を利用しネットワークにおいて標準的に使用されているＴＣＰ／ＵＤＰ／ＩＰといったインターネット標準プロトコルを実現しようとすれば、ＴＣＰ／ＵＤＰ／ＩＰのプロトコルスタックを低処理能力ＣＰＵで低ビットレート（帯域）ではあるが実現するか、又はＴＯＥ（ＴＣＰ／ＩＰオフロードエンジン）といったプロトコル処理に特化した補助的デバイスを利用する事で比較的広帯域なネットワーク通信を実現するか、の方法しかない。とはいったものの機器が扱う情報の量は写真、動画、音楽、いずれにおいても大きくなる一方で、機器のコストを低価格に抑える必要がある、といった背景においてはＴＯＥによるネットワーク通信機能実現のアプローチが今後増加してくることは想像に難くない。

ＴＯＥ実現（ＴＣＰ／ＩＰプロトコルスタックのハードウェアによる実現）において、最も簡単にこれを実現する為には、ただ単に今迄ソフトウェアで実現していた方法をそのままハードウェア化すればよいと言う考え方がある。ソフトウェアで実現されているＴＣＰ／ＵＤＰ／ＩＰプロトコルスタックは充分に枯れた方法により実現されており、この考え方は１つの妥当な考え方ではある。しかしソフトウェア（ＣＰＵ向け）に考案された方法をそのままハードウェア化したときに、それがゲートやレジスタ（フリップフロップ）やメモリといったプリミティブなデバイスで実現される事を考えるとソフトウェアの実現方法がそのままハードウェアの適切な実現方法であるかといえば、違うと言わざるを得ない。ハードウェアは複雑なポインタ処理や、変数の動的生成や消滅、再帰処理、多くのプロセス生成、といった処理方法は苦手であり、ソフトウェアで実現されたＴＣＰ／ＩＰプロトコルスタックは複雑なポインタ処理と変数やメモリ領域の動的生成や消滅といった手順が到るところに存在している。

従来手順をそのままハードウェアで実現すると大きく以下の流れになる。（１）アプリケーションデバイスから送信指示された一連の送信データを一時的に連続した共有メモリ領域に保存する。（２）共有メモリに保存された一連の送信データを、最も上位のプロトコル制御ブロックが参照、分割、ヘッダ追加を行い、次のプロトコル制御ブロックに共有メモリのアクセス権利と共に制御を移す。各プロトコル制御ブロックは順次、各々共有メモリの参照、分割、ヘッダ追加を行う。（３）ヘッダとペイロードを連続したメモリ空間に隣接して配置する。ペイロードの全てを連続したメモリ空間に配置できない場合は別のメモリ空間にペイロードのみを配置する。（４）ヘッダと隣接したペイロードや隣接しないペイロード、フレームの連続関係はメモリ制御情報として必要な数だけメモリ内に保存される（一般にｍｂｕｆと呼ばれる）。

即ち、複雑なペイロード分割とペイロードやヘッダの管理情報（ｍｂｕｆ）の生成後にヘッダが生成され、この処理は各プロトコルスタックで各々順次実行される。

また、下記の特許文献１には、汎用データの送受信を行うプロセッサにより構成されたプロトコル汎用処理手段と、ヘッダ情報を固定的に定め又は定型的に変化させたヘッダ情報と送信データとを結合しパケットを構成する専用のプロトコル専用処理手段と、送信データによってプロトコル処理手段を適宜選択する通信制御装置が記載されている。

また、下記の特許文献２には、通信ネットワークから受信したパケットを格納する第１受信バッファと、第１受信バッファに格納されたパケットの一部である第１部分データに基づき、第１の処理を行う第１処理回路と、第１の処理と少なくとも一部を並行して、第１受信バッファに格納されたパケットにおける、第１部分データとは異なる部分である第２部分データを、第１受信バッファから受け取って格納する第２受信バッファと、第２受信バッファに格納された第２部分データに基づき、第１の処理より長い処理時間を要する第２の処理を行う第２処理回路とを備える半導体回路デバイスが記載されている。

また、下記の特許文献３には、選択された分割データに対するプロトコル制御情報を生成して、分割データの先頭前方又は末尾後方に書き込み、パケットを生成し、プロトコル制御情報及び分割データをまとめて１パケットとして送信するデータ伝送装置が記載されている。

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

しかしながら以下の問題が発生する。（１）ハードウェアが元々持つ並列処理能力を発揮できない。また（２）メモリ管理方法もポインタ処理が多用されていてハードウェアで処理しにくい。

本発明の目的は、ハードウェアが持つ並列処理能力を有効活用することにより、高速なフレーム生成を実現することである。

本発明の通信制御装置は、送信データを送信するためのフレーム個数及びフレーム長を算出する算出手段と、前記算出手段による算出の結果を基に送信データをフレーム単位に分割するペイロード分割手段と、前記ペイロード分割手段による送信データの分割と並行して、前記算出手段による算出の結果を基に前記フレーム単位の送信データに付加すべきヘッダを生成するヘッダ生成手段と、を有し、前記ヘッダ生成手段は、複数レイヤのプロトコルのヘッダを並列して生成することを特徴とする。

また、本発明の通信制御方法は、通信制御装置が行う通信制御方法であって、送信データを送信するためのフレーム個数及びフレーム長を算出する算出ステップと、前記算出ステップにおける算出の結果に基づいて、送信データをフレーム単位に分割する分割ステップと、前記分割ステップにおける送信データの分割と並列して開始されるステップであり、前記算出ステップにおける算出の結果に基づいて、前記フレーム単位の送信データに付加すべきヘッダを生成するヘッダ生成ステップと、を有し、前記ヘッダ生成ステップでは、複数レイヤのプロトコルのヘッダを並列的に生成することを特徴とする。

本発明によれば、ハードウェアが持つ並列処理能力を有効に活用し、送信データをフレーム単位に分割する処理と、複数レイヤのプロトコルのヘッダを生成する処理と、を並列して実行するので、高速なフレーム生成を実現できる。

（第１の実施形態）
図１は、本発明の第１の実施形態による通信制御装置の構成例を示すブロック図である。以下、図１を用いてその構成を説明する。

［アプリケーションデバイス］
アプリケーションデバイス（１０１）は、送信要求（１０６）と送信データ長（１０７）をフレーム個数フレーム長算出部（１０２）に出力し、送信データ（１１０）をペイロード分割部（１０３）に出力する。アプリケーションデバイス（１０１）には、２つの種類が想定される。１つ目はコンスタントビットレート（単位時間あたりの情報量が一定）のデバイスである。２つ目はバリアブルビットレート（単位時間あたりの情報量が一定ではないが、単位時間辺りの情報量は明示される）のデバイスである。その他にバリアブルビットレートのデバイスからの情報を一時的にバッファリングし定期的に一定量の情報を出力する様シェーピングするデバイスである場合も想定されるがこれは１つ目の種類のデバイスと同じと見なせる。また、サンプリング周波数で予め規定された量子化ビットレートでＲＡＷ情報を出力してくるデバイスも想定できるが、これは１つ目の種類のデバイスと同様に見なすことが出来る。これら全てのアプリケーションデバイス（１０１）に接続される本実施形態による通信制御装置は、アプリケーションデバイス（１０１）とのインタフェースにおいて、送信要求（１０６）、送信データ長（１０７）、送信データ（１１０）を受ける事とする。

［フレーム個数フレーム長算出部］
フレーム個数フレーム長算出部（１０２）は、アプリケーションデバイス（１０１）から入力された送信要求（１０６）をトリガに、同じく入力された送信データ長（１０７）を基に送信データを幾つのフレームに分割して出力すべきかを算出する。

図２２を用いてペイロード長とヘッダ数算出の流れについて詳説する。フレーム個数フレーム長算出部（１０２）は、アプリケーションデバイス（１０１）からの送信要求（１０６）を受信すると併せて、その一度の送信要求で送信したいデータの長さを送信データ長（１０７）として受け取る（ステップ３０１、３０２）。するとフレーム個数フレーム長算出部（以後ＦＦＣと呼ぶ）はフレーム数（ＦＬＭ＿ＣＯＵＮＴ）、先頭フレームペイロード長（ＨＥＡＤ＿ＰＡＹ＿ＬＥＮ）、中間フレームペイロード長（ＭＩＤ＿ＰＡＹ＿ＬＥＮ）、最終フレームペイロード長（ＦＩＮ＿ＰＡＹ＿ＬＥＮ）を算出する必要があるが、これらをまず初期化する（ステップ３０３）。フレームをどの様な長さの単位で送信するかについてはＴＣＰ／ＵＤＰを想定した場合、インタフェースのＭＴＵ又はＴＣＰのＭＳＳが想定されるが、ここではまずインタフェースのＭＴＵを取得する（ステップ３０４）。また、ＴＣＰ／ＵＤＰ／ＩＰから形成されるフレームを扱う場合にフレームのペイロード長を算出する為には各々のプロトコルヘッダの長さを鑑みる必要があるのでＩＰＨＬ（ＩＰ Ｈｅａｄｅｒ Ｌｅｎｇｔｈ）及びＵＤＰＨＬ（ＵＤＰ Ｈｅａｄｅｒ Ｌｅｎｇｔｈ）及びＴＣＰＨＬ（ＴＣＰ Ｈｅａｄｅｒ Ｌｅｎｇｔｈ）を規定する（ステップ３０５）。このステップ３０５では、それぞれ基本のヘッダ長を示してあるが各プロトコルにおいてオプションヘッダを想定する場合はこの場でオプションヘッダ長まで加味したヘッダ長を規定する。次にコネクションの種別についてＴＣＰかＵＤＰか又はＲＡＷであるか、を識別する。コネクション種別は予めＦＦＣ（１０２）にて保持しておく方法とコネクション識別子を基に導出する方法が考えられる（ステップ３０６）。

ＵＤＰの場合は送信データ長がインタフェース層ＭＴＵ−ＩＰＨＬ−ＵＤＰＨＬ以下であるかを確認する（ステップ３１１）。そうである場合は１つのフレームに与えられた送信データが全て格納可能であるのでフレーム数１、先頭フレームペイロード長＝送信データ長である、とする（ステップ３０８）。そうでない場合は送信データを複数のフレームに分割する必要がある。この分割数や各ペイロード長を算出する作業は仮にフレームを送信していった場合にどうなるかという事を想定しながら分割作業を進めていく。まず仮の送信済みデータ長（ＤＯＮＥ＿ＬＥＮ）を０とする（ステップ３１２）。次に未送信データ長がフラグメントペイロード長以下であるかを確認する。これは最終フラグメントであるかという判断をおこなっており、未送信データ長は送信データ長から仮の送信済みデータ長（ＤＯＮＥ＿ＬＥＮ）を減算して求め、これとＭＴＵ−ＩＰＨＬの長さを比較する等という方法が想定できる（ステップ３１３）。ここまでの事前チェックの流れにおいては、初めての比較では未送信データ長がフラグメントペイロード長以下であるということは起き得ない。次にフレーム数（ＦＬＭ＿ＣＯＵＮＴ）をインクリメントする（ステップ３１４）。送信済みデータ長が０であれば（ステップ３１５）、先頭フレームであると判断されるので先頭フレームのペイロード長はＭＴＵ−ＩＰＨＬ−ＵＤＰＨＬであり、仮の送信済みデータ長はＭＴＵ−ＩＰＨＬ−ＵＤＰＨＬであると決定される（ステップ３１７）。先頭フレームではない場合は中間フレームであるから中間フレーム長をＭＴＵ−ＩＰＨＬ、仮の送信済みデータ長（ＤＯＮＥ＿ＬＥＮ）をＤＯＮＥ＿ＬＥＮ＋（ＭＴＵ−ＩＰＨＬ）とする（ステップ３１６）。これらの後再び未送信データ長がフラグメントペイロード長以下であるか、即ち最終フラグメントであるかを判断し（ステップ３１３）、もし最終フラグメントであれば最終フレームは送信データ長からＤＯＮＥ＿ＬＥＮを減算する事で求められる（ステップ３１８）。その後最終フラグメントフレームの分のフレーム数をカウントアップ（ＦＬＭ＿ＣＯＵＮＴ＋＋）し（ステップ３１９）、フレーム数、先頭フレームペイロード長、中間フレームペイロード長、最終フレームペイロード長が決定出力される（ステップ３１０）。

コネクション種別がＲＡＷの場合はフレーム数は１つで、フレームペイロード長はＭＴＵ−ＩＰＨＬの範囲内に収まるべきであり、もしそうでないとしてもその様に送信データを切り落として送信する事を想定している。又はアプリケーションデバイス（１０１）にエラーとして応答を送るという方法も考えられる（ステップ３０８、３０９）。

コネクション種別がＴＣＰの場合はフレーム長はＭＳＳ（マキシマムセグメントサイズ）が基本となるので取得する（ステップ３２０）。次に仮の送信済みデータサイズ（ＤＯＮＥ＿ＬＥＮ）をゼロに初期化し（ステップ３２１）、（仮の）未送信データ長がＭＳＳ以下であるかをチェックする（ステップ３２２）。もしＭＳＳ以下であれば与えられた送信データは次の１セグメントで送信完了できる事が判断できる。もしＭＳＳより大きければフレーム数をインクリメント（ステップ３２３）し、先頭セグメントであれば（この判断はＤＯＮＥ＿ＬＥＮが０であるか否かで行う）（ステップ３２４）、先頭フレーム長はＭＳＳであり、ＤＯＮＥ＿ＬＥＮはＭＳＳとなる（ステップ３２６）。再び仮の未送信データ長がＭＳＳ以下であるかを確認し、まだＭＳＳより大きい場合はフレーム数をカウントアップし今度は中間フレームペイロード長をＭＳＳとし送信済みデータ長ＤＯＮＥ＿ＬＥＮ＝ＤＯＮＥ＿ＬＥＮ＋ＭＳＳとする（ステップ３２５）。再び未送信データ長がＭＳＳ以下であるかを確認し、もし最終セグメントであると判断されれば最終フレームとして最終フレーム長を送信データ長からＤＯＮＥ＿ＬＥＮを減算した値とし（ステップ３２７）、最終フレームを送信フレーム数としてカウントする（ステップ３２８）。

上述の様にフレーム数、先頭フレームペイロード長、中間フレームペイロード長、最終フレームペイロード長が決定出力される（ステップ３１０）。これら４つの値をフレーム個数とフレーム長に関する値とし、ペイロード分離部（１０３）とプロトコル制御部（１１５）及びヘッダ／ペイロード合成部（１２０）に出力する。

［フレーム個数フレーム長算出部が期待するタイミングについて］
本通信制御装置ではアプリケーションデバイス（１０１）からの送信要求（１０６）と送信データ長（１０７）を基に、まずフレーム個数とフレーム長の算出を行い、その後、ペイロード分割とヘッダ生成を開始する。これはペイロード分割とヘッダ生成を同時に開始する事を狙ったものである。

この事について図２を用いて説明する。アプリケーションデバイス（２０１）が送信指示（２１０）と送信データ長（２１１）をフレーム個数フレーム長算出部（ＦＦＣ）（２０２）に送信（これら２つの送信は同期して同時に行われる事を想定）すると、ＦＦＣ（２０２）では先に述べた手順でペイロード長とフレーム個数を算出しこの情報をペイロード分割部（２０３）とプロトコル制御部（２０５）に送出する（ヘッダ／ペイロード合成部（１２０）にも送出するが図２の説明においては省略する）。ペイロード長（２１２）とフレーム個数（２１３）は同期して同時に送信されることを想定し、ペイロード分割部（２０３）とプロトコル制御部（２０５）はほぼ同時にペイロード長（２１２）とフレーム個数（２１３）を受信することを想定している。この受信時刻をｔ１とする。この時刻ｔ１よりペイロード分割部（２０３）ではアプリケーションデバイス（２０１）からのデータ受信を開始し、ヘッダ生成部ではヘッダ生成を開始する。ペイロード分割部（２０３）がアプリケーションデバイス（２０１）からの送信データ受信を開始すると（２１４）、アプリケーションデバイス（２０１）は送信データを先頭から順次ペイロード分割部（２０３）に送信していく。この時アプリケーションデバイス（２０１）とペイロード分割部（２０３）は同期をとりながらデータの送受信を行っていく。例えばアプリケーションデバイス（２０１）からの送信データが３フレーム相当の長さであったとすれば、アプリケーションデバイス（２０１）からのデータの送信時間は（２５４）（２５５）（２５６）で示された時間かかる。アプリケーションデバイス（２０１）からペイロード分割部（２０３）にデータ送信を行う際、１フレーム目に相当する長さのデータを送信終了した時刻をｔ３、２フレーム目に相当する長さのデータを送信終了した時刻をｔ４、３フレーム目に相当する長さのデータを送信終了した時刻をｔ５とする。図ではアプリケーションデバイス（２０１）からペイロード分割部（２０３）に送信するデータのフレーム区切りにまでの所要時間を（２５４）（２５５）（２５６）にて示しているが、アプリケーションデバイス（２０１）にとってはフレームの切れ目の意識はなく、連続して（但し同期を取りながら、例えば（２２２）（２２７）（２３２）の様に）ペイロード分割部（２０３）にデータを送信する。ペイロード分割部（２０３）では連続して受信したアプリケーションデバイスデータをフレーム単位に分割しながらフレームペイロード格納メモリ（２０４）にアプリケーションデータをフレーム単位で格納していく（２１６）（２２５）（２３０）。一方、プロトコル制御部（２０５）はペイロード長（２１２）とフレーム個数（２１３）を受信すると時刻ｔ１より各ヘッダ生成部（２０６）（２０７）（２０８）（２０９）にヘッダ生成の依頼を出しヘッダ生成を開始する。各ヘッダ生成部ではペイロード長（２１２）やフレーム個数（２１３）が判明しているのでフレームペイロードがアプリケーションデバイス（２０１）から受信されるより先にヘッダ生成を進めることが出来る。ヘッダ生成を行っている期間を（２４０）（２４１）（２４２）（２４３）（２４４）（２４５）（２４６）（２４７）で示している。ここでは１つの送信データについて３つのフレーム用にヘッダを生成することを想定し図示している。ここで生成されるヘッダの長さはＴＣＰ、ＵＤＰ、ＩＰ、ＭＡＣヘッダのいずれも数バイトや２０−３０バイト程度である。これに対し１つのフレームやセグメントのペイロード長は、数百から１５００バイト程度（インタフェース層がイーサネット（登録商標）の場合）と想定される。即ちアプリケーションデバイス（２０１）から１フレーム分の送信データを受信完了した時刻ｔ３に対し、ヘッダ生成部がヘッダ生成する時間は充分に短く済むはずであり、１つ目のフレームのヘッダ生成完了時刻はｔ２で図示される。また、２つ目３つ目のフレーム用のヘッダを生成したとしても時刻ｔ３近辺又はｔ３よりずっと以前に、全ヘッダを生成完了している可能性が高い。即ちｔ３には１つ目のフレームは送信可能となる。

ところで、ここでチェックサムに関する問題が発生する。ヘッダの殆どの部分はペイロードとの依存なく生成可能だが、データグラムチェックサムやＩＰパケットチェックサムは送信データ（ペイロード）から算出しなければならない。但しＵＤＰにはチェックサムを無効とするオプションがあり、この場合は図２に示す様なＵＤＰとＩＰのヘッダ生成とペイロード分割の完全な独立並行処理が可能となる。

また、ＴＣＰヘッダのチェックサムを考慮した場合も本実施形態によるヘッダ生成とペイロード分割の独立並行処理がスループットに貢献する事ができる。これについて図４を用いて説明する。アプリケーションデバイス（２０１）から１セグメント分のデータを受信する時刻がｔ７とすればｔ７直前には１セグメントのチェックサム値は算出可能であり、予め時刻ｔ１直後に期間（２６３）にて生成された１つ目のセグメントのＴＣＰヘッダに時刻ｔ７直前に算出されたセグメントチェックサムを追加して１つ目のセグメント用のＴＣＰヘッダ生成を完了すればｔ７直後には１つ目のセグメントを送信可能となる。同様に時刻ｔ８直前には２つ目のセグメントのチェックサム値が算出可能であり、そのチェックサム値を予め期間（２６４）で生成された２つ目のＴＣＰヘッダに追加して２つ目のＴＣＰヘッダを完成しｔ８直後には２つ目のセグメントが送出可能になる。さらにｔ９直後には３つ目のセグメントが送出可能になる。

ＵＤＰヘッダのデータグラムチェックサムを考慮した場合について図３に示す。データグラム用のＵＤＰヘッダを予め時刻ｔ１直後に期間（２７５）で生成したとしても１データグラムのデータグラムチェックサムが算出されるのはデータグラム全体をアプリケーションデバイス（２０１）からペイロード分割部（２０３）が受信完了した時刻ｔ１０でありこの時点で予め生成してあったＵＤＰヘッダにＵＤＰデータグラムチェックサムを追加し、ｔ１０直後にＵＤＰフレームが送出される事になる。この場合は２つ目、３つ目のフレームは既に生成完了しているので１つ目のフレーム送信直後に２つ目、３つ目のフレームを送信可能である。また、もしフレームの順番を保持して送出する必要がないのであれば、２つ目、３つ目のフレームを送出してから１つ目のＵＤＰヘッダつきフレームを送出する事も出来る。

［ペイロード分割部の分割］
ペイロード分割部（１０３）ではフレーム個数フレーム長算出部（１０２）から与えられたフレーム個数とフレーム長に関する入力（１０９）を基にアプリケーションデバイス（１０１）から与えられた送信データ（１１０）を分割しながらフレームペイロードとしてペイロードＴＸメモリ（１０４）に書き込み保存を行う（１１１）。ペイロード分割部（１０３）は、フレームペイロード書き込みが完了したらヘッダ／ペイロード合成部（１２０）に対しフレームペイロードの送信準備が出来た事を通知する（１３６）。

［ペイロード分割部のチェックサム］
ペイロード分割部（１０３）ではフレーム個数フレーム長算出部（１０２）から与えられたフレーム個数とフレーム長に関する入力（１０９）を基にアプリケーションデバイス（１０１）から与えられた送信データ（１１０）を分割しながらフレームペイロードとしてペイロードＴＸメモリ（１０４）に書き込み保存を行う（１１１）際、フレームペイロードのチェックサムをフレーム毎に求め、ＵＤＰヘッダ生成部（１１７）及び、ＴＣＰヘッダ生成部（１１６）にチェックサム値を伝える（１３５）。

［ＴＸメモリ］
ＴＸメモリ（１０４）では１つの送信要求に伴う一連の送信データを、送信要求毎、フレームペイロードＦＩＦＯにフレームペイロードの列として保存している。図５に示す様にＴＸメモリ（１０４）内部には１つの送信要求に伴い１つのＦＩＦＯが割り当てられ（３４０）、例えばここでは１つの送信要求による送信データが５つのフレームペイロードから成ることを示している。本図ではフレームペイロード１（先頭フレーム）からフレームペイロード５（最後尾フレーム）がＦＩＦＯに蓄えられているがフレーム単位での送信が行われる場合はこの様に５つのフレームが溜まることはない。各々のフレームペイロードはＦＩＦＯに挿入された直後にペイロード読み出し部（１０５）により抜き出され送信される事も考えられる。

［ペイロード読み出し部］
ペイロード読み出し部（１０５）ではヘッダ／ペイロード合成部（１２０）からの、１つのペイロード読み出し指示（１１４）に対し、送信すべきフレームペイロードをＴＸメモリ（１０４）から１つ取り出し、ヘッダ／ペイロード合成部（１２０）へ出力する（１１３）。

［プロトコル制御部］
プロトコル制御部（１１５）ではフレーム個数フレーム長算出部（１０２）からフレーム個数、先頭フレームのペイロード長、中間フレームのペイロード長、最終フレームのペイロード長の４つの値（１０８）を受信すると、送信フレームがＴＣＰなのかＵＤＰなのかを判断し、フレーム送信に必要なプロトコルヘッダを生成するための情報を収集し、ヘッダ生成指示とヘッダ生成情報を各プロトコルヘッダ生成部（１１６〜１１９）に同時配信する。収集する各種情報は静的に設定されている場合と動的にテーブル検索を行う場合がある。動的なテーブルとしては、コネクションに付随する宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポート、送信元ポートを割り出すアドレステーブルや、ＩＰのルーティングテーブルなどがあげられる。

ＵＤＰ／ＩＰのフレーム送信時に送信データグラムが３つのフラグメントフレームに分割された場合の例を図６に示す。プロトコル制御部（１１５）はフレーム個数フレーム長算出部（１０２）からの通知により、プロトコルタイプがＵＤＰ、フレーム個数が３個、ペイロード長が先頭フレームがＰＬ０の長さ、中間フレームがＰＬ１の長さ、最終フレームがＰＬ２の長さと判断する。次にＵＤＰ、ＩＰ、ＭＡＣヘッダ生成に必要な情報を収集し、各プロトコルヘッダ生成部にヘッダ生成指示と共にヘッダ生成情報を出力する（１２３〜１２５）。ＵＤＰヘッダ生成部（１１７）に出力するヘッダ生成情報としては、送信元ポート番号、宛先ポート番号、ＵＤＰデータ長を出力（１２３）する。ＩＰヘッダ生成部（１１８）に出力するヘッダ生成情報としてはヘッダ生成数３とヘッダ長、ＴＯＳ、識別子、ＴＴＬ、プロトコル、送信元ＩＰアドレス、宛先ＩＰアドレスを１フレーム分と、全長、フラグ、フラグメントオフセットを３フレーム分を出力（１２４）する。この時、先頭フレームはＩＰヘッダ長とＵＤＰヘッダ長とＰＬ０、中間フレームはＩＰヘッダ長とＰＬ１、最終フレームはＩＰヘッダ長とＰＬ２を加算した値が全長として出力される。ＭＡＣヘッダ生成部（１１９）に出力するヘッダ生成情報としては、ヘッダ生成数３と宛先ＭＡＣアドレス、送信元ＭＡＣアドレス、タイプレングスを１フレーム分を出力（１２５）する。

ＴＣＰ／ＩＰのフレーム送信時に送信データグラムが３つのセグメントに分割された場合の例を図７に示す。プロトコル制御部（１１５）はフレーム個数フレーム長算出部（１０２）からの通知により、プロトコルタイプがＴＣＰ、フレーム個数が３個、ペイロード長が先頭フレームＰＬ０、中間フレームＰＬ１、最終フレームＰＬ２と判断する。次にＴＣＰ、ＩＰ、ＭＡＣヘッダ生成に必要な情報を収集し、各プロトコルヘッダ生成部にヘッダ生成指示と共にヘッダ生成情報を出力する。ＴＣＰヘッダ生成部（１１６）に出力するヘッダ生成情報としてはヘッダ生成数が３と送信元ポート番号、宛先ポート番号、シーケンス番号、確認応答番号、ヘッダ長、フラグビット、ウィンドウサイズ、緊急ポインタを３フレーム分出力（１２２）する。ＩＰヘッダ生成部（１１８）に出力するヘッダ生成情報としてはヘッダ生成数３とヘッダ長、ＴＯＳ、フラグ、オフセット、ＴＴＬ、プロトコル、送信元ＩＰアドレス、宛先ＩＰアドレスを１フレーム分と、全長、識別子を３フレーム分出力（１２４）する。この時、先頭フレームはＩＰヘッダ長とＴＣＰヘッダ長とＰＬ０、中間フレームはＩＰヘッダ長とＴＣＰヘッダ長とＰＬ１、最終フレームはＩＰヘッダ長とＴＣＰヘッダ長とＰＬ２を加算した値が全長として出力される。ＭＡＣヘッダ生成部（１１９）に出力するヘッダ生成情報としては、ヘッダ生成数３と宛先ＭＡＣアドレス、送信元ＭＡＣアドレス、タイプレングスを１フレーム分出力（１２５）する。

［ＴＣＰヘッダ生成部］
ＴＣＰヘッダ生成部（１１６）ではプロトコル制御部（１１５）からのヘッダ生成指示及びヘッダ生成情報に基づきヘッダ生成を開始し、ヘッダ生成完了後にヘッダ／ペイロード合成部（１２０）にＴＣＰヘッダ生成完了通知（１２６）を行う。ヘッダ生成のフローチャートを図８に示す。ステップＳ８０１においてＴＣＰヘッダ生成指示をプロトコル制御部（１１５）から受信したかを確認する。もしＴＣＰヘッダ生成指示を受信したら、プロトコル制御部（１１５）からＴＣＰヘッダ情報を取得する（ステップＳ８０２）。ＴＣＰヘッダ情報はヘッダ生成数とヘッダ生成数分の送信元ポート番号、宛先ポート番号、シーケンス番号、確認応答番号、ヘッダ長、フラグビット、ウィンドウサイズ、緊急ポインタ及び擬似ヘッダ用の宛先ＩＰアドレス、送信元ＩＰアドレス、セグメント長（ＴＣＰヘッダ長＋ペイロード長）である。取得したヘッダ生成情報から擬似ヘッダとチェックサム以外のＴＣＰヘッダを作成する（ステップＳ８０３）。次にフレームごとのペイロードサムをペイロード分割部（１０３）より受信したかの判断を行い、もし受信していれば（ステップＳ８０４:Ｙｅｓ）、擬似ヘッダとチェックサム以外のＴＣＰヘッダとペイロードサムからＴＣＰのチェックサムを算出する（ステップＳ８０５）。ステップＳ８０５で算出したチェックサムをステップＳ８０６にてＴＣＰヘッダのチェックサムフィールドに設定し、１フレーム分のＴＣＰヘッダの生成を完了する。１フレーム分のＴＣＰヘッダの生成が完了すると、ステップＳ８０７においてヘッダ／ペイロード合成部（１２０）にＴＣＰヘッダ生成完了通知（１２６）を行い、ヘッダ生成数分のヘッダを生成したかの判断を行う（ステップＳ８０８）。もし、ヘッダ生成数分のヘッダを生成していない場合（ステップＳ８０８：Ｎｏ）は、ステップＳ８０３に戻り次のヘッダの生成を開始する。ヘッダ生成数分のヘッダを生成した場合（ステップＳ８０８：Ｙｅｓ）は、送信データグラムに付加しなければならないＴＣＰヘッダを全て生成したとしてＴＣＰヘッダ生成を終了する。ＴＣＰヘッダ生成部（１１６）で作成するヘッダのフォーマットを図１４に、擬似ヘッダフォーマットを図１５に示す。

また、ＴＣＰヘッダ生成部（１１６）はヘッダ／ペイロード合成部（１２０）からの出力要求（１２６）を受信すると、生成した順番にＴＣＰヘッダをヘッダ／ペイロード合成部（１２０）に出力（１３０）する。

［ＵＤＰヘッダ生成部］
ＵＤＰヘッダ生成部（１１７）ではプロトコル制御部（１１５）からのヘッダ生成指示及びヘッダ生成情報に基づきヘッダ生成を開始し、ヘッダ生成完了後にヘッダ／ペイロード合成部（１２０）にＵＤＰヘッダ生成完了通知（１２７）を行う。ヘッダ生成のフローチャートを図９に示す。ステップＳ９０１においてＵＤＰヘッダ生成指示をプロトコル制御部（１１５）から受信したかを確認する。もしＵＤＰヘッダ生成指示を受信したら、プロトコル制御部（１１５）からＵＤＰヘッダ生成情報を取得する（ステップＳ９０２）。ＵＤＰヘッダ生成情報は、フレーム個数、送信元ポート番号、宛先ポート番号、ＵＤＰデータ長である。取得したヘッダ生成情報から擬似ヘッダとチェックサム以外のＵＤＰヘッダを作成する（ステップＳ９０３）。次にフレームごとのペイロードサムをペイロード分割部（１０３）より受信したかの判断を行い、もし受信していれば（ステップＳ９０４：Ｙｅｓ）、ステップＳ９０５にてフレームごとのペイロードサムを加算する。次にステップＳ９０６にてフレーム個数分のペイロードサムをペイロード分割部（１０３）より受信したかの判断を行い、もし全てのペイロードサムを受信していなければ（ステップＳ９０６：Ｎｏ）、ステップＳ９０４に戻り次のフレームペイロード受信待ち状態になる。もし全てのペイロードサムを受信していれば（ステップＳ９０６：Ｙｅｓ）、ステップＳ９０７にて擬似ヘッダとチェックサム以外のＵＤＰヘッダとペイロードサムの合計からＵＤＰチェックサムを算出する。ステップＳ９０７で算出したチェックサムをステップＳ９０８にてＵＤＰヘッダのチェックサムフィールドに設定し、ＵＤＰヘッダの生成を完了する。ＵＤＰヘッダの生成が完了すると、ステップＳ９０９においてヘッダ／ペイロード合成部（１２０）にＵＤＰヘッダ生成完了通知（１２７）を行い、ＵＤＰヘッダ生成を終了する。ＵＤＰヘッダ生成部（１１７）で作成するヘッダのフォーマットを図１６に、擬似ヘッダフォーマットを図１７に示す。

また、ＵＤＰヘッダ生成部（１１７）はヘッダ／ペイロード合成部（１２０）からの出力要求（１２７）を受信すると、生成したＵＤＰヘッダをヘッダ／ペイロード合成部（１２０）に出力（１３１）する。

［ＩＰヘッダ生成部］
ＩＰヘッダ生成部（１１８）ではプロトコル制御部（１１５）からのヘッダ生成指示及びヘッダ生成情報に基づきヘッダ生成を開始し、ヘッダ生成完了後にヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了通知（１２８）を行う。ヘッダ生成のフローチャートを図１０に示す。ステップＳ１００１においてＩＰヘッダ生成指示をプロトコル制御部（１１５）から受信したかを確認する。もしＩＰヘッダ生成指示を受信したら、プロトコル制御部（１１５）からＩＰヘッダ情報を取得する（ステップＳ１００２）。次にステップＳ１００３にてヘッダ生成数が２個以上であるかの判断を行う。ヘッダ生成数が２個以上であるということは、ＴＣＰの場合はデータグラムがセグメント化されていることを意味し、ＵＤＰの場合はデータグラムがフラグメントされていることを意味する。もし、ヘッダ生成数が２個以上でない場合は（ステップＳ１００３：Ｎｏ）、ヘッダ生成情報からＩＰヘッダを生成し（ステップＳ１００４）、ヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了通知を行い（ステップＳ１００５）、ＩＰヘッダ生成を終了する。ヘッダ生成数が２個以上である場合（ステップＳ１００３：Ｙｅｓ）は、まずフレームごとに変化しないＩＰヘッダフィールドを設定する（ステップＳ１００６）。フレームごとに変化しないＩＰヘッダフィールドとは上位レイヤがＴＣＰの場合は、バージョン、ヘッダ長、ＴＯＳ、フラグ、フラグメントオフセット、ＴＴＬ、プロトコル、送信元ＩＰアドレス、宛先ＩＰアドレスを示し、上位レイヤがＵＤＰの場合はバージョン、ヘッダ長、ＴＯＳ、識別子、ＴＴＬ、プロトコル、送信元ＩＰアドレス、宛先ＩＰアドレスを示す（図１８及び図１９参照）。次にステップＳ１００７において先頭フレームのフレームごとに変化するＩＰヘッダフィールドを設定する。フレームごとに変化するＩＰヘッダフィールドとは上位レイヤがＴＣＰの場合は、全長、識別子、ヘッダチェックサムを示し、上位レイヤがＵＤＰの場合は、全長、フラグ、フラグメントオフセット、ヘッダチェックサムを示す（図１８及び図１９参照）。フレームごとに変化するＩＰヘッダフィールドの設定が終了するとステップＳ１００８においてヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了通知を行う。次にステップＳ１００９において次に生成するＩＰヘッダでセグメント化もしくはフラグメントされた最終のフレームかの判断を行う。もし、次に生成するＩＰヘッダで最終でない場合は（ステップＳ１００９：Ｎｏ）、ステップＳ１０１０にて中間フレームのフレームごとに変化するＩＰヘッダフィールドを設定し、ステップＳ１０１１にてヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了通知を行い、再び次にＩＰヘッダで最終でないかの判断（ステップＳ１００９）を行う。ステップＳ１００９において、もし次に生成するＩＰヘッダで最終である場合はステップＳ１０１２にて最終フレームのフレームごとに変化するＩＰヘッダフィールドを設定し、ステップＳ１０１３にてヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了通知（１２８）を行い、送信データグラムに付加しなければならないＩＰヘッダを全て生成したとしてＩＰヘッダ生成を終了する。

また、ＩＰヘッダ生成部（１１８）はヘッダ／ペイロード合成部（１２０）からの出力要求（１２８）を受信すると、生成した順番にＩＰヘッダをヘッダ／ペイロード合成部（１２０）に出力（１３２）する。

［ＭＡＣヘッダ生成部］
ＭＡＣヘッダ生成部（１１９）ではプロトコル制御部（１１５）からのヘッダ生成指示及びヘッダ生成情報に基づきヘッダ生成を開始し、ヘッダ生成完了後にヘッダ／ペイロード合成部（１２０）にＭＡＣヘッダ生成完了通知（１２９）を行う。ＭＡＣヘッダ生成部（１１９）はプロトコル制御部（１１５）からＭＡＣヘッダ生成指示を受信したら、ＭＡＣヘッダ情報を取得する。ＭＡＣヘッダ生成情報は、ヘッダ生成数、送信元ＭＡＣアドレス、宛先ＭＡＣアドレス、タイプレングスである。１つの送信データグラムがフラグメントやセグメント化によって複数のＭＡＣヘッダを生成する必要がある場合においても、そのヘッダの内容は同一であるため１つのＭＡＣヘッダ生成が完了するとＭＡＣヘッダ生成完了通知（１２９）をヘッダ／ペイロード合成部（１２０）にヘッダ生成数回出力する。ＭＡＣヘッダ生成部（１１９）で作成するＭＡＣヘッダのフォーマットを図２１に示す。

また、ＭＡＣヘッダ生成部（１１９）はヘッダ／ペイロード合成部（１２０）からの出力要求（１２９）を受信すると、生成したＭＡＣヘッダをヘッダ／ペイロード合成部（１２０）に出力（１３３）する。

［ヘッダ／ペイロード合成部］
ヘッダ／ペイロード合成部（１２０）はフレーム個数フレーム長算出部（１０２）からのフレーム個数から生成すべきヘッダの個数を割り出す。次に、各プロトコルヘッダ生成部からのヘッダ完了通知とペイロード分割部（１０３）からのペイロード送信準備完了通知により、送信フレームに必要なヘッダとペイロードの準備が完了していることを認識し、ＴＣＰ／ＩＰの場合はＭＡＣヘッダ生成部（１１９）、ＩＰヘッダ生成部（１１８）、ＴＣＰヘッダ生成部（１１６）、ペイロード読み出し部（１０５）の順に出力要求を行い、ヘッダ及びペイロードを読み出してフレームとして合成し、フレーム送出部（１２１）に出力する。ＵＤＰ／ＩＰの場合は先頭フレームはＭＡＣヘッダ生成部（１１９）、ＩＰヘッダ生成部（１１８）、ＵＤＰヘッダ生成部（１１７）、ペイロード読み出し部（１０５）の順に出力要求を行い、中間、最終フレームはＭＡＣヘッダ生成部（１１９）、ＩＰヘッダ生成部（１１８）、ペイロード読み出し部（１０５）の順に出力要求を行い、ヘッダ及びペイロードを読み出してフレームとして合成しフレーム送出部（１２１）に出力する。ペイロードを持たないフレームを送信する場合はヘッダのみ読み出して、フレームとして合成し、フレーム送出部（１２１）に出力する。

［フレーム送出部］
フレーム送出部（１２１）では、ヘッダ／ペイロード合成部（１２０）から出力されるフレームを通信制御装置外に送信する機能を有する。ＩＥＥＥ８０２．３に準拠し、プリアンブルの付加、フレームパディング、ＣＲＣの生成等を行う。

（第２の実施形態）
図１１は、本発明の第２の実施形態による通信制御装置の構成例を示すブロック図である。図１１を用いてその構成を説明する。

［アプリケーションデバイス］
アプリケーションデバイス（１０１）は、送信要求（１０６）と送信データ長（１０７）をフレーム個数フレーム長算出部（１０２）に出力し、送信データ（１１０）をペイロード分割部（１０３）に出力する。アプリケーションデバイス（１０１）には、２つの種類が想定される。１つ目はコンスタントビットレート（単位時間あたりの情報量が一定）のデバイスである。２つ目はバリアブルビットレート（単位時間あたりの情報量が一定ではないが、単位時間辺りの情報量は明示される）のデバイスである。その他にバリアブルビットレートのデバイスからの情報を一時的にバッファリングし定期的に一定量の情報を出力する様シェーピングするデバイスである場合も想定されるがこれは１つ目の種類のデバイスと同じと見なせる。また、サンプリング周波数で予め規定された量子化ビットレートでＲＡＷ情報を出力してくるデバイスも想定できるが、これは１つ目の種類のデバイスと同様に見なすことが出来る。これら全てのアプリケーションデバイス（１０１）に接続される本実施形態による通信制御装置は、アプリケーションデバイス（１０１）とのインタフェースにおいて、送信要求（１０６）、送信データ長（１０７）、送信データ（１１０）を受ける事とする。

［フレーム個数フレーム長算出部］
フレーム個数フレーム長算出部（１０２）は、アプリケーションデバイス（１０１）から入力された送信要求（１０６）をトリガに、同じく入力された送信データ長（１０７）を基に送信データを幾つのフレームに分割して出力すべきかを算出する。ペイロード長とヘッダ数算出の流れは、図２２の上記の説明と同じである。上述の様にフレーム数、先頭フレームペイロード長、中間フレームペイロード長、最終フレームペイロード長をフレーム個数とフレーム長に関する値とし、ペイロード分離部（１０３）とプロトコル制御部（１１５）及びヘッダ／ペイロード合成部（１２０）に出力する。

［ペイロード分割部の分割］
ペイロード分割部（１０３）ではフレーム個数フレーム長算出部（１０２）から与えられたフレーム個数とフレーム長に関する入力（１０９）を基にアプリケーションデバイス（１０１）から与えられた送信データ（１１０）を分割しながらフレームペイロードとしてペイロードＴＸメモリ（１０４）に書き込み保存を行う（１１１）。ペイロード分割部（１０３）は、フレームペイロード書き込みが完了したらプロトコル制御部（１１５）に対しフレームペイロードの送信準備が出来た事を通知する（１３６）。

［ペイロード分割部のチェックサム］
ペイロード分割部（１０３）ではフレーム個数フレーム長算出部（１０２）から与えられたフレーム個数とフレーム長に関する入力（１０９）を基にアプリケーションデバイス（１０１）から与えられた送信データ（１１０）を分割しながらフレームペイロードとしてペイロードＴＸメモリ（１０４）に書き込み保存を行う（１１１）際、フレームペイロードのチェックサムをフレーム毎に求め、ＵＤＰヘッダ生成部（１１７）及び、ＴＣＰヘッダ生成部（１１６）にチェックサム値を伝える（１３５）。

［ＴＸメモリ］
ＴＸメモリ（１０４）では１つの送信要求に伴う一連の送信データを、送信要求毎、フレームペイロードＦＩＦＯにフレームペイロードの列として保存している。図５に示す様にＴＸメモリ（１０４）内部には１つの送信要求に伴い１つのＦＩＦＯが割り当てられ（３４０）、例えばここでは１つの送信要求による送信データが５つのフレームペイロードから成ることを示している。本図ではフレームペイロード１（先頭フレーム）からフレームペイロード５（最後尾フレーム）がＦＩＦＯに蓄えられているがフレーム単位での送信が行われる場合はこの様に５つのフレームが溜まることはない。各々のフレームペイロードはＦＩＦＯに挿入された直後にペイロード読み出し部（１０５）により抜き出され送信される事も考えられる。

［ペイロード読み出し部］
ペイロード読み出し部（１０５）ではヘッダ／ペイロード合成部（１２０）からの、１つのペイロード読み出し指示（１１４）に対し、送信すべきフレームペイロードをＴＸメモリ（１０４）から１つ取り出し、ヘッダ／ペイロード合成部（１２０）へ出力する（１１３）。

［プロトコル制御部］
プロトコル制御部（１１５）ではフレーム個数フレーム長算出部（１０２）からの指示により、フレームごとに必要なヘッダを特定してヘッダに必要な情報を収集し、各プロトコルヘッダ生成部（１１６〜１１９）にヘッダ生成指示及びヘッダ生成情報を通知する（１２２〜１２５）。図１２にプロトコル制御部（１１５）のフローチャートを示す。ステップＳ１２０１においてフレーム個数フレーム長算出部（１０２）よりフレーム個数、先頭フレームのペイロード長、中間フレームのペイロード長、最終フレームのペイロード長の４つの値（１０８）を受信したかの判断を行う。もし受信すれば（ステップＳ１２０１：Ｙｅｓ）、ステップＳ１２０２において送信フレームがＴＣＰなのかＵＤＰなのかを判断し、フレーム送信に必要なプロトコルヘッダを生成するための情報を収集する（ステップＳ１２０３）。この時、収集する情報は１つのフレームに付加されるヘッダについてのみ行われる。つまり最初は先頭フレームに付加されるヘッダのみの情報収集を行う。また、収集する各種情報は静的に設定されている場合と動的にテーブル検索を行う場合がある。動的なテーブルとしては、コネクションに付随する宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ポート、送信元ポートを割り出すアドレステーブルや、ＩＰのルーティングテーブルなどがあげられる。次にペイロード分割部（１０３）からフレームペイロード送信準備完了通知を受信したかの判断を行う（ステップＳ１２０４）。もし、フレームペイロード送信準備完了通知を受信したら（ステップＳ１２０４：Ｙｅｓ）、ステップＳ１２０５にてヘッダ情報の収集が終了しているかの判断を行う。ヘッダ情報の収集が終了した場合（ステップＳ１２０５：Ｙｅｓ）は、ステップＳ１２０６にて送信フレームに必要なヘッダを生成するヘッダ生成部にヘッダ生成指示及びヘッダ生成情報を出力する。ヘッダ生成指示を出力後はステップＳ１２０７においてフレーム個数分のヘッダ生成指示を行ったかの判断を行う。もし、フレーム個数分のヘッダ生成指示を行った（ステップＳ１２０７：Ｙｅｓ）のなら、ステップＳ１２０８においてステップＳ１２０６で作成を指示したヘッダのヘッダ送信完了通知をヘッダ／ペイロード合成部（１２０）から受信するのを待ち、ヘッダ送信完了通知を受信したら１つのデータグラムに対する全てのフレームのヘッダが送信されたとしてプロトコル制御を終了する。ステップＳ１２０７においてもしフレーム個数分のヘッダ生成指示を行っていないのならば（Ｓ１２０７：Ｎｏ）、まだ送信すべきフレームを生成しなければならないとして、ステップＳ１２０９においてステップＳ１２０６で作成を指示したヘッダのヘッダ送信完了通知をヘッダ／ペイロード合成部（１２０）から受信するのを待ち、ヘッダ送信完了通知を受信したら次のフレームのヘッダ作成を開始する（ステップＳ１２１０）。そしてステップＳ１２０３に戻る。

［ＴＣＰヘッダ生成部］
ＴＣＰヘッダ生成部（１１６）ではプロトコル制御部（１１５）からのヘッダ生成指示及びヘッダ生成情報に基づきヘッダ生成を開始し、ヘッダ生成完了後にヘッダ／ペイロード合成部（１２０）にＴＣＰヘッダ生成完了通知（１２６）を行う。ＴＣＰヘッダ生成指示をプロトコル制御部（１１５）から受信したら、プロトコル制御部（１１５）からＴＣＰヘッダ情報を取得する。ＴＣＰヘッダ情報は送信元ポート番号、宛先ポート番号、シーケンス番号、確認応答番号、ヘッダ長、フラグビット、ウィンドウサイズ、緊急ポインタ及び擬似ヘッダ用の宛先ＩＰアドレス、送信元ＩＰアドレス、セグメント長（ＴＣＰヘッダ長＋ペイロード長）である。取得したヘッダ生成情報から擬似ヘッダとチェックサム以外のＴＣＰヘッダを作成する。次にフレームごとのペイロードサムをペイロード分割部（１０３）より受信し、擬似ヘッダとチェックサム以外のＴＣＰヘッダとペイロードサムからＴＣＰのチェックサムを算出し、チェックサムをＴＣＰヘッダのチェックサムフィールドに設定し、ＴＣＰヘッダの生成を完了する。ＴＣＰヘッダの生成が完了すると、ヘッダ／ペイロード合成部（１２０）にＴＣＰヘッダ生成完了通知を行い、ＴＣＰヘッダ生成を終了し、プロトコル制御部（１１５）より次のヘッダ生成指示があるまで待機する。ＴＣＰヘッダ生成部（１１６）で作成するヘッダのフォーマットを図１４に、擬似ヘッダフォーマットを図１５に示す。

また、ＴＣＰヘッダ生成部（１１６）はヘッダ／ペイロード合成部（１２０）からの出力要求（１２６）を受信すると、生成したＴＣＰヘッダをヘッダ／ペイロード合成部（１２０）に出力（１３０）する。

［ＵＤＰヘッダ生成部］
ＵＤＰヘッダ生成部（１１７）ではプロトコル制御部（１１５）からのヘッダ生成指示及びヘッダ生成情報に基づきヘッダ生成を開始し、ヘッダ生成完了後にヘッダ／ペイロード合成部（１２０）にＵＤＰヘッダ生成完了通知（１２７）を行う。ＵＤＰヘッダ生成指示をプロトコル制御部（１１５）から受信したら、プロトコル制御部（１１５）からＵＤＰヘッダ情報を取得する。ＵＤＰヘッダ情報は、送信元ポート番号、宛先ポート番号、ＵＤＰデータ長である。取得したヘッダ生成情報から擬似ヘッダとチェックサム以外のＵＤＰヘッダを作成する。次にペイロードサムをペイロード分割部（１０３）より受信したかの判断を行い、もし受信していれば擬似ヘッダとチェックサム以外のＵＤＰヘッダとペイロードサムの合計からＵＤＰチェックサムを算出し、チェックサムをＵＤＰヘッダのチェックサムフィールドに設定し、ＵＤＰヘッダの生成を完了する。ＵＤＰヘッダの生成が完了すると、ヘッダ／ペイロード合成部（１２０）にＵＤＰヘッダ生成完了通知を行い、ＵＤＰヘッダ生成を終了する。

ただし、ＵＤＰヘッダのチェックサムはオプションでの対応となっているため、ＵＤＰチェックサムを行わない設定にした場合は、プロトコル制御部（１１５）よりＵＤＰヘッダ情報（送信元ポート番号、宛先ポート番号、ＵＤＰデータ長）を取得した時点で、ＵＤＰチェックサムフィールドに０を設定し、ＵＤＰヘッダ生成完了通知をヘッダ／ペイロード合成部（１２０）に出力する。

ＵＤＰヘッダ生成部（１１７）で作成するヘッダのフォーマットを図１６に、擬似ヘッダフォーマットを図１７に示す。

また、ＵＤＰヘッダ生成部（１１７）はヘッダ／ペイロード合成部（１２０）からの出力要求（１２７）を受信すると、生成したＵＤＰヘッダをヘッダ／ペイロード合成部（１２０）に出力（１３１）する。

［ＩＰヘッダ生成部］
ＩＰヘッダ生成部（１１８）ではプロトコル制御部（１１５）からのヘッダ生成指示及びヘッダ生成情報に基づきヘッダ生成を開始し、ヘッダ生成完了後にヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了通知（１２８）を行う。ＩＰヘッダ生成指示をプロトコル制御部（１１５）から受信したら、プロトコル制御部（１１５）からＩＰヘッダ情報を取得する。ＩＰヘッダ情報はバージョン、ヘッダ長、ＴＯＳ、全長、識別子、フラグ、フラグメントオフセット、ＴＴＬ、プロトコル、送信元ＩＰアドレス、宛先ＩＰアドレスである。これらの情報からＩＰヘッダのヘッダチェックサムを算出してＩＰヘッダを完成させ、ヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了通知を行う。ＩＰヘッダ生成部（１１８）で作成するヘッダのフォーマットを図２０に示す。

また、ＩＰヘッダ生成部（１１８）はヘッダ／ペイロード合成部（１２０）からの出力要求（１２８）を受信すると、生成した順番にＩＰヘッダをヘッダ／ペイロード合成部（１２０）に出力（１３２）する。

［ＭＡＣヘッダ生成部］
ＭＡＣヘッダ生成部（１１９）ではプロトコル制御部（１１５）からのヘッダ生成指示及びヘッダ生成情報に基づきヘッダ生成を開始し、ヘッダ生成完了後にヘッダ／ペイロード合成部（１２０）にＭＡＣヘッダ生成完了通知（１２９）を行う。ＭＡＣヘッダ生成部（１１９）はプロトコル制御部（１１５）からＭＡＣヘッダ生成指示を受信したら、ＭＡＣヘッダ情報を取得する。ＭＡＣヘッダ生成情報は、ヘッダ生成数、送信元ＭＡＣアドレス、宛先ＭＡＣアドレス、タイプレングスである。これらの情報からＭＡＣヘッダを完成させ、ヘッダ／ペイロード合成部（１２０）にＭＡＣヘッダ生成完了通知を行う。ＭＡＣヘッダ生成部（１１９）で作成するＭＡＣヘッダのフォーマットを図２１に示す。

また、ＭＡＣヘッダ生成部（１１９）はヘッダ／ペイロード合成部（１２０）からの出力要求（１２９）を受信すると、生成したＭＡＣヘッダをヘッダ／ペイロード合成部（１２０）に出力（１３３）する。

［ヘッダ／ペイロード合成部］
ヘッダ／ペイロード合成部（１２０）はフレーム個数フレーム長算出部（１０２）からのフレーム個数から生成すべきヘッダの個数を割り出す。次に、各プロトコルヘッダ生成部からのヘッダ完了通知により、送信フレームに必要なヘッダが完了していることを認識し、ＴＣＰ／ＩＰの場合はＭＡＣヘッダ生成部（１１９）、ＩＰヘッダ生成部（１１８）、ＴＣＰヘッダ生成部（１１６）、ペイロード読み出し部（１０５）の順に出力要求を行い、ヘッダ及びペイロードを読み出してフレームとして合成し、フレーム送出部（１２１）に出力する。ＵＤＰ／ＩＰの場合は先頭フレームはＭＡＣヘッダ生成部（１１９）、ＩＰヘッダ生成部（１１８）、ＵＤＰヘッダ生成部（１１７）、ペイロード読み出し部（１０５）の順に出力要求を行い、中間、最終フレームはＭＡＣヘッダ生成部（１１９）、ＩＰヘッダ生成部（１１８）、ペイロード読み出し部（１０５）の順に出力要求を行い、ヘッダ及びペイロードを読み出してフレームとして合成しフレーム送出部（１２１）に出力する。ペイロードを持たないフレームを送信する場合はヘッダのみ読み出して、フレームとして合成し、フレーム送出部（１２１）に出力する。ヘッダ／ペイロード合成部（１２０）は、ヘッダをフレーム送出部（１２１）に出力した時点で、プロトコル制御部（１１５）にヘッダ送信完了（１３７）を出力する。

［フレーム送出部］
フレーム送出部（１２１）では、ヘッダ／ペイロード合成部（１２０）から出力されるフレームを通信制御装置外に送信する機能を有する。ＩＥＥＥ８０２．３に準拠し、プリアンブルの付加、フレームパディング、ＣＲＣの生成等を行う。

＜ＴＣＰセグメントの送信例＞
ＴＣＰ／ＩＰのフレーム送信時に送信データグラムが３つのセグメントに分割された場合の例を図１３に示す。アプリケーションデバイス（１０１）からの送信指示及び送信データ長（１３０１）を受けてフレーム個数フレーム長算出部（１０２）は、フレーム個数（３個）、先頭フレームのペイロード長（ＰＬ０の長さ）、中間フレームのペイロード長（ＰＬ１の長さ）、最終フレームのペイロード長（ＰＬ２の長さ）をプロトコル制御部（１１５）及びヘッダ／ペイロード合成部（１２０）に出力（１３０２）する。プロトコル制御部（１１５）ではプロトコルタイプをＴＣＰであると判断し、ＴＣＰ、ＩＰ、ＭＡＣのヘッダ情報の収集を行う。またペイロード分割部（１０３）においてペイロードをＴｘメモリ（１０４）に書き込んでいき、１フレーム分（１ＴＣＰセグメント分）書き込みが完了すると、プロトコル制御部（１１５）に対してフレームペイロード送信準備完了（１３０３）を出力する。プロトコル制御部（１１５）はフレームペイロード送信準備完了（１３０３）を受信するとデータグラムをセグメント化した先頭フレームのＴＣＰ、ＩＰ、ＭＡＣのヘッダを生成するためのヘッダ情報収集が終了しているかを判断し、終了していればＴＣＰヘッダ生成部（１１６）にヘッダ生成指示及びヘッダ情報（１３０４）を、ＩＰヘッダ生成部（１１８）にヘッダ生成指示及びヘッダ情報（１３０５）を、ＭＡＣヘッダ生成部（１１９）にヘッダ生成指示及びヘッダ情報（１３０６）を同時に出力する。ヘッダ生成指示を受信したＴＣＰヘッダ生成部（１１６）はプロトコル制御部（１１５）からのヘッダ情報とペイロード分割部（１０３）からのペイロードサム（１３０７）よりＴＣＰヘッダを生成し、ヘッダ／ペイロード合成部（１２０）にＴＣＰヘッダ生成完了（１３０８）を出力する。ヘッダ生成指示を受信したＩＰヘッダ生成部（１１８）はプロトコル制御部（１１５）からのヘッダ情報からＩＰヘッダを生成し、ヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了（１３０９）を出力する。ヘッダ生成指示を受信したＭＡＣヘッダ生成部（１１９）はプロトコル制御部（１１５）からのヘッダ情報からＭＡＣヘッダを生成し、ヘッダ／ペイロード合成部（１２０）にＭＡＣヘッダ生成完了（１３１０）をフレーム個数分出力する。ヘッダ／ペイロード合成部（１２０）はフレーム個数フレーム長算出部（１０２）から受信したフレーム個数（１３０２）から３つにセグメント化されたフレームの先頭フレームにはＴＣＰヘッダ、ＩＰヘッダ、ＭＡＣヘッダが必要であることを認識しており、ＴＣＰヘッダ生成完了（１３０８）、ＩＰヘッダ生成完了（１３０９）、ＭＡＣヘッダ生成完了（１３１０）の全てを受信するとフレームを送信可能な状態であると判断する。ヘッダ／ペイロード合成部（１２０）はＭＡＣヘッダ、ＩＰヘッダ、ＴＣＰヘッダ、ペイロードと読み出していきフレーム送出部（１２１）に先頭フレームを出力する。また、ＭＡＣ、ＩＰ、ＴＣＰヘッダをフレーム送出部（１２１）に出力した時点でプロトコル制御部（１１５）にヘッダ送信完了（１３１１）を出力する。

プロトコル制御部（１１５）はヘッダ送信完了（１３１１）を受信すると次のフレーム、つまりここでは３つにセグメント化されたフレームの中間フレームのヘッダ情報収集を行う。中間フレームに必要なヘッダは先頭と同様にＴＣＰ、ＩＰ、ＭＡＣヘッダの情報収集を行う。ペイロード分割部（１０３）からの次のフレームペイロード送信準備完了（１３１２）を受信すると、中間フレームのＴＣＰ、ＩＰ、ＭＡＣのヘッダを生成するためのヘッダ情報収集が終了しているかを判断し、終了していればＴＣＰヘッダ生成部（１１６）にヘッダ生成指示及びヘッダ情報（１３１３）を、ＩＰヘッダ生成部（１１８）にヘッダ生成指示及びヘッダ情報（１３１４）を同時に出力する。ヘッダ生成指示を受信したＴＣＰヘッダ生成部（１１６）はプロトコル制御部（１１５）からのヘッダ情報とペイロード分割部（１０３）からのペイロードサム（１３１５）よりＴＣＰヘッダを生成し、ヘッダ／ペイロード合成部（１２０）にＴＣＰヘッダ生成完了（１３１６）を出力する。ヘッダ生成指示を受信したＩＰヘッダ生成部（１１８）はプロトコル制御部（１１５）からのヘッダ情報からＩＰヘッダを生成し、ヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了（１３１７）を出力する。

ヘッダ／ペイロード合成部（１２０）はフレーム個数フレーム長算出部（１０２）から受信したフレーム個数（１３０２）から３つにセグメント化されたフレームの中間フレームにはＴＣＰヘッダ、ＩＰヘッダ、ＭＡＣヘッダが必要であることを認識しており、ＴＣＰヘッダ生成完了（１３１６）、ＩＰヘッダ生成完了（１３１７）を受信するとフレームを送信可能な状態であると判断する。ＭＡＣヘッダ生成完了については先頭フレームの時にフレーム個数分出力されているため、ヘッダ／ペイロード合成部（１２０）はこの時点で中間フレームのＭＡＣヘッダ生成が完了していると判断している。フレームが送信可能な状態であると判断したヘッダ／ペイロード合成部（１２０）はＭＡＣヘッダ、ＩＰヘッダ、ＴＣＰヘッダ、ペイロードと読み出していきフレーム送出部（１２１）に中間フレームを出力する。また、ＭＡＣ、ＩＰ、ＴＣＰヘッダをフレーム送出部（１２１）に出力した時点でプロトコル制御部（１１５）にヘッダ送信完了（１３２０）を出力する。

プロトコル制御部（１１５）はヘッダ送信完了（１３２０）を受信すると次のフレーム、つまりここでは３つにセグメント化されたフレームの最終フレームのヘッダ情報収集を行う。最終フレームに必要なヘッダは先頭、中間と同様にＴＣＰ、ＩＰ、ＭＡＣヘッダの情報収集を行う。ペイロード分割部（１０３）からの次のフレームペイロード送信準備完了（１３１８）をすでに受信しているので、ＴＣＰ、ＩＰ、ＭＡＣのヘッダを生成するためのヘッダ情報収集が終了し次第、ＴＣＰヘッダ生成部（１１６）にヘッダ生成指示及びヘッダ情報（１３２１）を、ＩＰヘッダ生成部（１１８）にヘッダ生成指示及びヘッダ情報（１３２２）を同時に出力する。ヘッダ生成指示を受信したＴＣＰヘッダ生成部（１１６）はプロトコル制御部（１１５）からのヘッダ情報とペイロード分割部（１０３）からのペイロードサム（１３１９）よりＴＣＰヘッダを生成し、ヘッダ／ペイロード合成部（１２０）にＴＣＰヘッダ生成完了（１３２３）を出力する。ヘッダ生成指示を受信したＩＰヘッダ生成部（１１８）はプロトコル制御部（１１５）からのヘッダ情報からＩＰヘッダを生成し、ヘッダ／ペイロード合成部（１２０）にＩＰヘッダ生成完了（１３２４）を出力する。

ヘッダ／ペイロード合成部（１２０）はフレーム個数フレーム長算出部（１０２）から受信したフレーム個数（１３０２）から３つにセグメント化されたフレームの最終フレームにはＴＣＰヘッダ、ＩＰヘッダ、ＭＡＣヘッダが必要であることを認識しており、ＴＣＰヘッダ生成完了（１３２３）、ＩＰヘッダ生成完了（１３２４）を受信するとフレームを送信可能な状態であると判断する。ＭＡＣヘッダ生成完了については先頭フレームの時にフレーム個数分出力されているため、ヘッダ／ペイロード合成部（１２０）はこの時点で中間フレームのＭＡＣヘッダ生成が完了していると判断している。フレームが送信可能な状態であると判断したヘッダ／ペイロード合成部（１２０）はＭＡＣヘッダ、ＩＰヘッダ、ＴＣＰヘッダ、ペイロードと読み出していきフレーム送出部（１２１）に最終フレームを出力する。また、ＭＡＣ、ＩＰ、ＴＣＰヘッダをフレーム送出部に出力した時点でプロトコル制御部（１１５）にヘッダ送信完了（１３２５）を出力する。

以上のように、第１及び第２の実施形態は、ネットワークに接続し、低価格のＣＰＵもしくはＣＰＵレスで、比較的高速なデータを送受信する機器における、ネットワークインタフェースの通信制御装置であって、アプリケーションデバイスから任意の長さの送信データを受信し、サポートするデータリンク層に適切なフレームサイズでフレーム出力する。

フレーム個数フレーム長算出部は、データ送信要求に基づき送信データを送信するためのフレーム個数及びフレーム長を算出する。ペイロード分割部は、フレーム個数フレーム長算出部により算出されたフレーム個数及びフレーム長を基に送信データをフレーム単位に分割する。ヘッダ生成部は、フレーム個数フレーム長算出部により算出されたフレーム個数及びフレーム長を基にフレーム単位の送信データに付加すべきヘッダを生成する。その際、ヘッダ生成部は、ペイロード分割部が送信データを入力している間に送信データに付加すべきヘッダを生成することができる。

ペイロード分割部は、フレーム単位の送信データを加算してフレーム毎のチェックサムを算出する。ヘッダ生成部は、ヘッダ内にチェックサムを付加する。これにより、送信データを受信してから短期間でヘッダつきフレームを出力することができる。

ペイロード分割部は、複数フレームの送信データを入力している間でも１フレーム分の送信データを入力して分割する毎にフレーム単位の分割完了通知を出力する。ヘッダ生成部は、フレーム単位の分割完了通知を基にフレーム単位のヘッダを生成する。また、ヘッダ生成部は、ペイロード分割部が複数フレームの送信データを入力している間でも各フレームのヘッダを生成する毎にフレーム単位のヘッダ生成完了通知を出力する。ヘッダ／ペイロード合成部は、フレーム単位のヘッダ生成完了通知を基にフレーム単位の送信データ及びヘッダを合成する。これにより、アプリケーションデバイスから複数フレームに相当する長い送信データを受信している間でも、その送信データを構成する各フレームの送信を開始することができる。

以上のように、第１及び第２の実施形態をまとめると、以下のようになる。
（１）アプリケーションデバイスからの送信指示を基に、送信データをフレームとしてどう分割すべきかを初めに算出する。即ち１つの送信指示に伴う送信データを幾つのフレームとして出力すべきか、先頭フレームのペイロード長、中間フレームのペイロード長、最終フレームのペイロード長を算出する。

（２）（１）の結果を基に、送信データをフレームとして送出する為のヘッダ生成と、フレームペイロード生成（分割）の処理を同時に開始する。

（３）フレーム個数とペイロード長が判明しているので各々のプロトコルスタック（ＴＣＰ／ＵＤＰ／ＩＰ／ＭＡＣ）のヘッダ生成を同時に開始する。

（４）ペイロード長が判明しているのでアプリケーションデバイスから送信データを受け取りメモリに一時退避するときにペイロード単位で分割しながらペイロード単位で保存する。

（５）フレーム単位でのヘッダ生成、ペイロード保存が成されるので、フレーム単位でヘッダとペイロードを合成してフレーム出力を行う。このフレーム出力はアプリケーションデバイスからの送信データを全て受けてからの場合もあるが、アプリケーションデバイスからの送信でデータのうちはじめの１フレームを受信したらすぐにはじめの１フレームを出力する場合もある。

本実施形態によれば、ハードウェアが持つ並列処理能力を発揮でき、メモリ管理方法も単純化される。スループットの大きい（帯域の広い）通信制御装置（ＴＯＥ又はプロトコル制御装置）を実現できる。アプリケーションからの送信データが本通信制御装置（ＴＯＥ又はプロトコル制御装置）に入力完了すると殆ど直ぐにインタフェースにフレームとして送信可能となる。即ち、アプリケーションデバイスからの送信データがフレームとしてネットワークインタフェースに出力されるまでの遅延時間が殆どない。

なお、上記実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。

本発明の第１の実施形態による通信制御装置の構成図である。 シーケンス１を示す図である。 シーケンス２を示す図である。 シーケンス３を示す図である。 ＴＸメモリを示す図である。 シーケンス４を示す図である。 シーケンス５を示す図である。 ＴＣＰヘッダ生成部の処理を示すフローチャートである。 ＵＤＰヘッダ生成部の処理を示すフローチャートである。 ＩＰヘッダ生成部の処理を示すフローチャートである。 本発明の第２の実施形態による通信制御装置の構成図である。 プロトコル制御部の処理を示すフローチャートである。 シーケンス６を示すフローチャートである。 ＴＣＰヘッダフォーマットを示す図である。 ＴＣＰ擬似ヘッダフォーマットを示す図である。 ＵＤＰヘッダフォーマットを示す図である。 ＵＤＰ擬似ヘッダフォーマットを示す図である。 ＩＰヘッダフォーマット（フラグメント）を示す図である。 ＩＰヘッダフォーマット（セグメント）を示す図である。 ＩＰヘッダフォーマットを示す図である。 ＭＡＣヘッダフォーマットを示す図である。 ペイロード長とヘッダ数算出の流れを示すフローチャートである。

符号の説明

１０１ アプリケーションデバイス
１０２ フレーム個数フレーム長算出部
１０３ ペイロード分割部
１０４ ＴＸメモリ
１０５ ペイロード読み出し部
１１５ プロトコル制御部
１１６ ＴＣＰヘッダ生成部
１１７ ＵＤＰヘッダ生成部
１１８ ＩＰヘッダ生成部
１１９ ＭＡＣヘッダ生成部
１２０ ヘッダ／ペイロード合成部
１２１ フレーム送出部

Claims (11)

1. 送信データを送信するためのフレーム個数及びフレーム長を算出する算出手段と、
   前記算出手段による算出の結果を基に送信データをフレーム単位に分割するペイロード分割手段と、
   前記ペイロード分割手段による送信データの分割と並列して、前記算出手段による算出の結果を基に前記フレーム単位の送信データに付加すべきヘッダを生成するヘッダ生成手段と、を有し、
   前記ヘッダ生成手段は、複数レイヤのプロトコルのヘッダを並列して生成することを特徴とする通信制御装置。
2. 前記算出手段は、データの送信要求に基づき前記フレーム個数及び前記フレーム長を算出し、
   前記ヘッダ生成手段は、前記ペイロード分割手段が送信データを入力している間に送信データに付加すべきヘッダを生成することを特徴とする請求項１記載の通信制御装置。
3. 前記ペイロード分割手段は、フレーム単位の送信データを加算してフレーム毎のチェックサムを算出し、
   前記ヘッダ生成手段は、前記ヘッダ内に前記チェックサムを付加することを特徴とする請求項１又は２記載の通信制御装置。
4. 前記ペイロード分割手段は、複数フレームの送信データを入力している間でも１フレーム分の送信データを入力して分割する毎にフレーム単位の分割完了通知を出力し、
   前記ヘッダ生成手段は、前記フレーム単位の分割完了通知を基に前記フレーム単位のヘッダを生成することを特徴とする請求項１〜３のいずれか１項に記載の通信制御装置。
5. 前記ヘッダ生成手段は、前記ペイロード分割手段が複数フレームの送信データを入力している間でも各フレームのヘッダを生成する毎にフレーム単位のヘッダ生成完了通知を出力し、
   さらに、前記フレーム単位のヘッダ生成完了通知を基に前記フレーム単位の送信データ及びヘッダを合成するヘッダ／ペイロード合成手段を有することを特徴とする請求項１〜４のいずれか１項に記載の通信制御装置。
6. さらに、フレームの生成に必要なヘッダ生成情報を収集し、ヘッダ生成指示及びヘッダ生成情報をフレーム毎に出力するプロトコル制御手段を有し、
   前記ヘッダ生成手段は、前記プロトコル制御手段から前記ヘッダ生成指示及び前記ヘッダ生成情報を入力すると、ヘッダを生成し、ヘッダ生成完了通知を出力することを特徴とする請求項５記載の通信制御装置。
7. さらに、前記ヘッダ／ペイロード合成手段により合成されたフレームを送信するフレーム送信手段を有することを特徴とする請求項５又は６記載の通信制御装置。
8. さらに、前記ペイロード分割手段により分割されたフレーム単位の送信データを格納するためのメモリを有することを特徴とする請求項７記載の通信制御装置。
9. さらに、前記メモリからフレーム単位の送信データを読み出して前記ヘッダ／ペイロード合成手段に出力するペイロード読み出し手段を有することを特徴とする請求項８記載の通信制御装置。
10. 前記ヘッダ生成手段は、
    ＴＣＰヘッダを生成するＴＣＰヘッダ生成手段と、
    ＵＤＰヘッダを生成するＵＤＰヘッダ生成手段と、
    ＩＰヘッダを生成するＩＰヘッダ生成手段と、
    ＭＡＣヘッダを生成するＭＡＣヘッダ生成手段とを有し、
    前記プロトコル制御手段は、前記ＴＣＰヘッダ生成手段、前記ＵＤＰヘッダ生成手段、前記ＩＰヘッダ生成手段及び前記ＭＡＣヘッダ生成手段にヘッダの生成指示を出力することができることを特徴とする請求項６〜９のいずれか１項に記載の通信制御装置。
11. 通信制御装置が行う通信制御方法であって、
    送信データを送信するためのフレーム個数及びフレーム長を算出する算出ステップと、
    前記算出ステップにおける算出の結果に基づいて、送信データをフレーム単位に分割する分割ステップと、
    前記分割ステップにおける送信データの分割と並列して開始されるステップであり、前記算出ステップにおける算出の結果に基づいて、前記フレーム単位の送信データに付加すべきヘッダを生成するヘッダ生成ステップと、を有し、
    前記ヘッダ生成ステップでは、複数レイヤのプロトコルのヘッダを並列的に生成することを特徴とする通信制御方法。

Images