JPH11341064A

JPH11341064A - 通信装置及び方法及びシステム及び記憶媒体

Info

Publication number: JPH11341064A
Application number: JP15022198A
Authority: JP
Inventors: Tomohiko Shimoyama; 朋彦下山
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 1998-05-29
Filing date: 1998-05-29
Publication date: 1999-12-10

Abstract

(57)【要約】【課題】ネットワークの状況に応じて動的に適切な送
信レートにさせ、最少の伝送遅延で通信を行うことを可
能にする。【解決手段】情報を送信する際、送信レートを徐々に
上げていく最中に、受信側端末からのｒｔｃｐデータに
基づいて伝送遅延時間が増加したかどうかを判断する。
伝送遅延時間が増加した場合には、その通信帯域を越え
た場合であると判断し、それ以上送信レートを増加させ
ないで、安定状態に移行する。そして、所定の期間経過
した場合には、今度は送信レートを徐々に下げていく処
理を行なう。この過程で、伝送遅延時間が小さくならな
いようなら、ネットワーク上のバッファ容量以下で送信
しているものとを判定し、安定状態に移行する。以下、
これの処理を繰り返す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はネットワークを介し
て発信側端末から受信側端末に向けてデータを送信する
通信装置及び方法及びシステム及び記憶媒体、特に、実
時間データの転送に関するものである。

【０００２】

【従来の技術】近年、インターネットなどの通信回線を
通じ、動画や音声などの実時間データを送信するシステ
ムが現れている。これらのシステムでは、送信側での送
信レート制御が重要となる。通信回線の帯域を越えた送
信レートで実時間データを送信すると、（１）ネットワ
ーク上のルーターなどのバッファに送信したデータが蓄
積され伝送遅延が大きくなり、（２）その後それらのバ
ッファがあふれるとパケットロスが生じる、などの弊害
が生じる。

【０００３】これまでの実装では、パケットロスを監視
しパケットロスが生じた時点で送信レートを抑えること
で、パケットロスが起きないように送信レートを制御し
ている。

【０００４】

【発明が解決しようとする課題】しかしながら、これま
での実装では、上記（２）の問題には対処できても、
（１）の伝送遅延の問題には対処することができない。
そのため、テレビ会議など映像転送に使用すると受けて
側では数十秒前の画像が表示されるなど、伝送遅延が大
きな問題となる。

【０００５】

【課題を解決するための手段】本発明はかかる問題点に
鑑みなされたものであり、ネットワークの状況に応じて
動的に適切な送信レートにさせ、最少の伝送遅延で通信
を行うことを可能ならしめる通信装置及び方法及びシス
テム及び記憶媒体を提供しようとするものである。

【０００６】この課題を解決するため、例えば本発明の
通信装置は以下の構成を備える。すなわち、所定のネッ
トワークを介して受信側端末に向けて情報を送信すると
共に、前記受信側端末が所定時間間隔で送信する受信状
況情報を受信する通信装置であって、前記受信側端末か
らの複数の受信状況情報に基づいて伝送遅延の状態を検
出する検出手段と、検出された伝送遅延の状態に応じて
送信レートを制御する制御手段とを備える。

【０００７】

【発明の実施の形態】以下、添付図面にしたがって本発
明にかかる実施形態を説明する。

【０００８】本実施形態においては、通信回線上の伝送
遅延時間を元に送信レートを制御することで解決する。

【０００９】特にｒｔｐ（Realtime Transport Protoco
l）（ＲＦＣ１８８９）のように伝送プロトコルから伝
送遅延時間を得ることが難しい時には、通信回線上をパ
ケットの往復にかかる時間（ＲＴＴ(Round Trip Time)
で伝送遅延時間を見積もる。

【００１０】送信レートを増減した結果、伝送遅延時間
が変化するかどうかで、その後の送信レートを制御す
る。これは定期的に送信レートを増減し、そのとき伝送
遅延時間がどう変化するかを監視することで実現する。

