JP4338525B2 - ネットワークを通じて異なるネットワークプロトコルを支援する受信機にデータストリームを送信するシステム - Google Patents

Description

本発明は、制御データと有効データを有するデータストリームを送信するシステムに関する。このシステムは、１つの送信機，少なくとも２つの典型的な受信機及びこの送信機とこれらの受信機との間に設けられている１つのネットワークを有する。受信機のうちの第１受信機は、第１ネットワークプロトコルを支援し、第２受信機は、第２ネットワークプロトコルを支援する。

機器をネットワーク化するため、いろいろな物理ネットワークが、使用分野に応じて過去において開発された。多くの場合、互換性の理由から、ネットワークに固有のネットワークプロトコルにしたがってデータを送信することに加えて、別のネットワーク又は別のネットワークプロトコルのデータを透過的に送信するという可能性もある。例えばこれに関しては、インターネットプロトコルに相当するネットワーク（ＩＰネットワーク）によるＩＰＸパケットの送信，ＩＥＥＥ基準 1394-1995又はＩＥＥＥ基準 1394a-2000 （1394ネットワーク）にしたがうネットワークによるインターネットプロトコルに相当するパケット（ＩＰパケット）及びＩＥＣ61883 にしたがうＲＴＰ又は1394ネットワークを用いたＩＰネットワークによるＭＰＥＧ２トランスポートストリームの送信を参照のこと。この場合、どのネットワークプロトコルがその都度の端末機器によって支援されるかに応じて、同一の物理ネットワークに転送するための実際の有効データをいろいろにパックにするか又は構成する必要がある。

使用されるネットワークがポイント・ツー・ポイント接続だけを物理的に構成する場合、このことは問題ない。有効データがそれぞれ１つの受信機だけに対して送信できる場合、このことは問題ない。しかしこの状況とは違って有効データが複数の異なる受信機に対して送信されなければならない場合、このことは、存在するネットワークを物理的に支援するものの、これらの個々の受信機は、互換性のない異なるネットワークプロトコルだけを支援する。この場合、有効データを異なるネットワークプロトコルに応じて多重に、例えば時分割で送信することが必要である。その結果、各受信機は、その受信機によって支援されるネットワークプロトコルに相当するデータを受信する。これらの有効データのこの何回もの送信の欠点は、ネットワークに必要な伝送帯域幅が大きい点にある。しかも、自由に使える送信帯域幅を超えるため、有効データを全ての受信機に対して同時に送信することが不可能である。

もう１つの基本的に既に公知の可能性は、ネットワーク変換部(Netzwerkuebergaenge) を相当する受信機に直列接続する点にある。これらの受信機によって支援されなかったネットワークプロトコルが、これらのネットワーク変換部によって固定にプリセットされた規則にしたがってこれらの規則によって支援されるネットワークプロトコルに変換される。対応するコンパイル装置が、国際公開第98 20647号明細書から公知である。この場合、ネットワークプロトコル間の違いのために、それぞれの受信機によって受信されるデータストリームが、送信機によって通常はもはや完全に制御されないか、又は、付随するネットワークプロトコルの可能性が、送信機によって通常はもはや完全に利用されない。したがって、送信すべきデータが、特定のネットワークプロトコルで送信機自体に存在する場合、別のネットワークプロトコルが、中間にあるネットワーク上で使用されるときに、この特定のネットワークプロトコルを使用する受信機がこれらのデータを変えないで保持することは保証され得ない。

本発明の課題は、上述した欠点を甘受することなしに送信機からネットワークを通じて異なるネットワークプロトコルを支援するいろいろな受信機に向けて効率のよい帯域幅でデータストリームを送信する手段を提供することにある。

この課題は、請求項１に記載の特徴を備えたシステムによって解決される。本発明の好適な構成及びその他の構成は、従属請求項２〜１２中に記載されている。請求項１３〜２０の対象は、制御データと有効データを有するデータストリームを生成する送信機である。請求項２１〜２６は、制御データと有効データを有するデータストリームを受信する実際の受信機に直列接続すべき機器又はこの機器内に組み込むべき処理ユニットに関する。 本発明の利点は、同じ有効データを何回も送信する必要がない点である。これらの有効データは、専ら唯一のネットワークプロトコルにしたがって送信される。１つのコンパイルユニットが、このネットワークプロトコルを支援しない全ての受信機にそれぞれ割り当てられている。このコンパイルユニットは、このネットワークプロトコルにしたがって送信される有効データを使用してそれぞれの受信機のネットワークプロトコルに相当するデータストリームを生成する。この説明したコンパイルユニットは、それぞれの受信機に直列接続されているか又はこの受信機内に組み込まれている。

本発明のもう１つの利点は、全ての支援されるネットワークプロトコルに対する完全な透過性にある。このため、送信に利用されるネットワークプロトコルに相当する実際の有効データに加えて、場合によってはそれぞれのネットワークプロトコルに変換するために、受信機が必要とする追加データが一緒に送信される。
これらの追加データは、その全て又は一部がそれぞれの受信機用のデータストリームの生成時にコンパイルユニット内で利用すべきコンパイルプログラム又はこれらのコンパイルプログラムの一部に相当するデータ、すなわちコンパイルソフトウェアでもよい。これによって、それぞれのネットワークプロトコルの将来の拡張を考慮して又は新しいネットワークプロトコルを考慮してシステムを簡単に拡張することもできる。
第２ネットワークプロトコルを支援する受信機が、本発明の好適な構成にしたがって補助ネットワークを通じて共通のコンパイルユニットに接続され得る。この共通のコンパイルユニットは、同様に主ネットワークに接続されていて、第１ネットワークプロトコルにしたがう主ネットワークを通じて送信されるデータストリームを第２ネットワークプロトコルに相当するデータストリームにコンパイルする。

請求項９に記載の対象のように検査ユニットが使用される場合、より僅かな送信帯域幅しか必要としないデータストリームが常に送信されることが保証されている。
請求項１１に記載の対象のように検査ユニットが使用される場合、受信側で実際に処理され得る追加情報又はコンパイル命令だけが送信されることが保証されている。これによって、既存の受信機との十分な互換性が実現可能である。
以下に、本発明のその他の好適な特徴を図に基づいて例示的に説明する。

図１は、制御データと有効データを有するデータストリームを送信するシステムのブロック図である。例えば送信すべきデータストリームは、ＭＰＥＧ２トランスポートストリームである。このＭＰＥＧ２トランスポートストリームは、ＩＥＣ61883-4 に関連するＩＥＣ61883-1 にしたがう1394ネットワーク又はＩＰネットワークを通じてＲＴＰを用いて送信されなければならない。このデータストリーム内では、送信すべきオーディオ／ビデオ有効データが、連続するデータパケットの形態で存在する。それぞれのヘッダが、これらのデータパケットに割り当てられている。ネットワークプロトコルに固有の追加情報が、このヘッダ内に送信される。このような追加情報は、例えば送信ステートメント，受信ステートメント，タイムマーカ及びチェックサムである。この追加情報の量は、一般にオーディオ／ビデオ有効データの量に比べて小さい。オーディオ／ビデオ有効データを個々のデータパケットに分割することは、使用されるネットワークプロトコルに応じて異なってもよい。例えば、一般にＭＰＥＧ２トランスポートストリームを送信する場合、ＩＥＥＥ1394-1995 基準の多数のパケットに相当するオーディオ／ビデオデータが、インターネットプロトコル基準の個々のパケットに割り当てられる。

