JP2015154128A - マルチキャスト中継装置、マルチキャスト配信システム及びマルチキャスト配信方法 - Google Patents

Abstract

【課題】利用者の属性に応じて配信経路が動的に構築されるマルチキャスト中継装置を提供する。【解決手段】複数の配信サーバのそれぞれに設定されたアドレスを仮想化した仮想化アドレスが配信要求に含まれている場合、配信を利用する利用者の属性情報に基づいて配信サーバのいずれかを決定する配信サーバ決定部２８２と、配信サーバ決定部２８２によって決定された配信サーバから端末装置にマルチキャストトラフィックが配信される配信経路を構築するルーティングプロトコル処理部２８１及び方路設定部２８３と、を有する。【選択図】図２

Description

本件は、マルチキャスト中継装置、マルチキャスト配信システム及びマルチキャスト配信方法に関する。

インターネットを利用して動画を配信する技術として、ＩＰマルチキャストが知られている。ＩＰマルチキャストでは、動画をマルチキャストトラフィックにより配信する配信サーバと配信された動画を受信する端末装置が利用される。配信サーバと端末装置との間には、配信サーバから配信されたマルチキャストトラフィックを中継する中継装置が設置される。例えば、配信元の配信サーバを特定するサーバアドレスとマルチキャストグループを特定するグループアドレスを含む番組表に基づいて、端末装置から動画の配信要求としてマルチキャストグループへの参加要求が送信されると、中継装置によって配信サーバと端末装置との間にマルチキャストトラフィックの配信経路が構築される。配信サーバから配信されるマルチキャストトラフィックは、構築された配信経路に従って端末装置に配信される。

上述したＩＰマルチキャストでは種々の技術が提案されている。例えば、ＩＰマルチキャストで複数の配信サーバが利用された場合に、配信サーバを特定していない配信要求が端末装置から送信されると、端末装置と接続された中継装置が優先度に応じて配信サーバを選択する技術が提案されている（例えば、特許文献１参照）。また、インターネットを用いる放送型サービスでは、仮想インターネットアドレスを受け付けた場合に、該仮想インターネットアドレスを、コンテンツを利用者に参照させるコンテンツ制御装置のインターネットアドレスに変換する技術も知られている（例えば、特許文献２参照）。

特開２００５−７２７５６号公報 特開平１１−８５６５０号公報

上述したように、参加要求を受信した中継装置はサーバアドレス及びグループアドレスに基づいて配信経路を構築する。しかしながら、例えば配信事業者と配信利用者との契約種別の変更（例えば仮契約から本契約への変更）といった利用者の属性の変更に基づいて配信サーバを切り替える場合、切り替え後の配信サーバと端末装置との配信経路を構築するために、端末装置はサーバアドレスとグループアドレスを含む番組表を新たに取得し直し、これらのアドレスを含む参加要求を別途送信する必要がある。すなわち、利用者の属性が変更されても、配信経路は動的に切り替わらないという問題点がある。

そこで、１つの側面では、本件は、利用者の属性に応じて配信経路が動的に構築されるマルチキャスト中継装置、マルチキャスト配信システム及びマルチキャスト配信方法を提供することを目的とする。

本明細書に開示のマルチキャスト中継装置は、複数の配信サーバのそれぞれに設定されたアドレスを仮想化した仮想化アドレスが配信要求に含まれている場合、配信を利用する利用者の属性情報に基づいて前記配信サーバのいずれかを決定する決定手段と、前記決定手段によって決定された配信サーバから端末装置にマルチキャストトラフィックが配信される配信経路を構築する構築手段と、を有するマルチキャスト中継装置である。

本明細書に開示のマルチキャスト配信システムは、上述したマルチキャスト中継装置と、前記属性情報を管理する管理手段と、前記属性情報が変更された場合に変更後の前記属性情報を前記マルチキャスト中継装置に通知する通知手段とを含む管理装置と、を有するマルチキャスト配信システムである。

本明細書に開示のマルチキャスト配信方法は、配信を利用する利用者の属性情報が変更された場合に変更後の前記属性情報を通知する通知ステップと、複数の配信サーバのそれぞれに設定されたアドレスを仮想化した仮想化アドレスが配信要求に含まれている場合、前記通知ステップによって通知された変更後の前記属性情報に基づいて前記配信サーバのいずれかを決定する決定ステップと、前記決定ステップによって決定された配信サーバから端末装置にマルチキャストトラフィックが配信される配信経路を構築する構築ステップと、を有するマルチキャスト配信方法である。

本明細書に開示のマルチキャスト中継装置、マルチキャスト配信システム及びマルチキャスト配信方法によれば、利用者の属性に応じて配信経路を動的に構築することができる。

図１は、マルチキャスト配信システムの一例を説明するための図である。 図２は、ＬＨＲのブロック図の一例である。 図３（ａ）は、ユニキャストルーティングテーブルの一例である。図３（ｂ）は、マルチキャストルーティングテーブルの一例である。図３（ｃ）は、変換テーブルの一例である。図３（ｄ）は、利用者情報テーブルの一例である。図３（ｅ）は、サーバ管理テーブルの一例である。 図４は、ＬＨＲのハードウェア構成の一例である。 図５は、ＬＨＲの動作の一例を示すフローチャートである。 図６（ａ）は、第１の参加要求のメッセージフォーマットの一例である。図６（ｂ）は、変換テーブルの一例である。図６（ｃ）は、マルチキャストルーティングテーブルの一例である。図６（ｄ）は、ＬＨＲ−ＦＨＲ間で用いられる第２の参加要求のメッセージフォーマットの一例である。図６（ｅ）は、ＬＨＲ−ＦＨＲ間で用いられる第２の参加要求のメッセージフォーマットの他の一例である。 図７は、パケット配信システムの動作の一例を説明するための図である。 図８は、パケット配信システムの動作の一例を説明するための図である。 図９は、パケット配信システムの動作の一例を説明するための図である。 図１０は、マルチキャストパケットの一例である。 図１１は、パケット配信システムのシーケンスの一例である。 図１２は、ＬＨＲの動作の一部を例示するフローチャートである。 図１３（ａ）は、サーバ管理テーブルの他の一例である。図１３（ｂ）は、変換テーブルの他の一例である。図１３（ｃ）は、マルチキャストルーティングテーブルの他の一例である。 図１４は、管理サーバのブロック図である。 図１５は、管理サーバのハードウェア構成の一例である。 図１６は、管理サーバの動作の一例を示すフローチャートである。 図１７は、利用者情報の変更例を説明するための図である。 図１８は、配信経路が切り替えられる前のマルチキャスト中継システムの動作を説明するための図である。 図１９は、ＬＨＲ（ユーザ管理部）の動作の一例を示すフローチャートである。 図２０は、ＬＨＲ（マルチキャスト経路制御部）の動作の一例を示すフローチャートである。 図２１（ａ）は、更新前後の変換テーブルを説明するための図である。図２１（ｂ）は、マルチキャストルーティングテーブルが変更される様子を説明するための図である。 図２２は、配信経路が切り替えられた後のマルチキャスト中継システムの動作を説明するための図である。 図２３は、パケット配信システムのシーケンスの他の一例である。 図２４（ａ）は、サーバ管理テーブルの他の一例である。図２４（ｂ）は、管理サーバの動作の一例を示すフローチャートである。 図２５は、配信経路が切り替えられる前のマルチキャスト中継システムの動作を説明するための図である。 図２６は、ＬＨＲ（ユーザ管理部）の動作の一例を示すフローチャートである。 図２７は、配信経路が切り替えられた後のマルチキャスト中継システムの動作を説明するための図である。

以下、本件を実施するための形態について図面を参照して説明する。

（第１実施形態）
図１は、マルチキャスト配信システムＳの一例を説明するための図である。
図１に示すように、マルチキャスト配信システムＳは、少なくとも管理サーバ１００とLast Hop Router（ＬＨＲ：ラストホップルータ）２００とを含んでいる。マルチキャスト配信システムＳには、端末装置３００，３１０と少なくとも２つの配信サーバ４００，４１０が含まれていてもよい。尚、端末装置３００，３１０としては、例えばPersonal Computer（ＰＣ）、タブレット型端末、スマートフォンを含む携帯電話機などがある。

管理サーバ１００は、配信サーバ４００，４１０が配信する動画の番組表、配信事業者と配信利用者との配信契約を含む利用者の属性情報などを管理する。管理サーバ１００はＬＨＲ２００と接続されており、ＬＨＲ２００に各種の情報を通知する。

ＬＨＲ２００は、ＩＰネットワーク１０の端末装置３００，３１０側の境界に設置されたエッジルータである。ＬＨＲ２００は、各端末装置３００，３１０及び隣接するNext Hop Router（ＮＨＲ：ネクストホップルータ）５００,５１０と接続されている。例えば、端末装置３００，３１０とはそれぞれインタフェース「Ｇ０１」，「Ｇ０２」を介して接続されている。ＮＨＲ５００，５１０とはそれぞれインタフェース「Ｇ１００」，「Ｇ１０１」を介して接続されている。ＬＨＲ２００は、配信要求として端末装置３００から送信された第１の参加要求を受信して、第１の参加要求のプロトコル（例えばMulticast Listener Discovery Version 2（ＭＬＤｖ２））と異なるプロトコル（例えばProtocol Independent Multicast-Source Specific Mode（ＰＩＭ−ＳＳＭ））でＮＨＲ５００,５１０に第２の参加要求を送信する。第１及び第２の参加要求は、マルチキャストグループに参加するための要求である。また、ＬＨＲ２００は、ＮＨＲ５００,５１０から出力されたマルチキャストパケット２０を受信して、第１の参加要求を送信した端末装置３００又は端末装置３１０にマルチキャストパケット２０を中継する。尚、マルチキャストパケット２０は、例えば所定の時刻になると配信サーバ４００，４１０から番組表の内容に沿うようにそれぞれ配信される。一例を挙げると、配信サーバ４００，４１０はそれぞれ同じ内容であるが品質の異なるマルチキャストパケット２０を配信する。

次に、図２及び図３を参照して、上述したＬＨＲ２００の詳細について説明する。

図２は、ＬＨＲ２００のブロック図の一例である。図３（ａ）は、ユニキャストルーティングテーブルの一例である。図３（ｂ）は、マルチキャストルーティングテーブルの一例である。図３（ｃ）は、変換テーブルの一例である。図３（ｄ）は、利用者情報テーブルの一例である。図３（ｅ）は、サーバ管理テーブルの一例である。

ＬＨＲ２００は、図２に示すように、ＵＣテーブル記憶部２１０、ＭＣテーブル記憶部２２０、通知情報記憶部２３０、第１送受信部２４０、第２送受信部２５０、パケット転送部２６０、ユニキャスト経路制御部２７０、マルチキャスト経路制御部２８０及びユーザ管理部２９０を含んでいる。

ＵＣテーブル記憶部２１０は、ユニキャストルーティングテーブルを記憶する。ユニキャストルーティングテーブルは、図３（ａ）に示すように、宛先アドレス、送信元アドレス、ネクストホップアドレス、方路名及びメトリックを構成要素として含んでいる。当該ユニキャストルーティングテーブルによれば、例えば、宛先アドレスがFirst Hop Router（ＦＨＲ：ファーストホップルータ）６００に割り当てられたＩＰアドレス「Ｒ３」であって、送信元アドレスがＬＨＲ２００に割り当てられたＩＰアドレス「Ｒ１」である第２の参加要求は、ＩＰアドレス「Ｒ２」が割り当てられたＮＨＲ５００に中継するために、パケット転送部２６０から方路名「Ｇ１００」を有する第２送受信部２５０に出力される。同様に、宛先アドレスがＦＨＲ６１０に割り当てられたＩＰアドレス「Ｒ５」であって、送信元アドレスがＬＨＲ２００に割り当てられたＩＰアドレス「Ｒ１」である第２の参加要求は、ＩＰアドレス「Ｒ４」が割り当てられたＮＨＲ５１０に中継するために、パケット転送部２６０から方路名「Ｇ１０１」を有する第２送受信部２５０に出力される。

ＭＣテーブル記憶部２２０は、マルチキャストルーティングテーブル及び変換テーブルを記憶する。マルチキャストルーティングテーブルは、マルチキャストパケット２０の転送先を決定するテーブルである。マルチキャストルーティングテーブルは、図３（ｂ）に示すように、エントリー名及び方路名を経路情報として含んでいる。エントリー名は、Source Address（ＳＡ：ソースアドレス）とGroup Address（ＧＡ：グループアドレス）を構成要素として含み、方路名は、Incoming Interface（ＩＩＦ：入方路）とOutgoing Interface（ＯＩＦ：出方路）を構成要素として含んでいる。マルチキャストルーティングテーブルに設定された入方路から所定のエントリー名を有するマルチキャストパケット２０が入力された場合、当該マルチキャストパケット２０はマルチキャストルーティングテーブルに基づいて、設定された出方路から出力される。

変換テーブルは仮想アドレスを配信サーバ４００又は配信サーバ４１０の現実のサーバアドレスに変換するテーブルである。変換テーブルは、図３（ｃ）に示すように、受信ソースアドレス、受信グループアドレス、端末アドレス、優先度及び変換後ソースアドレスを変換情報として含んでいる。優先度は利用者の属性（例えば契約の種別など）に応じて優先的に利用する配信サーバ４００，４１０を決定する情報である。例えば、第１の参加要求に仮想化アドレス「Ｖ−Ａ」が含まれていれば、変換テーブルによって配信サーバ４００又は配信サーバ４１０の現実のサーバアドレスに変換される。

通知情報記憶部２３０は、利用者情報テーブル及びサーバ管理テーブルを記憶する。利用者情報テーブル及びサーバ管理テーブルは予め設定されているか、管理サーバ１００から通知される。利用者情報テーブルは、図３（ｄ）に示すように、ユーザＩＤ、端末アドレス、利用者の属性情報及び利用中の配信サーバのサーバアドレスを利用者情報として有する。ユーザＩＤは、利用者を識別する識別情報である。端末アドレスは、利用者が使用する端末装置３００，３１０のＩＰアドレスである。属性情報は、利用者の属性に関する情報であって、例えば仮契約や本契約といった契約種別、ノーマルクラスやハイクラスといった会員クラス（又は会員種別）、動画を視聴可能な時間を制限する視聴制限時間等を含んでいる。配信サーバアドレスは、配信サーバ４００，４１０のサーバアドレスである。本実施形態では、配信サーバ４００にサーバアドレス「Ａ−１」が割り当てられている。配信サーバ４１０にサーバアドレス「Ａ−２」が割り当てられている。したがって、例えば配信事業者と仮契約を締結しているユーザＩＤ「Ｕ−Ｓ１」の利用者が使用する端末装置３００にはＩＰアドレス「Ｓ１」が設定されており、当該利用者はサーバアドレス「Ａ−１」の配信サーバ４００から配信される動画を１２時間に限り視聴できる。尚、図３（ｄ）に示すように、仮解約を締結した利用者と本契約を締結した利用者とでは配信サーバ４００，４１０が異なっている。これにより、例えば動画の品質を差別化できる。一例を挙げると、仮契約の利用者が動画を視聴する場合には、配信サーバ４００は本契約への移行を勧める広告を含む動画を配信し、当該利用者が本契約となった場合、配信サーバ４１０は広告を含まない動画を配信する。

サーバ管理テーブルは、配信サーバ４００，４１０に関する各種情報を管理する。サーバ管理テーブルは、図３（ｅ）に示すように、ソースアドレス及びグループアドレスを要素とするエントリー名、配信サーバ４００，４１０のアドレス及び優先度をサーバ情報として有している。サーバ管理テーブルによれば、エントリー名「Ｖ−Ａ，Ｇ１」である第１の参加要求対し、属性に応じた優先度が「優先１」であればサーバアドレス「Ａ−１」の配信サーバ４００が割り当てられ、属性に応じた優先度が「優先２」であればサーバアドレス「Ａ−２」の配信サーバ４１０が割り当てられる。

第１送受信部２４０は、インタフェースとして複数の入方路及び出方路を有している。第１送受信部２４０は、端末装置３００又は端末装置３１０から送信された第１の参加要求を受信し、パケット転送部２６０に出力する。また、パケット転送部２６０から出力されたマルチキャストパケット２０を端末装置３００又は端末装置３１０に送信する。
第２送受信部２５０は、インタフェースとして複数の入方路及び出方路を有している。第２送受信部２５０は、ＮＨＲ５００又はＮＨＲ５１０から送信されたマルチキャストパケットを受信し、パケット転送部２６０に出力する。また、パケット転送部２６０から出力された第２の参加要求をＮＨＲ５００又はＮＨＲ５１０に送信する。
パケット転送部２６０は、第１送受信部２４０から出力された第１の参加要求を受信すると、第２の参加要求をユニキャストルーティングテーブルに基づいて第２送受信部２５０に出力する。また、パケット転送部２６０は、第２送受信部２５０から出力されたマルチキャストパケットを受信すると、当該マルチキャストパケットをマルチキャストルーティングテーブルに基づいて第１送受信部２４０に出力する。

ユニキャスト経路制御部２７０は、ユニキャストルーティングテーブルを制御する。ユニキャスト経路制御部２７０は、ルーティングプロトコル処理部２７１を有する。ルーティングプロトコル処理部２７１は、ユニキャストルーティングテーブルを送受信したり、メトリックに基づいてユニキャストルーティングテーブルを生成したり更新したりする。生成されたユニキャストルーティングテーブルは、ＵＣテーブル記憶部２１０に保存される。

マルチキャスト経路制御部２８０は、マルチキャストルーティングテーブルを制御する。マルチキャスト経路制御部２８０は、ルーティングプロトコル処理部２８１、配信サーバ決定部２８２及び方路設定部２８３を有する。ルーティングプロトコル処理部２８１は、方路が設定されたマルチキャストルーティングテーブルに基づいて、配信経路（配信ツリー）を生成（構築）したり更新したりする。配信サーバ決定部２８２は、配信サーバ４００，４１０のそれぞれに設定されたサーバアドレス「Ａ−１」，「Ａ−２」を仮想化した仮想化アドレス「Ｖ−Ａ」が第１の参加要求に含まれている場合、利用者の属性情報に基づいて配信サーバ４００，４１０のいずれかを決定する。方路設定部２８３は、配信サーバ決定部２８２によって決定された配信サーバ４００又は配信サーバ４１０に基づいて、マルチキャストルーティングテーブルに方路を設定する。

ユーザ管理部２９０は、利用者情報及びサーバ情報を管理する。ユーザ管理部２９０は、通知情報管理部２９１を有している。通知情報管理部２９１は、例えば管理サーバ１００から通知された利用者情報及びサーバ情報を受信して通知情報記憶部２３０に登録する。したがって、図３（ｄ）及び（ｅ）を参照して説明した利用者情報テーブル及びサーバ管理テーブルが通知情報記憶部２３０に保存される。

次に、図４を参照して、上述したＬＨＲ２００のハードウェア構成について説明する。

図４は、ＬＨＲ２００のハードウェア構成の一例である。尚、ＮＨＲ５００，５１０及びＦＨＲ６００，６１０についても基本的にＬＨＲ２００と同様の構成を有する。
ＬＨＲ２００は、Central Processing Unit（ＣＰＵ）２００Ａ、Random Access Memory（ＲＡＭ）２００Ｂ、Read Only Memory（ＲＯＭ）２００Ｃ、通信Interface（Ｉ／Ｆ：インタフェース）２００Ｄ、Field-Programmable gate array（ＦＰＧＡ）２００Ｅ及び回線Ｉ／Ｆ２００Ｆを含んでいる。これらの各機器２００Ａ〜２００Ｅは、内部バス２００Ｇによって互いに接続されている。また、ＦＰＧＡ２００ＥはＲＡＭ２００Ｂ及び回線Ｉ／Ｆ２００Ｆと内部バス２００Ｇと異なる通信路で接続されている。

通信Ｉ／Ｆ２００Ｄは、例えばRegistered Jack 45（ＲＪ−４５）とPhysical Layer Chip（ＰＨＹチップ）とを備えている。ＬＨＲ２００は、通信Ｉ／Ｆ２００Ｄを介して管理サーバ１００と接続される。
ＦＰＧＡ２００Ｅは、設計に基づいてプログラミングされることにより、パケット転送部２６０の機能を実現する。
回線Ｉ／Ｆ２００Ｆは、例えばSmall Form-Factor Pluggable（ＳＦＰ）とＰＨＹチップとを備えている。回線Ｉ／Ｆ２００Ｆは、第１送受信部２４０及び第２送受信部２５０の機能を実現する。

ＲＡＭ２００Ｂは、上述したＵＣテーブル記憶部２１０、ＭＣテーブル記憶部２２０及び通知情報記憶部２３０を実現する。また、ＲＡＭ２００Ｂは、ＲＯＭ２００Ｃに記憶されたプログラムを読み込む。読み込まれたプログラムをＣＰＵ２００Ａが実行することにより、ＵＣテーブル記憶部２１０、ＭＣテーブル記憶部２２０、通知情報記憶部２３０、第１送受信部２４０、第２送受信部２５０及びパケット転送部２６０を除くＬＨＲ２００の各部２７１〜２９１が実現される。また、読み込まれたプログラムをＣＰＵ２００Ａが実行することにより、後述する各種ステップが実行される。尚、プログラムは後述するフローチャートに応じたものとすればよい。

次に、図５乃至図１０を参照して、ＬＨＲ２００の動作とパケット配信システムＳの動作について説明する。

図５は、ＬＨＲ２００の動作の一例を示すフローチャートである。図６（ａ）は、第１の参加要求のメッセージフォーマットの一例である。図６（ｂ）は、変換テーブルの一例である。図６（ｃ）は、マルチキャストルーティングテーブルの一例である。図６（ｄ）は、ＬＨＲ−ＦＨＲ間で用いられる第２の参加要求のメッセージフォーマットの一例である。図６（ｅ）は、ＬＨＲ−ＦＨＲ間で用いられる第２の参加要求のメッセージフォーマットの他の一例である。図７乃至図９は、パケット配信システムＳの動作の一例を説明するための図である。図１０は、マルチキャストパケット２０の一例である。

まず、図７に示すように、ユーザＩＤ「Ｕ−Ｓ１」を有する利用者が動画を視聴するために端末装置３００を操作して、管理サーバ１００から番組表を取得する。この場合、管理サーバ１００は、グループアドレス「Ｇ１」、配信サーバ４００，４１０のサーバアドレス「Ａ−１」，「Ａ−２」が仮想化された仮想化アドレス「Ｖ−Ａ」を含む番組表を端末装置３００に送信する。番組表を取得した端末装置３００は、ＬＨＲ２００から送信された所定のメッセージ（例えばクエリメッセージ）に応じて、グループアドレス「Ｇ１」、仮想化アドレス「Ｖ−Ａ」を含む第１の参加要求を定期的に送信する。第１の参加要求についてより詳しく説明すると、図６（ａ）に示すように、グループアドレス「Ｇ１」と仮想化アドレス「Ｖ−Ａ」が第１の参加要求のデータ部に格納され、ヘッダ部である送信元アドレスと宛先アドレスにそれぞれ端末装置３００のアドレス「Ｓ１」と固定値「ＦＦ０２：：１６」が格納されている。尚、図７に示すように、番組表に沿った動画のマルチキャストパケット２０が配信サーバ４００，４１０から既にＦＨＲ６００，６１０にそれぞれ配信されている。

ここで、図５に示すように、まず、配信サーバ決定部２８２は、第１送受信部２４０から、パケット転送部２６０及びルーティングプロトコル制御部２８１を介して取得した第１の参加要求に仮想化アドレスが含まれているか否かを判断する（ステップＳ１０１）。例えば、配信サーバ決定部２８２が仮想化アドレスを含む第１の参加要求（図６（ａ）参照）を取得した場合、配信サーバ決定部２８２は、第１の参加要求に仮想化アドレスが含まれていると判断する（ステップＳ１０１：ＹＥＳ）。

次いで、通知情報管理部２９１は、第１の配信要求に含まれる送信元アドレスに基づいて、通知情報記憶部２３０から対応するサーバアドレスと優先度を取得する（ステップＳ１０２）。通知情報記憶部２３０には、図３（ｄ）及び（ｅ）に示すように、管理サーバ１００から通知された利用者情報及びサーバ情報が含まれているため、図６（ａ）に示すように、第１の配信要求の送信元アドレスに端末装置３００の端末アドレス「Ｓ１」が含まれていれば、通知情報管理部２９１は利用者管理テーブルから契約種別「仮契約」を含む属性情報を取得し、取得した属性情報に対応する優先度「優先１」及びサーバアドレス「Ａ−１」をサーバ管理テーブルから取得できる。通知情報管理部２９１は、取得したサーバアドレスと優先度を配信サーバ決定部２８２に出力する。

次いで、ルーティングプロトコル処理部２７１は、配信サーバ決定部２８２に出力されたサーバアドレスに基づいて、第２の参加要求の方路を決定する（ステップＳ１０３）。上述したように、サーバアドレス「Ａ−１」が配信サーバ決定部２８２に出力されていれば、ルーティングプロトコル処理部２７１は、図３（ａ）に示すように、サーバアドレス「Ａ−１」に対応する方路「Ｇ１００」を決定する。ルーティングプロトコル処理部２７１は、決定した方路「Ｇ１００」を配信サーバ決定部２７１に出力する。

次いで、配信サーバ決定部２８２は、第１の参加要求に格納される情報と取得したサーバアドレスと優先度を変換テーブルに設定する（ステップＳ１０４）。この結果、第１の参加要求に格納されたソースアドレス「Ｖ−Ａ」、グループアドレス「Ｇ１」、送信元アドレス（端末アドレス）「Ｓ１」がそれぞれ、図６（ｂ）に示すように、受信ソースアドレス、受信グループアドレス及び端末アドレスに登録される。また、取得した優先度「優先１」及びサーバアドレス「Ａ−１」がそれぞれ、図６（ｂ）に示すように、優先度及び変換後ソースアドレスに登録される。

次いで、方路設定部２８３は、マルチキャストルーティングテーブルに入方路及び出方路を設定する（ステップＳ１０５）。例えば、方路設定部２８３は、配信サーバ決定部２８２から変換後ソースアドレス「Ａ−１」と対応するグループアドレス「Ｇ１」と方路「Ｇ１００」を取得する。取得した変換後ソースアドレス「Ａ−１」、グループアドレス「Ｇ１」及び方路「Ｇ１００」をそれぞれ、図６（ｃ）に示すように、マルチキャストテーブルのソースアドレス、グループアドレス及び入方路に設定する。一方、第１の配信要求を受信した入方路「Ｇ０１」を、図６（ｃ）に示すように、出方路に設定する。

次いで、配信サーバ決定部２８２は、ルーティングプロトコル処理部２８１に配信経路生成処理を起動させる（ステップＳ１０６）。これにより、ルーティングプロトコル処理部２８１は配信経路生成処理を起動する。具体的には、図６（ｄ）に示すように、ソースアドレス「Ａ−１」、グループアドレス「Ｇ１」及び自己のアドレス「Ｒ１」をデータ部に含む第２の参加要求を生成し、パケット転送部２６０に出力する。パケット転送部２６０は、ＵＣテーブル記憶部２１０に記憶されたユニキャストルーティングテーブルに基づいて、方路名「Ｇ１００」の第２送受信部２５０に出力する。第２送受信部２５０は第２の配信要求をＮＨＲ５００に送信する。この結果、図８に示すように、第２の参加要求がＬＨＲ２００からＮＨＲ５００に送信される。

第２の参加要求を受信したＮＨＲ５００は、ＬＨＲ２００と同様の処理により、図６（ｅ）に示すように、第２の参加要求のデータ部に自己のアドレス「Ｒ２」を格納し、図８に示すように、第２の参加要求をＦＨＲ６００に送信する。したがって、図９に示すように、第１の参加要求及び第２の参加要求を受信した各ルータでは入方路及び出方路が設定されて配信経路Ｔが構築される。配信サーバ４００と端末装置３００との配信経路Ｔが構築されると、配信経路に従ってＦＨＲ６００に配信されていたマルチキャストパケット２０がＮＨＲ５００を介してＬＨＲ２００に入力される。ＬＨＲ２００では、変換テーブルに基づいて、送信元アドレスに格納されていたサーバアドレス「Ａ−２」（図１０（ａ）参照）が、図１０（ｂ）に示すように、仮想化アドレス「Ｖ−Ａ」に変換される。ＬＨＲ２００は、図９に示すように、送信元アドレスが変換されたマルチキャストパケット２０を端末装置３００に送信する。これにより、端末装置３００の利用者は動画を視聴できる。尚、連続するマルチキャストパケット２０によりマルチキャストトラフィックが形成される。

次に、図１１を参照して、以上説明したパケット配信システムＳのシーケンスを説明する。
図１１は、パケット配信システムＳのシーケンスの一例である。
図１１に示すように、配信サーバ４００，４１０からそれぞれマルチキャストパケット２０が配信されている状態で、端末装置３００から第１の参加要求が送信されると、ＬＨＲ２００は第１の参加要求を受信し、受信した第１の参加要求に応じて第２の参加要求をＮＨＲ５００に送信する。ＮＨＲ５００は受信した第２の参加要求を自己のユニキャストルーティングテーブルに従ってＦＨＲ６００に送信する。

第２の参加要求を受信したＦＨＲ６００は、構築された配信経路に従ってマルチキャストパケット２０をＮＨＲ５００に送信し、ＮＨＲ５００は受信したマルチキャストパケット２０を同様にＬＨＲ２００に送信する。ＬＨＲ２００は、マルチキャストパケット２０の送信元アドレスを配信元のサーバアドレスから仮想化アドレスに変換し、送信元アドレスを変換したマルチキャストパケット２０を端末装置３００に送信する。この結果、端末装置３００では動画が表示される。

以上、第１実施形態によれば、配信サーバ４００，４１０のそれぞれに設定されたサーバアドレス「Ａ−１」，「Ａ−２」を仮想化した仮想化アドレス「Ｖ−Ａ」が第１の参加要求に含まれている場合、第１の参加要求を出力した端末装置３００を操作する利用者の属性情報（例えば契約種別、会員種別、視聴制限時間等）に基づいて配信サーバ４００，４１０のいずれかを決定し、決定した配信サーバ４００，４１０のいずれかから端末装置３００にマルチキャストパケット２０が配信される配信経路Ｔを構築することで、利用者の属性に応じた配信経路を動的に構築することができる。

（第２実施形態）
次に、図１２及び図１３を参照して本件の第２実施形態について説明する。
図１２は、ＬＨＲ２００の動作の一部を例示するフローチャートである。図１３（ａ）は、サーバ管理テーブルの他の一例である。図１３（ｂ）は、変換テーブルの他の一例である。図１３（ｃ）は、マルチキャストルーティングテーブルの他の一例である。図１２に示すように、ＬＨＲ２００の動作は、図５を参照して説明したＬＨＲ２００の動作と比べて、ステップＳ１０２及びステップＳ１０４の処理が相違する。また、図１３（ａ）に示すように、サーバ管理テーブルでは使用時間帯が管理されている点、及び図１３（ｂ）に示すように、時間帯毎に変換テーブルが設けられる点で図３（ｅ）及び図３（ｃ）と相違する。

