JP4773387B2 - ネットワークシステム - Google Patents

Description

本発明は、ネットワークシステムに係り、特に、放送などのコンテンツ情報配信に用いられるマルチキャストの認証及び課金を行うためのネットワークシステムに関する。

ユニキャスト通信を放送型通信に用いた場合、データを配信するサーバとそのデータを受信するユーザ端末が１対１となるため、配信サーバはユーザ端末数分のデータを同時に配信する。このため、配信サーバに負荷がかかりかつトラヒック量も増大する。

これらの課題を解決する技術として、ある特定の複数の宛先に同時にデータを配信する放送型の通信技術としてマルチキャスト通信がある。配信サーバとユーザ端末間に設置されるパケット転送装置（ルータ、ゲートウェイなど）に、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で標準となっているＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍｅｍｂｅｒｓｈｉｐ Ｐｒｏｔｏｃｏｌ：非特許文献１、２参照）やＭＬＤ（Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒｙ：非特許文献３参照）を実装することで、パケット転送装置が配信サーバからのデータをコピーし、配信要求のあったユーザ端末だけにデータを送信する。これによって配信サーバはパケット転送装置宛てにデータを送信するだけで済むため配信サーバの負荷が抑えられ、かつ配信サーバとパケット転送装置間のトラヒックも抑えられる。

また、マルチキャスト通信を用いてデータ配信のサービスを行う場合、認証や課金が必要な場合もある。これらの実現方法の一例として、ＩＧＡＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ ｍｅｍｂｅｒｓｈｉｐ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ：非特許文献４）がＩＥＴＦのドラフトとなっている。ＩＧＭＰパケットにユーザ識別情報やパスワードなど認証に必要な情報を付加し、マルチキャストルータがその情報を基にＲＡＤＩＵＳ（Ｒｅｍｏｔｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｉａｌ Ｉｎ Ｕｓｅｒ Ｓｅｒｖｉｃｅ：非特許文献５、６参照）を用いて認証・課金サーバに問い合わせを行う。その問い合わせ結果を基に、マルチキャストルータは要求のあったユーザ端末に対してデータ配信するかを判断する。接続記録から課金処理も可能となる。

上記方法を用いた場合、ユーザ端末が多数となると高価なマルチキャストルータを多数必要とする。少しでも高価なマルチキャストルータを減らす方法が、例えば、特開２００４−３５７２００号公報（特許文献１）に開示されている。この技術では、ユーザ端末とルータ間に設置されるレイヤ２スイッチなどにＩＧＡＰパケットをスヌーピングする機能を持たせ、レイヤ２スイッチでデータ配信の制御を行うことでルータの数を抑えることができる。特開２００４−３５７２００で号公報に開示された技術では、レイヤ２スイッチの配下のユーザ端末が同一サブネット内に存在することが前提条件となる。ユーザ端末が同一サブネットに存在している場合、セキュリティにもあまい。

一方、上記のようなマルチキャスト通信を用いたサービスが行われる実際のアクセス系のネットワークでは、インターネット接続のユーザ認証や、セキュリティ確保のためにユーザ端末とルータ間はＰＰＰｏＥ（Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｃｏｌ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ（Ｅｔｈｅｒｎｅｔは登録商標）：非特許文献７参照）で接続されている場合が多い。ＰＰＰｏＥを用いた場合、ユーザ端末とルータは論理的にＰｏｉｎｔ ｔｏ Ｐｏｉｎｔで接続される。そのため、このようなネットワーク上でマルチキャスト通信を行う場合、ルータの物理的な回線数以上にユーザ端末と論理的に接続できるので、一旦レイヤ２スイッチでユーザ端末を終端することでマルチキャストルータの数を抑えて、マルチキャストの認証・課金、配信データの制御が可能となる。さらにこの場合に、ユーザ端末のＰＰＰｏＥの認証時にルータが認証サーバからユーザがどのマルチキャストグループに参加可能であるかという情報を受信し、ルータでＰＰＰｏＥとマルチキャストとの対応テーブルを持つことで、ユーザ端末から配信要求を受信すると、認証サーバに問い合わせすることなく配信の可否が行える（例えば、特許文献２、特許文献３参照）。

しかし、上記のようにユーザ端末とルータ間がＰｏｉｎｔ ｔｏ Ｐｏｉｎｔで接続されると、ルータが配信データをそのルータ配下に接続されるユーザ端末数分だけコピーして送信しなければならない。そのため、レイヤ２スイッチとルータ間のトラヒックは特開２００４−３５７２００号公報の場合と比較してユーザ端末数分だけ倍増し、コピーを行うルータにも負荷がかかってしまう。

この課題を解決する技術のひとつが、特開２００６−１０９０４７号公報（特許文献４）に開示されている。この技術では、ユーザ端末とルータ間が論理的にＰｏｉｎｔ ｔｏ Ｐｏｉｎｔで接続されている場合に、ユーザ端末とルータ間に設置されるレイヤ２スイッチが、ルータとの間にマルチキャスト専用のコネクションをはり、配下に接続されるユーザ端末の代わりに配信データを受信、コピー、送信することでレイヤ２スイッチとルータ間のトラヒックを抑えられ、ルータの負荷も低減できる。

ＲＦＣ１１１２ ＲＦＣ２２３６ ＲＦＣ２７１０ ｈｔｔｐ：／／ｗｗｗ．ｐｏｔａｒｏｏ．ｎｅｔ／ｉｅｔｆ／ａｌｌ−ｉｄｓ／ｄｒａｆｔ−ｈａｙａｓｈｉ−ｉｇａｐ−０３．ｔｘｔ ＲＦＣ２８６５ ＲＦＣ２８６６ ＲＦＣ２５１６ 特開２００４−３５７２００号公報 特開２００６−４２２２３号公報 特開２００６−１４８７５０号公報 特開２００６−１０９０４７号公報

ユーザ端末とルータ間が、セキュリティやユーザ管理のためにＰＰＰｏＥなどにより論理的にＰｏｉｎｔ ｔｏ Ｐｏｉｎｔとなっているネットワークにおいて、マルチキャスト通信を用いてデータ配信サービスを実施する場合に、特開２００６−１０９０４７号公報の技術ではユーザ端末とルータ間に設置されるレイヤ２スイッチが配下に接続されるユーザ端末に代わって配信要求や配信データの受信を行う。これによって、トラヒックやルータへの負荷を低減させることができる。

しかし、ルータはユーザ端末からではなくレイヤ２スイッチから配信要求を受け、またユーザ端末宛てにデータを配信するのではなくレイヤ２スイッチに配信データを送信する。そのため、ルータは、マルチキャストパケットに関するユーザ情報を把握することができないので、ＩＧＡＰや特開２００６−１４８７５０号公報などの方法で、ルータがマルチキャストサービス時に認証・課金を行うことができない場合がある。

例えば、レイヤ２スイッチの配下に接続されているユーザ端末があるマルチキャストデータの自端末への配信要求をすると、その配信要求はレイヤ２スイッチで受信され、レイヤ２スイッチは代理でルータに、自スイッチへの配信要求をする。従って、ルータは、レイヤ２スイッチへの配信要求を受信するので、どのユーザ端末からの配信要求なのかを知る術がない。従って、ルータは、端末の認証等をするための認証サーバへ問い合わせができない場合がある。

また、ルータは、レイヤ２スイッチからの配信要求に応じて、レイヤ２スイッチにマルチキャストデータを配信するため、どの端末がデータを受信しているかわからない。従って、ルータが課金サーバなどを用いて端末毎の課金をすることができない場合がある。
さらに、レイヤ２スイッチでは、どの端末がマルチキャストデータの配信が許可され、及び、配信が拒否されているのか、配信可否の判断ができない場合がある。

本発明は、以上の点に鑑み、上記ネットワークにおいてレイヤ２スイッチで管理するユーザ情報をルータが知る手段、その情報をもとにルータが認証・課金のための処理を行う手段を有するネットワークシステムを提供することを目的のひとつとする。また、本発明は、認証結果をもとにレイヤ２スイッチが配信データの制御を行う手段を提供することを目的のひとつとする。本発明は、トラヒックを抑えつつ安価で認証や課金を伴うマルチキャストサービスを実現するためのネットワークシステムを提供することを目的のひとつとする。

本発明は、セキュリティやユーザ管理のためにＰＰＰｏＥなどで、ユーザ端末とルータ間が論理的にＰｏｉｎｔ ｔｏ Ｐｏｉｎｔとなっているアクセス系のネットワーク上で、マルチキャスト通信によるデータ配信サービスを行う場合に、安価な装置構成で、かつトラヒックや装置への負荷を抑えて、様々な認証・課金サービス、ユーザ管理を実現することを目的のひとつとする。

また、本発明は、ユーザ端末ユーザ端末に対して新たに機能追加や設定が不要で、ＰＰＰ接続の認証だけで済むため、マルチキャスト用のユーザＩＤ（ユーザ識別子）やパスワードも不要であり、ユーザがマルチキャストサービスを受けるために再度認証することを必要としないため、ユーザに負担をかけることなく実現することを目的のひとつとする。

ユーザ端末がルータに対してＰＰＰ接続要求をすると、それを受けたルータは認証サーバへ問い合わせを行う。認証サーバでは、ユーザＩＤ、パスワード、そのユーザが参加できるグループアドレスの情報を管理しており、ＰＰＰ接続の認証結果と、参加できるグループアドレスとをルータへ送信する。この後に、ユーザ端末からあるマルチキャストグループへの参加要求（Ｊｏｉｎ）が送信されると、レイヤ２スイッチでユーザ端末からの参加要求（Ｊｏｉｎ）を終端する。しかし、レイヤ２スイッチはそのユーザ端末に対する配信許可／拒絶がわからないので、ルータに対してこのユーザ端末の情報を付与した参加要求（Ｊｏｉｎ）をルータに対して送信する。

ルータは、参加要求の情報と認証サーバから受信したユーザ情報と比較し、情報に差分がある場合にはレイヤ２スイッチにルータが保持している情報を参加確認（Ｑｕｅｒｙ）に付与し送信する。このルータからの情報によって、レイヤ２スイッチではそのユーザ端末に対する配信の許可／拒絶が分かるようになり、データを配信するかどうかを判断できるようになる。さらに、ルータの定期的な参加確認（Ｑｕｅｒｙ）により常にルータの情報とレイヤ２スイッチの情報の整合性を維持する。これにより、上記のようにレイヤ２スイッチがルータへ確認することなく、レイヤ２スイッチだけで配信の許可／拒絶を判断できるようになる。ただし、ユーザ端末がＰＰＰ接続後に、あるグループアドレスへの参加許可となるとルータの情報を更新する必要があるので、レイヤ２スイッチからのユーザ情報でルータの管理するユーザ情報に該当するものがなかった場合、ルータが認証サーバに対して再度問い合わせを行う。また、ルータのユーザ情報を更新し、その更新した情報をレイヤ２スッチへ送信する。これにより、レイヤ２スイッチでも最新のユーザ情報を把握することが可能となる。

さらに、レイヤ２スイッチが、あるユーザ端末を「拒絶」とした場合、その後にそのユーザ端末が参加許可となってもそのユーザ端末がＰＰＰ再接続をしない限り、ルータが認証サーバへ問い合わせる契機がないとレイヤ２スイッチで「許可」となることがない。そこで、レイヤ２スイッチで「拒絶」となっているユーザ情報には有効期限を設けることで、その有効期限が切れてからそのユーザ端末から参加要求（Ｊｏｉｎ）があればルータが認証サーバへ問い合わせる。これにより、ユーザ端末がＰＰＰ再接続をしなくてもレイヤ２スッチのユーザ情報更新を可能にする。

また、レイヤ２スイッチは、配信の許可／拒絶だけでなく、実際にユーザ端末への配信ログを記録する。ユーザ端末が参加していたグループアドレスから離脱したことを契機に、レイヤ２スイッチは、配信ログをルータへ送信する。ルータが、ユーザＩＤなど課金に必要な情報を追加し、課金サーバへ送信することで課金を可能とする。ユーザ端末が離脱する契機としては、例えば、ユーザ端末からの離脱宣言をレイヤ２スイッチが受信したとき、レイヤ２スイッチからユーザ端末への参加確認（Ｑｕｅｒｙ）に対する応答（Ｒｅｐｏｒｔ）がなかったとき、ＰＰＰ接続が切断されたときなどがある。１つ目と２つ目はレイヤ２スイッチが離脱を認識することができるが、３つ目の契機についてはレイヤ２スイッチだけでは離脱を認識することができない。そこで、ＰＰＰ接続が切断されたことを知ることができるルータが、ＰＰＰ切断時にユーザ情報をレイヤ２スイッチに参加確認（Ｑｕｅｒｙ）に付与して送付する。これにより、レイヤ２スイッチが切断を認識することができる。

