(57)【要約】所定のプロトコルについての送信局から受信局にデータ量のフローを制御する方法が開示されている。この方法は、前記データ量を複数のデータセグメントに分割し、このデータセグメントがシーケンスに並べられている、工程を有している。そのセグメントは前記シーケンスの順番で受信局に送信される。受信局はデータセグメントの正確な受信を確認応答し、シーケンス中の適切な順番で受信された前記シーケンスの最新の正確に受信されたデータセグメントを確認応答する。送信局は、閾値数の重複確認応答を受信する場合には再送信を行うようになされている。再送信のきっかけとなるその閾値数は、適応的パラメータであり、３より大きい値を取るようにしている。
2004523992.tif 000002
【特許請求の範囲】
【請求項１】
所定の通信プロトコルについて送信局から受信局への所定量のデータのフローを制御する方法であって、
前記所定量のデータを、シーケンス中に並べられる複数のデータセグメントに分割する工程と、
前記データセグメントを前記送信局から前記受信局に前記シーケンスの順序で送信する工程と、
受信局において、データセグメントが正確に受信されたか否か、正確に受信されたデータセグメントが適切な順番の前記シーケンスにあるか否かを判定する工程と、
データセグメントの正確な受信を示し、前記適切な順番のシーケンスで受信された前記シーケンス中の最新の正確に受信されたデータセグメントを識別する確認応答メッセージを、前記受信局から前記送信局に送信する工程と、
前記適切な順番のシーケンスで受信された最新の正確に受信された前記シーケンス中のデータセグメントと同じ１つのデータセグメントをそれぞれ識別する閾値数の重複確認応答メッセージを送信局が受信する場合、前記１つのデータセグメントに直ちに続くセグメントを再送信する工程と、
前記閾値数をダイナミックに適応させるための閾値数適応処理工程とを備え、
前記閾値数適応処理工程は、前記閾値数が３より大きい値をとるようになされていることを特徴とするデータ量のフローを制御する方法。
【請求項２】
前記閾値数適応処理工程は、
前記データセグメント数はフロー制御に関連した所定のグループに属するデータセグメント数を識別する整数であり、データセグメント数決定処理を実行する工程と、
所定の因数により前記データセグメント数を除算する工程と、
前記所定の因数によって前記データセグメント数を除算した結果に基づいて前記閾値数を適応させる工程と、
を備えていることを特徴とする請求項１に記載の方法。
【請求項３】
前記所定の因数は、整数であることを特徴とする請求項２に記載の方法。
【請求項４】
前記所定の因数は２であることを特徴とする請求項３に記載の方法。
【請求項５】
前記所定の因数で前記データセグメント数を除算した結果に基づいて前記閾値数を適応させる工程は、
前記結果が整数の場合には、前記結果に等しい前記閾値数を設定し、前記結果が整数でない場合には、前記結果に所定の丸め演算を実行し、前記丸め演算の結果に等しい閾値数を設定することを特徴とする請求項２乃至４の何れか１項に記載の方法。
【請求項６】
データセグメントのフローを制御する工程は、１以上のウインドウを用いるスライド式ウインドウ技術を含み、前記所定のグループは前記１以上のウインドウの所定の１つに関連していることを特徴とする請求項２乃至５の何れか１項に記載の方法。
【請求項７】
前記所定のグループは、前記送信局によって計算されるウインドウに関連していることを特徴とする請求項６に記載の方法。
【請求項８】
前記所定の１つのウインドウは輻輳ウインドウであり、輻輳ウインドウは、前記複数のデータセグメントの送信開始時に前記送信局が前記輻輳ウインドウのサイズを所定の初期値に設定し、前記確認応答メッセージ及び輻輳表示イベントの発生に依存して前記サイズを制御するというフロー制御副処理に関連していることを特徴とする請求項６又は７に記載の方法。
【請求項９】
前記所定の通信プロトコルは、送信制御プロトコル（ＴＣＰ）であり、前記輻輳ウインドウはＴＣＰ輻輳ウインドウ（ｃｗｎｄ）であることを特徴とする請求項８に記載の方法。
【請求項１０】
前記データセグメント数決定処理工程は、データセグメントサイズ指標によって前記所定のウインドウのサイズを除算する工程を有することを特徴とする請求項６乃至９の何れか１項に記載の方法。
【請求項１１】
前記データセグメントサイズ指標は最大セグメントサイズであることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記所定のグループは、一連の未確定のデータセグメントであり、前記データセグメント数は未確定のデータセグメント数に等しく、未確定のデータセグメントは前記送信局によって送信されたが、前記送信局が適切な順番の前記シーケンスで受信された最新の正確に受信された前記シーケンス中のデータセグメントとして前記データセグメントを識別する確認応答メッセージを受信しなかったデータセグメントであることを特徴とする請求項２乃至５の何れか１項に記載の方法。
【請求項１３】
前記閾値数は、前記所定のグループが変わる度に適応されることを特徴とする請求項１乃至１２の何れか１項に記載の方法。
【請求項１４】
前記閾値数は、前記データセグメントの１つに対する重複確認応答メッセージが受信される最初のとき毎に少なくとも更新されることを特徴とする請求項１乃至１３の何れか１項に記載の方法。
【請求項１５】
前記閾値数は、重複確認応答メッセージが受信される毎に更新されることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記閾値数は、確認応答メッセージが受信される毎に更新されることを特徴とする請求項１乃至１２の何れか１項に記載の方法。
【請求項１７】
前記閾値数は、未確定のデータセグメントを識別する確認応答メッセージが受信される毎に更新され、未確定のデータセグメントは前記送信局によって送信されたが、前記送信局が適切な順番のシーケンスで受信された最新の正確に受信された前記シーケンス中のデータセグメントとして前記セグメントを識別する確認応答メッセージを受信しなかったデータセグメントであることを特徴とする請求項１乃至１６の何れか１項に記載の方法。
【請求項１８】
前記所定の通信プロトコルは第１のプロトコル層（Ｌ４）にあり、第２のプロトコル層（Ｌ２）は、前記所定の通信プロトコルの送信局から前記データセグメントを受信し、前記所定の通信プロトコルの受信局に前記データセグメントをリリースする、前記第１のプロトコル層（Ｌ４）に供給される所定のプロトコル実行を有し、前記所定のプロトコル実行は前記シーケンスの限度を越えて前記データセグメントをリリースするように動作することを特徴とする請求項１乃至１７の何れか１項に記載の方法。
【請求項１９】
前記第１のプロトコル層（Ｌ４）はトランスポート層であり、前記第２のプロトコル層（Ｌ２）はリンク層であることを特徴である請求項１８に記載の方法。
【請求項２０】
コンピュータ上で実行される際に請求項１乃至１９の何れか１項の方法を実行するようになされたコンピュータプログラム。
【請求項２１】
請求項２０記載のコンピュータプログラムを格納している、コンピュータ読み取り可能なメモリー装置。
【請求項２２】
データの送受信を行うようになされた通信装置であって、
前記通信装置は、請求項１乃至１９の何れか１項の方法に従って送信局及び／又は受信局として動作するようになされていることを特徴とする通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、所定の通信プロトコルにおける、送信局（送信ピア）から受信局（受信ピア）へのデータ量のフローを制御する方法に関するものである。
【背景技術】
【０００２】
通信分野において、所定量の送信されるべきデータは連続の順に並べられた複数のデータセグメントに分割されるというデータ送信技術が知られている。そして、これらのデータセグメントは前記連続の順に送信される。
【０００３】
この処理（Procedure）はいわゆる送信局（送信ピア）で起こるものであるが、その送信局での通信は、そのようなデータセグメントを処理するための規則を含む所定のプロトコルによって支配される。その所定のプロトコルに関連する受信エンティティは受信局（受信ピア）と呼ばれる。プロトコル、プロトコル階層分類、レイヤー、プロトコルピアは当該技術分野でよく知られている。例えば、Ｗ．リチャード・スティーブンス、アディソン・ウェスレイ著の”TCP/IP Illustrated Volume 1, The Protocols"（１９９４年）を参照のこと。ＴＣＰ／ＩＰプロトコル列（Suite)からの周知の送信制御プロトコル（ＴＣＰ）はそのようなプロトコルの一例であり、それは一連のセグメントに送信されるべきデータを配列する。
【０００４】
通常、個々のセグメントは、送信されるべく、所定のプロトコルによって定義される構造を有するデータユニットに配置される。これらのデータユニットは、異なるプロトコルに関して、パケットやフレームやプロトコルデータユニットやセル等のように異なる名前を持つ可能性がある。本願では、”データユニット”という文言は、あらゆるそのような定義されたデータ構造をもカバーするために一般的に用いられるものである。本願明細書では、”セグメント”という文言と”データユニット”という文言は置換可能なものとして用いられている。
【０００５】
送信局は、そのデータユニットを下位レイヤーに対して下り方向に送る。例えば、ＴＣＰ送信局はＴＣＰフレームをリンクレイヤーに伝え、受信局側では、受信局は下位レイヤー（Layers)からデータユニットを受信する。データユニットを定義する所定構造は、例えばセグメントの最初と最後を定義し、受信局が個々のセグメントを認識できるようにしている。
【０００６】
ＯＳＩレイヤーコンセプトに従えば、下位レイヤーに伝えられるデータユニットが、そこでどのように処理され、転送されようが問題ない。つまり、所定の送信局はビットストリームを下り方向に送信し、受信局はビットストリームを受信する。ここで、このビットストリームはフレーム境界インジケータのような所定の識別因数を含み、それによって受信局は個々のデータユニットや個々のセグメントを識別することができる。
【０００７】
データ送信の信頼性を確保するため、多くのプロトコルがデータユニット再送信の特徴を与えるが、これはシーケンスからのセグメントを必要に応じて再送することができることを意味するのである。通常、この特徴は確認応答（アクノレッジメント）技術のおかげで実現される。この確認応答技術とは受信局によるデータユニットの正確な受信が、受信局が送信局に返送する適切な確認応答メッセージで応答確認されることを意味するものである。いったん送信局がそのような確認応答メッセージを受信すると、さらにデータユニットを適切に送信しつづける。或いは、もし確認応答がないか、若しくは非確認応答メッセージが送信局側で受信されると、受信局で正確に受信できなかったデータユニットを送信局は再送することができる。
【０００８】
いくつかの周知技術のおかげで、送信局はデータユニット又はセグメントの喪失が起こったことのサイン（indication）を取得することになっていて、それで適切な再送信が実行される。そのような周知の技術の１つに、再送信タイムアウトがある。これは、データユニット送信後タイマーが監視され、当該データユニットに対する確認応答を受信せずに所定時間経過すると、データユニットは喪失されたと仮定されて当該データユニットが再送される。
【０００９】
他のそのような技術として、重複確認応答（Duplicate Acknowledgement）をカウントするものがある。重複確認応答は、以前に既確認応答されたデータセグメントを最新（最後）の正確に受信されたデータセグメントとして識別する確認応答技術である。即ち、例えばＴＣＰのような多くのプロトコルは、受信局用の確認応答発生メカニズム（手段）を有しており、その動作はシーケンスのうち各正確に受信したセグメントに対する確認応答メッセージを送出するようするものである。ここでは、その確認応答はシーケンスの順番において最新（最後）の正確に受信したデータセグメントを識別する。言い換えれば、例えば、第１番目から第４番目のセグメントが受信され、確認応答されて、その後第５のデータセグメントが到着する場合、受信局はその第５番目セグメントに対しての確認応答を送出するということである。その後、第７番目及び第８番目のセグメントが正確に到達すると、受信局は再度１又は２の確認応答メッセージを送出するが、これらの確認応答メッセージは第５番目セグメントを識別するだけである。なぜなら第５番目セグメントは、当該シーケンスの順番で正確に受信された最新（最後）のセグメントだからである。つまり、受信局は第６番目セグメントを期待しており、たとえ受信局が第６面目セグメントよりも上のセグメントを正確に受信しても、第５番目セグメントを確認応答することになるのである。従って、送信局による重複確認応答の受信によって、送信局はデータユニットが喪失されたというサインを受信することができる。
【００１０】
結局、上述の確認応答動作を用いるプロトコルでは、つまり、確認応答メッセージがシーケンスの順番で正確に受信できた最新（最後）のデータユニットを確認応答するのみであるという技術によれば、前記シーケンスにおいてさらに存在するデータユニットがたとえ受信されても、所定数の重複確認応答が送信局で受信されれば、再送信動作は実行されることになる。ＴＣＰでは、それに相当する動作は”高速再送信”として知られており、そこでは再送信は３つの重複確認応答受信後に実行される。ＴＣＰにおける高速再送信動作の詳細については、例えば、スティーブンス著書の上述の文献の２１．７章に示されている。
【００１１】
データユニットが失われたというサインを受信するための、上述のような全メカニズム（手段）には、送信局がデータユニット喪失の間接的なサインを受信するのみであるという問題点がある。実際に、所定のきっかけとなるイベントの発生（タイムアウト又は所定数の重複確認応答）は、データユニットが本当に失われたということを必ずしも意味するものではない。例えば、もしデータユニットが送信ネットワーク中で遅延している場合やシーケンス内のセグメントに関連する（複数の）データユニットがネットワークによって伝達されている間に、これらのきっかけとなるイベントは、また擬似的に生じされられる。そのような現象は、またリオーダーと呼ばれている。
【００１２】
タムラヨースケ（Yosuke Tamura）、トベヨシト（Yoshito Tobe）、トクダヒデユキ（Hideyuki Tokuda）による、ＸＰ−００２１１５０２８、”ＥＦＲ：ワイヤレスランにおけるＴＣＰ用再送信スキーム”において、新しい再送信スキームが提案されている。この論文は、送信ウインドウが小さいときに生じる問題点、つまり、そのときには送信されるべきセグメント数が少なすぎるため、受信機は高速再送信のきっかけのために必要とされる３つの重複確認応答を送信しないであろうということに言及している。この場合、高速再送信は不可能であり、送信機は再送信タイムアウトが起こるまで待機することになる。この状況に対する解決策として、最初の重複確認応答受信時に送信機は送信ウインドウサイズに依存する重複確認応答閾値を計算するということが提案されている。そのアルゴリズムは、まず、バイトサイズで与えられる送信ウインドウ値を、最大セグメントサイズでウインドウサイズを除算することによって、セグメント数を反映する値に変換する。そしてその結果から、重複確認応答閾値を決定するために、２が減算される。算出された閾値が３より大の場合には、閾値は自動的に３に設定される。それゆえに、重複確認応答閾値は、１、２、又はせいぜい３に設定されることになる。
【非特許文献１】
TCP/IP Illustrated Volume 1, The Protocols（１９９４）
【発明の開示】
【発明が解決しようとする課題】
【００１３】
本発明は、送信局におけるセグメントの再送信を処理するための可能性を一般的に改善するためになされたものである。
【００１４】
発  明  の  概  要
この本発明の目的は、請求項１の特徴をもつ方法、及び請求項２２の通信装置によって解決される。利点のある実施形態は、従属請求項において記述されている。
【００１５】
本発明によれば、所定数の重複確認応答メッセージの受信が、重複応答において識別されるデータセグメントに続く（次の）データセグメント再送信のきっかけとなるシステムにおいて、この所定数が３より大の値を想定する適応的パラメータであると決めることが提案される。これは、重複確認応答閾値がデータセグメント送信を取り巻く一般的条件、例えば送信局の条件や送信条件（セグメントが送信されているリンクや、セグメントが送信されている送信ネットワークによって一般的に決定される例に関して言えば）や、受信局の条件に適用可能なパラメータであることを意味する。
【００１６】
本発明は、セグメントが送信されてる通信プロトコルが上述の確認応答メカニズム（手段）を提供する限り、どんなタイプのフロー制御に関連しても実現することができることに注意すべきである。ここで、上述の確認応答動作によれば、確認応答メッセージはデータセグメントの正確な受信を示し、適切な順序のシーケンスで受信された最新（最後）の正確に受信されたシーケンスのデータセグメントを識別するものであり、この動作は、同一データセグメントを識別する閾値数の確認応答メッセージが送信局によって受信された場合に当該データセグメントが再送信されるというものである。
【００１７】
前記重複確認応答閾値を適応的にしたり、３より大の値と想定できるようにすることによって、送信局が送信するセグメントの柔軟性と制御性を非常に増大することができる。即ち、重複確認応答閾値は、どの位の期間送信局が重複確認応答メッセージを単にデータユニットリオーダ（reordering：順序変更）によるものであるとみなすであろうか、またいつ送信局がデータユニットが失われたかと想定するか、についてのサイン（indication)を与えるものである。つまり、重複確認応答閾値までは再送信は起こらず、最初の重複確認応答メッセージはリオーダ（reordering：順序変更）によるものと想定される一方、重複確認応答閾値に達するとデータユニットの喪失が発生したと想定される。
【００１８】
それゆえ、重複確認応答閾値は、重複確認応答が受信されているセグメントが失われたと想定されるまでどの位の期間待機するかについての送信局の決定に関連するパラメータである。本発明の解決策によって、閾値は適応的であり、３より大であると想定されているので、たとえ大多数のセグメントが送信されても、この送信局の決定を適応的で、よってより柔軟的にすることができる。
【００１９】
このように、本発明の方法は、たとえ大多数のセグメントが同時に送られうる場合であっても、セグメントリオーダ（reordering：順序変更）を処理するのにより適したものとなる。これによれば、リオーダは起こりやすいものであるので、本発明は、プロトコル実行に対して上位にあるデータユニットの伝送失敗を許容する下位レイヤ上を起動する当該プロトコル実行に有益的に適用される。
【００２０】
上記一般的条件に対する上記閾値数は、どんな適切な又は所望の方法でも適応されうるものである。例えば、送信局と受信局との間の接続の特徴は測定することができ、その閾値数はそのような測定された特徴に適応させることができる。好ましくは、そのような測定は送信局によって実行される。また、上記決定はその接続の、所望で測定可能な特徴の１以上に関して行われる。そのような特徴として、変動量（例えばエラーレートについて）、平均伝送時間、遅延などが挙げられる。例として、重複確認応答閾値を伝送エラーレートに、エラーレートが増加すると重複確認応答閾値が低くなる又はその逆になるように適応させることが可能である。より具体的には、初期エラーレート値に対して定められた所定の初期閾値から始まり、所定インクリメントに分のエラーレートの増加は、所定インクリメントによる、対応する閾値の低下につながるものである。当然、特定の値（閾値）は個々のアプリケーションや要求度によるものである。
【００２１】
好ましい実施例によれば、重複確認応答閾値は、フロー制御に関連する所定のグループに属するデータセグメントの変数に基づいて適応される。
【００２２】
また、好ましい実施例によれば、重複確認応答閾値は未確認応答のデータユニット数に基づいて適応される。ここで未確認応答のデータユニットとは、送信局によって送信されたが、送信されているシーケンスのうちで最新（最後）の正確に受信されたデータユニット（データセグメント）としてまだ確認応答処理されていないデータユニットをいう。未確認応答のデータユニット数はどの程度リオーダーが可能か、例えば、下位レイヤー効果、について示すので、重複確認応答閾値を未確認応答のデータユニット数に基づいて適応することは有益的である。
【００２３】
ウインドウベースのフロー制御を用いるシステムに対する、別の好ましい実施例によれば、重複確認応答閾値はまた、１以上の制御ウインドウに基づいて適応することができる。一種の輻輳ウインドウ（例えばＴＣＰから知られているもの）を用いるシステムにおいては、その輻輳ウインドウ（Congestion Window）に基づいて、例えばその割合として重複確認応答閾値を得ることが好ましい。また、輻輳ウインドウ（Congestion Window）は、未確認応答のデータユニット数に対する指標となるものである。しかしながら、たとえウインドウベースのフロー制御を用いるシステムにおいても、未確認応答のデータユニット数に基づいて重複確認応答閾値を直接適応させることも可能であることに注意すべきである。
【００２４】
さらに、重複確認応答閾値は１以上のパラメータに基づいて適応させることができ、上述のタイプや例のパラメータは、個別的に、又は、重複確認応答閾値を適応させるための任意の組み合わせに用いることができる。
【００２５】
上記重複確認応答閾値の適応又は更新は如何なる適切な若しくは所望の方法ででも実行することができ、また、それは、どのパラメータ（単一又は複数）が上記適応の基礎(根拠）として用いられるかに依存している。例えば、一様の間隔において重複確認応答閾値を更新することができる。言い換えれば、重複確認応答閾値を適応するための基礎（根拠）としてのパラメータ（単一又は複数）は、一様に測定される。また、その閾値はこれらの測定に基づいて一様に更新される。一方、重複確認応答閾値の更新は所定のきっかけとなるイベントの発生時にのみ実行されるということも可能である。そのきっかけとなるイベントは適切又は所望なものとして、例えば、重複確認応答の最初の受信時、重複確認応答の受信ごと、又は、重複確認応答閾値が適応される基礎(根拠）となる関連パラメータ（単一又は複数）が変化する度に、選択されるようにできる。
【００２６】
さらに別の可能性として、重複確認応答はまた、確認応答毎（即ち、重複確認応答の受信時だけではなく）や未確認応答のデータユニットやセグメントに関連する確認応答毎に、更新することができる。
【発明を実施するための最良の形態】
【００２７】
本発明は、送信されるべき所定量のデータが複数のデータセグメントに分割され、そのデータセグメントが所定のシーケンスで並べられている、所定の通信プロトコルについての如何なる態様にも適用されうるものである。ここで、受信局は送信局に確認応答を送信するが、その確認応答は上記シーケンスの適切な順序で正確に受信できたことを示すものであり、確認応答メッセージは上記適切な順序のシーケンスで受信された、最新（最後）の正確に受信できた上記シーケンスのデータセグメントを示すものとなっている。また、ここで、送信局が、適切な順序で受信されたセグメントの、最新（最後）の正確に受信できたセグメントのデータセグメントと同じデータセグメントをそれぞれ識別する所定閾値数の確認応答メッセージを受信した場合、重複確認応答が受信されたセグメントに直ちに続くセグメントが再送信される。
【００２８】
そのようなプロトコルの具体例はＴＣＰである。しかしながら、本発明は、上述の特徴を有する、他のあらゆる通信プロトコルにも適用可能であることに注意されたい。
【００２９】
本発明によれば、所定閾値数の確認応答メッセージ、即ち重複確認応答閾値は、３より大きい値を想定しているものと思われる適応的パラメータである。
【００３０】
従って、既述したように、重複確認応答閾値は重複確認応答を受信中の所定のセグメントが失われたと想定されるまでどの位の時間待機するかについての送信局の決定と関連するパラメータである。本発明に対する、閾値が適応的にされるという解決方法によれば、上記決定自身を適応的にして、それによってよりフレキシブルにすることができる。
【００３１】
図１は、本発明の実施例を説明するフローチャートである。フローチャートの左側は一般的なフロー制御に関するものであり、本発明が一般的なフロー制御とは無関係であることに鑑みて、左側は点線として単に模式的に表されている。図１の右側は重複確認応答を処理するための手順を開示している。即ち、一般的フロー制御の最中に確認応答（ＡＣＫ）が受信された場合、ステップＳ１を参照すると、重複確認応答処理が始まる。
【００３２】
ステップＳ２において、確認応答が重複確認応答か否かが判断される。即ち、シーケンスのうち適切な順序で受信されたシーケンスの、最新（最後）の正確に受信されたデータセグメントを識別する特定の確認応答の受信回数Ｎが判断され、このＮが１より大きいかどうか判断される。Ｎが１以下の場合は、ＡＣＫは重複ＡＣＫではなく、処理は一般的フロー制御に戻る。
【００３３】
ステップＳ２の結果が、確認応答が重複確認応答であると示している場合、処理はステップＳ３に移行し、そこで、Ｎ（ＡＣＫ）が重複確認応答閾値Ｔｈより大きいかどうか判断される。
【００３４】
このステップは如何なる適切な方法ででも実現可能である。例えば、最新（最後）の確認応答されたセグメントの記録を単に取って、関連のカウンタを設定する。そうすると、新たに次に受信した確認応答が先の確認応答（即ち、重複確認応答）と同一の場合にはカウンタが１つインクリメントされ、新しい確認応答が、最新（最後）の受信された確認応答の中で識別されるセグメントに後のセグメントを識別する場合、カウンタは１にリセットされる。
【００３５】
図１の例では、Ｎ（ＡＣＫ）は、送信局が所定の確認応答ＡＣＫを受信した回数を示している。言い換えれば、Ｎ＝１は所定のセグメントに対する確認応答が初めて受信されたことを意味し、Ｎ＞１はその確認応答が重複確認応答であることを示している。
【００３６】
ステップ３で、確認応答の数が所定の閾値に達していないと判断されると、処理は一般的フロー制御に戻る。しかしながら、その閾値に達しているか超過している場合には、処理はステップＳ４に移行し、そこで、受信された重複確認応答の数が現在設定されている重複確認応答閾値Ｔｈに等しいか判断される。等しい場合には、最も古い確認応答されていないセグメントがステップＳ５で再送信される。その最も古い確認応答されていないセグメントは、重複確認応答において識別されるセグメントに直ちに続くものである。一方、ステップＳ４の結果がＮｏの場合、即ちＮ（ＡＣＫ）＜Ｔｈの場合、重複確認応答において識別されるセグメントに直ちに続くセグメントの次のセグメントが送信される。
【００３７】
ステップＳ５又はＳ６の後、処理は再び一般的フロー制御に戻る。
【００３８】
図１の実施例は単に一例であって、この例は色々な方法で可変的に適用される。当業者であれば、上記ステップもまた異なる配列であってもよいことは理解できるであろう。さらに、ステップＳ６は、本発明は重複確認応答閾値を超えた後の処理には特に関係ないので、単に具体例を示したものである。言い換えれば、重複確認応答閾値を超えた後の処理は適切であればどんな方法でも選択でき、ここでは、ＴＣＰのようなプロトコルに対する色々な可能性がさらに後述されている。
【００３９】
同様に、重複確認応答に対する、一般的フロー制御における応答（レスポンス）は、本発明にとって本質ではない。例えば、ステップＳ３の結果がＮｏであった場合の後、即ち、重複確認応答が受信された場合であるが重複確認応答の数が所定の閾値に達していない場合、一般的フロー制御ではさらにセグメントを送ることを止めるか、又は、さらにセグメントを同様に送り続けることも可能である。
【００４０】
重複確認応答閾値は、適切であればどんな方法ででも更新することができる。例えば、その閾値を適応させるために用いられる１つ以上の値（one or more values）に基づいて、その閾値は定期的間隔において更新可能である。言い換えれば、これら１つ以上の値は定期的に評価（measure）されるか、判定されるものであり、閾値Ｔｈはそれに従って更新される。この処理は、図１で示されるものの外で、独立した処理として行われる。従って、この独立した処理は、適当に格納されたＴｈの値を定期的に更新するものであり、ステップＳ３やＳ４は単に、Ｔｈの現在値にアクセスまたは呼び出しているだけである。一方、所定のきっかけとなるイベントの発生時にＴｈを更新することも可能である。１つの可能性として、Ｔｈを適応させるために用いられる１つ以上の値の１つ以上が変わる場合のみ、Ｔｈを更新することが含まれる。そのような処理も、図１に示されるものとは独立したものであり、ステップＳ３やＳ４は単にＴｈの現在値にアクセスまたは呼び出しているに過ぎない。
【００４１】
しかしながら、特定のきっかけイベントはまた、図１に示される処理の一部である。即ち、確認応答の受信に関連するきっかけイベント発生時にＴｈ更新を実行することが可能である。例えば、Ｔｈは重複ＡＣＫの最初の受信時毎に更新可能である。これは図２ａに示されており、ここで、図１で用いられているものと同じ参照番号は同じステップについて言及している。言い換えれば、図２ａで示されるステップ２２と２３は、図１のステップＳ２とＳ３との間で実行される。ステップＳ２において、重複確認応答が受信されたと判定された後、ステップ２１において、重複確認応答が最初のものであるか、つまり、Ｎ（ＡＣＫ）＝２であるか判断される。その場合（Ｎ＝２）には、Ｔｈはステップ２２で更新される。ステップ２１又は２２の後、ステップＳ３が実行される。図１との関係で既に議論した他の全てのステップについては更なる議論は必要ないものである。
【００４２】
また、重複確認応答毎にＴｈの更新を実行することも可能である。これは図２ｂに示されている。即ち、更新ステップＳ２２はステップＳ２の後に続くものであり、全ての重複確認応答はＴｈの更新につながっている。
【００４３】
別の変形例として、図示されてはいないが、閾値Ｔｈはまた、確認応答毎に更新してもよい。言い換えれば、更新ステップＳ２２は、図１のステップＳ１とＳ２との間で実行される。別の例では、未確認応答のデータセグメントに関係するＡＣＫ毎に、即ち、Ｎ（ＡＣＫ）＝１の確認応答に対してのみ、閾値Ｔｈを更新するようにしてもよい。従って、更新ステップは、図１のステップＳ２の結果がＮｏであるときに実行されうるものである。
【００４４】
上述のように、重複確認応答閾値Ｔｈの更新は、適切又は望まれるときであればいつでも行うことができる。同様に、適切であればどんな根拠によっても実行することができる。重複確認応答閾値の現在値は、送信局と受信局との間の接続の特徴に関してなされる評価（measurements）に基づいて判定されるのが好ましい。そのような評価（measurements）はどのポイントでも、即ち、送信局、及び／又は送信局と受信局間のネットワーク、及び／又は受信局において、実行することができるが、好ましくは、送信局側で行われるのが良い。
【００４５】
重複確認応答閾値の値は適切であればどんな特徴又はパラメータに基づいても適応可能であるが、送信中のデータセグメントのフロー制御に関連した可変パラメータに基づいて適応するのが好ましい。送信中のデータセグメントのフロー制御に関連したそのようなパラメータは、所定のカテゴリ又はグループにおけるデータセグメントの数、例えばウインドウベースのフロー制御を用いるシステムの場合の所定の送信ウインドウにおけるデータユニットの数、とすることができ、又は、未確認応答（outstanding）のデータユニットの数ともすることができる。未確認応答のデータユニットとは、送信局によって送られたデータセグメント又はデータユニットであるが、送信局が確認応答メッセージを未受信のものをいう。ここで、その確認応答メッセージは、適切な順序で受信された、シーケンス中の最新（最後）のセグメントととして上記データユニット又はセグメントを識別するものである。
【００４６】
重複確認応答閾値がセグメント数に基づいて決定される場合には、例えば送信ウインドウのように、それは未確認応答のセグメント数又は所定のグループにおけるセグメント数である。そして、その重複確認応答は、好ましくは、データユニット数の所定の割合（Fraction）として決定される。例えば、この割合は１／２である。言い換えれば、そのグループ中のセグメント数は、所定のファクター、例えば２で除算される。
【００４７】
これは、閾値が送信ウインドウ内のセグメント数から定数を減算するという、タムラ他によって提案されたアルゴリズムと非常に異なる点である。
【００４８】
本発明が適用されるプロトコルが送信制御プロトコル（ＴＣＰ）である場合、重複確認応答閾値は輻輳ウインドウ（Congestion Window）の所定の割合、例えば１／２として決定されうる。１／３と２／３の間であればどんな割合でも適切なものである。送信ウインドウ、より具体的には輻輳関連ウインドウの所定の割合を用いる本発明の実施例は、ＴＣＰには限定されないことに注意されたい。そのような適用は、ウインドウベースで、かつ輻輳関連送信ウインドウを用いるいかなるプロトコルに関連して可能だからである。より具体的には、輻輳関連送信ウインドウというのは、送信局が所定の初期サイズに初期化し、そして受信局から受信した確認応答メッセージや、重複確認応答、再送信タイムアウト、非確認応答メッセージ、ネットワークからの直接輻輳表示メッセージ（direct congestion indication messages）等のイベントを示す輻輳の発生、によってサイズを制御するウインドウである。すなわち、確認応答受信の際に、輻輳ウインドウのサイズは増加し、輻輳表示イベントの発生の際に、輻輳ウインドウのサイズは減少する。
【００４９】
整数値である重複確認応答閾値がウインドウサイズに基づいて、又はより一般的には所定のカテゴリに属するデータユニット数に基づいて決定される上記実施例に対して、重複確認応答閾値の計算は、特定のプロトコル或いはプロトコル実行がデータセグメントを把握しているメカニズムに、また、どのようにそのようなウインドウやグループが表現されるかに、依存している。すなわち、プロトコルがセグメント志向の場合、つまりセグメントが連続数を有し、それで識別され、そしてウインドウもまた直接そのようなセグメント数として決定されることを意味している場合には、割合の計算は、単に、与えられた値を所定の分母や因数、例えば上述のように所定の割合が１／２なら２、で除算することにある。しかしながら、ＴＣＰのような多くのプロトコルは、バイト志向、つまりセグメントは直接番号化されていないが、それどころかバイトカウントによって参照されるようにされることを意味するものである。より具体的には、送信すべきデータ量がＫバイトからなるとすれば、各セグメントはバイトカウントｋｉ、ここでｋｉ＜Ｋかつｋｉ＜ｋｉ＋１、によって識別されることになる。例えば、送信すべきデータ量が１０２４０バイトからなる場合、このデータ量は１０セグメントに分割され、各セグメントは１０２４バイトのデータを有することになる。第１番目セグメントは１０２４、第２番目セグメントは２０４８、第３番目セグメントは３０７２、等で記述される。結果として、確認応答メッセージはそのようなバイトカウントを通信することによりセグメントを識別する。さらに、ウインドウベースのフロー制御を用いるバイト志向プロトコルでは、ウインドウサイズもバイトで表現される。そのようなバイト志向プロトコルは周知であるので、ここではさらに詳細な説明は省略する。
【００５０】
そのようなバイト志向プロトコルに対して、整数値である重複確認応答閾値の決定は、関連バイト値を除算することによってなされる。その関連バイト値に基づいて、閾値は所定の分母又は因数（所定の割合が１／２なら２）やバイト値をセグメント数に変換するための適切なセグメント変換サイズによって適応される（例えば、送信ウインドウサイズ又は未確認応答データユニット数のようなデータユニット数）。通常、このセグメント変換サイズは、最大セグメントサイズ（例えば、セグメントが想定する、バイトでの最大値）である。最大セグメントサイズは、上述の工程に対して特に定義され、例えば、最大セグメントサイズは最初に、初期重複確認応答閾値と共に設定される。或いは、本発明が適用されるプロトコルが既にそのような最大セグメントサイズをパラメータとして、ＴＣＰの場合のように、有している場合には、この有用なパラメータは直接用いることができる。
【００５１】
上述の両方の場合、即ち、整数セグメント数を直接除算する場合或いはバイト数を除算し、セグメント変換パラメータを用いる場合には、その除算の結果が整数でない可能性があることに注されたい。この場合、重複確認応答閾値は、直ぐ上の整数或いは直ぐ下の整数に適切な丸め演算を行うことによって決定されうるのである。
【００５２】
図４ａ−４ｃのグラフは、確認応答到着に関してのウインドウサイズを示しており、ここでは、黒点は確認応答の到着を表している。縦軸は、最大セグメントサイズの倍数について表されている。
【００５３】
ここでは、ＴＣＰのように動作するプロトコル実行に対する本発明の適用例について説明する。図４ａは、ウインドウサイズの調整について、ＴＣＰにおいて特定される様に重複確認応答の従来の管理動作を示している。より具体的には、例えばスティーブンスによる上記書籍の２１．７章に記述されているように、ＴＣＰは、第３番目の重複確認応答を受信した後再送信を実行するように準備され、また、再送信後、輻輳ウインドウｃｗｎｄは、図４ａにおいて第３番目の重複確認応答の受信し、そしてそのセグメントサイズを結果に３回加算した時にウインドウサイズの１／２として決定される、いわゆるスロースタート閾値サイズｓｓｔｈｒｅｓｈに設定される。そして、その輻輳ウインドウｃｎｗｄは、さらなる確認応答の到着に応じて線形的に増加する。結果として、第３番目の重複確認応答の受信時におけるウインドウサイズが非常に大きい場合には、１／２にし、結果として得られるウインドウに３セグメントサイズを加算することによるウインドウサイズの減縮によって、ウインドウサイズは大きく減縮されるということが分かる。従って、ウインドウが再送信前に有していたサイズに到達するにはある程度時間が掛かるであろう。
【００５４】
図４ｂは、本発明が適用される例を示している。つまり、重複確認応答閾値は従来のＴＣＰ（図４ａ参照）とは異なり３の値には固定されず、また、タムラ他による上述の論文とも異なり、３の最大値にも制限されない。しかし、それは、現在の輻輳ウインドウに基づいて決定される。図４ｂの例では、現在の輻輳ウインドウは１１倍、最大セグメントサイズである。より具体的には、その閾値は、この輻輳ウインドウサイズの１／２で、それが非整数値の場合には切り下げられるものとして決定される。１１がウインドウサイズのときは、１／２したことによって、５．５の非整数値になった場合には重複確認応答閾値は５に設定される。これから分かるように、この結果は３を超えるものである。従って、５番目の重複確認応答を受信した後、再送信が行われる。図４ｂの例に従って、輻輳ウインドウは従来の場合のように、ｓｓｔｈｒｅｔｈに、即ち、再送信時の輻輳ウインドウの１／２に減縮される。しかしながら、その後、重複確認応答閾値の値は、その結果に、即ち、図４ｂの例では５に、加算される。再送信時の輻輳ウインドウサイズが偶数値の場合、この処理は輻輳ウインドウが同サイズで残っていることを意味するものである。輻輳ウインドウが本例における最大セグメントの非偶数倍に相当するサイズを有するので、輻輳ウインドウサイズは再送信前の値、つまり図４ｂの例における１０．５よりもわずかに小さい値に戻るものである。
【００５５】
好ましくは、輻輳ウインドウサイズの制御は、再送信処理から切り離される。その処理は図４ｃで示されるように進行する。即ち、閾値数の重複確認応答を受信後（図４ｃの例では、図４ｂのようにＴｈの値は５に等しい）、輻輳ウインドウサイズは不変のままであり、さらに確認応答を受信した後はその輻輳ウインドウサイズは、例えば、ＴＣＰから周知の輻輳回避アルゴリズムに従って、線形的に増加する。
【００５６】
図４ａに示される場合及びタムラ他の従来技術に関して、図４ｂ及び４ｃに示される実施例の利点は、輻輳ウインドウが３よりかなり大きいサイズに到達できる場合により顕著となる。このことは、データユニットが送信されている送信ネットワークが、大きい容量、例えばユニバーサルモバイルテレフォンシステム（ＵＭＴＳ）スタンダードに従って動作するシステムの場合に期待できるのである。従って、本発明は、好ましくは、そのような高データレートリンクを供給するリンクレイヤプロトコル上で動作するプロトコルに関連して適用されるものである。言い換えれば、Ｌ４層が実行されるリンクレイヤＬ２がＵＭＴＳネットワークのような高バンド幅送信ネットワークに関連したレイヤであるときは、本発明の方法を、ＯＳＩスタンダードではＬ４と言われるトランスポート層に、適用するのが好ましい。本発明の方法はリオーダを扱うことができるので、Ｌ４以下の低プロトコル層が、リオーダが起こりやすい場合である、限度を越えてＬ４データユニットをリリースすることができるような方法で、実施される場合、本発明は特に、利点がある。
【００５７】
ここで、従来例及び本発明適用時の両方に対して、送信局と受信局との間でのセグメント及び対応確認応答の交換の具体例が、図３ａ及び３ｂを参照して説明される。より具体的には、図３ａは、送信機が整数の変数ｎによって参照されるセグメントを受信機に送る場合を示している。図３ａの例において、セグメントｎが送られて確認応答される。ここで、セグメントｎ＋１は送信中に失われている。結果として、受信機は、セグメントｎ＋２、ｎ＋３等を正しく受信したが、適切な順序のシーケンスで受信された最新（最後）の正確に受信したシーケンス中のデータセグメントとしてセグメントｎを確認応答するだけである。既に述べたように、図３ａは標準的なＴＣＰの従来技術の状況を示している。ここで、再送信が、第３番目の重複確認応答の受信後に行われる。セグメントｎ＋１の再送信が太線矢印によって示されている。再送信されたセグメントｎ＋１を正しく受信した後、送信機は適切な順序のシーケンスで受信された最新（最後）の正確に受信したシーケンス中のデータセグメントとしてセグメントｎ＋１１を確認応答する。
【００５８】
図３ｂは、図３ａと同じ初期状態を示しているが、本発明が適用され、重複確認応答閾値が輻輳ウインドウサイズに基づいて、即ち、この輻輳ウインドウサイズ（最大セグメントサイズの倍数で決定される）の１／２として、決定される。重複確認応答閾値は、それ故、特定値（標準的なＴＣＰの場合のような）には限定されず、特定の最大値（タムラ論文の場合のような）にも限定されない。図３ｂの例では、輻輳ウインドウサイズは１０又は１１とみなされ、そして重複確認応答閾値は５である。結果として、状況が図３ｂに示される場合、即ち、第５番目の重複確認応答が送信機側に到達する場合に、送信機はセグメントｎ＋１を再送信するまでΔＴだけ長い期間待機する。一方、セグメントｎ＋１が実際に失われておらず、ただ遅延している場合で、そして、それ（セグメントｎ＋１）が図３ｂに示される時間ΔＴ中に到達する場合には、セグメントｎ＋１の正確な受信は、重複確認応答の閾値にこの場合達していないので、再送信が送信機側で起こる前に確認応答されることになる。
【００５９】
本発明の方法は、適切であれば如何なる方法ででも実施することができ、特に、コンピュータプログラムの形でも実現でき、従って、そのようなコンピュータプログラムを実行する記憶媒体の形ででも実現できる。同様に、本発明は、本発明の方法に従って動作するようになされた通信装置の形で実現可能である。
【００６０】
本発明は詳細な実施例によって説明されてきたが、本発明はこれらの実施例に限定されるものではなく、添付の特許請求の範囲によって定義されるものである。また、特許請求の範囲中の参照番号は、特許請求の範囲を読みやすくするためのものであり、権利範囲を制限的に理解するようにするためのものではない。
【図面の簡単な説明】
【００６１】
本発明の更なる側面および利点は、発明の詳細な実施例の検討からより速やかに明らかになるものであり、その実施例の記載は添付の図面を参照して以下のようになされている。
【図１】図１は、本発明の実施例のフローチャートである。
【図２ａ】図２ａは、重複確認応答閾値に対する可能性ある更新手続に関連するフローチャートである。
【図２ｂ】図２ｂは、重複確認応答閾値に対する他の可能性ある更新手続に関連するフローチャートである。
【図３ａ】図３ａは、従来技術に従って動作する送信局と受信局との間のデータユニットと確認応答メッセージの交換処理を示す図である。
【図３ｂ】図３ｂは、本発明の実施例に従って動作する送信局と受信局との間のデータユニットと確認応答メッセージの交換処理を示す図である。
【図４ａ】図４ａは、ウインドウベースのフロー制御を用い、従来技術に従って動作するシステムにおける、送信ウインドウサイズとＡＣＫ到達時間との関係を示す図である。
【図４ｂ】図４ｂは、ウインドウベースのフロー制御を用い、本発明の実施例に従って動作するシステムにおける、送信ウインドウサイズとＡＣＫ到達時間との関係を示す図である。
【図４ｃ】図４ｃは、ウインドウベースのフロー制御を用い、本発明の別の実施例に従って動作するシステムにおける、送信ウインドウサイズとＡＣＫ到達時間との関係を示す図である。
【図１】
2004523992.tif 000003
【図２ａ】
2004523992.tif 000004
【図２ｂ】
2004523992.tif 000005
【図３ａ】
2004523992.tif 000006
【図３ｂ】
2004523992.tif 000007
【図４ａ】
2004523992.tif 000008
【図４ｂ】
2004523992.tif 000009
【図４ｃ】
2004523992.tif 000010
【国際公開パンフレット】
2004523992.tif 000011
2004523992.tif 000012
2004523992.tif 000013
2004523992.tif 000014
2004523992.tif 000015
2004523992.tif 000016
2004523992.tif 000017
2004523992.tif 000018
2004523992.tif 000019
2004523992.tif 000020
2004523992.tif 000021
2004523992.tif 000022
2004523992.tif 000023
2004523992.tif 000024
2004523992.tif 000025
2004523992.tif 000026
2004523992.tif 000027
2004523992.tif 000028
2004523992.tif 000029
2004523992.tif 000030
2004523992.tif 000031
2004523992.tif 000032
2004523992.tif 000033
2004523992.tif 000034
2004523992.tif 000035
2004523992.tif 000036
2004523992.tif 000037
2004523992.tif 000038
2004523992.tif 000039
2004523992.tif 000040
2004523992.tif 000041
2004523992.tif 000042
2004523992.tif 000043
2004523992.tif 000044
2004523992.tif 000045
2004523992.tif 000046
【手続補正書】
【提出日】平成15年9月29日(2003.9.29)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００１２
【補正方法】変更
【補正の内容】
【００１２】
タムラヨースケ（Yosuke Tamura）、トベヨシト（Yoshito Tobe）、トクダヒデユキ（Hideyuki Tokuda）による、ＸＰ−００２１１５０２８、”ＥＦＲ：ワイヤレスランにおけるＴＣＰ用再送信スキーム”において、新しい再送信スキームが提案されている。この論文は、送信ウインドウが小さいときに生じる問題点、つまり、そのときには送信されるべきセグメント数が少なすぎるため、受信機は高速再送信のきっかけのために必要とされる３つの重複確認応答を送信しないであろうということに言及している。この場合、高速再送信は不可能であり、送信機は再送信タイムアウトが起こるまで待機することになる。この状況に対する解決策として、最初の重複確認応答受信時に送信機は送信ウインドウサイズに依存する重複確認応答閾値を計算するということが提案されている。そのアルゴリズムは、まず、バイトサイズで与えられる送信ウインドウ値を、最大セグメントサイズでウインドウサイズを除算することによって、セグメント数を反映する値に変換する。そしてその結果から、重複確認応答閾値を決定するために、２が減算される。算出された閾値が３より大の場合には、閾値は自動的に３に設定される。それゆえに、重複確認応答閾値は、１、２、又はせいぜい３に設定されることになる。
コメント２８８３（ＸＰ−００２１７３９２３）に対するリクエストは、ＴＣＰ用選択的確認応答（ＳＡＣＫ）オプションへの拡張について記述している。この拡張は、重複セグメント（Ｄ−ＳＡＣＫ）にある。ＲｆＣ２８８３は、研究課題として、Ｄ−ＳＡＣＫを用いて送信機にいついわゆる高速再送信がパケット喪失の変わりにパケットリオーダ（reordering：順序変更）に起因したかを判断させる可能性を示している。そして、不必要な高速再送信を避けるために、送信機に重複確認応答閾値を調節させることが示唆されている。
Ｌ．ウッド他（L.Wood et al）による論文、”衛星群におけるルーティング戦略のＴＣＰへの効果、ＩＥＥＥ通信雑誌、２００１年３月発行（ＸＰ−００２１７３９２２）”は、スループットを増加させるために、マルチパス状況下において、３より高い値に重複確認応答閾値を設定する可能性について記述している。


【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１４
【補正方法】変更
【補正の内容】
【００１４】
発  明  の  概  要
この本発明の目的は、請求項１の特徴をもつ方法、及び請求項１５の通信装置によって解決される。利点のある実施形態は、従属請求項において記述されている。


【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００２０
【補正方法】削除
【補正の内容】
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００２１
【補正方法】削除
【補正の内容】
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００２２
【補正方法】変更
【補正の内容】
【００２２】
また、本発明によれば、重複確認応答閾値は未確認応答のデータユニット数に基づいて適応される。ここで未確認応答のデータユニットとは、送信局によって送信されたが、送信されているシーケンスのうちで最新（最後）の正確に受信されたデータユニット（データセグメント）としてまだ確認応答処理されていないデータユニットをいう。未確認応答のデータユニット数はどの程度リオーダーが可能か、例えば、下位レイヤー効果、について示すので、重複確認応答閾値を未確認応答のデータユニット数に基づいて適応することは有益的である。


【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００２３
【補正方法】削除
【補正の内容】
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００２４
【補正方法】変更
【補正の内容】
【００２４】
さらに、重複確認応答閾値は１以上のパラメータに基づいて適応させることができ、未確定の（未確認応答の）データユニット数に加えて、以下に述べるタイプや例のパラメータは、個別的に、又は、重複確認応答閾値を適応させるための任意の組み合わせに用いることができる。
例えば、送信局と受信局との接続関係の特徴は、評価（measure）可能であり、閾値数はそのような評価された特徴に適応可能である。好ましくは、そのような評価は送信局によって行われる。その判定は、外乱量（例えばエラーレートに関して）、平均送信時間、遅延等のような所望で評価可能な接続関係の特徴のうち、どんな１以上の特徴に関しても行うことができる。一例として、エラーレートが増加する場合に重複確認応答閾値が低くなるように又はその逆になるように、重複確認応答閾値を送信エラーレートに適応させることができる。より具体的には、初期エラーレート値のために決定される所定の初期閾値から始めると、所定の増分（インクリメント）に相当するエラーレートの増加は、対応した、所定増加分により閾値を低くすることにつながりうるのである。当然、特定の値は個別のアプリケーションや要件によるものであろう。
ウインドウベースのフロー制御を用いるシステムに対する、別の好ましい実施例によれば、重複確認応答閾値はまた、１以上の制御ウインドウに基づいて適応することができる。一種の輻輳ウインドウ（例えばＴＣＰから知られているもの）を用いるシステムにおいては、その輻輳ウインドウ（Congestion Window）に基づいて、例えばその割合として重複確認応答閾値を得ることが可能である。また、輻輳ウインドウ（Congestion Window）は、未確認応答のデータユニット数に対する指標となるものである。


【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】００４５
【補正方法】変更
【補正の内容】
【００４５】
重複確認応答閾値の値は、未確定（未確認応答）のデータセグメント数に基づいて適応される。送信中のデータセグメントのフロー制御に関連した可変パラメータに基づいて付加的に適応することができる。送信中のデータセグメントのフロー制御に関連したそのような付加的パラメータは、所定のカテゴリ又はグループにおけるデータセグメントの数、例えばウインドウベースのフロー制御を用いるシステムの場合の所定の送信ウインドウにおけるデータユニットの数、とすることができる。未確定（未確認応答）のデータユニットとは、送信局によって送られたデータセグメント又はデータユニットであるが、送信局が確認応答メッセージを未受信のものをいう。ここで、その確認応答メッセージは、適切な順序で受信された、最新（最後）の正確に受信されたシーケンス中のセグメントととして上記データユニット又はセグメントを識別するものである。


【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】００４６
【補正方法】変更
【補正の内容】
【００４６】
その重複確認応答は、好ましくは、未確認応答のデータユニット数の所定の割合（Fraction）として決定される。例えば、この割合は１／２である。言い換えれば、セグメント数が、所定のファクター、例えば２で除算される。


【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】００４８
【補正方法】変更
【補正の内容】
【００４８】
本発明が適用されるプロトコルが送信制御プロトコル（ＴＣＰ）である場合、重複確認応答閾値は輻輳ウインドウ（Congestion Window）の所定の割合、例えば１／２として、付加的に決定されうる。１／３と２／３の間であればどんな割合でも適切なものである。送信ウインドウ、より具体的には輻輳関連ウインドウの所定の割合を付加的に用いる本発明の実施例は、ＴＣＰには限定されないことに注意されたい。そのような適用は、ウインドウベースで、かつ輻輳関連送信ウインドウを用いるいかなるプロトコルに関連して可能だからである。より具体的には、輻輳関連送信ウインドウというのは、送信局が所定の初期サイズに初期化し、そして受信局から受信した確認応答メッセージや、重複確認応答、再送信タイムアウト、非確認応答メッセージ、ネットワークからの直接輻輳表示メッセージ（direct congestion indication messages）等のイベントを示す輻輳の発生、によってサイズを制御するウインドウである。すなわち、確認応答受信の際に、輻輳ウインドウのサイズは増加し、輻輳表示イベントの発生の際に、輻輳ウインドウのサイズは減少する。


【手続補正１１】
【補正対象書類名】明細書
【補正対象項目名】００４９
【補正方法】変更
【補正の内容】
【００４９】
整数値である重複確認応答閾値がウインドウサイズに基づいて、又はより一般的には所定のカテゴリに属するデータユニット数に基づいて付加的に決定される上記実施例に対して、重複確認応答閾値の計算は、特定のプロトコル或いはプロトコル実行がデータセグメントを把握しているメカニズムに、また、どのようにそのようなウインドウやグループが表現されるかに、依存している。すなわち、プロトコルがセグメント志向の場合、つまりセグメントが連続数を有し、それで識別され、そしてウインドウもまた直接そのようなセグメント数として決定されることを意味している場合には、割合の計算は、単に、与えられた値を所定の分母や因数、例えば上述のように所定の割合が１／２なら２、で除算することにある。しかしながら、ＴＣＰのような多くのプロトコルは、バイト志向、つまりセグメントは直接番号化されていないが、それどころかバイトカウントによって参照されるようにされることを意味するものである。より具体的には、送信すべきデータ量がＫバイトからなるとすれば、各セグメントはバイトカウントｋｉ、ここでｋｉ＜Ｋかつｋｉ＜ｋｉ＋１、によって識別されることになる。例えば、送信すべきデータ量が１０２４０バイトからなる場合、このデータ量は１０セグメントに分割され、各セグメントは１０２４バイトのデータを有することになる。第１番目セグメントは１０２４、第２番目セグメントは２０４８、第３番目セグメントは３０７２、等で記述される。結果として、確認応答メッセージはそのようなバイトカウントを通信することによりセグメントを識別する。さらに、ウインドウベースのフロー制御を用いるバイト志向プロトコルでは、ウインドウサイズもバイトで表現される。そのようなバイト志向プロトコルは周知であるので、ここではさらに詳細な説明は省略する。


【手続補正１２】
【補正対象書類名】明細書
【補正対象項目名】００５４
【補正方法】変更
【補正の内容】
【００５４】
図４ｂは、本発明には属さない例を示しており、ここでは、重複確認応答閾値は従来のＴＣＰ（図４ａ参照）とは異なり３の値には固定されず、また、タムラ他による上述の論文とも異なり、３の最大値にも制限されない。しかし、それは、現在の輻輳ウインドウに基づいて決定される。図４ｂの例では、現在の輻輳ウインドウは１１倍、最大セグメントサイズである。より具体的には、その閾値は、この輻輳ウインドウサイズの１／２で、それが非整数値の場合には切り下げられるものとして決定される。１１がウインドウサイズのときは、１／２したことによって、５．５の非整数値になった場合には重複確認応答閾値は５に設定される。これから分かるように、この結果は３を超えるものである。従って、５番目の重複確認応答を受信した後、再送信が行われる。図４ｂの例に従って、輻輳ウインドウは従来の場合のように、ｓｓｔｈｒｅｔｈに、即ち、再送信時の輻輳ウインドウの１／２に減縮される。しかしながら、その後、重複確認応答閾値の値は、その結果に、即ち、図４ｂの例では５に、加算される。再送信時の輻輳ウインドウサイズが偶数値の場合、この処理は輻輳ウインドウが同サイズで残っていることを意味するものである。輻輳ウインドウが本例における最大セグメントの非偶数倍に相当するサイズを有するので、輻輳ウインドウサイズは再送信前の値、つまり図４ｂの例における１０．５よりもわずかに小さい値に戻るものである。


【手続補正１３】
【補正対象書類名】明細書
【補正対象項目名】００５６
【補正方法】変更
【補正の内容】
【００５６】
図４ａに示される場合及びタムラ他の従来技術に関して、図４ｂ及び４ｃに示される具体例の利点は、輻輳ウインドウが３よりかなり大きいサイズに到達できる場合により顕著となる。このことは、データユニットが送信されている送信ネットワークが、大きい容量、例えばユニバーサルモバイルテレフォンシステム（ＵＭＴＳ）スタンダードに従って動作するシステムの場合に期待できるのである。従って、本発明は、好ましくは、そのような高データレートリンクを供給するリンクレイヤプロトコル上で動作するプロトコルに関連して適用されるものである。言い換えれば、Ｌ４層が実行されるリンクレイヤＬ２がＵＭＴＳネットワークのような高バンド幅送信ネットワークに関連したレイヤであるときは、本発明の方法を、ＯＳＩスタンダードではＬ４と言われるトランスポート層に、適用するのが好ましい。本発明の方法はリオーダを扱うことができるので、Ｌ４以下の低プロトコル層が、リオーダが起こりやすい場合である、限度を越えてＬ４データユニットをリリースすることができるような方法で、実施される場合、本発明は特に、利点がある。


【手続補正１４】
【補正対象書類名】明細書
【補正対象項目名】００５８
【補正方法】変更
【補正の内容】
【００５８】
図３ｂは、図３ａと同じ初期状態を示しているが、重複確認応答閾値が輻輳ウインドウサイズに基づいて、即ち、この輻輳ウインドウサイズ（最大セグメントサイズの倍数で決定される）の１／２として、決定される。重複確認応答閾値は、それ故、特定値（標準的なＴＣＰの場合のような）には限定されず、特定の最大値（タムラ論文の場合のような）にも限定されない。図３ｂの例では、輻輳ウインドウサイズは１０又は１１とみなされ、そして重複確認応答閾値は５である。結果として、状況が図３ｂに示される場合、即ち、第５番目の重複確認応答が送信機側に到達する場合に、送信機はセグメントｎ＋１を再送信するまでΔＴだけ長い期間待機する。一方、セグメントｎ＋１が実際に失われておらず、ただ遅延している場合で、そして、それ（セグメントｎ＋１）が図３ｂに示される時間ΔＴ中に到達する場合には、セグメントｎ＋１の正確な受信は、重複確認応答の閾値にこの場合達していないので、再送信が送信機側で起こる前に確認応答されることになる。




【手続補正書】
【提出日】平成15年9月29日(2003.9.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
所定の通信プロトコルについて送信局から受信局への所定量のデータのフローを制御する方法であって、
前記所定量のデータを、シーケンス中に並べられる複数のデータセグメントに分割する工程と、
前記データセグメントを前記送信局から前記受信局に前記シーケンスの順序で送信する工程と、
受信局において、データセグメントが正確に受信されたか否か、正確に受信されたデータセグメントが適切な順番の前記シーケンスにあるか否かを判定する工程と、
データセグメントの正確な受信を示し、前記適切な順番のシーケンスで受信された前記シーケンス中の最新の正確に受信されたデータセグメントを識別する確認応答メッセージを、前記受信局から前記送信局に送信する工程と、
前記適切な順番のシーケンスで受信された最新の正確に受信された前記シーケンス中のデータセグメントと同じ１つのデータセグメントをそれぞれ識別する閾値数の重複確認応答メッセージを送信局が受信する場合、前記１つのデータセグメントに直ちに続くセグメントを再送信する工程と、
前記閾値数をダイナミックに適応させるための閾値数適応処理工程とを備え、
前記閾値数適応処理工程は、前記閾値数が３より大きい値をとるようになされており、前記閾値数は未確定データセグメント数に直接依存しており、この未確定データセグメントは前記送信局によって送信されたが、適切な順序で受信された最新の正確に受信された前記シーケンスのデータセグメントとして前記データセグメントを識別する確認応答メッセージを前記送信局が受信しなかったデータセグメントであることを特徴とするデータ量のフローを制御する方法。
【請求項２】
前記閾値数適応処理工程は、
前記データセグメント数はフロー制御に関連した所定のグループに属するデータセグメント数を識別する整数であり、データセグメント数決定処理を実行する工程と、
所定の因数により前記データセグメント数を除算する工程と、
前記所定の因数によって前記データセグメント数を除算した結果に基づいて前記閾値数を適応させる工程と、
を備えていることを特徴とする請求項１に記載の方法。
【請求項３】
前記所定の因数は、整数であることを特徴とする請求項２に記載の方法。
【請求項４】
前記所定の因数は２であることを特徴とする請求項３に記載の方法。
【請求項５】
前記所定の因数で前記データセグメント数を除算した結果に基づいて前記閾値数を適応させる工程は、
前記結果が整数の場合には、前記結果に等しい前記閾値数を設定し、前記結果が整数でない場合には、前記結果に所定の丸め演算を実行し、前記丸め演算の結果に等しい閾値数を設定することを特徴とする請求項２乃至４の何れか１項に記載の方法。
【請求項６】
前記閾値数は、前記未確定データセグメント数が変わる度に適応されることを特徴とする請求項１乃至５の何れか１項に記載の方法。
【請求項７】
前記閾値数は、前記データセグメントの１つに対する重複確認応答メッセージが受信される最初のとき毎に少なくとも更新されることを特徴とする請求項１乃至６の何れか１項に記載の方法。
【請求項８】
前記閾値数は、重複確認応答メッセージが受信される毎に更新されることを特徴とする請求項７に記載の方法。
【請求項９】
前記閾値数は、確認応答メッセージが受信される毎に更新されることを特徴とする請求項１乃至６の何れか１項に記載の方法。
【請求項１０】
前記閾値数は、未確定データセグメントを識別する確認応答メッセージが受信される毎に更新されることを特徴とする請求項１乃至６の何れか１項に記載の方法。
【請求項１１】
前記所定の通信プロトコルは第１のプロトコル層（Ｌ４）にあり、第２のプロトコル層（Ｌ２）は、前記所定の通信プロトコルの送信局から前記データセグメントを受信し、前記所定の通信プロトコルの受信局に前記データセグメントをリリースする、前記第１のプロトコル層（Ｌ４）に供給される所定のプロトコル実行を有し、前記所定のプロトコル実行は前記シーケンスの限度を越えて前記データセグメントをリリースするように動作することを特徴とする請求項１乃至１０の何れか１項に記載の方法。
【請求項１２】
前記第１のプロトコル層（Ｌ４）はトランスポート層であり、前記第２のプロトコル層（Ｌ２）はリンク層であることを特徴である請求項１１に記載の方法。
【請求項１３】
コンピュータ上で実行される際に請求項１乃至１２の何れか１項の方法を実行するようになされたコンピュータプログラム。
【請求項１４】
請求項１３に記載のコンピュータプログラムを格納している、コンピュータ読み取り可能なメモリー装置。
【請求項１５】
データの送受信を行うようになされた通信装置であって、
前記通信装置は、請求項１乃至１２の何れか１項の方法に従って送信局及び／又は受信局として動作するようになされていることを特徴とする通信装置。
【国際調査報告】
2004523992.tif 000047
2004523992.tif 000048