JPH10308764A

JPH10308764A - ネットワーク間接続装置および通信装置および通信方法

Info

Publication number: JPH10308764A
Application number: JP5074698A
Authority: JP
Inventors: Takeshi Saito; 健斉藤; Yoshiaki Takahata; 由彰高畠; Mikio Hashimoto; 幹生橋本
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 1997-03-06
Filing date: 1998-03-03
Publication date: 1998-11-17

Abstract

(57)【要約】【課題】複数のネットワーク（例えば２つ以上のＩＥＥ
Ｅ１３９４）をまたがって転送する際に、所望の通信品
質を有する通信資源の確保を円滑に行うことができるネ
ットワーク間接続装置を提供する。【解決手段】第１のネットワークに接続されたノードか
らの要求に応じて、前記第２のネットワークの通信資源
の確保を行い、その識別子と既に確保されている第１の
ネットワークの通信資源の識別子を対応付ける対応テー
ブルを記憶し、前記第１のネットワークに接続されたノ
ードから前記第２のネットワークに接続されたノードに
送信される、少なくとも前記第１のネットワークで確保
された通信資源の識別子を含むメッセージを受信する
と、前記対応テーブルを参照して、そのメッセージに含
まれる識別子を前記第２のネットワークの通信資源の識
別子に書き変えて前記第２のネットワークに接続された
ノードに送信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、相互接続されたネ
ットワーク環境において非ＩＰパケットを転送する通信
システムに関する。

【０００２】

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

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

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

【０００５】現在、ＩＥＥＥ１３９４バスを用いたホー
ムネットワークの実現のための技術開発が活発に行われ
ているが、その開発の主な対象は、単一のＩＥＥＥ１３
９４バス上における情報転送のための装置、及びメカニ
ズムである。

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

【０００７】インターネット上で、これらの技術が実現
する近未来においては、家庭へのビデオ転送等、高速、
リアルタイムを要求される情報の転送の一部がインター
ネットを通じて行われる可能性がある。当然ながら、現
状で検討されているのは、「データは、インターネット
パケット（ＩＰパケット）の形で転送される」という方
式である。

【０００８】

【発明が解決しようとする課題】しかしながら、家庭内
外を流通すると考えられる情報は、必ずしもＩＰパケッ
トの形で流通するとは限らない。例えば、衛星放送のコ
ンテンツは、放送衛星や、通信衛星などから、直接ＭＰ
ＥＧ２のデジタルデータが周波数分割と、ＭＰＥＧ多重
の形で転送されてくる場合がほとんどである。これらの
情報を例えば複数のネットワーク（例えば、２つ以上の
ＩＥＥＥ１３９４）をまたがって流通させようという場
合、途中で同期チャネル番号が変わってしまうなどのＩ
ＥＥＥ１３９４特有の性質のため、そのメカニズムの開
発はいまだ行われていない。

【０００９】ＩＥＥＥ１３９４バスのブリッジ接続環境
において、ブリッジをまたがった同期チャネル、あるい
は非同期ストリームの確立方法が無い。また、ＩＥＥＥ
１３９４バスのブリッジ接続環境においては、ブリッジ
を通過するごとに同期チャネル番号が変更される可能性
があり、その場合、送信端末と受信端末の間で、前記ブ
リッジ接続された同期チャネルを、同一のものと判断す
る方法がなく、特定の同期チャネルを使って何らかの通
信をする場合のネゴシエーションなどができない問題点
もある。

【００１０】また、ＣＡＴＶ等、インターネットパケッ
トを転送するネットワークと同じ物理ネットワークを用
いて、別のデータ転送を行うことのできるネットワーク
が多く出てきている。あるＶＣ（仮想チャンネル）でイ
ンターネットサービスを行い、別のあるＶＣで非ＩＰパ
ケットの転送を行うＡＴＭ網等もこの例に入る。

【００１１】このような場合、非ＩＰパケットの形で転
送されてくる情報の獲得のための通信資源予約のための
メカニズムが、良好なＱＯＳ（通信品質）での受信のた
めには必要である。複数データリンクをまたがる形で、
これを実現するためのメカニズムはいまだ存在しない。

【００１２】本発明は、以上のような点を考慮してなさ
れたものであり、これらの問題点を解決しようとするも
のである。

【００１３】

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

（１）本発明の通信方法（ネットワーク間接続装置に適
用される通信方法）は、複数の放送型ネットワーク間で
データ転送を行う際に、少なくとも前記複数の放送型ネ
ットワークのそれぞれに確立された通信路の対応関係を
記憶手段に記憶し、前記記憶しておいた対応関係に基づ
き前記複数の放送型ネットワーク間でデータ転送を行う
ことを特徴とする。

【００１４】本発明によれば、複数の放送型ネットワー
クにまたがって確保した通信路を通して通信を行うよう
な環境において、例えば第１のネットワークと第２のネ
ットワークとで確保された通信路の識別子が異なる場合
においても、記憶手段に記憶しておいた入力側の通信路
と出力側の通信路との対応関係を参照して上で、データ
転送が可能となり、マルチメキャストを含む複数のネッ
トワークをまたがるエンドエンドの正確な通信が可能と
なる。

【００１５】（２）本発明のネットワーク間接続装置
は、第１の放送型ネットワークと第２の放送型ネットワ
ークに接続されたネットワーク間接続装置であって、前
記第１の放送型ネットワークに確立された第１の通信路
を用いて、複数の放送型ネットワークを介したデータフ
ローの送受信を行う複数の通信装置のうちの少なくとも
１つに向けて前記複数の放送型ネットワークのそれぞれ
に通信路を確立するための要求を受けて、前記第２の放
送型ネットワークに第２の通信路を確立する確立手段
と、この確立手段で確立された第２の通信路と前記第１
の通信路との対応関係を記憶する記憶手段と、この記憶
手段に記憶された対応関係に基づき、前記第１の放送型
ネットワークに確立された第１の通信路を用いて送信さ
れてきたデータを、前記第２の放送型ネットワークに確
立された前記第２の通信路に転送する転送手段と、を具
備したことを特徴とする。

【００１６】複数の放送型ネットワークにまたがって確
保した通信路を通して通信を行うような環境において、
例えば第１のネットワークと第２のネットワークとで確
保された通信路の識別子が異なる場合においても、記憶
手段に記憶しておいた入力側の通信路と出力側の通信路
との対応関係を参照して上で、データ転送が可能とな
り、マルチメキャストを含む複数のネットワークをまた
がるエンドエンドの正確な通信が可能となる。

【００１７】また、前記第１の放送型ネットワークおよ
び前記第２の放送型ネットワークの少なくとも一方はＩ
ＥＥＥ１３９４バスであり、しかも、前記メッセージに
含まれる識別子は前記ＩＥＥＥ１３９４バスの同期チャ
ネル番号であることにより、複数のネットワークをまた
がって、通信資源を確保した通信路を通して通信を行う
ような環境において、第１のネットワークと第２のネッ
トワークの少なくとも一方がＩＥＥＥ１３９４バスであ
る場合に、確保された通信路の識別子、特にＩＥＥＥ１
３９４バスの場合同期チャネル番号が第１のネットワー
クと第２のネットワークとで異なる場合においても、対
応テーブルと送信手段が、その適切な対応関係を把握し
た上で、前記メッセージを通じて送出する事が可能とな
るため、前記メッセージを確実に受信先まで送り届けて
やることが可能となると共に、そのメッセージ内容に矛
盾はなく、そのメッセージの受信者は、後に使われる通
信路を確実に知ることができるようになり、もって、エ
ンドエンドの正確な通信が可能となる。

【００１８】また、前記第１の放送型ネットワークおよ
び前記第２の放送型ネットワークの少なくとも一方はＵ
ＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）で
あり、しかも、前記メッセージに含まれる識別子は、前
記ＵＳＢのパイプ番号であることにより、複数のネット
ワークをまたがって、通信資源を確保した通信路を通し
て通信を行うような環境において、第１のネットワーク
と第２のネットワークの少なくとも一方がＵＳＢである
場合に、確保された通信路の識別子、特にＵＳＢの場合
パイプ番号が第１のネットワークと第２のネットワーク
とで異なる場合においても、対応テーブルと送信手段
が、その適切な対応関係を把握した上で、前記メッセー
ジを通じて送出する事が可能となるため、前記メッセー
ジを確実に受信先まで送り届けてやることが可能となる
と共に、そのメッセージ内容に矛盾はなく、そのメッセ
ージの受信者は、後に使われる通信路を確実に知ること
ができるようになり、もって、エンドエンドの正確な通
信が可能となる。

【００１９】（３、４、５）本発明のネットワーク間
接続装置は、第１の物理ネットワークと第２の物理ネッ
トワークに接続されたネットワーク間接続装置であっ
て、前記第１の物理ネットワークに接続されたノードと
前記第２の物理ネットワークに接続されたノードとの間
でデータを送受信する際の通信資源を確保するための論
理ネットワーク上のメッセージに基づき確保される前記
第１の物理ネットワークの通信資源の識別子と前記第２
の物理ネットワークの通信資源の識別子を対応付ける対
応テーブルを記憶する記憶手段と、前記メッセージに、
そのメッセージに基づき確保される通信資源を利用して
転送されるデータが前記論理ネットワーク上のデータで
ない旨の情報が含まれているときは、前記確保された通
信資源を利用して転送されるデータに対する論理ネット
ワークのデータ転送処理を省き、前記対応テーブルを参
照して前記第１の物理ネットワークに接続されたノード
から受信したデータを前記第２の物理ネットワークに接
続されたノードに送信する送信手段と、を具備したこと
により、複数のネットワークが相互に接続された環境に
おいて、例えば、ＩＰネットワーク（論理ネットワー
ク）上のＩＰパケットではない情報を転送しようとした
場合も、インターネットレイヤのシグナリングプロトコ
ル（たとえばＲＳＶＰ）のメッセージに、このメッセー
ジに基づき確保される通信資源を利用して送信されるデ
ータがＩＰパケットでない旨の情報を記述することによ
り、この情報をトリガとして前記通信資源の識別子のみ
を参照し、ＩＰレイヤ処理を伴わずに、パケットフォワ
ーディングを実行するデータリンクスイッチを実現する
ことも可能となり、データ転送処理の高速化が図れる。
また、複数のネットワークをまたがった、通信資源の確
保ができるようになると共に、途中の中継ノード（ネッ
トワーク間接続装置）が、前記通信資源（具体的には通
信路）を通過するデータが、ＩＰパケットではないと認
識することが可能である事から、中継ノードで通信資源
の確保手順を終了させることはできず、エンド・エンド
の確立確認が必要であるとの認識を中継ノードが持つこ
とができる様になる。

【００２０】また、途中の中継ノードを通して、データ
が前記通信資源（具体的には通信路）を通過する際に、
前記データはＩＰパケットではないことから、このデー
タをＩＰ処理部に入力させ、エラーですべてのデータが
廃棄される、といった不具合を未然に防止することが可
能となる。

【００２１】また、前記メッセージは、そのメッセージ
に基づき確保される通信資源を利用して転送されるデー
タの識別子を含み、前記第１および第２の物理ネットワ
ークに確保される通信資源あるいは前記受信データの転
送処理は前記データの識別子に対応付けられていること
により、前記第１および第２のネットワークに接続され
たノード、中継ノード（ネットワーク間接続装置）が、
このようなデータの識別子を含むメッセージ（例えば、
ＲＳＶＰのＰＡＨＴメッセージ）を受信した際、そのメ
ッセージが、例えば、前記データの送信のためのＲＳＶ
Ｐシグナリングメッセージであることを認識できるよう
になり、予約される通信資源と、前記データの受信を対
応づけできるようになる。

【００２２】また、例えば第１のネットワークから受信
したデータをフォーマット変換して第２のネットワーク
に転送するといった転送処理のトリがに前記識別子を用
いることも可能となる。

【００２３】なお、前記第１および第２の物理ネットワ
ークの少なくとも一方はＩＥＥＥ１３９４バスであり、
前記通信資源はＩＥＥＥ１３９４バスの同期チャネル番
号であってもよい。

【００２４】ＩＥＥＥ１３９４バスでは、ＩＥＣ１８８
３で定められる様に、ＭＰＥＧやＤＶフォーマットのデ
ータを１３９４バス上を伝送する際のパケットフォーマ
ットが細かく規定されている。例えば、ＡＴＭ網からＡ
ＴＭフォーラムのＭＰＥＧｏｖｅｒＡＴＭの規格により
伝送されてきたパケットをＩＥＥＥ１３９４バスに転送
する場合など、複数のネットワークをまたがってＩＰパ
ケットではないデータをＩＥＥＥ１３９４バスに転送す
る場合がある。このような場合、ＡＴＭ網とＩＥＥＥ１
３９４バスなど、複数のネットワークをまたがって通信
品質の確保を行った上で、上記フォーマット変換をした
上で転送することが求められる。上記のようにすること
によって、ＲＳＶＰで１３９４上の通信資源の確保を、
同期チャネルの確保という形で行うことができるように
なり、上記目的が達成される。

【００２５】（６、７、８）本発明の通信装置は、所
定のネットワークに接続された通信装置において、デー
タを送信あるいは受信する際の通信資源を確保するため
の論理ネットワーク上のメッセージを受信あるいは送信
する手段と、前記メッセージに、そのメッセージに基づ
き確保される通信資源を利用して転送されるデータが前
記論理ネットワーク上のデータでない旨の情報が含まれ
ているときは、前記確保された通信資源を介して受信あ
るいは送信されるデータに対する論理ネットワークのデ
ータ転送処理を省くことにより、例えば、ＩＰネットワ
ーク（論理ネットワーク）上のＩＰパケットではない情
報が転送される場合も、インターネットレイヤの既存の
シグナリングプロトコル（たとえばＲＳＶＰ）のメッセ
ージに、このメッセージに基づき確保される通信資源を
利用して送信されるデータがＩＰパケットでない旨の情
報を記述することにより、複数のネットワークが相互に
接続された環境において、通信資源の確保が容易に行
え、さらに、途中の中継ノード（ネットワーク間接続装
置）が前記通信資源（具体的には通信路）を通過するデ
ータがＩＰパケットではないと認識することが可能であ
ることから、中継ノードで通信資源の確保手順を終了さ
せることができず、エンド・エンドの確立確認が必要で
あるとの認識を各中継ノードが持つことができるように
なる。

【００２６】また、入出力されるデータが前記通信装置
内の通信路を通過する際に、前記データはＩＰパケット
ではないことから、このデータをＩＰ処理部に入力さ
せ、エラーですべてのデータが廃棄される、といった不
具合を未然に防止することが可能となる。

【００２７】また、前記メッセージは、そのメッセージ
に基づき確保される通信資源を利用して転送されるデー
タの識別子を含み、前記確保された通信資源は前記デー
タの識別子に対応付けられていることにより、例えば、
インターネット上の既存のシグナリングプロトコルであ
るＲＳＶＰのＰＡＴＨメッセージ中に前記データ（コン
テンツ情報）の識別子が含まれていれば、このメッセー
ジを受信した通信装置（受信端末）は、このＰＡＴＨメ
ッセージが前記データの転送のためのＲＳＶＰシグナリ
ングメッセージであることを認識できるようになり、予
約される通信資源と前記データの受信を対応つけること
ができるようになる。

【００２８】（９）本発明の通信方法（ネットワーク間
接続装置に適用される通信方法）は、複数の放送型ネッ
トワークを介してデータフローの送受信を行う複数の通
信装置のうちの少なくとも１つに向けて前記複数の放送
型ネットワークのそれぞれに同一識別子（仮想チャネル
識別子）の通信路を確立するため通知された、少なくと
も、前記識別子に対応させて前記複数の放送型ネットワ
ークのうちの１つに確立された第１の通信路と前記識別
子との対応関係を記憶手段（ブリッジ同期レジスタ）に
記憶し、前記識別子に対応させて前記複数の放送型ネッ
トワークのうちの他の１つに確立された第２の通信路を
用いて前記記憶しておいた対応関係に基づき前記複数の
放送型ネットワーク間でデータ転送を行うことを特徴と
する。

【００２９】本発明によれば、複数の放送型ネットワー
クをまたがった通信路（例えば、ＩＥＥＥ１３９４バス
におけるチャネル）を確立する際、その通信路に対し
て、該通信路の個別識別子（例えば、ＩＥＥＥ１３９４
のチャネル番号）とは別に、一貫した同一の識別子（仮
想チャネル識別子）をつけることで、送信端末、受信端
末、あるいは中継ノードであるブリッジ装置にて、当該
識別子でこの通信路を認識することが可能になる。これ
は、複数の放送型ネットワークのそれぞれに確立される
通信路の個別識別子（例えば、ＩＥＥＥ１３９４のチャ
ネル番号）がそれぞれ異なる場合に有益である。

【００３０】（１０）本発明の通信方法は（受信端末、
送信端末に適用される通信方法）、複数の放送型ネット
ワークを介してデータフローの送信あるいは受信を行う
際に、少なくとも予め指定された識別子（仮想チャネル
識別子）に対応させて前記複数の放送型ネットワークの
それぞれに確立された通信路のうちの１つと、前記複数
の放送型ネットワークのそれぞれに確立された通信路を
用いて送信あるいは受信される前記データフローの属性
情報との対応関係とを記憶手段（ブリッジ同期レジス
タ、レイヤ３フローレジスタ）に記憶し、前記記憶して
おいた対応関係に基づき、前記データフローを送信ある
いは受信することを特徴とする。

【００３１】本発明によれば、１つの識別子（仮想チャ
ネル識別子）に対応させて複数の放送型ネットワークの
それぞれに確立された通信路（例えば、ＩＥＥＥ１３９
４バスにおけるチャネル）を用いてデータフローが転送
されてくるので、複数のネットワークにまたがっての受
信端末と送信端末との間での通信が行われる場合、この
識別子を使って両端末間でこの通信路を共通して認識す
ることが可能となる。

【００３２】（１１）本発明のネットワーク間接続装置
は、第１の放送型ネットワークと第２の放送型ネットワ
ークに接続されたネットワーク間接続装置であって、複
数の放送型ネットワークを介してデータフローの送受信
を行う複数の通信装置のうちの少なくとも１つに向けて
前記複数の放送型ネットワークのそれぞれに同一識別子
（仮想チャネル識別子）の通信路を確立するため、前記
第１の放送型ネットワークを介して通知された、少なく
とも、前記識別子に対応させて前記第１の放送型ネット
ワークに確立された第１の通信路と前記識別子との対応
関係を記憶する記憶手段（ブリッジ同期レジスタ）と、
前記識別子に対応させて前記第２の放送型ネットワーク
に確立された第２の通信路を用いて、少なくとも前記複
数の通信装置のうちの１つのアドレスと前記識別子と前
記第２の通信路との対応関係を通知する通知手段と、前
記記憶手段に記憶された対応関係に基づき前記第１の放
送型ネットワークに確立された第１の通信路を用いて送
信されてきたデータを、前記第２の放送型ネットワーク
に確立された前記第２の通信路に転送する転送手段（ブ
リッジ対応テーブル、転送部）と、を具備したことを特
徴とする。

【００３３】本発明によれば、複数の放送型ネットワー
クをまたがった通信路（例えば、ＩＥＥＥ１３９４バス
におけるチャネル）を確立することができ、その通信路
に対して、一貫した同一の識別子（仮想チャネル識別
子）をつけることで、送信端末、受信端末、あるいは中
継ノードであるブリッジ装置にて、当該識別子でこの通
信路を認識することが可能になる。これは、複数の放送
型ネットワークのそれぞれに確立される通信路の個別識
別子（例えば、ＩＥＥＥ１３９４のチャネル番号）がそ
れぞれ異なる場合に有益である。

【００３４】（１２）本発明の通信装置は、複数の放送
型ネットワークを介してデータフローの送信あるいは受
信を行う相手通信装置に向けて前記複数の放送型ネット
ワークのそれぞれに同一識別子（仮想チャネル識別子）
の通信路を確立するため、少なくとも、相手通信装置の
アドレスと前記識別子に対応させて前記複数の放送型ネ
ットワークのうちの１つに確立された通信路と前記識別
子との対応関係とを前記第１の通信路を用いて通知する
第１の通知手段と、この第１の通知手段で通知された内
容に基づき前記複数の放送型ネットワークのそれぞれに
確立された通信路を用いて送信あるいは受信される前記
データフローの属性情報と前記識別子との対応関係を前
記相手通信装置に通知する第２の通知手段と、を具備
し、前記データフローを前記第１および第２の通信手段
で通知した対応関係に基づき送信あるいは受信すること
を特徴とする。

【００３５】本発明によれば、複数の放送型ネットワー
クをまたがった通信路（例えば、ＩＥＥＥ１３９４バス
におけるチャネル）を確立することができ、その通信路
に対して、一貫した同一の識別子（仮想チャネル識別
子）をつけることで、送信端末、受信端末、あるいは中
継ノードであるブリッジ装置にて、当該識別子でこの通
信路を認識することが可能になる。１つの識別子（仮想
チャネル識別子）に対応させて複数のネットワークのそ
れぞれに確立された通信路（例えば、ＩＥＥＥ１３９４
バスにおけるチャネル）を用いてデータフローが転送さ
れてくるので、複数のネットワークにまたがっての通信
装置間（受信端末と送信端末との間）での通信が行われ
る場合、この識別子を使って両端末間でこの通信路を共
通して認識することが可能となる。

【００３６】（１３）本発明の通信装置は、複数の放送
型ネットワークを介してネットワークレイヤデータフロ
ーの送信あるいは受信を行うため通知された、少なくと
も、前記複数の放送型ネットワークのそれぞれに確立さ
れた同一識別子（仮想チャネル識別子）の通信路のうち
の１つと前記複数の放送型ネットワークのそれぞれに確
立された通信路を用いて送信あるいは受信される前記デ
ータフローの属性情報との対応関係を記憶する記憶手段
（ブリッジ同期レジスタ、レイヤ３フローレジスタ）を
具備し、前記記憶手段に記憶された対応関係に基づき前
記ネットワークレイヤデータフローを送信あるいは受信
することを特徴とする。

【００３７】本発明によれば、１つの識別子（仮想チャ
ネル識別子）に対応させて複数の放送型ネットワークの
それぞれに確立された通信路（例えば、ＩＥＥＥ１３９
４バスにおけるチャネル）を用いてデータフローが転送
されてくるので、マルチメディアキャストを含む複数の
ネットワークにまたがっての通信装置間（受信端末と送
信端末との間）での通信が可能となる。

【００３８】

【発明の実施の形態】以下、本発明の実施形態について
図面を参照して説明する。

【００３９】（第１の実施形態）図１は、本発明の第１
の実施形態に係るネットワーク全体の構成例を示したも
ので、ここでは、一例として家庭内に構築されるネット
ワークの構成例を示している。

【００４０】図１において、第１の家庭内ネットワーク
１０２および第２のネットワーク１０４は、ＩＥＥＥ１
３９４ネットワークであり、第３のネットワーク１０６
はイーサネットである。第１のネットワーク１０２と第
２の家庭内ネットワーク１０４と第３の家庭内ネットワ
ーク１０６は接続装置１０３にて相互接続されている。

【００４１】第１のネットワーク１０２には、デジタル
衛星放送のセットトップボックス（ＳＴＢ）１０１が接
続されており、専用アンテナ１１０から同軸ケーブルを
通して信号が入力されている。そのほか、このセットト
ップボックス１０１には、衛星サービス会社あるいはセ
ットトップボックスベンダ独自のネットワークインタフ
ェースを有していても良い。

【００４２】このように相互接続された環境において、
インターネットパケットではないトラヒック（本実施形
態の場合、衛星放送の受信データ）の配送をどのように
制御するかについて説明する。

【００４３】図２７は、図１の接続装置１０３の構成例
を示したもので、ＩＥＥＥ１３９４バス（本実施形態の
場合、第１のネットワーク１０２、第２のネットワーク
１０４）の接続ポート毎に設けられるＩＥＥＥ１３９４
の予め定められたプロトコル処理を実行する１ＥＥＥ１
３９４インタフェース（Ｉ／Ｆ）部５０１と、イーサネ
ット（本実施形態の場合、第３のネットワーク１０６）
の接続ポートに設けられるイーサネットインタフェース
（Ｉ／Ｆ）部５０６、所定のメモリ領域に記憶されたブ
リッジ対応テーブル５０３を参照して一方のＩＥＥＥ１
３９４バスから他方のＩＥＥＥ１３９４バスへのデータ
のフィルタリング及び転送を行う転送部５０２、第１の
ネットワーク１０２に確立されたチャネルと第２のネッ
トワーク１０４に確立されたチャンネルとの対応関係を
記憶するチャネル対応テーブル５０４と、ＦＡＮＰ、Ｒ
ＳＶＰ等の所定の転送プロトコル処理を実行する転送処
理部５０５とから構成される。

【００４４】１ＥＥＥ１３９４Ｉ／Ｆ部５０１は、ＩＥ
ＥＥ１３９４の物理層、リンク層、トランザクション層
の各レイヤにおける予め定められた処理を実行するよう
になっている。

【００４５】ブリッジ対応テーブル５０３は、少なくと
も、第１の１３９４バス１０２および第２の１３９４バ
ス１０４のそれぞれに接続されている端末および他の１
３９４ブリッジのＥＵＩ６４アドレス、ノードＩＤ（バ
スリセットにより再設定されるもの）が記憶されてい
る。

【００４６】図２８は、第１の端末１０５の構成例を示
したもので、ＩＥＥＥ１３９４の予め定められたプロト
コル処理を実行する１ＥＥＥ１３９４インタフェース
（Ｉ／Ｆ）部６０１、ＩＰ処理部６０２、上位レイヤ処
理部６０３から構成される。

【００４７】１ＥＥＥ１３９４Ｉ／Ｆ部６０１は、ＩＥ
ＥＥ１３９４の物理層、リンク層、トランザクション層
の各レイヤにおける予め定められた処理を実行するよう
になっている。

【００４８】ＩＰ処理部６０２は、ＦＡＮＰ、ＲＳＶＰ
等を含む予め定められたＩＰ処理を実行するようになっ
ている。

【００４９】上位レイヤ処理部６０３は、例えば、第１
の端末１０５から相手端末（例えばＳＴＢ１０１）との
間でデータの送受信要求のためのプロトコル処理、相手
端末から送信されてきたデータに対する所定のサービス
処理等を実行するものである。

【００５０】（Ａ）まず、第２のネットワーク１０４
に接続された第１の端末１０５がＳＴＢ１０１、第１の
ネットワーク１０２、接続装置（１３９４ブリッジ）１
０３を介して、ＩＥＥＥ１３９４用に構築されたプロト
コルを用いて通信（第１の端末１０５における衛星放送
からのデータ／映像の受信）を行う場合について説明す
る。

【００５１】図２は全体の処理シーケンスを示し、図３
はＩＥＥＥ１３９４ブリッジである接続装置１０３の処
理シーケンスを図２に対応させて示している。以下、図
２、図３を参照して説明する。

【００５２】第１の端末１０５は、上位レイヤ処理部６
０３およびＩＰ処理部６０２およびＩＥＥＥ１３９４Ｉ
／Ｆ部６０１の処理として、ＩＥＥＥ１３９４の非同期
モードの転送フレームを使って、セットトップボックス
１０１に対して、決められたＴＶチャンネルの転送要求
を行う（ステップＳ２０１、Ｓ２０２）。

【００５３】この転送要求のためのプロトコルは、ＤＡ
ＶＩＣ（ＤｉｇｉｔａｌＡｕｄｉｏ−Ｖｉｓｕａｌ
Ｃｏｕｎｃｉｌ）のＤＳＭ−ＣＣあるいはこれに準ずる
手続きを用いてもよいし、ＷｅｂライクなＧＵＩとＲＴ
ＳＰやＨＴＴＰ等のプロトコルを用いてこれを行っても
良いし、独自プロトコルを用いても良い。なお、本実施
形態では、ＩＥＥＥ１３９４にて規定されているＡＶ／
Ｃプロトコル（ＤｉｇｉｔａｌＩｎｔｅｒｆａｃｅ
ｆｏｒＣｏｎｓｕｍｅｒＥｌｅｃｔｒｏｎｉｃＡ
ｕｄｉｏ／ＶｉｄｅｏＥｑｕｉｐｍｅｎｔ）を用いる
ものとする。即ち、あらかじめ第１の端末１０５とセッ
トトップボックス１０１に、このプロトコルがインスト
ールされており、両者ともお互いのＩＥＥＥ１３９４ア
ドレスを認識しているものとする。

【００５４】さて、番組を要求されたセットトップボッ
クス１０１は、セットトップボックス１０１から端末１
０５までの間の通信資源の確保と、使用するチャンネル
などの端末への通知等の手続きを行う必要がある。

【００５５】ＳＴＢ１０１と端末１０５が同一のＩＥＥ
Ｅ１３９４に接続されている場合、通信資源の確保はＳ
ＴＢ１０１がＩＥＥＥ１３９４上の同期リソースマネー
ジャへのレジスタアクセスにて、その確保された通信資
源の端末への通知はＩＥＣ１８３３プロトコルによりこ
れが行われるのが通常である。

【００５６】本実施形態では、接続装置（１３９４ブリ
ッジ）１０３を介して、ＩＥＥＥ１３９４がブリッジ接
続されているため、以下のような方法で、これらが実現
される。

【００５７】まず、ＳＴＢ１０１は第１のネットワーク
１０２のＩＥＥＥ１３９４の同期リソースマネージャの
レジスタにアクセスし、帯域とチャネル番号の確保を行
う（ステップＳ２０３）。

