JP2011045025A - データ転送方法及びデータ転送装置 - Google Patents

Abstract

【課題】コネクションを確立するために転送されるパケット数を低減することのできるデータ転送方法及びデータ転送装置を提供する。
【解決手段】問い合わせを受けたチャネル番号が未使用の場合に、未使用のｏＰＣＲの番号がオペランド４に格納され、そのｏＰＣＲのレジスタ値がオペランド５〜８に格納されたレスポンスフォーマット（図４（ａ）参照）を含むライトパケットをシンク機器に送信する。また、問い合わせを受けたチャネル番号が使用中の場合に、そのチャネル番号の設定されたｏＰＣＲのレジスタ値がオペランド５〜８に格納されたレスポンスフォーマット（図４（ｂ）参照）を含むライトパケットをシンク機器に送信する。
【選択図】図４

Description

本発明は、データ転送方法及びデータ転送装置に関するものである。

近年、大量の音声データや動画データを扱うパーソナルコンピュータやデジタルビデオカメラといったノード間を互いに結ぶシリアルインタフェースの一つとしてＩＥＥＥ１３９４規格が注目されている。このＩＥＥＥ１３９４には、音声データや動画データなどをリアルタイム転送する際に使用されるアイソクロナス（Isochronous）転送モードと、静止画像データや制御コマンドなどを確実に伝送する際に使用されるアシンクロナス（Asyncronous）転送モードが規定されている。

アイソクロナス（Ｉｓｏ）転送では、アイソクロナスリソースマネージャ（ＩＲＭ）から取得されたアイソクロナスチャネル番号（チャネル番号）と帯域を使用して、プラグコネクションを確立した機器間でＩｓｏデータの転送が行なわれる。ここで、チャネル番号は、データ（パケット）を識別するための論理的な番号である。このチャネル番号と帯域は、バスに接続されている全てのノードの資源（リソース）であり、これらリソースを管理するのが上記ＩＲＭである。そして、チャネル番号及び帯域の取得は、ＩＲＭの公開するレジスタを書き換えることによって行われる。

また、上記プラグコネクションの確立としては、１台の機器の出力プラグと別の１台の機器の入力プラグとを接続するpoint-to-point接続（ＰｔｏＰ接続）と、一つの出力プラグ又は入力プラグを一つのアイソクロナスチャネルに接続するブロードキャスト接続とがある。このようなプラグコネクションの確立は、各機器に設けられるプラグレジスタを用いて行われる。このプラグレジスタは、各機器間におけるＩｓｏデータの転送を制御するときに、アナログインタフェースに類似した信号経路を形成するために、プラグという概念をレジスタで仮想的に構成させて実体化したものである。プラグレジスタは、ＩＥＣ６１８８３規格で規定されており、マスタプラグレジスタ（ＭＰＲ）とプラグコントロールレジスタ（ＰＣＲ）とを有する。

図９に示すように、マスタプラグレジスタ（ＭＰＲ）には、入力マスタープラグレジスタ（ｉＭＰＲ）と出力マスタープラグレジスタ（ｏＭＰＲ）とが設けられる。これらｉＭＰＲ及びｏＭＰＲは、各機器内に一つだけ存在し、入力プラグ全体及び出力プラグ全体をそれぞれ管理している。

一方、プラグコントロールレジスタ（ＰＣＲ）には、入力プラグ（接続プラグ）の属性を制御する入力プラグコントロールレジスタ（ｉＰＣＲ）と、出力プラグ（接続プラグ）の属性を制御する出力プラグコントロールレジスタ（ｏＰＣＲ）とが設けられる。これらｉＰＣＲ及びｏＰＣＲは、図９に示すように各機器内に最大３１個設けられる。ここで、図１０にｏＰＣＲのデータフォーマットを示し、図１１にｉＰＣＲのデータフォーマットを示す。これらのフォーマットは規格化されている。なお、各フォーマットの図中下部に付された数字は、フォーマットを形成する各データのビット数を示している。

図１０に示すように、ｏＰＣＲは、on-line領域と、Broadcast connection counter領域と、Point-to-point connection counter（ｐｃｃ）領域と、Reserved領域と、Channel number（ｃｈ）領域と、Data rate領域と、Overhead ID領域と、Payload領域とを有する。このｏＰＣＲのレジスタ値のうちのon-line領域は、当該ｏＰＣＲに対応する出力プラグの使用状態を示す領域である。すなわち、on-line領域の値が１であれば出力プラグがＩｓｏデータの送信可能なオンライン状態であり、０であれば出力プラグがＩｓｏデータを送信できないオフライン状態であることを示す。また、ｐｃｃ領域は、当該ｏＰＣＲに対応する出力プラグを経由して形成されるＰｔｏＰ接続の数を示す領域である。また、ｃｈ領域は、当該ｏＰＣＲに対応する出力プラグが接続されるアイソクロナスチャネル番号（チャネル番号）を示す領域である。

また、図１１に示すように、ｉＰＣＲは、on-line領域と、Broadcast connection counter領域と、ｐｃｃ領域と、Reserved領域と、ｃｈ領域と、Reserved領域とを有する。このｉＰＣＲのレジスタ値のうちのon-line領域は、当該ｉＰＣＲに対応する入力プラグがＩｓｏデータの受信可能なオンライン状態（＝１）であるか、Ｉｓｏデータを受信できないオフライン状態（＝０）であるかを示す領域である。また、ｐｃｃ領域は、当該ｉＰＣＲに対応する入力プラグを経由して形成されるＰｔｏＰ接続の数を示す領域である。また、ｃｈ領域は、当該ｉＰＣＲに対応する入力プラグが接続されるチャネル番号を示す領域である。

これらｏＰＣＲ及びｉＰＣＲのレジスタ値を適切に設定することにより、上記ＰｔｏＰ接続等のプラグコネクションを確立することができ、任意の機器間でのＩｓｏデータの転送が可能となる。

次に、ＰｔｏＰ接続の接続形態について図１２に従って説明する。なお、図１２では、ｏＰＣＲ及びｉＰＣＲのレジスタ値（とくに、on-line領域、ｐｃｃ領域及びｃｈ領域の値）を用いてＰｔｏＰ接続を示している。

図１２（ａ）に示すように、ＰｔｏＰ接続は、一つのソース機器（送信機器）Ｂ１のｏＰＣＲ［０］と一つのシンク機器（受信機器）Ａ１のｉＰＣＲ［０］とを、一つのチャネルＣＨ２（２はチャネル番号）に結び付ける接続形態である。このとき、ソース機器Ｂ１のｏＰＣＲ［０］のレジスタ値は、on-lineがオンライン状態である［１］となり、ＰｔｏＰ接続の数が一つであるためｐｃｃが［１］となり、さらにチャネル番号が［２］となる。同様に、シンク機器Ａ１のｉＰＣＲ［０］のレジスタ値は、on-lineがオンライン状態である［１］となり、ｐｃｃが［１］となり、さらにチャネル番号が［２］となる。

このＰｔｏＰ接続では、ソース機器のｏＰＣＲのチャネル番号は一意に決定し、他のソース機器と重複することはない。但し、図１２（ｂ）に示すように、シンク機器については一つのチャネル番号を共有することができる。すなわち、例えばソース機器Ｂ２のｏＰＣＲ［０］とシンク機器Ａ２のｉＰＣＲ［０］とを一つのチャネルＣＨ３に結び付けてＰｔｏＰ接続を確立し、更にソース機器Ｂ２のｏＰＣＲ［０］とシンク機器Ｃ２のｉＰＣＲ［０］との間で同じチャネルＣＨ３を利用して別のＰｔｏＰ接続を重ね張り（オーバーレイ）することができる。このとき、ソース機器のｏＰＣＲ［０］のｐｃｃは、ＰｔｏＰ接続の数が二つであるため［２］となる。

また、ＰｔｏＰ接続では、図１２（ｃ）に示すように、一つのソース機器Ｂ３が複数のチャネルを保有することができる。すなわち、ソース機器Ｂ３のｏＰＣＲ［０］とシンク機器Ａ３のｉＰＣＲ［０］とを一つのチャネルＣＨ４に結び付けてＰｔｏＰ接続を確立し、更にそのソース機器Ｂ３のｏＰＣＲ［１］とシンク機器Ｃ３のｉＰＣＲ［０］とを、上記チャネルＣＨ４とは別のチャネルＣＨ６に結び付けてＰｔｏＰ接続を確立することができる。このとき、ソース機器Ｂ３のｏＰＣＲ［０］のｃｈは［４］となり、ソース機器Ｂ３のｏＰＣＲ［１］のｃｈは［６］となる。

次に、このようなＰｔｏＰ接続を確立するための処理手順について図１３に従って説明する。
今、各機器の電源投入などによってバスリセットが発生される。すると、そのバスリセット後に、シンク機器は、接続したいアイソクロナスチャネル番号の使用状態を、ＡＶ／Ｃ接続コマンドとして規格定義されているchannel usageステータスコマンドによって全てのソース機器に問い合わせる（ステップＳ４１）。その問い合わせを受けたソース機器は、該当するチャネル番号を使用しているか否かを示す応答パケットをシンク機器に送信する。シンク機器は、ソース機器からの応答パケットに基づいて問い合わせたチャネル番号が使用中であるか否かを判断する（ステップＳ４２）。

ここで、上述したようなＡＶ／Ｃコマンド、及びその応答は、ＡＶ／Ｃの下位プロトコルであるＦＣＰ（Function Control Protocol）フレーム（図１４参照）にＡＶ／Ｃコマンドフレーム（図１５参照）がカプセル化されて送受信される。なお、このＦＣＰフレームにカプセル化されたＡＶ／Ｃコマンドフレームは、アシンクロナス転送を利用して、図１４に示すシリアルバスブロックライトパケットとしてバスケーブル上を転送される。以下に、シリアルバスブロックライトパケット（ライトパケット）及びＡＶ／Ｃコマンドフレームのデータフォーマットについて図１４〜図１６に従って説明する。

図１４に示すように、ライトパケットは、パケットヘッダと、ヘッダＣＲＣ（header_CRC）と、ＦＣＰフレームと、データＣＲＣ（data_CRC）とを有する構造である。パケットヘッダには、データの転送先のノードＩＤを示すdestination_ID、パケット番号を示すtransact label（tl）や、当該パケットがはじめて伝送されたパケットであるか、再送されたパケットであるかを示すretry code（rt）の情報が格納されている。また、パケットヘッダには、指令コードを示すtcode、パケットの優先順位を示すpriority（pri）、データの転送元のノードＩＤを示すsource_ID、destination_offset、ＦＣＰデータのデータサイズを示すdata_lengthや、extended_tcode等の情報が格納されている。ヘッダＣＲＣには、パケットヘッダに対して所定の方式により生成された誤り検出符号が格納されている。また、データＣＲＣには、ＦＣＰデータに対して所定の方式により生成された誤り検出符号が格納されている。

ＦＣＰフレームには、図１５に示すＡＶ／Ｃコマンドフレームがカプセル化されて格納される。このＡＶ／Ｃコマンドフレーム（ＦＣＰフレーム）の先頭となる上位４ビットには、Command and Transaction Set（ｃｔｓ）が記述される。このｃｔｓは、当該ライトパケットのコマンドセットのＩＤを示すもので、例えば図１５に示すように［００００］と設定されている場合には、当該ライトパケットがＡＶ／Ｃコマンドパケットであることが示されることになる。

また、ＡＶ／Ｃコマンドフレームには、上記ｃｔｓに続いて、コマンドの機能分類を示すCommand type（ctype）、送信元機器のサブユニットの種類（モニタやＶＣＲ等）を示すsubunit_type、各サブユニットを特定するためのsubunit_ID等が格納される。

さらに、ＡＶ／Ｃコマンドフレームには、上記subunit_IDに続いて、オペレーションコード（オペコード：opcode）と、そのオペコードが必要とする情報（パラメータ）であるオペランド（operand）とが格納される。このオペコードは、サブユニット毎に各種コマンドが定義され、そのオペコードごとにオペランドが定義されている。そのオペコードの一つとして、AV/C Digital Interface Command Set General SpecificationではＡＶ／Ｃ接続コマンドとしてchannel usageステータスコマンド［１２ｈ］（なお、「ｈ」はその値が１６進数であることを示す。）が規格定義されている。このchannel usageステータスコマンドは、Ｉｓｏ転送をしているソース機器のチャネル番号設定状態を問い合わせ、ソース機器のノードＩＤ、チャネル番号を設定してあるｏＰＣＲ番号をレスポンスとして送信するコマンドである。

図１６に示すように、上記channel usageステータスコマンドが設定されると、すなわちＡＶ／Ｃコマンドフレームのオペコードとして［１２ｈ］が設定されると、オペランドには当該コマンドが必要とする情報が格納される。具体的には、オペランド０にはチャネル番号が格納され、オペランド１，２にはノードＩＤが格納され、オペランド３にはｏＰＣＲ番号が格納される。

さらに、上記ステップＳ４１でシンク機器からソース機器に問い合わせるときのchannel usageステータスコマンドのリクエストフォーマットについて図１６（ａ）に従って説明する。図１６（ａ）に示すように、リクエストフォーマットでは、オペランド０にはシンク機器が接続したいチャネル番号、オペランド１，２には［ＦＦＦＦｈ］、オペランド３には［ＦＦｈ］がそれぞれ格納される。なお、上記ステップＳ４１では、図１６（ａ）に示すフォーマットのリクエストデータがＦＣＰフレームにカプセル化されたライトパケットが、シンク機器から各ソース機器に送信される。

続いて、上記リクエストフォーマットに対するchannel usageステータスコマンドのレスポンスフォーマットについて図１６（ｂ）に従って説明する。図１６（ｂ）に示すように、レスポンスフォーマットでは、シンク機器から問い合わせされたチャネル番号を使用しているときにはオペランド１，２に該当するノードＩＤ、オペランド３に該当するｏＰＣＲ番号が格納される。一方、レスポンスフォーマットでは、シンク機器から問い合わせされたチャネル番号に対して使用していない場合には、オペランド１〜３には［ＦＦＦＦＦＦｈ］が格納される。なお、このchannel usageステータスコマンドでは、図１５に示すオペランド４以降のオペランドは未使用の状態である。

図１３のステップＳ４２において、シンク機器は、図１６（ｂ）に示すフォーマットのレスポンスデータがＦＣＰフレームにカプセル化されたライトパケットをソース機器から受信し、そのオペランド０〜３の情報に基づいて、問い合わせたチャネル番号が使用中であるかを判断する。ここで、問い合わせたチャネル番号が使用中である場合、すなわち問い合わせたチャネル番号の設定されたｏＰＣＲが存在する場合には、そのチャネル番号を使用しているソース機器の送信フォーマットの確認やユニット情報の確認が行われる（ステップＳ４３，Ｓ４４）。

そして、該当ソース機器がシンク機器のサポート可能な機器である場合には（ステップＳ４５でＹＥＳ）、そのソース機器側のプラグ（ｏＰＣＲ）がロックされる（ステップＳ４６）。これにより、問い合わせたチャネル番号の設定されたｏＰＣＲがロックされ、他のシンク機器が設定変更できなくなる。続いて、そのロックされたｏＰＣＲのレジスタ値（図１０参照）が取得される（ステップＳ４７）。具体的には、シンク機器はソース機器から受信したライトパケットからノードＩＤ及びｏＰＣＲ番号を取得し、それらの情報を用いたリードリクエストによってソース機器からｏＰＣＲのレジスタ値を取得する。この取得したｏＰＣＲのレジスタ値のｐｃｃ（図１０参照）が［０］の場合には（ステップＳ４８でＹＥＳ）、ＩＲＭに対して帯域の取得とチャネル番号の登録が行われる（ステップＳ４９，Ｓ５０）。続いて、上記ステップＳ４６でロックされたｏＰＣＲのロックが解除される（ステップＳ５１）。そして、ロックトランザクションを使用して、その解除されたソース機器のｏＰＣＲと、問い合わせたシンク機器のｉＰＣＲとに対して、上記ステップＳ５０で登録したチャネル番号等の設定（更新）が行われる（ステップＳ５２）。この設定が完了すると、それらソース機器のｏＰＣＲとシンク機器のｉＰＣＲとの間にＰｔｏＰ接続が確立し、ソース機器のｏＰＣＲからシンク機器のｉＰＣＲへのＩｓｏデータの転送が可能になる。

なお、上記ステップＳ４８において、ｏＰＣＲのｐｃｃが［０］でない場合には、当該ｏＰＣＲに対して既にＰｔｏＰ接続の確立されたシンク機器が存在し、ＩＲＭに対して帯域取得及びチャネル登録が既に完了している。このため、この場合にはステップＳ４９，Ｓ５０を省略してステップＳ５１に移る。このとき、チャネル番号を問い合わせたシンク機器は、上記登録済みのチャネル番号を自身のｉＰＣＲに設定し、ソース機器のｏＰＣＲに対してはロックトランザクションを使用してｐｃｃの更新等を行う。この設定・更新が完了すると、図１２（ｂ）に示すようなオーバーレイＰｔｏＰ接続が確立される。また、上記ステップＳ４５において、チャネル番号を使用しているソース機器がシンク機器でサポート可能でない機器の場合には、そのシンク機器は、上記説明したステップＳ４６〜Ｓ５２の処理を終了し、別のチャネル番号を問い合わせる処理に移る。

一方、ステップＳ４２において、シンク機器が問い合わせたチャネル番号が未使用中の場合、すなわち問い合わせチャネル番号の設定されたｏＰＣＲが一つも存在しない場合には、各ソース機器からコンフィグレーションＲＯＭが読み出される（ステップＳ５３）。その読み出したコンフィグレーションＲＯＭに基づきソース機器が対応するＡＶ機器でないと判断された場合には（ステップＳ５４でＮＯ）、処理を終了する。一方、読み出したコンフィグレーションＲＯＭに基づきソース機器が対応するＡＶ機器であると判断された場合には（ステップＳ５４でＹＥＳ）、ＩＲＭに対して帯域の取得とチャネル番号の登録が行われる（ステップＳ５５，Ｓ５６）。

続いて、シンク機器は、ソース機器のｏＰＣＲ［ｎ］の中から未使用の出力プラグ（ｏＰＣＲ）を検索する。すなわち、シンク機器は、リードリクエストによってソース機器のｏＰＣＲ番号とそのｏＰＣＲのレジスタ値をｏＰＣＲ［０］から一つずつ取得する（ステップＳ５７，Ｓ５８）。そして、シンク機器は、取得したｏＰＣＲのレジスタ値に基づき未使用のｏＰＣＲであるか否かを判断する（ステップＳ５９）。シンク機器は、未使用のｏＰＣＲが見つかるまでソース機器のｏＰＣＲのレジスタ値をｏＰＣＲ［０］からｏＰＣＲ［３０］まで一つずつ読み出し（ステップＳ６０，Ｓ６１）、未使用のｏＰＣＲが見つかると（ステップＳ５９でＹＥＳ）、ステップＳ６２に移る。このステップＳ６２では、ソース機器の未使用ｏＰＣＲのフォーマット設定が行われる。続いて、シンク機器は、ロックトランザクションを使用して、未使用ｏＰＣＲ及び当該シンク機器のｉＰＣＲに対して、上記ステップＳ５６で登録したチャネル番号の設定等を行う（ステップＳ６３）。この設定が完了すると、それらソース機器のｏＰＣＲとシンク機器のｉＰＣＲとの間にＰｔｏＰ接続が確立し、ソース機器のｏＰＣＲからシンク機器のｉＰＣＲへのＩｓｏデータの転送が可能になる。

なお、上記従来技術に関連する先行技術として、特許文献１，２が開示されている。

特開２００５−３４７９５３号公報 特開２００１−０４５０３０号公報

ところで、上述したようにシンク機器が問い合わせたチャネル番号が未使用であった場合に（ステップＳ４２でＮＯ）、シンク機器は、未使用のｏＰＣＲを検索するために、リードリクエストでｏＰＣＲの番号及びレジスタ値をソース機器に問い合わせる必要がある。ここで、ソース機器はｏＰＣＲを最大３１個有しているが、上記リードリクエストでは各ｏＰＣＲに対してリクエストパケットを発行しなければならない。このため、未使用のｏＰＣＲが見つかるまでに最大３１回の問い合わせを行われなければならず、ＰｔｏＰ接続の確立までに要する時間が長く、その確立タイミングが遅くなるという問題がある。

また、シンク機器の接続数が増加した場合には、そのシンク機器の分だけｏＰＣＲの番号等を問い合わせるためのリクエストパケット数が増大する。すると、ソース機器側でそのパケット処理が追いつかなくなり、これに伴ってシンク機器側からはack_busyにより上記リクエストパケットが再送されることになる。このようなリクエストパケットの再送が繰り返されると、パケット送信回数の限度を超えて、ＰｔｏＰ接続が確立しないまま処理が終了するという問題が発生する。さらに、リクエストパケット数が増大すると、結果としてネットワーク内のパケット数が増大するため、他の機器間のデータ転送のための帯域を圧迫するという問題もある。

開示のデータ転送方法は、データを識別するためのチャネル番号を含む接続プラグの情報を、前記接続プラグの情報を複数設定可能な送信側に設定して、前記チャネル番号を特定してデータを転送するデータ転送方法であって、前記チャネル番号の問い合わせを受け、前記チャネル番号が未使用の場合に、前記問い合わせに対して、未使用の接続プラグの情報を通知する。

開示のデータ転送方法によれば、プラグコネクションを確立するために転送されるパケット数を低減することができるという効果を奏する。

ソース機器のＩＰＣの内部構成を示すブロック図。 ネットワークシステムを示すブロック図。 本実施形態のリクエストフォーマットを示す説明図。 （ａ）、（ｂ）本実施形態のレスポンスフォーマットを示す説明図。 プラグコネクションの確立方法を説明するためのフローチャート。 プラグコネクションの確立方法を説明するためのフローチャート。 変形例のプラグコネクションの確立方法を説明するためのフローチャート。 変形例のプラグコネクションの確立方法を説明するためのフローチャート。 プラグレジスタのアドレスマップを示す説明図。 ｏＰＣＲのデータフォーマットを示す説明図。 ｉＰＣＲのデータフォーマットを示す説明図。 （ａ）〜（ｃ）ＰｔｏＰ接続の接続形態を説明するための説明図。 従来のプラグコネクションの確立方法を説明するためのフローチャート。 シリアルバスブロックライトパケットのデータフォーマットを示す説明図。 ＡＶ／Ｃコマンドフレームのデータフォーマットを示す説明図。 （ａ）、（ｂ）従来のリクエストフォーマット及びレスポンスフォーマットを示す説明図。

（第１実施形態）
以下、第１実施形態を図１〜図６に従って説明する。
図２は、ＩＥＥＥ１３９４規格に準拠したシステム構成（トポロジ）を示す。ノードＡにはＩＥＥＥ１３９４バスケーブル（バスケーブル）１ａを介してノードＢが接続され、ノードＢにはバスケーブル１ｂを介してノードＣが接続されている。なお、ノードＡ〜Ｃは、例えばＤＶＤプレーヤー、デジタルテレビジョン、デジタルセットトップボックス等の接続ポイントの総称である。ここでは、ノードＡ，Ｃは、デジタルテレビジョン等のシンク機器（受信機器）であり、ノードＢは、ＤＶＤプレーヤーやデジタルセットトップボックス等のソース機器（送信機器）である。

これらノードＡ〜Ｃは、ＩＥＥＥ１３９４プロトコルコントローラ（ＩＰＣ）を備える。ここでは、ソース機器であるノードＢの備えるＩＰＣ１０の内部構成について詳しく説明する。

図１に示すように、ノードＢのＩＰＣ１０は、１３９４用インタフェース（Ｉ／Ｆ）１１，１２と、物理層処理回路１３と、リンク層処理回路１４と、アイソクロナス転送制御回路１５と、アイソクロナスデータＩ／Ｆ１６と、アシンクロナス転送制御回路１７と、アシンクロナスバッファ１８と、ＭＰＵＩ／Ｆ１９と、接続制御回路２０とを備える。

１３９４用Ｉ／Ｆ１１は上記バスケーブル１ａを介してノードＡに接続され、１３９４用Ｉ／Ｆ１２は上記バスケーブル１ｂを介してノードＣに接続されている。これら１３９４用Ｉ／Ｆ１１，１２は、他ノードから受信する電気信号を装置内部で扱う電気信号に変換して物理層処理回路１３に出力する。また、１３９４用Ｉ／Ｆ１１，１２は、物理層処理回路１３からの電気信号をＩＥＥＥ１３９４規格の電気信号に変換して他ノードに送信する。

物理層処理回路１３は、バスの状態モニタ、バスリセット発生時の初期化動作、スピードシグナリング、アービトレーションなどを行う。また、この物理層処理回路１３は、１３９４用Ｉ／Ｆ１１，１２から入力される電気信号をリンク層処理回路１４が扱う論理信号に変換してリンク層処理回路１４に出力する。一方、物理層処理回路１３は、リンク層処理回路１４から入力される論理信号を電気信号に変換して１３９４用Ｉ／Ｆ１１，１２に出力する。

リンク層処理回路１４は、物理層処理回路１３から入力される論理信号（パケットデータ）のヘッダ部に基づいて、自身宛のパケットであるかを判断する。リンク層処理回路１４は、受信したパケットデータが自身宛であるときには、そのパケットデータがアイソクロナス（Ｉｓｏ）パケットかアシンクロナス（Ａｓｙｎ）パケットかを、該パケットのヘッダ部の内容から判断する。そして、リンク層処理回路１４は、受信したパケットがＩｓｏパケットの場合には、そのＩｓｏパケットをＩｓｏ転送制御回路１５に供給する。また、リンク層処理回路１４は、受信したパケットがＡｓｙｎパケットの場合には、そのＡｓｙｎパケットをＡｓｙｎ転送制御回路１７に供給する。

一方、リンク層処理回路１４は、Ｉｓｏ転送制御回路１５及びＡｓｙｎ転送制御回路１７から入力されるデータに基づいて、ＩＥＥＥ１３９４規格に準拠した標準パケットを生成して物理層処理回路１３に出力する。

Ｉｓｏ転送制御回路１５は、リンク層処理回路１４から入力されるＩｓｏパケットのヘッダ部とデータ部とを分離し、それらヘッダ部及びデータ部に対して誤り訂正処理を行う。そして、Ｉｓｏ転送制御回路１５は、誤り訂正処理後のデータをＩｓｏデータＩ／Ｆ１６に供給する。一方、Ｉｓｏ転送制御回路１５は、ＩｓｏデータＩ／Ｆ１６から入力されるデータに基づいて、Ｉｓｏパケットフォーマットを生成してリンク層処理回路１４に供給する。

Ａｓｙｎ転送制御回路１７は、リンク層処理回路１４から入力されるＡｓｙｎパケットのヘッダ部とデータ部とを分離し、それらヘッダ部及びデータ部に対して誤り訂正処理を行う。そして、Ａｓｙｎ転送制御回路１７は、誤り訂正処理後のデータをＡｓｙｎバッファ１８に出力する。一方、Ａｓｙｎ転送制御回路１７は、Ａｓｙｎバッファ１８から入力されるデータに基づいて、Ａｓｙｎパケットを生成してリンク層処理回路１４に供給する。

Ａｓｙｎバッファ１８は、Ａｓｙｎ転送制御回路１７から入力されるＡｓｙｎパケットをＭＰＵＩ／Ｆ１９に出力する。一方、Ａｓｙｎバッファ１８は、ＭＰＵＩ／Ｆ１９から入力されるデータをＡｓｙｎ転送制御回路１７に出力する。なお、このＭＰＵＩ／Ｆ１９は、図示しないマイクロプロセッサユニット（ＭＰＵ）とＡｓｙｎバッファ１８との間においてデータの送受信等を行う。

また、Ａｓｙｎバッファ１８は、Ａｓｙｎ転送制御回路１７から入力されるＡｓｙｎパケットを接続制御回路２０に出力する。この接続制御回路２０は、受信したＡｓｙｎパケットが図３に示すchannel usageステータスコマンドのリクエストフォーマットのデータを含む場合には、図４に示すchannel usageステータスコマンドのレスポンスフォーマットのデータを生成する。

ここで、本実施形態では、channel usageステータスコマンドのリクエストフォーマットを従来のフォーマット（図１６（ａ）参照）から図３に示すフォーマットに変更している。また、channel usageステータスコマンドのレスポンスフォーマットを従来のフォーマット（図１６（ｂ）参照）から図４（ａ）、（ｂ）に示すフォーマットに変更している。以下に、それぞれの変更後のフォーマットについて説明する。

図３及び図４に示すように、channel usageステータスコマンドのリクエストフォーマット及びレスポンスフォーマットは、オペコードに［１２ｈ］が格納され、オペランド０〜８には当該コマンドが必要とする情報が格納される。具体的には、オペランド０にはチャネル番号、オペランド１，２にはノードＩＤ、オペランド３にはｏＰＣＲ番号が格納される。また、オペランド４には未使用のｏＰＣＲ番号、オペランド５〜８にはｏＰＣＲの値が格納される。すなわち、変更後のリクエストフォーマット及びレスポンスフォーマットでは、従来のフォーマット（図１６参照）に対してオペランド４〜８が追加されている。そこで、その追加されたオペランド４〜８に格納される情報についてさらに詳述する。

図３に示すリクエストフォーマットでは、オペランド４には［ＦＦｈ］が格納され、オペランド５〜８には［ＦＦＦＦＦＦＦＦｈ］が格納される。なお、このリクエストフォーマットにおけるオペランド４〜８は、レスポンスフォーマットと整合をとるために追加されたものであり、未使用のｏＰＣＲ番号やｏＰＣＲの値を問い合わせる情報として機能する。

また、図４に示すレスポンスフォーマットでは、さらにシンク機器から問い合わせされたチャネル番号が設定されたｏＰＣＲが存在するか否かによって、オペランド４〜８に格納される情報が異なる。すなわち、問い合わせされたチャネル番号が当該ソース機器の全てのｏＰＣＲ［ｎ］に未設定の場合のレスポンスフォーマットでは、図４（ａ）に示すように、オペランド４にはｏＰＣＲ［ｎ］のうち未使用のｏＰＣＲの番号（ここでは［０１ｈ］）が格納される。また、オペランド５〜８には上記未使用ｏＰＣＲ［１］の値（現在値）、具体的には未使用ｏＰＣＲ［１］のレジスタ値（図１０参照）が格納される。この未使用のｏＰＣＲのレジスタ値は、通常［００００００００ｈ］となる。なお、これら未使用のｏＰＣＲの番号及びレジスタ値は、未使用の接続プラグの情報に含まれる。

一方、問い合わせされたチャネル番号の設定された設定済みｏＰＣＲが存在する場合のレスポンスフォーマットでは、図４（ｂ）に示すように、オペランド４には［ＦＦｈ］が格納される。また、オペランド５〜８には上記設定済みｏＰＣＲの値（現在値）、具体的には設定済みｏＰＣＲのレジスタ値（ここでは［８１１０００００ｈ］）が格納される。なお、この場合のオペランド４に格納される［ＦＦｈ］は、ｏＰＣＲ番号の上限よりも大きい値であれば特に制限されない。

次に、上記接続制御回路２０の内部構成を説明する。
図１に示すように、接続制御回路２０は、ラッチ回路２１と、第１比較回路２２と、ＦＩＦＯ（First In First Out）２３と、バッファ２４と、レジスタ部２５と、第２及び第３比較回路２６，２７と、マルチプレクサ２８と、記憶部２９とを備える。

ラッチ回路２１は、上記Ａｓｙｎバッファ１８から入力されるＡｓｙｎパケットから、リクエストフォーマット内のオペコードと、シンク機器から問い合わせされたチャネル番号と、送信元のノードＩＤと、リクエストフォーマットの長さを記憶する。

第１比較回路２２は、ラッチ回路２１からオペコードとリクエストフォーマットの長さとを読み出し、オペコードが［１２ｈ］と一致するかを判断し、更にリクエストフォーマットの長さが図３又は図１６（ａ）に示すリクエストフォーマットの長さに一致するかを判断する。双方が一致した場合に、第１比較回路２２は、ラッチ回路２１から読み出したオペコードと、チャネル番号と、送信元のノードＩＤと、リクエストフォーマットの長さとをＦＩＦＯ２３に格納するとともに、上記チャネル番号をバッファ２４に格納する。なお、ＦＩＦＯ２３は、複数のシンク機器からリクエストパケットが転送された場合にも対応可能なように、ＦＩＦＯ配列の数は多いことが好ましい。また、ＦＩＦＯ２３に格納されたデータは、バスリセット発生時にクリアされる。

レジスタ部２５は、当該ノードＢの備えるｏＰＣＲ［０］〜ｏＰＣＲ［３０］の各レジスタ値を格納する。
第２比較回路２６は、各ｏＰＣＲのレジスタ値に含まれるチャネル番号とバッファ２４に格納されたチャネル番号、すなわちシンク機器から問い合わせされたチャネル番号とを比較する。このとき、両チャネル番号が一致した場合には、そのｏＰＣＲに所望のチャネル番号が設定されていることになる、すなわち上記チャネル番号の一致したｏＰＣＲが設定済みｏＰＣＲになる。そこで、第２比較回路２６は、その設定済みｏＰＣＲの番号及びレジスタ値を第１出力信号Ｄ１としてマルチプレクサ２８に出力する。

第３比較回路２７は、ｏＰＣＲの初期値と各ｏＰＣＲのレジスタ値（現在値）とを比較する。ここで、ｏＰＣＲのレジスタ値が初期値と一致すれば、そのｏＰＣＲが未使用ｏＰＣＲであると判断することができる。そこで、第３比較回路２７は、その未使用ｏＰＣＲの番号及びレジスタ値を第２出力信号Ｄ２としてマルチプレクサ２８に出力する。なお、これら第２及び第３比較回路２６，２７は、例えばｏＰＣＲ［ｎ］の番号昇順で上記比較動作を行う。

マルチプレクサ２８は、第２及び第３比較回路２６，２７の第１及び第２出力信号Ｄ１，Ｄ２のうちの一方を第３出力信号Ｄ３として記憶部２９に出力する。具体的には、マルチプレクサ２８は、第２比較回路２６から第１出力信号Ｄ１が入力されている場合には、その第１出力信号Ｄ１（設定済みｏＰＣＲの番号及びレジスタ値）を記憶部２９に出力する。また、マルチプレクサ２８は、第２比較回路２６から第１出力信号Ｄ１が入力されていない場合には、第３比較回路２７から入力される第２出力信号Ｄ２（未使用ｏＰＣＲの番号及びレジスタ値）を記憶部２９に出力する。

記憶部２９は、マルチプレクサ２８から入力される第３出力信号Ｄ３、ＦＩＦＯ２３から入力されるデータ及び番号取得フラグを記憶する。すなわち、記憶部２９は、チャネル番号と、そのチャネル番号が設定されたｏＰＣＲ番号又は未使用ｏＰＣＲ番号と、そのｏＰＣＲのレジスタ値と、リクエストフォーマットの長さと、番号取得フラグとを処理結果として記憶する。ここで、番号取得フラグは、未使用ｏＰＣＲを処理結果として格納する場合に、問い合わせたシンク機器とは別のシンク機器に当該未使用ｏＰＣＲを使用されないように予約するためのものである。このため、上記第３比較回路２７では、上記比較動作時に、比較対象のｏＰＣＲ［ｎ］に番号取得フラグが設定されているかが判断され、番号取得フラグが設定されている場合にはそのｏＰＣＲが未使用ｏＰＣＲと判断されない。

この記憶部２９では、上記処理結果がリクエストフォーマットの長さに応じたレスポンスフォーマットと同様に整形されて記憶される。すなわち、リクエストフォーマットの長さが図３に示すフォーマットの長さと一致する場合には、上記処理結果のうちのチャネル番号、ｏＰＣＲ番号、ｏＰＣＲのレジスタ値が図４に示したレスポンスフォーマットのオペランド０〜８と同様に整形されて記憶される。また、リクエストフォーマットの長さが図１６（ａ）に示すフォーマットの長さと一致する場合には、上記処理結果のうちのチャネル番号及びｏＰＣＲ番号が図１６（ｂ）に示すレスポンスフォーマットのオペランド０〜４と同様に整形されて記憶される。なお、この記憶部２９は、複数のシンク機器からの問い合わせに応じてそれぞれの処理結果を記憶できるようにノード台数制限の６３台分の処理結果を記憶できる記憶容量を有し、例えばノード番号順に処理結果を記憶する。また、記憶部２９に格納されたデータは、バスリセット発生時にクリアされる。

そして、この記憶部２９に記憶された処理結果（レスポンスフォーマットと同様に整形されたデータ）がＦＣＰフレームにカプセル化されてライトパケットが生成され、そのライトパケットがシンク機器に返送される。なお、記憶部２９に記憶された処理結果がＭＰＵＩ／Ｆ１９に読み出されると、ＭＰＵ、ＭＰＵＩ／Ｆ１９、Ａｓｙｎバッファ１８、Ａｓｙｎ転送制御回路１７及びリンク層処理回路１４等によって、上記処理結果からライトパケットが生成される。すなわち、これら記憶部２９、ＭＰＵ、ＭＰＵＩ／Ｆ１９、Ａｓｙｎバッファ１８、Ａｓｙｎ転送制御回路１７及びリンク層処理回路１４は、上記処理結果をシンク機器に通知する通知手段として機能する。

次に、このように構成されたノードＢとノードＡ間でプラグコネクションを確立するための処理手順を図５及び図６に従って説明する。
今、各機器の電源投入などによってバスリセットが発生される。すると、そのバスリセット後に、シンク機器であるノードＡは、接続したいチャネル番号［１０ｈ］の使用状態を、channel usageステータスコマンドによって全てのソース機器（ここでは、ノードＢ）に問い合わせる（ステップＳ１）。具体的には、ノードＡは、図３に示すリクエストフォーマットのデータがカプセル化されたライトパケットをノードＢに送信する。そのライトパケットを受信したノードＢは、図４に示すレスポンスフォーマットのデータがカプセル化されたライトパケットを生成し、そのライトパケットをノードＡに送信する。ここで、ノードＢにおけるライトパケットの生成方法について図６に従って説明する。

ノードＢは、他ノードからのＡｓｙｎパケット（ここでは、ライトパケット）を読み込むと（ステップＳ２０）、リンク層処理回路１４やアシンクロナス転送制御回路１７において、上記Ａｓｙｎパケットを分離・解析する（ステップＳ２１）。この分離・解析されたＡｓｙｎパケットは、Ａｓｙｎバッファ１８を介して接続制御回路２０内のラッチ回路２１に格納される。すると、第１比較回路２２において、Ａｓｙｎパケット内のＡＶ／Ｃコマンドフレームのオペコードが［１２ｈ］であるか否かが判断される（ステップＳ２２）。ここでは、図３に示すchannel usageステータスコマンドのリクエストフォーマットを含むライトパケットを受信しているため、そのライトパケットのＡＶ／Ｃコマンドフレームのオペコードは［１２ｈ］である。このため、受信したＡｓｙｎパケットがchannel usageステータスコマンドのパケットであると判断される（ステップ２２でＹＥＳ）。

続いて、第１比較回路２２において、上記channel usageステータスコマンドのリクエストフォーマットの長さが図３に示すリクエストフォーマット（第１リクエストフォーマット）の長さ「１０」又は図１６（ａ）に示すリクエストフォーマット（第２リクエストフォーマット）の長さ「５」であるかが判断される（ステップＳ２３）。本例では、図３に示すリクエストフォーマットであるため、そのリクエストフォーマットのオペランド０に格納されたチャネル番号が取得される（ステップＳ２４）。なお、リクエストフォーマットの長さが「５」である場合でも、同様にオペランド０に格納されたチャネル番号が取得される。すなわち、受信したＡｓｙｎパケットに図３又は図１６（ａ）のリクエストフォーマットが含まれる場合に、そのオペランド０に格納されたチャネル番号、つまりノードＡが使用状態を問い合わせたチャネル番号が取得される。なお、リクエストフォーマットの長さが「５」、「１０」でない場合、及び上記ステップＳ２２でオペコードが［１２ｈ］でない場合には、処理を終了する。

続いて、上記取得されたチャネル番号の設定された設定済みｏＰＣＲが存在するか否かが検索される。まず、レジスタ部２５に格納されたｏＰＣＲ［ｎ］のレジスタ値、具体的には、はじめにｏＰＣＲ［０］のレジスタ値が読み出される（ステップＳ２５，Ｓ２６）。この読み出されたｏＰＣＲ［ｎ］のレジスタ値に含まれるチャネル番号と上記取得されたチャネル番号とが一致するか否かが第２比較回路２６で判断される（ステップＳ２７）。このとき、両チャネル番号が一致せずに（ステップＳ２７でＮＯ）、且つ上記リクエストフォーマットの長さが「１０」である場合には（ステップＳ２８でＹＥＳ）、さらに以下の未使用ｏＰＣＲの検索処理が行われる。本例では、リクエストフォーマットの長さが「１０」であるため、以下の未使用ｏＰＣＲの検索処理が行われる。

すなわち、上記読み出されたｏＰＣＲ［ｎ］のレジスタ値とｏＰＣＲの初期値が一致するかを比較することで、ｏＰＣＲ［ｎ］が未使用ｏＰＣＲであるか否かが第３比較回路２７で判断される（ステップＳ２９）。このとき、レジスタ値と初期値とが一致して上記ｏＰＣＲ［ｎ］が未使用と判断された場合には（ステップＳ２９でＹＥＳ）、そのｏＰＣＲ［ｎ］に番号取得フラグが設定されているか否かが第３比較回路２７で判断される（ステップＳ３０）。ここで、ｏＰＣＲ［ｎ］に番号取得フラグが設定されていない場合には（ステップＳ３０でＮＯ）、そのｏＰＣＲ［ｎ］に番号取得フラグを設定し（ステップＳ３１）、そのｏＰＣＲ番号について使用の予約をして（ステップＳ３２）、ステップＳ３３に移る。

なお、リクエストフォーマットの長さが「５」（図１６（ａ）に示す従来のリクエストフォーマットの長さ）の場合には（ステップＳ２８でＮＯ）、直ちにステップＳ３３に移る。すなわち、従来のリクエストフォーマットの場合には、未使用ｏＰＣＲの検索処理が行われない。また、ｏＰＣＲ［ｎ］が未使用ｏＰＣＲでない場合（ステップＳ２９でＮＯ）、及びｏＰＣＲ［ｎ］が未使用ｏＰＣＲであるが番号取得フラグが設定されている場合には、そのｏＰＣＲ［ｎ］を使用できないため、ステップＳ３３に移る。

その後、設定済みｏＰＣＲが見つかるまで、あるいは設定済みｏＰＣＲが無く、未使用ｏＰＣＲが見つかるまで、ｏＰＣＲ［１］からｏＰＣＲ［３０］のレジスタ値が番号昇順で読み出される（ステップＳ３３，Ｓ３４及びステップＳ２６）。そして、ステップＳ２６において、設定済みｏＰＣＲ（例えばｏＰＣＲ［６］）が見つかった場合には、ステップＳ３５に移る。このステップＳ３５では、まずリクエストフォーマットの長さが判断され、本例のように「１０」である場合には、チャネル番号、自ノードのノードＩＤ、設定済みｏＰＣＲの番号及びレジスタ値が図４（ｂ）に示すレスポンスフォーマットのオペランド０〜８と同様に整形される。なお、この場合には、上記設定済みｏＰＣＲ［６］が見つかるまでの未使用ｏＰＣＲの検索処理において設定された番号取得フラグの設定は解除される。また、リクエストフォーマットの長さが「５」である場合には、チャネル番号、自ノードのノードＩＤ及び設定済みｏＰＣＲ番号が図１６（ｂ）に示すレスポンスフォーマットのオペランド０〜３と同様に整形される。これにより、従来のリクエストフォーマットに対してもそのフォーマットに応じたデータを整形することができる。

一方、問い合わせされたチャネル番号が全てのｏＰＣＲ［０］〜ｏＰＣＲ［３０］に設定されていない場合には（ステップＳ３３でＹＥＳ）、ステップＳ３１で番号取得フラグの設定された所定のｏＰＣＲ（例えば最初に番号取得フラグの設定されたｏＰＣＲ）が未使用ｏＰＣＲとして設定される。そして、ステップＳ３５において、チャネル番号、未使用ｏＰＣＲの番号及びレジスタ値が図４（ａ）に示すレスポンスフォーマットのオペランド０〜８と同様に整形される。なお、この場合には、未使用ｏＰＣＲとして設定されなかったｏＰＣＲに対して設定された番号取得フラグの設定は解除される。また、リクエストフォーマットの長さが「５」の場合には、未使用ｏＰＣＲの検索処理が行われないため、従来と同様に、図１６（ｂ）に示すレスポンスフォーマットにおけるオペランド０〜３には「ＦＦＦＦＦＦｈ」が格納される。

続いて、上述のようにフォーマット整形された処理結果が記憶部２９に格納され、さらにフォーマット整形された処理結果（レスポンスフォーマット）を含むライトパケットが生成される（ステップＳ３６）。すなわち、本例では、問い合わせされたチャネル番号の設定された設定済みｏＰＣＲが存在する場合には、その設定済みｏＰＣＲの番号及びレジスタ値の格納されたレスポンスフォーマット（図４（ｂ）参照）を含むライトパケットが生成される。また、設定済みｏＰＣＲが存在しない場合には、未使用ｏＰＣＲの番号及びレジスタ値の格納されたレスポンスフォーマット（図４（ａ）参照）を含むライトパケットが生成される。なお、リクエストフォーマットの長さが「５」の場合には、従来のレスポンスフォーマット（図１６（ｂ）参照）を含むライトパケットが生成される。これにより、既存のリクエストフォーマットに対してもそのフォーマットに応じたレスポンスフォーマットを作成することができる。

そして、ノードＢは、その生成したライトパケットを、チャネル番号の使用状態を問い合わせたノードＡに送信する。
図５に示すステップＳ２において、上記レスポンスフォーマットを含むライトパケットをノードＡが受信すると、そのノードＡはレスポンスフォーマットの内容に基づいて問い合わせたチャネル番号が使用中であるか否かを判断する。

例えば図４（ｂ）に示すレスポンスフォーマットがライトパケットに含まれる場合には、問い合わせたチャネル番号が使用中であると判断され、ステップＳ３に移る。このステップＳ３〜Ｓ６は、先の図１３で説明したステップＳ４３〜Ｓ４６と同様の処理である。ここで、従来の処理手順では、上記ソース機器から受信されるレスポンスフォーマットには設定済みｏＰＣＲの番号のみしか格納されていないため、上記ステップＳ４６の後にリードリクエストを利用して設定済みｏＰＣＲのレジスタ値を取得する必要があった。これに対し、図４（ｂ）に示すレスポンスフォーマットでは、設定済みｏＰＣＲの番号及びレジスタ値が格納されている。このため、本実施形態の処理手順では、リードリクエストによる設定済みｏＰＣＲのレジスタ値の読み出し（図１３のステップＳ４７）を行う必要がない。従って、本例のノードＡは、上記ステップＳ６に続いて、図４（ｂ）に示すレスポンスフォーマット内の設定済みｏＰＣＲの番号及びレジスタ値に基づいて、ステップＳ８〜Ｓ１２の処理（ステップＳ４８〜Ｓ５２と同様の処理）を行ってＰｔｏＰ接続を確立する。

一方、ノードＢから受信されるライトパケットに図４（ａ）に示すレスポンスフォーマットが含まれる場合には、問い合わせたチャネル番号が未使用であると判断し（ステップＳ２でＮＯ）、ステップＳ１３に移る。このステップＳ１３〜Ｓ１６は、先の図１３で説明したステップＳ５３〜Ｓ５６と同様の処理である。ここで、従来の処理手順では、未使用ｏＰＣＲを検索するためにリードリクエストを利用してシンク機器がソース機器のｏＰＣＲ［ｎ］のレジスタ値を一つずつ読み出す必要があった。これに対し、図４（ａ）に示すレスポンスフォーマットでは、未使用ｏＰＣＲの番号及びレジスタ値が格納されている。このため、本実施形態の処理手順では、リードリクエストによるｏＰＣＲの番号及びレジスタ値の読み出し（図１３のステップＳ５７〜Ｓ６１）を行う必要がない。従って、本例のノードＡは、上記ステップＳ１６に続いて、図４（ａ）に示すレスポンスフォーマット内の未使用ｏＰＣＲの番号及びレジスタ値に基づいて、ステップＳ１８，Ｓ１９（ステップＳ６２，Ｓ６３と同様の処理）を行ってＰｔｏＰ接続を確立する。なお、この図４（ａ）に示すレスポンスフォーマットでは、ノードＢ（ソース機器）のノードＩＤを取得できない。このため、この場合にはライトパケット内のsource_IDからノードＢのノードＩＤを取得する。

以上説明したように、本実施形態によれば、以下の効果を奏することができる。
（１）channel usageステータスコマンドのレスポンスフォーマットに、未使用ｏＰＣＲの番号が格納されるオペランド４を追加し、このレスポンスフォーマットを含むライトパケットをシンク機器に送信するようにした。これにより、ソース機器とシンク機器とで未使用ｏＰＣＲの番号を速やかに共有できるため、その未使用のｏＰＣＲを検索するためのリクエストパケット数を減らすことができる。従って、シンク機器とソース機器との間でのパケットの送受信が減少するため、ソース機器におけるパケット処理にかかる負荷を小さくすることができる。この結果、プラグコネクションが確立しないまま処理が終了するという不具合の発生を好適に抑制することができる。また、リクエストパケット数が減少すると、結果としてネットワーク内のパケット数が減少するため、他の機器間によるデータ転送のための帯域を十分に確保することができる。これにより、他のシンク機器とソース機器とのデータ転送のリアルタイム性を担保することができる。この効果は、ネットワークに接続するノード数が増大するほど顕著なものとなる。

さらに、シンク機器では、上記レスポンスフォーマットから取得した未使用のｏＰＣＲ番号に基づいて、そのｏＰＣＲに対してチャネル番号の設定等を速やかに行うことができるため、プラグコネクションの確立を迅速に行うことができる。

（２）channel usageステータスコマンドのレスポンスフォーマットに、未使用ｏＰＣＲのレジスタ値が格納されるオペランド５〜８を追加するようにした。これにより、問い合わせたチャネル番号が未使用であった場合に、リードリクエストを用いた未使用のｏＰＣＲの番号とレジスタ値の検索処理（図１３のステップＳ５７〜Ｓ６１）を行うことなく、プラグコネクションを確立することができる。このため、プラグコネクションを確立するために転送されるパケット数（とくに、リクエストパケット数）を更に減少させることができる。

（３）channel usageステータスコマンドのレスポンスフォーマットに、設定済みｏＰＣＲのレジスタ値が格納されるオペランド５〜８を追加するようにした。これにより、問い合わせたチャネル番号が使用中であった場合に、リードリクエストを用いた設定済みｏＰＣＲのレジスタ値の読み出し（図１３のステップＳ４７）を行うことなく、プラグコネクションを確立することができる。このため、問い合わせたチャネル番号が使用中の場合であっても、プラグコネクションを確立するために転送されるパケット数を減少させることができる。

（４）レスポンスフォーマットの変更に伴ってリクエストフォーマットにもオペランド４〜８を追加し、そのリクエストフォーマットの長さから従来のリクエストフォーマット（図１６（ａ）参照）であるか図３に示すリクエストフォーマットであるかを判定するようにした。そして、従来のリクエストフォーマットである場合には、未使用ｏＰＣＲの検索処理を行わずに、従来のレスポンスフォーマット（図１６（ｂ）参照）を含むライトパケットをシンク機器に送信するようにした。これにより、図３に示すリクエストフォーマットを生成することのできない既存のシンク機器とネットワークを構築しても、従前通りのプラグコネクションの確立処理を支障なく行うことができる。

（５）設定済みｏＰＣＲの検索処理や未使用ｏＰＣＲの検索処理をハードウェアである接続制御回路２０で実行するようにした。従って、パケット処理にかかるＭＰＵ等の負荷を軽減できるとともに、上記両処理のためのプログラムをプログラム領域に格納する必要がない。

なお、上記実施形態は、これを適宜変更した以下の態様にて実施することもできる。
・上記実施形態におけるノードＢ（ソース機器）では、設定済みｏＰＣＲの検索処理及び未使用ｏＰＣＲの検索処理等の処理（図６に示した処理）を接続制御回路２０、すなわちハードウェアにて行うようにした。これに限らず、これらの処理（図６に示した処理）の一部又は全部をソフトウェアにて実行するようにしてもよい。

・図５のステップＳ２において、チャネル番号が使用中であると判断された後の処理（ステップＳ３〜Ｓ１２）を、図７に示される処理に変更してもよい。すなわち、ステップＳ６の後に、ソース機器から受信したライトパケット内のレスポンスフォーマットの長さが「１０」（図４に示すフォーマットの長さ）であるかを判断する処理（ステップＳ７）を追加するようにしてもよい。このステップＳ７において、レスポンスフォーマットの長さが「１０」である場合には、図５の処理手順と同様に、直ちにステップＳ８に移る。一方、ステップＳ７において、レスポンスフォーマットの長さが「１０」でない場合、すなわち「５」（図１６（ｂ）に示すフォーマットの長さ）である場合には、従来の処理手順と同様に、リードリクエストによってｏＰＣＲのレジスタ値を取得（ステップＳ４７）してから、ステップＳ８に移る。これにより、シンク機器は、従来のレスポンスフォーマットを受信した場合であっても、従前通りのプラグコネクションの確立処理を支障なく行うことができる。

・図５のステップＳ２において、チャネル番号が未使用であると判断された後の処理（ステップＳ１３〜Ｓ１９）を、図８に示される処理に変更してもよい。すなわち、ステップＳ１６の後に、ソース機器から受信したライトパケット内のレスポンスフォーマットの長さが「１０」（図４に示すフォーマットの長さ）であるかを判断する処理（ステップＳ１７）を追加するようにしてもよい。このステップＳ１７において、レスポンスフォーマットの長さが「１０」である場合には、図５の処理手順と同様に、直ちにステップＳ１８に移る。一方、ステップＳ１７において、レスポンスフォーマットの長さが「１０」でない場合、すなわち「５」（図１６（ｂ）に示すフォーマットの長さ）である場合には、従来の処理手順と同様に、リードリクエストによって未使用のｏＰＣＲを検索する処理（ステップＳ５７〜Ｓ６１）を行ってから、ステップＳ１８に移る。これにより、シンク機器は、従来のレスポンスフォーマットを受信した場合であっても、従前通りのプラグコネクションの確立処理を支障なく行うことができる。

・上記実施形態において、設定済みｏＰＣＲが存在する場合には、図４（ｂ）のレスポンスフォーマットではなく、図１６（ｂ）に示す従来のレスポンスフォーマットを含むライトパケットを生成するようにしてもよい。すなわち、問い合わせたチャネル番号が未使用の場合にのみ、レスポンスフォーマットを図４（ａ）のレスポンスフォーマットに変更するようにしてもよい。この場合にも、上記実施形態の（１）、（２）、（４）、（５）と同様の効果を奏することができる。

・上記実施形態における図４のレスポンスフォーマットからオペランド５〜８を省略してもよい。すなわち、図１６（ｂ）に示す従来のフォーマットに対して、未使用ｏＰＣＲの番号が格納されるオペランド４のみを追加するようにしてもよい。この場合には、図５のステップＳ１６の後に、リードリクエストによって未使用ｏＰＣＲのレジスタ値を読み出す必要が生じる場合もあるが、そのｏＰＣＲの番号はレスポンスフォーマットから取得されるため、リクエストパケットは多くても１個で済む。このため、このような構成であっても、最大３１個のリクエストパケットが必要であった従来よりも、大幅にリクエストパケット数を減少させることができる。

・上記実施形態では、設定済みｏＰＣＲの検索処理と未使用ｏＰＣＲの検索処理とを並行して実行しているが、例えば設定済みｏＰＣＲの検索処理によって設定済みｏＰＣＲが存在しないと判断されてから未使用ｏＰＣＲの検索処理を開始するようにしてもよい。

・上記実施形態におけるステップＳ２８（図６参照）の処理を省略してもよい。
・上記実施形態におけるステップＳ３０〜Ｓ３２（図６参照）の処理を省略してもよい。

・上記実施形態におけるネットワーク内のノード数に特に制限はない。
・上記実施形態では、ノードＡ〜ＣはＩＥＥＥ１３９４規格に準拠した装置に具体化したが、これに限らず、例えばＩＤＢ−１３９４規格に準拠した装置に具体化してもよい。

以上の様々な実施の形態をまとめると、以下のようになる。
（付記１）
データを識別するためのチャネル番号を含む接続プラグの情報を、前記接続プラグの情報を複数設定可能な送信側に設定して、前記チャネル番号を特定してデータを転送するデータ転送方法であって、
前記チャネル番号の問い合わせを受け、
前記チャネル番号が未使用の場合に、前記問い合わせに対して、未使用の接続プラグの情報を通知する
ことを特徴とするデータ転送方法。
（付記２）
前記未使用の接続プラグの情報は、前記未使用の接続プラグに対応するプラグコントロールレジスタの番号であることを特徴とする付記１に記載のデータ転送方法。
（付記３）
前記未使用の接続プラグの情報は、前記未使用の接続プラグに対応するプラグコントロールレジスタの番号と現在値であることを特徴とする付記１又は２に記載のデータ転送方法。
（付記４）
前記チャネル番号が使用中の場合に、前記問い合わせに対して、前記チャネル番号が設定されている接続プラグに対応するプラグコントロールレジスタの番号と現在値を通知することを特徴とする付記１〜３のいずれか１つに記載のデータ転送方法。
（付記５）
前記送信側において、該送信側の各出力プラグコントロールレジスタの現在値とその初期値とを比較して、前記未使用の接続プラグを検索する検索処理を含む
ことを特徴とする付記１〜４のいずれか１つに記載のデータ転送方法。
（付記６）
前記チャネル番号を問い合わせるために定義された接続コマンドの既存の第１リクエストフォーマットによって前記チャネル番号の問い合わせを受けた場合には、前記検索処理を行わず、
前記第１リクエストフォーマットに前記未使用の接続プラグの情報を問い合わせる情報が追加された第２リクエストフォーマットによって前記チャネル番号の問い合わせを受けた場合に、前記検索処理を行うことを特徴とする付記５に記載のデータ転送方法。
（付記７）
前記通知した前記未使用の接続プラグの情報にフラグを設定し、
前記検索処理において、前記検索された前記未使用の接続プラグの情報に前記フラグが設定されているか否かを判定する処理を更に行う
ことを特徴とする付記５又は６に記載のデータ転送方法。
（付記８）
前記未使用の接続プラグの情報を、前記チャネル番号を問い合わせるために定義された接続コマンドのレスポンスフォーマットに格納して通知することを特徴とする付記１〜７のいずれか１つに記載のデータ転送方法。
（付記９）
データを識別するためのチャネル番号を含む接続プラグの情報を設定して、前記チャネル番号を特定してデータを転送するデータ転送装置であって、
当該データ転送装置の有する複数の接続プラグのうちの未使用の接続プラグを検索する検索手段と、
使用状態の問い合わせを受けたチャネル番号が未使用の場合に、前記問い合わせに対して、前記検索手段にて検索された前記未使用の接続プラグの情報を通知する通知手段と
を含むことを特徴とするデータ転送装置。
（付記１０）
前記未使用の接続プラグの情報は、前記未使用の接続プラグに対応するプラグコントロールレジスタの番号であることを特徴とする付記９に記載のデータ転送装置。
（付記１１）
前記未使用の接続プラグの情報は、前記未使用の接続プラグに対応するプラグコントロールレジスタの番号と現在値であることを特徴とする付記９又は１０に記載のデータ転送装置。
（付記１２）
前記通知手段は、前記問い合わせを受けたチャネル番号が使用中の場合に、前記問い合わせに対して、前記チャネル番号が設定されている接続プラグに対応するプラグコントロールレジスタの番号と現在値を通知することを特徴とする付記９〜１１のいずれか１つに記載のデータ転送装置。
（付記１３）
前記検索手段は、当該データ転送装置の有する出力プラグコントロールレジスタの現在値とその初期値とを比較する第１比較手段を含むことを特徴とする付記９〜１２のいずれか１つに記載のデータ転送装置。
（付記１４）
前記問い合わせを受けたチャネル番号と当該データ転送装置の有する出力プラグコントロールレジスタの現在値内のチャネル番号とを比較して、前記問い合わせを受けたチャネル番号が使用中であるか否かを判定する第２比較手段を含むことを特徴とする付記９〜１３のいずれか１つに記載のデータ転送装置。

Ｂ ノード（データ転送装置）
１０ ＩＰＣ
１４ リンク層処理回路
１７ アシンクロナス転送制御回路
１８ アシンクロナスバッファ
１９ ＭＰＵＩ／Ｆ
２０ 接続制御回路
２２ 第１比較回路
２５ レジスタ部
２６ 第２比較回路（検索手段、第１比較手段）
２７ 第３比較回路（第２比較手段）
２８ マルチプレクサ
２９ 記憶部

Claims (10)

1. データを識別するためのチャネル番号を含む接続プラグの情報を、前記接続プラグの情報を複数設定可能な送信側に設定して、前記チャネル番号を特定してデータを転送するデータ転送方法であって、
   前記チャネル番号の問い合わせを受け、
   前記チャネル番号が未使用の場合に、前記問い合わせに対して、未使用の接続プラグの情報を通知する
   ことを特徴とするデータ転送方法。
2. 前記未使用の接続プラグの情報は、前記未使用の接続プラグに対応するプラグコントロールレジスタの番号であることを特徴とする請求項１に記載のデータ転送方法。
3. 前記未使用の接続プラグの情報は、前記未使用の接続プラグに対応するプラグコントロールレジスタの番号と現在値であることを特徴とする請求項１又は２に記載のデータ転送方法。
4. 前記チャネル番号が使用中の場合に、前記問い合わせに対して、前記チャネル番号が設定されている接続プラグに対応するプラグコントロールレジスタの番号と現在値を通知することを特徴とする請求項１〜３のいずれか１つに記載のデータ転送方法。
5. 前記送信側において、該送信側の各出力プラグコントロールレジスタの現在値とその初期値とを比較して、前記未使用の接続プラグを検索する検索処理を含む
   ことを特徴とする請求項１〜４のいずれか１つに記載のデータ転送方法。
6. 前記チャネル番号を問い合わせるために定義された接続コマンドの既存の第１リクエストフォーマットによって前記チャネル番号の問い合わせを受けた場合には、前記検索処理を行わず、
   前記第１リクエストフォーマットに前記未使用の接続プラグの情報を問い合わせる情報が追加された第２リクエストフォーマットによって前記チャネル番号の問い合わせを受けた場合に、前記検索処理を行うことを特徴とする請求項５に記載のデータ転送方法。
7. 前記通知した前記未使用の接続プラグの情報にフラグを設定し、
   前記検索処理において、前記検索された前記未使用の接続プラグの情報に前記フラグが設定されているか否かを判定する処理を更に行う
   ことを特徴とする請求項５又は６に記載のデータ転送方法。
8. データを識別するためのチャネル番号を含む接続プラグの情報を設定して、前記チャネル番号を特定してデータを転送するデータ転送装置であって、
   当該データ転送装置の有する複数の接続プラグのうちの未使用の接続プラグを検索する検索手段と、
   使用状態の問い合わせを受けたチャネル番号が未使用の場合に、前記問い合わせに対して、前記検索手段にて検索された前記未使用の接続プラグの情報を通知する通知手段と
   を含むことを特徴とするデータ転送装置。
9. 前記検索手段は、当該データ転送装置の有する出力プラグコントロールレジスタの現在値とその初期値とを比較する第１比較手段を含むことを特徴とする請求項８に記載のデータ転送装置。
10. 前記問い合わせを受けたチャネル番号と当該データ転送装置の有する出力プラグコントロールレジスタの現在値内のチャネル番号とを比較して、前記問い合わせを受けたチャネル番号が使用中であるか否かを判定する第２比較手段を含むことを特徴とする請求項８又は９に記載のデータ転送装置。

Images