"ネットワークを介してデータ伝送を行うネットワーク端末装置であって、無線接続される隣接する通信ノードとの間のデータ伝送処理を行うデータリンク層処理部と、前記データリンク層処理部を介して端末ノード間のデータ伝送処理を行うトランスポート層処理部と、前記データリンク層処理部のデータ伝送の状況を表わす第2層情報と、前記トランスポート層処理部のデータ伝送の状況を表わす第4層情報と、に基づいて前記ネットワーク上における伝送データの輻輳箇所を判別する輻輳箇所判別部と、判別された前記輻輳箇所に基づいて前記トランスポート層処理部の伝送レートを調整する伝送レート制御部と、を具備するネットワーク端末装置。少なくとも前記データリンク層処理部の再送制御に伴う伝送効率の低下を含めた前記データリンク層処理部の伝送レートを表わす実効レートを算出する実効レート算出部をさらに具備し、前記伝送レート制御部は、判別された前記輻輳箇所と算出された前記実効レートとに基づいて、前記トランスポート層処理部の伝送レートを調整する請求項1記載のネットワーク端末装置。前記実効レート算出部は、前記トランスポート層処理部でひとまとめに処理される伝送データのサイズであるウインドウサイズに合わせてデータ再送の発生割合の算出期間長を変化させ、算出された前記データ再送の発生割合に基づいて前記実効レートを算出する請求項2記載のネットワーク端末装置。前記伝送レート制御部は、通信相手の端末ノードへ前記伝送レートを決定させるフィードバック情報を送ることで前記トランスポート層処理部の伝送レートを調整する請求項1記載のネットワーク端末装置。前記フィードバック情報には、前記データリンク層処理部における伝送データの損失情報が含まれる請求項4記載のネットワーク端末装置。前記第2層情報は、前記データリンク層処理部におけるデータ再送の発生割合情報、前記データリンク層処理部における伝送データの損失情報、または、無線ノイズの強度情報を含む請求項1記載のネットワーク端末装置。前記データリンク層処理部は、隣接する通信ノードの通信バッファの使用状況情報を取得する情報取得手段を有し、前記第2層情報は、前記通信バッファの使用状況情報を含む請求項1記載のネットワーク端末装置。前記第4層情報は、伝送データの伝送遅延時間の変化情報を含む請求項1記載のネットワーク端末装置。前記輻輳箇所判別部は、前記第4層情報に含まれる伝送データの伝送遅延時間の変化情報と、前記第2層情報に含まれる隣接する通信ノードの通信バッファの使用状況情報とに基づいて、前記輻輳箇所を判別する請求項1記載のネットワーク端末装置。前記輻輳箇所判別部は、前記伝送データの輻輳箇所が、前記隣接する通信ノードとの間にあるか、前記隣接する通信ノードと通信相手の端末ノードとの間にあるかを判別する請求項1記載のネットワーク端末装置。前記伝送レート制御部は、前記トランスポート層処理部の伝送レートを回復させる際、前記第2層情報および/または前記第4層情報の履歴に基づいて、前記伝送レートの回復速度を補償する請求項1記載のネットワーク端末装置。前記第2層情報と前記実効レートとを対応づけるマッピング情報を管理するマッピング情報管理部を備え、前記実効レート算出部は、前記マッピング情報に基づいて前記実効レートを算出可能である請求項2記載のネットワーク端末装置。前記データリンク層処理部は、複数の動作モードを備え、前記実効レート算出部は、前記データリンク層処理部の動作モードに応じて前記実効レートを算出するためのパラメータおよび算出式を切り替える請求項2記載のネットワーク端末装置。ネットワークを介してデータ伝送を行うデータ伝送方法であって、無線を介して接続される隣接する通信ノードとの間のデータ伝送処理を行うデータリンク層処理ステップと、前記データリンク層処理ステップを介して端末ノード間のデータ伝送処理を行うトランスポート層処理ステップと、前記データリンク層処理ステップでのデータ伝送の状況を表わす第2層情報と、前記トランスポート層処理ステップでのデータ伝送の状況を表わす第4層情報と、に基づいて前記ネットワーク上における伝送データの輻輳箇所を判別する輻輳箇所判別ステップと、判別された前記輻輳箇所に基づいて前記トランスポート層処理ステップでの伝送レートを調整する伝送レート制御ステップと、を含むデータ伝送方法。少なくとも前記データリンク層処理ステップでの再送制御に伴う伝送効率の低下を含めた前記データリンク層処理ステップでの伝送レートを表わす実効レートを算出する実効レート算出ステップ、をさらに含み、前記伝送レート制御ステップは、判別された前記輻輳箇所と算出された前記実効レートとに基づいて、前記トランスポート層処理ステップでの伝送レートを調整する請求項14記載のデータ伝送方法。しかしながら、上記従来のレート制御では、次のような課題が生じる。すなわち、通常のレート制御例えば非特許文献1~4のレート制御では、伝送パケットの損失または遅延が有線区間の輻輳によるものか無線区間の障害によるものか区別できない。つまり、無線区間の一時的な障害に対しても、有線区間の輻輳に対ししても、通常のレート制御では、同じレート制御のアルゴリズムが使用される。そのため、上記従来のレート制御では、パケットロス等が検知された場合に、伝送レートが不必要に低くされてしまうことがある。この場合には、ネットワークのスループットが不必要に低下して、エンドツーエンドの通信品質が低下する。また、通常のレート制御では、ネットワークの輻輳の悪化を防ぐために、輻輳が回復されてきた場合に、伝送レートは緩やかに上げられる。そのため、通常のレート制御では、無線区間の一時的な障害例えば電子レンジの使用による無線ノイズの発生により伝送パケットが一時的に損失した場合でも、この障害が取り除かれた後の伝送レートの回復が無駄に遅くなる。さらに、通常のレート制御では、無線区間で小規模な障害が多発する場合に、上記のような伝送レートの調整が繰り返される。その結果、エンドツーエンドの伝送レートは、実際にデータ伝送可能なレートよりもずっと低い伝送レートで滞ってしまうという課題が生じる。この場合、無線リソースは十分に利用されず、エンドツーエンドのネットワーク帯域は、本来利用できる帯域よりもずっと狭いままとなる。また、無線区間の障害を検知する非特許文献5,6の技術では、次のような課題がある。すなわち、非特許文献5の技術では、ROTTの変化情報などのトランスポート層の情報のみで、伝送エラーの発生箇所が有線区間か無線区間かを判別している。そのため、この技術では、伝送エラーの発生箇所を正確に判別できないという課題がある。例えば、ROTTは、無線区間のリアルタイムの伝送状況を正確に反映するほど詳細な情報でない。つまり、無線区間の伝送状況の変化に対して、ROTTは、追従性よく変動しない。それゆえ、ROTTの変化情報だけでは、無線区間の一時的な障害または短時間の変動を正確に判別できない。また、非特許文献6の技術では、アクセスポイントから送信端末へフィードバック情報を送信する構成が必要となる。具体的には、非特許文献6の技術では、アクセスポイントおよび送信側端末のプロトコルに、ネットワーク階層をまたぐクロスレイヤとも呼ぶシグナリングプロトコル帯域予約のための信号交換プロトコルを、追加する必要が生じる。つまり、非特許文献6の技術では、送信側端末と受信側端末の改変だけではなく、アクセスポイントの改変が必要となる。したがって、この非特許文献6の技術では、例えば、公衆無線LANローカルエリアネットワークを利用したシステムなど、アクセスポイントがネットワークインフラの一部となっているシステムに対して適用困難であるという課題がある。この発明の目的は、中継ノードの改変を必要とせずに、伝送データの輻輳箇所に合わせた適切な伝送レートの調整を行うようにすることである。本発明の一態様に係るネットワーク端末装置は、ネットワークを介してデータ伝送を行うネットワーク端末装置であって、無線接続される隣接する通信ノードとの間のデータ伝送処理を行うデータリンク層処理部と、前記データリンク層処理部を介して端末ノード間のデータ伝送処理を行うトランスポート層処理部と、前記データリンク層処理部のデータ伝送の状況を表わす第2層情報と、前記トランスポート層処理部のデータ伝送の状況を表わす第4層情報と、に基づいて前記ネットワーク上における伝送データの輻輳箇所を判別する輻輳箇所判別部と、判別された前記輻輳箇所に基づいて前記トランスポート層処理部の伝送レートを調整する伝送レート制御部と、を具備する構成を採る。本発明の一態様に係るデータ伝送方法は、ネットワークを介してデータ伝送を行うデータ伝送方法であって、無線を介して接続される隣接する通信ノードとの間のデータ伝送処理を行うデータリンク層処理ステップと、前記データリンク層処理ステップを介して端末ノード間のデータ伝送処理を行うトランスポート層処理ステップと、前記データリンク層処理ステップでのデータ伝送の状況を表わす第2層情報と、前記トランスポート層処理ステップでのデータ伝送の状況を表わす第4層情報と、に基づいて前記ネットワーク上における伝送データの輻輳箇所を判別する輻輳箇所判別ステップと、判別された前記輻輳箇所に基づいて前記トランスポート層処理ステップでの伝送レートを調整する伝送レート制御ステップと、を含む構成を採る。本発明によれば、中継ノードの改変を必要とせずに、伝送データの輻輳箇所に合わせた適切な伝送レートの調整を行うことができる。以下、本発明の各実施の形態について図面を参照して詳細に説明する。実施の形態1図1は、本発明の実施の形態1のネットワーク端末装置が加わるネットワーク構成の一例を示す図である。実施の形態1のネットワーク構成には、図1に示すように、送信側端末101と、エッジネットワーク111,113と、コアネットワーク102と、アクセスポイント105と、受信側端末103とが含まれる。送信側端末101は、ネットワークを介してデータを送信する情報端末である。エッジネットワーク111は、送信側端末101が接続される有線区間のネットワークである。コアネットワーク102は、インターネットなどを含み、送信側端末101と受信側端末103との間に位置する主に有線のネットワークである。エッジネットワーク113は、アクセスポイント105と受信側端末103を接続する無線区間のネットワークである。アクセスポイント105は、エッジネットワーク無線区間113とコアネットワーク102の間に位置し、無線有線のネットワークブリッジとして機能する。受信側端末103は、ネットワークを介して送信側端末101からデータを受信する情報端末である。実施の形態1のネットワーク上で伝送されるデータには、データパケット121と、フィードバックパケット123とが含まれる。データパケット121は、例えばAVストリーミングデータなどであり、送信側端末101から受信側端末103へ向けて送信される。フィードバックパケット123は、データパケット121の伝送に対する応答および伝送制御用のデータを含み、受信側端末103から送信側端末101へ送信される。なお、図1では、ネットワークの詳細な構成要素が省略されているが、これらの構成要素が存在し得ることは当業者にとって明らかである。しかし、これらの構成要素は、本発明の概念に影響するものでない。図2は、本発明に係るネットワーク端末装置の一実施の形態である受信側端末103の要部構成図である。受信側端末103は、受信側データリンク層処理部211と、受信側トランスポート層処理部213と、輻輳箇所判別部235aと、伝送レート制御部235bと、実効レート算出部233aとを備える。受信側データリンク層処理部211は、受信側端末103におけるネットワーク処理のうち、データリンク層の処理を行う。受信側トランスポート層処理部213は、受信側端末103のネットワーク処理のうち、トランスポート層の受信処理を行う。実効レート算出部233aは、受信側データリンク層処理部211の実効ビットレートを算出する。ここで、算出される実効ビットレートは、受信側データリンク層処理部211の再送制御に伴う伝送効率の低下を考慮した実効的な伝送レートである。算出された実効ビットレートの情報は、伝送レート制御部235bへ送られる。輻輳箇所判別部235aは、受信側データリンク層処理部211の伝送状況を表わすデータリンク層情報と、受信側トランスポート層処理部213の伝送状況を表わすトランスポート層情報とに基づいて、ネットワークの輻輳箇所を判別する。データリンク層情報は、本発明に係る第2層情報の一実施形態であり、トランスポート層情報は、本発明に係る第4層情報の一実施形態である。判別結果の情報は、伝送レート制御部235bへ送られる。伝送レート制御部235bは、輻輳箇所の判別結果の情報と、実効ビットレートの情報とを受けて、これらの情報に基づき、トランスポート層の伝送レートを調整する制御を行う。なお、続いて示される図3の具体的な構成例において、実効レート算出部233aは、受信側データリンクレート制御部233に含まれている。しかし、実効レート算出部233aは、受信側データリンクレート制御部233と別に設けられても良い。また、図3の具体的な構成例において、輻輳箇所判別部235aと伝送レート制御部235bとは、図3の受信側トランスポートレート制御部235に含まれている。しかし、輻輳箇所判別部235aと伝送レート制御部235bとは、受信側トランスポートレート制御部235と別に設けられても良い。続く説明では、ネットワークの各ノードが、非特許文献7に示されるTCPTransmissionControlProtocolを使用して、データ伝送を行う例を示している。しかし、データ伝送のためのプロトコルは、送信データのレート制御と受信側から送信側へのフィードバックが可能であれば、その他のプロトコルを適用可能である。このことは当業者にとって明らかであり、本発明の概念に影響するものでない。その他のプロトコルとしては、例えば、非特許文献8に示されるDCCPDatagramCongestionControlProtocolが適用できる。または、その他のプロトコルとしては、非特許文献9に示されるSCTPStreamControlTransmissionProtocolが適用できる。図3は、図1の各装置の論理的構成を示すブロック図である。送信側端末101は、図3に示すように、送信側アプリケーション240と、送信側トランスポート層処理部201と、送信側トランスポートレート制御部231と、送信側データリンク層処理部203と、を備える。送信側アプリケーション240は、データの送信要求と指示とを行う。送信側トランスポート層処理部201は、送信側端末101におけるネットワーク処理のうち、トランスポート層の伝送処理を行う。送信側トランスポートレート制御部231は、送信側端末101における送信側トランスポート層処理部201において、送信側のトランスポート層のレート制御と必要な情報取得処理とを行う。送信側データリンク層処理部203は、送信側端末101におけるネットワーク処理のうち、データリンク層の伝送処理を行う。受信側端末103は、図3に示すように、受信側アプリケーション241と、受信側トランスポート層処理部213と、受信側トランスポートレート制御部235と、受信側データリンク層処理部211と、受信側データリンクレート制御部233と、を備える。受信側アプリケーション241は、データの受信要求と指示とを行う。受信側トランスポート層処理部213は、図2にも示したが、受信側端末103のネットワーク処理のうち、トランスポート層の受信処理を行う。受信側トランスポートレート制御部235は、受信側端末103における受信側トランスポート層処理部213において、受信側のトランスポート層のレート制御と必要な情報取得処理とを行う。受信側データリンク層処理部211は、図2にも示したが、受信側端末103におけるネットワーク処理のうち、データリンク層の処理を行う。受信側データリンクレート制御部233は、受信側端末103の受信側データリンク層処理部211において、受信側データリンクのレート見積もりと必要な情報取得処理とを行う。これらの構成のうち、受信側トランスポートレート制御部235は、本発明に係る伝送レート制御部の一実施形態である。アクセスポイント105は、図3に示すように、ブリッジ機構207と、無線リンク層処理部209と、有線リンク層処理部205と、を備える。ブリッジ機構207は、無線ネットワークと有線ネットワークの間のネットワークブリッジ機能の処理を行う。無線リンク層処理部209は、ブリッジ機構207のうち無線ネットワークのデータリンク層の処理を行う。有線リンク層処理部205は、ブリッジ機構207のうち有線ネットワークのデータリンク層の処理を行う。アクセスポイント105の無線リンク層処理部209には、伝送されるデータパケット省略してパケットとも呼ぶ121を一時的に保持するバッファが設けられている。アクセスポイント105は、一方から他方へデータパケットを転送する際、他方のネットワークに輻輳が生じてデータパケットを送出できない場合に、このデータパケットをバッファに一時的に蓄える。そして、アクセスポイント105は、他方のネットワークの輻輳が回復したら、バッファに蓄えたデータパケットを他方のネットワークを介して転送する。このバッファの作用により、アクセスポイント105は、ネットワークの一時的な輻輳に対して、データパケットの損失をある程度回避することができる。次に、上記のネットワーク構成において、データの伝送処理の流れについて説明する。送信側端末101は、送信側トランスポート層処理部201から送信側データリンク層処理部203を介して、アクセスポイント105へ向けてデータパケット121を送信する。アクセスポイント105の有線リンク層処理部205は、データパケット121を受信し、ブリッジ機構207を通じて、データを無線リンク層処理部209へ中継する。アクセスポイント105は、無線リンク層処理部209と受信側端末103の受信側データリンク層処理部211を介して、無線リンクを通じてデータパケット121を受信側端末103へ送信する。受信側データリンク層処理部211は、受信側端末103内の受信側トランスポート層処理部213へデータパケット121を転送する。アクセスポイント105と受信側端末103とは、エッジネットワーク113で無線の輻輳または衝突により伝送エラーが生じると、データ再送を試行する。このデータ再送は、受信側データリンク層処理部211と無線リンク層処理部209とにより、データリンク層の伝送処理として実行される。また、受信側トランスポート層処理部213と送信側トランスポート層処理部201とは、ネットワークの混雑状況に応じて、まとめて伝送するデータ量、すなわち、1回の確認応答を必要とする伝送データの量を変化させる。一般には、このデータ量の可変制御をウインドウ制御と呼び、ひとまとめのデータを受けるバッファのことをウインドウバッファと呼ぶ。また、このひとまとめのデータ量は、ウインドウサイズと呼ぶ。上記のデータ伝送中、コアネットワーク102またはエッジネットワーク111,113に何らかの障害が起きて伝送エラーが生じると、送信側トランスポートレート制御部231は、伝送エラーが生じないレベルに伝送レートを低くする。また、ネットワークの障害が取り除かれて伝送レートが回復可能になったときには、次に示すレート制御を行う。つまり、受信側トランスポートレート制御部235と送信側トランスポートレート制御部231とは、協働し、次に示すレート制御により伝送レートの回復を図る。次に、実施の形態1におけるレート制御について、説明する。図4は、実施の形態1の受信側端末103と送信側端末101とにより行われるレート制御の手順を示すフローチャートである。図4のレート制御は、通常のデータ伝送の進行中に行われる。具体的には、図4のレート制御は、送信側端末101からAVストリーミングデータを受信する通信セッションの開始から終了までを通して、定期的に繰り返し実行される。或いは、図4のレート制御は、トランスポート層情報またはデータリンク層情報に基づきネットワーク状況に変化が検出された際に実行されるようにしてもよい。また、図4のレート制御は、データパケットの損失が生じた場合には、高い頻度で実行され、データパケットの損失がない場合には、低い頻度で実行されるようにしてもよい。なお、図4のレート制御の処理のうちステップS807~S809の処理は、ネットワーク状況が輻輳から回復する際に実行される処理である。ネットワーク状況が輻輳へ陥る際に実行されるレート制御の処理では、ステップS807は省略され、ステップS808,S809のリカバリスケジュールは、単に伝送レートのスケジュールに変更される。ステップ801において、受信側データリンクレート制御部233は、可変ウインドウバッファを用いてデータリンク層のリトライ率を算出する。ここで、リトライ率とは、アクセスポイント105と受信側端末103との間で行われるデータリンク層におけるデータ再送制御の試行率である。また、可変ウインドウバッファとは、上述したトランスポート層のウインドウ制御におけるウインドウサイズに対応させて、サイズが変化するリトライ率算出用のバッファである。リトライ率の算出方法の詳細は後述する。次に、ステップS802において、受信側データリンクレート制御部233は、データリンク層のリトライ率を用いて、データリンク層の実効ビットレートを概算する。ここで、実効ビットレートとは、データリンク層における伝送レートを表わすもので、データリンク層からトランスポート層へ転送される有効なデータペイロードデータなどの伝送レートである。受信側データリンクレート制御部233は、トランスポート層のフィードバックパケット123のやり取り、および、データリンク層の再送制御に伴う無効なデータ送信などを反映させて、実効ビットレートを算出する。実効ビットレートの算出方法の詳細は後述する。次に、ステップS803において、受信側データリンクレート制御部233は、受信側トランスポートレート制御部235へ、輻輳位置を識別するために必要なデータリンク層の情報を伝達する。データリンク層の情報には、例えば、無線ノイズの大小情報、電波強度の良否情報、データ再送の率および回数、パケット到着間隔、および、アクセスポイントのバッファ使用率バッファ負荷とも呼ぶなどが含まれる。以下の説明では、このデータリンク層の情報を、ネットワーク階層をまたぐ情報であることからクロスレイヤ情報とも呼ぶ。なお、受信側データリンク層処理部211は、この処理で必要となるため、アクセスポイント105のバッファの使用率の情報を取得する機能を備えている。次に、ステップS804において、受信側トランスポートレート制御部235は、トランスポート層の情報と、受信側データリンクレート制御部233からのクロスレイヤ情報とを解析する。そして、この解析に基づいて、受信側トランスポートレート制御部235は、図5に示すように、現在のネットワーク状況輻輳、回復、輻輳位置、輻輳の要因などを含むを識別する。このトランスポート層の情報には、RTTRoundTripTimeなどが含まれる。図5は、実施の形態1のネットワーク輻輳位置の識別パターンと伝送方針の決定パターンとの一例を示す図表である。本実施の形態では、図5において、トランスポート層の情報をL4情報、データリンク層の情報クロスレイヤ情報をL2情報と記している。この識別処理により、受信側トランスポートレート制御部235は、図5のネットワーク状況推定の列に示されるネットワーク状況の識別結果を得る。この識別結果としては、例えば、コアネットワーク有線区間102の輻輳、または、エッジネットワーク無線区間113の輻輳などが含まれる。また、この識別結果としては、エッジネットワーク無線区間113の輻輳からの回復、無線ノイズによるエッジネットワーク無線区間113の一時的な障害などが含まれる。次に、ステップS805において、受信側トランスポートレート制御部235は、識別したネットワーク状況に基づいて、図5の伝送方針の列に示すように、現在のデータ伝送の方針を決定する。例えば、ネットワーク状況が有線区間の輻輳であると推定した場合、受信側トランスポートレート制御部235は、長い期間伝送レートを低くする方針従前のレート制御の方針とする。また、無線区間の輻輳と推定した場合、受信側トランスポートレート制御部235は、伝送レートを下げる方針とする。また、無線区間の輻輳からの回復状態と推定した場合、受信側トランスポートレート制御部235は、伝送レートを即座に回復する方針とする。また、無線区間の一時的な無線ノイズによる障害と推定した場合、受信側トランスポートレート制御部235は、伝送レートを変化させない、または、伝送レートを小さい幅で下げる方針とする。次に、ステップS806において、受信側トランスポートレート制御部235は、受信側データリンクレート制御部233で算出した実効ビットレートから、トランスポート層で達成できるエンドツーエンドのスループットを算出する。このスループットの算出方法の詳細は後述する。次に、ステップS807において、受信側トランスポートレート制御部235は、L4情報とL2情報との履歴情報を用いて、必要があれば、トランスポート層の伝送レートを回復させる制御スケジュールの補償を行う。なお、制御スケジュールは、リカバリスケジュールと呼ぶものとする。ここで、リカバリスケジュールとは、ステップS805,S806において決定された伝送方針および伝送レートエンドツーエンドのスループットのうち、ネットワーク輻輳の回復時に適用するものである。ステップS805,S806で決定された伝送方針および伝送レートは、アクセスポイント105のバッファ使用状況が考慮されていないため、このステップS807で補償を行う。受信側トランスポートレート制御部235は、この補償処理のために、必要な期間、L4情報とL2情報を履歴情報として保持および管理している。受信側トランスポートレート制御部235は、アクセスポイント105のバッファ使用率に基づき、図6に示すリカバリスケジュールの補償パターンに従って、リカバリスケジュールの補償を行う。具体的には、受信側トランスポートレート制御部235は、バッファ使用率が少なければ、伝送レートを速やかに上昇させるパターンを選択する。一方、受信側トランスポートレート制御部235は、バッファ使用率が多ければ、所定期間、伝送レートを次第に上昇させて補償パターンを選択する。このリカバリスケジュールの補償により、アクセスポイント105は所定期間のうちにバッファに溜まっている伝送データを転送させて、バッファをクリアすることができる。図6は、実施の形態1のリカバリスケジュールの補償パターンの一例を示す図表である。なお、図6は、無線区間の障害から回復する際のリカバリスケジュールに対する補償パターンを示している。受信側トランスポートレート制御部235は、有線区間の輻輳から回復する際に、図6に示すリカバリスケジュールの補償は行わない。なお、スループットを次第に上昇させる補償を行う際、受信側トランスポートレート制御部235は、現在の実効ビットレートおよびデータリンク層のリトライ率等の少なくとも一つの情報を利用して、補償量の最適化を図ってもよい。また、受信側トランスポートレート制御部235は、バッファ使用率の情報が取得できない場合、代わりに、RTTの履歴情報を用いてバッファ使用率を推定し、同様の補償処理を行うことができる。この代替的な処理の詳細は後述する。次に、ステップS808において、受信側トランスポートレート制御部235は、決定したリカバリスケジュールに基づいて、このスケジュールの実行に必要な情報をフィードバックパケット123に入れて送信側端末101へ送信する。フィードバックパケット123には、変更後の送信レートの値、変更タイミング、変更にかけるタイムスパン、損失したデータパケットの識別情報、または、有線区間の輻輳に対応した従前のレート制御処理の起動指示などが含まれる。次に、ステップS809において、送信側端末101の送信側トランスポートレート制御部231は、フィードバックパケット123に含まれるリカバリスケジュールに従って、伝送レートを実際に回復させるレート制御を行う。具体的には、送信側トランスポートレート制御部231は、フィードバックパケット123の内容に基づいて、送信レートの変更、或いは、従前のレート制御処理の起動を行う。また、送信側トランスポートレート制御部231は、フィードバックパケット123の内容に基づいて、損失したデータパケットの速やかな再送を行う。この損失したデータパケットを速やかに再送する処理の詳細については後述する。上記一連のレート制御によれば、例えば、コアネットワーク102の輻輳から回復する際には、輻輳を悪化させないように伝送レートを緩やかに上昇させる通常のレート制御が実現される。また、無線区間のエッジネットワーク113の一時的なノイズ障害または輻輳から回復する際には、無駄に低い伝送レートが続かないように、伝送レートを適宜速やかに上昇させるレート制御が実現される。次に、上述したレート制御の幾つかのステップのより詳細な具体例を説明する。[リトライ率の算出方法S801]ステップS801のリトライ率の算出は、受信側端末103と送信側端末101の伝送経路に含まれる無線リンク伝送状況を把握し、実効ビットレートの推定を行うために、次のように行われる。先ず、ステップS801の算出処理のために、受信側データリンクレート制御部233は、常時、無線区間の再送に伴うスループットの損失分を特定するための統計データを作成する。この統計データの作成には、ウインドウを基礎とした統計生成器が使用される。ウインドウとは、1回のリトライ率を算出するために統計データを取得する期間を表わし、また、リトライ率算出用の可変ウインドウバッファのサイズにも対応する。図7は、リトライ率を算出するための可変ウインドウバッファ500の構成例を示す。可変ウインドウバッファ500は、ウインドウサイズのシフトレジスタにより構成される。可変ウインドウバッファ500には、最新のリトライ履歴情報501が保存されるとともに、現時点のリトライ情報505が順次更新入力されることで、過去のリトライ履歴情報503が可変ウインドウバッファ500上で順次シフトされる。ここで、リトライ情報およびリトライ履歴情報とは、対象の時点におけるデータ再送の有無を示す情報である。可変ウインドウバッファ500には、リトライ情報の履歴を保持するためにウインドウサイズに対応する長さのシフトレジスタが使用される。ここで言うウインドウサイズとは、前述したトランスポート層のウインドウ制御におけるウインドウサイズのことである。図7の例では、ウインドウサイズは128個のパケットである。このため、可変ウインドウバッファ500には128ビットのシフトレジスタを使用している。トランスポート層のウインドウ制御におけるウインドウサイズが変化すれば、可変ウインドウバッファ500もウインドウサイズにあわせてサイズを変化させる。受信側データリンクレート制御部233は、データリンク層でパケットが受信される度に、シーケンス番号が順序通りであるかどうかチェックする。シーケンス番号が順序通りでない場合には、受信側データリンクレート制御部233は、無線区間でパケットロスがあると予測する。そして、受信側データリンクレート制御部233は、リトライ限界の回数まで再送が試行されたと推定し、可変ウインドウバッファ500にリトライ限界の回数分1の値を書き込む。この書き込みにより、可変ウインドウバッファ500には、リトライを表わす1の値が、リトライ限界回数分左にシフトされながら書き込まれる。また、受信したパケットが順序通りのシーケンス番号をもつ場合、受信側データリンクレート制御部233は、再送インジケータが受信データパケット121に関連付けられているか否かをチェックする。再送インジケータが有効であれば、受信側データリンクレート制御部233は、可変ウインドウバッファ500のデータを左へS回ビットシフトし、最初からS-1回のビットシフトではリトライを表わす1の値を入力する。また、最後のビットシフトでは、受信側データリンクレート制御部233は、リトライ無しを表わす0の値を入力する。ここで、Sはリトライの失敗率であり、後述するようにノイズレベルと信号強度によって決定される。一方、順序通りのシーケンス番号の付いたパケットが受信され、再送インジケータが何も設定されていない場合には、受信側データリンクレート制御部233は、可変ウインドウバッファ500のデータを左へ1回ビットシフトさせる。そして、受信側データリンクレート制御部233は、リトライ無しを表わす0の値を入力する。リトライの計数値は、初期化時に0に設定される。受信側データリンクレート制御部233は、可変ウインドウバッファ500のデータをビットシフトさせる度に、リトライの計数値を更新する。具体的には、ビットシフトの度に、受信側データリンクレート制御部233は、可変ウインドウバッファ500から出ていくビット値例えば128ビット番目の値と、入力されるビット値例えば1ビット番目の値とを比較する。そして、これら二つが同じであれば、受信側データリンクレート制御部233は、リトライの計数値を変更しない。出ていくビット値が1であり、入力されるビット値が0であれば、受信側データリンクレート制御部233は、リトライの計数値をデクリメントする。但し、リトライの計数値が0である場合には、そのままとする。また、出ていくビット値が0であり、入力されるビット値が1であれば、受信側データリンクレート制御部233は、リトライの計数値をインクリメントする。ウインドウ期間内のリトライ率RetryRateは、次の式により、リトライの計数値RetryCountと、ウインドウサイズWindowSizeから算出可能である。図7の具体例では、WindowSizeは128である。前述したように、ウインドウサイズは、データ伝送の状況に依存して変化する。ウインドウサイズが変更されると、リトライの計数値は、0または新たにサイズ変更された可変ウインドウバッファ500内で1の値を持つビットの個数に再設定される。例えば、ウインドウサイズが64パケットに変更される場合には、旧可変ウインドウバッファ500の1~64ビット番目のみの値が維持される。この場合、リトライの計数値は、1ビット番目から64ビット番目までの中で1の値をとるビットの個数に設定される。なお、上記の例では、リトライ率を算出するために導入されるウインドウの長さは、パケット単位で制御される構成とした。この制御は、リトライ率を推定する上で簡単で容易な方法である。しかし、長時間に渡りパケットが受信されないなどの深刻な障害の影響を避けるために、ウインドウは、時間を基礎として可変制御される構成としてもよい。この場合、パケットが受信されないまま、予め設定されたパケット送信タイマーの計時が終了するタイムアウト度に、受信側データリンクレート制御部233は、可変ウインドウバッファ500のデータを左へビットシフトする。そして、受信側データリンクレート制御部233は、リトライを表わす1の値を可変ウインドウバッファ500に新たに入力する。この場合、リトライ計数値は、パケットの受信またはタイムアウトによって更新される。また、上記の例では、可変ウインドウバッファ500は、ウインドウサイズの変更に伴いそのサイズを変動させる構成とした。しかし、リトライ率を算出する構成は、ウインドウサイズ毎に用意された長さの異なる複数のシフトレジスタを使用する構成としてもよい。この場合でも、ウインドウサイズが変わる際に、受信側データリンクレート制御部233は、使用するシフトレジスタをウインドウサイズの対応するものに変更すればよい。なお、受信データパケット121が再送データであるか否かは、受信データパケット121の無線リンクヘッダの再送マーキングの有無により判別できる。例えば、無線リンクがIEEE802.11非特許文献10を参照の技術を使用している場合、ヘッダは、そのパケットが再送であるか否かのインジケータを持っている。また、IEEE802.11において、アクセスポイント105は、パケットを黙って廃棄するまでに4~7回のパケットの再送が可能である。また、IEEE802.11パケットでは、データリンク層のヘッダが、管理フレームとデータフレームの両方で共有されるシーケンス番号も提供する。したがって、受信側データリンク層処理部211は、シーケンス番号Aのデータパケット121を受信すると、それ以前の最後に受信成功したパケットのシーケンス番号Bと、シーケンス番号を比較する。そして、受信側データリンク層処理部211は、新たに受信した管理フレームの数Cに基づく修正を行うことによって、何個のデータパケットを損失したかを推定できる。また、リトライの失敗率Sの値は、例えば、ノイズレベルまたは信号強度レベルといった無線状況に基づいて決定され得る。Sの値は、1~Tの範囲に入る。ここで、Tは、無線リンク層処理部209において、その回数以上のリトライがあった場合に、送信失敗処理へ遷移するリトライ限界数である。一般に、ノイズレベルがより高い場合、または信号強度がより低い場合、SはTにより近い値になり、逆の場合には、Sは1に近くなる。Sの値は、例えば、次の無線パラメータ間の所定のマッピングに基づいて、決定することも可能である。無線パラメータとは、例えば、ノイズレベル、アップリンクの失敗率、低減化期間、物理層のキャリア検知統計値、アップリンク送信試行の衝突率、前に演算されたリトライ率R等である。この所定のマッピングを実現するデータは、広範な測定とシミュレーションにより作成され、受信側端末103の無線モジュール用のファームウェアの一部とし、受信側データリンクレート制御部233内に記憶されること可能である。この場合、ユーザは、ネットワークを介して更新データをダウンロードすることにより、マッピングのデータを更新することができる。また、ウインドウサイズWindowSizeは、次のように動的に変化させてもよい。すなわち、受信側データリンクレート制御部233は、例えば、ノイズレベル、信号強度、及び前回算出されたリトライ率といった無線リンクのパラメータを利用して、使用すべき適切なウインドウの長さを決定してもよい。具体的には、ノイズレベルと信号強度が大きく変化せず、且つ、リトライ率が両方向に突然変化する、即ち、時折上昇し時折下降する場合、受信側データリンクレート制御部233は、ウインドウの長さを比較的大きな値に維持する。これにより、一時的な障害によるリトライ率の変化は、取り除かれる。しかし、演算されたリトライ率と共にノイズレベルと信号強度が変化している場合、受信側データリンクレート制御部233は、無線環境の変化を即座に反映できるように、ウインドウの長さをより小さく縮小する。例えば、ノイズレベルが高くなる場合および/または信号強度があるしきい値以下に低下し、且つ、演算されたリトライ率が上昇している場合には、ウインドウの長さはより短いものに縮小される。同様に、ノイズレベルが突然低くなった場合および/または信号強度がより高くなった場合、且つ、演算されたリトライ率が下降しているときには、ウインドウの長さはより短くされる。これにより、受信側データリンクレート制御部233は、無線環境の変化に十分速く対応できるリトライ率を算出できる。[実効ビットレートの概算方法ステップS802]一般に、無線リンクは、様々な状況に対応して使用される多様なリンクレートを持つ。例えば、IEEE802.11非特許文献10は、様々な符号化方式と変調方式に対応する様々なリンクレートを定義している。様々な無線状況に応じて、無線リンク層処理部209は、信頼性があり効果的な通信を成し遂げるために伝送レートを調整する。しかし、リンクレートの選択変更は、また、実際のトランスポート層のスループットに効果および影響がある。また、リンクレートの異なる複数種類の伝送処理には、それぞれ異なるオーバヘッドが含まれる。例えば、選択したリンクレートが24Mbpsであるならば、無線リンクにおけるフィードバック制御の伝送には、そのレートの半分である12Mbpsしか使用できない。同時に、例えば、ビーコンフレームのように、全ての端末へブロードキャストされる管理フレームは、上記のレートよりもかなり低いレートで伝送される必要がある。同様に、異なる無線技術は、オーバヘッドに大きな影響を与え得る。例えば、IEEE802.11bモードが使用される場合には、共通管理フレーム用に使用されるレートはより低くされるため、管理フレームを送信するためのオーバヘッドはかなり高くなる。そして、IEEE802.11n非特許文献11モードが、複数アンテナの同時利用MIMO:MultipleInputMultipleOutputで使用される場合には、オーバヘッドは一様でないことがあり得る。これは、データリンク層のヘッダが数ストリームの一つでのみで伝送されるためである。したがって、トランスポート層での実効ビットレートを正確に推定するためには、受信側データリンクレート制御部233は、リアルタイムの物理層の情報を利用する。この情報は、受信データパケットに付属しており、妥当なパラメータを決定するために使われる。例えば、無線アクセス技術がIEEE802.11非特許文献10、非特許文献11である場合には、以下の情報が使用される。‐オペレーションモード情報:例えば、IEEE802.11b/g/a/nの各モードなど、該当するオペレーションモード‐暗号化モード情報:暗号化が実施される場合、例えば、AESAdvancedEncryptionStandard-128、3DES3DataEncryptionStandardなど、暗号化アルゴリズムの種別‐リンクレート:無線リンクの動作モードオペレーションモードとも呼ばれるに応じたリンクレートリンクレートは、様々な形式で表現され得る。例えば、IEEE802.11a/b/gモードの場合、リンクレートは、Mbps単位で表現される。一方、動作モードがIEEE802.11nであれば、リンクレートは、MCSModulationandCodingSchemeインデックスの形で表現される。また、リンクレートは、MCSインデックスとキャリア帯域幅を組み合わせると、適切なリンクレートを導き出せる。‐ビーコン間隔‐ショートガードインターバルの使用の有無‐PLCPヘッダのオーバヘッドPLCPPhysicalLayerConvergenceProtocolProcedureヘッダ長は、変調及び符号化方式に基づいて導出可能である。そして、この変調及び符号化方式は、IEEE802.11a/b/gモードではリンクレート値から導出可能である。また、IEEE802.11nモードでは、MCSインデックスから導出可能である。‐IEEE802.11nモード使用時の使用ストリーム数ストリーム数に基づいて、リンク層ヘッダのオーバヘッドが算出可能である。なお、受信側データリンク層処理部211において、実効ビットレートの演算に使用可能な上記以外の他の情報があることは当業者にとって明らかである。何れの情報を使用するかは、本発明の概念に影響することではない。上記の情報を使用して、受信側データリンクレート制御部233は、次のようにして、無線リンク上でサポート可能なトランスポート層での実効ビットレートを推定する。先ず、受信側データリンクレート制御部233は、動作モードをチェックする。動作モードがIEEE802.11a/b/gのうちのいずれか一つであるならば、受信側データリンクレート制御部233は、対応する一組の実効ビットレート演算式を使用する。まず、IEEE802.11a/b/gモードの無線リンクの実効ビットレート推定は、演算式1を用いて計算する。この演算式1では、次の各時間のオーバヘッドを反映させた実効ビットレートEbtmbpsの計算が行われる。式1中の各パラメータは、次の通りである。‐Psize:トランスポート層のビット単位のペイロードサイズ‐Pt:データリンク層と物理層のオーバヘッドを含む実際のデータパケットを送信するのに要する時間‐Ft:対応する無線リンクのフィードバック制御用のデータ送信に要する時間‐1Binterval:ビーコンフレームを反映させた伝送効率‐:データリンク層のリトライ率を反映させた伝送効率‐Blength:ビーコンの長さ‐Binterval:ビーコンの間隔‐Rbeacon:ビーコン管理フレームを転送するためのレート‐Retry_Rate:ステップS801で算出されたリトライ率次に、データリンク層と物理層のオーバヘッドを含む実際のデータパケットを送信するのに要する時間Ptは、次式2で求めることができる。式2中の各パラメータは、以下の通りである。‐Psize:トランスポート層のビット単位のペイロードサイズ‐DataRate:受信側データリンク層処理部211によって、受信したデータパケット121に含まれるMbpsMegabitspersecond単位の受信レート‐Cprob:衝突の確率衝突の確率の値は、受信側データリンク層処理部211によって検知されたノイズレベルの変化によって調整され得る。これは、受信側データリンク層処理部211内にマッピングテーブルとして保存可能である。‐a:IEEE802.11非特許文献10に定義され、RTS/CTSRequesttoSendCleartoSend機構が有効であるか否かに依存する値aは、RTS/CTSが無効である場合には0であり、有効であれば1である。‐SIFS:短いフレーム間の間隔‐Backoff:平均のデータリンク層の低減化ウインドウwindowサイズこのサイズは、無線環境情報に基づいて動的に補正可能でもある。例えば、データリンク層が同一のアクセスポイント105に結び付いた無線局の数が多いこと、またはチャネル利用率が高いことを検出した場合には、この値はより高い値に設定され得る。受信側端末103は、IEEE802.11非特許文献10に定義されているように、ビーコンフレーム中のBSSBasicServiceSetのLOAD負荷情報からこれらの情報を取得できる。‐Tslot:スロット時間‐Protocolheader:それぞれ、データリンク層、ネットワーク層、及びトランスポート層に対応するそれぞれの層で使用されるヘッダ‐Tail:最後尾のビット‐Rsize:RTSのサイズ‐Csize:CTSのサイズ‐B:CTS‐RTSCleartoSendRequesttoSend方式が使用される場合に1、使用されない場合は0‐Asize:IEEE802.11ACKのサイズ‐Rctl:制御フレームの送信レート‐Preamb:プリアンブルの時間幅‐PLCP:物理層ヘッダの時間幅‐Sigext:信号拡張部分の時間幅次に、対応する無線リンクのフィードバック制御用のデータ送信に要する時間Ftは、次式3で求めることができる。式3中のパラメータは、以下の通りである。‐Feedback_size:例えば、拡張オプションの付いたTCPACKといったトランスポート層のフィードバックパケット123のサイズその他のパラメータは、式2で説明したものと同じである。なお、SIFS、Tslot、Preamb、PLCP、Sigext、MAC、Tail、Rsize、Csize、Rsize、Blength、Bintervalの各パラメータの値は、オペレーションモードとアクセスポイント105によって選択されたデータレートに依存する。受信側データリンク層処理部211は、受信したデータパケット121のデータレートをチェックすることによって、変調及び符号化方式を推定できる。この推定結果を用いて、受信側データリンク層処理部211は、IEEE802.11非特許文献10での定義に基づき、上記のパラメータの値を決定することができる。また、Rctrl及びRbeaconは、次の幾つかの設定に依存する。設定1:データパケット送信のためにアクセスポイント105によって選択されたデータレート設定2:例えば、IEEE802.11gと802.11bモード、またはIEEE802.11gモードのみというようなアクセスポイント105のオペレーションモード本実施の形態の実効ビットレートの演算式1では、無線リンクのフィードバック制御でのやり取り、データリンク層でのリトライ率および最大再送回数などが考慮される。具体的には、この演算式1では、無線メディアアクセスの衝突、および、それより前に推定されたリトライ率による潜在的なバックオフ等が考慮される。したがって、この演算式1により、受信側データリンクレート制御部233、受信側データリンク層処理部211の実効ビットレートをより厳密に算出することができる。なお、実効ビットレートの演算式1は、無線リンクでのデータ伝送において、暗号化通信が使用されないことを前提とした演算式である。なお、これ以外の種類の設定を反映するように、本演算式は、容易に変更可能であることは当業者にとって明らかである。例えば、暗号化が実施される場合、演算式中のPsizeは、暗号化前の実際のトランスポート層パケットのペイロードサイズに修正される。また、それ以外のPsize、ネットワーク層及びトランスポート層プロトコルヘッダは、すべて、暗号化後のサイズに修正される。これらの細かな変更は、本発明の概念に影響しないことは明白である。また、受信側データリンクレート制御部233は、特にトランスポート層プロトコルヘッダについて、すべての情報をもたない場合もある。したがって、一つの代替的な方法として、受信側データリンクレート制御部233は、受信側データリンク層処理部211に関する演算だけを実行する構成としてもよい。この場合、受信側データリンクレート制御部233は、途中までの演算結果を、クロスレイヤ情報と共に受信側トランスポート層処理部213内の受信側トランスポートレート制御部235まで送る。次に、受信側トランスポートレート制御部235は、受信側トランスポート層処理部213に知らされたトランスポート層の情報を付加して、実効ビットレートの演算を完了する。次には、無線リンクがIEEE802.11nモードで動作している場合の、別の実効ビットレートEbtの算出式4を示す。式4中の各パラメータは、次の通りである。‐Psize2:トランスポート層のビット単位のペイロードサイズ‐Phyt:データパケットの送信に付随する物理層のオーバヘッドの処理時間‐Mact:データパケットの送信に付随するデータリンク層のオーバヘッドの処理時間‐Trpt:ペイロードを送信するのに要する時間‐Trft:トランスポート層のフィードバックパケット123を送信するのに要する時間‐1Binterval:ビーコンフレームを反映させた伝送効率‐:データリンク層のリトライ率を反映させた伝送効率次に、トランスポート層のビット単位のペイロードサイズPsize2は、次式5で求めることができる。式5中の各パラメータは、以下の通りである。‐L2_frame_size:A-MPDUAggregatedMacProtocolDataUnitの連結後に、伝送のために物理層に渡されるPDUProtocolDataUnitのサイズ‐NmberofframesinA‐PMDU:A-MPDUフレームに含まれるフレームの数このフレームの数は、受信側データリンク層処理部211内に設定しておくことができ、アクセスポイント105へ通知される。また、受信側データリンク層処理部211は、リアルタイムの受信データパケットからこの値を読み込むことができる。‐Header_overheads:データリンク層、ネットワーク層、トランスポート層のヘッダのサイズ‐AMPDU_overhead:A-MPDUパケット構成中で使用される、A-MPDU区切り文字、A-MPDUパディング、等のサイズ次に、データパケットの送信に付随する物理層のオーバヘッドの処理時間Phytは、次式6で求めることができる。式6中の各パラメータは、以下の通りである。‐N_tx:データの伝送に使用される空間的ストリームの数この空間的ストリームの数は、データリンク層のパラメータから取得可能である。‐A:CTSCleartoSend‐to‐self方式が使用される場合に1、使用されない場合に0‐B:CTS‐RTSCleartoSendRequesttoSend方式が使用される場合に1、使用されない場合は0‐Preamb、SIFS、DIFS:IEEE802.11n非特許文献11に定義されているデータリンク層で使用されるパラメータ次に、データパケットの送信に付随するデータリンク層のオーバヘッドの処理時間Mactは、次式7で求めることができる。式7中の各パラメータは、以下の通りである。‐Asize:IEEE802.11ACKのサイズ‐Csize:CTSのサイズ‐Rsize:RTSのサイズ‐Ctl_rate:データリンク層で制御フレームを送信するために使用されるレートその他のパラメータは、式6で説明したものと同じである。次に、ペイロードを送信するのに要する時間Trptは、次式8で求めることができる。式8中の各パラメータは、以下の通りである。‐L2framesize:A-MPDUAggregatedMacProtocolDataUnitの連結後に、伝送のために物理層に渡されるPDUProtocolDataUnitのサイズ‐DataRate:データパケットの送信レートこの送信レートは、MCSインデックスとチャネル帯域幅値から導出可能である。次に、トランスポート層のフィードバックパケット123を送信するのに要する時間Trftは、次式9で求めることができる。式9中の各パラメータは、以下の通りである。‐numberofframesinAMPDU:A-MPDUフレームに含まれるフレームの数このフレームの数は、受信側データリンク層処理部211内に設定しておくことができ、アクセスポイント105へ通知される。また、受信側データリンク層処理部211は、リアルタイムの受信データパケットからこの値を読み込むことができる。‐Feedback_size:例えば、拡張オプションの付いたTCPACKといったトランスポート層のフィードバックパケット123のサイズその他のパラメータは、式8で説明したものと同じである。なお、上記のパラメータのいくつかは、データパケットの受信によって受信側データリンク層処理部211が入手可能なその他のパラメータから導出または推量される。例えば、numberofframesinA‐PMDUは、ペイロードサイズPsizeを、次のデータサイズ1~3の合計で除算することにより導出される。データサイズ1:A-MPDU中のサブフレームのフレームサイズデータサイズ2:LLCLogicalLinkControlヘッダのサイズデータサイズ3:IEEE802.11nデータリンク層ヘッダのサイズ本実施の形態の実効ビットレートの演算式4では、無線送信に使用されるストリームの数、および、物理層におけるフレームの総数が考慮されている。言い換えれば、この演算式4は、複数の空間的及び時間的送信ストリームN_txにより決定のデータリンク層での総計numberofframesinA‐PMDUにより決定を、考慮したものである。つまり、この演算式4は、IEEE802.11nの特徴を反映させたものである。さらに、この演算式4では、物理層とMAC層のオーバヘッドの時間が十分に考慮される。例えば、受信側データリンク層処理部211がデータパケットの送信に使用される二つのストリームを検出した場合、物理層のオーバヘッドは、そのうちの一つのストリーム中にだけ存在することになる。したがって、上記の演算式4、6において、オーバヘッド時間403の値は、プリアンブル時間、PLCP時間、SIFSShortInterFrameSpace及びDIFSDistributedCoordinationFunctionInterFrameSpace時間の合計の2倍に修正されている。一方、アクセスポイント105がデータパケットの送信のために単一のストリームを使用する場合、オーバヘッド値は、プリアンブル時間、PLCP時間、SIFS及びDIFS時間の合計の4倍に修正されている。さらに、この演算式4では、IEEE802.11a/b/gモードの場合と同様に、例えば、ビーコンの送信などの共通管理フレームの送信によるオーバヘッド、及びデータリンク層でのリトライ率についても考慮されている。したがって、この演算式1により、受信側データリンクレート制御部233は、IEEE802.11nの無線リンクが選択されている場合に、受信側データリンク層処理部211の実効ビットレートをより厳密に算出することができる。[データリンク層情報の生成及び伝達処理S803]図4のステップS803において、受信側データリンクレート制御部233は、データリンク層情報クロスレイヤ情報とも呼ぶをデータパケットにタグ付けして、受信側トランスポートレート制御部235に送信する。このデータリンク層情報クロスレイヤ情報は、次の情報を含む。‐推定された実効ビットレート‐データリンク層のパケット損失インジケータこれは、リンク層のシーケンス番号と管理フレームを追跡することによって、受信側データリンクレート制御部233が検出する。このインジケータにより、受信側トランスポートレート制御部235は、この成功したパケット送信の前に、パケット損失があったか否かを知ることができる。‐受信したパケットの伝送に際して、データリンク層での再送が実施されたか否かを示す、リトライ指示‐データリンク層でのパケット到着間隔時間‐アクセスポイント105でバッファに格納されたデータを示す、アクセスポイントバッファ負荷これは、受信側データリンクレート制御部233が、データパケットヘッダのQoSQualityofService制御フィールドから取得可能である。‐データリンク層のリトライ限界値‐ノイズレベルと信号強度このデータリンク層情報クロスレイヤ情報の伝達は、ネットワーク階層をまたぐクロスレイヤでの情報受け渡しとなり、通常のプロトコル設計ではサポートされてない。このような情報伝送は、受信側データリンクレート制御部233がアクセスするネットワークデータバッファ構造を変更して実現できる。具体的には、上記の情報伝達は、上記のネットワークデータバッファのパケット保持用バッファ構造に追加のデータエントリを関連づける実装を行って、上記のデータリンク層情報を登録して伝送することで実現できる。例えば、Linuxカーネルでは、skbuffと呼ばれるバッファに上記情報伝達用のフィールドを追加すればよい。また、FreeBSDカーネルでは、mbuffと呼ばれるバッファに上記情報伝達用のフィールドを追加すればよい。[ネットワーク輻輳位置の識別処理S804]図5の表に示したように、受信側トランスポートレート制御部235は、データリンク層の情報L2情報と、トランスポート層の情報L4情報とに基づき、ネットワーク状況を推定し識別する。以下、図5の表に示されるネットワーク状況を推定できる理由については、ネットワークの背景動作とともに説明する。先ず、コアネットワーク102の輻輳によりパケット損失が生じる場合の背景動作について説明する。送信側端末101及びその他のノードからのトラフィックが、ネットワーク中に存在する全リンクの容量を超えた場合に、コアネットワーク102は、輻輳状態になる。輻輳状態になると、パケットは、ネットワーク中の中継ノードのパケットバッファに蓄積されてゆく。中継ノードのパケットバッファがあふれ出した場合は、パケット損失が発生する。このような背景動作から、受信側トランスポートレート制御部235は、次の条件1-4を満たした場合に、コアネットワーク102中で何らかの輻輳が発生したと推定することができる。条件1:トランスポート層で観測された往復時間RTT、またはクロスレイヤ情報に関連付けられたパケット到着間隔時間が、著しく増加した場合条件2:アクセスポイント105のバッファ使用率が増加しないまたは減少した場合条件3:無線ノイズのノイズレベルが低い場合条件4:データリンク層の再送がない場合次に、受信側のエッジネットワーク無線区間113でパケット損失が生じる背景動作について説明する。受信側のエッジネットワーク無線区間113上では、パケット損失が異なる理由により発生する可能性がある。無線区間では、何らかの一時的な無線ノイズまたは電波の干渉が、エラーを伴うパケット受信を引き起こすことがある。エラーを伴うパケット受信は、データリンク層によって振るい落とされる。そのため、トランスポート層などの上位層の処理部は、パケットが損失したと見なす。例えば、IEEE802.11などのある種の無線技術は、再送サービスを提供できる。データリンク層例えば、アクセスポイント105の無線リンク層処理部209および受信側データリンク層処理部211では、パケットが受信側のデータリンク層によって到着確認の応答がない場合、パケットの再送の試行を数回行なう。この再送サービスは、場合によって、パケットロスの状況をある程度緩和できる。しかし、無線ノイズが強固な場合には、パケットの再送も失敗する。そのため、再送サービスは、パケットロスの状況を緩和できない。一方、次の状況では、パケットロスがアクセスポイント105で発生する。例えば、ダウンリンクのトラフィックネットワークを流れる情報がアクセスポイント105に到着した時、受信側のエッジネットワーク無線区間113では、電波干渉によって妨害を受けている場合を想定する。この場合は、アクセスポイント105から受信側端末103へのデータ送信が阻止される。そうなると、パケットは、全てアクセスポイント105のバッファに蓄積されるが、長い間干渉が起きていると、バッファがあふれてパケット損失が生じることになる。このような背景動作から、受信側トランスポートレート制御部235は、次の条件1-3を満たした場合に、受信側のエッジネットワーク無線区間113で輻輳アクセス集中が発生したと推定できる。条件1:アクセスポイント105のバッファ使用率が著しく増加した場合条件2:無線ノイズのノイズレベルが高い場合条件3:データリンク層の再送有りが発生した場合また、受信側トランスポートレート制御部235は、次の条件1-4を満たした場合に、受信側のエッジネットワーク無線区間113が輻輳アクセス集中から回復していると推定できる。条件1:RTTの値が高い場合条件2:アクセスポイント105のバッファ使用率が大きい場合条件3:無線ノイズのノイズレベルが低い場合条件4:信号強度が高い場合また、受信側トランスポートレート制御部235は、次の条件1-4を満たした場合に、RTTの変動が主に無線の一時的障害に起因すると推定できる。条件1:幾つかのパケットについてのRTTの値が高い場合条件2:様へアクセスポイント105のバッファ使用率が所定レベル未満で小さい場合条件3:無線リンク品質例えば、ノイズレベル、信号強度等が良好な場合条件4:データリンク層の再送ある場合このように、受信側トランスポートレート制御部235は、データリンク層の情報とトランスポート層の情報とに基づいて識別処理を行っているので、正確にネットワーク状況を推定し識別することができる。なお、図5では、トランスポート層の情報L4情報として、送信側端末101の送信側トランスポート層処理部201から情報であるRTTを例にとって説明している。しかし、このトランスポート層の情報には、受信側端末103のトランスポート層の情報を含めてもよい。例えば、受信側端末103のトランスポート層の情報としては、例えば、トランスポート層におけるデータパケット損失に関する情報、または、ウインドウサイズの情報などが含まれてもよい。[伝送方針の決定処理S805]ここでは、図5の表に示したように、受信側トランスポートレート制御部235が伝送方針を決定する理由について説明する。輻輳によるコアネットワーク102内でのパケットロスは、通常、深刻な状況であり、復旧するにはより長い時間を要する。このような場合、送信側端末101は、自己の送信レートを調整し、輻輳の悪化を防ぐ必要がある。したがって、受信側トランスポートレート制御部235は、コアネットワーク102の輻輳と推定した場合、さらなる輻輳の悪化を防ぐために、長い期間、伝送レートを低くする伝送方針を決定する。また、パケットロスが受信側のエッジネットワーク無線区間113上の一時的なノイズに起因するものであれば、送信側端末101は、送信レートを大幅に下げる必要はない。むしろ、送信側端末101は、できるだけ速やかに再送を実行すべきである。したがって、受信側トランスポートレート制御部235は、無線区間の一時的な無線ノイズによる障害と推定した場合、速やかな再送が実効されるように、伝送レートを変化なし、または、少しの幅で下げる伝送方針を決定する。また、パケットロスがアクセスポイント105で発生する場合には、事態はさらに複雑である。無線ノイズまたは電波干渉が持続的な場合、送信側端末101は、更なるパケットロスを避けるために送信レートを下げなくてはならない。したがって、受信側トランスポートレート制御部235は、無線区間の輻輳と推定した場合、パケットロスを避けるために、伝送レートを下げる伝送方針を決定する。一方、無線ノイズまたは電波干渉がもはや存在しない場合は、送信側端末101は、トランスポート層のウインドウ制御を用いて送信レートを即座に回復させなくてはならない。したがって、受信側トランスポートレート制御部235は、無線区間の輻輳が回復したと推定した場合、伝送レートを即座に回復させる伝送方針を決定する。ただし、無線ノイズまたは電波干渉は繰り返しまたは周期的に生じる可能性があり。そのため、送信側端末101は、無線状況を反映するために十分迅速に且つ正しい判断を行なうことが重要である。したがって、受信側トランスポートレート制御部235は、繰り返しまたは周期的な無線区間の障害も反映させて伝送方針を決定する構成としてもよい。[エンドツーエンドのスループットの概算S806]図4のステップS806において、受信側トランスポートレート制御部235は、前段で得られた無線区間の実効ビットレートを考慮して、最適なエンドツーエンドのスループットを算出する。また、受信側トランスポートレート制御部235は、前段で識別されたネットワークの輻輳箇所および輻輳原因を考慮して、最適なエンドツーエンドのスループットを算出する。先ず、受信側トランスポートレート制御部235は、ネットワーク輻輳がコアネットワーク102の輻輳によるものと識別した場合、非特許文献1~4に示されるような従来のレート制御を起動および実行する。つまり、この場合、受信側トランスポートレート制御部235は、従来のレート制御に従ったエンドツーエンドのスループットを算出する。ここで算出されるスループットの詳細については、従来のものと同様なので、説明を省略する。また、受信側トランスポートレート制御部235は、ネットワーク輻輳が受信側のエッジネットワーク無線区間113の輻輳によるものと識別した場合、この状況の悪化を避けるように処理を行う。すなわち、受信側トランスポートレート制御部235は、トランスポート層の伝送レートを制限すべく、エンドツーエンドのスループットとして直近に得られた実効ビットレートにより達成可能なスループットを算出する。具体的には、受信側トランスポートレート制御部235は、実効ビットレートからトランスポート層で不要なデータリンク層の情報L2情報を除外して再計算すればよい。その結果、ほぼ伝送レートは変化無し、または、少しの幅で下がるのみである。また、受信側トランスポートレート制御部235は、ネットワークの状況がエッジネットワーク無線区間113の輻輳から回復していると識別した場合、送信レートを回復させるように処理を行う。すなわち、受信側トランスポートレート制御部235は、送信レートを回復すべく、エンドツーエンドのスループットとして直近の回復時に得られた実効ビットレートによって達成可能なスループットを算出する。この場合の実効ビットレートからスループットを算出する具体例は、無線区間の輻輳のときと同一である。無線区間の輻輳のときと、輻輳の回復時とで、実効ビットレートの値が異なることで、算出されるスループットの値は変化する。また、受信側トランスポートレート制御部235は、RTTの変動が主に無線区間の一時的障害に起因して生じていると識別した場合、次の対応を行う。受信側トランスポートレート制御部235は、直近に算出された無線区間の実効ビットレートに近づけるように、達成可能なエンドツーエンドのスループットの値を増加させていく。この制御は、無線区間の一時的障害に起因したエンドツーエンドのスループットの大きな変動を防ぐ作用を及ぼす。具体的には、受信側トランスポートレート制御部235は、実効ビットレートからトランスポート層では不要なデータリンク層の情報L2情報を除外した値に一気に増加させるようにスループットを算出してもよい。また、受信側トランスポートレート制御部235は、上記の値に線形的に増加させて徐々に近づけるようにスループットを算出してもよい。このように算出されたスループットにより、本実施の形態の受信側トランスポートレート制御部235と送信側トランスポートレート制御部231とは、ネットワークの物理的な限界に近い伝送データのレート制御を実現する。[RTTに基づくリカバリスケジュールの補償S807]ここでは、受信側トランスポートレート制御部235が、アクセスポイント105のバッファ使用率の情報を利用できず、RTTの情報からエンドツーエンドのスループットのリカバリスケジュールを補償する場合について説明する。前述のように、受信側トランスポートレート制御部235は、ネットワーク輻輳の位置推定を実施するときに、RTTの変動とデータリンク層の状態とを参照する。このうち、RTT伝送データの往復時間は、無線区間のリトライとメディアアクセス衝突が起きた場合に、無線区間で伝送遅延が生じて、増加することがあり得る。RTTが増加する第1の状況は、一時的な無線ノイズまたは一時的な電波干渉に起因する可能性が最も高い。データリンク層の再送制御には、再送回数の制限すなわちリトライ限界値がある。そのため、この状況に起因する伝送遅延には、通常、上限がある。また、データリンク層の伝送処理では、伝送レートが無線ノイズのレベルに応じて適応されている。したがって、つまり、受信側トランスポートレート制御部235は、リトライ限界値によって制限された上限内でRTTが変化するならば、アクセスポイント105のバッファに余裕があると推定することができる。したがって、この場合、受信側トランスポートレート制御部235は、アクセスポイント105のバッファ使用率が低い場合と同様に、リカバリスケジュールの補償を行わない。一方、RTTが増加する第2の状況としては、無線ノイズまたは電波干渉が強くなった場合がある。この場合、アクセスポイント105は、無線ノイズまたは電波干渉が強くなるほど無線メディアがビジー状態であると検出する。さらに、この場合、アクセスポイント105は、バックオフを行う必要があり、データパケットをバッファに格納する。この場合には、データリンク層の伝送レートを適応させる処理は機能しなくなる。そして、この状況が長く続くまたは周期的に起きる場合は、アクセスポイント105のバッファ使用率は増加し続け、RTTの値も増加する。遂には、アクセスポイント105のバッファが満杯になり、パケット損失が発生する。このRTTの増加の監視を行うため、受信側トランスポートレート制御部235は、データ伝送により繰り返し得られるRTTRoundTripTimeの情報から、RTT増減の比較基準となるベースRTTを取得して保持する。ベースRTTは、例えば、データ伝送のセッション継続時間中に検知した最小のRTTとしてもよい。或いは、ベースRTTは、アクセスポイント105のバッファ負荷が閾値未満と観測された時のRTTとしてもよい。したがって、受信側トランスポートレート制御部235は、RTTがリトライ限界値によって制限された上限を超えて増加していれば、ネットワークが輻輳から回復した際に、アクセスポイント105のバッファ使用率が高いと推定できる。この場合、受信側トランスポートレート制御部235は、アクセスポイント105のバッファ使用率が高い場合と同様に、リカバリスケジュールの補償を行う。このようにRTTの履歴情報を用いることで、受信側トランスポートレート制御部235は、バッファ使用率に応じてリカバリスケジュールを補償する。つまり、受信側トランスポートレート制御部235は、アクセスポイント105のバッファ使用率の情報を直接得ることができない場合でも、リカバリスケジュールを補償することができる。[損失したデータパケットの速やかな再送処理S809]ここでは、ステップS809の処理のうち、送信側トランスポートレート制御部231が損失したデータパケットを速やかに再送する処理について詳細に説明する。前述した通り、受信側データリンクレート制御部233は、無線区間のパケットロス情報を受信側トランスポートレート制御部235へ提供する。このパケットロス情報は、受信側データリンクレート制御部233が、データリンク層のシーケンス番号と受信した管理フレームの数を追跡トレースすることで作成される。そして、無線区間のパケットロス情報が作成されるときは、現在受信に成功したパケットの前に何個かのパケットの損失があることを意味する。したがって、受信側トランスポートレート制御部235は、クロスレイヤ情報に含まれる受信したパケットのシーケンス番号をチェックすることで、どのパケットが再送されるべきかを瞬時に決定する。例えば、受信側トランスポート層処理部213がTCPのようなプロトコルを使用しているならば、順序を外れて受信されたパケットは、最初にバッファに保持される。したがって、受信側トランスポート層処理部213は、再送のために準備されるべき、今のパケットに先行した直前のパケットを識別できる。再送すべきパケットを識別したら、受信側トランスポート層処理部213は、送信側端末101へのフィードバックパケット123の中に、SACKSelectiveAcknowledgement:選択確認応答オプションまたは重複したACKを含める。これにより、受信側トランスポート層処理部213は、再送すべきパケットを送信側トランスポート層処理部201へすばやく通知することができる。或いは、代替的に、トランスポート層のフィードバックパケット123が、損失した疑いがあるパケットを示す追加のオプションフィールドを含む構成としてもよい。この構成により、受信側トランスポート層処理部213は、損失した疑いがあるパケットを送信側トランスポート層処理部201へすばやく通知することができる。そして、これらの通知により、送信側トランスポート層処理部201は、損失したパケットの再送を直ぐにスケジュールすることできる。一般に、TCPなどの通常のトランスポートプロトコルにおいて、受信側端末103は、受信したパケットが順序通りでないときに、前のACKメッセージとまったく同じシーケンス番号を付けてACKメッセージを送信する。送信側端末101は、連続して重複したACKメッセージが所定数例えば3個受信したら、ACKが戻ってこなかったパケットの再送制御を起動させる。つまり、受信側トランスポート層処理部213と送信側トランスポート層処理部201とは、所定数の重複したACKの受信を、再送制御を起動させる指示として使用する。それに対して、本実施の形態では、受信側トランスポート層処理部213が、クロスリンク情報を持っていることで、再送の必要なパケットの情報を送信側トランスポート層処理部201へ直接的に通知できる。したがって、本実施の形態のトランスポート層の再送制御では、一般的な3個の重複したACKによる非到達パケットの検知方式を利用した制御に比べて、ずっと早く再送をスケジュールすることができる。それゆえ、本実施の形態では、トランスポート層の再送制御の性能の向上を促進できる。以上、本発明の実施の形態1について説明した。なお、実施の形態1では、受信側端末103が、レート制御のための伝送方針の決定、エンドツーエンドのスループットの算出、および、リカバリスケジュールの補償を行う構成とした。しかしながら、本実施形態では、送信側端末101がこれらを行う構成とすることも可能であり、このことは当業者にとって明らかである。受信側データリンクレート制御部233と受信側トランスポートレート制御部235は、必要な情報を集め、集めた情報をトランスポート層のフィードバックパケット123として、送信側トランスポートレート制御部231へ渡せばよい。また、送信側トランスポートレート制御部231は、レート制御の内容を決定するために、上記受信した情報と、例えばRTT値およびバッファサイズなど、自ノードにある情報に基づいて、同様の演算処理を行えばよい。また、実施の形態1において、受信側データリンクレート制御部233は、無線リンク状況に関する所定の推定を行って、達成可能なエンドツーエンドのスループットを算出する構成とした。しかし、受信側データリンクレート制御部233は、所定のパターン認識に基づいて無線環境の動向から達成可能なエンドツーエンドのスループットを得る構成としてもよい。例えば、受信側データリンクレート制御部233は、無線リンクが短い一時的な干渉を受けた状況と、無線リンクが実効ビットレートの下降をより長い時間受ける状況とを、パターン認識に基づいて予測することができる。この場合、受信側データリンクレート制御部233は、ウインドウ期間におけるデータリンク層の再送試行の記録と、ノイズレベルに関する統計値とを対象に、パターン認識を行って上記の予測を行うことができる。このパターン認識に必要なパターンデータは、広範な測定とシミュレーションに基づいて予め作成可能であり、受信側データリンクレート制御部233内に記憶可能である。また、実施の形態1では、アクセスポイント105に一つの受信側端末103が無線接続されている構成の動作に主眼を置いて説明した。しかし、本発明は、アクセスポイント105に一つの受信側端末103と、他の1つ又は複数の無線局が接続されている構成に対しても有効に適用できる。例えば、アクセスポイント105は、ビーコン中にブロードキャストされるBSSBasicServiceSet負荷エレメントの情報に、局数カウントの値とチャネル利用率に関する情報とを含めている。局数カウントは、アクセスポイント105に結び付いた無線局STA:ステーションの数を示し、チャネル利用率は、無線メディアがビジーであった時間を示す。これらの情報により、受信側データリンクレート制御部233は、適切な実効ビットレートが使用されるべき対象の無線局を推定できる。また、実施の形態1では、受信側トランスポートレート制御部235が、ネットワーク混雑位置の識別S804と、現在の状況に対する伝送方針の決定S805と、達成可能なスループットの見積りS806とを行う構成とした。しかし、受信側端末103は、別個複数のモジュールを備え、これら複数のモジュールがステップS804~S806の処理をそれぞれ行う構成としてもよい。これらのモジュールは適宜、機能毎に分割または統合されていても構わない。例えば、受信側端末103は、ネットワーク混雑位置の識別機能と、現在の状況に対する伝送方針の決定機能を統合した伝送スケジューリングモジュールを備えてもよい。また、受信側端末103は、データリンク層の実効ビットレートの見積もり機能と、トランスポート層の達成可能エンドツーエンドのスループット見積もり機能とを、統合したレート制御モジュールを備えてもよい。実施の形態2図8は、本発明の実施の形態2のネットワーク伝送装置が加わるネットワーク構成の一例を示す図である。実施の形態2のネットワーク構成には、送信側端末601と、エッジネットワーク611,613と、アクセスポイント603と、コアネットワーク605と、受信側端末607とが含まれる。送信側端末601は、ネットワーク経由でAVストリーミングデータを送出する情報端末である。エッジネットワーク613は、送信側端末601が接続される送信側のネットワーク無線区間である。コアネットワーク605は、インターネットなどを含み、送信側端末601と受信側端末607との間に位置する主に有線のネットワークである。エッジネットワーク611は、受信側端末607とコアネットワーク605とを接続する受信側のネットワーク有線区間である。アクセスポイント603は、送信側エッジネットワーク無線区間613とコアネットワーク605の間に位置して、無線区間と有線区間のネットワークブリッジとして機能する。受信側端末607は、ネットワーク経由でAVストリーミングデータを受信する情報端末である。実施の形態2のネットワーク上で伝送されるデータには、データパケット621と、フィードバックパケット623とが含まれる。データパケット621は、例えばAVストリーミングデータなどであり、送信側端末601から受信側端末607へ向けて送信される。フィードバックパケット623は、データパケット621の伝送に対する応答および伝送制御用のデータを含み、受信側端末607から送信側端末601へ送信される。これらの構成のうち、送信側端末601が、本発明に係るネットワーク端末装置の一実施の形態である。図9は、本実施の形態2の送信側端末601の要部構成図である。送信側端末103は、送信側データリンク層処理部703と、送信側トランスポート層処理部701と、輻輳箇所判別部731aと、伝送レート制御部731bと、実効レート算出部733aと、を備える。送信側データリンク層処理部703は、送信側端末601におけるネットワーク処理のうち、データリンク層の処理を行う。送信側トランスポート層処理部701は、送信側端末601のネットワーク処理のうち、トランスポート層の送信処理を行う。実効レート算出部733aは、送信側データリンク層処理部703の実効ビットレートを算出する。ここで、算出される実効ビットレートは、送信側データリンク層処理部703の再送制御に伴う伝送効率の低下を考慮した実効的な伝送レートである。算出された実効ビットレートの情報は、伝送レート制御部731bへ送られる。輻輳箇所判別部731aは、送信側データリンク層処理部703の伝送状況を表わすデータリンク層情報と、送信側トランスポート層処理部213の伝送状況を表わすトランスポート層情報とに基づいて、ネットワークの輻輳箇所を判別する。データリンク層情報は、本発明に係る第2層情報の一実施形態である。トランスポート層情報は、本発明に係る第4層情報の一実施形態である。判別結果の情報は、伝送レート制御部731bへ送られる。伝送レート制御部731bは、輻輳箇所の判別結果の情報と、実効ビットレートの情報とを受けて、これらの情報に基づき、トランスポート層の伝送レートを決定する制御を行う。なお、後述する図10の具体的な構成例において、実効レート算出部733aは、送信側データリンクレート制御部733に含まれている。しかし、実効レート算出部733aは、送信側データリンクレート制御部733と別に設けられても良い。また、後述する図10の具体的な構成例において、輻輳箇所判別部731aと伝送レート制御部731bとは、図10の送信側トランスポートレート制御部731に含まれている。しかし、輻輳箇所判別部731aと伝送レート制御部731bとは、送信側トランスポートレート制御部731と別に設けられても良い。続く説明では、ネットワークの各ノードが、非特許文献7に示されるTCPTransmissionControlProtocolを使用して、データ伝送を行う例を示している。しかし、データ伝送のためのプロトコルは、送信データのレート制御と受信側から送信側へのフィードバックが可能であれば、その他のプロトコルを適用可能である。このことは当業者にとって明らかであり、本発明の概念に影響するものでない。その他のプロトコルとしては、例えば、非特許文献8に示されるDCCPDatagramCongestionControlProtocolが適用できる。また、その他のプロトコルとしては、非特許文献9に示されるSCTPStreamControlTransmissionProtocolが適用できる。図10は、図8の各装置の論理的構成を示すブロック図である。送信側端末601は、図10に示すように、送信側アプリケーション740と、送信側トランスポート層処理部701と、送信側トランスポートレート制御部731と、送信側データリンク層処理部703と、送信側データリンクレート制御部733と、を備える。送信側アプリケーション740は、データの送信要求と指示とを行う。送信側トランスポート層処理部701は、図9にも示したように、送信側端末601におけるネットワーク処理のうち、トランスポート層の伝送処理を行う。送信側トランスポートレート制御部731は、送信側端末601における送信側トランスポート層処理部701において、送信側のトランスポート層のレート制御と必要な情報取得処理とを行う。送信側データリンク層処理部703は、図9にも示したように、送信側端末601におけるネットワーク処理のうち、データリンク層の伝送処理を行う。送信側データリンクレート制御部733は、送信側端末601における送信側トランスポート層処理部701において、送信側のデータリンク層のレート制御と必要な情報取得処理とを行う。受信側端末607は、図10に示すように、受信側アプリケーション741と、受信側トランスポート層処理部713と、受信側トランスポートレート制御部735と、受信側データリンク層処理部711と、を備える。受信側アプリケーション741は、データの受信要求と指示とを行う。受信側トランスポート層処理部713は、受信側端末607におけるネットワーク処理のうち、トランスポート層の受信処理を行う。受信側トランスポートレート制御部735は、受信側端末607における受信側トランスポート層処理部713において、受信側のトランスポート層のレート制御と必要な情報取得処理とを行う。受信側データリンク層処理部711は、受信側端末607におけるネットワーク処理のうち、データリンク層の処理を行う。アクセスポイント603は、図10に示すように、ブリッジ機構705と、有線リンク層処理部709と、無線リンク層処理部707と、を備える。ブリッジ機構705は、アクセスポイント603において、無線ネットワークと有線ネットワークの間のネットワークブリッジ機能の処理を行う。有線リンク層処理部709は、ブリッジ機構705のうち、有線ネットワークのデータリンク層の処理を行う。無線リンク層処理部707は、ブリッジ機構705のうち、無線ネットワークのデータリンク層の処理を行う。次に、上記のネットワーク構成において、データの伝送処理の流れについて説明する。送信側端末601は、送信側トランスポート層処理部701から送信側データリンク層処理部703を介して、アクセスポイント603へ向けてデータパケット621を送信する。アクセスポイント603の無線リンク層処理部707は、データパケット621を受信し、ブリッジ機構705を通じて、データパケット621を有線リンク層処理部709へ中継する。アクセスポイント603は、有線リンク層処理部709、コアネットワーク605、および、受信側エッジネットワーク有線区間611を介して、データパケット621を受信側端末607へ送信する。受信側端末607は、受信側データリンク層処理部711を介して、データパケット621を受信する。受信側データリンク層処理部711は、受信側端末607内の受信側トランスポート層処理部713へデータパケット621を転送する。図11は、実施の形態2の受信側端末607と送信側端末601とにより行われるレート制御の手順を示すフローチャートである。このレート制御は、通常のデータ伝送の進行中に行われる。ステップS901において、送信側データリンクレート制御部733は、受信側端末607と送信側端末601との伝送経路に含まれる無線区間の伝送状況を把握する。次に、送信側データリンクレート制御部733は、実効リンクレートの推定を行うために、データリンク層におけるリトライ率を算出する。送信側データリンク層処理部703よりアクセスポイント603に送出されたパケットは、エラーを生じずに伝達される場合も、エラーによって送信のリトライが行われる場合もある。このリトライは、無線リソースを必要とするので、無線区間で実際に達成可能なスループットに影響を及ぼす。無線区間におけるデータ再送は、データリンク層で実施され、この再送が失敗を繰り返してトランスポート層で再送制御を行う必要が生じない限り、トランスポート層は関知しない。したがって、送信側トランスポート層処理部701は、従前の構成のままでは、無線区間のデータ再送を加味した処理はできない。送信側データリンクレート制御部733は、無線区間の再送に伴うスループットの損失分を特定するための統計データを作成し、この統計データからリトライ率を算出する。統計データとは、所定期間内の各送信タイミングにおけるデータ再送の有無の履歴を表わすデータである。リトライ率の算出は、実施の形態1におけるステップS801の説明で述べた通り、ウインドウサイズに連動してサイズが変更される可変ウインドウバッファ図7参照を用いて行われる。次に、ステップS902において、送信側データリンクレート制御部733は、送信側データリンクレート制御部733が算出したデータリンク層のリトライ率を用いて、データリンク層の実効ビットレートを見積もる。この計算は、実施の形態1におけるステップS802の説明で述べた通り、使用される無線アクセスのオペレーションモード毎に異なる計算式、例えば、実施の形態1で示した実効ビットレートの演算式1、4を用いて実行される。次に、ステップS903において、送信側データリンクレート制御部733は、実効ビットレートの推定後、トランスポート層へのデータフィードバックに所定のクロスレイヤ情報をタグ付けする。次に、送信側データリンクレート制御部733は、それをタグ付けデータとして、送信側トランスポートレート制御部731に送る。受け渡すクロスレイヤ情報、および、ネットワーク階層をまたいだ情報の受け渡しを行うための実装例については、実施の形態1におけるステップS803の説明で述べた通りである。次に、ステップS904において、送信側トランスポートレート制御部731は、クロスレイヤ情報を用いて、現在のネットワークの輻輳位置の識別を行う。この識別処理は、実施の形態1のステップS804の説明で述べた通りである。次に、ステップS905において、送信側トランスポートレート制御部731は、識別したネットワーク輻輳位置に基づいて現在の状況に対する伝送方針を決定する。この処理は、実施の形態1のステップS805の説明で述べた通りである。次に、ステップ906において、送信側トランスポートレート制御部731は、送信側データリンクレート制御部733で見積もった実効ビットレートを用いて、トランスポート層での達成可能エンドツーエンドのスループットを見積もる。この処理は、実施の形態1のステップS806の説明で述べた通りである。次に、ステップS907において、送信側トランスポートレート制御部731は、実際のデータ送信のスケジュールを算出する際に、履歴情報を用いてデータ送信スケジュールの補償を行う。この補償処理は、実施の形態1のステップS807の説明で述べた通りである。次に、ステップS908において、送信側トランスポートレート制御部731は、実際のデータ送信のリカバリスケジュールを実行する。上記一連のレート制御によって、受信側端末607と送信側端末601とは、ネットワークで伝送レートが低下したときでも、適切に輻輳またはパケットロスの位置を判定することができる。さらに、受信側端末607と送信側端末601とは、更なる輻輳またはパケットロスを防止しつつ利用可能なネットワークリソースを最大限に活用するような、伝送レートの回復に向けたレート制御を実現できる。以上、本発明の実施の形態2について説明した。なお、実施の形態2では、送信側トランスポートレート制御部731が、ネットワーク混雑位置の識別S904と、現在の状況に対する伝送方針の決定S905と、達成可能なスループットの見積りS906とを行う構成とした。しかし、送信側端末601は、別個複数のモジュールを備え、これら複数のモジュールがステップS904~S906の処理をそれぞれ行う構成としてもよい。これらのモジュールは、適宜、機能毎に分割または統合されていても構わない。例えば、送信側端末601は、ネットワーク混雑位置の識別機能と、現在の状況に対する伝送方針の決定機能を統合した伝送スケジューリングモジュールを備えてもよい。また、送信側端末601は、データリンク層の実効ビットレートの見積もり機能と、トランスポート層の達成可能エンドツーエンドのスループット見積もり機能とを、統合したレート制御モジュールを備えてもよい。上記の記述においては、具体的な実施の形態を詳細に説明し、添付の図面に図示したが、当業者は、これらの実施の形態の詳細部分の様々な修正または代替が本開示の全般的な教示内容を踏まえて可能であることを理解されるであろう。したがって、実施の形態に開示された構成は、本発明の範囲についての一例に過ぎず、本発明は実施の形態の構成に限定されるものではない。上記の実施形態の説明で使用された各機能部は、一般に集積回路として表現されるLSIとして実現可能である。これらは、個々に一つのチップとして製造されても、一部または全部を含む一つのチップとして設計されてもよい。ここでLSIと称するものは、集積の程度に応じて、IC、システムIC,超LSI、または極超LSIと呼ばれることもある。また、集積回路の技術は、LSIにだけ限定されず、集積回路は専用回路または汎用プロセッサとして実現可能である。本実施形態は、LSIの製造後にプログラム可能であるFPGAフィールドプログラマブルゲートアレイ、LSI内の回路セルの接続、または、設定が再構成され得る再構成可能プロセッサも使用可能ある。さらに、本実施形態は、半導体技術またはそれから派生したその他の技術の進歩により、LSIに取って代わる回路集積化の技術が出現し得るときには、そのような技術を使用することによって機能部を集積してもよい。例えば、バイオテクノロジーの適応は、このような可能性の一つである。"