JP4662445B2 - ストリーミングサービス管理プログラム及び方法 - Google Patents

Description

本発明はストリーミングサービス管理システムに関し、特に映像配信サービスにおける付加サービスとその方法であり、特に映像配信サービスの障害管理に適したサービスに関する。

近年、ブロードバンドネットワークの普及に伴い、スポーツ中継やコンサート等の映像配信サービスが広がりつつある。映像配信システムは、通常ユーザに映像を見せる表示クライアントと、映像を送出する配信サーバ、及びユーザからのリクエストを受け付けて、適切な配信サーバを決定し、配信要求を出す配信マネージャとから構成される。映像配信システムにおいてキーとなる技術は、映像リクエストのためのシグナリング技術及び映像配信技術である。

シグナリング技術としては、近年ＲＦＣ２３２６記載のＲＴＳＰ（Ｒeal Ｔime Ｓtreaming Ｐrotocol）及びＲＦＣ２５４３記載のＳＩＰ（Ｓession Ｉnitiation Ｐrotocol）が注目されている。ＲＴＳＰは、映像配信の制御に特化した制御プロトコルであり、映像コンテンツの配信、停止、早送り、巻き戻しといった制御コマンドが予め定義されている。

一方、ＳＩＰは、いわゆるマルチメディアのセッション制御向けの汎用プロトコルであり、セッションの確立、切断、転送等の基本的なコマンドは定義されているが、通常は制御対象に応じた拡張が必要となる。現在は、主にＩＰ電話のシグナリングに用いられている技術である。

ここで、ＳＩＰの特徴について補足する。電話では、一般に発信先サーバからの応答時間（呼び出し時間に相当）が長いため、この間に発信元クライアントの状態が変化している可能性を考慮に入れ、クライアント、サーバ間での状態の不一致をできるだけ防ぐために、サーバにリクエスト（ＩＮＶＩＴＥ）を投げて、その応答（ＯＫ）を受けたクライアントが更にその応答（ＡＣＫ）を返す、という３Ｗａｙハンドシェイクという方式が採られている点が特徴である。ＳＩＰは、その他、ストリームセッションの変更や状態通知等のメッセージが規定されている。

一方、映像配信技術としては、ＲＴＰ（Ｒeal Ｔime Ｐrotocol）を用いたマルチキャスト転送が広く利用されている。ＲＴＰは、映像情報を格納したパケットにその映像が表示されるべき時間が格納されており、ＲＴＰパケットを受信したクライアントは、表示されるべき時間がくるまでバッファリング、若しくは時間が過ぎていれば廃棄、という処理を行なう。

また、ＲＴＰと共に利用されるプロトコルとして、ＲＴＣＰ（ＲＴＰ Ｃontrol Ｐrotocol）がある。これは、配信サーバから表示クライアントに対し送信レート通知（センダーレポート）を、逆に表示クライアントから配信サーバに対し受信レート通知（レシーバレポート）を定期的に通知するというものである。ＲＴＳＰ及びＳＩＰと、ＲＴＰ及びＲＴＣＰの関係を補足すると、前者がストリームの配信開始、停止等を行なうプロトコルであり、後者はストリームトラフィックの自身の制御を行なう関係であるといえる。

図２９は従来システムの構成例を示すブロック図である。図において、１０は映像を配信するストリーミングサービス事業者、２０は該ストリーミングサービス事業者１０と接続される通信事業者である。ストリーミングサービス事業者１０内のストリーミングデータ配信手段１１は、通信事業者２０にストリーミングデータを配信する。図では、ストリーミングデータ配信手段１１は＃１と＃２の２台しか示されていないが、この数に限る必要はない。

通信事業者２０内では、ルータ（ノード）２１がストリーミングデータ配信手段１１からの配信データを受けてルーティングする。２２はルータ２１と接続されるネットワーク状態管理手段、２３は該ネットワーク状態管理手段２２と接続されるネットワーク構成情報格納手段である。通信事業者２０を経由したストリーミングデータは、ストリーミングデータ表示手段１に配信される。ここでは、ストリーミングデータ表示手段として、＃１と＃２の２台しか示されていないが、この数に限る必要はない。

従来のこの種の技術としては、ネットワーク装置から障害情報を得る手段と、障害情報をネットワークを介して通信される障害情報専用回線を介して通信するための障害情報通信手段と、通信された障害情報を受信し、解析する障害管理用サーバより構成され、ネットワーク環境のパフォーマンスを低下させずに、柔軟にトラブルに対して対応することができるシステムが知られている（例えば特許文献１参照）。
特開２００２−１１１７８２号公報（段落００２９〜００３４、図２）

ＲＴＰは一般的に、ＵＤＰ（Ｕser Ｄatagram Ｐrotocol）上で転送される。ＵＤＰはデータパケットの到着を保証しないプロトコルであり、接続の監視は行わないため、中継ネットワークにおいて障害が発生しても、配信サーバはそれを検出することができないという問題があった。

但し、ＲＴＣＰを利用すれば、配信サーバはレシーバレポートの到着を監視することで表示クライアント間での障害を検出することが可能である。しかしながら、一つの配信サーバには多数の表示クライアントが接続され、非常に多くのレシーバレポートが到着するため、配信サーバはレシーバレポートを処理しないのが一般的である。

更に、処理をしたとしてもレシーバレポートの通知間隔が比較的長いため判断に時間がかかり、利用者への迅速な障害通知等の付加サービスの提供や、障害が発生した時刻の判定が困難であるという問題があった。

また、中継ネットワークの障害等により配信が途絶えると、表示クライアントは配信マネージャ又は配信サーバに対し、途絶えたところから、又は現在のデータの再配信を要求する。配信マネージャ又は配信サーバは、要求に基づき途絶えたところからの再配信リクエストであれば新たにストリームを生成してデータを配信した後、そのアドレスとポートを表示クライアントに通知し、現在のデータの再配信リクエストであれば、現在配信しているアドレスとポートを通知するという処理を行なう。

この時は、途絶えたところからの再配信リクエストの送信タイミングは表示クライアントで一致しないため、一つの中継ネットワークの障害により、多数の再配信リクエストが異なるタイミングで到着するため、多数の配信トラフィックが生成されるという問題があった。

以上まとめると、ＲＴＰを用いたストリーミングサービスにおいては、ネットワークの障害を配信サーバは検出することができない、また検出できたとしても、検出に時間がかかり、かつ障害の発生時刻の判定が困難であるため、障害復旧時の障害発生時刻からのデータ再送等の付加サービスを提供することができなかった。更に、複数の再配信リクエストが異なるタイミングで到着することにより、多数の配信トラフィックが生成されて帯域が消費されるという問題があった。

本発明はこのような課題に鑑みてなされたものであって、ＳＩＰ及びＲＴＰを用いた映像配信システムにおいて、中継ネットワークの障害をネットワーク管理システム及び映像配信システムに手を加えることなく、迅速かつ正確に検出することができ、障害復旧時の障害発生時刻からのデータ再送等の付加サービスを提供することができるストリーミングサービス管理システムを提供することを目的としている。

前記した課題を解決するため、映像配信システムと、ネットワークの障害検出機能及び影響展開機能を持つネットワーク管理システム及び、両者をつなぐリクエストメッセージキャプチャ手段とを利用して、ネットワーク管理システムから中継ネットワークの障害によりサービス断となったユーザの情報及び発生時刻を得ることで、障害発生時刻からのデータ再送等の付加メッセージを提供する。
（１）請求項１記載の発明は、端末のアドレスを記憶する記憶部を有するコンピュータに、障害に関する障害通知を受信すると、該障害により影響を受けた端末のアドレスを該障害通知から抽出して、該アドレスを前記記憶部に記憶する処理と、端末からデータの再配信要求を受信すると、前記記憶部に記憶されたアドレスを有する端末のうち、いくつの端末から再配信要求を受信したかに応じて、再配信要求を送信した各端末に対して該データの再配信を実行する制御を行なう処理と、を実行させることを特徴とする。
（２）請求項２記載の発明は、前記処理は、前記いくつかの端末から再配信要求を受信したかを表す端末数が閾値を超えたら、再配信要求を送信した各端末に対して前記データの再配信を実行する制御を行なうことを特徴とする。
（３）請求項３記載の発明は、端末のアドレスを記憶する記憶部を有するコンピュータを備え、障害に関する障害通知を受信すると、該障害により影響を受けた端末のアドレスを該障害通知から抽出して、該アドレスを前記記憶部に記憶する処理と、端末からデータの再配信要求を受信すると、前記記憶部に記憶されたアドレスを有する端末のうち、いくつの端末から再配信要求を受信したかに応じて、再配信要求を送信した各端末に対して該データの再配信を実行する制御を行なう処理と、から構成されることを特徴とする。
（４）請求項４記載の発明は、前記処理は、前記いくつかの端末から再配信要求を受信したかを表す端末数が閾値を超えたら、再配信要求を送信した各端末に対して前記データの再配信を実行する制御を行なうことを特徴とする。

（１）請求項１記載の発明によれば、再配信要求を送信した各端末に対して再配信を行なうことができる。
（２）請求項２記載の発明によれば、いくつかの端末から再配信要求を受信したかを表す端末数が閾値を超えたら、再配信要求を送信した各端末に対してデータの再配信を行なうことができる。
（３）請求項３記載の発明によれば、再配信要求を送信した各端末に対して再配信を行なうことができる。
（４）請求項４記載の発明によれば、いくつかの端末から再配信要求を受信したかを表す端末数が閾値を超えたら、再配信要求を送信した各端末に対してデータの再配信を行なうことができる。

以下、図面を参照して本発明の実施の形態例を詳細に説明する。
図１は本発明の原理ブロック図である。図２９と同一のものは、同一の符号を付して示す。図において、１０はストリーミングサービス事業者、２０は該ストリーミングサービス事業者１０と接続される通信事業者である。ストリーミングサービス事業者１０において、１１はストリーミングデータを配信するストリーミングデータ配信手段としてのストリーミングデータ配信システムであり、図では＃１と＃２が設けられている場合を示しているが、本発明はこれに限るものではなく、任意の数のストリーミングデータ配信システムを設けることができる。＃１のストリーミングデータ配信システムのＩＰアドレスは１０．２０．１０．１０であり、＃２のストリーミングデータ配信システムのＩＰアドレスは１０．２０．２０．１０である。

通信事業者２０において、２１は複数設けられたストリーミングデータをルーチングするルータ（ノード）である。図では、Ｎ１〜Ｎ４までルータ２１が接続されてＩＰネットワークを構成している場合を示している。これらルータ２１の組み合わせでＩＰネットワークを構成する。また、ストリーミングデータ配信システム１１からのデータを受信するルータ２１は、ストリーミングデータ受信手段として機能する。２２はネットワークの物理的な接続構成とその状態を管理するネットワーク状態管理手段、２４はストリーミングデータ受信手段とストリーミングデータ配信システム１１との間にあって両者間の制御メッセージを監視する制御メッセージ監視手段である。

２３はネットワーク状態管理手段２２と接続され、前記メッセージ監視手段２４からの情報に基づきストリーミングサービスの状態を格納するネットワーク構成情報格納手段である。２５はネットワークのリンク又はノードをキーにそれを利用するユーザ（ストリーミングデータ表示手段）を抽出するユーザ抽出手段とからなるストリーミングサービス管理システムであり、ネットワーク／サービス関係管理手段２５ａと、ストリーミング状態管理手段２５ｂとから構成されている。１はストリーミングデータ表示手段である。図では、＃１と＃２の２台設けられている例を示しているが、これに限るものではなく、任意の数のストリーミングデータ表示手段を設けることができる。なお、ストリーミングデータ表示手段を単にデータ表示手段又はユーザ又は表示クライアントと呼ぶことがある。このように構成されたシステムの動作を説明すれば、以下の通りである。

主となる処理は、障害により影響を受けたユーザに関する情報を通信事業者２０が作成し、それをストリーミングサービス事業者１０に通知するという点であるが、ユーザに関する情報を予め登録しておく必要があるため、これをサービス登録フェーズとして説明し、次に影響ユーザ情報通知フェーズとして説明する。

図２はストリーミングデータ表示手段１の処理フローを示す図、図３はメッセージ監視手段２４の処理フローを示す図、図４はストリーミングデータ配信システム１１の処理フローを示す図、図５はストリーミング状態管理手段２５ｂの処理フローを示す図である。

以下、これらの処理フローについて説明する。先ず、図２に示すストリーミングデータ表示手段１の動作について説明する。先ず、閲覧したいコンテンツ情報の要求メッセージをストリーミングデータ配信システム１１に対して送信する（Ｓ１１）。次に、ストリーミングデータ表示手段１は、配信システム１１から応答メッセージが得られたかどうかチェックする（Ｓ１２）。得られた場合には、応答内容は閲覧ＯＫかどうかチェックする（Ｓ１３）。ＯＫでない場合には、処理を終了する（Ｓ１５）。ＯＫの場合には、応答メッセージに含まれている配信サーバ（ここではストリーミングデータ配信システム１１）のアドレスとポート番号にアクセスし、閲覧する（Ｓ１４）。

次に、図３に示すメッセージ監視手段２４の処理フローについて説明する。先ず、ストリーミング制御メッセージを受信するまで待つ（Ｓ２１）。次に、制御メッセージを受信したら、データ表示手段１からの要求メッセージであるかどうかチェックする（Ｓ２２）。データ表示手段１からの要求メッセージでない場合には、ストリーミングデータ配信システム１１からの応答メッセージであるかどうかチェックする（Ｓ２４）。配信システムからの応答メッセージでない場合には、ステップＳ２１に戻る。

ストリーミングデータ配信システム１１からの応答メッセージである場合には、応答メッセージからデータ表示手段１のＩＰアドレス、配信サーバのＩＰアドレス、コンテンツの帯域を抽出し、ストリーミング状態管理手段２５ｂに通知し（Ｓ２５）、ステップＳ２１に戻る。ステップＳ２２において、表示手段１からの要求メッセージである場合には、配信システムに転送し（Ｓ２３）、ステップＳ２１に戻る。

次に、図４のストリーミングデータ配信システム１１の処理フローについて説明する。先ず、制御メッセージを受信するまで待つ（Ｓ３１）。次に、制御メッセージを受信したらデータ表示手段１からの要求メッセージであるかどうかチェックする（Ｓ３２）。データ表示手段１からの要求メッセージでない場合には、通信事業者２０からの障害通知であるかどうかチェックする（Ｓ３４）。障害通知でない場合には、ステップＳ３１に戻る。障害通知であった場合には、障害により影響を受けたユーザの情報（ＩＰアドレス）を取得し（Ｓ３５）、ステップＳ３１に戻る。ステップＳ３２において、要求メッセージである場合には、要求されたコンテンツを提供できるストリーミングデータ配信システム１１を選び、そのＩＰアドレス、ポート、コンテンツの帯域幅情報を応答として返し（Ｓ３３）、ステップＳ３１に戻る。

次に、図５のストリーミング状態管理手段２５ｂの処理フローについて説明する。先ず、他コンポーネントからの通知を待つ（Ｓ４１）。次に、通知を受信したらメッセージ監視手段２４からのサービス発生通知であるかどうかチェックする（Ｓ４２）。そうでない場合には、ネットワーク状態管理手段２２からの障害通知であるかどうかチェックする（Ｓ４５）。障害通知でなかった場合には、ステップＳ４１に戻る。

障害通知であった場合には、該障害通知から、障害箇所（ノード又はリンク）を抽出する（Ｓ４６）。そして、ネットワーク構成情報格納手段２３を参照し、前ステップで得た障害箇所を利用しているサービスを抽出し、データ表示手段１のＩＰアドレスをストリーミングデータ配信システム１１に通知し（Ｓ４７）、ステップＳ４１に戻る。

ステップＳ４２において、メッセージ監視手段２４からのサービス発生通知であった場合には、発生したサービスに関する情報（データ表示手段１のＩＰアドレス、ストリーミングデータ配信システム１１のＩＰアドレス、コンテンツの帯域幅等）を得る（Ｓ４３）。次に、ネットワーク構成情報格納手段２３を参照し、データ表示手段１〜ストリーミングデータ配信システム１１間の経路を算出し、これをネットワーク／サービス関係管理手段２５ａに格納し（Ｓ４４）、ステップＳ４１に戻る。
（サービス登録フェーズ）
ストリーミングデータ表示手段１からストリーミングデータ配信システム１１に対して、閲覧したいコンテンツ情報の要求メッセージを送信する（Ｓ１１）。この時、メッセージ監視手段２４は、ストリーミングデータ配信システム１１のプロキシとして動作することで、要求メッセージの発生を検出する（Ｓ２１〜Ｓ２２）。要求メッセージからは、閲覧したいコンテンツの識別情報（例えばコンテンツＩＤ＝１００）と送信元（即ちストリーミングデータ表示手段１）のアドレス（例えば、ＩＰアドレス＝１０．１０．１０．１０とポート２００３）が得られる。ただし、要求メッセージから得られる情報が応答メッセージから得られる場合は、メッセージを単に転送（スルー）するだけでもよい（Ｓ２３）。

次に、ストリーミングデータ配信システム１１は、要求されたコンテンツに関する情報（配信サーバＩＰアドレス（例えばＩＰアドレス＝１０．２０．１０．１０とポート＝２０００））とコンテンツの帯域（例えば１０Ｍｂｐｓ）をストリーミングデータ表示手段１に対して応答する（Ｓ３１→Ｓ３２→Ｓ３３）。この時、メッセージ監視手段２４は、要求メッセージの場合と同様に、応答メッセージを検出した後、ストリーミング状態管理手段２５ｂにサービス発生を通知する（Ｓ２１→Ｓ２２→Ｓ２４→Ｓ２５）。

通知内容は、例えばストリーミングデータ表示手段１のＩＰアドレス（１０．１０．１０．１０）とストリーミングデータ配信システム１１のＩＰアドレス（１０．２０．１０．１０）とコンテンツの帯域幅（１０Ｍｂｐｓ）がある。ストリーミング状態管理手段２５ｂは、上述したようなサービス情報と、ネットワーク構成情報格納手段２３に格納されたネットワーク構成データとから、ストリームデータの経路を算出し（この場合、例えば１０．１０．１０．１０−Ｎ１−Ｎ３−１０．２０．１０．１０となる）、これを関係管理手段２５ａに格納する（Ｓ４１→Ｓ４２→Ｓ４３→Ｓ４４）。
（影響ユーザ通知フェーズ）
中継ネットワーク内で障害が発生したものとする（例えばノードＮ１）。この時、障害を検出したノード（ルータ）からネットワーク状態管理手段２２に障害発生が通知される（例えば、Ｎ２及びＮ３からＮ１につながるリンクの断をＳＮＭＰ（Ｓimple Ｎetwork Ｍanagement Ｐrotocol）のＴrapメッセージが通知される）。ネットワーク状態管理手段２２は、ストリーミング状態管理手段２５ｂにリンク断が発生した箇所を通知する（Ｎ１−Ｎ２，Ｎ１−Ｎ３）（Ｓ４１→Ｓ４２→Ｓ４５）。

ストリーミング状態管理手段２５ｂは、関係管理手段２５ａからサービス情報を抽出し、該当するリソース（Ｎ１−Ｎ２とＮ１−Ｎ３）を利用しているサービスを抽出する（Ｓ４６）。この例では、１０．１０．１０．１０−Ｎ１−Ｎ３−１０．２０．１０．１０が抽出される。

通信事業者２０は、ストリーミングサービス事業者１０に対して、障害に関する情報、例えば、影響を受けたユーザの情報（ＩＰアドレス＝１０．１０．１０．１０）やストリーミングデータ配信システム１１のＩＰアドレス（１０．２０．１０．１０）等をストリーミングサービス事業者１０に対して通知する（Ｓ４７）。この時、通知方法に関しては特に問わない（電子メール等でも可能）。ストリーミングサービス事業者１０は、通信事業者２０からの障害通知メッセージから影響を受けたユーザの情報（ＩＰアドレス等）を取得する（Ｓ３１→Ｓ３２→Ｓ３４→Ｓ３５）。

このように構成すれば、通信事業者２０が、ネットワークの障害情報から影響を受けるユーザを全て抽出し、前記ストリーミングサービス事業者１０に通知することで、中継ネットワークの障害をネットワーク管理システム及び映像配信システムに手を加えることなく、迅速かつ正確に検出することができる。

図６は本発明の第２の実施の形態例を示すブロック図である。図１と同一のものは、同一の符号を付して示す。この実施の形態例は、前記ストリーミングサービス管理システム２５がネットワークの障害情報から影響を受けるユーザを全て抽出した後、ストリーミングサービス管理システム２５がストリーミングデータ配信システム１１に通知するようにしたものである。

このように構成すれば、通信事業者２０が、ネットワークの障害情報から影響を受けるユーザを全て抽出し、前記ストリーミングサービス事業者１０に通知することで、中継ネットワークの障害をネットワーク管理システム及び映像配信システムに手を加えることなく、迅速かつ正確に検出することができる。

図７は本発明の第３の実施の形態例を示すブロック図である。図１と同一のものは、同一の符号を付して示す。この実施の形態例は、通信事業者２０内のストリーミングサービス管理システム２５からメッセージ監視手段２４に制御信号を出し、制御信号を受けたメッセージ制御手段２４からストリーミングサービス事業者１０内のストリーミングデータ配信システム１１に制御信号を与えるようにしたものである。このように構成されたシステムの動作を説明すれば、以下の通りである。

図８はストリーミング状態管理手段２５ｂの処理フローを示す図、図９はメッセージ監視手段２４の処理フローを示す図である。以下、これらの処理フローについて説明する。先ず図８に示す処理フローについて説明する。先ず、他コンポーネントからの通知を待つ（Ｓ４１）。そして、通知が来たらメッセージ監視手段２４からのサービス発生通知であるかどうかチェックする（Ｓ４２）。

メッセージ監視手段２４からのサービス発生通知でなかった場合には、ネットワーク状態管理手段２２からの障害通知であるかどうかをチェックする（Ｓ４５）。ネットワーク状態管理手段２２からの障害通知でなかった場合には、ステップＳ４１に戻る。ネットワーク状態管理手段２２からの通知であった場合には、その障害通知から、障害箇所（ノード又はリンク）を抽出する（Ｓ４６）。次に、ネットワーク構成情報格納手段２３を参照し、前ステップで得た障害箇所を利用しているサービスを抽出し、データ表示手段１のＩＰアドレスをストリーミングデータ配信システム１１に通知するように、メッセージ監視手段２４に要求し（Ｓ４８）、ステップＳ４１に戻る。

ステップＳ４２において、メッセージ監視手段からのサービス発生通知であった場合には、発生したサービスに関する情報（データ表示手段１のＩＰアドレス、ストリーミングデータ配信システム１１のＩＰアドレス、コンテンツの帯域幅当）を得る（Ｓ４３）。次に、ネットワーク構成情報格納手段２３を参照し、データ表示手段１〜ストリーミングデータ配信システム１１間の経路を算出し、これを関係管理手段２５ａに格納し（Ｓ４４）、ステップＳ４１に戻る。

次に、図９に示すフローについて説明する。先ず、メッセージ監視手段２４は、ストリーミング制御メッセージを受信するまで待つ（Ｓ２１）。ストリーミング制御メッセージを受信した場合には、データ表示手段１からの要求メッセージであるかどうかチェックする（Ｓ３２）。要求メッセージでない場合には、ストリーミングデータ配信システム１１からの応答メッセージであるかどうかチェックする（Ｓ２４）。応答メッセージでなかった場合には、ストリーミング状態管理手段２５ｂからの要求であるかどうかチェックする（Ｓ２６）。ストリーミング状態管理手段２５ｂからの要求でなかった場合にはステップＳ２１に戻る。ストリーミング状態管理手段２５ｂからの要求であった場合には、要求メッセージの内容（障害情報）をストリーミングデータ配信システム１１に通知し（Ｓ２７）、ステップＳ２１に戻る。

ステップＳ２４において、ストリーミングデータ配信システムからの応答メッセージであった場合には、該応答メッセージからデータ表示手段１のＩＰアドレス、ストリーミングデータ配信システム１１のＩＰアドレス、コンテンツの帯域を抽出し、ストリーミング状態管理手段２５ｂに通知し（Ｓ２５）、ステップＳ２１に戻る。ステップＳ２２において、データ表示手段１からの要求メッセージであった場合には、ストリーミングデータ配信システム１１に転送し（Ｓ２３）、ステップＳ２１に戻る。

以下、全体の動作について説明する。図１に示す実施の形態例との差分について説明する。影響ユーザ通知フェーズにおいて、ネットワーク状態管理手段２２は、ストリーミング状態管理手段２５ｂにリンク断が発生した箇所を通知する（Ｎ１−Ｎ２，Ｎ１−Ｎ３）（Ｓ４１→Ｓ４２→Ｓ４５）。ストリーミング状態管理手段２５ｂは、関係管理手段２５ａからサービス情報を抽出し、該当するリソース（Ｎ１−Ｎ２とＮ１−Ｎ３）を利用しているサービスを抽出する（Ｓ４６）。

この例では、１０．１０．１０．１０−Ｎ１−Ｎ３−１０．２０．１０．１０が抽出される。ストリーミング状態管理手段２５ｂは、メッセージ監視手段２４に対して、障害に関する情報、例えば影響を受けたユーザ（データ表示手段）１の情報（ＩＰアドレス＝１０．１０．１０．１０）やストリーミングデータ配信システム１１のＩＰアドレス（１０．２０．１０．１０）等をストリーミングデータ配信システム１１に対して通知するように依頼する（Ｓ４８）。

メッセージ監視手段２４は、前述した障害情報をストリーミングデータ配信システム１１に対して通知する（Ｓ２１→Ｓ２２→Ｓ２４→Ｓ２６→Ｓ２７）。この時、通知方法に関しては特に問わない（電子メール等でも可能）。ストリーミングデータ配信システム１１は通信事業者２０からの障害通知メッセージから影響を受けたユーザの情報（ＩＰアドレス等）を取得する（Ｓ３１→Ｓ３２→Ｓ３４→Ｓ３５）。

この実施の形態例によれば、メッセージ監視手段２４は、障害情報をストリーミングデータ配信システムに対して通知することができる。
図１０は本発明の第４の実施の形態例を示すブロック図である。図１と同一のものは、同一の符号を付して示す。この実施の形態例は、ストリーミングサービス事業者１０の構成がいままでのものと異なっている。図において、１３はストリーミングデータを配信する配信サーバであり、図では＃１と＃２の２台設けた場合を示しているが、これに限るものではない。１２は配信サーバ１３と接続されるノードであり、ＩＰネットワークと接続され、更に配信マネージャ１４とも接続されている。配信マネージャ１４には、通信事業者２０のストリーミングサービス管理システム２５と接続されている。このように構成されたシステムの動作を説明すれば、以下の通りである。

図１１はストリーミング状態管理手段２５ｂの処理フローを示す図、図１２は配信マネージャ１４の処理フローを示す図である。先ず、これらフローについて説明する。先ず、図１１について説明する。ストリーミング状態管理手段２５ｂは、他コンポーネントからの通知を待つ（Ｓ４１）。通知が来たら、メッセージ監視手段２４からのサービス発生通知であるかどうかチェックする（Ｓ４２）。

メッセージ監視手段２４からのサービス発生通知でない場合には、ネットワーク状態管理手段２２からの障害通知であるかどうかチェックする（Ｓ４５）。障害通知でない場合には、ステップＳ４１に戻る。障害通知であった場合には、障害通知から、障害箇所（ノード又はリンク）を抽出する（Ｓ４６）。次に、ネットワーク構成情報格納手段２３を参照し、前ステップで得た障害箇所を利用しているサービスを抽出し、データ表示手段１のＩＰアドレスを配信マネージャ１４に通知し（Ｓ４９）、ステップＳ４１に戻る。

ステップＳ４２において、メッセージ監視手段２４からのサービス発生通知であった場合には、発生したサービスに関する情報（データ表示手段１のＩＰアドレス、配信サーバ１３のＩＰアドレス、コンテンツ等）を得る（Ｓ４３）。次に、ネットワーク構成情報格納手段２３を参照し、データ表示手段１〜配信サーバ１３間の経路を算出し、これを関係管理手段２５ａに格納し（Ｓ４４）、ステップＳ４１に戻る。

次に、図１２について説明する。先ず、制御メッセージを受信するまで待つ（Ｓ５１）。次に、制御メッセージを受信したら、データ表示手段１からの要求メッセージであるかどうかチェックする（Ｓ５２）。データ表示手段１からの要求メッセージでない場合には、通信事業者２０からの障害通知であるかどうかチェックする（Ｓ５４）。そうでなかった場合には、ステップＳ５１に戻る。そうであった場合には、障害により影響を受けたユーザの情報（ＩＰアドレス）を取得し（Ｓ５５）、ステップＳ５１に戻る。ステップＳ５２において、データ表示手段１からの要求メッセージであった場合には、要求されたコンテンツを提供できる配信サーバ１３を選び、そのＩＰアドレス、ポート、コンテンツの帯域幅情報を応答として返し（Ｓ５３）、ステップＳ５１に戻る。

次に、全体の動作について説明する。先ず、図１０に示すシステムと図１に示すシステムとの差分について説明する。影響ユーザ通知フェーズにおいて、ネットワーク状態管理手段２２は、ストリーミング状態管理手段２５ｂにリンク断が発生した箇所を通知する（Ｎ１−Ｎ２，Ｎ１−Ｎ３）（Ｓ４１→Ｓ４２→Ｓ４５）。ストリーミング状態管理手段２５ｂは、関係管理手段２５ａからサービス情報を抽出し、該当するリソース（Ｎ１−Ｎ２とＮ１−Ｎ３）を利用しているサービスを抽出する（Ｓ４６）。

この例では、１０．１０．１０．１０−Ｎ１−Ｎ３−１０．２０．１０．１０が抽出される。ストリーミング状態管理手段２５ｂは、障害に関する情報、例えば影響を受けたユーザの情報（ＩＰアドレス＝１０．１０．１０．１０）や配信サーバ１３のＩＰアドレス（１０．２０．１０．１０）等を配信マネージャ１４に通知する（Ｓ４９）。この時、通知方法に関しては特に問わない。例えば電子メール等でもよい。配信マネージャ１４は、通信事業者２０からの障害通知メッセージから影響を受けたユーザの情報（ＩＰアドレス）を取得する（Ｓ５１→Ｓ５２→Ｓ５４→Ｓ５５）。

この実施の形態例によれば、配信マネージャ１４は、通信事業者２０から影響を受けたユーザの情報（ＩＰアドレス等）を取得することができる。
図１３は本発明の第５の実施の形態例を示すブロック図である。図１０と同一のものは、同一の符号を付して示す。この実施の形態例では、ストリーミングサービス管理システム２５の出力が配信マネージャ１４ではなく、配信サーバ１３に入力されている点が図１０と異なる。このように構成されたシステムの動作を説明すれば、以下の通りである。

図１４はストリーミング状態管理手段２５ｂの処理フローを示す図、図１５は配信サーバの処理フローを示す図である。先ず、図１４について説明する。先ず、他コンポーネントからの通知を待つ（Ｓ４１）。通知が来たらメッセージ監視手段２４からのサービス発生通知であるかどうかチェックする（Ｓ４２）。サービス発生通知でない場合には、ネットワーク状態管理手段２２からの障害通知であるかどうかチェックする（Ｓ４５）。ネットワーク状態管理手段２２からの障害通知でない場合には、ステップＳ４１に戻る。ネットワーク状態管理手段２２からの障害通知である場合には、該障害通知から、障害箇所（ノード又はリンク）を抽出する（Ｓ４６）。次に、ネットワーク構成情報格納手段２３を参照し、前ステップで得た障害箇所を利用しているサービスを抽出し、データ表示手段１のＩＰアドレスを配信サーバ１３に通知し（Ｓ４７）、ステップＳ４１に戻る。

ステップＳ４２において、メッセージ監視手段２４からのサービス発生通知であった場合には、発生したサービスに関する情報（データ表示手段１のＩＰアドレス、配信サーバ１３のＩＰアドレス、コンテンツの帯域幅等）を得る（Ｓ４３）。そして、ネットワーク構成情報格納手段２３を参照し、データ表示手段１〜配信サーバ１３間の経路を算出し、これを関係管理手段２５ａに格納し（Ｓ４４）、ステップＳ４１に戻る。