例えば、図１３（ａ）に示すように、優先度「優先１」で使用するサーバアドレス「Ａ−１」の配信サーバ４００は、使用時間帯「８：００−１６：００」に限り使用できる。優先度「優先２」で使用するサーバアドレス「Ａ−２」の配信サーバ４１０は、使用時間帯「１６：００−８：００」に限り使用できる。また、図１３（ｂ）に示すように、使用時間帯「８：００−１６：００」を表す時間帯Ａと使用時間帯「１６：００−８：００」を表す時間帯Ｂによって、変換テーブルは切り替わる。同様に、図１３（ｃ）に示すように、マルチキャストルーティングテーブルのルーティング情報も時間帯により切り替わる。例えば時間帯Ａであれば入方路「Ｇ１００」を含むルーティング情報が利用され、時間帯Ｂであれば入方路「Ｇ１０１」を含むルーティング情報が利用される。

ここで、第２実施形態におけるＬＨＲ２００の動作を説明すると、まず、図１２に示すように、第１実施形態で説明したステップＳ１０１の処理で第１の参加要求に仮想化アドレスが含まれていると判断されると（ステップＳ１０１：ＹＥＳ）、通知情報管理部２９１は、第１の配信要求に含まれる送信元アドレスに基づいて、通知情報記憶部２３０から対応するサーバアドレスと優先度と時間帯を取得する（ステップＳ１１０）。通知情報記憶部２３０には、図３（ｄ）及び図１３（ａ）に示すように、管理サーバ１００から通知された利用者情報及びサーバ情報が含まれているため、図６（ａ）に示すように、第１の配信要求の送信元アドレスに端末装置３００の端末アドレス「Ｓ１」が含まれていれば、通知情報管理部２９１は利用者管理テーブルから対応する属性情報を取得し、取得した属性情報に対応する優先度「優先１」、サーバアドレス「Ａ−１」及び使用時間帯「８：００−１６：００」をサーバ管理テーブルから取得できる。通知情報管理部２９１は、取得したサーバアドレスと優先度と時間帯を配信サーバ決定部２８２に出力する。

また、図１２に示すように、ステップＳ１１０とステップＳ１０３の処理が完了すると、配信サーバ決定部２８２は、第１の参加要求に格納される情報と取得したサーバアドレスと優先度を時間帯毎の変換テーブルに設定する（ステップＳ１１１）。この結果、第１の参加要求に格納されたソースアドレス「Ｖ−Ａ」、グループアドレス「Ｇ１」、送信元アドレス（端末アドレス）「Ｓ１」がそれぞれ、図１３（ｂ）に示すように、各時間帯における受信ソースアドレス、受信グループアドレス及び端末アドレスに登録される。また、取得した優先度「優先１」及びサーバアドレス「Ａ−１」がそれぞれ、時間帯Ａの優先度及び変換後ソースアドレスに登録される。取得した優先度「優先２」及びサーバアドレス「Ａ−２」がそれぞれ、時間帯Ｂの優先度及び変換後ソースアドレスに登録される。その後、ステップＳ１０５の処理及びＳ１０６の処理が行われる。

したがって、時間帯ＡにＬＨＲ２００が仮想化アドレス「Ｖ−Ａ」を含む第１の参加要求を端末装置３００から受信した場合、ユーザＩＤ「Ｕ−Ｓ１」の利用者は仮契約者であるため優先度「優先１」が適用され、時間帯Ａの変換テーブルに基づいて、変換後ソースアドレス「Ａ−１」が決定される。また、マルチキャストルーティングテーブルにおいて入方路「Ｇ１００」を含むルーティング情報が決定される。この結果、図９に示すように、配信経路Ｔが構築され、配信サーバ４００からマルチキャストパケット２０が端末装置３００に配信される。逆に、時間帯ＢにＬＨＲ２００が仮想化アドレス「Ｖ−Ａ」を含む第１の参加要求を端末装置３００から受信した場合、ユーザＩＤ「Ｕ−Ｓ１」の利用者は仮契約者であるため優先度「優先１」が同様に適用されるものの、時間帯Ｂの変換テーブルには優先度「優先２」が登録されているため、優先度は一致しない。したがって、変換後ソースアドレスを取得できないため、時間帯Ｂではマルチキャストパケット２０が端末装置３００に配信されない。

以上、第２実施形態によれば、第１実施形態で説明したサーバ管理テーブルに配信サーバ４００，４１０の使用時間帯を設け、使用時間帯に変換テーブルを生成するとともに、マルチキャストルーティグテーブルノルーティング情報を切り替えることで、マルチキャストパケット２０の配信を時間帯毎に制御することができる。

（第３実施形態）
次に、図１４乃至図２２を参照して本件の第３実施形態について説明する。
第３実施形態では、マルチキャストパケット２０が配信されている状態で、属性情報が変更され、配信経路Ｔを切り替える点で上述した第１実施形態及び第２実施形態と相違する。
まず、図１４及び図１５を参照して管理サーバ１００の構成について説明する。

図１４は、管理サーバ１００のブロック図である。
図１４に示すように、管理サーバ１００は、少なくとも利用者情報記憶部１１０、利用者情報管理部１２０及び利用者情報通知部１３０を含んでいる。管理サーバ１００にサーバ情報記憶部１４０、サーバ情報管理部１５０及びサーバ情報通知部１６０を含めてもよい。

利用者情報記憶部１１０は、第１実施形態で説明した利用者情報テーブル（図３（ｄ）参照）を記憶する。
利用者情報管理部１２０は、利用者情報記憶部１１０の利用者情報を管理する。例えば、新たな利用者が配信事業者と配信契約を締結した場合、契約情報管理部１２０は新たな利用者に対しユーザＩＤ、端末アドレス、属性情報及びサーバアドレスを割り当てて登録する。例えば、既存の利用者が仮解約から本契約に配信契約を変更した場合、利用者情報管理部１２０は属性情報を書き換える。例えば、既存の利用者が退会などにより配信事業者と配信契約を解除した場合、利用者情報管理部１２０は当該利用者の利用者情報を削除する。
利用者情報通知部１３０は、上述したように利用者情報に変更があった場合、利用者情報をＬＨＲ２００に通知する。

サーバ情報記憶部１４０は、第１実施形態で説明したサーバ管理テーブル（図３（ｅ）参照）又は第２実施形態で説明したサーバ管理テーブル（図１３（ａ）参照）を記憶する。
サーバ情報管理部１５０は、サーバ情報記憶部１４０のサーバ情報を管理する。例えば、サーバ情報管理部１５０は利用者情報通知部１３０が利用者情報をＬＨＲ２００に通知する際にサーバ情報を取得して、取得したサーバ情報をサーバ情報通知部１６０に出力する。
サーバ情報通知部１６０は、サーバ情報から出力されたサーバ情報をＬＨＲ２００に通知する。したがって、利用者情報が変更されると、利用者情報の通知に応じてサーバ情報の通知も行われる。

図１５は、管理サーバ１００のハードウェア構成の一例である。尚、配信サーバ４００，４１０についても基本的に管理サーバ１００と同様の構成を有する。
管理サーバ１００は、少なくともＣＰＵ１００Ａ、ＲＡＭ１００Ｂ、ＲＯＭ１００Ｃ及び通信Ｉ／Ｆ１００Ｄを含んでいる。管理サーバ１００に、Hard Disk Drive（ＨＤＤ）１００Ｅ、入力Ｉ／Ｆ１００Ｆ、出力Ｉ／Ｆ１００Ｇ、入出力Ｉ／Ｆ１００Ｈ、ドライブ装置１００Ｉの少なくとも１つを含めてもよい。これらの各機器１００Ａ〜１００Ｉは、内部バス１００Ｊによって互いに接続されている。少なくともＣＰＵ１００ＡとＲＡＭ１００Ｂとが協働することによってコンピュータが実現される。

通信Ｉ／Ｆ１００Ｄは、例えばＲＪ−４５とＰＨＹチップとを備えている。管理サーバ１００は、通信Ｉ／Ｆ１００Ｄを介してＬＨＲ２００と接続される。

入力Ｉ／Ｆ１００Ｆには、入力装置７１０が接続される。入力装置７１０としては、例えばキーボードやマウスなどがある。
出力Ｉ／Ｆ１００Ｇには、表示装置７２０が接続される。表示装置７２０としては、例えば液晶ディスプレイがある。
入出力Ｉ／Ｆ１００Ｈには、半導体メモリ７３０が接続される。半導体メモリ７３０としては、例えばUniversal Serial Bus（ＵＳＢ）メモリやフラッシュメモリなどがある。入出力Ｉ／Ｆ１００Ｈは、半導体メモリ７３０に記憶されたプログラムやデータを読み取る。
入力Ｉ／Ｆ１００Ｆ及び入出力Ｉ／Ｆ１００Ｈは、例えばＵＳＢポートを備えている。出力Ｉ／Ｆ１００Ｇは、例えばディスプレイポートを備えている。

ドライブ装置１００Ｉには、可搬型記録媒体７４０が挿入される。可搬型記録媒体７４０としては、例えばCompact Disc Read Only Memory（ＣＤ−ＲＯＭ）、Digital Versatile Disc（ＤＶＤ）、Blu-ray（登録商標） Disc（ＢＤ）といったリムーバブルディスクがある。搬送波は可搬型記録媒体７４０から除かれる。ドライブ装置１００Ｉは、可搬型記録媒体７４０に記録されたプログラムやデータを読み込む。

上述したＲＡＭ１００Ｂは、ＲＯＭ１００ＣやＨＤＤ１００Ｅに記憶されたプログラムを読み込む。ＲＡＭ１００Ｂは、可搬型記録媒体７４０に記録されたプログラムを読み込む。読み込まれたプログラムをＣＰＵ１００Ａが実行することにより、上述した利用者情報管理部１２０、利用者情報通知部１３０、サーバ情報管理部１５０及びサーバ情報通知部１６０が実現される。また、読み込まれたプログラムをＣＰＵ１００Ａが実行することにより、後述する各種ステップが実行される。尚、プログラムは後述するフローチャートに応じたものとすればよい。

次に、図１６乃至図１８を参照して、上述した管理サーバ１００の動作について説明する。

図１６は、管理サーバ１００の動作の一例を示すフローチャートである。図１７は、利用者情報の変更例を説明するための図である。図１８は、配信経路Ｔが切り替えられる前のマルチキャスト中継システムＳの動作を説明するための図である。
まず、図１６に示すように、利用者情報管理部１２０は、定期的に利用者情報の属性情報をユーザＩＤ毎に確認する（ステップＳ２０１）。次いで、利用者情報管理部１２０は、全利用者の属性情報を確認したか否かを判断し（ステップＳ２０２）、全利用者の属性情報を確認していないと判断した場合（ステップＳ２０２：ＮＯ）、確認対象の属性情報が変更されているか否かを判断する（ステップＳ２０３）。例えば、図１７に示すように、ユーザＩＤ「Ｕ−Ｓ１」の属性情報が契約変更により仮契約から本契約に変更され、変更に併せて配信サーバアドレスもサーバアドレス「Ａ−１」からサーバアドレス「Ａ−２」に変更された場合、利用者情報管理部１２０は、確認対象の属性情報が変更されていると判断する（ステップＳ２０３：ＹＥＳ）。例えば、ユーザＩＤ「Ｕ−Ｓ２」が退会などにより削除された場合についても同様に確認対象の属性情報が変更されていると判断される。

利用者情報通知部１３０とサーバ情報通知部１６０は、確認対象の属性情報が変更されていると判断された場合、確認対象となった属性情報を含む利用者情報とサーバ情報をそれぞれＬＨＲ２００に通知する（ステップＳ２０４）。一方、確認対象の属性情報が変更されていないと判断された場合（ステップＳ２０３：ＮＯ）、利用者情報管理部１２０は、ステップＳ２０１の処理に移り、次の利用者の属性情報を確認する。そして、利用者情報管理部１２０は、全利用者の属性情報を確認したと判断した場合（ステップＳ２０２：ＹＥＳ）、処理を終了する。この結果、図１８に示すように、確認対象となった利用者情報に変更がある度に、変更後の利用者情報とサーバ情報がＬＨＲ２００に順次通知される。

次に、図１９乃至図２２を参照して、変更後の利用者情報とサーバ情報を受信したＬＨＲ２００の動作について説明する。

図１９は、ＬＨＲ２００（ユーザ管理部２９０）の動作の一例を示すフローチャートである。図２０は、ＬＨＲ２００（マルチキャスト経路制御部２８０）の動作の一例を示すフローチャートである。図２１（ａ）は、更新前後の変換テーブルを説明するための図である。図２１（ｂ）は、マルチキャストルーティングテーブルが変更される様子を説明するための図である。図２２は、配信経路Ｔが切り替えられた後のマルチキャスト中継システムＳの動作を説明するための図である。

まず、図１９に示すように、通知情報管理部２９１は、定期的に入力される第１の参加要求に格納された端末アドレスに基づいて、利用者情報テーブルの属性情報を取得する（ステップＳ３０１）。例えば、第１の参加要求に端末アドレス「Ｓ１」が格納されていれば（図６（ａ）参照）、変更後の利用者情報テーブルの属性情報（図１７参照）を取得する。この結果、契約種別「本契約」を含む属性情報が取得される。

次いで、通知情報管理部２９１は、取得した属性情報に基づいて、対応するサーバアドレス及び優先度を求める（ステップＳ３０２）。例えば、属性情報に契約種別「本契約」が含まれていれば、当該属性情報に対応する優先度「優先２」及びサーバアドレス「Ａ−２」が求められる（図３（ｅ）参照）。通知情報管理部２９１は、求めたサーバアドレスと優先度を端末アドレスとともに配信サーバ決定部２８２に送信する（ステップＳ３０３）。

次いで、図２０に示すように、配信サーバ決定部２８２は、通知情報管理部２９１から送信された端末アドレス、サーバアドレス及び優先度を受信すると（ステップＳ４０１）、変換テーブルに端末アドレスに対応するエントリーがあるか否かを判断する（ステップＳ４０２）。例えば、端末アドレス「Ｓ１」が送信された場合、図２１（ａ）に示すように、端末アドレス「Ｓ１」に対応するエントリー（「Ｖ−Ａ」及び「Ｇ１」）が更新前の変換テーブルにあるため、配信サーバ決定部２８２は、変換テーブルに端末アドレスに対応するエントリーがあると判断する（ステップＳ４０２：ＹＥＳ）。

配信サーバ決定部２８２は、変換テーブルに端末アドレスに対応するエントリーがあると判断した場合、次いで、優先度が変更されているか否かを判断する（ステップＳ４０３）。例えば、優先度「優先２」を受信した場合、更新前の変換テーブルの優先度「優先１」と対比すると（図２１（ａ）参照）、優先度が変更されている。このため、配信サーバ決定部２８２は、優先度が変更されていると判断する（ステップＳ４０３：ＹＥＳ）。

配信サーバ決定部２８２は、優先度が変更されていると判断した場合、次いで、変換テーブルの優先度及び変換後のソースアドレスを受信した優先度とサーバアドレスで更新する（ステップＳ４０４）。この結果、図２１（ａ）に示すように、優先度「優先２」及び変更後ソースアドレス「Ａ−２」を含む変換情報が変換テーブルに登録される。

続いて、配信サーバ決定部２８２は、受信したサーバアドレスに基づいて、第２の参加要求の方路を決定する（ステップＳ４０５）。例えば、サーバアドレス「Ａ−２」を受信した場合、ユニキャストルーティングテーブル（図３（ａ）参照）に基づけば、方路名「Ｇ１０１」が決定される。次いで、配信サーバ決定部２８２は、配信経路生成処理を起動し（ステップＳ４０６）、マルチキャストルーティングテーブルに入方路及び出方路を設定する（ステップＳ４０７）。

この結果、第２の参加要求は、図８と対照的に、配信サーバ４１０側にＬＨＲ２００から送信されて、図２２に示すように、配信経路Ｔが構築される。すなわち、配信経路Ｔが図１８に示す状態から図２２に示す状態に切り替わる。そして、図２１（ｂ）に示すように、マルチキャストルーティングテーブルでは、エントリー名（Ａ−２，Ｇ１）を含む経路情報に入方路「Ｇ１０１」及び出方路「Ｇ０１」が設定され、エントリー名（Ａ−１，Ｇ１）を含む経路情報から入方路「Ｇ１００」及び出方路「Ｇ０１」が削除される。

尚、配信経路Ｔが切り替わった後すぐに入方路及び出方路が設定されても、配信サーバ４１０から配信されたマルチキャストパケット２０がＬＨＲ２００に入力されておらず、端末装置３００で視聴される動画が中断される可能性もあるため、切り替え後の配信サーバ４１０から配信が開始される十分な時間を待ってから、マルチキャストルーティングテーブルに入方路及び出方路を設定することが好ましい。

次に、図２３を参照して、以上説明したパケット配信システムＳのシーケンスを説明する。
図２３は、パケット配信システムＳのシーケンスの他の一例である。
図２３に示すように、配信サーバ４００，４１０からマルチキャストパケット２０がそれぞれ配信されている状態で、端末装置３００から第１の参加要求が送信されると、ＬＨＲ２００は第１の参加要求を受信し、受信した第１の参加要求に応じて第２の参加要求をＮＨＲ５００に送信する。ＮＨＲ５００は受信した第２の参加要求を自己のユニキャストルーティングテーブルに従ってＦＨＲ６００に送信する。

第２の参加要求を受信したＦＨＲ６００は、構築された配信経路に従ってマルチキャストパケット２０をＮＨＲ５００に送信し、ＮＨＲ５００は受信したマルチキャストパケット２０を同様にＬＨＲ２００に送信する。ＬＨＲ２００は、マルチキャストパケット２０の送信元アドレスを配信元のサーバアドレスから仮想化アドレスに変換し、送信元アドレスを変換したマルチキャストパケット２０を端末装置３００に送信する。この結果、端末装置３００では配信サーバ４００から配信されたマルチキャストパケット２０に基づく動画が表示される。

ここで、属性情報の変更に基づいて利用者情報がＬＨＲ２００に入力されると、ＬＨＲ２００は第２の参加要求をＮＨＲ５１０に送信する。ＮＨＲ５１０は受信した第２の参加要求を自己のユニキャストルーティングテーブルに従ってＦＨＲ６１０に送信する。

第２の参加要求を受信したＦＨＲ６１０は、構築された配信経路に従ってマルチキャストパケット２０をＮＨＲ５１０に送信し、ＮＨＲ５１０は受信したマルチキャストパケット２０を同様にＬＨＲ２００に送信する。ＬＨＲ２００は、マルチキャストパケット２０の送信元アドレスを配信元のサーバアドレスから仮想化アドレスに変換し、送信元アドレスを変換したマルチキャストパケット２０を端末装置３００に送信する。この結果、端末装置３００では配信サーバ４１０から配信されたマルチキャストパケット２０に基づく動画に切り替わって表示される。

以上、第３実施形態によれば、管理サーバ１００から属性情報の変更に応じて少なくとも利用者情報がＬＨＲ２００に通知されれば、マルチキャストパケット２０が配信されている状態であっても、配信経路Ｔを切り替えることができる。また、使用時間帯毎に配信を制御する場合には、利用者情報と共に使用時間帯を含むサーバ情報がＬＨＲ２００に通知されればよい。

（第４実施形態）
次に、図２４乃至図２７を参照して本件の第４実施形態について説明する。
第４実施形態では、マルチキャストパケット２０が配信されている状態で、配信サーバ４００，４１０のいずれかが故障し、配信経路Ｔを切り替える点で上述した第３実施形態と相違する。

まず、図２４及び図２５を参照して、管理サーバ１００の動作について説明する。
図２４（ａ）は、サーバ管理テーブルの他の一例である。図２４（ｂ）は、管理サーバ１００の動作の一例を示すフローチャートである。図２５は、配信経路Ｔが切り替えられる前のマルチキャスト中継システムＳの動作を説明するための図である。図２４（ａ）に示すように、第４実施形態のサーバ管理テーブルでは、配信サーバ４００，４１０の稼動状態が設けられて点で、図３（ｅ）又は図１３（ａ）を参照して説明したサーバ管理テーブルと相違する。

例えば、図２５に示すように、配信サーバ４００が故障すると、配信サーバ４００の故障に連動して、サーバ管理テーブルが変化する。例えば、図２４（ａ）に示すように、配信サーバ４００に設定されたサーバアドレス「Ａ−１」を含むサーバ情報の稼動状態が正常から故障に変化する。

図２４（ｂ）に示すように、サーバ情報管理部１５０は、定期的に配信サーバ４００，４１０の稼動状態をサーバアドレス毎に確認する（ステップＳ５０１）。次いで、サーバ情報管理部１５０は、全配信サーバ４００，４１０を確認したか否かを判断し（ステップＳ５０２）、全配信サーバ４００，４１０の稼動状態を確認していないと判断した場合（ステップＳ５０２：ＮＯ）、確認対象の稼動状態が前回の確認から変化しているか否かを判断する（ステップＳ５０３）。例えば、図２４（ａ）に示すように、サーバアドレス「Ａ−１」の稼動状態が正常から故障に変化している場合、サーバ情報管理部１５０は、確認対象の稼動状態が変化していると判断する（ステップＳ５０３：ＹＥＳ）。

サーバ情報通知部１６０は、確認対象の稼動状態が変化していると判断された場合、確認対象となった稼動状態を含むサーバ情報をＬＨＲ２００に通知する（ステップＳ５０４）。一方、確認対象の稼動状態が変化していないと判断された場合（ステップＳ５０３：ＮＯ）、サーバ情報管理部１５０は、ステップＳ５０１の処理に移り、次の配信サーバ４００，４１０の稼動状態を確認する。そして、サーバ情報管理部１５０は、全配信サーバ４００，４１０の稼動状態を確認したと判断した場合（ステップＳ５０２：ＹＥＳ）、処理を終了する。この結果、図２５に示すように、確認対象となった稼動状態が変化している度に、当該稼動状態を含むサーバ情報がＬＨＲ２００に順次通知される。

次に、図２６及び図２７を参照して、ＬＨＲ２００の動作について説明する。
図２６は、ＬＨＲ２００（ユーザ管理部２９０）の動作の一例を示すフローチャートである。図２７は、配信経路Ｔが切り替えられた後のマルチキャスト中継システムＳの動作を説明するための図である。

まず、図２６に示すように、通知情報管理部２９１は、配信サーバ４００，４１０の故障を検出したか否かを判断する（ステップＳ６０１）。例えば、管理サーバ１００から稼動状態を含むサーバ情報が通知されて、当該サーバ情報に故障が含まれていれば通知情報管理部２９１は、配信サーバ４００，４１０の故障を検出したと判断する（ステップＳ６０１：ＹＥＳ）。

次いで、通知情報管理部２９１は、配信サーバ４００，４１０の故障を検出したと判断した場合、全利用者を確認済みか否かを判断する（ステップＳ６０２）。例えば、通知情報管理部２９１は、通知情報記憶部２３０に記憶された利用者情報テーブル（図３（ｄ））を利用者情報毎に確認し、全ての利用者を確認し終えていた場合、全利用者を確認済みと判断する。

次いで、通知情報管理部２９１は、全利用者を確認済みでないと判断した場合、確認対象利用者が故障した配信サーバを利用しているか否かを判断する（ステップＳ６０３）。例えば、受信したサーバ情報では、サーバアドレス「Ａ−１」と稼動状態「故障」が関連付いているため、通知情報管理部２９１は、確認対象の利用者情報に含まれるサーバアドレス「Ａ−１」（図３（ｄ）参照）を利用して、故障した配信サーバを利用しているか否かを判断する。本実施形態では、通知情報管理部２９１は、ユーザＩＤ「Ｕ−Ｓ１」は故障した配信サーバ４００を利用していると判断する（ステップＳ６０３：ＹＥＳ）。

