(57)【特許請求の範囲】
【請求項１】
ＴＦＲＣを用いたレート制御を行うストリーミングの受信端末を第一の受信端末から第二の受信端末へ変更する通信方法において、
前記ストリーミングの送信端末と前記第一の受信端末との間のネットワーク上の経路と、前記送信端末と前記第二の受信端末との間の前記ネットワーク上の経路とが同一であることを判定する判定ステップと、
経路が同一であると判断した場合に、前記第一の受信端末が管理しているパケット損失の履歴情報を前記第二の受信端末に伝達する伝達ステップと、
を有する通信方法。
【請求項２】
ＴＦＲＣを用いたレート制御を行いながらマルチキャストにより配送されるストリーミングの受信端末として、第一の受信端末に加えて第二の受信端末を追加する通信方法において、
前記ストリーミングの送信端末と前記第一の受信端末との間のネットワーク上の経路と、前記送信端末と前記第二の受信端末との間の前記ネットワーク上の経路とが同一であることを判定する判定ステップと、
経路が同一であると判断した場合に、前記第一の受信端末が管理しているパケット損失の履歴情報を前記第二の受信端末に伝達する伝達ステップと、
を有する通信方法。
【請求項３】
経路が同一であると判断した場合に、前記送信端末および前記第二の受信端末に対して、前記パケット損失の履歴情報が前記第一の受信端末から前記第二の受信端末に伝達されたことを通知し、経路が同一でないと判断した場合に、前記送信端末および前記第二の受信端末に対して、前記第一の受信端末から前記第二の受信端末に前記パケット損失の履歴情報が伝達されずに受信端末の変更のみが実施されることを通知する通知ステップと、
を有する請求項１または２記載の通信方法。
【請求項４】
前記判定ステップは、トレースルートにより経路を測定する請求項１ないし３のいずれか一項記載の通信方法。
【請求項５】
前記判定ステップは、前記第一の受信端末と前記第二の受信端末とが同一のネットワークに接続されることを判定し、前記送信端末から前記同一のネットワーク上にルータが一台のみ接続されていることを判定する請求項１ないし３のいずれか一項記載の通信方法。
【請求項６】
ＴＦＲＣを用いたレート制御を行うストリーミングの受信端末であって、
前記ストリーミングの送信端末と自端末との間のネットワーク上の経路と、前記送信端末と他の受信端末との間のネットワーク上の経路とが、同一であることを判定する判定機能と、
経路が同一であると判断した場合に、自端末が管理しているパケット損失の履歴情報を前記他の受信端末に伝達する伝達機能と、
を有する受信端末。
【請求項７】
ＴＦＲＣを用いたレート制御を行いながらマルチキャストにより配送されるストリーミングの受信端末であって、
前記ストリーミングの送信端末と自端末との間のネットワーク上の経路と、前記送信端末と前記ストリーミングを受信する端末として新たに追加する受信端末との間のネットワーク上の経路とが、同一であることを判定する判定機能と、
経路が同一であると判断した場合に、自端末が管理しているパケット損失の履歴情報を前記新たに追加する受信端末に伝達する伝達機能と、
を有する受信端末。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＴＦＲＣ（ＴＣＰ  Ｆｒｉｅｎｄｌｙ  Ｒａｔｅ  Ｃｏｎｔｒｏｌ）を用いたレート制御を行うストリーミングの受信端末を第一の受信端末から第二の受信端末へ変更する通信方法および受信端末に関するものである。
【背景技術】
【０００２】
（インターネットの定義）
ここでは、各端末の近接ルータの間を接続するネットワークをインターネットと定義して説明する。具体的には、ある宅内の端末から別の宅内の端末にデータを送信する場合、送信するデータは、宅内ルータからＡＤＳＬや光回線などのアクセス回線、複数のＩＳＰ（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）の回線などを通じて伝送される。さらに、送信するデータは、別の宅内に向けたアクセス回線、宅内ルータを経由して別の宅内の端末に届けられる。この宅内ルータから別の宅内ルータまでのネットワークをインターネットと呼ぶ。
【０００３】
上記のインターネットに接続された任意の端末間で、固定的な帯域を確保することは困難である。従来、インターネットのルータ間で帯域を予約する方式として、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ  ＲｅＳｅｒＶａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用いて各端末間の通信毎に帯域を確保するＩＮＴＳＥＲＶ（Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅｓ）が知られている。しかし、インターネット上の複数のＩＳＰが運営するすべてのルータに同じ方式を適用しなければならないため、実用化には至っていない。このため、インターネットでは、あらゆる端末間の通信が帯域を共有しながら通信する、いわゆるベストエフォートで通信が行われている。
【０００４】
ベストエフォートなインターネットで各端末間の通信が公平に帯域を共有するための通信方式として、ＴＣＰが広く用いられている。このＴＣＰは、電子メールやＷＷＷ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）やＷｉｎｎｙやＷｉｎＭＸなどＰ２Ｐ（ｐｅｅｒ  ｔｏ  ｐｅｅｒ）ファイル交換通信などで用いられ、インターネットトラフィックの大半を占めている。このため、ベストエフォートのインターネット上の通信においては、このＴＣＰと公平に帯域を分け合うように送信レートを制御し、輻輳制御を実現することが推奨されている（参考文献：，“  Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｉｎｃｉｐｌｅｓ”，ＲＦＣ  ２９１４）。
【０００５】
一方、ＴＣＰは、送信レート制御においてＡＩＭＤ（Ａｄｄｉｔｉｖｅ  Ｉｎｃｒｅａｓｅ  Ｍｕｌｔｉｐｌｅ  Ｄｅｃｒｅａｓｅ）と呼ばれる特性を示す。この特性によって送信レートは劇的に変化するため、音声や動画などの連続情報をネットワークを介して伝送するストリーミングには向かない。
【０００６】
この問題を解決するために、滑らかな送信レート制御を行いながら、ＴＣＰと公平に帯域を共有するＴＦＲＣが開発されている。
【０００７】
ＴＦＲＣとは、後述する損失イベント率（ｐ）と往復時間（Ｒ）によってＴＣＰと公平に帯域を共有できる送信レート（Ｘ）を推定し、送信レートを制御する方式である。具体的には、次に示す式１で送信レート（Ｘ）を推定する。
【数１】
0004567007.tif 000002
【０００８】
ＴＦＲＣを用いた送信レート制御では、この式１を用いた送信レートの推定を損失発生の度に行う（図１参照）。
【０００９】
このＴＦＲＣの送信レート制御において滑らかな送信レートの制御を実現するために、損失イベント率（ｐ）は、過去数回（図１では８回）の損失情報を加味して計算される。
【００１０】
ＴＦＲＣでは、このように制御することにより、インターネットが過度な輻輳状態になった場合の高速な輻輳回避と、滑らかなレート制御を両立させている。つまり、インターネット上で輻輳状態が発生した場合、多くの損失イベントが短い時間に発生する。これにより、受信端末で観測される損失イベント率は即座に大きい値となる。この値が損失の度に送信者に報告されることで、式１により直ちに送信レートが算出適用され、流量が抑えられる。この結果、インターネットの輻輳回避として作用する。逆に、インターネット上で過度な輻輳状態が発生しておらず、あまり損失が発生しない場合は、損失の発生頻度が下がり、受信側で観測する損失イベント率も徐々に下がっていく。上述のように損失イベント率は、損失の履歴を加味して計算されるため、時間的に見れば滑らかに損失イベント率は減少し、それにしたがって送信レートも滑らかに増加していく。つまり、インターネット上で輻輳が発生した場合は、高速な輻輳回避動作がとられ、輻輳状態から回復する場合には、滑らかに送信レートが変動（増加）する。
【００１１】
また、ＴＦＲＣでは、送信開始時に、ＴＣＰと同様に、送信レート＝１パケット／往復時間から徐々に送信レートを上げる動作が行われる（スロースタートと呼ぶ）。しかし、ＴＦＲＣは、ＴＣＰと比較して滑らかに送信レートが変動するため、ストリーミングを行うために必要なレートに達するまで多くの時間が必要となる。また、連続的にデータを受信しながら再生するストリーミングでは、再生する速度以上の送信レートが確保できないと受信側で再生できない。したがって、受信端末にとっては、ストリーミングの受信を開始してから、実際に映像等を再生開始するまでに多くの時間が必要となっている。
【００１２】
このため、利用者が受信端末を特定の端末から新たな端末に切り替えた場合、多くの待ち時間が必要となる。
【００１３】
一方、新たな受信端末にストリーミングを送信する場合、その受信端末に対してどの程度の送信レートで送信が可能かを他の端末が知らせる方式が提案されている（例えば特許文献１参照）。
【００１４】
この方式では、新たな端末がインターネットに接続し、インターネット上の特定のサーバ（例：インスタントメッセージの交換を行うサーバ）にログインする際に、インターネット上の帯域計測サーバを用いて新たな端末と帯域計測サーバとの間の実効帯域を計測する。次に、計測した実効帯域の情報を上記特定のサーバを経由して別の端末に通知する。そして、この情報を用いて上記の新たな端末と別の端末との間で通信を行う。
【００１５】
この方式を用いれば、新たな端末の実効帯域に近い値を用いて、新たな端末と別の端末間で行うストリーミングにとって妥当な送信レートを大まかに決定することができる。具体的には、新たな端末と帯域計測サーバとの間の実効帯域が１．５Ｍｂｐｓであれば、最大送信レートが６Ｍｂｐｓといった高精細な動画の送信をあきらめる。そして、その代わりに１Ｍｂｐｓ程度の低精細な動画送信を行うといったことが可能となる。
【００１６】
【特許文献１】特開２００４−１２９２０５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１７】
上記のような従来の方式では、端末と計測サーバとの間の帯域を測定しているため、計測した値は、インターネットに接続するアクセス回線の実効速度の上限を大まかに把握するためには有効と考えられる。しかしながら、この値は、ストリーミングを行う送信端末と受信端末の間の帯域を測定した値ではないので、実際にストリーミングを行う送信レート（ＴＦＲＣの初期速度）として適用できない。具体的には、一つの宅内ルータに接続された第一の受信端末（例：キッチンに設置されたディスプレイ装置）で受信していたストリーミングを、同じ宅内ルータに接続された第二の受信端末（例：居間に設置されたディスプレイ装置）に切り替えた場合、第一の受信端末がそれまでに受信していた送信レートを直ちに第二の受信端末に適用できない。つまり、第二の受信端末と送信端末との間の帯域が測定されているわけではないので、ＴＦＲＣを用いたストリーミングにおいては、送信端末はスロースタートせざるを得ず、送信レートが低い状態から送信を開始し、送信レートを増速させることになる。したがって、第二の受信端末で動画等のストリーミングを再生できるまでの切り替え後の待ち時間は長くなる。
【００１８】
本発明は、上記のような問題に鑑みてなされたものであり、ＴＦＲＣアルゴリズムを用いた送信レート制御を適用したストリーミングを受信する端末を第一の受信端末から第二の受信端末へ切り替える際に、切り替えた後、直ちに途切れずにストリーミングを受信、再生することができる通信方法および受信端末を提供するものである。
【課題を解決するための手段】
【００１９】
本発明の通信方法は、ＴＦＲＣを用いたレート制御を行うストリーミングの受信端末を第一の受信端末から第二の受信端末へ変更する通信方法において、前記ストリーミングの送信端末と前記第一の受信端末との間のネットワーク上の経路と、前記送信端末と前記第二の受信端末との間の前記ネットワーク上の経路とが同一であることを判定する判定ステップと、経路が同一であると判断した場合に、前記第一の受信端末が管理しているパケット損失の履歴情報を前記第二の受信端末に伝達する伝達ステップと、を有する。
【００２０】
上記構成によれば、経路が同一であると判断した場合に、前記第一の受信端末が管理しているパケット損失の履歴情報を前記第二の受信端末に伝達することにより、第二の受信端末は、スロースタートを行うことなく、伝達された履歴情報を用いて、直ちに、第一の受信端末が使用していた送信レートと同一の送信レートでストリーミングを受信することができる為、受信端末を切り替えた直後から途切れずにストリーミングを受信および再生することができる。
【００２１】
また、上記構成によれば、ストリーミングの送信端末と前記第一の受信端末との間のネットワーク上の経路と、前記送信端末と前記第二の受信端末との間の前記ネットワーク上の経路とが、同一であることを判定することにより、ネットワーク上の経路が同一でない場合には第二の受信端末にパケット損失の履歴情報が伝達されない為、第二の受信端末が不適当に高い送信レートでストリーミングを受信してネットワークを輻輳状態にすることを防止できる。
【００２２】
また、本発明の通信方法は、ＴＦＲＣを用いたレート制御を行いながらマルチキャストにより配送されるストリーミングの受信端末として、第一の受信端末に加えて第二の受信端末を追加する通信方法において、前記ストリーミングの送信端末と前記第一の受信端末との間のネットワーク上の経路と、前記送信端末と前記第二の受信端末との間の前記ネットワーク上の経路とが同一であることを判定する判定ステップと、経路が同一であると判断した場合に、前記第一の受信端末が管理しているパケット損失の履歴情報を前記第二の受信端末に伝達する伝達ステップと、を有する。
【００２３】
上記構成によれば、経路が同一であると判断した場合に、前記第一の受信端末が管理しているパケット損失の履歴情報を前記第二の受信端末に伝達することにより、第二の受信端末は、スロースタートを行うことなく、伝達された履歴情報を用いて、直ちに、第一の受信端末が使用していた送信レートと同一の送信レートでストリーミングを受信することができる為、第一の受信端末に加えて第二の受信端末を追加した直後から途切れずにストリーミングを受信および再生することができる。
【００２４】
また、上記構成によれば、ストリーミングの送信端末と前記第一の受信端末との間のネットワーク上の経路と、前記送信端末と前記第二の受信端末との間の前記ネットワーク上の経路とが同一であることを判定することにより、ネットワーク上の経路が同一でない場合には第二の受信端末にパケット損失の履歴情報が伝達されない為、第二の受信端末が不適当に高い送信レートでストリーミングを受信してネットワークを輻輳状態にすることを防止できる。
【００２５】
また、本発明の通信方法は、経路が同一であると判断した場合に、前記送信端末および前記第二の受信端末に対して、前記パケット損失の履歴情報が前記第一の受信端末から前記第二の受信端末に伝達されたことを通知し、経路が同一でないと判断した場合に、前記送信端末および前記第二の受信端末に対して、前記第一の受信端末から前記第二の受信端末に前記パケット損失の履歴情報が伝達されずに受信端末の変更のみが実施されることを通知する通知ステップと、を有する。上記構成によれば、送信端末および第二の受信端末は、状況を把握することができる。
【００２６】
また、本発明の通信方法は、前記判定ステップが、トレースルートにより経路を測定するものである。
【００２７】
また、本発明の通信方法は、前記判定ステップが、前記第一の受信端末と前記第二の受信端末とが同一のネットワークに接続されることを判定し、前記送信端末から前記同一のネットワーク上にルータが一台のみ接続されていることを判定するものである。
【００２８】
また、本発明の受信端末は、ＴＦＲＣを用いたレート制御を行うストリーミングの受信端末であって、前記ストリーミングの送信端末と自端末との間のネットワーク上の経路と、前記送信端末と他の受信端末との間のネットワーク上の経路とが、同一であることを判定する判定機能と、経路が同一であると判断した場合に、自端末が管理しているパケット損失の履歴情報を前記他の受信端末に伝達する伝達機能と、を有する。
【００２９】
さらに、本発明の受信端末は、ＴＦＲＣを用いたレート制御を行いながらマルチキャストにより配送されるストリーミングの受信端末であって、前記ストリーミングの送信端末と自端末との間のネットワーク上の経路と、前記送信端末と前記ストリーミングを受信する端末として新たに追加する受信端末との間のネットワーク上の経路とが、同一であることを判定する判定機能と、経路が同一であると判断した場合に、自端末が管理しているパケット損失の履歴情報を前記新たに追加する受信端末に伝達する伝達機能と、を有する。
【発明の効果】
【００３０】
本発明によれば、ストリーミングを受信する端末を第一の受信端末から第二の受信端末に切り替える（または受信端末として第二の受信端末を追加する）際に、切り替えた（追加した）後、直ちに途切れずにストリーミングを受信、再生することができる。
【発明を実施するための最良の形態】
【００３１】
以下、本発明の実施の形態について図面を参照しながら説明する。
【００３２】
図１は、前述のＴＦＲＣを用いた送信レート制御の説明図である。この制御は、送信端末から受信端末にアプリケーションパケットが送信される際に、受信端末側で測定されたパケット損失の履歴情報と往復時間情報とを利用し、式１から帯域を推定して送信レート制御を行うものである。以下、このＴＦＲＣアルゴリズムを用いた送信レート制御を行う送信端末から送信されるストリーミングを受信する端末を変更、追加する場合の実施の形態を説明する。
【００３３】
（実施の形態１：呼制御サーバで集中制御）
図２は、本発明の実施の形態１を説明するための通信システムの構成を示すブロック図である。図２に示す通信システムは、送信端末１０１と、第一の受信端末２０１と、第二の受信端末３０１と、ルータ４０１と、呼制御サーバ６０１と、インターネット５０１と、ローカルネットワーク７０１とで構成される。また、送信端末１０１、呼制御サーバ６０１およびルータ４０１は、互いにインターネット５０１を介して接続され、ルータ４０１は、ローカルネットワーク７０１を介して第一の受信端末２０１および第二の受信端末３０１に接続される。
【００３４】
送信端末１０１は、ストリーミングを送信する端末であり、送信アプリケーション１０２、送信レート制御部１０３および呼転送制御部１０４を含む。送信アプリケーション１０２は、音声、動画等のストリーミング情報を送信するアプリケーションである。送信レート制御部１０３は、後述する受信端末から損失イベント率とＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）の往復時間情報を受信し、式１を用いて帯域を推定し、これに基づき送信アプリケーション１０２の送信レートを制御する。呼転送制御部１０４は、端末や呼制御サーバと呼制御のシグナリングを送受して、ストリーミングの送信開始や終了を制御する。
【００３５】
第一の受信端末２０１は、ストリーミングを受信する端末である。第一の受信端末２０１は、音声、動画等のストリーミングされてきた情報をスピーカやディスプレイ等で再生する受信アプリケーション２０２と、受信するパケットの損失状況を管理する損失情報管理部２０３と、送信端末１０１から送信されるストリーミングのパケットのパケット通番を監視することで損失検出を行い、損失履歴管理部２０３で管理されている損失履歴情報とあわせて損失イベント率を算出し、送信端末１０１に損失イベント率として報告する損失率報告部２０４と、送信端末１０１と自端末とのインターネット上の経路と、送信端末１０１と他の受信端末とのインターネット上の経路とが同一であることを判定するために必要な情報を測定、報告する経路情報報告部２０５と、他の端末や呼制御サーバ６０１と呼制御のシグナリングを送受して、ストリーミングの受信開始や終了を制御する呼転送制御部２０６とを含む。
【００３６】
第二の受信端末３０１は、第一の受信端末２０１と同様にストリーミングを受信する端末である。第二の受信端末３０１は、受信アプリケーション２０２と同等の受信アプリケーション３０２、損失履歴管理部２０３と同等の損失履歴管理部３０３、損失率報告部２０４と同等の損失率報告部３０４、呼制御転送部２０６と同等の呼制御転送部３０６と、送信端末１０１と自端末とのインターネット上の経路と、送信端末１０１と他の受信端末とのインターネット上の経路とが同一であることを判定するために必要な情報を測定、報告する経路関連情報報告部３０５とで構成される。
【００３７】
また、図２において、ルータ４０１は、宅内等に設置されるルータであり、第一の受信端末２０１および第二の受信端末３０１は、ローカルネットワーク７０１を通じて、ルータ４０１に接続されている。ルータ４０１は、インターネット５０１に接続されている。５０２は送信端末１０１とルータ４０１との間のインターネット上の経路を模式的に示したものである。
【００３８】
呼制御サーバ６０１は、送信端末１０１の呼制御転送部１０４、第一の受信端末２０１の呼転送制御部２０６および第二の受信端末３０１の呼制御転送部３０６と呼制御のシグナリングを送受、もしくは中継する呼制御サーバである。
【００３９】
次に、上記の構成において、送信端末１０１でＴＦＲＣの送信レート制御を行っている音声、動画等のストリームの受信端末を、第一の受信端末２０１から第二の受信端末３０１に切り替える動作について図を用いて説明する。
【００４０】
図３は、実施の形態１におけるストリーミングの受信端末の切り替え動作を説明するための説明図（同一経路の場合）である。図３は、呼制御のシーケンスの送受の方式として、ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を用い、呼制御サーバで集中制御しながら切り替えの動作を行った場合のシーケンスを示す。まず、第１の受信端末の損失履歴管理部２０３から損失履歴情報を呼転送制御部２０６に通知する。第一の受信端末２０１の呼転送制御部２０６が呼制御サーバ６０１に第二の受信端末３０１へ受信端末を切り替える切り替え要求メッセージを送付する。このメッセージには、第二の受信端末２０１を特定するＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）、現在送信端末１０１と受信端末との間で行われている通信（ストリーミング）を特定する識別子ＣＡＬＬ―ＩＤ、送信端末１０１と第一の受信端末２０１との間のインターネット上の経路を示す情報、および損失履歴管理部２０３で管理されていた損失履歴情報が含まれている。
【００４１】
呼制御サーバ６０１では、この切り替え要求メッセージを解釈し、第二の受信端末３０１を特定する。そして、呼制御サーバ６０１は、第二の受信端末３０１に対して、送信端末１０１と第二の受信端末３０１との間のインターネット上の経路を計測するために必要な情報として、送信端末１０１のＩＰアドレス情報を含む同一経路確認要求メッセージを送信する。同一経路確認要求メッセージを受信した第二の受信端末３０１の経路関連情報報告部３０５は、同一経路確認要求メッセージに含まれる送信端末１０１のＩＰアドレス情報を用いて、送信端末１０１と第二の受信端末３０１との経路を計測する。そして、経路関連情報報告部３０５は、計測した経路情報を同一経路確認応答メッセージに含めて、呼制御サーバ６０１に返答する。
【００４２】
同一経路確認応答メッセージを受信した呼制御サーバ６０１では、この経路情報を用いて、送信端末１０１と第一の受信端末２０１との間のインターネット上の経路と、送信端末１０１と第二の受信端末３０１との間のインターネット上の経路とが、同一であることを判定する。この判定を経路同一性の判定と呼ぶ。経路同一性の判定で、同一経路であると判定された場合、呼制御サーバ６０１は、第二の受信端末３０１へ第一の受信端末２０１の損失履歴情報を含むメッセージ（図３のＩＮＶＩＴＥメッセージ）を通知する。そして、呼制御サーバ６０１は、送信端末１０１に対して、第一の受信端末２０１と同じ送信レートを第二の受信端末３０１に対して適用することを記述した送信レート移送メッセージ（図３のＩＮＶＩＴＥメッセージ）を送信する。
【００４３】
図１０は、前記損失履歴情報を含むメッセージの形式の例を説明する図である。図１０において、1101は、インターネット標準文書RFC2543で規定されるSIP(Session Initiation Protocol)のINVITEメッセージのヘッダの例である。1102は、インターネット標準の草案draft-ietf-mmusic-sdp-new-25.txtで規定されるSDP(Session Description Protocol)形式のメッセージ本体の例である。1103は、損失履歴情報の記述例である。1104は、SDPにおける、「属性」を記述することを指定するための記号である。1105は、属性の種別、1106は、属性の値を示す。属性の値1106は、カンマで区切られたテキストで記述される。1107は属性が何通りあるかという属性の値の数を示す文字列である。1108以後1109までのカンマで区切られたそれぞれの文字列は、損失履歴を示す情報である。
本記述例では、損失履歴を示す情報は、あるパケット損失と次のパケット損失の間に記録されたパケットの数、すなわち、損失間隔を示すパケット数を記録したものである。すなわち、1108以後1109までのカンマで区切られた文字列は、損失間隔の履歴を示したものである。例えば、はじめのパケット損失発生から1024のパケットが到達した後にパケット損失が発生し、その後2000のパケットが到達した後に再びパケット損失が発生した、ということを示す。なお、損失履歴情報は、本実施例のように、損失イベントが発生した間に受信したパケットの数で表してもよいし、この数の逆数を損失イベント率として表してもよい。また、損失イベントが発生した時間間隔と、そのとき受信端末が受信しているストリーミングデータの受信速度を損失履歴の情報として伝達してもよい。また、本実施例では、損失履歴の情報を８個分送信する例を示しているが、これに限定されるものではない。すなわち、1個以上、有限個送付しても良い。なお、本実施例では、損失履歴の情報を記述する方式としてdraft-ietf-mmusic-sdp-new-25.txtで規定されるSDP(Session Description Protocol)形式に準拠したものを示しているが、XML(Extensible Markup Language)ベースでセッションの情報を記述するdraft-ietf-mmusic-sdpng-08.txtで規定されるSDPng形式で記述しても、他の記述方式で記述してもかまわない。
【００４４】
損失履歴情報を含むメッセージを受信した第二の受信端末３０１では、損失率報告部３０４にこの損失履歴情報を反映させ、第一の受信端末２０１と同等の受信履歴を保持する。具体的には、第二の受信端末３０１は、図１０に示す1108から1109に記述された損失間隔の履歴情報を損失履歴情報として保持する。そして、第二の受信端末３０１は、この損失履歴情報を用いてTFRCによるレート制御のために必要な情報（すなわち、送信レート移送メッセージ）を生成し、送信端末１０１に送信する。送信レート移送メッセージを受信した送信端末１０１の呼転送制御部１０４は、第二の受信端末３０１に対して、第一の受信端末２０１に適用していた送信レートと同一の送信レートを初期値として適用するように、送信レート制御部１０１および送信アプリケーション１０２を制御する。
【００４５】
このように動作することで、まず、ストリーミングを受信する受信端末を第一の受信端末２０１から第二の受信端末３０１に切り替える寸前に、送信端末１０１から第一の受信端末２０１へのストリーミングの送信に適用されていた送信レートが、送信端末１０１から第二の受信端末３０１へのストリーミングの初期値として適用される。また、切り替え後に送信端末１０１と第二の受信端末３０１の間で行われる送信レート制御動作は、第一の受信端末２０１の損失履歴情報を引き継いでいる。したがって、受信端末切り替え後に、送信端末１０１と第二の受信端末３０１の間で、送信端末１０１と第一の受信端末２０１の間で行われた送信レート制御動作と同等の動作を継続することが可能となる。
【００４６】
なお、上記の経路同一性の判定は、送信端末１０１と受信端末との間の経路をトレースルート（ｔｒａｃｅｒｏｕｔｅ）と呼ばれる経路判定方法を用いることにより実現できる。トレースルートとは、インターネット上のルータが、パケットに記載されているＴＴＬ（Ｔｉｍｅ  Ｔｏ  Ｌｉｖｅ）情報が０になった場合に送信元端末にＩＣＭＰを返送することを利用した経路測定方法である。この方法を用いると特定端末間のインターネット上の経路を計測することが可能となる。具体的な運用方法としては、（１）受信端末から送信端末へトレースルートを行う方法、（２）送信端末から受信端末へトレースルートを行う方法、（３）後述する特定条件の下で第一および第二の受信端末が同一ルータを介して接続されていることを確認する方法、が利用できる。
【００４７】
図３は（１）の方法、すなわち、受信端末から送信端末へトレースルートを行う場合を想定したシーケンスとなっている。同様に、（２）の方法、すなわち、送信端末から受信端末へトレースルートを行うことでも、経路同一性の判定を行うことができる。この場合、まず、呼制御サーバ６０１が、送信端末１０１の呼転送制御部１０４に第一および第二の受信端末２０１，３０１のＩＰアドレスを含む同一経路確認要求メッセージを送信する。そして、呼転送制御部１０４がトレースルートを用いて第一および第二の受信端末２０１，３０１に対する経路を測定し、測定の結果を同一経路応答メッセージに記載して返送すればよい。
【００４８】
なお、この同一経路判定方法は、第一の受信端末２０１と第二の受信端末３０１とが同一のローカルネットワーク７０１に接続されており、ローカルネットワーク７０１上にルータ４０１を経由する経路以外の経路がないことが確認できる場合、より簡素な方法で実現できる。すなわち、上記（３）で記した方法は、後述する２つの条件を満たすことで、同一経路と判定する方法である。２つの条件とは、第一の受信端末２０１と第二の受信端末３０１が接続されているローカルネットワークが同一であること（３−１）と、送信端末１０１から第一の受信端末２０１へのストリーミングがルータ４０１を経由して配送されていること（３−２）である。この方法は、宅内のネットワーク等のローカルネットワークが単一のＩＳＰに接続されていること（３−Ｐ１）が判定でき、第一および第二の受信端末に対して、トンネル通信が行われていない（３−Ｐ２）場合に有効である。
【００４９】
なお、（３−Ｐ１）の確認は、第一および第二の受信端末をローカルネットワークに接続する場合に、全てのルータがＪＯＩＮしているマルチキャストグループであるａｌｌ  ｒｏｕｔｅｒｓからの応答により行う。まず、ａｌｌ  ｒｏｕｔｅｒｓ  （例：ＩＰｖ６の場合、ｆｆ０２：：２）に応答要求（例：ｐｉｎｇ６）を発行し、この応答が一つのルータのみであることを確認することで判定できる。
【００５０】
なお、本実施の形態１において、損失履歴情報を、切り替え要求メッセージに含める方法を説明したが、図３のシーケンスにおいて、経路同一性判定の後に、呼制御サーバから第一の受信端末２０１に損失履歴情報の問い合わせをしてもよい。
【００５１】
図４は、実施の形態１におけるストリーミングの受信端末の切り替え動作を説明するための説明図（同一経路でない場合）であり、本実施の形態１の前記経路同一判定において、同一経路ではないと判定された場合のシーケンスである。図４で、同一経路確認応答までのシーケンスは、図３と同じである。同一経路確認応答により、呼制御サーバ６０１で、送信端末１０１と第一の受信端末２０１との間のインターネット上の経路と、送信端末１０１と第二の受信端末３０１との間のインターネット上の経路とが、同一経路であるか否かを判定する。同一経路でないと判定された場合、呼制御サーバ６０１は、第二の受信端末３０１および送信端末１０１に、送信レートの引継ぎなしでストリーミングの転送が行われた旨を通知する（図４のＩＮＶＩＴＥメッセージ）。このメッセージを受け取った第二の受信端末３０１は、損失履歴管理部３０３を初期化して送信端末１０１からのストリーミングの受信に備える。送信端末１０１の呼転送管理部１０４は、第一の受信端末２０１に適用していた送信レートを適用せずに、ＴＦＲＣのスロースタートアルゴリズムにしたがって、送信レートを増速させていく。この結果、第二の受信端末３０１では、切り替えの後、ストリーミングの送信レートが目的の送信レートに達するまでの間再生ができないが、受信端末の切り替え自体は完了することができる。
【００５２】
すなわち、本実施の形態の送信レート移送方法では、パケット損失の履歴情報と往復時間情報に基づいて帯域を推定して送信レート制御を行うストリーミングの受信端末を第一の受信端末２０１から第二の受信端末３０１へ変更する際の送信レート移送方法の処理手順は、次のようなステップを含む。つまり、ストリーミングの送信端末１０１と第一の受信端末２０１との間のネットワーク上の経路と、送信端末１０１と第二の受信端末３０１との間の前記ネットワーク上の経路とが、同一であるかを判定する判定ステップ（１）と、判定ステップ（１）で経路が同一であると判断した場合に、第一の受信端末２０１が管理しているパケット損失の履歴情報を第二の受信端末３０１に伝達する伝達ステップ（２）と、判定ステップ（１）で経路が同一であると判断した場合に、送信端末１０１および第二の受信端末３０１に対して、第一の受信端末２０１から第二の受信端末３０１に送信レートが引き継がれたことを通知し、判定ステップ（１）で経路が同一でないと判断した場合に、送信端末１０１および第二の受信端末２０１に対して、第一の受信端末２０１から第二の受信端末３０１に送信レートが引き継がれずに受信端末の変更のみが実施されることを通知する通知ステップ（３）とを有し、各ステップ（１）、（２）、（３）によって受信端末を変更するようにしている。
【００５３】
この構成によれば、経路が同一であると判断した場合に、第一の受信端末２０１が管理しているパケット損失の履歴情報を第二の受信端末３０１に伝達することにより、第二の受信端末３０１は、スロースタートを行うことなく、伝達された履歴情報を用いて、直ちに、第一の受信端末２０１が使用していた送信レートと同一の送信レートでストリーミングを受信することができる。したがって、受信端末を切り替えた直後から途切れずにストリーミングを受信および再生することができる。
【００５４】
また、上記構成によれば、ストリーミングの送信端末１０１と第一の受信端末２０１との間のネットワーク上の経路と、送信端末１０１と第二の受信端末３０１との間の前記ネットワーク上の経路とが、同一であることを判定することにより、ネットワーク上の経路が同一でない場合には第二の受信端末３０１にパケット損失の履歴情報が伝達されない。したがって、第二の受信端末３０１が不適当に高い送信レートでストリーミングを受信してネットワークを輻輳状態にすることを防止できる。
【００５５】
（実施の形態２：呼制御サーバなしで呼転送）
図５は、本発明の実施の形態２を説明するための通信システムの構成を示すブロック図である。
【００５６】
図５に示す通信システムは、図２に示す通信システムが備える呼制御サーバ６０１を備えないものである。図５中の１０２，１０３，２０１，２０２，２０３，２０４，２０５，３０２，３０３，３０４，３０５，４０１，５０１，５０２，７０１は、図２と同じものである。図５において、送信端末１０１の呼転送制御部１０４、第一の受信端末２０１の呼転送制御部２０６、第二の受信端末３０１の呼転送制御部３０６は、他の端末と呼制御のシグナリングを送受して、ストリーミングの受信開始や終了を制御するものであり、実施の形態１で説明したものと機能が異なる。また、図５に示す第一の受信端末２０１は、図２に示す経路関連情報報告部２０５の代わりに、送信端末１０１と自端末とのインターネット上の経路と、送信端末１０１と他の受信端末とのインターネット上の経路とが、同一であることを判定する同一経路判断部２０７を備える。つまり、図２の経路関連情報報告部２０５は、送信端末が主導的に経路計測を行った場合に経路を計測応答する機能、第一の受信端末２０１と第二の受信端末３０１が同一ネットワークに接続されており、インターネットの接続において同一のルータ４０１を持つことを確認する機能を持つものである。一方、同一経路判断部２０７は、受信端末が主導的に経路計測を行う機能を持つことが、経路情報報告部２０５の機能とは異なる。
【００５７】
この構成において、送信端末１０１においてＴＦＲＣの送信レート制御を行っている音声、動画等のストリーミングの受信端末を第一の受信端末２０１から第二の受信端末３０１に切り替える動作について説明する。
【００５８】
図６は、実施の形態２におけるストリーミングの受信端末の切替動作を説明するための説明図（同一経路の場合）である。図６は、呼制御のシーケンスの送受の方式としてＳＩＰを用い、呼制御サーバを用いずに切り替えの動作を行った場合のシーケンスを示したものである。
【００５９】
まず、第一の受信端末２０１の呼転送制御部２０６から第二の受信端末３０１の呼転送制御部３０６へ、受信端末を切り替える旨のＲＥＦＥＲ（送信端末）メッセージを送信する。このＲＥＦＥＲメッセージには、送信端末１０１を特定するＵＲＩおよび状態通知を要請するＳＵＢＳＣＲＩＢＥを含む。ＲＥＦＥＲメッセージを受信した第二の受信端末３０１の呼転送制御部３０６は、このＲＥＦＥＲメッセージを解釈して、送信端末１０１に送信レートの引継ぎを試みる意味を含むＩＮＶＩＴＥメッセージを送る。そして、この応答であるＯＫメッセージを受ける。
【００６０】
次に、第二の受信端末３０１の呼転送制御部３０６は、ＳＵＢＳＣＲＩＢＥメッセージに対応した状態通知メッセージであるＮＯＴＩＦＹメッセージを第一の受信端末２０１に返送する。ＮＯＴＩＦＹメッセージを受信した第一の受信端末２０１の呼転送制御部２０６は、送信端末との第二の受信端末３０１の呼制御動作が正常に行われたことを検知し、次に同一経路判断部２０７から第二の受信端末３０１に対して、同一経路確認要求メッセージを送る。第二の受信端末３０１の経路関連情報報告部３０５は、同一経路確認要求メッセージを受け取り、同一経路確認応答メッセージを返送する。この同一経路確認要求メッセージおよび同一経路確認応答メッセージは、実施の形態１で説明したものと同等のものである。同一経路判断部２０７は、第一の受信端末２０１と送信端末１０１の間の経路を測定する。同一経路判断部２０７が同一経路確認応答メッセージを受け取ると、送信端末１０１と第一の受信端末２０１との間のインターネット上の経路と、送信端末１０１と第二の受信端末３０１との間のインターネット上の経路とが、同一である場合、第一の受信端末２０１の損失履歴管理部２０３は、損失履歴情報を第二の受信端末３０１に送信し、次に呼転送制御部２０６はＮＯＴＩＦＹによる状態通知を停止するＵＮＳＵＢＳＣＲＩＢＥメッセージを送信する。
【００６１】
次に、第二の受信端末３０１は、損失履歴情報の引継ぎが完了したので、第一の受信端末２０１と同じ送信レートを第二の受信端末３０１へのストリーミングに対して適用するように指示する旨のメッセージを含むＡＣＫメッセージを送信端末１０１に対して送信する。このＡＣＫメッセージを受信した送信端末１０１の呼転送制御部１０４は、第一の受信端末２０１と同じ送信レートを第二の受信端末３０１へのストリーミングに適用するように送信レート制御部１０３および送信アプリケーション１０２を制御する。
【００６２】
このように動作することで、ストリーミングを受信する受信端末を第一の受信端末２０１から第二の受信端末３０１へ切り替える寸前に、同一経路判断部２０７によって、第一の受信端末２０１と送信端末の間の経路と第二の受信端末と送信端末の間の経路を確認できるので、送信端末１０１から第一の受信端末２０１へのストリーミングの送信に適用されていた送信レートが、送信端末１０１から第二の受信端末３０１へのストリーミングの初期値として適用される。また、切り替え後に送信端末１０１と第二の受信端末３０１の間で行われる送信レート制御動作は、第一の受信端末２０１の損失履歴情報を引き継いでいるので、送信端末１０１と第一の受信端末２０１の間で行われる送信レート制御動作と同等の動作を継続することが可能となる。
【００６３】
なお、図７は、実施の形態２におけるストリーミングの受信端末の切り替え動作を説明するための説明図（同一経路でない場合）である。図７は、上記経路同一判定において、同一経路ではないと判定された場合のシーケンスである。図７で、同一経路確認応答までのシーケンスは図６と同じである。すなわち、同一経路判断部２０５は、第一の受信端末２０１と送信端末１０１の間の経路と第二の受信端末３０１と送信端末１０１の間の経路が同一かどうか測定、判定する。このとき、同一経路確認応答により、第一の受信端末２０１で、送信端末１０１と第一の受信端末２０１との間のインターネット上の経路と、送信端末１０１と第二の受信端末３０１との間のインターネット上の経路とが、同一でないと判定された場合、第一の受信端末２０１は、第二の受信端末３０１に送信レートの引継ぎなしでストリーミングの転送を行う旨をＵＮＳＵＢＳＣＲＩＢＥメッセージで通知する。
【００６４】
ＵＮＳＵＢＳＣＲＩＢＥメッセージを受信した第二の受信端末３０１の呼転送制御部３０６は、損失履歴管理部３０３を初期化して送信端末１０１からのストリーミングの受信に備える。そして第二の受信端末３０１の呼転送制御部３０６は、送信レートの引継ぎなしでストリーミングの転送が行われた旨をＡＣＫメッセージに含めて送信端末１０１の呼転送制御部１０４に通知する。このＡＣＫメッセージを受信した送信端末１０１の呼転送管理部１０４は、第一の送信端末２０１に適用していた送信レートを適用せずに、ＴＦＲＣのスロースタートアルゴリズムにしたがって、送信レートを増速させていく。この結果、第二の受信端末３０１では、切り替えの後、ストリーミングの送信レートが目的の送信レートに達するまでの間再生ができないが、受信端末の切り替え自体は完了することができる。
【００６５】
（実施の形態３：マルチキャスト配信に適用）
実施の形態３を説明するための通信システムの構成は、図５に示すものと同じであるので、重複する説明は省略する。本実施の形態では、図５の呼転送制御部１０４、２０６および３０６は、他の端末と呼制御のシグナリングを送受して、ストリーミングの受信開始や終了を制御するものであり、実施の形態１および２で説明したものと機能が異なる。送信レート制御部１０３は、後述する損失率報告部２０４、３０４から利用可能な帯域の情報を受信し、最も遅い速度にあわせて送信アプリケーションのストリーミングを送信する。第一，第二の受信端末２０１，３０１の損失率報告部２０４、３０４は、受信端末が計測した送信端末１０１と各受信端末との間のＲＴＴと、損失イベント率とを用いて送信レートを算出し、送信端末１０１に報告する。
【００６６】
この構成において、送信端末１０１でＴＦＭＣＣ（ＴＣＰ−Ｆｒｉｅｎｄｌｙ  Ｍｕｌｔｉｃａｓｔ  Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ：参考文献、インターネット草案ｄｒａｆｔ−ｉｅｔｆ−ｒｍｔ−ｂｂ−ｔｆｍｃｃ−０１．ｔｘｔ  ）の送信レート制御を行っている音声、動画等のストリーミングを第一の受信端末２０１のみで受信している状態から、新たに第二の受信端末３０１にも受信させる場合の問題点と、この問題点を解決する動作について説明する。
【００６７】
まず、ＴＦＭＣＣの動作概要と問題点について説明する。ＴＦＭＣＣは、ＴＦＲＣの送信レート制御をマルチキャストに適用した方式である。受信側でパケットの損失を検知し、その履歴を管理し、損失履歴情報を用いて損失イベント率を計算する部分は、ＴＦＲＣの動作と同じである。ＴＦＭＣＣでは、送信端末と受信端末の間のＲＴＴを受信端末が計測し、このＲＴＴと損失イベント率を用いて受信端末が式１を用いて送信レートＸを推定する。受信端末は、この送信レートＸを送信端末に報告し、送信端末は、最も遅い受信端末の送信レートに合わせてストリーミングを送信する。
【００６８】
ＴＦＭＣＣ通常動作においては、新たに受信端末を追加した場合、スロースタートが行われるため、ストリーミングの送信レートが目的の送信レートに達するまでの間、再生ができないという問題があった。
【００６９】
実施の形態３は、ＴＦＭＣＣによるストリーミングの送信レート制御が行われているストリーミングにおいて、新たに受信端末を追加した場合に同じ送信レートで継続的に受信できる方法を提供する。本実施の形態３の動作について図８を用いて説明する。
【００７０】
図８は、実施の形態３におけるストリーミングの受信端末の追加動作を説明するための説明図（同一経路の場合）である。本実施の形態では、第二の受信端末３０１を新たに参加させる場合について説明する。すなわち、図８において第一の受信端末２０１は、これまでストリーミングを受信していた受信端末であり、第二の受信端末３０１が新たに追加される受信端末である。
まず、第一の受信端末２０１の呼転送制御部２０６から第二の受信端末３０１の呼転送制御部３０６に、送信端末１０１が送信しているストリーミングのマルチキャストアドレス情報を含むＩＮＶＩＴＥメッセージを送信する。第二の受信端末３０１の呼転送制御部３０６は、応答のＲＩＮＧＩＮＧメッセージを送信後、同一経路確認要求を含んだＯＫメッセージを送信する。ＯＫメッセージを受信した第一の受信端末２０１の呼転送制御部２０６は、損失履歴情報、同一経路確認応答を含むＡＣＫメッセージを第二の受信端末３０１に送信する。ＡＣＫメッセージを受信した第二の受信端末３０１の呼転送制御部３０６は、同一経路判断部２０７によって、第一の受信端末２０１と送信端末１０１の間の経路と第二の受信端末３０１と送信端末１０１の間の経路が同一かどうか判断する。この判断の方法は、実施の形態２で説明した方法と同じである。この経路同一性の判定結果において、送信端末１０１と第一の受信端末２０１との間のインターネット上の経路と、送信端末１０１と第二の受信端末３０１との間のインターネット上の経路とが、同一である場合、第二の受信端末３０１は、損失履歴情報を損失履歴管理部３０３に適用する。
その後、第二の受信端末３０１は、ＩＮＶＩＴＥメッセージに記載されているマルチキャストアドレスを受信するための手続きを実施する。具体的には、呼転送制御部３０６は、ＩＰｖ４の場合はＩＧＭＰ（Ｉｎｔｅｒｎｅｔ  Ｇｒｏｕｐ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）やＭＬＤ（Ｍｕｌｔｉｃａｓｔ  Ｌｉｓｔｅｎｅｒ  Ｄｉｓｃｏｖｅｒｙ：参考文献ＲＦＣ２７１０，インターネット草案ｄｒａｆｔ−ｈｏｌｂｒｏｏｋ−ｉｄｍｒ−ｉｇｍｐｖ３−ｓｓｍ−０７．ｔｘｔ）の参加メッセージ（ＪＯＩＮメッセージ）を送信し、マルチキャストデータを受信できるように受信アプリケーション、および受信端末のネットワークインターフェイス、ドライバを制御する。
【００７１】
このように動作することによって、第二の受信端末３０１はマルチキャストで伝送されるストリームを受信することが可能となる。また、このとき第二の受信端末３０１が送信端末１０１との間で報告する受信可能な帯域は、第一の受信端末２０１から受信した損失履歴情報に基づいて計算される。これにより、第二の受信端末３０１の損失率報告部３０３と第一の受信端末２０１の損失率報告部２０３は、同じ損失率を送信端末１０１に報告することになる。送信端末１０１の送信レート制御部１０３では、もっとも遅い受信端末に合わせてストリームの送信を行うように制御を行うが、第一の受信端末２０１と第二の受信端末３０１から報告される損失率が同じであり、且つ送信端末１０１と第一の受信端末２０１、第二の受信端末３０１の間の経路が同じであるため、往復時間も同じとなる。したがって、式（１）で算出する利用可能な帯域も同じ数値となる。つまり、第二の受信端末３０１は、第一の受信端末２０１と同等の送信レートを送信端末１０１に報告しながらマルチキャストグループに参加するので、送信端末１０１は、送信レートを低下させる必要がなくなる。このため送信端末１０１は、スロースタートせず、第二の受信端末３０１が受信する前の同じ制御を継続するので、送信端末１０１の送信レートが維持される。
【００７２】
結果、新たに受信端末が追加した場合に、第一の受信端末２０１、および第二の受信端末３０１は、同じ送信レートを初期値として継続的に受信できる。
【００７３】
なお、実施の形態３においては、ストリーミングは、受信端末がＪＯＩＮメッセージを発行することでインターネット上の配送木が構築されるマルチキャストでストリーミングの配送が行われ、送信レート制御としてＴＦＭＣＣが用いられていることを想定していたが、この方式に限らない。例えば、マルチキャストの方式としてＸＣＡＳＴ（ｅＸｐｌｉｃｉｔ  Ｍｕｌｔｉｃａｓｔ：参考文献Ｙ．  Ｉｍａｉ，  Ｍ．  Ｓｈｉｎ  ａｎｄ  Ｙ．  Ｋｉｍ，  “ＸＣＡＳＴ６：  ｅＸｐｌｉｃｉｔ  Ｍｕｌｔｉｃａｓｔ  ｏｎ  ＩＰｖ６”，  ＩＥＥＥ／ＩＰＳＪ  ＳＡＩＮＴ２００３  Ｗｏｒｋｓｈｏｐ  ４，  ＩＰｖ６  ａｎｄ  Ａｐｐｌｉｃａｔｉｏｎｓ，  Ｏｒｌａｎｄ，  Ｊａｎ．２００３）によって配送が行われ、送信レート制御の方式として、送信者起動マルチキャストを用いた輻輳制御方式（参考文献：村本  衛一，  米田  孝弘，  鈴木  史章，  鈴木  良宏，  中村  敦司，  “送信者起動マルチキャストにおける輻輳制御方法の提案”，  インターネットコンファレンス２００３論文集  ｐｐ５−１０，  ２００３／１０）を適用した場合でも実現することができる。具体的には、実施の形態３の図５に示す構成要素において、図６を用いて説明したシーケンスで第二の受信端末３０１を新たに参加させることで、第一の受信端末２０１および第二の受信端末３０１は、同じ送信レートを初期値として継続的に受信できる。
【００７４】
なお、実施の形態３において、実施の形態１で説明した呼制御サーバ６０１を導入し、集中制御する場合でも実現できる。
【００７５】
このように、本実施の形態では、パケット損失の履歴情報と往復時間情報に基づいて帯域を推定して送信レート制御を行いながら、マルチキャストにより配送されるストリーミングを受信する受信端末として、第一の受信端末に加えて第二の受信端末を追加する際の送信レート移送方法において、ストリーミングの送信端末と第一の受信端末との間のネットワーク上の経路と、該送信端末と第二の受信端末との間の前記ネットワーク上の経路とが同一であるかを判定する判定ステップ（１）と、判定ステップ（１）で経路が同一であると判断した場合に、第一の受信端末が管理しているパケット損失の履歴情報を第二の受信端末に伝達する伝達ステップ（２）と、判定ステップ（１）で経路が同一であると判断した場合に、送信端末および第二の受信端末に対して、送信レートが第一の受信端末から第二の受信端末に引き継がれたことを通知し、判定ステップ（１）で経路が同一でないと判断した場合に、送信端末および第二の受信端末に対して、送信レートが第一の受信端末から第二の受信端末に引き継がれずに受信端末の追加のみが実施されることを通知する通知ステップ（３）とを有し、各ステップ（１）、（２）、（３）によって受信端末を追加するようにしている。
【００７６】
この構成によれば、経路が同一であると判断した場合に、第一の受信端末２０１が管理しているパケット損失の履歴情報を第二の受信端末３０１に伝達することにより、第二の受信端末３０１は、スロースタートを行うことなく、伝達された履歴情報を用いて、直ちに、第一の受信端末２０１が使用していた送信レートと同一の送信レートでストリーミングを受信することができる。このため、第一の受信端末２０１に加えて第二の受信端末３０１を追加した直後から途切れずにストリーミングを受信および再生することができる。
【００７７】
また、上記構成によれば、ストリーミングの送信端末１０１と第一の受信端末２０１との間のネットワーク上の経路と、送信端末１０１と第二の受信端末３０１との間の前記ネットワーク上の経路とが同一であることを判定することにより、ネットワーク上の経路が同一でない場合には第二の受信端末３０１にパケット損失の履歴情報が伝達されない為、第二の受信端末３０１が不適当に高い送信レートでストリーミングを受信してネットワークを輻輳状態にすることを防止できる。
【００７８】
（実施の形態４：ルータに複数のネットワークが接続される場合に適用）
図９は、実施の形態４を説明するための通信システム（２つのサブネットを持つルータ）の構成を示すブロック図である。
【００７９】
図９に示す通信システムは、他の実施の形態で説明した通信システムとネットワークの接続関係が異なる。図９中の１０１，１０２，１０３，１０４，２０１，２０２，２０３，２０４，２０７，２０６，３０１，３０２，３０３，３０４，３０５，３０６，４０１，５０１，５０２は、図５と同じものである。図９において、７０１は、ルータ４０１および第一の受信端末２０１が接続されている第一のネットワーク、７０２はルータ４０１および第二の受信端末３０１が接続されている第二のネットワークである。
【００８０】
この構成において、図６を用いて説明したシーケンスを用いて第一の受信端末２０１から第二の受信端末３０１へ受信端末を切り替える実現方法について説明する。同一経路判断部２０７は、経路同一性の判断において次のアルゴリズムを適用することで、送信端末１０１と第一の受信端末２０１との間のインターネット上の経路と、送信端末１０１と第二の受信端末３０１との間のインターネット上の経路とが同一であることを判定することができる。
【００８１】
（経路同一性判定のアルゴリズム）
（ステップ１）隣接ルータの同一性を確認する。
（ステップ２）隣接ルータと送信端末の間の経路の同一性を確認する。
【００８２】
上記のステップ１、ステップ２で隣接ルータの同一性および隣接ルータと送信端末１０１の間の経路の同一性が確認できたことで、インターネット上の経路が同一であると判定する。
【００８３】
上記のステップ１は、実施の形態１で説明したトレースルートを用いて確認できる。まず、第一の受信端末２０１から第二の受信端末３０１へのトレースルートの結果における最初のルータ（以後、ファーストホップルータと呼ぶ）と、第一の受信端末２０１から送信端末１０１へのトレースルートの結果におけるファーストホップルータとが一致していることを確認する。また、第二の受信端末３０１から第一の受信端末２０１へのトレースルートの結果におけるファーストホップルータと、第二の受信端末３０１から送信端末１０１へのトレースルートの結果におけるファーストホップルータとが一致していることを確認する。さらに、第一の受信端末２０１と第二の受信端末３０１との間のルータが１台であることを確認する。これら３つを確認できれば、ステップ１が確認できる。
【００８４】
もしくは、送信端末１０１から第一の受信端末２０１のトレースルートの結果と送信端末１０１から第二の受信端末３０１のトレースルートの結果とを比較することでステップ１が確認できる。
【００８５】
なお、上記の経路同一性判定のアルゴリズムにおいて、ステップ３として第一の受信端末２０１および第二の受信端末３０１がトンネルインターフェイスのように仮想インターフェイスに接続されていないことを確認することを加えても良い。例えば、第一の受信端末２０１と送信端末１０１とがIPv6 over IPv4トンネルなど仮想インターフェイスを用いず通信し、第二の受信端末３０１がインターネット５０１上の特定サーバとVPN(Virtual Private Network)などトンネル通信を行っている場合を想定する。この場合、第二の受信端末３０１と送信端末１０１の間の経路は、仮想インターフェイスを用いず計測したトレースルートの経路とは異なり、前記特定サーバ経由の経路となることがある。このため、同一経路判定のアルゴリズムにおいて、仮想インターフェイスを用いた経路計測と仮想インターフェイスを用いなかった場合の経路計測が同一となるかどうかを判断するステップを付け加えることで、同一経路でない場合は、より早い判断が可能となる。一方、同一経路の場合は、より計測精度の高い同一経路判定が可能となる。
【００８６】
なお、上記の経路同一性判定のアルゴリズムにおいて、ステップ１は、以下の手順で確認できる。まず、第一および第二の受信端末２０１、３０１が、それぞれ第一および第二のネットワーク７０１、７０２上でａｌｌ  ｒｏｕｔｅｒｓに対して肯定応答要求（例：ｐｉｎｇ６）を発行する。そして、第一および第二の受信端末２０１、３０１は、ルータからの応答を受信し、この応答の送信元（ルータ）に名前の問い合わせ（例：インターネット草案：ｄｒａｆｔ−ｉｅｔｆ−ｉｐｎｇｗｇ−ｉｃｍｐ−ｎａｍｅ−ｌｏｏｋｕｐｓ−１０．ｔｘｔに規定されるＮｏｄｅ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｑｕｅｒｙ、例：ＤＮＳ（ｄｏｍａｉｎ  ｎａｍｅ  ｓｅｒｖｉｃｅ）のＩＰアドレスをキーに検索して名前を得る方法である逆引き）を行う。
【００８７】
ステップ２は、実施の形態１で説明したトレースルートを用いて確認できる。
【００８８】
このように動作することで、ストリーミングを受信する受信端末を第一の受信端末２０１から第二の受信端末３０１に切り替える寸前に、送信端末１０１から第一の受信端末２０１へのストリーミングの送信に適用されていた送信レートが、送信端末１０１から第二の受信端末３０１へのストリーミングの初期値として適用される。また、切り替え後に送信端末１０１と第二の受信端末３０１との間で行われる送信レート制御動作は、第一の受信端末２０１の損失履歴情報を引き継いでいる。これにより、送信端末１０１と第一の受信端末２０１との間で行われる送信レート制御動作と同等の動作を継続することが可能となる。
【００８９】
本発明を詳細にまた特定の実施態様を参照して説明したが、本発明の精神と範囲を逸脱することなく様々な変更や修正を加えることができることは当業者にとって明らかである。
本出願は、2005年1月11日出願の日本特許出願（特願2005−003967）に基づくものであり、その内容はここに参照として取り込まれる。
【産業上の利用可能性】
【００９０】
本発明は、ストリーミングを受信する端末を第一の受信端末から第二の受信端末に切り替える（または受信端末として第二の受信端末を追加する）際に、切り替えた（追加した）後、直ちに途切れずにストリーミングを受信、再生することができる効果を有し、ＴＦＲＣ（ＴＣＰ  Ｆｒｉｅｎｄｌｙ  Ｒａｔｅ  Ｃｏｎｔｒｏｌ）を用いたレート制御を行うストリーミングの受信端末を第一の受信端末から第二の受信端末へ変更する通信方法および受信端末等に有用である。
【図面の簡単な説明】
【００９１】
【図１】ＴＦＲＣを用いた送信レート制御の説明図
【図２】実施の形態１（呼制御サーバあり）を説明するための通信システムの構成を示すブロック図
【図３】実施の形態１におけるストリーミングの受信端末の切替動作を説明するための説明図（同一経路の場合）
【図４】実施の形態１におけるストリーミングの受信端末の切替動作を説明するための説明図（同一経路でない場合）
【図５】実施の形態２（呼制御サーバなし）を説明するための通信システムの構成を示すブロック図
【図６】実施の形態２におけるストリーミングの受信端末の切替動作を説明するための説明図（同一経路の場合）
【図７】実施の形態２におけるストリーミングの受信端末の切替動作を説明するための説明図（同一経路でない場合）
【図８】実施の形態３におけるストリーミングの受信端末の追加動作を説明するための説明図（同一経路の場合）
【図９】実施の形態４を説明するための通信システム（２つのサブネットを持つルータ）の構成を示すブロック図
【図１０】損失履歴を含むメッセージの例を説明する図
【符号の説明】
【００９２】
１０１  送信端末
１０２  送信アプリケーション
１０３  送信レート制御部
１０４、２０６、３０６  呼転送制御部
２０１  第一の受信端末
２０２、３０２  受信アプリケーション
２０３、３０３  損失履歴管理部
２０４、３０４  損失率報告部
２０５  経路関連情報報告部
２０７  同一経路判断部
３０１  第二の受信端末
３０５  経路関連情報報告部
４０１  ルータ
５０１  インターネット
５０２  インターネット上の経路
６０１  呼制御サーバ
７０１  第一のネットワーク（ローカルネットワーク）
７０２  第二のネットワーク
【図１】
0004567007.tif 000003
【図２】
0004567007.tif 000004
【図３】
0004567007.tif 000005
【図４】
0004567007.tif 000006
【図５】
0004567007.tif 000007
【図６】
0004567007.tif 000008
【図７】
0004567007.tif 000009
【図８】
0004567007.tif 000010
【図９】
0004567007.tif 000011
【図１０】
0004567007.tif 000012