JP3604615B2 - 通信装置、中継装置および通信制御方法 - Google Patents
通信装置、中継装置および通信制御方法 Download PDFInfo
- Publication number
- JP3604615B2 JP3604615B2 JP2000121631A JP2000121631A JP3604615B2 JP 3604615 B2 JP3604615 B2 JP 3604615B2 JP 2000121631 A JP2000121631 A JP 2000121631A JP 2000121631 A JP2000121631 A JP 2000121631A JP 3604615 B2 JP3604615 B2 JP 3604615B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- transmission
- packets
- tcp
- link layer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1664—Details of the supervisory signal the supervisory signal being transmitted together with payload signals; piggybacking
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1874—Buffer management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1887—Scheduling and prioritising arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1803—Stop-and-wait protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1806—Go-back-N protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1809—Selective-repeat protocols
Description
【０００１】
【発明の属する技術分野】
本発明は、情報損失補償機能を持った通信プロトコルを使用する通信装置に係り、特に、その通信プロトコルの下位層にも情報損失補償機能を採用した通信装置、およびその通信制御方法に関する。
【０００２】
【従来の技術】
エラーが発生する確率の高い、無線伝送路等の不安定な回線を介して、情報を伝送する場合、回線エラーによる情報損失の補償を目的として、リンク層のプロトコルに、情報の再送やエラー訂正等の機能を持たせることが、一般的である。
【０００３】
【発明が解決しようとする課題】
情報損失補償機能を採用したリンク層では、情報損失を補償するために情報を再送すると、その時だけ情報の伝送遅延が大幅に増大してしまう。また、リンク層が用いるエラー訂正のための冗長度を変化させることによっても、情報の伝送遅延が変動する。このため、上位層プロトコルとしてたとえば、情報損失補償機能を持つＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いた場合、リンク層がもたらす伝送遅延の変動によって、ＴＣＰプロトコルのタイムアウト再送が発生する可能性があることが知られている。一方、多くの場合、リンク層によって情報損失のほとんどを補償できるので、ＴＣＰによる再送は実際には不要であり、また再送を行なうことで、回線容量の無駄使いを招くことにもなる。
【０００４】
上記のような現象は、比較的近い値のＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ、ラウンド・トリップ時間）を持つ複数のＴＣＰコネクションが、情報損失の補償機能を持つ同じ回線を共有する場合に、顕著になる。たとえば、同時に複数のＴＣＰコネクションを設定することが一般的である、Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ（登録商標）や、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）といったＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）ブラウザを利用する場合である。ＴＣＰはウィンドウ・サイズを変化させることによってフロー制御を行なっており、ＴＣＰ送信端末は、ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅ、肯定応答）を受信すると、そのＡＣＫ受信によって新たに送信可能になったパケットを直ちに送信する。このため、特定のＴＣＰコネクションのパケットの連続的な送信の間に、他のパケットの送信が割り込める可能性は小さくなる。したがって、同一のＴＣＰコネクションのパケットは、固まって送信される傾向にある。
【０００５】
たとえば、ＴＣＰコネクション（「ＴＣＰコネクションａ」と呼ぶ）のパケットの情報を含むリンク層のフレームが、回線エラーによって失われた場合、リンク層は、ＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）等のエラー訂正の冗長度を上げて情報を再送する。このため、その時だけ伝送遅延が大幅に増大する。さらに、回線の状態が回復するまでの間、引き続くフレームも同じエラー訂正の冗長度で送信されると、回線の実質的な帯域が小さくなり、伝送遅延が一層増大する。ＴＣＰ送信端末は、ＴＣＰコネクションａのＡＣＫを比較的速やかに受信できるので、タイムアウトを発生させずに、ＴＣＰコネクションａのタイムアウト値を次第に大きくして、この状態に対応できる可能性が高い。
【０００６】
しかしながら、ＴＣＰコネクションａによって比較的長い期間、回線が占有されているため、ＴＣＰ送信端末は、ＴＣＰコネクションａ以外の他のＴＣＰコネクションのＡＣＫをしばらく受信できない。このため、これら他のＴＣＰコネクションはタイムアウト再送を起こし易くなる。
【０００７】
このことは、以下のバーストエラー条件が重なることで、より顕著になる。なお、上述した、エラー発生時にエラー訂正の冗長度を増大させるリンク層は、以下のバーストエラー条件に対応するものである。
【０００８】
無線回線のようにエラーがバースト的に発生する回線の場合、ＴＣＰの無駄なタイムアウト再送が発生し易くなる。すなわち、バーストエラーの場合、エラーが生じない比較的長い期間では、伝送遅延が小さいので、ＴＣＰの送信端末が観測するＲＴＴに応じて適応的に設定されるＴＣＰのタイムアウト時間も小さな値に落ち着き、次第にタイムアウトが発生し易い状態となる。バースト的なエラーが発生すると、伝送遅延が突然大きくなるため、ＴＣＰのタイムアウト時間の適応的な制御が間に合わず、タイムアウト再送が起こる可能性が高くなる。
【０００９】
本発明は、上記の如き従来の問題点を解決するための成されたものであり、その目的は、下位層にも情報損失補償機能を採用した、情報損失補償機能を持った通信プロトコルを利用して通信する場合に、下位層の情報損失補償機能によって伝送遅延が増大しても、上位層による無用な情報損失補償機能の実行を抑制することができる通信装置、中継装置、および、その通信制御方法を提供することにある。
【００１０】
【課題を解決するための手段】
上記目的を達成するために、本発明は、他の通信装置と接続するインターフェースを有し、そのインターフェースを介して他の通信装置からの複数のパケットを送受信する通信装置において、他の通信装置に送信すべき複数のパケットを蓄積するパケット蓄積手段と、そのパケット蓄積手段に蓄積された複数のパケットそれぞれが属するトランスポート層コネクションを識別するコネクション識別手段と、そのネクション識別手段の識別結果を用いて、トランスポート層コネクションそれぞれの送信状況を管理する送信状況管理手段と、その送信状況管理手段により管理された送信状況に基づいて、パケット蓄積手段に蓄積された複数のパケットの送信順序を、リンク層にて、制御するパケット送信順序制御手段と、から構成された通信装置であることを第１の特徴とする。
【００１１】
この第１の発明によれば、送信パケット蓄積手段に、送信要求順に蓄積されたパケットを、同一コネクションに属するパケットが連続して送信されないように、その送信順序を変更することが可能となる。すなわち、異なるコネクションに属するパケットが順に送信することが可能となる。このため、タイムアウト再送等、上位層による無用な情報損失補償機能の実行が抑制される。
【００１２】
本発明の第２の特徴は、上記の第１の特徴で述べた通信装置によって実現される通信制御方法に係り、他の通信装置に送信すべき複数のパケットを蓄積する工程と、その蓄積された複数のパケットが属するそれぞれのトランスポート層コネクションを識別する工程と、その識別結果を用いて、トランスポート層コネクションそれぞれの送信状況を管理し、その管理された送信状況に基づいて、蓄積された複数のパケットの送信順序を、リンク層にて、制御する工程と、を含む通信制御方法であることである。
【００１３】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態について詳細に説明する。以下の図面の記載において、同一または類似の部分には同一または類似の符号を付している。
【００１４】
（第１の実施の形態）
図１は、本発明の第１の実施の形態に係るネットワーク・システムの構成を示すブロック図である。この第１の実施の形態に係るネットワーク・システムにおいて、端末１０と無線基地局１２とは、ＩＰパケットの配送機能を持つネットワーク１４を介して、接続されている。無線基地局１２は、無線回線１６によって、無線端末１８を収容する。そして、端末１０と無線端末１８は、ネットワーク１４、無線基地局１２および無線回線１６を介して、ＩＰパケットを交換する。以下では、説明の簡単化を図るため、端末１０から無線端末１８に対して、ＴＣＰによる情報送信を行なうものとする。
【００１５】
図２は、通信機能に着目した、図１の無線端末１８のプロトコル構成を示す図である。無線端末１８は、通信アプリケーション１８１と、ＴＣＰ層１８２と、ＩＰ層１８３と、リンク層１８４と、無線物理層１８５と、で構成される。
【００１６】
また、図３は、通信機能に着目した、図１の無線基地局１２のプロトコル構成を示す図である。無線基地局１２は、ＩＰ層１２１と、リンク層１２２と、無線物理層１２３と、有線物理層１２４と、で構成される。ＩＰ層１２１は、ＩＰパケットのルーティング機能を含んでいる。ここで、無線物理層１２３にはリンク層１２２が存在するが、有線物理層１２４に対応するリンク層は存在しない。これは、再送やリンク状態に応じた適応的なエラー訂正等、回線状態に依存して伝送遅延が変換する要因が、有線側、すなわちネットワーク１４側にないことを示している。もちろん、一般には、有線側にもリンク層が存在しても良い。
【００１７】
図２（無線端末１８）のリンク層１８４と図３（無線基地局１２）のリンク層１２２とは対向して、無線回線１６を介した情報の送受信を行なう。そして、主として、無線回線１６において生じる無線エラーによって生じる情報損失を、エラー訂正や再送等の手段によって補償する機能を実現する。
【００１８】
また、本発明の第１の実施の形態では、図２のリンク層１８４と図３のリンク層１２２との間の１つのリンク層コネクションに、すべてのＴＣＰ／ＩＰパケットが多重化されることを仮定する。つまり、リンク層コネクションの設定解放は、ＴＣＰコネクションの設定解放とは無関係で良く、通常は無線端末１８が無線基地局１２と通信を開始した際に設定され、通信を終了する際に解放される。本発明では、リンク層でＴＣＰコネクションを識別する必要はあるが、リンク層コネクション設定のためのシグナリング（コネクション設定制御）情報等のオーバヘッドが増えることはない。ＵＤＰ／ＩＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）等の他の種類のパケットは、このリンク層コネクションに多重化されても良いし、別リンク層コネクションによって伝送されても良い。
【００１９】
図４は、図２のリンク層１８４および図３のリンク層１２２それぞれの機能ブロック図である。図４では、上位層２０が、図２のＩＰ層１８３および図３のＩＰ層１２１それぞれに相当し、無線回線インタフェース４４が、図２の無線物理層１８５および図３の無線物理層１２３に相当する。以下では、必要に応じて、図２の無線端末１８のリンク層１８４の機能であれば、「＊＊＊＊＊機能（Ｍ）」と呼び、図３の無線基地局１２のリンク層１２２の機能であれば、「＊＊＊＊＊機能（Ｂ）」と呼ぶこととする。たとえば図４の送信パケット蓄積機能２２は、図２の無線端末１８のリンク層１８４の機能であれば、「送信パケット蓄積機能（Ｍ）」と呼ばれ、図３の無線基地局１２のリンク層１２２の機能であれば、「送信パケット蓄積機能（Ｂ）」と呼ばれることになる。
【００２０】
次に、図４、図５および図６を参照して、本発明の第１の実施の形態に係る通信制御方法について説明する。図５は、本発明の第１の実施の形態に係る通信制御方法のうち、図３の無線基地局１２のリンク層１２２の処理手順を示すフローチャートである。また、図６は、本発明の第１の実施の形態に係る通信制御方法のうち、図２の無線端末１８のリンク層１８４の処理手順を示すフローチャートである。上述したように、ここでは、端末１０から、無線基地局１２を介して、無線端末１８に、ＴＣＰ／ＩＰによって情報を送信することを例に採っている。このため、図５は、送信側リンク層の処理手順であり、図６は、受信側リンク層の処理手順となる。図５および図６では、説明の煩雑さを避けるため、同時に１つのＩＰパケットを送受信し、そのＩＰパケットの送受信の処理が終了後、次のＩＰパケットの送受信処理を開始することを仮定している。これは、リンク層の再送アルゴリズムが、ＳＷ（Ｓｔｏｐ ａｎｄ Ｗａｉｔ）である場合に相当する。つまり、あるリンク層フレームの送受信が完了してから、次のリンク層フレームの送受信処理を行なうので、リンク層フレームが複数のＩＰパケットの情報を含まない限り（本第１の実施の形態の仮定）、ＩＰパケットも１つずつ送受信処理されることになる。再送アルゴリズムが、ＧＢＮ（Ｇｏ Ｂａｃｋ Ｎ）またはＳＲ（Ｓｅｌｅｃｔｉｖｅ Ｒｅｐｅａｔ）等の場合には、複数のＩＰパケットの送受信処理が同時に行なわれることがあるが、本発明は、これらの場合にも、もちろん有効である。
【００２１】
（Ａ）無線基地局１２のリンク層１２２（送信側リンク層）
（１）前ＩＰパケットの処理終了後、送信側リンク層１２２の上位層２０がさらに送信するべきＩＰパケットを持っていれば、送信パケット蓄積機能（Ｂ）２２は、そのＩＰパケットを、キュー（待ち行列）の最後に追加する（図５のＳ１０１）。ＩＰパケットは、同時には１つしか送受信処理されないので、直前のＩＰパケットの送信処理終了後では、キューに連なるＩＰパケットは、すべて未送信のＩＰパケットとなる。なお、複数のＩＰパケットを同時に送受信処理する、より一般的な場合、送信中ＩＰパケットがキューの先頭に０個以上連続して連なり、続いて１個以上の未送信ＩＰパケットが連なる、順番となる。また、ここでの「送信中」とは、ＩＰパケットを構成する情報の少なくとも一部がリンク層フレームとして、一度は送信され、かつすべての情報の送信は未完了である状態を意味する。
【００２２】
（２）送信パケット選択機能（Ｂ）３２は、次に送信する候補に挙げるＩＰパケットをキューに連なるＩＰパケットから選択する（図５のステップＳ１０２）。ここで、ＩＰパケットがＴＣＰ／ＩＰパケットであれば、図７に示すＩＰヘッダ、および図８に示すＴＣＰヘッダを持っている。そして、図７の「Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ」４８、 「Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ」５０、図８の「 Ｓｏｕｒｃｅ Ｐｏｒｔ」５２、「Ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ」５４、の４つの組によって、各ＴＣＰコネクションを一意に識別することができる。以後は、簡略のため、各ＴＣＰコネクションそれぞれを、コネクション＃１、コネクション＃２、．．．と呼ぶ。この時点で、ＴＣＰコネクション＃１および＃２の未送信パケットが、この順でキューに連なっているとする。この時点におけるＴＣＰ送信管理テーブルの内容を図９に示す。
【００２３】
送信パケット選択機能（Ｂ）３２は、識別機能（Ｂ）２４によって、未送信パケットのＴＣＰコネクション番号をキューの先頭から順に調べる。最初の未送信パケットは、ＴＣＰコネクション＃１であり、図９のＴＣＰ送信管理テーブルによれば、最近送信されたことがある。したがって、送信パケット選択機能３２は、ＴＣＰコネクション＃１のパケットを、次の送信パケット候補から外す。
【００２４】
次の未送信のパケットは、ＴＣＰコネクション＃２であり、図９のＴＣＰ送信管理テーブルによれば、最近送信されていない。したがって、送信パケット選択機能（Ｂ）３２は、ＴＣＰコネクション＃２のパケットを、次に送信するパケットの候補とする。そして、このＴＣＰコネクション＃２の未送信パケットは、キューの先頭に挿入される。つまり、キュー内における、ＴＣＰコネクション＃１の未送信パケットとＴＣＰコネクション＃２の未送信パケットの順番が逆転する。
【００２５】
（３）フレーム化機能（Ｂ）３０は、ＴＣＰコネクション＃２のパケット情報のフレーム化を行なう（図５のステップＳ１０３）。ここで、リンク層１２２，１８４のフレーム構造について説明する。図１０に、リンク層１２２，１８４のフレーム構造を示す。図１０のフレーム構造において、「コネクション番号」５６は、リンク層１２２，１８４のコネクションを識別するためのものである。フレーム化機能３０は、ＴＣＰ／ＩＰパケットを、すべて同じリンク層コネクションに多重化する。
【００２６】
フレーム化機能３０は、再送制御等のため、各パケットにリンク層１２２，１８４の「シーケンス番号」５８を付与する。なお、リンク層１２２，１８４の再送制御がＳＷならばシーケンス番号は不要である。一方、ＧＢＮやＳＲ（Ｓｅｌｅｃｔｉｖｅ Ｒｅｐｅａｔ）等の場合には、もちろん必要である。フレーム長はモードによって可変であり、同じパケットの情報が最初の送信と次の再送では別のフレームになることもある。このため、「シーケンス番号」５８はフレーム番号ではなく、リンク層１２２，１８４がこれまでに送信した情報量（ビットまたはバイト等の単位）の適当なｍｏｄである。
【００２７】
「ＡＣＫ／ＮＡＣＫ番号」６０は、送達確認あるいはエラー確認の対象となる、受信されたリンク層フレームのシーケンス番号である。そして、「ＡＣＫまたはＮＡＣＫ表示」６２は、「ＡＣＫ／ＮＡＣＫ番号」６０によって示された番号が、ＡＣＫ番号であるのか、あるいはＮＡＣＫ番号であるのかを示す。フレーム化機能３０は、送達確認送信機能４０から得られる情報によって、「ＡＣＫ／ＮＡＣＫ番号」６０と「ＡＣＫまたはＮＡＣＫ表示」６２を適当な値に設定する。
【００２８】
「モード情報」６４は、リンク層のフレーム化のモードを示す。ここでは、次の２つのモードが存在すると仮定する。（ａ）第１のモードは、無線回線１６の状態が良いと想定される時に使われるクリアモードである。これはペイロードにはエラー訂正を掛けない、つまりペイロードエラー訂正情報のオーバヘッドがないモードである。（ｂ）他のモードは、無線回線１６の状態が悪いと想定される時に使われるノイジーモードである。これは、ペイロードにエラー訂正を掛ける、つまりペイロードエラー訂正情報の冗長度を加えるモードである。フレーム化機能３０は、モード決定機能２８から得られる情報によって、「モード情報」６４の値を設定する。
【００２９】
「ペイロードデータ長」６８は、このフレームの「ペイロード」に納められる情報の長さを示す。「ペイロードエラー訂正情報」の長さは含まない、正味のデータ長である。
【００３０】
「ヘッダエラー訂正情報」７０は、「リンク層ヘッダ」７２を回線エラーから保護するために与えられる冗長度情報である。
【００３１】
図１１に、リンク層フレームとＴＣＰ／ＩＰパケットの関係を示す。図１１に示すように、一般に、１つのＴＣＰ／ＩＰパケットは、複数のリンク層フレームに分割される。ここで、フレーム化の対象となるのは、キューの先頭にあるＴＣＰコネクション＃２の未送信パケットである。フレーム化機能３０は、このパケットの情報の一部に、その時のモードに応じた「ペイロードエラー訂正情報」を加えて、「リンク層ペイロード」７４を構成する。ここでは、「モード情報」６４に設定されたモードは、クリアモードであるとする。
【００３２】
なお、複数のパケットの送受信処理を並列して行なう一般の場合、図５のステップＳ２０２で選択されたパケットが、フレーム化の対象になるとは限らない。送信中のパケットがある時には、その情報がフレーム化の対象となる場合がある。
【００３３】
（４）フレーム送信機能（Ｂ）３８は、このように形成されたフレームを送信するよう、無線回線インタフェース（Ｂ）４４に指示する。同時に、図１２に示すように、ＴＣＰ送信管理テーブルに、ＴＣＰコネクション＃２を、最近送信したものとしてマークする。無線回線インタフェース（Ｂ）４４は、無線回線１６によって、形成されたフレーム（「フレームａ」と呼ぶ）を送信する（図５のステップＳ１０４）。
【００３４】
ここで、図５の無線基地局１２のリンク層１２２（送信側リンク層）の処理から、図６の無線端末１８のリンク層１８４（受信側リンク層）の処理に移行する。
【００３５】
（Ｂ）無線端末１８のリンク層１８４（受信側リンク層）
（５）無線回線インタフェース（Ｍ）４４は、無線回線１６から受信したフレームａをフレーム受信機能（Ｍ）４２に渡す（図６のステップＳ２０１）。
【００３６】
（６）フレーム受信機能（Ｍ）４２は、最初に、フレームａの「ヘッダエラー訂正情報」７０を利用して、訂正が必要であれば、「リンク層ヘッダ」７２のエラーを訂正し、ヘッダ情報を読みとれる状態にする。以下では、ほとんどの無線エラーに対してヘッダ情報は十分な保護がされており、常に正しいエラー訂正が可能であると仮定する。「モード情報」６４によって「ペイロードデータ」のエラー訂正方法を決定し、この知識と「ペイロードエラー訂正情報」７０を利用して、「ペイロードデータ」を復元する（図６のステップＳ２０２）。
【００３７】
（７）モードがクリアモードであったとし、かつ無線エラーが発生したのでエラー訂正ができず、ペイロードが正しく復元できなかったとする。ただし、エラー検出は常に可能であると仮定している。そして、フレームａが訂正不可能なので（図６のステップＳ２０３ＮＯ）、送達確認送信機能（Ｍ）４０は、エラー確認であるＮＡＣＫ（否定応答）をフレームヘッダに入れて送信するようにフレーム化機能（Ｍ）３０に指示する。フレーム化機能（Ｍ）３０が作成するＮＡＣＫの、図１０の「リンク層フレーム」７６は、「リンク層ヘッダ」７２のみであって良い。ただし、送信するべきデータがあれば、エラー確認（ＮＡＣＫ）は、そのデータにピギーバッキング（ｐｉｇｇｙｂａｃｋｉｎｇ、おんぶ）されるので、「リンク層ペイロード」７４が付く。ＮＡＣＫの「コネクション番号」５６は、その訂正不可能であったフレームａの「コネクション番号」５６に等しくなる。また、「ＡＣＫ／ＮＡＣＫ番号」６０には、フレームａの「シーケンス番号」５８が与えられ、「ＡＣＫまたはＮＡＣＫ表示」６２には、ＮＡＣＫを示す値が与えられる。「エラー情報」６６は、訂正可能であれば、訂正されたビット数等の誤りの程度を示す値が設定されるが、ここでは訂正不可能なので、その旨を示す値に設定される。「リンク層ヘッダ」７２の他のフィールドには、「リンク層ペイロード」７４の内容に適した値を与え、「ヘッダエラー訂正情報」７０を付加する。必要なら「ペイロード」も付けて、ＮＡＣＫフレーム（「フレームｂ」と呼ぶ）を無線回線インタフェース（Ｍ）４４によって送信する（図６のステップＳ２０４）。そして、今回受信された、訂正不可能であったフレームａは廃棄される（図６のステップＳ２０５）。
【００３８】
ここで、再び、図６の無線端末１８のリンク層１８４（受信側リンク層）の処理から、図５の無線基地局１２のリンク層１２２（送信側リンク層）の処理に移る。
【００３９】
（Ｃ）無線基地局１２のリンク層１２２（送信側リンク層）
（８）ＮＡＣＫフレームｂは、無線基地局１２のフレーム受信機能（Ｂ）４２によって受信され、エラー確認に関する情報が送達確認受信機能（Ｂ）３６に渡される（図５のステップＳ１０５）。送達確認受信機能（Ｂ）３６は、モード決定機能（Ｂ）２８に、モードを決定するように指示する。モード決定機能（Ｂ）２８は、「エラー情報」６６の値が、エラー訂正不要であったことを示している時にはクリアモード、エラー訂正必要あるいはエラー訂正不可能であったことを示している時にはノイジーモードに決定する。したがって、ここでは、クリアモードからノイジーモードに変化することになる（図５のステップＳ１０６）。
【００４０】
（９）ＮＡＣＫを受信したので（図５のステップＳ１０７ＹＥＳ）、訂正不可能であったフレームａを再送する。既に述べたのと同様の手順でパケット情報をフレーム化する（図５のステップＳ１０３）。ただし、前回はクリアモードでフレーム化したが、今回はノイジーモードでフレーム化を行なう。エラー耐性を高めるためには、「ペイロードデータ長」はクリアモードの場合より小さくする方が良い。したがって、パケットをフレームに切り分ける境界が変化する。また、図１０の「ペイロードエラー訂正情報」も付加される。作られたフレームａ′を既に述べたのと同様に送信する（図５のステップＳ１０４）。
【００４１】
ここで、図５の無線基地局１２のリンク層１２２（送信側リンク層）の処理から、図６の無線端末１８のリンク層１８４（受信側リンク層）の処理に移行する。
【００４２】
（Ｄ）無線端末１８のリンク層１８４（受信側リンク層）
（１０）無線端末１８は、再送されたフレームａ′を前述と同様に受信し（図６のステップＳ２０１）、さらに無線端末１８のフレーム受信機能（Ｍ）４２がエラー訂正を行なう（図６のステップＳ２０２）。今回は、エラー訂正が可能であったとする（図６のステップＳ２０３ＹＥＳ）。
【００４３】
（１１）送達確認送信機能（Ｍ）４０は、送達確認（ＡＣＫ）をフレームヘッダに入れて送信するようにフレーム化機能（Ｍ）３０に指示する。フレーム化機能（Ｍ）３０が作成するＡＣＫの、図１０の「リンク層フレーム」７６は、「リンク層ヘッダ」７２のみであっても、ｐｉｇｇｙｂａｃｋされても良い。ＡＣＫフレームの「コネクション番号」５６は、受信されたフレームａ′の「コネクション番号」５６に等しい。「ＡＣＫ／ＮＡＣＫ番号」６０には、受信されたフレームａ′の「シーケンス番号」５８が与えられ、「ＡＣＫまたはＮＡＣＫ表示」６２には、ＡＣＫを示す値が与えられる。また、「エラー情報」６６には、訂正されたビット数を示す値が設定される。「リンク層ヘッダ」７２の他のフィールドに「リンク層ペイロード」７４の内容に適した値を与え、「ヘッダエラー訂正情報」を付加する。必要なら「ペイロード」も付けて、ＡＣＫフレーム（「フレームｂ」と呼ぶ）を無線回線インタフェース（Ｍ）４４によって送信する（図６のステップＳ２０６）。受信されたフレームａ′は蓄積される（図６のステップＳ２０７）。なお、フレームａ′だけでは、元々のパケットが完成しないとする（図６のステップＳ２０８ＮＯ）。
【００４４】
ここで、再び、図６の無線端末１８のリンク層１８４（受信側リンク層）の処理から、図５の無線基地局１２のリンク層１２２（送信側リンク層）の処理に移る。
【００４５】
（Ｅ）無線基地局１２のリンク層１２２（送信側リンク層）
（１２）ＡＣＫフレームｂは、無線基地局１２のフレーム受信機能（Ｂ）４２によって受信され、送達確認に関する情報が、送達確認受信機能（Ｂ）３６に渡される（図５のステップＳ１０５）。
【００４６】
（１３）送達確認受信機能（Ｂ）３６は、モード決定機能（Ｂ）２８に、モードを決定するように指示する。モード決定機能（Ｂ）２８は、ＡＣＫフレームｂの「エラー情報」６６の値が、エラー訂正必要であったことを示しているので、ノイジーモードとなるように、モードを決定する。したがって、ここでは、モードは変化しない（図５のステップＳ１０６）。
【００４７】
（１４）ＡＣＫを受信したので（図５のステップＳ１０７ＹＥＳ）、新しい情報をフレーム化して送信する。フレーム化の方法は、既に述べたのと同様である（図５のステップＳ１０３）。作られたフレームを既に述べたのと同様に送信する（図５のステップＳ１０４）。
【００４８】
（１５）上記の（１）〜（１４）によるフレームの交換を無線基地局１２と無線端末１８との間で繰り返す。そして、受信側である無線端末１８で、受信されたフレームによって、１つのパケットを完成したとする（図６のステップＳ２０８ＹＥＳ）。無線端末１８のパケット組立機能（Ｍ）２６は、これまで受信し、蓄積していたフレームから、パケットを組み立てて、完成したパケットを上位層２０に渡す。さらに、このパケットを構成していたフレームを、受信フレーム蓄積機能（Ｍ）３４から削除する（図６のステップＳ２０９）。
【００４９】
（１６）パケットを完成したフレームに対するＡＣＫを無線基地局１２が受信すると、これまでと同様の手順の他に、送達確認受信機能（Ｂ）３６が送信パケット蓄積機能（Ｂ）２２に対し、送信が完了したパケットを削除するように指示する（図５のステップＳ１０９）。これでＴＣＰコネクション＃２のＴＣＰ／ＩＰパケットの送受信処理が完了する。
【００５０】
（１７）無線基地局１２の送信パケット蓄積機能（Ｂ）２２が次のパケットをキューに追加しようとするが、上位層２０が新たなパケットの送信を要求してこなかったとする（図５のステップＳ１０１）。この場合、ＴＣＰコネクション＃１のＴＣＰ／ＩＰパケットしかない状態で、送信パケット選択機能３２が、次に送信する候補のパケットを選ぶことになる。図１２に示したＴＣＰ送信管理テーブルは、ＴＣＰコネクション＃１のパケットが、最近送信されたことを示している。そして、最近送信されたことのないＴＣＰコネクションのＴＣＰ／ＩＰパケットがキューの中に存在せず、次の送信候補が選択できない。この場合、送信パケット選択機能（Ｂ）３２は、ＴＣＰ送信管理テーブルをリセットして、図１３の状態にする。そして、ＴＣＰコネクション＃１のＴＣＰ／ＩＰパケットを次の送信候補として選択する。
【００５１】
一方、上位層２０が、新たにＴＣＰコネクション＃２と＃３のＴＣＰ／ＩＰパケットの送信を要求してきたとする。これらは送信パケット蓄積機能２２によってキューに追加される（図５のステップＳ１０１）。ＴＣＰコネクション＃２のＴＣＰ／ＩＰパケットは、上記したように、最近送信されたので、送信パケット選択機能３２は、既に述べたのと同様の方法で、ＴＣＰコネクション＃３のＴＣＰ／ＩＰパケットを次の送信候補として選択し、キューの先頭に移動することになる。
【００５２】
以上説明したように、本発明の第１の実施の形態によれば、パケット蓄積キューを単純なＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）として動作させた場合と比較して、同一のＴＣＰコネクションに属するパケットが連続的にフレーム化されて送信される可能性を減少させることができる。
【００５３】
特に、本発明の第１の実施の形態は、キュー長が長くなった場合に有効である。すなわち、無線エラーによって再送が発生した場合や、無線エラーからデータを保護するために、ペイロードエラー訂正情報の与える冗長度を増やすことで、無線回線１６の有効帯域が一時的に減少して、無縁回線１６がボトルネックになると、キュー長が長くなる。まさにこのような時に、ＴＣＰ送信端末である端末１０から見たＲＴＴが急増し、ＴＣＰのタイムアウト再送が発生し易くなる。
【００５４】
本発明の第１の実施の形態は、単一ないしは少数のＴＣＰコネクションデータ送信のために無線回線１６を連続的に占有し、他のＴＣＰコネクションのＡＣＫが長期間返らなくなる傾向を回避することができる。それにより、ＴＣＰコネクションのＲＴＴの増大を抑制し、各ＴＣＰコネクションに均等に無線回線１６を利用させることができる。このため、ＴＣＰによるタイムアウト再送するＴＣＰコネクション数を減少、あるいはなくすことが可能となる。
【００５５】
このように、本発明の第１の実施の形態によれば、リンク層が、同一のＴＣＰコネクションに属するパケットがなるべく連続して送出されないように、パケット送信順序を定めることができる。このため、無線回線状態が悪くなり、回線の実効帯域が減少して伝送遅延が急増する場合にも、各ＴＣＰコネクションのＴＣＰ送信端末が観測するＲＴＴの増加を最小限に押さえることが可能となり、ＴＣＰの不要なタイムアウト再送を制御することができる。これにより、無線回線の帯域が有効に利用できる。
【００５６】
本発明の第１の実施の形態は、図１に示したネットワーク・システム構成以外にも適用可能である。図１４に、本発明の第１の実施の形態に係る別のネットワーク・システムの構成を示す。図１４において、第１の端末８０と第２の端末８６とは、第１のネットワーク８１、第１の無線中継装置８２、第２の無線中継装置８４、および第２のネットワーク８５を介して、ＩＰパケットを交換する。ここで、第１および第２のネットワーク８１，８５それぞれは、ＩＰパケットの配送機能を有している。ＩＰパケットのルーティング機能（ＩＰルータ機能）を備えた、第１および第２の無線中継装置８２，８４のプロトコル構成は、図３に示した、無線基地局１２のプロトコル構成に準ずる。また、リンク層の機能ブロックについても、図４に示した機能ブロックに準ずる。
【００５７】
図１５は、ブリッジとして機能する場合における、第１および第１の無線中継装置８２，８４のプロトコル構成を示す図である。ここで、図３のＩＰ層１２１は、ＩＰアドレスとＩＰルーティングテーブルの情報に基づいてＩＰパケットのルーティングを行なうのに対し、図１５のブリッジ機能８２１は、単に一方から受信したフレームを他方に中継するだけである。ただし、ブリッジ機能８２１は、リンク層アドレス乃至ＭＡＣアドレスによって、中継するべきフレームと中継するべきでないフレームを区別し、中継するべきでないフレームを廃棄する、といった機能を持つ場合もある。図１５のリンク層８２２は、図４のリンク層の機能ブロックにおいて、上位層２０をブリッジ機能８２１に置き換える点以外は、図４に準ずる。
【００５８】
このように構成されたネットワークにおいて、第１の端末８０から第２の端末８６に対して、ＴＣＰによる情報送信を行なうことができる。この場合のリンク層の動作手順は、第１の無線中継装置８２側が図５に示した送信側の処理手順、第２の無線中継装置８４側が図６に示した受信側の処理手順、に準ずる。
【００５９】
さらに、別のネットワーク・システムの構成を図１６に示す。このネットワーク・システムにおいては、第１の無線端末９０と第２の無線端末９２とが、無線回線９１によって直結されており、第１の無線端末９０と第２の無線端末９２とは、無線回線９１を介して、ＩＰパケットを交換する。第１および第２の無線端末９０，９２それぞれのプロトコル構成は、図２に示した、無線端末１０のプロトコル構成に準ずる。また、リンク層の機能ブロックについても、図４に示した機能ブロックに準ずる。
【００６０】
第１の無線端末９０から第２の無線端末９２に対して、ＴＣＰによる情報送信を行なうことができる。この場合のリンク層の動作手順は、第１の無線端末９０側が図５に示した送信側の処理手順、第２の無線端末９２側が図６に示した受信側の処理手順、に準ずる。
【００６１】
また、上記の実施の形態では、不安定な回線として無線の場合について説明したが、本発明はこれに限られるものではない。すなわち、有線の場合であっても、回線品質に応じたリンク層以下のレイヤ（物理層を含む）の適応的なエラー補償により、回線の実効帯域が変動する場合には、本発明の適用が有効である。
【００６２】
（第２の実施の形態）
次に、本発明の第２の実施の形態について説明する。上記の第１の実施の形態において、リンク層が無線エラーからデータを保護するために、再送を行なったり、エラー訂正情報の冗長度を増したりすると、一種の輻輳が発生する。一方で、ＴＣＰ送信端末は、パケット損失を輻輳の兆候と解釈し、ウインドウを小さくしてＡＣＫされずにネットワークに送出できるデータ量を減らすことで輻輳制御を行なう。
【００６３】
しかし、リンク層はパケットが損失しないように、無線エラーからデータを保護するため、ＴＣＰの輻輳制御はこの輻輳に対しては有効に機能しない。ＴＣＰのウインドウサイズが増え続けるので、パケットキューのサイズが十分に大きくてキュー溢れを防げるとしても、伝送遅延が非常に大きくなるという問題がある。
【００６４】
本発明の第２の実施の形態は、第１の実施の形態に係る、図２のリンク層１８４および図３のリンク層１２２に、所定の規則で上位層パケット（ＩＰパケット）に記しを付けるか、ＩＰパケットを廃棄することで、ＴＣＰの輻輳制御を有効に機能させる上位層輻輳制御機能４６を、さらに設けた例である。この上位層輻輳制御機能４６は、ＲＥＤ（Ｒａｎｄｏｍ Ｅａｒｌｙ Ｄｅｔｅｃｔｉｏｎ）等に代表される、初期段階の輻輳を検出する、いわゆるＡｃｔｉｖｅ Ｑｕｅｕｅ Ｍａｎａｇｅｍｅｎｔ機能に相当する。ただし、この第２の実施の形態では、一般的に行なわれるＩＰ層の機能としての実現ではなく、リンク層の機能として実現する。
【００６５】
ここで、ＩＰパケットを、適当な規則で廃棄する場合は、広く使われているＴＣＰ／ＩＰの実装がそのまま利用できる。一方、ＩＰパケットに記しを付けてＴＣＰの輻輳制御を機能させる場合、次に述べるＴＣＰ／ＩＰの仕様を用いる。すなわち、図７のＩＰヘッダのＴＯＳ（Ｔｙｐｅ ｏｆ Ｓｅｒｖｉｃｅ）フィールドの一部を、ＥＣＮ（Ｅｘｐｌｉｃｉｔ Ｃｏｎｇｅｓｔｉｏｎ Ｎｏｎｔｉｆｉｃａｔｉｏｎ）のために割り当てる。ＴＯＳの第６ビットがＥＣＴ（ＥＣＮ−Ｃａｐａｂｌｅ Ｔｒａｎｓｐｏｒｔ）ビットとなり、第７ビットがＣＥ（Ｃｏｎｇｅｓｔｉｏｎ Ｅｘｐｅｒｉｅｎｃｅｄ）ビットとなる。また、図８のＴＣＰヘッダのＲｅｓｅｒｖｅｄフィールドの第９ビットをＥＣＮ−Ｅｃｈｏビットに、第８ビットをＣＷＲ（Ｃｏｎｇｅｓｔｉｏｎ Ｗｉｎｄｏｗ Ｒｅｄｕｃｅｄ）ビットに割り当てる（ＩＥＴＦ ＲＦＣ２４８１）。
【００６６】
本発明の第２の実施の形態に係る上位層輻輳制御機能４６は、送信パケット蓄積機能２２のキュー長を調べ、かつローパスフィルタされた平均キュー長を計算する。平均キュー長がしきい値を超え、かつ、乱数の値が別のしきい値を越えた場合に、▲１▼ＥＣＴフラグが“１”であれば、ＴＣＰ／ＩＰパケットのＣＥフラグを“１”に設定する。一方、▲２▼ＥＣＴフラグが“０”であれば、ＴＣＰ／ＩＰパケットを廃棄する。▲１▼のＣＥビットが“１”に設定されるＴＣＰ／ＩＰパケット、および、▲２▼の廃棄されるＴＣＰ／ＩＰパケットは共に、未送信パケットのうちのいずれかを選ぶことにしておけば、リンク層の再送制御等に影響せず、実装が比較的容易になる。
【００６７】
そして、上記▲２▼のＥＣＴビットが“０”の場合、ＴＣＰ送信端末は、ＴＣＰ／ＩＰパケット損失を検出し、通常の方法で輻輳制御を行なう。一方、上記▲１▼のＥＣＴビットが“１”であることは、ＴＣＰ送信端末とＴＣＰ受信端末が、共に、ＥＣＮに対応したＴＣＰ層を持つことを示している。この場合、ＴＣＰ受信端末が、“１”のＣＥビットを持つＴＣＰ／ＩＰパケットを受信すると、ＴＣＰ送信端末からＣＷＲビットが“１”であるＴＣＰ／ＩＰパケットを受信するまでのすべてのＴＣＰ ＡＣＫのＥＣＮ−Ｅｃｈｏビットを“１”に設定する。ＴＣＰ送信端末は、ＥＣＮ−Ｅｃｈｏビットが“１”のＴＣＰ ＡＣＫを受信すると、あたかもパケット損失を検出したかのように輻輳制御を行ないウインドウサイズを小さくする。詳細な方法は記述しないが、１ＲＴＴ期間で輻輳に対して反応するのは１回を越えないように制限される。
【００６８】
このように、本発明の第２の実施の形態によれば、ＴＣＰの不要な輻輳制御の発生も抑制するので、無線回線状態が良くなり、回線の実効帯域が回復した際に、速やかに帯域を使い切ることが可能になる。また、これらの効果を得るために、既存のＴＣＰの実装を変更する必要もなく、容易にＴＣＰに実装することができる。
【００６９】
【発明の効果】
本発明によれば、下位層にも情報損失補償機能を採用した、情報損失補償機能を持った通信プロトコルを利用して通信する場合に、下位層の情報損失補償機能によって伝送遅延が増大しても、上位層による無用な情報損失補償機能の実行を抑制することができる通信装置、中継装置、および、その通信制御方法を実現できる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態に係る通信装置が適用されるネットワーク・システムの構成を示すブロック図である。
【図２】図１の無線端末１８に利用される通信プロトコルの構成を示すブロック図である。
【図３】図１の無線基地局１２に利用される通信プロトコルの構成を示すブロック図である。
【図４】図２のリンク層１８４および図３のリンク層１２２それぞれの機能ブロック図である。
【図５】本発明の第１の実施の形態に係る通信制御方法の処理手順のうち、図３の無線基地局１２のリンク層１２２の処理手順を示すフローチャートである。
【図６】本発明の第１の実施の形態に係る通信制御方法の処理手順のうち、図２の無線端末１８のリンク層１８４の処理手順を示すフローチャートである。
【図７】一般的なＴＣＰ／ＩＰパケットに付加されたＩＰヘッダの内容を説明する図である。
【図８】一般的なＴＣＰ／ＩＰパケットに付加されたＴＣＰヘッダの内容を説明する図である。
【図９】ＴＣＰ送信管理テーブルの内容を説明する図である。
【図１０】図２および図３のリンク層１２２，１８４のフレーム構造を示す図である。
【図１１】リンク層フレームとＴＣＰ／ＩＰパケットとの対応関係を示す図である。
【図１２】ＴＣＰ送信管理テーブルの内容を説明する図である。
【図１３】ＴＣＰ送信管理テーブルの内容を説明する図である。
【図１４】本発明の第１の実施の形態に係る中継装置が適用されるネットワーク・システムの構成を示すブロック図である。
【図１５】図１４の無線中継装置８２，８４に利用される通信プロトコルの構成を示すブロック図である。
【図１６】本発明の第１の実施の形態に係る無線端末が適用されるネットワーク・システムの構成を示すブロック図である。
【符号の説明】
１０ 端末（ＴＣＰ送信端末）
１２ 無線基地局
１４ ネットワーク
１６，８３，９１ 無線回線
１８ 無線端末（ＴＣＰ受信端末）
２０ 上位層
２２ 送信パケット蓄積機能
２４ 識別機能
２６ パケット組立機能
２８ モード決定機能
３０ フレーム化機能
３２ 送信パケット選択機能
３４ 受信フレーム蓄積機能
３６ 送信確認受信機能
３８ フレーム送信機能
４０ 送信確認送信機能
４２ フレーム受信機能
４４ 無線回線インターフェース
４６ 上位層輻輳制御機能
４８ Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ
５０ Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ
５２ Ｓｏｕｒｃｅ Ｐｏｒｔ
５４ Ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ
５６ コネクション番号
５８ シーケンス番号
６０ ＡＣＫ／ＮＡＣＫ番号
６２ ＡＣＫまたはＮＡＣＫ表示
６４ モード情報
６６ エラー情報
６８ ペイロードデータ長
７０ ヘッダエラー訂正情報
７２ リンク層ヘッダ
７４ リンク層ペイロード
７６ リンク層フレーム
８０ 第１の端末
８１ 第１のネットワーク
８２ 第１の無線中継装置
８４ 第２の無線中継装置
８５ 第２のネットワーク
８６ 第２の端末
９０ 第１の無線端末
９２ 第２の無線端末
８２１ ブリッジ機能
１２１，１８３ ＩＰ層
１２２，１８４，８２２ リンク層
１２３，１８５，８２３ 無線物理層
１２４，８２４ 有線物理層
１８１ 通信アプリケーション
１８２ ＴＣＰ層
【発明の属する技術分野】
本発明は、情報損失補償機能を持った通信プロトコルを使用する通信装置に係り、特に、その通信プロトコルの下位層にも情報損失補償機能を採用した通信装置、およびその通信制御方法に関する。
【０００２】
【従来の技術】
エラーが発生する確率の高い、無線伝送路等の不安定な回線を介して、情報を伝送する場合、回線エラーによる情報損失の補償を目的として、リンク層のプロトコルに、情報の再送やエラー訂正等の機能を持たせることが、一般的である。
【０００３】
【発明が解決しようとする課題】
情報損失補償機能を採用したリンク層では、情報損失を補償するために情報を再送すると、その時だけ情報の伝送遅延が大幅に増大してしまう。また、リンク層が用いるエラー訂正のための冗長度を変化させることによっても、情報の伝送遅延が変動する。このため、上位層プロトコルとしてたとえば、情報損失補償機能を持つＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）を用いた場合、リンク層がもたらす伝送遅延の変動によって、ＴＣＰプロトコルのタイムアウト再送が発生する可能性があることが知られている。一方、多くの場合、リンク層によって情報損失のほとんどを補償できるので、ＴＣＰによる再送は実際には不要であり、また再送を行なうことで、回線容量の無駄使いを招くことにもなる。
【０００４】
上記のような現象は、比較的近い値のＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ、ラウンド・トリップ時間）を持つ複数のＴＣＰコネクションが、情報損失の補償機能を持つ同じ回線を共有する場合に、顕著になる。たとえば、同時に複数のＴＣＰコネクションを設定することが一般的である、Ｎｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ（登録商標）や、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）といったＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）ブラウザを利用する場合である。ＴＣＰはウィンドウ・サイズを変化させることによってフロー制御を行なっており、ＴＣＰ送信端末は、ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅ、肯定応答）を受信すると、そのＡＣＫ受信によって新たに送信可能になったパケットを直ちに送信する。このため、特定のＴＣＰコネクションのパケットの連続的な送信の間に、他のパケットの送信が割り込める可能性は小さくなる。したがって、同一のＴＣＰコネクションのパケットは、固まって送信される傾向にある。
【０００５】
たとえば、ＴＣＰコネクション（「ＴＣＰコネクションａ」と呼ぶ）のパケットの情報を含むリンク層のフレームが、回線エラーによって失われた場合、リンク層は、ＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）等のエラー訂正の冗長度を上げて情報を再送する。このため、その時だけ伝送遅延が大幅に増大する。さらに、回線の状態が回復するまでの間、引き続くフレームも同じエラー訂正の冗長度で送信されると、回線の実質的な帯域が小さくなり、伝送遅延が一層増大する。ＴＣＰ送信端末は、ＴＣＰコネクションａのＡＣＫを比較的速やかに受信できるので、タイムアウトを発生させずに、ＴＣＰコネクションａのタイムアウト値を次第に大きくして、この状態に対応できる可能性が高い。
【０００６】
しかしながら、ＴＣＰコネクションａによって比較的長い期間、回線が占有されているため、ＴＣＰ送信端末は、ＴＣＰコネクションａ以外の他のＴＣＰコネクションのＡＣＫをしばらく受信できない。このため、これら他のＴＣＰコネクションはタイムアウト再送を起こし易くなる。
【０００７】
このことは、以下のバーストエラー条件が重なることで、より顕著になる。なお、上述した、エラー発生時にエラー訂正の冗長度を増大させるリンク層は、以下のバーストエラー条件に対応するものである。
【０００８】
無線回線のようにエラーがバースト的に発生する回線の場合、ＴＣＰの無駄なタイムアウト再送が発生し易くなる。すなわち、バーストエラーの場合、エラーが生じない比較的長い期間では、伝送遅延が小さいので、ＴＣＰの送信端末が観測するＲＴＴに応じて適応的に設定されるＴＣＰのタイムアウト時間も小さな値に落ち着き、次第にタイムアウトが発生し易い状態となる。バースト的なエラーが発生すると、伝送遅延が突然大きくなるため、ＴＣＰのタイムアウト時間の適応的な制御が間に合わず、タイムアウト再送が起こる可能性が高くなる。
【０００９】
本発明は、上記の如き従来の問題点を解決するための成されたものであり、その目的は、下位層にも情報損失補償機能を採用した、情報損失補償機能を持った通信プロトコルを利用して通信する場合に、下位層の情報損失補償機能によって伝送遅延が増大しても、上位層による無用な情報損失補償機能の実行を抑制することができる通信装置、中継装置、および、その通信制御方法を提供することにある。
【００１０】
【課題を解決するための手段】
上記目的を達成するために、本発明は、他の通信装置と接続するインターフェースを有し、そのインターフェースを介して他の通信装置からの複数のパケットを送受信する通信装置において、他の通信装置に送信すべき複数のパケットを蓄積するパケット蓄積手段と、そのパケット蓄積手段に蓄積された複数のパケットそれぞれが属するトランスポート層コネクションを識別するコネクション識別手段と、そのネクション識別手段の識別結果を用いて、トランスポート層コネクションそれぞれの送信状況を管理する送信状況管理手段と、その送信状況管理手段により管理された送信状況に基づいて、パケット蓄積手段に蓄積された複数のパケットの送信順序を、リンク層にて、制御するパケット送信順序制御手段と、から構成された通信装置であることを第１の特徴とする。
【００１１】
この第１の発明によれば、送信パケット蓄積手段に、送信要求順に蓄積されたパケットを、同一コネクションに属するパケットが連続して送信されないように、その送信順序を変更することが可能となる。すなわち、異なるコネクションに属するパケットが順に送信することが可能となる。このため、タイムアウト再送等、上位層による無用な情報損失補償機能の実行が抑制される。
【００１２】
本発明の第２の特徴は、上記の第１の特徴で述べた通信装置によって実現される通信制御方法に係り、他の通信装置に送信すべき複数のパケットを蓄積する工程と、その蓄積された複数のパケットが属するそれぞれのトランスポート層コネクションを識別する工程と、その識別結果を用いて、トランスポート層コネクションそれぞれの送信状況を管理し、その管理された送信状況に基づいて、蓄積された複数のパケットの送信順序を、リンク層にて、制御する工程と、を含む通信制御方法であることである。
【００１３】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態について詳細に説明する。以下の図面の記載において、同一または類似の部分には同一または類似の符号を付している。
【００１４】
（第１の実施の形態）
図１は、本発明の第１の実施の形態に係るネットワーク・システムの構成を示すブロック図である。この第１の実施の形態に係るネットワーク・システムにおいて、端末１０と無線基地局１２とは、ＩＰパケットの配送機能を持つネットワーク１４を介して、接続されている。無線基地局１２は、無線回線１６によって、無線端末１８を収容する。そして、端末１０と無線端末１８は、ネットワーク１４、無線基地局１２および無線回線１６を介して、ＩＰパケットを交換する。以下では、説明の簡単化を図るため、端末１０から無線端末１８に対して、ＴＣＰによる情報送信を行なうものとする。
【００１５】
図２は、通信機能に着目した、図１の無線端末１８のプロトコル構成を示す図である。無線端末１８は、通信アプリケーション１８１と、ＴＣＰ層１８２と、ＩＰ層１８３と、リンク層１８４と、無線物理層１８５と、で構成される。
【００１６】
また、図３は、通信機能に着目した、図１の無線基地局１２のプロトコル構成を示す図である。無線基地局１２は、ＩＰ層１２１と、リンク層１２２と、無線物理層１２３と、有線物理層１２４と、で構成される。ＩＰ層１２１は、ＩＰパケットのルーティング機能を含んでいる。ここで、無線物理層１２３にはリンク層１２２が存在するが、有線物理層１２４に対応するリンク層は存在しない。これは、再送やリンク状態に応じた適応的なエラー訂正等、回線状態に依存して伝送遅延が変換する要因が、有線側、すなわちネットワーク１４側にないことを示している。もちろん、一般には、有線側にもリンク層が存在しても良い。
【００１７】
図２（無線端末１８）のリンク層１８４と図３（無線基地局１２）のリンク層１２２とは対向して、無線回線１６を介した情報の送受信を行なう。そして、主として、無線回線１６において生じる無線エラーによって生じる情報損失を、エラー訂正や再送等の手段によって補償する機能を実現する。
【００１８】
また、本発明の第１の実施の形態では、図２のリンク層１８４と図３のリンク層１２２との間の１つのリンク層コネクションに、すべてのＴＣＰ／ＩＰパケットが多重化されることを仮定する。つまり、リンク層コネクションの設定解放は、ＴＣＰコネクションの設定解放とは無関係で良く、通常は無線端末１８が無線基地局１２と通信を開始した際に設定され、通信を終了する際に解放される。本発明では、リンク層でＴＣＰコネクションを識別する必要はあるが、リンク層コネクション設定のためのシグナリング（コネクション設定制御）情報等のオーバヘッドが増えることはない。ＵＤＰ／ＩＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）等の他の種類のパケットは、このリンク層コネクションに多重化されても良いし、別リンク層コネクションによって伝送されても良い。
【００１９】
図４は、図２のリンク層１８４および図３のリンク層１２２それぞれの機能ブロック図である。図４では、上位層２０が、図２のＩＰ層１８３および図３のＩＰ層１２１それぞれに相当し、無線回線インタフェース４４が、図２の無線物理層１８５および図３の無線物理層１２３に相当する。以下では、必要に応じて、図２の無線端末１８のリンク層１８４の機能であれば、「＊＊＊＊＊機能（Ｍ）」と呼び、図３の無線基地局１２のリンク層１２２の機能であれば、「＊＊＊＊＊機能（Ｂ）」と呼ぶこととする。たとえば図４の送信パケット蓄積機能２２は、図２の無線端末１８のリンク層１８４の機能であれば、「送信パケット蓄積機能（Ｍ）」と呼ばれ、図３の無線基地局１２のリンク層１２２の機能であれば、「送信パケット蓄積機能（Ｂ）」と呼ばれることになる。
【００２０】
次に、図４、図５および図６を参照して、本発明の第１の実施の形態に係る通信制御方法について説明する。図５は、本発明の第１の実施の形態に係る通信制御方法のうち、図３の無線基地局１２のリンク層１２２の処理手順を示すフローチャートである。また、図６は、本発明の第１の実施の形態に係る通信制御方法のうち、図２の無線端末１８のリンク層１８４の処理手順を示すフローチャートである。上述したように、ここでは、端末１０から、無線基地局１２を介して、無線端末１８に、ＴＣＰ／ＩＰによって情報を送信することを例に採っている。このため、図５は、送信側リンク層の処理手順であり、図６は、受信側リンク層の処理手順となる。図５および図６では、説明の煩雑さを避けるため、同時に１つのＩＰパケットを送受信し、そのＩＰパケットの送受信の処理が終了後、次のＩＰパケットの送受信処理を開始することを仮定している。これは、リンク層の再送アルゴリズムが、ＳＷ（Ｓｔｏｐ ａｎｄ Ｗａｉｔ）である場合に相当する。つまり、あるリンク層フレームの送受信が完了してから、次のリンク層フレームの送受信処理を行なうので、リンク層フレームが複数のＩＰパケットの情報を含まない限り（本第１の実施の形態の仮定）、ＩＰパケットも１つずつ送受信処理されることになる。再送アルゴリズムが、ＧＢＮ（Ｇｏ Ｂａｃｋ Ｎ）またはＳＲ（Ｓｅｌｅｃｔｉｖｅ Ｒｅｐｅａｔ）等の場合には、複数のＩＰパケットの送受信処理が同時に行なわれることがあるが、本発明は、これらの場合にも、もちろん有効である。
【００２１】
（Ａ）無線基地局１２のリンク層１２２（送信側リンク層）
（１）前ＩＰパケットの処理終了後、送信側リンク層１２２の上位層２０がさらに送信するべきＩＰパケットを持っていれば、送信パケット蓄積機能（Ｂ）２２は、そのＩＰパケットを、キュー（待ち行列）の最後に追加する（図５のＳ１０１）。ＩＰパケットは、同時には１つしか送受信処理されないので、直前のＩＰパケットの送信処理終了後では、キューに連なるＩＰパケットは、すべて未送信のＩＰパケットとなる。なお、複数のＩＰパケットを同時に送受信処理する、より一般的な場合、送信中ＩＰパケットがキューの先頭に０個以上連続して連なり、続いて１個以上の未送信ＩＰパケットが連なる、順番となる。また、ここでの「送信中」とは、ＩＰパケットを構成する情報の少なくとも一部がリンク層フレームとして、一度は送信され、かつすべての情報の送信は未完了である状態を意味する。
【００２２】
（２）送信パケット選択機能（Ｂ）３２は、次に送信する候補に挙げるＩＰパケットをキューに連なるＩＰパケットから選択する（図５のステップＳ１０２）。ここで、ＩＰパケットがＴＣＰ／ＩＰパケットであれば、図７に示すＩＰヘッダ、および図８に示すＴＣＰヘッダを持っている。そして、図７の「Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ」４８、 「Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ」５０、図８の「 Ｓｏｕｒｃｅ Ｐｏｒｔ」５２、「Ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ」５４、の４つの組によって、各ＴＣＰコネクションを一意に識別することができる。以後は、簡略のため、各ＴＣＰコネクションそれぞれを、コネクション＃１、コネクション＃２、．．．と呼ぶ。この時点で、ＴＣＰコネクション＃１および＃２の未送信パケットが、この順でキューに連なっているとする。この時点におけるＴＣＰ送信管理テーブルの内容を図９に示す。
【００２３】
送信パケット選択機能（Ｂ）３２は、識別機能（Ｂ）２４によって、未送信パケットのＴＣＰコネクション番号をキューの先頭から順に調べる。最初の未送信パケットは、ＴＣＰコネクション＃１であり、図９のＴＣＰ送信管理テーブルによれば、最近送信されたことがある。したがって、送信パケット選択機能３２は、ＴＣＰコネクション＃１のパケットを、次の送信パケット候補から外す。
【００２４】
次の未送信のパケットは、ＴＣＰコネクション＃２であり、図９のＴＣＰ送信管理テーブルによれば、最近送信されていない。したがって、送信パケット選択機能（Ｂ）３２は、ＴＣＰコネクション＃２のパケットを、次に送信するパケットの候補とする。そして、このＴＣＰコネクション＃２の未送信パケットは、キューの先頭に挿入される。つまり、キュー内における、ＴＣＰコネクション＃１の未送信パケットとＴＣＰコネクション＃２の未送信パケットの順番が逆転する。
【００２５】
（３）フレーム化機能（Ｂ）３０は、ＴＣＰコネクション＃２のパケット情報のフレーム化を行なう（図５のステップＳ１０３）。ここで、リンク層１２２，１８４のフレーム構造について説明する。図１０に、リンク層１２２，１８４のフレーム構造を示す。図１０のフレーム構造において、「コネクション番号」５６は、リンク層１２２，１８４のコネクションを識別するためのものである。フレーム化機能３０は、ＴＣＰ／ＩＰパケットを、すべて同じリンク層コネクションに多重化する。
【００２６】
フレーム化機能３０は、再送制御等のため、各パケットにリンク層１２２，１８４の「シーケンス番号」５８を付与する。なお、リンク層１２２，１８４の再送制御がＳＷならばシーケンス番号は不要である。一方、ＧＢＮやＳＲ（Ｓｅｌｅｃｔｉｖｅ Ｒｅｐｅａｔ）等の場合には、もちろん必要である。フレーム長はモードによって可変であり、同じパケットの情報が最初の送信と次の再送では別のフレームになることもある。このため、「シーケンス番号」５８はフレーム番号ではなく、リンク層１２２，１８４がこれまでに送信した情報量（ビットまたはバイト等の単位）の適当なｍｏｄである。
【００２７】
「ＡＣＫ／ＮＡＣＫ番号」６０は、送達確認あるいはエラー確認の対象となる、受信されたリンク層フレームのシーケンス番号である。そして、「ＡＣＫまたはＮＡＣＫ表示」６２は、「ＡＣＫ／ＮＡＣＫ番号」６０によって示された番号が、ＡＣＫ番号であるのか、あるいはＮＡＣＫ番号であるのかを示す。フレーム化機能３０は、送達確認送信機能４０から得られる情報によって、「ＡＣＫ／ＮＡＣＫ番号」６０と「ＡＣＫまたはＮＡＣＫ表示」６２を適当な値に設定する。
【００２８】
「モード情報」６４は、リンク層のフレーム化のモードを示す。ここでは、次の２つのモードが存在すると仮定する。（ａ）第１のモードは、無線回線１６の状態が良いと想定される時に使われるクリアモードである。これはペイロードにはエラー訂正を掛けない、つまりペイロードエラー訂正情報のオーバヘッドがないモードである。（ｂ）他のモードは、無線回線１６の状態が悪いと想定される時に使われるノイジーモードである。これは、ペイロードにエラー訂正を掛ける、つまりペイロードエラー訂正情報の冗長度を加えるモードである。フレーム化機能３０は、モード決定機能２８から得られる情報によって、「モード情報」６４の値を設定する。
【００２９】
「ペイロードデータ長」６８は、このフレームの「ペイロード」に納められる情報の長さを示す。「ペイロードエラー訂正情報」の長さは含まない、正味のデータ長である。
【００３０】
「ヘッダエラー訂正情報」７０は、「リンク層ヘッダ」７２を回線エラーから保護するために与えられる冗長度情報である。
【００３１】
図１１に、リンク層フレームとＴＣＰ／ＩＰパケットの関係を示す。図１１に示すように、一般に、１つのＴＣＰ／ＩＰパケットは、複数のリンク層フレームに分割される。ここで、フレーム化の対象となるのは、キューの先頭にあるＴＣＰコネクション＃２の未送信パケットである。フレーム化機能３０は、このパケットの情報の一部に、その時のモードに応じた「ペイロードエラー訂正情報」を加えて、「リンク層ペイロード」７４を構成する。ここでは、「モード情報」６４に設定されたモードは、クリアモードであるとする。
【００３２】
なお、複数のパケットの送受信処理を並列して行なう一般の場合、図５のステップＳ２０２で選択されたパケットが、フレーム化の対象になるとは限らない。送信中のパケットがある時には、その情報がフレーム化の対象となる場合がある。
【００３３】
（４）フレーム送信機能（Ｂ）３８は、このように形成されたフレームを送信するよう、無線回線インタフェース（Ｂ）４４に指示する。同時に、図１２に示すように、ＴＣＰ送信管理テーブルに、ＴＣＰコネクション＃２を、最近送信したものとしてマークする。無線回線インタフェース（Ｂ）４４は、無線回線１６によって、形成されたフレーム（「フレームａ」と呼ぶ）を送信する（図５のステップＳ１０４）。
【００３４】
ここで、図５の無線基地局１２のリンク層１２２（送信側リンク層）の処理から、図６の無線端末１８のリンク層１８４（受信側リンク層）の処理に移行する。
【００３５】
（Ｂ）無線端末１８のリンク層１８４（受信側リンク層）
（５）無線回線インタフェース（Ｍ）４４は、無線回線１６から受信したフレームａをフレーム受信機能（Ｍ）４２に渡す（図６のステップＳ２０１）。
【００３６】
（６）フレーム受信機能（Ｍ）４２は、最初に、フレームａの「ヘッダエラー訂正情報」７０を利用して、訂正が必要であれば、「リンク層ヘッダ」７２のエラーを訂正し、ヘッダ情報を読みとれる状態にする。以下では、ほとんどの無線エラーに対してヘッダ情報は十分な保護がされており、常に正しいエラー訂正が可能であると仮定する。「モード情報」６４によって「ペイロードデータ」のエラー訂正方法を決定し、この知識と「ペイロードエラー訂正情報」７０を利用して、「ペイロードデータ」を復元する（図６のステップＳ２０２）。
【００３７】
（７）モードがクリアモードであったとし、かつ無線エラーが発生したのでエラー訂正ができず、ペイロードが正しく復元できなかったとする。ただし、エラー検出は常に可能であると仮定している。そして、フレームａが訂正不可能なので（図６のステップＳ２０３ＮＯ）、送達確認送信機能（Ｍ）４０は、エラー確認であるＮＡＣＫ（否定応答）をフレームヘッダに入れて送信するようにフレーム化機能（Ｍ）３０に指示する。フレーム化機能（Ｍ）３０が作成するＮＡＣＫの、図１０の「リンク層フレーム」７６は、「リンク層ヘッダ」７２のみであって良い。ただし、送信するべきデータがあれば、エラー確認（ＮＡＣＫ）は、そのデータにピギーバッキング（ｐｉｇｇｙｂａｃｋｉｎｇ、おんぶ）されるので、「リンク層ペイロード」７４が付く。ＮＡＣＫの「コネクション番号」５６は、その訂正不可能であったフレームａの「コネクション番号」５６に等しくなる。また、「ＡＣＫ／ＮＡＣＫ番号」６０には、フレームａの「シーケンス番号」５８が与えられ、「ＡＣＫまたはＮＡＣＫ表示」６２には、ＮＡＣＫを示す値が与えられる。「エラー情報」６６は、訂正可能であれば、訂正されたビット数等の誤りの程度を示す値が設定されるが、ここでは訂正不可能なので、その旨を示す値に設定される。「リンク層ヘッダ」７２の他のフィールドには、「リンク層ペイロード」７４の内容に適した値を与え、「ヘッダエラー訂正情報」７０を付加する。必要なら「ペイロード」も付けて、ＮＡＣＫフレーム（「フレームｂ」と呼ぶ）を無線回線インタフェース（Ｍ）４４によって送信する（図６のステップＳ２０４）。そして、今回受信された、訂正不可能であったフレームａは廃棄される（図６のステップＳ２０５）。
【００３８】
ここで、再び、図６の無線端末１８のリンク層１８４（受信側リンク層）の処理から、図５の無線基地局１２のリンク層１２２（送信側リンク層）の処理に移る。
【００３９】
（Ｃ）無線基地局１２のリンク層１２２（送信側リンク層）
（８）ＮＡＣＫフレームｂは、無線基地局１２のフレーム受信機能（Ｂ）４２によって受信され、エラー確認に関する情報が送達確認受信機能（Ｂ）３６に渡される（図５のステップＳ１０５）。送達確認受信機能（Ｂ）３６は、モード決定機能（Ｂ）２８に、モードを決定するように指示する。モード決定機能（Ｂ）２８は、「エラー情報」６６の値が、エラー訂正不要であったことを示している時にはクリアモード、エラー訂正必要あるいはエラー訂正不可能であったことを示している時にはノイジーモードに決定する。したがって、ここでは、クリアモードからノイジーモードに変化することになる（図５のステップＳ１０６）。
【００４０】
（９）ＮＡＣＫを受信したので（図５のステップＳ１０７ＹＥＳ）、訂正不可能であったフレームａを再送する。既に述べたのと同様の手順でパケット情報をフレーム化する（図５のステップＳ１０３）。ただし、前回はクリアモードでフレーム化したが、今回はノイジーモードでフレーム化を行なう。エラー耐性を高めるためには、「ペイロードデータ長」はクリアモードの場合より小さくする方が良い。したがって、パケットをフレームに切り分ける境界が変化する。また、図１０の「ペイロードエラー訂正情報」も付加される。作られたフレームａ′を既に述べたのと同様に送信する（図５のステップＳ１０４）。
【００４１】
ここで、図５の無線基地局１２のリンク層１２２（送信側リンク層）の処理から、図６の無線端末１８のリンク層１８４（受信側リンク層）の処理に移行する。
【００４２】
（Ｄ）無線端末１８のリンク層１８４（受信側リンク層）
（１０）無線端末１８は、再送されたフレームａ′を前述と同様に受信し（図６のステップＳ２０１）、さらに無線端末１８のフレーム受信機能（Ｍ）４２がエラー訂正を行なう（図６のステップＳ２０２）。今回は、エラー訂正が可能であったとする（図６のステップＳ２０３ＹＥＳ）。
【００４３】
（１１）送達確認送信機能（Ｍ）４０は、送達確認（ＡＣＫ）をフレームヘッダに入れて送信するようにフレーム化機能（Ｍ）３０に指示する。フレーム化機能（Ｍ）３０が作成するＡＣＫの、図１０の「リンク層フレーム」７６は、「リンク層ヘッダ」７２のみであっても、ｐｉｇｇｙｂａｃｋされても良い。ＡＣＫフレームの「コネクション番号」５６は、受信されたフレームａ′の「コネクション番号」５６に等しい。「ＡＣＫ／ＮＡＣＫ番号」６０には、受信されたフレームａ′の「シーケンス番号」５８が与えられ、「ＡＣＫまたはＮＡＣＫ表示」６２には、ＡＣＫを示す値が与えられる。また、「エラー情報」６６には、訂正されたビット数を示す値が設定される。「リンク層ヘッダ」７２の他のフィールドに「リンク層ペイロード」７４の内容に適した値を与え、「ヘッダエラー訂正情報」を付加する。必要なら「ペイロード」も付けて、ＡＣＫフレーム（「フレームｂ」と呼ぶ）を無線回線インタフェース（Ｍ）４４によって送信する（図６のステップＳ２０６）。受信されたフレームａ′は蓄積される（図６のステップＳ２０７）。なお、フレームａ′だけでは、元々のパケットが完成しないとする（図６のステップＳ２０８ＮＯ）。
【００４４】
ここで、再び、図６の無線端末１８のリンク層１８４（受信側リンク層）の処理から、図５の無線基地局１２のリンク層１２２（送信側リンク層）の処理に移る。
【００４５】
（Ｅ）無線基地局１２のリンク層１２２（送信側リンク層）
（１２）ＡＣＫフレームｂは、無線基地局１２のフレーム受信機能（Ｂ）４２によって受信され、送達確認に関する情報が、送達確認受信機能（Ｂ）３６に渡される（図５のステップＳ１０５）。
【００４６】
（１３）送達確認受信機能（Ｂ）３６は、モード決定機能（Ｂ）２８に、モードを決定するように指示する。モード決定機能（Ｂ）２８は、ＡＣＫフレームｂの「エラー情報」６６の値が、エラー訂正必要であったことを示しているので、ノイジーモードとなるように、モードを決定する。したがって、ここでは、モードは変化しない（図５のステップＳ１０６）。
【００４７】
（１４）ＡＣＫを受信したので（図５のステップＳ１０７ＹＥＳ）、新しい情報をフレーム化して送信する。フレーム化の方法は、既に述べたのと同様である（図５のステップＳ１０３）。作られたフレームを既に述べたのと同様に送信する（図５のステップＳ１０４）。
【００４８】
（１５）上記の（１）〜（１４）によるフレームの交換を無線基地局１２と無線端末１８との間で繰り返す。そして、受信側である無線端末１８で、受信されたフレームによって、１つのパケットを完成したとする（図６のステップＳ２０８ＹＥＳ）。無線端末１８のパケット組立機能（Ｍ）２６は、これまで受信し、蓄積していたフレームから、パケットを組み立てて、完成したパケットを上位層２０に渡す。さらに、このパケットを構成していたフレームを、受信フレーム蓄積機能（Ｍ）３４から削除する（図６のステップＳ２０９）。
【００４９】
（１６）パケットを完成したフレームに対するＡＣＫを無線基地局１２が受信すると、これまでと同様の手順の他に、送達確認受信機能（Ｂ）３６が送信パケット蓄積機能（Ｂ）２２に対し、送信が完了したパケットを削除するように指示する（図５のステップＳ１０９）。これでＴＣＰコネクション＃２のＴＣＰ／ＩＰパケットの送受信処理が完了する。
【００５０】
（１７）無線基地局１２の送信パケット蓄積機能（Ｂ）２２が次のパケットをキューに追加しようとするが、上位層２０が新たなパケットの送信を要求してこなかったとする（図５のステップＳ１０１）。この場合、ＴＣＰコネクション＃１のＴＣＰ／ＩＰパケットしかない状態で、送信パケット選択機能３２が、次に送信する候補のパケットを選ぶことになる。図１２に示したＴＣＰ送信管理テーブルは、ＴＣＰコネクション＃１のパケットが、最近送信されたことを示している。そして、最近送信されたことのないＴＣＰコネクションのＴＣＰ／ＩＰパケットがキューの中に存在せず、次の送信候補が選択できない。この場合、送信パケット選択機能（Ｂ）３２は、ＴＣＰ送信管理テーブルをリセットして、図１３の状態にする。そして、ＴＣＰコネクション＃１のＴＣＰ／ＩＰパケットを次の送信候補として選択する。
【００５１】
一方、上位層２０が、新たにＴＣＰコネクション＃２と＃３のＴＣＰ／ＩＰパケットの送信を要求してきたとする。これらは送信パケット蓄積機能２２によってキューに追加される（図５のステップＳ１０１）。ＴＣＰコネクション＃２のＴＣＰ／ＩＰパケットは、上記したように、最近送信されたので、送信パケット選択機能３２は、既に述べたのと同様の方法で、ＴＣＰコネクション＃３のＴＣＰ／ＩＰパケットを次の送信候補として選択し、キューの先頭に移動することになる。
【００５２】
以上説明したように、本発明の第１の実施の形態によれば、パケット蓄積キューを単純なＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）として動作させた場合と比較して、同一のＴＣＰコネクションに属するパケットが連続的にフレーム化されて送信される可能性を減少させることができる。
【００５３】
特に、本発明の第１の実施の形態は、キュー長が長くなった場合に有効である。すなわち、無線エラーによって再送が発生した場合や、無線エラーからデータを保護するために、ペイロードエラー訂正情報の与える冗長度を増やすことで、無線回線１６の有効帯域が一時的に減少して、無縁回線１６がボトルネックになると、キュー長が長くなる。まさにこのような時に、ＴＣＰ送信端末である端末１０から見たＲＴＴが急増し、ＴＣＰのタイムアウト再送が発生し易くなる。
【００５４】
本発明の第１の実施の形態は、単一ないしは少数のＴＣＰコネクションデータ送信のために無線回線１６を連続的に占有し、他のＴＣＰコネクションのＡＣＫが長期間返らなくなる傾向を回避することができる。それにより、ＴＣＰコネクションのＲＴＴの増大を抑制し、各ＴＣＰコネクションに均等に無線回線１６を利用させることができる。このため、ＴＣＰによるタイムアウト再送するＴＣＰコネクション数を減少、あるいはなくすことが可能となる。
【００５５】
このように、本発明の第１の実施の形態によれば、リンク層が、同一のＴＣＰコネクションに属するパケットがなるべく連続して送出されないように、パケット送信順序を定めることができる。このため、無線回線状態が悪くなり、回線の実効帯域が減少して伝送遅延が急増する場合にも、各ＴＣＰコネクションのＴＣＰ送信端末が観測するＲＴＴの増加を最小限に押さえることが可能となり、ＴＣＰの不要なタイムアウト再送を制御することができる。これにより、無線回線の帯域が有効に利用できる。
【００５６】
本発明の第１の実施の形態は、図１に示したネットワーク・システム構成以外にも適用可能である。図１４に、本発明の第１の実施の形態に係る別のネットワーク・システムの構成を示す。図１４において、第１の端末８０と第２の端末８６とは、第１のネットワーク８１、第１の無線中継装置８２、第２の無線中継装置８４、および第２のネットワーク８５を介して、ＩＰパケットを交換する。ここで、第１および第２のネットワーク８１，８５それぞれは、ＩＰパケットの配送機能を有している。ＩＰパケットのルーティング機能（ＩＰルータ機能）を備えた、第１および第２の無線中継装置８２，８４のプロトコル構成は、図３に示した、無線基地局１２のプロトコル構成に準ずる。また、リンク層の機能ブロックについても、図４に示した機能ブロックに準ずる。
【００５７】
図１５は、ブリッジとして機能する場合における、第１および第１の無線中継装置８２，８４のプロトコル構成を示す図である。ここで、図３のＩＰ層１２１は、ＩＰアドレスとＩＰルーティングテーブルの情報に基づいてＩＰパケットのルーティングを行なうのに対し、図１５のブリッジ機能８２１は、単に一方から受信したフレームを他方に中継するだけである。ただし、ブリッジ機能８２１は、リンク層アドレス乃至ＭＡＣアドレスによって、中継するべきフレームと中継するべきでないフレームを区別し、中継するべきでないフレームを廃棄する、といった機能を持つ場合もある。図１５のリンク層８２２は、図４のリンク層の機能ブロックにおいて、上位層２０をブリッジ機能８２１に置き換える点以外は、図４に準ずる。
【００５８】
このように構成されたネットワークにおいて、第１の端末８０から第２の端末８６に対して、ＴＣＰによる情報送信を行なうことができる。この場合のリンク層の動作手順は、第１の無線中継装置８２側が図５に示した送信側の処理手順、第２の無線中継装置８４側が図６に示した受信側の処理手順、に準ずる。
【００５９】
さらに、別のネットワーク・システムの構成を図１６に示す。このネットワーク・システムにおいては、第１の無線端末９０と第２の無線端末９２とが、無線回線９１によって直結されており、第１の無線端末９０と第２の無線端末９２とは、無線回線９１を介して、ＩＰパケットを交換する。第１および第２の無線端末９０，９２それぞれのプロトコル構成は、図２に示した、無線端末１０のプロトコル構成に準ずる。また、リンク層の機能ブロックについても、図４に示した機能ブロックに準ずる。
【００６０】
第１の無線端末９０から第２の無線端末９２に対して、ＴＣＰによる情報送信を行なうことができる。この場合のリンク層の動作手順は、第１の無線端末９０側が図５に示した送信側の処理手順、第２の無線端末９２側が図６に示した受信側の処理手順、に準ずる。
【００６１】
また、上記の実施の形態では、不安定な回線として無線の場合について説明したが、本発明はこれに限られるものではない。すなわち、有線の場合であっても、回線品質に応じたリンク層以下のレイヤ（物理層を含む）の適応的なエラー補償により、回線の実効帯域が変動する場合には、本発明の適用が有効である。
【００６２】
（第２の実施の形態）
次に、本発明の第２の実施の形態について説明する。上記の第１の実施の形態において、リンク層が無線エラーからデータを保護するために、再送を行なったり、エラー訂正情報の冗長度を増したりすると、一種の輻輳が発生する。一方で、ＴＣＰ送信端末は、パケット損失を輻輳の兆候と解釈し、ウインドウを小さくしてＡＣＫされずにネットワークに送出できるデータ量を減らすことで輻輳制御を行なう。
【００６３】
しかし、リンク層はパケットが損失しないように、無線エラーからデータを保護するため、ＴＣＰの輻輳制御はこの輻輳に対しては有効に機能しない。ＴＣＰのウインドウサイズが増え続けるので、パケットキューのサイズが十分に大きくてキュー溢れを防げるとしても、伝送遅延が非常に大きくなるという問題がある。
【００６４】
本発明の第２の実施の形態は、第１の実施の形態に係る、図２のリンク層１８４および図３のリンク層１２２に、所定の規則で上位層パケット（ＩＰパケット）に記しを付けるか、ＩＰパケットを廃棄することで、ＴＣＰの輻輳制御を有効に機能させる上位層輻輳制御機能４６を、さらに設けた例である。この上位層輻輳制御機能４６は、ＲＥＤ（Ｒａｎｄｏｍ Ｅａｒｌｙ Ｄｅｔｅｃｔｉｏｎ）等に代表される、初期段階の輻輳を検出する、いわゆるＡｃｔｉｖｅ Ｑｕｅｕｅ Ｍａｎａｇｅｍｅｎｔ機能に相当する。ただし、この第２の実施の形態では、一般的に行なわれるＩＰ層の機能としての実現ではなく、リンク層の機能として実現する。
【００６５】
ここで、ＩＰパケットを、適当な規則で廃棄する場合は、広く使われているＴＣＰ／ＩＰの実装がそのまま利用できる。一方、ＩＰパケットに記しを付けてＴＣＰの輻輳制御を機能させる場合、次に述べるＴＣＰ／ＩＰの仕様を用いる。すなわち、図７のＩＰヘッダのＴＯＳ（Ｔｙｐｅ ｏｆ Ｓｅｒｖｉｃｅ）フィールドの一部を、ＥＣＮ（Ｅｘｐｌｉｃｉｔ Ｃｏｎｇｅｓｔｉｏｎ Ｎｏｎｔｉｆｉｃａｔｉｏｎ）のために割り当てる。ＴＯＳの第６ビットがＥＣＴ（ＥＣＮ−Ｃａｐａｂｌｅ Ｔｒａｎｓｐｏｒｔ）ビットとなり、第７ビットがＣＥ（Ｃｏｎｇｅｓｔｉｏｎ Ｅｘｐｅｒｉｅｎｃｅｄ）ビットとなる。また、図８のＴＣＰヘッダのＲｅｓｅｒｖｅｄフィールドの第９ビットをＥＣＮ−Ｅｃｈｏビットに、第８ビットをＣＷＲ（Ｃｏｎｇｅｓｔｉｏｎ Ｗｉｎｄｏｗ Ｒｅｄｕｃｅｄ）ビットに割り当てる（ＩＥＴＦ ＲＦＣ２４８１）。
【００６６】
本発明の第２の実施の形態に係る上位層輻輳制御機能４６は、送信パケット蓄積機能２２のキュー長を調べ、かつローパスフィルタされた平均キュー長を計算する。平均キュー長がしきい値を超え、かつ、乱数の値が別のしきい値を越えた場合に、▲１▼ＥＣＴフラグが“１”であれば、ＴＣＰ／ＩＰパケットのＣＥフラグを“１”に設定する。一方、▲２▼ＥＣＴフラグが“０”であれば、ＴＣＰ／ＩＰパケットを廃棄する。▲１▼のＣＥビットが“１”に設定されるＴＣＰ／ＩＰパケット、および、▲２▼の廃棄されるＴＣＰ／ＩＰパケットは共に、未送信パケットのうちのいずれかを選ぶことにしておけば、リンク層の再送制御等に影響せず、実装が比較的容易になる。
【００６７】
そして、上記▲２▼のＥＣＴビットが“０”の場合、ＴＣＰ送信端末は、ＴＣＰ／ＩＰパケット損失を検出し、通常の方法で輻輳制御を行なう。一方、上記▲１▼のＥＣＴビットが“１”であることは、ＴＣＰ送信端末とＴＣＰ受信端末が、共に、ＥＣＮに対応したＴＣＰ層を持つことを示している。この場合、ＴＣＰ受信端末が、“１”のＣＥビットを持つＴＣＰ／ＩＰパケットを受信すると、ＴＣＰ送信端末からＣＷＲビットが“１”であるＴＣＰ／ＩＰパケットを受信するまでのすべてのＴＣＰ ＡＣＫのＥＣＮ−Ｅｃｈｏビットを“１”に設定する。ＴＣＰ送信端末は、ＥＣＮ−Ｅｃｈｏビットが“１”のＴＣＰ ＡＣＫを受信すると、あたかもパケット損失を検出したかのように輻輳制御を行ないウインドウサイズを小さくする。詳細な方法は記述しないが、１ＲＴＴ期間で輻輳に対して反応するのは１回を越えないように制限される。
【００６８】
このように、本発明の第２の実施の形態によれば、ＴＣＰの不要な輻輳制御の発生も抑制するので、無線回線状態が良くなり、回線の実効帯域が回復した際に、速やかに帯域を使い切ることが可能になる。また、これらの効果を得るために、既存のＴＣＰの実装を変更する必要もなく、容易にＴＣＰに実装することができる。
【００６９】
【発明の効果】
本発明によれば、下位層にも情報損失補償機能を採用した、情報損失補償機能を持った通信プロトコルを利用して通信する場合に、下位層の情報損失補償機能によって伝送遅延が増大しても、上位層による無用な情報損失補償機能の実行を抑制することができる通信装置、中継装置、および、その通信制御方法を実現できる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態に係る通信装置が適用されるネットワーク・システムの構成を示すブロック図である。
【図２】図１の無線端末１８に利用される通信プロトコルの構成を示すブロック図である。
【図３】図１の無線基地局１２に利用される通信プロトコルの構成を示すブロック図である。
【図４】図２のリンク層１８４および図３のリンク層１２２それぞれの機能ブロック図である。
【図５】本発明の第１の実施の形態に係る通信制御方法の処理手順のうち、図３の無線基地局１２のリンク層１２２の処理手順を示すフローチャートである。
【図６】本発明の第１の実施の形態に係る通信制御方法の処理手順のうち、図２の無線端末１８のリンク層１８４の処理手順を示すフローチャートである。
【図７】一般的なＴＣＰ／ＩＰパケットに付加されたＩＰヘッダの内容を説明する図である。
【図８】一般的なＴＣＰ／ＩＰパケットに付加されたＴＣＰヘッダの内容を説明する図である。
【図９】ＴＣＰ送信管理テーブルの内容を説明する図である。
【図１０】図２および図３のリンク層１２２，１８４のフレーム構造を示す図である。
【図１１】リンク層フレームとＴＣＰ／ＩＰパケットとの対応関係を示す図である。
【図１２】ＴＣＰ送信管理テーブルの内容を説明する図である。
【図１３】ＴＣＰ送信管理テーブルの内容を説明する図である。
【図１４】本発明の第１の実施の形態に係る中継装置が適用されるネットワーク・システムの構成を示すブロック図である。
【図１５】図１４の無線中継装置８２，８４に利用される通信プロトコルの構成を示すブロック図である。
【図１６】本発明の第１の実施の形態に係る無線端末が適用されるネットワーク・システムの構成を示すブロック図である。
【符号の説明】
１０ 端末（ＴＣＰ送信端末）
１２ 無線基地局
１４ ネットワーク
１６，８３，９１ 無線回線
１８ 無線端末（ＴＣＰ受信端末）
２０ 上位層
２２ 送信パケット蓄積機能
２４ 識別機能
２６ パケット組立機能
２８ モード決定機能
３０ フレーム化機能
３２ 送信パケット選択機能
３４ 受信フレーム蓄積機能
３６ 送信確認受信機能
３８ フレーム送信機能
４０ 送信確認送信機能
４２ フレーム受信機能
４４ 無線回線インターフェース
４６ 上位層輻輳制御機能
４８ Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ
５０ Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ
５２ Ｓｏｕｒｃｅ Ｐｏｒｔ
５４ Ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ
５６ コネクション番号
５８ シーケンス番号
６０ ＡＣＫ／ＮＡＣＫ番号
６２ ＡＣＫまたはＮＡＣＫ表示
６４ モード情報
６６ エラー情報
６８ ペイロードデータ長
７０ ヘッダエラー訂正情報
７２ リンク層ヘッダ
７４ リンク層ペイロード
７６ リンク層フレーム
８０ 第１の端末
８１ 第１のネットワーク
８２ 第１の無線中継装置
８４ 第２の無線中継装置
８５ 第２のネットワーク
８６ 第２の端末
９０ 第１の無線端末
９２ 第２の無線端末
８２１ ブリッジ機能
１２１，１８３ ＩＰ層
１２２，１８４，８２２ リンク層
１２３，１８５，８２３ 無線物理層
１２４，８２４ 有線物理層
１８１ 通信アプリケーション
１８２ ＴＣＰ層
Claims (9)
- 他の通信装置と接続するインターフェースを有し、該インターフェースを介して前記他の通信装置からの複数のパケットを送受信する通信装置において、
前記他の通信装置に送信すべき複数のパケットを蓄積するパケット蓄積手段と、
該パケット蓄積手段に蓄積された複数のパケットそれぞれが属するトランスポート層コネクションを識別するコネクション識別手段と、
該コネクション識別手段の識別結果を用いて、前記トランスポート層コネクションそれぞれの送信状況を管理する送信状況管理手段と、
該送信状況管理手段により管理された送信状況に基づいて、前記パケット蓄積手段に蓄積された複数のパケットの送信順序を、リンク層にて、制御するパケット送信順序制御手段と
を具備することを特徴とする通信装置。 - 所定のネットワークと接続する第１のインターフェースと、所定の端末と接続する第２のインターフェースと、を有し、前記第１のインターフェースを介して前記ネットワーク上の通信装置から複数のパケットを受信し、該受信した複数のパケットを、前記第２のインターフェースを介して、前記端末に送信する中継装置において、
前記受信した複数のパケットを蓄積するパケット蓄積手段と、
該パケット蓄積手段に蓄積された複数のパケットそれぞれが属するトランスポート層コネクションを識別するコネクション識別手段と、
該コネクション識別手段の識別結果を用いて、前記トランスポート層コネクションそれぞれの送信状況を管理する送信状況管理手段と、
該送信状況管理手段により管理された送信状況に基づいて、前記パケット蓄積手段に蓄積された複数のパケットの送信順序を、リンク層にて、制御するパケット送信順序制御手段と
を具備することを特徴とする中継装置。 - 前記送信状況管理手段は、各コネクションに属するパケットが、過去に送信されたことがあるか否かを示す情報を、前記コネクションそれぞれについて、一時的に記憶する、ことを特徴とする請求項１に記載の通信装置。
- 前記パケット蓄積手段は、各コネクションに属するパケットが、過去の所定の期間に送信されたことがあるか否かを示す履歴情報を、前記コネクションそれぞれについて記憶する、ことを特徴とする請求項１に記載の通信装置。
- 前記パケット送信順序制御手段は、２つ以上の異なるコネクションに属するそれぞれ１つ以上の送信待ちパケットが前記パケット蓄積手段に存在し、かつ、次の送信パケットを選択する時点で、属するパケットが未送信であるコネクションが存在しない場合には、前記送信管理手段に管理された情報を初期化する、ことを特徴とする請求項３または４に記載の通信装置。
- 前記パケット蓄積手段に蓄積されたパケット量に応じて、前記トランスポート層による輻輳制御を開始するよう制御する上位層輻輳制御手段を、さらに有することを特徴とする請求項１に記載の通信装置。
- 他の通信装置に送信すべき複数のパケットを蓄積する工程と、
該蓄積された複数のパケットが属するそれぞれのトランスポート層コネクションを識別する工程と、
該識別結果を用いて、前記トランスポート層コネクションそれぞれの送信状況を管理し、該管理された送信状況に基づいて、前記蓄積された複数のパケットの送信順序を、リンク層にて、制御する工程と
を含むことを特徴とする通信制御方法。 - 前記パケット送信順序制御工程は、２つ以上の異なるコネクションに属するそれぞれ１つ以上の送信待ちパケットが存在する場合に、連続して送信される少なくとも２つのパケットが、それぞれ異なるコネクションに属するように、パケット送信順序を制御するステップを含む、ことを特徴とする請求項７に記載の通信制御方法。
- 前記パケット送信順序制御工程は、次に送信されるパケットを選択する際に、前記送信状況に基づいて、パケットが送信された履歴のないコネクションに属するパケットを選択するステップを含む、ことを特徴とする請求項７に記載の通信制御方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000121631A JP3604615B2 (ja) | 2000-04-21 | 2000-04-21 | 通信装置、中継装置および通信制御方法 |
| US09/838,145 US6937600B2 (en) | 2000-04-21 | 2001-04-20 | Communication device and communication control method using lower layer data transmission order control at upper layer |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000121631A JP3604615B2 (ja) | 2000-04-21 | 2000-04-21 | 通信装置、中継装置および通信制御方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001308947A JP2001308947A (ja) | 2001-11-02 |
| JP3604615B2 true JP3604615B2 (ja) | 2004-12-22 |
Family
ID=18632253
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000121631A Expired - Fee Related JP3604615B2 (ja) | 2000-04-21 | 2000-04-21 | 通信装置、中継装置および通信制御方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6937600B2 (ja) |
| JP (1) | JP3604615B2 (ja) |
Families Citing this family (37)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE50113534D1 (de) * | 2001-05-04 | 2008-03-13 | Nokia Siemens Networks Gmbh | Verfahren zur Flusskontrolle bei mehreren Sendern mit unbekannter und/oder verschiedener Sendeleistung |
| US7050393B2 (en) * | 2001-05-10 | 2006-05-23 | International Business Machines Corporation | Method, system, and product for alleviating router congestion |
| US7469295B1 (en) * | 2001-06-25 | 2008-12-23 | Network Appliance, Inc. | Modified round robin load balancing technique based on IP identifier |
| EP1313247B1 (en) | 2001-11-16 | 2005-11-09 | Matsushita Electric Industrial Co., Ltd. | Incremental redundancy ARQ retransmission method using bit reordering schemes |
| US7394764B2 (en) * | 2001-12-14 | 2008-07-01 | Sasken Communication Technologies Limited | Technique for improving transmission control protocol performance in lossy networks |
| US20030128681A1 (en) * | 2001-12-29 | 2003-07-10 | Dennis Rauschmayer | Method and apparatus for implementing an automatic repeat request ("ARQ") function in a fixed wireless communication system |
| JP3801526B2 (ja) | 2002-04-30 | 2006-07-26 | 松下電器産業株式会社 | 無線送信装置及び無線受信装置 |
| US6920120B2 (en) * | 2002-08-22 | 2005-07-19 | Ericsson Inc. | System and method of scheduling radio resources in a wireless communications network |
| US7961617B2 (en) * | 2002-10-29 | 2011-06-14 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for wireless network congestion control |
| US7047001B2 (en) * | 2002-12-02 | 2006-05-16 | Qualcomm Inc. | Method and apparatus for mobile-terminated short data burst communication |
| US20040156381A1 (en) * | 2003-02-10 | 2004-08-12 | Fischer Michael Andrew | Partial queuing using an interface with bounded latency |
| TW200425690A (en) * | 2003-05-13 | 2004-11-16 | Benq Corp | A header format of transmission control protocol/Internet protocol |
| US7212538B2 (en) | 2003-09-05 | 2007-05-01 | Qualcomm Incorporated | Differential ack processing buffer manager and method therefor |
| DE60330069D1 (de) * | 2003-09-11 | 2009-12-24 | Ericsson Telefon Ab L M | Verfahren zum verwerfen aller dem selben paket entsprechenden segmente in einem puffer |
| JP3948454B2 (ja) | 2003-12-12 | 2007-07-25 | ソニー株式会社 | 通信装置と通信システムと通信方法およびプログラム |
| JP4610910B2 (ja) | 2004-02-27 | 2011-01-12 | 富士通株式会社 | 通信処理装置及びその方法 |
| US8130633B2 (en) * | 2004-10-22 | 2012-03-06 | Research In Motion Limited | Method for transferring data in a wireless network |
| US8498210B2 (en) * | 2005-01-31 | 2013-07-30 | British Telecommunications Plc | Control of data in a network |
| US7463865B2 (en) * | 2005-09-28 | 2008-12-09 | Honeywell International Inc. | Automatic cable loss compensation |
| CN101416433B (zh) * | 2006-04-19 | 2013-02-20 | 三菱电机株式会社 | 数据传送控制方法以及发送装置 |
| US7990860B2 (en) | 2006-06-16 | 2011-08-02 | Harris Corporation | Method and system for rule-based sequencing for QoS |
| US8064464B2 (en) | 2006-06-16 | 2011-11-22 | Harris Corporation | Method and system for inbound content-based QoS |
| US8516153B2 (en) | 2006-06-16 | 2013-08-20 | Harris Corporation | Method and system for network-independent QoS |
| US20070291768A1 (en) * | 2006-06-16 | 2007-12-20 | Harris Corporation | Method and system for content-based differentiation and sequencing as a mechanism of prioritization for QOS |
| US20070291765A1 (en) * | 2006-06-20 | 2007-12-20 | Harris Corporation | Systems and methods for dynamic mode-driven link management |
| US8730981B2 (en) | 2006-06-20 | 2014-05-20 | Harris Corporation | Method and system for compression based quality of service |
| US20080013559A1 (en) * | 2006-07-14 | 2008-01-17 | Smith Donald L | Systems and methods for applying back-pressure for sequencing in quality of service |
| US8300653B2 (en) | 2006-07-31 | 2012-10-30 | Harris Corporation | Systems and methods for assured communications with quality of service |
| US20100238801A1 (en) * | 2006-07-31 | 2010-09-23 | Smith Donald L | Method and system for stale data detection based quality of service |
| US20100241759A1 (en) * | 2006-07-31 | 2010-09-23 | Smith Donald L | Systems and methods for sar-capable quality of service |
| US8750334B2 (en) * | 2006-10-02 | 2014-06-10 | Motorola Mobility Llc | Link layer assisted robust header compression context update management |
| WO2009070898A1 (en) * | 2007-12-07 | 2009-06-11 | Scl Elements Inc. | Auto-configuring multi-layer network |
| US8238244B2 (en) * | 2009-08-10 | 2012-08-07 | Micron Technology, Inc. | Packet deconstruction/reconstruction and link-control |
| US8516302B2 (en) * | 2010-04-16 | 2013-08-20 | General Electric Company | Automatic error control scheme selection for fixed-length messages based upon message payload size |
| JP4973770B2 (ja) * | 2010-08-11 | 2012-07-11 | 富士通株式会社 | 通信処理装置及びその方法 |
| US20130272221A1 (en) * | 2010-08-12 | 2013-10-17 | Nokia Siemens Networks Oy | Methods and Devices for Exchanging Data in a Communications Network |
| CN102148662B (zh) * | 2011-03-21 | 2014-01-15 | 大唐移动通信设备有限公司 | 一种数据发送速率的调整方法及装置 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6078564A (en) * | 1996-08-30 | 2000-06-20 | Lucent Technologies, Inc. | System for improving data throughput of a TCP/IP network connection with slow return channel |
| CA2216980C (en) * | 1996-10-04 | 2001-09-25 | Hitachi, Ltd. | Communication method |
| US5912878A (en) * | 1997-02-27 | 1999-06-15 | Motorola, Inc. | Method and end station with improved user reponse time in a mobile network |
| US6104700A (en) * | 1997-08-29 | 2000-08-15 | Extreme Networks | Policy based quality of service |
| JP3315926B2 (ja) * | 1998-05-25 | 2002-08-19 | ケイディーディーアイ株式会社 | Ｔｃｐ通信高速化装置 |
| US6215769B1 (en) * | 1998-10-07 | 2001-04-10 | Nokia Telecommunications, Inc. | Enhanced acknowledgment pacing device and method for TCP connections |
| US6862283B2 (en) * | 2000-01-13 | 2005-03-01 | Freescale Semiconductor, Inc. | Method and apparatus for maintaining packet ordering with error recovery among multiple outstanding packets between two devices |
-
2000
- 2000-04-21 JP JP2000121631A patent/JP3604615B2/ja not_active Expired - Fee Related
-
2001
- 2001-04-20 US US09/838,145 patent/US6937600B2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US6937600B2 (en) | 2005-08-30 |
| JP2001308947A (ja) | 2001-11-02 |
| US20010036154A1 (en) | 2001-11-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3604615B2 (ja) | 通信装置、中継装置および通信制御方法 | |
| US7061856B2 (en) | Data throughput over lossy communication links | |
| EP1142226B1 (en) | Communication device and method | |
| KR100785293B1 (ko) | 다중 ｔｃｐ확인응답을 이용한 ｔｃｐ 혼잡 제어 시스템및 그 방법 | |
| US7042907B2 (en) | Packet transfer apparatus and method | |
| US6741555B1 (en) | Enhancement of explicit congestion notification (ECN) for wireless network applications | |
| EP1251661B1 (en) | Data flow control method | |
| US20170149675A1 (en) | Packet retransmission method and apparatus | |
| US8085669B2 (en) | Session relay device and session relay method | |
| EP2632102A1 (en) | Method and device for data transmission | |
| WO2005088917A1 (ja) | 制御局装置、基地局装置、端末装置、パケット通信システム及びパケット通信方法 | |
| EP2119085A2 (en) | Enhanced error control communication systems and methods | |
| US9876727B2 (en) | Physical-layer signaling of flow control updates | |
| US7359326B1 (en) | Method for splitting data and acknowledgements in a TCP session | |
| US7293215B2 (en) | Radio packet data transmission control system and method | |
| JP2005244897A (ja) | 信頼性のある通信方法及びその装置 | |
| Le et al. | Reliable user datagram protocol for airborne network | |
| JP3953343B2 (ja) | 無線パケット通信装置および無線パケット通信方法 | |
| US9510242B2 (en) | Reducing superfluous traffic in a network | |
| US7573883B2 (en) | System, method and operator for increasing the active window size in a NAK-based window protocol | |
| KR100913897B1 (ko) | 재전송 타임아웃 수를 줄이기 위한 전송 제어 프로토콜혼잡제어방법 | |
| JP2001136209A (ja) | 通信装置 | |
| Bhat et al. | MPTCP combining congestion window adaptation and packet scheduling for multi-homed device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040916 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040921 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040929 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081008 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081008 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091008 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101008 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111008 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111008 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121008 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131008 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |