JPH1023017A - 通信システム、通信端末及び通信方法 - Google Patents

Abstract

(57)【要約】 【課題】 ＡＣＫ等の送達確認が送信される回数を減ら
す一方で送達確認に起因するデータ転送の待ち状態を回
避すること。 【解決手段】 送信側では、一塊として送信することが
可能なデータの量（）に応じた量のデータを複数回に
分けて、例えばパケットとして送信する（…）。受信
側では、一塊として送信されるデータの量を予測し
（）、複数回に渡り受信したデータの総量（）がこ
の予測量（）を越えたとき、送達確認を送信側に返送
する（）。そして、送信側では、一塊として送信する
ことが可能なデータの量（）を、受信側から送られる
送達確認に応じて増減している。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、例えば端末間でパ
ケット通信を行う通信システムに係り、特に音声や画
像、データの通信を行うマルチメディアをサポートする
パケット通信などに好適な通信システム、通信端末及び
通信方法に関する。

【０００２】

【従来の技術】コンピュータなどの端末間で通信を行う
時に用いるトランスポート層プロトコルとしてＴＣＰ
（Transmission Control Protocol)がある。ＴＣＰでは
データを受信した端末がデータを送信した端末に対して
送達確認、たとえばＡＣＫの応答を返すことにより誤り
制御を行う。

【０００３】イーサネットで接続される端末間で、デー
タをアプリケーションにダウンロードした時のＴＣＰの
シーケンスを図１０に示す。

【０００４】ワークステーション（ＷＳ１）がワークス
テーション（ＷＳ２）とＴＣＰの接続を行い、データを
ダウンロードし、その応答をワークステーション（ＷＳ
１）がワークステーション（ＷＳ２）に返している。

【０００５】図１０では、ウィンドウサイズを8760バイ
ト、コンジェスチョンウィンドウを4380バイトとした時
からの変化を表している。イーサネットでは、一回で送
信できる最大パケット長は1500バイトであり、通常ＴＣ
Ｐ／ＩΡ（Internet Protocol)のオーバーヘッド40バイ
トを引いた1460バイトが一回の送信で送ることのできる
データ量となる。「ウィンドウサイズ」とは、受信側に
おいて受信可能なデータ量であり、「コンジェスチョン
ウィンドウ」とは、送信側において送達確認を受信する
までに送信できるデータ量である。また、一回の送信で
送ることのできる最大データ量（上記の例でいうと1460
バイト）を「最大セグメントサイズ」と呼ぶ。従って、
ワークステーションＷＳ２は、ワークステーションＷＳ
１に送信するデータをＴＣＰ層で1460バイトに分割し、
1パケット中のデータを1460バイトとしてワークステー
ションＷＳ１に送信することになる。

【０００６】ＴＣＰでは、フロー制御としてスライディ
ングウィンドウによる制御を行っている。「スライディ
ングウィンドウによる制御」とは、送信側は受信側から
示されたウィンドウサイズから、送信の度にデータ分を
減らしていき、ウィンドウサイズがなくなった場合には
送信を止めることをいう。

【０００７】ウィンドウサイズの初期値は受信側から提
示されるウィンドウサイズを用いる。これは受信側から
の送達確認とともに送信され、送信側はこの送達確認を
受信するたびに、ウィンドウサイズを更新する。

【０００８】また、送信側は前述したウィンドウサイズ
と同じように送信するたびにコンジェスチョンウィンド
ウを減らしていき、ウィンドウサイズかコンジェスチョ
ンウィンドウのいずれかがなくなった場合には、それ以
上の送信をストップする。

【０００９】コンジェスチョンウィンドウの初期値は、
コネクションが確立して最初の送受信が行われる時の最
大セグメントサイズの値（上記の例でいうと1460バイ
ト）に設定される。次に、正常な送達確認が受信側から
送信された時には最大セグメントサイズに最大セグメン
トサイズを足した値（上記の例でいうと2920バイト）を
初期値として、以降の送信を行う。以降、初期値を保持
しておき正常な送達確認が受信された場合は最大セグメ
ントサイズを初期値に足して新たな初期値とする等の処
理を行う。

【００１０】図１０において、まず、ワークステーショ
ンＷＳ２はウィンドウサイズとコンジェスチョンウィン
ドウのうち数の少ない方（図１０の例でいうと、コンジ
ェスチョンウィンドウ）の値を見て、送信したいパケッ
トに対して十分な量が確保されているかを判断する。十
分な量が確保されていると判断した場合は送信を行い、
そうでない場合は送信を行わず、ワークステーションＷ
Ｓ１からの送達確認によってウィンドウが確保されるま
で待つ。

【００１１】図１０において、送信可能であって送信を
行うものとすると、ワークステーションＷＳ２は、まず
1460バイトのデータをワークステーションＷＳ１に送る
（図１０）と共に、ウィンドウサイズを8760から1460
を引いて、7300バイト、コンジェスチョンウィンドウを
4380から1460引いて2920とする。このようにワークステ
ーションＷＳ２は、データを送信するたびに、送信可能
バイト数を減らしていく（図１０）。そして、ワーク
ステーションＷＳ１は正しいデータを受信したことを確
認して、それらのデータに対する送達確認とウィンドウ
サイズを応答として返す（図１０）。ワークステーシ
ョンＷＳ２は、ワークステーションＷＳ１から応答を受
信すると、応答に含まれているウィンドウサイズ（受信
可能バイト数）によりワークステーションＷＳ２のウィ
ンドウサイズ（送信可能バイト数）と、コンジェスチョ
ンウィンドウを前述した初期値の設定方法によって更新
する。図１０では、受信側から提示されるウィンドウサ
イズが8760バイトであるので初期値にリセットされ、コ
ンジェスチョンウィンドウは正常な送達確認が送信され
る場合に相当するので最大セグメントサイズ分を足し
て、4380から5840になる。 図１０に示すように、複数
のパケットによって伝送されたデータに対して一つの応
答を返すことにより、パケット毎に応答を返す方法より
もワークステーションＷＳ１からワークステーションＷ
Ｓ２への伝送路を有効に利用することができる。

【００１２】ところで、送達確認送信の仕組みとして
は、受信側のΤＣΡでは受信したパケットのうちでアプ
リケーションに渡された量を計算し、その値が予め定め
られた一定値（例えば上記の例でいうと2920）以上にな
った場合に送達確認を送信している。この予め定められ
た一定値は最大セグメントサイズのパケットが数個分に
相当する比較的小さな値であるため、送信側から連続し
てパケットが送信される場合には受信側で数個分のパケ
ットを受信処理した後にすぐに送達確認が送信されるの
で時間のロスが生じない。

【００１３】しかしながら、ワークステーションＷＳ１
において上記の一定値を越えてパケットを連続して受信
する場合には、頻繁に送達確認を送信することになる。
例えば、上記の一定値がパケット２個分に相当し、連続
して送信するパケットが１０個の場合には、５回送達確
認を送信することになる。このため、ワークステーショ
ンＷＳ１からワークステーションＷＳ２への妨げとな
る。

【００１４】一方、送信側からのパケットの送信頻度が
少ない場合などで、受信側のＴＣＰでアプリケーション
に渡されるパケットの量が前述した一定値を越えないま
ま長い時間が経過する場合にもパケットの受信側から送
達確認が送信されるようにするため、図１１に示すよう
に最初にパケットを受信した際にタイマーを起動し（図
１１）、そのタイマーがタイムアウトする（図１１
）ことで送達確認が送信される（図１１）ようにな
っている。

【００１５】しかしながら、この場合、例えば図１１
で示すように時間的に空きが生じてしまい、データが伝
送されない無駄な時間が生じ、結果的にデータ転送に時
間を要するという問題があった。

【００１６】

【発明が解決しようとする課題】本発明の目的は、ＡＣ
Ｋ等の送達確認が送信される回数を減らし、伝送路の有
効利用を図ることができる通信システム、通信端末及び
通信方法を提供することにある。

【００１７】本発明の目的は、送達確認に起因するデー
タ転送の待ち状態を回避し、結果的にデータ転送を迅速
に行うことができる通信システム、通信端末及び通信方
法を提供することにある。

【００１８】

【課題を解決するための手段】請求項１記載の本発明の
通信システムは、送受信端末間で一塊のデータを複数回
に分けて送受信する通信システムであって、送信端末
が、一塊として送信することが可能なデータの量を、受
信端末から送られる送達確認に応じて増減し、受信端末
が、前記送信端末より送信される一塊のデータの量を予
測し、複数回に渡り受信したデータの総量が前記予測し
た量を越えたときに送達確認を返送することを特徴とす
る。

【００１９】請求項２記載の本発明の通信端末は、複数
回に分けて送信される一塊のデータの量を予測する予測
手段と、この予測手段による予測量に関する情報を記憶
する予測量記憶手段と、複数回に渡り受信したデータの
総量に関する情報を記憶する受信総量記憶手段と、上記
の受信総量が予測量を越えたとき、送達確認をデータ送
信側に返送する手段とを具備する。

【００２０】請求項３記載の本発明の通信方法は、送信
側で、一塊として送信することが可能なデータの量に応
じた量のデータを複数回に分けて送信し、受信側で、一
塊として送信されるデータの量を予測し、複数回に渡り
受信したデータの総量がこの予測量を越えたとき、送達
確認を送信側に返送し、送信側で、前記一塊として送信
することが可能なデータの量を、受信側から送られる送
達確認に応じて増減することを特徴とする。

【００２１】ここで、一塊のデータを複数回に分けて送
受信するとは、例えば一塊のデータをパケットにより送
受信することをいう。しかし、例えばＡＴＭセルのよう
に他の形態でデータを送受信できればそれも含む。

【００２２】上記のデータの総量が予測量を「越えた」
には、データの総量が予測量と等しくなった場合も含ま
れる。

【００２３】送信端末より送信される一塊のデータの量
を予測する手段としては、 （１）予測量が受信データの総量を越えて送達確認を送
信した場合に予測量を増やすこと。

【００２４】（２）タイムアウトにより送達確認を送信
した場合には予測量を減らすこと。

【００２５】（３）重複したデータ、例えば重複したパ
ケットを受信した場合に予測量を更新、例えば最大セグ
メントサイズにすること。

【００２６】（４）重複した送達確認を送信した場合に
予測量を更新、例えば最大セグメントサイズにするこ
と。

【００２７】等がある。しかし、これ以外の他の予測手
段を用いてももちろん構わない。また、これらの予測手
段を２以上組み合わせてもよい。

【００２８】

【発明の実施の形態】図１は本発明の原理を説明するた
めの図である。

【００２９】送信側では、一塊として送信することが可
能なデータの量（）に応じた量のデータを複数回に分
けて、例えばパケットとして送信する（…）。

【００３０】受信側では、一塊として送信されるデータ
の量を予測し（）、複数回に渡り受信したデータの総
量（）がこの予測量（）を越えたとき、送達確認を
送信側に返送する（）。

【００３１】そして、送信側では、一塊として送信する
ことが可能なデータの量（）を、受信側から送られる
送達確認に応じて増減している。

【００３２】従って、本発明では、一塊として送信され
るデータの送信終了にほぼ合致するタイミングで送達確
認が送信側に返送されることになる。つまり必要にして
十分な数の送達確認が送信されることになる。よって、
本発明では、ＡＣＫ等の送達確認が送信される回数を減
らし、伝送路の有効利用を図ることができ、その一方で
送達確認に起因するデータ転送の待ち状態を回避し、結
果的にデータ転送を迅速に行うことができるようにな
る。

【００３３】

【実施例】図２は一実施例に係る通信システムの構成図
である。

【００３４】図２に示すように、このシステムでは、ワ
ークステーションＷＳ１とワークステーションＷＳ２と
が通信路３を介して接続されている。ワークステーショ
ンＷＳ１とワークステーションＷＳ２は、パケット通信
端末装置４を有し、ＴＣＰ（Transmission Control Pro
tocol)に従ってデータの送受を行う。

【００３５】図３はパケット通信端末装置４の構成を示
す図である。

【００３６】図３に示すように、パケット通信端末装置
４は、通信路３を介して相手側の端末から送られるパケ
ットを受信する受信手段５、通信路３を介して相手側の
端末に向けてパケットを送信する送信手段６、装置全体
を統括的に制御する制御手段７、複数回に渡り受信した
データの総量を記憶する受信データ量保持手段８、予測
量としての送達確認しきい値（予測値）を記憶する送達
確認しきい値保持手段９及びタイマー１０を備える。

【００３７】図４及び図５はパケット通信端末装置４の
送信側の動作及び受信側の動作を示すフローチャートで
ある。

【００３８】まず、送信側の動作を説明する。

【００３９】送信側では、受信側との間でコネクション
が確立した後、送信可能であるかどうかを判断する（ス
テップ４０１）。そして、送信可能な場合には、パケッ
トを送信する（ステップ４０２）。その際、そのパケッ
トが以前に送信したパケットであるときには（ステップ
４０３）、一度に送信できる量を最大セグメントサイズ
とする（ステップ４０４）。以下、このような送信動作
を繰り返す。

【００４０】「最大セグメントサイズ」とは、すでに述
べたように一回の送信で送ることのできる最大データ量
（本例でいうと1460バイト）である。

【００４１】その後、送達確認（以下、ＡＣＫと呼
ぶ。）を受信することになる（ステップ４０５、４０
６）。そして、ＡＣＫを受信すると、一度に送信できる
量すなわち一塊として送信することが可能なデータの量
を決められた式で増やす（ステップ４０７）。しかし、
同じＡＣＫを３回連続受信したときには（ステップ４０
８）、一度に送信できる量すなわち一塊として送信する
ことが可能なデータの量を半分にする（ステップ４０
９）。

【００４２】次に、受信側の動作を説明する。

【００４３】すなわち、受信側では、パケットを受信す
ると（ステップ５０１）、まず以前きたパケットと同じ
かどうかを判断する（ステップ５０２）。同じパケット
であるときには、予測値を最大セグメントサイズにする
（ステップ５０３）。次に、順序の異なったパケットで
あるかどうかを判断する（ステップ５０４）。

【００４４】順序の異なったパケットを受信したときに
は、受信側が期待したパケットを要求するＡＣＫを送信
する（ステップ５０５）。例えば、１番目のパケットを
受信して次に３番目のパケットを受信したときには、２
番目のパケットを要求するＡＣＫを送信する。そして、
同一のＡＣＫを３回連続して送信したときには（ステッ
プ５０６）、予測値を現在の半分にする（ステップ５０
７）。例えば、２番目のパケットを要求するＡＣＫを３
回連続して送信したときには、予測値を半分にする。

【００４５】一方、順番どおりのパケットを受信してい
るときには、まずタイマーをセットし（ステップ５０
８）、受信データ量を受信データ量保持手段８内の値に
加える（ステップ５０９）。そして、受信データ量保持
手段８内の値が予測値を越えたかどうかを判断する（ス
テップ５１０）。予測値を越えていない場合には、パケ
ットの受信を上記の動作に従って繰り返すが、予測値を
越えた場合には、予測値を最大セグメント分増やして
（ステップ５１１）タイマーをリセットする（ステップ
５１２）と共に、受信データ量保持手段８内の値を０に
して（ステップ５１３）ＡＣＫを送信する（ステップ５
１４）。ただし、ステップ５０８からステップ５１３の
間にタイマーがきれてタイムアウトしたときには（ステ
ップ５１５）、予測値を現在の０．８倍とした後（ステ
ップ５１６）、受信データ量保持手段８内の値を０にし
て（ステップ５１３）ＡＣＫを送信する（ステップ５１
４）。

【００４６】次に、各種の事例につき説明する。

【００４７】事例１ 図６ではコンジェスチョンウィンドウが5840バイト、ウ
ィンドウサイズが 11680バイトである。なお、両方のう
ち最小の値をとって、これをカレントウィンドウと呼
ぶ。ワークステーションＷＳ２は、ワークステーション
ＷＳ１に1460バイトづつデータを送信し、それをワーク
ステーションＷＳ１が受信するものとする。 ワークス
テーションＷＳ２はワークステーションＷＳ１からの応
答がなくても送信できるバイト数であるウィンドウサイ
ズを、送信したバイト数づつ減らしていく。

【００４８】パケットを受信手段５を通して受信したワ
ークステーションＷＳ１の制御手段７は、そのパケット
のデータの長さを計算し、受信データ量保持手段８に保
持されている値に今受信したパケットのデータ長の値を
加え、受信データ量保持手段８に格納する（ステップ５
０９）。

【００４９】制御手段７は、データパケットを受信した
のでタイマー１０をセットしておく（ステップ５０８）
とともに、送達確認しきい値保持手段９に予め保持して
ある、送信側が一度に送信できる値を予測した量である
送達確認しきい値（Α）と受信データ量保持手段８にあ
る、１度に受信したデータ量（Ｂ）とを比較する（ステ
ップ５１０）。図６では送達確認しきい値を2960バイト
としている。従ってΑ＞Ｂであるので、制御手段７は送
達確認は送信しない判断を下す。

【００５０】送信側では、カレントウィンドウにまだ余
裕があるので（ステップ４０１）、さらに1460バイトの
データを送信する（ステップ４０２）。先と同じように
ウィンドウサイズ、コンジェスチョンウィンドウサイズ
を1460減らし、それぞれ2920バイト、8760バイトとな
る。

【００５１】ここで、受信側であるワークステーション
ＷＳ１の制御手段７は、受信データ量保持手段８にある
受信データ量（Ｂ）が2920バイトとなり、送達確認しき
い値保持手段９にある送達確認しきい値（Α）と比べ
（ステップ５０９）、Α＜＝Ｂの式を満たすので、送達
確認を送信手段６を通して、ワークステーションＷＳ２
に向けて送信する（ステップ５１４）。その際、制御手
段７はタイマー１０をオフにし（ステップ５１２）、さ
らに受信データ量保持手段８に格納されている値を０に
する。

【００５２】これにより、タイマー１０のタイムアウト
まで送達確認の送信を避けることができるため、スルー
プットの向上を図ることが可能となる。

【００５３】なお、受信したデータはアプリケーション
が読み込むことになるが、ΤＣＰにおいては、前回の送
達確認が送信されてから後にアプリケーションが読み込
んだデータの量（Ｂ）が、前述した送信側が一度に送信
できる値を予測した量である送達確認しきい値（Α）と
比べ、Α＜＝Ｂの式を満たすかどうかを判断材料として
送達確認を送信することでも同様の効果を得ることがで
きる。

【００５４】ここで、以上の事例では、ワークステーシ
ョンＷＳ１では、正常状態による送達確認であり、受信
データ量の変化による送達確認であるので、送達確認し
きい値（Α）の値を最大セグメントサイズ分増やし、43
80バイトとし、送達確認しきい値保持手段９に保持させ
る。

【００５５】一方、送達確認を受信したワークステーシ
ョンＷＳ２は送達確認に含まれているウィンドウ通知に
従ってウィンドウを更新するとともに、正常な送達確認
であるためコンジェスチョンウィンドウの初期値をを最
大セグメントサイズ分増やして7300バイトにする。

【００５６】これによって、送信側で一度に送信できる
値であるコンジェスチョンウィンドウの初期値の増加に
伴って、受信側での予測値である送達確認しきい値も増
やすことができる。この結果、送達確認を無駄に送信す
ることが防げ、伝送路の有効利用ができる。

【００５７】事例２ 図７において、ワークステーションＷＳ２は、ウィンド
ウサイズが4380バイト、コンジェスチョンウィンドウが
2920バイトであることから（ステップ４０１）、連続し
て2920バイト分のパケットを送信する（ステップ４０
２）。

【００５８】2920バイト分のパケットを受信した（ステ
ップ５０１）ワークステーションＷＳ１は、送達確認し
きい値（Α）が8760バイトであるので、その時点で送達
確認を送信することはできず、タイマー切れを待って
（ステップ５１５）送信する（ステップ５１４）。そし
てタイマーによる送達確認であるので、制御手段７は送
達確認しきい値保持手段９にある送達確認しきい値
（Α）の値を 0.8倍する（ステップ５１６）。また、制
御手段７は受信データ量保持手段８に格納されている値
を０にする（ステップ５１３）。

【００５９】これによって、送信側で一度に送信できる
値であるコンジェスチョンウィンドウの初期値より、受
信側での予測値である送達確認しきい値が大きいことを
検出して、その予測値を小さくすることができる。この
結果、タイマーのタイムアウトまで送達確認の送信を待
つことを避けることができ、スループットの向上を図る
ことが可能となる。

【００６０】なお、ここで述べた事例では、送達確認し
きい値（Α）を 0.8倍したが、その値は１より小さけれ
ばよく、またこの様に１より小さい値との積を計算する
方法の他にも、例えば送達確認しきい値からある値を減
ずる方法でも同様な効果を得ることができる。

【００６１】事例３ 図８に示すように、送信側であるワークステーションＷ
Ｓ２が、あるＰというパケットを送信し、ある一定の間
にＰに対する送達確認がワークステーションＷＳ１から
送信されてこない場合、ワークステーションＷＳ２はタ
イムアウトを起こし、パケットＰを再送する（ステップ
４０２）。その際、ワークステーションＷＳ２は、コン
ジェスチョンウィンドウを最大パケットサイズと同じに
する（ステップ４０３、４０４）。

【００６２】受信側であるワークステーションＷＳ１
は、最初に送信されてきたパケットＰに対する送達確認
を送信する。その後、ワークステーションＷＳ２はパケ
ットＰに続くパケットを期待しているので、さらにパケ
ットＰが送信されてきた場合は（ステップ５０２）、制
御手段７はパケットＰが再送されたものと判断し、パケ
ットＰに対する送達確認を再び送信するとともに送達確
認しきい値保持手段９にある送達確認しきい値（Α）を
最大セグメントサイズにする（ステップ５０３）。 こ
れによって、送信側で一度に送信できる値であるコンジ
ェスチョンウィンドウの初期値の減少に伴って、受信側
での予測値である送達確認しきい値も減らすことができ
る。この結果、タイマーのタイムアウトまで送達確認の
送信を待つことを避けることができ、スループットの向
上を図ることが可能となる。

【００６３】事例４ 図９に示すように、送信側であるワークステーションＷ
Ｓ２が、一度の送信で連続して５つのパケットを送信可
能であり、また送信したとする。そしてネットワーク中
の何らかの障害で２番目のパケットが失われた場合、ワ
ークステーションＷＳ１は、１番目のパケットを受信
後、送信側が３番目に送信したパケットを受信すること
になる。ワークステーションＷＳ１は順番の異なったパ
ケットを受信したため（ステップ５０４）、その失われ
たパケットを期待する送達確認をワークステーションＷ
Ｓ２に送信する（ステップ５０５）。同じことをワーク
ステーションＷＳ２が４番目、５番目に送信したパケッ
トを受信したときに行う。３つの同じパケットを期待す
る送達確認（重複送達確認）を送信したので（ステップ
５０６）、制御手段７は送達確認しきい値保持手段９に
ある送達確認しきい値（Α）を半分にする（ステップ５
０７）。

【００６４】重複送達確認を３つ受信したワークステー
ションＷＳ２は（ステップ４０８）、送達確認に含まれ
ているウィンドウ通知に従ってウィンドウを更新すると
ともに、重複送達確認を３つ受信した時の対応としてコ
ンジェスチョンウィンドウを例えば半分にする（ステッ
プ４０９）。

【００６５】これによって、送信側で一度に送信できる
値であるコンジェスチョンウィンドウの初期値の減少に
伴って、受信側での予測値である送達確認しきい値も減
らすことができる。この結果、タイマーのタイムアウト
まで送達確認の送信を待つことを避けることができ、ス
ループットの向上を図ることが可能となる。

【００６６】以上の例により、受信側では、送信側のカ
レントウィンドウを予測できるので、タイムアウトによ
る送信や、送達確認しきい値（Α）がカレントウィンド
ウより極端に低いことから起こる不必要な送達確認を避
けることが可能となる。

【００６７】

【発明の効果】以上説明したように、本発明によれば、
一塊として送信されるデータの送信終了にほぼ合致する
タイミングで送達確認が送信側に返送されることになる
ので、ＡＣＫ等の送達確認が送信される回数を減らし、
伝送路の有効利用を図ることができ、その一方で送達確
認に起因するデータ転送の待ち状態を回避し、結果的に
データ転送を迅速に行うことができるようになる。

【図面の簡単な説明】

【図１】本発明の原理を説明するための図である。

【図２】本発明の一実施例に係る通信システムの構成図
である。

【図３】図２のパケット通信端末装置４の構成を示す図
である。

【図４】パケット通信端末装置４の送信側の動作及び受
信側の動作を示すフローチャートである（分図その
１）。

【図５】パケット通信端末装置４の送信側の動作及び受
信側の動作を示すフローチャートである（分図その
２）。

【図６】本発明に係る事例１を説明するための図であ
る。

【図７】本発明に係る事例２を説明するための図であ
る。

【図８】本発明に係る事例３を説明するための図であ
る。

【図９】本発明に係る事例４を説明するための図であ
る。

【図１０】従来のＴＣΡにおける一例を示す図である。

【図１１】従来のＴＣΡにおける一例を示す図である。

【符号の説明】 一塊として送信することが可能なデータの量 パケット 予測量 複数回に渡り受信したデータの総量 送達確認

Claims (3)

【特許請求の範囲】
1. 【請求項１】 送受信端末間で一塊のデータを複数回に
   分けて送受信する通信システムであって、 送信端末が、一塊として送信することが可能なデータの
   量を、受信端末から送られる送達確認に応じて増減し、 受信端末が、前記送信端末より送信される一塊のデータ
   の量を予測し、複数回に渡り受信したデータの総量が前
   記予測した量を越えたときに送達確認を返送することを
   特徴とする通信システム。
2. 【請求項２】 複数回に分けて送信される一塊のデータ
   の量を予測する予測手段と、 この予測手段による予測量に関する情報を記憶する予測
   量記憶手段と、 複数回に渡り受信したデータの総量に関する情報を記憶
   する受信総量記憶手段と、 上記の受信総量が予測量を越えたとき、送達確認をデー
   タ送信側に返送する手段とを具備することを特徴とする
   通信端末。
3. 【請求項３】 送信側で、一塊として送信することが可
   能なデータの量に応じた量のデータを複数回に分けて送
   信し、 受信側で、一塊として送信されるデータの量を予測し、
   複数回に渡り受信したデータの総量がこの予測量を越え
   たとき、送達確認を送信側に返送し、 送信側で、前記一塊として送信することが可能なデータ
   の量を、受信側から送られる送達確認に応じて増減する
   ことを特徴とする通信方法。