(57)【特許請求の範囲】
【請求項１】
被送信データを複数のセグメントデータに分割し、前記複数のセグメントデータをアシンクロナス（Ａｓｙｎｃｈｒｏｎｏｕｓ）転送を用いてデスティネーション・ノードに転送するソース・ノードと、
前記ソース・ノードと、前記デスティネーション・ノードとの間に論理的な接続関係を設定するコントローラとを有し、
前記コントローラは、
前記ソース・ノードの第１のレジスタから前記ソース・ノードの通信能力に関する情報を取得し、前記デスティネーション・ノードの第１のレジスタから前記デスティネーション・ノードの通信能力に関する情報を取得する取得手段と、
前記第１のレジスタから取得された情報と、前記第２のレジスタから取得された情報とを用いて、複数の通信プロトコルの中から使用可能な通信プロトコルを選択する選択手段と、
前記選択手段によって選択された通信プロトコルに関する情報と、前記論理的な接続関係に関する情報とを前記ソース・ノードの第２のレジスタに格納し、前記選択手段によって選択された通信プロトコルに関する情報と、前記論理的な接続関係に関する情報とを前記デスティネーション・ノードの第２のレジスタに格納する格納手段と
を有することを特徴とするデータ通信システム。
【請求項２】
前記複数の通信プロトコルは、マルチキャスト通信を行う通信プロトコルと、ユニキャスト通信を行う通信プロトコルとを含むことを特徴とする請求項１に記載のデータ通信システム。
【請求項３】
被送信データを複数のセグメントデータに分割し、前記複数のセグメントデータをアシンクロナス（Ａｓｙｎｃｈｒｏｎｏｕｓ）転送を用いてデスティネーション・ノードに転送するソース・ノードと、前記デスティネーション・ノードとの間に論理的な接続関係を設定するデータ通信装置であって、
前記ソース・ノードの第１のレジスタから前記ソース・ノードの通信能力に関する情報を取得し、前記デスティネーション・ノードの第１のレジスタから前記デスティネーション・ノードの通信能力に関する情報を取得する取得手段と、
前記第１のレジスタから取得された情報と、前記第２のレジスタから取得された情報とを用いて、複数の通信プロトコルの中から使用可能な通信プロトコルを選択する選択手段と、
前記選択手段によって選択された通信プロトコルに関する情報と、前記論理的な接続関係に関する情報とを、前記ソース・ノードの第２のレジスタに格納し、前記選択手段によって選択された通信プロトコルに関する情報と、前記論理的な接続関係に関する情報とを、前記デスティネーション・ノードの第２のレジスタに格納する格納手段と
を有することを特徴とするデータ通信装置。
【請求項４】
前記複数の通信プロトコルは、マルチキャスト通信を行う通信プロトコルと、ユニキャスト通信を行う通信プロトコルとを含むことを特徴とする請求項３に記載のデータ通信装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データ通信システム及びデータ通信装置に関する。
【０００２】
【従来の技術】
従来、パーソナルコンピュータ（以下、ＰＣ）の周辺機器の中で、最も利用頻度が高かったのはハードディスクやプリンタであった。これらの周辺機器は、専用の入出力インタフェース或いはＳＣＳＩ（small computer system interface）インタフェース等の汎用性のあるデジタルインタフェースによってＰＣと接続されていた。
【０００３】
一方、近年、デジタルカメラ、デジタルビデオカメラ等のＡＶ（Audio/Visual）機器もＰＣの周辺装置の１つとして注目を浴びている。これらのＡＶ（Audio/Visual）機器も専用インタフェースを介してＰＣと接続されていた。
【０００４】
ところが、従来の周辺機器の有するデジタルインタフェースとＡＶ機器の有するデジタルインタフェースとは互換性がなく、それらを直接接続することはできなかった。そのため、例えば、ＡＶ機器が周辺機器に、例えば、静止画像を通信したい場合、必ずＰＣを介す必要があった。
【０００５】
又、従来の専用インタフェースやＳＣＳＩインタフェースでは、特にＡＶ機器の有する静止画像や動画像のような大容量のデータを扱う場合において、データ転送レートが低い、パラレル通信のため通信ケーブルが太い、接続できる周辺機器の数と種類が少ない、接続方式に制限がある、リアルタイムなデータ転送が行えない等の多くの問題があった。
【０００６】
このような問題点を解決する次世代の高速、高性能デジタルインタフェースの１つとして、ＩＥＥＥ（The Institute of Electrical and Electronics Engineers，Inc.）１３９４−１９９５規格が知られている。
【０００７】
ＩＥＥＥ１３９４−１９９５規格に準拠したデジタルインタフェース（以下、１３９４インタフェース）には、次のような特徴がある。
（１）データ転送速度が高速である。
（２）リアルタイムなデータ転送方式（即ち、Ｉｓｏｃｈｒｏｎｏｕｓ転送方式）とＡｓｙｎｃｈｒｏｎｏｕｓ転送方式をサポートしている。
（３）自由度の高い接続構成（トポロジ）を構築できる。
（４）プラグ・アンド・プレイ機能と活線挿抜機能をサポートしている。
【０００８】
【発明が解決しようとする課題】
しかしながら、ＩＥＥＥ１３９４−１９９５規格では、コネクタの物理的、電気的な構成、最も基本的な２つのデータ転送方式等については定義しているが、どのような種類のデータを、どのようなデータ・フォーマットで、どのような通信プロトコルに基づいて送受信するのかについては定義していなかった。
【０００９】
又、ＩＥＥＥ１３９４−１９９５規格のＩｓｏｃｈｒｏｎｏｕｓ転送方式では、送出パケットに対する応答が規定されていないため、各Ｉｓｏｃｈｒｏｎｏｕｓパケットが確実に受信されたかは保証されない。従って、連続性のある複数のデータを確実に転送したい場合、或いは１つのファイルデータを複数のデータに分割して確実に転送したい場合、Ｉｓｏｃｈｒｏｎｏｕｓ転送方式を使用することはできなかった。
【００１０】
又、ＩＥＥＥ１３９４−１９９５規格のＩｓｏｃｈｒｏｎｏｕｓ転送方式では、転送帯域に空きがある場合でも、通信の総数が６４個に制限される。このため、少ない転送帯域で数多くの通信を行いたい場合、Ｉｓｏｃｈｒｏｎｏｕｓ転送方式を使用することはできなかった。
【００１１】
又、ＩＥＥＥ１３９４−１９９５規格では、ノードの電源のＯＮ／ＯＦＦ、ノードの接続／切り離し等に応じてバスリセットが生じた場合、データの転送を中断しなければならない。ところが、ＩＥＥＥ１３９４−１９９５規格では、バスリセットや伝送時のエラーによってデータ転送が中断した場合、どのような内容のデータを失ったのかについては知ることができなかった。更に、一度中断した転送を復帰するためには、非常に煩雑な通信手順を踏む必要があった。ここで、バスリセットとは、新たなトポロジの認識と各ノードに割り当てられるアドレス（ノードＩＤ）の設定とを自動的に行う機能である。この機能により、ＩＥＥＥ１３９４−１９９５規格では、プラグ・アンド・プレイ機能と活線挿抜機能とを提供することができる。
【００１２】
又、ＩＥＥＥ１３９４−１９９５規格に準拠した通信システムにおいて、リアルタイム性は必要とされないが、信頼性が要求される比較的データ量の多いオブジェクトデータ（例えば、静止画像データ、グラフィックスデータ、テキストデータ、ファイルデータ、プログラムデータ等）を、１以上のセグメントに分割し、各セグメントを１つ以上のＡｓｙｎｃｈｒｏｎｏｕｓ転送を用いて順次転送するための通信プロトコルは具体的に提案されていなかった。
【００１３】
特に、ＩＥＥＥ１３９４−１９９５規格に準拠した通信システムにおいて、複数の機器間のデータ通信を、Ａｓｙｎｃｈｒｏｎｏｕｓ転送方式によるブロードキャスト通信を用いて実現するための通信プロトコルも具体的に提案されていなかった。
【００１４】
又、このような通信プロトコルが複数個提案された場合、通信相手の使用する通信プロトコルを自動的に判別し、使い分けるようにできることが望ましい。しかしながら、複数の異なる通信プロトコルを使い分けるための仕組みについても具体的には何も提案されていなかった。
【００１５】
本発明は、複数の異なる通信プロトコルが存在する場合でも、使用可能な通信プロトコルを選択できるようにすることを目的とする。
【００１６】
【課題を解決するための手段】
本発明に係るデータ通信システムは、被送信データを複数のセグメントデータに分割し、前記複数のセグメントデータをアシンクロナス（Ａｓｙｎｃｈｒｏｎｏｕｓ）転送を用いてデスティネーション・ノードに転送するソース・ノードと、前記ソース・ノードと、前記デスティネーション・ノードとの間に論理的な接続関係を設定するコントローラとを有し、前記コントローラは、前記ソース・ノードの第１のレジスタから前記ソース・ノードの通信能力に関する情報を取得し、前記デスティネーション・ノードの第１のレジスタから前記デスティネーション・ノードの通信能力に関する情報を取得する取得手段と、前記第１のレジスタから取得された情報と、前記第２のレジスタから取得された情報とを用いて、複数の通信プロトコルの中から使用可能な通信プロトコルを選択する選択手段と、前記選択手段によって選択された通信プロトコルに関する情報と、前記論理的な接続関係に関する情報とを前記ソース・ノードの第２のレジスタに格納し、前記選択手段によって選択された通信プロトコルに関する情報と、前記論理的な接続関係に関する情報とを前記デスティネーション・ノードの第２のレジスタに格納する格納手段とを有することを特徴とする。
【００１８】
本発明に係るデータ通信装置は、被送信データを複数のセグメントデータに分割し、前記複数のセグメントデータをアシンクロナス（Ａｓｙｎｃｈｒｏｎｏｕｓ）転送を用いてデスティネーション・ノードに転送するソース・ノードと、前記デスティネーション・ノードとの間に論理的な接続関係を設定するデータ通信装置であって、前記ソース・ノードの第１のレジスタから前記ソース・ノードの通信能力に関する情報を取得し、前記デスティネーション・ノードの第１のレジスタから前記デスティネーション・ノードの通信能力に関する情報を取得する取得手段と、前記第１のレジスタから取得された情報と、前記第２のレジスタから取得された情報とを用いて、複数の通信プロトコルの中から使用可能な通信プロトコルを選択する選択手段と、前記選択手段によって選択された通信プロトコルに関する情報と、前記論理的な接続関係に関する情報とを、前記ソース・ノードの第２のレジスタに格納し、前記選択手段によって選択された通信プロトコルに関する情報と、前記論理的な接続関係に関する情報とを、前記デスティネーション・ノードの第２のレジスタに格納する格納手段とを有することを特徴とする。
【００２９】
【発明の実施の形態】
以下、本発明の好適な実施例について図面を参照して詳細に説明する。
図１は、データ通信システムの構成の一例を示す図である。本実施例のデータ通信システムは、図１に示すように、コンピュータ１０、カメラ一体型デジタルビデオレコーダ２８、プリンタ６０により構成されている。
【００３０】
まず、コンピュータ１０の構成について説明する。１２はコンピュータ１０の動作を制御する演算処理装置（ＭＰＵ）である。１４はＩＥＥＥ１３９４−１９９５規格に準拠した機能と本実施例において規定する通信プロトコルに関する機能とを有する１３９４インタフェースである。１６はキーボード、マウスなどからなる操作部である。１８は圧縮符号化されたディジタルデータ（動画像データ、静止画像データ、音声データ等）を復号するデコーダである。２０はＣＲＴディスプレイや液晶パネルなどの表示装置からなる表示部（ディスプレイ）である。２２は各種のディジタルデータ（動画像データ、静止画像データ、音声データ、グラフィックスデータ、テキストデータ、プログラムデータ等）を記録するハードディスク（ＨＤ）である。２４は内部メモリである。２６はＰＣＩバスなどのコンピュータ１０内部の各処理部を相互に接続する内部バスである。
【００３１】
次に、カメラ一体型デジタルビデオレコーダ（以下、ＤＶＣＲと称する）２８の構成について説明する。３０は被写体の光学像を電気信号に変換し、その電気信号をに変換する撮像部（ｏｐｔ）である。３２はアナログ-デジタル（Ａ／Ｄ）変換器である。３４はディジタル化された動画像、静止画像を所定のフォーマットのディジタル画像データに変換する画像処理部である。３６は圧縮／伸長処理部であり、圧縮符号化されたディジタルデータ（動画像データ、静止画像データ、音声データ等）を復号する機能と、デジタル画像データを高能率符号化する（例えば、ＭＰＥＧ方式やＤＶ方式のように、所定の画像単位に直交変換後、量子化し、可変長符号化する）機能とを有する。３８は高能率符号化されたディジタル画像データを一時的に格納するメモリである。４０は高能率符号化されていないディジタル画像データを一時的に格納するメモリである。４２はデータセレクタである。４４はＩＥＥＥ１３９４−１９９５規格に準拠した機能と本実施例において規定する通信プロトコルに関する機能とを有する１３９４インタフェースである。４６、４８はメモリ３８とメモリ４０の書き込みと読み出しとを制御するメモリ制御部である。５０はＤＶＣＲ２８の動作を制御する制御部（システムコントローラ）であり、マイクロコンピュータを有する。５２はリモコンや操作パネル等からなる操作部である。５４は電子ビューファインダ（ＥＶＦ）である。５６はＤ／Ａ変換器である。５８は磁気テープ、磁気ディスク、光磁気ディスク等の記録媒体からなる記録再生部で、各種のディジタルデータ（動画像データ、静止画像データ、音声データ等）を記録再生する。
【００３２】
次に、プリンタ６０の構成について説明する。６２はＩＥＥＥ１３９４−１９９５規格に準拠した機能と本実施例において規定する通信プロトコルに関する機能とを有する１３９４インタフェースである。６４はデータセレクタである。６６は操作ボタンやタッチパネル等からなる操作部である。６８はプリンタ６０の動作を制御するプリンタコントローラである。７０はデコーダである。７２は内部メモリである。７４は１３９４インタフェースを介して受信された静止画像データ、テキストデータ、グラフィックスデータ等を処理する画像処理部である。７６はドライバである。７８はプリンタヘッドである。
【００３３】
図１に示すように、コンピュータ１０、ＤＶＣＲ２８及びプリンタ６０の各通信装置（以下、ノードと称する）は、１３９４インタフェース１４、４４、６２を介して相互に接続されている（以下、１３９４インタフェースによって構成されたネットワークを１３９４シリアルバスと称する）。各ノードは、所定の通信プロトコルを定義することによって、各種のオブジェクトデータ（例えば、動画像データ、静止画像データ、音声データ、グラフィックスデータ、テキストデータ、プログラムデータ等）の授受、コマンドデータによる遠隔操作が可能となる。
【００３４】
次に、図１を用いて本実施例の通信システムを構成する各ノードの動作について説明する。
まず、コンピュータ１０を構成する各処理部の機能と動作について説明する。本実施例においてコンピュータ１０は、例えば、ＤＶＣＲ２８とプリンタ６０との間における画像データの送受信を制御するコントローラ、或いはＤＶＣＲ２８やプリンタ６０を遠隔操作するコントローラとして動作する。
【００３５】
ＭＰＵ１２は、ハードディスク２２に記録されているソフトウェアを実行するとともに、様々なデータを内部メモリ２４に移動させる。又、ＭＰＵ１２は、内部バス２６によって接続されている各処理部の調停動作なども合わせて行なう。
【００３６】
１３９４インタフェース１４は、１３９４シリアルバス上に転送された画像データを受信するとともに、ハードディスク２２や内部メモリ２４に記録されている画像データを１３９４シリアルバス上に送信することができる。又、１３９４インタフェース１４は、１３９４シリアルバス上の他のノードを遠隔操作するためのコマンドデータを送信することも可能である。更に、１３９４インタフェース１４は、１３９４シリアルバスを介して転送された信号を他のノードに転送する機能も有している。
【００３７】
ユーザは、操作部１６を介して所望のソフトウェアを選択し、ＭＰＵ１２にハードディスク２２に記録されているソフトウェアを実行させる。ここで、このソフトウェアに関する情報は、表示部２０によってユーザに提示される。デコーダ１８は、このソフトウェアに基づいて、１３９４シリアルバス上から受信した画像データをデコードする。デコードされた画像データは、表示部２０によってユーザに提示される。
【００３８】
次に、ＤＶＣＲ２８を構成する各処理部の機能と動作について説明する。本実施例においてＤＶＣＲ２８は、本実施例の通信プロトコルに基づいて画像データを転送する画像送信装置（ソース・ノード）として動作する。
【００３９】
撮像部３０は、被写体の光学像を輝度信号（Ｙ）と色差信号（Ｃ）とからなる電気信号に変換し、その電気信号をＡ／Ｄ変換器６０に供給する。Ａ／Ｄ変換器３２は、その電気信号をディジタル化する。
【００４０】
画像処理部３４は、ディジタル化された輝度信号と色差信号とに対して所定の画像処理を施すと共に、それらを多重化する。圧縮／伸長処理部３６は、ディジタル化された輝度信号と色差信号のデータ量を圧縮する。ここで、圧縮／伸長処理部３６は、独立した圧縮処理回路を用いて輝度信号と色差信号と並列に処理してもよい。又、共通の圧縮処理回路を用いてそれらを時分割に処理してもよい。又、圧縮／伸長処理部３６では、伝送路誤りに強くするために、圧縮画像データに対してシャフリング処理を施す。これにより、連続的な符号誤り（即ち、バーストエラー）を、修整や補間の行いやすい離散的な誤り（即ち、ランダムエラー）に変換することができる。ここで、画像の画面内の粗密による情報量の偏りを均一化したい場合、圧縮処理の前に本処理工程を持ってくると、ランレングス等の可変長符号化を用いた場合の都合が良い。
【００４１】
圧縮／伸長処理部３６では、圧縮画像データに対して、シャフリングを復元するためのデータ識別情報（ＩＤ）を付加する。圧縮／伸長処理部３６は、記録再生時の誤りを低減する為に、圧縮画像データに対してエラー訂正符号（ECC）を付加する。
【００４２】
圧縮／伸長処理部３６にて圧縮された画像データは、メモリ３８と記録再生部５８とに供給される。記録再生部５８は、ＩＤやＥＣＣの付加された圧縮画像データを磁気テープ等の記録媒体に記録する。ここで、圧縮画像データは、音声データとは異なる独立の記録エリアに記録される。
【００４３】
一方、画像処理部３４からＤ／Ａ変換器５６へ供給された画像データは、Ｄ／Ａ変換される。ＥＶＦ５４は、Ｄ／Ａ変換器５６から供給されたアナログ画像信号を表示する。又、画像処理部３４にて処理された画像データは、メモリ４０にも供給される。ここで、メモリ４０には、非圧縮の画像データが格納される。
【００４４】
データセレクタ４２は、ユーザの指示に基づいてメモリ３８或いはメモリ４０を選択し、圧縮画像データ或いは非圧縮画像データを１３９４インタフェース４４に供給する。又、データセレクタ４２は、１３９４インタフェース４４から供給された画像データをメモリ３８或いはメモリ４０に供給する。
【００４５】
１３９４インタフェース４４は、後述する本実施例の通信プロトコルに基づいて、圧縮画像データ或いは非圧縮画像データを転送する。又、１３９４インタフェース４４は、１３９４シリアルバスを介して、ＤＶＣＲ２８を制御するための制御コマンドを受信する。受信された制御コマンドは、データセレクタ４２を介して、制御部５０に供給される。１３９４インタフェース４４は、上記の制御コマンドに対するレスポンスを返送する。
【００４６】
次に、プリンタ６０を構成する各処理部の機能と動作について説明する。本実施例においてプリンタ６０は、本実施例の通信プロトコルに基づいて転送された画像データを受信して印刷する画像受信装置（デスティネーション・ノード）として動作する。
【００４７】
１３９４インタフェース６２は、１３９４シリアルバスを介して転送された画像データや制御コマンドを受信する。又、１３９４インタフェース６２は、制御コマンドに対するレスポンスを送信する。
【００４８】
受信された画像データは、データセレクタ６４を介して、デコーダ７０に供給される。デコーダ７０は、該画像データをデコードし、その結果を画像処理部７４に出力する。画像処理部７４は、デコードされた画像データをメモリ７２に一時的に記憶する。
【００４９】
又、画像処理部７４は、メモリ７２に一時的に記憶された画像データを印刷用のデータに変換し、それをプリンタヘッド７８に供給する。プリンタヘッド７８は、プリンタコントローラ６８の制御に基づき、印刷を実行する。
【００５０】
一方、受信された制御コマンドは、データセレクタ６４を介して、プリンタコントローラ６８に入力される。プリンタコントローラ６８は、該制御データに基づいて印刷に関する様々な制御を行なう。例えば、ドライバ７６による紙送り、プリンタヘッド７８の位置等を制御する。
【００５１】
次に、図２を用いて本実施例の１３９４インタフェース１４、４４、６２の構成について詳細に説明する。
１３９４インタフェースは、機能的に複数のレイヤ（階層）から構成されている。図２において、１３９４インタフェースは、ＩＥＥＥ１３９４−１９９５規格に準拠した通信ケーブル２０１を介して他のノードの１３９４インタフェースと接続される。又、１３９４インタフェースは、１つ以上の通信ポート２０２を有し、各通信ポート８０２はハードウェア部に含まれるフィジカル・レイヤ２０３と接続される。
【００５２】
図２において、ハードウェア部は、フィジカル・レイヤ２０３とリンク・レイヤ２０４とから構成されている。フィジカル・レイヤ２０３は、他のノードとの物理的、電気的なインタフェース、バスリセットの検出とそれに伴う処理、入出力信号の符号化／復号化、バス使用権の調停等を行う。又、リンク・レイヤ２０４は、通信パケットの生成、各種の通信パケットの送受信、サイクルタイマの制御等を行なう。更に、リンク・レイヤ２０４は、後述する第１、第２の通信プロトコルで使用するデータパケットの生成及び送受信の機能を提供する。
【００５３】
又、図２において、ファームウェア部は、トランザクション・レイヤ２０５とシリアル・バス・マネージメント２０６とを含んでいる。トランザクション・レイヤ２０５は、Ａｓｙｎｃｈｒｏｎｏｕｓ転送方式を管理し、各種のトランザクション（リード、ライト、ロック）を提供する。更に、トランザクション・レイヤ２０５は、後述する第１、第２の通信プロトコルの機能を提供する。シリアル・バス・マネージメント２０６は、後述するＩＥＥＥ１２１２ＣＳＲ規格に基づいて、自ノードの制御、自ノードの接続状態の管理、自ノードのＩＤ情報の管理、シリアルバスネットワークの資源管理を行う機能を提供する。
【００５４】
図２に示すハードウェア部及びファームウェア部が実質的に１３９４インタフェースを構成するものであり、それらの基本構成はＩＥＥＥ１３９４−１９９５規格により規定されている。
【００５５】
又、ソフトウェア部に含まれるアプリケーション・レイヤ２０７は、使用するアプリケーションソフトによって異なり、どのようなオブジェクトデータを第１、第２の通信プロトコルを用いてどのように転送するかを制御する。
【００５６】
後述する本実施例の第１、第２の通信プロトコルは、１３９４インタフェースを構成するハードウェア部及びファームウェア部の機能を拡張するものであり、ソフトウェア部に対して新規な転送手順を提供するものである。
【００５７】
次に、図３を用いて、本実施例の第１、第２の通信プロトコルの基本構成について説明する。本実施例において、第１の通信プロトコルは、マルチキャスト通信を実現する通信プロトコルである。又、第２の通信プロトコルは、ユニキャスト通信を実現する通信プロトコルである。
【００５８】
図３において、３００はコントローラ、３０２はソース・ノード、３０４はｎ（ｎ≧１）個のデスティネーション・ノード、３０６はソース・ノードの有するサブユニット（ｓｕｂｕｎｉｔ）、３０８は動画像データ、静止画像データ、グラフィックスデータ、テキストデータ、ファイルデータ、プログラムデータ等のオブジェクトデータ（object）である。
【００５９】
３１０はデスティネーション・ノード３０４内部にある第１のメモリ空間であり、所定のデスティネーション・オフセット（ｄｅｓｔｉｎａｔｉｏｎ_ｏｆｆｓｅｔ_０）により指定される。３１２はソース・ノード３０２とデスティネーション・ノード３０４との間の論理的な接続関係（以下、コネクションと称する）を示す第１のコネクションである。ここで、デスティネーション・オフセットとは、ｎ個のデスティネーション・ノード３０４の有するメモリ空間を共通に指定するアドレスである。
【００６０】
３１４はデスティネーション・ノード３０４内部にある第ｎのメモリ空間であり、所定のデスティネーション・オフセット（ｄｅｓｔｉｎａｔｉｏｎ_ｏｆｆｓｅｔ_ｎ）により指定される。３１６はソース・ノード３０２とデスティネーション・ノード３０４との間のコネクションを示す第ｎのコネクションである。
【００６１】
本実施例において、各ノードは、第１のメモリ空間３１０〜第ｎのメモリ空間３１４を、ＩＥＥＥ１２１２  ＣＳＲ（ＣｏｎｔｒｏｌａｎｄＳｔａｔｕｓＲｅｇｉｓｔｅｒＡｒｃｈｉｔｅｃｔｕｒｅ）規格（又は、ＩＳＯ／ＩＥＣ  １３２１３：１９９４規格）に準拠した６４ビットのアドレス空間により管理している。ＩＥＥＥ１２１２  ＣＳＲ規格とは、シリアルバス向けの制御、管理、アドレス割り振りを規定した規格である。
【００６２】
図４は、各ノードの有するアドレス空間について説明する図である。図４（ａ）は、各ノードのメモリ空間をアドレッシングする６４ビットのアドレス空間である。６４ビットアドレスの上位１６ビットは、あるバス内のあるノードを指定するために使用される。又、図４（ｂ）は、図４（ａ）に示すアドレス空間の一部であり、例えば、上位１６ビットで指定されたノードのもつあるアドレス空間を指定するために使用される。
【００６３】
図３に示す第１のメモリ空間３１０〜第ｎのメモリ空間３１４は、図４（ｂ）に示す４８ビットのアドレス（以下、デスティネーション・オフセットと称する）により指定される。図４（ｂ）において、例えば、００００００００００００16〜０００００００００３ＦＦ16は予約された領域であり、実際にオブジェクトデータ３０８の書き込まれる領域は、アドレスの下位４８ビットがＦＦＦＦＦ００００４００16以降となる領域である。
【００６４】
図３において、ソース・ノード３０２とは、第１或いは第２の通信プロトコルに従ってオブジェクトデータ３０８を転送する機能をもつノードであり、デスティネーション・ノード３０４とは、ソース・ノード３０２から転送されたオブジェクトデータ３０８を受信する機能をもつノードである。又、コントローラ３００とは、ソース・ノード３０２と１つ或いは複数のデスティネーション・ノード３０４との間のコネクション（即ち、論理的な接続関係）を設定、管理する機能と、そのコネクションにて使用される通信プロトコルを選択する機能をもつノードである。
【００６５】
ここで、コントローラ３００、ソース・ノード３０２、デスティネーション・ノード３０４は、夫々独立した別々のノードにおいて機能してもよい。又、コントローラ３００とソース・ノード３０２とが、１つの同じノードにおいて機能してもよい。又、コントローラ３００とデスティネーション・ノード３０４とが、１つの同じノードにおいて機能してもよい。この場合、コントローラ３００とソース・ノード３０２或いはデスティネーション・ノード３０４との間のトランザクションが不要となり、通信手順が簡略化される。
【００６６】
本実施例では、コントローラ３００、ソース・ノード３０２、デスティネーション・ノード３０４の夫々が、独立した別々のノードにおいて機能する場合について説明する。例えば、１３９４インタフェース１４を具備するコンピュータ１０が、コントローラ３００として機能する。又、１３９４インタフェース４４を具備するＤＶＣＲ２８がソース・ノード３０２、１３９４インタフェース６２を具備するプリンタ６０がデスティネーション・ノード３０４として機能する。
【００６７】
本実施例では、図３に示すように、ソース・ノード３０２と１つ以上のデスティネーション・ノード３０４との間に、１つ以上のコネクションを設定することができる。各コネクションは、あるオブジェクトデータの転送要求が生じた場合に、後述するソース・ノード３０２の出力レジスタ（図５参照）、デスティネーション・ノード３０４の入力レジスタ（図６参照）に基づいてコントローラ３００が設定する。
【００６８】
尚、本実施例において、コントローラ３００であるコンピュータ１０は、デスティネーション・ノード３０４として動作してもよい。この場合、１つのソース・ノード３０２と２つのデスティネーション・ノード３０４との間にコネクションが設定され、オブジェクトデータ３０８の転送が行われることになる。
【００６９】
又、本実施例において、コンピュータ１０がコントローラ３００として動作する場合について説明したが、コンピュータ１０が必ずコントローラ３００になる必要はない。ＤＶＣＲ２８或いはプリンタ６０がコントローラ３００として動作してもよい。
【００７０】
次に、図５、６を用いて、本実施例のソース・ノード３０２の有するレジスタ空間とデスティネーション・ノード３０４の有するレジスタ空間とについて説明する。図５は、ソース・ノード３０２の有する出力レジスタの構成を説明する図である。又、図６は、デスティネーション・ノード３０４の有する入力レジスタの構成を説明する図である。
【００７１】
各レジスタ空間は、図４に示すアドレス空間上の所定の領域に用意されており、コントローラ３００がソース・ノード３０２とデスティネーション・ノード３０４との間にコネクションを設定する場合、該コネクションに第１、第２の通信プロトコルの何れを割り当てるかを選択する場合に使用される。
【００７２】
図５（ａ）は、出力マスターコネクションレジスタ（以下、oMCR）である。OMCRは、主に、ソース・ノード３０２の有する通信能力について記述しているレジスタ空間（または、メモリ空間）である。
【００７３】
oMCRの最上位フィールド５０１（２ビット）は、max data rateフィールドであり、ソース・ノード３０２の最大の出力ビットレートを示す。該max data rateフィールドにセットされる値の一例を「表１」に示す。
【００７４】
次のフィールド５０２（１ビット）は、flow control flagであり、本実施例の第１の通信プロトコル（即ち、ブロードキャスト送信を用いたプロトコル）が使用可能か否かを示す。例えば、該フィールドの値が「１」のとき、第１の通信プロトコルが使用可能であることを示す。「０」のときは、第２の通信プロトコルが使用可能である。次のフィールド５０３（５ビット）は、reservedフィールドであり、将来のために予約されている。
【００７５】
【表１】
0004181688.tif 000002
【００７６】
次のフィールド５０４（６ビット）は、extension fieldであり、後述するoutput FIFO sizeフィールドを将来拡張する場合に用いる。次のフィールド５０５（１０ビット）は、output FIFO sizeフィールドであり、データ出力に用いられる先入れ先出し型のバッファメモリ（以下、FIFOメモリ）の容量を示す。
【００７７】
次のフィールド５０６（３ビット）は、reservedフィールドであり、将来のために予約されている。最下位フィールド５０７（５ビット）は、number of CCRsフィールドであり、後述する出力コネクションコントロールレジスタ（図５（ｂ）参照）の数、即ち、ソース・ノード３０２に設定することのできるコネクションの数を示す。
【００７８】
図５（ｂ）は、出力コネクションコントロールレジスタ（以下、oCCR）である。
oCCRは、ソース・ノード３０２に設定されたコネクションの１つについて記述するレジスタ空間（又は、メモリ空間）である。ソース・ノード３０２は、上記oCCRを、唯一つだけ有していても良いし、複数有していても良い。
【００７９】
oCCRの最上位フィールド５１０（２ビット）は、data rateフィールドであり、該oCCRに設定されたコネクションにて用いられる出力ビットレートを示す。「表２」に該data rateフィールドにセットされる値の一例を示す。
【００８０】
【表２】
0004181688.tif 000003
【００８１】
次のフィールド５１１（１ビット）は、broadcast flagフィールドであり、該oCCRに設定されたコネクションにてどの通信プロトコルが使用されているかを示すフラグである。該broadcast flagフィールドの値が「１」のとき、例えば、第１の通信プロトコルが用いられていることを示す。
【００８２】
次のフィールド５１２（１ビット）は、on-lineフィールドであり、該oCCRが使用されているか否かを示す。該on-lineフィールドの値が「１」のとき、該oCCRは使用されていることを示す。
【００８３】
次のフィールド５１３（１８ビット）は、reservedフィールドであり、将来のために予約されている。次のフィールド５１４（１０ビット）は、payload sizeフィールドであり、一回のデータ転送で転送されるデータパケットのデータ量を示す。該データ量はデータパケットのペイロードサイズを示し、パケットヘッダなどの付加データは含まれていない。
【００８４】
次のフィールド５１５（１６ビット）は、connection IDフィールドであり、該oCCRに設定されたコネクションを一意に識別するための識別情報、即ちコネクションIDが格納される。最後のフィールド５１６（４８ビット）は、offset addressフィールドであり、デスティネーション・ノード３０４に確保した所定のメモリ空間の先頭アドレスを示す。
【００８５】
図６（ａ）は、入力マスターコネクションレジスタ（以下、iMCR）である。iMCRは、主に、デスティネーション・ノード３０４の有する通信能力について記述しているレジスタ空間（又は、メモリ空間）である。
【００８６】
iMCRの最上位フィールド６０１（２ビット）は、max data rateフィールドであり、デスティネーション・ノード３０４の最大の入力ビットレートを示す。該max data rateフィールドにセットされる値は、例えば、上記「表１」と同じで良い。
【００８７】
次のフィールド６０２（１ビット）は、flow control flagフィールドであり、本実施例の第１の通信プロトコル（即ち、ブロードキャスト送信を用いたプロトコル）が使用可能か否かを示す。例えば、該フィールドの値が「１」のとき、第１の通信プロトコルが使用可能であり、「０」のときは、第２の通信プロトコルが使用可能であることを示す。次のフィールド６０３（５ビット）は、reservedフィールドであり、将来のために予約されている。
【００８８】
次のフィールド６０４（６ビット）は、extension fieldであり、後述するmaximum receive buffer sizeフィールドを将来拡張する場合に用いる。次のフィールド６０５（１０ビット）は、maximum receive buffer sizeフィールドであり、データ入力に用いられる受信バッファの最大メモリを示す。ここで、maximum receive buffer sizeフィールドは、１セグメントの最大データ量を示す。
【００８９】
次のフィールド６０６（３ビット）は、reservedフィールドであり、将来のために予約されている。最下位フィールド６０７（５ビット）は、number of CCRsフィールドであり、後述する入力コネクションコントロールレジスタ（図６（ｂ）参照）の数、すなわち、デスティネーション・ノード３０４に設定することのできるコネクションの数を示す。
【００９０】
図６（ｂ）は、入力コネクションコントローラレジスタ（以下、iCCR）である。
iCCRは、デスティネーション・ノード３０４に設定されたコネクションの１つについて記述するレジスタ空間（又は、メモリ空間）である。デスティネーション・ノード３０４は、上記iCCRを、唯一つだけ有していても良いし、複数有していても良い。
【００９１】
iCCRの最上位フィールド６１０（２ビット）は、data rateフィールドであり、該iCCRに設定されたコネクションにて用いられる入力ビットレートを示す。該data rateフィールドにセットされる値は、例えば、「表２」と同じでよい。
【００９２】
次のフィールド６１１（１ビット）は、broadcast flagフィールドであり、該iCCRに設定されたコネクションにてどの通信プロトコルが使用されているかを示すフラグである。該broadcast flagフィールドの値が「１」のとき、例えば、第１の通信プロトコルが用いられていることを示す。
【００９３】
次のフィールド６１２（１ビット）は、on-lineフィールドであり、該iCCRが使用されているか否かを示す。該on-lineフィールドの値が「１」のとき、該iCCRは使用されていることを示す。次のフィールド６１３（１８ビット）は、reservedフィールドであり、将来のために予約されている。
【００９４】
次のフィールド６１４（１０ビット）は、receive buffer sizeフィールドであり、デスティネーション・ノード３０４に確保したメモリ空間のサイズ、即ち、１セグメントのデータ量を示す。次のフィールド６１５（１６ビット）は、connection IDフィールドであり、該iCCRに設定されたコネクションを一意に識別するための識別情報、即ちコネクションIDが格納される。
【００９５】
最後のフィールド６１６（４８ビット）は、offset addressフィールドであり、デスティネーション・ノード３０４に確保した所定のメモリ空間の先頭アドレスを示す。
【００９６】
次に、図５、図６に示す各レジスタの内容を読み出すためのコマンドと、各レジスタに所定の値を書き込むコマンドについて説明する。
各コマンドは、ＩＥＥＥ１３９４−１９９５規格のＡｓｙｎｃｈｒｏｎｏｕｓ転送方式に準拠するＡｓｙｎｃｈｒｏｎｏｕｓパケットにパケッタイズされ、指定されたノードに転送される。ここで、Ａｓｙｎｃｈｒｏｎｏｕｓパケットは、図７に示すように、１Ｑｕａｄｌｅｔ（４ｂｙｔｅｓ＝３２ｂｉｔｓ)を単位とするデータパケットである。
【００９７】
本実施例のコントローラ３００は、図７に示すREAD MCR status commandを用いて、図５（ａ）のoMCR或いは図６（ａ）のiMCRの値を読み出すことができる。図７において、フィールド７０１（１６ｂｉｔｓ）は、destination_IDフィールドであり、通信相手のノードＩＤを指定する。フィールド７０２（６ｂｉｔｓ）は、トランザクション・ラベル(tl)フィールドであり、各トランザクション固有のタグを指定する。
【００９８】
フィールド７０３（２ｂｉｔｓ）は、リトライ(rt)コードであり、パケットがリトライを試みるかどうかを指定する。フィールド７０４（４ｂｉｔｓ）は、トランザクションコード(tcode)を示す。tcodeは、パケットのフォーマットや、実行しなければならないトランザクションのタイプを指定する。本実施例では、このフィールドの値を例えば「０００１2」とし、このパケットのデータ・フィールドをdestination_offsetフィールド７０７の示すメモリ空間に書き込む処理（即ち、ライト・トランザクション）をリクエストする。また、「０００５2」とした場合は、読み出し処理（即ち、リード・トランザクション）をリクエストする。
【００９９】
フィールド７０５（４ｂｉｔｓ）は、プライオリティ(pri)を示し、優先順位を指定する。本実施例では、このフィールドの値は「００００2」とする。フィールド７０６（１６ｂｉｔｓ）は、source_IDフィールドであり、送信元のノードＩＤを指定する。
【０１００】
フィールド７０７（４８ｂｉｔｓ）は、destination_offsetを示し、destination_IDフィールド７０１で指定されたノードのアドレス空間を指定する。フィールド７０８（１６ｂｉｔｓ）は、data_lengthを示し、後述するデータフィールドの長さをバイト単位で示す。
【０１０１】
フィールド７０９（１６ｂｉｔｓ）は、extended_tcodeを示す。本実施例では、このフィールドの値を「００００2」とする。フィールド７１０（３２ｂｉｔｓ）は、header_CRCであり、上述したフィールド７０１〜７０９のエラーを検出するためのエラー検出コードを格納する。
【０１０２】
次に、データ・フィールド（data field）の構成を説明する。本実施例において、データ・フィールドに格納されるデータ量がＱｕａｄｌｅｔの倍数に満たない場合、Ｑｕａｄｌｅｔの倍数となるまで「０」がセットされる。
【０１０３】
フィールド７１１（４ｂｉｔｓ）は、Command/Transaction Set（以下、ＣＴＳと称する）フィールドである。本実施例では、AV/C Digital Interface Command Set General Specification規格（以下、AV/C Command Set規格と称する）において定義されているＣＴＳを使用するため、このフィールドには「０16」がセットされる。
【０１０４】
フィールド７１２（４ｂｉｔｓ）は、ctype/responseフィールドであり、各種のコマンドやそのコマンドに対するレスポンスを指定する。例えば、status commandを指定する場合、このフィールドには「１16」がセットされる。又、このstatus commandに対応するレスポンス（即ち、status response）を指定する場合、このフィールドには「Ｃ16」がセットされる。
【０１０５】
フィールド７１３（５ｂｉｔｓ）は、subunit_typeフィールドであり、あるノードの有する仮想的な機能単位（即ち、subunit）を指定する。ここでsubunitとは、AV/C Command Set規格において規定されており、例えば、ＶＴＲサブユニット、プリンタサブユニット等がある。
【０１０６】
フィールド７１４（３ｂｉｔｓ）は、subunit_IDフィールドであり、subunit_typeフィールド７１３で指定された機能単位が１つ以上ある場合に、それらを識別するためのＩＤ番号を指定する。
【０１０７】
フィールド７１５（８ｂｉｔｓ）は、opcodeフィールドであり、コマンドの種類を指定する。本実施例のREAD MCR commandを指定する場合、このフィールドには、例えば「０６16」がセットされる。
【０１０８】
フィールド７１６（８ｂｉｔｓ）〜７１９（８ｂｉｔｓ）は、operand[０]〜operand[３]フィールドであり、その内容は、ctype/responceフィールド７１２、opcodeフィールド７１５の内容によって異なる。例えば、READ MCR status commandの場合、各フィールドには、「ＦＦ16」がセットされる。又、READ MCR status responseの場合、各フィールドには、図５（ａ）のoMCRの値、或いは図６（ｂ）のiMCRの値がセットされる。
【０１０９】
フィールド７２０（８ｂｉｔｓ）には、「０」がセットされる。フィールド７２１（３２ｂｉｔｓ）は、data_CRCであり、上記のheader_CRCと同様に、フィールド７１１〜７２０のエラーを検出するためのエラー検出コードを格納する。
【０１１０】
又、本実施例のコントローラ３００は、図８に示すSET CCR control commandを用いて、図５（ｂ）のoCCR或いは図６（ｂ）のiCCRに所定の値を書き込むことができる。
図８において、パケット・ヘッダ（packet header）に含まれるフィールド７０１〜７１０は、図７と同様に構成される。従って、以下、SET CCR control commandのデータ・フィールド（data field）の構成について説明する。
【０１１１】
フィールド８０１（４ｂｉｔｓ）は、ＣＴＳフィールドであり、図７のREAD MCR status commandと同様に、「０16」がセットされる。
【０１１２】
フィールド８０２（４ｂｉｔｓ）は、ctype/responseフィールドであり、各種のコマンドやそのコマンドに対するレスポンスを指定する。例えば、control commandを指定する場合、このフィールドには「０16」がセットされる。このcontrol commandが受け付けられたことを示すレスポンスを返す場合、このフィールドにはACCEPTED responseを示す「９16」がセットされる。又、このcontrol commandが受け付けられなかったことを示すレスポンスを返す場合、このフィールドにはREJECTED responseを示す「Ａ16」がセットされる。
【０１１３】
フィールド８０３（５ｂｉｔｓ）は、subunit_typeフィールドであり、図７のREAD MCR status commandと同様に、所定のsubunitを指定する。フィールド８０４（３ｂｉｔｓ）は、subunit_IDフィールドであり、図７のREAD MCR status commandと同様に、所定のsubunitを識別するためのＩＤ番号を指定する。
【０１１４】
フィールド８０５（８ｂｉｔｓ）は、opcodeフィールドであり、コマンドの種類を指定する。本実施例のSET CCR commandを指定する場合、このフィールドには、例えば「０７16」がセットされる。
【０１１５】
フィールド８０６（２ｂｉｔｓ）は、data_rateフィールドであり、所望のoCCR（或いはiCCR）に設定されたコネクションが用いる入力ビットレートを示す。該data_rateフィールドにセットされる値は、例えば、「表２」と同じである。
フィールド８０７（１ｂｉｔｓ）は、broadcast_flagフィールドであり、所望のoCCR（或いはiCCR）に設定されたコネクションが、どの通信プロトコルを使用するかを示すフラグである。該broadcast_flagフィールドが「１」のとき、例えば、第１の通信プロトコルが設定される。
【０１１６】
フィールド８０８（１ｂｉｔｓ）は、on_lineフィールドであり、所望のoCCR（或いはiCCR）の使用を要求するために「１」をセットする。ここで、所望のoCCR（或いはiCCR）のon_lineフィールド５１２（６１２）が「１」であれば、該oCCR（或いはiCCR）は既に使用されているため、このSET CCR control commandを受信したノードはREJECTED responseを返す。
【０１１７】
フィールド８０９（４ｂｉｔｓ）は、例えば、固定値「Ｆ16」を設定する。フィールド８１０（８ｂｉｔｓ）は、例えば、固定値「ＦＦ16」を設定する。フィールド８１１（６ｂｉｔｓ）は、例えば、固定値「３Ｆ16」を設定する。
【０１１８】
フィールド８１２（１０ｂｉｔｓ）は、oCCRをセットする場合、payload_sizeフィールドであり、iCCRをセットする場合は、receive_buffer_sizeフィールドである。payload_sizeフィールドには、一回のデータパケットで転送可能なデータ量が設定される。又、receive_buffer_sizeフィールドには、１セグメントのデータ量が設定される。
【０１１９】
フィールド８１３（８ｂｉｔｓ）は、図５（ｂ）、図６（ｂ）に示すconnection_IDフィールドの上位８ビットを指定するフィールド、フィールド８１４（８ｂｉｔｓ）は、connection_IDフィールドの下位８ビットを指定するフィールドである。コントローラ３００は、この２つのフィールドにより、所定のconnection_IDを所望のoCCR（或いはiCCR）にセットすることができる。
【０１２０】
フィールド８１５（４８ｂｉｔｓ）は、offset_addressフィールドであり、デスティネーション・ノード３０４に確保した所定のメモリ空間の先頭アドレスを設定する。フィールド８１６（８ｂｉｔｓ）は、CCR_numberフィールドであり、１つ又は複数個あるoCCR（或いはiCCR）から、所望のoCCR（或いはiCCR）を指定するための番号を設定する。
【０１２１】
フィールド８１７（３２ｂｉｔｓ）は、data_CRCであり、フィールド８０１〜８１６のエラーを検出するためのエラー検出コードを格納する。
【０１２２】
次に図９を用いて、コントローラ３００が、ソース・ノード３０２とデスティネーション・ノード３０４との間に論理的な接続関係を設定し、各ノード間で使用する通信プロトコルを設定するまでの手順について説明する。図９において、コントローラ３００、ソース・ノード３０２、デスティネーション・ノード３０４の三者は、以下に示すネゴシエーションを行う。
【０１２３】
まず、コントローラ３００が、図７に示すREAD MCR status commandパケットを、ソース・ノード３０２に対して発行する（９０１）。ソース・ノード３０２は、該ノードが有しているoMCRの各フィールド５０１〜５０７の値をセットしたresponseパケットを、コントローラ３００に返す（９０１）。
【０１２４】
次にコントローラ３００は、図７に示すREAD MCR status commandパケットを、デスティネーション・ノード３０４に対して発行する（９０２）。デスティネーション・ノード３０４は、該ノードが有しているiMCRの各フィールド６０１〜６０７の値をセットしたresponseパケットを、コントローラ３００に返す（９０２）。
【０１２５】
上記動作により、ソース・ノード３０２のoMCRとデスティネーション・ノード３０４のiMCRとを読み出したコントローラ３００は、各レジスタの内容から各ノードの主要な通信能力を判断し、使用可能な通信プロトコルを選択する。
【０１２６】
例えば、oMCRのflow control flag５０２とiMCRのflow control flag６０２の夫々が「１」であった場合、コントローラ３００は、ソース・ノード３０２とデスティネーション・ノード３０４の夫々が後述する第１の通信プロトコル（即ち、ブロードキャストによるデータ転送を行うプロトコル）に対応可能であると判断する。その場合、コントローラ３００は、第１の通信プロトコルの使用を選択する。
【０１２７】
第１の通信プロトコルの選択後、コントローラ３００は、ソース・ノード３０２とデスティネーション・ノード３０４との間に論理的な接続関係を設定するために、図８に示すSET CCR control commandを生成する。
【０１２８】
ソース・ノード３０２のoCCR（或いは、デスティネーション・ノード３０４のiCCR）をセットするSET CCR control commandにおいて、コントローラ３００は、broadcast_flagフィールド８０７に「１」を、on_lineフィールド８０８に「１」を、connection_IDフィールド８１２、８１３にコントローラ３００が管理する使用可能なコネクションＩＤを、offset_addressフィールド８１４にデスティネーション・ノード３０４の使用可能なデスティネーション・オフセットを、CCR_numberフィールド８１５に未使用のoCCR（又は、iCCR）を指定するCCR番号を夫々設定する。
【０１２９】
又、oMCRのflow control flag５０２とiMCRのflow control flag６０２のどちらか一方、或いは両方が「０」であった場合、コントローラ３００は、ソース・ノード３０２とデスティネーション・ノード３０４の夫々が後述する第１の通信プロトコル（即ち、ブロードキャストによるデータ転送を行うプロトコル）に対応できないと判断する。その場合、コントローラ３００は、後述する第２の通信プロトコルの使用を選択する。
【０１３０】
第２の通信プロトコルの選択後、コントローラ３００は、ソース・ノード３０２とデスティネーション・ノード３０４との間に論理的な接続関係を設定するために、図８に示すSET CCR control commandを生成する。
【０１３１】
ソース・ノード３０２のoCCRをセットするSET CCR control commandにおいて、コントローラ３００は、SET CCR control commandにおいて、broadcast_flagフィールド８０７に「０」を、on_lineフィールド８０８に「１」を、payload_sizeフィールド８１１に一回のデータパケットで転送可能なデータ量を設定する。
又、デスティネーション・ノード３０４のiCCRをセットするSET CCR control commandにおいて、receive_buffer_sizeフィールド８１１に１セグメントのデータ量を設定する。
【０１３２】
更に、コントローラ３００は、oCCR（又は、iCCR）をセットするSET CCR control commandにおいて、offset_addressフィールド８１４にデスティネーション・ノード３０４の使用可能なデスティネーション・オフセットを、CCR_numberフィールド８１５に未使用のoCCR（又は、iCCR）を指定するCCR番号を夫々設定する。
【０１３３】
本実施例において、コントローラ３００は、receive_buffer_sizeフィールドに設定する値を、payload_sizeフィールドに設定する値の整数倍とする。このように構成することにより、データ転送の効率を向上させることができる。
【０１３４】
次に、コントローラ３００は、oCCRを設定するために、ソース・ノード３０２に対して、上述のSET CCR control commandを発行する（９０３）。該SET CCR control commandには、コントローラ３００にて選択された通信プロトコルを示す値や、通信プロトコルに必要な値が含まれている。
【０１３５】
ソース・ノード３０２の状態が、上記SET CCR control commandに対応可能であった場合には、ソース・ノード３０２は、コントローラ３００に対してACCEPTED responseを返す（９０３）。その後、ソース・ノード３０２は、選択された通信プロトコルに基づき、データ転送を開始する。
【０１３６】
一方、ソース・ノード３０２の状態が、上記SET CCR control commandに対応できない場合には、ソース・ノード３０２は、コントローラ３００に対してREJECTED responseを返す。この場合、データ転送は開始されず、論理的な接続も開放され、各ノードは始めから再びネゴシエーションを開始する。
【０１３７】
次に、コントローラ３００は、iCCRを開始するために、デスティネーション・ノード３０４に対して、上述のSET CCR control commandを発行する（９０４）。該SET CCR control commandには、コントローラ３００にて選択された通信プロトコルを示す値や、通信プロトコルに必要な値が含まれている。
【０１３８】
デスティネーション・ノード３０４の状態が、上記SET CCR control commandに対応可能であった場合には、デスティネーション・ノード３０４は、コントローラ３００に対してACCEPTED responseを返す（９０４）。その後、デスティネーション・ノード３０４は、選択された通信プロトコルに基づき、データ転送を開始する。
【０１３９】
一方、デスティネーション・ノード３０４の状態が、上記SET CCR control commandに対応できない場合には、デスティネーション・ノード３０４は、コントローラ３００に対してREJECTED responseを返す。この場合、データ転送は開始されず、論理的な接続も開放され、各ノードは始めから再びネゴシエーションを開始する。
【０１４０】
以上の手順からなるネゴシエーションにより、コントローラ３００は、ソース・ノード３０２とデスティネーション・ノード３０４との間のコネクションと、該コネクションが使用する通信プロトコルとを設定することができる。尚、図９では、デスティネーション・ノードが１つの場合について説明したが、デスティネーション・ノードが複数個の場合には、上述の処理を各デスティネーション・ノードに対して行えばよい。この場合、コントローラ３００は、対象となる全てのノードの通信能力に応じて使用可能な通信プロトコルを選択する。
【０１４１】
次に、本実施例の第１の通信プロトコルに基づくデータ転送について説明する。
第１の通信プロトコルは、ブロードキャスト通信を利用し、マルチキャスト通信を実現する通信プロトコルである。
【０１４２】
第１の通信プロトコルにおいて、１つのオブジェクトデータは１つ以上のセグメントに分割され、各セグメントは１つ以上の「Asynchronous broadcast packet」にパケッタイズされ、各Asynchronous broadcast packetは「Asynchronous broadcast transaction」によりブロードキャスト転送される。ここで、Asynchronous broadcast packetとAsynchronous broadcast transactionとは、本実施例の第１の通信プロトコルにおいて規定する全く新規なパケット・フォーマットであり、転送方法である。
【０１４３】
以下、図１０、１２を用いて、第１の通信プロトコルに基づく転送手順について詳細に説明する。図１０は、１つのソース・ノードと１つのデスティネーション・ノードとの間の転送手順を説明するシーケンスチャートである。又、図１２は、１つのソース・ノードと３つのデスティネーション・ノード３０４との間の転送手順を説明するシーケンスチャートである。
【０１４４】
上述のネゴシエーションの終了後、コントローラ３００は、ソース・ノード３０２に対してオブジェクトデータ３０８の転送を開始するように指示する（図１０、１２の１００１）。
転送開始の指示を受けた後、ソース・ノード３０２は、１つ以上のデスティネーション・ノード３０４に対して、send request packetをAsynchronous broadcast transactionにより転送する（図１０、１２の１００２）。このsend request packetには、コントローラ３００によりセットされたコネクションＩＤが格納されている。
【０１４５】
send request packetを受信したデスティネーション・ノード３０４は、そのsend request packetのもつコネクションＩＤを、先のネゴシエーションにおいてiCCRにセットされたコネクションＩＤと比較する。両者が一致する場合、デスティネーション・ノード３０４はそのsend request packetを受信し、それに対応するack response packetをAsynchronous broadcast transactionにより転送する（図１０、１２の１００３）。ここで、このack response packetには、各デスティネーション・ノード３０４の確保できる内部バッファのサイズが格納されている。
【０１４６】
ack response packetの受信後、ソース・ノード３０２は、Asynchronous broadcast transactionを実行し、１つ以上のセグメントからなるオブジェクトデータ３０８を順次ブロードキャストする（図１０、１２の１００４〜１００７）。
【０１４７】
ここで、図１３を用いて、オブジェクトデータ３０８の転送手順の一例を説明する。図１３において、オブジェクトデータ３０８は、例えばデータサイズが１２８Ｋｂｙｔｅとなる静止画像データである。
【０１４８】
ソース・ノード３０２は、send request packetを用いて認識した各デスティネーション・ノード３０４の受信能力に応じてオブジェクトデータ３０８を１つ以上のセグメントに分割する。ここで、１セグメントのデータサイズは、各デスティネーション・ノード３０４の有する内部バッファのサイズによりソース・ノード３０２が可変的に設定する。例えば、図１３のように、オブジェクトデータ３０８と同じサイズの内部バッファを各デスティネーション・ノードに確保できた場合、ソース・ノード３０２は、オブジェクトデータ３０８を１つのセグメントに分割する。
【０１４９】
次に、ソース・ノード３０２は、各セグメントを１つ以上のセグメントデータに分割する。図１３には、１セグメントを例えば５００個のセグメントデータ（１セグメントデータは２５６ｂｙｔｅ）に分割する例を示す。
【０１５０】
ソース・ノード３０２は、各セグメントを少なくとも一回のAsynchronous broadcast transactionを用いて順次ブロードキャストする。図１３には、１セグメントデータを一回のAsynchronous broadcast transactionを用いて転送する例を示す。
【０１５１】
１セグメントの全てを転送した後、次のセグメントがあれば、ソース・ノード３０２はそのセグメントの転送を準備し、なければ各デスティネーション３０４とのデータ通信を終了する（図１０、１２の１００８、１００９）。
【０１５２】
次に、図１０、１２を用いて、コントローラ３００の動作について詳細に説明する。
コントローラ３００は、ソース・ノード３０２に対して送信コマンドパケット（transaction command packet）をＡｓｙｎｃｈｒｏｎｏｕｓ転送する（図１０、１２の１００１）。
【０１５３】
送信コマンドパケットを受信したソース・ノード３０２は、コントローラ３００から通知されたコネクションＩＤを用いて初期設定を行い（図１０、１２の１００２、１００３）、Asynchronous broadcast transactionを実行する（図１０、１２の１００４〜１００７）。このAsynchronous broadcast transactionにより、ソース・ノード３０２は、１つ以上のセグメントからなるオブジェクトデータ３０８を順次転送することができる。
【０１５４】
尚、本実施例の第１の通信プロトコルにおいて、コントローラ３００は、コネクションの接続、非接続を管理する機能を提供するものである。従って、コネクション設定後におけるオブジェクトデータ３０８の転送は、ソース・ノード３０２とデスティネーション・ノード３０４との間のネゴシエーションにより実行される。
【０１５５】
一連のAsynchronous broadcast transactionが終了した後、ソース・ノード３０２は、segment endを示すAsynchronous broadcast packet（以下、segment end packet）をブロードキャストする（図１０、１２の１００８）。
【０１５６】
コントローラ３００は、ソース・ノード３０２からのsegment end packetを受け取った後、コネクションを解放してデータ転送を終了する。
ここで、segment end packetは、ブロードキャストされるため、そのパケットの内容はデスティネーション・ノード３０４においても検出することができる。従って、コントローラ３００ではなく、デスティネーション・ノード３０４自体が、ソース・ノード３０２とのコネクションを解放するように構成してもよい。
【０１５７】
次に、図１０、１２を用いて、ソース・ノード３０２の動作について詳細に説明する。
コントローラ３００からのtransaction command packetを受け取ったソース・ノード３０２は、各デスティネーション・ノード３０４に対して上述のsend request packetを送出する（図１０、１２の１００２）。
【０１５８】
ここで、send request packetは、オブジェクトデータ３０８のAsynchronous broadcast transactionを開始する前に必要な初期情報を得るためのリクエストパケットである。このパケットには、コントローラ３００によって指定されたコネクションＩＤが書き込まれている。
【０１５９】
デスティネーション・ノード３０４は、send request packetに対応するレスポンスであるack response packetをブロードキャストする（図１０、１２の１００３）。ここで、ack response packetには、send request packetと同じコネクションＩＤが格納されている。従って、ソース・ノード３０２は、受信パケットのコネクションＩＤを確認することによって、どのコネクションを介して転送されたack response packetであるかを識別することができる。
【０１６０】
ここで、ack response packetには、各デスティネーション・ノード３０４に確保されている内部バッファのサイズが格納されている。ack response packetの受信後、ソース・ノード３０２は、各デスティネーション・ノード３０４のメモリ空間を共通に指定するデスティネーション・オフセットを用いて、Asynchronous broadcast transactionを開始する。ここで、このデスティネーション・オフセットは、上述のネゴシエーション時に、コントローラ３００から指示されたアドレスである。
【０１６１】
次にソース・ノード３０２は、最初のAsynchronous broadcast packetを、上述のデスティネーション・オフセットが示すメモリ空間に対して書き込む（図１０、１２の１００４）。このパケットには、コネクションＩＤ、セグメントデータのシークエンス番号が格納されている。
【０１６２】
最初のAsynchronous broadcast packetを送信した後、ソース・ノード３０２は、デスティネーション・ノード３０４からのレスポンス・パケットを待機する。デスティネーション・ノード３０４からは、コネクションＩＤとシークエンス番号とを格納したレスポンス・パケットがAsynchronous broadcast packetの形式で送出される。このレスポンス・パケットを受け取った後、ソース・ノード３０２は、シークエンス番号をインクリメントし、次のセグメントデータを含むAsynchronous broadcast packetを転送する（図１０、１２の１００５）。
【０１６３】
この手順を繰り返して、ソース・ノード３０２は順次Asynchronous broadcast transactionを行う（図１０、１２の１００６〜１００７）。デスティネーション・ノード３０４からのレスポンスを待機する最大の時間はあらかじめ決められており、その時間を過ぎてもレスポンスが帰ってこない場合は、同一シークエンス番号を用いて、同一データを再送する。
【０１６４】
又、デスティネーション・ノード３０４から再送を要求するレスポンス・パケットが転送された場合、ソース・ノード３０２は、指定されたシークエンス番号のデータを再度ブロードキャストすることもできる。
【０１６５】
オブジェクトデータ３０８の全てをAsynchronous broadcast transactionを用いて転送した後、ソース・ノード３０２は、segment end packetをブロードキャストし、データ転送を終了する（図１０、１２の１００８）。
【０１６６】
尚、上述の実施例では、１セグメントデータのAsynchronous broadcast transactionに伴って必ずレスポンス・パケットを送出するように規定しているが、それに限るものではない。デスティネーション・ノード３０４の有するデータバッファが、複数の連続するセグメントデータによって満たされた後に、デスティネーション・ノード３０４がレスポンス・パケットの送信を行うように構成してもよい。
【０１６７】
次に、図１０、１２を用いて、デスティネーション・ノード３０４の動作について詳細に説明する。
上述のネゴシエーション後、デスティネーション・ノード３０４は、ソース・ノード３０２からのsend request packetを待機する（図１０、１２の１００２）。
【０１６８】
send request packetを受け取ったデスティネーション・ノード３０４は、そのパケットに書かれているコネクションＩＤとコントローラから通知されたコネクションIDを確認し、このパケットがソース・ノード３０２からのパケットであるかどうかを判別する。
【０１６９】
ソース・ノード３０２からのsend request packetを受信した後、各デスティネーション・ノード３０４は、コネクションＩＤ、確保できる内部バッファのサイズを書き込んだack response packetをブロードキャストする（図１０、１２の１００３）。
【０１７０】
ソース・ノード３０２から転送されたAsynchronous broadcast packetをメモリ空間に書き込んだ後、デスティネーション・ノード３０４は、そのパケットのコネクションＩＤを確認する。そのパケットに含まれるコネクションＩＤが自己のコネクションＩＤと一致する場合、コネクションＩＤとそのパケットに含まれるシークエンス番号とを格納したレスポンス・パケットをブロードキャストする（図１０、１２の１００４〜１００７）。この場合、受信パケットに含まれるセグメントデータは、内部バッファに格納される。ここで、受信パケットに含まれるコネクションＩＤが自己のコネクションＩＤと異なる場合、デスティネーション・ノード３０４は、その受信パケットを廃棄する。
【０１７１】
又、デスティネーション・ノード３０４は、受信パケットのシークエンス番号の不整合を検出した場合に、再送要求を示すレスポンス・パケットを送出することもできる。その場合、デスティネーション・ノード３０４は、再送を要求するシークエンス番号をソース・ノード３０２に通知する。
【０１７２】
全てのAsynchronous broadcast transactionを終了すると、ソース・ノード３０２からsegment end packetがブロードキャストされる。このパケットを受信すると、デスティネーション・ノード３０４はデータ転送プロセスを終了する（図１０、１２の１００８）。
【０１７３】
segment end packetを受信した後、デスティネーション・ノード３０４は、segment end packetを正常に受信したことを示すレスポンス・パケットをブロードキャストする（図１０、１２の１００９）。
【０１７４】
以上説明したように本実施例の通信システムは、従来の通信方式の不便利性を解決することができる。又、リアルタイム性を必要としないデータ転送においても、簡便に高速にデータを転送することができる。
【０１７５】
又、本実施例では、コントローラ３００がコネクションを設定した後、オブジェクトデータの転送処理は、コントローラ３００に制御されることなくソース・ノード３００と各デスティネーション・ノード３０４との間において実行される。これにより、コントローラ３００の負荷を減らし、複雑な通信手順を踏むことのない簡単な通信プロトコルを提供することができる。
【０１７６】
又、本実施例では、デスティネーション・ノード３０４は、各Asynchronous broadcast transactionに対して必ずレスポンスを返すように構成されている。これにより、リアルタイム性の必要としないデータを確実に転送することのできる通信プロトコルを提供することができる。
【０１７７】
より確実なデータ転送を実現するためには、バスリセットや何らかの伝送エラーの発生によってデータ転送が中断した場合において、データを欠落させることなく速やかにデータ転送を再開させることが必要である。以下、図１１を用いて、本実施例の通信プロトコルで規定する再開手順について説明する。
【０１７８】
例えば、シークエンス番号iのAsynchronous broadcast packetを受信した後にバスリセットが発生した場合、各ノードは転送処理を中断し、ＩＥＥＥ１３９４−１９９５規格で定められた手順に従ってバスの初期化、接続構成の認識、ノードＩＤの設定等を実行する（図１１の１０１０、１０１１）。
【０１７９】
バスの再構築が完了した後、各デスティネーション・ノード３０４は、コネクションＩＤとシークエンス番号ｉとを格納した再開要求パケット（resend request packet）をブロードキャストする（図１１の１０１２）。
【０１８０】
Asynchronous broadcast transactionの再開が可能な場合、ソース・ノード３０２は、受信したresend request packetのコネクションＩＤを確認し、このコネクションＩＤを格納したack response packetをブロードキャストする（図１１の１０１３）。
【０１８１】
その後、ソース・ノード３０２は、受信したresend request packetにより要求されたシークエンス番号以降のセグメントデータ、すなわち、シークエンス番号(i+1)で始まるセグメントデータを順次ブロードキャストする（図１１の１０１４）。
【０１８２】
前述の手順により、コントローラ３００、ソース・ノード３０２、デスティネーション・ノード３０４は、それぞれのノードＩＤを考慮することなく、データ転送が中断しても、その後のデータ転送を容易に、かつ、確実に再開することができる。
【０１８３】
又、前述のように、本実施例では、データ転送が中断した場合にも、コントローラ３００の制御手順が簡略化できる効果がある。
【０１８４】
次に、図１４を用いて第１の通信プロトコルで使用するAsynchronous broadcast packetの構成について説明する。Asynchronous broadcast packetは、例えば、１Ｑｕａｄｌｅｔ（４ｂｙｔｅｓ＝３２ｂｉｔｓ)を単位とするデータパケットである。
【０１８５】
まず、パケット・ヘッダ（ｐａｃｋｅｔｈｅａｄｅｒ）１２１９の構成を説明する。
図１４において、フィールド１２０１（１６ｂｉｔｓ）は、destination_IDを示し、受信先（即ち、デスティネーション・ノード３０４）のノードＩＤを示す。本実施例の通信プロトコルでは、オブジェクトデータ３０８のAsynchronous broadcast transactionを実現するため、このフィールドの値をブロードキャスト用ＩＤ（即ち、「ＦＦＦＦ16」）とする。
【０１８６】
フィールド１２０２（６ｂｉｔｓ）は、トランザクション・ラベル(tl)フィールドを示し、各トランザクション固有のタグである。
フィールド１２０３（２ｂｉｔｓ）は、リトライ(rt)コードを示し、パケットがリトライを試みるかどうかを指定する。
【０１８７】
フィールド１２０４（４ｂｉｔｓ）は、トランザクションコード(tcode)を示す。tcodeは、パケットのフォーマットや、実行しなければならないトランザクションのタイプを指定する。本実施例では、このフィールドの値を例えば「０００１2」とし、このパケットのデータ・ブロック５２２をdestination_offsetフィールド１２０７の示すメモリ空間に書き込む処理（即ち、ライト・トランザクション）をリクエストする。
【０１８８】
フィールド１２０５（４ｂｉｔｓ）は、プライオリティ(pri)を示し、優先順位を指定する。本実施例では、このフィールドの値は「００００2」とする。
フィールド１２０６（１６ｂｉｔｓ）は、source_IDを示し、送信側（即ち、ソース・ノード３０２）のノードＩＤを示す。
【０１８９】
フィールド１２０７（４８ｂｉｔｓ）は、destination_offsetを示し、各デスティネーション・ノード３０４の有するアドレス空間の下位４８ｂｉｔｓを共通に指定する。
フィールド１２０８（１６ｂｉｔｓ）は、data_lengthを示し、後述するデータフィールドの長さをバイト単位で示す。
【０１９０】
フィールド１２０９（１６ｂｉｔｓ）は、extended_tcodeを示す。本実施例では、このフィールドの値を「００００2」とする。
フィールド１２１０（３２ｂｉｔｓ）は、header_CRCを示し、上述したフィールド１２０１〜１２０９のエラーを検出するためのエラー検出コードが格納される。
【０１９１】
次に、データ・ブロック（ｄａｔａｂｌｏｃｋ）１２２０の構成を説明する。データ・ブロック１２２０は、ヘッダ・インフォメーション（ｐａｃｋｅｔｉｎｆｏｒｍａｔｉｏｎ）１２２１とデータ・フィールド（ｄａｔａｆｉｅｌｄ）１２２２とにより構成される。
【０１９２】
ヘッダ・インフォメーション１２２１には、各ノード間の論理的な接続関係（即ち、コネクション）を識別するためのコネクションＩＤなどが格納される。尚、ヘッダ・インフォメーション１２２１の構成は、使用目的に応じて異なる。
【０１９３】
又、データ・フィールド１２２２は可変長なフィールドであり、上述のセグメントデータが格納される。ここで、データ・フィールド１２２２に格納されるセグメントデータがクアッドレットの倍数でない場合、クアッドレットに満たない分には「０」が詰められる。
【０１９４】
フィールド１２１１（１６ｂｉｔｓ）は、connection_IDを示し、本実施例のコネクションＩＤを格納する。本実施例の１３９４インタフェースは、このフィールドに格納されたコネクションＩＤに基づいてソース・ノード３０２と１つ以上のデスティネーション・ノード３０４との間に設定されたコネクションを識別する。本実施例では、２16×（ノード数）のコネクションを確立することが可能となる。これにより、各コネクションの使用する通信帯域の総量が伝送路の容量に達するまで、複数のコネクションを設定することが可能となる。
【０１９５】
フィールド１２１２（８ｂｉｔｓ）は、protocol_typeを示し、ヘッダ・インフォメーション１２２１に基づく通信手順（即ち、通信プロトコルの種類）を示す。本実施例の通信プロトコルを示す場合、このフィールドの値は例えば「０１16」となる。
【０１９６】
フィールド１２１３（８ｂｉｔｓ）は、control_flagsを示し、本実施例の通信プロトコルの通信手順等を制御する所定の制御データが設定される。本実施例では、このフィールドの最上位ビットを、例えば、再送要求(resend_request)フラグとする。従って、このフィールドの最上位ビットの値が「１」となる場合、本実施例の通信プロトコルに基づく再送要求が生じていることを示す。
【０１９７】
フィールド１２１４（１６ｂｉｔｓ）は、sequence_numberを示し、特定のコネクションＩＤ（フィールド５１１で指定されたコネクションＩＤ）に基づいて転送されるパケットに対して連続的な値（即ち、シークエンス番号）を設定する。このシークエンス番号によって、デスティネーション・ノード３０４は、順次Asynchronous broadcast transactionされるセグメントデータの連続性を監視することができる。不一致が生じた場合、デスティネーション・ノード３０４は、このシークエンス番号に基づいて再送を要求することもできる。
【０１９８】
フィールド１２１５（１６ｂｉｔｓ）は、reconfirmation_numberを示す。本実施例においてこのフィールドは、上述の再送要求フラグの値が１である場合にのみ意味を持つ。例えば、上述の再送要求フラグの値が１である場合、このフィールドには、再送を要求するパケットのシークエンス番号が設定される。
【０１９９】
フィールド１２１６（１６ｂｉｔｓ）は、buffer_sizeを示す。このフィールドには、デスティネーション・ノード３０４のバッファ・サイズが設定される。
フィールド１２１７（１６ｂｉｔｓ）は、reservedフィールドである。このフィールドは、将来のために予約されている。
【０２００】
フィールド１２１８（３２ｂｉｔｓ）は、data_CRCを示し、上記のheader_CRCと同様に、フィールド１２１１〜１２１７のエラーを検出するためのエラー検出コードが格納される。
【０２０１】
尚、本実施例の第１の通信プロトコルでは、図１４に示すAsynchronous broadcast packetを用いて、上述のAsynchronous broadcast transactionを実現したがそれに限るものではない。例えば、図１５に示すAsynchronous stream packetを用いて実現することも可能である。この場合、上述のオブジェクトデータは、１つ以上のセグメントに分割され、各セグメントは１つ以上のAsynchronous stream packetにパケッタイズされる。そして、ソース・ノード３０２は、各Asynchronous stream packetを、Asynchronous転送期間内において順次ブロードキャスト転送する。ここで、Asynchronous stream packetのフォーマットと転送方法とは、ＩＥＥＥ１３９４−１９９５規格の拡張規格であるＩＥＥＥ１３９４．ａ規格において規定されている。
【０２０２】
図１５において、フィールド１２４０（１６ｂｉｔｓ）は、data_lengthフィールドである。このフィールドには、後述するデータ・フィールド１２４６の長さをバイト単位にデータが格納される。フィールド１２４１（２ｂｉｔｓ）は、tagフィールドである。このフィールドには、「００2」が格納される。
【０２０３】
フィールド１２４２（６ｂｉｔｓ）は、channelフィールドである。このフィールドには、このパケットを含む一連のAsynchronous stream packetに割り当てられたチャネル番号がセットされる。フィールド１２４３（４ｂｉｔｓ）は、トランザクション・コード（tcode）フィールドであり、Asynchronous stream packetであることを示す「Ａ16」を指定する。
【０２０４】
フィールド１２４４（４ｂｉｔｓ）は、synchronization code（sy）フィールドである。このフィールドには、使用するアプリケーションによって決定された制御コードが格納される。フィールド１２４５（３２ｂｉｔｓ）は、header_CRCである。このフィールドには、上述したフィールド１２４１〜１２４４のエラーを検出するためのエラー検出コードが格納される。
【０２０５】
フィールド１２４６（可変長）は、データ・フィールドである。このフィールドには、図１４に示すフィールド１２１１〜１２１７の値とセグメントデータとが格納される。ここで、フィールド１２４６に格納されるセグメントデータがクアッドレットの倍数でない場合、クアッドレットに満たない分には「０」が詰められる。フィールド１２４７（３２ｂｉｔｓ）は、data_CRCである。このフィールドには、上記のheader_CRCと同様に、フィールド１２４６のエラーを検出するためのエラー検出コードが格納される。
【０２０６】
次に、本実施例の第２の通信プロトコルについて説明する。
第２の通信プロトコルは、通信相手を特定した通信方式を利用し、ユニキャスト通信を実現する通信プロトコルである。
第２の通信プロトコルにおいて、１つのオブジェクトデータは１つ以上のセグメントに分割され、各セグメントは１つ以上の「Asynchronous write request packet」にパケッタイズされ、各Asynchronous write request packetは「Asynchronous write transaction」により転送される。ここで、Asynchronous write request packetとAsynchronous write transactionとは、ＩＥＥＥ１３９４−１９９５規格において規定するパケット・フォーマットであり、転送方法である。
【０２０７】
以下、図１６を用いて、第２の通信プロトコルに基づく転送手順について詳細に説明する。
上記ネゴシエーション（図９参照）が終わると、最初に、コントローラ３００は、デスティネーション・ノード３０４に、Receive Segment commandを発行する（１３０１）。受信準備ができ次第、デスティネーション・ノード３０４は、コントローラ３００に、INTERIM responseを発行して待機状態に入る（１３０２）。
【０２０８】
次に、コントローラ３００は、ソース・ノード３０２に、Send Segment commandを発行する（１３０３）。ソース・ノード３０２は、コントローラ３００に、INTERIM responseを発行してデータ送信状態に入る（１３０４）。
【０２０９】
データ送信状態に入った後、ソース・ノード３０２は、Asynchronous write transactionを用いて、所望のオブジェクトデータ３０８をデスティネーション・ノード３０４に送信する（１３０５〜１３０８）。
【０２１０】
ここで、図１３を用いて、オブジェクトデータ３０８の転送手順の一例を説明する。図１３において、オブジェクトデータ３０８は、例えばデータサイズが１２８Ｋｂｙｔｅとなる静止画像データである。
【０２１１】
ソース・ノード３０２は、オブジェクトデータ３０８を１つ以上のセグメントに分割する。例えば、オブジェクトデータ３０８と同じサイズの内部バッファをデスティネーション・ノード３０４に確保できた場合、ソース・ノード３０２は、オブジェクトデータ３０８を１つのセグメントに分割する。
【０２１２】
次に、ソース・ノード３０２は、コントローラ３００から指示されたoCCRのpayload_sizeフィールド５１４の内容を検出し、各セグメントを１つ以上のセグメントデータに分割する。図１３には、１セグメントを５００個のセグメントデータ（１セグメントデータは２５６ｂｙｔｅ）に分割する例を示す。ここで、payload_sizeフィールド５１４の内容は、コントローラ３００によりセットされる。
【０２１３】
次に、ソース・ノード３０２は、各セグメントを少なくとも一回のAsynchronous write transactionを用いて順次転送する。図１３には、１セグメントデータを一回のAsynchronous write transactionを用いて転送する例を示す。
【０２１４】
１回以上のAsynchronous write transactionにより順次転送されたデータの総量が、receive_buffer_sizeフィールド６１４に設定された値（即ち、内部バッファの容量）に達した場合、ソース・ノード３０２は、上記Send Segment commandに対するACCEPTED responseをコントローラ３００に対して発行する（１３０９）。
【０２１５】
次に、デスティネーション・ノード３０４は、上記Receive Segment commandに対するACCEPTED responseをコントローラ３００に対して発行し、１セグメント分のデータ転送が完了したことを通知する（１３１０）。次のセグメントがある場合、コントローラ３００、ソース・ノード３０２、及びデスティネーション・ノード３０４は、上述の手順を繰り返し行う。
【０２１６】
これにより、ソース・ノード３０２は、Asynchronous write transactionを用いて、所望のオブジェクトデータ３０８をデスティネーション・ノード３０４に対して確実に送信することができる。
【０２１７】
以上説明したように上述の各実施例では、物理的な接続形態に依存しない論理的な接続関係をＩＥＥＥ１３９４−１９９５規格のようなバス型ネットワーク内に構築することができる。
【０２１８】
又、本実施例では、ＩＥＥＥ１３９４−１９９５規格に準拠した通信システムにおいて、リアルタイム性は必要とされないが、信頼性が要求される比較的データ量の多いオブジェクトデータ（例えば、静止画像データ、グラフィックスデータ、テキストデータ、ファイルデータ、プログラムデータ等）を、１以上のセグメントに分割し、各セグメントを１つ以上のＡｓｙｎｃｈｒｏｎｏｕｓ転送を用いて順次転送する全く新規な通信プロトコルを提供することができる。
【０２１９】
又、本実施例では、ＩＥＥＥ１３９４−１９９５規格に準拠した通信システムにおいて、複数の機器間のデータ通信を、Ａｓｙｎｃｈｒｏｎｏｕｓ転送方式によるブロードキャスト通信を用いて実現する全く新規な通信プロトコルを提供することもできる。
【０２２０】
更に本実施例では、ＩＥＥＥ１３９４−１９９５規格に準拠した通信システムにおいて、複数の異なる通信プロトコルが存在した場合でも、使用可能な通信プロトコルを自動的に判別し、使い分けることができる。
【０２２１】
なお、上述の各実施例において説明した通信プロトコル及びそれを実現するために必要な各種の処理動作は、ソフトウェアによって実現することも可能である。
例えば、上述の実施例の機能を実現するためのプログラムコードを記憶した記憶媒体を、各実施例の通信システムを構成する機器の制御部（例えば、図１のＭＰＵ１２、システムコントローラ５０、プリンタコントローラ６８）に供給するように構成する。そして、その制御部が、該記憶媒体に格納されたプログラムコードを読み出し、そのプログラムコードに従って各実施例の機能を実現するように通信システム或いは機器自体の動作を制御するように構成しても、上述の実施例を実現することができる。
【０２２２】
又、上述の実施例の機能を実現するためのプログラムコードを記憶した記憶媒体を、各機器の具備する１３９４インタフェース１４、４４、６２に供給し、該１３９４インタフェース１４、４４、６２の動作を制御する制御部（例えば、図２のシリアル・バス・マネージメント２０６）が、該記憶媒体に記憶されたプログラムコードに従って各実施例の機能を実現するように処理動作を制御するように構成してもよい。
【０２２３】
この場合、上述の記憶媒体から読み出されたプログラムコード自体が各実施例の機能を実現することになり、そのプログラムコード自体及びそのプログラムコードを制御部に供給するための手段（例えば、記憶媒体自体）は本発明を構成する。
【０２２４】
かかるプログラムコードを記憶する記憶媒体としては、例えば、フロッピディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【０２２５】
又、上述の記憶媒体から読み出されたプログラムコードが、上述の制御部上で稼動しているＯＳ（オペレーティングシステム）或いは各種のアプリケーションソフト等と共同して、各実施例の機能を実現する場合も本発明に含まれることは言うまでもない。
【０２２６】
更に、上述の記憶媒体から読み出されたプログラムコードを、上述の制御部に接続された機能拡張ユニットに備わるメモリに格納した後、その機能拡張ユニットに備わる制御部が、該メモリに格納したプログラムコードに従って実際の処理の一部或いは全てを行い、その処理によって各実施例の機能を実現する場合も本発明に含まれることは言うまでもない。
【０２２７】
尚、本発明はその精神、又は主要な特徴から逸脱することなく、他の様々な形で実施することができる。
例えば、本実施例のコントローラ３００は、ソース・ノード３０２のoMCRとデスティネーション・ノード３０４のiMCRとを読み出す際、図７に示すREAD MCR status commandを各ノードに発行するように構成したがそれに限るものではない。oMCR、iMCRのアドレスを予め特定のアドレスとなるように構成しておけば、コントローラ３００は、各レジスタの内容を、ＩＥＥＥ１３９４−１９９５規格のAsynchronousリード・トランザクションを用いて読み出すこともできる。
【０２２８】
このように構成した場合、本実施例の１３９４インタフェースは、図９に示すネゴシエーションの処理の一部を、図２に示すトランザクション・レイヤよりも上位のレイヤに影響を与えることなく実現することができる。これにより、本実施例の１３９４インタフェースは、アプリケーション・レイヤに対する負荷を少なくすることができ、ハードウェア化が容易になる。
【０２２９】
又、本実施例のコントローラ３００は、ソース・ノード３０２のoCCRとデスティネーション・ノード３０４のiCCRに所定の値を書き込む際、図８に示すSET CCR control commandを各ノードに発行するように構成したがそれに限るものではない。oCCR、iCCRのアドレスを予め特定のアドレスとなるように構成しておけば、コントローラ３００は、各レジスタの内容を、ＩＥＥＥ１３９４−１９９５規格のAsynchronousリード・ライト・コンペア・スワップ・ロック・トランザクションを用いて書き込むこともできる。
【０２３０】
このように構成した場合、本実施例の１３９４インタフェースは、ロック・トランザクションに対する応答により、図９に示すネゴシエーションの処理の一部を実現することができる。これにより、本実施例の１３９４インタフェースは、トランザクション・レイヤにおける応答により上述の処理を実現できるため、処理速度をより一層向上されることができる。又、アプリケーション・レイヤに対する負荷を少なくすることができ、ハードウェア化が容易になる。
【０２３１】
又、本実施例では、コントローラ３００が２種類の異なる通信プロトコルを選択する構成及び手順について説明したが、２種類以上の通信プロトコルの中から選択するように構成してもよい。この場合、各ノードは、oMCRのreservedフィールド５０３或いはiMCRのreservedフィールド５０６を用いて各通信プロトコルのサポート状態を示すことができる。
【０２３２】
更に、本実施例では、ＩＥＥＥ１３９４−１９９５規格に準拠したネットワークに適用可能な通信プロトコルについて説明したがそれに限るものではない。本実施例の通信プロトコルは、ＩＥＥＥ１３９４−１９９５規格のようなバス型ネットワークやバス型ネットワークを仮想的に構成できるネットワークに適用することもできる。
【０２３３】
従って、前述の各実施例ではあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。
本発明の範囲は特許請求の範囲によって示すものであって、明細書本文には何等拘束されない。更に、特許請求の範囲の均等範囲に属する変形や変更はすべて本発明の範囲のものである。
【０２３４】
【発明の効果】
本発明によれば、複数の異なる通信プロトコルが存在する場合でも、使用可能な通信プロトコルに選択することができる。
【図面の簡単な説明】
【図１】本実施例の通信システムの構成例を示すブロック図である。
【図２】本実施例の１３９４インターフェースの構成を説明する図である。
【図３】本実施例の第１、第２の通信プロトコルの基本構成を説明する概念図である。
【図４】各ノードの有するアドレス空間を説明する図である。
【図５】本実施例のソース・ノードの有する出力レジスタ（oMCRとoCCR）の構成を説明する図である。
【図６】本実施例のデスティネーション・ノードの有する入力レジスタ（iMCRとiCCR）の構成を説明する図である。
【図７】  MCR、iMCRの内容を読み出すためのコマンドの構成を示す図である。
【図８】  CCR、iCCRに所定の値を書き込むためのコマンドの構成を示す図である。
【図９】ソース・ノードとデスティネーション・ノードとの間で使用する通信プロトコルを設定するまでの手順について説明するシーケンスチャートである。
【図１０】本実施例の第１の通信プロトコルについて説明するシーケンスチャートで、１つのソース・ノードと１つのデスティネーション・ノードとの間の転送手順を説明する図である。
【図１１】本実施例の第１の通信プロトコルについて説明するシーケンスチャートで、通信プロトコルで規定する再開手順について説明する図である。
【図１２】本実施例の第１の通信プロトコルについて説明するシーケンスチャートで、１つのソース・ノードと３つのデスティネーション・ノード３０４との間の転送手順を説明する図である。
【図１３】第１の通信プロトコルによる通信オブジェクトデータの転送手順を説明する図である。
【図１４】第１の通信プロトコルにて使用されるデータパケットの構成を示す図である。
【図１５】第１の通信プロトコルにて使用されるデータパケットの構成を示す図である。
【図１６】本実施例の第２の通信プロトコルについて説明するシーケンスチャートである。
【符号の説明】
１０        コンピュータ
１２        演算処理装置
１４        １３９４インターフェース
１６        操作部
１８        デコーダ
２０        表示部
２２        ハードディスク
２４        内部メモリ
２６        内部バス
２８        カメラ一体型デジタルビデオレコーダ
３０        撮像部
３２        Ａ／Ｄ変換器
３４        画像処理部
３６        圧縮／伸長処理部
３８、４０  メモリ
４２        データセレクタ
４４        １３９４インターフェース
４６、４８  メモリ制御部
５０        制御部
５２        操作部
５４        電子ビューファインダ
５６        Ｄ／Ａ変換器
５８        記録再生部
６０        プリンタ
６２        １３９４インターフェース
６４        データセレクタ
６６        操作部
６８        プリンタコントローラ
７０        デコーダ
７２        内部メモリ
７４        画像処理部
７６        ドライバ
７８        プリンタヘッド
３００      コントローラ
３０２      ソース・ノード
３０４      デスティネーション・ノード
【図１】
0004181688.tif 000004
【図２】
0004181688.tif 000005
【図３】
0004181688.tif 000006
【図４】
0004181688.tif 000007
【図５】
0004181688.tif 000008
【図６】
0004181688.tif 000009
【図７】
0004181688.tif 000010
【図８】
0004181688.tif 000011
【図９】
0004181688.tif 000012
【図１０】
0004181688.tif 000013
【図１１】
0004181688.tif 000014
【図１２】
0004181688.tif 000015
【図１３】
0004181688.tif 000016
【図１４】
0004181688.tif 000017
【図１５】
0004181688.tif 000018
【図１６】
0004181688.tif 000019