【００１１】送信レートを上げてゆくときには次の制御
を行う。つまり、レートを上げても伝送遅延時間が増加
しないようなら、通信帯域が余っていると判断してさら
に送信レートを上げる。伝送遅延時間が増加するような
ら、通信帯域以上のデータを送っていると判断してそれ
以上への送信レートを上げることを中止する。そして、
所定の時間だけ、そのときの送信レートで送信を続け
る。この時間が経過すると、今度は以下に示す送信レー
トを下げる工程を実行する。

【００１２】送信レートを下げてゆく過程では、レート
を下げていく際に、伝送遅延時間が減少するようなら、
通信回線上でデータがバッファリングされていると判断
してさらに送信レートを下げる。一方、伝送遅延時間が
変わらないようなら、通信回線上ではデータはバッファ
リングされていないと判断して送信レートを下げること
を中止し、所定の時間だけそのときの送信レートで送信
を続ける。この時間が経過すると、今度は先に説明した
送信レートを上げる処理を行なう。以上の説明の状態遷
移を示したのが図１である。

【００１３】次に、上記の処理を実現するための、実施
形態におけるシステム全体図を図２に示し、以下にその
動作を説明する。ここでは、ネットワーク（例えばイン
ターネット等）３００により接続された送信側端末１０
０と受信側端末２００により構成されるシステムのみを
示しているが、ネットワーク上には多数の端末が接続さ
れていても構わない。また、送信側端末、受信側端末は
便宜的なものであって、例えば双方がカメラ装置を接続
し互いに映像を送信し、互いに受信する場合にも適用で
きるのは以下の説明から明らかになるであろう。更に、
送信側端末１００、受信側端末２００とも、独立した計
算機であって、例えばパーソナルコンピュータやワーク
ステーションをそのベースにしている。

【００１４】また、以下の説明に先立ち、受信側端末２
００は、ＲＦＣ１８８９の規約に従い、例えば５秒間隔
毎にＲＴＣＰ（rtp Control Protocol）にしたがったデ
ータ（以下、ｒｔｃｐデータという）を送信側端末１０
０に返信する。

【００１５】さて、本実施形態では、送信側端末１００
から受信側端末２００に対してｒｔｐを使用してデータ
（例えばカメラで撮影された映像データ）を送信する。
本実施形態ではｒｔｐ，ｒｔｃｐを送受信する機構はソ
フトウェアとして実現するが、同様の機能をハードウェ
アにより実現することも可能であり、本発明を限定する
ものではない。

【００１６】送信側端末１００と受信側端末２００はｒ
ｔｐ（ＲＦＣ１８８９）が定めるように、ｒｔｐにより
データの送受信を行い、ｒｔｃｐによりその制御データ
を転送している。ｒｔｐ，ｒｔｃｐの詳細に関しては周
知であるのでここでの詳述はしない。

【００１７】本実施形態では、送信側端末１００は、初
期段階では、受信側端末のユーザが指定したレート（も
しくは予め設定されたレート、以下、これらを総称して
目標レートという）で受信側端末２００に対してデータ
を送信する。このデータの送受信にはｒｔｐを使用す
る。そして、先に説明したように、もし回線状況が悪く
目標レートでデータを送れない場合には送信レートを落
とし、回線状態がよくなれば送信レートを上げて目標レ
ートに送信レートを近付ける。

【００１８】また送信側端末１００，受信側端末２００
は、ｒｔｃｐを使用して通信回線の制御情報を交換す
る。これらのｒｔｃｐを使用して、送信側端末１００，
受信側端末２００はレート制御を行う。説明が前後する
が、送信側端末１００は情報をパケットとして受信側端
末に向けてＲＴＰで送信するが、各パケットにはシーケ
ンス番号（順次大きくなる番号）を付加させて送るもの
である。

【００１９】受信側端末２００は送信側端末１０に対し
て制御情報をｒｔｃｐにしたがって返送する。この制御
情報（受信側端末２００が送信側端末１００に返信する
情報）に含まれる主だった情報は次の通りである。