【００５８】次に、第１の端末１０５の（バスＩＤ、ノ
ードＩＤ）＝（２、Ｘ）とすると、これに対して、複数
のＩＥＥＥ１３９４ネットワークをまたがる通信資源制
御のためのメッセージを送出する（ステップＳ２０
４）。このメッセージには、該制御メッセージである
旨、宛先端末１０５の物理ＩＤ（２、Ｘ）、使用帯域、
第１のネットワーク（ＩＥＥＥ１３９４ネットワーク）
１０２にて使用するチャネル番号等の情報が含まれる。

【００５９】このメッセージは、特願第８−２６４４９
６号（本発明の発明者による）に記載されているＦＡＮ
Ｐの拡張のプロトコルにて定められたものであっても良
い。なお、ステップＳ２０４におけるプロトコルは、図
中、同期チャネルブリッジ間獲得プロトコルと記述して
いる。

【００６０】また、接続装置１０３のＩＥＥＥ１３９４
Ｉ／Ｆ部（＃１）５０１内の特定のレジスタに対して、
上記の情報（宛先端末のＩＤ、使用帯域、第１のネット
ワークにて使用するチャネル番号等) を書き込むような
形にして、これを実現してもよい。

【００６１】さらに、インターネットプロトコルのＲＳ
ＶＰ（ＲｅｓｏｕｒｃｅＲｅｓｅｒｖａｔｉｏｎＰ
ｒｏｔｏｃｏｌ）／ＳＢＭ（ＳｕｂｎｅｔＢａｎｄｗ
ｉｄｔｈＭａｎａｇｅｒ）を用いた方式をもちいて、
これを行うこともできる。これについては、第２の実施
形態において説明する。

【００６２】本実施形態では、ＩＥＥＥ１３９４を家庭
内ネットワークとして用いていることから、基本的には
上記メッセージは、ＩＥＥＥ１３９４バスの非同期パケ
ットの形で転送される。が、家庭内ネットワークがＵＳ
Ｂ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）であ
る場合には、これらのメッセージは、割り込み転送、あ
るいは制御転送の形で、デフォルトパイプを転送され
る、といった形式であってもよい。

【００６３】通信資源獲得のためのメッセージを受信し
た接続装置（１３９４ブリッジ）１０３のＩＥＥＥ１３
９４Ｉ／Ｆ部（＃１）５０１は、その中に含まれる宛先
端末のＩＤを参照し、そのバスＩＤの値から、宛先端末
が第２のネットワーク（ＩＥＥＥ１３９４）１０４上の
端末への通信資源確保要求であることを認識し、該ブリ
ッジ１０３内部の通信資源（バッファなど）を確保した
後（ステップＳ２０５）、第２のネットワーク（ＩＥＥ
Ｅ１３９４）１０４上の同期リソースマネージャに帯
域、チャネル番号の確保を働きかける（ステップＳ２０
６）。

【００６４】確保が成功すると（ステップＳ２０７）、
送信者であるセットトップボックス１０１に、第２のネ
ットワーク１０４上の通信資源が確保された旨を通知す
るメッセージ（ＡＣＫ）を送信する。このＡＣＫの送信
は、必ずしも受信端末である第１の端末１０５が行う必
要は必ずしも無く、接続装置１０３が行えばよいもので
ある。その詳細は、例えば先に紹介した特願平第８−２
６４４９６号を参照されたい。

【００６５】第２のネットワーク１０４上に通信資源
（同期チャネル＃Ｙ）が確保されると、図４に示すよう
に、チャネル対応テーブル５０４に第１のネットワーク
１０２に確保された同期チャネル番号＃Ｘと、第２のネ
ットワーク１０４に確保された同期チャネル番号＃Ｙと
の対応関係が記憶される。

【００６６】ＳＴＢ１０１は、第１の端末１０５までの
通信経路が確保されたことを前記ＡＣＫ等により確認す
ると、続いて第１の端末１０５に対して、確保した同期
チャネルを通してＭＰＥＧデータ／映像の送信を開始す
ることを通知する必要がある。一般にそのためのプロト
コルとして、ＩＥＥＥ１３９４にて規定されているＩＥ
Ｃ１８８３が用いられる（ステップＳ２０８）。そのた
め、ＳＴＢ１０１は第１の端末１０５のＩＥＥＥ１３９
４Ｉ／Ｆ部６０１に設けられている物理ＩＤ＝（２、
Ｘ）のＰＣＲ（プラグ制御レジスタ）に対して、どれだ
けの帯域を使って送信するか等についてのデータを書き
込もうとする。具体的には、ＰＣＲに対して、（１）オンラインかオフラインか（２）ブロードキャストが存在しているか否か（３）ポイントポイントの通信が存在しているか否か（４）同期チャネル番号（５）データレート（帯域）等が書き込まれる。

【００６７】ここで、第１のネットワーク１０２と第２
のネットワーク１０４とでは、使用される同期チャネル
番号が異なる可能性がある。例えば、図２のように、第
１のネットワーク１０２においては同期チャネル番号＃
Ｘが、第２のネットワーク１０４においては同期チャネ
ル番号＃Ｙが使われるものとすると、ＳＴＢ１０１は、
第１の端末１０５のＰＣＲに対して、「同期チャネル番
号＃Ｘを用いて通信を行う」という旨の書込を行うこと
になる。

【００６８】ところが、第２のネットワーク１０４にお
いては、同期チャネル＃Ｙが該通信のために予約された
ものとなっているため、不具合が発生する。

【００６９】このため、本実施形態の接続装置１０３で
は、通過するＩＥＣ１８３３のメッセージを検出し、チ
ャネル対応テーブル５０４を参照して、適切なパラメー
タの修正を加えた上で、内部に状態を保持し、このＩＥ
Ｃ１８８３メッセージを該当するネットワーク側へとフ
ォワーディングする。

【００７０】ここで、接続装置１０３においては、通過
するメッセージがＩＥＣ１８８３のメッセージであるこ
とを認識する必要がある。これを実現する方法として、
例えば以下のような方法がある。

【００７１】１）ＩＥＣ１８８３によれば、各端末に
おいてＩｓｏｃｈｒｏｎｏｕｓ（アイソクロナス）デー
タの転送制御を行なうために、各端末のＣＳＲ（Ｃｏｎ
ｔｒｏｌａｎｄＳｔａｔｕｓＲｅｇｉｓｔｅｒ）
内に存在する入力マスタプラグレジスタ（ＩＮＰＵＴ
ＭＡＳＴＥＲＰＬＵＧｒｅｇｉｓｔｅｒ）、出力マス
タプラグレジスタ（ＯＵＴＰＵＴＭＡＳＴＥＲＰＬ
ＵＧｒｅｇｉｓｔｅｒ）、入力プラグ制御レジスタ
（ＩＮＰＵＴＰＬＵＧＣＯＮＴＲＯＬｒｅｇｉｓ
ｔｅｒ）、出力プラグ制御レジスタ（ＯＵＴＰＵＴＰ
ＬＵＧＣＯＮＴＲＯＬｒｅｇｉｓｔｅｒ）の４つの
レジスタを用いることになっている。また、これら４つ
のレジスタにはＣＳＲ内の特定の（規定された）アドレ
スが割り当てられている。

【００７２】よって、接続装置１０３において、受信し
たアシンクロナスパケットがＬｏｃｋ．Ｒｅｑｕｅｓｔ
パケット（ＩＥＥＥ１３９４Ｓｐｅｃｉｆｉｃａｔｉ
ｏｎにて規定される１３９４バス上の帯域とチャネル番
号の獲得要求パケット）であった場合に、その受信した
アシンクロナスパケットのパケット特定情報（オフセッ
ト値）を見て、そのオフセット値が各端末のＣＳＲ内で
の入力マスタプラグレジスタ、出力マスタプラグレジス
タ、入力プラグ制御レジスタ、出力プラグ制御レジスタ
の４つのレジスタに割り当てられているオフセット値で
あった場合に、その受信したパケットがＩＥＣ１８８３
プロトコルによるものであると認識する。

【００７３】２）アシンクロナスパケット中に割り当
てられているｔ−Ｃｏｄｅを用いて識別する。具体的に
は、あらかじめ、ｔ−Ｃｏｄｅによるパケット種別にお
いてユーザーが定義できる値を定義しておき、その定義
された値のｔ−Ｃｏｄｅを持ったアシンクロナスパケッ
ト、特に、Ｌｏｃｋ．Ｒｅｑｕｅｓｔパケットを受信し
た場合に、その受信したパケットがＩＥＣ１８８３プロ
トコルによるものであると認識する。

【００７４】３）Ａｓｙｎｃｈｒｎｏｕｓパケットの
データフィールドまで読んで、その内容がＩＥＣ１８８
３によって規定されている内容であれば、その受信した
パケットがＩＥＣ１８８３プロトコルによるものである
と認識する。いわゆるゲートウェイ処理を実行する方
法。

【００７５】４）接続装置が必ずアイソクロナスリ
ソースマネージャになるように自動構成認識処理を実
行し、接続装置１０３が属しているＩＥＥＥ１３９４ネ
ットワーク内での帯域／チャネル番号の設定要求パケッ
トを全て記憶し、その後に、その帯域／チャネル番号の
設定要求を行なった端末から送られてきたパケット、特
にＬｏｃｋ．Ｒｅｑｕｅｓｔパケットの宛先端末の物理
ＩＤが、自１３９４ネットワークに属する端末以外の物
理ＩＤであった場合に、その受信したパケットがＩＥＣ
１８８３プロトコルによるものであると認識する。

【００７６】５）上記１）〜４）の方法の任意の組合
せ。

【００７７】接続装置１０３のＩＥＥＥ１３９４Ｉ／Ｆ
部（＃１）５０１は、例えば上記のような方法を用い
て、通過するＩＥＣ１８８３メッセージを監視してお
り、これが複数の１３９４をまたがると認識すると、内
部に状態を作る（ステップＳ２０９）。即ち、接続装置
１０３の片側の入力側ともう片側の出力側で、チャネル
番号は変更されており（具体的には第１のネットワーク
１０２では＃Ｘ、第２のネットワーク１０４では＃
Ｙ）、転送部５０２は、これを図４に示したようなチャ
ネル対応テーブル５０４を参照して変換した上で、ＩＥ
ＥＥ１３９４Ｉ／Ｆ部（＃２）５０１を介して、第１の
端末１０５にＩＥＣ１８８３メッセージを伝達する。

【００７８】これをより詳細に説明すると、接続装置１
０３は、先の帯域予約の際にチャネル対応テーブル５０
４に記憶してた入力チャネル番号と出力チャネル番号と
の対応関係を用いて、次段（本実施形態の場合第２のネ
ットワーク１０４）のチャネル番号を知る。

【００７９】接続装置１０３内のチャネル対応テーブル
５０４は、図４に示すように、入力チャネル番号、出力
チャネル番号、帯域、その他１８８３のメッセージフィ
ールドにある値を内部状態として保持するものである。

【００８０】そうした上で、ＩＥＣ１８８３メッセージ
を、入力側の同期チャネル番号＃Ｘから、出力側の同期
チャネル番号＃Ｙに値を直した上で、ＩＥＣ１８８３メ
ッセージを送出する（ステップＳ２１０）。

【００８１】このように、接続装置１０３は、フレーム
の転送の他に、以上のような状態を伴う処理が行われる
ため、送信者（この場合ＳＴＢ１０１）への応答（ＡＣ
Ｋ−Ｃｏｍｐｌｅｔｅ）を即座に返すことはできない。
このため、接続装置１０３は、送信者に対して、ＡＣＫ
−Ｃｏｍｐｌｅｔｅメッセージの送出を遅らせるなり
（Ｐｅｎｄｉｎｇパケットを使うなど）の方法を用いて
も良い。

【００８２】また、ＩＥＣ１８８３に明示的にＡＣＫを
要求するフィールドを設けるなどして、即座の応答が返
せないこと（ＩＥＥＥ１８８３メッセージが複数ネット
ワークを往来する必要があること）を送信者（この場合
ＳＴＢ１０１）がＩＥＣ１８８３メッセージ中に明示す
る方法もある。

【００８３】最終的に、送信者にＩＥＣ１８８３メッセ
ージのＡＣＫ−Ｃｏｍｐｌｅｔｅが返るなり、ＩＥＣ１
８８３のＡＣＫが返るなりしたならば、送信者のＳＴＢ
１０１はＭＰＥＧ映像等の伝送を開始する（ステップＳ
２１１、Ｓ２１２）。

【００８４】以上の説明は、家庭内ネットワークがＩＥ
ＥＥ１３９４である場合を例としてきたが、その他のデ
ータリンク技術、例えばＵＳＢ等でも同様の議論をする
ことができる。この場合、本実施形態のＩＥＥＥ１３９
４の非同期チャネルと同期チャネルがそれぞれＵＳＢの
デフォルトパイプと一般のパイプに対応し、同期チャン
ネル番号は、パイプ番号に対応することとなる。

【００８５】（Ｂ）上記（Ａ）の説明は、送信者のＳ
ＴＢ１０１が、受信端末１０５は異なるネットワーク
（ＩＥＥＥ１３９４バス）の上に位置していることを認
識しており、ＩＥＣ１８８３にてデータ送信に用いる同
期チャネル番号等の情報を端末に通知する前に、自ら前
記ＦＡＮＰ等の通信資源獲得プロトコルを用いて、ＳＴ
Ｂ１０１と端末間１０５の帯域とチャネル番号の確保を
行うものであった。

【００８６】これに対し、送信者のＳＴＢ１０１は相手
端末がどこのＩＥＥＥ１３９４バスに接続されていよう
と、（即ち、ローカルな１３９４であろうと、リモート
の１３９４であろうと）変わらずに処理を行い、接続装
置１０３がこれを吸収する方法も考えられる。

【００８７】この方法では、上記エンドエンドの通信資
源獲得を、ＩＥＣ１８８３プロトコルを用いて行う。こ
の場合について図５に示す処理シーケンスを参照して説
明する。

【００８８】第１の端末１０５の上位レイヤ処理部６０
３がＳＴＢ１０１に対し、上位レイヤプロトコルを用い
て、番組要求をし（ステップＳ５０１、Ｓ５０２）、Ｓ
ＴＢ１０１が第１のネットワーク（ＩＥＥＥ１３９４）
１０２の同期リソースマネージャに帯域と同期チャネル
番号の確保を行ったなら（ステップＳ５０３、ここで同
期チャネル番号＃Ｘを確保したとする）、ＳＴＢ１０１
は第１のネットワーク１０２に端末１０５が存在する場
合と同様に、ＩＥＥＥ１３９４の非同期パケットを用い
て、相手端末である第１の端末１０５のＰＣＲ（プラグ
制御レジスタ）に直接ＩＥＣ１８８３を用いて、値を書
き込もうとする。これが、接続装置１０３について、電
話通信の呼設定の役割を果たす。

【００８９】接続装置１０３の処理シーケンスを図６に
示す。以下、図５および図６を参照しながら説明する。

【００９０】接続装置１０３は、例えば前述の接続装置
におけるＩＥＣ１８８３メッセージ検出方法を用いて、
これを監視している。このＩＥＣ１８８３メッセージを
受信した接続装置１０３は、受信メッセージがＩＥＣ１
８８３プロトコルのメッセージであり、その宛先が、受
信した１３９４バスとは異なる、接続装置がそのパケッ
トの配送／ルーチングを受け持つ１３９４バス（本実施
形態では第２のネットワーク（ＩＥＥＥ１３９４）１０
４）上の装置（本実施形態では第１の端末１０５）であ
る場合は、現在ローカルなＩＥＥＥ１３９４に予約され
ている帯域付きの同期チャネル（＃Ｘ）を、ＩＥＣ１８
８３メッセージの宛先である、宛先端末１０５が接続さ
れたＩＥＥＥ１３９４バス上まで、通信資源の確保を行
うことが望ましいと判断する（図６のステップＳ６０
２）。

【００９１】その間、送信者のＳＴＢ１０１へのＡＣＫ
−Ｃｏｍｐｌｅｔｅの送信は引き延ばしておいてもよ
い。

【００９２】例えば、接続装置１０３からの帯域確保要
求は失敗する可能性があり、その場合はＡＣＫ−Ｃｏｍ
ｐｌｅｔｅは合わない。よって、接続装置１０３は、受
信端末となる第１の端末１０５が接続された第２のネッ
トワーク（ＩＥＥＥ１３９４）１０４上の同期リソース
マネージャに対して、ＩＥＣ１８８３に示された帯域を
確保し、更に同期チャネル番号をも確保する（図５のス
テップＳ５０６）。ここでは、第２のネットワーク１０
４上に確保された同期チャネルの番号が＃Ｙであるもの
とする（図６のステップＳ６０３）。

【００９３】次に、同期チャネル＃Ｘと＃Ｙとの対応づ
けを行う図４に示したようなチャネル対応テーブル５０
４を作成する（図６のステップＳ６０４）。

【００９４】これらが完了した後、受信端末である第１
の端末１０５方向へのＩＥＣ１８８３メッセージのフォ
ワーディングを行う。この際は、新たに確保した同期チ
ャネル番号の値をこの書き込みに反映させるべく、第１
のネットワーク１０２での同期チャネル番号＃Ｘに対応
した同期チャネル番号の値＃Ｙを第１の端末１０５のＰ
ＣＲに記入することになる（図６のステップＳ６０
５）。

【００９５】これが第１の端末１０５に書き込まれ、Ａ
ＣＫ−Ｃｏｍｐｌｅｔｅが返されてきたなら、接続装置
１０３は、先ほどペンディングとしておいたＩＥＣ１８
８３のＬｏｃｋ．ＲｅｑｕｅｓｔパケットにＡｃｋ−Ｃ
ｏｍｐｌｅｔｅを返してもよいし、ＩＥＣ１８８３に含
まれるＡＣＫを返しても良い（図５のステップＳ５０
８）。

【００９６】こうして、ＳＴＢ１０１は、確保された同
期チャネル＃Ｘ、＃Ｙを通して、ＭＰＥＧデータ／映像
等の伝送を行うことになる（ステップＳ５０９、Ｓ５１
０）。この際、接続装置１０３は、上記２つの同期チャ
ネル間のデータフォワーディングを行うことになる。

【００９７】以上の説明は、家庭内ネットワークがＩＥ
ＥＥ１３９４である場合を例としてきたが、その他のデ
ータリンク技術、例えばＵＳＢ等でも同様の議論をする
ことができる。この場合、本実施形態のＩＥＥＥ１３９
４の非同期チャネルと同期チャネルがそれぞれＵＳＢの
デフォルトパイプと一般のパイプに対応し、同期チャン
ネル番号は、パイプ番号に対応することとなる。

【００９８】（第２の実施形態）次に、接続装置１０３
をまたがる帯域の予約に、ＩＥＴＦで議論されているＲ
ＳＶＰ／ＳＢＭを用いる場合を説明する。

【００９９】図１のＳＴＢ１０１を通してのデジタル衛
星放送からのデータは、ＭＰＥＧのデータ／映像がその
まま伝送されているものとする。これをＳＴＢ１０１か
ら端末１０５に転送するに際し、ＭＰＥＧフレームをＩ
Ｐパケットにカプセル化し、これを転送してもよいが、
カプセル化のためのオーバヘッドがかかることや、受信
端末１０５がＩＰ端末では必ずしも無いことから、従来
の１３９４ＡＶ機器と同様に、一般に「ＭＰＥＧｏｖｅ
ｒ１３９４」と言われるフォーマット（具体的にはＩＥ
Ｃ１８８３にて規定されているフォーマット）にて、Ｍ
ＰＥＧデータ／映像を１３９４上をそのまま流通させる
ことが望ましい場合がある。これは、何も家庭内ネット
ワーク内に限定されず、例えばＣＡＴＶ局からの情報伝
送を、ＭＰＥＧデータ／映像をそのままＣＡＴＶ局から
ＨＦＣ（ＨｙｂｒｉｄＦｉｂｅｒＣｏａｘ）やＦＴ
ＴＨ（ＦｉｂｅｒＴｏＴｈｅＨｏｍｅ）等を通っ
て、家庭まで流通させる場合にも、ＭＰＥＧデータ／映
像の直接伝送が求められる場合があろう。

【０１００】そこで、第２の実施形態では、伝送するデ
ータ（いわゆるＵプレーンのデータ）はＩＰパケットで
はないが、その通信資源の予約にはＲＳＶＰ／ＳＢＭを
用いる場合について説明する。

【０１０１】第２の実施形態に係るネットワーク全体の
構成例は図１とほぼ同様である。差分は、帯域予約等に
ＲＳＶＰ／ＳＢＭを使う点である。また、第２の実施形
態においては、接続装置１０３はＳＢＭノードである。
よって、接続装置１０３はＩＰ処理やＲＳＶＰ／ＳＢＭ
処理機能を有する。これらの処理機能は図２７の天昇処
理部５０５に含まれているとする。

【０１０２】これを実現するには、通信資源である１３
９４の同期チャネルの予約を、下流側のノードが行う方
法と、上流側のノードが行う方法とがある。各々につい
て説明する。

【０１０３】まず、通信資源である１３９４の同期チャ
ネルの予約を上流側のノードが行う方法について説明す
る。全体の処理シーケンスを図７に示す。

【０１０４】第１の実施形態にて説明した、上位レイヤ
プロトコル等を使って、端末１０５はＳＴＢ１０１にデ
ータ配信依頼を行う（ステップＳ１２０１、Ｓ１２０
２）。

【０１０５】このプロトコルのやりとりの時点で、端末
１０５はＳＴＢ１０１から配信されるデータ（ＭＰＥＧ
データ／映像など）がＩＰパケットにカプセル化されな
いことを認識しても良い。この時、後にやり取りされる
通信資源の確保の手順において、どの上位プロトコルと
対応するかを送信ノード（本実施形態の場合ＳＴＢ１０
１）が認識するために、認識ＩＤ（図中では「α」で表
している) を付与して、このやり取りを行ってもよい。

【０１０６】このデータ配信依頼に呼応して、ＳＴＢ１
０１は経路の通信資源の確保のために、ＲＳＶＰのＰＡ
ＴＨメッセージを端末に向かって流しはじめる（Ｓ１２
０３）。

【０１０７】ここで、ＰＡＴＨメッセージには、これか
ら送信するコンテンツ（この場合ＭＰＥＧデータ／映
像）が、ＩＰパケットにカプセル化されず、いわば「非
ＩＰのデータ転送ためのシグナリングである」旨のフラ
グが示される。これにより、ＰＡＴＨステートを作成す
る中間ノード（本実施形態では接続装置１０３）は、こ
れから予約される可能性のあるこのフローは、ＩＰパケ
ットではないため、ＩＰ処理部にてこれらのパケットの
ハンドリングは行わず、データリンクレイヤの処理のみ
で、中間ノードをスルーするような形の処理を行う必要
があることを認識する。

【０１０８】このＰＡＴＨメッセージには、先の送信要
求の際に付与した認識ＩＤ（「α」）がついてもよい。
これにより、端末１０５は、先に要求した送信要求に対
応するＰＡＴＨメッセージであることを認識することが
できる。

【０１０９】また、このＰＡＴＨメッセージには、上位
レイヤに乗せられるデータに関する情報も同時に運ばれ
てもよい。本実施形態の場合は、予約される通信資源で
伝達される情報が、ＭＰＥＧデータ／映像である旨がＰ
ＡＴＨメッセージに記述されていてもよい。この場合
は、ＲＳＶＰのメッセージの中で、エンドエンドのユー
ザ間で伝達される情報のフィールドにこの情報を記述す
ればよい。

【０１１０】接続装置１０３は、このＰＡＴＨメッセー
ジをＰＡＴＨステート確立後に第１の端末方向にフォワ
ードする（ステップＳ１２０４）。

【０１１１】ＰＡＴＨメッセージを受信した端末１０５
は、通信資源の確保を行うため、上流方向にＲＥＳＶメ
ッセージを送出する（ステップＳ１２０５）。このＲＥ
ＳＶメッセージにも、ＰＡＴＨメッセージと同様の「非
ＩＰのためのシグナリングである」ことを意味するフラ
グが立っていてもよい。また、認識ＩＤ（「α」）を含
む形であってもよい。

【０１１２】これを受信した接続装置１０３は、ＲＥＳ
Ｖメッセージに含まれるトラヒック特性に応じた帯域を
もつ同期チャネルを、第２のネットワーク１０４上に獲
得する（ステップＳ１２０６）。すなわち、図７に示す
シーケンスの様に、下流側（接続装置１０３と端末１０
５間）、接続装置１０３内部の通信資源の確保を行う。
これが成功し、同期チャネル（チャネル番号＃Ｙ）が獲
得できると、その後、ＲＥＳＶの上流側へのフォワーデ
ィングを行っていく（ステップＳ１２０７）。

【０１１３】その際、接続装置１０３は、この同期チャ
ネルと認識ＩＤとの対を、例えばチャネル対応テーブル
５０４に記憶しておく。

【０１１４】ＲＥＳＶを受信したＳＴＢ１０１は、接続
装置１０３と同様に、第１のネットワーク１０２上に同
期チャネルの予約を行う（ステップＳ１２０８）。ここ
で獲得できた同期チャネルのチャネル番号を「＃Ｘ」と
する。

【０１１５】これで、ＳＴＢ１０１から接続装置１０３
を経て、第１の端末１０５までエンドエンドに必要な通
信資源が確保できたことになる。

【０１１６】次に、途中ノードの接続装置１０３および
第１の端末１０５に、これら確保された通信資源の関係
づけと、伝達されるデータの通知のための手続きに入
る。なお、この手続きは、各段における同期チャネルの
予約成功の直後に行ってもよい。これを実現する方法に
は、いくつかのものが考えられる。

【０１１７】第１の方法は、ＰＡＴＨメッセージを通じ
て通知する方法である。資源が確保されたなら、ＲＳＶ
Ｐの低位レイヤ情報のフィールドを用いて、使用するリ
ンクレイヤ技術がＩＥＥＥ１３９４であること、使用す
る同期チャネル番号を下流方向に伝達していく。

【０１１８】図８に、ＰＡＴＨメッセージのフォーマッ
ト例を示す。図８に示すように、ＰＡＴＨメッセージに
は、下位レイヤ情報として、データリンク種別（ＩＥＥ
Ｅ１３９４を示す）や、使用する同期チャネル番号、そ
れに非ＩＰパケット伝送のための非ＩＰフラグが立って
いる。なお、上位レイヤ情報として、伝達するコンテン
ツやアプリケーションに関する情報、例えば本実施形態
の場合はＭＰＥＧデータ／映像等についての情報を伝達
してもよい。また、認識ＩＤ（「α」）もＰＡＲＨメッ
セージ中で伝達する事も可能である。

【０１１９】これを接続装置１０３、第１の端末１０５
と伝達することにより、接続装置１０３、第１の端末１
０５には、それぞれデータ（非ＩＰパケット）が伝送さ
れてくるデータリンクの識別子についての情報を入手す
ることができるようになり、接続装置１０３のチャネル
対応テーブル５０４に記憶された図４に示したようなチ
ャネル間の対応関係をもとにデータリンクレイヤヘッダ
を参照することにより、パケット（フレーム）のフォワ
ーディング、ルーチング処理が可能となる。

【０１２０】第２の方法は、発明者らが特願平第８−２
６４４９６号にて記載したＦＡＮＰを用いる方法であ
る。ＦＡＮＰメッセージに、上位レイヤ情報、下位レイ
ヤ情報、認識ＩＤ等を実装し、接続装置１０３、第１の
端末１０５に伝達する。

【０１２１】詳細は特願平８−２６４４９６号（本発明
の発明者らによる）にて説明しているため、ここでは省
略する。

【０１２２】第３の方法は、ＩＥＣ１８８３のＰＣＲを
拡張する方法である。図９（ａ）にに示すようなＩＥＥ
Ｅ１３９４の基本的なプラグ制御レジスタ（ＰＣＲ）を
拡張して、図９（ｂ）に示すようなＰＣＲをＩＥＥＥ１
３９４Ｉ／Ｆ部５０１に設ける。図９（ｂ）に示すよう
に、本実施形態のＰＣＲには、少なくとも、そのチャネ
ル番号を伝達する内容に関する情報や、前述の認識ＩＤ
（「α」）についての情報を記憶するようになってい
る。

【０１２３】接続装置１０３は、第１の実施形態で説明
したように、ＩＥＣ１８８３のメッセージであることを
認識する。ＳＴＢ１０１と接続装置１０３の間におい
て、ＩＥＣ１８８３の同期チャネル番号には「＃Ｘ」が
記述されている。そして、ＩＥＣ１８８３の宛先と共に
認識ＩＤ（「α」）を認識することにより、そのＰＣＲ
に記述されたチャネル番号である「＃Ｘ」と、先に下流
方向で予約したチャネル番号「＃Ｙ」が対応することを
知ることができ（チャネル対応テーブル５０４に当該対
応関係を記憶する）、その両者をデータリンクレイヤ情
報（即ち、同期チャネル番号）のみで接続できる。すな
わち、第１のネットワーク（ＩＥＥＥ１３９４）１０２
の同期チャネル番号「＃Ｘ」で入力されてきたデータ
は、第２ネットワーク（ＩＥＥＥ１３９４）１０４の同
期チャネル番号「＃Ｙ」にて出力するように設定するこ
とが可能となる。

【０１２４】それと前後して、接続装置１０３は、その
ＩＥＣ１８８３のメッセージに記述された同期チャネル
番号「＃Ｘ」を「＃Ｙ」に書き直した上で、第１の端末
１０５のＰＣＲに書き込む。

【０１２５】これらの方法のほかに、例えばＵＳＢの場
合は、デフォルトパイプを通して上記メッセージのやり
取りを行うといった方法が考えられる。

【０１２６】また、受信端末である第１の端末１０５
は、同期チャネル番号「＃Ｙ」の同期チャンネルを通し
て、データが送信されてくることを知ることができる。

【０１２７】また、ＰＣＲに上位レイヤ情報が書き込ま
れるのなら、これから同期チャネル番号「＃Ｙ」の同期
チャンネルにて伝送されてくるのは、ＭＰＥＧデータ／
映像であることも認識が可能であり、適当な初期化を行
うことができる。

【０１２８】図７に示したシーケンスでは、第３の方法
の場合について記してある（ステップＳ１２０９、Ｓ１
２１０）。

【０１２９】なお、映像伝送の前に、送信者（ＳＴＢ１
０１）はエンドエンドで通信資源の予約が成功したこと
を通知するために、ＲＥＳＶ−ＡＣＫを流しても良い。

【０１３０】（第３の実施形態）次に、第３の実施形態
として、通信資源であるＩＥＥＥ１３９４の同期チャネ
ルの予約を下流側のノードが行う方法について説明す
る。全体の処理シーケンスを図１０に示す。

【０１３１】第３の実施形態は、同期チャネルの確保を
行うのがＲＳＶＰ/ ＳＢＭの下流側のノードである点以
外は、第２の実施形態とほぼ同様である。図１０に示す
ようにのように、上位レイヤプロトコル等を使って、端
末１０５はＳＴＢ１０１にデータ配信依頼を行う（ステ
ップＳ１５０１、Ｓ１５０２）。

【０１３２】このデータ配信依頼に呼応して、ＳＴＢ１
０１は経路の通信資源の確保のために、ＲＳＶＰのＰＡ
ＴＨメッセージを端末１０５に向かって流しはじめる
（ステップＳ１５０３、Ｓ１５０４）。詳細は第２の実
施形態の場合と同様である。

【０１３３】ＰＡＴＨメッセージを受信した端末１０５
は、まず、その接続された第２のネットワーク（ＩＥＥ
Ｅ１３９４）１０４の同期チャネルの確保を行う（ステ
ップＳ１５０５）。

【０１３４】図１０に示すように、まず、第１の端末１
０５が自らＰＡＴＨメッセージから認識される必要な通
信資源（帯域）を、同期リソースマネージャのレジスタ
にアクセスすることにより確保する。ここでは、確保に
成功し、チャネル番号「＃Ｙ」の同期チャネルが獲得で
きたものとする。

【０１３５】すると、第１の端末１０５は、ＲＥＳＶメ
ッセージに、この獲得した同期チャネル番号を図１１の
ように下位レイヤ情報として盛り込んだ上で、これを上
流側のＳＢＭノードである接続装置１０３に転送する
（ステップＳ１５０６）。

【０１３６】接続装置１０３も同様に、上流側の帯域の
確保を行い、この予約が成功したものとし、第１のネッ
トワーク（ＩＥＥＥ１３９４）１０２上に同期チャネル
番号「＃Ｘ」で同期チャネルを取得したものとする（ス
テップＳ１５０７）。

【０１３７】接続装置１０３は、これが先に第１の端末
１０５からのＲＥＳＶメッセージに呼応して作成した同
期チャネルであることを認識しており、上流側の同期チ
ャネル（チャンネル番号「＃Ｘ」）と、下流側の同期チ
ャネル（チャンネル番号「＃Ｙ」）とが１つのＲＥＳＶ
メッセージにより作成されたものであることを認識して
いることから、図４と同様なチャネル対応テーブル５０
４を作成・記憶し、第１のネットワーク１０２から同期
チャネル番号「＃Ｘ」で入力されたデータは、入力パケ
ットの同期チャネル番号の参照により、第２のネットワ
ーク１０４の同期チャネル番号「＃Ｙ」に出力する様に
設定を行う。

【０１３８】これと前後して、取得した同期チャネル番
号「＃Ｘ」をＲＥＳＶメッセージに含めた上で、これを
上流側のＳＴＢ１０１に伝送する（ステップＳ１５０
８）。

【０１３９】これにより、上流側のＳＴＢ１０１は、下
流側で通信資源が確保されているリンクレイヤネットワ
ークの識別子を認識することができるようになり、適切
な通信パスに、適切なデータのフォワーディングができ
るようになる。この場合、上流のＳＴＢ１０１として
は、ＲＥＳＶメッセージが到達したということは、下流
側の設定が全て終了している（即ち、中継ノードである
接続装置は対応する上流側と下流側の同期チャネル番号
の対応関係を認識しているし、受信端末である第１の端
末１０５も、同期チャネル「＃Ｙ」にて入力されてくる
データは、ＭＰＥＧデータ／映像である、という点を既
に認識している）ため、そのまま、同期チャネル（「＃
Ｘ」）にて、ＭＰＥＧデータ／映像の伝送を開始するこ
とが可能である（ステップＳ１５０９、Ｓ１５１０）。

【０１４０】その後のＲＳＶＰのＰＡＴＨメッセージの
伝送には、図８の様に、伝送しているデータリンクレイ
ヤの情報等を含めて、これを送るようになっていてもよ
い。

【０１４１】なお、第２、第３の実施形態において、Ｍ
ＰＥＧフレームをＩＥＥＥ１３９４で伝送する場合に、
ＩＥＣ１８８３にて定められているＣＩＰヘッダを参照
することで、受信端末１０５はそれがＭＰＥＧフレーム
であることを認識することが可能であることから、ＩＥ
Ｃ１８８３を用いる場合は、必ずしもＲＳＶＰのＰＡＴ
Ｈメッセージで、上位レイヤ情報を伝達する必然性はな
い。

【０１４２】（第４の実施形態）次に、第４の実施形態
として、受信端末が接続されたネットワークがイーサネ
ットである場合、すなわち、図１において、受信端末が
第２の端末１０７であり、これが第３のネットワーク１
０６であるイーサネットに接続された場合について説明
する。

【０１４３】第２の端末１０７の構成例は、例えば、図
２８に示した第１の端末１０５のＩＥＥＥ１３９４Ｉ／
Ｆ部６０１がイーサネットインタフェース（Ｉ／Ｆ）部
に置き換えられたものとすればよい。

【０１４４】この場合の処理シーケンスを図１２に示
す。基本的には、図１０と同様である。

【０１４５】サービスに先立って、ＳＴＢ１０１と受信
端末１０７は上位レイヤプロトコルで視聴する番組の選
択等を行う。この際、これらの手続きを、後のＲＳＶＰ
／ＳＢＭのやりとりとマッピングするための識別子（Ｉ
Ｄ）である「γ」を、一緒に転送してもよい（ステップ
Ｓ２１０１、Ｓ２１０２）。

【０１４６】続いて、ＳＴＢ１０１はＲＳＶＰのＰＡＴ
Ｈメッセージを下流方向に流していく。ＰＡＴＨメッセ
ージは、ルータ、あるいはＳＢＭ（ＳｕｂｎｅｔＢａ
ｎｄｗｉｄｔｈＭａｎａｇｅｒ）を経由していくこと
になるが、本実施形態においては、接続装置１０３が第
１のネットワーク（ＩＥＥＥ１３９４）１０１のＳＢＭ
ノード、また第３のネットワーク１０６であるイーサネ
ットを構成しているイーサネットスイッチのうち、第３
のネットワーク１０６のＳＢＭとして動作をしているも
のがあれば、該イーサネットスイッチをＰＡＴＨメッセ
ージが経由していく。

【０１４７】なお、むろん、接続装置１０３がイーサネ
ットのＳＢＭとなっていてもよく（イーサネットＩ／Ｆ
部５０６の機能に含まれる）、この場合は、ＰＡＴＨメ
ッセージは、接続装置１０３から、直接第２の端末１０
７に転送される。

【０１４８】これら、ＰＡＴＨメッセージには、このメ
ッセージで予約される通信パスを流れる情報はＩＰパケ
ットではないことを示すフラグ（図１２では「非ＩＰフ
ラグ」と表している）と、前記上位レイヤのＩＤである
「γ」が含まれており、図８の様なフォーマットで伝達
される（ステップＳ２１０３、Ｓ２１０４、Ｓ２１０
５）。

【０１４９】これを受信した第２の端末１０７は、先に
手続きを行った上位レイヤプロトコルに対応するＲＳＶ
Ｐ／ＳＢＭメッセージであることを、上位レイヤＩＤ
「γ」より認識し、通信資源の予約のために上流側のＳ
ＢＭノード（イーサネットスイッチ）にＲＥＳＶメッセ
ージを送出する（ステップＳ２１０６）。

【０１５０】該イーサネットスイッチでは、ＲＳＶＰで
指定されている通信資源の予約をイーサネット上で行い
（ステップＳ２１０７）、ＲＥＳＶメッセージを上流側
にフォワードする（ステップＳ２１０８）。ここでは、
接続装置１０３から、第２の端末１０７宛てのパケット
（すなわち、ソースアドレスが接続装置１０３のＭＡＣ
アドレス、宛先アドレスが第２の端末１０７のＭＡＣア
ドレスであるようなイーサネットパケット）が、優先的
に転送されるような予約がなされたものとする。

【０１５１】さて、該ＲＥＳＶメッセージを受信した接
続装置１０３は、例えば、第３の実施形態で示した方法
と同様の方法で、ＳＴＢ１０１と接続装置１０３間の通
信資源の確保などを行う。

【０１５２】イーサネット上の帯域予約は、基本的にＩ
ＥＥＥ８０２．１ｐで定められているトラヒッククラス
等の規定に従い、ＲＳＶＰ／ＳＢＭで定められた方式に
より取得してもよい。

【０１５３】接続装置１０３は、確保した第１のネット
ワーク（ＩＥＥＥ１３９４）１０２上の通信資源である
同期チャネル「＃Ｘ」と、第３のネットワーク（イーサ
ネット）１０６上の通信資源（この場合は、接続装置１
０３のＭＡＣアドレスと第２の端末１０７のＭＡＣアド
レス）とが対応しており、該同期チャネルから転送され
てきたデータ（ＭＰＥＧデータ／映像等）は、前記イー
サネット上の通信資源に対して送信すべきである、とい
うことを状態として記憶する。この時、チャネル対応テ
ーブル５０４には、図１３に示すような対応テーブルが
記憶される。

【０１５４】ＲＥＳＶ要求を受信したＳＴＢ１０１は、
ＲＥＳＶメッセージ内の上位レイヤＩＤ「γ」より、先
に上位レイヤプロトコルで選択された番組配送のための
通信資源予約であり、更に下位レイヤＩＤを参照するこ
とにより、転送すべきＩＥＥＥ１３９４の同期チャネル
番号も認識できる。

【０１５５】そこで、ＳＴＢ１０１は、該ＲＥＳＶメッ
セージで示された同期チャネル「＃Ｘ」を通して、先に
上位レイヤプロトコルで選択された番組の転送を開始す
る（ステップＳ２１１１）。

【０１５６】これを受信した接続装置１０３は、同期チ
ャネル（「＃Ｘ」）とイーサネット上に確保された通信
資源との対応テーブルを用いて、受信したデータをイー
サネットを介して、第２の端末１０７に対して送出す
る。このとき、転送する情報がＩＰパケットではなく、
ＭＰＥＧフレーム等であるため、そのことをイーサネッ
トパケットに明示的に図示する必要がある。そのため、
図１４に示すように、転送するイーサネットフレームの
イーサタイプの部分には、転送されるコンテンツがＭＰ
ＥＧデータであることを示す領域が設けられている。

【０１５７】そして、第１のネットワーク（ＩＥＥＥ１
３９４）１０２上でＭＰＥＧが転送されていた時に使わ
れていた、ＭＰＥＧフレームごとのタイムスタンプは、
そのまま使用してもよい。この場合、受信端末１０７は
このタイムスタンプを基に、ネットワーク上でのジッタ
吸収を行うことになる。

【０１５８】（第５の実施形態）次に、図１５に示すよ
うに、第１および第２のＩＥＥＥ１３９４バス２０４、
２０５がブリッジ２０２を介して相互接続されている場
合に、ブリッジ２０２を介して同期チャネル（あるいは
非同期ストリーム（非同期パケットのアービトレーショ
ン時間に送信される、同期パケットのフォーマットのパ
ケットであり、同期リソースマネージャを通じて同期チ
ャネル番号のみが確保される））を確立し、これを通し
てあるデータフローを送受信する場合についての実現方
法を説明する。

【０１５９】図１５に示すように、２つのＩＥＥＥ１３
９４バス２０４、２０５が１３９４ブリッジ２０２を介
して相互接続されている。この環境で、第１のＩＥＥＥ
１３９４バス２０４上に送信端末２０１が、第２のＩＥ
ＥＥ１３９４バス２０５上に受信端末２０３が接続され
ている。送信端末２０１のＥＵＩ６４アドレスは「ＥＵ
Ｉ１」、ＩＰアドレスは「ＩＰ１」であるとする。また
受信端末２０３のＥＵＩ６４アドレスは「ＥＵＩ２」、
ＩＰアドレスは「ＩＰ２」であるとする。

【０１６０】図１６は、送信端末２０１、受信端末２０
３の構成例を示したもので、ＩＥＥＥ１３９４の予め定
められたプロトコル処理を実行する１ＥＥＥ１３９４イ
ンタフェース（Ｉ／Ｆ）部３０１、ブリッジ同期レジス
タ３０２、レイヤ３フローレジスタ３０３、ＩＰ処理部
３０４、上位レイヤ処理部３０５から構成される。

【０１６１】１ＥＥＥ１３９４Ｉ／Ｆ部３０１は、ＩＥ
ＥＥ１３９４の物理層、リンク層、トランザクション層
の各レイヤにおける予め定められた処理を実行するよう
になっている。

【０１６２】ブリッジ同期レジスタ３０２は、送受信端
末２０１、２０３に具備されたメモリに設けられるレジ
スタで、主に、このレジスタ３０２に対し例えば図１９
に示すようなデータの書込が行われることにより、複数
のＩＥＥＥ１３９４バス間でブリッジを介したデータフ
ローの送受信を行う場合に複数のＩＥＥＥ１３９４バス
のそれぞれで同一のデータフローについての同期チャネ
ル（あるいは非同期チャネル）の確保の要求を受け、当
該複数のＩＥＥＥ１３９４のそれぞれで別個に確保され
る同期チャネル（あるいは非同期チャネル）の統一識別
子としての仮想チャネル識別子を中継ノードに通知し合
うためのものである。ブリッジ同期レジスタ３０２に
は、データデータフローの送信側から書き込まれる入力
用（ブリッジ同期レジスタＩＮ）と、受信側から書き込
まれる出力用（ブリッジ同期レジスタＯＵＴ）とがあ
る。

【０１６３】レイヤ３フローレジスタ３０３は、送受信
端末２０１、２０３に具備されたメモリに設けられるレ
ジスタで、仮想チャネル識別子と、当該仮想チャネル識
別子の付された複数の同期チャネル（あるいは非同期チ
ャネル）を通じて流れるデータフローとの対応関係が書
き込まれるものである。

【０１６４】ＩＰ処理部３０４は、ＦＡＮＰ、ＲＳＶＰ
等を含む予め定められたＩＰ処理を実行するようになっ
ている。

【０１６５】上位レイヤ処理部３０５は、例えば、受信
端末２０３（送信端末２０１）と送信端末２０１（受信
端末２０３）との間でデータの送受信要求のためのプロ
トコル処理、相手端末から送信されてきたデータに対す
る所定のサービス処理等を実行するものである。

【０１６６】図１７は、１３９４ブリッジ２０２の構成
例を示したもので、ＩＥＥＥ１３９４バスの接続ポート
毎に設けられるＩＥＥＥ１３９４の予め定められたプロ
トコル処理を実行する１ＥＥＥ１３９４インタフェース
（Ｉ／Ｆ）部３１１とブリッジ同期レジスタ３１２、所
定のメモリ領域に記憶されたブリッジ対応テーブル３１
４を参照して一方のＩＥＥＥ１３９４バスから受け取っ
たデータのうち他方のＩＥＥＥ１３９４バスへのデータ
のみを通過させるフィルタリングを行う転送部３１３か
ら構成される。

【０１６７】ブリッジ対応テーブル３１４は、例えば、
第１の１３９４バス２０４および第２の１３９４バス２
０５のそれぞれに接続されている端末および他の１３９
４ブリッジのＥＵＩ６４アドレス、ノードＩＤ（バスリ
セットにより再設定される端末および１３９４ブリッジ
のアドレス）、１３９４ブリッジ２０２と当該端末ある
いは他の１３９４ブリッジとの間に確立されたチャネル
の番号が記憶されている。

【０１６８】転送部３１３は、１３９４ブリッジ２０２
が接続している複数のＩＥＥＥ１３９４バスのうちのい
ずれからデータが転送されてきたら、ブリッジ対応テー
ブル３１４を参照して、当該データに付された転送先の
アドレスが他のＩＥＥＥ１３９４バスに接続されている
他の１３９４ブリッジあるいは端末宛である場合のみ、
当該データを当該他の１３９４バスに転送するようにな
っている。その際、転送するデータに付されているチャ
ネル番号をブリッジ対応テーブル３１４に記憶されてい
る転送先のチャネル番号に合わせて書き換える。

【０１６９】ブリッジ同期レジスタ３１２は、１３９４
ブリッジ２０２に具備されたメモリに設けられるレジス
タで、ＩＥＥＥ１３９４バスの接続ポート毎（ここで
は、第１の１３９４バス２０４、第２のＩＥＥＥ１３９
４バス２０５の各接続ポート毎）に設けられている（＃
１、＃２）。このレジスタ３１２に対し所定のデータの
書込が行われることにより、複数のＩＥＥＥ１３９４バ
ス間でブリッジを介したデータフローの送受信を行う場
合に複数のＩＥＥＥ１３９４バスのそれぞれで同一のデ
ータフローについての同期チャネル（あるいは非同期チ
ャネル）の確保の要求を行うともに、当該複数のＩＥＥ
Ｅ１３９４のそれぞれで別個に確保される同期チャネル
（あるいは非同期チャネル）の統一識別子としての仮想
チャネル識別子を中継ノードに通知し合うためのもので
ある。ＩＥＥＥ１３９４バスの接続ポート毎に設けられ
るブリッジ同期レジスタ（＃１、＃２）３１２には、デ
ータフローの送信側から書き込まれる入力用（ブリッジ
同期レジスタＩＮ）と、受信側から書き込まれる出力用
（ブリッジ同期レジスタＯＵＴ）とがある。

【０１７０】なお、送受信端末のブリッジ同期レジスタ
３０２と１３９４ブリッジ２０２のブリッジ同期レジス
タ３１２とは同一のものである。

【０１７１】このような状況で、送信端末２０１は、受
信端末２０３までの同期チャネル（あるいは非同期スト
リーム）を確立し、これを通してある特定のデータフロ
ーを送信しようとしているものとする。この場合の処理
シーケンスを図１５を参照しながら説明する。

【０１７２】まず、送信端末２０１は、第１のＩＥＥＥ
１３９４バス２０４上の同期リソースマネージャ（図示
せず）にアクセスし、チャネル番号「＃ｘ」の確保を行
なう。必要に応じて、帯域の確保も行なってよい（ステ
ップＳ３００１）。

【０１７３】次に、送信端末２０１は、受信端末２０３
との間に、１３９４ブリッジ２０２を介して同期チャネ
ルを確立すべく、１３９４ブリッジ２０２のブリッジ同
期レジスタ（＃１）３１２に書き込みを行なう（ステッ
プＳ３００２）。

【０１７４】ブリッジ同期レジスタ（＃１）３１２は、
図１９に示すようなデータ構成をもつレジスタで、入力
用と出力用のペアのレジスタがＩＥＥＥ１３９４バスの
接続ポート毎に設けられていてもよい（レジスタ内に方
向を示す情報を記憶する領域があってももちろん良
い）。なお、図１９には、入力用（ＩＮ）のブリッジ同
期レジスタの場合を示している。

【０１７５】１３９４ブリッジ２０２のブリッジ同期レ
ジスタ３１２は、ＩＥＥＥ１３９４上でデータ送受信が
可能な端末（ここでは、例えば送信端末２０１、受信端
末２０３）から１３９４ブリッジ２０２に対して、当該
ブリッジをまたがった同期チャネル（あるいは非同期ス
トリーム）の確保の要求を受けるためのレジスタであ
り、図１９に示すように、確保されたチャネルのチャネ
ル番号、仮想チャネル識別子、相手端末のＥＵＩアドレ
ス（終点ノードＩＤ）、帯域が書き込まれるようになっ
ている。

【０１７６】チャネル番号のフィールドには、このレジ
スタを書き込む側のＩＥＥＥ１３９４バス（本実施形態
の場合、第１のＩＥＥＥ１３９４バス２０４）上に確保
された同期チャネルについての情報が記入される。例え
ば、本実施形態の１３９４ブリッジ２０２の場合、同期
チャネル番号「＃ｘ」が書き込まれる。帯域のフィール
ドには、当該同期チャネルで確保される帯域量が書き込
まれる。当然、非同期ストリームの場合には「０」が記
入される。

【０１７７】終点ノードＩＤのフィールドには、同期チ
ャネルの確保要求を最初に起動した側（この場合送信端
末２０１）からみて、この同期チャネルの終点となるべ
きノードのＩＤが記入される。１３９４ブリッジ２０２
のブリッジ同期レジスタ３１２では、終点ノードは受信
端末２０３であるため、受信端末２０３のＥＵＩ６４ア
ドレスである「ＥＵＩ２」が記入されるが、ここにＥＵ
Ｉ６４アドレスを記入する必要は必ずしもなく、「バス
ＩＤ＋ノードＩＤ」の形でノードＩＤが記入されてもよ
い。

【０１７８】なお、送受信端末のブリッジ同期レジスタ
３０２についても上記ブリッジ同期レジスタ３１２と同
様である。

【０１７９】仮想チャネル識別子は、送信端末２０１、
受信端末２０３、あるいは中継ノードとなる１３９４ブ
リッジ２０２において、確立した同期チャネルを同一の
識別子を通じて認識するための識別子で、例えば送信端
末２０１にて発行されるものである。即ち、複数のＩＥ
ＥＥ１３９４バスを通過するうちに、同期チャネル番号
等は変わってしまう可能性があるため、同期チャネル番
号では送信端末、受信端末、中継ノードで、これらが同
一のチャネルとしてつながっていることを認識すること
ができなくなる。このため、例えば送信端末２０１がこ
のチャネルを自分のＥＵＩ６４アドレスと、該送信端末
が任意に定めた番号（例えばシーケンス番号など）αを
使い、「このチャネルには（ＥＵＩ１、α）なる仮想チ
ャネル識別子を付与する」と定める。この値を、１３９
４ブリッジ２０２のブリッジ同期レジスタに記入してい
き、最終的に受信端末２０３までこの値を、各々のＩＥ
ＥＥ１３９４バス上にチャネルを確保しつつ、リレー式
に伝達する。この伝達は、例えば非同期ライトなどを用
いてもよい。このようにして、送信端末２０１、１３９
４ブリッジ２０２、受信端末２０３は、この仮想チャネ
ル識別子（ＥＵＩ１、α）を通じて、別々の同期チャネ
ル番号が付与される可能性のあるこれらを、同一の識別
子を通じて一貫して認識することが可能となる。

【０１８０】次に、１３９４ブリッジ２０２の動作（図
１５のステップＳ３００３〜ステップＳ３００５）を図
２０に示すフローチャートを参照して説明する。なお、
図２０に示した動作は、受信端末２０３においても同様
に当てはめることもできる。

【０１８１】図１５のステップＳ３００２でブリッジ同
期レジスタＩＮ（＃１）３１２に図１９に示したような
情報が書き込まれると（ステップＳ３１０１）、１３９
４ブリッジ２０２は、図１８に示しようなブリッジ対応
テーブル３１４を参照して、該ブリッジ同期レジスタ
（＃１）３１２に書き込まれた終点ノード（「ＥＵＩ
２」）が第２のＩＥＥＥ１３９４バス２０５上に存在し
ていることを認識し（ステップＳ３１０２）、さらに帯
域のフィールドから確保すべき帯域を認識して、第２の
ＩＥＥＥ１３９４バス２０５上に同期チャネルを確立す
る（ステップＳ３１０３）。ここで、確保した同期チャ
ネル番号を「＃ｙ」とし、例えば、図１８に示すよう
に、当該チャネル番号「＃ｙ」をブリッジ対応テーブル
３１４の「ＥＵＩ２」というアドレスに対応させて書き
込むようにしてもよい。

【０１８２】次に、１３９４ブリッジ２０２は、受信端
末２０３の入力用ブリッジ同期レジスタＩＮ３０２に書
き込みを行なう。この時は、チャネル番号として「＃
ｙ」、仮想チャネル識別子として「ＥＵＩ１、α」、終
点ノードＩＤとして「ＥＵＩ２」、帯域として必要な帯
域の値が書き込まれる（ステップＳ３１０４）。受信端
末２０３は、自分が終点ノードであることを終点ノード
ＩＤより認識できるので、これ以上の帯域確保の動作な
どは行なわない。このとき、受信端末２０３はデータ受
信の準備が整った旨の応答（ＡＣＫ）信号を送出しても
よい。（ステップＳ３１０１〜ステップＳ３１０２、ス
テップＳ３１０６）。

【０１８３】このようにして、送信端末２０１から受信
端末２０３までの同期チャネル（あるいは非同期ストリ
ーム）の確保が行なわれる。終点までのチャネルの確保
が行なわれたなら、終点側に一番近い１３９４ブリッジ
（本実施形態の場合１３９４ブリッジ２０２）から順に
上流側に向かってＡＣＫ信号を返していってもよい（ス
テップＳ３１０６）。このＡＣＫ信号が送信端末２０１
まで到達すると、送信端末２０１は、受信端末２０３ま
での同期チャネルの確立が成功したことを認識すること
ができる（図１５のステップＳ３００５）。

【０１８４】図１５の説明に戻り、送信端末２０１は、
確保した同期チャネル（＃ｘ、＃ｙ）を通じて、受信端
末２０３に対して、どのようなデータフローを送信しよ
うとしているのかを通知するために、受信端末２０３の
レイヤ３フローレジスタ３０３にフロー識別子とレイヤ
２識別子との対応関係を書き込む（ステップＳ３００
６）。ここで、確保した同期チャネル（＃ｘ、＃ｙ）を
通じて送信されるデータフローは、送信ＩＰアドレスが
「ＩＰ１」、送信側の上位レイヤサービスの番号（例え
ば、ＲＦＣ１３４０で規定されているウエルノウンポー
ト番号でもよい）を示すポート番号「ＰＯＲＴ１」、受
信側ＩＰアドレス「ＩＰ２」、受信側の上位レイヤサー
ビスの番号（例えば、ＲＦＣ１３４０で規定されている
ウエルノウンポート番号でもよい）を示すポート番号
「ＰＯＲＴ２」とする。

【０１８５】レイヤ３フローレジスタは、図２１に示す
ようなデータ構成をもつレジスタである。このレジスタ
は、基本的にレイヤ２識別子（例えば、レイヤ２の種別
（ここではＩＥＥＥ１３９４バス）、識別子種別（ここ
では仮想チャネル識別子）、当該識別子（ここでは、
（ＥＵＩ１、α））と、そのレイヤ２識別子であらわさ
れるチャネルを通ることになるフロー識別子にて特定さ
れるレイヤ３フローについての対応関係を登録するため
のレジスタである。フロー識別子には、例えば、当該デ
ータフローの送信側のＩＰアドレスおよびポート番号
と、当該データフローの受信側ＩＰアドレスおよびポー
ト番号とが含まれる。このレジスタには、その他に、そ
のフローが入力されるものであるのか、出力されるもの
であるのかについての情報の書込領域が用意されてい
る。

【０１８６】受信端末２０３にはデータフローが流れ込
むことになるため、フロー識別子として、送信側ＩＰア
ドレスには送信端末２０１のＩＰアドレス「ＩＰ１」
を、送信側ポート番号には、送信端末２０１のポート番
号「ＰＯＲＴ１」、受信側ＩＰアドレスには受信端末２
０３のＩＰアドレス「ＩＰ２」を、受信側ポート番号に
は、受信端末２０３のポート番号「ＰＯＲＴ２」が書き
込まれる。

【０１８７】レイヤ２識別子としては、ここではレイヤ
２種別として「ＩＥＥＥ１３９４」、識別子種別として
「仮想チャネル識別子」が書き込まれて、当該識別子と
しては、先に定めた仮想チャネル識別子「ＥＵＩ１、
α」が記入される。

【０１８８】方向としては、受信端末２０３がデータフ
ローを受信するので「順方向」とする。

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

【０１９０】受信端末２０３のレイヤ３フローレジスタ
に図２１に示すようなデータの書込みを行うことによ
り、受信端末２０３は、識別子（ＥＵＩ１、α）を参照
して、このレイヤ３フローレジスタを参照して通知され
るデータフローが、先に確保された同期チャネル（受信
端末２０３から見るとチャネル番号「＃ｙ」で受信され
る同期チャネル）を通じて送信されてくることを知るこ
とができるようになる。