さらに、ＰＰＰ接続時に、認証サーバから参加できるグループアドレスだけでなくその有効期限を送信し、ルータがレイヤ２スイッチに対してユーザ情報を送信する際にその有効期限を合わせて送信する。レイヤ２スイッチではその有効期限の間だけ配信を「許可」とすることで、例えばプリペイド式課金が可能となる。このとき、有効期限の代わりにトラヒックを指定し、あるトラヒックを配信したら配信をとめるようにしてもよい。

また、課金方法の別手段として、
マルチキャスト制御パケットに関しては、レイヤ２スイッチで終端するのではなく、レイヤ２スイッチでスヌーピングして配信制御テーブルを更新し、そのマルチキャスト制御パケットは通常パケットと同様に転送する。ルータは、ユーザ端末からの参加要求（Ｊｏｉｎ）の受信を契機に課金サーバへ課金開始通知をする。また、ユーザ端末からの離脱宣言（Ｌｅａｖｅ）を受信した場合、参加確認（Ｑｕｅｒｙ）に対する応答（Ｒｅｐｏｒｔ）がなかった場合、ＰＰＰ接続が切断された場合などに、課金サーバへ課金終了通知を行う。課金サーバは、ユーザ端末が参加した時刻と、離脱した時刻を把握することで課金が可能となる。さらに、課金終了通知時には、レイヤ２スイッチからの課金情報を合わせて課金サーバへ送信することでより正確な課金や従量課金が実現できる。

また、本発明では、上記課題を解決する手段として、レイヤ２スイッチやルータは、例えば複数の回線インタフェース、回線インタフェース制御部、パケットの解析／編集処理を行うプロセッサを具備する。メモリ上に保持するテーブルとしては、ユーザ情報を管理するテーブル、装置間のマルチキャスト用コネクションの管理をおこなうテーブルを具備する。

本発明の第２のパケット転送装置（ルータ）は、例えば、
複数のユーザ端末とＰｏｉｎｔ ｔｏ Ｐｏｎｉｔで接続されるパケット転送装置であって、
ユーザ端末の管理を行うユーザ管理テーブルと、配下に接続される下位パケット転送装置とのマルチキャスト用コネクション管理テーブルと、配下に接続される下位パケット転送装置からマルチキャストパケットを受信すると処理を行うプロセッサを備え、
前記プロセッサは配下に接続される下位パケット転送装置からユーザ情報を受信すると、パケット転送装置が管理しているユーザ管理テーブルと比較し、下位パケット転送装置のユーザ情報で配信許可が不明となっていた場合に、パケット転送装置のユーザ情報を下位パケット転送装置に送信し、下位パケット転送装置からユーザ情報がパケット転送装置のユーザ情報になかった場合には認証サーバへ問い合わせを行う。

また、本発明の第１のパケット転送装置（レイヤ２スイッチ）は、例えば、
上述の第２のパケット転送装置の配下に接続され、複数のユーザ端末を終端する下位パケット転送装置であって、
ユーザ端末への配信を制御する配信制御テーブルと、上位に接続される第２のパケット転送装置とのマルチキャスト用コネクション管理テーブルと、配下に接続されるユーザ端末からマルチキャストパケットを受信すると処理を行うプロセッサを備え、
前記プロセッサは、配下に接続されるユーザ端末からのマルチキャストパケットを受信すると、配信制御テーブルを更新し、上位パケット転送装置へ参加要求や参加確認に対する応答時にユーザ情報を送信し、上位パケット転送装置からユーザ情報を受信すると、その情報を元に配信制御テーブルを更新し、配信制御テーブルの情報を元に各ユーザ端末へのマルチキャストパケットの転送制御を行う。

上述の第１のパケット転送装置は、前記ユーザ管理テーブルには課金に必要な情報が記録され、前記プロセッサはユーザ端末から離脱宣言を受信すると、またユーザ端末から参加確認に対する応答がなかった場合、また上位パケット転送装置からユーザ情報を受信し配信制御テーブルを更新したときに配信を止めたとき、上位パケット転送装置にユーザ情報を送信することを特徴のひとつとする。

上述の第２のパケット転送装置は、ユーザ端末のＰＰＰ接続が切断されると、前記配信情報テーブルを更新し下位パケット転送装置に送信することを特徴のひとつとする。
上述の第２のパケット転送装置は、下位パケット転送装置から課金情報を含むユーザ情報を受信すると、管理しているユーザ情報を追加して、課金サーバへ送信することを特徴のひとつとする。

本発明の第１の解決手段によると、
複数のユーザ端末を終端し、受信したマルチキャストデータをコピーして前記ユーザ端末へ転送する第１のパケット転送装置と、
前記第１のパケット転送装置を介して複数の前記ユーザ端末とポイント トゥ ポイント接続される第２のパケット転送装置と、
前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを前記第２のパケット転送装置に出力するサーバと
を備え、
前記第１のパケット転送装置は、
グループアドレスと、前記ユーザ端末の端末識別情報と、配信許可及び配信拒絶のいずれかを示す情報とを含むエントリが記憶される配信制御テーブル
を有し、
前記第２のパケット転送装置は、前記ユーザ端末からポイント トゥ ポイント接続の接続要求を受信すると、前記サーバから前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを取得し、
前記第２のパケット転送装置は、受信されたグループアドレスと、前記ユーザ端末の端末識別情報とを対応して記憶し、
前記第１のパケット転送装置は、前記ユーザ端末から、予め定められたグループアドレスと該ユーザ端末の端末識別情報を含み、該ユーザ端末を送信元としたマルチキャストグループへの第１の参加要求を受信すると、該第１の参加要求を終端し、及び、前記配信制御テーブルに該グループアドレスと該端末識別情報とを対応して記憶し、
前記第１のパケット転送装置は、受信したグループアドレスと端末識別情報を含み、自装置を送信元とした第２の参加要求を前記第２のパケット転送装置に送信し、
前記第２のパケット転送装置は、第２の参加要求に含まれるグループアドレス及び端末識別情報と、記憶されたグループアドレス及び端末識別情報とを比較し、一致するものが記憶されていれば配信許可を示し、及び、記憶されていなければ配信拒絶を示す通知を前記第１のパケット転送装置に送信し、
前記第１のパケット転送装置は、該通知に従い、該グループアドレスと該端末識別情報とに対応して、配信許可又は配信拒絶を示す情報を前記配信制御テーブルに記憶し、
前記第１のパケット転送装置は、前記第２のパケット転送装置からグループアドレスを含むマルチキャストデータを受信し、前記配信制御テーブルを参照して、該グループアドレスに対応して配信許可を示す情報が記憶されたエントリの端末識別情報に従い、受信されたマルチキャストデータ及び／又はコピーしたマルチキャストデータをひとつ又は複数の前記ユーザ端末に送信するネットワークシステムが提供される。

本発明の第２の解決手段によると、
複数のユーザ端末を終端し、受信したマルチキャストデータをコピーして前記ユーザ端末へ転送する第１のパケット転送装置と、
前記第１のパケット転送装置を介して複数の前記ユーザ端末とポイント トゥ ポイント接続される第２のパケット転送装置と、
前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを前記第２のパケット転送装置に出力するサーバと
を備え、
前記第１のパケット転送装置は、
グループアドレスと、前記ユーザ端末の端末識別情報と、配信許可及び配信拒絶のいずれかを示す情報と、参加要求の受信及び未受信のいずれかを示す情報とを含むエントリが記憶される配信制御テーブル
を有し、
前記第２のパケット転送装置は、前記ユーザ端末からポイント トゥ ポイント接続の接続要求を受信すると、前記サーバから前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを取得し、
前記第２のパケット転送装置は、受信されたグループアドレスと、前記ユーザ端末の端末識別子とを含む通知を前記第１のパケット転送装置に送信し、
前記第１のパケット転送装置は、該通知に含まれるグループアドレス及び端末識別子と、配信許可を示す情報とを対応して前記配信制御テーブルに記憶し、
前記第１のパケット転送装置は、前記ユーザ端末から予め定められたグループアドレスと該ユーザ端末の端末識別情報を含むマルチキャストグループへの参加要求を受信すると、前記配信制御テーブルの該当するグループアドレスと端末識別情報に対応して、参加要求の受信を示す情報を記憶し、
前記第１のパケット転送装置は、前記第２のパケット転送装置からグループアドレスを含むマルチキャストデータを受信し、前記配信制御テーブルを参照して、該グループアドレスに対応して参加要求の受信を示す情報及び配信許可を示す情報が記憶されたエントリの端末識別情報に従い、受信されたマルチキャストデータ及び／又はコピーしたマルチキャストデータをひとつ又は複数の前記ユーザ端末に送信するネットワークシステムが提供される。

本発明の第３の解決手段によると、
複数のユーザ端末を終端し、受信したマルチキャストデータをコピーして前記ユーザ端末へ転送する第１のパケット転送装置と、
前記第１のパケット転送装置を介して複数の前記ユーザ端末とポイント トゥ ポイント接続される第２のパケット転送装置と、
前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを前記第２のパケット転送装置に出力し、及び、課金開始通知及び課金終了通知を受信することにより端末識別情報毎に課金を行うサーバと
を備え、
前記第１のパケット転送装置は、
グループアドレスと、前記ユーザ端末の端末識別情報と、配信許可及び配信拒絶のいずれかを示す情報とを含むエントリが記憶される配信制御テーブル
を有し、
前記第２のパケット転送装置は、前記ユーザ端末からポイント トゥ ポイント接続の接続要求を受信すると、前記サーバから前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを取得し、
前記第２のパケット転送装置は、受信されたグループアドレスと前記ユーザ端末の端末識別情報とを対応して記憶し、
前記第１のパケット転送装置は、前記ユーザ端末から、予め定められたグループアドレスと該ユーザ端末の端末識別情報を含むマルチキャストグループへの参加要求を受信すると、該参加要求をスヌーピングして、前記配信制御テーブルに該グループアドレスと該端末識別情報とを記憶し、及び、該参加要求を前記第２のパケット転送装置に転送し、
前記第２のパケット転送装置は、受信した参加要求に含まれるグループアドレス及び／又は端末識別情報を含む課金開始通知を前記サーバに送信し、
前記第２のパケット転送装置は、受信した参加要求に含まれるグループアドレス及び端末識別情報と、記憶されたグループアドレス及び端末識別情報とを比較し、一致するものが記憶されていれば配信許可を示し、及び、記憶されていなければ配信拒絶を示す通知を前記第１のパケット転送装置に送信し、
前記第１のパケット転送装置は、該通知に従い、グループアドレスと端末識別情報とに対応して、配信許可又は配信拒絶を示す情報を前記配信制御テーブルに記憶し、
前記第１のパケット転送装置は、前記第２のパケット転送装置からグループアドレスを含むマルチキャストデータを受信し、前記配信制御テーブルを参照して、該グループアドレスに対応して配信許可を示す情報が記憶されたエントリの端末識別情報に従い、受信されたマルチキャストデータ及び／又はコピーしたマルチキャストデータをひとつ又は複数の前記ユーザ端末に送信し、
前記第２のパケット転送装置は、前記第１のパケット転送装置を介して前記ユーザ端末から、グループアドレスと端末識別情報を含む離脱宣言を受信すると、受信した離脱宣言に含まれるグループアドレス及び／又は端末識別情報を含む課金終了通知を前記サーバに送信するネットワークシステムが提供される。

本発明によると、上記ネットワークにおいてレイヤ２スイッチで管理するユーザ情報をルータが知る手段、その情報をもとにルータが認証・課金のための処理を行う手段を有するネットワークシステムを提供することができる。また、本発明によると、認証結果をもとにレイヤ２スイッチが配信データの制御を行う手段を提供することができる。本発明によると、トラヒックを抑えつつ安価で認証や課金を伴うマルチキャストサービスを実現するためのネットワークシステムを提供することができる。

本発明によると、セキュリティやユーザ管理のためにＰＰＰｏＥなどで、ユーザ端末とルータ間が論理的にＰｏｉｎｔ ｔｏ Ｐｏｉｎｔとなっているアクセス系のネットワーク上で、マルチキャスト通信によるデータ配信サービスを行う場合に、安価な装置構成で、かつトラヒックや装置への負荷を抑えて、様々な認証・課金サービス、ユーザ管理が実現できる。

