JP4166956B2 - データ伝送システム、コネクション確立方法及び情報伝送装置 - Google Patents
データ伝送システム、コネクション確立方法及び情報伝送装置 Download PDFInfo
- Publication number
- JP4166956B2 JP4166956B2 JP2001005648A JP2001005648A JP4166956B2 JP 4166956 B2 JP4166956 B2 JP 4166956B2 JP 2001005648 A JP2001005648 A JP 2001005648A JP 2001005648 A JP2001005648 A JP 2001005648A JP 4166956 B2 JP4166956 B2 JP 4166956B2
- Authority
- JP
- Japan
- Prior art keywords
- connection
- bus
- connection establishment
- processing
- state
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
- Information Transfer Systems (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、複数の情報伝送機器がバス上のノードに接続され、各ノード間でコネクションを確立してデータを伝送するデータ伝送システムに関し、特に、ＩＥＥＥ１３９４（IEEE（Institute of Electrical and Electronic Engineers）Std.1394-1995 IEEE Standard for a High Performance serial Bus）規格に準拠したシリアルバスにおいて、各ノードでコネクション確立処理を実行するデータ伝送システム、コネクション確立方法及び情報伝送装置の技術分野に属するものである。
【０００２】
【従来の技術】
近年、ＡＶ機器やコンピュータ周辺機器が互いにディジタルデータを伝送するインターフェース規格として上記ＩＥＥＥ１３９４規格が注目されている。このＩＥＥＥ１３９４規格は、高速な転送速度でデータを転送でき、トポロジー接続の自由度が高く、アイソクロナス転送によりリアルタイムデータの転送に好適であるなど様々なメリットがあり、従来のインターフェース規格と比べても有用性が高い。
【０００３】
ＩＥＥＥ１３９４規格によりデータ伝送を行う場合、各ノードに設定されたプラグを接続するためにコネクションを確立する必要がある。そして、アイソクロナス転送を行うためには、アイソクロナスリソースを管理するＩＲＭ（Isochronous Resource Manager）にアクセスし、チャンネルと帯域などの確保を実行し、所定のプラグのレジスタを更新するなど必要な処理プロセスを順次実行する。また、電源を入れたままでの機器の活線挿抜をサポートすべく、バスのトポロジー接続が変更されたときにバスリセットを発生させ、確立されたコネクションをいったん解除した後、１秒間以内に各ノードの元のコネクションを回復させるコネクション回復処理が実行される。
【０００４】
【発明が解決しようとする課題】
しかしながら、ＩＥＥＥ１３９４バス上の各ノードに接続される機器には、複数の入力プラグと出力プラグを設定可能であるため、コネクションの種別もBroadcast-inコネクション、Broadcast-outコネクション、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-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする。
【００３１】
請求項１７に記載の情報伝送装置は、請求項１６に記載の情報伝送装置において、前記複数のコネクション確立処理は、バスリセット発生に伴い確立されたコネクションが解除されたとき、所定時間が経過するまでに各ノードにおいて前記コネクションを回復するためのコネクション回復処理に対応し、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする。
【００３２】
請求項６と請求項１７にそれぞれ記載の発明によれば、ＩＥＥＥ１３９４規格を用いて、上記３つのコネクション確立処理を、バスリセット時のコネクション回復処理に対し適用するので、情報伝送機器の活線挿抜が行われる度にバスリセットを発生させるＩＥＥＥ１３９４バスシステムの信頼性及び処理効率を高めることができる。
【００３３】
【発明の実施の形態】
以下、本発明の好適な実施形態を図面に基づいて説明する。本実施形態においては、データ転送のインターフェース規格としてＩＥＥＥ１３９４を採用したデータ伝送システムに対して本発明を適用した場合について説明する。また、以下では、ＩＥＥＥ１３９４データ伝送システムにおいて、コネクション確立処理の一例として、バスリセット時のコネクション回復処理に対して本発明を適用する場合を説明する。
【００３４】
図１は、ＩＥＥＥ１３９４のプロトコルの構成を示すブロック図である。ＩＥＥＥ１３９４のプロトコルは、図１に示すように、物理層１０、リンク層１１、トランザクション層１２の３つの層と、バス管理層１３とから構成される。一般に、物理層１０とリンク層１１はハードウェアで実現され、トランザクション層１２と、バス管理層１３はファームウェアで実現される。
【００３５】
物理層１０は、バスとの物理的・電気的インターフェースを行う層であり、信号のエンコードとデコードを行うエンコード／デコード部１０ａ、各ノード間のバス使用権の調停（アービトレーション）を行うバスアービトレーション部１０ｂ、バス上の媒体とのインターフェース動作を行うインターフェース部１０ｃを含んでいる。
【００３６】
リンク層１１は、パケットの送受信動作等を行う層であり、送受信の際のサイクル制御を行うサイクル制御部１１ａ、パケットの送信動作を行うパケット送信部１１ｂ、パケットの受信動作を行うパケット受信部１１ｃを含んでいる。また、同期データを送受信するためのアイソクロナス転送が行われる場合、リンク層１１とバスの間にアイソクロナスチャンネルが設定される。
【００３７】
トランザクション層１２は、上位のアプリケーションとリンク層１１の間の通信処理を制御する層であり、リンク層１１の動作を制御して指定されたノードとアドレスに対する読み出し又は書き込みを実行する。トランザクション層１２では、特定アドレスのデータを読み取るリードトランザクション、特定アドレスにデータを書き込むライトトランザクション、特定アドレスを参照して所定の条件に合致したとき更新するロックトランザクションをそれぞれ発行する。
【００３８】
バス管理層１３は、物理層１０、リンク層１１、トランザクション層１２の３層を制御し、ノード制御とバス資源管理のための基本的な機能を提供する。バス管理層１３には、バスの管理を行うバスマネージャ１３ａと、アイソクロナスリソースの管理を行うアイソクロナス資源管理部１３ｂと、ＣＳＲ（Command and Status Register）アーキテクチャに基づいてノードを制御するノード制御部１３ｃを含んでいる。
【００３９】
上記のアイソクロナス資源管理部１３ｂは、アイソクロナス転送の能力を有するノードに対し少なくとも１つ設定される上記ＩＲＭに対応する。このＩＲＭは、ＣＳＲアーキテクチャに対応するＣＳＲ空間において、アイソクロナスリソースの管理に用いるレジスタを保有している。そして、ＣＳＲ空間には、アイソクロナス転送に必要となるレジスタとして、ＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタとＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタが設けられている。
【００４０】
上記のＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタは、アイソクロナスチャンネルの使用状況を表す６４ビットのレジスタであり、各チャンネルが１であれば使用中であり、０であれば未使用であることを表す６４チャンネル分のデータを保持している。また、上記のＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタは、アイソクロナス転送に使用可能な帯域を示す数値を格納するレジスタであり、１６００Ｍｂｐｓの転送速度で３２ビットのデータ転送に要する時間を１ユニット（約２０ｎｓｅｃ）とし、これを単位に表わされる。
【００４１】
ＩＥＥＥ１３９４のバス上の各ノードがアイソクロナス転送を行う際は、適正なチャンネル及び帯域を確保する必要がある。そのため、ロックトランザクションを発行することにより、ＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタを更新し、更にＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタを更新し、これによりチャンネル及び帯域を確保することができる。このとき、チャンネルと帯域が正常に確保される場合はロックトランザクションによるレジスタ更新に成功するが、チャンネル又は帯域が確保できない場合はロックトランザクションによるレジスタ更新に失敗することになる。
【００４２】
次に図２は、ＩＥＥＥ１３９４のバス上に接続された複数の情報伝送機器が相互にデータを伝送可能なデータ伝送システムの概念を示す図である。ＩＥＥＥ１３９４では、各情報伝送機器どうしの従来の物理的な信号接続に代わり、論理的な信号接続を行うためのプラグの概念が導入される。よって、ＩＥＥＥ１３９４のバス上でデータを送受信する際は、各情報伝送機器の仮想的なプラグを介して制御される。
【００４３】
図２においては、３台の情報伝送機器としてのＡＶ機器２１、２２、２３がＩＥＥＥ１３９４上に接続されている場合を例に示している。各ＡＶ機器２１〜２３は、データ出力に用いる出力プラグとデータ入力に用いる入力プラグとを仮想的に備えており、特定のＡＶ機器の出力プラグを経由してアイソクロナスデータがバス上に送出され、他のＡＶ機器の入力プラグを経由してアイソクロナスデータを受け取ることによりデータ転送を行うことができる。
【００４４】
図２に示すように、各ＡＶ機器２１、２２は、出力プラグの属性を制御する出力プラグ制御レジスタ（ｏＰＣＲ：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）規格に準拠したシリアルバスにおいて、各ノードでコネクション確立処理を実行するデータ伝送システム、コネクション確立方法及び情報伝送装置の技術分野に属するものである。
【０００２】
【従来の技術】
近年、ＡＶ機器やコンピュータ周辺機器が互いにディジタルデータを伝送するインターフェース規格として上記ＩＥＥＥ１３９４規格が注目されている。このＩＥＥＥ１３９４規格は、高速な転送速度でデータを転送でき、トポロジー接続の自由度が高く、アイソクロナス転送によりリアルタイムデータの転送に好適であるなど様々なメリットがあり、従来のインターフェース規格と比べても有用性が高い。
【０００３】
ＩＥＥＥ１３９４規格によりデータ伝送を行う場合、各ノードに設定されたプラグを接続するためにコネクションを確立する必要がある。そして、アイソクロナス転送を行うためには、アイソクロナスリソースを管理するＩＲＭ（Isochronous Resource Manager）にアクセスし、チャンネルと帯域などの確保を実行し、所定のプラグのレジスタを更新するなど必要な処理プロセスを順次実行する。また、電源を入れたままでの機器の活線挿抜をサポートすべく、バスのトポロジー接続が変更されたときにバスリセットを発生させ、確立されたコネクションをいったん解除した後、１秒間以内に各ノードの元のコネクションを回復させるコネクション回復処理が実行される。
【０００４】
【発明が解決しようとする課題】
しかしながら、ＩＥＥＥ１３９４バス上の各ノードに接続される機器には、複数の入力プラグと出力プラグを設定可能であるため、コネクションの種別もBroadcast-inコネクション、Broadcast-outコネクション、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-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする。
【００３１】
請求項１７に記載の情報伝送装置は、請求項１６に記載の情報伝送装置において、前記複数のコネクション確立処理は、バスリセット発生に伴い確立されたコネクションが解除されたとき、所定時間が経過するまでに各ノードにおいて前記コネクションを回復するためのコネクション回復処理に対応し、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする。
【００３２】
請求項６と請求項１７にそれぞれ記載の発明によれば、ＩＥＥＥ１３９４規格を用いて、上記３つのコネクション確立処理を、バスリセット時のコネクション回復処理に対し適用するので、情報伝送機器の活線挿抜が行われる度にバスリセットを発生させるＩＥＥＥ１３９４バスシステムの信頼性及び処理効率を高めることができる。
【００３３】
【発明の実施の形態】
以下、本発明の好適な実施形態を図面に基づいて説明する。本実施形態においては、データ転送のインターフェース規格としてＩＥＥＥ１３９４を採用したデータ伝送システムに対して本発明を適用した場合について説明する。また、以下では、ＩＥＥＥ１３９４データ伝送システムにおいて、コネクション確立処理の一例として、バスリセット時のコネクション回復処理に対して本発明を適用する場合を説明する。
【００３４】
図１は、ＩＥＥＥ１３９４のプロトコルの構成を示すブロック図である。ＩＥＥＥ１３９４のプロトコルは、図１に示すように、物理層１０、リンク層１１、トランザクション層１２の３つの層と、バス管理層１３とから構成される。一般に、物理層１０とリンク層１１はハードウェアで実現され、トランザクション層１２と、バス管理層１３はファームウェアで実現される。
【００３５】
物理層１０は、バスとの物理的・電気的インターフェースを行う層であり、信号のエンコードとデコードを行うエンコード／デコード部１０ａ、各ノード間のバス使用権の調停（アービトレーション）を行うバスアービトレーション部１０ｂ、バス上の媒体とのインターフェース動作を行うインターフェース部１０ｃを含んでいる。
【００３６】
リンク層１１は、パケットの送受信動作等を行う層であり、送受信の際のサイクル制御を行うサイクル制御部１１ａ、パケットの送信動作を行うパケット送信部１１ｂ、パケットの受信動作を行うパケット受信部１１ｃを含んでいる。また、同期データを送受信するためのアイソクロナス転送が行われる場合、リンク層１１とバスの間にアイソクロナスチャンネルが設定される。
【００３７】
トランザクション層１２は、上位のアプリケーションとリンク層１１の間の通信処理を制御する層であり、リンク層１１の動作を制御して指定されたノードとアドレスに対する読み出し又は書き込みを実行する。トランザクション層１２では、特定アドレスのデータを読み取るリードトランザクション、特定アドレスにデータを書き込むライトトランザクション、特定アドレスを参照して所定の条件に合致したとき更新するロックトランザクションをそれぞれ発行する。
【００３８】
バス管理層１３は、物理層１０、リンク層１１、トランザクション層１２の３層を制御し、ノード制御とバス資源管理のための基本的な機能を提供する。バス管理層１３には、バスの管理を行うバスマネージャ１３ａと、アイソクロナスリソースの管理を行うアイソクロナス資源管理部１３ｂと、ＣＳＲ（Command and Status Register）アーキテクチャに基づいてノードを制御するノード制御部１３ｃを含んでいる。
【００３９】
上記のアイソクロナス資源管理部１３ｂは、アイソクロナス転送の能力を有するノードに対し少なくとも１つ設定される上記ＩＲＭに対応する。このＩＲＭは、ＣＳＲアーキテクチャに対応するＣＳＲ空間において、アイソクロナスリソースの管理に用いるレジスタを保有している。そして、ＣＳＲ空間には、アイソクロナス転送に必要となるレジスタとして、ＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタとＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタが設けられている。
【００４０】
上記のＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタは、アイソクロナスチャンネルの使用状況を表す６４ビットのレジスタであり、各チャンネルが１であれば使用中であり、０であれば未使用であることを表す６４チャンネル分のデータを保持している。また、上記のＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタは、アイソクロナス転送に使用可能な帯域を示す数値を格納するレジスタであり、１６００Ｍｂｐｓの転送速度で３２ビットのデータ転送に要する時間を１ユニット（約２０ｎｓｅｃ）とし、これを単位に表わされる。
【００４１】
ＩＥＥＥ１３９４のバス上の各ノードがアイソクロナス転送を行う際は、適正なチャンネル及び帯域を確保する必要がある。そのため、ロックトランザクションを発行することにより、ＣＨＡＮＮＥＬＳ＿ＡＶＡＩＬＡＢＬＥレジスタを更新し、更にＢＡＮＤＷＩＤＴＨ＿ＡＶＡＩＬＡＢＬＥレジスタを更新し、これによりチャンネル及び帯域を確保することができる。このとき、チャンネルと帯域が正常に確保される場合はロックトランザクションによるレジスタ更新に成功するが、チャンネル又は帯域が確保できない場合はロックトランザクションによるレジスタ更新に失敗することになる。
【００４２】
次に図２は、ＩＥＥＥ１３９４のバス上に接続された複数の情報伝送機器が相互にデータを伝送可能なデータ伝送システムの概念を示す図である。ＩＥＥＥ１３９４では、各情報伝送機器どうしの従来の物理的な信号接続に代わり、論理的な信号接続を行うためのプラグの概念が導入される。よって、ＩＥＥＥ１３９４のバス上でデータを送受信する際は、各情報伝送機器の仮想的なプラグを介して制御される。
【００４３】
図２においては、３台の情報伝送機器としてのＡＶ機器２１、２２、２３がＩＥＥＥ１３９４上に接続されている場合を例に示している。各ＡＶ機器２１〜２３は、データ出力に用いる出力プラグとデータ入力に用いる入力プラグとを仮想的に備えており、特定のＡＶ機器の出力プラグを経由してアイソクロナスデータがバス上に送出され、他のＡＶ機器の入力プラグを経由してアイソクロナスデータを受け取ることによりデータ転送を行うことができる。
【００４４】
図２に示すように、各ＡＶ機器２１、２２は、出力プラグの属性を制御する出力プラグ制御レジスタ（ｏＰＣＲ：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 (17)
- 複数の情報伝送機器がバス上のノードに接続され、各ノード間でコネクションを確立してデータを伝送するデータ伝送システムにおいて、
それぞれのノードにおけるコネクション確立処理を実行する際にコネクションの確立状態を示すコネクション状態情報を更新可能に保持し、
前記コネクション状態情報は、前記コネクション確立処理の結果に応じて更新され、且つ、コネクションを確立することができた有効状態と、コネクションを確立することができない無効状態と、コネクションを確立することができるか否かが不定である不定状態と、を少なくとも含み、
前記バス上で確立すべきコネクションのうち、少なくとも前記コネクション状態情報が不定状態に設定されたコネクションに対応するバス資源を解放することを特徴とするデータ伝送システム。 - 前記コネクションの種別に対応する複数のコネクション確立処理が設けられ、それぞれに対し前記コネクション状態情報が保持されることを特徴とする請求項１に記載のデータ伝送システム。
- 前記バス上で確立すべきコネクションのうち、前記不定状態に設定された前記コネクション状態情報が所定数以上存在する場合、バスリセットを発生させることを特徴とする請求項１又は請求項２に記載のデータ伝送システム。
- 前記コネクション確立処理には、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれ、それぞれの前記処理プロセスにおいてタイムアウト又はデータエラーが生じた場合、処理対象の前記コネクション状態情報を前記不定状態に設定することを特徴とする請求項１に記載のデータ伝送システム。
- 前記バスはＩＥＥＥ１３９４規格に準拠したシリアルバスであり、前記複数のコネクション確立処理には、Broadcast-outコネクションの確立処理、Broadcast-inコネクションの確立処理、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-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする請求項１６に記載の情報伝送装置。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001005648A JP4166956B2 (ja) | 2001-01-12 | 2001-01-12 | データ伝送システム、コネクション確立方法及び情報伝送装置 |
| US10/041,736 US7139853B2 (en) | 2001-01-12 | 2002-01-10 | Data transmission/reception system, connection establishing method and information transmission/reception apparatus |
| EP02250192A EP1223712A3 (en) | 2001-01-12 | 2002-01-11 | Data transmission/reception bus system, connection establishing method and information transmission/reception apparatus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001005648A JP4166956B2 (ja) | 2001-01-12 | 2001-01-12 | データ伝送システム、コネクション確立方法及び情報伝送装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002217907A JP2002217907A (ja) | 2002-08-02 |
| JP4166956B2 true JP4166956B2 (ja) | 2008-10-15 |
Family
ID=18873674
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001005648A Expired - Fee Related JP4166956B2 (ja) | 2001-01-12 | 2001-01-12 | データ伝送システム、コネクション確立方法及び情報伝送装置 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7139853B2 (ja) |
| EP (1) | EP1223712A3 (ja) |
| JP (1) | JP4166956B2 (ja) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004343526A (ja) | 2003-05-16 | 2004-12-02 | Pioneer Electronic Corp | 通信装置、通信方法並びに通信用プログラム及び情報記録媒体 |
| JP4502653B2 (ja) * | 2004-02-12 | 2010-07-14 | Ｎｅｃエンジニアリング株式会社 | パケット送受信装置及びそれに用いるパケット識別方法 |
| KR100567309B1 (ko) | 2004-06-15 | 2006-04-04 | 삼성전자주식회사 | 데이터 헤더 오류 체크를 통한 버스 사용 효율 향상 방법 |
| KR100581221B1 (ko) * | 2004-06-30 | 2006-05-22 | 삼성전자주식회사 | 테이프 배선 기판 제조 방법 |
| US20060161270A1 (en) * | 2004-10-14 | 2006-07-20 | Lagotek Corporation | Distributed wireless home and commercial electrical automation systems |
| US9635135B1 (en) * | 2008-04-21 | 2017-04-25 | United Services Automobile Association (Usaa) | Systems and methods for handling replies to transaction requests |
| US20120044952A1 (en) * | 2009-04-28 | 2012-02-23 | Pioneer Corporation | Control device, network system, transmitting device, receiving device, control method and control program |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE69631182T2 (de) | 1995-04-28 | 2004-08-19 | Matsushita Electric Industrial Co., Ltd., Kadoma | Datenübertragungsverfahren |
| JP3793238B2 (ja) * | 1997-01-10 | 2006-07-05 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | 通信バスシステム |
| US6418493B1 (en) * | 1997-12-29 | 2002-07-09 | Intel Corporation | Method and apparatus for robust addressing on a dynamically configurable bus |
| JPH11205363A (ja) | 1998-01-20 | 1999-07-30 | Nec Corp | Ｉｅｅｅ１３９４機器制御装置 |
| US6272546B1 (en) * | 1998-03-12 | 2001-08-07 | Sony Corporation | Method of and apparatus for managing resource allocation and bandwidth overflow in a cooperative, distributed computing environment |
| JP3145083B2 (ja) | 1998-08-04 | 2001-03-12 | 松下電器産業株式会社 | 伝送システム，帯域管理装置，および帯域管理方法 |
| JP3325839B2 (ja) | 1998-10-15 | 2002-09-17 | パイオニア株式会社 | 情報送信装置及び方法、情報受信装置及び方法並びに情報送受信装置及び方法 |
| JP3543647B2 (ja) * | 1998-10-27 | 2004-07-14 | セイコーエプソン株式会社 | データ転送制御装置及び電子機器 |
| JP2000341302A (ja) * | 1999-05-27 | 2000-12-08 | Sony Corp | 電子機器 |
| JP2001045030A (ja) * | 1999-07-29 | 2001-02-16 | Nec Corp | 接続制御装置 |
| KR100662484B1 (ko) * | 1999-08-23 | 2007-01-02 | 엘지전자 주식회사 | 디지털 인터페이스에서의 버스 제어방법 |
| US6721859B1 (en) * | 1999-10-21 | 2004-04-13 | Sony Corporation | Multi-protocol media storage device implementing protocols optimized for storing and retrieving both asynchronous and isochronous data |
-
2001
- 2001-01-12 JP JP2001005648A patent/JP4166956B2/ja not_active Expired - Fee Related
-
2002
- 2002-01-10 US US10/041,736 patent/US7139853B2/en not_active Expired - Fee Related
- 2002-01-11 EP EP02250192A patent/EP1223712A3/en not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| US20020095505A1 (en) | 2002-07-18 |
| EP1223712A2 (en) | 2002-07-17 |
| EP1223712A3 (en) | 2005-01-26 |
| US7139853B2 (en) | 2006-11-21 |
| JP2002217907A (ja) | 2002-08-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3277874B2 (ja) | Ｉｅｅｅ１３９４ブリッジ | |
| JP4143405B2 (ja) | 無線リンクを介してｉｅｅｅ１３９４規格遠隔装置をｉｅｅｅ１３９４規格装置のクラスタへ接続する方法 | |
| US6810452B1 (en) | Method and system for quarantine during bus topology configuration | |
| US6374316B1 (en) | Method and system for circumscribing a topology to form ring structures | |
| EP1327328B1 (en) | Method for linking several communication busses using wireless links | |
| US6647446B1 (en) | Method and system for using a new bus identifier resulting from a bus topology change | |
| JP4166956B2 (ja) | データ伝送システム、コネクション確立方法及び情報伝送装置 | |
| JP2003174486A (ja) | 情報通信装置、情報通信方法および情報通信処理プログラム | |
| JP4059423B2 (ja) | データ伝送システム、コネクション回復方法及び情報伝送装置 | |
| US6751697B1 (en) | Method and system for a multi-phase net refresh on a bus bridge interconnect | |
| US6584539B1 (en) | Method and system for message broadcast flow control on a bus bridge interconnect | |
| US6732262B1 (en) | Method and system for controlling reset of IEEE 1394 network | |
| EP1499071B1 (en) | Apparatus, method, program and information recording medium for data rate setting | |
| WO2000057263A1 (en) | A method and system for a multi-phase net refresh on a bus bridge interconnect | |
| JP2003289314A (ja) | ローカルバスブリッジ | |
| KR100677222B1 (ko) | Ｉｅｅｅ 1394 기반의 양방향 비동기 연결 방법 | |
| JP4611974B2 (ja) | Ｉｅｅｅ１３９４バスの再初期化メッセージを転送する方法、及びかかる方法を実行する装置 | |
| JP2003051824A (ja) | 通信方法、通信システム、プログラム及び記憶媒体 | |
| JP5618805B2 (ja) | 通信装置、ネットワークシステム及び通信方法 | |
| JP4129603B2 (ja) | 情報処理装置および方法、並びに提供媒体 | |
| EP1246400A1 (en) | Method for linking several communication busses using wireless links | |
| WO2001038951A2 (en) | A method and system for circumscribing a topology to form ring structures | |
| WO2000057289A1 (en) | A method and system for message broadcast flow control on a bus bridge interconnect | |
| EP1246402A1 (en) | Method for linking several communication busses using wireless links | |
| JP2004236090A (ja) | Ｉｅｅｅ１３９４シリアルバスへの接続機器 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20041111 |
|
| 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: 20080108 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080226 |
|
| 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: 20080729 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080731 |
|
| 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: 20110808 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110808 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120808 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130808 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |