特許 6248638 通信端末、プログラム、及び通信方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6248638

(24)【登録日】2017年12月1日

(45)【発行日】2017年12月20日

(54)【発明の名称】通信端末、プログラム、及び通信方法

(51)【国際特許分類】

   H04L 12/815 20130101AFI20171211BHJP

   H04L 12/825 20130101ALI20171211BHJP

【ＦＩ】

   H04L12/815

   H04L12/825

【請求項の数】13

【全頁数】22

(21)【出願番号】特願2014-416(P2014-416)

(22)【出願日】2014年1月6日

(65)【公開番号】特開2015-130561(P2015-130561A)

(43)【公開日】2015年7月16日

【審査請求日】2016年9月5日

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】100089118

【弁理士】

【氏名又は名称】酒井 宏明

(72)【発明者】

【氏名】鶴岡 哲明

【審査官】 野元 久道

(56)【参考文献】

【文献】 特開平１１−０９８２１９（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００３／００９７４６１（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／８１５

Ｈ０４Ｌ １２／８２５

(57)【特許請求の範囲】

【請求項1】

ウィンドウによってパケットの送信量を制御する通信端末であって、
前記通信端末が送信したパケットの受信装置から送信された確認応答の受信時、及び、前記通信端末におけるパケットの送信実行タイミング毎に更新されるタイマ値の満了時を含む送信タイミング候補毎に、目標送信レートに応じて蓄積される送信権利の蓄積量に基づいて、パケットの送信可否を判定し、
前記確認応答の受信時、及び、前記タイマ値の満了時に、前記送信権利の蓄積量を算出し、
タイマ分解能の単位期間内では、前記送信権利の一時利用上限基本値よりも大きい第１の閾値までの前記送信権利の蓄積、及び、前記第１の閾値に対応する前記送信権利の残量に応じた、パケットの送信量を許容し、
送信が可能と判定した前記送信タイミング候補において、パケットを送信する、
ことを特徴とする通信端末。

【請求項2】

前記送信実行タイミングにおける前記送信権利の残量及び前記目標送信レートに基づいて、前記タイマ値を設定する、
ことを特徴とする請求項１に記載の通信端末。

【請求項3】

前記単位期間の終了時には、前記一時利用上限基本値を超える前記送信権利の蓄積を許容しない、
ことを特徴とする請求項１に記載の通信端末。

【請求項4】

前記単位期間当たりの前記送信権利の蓄積量と予め定めた蓄積上限値との内で小さい方を、前記第１の閾値とする、
ことを特徴とする請求項１に記載の通信端末。

【請求項5】

前記確認応答の受信時において、前記確認応答が示す受信確認データ量に、実績送信レートに対する前記目標送信レートの比を乗算して得られる第１のデータ値が、前記送信権利の一時利用上限基本値より小さい場合、前記第１のデータ量をパケット単位データ量で除した商と等しい個数のパケットを送信する、
ことを特徴とする請求項１に記載の通信端末。

【請求項6】

前記第１のデータ量を前記パケット単位データ量で除した結果、余りが生じた場合、前記確認応答の次回の受信時において、前記余りを前記受信確認データ量に加算する、
ことを特徴とする請求項５に記載の通信端末。

【請求項7】

前記タイマ値の満了時に送信が可能と判定された場合に送信されるデータ量は、下限値を有し、
前記送信実行タイミングにおける前記送信権利の残量、前記目標送信レート、及び、前記下限値に基づいて、前記送信権利の蓄積量が前記下限値に到達するまでに掛かる時間を算出し、前記算出した時間を前記タイマ値に設定する、
ことを特徴とする請求項２に記載の通信端末。

【請求項8】

前記タイマ値は、下限値を有する、
ことを特徴とする請求項２に記載の通信端末。

【請求項9】

輻輳制御処理で設定される前記ウィンドウの制限値と、ラウンドトリップタイムとに基づいて、前記目標送信レートを算出する、
ことを特徴とする請求項１に記載の通信端末。

【請求項10】

送信済みであり且つ前記確認応答が受信されていない、パケットについてのデータ量の総量を、前記ウィンドウの制限値とする、
ことを特徴とする請求項１に記載の通信端末。

【請求項11】

前記タイマ値を管理するタイマは、さらに、応答タイムアウトを管理する、
ことを特徴とする請求項１に記載の通信端末。

【請求項12】

ウィンドウによってパケットの送信量を制御する通信端末に、
前記通信端末が送信したパケットの受信装置から送信された確認応答の受信時、及び、前記通信端末におけるパケットの送信実行タイミング毎に設定されるタイマ値の満了時を含む送信タイミング候補毎に、目標送信レートに応じて蓄積される送信権利の蓄積量に基づいて、パケットの送信可否を判定し、
前記確認応答の受信時、及び、前記タイマ値の満了時に、前記送信権利の蓄積量を算出し、
タイマ分解能の単位期間内では、前記送信権利の一時利用上限基本値よりも大きい第１の閾値までの前記送信権利の蓄積、及び、前記第１の閾値に対応する前記送信権利の残量に応じた、パケットの送信量を許容し、
送信が可能と判定した前記送信タイミング候補において、パケットを送信する、
処理を実行させることを特徴とするプログラム。

【請求項13】

ウィンドウによってパケットの送信量を制御する通信端末における通信方法であって、
前記通信端末が送信したパケットの受信装置から送信された確認応答の受信時、及び、前記通信端末におけるパケットの送信実行タイミング毎に設定されるタイマ値の満了時を含む送信タイミング候補毎に、目標送信レートに応じて蓄積される送信権利の蓄積量に基づいて、パケットの送信可否を判定し、
前記確認応答の受信時、及び、前記タイマ値の満了時に、前記送信権利の蓄積量を算出し、
タイマ分解能の単位期間内では、前記送信権利の一時利用上限基本値よりも大きい第１の閾値までの前記送信権利の蓄積、及び、前記第１の閾値に対応する前記送信権利の残量に応じた、パケットの送信量を許容し、
送信が可能と判定した前記送信タイミング候補において、パケットを送信する、
ことを特徴とする通信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信端末、プログラム、及び通信方法に関する。

【背景技術】

【0002】

近年のネットワークにおいては、インターネットに代表されるように、ネットワーク層以下のレイヤでは、データがパケット化されて伝送される。そして、パケットは、宛先に届いたことを保証しないデータグラムとして、パケットの宛先に向けて伝送される。これに対して、パケットの宛先への伝送を保証する仕組みは、ネットワーク層より上位のレイヤで実現され、ＴＣＰ(Transport Control Protocol)に代表されるトランスポート層サービスを用いて実現される仕組みが主流になっている。以下では、エンドトゥエンドのトランスポート層サービスを用いた、個々の通信を、「コネクション」と称することがある。

【0003】

ＴＣＰでは、転送時間を短縮するために、「ウィンドウ」が導入されている。「ウィンドウ」とは、確認応答を待たずに送信できる、パケットの数あるいはデータ量である。ＴＣＰでは、このウィンドウを用いて、フロー制御が行われる。すなわち、ＴＣＰでは、受信装置のバッファ量(つまり、受信バッファサイズ)、及び、送信データ（再送データを含む）の保持に要する送信バッファ量(つまり、送信バッファサイズ)を上限に、確認応答を受けずに送信可能なデータ量が取り決められる。そして、受信装置によるパケットの取りこぼしを回避しつつ、確認応答を受信するまでの期間にデータ転送を停止することを回避する。これにより、受信装置がパケットを漏らさない限りにおいて、スループットを向上させることができる。

【0004】

また、ＴＣＰでは、上記のフロー制御のメカニズムを活用して、送信レート制御を行う。すなわち、ウィンドウのサイズ（つまり、パケット数又はデータ量）を動的に調整することにより、送信レート制御が行われる。これは、ウィンドウサイズが、往復伝搬遅延時間（ＲＴＴ：ランドトゥリップタイム）内に送出が許可されているデータ量であり、送信レートを次の式で表すことができるためである。
送信レート＝ウィンドウサイズ／ＲＴＴ

【0005】

こうしたプロトコルは、さまざまなネットワークで使われることを想定する必要がある。そのため、これらを利用するネットワークにおける通信は、種々の装置及びアプリケーションを用いることにより、実現される。従って、送信装置から受信装置へ向けて送信されたパケットは、種々の遅延特性及び帯域幅を有するリンクを経由しうる。また、各リンクが複数の通信トラフィックで共用される状況が生じる。このため、送信装置及び受信装置の都合だけでパケットを送信した場合、トラフィック量がリンク帯域又はネットワーク容量を超える事態となり、バッファからデータが漏れ出してしまう現象及びネットワークを保護するための廃棄処理が実行される現象が起こりうる。さらには、廃棄処理に起因した再送パケットが発生し、最悪の場合、ネットワークがダウンする現象が起こりうる。これらの現象は、ネットワークの品質、及び、有効帯域を低下させる。

【0006】

そこで、ＴＣＰでは、「輻輳制御」が導入されている。「輻輳制御」は、ネットワークの混み具合、又は、リンク容量の変動に基づいて、送信レート、つまりパケットの送信量を調整する制御である。輻輳制御においては、パケットの送信量は、「輻輳ウィンドウ（congestion window）」を用いて制御される。すなわち、「輻輳ウィンドウ」は、ネットワークの混み具合、又は、リンク容量の変動が考慮された、ウィンドウである。以下では、輻輳ウィンドウをＣＷＮＤと略すことがある。

【0007】

また、輻輳制御において、送信装置がパケットを送信するタイミングは、応答確認を受信したタイミングである。すなわち、確認応答を受信すると確認応答を待っているデータ量が確認応答された分（＝その確認応答によって新たに相手の受信が示された「受信確認データ量」）減少し新たなパケット送信が可能となるため、パケット送信のトリガは、確認応答の受信である。この確認応答をトリガとしてパケット送信することを、「ＡＣＫクロッキング」と呼ぶことがある。

【0008】

また、輻輳制御において送信レートを増加又は減少させる場合、ＣＷＮＤサイズを増加又は減少させる。したがってＣＷＮＤサイズに対する空席分は、確認応答の示す「受信確認データ量」に、ＣＷＮＤサイズの増減量を加算した量となるため、これが送信可能なデータ量となる。すなわち、ＣＷＮＤサイズを増加させるタイミングでは、確認応答に応じたレートにＣＷＮＤの増加量を上乗せした送信レートによって、パケットが送信される。後述するスロースタート時にはこの上乗せが確認応答のたびになされるため、ＴＣＰのバースト性が高くなる典型的なケースとなる。

【0009】

ここで、輻輳制御の典型的方法である、「リノ（reno）」と呼ばれる方法を例に挙げて、輻輳制御を具体的に説明する。図１は、従来の輻輳制御の説明に供する図である。

【0010】

図１に示すように、初期状態はスロースタート状態に設定され、ＣＷＮＤサイズが最小値に設定される。そして、確認応答が受信される度に、ＣＷＮＤサイズが１パケット分増加させられる。すなわち、スロースタート状態では、確認応答の受信レートの倍でパケットが送信されることになるため、今回のＲＴＴにおける送信レートは、前回のＲＴＴにおける送信レートの２倍になる。

【0011】

そして、重複確認応答によってパケットロスＥ１０１−１が検出されると、状態がスロースタート状態から輻輳回避状態に遷移する。そして、スロースタート閾値（ssthresh）の最新値が初期設定値の半分に設定されると共に、ＣＷＮＤサイズもスロースタート閾値の最新値に合わせて設定される。そして、このＣＷＮＤサイズの現在の設定値に相当する分の確認応答が受信される度に、ＣＷＮＤサイズが１パケット分増加させられる。図１では、さらにもう一度、重複確認応答によってパケットロスＥ１０１−２が検出され、輻輳回避状態が繰り返されている。

【0012】

そして、図１に示すように、応答タイムアウト（RTO：Response TimeOut）Ｅ１０２が検出されると、スロースタート閾値の最新値がそのときの設定値の半分に設定されると共に、輻輳ウィンドウが最小値に設定される。そして、状態がスロースタート状態に遷移する。そして、輻輳ウィンドウが増加してスロースタート閾値に達すると、状態が、スロースタート状態から輻輳回避状態に遷移する。以上のようにして、輻輳制御が為されている。

【先行技術文献】

【特許文献】

【0013】

【特許文献1】特開２０１０−１８７２９２号公報

【発明の概要】

【発明が解決しようとする課題】

【0014】

しかしながら、上記従来の輻輳制御によると、以下に例示するような現象によって、所望の送信レートが得られない可能性がある。

【0015】

図２は、送信装置と受信装置との間におけるデータ転送の様子を示す図である。特に、図２では、送信装置と受信装置との間に、２つの中継ノードが存在する場合が示されている。また、図３は、中継ノードのバッファに送信待ちパケットが滞留する様子を示す図である。

【0016】

図２では、送信装置と第１の中継ノードとがリンク１で接続され、第１の中継ノードと第２の中継ノードとがリンク２で接続され、第２の中継ノードと受信装置とがリンク３で接続されている。そして、送信装置から送信されたパケットは、リンク１、第１の中継ノード、リンク２、第２の中継ノード、リンク３の順番で通過し、受信装置によって受信される。受信装置によって受信されたパケットに対する確認応答は、逆に、リンク３、第２の中継ノード、リンク２、第１の中継ノード、リンク１の順番で通過し、送信装置によって受信される。

【0017】

ここで、リンク１の帯域幅とリンク３の帯域幅とが等しく、リンク２の帯域幅がリンク１の帯域幅よりも狭いものとする。この場合、送信装置がパケットを制限無く送信すると、リンク１の速さ（つまり、帯域幅）に応じた第１の間隔でパケットがリンク１を通過し、第１の中継ノードで受信される。これに対して、第１の中継ノードは、リンク２の速度がリンク１の速度よりも遅いため、上記の第１の間隔よりも長い第２の間隔でしかパケットをリンク２へ送出することができない。この結果、第１の中継ノードのバッファに、送信待ちのパケットが滞留していくことになる。

【0018】

そして、リンク２では、第２の間隔でパケットが通過し、そのパケットが第２の中継ノードで受信される。そして、第２の中継ノードは、パケットの受信間隔に従って、第２の間隔でパケットをリンク３に送出する。リンク３では、第２の間隔でパケットが通過し、そのパケットが受信装置で受信される。

【0019】

そして、受信装置は、パケットの受信間隔に従って、受信パケットに対する確認応答を第２の間隔でリンク３に送出する。そして、第２の間隔で送出された確認応答は、その間隔を保って、リンク２及びリンク１を通過し、送信装置によって受信される。ここで、リンク２の様にパスにおいて最も帯域幅の狭いリンクを、「ボトルネックリンク」と呼ぶことがある。送信装置がボトルネックリンクの帯域幅以上でパケットを送信した場合、中継ノードにパケットが滞留してしまう現象が生じてしまう。なお、以下では、応答確認によって確認された受信確認データ量についてのレートを、「ＡＣＫレート」と呼ぶこととする。

【0020】

また、図３に示すように、ラウンドトリップタイム（ＲＴＴ）＃１の最初において送信装置が４つのパケットを送信可能な状態であるとすると、送信装置は、リンク１の帯域幅に応じて決まる間隔（つまり、上記の第１の間隔）で４つのパケットを送信する（図３のＲＴＴ＃１＠ｔｘ参照）。これに対して、上記の通り、ボトルネックリンクの帯域幅が狭いことに起因して、４つのパケットについての間隔が上記の第２の間隔に広がり、４つのパケットは第２の間隔で受信装置によって受信される（図３のＲＴＴ＃１＠ｒｘの上段参照）。この受信パケットに応じて、受信装置は、第２の間隔で４つの確認応答を送出する（図３のＲＴＴ＃１＠ｒｘの下段参照）。そして、受信装置から送出された４つの確認応答は、ＲＴＴ＃１の次のラウンドトリップタイムであるＲＴＴ＃２において、ボトルネックリンクの帯域幅に応じた第２の間隔で送信装置に到達する（図３のＲＴＴ＃２＠ｔｘの上段参照）。上記のスロースタート状態の輻輳制御アルゴリズムによれば、確認応答に応じて１つのパケットを送信できる上に、その確認応答に応じてＣＷＮＤサイズが拡大されることによってさらにもう１つのパケットを送信することができる（図３のＲＴＴ＃２＠ｔｘの下段参照）。なお、図３のＲＴＴ＃２＠ｔｘの下段において、網掛けされていない四角は、確認応答に応じたパケットを示す一方、網掛けされている四角は、確認応答に応じてＣＷＮＤサイズが拡大されることによって送信可能となったパケットを示す。

【0021】

そして、このように送信されたパケットがボトルネックバッファ（つまり、上記の第１の中継ノードのバッファに対応）に蓄積される状況が、図３の最下段に示されている。ここで、上記の通り、送信装置がボトルネックリンクの帯域幅以上でパケットを送信した場合、中継ノードにパケットが滞留してしまう現象が生じてしまう。ボトルネックバッファにおける蓄積状況を見てわかるように、ボトルネックリンクの速さに対する送信装置における送信レートの過剰分に対応するパケットがＲＴＴ＃２の期間中に蓄積される。すなわち、ＡＣＫレートがボトルネックリンクの速さに相当するので、ここで過剰分はＣＷＮＤサイズ拡大により送出された「網掛けされている四角」が該当し、「網掛けされている四角」の到着のタイミングでバッファ蓄積量が増加している。図４に示すように、仮にボトルネックバッファのサイズが十分に大きくない場合、蓄積量がバッファの限界値に達してしまい、バッファからパケットが溢れてしまう事象（以下では、「バッファ溢れ」と呼ぶことがある）が起こる可能性がある。図４は、ボトルネックバッファの蓄積量の時間に対する変化を示す図である。なお、このバッファにおける溢れは、第２の間隔で送出された確認応答が継続的に送られる期間におけるＣＷＮＤサイズの拡大数とバッファの空き容量の関係で決まるため、ボトルネックリンクのレートに余裕がある場合でも起こりうる。

【0022】

そして、スロースタート状態においてバッファ溢れが起こると、上記の通り、輻輳回避状態に移行する。輻輳回避状態では、スロースタート状態における送信レート上昇ペースよりも顕著に遅くなる。このように送信レート上昇ペースが落ちても、図５のラインＬ１に示すように、ボトルネック帯域付近まで送信レートが上昇した段階でバッファ溢れが起こった場合にはあまり不都合がない。これに対して、図５のラインＬ２に示すように、ボトルネック帯域に比べてかなり小さい送信レートの段階でバッファ溢れが起こった場合、送信レートがボトルネック帯域に到達するまでには長い時間を要することになる。この場合、仮にボトルネックリンクにおいて対象通信に割り当て可能な帯域が余っていたとしても、その割り当て可能帯域に到達する前に対象通信が完了してしまう可能性が高い。この結果、利用可能な送信レートよりも遅い送信レートでの通信を余儀なくされる可能性が高い。図５は、輻輳回避状態の説明に供する図である。

【0023】

なお、このような事態は、リンクを複数のトラフィックで共有する場合にも起こりうる。また、確認応答が何らかの理由で滞留した結果、確認応答が纏まって届いた場合、送信装置が高いバース性でパケットを送信することになるので、同様の事態が生じうる。

【0024】

開示の技術は、上記に鑑みてなされたものであって、送信レートの向上を実現することができる、通信端末、プログラム、及び通信方法を提供することを目的とする。

【課題を解決するための手段】

【0025】

開示の態様では、通信端末は、送信タイミング候補毎に、目標送信レートに応じて蓄積される送信権利の蓄積量に基づいて、パケットの送信可否を判定し、送信が可能と判定した前記送信タイミング候補において、パケットを送信する。前記送信タイミング候補は、前記通信端末が送信したパケットの受信装置から送信された確認応答の受信時、及び、前記通信端末におけるパケットの送信実行タイミング毎に更新されるタイマ値の満了時を含む。また、通信端末は、前記確認応答の受信時、及び、前記タイマ値の満了時に、前記送信権利の蓄積量を算出し、タイマ分解能の単位期間内では、前記送信権利の一時利用上限基本値よりも大きい第１の閾値までの前記送信権利の蓄積、及び、前記第１の閾値に対応する前記送信権利の残量に応じた、パケットの送信量を許容する。

【発明の効果】

【0026】

開示の態様によれば、送信レートの向上を実現することができる。

【図面の簡単な説明】

【0027】

【図1】図１は、従来の輻輳制御の説明に供する図である。

【図2】図２は、送信装置と受信装置との間におけるデータ転送の様子を示す図である。

【図3】図３は、中継ノードのバッファに送信待ちパケットが滞留する様子を示す図である。

【図4】図４は、ボトルネックバッファの蓄積量の時間に対する変化を示す図である。

【図5】図５は、輻輳回避状態の説明に供する図である。

【図6】図６は、実施例１の通信システムの一例を示す図である。

【図7】図７は、実施例１の通信端末の一例を示すブロック図である。

【図8】図８は、トークンバケット方式の説明に供する図である。

【図9】図９は、実施例１の通信端末の処理動作例の説明に供する図である。

【図10】図１０は、実施例１の通信端末の処理動作例の説明に供するフローチャートである。

【図11】図１１は、実施例１の通信端末の処理動作例の説明に供するフローチャートである。

【図12】図１２は、ボトルネックバッファの蓄積量の時間に対する変化を示す図である。

【図13】図１３は、実施例２のタイマ基準値の設定方法の一例の説明に供する図である。

【図14】図１４は、実施例３の通信端末の処理動作例の説明に供するフローチャートである。

【図15】図１５は、実施例４の通信端末の処理動作例の説明に供するフローチャートである。

【図16】図１６は、時間に対して送信レートが変動する様子の説明に供する図である。

【図17】図１７は、通信端末のハードウェア構成例を示す図である。

【発明を実施するための形態】

【0028】

以下に、本願の開示する通信端末、プログラム、及び通信方法の実施形態を図面に基づいて詳細に説明する。なお、この実施形態により本願の開示する通信端末、プログラム、及び通信方法が限定されるものではない。また、実施形態において同一の機能を有する構成には同一の符号を付し、重複する説明は省略される。また、実施形態において同一の処理を行うステップには同一の符号を付し、重複する説明は省略される。

【0029】

［実施例１］
［通信システムの概要］
図６は、実施例１の通信システムの一例を示す図である。図６において、通信システム１は、通信端末１０，３０と、ネットワーク５０とを有する。通信端末１０は、パケットを通信端末３０に向けて送信する。また、通信端末１０は、「輻輳ウィンドウ」によって、ラウンドトリップ時間内に送信するパケットの送信量を制御する。この輻輳ウィンドウによってパケットの送信量を制御するために用いられるプロトコルは、例えば、ＴＣＰである。以下では、利用されるプロトコルがＴＣＰであることを前提に説明する。そして、通信端末３０は、通信端末１０から送信されたパケットを受信すると、確認応答を通信端末３０へ送信する。

【0030】

また、通信端末１０は、「送信タイミング候補」毎に、「目標送信レート」に応じて蓄積される「送信権利」の蓄積量に基づいて、パケットの送信可否を判定する。ここで、「送信タイミング候補」は、通信端末３０から送信された確認応答の受信時、及び、通信端末１０によるパケットの「送信実行タイミング」毎に更新されるタイマ値の満了時を含む。また、「目標送信レート」とは、例えば、通信端末１０の平均送信レートの目標値である。また、「送信権利」は、例えば、「トークンバケット方式」におけるトークンである。「送信実行タイミング」とは、通信端末１０が実際にパケットを送信したタイミングである。

【0031】

具体的には、通信端末１０は、少なくとも次のような処理を行う。すなわち、通信端末１０は、確認応答を受信すると、送信権利の蓄積量を確認し、送信権利の蓄積量が「送信実行下限値」以上である場合、その蓄積量に応じたパケットを送信する。この時、通信端末１０は、タイマにタイマ基準値（つまり、タイマ初期値）を設定する。また、通信端末１０は、パケットを送信するとそのパケットの送信量分だけ送信権利の蓄積量を減少させる。また、１つの送信実行タイミングにおいて使用可能な送信権利は、「一時利用上限基本値」までに制限されている。すなわち、パケットシェーピングの技法が適用されている。そして、このタイマが満了する前に、通信端末１０が応答確認を受信し、送信権利の蓄積量を確認した結果、パケットを送信した場合、通信端末１０は、タイマの値をタイマ基準値に更新する。また、このタイマが満了した場合も、通信端末１０は、送信権利の蓄積量を確認し、送信権利の蓄積量が送信実行下限値以上である場合、その蓄積量に応じたパケットを送信する。この時にも、通信端末１０は、タイマにタイマ基準値を設定する。

【0032】

なお、通信端末１０は、タイマが満了する前に応答確認を受信し、送信権利の蓄積量を確認した結果、パケットを送信しないと判定した場合にも、タイマの値をタイマ基準値に更新してもよい。

【0033】

以上のようにすることで、送信権利に基づいて送信実行タイミングを平準化するように、複数の確認応答受信タイミングの内の一部を送信実行タイミングとし残りを送信非実行タイミングとすると共に、その送信非実行タイミングの代わりにタイマの満了時を送信実行タイミングとすることができる。これにより、パケット送信のバースト性を抑制することができる。また、その送信非実行タイミングにおけるパケット送信量を制御できるので、パケット送信のバースト性をさらに抑制することができる。この結果、ボトルネックバッファにおけるバッファ溢れが起こる可能性を低減できるので、送信レートを向上させることができる。なお、確認応答受信タイミングの一部を送信実行タイミングとしつつタイマ満了時を送信実行タイミングとすることにより、タイマのみによって送信実行タイミングを制御する場合に比べて、割り込み処理の発生頻度を抑えることができる。すなわち、通信端末１０における処理負荷を軽減することができる。

【0034】

［通信端末の構成］
図７は、実施例１の通信端末の一例を示すブロック図である。図７には、特に、パケットの送信側である通信端末１０の構成例を示している。図７において、通信端末１０は、制御部１１と、送信バッファ１２と、送信部１３と、受信部１４とを有する。

【0035】

送信バッファ１２は、送信パケットを入力して一時保持する。そして、送信バッファ１２は、保持している送信パケットを、制御部１１による制御に従って送信部１３へ出力する。

【0036】

送信部１３は、送信バッファ１２から出力された送信パケットに対して、所定の送信処理を施し、送信処理後の送信パケットをネットワーク５０へ送出する。

【0037】

受信部１４は、通信端末３０から送信された信号をネットワーク５０経由で受信し、受信信号に対して所定の受信処理を施す。そして、受信部１４は、受信処理後の信号に含まれる確認応答を制御部１１へ出力する。

【0038】

制御部１１は、送信パケットの送信制御を実行する。

【0039】

例えば、制御部１１は、上記した輻輳ウィンドウを調整する。

【0040】

また、例えば、制御部１１は、送信タイミング候補毎に、目標送信レートに応じて蓄積されるトークン（つまり、送信権利）の蓄積量に基づいて、パケットの送信可否を判定する。具体的には、制御部１１は、受信部１４から確認応答を受け取ると、トークンの蓄積量を確認し、トークンの蓄積量が「送信実行下限値」以上である場合、その蓄積量に応じたパケットを送信バッファ１２に出力させる。この時、制御部１１は、タイマ（図示せず）にタイマ基準値を設定する。また、制御部１１は、パケットを送信するとそのパケットの送信量分だけトークンの蓄積量を減少させる。また、１つの送信実行タイミングにおいて使用可能な送信権利は、「一時利用上限基本値」までに制限されている。そして、このタイマが満了する前に、制御部１１が応答確認を受信し、トークンの蓄積量を確認した結果、パケットを送信した場合、制御部１１は、タイマの値をタイマ基準値に更新する。また、このタイマが満了した場合も、制御部１１は、トークンの蓄積量を確認し、トークンの蓄積量が送信実行下限値以上である場合、その蓄積量に応じたパケットをバッファ１２に出力させる。この時にも、制御部１１は、タイマにタイマ基準値を設定する。なお、制御部１１は、タイマが満了する前に応答確認を受信し、送信権利の蓄積量を確認し、トークンの蓄積量が「送信実行下限値」未満の場合、パケットを送信しないと判定する。この場合にも、制御部１１は、タイマの値をタイマ基準値に更新してもよい。

【0041】

また、例えば、制御部１１は、トークンの管理を行う。例えば、制御部１１は、図８に示す「トークンバケット方式」に基づいて、トークンの管理を行う。図８は、トークンバケット方式の説明に供する図である。図８に示すように、制御部１１は、トークン（つまり、送信権利）を「一時利用上限基本値」まで蓄積可能な、論理的なバケットを有している。そして、バケットには、上記の目標送信レートに応じたペースでトークンが蓄積される。そして、制御部１１は、送信タイミング候補において、パケットを送信可能であると判定した場合、バケットに蓄積されたトークンの蓄積量に応じた数のパケットを送信する。そして、制御部１１は、送信したパケットのデータ量に相当するトークン量をトークンの蓄積量から減算する。なお、トークンの蓄積量の算出は、送信タイミング候補の時点で行ってもよい。

【0042】

なお、制御部１１は、上記の目標送信レートを、輻輳ウィンドウの制限値とラウンドトリップタイムとに基づいて算出してもよい。例えば、制御部１１は、輻輳ウィンドウの制限値をラウンドトリップタイムで除算することにより、目標送信レートを算出する。輻輳ウィンドウの制限値は、送信済みであり且つ確認応答が受信されていない、パケットについてのデータ量の総量であってもよい。また、ラウンドトリップタイムは、制御部１１が計測する。また、タイマ（図示せず）は、上記のタイマ値の管理とともに、上記の応答タイムアウト（ＲＴＯ）を管理してもよい。すなわち、タイマ（図示せず）は、上記のタイマ値の管理処理、及び、上記の応答タイムアウト（ＲＴＯ）の管理処理の両方で、共用されてもよい。

【0043】

また、制御部１１は、パケットの再送制御も行う。

【0044】

［通信端末の動作例］
以上の構成を有する通信端末１０の処理動作の一例について説明する。図９は、実施例１の通信端末の処理動作例の説明に供する図である。図１０、図１１は、実施例１の通信端末の処理動作例の説明に供するフローチャートである。図１０は、確認応答受信時に実行されるフローを示し、図１１は、タイマ満了時に実行されるフローを示す。

【0045】

図９において、通信端末１０によるＲＴＴ＃１での処理は、図３で説明した処理と同様である。

【0046】

ＲＴＴ＃２において、通信端末１０の制御部１１は、確認応答を受け取ると、図１０のフローをスタートさせる。

【0047】

制御部１１は、トークン蓄積量の前回更新時刻（Ｔｐｒｅｖ）と現在時刻（Ｔｎｏｗ）とを比較し、前回更新時刻から時間が経過しているか否かを判定する（ステップＳ１０１）。

【0048】

時間が経過している場合（ステップＳ１０１肯定）、制御部１１は、トークン加算量（ｔｏｋｅｎ＋）を算出する（ステップＳ１０２）。例えば、トークン加算量は、次の式によって算出される。
ｔｏｋｅｎ＋ ＝ｒａｔｅ×（Ｔｎｏｗ−Ｔｐｒｅｖ）

【0049】

そして、制御部１１は、前回更新時刻におけるトークン残量に、算出したトークン加算量を加算することにより、仮のトークン蓄積量を算出する。ただし、上記の通り、トークンの蓄積量には、上記の一時利用上限基本値（ｂｕｒｓｔ）による制限がある。

【0050】

そこで、制御部１１は、トークン上限制限処理を実行する（ステップＳ１０３）。例えば、制御部１１は、算出した仮のトークン蓄積量と、一時利用上限基本値とを比較し、小さい方を、実際のトークン蓄積量とする。

【0051】

そして、制御部１１は、実際のトークン蓄積量をパケット長（ｐｌｅｎ）で除算した時の商を、パケットの送信可能数（ｓｅｎｄ）とする（ステップＳ１０４）。なお、時間が経過していないと判定された場合（ステップＳ１０１否定）には、ステップＳ１０４が実行される。

【0052】

そして、制御部１１は、送信可能数（ｓｅｎｄ）が０より大きいか否かを判定する（ステップＳ１０５）。

【0053】

送信可能数（ｓｅｎｄ）が０より大きい場合、つまり送信可能数が１以上の場合（ステップＳ１０５肯定）、制御部１１は、送信可能数分だけパケットの送信処理を実行する（ステップＳ１０６）。

【0054】

そして、制御部１１は、パケットの送信量に応じたトークン量を、上記の実際のトークン蓄積量から減算する（ステップＳ１０７）。これにより、トークン残量を算出することができる。

【0055】

そして、制御部１１は、トークン更新時刻を現在の時刻で更新する（ステップＳ１０８）。なお、送信可能数が０以下であると判定された場合（ステップＳ１０５否定）には、ステップＳ１０８が実行される。

【0056】

また、制御部１１は、タイマにタイマ基準値を設定するとともに、タイマを起動させる（ステップＳ１０９）。なお、既にタイマが起動して動いている場合には、その時点でのタイマ値をタイマ基準値で更新する。

【0057】

図９のＲＴＴ＃２における１番目から４番目の確認応答のそれぞれについて、図１０のフローが実行される。

【0058】

そして、図９のＲＴＴ＃２の４番目の確認応答を受信した際に更新されたタイマは、確認応答が途中で受信されることなく、満了している。タイマが満了すると、制御部１１は、図１１のフローをスタートさせる。

【0059】

図１１におけるステップＳ１０２〜ステップＳ１０８の処理は、図１０におけるステップＳ１０２〜ステップＳ１０８の処理と同様である。

【0060】

制御部１１は、タイマ値をタイマ基準値で更新する（ステップＳ２０１）。

【0061】

ここで、図９の最下段、及び、図１２に示している通り、制御部１１が上記の処理動作を実行することにより、ボトムネックバッファに各時点で滞留するパケット量が低減されていることがわかる。これは、タイマを用いた制御によって、パケットの送信実行タイミングが分散化されるためである。図１２は、ボトルネックバッファの蓄積量の時間に対する変化を示す図である。

【0062】

以上のように本実施例によれば、通信端末１０は、輻輳ウィンドウによってラウンドトリップ時間内に送信するパケットの送信量を制御する。そして、通信端末１０において、制御部１１は、送信タイミング候補毎に、目標送信レートに応じて蓄積される送信権利の蓄積量に基づいて、パケットの送信可否を判定する。送信タイミング候補は、通信端末１０から送信されたパケットに対して通信端末３０から送信された確認応答の受信時、及び、通信端末１０によるパケットの送信実行タイミング毎に更新されるタイマ値の満了時を含む。

【0063】

この通信端末１０の構成により、複数の確認応答受信タイミングの内の一部を送信実行タイミングとし残りを送信非実行タイミングとすると共に、その送信非実行タイミングの代わりにタイマの満了時を送信実行タイミングとすることができる。これにより、送信実行タイミングを平準化することができるので、パケット送信のバースト性を抑制することができる。また、送信権利に基づいてパケット送信量を制御できるので、パケット送信のバースト性をさらに抑制することができる。この結果、ボトルネックバッファにおけるバッファ溢れが起こる可能性を低減できるので、送信レートを向上させることができる。また、確認応答受信タイミングの一部を送信実行タイミングとしつつタイマ満了時を送信実行タイミングとすることにより、タイマのみによって送信実行タイミングを制御する場合に比べて、割り込み処理の発生頻度を抑えることができる。すなわち、通信端末１０における処理負荷を軽減することができる。