次に、図１５について説明する。先ず、配信サーバ１３は、制御メッセージを受信するまで待つ（Ｓ６１）。制御メッセージを受信した場合には、通信事業者２０からの障害通知であるかどうかチェックする（Ｓ６２）。通信事業者２０からの障害通知でない場合には、ステップＳ６１に戻る。通信事業者２０からの障害通知である場合には、障害により影響を受けたユーザの情報（ＩＰアドレス）を取得し（Ｓ６３）、ステップＳ６１に戻る。

次に、全体の動作について説明する。先ず、図１３に示すシステムと図１に示すシステムとの差分について説明する。影響ユーザ通知フェーズにおいて、ネットワーク状態管理手段２２は、ストリーミング状態管理手段２５ｂにリンク断が発生した箇所を通知する（Ｎ１−Ｎ２，Ｎ１−Ｎ３）（Ｓ４１→Ｓ４２→Ｓ４５）。ストリーミング状態管理手段２５ｂは、関係管理手段２５ａからサービス情報を抽出し、該当するリソース（Ｎ１−Ｎ２とＮ１−Ｎ３）を利用しているサービスを抽出する（Ｓ４６）。この例では、１０．１０．１０．１０−Ｎ１−Ｎ３−１０．２０．１０．１０が抽出される。

ストリーミング状態管理手段２５ｂは、障害に関する情報、例えば影響を受けたユーザ（データ表示手段）１の情報（ＩＰアドレス＝１０．１０．１０．１０）や配信サーバ１３のＩＰアドレスＩＰアドレス（１０．２０．１０．１０）等を配信サーバ１３に通知する（Ｓ４７）。この時、通知方法に関しては特に問わない。例えば電子メール等でも可能である。配信サーバ１３は、通信事業者２０から影響を受けたユーザの情報（ＩＰアドレス等）を取得する（Ｓ６１→Ｓ６２→Ｓ６３）。

この実施の形態例によれば、配信サーバ１３は、影響を受けたユーザの情報を取得することができる。
図１６は本発明の第６の実施の形態例を示すブロック図である。図１０と同一のものは、同一の符号を付して示す。この実施の形態例は、ストリーミングサービス管理システム２５内のストリーミング状態管理手段２５ｂからの制御信号がメッセージ監視手段２４に入り、この制御信号を受けたメッセージ監視手段２４の出力が配信マネージャ１４に入るように構成されたものである。

この実施の形態例の動作については、図７に示す実施の形態例と、図１０に示す実施の形態例を組み合わせたものである。この実施の形態例によれば、メッセージ監視手段２４は、障害情報をストリーミングデータ配信システム２０の配信マネージャ１４に対して通知することができる。

図１７は本発明の第７の実施の形態例を示すブロック図である。図１０と同一のものは、同一の符号を付して示す。この実施の形態例は、ストリーミングサービス管理システム２５内のストリーミング状態管理手段２５ｂからの制御信号がメッセージ監視手段２４に入り、この制御信号を受けたメッセージ監視手段２４の出力が配信サーバ１３に入るように構成されたものである。

この実施の形態例の動作については、図７に示す実施の形態例と、図１３に示す実施の形態例を組み合わせたものである。この実施の形態例によれば、配信サーバ１３は、影響を受けたユーザの情報を取得することができる。

図１８は本発明の第８の実施の形態例を示すブロック図である。図１と同一のものは、同一の符号を付して示す。この実施の形態例は、通信事業者２０からストリーミングサービス事業者１０のストリーミングデータ配信システム１１に制御信号を通知するようにしたものである。図１９はストリーミング状態管理手段２５ｂの処理フローを示す図、図２０はストリーミングデータ配信システム１１の処理フローを示す図である。

先ず、図１９に示すフローについて説明する。先ず、ストリーミング状態管理手段２５ｂは、他コンポーネントからの通知を待つ（Ｓ４１）。通知が届いた場合には、メッセージ監視手段２４からのサービス発生通知であるかどうかチェックする（Ｓ４２）。サービス発生通知でなかった場合には、ネットワーク状態管理手段２２からの障害通知であるかどうかチェックする（Ｓ４５）。障害通知でなかった場合には、ネットワーク状態管理手段２２からの復旧通知であるかどうかチェックする（Ｓ４１１）。

復旧通知でなかった場合には、ステップＳ４１に戻る。復旧通知であった場合には、前回、障害を通知した先（ストリーミングデータ配信システム１１又はメッセージ監視手段２４）に障害の復旧を通知し（Ｓ４１２）、ステップＳ４１に戻る。ステップＳ４５において、ネットワーク状態管理手段２２からの障害通知であった場合には、障害通知から、障害箇所（ノード又はリンク）を抽出する（Ｓ４６）。そして、ネットワーク構成情報格納手段２３を参照し、前ステップで得た障害箇所を利用しているサービスを抽出し、データ表示手段１のＩＰアドレスをストリーミングデータ配信システム１１に通知し（Ｓ４７）、ステップＳ４１に戻る。

ステップＳ４２において、サービス発生通知であった場合には、発生したサービスに関する情報（データ表示手段１のＩＰアドレス、ストリーミングデータ配信システム１１のＩＰアドレス、コンテンツの帯域幅等）を得る（Ｓ４３）。次に、ネットワーク構成情報格納手段２３を参照し、データ表示手段１〜ストリーミングデータ配信システム１１間の経路を算出し、これを関係管理手段２５ａに格納し（Ｓ４４）、ステップＳ４１に戻る。

次に、図２０に示すフローについて説明する。ストリーミングデータ配信システム１１は、制御メッセージを受信するまで待つ（Ｓ３１）。制御メッセージを受信すると、データ表示手段１からの要求メッセージであるかどうかチェックする（Ｓ３２）。要求メッセージでない場合には、通信事業者２０からの障害通知であるかどうかチェックする（Ｓ３４）。障害通知でなかった場合には、通信事業者２０からの復旧通知であるかどうかチェックする（Ｓ３６）。復旧通知でなかった場合には、ステップＳ３１に戻る。

復旧通知であった場合には、障害発生時刻以前より再生したストリームを作成し、上記要求に含まれるＩＰアドレスが示す各データ表示手段１に対し、ストリームの切り替えを要求し（Ｓ３７）、ステップＳ３１に戻る。ステップＳ３４において、障害通知であった場合には、障害により影響を受けたユーザの情報（ＩＰアドレス）を取得し（Ｓ３５）、ステップＳ３１に戻る。

ステップＳ３２において、要求メッセージであった場合には、要求されたコンテンツを提供できるストリーミングデータ配信システム１１を選び、そのＩＰアドレス、ポート、コンテンツの帯域幅情報を応答として返し（Ｓ３３）、ステップＳ３１に戻る。

次に、全体の動作について説明する。図１に示す実施の形態例との差異について説明する。影響ユーザ通知フェーズにおいて、ネットワーク状態管理手段２２は、ストリーミング状態管理手段２５ｂにリンク確立が発生した箇所を通知する（Ｎ１−Ｎ２，Ｎ１−Ｎ３）（Ｓ４１→Ｓ４２→Ｓ４５→Ｓ４１１）。ストリーミング状態管理手段２５ｂは、障害発生を通知した宛先に向けて障害復旧を通知する（Ｓ４１２）。この時、通知方法に関しては特に問わない。例えば、電子メール等でも可能である。

ストリーミングデータ配信システム１１は、通信事業者２０からの障害復旧メッセージに含まれるデータ表示手段１を示すＩＰアドレス（例えば、１０．１０．１０．１０）に向けてストリームの切り替えを要求する（Ｓ３１→Ｓ３２→Ｓ３４→Ｓ３６→Ｓ３７）。なお、ストリームの切り替えそのものは、ＲＴＳＰやＳＩＰ等のシグナリングプロトコル（従来技術）を利用し、データ表示手段１（表示クライアント）１に対して新しいストリーミングデータ配信システム１１のアドレスとポート番号を通知することで実施することができる。