また、本発明によると、ユーザ端末ユーザ端末に対して新たに機能追加や設定が不要で、ＰＰＰ接続の認証だけで済むため、マルチキャスト用のユーザＩＤやパスワードも不要であり、ユーザがマルチキャストサービスを受けるために再度認証することを必要としないため、ユーザに負担をかけることなく実現できる。

以下、本実施の形態を図面を用いて説明する。以下の例では、ＩＰｖ４、ＩＧＭＰで説明しているが、ＩＰｖ６、ＭＬＤにおいても基本的な動作は同等であるのでＩＰｖ６、ＭＬＤの例を提示した説明は省略する。また、以下の例ではユーザ端末とルータ間がＰＰＰｏＥで接続されている場合を説明しているが、ＰＰＰｏＡ（ＰＰＰ ｏｖｅｒ ＡＴＭ）やＶＬＡＮ（Ｖｉｒｔｕａｌ ＬＡＮ）などユーザ端末とルータが論理的にＰｏｉｎｔ ｔｏ Ｐｏｉｎｔとなる場合にも同様に動作する。プロトコルは、上述のものに限らず適宜のプロトコルを用いることができる。装置としては、レイヤ２スイッチとルータを例に挙げているが、同等の機能を実装できる装置（例えばＢＡＳ（Ｂｒｏａｄｂａｎｄ Ａｃｃｅｓｓ Ｓｅｒｖｅｒ））であれば適宜装置に適用できる。また、以下の例では、認証サーバと課金サーバを同一サーバとして説明しているが、各サーバが分かれていた場合でも同様に動作する。さらに、以下の例では、各処理をソフトウェアで実行していることを前提に説明しているが、ハードウェアでも同様に実現できる。

１．第１の実施の形態
１．１ システム構成
図１に本実施の形態におけるネットワークシステムの構成図を示す。
ネットワークシステムは、例えば、レイヤ２スイッチ（Ｌ２ＳＷ、第１のパケット転送装置）１００、１０１と、ルータ（第２のパケット転送装置）２００と、コンテンツ配信サーバＳ１と、課金・認証サーバＳ２を備える。

このネットワーク構成例では、ユーザ端末（Ｈ１−１〜Ｈ１−ｎ、Ｈ２−１〜Ｈ２−ｎ）は一旦レイヤ２スイッチ（１００、１０１）に収容される。また、それぞれアクセスネットワーク（ＮＷ１、ＮＷ２）、及び、ＩＳＰ網（ＮＷ３）内にあるルータ（２００）を介して、インターネット（３００）やコンテンツ配信サーバ（Ｓ１）、課金・認証サーバ（Ｓ２）に接続される。なお、ユーザ端末（Ｈ１−１〜Ｈ１−ｎ、Ｈ２−１〜Ｈ２−ｎ）とルータ（２００）の間は、ＰＰＰｏＥで接続される。

図２は、従来技術を用いた場合のパケットの流れ及びその課題の説明図である。
ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）にはそれぞれに対しＭＡＣアドレス（００−００−８７−００−１１−１１〜００−００−８７−００−ｎｎ−ｎｎ）、ユーザＩＤ（ｕｓｅｒ１＠ｉｓｐ１、ｕｓｅｒ２＠ｉｓｐ１、ｕｓｅｒｎ＠ｉｓｐ１）が割り付けられているものとして説明する。ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）とルータ（１２００）は論理的なコネクション（ＬＰ１〜ＬＰｎ）で接続される。インターネット接続を行う場合、これらのコネクション（ＬＰ１〜ＬＰｎ）を通して接続する。また、ユーザ端末（Ｈ１−１、Ｈ１−ｎ）は予めコンテンツ配信業者と契約しており、マルチキャストグループ（グループアドレス２２４．１０．１０．１０）に参加する資格を有している。配信サーバ（Ｓ１）からのマルチキャストパケットの場合も同様に、コネクション（ＬＰ１、ＬＰｎ）を通して配信される。この場合マルチキャストパケットのコピー点はルータ（１２００）となる。そのため、参加するユーザ端末やＬ２ＳＷの数が増えると、その分だけルータでのコピーが必要となり、ルータ（１２００）に負荷がかかる。また、レイヤ２スイッチ（１１００）とルータ（１２００）間のトラヒックも増えてしまう。

図３は、本実施の形態のパケットの流れを示した図である。
インターネット接続に用いる論理的なコネクション（ＬＰ１〜ＬＰｎ）とは別に、Ｌ２ＳＷ（１００）とルータ（２００）間にマルチキャスト用の論理的なコネクション（ＬＭ）をはり、マルチキャストパケットをこのコネクション（ＬＭ）を通して配信する。この場合のマルチキャストパケットのコピー点はレイヤ２スイッチ（１００）となる。そのため、参加するユーザ端末が増えても、ルータ（２００）への負荷と、レイヤ２スイッチ（１００）とルータ（２００）間のトラヒックも抑えられる。

図４に、本実施の形態におけるレイヤ２スイッチ（１００）の内部構成図を示す。なお、本実施の形態とは直接関係しないレイヤ２スイッチの機能については適宜省略する。
レイヤ２スイッチ（１００）は、例えば、複数の入出力回線の回線インタフェース（１００−１−１〜１００−１−ｎ）と、回線インタフェース（１００−１−１〜１００−１−ｎ）の制御を行う回線インタフェース制御部（１００−２）と、パケットの解析、編集などを行うプロセッサ（１００−３）と、プロセッサ（１００−３）が処理を行うために使用するメモリ（１００−４）と、外付けの制御端末（１００−６）とのインタフェースを行う制御端末インタフェース（１００−５）と、送受信するパケットを一時的に格納する送受信バッファ（１００−７）とを備える。メモリ（１００−４）は、例えば、プロセッサ（１００−３）が実行するプログラム（１００−４−３）と、レイヤ２スイッチ（１００）の配下に接続されているユーザ端末（Ｈ１−１〜Ｈ１−ｎ）へのマルチキャストデータの配信を制御するための配信制御テーブル（１００−４−１）と、ルータ（２００）との間のマルチキャスト用コネクション管理テーブルＬ（１００−４−２）とが格納されている。また、送受信バッファ（１００−７）は、送信バッファ（１００−７−１）と受信バッファ（１００−７−２）を有する。

回線インタフェース（１００−１−１〜１００−１−ｎ）には、それぞれに対し個別のＭＡＣアドレスが割り付けられている。本例では、回線インタフェース＃１（１００−１−１）には００−００−８７−１１−１１−１１が、回線インタフェース＃２（１００−１−２）には００−００−８７−２２−２２−２２が、回線インタフェース＃３（１００−１−３）には００−００−８７−３３−３３−３３が、回線インタフェース＃ｎ（１００−１−ｎ）には００−００−８７−ｎｎ−ｎｎ−ｎｎがそれぞれ割り付けられているものとして説明する。

図５（ａ）に、配信制御テーブル（１００−４−１）の詳細構成例を示す。
配信制御テーブル（１００−４−１）は、レイヤ２スイッチの配下に接続される、ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）がどのマルチキャストグループに属しているか、参加要求のあり／なし、配信の許可／拒絶、配信時間やトラヒック量の記録などを管理するものである。配信制御テーブル（１００−４−１）は、例えば、グループアドレス（１００−４−１−１）、回線インタフェースのＩＤ（１００−４−１−２）、Ｓｅｓｓｉｏｎ ＩＤ（１００−４−１−３）、ユーザ端末ＭＡＣアドレス（１００−４−１−４）、参加要求の有無（受信又は未受信）（１００−４−１−５）、配信許可情報（配信許可又は配信拒絶又は不明）（１００−４−１−６）、配信開始時刻（１００−４−１−７）、配信終了時刻（１００−４−１−８）、及び、トラヒック情報（１００−４−１−９）を含む。図５（ｂ）〜（ｄ）、図６、図２２は、配信制御テーブル（１００−４−１）が更新されたものである。

図７に、マルチキャスト用コネクション管理テーブルＬ（１００−４−２）の詳細構成例を示す。
マルチキャスト用コネクション管理テーブル（１００−４−２）は、例えば、ルータ（２００）との間でどのグループアドレスのパケットを、どのコネクションを用いて送受信するかを管理するテーブルである。マルチキャスト用コネクション管理テーブル（１００−４−２）は、例えば、グループアドレス（１００−４−２−１）、回線インタフェースのＩＤ（１００−４−２−２）、Ｓｅｓｓｉｏｎ ＩＤ（１００−４−２−３）、及び、ルータＭＡＣアドレス（１００−４−２−４）を含む。

図８に、本実施の形態におけるルータ（２００）の内部構成図を示す。なお、本実施の形態とは直接関係しないルータの機能については適宜省略する。
ルータ（２００）は、例えば、複数の入出力回線の回線インタフェース（２００−１−１〜２００−１−ｎ）と、回線インタフェース（２００−１−１〜２００−１−ｎ）の制御を行う回線インタフェース制御部（２００−２）と、パケットの解析、編集などを行うプロセッサ（２００−３）と、プロセッサ（２００−３）が処理を行うために使用するメモリ（２００−４）と、外付けの制御端末（２００−６）とのインタフェースを行う制御端末インタフェース（２００−５）と、送受信するパケットを一時的に格納する送受信バッファ（２００−７）とを備える。

メモリ（２００−４）には、例えば、プロセッサ（２００−３）が実行するプログラム（２００−４−３）と、ルータ（２００）の配下に接続されているユーザ端末（Ｈ１−１〜Ｈ１−ｎ）を管理するための配信情報テーブル（２００−４−１）と、レイヤ２スイッチ（１００）との間のマルチキャスト用コネクション管理テーブルＲ（２００−４−２）とが格納されている。また、送信バッファ（２００−７）は、送信バッファ（２００−７−１）と受信バッファ（２００−７−２）を有する。

回線インタフェース（２００−１−１〜２００−１−ｎ）には、それぞれに対し個別のＭＡＣアドレスが割り付けられている。本例では、回線インタフェース＃１（２００−１−１）には００−００−８７−００−００−１１が、回線インタフェース＃２（２００−１−２）には００−００−８７−００−００−２２が、回線インタフェース＃３（２００−１−３）には００−００−８７−００−００−３３が、回線インタフェース＃ｎ（２００−１−ｎ）には００−００−８７−００−００−ｎｎがそれぞれ割り付けられているものとして説明する。

図９（ａ）に、配信情報テーブル（２００−４−１）の詳細構成例を示す。
配信情報テーブル（２００−４−１）は、例えば、ルータ（２００）が認証・課金サーバ（Ｓ２）とのやり取りに必要な情報や、ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）がどのグループアドレスに参加可能かを管理するテーブルである。配信情報テーブル（２００−４−１）は、例えば、ユーザＩＤ（２００−４−１−１）、パスワード（２００−４−１−２）、グループアドレス（２００−４−１−３）、回線インタフェースのＩＤ（２００−４−１−４）、Ｓｅｓｓｉｏｎ ＩＤ（２００−４−１−５）、及び、ユーザ端末ＭＡＣアドレス（２００−４−１−６）を含む。図９（ｂ）、（ｃ）、図２３は、配信情報テーブル（２００−４−１）が更新されたものである。

図１０に、マルチキャスト用コネクション管理テーブルＲ（２００−４−２）の詳細構成例を示す。
マルチキャスト用コネクション管理テーブルＲ（２００−４−２）は、例えば、レイヤ２スイッチ（１００）との間でどのグループアドレスのパケットを、どのコネクションを用いて送受信するかを管理するテーブルである。マルチキャスト用コネクション管理テーブルＲ（２００−４−２）は、例えば、グループアドレス（２００−４−２−１）、回線インタフェースのＩＤ（２００−４−２−２）、Ｓｅｓｓｉｏｎ ＩＤ（２００−４−２−３）、及び、レイヤ２スイッチＭＡＣアドレス（２００−４−２−４）を含む。

図１１（ａ）に、ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）とルータ（２００）間で送受信されるマルチキャストパケット以外のパケットの構成例を示す。
マルチキャストパケット以外のパケットは送信先物理アドレスであるＭＡＣ ＤＡ（３００）、送信元物理アドレスであるＭＡＣ ＳＡ（３０１）、ＰＰＰｏＥヘッダ情報（３０２）、ＰＰＰヘッダ情報（３０３）、送信元ＩＰアドレスであるＩＰ ＳＡ（３０４）、送信先ＩＰアドレスであるＩＰ ＤＡ（３０５）、及び、データ（３０６）を含む。

図１１（ｂ）に、ユーザ端末（Ｈ１−１〜Ｈ１−ｎ）とルータ（２００）間で送受信されるマルチキャストパケットの構成例を示す。
マルチキャストパケットは、上述のパケットの構成に、マルチキャスト制御情報であるＩＧＭＰ（３０７）が付与され、レイヤ２スイッチ（１００）とルータ（２００）間では、各装置が管理しているユーザ管理テーブル（１００−４−１、２００−４−１）の情報が付与される。

図１２に、認証・課金サーバ（Ｓ２）が保持しているユーザ管理テーブルの詳細構成例を示す。
ユーザ管理テーブルは、例えば、ＰＰＰ接続認証時に用いられるものであり、ユーザＩＤ（Ｓ２−１−１）、パスワード（Ｓ２−１−２）、グループアドレス（Ｓ２−１−３）を含む。このテーブルは、ユーザ識別やユーザ管理のためにＩＳＰ業者によって登録・更新されることができる。

１．２ 動作
図１３に、参加資格を有するユーザ端末（Ｈ１−１）のＰＰＰ接続要求からマルチキャストのデータを受信するまでの動作シーケンスを示す。図１４に、ユーザ端末（Ｈ１−１）がマルチキャストデータを受信している場合に、さらに参加資格を有するユーザ端末（Ｈ１−ｎ）のＰＰＰ接続要求からマルチキャストのデータを受信するまでの動作シーケンスを示す。図１５に、ユーザ端末（Ｈ１−１、Ｈ１−ｎ）がマルチキャストデータを受信している場合に、参加資格がないユーザ端末（Ｈ１−２）のＰＰＰ接続要求からマルチキャスト参加要求が拒絶されるまでの動作シーケンスを示す。

図１６に、レイヤ２スイッチ（１００）における、配下に接続されているユーザ端末（Ｈ１−１〜Ｈ１−ｎ）からパケットを受信した場合の処理フローを示す。図１７に、ルータ（２００）における、レイヤ２スイッチからマルチキャスト用コネクション（ＬＭ）を介してパケットを受信した場合の処理フローを示す。

図１８に、マルチキャストサービスに参加中であるユーザ端末（Ｈ１−１、Ｈ１−ｎ）がＬｅａｖｅパケットを送信して離脱した場合の課金動作シーケンスを示す。図１９に、マルチキャストサービスに参加中であるユーザ端末（Ｈ１−１）がＲｅｐｏｒｔパケットを返信しなくなり、離脱した場合の課金動作シーケンスを示す。図２０に、マルチキャストサービスに参加中であるユーザ端末（Ｈ１−１）がＰＰＰセッション切断により離脱した場合の課金動作シーケンスを示す。

図２１に、レイヤ２スイッチ（１００）がユーザ端末（Ｈ１−１〜Ｈ１−ｎ）からＬｅａｖｅパケットを受信した場合の処理フローを示す。

（マルチキャストサービス認証方法）
まず、例えば、グループアドレス２２４．１０．１０．１０のマルチキャストサービスへの参加資格を有するユーザ端末（Ｈ１−１）が、配信サーバ（Ｓ１）からの配信データを受信するまでの流れについて図１３を用いて説明する。

ユーザ端末（Ｈ１−１）は始めに、ルータ（２００）に対してＰＰＰ接続要求（ＳＱ１−１）を行う（ＳＱ１−１）。このときに、接続認証に必要となるユーザ端末（Ｈ１−１）のユーザＩＤ（ｕｓｅｒ１＠ｉｓｐ１）とパスワード（ｕｓｅｒ１ｐ）を送信する。なお、ユーザ端末（Ｈ１−１）のＭＡＣアドレスを含んでもよい。要求を受信したルータ（２００）は、ユーザ端末（Ｈ１−１）からの情報を含む認証依頼（Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ）を、認証・課金サーバ（Ｓ２）に送信する（ＳＱ１−２）。認証・課金サーバ（Ｓ２）では、受信したユーザＩＤとパスワードの組み合わせに基づき、管理しているユーザ管理テーブル（図１２）で保持しているユーザＩＤ（Ｓ２−１−１）とパスワード（Ｓ２−１−２）と同じ組み合わせがあるかを検索する（ＳＱ１−３）。存在した場合、対応するグループアドレス（ここでは２２４．１０．１０．１０）を取得し、インターネット接続に対するアクセス許可通知（Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）を、ルータ（２００）に対して送信する（ＳＱ１−４）。認証・課金サーバ（Ｓ２）のユーザ管理テーブル（図１２）には、ユーザが参加できるマルチキャストのグループアドレス（Ｓ２−１−３）も記録されていて、アクセス許可通知（Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）とグループアドレスとがルータ（２００）に送信される。

このアクセス許可通知（Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）を受信したルータ（２００）では、受信バッファ（２００−７−２）に格納されたパケットをプロセッサ（２００−３）が読み出し、配信情報テーブル（２００−４−１）を更新する（図９（ａ）、ＳＱ１−５）。ユーザＩＤ（２００−４−１−１）には、ユーザ端末（Ｈ１−１）のユーザＩＤ：ｕｓｅｒ１＠ｉｓｐ１が、パスワード（２００−４−１−２）には、ユーザ端末（Ｈ１−１）のパスワード：ｕｓｅｒ１ｐが、グループアドレス（２００−４−１−３）には、認証・課金サーバ（Ｓ２）から受信した２２４．１０．１０．１０が、回線インタフェース（２００−４−１−４）には、レイヤ２スイッチ（１００）に接続される回線インタフェースのＩＤ：例えば＃３が、Ｓｅｓｓｉｏｎ ＩＤ（２００−４−１−５）には、レイヤ２スイッチ（１００）とのセッションのＩＤ：例えば１０が、ユーザ端末ＭＡＣアドレス（２００−４−１−６）には、ユーザ端末（Ｈ１−１）のＭＡＣアドレス：００−００−８７−００−１１−１１が、それぞれ登録される。

なお、ユーザ端末ＭＡＣアドレスは、ＰＰＰ接続要求に含まれていてもよいし、認証・課金サーバ（Ｓ２）でユーザＩＤに対応して記憶しておき、アクセス許可通知に含めるなどによりルータ（２００）が取得してもよい。また、ユーザ端末ＭＡＣアドレスは、ＭＡＣアドレス以外にも、ユーザ端末を識別する適宜の端末識別情報であってもよい。例えば、ユーザＩＤなどでもよい。
ルータ（２００）は、認証が完了したことを、ユーザ端末（Ｈ１−１）に通知する（ＳＱ１−６）。これによって、ユーザ端末（Ｈ１−１）は、インターネット接続が可能となる。

その後、ユーザ端末（Ｈ１−１）が、グループアドレス２２４．１０．１０．１０のマルチキャストサービスに参加するために、ＩＧＭＰ Ｊｏｉｎ（第１の参加要求）を送信する（ＳＱ１−７）。なお、ユーザ端末（Ｈ１−１）は、予めマルチキャストのグループアドレスを取得していることができる。送信されるＩＧＭＰ Ｊｏｉｎは、例えば、予め定められたグループアドレスとユーザ端末の端末識別情報を含み、ユーザ端末を送信元（すなわちマルチキャストデータの配信先）としたパケットである。そのＩＧＭＰ Ｊｏｉｎパケットは、例えば、ユーザ端末（Ｈ１−１）が接続されるレイヤ２スイッチ（１００）の回線インタフェース＃１（１００−１−１）で受信される。回線インタフェース制御部（１００−２）が、ＩＧＭＰ Ｊｏｉｎパケットを受信バッファ（１００−７−２）に格納し、プロセッサ（１００−３）に対して、パケットを受信したことを通知する。通知を受けたプロセッサ（１００−３）は図１６のフローに従って、以下の処理を行う。

レイヤ２スイッチ（１００）のプロセッサ（１００−３）は、ユーザ端末からパケットを受信（図１６：Ｆ１−１）すると、受信したパケットがＩＧＭＰパケットかを判別する（Ｆ１−２）。プロセッサ（１００−３）は、ＩＧＭＰパケットでない場合は（Ｆ１−２）、送信バッファ（１００−７−１）に格納して通常の転送処理をする（Ｆ１−３）。例えば、送信バッファ（１００−７−１）に格納されたパケットは、回線インタフェース制御部（１００−２）がパケットの送信先物理アドレスであるＭＡＣ ＤＡ（３００）を基に、回線インタフェース＃３（１００−１−３）を介して送信する。通常、送信先物理アドレスであるＭＡＣ ＤＡ（３００）は００−００−８７−００−００−３３であり、ルータ（２００）宛てとなる。なお、前述のＰＰＰ接続要求時のパケットはこれら通常処理となる。

一方、受信パケットがＩＧＭＰパケットの場合（Ｆ１−２）、プロセッサ（１００−３）は、パケットがＪｏｉｎ（Ｒｅｐｏｒｔ）かＬｅａｖｅかを判別する（Ｆ１−４）。Ｌｅａｖｅの場合は、詳細は後述するが、図２１に示すフローで処理を進める（Ｆ１−５）。Ｊｏｉｎの場合、パケットの送信先ＩＰアドレス（ＩＰ ＤＡ）（３０５）となっているグループアドレスで、ルータ（２００）との間にコネクションが張られているかをマルチキャスト用コネクション管理テーブル（１００−４−２）を参照して確認する（Ｆ１−６）。

コネクションがない場合（該当するグループアドレスが記憶されていない場合）は（Ｆ１−６）、ルータ（２００）との間でマルチキャスト用コネクションを張り、その結果をマルチキャスト用コネクション管理テーブル（１００−４−２）に反映させる（Ｆ１−７、ＳＱ１−８、ＳＱ１−９）。図７は、反映後のテーブルの例である。このとき、ルータ（２００）のマルチキャスト用コネクション管理テーブル（２００−４−２）も同様に更新される。図１０は、更新後のテーブルの例である。その後、処理Ｆ１−１０に移る。

一方、コネクションがすでにあった場合（該当するグループアドレスが記憶されている場合）は（Ｆ１−６）、配信制御テーブル（１００−４−１）に登録済みかどうかを、パケットの送信元物理アドレスであるＭＡＣ ＤＡ（３０１）であるユーザ端末（Ｈ１−１）のＭＡＣアドレスと、グループアドレスとを検索キーにして確認する（Ｆ１−８）。登録済みの場合、受信バッファ（１００−７−２）からパケットを破棄する（Ｆ１−９）。一方、配信制御テーブル（１００−４−１）に未登録の場合、処理Ｆ１−１０に移る。
処理Ｆ１−１０では、図５（ａ）に示すように配信制御テーブル（１００−４−１）を更新する（Ｆ１−１１、ＳＱ１−１０）。この時点で、配信許可（１００−４−１−６）はわからないので、例えば「不明」とする。

最後に、更新した配信制御テーブル（１００−４−１）の情報をＪｏｉｎパケット（第２の参加要求）のデータ領域（３０８）に付与し、送信元物理アドレスであるＭＡＣ ＳＡ（３０１）を回線インタフェース＃３のＭＡＣアドレスである００−００−８７−３３−３３−３３に書き換え、送信バッファ（１００−７−１）に格納する。送信バッファ（１００−７−１）から回線インタフェース制御部（１００−２）がパケットの送信先物理アドレスであるＭＡＣ ＤＡ（３００）を基に、回線インタフェース＃３（１００−１−３）を介してルータ（２００）に送信する（Ｆ１−１１、ＳＱ１−１１）。ただし、配信制御テーブル（１００−４−１）の回線インタフェース（１００−４−１−２）の情報は、付与する情報には含めなくてもよい。

配信制御テーブル（１００−４−１）の情報が付与されたＪｏｉｎパケットがルータ（２００）の回線インタフェース＃３に到着すると、レイヤ２スイッチ（１００）と同様に受信バッファ（２００−７−２）に格納される。パケットを受信してからのプロセッサ（２００−３）の処理は図１７に示すフローですすめられる。

ルータ（２００）のプロセッサ（２００−３）は、パケットを受信すると（Ｆ２−１）、まずＪｏｉｎかＬｅａｖｅかを判別する（Ｆ２−２）。Ｌｅａｖｅの場合は、詳細は後述するが、配信情報テーブル（２００−４−１）を更新し、配信サーバ（Ｓ１）に対して、配信の停止要求であるＰＩＭ Ｌｅａｖｅを送信する（Ｆ２−３）。

Ｊｏｉｎの場合、パケットに付与されている配信制御テーブル（図５（ａ））の情報と、ルータ（２００）が管理している配信情報テーブル（図９（ａ））とを比較する（ＳＱ１−１１）。具体的には、まず配信制御テーブル（１００−４−１）に基づくＳｅｓｓｉｏｎ ＩＤ（１００−４−１−３）とユーザ端末ＭＡＣアドレス（１００−４−１−４）の組み合わせが、配信情報テーブル（２００−４−１）にあるかを検索する（Ｆ２−４）。なお、いずれか一方でもよい。該当しない場合はパケットを破棄する（Ｆ２−５）。該当するものがある場合、さらにグループアドレス（１００−４−１−１）が、配信情報テーブル（２００−４−１）のグループアドレス（２００−４−１−３）に該当するかを検索する（Ｆ２−６）。

該当するものがない場合には（Ｆ２−６）、配信情報テーブル（２００−４−１）のＳｅｓｓｉｏｎ ＩＤ（２００−４−１−５）、ユーザ端末ＭＡＣアドレス（２００−４−１−６）に対応するユーザＩＤ（２００−４−１−１）とパスワード（２００−４−１−２）を利用して、認証・課金サーバ（Ｓ２）へ認証依頼（Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ）を再送信して（Ｆ２−７）、最新のグループアドレス情報を確認する。また、配信情報テーブル（２００−４−１）を更新し（Ｆ２−８）、更新した配信情報テーブル（２００−４−１）の情報をＱｕｅｒｙパケットのデータ領域（３０８）に付与し、送信元物理アドレスであるＭＡＣ ＳＡ（３０１）を回線インタフェース＃３のＭＡＣアドレスである００−００−８７−００−００−３３に、送信先物理アドレスであるＭＡＣ ＤＡ（３００）を図１０のレイヤ２スイッチＭＡＣアドレス（２００−４−２−４）に記録されている００−００−８７−３３−３３−３３に書き換え、送信バッファ（２００−７−１）に格納する。送信バッファ（２００−７−１）から回線インタフェース制御部（２００−２）が、パケットのＭＡＣ ＤＡ（３００）を基に回線インタフェース＃３を介して送信する（Ｆ２−９）。このときに、Ｑｕｅｒｙパケットには配信情報テーブル（２００−４−１）のグループアドレス（２００−４−１−３）、Ｓｅｓｓｉｏｎ ＩＤ（２００−４−１−５）、ユーザ端末ＭＡＣアドレス（２００−４−１−６）が付与される。

一方、管理している配信情報テーブル（２００−４−１）にグループアドレスが該当する場合には（Ｆ２−６）、受信した配信制御テーブル（１００−４−１）の情報に基づく配信許可（１００−４−１−６）を確認する（Ｆ２−１０）。このデータは、受信したパケットに含まれている。配信許可情報が「不明」となっている場合には、グループアドレスが該当しなかった場合と同様に、配信情報テーブル（２００−４−１）の情報を付与しＱｕｅｒｙパケットを送信する（Ｆ２−９、ＳＱ１−１３）。なお、配信許可を示す適宜の通知を行ってもよい。すでに「許可」となっている場合には（Ｆ２−１０）、グループアドレス２２４．１０．１０．１０のデータをレイヤ２スイッチ（１００）に配信中であれば（Ｆ２−１１）、受信バッファ（２００−７−２）からそのパケットを破棄する（Ｆ２−１３）。配信中でなければ（Ｆ２−１１）、配信サーバ（Ｓ１）に対して、グループアドレス２２４．１０．１０．１０の配信要求ＰＩＭ Ｊｏｉｎを送信する（Ｆ２−１２、ＳＱ１−１７）。

Ｑｕｅｒｙパケットを受信したレイヤ２スイッチ（１００）は、レイヤ２スイッチ（１００）の配下に参加しているユーザ端末、つまり配信制御テーブル（１００−４−１）の配信許可（１００−４−１−６）が「許可」、かつ参加要求（１００−４−１−５）が「あり」となっているユーザ端末宛てにＱｕｅｒｙパケットを送信する。送信後、受信した配信情報テーブル（２００−４−１）の情報をもとに配信制御テーブル（１００−４−１）を更新する。具体的には、この時点で受信した配信情報テーブル（２００−４−１）には、グループアドレス（２００−４−１−４）には２２４．１０．１０．１０、Ｓｅｓｓｉｏｎ ＩＤ（２００−４−１−５）には１０、ユーザ端末ＭＡＣアドレス（２００−４−１−６）には００−００−８７−００−１１−１１が記録されている。

プロセッサ（１００−３）は、受信した配信情報テーブル（２００−４−１）の情報に含まれるユーザ端末は配信許可されていると判断する。従って、図５（ｂ）に示すように、配信制御テーブル（１００−４−１）の該当するユーザ端末ＭＡＣアドレスに対応する配信許可（１００−４−１−６）を、「不明」から「許可」に更新する（ＳＱ１−１４）。更新した配信制御テーブル（１００−４−１）の情報をＲｅｐｏｒｔパケットに付与し、ルータ（２００）に送信する（ＳＱ１−１５）。ルータ（２００）では先に述べたように、テーブルを比較し（ＳＱ１−１６）、配信サーバ（Ｓ１）に、データの配信要求であるＰＩＭ Ｊｏｉｎを送信する（ＳＱ１−１７）。配信サーバ（Ｓ１）からデータが配信される（ＳＱ１−１８）。

ルータ（２００）ではデータを受信すると、マルチキャスト用コネクション管理テーブル（２００−４−２）を参照して（ＳＱ１−１９）、グループアドレスに対応する回線インタフェースのＩＤ等に従い、レイヤ２スイッチ（１００）へデータを転送する（ＳＱ１−２０）。レイヤ２スイッチ（１００）ではデータを受信すると、配信制御テーブル（１００−４−１）を参照し（ＳＱ１−２１）、参加要求（１００−４−１−５）が「あり」、かつ、配信許可（１００−４−１−６）が「許可」となっているエントリの、ユーザ端末ＭＡＣアドレス、回線インタフェースのＩＤ等に従い、ユーザ端末（Ｈ１−１）宛てにデータを転送する（ＳＱ１−２２）。

このときレイヤ２スイッチ（１００）では、図５（ｃ）に示すように、配信制御テーブル（１００−４−１）の配信開始時刻（１００−４−１−７）を記録し、配信データを転送するたびにトラヒック（１００−４−１−９）を更新していく（ＳＱ１−２３）。

また、ルータ（２００）からは参加確認のために、定期的にＱｕｅｒｙパケットが送信され（ＳＱ１−２４）、レイヤ２スイッチ（１００）が配信制御テーブル（１００−４−１）を参照して（ＳＱ１−２５）、ユーザ端末（Ｈ１−１）へＱｕｅｒｙパケットを送信する（ＳＱ１−２６）。ユーザ端末（Ｈ１−１）が参加を継続する場合には、継続を要求するＲｅｐｏｒｔパケットを返信する（ＳＱ１−２７）。レイヤ２スイッチ（１００）では図１６のフローに従い配信制御テーブル（１００−４−１）を更新し（ＳＱ１−２８）、ルータ（２００）宛てにＲｅｐｏｒｔパケットを返信する（ＳＱ１−２９）。

ルータ（２００）は定期的な参加確認によって、配信データの要否だけでなく、レイヤ２スイッチ（１００）の配信制御テーブル（１００−４−１）とルータ（２００）の配信情報テーブル（１００−４−２）を比較する（ＳＱ１−３０）ことで、互いのテーブルの整合性を保つことができる。

次に、図１４を参照して、ユーザ端末（Ｈ１−１）がグループアドレス２２４．１０．１０．１０のマルチキャストサービスに参加している場合に、さらに参加資格を有するユーザ端末（Ｈ１−ｎ）がＰＰＰ接続をし、グループアドレス２２４．１０．１０．１０のマルチキャストサービスへの参加要求をし、配信データが転送されるまでの流れを説明する。

配信サーバ（Ｓ１）から配信データがルータ（２００）へ転送され（ＳＱ２−１）、前述と同様に配信情報テーブル（２００−４−１）を参照し（ＳＱ２−２）、レイヤ２スイッチ（１００）へ転送する（ＳＱ２−３）。レイヤ２スイッチ（１００）では配信制御テーブル（１００−４−１）を参照し（ＳＱ２−４）、ユーザ端末（Ｈ１−１）へデータを転送する（ＳＱ２−５）。このとき、データを転送するたびに、配信制御テーブル（１００−４−１）のトラヒック（１００−４−１−９）を更新する。

ここで、ユーザ端末（Ｈ１−ｎ）がＰＰＰ接続要求をする（ＳＱ２−７）。ルータ（２００）は、ユーザ端末（Ｈ１−１）のときと同様に、認証・課金サーバ（Ｓ２）へ認証依頼（Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ）を送信（ＳＱ２−８）する。認証・課金サーバ（Ｓ２）は、ユーザ管理テーブル（図１２）を検索し（ＳＱ２−９）、アクセス許可通知（Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）とともに、このユーザ端末（Ｈ１−ｎ）が参加できるグループアドレス情報を返信する（ＳＱ２−１０）。ルータ（２００）は、この情報をもとに配信情報テーブル（２００−４−１）を更新し（図９（ｂ）、ＳＱ２−１１）、ユーザ端末（Ｈ１−ｎ）へ認証完了通知を行う（ＳＱ２−１２）。

ここで、ルータ（２００）がグループアドレス２２４．１０．１０．１０への参加者がいるかどうかの確認と、レイヤ２スイッチ（１００）とのテーブルの整合性維持のためにレイヤ２スイッチ（１００）宛てに、図９（ｂ）の配信情報テーブルの各情報を含むＱｕｅｒｙパケットを送信した（ＳＱ２−１３）場合について説明する。なお、Ｑｕｅｒｙパケットを送信せず、後述するＳＱ２−２０の処理へ移ってもよい。レイヤ２スイッチ（１００）では配信制御テーブル（１００−４−１）を参照し（ＳＱ２−１４）、ユーザ端末（Ｈ１−１）へＱｕｅｒｙを送信し（ＳＱ２−１５）、ユーザ端末（Ｈ１−１）がその応答を返信する（ＳＱ２−１６）。その後、レイヤ２スイッチ（１００）は図５（ｄ）に示すように、配信制御テーブル（１００−４−１）を更新し（ＳＱ２−１７）、更新した配信制御テーブル（１００−４−１）の情報をＲｅｐｏｒｔパケットに付与してルータ（２００）へ送信する（ＳＱ２−１８）。この場合、ルータ（２００）がテーブル（図５（ｄ）と図９（ｂ））を比較すると（ＳＱ２−１９）、グループアドレス２２４．１０．１０．１０は既に配信中であるため整合性を確認後、パケットを破棄する（Ｆ２−１３）。

ユーザ端末（Ｈ１−ｎ）がグループアドレス２２４．１０．１０．１０への参加を要求すると（ＳＱ２−２０）、レイヤ２スイッチ（１００）は配信制御テーブル（１００−４−１、図５（ｄ））の参加要求（１００−４−１−５）を「なし」から「あり」へ変更する（ＳＱ２−２１）。配信制御テーブル（１００−４−１）がこの状態のとき、配信サーバ（Ｓ１）からデータ配信される（ＳＱ２−２２）と、ルータ（２００）ではユーザ端末が増えたことは関係なく、図１３のときと同様にマルチキャスト用コネクション管理テーブル（２００−４−２）を参照し（ＳＱ２−２３）、データをレイヤ２スイッチ（１００）へ転送する（ＳＱ２−２４）。このときにレイヤ２スイッチ（１００）で参照する（ＳＱ２−２５）配信制御テーブル（１００−４−１）には、２つのユーザ端末（Ｈ１−１、Ｈ１−ｎ）情報が参加要求（１００−４−１−５）があり、配信許可（１００−４−１−６）が許可となっている。そのため配信データをコピーし、２つのユーザ端末（Ｈ１−１、Ｈ１−ｎ）へ転送する（ＳＱ−２６）。このとき、配信制御テーブル（１００−４−１）は図６（ａ）のように更新される（ＳＱ２−２７）。