【０１９１】実際のデータフローは、送信端末２０１か
ら１３９４ブリッジ２０２までの間は同期チャネル「＃
ｘ」を介して送信され（ステップＳ３００７）、１３９
４ブリッジ２０２にて、ブリッジ対応テーブル３１４を
参照して同期チャネルの乗せかえが行われる（ステップ
Ｓ３００８）。即ち、先にブリッジ同期レジスタに書き
込まれた内容を参照して（仮想チャネル識別子を介し
て）、１３９４ブリッジ２０２は第１のＩＥＥＥ１３９
４バス２０４の同期チャネル「＃ｘ」と第２のＩＥＥＥ
１３９４バス２０５の同期チャネル「＃ｙ」とが対応し
ていることを認識しており、第１のＩＥＥＥ１３９４バ
ス２０４の同期チャネル「＃ｘ」から入力されてきたデ
ータは、第２のＩＥＥＥ１３９４バス２０５の同期チャ
ネル「＃ｙ」に出力する（ステップＳ３００８）。この
データは、受信端末２０３に同期チャネル「＃ｙ」を通
じて到達する（ステップＳ３００９）。

【０１９２】なお、受信端末２０３は、ステップＳ３０
０６のレジスタ書き込みにより、この同期チャネルを通
じて受信されるデータが、どのようなデータフローであ
るかを事前に認識しており、必要なバッファ量の確保な
ど、データフロー受信の準備を行なうことが可能とな
る。

【０１９３】上記実施形態では、送信端末２０１から受
信端末２０３へのレイヤ２のチャネルとレイヤ３フロー
の対応関係の通知はレイヤ２の処理としてレイヤ３フロ
ーレジスタに対し書き込みを行うこととしているが（ス
テップＳ３００６）、この場合に限らず、ＦＡＮＰ（Ｆ
ｌｏｗＡｔｔｒｉｂｕｔｅＮｏｔｉｆｉｃａｔｉｏ
ｎＰｒｏｔｏｃｏｌ）メッセージを通じてこれを行なう
ことももちろん可能である。

【０１９４】ＦＡＮＰは、ＩＰデータグラムを用いて、
あるデータリンクレイヤのチャネル（例えばＩＥＥＥ１
３９４の同期チャネルや非同期ストリーム、あるいはＡ
ＴＭやフレームリレーの仮想チャネル等）と、そのチャ
ネルを通る上位レイヤのフロー（例えばＩＰフロー）の
対応関係を通知するプロトコルである。

【０１９５】このＦＡＮＰを用いて、送信端末２０１は
レイヤ３の処理として図２２に示すようなＦＡＮＰメッ
セージを送出し、このＦＡＮＰメッセージを受けた受信
端末２０３はレイヤ３の処理を介してレイヤ３フローレ
ジスタに図２１に示した様なデータの書込を行うように
してもよい。

【０１９６】また、送信するデータフローがＩＰマルチ
キャストである場合も、基本的に上記同様のメカニズム
で行なうことができる。すなわち、図２３に示すよう
に、送信端末２０１をＩＧＭＰ（ＩｎｔｅｒｎｅｔＧ
ｒｏｕｐＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ）
ルータ２０６に置き換える。ＩＧＭＰルータ２０６のＥ
ＵＩ６４アドレスは「ＥＵＩｘ」、ＩＰアドレスは「Ｉ
Ｐｘ」であるとする。

【０１９７】ここでは、第２のＩＥＥＥ１３９４バス２
０５に接続している２つの受信端末２０３ａおよび２０
３ｂがＩＰマルチキャストアドレス「ＩＰｍ」に加入し
ているとする。受信端末２０３ａのＥＵＩ６４アドレス
は「ＥＵＩ２」、ＩＰアドレスは「ＩＰ２」、受信端末
２０３ｂのＥＵＩ６４アドレスは「ＥＵＩ３」、ＩＰア
ドレスは「ＩＰ３」であるとする。

【０１９８】ＩＧＭＰルータ２０６は、第１のＩＥＥＥ
１３９４バス２０４の同期リソースマネージャにアクセ
スし、同期チャネル番号を確保する（ステップＳ３００
１）。ＩＧＭＰルータ２０６からの要求に応じて同期リ
ソースマネージャにて確保された同期チャネル番号を
「＃ｘ」とする。

【０１９９】ＩＧＭＰルータ２０６は、同期チャネル番
号が確保されると、受信端末２０３ａおよび２０３ｂと
の間に、１３９４ブリッジ２０２を介して同期チャネル
を確立すべく、１３９４ブリッジ２０２のブリッジ同期
レジスタＩＮ（＃１）３１２に書き込みを行なう（ステ
ップＳ３００２）。この場合、確保されたチャネルのチ
ャネル番号（＃ｘ）、仮想チャネル識別子（ＥＵＩｘ、
α）、相手端末のＥＵＩアドレス（終点ノードＩＤ）、
帯域が書き込まれる。この場合、相手受信端末は複数あ
るので、図２３に示すように、各受信端末毎のブリッジ
同期レジスタＩＮ（＃１）３１２への書込を行うように
してもよい。すなわち、終点ノードＩＤを受信端末２０
３ａのＥＵＩ６４アドレス「ＥＵＩ２」とする書込と、
終点ノードＩＤを受信端末２０３ｂのＥＵＩ６４アドレ
ス「ＥＵＩ３」とする書込との２回の書込を１３９４ブ
リッジ２０２のブリッジ同期レジスタＩＮ（＃１）３１
２に対して行う。なお、マルチキャスト用のＥＵＩ６４
アドレスが予め定められている場合、例えば、そのマル
チキャスト用ＥＵＩ６４アドレスを「ＥＵＩｍ」とする
と、終点ノードＩＤを「ブロードキャスト」とするブリ
ッジ同期レジスタＩＮ（＃１）３１２への書込を１回の
み行うようにしてもよい。

【０２００】ブリッジ同期レジスタＩＮ（＃１）３１２
に上記情報が書き込まれると（ステップＳ３００２）、
１３９４ブリッジ２０２は、該ブリッジ同期レジスタ
（＃１）３１２の終点ノードＩＤのフィールドとブリッ
ジ対応テーブル３１４とを参照して、該フィールドに書
き込まれた終点ノード（受信端末２０３ａ、２０３ｂ）
が第２のＩＥＥＥ１３９４バス２０５上に存在している
こと、および、帯域のフィールドから確保すべき帯域を
認識し、マルチキャストの仮想チャネル識別子（ＥＵＩ
ｘ、α）に対応して第２のＩＥＥＥ１３９４バス２０５
上に同期チャネルを確立する（ステップＳ３００３）。
ここで、確保した同期チャネル番号を「＃ｙ」とする。

【０２０１】次に、１３９４ブリッジ２０２は、受信端
末２０３ａ、２０３ｂの入力用ブリッジ同期レジスタＩ
Ｎ３０２に書き込みを行なう。この時は、チャネル番号
として「＃ｙ」、仮想チャネル識別子として「ＥＵＩ
ｘ、α」、終点ノードＩＤ、帯域として必要な帯域の値
が書き込まれる（ステップＳ３００４）。この場合も、
相手受信端末は複数あるので、図２３に示すように、各
受信端末毎のブリッジ同期レジスタＩＮ３０２への書込
を行うようにしてもよい。すなわち、終点ノードＩＤを
受信端末２０３ａのＥＵＩ６４アドレス「ＥＵＩ２」と
する書込と、終点ノードＩＤを受信端末２０３ｂのＥＵ
Ｉ６４アドレス「ＥＵＩ３」とする書込との２回の書込
を各受信端末のブリッジ同期レジスタＩＮ３０２に対し
て行う。なお、マルチキャスト用のＥＵＩ６４アドレス
が予め定められている場合、例えば、そのマルチキャス
ト用ＥＵＩ６４アドレスを「ＥＵＩｍ」とすると、終点
ノードＩＤを「ブロードキャスト」とするブリッジ同期
レジスタＩＮ３０２への書込を１回のみ行うようにして
もよい。

【０２０２】受信端末２０３ａ、２０３ｂは、自分が終
点ノードであることを終点ノードＩＤより認識できるの
で、これ以上の帯域確保の動作などは行なわない。

【０２０３】以上で、ＩＧＭＰルータ２０６から受信端
末２０３ａ、２０３ｂまでの同期チャネル（あるいは非
同期ストリーム）の確保が行なわれた。終点までのチャ
ネルの確保が行なわれたなら、終点側に一番近い１３９
４ブリッジ（本実施形態の場合１３９４ブリッジ２０
２）から順に上流側に向かってＡＣＫ信号を返していっ
てもよい。このＡＣＫ信号がＩＧＭＰルータ２０６まで
到達すると、ＩＧＭＰルータ２０６は、受信端末２０
３、２０３ｂまでの同期チャネルの確立が成功したこと
を認識することができる（ステップＳ３００５）。

【０２０４】ＩＧＭＰルータ２０６は、確保した同期チ
ャネル（＃ｘ、＃ｙ）を通じて、受信端末２０３ａ、２
０３ｂに対して、どのようなデータフローを送信しよう
としているのかを通知するために、受信端末２０３ａ、
２０３ｂのそれぞれのレイヤ３フローレジスタ３０３に
書き込みを行なう（ステップＳ３００６）。ここで、確
保した同期チャネル（＃ｘ、＃ｙ）を通じて送信される
データフローは、送信ＩＰアドレスが「ＩＰｘ」、送信
側の上位レイヤサービスの番号（例えば、ＲＦＣ１３４
０で規定されているウエルノウンポート番号でもよい）
を示すポート番号「ＰＯＲＴ１」、受信側ＩＰアドレス
をＩＰマルチキャストアドレス「ＩＰｍ」、受信側の上
位レイヤサービスの番号（例えば、ＲＦＣ１３４０で規
定されているウエルノウンポート番号でもよい）を示す
ポート番号「ＰＯＲＴｍ」とする。

【０２０５】受信端末２０３ａ、２０３ｂのレイヤ３フ
ローレジスタ３０３には、ＩＰマルチキャストデータが
流れ込むことになるため、そのフロー識別子として、送
信側ＩＰアドレスには送信端末２０１のＩＰアドレス
「ＩＰ１」を、送信側ポート番号には、送信端末２０１
のポート番号「ＰＯＲＴ１」、受信側ＩＰアドレスには
ＩＰマルチキャストアドレス「ＩＰｍ」を、受信側ポー
ト番号には、ポート番号「ＰＯＲＴｍ」が書き込まれ
る。

【０２０６】レイヤ２識別子としては、ここではレイヤ
２種別として「ＩＥＥＥ１３９４」、識別子種別として
「仮想チャネル識別子」が書き込まれて、当該識別子と
しては、先に定めた仮想チャネル識別子「ＥＵＩｘ、
α」が記入される。

【０２０７】方向としては、受信端末２０３ａ、２０３
ｂがマルチキャストＩＰフローを受信するので「順方
向」とする。

【０２０８】受信端末２０３ａ、２０３ｂのレイヤ３フ
ローレジスタに上記データの書込みを行うことにより、
受信端末２０３ａ、２０３ｂは、識別子（ＥＵＩｘ、
α）を参照して、このレイヤ３フローレジスタで通知さ
れるマルチキャストＩＰフローが、先に確保された同期
チャネル（受信端末２０３ａ、２０３ｂから見るとチャ
ネル番号「＃ｙ」で受信される同期チャネル）を通じて
送信されてくることを知ることができるようになる。

【０２０９】実際のマルチキャストＩＰフローは、ＩＧ
ＭＰルータ２０６から１３９４ブリッジ２０２までの間
は同期チャネル「＃ｘ」を介して送信され（ステップＳ
３００７）、１３９４ブリッジ２０２にて、同期チャネ
ルの乗せかえが行われる（ステップＳ３００８）。即
ち、先にブリッジ同期レジスタに書き込まれた内容を参
照して、１３９４ブリッジ２０２は第１のＩＥＥＥ１３
９４バス２０４の同期チャネル「＃ｘ」と第２のＩＥＥ
Ｅ１３９４バス２０５の同期チャネル「＃ｙ」とが対応
していることを認識しており、第１のＩＥＥＥ１３９４
バス２０４の同期チャネル「＃ｘ」から入力されてきた
データは、第２のＩＥＥＥ１３９４バス２０５の同期チ
ャネル「＃ｙ」に出力する（ステップＳ３００８）。こ
のデータは、受信端末２０３ａ、２０３ｂに同期チャネ
ル「＃ｙ」を通じて到達する（ステップＳ３００９）。

【０２１０】送信するデータフローがＩＰマルチキャス
トである場合も、前述同様、ＩＧＭＰルータ２０６から
受信端末２０３ａ、２０３ｂへのレイヤ２のチャネルと
レイヤ３フローの対応関係の通知はレイヤ２の処理とし
てレイヤ３フローレジスタに対し書き込みを行うことと
しているが（ステップＳ３００６）、この場合に限ら
ず、ＦＡＮＰメッセージを通じてこれを行なうこともも
ちろん可能である。

【０２１１】さて、これまでは送信端末２０１が受信端
末２０３までの１３９４ブリッジ２０２を介した同期チ
ャネルの確立を行なう場合について説明したが、もちろ
ん受信端末２０３が送信端末２０１までの同期チャネル
を確立し、特定のデータフローの送信を促すことも可能
である。この場合を図２４を参照して説明する。

【０２１２】図１５とは逆方向に手続きが進んでいく。
すなわち、受信端末２０３は、同期チャネル確立を行い
（ステップＳ３２０１）、同期チャネル番号「＃ｙ」を
確保する。次に、１３９４ブリッジ２０２の出力用ブリ
ッジ同期レジスタＯＵＴ（＃２）３１２に書き込みを行
う（ステップＳ３２０２）。ここで、この同期チャネル
が受信端末２０３が受信するような方向であることを示
すために、出力用のブリッジ同期レジスタ（＃２）３１
２に図２５に示すように書込を行なう。仮想チャネル識
別子としては、この場合、受信端末２０３にて発行さ
れ、例えば（ＥＵＩ２、β）を用いる。１３９４ブリッ
ジ２０２は、終点ノードＩＤを参照して、第１のＩＥＥ
Ｅ１３９４バス２０４上に、必要な帯域を持った同期チ
ャネル「＃ｘ」を確保し（ステップＳ３２０３）、送信
端末２０１の出力用ブリッジ同期レジスタＯＵＴ３０２
に図２５と同様の情報（ただし、同期チャネル番号は
「＃ｘ」とする）を書き込む（ステップＳ３２０４）。

【０２１３】１３９４ブリッジ２０２は、同期チャネル
が最後まで（本実施形態の場合、送信端末２０１まで）
確立したことを確認すると、ＡＣＫ信号を返して受信端
末２０３に同期チャネルの貫通を知らせる（Ｓ３２０
５）。

【０２１４】すると、受信端末２０３は、送信端末２０
１のレイヤ３フローレジスタ３０３に図２６に示すよう
なデータの書込を行う（ステップＳ３２０６）。ここ
で、仮想チャネル識別子として（ＥＵＩ２、β）をもち
いることで、送信端末２０１は、先に確立されたチャネ
ル番号「＃ｘ」で示される同期チャネルに、このデータ
フローを送信すればよいのだ、ということを認識するこ
とができる。無論、ＦＡＮＰメッセージを用いてもよ
い。