この実施の形態例によれば、ストリーミング状態管理手段２５ｂは、障害発生を通知した宛先に向けて障害復旧を通知することができる。
次に、第９の実施の形態例について説明する。図２１はストリーミング状態管理手段の処理フローを示す図、図２２は配信マネージャの処理フローを示す図、図２３は配信サーバの処理フローを示す図である。システムとしては、例えば図１０を用いる。

先ず、図２１の処理フローについて説明する。ストリーミング状態管理手段２５ｂは、他コンポーネントからの通知を待つ（Ｓ４１）。通知が来た場合には、メッセージ監視手段２４からのサービス発生通知であるかどうかチェックする（Ｓ４２）。サービス発生通知でなかった場合には、ネットワーク状態管理手段２２からの障害通知であるかどうかチェックする（Ｓ４５）。障害通知でなかった場合、ネットワーク状態管理手段２２からの復旧通知であるかどうかチェックする（Ｓ４１１）。

ステップＳ４１１において、復旧通知でなかった場合には、ステップＳ４１に戻る。復旧通知であった場合には、前回障害を通知した先（配信システム又はメッセージ監視手段２４）に障害の復旧を通知し（Ｓ４１２）、ステップＳ４１に戻る。ステップＳ４５において、ネットワーク状態管理手段２２からの障害通知であった場合には、障害通知から、障害箇所（ノード又はリンク）を抽出する（Ｓ４６）。次に、ネットワーク構成情報格納手段２３を参照し、前ステップで得た障害箇所を利用しているサービスを抽出し、データ表示手段１のＩＰアドレスを配信サーバ１３に通知し（Ｓ４１０）、ステップＳ１に戻る。

ステップＳ４２において、メッセージ監視手段２４からのサービス発生通知であった場合には、発生したサービスに関する情報（データ表示手段１のＩＰアドレス、配信サーバのＩＰアドレス、コンテンツの帯域幅等）を得る（Ｓ４３）。そして、ネットワーク構成情報格納手段２３を参照し、データ表示手段〜配信サーバ１３間の経路を算出し、これを関係管理手段２５ａに格納し（Ｓ４４）、ステップＳ４１に戻る。

次に、図２２の処理フローについて説明する。配信マネージャ１４は、先ず制御メッセージを受信するまで待つ（Ｓ５１）。制御メッセージを受信したら、データ表示手段１からの要求メッセージであるかどうかチェックする（Ｓ５２）。要求メッセージでない場合には、通信事業者２０からの障害通知であるかどうかチェックする（Ｓ５４）。障害通知でない場合には、通信事業者２０からの復旧通知であるかどうかチェックする（Ｓ５６）。復旧通知でない場合には、ステップＳ５１に戻る。

復旧通知である場合には、障害発生時刻前から再生したストリームを作成し、上記要求に含まれるＩＰアドレスが示す各データ表示手段１に対して、ストリームの切り替えを実施するように配信サーバ１３に要求し（Ｓ５７）、ステップＳ５１に戻る。ステップＳ５４において、通信事業者２０からの障害通知であった場合には、障害により影響を受けたユーザの情報（ＩＰアドレス）を取得し（Ｓ５５）、ステップＳ５１に戻る。ステップＳ５２において、データ表示手段１からの要求メッセージであった場合には、要求されたコンテンツを提供できる配信サーバ１３を選び、そのＩＰアドレス、ポート、コンテンツの帯域幅情報を応答として返し（Ｓ５３）、ステップＳ５１に戻る。

次に、図２３の処理フローについて説明する。配信サーバ１３は、制御メッセージを受信するまで待つ（Ｓ６１）。受信した場合には、通信事業者２０からの障害通知であるかどうかチェックする（Ｓ６２）。障害通知でなかった場合には、配信マネージャ１４からの切替要求であるかどうかチェックする（Ｓ６４）。切替要求でなかった場合には、ステップＳ６１に戻る。

切替要求であった場合には、新たなストリームを生成し、上記要求に含まれているＩＰアドレスが示すデータ表示手段に対し、新ストリームへの切り替えを要求し（Ｓ６５）、ステップＳ６１に戻る。ステップＳ６２において、通信事業者からの障害通知であった場合には、障害により影響を受けたユーザの情報（ＩＰアドレス）を取得し（Ｓ６３）、ステップＳ６１に戻る。

次に、第９の実施の形態例の全体的な動作について説明する。この実施の形態例について、第１の実施との差分について説明する。影響ユーザ通知フェーズにおいて、ネットワーク状態管理手段２２は、ストリーミング状態管理手段２５ｂにリンク確立が発生した箇所を通知する（Ｎ１−Ｎ２，Ｎ１−Ｎ３）（Ｓ４１→Ｓ４２→Ｓ４５→Ｓ４１１）。ストリーミング状態管理手段２５ｂは、障害発生を通知した宛先に向けて障害復旧を通知する（Ｓ４１２）。この時、通知方法に関しては特に問わない（電子メール等でも可能）。

配信マネージャ１４は、通信事業者２０からの障害復旧メッセージに含まれるデータ表示手段１を示すＩＰアドレス（例えば１０．１０．１０．１０）に向けて、ストリームの切り替えを実施するように配信サーバに要求する（Ｓ５１→Ｓ５２→Ｓ５４→Ｓ５６→Ｓ５７）。配信サーバ１３は、指定されたデータ表示手段１に対してストリームの切り替えを要求する（Ｓ６１→Ｓ６２→Ｓ６４→Ｓ６５）。なお、ストリームの切り替えそのものは、ＲＴＳＰやＳＩＰ等のシグナリングプロトコル（従来技術）を利用し、表示クライアント１に対し新しい配信サーバのアドレスとポート番号を通知することで実施することができる。

この実施の形態例によれば、配信サーバ１３は、指定されたデータ表示手段１に対してストリームの切り替えを要求することができる。
次に、第１０の実施の形態例の動作について説明する。図２４はストリーミング状態管理手段２５ｂの処理フローを示す図、図２５は配信サーバ１３の処理フローを示す図である。システム構成としては、図１０を用いる。

先ず、図２４の処理フローについて説明する。ストリーミング状態管理手段２５ｂは、他コンポーネントからの通知を待つ（Ｓ４１）。通知が来たら、メッセージ監視手段２４からのサービス発生通知であるかどうかをチェックする（Ｓ４２）。サービス発生通知でなかった場合には、ネットワーク状態管理手段２２からの障害通知であるかどうかをチェックする（Ｓ４５）。ネットワーク状態管理手段２２からの障害通知でない場合には、ネットワーク状態管理手段２２からの復旧通知であるかどうかをチェックする（Ｓ４１１）。

ネットワーク状態管理手段２２からの復旧通知でない場合には、ステップＳ４１に戻る。ネットワーク管理手段２２からの復旧通知である場合には、前回、障害を通知した先（配信システム又はメッセージ監視手段２４）に障害の復旧を通知し（Ｓ４１２）、ステップＳ４１に戻る。ステップＳ４５において、ネットワーク状態管理手段２２からの障害通知である場合には、障害通知から、障害箇所（ノード又はリンク）を抽出する（Ｓ４６）。次に、ネットワーク構成情報格納手段２３を参照し、前ステップで得た障害箇所を利用しているサービスを抽出し、データ表示手段１のＩＰアドレスを配信サーバ１３に通知し（Ｓ４１０）、ステップＳ４１に戻る。

ステップＳ４２において、メッセージ監視手段２４からのサービス発生通知であった場合には、発生したサービスに関する情報（表示手段のＩＰアドレス、配信サーバのＩＰアドレス、コンテンツの帯域幅等）を得る（Ｓ４３）。次に、ネットワーク構成情報格納手段２３を参照し、データ表示手段１〜配信サーバ１３間の経路を算出し、これを関係管理手段２５ａに格納し（Ｓ４４）、ステップＳ４１に戻る。

次に、図２５の処理フローについて説明する。配信サーバ１３は、制御メッセージを受信するまで待つ（Ｓ６１）。制御メッセージを受信したら、通信事業者２０からの障害通知であるかどうかをチェックする（Ｓ６２）。障害通知でなかった場合に、配信マネージャ１４からの切替要求であるかどうかチェックする（Ｓ６４）。切替要求でなかった場合には、通信事業者２０からの復旧通知であるかどうかチェックする（Ｓ６６）。復旧通知でない場合には、ステップＳ６１に戻る。

復旧通知であった場合には、障害発生時刻前から再生したストリームを作成し、上記要求に含まれるＩＰアドレスが示す各データ表示手段１に対して、ストリームの切り替えを実施するように配信サーバ１３に要求し（Ｓ６７）、ステップＳ６１に戻る。ステップＳ６４において、配信マネージャからの切替要求であった場合には、新たなストリームを生成し、上記要求に含まれているＩＰアドレスが示すデータ表示手段１に対して、新ストリームへの切り替えを要求し（Ｓ６５）、ステップＳ６１に戻る。ステップＳ６２において、通信事業者２０からの障害通知である場合には、障害により影響を受けたユーザの情報（ＩＰアドレス）を取得し（Ｓ６３）、ステップＳ６１に戻る。ここで、ユーザとはデータ表示手段１のことである。

次に、第１０の実施の形態例について第１の実施の形態例との差分について説明する。影響ユーザ通知フェーズにおいて、ネットワーク状態管理手段２２は、ストリーミング状態管理手段２５ｂにリンク確立が発生した箇所を通知する（Ｎ１−Ｎ２，Ｎ１−Ｎ３）（Ｓ４１→Ｓ４２→Ｓ４５→Ｓ４１１）。ストリーミング状態管理手段２５ｂは、障害発生を通知した宛先に向けて障害復旧を通知する（Ｓ４１２）。この時、通知方法に関しては特に問わない（電子メール等でも可能）。

配信サーバ１３は、通信事業者２０からの障害復旧メッセージに含まれるＩＰアドレス（例えば１０．１０．１０．１０）に向けて、ストリームの切り替えを実施するように要求する（Ｓ６１→Ｓ６２→Ｓ６４→Ｓ６６→Ｓ６７）。ストリームの切り替えそのものは、ＲＴＳＰやＳＩＰ等のシグナリングプロトコル（従来技術）を利用し、データ表示手段１に対して新しい配信サーバのアドレスとポート番号を通知することで実施できる。

この実施の形態例によれば、配信サーバ１３は、通信事業者２０からの障害復旧メッセージに含まれるアドレスに向けて、ストリームの切り替えを実施するように要求することがでる。

第１１の実施の形態例については、第８〜１０にあるＳ３７，Ｓ５７，Ｓ６５，Ｓ６７を、復旧通知に含まれるＩＰアドレス（が示すデータ表示手段１）にストリームの切り替えを要求するのではなく、「予め受信した障害通知（Ｓ３５，Ｓ５５，Ｓ６３）に含まれているＩＰアドレスに向けて送信する」というようにすることができる。

この実施の形態例によれば、予め受信した障害通知に含まれているＩＰアドレスに向けて制御情報を送信することができる。
次に、第１２の実施の形態例について説明する。図２６，図２７はストリーミングデータ配信システムの処理フローを示す図である。システム構成部としては、図１を用いる。ストリーミング配信システム１１は、制御メッセージを受信するまで待つ（Ｓ３１）。制御メッセージを受信したら、データ表示手段１からの要求メッセージであるかどうかチェックする（Ｓ３２）。要求メッセージでない場合には、通信事業者２０からの障害通知であるかどうかチェックする（Ｓ３４）。

障害通知でなかった場合には、ステップＳ３１に戻る。障害通知であった場合には、障害により影響を受けたユーザ（データ表示手段１）の情報（ＩＰアドレス）を取得し（Ｓ３５）、ステップＳ３１に戻る。ステップＳ３２において、データ表示手段１からの要求メッセージであった場合には、それが再配信要求であるかどうかチェックする（Ｓ３２１）。再配信要求でなかった場合には、要求されたコンテンツを提供できる配信サーバを選び、そのＩＰアドレス、ポート、コンテンツの帯域幅情報を応答として返し（Ｓ３３）、ステップＳ３１に戻る。

ステップＳ３２１で配信要求であった場合には、それはステップＳ３５で取得したＩＰアドレスからであるかどうかチェックする（Ｓ６８）。そうであった場合には、再配信要求テーブルの再配信要求フラグをセットし、再配信要求率＝（再配信フラグがセットされている数）÷（再配信要求テーブルの行数）を計算する（Ｓ７０）。図２８はストリーミングデータ配信システムの管理データを示す図である。図より明らかなように、再配信要求テーブルと再配信実施閾値を示す図である。

再配信要求テーブルは、データ表示手段ＩＰアドレスと、再配信要求フラグを示している。データ表示手段１のＩＰアドレスには、ステップＳ３５で得られたＩＰアドレスが格納される。そして、再配信要求フラグはステップＳ７０で“１”にセットされる。再配信実施閾値は、例えば８０％である。

ステップＳ７０を実行すると、再配信要求率が再配信実施閾値を超えたかどうかチェックする（Ｓ７１）。超えなかった場合には、ステップＳ３１に戻る。超えた場合には、障害発生時刻前から再生したストリームを作成し、上記再配信要求フラグがセットされているＩＰアドレスが示す各データ表示手段１に対して、ストリームの切り替えを実施するようにストリーミングデータ配信システム１１に要求し（Ｓ７２）、ステップＳ３１に戻る。

次に、実施の形態例１２の形態例の全体的な動作について説明する。ここでは、再配信実施閾値を図２７に示すように８０％（つまり、全てのデータ表示手段１から要求が来た場合に再配信を行なう）と設定する。障害により影響を受けたデータ表示手段１のＩＰアドレス（例えば１０．１０．１０．１０と１０．１０．２０．１０）がストリームデータ配信システムに取得するところまでは第１の実施の形態例と同じである（Ｓ３１→Ｓ３２→Ｓ３４→Ｓ３５）。

その後、ネットワークが復旧すると、各データ表示手段１は、独立に再配信要求を送信してくる。ストリーミングデータ配信システム１１は、再配信を要求してきたデータ表示手段１のアドレスを受信ＩＰパケットから取得し、先ほど登録したＩＰアドレスと比較する（Ｓ３１→Ｓ３２→Ｓ３２１→Ｓ６８）。ここで若し、要求してきたデータ表示手段１のＩＰアドレスが．１０．１０．１０であったとすると、先に登録されたＩＰアドレスと一致するので、再配信要求数を１つ繰り上げ、再配信要求率を計算する（Ｓ７０）。

再配信要求率は、（再配信フラグがセットされている数）÷（再配信要求テーブルの行数）で計算される。次に、再配信要求数と実施閾値（今回は２個）を比較する（Ｓ７１）。実施の形態例の再配信要求テーブルでは、再配信要求率が７５％以下であるので再配信は行わない。若し、次に要求してきたデータ表示手段１のＩＰアドレスが１０．１０．２０．１０であった場合は、再配信要求率が再配信実施閾値を超えるため、再配信を実施する。