【００２０】・ｒｔｃｐを送り出した時点で最後に受け
取ったｒｔｐパケットのシーケンス番号（以下、high-s
eqと略する）・ｒｔｃｐを送り出した時点でのlost packetの通算
（以下cum-lost と略する）・ｒｔｃｐを送り出した時点で最後に受け取った送信側
端末からのｒｔｃｐに含まれる時刻情報（以下、timest
amp）・上記の送信側端末からのｒｔｃｐを受け取ってからそ
のｒｔｃｐを送信するまでに要した時間(difference la
st sender report）送信側端末１００は、受信側端末からの制御情報に含ま
れるこれらの情報とその制御情報を受信した時刻を元
に、送信レートを決定する。本実施形態ではこれらの情
報から受信側端末２００の実効受信レートとＲＴＴ(Rou
nd Ttip Time=往復時間)を算出する。ＲＴＴは、受信側
が返信してくるｒｔｃｐデータ中に含まれているtimest
ampとそのｒｔｃｐデータを受信した時刻から、受信側
端末が返信用のｒｔｃｐデータを作成するに要した時刻
を減じることで得られる。

【００２１】送信側端末１００の送信レートは実効受信
レート基準に、先の図１に示したアルゴリズムで決め
る。通常は“送信レート＝実効受信レート”で送信す
る。ＲＴＴは回線遅延時間の近似値として、その送信結
果の評価に用いる。

【００２２】そして定期的（ｒｔｃｐデータを受信側端
末から受信する度）に“実効受信レート＋α”のレート
で送信し、もっと帯域を増やせないか調べる。その結果
ＲＴＴが増加していく、つまり、往復にかかる時間が大
きくなるようなら、既に帯域を使い切っていると判断し
て送信レートを増加することをやめ、通常の“送信レー
ト＝実効受信レート”で所定時間（実施形態では１０秒
とした）だけ送信を行う（この状態を高レート安定状態
という）。

【００２３】同様に定期的に“実効受信レート−α”の
送信レートで情報を送信し、通信遅延を減らせないか調
べる。その結果ＲＴＴが減少していくようなら、通信遅
延を減らせると判断して引き続き送信レートを絞ってゆ
く。ＲＴＴが減少しないようなら既に通信遅延は最少で
あると判断して送信レートを減少することをやめ、通常
の“送信レート＝実効受信レート”で送信を行う（この
状態を低レート安定状態という）。

【００２４】次に実効受信レートの近似計算方法につい
て説明する。ＲＴＴの算出方法に関してはＲＦＣ１８８
９に示されているので省略する。

【００２５】ｒｔｐの規約では、送信側端末１００は受
信側端末２００の実効受信レートを直接知ることはでき
ない。そこで２つのｒｔｃｐパケット（受信側端末から
送られてきたパケット）から得た情報と、送信側端末１
００でパケットを送った際の情報（後述する図４のパケ
ット記録テーブル）から実効受信レートの近似計算をす
る。

【００２６】今、２つのｒｔｃｐパケット（受信側端末
が５秒間隔で返信してくるｒｔｃｐデータ）を、ｒｔｃ
ｐ０，ｒｔｃｐ１（ｒｔｃｐ０の方が先に来たパケッ
ト）とする。

【００２７】ｒｔｃｐ０，ｒｔｃｐ１の到着時間を送信
側端末１００で記録しておく。これによりｒｔｃｐ０と
ｒｔｃｐ１との間隔△ｔがわかる。

【００２８】△ｔの間に送信側端末１００が送ったデー
タ量は、ｒｔｃｐ０，ｒｔｃｐ１に含まれるそれぞれの
high-seqが、図４のパケット記録テーブルを調べること
で得られる。例えば、ｒｔｃｐ０に含まれていたhigh-s
eqが“５１４”で、ｒｔｃｐ１に含まれていたhigh-seq
が“５５０”であれば、図４のシーケンス番号５１４〜
５５０までの送信サイズの合計を演算すればよい。な
お、パケット記録テーブルは有限のサイズ（実施形態で
は２５６個分の格納できる容量）であるので、リング構
造をしている。例えば、ｒｔｐパケット（映像データ）
を送信する際、そのシーケンス番号が“７６６”である
ならば、それを２５６で割った余りの値“２５４”で示
される位置、つまり、テーブルの上から２５４番目にそ
の時の送信サイズを格納する。

【００２９】また、△ｔの間のパケットロス率の計算
も、ｒｔｃｐ０，ｒｔｃｐ１に含まれるhigh-seqとcum-
lostにより計算する。ｒｔｃｐ１のhigh-seqとｒｔｃｐ
０のhigh-seqの差から、△ｔの間に送信側端末１００が
送ったパケット数がわかる。同様にすることで、△ｔの
間に受信側端末１００までにロストしたパケットの数が
わかる。ここで、cum-lostは、送信パケット数から、実
際に受信したパケット数を減じた値であり、パケットロ
ス率は、ロスパケット数／送信パケット総数となる。

【００３０】したがって、実効受信レートは、送信パケット数×（１−パケットロス率）／Δｔで求めることができる。

【００３１】実効受信レートは、受信側端末２００から
ｒｔｃｐパケットを受信する度に計算し、メモリ等に記
憶する。

【００３２】次に送信側端末１００の内部について図３
を使って説明する。送信側端末１００はｒｔｐ送信部１
１０、ｒｔｃｐ送信部１２０、ｒｔｃｐ受信部１３０、
パケット記録テーブル１４０（図４参照）からなる。ｒ
ｔｃｐ受信部１３０の内部には、実施形態の送信レート
制御を行うレート制御部１３１がある。

【００３３】ｒｔｐ送信部１１０、ｒｔｃｐ送信部１２
０、ｒｔｃｐ受信部１３０は別々のtスレッドとして独
立に動作するものの、互いに共有変数を通じて連係をと
る。

【００３４】レート制御部１３１はｒｔｃｐ受信部１３
０のスレッドから呼び出されるサブルーチンの形で実装
している。

【００３５】パケット記録テーブルは図４に示したよう
に、パケットのシーケンス番号とそのときのパケットサ
イズを記録している。図示の如く、テーブルはリングバ
ッファとして構成されており、記録する際にはパケット
のシーケンス番号をテーブルを構成する項目数の剰余を
インデックスとしてテーブル内の記録位置を決める。こ
れにより過去２５６（２５６は表のサイズ）個のパケッ
トについての情報を保持している。

【００３６】パケット記録テーブル１４０はｒｔｐ送信
部１１０、レート制御部１３１により共有される。ｒｔ
ｐ送信部１１０はパケットを送信する度に、パケット記
録表１４０に送信情報を書き込む。ｒｔｃｐ受信部１３
０のなかから呼び出されるレート制御部１３１は基本的
に、ｒｔｃｐが受信される度に受信レートを更新する。
その際にレート制御部１３１はパケット記録表１４０を
アクセスする。

【００３７】各部のフローチャートを図５〜図８に示
す。

【００３８】図５は実施形態における送信側端末１００
のｒｔｐ送信部１１０のフローチャートである。送信側
端末は１０２４ｂｙｔｅの大きさのパケットをそのとき
の送信レート期間ごと（（１０２４ｂｙｔｅ／送信レー
ト）秒の期間ごと）に出力し、送信結果をパケット記録
テーブル１４０に格納することを繰り返す。ただし、初
期状態では予め設定された目標レートに設定してある。
なお、フローチャート中の“送信レート”はレート制御
部１３１と共有されており、ｒｔｃｐから得た受信側端
末の受信レート、ＲＴＴに従って変更されるものであ
る。

【００３９】図６は送信側端末１００のｒｔｃｐ送信部
１２０のフローチャートである。ｒｔｃｐ送信部１２０
は５秒ごとにアクティブになり、ｒｔｃｐを出力する。
ｒｔｃｐ送信部１２０はｒｔｐ送信部１１０からの送信
情報を元にｒｔｃｐパケットを作成するのだが、それら
に関してはＲＦＣ１８８９に従った既知のものとし説明
を省略する。

【００４０】図７〜図９は送信側端末１００のｒｔｃｐ
受信部１３０、レート制御部１３１のフローチャートで
ある。

【００４１】図７は、ｒｔｃｐ受信部１３０のフローチ
ャートである。

【００４２】ｒｔｃｐ受信部１３０はｒｔｃｐを受信す
ると（ステップＳ１かステップＳ２に進むと）、ｒｔｃ
ｐの情報から受信側端末２００の実効受信レートとＲＴ
Ｔを近似計算する（ステップＳ３）。これらの計算方法
については先に述べたとおりである。

【００４３】もし受信側端末でロスが検出された場合に
は、送信レートを（実効受信レート＊０．８）にして送
信レートを落とす（ステップＳ５）。また、ロスが生じ
ていない場合にはレート制御部１３１に制御を渡す（ス
テップＳ６）。

【００４４】図８は、レート制御部の動作処理内容を示
している。基本的には、図１に示した状態遷移図（図
１）に従うものである。

【００４５】状態がRate Upモードの時には、ＲＴＴを
監視しながら送信レートを徐々に上げていく状態にある
ことを示している。この場合、送信レートを上げてもＲ
ＴＴが増加しないと判定した場合（ステップＳ１４）に
は、さらにレートを上げるために送信レートを、そのと
きの受信レート×１．２と設定する。つまり、２０％だ
け送信レートを上げる。ただし、目標レートを越える設
定は行なわない（ステップＳ１４、Ｓ１５）。

【００４６】また、ＲＴＴが増加するようならば、回線
の帯域を越えた送信を行なっていることになるから、状
態を高レート安定状態（Stay Maxrate）に移行させる
（ステップＳ１６）。このとき、状態がStay Maxrateで
ある時間を測るタイマー（図示せず）をリセットさせ
（ステップＳ１７）、送信レートを直前の受信レートに
設定する。

【００４７】さて、状態が高レート安定状態（Stay Max
rate）である時（ステップＳ４２）にあって、ＲＴＴが
増加した場合には送信レートを下げ、状態をRate Down
モードに切り替えす。ＲＴＴが増加せず、状態がStayMa
xrateである時間を測るタイマーが１０秒を越えるまで
は、その状態を維持する。

【００４８】そして、１０秒経過した場合には、状態を
Rate Downモードに切換え、送信レートを受信レート×
０．８にする。

【００４９】状態がRate Downの時（ステップＳ３１）
には、ＲＴＴを監視しながら送信レートを徐々に下げて
いくことになる。レートを下げる場合には、レートを下
げた結果がフィードバックされる時間を待つために、以
前の送信レートと現在の受信レートを比較する。

【００５０】もし送信レートの方が受信レートよりも大
きい場合には、まだ結果がフィードバックされていない
と判断してＲＴＴの監視をせず、無条件にレートを下げ
たままにする。

【００５１】そうでなければＲＴＴが減少しているかど
うか判断し（ステップＳ３３）、減少しているようなら
引き続きレートを下げたままにする（ステップＳ３
４）。

【００５２】また、減少しなくなった場合には、低レー
ト安定状態（Stay Mindelay）に変え（ステップＳ３
５）、その状態を１０秒間維持するためにタイマーをリ
セットする（ステップＳ３６）。そして、送信レートを
直前の受信レートにセットする。

【００５３】こうして、低レート安定状態（Stay Minde
lay）がはじまるが、ＲＴＴが増加しない限りその状態
が１０秒を越えるまでは、送信レートは変動しない。ま
た、１０秒を越えるか、ＲＴＴが増加した場合には、状
態をRate Upモードに変え、送信レートを受信レート＊
１．２にする。

【００５４】以上の結果、送信側端末１００から受信側
端末２００にデータ（実施形態ではカメラにより撮影さ
れた映像データ）は、ネットワーク（回線）の状況に追
従する送信レートで送信されることになり、実時間送信
が要求される場合に適した転送が行われるようになる。
しかも、目標レートを越える送信レートでは送信しない
ようになっているので、ネットワーク、とくに、インタ
ーネット等の場合の如く、不特定多数のユーザが使用し
ている状況においては他のユーザに与える影響を最小限
にすることもできる。

【００５５】なお、先に説明したように、実施形態にお
ける送信側端末１００、受信側端末２００は共にパーソ
ナルコンピュータやワークステーション等をそのベース
にしている。ネットワークに接続するためのハードウェ
ア（ＮＩＣやモデム、ＴＡ等）や、実時間データを生成
するハード（カメラは動画像を記憶する記憶装置）が必
要であるものの、その処理の大部分はソフトウェアでも
って実現されるものである。

【００５６】したがって、本発明は、前述した実施形態
の機能を実現するソフトウェアのプログラムコードを記
録した記憶媒体を、システムあるいは装置に供給し、そ
のシステムあるいは装置のコンピュータ（またはＣＰＵ
やＭＰＵ）が記憶媒体に格納されたプログラムコードを
読出し実行することによっても、達成されるものである
のは明らかである。

【００５７】この場合、記憶媒体から読出されたプログ
ラムコード自体が前述した実施形態の機能を実現するこ
とになり、そのプログラムコードを記憶した記憶媒体は
本発明を構成することになる。

【００５８】プログラムコードを供給するための記憶媒
体としては、例えば、フロッピディスク，ハードディス
ク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ
−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭな
どを用いることができる。

【００５９】また、コンピュータが読出したプログラム
コードを実行することにより、前述した実施形態の機能
が実現されるだけでなく、そのプログラムコードの指示
に基づき、コンピュータ上で稼働しているＯＳ（オペレ
ーティングシステム）などが実際の処理の一部または全
部を行い、その処理によって前述した実施形態の機能が
実現される場合も含まれることは言うまでもない。

【００６０】さらに、記憶媒体から読出されたプログラ
ムコードが、コンピュータに挿入された機能拡張ボード
やコンピュータに接続された機能拡張ユニットに備わる
メモリに書込まれた後、そのプログラムコードの指示に
基づき、その機能拡張ボードや機能拡張ユニットに備わ
るＣＰＵなどが実際の処理の一部または全部を行い、そ
の処理によって前述した実施形態の機能が実現される場
合も含まれることは言うまでもない。

【００６１】以上の説明から明らかなように本実施形態
によれば、ネットワーク上にデータがバッファリングさ
れ、過大な送信を行うと伝送遅延が大きくなるようなネ
ットワーク上でも、最少の伝送遅延で通信を行うことが
できる。

【００６２】なお、実施形態ではｒｔｃｐデータは５秒
間隔、安定状態は１０秒として設定したが、これらの値
によって本発明が限定されるものではないし、適切であ
れば如何なる値を用いてもよい。また、実施形態では、
受信側端末からの連続する２つのｒｔｃｐデータに基づ
いて受信遅延の状態（特に伝送遅延の大きさ）の変化を
検出したが３つ、或いはそれ以上でもよいのは勿論であ
る。

【００６３】

【発明の効果】以上説明したように本発明によれば、ネ
ットワークの状況に応じて動的に適切な送信レートにさ
せ、最少の伝送遅延で通信を行うことが可能になる。

【００６４】

【図面の簡単な説明】

【図１】実施形態におけるレート制御部のアルゴリズム
を示す状態遷移図である。

【図２】本実施形態のシステムの全体構成図である。

【図３】実施形態における送信側端末ブロック構成図で
ある。

【図４】実施形態におけるパケット記録テーブルの構造
を示す図である。

【図５】実施形態における送信側端末のｒｔｐ送信部の
処理内容を示すフローチャートである。

【図６】実施形態における送信側端末のｒｔｃｐ送信部
の処理内容を示すフローチャートである。

【図７】実施形態における送信側端末のｒｔｃｐ受信部
の処理内容を示すフローチャートである。

【図８】実施形態における送信側端末のレート制御部の
の処理内容を示すフローチャートである。

【図９】実施形態における送信側端末のレート制御部の
の処理内容を示すフローチャートである。

【符号の説明】

１００送信側端末１１０ｒｔｐ送信部１２０ｒｔｃｐ送信部１３０ｒｔｃｐ受信部１３１レート制御部１４０パケット記録表２００受信側端末２１０ｒｔｐ送信部２２０ｒｔｃｐ送信部２３０ｒｔｃｐ受信部３００ネットワーク

Claims

【特許請求の範囲】

【請求項１】所定のネットワークを介して受信側端末
に向けて情報を送信すると共に、前記受信側端末が所定
時間間隔で送信する受信状況情報を受信する通信装置で
あって、前記受信側端末からの複数の受信状況情報に基づいて伝
送遅延の状態を検出する検出手段と、検出された伝送遅延の状態に応じて送信レートを制御す
る制御手段とを備えることを特徴とする通信装置。
【請求項２】前記制御手段は、前記検出手段における
前記受信側端末からの受信状況情報を受信する度に送信
レートを増減させて、当該増減過程での伝送遅延の変化
がなくなった場合には送信レートの増減を停止させるこ
とを周期的に繰り返すことを特徴とする請求項第１項に
記載の通信装置。
【請求項３】前記伝送遅延の状態は、情報伝送の往復
時間の大きさであることを特徴とする請求項第１項又は
第２項に記載の通信装置。
【請求項４】前記制御手段は送信レートを上げていく
最中に遅延変化がなくても、所定の目標転送レート以下
にすることを特徴とする請求項第１項に記載の通信装
置。
【請求項５】前記受信側端末との通信プロトコルはＲ
ＦＣ１８８９を用いることを特徴とする請求項第１項乃
至第４項のいずれか１つに記載の通信装置。
【請求項６】所定のネットワークを介して受信側端末
に向けて情報を送信すると共に、前記受信側端末が所定
時間間隔で送信する受信状況情報を受信する通信装置に
おける通信方法であって、前記受信側端末からの複数の受信状況情報に基づいて伝
送遅延の状態を検出する検出工程と、検出された伝送遅延の状態に応じて送信レートを制御す
る制御工程とを備えることを特徴とする通信方法。
【請求項７】所定のネットワークを介して受信側端末
に向けて情報を送信すると共に、前記受信側端末が所定
時間間隔で送信する受信状況情報を受信する通信装置と
して機能するプログラムコードを格納した記憶媒体であ
って、前記受信側端末からの複数の受信状況情報に基づいて伝
送遅延の状態を検出する検出工程のプログラムコード
と、検出された伝送遅延の状態に応じて送信レートを制御す
る制御工程のプログラムコードとを格納したことを特徴
とする記憶媒体。
【請求項８】所定のネットワークを介して相手先端末
に情報を送信する通信装置であって、相手側端末が所定時間間隔で送信してくる受信状況情報
を受信する受信手段と、受信した受信状況情報に基づいて、相手先端末への情報
伝送にかかる伝送遅延時間を検出する検出手段と、相手先端末への情報伝送の転送レートを徐々に増加させ
る第１のモードと、徐々に減少させる第２のモードのい
ずれかを選択する選択手段と、第１のモードが選択している場合にあっては、当該第１
のモードで情報送信している最中に前記検出手段によっ
て遅延時間が大きくなったことを検出した場合、それ以
上の転送レートの増加を停止し、第２のモードが選択さ
れている場合にあっては、当該第２のモードで情報送信
している最中に前記検出手段によって遅延時間が減少し
なくなったことを検出した場合、それ以上の転送レート
の減少を停止する転送レート制御手段とを備えることを
特徴とする通信装置。
【請求項９】前記選択手段は、一方のモードで転送レ
ートの変動を止めてから所定時間経過した後に、他方の
モードを選択すること交互に行なうことを特徴とする請
求項第８項に記載の通信装置。
【請求項１０】前記相手先端末は、所定時間間隔で前
記受信状況情報を送信することを特徴とする請求項第８
項に記載の通信装置。
【請求項１１】前記制御手段は送信レートを上げてい
く最中に遅延変化がなくても、所定の目標転送レート以
下にすることを特徴とする請求項第８項に記載の通信装
置。
【請求項１２】前記受信側端末との通信プロトコルは
ＲＦＣ１８８９を用いることを特徴とする請求項第８項
乃至第１１項のいずれか１つに記載の通信装置。
【請求項１３】所定のネットワークを介して相手先端
末に情報を送信する通信装置側の通信方法であって、相手側端末が所定時間間隔で送信してくる受信状況情報
を受信する受信工程と、受信した受信状況情報に基づいて、相手先端末への情報
伝送にかかる伝送遅延時間を検出する検出工程と、相手先端末への情報伝送の転送レートを徐々に増加させ
る第１のモードと、徐々に減少させる第２のモードのい
ずれかを選択する選択工程と、第１のモードが選択している場合にあっては、当該第１
のモードで情報送信している最中に前記検出工程によっ
て遅延時間が大きくなったことを検出した場合、それ以
上の転送レートの増加を停止し、第２のモードが選択さ
れている場合にあっては、当該第２のモードで情報送信
している最中に前記検出工程によって遅延時間が減少し
なくなったことを検出した場合、それ以上の転送レート
の減少を停止する転送レート制御工程とを備えことを特
徴とする通信方法。
【請求項１４】所定のネットワークを介して相手先端
末に情報を送信する通信装置側として機能するプログラ
ムコードを格納した記憶媒体であって、相手側端末が所定時間間隔で送信してくる受信状況情報
を受信する受信工程のプログラムコードと、受信した受信状況情報に基づいて、相手先端末への情報
伝送にかかる伝送遅延時間を検出する検出工程のプログ
ラムコードと、相手先端末への情報伝送の転送レートを徐々に増加させ
る第１のモードと、徐々に減少させる第２のモードのい
ずれかを選択する選択工程のプログラムコードと、第１のモードが選択している場合にあっては、当該第１
のモードで情報送信している最中に前記検出工程によっ
て遅延時間が大きくなったことを検出した場合、それ以
上の転送レートの増加を停止し、第２のモードが選択さ
れている場合にあっては、当該第２のモードで情報送信
している最中に前記検出工程によって遅延時間が減少し
なくなったことを検出した場合、それ以上の転送レート
の減少を停止する転送レート制御工程のプログラムコー
ドとを格納したことを特徴とする記憶媒体。
【請求項１５】所定のネットワークに接続された送信
側端末と受信側端末で構成される通信システムであっ
て、前記受信側端末は、前記送信側端末からの情報を受信する受信手段と、所定時間間隔で情報の受信状況情報を前記送信側端末に
送信する送信手段とを備え、前記送信側端末は、前記送信手段によって送信されてきた前記受信状況情報
に基づいて、相手先端末への情報伝送にかかる伝送遅延時間を検出す
る検出手段と、相手先端末への情報伝送の転送レートを徐々に増加させ
る第１のモードと、徐々に減少させる第２のモードのい
ずれか一方を選択する選択手段と、第１のモードが選択している場合にあっては、当該第１
のモードで情報送信している最中に前記検出手段によっ
て遅延時間が大きくなったことを検出した場合、それ以
上の転送レートの増加を停止し、第２のモードが選択さ
れている場合にあっては、当該第２のモードで情報送信
している最中に前記検出手段によって遅延時間が減少し
なくなったことを検出した場合、それ以上の転送レート
の減少を停止する転送レート制御手段とを備えることを
特徴とする通信システム。
【請求項１６】前記選択手段は、一方のモードで転送
レートの変動を止めてから所定時間経過した後に、他方
のモードを選択すること交互に行なうことを特徴とする
請求項第１５項に記載の通信システム。
【請求項１７】前記制御手段は送信レートを上げてい
く最中に遅延変化がなくても、所定の目標転送レート以
下にすることを特徴とする請求項第１５項に記載の通信
システム。
【請求項１８】前記受信側端末との通信プロトコルは
ＲＦＣ１８８９を用いることを特徴とする請求項第１５
項乃至第１７項のいずれか１つに記載の通信システム。