通信装置及び通信方法
【課題】 送るデータの量を、送信側が１つ又は２つ以上のデータ・ユニットに分割すると共に、前記送信側に受信確認データ・ユニットを返すことにより、受信側がデータ・ユニットを正しく受信したことの受信確認をする装置と方法を提案する。
【解決手段】 前記データ・ユニットは、１つ又は２つ以上の適応パラメータを伴うフロー制御手順に従って、前記送信側が送る。与えられたデータ・ユニットを送った後に、前記送信側がデータ消失検出ルーチンを実行し、始動イベントが起こった場合には、対応する応答手順を実施する。この場合の応答手順は、前記１つ又は２つ以上の適応パラメータを適応化する、少なくとも２つの異なるモードを含む。好ましくは第１及び第２のモードがあり、第１のモードは、データ・ユニットの実際の消失と関連付けて在来のデータ消失手順を含むようにし、第２のモードは、ユニットの消失ではなく、過度の遅延が起こったという認識と関連付けることにする。
【解決手段】 前記データ・ユニットは、１つ又は２つ以上の適応パラメータを伴うフロー制御手順に従って、前記送信側が送る。与えられたデータ・ユニットを送った後に、前記送信側がデータ消失検出ルーチンを実行し、始動イベントが起こった場合には、対応する応答手順を実施する。この場合の応答手順は、前記１つ又は２つ以上の適応パラメータを適応化する、少なくとも２つの異なるモードを含む。好ましくは第１及び第２のモードがあり、第１のモードは、データ・ユニットの実際の消失と関連付けて在来のデータ消失手順を含むようにし、第２のモードは、ユニットの消失ではなく、過度の遅延が起こったという認識と関連付けることにする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、所定の通信プロトコルに従って処理動作を行う、送信側と受信側（sender and receiver）の間のデータ・ユニット式通信（data unit oriented communication）を実施する通信装置及び通信方法に関する。
【背景技術】
【０００２】
データ・ユニット式通信はよく知られている。データ・ユニット式通信においては、データの量（an amount of data）が１つ又は２つ以上のデータ・ユニットに分割される。この場合、それらのデータ・ユニットの構造は、通信を行っている送信側と受信側が遵守する通信プロトコルによって定義される。そのプロトコルは、具体的情報（specific information）をどのように符号化すべきかということと、送信側及び／又は受信側が具体的情報に対してどのように反応（react（対応））し得るかということも定義するものである。また、データ・ユニット式通信は、パケット交換通信（packet exchange communication）としても知られている。具体的なプロトコルとの関係において用いられるデータ・ユニットは、例えば、パケット、フレーム（frames）、セグメント（segments）等のような異なる呼び名を有する点には注意されたい。本説明（the present description）においては、便宜上、“データ・ユニット”の用語がデータ・ユニット式通信で用いられるすべてのタイプのユニットを総称的に指すものとする。
【０００３】
信頼性（reliability）を高めるために多くの通信プロトコルが利用している機能（feature（特徴））としては、受信したデータについて受信確認（acknowledging）を行う機能がある。より具体的には、既定プロトコル（the given protocol）の送信側ないし送信側ピア（sending peer）がデータ・ユニットを送出すると共に、既定プロトコルの受信側ないし受信側ピア（receiving peer）が適切な受信確認データ・ユニット（acknowledgment data units）の返送によって正しい受信がなされた旨の受信確認をする（正しい受信がなされたことを通知する）。このようにして、その送信側ピアは、送信したデータ・ユニットが正しく受信もされたということを知らされ、これによって送るべき（送信すべき）さらなるデータ・ユニットのフロー制御（flow control）を調整できることになる。受信確認データ・ユニットを利用するプロトコルの一例としては、一連のＴＣＰ／ＩＰプロトコル（the TCP/IP protocol suite）の一部である、いわゆる伝送制御プロトコル（ＴＣＰ(transmission control protocol)）が挙げられる。
【０００４】
伝送制御プロトコル及び一連のＴＣＰ／ＩＰプロトコルについては、例えば、“TCP/IP Illustrated, Volume 1 - The Protocols”by W. Richard Stevens, Addison-Wesley, 1994 においてよく説明されている。
【０００５】
データ・ユニットないし受信確認データ・ユニットが消失することもあり得るという事実に対処するため、多くのプロトコルではタイムアウト機能（time-out feature）を備えている。そのタイムアウト機能とは、データが送られる時にタイムアウト期間（time-out period）を設定すると共に、そのタイムアウト期間が終了する時刻までにその具体的データ（the specific data）が受信確認をされなかった場合、タイムアウト応答の手順（time-out response procedure）を開始することを予定したものである。ＴＣＰにおいて、タイムアウト応答とは、受信確認されなかったデータを再送信すること（retransmitting）と、１つ又は２つ以上のフロー制御パラメータをリセットすることとにある（受信確認されなかったデータを再送信することと、１つ又は２つ以上のフロー制御パラメータをリセットすることとによってなされる）。
【０００６】
一例として、ＴＣＰでは、窓単位（window-based）のフロー制御を利用している。ＴＣＰは、送るべき与えられた数のバイトをいわゆるセグメントに分割するバイト式プロトコル（byte oriented protocol）であり、その送られたデータの記録（record）をバイトとの関係で保持する、すなわち、どのバイトまでデータが送信されたかという観点で送られたデータの記録を保持し、かつ、受信されたデータの記録もバイトとの関係で保持する。すなわち、どのバイトまでデータが受信されたかという観点で受信されたデータの記録を保持する。受信確認メッセージとの関連においてセグメントのフローを制御する最も簡単なやり方としては、セグメントを送信し、そして最後に送信したセグメントが受信確認されるまで次のセグメントを送信しないようにすることが挙げられよう。しかし、そのようなフロー制御の方法はあまり効率的でない。既に述べたように、ＴＣＰは、窓単位のフロー制御を利用するものであり、その窓単位のフロー制御は、スライド窓によるフロー制御（flow control according to sliding windows）とも呼ばれている。上述の W. Richard Stevens による著書においては、この概念についてもよく説明されている。
【０００７】
図２は、そのスライド窓の概念を例示的に図解したものである。図から分かるように、この例では、総量８１９２バイトの送信が行われているところであり、そのバイト総量が８つのセグメントに分割されている。セグメントの送信は送信窓（send window）に従って制御され、この場合において、送信窓の左端（left end）は、それらのセグメント中の送信されかつ既に受信確認がなされたデータによって定義される。図２の例では、これが２０４８バイトまでのデータ、すなわち、セグメント１及び２となっている。送信窓の長さ（length）の調整とそれによる窓の右端（right end）の調整は制御手順の問題であり、ここでは詳細に説明をする必要はない。
【０００８】
送信窓は、その対応する受信確認未済分（acknowledgment outstanding）を有し得るデータの量を定義する。図２の例において、４０９６バイトまでのデータ、すなわち、セグメント３及び４は、送信はされたが受信確認は未だされておらず、そして、かかる送信はされたが受信確認はされていないセグメントと送信窓の右端との間の差（difference）は、使用可能窓（usable window）、すなわち、如何なる受信確認をもさらに受信することなくなお送信してもよいこととされるデータを定義する。その結果として、図２の例においては、セグメント５及び６についてはこの時点でさらに送信することとしてもよいが、セグメント７及び８については窓が右に移動したときに送信できるのみとなる。窓が右に移動するということが起こるのは、さらなるセグメントの受信確認がなされて左端が右へ移動するようになった場合、及び／又は、送信窓の長さが増大した場合である。
【０００９】
さらに、留意すべき点として、ＴＣＰは累積的受信確認（cumulative acknowledgment）を提供する、すなわち、一つの受信確認メッセージが複数のセグメントをカバーし得る（may cover（複数セグメントについての受信確認メッセージとなり得る））ので、セグメントとセグメントに対する受信確認との間に一対一の対応往復通信（one-to-one correspondence）がない。一例としては、図２中に示したデータ量についての受信側ピアは、４、０９６までのバイトの一受信確認を送信し、その受信確認メッセージがセグメント３及び４の双方をカバーするものとなるようにすることができる。
【００１０】
送信側ピアで使用する送信窓は、いわゆる申告窓ないし通告窓（offered or advertised window）によって定められることになるのが通例である。その申告窓ないし通告窓とは、受信側ピアによって送信側ピアに対して与えられるデータの長さ（data length）である。これにより、受信側ピアは、送信側ピアが一度にいくつのセグメントを送信するかを支配する（influence（左右する））ことができ、通常は受信側ピアの受信バッファを基準として通告窓が計算されることになる。また、通告窓は、受信側ピアが送信する受信確認毎に、それらの受信確認によって変更し得る動的パラメータ（dynamic parameter）である。
【００１１】
通告窓以外には、いわゆる輻湊窓（congestion window）を定義することも知られている。その輻湊窓とは、低速スタート（slow start）、輻湊回避（congestion avoidance）、高速再送信及び高速復帰（fast recovery）等のようないくつかの輻湊制御ルーチンとの関連において使用されるものである（例えば、上述の W. Richard Stevens による著書を再度参照されたい。）。輻湊窓は、送信側ピアが保持する記録であり、かつ、送信側ピアと受信側ピアの間の接続手順における輻湊を考慮することを意図したものである。通常の制御メカニズムでは、送信窓が通告窓及び輻湊窓のうちのより小さいものに定義されることになる。
【００１２】
通告窓は、受信側ピアによって課される（imposed）フロー制御であるのに対し、輻湊窓は、輻湊を考慮に入れるためのメカニズムとして、送信側ピアによって課されるフロー制御である。
【００１３】
広い意味で言えば、輻湊窓は、適応フロー制御パラメータ（adaptive flow control parameter）の一例である。ＴＣＰにおいて、上述したタイムアウト応答は、輻湊窓を一つのセグメントにリセットすることと、次にその結果として一つのセグメントを送るだけとする、すなわち、受信確認がされずにそれによってタイムアウトを生じさせたセグメントを再送信する、ということとによってなされる。その後、送信側ピアは、再送信した当該セグメントの受信確認を待つ。
【００１４】
適応フロー制御パラメータの別の例としては、例えばＴＣＰではＲＴＯ（Retransmission Time Out）と呼ばれている、タイムアウト期間それ自体が挙げられる。ＲＴＯは、タイムアウトに応じるものとして倍になる。
【００１５】
既に述べたように、タイムアウト機能は、データ消失検出のメカニズム（data loss detection mechanism）である。データ消失検出のメカニズムは他にもある。別の例としては、複製受信確認（duplicate acknowledgments）の受信に応じた（応答した）ＴＣＰにおけるデータ・ユニットの再送信が挙げられる。このメカニズムについて以下に簡潔に説明する。
【００１６】
既に述べたように（例えば図２参照）、送られるデータ量はシーケンス（sequence）に分割される。従来におけるＴＣＰの実現手段（implementations）は、受信側ピアが既定バイト（a given byte）までの一定のデータ量（一定数の連続するセグメント）について受信と受信確認とをした場合に、その受信側ピアがそのシーケンスにおける次のデータを期待する（予期して待ち受ける）ように、予め構成されている（arranged）。例えば、セグメント４までのセグメントが受信された場合には、セグメント４についての受信確認がなされると共に受信側ピアがセグメント５の受信を期待する。その後、受信側ピアがセグメント５とは異なるさらなるデータ・ユニット（例えばセグメント６、７及び８）を受信すると、受信側ピアは、それが受信するそれぞれのデータ・ユニットに対してセグメント４の受信確認をし続ける。その結果として、送信側ピアは、複製受信確認を受信する。一般的に、ＴＣＰは、次のような方法で実現される。すなわち、送信側ピアが複製受信確認の数をカウントし、そして、一定の閾値（例えば３）に達した場合には、複製受信確認が受信されたデータ・ユニットの、シーケンスにおける次のデータ・ユニットを再送信する。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
本発明の目的は、送られたデータの受信確認を規定すると共にタイムアウト機能ないし複製受信確認の応答機能（duplicate acknowledgment response function）等のようなデータ消失検出機能を規定する通信プロトコルを利用したシステムにおける通信を改良することである。
【課題を解決するための手段】
【００１８】
この目的は、特許請求の範囲に記載した方法及び／又は装置によって達成される。
【００１９】
本発明によれば、通信中の送信側は、データ消失検出のメカニズムを始動させる（triggers（トリガーする））イベント（event）に応答して応答手順を実施し、前記応答手順が、フロー制御において使用される適応パラメータを適応化する（adapting（適応させる））ための、少なくとも２つの異なるモードを含むものとなっている。これにより、本発明の方法及び装置は、それらの始動イベントの管理（management of triggering events（トリガーとなるイベントの管理））において非常に柔軟なもの（柔軟性の高いもの）となっており、そして特に、始動イベントの様々な発生の可能性がある原因（potential causes）に応じて前記応答手順を選択し得るような形態で実現し、与えられる状況に対して正しい応答の対策（correct responsive measures）を発動し得るようにすることができ、かつ、それによって、データ消失検出のメカニズムを始動した後で生じ得る状況を実際には悪化させる（aggravate）可能性のある対策を回避することができる。
【００２０】
前記データ消失検出のメカニズムは、データ消失を検出することが可能なメカニズムである。例としては、タイムアウトのメカニズムや複製受信確認のメカニズムが挙げられる。勿論、本発明は、あらゆる適切なデータ消失検出のメカニズムに対しても適用することとしてよい。
【００２１】
本発明によれば、応答手順は、フロー制御において使用される適応パラメータを適応化するための、少なくとも２つの異なるモードを含む。好ましい実施形態を構成する一つの例としては、それぞれタイムアウト又は所定数（predetermined number（予め定めた数））の複製受信確認（例えば上述したように３つの複製受信確認）という異なる原因と関連付けられた、２つのモードがある。より具体的には、第１のモードがデータ・ユニットの消失と関連付けられたものとなっており、かつ、第２のモードが接続手順における過度の遅延（excessive delay along the connection）と関連付けられたものとなっている。２つの異なるモードを利用することにより、タイムアウト又は複製受信確認という原因に対して適切となるようにパラメータを適応化することが可能である。それ故に、そのフロー制御手順は、１つ又は２つ以上の評価及び判定の過程（evaluation and judgment steps）を含むことになり、その評価及び判定の過程においては、始動イベントが認定され（qualified）、例えば、イベントを生じさせたものに関してカテゴリー化（categorization）が実施される。その後、この特徴付け（characterization）の結果に応じて、適切な応答手順を作動することとしてもよい。上記例の場面においては、タイムアウト又は複製受信確認がデータ・ユニットの消失によって発生したと判断される（determined）場合には、データ・ユニットの消失に対する公知の応答手順を実行することとしてもよく、例えば、あらゆるタイムアウトないしいくつかの複製受信確認の受信がデータ・ユニットの消失によって発生するものとみなす、在来のＴＣＰから知られている手順を実行するようにしてもよい。しかし、この実施形態によれば、第２のモードがあり、タイムアウト又は複製受信確認が接続手順における過度の遅延によって発生したと判断される場合には、過度遅延応答手順（excessive delay response procedure）を実行することとし、その過度遅延応答手順は、通常ではデータ・ユニットの消失に対する応答手順とは異なるものとなる。
【００２２】
より具体的には、後のより詳細な説明においても述べるように、データ・ユニットが消失したとの判定に対しては、伝送速度（transmission rate）を減少させることによって応えることとし、それによってさらなる輻湊を回避する。他方、接続手順における過度の遅延がある場合には、仮定したデータ・ユニットの消失に応じて取られる対策が有効なものとはならず、それどころか逆に、それらがその過度の遅延を発生させている問題を実際には悪化させる可能性もある。したがって、過度の遅延に対する応答手順は、通常は異なるものとし、例えば、伝送速度を以前のレベルに維持することを含めるが、その一方でタイムアウト期間を増やすことを含めることとして、さらなる余計な（不要な）再送信を回避するようにする。
【００２３】
勿論、本発明は、様々な始動イベントの原因に対する任意の数のモードないし応答手順を備えるものとして実現してもよい。モードの数と各モードにおいて取る具体的な対策は、勿論具体的な状況に応じて定める。すなわち、モードの数と各モードにおいて取る具体的な対策は、選択したプロトコル、与えられた通信の状況等に応じて定める。
【００２４】
本発明の一つの重要な特徴（aspect）は、データ消失検出のメカニズムがデータ消失を検出することが可能であるが、データ消失検出のメカニズムの始動に対する反応（対応）では、必ずしもデータ消失が生じたとはみなさず、それとは極めて対照的に、様々な始動イベントの原因を考慮し得る柔軟な応答が可能である、という点である。
【００２５】
本発明のさらなる特徴と有利な効果（advantages）は、図面を参照した以下の詳細な説明からさらによく理解できるであろう。
【発明を実施するための最良の形態】
【００２６】
以下の説明においては、データの受信確認を利用すると共にタイムアウト機能も備えた任意の通信プロトコルを対象として広く説明を行うこととするが、一連のＴＣＰ／ＩＰプロトコルにより知られている伝送制御プロトコルＴＣＰに関係する例を度々挙げることにする。このプロトコルへの本発明の適用は、一つの好ましい実施形態である。余計な重複説明をすべて回避するため、その適用の導入においての開示は本発明の開示の中に取り入れることにする。
【実施例】
【００２７】
図１は、本発明の好ましい実施形態の部分的な流れ図を示したものである。図から分かるように、ステップＳ１は、応答手順に入ることを示している。図１がこの時点にまで導くフロー制御手順を示していないのは、それが本発明にとっては何等の重要性もないことだからである。例えば、それは、図２との関係で説明した窓単位のフロー制御手順であってもよく、ＴＣＰ等によってよく知られているものであってもよい。本発明にとって重要なことは、データ受信確認及びデータ消失検出機能があり、起こり得る（possible）データ消失ないし発生の可能性があるデータ消失を検出する能力（capability）をプロトコルの送信側ピアが有し、かつ、対応する応答手順をその送信側ピアが実施し得るようにすることだけである。既に述べたように、そのデータ消失検出機能は、例えば、タイムアウト機能や複製受信確認の検出機能等であってもよい。
【００２８】
図１の例では、応答手順に入った後に、ステップＳ２において、選択したフロー制御のために使用される適応パラメータを記憶し、かつ、それから所定の値（predetermined values（予め定めた値））にそれらの選択した適応パラメータをリセットする。例としては、タイムアウト期間及び／又は上述の輻湊窓がかかる適応フロー制御パラメータに当たる。在来のＴＣＰにおいては、通常では、輻湊窓を一つのセグメントの値にリセットし、かつ、同時にＲＴＯを倍にする。フロー制御手順において使用されるすべての適応パラメータを実際に変更する必要はなく、それとは全く別で選択したもの（a selected number）だけを実際に変更する必要があるだけである、という点に注意されたい。
【００２９】
また、本発明が当然窓単位のフロー制御及び関連する適応パラメータに制限されるものではなく、それどころか逆に、本発明があらゆるフロー制御の原理（principle）及び関連する適応パラメータに対して適用できるということは、明らかである。
【００３０】
図１に戻ると、ステップＳ３においては、イベントを始動させたデータ・ユニット（例えば、タイムアウトを発生させたデータ・ユニット）を再送信する。すなわち、タイムアウトの例を使い続ける場合にあっては、そのタイムアウト期間の間に何等の受信確認も受信されなかったデータ・ユニットが再送信される。その後、より後の時点において、再送信したデータ・ユニットに係る受信確認が受信されたかどうかをステップＳ４で判断する。これは、累積的受信確認であってもよく、あるいはまた、単独の受信確認（a single acknowledgment）であってもよい。注記し得る点として、図１中の点線は、他のステップを介在させる（interposed（間に他のステップを入れる））ことにしてもよいことを示しているが、それらは本発明にとって何等重要なことではない。その後、図１の好ましい例によれば、ステップＳ５において、再送信したデータ・ユニットに係る受信確認が実際にはそのデータ・ユニットのもとの送信（the original transmission）に対して受信確認するものであるか、あるいは、再送信に対して受信確認するものであるかを判断する。ここで注意すべき点として、その“もとの送信”が既に再送信となっていてもよく、“再送信”が再送信の再送信等々であるようになっていてもよい。ステップＳ５を実現することが可能な手段（possibilities）は、続くさらなる説明で述べるように様々なものがある。
【００３１】
受信確認メッセージが実際にデータ・ユニットの再送信に対して受信確認しているものとステップＳ５で判断される場合には、手順がステップＳ７へと進む。この場合のステップＳ７においては、データ・ユニットのもとの送信が消失したことを判断ステップＳ５の否定的結論（negative outcome）が指示している（indicates（示し表している））ので、データ・ユニット消失の応答手順を実行する。ＴＣＰの例では、データ・ユニット消失に備えての在来の対策によってステップＳ７がなされることになる。
【００３２】
これに対して、判断ステップＳ５で肯定的（affirmative）な応えがなされる場合には、手順がステップＳ６へと進む。この場合のステップＳ６においては、過度の遅延に応える（answers）応答手順を実行する。すなわち、ステップＳ５は、データ・ユニットのもとの送信が実際には消失したのではなく、過度に遅延しただけであることを指示しているので、対応する対策を取らなければならない。例えば、プロトコルの例としてＴＣＰを採用しているときは、これ（対応する対策）は、輻湊窓をステップＳ２で記憶した値に戻すことと、その一方でタイムアウト期間を遅延に適応させることとによって行うものとしてもよい。すなわち、タイムアウト期間を適応化するための基準としては、もとの送信及びもとの送信の受信確認に係る往復伝送時間ＲＴＴ（round trip time）を利用することができる。これにより、過度の遅延に起因するさらなる余計な再送信及びタイムアウト又は複製受信確認を回避することができる。
【００３３】
好ましくは、輻湊窓は、単純に以前の値にリセットするのではなく、むしろ、応答手順が行われなかったと仮定した場合の値、すなわち、データ消失検出のメカニズムが始動されなかったと仮定した場合の値に設定する方がはるかによい。
【００３４】
上述のことから分かるように、図１の例は、ステップＳ２、Ｓ３、Ｓ４、Ｓ５及びＳ７で構成されている第１のモードを示しており、これに加えてステップＳ２、Ｓ３、Ｓ４、Ｓ５及びＳ６で構成されている第２のモードも示している。
【００３５】
本発明について一層詳細に説明するために、従来のＴＣＰに関して行われるフロー制御手順の例を示した図３を参照する。グラフは、時間の経過とともに伝送されるデータの量をバイト単位で示したものである。図に示されているように、最初の２つのセグメントは、時刻ｔ＝４ｓに送信される。次に、受信確認データユニットと適応パラメータの調整との相互作用にしたがって、セグメントが送られる。
【００３６】
説明のために、ダイヤモンド状の記号はセグメントを表し、正方形の記号は受信確認データユニットを表すことに留意する必要がある。ダイヤモンド状の記号は、セグメントの最初のバイトを、正方形は受信確認されなかった最も下位のバイトをあらわす。所定のセグメントのレベルで示された受信確認データユニットは常に当該セグメントのレベルまでの送信されたセグメントを表す。換言すれば、６４００バイト（ｔ＝１２ｓ）セグメントレベルまでの受信確認は、６４００バイトより下のセグメントの受信確認を意味するが、６４００バイトそのものを含まない。反対に、図に明瞭に示したように、６４００バイト（ｔ＝１０ｓ）のセグメントは、時間切れを生じさせるデータユニット又はパケットである。したがって、６４００バイトレベルで前記データの再送信が行われる。
【００３７】
図３に示した時間切れが長すぎる遅延のために生じたものであり、図に示した第１のパケットが消失したために生じたものではないと仮定するなら、再送信は以下に記載するような不利益を伴なう。
【００３８】
第１に、同じデータが同一の接続又は接続パスを２回通らなくてはならず、さもなければ有益なデータのために使用することができたバンド幅を浪費することになるためにスループット性能を低下させる。この不利益は、時間切れに対して誤ってデータユニットの再送信で答えるすべてのプロトコルで生じるものである。
【００３９】
図３に示すように、ＴＣＰプロトコルが使用されているなら、データユニットの喪失で生じたものではない時間切れに対する送信側のこの応答は特に不都合である。送信側は滞留中のすべてのパケットを再送信して、さらに送信レートを低下させてしまう。このことを具体的に図３に示した。
【００４０】
上述のデータユニットの喪失ではなく生じた時間切れは、擬似時間切れとも称することに注意されたい。
【００４１】
図３に示されているように、従来のＴＣＰでは、送信側は再送信したデータユニットに対するすべての受信確認を、もとの送信の受信確認が遅れて受信されたものであっても、再送信を受信確認するものと誤って解釈する。
【００４２】
図３には示されていないが、送信側のピアから送信される２度目のデータユニットによって、受信側からの二重の受信確認を引き起こし、従来のＴＣＰ送信においては、通信レートはさらに低下し、輻湊による窓は初期の値の半分になる。
【００４３】
ＴＣＰ時間切れ時間が考慮する範囲を超えた過大な遅延は特に、少なくとも一部分が無線リンクで実行される無線ネットワークや、そのためのプロトコル接続において発生する。本発明の発明者は、その種のネットワークでは擬似時間切れが頻繁に発生して、重大な性能の低下をきたすことを発見した。その例を簡単に説明する。
【００４４】
図４は、２つのホストコンピュータがＴＣＰのピアとして動作する状態を示すものである（図の底部と頂部でホストとホストを結ぶ長い矢印で表す）。低層のプロトコルレイヤは、インターネットへの無線アクセスネットワークを含む。右側のインターネットとホストの接続は図示していない。無線リンクのプロトコルの例は、いわゆる無線リンク制御プロトコルＲＬＣである。図４に示したように、搬送レイヤプロトコル（たとえば、ＴＣＰ）と、リンクレイヤプロトコル（例えば、ＲＬＣ）は共に、ＡＲＱ（自動再送信要求）機能を具備している。これは、このプロトコルはいずれも時間切れと再送信機能を具備することを意味する。図４に示した状態では、リンクレイヤでＡＲＱが使用されているために、リンクレイヤと搬送レイヤとの間に競合状態が生じている。リンクレイヤがデータを再送信する間に、搬送再送信タイマが時間切れになって、擬似時間切れになる可能性が有る。リンクレイヤでの再送信は、例えば、ハンドオーバに起因する送信エラーやデータ消失の可能性がある。
【００４５】
無線ネットワークにおける送信の遅延は、通信レイヤプロトコルの送信側と受信側ピアの間の、両端間遅延の一部であることに注意する必要がある。この場合、無線ネットワークの搬送レイヤ接続のために使用可能なバンド幅が、短時間に顕著に低下すれば、搬送レイヤの送信側と受信側の両端の間の遅延が増大して、擬似時間切れを生じさせることになる。バンド幅低下の例は、移動ホストが、前のセルよりも提供できるバンド幅が少ないセルへのハンドオーバを実行する場合が含まれる。
【００４６】
前述のように、本発明を適用する際は、図３に示した問題を回避することができる。より具体的に述べれば、図３に示した問題に対して、図１に示した方法を適用することによって、送信側のピアは、もとのデータユニットに対する受信確認データユニットと、再送信したデータユニットに対する受信確認データユニットを区別することができる。この情報に基づいて、送信側は、擬似時間切れが発生したのか、データユニットが本当に消失したのかを決定することができる。送信側は、これに従って対処を行うことができる。
【００４７】
より具体的には、図３に示した例では、本発明を使用している送信側は、図示した第１のパケットを送信した後に受信した受信確認データユニットを、もとの送信（ｔ＝１０ｓ）に対する受信確認であって、再送信（ｔ＝１５ｓ）したものに対する受信確認ではないことを認識することができる。これに基づいて、送信側は過剰な遅延に対して適切な応答処理を実行して、つまり、第１の再送信データユニット以降についてはデータユニットを再送信するのではなく、送信レートの提言を行うこともせず、もとのデータユニットの送信から当該もとのデータユニットに対する受信確認データユニットの受信までの遅延に基づいて、フロー制御において採用する打ち切り時間を増大させる。この方法で、余計な再送信と打ち切りの発生を回避することができる。
【００４８】
すでに理解されるように、本発明は、データの受信確認と時間打ち切り機能又は二重受信確認検出機能を有するプロトコルを採用した際に、より柔軟な通信システムをもたらすことができる。上述の例では、契機となるイベントを種類によって分類することができる、つまり、少なくとも２つの異なる原因を区別して、それぞれに適切な対処を実行することができる。上述の例において、適応的なパラメータを適用する方法は、一方ではデータユニットの消失と、他方では過大な遅延とに対応しているが、本発明がこれらに限定されるわけではないことは当然である。反対に、適応的なパラメータを適応する態様は、時間切れイベント又は重複受信確認イベントを生じる原因となるものであれば、どのようなものに対しても適用することができる。
【００４９】
図１に示した実施例では、ステップＳ５で、所定のデータユニットの受信確認に対応するデータユニットが、もとの送信を受信確認するものであるか、再送信を受信確認するものであるかを決定する。当該ステップを実現する第１の好ましい実施態様によれば、送信側は送信側と受信側のピアの間の接続に関する往復時間ＲＴＴの記録を保持しており、特に、対象となる時刻までの最も短いＲＴＴ時間の記録を保持している。再送信されたデータユニットに対する受信確認データユニットが、当該最も短いＲＴＴの予め設定した一部よりも短い時間で受信された場合には、送信側は、この受信確認はもとの送信に対するものであって再送信に対するものではないと判断する。この一部の値は固定された値であっても良いし、適応的なパラメータであっても良い。当該比較値を掛けるべき値が測定された最短ＲＴＴ値である必要は無く、送信側は平均ＲＴＴ値を保持していることもできる。この意味において、当該一部の値は、一般的には、接続の途中において（当該セッションにおいて）測定された１つ以上のＲＴＴ値の関数である。
【００５０】
データユニットに、このようにマーキングすることはどのような方法で行っても良い。例えば、データユニットの内の１つのビットを、値が０であればもとの送信であって、値が１であれば再送信であるように、あるいはその逆に割り当てることも理論上は可能である。一般的には、さらに別の情報を搬送するビットストリングを選択することができる。しかし、そのような選択肢を提供するプロトコルについては、タイムスタンプオプションを使用するのが望ましい。当該オプションは、例えば、周知のＴＣＰについては、前出のW. R. Stevensによる書籍を参照されたい。換言すれば、送信されるデータユニットに、データユニットの送信時刻を示す時刻スタンプを含めることが望ましい。受信側は受信確認データユニットにこの時刻スタンプを含めて、送信側ではその受信確認がどの送信データに対するものかを識別することができるようにすることができる。
【００５１】
本発明の好ましい実施例について記載したが、実施例は本発明の範囲を制限するものではなく、本発明の理解を助けることのみを意図したものである。本発明の範囲は、添付の特許請求の範囲によって決定しなければならない。
【図面の簡単な説明】
【００５２】
【図１】本発明に基づく制御手順の好ましい実施形態を示した図である。
【図２】窓単位のフロー制御の概念を説明するための解説図である。
【図３】本発明の有利な効果を説明するためのグラフである。
【図４】２つのホスト・コンピュータ間の接続において過度の遅延が発生し得る状況を例示するための解説図である。
【技術分野】
【０００１】
本発明は、所定の通信プロトコルに従って処理動作を行う、送信側と受信側（sender and receiver）の間のデータ・ユニット式通信（data unit oriented communication）を実施する通信装置及び通信方法に関する。
【背景技術】
【０００２】
データ・ユニット式通信はよく知られている。データ・ユニット式通信においては、データの量（an amount of data）が１つ又は２つ以上のデータ・ユニットに分割される。この場合、それらのデータ・ユニットの構造は、通信を行っている送信側と受信側が遵守する通信プロトコルによって定義される。そのプロトコルは、具体的情報（specific information）をどのように符号化すべきかということと、送信側及び／又は受信側が具体的情報に対してどのように反応（react（対応））し得るかということも定義するものである。また、データ・ユニット式通信は、パケット交換通信（packet exchange communication）としても知られている。具体的なプロトコルとの関係において用いられるデータ・ユニットは、例えば、パケット、フレーム（frames）、セグメント（segments）等のような異なる呼び名を有する点には注意されたい。本説明（the present description）においては、便宜上、“データ・ユニット”の用語がデータ・ユニット式通信で用いられるすべてのタイプのユニットを総称的に指すものとする。
【０００３】
信頼性（reliability）を高めるために多くの通信プロトコルが利用している機能（feature（特徴））としては、受信したデータについて受信確認（acknowledging）を行う機能がある。より具体的には、既定プロトコル（the given protocol）の送信側ないし送信側ピア（sending peer）がデータ・ユニットを送出すると共に、既定プロトコルの受信側ないし受信側ピア（receiving peer）が適切な受信確認データ・ユニット（acknowledgment data units）の返送によって正しい受信がなされた旨の受信確認をする（正しい受信がなされたことを通知する）。このようにして、その送信側ピアは、送信したデータ・ユニットが正しく受信もされたということを知らされ、これによって送るべき（送信すべき）さらなるデータ・ユニットのフロー制御（flow control）を調整できることになる。受信確認データ・ユニットを利用するプロトコルの一例としては、一連のＴＣＰ／ＩＰプロトコル（the TCP/IP protocol suite）の一部である、いわゆる伝送制御プロトコル（ＴＣＰ(transmission control protocol)）が挙げられる。
【０００４】
伝送制御プロトコル及び一連のＴＣＰ／ＩＰプロトコルについては、例えば、“TCP/IP Illustrated, Volume 1 - The Protocols”by W. Richard Stevens, Addison-Wesley, 1994 においてよく説明されている。
【０００５】
データ・ユニットないし受信確認データ・ユニットが消失することもあり得るという事実に対処するため、多くのプロトコルではタイムアウト機能（time-out feature）を備えている。そのタイムアウト機能とは、データが送られる時にタイムアウト期間（time-out period）を設定すると共に、そのタイムアウト期間が終了する時刻までにその具体的データ（the specific data）が受信確認をされなかった場合、タイムアウト応答の手順（time-out response procedure）を開始することを予定したものである。ＴＣＰにおいて、タイムアウト応答とは、受信確認されなかったデータを再送信すること（retransmitting）と、１つ又は２つ以上のフロー制御パラメータをリセットすることとにある（受信確認されなかったデータを再送信することと、１つ又は２つ以上のフロー制御パラメータをリセットすることとによってなされる）。
【０００６】
一例として、ＴＣＰでは、窓単位（window-based）のフロー制御を利用している。ＴＣＰは、送るべき与えられた数のバイトをいわゆるセグメントに分割するバイト式プロトコル（byte oriented protocol）であり、その送られたデータの記録（record）をバイトとの関係で保持する、すなわち、どのバイトまでデータが送信されたかという観点で送られたデータの記録を保持し、かつ、受信されたデータの記録もバイトとの関係で保持する。すなわち、どのバイトまでデータが受信されたかという観点で受信されたデータの記録を保持する。受信確認メッセージとの関連においてセグメントのフローを制御する最も簡単なやり方としては、セグメントを送信し、そして最後に送信したセグメントが受信確認されるまで次のセグメントを送信しないようにすることが挙げられよう。しかし、そのようなフロー制御の方法はあまり効率的でない。既に述べたように、ＴＣＰは、窓単位のフロー制御を利用するものであり、その窓単位のフロー制御は、スライド窓によるフロー制御（flow control according to sliding windows）とも呼ばれている。上述の W. Richard Stevens による著書においては、この概念についてもよく説明されている。
【０００７】
図２は、そのスライド窓の概念を例示的に図解したものである。図から分かるように、この例では、総量８１９２バイトの送信が行われているところであり、そのバイト総量が８つのセグメントに分割されている。セグメントの送信は送信窓（send window）に従って制御され、この場合において、送信窓の左端（left end）は、それらのセグメント中の送信されかつ既に受信確認がなされたデータによって定義される。図２の例では、これが２０４８バイトまでのデータ、すなわち、セグメント１及び２となっている。送信窓の長さ（length）の調整とそれによる窓の右端（right end）の調整は制御手順の問題であり、ここでは詳細に説明をする必要はない。
【０００８】
送信窓は、その対応する受信確認未済分（acknowledgment outstanding）を有し得るデータの量を定義する。図２の例において、４０９６バイトまでのデータ、すなわち、セグメント３及び４は、送信はされたが受信確認は未だされておらず、そして、かかる送信はされたが受信確認はされていないセグメントと送信窓の右端との間の差（difference）は、使用可能窓（usable window）、すなわち、如何なる受信確認をもさらに受信することなくなお送信してもよいこととされるデータを定義する。その結果として、図２の例においては、セグメント５及び６についてはこの時点でさらに送信することとしてもよいが、セグメント７及び８については窓が右に移動したときに送信できるのみとなる。窓が右に移動するということが起こるのは、さらなるセグメントの受信確認がなされて左端が右へ移動するようになった場合、及び／又は、送信窓の長さが増大した場合である。
【０００９】
さらに、留意すべき点として、ＴＣＰは累積的受信確認（cumulative acknowledgment）を提供する、すなわち、一つの受信確認メッセージが複数のセグメントをカバーし得る（may cover（複数セグメントについての受信確認メッセージとなり得る））ので、セグメントとセグメントに対する受信確認との間に一対一の対応往復通信（one-to-one correspondence）がない。一例としては、図２中に示したデータ量についての受信側ピアは、４、０９６までのバイトの一受信確認を送信し、その受信確認メッセージがセグメント３及び４の双方をカバーするものとなるようにすることができる。
【００１０】
送信側ピアで使用する送信窓は、いわゆる申告窓ないし通告窓（offered or advertised window）によって定められることになるのが通例である。その申告窓ないし通告窓とは、受信側ピアによって送信側ピアに対して与えられるデータの長さ（data length）である。これにより、受信側ピアは、送信側ピアが一度にいくつのセグメントを送信するかを支配する（influence（左右する））ことができ、通常は受信側ピアの受信バッファを基準として通告窓が計算されることになる。また、通告窓は、受信側ピアが送信する受信確認毎に、それらの受信確認によって変更し得る動的パラメータ（dynamic parameter）である。
【００１１】
通告窓以外には、いわゆる輻湊窓（congestion window）を定義することも知られている。その輻湊窓とは、低速スタート（slow start）、輻湊回避（congestion avoidance）、高速再送信及び高速復帰（fast recovery）等のようないくつかの輻湊制御ルーチンとの関連において使用されるものである（例えば、上述の W. Richard Stevens による著書を再度参照されたい。）。輻湊窓は、送信側ピアが保持する記録であり、かつ、送信側ピアと受信側ピアの間の接続手順における輻湊を考慮することを意図したものである。通常の制御メカニズムでは、送信窓が通告窓及び輻湊窓のうちのより小さいものに定義されることになる。
【００１２】
通告窓は、受信側ピアによって課される（imposed）フロー制御であるのに対し、輻湊窓は、輻湊を考慮に入れるためのメカニズムとして、送信側ピアによって課されるフロー制御である。
【００１３】
広い意味で言えば、輻湊窓は、適応フロー制御パラメータ（adaptive flow control parameter）の一例である。ＴＣＰにおいて、上述したタイムアウト応答は、輻湊窓を一つのセグメントにリセットすることと、次にその結果として一つのセグメントを送るだけとする、すなわち、受信確認がされずにそれによってタイムアウトを生じさせたセグメントを再送信する、ということとによってなされる。その後、送信側ピアは、再送信した当該セグメントの受信確認を待つ。
【００１４】
適応フロー制御パラメータの別の例としては、例えばＴＣＰではＲＴＯ（Retransmission Time Out）と呼ばれている、タイムアウト期間それ自体が挙げられる。ＲＴＯは、タイムアウトに応じるものとして倍になる。
【００１５】
既に述べたように、タイムアウト機能は、データ消失検出のメカニズム（data loss detection mechanism）である。データ消失検出のメカニズムは他にもある。別の例としては、複製受信確認（duplicate acknowledgments）の受信に応じた（応答した）ＴＣＰにおけるデータ・ユニットの再送信が挙げられる。このメカニズムについて以下に簡潔に説明する。
【００１６】
既に述べたように（例えば図２参照）、送られるデータ量はシーケンス（sequence）に分割される。従来におけるＴＣＰの実現手段（implementations）は、受信側ピアが既定バイト（a given byte）までの一定のデータ量（一定数の連続するセグメント）について受信と受信確認とをした場合に、その受信側ピアがそのシーケンスにおける次のデータを期待する（予期して待ち受ける）ように、予め構成されている（arranged）。例えば、セグメント４までのセグメントが受信された場合には、セグメント４についての受信確認がなされると共に受信側ピアがセグメント５の受信を期待する。その後、受信側ピアがセグメント５とは異なるさらなるデータ・ユニット（例えばセグメント６、７及び８）を受信すると、受信側ピアは、それが受信するそれぞれのデータ・ユニットに対してセグメント４の受信確認をし続ける。その結果として、送信側ピアは、複製受信確認を受信する。一般的に、ＴＣＰは、次のような方法で実現される。すなわち、送信側ピアが複製受信確認の数をカウントし、そして、一定の閾値（例えば３）に達した場合には、複製受信確認が受信されたデータ・ユニットの、シーケンスにおける次のデータ・ユニットを再送信する。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
本発明の目的は、送られたデータの受信確認を規定すると共にタイムアウト機能ないし複製受信確認の応答機能（duplicate acknowledgment response function）等のようなデータ消失検出機能を規定する通信プロトコルを利用したシステムにおける通信を改良することである。
【課題を解決するための手段】
【００１８】
この目的は、特許請求の範囲に記載した方法及び／又は装置によって達成される。
【００１９】
本発明によれば、通信中の送信側は、データ消失検出のメカニズムを始動させる（triggers（トリガーする））イベント（event）に応答して応答手順を実施し、前記応答手順が、フロー制御において使用される適応パラメータを適応化する（adapting（適応させる））ための、少なくとも２つの異なるモードを含むものとなっている。これにより、本発明の方法及び装置は、それらの始動イベントの管理（management of triggering events（トリガーとなるイベントの管理））において非常に柔軟なもの（柔軟性の高いもの）となっており、そして特に、始動イベントの様々な発生の可能性がある原因（potential causes）に応じて前記応答手順を選択し得るような形態で実現し、与えられる状況に対して正しい応答の対策（correct responsive measures）を発動し得るようにすることができ、かつ、それによって、データ消失検出のメカニズムを始動した後で生じ得る状況を実際には悪化させる（aggravate）可能性のある対策を回避することができる。
【００２０】
前記データ消失検出のメカニズムは、データ消失を検出することが可能なメカニズムである。例としては、タイムアウトのメカニズムや複製受信確認のメカニズムが挙げられる。勿論、本発明は、あらゆる適切なデータ消失検出のメカニズムに対しても適用することとしてよい。
【００２１】
本発明によれば、応答手順は、フロー制御において使用される適応パラメータを適応化するための、少なくとも２つの異なるモードを含む。好ましい実施形態を構成する一つの例としては、それぞれタイムアウト又は所定数（predetermined number（予め定めた数））の複製受信確認（例えば上述したように３つの複製受信確認）という異なる原因と関連付けられた、２つのモードがある。より具体的には、第１のモードがデータ・ユニットの消失と関連付けられたものとなっており、かつ、第２のモードが接続手順における過度の遅延（excessive delay along the connection）と関連付けられたものとなっている。２つの異なるモードを利用することにより、タイムアウト又は複製受信確認という原因に対して適切となるようにパラメータを適応化することが可能である。それ故に、そのフロー制御手順は、１つ又は２つ以上の評価及び判定の過程（evaluation and judgment steps）を含むことになり、その評価及び判定の過程においては、始動イベントが認定され（qualified）、例えば、イベントを生じさせたものに関してカテゴリー化（categorization）が実施される。その後、この特徴付け（characterization）の結果に応じて、適切な応答手順を作動することとしてもよい。上記例の場面においては、タイムアウト又は複製受信確認がデータ・ユニットの消失によって発生したと判断される（determined）場合には、データ・ユニットの消失に対する公知の応答手順を実行することとしてもよく、例えば、あらゆるタイムアウトないしいくつかの複製受信確認の受信がデータ・ユニットの消失によって発生するものとみなす、在来のＴＣＰから知られている手順を実行するようにしてもよい。しかし、この実施形態によれば、第２のモードがあり、タイムアウト又は複製受信確認が接続手順における過度の遅延によって発生したと判断される場合には、過度遅延応答手順（excessive delay response procedure）を実行することとし、その過度遅延応答手順は、通常ではデータ・ユニットの消失に対する応答手順とは異なるものとなる。
【００２２】
より具体的には、後のより詳細な説明においても述べるように、データ・ユニットが消失したとの判定に対しては、伝送速度（transmission rate）を減少させることによって応えることとし、それによってさらなる輻湊を回避する。他方、接続手順における過度の遅延がある場合には、仮定したデータ・ユニットの消失に応じて取られる対策が有効なものとはならず、それどころか逆に、それらがその過度の遅延を発生させている問題を実際には悪化させる可能性もある。したがって、過度の遅延に対する応答手順は、通常は異なるものとし、例えば、伝送速度を以前のレベルに維持することを含めるが、その一方でタイムアウト期間を増やすことを含めることとして、さらなる余計な（不要な）再送信を回避するようにする。
【００２３】
勿論、本発明は、様々な始動イベントの原因に対する任意の数のモードないし応答手順を備えるものとして実現してもよい。モードの数と各モードにおいて取る具体的な対策は、勿論具体的な状況に応じて定める。すなわち、モードの数と各モードにおいて取る具体的な対策は、選択したプロトコル、与えられた通信の状況等に応じて定める。
【００２４】
本発明の一つの重要な特徴（aspect）は、データ消失検出のメカニズムがデータ消失を検出することが可能であるが、データ消失検出のメカニズムの始動に対する反応（対応）では、必ずしもデータ消失が生じたとはみなさず、それとは極めて対照的に、様々な始動イベントの原因を考慮し得る柔軟な応答が可能である、という点である。
【００２５】
本発明のさらなる特徴と有利な効果（advantages）は、図面を参照した以下の詳細な説明からさらによく理解できるであろう。
【発明を実施するための最良の形態】
【００２６】
以下の説明においては、データの受信確認を利用すると共にタイムアウト機能も備えた任意の通信プロトコルを対象として広く説明を行うこととするが、一連のＴＣＰ／ＩＰプロトコルにより知られている伝送制御プロトコルＴＣＰに関係する例を度々挙げることにする。このプロトコルへの本発明の適用は、一つの好ましい実施形態である。余計な重複説明をすべて回避するため、その適用の導入においての開示は本発明の開示の中に取り入れることにする。
【実施例】
【００２７】
図１は、本発明の好ましい実施形態の部分的な流れ図を示したものである。図から分かるように、ステップＳ１は、応答手順に入ることを示している。図１がこの時点にまで導くフロー制御手順を示していないのは、それが本発明にとっては何等の重要性もないことだからである。例えば、それは、図２との関係で説明した窓単位のフロー制御手順であってもよく、ＴＣＰ等によってよく知られているものであってもよい。本発明にとって重要なことは、データ受信確認及びデータ消失検出機能があり、起こり得る（possible）データ消失ないし発生の可能性があるデータ消失を検出する能力（capability）をプロトコルの送信側ピアが有し、かつ、対応する応答手順をその送信側ピアが実施し得るようにすることだけである。既に述べたように、そのデータ消失検出機能は、例えば、タイムアウト機能や複製受信確認の検出機能等であってもよい。
【００２８】
図１の例では、応答手順に入った後に、ステップＳ２において、選択したフロー制御のために使用される適応パラメータを記憶し、かつ、それから所定の値（predetermined values（予め定めた値））にそれらの選択した適応パラメータをリセットする。例としては、タイムアウト期間及び／又は上述の輻湊窓がかかる適応フロー制御パラメータに当たる。在来のＴＣＰにおいては、通常では、輻湊窓を一つのセグメントの値にリセットし、かつ、同時にＲＴＯを倍にする。フロー制御手順において使用されるすべての適応パラメータを実際に変更する必要はなく、それとは全く別で選択したもの（a selected number）だけを実際に変更する必要があるだけである、という点に注意されたい。
【００２９】
また、本発明が当然窓単位のフロー制御及び関連する適応パラメータに制限されるものではなく、それどころか逆に、本発明があらゆるフロー制御の原理（principle）及び関連する適応パラメータに対して適用できるということは、明らかである。
【００３０】
図１に戻ると、ステップＳ３においては、イベントを始動させたデータ・ユニット（例えば、タイムアウトを発生させたデータ・ユニット）を再送信する。すなわち、タイムアウトの例を使い続ける場合にあっては、そのタイムアウト期間の間に何等の受信確認も受信されなかったデータ・ユニットが再送信される。その後、より後の時点において、再送信したデータ・ユニットに係る受信確認が受信されたかどうかをステップＳ４で判断する。これは、累積的受信確認であってもよく、あるいはまた、単独の受信確認（a single acknowledgment）であってもよい。注記し得る点として、図１中の点線は、他のステップを介在させる（interposed（間に他のステップを入れる））ことにしてもよいことを示しているが、それらは本発明にとって何等重要なことではない。その後、図１の好ましい例によれば、ステップＳ５において、再送信したデータ・ユニットに係る受信確認が実際にはそのデータ・ユニットのもとの送信（the original transmission）に対して受信確認するものであるか、あるいは、再送信に対して受信確認するものであるかを判断する。ここで注意すべき点として、その“もとの送信”が既に再送信となっていてもよく、“再送信”が再送信の再送信等々であるようになっていてもよい。ステップＳ５を実現することが可能な手段（possibilities）は、続くさらなる説明で述べるように様々なものがある。
【００３１】
受信確認メッセージが実際にデータ・ユニットの再送信に対して受信確認しているものとステップＳ５で判断される場合には、手順がステップＳ７へと進む。この場合のステップＳ７においては、データ・ユニットのもとの送信が消失したことを判断ステップＳ５の否定的結論（negative outcome）が指示している（indicates（示し表している））ので、データ・ユニット消失の応答手順を実行する。ＴＣＰの例では、データ・ユニット消失に備えての在来の対策によってステップＳ７がなされることになる。
【００３２】
これに対して、判断ステップＳ５で肯定的（affirmative）な応えがなされる場合には、手順がステップＳ６へと進む。この場合のステップＳ６においては、過度の遅延に応える（answers）応答手順を実行する。すなわち、ステップＳ５は、データ・ユニットのもとの送信が実際には消失したのではなく、過度に遅延しただけであることを指示しているので、対応する対策を取らなければならない。例えば、プロトコルの例としてＴＣＰを採用しているときは、これ（対応する対策）は、輻湊窓をステップＳ２で記憶した値に戻すことと、その一方でタイムアウト期間を遅延に適応させることとによって行うものとしてもよい。すなわち、タイムアウト期間を適応化するための基準としては、もとの送信及びもとの送信の受信確認に係る往復伝送時間ＲＴＴ（round trip time）を利用することができる。これにより、過度の遅延に起因するさらなる余計な再送信及びタイムアウト又は複製受信確認を回避することができる。
【００３３】
好ましくは、輻湊窓は、単純に以前の値にリセットするのではなく、むしろ、応答手順が行われなかったと仮定した場合の値、すなわち、データ消失検出のメカニズムが始動されなかったと仮定した場合の値に設定する方がはるかによい。
【００３４】
上述のことから分かるように、図１の例は、ステップＳ２、Ｓ３、Ｓ４、Ｓ５及びＳ７で構成されている第１のモードを示しており、これに加えてステップＳ２、Ｓ３、Ｓ４、Ｓ５及びＳ６で構成されている第２のモードも示している。
【００３５】
本発明について一層詳細に説明するために、従来のＴＣＰに関して行われるフロー制御手順の例を示した図３を参照する。グラフは、時間の経過とともに伝送されるデータの量をバイト単位で示したものである。図に示されているように、最初の２つのセグメントは、時刻ｔ＝４ｓに送信される。次に、受信確認データユニットと適応パラメータの調整との相互作用にしたがって、セグメントが送られる。
【００３６】
説明のために、ダイヤモンド状の記号はセグメントを表し、正方形の記号は受信確認データユニットを表すことに留意する必要がある。ダイヤモンド状の記号は、セグメントの最初のバイトを、正方形は受信確認されなかった最も下位のバイトをあらわす。所定のセグメントのレベルで示された受信確認データユニットは常に当該セグメントのレベルまでの送信されたセグメントを表す。換言すれば、６４００バイト（ｔ＝１２ｓ）セグメントレベルまでの受信確認は、６４００バイトより下のセグメントの受信確認を意味するが、６４００バイトそのものを含まない。反対に、図に明瞭に示したように、６４００バイト（ｔ＝１０ｓ）のセグメントは、時間切れを生じさせるデータユニット又はパケットである。したがって、６４００バイトレベルで前記データの再送信が行われる。
【００３７】
図３に示した時間切れが長すぎる遅延のために生じたものであり、図に示した第１のパケットが消失したために生じたものではないと仮定するなら、再送信は以下に記載するような不利益を伴なう。
【００３８】
第１に、同じデータが同一の接続又は接続パスを２回通らなくてはならず、さもなければ有益なデータのために使用することができたバンド幅を浪費することになるためにスループット性能を低下させる。この不利益は、時間切れに対して誤ってデータユニットの再送信で答えるすべてのプロトコルで生じるものである。
【００３９】
図３に示すように、ＴＣＰプロトコルが使用されているなら、データユニットの喪失で生じたものではない時間切れに対する送信側のこの応答は特に不都合である。送信側は滞留中のすべてのパケットを再送信して、さらに送信レートを低下させてしまう。このことを具体的に図３に示した。
【００４０】
上述のデータユニットの喪失ではなく生じた時間切れは、擬似時間切れとも称することに注意されたい。
【００４１】
図３に示されているように、従来のＴＣＰでは、送信側は再送信したデータユニットに対するすべての受信確認を、もとの送信の受信確認が遅れて受信されたものであっても、再送信を受信確認するものと誤って解釈する。
【００４２】
図３には示されていないが、送信側のピアから送信される２度目のデータユニットによって、受信側からの二重の受信確認を引き起こし、従来のＴＣＰ送信においては、通信レートはさらに低下し、輻湊による窓は初期の値の半分になる。
【００４３】
ＴＣＰ時間切れ時間が考慮する範囲を超えた過大な遅延は特に、少なくとも一部分が無線リンクで実行される無線ネットワークや、そのためのプロトコル接続において発生する。本発明の発明者は、その種のネットワークでは擬似時間切れが頻繁に発生して、重大な性能の低下をきたすことを発見した。その例を簡単に説明する。
【００４４】
図４は、２つのホストコンピュータがＴＣＰのピアとして動作する状態を示すものである（図の底部と頂部でホストとホストを結ぶ長い矢印で表す）。低層のプロトコルレイヤは、インターネットへの無線アクセスネットワークを含む。右側のインターネットとホストの接続は図示していない。無線リンクのプロトコルの例は、いわゆる無線リンク制御プロトコルＲＬＣである。図４に示したように、搬送レイヤプロトコル（たとえば、ＴＣＰ）と、リンクレイヤプロトコル（例えば、ＲＬＣ）は共に、ＡＲＱ（自動再送信要求）機能を具備している。これは、このプロトコルはいずれも時間切れと再送信機能を具備することを意味する。図４に示した状態では、リンクレイヤでＡＲＱが使用されているために、リンクレイヤと搬送レイヤとの間に競合状態が生じている。リンクレイヤがデータを再送信する間に、搬送再送信タイマが時間切れになって、擬似時間切れになる可能性が有る。リンクレイヤでの再送信は、例えば、ハンドオーバに起因する送信エラーやデータ消失の可能性がある。
【００４５】
無線ネットワークにおける送信の遅延は、通信レイヤプロトコルの送信側と受信側ピアの間の、両端間遅延の一部であることに注意する必要がある。この場合、無線ネットワークの搬送レイヤ接続のために使用可能なバンド幅が、短時間に顕著に低下すれば、搬送レイヤの送信側と受信側の両端の間の遅延が増大して、擬似時間切れを生じさせることになる。バンド幅低下の例は、移動ホストが、前のセルよりも提供できるバンド幅が少ないセルへのハンドオーバを実行する場合が含まれる。
【００４６】
前述のように、本発明を適用する際は、図３に示した問題を回避することができる。より具体的に述べれば、図３に示した問題に対して、図１に示した方法を適用することによって、送信側のピアは、もとのデータユニットに対する受信確認データユニットと、再送信したデータユニットに対する受信確認データユニットを区別することができる。この情報に基づいて、送信側は、擬似時間切れが発生したのか、データユニットが本当に消失したのかを決定することができる。送信側は、これに従って対処を行うことができる。
【００４７】
より具体的には、図３に示した例では、本発明を使用している送信側は、図示した第１のパケットを送信した後に受信した受信確認データユニットを、もとの送信（ｔ＝１０ｓ）に対する受信確認であって、再送信（ｔ＝１５ｓ）したものに対する受信確認ではないことを認識することができる。これに基づいて、送信側は過剰な遅延に対して適切な応答処理を実行して、つまり、第１の再送信データユニット以降についてはデータユニットを再送信するのではなく、送信レートの提言を行うこともせず、もとのデータユニットの送信から当該もとのデータユニットに対する受信確認データユニットの受信までの遅延に基づいて、フロー制御において採用する打ち切り時間を増大させる。この方法で、余計な再送信と打ち切りの発生を回避することができる。
【００４８】
すでに理解されるように、本発明は、データの受信確認と時間打ち切り機能又は二重受信確認検出機能を有するプロトコルを採用した際に、より柔軟な通信システムをもたらすことができる。上述の例では、契機となるイベントを種類によって分類することができる、つまり、少なくとも２つの異なる原因を区別して、それぞれに適切な対処を実行することができる。上述の例において、適応的なパラメータを適用する方法は、一方ではデータユニットの消失と、他方では過大な遅延とに対応しているが、本発明がこれらに限定されるわけではないことは当然である。反対に、適応的なパラメータを適応する態様は、時間切れイベント又は重複受信確認イベントを生じる原因となるものであれば、どのようなものに対しても適用することができる。
【００４９】
図１に示した実施例では、ステップＳ５で、所定のデータユニットの受信確認に対応するデータユニットが、もとの送信を受信確認するものであるか、再送信を受信確認するものであるかを決定する。当該ステップを実現する第１の好ましい実施態様によれば、送信側は送信側と受信側のピアの間の接続に関する往復時間ＲＴＴの記録を保持しており、特に、対象となる時刻までの最も短いＲＴＴ時間の記録を保持している。再送信されたデータユニットに対する受信確認データユニットが、当該最も短いＲＴＴの予め設定した一部よりも短い時間で受信された場合には、送信側は、この受信確認はもとの送信に対するものであって再送信に対するものではないと判断する。この一部の値は固定された値であっても良いし、適応的なパラメータであっても良い。当該比較値を掛けるべき値が測定された最短ＲＴＴ値である必要は無く、送信側は平均ＲＴＴ値を保持していることもできる。この意味において、当該一部の値は、一般的には、接続の途中において（当該セッションにおいて）測定された１つ以上のＲＴＴ値の関数である。
【００５０】
データユニットに、このようにマーキングすることはどのような方法で行っても良い。例えば、データユニットの内の１つのビットを、値が０であればもとの送信であって、値が１であれば再送信であるように、あるいはその逆に割り当てることも理論上は可能である。一般的には、さらに別の情報を搬送するビットストリングを選択することができる。しかし、そのような選択肢を提供するプロトコルについては、タイムスタンプオプションを使用するのが望ましい。当該オプションは、例えば、周知のＴＣＰについては、前出のW. R. Stevensによる書籍を参照されたい。換言すれば、送信されるデータユニットに、データユニットの送信時刻を示す時刻スタンプを含めることが望ましい。受信側は受信確認データユニットにこの時刻スタンプを含めて、送信側ではその受信確認がどの送信データに対するものかを識別することができるようにすることができる。
【００５１】
本発明の好ましい実施例について記載したが、実施例は本発明の範囲を制限するものではなく、本発明の理解を助けることのみを意図したものである。本発明の範囲は、添付の特許請求の範囲によって決定しなければならない。
【図面の簡単な説明】
【００５２】
【図１】本発明に基づく制御手順の好ましい実施形態を示した図である。
【図２】窓単位のフロー制御の概念を説明するための解説図である。
【図３】本発明の有利な効果を説明するためのグラフである。
【図４】２つのホスト・コンピュータ間の接続において過度の遅延が発生し得る状況を例示するための解説図である。
【特許請求の範囲】
【請求項１】
送信側により受信された受信確認データ・ユニットが、もとの送信に対応するものか、再送信に対応するものかを検出する方法であって、当該方法が、所定の通信プロトコルに従った、送信側と受信側の間のデータ・ユニット式通信に係る方法であって、前記所定の通信プロトコルは、通信装置の前記送信側が、送信するデータの量を、１つ又はそれ以上のデータ・ユニットに分割し、当該通信の前記受信側は、前記送信側に対して受信確認データ・ユニットを返すことにより、データ・ユニットが正しく受信されたことの受信確認を行うことを規定し、当該方法は、
前記送信側は、送信するデータ・ユニットにマークを付加し、当該マークは、もとの送信と再送信の区別を可能とするものと定義され、
前記受信側は、前記受信したデータ・ユニットに対応する受信確認データ・ユニットに、受信したデータ・ユニット中の前記マークを付加し、
前記送信側が、受信した受信確認データ・ユニットが、もとの送信に対応するものか再送信に対応するものかを、前記マークに基づいて決定することからなる方法。
【請求項２】
前記マークが、予め決定されたビットストリングである、請求項１に記載の方法。
【請求項３】
前記マークが、タイムスタンプである、請求項１または２に記載の方法。
【請求項４】
前記所定の通信プロトコルが、ＴＣＰ（Transmission Control Protocol）である、請求項１ないし３のいずれか１項に記載の方法。
【請求項５】
所定の通信プロトコルに従った、送信側と受信側の間のデータ・ユニット式通信装置であって、当該所定の通信プロトコルは、通信装置の前記送信側が、送信するデータの量を、１つ又はそれ以上のデータ・ユニットに分割し、当該通信の前記受信側は、前記送信側に対して受信確認データ・ユニットを返すことにより、データ・ユニットが正しく受信されたことの受信確認を行うことを規定し、前記通信装置が、
送信側として動作するとき、当該送信側が送信するデータ・ユニットにマークを付加し、当該マークは、もとの送信と再送信の区別を可能とするものと定義され、そして当該送信側が、当該マークに基づいて、受信した受信確認データ・ユニットが、もとの送信に対応するものか、再送信に対応するものかを決定する通信装置。
【請求項６】
前記マークが、予め決定されたビットストリングである、請求項５に記載の通信装置。
【請求項７】
前記マークが、タイムスタンプである、請求項５または６に記載の通信装置。
【請求項８】
前記所定の通信プロトコルが、ＴＣＰ（Transmission Control Protocol）である、請求項５ないし７のいずれか１項に記載の方法。
【請求項９】
送信側により受信された受信確認データ・ユニットが、もとの送信あるいは、再送信に対応するものかを検出する方法であって、当該方法が、所定の通信プロトコルに従った送信側と受信側の間のデータ・ユニット式通信に係る方法であり、
前記所定の通信プロトコルは、通信装置の前記送信側が、送信するデータの量を、１つ又はそれ以上のデータ・ユニットに分割し、当該通信の前記受信側は、前記送信側に対して受信確認データ・ユニットを返すことにより、データ・ユニットが正しく受信されたことの受信確認を行うことを規定し、当該方法が、
前記送信側は、当該送信側と前記受信側の間の通信の往復時間を測定し、
データ・ユニットの再送信と、当該データ・ユニットに対応する最初の受信確認データ・ユニットの受信との間の時間を決定し、
当該時間と、前記測定された１つ又はそれ以上の往復時間から求められる値とを比較し、
前記受信確認データ・ユニットが、もとの送信あるいは再送信にもとづいたものかを、
当該比較に基づいて決定する方法。
【請求項１０】
前記往復時間の測定から求められた値が、当該通信の最短の往復時間であり、前記データ・ユニットの再送信と前記受信確認データ・ユニットの最初の受信との間の時間が、前記往復時間の予め決められた一部の値より小さくない場合には、前記受信確認データ・ユニットは、再送信に対応するものと決定される請求項９に記載の方法。
【請求項１１】
所定の通信プロトコルに従った、データ・ユニット式通信装置であって、
前記所定の通信プロトコルは、通信装置の前記送信側が、送信するデータの量を１つ又はそれ以上のデータ・ユニットに分割し、当該通信の前記受信側は、前記送信側に対して受信確認データ・ユニットを返すことにより、データ・ユニットが正しく受信されたことの受信確認を行うことを規定し、当該通信装置が、
送信側として動作するとき、当該送信側は、当該送信側と前記受信側の間の通信の往復時間を測定し、
データ・ユニットの再送信と、当該再送信に対応する最初の受信確認データユニットの受信との間の時間を決定し、
当該時間と、前記測定された１つ又はそれ以上の往復時間から求められる値とを比較し、
前記受信確認データ・ユニットが、もとの送信あるいは再送信にもとづいたものかを、
当該比較によって決定することを備える通信装置。
【請求項１２】
前記往復時間の測定から求められた値が、当該通信の最短の往復時間であり、前記データ・ユニットの再送信と前記受信確認データ・ユニットの最初の受信の間の時間が、前記往復時間の予め決められた一部の値より小さくない場合には、前記受信確認データ・ユニットは、再送信に対応するものと決定されることを、さらに備える請求項１１に記載の通信装置。
【請求項１】
送信側により受信された受信確認データ・ユニットが、もとの送信に対応するものか、再送信に対応するものかを検出する方法であって、当該方法が、所定の通信プロトコルに従った、送信側と受信側の間のデータ・ユニット式通信に係る方法であって、前記所定の通信プロトコルは、通信装置の前記送信側が、送信するデータの量を、１つ又はそれ以上のデータ・ユニットに分割し、当該通信の前記受信側は、前記送信側に対して受信確認データ・ユニットを返すことにより、データ・ユニットが正しく受信されたことの受信確認を行うことを規定し、当該方法は、
前記送信側は、送信するデータ・ユニットにマークを付加し、当該マークは、もとの送信と再送信の区別を可能とするものと定義され、
前記受信側は、前記受信したデータ・ユニットに対応する受信確認データ・ユニットに、受信したデータ・ユニット中の前記マークを付加し、
前記送信側が、受信した受信確認データ・ユニットが、もとの送信に対応するものか再送信に対応するものかを、前記マークに基づいて決定することからなる方法。
【請求項２】
前記マークが、予め決定されたビットストリングである、請求項１に記載の方法。
【請求項３】
前記マークが、タイムスタンプである、請求項１または２に記載の方法。
【請求項４】
前記所定の通信プロトコルが、ＴＣＰ（Transmission Control Protocol）である、請求項１ないし３のいずれか１項に記載の方法。
【請求項５】
所定の通信プロトコルに従った、送信側と受信側の間のデータ・ユニット式通信装置であって、当該所定の通信プロトコルは、通信装置の前記送信側が、送信するデータの量を、１つ又はそれ以上のデータ・ユニットに分割し、当該通信の前記受信側は、前記送信側に対して受信確認データ・ユニットを返すことにより、データ・ユニットが正しく受信されたことの受信確認を行うことを規定し、前記通信装置が、
送信側として動作するとき、当該送信側が送信するデータ・ユニットにマークを付加し、当該マークは、もとの送信と再送信の区別を可能とするものと定義され、そして当該送信側が、当該マークに基づいて、受信した受信確認データ・ユニットが、もとの送信に対応するものか、再送信に対応するものかを決定する通信装置。
【請求項６】
前記マークが、予め決定されたビットストリングである、請求項５に記載の通信装置。
【請求項７】
前記マークが、タイムスタンプである、請求項５または６に記載の通信装置。
【請求項８】
前記所定の通信プロトコルが、ＴＣＰ（Transmission Control Protocol）である、請求項５ないし７のいずれか１項に記載の方法。
【請求項９】
送信側により受信された受信確認データ・ユニットが、もとの送信あるいは、再送信に対応するものかを検出する方法であって、当該方法が、所定の通信プロトコルに従った送信側と受信側の間のデータ・ユニット式通信に係る方法であり、
前記所定の通信プロトコルは、通信装置の前記送信側が、送信するデータの量を、１つ又はそれ以上のデータ・ユニットに分割し、当該通信の前記受信側は、前記送信側に対して受信確認データ・ユニットを返すことにより、データ・ユニットが正しく受信されたことの受信確認を行うことを規定し、当該方法が、
前記送信側は、当該送信側と前記受信側の間の通信の往復時間を測定し、
データ・ユニットの再送信と、当該データ・ユニットに対応する最初の受信確認データ・ユニットの受信との間の時間を決定し、
当該時間と、前記測定された１つ又はそれ以上の往復時間から求められる値とを比較し、
前記受信確認データ・ユニットが、もとの送信あるいは再送信にもとづいたものかを、
当該比較に基づいて決定する方法。
【請求項１０】
前記往復時間の測定から求められた値が、当該通信の最短の往復時間であり、前記データ・ユニットの再送信と前記受信確認データ・ユニットの最初の受信との間の時間が、前記往復時間の予め決められた一部の値より小さくない場合には、前記受信確認データ・ユニットは、再送信に対応するものと決定される請求項９に記載の方法。
【請求項１１】
所定の通信プロトコルに従った、データ・ユニット式通信装置であって、
前記所定の通信プロトコルは、通信装置の前記送信側が、送信するデータの量を１つ又はそれ以上のデータ・ユニットに分割し、当該通信の前記受信側は、前記送信側に対して受信確認データ・ユニットを返すことにより、データ・ユニットが正しく受信されたことの受信確認を行うことを規定し、当該通信装置が、
送信側として動作するとき、当該送信側は、当該送信側と前記受信側の間の通信の往復時間を測定し、
データ・ユニットの再送信と、当該再送信に対応する最初の受信確認データユニットの受信との間の時間を決定し、
当該時間と、前記測定された１つ又はそれ以上の往復時間から求められる値とを比較し、
前記受信確認データ・ユニットが、もとの送信あるいは再送信にもとづいたものかを、
当該比較によって決定することを備える通信装置。
【請求項１２】
前記往復時間の測定から求められた値が、当該通信の最短の往復時間であり、前記データ・ユニットの再送信と前記受信確認データ・ユニットの最初の受信の間の時間が、前記往復時間の予め決められた一部の値より小さくない場合には、前記受信確認データ・ユニットは、再送信に対応するものと決定されることを、さらに備える請求項１１に記載の通信装置。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１２−２２７９５３（Ｐ２０１２−２２７９５３Ａ）
【公開日】平成２４年１１月１５日（２０１２．１１．１５）
【国際特許分類】
【出願番号】特願２０１２−１５５４６６（Ｐ２０１２−１５５４６６）
【出願日】平成２４年７月１１日（２０１２．７．１１）
【分割の表示】特願２０１０−１１３０４（Ｐ２０１０−１１３０４）の分割
【原出願日】平成１１年１２月３１日（１９９９．１２．３１）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公開日】平成２４年１１月１５日（２０１２．１１．１５）
【国際特許分類】
【出願日】平成２４年７月１１日（２０１２．７．１１）
【分割の表示】特願２０１０−１１３０４（Ｐ２０１０−１１３０４）の分割
【原出願日】平成１１年１２月３１日（１９９９．１２．３１）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]