以下では、図１中に示されたシステムの場合、ＭＰＥＧ２トランスポートストリームが、1394ネットワーク１を通じて同時に異なる受信機に送信されなければならないことを前提とする。これらの受信機は、いろいろなネットワークプロトコルを支援する。
ネットワーク１を通じて送信すべき制御データとオーディオ／ビデオ有効データを有するデータストリームは、送信機３によって任意に処理される。この送信機３は、第１ネットワークプロトコルに相当するデータストリームを生成する手段３ａを有する。この第１ネットワークプロトコルは、ここではＩＥＥＥ基準1394-1995 及びＩＥＥＥ基準1394a-2000に関連する標準ＩＥＣ61883-1 及びＩＥＣ61883-4 によって規定されている。送信機３によって生成されたデータストリームは、ネットワーク１を通じて多数の受信機に送信される。
第１受信機４が、ＩＥＥＥ基準1394-1995 及びＩＥＥＥ基準1394a-2000に関連する標準ＩＥＣ61883-1 及びＩＥＣ61883-4 によって規定された第１ネットワークプロトコルを支援する。したがって受信されるデータストリームは、受信機４内で例えば所望のテレビ放送番組に相当するオーディオ／ビデオデータの選択と復号の目的で簡単に評価され得る。受信機４は、テレビでもよい。テレビ放送番組に相当する画像信号が、このテレビのディスプレイ上に表示される。

第２受信機５は、標準ＩＥＣ61883-1 及びＩＥＣ61883-4 を支援するのではなくて、第２ネットワークプロトコルだけを支援する、例えばインターネットプロトコル基準及び特に例えばＲＦＣ2038に関連するＲＦＣ1889にしたがうこのインターネットプロトコル基準に基づくリアルタイムトランスポートプロトコル（ＲＴＰ）：ＲＴＰであるＭＰＥＧ１／ＭＰＥＧ２ビデオ用のペイロードフォーマットを支援する。ＩＥＣ61883-4 に関連する標準ＩＥＣ61883-1 にしたがって送信される信号の評価をこの受信機にも可能にさせるため、この第２受信機５は、組み込まれたコンパイルユニット６を有する。ＩＥＣ61883-4 に関連する標準ＩＥＣ61883-1 つまり第１ネットワークプロトコルにしたがって送信される信号をインターネットプロトコル基準つまり第２ネットワークプロトコルに相当するデータに変換するために、このコンパイルユニット６が設けられている。これらの第２ネットワークプロトコルに相当するデータは、第２受信機５内で例えば所望のテレビ放送番組に相当するオーディオ／ビデオデータの選択と復号の目的で簡単に評価され得る。この受信機５は、パーソナルコンピュータでもよい。テレビ放送番組に相当する画像信号が、このパーソナルコンピュータのディスプレイ上に表示される。

図１中に示された受信機８，９は、同様に第２ネットワークプロトコルを支援する受信機である。これらの受信機８，９は、補助ネットワーク２に接続されている。この補助ネットワーク２は、コンパイルユニット７を介して主ネットワーク１に接続されている。標準ＩＥＣ61883-1 及びＩＥＣ61883-4 に関連するＩＥＥＥ1394基準にしたがって主ネットワーク１を通じて送信される第１ネットワークプロトコルに相当するデータストリームを、第２ネットワークプロトコルに相当するデータストリームに変換するために、このコンパイルユニット７は設けられている。この第２ネットワークプロトコルに相当するデータストリームは、補助ネットワーク２に対してさらに送られ、この補助ネットワーク２を通じて受信機８，９に送信される。
図１中に示された実施形の代わりに、共通の補助ネットワークが使用されることなしに受信機８，９をそれぞれ１つの固有の外部コンパイルユニットを介して主ネットワーク１に接続することも可能である。
その代わりに、第３ネットワークプロトコルだけを支援する受信機１０が共通の又は分離された補助ネットワーク２を通じてこのコンパイルユニット７にさらに接続され得るように、コンパイルユニット７を構成することも可能である。このときこのコンパイルユニット７は、必要ならばこのコンパイルユニット７がこの第３ネットワークプロトコルに相当するその他の追加情報を受信し、同時にこれらのデータを生成し、このコンパイルユニット７が相当する補助ネットワーク２を通じて１つ又は複数の受信機１０に対してさらに送る。

コンパイルユニット６，７は、それぞれのコンパイル過程用のコンパイル命令を必要とする。コンパイルプログラム及び／又はネットワークプロトコルに依存する追加データの形態で存在するこれらのコンパイル命令は、それぞれのコンパイルユニット内に不揮発性に記憶され得る。この代わりに、説明したコンパイル命令の少なくとも一部を送信されるデータストリームで送信機から受信機に送信してもよい。この場合，この最後の実施形が好ましい。
この目的のために、送信機３は、コンパイル命令に相当するデータを生成して送信すべきデータストリーム内に挿入する手段３ｂを有する。コンパイル命令に相当するこれらのデータは、データストリームの状態で受信機側に送信され、それぞれの受信機又はそれぞれのコンパイルユニット内で、場合によってはコンパイル過程に対して必要ならば、送信されるデータストリームから分離され、コンパイルユニットによってそれぞれのコンパイル過程に対して使用される。
特にコンパイル命令に相当するデータを送信機からネットワークを通じて受信機に送信することには、システムが既存のネットワークプロトコルの拡張又は新しいネットワークプロトコルに対して簡単に適合され得るという利点がある。

この代わりに、１つ又は多数の論理的に又は物理的に分離された追加のネットワークを通じて送信機から受信機に追加データの全て又は一部を送信してもよい。この場合、手段３ｂは、コンパイル命令に相当するデータを送信されるデータストリーム内に直接挿入するのではなくて、これらのデータを論理的に又は物理的に分離されたネットワークだけを通じて受信機側のコンパイルユニットに直接送る。この場合、追加データは、受信機側のネットワークプロトコルにしたがって例えば既に送信機側で手段３ｂによって分離できる。このとき、受信機側のコンパイルユニットは、追加のネットワークに少なくとも接続することができる。コンパイル過程用の追加データが、これらのネットワークを通じて受信機に割り当てられているネットワークプロトコル内に送信される。
効率の良い帯域幅の送信を保証するため、送信機３は、本発明のその他の構成にしたがって検査ユニット３ｃを有する。ネットワーク１を通じたコンパイル命令を有するデータストリームの送信が、有効データを多重に、例えば時分割で多数の異なるネットワークプロトコルにしたがって有するデータストリームの送信よりも大きい送信容量を必要とするかどうかを検査するために、この検査ユニット３ｃは設けられている。コンパイル命令を有するデータストリームが、有効データを多重に、例えば時分割で多数の異なるネットワークプロトコルにしたがって有するデータストリームよりも僅かな送信容量を必要とすると、検査ユニット３ｃが認識した場合、送信機３は、コンパイル命令を有するデータストリームをネットワーク１に対して出力する。逆に、コンパイル命令を有するデータストリームが、有効データを多重に、例えば時分割で多数の異なるネットワークプロトコルにしたがって有するデータストリームよりも大きい送信容量を必要とすると、検査ユニット３ｃが認識した場合、送信機３は、有効データを多重に、例えば時分割で多数の異なるネットワークプロトコルにしたがって有するデータストリームをネットワーク１に対して出力する。

この説明した検査は、個々のデータパケットに対して実施してもよいし、データパケットのグループに対して実施してもよいし又は全ての有効データストリームに対して実施してもよい。
本発明のもう１つの構成によれば、送信機３は、検査ユニット３ｃを有する。適切なコンパイルユニットが、第２ネットワークプロトコルだけを支援する接続されている受信機のためのネットワーク１内に存在するかどうかを検査するために、又は、対応するコンパイルユニットが、これらの受信機に直列接続されているか若しくはこれらの受信機内に組み込まれているかどうかを検査するために、検査ユニット３ｃがこの検査のために設けられている。有効データストリームを受信する全ての受信機又は直列接続されたコンパイルユニットが、コンパイル命令又はコンパイルプログラムを使用することによってこの有効データストリームを第２ネットワークプロトコル内に送信できる場合だけ、送信機３は、これらのコンパイル命令又はコンパイルプログラムをこの有効データストリームに加える。これらの特定の追加データ（コンパイルプログラム）又はコンパイル命令は、ネットワーク１に接続されていてそれぞれの有効データストリームを受信しなければならない全ての受信機を解釈できる。必要ならば、このコンパイルユニットは、例えば時分割で受信機によって支援される異なるネットワークプロトコルにしたがって有効データストリームの多重送信に切り替る。これによって、既存の受信機との互換性が実現される。

例えば、送信機３がネットワーク１を通じて問合せ信号をこのネットワーク１に接続されている受信機に送信し、これらの受信機がそれぞれネットワーク１を通じてそれぞれの受信機によって支援されるネットワークプロトコルに関する情報を含むデータを送信機３に返送することによって、上述した検査が可能になる。
以下に、例えば拡張ＩＥＥＥ基準1394a-2000及びＩＥＣ61883:"Consumer Audio/Video Equipment-Digital Interface- "に関連するＩＥＥＥ基準1394-1995:"Standard for a High Performance Serial Bus"及びＩＥＥＥ Ｐ 1394.1:"Draft Standard for High Performance Serial Bus Bridges" 中に記されているような本発明のさらなる詳細をＩＥＥＥ1394ネットワークの使用の場合で説明する。
1394ネットワーク内でのデータストリームの送信の方法が、図２中に示されている。いわゆる「サイクルマスター」によって規則的に送信される「サイクルスタート」パケットによって、時間軸が、ほぼ125 μs ごとの時間間隔に分割される。いわゆるアイソクロノス送信（転送）の開始前に、チャネル番号が、データストリームに割り当てられ、一定の最大時間成分が、このサイクル内で保存される。各サイクルスタートパケットの受信後に、個々の機器が、この機器に割り当てられた各アイソクロノスチャネルに対してデータパケットを連続してそれぞれ最大に転送する。この場合、一方で予め設定されている平均的なビットレートで、他方で用途に固有の許容しうる有効データパケットの大きさのときに、全ての保存された送信時間が、多くの場合に各サイクル内で利用し尽くされない。残りは、その残りの保存されなかったいわゆる非同期チャネルを通じたデータ送信及び制御情報の交換用の送信時間と共に任意に使用できる。ここでは確かに、各機器が各サイクル内で送信時間を得ることが保証されていないものの、他方では十分な送信時間を前提として同じチャネル番号を有する多数のデータパケットが、同じサイクル内で送信される。

図２中では、アイソクロノスチャネル０をＩＫ０で示し、アイソクロノスチャネル１をＩＫ１で示し、アイソクロノスチャネル２をＩＫ２で示し、サイクルスタートパケットをＣＳＰで示し、利用される帯域幅をＧＢで示し、利用されないが保存される帯域幅をＵＧで示し、アイソクロノス送信に利用され／保存される帯域幅をＩＢで示す。
一般にアイソクロノス式1394チャネル、場合によっては非同期式1394チャネルが、図１中の受信機４に相当する機器用の有効データストリームの送信に対して使用される。したがってコンパイルプログラムも、アイソクロノス式に又は非同期式に送信され得る。コンパイルプログラムの送信時と解釈時のいろいろに可能な実施の形態が、他の方法で送信される追加情報又は構造命令によって選択され得る。
有効データストリーム及びコンパイルプログラムのアイソクロノス送信の場合、コンパイルプログラムを同様にアイソクロノス式に送信することが考えられる。このとき、有効データパケットが、アイソクロノスサイクルに基づいてそれぞれのコンパイルプログラムパケットに対して割り当てできる。送信が、このアイソクロノスサイクル内で実施される。この割り当ては、1394.1-konforme Bridgeによっても実現される。実際のサイクル内で送信されるアイソクロノスデータのほかに、記憶装置がさらに設けられている。先行するアイソクロノスサイクルのデータが、この記憶装置内に中間記憶される。すなわちこれらのデータをコンパイルプログラムによって参照することができる。特に、必要な各アイソクロノスチャネルに対して、一定の大きさのＦＩＦＯ記憶装置が設けられている。このとき、個々の有効データパケットは、例えば、

ａ）チャネル番号及びアイソクロノスサイクルの間隔に基づいて、

ｂ）チャネル番号及びパケットの送信時のＣＹＣＬＥ＿ＴＩＭＥレジスタの上位20ビットの一部（1394.1 Netzen の場合、各アイソクロノスチャネルの遅延が、接続の開始プログラムに知らされる。その結果、受信機が開始プログラムに一致するか、又は値がこの開始プログラムによって受信機に転送されたならば、ＣＹＣＬＥ＿ＴＩＭＥレジスタの値も、受信機側で受信機バスに対して決定され得える。）に基づいて、

ｃ）特にＩＥＣ61883-konformen isochronen Datenstroemenの場合、（場合によってはチャネル番号に加えて）ＣＩＰヘッダ（場合によってはＳＩＤとＦＭＴに関連する特にＤＢＣ）に対応するフィールドに基づいても、

ｄ）さらに（場合によってはチャネル番号に加えて）（有効）データパケットのフォーマットに固有のその他の一部に基づいて

参照することができる。場合によっては起こり得るあいまいさが、ＦＩＦＯ記憶装置の内部のパケットの古さ又は位置（最後に受信されたパケットの選択）に基づいて取り除かれ得る。

追加の記憶装置がコンパイルプログラム用に設けられている場合（特に例えば、コンパイルプログラムに対して利用されるアイソクロノスチャネル当たり一定の大きさ；これらの大きさは、このチャネル用の有効データバッファにも等しい）、これらのコンパイルプログラムが、その送信時に多数のアイソクロノスサイクルに分割できる。これによって、特に有効データ速度が低い場合、コンパイルプログラムに対して確保すべき帯域幅が減少する。さらにコンパイルプログラムの一部を処理する場合、生成すべきデータパケットが多数のコンパイルプログラムパケットによって書き込まれるよりも少なくともその一部の完全性を保証することができる。そのため、特にコンパイルプログラムパケットが（例えばＣＩＰフォーマットの使用時のＤＢＣフィールドによって）周期的に番号付けされ、コンパイルプログラムパケットの廃棄時に実際の（不完全な）パケットが拒否され、コンパイルプログラムに一部が、適切な同期点の発生まで実行されない。
有効データがコンパイルプログラムとして保存された帯域幅に応じて常に送信され得、復号が既知のバッファ容量の面から受信機内で可能であるかどうかを、送信機が演繹的推論で確認できるので、バスのリセットのような特別な場合を除いて、パケット損失が起こり得ない。

上述した可能性間の違い、場合によっては別の可能性間の違いが、特別な実行中に全ての使用されるコンパイルユニットに対して一様に確認されない限り、使用されるいろいろなコンパイルプログラム(Variante)が適切な構造命令によってこれらのコンパイルユニットに送ることができるか又は送信機と受信機側のこれらのコンパイルユニットとの間でやりとりして処理することができる。
選択的にコンパイルユニット内の記憶容量を低減するため、構造命令によってこれらのコンパイルユニットに送られるか又は送信機と受信機側のこれらのコンパイルユニットとの間でやりとりされ処理される。データパケット及び／又はコンパイルプログラムが、これらのチャネルを通じて送信される。（例えば、全大きさ，パケット数，サイクル数又は対応する組合わせに応じた）範囲内で、コンパイルプログラムパケット及び／又はデータパケットが、後続するコンパイルプログラムに対応するチャネル上に中間記憶することができる。

精確な送信に関係なく、コンパイルプログラムは、特に実際のプログラムの一部、場合によっては後続するデータの一部から構成される。それぞれのコンパイルプログラムの一部に対して、さらにcycle ＿count レジスタの上位20ビットの値が、このプログラムの一部の完全な受信に時点に対して既知である。

可能な命令セット：

ＮＯＰ
この命令は、何も処理をせず、特に後続する命令を場合によっては適切にワード境界に整列させるために使用される。

ＡＤＤ add
この命令は、次に続くＣＰＹ命令，ＣＰＹＩＭ命令又はＳＫＩＰ命令の長さを"add" オクテットだけ増やす。

ＧＥＮ start len mask value
有効データパケットを選択するための追加の比較マスターが、この命令によって決定される。"start" は開始を示す。"len" は、"mask"と"value" によって記述される比較マスターの長さをオクテットの単位で示す。

ＳＫＩＰｓ,
まだ起こらない範囲内で、先行するＧＥＮ命令，ＤＢＣ命令，ＣＩＰ命令，ＣＹＣ命令，ＣＨＡＮ命令によって特定された有効データパケットを選択した場合、そこから４ｓ飛び移り、さらに場合によっては最後のＣＰＹ又はＳＫＩＰから実行されたＡＤＤ命令によって特定された数のオクテット飛び移る。

ＤＢＣｖ
この命令は、ＤＢＣフィールドが"v" と一致するＣＩＰパケットを選択する。

ＣＩＰ sid fmt dbc
この命令は、フィールドＳＩＤ，ＦＭＴ及びＤＢＣに関して"sid" ，"fmt" 及び"dbc" によって特定された比較マスターに一致するＣＩＰパケットを選択する。この場合、場合によっては「ワイルドカード」も使用され得る。

ＣＹＣｃ
この命令は、アイソクロノスサイクルに基づいてアイソクロノスパケットを選択する。アイソクロノスパケットは、アイソクロノスサイクル内にパラメータ"c" によって特定することによって送信される。同時に、全ての先行するＧＥＮ命令，ＤＢＣ命令及びＣＩＰ命令の作用が廃棄される。

ＣＨＡＮｃ
この命令は、チャネル番号"c" を有するパケットを選択する。同時に、ＧＥＮ命令，ＤＢＣ命令及びＣＩＰ命令の作用が廃棄される。1394.1のネットワークの場合、"c" は、意味的に直接チャネルを示すのではなくて、例えば送信機の"output-Plug" レジスタを示す。それ故にこの値は、（先行する構造コマンドによって実行される結合構造に基づいて既知である）ローカル1394バスの付随するチャネル番号と最初に交換することができる。

ＣＰＹｓ
次の４ｓ及びさらに場合によって最後のＳＫＩＰ命令，ＣＰＹ命令又はＣＰＹＩＭ命令から処理されたＡＤＤ命令によって特定された数のオクテットを最後に選択されたパケットから実際に生成すべきパケットに付け加える。

ＳＴＯＰ
コンパイルプログラムを終了させ、場合によっては最後に生成されたデータパケットを送信する。（まだデータだけが、コンパイルプログラムパケット内で追随する。）

ＣＰＹＩＭｓ
コンパイルプログラム内で追随する４ｓ及びさらに場合によって最後のＳＫＩＰ命令，ＣＰＹ命令又はＣＰＹＩＭ命令から処理されたＡＤＤ命令によって特定された数のオクテットを実際に生成すべきパケットに付け加える。

最後に、ＩＥＥＥ1394/ ＩＥＣ61883 仕様とは異なって、チャネル当たり確保された送信時間が有効データストリームによって多くの場合に不完全に利用し尽くされるよりも、場合によってはコンパイルプログラムチャネル用の追加の帯域幅の確保を省略するか又はこの追加の帯域幅を少なくとも低減してもよい。何故なら、アイソクロノスチャネル用に確保された全時間部分を超えることなしに、コンパイルプログラムチャネルによって要求される送信時間部分が、対応するアイソクロノスサイクル内に付随する確保部分を逆にそれに応じて越えうるからである。
有効データストリーム又はコンパイルプログラムの非同期送信の場合、ＣＹＣＬＥ−ＴＩＭＥレジスタの付随する値が、この値の送信時に受信機側で非同期パケットの場合でも既知であるならば、ここでもアイソクロノス有効データストリームに関して説明した方法が実施される。確かにこのことは、特に1394.1-bridgesとは一般に違う場合である。個々の有効データパケットの身元を確認するため、一般にチャネル番号に加えて、及び送信ステートメント(source ＿id-Feld)のＧＰＳＡの場合、先の段落で説明した可能性中の下のｃ）及びｄ）だけが任意に使用できる。有効データストリーム又はコンパイルプログラムストリームのバッファリングに関しては、アイソクロノスの場合と同様な可能性が得られる。確かに、有効プログラムパケット又はコンパイルプログラムパケットが、コンパイルを理論的に可能にする時点で受信機内にもはや存在しないように一定の所定のバッファ量で考慮する必要がある。このことは、特性が保証されないネットワークの高負荷時の接続中のパケット損失に相当する。

以下に、コンパイルプログラムの命令セットを例示的に示す：

ＣＯＮＴＩＮＵＥ
実際に形成されたデータパケットを遮断することなしに、コンパイルプログラムにその次のコンパイルプログラムパケットを続ける。

ＣＰＹＩＭＮｓ
ＣＰＹＩＭＮと類似するものの、形成されたデータパケットをさらに送信する。
以下に、ＩＰパケットを送信する用途の場合で本発明をさらに詳しく説明する。

直列接続されたコンパイルユニットを有するIpover1394機器と直列接続されたコンパイルユニットを有さない機器とを区別するため、以下のメカニズムが使用可能である：
−1394ＡＲＰプロトコルの拡張（図３参照）：
コンパイルユニットが、直前のＡＲＰレスポンス(opcoded=2) に加えて別のオペコード、特に例えばopcode=3を有するＡＲＰパケットをＡＲＰリクエストに送信する。同時に、コンパイルプログラムパケット用のＦＩＦＯアドレスが、場合によってはsender＿unicast ＿FIFO＿hi/lo 内に送られる。
−コンフィグレーションＲＯＭ：

直前のunit＿spec＿ID=0x00005E とunit＿sw＿version=0x000001による入力に加えて、unic＿spec＿IDとunit＿sw＿version とから成る、例えば特にunit＿spec＿ID=0x00005E とunit＿sw＿version=0x000002と別の組合わせによる別の入力がセットアップされる。
送信機は、この送信機がコンパイルプログラムパケットを送信できるかどうかを場合によっては同様にこれらの両可能性のうちの一方の可能性によって示す。
コンパイルプログラムを送信するため、これらのコンパイルプログラムが、非同期チャネル又はアイソクロノスチャネルを通じて送信されるならば、P.Johansson ：Ipv4overIEEE1394,12 月1999( ＲＦＣ2734) 中に記されているような（図４参照）ＧＡＳＰフォーマットが使用される。実際のコンパイルプログラムは、場合によっては図５の"encapsulation header"にしたがって存在するか、又は"if"が０でない場合は"data"領域の開始に対して図６にしたがって存在する。この"encapsulation header"が、特別な実行中にＧＡＳＰパケット内で使用される場合、通常のIpover1394パケットとコンパイルプログラムパケットとが、既に保存された"t" ビット（t=0:Ipover1394パケット，t=1 コンパイルプログラムパケット）に基づいて又は固有の"ether＿type" によって区別できる。その他の場合、ＧＡＳＰパケットの"version" フィールドが、例えばIpover1394パケットに対しては"version=1" 及びコンパイルプログラムパケットに対しては"version=2" によってこの区別のために使用することができる。

この代わりにアイソクロノス送信の場合、特別に規定すべきＣＩＰ−ＦＭＴを使用してもよい。対応するヘッダに対するオーバーヘッドがここではより小さくできるので、これによって必要な帯域幅がより少なくて済む。このとき、１本のアイソクロノスチャネルが同時に多数の送信機によって利用されるので、ＧＡＳＰヘッダに余裕がなくてはならない。
コンパイルプログラムも、実行中に1394-block-writes によって送信されるならば、これらのコンパイルプログラムをＡＲＰ応答から応答可能なＦＩＦＯアドレスに対してセットすることができる。これらのコンパイルプログラムが、特別な実行中に通常のIpover1394パケット用のコンパイルユニットと区別が付く場合、コンパイルプログラムに対して"encapsulation header"の送信が省略できる。その他の場合、両パケットタイプは、このパケットタイプの"t" ビット又は"ether＿type" によって区別される。
以下に、送信に関与する受信機の確認を説明する。
ＩＰユニキャストの場合、上述したように、コンパイルユニットがその都度の次の受信機に割り当てられているかどうかを検査するだけで済む。
ＩＰブロードキャストに対する状況も同様である。ここでは、テストが、全てのIpover1394対応の機器に及ぶ。

ここでは多くの場合に制限的に不必要であるものの、この方法は、マルチキャストでも使用できる。以下に、コンパイルユニットが実際の各受信機に直列接続されているかどうかをどのようにして精確に判別され得るかを説明する。
−ＩＰルータ機能のない受信機
割り当てられたコンパイルユニットなしに受信機を確認するためには、ＩＧＭＰプロトコルを使用する必要がある。送信機３が、このＩＧＭＰパケットを転送しないことを別の方法で、例えば適切なコンフィグレーションパケットによって前もって全てのコンパイルユニットに知らせた後に、この送信機３は、受信機を確認する目的で要求することなしに図７のＩＧＭＰ問合せをそれぞれのマルチキャストアドレスに送信する。それ故に、マルチキャスト受信機だけが、コンパイルユニットなしに応答する。応答がない場合、コンパイルユニットのない受信機がその時点ではマルチキャストアドレス上で作動していない。 ＩＧＭＰｖ２では、可能な限り短い応答時間"Max Resp Time" が設けられる。特別な実行では、コンパイルプログラムパケットの使用を支援し、これらのコンパイルプログラムパケットを公表した送信機によって、ＩＧＭＰ問合せが、特別な最大応答時間、例えば"Max Resp time"=1 でコンパイルユニットのない受信機を確認するためだけに使用されることも規定できる。この場合、後続するＩＧＭＰ問合せについてコンパイルユニットに個別に知らせることが省略できる。

ＩＧＭＰｖ３では、各受信機がＩＧＭＰ問合せに応答する必要があることが規定されている。それ故に、ここでは対応する問合せの後に、ブロードキャストパケットと同様に実施され得る。ＩＧＭＰｖ３に関しては、Cain等:Internet Group Management Protocol, Version3, 2001 年３月(Internet Draft: draft-ietf-idmr-igmp-v3-07)を参照のこと。
各受信機が加入前にマルチキャストアドレスに要求されないで発信するＩＧＭＰ情報を監視することによって、新しい受信機が存在するマルチキャストアドレスに加入するかどうかが確認され得る。次いで判別が、これらの受信機に対して上述したように実施できる。
−ルータ機能を有する受信機
固有のルーチングプロトコルが、特別なIpover1394ネットワーク内で使用されない場合、受信するＩＰルータが、ルー多機能のない受信機に対してと同様に確認される。
その他の場合は、処理がそれぞれのルーチングプロトコルに依存する：
例えば、各ルータは、ＤＶＭＲＰで各マルチキャストアドレスに対してこのマルチキャストアドレスによって供給される全ての受信機のリストを管理する。それ故に、少なくとも送信機自体がルーチングプロトコルに加入している場合、この送信機は、この送信機がルータ機能を有するどの受信機に供給するかを確定できる。ＤＶＭＲＰに関しては、T.Pusateri:Distance Vector Multicast Routing Protocol, 2000 年８月(Internet Draft:draft-ietf-idmr-dvmrp-v3-10)を参照のこと。
全ての受信するルータの精確な確認が不可能である場合、一般にそれぞれのルーチングプロトコルに対して加入することによって、どのルータがローカルサブネットワーク内に存在するかを少なくと確認することができ、これらのルータの各々を可能な受信機とみなすことができる。

以下に、1394.1ネットワークにおけるチャネルの割り当ての送信及びその他の追加情報を説明する。
実際のIPover1394基準では、ＭＣＡＰ情報を用いたデフォルト・ブロードキャスト・チャネル以外のチャネルを使用することが記されている。さもなければ必要な計算機能を考慮した場合、この使用は、コンパイルプログラム及びこれらのコンパイルプログラムによって間接的に参照された1394チャネルを使用するときでも実施しなくてはならない。直前のＭＣＡＰ情報に対する識別が、情報自体の"opcode"フィールド又は適切に拡張した個々のＭＣＡＰグループ・アドレス・ディスクリプションの"type"フィールドによって実行できる。この場合、直前の情報に加えて、間接的に参照された各チャネル，場合によってはこのチャネルに対して必要な記憶容量を示すことができ、1394.1ネットワークの場合は付随する情報源のＧＵＩＤ番号及びＰｌｕｇ番号も示すことができる。特にこれに対しては、図８のフォーマットが使用され得る。ここでは、total ＿len が記述子の全長を示す。Channel,speed 及びbandwidth がコンパイルプログラムの送信に使用されるチャネルを示す。既に確保されたフィールドgroup ＿addr＿len 内には、group ＿address 自体の長さが、オクテットの単位で示されている。間接的に参照されたチャネルの直接続くリストが、例えば図９の入力から構成される。将来の拡張のため、図１０のフォーマットが確保される。

以下に、ＩＰｖ４ネットワークを使用した場合の本発明のさらなる詳細を説明する。
有効データストリームの変換に関与する全てのパケットが、長さステートメントを有する特別なＩＰヘッダオプションによって示される。実際のコンパイルプログラムは、有効データストリーム内部で又は別に提供された（例えば、ＩＰ）接続によって送信され得る。送信機の順序を再構築するため、各（論理）送信機によって出力される全ての有効データストリームに共通のシーケンス番号列が、各（論理）送信機によって送信される。異なる有効データストリームに対して異なるパケット速度を可能にするため、シーケンス番号も、有効データストリーム内部で送信され得る。この場合に欠けているパケットを確認できるようにするため、パケットのシーケンス番号に加えて、先行する（又は代わりの実行中に−この場合、確かに場合によっては送信機に対する因果関係が発生するその次の）パケットのシーケンス番号がさらに送信される。この場合、同じシーケンス番号が異なる有効データストリームのパケット内に発生できることが重要である。これによって、所定のビット数の全ての有効データストリームにわたる１つの一義的なシーケンス番号に対して、シーケンス番号列の完全な進行に対する期間が増大する。適切なサイクル的な順序が有効データストリームに割り当てられている場合、−必要ならば−精確な送信順序が、異なる有効データストリーム間でさらに再構築され得る。このサイクルが、場合によっては個々の有効データストリームの飛び移りの下で完全に進行した場合、共通のシーケンス番号が常に増大される。

コンパイルプログラムが規定された固有の接続部を通じて送信される場合、対応するシーケンス番号が、コンパイルプログラムパケット内にも記録される。
受信機側では、シーケンス番号に応じた個々の有効データパケットが、所定の又はその他の例えば接続構成時に構成可能な大きさの場合によっては分離されたＦＩＦＯ記憶器内に記録される。このことは、コンパイルプログラムのフラグメントに対しても成立する。対応するコンパイルプログラムフラグメントの完全な進行まで、このフラグメントによって参照された全ての有効データパケットが受信されないか、又は、個々の参照された有効データフラグメントがコンパイルプログラムフラグメントの受信前にＦＩＦＯを既に再び後にした場合、それに応じてまだ不完全に生じるパケットがエラー有りとして受信され評価される。
有効データストリーム内部のシーケンス番号又はコンパイルプログラムを送信するため、新しいＩＰヘッダオプションが、ＩＰヘッダ内部に規定される（図１１，１２参照）：この場合、オプション番号"optnum"が、既に使用された全てのオプション番号と区別される。この代わりにこの区別は、オプションクラス"cl"によっても実行できる。optnum及びclを異なるコンパイルプログラムフォーマットを区別するために使用してもよい。オプションの実際の内容は、場合によっては先行するパケットのシーケンス番号を伴う送信順序を再構築するためのサイクル的なシーケンス番号及びコンパイルプログラムの少なくとも開始から構成される。ジャンプ命令によって、ＩＰヘッダからパケット内部の任意の別の場所に分岐され得る。ヘッダの全長が15個の32ビット語に限定されているので、それ故にコンパイルプログラムの一部をＩＰヘッダの外部にも保管することが必要になりうる。この場合に図１中の機器４のような受信機との互換性を実現するためには、このような機器によって無視される適切な位置をより高いレベルのプロトコルの内部で見つけ出す必要がある。一般にこれに対しては、既に設けられている拡張可能性が、異なるＩＰプロトコル内で利用される。この場合、ＩＰヘッダ自体の内部で新しいオプションを使用することによって、受信機側のコンパイルユニット自体が、ＩＰレベル上だけで作動し、それ故に新しいフォーマットをより高いプロトコルレベル上に挿入するときでも変更する必要がないことが保証される。

以下に、可能なコンパイルプログラム命令セットを説明する：
実際のコンパイルプログラムは、特にまた以下の命令の任意の順序から説明できる。

ＮＯＰ
この命令は、何も処理をせず、特に後続する命令を場合によっては適切にワード境界に整列させるために使用される。

ＡＤＤ add
この命令は、実際のコンパイルプログラムパケットの内部の次のＣＰＹ命令の長さを"add" オクテットだけ長くする。

ＳＴＲＥＡＭid
これによって、有効データストリームが、別のコピー動作用のインデックス"id"によって選択される。

ＪＲoffset
コンパイルプログラム内の次の"offset"オクテットを飛び越す。"offset"は、符号で、例えば２の補数でコード化することができる。"I" がＪＰ命令の長さをオクテットの単位で示す場合、ＪＲ(-1)がコンパイルプログラムの終了と解釈される。ＪＲ(0) が基本的に対応する数のＮＯＰ命令に等しいものの、特別な実行中には別の目的に対しても規定され得る。

ＰＡＣＫＥＴoffset
後続するコピー操作に対してシーケンス番号に応じて先行するパケットを"offset"間隔で選択する。

ＣＰＹＩＭｓ
実際に生成すべきパケット４ｓ及び場合によっては最後のＣＰＹ命令又はＣＰＹＩＭ命令から処理されたＡＤＤ命令によってさらに特定された数のオクテットに付け加える。

ＣＰＹstart,size
実際の情報源パケット内で"start" によって示されたオクテットで開始して、実際に生成すべきパケット４ｓ及び場合によっては最後のＣＰＹ命令又はＣＰＹＩＭ命令から処理されたＡＤＤ命令によってさらに特定された数のオクテットに付け加える。

ＣＰＹＳＴＯＰstart,size
ＣＰＹに類似するものの、同時にコンパイルプログラムを終了させる。

ＳＥＮＤ…
実際のパケットを送信する。命令の精確な長さ及び意味が、それぞれの目的プロトコルに依存する。

ＳＥＮＤ ＳＴＯＰ
ＳＥＮＤに類似するものの、同時にコンパイルプログラムを終了させる。

以下に、ＩＰネットワーク内のアイソクロノス式と非同期式の1394チャネルのエミュレーションを説明する：
一般にＡＶ有効データストリームが、特に実際のアイソクロノス1394チャネルを通じてＣＥ領域内に送信される。マルチキャストアドレスが使用可能である範囲内で、多数の受信機の有効データストリームが、このＩＰ領域内で類似のアプリケーションに対してこれらの受信機に供給されなければならない。それ故に、場合によっては動的に構成可能なマルチキャストアドレス又はマルチキャストアドレス／ポートの組み合わせを各1394チャネルに割り当てることが提唱されている。このときデータフォーマットとして、例えば実際の有効データストリームに対応するＲＴＰフォーマットが使用され得る。さらに、個々にエミュレートされた1394ノードを調整するため、別のマルチキャストアドレス／ポートの組み合わせ（以下で、制御チャネルと記す）が使用される。以下の説明では、コンパイルプログラムが有効データストリームの内部のコンパイルユニットの視点から送信される場合に限定する。

コンパイルプログラム及び有効データを割り当てる調整は以下のように実行される：
各送信機が、制御チャネルを通じて規則的な間隔で付随するコンパイルプログラムを受信するためのＩＰアドレス及びポートをこの受信機によって利用される1394チャネルに対して、場合によってはこの受信機によって参照される有効データチャネルに対して与える。これらのチャネルコンフィグレーション情報は、復号に少なくとも必要なＦＩＦＯ値に関する情報も有する。受信機が、対応する構成の問合せによって制御チャネルを通じてチャネルコンフィグレーション情報を特別な1394チャネルに対して直接送信でき、同時にこれらの受信機によってこのチャネルに対して最大に処理可能なＦＩＦＯ値を伝えることができる。これらのＦＩＦＯ値が送信機によってその時に必要とされるＦＩＦＯ値よりも小さい場合、この送信機は、コード化をそのより小さいＦＩＦＯ値に応じて適合することを試みる。このことが不足している帯域幅に起因してＩＰレベル上で不可能である場合、送信機は、エミュレートされた1394ＢＵＳリセットを初期化し、接続の後続する再構築をこの再構築時に非常に狭い帯域幅のために失敗させる。
送信機によって知らされたＦＩＦＯ値の場合、ＩＰパケットがそれぞれの受信機によって最初の送信順序で受信され、全てのデフラグメントされたＩＰパケットがそれぞれ、この受信機によって記憶されることが条件とされる。それ故に、構成の問合せ内で可能なＦＩＦＯ値の計算時に、受信機が、送信順序を再配置するために場合によっては必要な記憶装置を考慮する必要がある。したがって対応する構成の問合せによって、ＩＰ送信特性の変化に適応した制御が可能である。

コンフィグレーション問合せ／情報の可能な構成：

