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

Abstract

(57)【要約】 【課題】ＩＥＥＥ１３９４等の放送型ネットワークにお
いて、通信資源を有効に利用してＩＰマルチキャストを
行うことができ、また、確保したチャネルとＩＰマルチ
キャストアドレスとの対応関係を送信側、受信側で同期
して認識することのできる通信装置を提供する。 【解決手段】前記ネットワークに接続された第２の通信
装置から、ネットワークレイヤマルチキャストアドレス
への加入申請を受け付ける受付手段と、前記加入申請に
応じて前記ネットワーク上に放送型チャネルを確立する
確立手段と、少なくとも前記確立された放送型チャネル
の識別子と前記ネットワークレイヤマルチキャストアド
レスとの対応関係を前記第２の通信装置に通知する通知
手段と、前記ネットワークレイヤマルチキャストアドレ
ス宛てのデータを前記確立された放送型のチャネルに送
出する送出手段とを具備する。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

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

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

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

【０００７】

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

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

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

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

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

【００１２】

【課題を解決するための手段】

１） 上記（問題点１）を解決するための手段 （請求項１、３、５）本発明の通信制御装置は、放送型
のネットワーク（例えばＩＥＥＥ１３９４）に接続され
た通信装置であって、前記ネットワークに接続された第
２の通信装置から、ネットワークレイヤマルチキャスト
データフローを識別する識別子と、前記ネットワークレ
イヤマルチキャストデータフローに対応する帯域の確保
要求を含む第１のメッセージを受信する受信手段と、こ
の受信手段で受信した第１のメッセージに基づき前記ネ
ットワーク上に放送型チャネル（例えば、ＩＥＥＥ１３
９４の同期チャネル）を確立する確立手段と、少なくと
も前記確立された放送型チャネルの識別子と前記ネット
ワークレイヤマルチキャストデータフローの識別子との
対応関係を含む第２のメッセージを前記第２の通信装置
に送信する送信手段と、を具備したことにより、例えば
ＲＳＶＰにて上流側のノードが下流側にＩＥＥＥ１３９
４の同期チャネルを予約することにより、前記受信手段
で受信した、例えばＲＳＶＰのＲＥＳＶメッセージで示
される、要求されている通信資源を、ＩＥＥＥ１３９４
バスの同期チャネルという形で確保することが可能とな
り、もって、ネットワークレイヤレベルのシグナリング
プロトコルで実現されるべき、エンド・エンドの通信資
源の確保された通信が実現可能となる。また、前記送信
手段を持つことにより、例えば、ＲＳＶＰのＲＥＳＶメ
ッセージに対応したＩＥＥＥ１３９４バス上で確保され
た通信資源（即ち同期チャネル）についての情報を受信
端末は入手することが可能となり、もって、受信端末は
ＲＳＶＰを使って予約した受信データを、通信資源が伴
う形で受信することが可能となる（図２参照）。

【００１３】また、前記通信資源の確保要求を含む第１
のメッセージ（例えば、ＲＳＶＰのＲＥＳＶメッセー
ジ）およびまたは前記対応関係を含む第２のメッセージ
（例えば、ＲＳＶＰのＰＡＴＨメッセージ）は、インタ
ーネット上でデータを送受信する際の通信資源の確保要
求プロトコルのメッセージであることにより、前記対応
関係の通知のための別メッセージを用意する必要がなく
なるとともに、ＰＡＴＨメッセージと、前記別メッセー
ジの対応付けを行うためのテーブルなどを受信側装置(
例えば受信端末や中継ルータ) が用意する必要も無くな
る。

【００１４】（請求項５、６） 本発明の通信装置は、
放送型のネットワークに接続された通信装置であって、
前記ネットワーク上に確立されたネットワークレイヤマ
ルチキャストデータフローを送受信する際に必要な帯域
の保証された放送型チャネルの識別子と前記ネットワー
クレイヤマルチキャストデータフローの識別子との対応
関係を記述するレジスタ（例えば、前記対応関係をＩＥ
ＥＥ１３９４のＰＣＲと呼ばれるレジスタ）を具備した
ことにより、このレジスタに記述された前記１３９４バ
ス上の同期チャネル番号と、その同期チャネルを通るフ
ローに関する情報との対応関係を他のノードに通知する
こと、あるいは他のノードから獲得することができるよ
うになる。すなわち、前記レジスタを持っているノード
が、送信ノードである場合、前記１３９４バス上の他の
ノードがこのレジスタを参照することによって、このレ
ジスタに記述された前記１３９４バス上の同期チャネル
上に、どのようなフローが通っているのか（即ち、前記
送信ノードがどのようなフローを送信しているのか）を
知ることが可能となる。また、前記レジスタを持ってい
るノードが、受信ノードである場合、前記１３９４バス
上の他のノードが、前記受信ノードの該レジスタに対応
関係を記入することにより、前記受信ノードは、このレ
ジスタに記述された前記１３９４バス上の同期チャネル
上に、どのようなフローが通ってくるのか（即ち、前記
受信ノードがどのようなフローを受信するのか）を知る
ことが可能となる。

【００１５】また、前記レジスタには、送信か、受信か
区別するフィールドを更に持ってもよい。これにより、
前述の送信ノード、受信ノードのどちらの用途に本レジ
スタを使用するのかを明確にすることができる。

【００１６】また、前記レジスタは、前記ＩＥＥＥ１３
９４バスに接続された他のノードから、その内容を記述
され、該レジスタに記述された同期チャネルの番号を基
に、ネットワークレイヤマルチキャストデータフローの
識別子を参照した、複数ネットワーク間のデータ転送を
行ってもよい。

【００１７】該レジスタを参照することにより、前記ノ
ードは、前記同期チャネルを通ってくるフローの属性を
知ることが可能となり、これは、前記ノードが、フロー
の中身を調査しなくとも、同期チャネルの番号から、フ
ローの属性が分かるということを意味する。よって、こ
の同期チャネル番号の値を基に、転送先のネットワー
ク、あるいは転送先のネットワークの( 仮想) チャネル
の識別子を直接マッピングすることにより、接続された
他のネットワークに対してデータ転送を、データリンク
レイヤ情報の参照、処理のみで直接行うことが可能とな
る。

【００１８】また、前記データフローはインターネット
のデータフローであってもよい。この場合、前記同期チ
ャネルを通るフローに関する情報として、ＩＰフローに
ついての情報、即ち送信／受信ＩＰアドレス、送信／受
信ポート番号、アプリケーションプロトコル種別など
を、このレジスタを使って、他のノードに通知すること
ができる。

【００１９】（請求項２、４、６） 本発明の通信装置
は、放送型のネットワークに接続された通信装置であっ
て、ネットワークレイヤマルチキャストデータフローを
送受信する際に必要な帯域の保証された放送型チャネル
を確立する確立手段と、少なくとも前記確立された放送
型チャネルの識別子と前記ネットワークレイヤマルチキ
ャストデータフローの識別子との対応関係を含むメッセ
ージを送信する送信手段と、を具備したことにより、例
えば、ＲＳＶＰのＲＥＳＶメッセージを送信する下流側
のノードが、上流側に同期チャネルを予約することによ
り、上流側のノードから送られてくる例えばＲＳＶＰの
ＰＡＴＨメッセージで示される、必要とされている通信
資源を、ＩＥＥＥ１３９４バスの同期チャネルという形
で確保することが可能となり、もって、ネットワークレ
イヤレベルのシグナリングプロトコルで実現されるべ
き、エンド・エンドの通信資源の確保された通信が実現
可能となる。

【００２０】また、前記送信手段を具備することによ
り、先に送信されてきたＰＡＴＨメッセージに対応し
た、ＩＥＥＥ１３９４バス上で確保された通信資源（即
ち同期チャネル）についての情報を、上流ノード（送信
端末、あるいは中継ルータ）は入手することが可能とな
り、もって、上流ノードは、例えばＲＳＶＰを使って予
約した受信データを、前記通信資源を用いて、通信資源
が伴う形で送信することが可能となる。

【００２１】また、本発明の通信装置において、前記対
応関係を通知するメッセージは、インターネット上でデ
ータを送受信する際の通信資源の確保要求プロトコルの
メッセージ（例えば、ＲＳＶＰのＰＡＴＨメッセージ）
であることにより、前記対応関係の通知のための別メッ
セージを用意する必要がなくなるとともに、ＲＥＳＶメ
ッセージと、前記別メッセージの対応付けを行うための
テーブルなどを上流ノード（例えば送信端末や中継ルー
タ）が用意する必要も無くなる。

【００２２】（請求項１３（請求項１に対応）） 本発
明の通信方法は、放送型のネットワークに接続された通
信装置から送信されたネットワークレイヤマルチキャス
トデータフローを識別する識別子と前記ネットワークレ
イヤマルチキャストデータフローに対応する帯域の確保
要求を含む第１のメッセージを受信したとき、この第１
のメッセージに基づき前記ネットワーク上に放送型チャ
ネルを確立し、少なくとも前記確立された放送型チャネ
ルの識別子と前記ネットワークレイヤマルチキャストデ
ータフローの識別子との対応関係を含む第２のメッセー
ジを前記通信装置に送信することを特徴とする。

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

