グループ管理装置、及び、マルチキャストグループ管理方法
【課題】 通信量を抑えてマルチキャストグループ管理を行うグループ管理装置、及び、マルチキャストグループ管理方法を提供する。
【解決手段】 グループ管理装置２０のトークン割当部２１は、加入要求メッセージを送信してきたデータ受信端末３０１にトークンを含んだ加入応答メッセージを送信する。データ受信端末３０１がトークン割当対象状態でないことが判明した場合に、トークン割当解除部２３は、データ受信端末３０１に対するトークンの割当を解除し、トークン割当部２１は、当該トークンを含んだ加入応答メッセージをデータ受信端末３０２に送信する。マルチキャスト配信データ中継部２４は、少なくとも１のデータ受信端末３０にトークンが割り当てられている間、マルチキャストグループに属しているデータ受信端末３０へのマルチキャスト配信データの中継を行う。
【解決手段】 グループ管理装置２０のトークン割当部２１は、加入要求メッセージを送信してきたデータ受信端末３０１にトークンを含んだ加入応答メッセージを送信する。データ受信端末３０１がトークン割当対象状態でないことが判明した場合に、トークン割当解除部２３は、データ受信端末３０１に対するトークンの割当を解除し、トークン割当部２１は、当該トークンを含んだ加入応答メッセージをデータ受信端末３０２に送信する。マルチキャスト配信データ中継部２４は、少なくとも１のデータ受信端末３０にトークンが割り当てられている間、マルチキャストグループに属しているデータ受信端末３０へのマルチキャスト配信データの中継を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチキャストグループを管理するグループ管理装置、及び、マルチキャストグループ管理方法に関する。
【背景技術】
【０００２】
従来のインターネット等を利用したデータ配信は、送信側であるデータ送信端末と受信側であるデータ受信端末との関係から、ユニキャスト配信、ブロードキャスト配信、及び、マルチキャスト配信に分類される。
ユニキャスト配信は、１つのデータ送信端末が１つのデータ受信端末にデータを配信する１対１の通信である。このため、データ送信端末が配信すべきデータ量はデータ受信端末の数に比例して大きくなり、データ受信端末の数が増加すると、データ送信端末や通信路においてデータの配信処理のための負荷が大きくなってしまう。
これに対し、ブロードキャスト配信及びマルチキャスト配信は、１つのデータ送信端末が多数のデータ受信端末にデータを配信する１対多の通信であるため、上記問題は生じない。
【０００３】
ここで、マルチキャスト配信は、ブロードキャスト配信と異なり、一回の操作で特定多数の相手にデータを配信する方式である。マルチキャスト配信の一例としては、ＩＰ（Internet protocol）を用いてマルチキャスト配信を実現するＩＰマルチキャストが広く知られている。ＩＰマルチキャストでは、同一のデータを受信するデータ受信端末のグループにマルチキャスト用のＩＰアドレスを割り当てることで、マルチキャストグループを構成する。このマルチキャストグループに割り当てられるＩＰアドレス（以下「マルチキャストアドレス」という）は当該グループに固有である。データ受信端末は、あるマルチキャストグループ宛に配信されるマルチキャスト配信データの受信を希望する場合、当該マルチキャストグループに所属してグループメンバとなる。具体的には、データ受信端末は、マルチキャストグループへの加入要求を、隣接しているグループ管理装置に送信することにより、当該マルチキャストグループに属するデータ受信端末が配下に存在することを示す情報を記憶させる。これにより、データ受信端末は、データ送信端末から当該マルチキャストグループ宛に配信されるデータを、グループ管理装置等を介して受信することができる。
【０００４】
ここで、上記マルチキャスト配信データを受信するデータ受信端末とグループ管理装置との間のマルチキャストグループ管理用プロトコルとしては、ＩＧＭＰ（Internet Group Management Protocol）が用いられている。このＩＧＭＰに対応したグループ管理装置であるＩＧＭＰルータには、自身の配下にあるデータ受信端末の中にマルチキャストグループに属しているデータ受信端末が存在するか否かを判別する機能が実装されている。
【０００５】
ＩＧＭＰやマルチキャストに関する文献としては、非特許文献１〜３が存在する。ＩＧＭＰは、ＩＧＭＰルータにおいて、データ受信端末を特定しない匿名モデルを採用している。匿名モデルでは、各データ受信端末を一つ一つ管理しないため、その管理コストの低減を図ることが可能であり、結果としてデータ受信端末数が増えた場合のスケーラビリティの確保が可能となる。
【０００６】
このようなＩＰマルチキャストの匿名モデルでは、データ受信端末を特定しないため、ユーザに対する課金やデータ受信者数の測定が不可能であるという問題点があった。そこで、ＩＧＡＰ（IGMP for user Authentication Protocol）を用いてデータ受信端末を使用するユーザの認証を行う技術が提案されている（例えば、非特許文献４参照）。ＩＧＡＰは、データ受信端末が発行するマルチキャストグループへの加入要求メッセージ（IGMP Membership Report）を拡張し、データ受信端末を使用するユーザを認証する。これにより、データ受信端末を使用するユーザを特定することが可能であり、ＩＧＭＰで提供する匿名モデルに対する課題を解決している。
【０００７】
ＩＧＭＰルータでは、最低１台のマルチキャストグループに属しているデータ受信端末（以下「グループメンバ」ともいう）が配下に存在するか否かの状態のみ保持しているため、グループメンバからマルチキャストグループ離脱要求（IGMP Leave Group）を受信した場合に、他のグループメンバが存在するか否かを確認する必要がある。このためにＩＧＭＰルータでは、IGMP Group‐Specific Queryを当該マルチキャストグループ宛にマルチキャストし、さらにそれを受信したデータ受信端末は、その返答（IGMP Membership Report）を返すことによって、他にもグループメンバが存在することをＩＧＭＰルータに伝えている。
【０００８】
以上の動作は、従来のイーサネット（登録商標）等の有線ＬＡＮ（Local Area Network）では問題とならなかったが、データ受信端末が頻繁に移動するような無線ＬＡＮでは問題となる。無線ＬＡＮにおけるデータ受信端末は頻繁に移動を繰り返す傾向にあるため、移動する毎に、移動元と移動先とのサブネットワークのＩＧＭＰルータに対してマルチキャストグループへの加入と離脱とを繰り返す必要があるためである。ＩＧＭＰでは、マルチキャストグループへの離脱を繰り返すたびに上記通信が必要となるため、無線ＬＡＮのようなネットワークではＩＧＭＰは適切ではない。
【０００９】
ＩＧＡＰでは、全てのグループメンバのユーザ認証を行うため、グループ管理装置であるＩＧＡＰルータにおいてグループメンバを厳密に管理することが可能である。こういった特徴を利用し、ＩＧＡＰでは、データ受信端末からのマルチキャストグループ離脱要求メッセージ（IGMP Leave Group）に対して、他にグループメンバが存在しているか否かを確認すること無しに、単に当該データ受信端末の管理情報を削除するFast Leave機能を提供している。これによれば、ＩＧＭＰのように、マルチキャストグループメンバの状況確認のための通信（IGMP Leave Group後のIGMP Group Specific Query）が必要ないなどの利点がある。
【００１０】
しかし、ＩＧＡＰでは、データ受信端末からのマルチキャストグループ加入要求メッセージ（IGMP Membership Report）に対するユーザ認証を実行するために、ユーザに対する課金やデータ受信者数の測定が必要ない場合には、この通信及び処理が冗長になる場合があった。
このように、ＩＧＭＰにおいては、グループメンバが離脱する度に他のグループメンバの状況を確認するための通信を行い、また、ＩＧＡＰにおいては、加入要求メッセージを受信する度にユーザ認証のための通信を行うため、どちらのプロトコルを用いても通信量が増大するという問題点があった。
【００１１】
一方、移動通信ネットワークにおけるマルチキャストグループ管理に関する技術も提案されている（例えば、特許文献１参照）。特許文献１においては、ルータ配下の移動通信端末が、他のルータ配下に移動したり、マルチキャストグループへの加入や離脱を繰り返す毎に、ルータはその旨の情報を受信してグループ管理情報を更新し、移動通信端末毎にグループ管理を行う。このような移動通信端末毎にグループ管理を行う方式では、上述した通信量が増大するという問題点を解決することはできない。
【００１２】
また、データ受信端末がマルチキャスト配信データを受信した後の応答メッセージ数を削減する技術について検討されている文献も存在する（例えば、特許文献２参照）。しかし、特許文献２に記載されている技術は、マルチキャスト配信データに対するデータ受信端末からの応答数を削減する技術であるため、ここで課題としているグループ管理のための通信量の削減に利用することは難しい。
【特許文献１】特開２００１−１７７５６４号公報
【特許文献２】特開２０００−１１５０５１号公報
【非特許文献１】Thomas Maufer著、楠本博之訳、「ＩＰマルチキャスト入門」、初版、共立出版株式会社、２００１年１１月
【非特許文献２】Dave Kosiur著、苅田幸雄監訳、「マスタリングＴＣＰ／ＩＰマルチキャスト編」、第１版、第２刷、平成１２年１１月
【非特許文献３】Beau Williamson著、コムサス訳、シスコシステムズ監訳、「ＩＰマルチキャストネットワーク開発ガイドVol.1」、初版、２００１年７月
【非特許文献４】林経正、他、著「ＩＧＡＰ：IGMP for User Authentication Protocol」、Internet‐draft、２００３年
【発明の開示】
【発明が解決しようとする課題】
【００１３】
以上のように、データ受信端末がマルチキャストグループへの加入と離脱を頻繁に繰り返すような通信環境において、どのようにグループ管理に必要な通信量を抑えるかが問題となる。
本発明は、以上の点を鑑みてなされたものであり、通信量を抑えてマルチキャストグループ管理を行うグループ管理装置、及び、マルチキャストグループ管理方法を提供することを目的とする。
【課題を解決するための手段】
【００１４】
上記課題を解決するために、請求項１に記載の発明は、自装置の配下に存在するデータ受信端末へのマルチキャスト配信データの中継を行うグループ管理装置において、あるマルチキャストグループに属している前記データ受信端末のうち、少なくとも１のデータ受信端末に対してトークンを割り当てるトークン割当手段と、前記トークンが割り当てられたデータ受信端末が、自装置の配下に存在し、かつ、前記あるマルチキャストグループに属している状態であるトークン割当対象状態であるか否かを管理するトークンメンバ管理手段と、前記トークンメンバ管理手段により、前記トークンが割り当てられたデータ受信端末が前記トークン割当対象状態でないことが判明した場合に、該データ受信端末に対するトークンの割当を解除するトークン割当解除手段と、少なくとも１のデータ受信端末に前記トークンが割り当てられている間、前記あるマルチキャストグループに属しているデータ受信端末へのマルチキャスト配信データの中継を行うマルチキャスト配信データ中継手段とを備えることを特徴とするグループ管理装置を提供する。
【００１５】
本発明によれば、前記グループ管理装置のトークン割当手段は、自装置の配下に存在し、かつ、あるマルチキャストグループに属しているデータ受信端末のうち、少なくとも１のデータ受信端末に対してトークンを割り当て、前記トークンメンバ管理手段は、前記トークンが割り当てられたデータ受信端末が前記トークン割当対象状態であるか否かを管理し、前記トークン割当解除手段は、前記トークンが割り当てられたデータ受信端末が前記トークン割当対象状態でないことが判明した場合に、該データ受信端末に対するトークンの割当を解除し、前記マルチキャスト配信データ中継手段は、少なくとも１のデータ受信端末に前記トークンが割り当てられている間、前記あるマルチキャストグループに属しているデータ受信端末へのマルチキャスト配信データの中継を行うため、前記グループ管理装置は、前記トークンが割り当てられたデータ受信端末の状態を管理するための通信量のみでグループ管理を行うことができ、グループ管理のための通信量を抑えることができる。
【００１６】
請求項２に記載の発明は、請求項１に記載のグループ管理装置において、前記トークン割当手段は、前記トークン割当解除手段により割当が解除されたトークンを、他のデータ受信端末に割り当てることを特徴とする。
本発明によれば、前記グループ管理装置のトークン割当手段は、前記トークン割当解除手段により割当が解除されたトークンを他のデータ受信端末に割り当てるため、前記トークンメンバ管理手段は、継続して、新たに前記トークンが割り当てられた前記他のデータ受信端末の状態を管理することができ、配下に前記あるマルチキャストグループに属しているデータ受信端末が存在するか否かを厳密に管理することが可能となる。
【００１７】
請求項３に記載の発明は、請求項１又は２に記載のグループ管理装置において、前記トークン割当手段は、前記データ受信端末が、自装置の配下に継続して存在しており、かつ、前記あるマルチキャストグループに継続して属している時間と、前記データ受信端末が、自装置の配下に存在し、かつ、前記あるマルチキャストグループに属していた過去の累積時間と、前記データ受信端末の機種との少なくとも１に応じて、前記トークンを割り当てるべきデータ受信端末を決定することを特徴とする。
【００１８】
本発明によれば、前記グループ管理装置のトークン割当手段は、前記あるマルチキャストグループに継続して属している時間と前記累積時間と前記機種との少なくとも１に応じて、前記トークンを割り当てるべきデータ受信端末を決定するため、前記あるマルチキャストグループに継続して属している時間や前記累積時間が長いデータ受信端末や、頻繁に移動しない機種のデータ受信端末に対して前記トークンを割り当てることが可能となる。このため、前記グループ管理装置は、加入及び離脱に伴うグループ管理のための通信量や、他のデータ受信端末に前記トークンを再割当するための通信量を削減することができる。
【００１９】
請求項４に記載の発明は、請求項１から３のいずれか１項に記載のグループ管理装置において、前記トークン割当手段は、自装置の配下に存在し、かつ、前記あるマルチキャストグループに属しているデータ受信端末の数と、前記データ受信端末が自装置の配下に継続して存在する平均時間との少なくとも一方に応じて、前記トークンを割り当てるべきデータ受信端末の数を決定することを特徴とする。
【００２０】
本発明によれば、前記グループ管理装置のトークン割当手段は、前記データ受信端末の数と前記平均時間との少なくとも一方に応じて、前記トークンを割り当てるべきデータ受信端末の数を決定するため、前記トークン割当手段は、配下に存在するデータ受信端末の数や移動状況に合わせて、前記トークンを割り当てるべきデータ受信端末の最適な数を決定することができる。このため、前記グループ管理装置は、最適な数のデータ受信端末のみを管理することができるため、通信量を抑えて、マルチキャストグループ管理を行うことができる。
【００２１】
請求項５に記載の発明は、請求項１から４のいずれか１項に記載のグループ管理装置において、前記トークンメンバ管理手段は、前記トークンが割り当てられたデータ受信端末に対してのみ、該データ受信端末より受信したメッセージに対する応答メッセージを返信することを特徴とする。
本発明によれば、前記グループ管理装置のトークンメンバ管理手段は、前記トークンが割り当てられたデータ受信端末に対してのみ、該データ受信端末より受信したメッセージに対する応答メッセージを返信するため、前記トークンが割り当てられたデータ受信端末とのメッセージ授受については、メッセージの欠落が生じないよう正確に管理することができる一方、前記トークンが割り当てられていないデータ受信端末に対しては、応答メッセージの返信を省くことができる。従って、グループ管理装置は、通信量を抑えてマルチキャストグループの管理を行うことができる。
【００２２】
請求項６に記載の発明は、請求項１から５のいずれか１項に記載のグループ管理装置において、前記トークンメンバ管理手段は、前記トークンが割り当てられたデータ受信端末に対してのみ、該データ受信端末が前記トークン割当対象状態であるか否かを確認するためのメッセージを送信することを特徴とする。
本発明によれば、前記グループ管理装置のトークンメンバ管理手段は、前記トークンが割り当てられたデータ受信端末に対してのみ、該データ受信端末が前記トークン割当対象状態であるか否かを確認するためのメッセージを送信するため、前記トークンが割り当てられているデータ受信端末ついては、正確に前記トークン割当対象状態であるか否かを管理する一方、前記トークンが割り当てられていないデータ受信端末に対しては、メッセージの送信を省くことができる。従って、前記グループ管理装置は、通信量を抑えて、マルチキャストグループ管理を行うことができる。
【００２３】
請求項７に記載の発明は、請求項１から６のいずれか１項に記載のグループ管理装置において、前記トークン割当手段は、前記あるマルチキャストグループ宛に問合せメッセージを送信することにより、該あるマルチキャストグループに属していることが確認されたデータ受信端末の中から、前記トークンを割り当てるべきデータ受信端末を決定することを特徴とする。
本発明によれば、前記グループ管理装置のトークン割当手段は、マルチキャストグループに属していることが確認されたデータ受信端末の中から前記トークンを割り当てるべきデータ受信端末を決定するため、自装置の配下に存在しなくなったりマルチキャストグループから離脱したデータ受信端末に対して、前記トークンを割り当てようとして失敗することがなくなるため、不要な通信量を削減することができる。
【００２４】
請求項８に記載の発明は、グループ管理装置が行うマルチキャストのグループ管理方法において、前記グループ管理装置の配下に存在し、かつ、あるマルチキャストグループに属しているデータ受信端末のうち、少なくとも１のデータ受信端末に対してトークンを割り当てるトークン割当ステップと、前記トークンが割り当てられたデータ受信端末の状態が、前記グループ管理装置の配下に存在していない状態と、前記あるマルチキャストグループに属していない状態との少なくとも１の状態であることが判明した場合に、前記データ受信端末に対するトークンの割当を解除するトークン割当解除ステップと、前記トークン割当解除ステップにおいて割当を解除されたトークンを、前記グループ管理装置の配下に存在し、かつ、前記あるマルチキャストグループに属しているデータ受信端末のうち、いずれか１のデータ受信端末に割り当てるトークン再割当ステップとを有し、少なくとも１のデータ受信端末に前記トークンが割り当てられている間、前記あるマルチキャストグループに属しているデータ受信端末へのマルチキャスト配信データの中継を行うことを特徴とするグループ管理方法を提供する。
本発明によれば、前記グループ管理装置は、前記トークンが割り当てられたデータ受信端末の状態を管理するための通信量のみでマルチキャストグループ管理を行うことができ、マルチキャストグループ管理のための通信量を抑えることができる。
【発明の効果】
【００２５】
本発明によれば、グループ管理装置は、自装置の配下に存在し、かつ、あるマルチキャストグループに属しているデータ受信端末のうち、少なくとも１のデータ受信端末に対してトークンを割り当て、該トークンが割り当てられたデータ受信端末が前記トークン割当対象状態であるか否かを管理するため、前記トークンが割り当てられたデータ受信端末の状態を管理するための通信量のみでマルチキャストグループ管理を行うことができ、マルチキャストグループ管理のための通信量を抑えることができる。
【発明を実施するための最良の形態】
【００２６】
次に、図面を参照しながら、本発明の実施の形態について説明する。なお、以下の説明において参照する各図においては、他の図と同等部分に同一符号が付されている。
［１．構成］
図１には、本発明の実施の形態に係るマルチキャストグループ管理システム１０の構成を示す。同図に示すように、マルチキャストグループ管理システム１０は、マルチキャストグループを管理するグループ管理装置２０と、当該グループ管理装置２０の配下に存在する複数のデータ受信端末３０とを含むネットワークで構成される。ここで、「グループ管理装置２０の配下にデータ受信端末３０が存在する」とは、グループ管理装置２０とデータ受信端末３０とが通信可能に接続されており、グループ管理装置２０がデータ受信端末３０に対するデータ配信を中継する状態のことをいう。このようなネットワークの例としてイーサネット（登録商標）や無線ＬＡＮ、移動通信網等が考えられる。グループ管理装置２０は、例えば、ルータであり、この場合には、ルータに管理されるサブネットワーク上のデータ受信端末３０が、ルータの配下に存在するデータ受信端末３０となる。データ受信端末３０は、例えば、移動通信端末やパーソナルコンピュータ（以下「ＰＣ」という）である。なお、以下の説明において、複数のデータ受信端末３０をそれぞれ区別する必要がある場合には、データ受信端末３０１、データ受信端末３０２、データ受信端末３０３、・・・、と記述する。
【００２７】
図２には、マルチキャストグループ管理システム１０と他の関連する装置とを含むネットワーク構成の一例を示す。グループ管理装置２０は、データ配信を中継するデータ中継装置４０と接続されており、グループ管理装置２０自身はデータ中継装置４０の機能も保持している。グループ管理装置２０とデータ中継装置４０とは相互に接続されており、インターネット等のネットワークを形成する。データ送信端末５０は、データ中継装置４０に接続されており、データ中継装置４０を介してネットワークにデータを配信することが可能である。
【００２８】
次に、グループ管理装置２０の構成について詳細に説明する。グループ管理装置２０は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ハードディスク、通信インターフェース、及び、内部時計を含んで構成され、一般的なコンピュータのハードウェア資源を備えている。また、ＲＯＭ、ＲＡＭ及びハードディスクには、データやプログラム等のソフトウェア資源が記憶されている。
【００２９】
グループ管理装置２０のハードディスクに記憶されるソフトウェア資源として、例えば、マルチキャストグループのメンバを管理するためのグループ管理テーブルが存在する。当該グループ管理テーブルは、グループ管理装置２０の配下に存在し、かつ、マルチキャストグループに属しているデータ受信端末３０についての管理情報を管理するためのテーブルである。当該グループ管理テーブルは、マルチキャストグループ毎に作成される。
【００３０】
図３には、グループ管理テーブルの一例を示す。同図に示すように、グループ管理テーブルには、端末フィールドと状態フィールドとトークン情報フィールドと時刻フィールドとが設けられている。端末フィールドには、ＩＰアドレス等の、データ受信端末３０を一意に識別するための情報が記録される。状態フィールドには、データ受信端末３０に対するグループ管理装置２０の状態を示す情報、例えば、授受したメッセージ内容や通信状態を示す情報が記録される。トークン情報フィールドには、本発明で大きな役割を担うトークンがデータ受信端末３０に割り当てられているか否かを示す情報が記録される。時刻フィールドには、これらのフィールドが更新された時刻を示す時刻情報が記録される。以下では、これらのフィールドに記録される「端末」と「状態」と「トークン情報」と「時刻」とを含む情報を「管理情報」という。また、グループ管理テーブルは、図示せぬ、マルチキャストグループを識別するための情報と関連付けられており、この情報によって、グループ管理テーブルが、どのマルチキャストグループを管理するためのテーブルであるかを識別することが可能である。
【００３１】
次に、本発明における「トークン」について説明する。本発明における「トークン」は、グループ管理装置２０の配下に存在し、かつ、あるマルチキャストグループに属しているデータ受信端末３０のうち、少なくとも１のデータ受信端末３０に割り当てられる情報である。トークンが割り当てられたデータ受信端末３０は、マルチキャストグループへの加入状況や、グループ管理装置２０配下からの移動状況等の管理が厳密に行われる。
【００３２】
トークンに含まれる情報としては、トークンを一意に識別するためのＩＤ、トークンが適用されるマルチキャストアドレス、及び、有効期限等が存在する。場合によっては、グループ管理装置２０の電子署名が含まれていても良い。以下では、トークンが割り当てられたデータ受信端末３０を「トークンメンバ」とも呼び、トークンが割り当てられていないデータ受信端末３０を「非トークンメンバ」とも呼ぶ。
【００３３】
また、グループ管理装置２０のハードディスクには、グループ管理テーブルに管理情報を記録するためのプログラムや、トークンをデータ受信端末３０に割り当てるためのプログラムが記憶されている。
これらのハードウェア資源とソフトウェア資源とが協働して動作することにより、図４に示す、トークン割当部２１、トークンメンバ管理部２２、トークン割当解除部２３、及び、マルチキャスト配信データ中継部２４がグループ管理装置２０に実現される。
【００３４】
トークン割当部２１は、あるマルチキャストグループに属している配下のデータ受信端末３０のうち、少なくとも１のデータ受信端末３０に対してトークンを割り当てる。具体的なトークンの割当手順としては、トークン割当部２１は、トークンを割り当てるべきデータ受信端末３０に対して、トークンを含んだ加入応答メッセージ（Join Response）をデータ受信端末３０に送信する。これにより、データ受信端末３０から加入応答確認メッセージ（Join Response ACK）を受信すると、トークン割当部２１は、グループ管理テーブルのトークン情報フィールドに、データ受信端末３０に対してトークンを割り当てたことを示す情報“Ｙｅｓ”を記録する。
【００３５】
また、トークン割当部２１は、トークン割当解除部２３がデータ受信端末３０に対するトークンの割当を解除した場合に、当該割当が解除されたトークンを、他の割当可能なデータ受信端末３０に割り当てる。
また、トークン割当部２１は、トークンを割り当てるべきデータ受信端末３０を決定する機能を有している。トークン割当部２１は、各種情報に基づいて、今後最も長い期間、マルチキャストグループから離脱せず、かつ配下から移動しないと予想されるデータ受信端末３０に対して、トークンを割り当てることに決定する。
【００３６】
具体的な決定方法の例としては、トークン割当部２１は、データ受信端末３０がグループ管理装置２０の配下に存在し続けており、かつ、あるマルチキャストグループに属し続けている「継続時間」に応じて、トークンを割り当てるべきデータ受信端末３０を決定する。例えば、トークン割当部２１は、上記「継続時間」が一番長いデータ受信端末３０に対してトークンを付与する。これは、あるマルチキャストグループに一番長く属していたデータ受信端末３０は、今後も同じ状態が続くと予想されるためである。ここでは、「継続時間」は、グループ管理テーブルの時刻フィールドに記録されている時刻情報を用いて算出される。
【００３７】
また、別の決定方法の例として、トークン割当部２１は、データ受信端末３０がグループ管理装置２０の配下に存在し、かつ、あるマルチキャストグループに属していた過去の「累積時間」に応じて、トークンを割り当てるべきデータ受信端末３０を決定する。「累積時間」の算出方法としては、例えば、グループ管理装置２０は、グループ管理テーブルの更新履歴をハードディスクに記憶しておく。そして、トークン割当部２１は、当該更新履歴に含まれる時刻情報に基づいて、データ受信端末３０があるマルチキャストグループに属していた累積時間をデータ受信端末３０毎に算出する。トークン割当部２１は、算出結果に基づいて、累積時間が最も長いデータ受信端末３０に対してトークンを割り当てることに決定する。
【００３８】
また、別の決定方法の例として、トークン割当部２１は、データ受信端末３０の機種に応じて、トークンを割り当てるべきデータ受信端末３０を決定する。具体的には、グループ管理装置２０は、データ受信端末３０から送信されてきたメッセージに含まれる機種情報をハードディスクに記録しておく。トークン割当部２１は当該機種情報を参照して、最も移動量が少ないと予想される機種のデータ受信端末３０を、トークンを割り当てるべきデータ受信端末３０として決定する。例えば、トークン割当部２１は、携帯電話機よりもＰＣを、また、ノート型ＰＣよりもデスクトップ型ＰＣを、トークンを割り当てるべきデータ受信端末３０に決定する。
【００３９】
また、トークン割当部２１は、マルチキャストグループ毎にトークンを割り当てるべきデータ受信端末３０の数を決定する機能を備えている。決定方法としては、トークン割当部２１は、グループ管理装置２０の配下に存在し、かつ、あるマルチキャストグループに属しているデータ受信端末３０の数に応じて、トークンを割り当てるべきデータ受信端末３０の数を決定する。例えば、トークン割当部２１は、あるマルチキャストグループに属している配下のデータ受信端末３０が所定の数を超えたときには、当該あるマルチキャストグループに対してトークンを割り当てるべきデータ受信端末３０の数を２台に決定する。
【００４０】
また、別の決定方法としては、トークン割当部２１は、データ受信端末３０が、グループ管理装置２０の配下に継続して存在する平均時間に基づき、トークンを割り当てるべきデータ受信端末３０の数を変更しても良い。例えば、平均時間が所定の閾値よりも短い場合には、トークン割当部２１は、配下のネットワーク上に存在するデータ受信端末３０が移動する傾向が強いと判断し、トークンを割り当てるべきデータ受信端末３０の数を増加させても良い。このようにトークンメンバの数を増加させることにより、グループ管理テーブルに記録されているグループメンバと実際配下に存在するグループメンバとの不一致が多く発生した場合にも、グループ管理装置２０が送信したメッセージに対する応答が得られる確率が高くなるため、離脱遅延（Leave Latency）の問題を解消することが可能である。
【００４１】
なお、トークン割当部２１は、場合によっては、配下のあるマルチキャストグループに属しているデータ受信端末３０全てに対してトークンを割り当てても良い。この場合には、グループ管理装置２０とデータ受信端末３０とは１対１の状態管理を行うことになり、厳密なグループメンバの管理が可能である。このような管理方法はグループメンバ数が少ない場合には有効である。しかし、グループメンバ数が増加した場合には、スケーラビリティの問題が発生するため、この場合には逆に与えるトークン数を減少させ、一部のグループメンバのみトークンを与えるというような管理方法をとるのがよい。
【００４２】
トークンメンバ管理部２２は、前記トークン割当部２１によりトークンが割り当てられたデータ受信端末３０が「トークン割当対象状態」であるか否かを管理する。ここで、「トークン割当対象状態」とは、あるマルチキャストグループに対応するトークンが割り当てられたデータ受信端末３０が、継続して、グループ管理装置２０の配下に存在し、かつ、当該あるマルチキャストグループに属している状態をいう。従って、あるマルチキャストグループに対応するトークンが割り当てられたデータ受信端末３０が、グループ管理装置２０の配下に存在しなくなった場合、すなわち、当該データ受信端末３０が、他のグループ管理装置２０の配下に移動したり、電源断となった場合には、当該データ受信端末３０は「トークン割当対象状態」でなくなる。また、当該データ受信端末３０が、あるマルチキャストグループから離脱するために離脱要求メッセージ（Leave Request）をグループ管理装置２０に送信した場合にも、当該データ受信端末３０は「トークン割当対象状態」でなくなる。
【００４３】
トークンメンバ管理部２２による「トークン割当対象状態」の具体的な管理方法としては、以下の方法がある。トークンメンバ管理部２２は、トークンが割り当てられたデータ受信端末３０に対してのみ、受信したメッセージに対する応答メッセージを返信し、メッセージの欠落が生じないように管理する。データ受信端末３０から受信するメッセージには、例えば、加入要求メッセージ（Join Request）や離脱要求メッセージ（Leave Request）がある。なお、「トークンが割り当てられたデータ受信端末３０」には、トークン割当対象に決定されたデータ受信端末３０も含まれる。また、他の管理方法としては、トークンメンバ管理部２２は、トークンが割り当てられたデータ受信端末３０に対してのみ、状態を確認するための状態確認メッセージ（Hello）を送信する。
【００４４】
トークンメンバ管理部２２は、以上のようなメッセージの授受により、トークンが割り当てられているデータ受信端末３０が「トークン割当対象状態」であるか否かを厳密に管理する。
トークン割当解除部２３は、トークンメンバ管理部２２による管理によって、トークンが割り当てられているデータ受信端末３０が「トークン割当対象状態」でないことが判明した場合に、当該データ受信端末３０に対するトークンの割当を解除する。具体的な割当解除方法としては、トークン割当解除部２３は、グループ管理テーブルのデータ受信端末３０に対するトークン情報フィールドを“Ｎｏ”に更新する。
【００４５】
マルチキャスト配信データ中継部２４は、少なくとも１のデータ受信端末３０にトークンが割り当てられている間、当該トークンに対応するマルチキャストグループに属しているデータ受信端末３０へのマルチキャスト配信データの中継を行う。少なくとも１のデータ受信端末３０に、あるマルチキャストグループに対応するトークンが割り当てられているか否かの判断は、あるマルチキャストグループのグループ管理テーブルのトークン状態フィールドに“Ｙｅｓ”が記述されている管理情報が存在するか否かによって判断される。
【００４６】
［２．動作］
以下では、マルチキャストグループ管理システム１０におけるマルチキャストグループ管理方法について、図を用いて説明する。
本発明に係るマルチキャストグループ管理方法においては、グループ管理装置２０の配下に存在するデータ受信端末３０の中に、あるマルチキャストグループ宛に配信されるマルチキャスト配信データの受信を所望するデータ受信端末３０が存在するか否かを管理する方法を提供する。
【００４７】
（最初のグループメンバ加入時のトークン割当処理）
図５〜図８は、データ受信端末３０１が最初のグループメンバとして、あるマルチキャストグループ（ここでは、「マルチキャストグループＡ」とする）に加入する場合に行われるトークン割当処理の動作手順を説明する図である。
データ受信端末３０１が最初のグループメンバであるため、本手順を実行する時点においては、グループ管理装置２０のハードディスクには、マルチキャストグループＡのグループ管理テーブルは作成されていない。また、ここでは、グループ管理装置２０配下のマルチキャストグループＡのメンバに対して、１つのトークンが割り当てられるものとする。
【００４８】
まず、データ受信端末３０１は、加入要求メッセージ（Join Request）をグループ管理装置２０に対して送信することで、マルチキャストグループＡ宛に配信されるデータの受信を所望することを伝える（図５及び図６のステップＳ１）。
Join Requestを受信したグループ管理装置２０は、ハードディスクにマルチキャストグループＡのグループ管理テーブルが存在するか否かを確認する。ここでは、マルチキャストグループＡのグループ管理テーブルが存在しないことから、グループ管理装置２０は、データ受信端末３０１が当該マルチキャストグループＡにおける最初のグループメンバとなることが分かる。そして、グループ管理装置２０は、当該マルチキャストグループＡのグループ管理テーブルを作成する（図５のステップＳ２）。
【００４９】
同時に、グループ管理装置２０のマルチキャスト配信データ中継部２４は、当該マルチキャストグループＡ宛のマルチキャスト配信データを中継するために、ＰＩＭ（Protocol Independent Multicast）等のマルチキャストルーティングプロトコルを用いてマルチキャスト配信経路を構築する（図５のステップＳ３）。そして、マルチキャスト配信データ中継部２４は、マルチキャストグループＡに属するデータ受信端末３０１に対してマルチキャスト配信データの中継を行う。これによって、データ受信端末３０１は、当該マルチキャスト配信データの受信が可能となる。
【００５０】
グループ管理装置２０は、Join Requestを受信すると、グループ管理テーブルにデータ受信端末３０１の管理情報を記述するための領域を作成する。そして、グループ管理装置２０は、作成した領域の端末フィールドにデータ受信端末３０１を識別するための情報“３０１”を記録し、状態フィールドにJoin Requestを受信したことを示す情報“Join Received”を記録し、トークン情報フィールドに“Ｎｏ”を記録し、時刻フィールドにJoin Requestを受信した時刻“１１：３０”を記録する（図５及び図６のステップＳ４）。
【００５１】
ここで、グループ管理装置２０のトークン割当部２１は、マルチキャストグループＡのグループメンバに少なくとも１のトークンを割り当てる必要があるが、現在マルチキャストグループＡの最初のグループメンバとなるデータ受信端末３０１からのJoin Requestを受信しているため、データ受信端末３０１にトークンを割り当てることに決定する。そして、トークン割当部２１は、トークンを一意に識別するためのトークンＩＤと、マルチキャストグループＡを識別するためのマルチキャストアドレスとを含むトークンを生成する。
【００５２】
トークンメンバ管理部２２は、データ受信端末３０１に対して、生成したトークンを含む加入応答メッセージ（Join Response）を返す（図５及び図７のステップＳ５）。次いで、トークンメンバ管理部２２は、グループ管理テーブルの状態フィールドに、Join Responseを送信したことを示す情報“Join Response Sent”を記録する（図５及び図７のステップＳ６）。
Join Requestを受信したデータ受信端末３０１は、加入応答確認メッセージ（Join Response ACK）を返す（図５及び図８のステップＳ７）。
【００５３】
Join Response ACKを受信したグループ管理装置２０のトークンメンバ管理部２２は、グループ管理テーブルの状態フィールドに、Join Response ACKが届いたことを示す情報“Connected”を記録する。さらに、トークンメンバ管理部２２は、トークンが無事にデータ受信端末３０１に届いたことが確認できたため、トークン情報フィールドに“Ｙｅｓ”を記録する（図５及び図８のステップＳ８）。
以上の動作により、グループ管理装置２０は、マルチキャストグループＡの最初のグループメンバであるデータ受信端末３０１に対してのトークンの割当と、その確認応答とを完了することが出来る。
【００５４】
（二番目以降のグループメンバの加入）
次に、図９及び図１０を参照して、データ受信端末３０２が二番目以降のグループメンバとしてマルチキャストグループＡに加入する時の動作手順を説明する。
データ受信端末３０２は、データ受信端末３０１と同様に、加入要求メッセージ（Join Request）をグループ管理装置２０に対して送信することで、マルチキャストグループＡ宛に配信されるマルチキャスト配信データの受信を所望することを伝える（図９及び図１０のステップＳ１１）。本手順は最初のグループメンバ加入時と同様である。
【００５５】
Join Requestを受信したグループ管理装置２０は、マルチキャストグループＡを管理するためのグループ管理テーブルが既に作成されているか否かを確認する。ここでは、グループ管理装置２０のハードディスクに、マルチキャストグループＡのグループ管理テーブルが既に作成されており、当該グループ管理テーブルに、データ受信端末３０１に関する管理情報が記録されていることから、データ受信端末３０２がマルチキャストグループＡにおける二番目以降のグループメンバであることが分かる。グループ管理装置２０は、マルチキャストグループＡのグループ管理テーブルに、データ受信端末３０２の管理情報を追加する。具体的には、グループ管理装置２０は、グループ管理テーブルにデータ受信端末３０２の管理情報を記録するための領域を作成する。そして、グループ管理装置２０は、作成した領域の端末フィールドに、データ受信端末３０２を識別するための情報“３０２”を記録し、状態フィールドに“Join Received”を記録し、トークン情報フィールドに“Ｎｏ”を記録し、時刻フィールドに、Join Requestを受信した時刻“１１：３４”を記録する（図９及び図１０のステップＳ１２）。
【００５６】
グループ管理装置２０は、二番目以降のグループメンバからJoin Requestを受信した場合には、二番目以降のグループメンバにトークンを割り当てる必要がないため、ここで処理を終了する。
データ受信端末３０２は、データ受信端末３０１がすでにマルチキャストグループＡのメンバであることから、Join Request送出時点からマルチキャスト配信データを受信することが出来る。
【００５７】
（トークンメンバ離脱時のトークン割当解除処理）
図１１〜図１６は、トークンメンバであるデータ受信端末３０１が、マルチキャストグループＡ宛のマルチキャスト配信データの受信を希望しない場合や、グループ管理装置２０の配下から移動する場合に、マルチキャストグループＡから離脱する際のトークン割当解除処理の動作手順を示す図である。なお、ここでは、マルチキャストグループＡのグループ管理テーブルに、データ受信端末３０３やデータ受信端末３０４についてもグループメンバとして記録されている状態から説明を開始する。
データ受信端末３０１は、離脱要求メッセージ（Leave Request）をグループ管理装置２０に対して送信することで、マルチキャストグループＡからの離脱を所望することを伝える（図１１及び図１２のステップＳ２１）。このLeave Requestには、データ受信端末３０１が開放するトークンに関する情報を含む。
【００５８】
Leave Requestを受信したグループ管理装置２０のトークンメンバ管理部２２は、グループ管理テーブルを参照して、データ受信端末３０１に対するトークン情報フィールドに“Ｙｅｓ”が記録されていることから、トークンメンバであるデータ受信端末３０１からのLeave Requestであると判断する。そして、トークンメンバ管理部２２は、グループ管理テーブルのデータ受信端末３０１に対する状態フィールドを、データ受信端末３０１からLeave Requestを受信したことを示す情報“Leave Request Received”で更新する。さらに、トークンメンバ管理部２２は、受信したトークンに関する情報が正しい情報であるかどうかを判断する。例えば、トークンメンバ管理部２２は、一般的な改ざんチェックや送信元の正当性チェックを行う。例えば、トークンの改ざんチェックの方法の一例として、鍵付きハッシュ関数を用いて生成したメッセージ認証コードを、トークンとして用いたり、トークンの付属情報として付加する方法がある。判断の結果、正しいトークンであると判断すると、トークンメンバ管理部２２は、データ受信端末３０１が「トークン割当対象状態」でなくなったと判断する。
【００５９】
これにより、トークン割当解除部２３は、データ受信端末３０１のトークン情報フィールドを“Ｎｏ”に変更することにより、トークンが返却された、すなわち、当該データ受信端末３０１に対するトークンの割当が解除されたことを記録する（図１１及び図１２のステップＳ２２）。
その後、グループ管理装置２０のトークンメンバ管理部２２は、当該データ受信端末３０１に対して離脱要求確認メッセージ（Leave Request ACK）を返す（図１１及び図１３のステップＳ２３）。そして、グループ管理装置２０のトークンメンバ管理部２２は、グループ管理テーブルに記録されているデータ受信端末３０１に関する管理情報を削除する（図１１及び図１３のステップＳ２４）。
以上の手順によりトークンメンバであるデータ受信端末３０１のマルチキャストグループＡからの離脱が完了する。
【００６０】
＜他端末へのトークンの付与＞
ここでトークンは、マルチキャストグループメンバの中で最低１台のデータ受信端末３０に割り当てられるという特徴を持つものであるため、グループ管理装置２０のトークン割当部２１は、データ受信端末３０１に割り当てられていたトークンを、別のデータ受信端末３０に対して割り当てる必要がある。
そこで、マルチキャストグループＡのグループ管理テーブルに、グループメンバとして記録されているデータ受信端末３０が存在する場合には（図１４のステップＳ３１；Ｙｅｓ）、グループ管理装置２０のトークン割当部２１は、グループ管理テーブルから、最も過去の時刻情報を含む管理情報を検索し、当該検索された管理情報に対するデータ受信端末３０を、次のトークンメンバとして選出する（図１４のステップＳ３３）。
【００６１】
なお、グループ管理テーブルに他のデータ受信端末３０が記録されていない場合には（図１４のステップＳ３１；Ｎｏ）、この時点でマルチキャストグループＡのグループメンバが配下に存在しないことになる。このため、トークンメンバ管理部２２は、当該グループ管理テーブル自体をハードディスクから削除する。これにより、マルチキャスト配信データ中継部２４は、マルチキャストグループＡに対する配信データの中継を停止する（図１４のステップＳ３２）。
【００６２】
ここでは、図１５に示すように、グループ管理テーブルにグループメンバとして記録されているデータ受信端末３０が存在し（図１４のステップＳ３１；Ｙｅｓ）、グループ管理テーブルの時刻フィールドに記録されている時刻情報から、データ受信端末３０２が一番長い時間、配下でマルチキャストグループＡにグループメンバとして属していることが判る。このため、トークン割当部２１は、データ受信端末３０２を次のトークンメンバとして選出することになる（図１４のステップＳ３３）。
【００６３】
次に、次のトークンメンバとして選出されたデータ受信端末３０２へのトークンの割当処理について説明する。グループ管理装置２０のトークン割当部２１は、次のトークンメンバとなるべきデータ受信端末３０２に対して、トークンを含んだ加入応答メッセージ（Join Response）を返す（図１４及び図１５のステップＳ３４）。また、グループ管理装置２０のトークンメンバ管理部２２は、グループ管理テーブルのデータ受信端末３０２に対する状態フィールドに、Join Responseを送信したことを示す情報として“Join Response Sent”を記録する（図１４及び図１５のステップＳ３５）。
【００６４】
Join Responseを受信したデータ受信端末３０２は、加入応答確認メッセージ（Join Response ACK）を返す（図１４及び図１６のステップＳ３６）。
Join Response ACKを受信したグループ管理装置２０のトークンメンバ管理部２２は、グループ管理テーブルのデータ受信端末３０２に対する状態フィールドに、加入応答確認が完了したことを示す情報として“Connected”を記録する。さらに、Join Response ACKにより、トークンが無事にデータ受信端末３０２に届いたことを確認できたため、トークン割当部２１は、データ受信端末３０２に対するトークン情報フィールドに“Ｙｅｓ”を記録する（図１４及び図１６のステップＳ３７）。
【００６５】
以上の動作によって、トークン割当解除部２３によりトークンメンバであるデータ受信端末３０１に対するトークンの割当が解除された場合に、グループ管理装置２０のトークン割当部２１は、次のトークンメンバとなるべきデータ受信端末３０２に対してトークンを割り当てることができる。
【００６６】
（非トークンメンバの離脱）
図１７及び図１８は、非トークンメンバであるデータ受信端末３０３がマルチキャストグループＡから離脱する場合の動作手順を説明したものである。
本手順を開始する時点においては、グループ管理テーブルには図１６に示す管理情報が記録されているものとする。
まず、データ受信端末３０３は、離脱要求メッセージ（Leave Request）をグループ管理装置２０に対して送信することで、マルチキャストグループＡのグループメンバに配信されるデータの受信停止を所望することを伝える（図１７及び図１８のステップＳ４１）。
【００６７】
Leave Requestを受信したグループ管理装置２０は、図１６のグループ管理テーブルに示すように、データ受信端末３０３に対するトークン情報フィールドに“Ｎｏ”が記録されていることから、非トークンメンバであるデータ受信端末３０３からのLeave Requestであると判断する。そして、グループ管理装置２０は、グループ管理テーブルから、データ受信端末３０３に関する管理情報を削除する（図１７及び図１８のステップＳ４２）。以上の動作により、非トークンメンバの離脱手順が完了する。
【００６８】
（トークンメンバのKeep Alive）
以上説明したように、グループ管理装置２０のトークン割当部２１は、配下に存在するマルチキャストのグループメンバを、トークンメンバと非トークンメンバに分ける。そして、トークンメンバ管理部２２は、トークンメンバに関しては各メッセージのやり取りに対して確認応答を行い、厳密なメンバシップ管理を行う。これにより、トークンメンバ管理部２２は、トークンメンバが「トークン割当対象状態」であることを厳密に管理する。一方、非トークンメンバに関してはメッセージのやり取りを最小限に抑えて厳密な管理を行わないことで、グループ管理装置２０におけるスケーラビリティを確保しようとするのが本発明の特徴である。
【００６９】
従って、グループ管理装置２０のトークンメンバ管理部２２は、トークンメンバに対しては、確認応答を行う以外にも、定期的に状況確認を行い、トークンメンバが配下においてそのマルチキャストグループに属しているか否か、すなわち、トークンメンバが「トークン割当対象状態」であるか否かを厳密に管理する必要がある。
図１９及び図２０を参照しながら、トークンメンバが「トークン割当対象状態」であることを確認するためのKeep Alive手順について説明する。
【００７０】
図１９では、グループ管理装置２０のトークンメンバ管理部２２が、トークンメンバに対して、定期的に状態確認メッセージ（Hello）を送信する（図１９のステップＳ５１）。Helloは、決められたタイマに従って、トークンメンバに対して送信される。
Helloを受信したトークンメンバであるデータ受信端末３０２は、Helloの応答として状態確認応答メッセージ（Hello ACK）を返す（図２０のステップＳ５２）。
以上の動作により、グループ管理装置２０のトークンメンバ管理部２２は、トークンメンバであるデータ受信端末３０２が「トークン割当対象状態」であることを確認することができる。
【００７１】
グループ管理装置２０のトークンメンバ管理部２２は、トークンメンバにHelloを送信したものの、一定のタイムアウト時間を待ってもその応答が無い場合には、当該トークンメンバが「トークン割当対象状態」でなくなったと判断する。これにより、トークン割当解除部２３は、トークンメンバに対するトークンの割当を解除する。具体的には、トークン割当解除部２３は、トークンメンバの管理情報をグループ管理テーブルより削除する。次いで、トークン割当部２１は、トークンの割当が解除されたのを検知して、図１４に示す手順に従い、配下に存在する他のグループメンバに対するトークン割当処理を行う。これにより、トークン割当部２１は、配下のサブネットワーク上にトークンメンバが最低一台存在するように制御することとなる。
【００７２】
（非トークンメンバの突然の離脱）
非トークンメンバについては、Join RequestもしくはLeave Requestに対する確認応答を行わず、さらにKeep Aliveによる状態確認を行わないため、グループ管理装置２０のグループ管理テーブルで管理されるデータ受信端末３０の加入状況と、実際のデータ受信端末３０の加入状況とが一致しない場合がしばしば発生する。
例えば、データ受信端末３０が頻繁に移動する無線ＬＡＮのようなモバイルネットワークにおいては、非トークンメンバであるデータ受信端末３０が、Leave Requestを送信すること無しに、他のグループ管理装置２０の配下に移動してしまうことが当然発生する。また、データ受信端末３０が突然電源断となった場合なども考えられる。その際には、グループ管理装置２０は、自身が保持するグループ管理テーブルで管理される加入状況と、実際の加入状況が一致しないという状態が発生する。このような状態が問題となる場合として、図１４に示すような、非トークンメンバがトークンを割り当てられてトークンメンバに変化する例が存在する。
【００７３】
図１４及び図１５のステップＳ３４において、グループ管理装置２０がJoin Responseを送信した時に、データ受信端末３０２がすでに存在しない場合の動作手順を、図２１を参照して説明する。
図２１には、データ受信端末３０２が電源断や移動により、Leave Requestを出すこと無しに不在になった状況を示している。このような場合には、グループ管理装置２０のトークンメンバ管理部２２は、Join Responseを出すものの、それに対する応答（リプライ）が無いために、当該データ受信端末３０２が「トークン割当対象状態」でないものと判断する。そして、トークン割当解除部２３は、グループ管理テーブルから、データ受信端末３０２に関する管理情報を削除する。
その後、グループ管理装置２０のトークン割当部２１は、他のデータ受信端末３０に対してトークンを与えるための手順を行うために、図１４に示す他端末へのトークンの割当手順を実行する。
【００７４】
（Membership Query）
非トークンメンバの突然の離脱が多くのデータ受信端末３０に渡ると、図２１で説明したような、Join Responseに対するリプライを返信しないデータ受信端末３０が多数存在することになる。このような場合には、グループ管理装置２０のトークン割当部２１は、トークンをデータ受信端末３０に対して割り当てるために、連続してJoin Responseをデータ受信端末３０に対して送信する場合がある。
【００７５】
具体的な例として、グループ管理装置２０が、グループ管理テーブルに記録されている管理情報に基づいて、配下にグループメンバが多数存在すると把握していたとしても、グループメンバの電源断や移動等の理由で、自装置２０の配下に存在すると把握していた全てのグループメンバが実際には存在しない場合も考えられる。このような場合には、グループ管理装置２０のトークン割当部２１は、グループ管理テーブルにグループメンバとして記録されている全てのデータ受信端末３０に対して順にトークンを与えようとし、さらにそのリプライを待ち続けるという状況が発生する。このような例においては、グループ管理装置２０はマルチキャスト配信データの中継が必要ない場合にも当該データの中継を続けてしまうという離脱遅延（Leave Latency）の問題が発生し、結果としてネットワークの利用効率を著しく低下させる原因となる。
【００７６】
以上のことから、グループ管理装置２０のトークン割当部２１は、Join Responseの代わりに加入者問い合わせメッセージ（Membership Query）をネットワーク全体にマルチキャスト配信しても良い。
図２２は、グループ管理装置２０がMembership Queryを用いて、マルチキャストグループメンバの確認を行った場合の例を示す。データ受信端末３０は、Membership Queryを受信すると、グループ管理装置２０から指定された最大応答時間（Max Response Time）の範囲内でタイマを起動し、そのタイマが満了した場合には、グループ管理装置２０に対してJoin Requestを改めて送信する。
【００７７】
これにより、グループ管理装置２０は、どのデータ受信端末３０がグループメンバとして存在しているか否かを確認することが可能となる。このように、トークン割当部２１は、グループ管理テーブルで管理されているグループメンバの加入状況と実際の加入状況とを一致させるために、Membership Queryを用いることができる。
グループ管理装置２０のトークン割当部２１は、Join Responseを個々のデータ受信端末３０に送信する代わりにMembership Queryを使用するか否かを決定することが出来る。例えば、Join Responseに対するタイムアウトがある決められた値回数以上発生した場合に、グループ管理テーブルで管理されているグループメンバの加入状況と実際の加入状況とが一致していない可能性が高いと考えられるため、トークン割当部２１はMembership Queryを使用するという決定方法が考えられる。
【００７８】
グループ管理装置２０は、定期的にMembership Queryを用いて、配下のデータ受信端末３０の加入状況確認を行っても良い。例えば、無線ＬＡＮ等のデータ受信端末３０が頻繁に移動するネットワークで用いられるグループ管理装置２０の場合、Membership Query発行の時間間隔を短くするなどの工夫が考えられる。
【００７９】
（メッセージの欠落による状態不一致）
トークンメンバであるデータ受信端末３０とグループ管理装置２０とのメッセージのやり取りは、マルチキャストグループ加入の際に、Join Request→Join Response→Join Response ACK、マルチキャストグループ離脱の際に、Leave Request→Leave Request ACKの構成となっており、いずれかのメッセージが欠落した場合には再送により対処することが出来る。
【００８０】
例えば、マルチキャストグループへの加入の際に、Join Responseが何らかの原因で欠落した場合には、グループ管理装置２０のトークンメンバ管理部２２は、Join Response ACKが戻ってこないことによりその状況を把握する。そしてグループ管理装置２０のトークンメンバ管理部２２は、Join Responseを再送することによりメッセージの欠落に対処する。Join Response ACKが欠落した場合にも同様である。
【００８１】
同様に、Leave RequestやLeave Request ACKの欠落に対しても、データ受信端末３０は、Leave Request に対するLeave Request ACKが届かないことにより、データの欠落を検出することができる。データの欠落を検出したデータ受信端末３０は、Leave Requestを再送することでメッセージの欠落に対処することが可能である、
ただし、非トークンメンバの場合には、非トークンメンバが送信したJoin RequestとLeave Requestとのいずれに対してもグループ管理装置２０から応答が無いため、それらのメッセージが欠落したとしても、欠落していることを検出することが出来ない場合がある。
【００８２】
例えば、最初にあるマルチキャストグループに加入するためのJoin Requestを発行したトークンメンバとなるべきデータ受信端末３０のJoin Requestが欠落した場合には、データ受信端末３０はマルチキャスト配信データの配信を受けることができないため、データ受信端末３０はJoin Requestを再送するための判断をすることが可能である。
【００８３】
一方、非トークンメンバが送信したJoin Requestが欠落した場合には、そのメッセージが実際にグループ管理装置２０に届いていないにもかかわらず、非トークンメンバはマルチキャスト配信データを受信することは可能であるため、グループ管理テーブルで管理されているグループメンバの加入状況と実際の加入状況との不一致が発生する。このような場合、データ受信端末３０は、実際にはグループメンバであるのにもかかわらずグループ管理装置２０には認識されないという状況が発生するため、他のグループメンバの離脱によって突然マルチキャスト配信データの中継が停止されてしまうことも考えられる。このような場合には、データ受信端末３０は、マルチキャスト配信データの受信が終了してしまったことで何らかの異常が発生したと判断し、Join Requestを改めて送信するなどの対処が必要である。
【００８４】
グループ管理装置２０は、以上のような状況が発生することを鑑み、最後のグループメンバが離脱したと判断したときには、データの中継を停止する前にMembership Queryを用いて残存しているグループメンバが存在するか否かを問い合わせても良い。このようにすれば、グループ管理装置２０は、非トークンメンバヘのマルチキャストデータの中継を停止してしまうということが無くなる。
【００８５】
（非グループメンバのメッセージの受信）
グループ管理装置２０のグループ管理テーブルで管理されているグループ加入状況と実際のデータ受信端末３０のグループ加入状況とが不一致である場合に、データ受信端末３０は、あるマルチキャストグループのメンバで無いのに、Join Response、Hello、或いは、Membership Queryを受信することがある。
【００８６】
このような場合、データ受信端末３０が当該メッセージを無視することによって、結果的にグループ管理装置２０は当該データ受信端末３０が存在しないと判断するため、グループ管理テーブルで管理されているグループ加入状況を実際のグループ加入状況に一致させることが出来る。しかし、無視することによってグループ管理装置２０のタイムアウトを発生させる方法では、グループ管理装置２０がメッセージを送信してからグループ管理テーブルを更新するまでのタイムラグが生じる。
従って、データ受信端末３０は、あるマルチキャストグループのメンバで無いのに、そのグループに対するJoin Response、Hello、又は、Membership Queryを受信した場合には、それに対する否定応答（NACK）を返しても良い。NACKを返すことによって、グループ管理装置２０はいち早く不一致を把握することが可能である。
【００８７】
（各メッセージの宛先アドレス）
図２３は、以上に説明した各メッセージの一覧をまとめたものである。
Join Requestは、データ受信端末３０からグループ管理装置２０に対して送信するものであるため、グループ管理装置２０のユニキャストアドレスがその宛先となる。もしくは、グループ管理装置２０群あてのマルチキャストグループアドレスをあらかじめ割り当て、それを宛先アドレスとしても良い。もしくはグループ管理装置２０用に割り当てられたエニイキャストアドレスがある場合には、それを宛先アドレスにしても良い。
【００８８】
Join Responseは、グループ管理装置２０からデータ受信端末３０に対して送信するものであり、データ受信端末３０のユニキャストアドレスがその宛先アドレスに用いられる。
Join Response ACKは、データ受信端末３０からグループ管理装置２０に対して送信するものであり、Join Responseと同様に３種類の宛先アドレスの設定方法が存在する。
【００８９】
Leave Requestは、データ受信端末３０からグループ管理装置２０に対して送信するものであるため、グループ管理装置２０のユニキャストアドレスがその宛先となる。もしくは、グループ管理装置２０群あてのマルチキャストグループアドレスをあらかじめ割り当て、それを宛先アドレスとしても良い。もしくはグループ管理装置２０用に割り当てられたエニイキャストアドレスがある場合には、それを宛先アドレスにしても良い。
【００９０】
Leave Request ACKは、グループ管理装置２０からデータ受信端末３０に対して送信するものであり、データ受信端末３０のユニキャストアドレスがその宛先アドレスに用いられる。
Membership Queryに関しては、グループ管理装置２０から当該マルチキャストグループのメンバであるデータ受信端末３０に対して送信されるメッセージであるため、当該マルチキャストアドレスがその宛先に用いられる。
【００９１】
Helloに関しては、グループ管理装置２０からデータ受信端末３０に対して送信されるものであるため、データ受信端末３０のユニキャストアドレスがその宛先アドレスに用いられる。
但し、前に説明するようにトークンメンバは複数存在することも考えられるので、トークンメンバ全てに対してHelloメッセージをするために、トークンメンバ用マルチキャストグループを宛先としても良い。
【００９２】
Hello ACKに関しては、データ受信端末３０からグループ管理装置２０に対して送信するものであるため、グループ管理装置２０のユニキャストアドレスがその宛先となる。もしくは、グループ管理装置２０群あてのマルチキャストグループアドレスをあらかじめ割り当て、それを宛先アドレスとしても良い。もしくはグループ管理装置２０用に割り当てられたエニイキャストアドレスがある場合には、それを宛先アドレスにしても良い。
【００９３】
（まとめ）
以上説明したように、グループ管理装置２０は、トークンが割り当てられたデータ受信端末３０のみを厳密に管理することによって、グループ管理のための通信量を抑えることができる。また、グループ管理装置２０は、トークンが割り当てられたデータ受信端末３０を厳密に管理することにより、少なくとも１のデータ受信端末３０にトークンが割り当てられているか否かによって、マルチキャストグループに属しているデータ受信端末３０が配下に存在しているか否かを判断することができる。このため、従来のように、配下にグループメンバが存在しているか否かを確認するためのメッセージを送信する必要がなくなる。このように、本発明によって、通信量を抑えたマルチキャストグループ管理を行うことが可能となる。
【００９４】
また、無線ＬＡＮ等のモバイル環境においては、データ受信端末３０は頻繁に移動し、グループ管理装置２０配下のマルチキャストグループに属している期間は通常短くなるものと考えられる。このため、頻繁に移動するデータ受信端末３０に対しては、トークンを割り当てないことによって、厳密な管理を行わないようにする。その一方、移動が少なくマルチキャストグループに属している期間が長い一部のデータ受信端末３０に対しては、トークンを割り当てて厳密に管理する。このようなグループ管理を行うことで、データ受信端末３０の移動に伴い発生する加入、離脱による余計な通信が発生しないようにすることが可能となる。
【００９５】
［３．変形例］
以上、本発明の実施形態について説明したが、本発明は係る実施形態に限定されるものではなく、その技術思想の範囲内で様々な変形が可能である。変形例としては、例えば、以下のようなものが考えられる。
（１）上述した実施形態におけるトークン割当部２１によるトークン割当の方法としては、トークン割当部２１が、トークンに関する情報を含んだJoin Responseをデータ受信端末３０に送信することによって、データ受信端末３０にトークンを記憶させるようにしたが、これに限定されることはない。例えば、トークンに関する情報を含まないJoin Responseをデータ受信端末３０に送信し、データ受信端末３０に対してトークンを割り当てた旨の情報をグループ管理テーブルに記録しておくだけでもよい。
【００９６】
（２）上述した実施形態においては、トークンは、基本的に、あるマルチキャストグループに最初に加入したデータ受信端末３０に対して与えられるとして説明したが、これに限定されることはない。例えば、１秒差で、グループメンバが存在していない同一のマルチキャストグループへの加入要求を、２つのデータ受信端末３０より受信した場合には、トークン割当部２１は、例えば、データ受信端末３０の機種によって、どちらのデータ受信端末３０にトークンを割り当てるかを決定するようにしてもよい。
【００９７】
（３）上述した実施形態においては、データ受信端末３０は、グループ管理装置２０の配下から移動する時に、基本的に離脱要求メッセージ（Leave Request）を送信することを前提として説明したが、これに限定されることはない。データ受信端末３０がグループ管理装置２０の配下から移動する時に、離脱要求メッセージ（Leave Request）を送信しない場合には、グループ管理装置２０は、加入者問い合わせメッセージ（Membership Query）を送信したり、または、データ受信端末３０の位置情報を受信して、データ受信端末３０が配下に存在するか否かを判断するようにしても良い。
【００９８】
（４）上述した実施形態におけるメッセージの種類は一例であり、同様の機能を果たすメッセージであれば、どのようなメッセージでも良い。また、「トークン割当対象状態」を管理するための方法や、管理のために使用するメーセージの種類についても一例に過ぎず、厳密に「トークン割当対象状態」を管理することができる方法であれば、どのような方法を用いても良い。
【００９９】
（５）上述した実施形態においては、グループ管理テーブルは、マルチキャストグループ毎に作成されるとして説明したが、１つのグループ管理テーブルによって全てのマルチキャストグループを管理してもよい。また、グループ管理テーブルのデータ構成は一例であり、例えば、マルチキャストグループの識別情報としてマルチキャストアドレスのフィールドを設けても良い。
【産業上の利用可能性】
【０１００】
マルチキャストグループ管理に利用することができる。特に、多くのグループメンバが頻繁に移動する通信環境において利用した場合には、グループ管理に必要な通信量を大幅に削減することができる。
【図面の簡単な説明】
【０１０１】
【図１】本発明の実施の形態に係るマルチキャストグループ管理システム１０の構成図である。
【図２】同実施の形態に係るマルチキャストグループ管理システム１０を含むネットワーク構成の一例を示す図である。
【図３】同実施の形態に係るグループ管理テーブルの一例を示す図である。
【図４】同実施の形態に係るグループ管理装置２０の機能構成を示す図である。
【図５】同実施の形態に係るデータ受信端末３０１が最初のグループメンバとしてマルチキャストグループに加入する場合に行われるトークン割当処理の動作手順を示すフローチャートである。
【図６】同実施の形態に係るデータ受信端末３０１が加入要求メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図７】同実施の形態に係るグループ管理装置２０がデータ受信端末３０１に加入応答メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図８】同実施の形態に係るデータ受信端末３０１が加入応答確認メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図９】同実施の形態に係るデータ受信端末３０２が二番目以降のグループメンバとしてマルチキャストグループに加入する場合の動作手順を示すフローチャートである。
【図１０】同実施の形態に係るデータ受信端末３０２が加入要求メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図１１】同実施の形態に係るデータ受信端末３０１がマルチキャストグループから離脱する場合に行われるトークン割当解除処理の動作手順を示すフローチャートである。
【図１２】同実施の形態に係るトークンメンバであるデータ受信端末３０１が離脱要求メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図１３】同実施の形態に係るグループ管理装置２０が離脱要求確認メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図１４】同実施の形態に係るトークン割当解除後のトークン割当処理の動作手順を示すフローチャートである。
【図１５】同実施の形態に係るグループ管理装置２０がデータ受信端末３０２に加入応答メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図１６】同実施の形態に係るデータ受信端末３０２が加入応答確認メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図１７】同実施の形態に係る非トークンメンバであるデータ受信端末３０３がマルチキャストグループから離脱する場合の動作手順を示すフローチャートである。
【図１８】同実施の形態に係る非トークンメンバであるデータ受信端末３０３が離脱要求メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図１９】同実施の形態に係るグループ管理装置２０がトークンメンバであるデータ受信端末３０２に状態確認メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図２０】同実施の形態に係るデータ受信端末３０２が状態確認応答メッセージをグループ管理装置２０に送信したときのグループ管理テーブルの状態を示す図である。
【図２１】同実施の形態に係るグループ管理装置２０が非存在メンバヘトークンを割り当てようとしたときの状態を説明するための図である。
【図２２】同実施の形態に係るグループ管理装置２０が配下のデータ受信端末３０に対して加入者問い合わせメッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図２３】同実施の形態に係るメッセージの種別を説明するための図である。
【符号の説明】
【０１０２】
１０ マルチキャストグループ管理システム
２０ グループ管理装置
２１ トークン割当部
２２ トークンメンバ管理部
２３ トークン割当解除部
２４ マルチキャスト配信データ中継部
３０，３０１，３０２，３０３，３０４ データ受信端末
４０ データ中継装置
５０ データ送信端末
【技術分野】
【０００１】
本発明は、マルチキャストグループを管理するグループ管理装置、及び、マルチキャストグループ管理方法に関する。
【背景技術】
【０００２】
従来のインターネット等を利用したデータ配信は、送信側であるデータ送信端末と受信側であるデータ受信端末との関係から、ユニキャスト配信、ブロードキャスト配信、及び、マルチキャスト配信に分類される。
ユニキャスト配信は、１つのデータ送信端末が１つのデータ受信端末にデータを配信する１対１の通信である。このため、データ送信端末が配信すべきデータ量はデータ受信端末の数に比例して大きくなり、データ受信端末の数が増加すると、データ送信端末や通信路においてデータの配信処理のための負荷が大きくなってしまう。
これに対し、ブロードキャスト配信及びマルチキャスト配信は、１つのデータ送信端末が多数のデータ受信端末にデータを配信する１対多の通信であるため、上記問題は生じない。
【０００３】
ここで、マルチキャスト配信は、ブロードキャスト配信と異なり、一回の操作で特定多数の相手にデータを配信する方式である。マルチキャスト配信の一例としては、ＩＰ（Internet protocol）を用いてマルチキャスト配信を実現するＩＰマルチキャストが広く知られている。ＩＰマルチキャストでは、同一のデータを受信するデータ受信端末のグループにマルチキャスト用のＩＰアドレスを割り当てることで、マルチキャストグループを構成する。このマルチキャストグループに割り当てられるＩＰアドレス（以下「マルチキャストアドレス」という）は当該グループに固有である。データ受信端末は、あるマルチキャストグループ宛に配信されるマルチキャスト配信データの受信を希望する場合、当該マルチキャストグループに所属してグループメンバとなる。具体的には、データ受信端末は、マルチキャストグループへの加入要求を、隣接しているグループ管理装置に送信することにより、当該マルチキャストグループに属するデータ受信端末が配下に存在することを示す情報を記憶させる。これにより、データ受信端末は、データ送信端末から当該マルチキャストグループ宛に配信されるデータを、グループ管理装置等を介して受信することができる。
【０００４】
ここで、上記マルチキャスト配信データを受信するデータ受信端末とグループ管理装置との間のマルチキャストグループ管理用プロトコルとしては、ＩＧＭＰ（Internet Group Management Protocol）が用いられている。このＩＧＭＰに対応したグループ管理装置であるＩＧＭＰルータには、自身の配下にあるデータ受信端末の中にマルチキャストグループに属しているデータ受信端末が存在するか否かを判別する機能が実装されている。
【０００５】
ＩＧＭＰやマルチキャストに関する文献としては、非特許文献１〜３が存在する。ＩＧＭＰは、ＩＧＭＰルータにおいて、データ受信端末を特定しない匿名モデルを採用している。匿名モデルでは、各データ受信端末を一つ一つ管理しないため、その管理コストの低減を図ることが可能であり、結果としてデータ受信端末数が増えた場合のスケーラビリティの確保が可能となる。
【０００６】
このようなＩＰマルチキャストの匿名モデルでは、データ受信端末を特定しないため、ユーザに対する課金やデータ受信者数の測定が不可能であるという問題点があった。そこで、ＩＧＡＰ（IGMP for user Authentication Protocol）を用いてデータ受信端末を使用するユーザの認証を行う技術が提案されている（例えば、非特許文献４参照）。ＩＧＡＰは、データ受信端末が発行するマルチキャストグループへの加入要求メッセージ（IGMP Membership Report）を拡張し、データ受信端末を使用するユーザを認証する。これにより、データ受信端末を使用するユーザを特定することが可能であり、ＩＧＭＰで提供する匿名モデルに対する課題を解決している。
【０００７】
ＩＧＭＰルータでは、最低１台のマルチキャストグループに属しているデータ受信端末（以下「グループメンバ」ともいう）が配下に存在するか否かの状態のみ保持しているため、グループメンバからマルチキャストグループ離脱要求（IGMP Leave Group）を受信した場合に、他のグループメンバが存在するか否かを確認する必要がある。このためにＩＧＭＰルータでは、IGMP Group‐Specific Queryを当該マルチキャストグループ宛にマルチキャストし、さらにそれを受信したデータ受信端末は、その返答（IGMP Membership Report）を返すことによって、他にもグループメンバが存在することをＩＧＭＰルータに伝えている。
【０００８】
以上の動作は、従来のイーサネット（登録商標）等の有線ＬＡＮ（Local Area Network）では問題とならなかったが、データ受信端末が頻繁に移動するような無線ＬＡＮでは問題となる。無線ＬＡＮにおけるデータ受信端末は頻繁に移動を繰り返す傾向にあるため、移動する毎に、移動元と移動先とのサブネットワークのＩＧＭＰルータに対してマルチキャストグループへの加入と離脱とを繰り返す必要があるためである。ＩＧＭＰでは、マルチキャストグループへの離脱を繰り返すたびに上記通信が必要となるため、無線ＬＡＮのようなネットワークではＩＧＭＰは適切ではない。
【０００９】
ＩＧＡＰでは、全てのグループメンバのユーザ認証を行うため、グループ管理装置であるＩＧＡＰルータにおいてグループメンバを厳密に管理することが可能である。こういった特徴を利用し、ＩＧＡＰでは、データ受信端末からのマルチキャストグループ離脱要求メッセージ（IGMP Leave Group）に対して、他にグループメンバが存在しているか否かを確認すること無しに、単に当該データ受信端末の管理情報を削除するFast Leave機能を提供している。これによれば、ＩＧＭＰのように、マルチキャストグループメンバの状況確認のための通信（IGMP Leave Group後のIGMP Group Specific Query）が必要ないなどの利点がある。
【００１０】
しかし、ＩＧＡＰでは、データ受信端末からのマルチキャストグループ加入要求メッセージ（IGMP Membership Report）に対するユーザ認証を実行するために、ユーザに対する課金やデータ受信者数の測定が必要ない場合には、この通信及び処理が冗長になる場合があった。
このように、ＩＧＭＰにおいては、グループメンバが離脱する度に他のグループメンバの状況を確認するための通信を行い、また、ＩＧＡＰにおいては、加入要求メッセージを受信する度にユーザ認証のための通信を行うため、どちらのプロトコルを用いても通信量が増大するという問題点があった。
【００１１】
一方、移動通信ネットワークにおけるマルチキャストグループ管理に関する技術も提案されている（例えば、特許文献１参照）。特許文献１においては、ルータ配下の移動通信端末が、他のルータ配下に移動したり、マルチキャストグループへの加入や離脱を繰り返す毎に、ルータはその旨の情報を受信してグループ管理情報を更新し、移動通信端末毎にグループ管理を行う。このような移動通信端末毎にグループ管理を行う方式では、上述した通信量が増大するという問題点を解決することはできない。
【００１２】
また、データ受信端末がマルチキャスト配信データを受信した後の応答メッセージ数を削減する技術について検討されている文献も存在する（例えば、特許文献２参照）。しかし、特許文献２に記載されている技術は、マルチキャスト配信データに対するデータ受信端末からの応答数を削減する技術であるため、ここで課題としているグループ管理のための通信量の削減に利用することは難しい。
【特許文献１】特開２００１−１７７５６４号公報
【特許文献２】特開２０００−１１５０５１号公報
【非特許文献１】Thomas Maufer著、楠本博之訳、「ＩＰマルチキャスト入門」、初版、共立出版株式会社、２００１年１１月
【非特許文献２】Dave Kosiur著、苅田幸雄監訳、「マスタリングＴＣＰ／ＩＰマルチキャスト編」、第１版、第２刷、平成１２年１１月
【非特許文献３】Beau Williamson著、コムサス訳、シスコシステムズ監訳、「ＩＰマルチキャストネットワーク開発ガイドVol.1」、初版、２００１年７月
【非特許文献４】林経正、他、著「ＩＧＡＰ：IGMP for User Authentication Protocol」、Internet‐draft、２００３年
【発明の開示】
【発明が解決しようとする課題】
【００１３】
以上のように、データ受信端末がマルチキャストグループへの加入と離脱を頻繁に繰り返すような通信環境において、どのようにグループ管理に必要な通信量を抑えるかが問題となる。
本発明は、以上の点を鑑みてなされたものであり、通信量を抑えてマルチキャストグループ管理を行うグループ管理装置、及び、マルチキャストグループ管理方法を提供することを目的とする。
【課題を解決するための手段】
【００１４】
上記課題を解決するために、請求項１に記載の発明は、自装置の配下に存在するデータ受信端末へのマルチキャスト配信データの中継を行うグループ管理装置において、あるマルチキャストグループに属している前記データ受信端末のうち、少なくとも１のデータ受信端末に対してトークンを割り当てるトークン割当手段と、前記トークンが割り当てられたデータ受信端末が、自装置の配下に存在し、かつ、前記あるマルチキャストグループに属している状態であるトークン割当対象状態であるか否かを管理するトークンメンバ管理手段と、前記トークンメンバ管理手段により、前記トークンが割り当てられたデータ受信端末が前記トークン割当対象状態でないことが判明した場合に、該データ受信端末に対するトークンの割当を解除するトークン割当解除手段と、少なくとも１のデータ受信端末に前記トークンが割り当てられている間、前記あるマルチキャストグループに属しているデータ受信端末へのマルチキャスト配信データの中継を行うマルチキャスト配信データ中継手段とを備えることを特徴とするグループ管理装置を提供する。
【００１５】
本発明によれば、前記グループ管理装置のトークン割当手段は、自装置の配下に存在し、かつ、あるマルチキャストグループに属しているデータ受信端末のうち、少なくとも１のデータ受信端末に対してトークンを割り当て、前記トークンメンバ管理手段は、前記トークンが割り当てられたデータ受信端末が前記トークン割当対象状態であるか否かを管理し、前記トークン割当解除手段は、前記トークンが割り当てられたデータ受信端末が前記トークン割当対象状態でないことが判明した場合に、該データ受信端末に対するトークンの割当を解除し、前記マルチキャスト配信データ中継手段は、少なくとも１のデータ受信端末に前記トークンが割り当てられている間、前記あるマルチキャストグループに属しているデータ受信端末へのマルチキャスト配信データの中継を行うため、前記グループ管理装置は、前記トークンが割り当てられたデータ受信端末の状態を管理するための通信量のみでグループ管理を行うことができ、グループ管理のための通信量を抑えることができる。
【００１６】
請求項２に記載の発明は、請求項１に記載のグループ管理装置において、前記トークン割当手段は、前記トークン割当解除手段により割当が解除されたトークンを、他のデータ受信端末に割り当てることを特徴とする。
本発明によれば、前記グループ管理装置のトークン割当手段は、前記トークン割当解除手段により割当が解除されたトークンを他のデータ受信端末に割り当てるため、前記トークンメンバ管理手段は、継続して、新たに前記トークンが割り当てられた前記他のデータ受信端末の状態を管理することができ、配下に前記あるマルチキャストグループに属しているデータ受信端末が存在するか否かを厳密に管理することが可能となる。
【００１７】
請求項３に記載の発明は、請求項１又は２に記載のグループ管理装置において、前記トークン割当手段は、前記データ受信端末が、自装置の配下に継続して存在しており、かつ、前記あるマルチキャストグループに継続して属している時間と、前記データ受信端末が、自装置の配下に存在し、かつ、前記あるマルチキャストグループに属していた過去の累積時間と、前記データ受信端末の機種との少なくとも１に応じて、前記トークンを割り当てるべきデータ受信端末を決定することを特徴とする。
【００１８】
本発明によれば、前記グループ管理装置のトークン割当手段は、前記あるマルチキャストグループに継続して属している時間と前記累積時間と前記機種との少なくとも１に応じて、前記トークンを割り当てるべきデータ受信端末を決定するため、前記あるマルチキャストグループに継続して属している時間や前記累積時間が長いデータ受信端末や、頻繁に移動しない機種のデータ受信端末に対して前記トークンを割り当てることが可能となる。このため、前記グループ管理装置は、加入及び離脱に伴うグループ管理のための通信量や、他のデータ受信端末に前記トークンを再割当するための通信量を削減することができる。
【００１９】
請求項４に記載の発明は、請求項１から３のいずれか１項に記載のグループ管理装置において、前記トークン割当手段は、自装置の配下に存在し、かつ、前記あるマルチキャストグループに属しているデータ受信端末の数と、前記データ受信端末が自装置の配下に継続して存在する平均時間との少なくとも一方に応じて、前記トークンを割り当てるべきデータ受信端末の数を決定することを特徴とする。
【００２０】
本発明によれば、前記グループ管理装置のトークン割当手段は、前記データ受信端末の数と前記平均時間との少なくとも一方に応じて、前記トークンを割り当てるべきデータ受信端末の数を決定するため、前記トークン割当手段は、配下に存在するデータ受信端末の数や移動状況に合わせて、前記トークンを割り当てるべきデータ受信端末の最適な数を決定することができる。このため、前記グループ管理装置は、最適な数のデータ受信端末のみを管理することができるため、通信量を抑えて、マルチキャストグループ管理を行うことができる。
【００２１】
請求項５に記載の発明は、請求項１から４のいずれか１項に記載のグループ管理装置において、前記トークンメンバ管理手段は、前記トークンが割り当てられたデータ受信端末に対してのみ、該データ受信端末より受信したメッセージに対する応答メッセージを返信することを特徴とする。
本発明によれば、前記グループ管理装置のトークンメンバ管理手段は、前記トークンが割り当てられたデータ受信端末に対してのみ、該データ受信端末より受信したメッセージに対する応答メッセージを返信するため、前記トークンが割り当てられたデータ受信端末とのメッセージ授受については、メッセージの欠落が生じないよう正確に管理することができる一方、前記トークンが割り当てられていないデータ受信端末に対しては、応答メッセージの返信を省くことができる。従って、グループ管理装置は、通信量を抑えてマルチキャストグループの管理を行うことができる。
【００２２】
請求項６に記載の発明は、請求項１から５のいずれか１項に記載のグループ管理装置において、前記トークンメンバ管理手段は、前記トークンが割り当てられたデータ受信端末に対してのみ、該データ受信端末が前記トークン割当対象状態であるか否かを確認するためのメッセージを送信することを特徴とする。
本発明によれば、前記グループ管理装置のトークンメンバ管理手段は、前記トークンが割り当てられたデータ受信端末に対してのみ、該データ受信端末が前記トークン割当対象状態であるか否かを確認するためのメッセージを送信するため、前記トークンが割り当てられているデータ受信端末ついては、正確に前記トークン割当対象状態であるか否かを管理する一方、前記トークンが割り当てられていないデータ受信端末に対しては、メッセージの送信を省くことができる。従って、前記グループ管理装置は、通信量を抑えて、マルチキャストグループ管理を行うことができる。
【００２３】
請求項７に記載の発明は、請求項１から６のいずれか１項に記載のグループ管理装置において、前記トークン割当手段は、前記あるマルチキャストグループ宛に問合せメッセージを送信することにより、該あるマルチキャストグループに属していることが確認されたデータ受信端末の中から、前記トークンを割り当てるべきデータ受信端末を決定することを特徴とする。
本発明によれば、前記グループ管理装置のトークン割当手段は、マルチキャストグループに属していることが確認されたデータ受信端末の中から前記トークンを割り当てるべきデータ受信端末を決定するため、自装置の配下に存在しなくなったりマルチキャストグループから離脱したデータ受信端末に対して、前記トークンを割り当てようとして失敗することがなくなるため、不要な通信量を削減することができる。
【００２４】
請求項８に記載の発明は、グループ管理装置が行うマルチキャストのグループ管理方法において、前記グループ管理装置の配下に存在し、かつ、あるマルチキャストグループに属しているデータ受信端末のうち、少なくとも１のデータ受信端末に対してトークンを割り当てるトークン割当ステップと、前記トークンが割り当てられたデータ受信端末の状態が、前記グループ管理装置の配下に存在していない状態と、前記あるマルチキャストグループに属していない状態との少なくとも１の状態であることが判明した場合に、前記データ受信端末に対するトークンの割当を解除するトークン割当解除ステップと、前記トークン割当解除ステップにおいて割当を解除されたトークンを、前記グループ管理装置の配下に存在し、かつ、前記あるマルチキャストグループに属しているデータ受信端末のうち、いずれか１のデータ受信端末に割り当てるトークン再割当ステップとを有し、少なくとも１のデータ受信端末に前記トークンが割り当てられている間、前記あるマルチキャストグループに属しているデータ受信端末へのマルチキャスト配信データの中継を行うことを特徴とするグループ管理方法を提供する。
本発明によれば、前記グループ管理装置は、前記トークンが割り当てられたデータ受信端末の状態を管理するための通信量のみでマルチキャストグループ管理を行うことができ、マルチキャストグループ管理のための通信量を抑えることができる。
【発明の効果】
【００２５】
本発明によれば、グループ管理装置は、自装置の配下に存在し、かつ、あるマルチキャストグループに属しているデータ受信端末のうち、少なくとも１のデータ受信端末に対してトークンを割り当て、該トークンが割り当てられたデータ受信端末が前記トークン割当対象状態であるか否かを管理するため、前記トークンが割り当てられたデータ受信端末の状態を管理するための通信量のみでマルチキャストグループ管理を行うことができ、マルチキャストグループ管理のための通信量を抑えることができる。
【発明を実施するための最良の形態】
【００２６】
次に、図面を参照しながら、本発明の実施の形態について説明する。なお、以下の説明において参照する各図においては、他の図と同等部分に同一符号が付されている。
［１．構成］
図１には、本発明の実施の形態に係るマルチキャストグループ管理システム１０の構成を示す。同図に示すように、マルチキャストグループ管理システム１０は、マルチキャストグループを管理するグループ管理装置２０と、当該グループ管理装置２０の配下に存在する複数のデータ受信端末３０とを含むネットワークで構成される。ここで、「グループ管理装置２０の配下にデータ受信端末３０が存在する」とは、グループ管理装置２０とデータ受信端末３０とが通信可能に接続されており、グループ管理装置２０がデータ受信端末３０に対するデータ配信を中継する状態のことをいう。このようなネットワークの例としてイーサネット（登録商標）や無線ＬＡＮ、移動通信網等が考えられる。グループ管理装置２０は、例えば、ルータであり、この場合には、ルータに管理されるサブネットワーク上のデータ受信端末３０が、ルータの配下に存在するデータ受信端末３０となる。データ受信端末３０は、例えば、移動通信端末やパーソナルコンピュータ（以下「ＰＣ」という）である。なお、以下の説明において、複数のデータ受信端末３０をそれぞれ区別する必要がある場合には、データ受信端末３０１、データ受信端末３０２、データ受信端末３０３、・・・、と記述する。
【００２７】
図２には、マルチキャストグループ管理システム１０と他の関連する装置とを含むネットワーク構成の一例を示す。グループ管理装置２０は、データ配信を中継するデータ中継装置４０と接続されており、グループ管理装置２０自身はデータ中継装置４０の機能も保持している。グループ管理装置２０とデータ中継装置４０とは相互に接続されており、インターネット等のネットワークを形成する。データ送信端末５０は、データ中継装置４０に接続されており、データ中継装置４０を介してネットワークにデータを配信することが可能である。
【００２８】
次に、グループ管理装置２０の構成について詳細に説明する。グループ管理装置２０は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ハードディスク、通信インターフェース、及び、内部時計を含んで構成され、一般的なコンピュータのハードウェア資源を備えている。また、ＲＯＭ、ＲＡＭ及びハードディスクには、データやプログラム等のソフトウェア資源が記憶されている。
【００２９】
グループ管理装置２０のハードディスクに記憶されるソフトウェア資源として、例えば、マルチキャストグループのメンバを管理するためのグループ管理テーブルが存在する。当該グループ管理テーブルは、グループ管理装置２０の配下に存在し、かつ、マルチキャストグループに属しているデータ受信端末３０についての管理情報を管理するためのテーブルである。当該グループ管理テーブルは、マルチキャストグループ毎に作成される。
【００３０】
図３には、グループ管理テーブルの一例を示す。同図に示すように、グループ管理テーブルには、端末フィールドと状態フィールドとトークン情報フィールドと時刻フィールドとが設けられている。端末フィールドには、ＩＰアドレス等の、データ受信端末３０を一意に識別するための情報が記録される。状態フィールドには、データ受信端末３０に対するグループ管理装置２０の状態を示す情報、例えば、授受したメッセージ内容や通信状態を示す情報が記録される。トークン情報フィールドには、本発明で大きな役割を担うトークンがデータ受信端末３０に割り当てられているか否かを示す情報が記録される。時刻フィールドには、これらのフィールドが更新された時刻を示す時刻情報が記録される。以下では、これらのフィールドに記録される「端末」と「状態」と「トークン情報」と「時刻」とを含む情報を「管理情報」という。また、グループ管理テーブルは、図示せぬ、マルチキャストグループを識別するための情報と関連付けられており、この情報によって、グループ管理テーブルが、どのマルチキャストグループを管理するためのテーブルであるかを識別することが可能である。
【００３１】
次に、本発明における「トークン」について説明する。本発明における「トークン」は、グループ管理装置２０の配下に存在し、かつ、あるマルチキャストグループに属しているデータ受信端末３０のうち、少なくとも１のデータ受信端末３０に割り当てられる情報である。トークンが割り当てられたデータ受信端末３０は、マルチキャストグループへの加入状況や、グループ管理装置２０配下からの移動状況等の管理が厳密に行われる。
【００３２】
トークンに含まれる情報としては、トークンを一意に識別するためのＩＤ、トークンが適用されるマルチキャストアドレス、及び、有効期限等が存在する。場合によっては、グループ管理装置２０の電子署名が含まれていても良い。以下では、トークンが割り当てられたデータ受信端末３０を「トークンメンバ」とも呼び、トークンが割り当てられていないデータ受信端末３０を「非トークンメンバ」とも呼ぶ。
【００３３】
また、グループ管理装置２０のハードディスクには、グループ管理テーブルに管理情報を記録するためのプログラムや、トークンをデータ受信端末３０に割り当てるためのプログラムが記憶されている。
これらのハードウェア資源とソフトウェア資源とが協働して動作することにより、図４に示す、トークン割当部２１、トークンメンバ管理部２２、トークン割当解除部２３、及び、マルチキャスト配信データ中継部２４がグループ管理装置２０に実現される。
【００３４】
トークン割当部２１は、あるマルチキャストグループに属している配下のデータ受信端末３０のうち、少なくとも１のデータ受信端末３０に対してトークンを割り当てる。具体的なトークンの割当手順としては、トークン割当部２１は、トークンを割り当てるべきデータ受信端末３０に対して、トークンを含んだ加入応答メッセージ（Join Response）をデータ受信端末３０に送信する。これにより、データ受信端末３０から加入応答確認メッセージ（Join Response ACK）を受信すると、トークン割当部２１は、グループ管理テーブルのトークン情報フィールドに、データ受信端末３０に対してトークンを割り当てたことを示す情報“Ｙｅｓ”を記録する。
【００３５】
また、トークン割当部２１は、トークン割当解除部２３がデータ受信端末３０に対するトークンの割当を解除した場合に、当該割当が解除されたトークンを、他の割当可能なデータ受信端末３０に割り当てる。
また、トークン割当部２１は、トークンを割り当てるべきデータ受信端末３０を決定する機能を有している。トークン割当部２１は、各種情報に基づいて、今後最も長い期間、マルチキャストグループから離脱せず、かつ配下から移動しないと予想されるデータ受信端末３０に対して、トークンを割り当てることに決定する。
【００３６】
具体的な決定方法の例としては、トークン割当部２１は、データ受信端末３０がグループ管理装置２０の配下に存在し続けており、かつ、あるマルチキャストグループに属し続けている「継続時間」に応じて、トークンを割り当てるべきデータ受信端末３０を決定する。例えば、トークン割当部２１は、上記「継続時間」が一番長いデータ受信端末３０に対してトークンを付与する。これは、あるマルチキャストグループに一番長く属していたデータ受信端末３０は、今後も同じ状態が続くと予想されるためである。ここでは、「継続時間」は、グループ管理テーブルの時刻フィールドに記録されている時刻情報を用いて算出される。
【００３７】
また、別の決定方法の例として、トークン割当部２１は、データ受信端末３０がグループ管理装置２０の配下に存在し、かつ、あるマルチキャストグループに属していた過去の「累積時間」に応じて、トークンを割り当てるべきデータ受信端末３０を決定する。「累積時間」の算出方法としては、例えば、グループ管理装置２０は、グループ管理テーブルの更新履歴をハードディスクに記憶しておく。そして、トークン割当部２１は、当該更新履歴に含まれる時刻情報に基づいて、データ受信端末３０があるマルチキャストグループに属していた累積時間をデータ受信端末３０毎に算出する。トークン割当部２１は、算出結果に基づいて、累積時間が最も長いデータ受信端末３０に対してトークンを割り当てることに決定する。
【００３８】
また、別の決定方法の例として、トークン割当部２１は、データ受信端末３０の機種に応じて、トークンを割り当てるべきデータ受信端末３０を決定する。具体的には、グループ管理装置２０は、データ受信端末３０から送信されてきたメッセージに含まれる機種情報をハードディスクに記録しておく。トークン割当部２１は当該機種情報を参照して、最も移動量が少ないと予想される機種のデータ受信端末３０を、トークンを割り当てるべきデータ受信端末３０として決定する。例えば、トークン割当部２１は、携帯電話機よりもＰＣを、また、ノート型ＰＣよりもデスクトップ型ＰＣを、トークンを割り当てるべきデータ受信端末３０に決定する。
【００３９】
また、トークン割当部２１は、マルチキャストグループ毎にトークンを割り当てるべきデータ受信端末３０の数を決定する機能を備えている。決定方法としては、トークン割当部２１は、グループ管理装置２０の配下に存在し、かつ、あるマルチキャストグループに属しているデータ受信端末３０の数に応じて、トークンを割り当てるべきデータ受信端末３０の数を決定する。例えば、トークン割当部２１は、あるマルチキャストグループに属している配下のデータ受信端末３０が所定の数を超えたときには、当該あるマルチキャストグループに対してトークンを割り当てるべきデータ受信端末３０の数を２台に決定する。
【００４０】
また、別の決定方法としては、トークン割当部２１は、データ受信端末３０が、グループ管理装置２０の配下に継続して存在する平均時間に基づき、トークンを割り当てるべきデータ受信端末３０の数を変更しても良い。例えば、平均時間が所定の閾値よりも短い場合には、トークン割当部２１は、配下のネットワーク上に存在するデータ受信端末３０が移動する傾向が強いと判断し、トークンを割り当てるべきデータ受信端末３０の数を増加させても良い。このようにトークンメンバの数を増加させることにより、グループ管理テーブルに記録されているグループメンバと実際配下に存在するグループメンバとの不一致が多く発生した場合にも、グループ管理装置２０が送信したメッセージに対する応答が得られる確率が高くなるため、離脱遅延（Leave Latency）の問題を解消することが可能である。
【００４１】
なお、トークン割当部２１は、場合によっては、配下のあるマルチキャストグループに属しているデータ受信端末３０全てに対してトークンを割り当てても良い。この場合には、グループ管理装置２０とデータ受信端末３０とは１対１の状態管理を行うことになり、厳密なグループメンバの管理が可能である。このような管理方法はグループメンバ数が少ない場合には有効である。しかし、グループメンバ数が増加した場合には、スケーラビリティの問題が発生するため、この場合には逆に与えるトークン数を減少させ、一部のグループメンバのみトークンを与えるというような管理方法をとるのがよい。
【００４２】
トークンメンバ管理部２２は、前記トークン割当部２１によりトークンが割り当てられたデータ受信端末３０が「トークン割当対象状態」であるか否かを管理する。ここで、「トークン割当対象状態」とは、あるマルチキャストグループに対応するトークンが割り当てられたデータ受信端末３０が、継続して、グループ管理装置２０の配下に存在し、かつ、当該あるマルチキャストグループに属している状態をいう。従って、あるマルチキャストグループに対応するトークンが割り当てられたデータ受信端末３０が、グループ管理装置２０の配下に存在しなくなった場合、すなわち、当該データ受信端末３０が、他のグループ管理装置２０の配下に移動したり、電源断となった場合には、当該データ受信端末３０は「トークン割当対象状態」でなくなる。また、当該データ受信端末３０が、あるマルチキャストグループから離脱するために離脱要求メッセージ（Leave Request）をグループ管理装置２０に送信した場合にも、当該データ受信端末３０は「トークン割当対象状態」でなくなる。
【００４３】
トークンメンバ管理部２２による「トークン割当対象状態」の具体的な管理方法としては、以下の方法がある。トークンメンバ管理部２２は、トークンが割り当てられたデータ受信端末３０に対してのみ、受信したメッセージに対する応答メッセージを返信し、メッセージの欠落が生じないように管理する。データ受信端末３０から受信するメッセージには、例えば、加入要求メッセージ（Join Request）や離脱要求メッセージ（Leave Request）がある。なお、「トークンが割り当てられたデータ受信端末３０」には、トークン割当対象に決定されたデータ受信端末３０も含まれる。また、他の管理方法としては、トークンメンバ管理部２２は、トークンが割り当てられたデータ受信端末３０に対してのみ、状態を確認するための状態確認メッセージ（Hello）を送信する。
【００４４】
トークンメンバ管理部２２は、以上のようなメッセージの授受により、トークンが割り当てられているデータ受信端末３０が「トークン割当対象状態」であるか否かを厳密に管理する。
トークン割当解除部２３は、トークンメンバ管理部２２による管理によって、トークンが割り当てられているデータ受信端末３０が「トークン割当対象状態」でないことが判明した場合に、当該データ受信端末３０に対するトークンの割当を解除する。具体的な割当解除方法としては、トークン割当解除部２３は、グループ管理テーブルのデータ受信端末３０に対するトークン情報フィールドを“Ｎｏ”に更新する。
【００４５】
マルチキャスト配信データ中継部２４は、少なくとも１のデータ受信端末３０にトークンが割り当てられている間、当該トークンに対応するマルチキャストグループに属しているデータ受信端末３０へのマルチキャスト配信データの中継を行う。少なくとも１のデータ受信端末３０に、あるマルチキャストグループに対応するトークンが割り当てられているか否かの判断は、あるマルチキャストグループのグループ管理テーブルのトークン状態フィールドに“Ｙｅｓ”が記述されている管理情報が存在するか否かによって判断される。
【００４６】
［２．動作］
以下では、マルチキャストグループ管理システム１０におけるマルチキャストグループ管理方法について、図を用いて説明する。
本発明に係るマルチキャストグループ管理方法においては、グループ管理装置２０の配下に存在するデータ受信端末３０の中に、あるマルチキャストグループ宛に配信されるマルチキャスト配信データの受信を所望するデータ受信端末３０が存在するか否かを管理する方法を提供する。
【００４７】
（最初のグループメンバ加入時のトークン割当処理）
図５〜図８は、データ受信端末３０１が最初のグループメンバとして、あるマルチキャストグループ（ここでは、「マルチキャストグループＡ」とする）に加入する場合に行われるトークン割当処理の動作手順を説明する図である。
データ受信端末３０１が最初のグループメンバであるため、本手順を実行する時点においては、グループ管理装置２０のハードディスクには、マルチキャストグループＡのグループ管理テーブルは作成されていない。また、ここでは、グループ管理装置２０配下のマルチキャストグループＡのメンバに対して、１つのトークンが割り当てられるものとする。
【００４８】
まず、データ受信端末３０１は、加入要求メッセージ（Join Request）をグループ管理装置２０に対して送信することで、マルチキャストグループＡ宛に配信されるデータの受信を所望することを伝える（図５及び図６のステップＳ１）。
Join Requestを受信したグループ管理装置２０は、ハードディスクにマルチキャストグループＡのグループ管理テーブルが存在するか否かを確認する。ここでは、マルチキャストグループＡのグループ管理テーブルが存在しないことから、グループ管理装置２０は、データ受信端末３０１が当該マルチキャストグループＡにおける最初のグループメンバとなることが分かる。そして、グループ管理装置２０は、当該マルチキャストグループＡのグループ管理テーブルを作成する（図５のステップＳ２）。
【００４９】
同時に、グループ管理装置２０のマルチキャスト配信データ中継部２４は、当該マルチキャストグループＡ宛のマルチキャスト配信データを中継するために、ＰＩＭ（Protocol Independent Multicast）等のマルチキャストルーティングプロトコルを用いてマルチキャスト配信経路を構築する（図５のステップＳ３）。そして、マルチキャスト配信データ中継部２４は、マルチキャストグループＡに属するデータ受信端末３０１に対してマルチキャスト配信データの中継を行う。これによって、データ受信端末３０１は、当該マルチキャスト配信データの受信が可能となる。
【００５０】
グループ管理装置２０は、Join Requestを受信すると、グループ管理テーブルにデータ受信端末３０１の管理情報を記述するための領域を作成する。そして、グループ管理装置２０は、作成した領域の端末フィールドにデータ受信端末３０１を識別するための情報“３０１”を記録し、状態フィールドにJoin Requestを受信したことを示す情報“Join Received”を記録し、トークン情報フィールドに“Ｎｏ”を記録し、時刻フィールドにJoin Requestを受信した時刻“１１：３０”を記録する（図５及び図６のステップＳ４）。
【００５１】
ここで、グループ管理装置２０のトークン割当部２１は、マルチキャストグループＡのグループメンバに少なくとも１のトークンを割り当てる必要があるが、現在マルチキャストグループＡの最初のグループメンバとなるデータ受信端末３０１からのJoin Requestを受信しているため、データ受信端末３０１にトークンを割り当てることに決定する。そして、トークン割当部２１は、トークンを一意に識別するためのトークンＩＤと、マルチキャストグループＡを識別するためのマルチキャストアドレスとを含むトークンを生成する。
【００５２】
トークンメンバ管理部２２は、データ受信端末３０１に対して、生成したトークンを含む加入応答メッセージ（Join Response）を返す（図５及び図７のステップＳ５）。次いで、トークンメンバ管理部２２は、グループ管理テーブルの状態フィールドに、Join Responseを送信したことを示す情報“Join Response Sent”を記録する（図５及び図７のステップＳ６）。
Join Requestを受信したデータ受信端末３０１は、加入応答確認メッセージ（Join Response ACK）を返す（図５及び図８のステップＳ７）。
【００５３】
Join Response ACKを受信したグループ管理装置２０のトークンメンバ管理部２２は、グループ管理テーブルの状態フィールドに、Join Response ACKが届いたことを示す情報“Connected”を記録する。さらに、トークンメンバ管理部２２は、トークンが無事にデータ受信端末３０１に届いたことが確認できたため、トークン情報フィールドに“Ｙｅｓ”を記録する（図５及び図８のステップＳ８）。
以上の動作により、グループ管理装置２０は、マルチキャストグループＡの最初のグループメンバであるデータ受信端末３０１に対してのトークンの割当と、その確認応答とを完了することが出来る。
【００５４】
（二番目以降のグループメンバの加入）
次に、図９及び図１０を参照して、データ受信端末３０２が二番目以降のグループメンバとしてマルチキャストグループＡに加入する時の動作手順を説明する。
データ受信端末３０２は、データ受信端末３０１と同様に、加入要求メッセージ（Join Request）をグループ管理装置２０に対して送信することで、マルチキャストグループＡ宛に配信されるマルチキャスト配信データの受信を所望することを伝える（図９及び図１０のステップＳ１１）。本手順は最初のグループメンバ加入時と同様である。
【００５５】
Join Requestを受信したグループ管理装置２０は、マルチキャストグループＡを管理するためのグループ管理テーブルが既に作成されているか否かを確認する。ここでは、グループ管理装置２０のハードディスクに、マルチキャストグループＡのグループ管理テーブルが既に作成されており、当該グループ管理テーブルに、データ受信端末３０１に関する管理情報が記録されていることから、データ受信端末３０２がマルチキャストグループＡにおける二番目以降のグループメンバであることが分かる。グループ管理装置２０は、マルチキャストグループＡのグループ管理テーブルに、データ受信端末３０２の管理情報を追加する。具体的には、グループ管理装置２０は、グループ管理テーブルにデータ受信端末３０２の管理情報を記録するための領域を作成する。そして、グループ管理装置２０は、作成した領域の端末フィールドに、データ受信端末３０２を識別するための情報“３０２”を記録し、状態フィールドに“Join Received”を記録し、トークン情報フィールドに“Ｎｏ”を記録し、時刻フィールドに、Join Requestを受信した時刻“１１：３４”を記録する（図９及び図１０のステップＳ１２）。
【００５６】
グループ管理装置２０は、二番目以降のグループメンバからJoin Requestを受信した場合には、二番目以降のグループメンバにトークンを割り当てる必要がないため、ここで処理を終了する。
データ受信端末３０２は、データ受信端末３０１がすでにマルチキャストグループＡのメンバであることから、Join Request送出時点からマルチキャスト配信データを受信することが出来る。
【００５７】
（トークンメンバ離脱時のトークン割当解除処理）
図１１〜図１６は、トークンメンバであるデータ受信端末３０１が、マルチキャストグループＡ宛のマルチキャスト配信データの受信を希望しない場合や、グループ管理装置２０の配下から移動する場合に、マルチキャストグループＡから離脱する際のトークン割当解除処理の動作手順を示す図である。なお、ここでは、マルチキャストグループＡのグループ管理テーブルに、データ受信端末３０３やデータ受信端末３０４についてもグループメンバとして記録されている状態から説明を開始する。
データ受信端末３０１は、離脱要求メッセージ（Leave Request）をグループ管理装置２０に対して送信することで、マルチキャストグループＡからの離脱を所望することを伝える（図１１及び図１２のステップＳ２１）。このLeave Requestには、データ受信端末３０１が開放するトークンに関する情報を含む。
【００５８】
Leave Requestを受信したグループ管理装置２０のトークンメンバ管理部２２は、グループ管理テーブルを参照して、データ受信端末３０１に対するトークン情報フィールドに“Ｙｅｓ”が記録されていることから、トークンメンバであるデータ受信端末３０１からのLeave Requestであると判断する。そして、トークンメンバ管理部２２は、グループ管理テーブルのデータ受信端末３０１に対する状態フィールドを、データ受信端末３０１からLeave Requestを受信したことを示す情報“Leave Request Received”で更新する。さらに、トークンメンバ管理部２２は、受信したトークンに関する情報が正しい情報であるかどうかを判断する。例えば、トークンメンバ管理部２２は、一般的な改ざんチェックや送信元の正当性チェックを行う。例えば、トークンの改ざんチェックの方法の一例として、鍵付きハッシュ関数を用いて生成したメッセージ認証コードを、トークンとして用いたり、トークンの付属情報として付加する方法がある。判断の結果、正しいトークンであると判断すると、トークンメンバ管理部２２は、データ受信端末３０１が「トークン割当対象状態」でなくなったと判断する。
【００５９】
これにより、トークン割当解除部２３は、データ受信端末３０１のトークン情報フィールドを“Ｎｏ”に変更することにより、トークンが返却された、すなわち、当該データ受信端末３０１に対するトークンの割当が解除されたことを記録する（図１１及び図１２のステップＳ２２）。
その後、グループ管理装置２０のトークンメンバ管理部２２は、当該データ受信端末３０１に対して離脱要求確認メッセージ（Leave Request ACK）を返す（図１１及び図１３のステップＳ２３）。そして、グループ管理装置２０のトークンメンバ管理部２２は、グループ管理テーブルに記録されているデータ受信端末３０１に関する管理情報を削除する（図１１及び図１３のステップＳ２４）。
以上の手順によりトークンメンバであるデータ受信端末３０１のマルチキャストグループＡからの離脱が完了する。
【００６０】
＜他端末へのトークンの付与＞
ここでトークンは、マルチキャストグループメンバの中で最低１台のデータ受信端末３０に割り当てられるという特徴を持つものであるため、グループ管理装置２０のトークン割当部２１は、データ受信端末３０１に割り当てられていたトークンを、別のデータ受信端末３０に対して割り当てる必要がある。
そこで、マルチキャストグループＡのグループ管理テーブルに、グループメンバとして記録されているデータ受信端末３０が存在する場合には（図１４のステップＳ３１；Ｙｅｓ）、グループ管理装置２０のトークン割当部２１は、グループ管理テーブルから、最も過去の時刻情報を含む管理情報を検索し、当該検索された管理情報に対するデータ受信端末３０を、次のトークンメンバとして選出する（図１４のステップＳ３３）。
【００６１】
なお、グループ管理テーブルに他のデータ受信端末３０が記録されていない場合には（図１４のステップＳ３１；Ｎｏ）、この時点でマルチキャストグループＡのグループメンバが配下に存在しないことになる。このため、トークンメンバ管理部２２は、当該グループ管理テーブル自体をハードディスクから削除する。これにより、マルチキャスト配信データ中継部２４は、マルチキャストグループＡに対する配信データの中継を停止する（図１４のステップＳ３２）。
【００６２】
ここでは、図１５に示すように、グループ管理テーブルにグループメンバとして記録されているデータ受信端末３０が存在し（図１４のステップＳ３１；Ｙｅｓ）、グループ管理テーブルの時刻フィールドに記録されている時刻情報から、データ受信端末３０２が一番長い時間、配下でマルチキャストグループＡにグループメンバとして属していることが判る。このため、トークン割当部２１は、データ受信端末３０２を次のトークンメンバとして選出することになる（図１４のステップＳ３３）。
【００６３】
次に、次のトークンメンバとして選出されたデータ受信端末３０２へのトークンの割当処理について説明する。グループ管理装置２０のトークン割当部２１は、次のトークンメンバとなるべきデータ受信端末３０２に対して、トークンを含んだ加入応答メッセージ（Join Response）を返す（図１４及び図１５のステップＳ３４）。また、グループ管理装置２０のトークンメンバ管理部２２は、グループ管理テーブルのデータ受信端末３０２に対する状態フィールドに、Join Responseを送信したことを示す情報として“Join Response Sent”を記録する（図１４及び図１５のステップＳ３５）。
【００６４】
Join Responseを受信したデータ受信端末３０２は、加入応答確認メッセージ（Join Response ACK）を返す（図１４及び図１６のステップＳ３６）。
Join Response ACKを受信したグループ管理装置２０のトークンメンバ管理部２２は、グループ管理テーブルのデータ受信端末３０２に対する状態フィールドに、加入応答確認が完了したことを示す情報として“Connected”を記録する。さらに、Join Response ACKにより、トークンが無事にデータ受信端末３０２に届いたことを確認できたため、トークン割当部２１は、データ受信端末３０２に対するトークン情報フィールドに“Ｙｅｓ”を記録する（図１４及び図１６のステップＳ３７）。
【００６５】
以上の動作によって、トークン割当解除部２３によりトークンメンバであるデータ受信端末３０１に対するトークンの割当が解除された場合に、グループ管理装置２０のトークン割当部２１は、次のトークンメンバとなるべきデータ受信端末３０２に対してトークンを割り当てることができる。
【００６６】
（非トークンメンバの離脱）
図１７及び図１８は、非トークンメンバであるデータ受信端末３０３がマルチキャストグループＡから離脱する場合の動作手順を説明したものである。
本手順を開始する時点においては、グループ管理テーブルには図１６に示す管理情報が記録されているものとする。
まず、データ受信端末３０３は、離脱要求メッセージ（Leave Request）をグループ管理装置２０に対して送信することで、マルチキャストグループＡのグループメンバに配信されるデータの受信停止を所望することを伝える（図１７及び図１８のステップＳ４１）。
【００６７】
Leave Requestを受信したグループ管理装置２０は、図１６のグループ管理テーブルに示すように、データ受信端末３０３に対するトークン情報フィールドに“Ｎｏ”が記録されていることから、非トークンメンバであるデータ受信端末３０３からのLeave Requestであると判断する。そして、グループ管理装置２０は、グループ管理テーブルから、データ受信端末３０３に関する管理情報を削除する（図１７及び図１８のステップＳ４２）。以上の動作により、非トークンメンバの離脱手順が完了する。
【００６８】
（トークンメンバのKeep Alive）
以上説明したように、グループ管理装置２０のトークン割当部２１は、配下に存在するマルチキャストのグループメンバを、トークンメンバと非トークンメンバに分ける。そして、トークンメンバ管理部２２は、トークンメンバに関しては各メッセージのやり取りに対して確認応答を行い、厳密なメンバシップ管理を行う。これにより、トークンメンバ管理部２２は、トークンメンバが「トークン割当対象状態」であることを厳密に管理する。一方、非トークンメンバに関してはメッセージのやり取りを最小限に抑えて厳密な管理を行わないことで、グループ管理装置２０におけるスケーラビリティを確保しようとするのが本発明の特徴である。
【００６９】
従って、グループ管理装置２０のトークンメンバ管理部２２は、トークンメンバに対しては、確認応答を行う以外にも、定期的に状況確認を行い、トークンメンバが配下においてそのマルチキャストグループに属しているか否か、すなわち、トークンメンバが「トークン割当対象状態」であるか否かを厳密に管理する必要がある。
図１９及び図２０を参照しながら、トークンメンバが「トークン割当対象状態」であることを確認するためのKeep Alive手順について説明する。
【００７０】
図１９では、グループ管理装置２０のトークンメンバ管理部２２が、トークンメンバに対して、定期的に状態確認メッセージ（Hello）を送信する（図１９のステップＳ５１）。Helloは、決められたタイマに従って、トークンメンバに対して送信される。
Helloを受信したトークンメンバであるデータ受信端末３０２は、Helloの応答として状態確認応答メッセージ（Hello ACK）を返す（図２０のステップＳ５２）。
以上の動作により、グループ管理装置２０のトークンメンバ管理部２２は、トークンメンバであるデータ受信端末３０２が「トークン割当対象状態」であることを確認することができる。
【００７１】
グループ管理装置２０のトークンメンバ管理部２２は、トークンメンバにHelloを送信したものの、一定のタイムアウト時間を待ってもその応答が無い場合には、当該トークンメンバが「トークン割当対象状態」でなくなったと判断する。これにより、トークン割当解除部２３は、トークンメンバに対するトークンの割当を解除する。具体的には、トークン割当解除部２３は、トークンメンバの管理情報をグループ管理テーブルより削除する。次いで、トークン割当部２１は、トークンの割当が解除されたのを検知して、図１４に示す手順に従い、配下に存在する他のグループメンバに対するトークン割当処理を行う。これにより、トークン割当部２１は、配下のサブネットワーク上にトークンメンバが最低一台存在するように制御することとなる。
【００７２】
（非トークンメンバの突然の離脱）
非トークンメンバについては、Join RequestもしくはLeave Requestに対する確認応答を行わず、さらにKeep Aliveによる状態確認を行わないため、グループ管理装置２０のグループ管理テーブルで管理されるデータ受信端末３０の加入状況と、実際のデータ受信端末３０の加入状況とが一致しない場合がしばしば発生する。
例えば、データ受信端末３０が頻繁に移動する無線ＬＡＮのようなモバイルネットワークにおいては、非トークンメンバであるデータ受信端末３０が、Leave Requestを送信すること無しに、他のグループ管理装置２０の配下に移動してしまうことが当然発生する。また、データ受信端末３０が突然電源断となった場合なども考えられる。その際には、グループ管理装置２０は、自身が保持するグループ管理テーブルで管理される加入状況と、実際の加入状況が一致しないという状態が発生する。このような状態が問題となる場合として、図１４に示すような、非トークンメンバがトークンを割り当てられてトークンメンバに変化する例が存在する。
【００７３】
図１４及び図１５のステップＳ３４において、グループ管理装置２０がJoin Responseを送信した時に、データ受信端末３０２がすでに存在しない場合の動作手順を、図２１を参照して説明する。
図２１には、データ受信端末３０２が電源断や移動により、Leave Requestを出すこと無しに不在になった状況を示している。このような場合には、グループ管理装置２０のトークンメンバ管理部２２は、Join Responseを出すものの、それに対する応答（リプライ）が無いために、当該データ受信端末３０２が「トークン割当対象状態」でないものと判断する。そして、トークン割当解除部２３は、グループ管理テーブルから、データ受信端末３０２に関する管理情報を削除する。
その後、グループ管理装置２０のトークン割当部２１は、他のデータ受信端末３０に対してトークンを与えるための手順を行うために、図１４に示す他端末へのトークンの割当手順を実行する。
【００７４】
（Membership Query）
非トークンメンバの突然の離脱が多くのデータ受信端末３０に渡ると、図２１で説明したような、Join Responseに対するリプライを返信しないデータ受信端末３０が多数存在することになる。このような場合には、グループ管理装置２０のトークン割当部２１は、トークンをデータ受信端末３０に対して割り当てるために、連続してJoin Responseをデータ受信端末３０に対して送信する場合がある。
【００７５】
具体的な例として、グループ管理装置２０が、グループ管理テーブルに記録されている管理情報に基づいて、配下にグループメンバが多数存在すると把握していたとしても、グループメンバの電源断や移動等の理由で、自装置２０の配下に存在すると把握していた全てのグループメンバが実際には存在しない場合も考えられる。このような場合には、グループ管理装置２０のトークン割当部２１は、グループ管理テーブルにグループメンバとして記録されている全てのデータ受信端末３０に対して順にトークンを与えようとし、さらにそのリプライを待ち続けるという状況が発生する。このような例においては、グループ管理装置２０はマルチキャスト配信データの中継が必要ない場合にも当該データの中継を続けてしまうという離脱遅延（Leave Latency）の問題が発生し、結果としてネットワークの利用効率を著しく低下させる原因となる。
【００７６】
以上のことから、グループ管理装置２０のトークン割当部２１は、Join Responseの代わりに加入者問い合わせメッセージ（Membership Query）をネットワーク全体にマルチキャスト配信しても良い。
図２２は、グループ管理装置２０がMembership Queryを用いて、マルチキャストグループメンバの確認を行った場合の例を示す。データ受信端末３０は、Membership Queryを受信すると、グループ管理装置２０から指定された最大応答時間（Max Response Time）の範囲内でタイマを起動し、そのタイマが満了した場合には、グループ管理装置２０に対してJoin Requestを改めて送信する。
【００７７】
これにより、グループ管理装置２０は、どのデータ受信端末３０がグループメンバとして存在しているか否かを確認することが可能となる。このように、トークン割当部２１は、グループ管理テーブルで管理されているグループメンバの加入状況と実際の加入状況とを一致させるために、Membership Queryを用いることができる。
グループ管理装置２０のトークン割当部２１は、Join Responseを個々のデータ受信端末３０に送信する代わりにMembership Queryを使用するか否かを決定することが出来る。例えば、Join Responseに対するタイムアウトがある決められた値回数以上発生した場合に、グループ管理テーブルで管理されているグループメンバの加入状況と実際の加入状況とが一致していない可能性が高いと考えられるため、トークン割当部２１はMembership Queryを使用するという決定方法が考えられる。
【００７８】
グループ管理装置２０は、定期的にMembership Queryを用いて、配下のデータ受信端末３０の加入状況確認を行っても良い。例えば、無線ＬＡＮ等のデータ受信端末３０が頻繁に移動するネットワークで用いられるグループ管理装置２０の場合、Membership Query発行の時間間隔を短くするなどの工夫が考えられる。
【００７９】
（メッセージの欠落による状態不一致）
トークンメンバであるデータ受信端末３０とグループ管理装置２０とのメッセージのやり取りは、マルチキャストグループ加入の際に、Join Request→Join Response→Join Response ACK、マルチキャストグループ離脱の際に、Leave Request→Leave Request ACKの構成となっており、いずれかのメッセージが欠落した場合には再送により対処することが出来る。
【００８０】
例えば、マルチキャストグループへの加入の際に、Join Responseが何らかの原因で欠落した場合には、グループ管理装置２０のトークンメンバ管理部２２は、Join Response ACKが戻ってこないことによりその状況を把握する。そしてグループ管理装置２０のトークンメンバ管理部２２は、Join Responseを再送することによりメッセージの欠落に対処する。Join Response ACKが欠落した場合にも同様である。
【００８１】
同様に、Leave RequestやLeave Request ACKの欠落に対しても、データ受信端末３０は、Leave Request に対するLeave Request ACKが届かないことにより、データの欠落を検出することができる。データの欠落を検出したデータ受信端末３０は、Leave Requestを再送することでメッセージの欠落に対処することが可能である、
ただし、非トークンメンバの場合には、非トークンメンバが送信したJoin RequestとLeave Requestとのいずれに対してもグループ管理装置２０から応答が無いため、それらのメッセージが欠落したとしても、欠落していることを検出することが出来ない場合がある。
【００８２】
例えば、最初にあるマルチキャストグループに加入するためのJoin Requestを発行したトークンメンバとなるべきデータ受信端末３０のJoin Requestが欠落した場合には、データ受信端末３０はマルチキャスト配信データの配信を受けることができないため、データ受信端末３０はJoin Requestを再送するための判断をすることが可能である。
【００８３】
一方、非トークンメンバが送信したJoin Requestが欠落した場合には、そのメッセージが実際にグループ管理装置２０に届いていないにもかかわらず、非トークンメンバはマルチキャスト配信データを受信することは可能であるため、グループ管理テーブルで管理されているグループメンバの加入状況と実際の加入状況との不一致が発生する。このような場合、データ受信端末３０は、実際にはグループメンバであるのにもかかわらずグループ管理装置２０には認識されないという状況が発生するため、他のグループメンバの離脱によって突然マルチキャスト配信データの中継が停止されてしまうことも考えられる。このような場合には、データ受信端末３０は、マルチキャスト配信データの受信が終了してしまったことで何らかの異常が発生したと判断し、Join Requestを改めて送信するなどの対処が必要である。
【００８４】
グループ管理装置２０は、以上のような状況が発生することを鑑み、最後のグループメンバが離脱したと判断したときには、データの中継を停止する前にMembership Queryを用いて残存しているグループメンバが存在するか否かを問い合わせても良い。このようにすれば、グループ管理装置２０は、非トークンメンバヘのマルチキャストデータの中継を停止してしまうということが無くなる。
【００８５】
（非グループメンバのメッセージの受信）
グループ管理装置２０のグループ管理テーブルで管理されているグループ加入状況と実際のデータ受信端末３０のグループ加入状況とが不一致である場合に、データ受信端末３０は、あるマルチキャストグループのメンバで無いのに、Join Response、Hello、或いは、Membership Queryを受信することがある。
【００８６】
このような場合、データ受信端末３０が当該メッセージを無視することによって、結果的にグループ管理装置２０は当該データ受信端末３０が存在しないと判断するため、グループ管理テーブルで管理されているグループ加入状況を実際のグループ加入状況に一致させることが出来る。しかし、無視することによってグループ管理装置２０のタイムアウトを発生させる方法では、グループ管理装置２０がメッセージを送信してからグループ管理テーブルを更新するまでのタイムラグが生じる。
従って、データ受信端末３０は、あるマルチキャストグループのメンバで無いのに、そのグループに対するJoin Response、Hello、又は、Membership Queryを受信した場合には、それに対する否定応答（NACK）を返しても良い。NACKを返すことによって、グループ管理装置２０はいち早く不一致を把握することが可能である。
【００８７】
（各メッセージの宛先アドレス）
図２３は、以上に説明した各メッセージの一覧をまとめたものである。
Join Requestは、データ受信端末３０からグループ管理装置２０に対して送信するものであるため、グループ管理装置２０のユニキャストアドレスがその宛先となる。もしくは、グループ管理装置２０群あてのマルチキャストグループアドレスをあらかじめ割り当て、それを宛先アドレスとしても良い。もしくはグループ管理装置２０用に割り当てられたエニイキャストアドレスがある場合には、それを宛先アドレスにしても良い。
【００８８】
Join Responseは、グループ管理装置２０からデータ受信端末３０に対して送信するものであり、データ受信端末３０のユニキャストアドレスがその宛先アドレスに用いられる。
Join Response ACKは、データ受信端末３０からグループ管理装置２０に対して送信するものであり、Join Responseと同様に３種類の宛先アドレスの設定方法が存在する。
【００８９】
Leave Requestは、データ受信端末３０からグループ管理装置２０に対して送信するものであるため、グループ管理装置２０のユニキャストアドレスがその宛先となる。もしくは、グループ管理装置２０群あてのマルチキャストグループアドレスをあらかじめ割り当て、それを宛先アドレスとしても良い。もしくはグループ管理装置２０用に割り当てられたエニイキャストアドレスがある場合には、それを宛先アドレスにしても良い。
【００９０】
Leave Request ACKは、グループ管理装置２０からデータ受信端末３０に対して送信するものであり、データ受信端末３０のユニキャストアドレスがその宛先アドレスに用いられる。
Membership Queryに関しては、グループ管理装置２０から当該マルチキャストグループのメンバであるデータ受信端末３０に対して送信されるメッセージであるため、当該マルチキャストアドレスがその宛先に用いられる。
【００９１】
Helloに関しては、グループ管理装置２０からデータ受信端末３０に対して送信されるものであるため、データ受信端末３０のユニキャストアドレスがその宛先アドレスに用いられる。
但し、前に説明するようにトークンメンバは複数存在することも考えられるので、トークンメンバ全てに対してHelloメッセージをするために、トークンメンバ用マルチキャストグループを宛先としても良い。
【００９２】
Hello ACKに関しては、データ受信端末３０からグループ管理装置２０に対して送信するものであるため、グループ管理装置２０のユニキャストアドレスがその宛先となる。もしくは、グループ管理装置２０群あてのマルチキャストグループアドレスをあらかじめ割り当て、それを宛先アドレスとしても良い。もしくはグループ管理装置２０用に割り当てられたエニイキャストアドレスがある場合には、それを宛先アドレスにしても良い。
【００９３】
（まとめ）
以上説明したように、グループ管理装置２０は、トークンが割り当てられたデータ受信端末３０のみを厳密に管理することによって、グループ管理のための通信量を抑えることができる。また、グループ管理装置２０は、トークンが割り当てられたデータ受信端末３０を厳密に管理することにより、少なくとも１のデータ受信端末３０にトークンが割り当てられているか否かによって、マルチキャストグループに属しているデータ受信端末３０が配下に存在しているか否かを判断することができる。このため、従来のように、配下にグループメンバが存在しているか否かを確認するためのメッセージを送信する必要がなくなる。このように、本発明によって、通信量を抑えたマルチキャストグループ管理を行うことが可能となる。
【００９４】
また、無線ＬＡＮ等のモバイル環境においては、データ受信端末３０は頻繁に移動し、グループ管理装置２０配下のマルチキャストグループに属している期間は通常短くなるものと考えられる。このため、頻繁に移動するデータ受信端末３０に対しては、トークンを割り当てないことによって、厳密な管理を行わないようにする。その一方、移動が少なくマルチキャストグループに属している期間が長い一部のデータ受信端末３０に対しては、トークンを割り当てて厳密に管理する。このようなグループ管理を行うことで、データ受信端末３０の移動に伴い発生する加入、離脱による余計な通信が発生しないようにすることが可能となる。
【００９５】
［３．変形例］
以上、本発明の実施形態について説明したが、本発明は係る実施形態に限定されるものではなく、その技術思想の範囲内で様々な変形が可能である。変形例としては、例えば、以下のようなものが考えられる。
（１）上述した実施形態におけるトークン割当部２１によるトークン割当の方法としては、トークン割当部２１が、トークンに関する情報を含んだJoin Responseをデータ受信端末３０に送信することによって、データ受信端末３０にトークンを記憶させるようにしたが、これに限定されることはない。例えば、トークンに関する情報を含まないJoin Responseをデータ受信端末３０に送信し、データ受信端末３０に対してトークンを割り当てた旨の情報をグループ管理テーブルに記録しておくだけでもよい。
【００９６】
（２）上述した実施形態においては、トークンは、基本的に、あるマルチキャストグループに最初に加入したデータ受信端末３０に対して与えられるとして説明したが、これに限定されることはない。例えば、１秒差で、グループメンバが存在していない同一のマルチキャストグループへの加入要求を、２つのデータ受信端末３０より受信した場合には、トークン割当部２１は、例えば、データ受信端末３０の機種によって、どちらのデータ受信端末３０にトークンを割り当てるかを決定するようにしてもよい。
【００９７】
（３）上述した実施形態においては、データ受信端末３０は、グループ管理装置２０の配下から移動する時に、基本的に離脱要求メッセージ（Leave Request）を送信することを前提として説明したが、これに限定されることはない。データ受信端末３０がグループ管理装置２０の配下から移動する時に、離脱要求メッセージ（Leave Request）を送信しない場合には、グループ管理装置２０は、加入者問い合わせメッセージ（Membership Query）を送信したり、または、データ受信端末３０の位置情報を受信して、データ受信端末３０が配下に存在するか否かを判断するようにしても良い。
【００９８】
（４）上述した実施形態におけるメッセージの種類は一例であり、同様の機能を果たすメッセージであれば、どのようなメッセージでも良い。また、「トークン割当対象状態」を管理するための方法や、管理のために使用するメーセージの種類についても一例に過ぎず、厳密に「トークン割当対象状態」を管理することができる方法であれば、どのような方法を用いても良い。
【００９９】
（５）上述した実施形態においては、グループ管理テーブルは、マルチキャストグループ毎に作成されるとして説明したが、１つのグループ管理テーブルによって全てのマルチキャストグループを管理してもよい。また、グループ管理テーブルのデータ構成は一例であり、例えば、マルチキャストグループの識別情報としてマルチキャストアドレスのフィールドを設けても良い。
【産業上の利用可能性】
【０１００】
マルチキャストグループ管理に利用することができる。特に、多くのグループメンバが頻繁に移動する通信環境において利用した場合には、グループ管理に必要な通信量を大幅に削減することができる。
【図面の簡単な説明】
【０１０１】
【図１】本発明の実施の形態に係るマルチキャストグループ管理システム１０の構成図である。
【図２】同実施の形態に係るマルチキャストグループ管理システム１０を含むネットワーク構成の一例を示す図である。
【図３】同実施の形態に係るグループ管理テーブルの一例を示す図である。
【図４】同実施の形態に係るグループ管理装置２０の機能構成を示す図である。
【図５】同実施の形態に係るデータ受信端末３０１が最初のグループメンバとしてマルチキャストグループに加入する場合に行われるトークン割当処理の動作手順を示すフローチャートである。
【図６】同実施の形態に係るデータ受信端末３０１が加入要求メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図７】同実施の形態に係るグループ管理装置２０がデータ受信端末３０１に加入応答メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図８】同実施の形態に係るデータ受信端末３０１が加入応答確認メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図９】同実施の形態に係るデータ受信端末３０２が二番目以降のグループメンバとしてマルチキャストグループに加入する場合の動作手順を示すフローチャートである。
【図１０】同実施の形態に係るデータ受信端末３０２が加入要求メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図１１】同実施の形態に係るデータ受信端末３０１がマルチキャストグループから離脱する場合に行われるトークン割当解除処理の動作手順を示すフローチャートである。
【図１２】同実施の形態に係るトークンメンバであるデータ受信端末３０１が離脱要求メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図１３】同実施の形態に係るグループ管理装置２０が離脱要求確認メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図１４】同実施の形態に係るトークン割当解除後のトークン割当処理の動作手順を示すフローチャートである。
【図１５】同実施の形態に係るグループ管理装置２０がデータ受信端末３０２に加入応答メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図１６】同実施の形態に係るデータ受信端末３０２が加入応答確認メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図１７】同実施の形態に係る非トークンメンバであるデータ受信端末３０３がマルチキャストグループから離脱する場合の動作手順を示すフローチャートである。
【図１８】同実施の形態に係る非トークンメンバであるデータ受信端末３０３が離脱要求メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図１９】同実施の形態に係るグループ管理装置２０がトークンメンバであるデータ受信端末３０２に状態確認メッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図２０】同実施の形態に係るデータ受信端末３０２が状態確認応答メッセージをグループ管理装置２０に送信したときのグループ管理テーブルの状態を示す図である。
【図２１】同実施の形態に係るグループ管理装置２０が非存在メンバヘトークンを割り当てようとしたときの状態を説明するための図である。
【図２２】同実施の形態に係るグループ管理装置２０が配下のデータ受信端末３０に対して加入者問い合わせメッセージを送信したときのグループ管理テーブルの状態を示す図である。
【図２３】同実施の形態に係るメッセージの種別を説明するための図である。
【符号の説明】
【０１０２】
１０ マルチキャストグループ管理システム
２０ グループ管理装置
２１ トークン割当部
２２ トークンメンバ管理部
２３ トークン割当解除部
２４ マルチキャスト配信データ中継部
３０，３０１，３０２，３０３，３０４ データ受信端末
４０ データ中継装置
５０ データ送信端末
【特許請求の範囲】
【請求項１】
自装置の配下に存在するデータ受信端末へのマルチキャスト配信データの中継を行うグループ管理装置において、
あるマルチキャストグループに属している前記データ受信端末のうち、少なくとも１のデータ受信端末に対してトークンを割り当てるトークン割当手段と、
前記トークンが割り当てられたデータ受信端末が、自装置の配下に存在し、かつ、前記あるマルチキャストグループに属している状態であるトークン割当対象状態であるか否かを管理するトークンメンバ管理手段と、
前記トークンメンバ管理手段により、前記トークンが割り当てられたデータ受信端末が前記トークン割当対象状態でないことが判明した場合に、該データ受信端末に対するトークンの割当を解除するトークン割当解除手段と、
少なくとも１のデータ受信端末に前記トークンが割り当てられている間、前記あるマルチキャストグループに属しているデータ受信端末へのマルチキャスト配信データの中継を行うマルチキャスト配信データ中継手段と
を備えることを特徴とするグループ管理装置。
【請求項２】
前記トークン割当手段は、前記トークン割当解除手段により割当が解除されたトークンを、他のデータ受信端末に割り当てることを特徴とする
請求項１に記載のグループ管理装置。
【請求項３】
前記トークン割当手段は、
前記データ受信端末が、自装置の配下に継続して存在しており、かつ、前記あるマルチキャストグループに継続して属している時間と、
前記データ受信端末が、自装置の配下に存在し、かつ、前記あるマルチキャストグループに属していた過去の累積時間と、
前記データ受信端末の機種と
の少なくとも１に応じて、前記トークンを割り当てるべきデータ受信端末を決定することを特徴とする
請求項１又は２に記載のグループ管理装置。
【請求項４】
前記トークン割当手段は、
自装置の配下に存在し、かつ、前記あるマルチキャストグループに属しているデータ受信端末の数と、
前記データ受信端末が自装置の配下に継続して存在する平均時間と
の少なくとも一方に応じて、前記トークンを割り当てるべきデータ受信端末の数を決定することを特徴とする
請求項１から３のいずれか１項に記載のグループ管理装置。
【請求項５】
前記トークンメンバ管理手段は、
前記トークンが割り当てられたデータ受信端末に対してのみ、該データ受信端末より受信したメッセージに対する応答メッセージを返信することを特徴とする
請求項１から４のいずれか１項に記載のグループ管理装置。
【請求項６】
前記トークンメンバ管理手段は、
前記トークンが割り当てられたデータ受信端末に対してのみ、該データ受信端末が前記トークン割当対象状態であるか否かを確認するためのメッセージを送信することを特徴とする
請求項１から５のいずれか１項に記載のグループ管理装置。
【請求項７】
前記トークン割当手段は、
前記あるマルチキャストグループ宛に問合せメッセージを送信することにより、該あるマルチキャストグループに属していることが確認されたデータ受信端末の中から、前記トークンを割り当てるべきデータ受信端末を決定することを特徴とする
請求項１から６のいずれか１項に記載のグループ管理装置。
【請求項８】
グループ管理装置が行うマルチキャストのグループ管理方法において、
前記グループ管理装置の配下に存在し、かつ、あるマルチキャストグループに属しているデータ受信端末のうち、少なくとも１のデータ受信端末に対してトークンを割り当てるトークン割当ステップと、
前記トークンが割り当てられたデータ受信端末の状態が、前記グループ管理装置の配下に存在していない状態と、前記あるマルチキャストグループに属していない状態との少なくとも１の状態であることが判明した場合に、前記データ受信端末に対するトークンの割当を解除するトークン割当解除ステップと、
前記トークン割当解除ステップにおいて割当が解除されたトークンを、前記グループ管理装置の配下に存在し、かつ、前記あるマルチキャストグループに属しているデータ受信端末のうち、いずれか１のデータ受信端末に割り当てるトークン再割当ステップと
を有し、
少なくとも１のデータ受信端末に前記トークンが割り当てられている間、前記あるマルチキャストグループに属しているデータ受信端末へのマルチキャスト配信データの中継を行うことを特徴とするグループ管理方法。
【請求項１】
自装置の配下に存在するデータ受信端末へのマルチキャスト配信データの中継を行うグループ管理装置において、
あるマルチキャストグループに属している前記データ受信端末のうち、少なくとも１のデータ受信端末に対してトークンを割り当てるトークン割当手段と、
前記トークンが割り当てられたデータ受信端末が、自装置の配下に存在し、かつ、前記あるマルチキャストグループに属している状態であるトークン割当対象状態であるか否かを管理するトークンメンバ管理手段と、
前記トークンメンバ管理手段により、前記トークンが割り当てられたデータ受信端末が前記トークン割当対象状態でないことが判明した場合に、該データ受信端末に対するトークンの割当を解除するトークン割当解除手段と、
少なくとも１のデータ受信端末に前記トークンが割り当てられている間、前記あるマルチキャストグループに属しているデータ受信端末へのマルチキャスト配信データの中継を行うマルチキャスト配信データ中継手段と
を備えることを特徴とするグループ管理装置。
【請求項２】
前記トークン割当手段は、前記トークン割当解除手段により割当が解除されたトークンを、他のデータ受信端末に割り当てることを特徴とする
請求項１に記載のグループ管理装置。
【請求項３】
前記トークン割当手段は、
前記データ受信端末が、自装置の配下に継続して存在しており、かつ、前記あるマルチキャストグループに継続して属している時間と、
前記データ受信端末が、自装置の配下に存在し、かつ、前記あるマルチキャストグループに属していた過去の累積時間と、
前記データ受信端末の機種と
の少なくとも１に応じて、前記トークンを割り当てるべきデータ受信端末を決定することを特徴とする
請求項１又は２に記載のグループ管理装置。
【請求項４】
前記トークン割当手段は、
自装置の配下に存在し、かつ、前記あるマルチキャストグループに属しているデータ受信端末の数と、
前記データ受信端末が自装置の配下に継続して存在する平均時間と
の少なくとも一方に応じて、前記トークンを割り当てるべきデータ受信端末の数を決定することを特徴とする
請求項１から３のいずれか１項に記載のグループ管理装置。
【請求項５】
前記トークンメンバ管理手段は、
前記トークンが割り当てられたデータ受信端末に対してのみ、該データ受信端末より受信したメッセージに対する応答メッセージを返信することを特徴とする
請求項１から４のいずれか１項に記載のグループ管理装置。
【請求項６】
前記トークンメンバ管理手段は、
前記トークンが割り当てられたデータ受信端末に対してのみ、該データ受信端末が前記トークン割当対象状態であるか否かを確認するためのメッセージを送信することを特徴とする
請求項１から５のいずれか１項に記載のグループ管理装置。
【請求項７】
前記トークン割当手段は、
前記あるマルチキャストグループ宛に問合せメッセージを送信することにより、該あるマルチキャストグループに属していることが確認されたデータ受信端末の中から、前記トークンを割り当てるべきデータ受信端末を決定することを特徴とする
請求項１から６のいずれか１項に記載のグループ管理装置。
【請求項８】
グループ管理装置が行うマルチキャストのグループ管理方法において、
前記グループ管理装置の配下に存在し、かつ、あるマルチキャストグループに属しているデータ受信端末のうち、少なくとも１のデータ受信端末に対してトークンを割り当てるトークン割当ステップと、
前記トークンが割り当てられたデータ受信端末の状態が、前記グループ管理装置の配下に存在していない状態と、前記あるマルチキャストグループに属していない状態との少なくとも１の状態であることが判明した場合に、前記データ受信端末に対するトークンの割当を解除するトークン割当解除ステップと、
前記トークン割当解除ステップにおいて割当が解除されたトークンを、前記グループ管理装置の配下に存在し、かつ、前記あるマルチキャストグループに属しているデータ受信端末のうち、いずれか１のデータ受信端末に割り当てるトークン再割当ステップと
を有し、
少なくとも１のデータ受信端末に前記トークンが割り当てられている間、前記あるマルチキャストグループに属しているデータ受信端末へのマルチキャスト配信データの中継を行うことを特徴とするグループ管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２００６−５７１４（Ｐ２００６−５７１４Ａ）
【公開日】平成１８年１月５日（２００６．１．５）
【国際特許分類】
【出願番号】特願２００４−１８０８６４（Ｐ２００４−１８０８６４）
【出願日】平成１６年６月１８日（２００４．６．１８）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
【公開日】平成１８年１月５日（２００６．１．５）
【国際特許分類】
【出願日】平成１６年６月１８日（２００４．６．１８）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
[ Back to top ]