ａ）ヘッダ：（図１３参照）
バージョン：フォーマットバージョン（ここでは０）
下方互換性でない情報フォーマットが、新しいバージョン番号を有する。
t:パケットタイプ：
０：コンフィグレーション情報
１：コンフィグレーション問合せ
＞＝２：将来の拡張に対して確保
tlength:オクテット単位のこのコンフィグレーション情報／コンフィグレーション問合せ の全長
hlength: オクテット単位のヘッダの長さ（ここでは12又は特にfifo＿size=0に対 しては8 ）
res:将来の拡張に対して確保
fifo＿size: 必要な（コンフィグレーション情報）又は最大に可能な（コンフィグレーション問合せ）に共通のＩＰデータストリーム用のＦＩＦＯ値
s:コンフィグレーション問合せ中だけ：
０：その他の個別ＦＩＦＯの分割が不可能
１：その他の個別ＦＩＦＯの分割が可能
overhead:分割された個別ＦＩＦＯごとに、この個別ＦＩＦＯの値に加えて、管 理情報に対するfifo＿size overhead オクテットから引くことができ る。
異なるチャネル用の情報及び問合せも、ＩＰパケットの内部で連続して送信され得る。

ｂ）場合によってはこのチャネルに割り当てられたＩＰデータストリームのリストが、ヘッダに続く。図１４のフォーマットが、このリストの各要素を有する。
version:フォーマットバージョン
下方互換性でない情報フォーマットが、新しいバージョン番号を有する。
protocol ＩＰプロトコル番号
length: このリスト要素の長さ（ここでは12又は16）
dest＿addr: ＩＰ目的アドレス
dest＿port: ＩＰポート（対応するＩＰプロトコルによって支援される場合 ）
fifo＿size必要な（コンフィグレーション情報）又は最大に可能な（コンフィグレーション問合せ）のこのＩＰデータストリーム用の追加のＦＩＦＯ値。
命令ＳＥＮＤ及びＳＥＮＤ＿ＳＴＯＰのような追加のコンパイル命令を以下のように規定する：

ＳＥＮＤsecond count cycle count
直線に構成されたパケットを非同期（ａ＝１）又はアイソクロノス（ａ＝０）とみなす。このパケットは、先行するアイソクロノス1394サイクル"[second＿count,cycle ＿count]" 中又はそのサイクルの前以外に送信される。"[second＿count,cycle ＿count]" は、1394ＣＹＣＬＥ−ＣＯＵＮＴレジスタの上位20ビットに対応する。

ＳＥＮＤＳＴＯＰsecond count cycle count
ＳＥＮＤと類似するものの、同時にコンパイルプログラムを終了させる。
ＲＴＰトランスポートプロトコルを使用する場合のコンパイルプログラムの送信は、以下のように実行される：
ＲＴＰトランスポートプロトコルの仕様では、いわゆる"Header Extension"が実際のＲＴＰヘッダに選択的に続くことが規定されている。これに対しては、Schulzrinne 等著：A Transport Protocol for Real-Time Application, January 1996(RFC 1889)を参照のこと。この"Header Extension"は、この"Header Extension"を支援しないＲＴＰ実行によって無視されなければならない。特に完全なコンパイルプログラムパケット用の十分な場所がＩＰヘッダ内に存在しない場合、それ故にこの完全なコンパイルプログラムパケットは、ＲＴＰHeader Extensionの形態で送信され得る。

本発明のシステムのブロック図 1394ネットワーク内のアイソクロノス送信を説明する概略図 1394ＡＲＰプロトコルの拡張 ＧＡＳＰフォーマット "encapsulstion header" もう１つの"encapsulstion header" ＩＧＭＰ問合せ ＭＣＡＰフォーマット 図８の"indirect ＿channel ＿list" の記入フォーマット "indirect ＿channel ＿list" 中への異なる記入用のフォーマット Ipv4ヘッダ 長さステートメントを有するＩＰヘッダオプション コンフィグレーション問合せ／コンフィグレーション情報のヘッダの構成 コンフィグレーション問合せ／コンフィグレーション情報の個々の要素

符号の説明

１ 主ネットワーク
２ 補助ネットワーク
３ 送信機
３ａ １．ネットワークプロトコルに相当するデータストリームを生成する手段
３ｂ コンパイル命令に相当するデータを生成する手段
３ｃ 検査ユニット
４ １．ネットワークプロトコルを支援する受信機
５ ２．ネットワークプロトコルを支援する受信機
６ コンパイルユニット
７ コンパイルユニット
８ ２．ネットワークプロトコルを支援する受信機
９ ２．ネットワークプロトコルを支援する受信機
１０ ３．ネットワークプロトコルを支援する受信機

Claims (21)

1. 制御データ及び有効データを有するデータストリームを送信する装置にあって、この装置は：
   −少なくとも１つの送信機を備え、
   −第１ネットワークプロトコルを有するネットワークを備え、このネットワークは、少なくとも１つの送信機と少なくとも１つの受信機との間に設けられていて、
   −このネットワークに直接に又は間接に接続されている１つ又は多数の受信機を備え、これらの受信機のうちの少なくとも１つの受信機が、第１ネットワークプロトコルの代わりに第２ネットワークプロトコルを支援し、この場合、
   −送信機（３）は、第１ネットワークプロトコルに対応するデータストリームを生成する手段（３ａ）及び追加情報を生成する手段を有し、この送信機（３）は、追加情報を受信機側のコンパイルユニット（６，７）に対して転送する装置において、
   第１ネットワークプロトコルの代わりに第２ネットワークプロトコルを支援する受信機のうちの少なくとも１つの受信機（５，８，９）が、直列接続された又は組み込まれたコンパイルユニット（７，６）を有し、このコンパイルユニット（７，６）は、第１ネットワークプロトコルにしたがってアイソクロノス送信されるデータを追加情報に関連して第２ネットワークプロトコルに対応するデータに変換し、この場合、送信機(３)の手段（３ｂ）によって使用される追加情報の全部又は一部が、コンパイルプログラム又はコンパイルプログラムの一部であること、
   送信機（３）の手段（３ｂ）によって設定された追加情報の全部又は一部が、論理的に又は物理的に分離された少なくとも１つの別のネットワークを通じて受信機側のコンパイルユニットに転送されること、
   送信機（３）の手段（３ｂ）によって生成された送信機の追加情報が、受信機側の有効データプロトコルに基づいて追加情報を必要とするその他のネットワークに配分されること、
   送信機（３）は、検査ユニット（３ｃ）を有し、この検査ユニット（３ｃ）は、コンパイル命令を有するデータストリームの送信が多数のネットワークプロトコルにしたがうデータストリームの送信よりも多くの送信帯域幅を必要とするかどうかを検査するために設けられていること、及び、送信機（３）は、より僅かな送信帯域幅を必要とするデータストリームを送信すること、及び
   検査は、個々のデータパケットに対して、データパケットのグループに対して又は全ての有効データストリームに対して実行されることを特徴とする装置。
