ネットワーク性能劣化原因判定方法及び輻輳制御方法
【課題】ストリーミング中のパケット損失率などの増大の原因がネットワーク輻輳によるパケット棄却によるものではなくリンク／ノード障害であることを簡単に判別することで、夫々の原因に応じた適切な対応を取ることができるようにする。
【解決手段】パケット損失がバースト上に起こった場合にはリンク／ノード障害が原因であると判定する。この場合にはネットワーク輻輳が原因である場合とは異なり、ストリーム送出レート低減を行わないことで、受信されたストリームの品質が更に悪化することを防止する。
【解決手段】パケット損失がバースト上に起こった場合にはリンク／ノード障害が原因であると判定する。この場合にはネットワーク輻輳が原因である場合とは異なり、ストリーム送出レート低減を行わないことで、受信されたストリームの品質が更に悪化することを防止する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はストリーミングに関し、特にネットワーク性能の劣化の原因の判定及び判定された原因に基づいた輻輳制御に関する。
【背景技術】
【０００２】
ＩＰネットワークを介して音声、ビデオを含むいわゆるマルチメディアなどの時間軸方向に継続するデータをストリーミング方式で送ることはよく知られており、またこのようなサービスは既にインターネット上で多数提供されている。
【０００３】
ストリーミングを行うにあたって、ＩＰネットワークのトランスポート・プロトコルは、対応するパケット・ストリームの送出レートを、当該パケット・ストリームがネットワークを介してあて先に到達するまでの間に出会うトラフィックに従って規制しなければならない。このトラフィックが増大するにつれて、トランスポート・プロトコルはパケット・ストリームの送出レートを低下させなければならない。これにより、パケット・ストリームの転送経路における限られたネットワーク資源を同時に使おうとして競合するユーザ間でのある程度の公平性が維持される。このようなレート低減手順は一般に輻輳制御と呼ばれる。
【０００４】
広く使われているデータ・トランスポート・プロトコルであるＴＣＰでは、輻輳制御はパケット損失率やラウンド・トリップ時間（Round Trip Time, RTT）などの端点間の統計に基いて行われ、更に、パケットが厳密に正しい順序で到達するようにするためパケットの再送は必ず行われる。
【０００５】
メディア・ストリーミングではＴＣＰはトランスポート・プロトコルとしては不適切である。それは、必ずパケット再送を行うということは、パケットの滞留が起きる可能性があり、その結果、パケットが連続再生を行うための所要時間内にクライアントに到達しなくなるかもしれないことを意味するからである。
【０００６】
しかしながら、メディア・ストリーミング・サーバがどのようなトランスポート・プロトコルを採用したとしても、そのようなトランスポート・プロトコルは大量のＴＣＰトラフィックに対して公平性を持っている必要がある。つまり、そのようなトランスポート・プロトコルは、同じネットワーク条件下でのＴＣＰ接続よりも広い帯域を占有することはないという意味でＴＣＰ親和性がなければならない。ＴＣＰ親和性を有するトランスポート・プロトコルの例としては、送出するパケットとパケットの間に、よく知られているＴＣＰ親和性輻輳制御方程式（１）に従って間隔Ｔを開けるというものがある。
【０００７】
【数１】
【０００８】
上式中、εR、μR、σR2は夫々、サーバからクライアントまでのパケット損失率、及びサーバとクライアント間のラウンド・トリップ時間の平均、分散の推定値を表す。なお、式（１）については以下の非特許文献１に詳細が説明されている。
【非特許文献１】S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-based congestion control for unicast applications" ACM SIGCOMM, 2000
【０００９】
しかしながら、以下の非特許文献２に示されるように、インターネットの性能の劣化はネットワーク輻輳ではなくリンク／ノード障害によって起こり得ることがわかってきた。リンク／ノード障害の場合には、限られたネットワーク資源を取り合うユーザが存在するわけではないので、ストリーミング・サーバは、競合するユーザ間の公平性のために送出レートを低減する代わりに、リンク／ノード障害によるバケット損失と遅延の増大に対処するため、メディア・ストリーム・エラーへの耐性を向上させることに注力する必要がある。
【非特許文献２】G. Iannaccone, C.-N. Chuah, R. Mortier, S. Bhattacharyya, and C. Diot, "Analysis of Link Failures in an IP Backbone," ACM SIGCOMM Internet Measurement Workshop, November, 2002
【００１０】
上述のインターネットの性能劣化の２つの要因とそれに対する従来技術における解決策を以下で更に説明する。
【００１１】
インターネット上でのビデオなどのストリーミングの性能劣化の２つの主要な要因として、上述したネットワークの輻輳とリンク／ノード障害によるルーティングの不安定化が挙げられる。従来のインターネット上のストリーミングでは、パケット損失や遅延が観測されるとそれはネットワーク輻輳だけによるものと仮定し、これに応じてパケット送出レートを低減するという輻輳制御を行っていた。
【００１２】
しかしながら、最近の研究によれば、ネットワーク中のコアＩＰバックボーン内での輻輳の程度は通常は無視できるものであり、従ってストリーミングに代表される遅延が問題となるアプリケーションにとってはこの輻輳の影響はむしろ少ないということが見出された。
【００１３】
一方、リンク／ノード障害、つまり光ファイバの断線などによる通信リンクの切断などのリンクの障害やルータなどの機器の故障やルータ構成の異常などによるノードの障害は、ネットワークの日常的な運用に当たってごく普通に起こる事態であることがわかってきた。リンク／ノード障害後の再ルーティングは、単一のドメイン内でも数１０秒を要することがあり、ＢＧＰ（Border Gateway Protocol）を用いて行われるドメイン間ルート変更は、数分しないと収束しない場合がある。このルート収束までの過渡状態期間においては、パケットは誤った経路に入ってしまうことで失われたり、ルーティング・ループに入り込むことによって遅延時間が増大してしまうことがある。
【００１４】
現在提案されている、ネットワーク性能の劣化がリンク／ノード障害によるものであることに「気がつかない」レート適応型メディア・ストリーミング方式では、ネットワーク上でのパケットの損失や遅延が観測されるとそれはネットワーク輻輳によるものであると解釈して、既知の輻輳制御アルゴリズムを使用してパケット送出レートを低減するという輻輳制御を行ってしまう。観測されたネットワークの挙動の統計情報を誤って解釈することによる、このような輻輳制御を行うと、リアルタイムのビデオ・ストリーミングなどのストリーミング・データの送出レートを不必要に低下させ、その結果、再生品質を、何も対策を取らない場合に比べて更に劣化させてしまう。
【００１５】
ネットワーク上でのパケット損失が観測された場合、それがネットワーク輻輳ではなくリンク／ノード障害によるものであれば、そのようなパケット損失に対するより適切な対応は、パケット送出レートを維持するとともに、自動再送要求（automatic retransmission request, ARQ）及び／または誤り訂正（forward error protection, FEC）を用いてパケット保護を強化することである。すなわち、パケット損失の原因が上述の２つの要因のどちらであるかを識別して夫々適切な対策を取ることが、ストリーミング・データの再生結果の品質を維持するに当たって重要である。
【００１６】
この識別を行うために、例えば、ネットワーク・プロキシあるいは輻輳を検知するルータをネットワーク上に配置することで、ストリーミング・サーバあるいはクライアントにリンク／ノード障害が起こっているかもしれないということを通知する構成が考えられる。しかしながら、このようなネットワーク構成では実現に当たって高コストになる上に、スケーラブルでなくまたネットワーク全体に一挙に展開する必要があるため、既存のネットワークや大規模なネットワークに採用するには問題が大きい。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
上述した従来技術の問題点を解消し、ネットワーク性能の劣化が上述の２つの要因のいずれで起こっているかを簡単に識別してそれに適した対策を取ることが本発明の課題である。
【課題を解決するための手段】
【００１８】
上述の課題を達成するため、本発明においては、ストリーミング・サーバからネットワークを介してクライアントへストリーミングにより送出されたストリーム中で前記クライアントまたは前記ネットワーク上の所定のノードに到達するまでの間にバースト状のパケット損失が発生した場合にリンク／ノード障害が発生したと判定するネットワーク性能劣化原因判定方法が提供される。
【００１９】
この判定方法において、ストリーム中の連続した所定個数のパケットが失われた場合にバースト状のパケット損失が発生したと判定することができる。
また、この方法において、リンク／ノード障害の判定をネットワーク輻輳の判定に優先させることができる。
【００２０】
この判定方法において、更に、パケット損失率及び／またはランド・トリップ時間が増大した場合にネットワーク輻輳が発生したと判定することができる。
【００２１】
この判定方法において、更にまた、リンク／ノード障害が発生したと判定された後、ネットワークの性能に関する統計情報が安定化したと判定された場合に、リンク／ノード障害から回復したと判定することができる。
【００２２】
この判定方法において、更にまた、ネットワークの性能に関する統計情報はパケット損失率またはラウンド・トリップ時間を含むことができる。
【００２３】
この判定方法において、更にまた、ネットワークはＩＰネットワークとすることができる。
【００２４】
また、上述の課題を達成するため、ストリーミング・サーバからネットワークを介してクライアントへストリーミングにより送出されたストリーム中でクライアントまたはネットワーク上の所定のノードに到達するまでの間にバースト状のパケット損失が発生した場合にリンク／ノード障害が発生したと判定し、リンク／ノード障害が発生していない間にネットワーク輻輳が発生したと判定された場合には、ストリーミング・サーバからのストリームの送出レートを低下させる処理を実行し、リンク／ノード障害が発生したと判定された場合にはストリームの送出レートの低下を行わせる処理を実行しない輻輳制御方法を提供することができる。
【００２５】
この輻輳制御方法において、前記リンク／ノード障害が発生したと判定された場合には、前記ストリームのエラー回復能力を増大させる処理を行う、請求項８記載の輻輳制御方法。
【００２６】
この輻輳制御方法において、更に、エラー回復能力を増大させる処理は、エラー訂正コードの使用、通常使用するよりもエラー訂正能力の高いエラー訂正コードの使用、損失パケットの再送のいずれかとすることができる。
【００２７】
この輻輳制御方法において、更に、ストリーム中の連続した所定個数のパケットが失われた場合にバースト状のパケット損失が発生したと判定することができる。
【００２８】
この輻輳制御方法において、更にまた、パケット損失率及び／またはランド・トリップ時間が増大した場合にネットワーク輻輳が発生したと判定することができる。
【００２９】
この輻輳制御方法において、更にまた、リンク／ノード障害が発生したと判定された後、ネットワークの性能に関する統計情報が安定化したと判定された場合に、リンク／ノード障害から回復したと判定することができる。
【００３０】
この輻輳制御方法において、更にまた、ネットワークの性能に関する統計情報はパケット損失率またはラウンド・トリップ時間を含むことができる。
【発明の効果】
【００３１】
本発明を用いることにより、ネットワークの輻輳とリンク／ノード障害の何れが原因のパケット損失の増大に対しても、夫々を確実に識別することができる。また、当該識別された原因に適した対策を取ることで、ストリーミング・データの品質の劣化を最小限に抑えることができる。また、本発明は低コストで実現することができるとともに、規模の小さなネットワークから大規模なネットワークまで広い範囲に渡って適用することができる。さらに、本発明はネットワーク全体に一挙に適用する必要はなく、必要なあるいは可能なストリーミング・サーバから順次本発明を適用することができるので、既存のネットワークに本発明を適用することが容易になるという点で、実用化に当たって有利である。
【発明を実施するための最良の形態】
【００３２】
図１に示すようなネットワーク１００上のストリーミングを例として、本発明の一実施例を説明する。図１において、ストリーミング・サーバ１０１からクライアント１１１へストリーミングによりビデオ・データなどを送るものとする。ストリーミングによりネットワーク上をサーバ１０１からクライアント１１１へ送られるパケットはたとえば通信リンク（以下、単にリンクと称する）１０３、ルータなどのノード（以下、ルータと称する）１０５、リンク１０７、ルータ１０９、．．．、という経路を経由してクライアント１１１に到達する。
【００３３】
また、クライアント１１１はパケットを受信すると、それに対する確認応答を送信元のストリーミング・サーバ１０１へ返送する。なお、この確認応答はトランスポート層で行ってもよいし、それよりも上の層で行ってもよい。また、確認応答の形態はたとえば１つ１つのパケットの受信毎に返送するというものでもよいし、あるいは複数のパケットについてまとめて返送してもよい。さらにまた、あるシーケンス番号から連続してある個数のパケットを受け取った、あるいは受信されたストリーム中で連続してある個数のパケットが失われていた、などの、複数のパケットについて情報を整理した形態での返送を行ってもよい。いずれによせよ、後述のパケット損失の原因の解析とそれに対する対応が実用的に十分な時間応答性を持つことができるような形態であればよい。
【００３４】
なお、この確認応答を返送するのはストリーミングによるデータ転送のあて先であるクライアント１１１であってもよいし、あるいはネットワーク１００内の何らかの中継ノードであってもよい。例えば、これに限らないが、クライアント１１１が携帯電話などのモバイル端末であり、このモバイル端末がネットワーク１００に接続されている無線基地局（図示せず）と通信する場合には、ストリーミング・サーバ１０１と無線基地局の間の（通常は有線の）通信経路と無線基地局とモバイル端末間の無線通信経路とでは通信回線の性質・挙動が異なるので、有線通信経路と無線通信経路の夫々で別のエラー制御を行ったほうが効率的な場合がある。従って、このような構成では基地局からストリーミング・サーバ１０１へ確認応答を返すことができる。もちろん、基地局とモバイル端末の両方から確認応答を返してもよい。
【００３５】
確認応答には、上述のような、またそれ以外の点でも多様な実現形態があり得るが、本発明は確認応答のための構成・方法それ自体を主題とするものではないので、これ以上の説明は省略する。
【００３６】
次に、上述した形態でストリーミングを行う際に発生する可能性のあるパケット損失の２つの原因である、ネットワーク輻輳とリンク／ノード障害、及びそれぞれの原因によるパケット損失のパターンの違いを詳細に説明する。
【００３７】
典型的なネットワーク輻輳においては、パケットはネットワーク・ルータ中のパケット・キューで発生するオーバーフローによって失われる。今日のルータのほとんどは、パケット・キューで棄却するパケットを選択するアルゴリズムとしてＲＥＤ（Random Early Drop）とよばれるものを採用している。
【００３８】
図２を参照してＲＥＤを説明する。ネットワーク１００上の例えばルータ１０５には、よく知られているように、ルータ１０５に到着するパケットが適切なリンクに送り出されるまでの間蓄積しておくためのパケット・キュー（ＲＥＤキュー）２０１が設けられている。ＲＥＤキュー２０１の容量（最大長）をＨmaxとする。ストリーミング・サーバ１０１からクライアント１１１へのストリーム２０３に加えて、他のパケットのフロー２０５（これもストリームかもしれないし、あるいは他の形態のパケットのフローであるかもしれない）もルータ１０５を通り、これらがＲＥＤキュー２０１に流れ込んでいるとする。ここにおいて、現在ＲＥＤキュー２０１中に入っているパケット数ｈ(t)が容量Ｈmaxになるまで放置し、ＲＥＤキュー２０１が満杯になるとそれ以上のパケットを棄却するという制御を行うと、突然大量のパケットの棄却が始まってしまう可能性があるが、これではパケットのあて先側でネットワーク輻輳の「兆候」を検知して事前に適切な対策を取ることができないなどの不都合がある。そのため、ＲＥＤにおいては、ＲＥＤキュー２０１の容量よりも小さい警告レベルＨminを設定し、現在のパケット数ｈ(t)が警告レベルＨminを超えた場合には、ＲＥＤキュー２０１に新たに入来するパケットをＨmin - ｈ(t)に比例した確率でランダムに棄却する。ＲＥＤキュー２０１が満杯になろうとするにつれて、ＲＥＤキュー２０１に入来する全てのフローについてパケットがこのように徐々に棄却されるため、これらのフローのあて先で観測されるところのフロー中のパケット損失のパターンは不連続的、つまりフロー中で失われたパケットが飛び飛びに分布するパターンになる可能性が非常に高い。
【００３９】
ＲＥＤについての更に詳細な説明は以下の非特許文献３を参照されたい。
【非特許文献３】S. Floyd, V. Jacobson, "Random Early Detection Gateways for Congestion Avoidance," IEEE/ACM Transactions on Networking, vol.1 no.4, August 1993, p.397-413
【００４０】
仮に、ＲＥＤとは別のパケット棄却アルゴリズムを採用したとしても、ネットワーク輻輳の際にフロー中のパケットが連続して失われるような事態を回避することが一般に好ましいので、結局この場合でもネットワーク輻輳によって起こるパケット損失パターンはやはり不連続的になる可能性が非常に高くなるようなアルゴリズムが通常は採用されることになる。
【００４１】
一方、リンク／ノード障害では、ネットワークの性能劣化は以下の２つのステージを取る。
（１）遮断ステージ：先ず、障害の起こったリンクやノード上で伝送中であったりあるいは障害を検知して送り先を切り替えるまでの間にそこへ送り込まれた全てのパケットが失われる。
（２）ルーティング・ループ・ステージ：障害の起こったリンクやノードを回避するように他のノードで夫々ルーティング・テーブルを再構成する過程でこれらのルーティング・テーブル間の不適合により引き起こされるルーティング・ループにパケットが入ってしまうことがある。ルーティング・ループに入って余分なホップが追加されることでＴＴＬ（Time To Live、生存時間）が設定値を超えてしまったパケットは失われる。ルーティング・ループに入ったもののそこから抜け出してＴＴＬ内にあて先に到達することができたパケットも、その遅延は通常よりも大きくなる。
【００４２】
遮断ステージの期間は典型的にはほぼ１〜２秒程度である。つまり、クライアントからは、リンク／ノード障害の遮断ステージに対応して、１〜２秒程度の連続した、つまりバースト状のパケット損失が観測される。その後、各ノードにおいてルーティング・テーブルの再構成が行われるが、この過渡状態の間はリンク・ノード障害の発生前に比べてパケット損失率とパケット遅延時間が増大する可能性が高い。
【００４３】
上述のように、ネットワーク性能劣化の２つの原因による夫々のパケット損失パターンははっきりと異なるため、ストリーミング・セッションの間にパケット損失パターンを観測していれば、今観測されているネットワーク性能劣化がいずれの原因で起こっているかを識別することができる。
【００４４】
図３は図１のネットワークのストリーミング・サーバ１０１で行われる、ネットワーク輻輳・リンク／ノード障害制御の手順を示すフローチャートである。
【００４５】
図３のフローチャート中のブロック３０１において、ストリーミング・サーバ１０１がクライアント１１１へのストリームの送信を開始するに当たって、このストリームに関する過去Ｔ秒間のネットワーク統計情報を取り続けるという処理を開始する。ネットワーク統計情報とは、ここでは前述の式（１）を使って行われる標準的なネットワーク輻輳制御のためのパラメータとして使用される平均パケット損失率の平均値とラウンド・トリップ時間の平均値及び分散のことである。時間Ｔは、対象となるネットワークの性質や使用状況、またこれまでの統計データなどに基づいて、これらのパラメータが式（１）を用いて輻輳制御を行うために十分な安定性をもつとともに状況の変化に対応できる応答性を持つような値に設定される。ブロック３０１は更に輻輳制御を開始する。ここで開始される輻輳制御としては、例えば前述の式（１）に基づく輻輳制御であってよい。なお、輻輳制御開始当初においては、必要なパラメータの十分に正確な値は不明であることが多いが、このような場合は、例えば過去の同じようなストリーミング転送やネットワーク１００上で最近行われたストリーミング転送の際に得られたパラメータを初期値として使用することができる。
【００４６】
次に、ブロック３０３において、現在のネットワーク統計情報を退避する。
【００４７】
ストリームがサーバ１０１からクライアント１１１に送られている間、クライアント１１１からサーバにストリームを構成するパケットの到着に対する確認応答が返送され続ける。ブロック３０５において、この確認応答からｎ個以上の連続したパケット損失が検出されたか否か、つまりリンク／ノード障害が発生したかどうかが検査される。ｎ個以上の連続したパケット損失があったか否かを検査する具体的な方法としては、例えば、確認応答に受信したパケットのシーケンス番号を含めておくことで、一連の確認応答中の隣り合うシーケンス番号が（ｎ＋１）以上変化したことを検出すればよい。あるいはパケットを送り出してから一定時間以上それに対する確認応答が到着しない場合は当該パケットはクライアント１１１に到着しなかったと判断したり、あるいはクライアント１１１が次に到着すべきパケットを所定期間受信できなかった場合、当該パケットは失われたものとクライアント１１１が判断してそれが到着しなかったという応答をサーバに返すという、タイムアウトを考慮した処理を行うこともできる。また、連続したｎ個のパケット損失が起こったことをクライアント１１１側で検出してサーバ１０１にその結果を返送することもできる。なお、ｎは、対象となっている具体的なネットワークの性質やこれまでの統計データなどに基づいて、ネットワーク輻輳とリンク／ノード障害を必要とされる精度で識別できる値に設定すればよい。また、タイムアウト処理における所定時間も同様に設定することができる。また、完全に連続したパケット損失だけではなく、例えば連続した１０個のパケットのうちの９個が失われたというような、実質的に連続したパケット損失も連続したパケット損失として取り扱うこともできる。
【００４８】
ブロック３０５がｎ個以上の連続したパケット損失を確認すると、先ずブロック３０７において、先に退避しておいたネットワーク統計情報（ブロック３０３）を輻輳制御（ブロック３０１により開始）が現在のネットワーク統計情報の代わりに使用するように設定する。これにより、輻輳制御から見たネットワーク統計情報はリンク／ノード障害発生直前の状態に固定される。従って、リンク／ノード障害によるネットワーク性能の劣化が起こっている間、つまりブロック３０５の判断結果がＹＥＳになってからこの障害が回復するまで（ブロック３１１の説明を参照）の間は、ネットワーク輻輳制御を、直近のネットワーク統計情報ではなく、今回のリンク／ノード障害が発生する直前の統計情報に基づいて行われるようにしている。
【００４９】
次に、ブロック３０９で、ストリームの送出のために使用する帯域を維持したままでエラー訂正能力を向上させる処理を開始する。この処理としては、例えばエラー訂正コードを付加する、通常の状態で使用しているエラー訂正コードよりも訂正能力の高いエラー訂正コードに切り替える、損失パケットの再送を行うようにする、などがある。ルーティング・ループ・ステージの間のネットワーク性能の劣化は送出するストリームのレートを下げても改善されないが、ここで挙げたようなエラー訂正能力の向上処理を行うことで、この間にクライアントで受信されるストリームの品質が改善される。
【００５０】
なお、この処理に当たって、ストリームの送出にこれまで使用してきた帯域の一部をエラー訂正コードや再送パケット用に割り当てると、ストリーム中のビデオや音声などのデータそれ自体の帯域は減少する。この場合でもストリーム全体のために使用する帯域は維持されていると考える。また、状況が許すなら、データそれ自体が使用する帯域をそのまま維持し、エラー訂正用などに別途帯域を確保してもよい。
【００５１】
なお、ブロック３０９の処理は必ずしも必要ではない。つまりブロック３０９を省略したとしても、リンク／ノード障害をネットワーク輻輳によるものと誤認してストリームの送出レートを下げてしまうという不適切な処理を行うためにルーティング・ループ・ステージの間に受信ストリーム品質を何も処理をしない場合に比べても更に低下させてしまう、という従来技術の欠点は解消される。
【００５２】
次にブロック３１１において、リンク／ノード障害から回復したか否かを判定する。具体的には、ネットワーク統計情報の最近の値が安定化してきたか否か（つまり値の変化が小さくなり、障害発生前と同じである必要はないが定常値に収束してきたか否か）を判定し、安定化してきたと判断された場合にはルーティング・ループ・ステージの終了、つまりリンク・ノード障害状態から回復したと判定する。ネットワーク統計情報が安定化してきたか否かの判定は、より具体的には、例えばパケット損失率とラウンド・トリップ時間の分散がそれぞれの平均の所定倍以内に収束したかどうかを検査することによって行うことができる。
【００５３】
ブロック３１１においてリンク／ノード障害から回復したと判定された場合には、ブロック３１３においてエラー訂正能力の向上処理（ブロック３０９により開始）を終了させるとともに、退避されていたネットワーク統計情報の代わりに現在のネットワーク統計情報が輻輳制御に供給されるように設定して、ブロック３０３に戻る。
【００５４】
なお、ブロック３０５においてｎ個以上の連続したパケット損失が検出されなかった場合には制御は３０３に戻り、輻輳処理は現在のネットワーク統計情報を使用し続ける。従って、リンク／ノード障害ではなくネットワーク輻輳によってネットワーク性能が低下すると、それに応答して輻輳制御がストリームの送出レートを低下させるという適切な対応が取られる。
【００５５】
以上説明したように、本発明によれば、ネットワーク性能が劣化した場合にその原因を簡単な構成・手順で判別してそれに応じた対応を取ることで、ストリーミング品質の低下を最小限に抑えることができる。
【産業上の利用可能性】
【００５６】
従って、本発明をネットワーク上のストリーミングにおける輻輳制御に適用することは大いに有益である。
【図面の簡単な説明】
【００５７】
【図１】本発明が適用されるネットワークを説明する図。
【図２】本発明が適用されるネットワークを説明する図。
【図３】本発明の一実施例を説明するフローチャート。
【符号の説明】
【００５８】
１００：ネットワーク
１０１：ストリーミング・サーバ
１０３：リンク
１０５：ルータ
１０７：リンク
１０９：ルータ
１１１：クライアント
２０１：ＲＥＤキュー
２０３：ストリーム
２０５：フロー
２０７：パケット
２０９：パケット
【技術分野】
【０００１】
本発明はストリーミングに関し、特にネットワーク性能の劣化の原因の判定及び判定された原因に基づいた輻輳制御に関する。
【背景技術】
【０００２】
ＩＰネットワークを介して音声、ビデオを含むいわゆるマルチメディアなどの時間軸方向に継続するデータをストリーミング方式で送ることはよく知られており、またこのようなサービスは既にインターネット上で多数提供されている。
【０００３】
ストリーミングを行うにあたって、ＩＰネットワークのトランスポート・プロトコルは、対応するパケット・ストリームの送出レートを、当該パケット・ストリームがネットワークを介してあて先に到達するまでの間に出会うトラフィックに従って規制しなければならない。このトラフィックが増大するにつれて、トランスポート・プロトコルはパケット・ストリームの送出レートを低下させなければならない。これにより、パケット・ストリームの転送経路における限られたネットワーク資源を同時に使おうとして競合するユーザ間でのある程度の公平性が維持される。このようなレート低減手順は一般に輻輳制御と呼ばれる。
【０００４】
広く使われているデータ・トランスポート・プロトコルであるＴＣＰでは、輻輳制御はパケット損失率やラウンド・トリップ時間（Round Trip Time, RTT）などの端点間の統計に基いて行われ、更に、パケットが厳密に正しい順序で到達するようにするためパケットの再送は必ず行われる。
【０００５】
メディア・ストリーミングではＴＣＰはトランスポート・プロトコルとしては不適切である。それは、必ずパケット再送を行うということは、パケットの滞留が起きる可能性があり、その結果、パケットが連続再生を行うための所要時間内にクライアントに到達しなくなるかもしれないことを意味するからである。
【０００６】
しかしながら、メディア・ストリーミング・サーバがどのようなトランスポート・プロトコルを採用したとしても、そのようなトランスポート・プロトコルは大量のＴＣＰトラフィックに対して公平性を持っている必要がある。つまり、そのようなトランスポート・プロトコルは、同じネットワーク条件下でのＴＣＰ接続よりも広い帯域を占有することはないという意味でＴＣＰ親和性がなければならない。ＴＣＰ親和性を有するトランスポート・プロトコルの例としては、送出するパケットとパケットの間に、よく知られているＴＣＰ親和性輻輳制御方程式（１）に従って間隔Ｔを開けるというものがある。
【０００７】
【数１】
【０００８】
上式中、εR、μR、σR2は夫々、サーバからクライアントまでのパケット損失率、及びサーバとクライアント間のラウンド・トリップ時間の平均、分散の推定値を表す。なお、式（１）については以下の非特許文献１に詳細が説明されている。
【非特許文献１】S. Floyd, M. Handley, J. Padhye, and J. Widmer, "Equation-based congestion control for unicast applications" ACM SIGCOMM, 2000
【０００９】
しかしながら、以下の非特許文献２に示されるように、インターネットの性能の劣化はネットワーク輻輳ではなくリンク／ノード障害によって起こり得ることがわかってきた。リンク／ノード障害の場合には、限られたネットワーク資源を取り合うユーザが存在するわけではないので、ストリーミング・サーバは、競合するユーザ間の公平性のために送出レートを低減する代わりに、リンク／ノード障害によるバケット損失と遅延の増大に対処するため、メディア・ストリーム・エラーへの耐性を向上させることに注力する必要がある。
【非特許文献２】G. Iannaccone, C.-N. Chuah, R. Mortier, S. Bhattacharyya, and C. Diot, "Analysis of Link Failures in an IP Backbone," ACM SIGCOMM Internet Measurement Workshop, November, 2002
【００１０】
上述のインターネットの性能劣化の２つの要因とそれに対する従来技術における解決策を以下で更に説明する。
【００１１】
インターネット上でのビデオなどのストリーミングの性能劣化の２つの主要な要因として、上述したネットワークの輻輳とリンク／ノード障害によるルーティングの不安定化が挙げられる。従来のインターネット上のストリーミングでは、パケット損失や遅延が観測されるとそれはネットワーク輻輳だけによるものと仮定し、これに応じてパケット送出レートを低減するという輻輳制御を行っていた。
【００１２】
しかしながら、最近の研究によれば、ネットワーク中のコアＩＰバックボーン内での輻輳の程度は通常は無視できるものであり、従ってストリーミングに代表される遅延が問題となるアプリケーションにとってはこの輻輳の影響はむしろ少ないということが見出された。
【００１３】
一方、リンク／ノード障害、つまり光ファイバの断線などによる通信リンクの切断などのリンクの障害やルータなどの機器の故障やルータ構成の異常などによるノードの障害は、ネットワークの日常的な運用に当たってごく普通に起こる事態であることがわかってきた。リンク／ノード障害後の再ルーティングは、単一のドメイン内でも数１０秒を要することがあり、ＢＧＰ（Border Gateway Protocol）を用いて行われるドメイン間ルート変更は、数分しないと収束しない場合がある。このルート収束までの過渡状態期間においては、パケットは誤った経路に入ってしまうことで失われたり、ルーティング・ループに入り込むことによって遅延時間が増大してしまうことがある。
【００１４】
現在提案されている、ネットワーク性能の劣化がリンク／ノード障害によるものであることに「気がつかない」レート適応型メディア・ストリーミング方式では、ネットワーク上でのパケットの損失や遅延が観測されるとそれはネットワーク輻輳によるものであると解釈して、既知の輻輳制御アルゴリズムを使用してパケット送出レートを低減するという輻輳制御を行ってしまう。観測されたネットワークの挙動の統計情報を誤って解釈することによる、このような輻輳制御を行うと、リアルタイムのビデオ・ストリーミングなどのストリーミング・データの送出レートを不必要に低下させ、その結果、再生品質を、何も対策を取らない場合に比べて更に劣化させてしまう。
【００１５】
ネットワーク上でのパケット損失が観測された場合、それがネットワーク輻輳ではなくリンク／ノード障害によるものであれば、そのようなパケット損失に対するより適切な対応は、パケット送出レートを維持するとともに、自動再送要求（automatic retransmission request, ARQ）及び／または誤り訂正（forward error protection, FEC）を用いてパケット保護を強化することである。すなわち、パケット損失の原因が上述の２つの要因のどちらであるかを識別して夫々適切な対策を取ることが、ストリーミング・データの再生結果の品質を維持するに当たって重要である。
【００１６】
この識別を行うために、例えば、ネットワーク・プロキシあるいは輻輳を検知するルータをネットワーク上に配置することで、ストリーミング・サーバあるいはクライアントにリンク／ノード障害が起こっているかもしれないということを通知する構成が考えられる。しかしながら、このようなネットワーク構成では実現に当たって高コストになる上に、スケーラブルでなくまたネットワーク全体に一挙に展開する必要があるため、既存のネットワークや大規模なネットワークに採用するには問題が大きい。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
上述した従来技術の問題点を解消し、ネットワーク性能の劣化が上述の２つの要因のいずれで起こっているかを簡単に識別してそれに適した対策を取ることが本発明の課題である。
【課題を解決するための手段】
【００１８】
上述の課題を達成するため、本発明においては、ストリーミング・サーバからネットワークを介してクライアントへストリーミングにより送出されたストリーム中で前記クライアントまたは前記ネットワーク上の所定のノードに到達するまでの間にバースト状のパケット損失が発生した場合にリンク／ノード障害が発生したと判定するネットワーク性能劣化原因判定方法が提供される。
【００１９】
この判定方法において、ストリーム中の連続した所定個数のパケットが失われた場合にバースト状のパケット損失が発生したと判定することができる。
また、この方法において、リンク／ノード障害の判定をネットワーク輻輳の判定に優先させることができる。
【００２０】
この判定方法において、更に、パケット損失率及び／またはランド・トリップ時間が増大した場合にネットワーク輻輳が発生したと判定することができる。
【００２１】
この判定方法において、更にまた、リンク／ノード障害が発生したと判定された後、ネットワークの性能に関する統計情報が安定化したと判定された場合に、リンク／ノード障害から回復したと判定することができる。
【００２２】
この判定方法において、更にまた、ネットワークの性能に関する統計情報はパケット損失率またはラウンド・トリップ時間を含むことができる。
【００２３】
この判定方法において、更にまた、ネットワークはＩＰネットワークとすることができる。
【００２４】
また、上述の課題を達成するため、ストリーミング・サーバからネットワークを介してクライアントへストリーミングにより送出されたストリーム中でクライアントまたはネットワーク上の所定のノードに到達するまでの間にバースト状のパケット損失が発生した場合にリンク／ノード障害が発生したと判定し、リンク／ノード障害が発生していない間にネットワーク輻輳が発生したと判定された場合には、ストリーミング・サーバからのストリームの送出レートを低下させる処理を実行し、リンク／ノード障害が発生したと判定された場合にはストリームの送出レートの低下を行わせる処理を実行しない輻輳制御方法を提供することができる。
【００２５】
この輻輳制御方法において、前記リンク／ノード障害が発生したと判定された場合には、前記ストリームのエラー回復能力を増大させる処理を行う、請求項８記載の輻輳制御方法。
【００２６】
この輻輳制御方法において、更に、エラー回復能力を増大させる処理は、エラー訂正コードの使用、通常使用するよりもエラー訂正能力の高いエラー訂正コードの使用、損失パケットの再送のいずれかとすることができる。
【００２７】
この輻輳制御方法において、更に、ストリーム中の連続した所定個数のパケットが失われた場合にバースト状のパケット損失が発生したと判定することができる。
【００２８】
この輻輳制御方法において、更にまた、パケット損失率及び／またはランド・トリップ時間が増大した場合にネットワーク輻輳が発生したと判定することができる。
【００２９】
この輻輳制御方法において、更にまた、リンク／ノード障害が発生したと判定された後、ネットワークの性能に関する統計情報が安定化したと判定された場合に、リンク／ノード障害から回復したと判定することができる。
【００３０】
この輻輳制御方法において、更にまた、ネットワークの性能に関する統計情報はパケット損失率またはラウンド・トリップ時間を含むことができる。
【発明の効果】
【００３１】
本発明を用いることにより、ネットワークの輻輳とリンク／ノード障害の何れが原因のパケット損失の増大に対しても、夫々を確実に識別することができる。また、当該識別された原因に適した対策を取ることで、ストリーミング・データの品質の劣化を最小限に抑えることができる。また、本発明は低コストで実現することができるとともに、規模の小さなネットワークから大規模なネットワークまで広い範囲に渡って適用することができる。さらに、本発明はネットワーク全体に一挙に適用する必要はなく、必要なあるいは可能なストリーミング・サーバから順次本発明を適用することができるので、既存のネットワークに本発明を適用することが容易になるという点で、実用化に当たって有利である。
【発明を実施するための最良の形態】
【００３２】
図１に示すようなネットワーク１００上のストリーミングを例として、本発明の一実施例を説明する。図１において、ストリーミング・サーバ１０１からクライアント１１１へストリーミングによりビデオ・データなどを送るものとする。ストリーミングによりネットワーク上をサーバ１０１からクライアント１１１へ送られるパケットはたとえば通信リンク（以下、単にリンクと称する）１０３、ルータなどのノード（以下、ルータと称する）１０５、リンク１０７、ルータ１０９、．．．、という経路を経由してクライアント１１１に到達する。
【００３３】
また、クライアント１１１はパケットを受信すると、それに対する確認応答を送信元のストリーミング・サーバ１０１へ返送する。なお、この確認応答はトランスポート層で行ってもよいし、それよりも上の層で行ってもよい。また、確認応答の形態はたとえば１つ１つのパケットの受信毎に返送するというものでもよいし、あるいは複数のパケットについてまとめて返送してもよい。さらにまた、あるシーケンス番号から連続してある個数のパケットを受け取った、あるいは受信されたストリーム中で連続してある個数のパケットが失われていた、などの、複数のパケットについて情報を整理した形態での返送を行ってもよい。いずれによせよ、後述のパケット損失の原因の解析とそれに対する対応が実用的に十分な時間応答性を持つことができるような形態であればよい。
【００３４】
なお、この確認応答を返送するのはストリーミングによるデータ転送のあて先であるクライアント１１１であってもよいし、あるいはネットワーク１００内の何らかの中継ノードであってもよい。例えば、これに限らないが、クライアント１１１が携帯電話などのモバイル端末であり、このモバイル端末がネットワーク１００に接続されている無線基地局（図示せず）と通信する場合には、ストリーミング・サーバ１０１と無線基地局の間の（通常は有線の）通信経路と無線基地局とモバイル端末間の無線通信経路とでは通信回線の性質・挙動が異なるので、有線通信経路と無線通信経路の夫々で別のエラー制御を行ったほうが効率的な場合がある。従って、このような構成では基地局からストリーミング・サーバ１０１へ確認応答を返すことができる。もちろん、基地局とモバイル端末の両方から確認応答を返してもよい。
【００３５】
確認応答には、上述のような、またそれ以外の点でも多様な実現形態があり得るが、本発明は確認応答のための構成・方法それ自体を主題とするものではないので、これ以上の説明は省略する。
【００３６】
次に、上述した形態でストリーミングを行う際に発生する可能性のあるパケット損失の２つの原因である、ネットワーク輻輳とリンク／ノード障害、及びそれぞれの原因によるパケット損失のパターンの違いを詳細に説明する。
【００３７】
典型的なネットワーク輻輳においては、パケットはネットワーク・ルータ中のパケット・キューで発生するオーバーフローによって失われる。今日のルータのほとんどは、パケット・キューで棄却するパケットを選択するアルゴリズムとしてＲＥＤ（Random Early Drop）とよばれるものを採用している。
【００３８】
図２を参照してＲＥＤを説明する。ネットワーク１００上の例えばルータ１０５には、よく知られているように、ルータ１０５に到着するパケットが適切なリンクに送り出されるまでの間蓄積しておくためのパケット・キュー（ＲＥＤキュー）２０１が設けられている。ＲＥＤキュー２０１の容量（最大長）をＨmaxとする。ストリーミング・サーバ１０１からクライアント１１１へのストリーム２０３に加えて、他のパケットのフロー２０５（これもストリームかもしれないし、あるいは他の形態のパケットのフローであるかもしれない）もルータ１０５を通り、これらがＲＥＤキュー２０１に流れ込んでいるとする。ここにおいて、現在ＲＥＤキュー２０１中に入っているパケット数ｈ(t)が容量Ｈmaxになるまで放置し、ＲＥＤキュー２０１が満杯になるとそれ以上のパケットを棄却するという制御を行うと、突然大量のパケットの棄却が始まってしまう可能性があるが、これではパケットのあて先側でネットワーク輻輳の「兆候」を検知して事前に適切な対策を取ることができないなどの不都合がある。そのため、ＲＥＤにおいては、ＲＥＤキュー２０１の容量よりも小さい警告レベルＨminを設定し、現在のパケット数ｈ(t)が警告レベルＨminを超えた場合には、ＲＥＤキュー２０１に新たに入来するパケットをＨmin - ｈ(t)に比例した確率でランダムに棄却する。ＲＥＤキュー２０１が満杯になろうとするにつれて、ＲＥＤキュー２０１に入来する全てのフローについてパケットがこのように徐々に棄却されるため、これらのフローのあて先で観測されるところのフロー中のパケット損失のパターンは不連続的、つまりフロー中で失われたパケットが飛び飛びに分布するパターンになる可能性が非常に高い。
【００３９】
ＲＥＤについての更に詳細な説明は以下の非特許文献３を参照されたい。
【非特許文献３】S. Floyd, V. Jacobson, "Random Early Detection Gateways for Congestion Avoidance," IEEE/ACM Transactions on Networking, vol.1 no.4, August 1993, p.397-413
【００４０】
仮に、ＲＥＤとは別のパケット棄却アルゴリズムを採用したとしても、ネットワーク輻輳の際にフロー中のパケットが連続して失われるような事態を回避することが一般に好ましいので、結局この場合でもネットワーク輻輳によって起こるパケット損失パターンはやはり不連続的になる可能性が非常に高くなるようなアルゴリズムが通常は採用されることになる。
【００４１】
一方、リンク／ノード障害では、ネットワークの性能劣化は以下の２つのステージを取る。
（１）遮断ステージ：先ず、障害の起こったリンクやノード上で伝送中であったりあるいは障害を検知して送り先を切り替えるまでの間にそこへ送り込まれた全てのパケットが失われる。
（２）ルーティング・ループ・ステージ：障害の起こったリンクやノードを回避するように他のノードで夫々ルーティング・テーブルを再構成する過程でこれらのルーティング・テーブル間の不適合により引き起こされるルーティング・ループにパケットが入ってしまうことがある。ルーティング・ループに入って余分なホップが追加されることでＴＴＬ（Time To Live、生存時間）が設定値を超えてしまったパケットは失われる。ルーティング・ループに入ったもののそこから抜け出してＴＴＬ内にあて先に到達することができたパケットも、その遅延は通常よりも大きくなる。
【００４２】
遮断ステージの期間は典型的にはほぼ１〜２秒程度である。つまり、クライアントからは、リンク／ノード障害の遮断ステージに対応して、１〜２秒程度の連続した、つまりバースト状のパケット損失が観測される。その後、各ノードにおいてルーティング・テーブルの再構成が行われるが、この過渡状態の間はリンク・ノード障害の発生前に比べてパケット損失率とパケット遅延時間が増大する可能性が高い。
【００４３】
上述のように、ネットワーク性能劣化の２つの原因による夫々のパケット損失パターンははっきりと異なるため、ストリーミング・セッションの間にパケット損失パターンを観測していれば、今観測されているネットワーク性能劣化がいずれの原因で起こっているかを識別することができる。
【００４４】
図３は図１のネットワークのストリーミング・サーバ１０１で行われる、ネットワーク輻輳・リンク／ノード障害制御の手順を示すフローチャートである。
【００４５】
図３のフローチャート中のブロック３０１において、ストリーミング・サーバ１０１がクライアント１１１へのストリームの送信を開始するに当たって、このストリームに関する過去Ｔ秒間のネットワーク統計情報を取り続けるという処理を開始する。ネットワーク統計情報とは、ここでは前述の式（１）を使って行われる標準的なネットワーク輻輳制御のためのパラメータとして使用される平均パケット損失率の平均値とラウンド・トリップ時間の平均値及び分散のことである。時間Ｔは、対象となるネットワークの性質や使用状況、またこれまでの統計データなどに基づいて、これらのパラメータが式（１）を用いて輻輳制御を行うために十分な安定性をもつとともに状況の変化に対応できる応答性を持つような値に設定される。ブロック３０１は更に輻輳制御を開始する。ここで開始される輻輳制御としては、例えば前述の式（１）に基づく輻輳制御であってよい。なお、輻輳制御開始当初においては、必要なパラメータの十分に正確な値は不明であることが多いが、このような場合は、例えば過去の同じようなストリーミング転送やネットワーク１００上で最近行われたストリーミング転送の際に得られたパラメータを初期値として使用することができる。
【００４６】
次に、ブロック３０３において、現在のネットワーク統計情報を退避する。
【００４７】
ストリームがサーバ１０１からクライアント１１１に送られている間、クライアント１１１からサーバにストリームを構成するパケットの到着に対する確認応答が返送され続ける。ブロック３０５において、この確認応答からｎ個以上の連続したパケット損失が検出されたか否か、つまりリンク／ノード障害が発生したかどうかが検査される。ｎ個以上の連続したパケット損失があったか否かを検査する具体的な方法としては、例えば、確認応答に受信したパケットのシーケンス番号を含めておくことで、一連の確認応答中の隣り合うシーケンス番号が（ｎ＋１）以上変化したことを検出すればよい。あるいはパケットを送り出してから一定時間以上それに対する確認応答が到着しない場合は当該パケットはクライアント１１１に到着しなかったと判断したり、あるいはクライアント１１１が次に到着すべきパケットを所定期間受信できなかった場合、当該パケットは失われたものとクライアント１１１が判断してそれが到着しなかったという応答をサーバに返すという、タイムアウトを考慮した処理を行うこともできる。また、連続したｎ個のパケット損失が起こったことをクライアント１１１側で検出してサーバ１０１にその結果を返送することもできる。なお、ｎは、対象となっている具体的なネットワークの性質やこれまでの統計データなどに基づいて、ネットワーク輻輳とリンク／ノード障害を必要とされる精度で識別できる値に設定すればよい。また、タイムアウト処理における所定時間も同様に設定することができる。また、完全に連続したパケット損失だけではなく、例えば連続した１０個のパケットのうちの９個が失われたというような、実質的に連続したパケット損失も連続したパケット損失として取り扱うこともできる。
【００４８】
ブロック３０５がｎ個以上の連続したパケット損失を確認すると、先ずブロック３０７において、先に退避しておいたネットワーク統計情報（ブロック３０３）を輻輳制御（ブロック３０１により開始）が現在のネットワーク統計情報の代わりに使用するように設定する。これにより、輻輳制御から見たネットワーク統計情報はリンク／ノード障害発生直前の状態に固定される。従って、リンク／ノード障害によるネットワーク性能の劣化が起こっている間、つまりブロック３０５の判断結果がＹＥＳになってからこの障害が回復するまで（ブロック３１１の説明を参照）の間は、ネットワーク輻輳制御を、直近のネットワーク統計情報ではなく、今回のリンク／ノード障害が発生する直前の統計情報に基づいて行われるようにしている。
【００４９】
次に、ブロック３０９で、ストリームの送出のために使用する帯域を維持したままでエラー訂正能力を向上させる処理を開始する。この処理としては、例えばエラー訂正コードを付加する、通常の状態で使用しているエラー訂正コードよりも訂正能力の高いエラー訂正コードに切り替える、損失パケットの再送を行うようにする、などがある。ルーティング・ループ・ステージの間のネットワーク性能の劣化は送出するストリームのレートを下げても改善されないが、ここで挙げたようなエラー訂正能力の向上処理を行うことで、この間にクライアントで受信されるストリームの品質が改善される。
【００５０】
なお、この処理に当たって、ストリームの送出にこれまで使用してきた帯域の一部をエラー訂正コードや再送パケット用に割り当てると、ストリーム中のビデオや音声などのデータそれ自体の帯域は減少する。この場合でもストリーム全体のために使用する帯域は維持されていると考える。また、状況が許すなら、データそれ自体が使用する帯域をそのまま維持し、エラー訂正用などに別途帯域を確保してもよい。
【００５１】
なお、ブロック３０９の処理は必ずしも必要ではない。つまりブロック３０９を省略したとしても、リンク／ノード障害をネットワーク輻輳によるものと誤認してストリームの送出レートを下げてしまうという不適切な処理を行うためにルーティング・ループ・ステージの間に受信ストリーム品質を何も処理をしない場合に比べても更に低下させてしまう、という従来技術の欠点は解消される。
【００５２】
次にブロック３１１において、リンク／ノード障害から回復したか否かを判定する。具体的には、ネットワーク統計情報の最近の値が安定化してきたか否か（つまり値の変化が小さくなり、障害発生前と同じである必要はないが定常値に収束してきたか否か）を判定し、安定化してきたと判断された場合にはルーティング・ループ・ステージの終了、つまりリンク・ノード障害状態から回復したと判定する。ネットワーク統計情報が安定化してきたか否かの判定は、より具体的には、例えばパケット損失率とラウンド・トリップ時間の分散がそれぞれの平均の所定倍以内に収束したかどうかを検査することによって行うことができる。
【００５３】
ブロック３１１においてリンク／ノード障害から回復したと判定された場合には、ブロック３１３においてエラー訂正能力の向上処理（ブロック３０９により開始）を終了させるとともに、退避されていたネットワーク統計情報の代わりに現在のネットワーク統計情報が輻輳制御に供給されるように設定して、ブロック３０３に戻る。
【００５４】
なお、ブロック３０５においてｎ個以上の連続したパケット損失が検出されなかった場合には制御は３０３に戻り、輻輳処理は現在のネットワーク統計情報を使用し続ける。従って、リンク／ノード障害ではなくネットワーク輻輳によってネットワーク性能が低下すると、それに応答して輻輳制御がストリームの送出レートを低下させるという適切な対応が取られる。
【００５５】
以上説明したように、本発明によれば、ネットワーク性能が劣化した場合にその原因を簡単な構成・手順で判別してそれに応じた対応を取ることで、ストリーミング品質の低下を最小限に抑えることができる。
【産業上の利用可能性】
【００５６】
従って、本発明をネットワーク上のストリーミングにおける輻輳制御に適用することは大いに有益である。
【図面の簡単な説明】
【００５７】
【図１】本発明が適用されるネットワークを説明する図。
【図２】本発明が適用されるネットワークを説明する図。
【図３】本発明の一実施例を説明するフローチャート。
【符号の説明】
【００５８】
１００：ネットワーク
１０１：ストリーミング・サーバ
１０３：リンク
１０５：ルータ
１０７：リンク
１０９：ルータ
１１１：クライアント
２０１：ＲＥＤキュー
２０３：ストリーム
２０５：フロー
２０７：パケット
２０９：パケット
【特許請求の範囲】
【請求項１】
ストリーミング・サーバからネットワークを介してクライアントへストリーミングにより送出されたストリーム中で前記クライアントまたは前記ネットワーク上の所定のノードに到達するまでの間にバースト状のパケット損失が発生した場合にリンク／ノード障害が発生したと判定するネットワーク性能劣化原因判定方法。
【請求項２】
前記ストリーム中の連続した所定個数のパケットが失われた場合に前記バースト状のパケット損失が発生したと判定する、請求項１のネットワーク性能劣化原因判定方法。
【請求項３】
前記リンク／ノード障害の判定をネットワーク輻輳の判定に優先させる、請求項１または２記載のネットワーク性能劣化原因判定方法。
【請求項４】
パケット損失率及び／またはランド・トリップ時間が増大した場合に前記ネットワーク輻輳が発生したと判定する、請求項３記載のネットワーク性能劣化原因判定方法。
【請求項５】
前記リンク／ノード障害が発生したと判定された後、前記ネットワークの性能に関する統計情報が安定化したと判定された場合に、前記リンク／ノード障害から回復したと判定する、請求項１から４のいずれかに記載のネットワーク性能劣化原因判定方法。
【請求項６】
前記ネットワークの性能に関する統計情報はパケット損失率またはラウンド・トリップ時間を含む、請求項５記載のネットワーク性能劣化原因判定方法。
【請求項７】
前記ネットワークはＩＰネットワークであることを特徴とする、請求項１から６のいずれかに記載のネットワーク性能劣化原因判定方法。
【請求項８】
ストリーミング・サーバからネットワークを介してクライアントへストリーミングにより送出されたストリーム中で前記クライアントまたは前記ネットワーク上の所定のノードに到達するまでの間にバースト状のパケット損失が発生した場合にリンク／ノード障害が発生したと判定し、
前記リンク／ノード障害が発生していない間にネットワーク輻輳が発生したと判定された場合には、前記ストリーミング・サーバからの前記ストリームの送出レートを低下させる処理を実行し、
前記リンク／ノード障害が発生したと判定された場合には前記ストリームの送出レートの低下を行わせる処理を実行しない
輻輳制御方法。
【請求項９】
前記リンク／ノード障害が発生したと判定された場合には、前記ストリームのエラー回復能力を増大させる処理を行う、請求項８記載の輻輳制御方法。
【請求項１０】
前記エラー回復能力を増大させる処理は、エラー訂正コードの使用、通常使用するよりもエラー訂正能力の高いエラー訂正コードの使用、損失パケットの再送のいずれかである、請求項７記載の輻輳制御方法。
【請求項１１】
前記ストリーム中の連続した所定個数のパケットが失われた場合に前記バースト状のパケット損失が発生したと判定する、請求項８から１０のいずれかに記載の輻輳制御方法。
【請求項１２】
パケット損失率及び／またはランド・トリップ時間が増大した場合に前記ネットワーク輻輳が発生したと判定する、請求項８から１１のいずれかに記載の輻輳制御方法。
【請求項１３】
前記リンク／ノード障害が発生したと判定された後、前記ネットワークの性能に関する統計情報が安定化したと判定された場合に、前記リンク／ノード障害から回復したと判定する、請求項８から１２のいずれかに記載の輻輳制御方法。
【請求項１４】
前記ネットワークの性能に関する統計情報はパケット損失率またはラウンド・トリップ時間を含む、請求項１３記載の輻輳制御方法。
【請求項１】
ストリーミング・サーバからネットワークを介してクライアントへストリーミングにより送出されたストリーム中で前記クライアントまたは前記ネットワーク上の所定のノードに到達するまでの間にバースト状のパケット損失が発生した場合にリンク／ノード障害が発生したと判定するネットワーク性能劣化原因判定方法。
【請求項２】
前記ストリーム中の連続した所定個数のパケットが失われた場合に前記バースト状のパケット損失が発生したと判定する、請求項１のネットワーク性能劣化原因判定方法。
【請求項３】
前記リンク／ノード障害の判定をネットワーク輻輳の判定に優先させる、請求項１または２記載のネットワーク性能劣化原因判定方法。
【請求項４】
パケット損失率及び／またはランド・トリップ時間が増大した場合に前記ネットワーク輻輳が発生したと判定する、請求項３記載のネットワーク性能劣化原因判定方法。
【請求項５】
前記リンク／ノード障害が発生したと判定された後、前記ネットワークの性能に関する統計情報が安定化したと判定された場合に、前記リンク／ノード障害から回復したと判定する、請求項１から４のいずれかに記載のネットワーク性能劣化原因判定方法。
【請求項６】
前記ネットワークの性能に関する統計情報はパケット損失率またはラウンド・トリップ時間を含む、請求項５記載のネットワーク性能劣化原因判定方法。
【請求項７】
前記ネットワークはＩＰネットワークであることを特徴とする、請求項１から６のいずれかに記載のネットワーク性能劣化原因判定方法。
【請求項８】
ストリーミング・サーバからネットワークを介してクライアントへストリーミングにより送出されたストリーム中で前記クライアントまたは前記ネットワーク上の所定のノードに到達するまでの間にバースト状のパケット損失が発生した場合にリンク／ノード障害が発生したと判定し、
前記リンク／ノード障害が発生していない間にネットワーク輻輳が発生したと判定された場合には、前記ストリーミング・サーバからの前記ストリームの送出レートを低下させる処理を実行し、
前記リンク／ノード障害が発生したと判定された場合には前記ストリームの送出レートの低下を行わせる処理を実行しない
輻輳制御方法。
【請求項９】
前記リンク／ノード障害が発生したと判定された場合には、前記ストリームのエラー回復能力を増大させる処理を行う、請求項８記載の輻輳制御方法。
【請求項１０】
前記エラー回復能力を増大させる処理は、エラー訂正コードの使用、通常使用するよりもエラー訂正能力の高いエラー訂正コードの使用、損失パケットの再送のいずれかである、請求項７記載の輻輳制御方法。
【請求項１１】
前記ストリーム中の連続した所定個数のパケットが失われた場合に前記バースト状のパケット損失が発生したと判定する、請求項８から１０のいずれかに記載の輻輳制御方法。
【請求項１２】
パケット損失率及び／またはランド・トリップ時間が増大した場合に前記ネットワーク輻輳が発生したと判定する、請求項８から１１のいずれかに記載の輻輳制御方法。
【請求項１３】
前記リンク／ノード障害が発生したと判定された後、前記ネットワークの性能に関する統計情報が安定化したと判定された場合に、前記リンク／ノード障害から回復したと判定する、請求項８から１２のいずれかに記載の輻輳制御方法。
【請求項１４】
前記ネットワークの性能に関する統計情報はパケット損失率またはラウンド・トリップ時間を含む、請求項１３記載の輻輳制御方法。
【図１】
【図２】
【図３】
【図２】
【図３】
【公開番号】特開２００６−５７７５（Ｐ２００６−５７７５Ａ）
【公開日】平成１８年１月５日（２００６．１．５）
【国際特許分類】
【出願番号】特願２００４−１８１５９８（Ｐ２００４−１８１５９８）
【出願日】平成１６年６月１８日（２００４．６．１８）
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
【公開日】平成１８年１月５日（２００６．１．５）
【国際特許分類】
【出願日】平成１６年６月１８日（２００４．６．１８）
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
[ Back to top ]