JP4059423B2 - データ伝送システム、コネクション回復方法及び情報伝送装置 - Google Patents
データ伝送システム、コネクション回復方法及び情報伝送装置 Download PDFInfo
- Publication number
- JP4059423B2 JP4059423B2 JP2001005649A JP2001005649A JP4059423B2 JP 4059423 B2 JP4059423 B2 JP 4059423B2 JP 2001005649 A JP2001005649 A JP 2001005649A JP 2001005649 A JP2001005649 A JP 2001005649A JP 4059423 B2 JP4059423 B2 JP 4059423B2
- Authority
- JP
- Japan
- Prior art keywords
- connection
- processing
- recovery
- connection recovery
- bus
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40058—Isochronous transmission
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40065—Bandwidth and channel allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L12/40052—High-speed IEEE 1394 serial bus
- H04L12/40071—Packet processing; Packet format
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Information Transfer Systems (AREA)
- Small-Scale Networks (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、複数の情報伝送機器がバス上のノードに接続され、各ノード間でコネクションを確立してデータを伝送するデータ伝送システムに関し、特に、ＩＥＥＥ１３９４（IEEE（Institute of Electrical and Electronic Engineers）Std.1394-1995 IEEE Standard for a High Performance serial Bus）規格に準拠したシリアルバスにおいて、バスリセット発生時にコネクション回復処理を実行するデータ伝送システム、コネクション回復方法及び情報伝送装置の技術分野に属するものである。
【０００２】
【従来の技術】
近年、ＡＶ機器やコンピュータ周辺機器が互いにディジタルデータを伝送するインターフェース規格として上記ＩＥＥＥ１３９４規格が注目されている。このＩＥＥＥ１３９４規格は、高速な転送速度でデータを転送でき、トポロジー接続の自由度が高く、アイソクロナス転送によりリアルタイムデータの転送に好適であるなど様々なメリットがあり、従来のインターフェース規格と比べても有用性が高い。
【０００３】
また、ＩＥＥＥ１３９４規格では、一般ユーザの利用状況を考慮して、電源を入れたままでの機器の活線挿抜をサポートしている。そのため、バスのトポロジー接続が変更されたときにバスリセットを発生させ、ノード間で確立されたコネクションをいったん解除するが、バスリセットから１秒間はそれまでのデータ伝送を維持する。よって、この１秒間に各ノードが元のコネクションを回復させる処理を実行する必要がある。
【０００４】
【発明が解決しようとする課題】
しかしながら、ＩＥＥＥ１３９４バス上の各ノードに接続される機器には、入力プラグと出力プラグをそれぞれ複数設定可能であり、コネクションの種別もBroadcast-inコネクション、Broadcast-outコネクション、Point-to-pointコネクションなど多様であるため、バスリセット時に実行すべきコネクション回復処理は複雑になる。一方、各コネクション回復処理に含まれる個別の処理において、例えば、チャンネルや帯域の確保に失敗したり、入出力プラグのレジスタの更新に失敗する場合が想定される。そのため、これらの個別の処理を成功するまで実行し続けることになると、特定のコネクション回復処理で時間を要するために、それ以外のコネクション回復処理に必要な時間が不足する場合がある。その結果、回復可能なコネクションが未回復のままバスリセット後の１秒間が経過する可能性があり、正常なコネクションの回復に支障を来すおそれがある。
【０００５】
そこで、本発明はこのような問題に鑑みなされたものであり、バスリセット時に回復すべきコネクションが多数ある場合であっても、１つのコネクション回復処理に制約されることなく全体のコネクション回復処理を迅速に進行でき、処理効率及び信頼性を向上させることができるコネクション回復方法を提供するとともに、かかるコネクション回復方法を実行可能なデータ伝送システムを構築することを目的とする。
【０００６】
【課題を解決するための手段】
上記の課題を解決するために、請求項１に記載のデータ伝送システムは、複数の情報伝送機器がバス上のノードに接続され、各ノード間でコネクションを確立してデータを伝送するデータ伝送システムにおいて、バスリセット発生に伴い前記確立されたコネクションが解除されたとき、所定時間が経過するまでに、それぞれのノードにおいて前記コネクションを回復するコネクション回復制御手段を備え、前記コネクション回復制御手段は、前記コネクションの種別に対応する複数のコネクション回復処理の実行順を制御するとともに、前記それぞれのコネクション回復処理を複数の処理プロセスに分割し、前記実行順に対応するコネクション回復処理に際し所定の処理プロセスを前記コネクションの回復状態に基づいて選択的に順次実行し、前記コネクション回復処理の実行順を登録された登録手段を参照することにより前記実行順を制御し、前記コネクションの回復状態に応じて前記登録手段の内容を適宜更新することを特徴とする。
【０００７】
また、請求項７に記載のコネクション回復方法は、複数の情報伝送機器がバス上のノードに接続され、各ノード間でコネクションを確立してデータを伝送するデータ伝送システム上で、バスリセット発生に伴い前記確立されたコネクションが解除されたとき、所定時間が経過するまでに、それぞれのノードにおいて前記コネクションを回復するコネクション回復方法において、前記コネクションの種別に対応する複数のコネクション回復処理の実行順を制御するとともに、前記それぞれのコネクション回復処理を複数の処理プロセスに分割し、前記実行順に対応するコネクション回復処理に際し所定の処理プロセスを前記コネクションの回復状態に基づいて選択的に順次実行し、前記コネクション回復処理の実行順を登録された登録手段を参照することにより前記実行順を制御し、前記コネクションの回復状態に応じて前記登録手段の内容を適宜更新することを特徴とする。
【０００８】
また、請求項１１に記載の情報伝送装置は、バス上のノードに接続可能で、他ノードとの間でコネクションを確立してデータを伝送する情報伝送装置において、バスリセット発生に伴い前記確立されたコネクションが解除されたとき、所定時間が経過するまでに、前記コネクションを回復するコネクション回復制御手段を備え、前記コネクション回復制御手段は、前記コネクションの種別に対応する複数のコネクション回復処理の実行順を制御するとともに、前記それぞれのコネクション回復処理を複数の処理プロセスに分割し、前記実行順に対応するコネクション回復処理に際し所定の処理プロセスを前記コネクションの回復状態に基づいて選択的に順次実行し、前記コネクション回復処理の実行順を登録された登録手段を参照することにより前記実行順を制御し、前記コネクションの回復状態に応じて前記登録手段の内容を適宜更新することを特徴とする。
【０００９】
請求項１、７、１１にそれぞれ記載の発明によれば、データ伝送システムにおいて例えば情報伝送機器の接続状態の変更によりバスリセットが発生すると、所定時間内に各ノードを結ぶコネクションを回復させるための処理が開始される。処理対象のコネクション回復処理は実行順を制御されつつ、更に複数の処理プロセスに分割され、その中からコネクションの回復状態に対応して特定の処理プロセスが実行される。このように、処理時間を細分化して個別の処理を交互に切り換えて制御するので、複数のコネクション回復処理を並列実行するのと同様の効果があり、１つのコネクションが回復困難になった場合でも、それにより停滞することなく他のコネクション回復処理を進行できる。よって、時間を有効に活用してコネクション回復の処理効率を向上させることができる。
【００１３】
請求項１、７、１１にそれぞれ記載の発明によれば、コネクション回復処理の実行順の制御に際し登録手段を参照するようにしたので、簡易かつ確実に上記の制御を行うことができるとともに、登録手段の内容を更新可能としたので、処理の進行状況に応じて実行順を自在に可変することができる。
【００１４】
請求項２に記載のデータ伝送システムは、請求項１に記載のデータ伝送システムにおいて、前記バス上の各ノードには、前記コネクションの回復状態及び選択対象の前記処理プロセスを含むコネクション情報を更新可能に保持するコネクション情報記録手段が設けられることを特徴とする。
【００１５】
また、請求項１２に記載の情報伝送装置は、請求項１１に記載の情報伝送装置において、前記コネクションの回復状態及び選択対象の前記処理プロセスを含むコネクション情報を更新可能に保持するコネクション情報記録手段が設けられることを特徴とする。
【００１６】
請求項２と請求項１２にそれぞれ記載の発明によれば、コネクション回復処理に際し、コネクション情報記録手段にはコネクションの回復状態と選択対象の処理プロセスが記録されるので、状況に応じて次に実行すべき処理内容を的確に判断することができる。
【００１７】
請求項３に記載のデータ伝送システムは、請求項１に記載のデータ伝送システムにおいて、前記複数の処理プロセスには、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれることを特徴とする。
【００１８】
また、請求項８のコネクション回復方法は、請求項７に記載のコネクション回復方法において、前記複数の処理プロセスには、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれることを特徴とする。
【００１９】
また、請求項１３に記載の情報伝送装置は、請求項１１に記載の情報伝送装置において、前記複数の処理プロセスには、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれることを特徴とする。
【００２０】
請求項３、８、１３にそれぞれ記載の発明によれば、コネクション回復処理では、チャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスを分割実行するので、各々の処理時間を短縮して一層処理効率を向上させることができる。
【００２１】
請求項４に記載のデータ伝送システムは、請求項３に記載のデータ伝送システムにおいて、前記バスはＩＥＥＥ１３９４規格に準拠したシリアルバスであり、前記複数のコネクション回復処理には、Broadcastoutコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする。
【００２２】
また、請求項９に記載のコネクション回復方法は、請求項７に記載のコネクション回復方法において、前記バスはＩＥＥＥ１３９４規格に準拠したシリアルバスであり、前記複数のコネクション回復処理には、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする。
【００２３】
また、請求項１４に記載の情報伝送装置は、請求項１３に記載の情報伝送装置において、前記バスはＩＥＥＥ１３９４規格に準拠したシリアルバスであり、前記複数のコネクション回復処理には、Broadcastoutコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする。
【００２４】
請求項４、９、１４にそれぞれ記載の発明によれば、汎用的でディジタルデータ伝送に好適なＩＥＥＥ１３９４規格を用いて、上記３つのコネクション回復処理を上述のように制御するので、情報伝送機器の活線挿抜が行われる際のバスリセットが頻繁に発生するＩＥＥＥ１３９４バスシステムの信頼性及び処理効率を高めることができる。
【００２５】
請求項５に記載のデータ伝送システムは、請求項４に記載のデータ伝送システムにおいて、前記複数の処理プロセスには、送信側の出力プラグのｏＰＣＲを更新する処理プロセスと、受信側の入力プラグのｉＰＣＲを更新する処理プロセスが含まれることを特徴とする。
【００２６】
また、請求項１０に記載のコネクション回復方法によれば、請求項９に記載のコネクション回復方法において、前記複数の処理プロセスには、送信側の出力プラグのｏＰＣＲを更新する処理プロセスと、受信側の入力プラグのｉＰＣＲを更新する処理プロセスが含まれることを特徴とする。
【００２７】
また、請求項１５に記載の情報伝送装置は、請求項１４に記載の情報伝送装置において、前記複数の処理プロセスには、送信側の出力プラグのｏＰＣＲを更新する処理プロセスと、受信側の入力プラグのｉＰＣＲを更新する処理プロセスが含まれることを特徴とする。
【００２８】
請求項５、１０、１５にそれぞれ記載の発明によれば、ＩＥＥＥ１３９４バスシステムにおけるコネクションの入出力プラグに対し、ｏＰＣＲを更新する処理プロセスと、ｉＰＣＲを更新する処理プロセスを分割実行するので、各々の処理時間を短縮して確実性を高めることができる。
【００２９】
請求項６に記載のデータ伝送システムは、請求項２に記載のデータ伝送システムにおいて、前記コネクション情報記録手段には、前記それぞれの情報伝送機器に固有のＩＤが保持され、前記コネクション回復制御手段は、前記ＩＤの取得処理の実行順を制御することを特徴とする。
【００３０】
また、請求項１６に記載の情報伝送装置は、請求項１４に記載の情報伝送装置において、前記コネクション情報記録手段には、バス上のノードに接続された情報伝送機器に固有のＩＤが保持され、前記コネクション回復制御手段は、前記ＩＤの取得処理の実行順を制御することを特徴とする。
【００３１】
請求項６と請求項１６にそれぞれ記載の発明によれば、ＩＥＥＥ１３９４バス上のノードに接続された情報伝送機器をＧＵＩＤを参照して特定することできので、コネクション回復処理の確実性を高めることができる。
【００３２】
【発明の実施の形態】
以下、本発明の好適な実施形態を図面に基づいて説明する。本実施形態においては、データ転送のインターフェース規格としてＩＥＥＥ１３９４を採用したデータ転送システムに対して本発明を適用した場合について説明する。
【００３３】
図１は、ＩＥＥＥ１３９４のプロトコルの構成を示すブロック図である。ＩＥＥＥ１３９４のプロトコルは、図１に示すように、物理層１０、リンク層１１、トランザクション層１２の３つの層と、バス管理層１３とから構成される。一般に、物理層１０とリンク層１１はハードウェアで実現され、トランザクション層１２と、バス管理層１３はファームウェアで実現される。
【００３４】
物理層１０は、バスとの物理的・電気的インターフェースを行う層であり、信号のエンコードとデコードを行うエンコード／デコード部１０ａ、各ノード間のバス使用権の調停（アービトレーション）を行うバスアービトレーション部１０ｂ、バス上の媒体とのインターフェース動作を行うインターフェース部１０ｃを含んでいる。
【００３５】
リンク層１１は、パケットの送受信動作等を行う層であり、送受信の際のサイクル制御を行うサイクル制御部１１ａ、パケットの送信動作を行うパケット送信部１１ｂ、パケットの受信動作を行うパケット受信部１１ｃを含んでいる。また、同期データを送受信するためのアイソクロナス転送が行われる場合、リンク層１１とバスの間にアイソクロナスチャンネルが設定される。
【００３６】
トランザクション層１２は、上位のアプリケーションとリンク層１１の間の通信処理を制御する層であり、リンク層１１の動作を制御して指定されたノードとアドレスに対する読み出し又は書き込みを実行する。トランザクション層１２では、特定アドレスのデータを読み取るリードトランザクション、特定アドレスにデータを書き込むライトトランザクション、特定アドレスを参照して所定の条件に合致したとき更新するロックトランザクションをそれぞれ発行する。
【００３７】
バス管理層１３は、物理層１０、リンク層１１、トランザクション層１２の３層を制御し、ノード制御とバス資源管理のための基本的な機能を提供する。バス管理層１３には、バスの管理を行うバスマネージャ１３ａと、アイクロナスリソースの管理を行うアイソクロナス資源管理部１３ｂと、ＣＳＲ（Command and Status Register）アーキテクチャに基づいてノードを制御するノード制御部１３ｃを含んでいる。
【００３８】
上記のアイソクロナス資源管理部１３ｂは、アイソクロナス転送の能力を有するノードに対し少なくとも１つ設定されるＩＲＭ（Isochronous Resource Manager）に対応する。このＩＲＭは、ＣＳＲアーキテクチャに対応するＣＳＲ空間において、アイソクロナスリソースの管理に用いるレジスタを保有している。そして、ＣＳＲ空間には、アイソクロナス転送に必要となるレジスタとして、ＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタとＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタが設けられている。
【００３９】
上記のＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタは、アイソクロナスチャンネルの使用状況を表す６４ビットのレジスタであり、各チャンネルが１であれば使用中であり、０であれば未使用であることを表す６４チャンネル分のデータを保持している。また、上記のＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタは、アイソクロナス転送に使用可能な帯域を示す数値を格納するレジスタであり、１６００Ｍｂｐｓの転送速度で３２ビットのデータ転送に要する時間を１ユニット（約２０ｎｓｅｃ）とし、これを単位に表わされる。
【００４０】
ＩＥＥＥ１３９４のバス上の各ノードがアイソクロナス転送を行う際は、適正なチャンネル及び帯域を確保する必要がある。そのため、ロックトランザクションを発行することにより、ＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタを更新し、更にＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタを更新し、これによりチャンネル及び帯域を確保することができる。このとき、チャンネルと帯域が正常に確保される場合はロックトランザクションによるレジスタ更新に成功するが、チャンネル又は帯域が確保できない場合はロックトランザクションによるレジスタ更新に失敗することになる。
【００４１】
次に図２は、ＩＥＥＥ１３９４のバス上に接続された複数の情報伝送機器が相互にデータを伝送可能なデータ伝送システムの概念を示す図である。ＩＥＥＥ１３９４では、各情報伝送機器どうしの従来の物理的な信号接続に代わり、論理的な信号接続を行うためのプラグの概念が導入される。よって、ＩＥＥＥ１３９４のバス上でデータを送受信する際は、各情報伝送機器の仮想的なプラグを介して制御される。
【００４２】
図２においては、３台の情報伝送機器としてのＡＶ機器２１、２２、２３がＩＥＥＥ１３９４上に接続されている場合を例に示している。各ＡＶ機器２１〜２３は、データ出力に用いる出力プラグとデータ入力に用いる入力プラグとを仮想的に備えており、特定のＡＶ機器の出力プラグを経由してアイソクロナスデータがバス上に送出され、他のＡＶ機器の入力プラグを経由してアイソクロナスデータを受け取ることによりデータ転送を行うことができる。
【００４３】
図２に示すように、各ＡＶ機器２１、２２は、出力プラグの属性を制御する出力プラグ制御レジスタ（ｏＰＣＲ：output plug control register）と、ＡＶ機器のｏＰＣＲに共通の属性を制御する出力マスタープラグレジスタ（ｏＭＰＲ：output master plug register）を備えている。また、各ＡＶ機器２１、２３は、入力プラグの属性を制御する入力プラグ制御レジスタ（ｉＰＣＲ：input plug control register）と、ＡＶ機器のｉＰＣＲに共通の属性を制御する入力マスタープラグレジスタ（ｉＭＰＲ：input master plug register）を備えている。
【００４４】
なお、１つのＡＶ機器でプラグ数は最大３１個まで設定可能であるため、ｏＰＣＲとｉＰＣＲは、それぞれ１つのＡＶ機器において０個から最大３１個まで存在可能である。一方、１つのＡＶ機器においてｏＰＣＲとｉＰＣＲが多数存在する場合であっても、ｏＭＰＲとｉＭＰＲはそれぞれ１個存在するだけである。図２の例では、ＡＶ機器２１はｉＭＰＲ、ｉＰＣＲ、ｏＭＰＲ，ｏＰＣＲをそれぞれ１個づつ持ち、ＡＶ機器２２はｉＭＰＲ、ｉＰＣＲ、ｏＭＰＲをそれぞれ１個づつと２個のｏＰＣＲを持ち、ＡＶ機器２３は１個のｉＭＰＲと２個のｉＰＣＲを持っているとともに、各ＡＶ機器２１〜２３のプラグ間を結ぶ２系統のアイソクロナスチャンネルが確立されていることがわかる。
【００４５】
ここで、上記のｏＰＣＲ及びｉＰＣＲのデータフォーマットについて図３と図４を用いて説明する。図３に示すように、ｏＰＣＲのデータフォーマットは、出力プラグの接続がオン又はオフのいずれであるかを示すオンラインフラグと、出力プラグを経由する後述のbroadcastコネクションの個数を示すbroadcastコネクションカウンタと、出力プラグを経由する後述のPoint-to-pointコネクションの個数を示すPoint-to-pointコネクションカウンタと、将来の機能拡張用の予備領域と、アイソクロナスデータの転送に用いるチャンネルの番号を示すチャンネル番号と、データを転送する際の転送速度を表すデータ転送速度と、アイソクロナスデータに付加されるオーバーヘッド量を示すオーバーヘッドＩＤと、１サイクルごとに転送されるデータ量を示すペイロードを含んでいる。
【００４６】
また、図４に示すように、ｉＰＣＲのデータフォーマットは、入力プラグの接続がオン又はオフのいずれであるかを示すオンラインフラグと、入力プラグを経由する後述のbroadcastコネクションの個数を示すbroadcastコネクションカウンタと、入力プラグを経由する後述のPoint-to-pointコネクションの個数を示すPoint-to-pointコネクションカウンタと、将来の機能拡張用の２つの予備領域と、アイソクロナスデータの転送に用いるチャンネルの番号を示すチャンネル番号を含んでいる。
【００４７】
なお、上述のｏＰＣＲ及びｉＰＣＲのデータ内容を変更する場合、変更対象となるｏＰＣＲ又はｉＰＣＲを所有するＡＶ機器自らが変更することも可能であるとともに、他のＡＶ機器がＩＥＥＥ１３９４のバスを介してロックトランザクションを発行することにより変更することも可能である。このようなロックトランザクションを用いる場合、要求側から応答側にデータを転送するとともに、応答側の特定のアドレスでデータを処理した後、要求側に返送するという手順に従って処理が行われる。
【００４８】
一方、上述した通り、各ＡＶ機器間のアイソクロナスデータの転送は、図２に示すように、ＩＥＥＥ１３９４のバス上に設定されたアイソクロナスチャンネルを経由して行われる。このアイソクロナスチャンネルは、各ＡＶ機器の入力プラグと出力プラグを結び付けるパスとして機能し、上述のＰＣＲを適切に設定することにより所望のアイスクロナスチャンネルを設定することができる。各ＡＶ機器のアイソクロナスチャンネルへのコネクションの形態としては、Point-to-pointコネクションと、broadcastコネクションの２種類がある。
【００４９】
Point-to-pointコネクションは、特定のＡＶ機器の１つの出力プラグ（ｏＰＣＲ）と他のＡＶ機器の１つの入力プラグ（ｉＰＣＲ）とを、１つのアイソクロナスチャンネルに結び付けるコネクションの形態である。なお、１つのプラグに既に存在するpoint-to-pointコネクションに対し、別のPoint-to-point コネクションを存在させることも可能である。
【００５０】
また、Broadcastコネクションには、特定のＡＶ機器の１つの出力プラグ（ｏＰＣＲ）を１つのアイソクロナスチャンネルに結び付けるコネクションの形態であるBroadcast-outコネクション、及び、特定のＡＶ機器の１つの入力プラグ（ｉＰＣＲ）を１つのアイソクロナスチャンネルに結び付けるコネクションの形態であるBroadcast-inコネクションの２つがある。
【００５１】
次に、本実施形態におけるＩＥＥＥ１３９４バス上のデータ伝送システムでバスリセットが発生した場合の処理について説明する。データ伝送システムに対し、新たなノードがバスに接続されたり、接続中のノードがバスから外れたりする状況が生じた場合、バス上の全てのノードにバスリセット信号が伝送され、トポロジー情報はいったん全てクリアされ、状況の変化に応じた新たなトポロジーを構築するための初期化処理が実行される。
【００５２】
バスリセットが発生すると、各ノードのコネクションの確立時に取得されたアイソクロナスリソースやプラグが全てリセットされ、コネクションが解除されることになるが、バスリセット発生タイミングから１秒間はアイソクロナスデータの転送が継続される。よって、各ノードは、バスリセットが発生してから１秒以内に、新たなトポロジー情報に対応してアイソクロナスリソースの確保と各プラグの更新を行い、コネクションを回復するための処理を行う必要がある。ＩＥＥＥ１３９４バス上におけるコネクション回復処理は多数のプロセスからなり、実際にはアイソクロナスリソースの確保やトランザクションによるレジスタ更新に失敗する場合も想定されるので、１秒間ではコネクションが回復できないものも残る場合がある。本実施形態では、後述するように合理的な手順によりバスリセット時の回復不可能なコネクションを最低限に抑えることができる。
【００５３】
次に、図５〜１５を参照して、本実施形態におけるバスリセット時のコネクション回復処理について具体的に説明する。ここで、本実施形態ではＩＥＥＥ１３９４バス上のメモリ手段において各プラグのコネクション情報データベースを構成し、バスリセット時のコネクション回復処理において必要となる各種データを保持する。図５は、このようなコネクション情報データベースの構成を示す図である。図５に示すコネクション情報データベースは、本実施形態のコネクション情報記録手段としての役割を担い、各出力プラグに対応するｏＰＣＲ情報と、各入力プラグに対応するｉＰＣＲ情報と、各コネクションに対応するPoint-to-pointコネクション情報とを含んで構成される。
【００５４】
図５（ａ）に示すｏＰＣＲ情報は、Broadcast-outコネクションのステータスと、Broadcast-outコネクションの回復処理で実行すべき処理プロセスと、上記ｏＰＣＲ中のbroadcastコネクションカウンタ及びオーバーヘッドＩＤ（図３）を含んでいる。また、図５（ｂ）に示すｉＰＣＲ情報は、Broadcast-inコネクションのステータスと、ｉＰＣＲ中のbroadcastコネクションカウンタ（図４）を含んでいる。また、図５（ｃ）に示すPoint-to-pointコネクション情報は、Point-to-pointコネクションのステータスと、Point-to-pointコネクションの回復処理で実行すべき処理プロセスと、送信側ノードのＧＵＩＤ及びプラグＩＤと、受信側ノードのＧＵＩＤ及びプラグＩＤと、ｏＰＣＲ中のデータ転送速度、オーバーヘッドＩＤ、ペイロード、チャンネル番号（図３）を含んでいる。
【００５５】
コネクション情報データベースに含まれる各ステータスは、それぞれのコネクション回復処理についての回復状態に応じて変化し、コネクション回復処理の状態が有効であるときはＶＡＬＩＤ、無効であるときはＩＮＶＡＬＤ、不定であるときはＵＮＫＮＯＷＮ、コネクションの回復中であるときはＰＥＮＤＩＮＧの４つの値をとる。なお、バスリセット直後、有効なコネクションが存在する場合には各ステータスがＰＥＮＤＩＮＧにセットされる。
【００５６】
また、ｏＰＣＲ情報とPoint-to-pointコネクション情報に含まれる処理プロセスは、各コネクション回復処理を細分化して分割実行される各々の処理プロセスのうち、実行すべき最新の処理プロセスを保持するパラメータである。更に、Point-to-pointコネクション情報に含まれるＧＵＩＤは、各ＡＶ機器に固有のＩＤであり、ＩＥＥＥ１３９４バス上に接続されたＡＶ機器を特定するためのパラメータであり、ＣＳＲアーキテクチャで規定されるコンフィギュレーションＲＯＭに記述されている。バスリセット時のコネクション回復処理の際にＧＵＩＤを取得することにより、上記のノードＩＤとの対応関係を明確にできるが、具体的な処理については後述する。
【００５７】
次に図６は、バスリセット時に特定のノードにおいて実行されるコネクション回復処理の概略を示すフローチャートである。図６に示すように、まず、ＩＥＥＥ１３９４バス上のノード接続の変更に起因し、所定のタイミングでバスリセットが発生する（ステップＳ１）。そして、バスリセット時のコネクション回復処理を行うのに先立って、対象ノードのコネクション情報データベースの各ステータスを初期化する（ステップＳ２）。この場合、ステータスがＶＡＬＩＤであるときはＰＥＮＤＩＮＧにセットし、ステータスがＵＮＫＮＯＷＮであるときはＩＮＶＡＬＩＤにセットし、ステータスがＩＮＶＡＬＩＤ又はＰＥＮＤＩＮＧであるときはその値を保持する。
【００５８】
続いて、コネクション回復処理の実行順を登録する回復コネクションキューを初期化する（ステップＳ３）。この回復コネクションキューは、ＩＥＥＥ１３９４バス上の各ノードのファームウェア等で実現されるＦＩＦＯで構成され、コネクション回復処理に含まれる各処理を順次登録し、その実行順を制御する登録手段としての役割を担う。すなわち、本実施形態では対象ノードについて実行すべきコネクション回復処理として、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理に加え、ＧＵＩＤ取得処理の４つの処理に大別している。よって、これら４つの処理をコード化して回復コネクショキューに必要に応じて登録し、登録された順序で順次実行するように制御される。そして、ステップＳ３の初期化時には、ＧＵＩＤ取得処理、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理の順に回復コネクションキューに登録し、最初はこの順に従って各回復処理が実行される。
【００５９】
次に、バスリセット時点からの経過時間を監視し、１秒が経過したか否かを判断する（ステップＳ４）。その結果、バスリセット時点から１秒経過していない場合は（ステップＳ４；ＮＯ）、続いてコネクション情報データベースのいずれかのステータスがＰＥＮＤＩＮＧにセットされているか否かを判断する（ステップＳ５）。
【００６０】
ステップＳ４、Ｓ５の判断の結果、バスリセット時点から１秒経過した場合（ステップＳ４；ＹＥＳ）、あるいは、ＰＥＮＤＩＮＧのステータスが存在しない場合には（ステップＳ５；ＮＯ）、全てのステータス中にＵＮＫＮＯＷＮのステータスが所定数以上あるか否かを判断する（ステップＳ６）。その結果、ＵＮＫＮＯＷＮのステータスが所定数以上存在する場合は（ステップＳ６；ＹＥＳ）、バスリセットを発生させ（ステップＳ７）、図６の処理を終える。これにより、各コネクション回復処理において不定の状態が多く、コネクションを正常に回復できないと判断される場合、コネクション回復処理をやり直すべくバスリセット発生により図６の処理を再度実行させることができる。一方、ＵＮＫＮＯＷＮのステータスが所定数に満たない場合は（ステップＳ６；ＮＯ）、ステップＳ７を行うことなく図６の処理を終え、回復されたコネクションによりデータ伝送を行うことができる。
【００６１】
一方、ステップＳ５の判断の結果、ＰＥＮＤＩＮＧのステータスがあると判断された場合（ステップＳ５；ＹＥＳ）、上記の回復コネクションキューを参照し、その内容に応じた処理を実行する（ステップＳ８）。上述したように、回復コネクションキューに登録された実行順に従って、ＧＵＩＤの取得処理（ステップＳ９）、Broadcast-outコネクションの回復処理（ステップＳ１０）、Broadcast-inコネクションの回復処理（ステップＳ１１）、Point-to-pointコネクションの回復処理（ステップＳ１２）のいずれかを順次実行する。以下、これら４つの各処理についてそれぞれ説明する。
【００６２】
まず、ＧＵＩＤの取得処理（ステップＳ９）では、対象ノードのＡＶ機器に設定された上記コンフィグレーションＲＯＭを読み出してＧＵＩＤの取得を行う。この時点で全てのノードについてのＧＵＩＤを取得した場合は、そのままステップＳ９を終える。一方、何らかの要因でＧＵＩＤを取得できないノードが残っている場合は、次の機会にＧＵＩＤを取得すべく、回復コネクションキューにＧＵＩＤの取得処理を登録する。
【００６３】
次に、図７〜図１０のフローチャートを用いて、ステップＳ１０のBroadcast-outコネクションの回復処理について説明する。図７に示すように、回復コネクションキューに従ってBroadcast-outコネクションの回復処理が開始されると、コネクション情報データベースのｏＰＣＲ情報にアクセスし、上記の処理プロセスによって判別される個別の処理を実行する（ステップＳ１０１）。Broadcast-outコネクションの回復処理は、処理プロセスが１から６まで計６つの個別の処理に分割されている。なお、処理プロセスの初期値は１に設定されているものとする。
【００６４】
ステップＳ１０１の判断に基づき処理プロセス１が実行される場合は、対象ノードについてチャンネルの確保を実行する（ステップＳ１０２）。すなわち、ＣＳＲ空間のＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタにアクセスし、所望のチャンネルに対応して更新を行うことによりチャンネルが確保される。次いで、ステップＳ１０２の処理がタイムアウト又はデータエラーとなるか否かを判断する（ステップＳ１０３）。ステップＳ１０３の判断結果が「ＹＥＳ」である場合はチャンネルが確保できないので、これ以降の処理を行うことなくステップＳ１２１（図１０）に移行する。なお、本実施形態では、タイムアウトを判定する経過時間を１サイクル＝１２５μｓｅｃとして８００サイクル（＝１００ｍｓｅｃ）に設定する。
【００６５】
ステップＳ１０３の判断結果が「ＮＯ」であるときは、所望のチャンネルの確保に成功したか否かを判断する（ステップＳ１０４）。例えば、他のノードにより所望のチャンネルが既に使用されている場合は、そのチャンネルを確保することはできない。そして、チャンネルの確保に失敗したときは（ステップＳ１０４；ＮＯ）処理プロセスを２に設定し（ステップＳ１０５）、チャンネルの確保に成功したときは（ステップＳ１０４；ＹＥＳ）処理プロセスを３に設定する（ステップＳ１０６）。ステップＳ１０５又はステップＳ１０６を終えると、ステップＳ１２４（図１０）に移行する。
【００６６】
次に、ステップＳ１０１の判断に基づき処理プロセス２が実行される場合は、接続可能な出力プラグに対しｏＰＣＲのポーリングを実行する（ステップＳ１０７）。これは、処理プロセス１にてチャンネル確保に失敗した場合であっても、使用すべきチャンネルに対してオーバレイを行う可能性を考慮したものである。このオーバーレイは、ソースノードとｏＰＣＲが同一である場合、既に存在するそのｏＰＣＲ上のコネクションに対して、別のコネクションを重ねたり、Point-to-pointコネクションの上にBroadcast-outコネクション又はPoint-to-pointコネクションを重ねて設定することである。ステップＳ１０７では、他のノードによりオーバーレイが行われることを想定し、各出力プラグのｏＰＣＲのPoint-to-pointコネクションカウンタがバスリセット後に更新されるか否かを監視すべく、ｏＰＣＲのポーリングを行うものである。
【００６７】
次いで、ステップＳ１０７でポーリングされたｏＰＣＲが更新されたか否かを判断する（ステップＳ１０８）。例えば、元々Point-to-pointコネクションの値が０であるとき更新されると値は１に変化する。ステップＳ１０８の判断結果が「ＮＯ」であるときは、ステップＳ１２４（図１０）に移行する。一方、ステップＳ１０８の判断結果が「ＹＥＳ」であるときは、処理プロセスを４に設定する（ステップＳ１０９）。ステップＳ１０９を終えると、ステップＳ１２４（図１０）に移行する。
【００６８】
次に図８に示すように、ステップＳ１０１の判断に基づき処理プロセス３が実行される場合は、対象ノードについて帯域の確保を実行する（ステップＳ１１０）。すなわち、ＣＳＲ空間のＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタにアクセスし、転送に必要となる帯域に対応して更新を行うことにより帯域が確保される。次いで、ステップＳ１１０の処理がタイムアウト（８００サイクル（＝１００ｍｓｅｃ）経過時点）又はデータエラーとなるか否かを判断する（ステップＳ１１１）。ステップＳ１１１の判断結果が「ＹＥＳ」であるときは、帯域が確保できないので、これ以降の処理を行うことなくステップＳ１２１に（図１０）に移行する。
【００６９】
一方、ステップＳ１１１の判断結果が「ＮＯ」であるときは、必要な帯域の確保に成功したか否かを判断する（ステップＳ１１２）。例えば、空いている帯域が必要な帯域に不足している場合は、その帯域を確保することはできない。そして、帯域の確保に成功したときは（ステップＳ１１２；ＹＥＳ）、処理プロセスを４に設定し（ステップＳ１１３）、帯域の確保に失敗したときは（ステップＳ１１２；ＮＯ）、処理プロセスを６に設定する（ステップＳ１１４）。ステップＳ１１３又はステップＳ１１４を終えると、ステップＳ１２４（図１０）に移行する。
【００７０】
次に、ステップＳ１０１の判断に基づき処理プロセス４が実行される場合は、対象ノードの出力プラグに対し、ｏＰＣＲの更新を実行する（ステップＳ１１５）。すなわち、処理プロセス１及び３により確保されたチャンネル及び帯域に対応する値をｏＰＣＲのチャンネル番号やデータ転送速度に設定するとともに、broadcastコネクションカウンタをインクリメントする。そして、ステップＳ１１５の結果、ｏＰＣＲの更新に成功したか否かを判断し（ステップＳ１１６）、判断結果が「ＹＥＳ」であるときは、ステップＳ１２２（図１０）に移行し、判断結果が「ＮＯ」であるときは、処理プロセスを５に設定する（ステップＳ１１７）。ステップＳ１１７を終えると、ステップＳ１２４（図１０）に移行する。
【００７１】
次に図９に示すように、ステップＳ１０１の判断に基づき処理プロセス５が実行される場合は、ステップＳ１１２で確保された帯域の解放を実行する（ステップＳ１１８）。すなわち、処理プロセス４でｏＰＣＲの更新に失敗したため、この時点では所望のBroadcast-outコネクションを回復できないと判断され、確保した帯域をいったん解放すべくステップＳ１１８を実行するのである。その後、処理プロセスを６に設定し（ステップＳ１１９）、ステップＳ１２４（図１０）に移行する。
【００７２】
また、ステップＳ１０１の判断に基づき処理プロセス６が実行される場合は、ステップＳ１０２で確保されたチャンネルの解放を実行する（ステップＳ１２０）。すなわち、上述した処理プロセスと同様の理由により、確保したチャンネルをいったん解放すべくステップＳ１２０を実行するのである。この処理プロセス６に続いてステップＳ１２３（図１０）に移行する。
【００７３】
次に、Broadcast-outコネクションの回復処理において、各処理プロセス１〜６に後続する処理について図１０のフローチャートを用いて説明する。図１０におけるステップＳ１２１〜Ｓ１２４は、コネクション情報データベースの対象となるステータスに関する処理である。
【００７４】
まず、処理プロセス１のステップＳ１０３（図７）又は処理プロセス３のステップＳ１１１（図８）から移行した場合は、ステータスをＵＮＫＮＯＷＮにセットする（ステップＳ１２１）。この場合は、タイムアウト又はデータエラーと判断されたので、この時点で処理対象のコネクションが正常に回復できる否かが不定の状態にある。
【００７５】
また、処理プロセス４のステップＳ１１６（図８）から移行した場合は、ステータスをＶＡＬＩＤにセットする（ステップＳ１２２）。この場合は、チャンネルと帯域の確保及びｏＰＣＲの更新に成功し、この時点で処理対象のコネクションが回復して有効な状態にある。
【００７６】
また、処理プロセス６のステップＳ１２０（図９）から移行した場合は、ステータスをＩＮＶＡＬＩＤにセットする（ステップＳ１２３）。この場合は、上述した理由でチャンネルと帯域を解放したので、この時点で処理対象のコネクションが回復できず無効な状態にある。
【００７７】
また、各処理プロセス１〜６において、次に実行すべき処理プロセスの設定後に移行した場合、あるいは、処理プロセス２のステップＳ１０８（図７）から移行した場合は、ステータスを変えずに元の値を維持する（ステップＳ１２４）。この場合は、対象のコネクション回復処理を継続する必要があり、更に処理が進行した時点でステータスを更新すればよい。
【００７８】
ステップＳ１２１〜Ｓ１２４に続いて、対象ノードの全ての出力プラグについてBroadcast-outコネクションの回復処理を終了したか否かを判断する（ステップＳ１２５）。その結果、未終了の出力プラグがある場合は（ステップＳ１２５；ＮＯ）、回復コネクションキューにBroadcast-outコネクションの回復処理を登録し（ステップＳ１２６）、図１０の処理を終える。これにより、残存するBroadcast-outコネクションの回復処理については、後に回復コネクションキューの順序に従って図７〜図１０の処理が再度実行されることになる。一方、全ての出力プラグについて上記処理を終了した場合は（ステップＳ１２５；ＹＥＳ）、又はステップＳ１２６の終了後は、図１１の処理を終えてステップＳ１３（図６）に移行する。
【００７９】
次に、図１１のフローチャートを用いて、ステップＳ１１のBroadcast-inコネクションの回復処理について説明する。ここでは、入力プラグについてのｉＰＣＲに関する処理を行うこととし、出力プラグを経由するBroadcastコネクションに対するチャンネル及び帯域の確保に関しては、上述のBroadcast-outコネクションの回復処理において実行されることになる。よって、Broadcast-inコネクションの回復処理は、Broadcast-outコネクションの回復処理のように複数の処理プロセスに細分化する必要はない。
【００８０】
図１１において、回復コネクションキューに従ってBroadcast-inコネクションの回復処理が開始されると、対象ノードの入力プラグに対し、ｉＰＣＲの更新を実行する（ステップＳ２０１）。すなわち、受信すべきチャンネル番号に設定するとともに、broadcastコネクションカウンタをインクリメントする。続いて、ステップＳ２０１の結果、ｉＰＣＲの更新に成功したか否かを判断する（ステップＳ２０２）。
【００８１】
ステップＳ２０２の判断結果が「ＹＥＳ」となりｉＰＣＲの更新に成功した場合は、コネクション情報データベースの対象となるステータスをＶＡＬＩＤにセットする（ステップＳ２０３）。一方、ステップＳ２０２の判断結果が「ＮＯ」となりｉＰＣＲの更新に失敗したときは、上記ステータスをＩＮＶＡＬＩＤにセットする（ステップＳ２０４）。そして、対象ノードの全ての入力プラグについてBroadcast-inコネクションの回復処理を終了したか否かを判断し（ステップＳ２０５）。その結果、未終了の入力プラグがある場合は（ステップＳ２０５；ＮＯ）、回復コネクションキューにBroadcast-inコネクションの回復処理を登録し（ステップＳ２０６）、図１１の処理を終える。一方、全ての入力プラグについて上記処理を終了した場合は（ステップＳ２０５；ＹＥＳ）、ステップＳ２０６を行うことなく図１１の処理を終える。これにより、残存するBroadcast-inコネクションの回復処理については、後に回復コネクションキューの順序に従って図１１の処理が再度実行されることになる。
【００８２】
次に、図１２〜図１５のフローチャートを用いて、ステップＳ１２のPoint-to-pointコネクションの回復処理について説明する。図１２に示すように、回復コネクションキューに従ってPoint-to-pointコネクションの回復処理が開始されると、コネクション情報データベースのPoint-to-pointコネクション情報にアクセスし、上記の処理プロセスによって判別される個別の処理を実行する（ステップＳ３０１）。Point-to-pointコネクションの回復処理は、処理プロセスが１から８までの計８つの個別の処理に分割され、上記のBroadcast-outコネクションの回復処理よりも更に多くなっている。この場合も、処理プロセスの初期値は１に設定されているものとする。
【００８３】
図１２に示すように、ステップＳ３０１の判断に基づき処理プロセス１が実行される場合は、Point-to-pointコネクションで必要なＧＵＩＤが既知であるか否かを判断する（ステップＳ３０２）。すなわち、Point-to-pointコネクションでは入力プラグと出力プラグの双方が存在するので、それぞれのノードのＡＶ機器が判別可能であることが前提となるため、図６のステップＳ９に基づきＧＵＩＤが取得済みであることを確認するものである。または、バスリセット後に受信したアイソクロナスパケットから送信ノードを特定することで、バスリセット前に接続されていたＡＶ機器と判別するようにしてもよい。その結果、ＧＵＩＤが未知であるときは（ステップＳ３０２；ＮＯ）、これ以降の処理を行うことなくステップＳ３３３（図１５）に移行する。
【００８４】
一方、ＧＵＩＤが既知であるときは（ステップＳ３０２；ＹＥＳ）、回復すべきPoint-to-pointコネクションで用いるチャンネルの確保を実行する（ステップＳ３０３）。すなわち、ＣＳＲ空間のＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタにアクセスし、上記のチャンネルに対応して更新を行うことによりチャンネルが確保される。次いで、ステップＳ３０３の処理がタイムアウト（８００サイクル（＝１００ｍｓｅｃ）経過時点）又はデータエラーとなるか否かを判断する（ステップＳ３０４）。ステップＳ３０４の判断結果が「ＹＥＳ」である場合はチャンネルが確保できないので、これ以降の処理を行うことなくステップＳ３３０（図１５）に移行する。
【００８５】
ステップＳ３０４の判断結果が「ＮＯ」である場合は、所望のチャンネルの確保に成功したか否かを判断する（ステップＳ３０５）。その結果、チャンネルの確保に失敗したときは（ステップＳ３０５；ＮＯ）処理プロセスを２に設定し（ステップＳ３０６）、チャンネルの確保に成功したときは（ステップＳ３０５；ＹＥＳ）処理プロセスを３に設定する（ステップＳ３０７）。ステップＳ３０７を終えると、ステップＳ３３３（図１５）に移行する。
【００８６】
次に、ステップＳ３０１の判断に基づき処理プロセス２が実行される場合は、接続可能な出力プラグに対しｏＰＣＲのポーリングを実行する（ステップＳ３０８）。これは、Broadcast-outコネクションの回復処理の処理プロセス２と同様に、BroadcastコネクションとPoint-to-pointコネクションのオーバレイを考慮した処理である。すなわち、ステップＳ３０８では、他のノードによりオーバーレイが行われることを想定し、各出力プラグのｏＰＣＲのPoint-to-pointコネクションカウンタがバスリセット後に更新されるか否かを監視すべく、ｏＰＣＲのポーリングを行うものである。
【００８７】
次いで、ステップＳ３０８でポーリングされたｏＰＣＲが更新されたか否かを判断する（ステップＳ３０９）。そして、ステップＳ３０９の判断結果が「ＮＯ」であるときは、ステップＳ３３３（図１５）に移行する。一方、ステップＳ３０９の判断結果が「ＹＥＳ」であるときは、処理プロセスを４に設定し（ステップＳ３１０）、ステップＳ３３３（図１５）に移行する。
【００８８】
次に図１３に示すように、ステップＳ３０１の判断に基づき処理プロセス３が実行される場合は、転送に必要な帯域の確保を実行する（ステップＳ３１１）。すなわち、ＣＳＲ空間のＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタにアクセスし、転送に必要となる帯域に対応して更新を行うことにより帯域が確保される。次いで、ステップＳ３１１の処理がタイムアウト（８００サイクル（＝１００ｍｓｅｃ）経過時点）又はデータエラーとなるか否かを判断する（ステップＳ３１２）。ステップＳ３１２の判断結果が「ＹＥＳ」であるときは、これ以降の処理を行うことなくステップＳ３３０（図１５）に移行する。
【００８９】
一方、ステップＳ３１２の判断結果が「ＮＯ」であるときは、必要な帯域の確保に成功したか否かを判断する（ステップＳ３１３）。そして、帯域の確保に成功したときは（ステップＳ３１３；ＹＥＳ）、処理プロセスを４に設定し（ステップＳ３１４）、帯域の確保に失敗したときは（ステップＳ３１３；ＮＯ）、処理プロセスを８に設定する（ステップＳ３１５）。ステップＳ３１４又はステップＳ３１５を終えると、ステップＳ３３３（図１５）に移行する。
【００９０】
次に、ステップＳ３０１の判断に基づき処理プロセス４が実行される場合は、Point-to-pointコネクションの送信側の出力プラグに対し、ｏＰＣＲの更新を実行する（ステップＳ３１６）。ここでは、Point-to-pointコネクション確立側のノードが更新対象のノードと異なる場合を前提とする。この場合、更新対象のノードに対してトランザクションを発行することにより、処理プロセス１及び３により確保されたチャンネル及び帯域に対応する値をｏＰＣＲのチャンネル番号やデータ転送速度に設定するとともに、Point-to-pointコネクションカウンタをインクリメントする。そして、ステップＳ３１６の処理がタイムアウト（８００サイクル（＝１００ｍｓｅｃ）経過時点）又はデータエラーとなるか否かを判断し（ステップＳ３１７）。判断結果が「ＹＥＳ」であるときは、これ以降の処理を行うことなくステップＳ３３１（図１５）に移行する。
【００９１】
一方、ステップＳ３１７の判断結果が「ＮＯ」であるときは、ｏＰＣＲの更新に成功したか否かを判断する（ステップＳ３１８）。その結果、ｏＰＣＲの更新に成功した場合は（ステップＳ３１８；ＹＥＳ）、処理プロセスを５に設定し（ステップＳ３１９）、ｏＰＣＲの更新に失敗した場合は（ステップＳ３１８；ＮＯ）、処理プロセスを７に設定する（ステップＳ３２０）。ステップＳ３１９又はステップＳ３２０を終えると、ステップＳ３３３（図１５）に移行する。
【００９２】
次に図１４に示すように、ステップＳ３０１の判断に基づき処理プロセス５が実行される場合は、Point-to-pointコネクションの受信側の入力プラグに対し、ｉＰＣＲの更新を実行する（ステップＳ３２１）。上述したように、Point-to-pointコネクション確立側のノードが更新対象のノードと異なる場合を前提とする。この場合、更新対象のノードに対してトランザクションを発行することにより、処理プロセス１により確保されたチャンネルをｉＰＣＲのチャンネル番号に設定するとともに、Point-to-pointコネクションカウンタをインクリメントする。そして、ステップＳ３２１の処理がタイムアウト（８００サイクル（＝１００ｍｓｅｃ）経過時点）又はデータエラーとなるか否かを判断し（ステップＳ３２２）。判断結果が「ＹＥＳ」であるときは、これ以降の処理を行うことなくステップＳ３３０（図１５）に移行する。
【００９３】
一方、ステップＳ３２２の判断結果が「ＮＯ」であるときは、ｉＰＣＲの更新に成功したか否かを判断する（ステップＳ３２３）。その結果、ｉＰＣＲの更新に成功した場合は（ステップＳ３２３；ＹＥＳ）、ステップＳ３３１（図１５）に移行し、ｉＰＣＲの更新に失敗した場合は（ステップＳ３２３；ＮＯ）、処理プロセスを６に設定する（ステップＳ３２４）。ステップＳ３２４を終えると、ステップＳ３３３（図１５）に移行する。
【００９４】
次に、ステップＳ３０１の判断に基づき処理プロセス６が実行される場合は、上記の処理プロセス４にて更新されたｏＰＣＲの解放を実行する（ステップＳ３２５）。これは、処理プロセス４において送信側の出力プラグに対しｏＰＣＲを更新したにもかかわらず、処理プロセス５において受信側の入力プラグに対するｉＰＣＲを更新できなかった場合の処理である。すなわち、この時点では所望のPoint-to-pointコネクションを回復できないと判断されるので、いったんｏＰＣＲの状態を元に戻すべくステップＳ３２５を実行するのである。その後は処理プロセスを７に設定し（ステップＳ３２６）、ステップＳ３３３（図１５）に移行する。
【００９５】
次に、ステップＳ３０１の判断に基づき処理プロセス７が実行される場合は、ステップＳ３１１で確保された帯域の解放を実行する（ステップＳ３２７）。これは、処理プロセス４において送信側の出力プラグに対するｏＰＣＲを更新できなかった場合、又は、処理プロセス５において受信側の入力プラグに対するｉＰＣＲを更新できなった場合の処理である。いずれの場合も、この時点では所望のPoint-to-pointコネクションを回復できないと判断され、確保した帯域をいったん解放すべくステップＳ３２７を実行するのである。その後、処理プロセスを８に設定し（ステップＳ３２８）、ステップＳ３３３（図１５）に移行する。
【００９６】
また、ステップＳ１０１の判断に基づき処理プロセス８が実行される場合は、ステップＳ３０３で確保されたチャンネルの解放を実行する（ステップＳ３２９）。すなわち、上述した処理プロセス７と同様の理由により、確保したチャンネルをいったん解放すべくステップＳ３２９を実行するのである。その後はステップＳ３３２（図１５）に移行する。
【００９７】
次に、Broadcast-inコネクションの回復処理において、各処理プロセス１〜８に後続する処理について図１５のフローチャートを用いて説明する。図１５におけるステップＳ３３０〜Ｓ３３３は、コネクション情報データベースの対象となるステータスに関する処理である。
【００９８】
まず、処理プロセス１、３、４、５にてタイムアウト又はデータエラーと判断されて移行した場合は、ステータスをＵＮＫＮＯＷＮにセットする（ステップＳ３３０）。上述したように、この時点では処理対象のコネクションが正常に回復できる否かが不定の状態にある。
【００９９】
また、処理プロセス５のステップＳ３２３（図１４）から移行した場合は、ステータスをＶＡＬＩＤにセットする（ステップＳ３３１）。この場合は、チャンネルと帯域の確保及びｏＰＣＲとｉＰＣＲの更新に成功し、この時点で処理対象のコネクションが回復して有効な状態にある。
【０１００】
また、処理プロセス８のステップＳ３２９（図１４）から移行した場合は、ステータスをＩＮＶＡＬＩＤにセットする（ステップＳ３３２）。この場合は、上述した理由でチャンネルと帯域を解放したので、この時点で処理対象のコネクションが回復できず無効な状態にある。
【０１０１】
また、各処理プロセス１〜８において、次に実行すべき処理プロセスを設定後に移行した場合、あるいは、処理プロセス２のステップＳ３０９（図１２）から移行した場合は、ステータスを変えずに元の値を維持する（ステップＳ３３３）。この場合は、コネクション回復処理を継続して実行する必要があり、更に処理が進行した時点でステータスを更新すればよい。
【０１０２】
ステップＳ３３０〜Ｓ３３３に続いて、対象ノードの全てのPoint-to-pointコネクションについて回復処理を終了したか否かを判断する（ステップＳ３３４）。その結果、未終了のPoint-to-pointコネクションがある場合は（ステップＳ３３４；ＮＯ）、回復コネクションキューにPoint-to-pointコネクションの回復処理を登録する（ステップＳ３３５）。これにより、残存するPoint-to-pointコネクションの回復処理については、後に回復コネクションキューの順序に従って図１２〜１５の処理が再度実行されることになる。一方、全てのPoint-to-pointコネクションについて上記処理を終了した場合（ステップＳ３３４；ＹＥＳ）、又はステップＳ３３５の終了後は、図１５の処理を終えてステップＳ１３（図６）に移行する。
【０１０３】
以上、図６のステップＳ８により実行順を制御される処理として、ＧＵＩＤの取得処理、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理について、それぞれ説明を行った。次に図６に戻って、ステップＳ９〜Ｓ１２に続いて、新たなバスリセットの発生の有無を検出する（ステップＳ１３）。その結果、バスリセットの発生が検出されたときは（ステップＳ１３；ＹＥＳ）、ステップＳ２に移行して再び初期化（ステップＳ３、Ｓ４）を行って最初から上記の処理を実行する。一方、バスリセットの発生が検出されないときは（ステップＳ１３；ＮＯ）、ステップＳ４以降の処理を繰り返し実行する。
【０１０４】
このように本実施形態によれば、各ノードにおけるコネクション回復に関連する処理を大きく４つに分け、その実行順を回復コネクションキューにより制御するとともに、Broadcast-outコネクションの回復処理とPoint-to-pointコネクションの回復処理は、それぞれを細分化して複数の処理プロセスを分割実行するように制御する。これにより、コネクション回復処理を時間の経過とともに切り換えて実行でき、コネクションの回復状態に基づき選択すべき処理プロセスを制御するので、各コネクション回復処理を仮想的に並列実行する効果を実現できる。よって、回復不可能なコネクションがある場合でも、時間的なロスを最小限に抑えることができ、バスリセットからの１秒間を有効活用して処理効率の向上させることができる。
【０１０５】
なお、本実施形態では、データ転送のインターフェース規格としてＩＥＥＥ１３９４を採用したデータ転送システムに対し本発明を適用した場合を説明したが、これに限られることなく、バスリセット時におけるコネクション回復処理が必要な各種データ転送システムに対し、広く本発明を適用することができる。
【０１０６】
【発明の効果】
以上説明したように本発明によれば、バスリセット時に回復すべきコネクションが多数ある場合であっても、コネクション回復処理が滞ることなく迅速に進行可能であり、処理効率及び信頼性を向上させることができるコネクション回復方法と、このコネクション回復方法を実行可能なデータ伝送システム及び情報伝送装置を構築することができる。
【図面の簡単な説明】
【図１】ＩＥＥＥ１３９４のプロトコルの構成を示すブロック図である。
【図２】ＩＥＥＥ１３９４のバス上に接続された複数の情報伝送機器によるデータ伝送システムの概念を示す図である。
【図３】ｏＰＣＲのデータフォーマットを示す図である。
【図４】ｉＰＣＲのデータフォーマットを示す図である。
【図５】コネクション情報データベースの構成を示す図である
【図６】本実施形態に係るコネクション回復処理の概略を示すフローチャートである。
【図７】 Broadcast-outコネクションの回復処理を示す第１のフローチャートである。
【図８】 Broadcast-outコネクションの回復処理を示す第２のフローチャートである。
【図９】 Broadcast-outコネクションの回復処理を示す第３のフローチャートである。
【図１０】 Broadcast-outコネクションの回復処理を示す第４のフローチャートである。
【図１１】 Broadcast-inコネクションの回復処理を示すフローチャートである。
【図１２】 Point-to-pointコネクションの回復処理を示す第１のフローチャートである。
【図１３】 Point-to-pointコネクションの回復処理を示す第２のフローチャートである。
【図１４】 Point-to-pointコネクションの回復処理を示す第３のフローチャートである。
【図１５】 Point-to-pointコネクションの回復処理を示す第４のフローチャートである。
【符号の説明】
１０…物理層
１１…リンク層
１２…トランザクション層
１３…バス管理層
２１〜２３…ＡＶ機器
【発明の属する技術分野】
本発明は、複数の情報伝送機器がバス上のノードに接続され、各ノード間でコネクションを確立してデータを伝送するデータ伝送システムに関し、特に、ＩＥＥＥ１３９４（IEEE（Institute of Electrical and Electronic Engineers）Std.1394-1995 IEEE Standard for a High Performance serial Bus）規格に準拠したシリアルバスにおいて、バスリセット発生時にコネクション回復処理を実行するデータ伝送システム、コネクション回復方法及び情報伝送装置の技術分野に属するものである。
【０００２】
【従来の技術】
近年、ＡＶ機器やコンピュータ周辺機器が互いにディジタルデータを伝送するインターフェース規格として上記ＩＥＥＥ１３９４規格が注目されている。このＩＥＥＥ１３９４規格は、高速な転送速度でデータを転送でき、トポロジー接続の自由度が高く、アイソクロナス転送によりリアルタイムデータの転送に好適であるなど様々なメリットがあり、従来のインターフェース規格と比べても有用性が高い。
【０００３】
また、ＩＥＥＥ１３９４規格では、一般ユーザの利用状況を考慮して、電源を入れたままでの機器の活線挿抜をサポートしている。そのため、バスのトポロジー接続が変更されたときにバスリセットを発生させ、ノード間で確立されたコネクションをいったん解除するが、バスリセットから１秒間はそれまでのデータ伝送を維持する。よって、この１秒間に各ノードが元のコネクションを回復させる処理を実行する必要がある。
【０００４】
【発明が解決しようとする課題】
しかしながら、ＩＥＥＥ１３９４バス上の各ノードに接続される機器には、入力プラグと出力プラグをそれぞれ複数設定可能であり、コネクションの種別もBroadcast-inコネクション、Broadcast-outコネクション、Point-to-pointコネクションなど多様であるため、バスリセット時に実行すべきコネクション回復処理は複雑になる。一方、各コネクション回復処理に含まれる個別の処理において、例えば、チャンネルや帯域の確保に失敗したり、入出力プラグのレジスタの更新に失敗する場合が想定される。そのため、これらの個別の処理を成功するまで実行し続けることになると、特定のコネクション回復処理で時間を要するために、それ以外のコネクション回復処理に必要な時間が不足する場合がある。その結果、回復可能なコネクションが未回復のままバスリセット後の１秒間が経過する可能性があり、正常なコネクションの回復に支障を来すおそれがある。
【０００５】
そこで、本発明はこのような問題に鑑みなされたものであり、バスリセット時に回復すべきコネクションが多数ある場合であっても、１つのコネクション回復処理に制約されることなく全体のコネクション回復処理を迅速に進行でき、処理効率及び信頼性を向上させることができるコネクション回復方法を提供するとともに、かかるコネクション回復方法を実行可能なデータ伝送システムを構築することを目的とする。
【０００６】
【課題を解決するための手段】
上記の課題を解決するために、請求項１に記載のデータ伝送システムは、複数の情報伝送機器がバス上のノードに接続され、各ノード間でコネクションを確立してデータを伝送するデータ伝送システムにおいて、バスリセット発生に伴い前記確立されたコネクションが解除されたとき、所定時間が経過するまでに、それぞれのノードにおいて前記コネクションを回復するコネクション回復制御手段を備え、前記コネクション回復制御手段は、前記コネクションの種別に対応する複数のコネクション回復処理の実行順を制御するとともに、前記それぞれのコネクション回復処理を複数の処理プロセスに分割し、前記実行順に対応するコネクション回復処理に際し所定の処理プロセスを前記コネクションの回復状態に基づいて選択的に順次実行し、前記コネクション回復処理の実行順を登録された登録手段を参照することにより前記実行順を制御し、前記コネクションの回復状態に応じて前記登録手段の内容を適宜更新することを特徴とする。
【０００７】
また、請求項７に記載のコネクション回復方法は、複数の情報伝送機器がバス上のノードに接続され、各ノード間でコネクションを確立してデータを伝送するデータ伝送システム上で、バスリセット発生に伴い前記確立されたコネクションが解除されたとき、所定時間が経過するまでに、それぞれのノードにおいて前記コネクションを回復するコネクション回復方法において、前記コネクションの種別に対応する複数のコネクション回復処理の実行順を制御するとともに、前記それぞれのコネクション回復処理を複数の処理プロセスに分割し、前記実行順に対応するコネクション回復処理に際し所定の処理プロセスを前記コネクションの回復状態に基づいて選択的に順次実行し、前記コネクション回復処理の実行順を登録された登録手段を参照することにより前記実行順を制御し、前記コネクションの回復状態に応じて前記登録手段の内容を適宜更新することを特徴とする。
【０００８】
また、請求項１１に記載の情報伝送装置は、バス上のノードに接続可能で、他ノードとの間でコネクションを確立してデータを伝送する情報伝送装置において、バスリセット発生に伴い前記確立されたコネクションが解除されたとき、所定時間が経過するまでに、前記コネクションを回復するコネクション回復制御手段を備え、前記コネクション回復制御手段は、前記コネクションの種別に対応する複数のコネクション回復処理の実行順を制御するとともに、前記それぞれのコネクション回復処理を複数の処理プロセスに分割し、前記実行順に対応するコネクション回復処理に際し所定の処理プロセスを前記コネクションの回復状態に基づいて選択的に順次実行し、前記コネクション回復処理の実行順を登録された登録手段を参照することにより前記実行順を制御し、前記コネクションの回復状態に応じて前記登録手段の内容を適宜更新することを特徴とする。
【０００９】
請求項１、７、１１にそれぞれ記載の発明によれば、データ伝送システムにおいて例えば情報伝送機器の接続状態の変更によりバスリセットが発生すると、所定時間内に各ノードを結ぶコネクションを回復させるための処理が開始される。処理対象のコネクション回復処理は実行順を制御されつつ、更に複数の処理プロセスに分割され、その中からコネクションの回復状態に対応して特定の処理プロセスが実行される。このように、処理時間を細分化して個別の処理を交互に切り換えて制御するので、複数のコネクション回復処理を並列実行するのと同様の効果があり、１つのコネクションが回復困難になった場合でも、それにより停滞することなく他のコネクション回復処理を進行できる。よって、時間を有効に活用してコネクション回復の処理効率を向上させることができる。
【００１３】
請求項１、７、１１にそれぞれ記載の発明によれば、コネクション回復処理の実行順の制御に際し登録手段を参照するようにしたので、簡易かつ確実に上記の制御を行うことができるとともに、登録手段の内容を更新可能としたので、処理の進行状況に応じて実行順を自在に可変することができる。
【００１４】
請求項２に記載のデータ伝送システムは、請求項１に記載のデータ伝送システムにおいて、前記バス上の各ノードには、前記コネクションの回復状態及び選択対象の前記処理プロセスを含むコネクション情報を更新可能に保持するコネクション情報記録手段が設けられることを特徴とする。
【００１５】
また、請求項１２に記載の情報伝送装置は、請求項１１に記載の情報伝送装置において、前記コネクションの回復状態及び選択対象の前記処理プロセスを含むコネクション情報を更新可能に保持するコネクション情報記録手段が設けられることを特徴とする。
【００１６】
請求項２と請求項１２にそれぞれ記載の発明によれば、コネクション回復処理に際し、コネクション情報記録手段にはコネクションの回復状態と選択対象の処理プロセスが記録されるので、状況に応じて次に実行すべき処理内容を的確に判断することができる。
【００１７】
請求項３に記載のデータ伝送システムは、請求項１に記載のデータ伝送システムにおいて、前記複数の処理プロセスには、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれることを特徴とする。
【００１８】
また、請求項８のコネクション回復方法は、請求項７に記載のコネクション回復方法において、前記複数の処理プロセスには、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれることを特徴とする。
【００１９】
また、請求項１３に記載の情報伝送装置は、請求項１１に記載の情報伝送装置において、前記複数の処理プロセスには、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれることを特徴とする。
【００２０】
請求項３、８、１３にそれぞれ記載の発明によれば、コネクション回復処理では、チャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスを分割実行するので、各々の処理時間を短縮して一層処理効率を向上させることができる。
【００２１】
請求項４に記載のデータ伝送システムは、請求項３に記載のデータ伝送システムにおいて、前記バスはＩＥＥＥ１３９４規格に準拠したシリアルバスであり、前記複数のコネクション回復処理には、Broadcastoutコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする。
【００２２】
また、請求項９に記載のコネクション回復方法は、請求項７に記載のコネクション回復方法において、前記バスはＩＥＥＥ１３９４規格に準拠したシリアルバスであり、前記複数のコネクション回復処理には、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする。
【００２３】
また、請求項１４に記載の情報伝送装置は、請求項１３に記載の情報伝送装置において、前記バスはＩＥＥＥ１３９４規格に準拠したシリアルバスであり、前記複数のコネクション回復処理には、Broadcastoutコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする。
【００２４】
請求項４、９、１４にそれぞれ記載の発明によれば、汎用的でディジタルデータ伝送に好適なＩＥＥＥ１３９４規格を用いて、上記３つのコネクション回復処理を上述のように制御するので、情報伝送機器の活線挿抜が行われる際のバスリセットが頻繁に発生するＩＥＥＥ１３９４バスシステムの信頼性及び処理効率を高めることができる。
【００２５】
請求項５に記載のデータ伝送システムは、請求項４に記載のデータ伝送システムにおいて、前記複数の処理プロセスには、送信側の出力プラグのｏＰＣＲを更新する処理プロセスと、受信側の入力プラグのｉＰＣＲを更新する処理プロセスが含まれることを特徴とする。
【００２６】
また、請求項１０に記載のコネクション回復方法によれば、請求項９に記載のコネクション回復方法において、前記複数の処理プロセスには、送信側の出力プラグのｏＰＣＲを更新する処理プロセスと、受信側の入力プラグのｉＰＣＲを更新する処理プロセスが含まれることを特徴とする。
【００２７】
また、請求項１５に記載の情報伝送装置は、請求項１４に記載の情報伝送装置において、前記複数の処理プロセスには、送信側の出力プラグのｏＰＣＲを更新する処理プロセスと、受信側の入力プラグのｉＰＣＲを更新する処理プロセスが含まれることを特徴とする。
【００２８】
請求項５、１０、１５にそれぞれ記載の発明によれば、ＩＥＥＥ１３９４バスシステムにおけるコネクションの入出力プラグに対し、ｏＰＣＲを更新する処理プロセスと、ｉＰＣＲを更新する処理プロセスを分割実行するので、各々の処理時間を短縮して確実性を高めることができる。
【００２９】
請求項６に記載のデータ伝送システムは、請求項２に記載のデータ伝送システムにおいて、前記コネクション情報記録手段には、前記それぞれの情報伝送機器に固有のＩＤが保持され、前記コネクション回復制御手段は、前記ＩＤの取得処理の実行順を制御することを特徴とする。
【００３０】
また、請求項１６に記載の情報伝送装置は、請求項１４に記載の情報伝送装置において、前記コネクション情報記録手段には、バス上のノードに接続された情報伝送機器に固有のＩＤが保持され、前記コネクション回復制御手段は、前記ＩＤの取得処理の実行順を制御することを特徴とする。
【００３１】
請求項６と請求項１６にそれぞれ記載の発明によれば、ＩＥＥＥ１３９４バス上のノードに接続された情報伝送機器をＧＵＩＤを参照して特定することできので、コネクション回復処理の確実性を高めることができる。
【００３２】
【発明の実施の形態】
以下、本発明の好適な実施形態を図面に基づいて説明する。本実施形態においては、データ転送のインターフェース規格としてＩＥＥＥ１３９４を採用したデータ転送システムに対して本発明を適用した場合について説明する。
【００３３】
図１は、ＩＥＥＥ１３９４のプロトコルの構成を示すブロック図である。ＩＥＥＥ１３９４のプロトコルは、図１に示すように、物理層１０、リンク層１１、トランザクション層１２の３つの層と、バス管理層１３とから構成される。一般に、物理層１０とリンク層１１はハードウェアで実現され、トランザクション層１２と、バス管理層１３はファームウェアで実現される。
【００３４】
物理層１０は、バスとの物理的・電気的インターフェースを行う層であり、信号のエンコードとデコードを行うエンコード／デコード部１０ａ、各ノード間のバス使用権の調停（アービトレーション）を行うバスアービトレーション部１０ｂ、バス上の媒体とのインターフェース動作を行うインターフェース部１０ｃを含んでいる。
【００３５】
リンク層１１は、パケットの送受信動作等を行う層であり、送受信の際のサイクル制御を行うサイクル制御部１１ａ、パケットの送信動作を行うパケット送信部１１ｂ、パケットの受信動作を行うパケット受信部１１ｃを含んでいる。また、同期データを送受信するためのアイソクロナス転送が行われる場合、リンク層１１とバスの間にアイソクロナスチャンネルが設定される。
【００３６】
トランザクション層１２は、上位のアプリケーションとリンク層１１の間の通信処理を制御する層であり、リンク層１１の動作を制御して指定されたノードとアドレスに対する読み出し又は書き込みを実行する。トランザクション層１２では、特定アドレスのデータを読み取るリードトランザクション、特定アドレスにデータを書き込むライトトランザクション、特定アドレスを参照して所定の条件に合致したとき更新するロックトランザクションをそれぞれ発行する。
【００３７】
バス管理層１３は、物理層１０、リンク層１１、トランザクション層１２の３層を制御し、ノード制御とバス資源管理のための基本的な機能を提供する。バス管理層１３には、バスの管理を行うバスマネージャ１３ａと、アイクロナスリソースの管理を行うアイソクロナス資源管理部１３ｂと、ＣＳＲ（Command and Status Register）アーキテクチャに基づいてノードを制御するノード制御部１３ｃを含んでいる。
【００３８】
上記のアイソクロナス資源管理部１３ｂは、アイソクロナス転送の能力を有するノードに対し少なくとも１つ設定されるＩＲＭ（Isochronous Resource Manager）に対応する。このＩＲＭは、ＣＳＲアーキテクチャに対応するＣＳＲ空間において、アイソクロナスリソースの管理に用いるレジスタを保有している。そして、ＣＳＲ空間には、アイソクロナス転送に必要となるレジスタとして、ＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタとＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタが設けられている。
【００３９】
上記のＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタは、アイソクロナスチャンネルの使用状況を表す６４ビットのレジスタであり、各チャンネルが１であれば使用中であり、０であれば未使用であることを表す６４チャンネル分のデータを保持している。また、上記のＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタは、アイソクロナス転送に使用可能な帯域を示す数値を格納するレジスタであり、１６００Ｍｂｐｓの転送速度で３２ビットのデータ転送に要する時間を１ユニット（約２０ｎｓｅｃ）とし、これを単位に表わされる。
【００４０】
ＩＥＥＥ１３９４のバス上の各ノードがアイソクロナス転送を行う際は、適正なチャンネル及び帯域を確保する必要がある。そのため、ロックトランザクションを発行することにより、ＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタを更新し、更にＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタを更新し、これによりチャンネル及び帯域を確保することができる。このとき、チャンネルと帯域が正常に確保される場合はロックトランザクションによるレジスタ更新に成功するが、チャンネル又は帯域が確保できない場合はロックトランザクションによるレジスタ更新に失敗することになる。
【００４１】
次に図２は、ＩＥＥＥ１３９４のバス上に接続された複数の情報伝送機器が相互にデータを伝送可能なデータ伝送システムの概念を示す図である。ＩＥＥＥ１３９４では、各情報伝送機器どうしの従来の物理的な信号接続に代わり、論理的な信号接続を行うためのプラグの概念が導入される。よって、ＩＥＥＥ１３９４のバス上でデータを送受信する際は、各情報伝送機器の仮想的なプラグを介して制御される。
【００４２】
図２においては、３台の情報伝送機器としてのＡＶ機器２１、２２、２３がＩＥＥＥ１３９４上に接続されている場合を例に示している。各ＡＶ機器２１〜２３は、データ出力に用いる出力プラグとデータ入力に用いる入力プラグとを仮想的に備えており、特定のＡＶ機器の出力プラグを経由してアイソクロナスデータがバス上に送出され、他のＡＶ機器の入力プラグを経由してアイソクロナスデータを受け取ることによりデータ転送を行うことができる。
【００４３】
図２に示すように、各ＡＶ機器２１、２２は、出力プラグの属性を制御する出力プラグ制御レジスタ（ｏＰＣＲ：output plug control register）と、ＡＶ機器のｏＰＣＲに共通の属性を制御する出力マスタープラグレジスタ（ｏＭＰＲ：output master plug register）を備えている。また、各ＡＶ機器２１、２３は、入力プラグの属性を制御する入力プラグ制御レジスタ（ｉＰＣＲ：input plug control register）と、ＡＶ機器のｉＰＣＲに共通の属性を制御する入力マスタープラグレジスタ（ｉＭＰＲ：input master plug register）を備えている。
【００４４】
なお、１つのＡＶ機器でプラグ数は最大３１個まで設定可能であるため、ｏＰＣＲとｉＰＣＲは、それぞれ１つのＡＶ機器において０個から最大３１個まで存在可能である。一方、１つのＡＶ機器においてｏＰＣＲとｉＰＣＲが多数存在する場合であっても、ｏＭＰＲとｉＭＰＲはそれぞれ１個存在するだけである。図２の例では、ＡＶ機器２１はｉＭＰＲ、ｉＰＣＲ、ｏＭＰＲ，ｏＰＣＲをそれぞれ１個づつ持ち、ＡＶ機器２２はｉＭＰＲ、ｉＰＣＲ、ｏＭＰＲをそれぞれ１個づつと２個のｏＰＣＲを持ち、ＡＶ機器２３は１個のｉＭＰＲと２個のｉＰＣＲを持っているとともに、各ＡＶ機器２１〜２３のプラグ間を結ぶ２系統のアイソクロナスチャンネルが確立されていることがわかる。
【００４５】
ここで、上記のｏＰＣＲ及びｉＰＣＲのデータフォーマットについて図３と図４を用いて説明する。図３に示すように、ｏＰＣＲのデータフォーマットは、出力プラグの接続がオン又はオフのいずれであるかを示すオンラインフラグと、出力プラグを経由する後述のbroadcastコネクションの個数を示すbroadcastコネクションカウンタと、出力プラグを経由する後述のPoint-to-pointコネクションの個数を示すPoint-to-pointコネクションカウンタと、将来の機能拡張用の予備領域と、アイソクロナスデータの転送に用いるチャンネルの番号を示すチャンネル番号と、データを転送する際の転送速度を表すデータ転送速度と、アイソクロナスデータに付加されるオーバーヘッド量を示すオーバーヘッドＩＤと、１サイクルごとに転送されるデータ量を示すペイロードを含んでいる。
【００４６】
また、図４に示すように、ｉＰＣＲのデータフォーマットは、入力プラグの接続がオン又はオフのいずれであるかを示すオンラインフラグと、入力プラグを経由する後述のbroadcastコネクションの個数を示すbroadcastコネクションカウンタと、入力プラグを経由する後述のPoint-to-pointコネクションの個数を示すPoint-to-pointコネクションカウンタと、将来の機能拡張用の２つの予備領域と、アイソクロナスデータの転送に用いるチャンネルの番号を示すチャンネル番号を含んでいる。
【００４７】
なお、上述のｏＰＣＲ及びｉＰＣＲのデータ内容を変更する場合、変更対象となるｏＰＣＲ又はｉＰＣＲを所有するＡＶ機器自らが変更することも可能であるとともに、他のＡＶ機器がＩＥＥＥ１３９４のバスを介してロックトランザクションを発行することにより変更することも可能である。このようなロックトランザクションを用いる場合、要求側から応答側にデータを転送するとともに、応答側の特定のアドレスでデータを処理した後、要求側に返送するという手順に従って処理が行われる。
【００４８】
一方、上述した通り、各ＡＶ機器間のアイソクロナスデータの転送は、図２に示すように、ＩＥＥＥ１３９４のバス上に設定されたアイソクロナスチャンネルを経由して行われる。このアイソクロナスチャンネルは、各ＡＶ機器の入力プラグと出力プラグを結び付けるパスとして機能し、上述のＰＣＲを適切に設定することにより所望のアイスクロナスチャンネルを設定することができる。各ＡＶ機器のアイソクロナスチャンネルへのコネクションの形態としては、Point-to-pointコネクションと、broadcastコネクションの２種類がある。
【００４９】
Point-to-pointコネクションは、特定のＡＶ機器の１つの出力プラグ（ｏＰＣＲ）と他のＡＶ機器の１つの入力プラグ（ｉＰＣＲ）とを、１つのアイソクロナスチャンネルに結び付けるコネクションの形態である。なお、１つのプラグに既に存在するpoint-to-pointコネクションに対し、別のPoint-to-point コネクションを存在させることも可能である。
【００５０】
また、Broadcastコネクションには、特定のＡＶ機器の１つの出力プラグ（ｏＰＣＲ）を１つのアイソクロナスチャンネルに結び付けるコネクションの形態であるBroadcast-outコネクション、及び、特定のＡＶ機器の１つの入力プラグ（ｉＰＣＲ）を１つのアイソクロナスチャンネルに結び付けるコネクションの形態であるBroadcast-inコネクションの２つがある。
【００５１】
次に、本実施形態におけるＩＥＥＥ１３９４バス上のデータ伝送システムでバスリセットが発生した場合の処理について説明する。データ伝送システムに対し、新たなノードがバスに接続されたり、接続中のノードがバスから外れたりする状況が生じた場合、バス上の全てのノードにバスリセット信号が伝送され、トポロジー情報はいったん全てクリアされ、状況の変化に応じた新たなトポロジーを構築するための初期化処理が実行される。
【００５２】
バスリセットが発生すると、各ノードのコネクションの確立時に取得されたアイソクロナスリソースやプラグが全てリセットされ、コネクションが解除されることになるが、バスリセット発生タイミングから１秒間はアイソクロナスデータの転送が継続される。よって、各ノードは、バスリセットが発生してから１秒以内に、新たなトポロジー情報に対応してアイソクロナスリソースの確保と各プラグの更新を行い、コネクションを回復するための処理を行う必要がある。ＩＥＥＥ１３９４バス上におけるコネクション回復処理は多数のプロセスからなり、実際にはアイソクロナスリソースの確保やトランザクションによるレジスタ更新に失敗する場合も想定されるので、１秒間ではコネクションが回復できないものも残る場合がある。本実施形態では、後述するように合理的な手順によりバスリセット時の回復不可能なコネクションを最低限に抑えることができる。
【００５３】
次に、図５〜１５を参照して、本実施形態におけるバスリセット時のコネクション回復処理について具体的に説明する。ここで、本実施形態ではＩＥＥＥ１３９４バス上のメモリ手段において各プラグのコネクション情報データベースを構成し、バスリセット時のコネクション回復処理において必要となる各種データを保持する。図５は、このようなコネクション情報データベースの構成を示す図である。図５に示すコネクション情報データベースは、本実施形態のコネクション情報記録手段としての役割を担い、各出力プラグに対応するｏＰＣＲ情報と、各入力プラグに対応するｉＰＣＲ情報と、各コネクションに対応するPoint-to-pointコネクション情報とを含んで構成される。
【００５４】
図５（ａ）に示すｏＰＣＲ情報は、Broadcast-outコネクションのステータスと、Broadcast-outコネクションの回復処理で実行すべき処理プロセスと、上記ｏＰＣＲ中のbroadcastコネクションカウンタ及びオーバーヘッドＩＤ（図３）を含んでいる。また、図５（ｂ）に示すｉＰＣＲ情報は、Broadcast-inコネクションのステータスと、ｉＰＣＲ中のbroadcastコネクションカウンタ（図４）を含んでいる。また、図５（ｃ）に示すPoint-to-pointコネクション情報は、Point-to-pointコネクションのステータスと、Point-to-pointコネクションの回復処理で実行すべき処理プロセスと、送信側ノードのＧＵＩＤ及びプラグＩＤと、受信側ノードのＧＵＩＤ及びプラグＩＤと、ｏＰＣＲ中のデータ転送速度、オーバーヘッドＩＤ、ペイロード、チャンネル番号（図３）を含んでいる。
【００５５】
コネクション情報データベースに含まれる各ステータスは、それぞれのコネクション回復処理についての回復状態に応じて変化し、コネクション回復処理の状態が有効であるときはＶＡＬＩＤ、無効であるときはＩＮＶＡＬＤ、不定であるときはＵＮＫＮＯＷＮ、コネクションの回復中であるときはＰＥＮＤＩＮＧの４つの値をとる。なお、バスリセット直後、有効なコネクションが存在する場合には各ステータスがＰＥＮＤＩＮＧにセットされる。
【００５６】
また、ｏＰＣＲ情報とPoint-to-pointコネクション情報に含まれる処理プロセスは、各コネクション回復処理を細分化して分割実行される各々の処理プロセスのうち、実行すべき最新の処理プロセスを保持するパラメータである。更に、Point-to-pointコネクション情報に含まれるＧＵＩＤは、各ＡＶ機器に固有のＩＤであり、ＩＥＥＥ１３９４バス上に接続されたＡＶ機器を特定するためのパラメータであり、ＣＳＲアーキテクチャで規定されるコンフィギュレーションＲＯＭに記述されている。バスリセット時のコネクション回復処理の際にＧＵＩＤを取得することにより、上記のノードＩＤとの対応関係を明確にできるが、具体的な処理については後述する。
【００５７】
次に図６は、バスリセット時に特定のノードにおいて実行されるコネクション回復処理の概略を示すフローチャートである。図６に示すように、まず、ＩＥＥＥ１３９４バス上のノード接続の変更に起因し、所定のタイミングでバスリセットが発生する（ステップＳ１）。そして、バスリセット時のコネクション回復処理を行うのに先立って、対象ノードのコネクション情報データベースの各ステータスを初期化する（ステップＳ２）。この場合、ステータスがＶＡＬＩＤであるときはＰＥＮＤＩＮＧにセットし、ステータスがＵＮＫＮＯＷＮであるときはＩＮＶＡＬＩＤにセットし、ステータスがＩＮＶＡＬＩＤ又はＰＥＮＤＩＮＧであるときはその値を保持する。
【００５８】
続いて、コネクション回復処理の実行順を登録する回復コネクションキューを初期化する（ステップＳ３）。この回復コネクションキューは、ＩＥＥＥ１３９４バス上の各ノードのファームウェア等で実現されるＦＩＦＯで構成され、コネクション回復処理に含まれる各処理を順次登録し、その実行順を制御する登録手段としての役割を担う。すなわち、本実施形態では対象ノードについて実行すべきコネクション回復処理として、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理に加え、ＧＵＩＤ取得処理の４つの処理に大別している。よって、これら４つの処理をコード化して回復コネクショキューに必要に応じて登録し、登録された順序で順次実行するように制御される。そして、ステップＳ３の初期化時には、ＧＵＩＤ取得処理、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理の順に回復コネクションキューに登録し、最初はこの順に従って各回復処理が実行される。
【００５９】
次に、バスリセット時点からの経過時間を監視し、１秒が経過したか否かを判断する（ステップＳ４）。その結果、バスリセット時点から１秒経過していない場合は（ステップＳ４；ＮＯ）、続いてコネクション情報データベースのいずれかのステータスがＰＥＮＤＩＮＧにセットされているか否かを判断する（ステップＳ５）。
【００６０】
ステップＳ４、Ｓ５の判断の結果、バスリセット時点から１秒経過した場合（ステップＳ４；ＹＥＳ）、あるいは、ＰＥＮＤＩＮＧのステータスが存在しない場合には（ステップＳ５；ＮＯ）、全てのステータス中にＵＮＫＮＯＷＮのステータスが所定数以上あるか否かを判断する（ステップＳ６）。その結果、ＵＮＫＮＯＷＮのステータスが所定数以上存在する場合は（ステップＳ６；ＹＥＳ）、バスリセットを発生させ（ステップＳ７）、図６の処理を終える。これにより、各コネクション回復処理において不定の状態が多く、コネクションを正常に回復できないと判断される場合、コネクション回復処理をやり直すべくバスリセット発生により図６の処理を再度実行させることができる。一方、ＵＮＫＮＯＷＮのステータスが所定数に満たない場合は（ステップＳ６；ＮＯ）、ステップＳ７を行うことなく図６の処理を終え、回復されたコネクションによりデータ伝送を行うことができる。
【００６１】
一方、ステップＳ５の判断の結果、ＰＥＮＤＩＮＧのステータスがあると判断された場合（ステップＳ５；ＹＥＳ）、上記の回復コネクションキューを参照し、その内容に応じた処理を実行する（ステップＳ８）。上述したように、回復コネクションキューに登録された実行順に従って、ＧＵＩＤの取得処理（ステップＳ９）、Broadcast-outコネクションの回復処理（ステップＳ１０）、Broadcast-inコネクションの回復処理（ステップＳ１１）、Point-to-pointコネクションの回復処理（ステップＳ１２）のいずれかを順次実行する。以下、これら４つの各処理についてそれぞれ説明する。
【００６２】
まず、ＧＵＩＤの取得処理（ステップＳ９）では、対象ノードのＡＶ機器に設定された上記コンフィグレーションＲＯＭを読み出してＧＵＩＤの取得を行う。この時点で全てのノードについてのＧＵＩＤを取得した場合は、そのままステップＳ９を終える。一方、何らかの要因でＧＵＩＤを取得できないノードが残っている場合は、次の機会にＧＵＩＤを取得すべく、回復コネクションキューにＧＵＩＤの取得処理を登録する。
【００６３】
次に、図７〜図１０のフローチャートを用いて、ステップＳ１０のBroadcast-outコネクションの回復処理について説明する。図７に示すように、回復コネクションキューに従ってBroadcast-outコネクションの回復処理が開始されると、コネクション情報データベースのｏＰＣＲ情報にアクセスし、上記の処理プロセスによって判別される個別の処理を実行する（ステップＳ１０１）。Broadcast-outコネクションの回復処理は、処理プロセスが１から６まで計６つの個別の処理に分割されている。なお、処理プロセスの初期値は１に設定されているものとする。
【００６４】
ステップＳ１０１の判断に基づき処理プロセス１が実行される場合は、対象ノードについてチャンネルの確保を実行する（ステップＳ１０２）。すなわち、ＣＳＲ空間のＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタにアクセスし、所望のチャンネルに対応して更新を行うことによりチャンネルが確保される。次いで、ステップＳ１０２の処理がタイムアウト又はデータエラーとなるか否かを判断する（ステップＳ１０３）。ステップＳ１０３の判断結果が「ＹＥＳ」である場合はチャンネルが確保できないので、これ以降の処理を行うことなくステップＳ１２１（図１０）に移行する。なお、本実施形態では、タイムアウトを判定する経過時間を１サイクル＝１２５μｓｅｃとして８００サイクル（＝１００ｍｓｅｃ）に設定する。
【００６５】
ステップＳ１０３の判断結果が「ＮＯ」であるときは、所望のチャンネルの確保に成功したか否かを判断する（ステップＳ１０４）。例えば、他のノードにより所望のチャンネルが既に使用されている場合は、そのチャンネルを確保することはできない。そして、チャンネルの確保に失敗したときは（ステップＳ１０４；ＮＯ）処理プロセスを２に設定し（ステップＳ１０５）、チャンネルの確保に成功したときは（ステップＳ１０４；ＹＥＳ）処理プロセスを３に設定する（ステップＳ１０６）。ステップＳ１０５又はステップＳ１０６を終えると、ステップＳ１２４（図１０）に移行する。
【００６６】
次に、ステップＳ１０１の判断に基づき処理プロセス２が実行される場合は、接続可能な出力プラグに対しｏＰＣＲのポーリングを実行する（ステップＳ１０７）。これは、処理プロセス１にてチャンネル確保に失敗した場合であっても、使用すべきチャンネルに対してオーバレイを行う可能性を考慮したものである。このオーバーレイは、ソースノードとｏＰＣＲが同一である場合、既に存在するそのｏＰＣＲ上のコネクションに対して、別のコネクションを重ねたり、Point-to-pointコネクションの上にBroadcast-outコネクション又はPoint-to-pointコネクションを重ねて設定することである。ステップＳ１０７では、他のノードによりオーバーレイが行われることを想定し、各出力プラグのｏＰＣＲのPoint-to-pointコネクションカウンタがバスリセット後に更新されるか否かを監視すべく、ｏＰＣＲのポーリングを行うものである。
【００６７】
次いで、ステップＳ１０７でポーリングされたｏＰＣＲが更新されたか否かを判断する（ステップＳ１０８）。例えば、元々Point-to-pointコネクションの値が０であるとき更新されると値は１に変化する。ステップＳ１０８の判断結果が「ＮＯ」であるときは、ステップＳ１２４（図１０）に移行する。一方、ステップＳ１０８の判断結果が「ＹＥＳ」であるときは、処理プロセスを４に設定する（ステップＳ１０９）。ステップＳ１０９を終えると、ステップＳ１２４（図１０）に移行する。
【００６８】
次に図８に示すように、ステップＳ１０１の判断に基づき処理プロセス３が実行される場合は、対象ノードについて帯域の確保を実行する（ステップＳ１１０）。すなわち、ＣＳＲ空間のＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタにアクセスし、転送に必要となる帯域に対応して更新を行うことにより帯域が確保される。次いで、ステップＳ１１０の処理がタイムアウト（８００サイクル（＝１００ｍｓｅｃ）経過時点）又はデータエラーとなるか否かを判断する（ステップＳ１１１）。ステップＳ１１１の判断結果が「ＹＥＳ」であるときは、帯域が確保できないので、これ以降の処理を行うことなくステップＳ１２１に（図１０）に移行する。
【００６９】
一方、ステップＳ１１１の判断結果が「ＮＯ」であるときは、必要な帯域の確保に成功したか否かを判断する（ステップＳ１１２）。例えば、空いている帯域が必要な帯域に不足している場合は、その帯域を確保することはできない。そして、帯域の確保に成功したときは（ステップＳ１１２；ＹＥＳ）、処理プロセスを４に設定し（ステップＳ１１３）、帯域の確保に失敗したときは（ステップＳ１１２；ＮＯ）、処理プロセスを６に設定する（ステップＳ１１４）。ステップＳ１１３又はステップＳ１１４を終えると、ステップＳ１２４（図１０）に移行する。
【００７０】
次に、ステップＳ１０１の判断に基づき処理プロセス４が実行される場合は、対象ノードの出力プラグに対し、ｏＰＣＲの更新を実行する（ステップＳ１１５）。すなわち、処理プロセス１及び３により確保されたチャンネル及び帯域に対応する値をｏＰＣＲのチャンネル番号やデータ転送速度に設定するとともに、broadcastコネクションカウンタをインクリメントする。そして、ステップＳ１１５の結果、ｏＰＣＲの更新に成功したか否かを判断し（ステップＳ１１６）、判断結果が「ＹＥＳ」であるときは、ステップＳ１２２（図１０）に移行し、判断結果が「ＮＯ」であるときは、処理プロセスを５に設定する（ステップＳ１１７）。ステップＳ１１７を終えると、ステップＳ１２４（図１０）に移行する。
【００７１】
次に図９に示すように、ステップＳ１０１の判断に基づき処理プロセス５が実行される場合は、ステップＳ１１２で確保された帯域の解放を実行する（ステップＳ１１８）。すなわち、処理プロセス４でｏＰＣＲの更新に失敗したため、この時点では所望のBroadcast-outコネクションを回復できないと判断され、確保した帯域をいったん解放すべくステップＳ１１８を実行するのである。その後、処理プロセスを６に設定し（ステップＳ１１９）、ステップＳ１２４（図１０）に移行する。
【００７２】
また、ステップＳ１０１の判断に基づき処理プロセス６が実行される場合は、ステップＳ１０２で確保されたチャンネルの解放を実行する（ステップＳ１２０）。すなわち、上述した処理プロセスと同様の理由により、確保したチャンネルをいったん解放すべくステップＳ１２０を実行するのである。この処理プロセス６に続いてステップＳ１２３（図１０）に移行する。
【００７３】
次に、Broadcast-outコネクションの回復処理において、各処理プロセス１〜６に後続する処理について図１０のフローチャートを用いて説明する。図１０におけるステップＳ１２１〜Ｓ１２４は、コネクション情報データベースの対象となるステータスに関する処理である。
【００７４】
まず、処理プロセス１のステップＳ１０３（図７）又は処理プロセス３のステップＳ１１１（図８）から移行した場合は、ステータスをＵＮＫＮＯＷＮにセットする（ステップＳ１２１）。この場合は、タイムアウト又はデータエラーと判断されたので、この時点で処理対象のコネクションが正常に回復できる否かが不定の状態にある。
【００７５】
また、処理プロセス４のステップＳ１１６（図８）から移行した場合は、ステータスをＶＡＬＩＤにセットする（ステップＳ１２２）。この場合は、チャンネルと帯域の確保及びｏＰＣＲの更新に成功し、この時点で処理対象のコネクションが回復して有効な状態にある。
【００７６】
また、処理プロセス６のステップＳ１２０（図９）から移行した場合は、ステータスをＩＮＶＡＬＩＤにセットする（ステップＳ１２３）。この場合は、上述した理由でチャンネルと帯域を解放したので、この時点で処理対象のコネクションが回復できず無効な状態にある。
【００７７】
また、各処理プロセス１〜６において、次に実行すべき処理プロセスの設定後に移行した場合、あるいは、処理プロセス２のステップＳ１０８（図７）から移行した場合は、ステータスを変えずに元の値を維持する（ステップＳ１２４）。この場合は、対象のコネクション回復処理を継続する必要があり、更に処理が進行した時点でステータスを更新すればよい。
【００７８】
ステップＳ１２１〜Ｓ１２４に続いて、対象ノードの全ての出力プラグについてBroadcast-outコネクションの回復処理を終了したか否かを判断する（ステップＳ１２５）。その結果、未終了の出力プラグがある場合は（ステップＳ１２５；ＮＯ）、回復コネクションキューにBroadcast-outコネクションの回復処理を登録し（ステップＳ１２６）、図１０の処理を終える。これにより、残存するBroadcast-outコネクションの回復処理については、後に回復コネクションキューの順序に従って図７〜図１０の処理が再度実行されることになる。一方、全ての出力プラグについて上記処理を終了した場合は（ステップＳ１２５；ＹＥＳ）、又はステップＳ１２６の終了後は、図１１の処理を終えてステップＳ１３（図６）に移行する。
【００７９】
次に、図１１のフローチャートを用いて、ステップＳ１１のBroadcast-inコネクションの回復処理について説明する。ここでは、入力プラグについてのｉＰＣＲに関する処理を行うこととし、出力プラグを経由するBroadcastコネクションに対するチャンネル及び帯域の確保に関しては、上述のBroadcast-outコネクションの回復処理において実行されることになる。よって、Broadcast-inコネクションの回復処理は、Broadcast-outコネクションの回復処理のように複数の処理プロセスに細分化する必要はない。
【００８０】
図１１において、回復コネクションキューに従ってBroadcast-inコネクションの回復処理が開始されると、対象ノードの入力プラグに対し、ｉＰＣＲの更新を実行する（ステップＳ２０１）。すなわち、受信すべきチャンネル番号に設定するとともに、broadcastコネクションカウンタをインクリメントする。続いて、ステップＳ２０１の結果、ｉＰＣＲの更新に成功したか否かを判断する（ステップＳ２０２）。
【００８１】
ステップＳ２０２の判断結果が「ＹＥＳ」となりｉＰＣＲの更新に成功した場合は、コネクション情報データベースの対象となるステータスをＶＡＬＩＤにセットする（ステップＳ２０３）。一方、ステップＳ２０２の判断結果が「ＮＯ」となりｉＰＣＲの更新に失敗したときは、上記ステータスをＩＮＶＡＬＩＤにセットする（ステップＳ２０４）。そして、対象ノードの全ての入力プラグについてBroadcast-inコネクションの回復処理を終了したか否かを判断し（ステップＳ２０５）。その結果、未終了の入力プラグがある場合は（ステップＳ２０５；ＮＯ）、回復コネクションキューにBroadcast-inコネクションの回復処理を登録し（ステップＳ２０６）、図１１の処理を終える。一方、全ての入力プラグについて上記処理を終了した場合は（ステップＳ２０５；ＹＥＳ）、ステップＳ２０６を行うことなく図１１の処理を終える。これにより、残存するBroadcast-inコネクションの回復処理については、後に回復コネクションキューの順序に従って図１１の処理が再度実行されることになる。
【００８２】
次に、図１２〜図１５のフローチャートを用いて、ステップＳ１２のPoint-to-pointコネクションの回復処理について説明する。図１２に示すように、回復コネクションキューに従ってPoint-to-pointコネクションの回復処理が開始されると、コネクション情報データベースのPoint-to-pointコネクション情報にアクセスし、上記の処理プロセスによって判別される個別の処理を実行する（ステップＳ３０１）。Point-to-pointコネクションの回復処理は、処理プロセスが１から８までの計８つの個別の処理に分割され、上記のBroadcast-outコネクションの回復処理よりも更に多くなっている。この場合も、処理プロセスの初期値は１に設定されているものとする。
【００８３】
図１２に示すように、ステップＳ３０１の判断に基づき処理プロセス１が実行される場合は、Point-to-pointコネクションで必要なＧＵＩＤが既知であるか否かを判断する（ステップＳ３０２）。すなわち、Point-to-pointコネクションでは入力プラグと出力プラグの双方が存在するので、それぞれのノードのＡＶ機器が判別可能であることが前提となるため、図６のステップＳ９に基づきＧＵＩＤが取得済みであることを確認するものである。または、バスリセット後に受信したアイソクロナスパケットから送信ノードを特定することで、バスリセット前に接続されていたＡＶ機器と判別するようにしてもよい。その結果、ＧＵＩＤが未知であるときは（ステップＳ３０２；ＮＯ）、これ以降の処理を行うことなくステップＳ３３３（図１５）に移行する。
【００８４】
一方、ＧＵＩＤが既知であるときは（ステップＳ３０２；ＹＥＳ）、回復すべきPoint-to-pointコネクションで用いるチャンネルの確保を実行する（ステップＳ３０３）。すなわち、ＣＳＲ空間のＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタにアクセスし、上記のチャンネルに対応して更新を行うことによりチャンネルが確保される。次いで、ステップＳ３０３の処理がタイムアウト（８００サイクル（＝１００ｍｓｅｃ）経過時点）又はデータエラーとなるか否かを判断する（ステップＳ３０４）。ステップＳ３０４の判断結果が「ＹＥＳ」である場合はチャンネルが確保できないので、これ以降の処理を行うことなくステップＳ３３０（図１５）に移行する。
【００８５】
ステップＳ３０４の判断結果が「ＮＯ」である場合は、所望のチャンネルの確保に成功したか否かを判断する（ステップＳ３０５）。その結果、チャンネルの確保に失敗したときは（ステップＳ３０５；ＮＯ）処理プロセスを２に設定し（ステップＳ３０６）、チャンネルの確保に成功したときは（ステップＳ３０５；ＹＥＳ）処理プロセスを３に設定する（ステップＳ３０７）。ステップＳ３０７を終えると、ステップＳ３３３（図１５）に移行する。
【００８６】
次に、ステップＳ３０１の判断に基づき処理プロセス２が実行される場合は、接続可能な出力プラグに対しｏＰＣＲのポーリングを実行する（ステップＳ３０８）。これは、Broadcast-outコネクションの回復処理の処理プロセス２と同様に、BroadcastコネクションとPoint-to-pointコネクションのオーバレイを考慮した処理である。すなわち、ステップＳ３０８では、他のノードによりオーバーレイが行われることを想定し、各出力プラグのｏＰＣＲのPoint-to-pointコネクションカウンタがバスリセット後に更新されるか否かを監視すべく、ｏＰＣＲのポーリングを行うものである。
【００８７】
次いで、ステップＳ３０８でポーリングされたｏＰＣＲが更新されたか否かを判断する（ステップＳ３０９）。そして、ステップＳ３０９の判断結果が「ＮＯ」であるときは、ステップＳ３３３（図１５）に移行する。一方、ステップＳ３０９の判断結果が「ＹＥＳ」であるときは、処理プロセスを４に設定し（ステップＳ３１０）、ステップＳ３３３（図１５）に移行する。
【００８８】
次に図１３に示すように、ステップＳ３０１の判断に基づき処理プロセス３が実行される場合は、転送に必要な帯域の確保を実行する（ステップＳ３１１）。すなわち、ＣＳＲ空間のＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタにアクセスし、転送に必要となる帯域に対応して更新を行うことにより帯域が確保される。次いで、ステップＳ３１１の処理がタイムアウト（８００サイクル（＝１００ｍｓｅｃ）経過時点）又はデータエラーとなるか否かを判断する（ステップＳ３１２）。ステップＳ３１２の判断結果が「ＹＥＳ」であるときは、これ以降の処理を行うことなくステップＳ３３０（図１５）に移行する。
【００８９】
一方、ステップＳ３１２の判断結果が「ＮＯ」であるときは、必要な帯域の確保に成功したか否かを判断する（ステップＳ３１３）。そして、帯域の確保に成功したときは（ステップＳ３１３；ＹＥＳ）、処理プロセスを４に設定し（ステップＳ３１４）、帯域の確保に失敗したときは（ステップＳ３１３；ＮＯ）、処理プロセスを８に設定する（ステップＳ３１５）。ステップＳ３１４又はステップＳ３１５を終えると、ステップＳ３３３（図１５）に移行する。
【００９０】
次に、ステップＳ３０１の判断に基づき処理プロセス４が実行される場合は、Point-to-pointコネクションの送信側の出力プラグに対し、ｏＰＣＲの更新を実行する（ステップＳ３１６）。ここでは、Point-to-pointコネクション確立側のノードが更新対象のノードと異なる場合を前提とする。この場合、更新対象のノードに対してトランザクションを発行することにより、処理プロセス１及び３により確保されたチャンネル及び帯域に対応する値をｏＰＣＲのチャンネル番号やデータ転送速度に設定するとともに、Point-to-pointコネクションカウンタをインクリメントする。そして、ステップＳ３１６の処理がタイムアウト（８００サイクル（＝１００ｍｓｅｃ）経過時点）又はデータエラーとなるか否かを判断し（ステップＳ３１７）。判断結果が「ＹＥＳ」であるときは、これ以降の処理を行うことなくステップＳ３３１（図１５）に移行する。
【００９１】
一方、ステップＳ３１７の判断結果が「ＮＯ」であるときは、ｏＰＣＲの更新に成功したか否かを判断する（ステップＳ３１８）。その結果、ｏＰＣＲの更新に成功した場合は（ステップＳ３１８；ＹＥＳ）、処理プロセスを５に設定し（ステップＳ３１９）、ｏＰＣＲの更新に失敗した場合は（ステップＳ３１８；ＮＯ）、処理プロセスを７に設定する（ステップＳ３２０）。ステップＳ３１９又はステップＳ３２０を終えると、ステップＳ３３３（図１５）に移行する。
【００９２】
次に図１４に示すように、ステップＳ３０１の判断に基づき処理プロセス５が実行される場合は、Point-to-pointコネクションの受信側の入力プラグに対し、ｉＰＣＲの更新を実行する（ステップＳ３２１）。上述したように、Point-to-pointコネクション確立側のノードが更新対象のノードと異なる場合を前提とする。この場合、更新対象のノードに対してトランザクションを発行することにより、処理プロセス１により確保されたチャンネルをｉＰＣＲのチャンネル番号に設定するとともに、Point-to-pointコネクションカウンタをインクリメントする。そして、ステップＳ３２１の処理がタイムアウト（８００サイクル（＝１００ｍｓｅｃ）経過時点）又はデータエラーとなるか否かを判断し（ステップＳ３２２）。判断結果が「ＹＥＳ」であるときは、これ以降の処理を行うことなくステップＳ３３０（図１５）に移行する。
【００９３】
一方、ステップＳ３２２の判断結果が「ＮＯ」であるときは、ｉＰＣＲの更新に成功したか否かを判断する（ステップＳ３２３）。その結果、ｉＰＣＲの更新に成功した場合は（ステップＳ３２３；ＹＥＳ）、ステップＳ３３１（図１５）に移行し、ｉＰＣＲの更新に失敗した場合は（ステップＳ３２３；ＮＯ）、処理プロセスを６に設定する（ステップＳ３２４）。ステップＳ３２４を終えると、ステップＳ３３３（図１５）に移行する。
【００９４】
次に、ステップＳ３０１の判断に基づき処理プロセス６が実行される場合は、上記の処理プロセス４にて更新されたｏＰＣＲの解放を実行する（ステップＳ３２５）。これは、処理プロセス４において送信側の出力プラグに対しｏＰＣＲを更新したにもかかわらず、処理プロセス５において受信側の入力プラグに対するｉＰＣＲを更新できなかった場合の処理である。すなわち、この時点では所望のPoint-to-pointコネクションを回復できないと判断されるので、いったんｏＰＣＲの状態を元に戻すべくステップＳ３２５を実行するのである。その後は処理プロセスを７に設定し（ステップＳ３２６）、ステップＳ３３３（図１５）に移行する。
【００９５】
次に、ステップＳ３０１の判断に基づき処理プロセス７が実行される場合は、ステップＳ３１１で確保された帯域の解放を実行する（ステップＳ３２７）。これは、処理プロセス４において送信側の出力プラグに対するｏＰＣＲを更新できなかった場合、又は、処理プロセス５において受信側の入力プラグに対するｉＰＣＲを更新できなった場合の処理である。いずれの場合も、この時点では所望のPoint-to-pointコネクションを回復できないと判断され、確保した帯域をいったん解放すべくステップＳ３２７を実行するのである。その後、処理プロセスを８に設定し（ステップＳ３２８）、ステップＳ３３３（図１５）に移行する。
【００９６】
また、ステップＳ１０１の判断に基づき処理プロセス８が実行される場合は、ステップＳ３０３で確保されたチャンネルの解放を実行する（ステップＳ３２９）。すなわち、上述した処理プロセス７と同様の理由により、確保したチャンネルをいったん解放すべくステップＳ３２９を実行するのである。その後はステップＳ３３２（図１５）に移行する。
【００９７】
次に、Broadcast-inコネクションの回復処理において、各処理プロセス１〜８に後続する処理について図１５のフローチャートを用いて説明する。図１５におけるステップＳ３３０〜Ｓ３３３は、コネクション情報データベースの対象となるステータスに関する処理である。
【００９８】
まず、処理プロセス１、３、４、５にてタイムアウト又はデータエラーと判断されて移行した場合は、ステータスをＵＮＫＮＯＷＮにセットする（ステップＳ３３０）。上述したように、この時点では処理対象のコネクションが正常に回復できる否かが不定の状態にある。
【００９９】
また、処理プロセス５のステップＳ３２３（図１４）から移行した場合は、ステータスをＶＡＬＩＤにセットする（ステップＳ３３１）。この場合は、チャンネルと帯域の確保及びｏＰＣＲとｉＰＣＲの更新に成功し、この時点で処理対象のコネクションが回復して有効な状態にある。
【０１００】
また、処理プロセス８のステップＳ３２９（図１４）から移行した場合は、ステータスをＩＮＶＡＬＩＤにセットする（ステップＳ３３２）。この場合は、上述した理由でチャンネルと帯域を解放したので、この時点で処理対象のコネクションが回復できず無効な状態にある。
【０１０１】
また、各処理プロセス１〜８において、次に実行すべき処理プロセスを設定後に移行した場合、あるいは、処理プロセス２のステップＳ３０９（図１２）から移行した場合は、ステータスを変えずに元の値を維持する（ステップＳ３３３）。この場合は、コネクション回復処理を継続して実行する必要があり、更に処理が進行した時点でステータスを更新すればよい。
【０１０２】
ステップＳ３３０〜Ｓ３３３に続いて、対象ノードの全てのPoint-to-pointコネクションについて回復処理を終了したか否かを判断する（ステップＳ３３４）。その結果、未終了のPoint-to-pointコネクションがある場合は（ステップＳ３３４；ＮＯ）、回復コネクションキューにPoint-to-pointコネクションの回復処理を登録する（ステップＳ３３５）。これにより、残存するPoint-to-pointコネクションの回復処理については、後に回復コネクションキューの順序に従って図１２〜１５の処理が再度実行されることになる。一方、全てのPoint-to-pointコネクションについて上記処理を終了した場合（ステップＳ３３４；ＹＥＳ）、又はステップＳ３３５の終了後は、図１５の処理を終えてステップＳ１３（図６）に移行する。
【０１０３】
以上、図６のステップＳ８により実行順を制御される処理として、ＧＵＩＤの取得処理、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理について、それぞれ説明を行った。次に図６に戻って、ステップＳ９〜Ｓ１２に続いて、新たなバスリセットの発生の有無を検出する（ステップＳ１３）。その結果、バスリセットの発生が検出されたときは（ステップＳ１３；ＹＥＳ）、ステップＳ２に移行して再び初期化（ステップＳ３、Ｓ４）を行って最初から上記の処理を実行する。一方、バスリセットの発生が検出されないときは（ステップＳ１３；ＮＯ）、ステップＳ４以降の処理を繰り返し実行する。
【０１０４】
このように本実施形態によれば、各ノードにおけるコネクション回復に関連する処理を大きく４つに分け、その実行順を回復コネクションキューにより制御するとともに、Broadcast-outコネクションの回復処理とPoint-to-pointコネクションの回復処理は、それぞれを細分化して複数の処理プロセスを分割実行するように制御する。これにより、コネクション回復処理を時間の経過とともに切り換えて実行でき、コネクションの回復状態に基づき選択すべき処理プロセスを制御するので、各コネクション回復処理を仮想的に並列実行する効果を実現できる。よって、回復不可能なコネクションがある場合でも、時間的なロスを最小限に抑えることができ、バスリセットからの１秒間を有効活用して処理効率の向上させることができる。
【０１０５】
なお、本実施形態では、データ転送のインターフェース規格としてＩＥＥＥ１３９４を採用したデータ転送システムに対し本発明を適用した場合を説明したが、これに限られることなく、バスリセット時におけるコネクション回復処理が必要な各種データ転送システムに対し、広く本発明を適用することができる。
【０１０６】
【発明の効果】
以上説明したように本発明によれば、バスリセット時に回復すべきコネクションが多数ある場合であっても、コネクション回復処理が滞ることなく迅速に進行可能であり、処理効率及び信頼性を向上させることができるコネクション回復方法と、このコネクション回復方法を実行可能なデータ伝送システム及び情報伝送装置を構築することができる。
【図面の簡単な説明】
【図１】ＩＥＥＥ１３９４のプロトコルの構成を示すブロック図である。
【図２】ＩＥＥＥ１３９４のバス上に接続された複数の情報伝送機器によるデータ伝送システムの概念を示す図である。
【図３】ｏＰＣＲのデータフォーマットを示す図である。
【図４】ｉＰＣＲのデータフォーマットを示す図である。
【図５】コネクション情報データベースの構成を示す図である
【図６】本実施形態に係るコネクション回復処理の概略を示すフローチャートである。
【図７】 Broadcast-outコネクションの回復処理を示す第１のフローチャートである。
【図８】 Broadcast-outコネクションの回復処理を示す第２のフローチャートである。
【図９】 Broadcast-outコネクションの回復処理を示す第３のフローチャートである。
【図１０】 Broadcast-outコネクションの回復処理を示す第４のフローチャートである。
【図１１】 Broadcast-inコネクションの回復処理を示すフローチャートである。
【図１２】 Point-to-pointコネクションの回復処理を示す第１のフローチャートである。
【図１３】 Point-to-pointコネクションの回復処理を示す第２のフローチャートである。
【図１４】 Point-to-pointコネクションの回復処理を示す第３のフローチャートである。
【図１５】 Point-to-pointコネクションの回復処理を示す第４のフローチャートである。
【符号の説明】
１０…物理層
１１…リンク層
１２…トランザクション層
１３…バス管理層
２１〜２３…ＡＶ機器
Claims (16)
- 複数の情報伝送機器がバス上のノードに接続され、各ノード間でコネクションを確立してデータを伝送するデータ伝送システムにおいて、
バスリセット発生に伴い前記確立されたコネクションが解除されたとき、所定時間が経過するまでに、それぞれのノードにおいて前記コネクションを回復するコネクション回復制御手段を備え、
前記コネクション回復制御手段は、前記コネクションの種別に対応する複数のコネクション回復処理の実行順を制御するとともに、前記それぞれのコネクション回復処理を複数の処理プロセスに分割し、前記実行順に対応するコネクション回復処理に際し所定の処理プロセスを前記コネクションの回復状態に基づいて選択的に順次実行し、前記コネクション回復処理の実行順を登録された登録手段を参照することにより前記実行順を制御し、前記コネクションの回復状態に応じて前記登録手段の内容を適宜更新することを特徴とするデータ伝送システム。 - 前記バス上の各ノードには、前記コネクションの回復状態及び選択対象の前記処理プロセスを含むコネクション情報を更新可能に保持するコネクション情報記録手段が設けられることを特徴とする請求項１に記載のデータ伝送システム。
- 前記複数の処理プロセスには、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれることを特徴とする請求項１に記載のデータ伝送システム。
- 前記バスはＩＥＥＥ１３９４規格に準拠したシリアルバスであり、前記複数のコネクション回復処理には、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする請求項３に記載のデータ伝送システム。
- 前記複数の処理プロセスには、送信側の出力プラグのｏＰＣＲを更新する処理プロセスと、受信側の入力プラグのｉＰＣＲを更新する処理プロセスが含まれることを特徴とする請求項４に記載のデータ伝送システム。
- 前記コネクション情報記録手段には、前記それぞれの情報伝送機器に固有のＩＤが保持され、前記コネクション回復制御手段は、前記ＩＤの取得処理の実行順を制御することを特徴とする請求項２に記載のデータ伝送システム。
- 複数の情報伝送機器がバス上のノードに接続され、各ノード間でコネクションを確立してデータを伝送するデータ伝送システム上で、バスリセット発生に伴い前記確立されたコネクションが解除されたとき、所定時間が経過するまでに、それぞれのノードにおいて前記コネクションを回復するコネクション回復方法において、
前記コネクションの種別に対応する複数のコネクション回復処理の実行順を制御するとともに、前記それぞれのコネクション回復処理を複数の処理プロセスに分割し、前記実行順に対応するコネクション回復処理に際し所定の処理プロセスを前記コネクションの回復状態に基づいて選択的に順次実行し、前記コネクション回復処理の実行順を登録された登録手段を参照することにより前記実行順を制御し、前記コネクションの回復状態に応じて前記登録手段の内容を適宜更新することを特徴とするコネクション回復方法。 - 前記複数の処理プロセスには、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれることを特徴とする請求項７に記載のコネクション回復方法。
- 前記バスはＩＥＥＥ１３９４規格に準拠したシリアルバスであり、前記複数のコネクション回復処理には、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする請求項７に記載のコネクション回復方法。
- 前記複数の処理プロセスには、送信側の出力プラグのｏＰＣＲを更新する処理プロセスと、受信側の入力プラグのｉＰＣＲを更新する処理プロセスが含まれることを特徴とする請求項９に記載のコネクション回復方法。
- バス上のノードに接続可能で、他ノードとの間でコネクションを確立してデータを伝送する情報伝送装置において、バスリセット発生に伴い前記確立されたコネクションが解除されたとき、所定時間が経過するまでに、前記コネクションを回復するコネクション回復制御手段を備え、
前記コネクション回復制御手段は、前記コネクションの種別に対応する複数のコネクション回復処理の実行順を制御するとともに、前記それぞれのコネクション回復処理を複数の処理プロセスに分割し、前記実行順に対応するコネクション回復処理に際し所定の処理プロセスを前記コネクションの回復状態に基づいて選択的に順次実行し、前記コネクション回復処理の実行順を登録された登録手段を参照することにより前記実行順を制御し、前記コネクションの回復状態に応じて前記登録手段の内容を適宜更新することを特徴とする情報伝送装置。 - 前記コネクションの回復状態及び選択対象の前記処理プロセスを含むコネクション情報を更新可能に保持するコネクション情報記録手段が設けられることを特徴とする請求項１１に記載の情報伝送装置。
- 記複数の処理プロセスには、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれることを特徴とする請求項１１に記載の情報伝送装置。
- 前記バスはＩＥＥＥ１３９４規格に準拠したシリアルバスであり、前記複数のコネクション回復処理には、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする請求項１３に記載の情報伝送装置。
- 前記複数の処理プロセスには、送信側の出力プラグのｏＰＣＲを更新する処理プロセスと、受信側の入力プラグのｉＰＣＲを更新する処理プロセスが含まれることを特徴とする請求項１４に記載の情報伝送装置。
- 前記コネクション情報記録手段には、バス上のノードに接続された情報伝送機器に固有のＩＤが保持され、前記コネクション回復制御手段は、前記ＩＤの取得処理の実行順を制御することを特徴とする請求項１４に記載の情報伝送装置。
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001005649A JP4059423B2 (ja) | 2001-01-12 | 2001-01-12 | データ伝送システム、コネクション回復方法及び情報伝送装置 |
| EP02250191A EP1225724B1 (en) | 2001-01-12 | 2002-01-11 | Data transmission/reception system, connection restoring method and information transmission/reception apparatus |
| DE60210521T DE60210521T2 (de) | 2001-01-12 | 2002-01-11 | Datenübertragungs-Datenempfangssystem, Verfahren zur Wiederherstellung einer Verbindung und Nachrichtenübertragungs-/Nachrichtenempfangsvorrichtung |
| US10/042,390 US7227846B2 (en) | 2001-01-12 | 2002-01-11 | Data transmission/ reception system, connection restoring method and information transmission/ reception apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001005649A JP4059423B2 (ja) | 2001-01-12 | 2001-01-12 | データ伝送システム、コネクション回復方法及び情報伝送装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002217908A JP2002217908A (ja) | 2002-08-02 |
| JP4059423B2 true JP4059423B2 (ja) | 2008-03-12 |
Family
ID=18873675
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001005649A Expired - Fee Related JP4059423B2 (ja) | 2001-01-12 | 2001-01-12 | データ伝送システム、コネクション回復方法及び情報伝送装置 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US7227846B2 (ja) |
| EP (1) | EP1225724B1 (ja) |
| JP (1) | JP4059423B2 (ja) |
| DE (1) | DE60210521T2 (ja) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7389533B2 (en) * | 2002-01-28 | 2008-06-17 | Hughes Network Systems, Llc | Method and system for adaptively applying performance enhancing functions |
| EP1575229A3 (en) * | 2002-07-30 | 2007-12-12 | Yamaha Corporation | Data transmission apparatus with dynamic assignment of transmission sequences |
| US8029454B2 (en) | 2003-11-05 | 2011-10-04 | Baxter International Inc. | High convection home hemodialysis/hemofiltration and sorbent system |
| JP4502653B2 (ja) * | 2004-02-12 | 2010-07-14 | Ｎｅｃエンジニアリング株式会社 | パケット送受信装置及びそれに用いるパケット識別方法 |
| DE102004031945A1 (de) * | 2004-06-30 | 2006-03-09 | Deutsche Thomson-Brandt Gmbh | Verfahren zur Bereitstellung einer Tabelle stationsspezifischer Informationen in einem Netzwerk verteilter Stationen sowie Netzwerkstation für die Durchführung des Verfahrens |
| US7792137B2 (en) * | 2006-07-05 | 2010-09-07 | Abidanet, Llc | Self-organized and self-managed ad hoc communications network |
| CN111193769A (zh) * | 2019-11-25 | 2020-05-22 | 泰康保险集团股份有限公司 | 恢复长连接的方法、系统、装置、电子设备及存储介质 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5764930A (en) * | 1996-04-01 | 1998-06-09 | Apple Computer, Inc. | Method and apparatus for providing reset transparency on a reconfigurable bus |
| US6160796A (en) * | 1998-01-06 | 2000-12-12 | Sony Corporation Of Japan | Method and system for updating device identification and status information after a local bus reset within a home audio/video network |
| JPH11205363A (ja) | 1998-01-20 | 1999-07-30 | Nec Corp | Ｉｅｅｅ１３９４機器制御装置 |
| JP3325839B2 (ja) * | 1998-10-15 | 2002-09-17 | パイオニア株式会社 | 情報送信装置及び方法、情報受信装置及び方法並びに情報送受信装置及び方法 |
| US6169725B1 (en) * | 1998-10-30 | 2001-01-02 | Sony Corporation Of Japan | Apparatus and method for restoration of internal connections in a home audio/video system |
| JP2000341302A (ja) * | 1999-05-27 | 2000-12-08 | Sony Corp | 電子機器 |
| KR100618967B1 (ko) * | 1999-07-01 | 2006-08-31 | 삼성전자주식회사 | 디지털 인터페이스 연결 관리 방법 |
-
2001
- 2001-01-12 JP JP2001005649A patent/JP4059423B2/ja not_active Expired - Fee Related
-
2002
- 2002-01-11 DE DE60210521T patent/DE60210521T2/de not_active Expired - Lifetime
- 2002-01-11 US US10/042,390 patent/US7227846B2/en not_active Expired - Fee Related
- 2002-01-11 EP EP02250191A patent/EP1225724B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| EP1225724B1 (en) | 2006-04-12 |
| US20020093977A1 (en) | 2002-07-18 |
| DE60210521T2 (de) | 2006-11-23 |
| US7227846B2 (en) | 2007-06-05 |
| EP1225724A2 (en) | 2002-07-24 |
| EP1225724A3 (en) | 2005-02-02 |
| JP2002217908A (ja) | 2002-08-02 |
| DE60210521D1 (de) | 2006-05-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6810452B1 (en) | Method and system for quarantine during bus topology configuration | |
| JP2004363687A (ja) | 情報通信装置、そのシステム、その方法、そのプログラム、および、そのプログラムを記録した記録媒体 | |
| EP1199840A1 (en) | Method for connecting an IEEE1394 remote device to a cluster of IEEE1394 devices through a wireless link | |
| EP1327328B1 (en) | Method for linking several communication busses using wireless links | |
| JP4059423B2 (ja) | データ伝送システム、コネクション回復方法及び情報伝送装置 | |
| JP2003174486A (ja) | 情報通信装置、情報通信方法および情報通信処理プログラム | |
| US6647446B1 (en) | Method and system for using a new bus identifier resulting from a bus topology change | |
| JP4166956B2 (ja) | データ伝送システム、コネクション確立方法及び情報伝送装置 | |
| EP1193914A2 (en) | Data transmission and reception | |
| US20040057448A1 (en) | Information processing system, information processing apparatus, and information processing method | |
| CN1321512C (zh) | 管理包括多于两个无线设备的无线链路的通信网络的方法 | |
| JP4627456B2 (ja) | 通信システム、サイクルマスタノード及び通信方法 | |
| US20050013252A1 (en) | Data rate setting apparatus, data rate setting method, data rate setting program, and information recording medium | |
| JP2003289314A (ja) | ローカルバスブリッジ | |
| KR100677222B1 (ko) | Ｉｅｅｅ 1394 기반의 양방향 비동기 연결 방법 | |
| JP4611974B2 (ja) | Ｉｅｅｅ１３９４バスの再初期化メッセージを転送する方法、及びかかる方法を実行する装置 | |
| JP4129603B2 (ja) | 情報処理装置および方法、並びに提供媒体 | |
| JP2003051824A (ja) | 通信方法、通信システム、プログラム及び記憶媒体 | |
| WO2001038951A2 (en) | A method and system for circumscribing a topology to form ring structures | |
| EP1246400A1 (en) | Method for linking several communication busses using wireless links | |
| WO2000057289A1 (en) | A method and system for message broadcast flow control on a bus bridge interconnect | |
| JP4244474B2 (ja) | 情報処理装置及び方法 | |
| JPH11215132A (ja) | 情報処理装置および方法、並びに提供媒体 | |
| KR100546563B1 (ko) | 버스시스템에서의 기기간 연결 제어방법 | |
| JP4161186B2 (ja) | アシンクロナス転送機能つきネットワーク通信機器 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060308 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071106 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071122 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20071212 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071214 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101228 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101228 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111228 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |