JPH10308759A - 通信装置および通信方法 - Google Patents

Abstract

(57)【要約】 【課題】IEEE１３９４等の放送型ネットワークにおい
て、通信帯域の確保を行うことができ、また通信資源を
有効に利用してＩＰマルチキャストを行うことができ、
確保したチャネルとＩＰマルチキャストアドレスとの対
応関係を送信側、受信側で同期して認識することのでき
る通信装置を提供する。 【解決手段】放送型のネットワークに接続された通信装
置であって、前記ネットワークに接続された第２の通信
装置から、ネットワークレイヤデータフローを識別する
識別子を含み、かつ前記ネットワークレイヤデータフロ
ーに対応する帯域の確保要求を含む第１のメッセージを
受信する受信手段と、この受信手段で受信した第１のメ
ッセージに基づき前記ネットワーク上に放送型チャネル
を確立する確立手段と、少なくとも前記確立された放送
型チャネルの識別子と前記ネットワークレイヤデータフ
ローの識別子との対応関係を含む第２のメッセージを前
記第２の通信装置に送信する送信手段とを具備する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ＩＥＥＥ１３９４
バス等の放送型のネットワークを介してデータ通信を行
う通信装置に関する。

【０００２】

【従来の技術】最近インターネットをはじめとする通信
技術の急激な進歩が各方面で話題になっており、企業や
大学などを中心にＬＡＮの導入、あるいはこれのＷＡＮ
やインターネットへの接続といったことが話題になって
いる。

【０００３】これらの技術革新は、家庭を取り巻くネッ
トワーク環境をも変える可能性が高い。即ち、家庭にＰ
ＣやＤＶＤ、デジタルセットトップボックス等のデジタ
ル機器が普及してくるに連れて、これらを相互にデジタ
ルネットワークにて接続しようという気運が高まるのは
必然である。現在、ＡＶベンダを中心に、ＩＥＥＥ１３
９４バスが、その候補の筆頭として、各方面から注目を
集めている。

【０００４】ＩＥＥＥ１３９４バスは、１００Ｍ、２０
０Ｍ、４００Ｍｂｐｓの高速デジタル網として利用する
ことができ、プラグアンドプレイ、同期チャネルを用い
た同期転送機能等、いくつもの注目すべき機能がある。

【０００５】それとともに、いわゆる家庭へのアクセス
網の技術革新も急である。即ち、ＣＡＴＶやＡＤＳＬ
（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃ
ｒａｉｂｅｒ Ｌｉｎｅ）、ＦＴＴＨ（ｆｉｂｅｒ−ｔ
ｏ−ｔｈｅ−ｈｏｍｅ）等の高速ネットワーク技術、イ
ンターネット等のネットワークサービス等、その進歩は
著しい。特に、インターネット技術は、その高速化、Ｒ
ＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｅｒｖａｔｉｏｎ Ｐ
ｒｏｔｏｃｏｌ）等ネットワークレイヤレベルのシグナ
リングプロトコルを用いたＱＯＳ（Ｑｕａｌｉｔｙ ｏ
ｆ Ｓｅｒｖｉｃｅ）保証、マルチキャスト等、注目す
べき技術が次々と生まれている。

【０００６】インターネット上で、これらの技術が実現
する近未来においては、家庭へのビデオ転送等、高速、
リアルタイムを要求される情報の転送の一部がインター
ネットを通じて行われる可能性がある。これは、インタ
ーネットに蓄積される情報量が実質的に無限であり、ユ
ーザが、従来は地上波、衛星放送などからでていた前記
情報をインターネットを通じて入手するようになると考
えるのは、ごく自然なことである。

【０００７】

【発明が解決しようとする課題】しかしながら、家庭内
のデジタル機器を、アクセス網を介して接続し、インタ
ーネットを通じた情報のやり取りをしようとした場合、
以下のような問題点が考えられる。

【０００８】現在、ＩＥＥＥ１３９４上をインターネッ
トのデータを流通させるための検討、即ち「ＩＰ ｏｖ
ｅｒ １３９４」の検討が、各方面で進められている。
しかし、現在その検討はいわゆるアドレス解決方式にと
どまっている。一方、インターネット上を通信品質を保
証する形でデータのやり取りを行うためのシグナリング
プロトコルとして、例えばＲＳＶＰが提案されている。
しかし、これらのネットワークレイヤのシグナリングプ
ロトコルをＩＥＥＥ１３９４上で運用する方式がいまだ
決まっておらず、ＩＥＥＥ１３９４上では通信品質が確
保されない転送方式にマッピングせざるをえない。従っ
て、上記シグナリングが実行されたとしても、ＩＥＥＥ
１３９４上をベストエフォート（具体的には非同期チャ
ネル）を通じてデータが転送されてしまうため、エンド
エンドの通信品質が保たれない。

【０００９】また、ＩＥＥＥ１３９４バス上でＩＰマル
チキャストを送受信しようとした場合、ＩＥＥＥ１３９
４バス上のトラヒックを最小限にするために、ＩＥＥＥ
１３９４バスの同期チャネルあるいは非同期ストリーム
を用いることが考えられる。しかしながら、同時に２つ
以上の装置が同じＩＰマルチキャストに加入しようとい
う場合は、これら２つ以上の装置が独立に別個のチャネ
ルを確保してしまう可能性があり、通信資源の有効利用
が図れない。また、確保したチャネルと、ＩＰマルチキ
ャストアドレスとの対応関係を送信側、受信側で同期し
て認識するための機構が無い。

【００１０】そこで、本発明は、上記問題点に鑑みてな
されたものであり、ＲＳＶＰのＩＥＥＥ１３９４バス上
での適用方法を示し、ＩＥＥＥ１３９４上でも、相互接
続環境での通信品質を確保した通信が可能となる通信装
置を提供することを目的とする。

【００１１】また、本発明は、ＩＥＥＥ１３９４等の放
送型ネットワークにおいて、通信資源を有効に利用して
ＩＰマルチキャストを行うことができ、また、確保した
チャネルとＩＰマルチキャストアドレスとの対応関係を
送信側、受信側で同期して認識することのできる通信装
置を提供することを目的とする。

【００１２】

【課題を解決するための手段】上記問題を解決するため
に、本発明の通信装置は、放送型のネットワークに接続
された通信装置であって、前記ネットワークに接続され
た第２の通信装置から、ネットワークレイヤデータフロ
ーを識別する識別子を含み、かつ前記ネットワークレイ
ヤデータフローに対応する帯域の確保要求を含む第１の
メッセージを受信する受信手段と、 この受信手段で受
信した第１のメッセージに基づき前記ネットワーク上に
放送型チャネルを確立する確立手段と、少なくとも前記
確立された放送型チャネルの識別子と前記ネットワーク
レイヤデータフローの識別子との対応関係を含む第２の
メッセージを前記第２の通信装置に送信する送信手段と
を具備することにより、インターネットにおけるRSVPプ
ロトコルのようにネットワークレイヤデータフローに対
応する帯域確保のための制御プロトコルにおいて、この
制御メッセージ( 第1 のメッセージ。RSVPの場合はPAT
H メッセージやRESVメッセージにあたる) を受信したノ
ードが、そのネットワーク上に放送型のチャネル( 例え
ばIEEE1394の同期チャネルや非同期ストリーム) を確保
することにより、要求されている通信資源を放送型チャ
ネルという形で確保することが可能となり、ネットワー
クレイヤレベルのシグナリングプロトコルで実現される
べき、エンド・エンドの通信資源の確保された通信が実
現可能となる。

【００１３】また、前記第2 のメッセージは、ネットワ
ークの境界でのデータリンク転送、即ちデータリンクレ
イヤの識別子( 例えば放送型チャネルの識別子) のみを
参照して、その識別子を持つチャネルが転送しているネ
ットワークレイヤフローを暗示的に認識し、ネットワー
クレイヤのルーチング処理を伴わずに次段のネットワー
クに転送するために使うこともできる。また、前記第2
のメッセージを用いて、下流ノードがそのチャネルから
前記ネットワークレイヤフローを受信する準備をした
り、上流ノードがそのチャネルへネットワークレイヤフ
ローを送信する準備をするのに使うことができるように
なる。

【００１４】さらに本発明の通信装置は前記第1 のメッ
セージは、帯域の確保要求のためのメッセージであり、
前記ネットワークレイヤデータフローの下流方向に接続
された前記第2 の通信装置から送信されたものであるこ
とにより、ネットワークレイヤフローに対して上流側の
ノードが本放送型ネットワークの帯域資源確保を行う形
で、本帯域確保を行うことができる。即ち、ネットワー
クレイヤフローに対して上流側のノードが前記第1 のメ
ッセージとして、RSVPのRESVを受信した場合のように、
その下流方向からの帯域確保要求に対して、この帯域確
保を実現することができるようになる。

【００１５】さらに本発明の通信装置は、前記第1 のメ
ッセージは、使用帯域の通知のためのメッセージであ
り、前記ネットワークレイヤデータフローの上流方向に
接続された前記第2 の通信装置から送信されたものであ
ることにより、ネットワークレイヤフローに対して下流
側のノードが本放送型ネットワークの帯域資源確保を行
う形で、本帯域確保を行うことができる。即ち、ネット
ワークレイヤフローに対して下流側のノードが、前記第
1 のメッセージとして、RSVPのPATHを受信した場合のよ
うに、その上流方向からの帯域確保のための制御メッセ
ージに対して、このノードがこの帯域確保を行うことに
よって、この帯域確保を実現することができるようにな
る。

【００１６】さらに本発明の通信装置は、前記ネットワ
ークレイヤフローの上流方向に接続された前記第2 の通
信装置に対し、帯域の確保要求のためのメッセージを送
信する送信手段を更に具備したことにより、例えばRSVP
のRESVメッセージのようなネットワークレイヤの帯域確
保の為のメッセージを上流の前記第2 の通信装置に対し
て送信し、もってエンド・エンドの帯域確保を行う事が
できるようになる。

【００１７】さらに本発明の通信装置は、前記第2 のメ
ッセージの送信は、前記第2 の通信装置に備えられたレ
ジスタへの書き込みの形にて行われることにより、IEEE
1394等の放送型ネットワークにおいて制御情報を伝達す
る手段として一般的な、レジスタへの書き込みを用い
て、前記確立された放送型チャネルの識別子と、前記ネ
ットワークレイヤデータフローの識別子との対応関係の
通知を行うことができるようになる。この対応関係は、
データリンクレイヤのチャネルに関する情報であるた
め、データリンクレイヤの制御情報を伝達するレジスタ
を用いるのは妥当であり、ネットワークレイヤにこの対
応情報を受信、解釈する機構を用意する必要がなくな
る。

【００１８】また本発明の通信装置は、放送型のネット
ワークに接続された通信装置であって、 前記ネットワ
ーク上に確立されたネットワークレイヤデータフローを
送受信する際に必要な放送型チャネルの識別子と前記ネ
ットワークレイヤデーターフローの識別子との対応関係
を記述するレジスタと、 前記放送型チャネルを通じ
て、前記ネットワークレイヤデータフローを送受信する
手段とを具備したことにより、このレジスタに記述され
た放送型ネットワーク( 例えばIEEE1394) の放送型チャ
ネル識別子と、そのチャネルを通るフローに関する情報
の対応関係を他のノードに通知すること、あるは他のノ
ードから獲得することができるようになる。この対応関
係は、データリンクレイヤのチャネルに関する情報であ
るため、データリンクレイヤの制御情報を伝達するレジ
スタを用いるのは妥当であり、ネットワークレイヤにこ
の対応情報を受信、解釈する機構を用意する必要がなく
なる。これを用いることにより、前記レジスタを持って
いるノードが送信ノードである場合に前記放送型ネット
ワークの他のノードがこのレジスタを参照することによ
って、このレジスタに記述された前記放送型ネットワー
クの放送型チャネル上に、そのようなフローが通ってい
るのか( 前記送信ノードがどのようなフローを送信して
いるのか) を知ることができるようになる。また、前記
レジスタを持っているノードが受信ノードである場合に
前記放送型ネットワークの他のノードがこのレジスタに
対応関係を記述することによって、前記受信ノードは、
このレジスタに記述された前記放送型ネットワークの放
送型チャネル上に、そのようなフローが通ってくるのか
( 前記受信ノードがどのようなフローを受信するのか)
を知ることができるようになる。また、前記レジスタに
は送信か受信かを区別するフィールドを更に持ってもよ
い。これにより、前述の送信ノード、受信ノードのどち
らの用途に本レジスタを使用するのかを明確にすること
ができる。

【００１９】また本発明の通信装置は、放送型のネット
ワークに接続された通信装置であって、 前記ネットワ
ークに接続された第２の通信装置から、ネットワークレ
イヤマルチキャストアドレスへの加入申請を受け付ける
受付手段と、前記加入申請に応じて前記ネットワーク上
に放送型チャネルを確立する確立手段と、少なくとも前
記確立された放送型チャネルの識別子と前記ネットワー
クレイヤマルチキャストアドレスとの対応関係を前記第
２の通信装置に通知する通知手段と、前記ネットワーク
レイヤマルチキャストアドレス宛てのデータを前記確立
された放送型のチャネルに送出する送出手段とを具備し
たことにより、該当するネットワークレイヤマルチキャ
ストを送信するための同期チャネルの確立を、同マルチ
キャストアドレスへの加入申請を受け付けるＩＧＭＰル
ータが行うことで、同一のマルチキャストアドレスに対
して、複数のチャネルが確立されて、網内の通信資源が
浪費されるのを未然に防ぐことが可能になる。また、前
記確立された放送型チャネルの識別子と前記ネットワー
クレイヤマルチキャストアドレスとの対応関係を前記第
２の通信装置に通知することにより、第２の通信装置
（受信端末）がどのチャネルより、該マルチキャストデ
ータを受信できるようになるのかを通知することが出来
るようになり、しかも放送型のチャネルを用いるため
に、複数の受信端末の収容を１つのチャネルを通じて行
うことが可能になる。

【００２０】さらに本発明の通信装置は、前記第２の通
信装置からの前記ネットワークレイヤマルチキャスト宛
てのデータを受信する際に必要な帯域の確保要求を前記
第２の通信装置から受け付ける第２の受付手段と、前記
確立された放送型チャネルの帯域を確保する確保手段と
をさらに具備したことにより、前記マルチキャストの通
信品質を保証した形での伝送が可能になる。

【００２１】また本発明の通信装置は、放送型のネット
ワークに接続され、ネットワークレイヤマルチキャスト
アドレス宛てのデータを送信する通信装置であって、前
記ネットワーク上に確立されている放送型チャネルに対
する通信帯域を確保する確保手段と、前記放送型チャネ
ルに帯域が確保されていない場合に、前記ネットワーク
レイヤマルチキャストアドレス宛てのデータを前記放送
型チャネルの帯域が確保されていない周期あるいはコネ
クションで送信する第1 の送信手段と、前記確保手段に
より前記放送型チャネルに帯域が確保された場合に、前
記ネットワークレイヤマルチキャストアドレス宛てのデ
ータを前記放送型チャネルの帯域が確保されていない周
期あるいはコネクションから、前記放送型チャネルの帯
域が確保された周期あるいはコネクションに切り替えて
送信する第2 の送信手段とを具備したことにより、ネッ
トワークレイヤマルチキャストパケットを帯域を確保さ
れていない形での伝送から、確保された形での伝送に切
り替える場合に、これまでのように、再度放送型チャネ
ルと帯域の確保の両方を資源確保を行っているマネージ
ャ( 例えばIEEE1394における同期リソースマネージャ)
に要求する必要がなくなる。即ち、単に既に通信資源と
して持っている放送型チャネル向けのパケットを第1 の
送信手段に送り込むのみでこれが可能となる。逆の切り
替え( 帯域確保から非確保への切り替え) も同様であ
る。

【００２２】さらに本発明の通信装置では、前記確保手
段で帯域が確保された場合の前記第1 の送信手段から出
力される放送型チャネルの識別子は、帯域が確保されて
いない場合の前記第2 の送信手段から出力される放送型
チャネルの識別子と同一の識別子であることにより、放
送型チャネルの浪費を防ぐことが可能となる。特に、IE
EE13 94 の様なチャネル資源が比較的少ない様なデータ
リンクに関しては、帯域確保の形で流すネットワークレ
イヤマルチキャストパケットと、帯域確保無しで流すマ
ルチキャストパケットとを同一のチャネルで共有するこ
とができるようになり、これも通信資源の有効活用につ
ながる。

【００２３】

【発明の実施の形態】以下、図面を参照して本発明の実
施形態について説明する。なお、以下の説明では、一例
として家庭内に構築されたネットワーク（家庭内ネット
ワーク）を対象として説明するが、これに限るものでは
なく、例えば、ホテル等の建物、敷地内といった限られ
た範囲に構築されるネットワークにおいても適用でき
る。

【００２４】（第１の実施形態）図１は、本発明の第１
の実施形態に係るネットワーク全体の構成例を示したも
ので、映像サービスを提供しているビデオサーバからの
データを、公衆網を介して家庭内ネットワークにとりこ
み、家庭内ネットワークに接続された端末で、該サービ
スを受ける状況を説明する図となっている。

【００２５】図１に示すように、全体の構成は、ビデオ
サーバ１０１、公衆網１０４、接続装置１０２、例えば
家庭内に構築された第１のネットワーク１０５、第２の
ネットワーク１０６、第１のネットワークに接続された
端末１０３からなる。

【００２６】なお、図１では第１のネットワーク１０５
に端末１０３が１つ接続されているのみであるが、実際
には両ネットワーク１０５、１０６に、他の種々の端
末、あるいは網間接続装置等が接続されていても良い。

【００２７】公衆網は、例えばＣＡＴＶ網、あるいはＩ
ＳＤＮ／Ｂ−ＩＳＤＮ網、ＡＴＭ−ＰＯＮ網、高速無線
アクセス網、ＡＤＳＬ／ＨＤＳＬ網等、色々な場合が考
えられる。ただし、本実施形態のビデオサービスはＭＰ
ＥＧ映像をインターネットを介して提供されるものとす
る（ＭＰＥＧｏｖｅｒＩＰ）。よって、本サービスが提
供されるインタフェースはデジタルインタフェースを仮
定する。

【００２８】本実施形態においては、該デジタルネット
ワークはデータリンク方式として、ＡＴＭ方式を採用し
ているものとして、以後の説明を進めていくが、本発明
の方式はＡＴＭ方式に限定されるものではない。例え
ば、以後の説明のＡＴＭのＶＰＩ／ＶＣＩ等のデータリ
ンクレイヤ識別子は、ＩＳＤＮであればＢチャネル識別
子、ＣＡＴＶであれば周波数に対応するものである。こ
のように、本実施形態のＡＴＭにおけるＶＰＩ／ＶＣＩ
をこれら他のデータリンクレイヤ識別子に置き換えたも
のも、本発明に含まれるものである。

【００２９】ビデオサーバ１０１は、専用のビデオサー
バでも良いし、例えば映像対応ＷＷＷサーバ等、映像信
号を送出できるサーバであれば良い。ここで、「映像信
号を送出できる」とは、リアルタイム伝送を行う事は必
ずしも意味しない。例えば、映像データを、リアルタイ
ム配信ではなく、ベストエフォートにて配信する場合が
これにあたる。

【００３０】公衆網１０４と家庭内に構築されたネット
ワークの間は、専用の接続装置１０２にて接続されてい
る。接続装置１０２には、この場合、公衆網１０４の終
端機能、家庭内のネットワーク１０５、１０６の終端機
能、ＩＰ処理機能、ＲＦＣ１６３１にて標準化されてい
るＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎ
ｓｌａｔｉｏｎ）機能の他に、ＩＰマルチキャスト対応
機能、ＩＰシグナリング機能、公衆網と家庭内のネット
ワーク間でリアルタイムデータ転送可能なデータリンク
レイヤレベルのスイッチ、アドレス通知機能等が実装さ
れている。詳細は後述する。

【００３１】次に、図１に示したネットワーク上のＩＰ
のサブネット構成とアドレス割当について説明する。図
１に示すように、第１の実施形態において、家庭内のネ
ットワーク全体（第１および第２のネットワーク１０
５、１０６）にて１つのＩＰサブネット( ネットワーク
アドレスＰ）が構成されており、更に家庭内ネットワー
クは、ＲＦＣ１５９７にて標準化されているプライベー
トアドレスを利用している。

【００３２】また、接続装置１０２の公衆網側には、グ
ローバルなＩＰアドレス（Ｇ．２）が割り当てられてい
る。このようなアドレス構成となっている理由は、例え
ば複数のグローバルなＩＰアドレスの取得には、１つの
グローバルＩＰアドレス取得と比べてコストがかかる、
あるいは世界的なＩＰアドレスの枯渇のためである。即
ち、端末数、アドレス数の急成長が見込まれる家庭内ネ
ットワークへの接続端末にはグローバルなＩＰアドレス
の新規の割当は実質的にはほとんど不可能、等の理由に
よるものである。

【００３３】なお、第１のネットワーク１０５、第２の
ネットワーク１０６は、それぞれ別のプライベートアド
レス内という限定の上で、別々のサブネットとなってい
てもよい。この場合は、両者の間にはいる接続装置１０
２はルータとなる。

【００３４】本実施形態においては、第１および第２の
ネットワーク１０５、１０６は同一のサブネットに属す
るものとして、以降の説明を行う。次に、図１の端末１
０３が接続装置１０２、公衆網１０４を通してビデオサ
ーバからビデオを転送してもらうまでの処理手順につい
て、図２を参照して説明する。また、その際の端末１０
３の処理手順および接続装置１０２の処理手順を、それ
ぞれ図３、図４に示す。

【００３５】図２、図３、図４は、後に示すように、接
続装置１０２がＳＢＭ（Ｓｕｂｎｅｔ Ｂａｎｄｗｉｄ
ｔｈ Ｍａｎａｇｅｒ）であるような場合に、この機構
を用いて通信資源の確保を使った場合のシーケンスを記
述したものである。

【００３６】ＳＢＭとは、ＩＥＴＦのＩｎｔＳｅｒｖワ
ーキンググループで議論されているもので、サブネット
内の通信資源確保をＲＳＶＰを用いて行うものである。
まず、端末１０３は、ＯＳＩの標準化された７レイヤの
うちのレイヤ５以上のプロトコルを用いて、見たいビデ
オについての情報の入手を行う（ステップＳ２０１、Ｓ
２０３）。これは、ＭＰＥＧ／ＤＡＶＩＣのＤＳＭ−Ｃ
Ｃや、それに準じたプロトコルを用いたネゴシエーショ
ンや、ＲＴＳＰ等を用いてＷＷＷサーバからの情報の選
択をＷｅｂ上で行う事による情報の選択など、色々な場
合が考えられる。以降では、これを「上位レイヤプロト
コル」として、まとめて表現する。

【００３７】本実施形態では、これらの情報の交換は、
ＩＰパケットを使って行われるものとする。ちなみに、
この上位レイヤプロトコルは、接続装置１０２にてＮＡ
Ｔの処理を受けながら通信されていても良い（ステップ
Ｓ２０２）。

【００３８】ＮＡＴ処理とは、プライベートＩＰ網から
インターネットにＩＰパケットをフォワーディングする
に際し、プライベートＩＰアドレスをインターネット側
に送出するのは許されないため、接続装置１０２にて、
プライベートＩＰアドレスを自身のグローバルＩＰアド
レス( ここでは「Ｇ．２」）に変換して送出する方式を
言う。

【００３９】ＮＡＴ処理の詳細については、例えば本発
明者らによる特願平第８−３１６５５２号を参照された
い。本実施形態においては、ビデオサーバからの映像サ
ービスは、ＩＰマルチキャストを通じて提供されるもの
とする。そこで、前記上位レイヤプロトコルを用いて選
択するビデオが決定した場合、そのビデオを転送するた
めのＩＰマルチキャストアドレスを取得する必要があ
る。

【００４０】その放送形態( 配信形態) にはいくつかの
形態が考えられる。 （Ａ） まず、ビデオ毎( コンテンツ毎) に、別々のＩ
Ｐマルチキャストアドレスが割り当てられている場合か
ら説明する。

【００４１】これは、例えばＡ放送局からの放送はＩＰ
マルチキャストアドレス＝「＃１」、Ｂ放送局からの放
送は「＃６」等と、ＩＰマルチキャストアドレスが割当
てられている場合である。

【００４２】上位レイヤプロトコルを通して、ビデオサ
ーバ１０１は、端末１０３にそのビデオを転送するため
のマルチキャストアドレス「Ｍ」を通知する。すると、
端末１０３は、ＩＰマルチキャストのプロトコル（例え
ばＩＧＭＰ（ＲＦＣ１１１２））に従い、インターネッ
ト側から受け取るＱＵＥＲＹメッセージに対し、加入し
たいマルチキャストアドレス「Ｍ」についてのＲＥＰＯ
ＲＴメッセージを送出する（ステップＳ２０４）。

【００４３】これを受信した接続装置１０２は、端末１
０３のプライベートアドレス「Ｐ．２」と、要求された
マルチキャストアドレス「Ｍ」との対応関係を記憶した
後（ステップＳ２０５）、ＲＥＰＯＲＴメッセージを上
流のルータに通知する（ステップＳ２０６）。その際、
送信者アドレスを自身（接続装置１０２）のグローバル
ＩＰアドレス「Ｇ．２」としておく。

【００４４】接続装置１０２に記憶される対応テーブル
の一例を図５に示す。マルチキャストアドレス「Ｍ」へ
の加入が成功すると、接続装置１０２は、端末１０３が
マルチキャストアドレス「Ｍ」に加入した旨を記憶し
（ステップＳ２０５）、これを端末１０３に通知する。

【００４５】次に、端末１０３は、このビデオ映像を良
い品質で受信するための通信資源の予約を行う。このた
めの方法として、いくつかの方法が考えられる。 （ａ） ＳＢＭを用いる方法 ＳＢＭ（Ｓｕｂｎｅｔ Ｂａｎｄｗｉｄｔｈ Ｍａｎａ
ｇｅｒ）とは、インターネットの標準化機関であるＩＥ
ＴＦで提案されているサブネット内の帯域予約のための
方式であり、サブネット内の帯域予約をＲＳＶＰを使っ
て行うものである。

【００４６】（ｂ） ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒ
ｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いる方
法 （ｃ） ＩＥＣ１８８３を用いる方法 以下、順に説明する。

【００４７】（ａ）ＳＢＭを用いる方法 まず、ＳＢＭを用いる場合について、図２に示すシーケ
ンスを参照して説明する。

【００４８】接続装置１０２は、ＳＢＭノードであるこ
とから、ルーチングプロトコルは稼動していない。本実
施形態の接続装置は、ＮＡＴ機能を持っているため、グ
ローバルＩＰアドレス（Ｇ．２）を有しているが、家庭
内ネットワーク側に複数の物理インタフェースがあると
しても、物理インタフェース毎にＩＰアドレス( プライ
ベートアドレス) を持つ必要はない。例えば、接続装置
１０２は、グローバルＩＰアドレスの他、プライベート
アドレスを１つ持てば充分である。ここでは、接続装置
１０２はプライベートＩＰアドレス「Ｐ．１」を持って
いる。

【００４９】端末１０３は、上位レイヤプロトコル等で
ＲＳＶＰのＰＡＴＨメッセージの送出をビデオサーバ１
０１に促しても良い。ＰＡＴＨメッセージはマルチキャ
ストアドレス「Ｍ」宛てに送出され、接続装置１０２に
届く（ステップＳ２０７）。

【００５０】接続装置１０２では、ＲＳＶＰのＰＡＴＨ
ステートを作成し（ステップＳ２０８）、その後、ＰＡ
ＴＨメッセージをマルチキャストアドレス「Ｍ」宛に送
出し、結局、端末１０３に到着する（ステップＳ２０
９）。その際、接続装置１０２は端末１０３がマルチキ
ャストアドレス「Ｍ」に属している事を、図５の対応テ
ーブルにより認識しているので、該ＰＡＴＨメッセージ
を端末１０３にフォワードする事が出来る。

【００５１】接続装置１０２内には、ＰＡＴＨステート
が出来る。ここで、接続装置１０２はＳＢＭノードであ
る。端末１０３は、帯域等の通信資源を予約すべく、Ｒ
ＳＶＰのＲＥＳＶメッセージを上流の接続装置１０２に
送出する（ステップＳ２１０）。

【００５２】ＲＥＳＶメッセージを受信した接続装置１
０２は、接続装置１０２と端末１０３間の通信資源を確
保すべく、第１のネットワーク（ＩＥＥＥ１３９４）１
０５のＩＥＥＥ１３９４同期リソースマネージャにアク
セスして、必要な帯域と同期チャネル番号を確保する
（ステップＳ２１１）。ここで、確保された同期チャネ
ルの番号を「＃ｘ」とする。

【００５３】この時点で、接続装置１０２は、端末１０
３に「どの同期チャネルを用いて、リクエストされた番
組を送出するのか」を端末１０３に通知しても良い（ス
テップＳ２１２）。

【００５４】この通知方法としては、例えば、図６に示
したようなフォーマットのＲＳＶＰのＰＡＴＨメッセー
ジを用いる方法がある。すなわち、図６に示すように、
ＲＳＶＰのＰＡＴＨメッセージ内に、「今後（あるいは
今）、このＰＡＴＨメッセージに含まれるデータ（ＩＰ
フロー）は、同期チャネル番号＝「＃ｘ」にて伝送す
る」といった旨の情報が記述される。

【００５５】第２の通知方法は、発明者らが特願平第８
−２６４４９６号に記載したＦＡＮＰ（Ｆｌｏｗ Ａｔ
ｔｒｉｂｕｔｅ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｐｒｏｔ
ｏｃｏｌ）を用いる方法である。

【００５６】ＦＡＮＰは、隣接ノード間（本実施形態の
場合、接続装置１０２と端末１０３間）にて、送信する
ＩＰフロー等（本実施形態の場合、例えばＩＰマルチキ
ャストアドレス「Ｍ」）と、リンクレイヤのＩＤ情報
（本実施形態の場合、先に確保したＩＥＥＥ１３９４の
チャネル番号）との対応関係を通知しあうものである。

【００５７】第３の通知方法は、ＩＥＣ１８８３のＣＩ
Ｐヘッダを用いる方法である。ＩＥＣ１８８３を用い
て、接続装置１０２が直接端末１０３のＰＣＲ（Ｐｌｕ
ｇ Ｃｏｎｔｒｏｌ Ｒｅｇｉｓｔｅｒ）に使用するチ
ャネル番号を書き込み、１３９４のヘッダなり、ＩＥＣ
１８８３にて定められたＣＩＰ（Ｃｏｍｍｏｎ Ｉｓｏ
ｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔ）ヘッダなりで端末１
０３に、送信している情報がＭＰＥＧｏｖｅｒＩＰであ
ることを認識させる。例えば、ＣＩＰヘッダを拡張する
場合は、そのパケットがＩＰパケットである旨、あるい
はＭＰＥＧｏｖｅｒＩＰである旨を示す値をＦＭＰ（フ
ォーマットＩＤ）領域に書き込むことにより、端末１０
３はＣＩＰヘッダを見ることにより、そのパケットの属
性がＩＰパケット、あるいはＭＰＥＧが載ったＩＰパケ
ットであることが認識できるようになる。

【００５８】第４の通知方法は、図７に示すように、Ｐ
ＣＲを拡張して、ＰＣＲレジスタの意味の一部を、その
チャネル番号に伝送する内容を意味するものとする。例
えば、ＩＰパケットあるいはＭＰＥＧｏｖｅｒＩＰのパ
ケットである。また、そのチャネル番号を伝送されるフ
ローの属性を記述しても良い。例えば、送信ＩＰアドレ
ス／受信ＩＰアドレス／送信ポート番号／受信ポート番
号の組み合わせなどである。このようなレジスタを端末
１０３に用意し、接続装置１０２( あるいはコントロー
ラ) がこのレジスタに適切に記述することにより、端末
１０３が、そのチャネル番号を通して受信するデータが
ＩＰパケット、あるいはＭＰＥＧｏｖｅｒＩＰのパケッ
トであること、あるいは、その属性を認識できるように
なる。

【００５９】無論、上記第１〜第４の通知方法の適宜組
み合わせて用いることもできる。なお、タイミング的に
は、ここで説明したタイミング以外にも、ビデオサーバ
１０１まで通信資源の予約が完了し、エンド- エンドの
通信が可能になった段階で上記の手続きを行う形も考え
られる。

【００６０】さて、下流側の通信資源の確保に成功した
接続装置１０２は、ＲＳＶＰのＲＥＳＶメッセージを更
に上流へと流す（ステップＳ２１３）。これを受けとっ
たインターネット内のルータは例えば、Ｑ．２９３１等
を使って下流側のＡＴＭ網の通信資源を確保し（ステッ
プＳ２１４）、それを確認した後、更に上流へとＲＥＳ
Ｖメッセージの送出、といったことを繰り返す。

【００６１】更に、ＰＡＴＨあるいはＦＡＮＰを用いて
下流方向のＲＳＶＰ／ＳＢＭノードに対して、使用する
データリンク識別子（この場合、データリンク技術がＡ
ＴＭであるため、ＶＰＩ／ＶＣＩ）についての情報を送
出し、該ＲＳＶＰ／ＳＢＭノードに、送出ＩＰフローと
データリンク識別子との対応関係の通知を行う（ステッ
プＳ２１５）。ここで、接続装置１０２に対して確保さ
れたＡＴＭのＶＣＩの値「＃ｙ」とする。

【００６２】こうして、エンドエンドの通信資源が確保
されたなら、ビデオ転送を開始する（ステップＳ２１
６、Ｓ２１７）。ここで、接続装置１０２では、ビデオ
サーバ１０１からＡＴＭコネクション「＃ｙ（ＶＣＩ値
＝「＃ｙ」）」にてＭＰＥＧｏｖｅｒＩＰのデータが伝
送されてくることを認識しており、また端末１０３に対
してＩＥＥＥ１３９４の同期チャネル「＃ｘ」にて受信
したＩＰパケットを送出すればよいことを認識してい
る。

【００６３】そこで、接続装置１０２では、ＶＣＩ「＃
ｙ」を通して受信したデータを、ＩＰパケットのヘッダ
の中身まで検証することなく、直接ＩＥＥＥ１３９４の
同期チャネル「＃ｘ」に対して、ＩＰパケットの同期を
とった上で伝送する。即ち、ＶＣＩ値のみの検証によ
り、ＩＰレイヤの処理をすることなく、直接１３９４へ
のデータ転送を行うことができる。これは、データリン
クレイヤの情報のみで、データのスイッチングを行って
いることから、データリンクスイッチと見ることができ
る。

【００６４】このことにより、本来ＩＰレイヤで行うべ
き、ＩＰレイヤ処理、即ちＩＰヘッダの検証やルーチン
グ処理等の一連のソフトウエア処理を、データリンクレ
イヤスイッチング処理にて置き換えることが可能にな
り、処理時間、及び処理負荷の大幅な低減を図ることが
可能になる。これは、ＳＢＭを行った上で、データリン
クスイッチを行っていることに相当する。

【００６５】なお、以上の説明では、接続装置１０２は
ＳＢＭノードとして説明を行ってきたが、接続装置１０
２がルータであり、ＲＳＶＰを利用した通信資源の確保
を行ってももちろんよい。

【００６６】また、通信資源の予約を行う際に、本発明
の発明者らによる特願平第８−２６４４９６号に記載さ
れている方法、すなわち、ＦＡＮＰにより通信資源の予
約を行うようにしてもよい。

【００６７】以上は、ＩＥＥＥ１３９４上の通信資源予
約をＲＳＶＰの上流のノードが行う場合についての説明
であった。これに対し、図８に示すように、ＩＥＥＥ１
３９４バス上の同期チャネルの確保を、下流側のノード
（本実施形態の場合、端末１０３）が行ってもよい。

【００６８】下流側のノードが必要な通信資源を持った
同期チャネルの確保を行った後（ステップＳ２１１
０）、上流側にＲＥＳＶメッセージの送出を行う（ステ
ップＳ２１１１）。この場合、確保した同期チャネルの
番号等は、続けて送出するＲＳＶＰのＲＥＳＶメッセー
ジに含めて送出しても良い。

【００６９】また、上流側に同期チャネル番号と帯域確
保を行うフローの対応の通知をRESVメッセージとは別の
メッセージで行ってもよい。この場合は、RESVメッセー
ジは単に接続装置に対して、該フローの帯域確保の要求
をするために用いられ、同期チャネル番号と帯域確保を
行うフローの対応関係は、別メッセージ( 本図ではFANP
メッセージ) にて行われてもよい。この通知を受けた接
続装置は、RESVメッセージで帯域予約を受けたフローに
ついて、どのリンクレイヤコネクション、つまり同期チ
ャネルにて転送すればよいのかについての情報を、この
メッセージから得ることができる。

【００７０】さて、端末１０３のユーザが、異なるビデ
オ映像( 例えば、違うチャネルのテレビ番組) を見たい
と考えた場合、上記同様の手続きをもう一度踏む事にな
る。即ち、その新しいビデオ映像に対応するＩＰマルチ
キャストアドレスを上位プロトコルなどを通じて入手
し、該ＩＰマルチキャストアドレスへの加入という手続
きを再度踏むことで、これを実現する。その際は、先に
加入していたＩＰマルチキャストアドレスは離脱するこ
とが、通信資源の有効活用の観点から望ましい。この様
子を図９に示している。

【００７１】また、家庭内に構築されたネットワークに
は端末が複数接続され、その各々が別々の放送を見てい
る場合は、その各々のデータが公衆網１０４および接続
装置１０２を通ることになる。接続装置１０２におい
て、データリンクスイッチを行うため、別々のＡＴＭ−
ＶＣにて別々の端末宛てのこれらのデータが伝送されて
くることが望ましい。通信資源の確保については、再度
上記のようなＳＢＭ／ＲＳＶＰ／ＦＡＮＰ等を使った手
続きが必要あるかどうかは、ＲＳＶＰ／ＳＢＭの予約の
仕方による。即ち、Ｓｈａｒｅｄ Ｅｘｐｌｉｃｉｔの
予約であれば、送信者のビデオサーバが同一である限
り、あるいはＳｈａｒｅｄ Ｅｘｐｌｉｃｉｔのサーバ
のアドレスとして、次にビデオを送出する新しいビデオ
サーバが登録されていれば、先に予約したのと同一の通
信資源（ＡＴＭのＶＣ、１３９４の同期チャネル）をそ
のまま利用し続ければよく、ＩＰマルチキャストの再加
入を行うのみで良い。

【００７２】（Ｂ） 次に、ＩＰマルチキャストアドレ
スは同じで、コンテンツが変わる場合を説明する。この
場合は、同一のマルチキャストアドレスを用いて、同一
のユーザに対して複数の映像サービスを行う形式とな
り、上位プロトコルを用いて映像コンテンツの変更（テ
レビのチャネルの変更に相当）を行う形となる。

【００７３】このときも、最初の通信資源の確保までは
同じ手順を踏む。ただし、上位レイヤプロトコルを通し
て与えられるＩＰマルチキャストアドレスは、あらかじ
めその端末に固有に与えられた（あらかじめ、ネットワ
ークサービスプロバイダが、ユーザ毎、あるいは端末毎
に割当てておいた）ＩＰマルチキャストアドレスであっ
てもよい。端末の識別は、例えばネットワークサービス
プロバイダがあらかじめ端末毎に与えておいた識別子を
用いて、上位レイヤプロトコルを使って行う等の方法が
考えられる。

【００７４】次のコンテンツの変更（テレビのチャネル
の変更に相当）の際に、端末は上位レイヤプロトコルを
用いて、このコンテンツ変更を要求する。ビデオサーバ
１０１は、使用しているＩＰマルチキャストアドレスを
変更することなく、そのまま用い、変更したコンテンツ
を、該ＩＰマルチキャストアドレス宛に送出する。

【００７５】前述の様に、このＩＰマルチキャストアド
レスは、図１０に示すように、必ずしもマルチキャスト
に用いる必要は無く、単一の端末に対するコンテンツ転
送に用いても良い。即ち、一つ一つのマルチキャストア
ドレスを、ビデオ配信の要求のあったユーザ( 端末) に
割当て、送出コンテンツの変更は、例えば上位レイヤプ
ロトコルにて対応する。

【００７６】また、接続装置１０２から送信されるＩＰ
パケットのポート番号の違いを見て、別々のマルチキャ
ストアドレスを割当てる判断のトリガとしてもよい。こ
のように、ユーザ毎、あるいはアプリケーション毎に別
々のＩＰマルチキャストアドレスを与えるようにするこ
とにより、ＩＰマルチキャストアドレスは端末に対して
動的な割当てが可能であることから、プライベートアド
レス環境においても、グローバルユニークなＩＰアドレ
スとの重複を心配すること無く、種々のコンテンツをプ
ライベートアドレスを持った端末に送信することが可能
となる。

【００７７】なお、本実施例においてはIPマルチキャス
トのデータフローの転送をRSV P を使って帯域予約する
場合を記述してきたが、全く同様の方法をIPユニキャス
ト、あるいは他のネットワークレイヤのユニキャスト、
あるいはマルチキャストについて適用できることは明ら
かである。

【００７８】（第２の実施形態）図１１は、本発明の第
２の実施形態に係るネットワークの構成例を示したもの
で、ＩＥＥＥ１３９４バス上にＩＧＭＰ（Ｉｎｔｅｒｎ
ｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏ
ｃｏｌ）ルータ２１０１、ＩＥＥＥ１３９４の同期リソ
ースマネージャ２１０４、端末２１０２、２１０３が互
いに通信可能なように接続されて構成されている。

【００７９】（２−１）このような構成のネットワーク
において、端末２１０２、２１０３がＩＰマルチキャス
トへ加入して、マルチキャストデータを受信する場合に
ついて説明する。ここで、端末２１０２、２１０３は、
ＩＰマルチキャストへ加入した後は、マルチキャストデ
ータの受信端末となることから、以下、受信端末２１０
２、２１０３と呼ぶ。

【００８０】受信端末２１０２、２１０３がＩＰマルチ
キャストに加入する場合の手順について、図１２を参照
して説明する。また、その際のＩＧＭＰルータ２１０１
の処理手順を図１３に示す。

【００８１】図１１に示したように、ＩＥＥＥ１３９４
バス上には、ＩＧＭＰルータ２１０１、受信端末２１０
２、２１０３、同期リソースマネージャ２１０４が接続
されている。受信端末２１０２のＩＰアドレスは「ＩＰ
１」、受信端末２１０３のＩＰアドレスは「ＩＰ２」で
あるとする。また、同期リソースマネージャ２１０４の
機能は、他の３つの装置のうちのいずれかと一体となっ
ていてもよい（即ち、ＩＧＭＰルータ２１０１あるいは
受信端末２１０２、２１０３のうちのいずれかが同期リ
ソースマネージャであってもよい）。

【００８２】受信端末２１０２、２１０３は、予め何ら
かの手段にてＩＰマルチキャストアドレス「ＩＰｍ」を
取得しているものとする。まず、受信端末２１０２がＩ
Ｐマルチキャストアドレス「ＩＰｍ」に加入を希望して
いるとする。そのため、ＩＧＭＰルータ２１０１と、受
信端末２１０２との間で、ＩＧＭＰメッセージのやり取
り（ＩＧＭＰクエリーやＩＧＭＰレポート等の送受信）
が行なわれ、受信端末２１０２がＩＧＭＰルータ２１０
１に対して、ＩＰマルチキャストアドレス「ＩＰｍ」に
対して加入を希望している旨を伝える（Ｓ２１０１）。
ここで、ＩＧＭＰルータ２１０１は、このＩＰマルチキ
ャストアドレス「ＩＰｍ」のサポートを行なうことので
きるルータであるとする。

【００８３】ＩＧＭＰルータ２１０１は、セットトップ
ボックスのようなものでもよい。即ち、放送波を通じて
送られてくるＩＰマルチキャストパケットの中から、適
当なＩＰマルチキャストアドレス宛のパケットを抽出
し、これをフォワードする機能を持ったノードであって
もよい。

【００８４】ＩＧＭＰルータ２１０１は、受信端末２１
０２からＩＰマルチキャストドレス「ＩＰｍ」への加入
要求を受信すると、図１３のフローチャートに従った処
理を実行する。すなわち、本実施形態の場合、受信端末
２１０２からの加入要求が、そのサブネット（ＩＥＥＥ
１３９４バス）からのＩＰマルチキャストアドレス「Ｉ
Ｐｍ」への最初の加入要求であるため、ＩＧＭＰルータ
２１０１は、所定のＩＰマルチキャストアドレスへの加
入手続き処理を行い（ステップＳ２２０１〜ステップＳ
２２０３）、その手続き処理が成功したら、次に、同期
リソースマネージャ２１０４にアクセスし、同期チャネ
ル番号を確保する（ステップＳ２２０４〜ステップＳ２
２０５、図１２のステップＳ２１０２）。なお、図１３
のステップＳ２２０３において、ＩＧＭＰルータ２１０
１は、さらに上流のＩＧＭＰルータに働きかけ、このＩ
Ｐマルチキャストアドレスへの加入手続きを行なっても
よい。また、加入手続き処理が失敗した場合は、その旨
を受信端末２１０２に通知する（図１３のステップＳ２
２０６）。

【００８５】図１３のステップＳ２２０５において、Ｉ
ＧＭＰルータ２１０１からの要求に応じて同期リソース
マネージャ２１０４にて確保された同期チャネル番号を
「＃ｘ」とする。ここで、同時に帯域を確保する必要は
必ずしもない。これは、この時点で確保されるのはＩＥ
ＥＥ１３９４の非同期ストリームであるからである。

【００８６】非同期ストリームとは、非同期パケットの
アービトレーション時間に送信される、同期パケットの
フォーマットのパケットであり、同期リソースマネージ
ャ２１０４を通じて同期チャネル番号のみが確保され
る。

【００８７】帯域を確保することが必要な場合について
は後述する。図１３の説明に戻り、ＩＧＭＰルータ２１
０１は、同期チャネル番号が確保されると、次に、自ら
のレイヤ３フローレジスタに、このＩＰマルチキャスト
フローについての情報を記入する（ステップＳ２２０
６、図１２のステップＳ２１０３）。

【００８８】図１４は、レイヤ３フローレジスタのフォ
ーマットの一例を示したもので、レイヤ３フローレジス
タは、基本的にレイヤ２識別子（本実施形態の場合、同
期チャネル番号）と、そのレイヤ２識別子であらわされ
るチャネルを通ることになるレイヤ３フローについての
対応関係を登録するためのレジスタである。このレジス
タには、その他に、そのフローが入力されるものである
のか、出力されるものであるのかについての情報、その
レイヤ２識別子であらわされるチャネルに確保された帯
域量、そのチャネルを使用している端末をカウントする
カウンタ等の領域が用意されている。

【００８９】図１４に示すように、ここでは、確保され
たチャネルには帯域が確保されないので、レイヤ３フロ
ーレジスタの帯域の項目欄には、例えば「０」が記入さ
れている。

【００９０】このチャネルに対して宛先がＩＰマルチキ
ャストアドレスが「ＩＰｍ」であるＩＰフローが流れ込
むことになるため、フロー識別子として、受信側ＩＰア
ドレスには「ＩＰｍ」を、受信側ポート番号には、番号
が限定されている時はその番号（例えばＰＯＲＴ１）
を、限定されていない時は例えば「０」を記入する。本
実施形態では、特に限定が無いため「０」を記入する。
ＩＰマルチキャストアドレスは、送信端末は限定されな
いため、送信端末や送信ポート番号にはそれぞれ「０」
が記入される。

【００９１】レイヤ２識別子としては、ここではレイヤ
２種別として「ＩＥＥＥ１３９４」、識別子種別として
「同期チャネル番号」が記入され、識別子としては、先
に確保された同期チャネル番号である「＃ｘ」が記入さ
れる。

【００９２】方向としては、基本的にこのＩＧＭＰルー
タがこれらのＩＰマルチキャストパケットを送信するも
のとして「順方向」とする。コネクションカウンタは、
この非同期ストリームを受信していると考えられるノー
ドの数を表すカウンタである。受信者はこの時点で受信
端末２１０２のみであると考えられるので、カウンタ値
「１」が入力される。

【００９３】なお、このレイヤ３フローレジスタは、Ｉ
ＥＣ１８８３にて使用されるプラグコントロールレジス
タおよびそのチャネルで転送されるレイヤ３フローにつ
いての情報を格納するレジスタの組み合わせの形で実現
しても良い。

【００９４】次に、ＩＧＭＰルータ２１０１は、受信端
末２１０２のレイヤ３フローレジスタに対して、図１４
と同様の情報を書き込む（ステップＳ２２０７、図１２
のステップＳ２１０４）。

【００９５】このようにして、レイヤ３フロー情報と、
レイヤ２識別子との対応関係が、受信端末２１０２のレ
イヤ３フローレジスタに書き込まれることで、受信端末
２１０２は、今後、非同期ストリームのチャネル番号
「＃ｘ」は、ＩＰマルチキャストアドレス「ＩＰｍ」宛
のＩＰマルチキャスト用に割り当てられたことが認識で
きる。受信端末２１０２は、ＩＰマルチキャストアドレ
ス「ＩＰｍ」宛のデータグラムについては、チャネル番
号「＃ｘ」の非同期ストリームを受信すれば良い（ステ
ップＳ２１０５）。

【００９６】なお、上記実施形態では、受信端末２１０
２のレイヤ３フローレジスタ内に、そのチャネル番号で
示される非同期ストリームあるいは同期チャネルから流
れてくるＩＰフローが、入力されてくるのか、出力する
ものなのかについての情報が書かれているが、レイヤ３
フローレジスタを入力用と出力用とを分けて用意してお
き、これらを適当に使い分けることも可能である。

【００９７】さて、図１２の説明に戻り、受信端末２１
０３が続いて同じＩＰマルチキャストアドレス「ＩＰ
ｍ」に加入を希望しているものとする。ＩＧＭＰによる
加入手続きがＩＧＭＰルータ２１０１と受信端末２１０
３の間で行われる（Ｓ２１０６）。

【００９８】そして、ＩＧＭＰルータ２１０１では、図
１３のフローチャートに示したような処理動作を実行す
る。すなわち、ＩＧＭＰルータ２１０１は、すでにこの
ＩＰマルチキャストアドレス「ＩＰｍ」についてのサー
ビスを開始しているため、自らのレイヤ３フローレジス
タのコネクションカウンタをインクリメントし（例え
ば、コネクションカウンタの値を「２」とする）、さら
に受信端末２１０３のレイヤ３フローレジスタに、受信
端末２１０２の同レジスタと同じ情報を書き込んで、チ
ャネル番号とＩＰフローの対応関係を通知する。

【００９９】なお、ＩＰマルチキャストアドレス「ＩＰ
ｍ」に加入している端末数は、ＩＧＭＰルータ２１０１
が把握しており、各端末が把握する必要は必ずしもない
ため、各受信端末２１０２、２１０３の同レジスタに書
き込まれるコネクションカウンタの値は、例えば「１」
でも良い。

【０１００】以上はＩＰマルチキャストアドレスへの加
入手続きについての説明であったが、次に、脱退の時の
ＩＧＭＰルータ２１０１の動作について、図１５に示す
フローチャートを参照して説明する。

【０１０１】脱退の場合、ＩＧＰＭルータ２１０１は、
受信端末のいずれかかからＩＰマルチキャストアドレス
「ＩＰｍ」への脱退手続きを受信した場合（ステップＳ
２３０１）、あるいは、受信端末のいずれかからのＩＰ
マルチキャストアドレス「ＩＰｍ」を受信し続けている
とのキープアライブ信号であるＩＧＭＰ ＲＥＰＯＲＴ
を一定時間以上受信しなかった場合（ステップＳ２３０
２）、当該受信端末が上記ＩＰマルチキャストアドレス
「ＩＰｍ」の受信を止めるものと判断し、自らのレイヤ
３フローレジスタのコネクションカウントの値をデクリ
メントする（ステップＳ２３０３）。

【０１０２】ＩＧＭＰルータ２１０１のレイヤ３フロー
レジスタに書き込まれるコネクションカウントの値は、
そのＩＥＥＥ１３９４バス上における、ＩＰマルチキャ
ストアドレス「ＩＰｍ」に加入している端末の数である
ため、この値が「０」になったとき（ステップＳ２３０
４）、そのＩＥＥＥ１３９４バス上にＩＰマルチキャス
トアドレス「ＩＰｍ」を受信している端末はもはやなく
なったものと判断し、そのＩＰマルチキャストアドレス
「ＩＰｍ」から脱退する（ステップＳ２３０５）。

【０１０３】これと前後して、脱退した受信端末に脱退
した旨を伝えるため、その受信端末のレイヤ３フローレ
ジスタに、例えばオール「０」の値を書き込むなどの動
作を行なってもよい。

【０１０４】なお、このＩＰマルチキャストアドレス加
入、あるいは加入後の一連の過程でＩＥＥＥ１３９４バ
スでバスリセットが引き起こされた場合においても、こ
れらのＩＰマルチキャストアドレスについての情報を保
持しつづけ、レジスタ（レイヤ３フローレジスタ）の値
も保持しておくことで、迅速なＩＰマルチキャストデー
タグラム受信の復帰を行なうことが可能である。

【０１０５】繰り返しになるが、ＩＰマルチキャストア
ドレス「ＩＰｍ」宛ての全てのパケットは、チャネル番
号「＃ｘ」にて表される非同期ストリームを通じて送受
信されるものとなる。なお、ＩＧＭＰ等の制御パケット
については、当該マルチキャストアドレスに対応する非
同期ストリームを使用しても良いし、またはデフォルト
の非同期ストリーム（ＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓ
ｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）やＩＰブロードキ
ャスト等のために割当てられた非同期ストリームのチャ
ネルや非同期のブロードキャストを用いて、これを通信
しても良い。

【０１０６】また、ＩＰマルチキャスト加入時にＩＧＭ
Ｐの制御パケットや、ＩＰアドレス＝「２２４．０．
０．１」等の全ホストが宛先アドレスのＩＰパケット等
が流れるチャネルとしては、デフォルトの非同期ストリ
ーム、もしくは非同期ライトのブロードキャストのいず
れかを使用する。

【０１０７】（２−２）次に、ＩＰマルチキャストを
「帯域（ＱＯＳ）あり」の状態に変更する場合、すなわ
ち、非同期ストリームに対して帯域を与え、これを送受
信する場合について図１６のシーケンス図を参照して説
明する。

【０１０８】受信端末２１０２が、ＩＰマルチキャスト
アドレス「ＩＰｍ」宛のデータグラムを受信できるよう
になるまで（ステップＳ２５０１〜ステップＳ２５０
４）は、図１２のステップＳ２１０１〜ステップＳ２１
０５と同様である。

【０１０９】このＩＰマルチキャストについて、帯域あ
りの伝送が可能である場合、ＩＧＭＰルータ２１０１
は、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉ
ｏｎＳｅｔｕｐ Ｐｒｏｔｏｃｏｌ）のＰＡＴＨメッセ
ージを受信端末（ＩＰマルチキャストアドレス「ＩＰ
ｍ」）に対して送付する（ステップＳ２５０５）。

【０１１０】これに対し、このＩＰマルチキャストを
「帯域あり」の状態で受信したい受信端末２１０２は、
上流側（即ちＩＧＭＰルータ２１０１）に対して、ＲＳ
ＶＰのＲＥＳＶメッセージを送付して、帯域の確保を要
求する（ステップＳ２５０６）。

【０１１１】ＩＰ上の帯域予約プロトコルの一例である
ＲＳＶＰでは、送信ホスト（上流側のノード）がＰＡＴ
Ｈメッセージをデータと共に送信する。通信帯域などは
この送信ホストが基本的に設定する。これに対して、帯
域予約を希望する受信端末は、ＲＥＳＶメッセージを送
信ノード宛てに送信する。一般にルータは、ＰＡＴＨメ
ッセージに対応するＲＥＳＶメッセージを監視して、Ｒ
ＥＳＶメッセージを検出すると帯域予約を実行する。こ
こでは、既に説明したＩＰマルチキャストアドレスとチ
ャネルの対応が設定されているものとする。

【０１１２】受信端末２１０２からのＲＥＳＶメッセー
ジを検出すると、ＩＧＭＰルータ２１０１は、同期リソ
ースマネージャ２１０４にアクセスし、帯域を確保す
る。帯域が確保できた場合は、自らと受信端末２１０１
のレイヤ３フローレジスタに確保した帯域情報（帯域量
ｙ）を記入して、帯域確保に成功した旨を伝える（ステ
ップＳ２５０７〜ステップＳ２５０８）。

【０１１３】その後、帯域の確保された同期チャネル
（チャネル番号「＃ｘ」）を使って、引き続きＩＰマル
チキャストアドレス「ＩＰｍ」宛のデータグラム配送が
行われる（ステップＳ２５０９）。

【０１１４】なお、この時点で複数の受信端末がいる場
合には、各々の受信端末のレイヤ３フローレジスタの帯
域の部分をＩＧＭＰルータ２１０１は書き換えてもよ
い。また、各々の受信端末の同レジスタの書き換えが、
受信端末数が多い時などに面倒な作業となるため、受信
端末の同レジスタの書き換えは行なわず、自ら（ＩＧＭ
Ｐルータ２１０１）のレイヤ３フローレジスタの値のみ
を反映させる方式も考えられる。

【０１１５】以上説明したように、非同期ストリームに
対して帯域を与える際には、ＱＯＳパケットを送信する
ノードが帯域の確保を行うというルールに従うことによ
り、複数の受信端末が同時に同じチャネルに対して帯域
を確保してしまうような、いわゆる帯域の２重確保を回
避することが可能である。また、通常必要な帯域は送信
ノードがその値を把握している場合が多いと考えられる
ため、この観点からも妥当である。

【０１１６】（２−３）さて、これまではレイヤ３フロ
ーレジスタを使って、ＩＰマルチキャストフローと、そ
のフローが流れる同期チャネルまたは非同期ストリーム
のチャネル番号の対応関係を通知してきたが、これをＦ
ＡＮＰ（Ｆｌｏｗ ＡｔｔｒｉｂｕｔｅＮｏｔｉｆｉｃ
ａｔｉｏｎＰｒｏｔｏｃｏｌ）を用いて行なうことも可
能である。ＦＡＮＰは、ＩＰデータグラムを用いて、あ
るデータリンクレイヤのチャネル（例えばＩＥＥＥ１３
９４の同期チャネルや非同期ストリーム、あるいはＡＴ
Ｍやフレームリレーの仮想チャネル等）と、そのチャネ
ルを通る上位レイヤのフロー（例えばＩＰフロー）の対
応関係を通知するプロトコルである。

【０１１７】この場合の手順を図１７に示すシーケンス
図を参照して説明する。受信端末２１０２がＩＰマルチ
キャストアドレス「ＩＰｍ」への加入を希望している場
合、ＩＧＭＰを使った加入手続きは、ＩＧＭＰルータ２
１０１との間で図１２の場合と同様に行なわれる（ステ
ップＳ２６０１）。ＩＧＭＰルータ２１０１は、このＩ
Ｐマルチキャストアドレス「ＩＰｍ」のためのチャネル
を確保するべく、同期リソースマネージャ２１０４にア
クセスし、チャネル番号「＃ｘ」を確保する（ステップ
Ｓ２６０２）。

【０１１８】次に、ＩＧＭＰルータ２１０１は、受信端
末２１０２に対して、「チャネル「＃ｘ」を通して、Ｉ
Ｐマルチキャスト「ＩＰｍ」を提供する」旨を通知する
ため、ＩＥＥＥ１３９４のプラグコントロールレジスタ
とＦＡＮＰを使う。

【０１１９】プラグコントロールレジスタとは、あるチ
ャネル番号を使って提供される、同期チャネル／非同期
ストリームを受信、あるいは送信するように促す作用の
あるレジスタであり、入力用と出力用が分かれている。
このプラグコントロールレジスタを使って、ＩＧＭＰル
ータ２１０１は、受信端末２１０２に対して、チャネル
「＃ｘ」を受信するように促す（ステップＳＳ６０
３）。なお、その際、ＩＧＭＰルータ２１０１は、自ら
のプラグコントロールレジスタについても記入を行なっ
てもよい。この場合は、コネクションカウンタに前例と
同様なルールで、そのＩＰマルチキャストアドレスの受
信端末の数を記入していってもよい。これにより、その
マルチキャストをそのチャネルから受信しているノード
数などの把握を行うことが可能である。

【０１２０】次に、ＩＧＭＰルータ２１０１は、ＦＡＮ
Ｐオファーメッセージとして、図１８のようなメッセー
ジを受信端末２１０２に送付する。このＦＡＮＰメッセ
ージの宛先はＩＰマルチキャストアドレス「ＩＰｍ」で
あり、また、このＦＡＮＰメッセージはＩＥＥＥ１３９
４バスに割り当てられたレイヤ３パケットのブロードキ
ャストチャネル（例えば、特定の非同期ストリームや、
ノードＩＤ＝オール「１」宛のパケット）で送付され
る。

【０１２１】図１８に示すように、ＦＡＮＰオファーメ
ッセージには、フロー識別子とレイヤ２識別子が含ま
れ、前述したようなレイヤ２識別子（本実施形態の場
合、チャネル番号「＃ｘ」）と、このレイヤ２識別子で
あらわされるチャネルを通して提供される上位レイヤフ
ロー（本実施形態の場合、ＩＰマルチキャストアドレス
「ＩＰｍ」）との対応関係を通知する（Ｓ２６０４）。

【０１２２】その後、このチャネル「＃ｘ」を通じて、
ＩＰマルチキャストアドレス「ＩＰｍ」宛のデータグラ
ムが送信されることになる（ステップＳ２６０５）。同
様に、他の受信端末２１０２からの加入要求があった場
合（ステップＳ２６０６）も、プラグコントロールレジ
スタへの書き込みと（ステップＳ２６０７）、ＦＡＮＰ
メッセージの送付（ステップＳ２６０８）を行なうこと
で、対応関係の通知を行なうことができる。

【０１２３】なお、この場合、ＦＡＮＰメッセージは、
ＩＰマルチキャストアドレス宛であるため、受信端末が
複数の場合であっても、必ずしもいちいち各々の受信端
末宛にＦＡＮＰメッセージを送付する必要は必ずしもな
く、ＩＰマルチキャストアドレス「ＩＰｍ」宛のデータ
グラムを１回送信すればよいので、ＩＥＥＥ１３９４バ
ス上のトラヒックを減らすことが出きる点で有利であ
る。

【０１２４】さて、本実施形態においては、プラグコン
トロールレジスタとＦＡＮＰオファーメッセージを使っ
て、レイヤ２識別子とレイヤ３フローの対応関係を通知
してきた。ここで、ＦＡＮＰメッセージを使わないと上
記対応関係の通知はできないが、プラグコントロールレ
ジスタへの書き込みにより、受信端末はこの同期チャネ
ルからのデータ受信は行なうようになるため、必ずしも
上記対応関係の通知が必要ない場合は、上記ＦＡＮＰメ
ッセージの送付は省略してもよい。また逆に、ＦＡＮＰ
メッセージがあれば、受信端末はどのチャネル番号から
どのレイヤ３フローが入力されてくるのかを認識するこ
とが可能であるため、プラグコントロールレジスタへの
書き込み手順を省略することも可能である。

【０１２５】（２−４）次に、同じＩＰマルチキャスト
アドレスを用いて、複数のフローが送信される場合の手
順を図１９に示すシーケンス図を参照して説明する。

【０１２６】図１９では、ＩＧＭＰルータ２１０１から
受信端末２１０１に向ってＩＰマルチキャストアドレス
が「ＩＰｍ」のマルチキャストパケットが送信される場
合、ポート番号が「ＰＯＲＴ１」で表されるフロー（ス
テップＳ２８０４）と、「ＰＯＲＴ２」で表されるフロ
ー（ステップＳ２８０５）の計２つのフローが同時に送
信される場合を示している。

【０１２７】ＩＧＭＰによるマルチキャストアドレスへ
の加入（ステップＳ２８０１）、ＩＧＭＰルータ２１０
１による同期チャネル番号の確保（ステップＳ２８０
２）については、前述同様である。

【０１２８】ステップＳ２８０３で、レイヤ３フローレ
ジスタの書き込みを行う際には、特に、ステップＳ２８
０２で確保した同期チャネル番号「＃ｘ」で表される非
同期ストリームに送信されるフローは特に限定されず、
単にＩＰマルチキャストアドレス「ＩＰｍ」のパケット
が送信される事のみが限定されることから、ステップＳ
２８０４とステップＳ２８０５の両方のフローが、チャ
ネル番号「＃ｘ」で表される非同期ストリームにて転送
される。

【０１２９】さて、このうちＩＧＭＰルータ２１０１
は、「ＰＯＲＴ１」で表されるフローについては、ＱＯ
Ｓありの送信を許容しているものとする。そのため、Ｉ
ＧＭＰルータ２１０１は、ＲＳＶＰのＰＡＴＨメッセー
ジをＩＰマルチキャストアドレス「ＩＰｍ」宛てに送信
する（ステップＳ２８０６）。これに対し、受信端末２
１０１はＲＥＳＶメッセージを送信することで、帯域の
確保を要求する（Ｓ８０７）。すると、ＩＧＭＰルータ
は、同期リソースマネージャにアクセスし、ＲＳＶＰメ
ッセージで指定された、必要な帯域を確保する。ここで
は、この値を「ｙ」とする（ステップＳ２８０８）。

【０１３０】すると、ＩＧＭＰルータ２１０１は、受信
端末２１０２に対して、同期チャネル番号「＃ｘ」を通
して帯域量「ｙ」のデータが、同期チャネルのアービト
レーション周期にて送信されることを受信端末２１０２
に通知するため、受信端末２１０２のレイヤ３フローレ
ジスタに書き込む（ステップＳ２８０９）。ステップＳ
２８０９において、受信端末２１０２に通知する内容
は、レイヤ３フローレジスタを用いる場合に限らず、前
述したＦＡＮＰ、あるいはＩＥＣ１８８３のプラグコン
トロールレジスタを用いても通知できる。どれを用いる
かはシステムに依存である。

【０１３１】その後のＩＧＭＰルータ２１０１からのＩ
Ｐマルチキャストデータの送信は、帯域確保がされてい
ない「ＰＯＲＴ２」で示されるフローについては、ステ
ップＳ２８０５でのフローと同様、非同期ストリームを
通して送信されるが（ステップＳ２８１１）、帯域確保
を行った「ＰＯＲＴ１」で表されるフローについては、
同期チャネルとして（即ち、同期のアービトレーション
期間にて）送信される（ステップＳ２８１０）。

【０１３２】さて、ＩＧＭＰルータ２１０１において、
同期チャネル「＃ｘ」で確保した帯域量「ｙ」以上の帯
域のＩＰマルチキャストデータ（「ＩＰｍ」宛てのＩＰ
マルチキャストパケット）が入り込む可能性がある。こ
れらのパケットをそのまま同期チャネル「＃ｘ」に流し
込むことは、確保していない帯域分も、このＩＰマルチ
キャストパケットが通信資源を消費してしまうことを意
味し、望ましくない。

【０１３３】そこで、図２０のようなアルゴリズムを用
いて、帯域が確保されている分については同期チャネル
に（ステップＳ２９０１、ステップＳ２９０２）、確保
されていない分については非同期ストリームに（ステッ
プＳ２９０１、ステップＳ２９０３）それぞれ送信する
というルールを作ることにより、確保した以上の帯域量
のデータを、該同期チャネルに流し込んでしまうことを
防ぐことが出来る。

【０１３４】ここで、Ｔスペックとは、ＲＳＶＰの予約
の時に指定されるトラヒックパラメータのことで、ピー
クレートやリーキーバケットのバケツの深さ等が指定さ
れてもよい。

【０１３５】図２０のメカニズムを実現するための構成
例を図２１に示す。ＷＦＱとは、Ｗｅｉｇｈｔｅｄ Ｆ
ａｉｒ Ｑｕｅｕｅｉｎｇの略で、１つの出力ポートを
複数のセンダ／フローからのパケットが共有する場合
に、フロー毎にあらかじめ指定された量（重みという）
の比に従って、送出されるパケット量の比もこれと同じ
にするパケットスケジューリング方法である。

【０１３６】ＷＦＱ処理部２２０１は、このＷＦＱのス
ケジューリングで、Ｔスペックを満たすものについて
は、同期キュー２２０２に、満たさないものについては
非同期キュー２２０３に入れるものとし、同期キューに
溜められたデータは、パケット送信部２２０４を介して
同期のアービトレーション期間に、非同期キューに溜め
られたデータは、パケット送信部２２０４を介して非同
期のアービトレーション期間にそれぞれ送信される。

【０１３７】以上は、帯域を確保した場合にも、同期チ
ャネル番号は同じ値を続けて使用する使い方についてで
あった。これに対して、帯域確保が必要なチャネルにつ
いては、非同期ストリームで利用していたチャネル
（「＃ｘ」）とは別の同期チャネル（「＃ｚ」）を確保
する方法も考えられる。

【０１３８】この場合の手順について、図２２のシーケ
ンス図を参照して説明する。図２２のステップＳ３１０
１〜ステップＳ３１０７において、ＲＳＶＰのＲＥＳＶ
メッセージにて、帯域確保の要求（ＲＥＳＶ）が受信端
末２１０１からあるまでは、図１９のステップＳ２８０
１〜ステップＳ２８０７と同様である。

【０１３９】ステップＳ３１０７で、帯域の確保要求を
受け取ると、ＩＧＭＰルータ２１０１は、これまで使用
していた非同期ストリームのチャネル番号（「＃ｘ」）
とは異なる、同期チャネル番号（「＃ｚ」）と帯域量
（ｙ）の両方の確保を行う（ステップＳ３１０８、ステ
ップＳ３１０９）。

【０１４０】この場合も「送信者（すなわち、本実施形
態の場合、ＩＧＭＰルータ２１０１）が、リンクレイヤ
の必要な帯域を確保する」というルールに従っている。
その後、ＩＧＭＰルータ２１０１は、受信端末２１０２
のレイヤ３フローレジスタに、「ＰＯＲＴ１」で表され
るフローについては、同期チャネル番号「＃ｚ」で表さ
れる（非同期ストリームではなくて）同期チャネルを用
いて送信されることを書き込むことで、受信端末２１０
２に通知する（ステップＳ３１１０）。なお、ステップ
Ｓ３１１１において、受信端末２１０２に通知する内容
は、レイヤ３フローレジスタを用いる場合に限らず、前
述のように、ＩＥＣ１８８３のプラグコントロールレジ
スタや、ＦＡＮＰを用いて行うこともできる。

【０１４１】以後、ＩＰマルチキャストアドレス「ＩＰ
ｍ」宛てのパケットのうち、「ＰＯＲＴ１」で表される
フローについては、同期チャネル「＃ｚ」を通して、同
期チャネルで転送され（ステップＳ３１１１）、それ以
外のフローについては、引き続き非同期ストリームにて
送信され続ける（ステップＳ３１１２）。

【０１４２】（２−５）次に、１つのチャネル番号で示
される非同期ストリームあるいは同期チャネルを用い
て、複数のマルチキャストデータのセンダがいる場合に
ついて、図２３を参照して説明する。なお、ここでは、
図１１の端末２１０２、２１０３は、ＩＰマルチキャス
トへ加入した後は、マルチキャストデータの送受信端末
となり、以下、端末２１０２、２１０３を端末Ａ、端末
Ｂと呼ぶ。

【０１４３】図２３は、同一のＩＰマルチキャストアド
レス「ＩＰｍ」に対して、端末Ａ（ＩＰアドレス「ＩＰ
１」、１３９４アドレス「ＦＷ１」）と、端末Ｂ（ＩＰ
アドレス「ＩＰ２」、１３９４アドレス「ＦＷ２」）の
２つの端末がＩＰマルチキャストパケットを送信する場
合を示している。ここで、１３９４アドレスとは、例え
ばＩＥＥＥ１３９４のノードＩＤ等、そのＩＥＥＥ１３
９４バス上でその端末を一意に識別することの出来るＩ
Ｄを指す。

【０１４４】図２３のステップＳ３２０１〜ステップＳ
３０４、ステップＳ３２０６〜ステップＳ３３２０８の
マルチキャストへの加入、チャネル番号の確保、ＩＰマ
ルチキャストアドレスとチャネル番号との対応関係の通
知の手順は、図１１と同様である。

【０１４５】特徴的な点は、端末Ａ、Ｂのそれぞれは、
ＩＰマルチキャストパケットに同一のチャネル番号「＃
ｘ」で表されるチャネルに、自らのソースアドレス
（「ＦＷ１」または「ＦＷ２」）を付加して当該パケッ
トを送信する（ステップＳ３２０５、Ｓ３２０９、Ｓ３
２１０）ことである。

【０１４６】このソースアドレスは、フラグメントヘッ
ダと呼ばれる、ＩＰパケットを１３９４フレームに分割
する時に、そのそれぞれの分割片に付与するヘッダに書
き込まれる。

【０１４７】端末Ａ、Ｂのそれぞれから送出されるＩＰ
マルチキャストのデータ構成の概略を図２４に示す。な
お、図２４（ａ）は端末Ａから送出されるＩＰマルチキ
ャストのデータ構成で、図２４（ｂ）は端末Ｂから送出
されるＩＰマルチキャストのデータ構成である。図２４
（ａ）、（ｂ）に示すように、ＩＰマルチキャストパケ
ット（あるいはこれをフラグメントしたもの）３３０
１、３３０４をソースアドレスを含むフラグメントヘッ
ダでカプセル化して生成されたフラグメントデータ３３
０２、３３０５を、更に１３９４フレーム１３０３（こ
の場合、同期フレーム）に収めて構成される。

【０１４８】受信者は、同一のチャネル番号で示される
非同期ストリームから、複数のセンダからのパケットを
受け取ることになるが、このようにソースアドレスがそ
れぞれのフレームに付与されていることで、各々のパケ
ットのリアセンブリを、ソースアドレスを参照すること
により、正確に行うことが出来るようになる。

【０１４９】以上は、同一のＩＰマルチキャストアドレ
スに対して、複数のセンダが送信する場合において、帯
域確保が伴わない場合についての説明であった。これに
対し、帯域確保を伴う場合の説明を以下に行う。

【０１５０】図２５において、例えば、図２３のＳ３２
０１〜Ｓ３２１０の手順が終了し、非同期ストリームの
形で２つのセンダ、すなわち、端末Ａと端末Ｂとから同
一のＩＰマルチキャストアドレス「ＩＰｍ」宛てのＩＰ
マルチキャストパケットが送信されているものとする
（ステップＳ３４０１、ステップＳ３４０２）。

【０１５１】ここで、端末Ａが、何等かの形で帯域あり
の形でのＩＰマルチキャストデータの送信を依頼された
場合（例えばＲＳＶＰのＲＥＳＶを受信した場合等）
や、帯域ありの形でのデータ送信を自ら選択した様な場
合、同期リソースマネージャ２１０４にアクセスして帯
域量（ｙ１）を確保要求を行って（ステップＳ３４０
３）、以後、端末Ａは、送信するＩＰマルチキャストの
パケットは、確保された帯域量ｙ１の同期チャネルを通
して、かつ、同期のアービトレーション期間に送信する
（ステップＳ３４０４）。ここで、帯域確保をしていな
い端末Ｂは、同じチャネル番号「＃ｘ」にＩＰマルチキ
ャストパケットを送信し続けているものの、送信は非同
期ストリームとして、非同期のアービトレーション期間
に送信する（ステップＳ３４０５）。

【０１５２】端末Ｂが帯域ありの形で送信する場合は、
端末Ｂも同期リソースマネージャ２１０４にアクセスし
て、やはり所望の帯域を確保し（ステップＳ３４０
６）、データ送信を同期のアービトレーション期間内に
行うことになる（ステップＳ３４０８）。

【０１５３】先に確保された帯域をキャンセルする場合
は、同期リソースマネージャ２１０４に対し、その帯域
をキャンセルするための要求を行い（ステップＳ３４０
９）、同期のアービトレーション周期にはパケットを送
信しないようにし、もし送信パケットがある場合には、
非同期ストリーム（非同期のアービトレーション期間）
に送信する（ステップＳ３４１０）。

【０１５４】これに対して、帯域ありの形でＩＰマルチ
キャストを送信する場合には、非同期ストリームで使用
していたチャネル番号「＃ｘ」とは別のチャネル番号
「＃ｚ」を持つ同期チャネルで、これを送信する方法も
考えられる。この場合について、図２６のシーケンス図
を参照して説明する。

【０１５５】図２６において、例えば、図２３のＳ３２
０１〜Ｓ３２１０の手順が終了し、非同期ストリームの
形で２つのセンダ、すなわち、端末Ａと端末Ｂとから同
一のＩＰマルチキャストアドレス「ＩＰｍ」宛てのＩＰ
マルチキャストパケットが送信されているものとする
（ステップＳ３５０１、ステップＳ３５０２）。

【０１５６】このとき、例えば、ＲＳＶＰのＲＥＳＶメ
ッセージなどで、帯域ありの形でのＩＰマルチキャスト
パケットの送信を依頼された（例えば、図２６に示した
ように、端末ＡからのＲＳＶＰのＰＡＴＨメッセージに
を受けて端末ＢからＲＥＳＶメッセージを受信したと
き）、端末Ａは、同期リソースマネージャ２１０４にア
クセスし、同期チャネル番号「＃ｚ」の確保と、帯域量
「ｙ１」の確保を行う（ステップＳ３５０３〜ステップ
Ｓ３５０６）。

【０１５７】続いて、確保した同期チャネル番号と、そ
の同期チャネルを通して送信するフローの対応関係を通
知するためのＦＡＮＰメッセージを、該ＩＰマルチキャ
ストアドレス「ＩＰｍ」宛てに、例えば非同期ストリー
ム「＃ｘ」、またはデフォルトの非同期ストリームなど
で送信する（ステップＳ３５０７）。これを受信したノ
ードは、どの同期チャネルから、どのようなフローがど
のような特性で入力されてくるかを認識することが出来
るようになる。なお、前述のように、ここではＦＡＮＰ
メッセージを用いて、この対応関係の通知を行っている
が、これはレイヤ３フローレジスタ、あるいはＩＥＣ１
８８３において使用されるプラグコントロールレジスタ
を用いても実現が可能なものである。

【０１５８】

【発明の効果】以上説明したように、第１の発明（第１
の実施形態）によれば、ＲＳＶＰ等のネットワークレイ
ヤのシグナリングプロトコルをＩＥＥＥ１３９４上で運
用する方式がいまだ決まっておらず、そのままマッピン
グを行うと、ＩＥＥＥ１３９４上では通信品質が確保さ
れず、エンドエンドの通信品質が保たれないという問題
点に対し、ＲＳＶＰのＩＥＥＥ１３９４バス上での適用
方法を示し、ＩＥＥＥ１３９４上でも、相互接続環境で
の通信品質を確保した通信が可能となる。

【０１５９】また、第２の発明（第２の実施形態）によ
れば、ＩＥＥＥ１３９４等の放送型ネットワークにおい
て、通信資源を有効に利用してＩＰマルチキャストを行
うことができ、また、確保したチャネルとＩＰマルチキ
ャストアドレスとの対応関係を送信側、受信側で同期し
て認識することのできる。

【図面の簡単な説明】

【図１】本発明の第１の実施形態に係るネットワーク全
体の構成例を示したもので、映像サービスを提供してい
るビデオサーバからのデータを、公衆網を介して家庭内
ネットワークにとりこみ、家庭内ネットワークに接続さ
れた端末で、該サービスを受ける状況を説明するための
図。

【図２】図１の端末が接続装置、公衆網を通してビデオ
サーバからビデオを転送してもらうまでの全体の処理手
順を示した図で、ＩＥＥＥ１３９４上の通信資源予約を
ＲＳＶＰの上流のノードが行う場合を示している。

【図３】図１の端末が接続装置、公衆網を通してビデオ
サーバからビデオを転送してもらうまでの端末の処理手
順を示した図。

【図４】図１の端末が接続装置、公衆網を通してビデオ
サーバからビデオを転送してもらうまでの接続装置の処
理手順を示した図。

【図５】接続装置に記憶される対応テーブルの一例を示
した図。

【図６】ＲＳＶＰのＰＡＴＨメッセージのフォーマット
の一例を示した図。

【図７】ＩＥＥＥ１３９４のＰＣＲレジスタの記述例を
示した図。

【図８】図１の端末が接続装置、公衆網を通してビデオ
サーバからビデオを転送してもらうまでの通信システム
全体の処理手順を示した図で、ＩＥＥＥ１３９４上の通
信資源予約をＲＳＶＰの下流のノードが行う場合を示し
ている。

【図９】すでに加入したＩＰマルチキャストアドレスを
離脱して異なるＩＰマルチキャストアドレスに加入し、
異なるコンテンツの配送を行う場合について説明するた
めの図。

【図１０】ＩＰマルチキャストアドレスは同じで、コン
テンツが変わる場合について説明するための図。

【図１１】本発明の第２の実施形態に係るネットワーク
（ＩＥＥＥ１３９４バス）全体の構成例を示した図。

【図１２】受信端末がＩＰマルチキャストに加入する場
合の手順を説明したシーケンス図。

【図１３】ＩＧＭＰルータにおけるＩＰマルチキャスト
アドレスへの加入時の処理手順を説明するためのフロー
チャート。

【図１４】レイヤ３フローレジスタのフォーマットの一
例を示した図。

【図１５】ＩＧＭＰルータにおけるＩＰマルチキャスト
アドレスからの脱退時の処理手順を説明するためのフロ
ーチャート。

【図１６】ＩＰマルチキャストのために確保された非同
期ストリームに対して帯域を与える場合の手順を説明す
るためのシーケンス図。

【図１７】ＩＰマルチキャストフローとチャネル番号の
対応関係をＦＡＮＰを用いて行う場合の手順を説明する
ためのシーケンス図。

【図１８】ＦＡＮＰオファーメッセージの一例を示した
図。

【図１９】同じＩＰマルチキャストアドレスを用いて、
複数のフローが送信される場合の手順を説明するための
シーケンス図。

【図２０】同期チャネルに予め確保されている帯域量以
上のＩＰマルチキャストデータを送信する場合のＩＧＭ
Ｐルータの処理動作について説明するためのフローチャ
ート。

【図２１】図２０のアルゴリズムを実現するための構成
例を示した図。

【図２２】ＩＰマルチキャストのために確保された非同
期ストリームに対して帯域を与え、その帯域を与えられ
た同期チャネルには非同期ストリームとは異なるチャネ
ル番号を用いる場合の手順を説明するためのシーケンス
図。

【図２３】同一のＩＰマルチキャストアドレスに対して
複数のセンダがいる場合の手順を説明するためのシーケ
ンス図。

【図２４】端末Ａ、Ｂのそれぞれから送出されるＩＰマ
ルチキャストのデータ構成の概略を示した図。

【図２５】同一のＩＰマルチキャストアドレスに対して
複数のセンダが送信する場合において、さらに帯域確保
を伴う場合の手順を説明するためのシーケンス図。

【図２６】同一のＩＰマルチキャストアドレスに対して
複数のセンダが送信する場合において、さらに帯域確保
を伴う場合には、非同期ストリームとは異なるチャネル
番号を用いる場合の手順を説明するためのシーケンス
図。

【符号の説明】

１０１…ビデオサーバ（通信装置、送信端末） １０２…接続装置（通信制御装置） １０３…端末（通信装置） １０４…公衆網 １０５…第１の家庭内ネットワーク（ＩＥＥＥ１３９
４） １０６…第２の家庭内ネットワーク ２１０１…ＩＧＭＰルータ（通信装置） ２１０２…端末装置（受信端末、通信装置） ２１０３…端末装置（受信端末、通信装置） ２１０４…同期リソースマネージャ

Claims (13)

【特許請求の範囲】
1. 【請求項１】 放送型のネットワークに接続された通信
   装置であって、 前記ネットワークに接続された第２の通信装置から、ネ
   ットワークレイヤデータフローを識別する識別子を含
   み、かつ前記ネットワークレイヤデータフローに対応す
   る帯域の確保要求を含む第１のメッセージを受信する受
   信手段と、 この受信手段で受信した第１のメッセージに基づき前記
   ネットワーク上に放送型チャネルを確立する確立手段
   と、 少なくとも前記確立された放送型チャネルの識別子と前
   記ネットワークレイヤデータフローの識別子との対応関
   係を含む第２のメッセージを前記第２の通信装置に送信
   する送信手段と、 を具備したことを特徴とする通信装置。
2. 【請求項２】 前記第1 のメッセージは、帯域の確保要
   求のためのメッセージであり、前記ネットワークレイヤ
   データフローの下流方向に接続された前記第2 の通信装
   置から送信されたものであることを特徴とする請求項１
   記載の通信装置。
3. 【請求項３】 前記第1 のメッセージは、使用帯域の通
   知のためのメッセージであり、前記ネットワークレイヤ
   データフローの上流方向に接続された前記第2 の通信装
   置から送信されたものであることを特徴とする請求項１
   の通信装置。
4. 【請求項４】 前記ネットワークレイヤフローの上流方
   向に接続された前記第2 の通信装置に対し、帯域の確保
   要求のためのメッセージを送信する送信手段を更に具備
   したことを特徴とする請求項３記載の通信装置。
5. 【請求項５】 前記第2 のメッセージの送信は、前記第
   2 の通信装置に備えられたレジスタへの書き込みの形に
   て行われることを特徴とする請求項１記載の通信装置。
6. 【請求項６】 放送型のネットワークに接続された通信
   装置であって、 前記ネットワーク上に確立されたネットワークレイヤデ
   ータフローを送受信する際に必要な放送型チャネルの識
   別子と前記ネットワークレイヤデーターフローの識別子
   との対応関係を記述するレジスタと、 前記放送型チャネルを通じて、前記ネットワークレイヤ
   データフローを送受信する手段と、 を具備したことを特徴とする通信装置。
7. 【請求項７】 放送型のネットワークに接続された通信
   装置であって、 前記ネットワークに接続された第２の通信装置から、ネ
   ットワークレイヤマルチキャストアドレスへの加入申請
   を受け付ける受付手段と、 前記加入申請に応じて前記ネットワーク上に放送型チャ
   ネルを確立する確立手段と、 少なくとも前記確立された放送型チャネルの識別子と前
   記ネットワークレイヤマルチキャストアドレスとの対応
   関係を前記第２の通信装置に通知する通知手段と、 前記ネットワークレイヤマルチキャストアドレス宛ての
   データを前記確立された放送型のチャネルに送出する送
   出手段と、 を具備したことを特徴とする通信装置。
8. 【請求項８】 前記第２の通信装置からの前記ネットワ
   ークレイヤマルチキャスト宛てのデータを受信する際に
   必要な帯域の確保要求を前記第２の通信装置から受け付
   ける第２の受付手段と、 前記確立された放送型チャネルの帯域を確保する確保手
   段と、 をさらに具備したことを特徴とする請求項７記載の通信
   装置。
9. 【請求項９】 放送型のネットワークに接続され、ネッ
   トワークレイヤマルチキャストアドレス宛てのデータを
   送信する通信装置であって、 前記ネットワーク上に確立されている放送型チャネルに
   対する通信帯域を確保する確保手段と、 前記放送型チャネルに帯域が確保されていない場合に、
   前記ネットワークレイヤマルチキャストアドレス宛ての
   データを前記放送型チャネルの帯域が確保されていない
   周期あるいはコネクションで送信する第1 の送信手段
   と、 前記確保手段により前記放送型チャネルに帯域が確保さ
   れた場合に、前記ネットワークレイヤマルチキャストア
   ドレス宛てのデータを前記放送型チャネルの帯域が確保
   されていない周期あるいはコネクションから、前記放送
   型チャネルの帯域が確保された周期あるいはコネクショ
   ンに切り替えて送信する第2 の送信手段と、 を具備したことを特徴とする通信装置。
10. 【請求項１０】 前記確保手段で帯域が確保された場合
    の前記第1 の送信手段から出力される放送型チャネルの
    識別子は、帯域が確保されていない場合の前記第2 の送
    信手段から出力される放送型チャネルの識別子と同一の
    識別子であることを特徴とする請求項９記載の通信装
    置。
11. 【請求項１１】 放送型のネットワークに接続された通
    信装置から送信されたネットワークレイヤデータフロー
    を識別する識別子と前記ネットワークレイヤデータフロ
    ーに対応する帯域の確保要求を含む第１のメッセージを
    受信したとき、この第１のメッセージに基づき前記ネッ
    トワーク上に放送型チャネルを確立し、少なくとも前記
    確立された放送型チャネルの識別子と前記ネットワーク
    レイヤデータフローの識別子との対応関係を含む第２の
    メッセージを前記通信装置に送信することを特徴とする
    通信方法。
12. 【請求項１２】 放送型のネットワークに接続された通
    信装置からのネットワークレイヤマルチキャストアドレ
    スへの加入申請に応じて前記ネットワーク上に放送型チ
    ャネルを確立し、少なくとも前記確立された放送型チャ
    ネルの識別子と前記ネットワークレイヤマルチキャスト
    アドレスとの対応関係を前記通信装置に通知した後、前
    記ネットワークレイヤマルチキャストアドレス宛てのデ
    ータを前記確立された放送型のチャネルに送出すること
    を特徴とする通信方法。
13. 【請求項１３】 放送型のネットワークに接続され、ネ
    ットワークレイヤマルチキャストアドレス宛てのデータ
    を送信する通信方法において、 前記ネットワーク上に確立されている放送型チャネルに
    通信帯域が確保されていない場合に、前記ネットワーク
    レイヤマルチキャストアドレス宛てのデータを前記放送
    型チャネルの帯域が確保されていない周期あるいはコネ
    クションで送信し、 前記ネットワーク上に確立されている放送型チャネルに
    対して通信帯域が確保された場合に、前記ネットワーク
    レイヤマルチキャストアドレス宛てのデータを、前記放
    送型チャネルの帯域が確保されていない周期あるいはコ
    ネクションから、前記放送型チャネルの帯域が確保され
    た周期あるいはコネクションに切り替えて送信すること
    を特徴とする通信方法。