【００２４】また、前記確立された放送型チャネルの識
別子と前記ネットワークレイヤマルチキャストアドレス
との対応関係を前記第２の通信装置に通知することによ
り、第２の通信装置（受信端末）がどのチャネルより、
該マルチキャストデータを受信できるようになるのかを
通知することが出来るようになり、しかも放送型のチャ
ネルを用いるために、複数の受信端末の収容を１つのチ
ャネルを通じて行うことが可能になる。

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

【００２６】本発明の通信装置（請求項９〜１２）は、
放送型のネットワークに接続され、ネットワークレイヤ
マルチキャストアドレス宛てのデータを送信する通信装
置であって、前記ネットワーク上に確立されている放送
型チャネルに対する通信帯域を確保する確保手段と、こ
の確保手段で前記放送型チャネルに帯域が確保されたと
き、前記ネットワークレイヤマルチキャストアドレス宛
てのデータを、前記放送型チャネルの帯域が確保された
周期あるいはコネクションで送信し、前記放送型チャネ
ルに帯域が確保されていないとき、前記ネットワークレ
イヤマルチキャストアドレス宛てのデータを前記放送型
チャネルの帯域が確保されていない周期あるいはコネク
ションで送信する送信手段と、を具備し、ネットワーク
レイヤマルチキャストパケットを帯域有りの形で伝送す
る場合に、そのマルチキャストパケットの送信者が帯域
を確保するという規則に従うことにより、複数のノード
が同時に同じチャネルに対して帯域を確保してしまうよ
うな、いわゆる帯域の２重確保を回避することが可能で
ある。また、通常必要な帯域は送信ノードがその値を把
握している場合が多いと考えられるため、この観点から
も妥当である。

【００２７】また、本発明の通信装置（請求項１２）
は、前記確保手段で帯域が確保されたときの前記放送型
チャネルの識別子は、帯域が確保されていないときの前
記放送型チャネルと同一の識別子であることにより、チ
ャネル番号の浪費を防ぐことが可能となり、特にＩＥＥ
Ｅ１３９４バスのようなチャネル番号の数が比較的少な
めの上限（ＩＥＥＥ１３９４の場合、６４個）があるよ
うなデータリンクに関しては、帯域有りの形で流すＩＰ
マルチキャストパケットと、帯域なしのベストエフォー
トで流すＩＰマルチキャストパケットとを、同一のチャ
ネルで共有することができるようになり、これも通信資
源の有効活用につながる。

【００２８】本発明の通信方法（請求項１４（請求項７
に対応））は、放送型のネットワークに接続された通信
装置からのネットワークレイヤマルチキャストアドレス
への加入申請に応じて前記ネットワーク上に放送型チャ
ネルを確立し、少なくとも前記確立された放送型チャネ
ルの識別子と前記ネットワークレイヤマルチキャストア
ドレスとの対応関係を前記通信装置に通知した後、前記
ネットワークレイヤマルチキャストアドレス宛てのデー
タを前記確立された放送型のチャネルに送出することを
特徴とする。

【００２９】本発明の通信方法（請求項１５（請求項１
１に対応））は、放送型のネットワークに接続され、ネ
ットワークレイヤマルチキャストアドレス宛てのデータ
を送信する通信方法において、前記ネットワーク上に確
立されている放送型チャネルに対して通信帯域が確保さ
れたとき、前記ネットワークレイヤマルチキャストアド
レス宛てのデータを、前記放送型チャネルの帯域が確保
された周期あるいはコネクションで送信し、前記放送型
チャネルに帯域が確保されていないとき、前記ネットワ
ークレイヤマルチキャストアドレス宛てのデータを前記
放送型チャネルの帯域が確保されていない周期あるいは
コネクションで送信することを特徴とする。

【００３０】

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

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

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

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

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

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

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

【００３７】公衆網１０４と家庭内に構築されたネット
ワークの間は、専用の接続装置１０２にて接続されてい
る。

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

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

【００４０】また、接続装置１０２の公衆網側には、グ
ローバルなＩＰアドレス（Ｇ．２）が割り当てられてい
る。

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

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

【００４３】本実施形態においては、第１および第２の
ネットワーク１０５、１０６は同一のサブネットに属す
るものとして、以降の説明を行う。

【００４４】次に、図１の端末１０３が接続装置１０
２、公衆網１０４を通してビデオサーバからビデオを転
送してもらうまでの処理手順について、図２を参照して
説明する。また、その際の端末１０３の処理手順および
接続装置１０２の処理手順を、それぞれ図３、図４に示
す。

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

