(57)【要約】【課題】チャネル数や同時配信数といったマルチキャストリソースの上限に達した場合でもマルチキャストのコンテンツを受信できるようにする。【解決手段】マルチキャストネットワークに接続するコントロールサーバ１０が、レシーバ１２によるマルチキャストネットワークへの参加要求に対して、マルチキャストリソースの上から参加可能か否かの判断を行い、参加不可能の場合、参加しようとするレシーバ１２に対して、マルチキャスト配信を行うセンダ１１へユニキャストでの配信を要求させる。【選択図】図１
2017183876.tif 000002
【特許請求の範囲】
【請求項１】
マルチキャストネットワークへコンテンツを送信するセンダに接続して上記コンテンツのマルチキャスト配信を行うファーストホップルータと、上記コンテンツを受信するレシーバに接続するラストホップルータとを含むマルチキャストネットワークに接続されるサーバであって、
新たに上記コンテンツをマルチキャストで受信するために上記マルチキャストネットワークに参加しようとする上記レシーバからの参加要求を受信し、
マルチキャストリソースの点から参加可否の判断を行い、参加不可の場合、上記レシーバに対して、該当するコンテンツをユニキャストで配信することを上記センダへ要求することを指示する、
コントロールサーバ。
【請求項２】
コンテンツのマルチキャスト送信を行うセンダと、上記コンテンツを受信するレシーバと、上記センダ及び上記レシーバの間に存在する２つ以上のルータと、上記ルータとの間で通信可能なコントロールサーバとを有し、
上記ルータとして、上記レシーバに接続されるラストホップルータと、上記センダに接続されるファーストホップルータを有し、
上記レシーバからのマルチキャストグループへの参加要求を受信した上記ラストホップルータは、上記コントロールサーバに上記参加要求を通知し、
上記参加要求を受けた上記コントロールサーバは、参加するネットワークにおけるマルチキャストとマルチキャストの代替となる代替ユニキャストとの情報を登録した管理データベースの情報から、上記参加要求に対するマルチキャスト配信の可否を判断し、
上記マルチキャスト配信が可能である場合、
上記コントロールサーバは、上記ラストホップルータに許可の返答をし、
上記許可の返答を受けたラストホップルータは、マルチキャストルーティングプロトコルに従って上記参加要求のマルチキャストグループに上記レシーバが参加して受信できるようにマルチキャスト転送制御を行い、
上記マルチキャスト配信が不可である場合、
上記コントロールサーバは、上記レシーバにユニキャストへの転向要求を送信し、
上記転向要求を受信した上記レシーバは、上記マルチキャストグループへの送信を行う上記センダへ、代替となる代替ユニキャストの配信を求める代替要求を送信し、
上記代替要求を受信した上記センダは、上記マルチキャストグループの配信に対応する内容をユニキャストで上記レシーバへ送信する、
マルチキャストシステム。
【請求項３】
上記マルチキャストネットワークでマルチキャスト又はその代替となる代替ユニキャストを受信している上記レシーバに対して定期的に参加問い合わせを行い、上記レシーバの受信状況を把握し、
この受信状況を元に、使用するマルチキャストリソースが低減できるように所定の判断基準に従って、一部のマルチキャストを代替ユニキャストに変更し、一部の代替ユニキャストをマルチキャストに変更する、請求項１に記載のコントロールサーバ。
【請求項４】
上記コントロールサーバは、
上記レシーバに対して定期的な参加状況問合を送信し、
この参加状況問合に対する上記レシーバからの応答を受けて上記管理データベースを定期的に更新し、
上記管理データベースにおける情報を元に、ネットワークの消費リソースを削減するための所定の評価基準に従って、配信中のコンテンツのうち、マルチキャストとユニキャストとの配信方式を切り替えるコンテンツを選んで切替リストを登録し、
上記切替リストに、配信方式を切り替えるコンテンツが登録されている場合、
上記コントロールサーバは、配信方式をマルチキャストからユニキャストに切り替えるコンテンツを受信する上記レシーバへ、ユニキャスト切替要求を送信し、
上記ユニキャスト切替要求を受信した上記レシーバは、上記センダに代替ユニキャストの配信を要求し、
その要求を受け取った上記センダは上記レシーバへ対応するコンテンツを代替ユニキャストで配信し、
その代替ユニキャストによる配信を受け取った上記レシーバは、上記コントロールサーバへ代替ユニキャストを受信した状況を報告送信し、
この報告送信を受け取った上記コントロールサーバは、上記レシーバの配信形態がユニキャストに切り替わった旨を上記管理データベースに更新登録し、かつ、上記ラストホップルータに上記レシーバへの切り替え元となるマルチキャストを配信停止するようマルチキャスト転送制御を指示し、
このマルチキャスト転送制御を受け取った上記ラストホップルータは、マルチキャスト転送制御を行い、該当する上記レシーバへの該当するマルチキャストの配信を停止し、
一方で、
上記コントロールサーバは、配信方式を代替ユニキャストであるユニキャストからマルチキャストに切り替えるコンテンツを受信する上記レシーバへ、マルチキャスト切替要求を送信し、
上記マルチキャスト切替要求を受信した上記レシーバは、上記ラストホップルータにマルチキャストグループへの切替参加要求を送信し、
上記切替参加要求を受信した上記ラストホップルータは、マルチキャストルーティングプロトコルに従ってマルチキャスト転送制御を行い、切替元の代替ユニキャストに対応するマルチキャストを上記レシーバへ配信し、
そのマルチキャストを受信した上記レシーバは上記コントロールサーバへマルチキャストを受信した状況を報告送信し、
この報告送信を受け取った上記コントロールサーバは、上記レシーバの配信形態が上記マルチキャストに切り替わった旨を上記管理データベースに更新登録し、かつ、上記センダに対して、該当する上記レシーバへの代替ユニキャストを配信停止するよう配信停止要求を指示し、
この配信停止要求を受け取った上記センダは、該当する上記レシーバへの代替ユニキャストの配信を停止する、
請求項２に記載のマルチキャストシステム。
【請求項５】
上記コントロールサーバは、上記参加要求を受信した際の上記管理データベースへの登録の際にも、上記切替リストへ登録する、配信方式を切り替えるコンテンツを選ぶステップを実行する、請求項４に記載のマルチキャストシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、マルチキャストネットワークの運用に関する。
【背景技術】
【０００２】
現在、電気通信事業者のネットワークでは、エンドユーザの利用機器やコンテンツの増加により、トラフィックの激増が大きな問題となっている。特に大容量の通信になりやすい映像配信などのうち、一対多で同時配信を行う際には、複数のユニキャスト通信を並行して行うよりも、マルチキャストを行う方がネットワークトラフィックを軽減しやすい。このマルチキャストを用いることでトラフィックの削減が可能な用途としては、例えば地デジ放送の再配信、緊急放送や防災無線などの自治体利用通信、ＩＰマルチキャスト放送や会議システムなどの映像配信サービス、音楽配信やラジオ配信などの音声配信サービス、デジタルサイネージ、企業端末への情報配信などの企業システムなどが挙げられる。
【０００３】
マルチキャストを利用する場合、ネットワークを構成する通信装置は、ＩＰｖ４：ＩＧＭＰｖ３やＩＰｖ６：ＭＬＤｖ２などのマルチキャストグループ管理プロトコル、ＰＩＭ−ＳＳＭなどのマルチキャストルーティングプロトコルに対応している必要がある。この例として、非特許文献１に記載のRFC3810が挙げられている。
【０００４】
また、マルチキャストとユニキャストとの配信方式を切り替えて配信する同報システムが、特許文献１に記載されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開2011-259160号公報
【非特許文献】
【０００６】
【非特許文献１】RFC3810、[online]、2004年6月、The Internet Engineering Task Force、[２０１６年３月１４日検索]、インターネット<URL: https://tools.ietf.org/html/rfc3810>
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、マルチキャストはチャネル数や同時配信数を無限に増加させることはできず、装置の仕様によってそのリソースには限界がある。マルチキャストの送信元サーバ自身のユニキャストアドレスをソースアドレス（Ｓ）、受信端末が視聴するために指定するアドレスをグループアドレス（Ｇ）とする。マルチキャストルーティングプロトコルでは（Ｓ，Ｇ）として示すチャネル情報を元に、それぞれのルータが有するマルチキャストルーティングテーブルにエントリを登録する。このエントリ登録が可能な数（チャネル数）に限界があり、超過するエントリ登録要求は破棄されてしまう。
【０００８】
さらに、それぞれのマルチキャストグループに参加するメンバの管理はマルチキャストネットワークを構成するネットワーク装置で行われる。一般には送信者と受信者との間にあるルータである。マルチキャストにおいては、全てのメンバに対して定期的にグループ参加状況を確認する必要があるが、その確認処理に負荷が掛かるため、同時配信数には制限が設けられている。グループ参加メンバが増大するにつれて、ネットワーク装置が処理している他のネットワーク機能が不安定になるといった影響が生じる。
【０００９】
特許文献１に記載の同報システムは、受信端末が増えたときにはマルチキャストに、受信端末が少なくなったときにはユニキャストに切り替えるものであるが、その切替の判断は予め定めた閾値Ｎ、Ｍについて判断しており、固定的な対応に留まっていた。
【００１０】
そこでこの発明は、チャネル数や同時配信数といったマルチキャストリソースの上限に達した場合でもサービスを利用可能にすることを目的とし、さらには、上記上限に到達するケースを抑制して円滑なマルチキャスト配信ができるようにすることを目的とする。
【課題を解決するための手段】
【００１１】
この発明は、
マルチキャストネットワークに接続するコントロールサーバが、マルチキャストグループへの参加要求に対して、マルチキャストリソースの上から参加可能か否かの判断を行い、参加不可能の場合、参加しようとするレシーバに対して、マルチキャスト配信を行うセンダへユニキャストでの配信を要求させることにより、上記の課題を解決したのである。
【００１２】
従来のマルチキャストネットワークでは、マルチキャストのためのリソースが足りない場合は配信を拒絶せざるを得なかった。上記レシーバが、上記コントロールサーバからの指示に従い、マルチキャストの受信ができない場合には、ユニキャストでの受信を要求するように切り替えられるようにし、なおかつ、上記センダが、そのユニキャストの要求に対して、当初上記レシーバが受信することを要求していた上記マルチキャストに対応する内容を、ユニキャストで送信できるようにすることで、この状況に対応できる。上記コントロールサーバは、マルチキャストネットワークにおけるマルチキャストリソースの上から参加可能であるか否かを判断するために、ネットワークリソースを管理できるように、マルチキャストと、そのマルチキャストの代替として送信されるユニキャストとの情報を登録した管理データベースを持つ。また、上記コントロールサーバは、マルチキャストネットワークを構成するルータからの問い合わせに応答し、さらに、マルチキャストネットワークに参加しようとするレシーバに指示可能であるように、マルチキャストネットワークに接続される。
【００１３】
この発明にかかるマルチキャストシステムの具体的な構成としては次のようになる。
コンテンツのマルチキャスト送信を行うセンダと、上記コンテンツを受信するレシーバと、上記センダ及び上記レシーバの間に存在する２つ以上のルータと、上記ルータとの間で通信可能なコントロールサーバとを有し、
上記ルータとして、上記レシーバに最も近いラストホップルータと、上記センダに最も近いファーストホップルータを有し、
上記レシーバからのマルチキャストグループへの参加要求を受信した上記ラストホップルータは、上記コントロールサーバに上記参加要求を通知し、
上記参加要求を受けた上記コントロールサーバは、参加するネットワークにおけるマルチキャストとマルチキャストの代替となる代替ユニキャストとの情報を登録した管理データベースの情報から、上記参加要求に対するマルチキャスト配信の可否を判断し、
上記マルチキャスト配信が可能である場合、
上記コントロールサーバは、上記ラストホップルータに許可の返答をし、
上記許可の返答を受けたラストホップルータは、マルチキャストルーティングプロトコルに従って上記参加要求のマルチキャストグループに上記レシーバが参加して受信できるようにマルチキャスト転送制御を行い、
上記マルチキャスト配信が不可である場合、
上記コントロールサーバは、上記レシーバにユニキャストへの転向要求を送信し、
上記転向要求を受信した上記レシーバは、上記マルチキャストグループへの送信を行う上記センダへ、代替となる代替ユニキャストの配信を求める代替要求を送信し、
上記代替要求を受信した上記センダは、上記マルチキャストグループの配信に対応する内容の内容をユニキャストで上記レシーバへ送信する、
マルチキャストシステムとする。
【００１４】
さらに、ネットワークリソースを節約し、円滑なマルチキャスト配信を行えるようにするために、この発明にかかるマルチキャストシステムを構成する上記コントロールサーバは、次のような機能を有し実行できると好ましい。
上記コントロールサーバは、上記マルチキャストネットワークでマルチキャスト又はその代替となる代替ユニキャストを受信している上記レシーバに対して定期的に参加問い合わせを行い、上記レシーバの受信状況を把握する。この受信状況を元に、使用するマルチキャストリソースが低減できるように所定の判断基準に従って、一部のマルチキャストを代替ユニキャストに変更し、一部の代替ユニキャストをマルチキャストに変更する。
【００１５】
このさらなる発明の、マルチキャストリソースを節約する具体的な構成は次の通りとなる。
まず、上記コントロールサーバは、上記レシーバに対して定期的な参加状況問合を送信し、この参加状況問合に対する上記レシーバからの受信状況と受信方式の応答を受けて上記管理データベースを定期的に更新し、上記管理データベースにおける情報を元に、ネットワークの消費リソースを削減するための所定の評価基準に従って、配信中のコンテンツのうち、マルチキャストとユニキャストとの配信方式を切り替えるコンテンツを選んで登録した切替リストを作成する。
【００１６】
次に、この切替リストに従って、配信方式をマルチキャストからユニキャストに切り替える手順は次の通りである。
上記コントロールサーバは、配信方式をマルチキャストからユニキャストに切り替えるコンテンツを受信する上記レシーバへ、ユニキャスト切替要求を送信し、
上記ユニキャスト切替要求を受信した上記レシーバは、上記センダに代替ユニキャストの配信を要求し、
その要求を受け取った上記センダは上記レシーバへ対応するコンテンツを代替ユニキャストで配信し、
その代替ユニキャストによる配信を受け取った上記レシーバは、上記コントロールサーバへ上記代替ユニキャストを受信した状況を報告送信し、
この報告送信を受け取った上記コントロールサーバは、上記レシーバの配信形態がユニキャストに切り替わった旨を上記管理データベースに更新登録し、かつ、上記ラストホップルータに上記レシーバへの切り替え元となるマルチキャストを配信停止するようマルチキャスト転送制御を指示し、
このマルチキャスト転送制御を受け取った上記ラストホップルータは、マルチキャスト転送制御を行い、該当する上記レシーバへの該当するマルチキャストの配信を停止する。
【００１７】
一方で、この切替リストに従って、配信方式を代替ユニキャストであるユニキャストからマルチキャストに切り替える手順は次の通りである。
上記コントロールサーバは、配信方式をユニキャストからマルチキャストに切り替えるコンテンツを受信する上記レシーバへ、マルチキャスト切替要求を送信し、
上記マルチキャスト切替要求を受信した上記レシーバは、上記ラストホップルータにマルチキャストグループへの切替参加要求を送信し、
上記切替参加要求を受信した上記ラストホップルータは、マルチキャストルーティングプロトコルに従ってマルチキャスト転送制御を行い、切替元の代替ユニキャストに対応するマルチキャストを上記レシーバへ配信し、
そのマルチキャストを受信した上記レシーバは上記コントロールサーバへマルチキャストを受信した状況を報告送信し、
この報告送信を受け取った上記コントロールサーバは、上記レシーバの配信形態が上記マルチキャストに切り替わった旨を上記管理データベースに更新登録し、かつ、上記センダに対して、該当する上記レシーバへの代替ユニキャストを配信停止するよう配信停止要求を指示し、
この配信停止要求を受け取った上記センダは、該当する上記レシーバへの代替ユニキャスト配信を停止する。
【発明の効果】
【００１８】
この発明により、マルチキャスト配信ができない場合はユニキャストを並行して行い、状況を監視して、複数のユニキャストをマルチキャストに統合した方がネットワークリソースを軽減できる場合は、その統合を行い、そのためにネットワークリソースが不足する場合は、逆に負荷の小さいマルチキャストをユニキャストに切り替えることで、より負荷の大きいコンテンツをマルチキャストに割り当てられるようにすることができ、全体として、マルチキャストの利用をしやすくし、ネットワークリソースを節約することができる。
【図面の簡単な説明】
【００１９】
【図１】この発明に係るマルチキャストシステムの機能ブロック図
【図２】この発明にかかるコントロールサーバが有する管理データベースのテーブル例図
【図３】この発明にかかるコントロールサーバが有する切替リストのテーブル例図
【図４】新たなレシーバの参加要求を受けたときの処理を示すフロー例図
【図５】定期的にレシーバの参加状況を問い合わせる際の処理を示すフロー例図
【図６】代替ユニキャストからマルチキャストに切り替える際のフロー例図
【図７】マルチキャストから代替ユニキャストに切り替える際のフロー例図
【発明を実施するための形態】
【００２０】
以下、この発明について実施形態の例を示して詳細に説明する。
この発明は、センダから配信するコンテンツの少なくとも一部をマルチキャストとしてレシーバに配信するネットワークシステムである。
【００２１】
この発明にかかるマルチキャストネットワークを構成するシステムを構成する構成要素の関係図を図１に示す。
センダ１１はコンテンツの配信を行う装置である。センダ１１自体は通信機能を有するコンピュータである必要があり、具体的にはパソコンやスマートフォンなどが挙げられる。コンテンツは磁気ディスクや不揮発メモリなどの記憶装置に保存されたものであってもよいし、センダ１１がカメラやマイクなどからリアルタイムに入力されたものを、メモリ上でリアルタイム処理して送信するものであってもよい。これらの一時的又は恒久的にコンテンツを保持するものをまとめてコンテンツ保持部２１と呼ぶ。コンテンツ保持部２１からはコンテンツを送信するにあたり、マルチキャストを行うマルチキャスト送信部２２と、ユニキャストを行うユニキャスト送信部２３に繋がる。どちらも、物理的なネットワークインターフェースを介して、ファーストホップルータ１５に接続される。
【００２２】
レシーバ１２は、コンテンツの受信を行う装置である。この発明においては、コンテンツの視聴等の最終出力を行うパソコンやスマートフォン、テレビなどの視聴機器そのものではなく、それらの機器が直接接続されるＬＡＮに繋がる、家庭用又は事業者用のゲートウェイ装置が該当する。レシーバ１２は、送信されるマルチキャストを受信するマルチキャスト受信部４２と、送信されるユニキャストを受信するユニキャスト受信部４３と、コントロールサーバ１０からの指示を受けてこれらの受信を停止したり、センダ１１への問い合わせを行ったりする受信管理部４１を有する。
【００２３】
上記マルチキャストネットワークは、複数のルータで構成されている。個々のルータはマルチキャスト／ユニキャスト（ＭＣ／ＵＣ）それぞれのルーティングテーブルを有し、どの接続先にあるマルチキャストを配信するセンダ１１があり、どの接続先にあるマルチキャストを受信するレシーバ１２があるかを、このＭＣ／ＵＣそれぞれのルーティングテーブルに登録している。また、このＭＣルーティングテーブルにはグループアドレスなど、その他マルチキャストに必要な情報が登録される。
【００２４】
ファーストホップルータ１５は、マルチキャストネットワークを構成する上記ルータのうち、センダ１１がマルチキャストネットワークに接続する部分を担うルータである。あるコンテンツの配信における役割であり、センダ１１が接続される上記ルータがファーストホップルータ１５となるが、図では一のコンテンツについて配信する場合として記載する。実際にはセンダ１１が複数存在し、それに直接接続するファーストホップルータ１５も複数存在する。また、別のコンテンツについては後述するラストホップルータ１６として機能する場合もある。
【００２５】
ラストホップルータ１６は、マルチキャストネットワークを構成する上記ルータのうち、レシーバ１２に直接接続する部分を担うルータである。これはレシーバ１２とセンダ１１に対する役割である。一のコンテンツがマルチキャストされる場合、一のラストホップルータ１６に複数のレシーバ１２が接続される場合もある。また、ラストホップルータ１６が異なるレシーバ１２にマルチキャストされる場合もある。図１では、一つのルータがラストホップルータ１６として接続されるレシーバ１２をピックアップして記載する。なお、レシーバ１２とラストホップルータ１６との間にＬ２スイッチなどのルータではない中継機が介在していてもよい。ラストホップルータ１６は、レシーバ１２からのマルチキャストへの参加要求を、後述するコントロールサーバ１０へ転送するとともに、マルチキャストが配信される場合には、マルチキャストルーティングプロトコルに従ってレシーバ１２にマルチキャストを配信する。
【００２６】
この発明にかかるシステムは、マルチキャストネットワークを構成する上記ルータ（１５，１６）から接続可能で、これらと通信できる、コントロールサーバ１０を有している。コントロールサーバ１０は、上記マルチキャストネットワークで配信されるマルチキャストと、そのマルチキャストの代替となる代替ユニキャストとの情報を登録した管理データベース３１を有している。管理データベース３１の例を図２に示す。「コンテンツ番号」はセンダ１１によって配信されるマルチキャストのコンテンツごとに割り振られる値である。「レシーバＩＰ」はそれぞれのコンテンツを受信するレシーバのＩＰアドレスである。ここでは例示としてローカルアドレスにしているが、実際にはレシーバ１２に割り当てられるグローバルアドレスが登録されてよい。「ＭＣ／ＵＣ」は当該コンテンツを受信するレシーバＩＰに該当するレシーバ１２に対して、そのコンテンツがマルチキャストで受信されているか、代替ユニキャストで受信されているかの種別である。
【００２７】
また、コントロールサーバ１０は、このマルチキャストネットワークで配信されるコンテンツについて、代替ユニキャストからマルチキャストへの切り替え、又は代替ユニキャストからマルチキャストへの切り替えを行うものを管理する切替リスト３２を有している。この切替リスト３２の例を図３に示す。「コンテンツ番号」は管理データベース３１のものと同じである。「MC数」はそのコンテンツをマルチキャストで受信しているレシーバ１２の数である。「UC数」はそのコンテンツを代替ユニキャストで受信しているレシーバ１２の数である。MC数とUC数は一方が０であることもあるが、マルチキャストリソースの限界に達してさらにレシーバ１２が参加要求し、代替ユニキャストが割り当てられた場合は、どちらも１以上になることがありうる。「必要帯域」はそのマルチキャストが使用するデータ量であり、kbyte数やなんらかの基準による比の数で表記する。「配信方式」は、基本的にはマルチキャストである。代替ユニキャストとなるレシーバ１２の上記UC数が１以上であっても、マルチキャストが配信されていれば「配信方式」をマルチキャストとする。一方、後述する評価にしたがって、マルチキャストの配信を止めて代替ユニキャストのみになった場合、「配信方式」をユニキャストとする。「評価値」はマルチキャストネットワークのリソースに応じて評価する、リソースの消耗や負荷を示す値である。評価方法は特に限定されるものではなく、ネットワークの構成によっても好適な評価基準が変わる。図３の例では、必要帯域と受信数の積を負荷の値として示している。「状態」は、上記の評価の結果、マルチキャスト配信を停止して代替ユニキャストに切り替えるものと、代替ユニキャストをマルチキャストに切り替えるものとを指示する状態を示す。
【００２８】
さらにコントロールサーバ１０は、レシーバ１２からラストホップルータ１６を経て問い合わされた、マルチキャストグループへの参加要求を、マルチキャストリソースの点から許容可能であるか否かを判断するリソース評価部３３を有する。マルチキャストリソースは、ネットワークを構成するハードウェアのアーキテクチャにより決定される、マルチキャストを送信するための許容量である。このマルチキャストリソースの上限としては、例えば、チャネル数と同時配信数とを評価対象とする手法が挙げられる。リソース評価部３３は、上記チャネル数や上記同時配信数を例とするマルチキャストリソースの点から、上記参加要求を許容できる場合にはラストホップルータ１６に対して許可の返答を返す。許容できない場合は、レシーバ１２に対して、マルチキャストの配信を受けるのではなく代替ユニキャストをセンダ１１から受信するように指示する転向要求を送信する。
【００２９】
上記チャネル数は、マルチキャストルーティングプロトコルにおいて、上記ルータのマルチキャストルーティングテーブルに登録されるエントリの数である。個々のマルチキャストは、センダ１１のユニキャストアドレスをソースアドレス「Ｓ」、レシーバ１２（のLANに繋がる端末）が視聴するために指定するアドレスをグループアドレス「Ｇ」とし、これらをまとめた「（Ｓ，Ｇ）」として個々のチャネルを識別する。上記チャネル数は、そのチャネルをエントリとして登録可能な、すなわち、上記ルータが処理可能なマルチキャストのチャネルの数を示す。チャネル数が上限に達すると、それ以上マルチキャストのチャネルを増やすことはできず、いずれかのマルチキャストを終了させなければ、新たなマルチキャストを配信させることはできない。
【００３０】
上記同時配信数は、それぞれの上記ルータ（ファーストホップルータ１５とラストホップルータ１６とを含む。）における、中継するマルチキャスト毎の、中継すべき次の配信先の数の合計である。一つの接続先（ラストホップルータ１６の場合はレシーバ１２）に複数のマルチキャストが送信される場合は、このメンバの数は重複してカウントされる。マルチキャストグループに参加するメンバの数と状況は上記ルータが定期的に確認するが、その確認処理に負荷がかかるため、同時に配信出来るマルチキャストの数には限界がある。参加するメンバの数が増大するにつれて、上記ルータのマルチキャスト以外の機能が不安定になる場合がある。なお、この発明における評価にあたっては、マルチキャストをそのまま受信するレシーバ１２と代替ユニキャストで受信するレシーバ１２とを同列に扱ってもよいし、別基準で評価するものとしてもよい。
【００３１】
さらにまたコントロールサーバ１０は、定期的にレシーバ１２に対して、マルチキャストネットワークへの参加状況と受信方式を問い合わせる参加状況問合を行い、管理データベース３１を更新するコンテンツ管理部３４を有する。
【００３２】
さらにまたコントロールサーバ１０は、上記のコンテンツ管理部３４による管理データベース３１の情報更新や、レシーバ１２からの新たな参加要求をトリガーとして、マルチキャストリソースの使用がより少なくなるように、マルチキャストと代替ユニキャストとを切り替えるよう切替リスト３２に切替指示を登録し、その切替指示のための指示を送信する通信方式管理部３５を有する。
【００３３】
この発明にかかるマルチキャストシステムを実施して代替ユニキャストへの切替を指示する際の処理フローを図４の例とともに説明する。前提として、このフローの前に、センダ１１によるマルチキャストの配信が行われており、上記ルータの上記ＭＣルーティングテーブルにはこのマルチキャストの情報が登録されている。
【００３４】
まず、マルチキャストを受信しようとする端末（図示せず）をＬＡＮに抱えるレシーバ１２は、直近のラストホップルータ１６に、マルチキャストグループを上記（Ｓ，Ｇ）にて指定した参加要求を送信する（Ｓ１０１）。この参加要求を受けたラストホップルータ１６は（Ｓ１０２）、コントロールサーバ１０にこの情報を通知する（Ｓ１０３）。通知を受けたコントロールサーバ１０は（Ｓ１０４）、管理データベース３１に、上記（Ｓ，Ｇ）に対応したコンテンツ番号と、レシーバ１２のＩＰアドレスを含むエントリを登録する（Ｓ１０５）。その上で、リソース評価部３３は、マルチキャストリソースの点から、この参加要求に対してマルチキャストの配信が可能か否かを判断する（Ｓ１０６）。
【００３５】
マルチキャストの配信が可能であれば（Ｓ１０６→ｙｅｓ）、リソース評価部３３は、ラストホップルータ１６に対して、許可の返答を返す。許可の返答を受けたラストホップルータ１６は、マルチキャストルーティングプロトコルに従って上記参加要求のマルチキャストグループにレシーバ１２が参加して受信できるようにマルチキャスト転送制御を行う（Ｓ１０７）。具体的には、上記ＭＣルーティングテーブルにそのマルチキャストのエントリを登録するとともに、上記参加要求を、ファーストホップルータ１５へ通じる上記ルータへ送信する。途中で経由する上記ルータのそれぞれで、同様に、上記ＭＣルーティングテーブルにそのマルチキャストのエントリを登録して、さらにファーストホップルータ１５へ通じる上記ルータへ登録する。図４では途中の上記ルータは略記する。ファーストホップルータ１５でも同様にマルチキャスト転送制御を行い、上記ＭＣルーティングテーブルにマルチキャストエントリとしてレシーバ１２のアドレスや経路が登録される（Ｓ１０８）。なお、上記参加要求はこのファーストホップルータ１５までで、センダ１１までは転送されない。以後、センダ１１からの該当するマルチキャストは、ファーストホップルータ１５からラストホップルータ１６までを経由して、レシーバ１２に受信される（Ｓ１０９）。なお、ここでは表記を省くが、マルチキャストを受信したレシーバ１２は受信状況をコントロールサーバ１０に報告すると、コントロールサーバ１０が状況を確認して管理データベース１５を更新できる（後述するＳ２１２に対応）。
【００３６】
一方、マルチキャストの配信ができない場合は（Ｓ１０６→ｎｏ）、コントロールサーバ１０のリソース評価部３３は、レシーバ１２に対して、要求しているマルチキャストグループのマルチキャストの内容を、ユニキャストで受信するよう要求する転向要求を送信する（Ｓ１１１）。上記転向要求を受けたレシーバ１２は、上記マルチキャストグループへのコンテンツを送信するセンダ１１に、代替ユニキャストでの配信を求める代替要求を送信する（Ｓ１１２）。この代替要求を受けたセンダ１１は（Ｓ１１３）、マルチキャスト配信している内容を、別途、代替ユニキャストでレシーバ１２へ送信する（Ｓ１１４）。レシーバ１２は代替ユニキャストにて上記コンテンツを受信する（Ｓ１１５）。
【００３７】
なお、管理データベース３１に新たに作成されたレコードには、Ｓ１０６の判断に合わせて、マルチキャスト又は代替ユニキャストを送信している旨の情報を登録する。
【００３８】
上記のＳ１０７とＳ１１４とのいずれであるかに関わらず、コントロールサーバ１０のコンテンツ管理部３４は、管理データベース３１に登録されている全てのレシーバ１２のアドレスに対して、受信状況と受信方式を問い合わせる参加状況問合を定期的に送信する。その確認の処理フローを図５の例とともに説明する。コントロールサーバ１０からの参加状況問合（Ｓ１５１）を受信したレシーバ１２は、センダ１１からマルチキャスト又は代替ユニキャストを受信していなければ、応答なくそのままとする（Ｓ１５２→ｎｏ）。センダ１１からマルチキャスト又は代替ユニキャストを受信している場合は（Ｓ１５３→ｙｅｓ）、受信している受信状況と、その受信方式がマルチキャストと代替ユニキャストとのいずれであるかを示す受信方式を含めて、コントロールサーバ１０へ応答する（Ｓ１５３）。応答を受けたコンテンツ管理部３４は（Ｓ１５４）、その状況に合わせて管理データベース３１の該当するレシーバ１２のレコードを更新する（Ｓ１５５）。
【００３９】
またコンテンツ管理部３４は、管理データベース３１にレコードがあっても、レシーバ１２からの応答が無いものについては（Ｓ１５６→ｙｅｓ）、マルチキャスト又は代替ユニキャストの受信が終了したものと判断して、管理データベース３１から該当するコンテンツ番号の該当するレシーバ１２のアドレスのレコードを削除する（Ｓ１５７）。このレコードの削除に続いて、コントロールサーバ１０のコンテンツ管理部３４は、削除されたレコードに記録されていた、マルチキャスト又は代替ユニキャストの配信を停止させる指示を、ファーストホップルータ１５又はセンダ１１に送信する（Ｓ１５８）。
【００４０】
上記のＳ１０５，Ｓ１５４又はＳ１５６におけるレコードの更新によって、管理データベース３１のレコードは、直近の状態を反映するものとなる。この情報を用いて、コントロールサーバ１０の通信方式管理部３５は、マルチキャストリソースの使用を抑制するための定期的な切り替え作業を指示する。その工程を、図６及び図７のフロー例とともに説明する。
【００４１】
まず、Ｓ１０５，Ｓ１５４又はＳ１５６における上記の管理データベース３１のレコードの更新がされたとき（Ｓ２０１）、コントロールサーバ１０は、所定の基準に則って、マルチキャストリソースの使用がより少なくなるように、マルチキャストと代替ユニキャストとを切り替える切替指示を、切替リスト３２の切り替え対象となるレコードに登録する。この判断基準は、例えば図３における評価値が高いものから順に、チャネル数の限界までをマルチキャスト配信方式とし、評価値の低いものはユニキャストで扱うように分類するといった手法が挙げられる。ネットワークの構成とハードウェアの機能に応じて、この評価手法は最適なものを検討し選択するとよい。いずれの評価手法を採用する場合であっても、このＳ２０１の段階で、どのコンテンツ番号の配信をマルチキャスト又はユニキャストのいずれかで行うべきかを判断し、その判断された方式が現在の配信方式と異なる場合には、切替リスト３２の「状態」項目に、マルチキャストからユニキャストへの変更を指示する値である「ユニキャスト切替指示」、又はユニキャストからマルチキャストへの変更を指示する値である「マルチキャスト切替指示」を登録する。なお、いずれの値への登録も無い場合は、次のＳ１０５，Ｓ１５４又はＳ１５６まで待機することになる（Ｓ２０１を繰り返し）。
【００４２】
切替リスト３２に「マルチキャスト切替指示」がある場合、主にチャネル数の上限を始めとして、マルチキャストリソースの上から新たなマルチキャストを割り当てることができるか否かを判断する（Ｓ２０２）。マルチキャストへ切り替えるべきコンテンツがあり、かつマルチキャストへの切り替え可能なリソースがあれば（Ｓ２０２→ｙｅｓ）、コントロールサーバ１０の通信方式管理部３５は、当該コンテンツを代替ユニキャストで受信しているレシーバ１２に対して、マルチキャストへの切替指示を送信する（Ｓ２０３）。なお、切替リスト３２に「マルチキャスト切替指示」がなく、「ユニキャスト切替指示」がある場合は、後述するユニキャストへの切替フローへ移る（Ｓ２０２→ｎｏ→Ｓ２３１）。また、切替リスト３２に「マルチキャスト切替指示」があってもマルチキャストへの切り替え可能なリソースが無い場合も、一旦別のコンテンツをマルチキャストから代替ユニキャストに切り替える必要があるため、一旦ユニキャストへの切替フローへ移る（同じくＳ２０２→ｎｏ→Ｓ２３１）。
【００４３】
マルチキャストへの切替指示（Ｓ２０３）を受信したレシーバ１２は（Ｓ２０４）、直近のラストホップルータ１６に、その時点でセンダ１１から代替ユニキャストとして受信しているコンテンツに対応しているマルチキャストグループを上記（Ｓ，Ｇ）に指定した参加要求を送信する（Ｓ２０５）。その参加要求を送信するステップ自体は図４のＳ１０１と同一である。この参加要求を受けたラストホップルータ１６は、コントロールサーバ１０にこの情報を通知する（Ｓ２０６、Ｓ１０２，Ｓ１０３）。コントロールサーバ１０では、この受信した参加要求の（Ｓ，Ｇ）を始めとする内容から、上記の切替指示（Ｓ２０３）に対応する参加要求であることを判別し、上記のＳ１０４〜Ｓ１０６→ｙｅｓに相当する処理を経て（Ｓ２０７）、ラストホップルータ１６に対して許可の返答を返す。許可の返答を受けたラストホップルータ１６は、マルチキャストルーティングプロトコルに従って上記参加要求のマルチキャストグループに上記レシーバが参加して受信できるようにマルチキャスト転送制御を行う（Ｓ２０８，Ｓ１０７）。この後、図に記載の無い途中の上記ルータを経由し、ファーストホップルータ１５まで、順次、マルチキャスト転送制御を行う（Ｓ２０９，Ｓ１０８）。ファーストホップルータ１５は、センダ１１から受けていたマルチキャストを、上記ＭＣルーティングテーブルに従って、マルチキャスト配信する（Ｓ２１０）。配信されたマルチキャストは上記ルータを経由し、ラストホップルータ１６からレシーバ１２に到達する（Ｓ２１１）。
【００４４】
レシーバ１２は、その時点で代替ユニキャストを受信しているコンテンツに対応しているマルチキャストを受信したら、以後の受信をマルチキャストに切り替え、代替ユニキャストの受信を停止することになる。そのために、対応するマルチキャストを受信した受信状況をコントロールサーバ１０に報告送信する（Ｓ２１２）。この報告送信を受信したコントロールサーバ１０は（Ｓ２１３）、管理データベース３１における該当するコンテンツの該当するレシーバ１２のＩＰアドレスに対応するレコードについて、「ＭＣ／ＵＣ」の値を「ＭＣ」に更新して（Ｓ２１４）、配信形態がマルチキャストに切り替わった旨を登録する。併せて、切替リスト３２における該当するコンテンツの「マルチキャスト切替指示」の項目を削除する。ただし、この項目の削除は、マルチキャストを受信する多数のレシーバ１２の全てから、マルチキャストを受信する旨の受信状況を受信したときに行うとよい。
【００４５】
レシーバ１２からのマルチキャスト受信を確認したコントロールサーバ１０は、そのレシーバ１２が代替ユニキャストを受信していたセンダ１１に対して、該当するレシーバ１２への代替ユニキャストの配信を停止するよう、配信停止要求を送信する。この配信停止要求は、どのレシーバ１２へのどのコンテンツの受信であるかを判別可能である情報を含んでいる。この配信停止要求を受け取ったセンダ１１は（Ｓ２１５）、該当するレシーバ１２への該当する代替ユニキャストの配信を停止する（Ｓ２１６）。これで、一つのレシーバ１２への代替ユニキャストからマルチキャストへの切替が完了する。同様の処理が、マルチキャストを受信する他のレシーバ１２についても並行して行われる。
【００４６】
上記のような代替ユニキャストからマルチキャストへの処理が、Ｓ２０２での処理で可能である分について進行する。一方、マルチキャストへの切替が全て終了したり、代替ユニキャストへの切替を先に行ってマルチキャストリソースを解放しなければならない場合は、次の代替ユニキャストへの切替処理へと移る（Ｓ２０２→ｎｏ）。以降のフローが図７に対応する。
【００４７】
まず、代替ユニキャストへの切替を行う「ユニキャスト切替指示」が切替リスト３２に無い場合は（Ｓ２３１→ｎｏ）、そこで切替処理は終了となる（Ｓ２５１）。切替リスト３２に、状態が「ユニキャスト切替指示」であるコンテンツがある場合は（Ｓ２３１→ｙｅｓ）、コントロールサーバ１０の通信方式管理部３５は、そのマルチキャストを受信する全てのレシーバ１２に、代替ユニキャストでの受信に切り替えるように、ユニキャスト切替要求を送信する。このユニキャスト切替要求を受信したレシーバ１２は（Ｓ２３２）、切り替えるべきマルチキャストを送信するファーストホップルータ１５へ該当するコンテンツを送信しているセンダ１１へ、そのコンテンツのユニキャストでの配信を要求する（Ｓ２３３）。このユニキャスト配信要求を受け取ったセンダ１１は（Ｓ２３４）、指定されたコンテンツの代替ユニキャストをレシーバ１２に送信し始める（Ｓ２３５）。実際には、切り替えるべきマルチキャストを受信している複数のレシーバ１２について、並行して、このような代替ユニキャストの配信が行われる。
【００４８】
代替ユニキャストを受信したレシーバ１２は（Ｓ２３６）、実際にＬＡＮ内に接続される端末等で利用する通信を、マルチキャストから代替ユニキャストへ切替るとともに、代替ユニキャストを受信した旨と、代替ユニキャストによる受信である受信方式を含む受信状況を、コントロールサーバ１０へ送信する（Ｓ２３７）。この受信状況を受信したコントロールサーバ１０は（Ｓ２３８）、管理データベース３１の該当するコンテンツの該当するレシーバ１２についてのレコードを、「ＭＣ」から「ＵＣ」に更新する（Ｓ２３９）。また、全てのレシーバ１２から代替ユニキャストに切り替えた旨の報告を受け取ったら、切替リスト３２の状態である「ユニキャスト切替指示」を削除するとよい。更新し終わったコントロールサーバ１０は、代替ユニキャストへの切替を確認したレシーバ１２宛の切替元となるマルチキャストの配信を停止するよう、そのレシーバ１２に繋がるラストホップルータ１６へ、マルチキャスト転送制御を指示する。このマルチキャスト転送制御を指示されたラストホップルータ１６は、ＭＣルーティングテーブルを更新して、レシーバ１２への該当するコンテンツのマルチキャスト配信を停止するマルチキャスト配信制御を行う（Ｓ２４０）。さらに、ファーストホップルータ１５までの経由する上記ルータについても同様のマルチキャスト配信制御を行い、該当するレシーバ１２へのマルチキャスト配信を順次停止していく（Ｓ２４１）。
【００４９】
ファーストホップルータ１５が一つのコンテンツについてマルチキャスト配信していた全てのレシーバ１２について、マルチキャストの配信を停止するマルチキャスト配信制御が完了したら、ファーストホップルータ１５からのマルチキャストそのものを停止し、チャネルを解放する（Ｓ２４２）。なお、センダ１１からのコンテンツの送信は特に停止されることなく、再びマルチキャストに切り替える際にはファーストホップルータ１５におけるチャネルの確保と切替によってマルチキャストの配信を再開する。
【００５０】
切替リスト３２に「マルチキャスト切替指示」の項目が残っている場合、Ｓ２４２におけるチャネルの解放によって、マルチキャストを配信可能なリソースが空くことになる。これにより、図６のＳ２０２→ｙｅｓ以降の処理が可能となる。元々マルチキャストリソースを上限いっぱいまで使用している場合は、このように、マルチキャストのうちの一部を一旦代替ユニキャストにしてマルチキャストリソースを解放し、その解放したマルチキャストリソースに、代替ユニキャストからマルチキャストに切り替えるコンテンツを割り当てることで、全体として切り替えが実現できる。
【符号の説明】
【００５１】
１０  コントロールサーバ
１１  センダ
１２  レシーバ
１５  ファーストホップルータ
１６  ラストホップルータ
２１  コンテンツ保持部
２２  マルチキャスト送信部
２３  ユニキャスト送信部
３１  管理データベース
３２  切替リスト
３３  リソース評価部
３４  コンテンツ管理部
３５  通信方式管理部
４１  受信管理部
４２  マルチキャスト受信部
４３  ユニキャスト受信部
【図１】
2017183876.tif 000003
【図２】
2017183876.tif 000004
【図３】
2017183876.tif 000005
【図４】
2017183876.tif 000006
【図５】
2017183876.tif 000007
【図６】
2017183876.tif 000008
【図７】
2017183876.tif 000009
【手続補正書】
【提出日】平成29年6月29日(2017.6.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
マルチキャストネットワークへコンテンツを送信するセンダに接続して上記コンテンツ
のマルチキャスト配信を行うファーストホップルータと、上記コンテンツを受信するレシ
ーバに接続するラストホップルータとを含むマルチキャストネットワークに接続されるサ
ーバであって、
新たに上記コンテンツをマルチキャストで受信するために上記マルチキャストネットワ
ークに参加しようとする上記レシーバからの参加要求を受信し、
マルチキャストリソースの点から参加可否の判断を行い、参加不可の場合、上記レシー
バに対して、該当するコンテンツをユニキャストで配信することを上記センダへ要求する
ことを指示する、
コントロールサーバであって、
上記マルチキャストネットワークでマルチキャスト又はその代替となる代替ユニキャス
トを受信している上記レシーバに対して定期的に参加問い合わせを行い、上記レシーバの
受信状況を把握し、
この受信状況を元に、使用するマルチキャストリソースが低減できるように所定の判断
基準に従って、一部のマルチキャストを代替ユニキャストに変更し、一部の代替ユニキャ
ストをマルチキャストに変更する、コントロールサーバ。
【請求項２】
コンテンツのマルチキャスト送信を行うセンダと、上記コンテンツを受信するレシーバ
と、上記センダ及び上記レシーバの間に存在する２つ以上のルータと、上記ルータとの間
で通信可能なコントロールサーバとを有し、
上記ルータとして、上記レシーバに接続されるラストホップルータと、上記センダに接
続されるファーストホップルータを有し、
上記レシーバからのマルチキャストグループへの参加要求を受信した上記ラストホップ
ルータは、上記コントロールサーバに上記参加要求を通知し、
上記参加要求を受けた上記コントロールサーバは、参加するネットワークにおけるマル
チキャストとマルチキャストの代替となる代替ユニキャストとの情報を登録した管理デー
タベースの情報から、上記参加要求に対するマルチキャスト配信の可否を判断し、
上記マルチキャスト配信が可能である場合、
上記コントロールサーバは、上記ラストホップルータに許可の返答をし、
上記許可の返答を受けたラストホップルータは、マルチキャストルーティングプロトコ
ルに従って上記参加要求のマルチキャストグループに上記レシーバが参加して受信できる
ようにマルチキャスト転送制御を行い、
上記マルチキャスト配信が不可である場合、
上記コントロールサーバは、上記レシーバにユニキャストへの転向要求を送信し、
上記転向要求を受信した上記レシーバは、上記マルチキャストグループへの送信を行う
上記センダへ、代替となる代替ユニキャストの配信を求める代替要求を送信し、
上記代替要求を受信した上記センダは、上記マルチキャストグループの配信に対応する
内容をユニキャストで上記レシーバへ送信する、
マルチキャストシステム。
【請求項３】
上記コントロールサーバは、
上記レシーバに対して定期的な参加状況問合を送信し、
この参加状況問合に対する上記レシーバからの応答を受けて上記管理データベースを定
期的に更新し、
上記管理データベースにおける情報を元に、ネットワークの消費リソースを削減するた
めの所定の評価基準に従って、配信中のコンテンツのうち、マルチキャストとユニキャス
トとの配信方式を切り替えるコンテンツを選んで切替リストを登録し、
上記切替リストに、配信方式を切り替えるコンテンツが登録されている場合、
上記コントロールサーバは、配信方式をマルチキャストからユニキャストに切り替える
コンテンツを受信する上記レシーバへ、ユニキャスト切替要求を送信し、
上記ユニキャスト切替要求を受信した上記レシーバは、上記センダに代替ユニキャスト
の配信を要求し、
その要求を受け取った上記センダは上記レシーバへ対応するコンテンツを代替ユニキャ
ストで配信し、
その代替ユニキャストによる配信を受け取った上記レシーバは、上記コントロールサー
バへ代替ユニキャストを受信した状況を報告送信し、
この報告送信を受け取った上記コントロールサーバは、上記レシーバの配信形態がユニ
キャストに切り替わった旨を上記管理データベースに更新登録し、かつ、上記ラストホッ
プルータに上記レシーバへの切り替え元となるマルチキャストを配信停止するようマルチ
キャスト転送制御を指示し、
このマルチキャスト転送制御を受け取った上記ラストホップルータは、マルチキャスト
転送制御を行い、該当する上記レシーバへの該当するマルチキャストの配信を停止し、
一方で、
上記コントロールサーバは、配信方式を代替ユニキャストであるユニキャストからマル
チキャストに切り替えるコンテンツを受信する上記レシーバへ、マルチキャスト切替要求
を送信し、
上記マルチキャスト切替要求を受信した上記レシーバは、上記ラストホップルータにマ
ルチキャストグループへの切替参加要求を送信し、
上記切替参加要求を受信した上記ラストホップルータは、マルチキャストルーティング
プロトコルに従ってマルチキャスト転送制御を行い、切替元の代替ユニキャストに対応す
るマルチキャストを上記レシーバへ配信し、
そのマルチキャストを受信した上記レシーバは上記コントロールサーバへマルチキャス
トを受信した状況を報告送信し、
この報告送信を受け取った上記コントロールサーバは、上記レシーバの配信形態が上記
マルチキャストに切り替わった旨を上記管理データベースに更新登録し、かつ、上記セン
ダに対して、該当する上記レシーバへの代替ユニキャストを配信停止するよう配信停止要
求を指示し、
この配信停止要求を受け取った上記センダは、該当する上記レシーバへの代替ユニキャ
ストの配信を停止する、
請求項２に記載のマルチキャストシステム。
【請求項４】
上記コントロールサーバは、上記参加要求を受信した際の上記管理データベースへの登
録の際にも、上記切替リストへ登録する、配信方式を切り替えるコンテンツを選ぶステッ
プを実行する、請求項３に記載のマルチキャストシステム。