JPH11284659A

JPH11284659A - 通信制御方法及びその装置及び記憶媒体

Info

Publication number: JPH11284659A
Application number: JP8764898A
Authority: JP
Inventors: Tomohiko Shimoyama; 朋彦下山; Koichi Yano; 晃一矢野
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 1998-03-31
Filing date: 1998-03-31
Publication date: 1999-10-15

Abstract

(57)【要約】【課題】ネットワークの状況に応じて制御情報を発信
することにより、効率良くデータの送信を行なうことを
可能にする。【解決手段】送信側端末は送信すべきデータをＲＴＰ
プロトコルで送信し、ネットワークの状況を把握するた
めの制御信号を送信側端末及び受信側端末双方でＲＴＣ
Ｐプロトコルで送信する。ここで送信側端末は、所定周
期毎に制御情報をＲＴＣＰパケットとして送信するが、
通信レートが目標レートに到達しない場合には前記所定
周期とは非同期に送信レートを所定割合高くするように
設定する。また、受信側端末から送られてきた制御情報
に基づいて送信ロスがあったと判断した場合には、前記
所定周期とは非同期に送信レートを所定割合低くするよ
うに設定する。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

【従来の技術】近年、インターネットなどの通信回線を
通じ、ビデオカメラ及びそれに付随するマイクロホンに
より得られた動画や音声などの実時間データを送信する
システムが現れている。これらのシステムを構築する際
には、常に状態の変わる通信回線状況に対応する必要が
ある。つまり受信側が受け取れるだけの速度で、送信側
からデータを送り出してやる必要がある。

【０００３】送信側で、データ送り出し速度を制御する
ためには、受信側での実効受信速度を知る必要がある。
これを知るために送信側、受信側の間で、本来のデータ
送信に加えて、制御情報を交換することが必要となる。

【０００４】このような通信プロトコルの使用としては
ＲＴＰ(Realtime Transport Protcol)として知られてい
るＲＦＣ１８８９があげられる。ＲＴＰではデータの送
受信にはＲＴＰ(RTP Data Transfer Protocl)を使い、
制御情報の送受信にはＲＴＣＰ(RTP Control Protocl)
を使用することでこれらを実現している。

【０００５】

【発明が解決しようとする課題】だがこれまでは、制御
情報の送受信は定期的（ＲＴＰではＲＴＣＰの送信間隔
として５秒に１回程度が推奨されている）に行われてい
た。そのため、通信回線の状況が悪化した時などに、そ
の状況変化を感知するのが遅れてしまい、またそれに対
して送信レートを変化させたことに対するフィードバッ
ク情報も遅くなってしまっていた。

【０００６】例えば５秒に１回制御情報を流すシステム
では、最悪５秒後に回線状況の変化を検出し、送信側の
送信レートの変更した場合にその変更が適切かどうかは
最悪１０秒後にならないとわからなかった。そのため回
線状態が変化すると脱落するパケットが増えたり、パケ
ット配送の遅延が起きるなどの問題が生じていた。

【０００７】

【課題を解決するための手段】本発明はかかる問題点に
鑑みなされたものであり、ネットワークの状況に応じて
制御情報を発信することにより、効率良くデータの送信
を行なうことを可能ならしめる通信制御方法及びシステ
ム及び記憶媒体を提供しようとするものである。

【０００８】この課題を解決するため、例えば本発明の
通信制御方法は以下の工程を備える。すなわち、所定の
ネットワークを介して、発信側端末から受信側端末に向
けてデータを送信すると共に、前記ネットワーク上の状
況を把握するための制御信号を所定時間間隔に発信する
通信制御方法であって、前記ネットワークの状況の変化
を検出し、検出された状況の変化に応じて前記制御情報
の発信の頻度を調整することを特徴とする。

【０００９】

【発明の実施の形態】以下、添付図面に従って本発明に
係る実施形態を詳細に説明する。

【００１０】図１は実施形態におけるシステム全体図で
ある。本実施形態はネットワーク３００（電話網を含
む）により接続された送信側端末１００と受信側端末２
００により構成される。送信側端末１００は、例えばビ
デオカメラ及びマイクを有する装置或いはシステムであ
って、実時間の映像／音声を受信側端末２００に送信す
るものである。送信側端末１００と受信側端末２００は
互いに独立した計算機或いはシステムであり、いずれも
ネットワーク接続のためのハードウェア、送信側では実
時間で転送するためのデータソース（カメラやマイク等
のハードウェア）を必要とするものの、汎用的なワーク
ステーションもしくはパーソナルコンピュータで実現で
きる。

【００１１】ここでは、送信側端末１００から受信側端
末２００に対してｒｔｐを使用してデータを送信する。
本実施形態では、ｒｔｐパケット、ｒｔｃｐパケットを
送受信する機構はソフトウェアで実現するが、同様の機
能をハードウェアにより実現することも可能であり、本
発明はこれらにより制限されるものではない。

【００１２】送信側端末１００と受信側端末２００はｒ
ｔｐ（ＲＦＣ１８８９）が定めるように、ｒｔｐパケッ
トによりデータの送受信を、ｒｔｃｐパケットによりそ
の制御データを転送している。ｒｔｐ、ｒｔｃｐの詳細
に関しては既知のものとして説明を省略する。

【００１３】送信側端末１００はあらかじめ定められた
レート（目標レート）で受信側端末２００に対してデー
タを送信する。このデータの送受信にはｒｔｐを使用す
る。もし回線状況が悪く目標レートでデータを遅れない
場合には、送信レートを落とす。

【００１４】また送信側端末１００，受信側端末２００
は、ｒｔｃｐパケットを使用して通信回線の制御情報を
交換する。これらのｒｔｃｐを使用して、送信側端末１
００、受信側端末２００はレート制御を行う。

【００１５】受信側端末２００から送信側端末１００に
向けてのｒｔｃｐパケットに含まれる主だった情報は次
の通りである。

【００１６】・ｒｔｃｐパケットを送り出した時点での
パケットロス率(fraction lost) ・ｒｔｃｐパケットを送り出した時点で最後に受け取っ
た送信側端末からのｒｔｃｐパケットのタイムスタンプ
（timestamp）・上記の送信側端末からのｒｔｃｐパケットを受け取っ
てからそのｒｔｃｐパケットを送信するまでの時間(dif
ference last sender report) 送信側端末１００はこれらの情報を元に、送信レートを
決定する。本実施形態ではパケットのロス率を元に送信
レートを決定する。パケットロスがある場合には送信レ
ートを下げ、ない場合には徐々に送信レートを上げるこ
とで、ネットワーク３００の通信容量を使い切るように
動作する。

【００１７】従って、受信側端末２００はｒｔｃｐパケ
ットの到着毎に新たな送信レートを決定できることにな
り、送信状況、回線状況に変化があった場合には頻繁に
ｒｔｃｐパケットが送られてくることが期待される。

【００１８】一方、送信側端末１００から受信側端末２
００に向けてのｒｔｃｐに含まれる主だった情報は次の
通りである。

【００１９】・送信側端末がｒｔｃｐパケットを送り出
した時の時刻(sender's timestamp) ・送信側端末がｒｔｃｐパケットを送り出した時点で累
積で何バイトのデータを送ったか(sender's octed) これらの情報を受け取ることで、受信側端末２００は送
信側端末１００からのデータの送信レートを計算するこ
とができる。これは２つのｒｔｃｐ情報（ｒｔｃｐ０，
１とすると）から次の式で計算することができる。

【００２０】送信レート＝（rtcp1のsender's octed -r
tcp0のsender's octed）／(rtcp1のsender's timestamp
-rtcp0のsender's timestamp) 受信側端末２００はこうして得た送信レートと受信レー
トの差をとり（受信レートは２つのｒｔｐパケット情報
により計算する（後述））、その差が大きくなった場合
には送信側端末１００にｒｔｃｐパケットを頻繁に送
る。

【００２１】レートの差が大きい状況はロスが発生する
状況（またはネットワークでの遅延が大きくなる状
況）、もしくは送信側端末１００が最適な送信レートを
探して送信レートを増加しているときである。

【００２２】前者の場合には早急に送信側端末１００に
おいて送信レートを絞る必要があり、後者の場合には、
送信レートの増加による影響のフィードバックをすばや
く送信側端末１００にかける必要から、やはりｒｔｃｐ
パケットを早急に送る必要があり、本発明が有効に機能
する。

【００２３】同様の理由から送信側端末１００でも、送
信レートを変化する時には頻繁にｒｔｃｐパケットの送
信をすることで受信側端末２００に現在の送信レートを
早急に知らせる。

【００２４】また本実施形態では採用しなかったが、ｒ
ｔｃｐパケットに含まれる情報から送信側端末１００と
受信側端末２００との間でパケットが往復するのに要す
る時間（ｒｔｔ：round trip time）を測定することが
できる。このｒｔｔの変化を検出してｒｔｃｐパケット
を頻繁に送ることも有効である（ｒｔｔの計算方法はＲ
ＦＣ１８８９に記述されているものに従って求める）。

【００２５】次に送信側端末１００、受信側端末２００
の内部について説明する。送信側端末１００はｒｔｐパ
ケット送信部１１０、ｒｔｃｐパケット送信部１２０、
ｒｔｃｐパケット受信部１３０で構成される。また、受
信側端末２００はｒｔｐパケット受信部２１０、ｒｔｃ
ｐパケット２２０、ｒｔｃｐパケット受信部２３０から
構成される。これらは全て別々のスレッドとして独立に
動作し、スレッド間で共有されたいくつかに変数を通じ
て連係をとる。

【００２６】以下、各処理部の処理内容を図２〜図６の
フローチャートに従い説明する。

【００２７】図２は送信側端末のｒｔｐパケット送信部
１１０のフローチャートである。

【００２８】先ず初期値として送信レートに目標レー
ト、レートカウンタに初期として“０”を設定し（ステ
ップＳ１）、タイマを送信レートに従った時間を設定
し、その時間が経過するのを待つ（ステップＳ２）。こ
れは前回の送信が完了するのを待っていることに他なら
ない。次いで、今回の１０２４バイトをパケットを送信
し（ステップＳ３）、レートカウンタを“１”だけイン
クリメントする（ステップＳ４）。こうして、レートカ
ウンタが“１００”になるまで、上記のステップＳ２以
降の処理を繰り返す。レートカウンタが“１００”にな
ると、そのカウンタを“０”でリセットし（ステップＳ
６）、目標レートと実際の送信レートの比較を行なう
（ステップＳ７）。ここで送信レートは目標レートに達
したか、それ以上になった場合には、その時点での送信
レートに従ってデータ転送を行なうためにステップＳ２
に戻る。

【００２９】一方、送信レートが目標レートよりも小さ
い場合には、送信レートを変更するため、例えば従前の
送信レートに対して１．２倍（２０％アップ）すると共
に、それを受信側に報知するため、ＲＴＣＰ出力フラグ
（後述）をＯＮにする。

【００３０】つまり、送信側端末は１０２４ｂｙｔｅの
大きさのパケットを一定期間ごと（（１０２４ｂｙｔｅ
／送信レート）秒の期間ごと）に出力する。そして１０
０パケットを送る毎に送信レートを１．２倍してゆく。
送信レートを変更した時には、ｒｔｃｐパケット送信部
１２０と共有したｒｔｃｐ出力フラグをＯＮにすること
でｒｔｃｐを素早く受信側端末２００に届け、送信レー
トの変更による影響を早い時期に伝えている。

【００３１】図３は送信側端末１００、受信側端末２０
０のｒｔｃｐパケット送信部１２０のフローチャートで
ある。

【００３２】基本的にｒｔｃｐパケット送信部１２０
は、例えば１秒ごとにアクティブになり（ステップＳ１
１）、５秒に１回ｒｔｃｐパケットを出力する（ステッ
プＳ１３〜Ｓ１６）。またｒｔｃｐ出力フラグがＯＮ
（図２のフローチャート、及び後述する図４のフローチ
ャートによって決定される）になっている場合（ステッ
プＳ１２）には、例え５秒経過していなくてもｒｔｃｐ
パケットを出力する。尚、ここで言う５秒は本発明にお
ける所定間隔に相当するものであるが、その時間間隔は
所定の条件を満たす間隔であって、条件によって変動可
能としても良い。

【００３３】図４は送信側端末１００のｒｔｃｐパケッ
ト受信部１３０のフローチャートである。

【００３４】ｒｔｃｐパケット受信部１３０は受信した
ｒｔｃｐパケット（ステップＳ２１、２２）に基づいて
受信側端末でロスが検出されたと判断した場合（ステッ
プＳ２３）、ｒｔｐパケットの送信レート（図２の送信
レートに反映される）を０．８倍（２０％ダウン）す
る。また０．８倍したことによる影響を早い時期に受信
側端末２００に知らせるためにｒｔｃｐ出力フラグをＯ
Ｎにする。

【００３５】図５は受信側端末２００のｒｔｐパケット
受信部２００のフローチャートである。

【００３６】ｒｔｐパケット受信部２１０はｒｔｐパケ
ットを受信すると（ステップＳ３１、Ｓ３２）、その情
報（ｒｔｐパケットのシーケンス番号等）を格納する。
ｒｔｃｐパケット送信部２２０はそれらの情報をもとに
ｒｔｃｐパケットを構築する（ステップＳ３３）。その
後一定期間毎に（ここでは１秒置き以上の間隔で）、受
信レートを計算する。受信レートの計算は、２つのｒｔ
ｐパケットの到着時刻により次の式で近似計算する（ス
テップＳ３５）。

【００３７】受信レート＝rtp0のパケットサイズ／（rt
p1を受信した時刻−rtpc0を受信した時刻）もし受信レートと送信レートの差が大きいと判断したら
（ステップＳ３６）、ｒｔｐパケット受信部２１０はｒ
ｔｃｐ出力フラグをＯＮにして、早急にｒｔｃｐパケッ
ト送信部２２０にｒｔｃｐパケットを出力させる。尚、
ここでは、その差の大小の判断閾値として、送信レート
の±１０％以内に受信レートがおさまっているかで判定
した。

【００３８】図６は受信側端末２００のｒｔｃｐパケッ
ト受信部２３０のフローチャートである。ｒｔｃｐパケ
ット受信部２３０はｒｔｃｐパケットを受信すると（ス
テップＳ４１、Ｓ４２）、先に［００２０］で示した手
法により送信側端末１００の送信レートを計算する（ス
テップＳ４３）。この計算結果は先に示したようにｒｔ
ｐパケット受信部２１０内で使用される。

【００３９】以上説明したように本実施形態に従えば、
回線状態の変化、送受信状況の変化などに対応して、ネ
ットワークの制御情報を送る頻度を変えることができ
る。これにより従来の一定期間ごとに制御情報を送る手
法と比較して、早く送受信にフィードバックをかけるこ
とが可能となり、ロスや伝送遅延の少ない通信を行うこ
とができるようになる。

【００４０】尚、実施形態では、送信側端末としてビデ
オカメラを有するものとして説明したが、これに限らな
い。例えば動画をファイルとして記憶しておき、それを
送信する場合でもよいからである。また、送信するデー
タは他のデータ（例えば音声）でも良く、画像データに
限るものでもない。

【００４１】また、上記実施形態で説明したとおり、実
施形態における送信側装置及び受信側装置は、ネットワ
ーク接続等の多少のハードウェア（ネットワークカード
やモデム等）を必要とするものの、汎用のコンピュータ
等で構成できるものである。また、送信側装置及び受信
側装置はそれぞれ単独の装置であっても複数の装置で構
成されるシステムであっても良い。

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

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

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

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

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

【００４７】また、実施形態では通信プロトコルの仕様
としてＲＦＣ１８８９に従って説明したが、これに限ら
れるものではない。また、上記実施形態で説明した１パ
ケットのサイズ（１０２４バイト）やタイマの値（図３
における１秒等）も、これに限定されるものでは無く、
如何なる値にしても構わない。

【００４８】

【発明の効果】以上説明したように本発明によれば、ネ
ットワークの状況に応じて制御情報を発信することによ
り、効率良くデータの送信を行なうことが可能になる。

【００４９】

【図面の簡単な説明】

【図１】本実施形態におけるシステム構成図である。

【図２】送信側端末のｒｔｐパケット送信のフローチャ
ートである。

【図３】送信側端末及び受信側端末のｒｔｃｐパケット
送信のフローチャートである。

【図４】送信側端末のｒｔｃｐパケット受信のフローチ
ャートである。

【図５】受信側端末のｒｔｐパケット受信のフローチャ
ートである。

【図６】受信側端末のｒｔｃｐパケット受信のフローチ
ャートである。

【符号の説明】

１００送信側端末１１０ｒｔｐパケット送信部１２０ｒｔｃｐパケット送信部１３０ｒｔｃｐパケット受信部２００受信側端末２１０ｒｔｐパケット送信部２２０ｒｔｃｐパケット送信部２３０ｒｔｃｐパケット受信部３００ネットワーク

Claims

【特許請求の範囲】

【請求項１】所定のネットワークを介して、発信側端
末から受信側端末に向けてデータを送信すると共に、前
記ネットワーク上の状況を把握するための制御信号を所
定間隔に発信する通信制御方法であって、前記ネットワークの状況の変化を検出し、検出された状況の変化に応じて前記制御情報の発信の頻
度を調整することを特徴とする通信制御方法。
【請求項２】前記ネットワークの状況は、発信側端末
からの発信レート及び受信側端末での受信レートの差を
監視して検出することを特徴とする請求項第１項に記載
の通信制御方法。
【請求項３】前記発信側端末は送信レートを変更した
場合には制御情報の発信頻度を変更することを特徴とす
る請求項第１項に記載の通信制御方法。
【請求項４】前記発信側端末は前記データに与えられ
た所定の目標送信レートに対する実際の送信レートが低
い場合には当該送信レートを所定の割合高くすると共
に、前記所定間隔にかかわらず前記制御情報を受信側端
末に向けて送信することを特徴とする請求項第１項に記
載の通信制御方法。
【請求項５】前記所定間隔は所定の時間間隔であるこ
とを特徴とする請求項第１項に記載の通信制御方法。
【請求項６】前記発信側端末は、前記受信側からの制
御情報に基づいて転送データにロスが発生したか否かを
判断し、この判断によってロスの発生を判断した場合に、前記転
送レートを所定割合低く設定すると共に、前記所定間隔
にかかわらず前記制御情報を受信側端末に向けて送信す
ることを特徴とする請求項第１項に記載の通信制御方
法。
【請求項７】前記データはＲＴＰプロトコルに従った
パケット送信であって、前記制御情報はＲＴＣＰプロト
コルに従ったパケット送信であることを特徴とする請求
項第１項乃至第６項のいずれかに記載の通信制御方法。
【請求項８】前記受信側端末は、前記送信側端末から
の前記データの転送レートと、受信レートとの差が所定
以上になった場合、前記制御情報を前記送信側端末に送
信することを特徴とする請求項第１項乃至第７項に記載
の通信制御方法。
【請求項９】所定のネットワーク回線を介して、発信
側端末から受信側端末に向けてデータを送信すると共
に、前記ネットワーク上の状況を把握するための制御信
号を所定間隔に発信する通信制御システムであって、前記ネットワーク回線の状況の変化を検出する検出手段
と、検出された状況の変化に応じて前記制御情報の発信の頻
度を調整する調整手段とを備えることを特徴とする通信
制御システム。
【請求項１０】コンピュータが読み込み実行すること
で、所定のネットワーク回線を介して、発信側端末から
受信側端末に向けてデータを送信すると共に、前記ネッ
トワーク上の状況を把握するための制御信号を所定間隔
に発信する通信制御システムとして機能するプログラム
を格納した記憶媒体であって、前記ネットワーク回線の状況の変化を検出する検出手段
と、検出された状況の変化に応じて前記制御情報の発信の頻
度を調整する調整手段として機能するプログラムコード
を格納したことを特徴とする記憶媒体。