【０２１５】このレイヤ３フローレジスタ３０３への書
込を受けて、送信端末２０１は、チャネル番号「＃ｘ」
にて示されるチャネルに、レイヤ３フローレジスタ３０
３に書き込まれたデータフローを送信する（Ｓ３２０
７）。

【０２１６】１３９４ブリッジ２０２は、同期チャネル
の乗せ換えを行い（ステップＳ３２０８）、第１のＩＥ
ＥＥ１３９４バス２０４の同期チャネル「＃ｘ」から入
力されたデータを第２のＩＥＥＥ１３９４バス２０５の
同期チャネル「＃ｙ」に乗せ換え、受信端末２０３に送
信する（ステップＳ３２０９）。

【０２１７】このようにして、受信端末２０３は、送信
端末２０１から、特定のデータフローを同期チャネルを
通じて送信してもらうことを、ブリッジ環境においても
行なうことができるようになる。

【０２１８】以上説明したように、上記第５の実施形態
によれば、ＩＥＥＥ１３９４バスのブリッジ接続環境に
おいて、ブリッジをまたがった同期チャネル、あるいは
非同期ストリームの確立方法を提供できる。また、ＩＥ
ＥＥ１３９４バスのブリッジ接続環境において、ブリッ
ジを通過するごとに同期チャネル番号が変更される場合
でも、送信端末と受信端末の間で、当該ブリッジ接続さ
れた同期チャネルを仮想チャネル識別子にて同一のもの
と判断することができる。

【０２１９】

【発明の効果】以上説明したように、本発明によれば、
必ずしもＩＰパケットの形で転送されるとは限らない情
報データ（例えば衛星放送のコンテンツ等）を、例えば
家庭内に構築された複数のネットワーク（例えば２つ以
上のＩＥＥＥ１３９４）をまたがって転送する際に、所
望の通信品質を有する通信資源の確保を円滑に行うこと
ができる。

【０２２０】また、本発明によれば、ＩＥＥＥ１３９４
バスのブリッジ接続環境において、ブリッジをまたがっ
た同期チャネル、あるいは非同期ストリームの確立方法
を提供できる。また、ＩＥＥＥ１３９４バスのブリッジ
接続環境において、ブリッジを通過するごとに同期チャ
ネル番号が変更される場合でも、送信端末と受信端末の
間で、当該ブリッジ接続された同期チャネルを仮想チャ
ネル識別子にて同一のものと判断することができる。

【図面の簡単な説明】

【図１】本発明の実施形態に係るネットワーク（特に家
庭内に構築されるネットワーク）の構成例を示した図。

【図２】本発明の第１の実施形態に係るＩＥＥＥ１３９
４ネットワークをブリッジ接続した環境おける同期チャ
ンネルの設定手順を説明するためのシーケンス図。

【図３】接続装置の処理手順を説明するための図２に対
応するフローチャート。

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

【図５】ＩＥＥＥ１３９４ネットワークをブリッジ接続
した環境おける同期チャンネル設定手順を説明するため
の他のシーケンス図。

【図６】接続装置の処理手順を説明するための図５に対
応するフローチャート。

【図７】本発明の第２の実施形態に係る非ＩＰのトラヒ
ックが通るための通信資源をＲＳＶＰを用いて予約する
場合について説明するための処理シーケンス図。

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

【図９】ＩＥＣ１８８３のフラグ制御レジスタ（ＰＣ
Ｒ）を拡張して、確保された通信資源の関係づけと、伝
達されるデータの通知のための手続きを行う場合につい
て説明するための図。

【図１０】非ＩＰのトラヒックが通るための通信資源を
ＲＳＶＰを用いて予約する際、ＩＥＥＥ１３９４の同期
チャネルの予約を下流側のノードが行う場合の処理シー
ケンス図。

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

【図１２】本発明の第３の実施形態に係る、イーサネッ
トに接続された端末とＩＥＥＥ１３９４に接続された端
末との間に非ＩＰのトラヒックが通るための通信資源を
ＲＳＶＰを用いて予約する場合の処理シーケンス図。

【図１３】接続装置に記憶される対応テーブルの一例を
示した図で、図１２に対応するこのである。

【図１４】イーサネットフレームの一例を示した図。

【図１５】本発明の第５の実施形態に係るネットワーク
構成例およびチャンネルの設定手順を説明するためのシ
ーケンス図。

【図１６】図１５の受信端末および送信端末の構成例を
示した図。

【図１７】図１５の１３９４ブリッジ（ネットワーク間
接続装置）の構成例を示した図。

【図１８】図１７のブリッジ対応テーブルの一例を示し
た図。

【図１９】仮想チャネル識別子とチャネル番号との対応
関係を記憶する入力用ブリッジ同期レジスタの一例を示
した図。

【図２０】１３９４ブリッジの動作を説明するためのフ
ローチャート。

【図２１】仮想チャネル識別子を含むレイヤ２識別子と
レイヤ３フロー（ＩＰフロー）の識別子との対応関係を
記憶したレイヤ３フローレジスタの一例を示した図。

【図２２】仮想チャネル識別子を含むレイヤ２識別子と
レイヤ３フロー（ＩＰフロー）の識別子との対応関係を
通知するためのＦＡＮＰメッセージの一例を示した図。

【図２３】ＩＰフローがＩＰマルチキャストである場合
のチャンネルの設定手順を説明するためのネットワーク
構成例とシーケンス図。

【図２４】受信端末が送信端末まで、ＩＥＥＥ１３９４
バス上にチャネルを確立し、特定のＩＰフローの送信を
促す際のシーケンス図。

【図２５】受信端末が始点として送信端末までのチャネ
ルを確立する際の、仮想チャネル識別子とチャネル番号
との対応関係を記憶する出力用ブリッジ同期レジスタの
一例を示した図。

【図２６】受信端末が始点として送信端末までのチャネ
ルを確立する際の、仮想チャネル識別子を含むレイヤ２
識別子とレイヤ３フロー（ＩＰフロー）の識別子との対
応関係を記憶したレイヤ３フローレジスタの一例を示し
た図。

【図２７】図１の接続装置の構成例を示した図。

【図２８】図１の第１の端末の構成例を示した図。

【符号の説明】

１０１…（デジタル衛星放送の）セットトップボックス
（送信端末）１０２…第１のネットワーク（ＩＥＥＥ１３９４）１０３…接続装置（ネットワーク間接続装置）１０４…第２のネットワーク（ＩＥＥＥ１３９４）１０５…第１の端末（受信端末）１０６…第３のネットワーク（イーサネット）１０７…第２の端末（受信端末）２０１…送信端末２０２…１３９４ブリッジ（ネットワーク間接続装置）２０３…受信端末２０４…第１のＩＥＥＥ１３９４バス２０５…第２のＩＥＥＥ１３９４バス３０２、３１２…ブリッジ同期レジスタ（入力用（Ｉ
Ｎ）、出力用（ＯＵＴ））３０３…レイヤ３フローレジスタ

Claims

【特許請求の範囲】

【請求項１】複数の放送型ネットワーク間でデータ転
送を行う際に、少なくとも前記複数の放送型ネットワー
クのそれぞれに確立された通信路の対応関係を記憶手段
に記憶し、前記記憶しておいた対応関係に基づき前記複
数の放送型ネットワーク間でデータ転送を行うことを特
徴とする通信方法。
【請求項２】第１の放送型ネットワークと第２の放送
型ネットワークに接続されたネットワーク間接続装置で
あって、前記第１の放送型ネットワークに確立された第１の通信
路を用いて、複数の放送型ネットワークを介したデータ
フローの送受信を行う複数の通信装置のうちの少なくと
も１つに向けて前記複数の放送型ネットワークのそれぞ
れに通信路を確立するための要求を受けて、前記第２の
放送型ネットワークに第２の通信路を確立する確立手段
と、この確立手段で確立された第２の通信路と前記第１の通
信路との対応関係を記憶する記憶手段と、この記憶手段に記憶された対応関係に基づき、前記第１
の放送型ネットワークに確立された第１の通信路を用い
て送信されてきたデータを、前記第２の放送型ネットワ
ークに確立された前記第２の通信路に転送する転送手段
と、を具備したことを特徴とするネットワーク間接続装置。
【請求項３】第１の物理ネットワークと第２の物理ネ
ットワークに接続されたネットワーク間接続装置であっ
て、前記第１の物理ネットワークに接続されたノードと前記
第２の物理ネットワークに接続されたノードとの間でデ
ータを送受信する際の通信資源を確保するための論理ネ
ットワーク上のメッセージに基づき確保される前記第１
の物理ネットワークの通信資源の識別子と前記第２の物
理ネットワークの通信資源の識別子を対応付ける対応テ
ーブルを記憶する記憶手段と、前記メッセージに、そのメッセージに基づき確保される
通信資源を利用して転送されるデータが前記論理ネット
ワーク上のデータでない旨の情報が含まれているとき
は、前記確保された通信資源を利用して転送されるデー
タに対する論理ネットワークのデータ転送処理を省き、
前記対応テーブルを参照して前記第１の物理ネットワー
クに接続されたノードから受信したデータを前記第２の
物理ネットワークに接続されたノードに送信する送信手
段と、を具備したことを特徴とするネットワーク間接続装置。
【請求項４】前記論理ネットワークはインターネット
であり、前記送信手段は、ＲＳＶＰのＰＡＴＨメッセー
ジに、そのメッセージに基づき確保される通信資源を利
用して転送されるデータがインターネット上のデータで
ない旨の情報が含まれているときは、前記確保された通
信資源を利用して転送されるデータに対するインターネ
ットのデータ転送処理を省き、前記対応テーブルを参照
して前記第１の物理ネットワークに接続されたノードか
ら受信したデータを前記第２の物理ネットワークに接続
されたノードに送信することを特徴とする請求項３記載
のネットワーク間接続装置。
【請求項５】前記メッセージは、そのメッセージに基
づき確保される通信資源を利用して転送されるデータの
識別子を含み、前記第１および第２の物理ネットワーク
に確保される通信資源あるいは前記受信データの転送処
理は前記データの識別子に対応付けられていることを特
徴とする請求項３記載のネットワーク間接続装置。
【請求項６】所定のネットワークに接続された通信装
置において、データを送信あるいは受信する際の通信資源を確保する
ための論理ネットワーク上のメッセージを受信あるいは
送信する手段と、前記メッセージに、そのメッセージに基づき確保される
通信資源を利用して転送されるデータが前記論理ネット
ワーク上のデータでない旨の情報が含まれているとき
は、前記確保された通信資源を介して受信あるいは送信
されるデータに対する論理ネットワークのデータ転送処
理を省くことを特徴とする通信装置。
【請求項７】前記論理ネットワークはインターネット
であり、ＲＳＶＰのＰＡＴＨメッセージに、そのメッセ
ージに基づき確保される通信資源を利用して転送される
データがインターネット上のデータでない旨の情報が含
まれているときは、前記確保された通信資源を介して受
信あるいは送信されるデータに対するインターネットの
データ転送処理を省くことを特徴とする請求項６記載の
通信装置。
【請求項８】前記メッセージは、そのメッセージに基
づき確保される通信資源を利用して転送されるデータの
識別子を含み、前記確保された通信資源は前記データの
識別子に対応付けられていることを特徴とする請求項６
記載の通信装置。
【請求項９】複数の放送型ネットワークを介してデー
タフローの送受信を行う複数の通信装置のうちの少なく
とも１つに向けて前記複数の放送型ネットワークのそれ
ぞれに同一識別子の通信路を確立するため通知された、
少なくとも、前記識別子に対応させて前記複数の放送型
ネットワークのうちの１つに確立された第１の通信路と
前記識別子との対応関係を記憶手段に記憶し、前記識別
子に対応させて前記複数の放送型ネットワークのうちの
他の１つに確立された第２の通信路を用いて前記記憶し
ておいた対応関係に基づき前記複数の放送型ネットワー
間でデータ転送を行うことを特徴とする通信方法。
【請求項１０】複数の放送型ネットワークを介してデ
ータフローの送信あるいは受信を行う際に、少なくとも
予め指定された識別子に対応させて前記複数の放送型ネ
ットワークのそれぞれに確立された通信路のうちの１つ
と、前記複数の放送型ネットワークのそれぞれに確立さ
れた通信路を用いて送信あるいは受信される前記データ
フローの属性情報との対応関係とを記憶手段に記憶し、
前記記憶しておいた対応関係に基づき、前記データフロ
ーを送信あるいは受信することを特徴とする通信方法。
【請求項１１】第１の放送型ネットワークと第２の放
送型ネットワークに接続されたネットワーク間接続装置
であって、複数の放送型ネットワークを介してデータフローの送受
信を行う複数の通信装置のうちの少なくとも１つに向け
て前記複数の放送型ネットワークのそれぞれに同一識別
子の通信路を確立するため、前記第１の放送型ネットワ
ークを介して通知された、少なくとも、前記識別子に対
応させて前記第１の放送型ネットワークに確立された第
１の通信路と前記識別子との対応関係を記憶する記憶手
段と、前記識別子に対応させて前記第２の放送型ネットワーク
に確立された第２の通信路を用いて、少なくとも前記複
数の通信装置のうちの１つのアドレスと前記識別子と前
記第２の通信路との対応関係を通知する通知手段と、前記記憶手段に記憶された対応関係に基づき前記第１の
放送型ネットワークに確立された第１の通信路を用いて
送信されてきたデータを、前記第２の放送型ネットワー
クに確立された前記第２の通信路に転送する転送手段
と、を具備したことを特徴とするネットワーク間接続装置。
【請求項１２】複数の放送型ネットワークを介してデ
ータフローの送信あるいは受信を行う相手通信装置に向
けて前記複数の放送型ネットワークのそれぞれに同一識
別子の通信路を確立するため、少なくとも、相手通信装
置のアドレスと前記識別子に対応させて前記複数の放送
型ネットワークのうちの１つに確立された通信路と前記
識別子との対応関係とを通知する第１の通知手段と、この第１の通知手段で通知された内容に基づき前記複数
の放送型ネットワークのそれぞれに確立された通信路を
用いて送信あるいは受信される前記データフローの属性
情報と前記識別子との対応関係を前記相手通信装置に通
知する第２の通知手段と、を具備し、前記データフローを前記第１および第２の通信手段で通
知した対応関係に基づき送信あるいは受信することを特
徴とする通信装置。
【請求項１３】複数の放送型ネットワークを介してデ
ータフローの送信あるいは受信を行うため通知された、
少なくとも、前記複数の放送型ネットワークのそれぞれ
に確立された同一識別子の通信路のうちの１つと前記複
数の放送型ネットワークのそれぞれに確立された通信路
を用いて送信あるいは受信される前記データフローの属
性情報との対応関係を記憶する記憶手段を具備し、前記記憶手段に記憶された対応関係に基づき前記データ
フローを送信あるいは受信することを特徴とする通信装
置。