JP3662907B2 - データ送受信方法、送信装置、受信装置、送受信システム、およびプログラム - Google Patents

Description

【０００１】
［技術分野］
本発明は、例えばインターネットなどを利用したデータの送受信における、有線、無線が混在した、帯域が非常に大きく変動する環境下でのデータ送受信方法、送信装置、受信装置、送受信システム、およびプログラムに関するものである。
【０００２】
［背景技術］
イントラネット、インターネットといった、ＩＰ（Internet Protocol）ネットワーク上では、接続形態により利用可能な帯域が数Ｋｂｐｓ〜数百Ｍｂｐｓと大きく異なる。しかも、他のフローの影響により、利用可能な帯域が時間的に変動する。このようなネットワークを用いて安定した通信品質を提供するためには、通信経路において確保できる伝送帯域の最大値を見積もり（帯域推定と呼ぶ）、帯域の時間的な変動に応じて送信端末からのデータの伝送レートを変更する（伝送レート制御と呼ぶ）ことが必要となる。特に、ＵＤＰ（User Datagram Protocol）パケットを用いたデータ伝送は、ＴＣＰ（Transmission Control Protocol）と異なりトランスポート層においてフロー制御を行わないため、アプリケーション層においてデータの伝送レートを制御する必要がある。さらに、より伝送品質を向上させたい場合には、ルータなどの伝送路上の中間ノードでの帯域保証などが必要になる。
【０００３】
以下では、（１）帯域推定、（２）伝送レート制御、（３）帯域保証について、従来の技術を述べる。
【０００４】
（１） 帯域推定の従来技術
帯域推定の従来技術は、大きく分けて、パスチャ（pathchar）方式と、ペアパケット（Pair Packet）方式とが存在する。以下、pathchar方式とPair Packet方式をそれぞれ説明する。
【０００５】
（i） pathchar方式；通信経路における帯域推定方法の１つとして、pathcharが提供されている。これはtracerouteと同様、ＴＴＬ（Time To Live）フィールドをｎにしたパケットを送出することにより、経路上のｎ番目のルータにＩＣＭＰ（Internet Control Message Protocol）パケットのTTL Expiredメッセージを送信させることで各ルータとの往復伝播遅延時間（ＲＴＴ：Round Trip Time）を計測するものである（A. B. Downey et al.,"Using pathchar estimate Internet link characteristics", ACM SIGCOMM '99）。
【０００６】
pathcharによる帯域推定は多くのＲＴＴデータから統計処理によって帯域を推定する。pcharは、さらにこの統計処理方法を工夫することにより、精度向上とともに推定した帯域の信頼度を計算することができる。
【０００７】
（ii） Pair Packet方式；Pair Packet方式による帯域推定は以下のように行われる。すなわち、送信端末は、帯域推定用パケットを連続して受信端末に送信する。帯域推定用パケットは、リンクのパケット処理速度の違いから、ボトルネックリンクを通過したあとに、パケット間に間隔が発生する。この間隔を測定し、帯域推定用パケットのサイズを用いてボトルネックリンクの帯域を計算する（R. L. Carter et al., "Measuring Bottleneck Link Speed in Packet-Switched Networks", Technical Report BU-CS-96-006, Computer Science Department, Boston University, March 1996）。
【０００８】
（２） 伝送レート制御の従来技術
従来のＵＤＰパケットの伝送レート制御の例として、ＤＡＡ（Direct Adjustment Algorithm）方式を挙げることができる（D. Sisalem et al.,"The Direct Adjustment Algorithm: A TCP-Friendly Adaptation Scheme", Technical Report GMD-FOKUS, August 1997. Available from http://www.fokus.gmd.dc/usr/sisalem）。また、ＬＤＡ（Loss-Delay Based Adjustment Algorithm）方式を挙げることができる（D. Sisalem et al.,"The Loss-Delay Based Adjustment Algorithm: A TCP-Friendly Adaptation Scheme", in the proceedings of NOSSDAV'98, July, Cambridge, UK）。ＤＡＡ方式やＬＤＡ方式では、データのロス率をＲＴＣＰ（RTP Control Protocol）を用いて受信端末から送信端末にフィードバックし、パケットロス率や受信端末の受信レートなどに基づいてデータの伝送レートを変更する。
【０００９】
また、送信端末から受信端末までの伝送路に１つの仮想バッファがあるものとみなし、仮想バッファ内に残留しているデータ量を目標バッファ量に近づけるように伝送レートを調整する方式もある（日本国特開平１１−３０８２７１号公報）。
【００１０】
決定された伝送レートに基づいて送信するデータ量を調整する方法は、リアルタイムデータを送信する場合と、蓄積データを送信する場合とで異なる。例えば、監視カメラの映像を直接配信するようなリアルタイムデータの配信では、エンコーダに直接符号化レートを指示することが可能である。蓄積データの場合には、映像がすでに符号化されているため符号化レートを指示することはできない。したがって、蓄積データの場合には、異なる符号化レートで同一のデータを符号化しておき、決定した伝送レートに最も近い伝送レートで配信する方法が適用されている。例えば、RealVideoは、この方式を採用している（http://service.jp.real.com/help/faq/surestream.html ）。
【００１１】
その他、符号化したデータを間引く（映像データならば、フレームを間引くなど）処理を行って配信するか、一旦映像データを復号して指定された符号化レートに符号化しなおすなどの方法により、データ送信量を伝送レートにあわせる方法が考えられている。
【００１２】
（３） 帯域保証の従来技術
ＦＴＴＨ（Fiber To The Home）では、最低利用できる帯域の保証と、最大限利用できる帯域を限定する方式が提案されている。
【００１３】
従来技術は以上のとおりであるが、インターネットのような、様々な接続形態が存在し、しかも伝送帯域が変動する伝送路において、安定した伝送品質でデータ伝送を行うことは、上記の従来技術だけでは困難である。例えば、上記従来技術には次に述べるような課題があった。
【００１４】
〈課題１〉
pathchar方式は、３２バイトから１４７２バイトまで３２バイト間隔で４６種類のサイズのパケットを送信するという１セットを、３２セット繰り返す。したがって、リンクの帯域を１箇所測定するのに、１４７２パケットを送信することになり、推定に多くの時間を要することになる。
【００１５】
〈課題２〉
Pair Packet方式を実際に帯域推定に利用する場合は、帯域推定用のパケットを本来送信したいデータパケットのほかに送信することとなり、伝送帯域を無駄に浪費することとなる。また、実際に帯域推定を行う場合には、帯域推定用のプロトコルをデータパケット送信用のプロトコルとは別に送受信端末に備える必要がある。
【００１６】
〈課題３〉
ＤＡＡ方式やＬＤＡ方式は、伝送レートの計算にパケットのロス率を用いている。これらの方式のように、ロス率に基づいて伝送レート制御を行う方式は、イーサネット（Ethernet）やマルチキャストでは有効である。しかしながら、ＩＰネットワーク上でのエンド−エンド間の通信で、狭帯域の伝送路を利用した場合には、パケットロスの発生から伝送レートの変更までに長時間を要することになる。パケットロスはボトルネックリンクのバッファオーバーフローにより発生するため、受信端末にパケットロスの情報が伝送されるのはオーバーフローしたバッファ内の全てのデータが伝送されるまでかかるからである。
【００１７】
一方、仮想バッファにバッファリングされているデータ量の計算にＲＴＴを用いる手法によれば、バッファオーバーフローが発生する前に伝送レートを調整することができるはずである。しかしながら、伝送路上にある複数のバッファを１つの仮想バッファに近似してしまうため、送信データが複数のバッファに分散している場合と、１つのバッファに集中している場合と、どちらの場合についても同じ動作を行うことになる。このような動作は、データのスループットを向上させたい場合には問題となる。
【００１８】
例えば、複数のバッファに送信データが分散してバッファリングされている場合には、個々のバッファに残留するデータ量が少なく、バッファに余裕があるため、目標バッファ量を大きく設定することでスループットを向上させることができる。また、１つのバッファに集中して送信データがバッファリングされている場合は、バッファに余裕がないため、目標バッファ量を大きく設定してしまうと、バッファオーバーフローが発生し、パケットロスが増大することとなる。
【００１９】
したがって、複数のバッファに分散してデータがバッファリングされている場合と、１つのバッファのみに集中してデータがバッファリングされている場合とで動作を切り替える必要があるが、１つの仮想バッファを考慮するのみでは、動作の切り替えは不可能である。
【００２０】
〈課題４〉
パケットロスが発生した場合には、パケットロスに基づいて伝送レートを変更し、パケットロスが発生していない場合には、レート制御方式の切り替えなどを行うことにより、パケットロスの発生に対して俊敏に対応することができる。しかしながら、そのための具体的な方法は、現在のところ提案されていない。
【００２１】
また、前述の課題３に述べたように、Ethernetやマルチキャストといったネットワークでは、パケットロスに基づいて伝送レート制御を行う方が効果的であるのに対し、エンド−エンド間の通信で、帯域ギャップの大きな伝送路を利用した場合には、前述のような方法を用いた方が効果的である。
【００２２】
このように、伝送路や配送方式によって適したレート制御方式が異なるが、伝送路や配送方式に応じて伝送レート制御を切り替える方式は、提案されていない。
【００２３】
〈課題５〉
一般に伝送レート制御を行う際には、伝送レートの初期値が問題となる。初期値を大きくし過ぎてしまうと、パケットロスが発生し、初期値を小さくし過ぎると、初期段階で帯域を有効に利用できない。
【００２４】
〈課題６〉
ＦＴＴＨなどでは、伝送すべきコンテンツ（映像、音声、データなど）の符号化レート、バッファリング時間、伝送レートに関しては、考慮されていなかった。そのため、伝送するコンテンツによっては、伝送品質が著しく劣化してしまっていた。
【００２５】
〈課題７〉
送信端末からのデータ伝送を受信端末で制御するプロトコルとして、ＲＴＳＰ（H. Schulzrinne et al., "Real Time Streaming Protocol", RFC 2326, Internet Engineering Taskforce, Apr. 1998）がある。このプロトコルでは、受信端末がデータ送信の開始、停止などを送信端末に要求し、送信端末が要求に応じてデータ送信の開始、停止を行うことができる。しかしながら、従来の伝送路では、パケットはＦＩＦＯ（First-In First-Out）キューに入力され、キューがいっぱいで入力できない場合にパケットを廃棄するのが一般的であったため、伝送路が輻輳している場合には、受信端末からの要求が輻輳により遅延、もしくはロスし、データの送信の開始、停止が遅延するという問題があった。特に、受信端末主導で輻輳回避を行うために、異なる伝送レートの映像をＲＴＳＰを用いて切り替えるような場合には、受信端末からのデータ送信の開始、停止は低遅延かつ確実に行われる必要がある。データ送信の停止が遅れると、輻輳がさらに悪化し、データ送信の開始が遅れると、受信端末で映像が途切れる結果となる。
【００２６】
ＴＣＰに関しても、制御パケット（ＳＹＮ、ＦＩＮパケットなど）とデータパケットの区別なく廃棄されると、セッションの確立、開放が遅れることになり、伝送効率の面で問題となる。
【００２７】
〈課題８〉
有線網と無線網とが相互に接続されたネットワークにおいて、例えば有線網に存在するＡＶサーバから無線網に存在する端末に対してＡＶデータを伝送する場合、有線網の輻輳を回避するために伝送レート制御が必要である。しかしながら、受信端末において、有線網で発生する輻輳によるパケットロスと無線網で発生する伝送エラーによるパケットロスとを区別することは困難であるため、このような伝送路ではパケットロスに基づいた伝送レート制御方式を適用しても、適切な伝送レート制御を行うことができなかった。輻輳が原因でパケットロスした場合は、輻輳回避のために伝送レートを下げる必要があるが、伝送エラーによるパケットロスに関しては、伝送レートを下げてもパケットロス率が変化しないため、伝送レートを下げる必要はない。
【００２８】
さらに、送信端末−受信端末間のＲＴＴに基づく伝送レート制御方式を適用した場合でも、無線網のＲＴＴが、リンクレイヤレベルでの再送や、ハンドオーバ、ヘッダ圧縮などの処理によって大きく揺らぐため、正確な伝送レート制御は困難であった（西田「無線ネットワークにおけるＴＣＰの改善に関する考察」，モバイルコンピューティングとワイヤレス通信研究会予稿集１４−６，pp.39-45，情報処理学会，２０００年９月）。
【００２９】
［発明の開示］
本発明は、このような従来の課題を考慮し、インターネットのような、様々な接続形態が存在し、しかも伝送帯域が変動する伝送路において（特に、従来安定した伝送品質でデータ伝送を行うことが困難であった有線網、無線網の混在する接続形態において）、安定した伝送品質でデータ伝送を行うことを目的とする。
【００３０】
この目的を達成するため、本発明に係るデータ送受信方法は、送信端末と受信端末との間の伝送路上に設けられた中間ノードのうちの全部または一部の中間ノードにおけるデータの受信および／または送信の状態に基づいて、前記送信端末からの伝送レートを決定することとしたものである。しかも、前記全部または一部の中間ノードと前記送信端末との間の往復伝播遅延時間、往復伝播遅延時間の揺らぎ、中間ノードでのパケットロス、中間ノードのリンクの帯域、過去の伝送レートの少なくとも１つに基づいて、前記送信端末からの伝送レートを決定することとし、前記往復伝播遅延時間、前記往復伝播遅延時間の揺らぎ、前記中間ノードでのパケットロスのうち少なくとも１つ以上の情報を前記送信端末が取得する際に、前記情報の取得が可能な送信端末を前記中間ノードで制限するものである。
【００３４】
［発明を実施するための最良の形態］
以下では、本発明に係る実施の形態について、図面を参照しつつ説明を行う。
【００３５】
〈実施の形態１〉
本実施の形態は、各中間ノードの送信または受信の状態に基づいて伝送レートを決定する伝送レート制御方式に関し、主として前述の課題３および５を解決するためのものである。
【００３６】
図１は、本実施の形態における全体像を表す図である。送信端末１０において、データ送信部１００は、キャプチャ、マイク、ファイルといった入力からデータを受け取り、必要なら符号化し、必要ならパケット化して受信端末１１にデータパケット送信する手段である。また、送信されたデータパケットのデータ量を測定する手段でもある。また、伝送レート決定部１０４により決定された伝送レートに基づき、データパケットの伝送レートを調整する手段でもある。データパケットの送信用プロトコルとしては、ＲＴＰ（Real Time Transport Protocol）といったデータ送信用プロトコルを想定している。
【００３７】
制御情報送受信部１０１は、データパケットに関する制御情報を受信端末１１と送受信する手段である。制御情報としては、パケットロス率、ＲＴＴ、受信端末１１が受信したデータパケットの最大シーケンス番号といった情報を想定している。制御情報送受信用のプロトコルとしては、ＲＴＣＰ（RTP Control Protocol）といったデータ伝送制御用プロトコルを想定している。
【００３８】
伝播遅延測定部１０２は、中間ノード１２，１３，１４、もしくは受信端末１１に対して、例えばＰＩＮＧ（Packet Internet Groper）パケットといったＲＴＴの測定可能なパケット（ＲＴＴ測定パケット）を送信し、ＲＴＴを測定する手段である。ＲＴＴ測定パケットは、全ての中間ノード１２〜１４および受信端末１１に送信してもよいし、過去の測定結果に基づいて、データパケットの残留している可能性の高い中間ノードにのみ送信してもよい。また、指定された閾値より狭いリンク帯域を持つ中間ノードに送信することとしてもよい。ＲＴＴ自体に代えてＲＴＴの揺らぎを、伝播遅延測定部１０２が測定することとしてもよい。
【００３９】
帯域情報取得部１０３は、伝送経路上の、送信端末−中間ノード間、中間ノード−中間ノード間、受信端末−中間ノード間のリンクの帯域（帯域情報と呼ぶ）を取得する手段である。取得方法としては、例えばＳＮＭＰ（Simple Network Management Protocol）といった機器管理用プロトコルを用いて中間ノードからリンクの帯域情報を取得してもよいし、pchar、pathchar、後述の実施の形態８に示す方法といった、帯域推定方法を用いてもよい。なお、この帯域情報取得部１０３は、ボトルネックとなるリンクを検出するための手段であるため、ネットワークの構成が明らかであり、ボトルネックリンクがわかっており、かつボトルネックリンクの帯域がわかっているかボトルネックリンクの帯域を知る必要がない場合は備えていなくともよい。
【００４０】
伝送レート決定部１０４は、データ送信部１００、制御情報送受信部１０１、伝播遅延測定部１０２、帯域情報取得部１０３より得られる、受信端末１１および中間ノード１２〜１４との間のＲＴＴ、帯域情報、送信したデータパケットのデータ量、各中間ノードに残留している送信データ量などに基づき、データパケットの伝送レートを決定する手段である。
【００４１】
端末制御部１０５は、これら各部を制御する手段である。
【００４２】
受信端末１１において、データ受信部１１０は、送信端末１０からのデータパケットを受信し、必要ならパケットをほどき、必要なら復号化し、モニタ、スピーカ、ファイルといった出力にデータを渡す手段である。
【００４３】
制御情報送受信部１１１は、データパケットに関する制御情報を送信端末１０と送受信する手段である。
【００４４】
伝播遅延測定応答部１１２は、伝播遅延測定部１０２から送信されるＰＩＮＧパケットといったＲＴＴ測定パケットに対して応答パケットを送信する手段である。制御情報送受信部１１１においてＲＴＴが測定可能な場合（例えば、制御情報送信用プロトコルにＲＴＣＰを用いた場合など）には、伝播遅延測定応答部１１２は備えていなくてもよい。
【００４５】
帯域推定応答部１１３は、送信端末１０からの帯域推定用パケットに応答する手段である。帯域情報取得部１０３が、ＳＮＭＰといった機器管理用プロトコルを用いて中間ノード１２〜１４からリンクの帯域情報を取得する場合には、帯域推定応答部１１３は備えていなくてもよい。また、送信端末１０が帯域情報取得部１０３を備えていない場合にも、帯域推定応答部１１３を備えていなくともよい。
【００４６】
端末制御部１１４は、受信端末１１における各部を制御する手段である。
【００４７】
中間ノード１２は、ＩＰルータのように、受信したデータパケットをあて先に転送するノードである。また、（１）送信する先のリンクの帯域よりも到着レートが高い場合には、データパケットをバッファリングすること、（２）帯域情報通知のための機器管理プロトコルを備える、もしくは帯域推定用パケットに応答すること（送信端末１０が帯域情報取得部１０３を備えていない場合には不要）、（３）認証された、つまり接続が許可された送信端末１０からのＲＴＴ測定パケットに応答することを想定している。
【００４８】
なお、上記（３）に関して、送信端末を認証する方法としては、ＲＴＴ測定パケットに応答する送信端末のＩＰアドレスを登録しておき、ＲＴＴ測定パケットを受信した際にＩＰアドレスを確認し、登録されている送信端末にのみ応答するという方法を用いる。
【００４９】
図２は、本実施の形態における、送信端末１０の動作を表すフローチャートである。送信端末１０は、データを送信する前に帯域情報を取得する（ステップ２００）。このステップは、帯域情報取得部１０３によって行われる。予めボトルネックとなる中間ノードがわかっており、かつボトルネックリンクの帯域がわかっているかボトルネックリンクの帯域の情報が伝送レートを決定する際に不要である場合には、このステップは不要である。
【００５０】
続いて、取得した帯域情報に基づき、データパケットの伝送レートＲ_sndの初期値を決定し、現在の時刻と、制御情報パケットの送信間隔Ｉｎｖｌとに基づき、制御情報パケットを送信する時刻Ｔ_sndを決定する（ステップ２０１）。伝送レートの初期値は、ステップ２００で得られた帯域情報を用いて、最も狭いリンクの帯域の値とする。これは、課題５の解決にあたる。ステップ２００を省いたため、ボトルネックリンクの帯域がわからない場合は、最低伝送レートなどで送信を開始する。伝送レートの初期値の決定は、伝送レート決定部１０４によって行われ、制御情報パケットの送信時刻の決定は、制御情報送受信部１０１によって行われる。
【００５１】
続いて、データパケットの送信を開始する（ステップ２０２）。このステップは、データ送信部１００によって行われる。制御情報パケットの送信時刻になった場合には、ＲＴＴ測定パケットと制御情報パケットを送信する（ステップ２０３）。ＲＴＴ測定パケットは、伝播遅延測定部１０２によって送信され、制御情報パケットは、制御情報送受信部１０１によって送信される。また、ＲＴＴ測定パケットの応答が受信された場合には、測定結果を記録する（ステップ２０４）。このステップは、伝播遅延測定部１０２によって行われる。また、受信端末１１から制御情報パケットを受信した場合には、送信したデータパケットのデータ量、帯域情報、測定されたＲＴＴから、次の伝送レートＲ_newを決定する（ステップ２０５）。このステップの動作は、伝送レート決定部１０４によって行われる。送信端末１０は、ステップ２０３からステップ２０５を繰り返し、伝送レートを更新していく。
【００５２】
図３は、図２において、伝送レートを決定するステップ（ステップ２０５）の送信端末１０の動作を表すフローチャートである。この動作は、伝送レート決定部１０４によって行われる。
【００５３】
送信端末１０と受信端末１１との間に、Ｎ個の中間ノードが存在するものとして、送信端末１０からｋ番目の中間ノードをＮｏｄｅ（ｋ）とする。送信端末１０とＮｏｄｅ（ｋ）、Ｎｏｄｅ（ｋ−１）との間の往復伝播遅延時間ＲＴＴ（ｋ）、ＲＴＴ（ｋ−１）と、Ｎｏｄｅ（ｋ）のリンクの帯域Ｒ_max（ｋ）から、Ｎｏｄｅ（ｋ）に残留している他のフローを含めた全データ量Ｂ_total（ｋ）を推定する（ステップ３００）。ここで、ＲＴＴ_min（ｋ）は、今までに測定した送信端末１０とＮｏｄｅ（ｋ）との間のＲＴＴのうちで、最小の値である。データ量Ｂ_total（ｋ）が閾値より大きい場合には、バッファにデータパケットが残留しているものと判定し、閾値よりも小さい場合には、Ｎｏｄｅ（ｋ）にデータパケットが残留していないものと判定する（ステップ３０１）。
【００５４】
データパケットが残留していないと判定された場合には、Ｎｏｄｅ（ｋ）からの出力レートはＮｏｄｅ（ｋ−１）の出力レートと等しいものとして、中間ノードからの送信データパケットの出力レートＲ_out（ｋ）を計算し、Ｎｏｄｅ（ｋ＋１）に対する処理に移る（ステップ３０２）。
【００５５】
データパケットが残留していると判定された場合には、ステップ３０３からステップ３０７の処理を行う。
【００５６】
まず、Ｎｏｄｅ（ｋ）にＩｎｖｌの間に流入した送信端末１０の送信データ量Ｂ_snd（ｋ）と、Ｎｏｄｅ（ｋ）にＩｎｖｌの間に流入した他のフローのデータ量Ｂ_other（ｋ）とを計算する（ステップ３０３）。ここで、Ｉｎｖｌは、受信端末１１から送信される制御情報パケットの送信時間間隔である。Ｒ_snd（ｋ）は、送信端末１０からのデータパケットがＮｏｄｅ（ｋ）に流入した入力レートであり、この値は、Ｎｏｄｅ（ｋ−１）の出力レートＲ_out（ｋ−１）に等しい。また、Ｂ’_total（ｋ）は、前回の測定で得られたＮｏｄｅ（ｋ）に残留している他のフローを含めた全データ量である。
【００５７】
続いて、Ｂ_snd（ｋ）とＢ_other（ｋ）との割合と、Ｎｏｄｅ（ｋ）に残留している送信端末１０の送信データ量と他のフローのデータ量との割合とが等しい、すなわち、
Ｂ_other（ｋ）：Ｂ_snd（ｋ）＝Ｂ_total（ｋ）−Ｂ_est（ｋ）：Ｂ_est（ｋ）が成立するものとして、送信データパケットの残留量Ｂ_est（ｋ）を計算する（ステップ３０４）。
【００５８】
また、Ｂ_snd（ｋ）とＢ_other（ｋ）との割合と、Ｎｏｄｅ（ｋ）からＩｎｖｌの間に流出した送信データ量と他のフローのデータ量との割合とが等しい、すなわち、
Ｂ_other（ｋ）：Ｂ_snd（ｋ）
＝（Ｒ_max（ｋ）−Ｒ_out（ｋ））・Ｉｎｖｌ：Ｒ_out（ｋ）・Ｉｎｖｌ
が成立するものとして、Ｎｏｄｅ（ｋ）からの送信データパケットの出力レートＲ_out（ｋ）を計算する（ステップ３０５）。
【００５９】
続いて、Ｎｏｄｅ（ｋ）に残留している送信データ量が、Ｉｎｖｌ後に目標データ量Ｂ_desに到達するよう入力レートＲ_inを設定する（ステップ３０６）。
【００６０】
最後に、Ｎｏｄｅ（ｋ）への入力レートがＲ_inとなるようＲ_new（ｋ）を求める（ステップ３０７）。
【００６１】
以上の計算を全ての中間ノードについて行い、Ｒ_new（ｋ）のなかで、最も小さい値を次の伝送レートＲ_newとする（ステップ３０８）。
【００６２】
なお、上記で説明した伝送レートの決定方法以外にも、中間ノード−送信端末間のＲＴＴもしくはＲＴＴの揺らぎ（ジッタ）を用いて伝送レートを決定するアルゴリズムや、中間ノードでのパケットロスの情報を利用したアルゴリズムも考えることができる。
【００６３】
例えば、ＲＴＴを用いたアルゴリズムとしては、以下が挙げられる。まず、ＲＴＴ（ｋ）、ＲＴＴ（ｋ−１）、ＲＴＴ_min（ｋ）、ＲＴＴ_min（ｋ−１）を用いて、Ｎｏｄｅ（ｋ）に観測パケットが残留していた時間Ｔ（ｋ）を、
Ｔ（ｋ）＝ＲＴＴ（ｋ）−ＲＴＴ_min（ｋ）
−（ＲＴＴ（ｋ−１）−ＲＴＴ_min（ｋ−１））
より計算する。
【００６４】
そして、このＴ（ｋ）がしきい値Ｔ_th（中間ノードのデータ残留時間の目標値、ユーザが指定する固定値）に近づくように、Ｒ_snd（ｋ）を、
Ｒ_snd（ｋ）＝（１−Ｔ（ｋ）／Ｔ_th）・Ｒ_max（ｋ）／ｎ＋Ｒ_rcv
より計算する。
【００６５】
ここで、Ｒ_max（ｋ）は、帯域推定において測定されたリンクの最大伝送帯域である。ｎは、送信レートの増減の割合を決定するパラメータである。この値をｎ＝Ｎと設定すると、Ｔ（ｋ）が常に０の場合（すなわち、常に輻輳が発生していない場合）、Ｒ_rcv＝０の状態から、最大伝送レートに達するまでにＮステップを要することになる。なお、帯域推定を行わず、ユーザがＲ_max（ｋ）の値を適当に決定することとしてもよい。この場合には、帯域情報取得部１０３を有する必要がなくなるため、実装が簡便となり、帯域推定を行うための時間を省略できるという利点がある。Ｒ_rcvは、受信端末１１からのフィードバック情報から計算される受信レートであり、例えば、ＲＴＣＰを用いてフィードバック情報を受信している場合には、
Ｒ_rcv＝Ｐ・（Ｓｅｑ_max（ｊ）−Ｓｅｑ_max（ｊ−１））
／Ｉ・（１−Ｌｏｓｓ）
で計算できる。ただし、Ｐは平均送信パケットサイズ、ＩはＲＴＣＰ受信レポートの受信間隔、Ｓｅｑ_max（ｊ）はｊ番目のＲＴＣＰ受信レポートの最大シーケンス番号、Ｌｏｓｓはパケットロス率である。
【００６６】
以上の計算を全ての中間ノードについて行い、最も小さいＲ_snd（ｋ）をデータの伝送レートＲ_newと決定する。
【００６７】
また、ＲＴＴの揺らぎを利用したアルゴリズムとしては以下のアルゴリズムが挙げられる。まず、上記で示したＴ（ｋ）の過去ｍ回の平均値ＳＴ（ｋ）と、Ｔ（ｋ）の標準偏差Ｊ（ｋ）とを用いて、
Ｔ_th（ｋ）＝ＳＴ（ｋ）＋ｋ・Ｊ（ｋ）
を計算する。ここで、ｍ、ｋは定数である。Ｔ_th（ｋ）とＴ（ｋ）とを比較し、Ｔ（ｋ）よりもＴ_th（ｋ）が大きい場合には、Ｎｏｄｅ（ｋ）に対する伝送レートＲ_snd（ｋ）をＲ_snd（ｋ）＝Ｒ_rcv＋Ｂとし、Ｔ（ｋ）よりもＴ_th（ｋ）が小さい場合にはＲ_snd（ｋ）＝Ｒ_rcv−Ｂとする。ここで、Ｂは伝送レートの増減の変動の大きさを決定する値である。上記の計算を全ての中間ノードで行い、最小の値を伝送レートＲ_newとする。
【００６８】
また、パケットロスの情報を用いた場合には、以下のアルゴリズムを適用できる。まず、パケットロス率を中間ノードから通知するしくみであるものとし、伝送レートＲ_newを、
Ｒ_new＝（現在の伝送レート）・（１−Ｌｏｓｓ）
と計算する。もしくは、パケットがバッファ溢れによりロスしたことを中間ノードから通知するしくみであるものとし、パケットロスの通知を受信した際に、Ｒ_new＝（現在の伝送レート）・αあるいはＲ_new＝（現在の伝送レート）−α’（ここでαあるいはα’は定数）といったように、伝送レートを指数的もしくは加算的に削減する。
【００６９】
なお、上記の例では、全ての中間ノードについてＲ_snd（ｋ）の計算を行うこととしたが、伝送経路上のボトルネックリンクを選択し、そのリンクに接続された中間ノードにのみＲＴＴ測定パケットを送信して上記の計算を行うこととしてもよい。ボトルネックリンクの選択方法としては、例えば、
Ｒ_max（ｊ）＜α・ｍｉｎ（Ｒ_max（ｉ））
を満たすリンクをボトルネックリンクとみなす方法が考えられる。ここで、ｍｉｎ（Ｘ（ｉ））は、Ｘ（ｉ）の要素の中で、最も小さい値を表す。αはボトルネックリンクの検出感度を表す値であり、この値が大きいほど多くのリンクをボトルネックリンクとして判定する。
【００７０】
〈実施の形態２〉
次に、課題８の解決について説明する。本発明の中間ノードの輻輳状態を利用した伝送レート制御方式を利用すれば、図４に示すような有線網４０４と無線網４０５とが相互に接続されたネットワークにおいて、例えば、有線網４０４上に存在する送信端末４０１から無線網４０５上に存在する受信端末４０３に対して、データを伝送する場合に、無線網４０５の伝播遅延の揺らぎの影響を受けずに、伝送レート制御を行うことが可能となる。このような接続形態は、携帯電話などの移動体端末が受信端末４０３となり、サーバ（送信端末）４０１に接続する場合などが考えられる。すなわち、サーバ４０１とゲートウェイ４０２とがEthernetやＡＴＭ（Asynchronous Transfer Mode）などの有線網４０４で接続され、ゲートウェイ４０２と受信端末４０３とが無線ＬＡＮ（Local Area Network）やＷ−ＣＤＭＡ（Wideband Code Division Multiple Access）などの無線網４０５で接続されている場合である。また、家庭内ネットワークが無線ＬＡＮ、BlueToothなどにより構成されており、家庭内のネットワークと外部ネットワークとを接続するホームゲートウェイ４０２などから電話回線などを通じてインターネットに接続されている場合にも、同様の接続形態になる。アプリケーションとしては、ビデオ・オン・デマンドのような映像配信や、ＴＶ電話のような双方向の通信を想定している。
【００７１】
より具体的に述べると、通常は有線網４０４と無線網４０５とを相互接続するためのゲートウェイ（あるいはルータ）４０２において輻輳が発生するため、送信端末４０１とゲートウェイ４０２との間の輻輳状態を、例えばＲＴＴを利用して測定することで（他の中間ノードを含めてもよい）、送信端末４０１からの送出量を制御することができる。すなわち、ゲートウェイ４０２を上記実施の形態１の中間ノード１２〜１４の１つとみなし、当該中間ノードの状態により伝送レート制御を行うのである。
【００７２】
送信端末４０１と受信端末４０３との間で輻輳状態の検出のためにＲＴＴ、ＲＴＴの揺らぎを測定した場合には、無線網４０５の揺らぎが大きく輻輳状態の検出を正確に行うことができない場合が多いが、本発明を用いれば、送信端末４０１とゲートウェイ４０２との間の有線網４０４のみのＲＴＴ、ＲＴＴの揺らぎを測定するため、輻輳の検出を正確に行うことが可能となる。また、パケットロスの原因が有線網４０４は輻輳、無線網４０５は伝送エラーであるため、送信端末４０１と受信端末４０３との間でパケットロスを観測した場合には、前述の課題８に述べたとおり、適切な伝送レート制御ができないが、本発明を用いれば、送信端末４０１とゲートウェイ４０２との間の有線網４０４のみのパケットロスを観測するため、輻輳によるパケットロスだけを観測することができ、適切な伝送レート制御を行うことが可能である。
【００７３】
なお、図４の形態以外にも、例えば、図５に示すような接続形態や、さらに、有線網、無線網を複数段通過する接続形態が考えられるが、そのような接続形態においても、送信端末と当該送信端末から１つ目のゲートウェイまでの間の有線網にボトルネックリンクが存在し、２つ目以降の有線網にボトルネックリンクが存在しない場合には、本発明の実施は可能である。図５に示される接続形態としては、屋内のネットワークが有線で構築されており、ＦＷＡ（Fixed Wireless Access）などで外部ネットワークに接続している形態が考えられる。また、自動車の車内ネットワークが有線で構築されており、ＤＳＲＣ（Dedicated Short Range Communication）などで外部ネットワークと接続している場合も同様の接続形態となる。アプリケーションとしては、ビデオ・オン・デマンドのような映像配信や、ＴＶ電話のような双方向の通信が考えられる。
【００７４】
なお、図４および図５に示す無線網と有線網とを相互接続したネットワークにおいて、有線網で発生する輻輳に対処してデータ送出量の制御を行うための方法としては、上記の方法の他にも、例えば次の２つが考えられる。
【００７５】
１つ目の方法は、送信端末と受信端末との間で、ＲＴＴ、パケットロス、ジッタなどのうちの少なくとも１つを測定することでその変動幅や変化期間を計算し、ネットワークにおいて、輻輳が発生している状態にあるのか、あるいはハンドオーバーや伝送エラーなどが発生している状態にあるのかを判断し、前者であると判断した場合には、送信端末は輻輳状態に応じてデータの送出量を制御する方法である。
【００７６】
２つ目の方法は、ゲートウェイなどのルータで輻輳が発生している場合に、輻輳の発生を示すための、ＩＰパケットにおけるＥＣＮ（Explicit Congestion Notification）フラグを利用して、ルータから受信端末へそれを通知する方法である（ＥＣＮ方式と呼ぶ）。
【００７７】
まず、送信端末は、同一内容のコンテンツをいくつかの相異なる符号化レートで符号化する。リアルタイムで送信を行う場合には複数のエンコーダでこのような符号化を行い、蓄積コンテンツを利用して送信を行う場合には複数の符号化レートで予め符号化を行っておけばよい。送信端末は、送信される複数の符号化レートをＳＭＩＬ（Synchronized Multimedia Integration Language）などを用いて受信端末に通知し、受信端末は、そのうちの１つをＲＴＳＰなどを用いて選択的に受信する。送信途中で輻輳が発生した場合には、ルータにおいて前述のＥＣＮフラグにマークが付されるため、受信端末は、ＥＣＮフラグを監視することで輻輳の発生を検知することができる。そして、輻輳の発生が検知されたときには、受信端末がＲＴＳＰなどを用いてより低い符号化レートに選択を切り替えて受信（および再生）を行うことで、輻輳状態が緩和される。なお、どの符号化レートへの選択切替を行うのかは、所定期間内に受信されたＩＰパケットのうち、ＥＣＮフラグにマークが付されたＩＰパケットの個数を所定の閾値と比較するなどして決定すればよい。もちろん、（１）ＥＣＮフラグにマークが付されたＩＰパケットを所定期間内に全く受信しなかった場合や、（２）所定期間内に受信したＩＰパケットのうちでＥＣＮフラグにマークが付されたＩＰパケットの個数が所定の閾値よりも少なかった場合には、ＲＴＳＰなどを用いてより高い符号化レートへの選択切替を行うことにより、輻輳の発生を回避しつつ伝送レートを増加させ、高品質のコンテンツ伝送を実現することが可能になる。なお、どの符号化レートへの選択切替を行うのかは、前述の場合と同様、ＥＣＮフラグにマークが付されたＩＰパケットの個数を所定の閾値と比較するなどして決定すればよい。
【００７８】
ＥＣＮ方式では、ＥＣＮフラグを用いることにより、輻輳を明示的に受信端末に通知する。これにより、有線網と無線網とが相互接続された伝送路においても、受信端末が輻輳検出を正確に行うことができるようになり、適切な伝送レート制御を行うことができる。さらに、ＥＣＮ方式は、受信端末主導で伝送レートを切り替えるため、ユーザ要求の反映が容易であるという効果がある。つまり、伝送レートの変動範囲を受信端末に登録するだけでよい。送信端末主導の伝送レート制御方式の場合には、送信端末に伝送レートの変動範囲を登録する必要があるため、登録用のプロトコルなどが必要になる。さらに、有線網、無線網が複数段接続された接続形態においても、受信端末での輻輳検出が可能となり、適切な伝送レート制御を行うことが可能となる。
【００７９】
図６は、本実施の形態に係るＥＣＮ方式の全体像を表す概略図である。送信端末６０におけるデータ送信部６０１、端末制御部６０４、および受信端末６１における端末制御部６０９は、図１と同等である。
【００８０】
データ情報送信部６０３は、送信端末６０が送信可能なデータの伝送レートを通知する手段である。送信端末６０が送信可能なデータの伝送レートを記述する記述言語としては、ＳＭＩＬなどを用いればよい。
【００８１】
データ送信制御応答部６０２は、受信端末６１からのデータ送信／停止などの要求を受信し、要求に基づいてデータ送信の開始、停止指示をデータ送信部６０１に指示し、その要求が受け入れられたかどうかの結果を受信端末６１に応答する手段である。送信端末６０と受信端末６１との間の要求／応答の送受信プロトコルとしては、ＲＴＳＰなどを用いればよい。
【００８２】
例えば中間ノード６２に設けられた輻輳検出部６１０は、当該中間ノード６２のデータの送受信状態を監視し、輻輳が発生した場合には、輻輳が発生したことを表す輻輳情報（フラグなど）をデータパケットに付加して受信端末６１に送信する手段である。輻輳情報は、例えばＩＰパケットのＥＣＮフラグを用いて通知すればよい。この輻輳検出部６１０は、中間ノード６２，６３，６４の全てに搭載されていてもよいし、輻輳の発生しやすい中間ノードにのみ搭載することとしてもよい。
【００８３】
受信端末６１において、データ受信部６０５は、図１のデータ受信部１１０に、中間ノード６２によって付加された輻輳情報を伝送レート決定部６０８に通知する機能を追加したものである。
【００８４】
データ情報取得部６０７は、送信端末６０が送信可能なデータの伝送レートを取得し、伝送レート決定部６０８に通知する手段である。
【００８５】
伝送レート決定部６０８は、通知された輻輳情報と送信端末６０が送信可能な伝送レートとに基づき、伝送レートを決定し、データ送信制御要求部６０６に通知する手段である。
【００８６】
データ送信制御要求部６０６は、伝送レート決定部６０８で決定された伝送レートに基づき、データ送信／停止などの要求を送信する手段である。
【００８７】
図７は、本ＥＣＮ方式の動作の流れを表すシーケンス例である。まず、受信端末６１は、送信端末６０が送信可能な伝送レートをＳＭＩＬにより取得する（ステップ７０１）。図８にこの例で使用するＳＭＩＬの記述のうち、伝送レートに関する部分を示す。図８をみると、この例では、Ｓｔｒｅａｍ２を選択した場合には６４Ｋｂｐｓ（８０１）、Ｓｔｒｅａｍ１を選択した場合には１２８Ｋｂｐｓ（８０２）の２種類の伝送レートでデータの送信が可能であることがわかる。
【００８８】
受信端末６１は、受信したＳＭＩＬの記述に基づき、ＲＴＳＰのＳＥＴＵＰメソッドを用いて、全ての伝送レートのデータを送信開始可能な状態（Ｒｅａｄｙ状態）にする（ステップ７０２）。もちろん、データ送信開始の前に必ずしも全ての伝送レートのデータをＲｅａｄｙ状態にする必要はなく、データ送信開始の前には一部の伝送レートのデータだけＲｅａｄｙ状態にしておき、他の伝送レートのデータはデータの送信中に必要があればＲｅａｄｙ状態にすることにしてもよい。
【００８９】
続いて受信端末６１は、送信端末６０が送信可能な伝送レートのうち、１つを選択してデータ送信の開始を送信端末６０に要求する。送信端末６０は、要求に応答してデータの送信を開始する（ステップ７０３）。図７では、データ送信用プロトコルとしてＲＴＰを用い、１２８Ｋｂｐｓでデータ（Ｓｔｒｅａｍ１）の送信を開始している。その後、データ送信中に中間ノード６２において輻輳が発生すると、輻輳が発生したことをＥＣＮフラグを用いて受信端末６１に通知する（ステップ７０４）。受信端末６１は、中間ノード６２がセットしたＥＣＮフラグに基づいて伝送レートを決定し、伝送レートを変更するために、現在受信しているデータの送信をＲＴＳＰのＰＡＵＳＥメソッドにより一時停止し、現在受信したデータの続きから他の伝送レートのデータを送信するようＲＴＳＰのＰＬＡＹメソッドを用いて送信端末６０に通知する。データの途中からの送信開始は、ＲＴＳＰのＰＬＡＹメソッドに再生範囲を指定するヘッダ（Ｒａｎｇｅヘッダ）があるので、それを利用すればよい。送信端末６０は、一時停止/再生要求に基づいて、現在送信している伝送レートのデータ送信を一時停止し、他の伝送レートのデータ送信を開始する（ステップ７０５）。図７では、１２８Ｋｂｐｓのデータ（Ｓｔｒｅａｍ１）の送信を一時停止し、６４Ｋｂｐｓのデータ（Ｓｔｒｅａｍ２）のデータの送信を開始している。
【００９０】
図９は、伝送レート決定部６０８が伝送レートを決定するアルゴリズムを示すフローチャートである。まず、送信端末６０が送信可能な伝送レートＲ_snd（ｊ）（１≦ｊ≦Ｎ）を取得し、記録する（ステップ９０１）。この例では、送信端末６０が送信可能な伝送レートはＮ個の離散値であることを想定している。
【００９１】
次に、送信端末６０が送信可能な伝送レートのうちの１つを初期伝送レートとして決定し、データ送信制御要求部６０６に通知する（ステップ９０２）。続いて、データパケットを受信するたびに、過去Ｎ個の受信パケットのうち、ＥＣＮフラグの立っていたパケットの数をＭとし、その割合Ｌ＝Ｍ／Ｎを計算する（ステップ９０３）。ここで、ｉ回目のデータパケットの受信の際に計算されたＭ、ＬをそれぞれＭ（ｉ）、Ｌ（ｉ）とし、以下のルールに従い、伝送レートを決定する。
【００９２】
（１） Ｍ（ｉ−１）＝０かつＭ（ｉ）≠０ならば、現在受信している伝送レートＲよりもαだけ伝送レートを下げる（ステップ９０４）。ここで、αは固定値である。
【００９３】
（２） Ｌ（ｉ）＞β（βは０＜β＜１の定数）の場合には、伝送レートを（現在の伝送レート）・（１−Ｌ（ｉ））に下げる。このステップを行ったあとは、伝送レートはＩ秒間変化させない（ステップ９０５）。
【００９４】
（３） Ｍ（ｌ）（ｉ−Ｋ≦ｌ≦ｉ、Ｋは定数）から、Ｍ（ｉ）≒γ・ｉ＋δとなる一次近似直線を最小２乗法などにより求め、γがある閾値より大きい場合には、伝送レートを（現在の伝送レート）・Ｃ／γ（Ｃは定数）に下げる。このステップを行った後は、Ｉ’秒間このステップを行わない（ステップ９０６）。このステップは、Ｍ（ｉ）が増加傾向にある場合に伝送レートを下げる役割を果たしている。
【００９５】
（４） 伝送レートを変更してＩ”秒が経過しており、Ｍ（ｉ）＜θ（θは定数）ならば、伝送レートを（現在の伝送レート）＋α’（α’は定数）に増加させる。このステップを行った後は、Ｉ”秒間このステップを行わない（ステップ９０７）。
【００９６】
（５） （１）〜（４）に当てはまらない場合には、伝送レートを変更しない。
【００９７】
以上のステップで決定された伝送レートの値と送信端末６０が送信可能な伝送レートとを比較し、最も近い値を伝送レートとして決定し、現在受信している伝送レートと異なる場合には、新しい伝送レートをデータ送信制御要求部６０６に通知する（ステップ９０８）。
【００９８】
なお、本実施の形態は、伝送レートを決定する方法を示すものであり、決定された伝送レートに基づいてデータの送信量を調整する方法については、先に従来例に述べたとおりの方法を用いればよい。すなわち、リアルタイムデータであれば、エンコーダに直接符号化レートを指示することで調整が可能であり、蓄積データであれば、複数の符号化レートでデータを符号化しておき、決定された伝送レートに最も近い符号化レートのデータを送信するなどにより調整が可能である。
【００９９】
〈実施の形態３〉
本発明は、１対１のデータ送受信に限定されるものではなく、マルチキャストのような１対Ｎでのデータ送受信にも利用可能である。マルチキャストの場合にも、図１０に示すように、送信端末と複数の受信端末とが、１つのゲートウェイを介して接続している接続形態の場合には、前述の場合と同様、送信端末とゲートウェイとの間のＲＴＴ、パケットロス、ジッタなどのうちの少なくとも１つを測定することで、送信端末からのデータの送出量を制御することができる。すなわち、有線網における輻輳状態を測定することにより、このような制御を行うのである。
【０１００】
しかしながら、図１１に示すように、送信端末と複数の受信端末とが複数のゲートウェイを介して接続する接続形態で伝送レートを決定する場合には、有線網の伝送経路が１つでないため、上記で述べた伝送レート制御方法だけでは全ての受信端末に最適な伝送レート制御を行うことができない。
【０１０１】
本実施の形態は、送信端末と複数のゲートウェイとが接続している接続形態での、伝送レート制御方法を提供するものである。
【０１０２】
送信端末と複数の受信端末とが複数のゲートウェイを介して接続している場合には、測定によって得られた複数のゲートウェイでの輻輳状態に応じて、輻輳が発生しているゲートウェイをグループに分割し、グループごとにデータの送出量を調整する。ＩＰｖ４（Internet Protocol Version 4）においては、そのようなグループの範囲をＴＴＬの値を利用して制限することが可能である。例えば、輻輳の発生している受信端末が属するグループに対してはデータの送出量を減らし、輻輳の発生していないグループに対しては送出量を増やす。このようなグループ分割により、ネットワークにおける輻輳の発生状態に対応したきめ細かなデータ送出量の制御を行うことができる。
【０１０３】
図１２は、本実施の形態における全体像を示す概略図である。送信端末１２１は、グループ決定部１２０１を除いて、図１における送信端末１０と同等である。また、受信端末１２２は、グループ変更部１２０２を除いて、図１における受信端末１１と同等である。
【０１０４】
グループ決定部１２０１は、制御情報送受信部１２０３で観測された、ＲＴＴ、パケットロス、ジッタなどの統計情報や、伝播遅延測定部１２０４で観測された、各中間ノード（複数のゲートウェイを含む）とのＲＴＴ、伝送レート決定部１２０５で決定された伝送レートのうち、少なくとも１つに基づき、受信端末１２２をグループ分けし、受信端末１２２にそれぞれが所属するグループを通知する手段である。
【０１０５】
グループ変更部１２０２は、送信端末１２１から通知されたグループが、自分が現在所属しているグループと異なる場合に、所属するグループを通知されたグループに変更する手段である。
【０１０６】
図１３は、本実施の形態の動作を表すシーケンス図である。この例では、受信端末ＡはゲートウェイＡに接続されており、受信端末Ｂ、ＣはゲートウェイＢに接続されているものとしている。
【０１０７】
受信端末Ａ、Ｂ、Ｃは、マルチキャストで映像受信を開始する際に、ＩＧＭＰ（Internet Group Management Protocol）を用いて特定のマルチキャストグループに参加する（ステップ１３０１）。この例では、各受信端末は最初にグループＡに参加する。送信端末１２１は、受信端末からの制御情報パケットによって、受信端末がマルチキャストグループに参加したことを知ることができる（ステップ１３０２）。更に、送信端末１２１は、各受信端末までの伝送経路上のボトルネックとなりうるリンクにＲＴＴ観測パケットを送信し、ＲＴＴを求める（ステップ１３０３）。このＲＴＴと、制御情報パケットから得られる受信端末との間のＲＴＴ、パケットロス、ジッタなどの情報を用いて、各端末が所属するグループを決定し、受信端末に通知する（ステップ１３０４）。この例では、受信端末ＡをグループＢに変更する通知を送信している。受信端末Ａは、現在所属しているグループと、送信端末１２１から通知されたグループとが異なるため、グループＡをいったん抜けて、グループＢに参加しなおす（ステップ１３０４）。
【０１０８】
なお、各マルチキャストグループに対してデータを送信する際の伝送レートは、そのマルチキャストグループに所属する各受信端末に対する伝送レート（上記実施の形態１または２に示した方法で計算できる）の平均値とする。後述するように、伝送レートの変化の傾向が似ている受信端末を同じグループにまとめているため、上記のような単純な伝送レート決定方法でも、そのマルチキャストグループに参加する受信端末がおよそ満足できる伝送レートになる。
【０１０９】
図１４は、グループ決定部１２０１の動作を示すフローチャートである。まず、受信端末Ａからの制御情報パケットと、受信端末Ａへの伝送路上にある中間ノードからのＲＴＴ観測パケットとを受信し、上記実施の形態１または２に示す伝送レート制御方法に従って伝送レートＲｍを決定する（ステップ１４０１）。続いて、受信端末Ａについて過去Ｎ回計算された伝送レートＲｍ（ｉ）（１≦ｉ≦Ｎ）と、マルチキャストグループｊ（１≦ｉ≦Ｍ、Ｍは送信端末１２１の管理しているマルチキャストグループの数）について過去Ｎ回計算された伝送レートＲｏ（ｊ,ｉ）から、伝送レートの差Ｑを計算する（ステップ１４０２）。Ｑがある閾値Ｃよりも小さければ、伝送レートの変化の傾向が近いと判断し、受信端末Ａをマルチキャストグループｊに変更する（ステップ１４０３）。ＱがＣよりも大きい場合には、伝送レートの変化の傾向が異なるものとして、受信端末Ａをマルチキャストグループｊに含めない（ステップ１４０４）。ステップ１４０３、１４０４を、受信端末Ａをいずれかのマルチキャストグループに分類するか、全てのマルチキャストグループと伝送レートの変化の傾向を比較するまで繰り返す。全てのマルチキャストグループと伝送レートの変化の傾向を比較しても、Ｑ＜Ｃを満たすマルチキャストグループがない場合には、新しいマルチキャストグループを生成し、受信端末Ａをそのグループに変更する（ステップ１４０５）。
【０１１０】
なお、本実施の形態においては、グループ分割を行う方法として、伝送レートの変動の傾向が似ているものをグループ化しているが、より単純に、同じゲートウェイに接続されている受信端末を１つのグループとしてもよい。また、伝送レートの変動の傾向ではなく、パケットロスの傾向、ＲＴＴの変動の傾向などが似ているものでグループ化してもよい。
【０１１１】
また、本実施の形態においては、伝送レートの決定に送信端末１２１と中間ノードとの間のＲＴＴを利用していたが、図３の説明の際に述べたとおり、中間ノードとの間のＲＴＴの揺らぎ、中間ノードでのパケットロスに基づいて、伝送レートを決定し、決定された伝送レートに基づいてグループ分割を行うこととしてもよい。
【０１１２】
また、送信端末１２１と受信端末との間のＲＴＴ、パケットロス、ジッタなどのうちの少なくとも１つを測定することでその変動幅や変化期間を計算し、ネットワークにおいて、輻輳が発生している状態にあるのか、あるいはハンドオーバーや伝送エラーなどが発生している状態にあるのかを判断し、前者であると判断した場合には、送信端末１２１は輻輳状態に応じて前述のようなグループ分割を行うこともできる。
【０１１３】
また、本実施の形態においては、送信端末１２１が各受信端末の所属すべきグループを決定し、受信端末がそれに従うという方法により、グループ分割がなされているが、受信端末がグループ決定部１２０１を保持することにより、受信端末主導でグループ分割を行うことも可能である。例えば、図６に示す構成の受信端末６１にグループ決定部１２０１を追加した構成の場合には、送信端末６０が送信可能な伝送レートとマルチキャストアドレスとの組をデータ情報として受信端末６１に送信しておき、伝送レート決定部６０８で決定された伝送レートに基づいて参加するマルチキャストグループを変更するといった方法を用いることにより、受信端末主導のグループ分割も可能である。
【０１１４】
また、本実施の形態において、階層符号化を利用したＡＶ伝送が可能である場合には、受信端末において、利用する階層を輻輳状態に応じて決定することもできる。例えば、輻輳の程度が深刻である場合には、最下位の階層のみを利用することにすればよい。
【０１１５】
以上述べたとおり、実施の形態１〜３によれば、中間ノードのデータの送受信の状態を考慮した伝送レート制御を行うことで、インターネットのような様々な接続形態で接続されるネットワークにおいても、適切な伝送レート制御を行うことができる。特に、従来適切な伝送レート制御が困難であった、無線ＬＡＮ、ＤＳＲＣ、Ｗ−ＣＤＭＡ、ＦＷＡ、といった無線網と、Ethernet、ＡＴＭといった有線網とが混在する接続形態において、１対１通信、１対Ｎ通信（マルチキャスト）によらず、ＴＶ電話、ビデオ・オン・デマンドといったアプリケーションで適切な伝送レート制御を行うことができる。
【０１１６】
〈実施の形態４〉
本実施の形態は、中間ノードに残留する残留データ量を目標値に近づけようとする際における、中間ノードの状態に応じた目標値変更方式に関し、主として前述の課題３を解決するためのものである。
【０１１７】
図１５は、本実施の形態における全体像を表す概略図である。同図において、送信端末１５０は、図１の送信端末１０から帯域情報取得部１０３を削除したものである。受信端末１５１は、図１の受信端末１１から帯域推定応答部１１３を削除したものである。中間ノード１５２，１５３，１５４は、図１の中間ノード１２〜１４と同等である。
【０１１８】
図１６は、本実施の形態における送信端末１５０の動作を表すフローチャートである。同図は、図２において、帯域情報を取得するステップ（ステップ２００）を削除し、伝送レートの初期値を適当な値に設定するよう変更したものに他ならないので、ステップ番号は省略する。
【０１１９】
図１７は、図１６中の伝送レートを決定するステップの動作を表すフローチャートである。この動作は、送信端末１５０における伝送レート決定部１５０３の動作である。まず、受信端末１５１の受信レートＲ_rcvを計算する（ステップ１７００）。ＲＴＣＰを用いて制御情報を送信している場合には、最大シーケンス番号ＳＥＱ_maxと、パケットロス率Ｌｏｓｓと、制御情報パケットの送信間隔Ｉｎｖｌとを用いてＲ_rcvを計算できる。ただし、ＳＥＱ’_maxは、前回のＲＴＣＰパケットによって通知された最大シーケンス番号である。
【０１２０】
続いて、送信端末１５０と受信端末１５１との間の伝送路上に残留しているデータ量Ｂ_estを、送信端末１５０と受信端末１５１との間のＲＴＴと、Ｒ_rcvとを用いて計算する（ステップ１７０１）。ここで、ＲＴＴ_minは、今までに送信端末１５０と受信端末１５１との間で測定したＲＴＴのうちで最小の値を表す。
【０１２１】
続いて、送信端末１５０とＮｏｄｅ（ｋ）、Ｎｏｄｅ（ｋ−１）との間の往復伝播遅延時間ＲＴＴ（ｋ）、ＲＴＴ（ｋ−１）と、Ｎｏｄｅ（ｋ）のリンクの帯域Ｒ_max（ｋ）とから、Ｎｏｄｅ（ｋ）に残留している他のフローを含めた全データ量Ｂ_total（ｋ）を推定する（ステップ１７０２）。ここで、ＲＴＴ_min（ｋ）は、今までに送信端末１５０とＮｏｄｅ（ｋ）との間で測定したＲＴＴのうちで最小の値を表す。このデータ量Ｂ_total（ｋ）が閾値より大きい場合には、Ｎｏｄｅ（ｋ）にデータパケットが残留しているものと判定し、閾値よりも小さい場合には、Ｎｏｄｅ（ｋ）にデータパケットが残留していないものと判定する（ステップ１７０３）。
【０１２２】
判定によってデータパケットが残留しているとされた中間ノードの数ｎをカウントし、目標データ量Ｂ_desを基本目標データ量Ｂ_baseとｎより計算する（ステップ１７０４）。最後に、受信端末１５１からの制御情報の送信時間間隔Ｉｎｖｌの間に残留データ量がＢ_desに到達するよう次の伝送レートＲ_newを決定する（ステップ１７０５）。
【０１２３】
なお、ステップ１７０４において、目標データ量をＢ_baseとｎにより計算したが、パケットロス率Ｌｏｓｓにより、Ｂ_des＝Ｂ_base・（１−Ｌｏｓｓ）と計算することとしてもよい。
【０１２４】
〈実施の形態５〉
本実施の形態は、パケットロスが発生しているかいないかにより、伝送レートの決定方法を切り替える方式に関し、主として前述の課題４を解決するためのものである。
【０１２５】
本実施の形態における全体像を表す概略図は、図１と同等である。また、本実施の形態における送信端末の動作を示すフローチャートは図２と同等である。
【０１２６】
図１８は、本実施の形態において、伝送レートを決定するステップ（図２中のステップ２０５）の動作を表すフローチャートである。まず、パケットロスが発生しているかどうかを制御情報パケットのパケットロス率Ｌｏｓｓに基づいて判定する（ステップ１８００）。パケットロスが発生したと判定した場合には、パケットロス率Ｌｏｓｓと前回の伝送レートＲ’_sndとに基づき、次の伝送レートＲ_newを決定する（ステップ１８０１）。なお、ステップ１８０１に示す方法以外にも、前回の送信レートに基づいて、Ｒ_snd＝Ｒ’_snd・（定数）（ただし、定数は０以上１以下の実数である）としてもよいし、ＤＡＡ方式やＬＤＡ方式といった、パケットロスに基づいたレート制御方式を用いてもよい。パケットロスが発生していないときには、図３に示す方法を用いて伝送レートＲ_newを決定する（ステップ１８０２）。なお、ステップ１８０２は、図３に示す方法以外に、図１７に示す方法などを用いてもよい。
【０１２７】
ステップ１８００において、パケットロスが発生したかどうかによって伝送レート制御方式を切り替えるのではなく、現在使用している伝送路や配送方式に基づいて伝送レート制御方式を切り替えてもよい。すなわち、Ethernetやマルチキャストの場合には、ステップ１８０１を行い、１対１通信で、帯域ギャップの大きい伝送路を使用している場合にはステップ１８０２を行うこととしてもよい。
【０１２８】
〈実施の形態６〉
本実施の形態は、制御情報チャネルとデータチャネルとを用いて帯域推定を行う帯域推定方式に関し、主として前述の課題２を解決するためのものである。
【０１２９】
図１９は、本実施の形態における全体像を示す概略図である。送信端末１９００において、データ送信部１９０１は、キャプチャ、マイク、ファイルといった入力からデータを受け取り、必要なら符号化し、必要ならパケット化して受信端末１９１０にデータパケット送信する手段である。また、帯域推定制御部１９０３の指示により、データパケットを、パケットの送信間隔なしに連続して送信する手段でもある。データの送信用プロトコルとしては、ＲＴＰといったデータ送信用プロトコルを想定している。
【０１３０】
制御情報送受信部１９０２は、送信端末１９００から送信するデータパケットに関する制御情報を受信端末１９１０と送受信する手段である。送信端末１９００から受信端末１９１０に送信する制御情報としては、どのデータパケットを帯域推定用として送信したかを示す情報があり、受信端末１９１０から送信端末１９００への情報としては、帯域推定の結果がある。制御情報送信用のプロトコルとしては、ＴＣＰを用いてもよいし、ＲＴＣＰといったデータ伝送制御プロトコルを拡張してもよい。
【０１３１】
帯域推定制御部１９０３は、帯域推定用のパケットとして、データ送信部１９０１に、データパケットをパケットの送信間隔なしに連続して送信するよう指示する手段である。また、帯域推定用に送信されるパケット（例えば、データパケットをＲＴＰを用いて送信している場合には、送信間隔なしに送信されたパケットの先頭と末尾のシーケンス番号）を制御情報送受信部１９０２に通知する手段でもある。
【０１３２】
端末制御部１９０４は、送信端末１９００の各部を制御する手段である。
【０１３３】
受信端末１９１０において、データ受信部１９１１は、送信端末１９００からの送信データパケットを受信し、必要ならパケットをほどき、必要なら復号化し、モニタ、スピーカ、ファイルといった出力にデータを渡す手段である。
【０１３４】
制御情報送受信部１９１２は、送信データパケットに関する制御情報を送信端末１９００と送受信する手段である。
【０１３５】
帯域推定部１９１３は、制御情報送受信部１９１２において受信される帯域推定用パケットを示す情報に基づき、帯域推定用パケットの到着間隔を測定する手段である。この到着間隔に基づき、伝送帯域を推定し、その結果を制御情報送受信部１９１２に通知する手段でもある。
【０１３６】
端末制御部１９１４は、受信端末１９１０の各部を制御する手段である。
【０１３７】
図２０は、帯域推定を行う際に、制御情報送信用プロトコルとしてＴＣＰを、データパケット送信用のプロトコルとしてＲＴＰをそれぞれ用いた場合の送信端末１９００と受信端末１９１０との間のシーケンス図である。
【０１３８】
送信端末１９００は、まず、どのデータパケットが帯域推定用のパケットであるかを通知する制御情報パケットを送信する（ＴＣＰパケット２０００）。同図では、Ｓｅｑ１からＳｅｑ２までの間のデータパケットを用いることとしている。続いて、帯域推定用パケットとしてデータパケットを所定の時間間隔で連続して送信する（ＲＴＰパケット２００１）。所定の時間間隔は、なるべく伝送路上で帯域推定用パケット間に他のパケットが挿入されない程度の短い間隔（当然、０秒を含む）とする。受信端末１９１０は、送信端末１９００から通知された帯域推定用パケットの到着間隔ｄｅｌｔａを測定し、これに基づいてボトルネックリンクの帯域Ｒ_b＝Ｐ／（ｄｅｌｔａの平均値）を推定する（ここで、Ｐはデータパケットのパケットサイズである）。受信端末１９１０は、測定結果を制御情報パケットを用いて送信する（ＴＣＰパケット２００２）。
【０１３９】
〈実施の形態７〉
本実施の形態は、データパケットに帯域推定フラグを持つ帯域推定方式に関し、主として前述の課題２を解決するためのものである。
【０１４０】
図２１は、本実施の形態における全体像を表す概略図である。送信端末２１００において、データ送信部２１０１は、キャプチャ、マイク、ファイルといった入力からデータを受け取り、必要なら符号化し、必要ならパケット化して受信端末２１１０にデータパケット送信する手段である。また、帯域推定制御部２１０３の指示により、データパケットを、パケットの送信間隔なしに連続して送信する手段でもある。また、帯域推定用パケットとして送信されたデータパケットに、帯域推定用パケットであることを示す帯域推定フラグを立てる手段でもある。データの送信用プロトコルとしては、ＲＴＰといったデータ送信用プロトコルを想定している。帯域推定フラグは、ＲＴＰのマーカービットフィールド、エクステンションビットフィールドといった、データパケットヘッダの既存のフィールドを利用してもよいし、ＲＴＰパケットを拡張して新たなフィールドを定義してもよいし、ペイロードに入力してもよい。なお、帯域推定フラグは、帯域推定用パケットとして送信されるパケット全てのフラグを立てることとしてもよいし、帯域推定用パケットとして送信される先頭のパケットと末尾のパケットにのみ立てることとしてもよい。
【０１４１】
推定結果受信部２１０２は、受信端末２１１０からの帯域推定の結果を受信する手段である。推定結果送受信用のプロトコルとしては、ＲＴＣＰといったデータ伝送制御プロトコルを想定している。
【０１４２】
帯域推定制御部２１０３は、データ送信部２１０１に、帯域推定用パケットとして、データパケットをパケットの間隔なしに連続して送信するよう指示する手段である。
【０１４３】
端末制御部２１０４は、送信端末２１００の各部を制御する手段である。
【０１４４】
受信端末２１１０において、データ受信部２１１１は、送信端末２１００からの送信データパケットを受信し、必要ならパケットをほどき、必要なら復号化し、モニタ、スピーカ、ファイルといった出力にデータを渡す手段である。
【０１４５】
推定結果送信部２１１２は、帯域推定部２１１３において推定されたボトルネックリンクの帯域を、送信端末２１００に送信する手段である。推定結果送受信用のプロトコルとしては、ＲＴＣＰといったデータ伝送制御プロトコルを想定している。
【０１４６】
帯域推定部２１１３は、データパケットの帯域推定フラグをチェックする手段である。また、帯域推定フラグが立っている場合には、データパケットの到着間隔ｄｅｌｔａを測定し、この結果に基づいてボトルネックリンクの帯域Ｒ_b＝Ｐ／（ｄｅｌｔａの平均値）（Ｐはデータパケットのパケットサイズ）を推定し、その結果を推定結果送信部２１１２に通知する手段でもある。この際、ＲＴＰパケットのシーケンス番号Ｓｅｑの跳びによりパケットロスを検知した場合には、シーケンス番号Ｓｅｑ−１とＳｅｑ＋１との到着間隔ｄｅｌｔａを測定結果に含めないこととする。これは、パケットロスによる推定の誤差をなくすためである。
【０１４７】
端末制御部２１１４は、受信端末２１１０の各部を制御する手段である。
【０１４８】
図２２は、帯域推定を行う際に、データパケット送信にＲＴＰを、推定結果の送信にＲＴＣＰをそれぞれ用いた場合の、送信端末２１００と受信端末２１１０との間のシーケンス図である。まず、送信端末２１００は、帯域推定用のパケットとして、送信間隔なしにデータパケットを送信する（ＲＴＰパケット２２００）。このとき、データパケットにはそのパケットが帯域推定用であることを示す帯域推定フラグが立てられている。受信端末２１１０は、データパケットを受信し、データパケットの帯域推定フラグをチェックする。帯域推定フラグが立っている場合には、パケットの到着間隔を測定し、この結果に基づいてボトルネックリンクの帯域を推定する。受信端末２１１０は、推定結果を送信端末２１００に送信する（ＲＴＣＰパケット２２０１）。
【０１４９】
なお、本実施の形態において、データパケットを送信する前に予めボトルネックリンクの帯域Ｒ_bを推定したい場合や、帯域推定パケットとしてデータパケットを用いたくない場合には、データをペイロードに含んでいないデータパケットを帯域測定用パケットとして送信し、受信端末２１１０において帯域推定用パケットの到着間隔のみ測定し、パケットを破棄することとしてもよい。
【０１５０】
また、本実施の形態において、帯域推定フラグではなく、帯域推定用パケットを送信した数を表す帯域推定シーケンス番号を用いてもよい。この際、帯域推定シーケンス番号が０である場合には、到着間隔の測定を行わず、０以外になった場合に到着間隔を測定することとする。また、帯域推定シーケンス番号が跳んだことでパケットロスを検出し、ロスしたパケットの前後のパケットを用いて到着間隔を測定しないことで、パケットロスによる推定の誤差をなくすことができる。
【０１５１】
〈実施の形態８〉
本実施の形態は、終了条件付き帯域推定方式に関し、主として前述の課題１を解決するためのものである。
【０１５２】
図２３は、本実施の形態における全体像を示す概略図である。同図において、送信端末２３０１は、受信端末２３０２までの経路上に存在する各中間ノード２３０３，２３０４に対して、帯域推定用のパケットを送信する。帯域推定用のパケットは、経路上の各中間ノード２３０３，２３０４との間のＲＴＴを計測するパケットである。例えば、ＩＰネットワークであれば、ＴＴＬフィールドをｎにしたＩＰパケットを送出することにより、経路上のｎ番目の中間ノードにＩＣＭＰパケットのTTL Expiredメッセージを送信させることで、各中間ノードとのＲＴＴを計測することができる。
【０１５３】
受信端末２３０２は、送信端末２３０１から送信された帯域推定用のパケットに対し、応答を送信する。例えば、ＩＰネットワークであれば、送信端末２３０１からのＰＩＮＧパケットに対し、応答ＰＩＮＧパケットを送信する。受信端末２３０２は、送信端末２３０１が帯域を計測する経路の終端である。
【０１５４】
中間ノード２３０３，２３０４は、送信端末２３０１から送信された帯域推定用のパケットに対し、応答を送信する。例えば、ＩＰネットワークであれば、ＴＴＬフィールドをｎにしたＩＰパケットを送信端末２３０１が送信した場合には、経路上のｎ番目のノードがＩＣＭＰパケットのTTL Expiredメッセージを送信端末２３０１に送信する。
【０１５５】
リンク２３０５，２３０６，２３０７は、送信端末２３０１、受信端末２３０２、各中間ノード２３０３，２３０４を接続するEthernet、ＳＬＩＰ（Serial Line Internet Protocol）といったネットワークである。本実施の形態では、このリンクの帯域を推定する。
【０１５６】
図２４は、送信端末２３０１が帯域推定を行う際の動作を示すフローチャートである。送信端末２３０１は、当該送信端末２３０１に近い順にリンクの帯域の推定を行っていく。全リンクの測定時間Ｔ_pを指定し、送信端末２３０１から受信端末２３０２までの間にＮ個のリンクが存在するものとし、送信端末２３０１からｋ番目のリンクの帯域を以下のとおり推定する。
【０１５７】
まず、３２バイトから１４７２バイトまで３２バイト間隔４６種類のサイズのパケットを中間ノード２３０３に送信する（ステップ２４００）。続いて、パケットサイズをｓ、最小ＲＴＴをｔとし、
ｔ＝α（ｋ）＋β（ｋ）ｓ
となるα（ｋ）およびβ（ｋ）を、最小２乗法を用いて求める（ステップ２４０１）。なお、より少ない計測点数でより精度の高い結果を得るために、Ｍ推定、重み付き最小２乗法といった、他の統計処理を用いてもよい。
【０１５８】
α（ｋ）、β（ｋ）の計算結果を、前回の試行の結果で得られたα’（ｋ）、β’（ｋ）と比較し、変化が閾値の範囲内であれば、結果が収束したものと判定する。ただし、ｋ番目のノードの推定終了時刻Ｔを過ぎた場合には、結果が収束したものと判定する。なお、ｋ番目のノードの推定終了時刻は、（推定開始時刻）＋ｋ・Ｔ_p／Ｎであるものとする（ステップ２４０２）。
【０１５９】
収束していないと判定された場合には、もう一度ステップ２４００、２４０１を繰り返す。なお、収束判定の際に、前回の試行の結果だけでなく、過去複数回の試行の結果と比較して変化が閾値の範囲内であるかどうかを判定してもよい。
【０１６０】
ステップ２４０２において、α（ｋ）、β（ｋ）が収束したと判定された場合には、β（ｋ）とβ（ｋ−１）とを比較する。β（ｋ−１）よりもβ（ｋ）が小さい場合は、推定帯域がマイナスとなるため、β（ｋ−１）、β（ｋ）のどちらかに誤りがあることになる。この誤りを正すために、測定時間が残っている場合には、前のホップに戻って測定をやり直す（ステップ２４０３）。
【０１６１】
β（ｋ）がβ（ｋ−１）よりも大きい場合もしくは測定時刻を過ぎた場合には、正しく測定されたと判定し、リンクの帯域を求める（ステップ２４０４）。続いて、次のホップがあるなら次のホップの帯域推定に移り、最終ホップへ到達した場合には、処理を終了する（ステップ２４０５）。
【０１６２】
〈実施の形態９〉
本実施の形態は、中間ノード（例えばルータやゲートウェイ）で最低限の帯域を確保して、伝送品質を確保する方式に関し、主として前述の課題６を解決するためのものである。
【０１６３】
図２５は、本実施の形態における全体像を表す概略図である。送信端末２５０は、図１に示す送信端末１０に、帯域予約部２５０１を追加したものである。送信端末２５０と受信端末２５１との間に介在した中間ノード２５２は、図１に示す中間ノード１２に、帯域制御部２５０２を追加したものである。
【０１６４】
帯域予約部２５０１は、送信端末２５０が送信可能な最低伝送レートと、最大伝送レートとを中間ノード２５２に通知する手段である。また、通知した伝送レートで帯域が確保できたかどうかの結果を受信する手段でもある。
【０１６５】
帯域制御部２５０２は、送信端末２５０から通知された最低伝送レートで伝送帯域を予約する手段である。また、伝送帯域の予約が不可能である場合には、伝送帯域を確保できないことを送信端末２５０に通知する手段でもある。
【０１６６】
図２６は、本実施の形態の動作を表すシーケンス図である。データの送信前に、送信端末２５０は、当該送信端末２５０が送信可能な最小伝送レートと最大伝送レートとを中間ノード２５２に通知する（ステップ２６０１）。中間ノード２５２は、通知された伝送レートで伝送帯域を予約し、予約ができたことを送信端末２５０に通知する（ステップ２６０２）。送信端末２５０は、伝送帯域が予約できたことを確認し、データの送信を開始する。この際、送信端末２５０は、制御情報パケットや、中間ノード２５２との間のＲＴＴなどから、上記実施の形態１または２で説明した方法で伝送レートを決定し、決定された伝送レートでデータを送信する。輻輳が極端に悪化し、伝送レートを最低値まで下げた場合には、中間ノード２５２で伝送帯域が予約されているため、最低限の伝送品質を確保することができ（つまり、帯域予約により、パケットロスが発生しない）、乱れのない映像や途切れの少ない音声伝送を実現することが可能となる（ステップ２６０３）。
【０１６７】
なお、本実施の形態では、送信端末２５０が必要な伝送帯域を通知して伝送帯域の予約を行ったが、送信端末２５０からの伝送帯域の通知を行わずに本発明を実施することも可能である。例えば、送信端末２５０の最低伝送レートが決定しているものとして、管理者が中間ノード２５２で予め予約する帯域を設定することとしても、本発明の実施は可能である。また、中間ノード２５２におけるデータの送信に使用可能な伝送帯域を予約し、予約された帯域を送信端末２５０に通知し、送信端末２５０が、伝送レートの決定をその予約された伝送帯域に基づいて行っても本発明の実施は可能である。ここで、中間ノード２５２におけるデータの送信に使用可能な伝送帯域は、当該中間ノード２５２において送信されるデータの種類に基づいていてもよい。
【０１６８】
さらに、受信端末２５１が、送信端末２５０に要求する最低伝送レートを中間ノード２５２に通知し、中間ノード２５２が予約を行うことも可能である。このような予約方法は、受信端末２５１が要求する最低の映像品質を伝送に反映するのに有効である。
【０１６９】
また、受信端末２５１は、データを再生する前にネットワークの揺らぎを吸収するためにデータを数秒間バッファリングするが、この受信端末２５１は（バッファリング時間）×（最低伝送レート）のバッファを最低限保持することで、乱れのない映像や途切れの少ない音声伝送を実現することができる。
【０１７０】
〈実施の形態１０〉
本実施の形態は、制御パケットを優先して送信することで、映像品質を確保する方式に関し、主として前述の課題７を解決するためのものである。
【０１７１】
図２７は、本実施の形態における全体像を示す概略図である。送信端末２７１において、データ送信部２７０１およびデータ送信制御応答部２７０２は、図６に示すデータ送信部６０１およびデータ送信制御応答部６０２とそれぞれ同等である。また、受信端末２７２において、データ受信部２７０６およびデータ送信制御要求部２７０８は、図６に示すデータ受信部６０５およびデータ送信制御要求部６０６とそれぞれ同等である。
【０１７２】
図２７中の優先度付加部２７０３，２７０７は、ネットワークに送信するパケットのうち、制御用のパケットに高い優先度を、データパケットに低い優先度を付加する手段である。優先度付加の方法としては、ＩＰパケットのＴＯＳフィールドに、優先度情報を入力するといった方法が挙げられる。
【０１７３】
中間ノード２７３に配置された優先度処理部２７０５は、高い優先度を付加したパケットを優先的に処理する手段である。この優先度処理部２７０５により、高い優先度を付加されたパケットは廃棄される確率が低くなり、低遅延で受信端末２７２に伝送されるようになる。優先度処理の方法として、DiffServを用いてもよい。
【０１７４】
上記の構成により、輻輳が発生している場合でも、制御用のパケットを低遅延かつロスすることなく送信することが可能となり、データパケットの送信の停止、開始を低遅延かつ確実に行うことができるようになる。
【０１７５】
なお、上記の構成をＴＣＰに適用することにより、ＴＣＰのセッションの確立、開放を低遅延かつ確実に行うことが可能となる。例えば、制御パケット（ＳＹＮ、ＦＩＮパケット）に対して、廃棄確率が低くなるように優先度を設定することで、ＴＣＰのセッションの確立、開放を低遅延かつ確実に行うことが可能となる。
【０１７６】
もちろん、このような手法は、端末とサーバとの間の１対１通信だけではなく、複数の端末に放送する１対Ｎ通信（マルチキャスト）に対しても適用可能である。
【０１７７】
以上、本発明に係る実施の形態１〜１０を説明したが、本発明のデータ送受信方法を実現するための送信装置、受信装置、およびこれらを備えた送受信システムも本発明に含まれることは、言うまでもない。
【０１７８】
本発明は、上述した本発明の送信装置、受信装置、送受信システムの全部または一部の手段（または、装置、素子、回路、部など）の機能をコンピュータにより実行させるためのプログラムであって、コンピュータと協働して動作するプログラムをも含む。なお、本発明のコンピュータは、ＣＰＵ（Central Processing Unit）などの純然たるハードウェアに限らず、ファームウェアやＯＳ（Operating System）、さらに周辺機器を含むものであってもよい。
【０１７９】
本発明は、上述した本発明のデータ送受信方法の全部または一部のステップ（または、工程、動作、作用など）の動作をコンピュータにより実行させるためのプログラムであって、コンピュータと協働して動作するプログラムをも含む。
【０１８０】
また、本発明のプログラムを記録した、コンピュータに読み取り可能な記録媒体も本発明に含まれる。また、本発明のプログラムの一利用形態は、コンピュータにより読み取り可能な記録媒体に記録され、コンピュータと協働して動作する態様であってもよい。また、本発明のプログラムの一利用形態は、伝送媒体中を伝送し、コンピュータにより読み取られ、コンピュータと協働して動作する態様であってもよい。また、記録媒体としては、ＲＯＭ（Read Only Memory）等が含まれ、伝送媒体としては、インターネット等の伝送媒体、光・電波・音波等が含まれる。
【０１８１】
また、本発明の構成は、ソフトウェア的に実現してもよいし、ハードウェア的に実現してもよい。
【０１８２】
［産業上の利用の可能性］
本発明によれば、インターネットのような、様々な接続形態が存在し、しかも伝送帯域が変動する伝送路において、安定した伝送品質で、効率良くデータ伝送を行うことができる。特に、従来安定した伝送品質でデータ伝送を行うことが困難であった有線網、無線網の混在する接続形態においても、本発明を適用することにより、インターネットＴＶ電話、ビデオ・オン・デマンド、放送（マルチキャスト）、ビデオ掲示板などの幅広いアプリケーションにおいて、安定した伝送品質で、効率良くデータ伝送を行うことが可能となる。
【図面の簡単な説明】
【図１】本発明の実施の形態１における全体像を示す概略図である。
【図２】本発明の実施の形態１における送信端末の動作を表すフローチャートである。
【図３】本発明の実施の形態１における伝送レート制御のフローチャートである。
【図４】本発明の実施の形態２における有線網と無線網とが混在する接続形態を表す図である。
【図５】本発明の実施の形態２における有線網と無線網とが混在する他の接続形態を表す図である。
【図６】本発明の実施の形態２における全体像を示す概略図である。
【図７】本発明の実施の形態２における送信端末と受信端末との間のシーケンス図である。
【図８】本発明の実施の形態２における伝送レートに関する情報の記述を示す図である。
【図９】本発明の実施の形態２における伝送レート制御のフローチャートである。
【図１０】本発明の実施の形態３におけるマルチキャストでの接続形態を表す図である。
【図１１】本発明の実施の形態３におけるマルチキャストでの他の接続形態を表す図である。
【図１２】本発明の実施の形態３における全体像を示す概略図である。
【図１３】本発明の実施の形態３における送信端末と複数の受信端末との間のシーケンス図である。
【図１４】本発明の実施の形態３における複数の受信端末のグループ分割のためのフローチャートである。
【図１５】本発明の実施の形態４における全体像を示す概略図である。
【図１６】本発明の実施の形態４における送信端末の動作を表すフローチャートである。
【図１７】本発明の実施の形態４における伝送レート制御のフローチャートである。
【図１８】本発明の実施の形態５における伝送レート制御のフローチャートである。
【図１９】本発明の実施の形態６における全体像を示す概略図である。
【図２０】本発明の実施の形態６における送信端末と受信端末との間のシーケンス図である。
【図２１】本発明の実施の形態７における全体像を示す概略図である。
【図２２】本発明の実施の形態７における送信端末と受信端末との間のシーケンス図である。
【図２３】本発明の実施の形態８における全体像を示す概略図である。
【図２４】本発明の実施の形態８における送信端末の動作を表すフローチャートである。
【図２５】本発明の実施の形態９における全体像を示す概略図である。
【図２６】本発明の実施の形態９における送信端末と受信端末との間のシーケンス図である。
【図２７】本発明の実施の形態１０における全体像を示す概略図である。