【0064】

また、制御部１１は、１つの送信実行タイミングにおいて使用可能な送信権利の量を一時利用上限基本値までに制限する。

【0065】

この通信端末１０の構成により、一時に送信されるパケットのデータ量を制限することができるので、バースト性を抑制することができる。

【0066】

また、制御部１１は、確認応答の受信時、及び、タイマ値の満了時に、送信権利の残量を算出する。

【0067】

この通信端末１０の構成により、送信権利の残量の算出タイミングを限定することができるので、通信端末１０の処理量を低減することができる。

【0068】

また、制御部１１は、輻輳制御処理で設定される輻輳ウィンドウの制限値と、ラウンドトリップタイムとに基づいて、目標送信レートを算出する。

【0069】

この通信端末１０の構成により、輻輳ウィンドウの値と整合のとれたパケット送信を実現することができる。

【0070】

また、制御部１１は、送信済みであり且つ確認応答が受信されていない、パケットについてのデータ量の総量を、輻輳ウィンドウの制限値とする。

【0071】

この通信端末１０の構成により、既存のＴＣＰにおけるパケット送信と整合のとれたパケット送信を実現することができる。

【0072】

また、タイマは、タイマ値の管理とともに、応答タイムアウト（ＲＴＯ）を管理する。これにより、タイマを共用することができるので、通信端末１０の構成を簡略化できる。

【0073】

［実施例２］
実施例２は、実施例１の「タイマ基準値」の設定方法に関する。なお、実施例２の通信端末の構成は、実施例１の通信端末１０の構成と基本的に同じであるので、図７を用いて説明する。

【0074】

実施例２の通信端末１０の制御部１１は、送信実行タイミングにおける送信権利の残量及び目標送信レートに基づいて、タイマ基準値を設定する。

【0075】

例えば、制御部１１は、送信実行タイミングにおける送信権利の残量、目標送信レート、及び、「一時利用下限値」に基づいて、送信権利の蓄積量が一時利用下限値に到達するまでに掛かる時間を算出し、算出した時間をタイマ基準値に設定する。「一時利用下限値」とは、タイマ値の満了時に送信が可能と判定された場合に送信されるデータ量の下限値である。

【0076】

ここで、タイマ基準値は、下限値（以下では、「タイマ下限値」と呼ぶことがある）を有していてもよい。

【0077】

図１３は、実施例２のタイマ基準値の設定方法の一例の説明に供する図である。

【0078】

図１３には、目標送信レート（つまり、傾き）の異なる３つの直線、つまり、直線Ｌ１１，直線Ｌ１２，直線Ｌ１３が示されている。図１３において、Ｘ軸は、時間長であり、Ｙ軸は、トークンの蓄積量である。直線Ｌ１２の目標送信レートは、直線Ｌ１１の目標送信レートよりも大きく、直線Ｌ１３の目標送信レートは、直線Ｌ１２の目標送信レートよりも大きい。また、図１３において、ｍｉｎＩｎｔｖｌは、上記のタイマ下限値である。また、図１３において、ｍｉｎＢｕｒｓｔは、上記の一時利用下限値である。また、図１３において、ＭａｘＢｕｒｓｔは、実施例１で説明した「一時利用上限基本値」である。

【0079】

まず、直線Ｌ１１に着目すると、トークンの蓄積量が一時利用下限値に到達する時間、つまり、直線Ｌ１１とＹ＝ｍｉｎＢｕｒｓｔとの交点のＸ座標は、ｍｉｎＩｎｔｖｌよりも大きい値となっている。従って、制御部１１は、直線Ｌ１１に相当する状況では、トークンの蓄積量が一時利用下限値に到達する時間長をタイマ基準値として設定する。このタイマ基準値が満了した場合、一時利用下限値分だけトークンが蓄積されているので、一時利用下限値分のパケットが送信されることになる。

【0080】

次に、直線Ｌ１２に着目すると、トークンの蓄積量が一時利用下限値に到達する時間、つまり、直線Ｌ１２とＹ＝ｍｉｎＢｕｒｓｔとの交点のＸ座標は、ｍｉｎＩｎｔｖｌよりも小さい値となっている。従って、制御部１１は、直線Ｌ１２に相当する状況では、タイマ下限値（ｍｉｎＩｎｔｖｌ）をタイマ基準値として設定する。このタイマ基準値が満了した場合、直線Ｌ１２とＸ＝ｍｉｎＩｎｔｖｌとの交点のＹ座標に相当する蓄積量だけトークンが蓄積されているので、この蓄積量分だけパケットが送信されることになる。

【0081】

次に、直線Ｌ１３に着目すると、トークンの蓄積量が一時利用下限値に到達する時間、つまり、直線Ｌ１３とＹ＝ｍｉｎＢｕｒｓｔとの交点のＸ座標は、ｍｉｎＩｎｔｖｌよりも小さい値となっている。従って、制御部１１は、直線Ｌ１３に相当する状況では、タイマ下限値（ｍｉｎＩｎｔｖｌ）をタイマ基準値として設定する。このタイマ基準値が満了した場合、直線Ｌ１３とＸ＝ｍｉｎＩｎｔｖｌとの交点のＹ座標に相当する蓄積量だけトークンが蓄積されている。しかし、このＹ座標は、一時利用上限基本値（ＭａｘＢｕｒｓｔ）よりも大きい値となっている。そこで、制御部１１は、直線Ｌ１３に相当する状況では、一時利用上限基本値分だけパケットを送信することになる。

【0082】

以上のように本実施例によれば、通信端末１０において、制御部１１は、送信実行タイミングにおける送信権利の残量及び目標送信レートに基づいて、タイマ値を設定する。例えば、タイマ値の満了時に送信が可能と判定された場合に送信されるデータ量は、下限値（つまり、一時利用下限値）を有する。そして、制御部１１は、送信実行タイミングにおける送信権利の残量、目標送信レート、及び、一時利用下限値に基づいて、送信権利の蓄積量が一時利用下限値に到達するまでに掛かる時間を算出し、算出した時間をタイマ値に設定する。

【0083】

この通信端末１０の構成により、パケット送信が許容されていない状況でタイマが満了することを防止できるので、通信端末１０における無駄な処理を回避することができる。

【0084】

また、タイマ基準値は、下限値を有する。これにより、タイマ更新処理の負荷を低減することができるので、通信端末１０の処理負荷を低減することができる。

【0085】

［実施例３］
実施例３は、タイマ分解能の単位期間（以下では、「Ｔｉｃｋ」と呼ぶことがある）内における、トークン（つまり、送信権利）の蓄積及びパケット送信量の制御、並びに、タイマ分解能の単位期間の終了時における、トークン（つまり、送信権利）の蓄積の制御に関する。一般に、ソフトウェアが管理するタイマの分解能は、昨今の通信速度（例えば、パケットレート）に比べて、低い。例えば、オープンソースのＯＳとして知られるｌｉｎｕｘ（登録商標）は、標準的には１〜１０ｍｓ程度の分解能である。これに対して、ギガビットのイーサネット（登録商標）では、ジャンボフレームを使用しない場合、１５１８バイトが最大長となるため、１ｍｓに８００個以上のパケットを送信することができる。このため、許容バーストサイズ（つまり、上記の一時利用上限基本値）を例えば１００パケットとすると、ギガビットのイーサネット（登録商標）では、１ｍｓ当たりに蓄積されるトークンの量が、許容バーストサイズ（つまり、上記の一時利用上限基本値）を超えてしまうことが起こり得る。そこで、実施例３では、上記の制御を実行する。なお、実施例３の通信端末の構成は、実施例１の通信端末１０の構成と基本的に同じであるので、図７を用いて説明する。

【0086】

実施例３の通信端末１０の制御部１１は、タイマ分解能の単位期間（Ｔｉｃｋ）内では、「第１の閾値」までの送信権利の蓄積、及び、「第１の閾値」に対応する送信権利の残量に応じたパケットの送信量を許容する。「第１の閾値」は、上記の一時利用上限基本値よりも大きい値を有する。一方、制御部１１は、タイマ分解能の単位期間（Ｔｉｃｋ）の終了時には、上記の一時利用上限基本値の閾値を超える、送信権利の蓄積を許容しない。すなわち、制御部１１は、タイマ分解能の単位期間（Ｔｉｃｋ）内では、一時利用上限基本値以上第１の閾値以下の送信権利の蓄積を許容する一方、タイマ分解能の単位期間（Ｔｉｃｋ）の終了時には、一時利用上限基本値を上限として送信権利の蓄積を許容する。

【0087】

ここで、制御部１１は、単位期間（Ｔｉｃｋ）当たりの送信権利の蓄積量と、予め定めた「蓄積上限値」との内の小さい方を、「第１の閾値」としてもよい。

【0088】

図１４は、実施例３の通信端末の処理動作例の説明に供するフローチャートである。

【0089】

実施例３の通信端末１０の制御部１１は、確認応答を受け取ると、図１４のフローをスタートさせる。

【0090】

時間が経過している場合（ステップＳ１０１肯定）、制御部１１は、トークン繰越制限処理を実行する（ステップＳ３０１）。すなわち、制御部１１は、前回更新時刻におけるトークン残量（ｔｏｋｅｎ）と、一時利用上限基本値（ｂｕｒｓｔ）との内の小さい方を、現時点でのトークン蓄積量（ｔｏｋｅｎ）とする。

【0091】

そして、制御部１１は、トークン加算量（ｔｏｋｅｎ＋）を算出する（ステップＳ１０２）。

【0092】

そして、制御部１１は、現時点でのトークン蓄積量（ｔｏｋｅｎ）に、算出したトークン加算量を加算することにより、仮のトークン蓄積量を算出する。

【0093】

そして、制御部１１は、１Ｔｉｃｋ内に限定の上限超過検査を実行する（ステップＳ３０２）。すなわち、制御部１１は、算出した仮のトークン蓄積量（ｔｏｋｅｎ）と、上記の第１の閾値（ｅｂｕｒｓｔ）との内の小さい方を、実際のトークン残量とする。

【0094】

以上のように本実施例によれば、通信端末１０において、制御部１１は、タイマ分解能の単位期間（Ｔｉｃｋ）内では、送信権利の一時利用上限基本値よりも大きい第１の閾値までの送信権利の蓄積、及び、第１の閾値に対応する送信権利の残量に応じた、パケットの送信量を許容する。

【0095】

この通信端末１０の構成により、タイマ分解能の単位期間内における確認応答の受信を契機としたパケット送信では一時利用上限基本値を超えるデータ量のパケット送信を許容するので、送信レートを上昇させることができる。

【0096】

また、制御部１１は、タイマ分解能の単位期間の終了時には、一時利用上限基本値を超える送信権利の蓄積を許容しない。

【0097】

この通信端末１０の構成により、過剰に割り当てた送信権利が単位期間を跨いで繰り越されることを防止できるので、バースト性が高まることを防止できる。

【0098】

また、制御部１１は、単位期間当たりの送信権利の蓄積量と、予め定めた蓄積上限値との内で小さい方を、第１の閾値とする。

【0099】

この通信端末１０の構成により、蓄積上限値だけで制限すると過剰に送信権利を蓄えるリスクが生じるが、第１の閾値を目標送信レート相当までに制限できるので、過剰に送信権利が蓄えられることを防止することができる。

【0100】

［実施例４］
実施例４は、パケットの送信量の制御に関する。例えば、ある程度高い頻度で確認応答が到着するような状況下で、上記の一時利用上限基本値に相当する量のパケットを一度に送信してしまうと、続く確認応答を受信した時にトークンの残量が無くパケットを新たに送信できない事態が起こり得る。このような状況は、確認応答が安定して送信されてくるような状況下においてバースト性を高めてしまう。そこで、実施例４では、パケットの送信量の制御を実行する。なお、実施例４の通信端末の構成は、実施例１の通信端末１０の構成と基本的に同じであるので、図７を用いて説明する。

【0101】

実施例４の通信端末１０の制御部１１は、確認応答の受信時において、第１の条件が満たされた場合、第１のデータ量をパケット単位データ量で除した商と等しい個数のパケットを送信する。上記の第１の条件とは、確認応答が示す受信確認データ量に、実績送信レートに対する目標送信レートの比を乗算して得られる第１のデータ値が、送信権利の一時利用上限基本値より小さい場合である。

【0102】

ここで、制御部１１は、上記の第１のデータ量をパケット単位データ量で除した結果、余りが生じた場合、確認応答の次回の受信時において、その余りを受信確認データ量に加算してもよい。

【0103】

図１５は、実施例４の通信端末の処理動作例の説明に供するフローチャートである。

【0104】

実施例４の通信端末１０の制御部１１は、確認応答を受け取ると、図１５のフローをスタートさせる。

【0105】

送信可能数（ｓｅｎｄ）が０より大きい場合、つまり送信可能数が１以上の場合（ステップＳ１０５肯定）、制御部１１は、バーストサイズ制限処理を実行する（ステップＳ４０１）。すなわち、制御部１１は、一時利用上限基本値（ｂｕｒｓｔ）と、送信可能数（ｓｅｎｄ）との内の小さい方を、第２の送信可能数（ｓｅｎｄ）とする。

【0106】

そして、制御部１１は、レート比制限処理を実行する（ステップＳ４０２）。すなわち、制御部１１は、確認応答が示す受信確認データ量（ａｃｋｅｄ）に、実績送信レートに対する目標送信レートの比を乗算し、この乗算結果に前回の確認応答受信時における余り（ｆｒａｃ）を加算した値（ｒｌｉｍ）を算出する。そして、制御部１１は、その値（ｒｌｉｍ）をパケット長（ｐｌｅｎ）で除算した商を、第３の送信可能数（ｐｌｉｍ）とする。そして、制御部１１は、第３の送信可能数（ｐｌｉｍ）と、第２の送信可能数（ｓｅｎｄ）との内の小さい方を、実際の送信可能数（ｓｅｎｄ）とする。