【００４６】ＳＢＭとは、ＩＥＴＦのＩｎｔＳｅｒｖワ
ーキンググループで議論されているもので、サブネット
内の通信資源確保をＲＳＶＰを用いて行うものである。

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

【００４８】本実施形態では、これらの情報の交換は、
ＩＰパケットを使って行われるものとする。

【００４９】ちなみに、この上位レイヤプロトコルは、
接続装置１０２にてＮＡＴの処理を受けながら通信され
ていても良い（ステップＳ２０２）。

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

【００５１】ＮＡＴ処理の詳細については、例えば本発
明者らによる特願平第８−３１６５５２号を参照された
い。

【００５２】本実施形態においては、ビデオサーバから
の映像サービスは、ＩＰマルチキャストを通じて提供さ
れるものとする。そこで、前記上位レイヤプロトコルを
用いて選択するビデオが決定した場合、そのビデオを転
送するためのＩＰマルチキャストアドレスを取得する必
要がある。

【００５３】その放送形態( 配信形態) にはいくつかの
形態が考えられる。

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

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

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

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

【００５８】接続装置１０２に記憶される対応テーブル
の一例を図５に示す。

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

【００６０】次に、端末１０３は、このビデオ映像を良
い品質で受信するための通信資源の予約を行う。このた
めの方法として、いくつかの方法が考えられる。

【００６１】（ａ） ＳＢＭを用いる方法 ＳＢＭ（Ｓｕｂｎｅｔ Ｂａｎｄｗｉｄｔｈ Ｍａｎａ
ｇｅｒ）とは、インターネットの標準化機関であるＩＥ
ＴＦで提案されているサブネット内の帯域予約のための
方式であり、サブネット内の帯域予約をＲＳＶＰを使っ
て行うものである。

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

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

【００６４】接続装置１０２は、ＳＢＭノードであるこ
とから、ルーチングプロトコルは稼動していない。

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

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

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

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

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

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

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

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

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

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

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

【００７６】無論、上記第１〜第４の通知方法の適宜組
み合わせて用いることもできる。

【００７７】なお、タイミング的には、ここで説明した
タイミング以外にも、ビデオサーバ１０１まで通信資源
の予約が完了し、エンド- エンドの通信が可能になった
段階で上記の手続きを行う形も考えられる。

【００７８】さて、下流側の通信資源の確保に成功した
接続装置１０２は、ＲＳＶＰのＲＥＳＶメッセージを更
に上流へと流す（ステップＳ２１３）。

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

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

【００８１】こうして、エンドエンドの通信資源が確保
されたなら、ビデオ転送を開始する（ステップＳ２１
６、Ｓ２１７）。

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

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

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

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

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

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

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

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

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

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

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

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

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

【００９５】また、接続装置１０２から送信されるＩＰ
パケットのポート番号の違いを見て、別々のマルチキャ
ストアドレスを割当てる判断のトリガとしてもよい。

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

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

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

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

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

【０１０１】受信端末２１０２、２１０３は、予め何ら
かの手段にてＩＰマルチキャストアドレス「ＩＰｍ」を
取得しているものとする。

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

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

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

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

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

【０１０７】帯域を確保することが必要な場合について
は後述する。

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

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

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

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

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

【０１１３】方向としては、基本的にこのＩＧＭＰルー
タがこれらのＩＰマルチキャストパケットを送信するも
のとして「順方向」とする。

【０１１４】コネクションカウンタは、この非同期スト
リームを受信していると考えられるノードの数を表すカ
ウンタである。受信者はこの時点で受信端末２１０２の
みであると考えられるので、カウンタ値「１」が入力さ
れる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１４４】その後、このチャネル「＃ｘ」を通じて、
ＩＰマルチキャストアドレス「ＩＰｍ」宛のデータグラ
ムが送信されることになる（ステップＳ２６０５）。

【０１４５】同様に、他の受信端末２１０２からの加入
要求があった場合（ステップＳ２６０６）も、プラグコ
ントロールレジスタへの書き込みと（ステップＳ２６０
７）、ＦＡＮＰメッセージの送付（ステップＳ２６０
８）を行なうことで、対応関係の通知を行なうことがで
きる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１６１】この場合の手順について、図２２のシーケ
ンス図を参照して説明する。

【０１６２】図２２のステップＳ３１０１〜ステップＳ
３１０７において、ＲＳＶＰのＲＥＳＶメッセージに
て、帯域確保の要求（ＲＥＳＶ）が受信端末２１０１か
らあるまでは、図１９のステップＳ２８０１〜ステップ
Ｓ２８０７と同様である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１８２】

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

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

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【符号の説明】

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

Claims (15)

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