JP4003989B2 - 通信装置および通信方法 - Google Patents
通信装置および通信方法 Download PDFInfo
- Publication number
- JP4003989B2 JP4003989B2 JP05332198A JP5332198A JP4003989B2 JP 4003989 B2 JP4003989 B2 JP 4003989B2 JP 05332198 A JP05332198 A JP 05332198A JP 5332198 A JP5332198 A JP 5332198A JP 4003989 B2 JP4003989 B2 JP 4003989B2
- Authority
- JP
- Japan
- Prior art keywords
- multicast
- network
- terminal
- bandwidth
- multicast address
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、ＩＥＥＥ１３９４バス等の放送型のネットワークを介してデータ通信を行う通信装置に関する。
【０００２】
【従来の技術】
最近インターネットをはじめとする通信技術の急激な進歩が各方面で話題になっており、企業や大学などを中心にＬＡＮの導入、あるいはこれのＷＡＮやインターネットへの接続といったことが話題になっている。
【０００３】
これらの技術革新は、家庭を取り巻くネットワーク環境をも変える可能性が高い。即ち、家庭にＰＣやＤＶＤ、デジタルセットトップボックス等のデジタル機器が普及してくるに連れて、これらを相互にデジタルネットワークにて接続しようという気運が高まるのは必然である。現在、ＡＶベンダを中心に、ＩＥＥＥ１３９４バスが、その候補の筆頭として、各方面から注目を集めている。
【０００４】
ＩＥＥＥ１３９４バスは、１００Ｍ、２００Ｍ、４００Ｍｂｐｓの高速デジタル網として利用することができ、プラグアンドプレイ、同期チャネルを用いた同期転送機能等、いくつもの注目すべき機能がある。
【０００５】
それとともに、いわゆる家庭へのアクセス網の技術革新も急である。即ち、ＣＡＴＶやＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒａｉｂｅｒ Ｌｉｎｅ）、ＦＴＴＨ（ｆｉｂｅｒ−ｔｏ−ｔｈｅ−ｈｏｍｅ）等の高速ネットワーク技術、インターネット等のネットワークサービス等、その進歩は著しい。特に、インターネット技術は、その高速化、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）等ネットワークレイヤレベルのシグナリングプロトコルを用いたＱＯＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）保証、マルチキャスト等、注目すべき技術が次々と生まれている。
【０００６】
インターネット上で、これらの技術が実現する近未来においては、家庭へのビデオ転送等、高速、リアルタイムを要求される情報の転送の一部がインターネットを通じて行われる可能性がある。これは、インターネットに蓄積される情報量が実質的に無限であり、ユーザが、従来は地上波、衛星放送などからでていた前記情報をインターネットを通じて入手するようになると考えるのは、ごく自然なことである。
【０００７】
【発明が解決しようとする課題】
しかしながら、家庭内のデジタル機器を、アクセス網を介して接続し、インターネットを通じた情報のやり取りをしようとした場合、以下のような問題点が考えられる。
【０００８】
現在、ＩＥＥＥ１３９４上をインターネットのデータを流通させるための検討、即ち「ＩＰ ｏｖｅｒ １３９４」の検討が、各方面で進められている。しかし、現在その検討はいわゆるアドレス解決方式にとどまっている。一方、インターネット上を通信品質を保証する形でデータのやり取りを行うためのシグナリングプロトコルとして、例えばＲＳＶＰが提案されている。しかし、これらのネットワークレイヤのシグナリングプロトコルをＩＥＥＥ１３９４上で運用する方式がいまだ決まっておらず、ＩＥＥＥ１３９４上では通信品質が確保されない転送方式にマッピングせざるをえない。従って、上記シグナリングが実行されたとしても、ＩＥＥＥ１３９４上をベストエフォート（具体的には非同期チャネル）を通じてデータが転送されてしまうため、エンドエンドの通信品質が保たれない。
【０００９】
また、ＩＥＥＥ１３９４バス上でＩＰマルチキャストを送受信しようとした場合、ＩＥＥＥ１３９４バス上のトラヒックを最小限にするために、ＩＥＥＥ１３９４バスの同期チャネルあるいは非同期ストリームを用いることが考えられる。しかしながら、同時に２つ以上の装置が同じＩＰマルチキャストに加入しようという場合は、これら２つ以上の装置が独立に別個のチャネルを確保してしまう可能性があり、通信資源の有効利用が図れない。また、確保したチャネルと、ＩＰマルチキャストアドレスとの対応関係を送信側、受信側で同期して認識するための機構が無い。
【００１０】
そこで、本発明は、上記問題点に鑑みてなされたものであり、ＲＳＶＰのＩＥＥＥ１３９４バス上での適用方法を示し、ＩＥＥＥ１３９４上でも、相互接続環境での通信品質を確保した通信が可能となる通信装置を提供することを目的とする。
【００１１】
また、本発明は、ＩＥＥＥ１３９４等の放送型ネットワークにおいて、通信資源を有効に利用してＩＰマルチキャストを行うことができ、また、確保したチャネルとＩＰマルチキャストアドレスとの対応関係を送信側、受信側で同期して認識することのできる通信装置を提供することを目的とする。
【００１２】
【課題を解決するための手段】
上記問題を解決するために、本発明の通信装置は、放送型のネットワークに接続され、ネットワークレイヤマルチキャストアドレス宛てのデータを送信する通信装置であって、前記ネットワーク上に確立されている放送型チャネルに対する通信帯域を確保する確保手段と、前記放送型チャネルに帯域が確保されていない場合に、前記ネットワークレイヤマルチキャストアドレス宛てのデータを前記放送型チャネルの帯域が確保されていない周期あるいはコネクションで送信する第１の送信手段と、前記確保手段により前記放送型チャネルに帯域が確保された場合に、前記ネットワークレイヤマルチキャストアドレス宛てのデータを前記放送型チャネルの帯域が確保されていない周期あるいはコネクションから、前記放送型チャネルの帯域が確保された周期あるいはコネクションに切り替えて送信する第２の送信手段とを具備したことにより、ネットワークレイヤマルチキャストパケットを帯域を確保されていない形での伝送から、確保された形での伝送に切り替える場合に、これまでのように、再度放送型チャネルと帯域の確保の両方を資源確保を行っているマネージャ（例えばＩＥＥＥ１３９４における同期リソースマネージャ）に要求する必要がなくなる。即ち、単に既に通信資源として持っている放送型チャネル向けのパケットを第１の送信手段に送り込むのみでこれが可能となる。逆の切り替え（帯域確保から非確保への切り替え）も同様である。
【００２２】
さらに本発明の通信装置では、前記確保手段で帯域が確保された場合の前記第1 の送信手段から出力される放送型チャネルの識別子は、帯域が確保されていない場合の前記第2 の送信手段から出力される放送型チャネルの識別子と同一の識別子であることにより、放送型チャネルの浪費を防ぐことが可能となる。特に、IEEE13 94 の様なチャネル資源が比較的少ない様なデータリンクに関しては、帯域確保の形で流すネットワークレイヤマルチキャストパケットと、帯域確保無しで流すマルチキャストパケットとを同一のチャネルで共有することができるようになり、これも通信資源の有効活用につながる。
【００２３】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態について説明する。なお、以下の説明では、一例として家庭内に構築されたネットワーク（家庭内ネットワーク）を対象として説明するが、これに限るものではなく、例えば、ホテル等の建物、敷地内といった限られた範囲に構築されるネットワークにおいても適用できる。
【００２４】
（第１の実施形態）
図１は、本発明の第１の実施形態に係るネットワーク全体の構成例を示したもので、映像サービスを提供しているビデオサーバからのデータを、公衆網を介して家庭内ネットワークにとりこみ、家庭内ネットワークに接続された端末で、該サービスを受ける状況を説明する図となっている。
【００２５】
図１に示すように、全体の構成は、ビデオサーバ１０１、公衆網１０４、接続装置１０２、例えば家庭内に構築された第１のネットワーク１０５、第２のネットワーク１０６、第１のネットワークに接続された端末１０３からなる。
【００２６】
なお、図１では第１のネットワーク１０５に端末１０３が１つ接続されているのみであるが、実際には両ネットワーク１０５、１０６に、他の種々の端末、あるいは網間接続装置等が接続されていても良い。
【００２７】
公衆網は、例えばＣＡＴＶ網、あるいはＩＳＤＮ／Ｂ−ＩＳＤＮ網、ＡＴＭ−ＰＯＮ網、高速無線アクセス網、ＡＤＳＬ／ＨＤＳＬ網等、色々な場合が考えられる。ただし、本実施形態のビデオサービスはＭＰＥＧ映像をインターネットを介して提供されるものとする（ＭＰＥＧｏｖｅｒＩＰ）。よって、本サービスが提供されるインタフェースはデジタルインタフェースを仮定する。
【００２８】
本実施形態においては、該デジタルネットワークはデータリンク方式として、ＡＴＭ方式を採用しているものとして、以後の説明を進めていくが、本発明の方式はＡＴＭ方式に限定されるものではない。例えば、以後の説明のＡＴＭのＶＰＩ／ＶＣＩ等のデータリンクレイヤ識別子は、ＩＳＤＮであればＢチャネル識別子、ＣＡＴＶであれば周波数に対応するものである。このように、本実施形態のＡＴＭにおけるＶＰＩ／ＶＣＩをこれら他のデータリンクレイヤ識別子に置き換えたものも、本発明に含まれるものである。
【００２９】
ビデオサーバ１０１は、専用のビデオサーバでも良いし、例えば映像対応ＷＷＷサーバ等、映像信号を送出できるサーバであれば良い。ここで、「映像信号を送出できる」とは、リアルタイム伝送を行う事は必ずしも意味しない。例えば、映像データを、リアルタイム配信ではなく、ベストエフォートにて配信する場合がこれにあたる。
【００３０】
公衆網１０４と家庭内に構築されたネットワークの間は、専用の接続装置１０２にて接続されている。
接続装置１０２には、この場合、公衆網１０４の終端機能、家庭内のネットワーク１０５、１０６の終端機能、ＩＰ処理機能、ＲＦＣ１６３１にて標準化されているＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）機能の他に、ＩＰマルチキャスト対応機能、ＩＰシグナリング機能、公衆網と家庭内のネットワーク間でリアルタイムデータ転送可能なデータリンクレイヤレベルのスイッチ、アドレス通知機能等が実装されている。詳細は後述する。
【００３１】
次に、図１に示したネットワーク上のＩＰのサブネット構成とアドレス割当について説明する。図１に示すように、第１の実施形態において、家庭内のネットワーク全体（第１および第２のネットワーク１０５、１０６）にて１つのＩＰサブネット( ネットワークアドレスＰ）が構成されており、更に家庭内ネットワークは、ＲＦＣ１５９７にて標準化されているプライベートアドレスを利用している。
【００３２】
また、接続装置１０２の公衆網側には、グローバルなＩＰアドレス（Ｇ．２）が割り当てられている。
このようなアドレス構成となっている理由は、例えば複数のグローバルなＩＰアドレスの取得には、１つのグローバルＩＰアドレス取得と比べてコストがかかる、あるいは世界的なＩＰアドレスの枯渇のためである。即ち、端末数、アドレス数の急成長が見込まれる家庭内ネットワークへの接続端末にはグローバルなＩＰアドレスの新規の割当は実質的にはほとんど不可能、等の理由によるものである。
【００３３】
なお、第１のネットワーク１０５、第２のネットワーク１０６は、それぞれ別のプライベートアドレス内という限定の上で、別々のサブネットとなっていてもよい。この場合は、両者の間にはいる接続装置１０２はルータとなる。
【００３４】
本実施形態においては、第１および第２のネットワーク１０５、１０６は同一のサブネットに属するものとして、以降の説明を行う。
次に、図１の端末１０３が接続装置１０２、公衆網１０４を通してビデオサーバからビデオを転送してもらうまでの処理手順について、図２を参照して説明する。また、その際の端末１０３の処理手順および接続装置１０２の処理手順を、それぞれ図３、図４に示す。
【００３５】
図２、図３、図４は、後に示すように、接続装置１０２がＳＢＭ（Ｓｕｂｎｅｔ Ｂａｎｄｗｉｄｔｈ Ｍａｎａｇｅｒ）であるような場合に、この機構を用いて通信資源の確保を使った場合のシーケンスを記述したものである。
【００３６】
ＳＢＭとは、ＩＥＴＦのＩｎｔＳｅｒｖワーキンググループで議論されているもので、サブネット内の通信資源確保をＲＳＶＰを用いて行うものである。
まず、端末１０３は、ＯＳＩの標準化された７レイヤのうちのレイヤ５以上のプロトコルを用いて、見たいビデオについての情報の入手を行う（ステップＳ２０１、Ｓ２０３）。これは、ＭＰＥＧ／ＤＡＶＩＣのＤＳＭ−ＣＣや、それに準じたプロトコルを用いたネゴシエーションや、ＲＴＳＰ等を用いてＷＷＷサーバからの情報の選択をＷｅｂ上で行う事による情報の選択など、色々な場合が考えられる。以降では、これを「上位レイヤプロトコル」として、まとめて表現する。
【００３７】
本実施形態では、これらの情報の交換は、ＩＰパケットを使って行われるものとする。
ちなみに、この上位レイヤプロトコルは、接続装置１０２にてＮＡＴの処理を受けながら通信されていても良い（ステップＳ２０２）。
【００３８】
ＮＡＴ処理とは、プライベートＩＰ網からインターネットにＩＰパケットをフォワーディングするに際し、プライベートＩＰアドレスをインターネット側に送出するのは許されないため、接続装置１０２にて、プライベートＩＰアドレスを自身のグローバルＩＰアドレス( ここでは「Ｇ．２」）に変換して送出する方式を言う。
【００３９】
ＮＡＴ処理の詳細については、例えば本発明者らによる特願平第８−３１６５５２号を参照されたい。
本実施形態においては、ビデオサーバからの映像サービスは、ＩＰマルチキャストを通じて提供されるものとする。そこで、前記上位レイヤプロトコルを用いて選択するビデオが決定した場合、そのビデオを転送するためのＩＰマルチキャストアドレスを取得する必要がある。
【００４０】
その放送形態( 配信形態) にはいくつかの形態が考えられる。
（Ａ） まず、ビデオ毎( コンテンツ毎) に、別々のＩＰマルチキャストアドレスが割り当てられている場合から説明する。
【００４１】
これは、例えばＡ放送局からの放送はＩＰマルチキャストアドレス＝「＃１」、Ｂ放送局からの放送は「＃６」等と、ＩＰマルチキャストアドレスが割当てられている場合である。
【００４２】
上位レイヤプロトコルを通して、ビデオサーバ１０１は、端末１０３にそのビデオを転送するためのマルチキャストアドレス「Ｍ」を通知する。すると、端末１０３は、ＩＰマルチキャストのプロトコル（例えばＩＧＭＰ（ＲＦＣ１１１２））に従い、インターネット側から受け取るＱＵＥＲＹメッセージに対し、加入したいマルチキャストアドレス「Ｍ」についてのＲＥＰＯＲＴメッセージを送出する（ステップＳ２０４）。
【００４３】
これを受信した接続装置１０２は、端末１０３のプライベートアドレス「Ｐ．２」と、要求されたマルチキャストアドレス「Ｍ」との対応関係を記憶した後（ステップＳ２０５）、ＲＥＰＯＲＴメッセージを上流のルータに通知する（ステップＳ２０６）。その際、送信者アドレスを自身（接続装置１０２）のグローバルＩＰアドレス「Ｇ．２」としておく。
【００４４】
接続装置１０２に記憶される対応テーブルの一例を図５に示す。
マルチキャストアドレス「Ｍ」への加入が成功すると、接続装置１０２は、端末１０３がマルチキャストアドレス「Ｍ」に加入した旨を記憶し（ステップＳ２０５）、これを端末１０３に通知する。
【００４５】
次に、端末１０３は、このビデオ映像を良い品質で受信するための通信資源の予約を行う。このための方法として、いくつかの方法が考えられる。
（ａ） ＳＢＭを用いる方法
ＳＢＭ（Ｓｕｂｎｅｔ Ｂａｎｄｗｉｄｔｈ Ｍａｎａｇｅｒ）とは、インターネットの標準化機関であるＩＥＴＦで提案されているサブネット内の帯域予約のための方式であり、サブネット内の帯域予約をＲＳＶＰを使って行うものである。
【００４６】
（ｂ） ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いる方法
（ｃ） ＩＥＣ１８８３を用いる方法
以下、順に説明する。
【００４７】
（ａ）ＳＢＭを用いる方法
まず、ＳＢＭを用いる場合について、図２に示すシーケンスを参照して説明する。
【００４８】
接続装置１０２は、ＳＢＭノードであることから、ルーチングプロトコルは稼動していない。
本実施形態の接続装置は、ＮＡＴ機能を持っているため、グローバルＩＰアドレス（Ｇ．２）を有しているが、家庭内ネットワーク側に複数の物理インタフェースがあるとしても、物理インタフェース毎にＩＰアドレス( プライベートアドレス) を持つ必要はない。例えば、接続装置１０２は、グローバルＩＰアドレスの他、プライベートアドレスを１つ持てば充分である。ここでは、接続装置１０２はプライベートＩＰアドレス「Ｐ．１」を持っている。
【００４９】
端末１０３は、上位レイヤプロトコル等でＲＳＶＰのＰＡＴＨメッセージの送出をビデオサーバ１０１に促しても良い。ＰＡＴＨメッセージはマルチキャストアドレス「Ｍ」宛てに送出され、接続装置１０２に届く（ステップＳ２０７）。
【００５０】
接続装置１０２では、ＲＳＶＰのＰＡＴＨステートを作成し（ステップＳ２０８）、その後、ＰＡＴＨメッセージをマルチキャストアドレス「Ｍ」宛に送出し、結局、端末１０３に到着する（ステップＳ２０９）。その際、接続装置１０２は端末１０３がマルチキャストアドレス「Ｍ」に属している事を、図５の対応テーブルにより認識しているので、該ＰＡＴＨメッセージを端末１０３にフォワードする事が出来る。
【００５１】
接続装置１０２内には、ＰＡＴＨステートが出来る。ここで、接続装置１０２はＳＢＭノードである。端末１０３は、帯域等の通信資源を予約すべく、ＲＳＶＰのＲＥＳＶメッセージを上流の接続装置１０２に送出する（ステップＳ２１０）。
【００５２】
ＲＥＳＶメッセージを受信した接続装置１０２は、接続装置１０２と端末１０３間の通信資源を確保すべく、第１のネットワーク（ＩＥＥＥ１３９４）１０５のＩＥＥＥ１３９４同期リソースマネージャにアクセスして、必要な帯域と同期チャネル番号を確保する（ステップＳ２１１）。ここで、確保された同期チャネルの番号を「＃ｘ」とする。
【００５３】
この時点で、接続装置１０２は、端末１０３に「どの同期チャネルを用いて、リクエストされた番組を送出するのか」を端末１０３に通知しても良い（ステップＳ２１２）。
【００５４】
この通知方法としては、例えば、図６に示したようなフォーマットのＲＳＶＰのＰＡＴＨメッセージを用いる方法がある。すなわち、図６に示すように、ＲＳＶＰのＰＡＴＨメッセージ内に、「今後（あるいは今）、このＰＡＴＨメッセージに含まれるデータ（ＩＰフロー）は、同期チャネル番号＝「＃ｘ」にて伝送する」といった旨の情報が記述される。
【００５５】
第２の通知方法は、発明者らが特願平第８−２６４４９６号に記載したＦＡＮＰ（Ｆｌｏｗ Ａｔｔｒｉｂｕｔｅ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いる方法である。
【００５６】
ＦＡＮＰは、隣接ノード間（本実施形態の場合、接続装置１０２と端末１０３間）にて、送信するＩＰフロー等（本実施形態の場合、例えばＩＰマルチキャストアドレス「Ｍ」）と、リンクレイヤのＩＤ情報（本実施形態の場合、先に確保したＩＥＥＥ１３９４のチャネル番号）との対応関係を通知しあうものである。
【００５７】
第３の通知方法は、ＩＥＣ１８８３のＣＩＰヘッダを用いる方法である。ＩＥＣ１８８３を用いて、接続装置１０２が直接端末１０３のＰＣＲ（Ｐｌｕｇ Ｃｏｎｔｒｏｌ Ｒｅｇｉｓｔｅｒ）に使用するチャネル番号を書き込み、１３９４のヘッダなり、ＩＥＣ１８８３にて定められたＣＩＰ（Ｃｏｍｍｏｎ Ｉｓｏｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔ）ヘッダなりで端末１０３に、送信している情報がＭＰＥＧｏｖｅｒＩＰであることを認識させる。例えば、ＣＩＰヘッダを拡張する場合は、そのパケットがＩＰパケットである旨、あるいはＭＰＥＧｏｖｅｒＩＰである旨を示す値をＦＭＰ（フォーマットＩＤ）領域に書き込むことにより、端末１０３はＣＩＰヘッダを見ることにより、そのパケットの属性がＩＰパケット、あるいはＭＰＥＧが載ったＩＰパケットであることが認識できるようになる。
【００５８】
第４の通知方法は、図７に示すように、ＰＣＲを拡張して、ＰＣＲレジスタの意味の一部を、そのチャネル番号に伝送する内容を意味するものとする。例えば、ＩＰパケットあるいはＭＰＥＧｏｖｅｒＩＰのパケットである。また、そのチャネル番号を伝送されるフローの属性を記述しても良い。例えば、送信ＩＰアドレス／受信ＩＰアドレス／送信ポート番号／受信ポート番号の組み合わせなどである。このようなレジスタを端末１０３に用意し、接続装置１０２( あるいはコントローラ) がこのレジスタに適切に記述することにより、端末１０３が、そのチャネル番号を通して受信するデータがＩＰパケット、あるいはＭＰＥＧｏｖｅｒＩＰのパケットであること、あるいは、その属性を認識できるようになる。
【００５９】
無論、上記第１〜第４の通知方法の適宜組み合わせて用いることもできる。
なお、タイミング的には、ここで説明したタイミング以外にも、ビデオサーバ１０１まで通信資源の予約が完了し、エンド- エンドの通信が可能になった段階で上記の手続きを行う形も考えられる。
【００６０】
さて、下流側の通信資源の確保に成功した接続装置１０２は、ＲＳＶＰのＲＥＳＶメッセージを更に上流へと流す（ステップＳ２１３）。
これを受けとったインターネット内のルータは例えば、Ｑ．２９３１等を使って下流側のＡＴＭ網の通信資源を確保し（ステップＳ２１４）、それを確認した後、更に上流へとＲＥＳＶメッセージの送出、といったことを繰り返す。
【００６１】
更に、ＰＡＴＨあるいはＦＡＮＰを用いて下流方向のＲＳＶＰ／ＳＢＭノードに対して、使用するデータリンク識別子（この場合、データリンク技術がＡＴＭであるため、ＶＰＩ／ＶＣＩ）についての情報を送出し、該ＲＳＶＰ／ＳＢＭノードに、送出ＩＰフローとデータリンク識別子との対応関係の通知を行う（ステップＳ２１５）。ここで、接続装置１０２に対して確保されたＡＴＭのＶＣＩの値「＃ｙ」とする。
【００６２】
こうして、エンドエンドの通信資源が確保されたなら、ビデオ転送を開始する（ステップＳ２１６、Ｓ２１７）。
ここで、接続装置１０２では、ビデオサーバ１０１からＡＴＭコネクション「＃ｙ（ＶＣＩ値＝「＃ｙ」）」にてＭＰＥＧｏｖｅｒＩＰのデータが伝送されてくることを認識しており、また端末１０３に対してＩＥＥＥ１３９４の同期チャネル「＃ｘ」にて受信したＩＰパケットを送出すればよいことを認識している。
【００６３】
そこで、接続装置１０２では、ＶＣＩ「＃ｙ」を通して受信したデータを、ＩＰパケットのヘッダの中身まで検証することなく、直接ＩＥＥＥ１３９４の同期チャネル「＃ｘ」に対して、ＩＰパケットの同期をとった上で伝送する。即ち、ＶＣＩ値のみの検証により、ＩＰレイヤの処理をすることなく、直接１３９４へのデータ転送を行うことができる。これは、データリンクレイヤの情報のみで、データのスイッチングを行っていることから、データリンクスイッチと見ることができる。
【００６４】
このことにより、本来ＩＰレイヤで行うべき、ＩＰレイヤ処理、即ちＩＰヘッダの検証やルーチング処理等の一連のソフトウエア処理を、データリンクレイヤスイッチング処理にて置き換えることが可能になり、処理時間、及び処理負荷の大幅な低減を図ることが可能になる。これは、ＳＢＭを行った上で、データリンクスイッチを行っていることに相当する。
【００６５】
なお、以上の説明では、接続装置１０２はＳＢＭノードとして説明を行ってきたが、接続装置１０２がルータであり、ＲＳＶＰを利用した通信資源の確保を行ってももちろんよい。
【００６６】
また、通信資源の予約を行う際に、本発明の発明者らによる特願平第８−２６４４９６号に記載されている方法、すなわち、ＦＡＮＰにより通信資源の予約を行うようにしてもよい。
【００６７】
以上は、ＩＥＥＥ１３９４上の通信資源予約をＲＳＶＰの上流のノードが行う場合についての説明であった。これに対し、図８に示すように、ＩＥＥＥ１３９４バス上の同期チャネルの確保を、下流側のノード（本実施形態の場合、端末１０３）が行ってもよい。
【００６８】
下流側のノードが必要な通信資源を持った同期チャネルの確保を行った後（ステップＳ２１１０）、上流側にＲＥＳＶメッセージの送出を行う（ステップＳ２１１１）。この場合、確保した同期チャネルの番号等は、続けて送出するＲＳＶＰのＲＥＳＶメッセージに含めて送出しても良い。
【００６９】
また、上流側に同期チャネル番号と帯域確保を行うフローの対応の通知をRESVメッセージとは別のメッセージで行ってもよい。この場合は、RESVメッセージは単に接続装置に対して、該フローの帯域確保の要求をするために用いられ、同期チャネル番号と帯域確保を行うフローの対応関係は、別メッセージ( 本図ではFANPメッセージ) にて行われてもよい。この通知を受けた接続装置は、RESVメッセージで帯域予約を受けたフローについて、どのリンクレイヤコネクション、つまり同期チャネルにて転送すればよいのかについての情報を、このメッセージから得ることができる。
【００７０】
さて、端末１０３のユーザが、異なるビデオ映像( 例えば、違うチャネルのテレビ番組) を見たいと考えた場合、上記同様の手続きをもう一度踏む事になる。即ち、その新しいビデオ映像に対応するＩＰマルチキャストアドレスを上位プロトコルなどを通じて入手し、該ＩＰマルチキャストアドレスへの加入という手続きを再度踏むことで、これを実現する。その際は、先に加入していたＩＰマルチキャストアドレスは離脱することが、通信資源の有効活用の観点から望ましい。この様子を図９に示している。
【００７１】
また、家庭内に構築されたネットワークには端末が複数接続され、その各々が別々の放送を見ている場合は、その各々のデータが公衆網１０４および接続装置１０２を通ることになる。接続装置１０２において、データリンクスイッチを行うため、別々のＡＴＭ−ＶＣにて別々の端末宛てのこれらのデータが伝送されてくることが望ましい。通信資源の確保については、再度上記のようなＳＢＭ／ＲＳＶＰ／ＦＡＮＰ等を使った手続きが必要あるかどうかは、ＲＳＶＰ／ＳＢＭの予約の仕方による。即ち、Ｓｈａｒｅｄ Ｅｘｐｌｉｃｉｔの予約であれば、送信者のビデオサーバが同一である限り、あるいはＳｈａｒｅｄ Ｅｘｐｌｉｃｉｔのサーバのアドレスとして、次にビデオを送出する新しいビデオサーバが登録されていれば、先に予約したのと同一の通信資源（ＡＴＭのＶＣ、１３９４の同期チャネル）をそのまま利用し続ければよく、ＩＰマルチキャストの再加入を行うのみで良い。
【００７２】
（Ｂ） 次に、ＩＰマルチキャストアドレスは同じで、コンテンツが変わる場合を説明する。この場合は、同一のマルチキャストアドレスを用いて、同一のユーザに対して複数の映像サービスを行う形式となり、上位プロトコルを用いて映像コンテンツの変更（テレビのチャネルの変更に相当）を行う形となる。
【００７３】
このときも、最初の通信資源の確保までは同じ手順を踏む。ただし、上位レイヤプロトコルを通して与えられるＩＰマルチキャストアドレスは、あらかじめその端末に固有に与えられた（あらかじめ、ネットワークサービスプロバイダが、ユーザ毎、あるいは端末毎に割当てておいた）ＩＰマルチキャストアドレスであってもよい。端末の識別は、例えばネットワークサービスプロバイダがあらかじめ端末毎に与えておいた識別子を用いて、上位レイヤプロトコルを使って行う等の方法が考えられる。
【００７４】
次のコンテンツの変更（テレビのチャネルの変更に相当）の際に、端末は上位レイヤプロトコルを用いて、このコンテンツ変更を要求する。ビデオサーバ１０１は、使用しているＩＰマルチキャストアドレスを変更することなく、そのまま用い、変更したコンテンツを、該ＩＰマルチキャストアドレス宛に送出する。
【００７５】
前述の様に、このＩＰマルチキャストアドレスは、図１０に示すように、必ずしもマルチキャストに用いる必要は無く、単一の端末に対するコンテンツ転送に用いても良い。即ち、一つ一つのマルチキャストアドレスを、ビデオ配信の要求のあったユーザ( 端末) に割当て、送出コンテンツの変更は、例えば上位レイヤプロトコルにて対応する。
【００７６】
また、接続装置１０２から送信されるＩＰパケットのポート番号の違いを見て、別々のマルチキャストアドレスを割当てる判断のトリガとしてもよい。
このように、ユーザ毎、あるいはアプリケーション毎に別々のＩＰマルチキャストアドレスを与えるようにすることにより、ＩＰマルチキャストアドレスは端末に対して動的な割当てが可能であることから、プライベートアドレス環境においても、グローバルユニークなＩＰアドレスとの重複を心配すること無く、種々のコンテンツをプライベートアドレスを持った端末に送信することが可能となる。
【００７７】
なお、本実施例においてはIPマルチキャストのデータフローの転送をRSV P を使って帯域予約する場合を記述してきたが、全く同様の方法をIPユニキャスト、あるいは他のネットワークレイヤのユニキャスト、あるいはマルチキャストについて適用できることは明らかである。
【００７８】
（第２の実施形態）
図１１は、本発明の第２の実施形態に係るネットワークの構成例を示したもので、ＩＥＥＥ１３９４バス上にＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）ルータ２１０１、ＩＥＥＥ１３９４の同期リソースマネージャ２１０４、端末２１０２、２１０３が互いに通信可能なように接続されて構成されている。
【００７９】
（２−１）
このような構成のネットワークにおいて、端末２１０２、２１０３がＩＰマルチキャストへ加入して、マルチキャストデータを受信する場合について説明する。ここで、端末２１０２、２１０３は、ＩＰマルチキャストへ加入した後は、マルチキャストデータの受信端末となることから、以下、受信端末２１０２、２１０３と呼ぶ。
【００８０】
受信端末２１０２、２１０３がＩＰマルチキャストに加入する場合の手順について、図１２を参照して説明する。また、その際のＩＧＭＰルータ２１０１の処理手順を図１３に示す。
【００８１】
図１１に示したように、ＩＥＥＥ１３９４バス上には、ＩＧＭＰルータ２１０１、受信端末２１０２、２１０３、同期リソースマネージャ２１０４が接続されている。受信端末２１０２のＩＰアドレスは「ＩＰ１」、受信端末２１０３のＩＰアドレスは「ＩＰ２」であるとする。また、同期リソースマネージャ２１０４の機能は、他の３つの装置のうちのいずれかと一体となっていてもよい（即ち、ＩＧＭＰルータ２１０１あるいは受信端末２１０２、２１０３のうちのいずれかが同期リソースマネージャであってもよい）。
【００８２】
受信端末２１０２、２１０３は、予め何らかの手段にてＩＰマルチキャストアドレス「ＩＰｍ」を取得しているものとする。
まず、受信端末２１０２がＩＰマルチキャストアドレス「ＩＰｍ」に加入を希望しているとする。そのため、ＩＧＭＰルータ２１０１と、受信端末２１０２との間で、ＩＧＭＰメッセージのやり取り（ＩＧＭＰクエリーやＩＧＭＰレポート等の送受信）が行なわれ、受信端末２１０２がＩＧＭＰルータ２１０１に対して、ＩＰマルチキャストアドレス「ＩＰｍ」に対して加入を希望している旨を伝える（Ｓ２１０１）。ここで、ＩＧＭＰルータ２１０１は、このＩＰマルチキャストアドレス「ＩＰｍ」のサポートを行なうことのできるルータであるとする。
【００８３】
ＩＧＭＰルータ２１０１は、セットトップボックスのようなものでもよい。即ち、放送波を通じて送られてくるＩＰマルチキャストパケットの中から、適当なＩＰマルチキャストアドレス宛のパケットを抽出し、これをフォワードする機能を持ったノードであってもよい。
【００８４】
ＩＧＭＰルータ２１０１は、受信端末２１０２からＩＰマルチキャストドレス「ＩＰｍ」への加入要求を受信すると、図１３のフローチャートに従った処理を実行する。すなわち、本実施形態の場合、受信端末２１０２からの加入要求が、そのサブネット（ＩＥＥＥ１３９４バス）からのＩＰマルチキャストアドレス「ＩＰｍ」への最初の加入要求であるため、ＩＧＭＰルータ２１０１は、所定のＩＰマルチキャストアドレスへの加入手続き処理を行い（ステップＳ２２０１〜ステップＳ２２０３）、その手続き処理が成功したら、次に、同期リソースマネージャ２１０４にアクセスし、同期チャネル番号を確保する（ステップＳ２２０４〜ステップＳ２２０５、図１２のステップＳ２１０２）。なお、図１３のステップＳ２２０３において、ＩＧＭＰルータ２１０１は、さらに上流のＩＧＭＰルータに働きかけ、このＩＰマルチキャストアドレスへの加入手続きを行なってもよい。また、加入手続き処理が失敗した場合は、その旨を受信端末２１０２に通知する（図１３のステップＳ２２０６）。
【００８５】
図１３のステップＳ２２０５において、ＩＧＭＰルータ２１０１からの要求に応じて同期リソースマネージャ２１０４にて確保された同期チャネル番号を「＃ｘ」とする。ここで、同時に帯域を確保する必要は必ずしもない。これは、この時点で確保されるのはＩＥＥＥ１３９４の非同期ストリームであるからである。
【００８６】
非同期ストリームとは、非同期パケットのアービトレーション時間に送信される、同期パケットのフォーマットのパケットであり、同期リソースマネージャ２１０４を通じて同期チャネル番号のみが確保される。
【００８７】
帯域を確保することが必要な場合については後述する。
図１３の説明に戻り、ＩＧＭＰルータ２１０１は、同期チャネル番号が確保されると、次に、自らのレイヤ３フローレジスタに、このＩＰマルチキャストフローについての情報を記入する（ステップＳ２２０６、図１２のステップＳ２１０３）。
【００８８】
図１４は、レイヤ３フローレジスタのフォーマットの一例を示したもので、レイヤ３フローレジスタは、基本的にレイヤ２識別子（本実施形態の場合、同期チャネル番号）と、そのレイヤ２識別子であらわされるチャネルを通ることになるレイヤ３フローについての対応関係を登録するためのレジスタである。このレジスタには、その他に、そのフローが入力されるものであるのか、出力されるものであるのかについての情報、そのレイヤ２識別子であらわされるチャネルに確保された帯域量、そのチャネルを使用している端末をカウントするカウンタ等の領域が用意されている。
【００８９】
図１４に示すように、ここでは、確保されたチャネルには帯域が確保されないので、レイヤ３フローレジスタの帯域の項目欄には、例えば「０」が記入されている。
【００９０】
このチャネルに対して宛先がＩＰマルチキャストアドレスが「ＩＰｍ」であるＩＰフローが流れ込むことになるため、フロー識別子として、受信側ＩＰアドレスには「ＩＰｍ」を、受信側ポート番号には、番号が限定されている時はその番号（例えばＰＯＲＴ１）を、限定されていない時は例えば「０」を記入する。本実施形態では、特に限定が無いため「０」を記入する。ＩＰマルチキャストアドレスは、送信端末は限定されないため、送信端末や送信ポート番号にはそれぞれ「０」が記入される。
【００９１】
レイヤ２識別子としては、ここではレイヤ２種別として「ＩＥＥＥ１３９４」、識別子種別として「同期チャネル番号」が記入され、識別子としては、先に確保された同期チャネル番号である「＃ｘ」が記入される。
【００９２】
方向としては、基本的にこのＩＧＭＰルータがこれらのＩＰマルチキャストパケットを送信するものとして「順方向」とする。
コネクションカウンタは、この非同期ストリームを受信していると考えられるノードの数を表すカウンタである。受信者はこの時点で受信端末２１０２のみであると考えられるので、カウンタ値「１」が入力される。
【００９３】
なお、このレイヤ３フローレジスタは、ＩＥＣ１８８３にて使用されるプラグコントロールレジスタおよびそのチャネルで転送されるレイヤ３フローについての情報を格納するレジスタの組み合わせの形で実現しても良い。
【００９４】
次に、ＩＧＭＰルータ２１０１は、受信端末２１０２のレイヤ３フローレジスタに対して、図１４と同様の情報を書き込む（ステップＳ２２０７、図１２のステップＳ２１０４）。
【００９５】
このようにして、レイヤ３フロー情報と、レイヤ２識別子との対応関係が、受信端末２１０２のレイヤ３フローレジスタに書き込まれることで、受信端末２１０２は、今後、非同期ストリームのチャネル番号「＃ｘ」は、ＩＰマルチキャストアドレス「ＩＰｍ」宛のＩＰマルチキャスト用に割り当てられたことが認識できる。受信端末２１０２は、ＩＰマルチキャストアドレス「ＩＰｍ」宛のデータグラムについては、チャネル番号「＃ｘ」の非同期ストリームを受信すれば良い（ステップＳ２１０５）。
【００９６】
なお、上記実施形態では、受信端末２１０２のレイヤ３フローレジスタ内に、そのチャネル番号で示される非同期ストリームあるいは同期チャネルから流れてくるＩＰフローが、入力されてくるのか、出力するものなのかについての情報が書かれているが、レイヤ３フローレジスタを入力用と出力用とを分けて用意しておき、これらを適当に使い分けることも可能である。
【００９７】
さて、図１２の説明に戻り、受信端末２１０３が続いて同じＩＰマルチキャストアドレス「ＩＰｍ」に加入を希望しているものとする。ＩＧＭＰによる加入手続きがＩＧＭＰルータ２１０１と受信端末２１０３の間で行われる（Ｓ２１０６）。
【００９８】
そして、ＩＧＭＰルータ２１０１では、図１３のフローチャートに示したような処理動作を実行する。すなわち、ＩＧＭＰルータ２１０１は、すでにこのＩＰマルチキャストアドレス「ＩＰｍ」についてのサービスを開始しているため、自らのレイヤ３フローレジスタのコネクションカウンタをインクリメントし（例えば、コネクションカウンタの値を「２」とする）、さらに受信端末２１０３のレイヤ３フローレジスタに、受信端末２１０２の同レジスタと同じ情報を書き込んで、チャネル番号とＩＰフローの対応関係を通知する。
【００９９】
なお、ＩＰマルチキャストアドレス「ＩＰｍ」に加入している端末数は、ＩＧＭＰルータ２１０１が把握しており、各端末が把握する必要は必ずしもないため、各受信端末２１０２、２１０３の同レジスタに書き込まれるコネクションカウンタの値は、例えば「１」でも良い。
【０１００】
以上はＩＰマルチキャストアドレスへの加入手続きについての説明であったが、次に、脱退の時のＩＧＭＰルータ２１０１の動作について、図１５に示すフローチャートを参照して説明する。
【０１０１】
脱退の場合、ＩＧＰＭルータ２１０１は、受信端末のいずれかかからＩＰマルチキャストアドレス「ＩＰｍ」への脱退手続きを受信した場合（ステップＳ２３０１）、あるいは、受信端末のいずれかからのＩＰマルチキャストアドレス「ＩＰｍ」を受信し続けているとのキープアライブ信号であるＩＧＭＰ ＲＥＰＯＲＴを一定時間以上受信しなかった場合（ステップＳ２３０２）、当該受信端末が上記ＩＰマルチキャストアドレス「ＩＰｍ」の受信を止めるものと判断し、自らのレイヤ３フローレジスタのコネクションカウントの値をデクリメントする（ステップＳ２３０３）。
【０１０２】
ＩＧＭＰルータ２１０１のレイヤ３フローレジスタに書き込まれるコネクションカウントの値は、そのＩＥＥＥ１３９４バス上における、ＩＰマルチキャストアドレス「ＩＰｍ」に加入している端末の数であるため、この値が「０」になったとき（ステップＳ２３０４）、そのＩＥＥＥ１３９４バス上にＩＰマルチキャストアドレス「ＩＰｍ」を受信している端末はもはやなくなったものと判断し、そのＩＰマルチキャストアドレス「ＩＰｍ」から脱退する（ステップＳ２３０５）。
【０１０３】
これと前後して、脱退した受信端末に脱退した旨を伝えるため、その受信端末のレイヤ３フローレジスタに、例えばオール「０」の値を書き込むなどの動作を行なってもよい。
【０１０４】
なお、このＩＰマルチキャストアドレス加入、あるいは加入後の一連の過程でＩＥＥＥ１３９４バスでバスリセットが引き起こされた場合においても、これらのＩＰマルチキャストアドレスについての情報を保持しつづけ、レジスタ（レイヤ３フローレジスタ）の値も保持しておくことで、迅速なＩＰマルチキャストデータグラム受信の復帰を行なうことが可能である。
【０１０５】
繰り返しになるが、ＩＰマルチキャストアドレス「ＩＰｍ」宛ての全てのパケットは、チャネル番号「＃ｘ」にて表される非同期ストリームを通じて送受信されるものとなる。なお、ＩＧＭＰ等の制御パケットについては、当該マルチキャストアドレスに対応する非同期ストリームを使用しても良いし、またはデフォルトの非同期ストリーム（ＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）やＩＰブロードキャスト等のために割当てられた非同期ストリームのチャネルや非同期のブロードキャストを用いて、これを通信しても良い。
【０１０６】
また、ＩＰマルチキャスト加入時にＩＧＭＰの制御パケットや、ＩＰアドレス＝「２２４．０．０．１」等の全ホストが宛先アドレスのＩＰパケット等が流れるチャネルとしては、デフォルトの非同期ストリーム、もしくは非同期ライトのブロードキャストのいずれかを使用する。
【０１０７】
（２−２）
次に、ＩＰマルチキャストを「帯域（ＱＯＳ）あり」の状態に変更する場合、すなわち、非同期ストリームに対して帯域を与え、これを送受信する場合について図１６のシーケンス図を参照して説明する。
【０１０８】
受信端末２１０２が、ＩＰマルチキャストアドレス「ＩＰｍ」宛のデータグラムを受信できるようになるまで（ステップＳ２５０１〜ステップＳ２５０４）は、図１２のステップＳ２１０１〜ステップＳ２１０５と同様である。
【０１０９】
このＩＰマルチキャストについて、帯域ありの伝送が可能である場合、ＩＧＭＰルータ２１０１は、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｓｅｔｕｐ Ｐｒｏｔｏｃｏｌ）のＰＡＴＨメッセージを受信端末（ＩＰマルチキャストアドレス「ＩＰｍ」）に対して送付する（ステップＳ２５０５）。
【０１１０】
これに対し、このＩＰマルチキャストを「帯域あり」の状態で受信したい受信端末２１０２は、上流側（即ちＩＧＭＰルータ２１０１）に対して、ＲＳＶＰのＲＥＳＶメッセージを送付して、帯域の確保を要求する（ステップＳ２５０６）。
【０１１１】
ＩＰ上の帯域予約プロトコルの一例であるＲＳＶＰでは、送信ホスト（上流側のノード）がＰＡＴＨメッセージをデータと共に送信する。通信帯域などはこの送信ホストが基本的に設定する。これに対して、帯域予約を希望する受信端末は、ＲＥＳＶメッセージを送信ノード宛てに送信する。一般にルータは、ＰＡＴＨメッセージに対応するＲＥＳＶメッセージを監視して、ＲＥＳＶメッセージを検出すると帯域予約を実行する。ここでは、既に説明したＩＰマルチキャストアドレスとチャネルの対応が設定されているものとする。
【０１１２】
受信端末２１０２からのＲＥＳＶメッセージを検出すると、ＩＧＭＰルータ２１０１は、同期リソースマネージャ２１０４にアクセスし、帯域を確保する。帯域が確保できた場合は、自らと受信端末２１０１のレイヤ３フローレジスタに確保した帯域情報（帯域量ｙ）を記入して、帯域確保に成功した旨を伝える（ステップＳ２５０７〜ステップＳ２５０８）。
【０１１３】
その後、帯域の確保された同期チャネル（チャネル番号「＃ｘ」）を使って、引き続きＩＰマルチキャストアドレス「ＩＰｍ」宛のデータグラム配送が行われる（ステップＳ２５０９）。
【０１１４】
なお、この時点で複数の受信端末がいる場合には、各々の受信端末のレイヤ３フローレジスタの帯域の部分をＩＧＭＰルータ２１０１は書き換えてもよい。また、各々の受信端末の同レジスタの書き換えが、受信端末数が多い時などに面倒な作業となるため、受信端末の同レジスタの書き換えは行なわず、自ら（ＩＧＭＰルータ２１０１）のレイヤ３フローレジスタの値のみを反映させる方式も考えられる。
【０１１５】
以上説明したように、非同期ストリームに対して帯域を与える際には、ＱＯＳパケットを送信するノードが帯域の確保を行うというルールに従うことにより、複数の受信端末が同時に同じチャネルに対して帯域を確保してしまうような、いわゆる帯域の２重確保を回避することが可能である。また、通常必要な帯域は送信ノードがその値を把握している場合が多いと考えられるため、この観点からも妥当である。
【０１１６】
（２−３）
さて、これまではレイヤ３フローレジスタを使って、ＩＰマルチキャストフローと、そのフローが流れる同期チャネルまたは非同期ストリームのチャネル番号の対応関係を通知してきたが、これをＦＡＮＰ（Ｆｌｏｗ ＡｔｔｒｉｂｕｔｅＮｏｔｉｆｉｃａｔｉｏｎＰｒｏｔｏｃｏｌ）を用いて行なうことも可能である。ＦＡＮＰは、ＩＰデータグラムを用いて、あるデータリンクレイヤのチャネル（例えばＩＥＥＥ１３９４の同期チャネルや非同期ストリーム、あるいはＡＴＭやフレームリレーの仮想チャネル等）と、そのチャネルを通る上位レイヤのフロー（例えばＩＰフロー）の対応関係を通知するプロトコルである。
【０１１７】
この場合の手順を図１７に示すシーケンス図を参照して説明する。受信端末２１０２がＩＰマルチキャストアドレス「ＩＰｍ」への加入を希望している場合、ＩＧＭＰを使った加入手続きは、ＩＧＭＰルータ２１０１との間で図１２の場合と同様に行なわれる（ステップＳ２６０１）。ＩＧＭＰルータ２１０１は、このＩＰマルチキャストアドレス「ＩＰｍ」のためのチャネルを確保するべく、同期リソースマネージャ２１０４にアクセスし、チャネル番号「＃ｘ」を確保する（ステップＳ２６０２）。
【０１１８】
次に、ＩＧＭＰルータ２１０１は、受信端末２１０２に対して、「チャネル「＃ｘ」を通して、ＩＰマルチキャスト「ＩＰｍ」を提供する」旨を通知するため、ＩＥＥＥ１３９４のプラグコントロールレジスタとＦＡＮＰを使う。
【０１１９】
プラグコントロールレジスタとは、あるチャネル番号を使って提供される、同期チャネル／非同期ストリームを受信、あるいは送信するように促す作用のあるレジスタであり、入力用と出力用が分かれている。このプラグコントロールレジスタを使って、ＩＧＭＰルータ２１０１は、受信端末２１０２に対して、チャネル「＃ｘ」を受信するように促す（ステップＳＳ６０３）。なお、その際、ＩＧＭＰルータ２１０１は、自らのプラグコントロールレジスタについても記入を行なってもよい。この場合は、コネクションカウンタに前例と同様なルールで、そのＩＰマルチキャストアドレスの受信端末の数を記入していってもよい。これにより、そのマルチキャストをそのチャネルから受信しているノード数などの把握を行うことが可能である。
【０１２０】
次に、ＩＧＭＰルータ２１０１は、ＦＡＮＰオファーメッセージとして、図１８のようなメッセージを受信端末２１０２に送付する。このＦＡＮＰメッセージの宛先はＩＰマルチキャストアドレス「ＩＰｍ」であり、また、このＦＡＮＰメッセージはＩＥＥＥ１３９４バスに割り当てられたレイヤ３パケットのブロードキャストチャネル（例えば、特定の非同期ストリームや、ノードＩＤ＝オール「１」宛のパケット）で送付される。
【０１２１】
図１８に示すように、ＦＡＮＰオファーメッセージには、フロー識別子とレイヤ２識別子が含まれ、前述したようなレイヤ２識別子（本実施形態の場合、チャネル番号「＃ｘ」）と、このレイヤ２識別子であらわされるチャネルを通して提供される上位レイヤフロー（本実施形態の場合、ＩＰマルチキャストアドレス「ＩＰｍ」）との対応関係を通知する（Ｓ２６０４）。
【０１２２】
その後、このチャネル「＃ｘ」を通じて、ＩＰマルチキャストアドレス「ＩＰｍ」宛のデータグラムが送信されることになる（ステップＳ２６０５）。
同様に、他の受信端末２１０２からの加入要求があった場合（ステップＳ２６０６）も、プラグコントロールレジスタへの書き込みと（ステップＳ２６０７）、ＦＡＮＰメッセージの送付（ステップＳ２６０８）を行なうことで、対応関係の通知を行なうことができる。
【０１２３】
なお、この場合、ＦＡＮＰメッセージは、ＩＰマルチキャストアドレス宛であるため、受信端末が複数の場合であっても、必ずしもいちいち各々の受信端末宛にＦＡＮＰメッセージを送付する必要は必ずしもなく、ＩＰマルチキャストアドレス「ＩＰｍ」宛のデータグラムを１回送信すればよいので、ＩＥＥＥ１３９４バス上のトラヒックを減らすことが出きる点で有利である。
【０１２４】
さて、本実施形態においては、プラグコントロールレジスタとＦＡＮＰオファーメッセージを使って、レイヤ２識別子とレイヤ３フローの対応関係を通知してきた。ここで、ＦＡＮＰメッセージを使わないと上記対応関係の通知はできないが、プラグコントロールレジスタへの書き込みにより、受信端末はこの同期チャネルからのデータ受信は行なうようになるため、必ずしも上記対応関係の通知が必要ない場合は、上記ＦＡＮＰメッセージの送付は省略してもよい。また逆に、ＦＡＮＰメッセージがあれば、受信端末はどのチャネル番号からどのレイヤ３フローが入力されてくるのかを認識することが可能であるため、プラグコントロールレジスタへの書き込み手順を省略することも可能である。
【０１２５】
（２−４）
次に、同じＩＰマルチキャストアドレスを用いて、複数のフローが送信される場合の手順を図１９に示すシーケンス図を参照して説明する。
【０１２６】
図１９では、ＩＧＭＰルータ２１０１から受信端末２１０１に向ってＩＰマルチキャストアドレスが「ＩＰｍ」のマルチキャストパケットが送信される場合、ポート番号が「ＰＯＲＴ１」で表されるフロー（ステップＳ２８０４）と、「ＰＯＲＴ２」で表されるフロー（ステップＳ２８０５）の計２つのフローが同時に送信される場合を示している。
【０１２７】
ＩＧＭＰによるマルチキャストアドレスへの加入（ステップＳ２８０１）、ＩＧＭＰルータ２１０１による同期チャネル番号の確保（ステップＳ２８０２）については、前述同様である。
【０１２８】
ステップＳ２８０３で、レイヤ３フローレジスタの書き込みを行う際には、特に、ステップＳ２８０２で確保した同期チャネル番号「＃ｘ」で表される非同期ストリームに送信されるフローは特に限定されず、単にＩＰマルチキャストアドレス「ＩＰｍ」のパケットが送信される事のみが限定されることから、ステップＳ２８０４とステップＳ２８０５の両方のフローが、チャネル番号「＃ｘ」で表される非同期ストリームにて転送される。
【０１２９】
さて、このうちＩＧＭＰルータ２１０１は、「ＰＯＲＴ１」で表されるフローについては、ＱＯＳありの送信を許容しているものとする。そのため、ＩＧＭＰルータ２１０１は、ＲＳＶＰのＰＡＴＨメッセージをＩＰマルチキャストアドレス「ＩＰｍ」宛てに送信する（ステップＳ２８０６）。これに対し、受信端末２１０１はＲＥＳＶメッセージを送信することで、帯域の確保を要求する（Ｓ８０７）。すると、ＩＧＭＰルータは、同期リソースマネージャにアクセスし、ＲＳＶＰメッセージで指定された、必要な帯域を確保する。ここでは、この値を「ｙ」とする（ステップＳ２８０８）。
【０１３０】
すると、ＩＧＭＰルータ２１０１は、受信端末２１０２に対して、同期チャネル番号「＃ｘ」を通して帯域量「ｙ」のデータが、同期チャネルのアービトレーション周期にて送信されることを受信端末２１０２に通知するため、受信端末２１０２のレイヤ３フローレジスタに書き込む（ステップＳ２８０９）。ステップＳ２８０９において、受信端末２１０２に通知する内容は、レイヤ３フローレジスタを用いる場合に限らず、前述したＦＡＮＰ、あるいはＩＥＣ１８８３のプラグコントロールレジスタを用いても通知できる。どれを用いるかはシステムに依存である。
【０１３１】
その後のＩＧＭＰルータ２１０１からのＩＰマルチキャストデータの送信は、帯域確保がされていない「ＰＯＲＴ２」で示されるフローについては、ステップＳ２８０５でのフローと同様、非同期ストリームを通して送信されるが（ステップＳ２８１１）、帯域確保を行った「ＰＯＲＴ１」で表されるフローについては、同期チャネルとして（即ち、同期のアービトレーション期間にて）送信される（ステップＳ２８１０）。
【０１３２】
さて、ＩＧＭＰルータ２１０１において、同期チャネル「＃ｘ」で確保した帯域量「ｙ」以上の帯域のＩＰマルチキャストデータ（「ＩＰｍ」宛てのＩＰマルチキャストパケット）が入り込む可能性がある。これらのパケットをそのまま同期チャネル「＃ｘ」に流し込むことは、確保していない帯域分も、このＩＰマルチキャストパケットが通信資源を消費してしまうことを意味し、望ましくない。
【０１３３】
そこで、図２０のようなアルゴリズムを用いて、帯域が確保されている分については同期チャネルに（ステップＳ２９０１、ステップＳ２９０２）、確保されていない分については非同期ストリームに（ステップＳ２９０１、ステップＳ２９０３）それぞれ送信するというルールを作ることにより、確保した以上の帯域量のデータを、該同期チャネルに流し込んでしまうことを防ぐことが出来る。
【０１３４】
ここで、Ｔスペックとは、ＲＳＶＰの予約の時に指定されるトラヒックパラメータのことで、ピークレートやリーキーバケットのバケツの深さ等が指定されてもよい。
【０１３５】
図２０のメカニズムを実現するための構成例を図２１に示す。ＷＦＱとは、Ｗｅｉｇｈｔｅｄ Ｆａｉｒ Ｑｕｅｕｅｉｎｇの略で、１つの出力ポートを複数のセンダ／フローからのパケットが共有する場合に、フロー毎にあらかじめ指定された量（重みという）の比に従って、送出されるパケット量の比もこれと同じにするパケットスケジューリング方法である。
【０１３６】
ＷＦＱ処理部２２０１は、このＷＦＱのスケジューリングで、Ｔスペックを満たすものについては、同期キュー２２０２に、満たさないものについては非同期キュー２２０３に入れるものとし、同期キューに溜められたデータは、パケット送信部２２０４を介して同期のアービトレーション期間に、非同期キューに溜められたデータは、パケット送信部２２０４を介して非同期のアービトレーション期間にそれぞれ送信される。
【０１３７】
以上は、帯域を確保した場合にも、同期チャネル番号は同じ値を続けて使用する使い方についてであった。これに対して、帯域確保が必要なチャネルについては、非同期ストリームで利用していたチャネル（「＃ｘ」）とは別の同期チャネル（「＃ｚ」）を確保する方法も考えられる。
【０１３８】
この場合の手順について、図２２のシーケンス図を参照して説明する。
図２２のステップＳ３１０１〜ステップＳ３１０７において、ＲＳＶＰのＲＥＳＶメッセージにて、帯域確保の要求（ＲＥＳＶ）が受信端末２１０１からあるまでは、図１９のステップＳ２８０１〜ステップＳ２８０７と同様である。
【０１３９】
ステップＳ３１０７で、帯域の確保要求を受け取ると、ＩＧＭＰルータ２１０１は、これまで使用していた非同期ストリームのチャネル番号（「＃ｘ」）とは異なる、同期チャネル番号（「＃ｚ」）と帯域量（ｙ）の両方の確保を行う（ステップＳ３１０８、ステップＳ３１０９）。
【０１４０】
この場合も「送信者（すなわち、本実施形態の場合、ＩＧＭＰルータ２１０１）が、リンクレイヤの必要な帯域を確保する」というルールに従っている。その後、ＩＧＭＰルータ２１０１は、受信端末２１０２のレイヤ３フローレジスタに、「ＰＯＲＴ１」で表されるフローについては、同期チャネル番号「＃ｚ」で表される（非同期ストリームではなくて）同期チャネルを用いて送信されることを書き込むことで、受信端末２１０２に通知する（ステップＳ３１１０）。なお、ステップＳ３１１１において、受信端末２１０２に通知する内容は、レイヤ３フローレジスタを用いる場合に限らず、前述のように、ＩＥＣ１８８３のプラグコントロールレジスタや、ＦＡＮＰを用いて行うこともできる。
【０１４１】
以後、ＩＰマルチキャストアドレス「ＩＰｍ」宛てのパケットのうち、「ＰＯＲＴ１」で表されるフローについては、同期チャネル「＃ｚ」を通して、同期チャネルで転送され（ステップＳ３１１１）、それ以外のフローについては、引き続き非同期ストリームにて送信され続ける（ステップＳ３１１２）。
【０１４２】
（２−５）
次に、１つのチャネル番号で示される非同期ストリームあるいは同期チャネルを用いて、複数のマルチキャストデータのセンダがいる場合について、図２３を参照して説明する。なお、ここでは、図１１の端末２１０２、２１０３は、ＩＰマルチキャストへ加入した後は、マルチキャストデータの送受信端末となり、以下、端末２１０２、２１０３を端末Ａ、端末Ｂと呼ぶ。
【０１４３】
図２３は、同一のＩＰマルチキャストアドレス「ＩＰｍ」に対して、端末Ａ（ＩＰアドレス「ＩＰ１」、１３９４アドレス「ＦＷ１」）と、端末Ｂ（ＩＰアドレス「ＩＰ２」、１３９４アドレス「ＦＷ２」）の２つの端末がＩＰマルチキャストパケットを送信する場合を示している。ここで、１３９４アドレスとは、例えばＩＥＥＥ１３９４のノードＩＤ等、そのＩＥＥＥ１３９４バス上でその端末を一意に識別することの出来るＩＤを指す。
【０１４４】
図２３のステップＳ３２０１〜ステップＳ３０４、ステップＳ３２０６〜ステップＳ３３２０８のマルチキャストへの加入、チャネル番号の確保、ＩＰマルチキャストアドレスとチャネル番号との対応関係の通知の手順は、図１１と同様である。
【０１４５】
特徴的な点は、端末Ａ、Ｂのそれぞれは、ＩＰマルチキャストパケットに同一のチャネル番号「＃ｘ」で表されるチャネルに、自らのソースアドレス（「ＦＷ１」または「ＦＷ２」）を付加して当該パケットを送信する（ステップＳ３２０５、Ｓ３２０９、Ｓ３２１０）ことである。
【０１４６】
このソースアドレスは、フラグメントヘッダと呼ばれる、ＩＰパケットを１３９４フレームに分割する時に、そのそれぞれの分割片に付与するヘッダに書き込まれる。
【０１４７】
端末Ａ、Ｂのそれぞれから送出されるＩＰマルチキャストのデータ構成の概略を図２４に示す。なお、図２４（ａ）は端末Ａから送出されるＩＰマルチキャストのデータ構成で、図２４（ｂ）は端末Ｂから送出されるＩＰマルチキャストのデータ構成である。図２４（ａ）、（ｂ）に示すように、ＩＰマルチキャストパケット（あるいはこれをフラグメントしたもの）３３０１、３３０４をソースアドレスを含むフラグメントヘッダでカプセル化して生成されたフラグメントデータ３３０２、３３０５を、更に１３９４フレーム１３０３（この場合、同期フレーム）に収めて構成される。
【０１４８】
受信者は、同一のチャネル番号で示される非同期ストリームから、複数のセンダからのパケットを受け取ることになるが、このようにソースアドレスがそれぞれのフレームに付与されていることで、各々のパケットのリアセンブリを、ソースアドレスを参照することにより、正確に行うことが出来るようになる。
【０１４９】
以上は、同一のＩＰマルチキャストアドレスに対して、複数のセンダが送信する場合において、帯域確保が伴わない場合についての説明であった。これに対し、帯域確保を伴う場合の説明を以下に行う。
【０１５０】
図２５において、例えば、図２３のＳ３２０１〜Ｓ３２１０の手順が終了し、非同期ストリームの形で２つのセンダ、すなわち、端末Ａと端末Ｂとから同一のＩＰマルチキャストアドレス「ＩＰｍ」宛てのＩＰマルチキャストパケットが送信されているものとする（ステップＳ３４０１、ステップＳ３４０２）。
【０１５１】
ここで、端末Ａが、何等かの形で帯域ありの形でのＩＰマルチキャストデータの送信を依頼された場合（例えばＲＳＶＰのＲＥＳＶを受信した場合等）や、帯域ありの形でのデータ送信を自ら選択した様な場合、同期リソースマネージャ２１０４にアクセスして帯域量（ｙ１）を確保要求を行って（ステップＳ３４０３）、以後、端末Ａは、送信するＩＰマルチキャストのパケットは、確保された帯域量ｙ１の同期チャネルを通して、かつ、同期のアービトレーション期間に送信する（ステップＳ３４０４）。ここで、帯域確保をしていない端末Ｂは、同じチャネル番号「＃ｘ」にＩＰマルチキャストパケットを送信し続けているものの、送信は非同期ストリームとして、非同期のアービトレーション期間に送信する（ステップＳ３４０５）。
【０１５２】
端末Ｂが帯域ありの形で送信する場合は、端末Ｂも同期リソースマネージャ２１０４にアクセスして、やはり所望の帯域を確保し（ステップＳ３４０６）、データ送信を同期のアービトレーション期間内に行うことになる（ステップＳ３４０８）。
【０１５３】
先に確保された帯域をキャンセルする場合は、同期リソースマネージャ２１０４に対し、その帯域をキャンセルするための要求を行い（ステップＳ３４０９）、同期のアービトレーション周期にはパケットを送信しないようにし、もし送信パケットがある場合には、非同期ストリーム（非同期のアービトレーション期間）に送信する（ステップＳ３４１０）。
【０１５４】
これに対して、帯域ありの形でＩＰマルチキャストを送信する場合には、非同期ストリームで使用していたチャネル番号「＃ｘ」とは別のチャネル番号「＃ｚ」を持つ同期チャネルで、これを送信する方法も考えられる。この場合について、図２６のシーケンス図を参照して説明する。
【０１５５】
図２６において、例えば、図２３のＳ３２０１〜Ｓ３２１０の手順が終了し、非同期ストリームの形で２つのセンダ、すなわち、端末Ａと端末Ｂとから同一のＩＰマルチキャストアドレス「ＩＰｍ」宛てのＩＰマルチキャストパケットが送信されているものとする（ステップＳ３５０１、ステップＳ３５０２）。
【０１５６】
このとき、例えば、ＲＳＶＰのＲＥＳＶメッセージなどで、帯域ありの形でのＩＰマルチキャストパケットの送信を依頼された（例えば、図２６に示したように、端末ＡからのＲＳＶＰのＰＡＴＨメッセージにを受けて端末ＢからＲＥＳＶメッセージを受信したとき）、端末Ａは、同期リソースマネージャ２１０４にアクセスし、同期チャネル番号「＃ｚ」の確保と、帯域量「ｙ１」の確保を行う（ステップＳ３５０３〜ステップＳ３５０６）。
【０１５７】
続いて、確保した同期チャネル番号と、その同期チャネルを通して送信するフローの対応関係を通知するためのＦＡＮＰメッセージを、該ＩＰマルチキャストアドレス「ＩＰｍ」宛てに、例えば非同期ストリーム「＃ｘ」、またはデフォルトの非同期ストリームなどで送信する（ステップＳ３５０７）。これを受信したノードは、どの同期チャネルから、どのようなフローがどのような特性で入力されてくるかを認識することが出来るようになる。なお、前述のように、ここではＦＡＮＰメッセージを用いて、この対応関係の通知を行っているが、これはレイヤ３フローレジスタ、あるいはＩＥＣ１８８３において使用されるプラグコントロールレジスタを用いても実現が可能なものである。
【０１５８】
【発明の効果】
以上説明したように、第１の発明（第１の実施形態）によれば、ＲＳＶＰ等のネットワークレイヤのシグナリングプロトコルをＩＥＥＥ１３９４上で運用する方式がいまだ決まっておらず、そのままマッピングを行うと、ＩＥＥＥ１３９４上では通信品質が確保されず、エンドエンドの通信品質が保たれないという問題点に対し、ＲＳＶＰのＩＥＥＥ１３９４バス上での適用方法を示し、ＩＥＥＥ１３９４上でも、相互接続環境での通信品質を確保した通信が可能となる。
【０１５９】
また、第２の発明（第２の実施形態）によれば、ＩＥＥＥ１３９４等の放送型ネットワークにおいて、通信資源を有効に利用してＩＰマルチキャストを行うことができ、また、確保したチャネルとＩＰマルチキャストアドレスとの対応関係を送信側、受信側で同期して認識することのできる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るネットワーク全体の構成例を示したもので、映像サービスを提供しているビデオサーバからのデータを、公衆網を介して家庭内ネットワークにとりこみ、家庭内ネットワークに接続された端末で、該サービスを受ける状況を説明するための図。
【図２】図１の端末が接続装置、公衆網を通してビデオサーバからビデオを転送してもらうまでの全体の処理手順を示した図で、ＩＥＥＥ１３９４上の通信資源予約をＲＳＶＰの上流のノードが行う場合を示している。
【図３】図１の端末が接続装置、公衆網を通してビデオサーバからビデオを転送してもらうまでの端末の処理手順を示した図。
【図４】図１の端末が接続装置、公衆網を通してビデオサーバからビデオを転送してもらうまでの接続装置の処理手順を示した図。
【図５】接続装置に記憶される対応テーブルの一例を示した図。
【図６】ＲＳＶＰのＰＡＴＨメッセージのフォーマットの一例を示した図。
【図７】ＩＥＥＥ１３９４のＰＣＲレジスタの記述例を示した図。
【図８】図１の端末が接続装置、公衆網を通してビデオサーバからビデオを転送してもらうまでの通信システム全体の処理手順を示した図で、ＩＥＥＥ１３９４上の通信資源予約をＲＳＶＰの下流のノードが行う場合を示している。
【図９】すでに加入したＩＰマルチキャストアドレスを離脱して異なるＩＰマルチキャストアドレスに加入し、異なるコンテンツの配送を行う場合について説明するための図。
【図１０】ＩＰマルチキャストアドレスは同じで、コンテンツが変わる場合について説明するための図。
【図１１】本発明の第２の実施形態に係るネットワーク（ＩＥＥＥ１３９４バス）全体の構成例を示した図。
【図１２】受信端末がＩＰマルチキャストに加入する場合の手順を説明したシーケンス図。
【図１３】ＩＧＭＰルータにおけるＩＰマルチキャストアドレスへの加入時の処理手順を説明するためのフローチャート。
【図１４】レイヤ３フローレジスタのフォーマットの一例を示した図。
【図１５】ＩＧＭＰルータにおけるＩＰマルチキャストアドレスからの脱退時の処理手順を説明するためのフローチャート。
【図１６】ＩＰマルチキャストのために確保された非同期ストリームに対して帯域を与える場合の手順を説明するためのシーケンス図。
【図１７】ＩＰマルチキャストフローとチャネル番号の対応関係をＦＡＮＰを用いて行う場合の手順を説明するためのシーケンス図。
【図１８】ＦＡＮＰオファーメッセージの一例を示した図。
【図１９】同じＩＰマルチキャストアドレスを用いて、複数のフローが送信される場合の手順を説明するためのシーケンス図。
【図２０】同期チャネルに予め確保されている帯域量以上のＩＰマルチキャストデータを送信する場合のＩＧＭＰルータの処理動作について説明するためのフローチャート。
【図２１】図２０のアルゴリズムを実現するための構成例を示した図。
【図２２】ＩＰマルチキャストのために確保された非同期ストリームに対して帯域を与え、その帯域を与えられた同期チャネルには非同期ストリームとは異なるチャネル番号を用いる場合の手順を説明するためのシーケンス図。
【図２３】同一のＩＰマルチキャストアドレスに対して複数のセンダがいる場合の手順を説明するためのシーケンス図。
【図２４】端末Ａ、Ｂのそれぞれから送出されるＩＰマルチキャストのデータ構成の概略を示した図。
【図２５】同一のＩＰマルチキャストアドレスに対して複数のセンダが送信する場合において、さらに帯域確保を伴う場合の手順を説明するためのシーケンス図。
【図２６】同一のＩＰマルチキャストアドレスに対して複数のセンダが送信する場合において、さらに帯域確保を伴う場合には、非同期ストリームとは異なるチャネル番号を用いる場合の手順を説明するためのシーケンス図。
【符号の説明】
１０１…ビデオサーバ（通信装置、送信端末）
１０２…接続装置（通信制御装置）
１０３…端末（通信装置）
１０４…公衆網
１０５…第１の家庭内ネットワーク（ＩＥＥＥ１３９４）
１０６…第２の家庭内ネットワーク
２１０１…ＩＧＭＰルータ（通信装置）
２１０２…端末装置（受信端末、通信装置）
２１０３…端末装置（受信端末、通信装置）
２１０４…同期リソースマネージャ
【発明の属する技術分野】
本発明は、ＩＥＥＥ１３９４バス等の放送型のネットワークを介してデータ通信を行う通信装置に関する。
【０００２】
【従来の技術】
最近インターネットをはじめとする通信技術の急激な進歩が各方面で話題になっており、企業や大学などを中心にＬＡＮの導入、あるいはこれのＷＡＮやインターネットへの接続といったことが話題になっている。
【０００３】
これらの技術革新は、家庭を取り巻くネットワーク環境をも変える可能性が高い。即ち、家庭にＰＣやＤＶＤ、デジタルセットトップボックス等のデジタル機器が普及してくるに連れて、これらを相互にデジタルネットワークにて接続しようという気運が高まるのは必然である。現在、ＡＶベンダを中心に、ＩＥＥＥ１３９４バスが、その候補の筆頭として、各方面から注目を集めている。
【０００４】
ＩＥＥＥ１３９４バスは、１００Ｍ、２００Ｍ、４００Ｍｂｐｓの高速デジタル網として利用することができ、プラグアンドプレイ、同期チャネルを用いた同期転送機能等、いくつもの注目すべき機能がある。
【０００５】
それとともに、いわゆる家庭へのアクセス網の技術革新も急である。即ち、ＣＡＴＶやＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒａｉｂｅｒ Ｌｉｎｅ）、ＦＴＴＨ（ｆｉｂｅｒ−ｔｏ−ｔｈｅ−ｈｏｍｅ）等の高速ネットワーク技術、インターネット等のネットワークサービス等、その進歩は著しい。特に、インターネット技術は、その高速化、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）等ネットワークレイヤレベルのシグナリングプロトコルを用いたＱＯＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）保証、マルチキャスト等、注目すべき技術が次々と生まれている。
【０００６】
インターネット上で、これらの技術が実現する近未来においては、家庭へのビデオ転送等、高速、リアルタイムを要求される情報の転送の一部がインターネットを通じて行われる可能性がある。これは、インターネットに蓄積される情報量が実質的に無限であり、ユーザが、従来は地上波、衛星放送などからでていた前記情報をインターネットを通じて入手するようになると考えるのは、ごく自然なことである。
【０００７】
【発明が解決しようとする課題】
しかしながら、家庭内のデジタル機器を、アクセス網を介して接続し、インターネットを通じた情報のやり取りをしようとした場合、以下のような問題点が考えられる。
【０００８】
現在、ＩＥＥＥ１３９４上をインターネットのデータを流通させるための検討、即ち「ＩＰ ｏｖｅｒ １３９４」の検討が、各方面で進められている。しかし、現在その検討はいわゆるアドレス解決方式にとどまっている。一方、インターネット上を通信品質を保証する形でデータのやり取りを行うためのシグナリングプロトコルとして、例えばＲＳＶＰが提案されている。しかし、これらのネットワークレイヤのシグナリングプロトコルをＩＥＥＥ１３９４上で運用する方式がいまだ決まっておらず、ＩＥＥＥ１３９４上では通信品質が確保されない転送方式にマッピングせざるをえない。従って、上記シグナリングが実行されたとしても、ＩＥＥＥ１３９４上をベストエフォート（具体的には非同期チャネル）を通じてデータが転送されてしまうため、エンドエンドの通信品質が保たれない。
【０００９】
また、ＩＥＥＥ１３９４バス上でＩＰマルチキャストを送受信しようとした場合、ＩＥＥＥ１３９４バス上のトラヒックを最小限にするために、ＩＥＥＥ１３９４バスの同期チャネルあるいは非同期ストリームを用いることが考えられる。しかしながら、同時に２つ以上の装置が同じＩＰマルチキャストに加入しようという場合は、これら２つ以上の装置が独立に別個のチャネルを確保してしまう可能性があり、通信資源の有効利用が図れない。また、確保したチャネルと、ＩＰマルチキャストアドレスとの対応関係を送信側、受信側で同期して認識するための機構が無い。
【００１０】
そこで、本発明は、上記問題点に鑑みてなされたものであり、ＲＳＶＰのＩＥＥＥ１３９４バス上での適用方法を示し、ＩＥＥＥ１３９４上でも、相互接続環境での通信品質を確保した通信が可能となる通信装置を提供することを目的とする。
【００１１】
また、本発明は、ＩＥＥＥ１３９４等の放送型ネットワークにおいて、通信資源を有効に利用してＩＰマルチキャストを行うことができ、また、確保したチャネルとＩＰマルチキャストアドレスとの対応関係を送信側、受信側で同期して認識することのできる通信装置を提供することを目的とする。
【００１２】
【課題を解決するための手段】
上記問題を解決するために、本発明の通信装置は、放送型のネットワークに接続され、ネットワークレイヤマルチキャストアドレス宛てのデータを送信する通信装置であって、前記ネットワーク上に確立されている放送型チャネルに対する通信帯域を確保する確保手段と、前記放送型チャネルに帯域が確保されていない場合に、前記ネットワークレイヤマルチキャストアドレス宛てのデータを前記放送型チャネルの帯域が確保されていない周期あるいはコネクションで送信する第１の送信手段と、前記確保手段により前記放送型チャネルに帯域が確保された場合に、前記ネットワークレイヤマルチキャストアドレス宛てのデータを前記放送型チャネルの帯域が確保されていない周期あるいはコネクションから、前記放送型チャネルの帯域が確保された周期あるいはコネクションに切り替えて送信する第２の送信手段とを具備したことにより、ネットワークレイヤマルチキャストパケットを帯域を確保されていない形での伝送から、確保された形での伝送に切り替える場合に、これまでのように、再度放送型チャネルと帯域の確保の両方を資源確保を行っているマネージャ（例えばＩＥＥＥ１３９４における同期リソースマネージャ）に要求する必要がなくなる。即ち、単に既に通信資源として持っている放送型チャネル向けのパケットを第１の送信手段に送り込むのみでこれが可能となる。逆の切り替え（帯域確保から非確保への切り替え）も同様である。
【００２２】
さらに本発明の通信装置では、前記確保手段で帯域が確保された場合の前記第1 の送信手段から出力される放送型チャネルの識別子は、帯域が確保されていない場合の前記第2 の送信手段から出力される放送型チャネルの識別子と同一の識別子であることにより、放送型チャネルの浪費を防ぐことが可能となる。特に、IEEE13 94 の様なチャネル資源が比較的少ない様なデータリンクに関しては、帯域確保の形で流すネットワークレイヤマルチキャストパケットと、帯域確保無しで流すマルチキャストパケットとを同一のチャネルで共有することができるようになり、これも通信資源の有効活用につながる。
【００２３】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態について説明する。なお、以下の説明では、一例として家庭内に構築されたネットワーク（家庭内ネットワーク）を対象として説明するが、これに限るものではなく、例えば、ホテル等の建物、敷地内といった限られた範囲に構築されるネットワークにおいても適用できる。
【００２４】
（第１の実施形態）
図１は、本発明の第１の実施形態に係るネットワーク全体の構成例を示したもので、映像サービスを提供しているビデオサーバからのデータを、公衆網を介して家庭内ネットワークにとりこみ、家庭内ネットワークに接続された端末で、該サービスを受ける状況を説明する図となっている。
【００２５】
図１に示すように、全体の構成は、ビデオサーバ１０１、公衆網１０４、接続装置１０２、例えば家庭内に構築された第１のネットワーク１０５、第２のネットワーク１０６、第１のネットワークに接続された端末１０３からなる。
【００２６】
なお、図１では第１のネットワーク１０５に端末１０３が１つ接続されているのみであるが、実際には両ネットワーク１０５、１０６に、他の種々の端末、あるいは網間接続装置等が接続されていても良い。
【００２７】
公衆網は、例えばＣＡＴＶ網、あるいはＩＳＤＮ／Ｂ−ＩＳＤＮ網、ＡＴＭ−ＰＯＮ網、高速無線アクセス網、ＡＤＳＬ／ＨＤＳＬ網等、色々な場合が考えられる。ただし、本実施形態のビデオサービスはＭＰＥＧ映像をインターネットを介して提供されるものとする（ＭＰＥＧｏｖｅｒＩＰ）。よって、本サービスが提供されるインタフェースはデジタルインタフェースを仮定する。
【００２８】
本実施形態においては、該デジタルネットワークはデータリンク方式として、ＡＴＭ方式を採用しているものとして、以後の説明を進めていくが、本発明の方式はＡＴＭ方式に限定されるものではない。例えば、以後の説明のＡＴＭのＶＰＩ／ＶＣＩ等のデータリンクレイヤ識別子は、ＩＳＤＮであればＢチャネル識別子、ＣＡＴＶであれば周波数に対応するものである。このように、本実施形態のＡＴＭにおけるＶＰＩ／ＶＣＩをこれら他のデータリンクレイヤ識別子に置き換えたものも、本発明に含まれるものである。
【００２９】
ビデオサーバ１０１は、専用のビデオサーバでも良いし、例えば映像対応ＷＷＷサーバ等、映像信号を送出できるサーバであれば良い。ここで、「映像信号を送出できる」とは、リアルタイム伝送を行う事は必ずしも意味しない。例えば、映像データを、リアルタイム配信ではなく、ベストエフォートにて配信する場合がこれにあたる。
【００３０】
公衆網１０４と家庭内に構築されたネットワークの間は、専用の接続装置１０２にて接続されている。
接続装置１０２には、この場合、公衆網１０４の終端機能、家庭内のネットワーク１０５、１０６の終端機能、ＩＰ処理機能、ＲＦＣ１６３１にて標準化されているＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）機能の他に、ＩＰマルチキャスト対応機能、ＩＰシグナリング機能、公衆網と家庭内のネットワーク間でリアルタイムデータ転送可能なデータリンクレイヤレベルのスイッチ、アドレス通知機能等が実装されている。詳細は後述する。
【００３１】
次に、図１に示したネットワーク上のＩＰのサブネット構成とアドレス割当について説明する。図１に示すように、第１の実施形態において、家庭内のネットワーク全体（第１および第２のネットワーク１０５、１０６）にて１つのＩＰサブネット( ネットワークアドレスＰ）が構成されており、更に家庭内ネットワークは、ＲＦＣ１５９７にて標準化されているプライベートアドレスを利用している。
【００３２】
また、接続装置１０２の公衆網側には、グローバルなＩＰアドレス（Ｇ．２）が割り当てられている。
このようなアドレス構成となっている理由は、例えば複数のグローバルなＩＰアドレスの取得には、１つのグローバルＩＰアドレス取得と比べてコストがかかる、あるいは世界的なＩＰアドレスの枯渇のためである。即ち、端末数、アドレス数の急成長が見込まれる家庭内ネットワークへの接続端末にはグローバルなＩＰアドレスの新規の割当は実質的にはほとんど不可能、等の理由によるものである。
【００３３】
なお、第１のネットワーク１０５、第２のネットワーク１０６は、それぞれ別のプライベートアドレス内という限定の上で、別々のサブネットとなっていてもよい。この場合は、両者の間にはいる接続装置１０２はルータとなる。
【００３４】
本実施形態においては、第１および第２のネットワーク１０５、１０６は同一のサブネットに属するものとして、以降の説明を行う。
次に、図１の端末１０３が接続装置１０２、公衆網１０４を通してビデオサーバからビデオを転送してもらうまでの処理手順について、図２を参照して説明する。また、その際の端末１０３の処理手順および接続装置１０２の処理手順を、それぞれ図３、図４に示す。
【００３５】
図２、図３、図４は、後に示すように、接続装置１０２がＳＢＭ（Ｓｕｂｎｅｔ Ｂａｎｄｗｉｄｔｈ Ｍａｎａｇｅｒ）であるような場合に、この機構を用いて通信資源の確保を使った場合のシーケンスを記述したものである。
【００３６】
ＳＢＭとは、ＩＥＴＦのＩｎｔＳｅｒｖワーキンググループで議論されているもので、サブネット内の通信資源確保をＲＳＶＰを用いて行うものである。
まず、端末１０３は、ＯＳＩの標準化された７レイヤのうちのレイヤ５以上のプロトコルを用いて、見たいビデオについての情報の入手を行う（ステップＳ２０１、Ｓ２０３）。これは、ＭＰＥＧ／ＤＡＶＩＣのＤＳＭ−ＣＣや、それに準じたプロトコルを用いたネゴシエーションや、ＲＴＳＰ等を用いてＷＷＷサーバからの情報の選択をＷｅｂ上で行う事による情報の選択など、色々な場合が考えられる。以降では、これを「上位レイヤプロトコル」として、まとめて表現する。
【００３７】
本実施形態では、これらの情報の交換は、ＩＰパケットを使って行われるものとする。
ちなみに、この上位レイヤプロトコルは、接続装置１０２にてＮＡＴの処理を受けながら通信されていても良い（ステップＳ２０２）。
【００３８】
ＮＡＴ処理とは、プライベートＩＰ網からインターネットにＩＰパケットをフォワーディングするに際し、プライベートＩＰアドレスをインターネット側に送出するのは許されないため、接続装置１０２にて、プライベートＩＰアドレスを自身のグローバルＩＰアドレス( ここでは「Ｇ．２」）に変換して送出する方式を言う。
【００３９】
ＮＡＴ処理の詳細については、例えば本発明者らによる特願平第８−３１６５５２号を参照されたい。
本実施形態においては、ビデオサーバからの映像サービスは、ＩＰマルチキャストを通じて提供されるものとする。そこで、前記上位レイヤプロトコルを用いて選択するビデオが決定した場合、そのビデオを転送するためのＩＰマルチキャストアドレスを取得する必要がある。
【００４０】
その放送形態( 配信形態) にはいくつかの形態が考えられる。
（Ａ） まず、ビデオ毎( コンテンツ毎) に、別々のＩＰマルチキャストアドレスが割り当てられている場合から説明する。
【００４１】
これは、例えばＡ放送局からの放送はＩＰマルチキャストアドレス＝「＃１」、Ｂ放送局からの放送は「＃６」等と、ＩＰマルチキャストアドレスが割当てられている場合である。
【００４２】
上位レイヤプロトコルを通して、ビデオサーバ１０１は、端末１０３にそのビデオを転送するためのマルチキャストアドレス「Ｍ」を通知する。すると、端末１０３は、ＩＰマルチキャストのプロトコル（例えばＩＧＭＰ（ＲＦＣ１１１２））に従い、インターネット側から受け取るＱＵＥＲＹメッセージに対し、加入したいマルチキャストアドレス「Ｍ」についてのＲＥＰＯＲＴメッセージを送出する（ステップＳ２０４）。
【００４３】
これを受信した接続装置１０２は、端末１０３のプライベートアドレス「Ｐ．２」と、要求されたマルチキャストアドレス「Ｍ」との対応関係を記憶した後（ステップＳ２０５）、ＲＥＰＯＲＴメッセージを上流のルータに通知する（ステップＳ２０６）。その際、送信者アドレスを自身（接続装置１０２）のグローバルＩＰアドレス「Ｇ．２」としておく。
【００４４】
接続装置１０２に記憶される対応テーブルの一例を図５に示す。
マルチキャストアドレス「Ｍ」への加入が成功すると、接続装置１０２は、端末１０３がマルチキャストアドレス「Ｍ」に加入した旨を記憶し（ステップＳ２０５）、これを端末１０３に通知する。
【００４５】
次に、端末１０３は、このビデオ映像を良い品質で受信するための通信資源の予約を行う。このための方法として、いくつかの方法が考えられる。
（ａ） ＳＢＭを用いる方法
ＳＢＭ（Ｓｕｂｎｅｔ Ｂａｎｄｗｉｄｔｈ Ｍａｎａｇｅｒ）とは、インターネットの標準化機関であるＩＥＴＦで提案されているサブネット内の帯域予約のための方式であり、サブネット内の帯域予約をＲＳＶＰを使って行うものである。
【００４６】
（ｂ） ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いる方法
（ｃ） ＩＥＣ１８８３を用いる方法
以下、順に説明する。
【００４７】
（ａ）ＳＢＭを用いる方法
まず、ＳＢＭを用いる場合について、図２に示すシーケンスを参照して説明する。
【００４８】
接続装置１０２は、ＳＢＭノードであることから、ルーチングプロトコルは稼動していない。
本実施形態の接続装置は、ＮＡＴ機能を持っているため、グローバルＩＰアドレス（Ｇ．２）を有しているが、家庭内ネットワーク側に複数の物理インタフェースがあるとしても、物理インタフェース毎にＩＰアドレス( プライベートアドレス) を持つ必要はない。例えば、接続装置１０２は、グローバルＩＰアドレスの他、プライベートアドレスを１つ持てば充分である。ここでは、接続装置１０２はプライベートＩＰアドレス「Ｐ．１」を持っている。
【００４９】
端末１０３は、上位レイヤプロトコル等でＲＳＶＰのＰＡＴＨメッセージの送出をビデオサーバ１０１に促しても良い。ＰＡＴＨメッセージはマルチキャストアドレス「Ｍ」宛てに送出され、接続装置１０２に届く（ステップＳ２０７）。
【００５０】
接続装置１０２では、ＲＳＶＰのＰＡＴＨステートを作成し（ステップＳ２０８）、その後、ＰＡＴＨメッセージをマルチキャストアドレス「Ｍ」宛に送出し、結局、端末１０３に到着する（ステップＳ２０９）。その際、接続装置１０２は端末１０３がマルチキャストアドレス「Ｍ」に属している事を、図５の対応テーブルにより認識しているので、該ＰＡＴＨメッセージを端末１０３にフォワードする事が出来る。
【００５１】
接続装置１０２内には、ＰＡＴＨステートが出来る。ここで、接続装置１０２はＳＢＭノードである。端末１０３は、帯域等の通信資源を予約すべく、ＲＳＶＰのＲＥＳＶメッセージを上流の接続装置１０２に送出する（ステップＳ２１０）。
【００５２】
ＲＥＳＶメッセージを受信した接続装置１０２は、接続装置１０２と端末１０３間の通信資源を確保すべく、第１のネットワーク（ＩＥＥＥ１３９４）１０５のＩＥＥＥ１３９４同期リソースマネージャにアクセスして、必要な帯域と同期チャネル番号を確保する（ステップＳ２１１）。ここで、確保された同期チャネルの番号を「＃ｘ」とする。
【００５３】
この時点で、接続装置１０２は、端末１０３に「どの同期チャネルを用いて、リクエストされた番組を送出するのか」を端末１０３に通知しても良い（ステップＳ２１２）。
【００５４】
この通知方法としては、例えば、図６に示したようなフォーマットのＲＳＶＰのＰＡＴＨメッセージを用いる方法がある。すなわち、図６に示すように、ＲＳＶＰのＰＡＴＨメッセージ内に、「今後（あるいは今）、このＰＡＴＨメッセージに含まれるデータ（ＩＰフロー）は、同期チャネル番号＝「＃ｘ」にて伝送する」といった旨の情報が記述される。
【００５５】
第２の通知方法は、発明者らが特願平第８−２６４４９６号に記載したＦＡＮＰ（Ｆｌｏｗ Ａｔｔｒｉｂｕｔｅ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いる方法である。
【００５６】
ＦＡＮＰは、隣接ノード間（本実施形態の場合、接続装置１０２と端末１０３間）にて、送信するＩＰフロー等（本実施形態の場合、例えばＩＰマルチキャストアドレス「Ｍ」）と、リンクレイヤのＩＤ情報（本実施形態の場合、先に確保したＩＥＥＥ１３９４のチャネル番号）との対応関係を通知しあうものである。
【００５７】
第３の通知方法は、ＩＥＣ１８８３のＣＩＰヘッダを用いる方法である。ＩＥＣ１８８３を用いて、接続装置１０２が直接端末１０３のＰＣＲ（Ｐｌｕｇ Ｃｏｎｔｒｏｌ Ｒｅｇｉｓｔｅｒ）に使用するチャネル番号を書き込み、１３９４のヘッダなり、ＩＥＣ１８８３にて定められたＣＩＰ（Ｃｏｍｍｏｎ Ｉｓｏｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔ）ヘッダなりで端末１０３に、送信している情報がＭＰＥＧｏｖｅｒＩＰであることを認識させる。例えば、ＣＩＰヘッダを拡張する場合は、そのパケットがＩＰパケットである旨、あるいはＭＰＥＧｏｖｅｒＩＰである旨を示す値をＦＭＰ（フォーマットＩＤ）領域に書き込むことにより、端末１０３はＣＩＰヘッダを見ることにより、そのパケットの属性がＩＰパケット、あるいはＭＰＥＧが載ったＩＰパケットであることが認識できるようになる。
【００５８】
第４の通知方法は、図７に示すように、ＰＣＲを拡張して、ＰＣＲレジスタの意味の一部を、そのチャネル番号に伝送する内容を意味するものとする。例えば、ＩＰパケットあるいはＭＰＥＧｏｖｅｒＩＰのパケットである。また、そのチャネル番号を伝送されるフローの属性を記述しても良い。例えば、送信ＩＰアドレス／受信ＩＰアドレス／送信ポート番号／受信ポート番号の組み合わせなどである。このようなレジスタを端末１０３に用意し、接続装置１０２( あるいはコントローラ) がこのレジスタに適切に記述することにより、端末１０３が、そのチャネル番号を通して受信するデータがＩＰパケット、あるいはＭＰＥＧｏｖｅｒＩＰのパケットであること、あるいは、その属性を認識できるようになる。
【００５９】
無論、上記第１〜第４の通知方法の適宜組み合わせて用いることもできる。
なお、タイミング的には、ここで説明したタイミング以外にも、ビデオサーバ１０１まで通信資源の予約が完了し、エンド- エンドの通信が可能になった段階で上記の手続きを行う形も考えられる。
【００６０】
さて、下流側の通信資源の確保に成功した接続装置１０２は、ＲＳＶＰのＲＥＳＶメッセージを更に上流へと流す（ステップＳ２１３）。
これを受けとったインターネット内のルータは例えば、Ｑ．２９３１等を使って下流側のＡＴＭ網の通信資源を確保し（ステップＳ２１４）、それを確認した後、更に上流へとＲＥＳＶメッセージの送出、といったことを繰り返す。
【００６１】
更に、ＰＡＴＨあるいはＦＡＮＰを用いて下流方向のＲＳＶＰ／ＳＢＭノードに対して、使用するデータリンク識別子（この場合、データリンク技術がＡＴＭであるため、ＶＰＩ／ＶＣＩ）についての情報を送出し、該ＲＳＶＰ／ＳＢＭノードに、送出ＩＰフローとデータリンク識別子との対応関係の通知を行う（ステップＳ２１５）。ここで、接続装置１０２に対して確保されたＡＴＭのＶＣＩの値「＃ｙ」とする。
【００６２】
こうして、エンドエンドの通信資源が確保されたなら、ビデオ転送を開始する（ステップＳ２１６、Ｓ２１７）。
ここで、接続装置１０２では、ビデオサーバ１０１からＡＴＭコネクション「＃ｙ（ＶＣＩ値＝「＃ｙ」）」にてＭＰＥＧｏｖｅｒＩＰのデータが伝送されてくることを認識しており、また端末１０３に対してＩＥＥＥ１３９４の同期チャネル「＃ｘ」にて受信したＩＰパケットを送出すればよいことを認識している。
【００６３】
そこで、接続装置１０２では、ＶＣＩ「＃ｙ」を通して受信したデータを、ＩＰパケットのヘッダの中身まで検証することなく、直接ＩＥＥＥ１３９４の同期チャネル「＃ｘ」に対して、ＩＰパケットの同期をとった上で伝送する。即ち、ＶＣＩ値のみの検証により、ＩＰレイヤの処理をすることなく、直接１３９４へのデータ転送を行うことができる。これは、データリンクレイヤの情報のみで、データのスイッチングを行っていることから、データリンクスイッチと見ることができる。
【００６４】
このことにより、本来ＩＰレイヤで行うべき、ＩＰレイヤ処理、即ちＩＰヘッダの検証やルーチング処理等の一連のソフトウエア処理を、データリンクレイヤスイッチング処理にて置き換えることが可能になり、処理時間、及び処理負荷の大幅な低減を図ることが可能になる。これは、ＳＢＭを行った上で、データリンクスイッチを行っていることに相当する。
【００６５】
なお、以上の説明では、接続装置１０２はＳＢＭノードとして説明を行ってきたが、接続装置１０２がルータであり、ＲＳＶＰを利用した通信資源の確保を行ってももちろんよい。
【００６６】
また、通信資源の予約を行う際に、本発明の発明者らによる特願平第８−２６４４９６号に記載されている方法、すなわち、ＦＡＮＰにより通信資源の予約を行うようにしてもよい。
【００６７】
以上は、ＩＥＥＥ１３９４上の通信資源予約をＲＳＶＰの上流のノードが行う場合についての説明であった。これに対し、図８に示すように、ＩＥＥＥ１３９４バス上の同期チャネルの確保を、下流側のノード（本実施形態の場合、端末１０３）が行ってもよい。
【００６８】
下流側のノードが必要な通信資源を持った同期チャネルの確保を行った後（ステップＳ２１１０）、上流側にＲＥＳＶメッセージの送出を行う（ステップＳ２１１１）。この場合、確保した同期チャネルの番号等は、続けて送出するＲＳＶＰのＲＥＳＶメッセージに含めて送出しても良い。
【００６９】
また、上流側に同期チャネル番号と帯域確保を行うフローの対応の通知をRESVメッセージとは別のメッセージで行ってもよい。この場合は、RESVメッセージは単に接続装置に対して、該フローの帯域確保の要求をするために用いられ、同期チャネル番号と帯域確保を行うフローの対応関係は、別メッセージ( 本図ではFANPメッセージ) にて行われてもよい。この通知を受けた接続装置は、RESVメッセージで帯域予約を受けたフローについて、どのリンクレイヤコネクション、つまり同期チャネルにて転送すればよいのかについての情報を、このメッセージから得ることができる。
【００７０】
さて、端末１０３のユーザが、異なるビデオ映像( 例えば、違うチャネルのテレビ番組) を見たいと考えた場合、上記同様の手続きをもう一度踏む事になる。即ち、その新しいビデオ映像に対応するＩＰマルチキャストアドレスを上位プロトコルなどを通じて入手し、該ＩＰマルチキャストアドレスへの加入という手続きを再度踏むことで、これを実現する。その際は、先に加入していたＩＰマルチキャストアドレスは離脱することが、通信資源の有効活用の観点から望ましい。この様子を図９に示している。
【００７１】
また、家庭内に構築されたネットワークには端末が複数接続され、その各々が別々の放送を見ている場合は、その各々のデータが公衆網１０４および接続装置１０２を通ることになる。接続装置１０２において、データリンクスイッチを行うため、別々のＡＴＭ−ＶＣにて別々の端末宛てのこれらのデータが伝送されてくることが望ましい。通信資源の確保については、再度上記のようなＳＢＭ／ＲＳＶＰ／ＦＡＮＰ等を使った手続きが必要あるかどうかは、ＲＳＶＰ／ＳＢＭの予約の仕方による。即ち、Ｓｈａｒｅｄ Ｅｘｐｌｉｃｉｔの予約であれば、送信者のビデオサーバが同一である限り、あるいはＳｈａｒｅｄ Ｅｘｐｌｉｃｉｔのサーバのアドレスとして、次にビデオを送出する新しいビデオサーバが登録されていれば、先に予約したのと同一の通信資源（ＡＴＭのＶＣ、１３９４の同期チャネル）をそのまま利用し続ければよく、ＩＰマルチキャストの再加入を行うのみで良い。
【００７２】
（Ｂ） 次に、ＩＰマルチキャストアドレスは同じで、コンテンツが変わる場合を説明する。この場合は、同一のマルチキャストアドレスを用いて、同一のユーザに対して複数の映像サービスを行う形式となり、上位プロトコルを用いて映像コンテンツの変更（テレビのチャネルの変更に相当）を行う形となる。
【００７３】
このときも、最初の通信資源の確保までは同じ手順を踏む。ただし、上位レイヤプロトコルを通して与えられるＩＰマルチキャストアドレスは、あらかじめその端末に固有に与えられた（あらかじめ、ネットワークサービスプロバイダが、ユーザ毎、あるいは端末毎に割当てておいた）ＩＰマルチキャストアドレスであってもよい。端末の識別は、例えばネットワークサービスプロバイダがあらかじめ端末毎に与えておいた識別子を用いて、上位レイヤプロトコルを使って行う等の方法が考えられる。
【００７４】
次のコンテンツの変更（テレビのチャネルの変更に相当）の際に、端末は上位レイヤプロトコルを用いて、このコンテンツ変更を要求する。ビデオサーバ１０１は、使用しているＩＰマルチキャストアドレスを変更することなく、そのまま用い、変更したコンテンツを、該ＩＰマルチキャストアドレス宛に送出する。
【００７５】
前述の様に、このＩＰマルチキャストアドレスは、図１０に示すように、必ずしもマルチキャストに用いる必要は無く、単一の端末に対するコンテンツ転送に用いても良い。即ち、一つ一つのマルチキャストアドレスを、ビデオ配信の要求のあったユーザ( 端末) に割当て、送出コンテンツの変更は、例えば上位レイヤプロトコルにて対応する。
【００７６】
また、接続装置１０２から送信されるＩＰパケットのポート番号の違いを見て、別々のマルチキャストアドレスを割当てる判断のトリガとしてもよい。
このように、ユーザ毎、あるいはアプリケーション毎に別々のＩＰマルチキャストアドレスを与えるようにすることにより、ＩＰマルチキャストアドレスは端末に対して動的な割当てが可能であることから、プライベートアドレス環境においても、グローバルユニークなＩＰアドレスとの重複を心配すること無く、種々のコンテンツをプライベートアドレスを持った端末に送信することが可能となる。
【００７７】
なお、本実施例においてはIPマルチキャストのデータフローの転送をRSV P を使って帯域予約する場合を記述してきたが、全く同様の方法をIPユニキャスト、あるいは他のネットワークレイヤのユニキャスト、あるいはマルチキャストについて適用できることは明らかである。
【００７８】
（第２の実施形態）
図１１は、本発明の第２の実施形態に係るネットワークの構成例を示したもので、ＩＥＥＥ１３９４バス上にＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）ルータ２１０１、ＩＥＥＥ１３９４の同期リソースマネージャ２１０４、端末２１０２、２１０３が互いに通信可能なように接続されて構成されている。
【００７９】
（２−１）
このような構成のネットワークにおいて、端末２１０２、２１０３がＩＰマルチキャストへ加入して、マルチキャストデータを受信する場合について説明する。ここで、端末２１０２、２１０３は、ＩＰマルチキャストへ加入した後は、マルチキャストデータの受信端末となることから、以下、受信端末２１０２、２１０３と呼ぶ。
【００８０】
受信端末２１０２、２１０３がＩＰマルチキャストに加入する場合の手順について、図１２を参照して説明する。また、その際のＩＧＭＰルータ２１０１の処理手順を図１３に示す。
【００８１】
図１１に示したように、ＩＥＥＥ１３９４バス上には、ＩＧＭＰルータ２１０１、受信端末２１０２、２１０３、同期リソースマネージャ２１０４が接続されている。受信端末２１０２のＩＰアドレスは「ＩＰ１」、受信端末２１０３のＩＰアドレスは「ＩＰ２」であるとする。また、同期リソースマネージャ２１０４の機能は、他の３つの装置のうちのいずれかと一体となっていてもよい（即ち、ＩＧＭＰルータ２１０１あるいは受信端末２１０２、２１０３のうちのいずれかが同期リソースマネージャであってもよい）。
【００８２】
受信端末２１０２、２１０３は、予め何らかの手段にてＩＰマルチキャストアドレス「ＩＰｍ」を取得しているものとする。
まず、受信端末２１０２がＩＰマルチキャストアドレス「ＩＰｍ」に加入を希望しているとする。そのため、ＩＧＭＰルータ２１０１と、受信端末２１０２との間で、ＩＧＭＰメッセージのやり取り（ＩＧＭＰクエリーやＩＧＭＰレポート等の送受信）が行なわれ、受信端末２１０２がＩＧＭＰルータ２１０１に対して、ＩＰマルチキャストアドレス「ＩＰｍ」に対して加入を希望している旨を伝える（Ｓ２１０１）。ここで、ＩＧＭＰルータ２１０１は、このＩＰマルチキャストアドレス「ＩＰｍ」のサポートを行なうことのできるルータであるとする。
【００８３】
ＩＧＭＰルータ２１０１は、セットトップボックスのようなものでもよい。即ち、放送波を通じて送られてくるＩＰマルチキャストパケットの中から、適当なＩＰマルチキャストアドレス宛のパケットを抽出し、これをフォワードする機能を持ったノードであってもよい。
【００８４】
ＩＧＭＰルータ２１０１は、受信端末２１０２からＩＰマルチキャストドレス「ＩＰｍ」への加入要求を受信すると、図１３のフローチャートに従った処理を実行する。すなわち、本実施形態の場合、受信端末２１０２からの加入要求が、そのサブネット（ＩＥＥＥ１３９４バス）からのＩＰマルチキャストアドレス「ＩＰｍ」への最初の加入要求であるため、ＩＧＭＰルータ２１０１は、所定のＩＰマルチキャストアドレスへの加入手続き処理を行い（ステップＳ２２０１〜ステップＳ２２０３）、その手続き処理が成功したら、次に、同期リソースマネージャ２１０４にアクセスし、同期チャネル番号を確保する（ステップＳ２２０４〜ステップＳ２２０５、図１２のステップＳ２１０２）。なお、図１３のステップＳ２２０３において、ＩＧＭＰルータ２１０１は、さらに上流のＩＧＭＰルータに働きかけ、このＩＰマルチキャストアドレスへの加入手続きを行なってもよい。また、加入手続き処理が失敗した場合は、その旨を受信端末２１０２に通知する（図１３のステップＳ２２０６）。
【００８５】
図１３のステップＳ２２０５において、ＩＧＭＰルータ２１０１からの要求に応じて同期リソースマネージャ２１０４にて確保された同期チャネル番号を「＃ｘ」とする。ここで、同時に帯域を確保する必要は必ずしもない。これは、この時点で確保されるのはＩＥＥＥ１３９４の非同期ストリームであるからである。
【００８６】
非同期ストリームとは、非同期パケットのアービトレーション時間に送信される、同期パケットのフォーマットのパケットであり、同期リソースマネージャ２１０４を通じて同期チャネル番号のみが確保される。
【００８７】
帯域を確保することが必要な場合については後述する。
図１３の説明に戻り、ＩＧＭＰルータ２１０１は、同期チャネル番号が確保されると、次に、自らのレイヤ３フローレジスタに、このＩＰマルチキャストフローについての情報を記入する（ステップＳ２２０６、図１２のステップＳ２１０３）。
【００８８】
図１４は、レイヤ３フローレジスタのフォーマットの一例を示したもので、レイヤ３フローレジスタは、基本的にレイヤ２識別子（本実施形態の場合、同期チャネル番号）と、そのレイヤ２識別子であらわされるチャネルを通ることになるレイヤ３フローについての対応関係を登録するためのレジスタである。このレジスタには、その他に、そのフローが入力されるものであるのか、出力されるものであるのかについての情報、そのレイヤ２識別子であらわされるチャネルに確保された帯域量、そのチャネルを使用している端末をカウントするカウンタ等の領域が用意されている。
【００８９】
図１４に示すように、ここでは、確保されたチャネルには帯域が確保されないので、レイヤ３フローレジスタの帯域の項目欄には、例えば「０」が記入されている。
【００９０】
このチャネルに対して宛先がＩＰマルチキャストアドレスが「ＩＰｍ」であるＩＰフローが流れ込むことになるため、フロー識別子として、受信側ＩＰアドレスには「ＩＰｍ」を、受信側ポート番号には、番号が限定されている時はその番号（例えばＰＯＲＴ１）を、限定されていない時は例えば「０」を記入する。本実施形態では、特に限定が無いため「０」を記入する。ＩＰマルチキャストアドレスは、送信端末は限定されないため、送信端末や送信ポート番号にはそれぞれ「０」が記入される。
【００９１】
レイヤ２識別子としては、ここではレイヤ２種別として「ＩＥＥＥ１３９４」、識別子種別として「同期チャネル番号」が記入され、識別子としては、先に確保された同期チャネル番号である「＃ｘ」が記入される。
【００９２】
方向としては、基本的にこのＩＧＭＰルータがこれらのＩＰマルチキャストパケットを送信するものとして「順方向」とする。
コネクションカウンタは、この非同期ストリームを受信していると考えられるノードの数を表すカウンタである。受信者はこの時点で受信端末２１０２のみであると考えられるので、カウンタ値「１」が入力される。
【００９３】
なお、このレイヤ３フローレジスタは、ＩＥＣ１８８３にて使用されるプラグコントロールレジスタおよびそのチャネルで転送されるレイヤ３フローについての情報を格納するレジスタの組み合わせの形で実現しても良い。
【００９４】
次に、ＩＧＭＰルータ２１０１は、受信端末２１０２のレイヤ３フローレジスタに対して、図１４と同様の情報を書き込む（ステップＳ２２０７、図１２のステップＳ２１０４）。
【００９５】
このようにして、レイヤ３フロー情報と、レイヤ２識別子との対応関係が、受信端末２１０２のレイヤ３フローレジスタに書き込まれることで、受信端末２１０２は、今後、非同期ストリームのチャネル番号「＃ｘ」は、ＩＰマルチキャストアドレス「ＩＰｍ」宛のＩＰマルチキャスト用に割り当てられたことが認識できる。受信端末２１０２は、ＩＰマルチキャストアドレス「ＩＰｍ」宛のデータグラムについては、チャネル番号「＃ｘ」の非同期ストリームを受信すれば良い（ステップＳ２１０５）。
【００９６】
なお、上記実施形態では、受信端末２１０２のレイヤ３フローレジスタ内に、そのチャネル番号で示される非同期ストリームあるいは同期チャネルから流れてくるＩＰフローが、入力されてくるのか、出力するものなのかについての情報が書かれているが、レイヤ３フローレジスタを入力用と出力用とを分けて用意しておき、これらを適当に使い分けることも可能である。
【００９７】
さて、図１２の説明に戻り、受信端末２１０３が続いて同じＩＰマルチキャストアドレス「ＩＰｍ」に加入を希望しているものとする。ＩＧＭＰによる加入手続きがＩＧＭＰルータ２１０１と受信端末２１０３の間で行われる（Ｓ２１０６）。
【００９８】
そして、ＩＧＭＰルータ２１０１では、図１３のフローチャートに示したような処理動作を実行する。すなわち、ＩＧＭＰルータ２１０１は、すでにこのＩＰマルチキャストアドレス「ＩＰｍ」についてのサービスを開始しているため、自らのレイヤ３フローレジスタのコネクションカウンタをインクリメントし（例えば、コネクションカウンタの値を「２」とする）、さらに受信端末２１０３のレイヤ３フローレジスタに、受信端末２１０２の同レジスタと同じ情報を書き込んで、チャネル番号とＩＰフローの対応関係を通知する。
【００９９】
なお、ＩＰマルチキャストアドレス「ＩＰｍ」に加入している端末数は、ＩＧＭＰルータ２１０１が把握しており、各端末が把握する必要は必ずしもないため、各受信端末２１０２、２１０３の同レジスタに書き込まれるコネクションカウンタの値は、例えば「１」でも良い。
【０１００】
以上はＩＰマルチキャストアドレスへの加入手続きについての説明であったが、次に、脱退の時のＩＧＭＰルータ２１０１の動作について、図１５に示すフローチャートを参照して説明する。
【０１０１】
脱退の場合、ＩＧＰＭルータ２１０１は、受信端末のいずれかかからＩＰマルチキャストアドレス「ＩＰｍ」への脱退手続きを受信した場合（ステップＳ２３０１）、あるいは、受信端末のいずれかからのＩＰマルチキャストアドレス「ＩＰｍ」を受信し続けているとのキープアライブ信号であるＩＧＭＰ ＲＥＰＯＲＴを一定時間以上受信しなかった場合（ステップＳ２３０２）、当該受信端末が上記ＩＰマルチキャストアドレス「ＩＰｍ」の受信を止めるものと判断し、自らのレイヤ３フローレジスタのコネクションカウントの値をデクリメントする（ステップＳ２３０３）。
【０１０２】
ＩＧＭＰルータ２１０１のレイヤ３フローレジスタに書き込まれるコネクションカウントの値は、そのＩＥＥＥ１３９４バス上における、ＩＰマルチキャストアドレス「ＩＰｍ」に加入している端末の数であるため、この値が「０」になったとき（ステップＳ２３０４）、そのＩＥＥＥ１３９４バス上にＩＰマルチキャストアドレス「ＩＰｍ」を受信している端末はもはやなくなったものと判断し、そのＩＰマルチキャストアドレス「ＩＰｍ」から脱退する（ステップＳ２３０５）。
【０１０３】
これと前後して、脱退した受信端末に脱退した旨を伝えるため、その受信端末のレイヤ３フローレジスタに、例えばオール「０」の値を書き込むなどの動作を行なってもよい。
【０１０４】
なお、このＩＰマルチキャストアドレス加入、あるいは加入後の一連の過程でＩＥＥＥ１３９４バスでバスリセットが引き起こされた場合においても、これらのＩＰマルチキャストアドレスについての情報を保持しつづけ、レジスタ（レイヤ３フローレジスタ）の値も保持しておくことで、迅速なＩＰマルチキャストデータグラム受信の復帰を行なうことが可能である。
【０１０５】
繰り返しになるが、ＩＰマルチキャストアドレス「ＩＰｍ」宛ての全てのパケットは、チャネル番号「＃ｘ」にて表される非同期ストリームを通じて送受信されるものとなる。なお、ＩＧＭＰ等の制御パケットについては、当該マルチキャストアドレスに対応する非同期ストリームを使用しても良いし、またはデフォルトの非同期ストリーム（ＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）やＩＰブロードキャスト等のために割当てられた非同期ストリームのチャネルや非同期のブロードキャストを用いて、これを通信しても良い。
【０１０６】
また、ＩＰマルチキャスト加入時にＩＧＭＰの制御パケットや、ＩＰアドレス＝「２２４．０．０．１」等の全ホストが宛先アドレスのＩＰパケット等が流れるチャネルとしては、デフォルトの非同期ストリーム、もしくは非同期ライトのブロードキャストのいずれかを使用する。
【０１０７】
（２−２）
次に、ＩＰマルチキャストを「帯域（ＱＯＳ）あり」の状態に変更する場合、すなわち、非同期ストリームに対して帯域を与え、これを送受信する場合について図１６のシーケンス図を参照して説明する。
【０１０８】
受信端末２１０２が、ＩＰマルチキャストアドレス「ＩＰｍ」宛のデータグラムを受信できるようになるまで（ステップＳ２５０１〜ステップＳ２５０４）は、図１２のステップＳ２１０１〜ステップＳ２１０５と同様である。
【０１０９】
このＩＰマルチキャストについて、帯域ありの伝送が可能である場合、ＩＧＭＰルータ２１０１は、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｓｅｔｕｐ Ｐｒｏｔｏｃｏｌ）のＰＡＴＨメッセージを受信端末（ＩＰマルチキャストアドレス「ＩＰｍ」）に対して送付する（ステップＳ２５０５）。
【０１１０】
これに対し、このＩＰマルチキャストを「帯域あり」の状態で受信したい受信端末２１０２は、上流側（即ちＩＧＭＰルータ２１０１）に対して、ＲＳＶＰのＲＥＳＶメッセージを送付して、帯域の確保を要求する（ステップＳ２５０６）。
【０１１１】
ＩＰ上の帯域予約プロトコルの一例であるＲＳＶＰでは、送信ホスト（上流側のノード）がＰＡＴＨメッセージをデータと共に送信する。通信帯域などはこの送信ホストが基本的に設定する。これに対して、帯域予約を希望する受信端末は、ＲＥＳＶメッセージを送信ノード宛てに送信する。一般にルータは、ＰＡＴＨメッセージに対応するＲＥＳＶメッセージを監視して、ＲＥＳＶメッセージを検出すると帯域予約を実行する。ここでは、既に説明したＩＰマルチキャストアドレスとチャネルの対応が設定されているものとする。
【０１１２】
受信端末２１０２からのＲＥＳＶメッセージを検出すると、ＩＧＭＰルータ２１０１は、同期リソースマネージャ２１０４にアクセスし、帯域を確保する。帯域が確保できた場合は、自らと受信端末２１０１のレイヤ３フローレジスタに確保した帯域情報（帯域量ｙ）を記入して、帯域確保に成功した旨を伝える（ステップＳ２５０７〜ステップＳ２５０８）。
【０１１３】
その後、帯域の確保された同期チャネル（チャネル番号「＃ｘ」）を使って、引き続きＩＰマルチキャストアドレス「ＩＰｍ」宛のデータグラム配送が行われる（ステップＳ２５０９）。
【０１１４】
なお、この時点で複数の受信端末がいる場合には、各々の受信端末のレイヤ３フローレジスタの帯域の部分をＩＧＭＰルータ２１０１は書き換えてもよい。また、各々の受信端末の同レジスタの書き換えが、受信端末数が多い時などに面倒な作業となるため、受信端末の同レジスタの書き換えは行なわず、自ら（ＩＧＭＰルータ２１０１）のレイヤ３フローレジスタの値のみを反映させる方式も考えられる。
【０１１５】
以上説明したように、非同期ストリームに対して帯域を与える際には、ＱＯＳパケットを送信するノードが帯域の確保を行うというルールに従うことにより、複数の受信端末が同時に同じチャネルに対して帯域を確保してしまうような、いわゆる帯域の２重確保を回避することが可能である。また、通常必要な帯域は送信ノードがその値を把握している場合が多いと考えられるため、この観点からも妥当である。
【０１１６】
（２−３）
さて、これまではレイヤ３フローレジスタを使って、ＩＰマルチキャストフローと、そのフローが流れる同期チャネルまたは非同期ストリームのチャネル番号の対応関係を通知してきたが、これをＦＡＮＰ（Ｆｌｏｗ ＡｔｔｒｉｂｕｔｅＮｏｔｉｆｉｃａｔｉｏｎＰｒｏｔｏｃｏｌ）を用いて行なうことも可能である。ＦＡＮＰは、ＩＰデータグラムを用いて、あるデータリンクレイヤのチャネル（例えばＩＥＥＥ１３９４の同期チャネルや非同期ストリーム、あるいはＡＴＭやフレームリレーの仮想チャネル等）と、そのチャネルを通る上位レイヤのフロー（例えばＩＰフロー）の対応関係を通知するプロトコルである。
【０１１７】
この場合の手順を図１７に示すシーケンス図を参照して説明する。受信端末２１０２がＩＰマルチキャストアドレス「ＩＰｍ」への加入を希望している場合、ＩＧＭＰを使った加入手続きは、ＩＧＭＰルータ２１０１との間で図１２の場合と同様に行なわれる（ステップＳ２６０１）。ＩＧＭＰルータ２１０１は、このＩＰマルチキャストアドレス「ＩＰｍ」のためのチャネルを確保するべく、同期リソースマネージャ２１０４にアクセスし、チャネル番号「＃ｘ」を確保する（ステップＳ２６０２）。
【０１１８】
次に、ＩＧＭＰルータ２１０１は、受信端末２１０２に対して、「チャネル「＃ｘ」を通して、ＩＰマルチキャスト「ＩＰｍ」を提供する」旨を通知するため、ＩＥＥＥ１３９４のプラグコントロールレジスタとＦＡＮＰを使う。
【０１１９】
プラグコントロールレジスタとは、あるチャネル番号を使って提供される、同期チャネル／非同期ストリームを受信、あるいは送信するように促す作用のあるレジスタであり、入力用と出力用が分かれている。このプラグコントロールレジスタを使って、ＩＧＭＰルータ２１０１は、受信端末２１０２に対して、チャネル「＃ｘ」を受信するように促す（ステップＳＳ６０３）。なお、その際、ＩＧＭＰルータ２１０１は、自らのプラグコントロールレジスタについても記入を行なってもよい。この場合は、コネクションカウンタに前例と同様なルールで、そのＩＰマルチキャストアドレスの受信端末の数を記入していってもよい。これにより、そのマルチキャストをそのチャネルから受信しているノード数などの把握を行うことが可能である。
【０１２０】
次に、ＩＧＭＰルータ２１０１は、ＦＡＮＰオファーメッセージとして、図１８のようなメッセージを受信端末２１０２に送付する。このＦＡＮＰメッセージの宛先はＩＰマルチキャストアドレス「ＩＰｍ」であり、また、このＦＡＮＰメッセージはＩＥＥＥ１３９４バスに割り当てられたレイヤ３パケットのブロードキャストチャネル（例えば、特定の非同期ストリームや、ノードＩＤ＝オール「１」宛のパケット）で送付される。
【０１２１】
図１８に示すように、ＦＡＮＰオファーメッセージには、フロー識別子とレイヤ２識別子が含まれ、前述したようなレイヤ２識別子（本実施形態の場合、チャネル番号「＃ｘ」）と、このレイヤ２識別子であらわされるチャネルを通して提供される上位レイヤフロー（本実施形態の場合、ＩＰマルチキャストアドレス「ＩＰｍ」）との対応関係を通知する（Ｓ２６０４）。
【０１２２】
その後、このチャネル「＃ｘ」を通じて、ＩＰマルチキャストアドレス「ＩＰｍ」宛のデータグラムが送信されることになる（ステップＳ２６０５）。
同様に、他の受信端末２１０２からの加入要求があった場合（ステップＳ２６０６）も、プラグコントロールレジスタへの書き込みと（ステップＳ２６０７）、ＦＡＮＰメッセージの送付（ステップＳ２６０８）を行なうことで、対応関係の通知を行なうことができる。
【０１２３】
なお、この場合、ＦＡＮＰメッセージは、ＩＰマルチキャストアドレス宛であるため、受信端末が複数の場合であっても、必ずしもいちいち各々の受信端末宛にＦＡＮＰメッセージを送付する必要は必ずしもなく、ＩＰマルチキャストアドレス「ＩＰｍ」宛のデータグラムを１回送信すればよいので、ＩＥＥＥ１３９４バス上のトラヒックを減らすことが出きる点で有利である。
【０１２４】
さて、本実施形態においては、プラグコントロールレジスタとＦＡＮＰオファーメッセージを使って、レイヤ２識別子とレイヤ３フローの対応関係を通知してきた。ここで、ＦＡＮＰメッセージを使わないと上記対応関係の通知はできないが、プラグコントロールレジスタへの書き込みにより、受信端末はこの同期チャネルからのデータ受信は行なうようになるため、必ずしも上記対応関係の通知が必要ない場合は、上記ＦＡＮＰメッセージの送付は省略してもよい。また逆に、ＦＡＮＰメッセージがあれば、受信端末はどのチャネル番号からどのレイヤ３フローが入力されてくるのかを認識することが可能であるため、プラグコントロールレジスタへの書き込み手順を省略することも可能である。
【０１２５】
（２−４）
次に、同じＩＰマルチキャストアドレスを用いて、複数のフローが送信される場合の手順を図１９に示すシーケンス図を参照して説明する。
【０１２６】
図１９では、ＩＧＭＰルータ２１０１から受信端末２１０１に向ってＩＰマルチキャストアドレスが「ＩＰｍ」のマルチキャストパケットが送信される場合、ポート番号が「ＰＯＲＴ１」で表されるフロー（ステップＳ２８０４）と、「ＰＯＲＴ２」で表されるフロー（ステップＳ２８０５）の計２つのフローが同時に送信される場合を示している。
【０１２７】
ＩＧＭＰによるマルチキャストアドレスへの加入（ステップＳ２８０１）、ＩＧＭＰルータ２１０１による同期チャネル番号の確保（ステップＳ２８０２）については、前述同様である。
【０１２８】
ステップＳ２８０３で、レイヤ３フローレジスタの書き込みを行う際には、特に、ステップＳ２８０２で確保した同期チャネル番号「＃ｘ」で表される非同期ストリームに送信されるフローは特に限定されず、単にＩＰマルチキャストアドレス「ＩＰｍ」のパケットが送信される事のみが限定されることから、ステップＳ２８０４とステップＳ２８０５の両方のフローが、チャネル番号「＃ｘ」で表される非同期ストリームにて転送される。
【０１２９】
さて、このうちＩＧＭＰルータ２１０１は、「ＰＯＲＴ１」で表されるフローについては、ＱＯＳありの送信を許容しているものとする。そのため、ＩＧＭＰルータ２１０１は、ＲＳＶＰのＰＡＴＨメッセージをＩＰマルチキャストアドレス「ＩＰｍ」宛てに送信する（ステップＳ２８０６）。これに対し、受信端末２１０１はＲＥＳＶメッセージを送信することで、帯域の確保を要求する（Ｓ８０７）。すると、ＩＧＭＰルータは、同期リソースマネージャにアクセスし、ＲＳＶＰメッセージで指定された、必要な帯域を確保する。ここでは、この値を「ｙ」とする（ステップＳ２８０８）。
【０１３０】
すると、ＩＧＭＰルータ２１０１は、受信端末２１０２に対して、同期チャネル番号「＃ｘ」を通して帯域量「ｙ」のデータが、同期チャネルのアービトレーション周期にて送信されることを受信端末２１０２に通知するため、受信端末２１０２のレイヤ３フローレジスタに書き込む（ステップＳ２８０９）。ステップＳ２８０９において、受信端末２１０２に通知する内容は、レイヤ３フローレジスタを用いる場合に限らず、前述したＦＡＮＰ、あるいはＩＥＣ１８８３のプラグコントロールレジスタを用いても通知できる。どれを用いるかはシステムに依存である。
【０１３１】
その後のＩＧＭＰルータ２１０１からのＩＰマルチキャストデータの送信は、帯域確保がされていない「ＰＯＲＴ２」で示されるフローについては、ステップＳ２８０５でのフローと同様、非同期ストリームを通して送信されるが（ステップＳ２８１１）、帯域確保を行った「ＰＯＲＴ１」で表されるフローについては、同期チャネルとして（即ち、同期のアービトレーション期間にて）送信される（ステップＳ２８１０）。
【０１３２】
さて、ＩＧＭＰルータ２１０１において、同期チャネル「＃ｘ」で確保した帯域量「ｙ」以上の帯域のＩＰマルチキャストデータ（「ＩＰｍ」宛てのＩＰマルチキャストパケット）が入り込む可能性がある。これらのパケットをそのまま同期チャネル「＃ｘ」に流し込むことは、確保していない帯域分も、このＩＰマルチキャストパケットが通信資源を消費してしまうことを意味し、望ましくない。
【０１３３】
そこで、図２０のようなアルゴリズムを用いて、帯域が確保されている分については同期チャネルに（ステップＳ２９０１、ステップＳ２９０２）、確保されていない分については非同期ストリームに（ステップＳ２９０１、ステップＳ２９０３）それぞれ送信するというルールを作ることにより、確保した以上の帯域量のデータを、該同期チャネルに流し込んでしまうことを防ぐことが出来る。
【０１３４】
ここで、Ｔスペックとは、ＲＳＶＰの予約の時に指定されるトラヒックパラメータのことで、ピークレートやリーキーバケットのバケツの深さ等が指定されてもよい。
【０１３５】
図２０のメカニズムを実現するための構成例を図２１に示す。ＷＦＱとは、Ｗｅｉｇｈｔｅｄ Ｆａｉｒ Ｑｕｅｕｅｉｎｇの略で、１つの出力ポートを複数のセンダ／フローからのパケットが共有する場合に、フロー毎にあらかじめ指定された量（重みという）の比に従って、送出されるパケット量の比もこれと同じにするパケットスケジューリング方法である。
【０１３６】
ＷＦＱ処理部２２０１は、このＷＦＱのスケジューリングで、Ｔスペックを満たすものについては、同期キュー２２０２に、満たさないものについては非同期キュー２２０３に入れるものとし、同期キューに溜められたデータは、パケット送信部２２０４を介して同期のアービトレーション期間に、非同期キューに溜められたデータは、パケット送信部２２０４を介して非同期のアービトレーション期間にそれぞれ送信される。
【０１３７】
以上は、帯域を確保した場合にも、同期チャネル番号は同じ値を続けて使用する使い方についてであった。これに対して、帯域確保が必要なチャネルについては、非同期ストリームで利用していたチャネル（「＃ｘ」）とは別の同期チャネル（「＃ｚ」）を確保する方法も考えられる。
【０１３８】
この場合の手順について、図２２のシーケンス図を参照して説明する。
図２２のステップＳ３１０１〜ステップＳ３１０７において、ＲＳＶＰのＲＥＳＶメッセージにて、帯域確保の要求（ＲＥＳＶ）が受信端末２１０１からあるまでは、図１９のステップＳ２８０１〜ステップＳ２８０７と同様である。
【０１３９】
ステップＳ３１０７で、帯域の確保要求を受け取ると、ＩＧＭＰルータ２１０１は、これまで使用していた非同期ストリームのチャネル番号（「＃ｘ」）とは異なる、同期チャネル番号（「＃ｚ」）と帯域量（ｙ）の両方の確保を行う（ステップＳ３１０８、ステップＳ３１０９）。
【０１４０】
この場合も「送信者（すなわち、本実施形態の場合、ＩＧＭＰルータ２１０１）が、リンクレイヤの必要な帯域を確保する」というルールに従っている。その後、ＩＧＭＰルータ２１０１は、受信端末２１０２のレイヤ３フローレジスタに、「ＰＯＲＴ１」で表されるフローについては、同期チャネル番号「＃ｚ」で表される（非同期ストリームではなくて）同期チャネルを用いて送信されることを書き込むことで、受信端末２１０２に通知する（ステップＳ３１１０）。なお、ステップＳ３１１１において、受信端末２１０２に通知する内容は、レイヤ３フローレジスタを用いる場合に限らず、前述のように、ＩＥＣ１８８３のプラグコントロールレジスタや、ＦＡＮＰを用いて行うこともできる。
【０１４１】
以後、ＩＰマルチキャストアドレス「ＩＰｍ」宛てのパケットのうち、「ＰＯＲＴ１」で表されるフローについては、同期チャネル「＃ｚ」を通して、同期チャネルで転送され（ステップＳ３１１１）、それ以外のフローについては、引き続き非同期ストリームにて送信され続ける（ステップＳ３１１２）。
【０１４２】
（２−５）
次に、１つのチャネル番号で示される非同期ストリームあるいは同期チャネルを用いて、複数のマルチキャストデータのセンダがいる場合について、図２３を参照して説明する。なお、ここでは、図１１の端末２１０２、２１０３は、ＩＰマルチキャストへ加入した後は、マルチキャストデータの送受信端末となり、以下、端末２１０２、２１０３を端末Ａ、端末Ｂと呼ぶ。
【０１４３】
図２３は、同一のＩＰマルチキャストアドレス「ＩＰｍ」に対して、端末Ａ（ＩＰアドレス「ＩＰ１」、１３９４アドレス「ＦＷ１」）と、端末Ｂ（ＩＰアドレス「ＩＰ２」、１３９４アドレス「ＦＷ２」）の２つの端末がＩＰマルチキャストパケットを送信する場合を示している。ここで、１３９４アドレスとは、例えばＩＥＥＥ１３９４のノードＩＤ等、そのＩＥＥＥ１３９４バス上でその端末を一意に識別することの出来るＩＤを指す。
【０１４４】
図２３のステップＳ３２０１〜ステップＳ３０４、ステップＳ３２０６〜ステップＳ３３２０８のマルチキャストへの加入、チャネル番号の確保、ＩＰマルチキャストアドレスとチャネル番号との対応関係の通知の手順は、図１１と同様である。
【０１４５】
特徴的な点は、端末Ａ、Ｂのそれぞれは、ＩＰマルチキャストパケットに同一のチャネル番号「＃ｘ」で表されるチャネルに、自らのソースアドレス（「ＦＷ１」または「ＦＷ２」）を付加して当該パケットを送信する（ステップＳ３２０５、Ｓ３２０９、Ｓ３２１０）ことである。
【０１４６】
このソースアドレスは、フラグメントヘッダと呼ばれる、ＩＰパケットを１３９４フレームに分割する時に、そのそれぞれの分割片に付与するヘッダに書き込まれる。
【０１４７】
端末Ａ、Ｂのそれぞれから送出されるＩＰマルチキャストのデータ構成の概略を図２４に示す。なお、図２４（ａ）は端末Ａから送出されるＩＰマルチキャストのデータ構成で、図２４（ｂ）は端末Ｂから送出されるＩＰマルチキャストのデータ構成である。図２４（ａ）、（ｂ）に示すように、ＩＰマルチキャストパケット（あるいはこれをフラグメントしたもの）３３０１、３３０４をソースアドレスを含むフラグメントヘッダでカプセル化して生成されたフラグメントデータ３３０２、３３０５を、更に１３９４フレーム１３０３（この場合、同期フレーム）に収めて構成される。
【０１４８】
受信者は、同一のチャネル番号で示される非同期ストリームから、複数のセンダからのパケットを受け取ることになるが、このようにソースアドレスがそれぞれのフレームに付与されていることで、各々のパケットのリアセンブリを、ソースアドレスを参照することにより、正確に行うことが出来るようになる。
【０１４９】
以上は、同一のＩＰマルチキャストアドレスに対して、複数のセンダが送信する場合において、帯域確保が伴わない場合についての説明であった。これに対し、帯域確保を伴う場合の説明を以下に行う。
【０１５０】
図２５において、例えば、図２３のＳ３２０１〜Ｓ３２１０の手順が終了し、非同期ストリームの形で２つのセンダ、すなわち、端末Ａと端末Ｂとから同一のＩＰマルチキャストアドレス「ＩＰｍ」宛てのＩＰマルチキャストパケットが送信されているものとする（ステップＳ３４０１、ステップＳ３４０２）。
【０１５１】
ここで、端末Ａが、何等かの形で帯域ありの形でのＩＰマルチキャストデータの送信を依頼された場合（例えばＲＳＶＰのＲＥＳＶを受信した場合等）や、帯域ありの形でのデータ送信を自ら選択した様な場合、同期リソースマネージャ２１０４にアクセスして帯域量（ｙ１）を確保要求を行って（ステップＳ３４０３）、以後、端末Ａは、送信するＩＰマルチキャストのパケットは、確保された帯域量ｙ１の同期チャネルを通して、かつ、同期のアービトレーション期間に送信する（ステップＳ３４０４）。ここで、帯域確保をしていない端末Ｂは、同じチャネル番号「＃ｘ」にＩＰマルチキャストパケットを送信し続けているものの、送信は非同期ストリームとして、非同期のアービトレーション期間に送信する（ステップＳ３４０５）。
【０１５２】
端末Ｂが帯域ありの形で送信する場合は、端末Ｂも同期リソースマネージャ２１０４にアクセスして、やはり所望の帯域を確保し（ステップＳ３４０６）、データ送信を同期のアービトレーション期間内に行うことになる（ステップＳ３４０８）。
【０１５３】
先に確保された帯域をキャンセルする場合は、同期リソースマネージャ２１０４に対し、その帯域をキャンセルするための要求を行い（ステップＳ３４０９）、同期のアービトレーション周期にはパケットを送信しないようにし、もし送信パケットがある場合には、非同期ストリーム（非同期のアービトレーション期間）に送信する（ステップＳ３４１０）。
【０１５４】
これに対して、帯域ありの形でＩＰマルチキャストを送信する場合には、非同期ストリームで使用していたチャネル番号「＃ｘ」とは別のチャネル番号「＃ｚ」を持つ同期チャネルで、これを送信する方法も考えられる。この場合について、図２６のシーケンス図を参照して説明する。
【０１５５】
図２６において、例えば、図２３のＳ３２０１〜Ｓ３２１０の手順が終了し、非同期ストリームの形で２つのセンダ、すなわち、端末Ａと端末Ｂとから同一のＩＰマルチキャストアドレス「ＩＰｍ」宛てのＩＰマルチキャストパケットが送信されているものとする（ステップＳ３５０１、ステップＳ３５０２）。
【０１５６】
このとき、例えば、ＲＳＶＰのＲＥＳＶメッセージなどで、帯域ありの形でのＩＰマルチキャストパケットの送信を依頼された（例えば、図２６に示したように、端末ＡからのＲＳＶＰのＰＡＴＨメッセージにを受けて端末ＢからＲＥＳＶメッセージを受信したとき）、端末Ａは、同期リソースマネージャ２１０４にアクセスし、同期チャネル番号「＃ｚ」の確保と、帯域量「ｙ１」の確保を行う（ステップＳ３５０３〜ステップＳ３５０６）。
【０１５７】
続いて、確保した同期チャネル番号と、その同期チャネルを通して送信するフローの対応関係を通知するためのＦＡＮＰメッセージを、該ＩＰマルチキャストアドレス「ＩＰｍ」宛てに、例えば非同期ストリーム「＃ｘ」、またはデフォルトの非同期ストリームなどで送信する（ステップＳ３５０７）。これを受信したノードは、どの同期チャネルから、どのようなフローがどのような特性で入力されてくるかを認識することが出来るようになる。なお、前述のように、ここではＦＡＮＰメッセージを用いて、この対応関係の通知を行っているが、これはレイヤ３フローレジスタ、あるいはＩＥＣ１８８３において使用されるプラグコントロールレジスタを用いても実現が可能なものである。
【０１５８】
【発明の効果】
以上説明したように、第１の発明（第１の実施形態）によれば、ＲＳＶＰ等のネットワークレイヤのシグナリングプロトコルをＩＥＥＥ１３９４上で運用する方式がいまだ決まっておらず、そのままマッピングを行うと、ＩＥＥＥ１３９４上では通信品質が確保されず、エンドエンドの通信品質が保たれないという問題点に対し、ＲＳＶＰのＩＥＥＥ１３９４バス上での適用方法を示し、ＩＥＥＥ１３９４上でも、相互接続環境での通信品質を確保した通信が可能となる。
【０１５９】
また、第２の発明（第２の実施形態）によれば、ＩＥＥＥ１３９４等の放送型ネットワークにおいて、通信資源を有効に利用してＩＰマルチキャストを行うことができ、また、確保したチャネルとＩＰマルチキャストアドレスとの対応関係を送信側、受信側で同期して認識することのできる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るネットワーク全体の構成例を示したもので、映像サービスを提供しているビデオサーバからのデータを、公衆網を介して家庭内ネットワークにとりこみ、家庭内ネットワークに接続された端末で、該サービスを受ける状況を説明するための図。
【図２】図１の端末が接続装置、公衆網を通してビデオサーバからビデオを転送してもらうまでの全体の処理手順を示した図で、ＩＥＥＥ１３９４上の通信資源予約をＲＳＶＰの上流のノードが行う場合を示している。
【図３】図１の端末が接続装置、公衆網を通してビデオサーバからビデオを転送してもらうまでの端末の処理手順を示した図。
【図４】図１の端末が接続装置、公衆網を通してビデオサーバからビデオを転送してもらうまでの接続装置の処理手順を示した図。
【図５】接続装置に記憶される対応テーブルの一例を示した図。
【図６】ＲＳＶＰのＰＡＴＨメッセージのフォーマットの一例を示した図。
【図７】ＩＥＥＥ１３９４のＰＣＲレジスタの記述例を示した図。
【図８】図１の端末が接続装置、公衆網を通してビデオサーバからビデオを転送してもらうまでの通信システム全体の処理手順を示した図で、ＩＥＥＥ１３９４上の通信資源予約をＲＳＶＰの下流のノードが行う場合を示している。
【図９】すでに加入したＩＰマルチキャストアドレスを離脱して異なるＩＰマルチキャストアドレスに加入し、異なるコンテンツの配送を行う場合について説明するための図。
【図１０】ＩＰマルチキャストアドレスは同じで、コンテンツが変わる場合について説明するための図。
【図１１】本発明の第２の実施形態に係るネットワーク（ＩＥＥＥ１３９４バス）全体の構成例を示した図。
【図１２】受信端末がＩＰマルチキャストに加入する場合の手順を説明したシーケンス図。
【図１３】ＩＧＭＰルータにおけるＩＰマルチキャストアドレスへの加入時の処理手順を説明するためのフローチャート。
【図１４】レイヤ３フローレジスタのフォーマットの一例を示した図。
【図１５】ＩＧＭＰルータにおけるＩＰマルチキャストアドレスからの脱退時の処理手順を説明するためのフローチャート。
【図１６】ＩＰマルチキャストのために確保された非同期ストリームに対して帯域を与える場合の手順を説明するためのシーケンス図。
【図１７】ＩＰマルチキャストフローとチャネル番号の対応関係をＦＡＮＰを用いて行う場合の手順を説明するためのシーケンス図。
【図１８】ＦＡＮＰオファーメッセージの一例を示した図。
【図１９】同じＩＰマルチキャストアドレスを用いて、複数のフローが送信される場合の手順を説明するためのシーケンス図。
【図２０】同期チャネルに予め確保されている帯域量以上のＩＰマルチキャストデータを送信する場合のＩＧＭＰルータの処理動作について説明するためのフローチャート。
【図２１】図２０のアルゴリズムを実現するための構成例を示した図。
【図２２】ＩＰマルチキャストのために確保された非同期ストリームに対して帯域を与え、その帯域を与えられた同期チャネルには非同期ストリームとは異なるチャネル番号を用いる場合の手順を説明するためのシーケンス図。
【図２３】同一のＩＰマルチキャストアドレスに対して複数のセンダがいる場合の手順を説明するためのシーケンス図。
【図２４】端末Ａ、Ｂのそれぞれから送出されるＩＰマルチキャストのデータ構成の概略を示した図。
【図２５】同一のＩＰマルチキャストアドレスに対して複数のセンダが送信する場合において、さらに帯域確保を伴う場合の手順を説明するためのシーケンス図。
【図２６】同一のＩＰマルチキャストアドレスに対して複数のセンダが送信する場合において、さらに帯域確保を伴う場合には、非同期ストリームとは異なるチャネル番号を用いる場合の手順を説明するためのシーケンス図。
【符号の説明】
１０１…ビデオサーバ（通信装置、送信端末）
１０２…接続装置（通信制御装置）
１０３…端末（通信装置）
１０４…公衆網
１０５…第１の家庭内ネットワーク（ＩＥＥＥ１３９４）
１０６…第２の家庭内ネットワーク
２１０１…ＩＧＭＰルータ（通信装置）
２１０２…端末装置（受信端末、通信装置）
２１０３…端末装置（受信端末、通信装置）
２１０４…同期リソースマネージャ
Claims (3)
- 放送型のネットワークに接続され、ネットワークレイヤマルチキャストアドレス宛てのデータを送信する通信装置であって、
前記ネットワーク上に確立されている放送型チャネルに対する通信帯域を確保する確保手段と、
前記放送型チャネルに帯域が確保されていない場合に、前記ネットワークレイヤマルチキャストアドレス宛てのデータを前記放送型チャネルの帯域が確保されていない周期あるいはコネクションで送信する第１の送信手段と、
前記確保手段により前記放送型チャネルに帯域が確保された場合に、前記ネットワークレイヤマルチキャストアドレス宛てのデータを前記放送型チャネルの帯域が確保されていない周期あるいはコネクションから、前記放送型チャネルの帯域が確保された周期あるいはコネクションに切り替えて送信する第２の送信手段と、
を具備したことを特徴とする通信装置。 - 前記確保手段で帯域が確保された場合の前記第１の送信手段から出力される放送型チャネルの識別子は、帯域が確保されていない場合の前記第２の送信手段から出力される放送型チャネルの識別子と同一の識別子であることを特徴とする請求項１記載の通信装置。
- 放送型のネットワークに接続され、ネットワークレイヤマルチキャストアドレス宛てのデータを送信する通信方法において、
前記ネットワーク上に確立されている放送型チャネルに通信帯域が確保されていない場合に、前記ネットワークレイヤマルチキャストアドレス宛てのデータを前記放送型チャネルの帯域が確保されていない周期あるいはコネクションで送信し、
前記ネットワーク上に確立されている放送型チャネルに対して通信帯域が確保された場合に、前記ネットワークレイヤマルチキャストアドレス宛てのデータを、前記放送型チャネルの帯域が確保されていない周期あるいはコネクションから、前記放送型チャネルの帯域が確保された周期あるいはコネクションに切り替えて送信する
ことを特徴とする通信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP05332198A JP4003989B2 (ja) | 1997-03-06 | 1998-03-05 | 通信装置および通信方法 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP9-52125 | 1997-03-06 | ||
| JP5212597 | 1997-03-06 | ||
| JP05332198A JP4003989B2 (ja) | 1997-03-06 | 1998-03-05 | 通信装置および通信方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10308759A JPH10308759A (ja) | 1998-11-17 |
| JP4003989B2 true JP4003989B2 (ja) | 2007-11-07 |
Family
ID=26392736
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP05332198A Expired - Fee Related JP4003989B2 (ja) | 1997-03-06 | 1998-03-05 | 通信装置および通信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4003989B2 (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4168302B2 (ja) * | 1998-05-12 | 2008-10-22 | ソニー株式会社 | 情報受信装置および方法、並びに記録媒体 |
| JP3436174B2 (ja) | 1999-03-09 | 2003-08-11 | 日本電気株式会社 | 通信方法 |
| US6977928B1 (en) | 2000-04-13 | 2005-12-20 | International Business Machines Corporation | Method and system for data flow multicasting |
| US20020077117A1 (en) * | 2000-12-15 | 2002-06-20 | Jocelyn Cloutier | Synchronous transmission of data with network remote control |
| JP3685753B2 (ja) | 2001-11-30 | 2005-08-24 | パナソニック コミュニケーションズ株式会社 | 宅側情報配信システム及び番組受信方法 |
| JP4041967B2 (ja) | 2002-10-01 | 2008-02-06 | ソニー株式会社 | 無線通信端末および無線通信方法 |
| JP4832784B2 (ja) * | 2005-04-01 | 2011-12-07 | Ｋｄｄｉ株式会社 | 放送コンテンツ伝送装置、放送コンテンツ受信装置、放送コンテンツ伝送方法、及び放送コンテンツ受信方法 |
| JP4764509B2 (ja) | 2007-06-12 | 2011-09-07 | 富士通株式会社 | 通信装置および通信リソース管理方法 |
| KR101837085B1 (ko) | 2010-08-20 | 2018-03-09 | 삼성전자주식회사 | Ａｖ 인터페이스에 기초해 성립된 네트워크에서 경로 대역폭을 확보하여 데이터를 송수신하는 방법 및 장치 |
-
1998
- 1998-03-05 JP JP05332198A patent/JP4003989B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH10308759A (ja) | 1998-11-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0741937B1 (en) | Network having secure fast packet switching and guaranteed quality of service | |
| US7720090B2 (en) | Apparatuses and methods to utilize multiple protocols in a communication system | |
| US6021263A (en) | Management of ATM virtual circuits with resources reservation protocol | |
| EP1734697B1 (en) | A method for transmitting the policy information between the network devices | |
| CA2286422C (en) | Multicast communication method and apparatus | |
| US20050190775A1 (en) | System and method for establishing service access relations | |
| JPH11103303A (ja) | ネットワーク資源予約制御方法および装置、受信端末、送信端末、並びに中継装置 | |
| US6028862A (en) | Fast path networking | |
| CA2250918A1 (en) | Apparatus, method, system and system method for distributed routing in a multipoint communication system | |
| CN101299671A (zh) | 用于组播数据包发送与接收的方法和装置 | |
| JPH1155330A (ja) | インターネット閉域ユーザーグループ | |
| JP2001502509A (ja) | 優先順位付けされたパケットの送信用ａｔｍセルを用いたケーブルネットワーク | |
| JP4376457B2 (ja) | 構内または広域ネットワークのサービスの保証された品質を与える方法および装置 | |
| EP1134932B1 (en) | System for receiving multicast data | |
| JP4003989B2 (ja) | 通信装置および通信方法 | |
| JP2005039814A (ja) | 電力線通信に基づくｌａｎにおけるパケット伝送制御方法 | |
| Ghanwani et al. | A framework for integrated services over shared and switched IEEE 802 LAN technologies | |
| JP3634201B2 (ja) | ネットワーク間データ伝送方法 | |
| KR100433545B1 (ko) | 동일 네트웍 상에 존재하는 기기들의 ＭＣＡＰ（Ｍｕｌｔｉｃａｓｔ ＣｈａｎｎｅｌＡｌｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）지원 여부 식별방법 및 이를 이용한 멀티캐스트 통신 방법 | |
| RU2310994C2 (ru) | Фильтр для разделения трафика | |
| JPH10308758A (ja) | 通信装置 | |
| JPH10308756A (ja) | 通信装置および通信方法 | |
| Montessoro et al. | Advanced research issues for tomorrow's multimedia networks | |
| Chapman et al. | Enhancing transport networks with Internet protocols | |
| CN115189983B (zh) | 一种访问autbus网络的tsn装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050228 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20050414 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20050606 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070307 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070612 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070726 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070817 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070820 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100831 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100831 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110831 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110831 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120831 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120831 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130831 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |