以下、本発明の実施の形態について、図面を参照して説明する。
(第1の実施形態)
図1に、第1の実施形態に係る通信ネットワークシステムの構成例を示したもので、例えば、家庭宅内のホームネットワークの構成例を示したものである。
図1に示すように、ホームネットワークは、送信端末1、第1のAV制御端末2、第1のハーフコネクタ3、第2のハーフコネクタ4、第2のAV制御端末5、受信端末6、第1の1394バス11、第2の1394バス12からなる。また、本実施形態では両ハーフコネクタ3、4間の伝送方式はATMであるとする。
送信端末1及び受信端末6は、非IP端末である(AV/Cプロトコルや、IEC1883などに代表される、1394プロトコルしか理解できない端末である。以降1394プロトコルと呼ぶ)。即ち、インターネットプロトコルを解さない端末である。
本実施形態では、このようにIPプロトコルを理解出来ない端末同士(あるいは、どちらか一方がそのような場合)で、1394プロトコルによる通信が直接お互いにはできないような場合(すなわち、1394バス同士がブリッジ接続されていない場合、言い換えれば、両者の間に1394バス以外のネットワークが存在している場合や、インターネットやISDN等の公衆網が存在している場合)において、AV制御端末による制御により、両者が通信し合う方法について説明を行う。
両1394バスは、直接ブリッジ接続されているわけではなく、間にATMネットワークが存在するため、一方の1394バスにつながれた1394専用ノード(1394プロトコルしか理解できない端末)からは、他方の1394バスに接続された1394専用ノードは、1394プロトコル上からは見えないものとする。
これに対し、相互接続網プロトコルであるIP端末(以下、IPノードと呼ぶことがある)は、両1394バスに接続されたものであったとしても、他方のバスに接続されたIP端末を認識できる。
送信端末1、受信端末6は、共に、いわゆる1394端末、即ちインターネットプロトコルは理解できず、IEEE1394において定められている1394専用のプロトコル、例えばAV/CプロトコルやIEC1338の様なプロトコルのみを理解出来る端末である。また、1394の専用端末であっても良い。
両者を例えば映像端末(例えば送信端末1がDVDプレーヤ、受信端末6がテレビ、といった場合)とし、かつ、両者が相異なる1394バス上にある時に、いかにして両者の通信を実現するかが問題となる。
図2に、ハーフコネクタ2、3の内部構成例を示す。図2に示すように、ハーフコネクタ2、3は、1394物理部101、1394リンク部102、第1のMUX−DEMUX103、IP/FANP処理部104、1394・ATM乗換部105、第2のMUX−DEMUX106、ATMインタフェース部107からなる。
1394物理部101、1394リンク部102は、それぞれ接続された1394バスについて、その物理レイヤ処理、リンクレイヤ処理及びバス管理及びとトランザクションレイヤ処理をそれぞれ行い、送受信する1394フレームを、第1のMUX−DEMUX103または第2のMUX−DEMUX106を通して、IP/FANP処理部104または1394・ATM乗せ換え部105とデータ(1394から見ると、PDU(Protocol Data Unit))のやりとりを行う。
IP/FANP処理部104は、受信したIPパケット、FANPパケット(後述)、ARPパケット等について、IPアドレスに基づくルーチング、ルーチングテーブルの管理、FANP処理、ARP処理等を行う機能を持つ(なお、FANPについては、特願平第8−264496号の記載参照のこと)。
1394・ATM乗せ換え部105は、1394側から受信したデータ、特に同期チャネルを通して受信したデータを、その同期チャネル番号をキーとして、特定のATMのヘッダ(VPI/VCI値)を付与した後に、これをATM側に送出する機能と、逆にATM側から受信したデータを、そのヘッダ情報(VPI/VCI情報)をキーとして、1394側の特定の同期チャネルに送出する機能を有する。すなわち、この処理部におけるデータのフォワーディングはデータリンクレイヤ処理のみで行われる。
例えば、図3(1394側からの入力をATM側に出力する場合)、図4(ATM側からの入力を1394側に出力する場合)に示すような対応テーブルを用い、VPI/VCIの値と1394バスの同期チャネルのチャネル番号との対応テーブルを作成する。この各々のマッピング(対応テーブルの作成)については、IP/FANP処理部104が行う。
データフォワーディング機能については、後に説明するFANPによる通信品質保証機能が備わっており、たとえばWFQやWRR等のデータスケジューリング方式が実装されていてもよい。
ATMインタフェース部107は、物理的に接続されたATM網(本実施形態の場合はATMケーブル)とのインタフェースを司る部分であり、第2のMUX−DEMUX106とやりとりするデータと、ATMセルとのセル化、デセル化等を行う。ABR(Available Bit Rate)処理やUPC(Usage Parameter Control)処理、あるいはSDH(Synchronous Digital Hierarchy)処理などを行っても良い。
なお、特願平第8−264496号にて説明されているように、両1394コネクタ間には、ATMのデフォルトVCとして、あるVCが定義されており、FANPのメッセージはこのデフォルトVCを通ってやり取りされることを、双方のハーフコネクタ3、4が認識している。
第1のAV制御端末2および第2のAV制御端末5は、共にIPノードであり、かつFANPノードであり、当然インターネットプロトコルにて通信する事の出来る端末である。これらAV制御端末2、5は、後述するように、1394プロトコルとIPを理解することができ、1394プロトコルを使ってローカルな1394バス上の端末と通信をおこない、IPをつかって、ローカル及びリモートのIP端末と通信を行う事ができる。
図1中のIPノードは、それぞれ同一のIPサブネットに属するものとして、以降の説明を行う。
AV制御端末2、5には、「映像送受信制御アプリケーション」が実装されている。このアプリケーションは、
(1)お互いに自分のローカルバス上の資源(ノードなど)を調査し、この結果をお互いにIPを用いて通信し合う機能。
(2)(1)の情報を元に、リモートのバス上の端末の資源をユーザに表示し、それらの操作を行わさせる機能と、これらの制御情報をお互いに交換する機能。(3)お互いにFANPパケットのやり取りを行い、該AV制御端末が位置する1394バス間の伝送パス(必要な場合は帯域等が確保されたコネクション)を確保する機能。
(4)ローカルバス上のノードの制御を1394のプロトコル(AV/Cプロトコルなど)を使って行う機能。
等がある。このAV制御端末を使うことにより、ユーザは、リモートの1394バス上に位置する端末とのデータのやり取りを、たとえ送受信用の端末がIP端末ではなかったとしても行うことができるようになる。
このように、ローカル、リモートに関わらず、1394上のAV機器の制御を行うプロトコルを、ここではFANP−AVプロトコルと呼ぶ。このプロトコルは、IPアプリケーションであってもよい。
例えば、第1の1394バス11が家庭宅内の部屋Aに配置されており、第2の1394バス12が家庭宅内の部屋Bに配置されている場合を考える。ここで、部屋Bにいるユーザが、部屋Aにある送信端末1からの映像データを、部屋Bの受信端末6に映し出すことを行うとする。
なお、これら2つの部屋が同じ家庭宅内に属している必要は必ずしもない。その場合は、2つのハーフコネクタ3、4の間に公衆網が入ることになってもよい(この場合は、お互いに同一のIPサブネットに属するとは限らないので、後述するブロードキャストは行わず、手設定にてお互いのアドレスと存在を認識してもよい)。
以下、図5に示すシーケンスを参照して、非IP端末である送信端末1と受信端末6との間で映像データのやりとりを行うまでの手順(FANP−AVプロトコルを含む)について説明する。
まず、本発明の通信システムにおいては、該ユーザは、第2のAV制御端末5を起動し、AV制御端末5上で必要な設定を行う。すなわち、図5に示すように、第2のAV制御端末5は、ホームネットワーク上に、FANP−AVプロトコルを処理するノードの有無を確認するため、ホームネットワーク全体、即ちIPブロードキャストアドレスに「FANP−AV要求」パケットを送出する(ステップS1)。
このパケットには、FANP−AV処理機能にあらかじめ割り当てられたウエルノウンのポート番号が振られている。このIPブロードキャストパケットは、第2の1394バス12上で、1394アドレスの「バスブロードキャストアドレス」、すなわち、その家庭のホームネットワークにおけるすべてのノードに対するブロードキャストの形で非同期チャネルに送出される。このブロードキャストパケットは、第2の1394バス12上の全てのノードに到達する。ちなみに、このパケットを、1394アドレスの「ローカルバスブロードキャスト」に送出される形でも、そのIPサブネット内の全てのノードに届くようになっていれば良い。すなわち、1394バス以外のネットワークが接続されている場合でも、これが配送されるようになっていればよい。
さて、これを受信した第2のハーフコネクタ4は、これが「全てのバスに対するブロードキャスト」であることを宛先1394アドレスにより確認すると、これを第1のハーフコネクタ3の側にフォワードする。これを受信した第1のハーフコネクタ3は、今度はこれを第1の1394バス11にフォワードする(ステップS2)。その際の、宛先1394アドレスは「バスブロードキャストアドレス」である。
ここで、自らがFANP−AVプロトコルを稼動させているノードは、このパケット(FANP−AV要求パケット)を受信し、ポート番号を参照することによって、これが「FANP−AV要求」、即ちFANP−AVプロトコルを稼動しているノードを探すためのパケットであることを確認すると、このパケットに対する返答として、「自分もFANP−AVプロトコルを稼動させている」という旨の「FANP−AV応答」パケットを送信IPアドレスに対して送出する(ステップS3)。図5では、第1のAV制御端末2が、FANP−AVプロトコルノードであるため、この端末がFANP−AV応答パケットを「FANP−AV要求」パケットの送信元である第2のAV制御端末5に送出する。それとともに、第1のAV制御端末2は、第2のAV制御端末5が存在することと、そのIPアドレスを記憶しておく。
なお、前述のように、このような自動的な構成認識を行うのではなく、各々のAV制御端末にあらかじめ手設定でお互いのアドレスなどを登録しておく、等の方法を使う事により、お互いを認識させておいても良い。
これと前後して、各FANP−AVノード(AV制御端末2、5)は、自分の接続された1394バス上に有るAV機器についての情報を、1394プロトコルを用いて収集する(ステップS4、ステップS5)。これには、1394トレードアソシエーションやHD−DVTR協議会等で標準化しているAV/Cプロトコル等、あるいはこれらを拡張したものを用いて、これを行っても良い。
こうして各AV制御端末2、5は、自分が所属する1394バス上のAV機器についての情報、すなわち、どのようなAV機器か、どのようなコンテンツが有るか、何枚のメディアを持っているか、その1394アドレスは何か、といった各種の情報を収集し、内部のテーブルに記憶する。
次に、各AV制御端末2、5は、お互いのこれらの情報を交換する(ステップS6)。この情報の交換には、IPパケットを用い、お互いのIPアドレス宛にこれらの情報を送信しあう。その結果、各AV制御端末2、5には、例えば、図6に示すような内容のテーブルが作成されることになる。すなわち、各AV制御端末2、5は、自分が所属する1394バス上のAV機器についての情報以外に、各AV制御端末2、5との間で情報交換を行うことにより、他のAV制御端末が所属するネットワークに接続されたAV機器等の情報(属性情報)、すなわち、どのようなAV機器か、どのようなコンテンツが有るか、何枚のメディアを持っているか、その1394アドレスは何か、といった各種の情報が、図6のテーブル上に収集できる。
また、AV制御端末2、5の画面等に図6のテーブル上の情報を表示させることも可能である。図7に第2のAV制御端末5に具備されたディスプレイ装置の画面表示例を示す。図7では、見やすさのため、1部屋1バス(あるいは1部屋1データリンクネットワーク)と考えて、表示画面中の各表示ウインドウ(W1〜W4)に、それぞれ各部屋のネットワークを対応させ、部屋毎の配置の形で画面表示を行っている。ユーザは、これをみて、「どの端末から、データを送ってもらうか。あるいは、送るか」といった判断を行うことができる。
例えば、部屋Bのユーザは、送信端末1から、映像データを送ってもらい、受信端末6に表示させたいと思っているとする。そこで、該ユーザは、第2のAV制御端末5を操作し、送信端末1のしかるべきコンテンツである映像を、受信端末6に送信し、そこで表示させるように設定をおこなう。この操作は、第2のAV制御端末5上のGUIを通して行われても良い。すると、第2のAV制御端末5は、「送信端末1のしかるべきコンテンツである映像を、受信端末6に送信せよ」という内容の命令を、第1のAV制御端末2に対して送信する(ステップS7)。これにより、第1のAV制御端末2は、送信先の送信端末1のアドレスを、1394アドレスとして知ることができる。
この命令を受信した第1のAV制御端末2は、送信端末1と1394プロトコルにて通信し、映像送信が可能であるかどうかのチェックなどを行う。また、第2のAV制御端末2との間で認証などの動作を行っても良い。
次に、第1のAV制御端末2は、第1の1394バス11にて、1394のプロトコルおよび1394AVプロトコル等を使って、第1の1394バス11の同期チャネルを確保する(ステップS8)。このとき確保したチャネル番号を#Xとする(図8の同期チャンネル31)。また、このとき、1394バス11の同期リソースマネージャに働きかけ、映像送信に必要な帯域を確保することは言うまでもない。
次に、第1のAV制御端末2は、第1のハーフコネクタ3に対して、同期チャネルの#Xを受信するように設定する。そして、この同期チャネルを通して、FANPのオファーメッセージを第1のハーフコネクタ3に向かって送出する(ステップS9)。
ここで、FANP(Flow Attribution Notification Protocol)とは、前述の通り、特願平第8−264496号に記載されているプロトコルである。すなわち、このプロトコルは、隣接のFANPを解釈するノード(通常は、ホームネットワークを構成するネットワークのセグメントとセグメントの中間におかれ、これら複数のセグメントの相互接続装置の位置づけとなる)との通信を行い、送信するデータを通すチャネルの識別子と、宛先アドレスおよび、その通信属性や通信品質を通知するために用いる。また、これを、エンド−エンドのコネクションの設定のために用いることもできる。
さて、このオファーメッセージには、データ(本実施形態の場合、映像データ)をこれから送信するチャネル番号(または、仮想チャネル識別子等)、該映像データの宛先アドレス(本実施形態の場合IPアドレス)、使用する帯域(通信品質)、通信属性(MPEG等の符号化方式など)、エンド−エンドのACKの要求等が運ばれる。なお、該送信するチャネル番号、または仮想チャネル識別子等を両端の端末で共有していない場合は、両端でFANPのプロポーズメッセージとプロポーズACKメッセージのやり取りを行ってもよい。また、該データの宛先アドレス(ターゲットIPアドレス)は、第2のAV制御端末5のIPアドレスである。
オファーメッセージを受け取った第1のハーフコネクタ3は、内部のルーチングテーブルを参照して、第2のAV制御端末5が第2のハーフコネクタ4の方向にあることを確認すると、そのオファーメッセージにて要求されている帯域、通信品質などが、ハーフコネクタ4内部の通信路の空き帯域等を参照することによりサポートできるかを確かめる。サポート可能と判断した場合は、プロポーズメッセージ、プロポーズACKメッセージ、オファーメッセージ等を前述の処理と同様に第2のハーフコネクタ4に送出する。なお、サポートできないと判断した場合は、リジェクトメッセージを第1のAV制御端末2に送出する。
第2のハーフコネクタ4は、内部の通信資源の確認後(第1のハーフコネクタ3と同様に、オファーメッセージに記載された通信品質が内部的に可能であるかどうかを確認)、第2の1394バス12上に同期チャネル#Y(図8の同期チャネル33)を確立し(ステップS10)、これと前後して、1394プロトコルを用いて、第2のAV制御端末5に、この同期チャネルの内容を取り込むように指示する。その後、第2のAV制御端末5との間で、プロポーズメッセージ、プロポーズACKメッセージ、オファーメッセージのやり取りなどを行う(ステップS11)。
プロポーズメッセージ、オファーメッセージを受け取った第2のAV制御端末5は、これが自分が先に第1のAV制御端末2に嘆願した映像伝送のためのものであることを、フローIDや、あらかじめ両者の間で合意した、定められた識別子等により認識する。この定められた識別子は、FANPメッセージにより運ばれてきたものであってもよい。
次に、第2のAV制御端末5は、IEC1338等の1394プロトコルを用いて、受信端末6に対し、同期チャネル#Yを介して送信されるデータを受信する様、指示する(ステップS12)。これにより、同期チャネル#Yを介して送出されたデータは受信端末6により受信できることになる。
その後、第2のAV制御端末5は、リダイレクトメッセージを第2のハーフコネクタ4に送出する(ステップS13)。このリダイレクトメッセージは、ステップS11のオファーメッセージで申しだされた設定を受諾した、との意味を持つメッセージである。オファーメッセージにエンド−エンドACKの要求があった場合、エンド−エンドのACKのフラグを「オン」にして(エンド−エンドのACKを「オン」にするとは、送信端末1から受信端末6までの映像データを送信するための経路が設定できた旨を示すものである)、リダイレクトメッセージを送出する。このACKのフラグは、送信端末(本実施形態の場合、第1のAV制御端末2)まで到達する。
リダイレクトメッセージを受信した第2のハーフコネクタ4は、内部のデータリンクレイヤの乗せ換え部105の適切な設定(具体的には、図3、図4に示したような対応テーブルの設定)を行う。すなわち、ステップS9でのオファーメッセージで申し出のあったATM仮想コネクション32(図8参照)と、同期チャネル#Yとをデータリンク的にスイッチ接続する。具体的には、ATM/1394乗せ換え部105では、ATM仮想コネクション32から入力されたATMセルを、IP/FANP処理部104における処理を受けることなく、直接VCIの値が参照されて、1394データへの乗せ換えが行われ、同期チャネル#Yに入れる。その際は、FANPにて定められた通信品質が保たれるようなデータ/パケットスケジューリング方式が選択されてもよい。なお、このとき参照されるATM/1394乗せ換え部105内の対応テーブルは図3、図4に示したものである。
リダイレクトメッセージは、第2のハーフコネクタ4から、第1のハーフコネクタ3(第2のハーフコネクタ4と、同様の操作、すなわち、ATM/1394乗せ換え部105の設定を受ける)、第1のAV制御端末2へと返る(ステップS14)。
ここで、第1のAV制御端末2は、最終端末(本実施形態の場合、受信端末6である。ただし、受信端末6は、FANPやIPが理解できるノードではなく1394の専用端末である。受信端末6が映像データを受信できるように準備を行ったのは、第2のAV制御端末5であり、これが1394プロトコルにより、設定を行った。)まで、データリンクレイヤコネクションが図8に示したように整ったことを確認する。
そして、第1のAV制御端末2は、送信端末1に対し、1394プロトコルにて、該当する適当な映像の送信を、チャネル番号#Xの同期チャネル(図8の同期チャネル31)に対して行うように指示する(ステップS15)。
送信された映像は、第1の1394バス11上の同期チャネル31、ATM仮想コネクション32、第2の1394バス12上の同期チャネル33を通過して、受信端末6に到達する(ステップS16)。その間、途中ノード(ハーフコネクタ3、4)では、データリンクレイヤによるスイッチングを受けているのみである。よって、この経路を通る間、通信品質は保証されたまま、データ転送が行われる。
この映像送信を持続するためのリダイレクトメッセージの送信は、第2のAV制御端末5から上流側(すなわち、第2のハーフコネクタ4から第1のハーフコネクタ3を通り、第1のAV制御端末2)に向かって行われる(ステップS17)。
また、ユーザ側からの送信の中断の要請(リリースメッセージの送信)も、第2のAV制御端末5から同様の順序で送られる。その際は、第1のAV制御端末2が、送信端末1に向かって、映像の送信を終了するようにAV/Cプロトコル等の1394プロトコルにて制御を行う。
以上説明したように、本実施形態の通信ネットワークシステムによれば、送信端末1から、受信端末6までの映像の配信、中断等の、複数の1394バスをまたがるAV機器の制御を、送信端末1と受信端末6がIP端末ではないにもかかわらず(すなわち、AV制御端末2、5を介して)、FANPとFANP−AVプロトコルにて行われている。
一般にIPを実装するにはコストがかかるといわれているが、本発明の方式を用いることにより、IPを実装していないAV機器間の制御、複数の1394バスをまたがるコネクションの制御等を、IPとFANPを実装したAV制御端末2、5により行うことができ、全体システムとしての簡単化、低コスト化、制御の集中化等を行うことができる。また、ハーフコネクタ間に複数のFANPノードが存在しても、全く同じ原理でこれを実現できること明白である。よって、1394バスの欠点である複雑な1394ブリッジプロトコルや、長距離の1394バス転送を行うことなしに、任意の1394上のAV端末間の制御を行うことができる。
なお、本実施形態において、AV制御端末2、5同士はIPを用いて通信を行うことを前提としてきたが、IPの代わりに他のネットワークレイヤ技術(例えばNetwareやCLNP(Connectionless Network Protocl)等)やI−PNNI(Integrated P−NNI)等の技術を用いてこれを実現する事も可能である。
また、本実施形態において、FANPと呼ぶプロトコルを用いて両AV制御端末2、5間のコネクション(チャネル)の設定を行ってきたが、FANPの代わりにRSVP(Resource Reservation Protocol)やST2(Stream Transport Protocol−2)、あるいはI−PNNI等のコネクション設定プロトコルを用いても、実現は容易である。
また、本実施形態において、送信端末1、受信端末6が接続されたネットワークが、IEEE1394バスであることを前提としてきたが、FDDI2や、特願平第8−108015号記載の「ATM通信システム」にあるような家庭内ATM−LANのようなブロードキャストベースのネットワークについては、本実施形態における説明と同様の操作により、これを実現することが可能である。また、ブロードキャストベースのネットワークでない場合も、サードパーティセットアップのように、AV制御端末が、ハーフコネクタと送信/受信端末との間のコネクション設定を行ってやることにより、これを実現することも可能である。
また、本実施形態において、AV制御端末2、5とハーフコネクタ3、4は別の筐体にあるものとして説明を行ってきたが、同一の筐体内にこれが存在してもよい。すなわち、AV制御端末2とハーフコネクタ3が同一の筐体内にあり、AV制御端末5とハーフコネクタ4が同一の筐体内にある場合、ハーフコネクタ3、4自身が、AV制御端末2、5の機能をそのまま持つものと考えればよい。
また、本実施形態において、AV制御端末2、5同士がお互いに、ローカルのバス上のAV機器に関する情報について、情報を交換し合う方法について述べたが、AV制御端末の数が増えてきた場合は、お互いにメッシュ接続の形にして、これらの情報の交換を行ってもよいし、サーバとなるAV制御端末がほかのAV制御端末に対してこの情報を分配するようなやり方、あるいは、その中間(あるAV制御端末が、複数のAV制御端末に関する情報をアグリゲートして、他のAV制御端末に通知する)の方法を用いてもよい。
また、本実施形態において、ユーザがAV制御端末の操作を行っている時、その制御過程は、受信端末6に具備されるディスプレイ装置に表示するようになっていてもよい。
(第2の実施形態)
次に、エンド−エンドのデータの伝送がRSVPやST2等のネットワークレイヤのシグナリングプロトコルにより制御されており、該ネットワークレイヤのネットワークとのデータのやり取りを行う場合について説明する。
図9は、第2の実施形態に係る通信ネットワークシステムの構成例を示したものである。図9において、AV制御端末1103がインターネット1102(あるいは任意のネットワーク)に接続されており、1394バス1104を経て、受信端末1105に接続されている。そして、インターネット1102に接続されたビデオサーバ1101からビデオデータの配信が、例えば受信端末1105対し行われるものとする。
ビデオサーバ1101は、インターネット端末であり、ビデオデータをIPパケットに乗せて、すなわち、MPEGoverIPの形で送出する。例えば、MPEGのTS(タイムスタンプ)をRTPによる伝送を行う、等の形態でもよい。
AV制御端末1103は、インターネット1102と1394バス1104の間に接続されて、インターネット1102側への制御、1394バス1104側への制御、および、両者からの通信の整合を取り、一方のネットワークから他方のネットワークへデータを送出する機能を有する。
AV制御端末1103は、いわゆるセットトップボックスと呼ばれるユニットであってもよい。
受信端末1105はビデオデータの受信を行う、1394プロトコルのみを理解できる非IP端末である。よって、MPEGデータの受信はたとえばIEC1883に定められた、MPEGover1394のデータフォーマットに従う必要がある。
前述したように、本実施形態では、ビデオサーバ1101からのビデオデータの転送は、インターネット1102を通して、MPEGoverIPの形で送信されて来るものとする。このビデオデータの伝送を、インターネット1102内にて通信品質を保ちつつ、これを行うために、インターネット1102内ではRSVPにて通信品質の保証を行う(無論、ST2やFANPによる保証を行ってもよい。本実施形態では、RSVPの場合についての説明を行う)。
以下、図9に示した通信ネットワークシステムにおいて、ビデオサーバ1101からのビデオデータを、どのようにIP端末ではない受信端末1105まで送信するかについて説明を行う。
図10にAV制御端末1103の内部構成例を示す。図10に示すように、AV制御端末1103は、外部網インタフェース1201、第1のMUX−DEMUX1202、RSVP処理部1203、1394AV処理部1204、MPEGoverIP/MPEGover1394変換部1205、第2のMUX−DEMUX1206、1394インタフェース1207からなる。
外部網インタフェース1201は、インターネット1102とのインタフェース、特にデータリンクレイヤと物理レイヤのインタフェースを司るものである。受信したデータは必要に応じて、第1のMUX−DEMUX1202を介して、RSVP処理部1203あるいはMPEGoverIP/MPEGover1394変換部1205に送出される。
RSVP処理部1203は、インターネット1102を通して、RSVPの処理を行い、AV制御端末1103とインターネット1102に接続された任意端末(本実施形態の場合ビデオサーバ1101)との間に通信品質を保証した経路を確保する機能と、IP処理の機能を有する。
1394AV処理部204は、1394バス1104を通して、第1の実施形態において説明した1394AVプロトコル(AV/Cプロトコル、IEC1883等)、あるいは、FANP−AVプロトコルの処理を行う機能を有する。
MPEGoverIP/MPEGover1394変換部1205は、インターネット1102からMPEGoverIPのフォーマットで入力されたMPEGフレームをMPEGover1394のフォーマットに乗せ換え、これを送出する機能を有する。無論、逆方向の変換機能を有していても良い。このフォーマットの乗せ換えは、到着したIPパケットのソースアドレス、宛先アドレス、ポート番号、フローラベル等を参照して行っても良いし、インターネットが仮想コネクション型ネットワークである場合は、仮想チャネル識別子、あるいはチャネル番号等を参照してこれを行っても良い。本実施形態では、後者の処理が取られるものを例にとり説明する。
1394インタフェース1207は、1394バス1104とのインタフェース、具体的には物理レイヤ、リンクレイヤ、トランザクションレイヤ、バス管理等の処理を行う機能を有する。
図10に示した構成のAV制御端末は、受信端末1105が、MPEGの再生機能(MPEGのデコード機能)を有している場合のものである。このほか、AV制御端末1103は、一般にセットトップボックスとよばれる機能(アナログ回路などを含む)を有していても良い。
ユーザは、受信端末1105にて、ビデオサーバ1101からの映像データの受信を望む場合には、AV制御端末1103に働きかける。すなわち、AV制御端末1103に対して、どのビデオサーバから、どの映像を送ってもらい、どの受信端末にてそれを受信(鑑賞)したいかについて設定を行う。
このとき、ユーザはAV制御端末1103に直接働きかけるのではなく、他の端末に働きかけを行い、該他の端末から該AV制御端末に対して、以降の一連の制御を要請するような制御メッセージが送られるような構成になっていても良い。
AV制御端末1103は、IPノードであるビデオサーバ1101に対して、映像データの送信をIPプロトコルにて要求する。HTTP等のプロトコルを通して、これを行ってもよい。また、ITU−TやDAVIC等により定められているDSM−CC等の制御プロトコルが、インターネット上を流れていく形になっていてもよい。
この時、RSVPのPATHメッセージがビデオサーバから流れてきており、これに対してAV制御端末1103からRSVPのRESVメッセージを送ることにより、ビデオーサーバ1101とAV制御端末1103間にQOSを確保した経路を確立しても良い(図11のステップS101)。
さらに、AV制御端末1103は、受信端末1105に対して、1394バス1104上の同期チャネル(チャネル番号#x)を確立し、IEC1883やAV/Cプロトコル、あるいは1394−1995といった1394プロトコルにより、該同期チャネルからのデータの受信を指示するメッセージを送出する(図11のステップS102、ステップS103)。
これと共に、MPEGoverIP/MPEGover1394変換部1205の設定、具体的にはインターネット1102から入力されるMPEGoverIPのパケットのヘッダ情報(該パケットを通すデータリンクレイヤコネクションの識別子、あるいはIPヘッダ情報、あるいはフローラベルなど)から、該パケットを取り出し、これをMPEGover1394のデータフォーマットに変換して、定められた1394バス1104上の同期チャネル#X(図12の同期チャネル1111)に送出するような設定がなされる(ステップS104)。この処理は、ジッタや遅延時間といった通信品質を保証する形で設定されるようにしてもよい。
これにより、ビデオサーバ1101から受信端末1105にいたる経路1110、1111(通信品質の確保された経路)が図12に示すように確保されたことになる。
ここで、インターネット1102を通ってきたパケットのうち該MPEGパケットについては、該変換部1205にフォワーディングし、そこでのフォーマット変換をかけるトリガとなる情報は、例えば、インターネット1102のアクセスデータリンクが例えばATMなら、該MPEGデータを運ぶVPI/VCIの値から、これを行っても良い。この場合、IP層まで、その処理を持ち上げる必要はない。
また、アクセスデータリンクがSTM網なら、そのチャネル番号/特定のタイムスロットからの入力等を用いてこれを行っても良い。この場合も、IP層まで、その処理を持ち上げる必要はない。
また、該インターネットパケットのヘッダ情報の一部(例えば、宛先アドレス+ポート番号、IPv6のフローラベル等)を用いてこれを行ってもよい。
ビデオサーバ1101からは、MPEGoverIPのフォーマットで、MPEGデータが送られて来るので、これをAV制御端末1103は、変換部1205において、MPEGover1394フォーマットに乗せ換えた上で受信端末1105に送出する(ステップS105)。
このようにして、IP端末ではない受信端末(本実施形態では受信端末1105)においても、IPで送信されてきたビデオデータの受信を行うことができる。
なお、1394バス1104の部分は、ブリッジ接続された1394バス群であっても良い。また、1394バスがエミュレートされている、他のネットワークとの混在網で構成されたネットワークであっても良い。
インターネット1102の代わりに、家庭へのアクセス網としてATMアクセス網が適用されている場合も考えられる。その場合の通信ネットワークシステムの構成例を図13に示す。図9と異なる部分は、図9のインターネット1102がATMアクセス網1502に置き換わっていることである。
なお、この場合は、図13において、AV制御端末1503やビデオサーバ1501はATM端末(ATM−APIのみが理解・処理できる端末)になっていてもよく、よってAV制御端末1503とビデオサーバ1501間のやり取りは、ATMシグナリングによる呼設定等が絡んでくることになる。
AV制御端末1503の内部構成例を図14に示す。図14に示すように、フォーマット変換は、変換部1605において、MPEGoverATMフォーマットとMPEGover1394フォーマットとの間にて行われることになる。ここで、MPEGoverATMのフォーマットは、ATMフォーラムのAMSにて定められたプロトコルに従った形であってもよい。
AV制御端末1503とビデオサーバ1501間のATMシグナリングによる呼設定等は、ATMシグナリング処理部1603で行われるようになっている。
その他各部の機能は、図10と同様である。
図15に図13に示した通信ネットワークシステム全体の動作を示すシーケンスを示す。図11と異なる部分は、図15のステップS201で(図11のステップS101に対応)、ビデオーサーバ1501とAV制御端末1503間に経路を確立する際に、ATMシグナリングによる呼設定を行う仮想コネクション(VCI=#x)を確立する点である。その他の部分はほぼ同様である。
ちなみに、本実施形態では、家庭内のネットワークが1394バスで構成されている例を示したが、本発明の手法は、家庭内のネットワークが1394バスではなく、他のネットワーク技術(例えばATM等)においても適用可能であることはいうまでもない。
以上の実施形態では、受信端末側にMPEGデコーダが配置されている場合についての例を示してきた。これに対し、MPEGデコーダが受信端末側には存在せず、生の映像データをそのまま受け取り、これを映し出す機能しか有しない場合も考えられる。
このような場合、例えば、図9の通信ネットワークシステムにおいて、AV制御端末1103にてフォーマット変換をする代わりに、MPEGデコーダ1805を図16に示すように、AV制御端末1103内に配置し、AV制御端末1103に入力されるMPEGoverIPデータ(あるいはMPEGoverATMデータなど)について、AV制御端末1103内でMPEGデコードを済ませてしまい、1394バス1104を介して受信端末1105に対しては、MPEG復号化が終わった生の映像データを送信する構成とすることも可能である。この場合のシーケンスを図17に示す。すなわち、図11と異なる部分は、図11のステップS104〜ステップS105が、図17では、ステップS111〜ステップS113に置き換わっていて、フォーマット変換を行わずに、MPEGデコード部1805にてMPEGoverIPデータ(あるいはMPEGoverATMデータなど)をMPEGデコードして生の映像データを1394バス1104上の同期チャネル#xを介して受信端末1105に送出するようになっている(図17のステップS111〜ステップS113)。
これにより、AV制御端末1103にMPEGの復号化などの高度な機能が集中するようになるため、受信端末1105の負荷が小さくなるというメリットもある。図9ではビデオサーバ1101とAV制御端末1103間がインターネットで有るものとしているが、無論、インターネットに限定するものではなく、ATM網やSDH網、FTTH等のネットワーク構成においても本手法をとることが可能である。
なお、AV制御端末1103の構成として、同時に複数のMPEGストリームの処理が可能となるような構成も考えられる。この場合、ストリーム毎に別個の処理、例えば、あるMPEGストリームについてはMPEGデコード、別のあるMPEGストリームについてはMPEGoverIPからMPEGover1394へのフォーマット変換を行うといった処理形式も可能である。この場合は、AV制御端末1103内部に、複数のMPEGデコーダや、MPEGエンコーダ、
あるいは乗せ換え部を具備すればよい。
(第3の実施形態)
図18に第3の実施形態に係る通信ネットワークシステムの全体の構成例を示す。
図18に示すように、第3の実施形態に係る通信ネットワークシステムは、ルータ2001、第1のハーフコネクタ2002、第2のハーフコネクタ2003、AV制御端末2004、受信端末2005、インターネット2011、第1の1394バス2012、第2の1394バス2013からなる。
図18において、ルータ2001を含め、ルータ2001より右側の機器(ルータ2001、第1の1394バス2012、第1のハーフコネクタ2002、第2のハーフコネクタ2003、第2の1394バス2013、AV制御端末2004、映像端末2005)から構成されるネットワークは家庭内に構成されるもの(ホームネットワーク)であっても良い。
また、本実施形態においても、第1の実施形態と同様に、受信端末2005は非IP端末とする。
ここで、インターネット2011上にあるビデオサーバ(図示せず)からのビデオデータ(MPEGoverIPで伝送されてくるとする)を、非IP端末である受信端末2005にて受信する場合を考える。
なお、ここでも、第2の実施形態と同様に、インターネットあるいはビデオサーバとIPにて直接ネゴシエーションするのはAV制御端末2004である。
第2の実施形態と異なる部分は、MPEGoverIPからMPEGover1394への乗せ換え制御を行うのが、AV制御端末2004ではなく、第2のハーフコネクタ2003である点である。(なお、該乗せ換え制御を行うのは、第2のハーフコネクタ2003ではなく、第1のハーフコネクタ2002であってもよいし、ルータ2001であってもよい。本実施形態では、乗せ換え制御は第2のハーフコネクタ2003にて行うものとする)
このため、AV制御端末2004は第2の1394バス2013につながれてはいるが、第1の実施形態のように、インターネット2011から受信端末2005に至る経路上にある必然性は必ずしも無い。
また、ここでは第2のハーフコネクタ2003が、受信端末から見て、セットトップボックスのように見えても良い。
また、本実施形態においては、インターネットのサブネット間(IPサブネットとIPサブネットの境界間)での帯域制御はRSVPにて行い、サブネット内(即ちルータ2001よりも右側の構成部)については、第1の実施形態にて説明したFANPを用いるものとする。よって、ルータ2001とAV制御端末2004がRSVPノード、ルータ2001と第1のハーフコネクタ2002と第2のハーフコネクタ2003とAV制御端末2004がFANPノードとなる。
両ハーフコネクタ2002、2003間の伝送方式は、ここでは第1の実施形態と同様にATMであるとする。
次に、図19を参照して、ビデオデータ伝送のシーケンスを説明する。
受信端末2005にて、インターネットから送られてくるビデオを享受したいと考えているユーザは、第2の実施形態と同様にAV制御端末2004を操作して、番組のリクエストを行う。ここで、実際の操作画面は、映像端末2005に具備されるディスプレイ装置に表示されるようになっていてもよい。また、この予約の時、高い通信品質にてビデオ番組を享受するため、RSVPにて通信資源の予約を行ってもよい。よって、インターネット2011側から送られてくるRSVPのPATHメッセージに対し、RSVPのRESVメッセージにて通信資源の予約を行う(ステップS201)。なお、ハーフコネクタ2002、2003はRSVPノードではないため、RSVPのメッセージは通過する。
RESVメッセージを受け取ったルータ2001は、第1の実施形態にて説明したFANPを用いて、ルータ2001からAV制御端末2004に至る経路のコネクションと通信資源とを確保する。このとき、FANPにて転送されるデータがMPEGデータである旨を各ノードに通知しても良い。
確保された通信資源が、例えば、図20に示すように、第1の1394バス上の同期チャネル2202、ハーフコネクタ間のコネクション2203、第2の1394バス上の同期チャネル2204であるとする。ここで、第2の1394バス上の同期チャネル2204については、1394バスの性質上、第2の1394バス上をブロードキャストされる。
さて、ルータ2001から送信されるFANPオファーメッセージを受け取ったAV制御端末2004は(ステップS202)、FANPリダイレクトメッセージを送り返すことにより(ステップS203)、コネクションの確立を了承すると共に、以下の2つの動作をこれと前後して行う。
1つ目の動作は、映像端末2005に対して、1394プロトコルにて、同期チャネル2204での同期データの受信を指示することである(ステップS204)。これにより、実質的に、図20のルータ2001から映像端末2005までの通信品質が保証されたコネクションが確立された状態になる。
AV制御端末2004の2つ目の動作は、第2のハーフコネクタ2003に対して、MPEGoverIPからMPEGover1394へのフォーマット変換を指示することである(ステップS205)。なお、MPEGover1394のフォーマットは、IEC1883などにより定められたフォーマットであってもよい。この場合、AV制御端末2004は、第2のハーフコネクタ2003があらかじめ該乗せ換え機能を有していることを認識していても良いし、乗せかえ機能の有無を確かめるための何らかのプロトコルが網内を走っていてもよい。
この乗せ換え指示は、IPのアプリケーションとして行われても良いし、1394のアプリケーションとして行われても良い。そのために、第2のハーフコネクタ2003は、図21に示すように、内部にMPEGoverIPからMPEGover1394への乗せ換え機能(変換部2304)を有したものとなる。
第2のハーフコネクタ2003の内部構成において、第1の実施形態のハーフコネクタの内部構成と異なる部分は、第2のハーフコネクタ2003では、MPEGover1394/MPEGoverIP変換部2304が構成要素となっている点と、IP/FANP処理部2303が、図19のシーケンスのステップS205における「乗せ換え指示」の信号にしたがって、MPEGover1394/MPEGoverIP変換部2304の設定を行い、MPEGデータが載った適当な入力IPパケットについて、MPEGoverIPからMPEGover1394へのフォーマット変換を行う様に設定する機能を有する点である。
さて、ルータ2001に達したRSVP・RESVメッセージは、更に上流に上り、ビデオサーバ(図示せず)に到達する(ステップS206)。この時点で、図20に示すように、ビデオサーバから映像端末2005までの通信品質の保証されたエンド・エンドのコネクションが確立されたことになる。なお、ビデオデータの送信に先立って、AV制御端末2004からビデオサーバに対して、何らかの通知信号(映像データの送信を促す信号)が伝達されても良い。
その後、ビデオサーバからビデオデータの伝送が開始される(ステップS207)。ビデオデータは、図20のIP上のコネクションの集合2201を通った後、FANPにより確立されたコネクション2202、2203、2204を通って映像端末2005に到達する。なお、第2のハーフコネクタ2003において、MPEGoverIPのフォーマットからMPEGover1394フォーマットへのフォーマット変換が行われている。
以上の説明は、映像端末2005がMPEGデコーダを有している場合である。これに対し、映像端末2005がMPEGデコーダを有しておらず、生の映像データの受信を行って、それを再生するといった構成になっている場合については、第2のハーフコネクタ2003にMPEGデコーダを配し、MPEGoverIPからのMPEGデコードを行なわせ、生の映像データとした上で、映像端末2005に送信する構成も可能である。このようにすることにより、映像端末2005に高価なMPEGデコーダの実装を行う必要がなくなり、低コストなシステムの構築が可能となるメリットがある。
この場合の第2のハーフコネクタ2003の内部構成例を図22に示す。図22において図21と異なる部分は、図21のMPEGover1394/MPEGoverIP変換部2304の代わりに、MPEGデコーダ部2404が配置されている点である。
MPEGデコーダ部2404では、AV制御端末2004から第2のハーフコネクタ2003に対して、MPEGデータのデコードを指示する指示信号が送られた場合にMPEGデコードを行うようにしてもよい。
なお、MPEGのフォーマット変換、あるいはMPEGのデコードを行う場合には、2つのハーフコネクタ2002、2003間のリンクのデータリンク識別子(例えばATMならVPI/VCI等)の値から、これのコンテンツがMPEGデータであると暗示的に認識し、IPレイヤ処理を行うこと無く、フォーマット変換、あるいはデコード処理をおこなってもよい。このようにすることにより、一般にコストがかかるといわれているIP処理を省いてMPEGフォーマット変換処理、あるいはデコード処理にとりかかることが可能となるため、迅速な処理と低コストかが同時に図ることが可能となる。
なお、言うまでもないが、このような構成のシステムは、インターネットからのビデオのみでなく、第2の実施形態のようにアクセス網がATM網である場合のMPEGoverATMによる映像データの伝送、その他の方式によるものでも良い。
また、ビデオデータ(あるいは一般のデータ全般)の伝送もMPEGに限定したものではなく、任意の符号化方式の適用が可能である。
また、以上の操作は、応用として、家庭からの情報の発信にも使うことができる。すなわち、図23に示すような構成の通信ネットワークシステムにおいて、非IP端末である送信端末3001からの生の映像、もしくはMPEGデータ送信を行うことを考える。
基本的に、先の受信の場合と反対のシーケンスを行えば良い(図25に示すシーケンス参照)。すなわち、AV制御端末3002は、ネットワークレイヤのシグナリングプロトコルにて受信端末までのコネクションを確立し(ステップS301)、FANPオファーメッセージにて、同期チャネル番号等をルータ3005に送信し(ステップS302)、ルータ3005からのリダイレクトメッセージを受け取る(ステップS303)。また、AV制御端末3002は、送信端末3001に対して、1394プロトコルにて、先に設定された同期チャネルでのデータの送信を指示し(ステップS304)、さらに、AV制御端末3002から例えば、第1のハーフコネクタ3003に対して、乗せ換え(あるいはMPEG符号化)の指示を送る(ステップS305)。
これにより、例えば、第1のハーフコネクタ3003に、図24に示すようなMPEGエンコーダ3404(送信端末3002にMPEGエンコーダを具備しない場合)、あるいは、図21に示すようなMPEGover1394からMPEGoverIPへのフォーマット変換機能(変換部2304)を配備しているならば、送信端末3001からのデータ伝送を行うことが可能となる(ステップS306)。
なお、例えば、図22に示した構成のハーフコネクタに、図24に示した構成のハーフコネクタのMPEGエンコーダ部3404(1394側からATM側に向けて送出するビデオデータをエンコードする)を具備して、MPEGエンコーダとMPEGデコーダを同時に持つようにすれば、単一の装置(ハーフコネクタ)にて双方向の通信が可能となる(片方向の通信を同時に2本以上行い、おのおのでエンコーダ、デコーダをそれぞれ用いる、といった使い方も、もちろん可能である)。
また、MPEGエンコード、MPEGデコード、MPEGフォーマット変換のそれぞれの機能を持ち、AV制御端末3002からの適当な制御信号により、モードを切り替えて(これらの機能のうち必要な部分についての機能を実行する)様な構成も考えられる。
また、同時に複数のMPEGストリームの処理を可能とするような構成も考えられる。この場合、ストリーム毎に別個の処理、例えば、あるMPEGストリームについてはMPEGデコード、別のあるMPEGストリームについてはMPEGoverIPからMPEGover1394へのフォーマット変換を行うといった処理形式も可能である。
1…送信端末、2…第2のAV制御端末、3…第1のハーフコネクタ、4…第2のハーフコネクタ、5…第2のAV制御端末、6…受信端末、11…第1の1394バス、12…第2の1394バス、1101…ビデオサーバ、1102…インターネット、1103…AV制御端末、1104…1394バス、1105…受信端末、1501…ビデオサーバ、1502…ATMアクセス網、1503…AV制御端末、1504…1394バス、1505…受信端末、2001…ルータ、2002…第1のハーフコネクタ、2003…第2のハーフコネクタ、2004…AV制御端末、2005…映像端末、2011…インターネット、2012…第1の1394バス、2013…第2の1394バス、3001…送信端末、3002…AV制御端末、3003…第1のハーフコネクタ、3004…第2のハーフコネクタ、3005…ルータ、3011…第1の1394バス、3012…第2の1394バス、3013…インターネット。