JP4327746B2 - 中継装置 - Google Patents

Description

本発明は、ホームネットワーク環境を構築するネットワークシステムに関する。

近年、マルチメディアという言葉に代表されるように、電子機器のデジタルが急速に進行している。この傾向は、まずオフィス環境で始まっている。

具体的には、まずハードウエアとしては、パソコンの導入、ＯＡ機器のデジタル化、及びそれらのネットワーク化という形で、進行している。また、ソフトウエアとして、ホストによる（あるいはライトサイジングされてパソコン等に移行されつつある）基幹業務や、ワープロ、表計算などのソフトウエア、あるいはＷＷＷ等のインターネットアプリケーション等、その発展はとどまるところを知らない。

この動きは、家庭においても見られる。即ち、家庭においても、ＡＶ機器のデジタル化（ＤＶＤ、デジタルＶＴＲ、デジタルビデオカメラ等）や、放送のデジタル化、あるいはＯＣＮ等のインターネットアクセス等の形で、デジタル化の進行は着実に進んでいる。

オフィス環境と同様に、これらの波はネットワーク化へと今後向かっていくことが考えられる。即ち、情報・通信・放送といった種々の分野の技術がデジタル化によって束ねられ、ネットワーク化によって、相互乗り入れを始めていく、と言われている。

このためのネットワーク技術としては、種々の候補が有る。例えば、イーサネットは、オフィス環境にて圧倒的な実績を持っており、家庭でのパソコンネットワークにおいても、その最有力候補であろう。また、ＡＴＭも有力な候補である。これは、インフラの構築側（電話会社やＣＡＴＶ等）が、高速、リアルタイム、広帯域といったＡＴＭの特徴に注目し、この技術を使ってインフラを構築していこうというのが一般的な動きであるからである。

これらの候補に加えて、最近ＩＥＥＥ１３９４なるネットワーク技術（バス技術）が注目を集めている。これは、高速、リアルタイム（ＱＯＳ保証）、プラグアンドプレイ等の数々の注目すべき特徴を持っており、特にＡＶ業界から、デジタルＡＶ機器同士の接続方式の最有力候補として、業界から大変な注目を集めている。これにひきづられる様に、パソコンなどのコンピュータ業界も、この技術への注目が集まりはじめた。

当初は、家庭向けのデジタル機器の普及に伴い、それらの機器の相互接続がユーザの好み・要望により、これらの数々のネットワーク技術により実現されていくだろう。このようにして、徐々に家庭内にデジタルネットワークの雛形が誕生していく。

その次の段階として、これらのデジタルネットワークを相互に接続したいという要求が出て来る。例えば、１階の応接間の１３９４ネットワークに接続されＡＶ機器と、２階の部屋の１３９４ネットワークに接続されたＡＶ機器とを、相互接続して、例えばダビング等、協調動作をさせようというような場合である。

しかしながら、これを実現するには、以下のような問題がある。

現在では、多くのＡＶ機器が１３９４専用端末として発売される可能性が高い。これは、現状ではインターネットやＢ−ＩＳＤＮ等のインフラの整備がまだまだ進んでおらず、これを見越したＡＶ機器の開発を進めにくいという現状が有る。

しかし、このようなインフラが整備されるに連れて、インターネットやＢ−ＩＳＤＮ対応のＡＶ機器が発売されてくるものと考えられるが、これらの機器と既存の１３９４専用端末間の相互接続が難しくなってしまう。また、そのような場合、この１３９４専用のＡＶ機器と同じ１３９４に接続された端末のみがＡＶデータのやり取りが出来る事になってしまい、１３９４以外のネットワークに接続されたノード、遠隔ノード等とのデータのやり取りを行う事ができないという問題点も生じる。

本発明は、異なるネットワーク間で、ＡＶデータの受け渡しを容易に行える中継装置を提供することを目的とする。

本発明の、第１のネットワークまたはケーブルと第２のネットワークまたはケーブルに接続された中継装置は、（ａ）第１のネットワークまたはケーブル上の各端末から当該端末のアドレス、当該端末が有するコンテンツ、属性情報のうちの少なくとも１つを収集し、（ｂ）第１のネットワークまたはケーブル上に、送信端末としての第１の端末から当該中継装置を通して第２のネットワークまたはケーブル上の受信端末としての第２の端末へ送信されるＡＶデータを伝送するためのコネクションを設定し、（ｃ）第1の端末に対してＡＶデータの送信を要求し、（ｄ）第２のネットワークまたはケーブル上に、第1の端末から当該中継装置を通して第２の端末へ送信されるＡＶデータを伝送するためのチャネルを設定し、（ｅ）前記コネクションを用いて第1の端末から送信されてきた、第１のネットワークまたはケーブルに依存するデータフォーマットのＡＶデータを受信すると、（ｆ）受信されたＡＶデータのデータフォーマットを、第２のネットワークまたはケーブルに依存するデータフォーマットに変換し、前記チャネルを用いて第２の端末へ送信する。

本発明によれば、異なるネットワーク間で、ＡＶデータの受け渡しを容易に行える。

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

（第１の実施形態）
図１に、第１の実施形態に係る通信ネットワークシステムの構成例を示したもので、例えば、家庭宅内のホームネットワークの構成例を示したものである。

図１に示すように、ホームネットワークは、送信端末１、第１のＡＶ制御端末２、第１のハーフコネクタ３、第２のハーフコネクタ４、第２のＡＶ制御端末５、受信端末６、第１の１３９４バス１１、第２の１３９４バス１２からなる。また、本実施形態では両ハーフコネクタ３、４間の伝送方式はＡＴＭであるとする。

送信端末１及び受信端末６は、非ＩＰ端末である（ＡＶ／Ｃプロトコルや、ＩＥＣ１８８３などに代表される、１３９４プロトコルしか理解できない端末である。以降１３９４プロトコルと呼ぶ）。即ち、インターネットプロトコルを解さない端末である。

本実施形態では、このようにＩＰプロトコルを理解出来ない端末同士（あるいは、どちらか一方がそのような場合）で、１３９４プロトコルによる通信が直接お互いにはできないような場合（すなわち、１３９４バス同士がブリッジ接続されていない場合、言い換えれば、両者の間に１３９４バス以外のネットワークが存在している場合や、インターネットやＩＳＤＮ等の公衆網が存在している場合）において、ＡＶ制御端末による制御により、両者が通信し合う方法について説明を行う。

両１３９４バスは、直接ブリッジ接続されているわけではなく、間にＡＴＭネットワークが存在するため、一方の１３９４バスにつながれた１３９４専用ノード（１３９４プロトコルしか理解できない端末）からは、他方の１３９４バスに接続された１３９４専用ノードは、１３９４プロトコル上からは見えないものとする。

これに対し、相互接続網プロトコルであるＩＰ端末（以下、ＩＰノードと呼ぶことがある）は、両１３９４バスに接続されたものであったとしても、他方のバスに接続されたＩＰ端末を認識できる。

送信端末１、受信端末６は、共に、いわゆる１３９４端末、即ちインターネットプロトコルは理解できず、ＩＥＥＥ１３９４において定められている１３９４専用のプロトコル、例えばＡＶ／ＣプロトコルやＩＥＣ１３３８の様なプロトコルのみを理解出来る端末である。また、１３９４の専用端末であっても良い。

両者を例えば映像端末（例えば送信端末１がＤＶＤプレーヤ、受信端末６がテレビ、といった場合）とし、かつ、両者が相異なる１３９４バス上にある時に、いかにして両者の通信を実現するかが問題となる。

図２に、ハーフコネクタ２、３の内部構成例を示す。図２に示すように、ハーフコネクタ２、３は、１３９４物理部１０１、１３９４リンク部１０２、第１のＭＵＸ−ＤＥＭＵＸ１０３、ＩＰ／ＦＡＮＰ処理部１０４、１３９４・ＡＴＭ乗換部１０５、第２のＭＵＸ−ＤＥＭＵＸ１０６、ＡＴＭインタフェース部１０７からなる。

１３９４物理部１０１、１３９４リンク部１０２は、それぞれ接続された１３９４バスについて、その物理レイヤ処理、リンクレイヤ処理及びバス管理及びとトランザクションレイヤ処理をそれぞれ行い、送受信する１３９４フレームを、第１のＭＵＸ−ＤＥＭＵＸ１０３または第２のＭＵＸ−ＤＥＭＵＸ１０６を通して、ＩＰ／ＦＡＮＰ処理部１０４または１３９４・ＡＴＭ乗せ換え部１０５とデータ（１３９４から見ると、ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ））のやりとりを行う。

ＩＰ／ＦＡＮＰ処理部１０４は、受信したＩＰパケット、ＦＡＮＰパケット（後述）、ＡＲＰパケット等について、ＩＰアドレスに基づくルーチング、ルーチングテーブルの管理、ＦＡＮＰ処理、ＡＲＰ処理等を行う機能を持つ（なお、ＦＡＮＰについては、特願平第８−２６４４９６号の記載参照のこと）。

１３９４・ＡＴＭ乗せ換え部１０５は、１３９４側から受信したデータ、特に同期チャネルを通して受信したデータを、その同期チャネル番号をキーとして、特定のＡＴＭのヘッダ（ＶＰＩ／ＶＣＩ値）を付与した後に、これをＡＴＭ側に送出する機能と、逆にＡＴＭ側から受信したデータを、そのヘッダ情報（ＶＰＩ／ＶＣＩ情報）をキーとして、１３９４側の特定の同期チャネルに送出する機能を有する。すなわち、この処理部におけるデータのフォワーディングはデータリンクレイヤ処理のみで行われる。

例えば、図３（１３９４側からの入力をＡＴＭ側に出力する場合）、図４（ＡＴＭ側からの入力を１３９４側に出力する場合）に示すような対応テーブルを用い、ＶＰＩ／ＶＣＩの値と１３９４バスの同期チャネルのチャネル番号との対応テーブルを作成する。この各々のマッピング（対応テーブルの作成）については、ＩＰ／ＦＡＮＰ処理部１０４が行う。

データフォワーディング機能については、後に説明するＦＡＮＰによる通信品質保証機能が備わっており、たとえばＷＦＱやＷＲＲ等のデータスケジューリング方式が実装されていてもよい。

ＡＴＭインタフェース部１０７は、物理的に接続されたＡＴＭ網（本実施形態の場合はＡＴＭケーブル）とのインタフェースを司る部分であり、第２のＭＵＸ−ＤＥＭＵＸ１０６とやりとりするデータと、ＡＴＭセルとのセル化、デセル化等を行う。ＡＢＲ（Ａｖａｉｌａｂｌｅ Ｂｉｔ Ｒａｔｅ）処理やＵＰＣ（Ｕｓａｇｅ Ｐａｒａｍｅｔｅｒ Ｃｏｎｔｒｏｌ）処理、あるいはＳＤＨ（Ｓｙｎｃｈｒｏｎｏｕｓ Ｄｉｇｉｔａｌ Ｈｉｅｒａｒｃｈｙ）処理などを行っても良い。

なお、特願平第８−２６４４９６号にて説明されているように、両１３９４コネクタ間には、ＡＴＭのデフォルトＶＣとして、あるＶＣが定義されており、ＦＡＮＰのメッセージはこのデフォルトＶＣを通ってやり取りされることを、双方のハーフコネクタ３、４が認識している。

第１のＡＶ制御端末２および第２のＡＶ制御端末５は、共にＩＰノードであり、かつＦＡＮＰノードであり、当然インターネットプロトコルにて通信する事の出来る端末である。これらＡＶ制御端末２、５は、後述するように、１３９４プロトコルとＩＰを理解することができ、１３９４プロトコルを使ってローカルな１３９４バス上の端末と通信をおこない、ＩＰをつかって、ローカル及びリモートのＩＰ端末と通信を行う事ができる。

図１中のＩＰノードは、それぞれ同一のＩＰサブネットに属するものとして、以降の説明を行う。

ＡＶ制御端末２、５には、「映像送受信制御アプリケーション」が実装されている。このアプリケーションは、
（１）お互いに自分のローカルバス上の資源（ノードなど）を調査し、この結果をお互いにＩＰを用いて通信し合う機能。
（２）（１）の情報を元に、リモートのバス上の端末の資源をユーザに表示し、それらの操作を行わさせる機能と、これらの制御情報をお互いに交換する機能。（３）お互いにＦＡＮＰパケットのやり取りを行い、該ＡＶ制御端末が位置する１３９４バス間の伝送パス（必要な場合は帯域等が確保されたコネクション）を確保する機能。
（４）ローカルバス上のノードの制御を１３９４のプロトコル（ＡＶ／Ｃプロトコルなど）を使って行う機能。

等がある。このＡＶ制御端末を使うことにより、ユーザは、リモートの１３９４バス上に位置する端末とのデータのやり取りを、たとえ送受信用の端末がＩＰ端末ではなかったとしても行うことができるようになる。

このように、ローカル、リモートに関わらず、１３９４上のＡＶ機器の制御を行うプロトコルを、ここではＦＡＮＰ−ＡＶプロトコルと呼ぶ。このプロトコルは、ＩＰアプリケーションであってもよい。

例えば、第１の１３９４バス１１が家庭宅内の部屋Ａに配置されており、第２の１３９４バス１２が家庭宅内の部屋Ｂに配置されている場合を考える。ここで、部屋Ｂにいるユーザが、部屋Ａにある送信端末１からの映像データを、部屋Ｂの受信端末６に映し出すことを行うとする。

なお、これら２つの部屋が同じ家庭宅内に属している必要は必ずしもない。その場合は、２つのハーフコネクタ３、４の間に公衆網が入ることになってもよい（この場合は、お互いに同一のＩＰサブネットに属するとは限らないので、後述するブロードキャストは行わず、手設定にてお互いのアドレスと存在を認識してもよい）。

以下、図５に示すシーケンスを参照して、非ＩＰ端末である送信端末１と受信端末６との間で映像データのやりとりを行うまでの手順（ＦＡＮＰ−ＡＶプロトコルを含む）について説明する。

まず、本発明の通信システムにおいては、該ユーザは、第２のＡＶ制御端末５を起動し、ＡＶ制御端末５上で必要な設定を行う。すなわち、図５に示すように、第２のＡＶ制御端末５は、ホームネットワーク上に、ＦＡＮＰ−ＡＶプロトコルを処理するノードの有無を確認するため、ホームネットワーク全体、即ちＩＰブロードキャストアドレスに「ＦＡＮＰ−ＡＶ要求」パケットを送出する（ステップＳ１）。

このパケットには、ＦＡＮＰ−ＡＶ処理機能にあらかじめ割り当てられたウエルノウンのポート番号が振られている。このＩＰブロードキャストパケットは、第２の１３９４バス１２上で、１３９４アドレスの「バスブロードキャストアドレス」、すなわち、その家庭のホームネットワークにおけるすべてのノードに対するブロードキャストの形で非同期チャネルに送出される。このブロードキャストパケットは、第２の１３９４バス１２上の全てのノードに到達する。ちなみに、このパケットを、１３９４アドレスの「ローカルバスブロードキャスト」に送出される形でも、そのＩＰサブネット内の全てのノードに届くようになっていれば良い。すなわち、１３９４バス以外のネットワークが接続されている場合でも、これが配送されるようになっていればよい。

さて、これを受信した第２のハーフコネクタ４は、これが「全てのバスに対するブロードキャスト」であることを宛先１３９４アドレスにより確認すると、これを第１のハーフコネクタ３の側にフォワードする。これを受信した第１のハーフコネクタ３は、今度はこれを第１の１３９４バス１１にフォワードする（ステップＳ２）。その際の、宛先１３９４アドレスは「バスブロードキャストアドレス」である。

ここで、自らがＦＡＮＰ−ＡＶプロトコルを稼動させているノードは、このパケット（ＦＡＮＰ−ＡＶ要求パケット）を受信し、ポート番号を参照することによって、これが「ＦＡＮＰ−ＡＶ要求」、即ちＦＡＮＰ−ＡＶプロトコルを稼動しているノードを探すためのパケットであることを確認すると、このパケットに対する返答として、「自分もＦＡＮＰ−ＡＶプロトコルを稼動させている」という旨の「ＦＡＮＰ−ＡＶ応答」パケットを送信ＩＰアドレスに対して送出する（ステップＳ３）。図５では、第１のＡＶ制御端末２が、ＦＡＮＰ−ＡＶプロトコルノードであるため、この端末がＦＡＮＰ−ＡＶ応答パケットを「ＦＡＮＰ−ＡＶ要求」パケットの送信元である第２のＡＶ制御端末５に送出する。それとともに、第１のＡＶ制御端末２は、第２のＡＶ制御端末５が存在することと、そのＩＰアドレスを記憶しておく。

なお、前述のように、このような自動的な構成認識を行うのではなく、各々のＡＶ制御端末にあらかじめ手設定でお互いのアドレスなどを登録しておく、等の方法を使う事により、お互いを認識させておいても良い。

これと前後して、各ＦＡＮＰ−ＡＶノード（ＡＶ制御端末２、５）は、自分の接続された１３９４バス上に有るＡＶ機器についての情報を、１３９４プロトコルを用いて収集する（ステップＳ４、ステップＳ５）。これには、１３９４トレードアソシエーションやＨＤ−ＤＶＴＲ協議会等で標準化しているＡＶ／Ｃプロトコル等、あるいはこれらを拡張したものを用いて、これを行っても良い。

こうして各ＡＶ制御端末２、５は、自分が所属する１３９４バス上のＡＶ機器についての情報、すなわち、どのようなＡＶ機器か、どのようなコンテンツが有るか、何枚のメディアを持っているか、その１３９４アドレスは何か、といった各種の情報を収集し、内部のテーブルに記憶する。

次に、各ＡＶ制御端末２、５は、お互いのこれらの情報を交換する（ステップＳ６）。この情報の交換には、ＩＰパケットを用い、お互いのＩＰアドレス宛にこれらの情報を送信しあう。その結果、各ＡＶ制御端末２、５には、例えば、図６に示すような内容のテーブルが作成されることになる。すなわち、各ＡＶ制御端末２、５は、自分が所属する１３９４バス上のＡＶ機器についての情報以外に、各ＡＶ制御端末２、５との間で情報交換を行うことにより、他のＡＶ制御端末が所属するネットワークに接続されたＡＶ機器等の情報（属性情報）、すなわち、どのようなＡＶ機器か、どのようなコンテンツが有るか、何枚のメディアを持っているか、その１３９４アドレスは何か、といった各種の情報が、図６のテーブル上に収集できる。

また、ＡＶ制御端末２、５の画面等に図６のテーブル上の情報を表示させることも可能である。図７に第２のＡＶ制御端末５に具備されたディスプレイ装置の画面表示例を示す。図７では、見やすさのため、１部屋１バス（あるいは１部屋１データリンクネットワーク）と考えて、表示画面中の各表示ウインドウ（Ｗ１〜Ｗ４）に、それぞれ各部屋のネットワークを対応させ、部屋毎の配置の形で画面表示を行っている。ユーザは、これをみて、「どの端末から、データを送ってもらうか。あるいは、送るか」といった判断を行うことができる。

例えば、部屋Ｂのユーザは、送信端末１から、映像データを送ってもらい、受信端末６に表示させたいと思っているとする。そこで、該ユーザは、第２のＡＶ制御端末５を操作し、送信端末１のしかるべきコンテンツである映像を、受信端末６に送信し、そこで表示させるように設定をおこなう。この操作は、第２のＡＶ制御端末５上のＧＵＩを通して行われても良い。すると、第２のＡＶ制御端末５は、「送信端末１のしかるべきコンテンツである映像を、受信端末６に送信せよ」という内容の命令を、第１のＡＶ制御端末２に対して送信する（ステップＳ７）。これにより、第１のＡＶ制御端末２は、送信先の送信端末１のアドレスを、１３９４アドレスとして知ることができる。

この命令を受信した第１のＡＶ制御端末２は、送信端末１と１３９４プロトコルにて通信し、映像送信が可能であるかどうかのチェックなどを行う。また、第２のＡＶ制御端末２との間で認証などの動作を行っても良い。

次に、第１のＡＶ制御端末２は、第１の１３９４バス１１にて、１３９４のプロトコルおよび１３９４ＡＶプロトコル等を使って、第１の１３９４バス１１の同期チャネルを確保する（ステップＳ８）。このとき確保したチャネル番号を＃Ｘとする（図８の同期チャンネル３１）。また、このとき、１３９４バス１１の同期リソースマネージャに働きかけ、映像送信に必要な帯域を確保することは言うまでもない。

次に、第１のＡＶ制御端末２は、第１のハーフコネクタ３に対して、同期チャネルの＃Ｘを受信するように設定する。そして、この同期チャネルを通して、ＦＡＮＰのオファーメッセージを第１のハーフコネクタ３に向かって送出する（ステップＳ９）。

ここで、ＦＡＮＰ（Ｆｌｏｗ Ａｔｔｒｉｂｕｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）とは、前述の通り、特願平第８−２６４４９６号に記載されているプロトコルである。すなわち、このプロトコルは、隣接のＦＡＮＰを解釈するノード（通常は、ホームネットワークを構成するネットワークのセグメントとセグメントの中間におかれ、これら複数のセグメントの相互接続装置の位置づけとなる）との通信を行い、送信するデータを通すチャネルの識別子と、宛先アドレスおよび、その通信属性や通信品質を通知するために用いる。また、これを、エンド−エンドのコネクションの設定のために用いることもできる。

さて、このオファーメッセージには、データ（本実施形態の場合、映像データ）をこれから送信するチャネル番号（または、仮想チャネル識別子等）、該映像データの宛先アドレス（本実施形態の場合ＩＰアドレス）、使用する帯域（通信品質）、通信属性（ＭＰＥＧ等の符号化方式など）、エンド−エンドのＡＣＫの要求等が運ばれる。なお、該送信するチャネル番号、または仮想チャネル識別子等を両端の端末で共有していない場合は、両端でＦＡＮＰのプロポーズメッセージとプロポーズＡＣＫメッセージのやり取りを行ってもよい。また、該データの宛先アドレス（ターゲットＩＰアドレス）は、第２のＡＶ制御端末５のＩＰアドレスである。

オファーメッセージを受け取った第１のハーフコネクタ３は、内部のルーチングテーブルを参照して、第２のＡＶ制御端末５が第２のハーフコネクタ４の方向にあることを確認すると、そのオファーメッセージにて要求されている帯域、通信品質などが、ハーフコネクタ４内部の通信路の空き帯域等を参照することによりサポートできるかを確かめる。サポート可能と判断した場合は、プロポーズメッセージ、プロポーズＡＣＫメッセージ、オファーメッセージ等を前述の処理と同様に第２のハーフコネクタ４に送出する。なお、サポートできないと判断した場合は、リジェクトメッセージを第１のＡＶ制御端末２に送出する。

第２のハーフコネクタ４は、内部の通信資源の確認後（第１のハーフコネクタ３と同様に、オファーメッセージに記載された通信品質が内部的に可能であるかどうかを確認）、第２の１３９４バス１２上に同期チャネル＃Ｙ（図８の同期チャネル３３）を確立し（ステップＳ１０）、これと前後して、１３９４プロトコルを用いて、第２のＡＶ制御端末５に、この同期チャネルの内容を取り込むように指示する。その後、第２のＡＶ制御端末５との間で、プロポーズメッセージ、プロポーズＡＣＫメッセージ、オファーメッセージのやり取りなどを行う（ステップＳ１１）。

プロポーズメッセージ、オファーメッセージを受け取った第２のＡＶ制御端末５は、これが自分が先に第１のＡＶ制御端末２に嘆願した映像伝送のためのものであることを、フローＩＤや、あらかじめ両者の間で合意した、定められた識別子等により認識する。この定められた識別子は、ＦＡＮＰメッセージにより運ばれてきたものであってもよい。

次に、第２のＡＶ制御端末５は、ＩＥＣ１３３８等の１３９４プロトコルを用いて、受信端末６に対し、同期チャネル＃Ｙを介して送信されるデータを受信する様、指示する（ステップＳ１２）。これにより、同期チャネル＃Ｙを介して送出されたデータは受信端末６により受信できることになる。

その後、第２のＡＶ制御端末５は、リダイレクトメッセージを第２のハーフコネクタ４に送出する（ステップＳ１３）。このリダイレクトメッセージは、ステップＳ１１のオファーメッセージで申しだされた設定を受諾した、との意味を持つメッセージである。オファーメッセージにエンド−エンドＡＣＫの要求があった場合、エンド−エンドのＡＣＫのフラグを「オン」にして（エンド−エンドのＡＣＫを「オン」にするとは、送信端末１から受信端末６までの映像データを送信するための経路が設定できた旨を示すものである）、リダイレクトメッセージを送出する。このＡＣＫのフラグは、送信端末（本実施形態の場合、第１のＡＶ制御端末２）まで到達する。

リダイレクトメッセージを受信した第２のハーフコネクタ４は、内部のデータリンクレイヤの乗せ換え部１０５の適切な設定（具体的には、図３、図４に示したような対応テーブルの設定）を行う。すなわち、ステップＳ９でのオファーメッセージで申し出のあったＡＴＭ仮想コネクション３２（図８参照）と、同期チャネル＃Ｙとをデータリンク的にスイッチ接続する。具体的には、ＡＴＭ／１３９４乗せ換え部１０５では、ＡＴＭ仮想コネクション３２から入力されたＡＴＭセルを、ＩＰ／ＦＡＮＰ処理部１０４における処理を受けることなく、直接ＶＣＩの値が参照されて、１３９４データへの乗せ換えが行われ、同期チャネル＃Ｙに入れる。その際は、ＦＡＮＰにて定められた通信品質が保たれるようなデータ／パケットスケジューリング方式が選択されてもよい。なお、このとき参照されるＡＴＭ／１３９４乗せ換え部１０５内の対応テーブルは図３、図４に示したものである。

リダイレクトメッセージは、第２のハーフコネクタ４から、第１のハーフコネクタ３（第２のハーフコネクタ４と、同様の操作、すなわち、ＡＴＭ／１３９４乗せ換え部１０５の設定を受ける）、第１のＡＶ制御端末２へと返る（ステップＳ１４）。

ここで、第１のＡＶ制御端末２は、最終端末（本実施形態の場合、受信端末６である。ただし、受信端末６は、ＦＡＮＰやＩＰが理解できるノードではなく１３９４の専用端末である。受信端末６が映像データを受信できるように準備を行ったのは、第２のＡＶ制御端末５であり、これが１３９４プロトコルにより、設定を行った。）まで、データリンクレイヤコネクションが図８に示したように整ったことを確認する。

そして、第１のＡＶ制御端末２は、送信端末１に対し、１３９４プロトコルにて、該当する適当な映像の送信を、チャネル番号＃Ｘの同期チャネル（図８の同期チャネル３１）に対して行うように指示する（ステップＳ１５）。

送信された映像は、第１の１３９４バス１１上の同期チャネル３１、ＡＴＭ仮想コネクション３２、第２の１３９４バス１２上の同期チャネル３３を通過して、受信端末６に到達する（ステップＳ１６）。その間、途中ノード（ハーフコネクタ３、４）では、データリンクレイヤによるスイッチングを受けているのみである。よって、この経路を通る間、通信品質は保証されたまま、データ転送が行われる。

この映像送信を持続するためのリダイレクトメッセージの送信は、第２のＡＶ制御端末５から上流側（すなわち、第２のハーフコネクタ４から第１のハーフコネクタ３を通り、第１のＡＶ制御端末２）に向かって行われる（ステップＳ１７）。

また、ユーザ側からの送信の中断の要請（リリースメッセージの送信）も、第２のＡＶ制御端末５から同様の順序で送られる。その際は、第１のＡＶ制御端末２が、送信端末１に向かって、映像の送信を終了するようにＡＶ／Ｃプロトコル等の１３９４プロトコルにて制御を行う。

以上説明したように、本実施形態の通信ネットワークシステムによれば、送信端末１から、受信端末６までの映像の配信、中断等の、複数の１３９４バスをまたがるＡＶ機器の制御を、送信端末１と受信端末６がＩＰ端末ではないにもかかわらず（すなわち、ＡＶ制御端末２、５を介して）、ＦＡＮＰとＦＡＮＰ−ＡＶプロトコルにて行われている。

一般にＩＰを実装するにはコストがかかるといわれているが、本発明の方式を用いることにより、ＩＰを実装していないＡＶ機器間の制御、複数の１３９４バスをまたがるコネクションの制御等を、ＩＰとＦＡＮＰを実装したＡＶ制御端末２、５により行うことができ、全体システムとしての簡単化、低コスト化、制御の集中化等を行うことができる。また、ハーフコネクタ間に複数のＦＡＮＰノードが存在しても、全く同じ原理でこれを実現できること明白である。よって、１３９４バスの欠点である複雑な１３９４ブリッジプロトコルや、長距離の１３９４バス転送を行うことなしに、任意の１３９４上のＡＶ端末間の制御を行うことができる。

なお、本実施形態において、ＡＶ制御端末２、５同士はＩＰを用いて通信を行うことを前提としてきたが、ＩＰの代わりに他のネットワークレイヤ技術（例えばＮｅｔｗａｒｅやＣＬＮＰ（Ｃｏｎｎｅｃｔｉｏｎｌｅｓｓ Ｎｅｔｗｏｒｋ Ｐｒｏｔｏｃｌ）等）やＩ−ＰＮＮＩ（Ｉｎｔｅｇｒａｔｅｄ Ｐ−ＮＮＩ）等の技術を用いてこれを実現する事も可能である。

また、本実施形態において、ＦＡＮＰと呼ぶプロトコルを用いて両ＡＶ制御端末２、５間のコネクション（チャネル）の設定を行ってきたが、ＦＡＮＰの代わりにＲＳＶＰ（Ｒｅｓｏｕｒｃｅ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）やＳＴ２（Ｓｔｒｅａｍ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ−２）、あるいはＩ−ＰＮＮＩ等のコネクション設定プロトコルを用いても、実現は容易である。

また、本実施形態において、送信端末１、受信端末６が接続されたネットワークが、ＩＥＥＥ１３９４バスであることを前提としてきたが、ＦＤＤＩ２や、特願平第８−１０８０１５号記載の「ＡＴＭ通信システム」にあるような家庭内ＡＴＭ−ＬＡＮのようなブロードキャストベースのネットワークについては、本実施形態における説明と同様の操作により、これを実現することが可能である。また、ブロードキャストベースのネットワークでない場合も、サードパーティセットアップのように、ＡＶ制御端末が、ハーフコネクタと送信／受信端末との間のコネクション設定を行ってやることにより、これを実現することも可能である。

また、本実施形態において、ＡＶ制御端末２、５とハーフコネクタ３、４は別の筐体にあるものとして説明を行ってきたが、同一の筐体内にこれが存在してもよい。すなわち、ＡＶ制御端末２とハーフコネクタ３が同一の筐体内にあり、ＡＶ制御端末５とハーフコネクタ４が同一の筐体内にある場合、ハーフコネクタ３、４自身が、ＡＶ制御端末２、５の機能をそのまま持つものと考えればよい。

また、本実施形態において、ＡＶ制御端末２、５同士がお互いに、ローカルのバス上のＡＶ機器に関する情報について、情報を交換し合う方法について述べたが、ＡＶ制御端末の数が増えてきた場合は、お互いにメッシュ接続の形にして、これらの情報の交換を行ってもよいし、サーバとなるＡＶ制御端末がほかのＡＶ制御端末に対してこの情報を分配するようなやり方、あるいは、その中間（あるＡＶ制御端末が、複数のＡＶ制御端末に関する情報をアグリゲートして、他のＡＶ制御端末に通知する）の方法を用いてもよい。

また、本実施形態において、ユーザがＡＶ制御端末の操作を行っている時、その制御過程は、受信端末６に具備されるディスプレイ装置に表示するようになっていてもよい。

（第２の実施形態）
次に、エンド−エンドのデータの伝送がＲＳＶＰやＳＴ２等のネットワークレイヤのシグナリングプロトコルにより制御されており、該ネットワークレイヤのネットワークとのデータのやり取りを行う場合について説明する。

図９は、第２の実施形態に係る通信ネットワークシステムの構成例を示したものである。図９において、ＡＶ制御端末１１０３がインターネット１１０２（あるいは任意のネットワーク）に接続されており、１３９４バス１１０４を経て、受信端末１１０５に接続されている。そして、インターネット１１０２に接続されたビデオサーバ１１０１からビデオデータの配信が、例えば受信端末１１０５対し行われるものとする。

ビデオサーバ１１０１は、インターネット端末であり、ビデオデータをＩＰパケットに乗せて、すなわち、ＭＰＥＧｏｖｅｒＩＰの形で送出する。例えば、ＭＰＥＧのＴＳ（タイムスタンプ）をＲＴＰによる伝送を行う、等の形態でもよい。

ＡＶ制御端末１１０３は、インターネット１１０２と１３９４バス１１０４の間に接続されて、インターネット１１０２側への制御、１３９４バス１１０４側への制御、および、両者からの通信の整合を取り、一方のネットワークから他方のネットワークへデータを送出する機能を有する。

ＡＶ制御端末１１０３は、いわゆるセットトップボックスと呼ばれるユニットであってもよい。

受信端末１１０５はビデオデータの受信を行う、１３９４プロトコルのみを理解できる非ＩＰ端末である。よって、ＭＰＥＧデータの受信はたとえばＩＥＣ１８８３に定められた、ＭＰＥＧｏｖｅｒ１３９４のデータフォーマットに従う必要がある。

前述したように、本実施形態では、ビデオサーバ１１０１からのビデオデータの転送は、インターネット１１０２を通して、ＭＰＥＧｏｖｅｒＩＰの形で送信されて来るものとする。このビデオデータの伝送を、インターネット１１０２内にて通信品質を保ちつつ、これを行うために、インターネット１１０２内ではＲＳＶＰにて通信品質の保証を行う（無論、ＳＴ２やＦＡＮＰによる保証を行ってもよい。本実施形態では、ＲＳＶＰの場合についての説明を行う）。

以下、図９に示した通信ネットワークシステムにおいて、ビデオサーバ１１０１からのビデオデータを、どのようにＩＰ端末ではない受信端末１１０５まで送信するかについて説明を行う。

図１０にＡＶ制御端末１１０３の内部構成例を示す。図１０に示すように、ＡＶ制御端末１１０３は、外部網インタフェース１２０１、第１のＭＵＸ−ＤＥＭＵＸ１２０２、ＲＳＶＰ処理部１２０３、１３９４ＡＶ処理部１２０４、ＭＰＥＧｏｖｅｒＩＰ／ＭＰＥＧｏｖｅｒ１３９４変換部１２０５、第２のＭＵＸ−ＤＥＭＵＸ１２０６、１３９４インタフェース１２０７からなる。

外部網インタフェース１２０１は、インターネット１１０２とのインタフェース、特にデータリンクレイヤと物理レイヤのインタフェースを司るものである。受信したデータは必要に応じて、第１のＭＵＸ−ＤＥＭＵＸ１２０２を介して、ＲＳＶＰ処理部１２０３あるいはＭＰＥＧｏｖｅｒＩＰ／ＭＰＥＧｏｖｅｒ１３９４変換部１２０５に送出される。

ＲＳＶＰ処理部１２０３は、インターネット１１０２を通して、ＲＳＶＰの処理を行い、ＡＶ制御端末１１０３とインターネット１１０２に接続された任意端末（本実施形態の場合ビデオサーバ１１０１）との間に通信品質を保証した経路を確保する機能と、ＩＰ処理の機能を有する。

１３９４ＡＶ処理部２０４は、１３９４バス１１０４を通して、第１の実施形態において説明した１３９４ＡＶプロトコル（ＡＶ／Ｃプロトコル、ＩＥＣ１８８３等）、あるいは、ＦＡＮＰ−ＡＶプロトコルの処理を行う機能を有する。

ＭＰＥＧｏｖｅｒＩＰ／ＭＰＥＧｏｖｅｒ１３９４変換部１２０５は、インターネット１１０２からＭＰＥＧｏｖｅｒＩＰのフォーマットで入力されたＭＰＥＧフレームをＭＰＥＧｏｖｅｒ１３９４のフォーマットに乗せ換え、これを送出する機能を有する。無論、逆方向の変換機能を有していても良い。このフォーマットの乗せ換えは、到着したＩＰパケットのソースアドレス、宛先アドレス、ポート番号、フローラベル等を参照して行っても良いし、インターネットが仮想コネクション型ネットワークである場合は、仮想チャネル識別子、あるいはチャネル番号等を参照してこれを行っても良い。本実施形態では、後者の処理が取られるものを例にとり説明する。

１３９４インタフェース１２０７は、１３９４バス１１０４とのインタフェース、具体的には物理レイヤ、リンクレイヤ、トランザクションレイヤ、バス管理等の処理を行う機能を有する。

図１０に示した構成のＡＶ制御端末は、受信端末１１０５が、ＭＰＥＧの再生機能（ＭＰＥＧのデコード機能）を有している場合のものである。このほか、ＡＶ制御端末１１０３は、一般にセットトップボックスとよばれる機能（アナログ回路などを含む）を有していても良い。

ユーザは、受信端末１１０５にて、ビデオサーバ１１０１からの映像データの受信を望む場合には、ＡＶ制御端末１１０３に働きかける。すなわち、ＡＶ制御端末１１０３に対して、どのビデオサーバから、どの映像を送ってもらい、どの受信端末にてそれを受信（鑑賞）したいかについて設定を行う。

このとき、ユーザはＡＶ制御端末１１０３に直接働きかけるのではなく、他の端末に働きかけを行い、該他の端末から該ＡＶ制御端末に対して、以降の一連の制御を要請するような制御メッセージが送られるような構成になっていても良い。

ＡＶ制御端末１１０３は、ＩＰノードであるビデオサーバ１１０１に対して、映像データの送信をＩＰプロトコルにて要求する。ＨＴＴＰ等のプロトコルを通して、これを行ってもよい。また、ＩＴＵ−ＴやＤＡＶＩＣ等により定められているＤＳＭ−ＣＣ等の制御プロトコルが、インターネット上を流れていく形になっていてもよい。

この時、ＲＳＶＰのＰＡＴＨメッセージがビデオサーバから流れてきており、これに対してＡＶ制御端末１１０３からＲＳＶＰのＲＥＳＶメッセージを送ることにより、ビデオーサーバ１１０１とＡＶ制御端末１１０３間にＱＯＳを確保した経路を確立しても良い（図１１のステップＳ１０１）。

さらに、ＡＶ制御端末１１０３は、受信端末１１０５に対して、１３９４バス１１０４上の同期チャネル（チャネル番号＃ｘ）を確立し、ＩＥＣ１８８３やＡＶ／Ｃプロトコル、あるいは１３９４−１９９５といった１３９４プロトコルにより、該同期チャネルからのデータの受信を指示するメッセージを送出する（図１１のステップＳ１０２、ステップＳ１０３）。

これと共に、ＭＰＥＧｏｖｅｒＩＰ／ＭＰＥＧｏｖｅｒ１３９４変換部１２０５の設定、具体的にはインターネット１１０２から入力されるＭＰＥＧｏｖｅｒＩＰのパケットのヘッダ情報（該パケットを通すデータリンクレイヤコネクションの識別子、あるいはＩＰヘッダ情報、あるいはフローラベルなど）から、該パケットを取り出し、これをＭＰＥＧｏｖｅｒ１３９４のデータフォーマットに変換して、定められた１３９４バス１１０４上の同期チャネル＃Ｘ（図１２の同期チャネル１１１１）に送出するような設定がなされる（ステップＳ１０４）。この処理は、ジッタや遅延時間といった通信品質を保証する形で設定されるようにしてもよい。

これにより、ビデオサーバ１１０１から受信端末１１０５にいたる経路１１１０、１１１１（通信品質の確保された経路）が図１２に示すように確保されたことになる。

ここで、インターネット１１０２を通ってきたパケットのうち該ＭＰＥＧパケットについては、該変換部１２０５にフォワーディングし、そこでのフォーマット変換をかけるトリガとなる情報は、例えば、インターネット１１０２のアクセスデータリンクが例えばＡＴＭなら、該ＭＰＥＧデータを運ぶＶＰＩ／ＶＣＩの値から、これを行っても良い。この場合、ＩＰ層まで、その処理を持ち上げる必要はない。

また、アクセスデータリンクがＳＴＭ網なら、そのチャネル番号／特定のタイムスロットからの入力等を用いてこれを行っても良い。この場合も、ＩＰ層まで、その処理を持ち上げる必要はない。

また、該インターネットパケットのヘッダ情報の一部（例えば、宛先アドレス＋ポート番号、ＩＰｖ６のフローラベル等）を用いてこれを行ってもよい。

ビデオサーバ１１０１からは、ＭＰＥＧｏｖｅｒＩＰのフォーマットで、ＭＰＥＧデータが送られて来るので、これをＡＶ制御端末１１０３は、変換部１２０５において、ＭＰＥＧｏｖｅｒ１３９４フォーマットに乗せ換えた上で受信端末１１０５に送出する（ステップＳ１０５）。

このようにして、ＩＰ端末ではない受信端末（本実施形態では受信端末１１０５）においても、ＩＰで送信されてきたビデオデータの受信を行うことができる。

なお、１３９４バス１１０４の部分は、ブリッジ接続された１３９４バス群であっても良い。また、１３９４バスがエミュレートされている、他のネットワークとの混在網で構成されたネットワークであっても良い。

インターネット１１０２の代わりに、家庭へのアクセス網としてＡＴＭアクセス網が適用されている場合も考えられる。その場合の通信ネットワークシステムの構成例を図１３に示す。図９と異なる部分は、図９のインターネット１１０２がＡＴＭアクセス網１５０２に置き換わっていることである。

なお、この場合は、図１３において、ＡＶ制御端末１５０３やビデオサーバ１５０１はＡＴＭ端末（ＡＴＭ−ＡＰＩのみが理解・処理できる端末）になっていてもよく、よってＡＶ制御端末１５０３とビデオサーバ１５０１間のやり取りは、ＡＴＭシグナリングによる呼設定等が絡んでくることになる。

ＡＶ制御端末１５０３の内部構成例を図１４に示す。図１４に示すように、フォーマット変換は、変換部１６０５において、ＭＰＥＧｏｖｅｒＡＴＭフォーマットとＭＰＥＧｏｖｅｒ１３９４フォーマットとの間にて行われることになる。ここで、ＭＰＥＧｏｖｅｒＡＴＭのフォーマットは、ＡＴＭフォーラムのＡＭＳにて定められたプロトコルに従った形であってもよい。

ＡＶ制御端末１５０３とビデオサーバ１５０１間のＡＴＭシグナリングによる呼設定等は、ＡＴＭシグナリング処理部１６０３で行われるようになっている。

その他各部の機能は、図１０と同様である。
図１５に図１３に示した通信ネットワークシステム全体の動作を示すシーケンスを示す。図１１と異なる部分は、図１５のステップＳ２０１で（図１１のステップＳ１０１に対応）、ビデオーサーバ１５０１とＡＶ制御端末１５０３間に経路を確立する際に、ＡＴＭシグナリングによる呼設定を行う仮想コネクション（ＶＣＩ＝＃ｘ）を確立する点である。その他の部分はほぼ同様である。

ちなみに、本実施形態では、家庭内のネットワークが１３９４バスで構成されている例を示したが、本発明の手法は、家庭内のネットワークが１３９４バスではなく、他のネットワーク技術（例えばＡＴＭ等）においても適用可能であることはいうまでもない。

以上の実施形態では、受信端末側にＭＰＥＧデコーダが配置されている場合についての例を示してきた。これに対し、ＭＰＥＧデコーダが受信端末側には存在せず、生の映像データをそのまま受け取り、これを映し出す機能しか有しない場合も考えられる。

このような場合、例えば、図９の通信ネットワークシステムにおいて、ＡＶ制御端末１１０３にてフォーマット変換をする代わりに、ＭＰＥＧデコーダ１８０５を図１６に示すように、ＡＶ制御端末１１０３内に配置し、ＡＶ制御端末１１０３に入力されるＭＰＥＧｏｖｅｒＩＰデータ（あるいはＭＰＥＧｏｖｅｒＡＴＭデータなど）について、ＡＶ制御端末１１０３内でＭＰＥＧデコードを済ませてしまい、１３９４バス１１０４を介して受信端末１１０５に対しては、ＭＰＥＧ復号化が終わった生の映像データを送信する構成とすることも可能である。この場合のシーケンスを図１７に示す。すなわち、図１１と異なる部分は、図１１のステップＳ１０４〜ステップＳ１０５が、図１７では、ステップＳ１１１〜ステップＳ１１３に置き換わっていて、フォーマット変換を行わずに、ＭＰＥＧデコード部１８０５にてＭＰＥＧｏｖｅｒＩＰデータ（あるいはＭＰＥＧｏｖｅｒＡＴＭデータなど）をＭＰＥＧデコードして生の映像データを１３９４バス１１０４上の同期チャネル＃ｘを介して受信端末１１０５に送出するようになっている（図１７のステップＳ１１１〜ステップＳ１１３）。

これにより、ＡＶ制御端末１１０３にＭＰＥＧの復号化などの高度な機能が集中するようになるため、受信端末１１０５の負荷が小さくなるというメリットもある。図９ではビデオサーバ１１０１とＡＶ制御端末１１０３間がインターネットで有るものとしているが、無論、インターネットに限定するものではなく、ＡＴＭ網やＳＤＨ網、ＦＴＴＨ等のネットワーク構成においても本手法をとることが可能である。

なお、ＡＶ制御端末１１０３の構成として、同時に複数のＭＰＥＧストリームの処理が可能となるような構成も考えられる。この場合、ストリーム毎に別個の処理、例えば、あるＭＰＥＧストリームについてはＭＰＥＧデコード、別のあるＭＰＥＧストリームについてはＭＰＥＧｏｖｅｒＩＰからＭＰＥＧｏｖｅｒ１３９４へのフォーマット変換を行うといった処理形式も可能である。この場合は、ＡＶ制御端末１１０３内部に、複数のＭＰＥＧデコーダや、ＭＰＥＧエンコーダ、
あるいは乗せ換え部を具備すればよい。

（第３の実施形態）
図１８に第３の実施形態に係る通信ネットワークシステムの全体の構成例を示す。

図１８に示すように、第３の実施形態に係る通信ネットワークシステムは、ルータ２００１、第１のハーフコネクタ２００２、第２のハーフコネクタ２００３、ＡＶ制御端末２００４、受信端末２００５、インターネット２０１１、第１の１３９４バス２０１２、第２の１３９４バス２０１３からなる。

図１８において、ルータ２００１を含め、ルータ２００１より右側の機器（ルータ２００１、第１の１３９４バス２０１２、第１のハーフコネクタ２００２、第２のハーフコネクタ２００３、第２の１３９４バス２０１３、ＡＶ制御端末２００４、映像端末２００５）から構成されるネットワークは家庭内に構成されるもの（ホームネットワーク）であっても良い。

また、本実施形態においても、第１の実施形態と同様に、受信端末２００５は非ＩＰ端末とする。

ここで、インターネット２０１１上にあるビデオサーバ（図示せず）からのビデオデータ（ＭＰＥＧｏｖｅｒＩＰで伝送されてくるとする）を、非ＩＰ端末である受信端末２００５にて受信する場合を考える。

なお、ここでも、第２の実施形態と同様に、インターネットあるいはビデオサーバとＩＰにて直接ネゴシエーションするのはＡＶ制御端末２００４である。

第２の実施形態と異なる部分は、ＭＰＥＧｏｖｅｒＩＰからＭＰＥＧｏｖｅｒ１３９４への乗せ換え制御を行うのが、ＡＶ制御端末２００４ではなく、第２のハーフコネクタ２００３である点である。（なお、該乗せ換え制御を行うのは、第２のハーフコネクタ２００３ではなく、第１のハーフコネクタ２００２であってもよいし、ルータ２００１であってもよい。本実施形態では、乗せ換え制御は第２のハーフコネクタ２００３にて行うものとする）
このため、ＡＶ制御端末２００４は第２の１３９４バス２０１３につながれてはいるが、第１の実施形態のように、インターネット２０１１から受信端末２００５に至る経路上にある必然性は必ずしも無い。

また、ここでは第２のハーフコネクタ２００３が、受信端末から見て、セットトップボックスのように見えても良い。

また、本実施形態においては、インターネットのサブネット間（ＩＰサブネットとＩＰサブネットの境界間）での帯域制御はＲＳＶＰにて行い、サブネット内（即ちルータ２００１よりも右側の構成部）については、第１の実施形態にて説明したＦＡＮＰを用いるものとする。よって、ルータ２００１とＡＶ制御端末２００４がＲＳＶＰノード、ルータ２００１と第１のハーフコネクタ２００２と第２のハーフコネクタ２００３とＡＶ制御端末２００４がＦＡＮＰノードとなる。

両ハーフコネクタ２００２、２００３間の伝送方式は、ここでは第１の実施形態と同様にＡＴＭであるとする。

次に、図１９を参照して、ビデオデータ伝送のシーケンスを説明する。

受信端末２００５にて、インターネットから送られてくるビデオを享受したいと考えているユーザは、第２の実施形態と同様にＡＶ制御端末２００４を操作して、番組のリクエストを行う。ここで、実際の操作画面は、映像端末２００５に具備されるディスプレイ装置に表示されるようになっていてもよい。また、この予約の時、高い通信品質にてビデオ番組を享受するため、ＲＳＶＰにて通信資源の予約を行ってもよい。よって、インターネット２０１１側から送られてくるＲＳＶＰのＰＡＴＨメッセージに対し、ＲＳＶＰのＲＥＳＶメッセージにて通信資源の予約を行う（ステップＳ２０１）。なお、ハーフコネクタ２００２、２００３はＲＳＶＰノードではないため、ＲＳＶＰのメッセージは通過する。

ＲＥＳＶメッセージを受け取ったルータ２００１は、第１の実施形態にて説明したＦＡＮＰを用いて、ルータ２００１からＡＶ制御端末２００４に至る経路のコネクションと通信資源とを確保する。このとき、ＦＡＮＰにて転送されるデータがＭＰＥＧデータである旨を各ノードに通知しても良い。

確保された通信資源が、例えば、図２０に示すように、第１の１３９４バス上の同期チャネル２２０２、ハーフコネクタ間のコネクション２２０３、第２の１３９４バス上の同期チャネル２２０４であるとする。ここで、第２の１３９４バス上の同期チャネル２２０４については、１３９４バスの性質上、第２の１３９４バス上をブロードキャストされる。

さて、ルータ２００１から送信されるＦＡＮＰオファーメッセージを受け取ったＡＶ制御端末２００４は（ステップＳ２０２）、ＦＡＮＰリダイレクトメッセージを送り返すことにより（ステップＳ２０３）、コネクションの確立を了承すると共に、以下の２つの動作をこれと前後して行う。

１つ目の動作は、映像端末２００５に対して、１３９４プロトコルにて、同期チャネル２２０４での同期データの受信を指示することである（ステップＳ２０４）。これにより、実質的に、図２０のルータ２００１から映像端末２００５までの通信品質が保証されたコネクションが確立された状態になる。

ＡＶ制御端末２００４の２つ目の動作は、第２のハーフコネクタ２００３に対して、ＭＰＥＧｏｖｅｒＩＰからＭＰＥＧｏｖｅｒ１３９４へのフォーマット変換を指示することである（ステップＳ２０５）。なお、ＭＰＥＧｏｖｅｒ１３９４のフォーマットは、ＩＥＣ１８８３などにより定められたフォーマットであってもよい。この場合、ＡＶ制御端末２００４は、第２のハーフコネクタ２００３があらかじめ該乗せ換え機能を有していることを認識していても良いし、乗せかえ機能の有無を確かめるための何らかのプロトコルが網内を走っていてもよい。

この乗せ換え指示は、ＩＰのアプリケーションとして行われても良いし、１３９４のアプリケーションとして行われても良い。そのために、第２のハーフコネクタ２００３は、図２１に示すように、内部にＭＰＥＧｏｖｅｒＩＰからＭＰＥＧｏｖｅｒ１３９４への乗せ換え機能（変換部２３０４）を有したものとなる。

第２のハーフコネクタ２００３の内部構成において、第１の実施形態のハーフコネクタの内部構成と異なる部分は、第２のハーフコネクタ２００３では、ＭＰＥＧｏｖｅｒ１３９４／ＭＰＥＧｏｖｅｒＩＰ変換部２３０４が構成要素となっている点と、ＩＰ／ＦＡＮＰ処理部２３０３が、図１９のシーケンスのステップＳ２０５における「乗せ換え指示」の信号にしたがって、ＭＰＥＧｏｖｅｒ１３９４／ＭＰＥＧｏｖｅｒＩＰ変換部２３０４の設定を行い、ＭＰＥＧデータが載った適当な入力ＩＰパケットについて、ＭＰＥＧｏｖｅｒＩＰからＭＰＥＧｏｖｅｒ１３９４へのフォーマット変換を行う様に設定する機能を有する点である。

さて、ルータ２００１に達したＲＳＶＰ・ＲＥＳＶメッセージは、更に上流に上り、ビデオサーバ（図示せず）に到達する（ステップＳ２０６）。この時点で、図２０に示すように、ビデオサーバから映像端末２００５までの通信品質の保証されたエンド・エンドのコネクションが確立されたことになる。なお、ビデオデータの送信に先立って、ＡＶ制御端末２００４からビデオサーバに対して、何らかの通知信号（映像データの送信を促す信号）が伝達されても良い。

その後、ビデオサーバからビデオデータの伝送が開始される（ステップＳ２０７）。ビデオデータは、図２０のＩＰ上のコネクションの集合２２０１を通った後、ＦＡＮＰにより確立されたコネクション２２０２、２２０３、２２０４を通って映像端末２００５に到達する。なお、第２のハーフコネクタ２００３において、ＭＰＥＧｏｖｅｒＩＰのフォーマットからＭＰＥＧｏｖｅｒ１３９４フォーマットへのフォーマット変換が行われている。

以上の説明は、映像端末２００５がＭＰＥＧデコーダを有している場合である。これに対し、映像端末２００５がＭＰＥＧデコーダを有しておらず、生の映像データの受信を行って、それを再生するといった構成になっている場合については、第２のハーフコネクタ２００３にＭＰＥＧデコーダを配し、ＭＰＥＧｏｖｅｒＩＰからのＭＰＥＧデコードを行なわせ、生の映像データとした上で、映像端末２００５に送信する構成も可能である。このようにすることにより、映像端末２００５に高価なＭＰＥＧデコーダの実装を行う必要がなくなり、低コストなシステムの構築が可能となるメリットがある。

この場合の第２のハーフコネクタ２００３の内部構成例を図２２に示す。図２２において図２１と異なる部分は、図２１のＭＰＥＧｏｖｅｒ１３９４／ＭＰＥＧｏｖｅｒＩＰ変換部２３０４の代わりに、ＭＰＥＧデコーダ部２４０４が配置されている点である。

ＭＰＥＧデコーダ部２４０４では、ＡＶ制御端末２００４から第２のハーフコネクタ２００３に対して、ＭＰＥＧデータのデコードを指示する指示信号が送られた場合にＭＰＥＧデコードを行うようにしてもよい。

なお、ＭＰＥＧのフォーマット変換、あるいはＭＰＥＧのデコードを行う場合には、２つのハーフコネクタ２００２、２００３間のリンクのデータリンク識別子（例えばＡＴＭならＶＰＩ／ＶＣＩ等）の値から、これのコンテンツがＭＰＥＧデータであると暗示的に認識し、ＩＰレイヤ処理を行うこと無く、フォーマット変換、あるいはデコード処理をおこなってもよい。このようにすることにより、一般にコストがかかるといわれているＩＰ処理を省いてＭＰＥＧフォーマット変換処理、あるいはデコード処理にとりかかることが可能となるため、迅速な処理と低コストかが同時に図ることが可能となる。

なお、言うまでもないが、このような構成のシステムは、インターネットからのビデオのみでなく、第２の実施形態のようにアクセス網がＡＴＭ網である場合のＭＰＥＧｏｖｅｒＡＴＭによる映像データの伝送、その他の方式によるものでも良い。

また、ビデオデータ（あるいは一般のデータ全般）の伝送もＭＰＥＧに限定したものではなく、任意の符号化方式の適用が可能である。

また、以上の操作は、応用として、家庭からの情報の発信にも使うことができる。すなわち、図２３に示すような構成の通信ネットワークシステムにおいて、非ＩＰ端末である送信端末３００１からの生の映像、もしくはＭＰＥＧデータ送信を行うことを考える。

基本的に、先の受信の場合と反対のシーケンスを行えば良い（図２５に示すシーケンス参照）。すなわち、ＡＶ制御端末３００２は、ネットワークレイヤのシグナリングプロトコルにて受信端末までのコネクションを確立し（ステップＳ３０１）、ＦＡＮＰオファーメッセージにて、同期チャネル番号等をルータ３００５に送信し（ステップＳ３０２）、ルータ３００５からのリダイレクトメッセージを受け取る（ステップＳ３０３）。また、ＡＶ制御端末３００２は、送信端末３００１に対して、１３９４プロトコルにて、先に設定された同期チャネルでのデータの送信を指示し（ステップＳ３０４）、さらに、ＡＶ制御端末３００２から例えば、第１のハーフコネクタ３００３に対して、乗せ換え（あるいはＭＰＥＧ符号化）の指示を送る（ステップＳ３０５）。

これにより、例えば、第１のハーフコネクタ３００３に、図２４に示すようなＭＰＥＧエンコーダ３４０４（送信端末３００２にＭＰＥＧエンコーダを具備しない場合）、あるいは、図２１に示すようなＭＰＥＧｏｖｅｒ１３９４からＭＰＥＧｏｖｅｒＩＰへのフォーマット変換機能（変換部２３０４）を配備しているならば、送信端末３００１からのデータ伝送を行うことが可能となる（ステップＳ３０６）。