この実施の形態例によれば、再配信要求率に基づいて再配信を行なうことができる。
（付記１） ストリーミングデータ配信手段を有するストリーミングサービス事業者と、
ルータやネットワークスイッチから構成されるＩＰネットワークと、
ストリーミングデータを受信するストリーミングデータ受信手段と、
該ストリーミングデータ受信手段と前記ストリーミングデータ配信手段との間にあって両者間の制御メッセージを監視する制御メッセージ監視手段と、
ネットワークの物理的な接続構成とその状態を管理するネットワーク状態管理手段、前記メッセージ監視手段からの情報に基づきストリーミングサービスの状態を格納するネットワーク構成情報格納手段、ネットワークのリンク又はノードをキーにそれを利用するユーザを抽出するユーザ抽出手段とからなるストリーミングサービス管理システムとを有する通信事業者と、
で構成され、該通信事業者がネットワークの障害情報から影響を受けるユーザを全て抽出し、前記ストリーミングサービス事業者に通知することを特徴とするストリーミングサービス管理システム。
（付記２） 前記ストリーミングサービス管理システムがネットワークの障害情報から影響を受けるユーザを全て抽出した後、管理システムがストリーミングデータ配信手段に通知することを特徴とする付記１記載のストリーミングサービス管理システム。
（付記３） 前記ストリーミングサービス管理システムがネットワークの障害情報から影響を受けるユーザを全て抽出した後、制御メッセージ監視手段に対し、前記ストリーミングデータ配信手段への影響ユーザに関する情報の通知を要求することを特徴とする付記１記載のストリーミングサービス管理システム。
（付記４） 前記ストリーミングデータ配信手段が、データの送信を行なう配信サーバと、該配信サーバの選択及びユーザの視聴状況を管理する配信マネージャとからなる場合に、ネットワークの障害情報から影響を受けるユーザを全て抽出し、配信マネージャに通知することを特徴とする付記１記載のストリーミングサービス管理システム。
（付記５） 前記ストリーミングデータ配信手段が、データの送信を行なう配信サーバと、該配信サーバの選択及びユーザの視聴状況を管理する配信マネージャとからなる場合に、ネットワークの障害情報から影響を受けるユーザを全て抽出し、配信サーバに通知することを特徴とする付記１記載のストリーミングサービス管理システム。
（付記６） 前記ストリーミングデータ配信手段が、データの送信を行なう配信サーバと、配信サーバの選択及びユーザの視聴状況を管理する配信マネージャとからなる場合に、前記サービス管理システムがネットワークの障害情報から影響を受けるユーザを全て抽出した後、前記制御メッセージ監視手段に対し、配信マネージャへの影響ユーザに関する情報の通知要求をすることを特徴とする付記１記載のストリーミングサービス管理システム。
（付記７） 前記ストリーミングデータ配信手段が、データの送信を行なう配信サーバと、配信サーバの選択及びユーザの視聴状況を管理する配信マネージャとからなる場合に、前記管理システムがネットワークの障害情報から影響を受けるユーザを全て抽出した後、前記制御メッセージを監視する制御メッセージ監視手段に対し、配信サーバへの影響ユーザに関する情報の通知を要求することを特徴とする請求項１記載のストリーミングサービス管理システム。
（付記８） 前記ストリーミングデータ配信手段が、管理システムからの障害情報を格納しておき、通信事業者からの障害復旧情報をトリガに、影響ユーザに対し障害発生時刻まで遡ったストリーミングを配信することを特徴とする付記１記載のストリーミングサービス管理システム。
（付記９） 前記ストリーミングデータ配信手段が、データの送信を行なう配信サーバと配信サーバの選択及びユーザの視聴状況を管理する配信マネージャとからなり、配信マネージャに障害情報が通知される場合に、前記配信マネージャがサービス管理システムからの障害復旧情報をトリガに、影響ユーザに対して障害発生時刻まで遡ったストリーミングを配信することを特徴とする付記４又は６記載のストリーミングサービス管理システム。
（付記１０） 前記ストリーミングデータ配信手段が、データの送信を行なう配信サーバと該配信サーバの選択及びユーザの視聴状況を管理する配信マネージャとからなり、配信サーバに障害情報が通知される場合に、前記配信サーバが管理システムからの障害復旧情報をトリガに、影響ユーザに対して障害発生時刻まで遡ったストリーミングを配信することを特徴とする付記５又は７記載のストリーミングサービス管理システム。
（付記１１） 前記ストリーミングデータ配信手段が、管理システムからの障害情報（影響ユーザ情報）を格納しておき、前記ストリーミングサービス管理システムからの障害復旧情報をトリガに、影響ユーザに対して障害発生時刻まで遡ったストリーミングデータを配信することを特徴とする付記１記載のストリーミングサービス管理システム。
（付記１２） 前記ストリーミングデータ配信手段が前記ストリーミングデータ表示手段からの再送要求が予め格納したストリーミングサービス管理システムからの障害情報（影響ユーザ情報）に含まれているか否かを判断する手段を備え、障害情報に含まれる再送要求の数が予め管理者が設定した閾値を越えた際に、再送要求を送信した影響ユーザに対し、障害発生時刻まで遡ったストリーミングを配信することを特徴とす付記１記載のストリーミングサービス管理システム。

以上、詳細に説明したように、本発明によれば、ＳＩＰ及びＲＴＰを用いた映像配信システムにおいて、配信マネージャ／サーバが従来検出できなかった、また検出できたとしても検出に時間がかかり、かつ障害の発生時刻の判定が困難であった中継ネットワークの障害をメッセージキャプチャを利用することで、ネットワーク管理システム及び映像配信システムに手を加えることなく、迅速かつ正確に検出することができ、障害復旧時の障害発生時刻からのデータ再送等の付加サービスを提供することができるようになる。また、第１２の実施の形態例については、再送要求をしてきたデータ表示手段に対して個別に再配信をするのに比べて、一つの障害に対する再配信ストリーム数（即ち、消費するネットワークリソース）を減らすことができる。

本発明の第１の実施の形態例を示すブロック図である。 ストリーミングデータ表示手段の処理フローを示す図である。 メッセージ監視手段の処理フローを示す図である。 ストリーミングデータ配信システムの処理フローを示す図である。 ストリーミング状態管理手段の処理フローを示す図である。 本発明の第２の実施の形態例を示すブロック図である。 本発明の第３の実施の形態例を示すブロック図である。 ストリーミング状態管理手段の処理フローを示す図である。 メッセージ監視手段の処理フローを示す図である。 本発明の第４の実施の形態例を示すブロック図である。 ストリーミング状態管理手段の処理フローを示す図である。 配信マネージャの処理フローを示す図である。 本発明の第５の実施の形態例を示すブロック図である。 ストリーミング状態管理手段の処理フローを示す図である。 配信サーバの処理フローを示す図である。 本発明の第６の実施の形態例を示すブロック図である。 本発明の第７の実施の形態例を示すブロック図である。 本発明の第８の実施の形態例を示すブロック図である。 ストリーミング状態管理手段の処理フローを示す図である。 ストリーミングデータ配信システムの処理フローを示す図である。 ストリーミング状態管理手段の処理フローを示す図である。 配信マネージャの処理フローを示す図である。 配信サーバの処理フローを示す図である。 ストリーミング状態管理手段の処理フローを示す図である。 配信サーバの処理フローを示す図である。 ストリーミングデータ配信システムの処理フローを示す図である。 ストリーミングデータ配信システムの処理フローを示す図である。 ストリーミングデータ配信システムの管理データを示す図である。 従来システムの構成例を示すブロック図である。

符号の説明

１ ストリーミングデータ表示手段
１０ ストリーミングサービス事業者
１１ ストリーミングデータ配信システム
２０ 通信事業者
２１ ルータ（ノード）
２２ ネットワーク状態管理手段
２３ ネットワーク構成情報格納手段
２４ メッセージ監視手段
２５ ストリーミングサービス管理システム
２５ａ ネットワーク／サービス関係管理手段
２５ｂ ストリーミング状態管理手段

Claims (4)

1. 端末のアドレスを記憶する記憶部を有するコンピュータに、
   障害に関する障害通知を受信すると、該障害により影響を受けた端末のアドレスを該障害通知から抽出して、該アドレスを前記記憶部に記憶する処理と、
   端末からデータの再配信要求を受信すると、前記記憶部に記憶されたアドレスを有する端末のうち、いくつの端末から再配信要求を受信したかに応じて、再配信要求を送信した各端末に対して該データの再配信を実行する制御を行なう処理と、
   を実行させることを特徴とするストリーミングサービス管理プログラム。
2. 前記処理は、前記いくつかの端末から再配信要求を受信したかを表す端末数が閾値を超えたら、再配信要求を送信した各端末に対して前記データの再配信を実行する制御を行なうことを特徴とする請求項１記載のストリーミングサービス管理プログラム。
3. 端末のアドレスを記憶する記憶部を有するコンピュータを備え、
   障害に関する障害通知を受信すると、該障害により影響を受けた端末のアドレスを該障害通知から抽出して、該アドレスを前記記憶部に記憶する処理と、
   端末からデータの再配信要求を受信すると、前記記憶部に記憶されたアドレスを有する端末のうち、いくつの端末から再配信要求を受信したかに応じて、再配信要求を送信した各端末に対して該データの再配信を実行する制御を行なう処理と、
   から構成されることを特徴とするストリーミングサービス管理方法。
4. 前記処理は、前記いくつかの端末から再配信要求を受信したかを表す端末数が閾値を超えたら、再配信要求を送信した各端末に対して前記データの再配信を実行する制御を行なうことを特徴とする請求項３記載のストリーミングサービス管理方法。

Images