【0107】

そして、制御部１１は、実際の送信可能数（ｓｅｎｄ）が０より大きいか否かを判定する（ステップＳ４０３）。

【0108】

ここで、実施例１から実施例４を適用した場合の、時間に対する送信レートの変動について説明する。図１６は、時間に対して送信レートが変動する様子の説明に供する図である。図１６には、３つのＲＴＴが示されている。図１６において左及び中央のＲＴＴは、スロースタート状態のＲＴＴを示し、右のＲＴＴは、安定期、つまり確認応答が間断無く届く状態のＲＴＴを示している。また、図１６において、線分Ｌ５１，Ｌ５２，Ｌ５３，Ｌ５４，Ｌ５５は、応答確認のレート（つまり、ＡＣＫレート）を示す。また、線分Ｌ６１，Ｌ６２，Ｌ６３，Ｌ６４は、パケットシェーピングが用いられない従来方法による、パケットの送信レートを示す。また、線分Ｌ７１，Ｌ７２，Ｌ７３，Ｌ７４，Ｌ７５，Ｌ７６は、実施例１から実施例４で説明した技術を適用した場合の送信レートを示す。まず、パケットシェーピングが用いられない従来方法によれば、パケットの送信レートは、ＡＣＫレートの２倍となる。

【0109】

これに対して、図１６の左のＲＴＴにおいて、応答確認が受信されている期間（つまり、線分Ｌ５１，Ｌ５２に対応する期間）では、パケットシェーピングによってＡＣＫレートよりも低いレートでパケットが送信されている。また、図１６の左のＲＴＴにおいて、確認応答が受信されていない期間（つまり、線分Ｌ５１，Ｌ５２に対応する期間と重ならない期間）では、タイマが発動することによってパケットが送信されている。すなわち、送信タイミングを分散させることができるので、バースト性を抑制することができる。

【0110】

また、図１６の中央のＲＴＴにおいて、応答確認が受信されている期間（つまり、線分Ｌ５３，Ｌ５４に対応する期間）では、パケットの送信レートは、ＡＣＫレートよりも少しだけ高くなっている。一方、図１６の中央のＲＴＴにおいて、確認応答が受信されていない期間（つまり、線分Ｌ５３，Ｌ５４に対応する期間と重ならない期間）では、パケットの送信レートは、本来のレートよりも小さくなっている。これは、タイマ分解能の限界と一回で送信するデータ量についての制限とに起因する。ただし、図１６の中央のＲＴＴの全体では、パケットの送信レートは、適正な送信レートに平準化されており、バースト性の抑制が実現されている。

【0111】

また、図１６の右のＲＴＴのように安定期になると、ＡＣＫが間断無く受信される。ＡＣＫレートは種々の変動要素に起因して変動する可能性がある。ただし、実施例１から実施例４で説明した技術を適用することにより、パケットの送信レートを平準化することができる（線分Ｌ７６を参照）。

【0112】

以上のように本実施例によれば、通信端末１０において、制御部１１は、第１のデータ値が送信権利の一時利用上限基本値より小さい場合、第１のデータ量をパケット単位データ量で除した商と等しい個数のパケットを送信する。第１のデータ量は、確認応答の受信時において、確認応答が示す受信確認データ量に、実績送信レートに対する目標送信レートの比を乗算して得られる値である。

【0113】

この通信端末１０の構成により、バースト性が高まることを防止することができる。すなわち、ある程度高い頻度で確認応答が到着するような状況下で、上記の一時利用上限基本値に相当する量のパケットを一度に送信してしまうと、続く確認応答を受信した時にトークンの残量が無くパケットを新たに送信できない事態が起こり得る。このような状況は、確認応答が安定して送信されてくるような状況下においてバースト性を高めてしまう。そこで、上記の通信端末１０の構成によってバースト性が高まることを防止している。特に、実施例３のように一時利用上限基本値を超えた送信権利の蓄積を許容している場合に、特に有効となる。ＯＳ等で管理するタイマによれば同時刻であるが厳密には時間差をもって確認応答が大量に届くように高い送信レートで通信している場合、応答確認毎に一時利用上限基本値に相当するデータ量のパケットを送信すると、前半で纏めてパケットを送信してしまい、後半では送信権利が残っていない状況が起こり易い。そこで、確認応答の受信時において、確認応答が示す受信確認データ量に、実績送信レートに対する目標送信レートの比を乗算して得られる値によって、送信データ量を制限することにより、応答確認毎に送信されるパケットの数を安定化することがでる。これにより、タイマ分解能の単位期間内においてバースト性が高まることを防止することができる。

【0114】

また、制御部１１は、第１のデータ量を前記パケット単位データ量で除した結果、余りが生じた場合、確認応答の次回の受信時において、余りを受信確認データ量に加算する。

【0115】

この通信端末１０の構成により、パケット長に満たない、送信権利の残量を有効に活用することができるので、送信レートを目標送信レートに近づけることができる。

【0116】

［他の実施例］
［１］実施例１から実施例４では、通信端末１０がネットワーク５０に有線で接続されていることを前提に説明したが、これに限定されない。通信端末１０は、無線でネットワーク５０と接続されていてもよい。

【0117】

［２］実施例１から実施例４で図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

【0118】

更に、各装置で行われる各種処理機能は、ＣＰＵ（Central Processing Unit）（又はＭＰＵ（Micro Processing Unit）、ＭＣＵ（Micro Controller Unit）等のマイクロ・コンピュータ）上で、その全部又は任意の一部を実行するようにしてもよい。また、各種処理機能は、ＣＰＵ（又はＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行するプログラム上、又はワイヤードロジックによるハードウェア上で、その全部又は任意の一部を実行するようにしてもよい。

【0119】

実施例１から実施例４の通信端末は、例えば、次のようなハードウェア構成により実現することができる。

【0120】

図１７は、通信端末のハードウェア構成例を示す図である。図１７に示すように、通信端末１００は、通信回路１０１と、プロセッサ１０２と、メモリ１０３とを有する。

【0121】

プロセッサ１０２の一例としては、ＣＰＵ、ＤＳＰ（Digital Signal Processor）、ＦＰＧＡ（Field Programmable Gate Array）等が挙げられる。また、メモリ１０３の一例としては、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）等のＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ等が挙げられる。

【0122】

そして、実施例１から実施例４の通信端末１０で行われる各種処理機能は、不揮発性記憶媒体などの各種メモリに格納されたプログラムを通話装置が備えるプロセッサで実行することによって実現してもよい。すなわち、制御部１１によって実行される各処理に対応するプログラムがメモリ１０３に記録され、各プログラムがプロセッサ１０２で実行されてもよい。また、制御部１１によって実行される各処理は、ベースバンドＣＰＵ及びアプリケーションＣＰＵ等の複数のプロセッサによって分担されて実行されてもよい。また、送信部１３及び受信部１４は、通信回路１０１によって実現される。また、送信バッファ１２は、メモリ１０３によって実現される。

【符号の説明】

【0123】

１ 通信システム
１０，３０ 通信端末
１１ 制御部
１２ 送信バッファ
１３ 送信部
１４ 受信部
５０ ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】