なお、例えば、図２２に示した構成のハーフコネクタに、図２４に示した構成のハーフコネクタのＭＰＥＧエンコーダ部３４０４（１３９４側からＡＴＭ側に向けて送出するビデオデータをエンコードする）を具備して、ＭＰＥＧエンコーダとＭＰＥＧデコーダを同時に持つようにすれば、単一の装置（ハーフコネクタ）にて双方向の通信が可能となる（片方向の通信を同時に２本以上行い、おのおのでエンコーダ、デコーダをそれぞれ用いる、といった使い方も、もちろん可能である）。

また、ＭＰＥＧエンコード、ＭＰＥＧデコード、ＭＰＥＧフォーマット変換のそれぞれの機能を持ち、ＡＶ制御端末３００２からの適当な制御信号により、モードを切り替えて（これらの機能のうち必要な部分についての機能を実行する）様な構成も考えられる。

また、同時に複数のＭＰＥＧストリームの処理を可能とするような構成も考えられる。この場合、ストリーム毎に別個の処理、例えば、あるＭＰＥＧストリームについてはＭＰＥＧデコード、別のあるＭＰＥＧストリームについてはＭＰＥＧｏｖｅｒＩＰからＭＰＥＧｏｖｅｒ１３９４へのフォーマット変換を行うといった処理形式も可能である。

本発明の第１の実施形態に係る通信ネットワークシステム（ホームネットワーク）の構成例を示した図。 図１のハーフコネクタの内部構成例を示した図。 図２の１３９４・ＡＴＭ乗せ換え部に具備される１３９４側からの入力をＡＴＭ側に出力する場合に用いられる対応テーブルの一例を示した図。 図２の１３９４・ＡＴＭ乗せ換え部に具備されるＡＴＭ側からの入力を１３９４側に出力する場合に用いられる対応テーブルの一例を示した図。 図１の通信ネットワーク上で送信端末から受信端末へ映像データを送信する場合の処理手順を説明するためのシーケンスの一例を示した図。 ＡＶ制御端末に具備される情報機器の属性情報を記憶するテーブルの一例を示した図。 ＡＶ制御端末に具備されたディスプレイ装置の画面表示例を示した図。 図５のシーケンスに基づき図１の通信ネットワーク上に設定される通信経路を示した図。 本発明の第２の実施形態に係る通信ネットワークの構成例を示した図。 図９のＡＶ制御端末の内部構成例を示した図。 図９の通信ネットワーク上でビデオサーバから受信端末へ映像データを送信する場合の処理手順を説明するためのシーケンスの一例を示した図。 図５のシーケンスに基づき図１の通信ネットワーク上に設定され通信経路を示した図。 本発明の第２の実施形態二係る通信ネットワークシステムの構成例を示した図で、例えば、家庭内に構築されるネットワークへのアクセス網として図９のインターネットの代わりにＡＴＭアクセス網を用いた場合を示している。 図１４のＡＶ制御端末の構成例を示した図。 図１３の通信ネットワーク上でビデオサーバから受信端末へ映像データを送信する場合の処理手順を説明するためのシーケンスの一例を示した図。 ＡＶ制御端末の他の構成例を示した図で、ＡＶ制御端末にＭＰＥＧデコーダを具備する場合を示したものである。 図１６のＡＶ制御端末を用いた図９の通信ネットワーク上でビデオサーバから受信端末へ映像データを送信する場合の処理手順を説明するためのシーケンスの一例を示した図。 本発明の第３の実施形態に係る通信ネットワークの構成例を示した図で、例えば、家庭内に構築されたネットワーク上の映像端末が外部網から映像データを受信する場合を示したものである。 図１８の通信ネットワーク上で送信端末（インターネット上）から受信端末（家庭内に構築されたネットワーク上）へ映像データを送信する場合の処理手順を説明するためのシーケンスの一例を示した図。 図１９のシーケンスに基づき図１８の通信ネットワーク上に設定され通信経路を示した図。 図１８のハーフコネクタの内部構成例を示した図。 図１８のハーフコネクタの他の内部構成例を示した図。 本発明の第３の実施形態に係る通信ネットワークの他の構成例を示した図で、例えば、家庭内に構築されたネットワーク上の映像端末が外部網へ映像データを送信する場合を示したものである。 図２３のハーフコネクタの内部構成例を示した図。 図２３の通信ネットワーク上で送信端末（家庭内に構築されたネットワーク上）から受信端末（インターネット上）へ映像データを送信する場合の処理手順を説明するためのシーケンスの一例を示した図。

符号の説明

１…送信端末、２…第２のＡＶ制御端末、３…第１のハーフコネクタ、４…第２のハーフコネクタ、５…第２のＡＶ制御端末、６…受信端末、１１…第１の１３９４バス、１２…第２の１３９４バス、１１０１…ビデオサーバ、１１０２…インターネット、１１０３…ＡＶ制御端末、１１０４…１３９４バス、１１０５…受信端末、１５０１…ビデオサーバ、１５０２…ＡＴＭアクセス網、１５０３…ＡＶ制御端末、１５０４…１３９４バス、１５０５…受信端末、２００１…ルータ、２００２…第１のハーフコネクタ、２００３…第２のハーフコネクタ、２００４…ＡＶ制御端末、２００５…映像端末、２０１１…インターネット、２０１２…第１の１３９４バス、２０１３…第２の１３９４バス、３００１…送信端末、３００２…ＡＶ制御端末、３００３…第１のハーフコネクタ、３００４…第２のハーフコネクタ、３００５…ルータ、３０１１…第１の１３９４バス、３０１２…第２の１３９４バス、３０１３…インターネット。

Claims (5)

1. 第１のネットワークまたはケーブルに接続された端末と、第２のネットワークまたはケーブルに接続された端末との間でＡＶデータを送受信するための中継装置であって、
   当該中継装置は、前記第１のネットワークまたはケーブルと前記第２のネットワークまたはケーブルとに接続されており、
   前記第１のネットワークまたはケーブル上の各端末に対し、当該端末の種別、当該端末がコンテンツを有する場合には該コンテンツに関する情報、及び当該端末のアドレスを含む属性情報を問い合わせて、各端末の前記属性情報を収集する収集手段と、
   前記収集手段で収集された前記第１のネットワークまたはケーブル上の各端末の属性情報のうち少なくとも一部を表示する表示手段と、
   前記表示手段で表示された属性情報を基に選択された、前記第１のネットワークまたはケーブルに接続された第１の端末の有するコンテンツのＡＶデータの送信指示を受け付ける手段と、
   前記第１のネットワークまたはケーブル上に、送信端末としての前記第１の端末から当該中継装置を通して前記第２のネットワークまたはケーブル上の第２の端末へ送信される、前記送信指示を受け付ける手段で受け付けた、前記選択されたコンテンツのＡＶデータを伝送するためのコネクションを設定する第１の設定手段と、
   前記第1の端末に対してＡＶデータの送信を要求する手段と、
   前記第２のネットワークまたはケーブル上に、前記第1の端末から当該中継装置を通して前記第２の端末へ送信される前記選択されたコンテンツのＡＶデータを伝送するためのチャネルを設定する第２の設定手段と、
   前記コネクションを用いて前記第1の端末から送信されてきた前記ＡＶデータを受信する受信手段と、
   前記ＡＶデータを前記チャネルを用いて前記第２の端末へ送信する送信手段と、
   を具備したことを特徴とする中継装置。
2. 前記第２の端末は、符号化されたＡＶデータを復号するための機能を持たない端末であり、
   前記受信手段で受信された符号化されたＡＶデータを復号する復号手段をさらに具備し、
   前記送信手段は、前記復号手段で復号されたＡＶデータを、前記チャネルを用いて前記第２の端末へ送信することを特徴とする請求項１記載の中継装置。
3. 前記第２の設定手段で設定された前記チャネルを用いて送信される前記ＡＶデータを受信するよう前記第２の端末に対し指示する指示手段をさらに具備したことを特徴とする請求項１記載の中継装置。
4. 前記中継装置は、
   前記収集手段で収集された第１のネットワークまたはケーブル上の各端末の種別、アドレス、及び当該端末が有するコンテンツに関する情報のうちの少なくとも１つを、前記第２のネットワークまたはケーブルに接続された他の中継装置へ送信する手段と、
   をさらに具備したことを特徴とする請求項１記載の中継装置。
5. 前記中継装置は、
   前記第２のネットワークまたはケーブルに接続された前記他の中継装置から、当該他の中継装置に接続された第３のネットワークまたはケーブル上の各端末の種別、アドレス、及び当該端末が有するコンテンツに関する情報のうちの少なくとも１つを収集する第２の収集手段をさらに具備したことを特徴とする請求項４記載の中継装置。

Images