Claims (5)

1. 送信端末と受信端末との間の伝送路上に設けられた中間ノードのうちの全部または一部の中間ノードにおけるデータの受信および／または送信の状態に基づいて、前記送信端末からの伝送レートを決定するデータ送受信方法であって、
   前記全部または一部の中間ノードと前記送信端末との間の往復伝播遅延時間、往復伝播遅延時間の揺らぎ、中間ノードでのパケットロス、中間ノードのリンクの帯域、過去の伝送レートの少なくとも１つに基づいて、前記送信端末からの伝送レートを決定することとし、
   前記往復伝播遅延時間、前記往復伝播遅延時間の揺らぎ、前記中間ノードでのパケットロスのうち少なくとも１つ以上の情報を前記送信端末が取得する際に、前記情報の取得が可能な送信端末を前記中間ノードで制限することを特徴とするデータ送受信方法。
2. 請求項１記載のデータ送受信方法を実現するための受信装置。
3. 送信端末と受信端末との間の伝送路上に設けられた中間ノードのうちの全部または一部の中間ノードにおけるデータの受信および／または送信の状態に基づいて、前記送信端末からの伝送レートを決定するデータ送信装置であって、
   前記全部または一部の中間ノードと前記送信端末との間の往復伝播遅延時間、往復伝播遅延時間の揺らぎ、中間ノードでのパケットロス、中間ノードのリンクの帯域、過去の伝送レートの少なくとも１つに基づいて、前記送信端末からの伝送レートを決定する伝送レート決定手段と、
   前記往復伝播遅延時間、前記往復伝播遅延時間の揺らぎ、前記中間ノードでのパケットロスのうち少なくとも１つ以上の情報を前記送信端末が取得する際に、前記情報の取得が可能な送信端末を前記中間ノードで制限する端末制御手段とを備えることを特徴とするデータ送信装置。
4. 送信端末と受信端末との間の伝送路上に設けられた中間ノードのうちの全部または一部の中間ノードにおけるデータの受信および／または送信の状態に基づいて、前記送信端末からの伝送レートを決定するように構成されたデータ送受信システムであって、
   前記全部または一部の中間ノードと前記送信端末との間の往復伝播遅延時間、往復伝播遅延時間の揺らぎ、中間ノードでのパケットロス、中間ノードのリンクの帯域、過去の伝送レートの少なくとも１つに基づいて、前記送信端末からの伝送レートを決定することとし、
   前記往復伝播遅延時間、前記往復伝播遅延時間の揺らぎ、前記中間ノードでのパケットロスのうち少なくとも１つ以上の情報を前記送信端末が取得する際に、前記情報の取得が可能な送信端末を前記中間ノードで制限することを特徴とするデータ送受信システム。
5. 送信端末と受信端末との間の伝送路上に設けられた中間ノードのうちの全部または一部の中間ノードにおけるデータの受信および／または送信の状態に基づいて、前記送信端末からの伝送レートを決定するデータ送受信方法をコンピュータにより実行させるためのプログラムであって、
   前記全部または一部の中間ノードと前記送信端末との間の往復伝播遅延時間、往復伝播遅延時間の揺らぎ、中間ノードでのパケットロス、中間ノードのリンクの帯域、過去の伝送レートの少なくとも１つに基づいて、前記送信端末からの伝送レートを決定することとし、
   前記往復伝播遅延時間、前記往復伝播遅延時間の揺らぎ、前記中間ノードでのパケットロスのうち少なくとも１つ以上の情報を前記送信端末が取得する際に、前記情報の取得が可能な送信端末を前記中間ノードで制限することを特徴とするプログラム。

Images