また、ルータ（２００）の定期的なＱｕｅｒｙパケット（ＳＱ２−２８）に対しても図６（ａ）の配信制御テーブル（１００−４−１）が参照される（ＳＱ２−２９）ため、レイヤ２スイッチ（１００）は２つのユーザ端末（Ｈ１−１、Ｈ１−ｎ）宛てにＱｕｅｒｙパケットを送信する（ＳＱ２−３０）。レイヤ２スイッチ（１００）ではある一定時間ユーザ端末（Ｈ１−１、Ｈ１−ｎ）からの応答であるＲｅｐｏｒｔパケット（ＳＱ２−３１）を待ち、その後配信制御テーブル（１００−４−１）を更新し（ＳＱ２−３２）（ただし、この場合は更新処理を行っても情報に変化はない。しかし、ルータ（２００）からの情報と整合性をとるために更新処理を行う。）、ルータ（２００）にＲｅｐｏｒｔパケットを返信し（ＳＱ２−３３）、ルータ（２００）ではテーブルを比較する（ＳＱ２−３４）ことで参加確認とテーブルの整合性を確認する。

これによって、あるグループアドレスへ新たなユーザ端末が同一グループアドレスへの参加要求をした場合、ルータ（２００）の定期的な参加確認よって、配信制御テーブル（１００−４−１）が更新されていれば図１３のＳＱ１−１２〜ＳＱ１−１５が省略できる。

次に、図１５を参照して、ユーザ端末（Ｈ１−１、Ｈ１−ｎ）がグループアドレス２２４．１０．１０．１０のマルチキャストサービスに参加している場合に、さらに参加資格がないユーザ端末（Ｈ１−２）がＰＰＰ接続をし、グループアドレス２２４．１０．１０．１０のマルチキャストサービスへの参加要求をし、配信データが転送されない場合の流れについて説明する。

配信サーバ（Ｓ１）からデータが配信され、ユーザ端末（Ｈ１−１、Ｈ１−ｎ）へデータが配信されるまでの流れ（ＳＱ３−１〜ＳＱ３−５）は前述と同じであるため省略する。またこの時点で更新された（ＳＱ３−６）配信制御テーブル（１００−４−１）は図６（ａ）となる。また、グループアドレス２２４．１０．１０．１０への参加資格がないユーザ端末（Ｈ１−２）が、上述と同様にＰＰＰ接続要求から認証が完了すると（ＳＱ３−７〜ＳＱ３−１２）、ルータ（２００）の配信情報テーブル（２００−４−１）は図９（ｃ）の状態となる。

そこに、ユーザ端末（Ｈ１−２）から参加要求であるＪｏｉｎパケットが送信されると（ＳＱ３−１３）、配信制御テーブル（１００−４−１）は図６（ｂ）に示すように更新される（ＳＱ３−１４）。レイヤ２スイッチ（１００）がこの情報をＪｏｉｎパケットに付与してルータ（２００）に送信し（ＳＱ３−１５）、ルータ（２００）ではテーブル（図６（ｂ）と図９（ｃ））の比較を行う（ＳＱ３−１６）。すると、配信情報テーブル（２００−４−２）には、Ｓｅｓｓｉｏｎ ＩＤ（２００−４−１−５）が２０で、ユーザ端末ＭＡＣアドレス（２００−４−１−６）が００−００−８７−００−２２−２２の組み合わせに対応して、グループアドレス２２４．１０．１０．１０は登録されていないため、ユーザＩＤ（２００−４−１−１）のｕｓｅｒ２＠ｉｓｐ１と、パスワード（２００−４−１−２）のｕｓｅｒ２ｐを用いて、認証・課金サーバ（Ｓ２）へ認証依頼（Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ）を再送信する（Ｆ２−７、ＳＱ３−１７）。その応答であるアクセス許可通知（Ａｃｃｅｓｓ−Ａｃｃｅｐｔ）と合わせて、ユーザ端末（Ｈ１−２）が参加資格を有するグループアドレスが送信され（ＳＱ３−１８、ＳＱ３−１９）、ルータ（２００）はその応答を受信すると配信情報テーブル（２００−４−１）を更新する（ＳＱ３−２０）。認証・課金サーバへの再確認でもユーザ端末（Ｈ１−２）が参加できるグループアドレスがなければ、配信情報テーブル（２００−４−１）は図９（ｃ）のままとなる。

ルータ（２００）は、再確認結果を反映させた情報をＱｕｅｒｙパケットに付与し、レイヤ２スイッチ（１００）へ送信する（ＳＱ３−２１）。そのパケットを受信したレイヤ２スイッチ（１００）では、まず現時点での配信制御テーブル（１００−４−１）を参照し（ＳＱ３−２２）、参加・配信中であるユーザ端末（Ｈ１−１、Ｈ１−ｎ）へＱｕｅｒｙパケットを送信する（ＳＱ３−２３）。ある一定時間、ユーザ端末（Ｈ１−１、Ｈ１−ｎ）からのＲｅｐｏｒｔパケット（ＳＱ３−２４）を待ち、その後ルータ（２００）からの情報を基に配信制御テーブル（１００−４−１）を更新する（ＳＱ３−２５、図６（ｃ））。この場合、具体的には図６（ｂ）では端末（Ｈ１−２）の配信許可（１００−４−１−６）が「不明」となっていたが、ルータ（２００）からの情報にはグループアドレスがないことから、「拒絶」と更新する。更新した配信制御テーブル（１００−４−１）の情報をＲｅｐｏｒｔパケットに付与し、ルータ（２００）へ返信する（ＳＱ３−２６）。ルータ（２００）ではこのパケットを受信すると、テーブル（図６（ｃ）と図９（ｃ））の整合性を確認する（ＳＱ３−２７）。

レイヤ２スイッチ（１００）の配信制御テーブル（１００−４−１）が図６（ｃ）の状態のときに、ユーザ端末（Ｈ１−２）が再度参加要求であるＪｏｉｎパケットを送信した場合（ＳＱ３−２８）でも、配信制御テーブル（１００−４−１）は更新されない。このため、配信サーバ（Ｓ１）からデータが送信されても、参加要求（１００−４−１−５）がありで、かつ配信許可（１００−４−１−６）が許可となっているユーザ端末（Ｈ１−１、Ｈ１−ｎ）だけにしか転送されないようにできる（ＳＱ３−２９〜ＳＱ３−３４）。また、レイヤ２スイッチ（１００）は、配信許可が「拒絶」となっているため、Ｊｏｉｎパケットを破棄する。

ここで、ルータ（２００）が認証・課金サーバ（Ｓ２）に再確認する必要性について説明する。ＰＰＰ接続要求（ＳＱ３−７）の時点では、認証・課金サーバ（Ｓ２）にはユーザ端末（Ｈ１−２）が参加できるグループアドレスがなかったが、認証完了（ＳＱ３−１２）後に認証・課金サーバ（Ｓ２）で保持している情報が更新されて、グループアドレス２２４．１０．１０．１０に参加できるようになったことを想定する。その場合、ユーザ端末（Ｈ１−２）のＰＰＰ接続再要求がなければルータ（２００）の配信情報テーブル（２００−４−１）が更新されなくなってしまう。そのため、ルータ（２００）ではレイヤ２スイッチ（１００）からの情報で、該当するグループアドレスがなかった場合は再確認をする。

さらに、この再確認時にはまだ参加グループはなかったが、その後認証・課金サーバ（Ｓ２）で保持している情報が更新されて、グループアドレス２２４．１０．１０．１０に参加できるようになったことを想定すると、レイヤ２スイッチ（１００）の配信制御テーブル（１００−４−１）の配信許可（１００−４−１−６）は「拒絶」となっているため、何度ユーザ端末（Ｈ１−２）が参加要求をリトライしても、許可されなくなってしまう。そこで、この配信許可（１００−４−１−６）が「拒絶」と更新した場合には、その情報の有効時間（規定回数）を設定して、有効時間（規定回数）を過ぎたら「拒絶」から「不明」へ変更するようにしてもよい。これによってルータ（２００）が認証・課金サーバ（Ｓ２）へ再確認をする契機ができる。

以上のように、ユーザ端末のマルチキャストサービスへの参加要求を把握できないルータ（２００）で許可、拒絶の制御をするのではなく、レイヤ２スイッチ（１００）がルータ（２００）の情報を受け取り、かつ定期的に整合性を確認することで、ユーザ端末から参加要求があるたびにルータ（２００）もしくは認証・課金サーバ（Ｓ２）へ認証確認が不要であり、必要最小限の認証確認で正確にレイヤ２スイッチ（１００）で制御できるようになる。

（マルチキャストサービス課金方法）
本実施の形態が想定するネットワーク構成では、ルータが配信データのユーザ端末への転送制御を行わないため、ユーザ端末がマルチキャストサービスにいつ参加して、いつ離脱するかをルータで把握できない。そのため、例えば特開２００６−１４８７５０号公報に開示された技術のように、ルータが、ユーザ端末の参加と離脱を契機に、課金サーバに対して課金開始通知と課金終了通知を送信することができない。そこで本実施の形態では、配信データのユーザ端末への転送制御を行うレイヤ２スイッチで課金に必要となる情報を収集し、例えばユーザ端末のグループからの離脱を契機にそれらの情報をルータへ送信し、ルータが課金サーバへ転送することで課金を実現させる。

ここで、ユーザ端末のグループからの離脱とは、例えば、ユーザ端末からのＬｅａｖｅパケット受信、定期的な参加確認（Ｑｕｅｒｙ）に対する応答（Ｒｅｐｏｒｔ）なし、ＰＰＰセッション切断の３つがある。なお、これら以外によるものでもよい。以下、これらについて順に説明する。

まず、図１８、図２１を参照して、参加しているユーザ端末（Ｈ１−１）から離脱宣言であるＬｅａｖｅパケットを受信した場合の流れを説明する。
配信サーバ（Ｓ１）からデータが配信され（ＳＱ４−１）、ルータ（２００）はマルチキャスト用コネクション管理テーブル（２００−４−２）を参照し（ＳＱ４−１）、レイヤ２スイッチ（１００）にデータを転送する（ＳＱ４−３）。レイヤ２スイッチ（１００）は配信制御テーブル（例えば図６（ａ））を参照し（ＳＱ４−４）、ユーザ端末（Ｈ１−１、Ｈ１−ｎ）へデータを転送している（ＳＱ４−５）。

ここで、ユーザ端末（Ｈ１−１）からグループアドレス２２４．１０．１０．１０からの離脱宣言であるＬｅａｖｅパケットが送信される（ＳＱ４−７）。Ｌｅａｖｅパケットは、例えば、グループアドレスと端末ＭＡＣアドレスを含む。レイヤ２スイッチ（１００）のプロセッサ（１００−３）では、ユーザ端末からＬｅａｖｅパケットを受信する（Ｆ１−５−１）と、図２１に示すフローで処理をすすめる。

まず、レイヤ２スイッチ（１００）は、配信制御テーブル（１００−４−１）のユーザ端末（Ｈ１−１）のＭＡＣアドレスに対応する配信終了時刻（１００−４−１−８）に現在時刻を記録する（Ｆ１−５−２、ＳＱ４−８、図２２（ａ））。次に、グループアドレス２２４．１０．１０．１０に参加しているユーザ端末が他にあるかを確認し（Ｆ１−５−３）、他のユーザ端末（Ｈ１−ｎ）が参加している場合にはＪｏｉｎパケットに配信制御テーブル（１００−４−１）の情報を付与し、ルータ（２００）へ送信する（Ｆ１−５−４、ＳＱ４−９）。送信後、離脱したユーザ端末（Ｈ１−１）の情報を配信制御テーブル（１００−４−１）から削除する（Ｆ１−５−６、ＳＱ４−１０、図２２（ｂ））。

配信終了（１００−４−１−８）に時刻が記録されている情報をルータ（２００）が受信すると、配信情報テーブル（２００−４−１）の対応するユーザ情報のグループアドレス（２００−４−１−３）を削除し（ＳＱ４−１１、図２３）、レイヤ２スイッチ（１００）から受け取った、配信開始／終了時刻、トラヒック量、グループアドレスとユーザＩＤ（２００−４−１−１）を課金情報として認証・課金サーバ（Ｓ２）へ送信する（Ｆ２−３、ＳＱ４−１２）。配信業者は認証・課金サーバに残された情報から課金を実現できる。

