JP2000183958A - 通信制御装置及び制御方法及び記憶媒体及びシステム - Google Patents
通信制御装置及び制御方法及び記憶媒体及びシステムInfo
- Publication number
- JP2000183958A JP2000183958A JP35189198A JP35189198A JP2000183958A JP 2000183958 A JP2000183958 A JP 2000183958A JP 35189198 A JP35189198 A JP 35189198A JP 35189198 A JP35189198 A JP 35189198A JP 2000183958 A JP2000183958 A JP 2000183958A
- Authority
- JP
- Japan
- Prior art keywords
- rate
- real
- transfer protocol
- reception
- time transfer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Abstract
(57)【要約】
【課題】 汎用の実時間転送プロトコルを利用しつつ
も、送信側に格別な構成を追加することなく、受信側か
ら、送信側の送信レートを制御する。 【解決手段】 受信側端末２００のＲＴＰ受信部２１０
は、受信されるデータの実受信レートを算出する。そし
て、ｒｔｃｐ送信部２２０は、予め設定された目標受信
レートを越えるような実受信レートである場合には、疑
似的に通信ロスが発生したものとしてそれを算出し、実
ロス率として送信側端末１００に通知する。
も、送信側に格別な構成を追加することなく、受信側か
ら、送信側の送信レートを制御する。 【解決手段】 受信側端末２００のＲＴＰ受信部２１０
は、受信されるデータの実受信レートを算出する。そし
て、ｒｔｃｐ送信部２２０は、予め設定された目標受信
レートを越えるような実受信レートである場合には、疑
似的に通信ロスが発生したものとしてそれを算出し、実
ロス率として送信側端末１００に通知する。
Description
【０００１】
【発明の属する技術分野】本発明は通信制御装置及び制
御方法及び記憶媒体及びシステムに関するものである。
御方法及び記憶媒体及びシステムに関するものである。
【０００２】
【従来の技術】近年、インターネットを通じた通信が広
く使われるようになっている。インターネットのような
通信回線では常に回線状態が変化している。従って、実
時間データを送受信する場合、この変化に送信側、受信
側がそれぞれ対応する必要がある。つまり受信側が受け
取れるだけの速度で、送信側からのデータを送り出する
のである。
く使われるようになっている。インターネットのような
通信回線では常に回線状態が変化している。従って、実
時間データを送受信する場合、この変化に送信側、受信
側がそれぞれ対応する必要がある。つまり受信側が受け
取れるだけの速度で、送信側からのデータを送り出する
のである。
【０００３】従来、送信側でパケット毎にシーケンス番
号（とおし番号）を付け、受信側でその番号が連続して
いることを確認することで、ロスが生じているかどうか
を検出し、ロスが発生していればそのことを送信側に報
告する。そしてロス発生の報告をうけた送信側は、ロス
発生がなくなるまで送信レートを下げることで、受信側
の受け取り速度に合わせるという技術があった。
号（とおし番号）を付け、受信側でその番号が連続して
いることを確認することで、ロスが生じているかどうか
を検出し、ロスが発生していればそのことを送信側に報
告する。そしてロス発生の報告をうけた送信側は、ロス
発生がなくなるまで送信レートを下げることで、受信側
の受け取り速度に合わせるという技術があった。
【０００４】このような機構の実装例としてはＲＴＰと
して知られているＲＦＣ１８８９があげられる。ＲＴＰ
(Realtime Transport Protcol)ではデータの送受信にＲ
ＴＰ(ｒｔｐ Data Transfer Protocl)を使い、制御情報
の送信側にはＲＴＣＰ(ｒｔｐ Control Protocl)を使用
することでこれらを実現している。
して知られているＲＦＣ１８８９があげられる。ＲＴＰ
(Realtime Transport Protcol)ではデータの送受信にＲ
ＴＰ(ｒｔｐ Data Transfer Protocl)を使い、制御情報
の送信側にはＲＴＣＰ(ｒｔｐ Control Protocl)を使用
することでこれらを実現している。
【０００５】
【発明が解決しようとする課題】だがこのような実装で
は、送信側主導で送信レートが決められ、通信は送信側
が設定した最大送信レートに近付けるように行なわれて
いた。
は、送信側主導で送信レートが決められ、通信は送信側
が設定した最大送信レートに近付けるように行なわれて
いた。
【０００６】そのため受信側がネットワーク帯域のすべ
てを使い切りたくない場合に対処できない。従って、送
信側が設定した送信レートによってはネットワーク帯域
がすべて使われてしまい、他のネットワークユーザに影
響を及ぼすことがあった。
てを使い切りたくない場合に対処できない。従って、送
信側が設定した送信レートによってはネットワーク帯域
がすべて使われてしまい、他のネットワークユーザに影
響を及ぼすことがあった。
【０００７】このような事態を防ぐには、受信側が希望
する送信レートを送信側に伝えるための機構を新たに作
成する必要がある。
する送信レートを送信側に伝えるための機構を新たに作
成する必要がある。
【０００８】
【課題を解決するための手段】そこで、本願発明は、汎
用の実時間転送プロトコルを利用しつつ、送信元装置に
格別な構成を付加することなく、その送信元装置におけ
る送信レートを、受信側から制御可能とする通信制御装
置及び制御方法及び記憶媒体及びシステムを提供しよう
とするものである。
用の実時間転送プロトコルを利用しつつ、送信元装置に
格別な構成を付加することなく、その送信元装置におけ
る送信レートを、受信側から制御可能とする通信制御装
置及び制御方法及び記憶媒体及びシステムを提供しよう
とするものである。
【０００９】この課題を解決するため、例えば本発明の
通信制御装置は以下の構成を備える。すなわち、所定の
通信回線を介して所定の実時間転送プロトコルでもって
転送されてくるデータを受信する通信制御装置であっ
て、受信レートを制御すべく、擬似ロス率を実ロス率と
してデータ供給元に、前記実時間転送プロトコルに従っ
て通知する手段を備えることを特徴とする。
通信制御装置は以下の構成を備える。すなわち、所定の
通信回線を介して所定の実時間転送プロトコルでもって
転送されてくるデータを受信する通信制御装置であっ
て、受信レートを制御すべく、擬似ロス率を実ロス率と
してデータ供給元に、前記実時間転送プロトコルに従っ
て通知する手段を備えることを特徴とする。
【００１０】
【発明の実施の形態】以下、添付図面に従って本発明に
係る実施形態を詳細に説明する。
係る実施形態を詳細に説明する。
【００１１】図１に実施形態におけるシステム構成図を
示す。本実施形態はネットワーク３００により接続され
た送信側端末１００と受信側端末２００により構成され
る。なお、図示では送信側端末、受信側端末とも１台ず
つしめしているが、ネットワーク上にはいくつもの端末
が接続されていてもかまわない。特に、実施形態でのネ
ットワークは、インターネット等の大規模ネットワーク
にも、社内等でのイントラネットに適用できるものであ
る。
示す。本実施形態はネットワーク３００により接続され
た送信側端末１００と受信側端末２００により構成され
る。なお、図示では送信側端末、受信側端末とも１台ず
つしめしているが、ネットワーク上にはいくつもの端末
が接続されていてもかまわない。特に、実施形態でのネ
ットワークは、インターネット等の大規模ネットワーク
にも、社内等でのイントラネットに適用できるものであ
る。
【００１２】送信側端末１００、受信側端末２００はそ
れぞれ独立した計算機（例えばパーソナルコンピュータ
等の汎用情報処理装置）である。送信側端末１００から
受信側端末２００に対してｒｔｐを使用してデータを送
信する。本実施形態では、ｒｔｐ，ｒｔｃｐを送受信す
る機構はソフトウェアとして実現したが、同様の機能を
ハードウェアにより実現することも可能であり、これら
によって本発明が制限されるものではない。
れぞれ独立した計算機（例えばパーソナルコンピュータ
等の汎用情報処理装置）である。送信側端末１００から
受信側端末２００に対してｒｔｐを使用してデータを送
信する。本実施形態では、ｒｔｐ，ｒｔｃｐを送受信す
る機構はソフトウェアとして実現したが、同様の機能を
ハードウェアにより実現することも可能であり、これら
によって本発明が制限されるものではない。
【００１３】送信側端末１００と受信側端末２００はｒ
ｔｐ(ＲＦＣ１８８９）が定めるように、ｒｔｐにより
データの送受信を、ｒｔｃｐによりその制御データを転
送している。なお、ｒｔｐ，ｒｔｃｐそのものは公知で
あるので、詳述しない。
ｔｐ(ＲＦＣ１８８９）が定めるように、ｒｔｐにより
データの送受信を、ｒｔｃｐによりその制御データを転
送している。なお、ｒｔｐ，ｒｔｃｐそのものは公知で
あるので、詳述しない。
【００１４】本実施形態では、送信側端末１００はあら
かじめ定められたレート（目標送信レート）で受信側端
末２００に対してデータを送信する。このデータの送受
信にはｒｔｐを使用する。もし回線状況が悪く目標送信
レートでデータを送れない場合には、送信レートを落と
す。
かじめ定められたレート（目標送信レート）で受信側端
末２００に対してデータを送信する。このデータの送受
信にはｒｔｐを使用する。もし回線状況が悪く目標送信
レートでデータを送れない場合には、送信レートを落と
す。
【００１５】同様に受信側端末２００も送信側端末１０
０とは独立にあらかじめ定められたレート（目標受信レ
ート）によりデータを受信しようとする。もし受信レー
トが目標送信レートを越えるようなら、受信側端末２０
０は送信側端末１００に目標受信レートまでレートを落
とさせるようにする（詳細は後述）。
０とは独立にあらかじめ定められたレート（目標受信レ
ート）によりデータを受信しようとする。もし受信レー
トが目標送信レートを越えるようなら、受信側端末２０
０は送信側端末１００に目標受信レートまでレートを落
とさせるようにする（詳細は後述）。
【００１６】送信側端末１００、受信側端末２００は、
ｒｔｃｐを使用して通信回線の制御情報を交換する。こ
れらのｒｔｃｐを使用して、送信側端末１００、受信側
端末２００のパケットのロス率を知りレート制御を行な
う。
ｒｔｃｐを使用して通信回線の制御情報を交換する。こ
れらのｒｔｃｐを使用して、送信側端末１００、受信側
端末２００のパケットのロス率を知りレート制御を行な
う。
【００１７】受信側端末２００からのｒｔｃｐに含まれ
る主立った情報は次の通りである。 ・ｒｔｃｐを送り出した時点でのパケットロス率(fract
ion lost) ・ｒｔｃｐを送り出した時点で最後に受け取った送信側
端末からのｒｔｃｐのtimestamp ・上記の送信側端末からのｒｔｃｐを受け取ってからそ
のｒｔｃｐを送信するまでの時間(difference last rec
eiver report) 送信側端末１００はパケットのロス率を元に送信レート
を決定する。パケットロスがある場合には送信レートを
下げ、ない場合には徐々に送信レートを上げることで、
ネットワーク３００の通信容量を使い切るように動作す
る。
る主立った情報は次の通りである。 ・ｒｔｃｐを送り出した時点でのパケットロス率(fract
ion lost) ・ｒｔｃｐを送り出した時点で最後に受け取った送信側
端末からのｒｔｃｐのtimestamp ・上記の送信側端末からのｒｔｃｐを受け取ってからそ
のｒｔｃｐを送信するまでの時間(difference last rec
eiver report) 送信側端末１００はパケットのロス率を元に送信レート
を決定する。パケットロスがある場合には送信レートを
下げ、ない場合には徐々に送信レートを上げることで、
ネットワーク３００の通信容量を使い切るように動作す
る。
【００１８】受信側端末２００はパケットロスが発生し
た場合にｒｔｃｐを用いてロス情報を送信側端末１００
に報告する。またロスが生じていない場合にも、受信レ
ートが目標受信レートを越えた場合には、ロスが発生し
たとｒｔｃｐパケットの内容を書き換え送信側端末１０
０に報告する。このときロス率は次の式で計算した値を
使用する。
た場合にｒｔｃｐを用いてロス情報を送信側端末１００
に報告する。またロスが生じていない場合にも、受信レ
ートが目標受信レートを越えた場合には、ロスが発生し
たとｒｔｃｐパケットの内容を書き換え送信側端末１０
０に報告する。このときロス率は次の式で計算した値を
使用する。
【００１９】（１−（希望受信レート）／（受信レー
ト））*１００ （単位：１００パーセント） 従って、受信側端末が設定している希望受信レートを越
えた場合、送信側はあたかもパケットにロスが発生した
判断することになり、送信レートを下げるように制御す
ることになる。
ト））*１００ （単位：１００パーセント） 従って、受信側端末が設定している希望受信レートを越
えた場合、送信側はあたかもパケットにロスが発生した
判断することになり、送信レートを下げるように制御す
ることになる。
【００２０】次に送信側端末１００、受信側端末２００
の内部について説明する。
の内部について説明する。
【００２１】送信側端末１００は図１に示す如く、ｒｔ
ｐ送信部１１０、ｒｔｃｐ送信部１２０、ｒｔｃｐ受信
部１３０を備える。これらはネットワークインタフェー
スを介して動作するものであり、先に説明したように、
実際はソフトウェアでもって実現している。
ｐ送信部１１０、ｒｔｃｐ送信部１２０、ｒｔｃｐ受信
部１３０を備える。これらはネットワークインタフェー
スを介して動作するものであり、先に説明したように、
実際はソフトウェアでもって実現している。
【００２２】受信側端末２００はｒｔｐ受信部２１０、
ｒｔｃｐ送信部２２０、ｒｔｃｐ受信部２３０を備え
る。これらもソフトウェアでもって実現する。送受信側
とも、各部は別々のthreadとして独立に動作し、thread
間で共有されたいくつかに変数を通じて連係をとる。
ｒｔｃｐ送信部２２０、ｒｔｃｐ受信部２３０を備え
る。これらもソフトウェアでもって実現する。送受信側
とも、各部は別々のthreadとして独立に動作し、thread
間で共有されたいくつかに変数を通じて連係をとる。
【００２３】以下、各部の動作処理手順を図２〜図６の
フローチャートに従って説明する。
フローチャートに従って説明する。
【００２４】なお、送信側端末１００から受信側端末２
００に転送する実時間情報として、実施形態では映像情
報を例にする。例えば、送信側端末（サーバ）１００に
は、例えばビデオカメラが接続され、これで撮像された
映像情報（ディジタルデータに変換する必要はある）を
受信側端末（クライアント）に送信する場合である。
００に転送する実時間情報として、実施形態では映像情
報を例にする。例えば、送信側端末（サーバ）１００に
は、例えばビデオカメラが接続され、これで撮像された
映像情報（ディジタルデータに変換する必要はある）を
受信側端末（クライアント）に送信する場合である。
【００２５】図２は送信側端末のｒｔｐ送信部１１０の
フローチャートである。送信側端末は１０２４ｂｙｔｅ
の大きさのパケットを一定期間ごと（（１０２４ｂｙｔ
ｅ／送信レート）秒の期間ごと）に出力する。
フローチャートである。送信側端末は１０２４ｂｙｔｅ
の大きさのパケットを一定期間ごと（（１０２４ｂｙｔ
ｅ／送信レート）秒の期間ごと）に出力する。
【００２６】このため、初期時には、送信レートに目標
レートをセットする（ステップＳ１）が、その後のステ
ップＳ２、Ｓ３のループでは、後述する処理で変動する
送信レートに従った間隔になるようタイマをセットし、
そのセットした時間間隔で１０２４バイト送信を行なう
ようになっている。なお、送信するデータはパケット形
式であって、実施形態では１０２４バイト単位とした。
また、この中には、シーケンス番号（パケット毎に
“１”ずつ増加する番号）を含めるようにした。
レートをセットする（ステップＳ１）が、その後のステ
ップＳ２、Ｓ３のループでは、後述する処理で変動する
送信レートに従った間隔になるようタイマをセットし、
そのセットした時間間隔で１０２４バイト送信を行なう
ようになっている。なお、送信するデータはパケット形
式であって、実施形態では１０２４バイト単位とした。
また、この中には、シーケンス番号（パケット毎に
“１”ずつ増加する番号）を含めるようにした。
【００２７】また、上記の処理において、カメラで撮像
して得られた画像データは、複数パケットに分割されて
送信されるものであるが、１画面分を送信するまでは、
その間に撮像して得られた画像は無視するようにし、１
画面分を送信した後は、その時点で得られた最新の１画
面分の画像を送信するものとしている。
して得られた画像データは、複数パケットに分割されて
送信されるものであるが、１画面分を送信するまでは、
その間に撮像して得られた画像は無視するようにし、１
画面分を送信した後は、その時点で得られた最新の１画
面分の画像を送信するものとしている。
【００２８】図３は送信側端末１００のｒｔｃｐ送信部
１２０のフローチャートである。
１２０のフローチャートである。
【００２９】図示のステップＳ１１〜Ｓ１３の如く、ｒ
ｔｃｐ送信部１２０は５秒間隔毎にアクティブになり、
ｒｔｃｐを作成及び送信を繰り返す処理を行なう。
ｔｃｐ送信部１２０は５秒間隔毎にアクティブになり、
ｒｔｃｐを作成及び送信を繰り返す処理を行なう。
【００３０】図４は送信側端末１００のｒｔｃｐ受信部
１３０のフローチャートである。
１３０のフローチャートである。
【００３１】ｒｔｃｐ受信部１３０は、受信側端末２０
０からのｒｔｃｐの受信を待ち（ステップＳ２１）、そ
れを受信した場合には（ステップＳ２２）、そのｒｔｃ
ｐに含まれる先に示した受信レポート（ＲＦＣ１８８９
に詳細が規定されている）から、受信側端末でロスが検
出されたかを判断する（ステップＳ２３）。ロスが検出
された場合には現在の送信レートを０．８倍する（ステ
ップＳ２４）。また、ロスが検出されなかった場合に
は、送信レートを１．２倍する（ステップＳ２５）。
０からのｒｔｃｐの受信を待ち（ステップＳ２１）、そ
れを受信した場合には（ステップＳ２２）、そのｒｔｃ
ｐに含まれる先に示した受信レポート（ＲＦＣ１８８９
に詳細が規定されている）から、受信側端末でロスが検
出されたかを判断する（ステップＳ２３）。ロスが検出
された場合には現在の送信レートを０．８倍する（ステ
ップＳ２４）。また、ロスが検出されなかった場合に
は、送信レートを１．２倍する（ステップＳ２５）。
【００３２】このように指定、順次更新された送信レー
トが、先に示したｒｔｐ送信部に反映されることにな
る。
トが、先に示したｒｔｐ送信部に反映されることにな
る。
【００３３】次に、受信側端末２００について説明す
る。図５は受信側端末２００のｒｔｐ受信部２１０のフ
ローチャートである。
る。図５は受信側端末２００のｒｔｐ受信部２１０のフ
ローチャートである。
【００３４】ｒｔｐ受信部２１０は送信側端末１００か
らｒｔｐパケット（実施形態の場合には動画像データと
いうことになる）の受信を待ち（ステップＳ３１）、そ
れを受信すると（ステップＳ３２）、その情報（ｒｔｐ
パケットに含まれるシーケンス番号等）を所定のＲＡＭ
に格納する。これにより、ｒｔｃｐ送信部２２０はそれ
らの情報を元にｒｔｃｐパケットを構築することにな
る。その後一定期間（実施形態では１秒）経過したか否
かを判断し（ステップＳ３４）、否の場合には、ステッ
プＳ３１に戻って上記処理を繰り返す。一定期間経過し
たと判断した場合には、ステップＳ３５に進み、受信レ
ートを計算する。
らｒｔｐパケット（実施形態の場合には動画像データと
いうことになる）の受信を待ち（ステップＳ３１）、そ
れを受信すると（ステップＳ３２）、その情報（ｒｔｐ
パケットに含まれるシーケンス番号等）を所定のＲＡＭ
に格納する。これにより、ｒｔｃｐ送信部２２０はそれ
らの情報を元にｒｔｃｐパケットを構築することにな
る。その後一定期間（実施形態では１秒）経過したか否
かを判断し（ステップＳ３４）、否の場合には、ステッ
プＳ３１に戻って上記処理を繰り返す。一定期間経過し
たと判断した場合には、ステップＳ３５に進み、受信レ
ートを計算する。
【００３５】受信レートの計算は、２つのｒｔｐパケッ
トの到着時刻（実施形態では１秒間に受信したデータの
うちで最初のパケットをｒｔｐ０、最後に受信したパケ
ットをｒｔｐ１とする）により次の式で近似計算する。
計算した受信レートは、ｒｔｃｐの送信部２２０で使用
される。
トの到着時刻（実施形態では１秒間に受信したデータの
うちで最初のパケットをｒｔｐ０、最後に受信したパケ
ットをｒｔｐ１とする）により次の式で近似計算する。
計算した受信レートは、ｒｔｃｐの送信部２２０で使用
される。
【００３６】受信レート＝rtp0〜rtp1の間に受け取った
ｒｔｐのパケットサイズの合計／｛rtp1の受信時刻−rt
p0の受信時刻｝ そして、ステップＳ３６に進み、計算した受信レート
を、ｒｔｃｐ送信部２２０が参照可能なメモリ領域に書
き込むことで引き渡す。
ｒｔｐのパケットサイズの合計／｛rtp1の受信時刻−rt
p0の受信時刻｝ そして、ステップＳ３６に進み、計算した受信レート
を、ｒｔｃｐ送信部２２０が参照可能なメモリ領域に書
き込むことで引き渡す。
【００３７】図６は受信側端末２００のｒｔｃｐ送信部
２２０のフローチャートである。
２２０のフローチャートである。
【００３８】ｒｔｃｐ送信部２２０は５秒毎にアクティ
ブになりｒｔｃｐを出力する。従って、常にｒｔｐの受
信状態に対して応えるものではない。
ブになりｒｔｃｐを出力する。従って、常にｒｔｐの受
信状態に対して応えるものではない。
【００３９】まず、ステップＳ４１で５秒経過するのを
待ち、それが経過するとＲＴＣＰパケットによる受信レ
ポートを作成する（ステップＳ４２）。次いで、ステッ
プＳ４３に進み、受信側端末２００のｒｔｐ受信部２１
０が計算した実受信レートと、目標受信レートから、次
の疑似的なロス率を計算する。
待ち、それが経過するとＲＴＣＰパケットによる受信レ
ポートを作成する（ステップＳ４２）。次いで、ステッ
プＳ４３に進み、受信側端末２００のｒｔｐ受信部２１
０が計算した実受信レートと、目標受信レートから、次
の疑似的なロス率を計算する。
【００４０】疑似ロス率＝（１−（希望受信レート）／
（実受信レート））*１００ この式からもわかるように、希望受信レートより、実受
信レートの方が大きければ大きいほど、擬似ロス率も大
きくなる。換言すれば、擬似ロス率の符号が陽（＋）で
あれば、希望した受信レート以上でデータ受信が行われ
ていることを意味することになる。なお、希望受信レー
トは、受信側端末の操作者、もしくは、受信側端末の管
理者が予め設定しておくもので、設定した希望受信レー
トは変更しない限りハードディスク等に記憶保持されて
いる。ただし、受信側端末の表示画面上でこの値を自由
に変更するユーザインタフェースを設けても良い。
（実受信レート））*１００ この式からもわかるように、希望受信レートより、実受
信レートの方が大きければ大きいほど、擬似ロス率も大
きくなる。換言すれば、擬似ロス率の符号が陽（＋）で
あれば、希望した受信レート以上でデータ受信が行われ
ていることを意味することになる。なお、希望受信レー
トは、受信側端末の操作者、もしくは、受信側端末の管
理者が予め設定しておくもので、設定した希望受信レー
トは変更しない限りハードディスク等に記憶保持されて
いる。ただし、受信側端末の表示画面上でこの値を自由
に変更するユーザインタフェースを設けても良い。
【００４１】次のステップＳ４４では、擬似ロス率と本
来のロス率とを比較する。ここで、擬似ロス率が本来の
ロス率よりも大きい場合には、先のステップＳ４２で作
成した受信レポート中のロス率の項目に、ステップＳ４
３で算出した擬似ロス率を書き換える。一方、擬似ロス
率が本来のロス率以下である場合には、ステップＳ４２
で作成した受信レポートには細工しない。
来のロス率とを比較する。ここで、擬似ロス率が本来の
ロス率よりも大きい場合には、先のステップＳ４２で作
成した受信レポート中のロス率の項目に、ステップＳ４
３で算出した擬似ロス率を書き換える。一方、擬似ロス
率が本来のロス率以下である場合には、ステップＳ４２
で作成した受信レポートには細工しない。
【００４２】いずれにしても、処理はステップＳ４６に
進み、ｒｔｃｐパケットによる受信レポートを送信す
る。これにより送信側端末１００に希望する送信レート
で送信させる。
進み、ｒｔｃｐパケットによる受信レポートを送信す
る。これにより送信側端末１００に希望する送信レート
で送信させる。
【００４３】図７は受信側端末２００のｒｔｃｐ受信部
２３０のフローチャートである。本実施形態では受信側
端末２００では特にｒｔｃｐを使用していない。従っ
て、通常通り、ｒｔｃｐ受信を待ってそれを受信すると
いう処理をループするだけである。
２３０のフローチャートである。本実施形態では受信側
端末２００では特にｒｔｃｐを使用していない。従っ
て、通常通り、ｒｔｃｐ受信を待ってそれを受信すると
いう処理をループするだけである。
【００４４】なお、実施形態で受信側端末では、ｒｔｐ
受信部２１０が受信するのはカメラで撮影されたデータ
としているので、ここで受信したデータは上位の処理プ
ログラムに引き渡され、画面等に表示されることにな
る。
受信部２１０が受信するのはカメラで撮影されたデータ
としているので、ここで受信したデータは上位の処理プ
ログラムに引き渡され、画面等に表示されることにな
る。
【００４５】また、実施形態では、送信側端末１００に
はカメラが設置されているものとして説明したが、例え
ば動画像をファイルとして記憶（例えばハードディスク
等）しており、それを受信側端末に送信する場合に適用
してもよい。
はカメラが設置されているものとして説明したが、例え
ば動画像をファイルとして記憶（例えばハードディスク
等）しており、それを受信側端末に送信する場合に適用
してもよい。
【００４６】さらにまた、実施形態では送信する情報は
画像（動画像）であるものとして説明したが、実時間転
送が要求さる情報であればこれに限るものではない。
画像（動画像）であるものとして説明したが、実時間転
送が要求さる情報であればこれに限るものではない。
【００４７】また、実施形態では、ＲＦＣ１８８９によ
るＲＴＰを例にして説明したが、実時間転送を行なうよ
うなプロトコルに適用できるので、これによっても本願
発明が限定されるものではない。
るＲＴＰを例にして説明したが、実時間転送を行なうよ
うなプロトコルに適用できるので、これによっても本願
発明が限定されるものではない。
【００４８】そして、実施形態で説明した送受信端末
は、ネットワーク通信を行なうためのハードウェア（イ
ーサネットやモデム、ＴＡ等）を必要とするものの、パ
ーソナルコンピュータ等の汎用情報処理装置で実現でき
る。
は、ネットワーク通信を行なうためのハードウェア（イ
ーサネットやモデム、ＴＡ等）を必要とするものの、パ
ーソナルコンピュータ等の汎用情報処理装置で実現でき
る。
【００４９】従って、本発明の目的は、前述した実施形
態の機能を実現するソフトウェアのプログラムコードを
記録した記憶媒体を、システムあるいは装置に供給し、
そのシステムあるいは装置のコンピュータ（またはＣＰ
ＵやＭＰＵ）が記憶媒体に格納されたプログラムコード
を読出し実行することによっても、達成されることは言
うまでもない。
態の機能を実現するソフトウェアのプログラムコードを
記録した記憶媒体を、システムあるいは装置に供給し、
そのシステムあるいは装置のコンピュータ（またはＣＰ
ＵやＭＰＵ）が記憶媒体に格納されたプログラムコード
を読出し実行することによっても、達成されることは言
うまでもない。
【００５０】この場合、記憶媒体から読出されたプログ
ラムコード自体が前述した実施形態の機能を実現するこ
とになり、そのプログラムコードを記憶した記憶媒体は
本発明を構成することになる。
ラムコード自体が前述した実施形態の機能を実現するこ
とになり、そのプログラムコードを記憶した記憶媒体は
本発明を構成することになる。
【００５１】プログラムコードを供給するための記憶媒
体としては、例えば、フロッピディスク，ハードディス
ク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ
−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭな
どを用いることができる。
体としては、例えば、フロッピディスク，ハードディス
ク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ
−Ｒ，磁気テープ，不揮発性のメモリカード，ＲＯＭな
どを用いることができる。
【００５２】また、コンピュータが読出したプログラム
コードを実行することにより、前述した実施形態の機能
が実現されるだけでなく、そのプログラムコードの指示
に基づき、コンピュータ上で稼働しているＯＳ（オペレ
ーティングシステム）などが実際の処理の一部または全
部を行い、その処理によって前述した実施形態の機能が
実現される場合も含まれることは言うまでもない。
コードを実行することにより、前述した実施形態の機能
が実現されるだけでなく、そのプログラムコードの指示
に基づき、コンピュータ上で稼働しているＯＳ（オペレ
ーティングシステム）などが実際の処理の一部または全
部を行い、その処理によって前述した実施形態の機能が
実現される場合も含まれることは言うまでもない。
【００５３】さらに、記憶媒体から読出されたプログラ
ムコードが、コンピュータに挿入された機能拡張ボード
やコンピュータに接続された機能拡張ユニットに備わる
メモリに書込まれた後、そのプログラムコードの指示に
基づき、その機能拡張ボードや機能拡張ユニットに備わ
るＣＰＵなどが実際の処理の一部または全部を行い、そ
の処理によって前述した実施形態の機能が実現される場
合も含まれることは言うまでもない。
ムコードが、コンピュータに挿入された機能拡張ボード
やコンピュータに接続された機能拡張ユニットに備わる
メモリに書込まれた後、そのプログラムコードの指示に
基づき、その機能拡張ボードや機能拡張ユニットに備わ
るＣＰＵなどが実際の処理の一部または全部を行い、そ
の処理によって前述した実施形態の機能が実現される場
合も含まれることは言うまでもない。
【００５４】以上説明したように本実施形態によれば、
受信側から送信側にロス率を報告する機構を設けるだけ
で、新たな機構を設けることなく受信側から送信側の送
信レートを制御することが可能になる。
受信側から送信側にロス率を報告する機構を設けるだけ
で、新たな機構を設けることなく受信側から送信側の送
信レートを制御することが可能になる。
【００５５】特に、実施形態に従えば、送信側端末は初
期時には目標送信レートで送信するものであるが、受信
端末側で、それとは全く無関係に設定した希望受信レー
トを設定することで、送信側端末の送信レートを制御す
ることができるようになる。従って、希望受信レートと
して、ネットワークの帯域を十分に下回る値を設定して
おけば、他のネットワークユーザに迷惑になることもな
くなり、良好なネットワーク環境を維持できるようにな
る。
期時には目標送信レートで送信するものであるが、受信
端末側で、それとは全く無関係に設定した希望受信レー
トを設定することで、送信側端末の送信レートを制御す
ることができるようになる。従って、希望受信レートと
して、ネットワークの帯域を十分に下回る値を設定して
おけば、他のネットワークユーザに迷惑になることもな
くなり、良好なネットワーク環境を維持できるようにな
る。
【００５６】
【発明の効果】以上説明したように本発明によれば、汎
用の実時間転送プロトコルを利用しつつも、送信側に格
別な構成を追加することなく、受信側から送信側の送信
レートを制御することが可能となる。
用の実時間転送プロトコルを利用しつつも、送信側に格
別な構成を追加することなく、受信側から送信側の送信
レートを制御することが可能となる。
【図１】実施形態におけるシステム構成図である。
【図２】実施形態における送信側端末のｒｔｐ送信部の
処理内容を示すフローチャートである。
処理内容を示すフローチャートである。
【図３】実施形態における送信側端末のｒｔｐ受信部の
処理内容を示すフローチャートである。
処理内容を示すフローチャートである。
【図４】実施形態における送信側端末のｒｔｃｐ受信部
の処理内容を示すフローチャートである。
の処理内容を示すフローチャートである。
【図５】実施形態における受信側端末のｒｔｐ受信部の
処理内容を示すフローチャートである。
処理内容を示すフローチャートである。
【図６】実施形態における受信側端末のｒｔｃｐ送信部
の処理内容を示すフローチャートである。
の処理内容を示すフローチャートである。
【図７】実施形態における受信側端末のｒｔｃｐ受信部
の処理内容を示すフローチャートである。
の処理内容を示すフローチャートである。
１００ 送信側端末 １１０ ｒｔｐ送信部 １２０ ｒｔｃｐ送信部 １３０ ｒｔｃｐ受信部 ２００ 受信側端末 ２１０ ｒｔｐ送信部 ２２０ ｒｔｃｐ送信部 ２３０ ｒｔｃｐ受信部 ３００ ネットワーク
Claims (6)
- 【請求項１】 所定の通信回線を介して所定の実時間転
送プロトコルでもって転送されてくるデータを受信する
通信制御装置であって、 受信レートを制御すべく、擬似ロス率を実ロス率として
データ供給元に、前記実時間転送プロトコルに従って通
知する手段を備えることを特徴とする通信制御装置。 - 【請求項２】 前記実時間転送プロトコルはＲＦＣ１８
８９のＲＴＰを用いることを特徴とする請求項第１項に
記載の通信制御装置。 - 【請求項３】 前記通知手段は、 実受信レートと、希望受信レートに基づいて、 擬似ロス率＝１−希望受信レート／実受信レート で算出した値の百分率を通知することを特徴とする請求
項第１項に記載の通信制御装置。 - 【請求項４】 所定の通信回線を介して所定の実時間転
送プロトコルでもって転送されてくるデータを受信する
通信制御装置の制御方法であって、 受信レートを制御すべく、擬似ロス率を実ロス率として
データ供給元に、前記実時間転送プロトコルに従って通
知する通知工程とを備えることを特徴とする通信制御装
置の制御方法。 - 【請求項５】 コンピュータが読込み実行することで、
所定の通信回線を介して所定の実時間転送プロトコルで
もって転送されてくるデータを受信する通信制御装置と
して機能するプログラムコードを格納した記憶媒体であ
って、 受信レートを制御すべく、擬似ロス率を実ロス率として
データ供給元に、前記実時間転送プロトコルに従って通
知する通知手段として機能するプログラムコードを格納
した記憶媒体。 - 【請求項６】 所定のネットワーク上に設けられた送信
側端末と、受信側端末で構成され、当該端末間を所定の
実時間転送プロトコルでもって通信する通信システムで
あって、 前記受信側端末は、 受信レートを制御すべく、擬似ロス率を実ロス率として
データ供給元に、前記実時間転送プロトコルに従って通
知する通知手段とを備えることを特徴とする通信システ
ム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP35189198A JP2000183958A (ja) | 1998-12-10 | 1998-12-10 | 通信制御装置及び制御方法及び記憶媒体及びシステム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP35189198A JP2000183958A (ja) | 1998-12-10 | 1998-12-10 | 通信制御装置及び制御方法及び記憶媒体及びシステム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2000183958A true JP2000183958A (ja) | 2000-06-30 |
Family
ID=18420329
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP35189198A Withdrawn JP2000183958A (ja) | 1998-12-10 | 1998-12-10 | 通信制御装置及び制御方法及び記憶媒体及びシステム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2000183958A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005503722A (ja) * | 2001-09-21 | 2005-02-03 | ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー | 輻輳制御用に伝送レートを計算するためにバッファサイズの受領を用いるデータ通信方法とシステム |
| JP2007097099A (ja) * | 2005-09-30 | 2007-04-12 | Hitachi Kokusai Electric Inc | データ伝送装置 |
| US7974200B2 (en) | 2000-11-29 | 2011-07-05 | British Telecommunications Public Limited Company | Transmitting and receiving real-time data |
| US8135852B2 (en) | 2002-03-27 | 2012-03-13 | British Telecommunications Public Limited Company | Data streaming system and method |
-
1998
- 1998-12-10 JP JP35189198A patent/JP2000183958A/ja not_active Withdrawn
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7974200B2 (en) | 2000-11-29 | 2011-07-05 | British Telecommunications Public Limited Company | Transmitting and receiving real-time data |
| JP2005503722A (ja) * | 2001-09-21 | 2005-02-03 | ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー | 輻輳制御用に伝送レートを計算するためにバッファサイズの受領を用いるデータ通信方法とシステム |
| US8135852B2 (en) | 2002-03-27 | 2012-03-13 | British Telecommunications Public Limited Company | Data streaming system and method |
| US8386631B2 (en) | 2002-03-27 | 2013-02-26 | British Telecommunications Plc | Data streaming system and method |
| JP2007097099A (ja) * | 2005-09-30 | 2007-04-12 | Hitachi Kokusai Electric Inc | データ伝送装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3825099B2 (ja) | 映像データ転送方式およびビデオサーバ装置 | |
| EP1397899B1 (en) | Real-time packetization and retransmission in streaming applications | |
| JP4660557B2 (ja) | データ伝送システムおよび方法 | |
| US20090198830A1 (en) | Method of adjusting network data sending speed according to data processing speed at client | |
| US8819741B2 (en) | Streaming video over a wireless network | |
| KR20010074883A (ko) | 적은 대기 시간 통신 시스템 및 그 방법 | |
| CN103595559A (zh) | 一种大数据的传输系统、传输方法及其业务系统 | |
| WO2022105798A1 (zh) | 音视频的处理方法、装置及存储介质 | |
| KR100982630B1 (ko) | 콘텐츠의 스트림 비트율을 조정하기 위한 디바이스 및프로세스 그리고 관련 제품 | |
| CN111327962A (zh) | 播放控制方法、装置、设备及存储介质 | |
| JP2001144802A (ja) | データ通信装置及びその方法及び通信システム及び記憶媒体 | |
| JP2000183958A (ja) | 通信制御装置及び制御方法及び記憶媒体及びシステム | |
| JP2005051299A (ja) | パケット送信装置、パケット受信装置、パケット送信方法及びパケット受信方法 | |
| JP4042396B2 (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| WO2023179538A1 (zh) | 数据传输方法、装置、电子设备和存储介质 | |
| JPH11284659A (ja) | 通信制御方法及びその装置及び記憶媒体 | |
| WO2006094427A1 (en) | Self-adaptive multicast file transfer protocol | |
| CN113726817B (zh) | 一种流媒体数据的传输方法、装置及介质 | |
| JP2000172599A (ja) | マルチキャストストリームデータ転送方法およびシステム | |
| TW201929551A (zh) | 具有備援機制的串流系統及其備援方法 | |
| JP3906678B2 (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| JP2004007172A (ja) | 情報配信システム、情報配信装置および方法、情報端末装置および情報処理方法、記録媒体、並びにプログラム | |
| JPH09284343A (ja) | 蓄積型マルチメディア情報の転送再生方法および装置 | |
| JP2004186793A (ja) | ストリーミング配信装置、ストリーミング端末装置、ストリーミング配信システム、及びストリーミング配信方法 | |
| JPH11163934A (ja) | 伝送システム及び伝送装置及び受信装置及び実時間動画像及び音声送信システム及び装置及びその制御方法及び記憶媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20060307 |