2. 制御データ及び有効データを有するデータストリームを送信する装置にあって、この装置は：
   −少なくとも１つの送信機を備え、
   −第１ネットワークプロトコルを有するネットワークを備え、このネットワークは、少なくとも１つの送信機と少なくとも１つの受信機との間に設けられていて、
   −このネットワークに直接に又は間接に接続されている１つ又は多数の受信機を備え、これらの受信機のうちの少なくとも１つの受信機が、第１ネットワークプロトコルの代わりに第２ネットワークプロトコルを支援し、この場合、
   −送信機（３）は、第１ネットワークプロトコルに対応するデータストリームを生成する手段（３ａ）及び追加情報を生成する手段を有し、この送信機（３）は、追加情報を受信機側のコンパイルユニット（６，７）に対して転送する装置において、
   第１ネットワークプロトコルの代わりに第２ネットワークプロトコルを支援する受信機のうちの少なくとも１つの受信機（５，８，９）が、直列接続された又は組み込まれたコンパイルユニット（７，６）を有し、このコンパイルユニット（７，６）は、第１ネットワークプロトコルにしたがってアイソクロノス送信されるデータを追加情報に関連して第２ネットワークプロトコルに対応するデータに変換し、この場合、送信機(３)の手段（３ｂ）によって使用される追加情報の全部又は一部が、コンパイルプログラム又はコンパイルプログラムの一部であること、
   コンパイルユニット（７）は、少なくとも１つの補助ネットワーク（２）を通じて第２受信機（８）に接続されていること、
   少なくとも１つの別の受信機（９）が、補助ネットワーク（２）に接続されていて、この受信機（９）は、第２ネットワークプロトコルを支援すること、
   送信機（３）は、検査ユニット（３ｃ）を有し、この検査ユニット（３ｃ）は、コンパイル命令を有するデータストリームの送信が多数のネットワークプロトコルにしたがうデータストリームの送信よりも多くの送信帯域幅を必要とするかどうかを検査するために設けられていること、及び、送信機（３）は、より僅かな送信帯域幅を必要とするデータストリームを送信すること、及び
   検査は、個々のデータパケットに対して、データパケットのグループに対して又は全ての有効データストリームに対して実行されることを特徴とする装置。
3. 送信機（３）の手段（３ｂ）によって生成された追加情報は、データストリーム内に封入されることを特徴とする請求項１又は２に記載の装置。
4. コンパイルユニット（７）は、システム又は別の補助ネットワーク（２）を通じて少なくとも１つの別の受信機（１０）に接続されていて、この受信機（１０）は、第３又は別のネットワークプロトコルを支援し、このコンパイルユニット（７）は、追加情報を使用してこの第３又は別のネットワークプロトコルに対応するデータに変換することを特徴とする請求項２に記載の装置。
5. 送信機（３）は、検査ユニット（３ｃ）を有し、適切なコンパイルユニットが、第２ネットワークプロトコルだけを支援する接続されている受信機のためのネットワーク（１）内に存在するかどうかを検査するために、又は、対応するコンパイルユニットが、これらの受信機に直列接続されているか若しくはこれらの受信機内に組み込まれているかどうかを検査するために、前記検査ユニット（３ｃ）がこの検査のために設けられていて、有効データストリームを受信する全ての受信機又は直列接続されたコンパイルユニットが、コンパイル命令又はコンパイルプログラムを使用することによって前記有効データストリームを第２ネットワークプロトコル内に送信できる場合だけ、前記送信機（３）は、これらのコンパイル命令又はコンパイルプログラムを前記有効データストリームに加えることを特徴とする請求項１〜４のいずれか１項に記載の装置。
6. 受信機及び／又はコンパイルユニットの少なくとも一部がそれぞれ、それぞれ支持されるネットワークプロトコルに関する情報並びに／又はコンパイル命令若しくはコンパイルプログラムを処理する可能性及び範囲に関する情報を有するデータを送信機に送信するために設けられていることを特徴とする請求項５に記載の装置。
7. 請求項１〜６のいずれか１項に記載の装置内で作動させる制御データと有効データを有するデータストリームを生成する送信機において、この送信機は：
   −第１ネットワークプロトコルに対応するアイソクロノス送信可能なデータストリームを生成する手段（３ａ）を備え、
   −コンパイル命令を有するデータをデータストリーム内に生成する手段（３ｂ）を備え、この場合、コンパイル命令が、第１ネットワークプロトコルに対応するデータを第２ネットワークプロトコルに対応するデータに変換するために設けられている送信機。
8. 手段（３ｂ）によって生成された追加情報が、データストリーム内に挿入されることを特徴とする請求項７に記載の送信機。
9. 手段（３ｂ）によって生成された追加情報の全体又は一部が、少なくとも１つの別の論理又は物理ネットワーク端子に転送されることを特徴とする請求項７又は８に記載の送信機。
10. 送信機（３）の手段（３ｂ）によって生成されたこの送信機の追加情報が、受信機側の有効データプロトコルに基づいて追加情報を必要とするその他のネットワーク端子に配分されることを特徴とする請求項９に記載の送信機。
11. 手段（３ｂ）によって設定された追加情報の全部又は一部は、コンパイルプログラム又はコンパイルプログラムの一部に対応するデータであることを特徴とする請求項７〜１０のいずれか１項に記載の送信機。
12. 送信機は、検査ユニット（３ｃ）を有し、この検査ユニット（３ｃ）は、コンパイル命令を有するデータストリームの送信が多数のネットワークプロトコルにしたがうデータストリームの送信よりも多くの送信帯域幅を必要とするかどうかを検査するために設けられていること、及び、送信機は、より僅かな送信帯域幅を必要とするデータストリームを送信することを特徴とする請求項７〜１１のいずれか１項に記載の送信機。
13. 送信機は、個々のデータパケットに対して、データパケットのグループに対して又は全ての有効データストリームに対して検査することを特徴とする請求項１２に記載の送信機。
14. 送信機（３）は、検査ユニット（３ｃ）を有し、適切なコンパイルユニットが、第２ネットワークプロトコルだけを支援する接続されている受信機のためのネットワーク（１）内に存在するかどうかを検査するために、又は、対応するコンパイルユニットが、これらの受信機に直列接続されているか若しくはこれらの受信機内に組み込まれているかどうかを検査するために、前記検査ユニット（３ｃ）がこの検査のために設けられていて、有効データストリームを受信する全ての受信機又は直列接続されたコンパイルユニットが、コンパイル命令又はコンパイルプログラムを使用することによって前記有効データストリームを第２ネットワークプロトコル内に送信できる場合だけ、前記送信機（３）は、これらのコンパイル命令又はコンパイルプログラムを前記有効データストリームに加えることを特徴とする請求項７〜１３のいずれか１項に記載の送信機。
15. 請求項１〜６のいずれか１項に記載の装置を作動させるコンパイルユニットにおいて、コンパイルユニットは、第１ネットワークプロトコルにしたがってアイソクロノス送信される有効データを、追加情報を使用して別のネットワークプロトコルに対応するデータに変換することを特徴とするコンパイルユニット。
16. 追加情報は、第１ネットワークプロトコルにしたがって送信される有効データと一緒にネットワークによって受信されることを特徴とする請求項１５に記載のコンパイルユニット。
17. 追加情報の少なくとも一部が、少なくとも１つの別の論理又は物理ネットワークによっても受信されることを特徴とする請求項１５又は１６に記載のコンパイルユニット。
18. 追加情報の少なくとも一部が、ネットワークプロトコルの後に分離して受信され、追加情報の少なくとも一部は、有効データストリームの変換時にこれらのネットワークプロトコルに対して必要になることを特徴とする請求項１７に記載のコンパイルユニット。
19. コンパイルユニットは、追加情報の全部又は一部をコンパイル命令又はコンパイルプログラム又はコンパイルプログラムの一部として解釈することを特徴とする請求項１５〜１８のいずれか１項に記載のコンパイルユニット。
20. コンパイルユニットは、請求項１４に記載の検査ユニットで使用するために規定されている情報を送信することを特徴とする請求項１５〜１９のいずれか１項に記載のコンパイルユニット。
21. 請求項１〜６のいずれか１項に記載のデータをアイソクロノス送信可能にする装置内で作動させる受信機において、この受信機は、請求項１５〜２０のいずれか１項に記載のコンパイルユニット内に組み込まれていることを特徴とする受信機。

Images