また、ユーザ端末（Ｈ１−１）が離脱後、さらにユーザ端末（Ｈ１−ｎ）がＬｅａｖｅパケットを送信する（ＳＱ４−１３）と、レイヤ２スイッチ（１００）では同様に配信制御テーブル（１００−４−１）を更新する（ＳＱ４−１４）。この場合、他にグループアドレス２２４．１０．１０．１０に参加している他ユーザ端末はないため、Ｌｅａｖｅパケットに配信制御テーブル（１００−４−１）の情報を付与し送信する（Ｆ１−５−５、ＳＱ４−１５）。送信後、配信制御テーブル（１００−４−１−）からユーザ端末（Ｈ１−ｎ）の情報を削除する（Ｆ１−５−６、ＳＱ４−１６）。

ルータ（２００）は、レイヤ２スイッチ（１００）からＬｅａｖｅパケットを受信すると（ＳＱ４−１５）、配信情報テーブル（２００−４−１）のグループアドレスを削除し（ＳＱ４−１７）、配信サーバ（Ｓ２）に対して配信停止要求であるＰＩＭ Ｌｅａｖｅを送信する（ＳＱ４−１８）。そして、最初に離脱したユーザ端末（Ｈ１−１）のときと同様に、ユーザ端末（Ｈ１−ｎ）の課金情報を認証・課金サーバへ送信する（ＳＱ４−１９）。

次に、図１９を参照して、定期的な参加確認（Ｑｕｅｒｙ）に対するユーザ端末（Ｈ１−１）の応答（Ｒｅｐｏｒｔ）がなかった場合について説明する。
まず、ルータ（２００）から参加確認であるＱｕｅｒｙパケットがレイヤ２スイッチ（１００）送信される（ＳＱ５−１）と、そのパケットを受信したレイヤ２スイッチ（１００）は配信制御テーブル（１００−４−１）を参照し（ＳＱ５−２）、ユーザ端末（Ｈ１−１、Ｈ１−ｎ）へＱｕｅｒｙパケットを送信する（ＳＱ５−３）。レイヤ２スイッチ（１００）ではある一定時間内にユーザ端末（Ｈ１−１、Ｈ１−ｎ）から参加継続を示すＲｅｐｏｒｔパケットが返信されない場合（ＳＱ５−４）、端末が離脱したと判断し、Ｌｅａｖｅパケットを受信したときと同様の処理を行う。例えば、レイヤ２スイッチ（１００）は、配信制御テーブル（１００−４−１）を更新し（ＳＱ５−５、図２２（ａ））、その情報をルータ（２００）へ送信し（ＳＱ５−６）、ユーザ情報を削除する（ＳＱ５−７、図２２（ｂ））。ルータ（２００）でも同様に課金情報を認証・課金サーバ（Ｓ２）へ送信することで、ユーザ端末から参加確認（Ｑｕｅｒｙ）に対する応答（Ｒｅｐｏｒｔ）がなかった場合でも、課金が実現できる（ＳＱ５−８、ＳＱ５−９）。

ただし、レイヤ２スイッチ（１００）がＲｅｐｏｒｔパケットを待っている時間や、複数回連続でＲｅｐｏｒｔパケットが返信されなかった場合に離脱と判断するなど、通常のマルチキャストルータのような機能をレイヤ２スイッチ（１００）持たせることでサービス内容や課金方法、ユーザ端末数などの環境に対応できる。

次に、図２０を参照して、ＰＰＰセッション切断時の場合について説明する。
本実施の形態の想定するネットワーク構成では、ＰＰＰセッションが切断された場合、そのセッション上で行っているマルチキャストサービスも継続できなくなる。
ユーザ端末（Ｈ１−１）とルータ（２００）間のＰＰＰセッションが切断されると（ＳＱ６−１）、ルータ（２００）は配信情報テーブル（２００−４−１）を図２３のように更新し（ＳＱ６−２）、更新した後の情報をＱｕｅｒｙパケットに付与しレイヤ２スイッチ（１００）へ送信する（ＳＱ−６−３）。

レイヤ２スイッチ（１００）では、ＰＰＰセッションが切断されたユーザ端末（Ｈ１−１）は配信許可（１００−４−１−６）が拒絶であると判断し、配信制御テーブル（１００−４−１）の配信終了（１００−４−１−８）時刻を記録し（ＳＱ６−４、図２２（ａ））、その情報をルータへ送信する（ＳＱ６−５）。その後、配信制御テーブル（１００−４−１）からユーザ端末（Ｈ１−１）の情報を削除する（ＳＱ６−６、図２２（ｂ））。このとき、レイヤ２スイッチ（１００）では本来であれば、ルータ（２００）からＱｕｅｒｙパケットを受信すると、配信制御テーブル（１００−４−１）を更新する前に配信制御テーブル（１００−４−１）を参照してユーザ端末（Ｈ１−１、Ｈ１−ｎ）へＱｕｅｒｙパケットを送信する。しかし、参加中のユーザ端末（Ｈ１−１）がルータ（２００）のＱｕｅｒｙパケットにより拒絶となった場合には、配信制御テーブル（１００−４−１）を更新しルータ（２００）へ情報を送信するようにしてもよい。

以上のように、ルータ（２００）ではなくレイヤ２スイッチ（１００）で課金に必要な情報を収集し、ルータ（２００）を介して認証・課金サーバへ送信することで課金を実現できる。

また、ルータ（２００）の配信情報テーブル（２００−４−１）のグループアドレス（２００−４−１−３）に有効期限を設定し、その情報も合わせてレイヤ２スイッチ（１００）へ送信することで、レイヤ２スイッチ（１００）ではその有効期限が切れた場合に配信データの転送をやめるなど、時間によるプリペイド式課金も可能となる。さらに、有効期限のかわりにトラヒック量を設定し、そのトラヒック量を超えた場合に転送をやめるなどトラヒック量によるプリペイド式課金も可能となる。

２． 第２の実施の形態
第２の実施の形態では、認証を伴う配信データの制御については第１の実施の形態と同様に行う。
（マルチキャストサービス課金方法）
図２４に、第２の実施の形態による課金動作シーケンスを示す。
第１の実施の形態では、ユーザ端末からのＩＧＭＰパケットをレイヤ２スイッチで終端していたが、第２の実施の形態では、レイヤ２スイッチは終端はせずにスヌーピングする。

図２４を参照して、グループアドレス２２４．１０．１０．１０のマルチキャストサービスへの参加資格を有するユーザ端末（Ｈ１−１）が配信サーバ（Ｓ１）からの配信データを受信し、離脱宣言（Ｌｅａｖｅ）により離脱した場合の流れについて説明する。

グループアドレス２２４．１０．１０．１０への参加資格を有するユーザ端末（Ｈ１−１）が、ＰＰＰ接続要求をし、ルータ（２００）から認証完了通知を受信するまでの動作（ＳＱ７−１〜ＳＱ７−５）は第１の実施の形態の場合と同じである。ＰＰＰ接続完了後、ユーザ端末（Ｈ１−１）がＪｏｉｎパケットを送信すると（ＳＱ７−６）、レイヤ２スイッチ（１００）はパケットの中身をスヌーピングし、そのパケットをルータ（２００）へ転送する。Ｊｏｉｎパケットは、例えば、グループアドレスとユーザ端末のＭＡＣアドレスとを含む。レイヤ２スイッチ（１００）は、スヌーピングした情報から図１６のフローに従い、第１の実施の形態と同様に処理をすすめる（ＳＱ７−１０〜ＳＱ７−１３）。

一方、レイヤ２スイッチ（１００）で転送されたパケットをルータ（２００）が受信すると、配信情報テーブル（２００−４−１）を参照し（ＳＱ７−７）、課金開始通知（Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ−Ｓｔａｒｔ）を認証・課金サーバ（Ｓ２）へ送信する（ＳＱ７−８）。課金開始通知は、例えば、グループアドレスとユーザ端末のＭＡＣアドレスとを含む。認証・課金サーバ（Ｓ２）では課金開始通知を受信した時刻を、例えば端末のＭＡＣアドレス毎に記録し、ルータ（２００）へ応答（Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ−Ｒｅｓｐｏｎｓｅ）を返す（ＳＱ７−９）。また、ルータ（２００）は、配信サーバ（Ｓ１）へ配信要求（ＰＩＭ Ｊｏｉｎ）を送信する（ＳＱ７−１４）。

ルータ（２００）はマルチキャスト用コネクション（ＬＭ）を介してレイヤ２スイッチ（１００）からパケットを受信すると図１７のフローに従い、第１の実施の形態と同様に処理をすすめ、各装置で管理するユーザ情報の整合性をとる（ＳＱ７−１５〜ＳＱ７−１７）。ルータ（２００）からの配信要求（ＳＱ７−１４）により、第１の実施の形態と同様に配信データがユーザ端末（Ｈ１−１）へ転送される（ＳＱ７−２０〜ＳＱ７−２４）。なお、本実施の形態では、ルータ（２００）はユーザ端末からＪｏｉｎを受信しているが、例えば、レイヤ２スイッチ（１００）との間に確立されたマルチキャスト用のコネクションを介して、配信データをレイヤ２スイッチ（１００）に送信し、レイヤ２スイッチ（１００）がデータをコピーしてユーザ端末（Ｈ１−１）に配信するようにしてもよい。

グループアドレス２２４．１０．１０．１０へ参加中であるユーザ端末（Ｈ１−１）が、Ｌｅａｖｅパケットを送信すると（ＳＱ７−２５）、レイヤ２スイッチ（１００）はパケットの中身をスヌーピングし、そのパケットをルータ（２００）へ転送する。Ｌｅａｖｅパケットは、例えば、グループアドレスとユーザ端末のＭＡＣアドレスとを含む。レイヤ２スイッチ（１００）は、スヌーピングした情報から図２１のフローに従い、第１の実施の形態と同様に処理をすすめる（ＳＱ７−２６〜ＳＱ７−２８）。

一方、レイヤ２スイッチ（１００）で転送されたＬｅａｖｅパケットをルータ（２００）が受信すると、配信情報テーブル（２００−４−１）を更新し（ＳＱ７−２９）、課金終了通知（Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ−Ｓｔｏｐ）を認証・課金サーバ（Ｓ２）へ送信する（ＳＱ７−３１）。課金終了通知は、例えば、グループアドレスとユーザ端末のＭＡＣアドレスとを含む。また、ルータ（２００）は、配信サーバ（Ｓ１）へ配信停止要求（ＰＩＭ Ｌｅａｖｅ）を送信する（ＳＱ７−３０）。認証・課金サーバ（Ｓ２）では課金終了通知を記録し、ルータ（２００）へ応答（Ａｃｃｅｓｓ−Ｒｅｑｕｅｓｔ−Ｒｅｓｐｏｎｓｅ）を返す（ＳＱ７−３２）。

以上により、認証・課金サーバ（Ｓ２）では、ユーザ端末（Ｈ１−１）がグループアドレス２２４．１０．１０．１０に参加した時刻と、離脱した時刻を把握することができ配信業者はマルチキャストサービスの課金が実現できる。例えば、ユーザ端末毎の課金、グループアドレスに応じた課金が実現できる。

また、ルータ（２００）が課金終了通知送信するときに、レイヤ２スイッチ（１００）から受信した（ＳＱ７−２７）課金情報を付与することでより正確な課金や従量課金が実現できる。

本発明は、例えば、ＩＰｖ６、ＭＬＤ等の各種方式に適用することができる。また、本発明は、レイヤ２スイッチに限らず、各手段を実装でき、ルータとユーザ端末間に配置されるＢＡＳ（Ｂｒｏａｄｂａｎｄ Ａｃｃｅｓｓ Ｓｅｒｖｅｒ）のような通信装置であれば装置は選ばない。さらに、本発明は、ルータ以外にも、マルチキャスト配信をするものであれば、適宜のパケット転送装置を採用することができる。

本実施の形態が想定するネットワーク構成図。 従来技術を用いた場合のパケットの流れを示す図。 本実施の形態を用いた場合のパケットの流れを示す図。 本実施の形態のレイヤ２スイッチの内部構成の一例を示す図。 レイヤ２スイッチの配信制御テーブルの一例を示す図（１）。 レイヤ２スイッチの配信制御テーブルの一例を示す図（２）。 レイヤ２スイッチのマルチキャスト用コネクション管理テーブルの一例を示す図。 本実施の形態のルータの内部構成の一例を示す図。 ルータの配信情報テーブルの一例を示す図（１）。 ルータのマルチキャスト用コネクション管理テーブルの一例を示す図。 ユーザ端末とルータ間で送受信されるマルチキャストパケット以外のパケット、及び、マルチキャストパケットの構成例。 認証・課金サーバのユーザ管理テーブルの一例を示す図。 ユーザ端末（Ｈ１−１）のＰＰＰ接続要求からマルチキャストのデータを受信するまでの動作シーケンスを示す図。 図１３の状態から、ユーザ端末（Ｈ１−ｎ）のＰＰＰ接続要求からマルチキャストのデータを受信するまでの動作シーケンスを示す図。 図１４の状態から、ユーザ端末（Ｈ１−２）のＰＰＰ接続要求からマルチキャスト参加要求が拒絶されるまでの動作シーケンスを示す図。 レイヤ２スイッチがユーザ端末からパケットを受信した場合の処理フローを示す図。 ルータがレイヤ２スイッチからＩＧＭＰパケットを受信した場合の処理フローを示す図。 ユーザ端末（Ｈ１−１、Ｈ１−ｎ）がＬｅａｖｅパケットを送信して離脱した場合の課金動作シーケンスを示す図。 ユーザ端末（Ｈ１−１）がＲｅｐｏｒｔパケットを返信しなくなり、離脱した場合の課金動作シーケンスを示す図。 ユーザ端末（Ｈ１−１）がＰＰＰセッション切断により離脱した場合の課金動作シーケンスを示す図。 レイヤ２スイッチがユーザ端末からＬｅａｖｅパケットを受信した場合の処理フローを示す図。 レイヤ２スイッチの配信制御テーブルの一例を示す図（３）。 ルータの配信情報テーブルの一例を示す図（２）。 第２の実施の形態の手段を用いた場合の課金動作シーケンスを示す図。

符号の説明

Ｈ１−１〜Ｈ１−ｎ、Ｈ２−１〜Ｈ２−ｎ：ユーザ端末
Ｓ１：配信サーバ
Ｓ２：認証・課金サーバ
１００、１０１：レイヤ２スイッチ
２００：ルータ
３００：インターネット網
ＮＷ１、ＮＷ２：アクセスネットワーク
ＮＷ３：ＩＳＰ網
ＬＰ１〜ＬＰｎ：ＰＰＰコネクション
ＬＭ：マルチキャスト用コネクション
１００−１−１〜１００−１−ｎ：回線インタフェース
１００−２：回線インタフェース制御部
１００−３：プロセッサ
１００−４：メモリ
１００−４−１：配信制御テーブル
１００−４−２：マルチキャスト用コネクション管理テーブル
１００−４−３：プログラム
１００−５：制御端末インタフェース
１００−６：制御端末
１００−４−１−１：グループアドレス
１００−４−１−２：回線インタフェース
１００−４−１−３：Ｓｅｓｓｉｏｎ ＩＤ
１００−４−１−４：ユーザ端末ＭＡＣアドレス
１００−４−１−５：参加要求（あり／なし）
１００−４−１−６：配信許可（許可／拒絶／不明）
１００−４−１−７：配信開始（時刻）
１００−４−１−８：配信終了（時刻）
１００−４−１−９：トラヒック（Ｍｂｙｔｅ）
１００−４−２−１：グループアドレス
１００−４−２−２：回線インタフェース
１００−４−２−３：Ｓｅｓｓｉｏｎ ＩＤ
１００−４−２−４：ルータＭＡＣアドレス
２００−１−１〜２００−１−ｎ：回線インタフェース
２００−２：回線インタフェース制御部
２００−３：プロセッサ
２００−４：メモリ
２００−４−１：配信情報テーブル
２００−４−２：マルチキャスト用コネクション管理テーブル
２００−４−３：プログラム
２００−５：制御端末インタフェース
２００−６：制御端末
２００−４−１−１：ユーザＩＤ
２００−４−１−２：パスワード
２００−４−１−３：グループアドレス
２００−４−１−４：回線インタフェース
２００−４−１−５：Ｓｅｓｓｉｏｎ ＩＤ
２００−４−１−６：ユーザ端末ＭＡＣアドレス
２００−４−２−１：グループアドレス
２００−４−２−２：回線インタフェース
２００−４−２−３：Ｓｅｓｓｉｏｎ ＩＤ
２００−４−２−４：レイヤ２スイッチＭＡＣアドレス
３００：送信先ＭＡＣアドレス
３０１：送信元ＭＡＣアドレス
３０２：ＰＰＰｏＥヘッダ情報
３０３：ＰＰＰヘッダ情報
３０４：送信元ＩＰアドレス
３０５：送信先ＩＰアドレス
３０６：データ領域
３０７：ＩＧＭＰヘッダ情報
３０８：データ領域

Claims (8)

1. 複数のユーザ端末を終端し、受信したマルチキャストデータをコピーして前記ユーザ端末へ転送するレイヤ２スイッチと、
   前記レイヤ２スイッチを介して複数の前記ユーザ端末とポイント トゥ ポイント接続され、マルチキャストグループへの参加要求に対し、該参加要求の送信元へマルチキャストデータを送信するルータと、
   前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを前記ルータに出力するサーバと
   を備え、
   前記ユーザ端末と前記ルータが、前記レイヤ２スイッチを介してＰｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ（ＰＰＰ）で接続され、
   前記レイヤ２スイッチは、
   グループアドレスと、前記ユーザ端末の端末識別情報と、配信許可及び配信拒絶のいずれかを示す情報とを含むエントリが記憶される配信制御テーブル
   を有し、
   前記ルータは、前記ユーザ端末からポイント トゥ ポイント接続の接続要求を受信すると、前記サーバから前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを取得し、
   前記ルータは、受信されたグループアドレスと、前記ユーザ端末の端末識別情報とを対応して記憶し、
   前記レイヤ２スイッチは、前記ユーザ端末から、予め定められたグループアドレスと該ユーザ端末の端末識別情報を含み、該ユーザ端末を送信元としたマルチキャストグループへの第１の参加要求を受信すると、該第１の参加要求を終端し、及び、前記配信制御テーブルに該グループアドレスと該端末識別情報とを対応して記憶し、
   前記レイヤ２スイッチは、受信したグループアドレスと端末識別情報を含み、自装置を送信元とした第２の参加要求を前記ルータに送信し、
   前記ルータは、第２の参加要求に含まれるグループアドレス及び端末識別情報と、記憶されたグループアドレス及び端末識別情報とを比較し、一致するものが記憶されていれば配信許可を示し、及び、記憶されていなければ配信拒絶を示す通知を前記レイヤ２スイッチに送信し、
   前記レイヤ２スイッチは、該通知に従い、該グループアドレスと該端末識別情報とに対応して、配信許可又は配信拒絶を示す情報を前記配信制御テーブルに記憶し、
   前記レイヤ２スイッチは、前記レイヤ２スイッチを送信元とする第２の参加要求に対して、グループアドレスを含むマルチキャストデータを該第２の参加要求の送信元であるレイヤ２スイッチに送信する前記ルータから、グループアドレスを含む該マルチキャストデータを受信し、前記配信制御テーブルを参照して、該グループアドレスに対応して配信許可を示す情報が記憶されたエントリの端末識別情報に従い、受信されたマルチキャストデータ及び／又はコピーしたマルチキャストデータをひとつ又は複数の前記ユーザ端末に送信するネットワークシステム。
2. 前記レイヤ２スイッチは、端末識別情報毎に、マルチキャストデータの配信開始時刻と配信終了時刻を記憶し、
   前記ユーザ端末が、マルチキャストグループから離脱したと判断すると、該ユーザ端末の端末識別情報と配信開始時刻と配信終了時刻を前記ルータに送信し、
   前記ルータは、配信開始時刻と配信終了時刻に基づく課金情報を、課金の管理を行う課金サーバに送信する請求項１に記載のネットワークシステム。
3. 前記レイヤ２スイッチは、端末識別情報毎に、マルチキャストデータを配信したトラヒック量を記憶し、
   前記ユーザ端末が、マルチキャストグループから離脱したと判断すると、該ユーザ端末の端末識別情報とトラヒック量を前記ルータに送信し、
   前記ルータは、トラヒック量に基づく課金情報を、課金の管理を行う課金サーバに送信する請求項１に記載のネットワークシステム。
4. 前記レイヤ２スイッチは、前記ユーザ端末がマルチキャストグループから離脱したことを、
   該ユーザ端末から離脱宣言を受信したこと、又は、該ユーザ端末に参加確認を送信し、該参加確認に対する応答が所定時間内に受信されなかったこと、又は、前記ルータから該ユーザ端末とのポイント トゥ ポイント接続が切断された通知を受けたことにより判断する請求項２又は３に記載のネットワークシステム。
5. 前記ルータは、
   グループアドレスに対応して、前記レイヤ２スイッチとのコネクションを識別するためのコネクション識別情報が記憶されるコネクション管理テーブル
   を有し、
   前記レイヤ２スイッチと前記ルータの間で、マルチキャストデータを通信するためのコネクションを確立し、
   前記ルータは、前記コネクション管理テーブルに、グループアドレスとコネクション識別情報を対応して記憶し、
   前記ルータは、グループアドレスを含むマルチキャストデータを受信すると、前記コネクション管理テーブルを参照して、該グループアドレスに対応するコネクション情報に従い、確立されたマルチキャストデータを通信するためのコネクションを介して、前記レイヤ２スイッチにマルチキャストデータを送信する請求項１に記載のネットワークシステム。
6. 前記ルータは、前記サーバから受信されたグループアドレスに対応して前記ユーザ端末の端末識別情報が記憶される配信情報テーブルを有し、
   前記ルータは、前記配信情報テーブルの各情報を前記レイヤ２スイッチに送信し、
   前記レイヤ２スイッチは、前記配信制御テーブルの各情報を前記ルータに送信し、
   前記レイヤ２スイッチの前記配信制御テーブルと、前記ルータの前記配信情報テーブルとで情報の整合を取ることを特徴とする請求項１に記載のネットワークシステム。
7. 前記ルータは、第２の参加要求に含まれるグループアドレス及び端末識別情報と一致するグループアドレス及び端末識別情報が記憶されていない場合、前記サーバから前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを再度取得して、新たに取得されたグループアドレスを用いて、再度前記比較を行う請求項１に記載のネットワークシステム。
8. 複数のユーザ端末を終端し、受信したマルチキャストデータをコピーして前記ユーザ端末へ転送するレイヤ２スイッチと、
   前記レイヤ２スイッチを介して複数の前記ユーザ端末とポイント トゥ ポイント接続され、マルチキャストグループへの参加要求に対し、該参加要求の送信元へマルチキャストデータを送信するルータと、
   前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを前記ルータに出力するサーバと
   を備え、
   前記ユーザ端末と前記ルータが、前記レイヤ２スイッチを介してＰｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ（ＰＰＰ）で接続され、
   前記レイヤ２スイッチは、
   グループアドレスと、前記ユーザ端末の端末識別情報と、配信許可及び配信拒絶のいずれかを示す情報と、参加要求の受信及び未受信のいずれかを示す情報とを含むエントリが記憶される配信制御テーブル
   を有し、
   前記ルータは、前記ユーザ端末からポイント トゥ ポイント接続の接続要求を受信すると、前記サーバから前記ユーザ端末が参加できるマルチキャストグループのグループアドレスを取得し、
   前記ルータは、受信されたグループアドレスと、前記ユーザ端末の端末識別情報とを含む通知を前記レイヤ２スイッチに送信し、
   前記レイヤ２スイッチは、該通知に含まれるグループアドレス及び端末識別情報と、配信許可を示す情報とを対応して前記配信制御テーブルに記憶し、
   前記レイヤ２スイッチは、前記ユーザ端末から予め定められたグループアドレスと該ユーザ端末の端末識別情報を含み、該ユーザ端末を送信元としたマルチキャストグループへの第１の参加要求を受信すると、該第１の参加要求を終端し、及び、前記配信制御テーブルの該当するグループアドレスと端末識別情報に対応して、参加要求の受信を示す情報を記憶し、
   前記レイヤ２スイッチは、受信したグループアドレスを含み、自装置を送信元とした第２の参加要求を前記ルータに送信し、
   前記ルータは、前記レイヤ２スイッチを送信元とする第２の参加要求に対して、グループアドレスを含むマルチキャストデータを、第２の参加要求の送信元であるレイヤ２スイッチに送信し、
   前記レイヤ２スイッチは、前記ルータからグループアドレスを含むマルチキャストデータを受信し、前記配信制御テーブルを参照して、該グループアドレスに対応して参加要求の受信を示す情報及び配信許可を示す情報が記憶されたエントリの端末識別情報に従い、受信されたマルチキャストデータ及び／又はコピーしたマルチキャストデータをひとつ又は複数の前記ユーザ端末に送信するネットワークシステム。

Images