次いで、通知情報管理部２９１は、確認対象利用者が故障した配信サーバを利用していると判断した場合、利用者の優先度が「優先１」以上であるか否かを判断する（ステップＳ６０４）。例えば、通知情報管理部２９１は、確認対象の利用者情報に含まれる属性情報に基づいて、サーバ管理テーブルから対応する優先度を取得し、取得した優先度が「優先１」以上あるか否かを判断する。本実施形態では、図３（ｄ）及び（ｅ）に示すように、故障した配信サーバ４００を利用するユーザＩＤ「Ｕ−Ｓ１」の属性情報は、サーバ管理テーブルの優先度「優先１」と対応するため、通知情報管理部２９１は、利用者の優先度が「優先１」以上であると判断する（ステップＳ６０４：ＹＥＳ）。

通知情報管理部２９１は、利用者の優先度が「優先１」以上であると判断すると、次いで、サーバ管理テーブルから利用可能な配信サーバのサーバアドレスを求め、利用者情報テーブルのサーバアドレスを更新する（ステップＳ６０５）。例えば、通知情報管理部２９１はサーバ管理テーブルを確認し、図２４（ａ）に示すように、サーバアドレス「Ａ−２」の稼動状態が正常であると、当該サーバアドレスを求める。そして、求めたサーバアドレス「Ａ−２」で利用者情報テーブルの確認対象のサーバアドレスを更新する。この結果、図３（ｄ）において、配信サーバアドレス「Ａ−１」が「Ａ−２」に変更される。

次いで、通知情報管理部２９１は、ステップＳ６０５の処理で求めたサーバアドレスを配信サーバ決定部２８２に送信する（ステップＳ６０６）。サーバアドレスを受信した配信サーバ決定部２８２は、図２０を参照して説明した各処理の中で、ステップＳ４０３の処理を除いて実行する。すなわち、優先度は変更されていないため、ステップＳ４０１の処理では優先度が受信されず、後続するステップＳ４０４の処理でも優先度は更新されない。したがって、図２１（ａ）において、更新後の変換テーブルでは優先度「優先１」が維持され、変換後ソースアドレス「Ａ−２」が設定される。この結果、図２７に示すように、配信経路Ｔが図２５に示す状態から図２７に示す状態に変更される。

以上、第４実施形態によれば、配信サーバ４００の故障により、管理サーバ１００から稼動状態の変化に応じたサーバ情報がＬＨＲ２００に通知されれば、マルチキャストパケット２０が配信されている状態であっても、配信経路Ｔを切り替えることができる。

以上、本発明の好ましい実施形態について詳述したが、本発明に係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

なお、以上の説明に関して更に以下の付記を開示する。
（付記１）複数の配信サーバのそれぞれに設定されたアドレスを仮想化した仮想化アドレスが配信要求に含まれている場合、配信を利用する利用者の属性情報に基づいて前記配信サーバのいずれかを決定する決定手段と、前記決定手段によって決定された配信サーバから端末装置にマルチキャストトラフィックが配信される配信経路を構築する構築手段と、を有するマルチキャスト中継装置。
（付記２）前記決定手段は、前記属性情報と前記配信要求を受信した時間帯に基づいて前記配信サーバのいずれかを決定することを特徴とする付記１に記載のマルチキャスト中継装置。
（付記３）前記決定手段は、前記マルチキャストトラフィックが入力された場合、前記マルチキャストトラフィックの送信元アドレスに格納された前記アドレスを前記仮想化アドレスに変換して出力することを特徴とする付記１又は２に記載のマルチキャスト中継装置。
（付記４）付記１に記載のマルチキャスト中継装置と、前記属性情報を管理する管理手段と、前記属性情報が変更された場合に変更後の前記属性情報を前記マルチキャスト中継装置に通知する通知手段とを含む管理装置と、を有するマルチキャスト配信システム。
（付記５）付記２に記載のマルチキャスト中継装置と、前記属性情報と前記配信要求を受信した時間帯に使用する配信サーバとを管理する管理手段と、前記属性情報が変更された場合に変更後の前記属性情報と前記配信要求を受信した時間帯に使用する配信サーバとを前記マルチキャスト中継装置に通知する通知手段とを含む管理装置と、を有するマルチキャスト配信システム。
（付記６）付記１又は２に記載のマルチキャスト中継装置と、前記配信サーバのそれぞれの稼動状態を管理する管理手段と、前記稼動状態が変化した場合に前記マルチキャストトラフィックを配信可能な配信サーバを前記マルチキャスト中継装置に通知する通知手段とを含む管理装置と、を有するマルチキャスト配信システム。
（付記７）配信を利用する利用者の属性情報が変更された場合に変更後の前記属性情報を通知する通知ステップと、複数の配信サーバのそれぞれに設定されたアドレスを仮想化した仮想化アドレスが配信要求に含まれている場合、前記通知ステップによって通知された変更後の前記属性情報に基づいて前記配信サーバのいずれかを決定する決定ステップと、前記決定ステップによって決定された配信サーバから端末装置にマルチキャストトラフィックが配信される配信経路を構築する構築ステップと、を有するマルチキャスト配信方法。
（付記８）前記決定ステップは、前記属性情報と前記配信要求を受信した時間帯に基づいて前記配信サーバのいずれかを決定することを特徴とする付記７に記載のマルチキャスト配信方法。
（付記９）前記決定ステップは、前記マルチキャストトラフィックが入力された場合、前記マルチキャストトラフィックの送信元アドレスに格納された前記アドレスを前記仮想化アドレスに変換して出力することを特徴とする付記７又は８に記載のマルチキャスト配信方法。

Ｓ マルチキャスト配信システム
１００ 管理サーバ（管理装置）
１１０ 利用者情報記憶部
１２０ 利用者情報管理部（管理手段）
１３０ 利用者情報通知部（通知手段）
１４０ サーバ情報記憶部
１５０ サーバ情報管理部（管理手段）
１６０ サーバ情報通知部（通知手段）
２００ ＬＨＲ（マルチキャスト中継装置）
２８０ マルチキャスト経路制御部
２８１ ルーティングプロトコル処理部（構築手段）
２８２ 配信サーバ決定部（決定手段）
２８３ 方路設定部（構築手段）

Claims (6)

1. 複数の配信サーバのそれぞれに設定されたアドレスを仮想化した仮想化アドレスが配信要求に含まれている場合、配信を利用する利用者の属性情報に基づいて前記配信サーバのいずれかを決定する決定手段と、
   前記決定手段によって決定された配信サーバから端末装置にマルチキャストトラフィックが配信される配信経路を構築する構築手段と、
   を有するマルチキャスト中継装置。
2. 前記決定手段は、前記属性情報と前記配信要求を受信した時間帯に基づいて前記配信サーバのいずれかを決定することを特徴とする請求項１に記載のマルチキャスト中継装置。
3. 請求項１に記載のマルチキャスト中継装置と、
   前記属性情報を管理する管理手段と、前記属性情報が変更された場合に変更後の前記属性情報を前記マルチキャスト中継装置に通知する通知手段とを含む管理装置と、
   を有するマルチキャスト配信システム。
4. 請求項２に記載のマルチキャスト中継装置と、
   前記属性情報と前記配信要求を受信した時間帯に使用する配信サーバとを管理する管理手段と、前記属性情報が変更された場合に変更後の前記属性情報と前記配信要求を受信した時間帯に使用する配信サーバとを前記マルチキャスト中継装置に通知する通知手段とを含む管理装置と、
   を有するマルチキャスト配信システム。
5. 請求項１又は２に記載のマルチキャスト中継装置と、
   前記配信サーバのそれぞれの稼動状態を管理する管理手段と、前記稼動状態が変化した場合に前記マルチキャストトラフィックを配信可能な配信サーバを前記マルチキャスト中継装置に通知する通知手段とを含む管理装置と、
   を有するマルチキャスト配信システム。
6. 配信を利用する利用者の属性情報が変更された場合に変更後の前記属性情報を通知する通知ステップと、
   複数の配信サーバのそれぞれに設定されたアドレスを仮想化した仮想化アドレスが配信要求に含まれている場合、前記通知ステップによって通知された変更後の前記属性情報に基づいて前記配信サーバのいずれかを決定する決定ステップと、
   前記決定ステップによって決定された配信サーバから端末装置にマルチキャストトラフィックが配信される配信経路を構築する構築ステップと、
   を有するマルチキャスト配信方法。

Images