(57)【要約】【課題】  ＰＬＣや無線ＬＡＮ等の通信速度の変動が激しいモデムを使用する場合でも、映像系データ等の大容量のデータを適切にマルチキャストすることができるマルチキャスト通信システムを提供する。【解決手段】  本発明は、ＩＰ通信が可能な複数のモデム３，８を備え、そのうちの一つ３が、ＩＰプロトコルに準拠するマルチキャストパケット３０を上位ネットワークから受信可能であるマルチキャスト通信システム１である。  一つのモデム３は、上位ネットワーク６側から受信したマルチキャストパケット３０をユニキャストパケット３１に変換して他のモデム８に送信し、この変換されたユニキャストパケット３１を受信した他のモデム８が、当該変換されたユニキャストパケット３１を元のマルチキャストパケット３２に戻して、当該マルチキャストパケット３２を必要とする端末装置９に送信する。【選択図】      図３
2008187626.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰ通信が可能な複数のモデムを備え、そのうちの一つが、ＩＰプロトコルに準拠するマルチキャストパケットを上位ネットワークから受信可能であるマルチキャスト通信システムであって、
前記一つのモデムが、上位ネットワーク側から受信した前記マルチキャストパケットをユニキャストパケットに変換して他のモデムに送信し、この変換されたユニキャストパケットを受信した他のモデムが、当該変換されたユニキャストパケットを元の前記マルチキャストパケットに戻して、前記マルチキャストパケットを必要とする端末装置に送信することを特徴とするマルチキャスト通信システム。
【請求項２】
前記一つのモデムにおけるパケット変換は、前記マルチキャストパケットの宛先ＭＡＣアドレスを前記他方のモデムのＭＡＣアドレスに書き換えるアドレス変換である請求項１に記載のマルチキャスト通信システム。
【請求項３】
前記他のモデムにおけるパケット変換は、前記変換されたユニキャストパケットに含まれるＩＰアドレスに基づいて前記宛先ＭＡＣアドレスをマルチキャスト用符号に書き換えるアドレス変換である請求項２に記載のマルチキャスト通信システム。
【請求項４】
前記他のモデムは、前記一つのモデムから受信する前記ユニキャストパケットが、当該一つのモデムによって変換されたものか否かを判定する請求項１〜３のいずれか１項に記載のマルチキャスト通信システム。
【請求項５】
前記一つのモデムは、前記端末装置から送信されたレポートに記載されているＩＰマルチキャストアドレスに基づいて、前記他のモデムに送信すべき前記マルチキャストパケットの種類を特定する管理テーブルを動的に作成する請求項１〜４のいずれか１項に記載のマルチキャスト通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Internet Protocol）を通信プロトコルとするネットワークにおけるマルチキャスト通信システムに関するものである。
【背景技術】
【０００２】
ＩＰを用いたマルチキャスト通信（以下、ＩＰマルチキャストと記載することがある。）においては、多数のホストに対してルータを経由してパケットデータを送信するが、その多数のホストとルータの間のプロトコルとして、ＩＧＭＰ（Internet Group Management Protocol：IPv4の場合）やＭＬＤ（Multicast Listening Discovery：IPv6の場合）等の受信側ベースのプロトコルが使用される。
【０００３】
受信側ベースの上記マルチキャスト通信のプロトコルにおいては、あるホストが所定のマルチキャストグループに参加したい場合、このホストは、その参加したいマルチキャストグループに対する参加要求（Report）をルータに送信する。この参加要求を受信したルータは、参加要求があった送信元のホストの参加登録を行う。
【０００４】
また、ルータから参加確認を表すデータ（Query）がマルチキャストグループに参加登録されている全てのホストに定期的に送信されており、そのマルチキャストグループに継続して参加する場合、各ホストは、送信されてきた参加確認に応答する旨の参加中応答をルータに対して送信するようになっている。
この結果、ルータは、送信されてきた参加中応答を受信確認することにより、マルチキャストグループに参加している全てのホストの参加状態を把握することができる（特許文献１参照）。
【０００５】
【特許文献１】特開２００４−２８２１６１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
一方、ＩＰ通信が可能なサブネットワークとして、電力線通信（ＰＬＣ：Power Line Communication）や無線ＬＡＮがあるが、これらは信号減衰やノイズ等の影響によって通信速度が変動するという特質があるため、上記マルチキャスト通信を行うパケットに対しては、ノイズ等の影響を受け難い変調方式を使用することで、様々な通信環境のモデムに対しても同時に通信できるようにしている。
例えば、ＰＬＣシステムでは、電力線の分岐形態及び分岐長さの相違や外来ノイズ等の原因により、周波数の減衰特性が一様ではなく、通信を行う２点間ごとに減衰特性に大きな差が発生することが多い。
【０００７】
そのため、複数のノードに対してマルチキャストやブロードキャストでの同時通信が必要な場合には、減衰特性の影響を最小限に抑えるために、通信速度を大幅に落としているのが現状である。一般的には、ユニキャストで２００Ｍｂｐｓの性能を持ったＰＬＣモデムであっても、ＰＬＣ部でマルチキャストやブロードキャストをした場合には、冗長性を上げるために数Ｍｂｐｓまで伝送レートが落ちる。
【０００８】
このように、ＰＬＣシステムでは、平衡度の悪い電力線を伝送路として採用しているため、分岐や反射等の影響により周波数ごとの信号減衰の特性が大きく違っている。またこれらは、電力線のどの２点間（ノードの接続点間）を使って測定するかによっても大きく変化するし、時間経過に伴って経路や機器の接続構成が変わることなどによっても変化する。
【０００９】
しかし、昨今のＩＰ放送などの映像系の伝送においては、複数のノードに対して同時に同じデータを送信することになる。そして、ＰＬＣシステムでは、マルチキャストで低速で伝送する場合、マルチキャスト時はレートが著しく落ちる（１０分の１以下になることもある。）ため、例えば映像配信等の大容量のデータの場合には、そのデータをマルチキャストで伝送できないことがある。
【００１０】
本発明は、このような実情に鑑み、ＰＬＣや無線ＬＡＮ等の通信速度の変動が激しいモデムを使用する場合でも、映像系データ等の大容量のデータを適切にマルチキャストすることができるマルチキャスト通信システムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
本発明のマルチキャスト通信システムは、ＩＰ通信が可能な複数のモデムを備え、そのうちの一つが、ＩＰプロトコルに準拠するマルチキャストパケットを上位ネットワークから受信可能であるマルチキャスト通信システムであって、前記一つのモデムが、上位ネットワーク側から受信した前記マルチキャストパケットをユニキャストパケットに変換して他のモデムに送信し、この変換されたユニキャストパケットを受信した他のモデムが、当該変換されたユニキャストパケットを元の前記マルチキャストパケットに戻して、前記マルチキャストパケットを必要とする端末装置に送信することを特徴とする。
【００１２】
上記のマルチキャスト通信システムによれば、複数のモデムのうちの一つが、上位ネットワーク側から受信したマルチキャストパケットをユニキャストパケットに変換して他のモデムに送信し、他のモデムが、その変換されたユニキャストパケットを元のマルチキャストパケットに戻して端末装置に送信するので、当該一対のモデム同士の間においては、マルチキャスト通信ではなくユニキャスト通信が行われる。
このため、これらの一対のモデムが、信号減衰やノイズ等の影響で通信速度が変動し易いもの（ＰＬＣや無線ＬＡＮ等）であっても、それらのモデム間ではユニキャスト通信を行うことで伝送速度を確保することができ、映像系データ等の大容量のデータを適切にマルチキャストすることができる。
【００１３】
本発明のマルチキャスト通信システムにおいて、前記一つのモデムにおけるパケット変換は、具体的には、前記マルチキャストパケットの宛先ＭＡＣアドレスを前記他方のモデムのＭＡＣアドレスに書き換えるアドレス変換によって行うことができる。
この場合、マルチキャストパケットからユニキャストパケットへのパケット変換をＭＡＣアドレスのアドレス変換によって行うので、前記他のモデムにおけるパケット変換を、前記ユニキャストパケットに含まれるＩＰアドレスに基づいて前記ＭＡＣアドレスをマルチキャスト用符号に書き換えるアドレス変換を行うだけで足りる。
【００１４】
なお、本発明の通信システムでは、前記他のモデムが、前記一つのモデムで変換されたユニキャストパケットを元のマルチキャストパケットに戻すことから、当該他のモデムは、前記一つのモデムから受信する前記ユニキャストパケットが、当該一つのモデムによって変換されたものか否かを判定する必要がある。
【００１５】
また、本発明の通信システムにおいて、前記一つのモデムは、前記端末装置から送信されたレポートに記載されているＩＰマルチキャストアドレスに基づいて、前記他のモデムに送信すべき前記マルチキャストパケットの種類を特定する管理テーブルを動的に作成するものであることが好ましい。
この場合、一つのモデムが上記管理テーブルを動的に作成するので、要求・不要球の変化が激しいマルチキャストパケットを自動的に集中管理することができる。
【発明の効果】
【００１６】
以上の通り、本発明によれば、ＰＬＣや無線ＬＡＮ等の通信速度の変動が激しいモデムを使用する場合でも、映像系データ等の大容量のデータを適切にマルチキャストすることができる。
【発明を実施するための最良の形態】
【００１７】
以下、図面に基づいて、本発明の実施形態を説明する。
〔システムの全体構成〕
図１は、本発明に係るマルチキャスト通信システムの一例の全体構成を示し、本実施形態のシステム１は、親機モデム３と子機モデム８とからなる電力線通信システム（以下、ＰＬＣシステムという。）をサブネットワークとして備えている。このＰＬＣシステムは、マンション等の集合住宅（ユーザ宅）が予め有する、当該住宅に電力供給を行う電力線２を通信に利用するものである。
【００１８】
上記電力線２の屋外側端には、親機モデム３が接続されており、このモデム３はメディアコンバータ等よりなる光回線インタフェース４とともに屋外に設置可能であるが、日本では、今のところ屋内の設置が義務づけられている。このインタフェース４は光ファイバ５を介してインターネット等よりなる上位ネットワーク６に通じており、上位ネットワーク６はケーブルテレビの放送局等のビデオソース７と繋がっている。
このため、ビデオソース７からの映像系のデータは、上位ネットワーク６を介して光回線インタフェース４に至り、このインタフェース４によって光電変換され、イーサネット（登録商標：以下同様）信号となって親機モデム３に送信されるようになっている。
【００１９】
ユーザ宅での通信媒体網を構成する電力線２には、前記親機モデム３と複数の子機モデム８が接続されている。電力線２に接続された親機モデム３と子機モデム８は、イーサネット信号をＯＦＤＭ方式によって電力線２に重畳可能な信号（ＰＬＣ信号）に変復調するＰＬＣモデムよりなり、各子機モデム８のイーサネット側には、イーサネット対応のテレビ受像用端末装置（セットトップボックス）９やパーソナルコンピュータ１０が接続されている。
なお、本実施形態の各モデム３，８は、例えばＨｏｍｅＰｌｕｇ ＡＶに準拠するＰＬＣ通信が可能であり、従って、ユニキャスト通信の場合にはモデム３，８間で２００Ｍｂｐｓの通信速度を確保できる。
【００２０】
〔ＰＬＣモデムの内部構成〕
図５は、ＰＬＣモデム３，８の内部構成の一例を示すブロック図である。
図５に示すように、各ＰＬＣモデム３，８は、それぞれ、ＰＨＹ部１１と、プロセッサ部１２と、ＰＬＣ変復調部１３とを筐体内に備えている。
このうち、ＰＨＹ部１１は、イーサネット対応のトランシーバよりなり、コネクタ１４に接続されたイーサネットケーブルに対してイーサネット信号の送受信が可能である。ＰＬＣ変復調部１３は、イーサネット信号とＰＬＣ信号を相互に変換して送受信するものであり、コネクタ１５に接続された電力線２に対してＰＬＣ信号を重畳して送受信する。
【００２１】
図５に示す例では、プロセッサ部１２は、２つのＭＩＩ（Medium Independent Interface）のポートを備えており、これらの各ポートに前記ＰＨＹ部１１とＰＬＣ変復調部１３がそれぞれ接続されている。そして、このプロセッサ部１２は、マルチキャスト通信を含むＩＰプロトコルに従う所定のパケット転送と、後述のＭＬＤ（Multicast Listening Discovery）処理を行うことができる。
このように、図５に示すモデム３，８の内部構成では、パケット転送を行うプロセッサ部１２によるＭＬＤ処理が可能となっているので、モデム３，８内の構造がシンプルになり、モデムの低価格化を実現することができる。
【００２２】
もっとも、この場合には、同じプロセッサ部１２において、パケット転送とＭＬＤ処理の双方を行うことから、高速なパケット転送を実現できなくなる恐れがある。
そこで、図６に示すように、プロセッサ部１２を、カスタムチップよりなる比較的高速のパケット転送用の第一プロセッサ部１２Ａと、比較的低速なＭＬＤ処理用の第二プロセッサ部１２Ｂとに分離することにしてもよく、この場合には、パケットの転送速度をより高速化することができる。
【００２３】
〔ＭＬＤ処理（スヌーピング）〕
以下、上記通信システム１で行われるマルチキャスト通信について説明する。
なお、本実施形態では、通信システム１を構成する各ノードは、ＩＰｖ６（Internet Protocol version6）に準拠したＩＰ通信が可能であり、マルチキャスト通信に関しては、ＭＬＤｖ２（Multicast Listening Discovery version2）に準拠した処理が行われるものとする。
また、図１に示すように、ビデオソース７、光回線インタフェース４、親機モデム３、子機モデム５及び端末装置９には、それぞれ、所定のＩＰアドレスとＭＡＣアドレスが割り当てられているものとする。
【００２４】
〔ＭＬＤレポート〕
図２に示すように、端末装置９（ＳＴＢ１〜ｎ）は、まず、マルチキャスト通信の参加要求を行うためのＭＬＤレポート２０を子機モデム８に送出する。
このＭＬＤレポート２０は、例えば図４（ａ）に示すように、ＤＡ（Destination address）及びＳＡ（Sender address）の領域を有するＭＡＣヘッダ部２１と、宛て先ＩＰアドレス及び送信元ＩＰアドレスの領域を有するＩＰヘッダ部２２と、マルチキャスト通信に関する制御情報が記載されるマルチキャストレコード部２３とを備えている。
【００２５】
上記マルチキャストレコード部２３は、マルチキャストアドレス２４、レコードタイプ２５及びソースアドレス２６の記載領域を有する。
このうち、マルチキャストアドレス２４には、例えばＩＰ放送を行うマルチキャストグループ（ＮＨＫやショップチャンネル等）のＩＰアドレスが記載され、ソースアドレス２６には、そのグループに属するコンテンツサーバである前記ビデオソース（ＳＯＵＲＣＥ１〜ｎ）７のＩＰアドレスが記載される。また、レコードタイプ２５には、当該ビデオソース７を利用するか否かに関する視聴モードが記載される。
【００２６】
各端末装置９（ＳＴＢ１〜ｎ）は、自身が視聴したいマルチキャストグループをどのソースアドレスから視聴するのかを、上記ＭＬＤレポート２０を利用して特定する。
例えば、ＮＨＫのＩＰ放送を行うビデオサーバ７がＳＯＵＲＣＥ１〜３であり、ＳＴＢ１がＳＯＵＲＣＥ１だけからそのＩＰ放送を受信する場合には、ＳＴＢ１は、マルチキャストアドレス２４がＮＨＫであるＭＬＤレポート２０に対して、ＩＰＳＯＵＲＣＥ１に対応するレコードタイプ２５だけをオン（○）となるように記載する（図４（ｂ）のＩＰ管理テーブル参照）。
また、ショップチャンネルのＩＰ放送を行うビデオサーバ７がＳＯＵＲＣＥ６，７及び９であり、ＳＴＢ１がＳＯＵＲＣＥ６及び９からそのＩＰ放送を受信する場合には、ＳＴＢ１は、マルチキャストアドレス２４がショップチャンネルあるＭＬＤレポート２０に対して、ＩＰＳＯＵＲＣＥ６及び９に対応するレコードタイプ２５がオン（○）となるように記載する。
【００２７】
各端末装置９（ＳＴＢ１〜ｎ）は、上記ＭＬＤレポート２０をそれぞれ子機モデム８（ＰＬＣ１〜ｎ）に向かって送出する。この場合、ＩＰｖ６のマルチキャストパケットの場合、ＭＡＣヘッダ部２１のＤＡはその先頭が「３３：３３：」になる（なお、ＭＬＤレポート２０のＤＡは「３３：３３：００：００：００：１６」（固定アドレス）である。）。  従って、図２に示すように、端末装置９が送出するＭＬＤレポート２０では、ＭＡＣヘッダ部２１のＤＡが「３３：３３：……」であり、ＭＡＣヘッダ部２１のＳＡが自身のＭＡＣアドレス（ＳＴＢ１の場合には、「ＭＡＣＳＴＢ１」）となる。
【００２８】
上記ＭＬＤレポート２０を受けた各子機モデム８（ＰＬＣ１〜ｎ）は、ＭＡＣヘッダ部２１のＤＡはそのままにした状態で、ＭＡＣヘッダ部２１のＳＡを自身のＭＡＣアドレス（ＰＬＣ１の場合には、「ＭＡＣＰＬＣ１」）に書き換え、このように書き換えたＭＬＤレポート２０を親機モデム３（ＰＬＣ０）に送出する。
従って、親機モデム３は、各子機モデム８から、ＭＡＣヘッダ部２１のＳＡが当該子機モデム８のＭＡＣアドレスに書き換えられた多数のＭＬＤレポート２０を逐次受信することになる。なお、親機モデム３は、各ＭＬＤレポート２０を光回線インタフェース４にそのまま送出する。
【００２９】
〔ＩＰ管理テーブル〕
親機モデム３は、子機モデム８から受信した各ＭＬＤレポート２０の記載内容を解析して、例えば図４（ｂ）に示すＩＰ管理テーブル２７を各端末装置９（ＳＴＢ１〜ｎ）のＩＰアドレス毎に作成する。
このＩＰ管理テーブル２７は、ＭＬＤレポート２０のＩＰヘッダ部２２の送信元に記載されているＩＰアドレス毎に作成されるもので、前記マルチキャストレコード部２３の記載内容に基づき、ある特定の端末装置９（ＳＴＢ１〜ｎ）がどのマルチキャストグループの放送をどのビデオソース７（ＳＯＵＲＣＥ１〜ｎ）から視聴するのかを、テーブル化したものである。
【００３０】
なお、親機モデム３のプロセッサ部１２は、ＭＬＤレポート２０の解析により、送出元のＩＰアドレス数（ＳＴＭの数）やマルチキャストアドレス数が最大値を超えている場合には、追加しようとしている項目を無視する機能を有する。
また、親機モデム３は、前記ＭＬＤレポート２０のタイマフィールド（図示せず）から得たタイマ情報で定期的にＩＰ管理テーブル２７の各値を更新し、タイムアウトを超えたフィールドを削除するようになっており、これにより、ＩＰ管理テーブル２７が動的に更新されるようになっている。
【００３１】
〔パケット変換テーブル〕
後述の通り、親機モデム８は、ビデオソース７からのマルチキャストパケット（下りのマルチキャストパケット）３０を、子機モデム８に対して、見かけ上、ユニキャストパケット３１に変換して送信する。
かかるマルチキャストからユニキャストへの変換は、例えば、下りのマルチキャストパケット３０のＩＰアドレスの下位の４オクテットを取り出し、ＭＡＣヘッダ部２１のＤＡの先頭に「３３：３３」を付加することによって生成することができる。
【００３２】
また、前記した通り、各子機モデム８は、ＭＬＤレポート２０を親機モデム３に送出する際に、そのレポート２０のＭＡＣヘッダ部２１のＳＡを自身のＭＡＣアドレスに書き換えているので、親機モデム３は、各端末装置９（ＳＴＢ１〜ｎ）がどの子機モデム８（ＰＬＣ１〜ｎ）に繋がっているかを把握することができる。
そこで、親機モデム３は、前記ＩＰ管理テーブル２７に基づき、下りのマルチキャストＭＡＣアドレスをユニキャストＭＡＣアドレスに変換するためのパケット変換テーブル（図示せず）を予め作成しており、この変換テーブルも、上記ＩＰ管理テーブル２７が更新される度に更新される。
【００３３】
上記の通り、子機モデム８は、ＭＬＤレポート２０をイーサネット側（端末装置９）から受信すると、そのレポート２０のＭＡＣヘッダ部２１のＳＡを自身のＭＡＣアドレスに書き換えて、ＰＬＣ側（親機モデム３）に送信する。
なお、この際、ＰＬＣ転送によってＭＬＤレポート２０のパケットをドロップすると、画像の視聴に大きな影響を与えることがあるため、そのパケットにＶＬＡＮタグを付加して、そのＩＥＥＥ８０２．１ｐフィールドの優先度を最高にする（もっとも、受信側ではこのＶＬＡＮタグを除去する。）ことが好ましい。
また、親機モデム３は、マルチキャストへの参加希望を探索するためのＭＬＤクエリを所定時間毎に子機モデム８側に送出するが、子機モデム８は、当該ＭＬＤクエリについては何も処理せずに、そのまま各端末装置９に転送するようになっている。
【００３４】
一方、親機モデム３は、ＭＬＤレポート２０をＰＬＣ側（子機モデム８）から受信した場合は、そのままイーサネット側（ゲートウェイＧＷ４）に転送するとともに、ＭＬＤレポート２０の内容をプロセッサ部１２において解析する。
なお、子機モデム８からのパケットがＭＬＤレポート２０か否かの判断は、例えば、下記条件の有無（一部でもよい）で行うことができる。
１）宛先ＭＡＣアドレスの先頭２オクテットが「33：33」である。
２）イーサネットヘッダのTypeフィールドが「0x86DD」か、IEEE802.3パケットである。
３）IPv6ヘッダのversionが6である。
４）IPv6ヘッダのHop Limitが1である。
５）IPv6ヘッダのNext Headerの値が0x00である。
６）Hop-by-Hop Options HeaderのNext Headerフィールドの値が0x3Aである。
７）Hop-by-Hop Options Header内にRouter Alert optionが含まれる。
８）MLDv2メッセージのTypeがReport(0x8F)である。
９）MLDのチェックサム(RFC2463及びRFC2460参照)が正しい。
【００３５】
〔下りのマルチキャストパケット〕
図３は、ビデオソース７から受信したマルチキャストパケットの転送を示している。
図３に示すように、ビデオソース７が送信したマルチキャストパケット３０は、上位ネットワーク６を通じて光回線インタフェース４に至り、イーサネット信号として親機モデム３に送信され、この親機モデム３と子機モデム４の間のＰＬＣ通信を通じて、当該マルチキャストグループに属する端末装置９に転送される。
【００３６】
〔マルチ→ユニ変換〕
かかる下りのマルチキャストパケット３０は、光回線インタフェース４が送出する時点においては、ＭＡＣヘッダ部２１のＤＡが「３３：３３：…」であり、かつ、ＭＡＣヘッダ部２１のＳＡが「ＭＡＣＧＷ」になっている。
そこで、親機モデム３は、上記マルチキャストパケット３０のＭＡＣヘッダ部２１のＤＡを、前記パケット変換テーブルに基づいて特定の子機モデム８宛てに書き換える。
例えば、図３に示すように、そのマルチキャストパケット３０がＰＬＣ１宛てであれば、そのＤＡを「ＭＡＣＰＬＣ１」に書き換え、これにより、当該マルチキャストパケット３０を見かけ上、ＰＬＣ１宛のユニキャストパケット３１に変換する。
【００３７】
〔ユニ→マルチ変換〕
他方、上記のように親機モデム３で変換されたユニキャストパケット３１を受信した子機モデム８（図３のＰＬＣ１）は、そのユニキャストパケット３１に逆の処理を施してマルチキャストパケット３２に戻す処理を行う。
具体的には、子機モデム８は、親機モデム３で変換されたユニキャストパケット３１に含まれている、宛先ＩＰアドレスの下位４オクテットを取り出し、その先頭に「３３：３３」を付加したものをＭＡＣヘッダ部２１のＤＡに記載することにより、当該ユニキャストパケット３１をマルチキャストパケット３２に戻す。
【００３８】
なお、子機モデム８が受信したユニキャストパケット３１が、親機モデム３によってマルチキャストから変換されたものであるか、或いは、そのような変換を行っていない通常のユニキャストパケットであるか否かの判断は、例えば、次の条件を満たすか否かによって行うことができる。
１）  宛先MACアドレスが外付けCPU自身のMACアドレスかブロードキャスト(FF:FF:FF:FF:FF:FF)である。
２）  EthernetヘッダのTypeフィールドが0x86DDである。
３）  IPv6ヘッダのVersionが6である。
４）  IPv6ヘッダのDestination IPv6 Addressの最初の1オクテット目が0xFFである。
【００３９】
上記の通り、本実施形態の通信システム１によれば、親機モデム３が、上位ネットワーク６から受信したマルチキャストパケット３０をユニキャストパケット３１に変換して子機モデム８に送信し、その子機モデム８が、変換されたユニキャストパケット３１を元のマルチキャストパケット３２に戻して端末装置９に送信するので、ＰＬＣ通信を行う親機モデム３と子機モデム８同士の間においては、マルチキャスト通信ではなくユニキャスト通信が行われる。
【００４０】
このため、本実施形態のように、親機モデム３と子機モデム８がＰＬＣモデムであるが故に、信号減衰やノイズ等の影響で通信速度が変動し易く、その間のマルチキャストでの通信速度が制限されるよう場合であっても、それらのモデム３，８間でユニキャスト通信を行うことで伝送速度を確保することができ、映像系データ等の大容量のデータを適切にマルチキャストすることができる。
【００４１】
なお、上記実施形態は例示であって制限的なものではない。本発明の権利範囲は特許請求の範囲によって規定され、そこに記載された構成と均等の範囲内のすべての変更も本発明に含まれる。
例えば、上記実施形態では、通信システム１がＩＰｖ６に準拠したＩＰ通信を行う場合を例示したが、ＩＰｖ４であってもよく、この場合には、ＩＧＭＰ（Internet Group Management Protocol）に基づくスヌーピングが適用される。
【００４２】
例えば、米国Intellon社の「INT6000」チップを採用したＰＬＣモデムの場合、ＩＰｖ４に準拠したＩＰ通信しか行えないが、この場合には、ＩＰｖ４に基づくＩＧＭＰスヌーピングを採用することによって、本発明を実施することができる。また、この場合でも、ＩＰｖ６とＩＰｖ４間のパケット変換をプロセッサ部１２で行うようにすれば、前記ＭＬＤスヌーピングに基づくマルチキャスト通信を実施することもできる。
更に、本発明は、ＰＬＣモデム３，８に限らず、無線ＬＡＮで通信する一対のモデムを使用することもできる。
【図面の簡単な説明】
【００４３】
【図１】本発明に係るマルチキャスト通信システムの一例を示す全体構成図である。
【図２】ＭＬＤレポートの送信状態を追記した上記全体構成図である。
【図３】マルチキャストパケットの送信状態を追記した上記全体構成図である。
【図４】（ａ）はＭＬＤレポートの構成図であり、（ｂ）はＩＰ管理テーブルの一例を示す図である。
【図５】ＰＬＣモデムの内部構成の一例を示すブロック図である。
【図６】ＰＬＣモデムの内部構成の他の例を示すブロック図である。
【符号の説明】
【００４４】
１：マルチキャスト通信システム、２：電力線、３：親機モデム、
４：光回線インタフェース（ゲートウェイ）、５：光ファイバ、
６：上位ネットワーク、７：ビデオソース、８：子機モデム、９：端末装置、
１０：パーソナルコンピュータ、１１：ＰＨＹ部、１２：プロセッサ部、
１２Ａ：第一プロセッサ部、１２Ｂ：第二プロセッサ部、１３：ＰＬＣ変復調部、
１４：コネクタ、１５：コネクタ、
２０：ＭＬＤレポート、２１：ＭＡＣヘッダ部、２２：ＩＰヘッダ部、
２３：マルチキャストレコード部、２４：マルチキャストアドレス、
２５：レコードタイプ、２６：ソースアドレス、２７：ＩＰ管理テーブル、
３０：マルチキャストパケット、３１：ユニキャストパケット、
３２：マルチキャストパケット
【図１】
2008187626.tif 000003
【図２】
2008187626.tif 000004
【図３】
2008187626.tif 000005
【図４】
2008187626.tif 000006
【図５】
2008187626.tif 000007
【図６】
2008187626.tif 000008