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
【発明の属する技術分野】
本発明は、複数の情報伝送機器がバス上のノードに接続され、各ノード間でコネクションを確立してデータを伝送するデータ伝送システムに関し、特に、IEEE1394(IEEE(Institute of Electrical and Electronic Engineers)Std.1394-1995 IEEE Standard for a High Performance serial Bus)規格に準拠したシリアルバスにおいて、各ノードでコネクション確立処理を実行するデータ伝送システム、コネクション確立方法及び情報伝送装置の技術分野に属するものである。
【0002】
【従来の技術】
近年、AV機器やコンピュータ周辺機器が互いにディジタルデータを伝送するインターフェース規格として上記IEEE1394規格が注目されている。このIEEE1394規格は、高速な転送速度でデータを転送でき、トポロジー接続の自由度が高く、アイソクロナス転送によりリアルタイムデータの転送に好適であるなど様々なメリットがあり、従来のインターフェース規格と比べても有用性が高い。
【0003】
IEEE1394規格によりデータ伝送を行う場合、各ノードに設定されたプラグを接続するためにコネクションを確立する必要がある。そして、アイソクロナス転送を行うためには、アイソクロナスリソースを管理するIRM(Isochronous Resource Manager)にアクセスし、チャンネルと帯域などの確保を実行し、所定のプラグのレジスタを更新するなど必要な処理プロセスを順次実行する。また、電源を入れたままでの機器の活線挿抜をサポートすべく、バスのトポロジー接続が変更されたときにバスリセットを発生させ、確立されたコネクションをいったん解除した後、1秒間以内に各ノードの元のコネクションを回復させるコネクション回復処理が実行される。
【0004】
【発明が解決しようとする課題】
しかしながら、IEEE1394バス上の各ノードに接続される機器には、複数の入力プラグと出力プラグを設定可能であるため、コネクションの種別もBroadcast-inコネクション、Broadcast-outコネクション、Point-to-pointコネクションなど多様である。よって、コネクション確立処理に含まれる一連の処理プロセスは複雑になる。そして、チャンネルや帯域を確保する際にはトランザクションを発行することになるが、その際にタイムアウトになったりデータエラーが発生することがある。この場合、トランザクションに対するレスポンスが得られないと、コネクションに用いるべきアイソクロナスリソースの管理状態は不定となり、一部のチャンネルや帯域が未使用の状態のまま放置される可能性がある。その結果、本来のアイソクロナスリソースのうち確保可能な部分が実質的に減少し、コネクションを確立する過程でIEEE1394のバス資源が無駄に使用されるという問題がある。なお、この問題は、上述のバスリセット時に行われるコネクション回復処理の場合も同様に当てはまる。
【0005】
そこで、本発明はこのような問題に鑑みなされたものであり、データ伝送システムにおけるコネクション確立処理に際し、バス資源が管理できる状態にあるか否かを判断し、コネクションが確立されたときに管理不能のバス資源が残った状態になることを回避し、バス資源を適正に割り当てて信頼性の高いデータ伝送システムを構築することを目的とする。
【0006】
【課題を解決するための手段】
上記課題を解決するために、請求項1に記載のデータ伝送システムは、複数の情報伝送機器がバス上のノードに接続され、各ノード間でコネクションを確立してデータを伝送するデータ伝送システムにおいて、それぞれのノードにおけるコネクション確立処理を実行する際にコネクションの確立状態を示すコネクション状態情報を更新可能に保持し、前記コネクション状態情報は、前記コネクション確立処理の結果に応じて更新され、且つ、コネクションを確立することができた有効状態と、コネクションを確立することができない無効状態と、コネクションを確立することができるか否かが不定である不定状態と、を少なくとも含み、前記バス上で確立すべきコネクションのうち、少なくとも前記コネクション状態情報が不定状態に設定されたコネクションに対応するバス資源を解放することを特徴とする。
【0007】
また、請求項7に記載のコネクション確立方法は、バス上のノードに接続された複数の情報伝送機器がデータを伝送するデータ伝送システムの前記各ノード間でコネクションを確立するコネクション確立方法において、それぞれのノードにおけるコネクション確立処理を実行する際にコネクションの確立状態を示すコネクション状態情報を更新可能に保持し、前記コネクション状態情報は、前記コネクション確立処理の結果に応じて更新され、且つ、コネクションを確立することができた有効状態と、コネクションを確立することができない無効状態と、コネクションを確立することができるか否かが不定である不定状態と、を少なくとも含み、前記バス上で確立すべきコネクションのうち、少なくとも前記コネクション状態情報が不定状態に設定されたコネクションに対応するバス資源を解放することを特徴とする。
【0008】
また、請求項12に記載の情報伝送装置は、バス上のノードに接続可能で、他ノードとの間でコネクションを確立してデータを伝送する情報伝送装置において、コネクション確立処理を実行する際にコネクションの確立状態を示すコネクション状態情報を更新可能に保持し、前記コネクション状態情報は、前記コネクション確立処理の結果に応じて更新され、且つ、コネクションを確立することができた有効状態と、コネクションを確立することができない無効状態と、コネクションを確立することができるか否かが不定である不定状態と、を少なくとも含み、前記コネクション状態情報が不定状態に設定されたコネクションに対応するバス資源を解放させるように制御することを特徴とする。
【0009】
請求項1、7、12にそれぞれ記載の発明によれば、データ伝送システムにおいて情報伝送機器の間でデータ伝送を行うべく、それぞれのノードでコネクション確立処理が開始されると、コネクション状態情報にはコネクションの確立状態が逐次更新されつつ保持される。このコネクション状態情報としては、コネクションを確立することができた有効状態と、コネクションを確立することができない無効状態と、コネクションを確立することができるか否かが不定である不定状態と、が少なくとも含まれる。よって、コネクション確立処理を正常に進行するためのバス資源が管理できる状態にあるか否かを容易に判断できる。そして、コネクション状態情報が不定状態に設定されているときは、その旨をアプリケーション等の上位層へ通知することにより、例えばバスリセットを発生させるなどバス上のコネクションがいったん解除されてバス資源が解放され、コネクション確立処理が新たに実行し直されるなどの処置が行われる。よって、管理不能のバス資源が残った状態を維持することなく、バス資源が無駄に使用されることを防止し、バス資源を適正に割り当ててコネクションを確立することができる。
【0010】
請求項2に記載のデータ伝送システムは、請求項1に記載のデータ伝送システムにおいて、前記コネクションの種別に対応する複数のコネクション確立処理が設けられ、それぞれに対し前記コネクション状態情報が保持されることを特徴とする。
【0011】
また、請求項8に記載のコネクション確立方法は、請求項7に記載のコネクション確立方法において、前記コネクションの種別に対応する複数のコネクション確立処理が設けられ、それぞれに対し前記コネクション状態情報が保持されることを特徴とする。
【0012】
また、請求項13に記載の情報伝送装置は、請求項12に記載の情報伝送装置において、前記コネクションの種別に対応する複数のコネクション確立処理が設けられ、それぞれに対し前記コネクション状態情報が保持されることを特徴とする。
【0013】
請求項2、8、13にそれぞれ記載の発明によれば、各ノードでは異なるコネクションの種別を用いることができ、それぞれ異なるコネクション状態情報を用いたコネクション確立処理が実行されるので、特定のコネクション確立処理が管理不能であっても、他のコネクション確立処理を円滑に進行することができる。
【0014】
請求項3に記載のデータ伝送システムは、請求項1又は請求項2に記載のデータ伝送システムにおいて、前記バス上で確立すべきコネクションのうち、前記不定状態に設定された前記コネクション状態情報が所定数以上存在する場合、バスリセットを発生させることを特徴とする。
【0015】
また、請求項9に記載のコネクション確立方法は、請求項7又は請求項8に記載のコネクション確立方法において、前記バス上で確立すべきコネクションのうち、前記不定状態に設定された前記コネクション状態情報が所定数以上存在する場合、バスリセットを発生させることを特徴とする。
【0016】
また、請求項14に記載の情報伝送装置は、請求項12又は請求項13に記載の情報伝送装置において、前記バス上で確立すべきコネクションのうち、前記不定状態に設定された前記コネクション状態情報が所定数以上存在する場合、バスリセットを発生させることを特徴とする。
【0017】
請求項3、9、14にそれぞれ記載の発明によれば、コネクション確立処理に際し、バス全体のコネクションに対応するコネクション状態情報のうち、不定状態であるものが所定数以上あるとき、バスリセットを発生させるようにしたので、不定状態のコネクションの増加によりバス資源が無駄に用いられる事態を防止することができる。
【0022】
請求項4に記載のデータ伝送システムは、請求項1に記載のデータ伝送システムにおいて、前記コネクション確立処理には、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれ、それぞれの前記処理プロセスにおいてタイムアウト又はデータエラーが生じた場合、処理対象の前記コネクション状態情報を前記不定状態に設定することを特徴とする。
【0023】
また、請求項10に記載のコネクション確立方法は、請求項7に記載のコネクション確立方法において、前記コネクション確立処理には、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれ、それぞれの前記処理プロセスにおいてタイムアウト又はデータエラーが生じた場合、処理対象の前記コネクション状態情報を前記不定状態に設定することを特徴とする。
【0024】
また、請求項15に記載の情報伝送装置は、請求項12に記載の情報伝送装置において、前記コネクション確立処理には、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれ、それぞれの前記処理プロセスにおいてタイムアウト又はデータエラーが生じた場合、処理対象の前記コネクション状態情報を前記不定状態に設定することを特徴とする。
【0025】
請求項4、10、15にそれぞれ記載の発明によれば、コネクション回復処理におけるチャンネル、帯域を確保する処理プロセスにおいて、タイムアウト、データエラーが生じた場合にコネクション状態情報を不定状態に設定するようにしたので、例えば他のノードから正常なレスポンスが得られない場合、特定のチャンネルや帯域の確保が不定である状態を回避することができる。
【0026】
請求項5に記載のデータ伝送システムは、請求項2に記載のデータ伝送システムにおいて、前記バスはIEEE1394規格に準拠したシリアルバスであり、前記複数のコネクション確立処理には、Broadcast-outコネクションの確立処理、Broadcast-inコネクションの確立処理、Point-to-pointコネクションの確立処理が含まれることを特徴とする。
【0027】
また、請求項11に記載のコネクション確立方法は、請求項8に記載のコネクション確立方法において、前記バスはIEEE1394規格に準拠したシリアルバスであり、前記複数のコネクション確立処理には、Broadcast-outコネクションの確立処理、Broadcast-inコネクションの確立処理、Point-to-pointコネクションの確立処理が含まれることを特徴とする。
【0028】
また、請求項16に記載の情報伝送装置は、請求項13に記載の情報伝送装置において、前記バスはIEEE1394規格に準拠したシリアルバスであり、前記複数のコネクション確立処理には、Broadcast-outコネクションの確立処理、Broadcast-inコネクションの確立処理、Point-to-pointコネクションの確立処理が含まれることを特徴とする。
【0029】
請求項5、11、16にそれぞれ記載の発明によれば、汎用的でディジタルデータの伝送に好適なIEEE1394規格を用いて上記3つのようにコネクション確立処理を実行するので、IEEE1394バスシステムの信頼性及び処理効率を高めることができる。
【0030】
請求項6に記載のデータ伝送システムは、請求項5に記載のデータ伝送システムにおいて、前記複数のコネクション確立処理は、バスリセット発生に伴い確立されたコネクションが解除されたとき、所定時間が経過するまでに各ノードにおいて前記コネクションを回復するためのコネクション回復処理に対応し、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする。
【0031】
請求項17に記載の情報伝送装置は、請求項16に記載の情報伝送装置において、前記複数のコネクション確立処理は、バスリセット発生に伴い確立されたコネクションが解除されたとき、所定時間が経過するまでに各ノードにおいて前記コネクションを回復するためのコネクション回復処理に対応し、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする。
【0032】
請求項6と請求項17にそれぞれ記載の発明によれば、IEEE1394規格を用いて、上記3つのコネクション確立処理を、バスリセット時のコネクション回復処理に対し適用するので、情報伝送機器の活線挿抜が行われる度にバスリセットを発生させるIEEE1394バスシステムの信頼性及び処理効率を高めることができる。
【0033】
【発明の実施の形態】
以下、本発明の好適な実施形態を図面に基づいて説明する。本実施形態においては、データ転送のインターフェース規格としてIEEE1394を採用したデータ伝送システムに対して本発明を適用した場合について説明する。また、以下では、IEEE1394データ伝送システムにおいて、コネクション確立処理の一例として、バスリセット時のコネクション回復処理に対して本発明を適用する場合を説明する。
【0034】
図1は、IEEE1394のプロトコルの構成を示すブロック図である。IEEE1394のプロトコルは、図1に示すように、物理層10、リンク層11、トランザクション層12の3つの層と、バス管理層13とから構成される。一般に、物理層10とリンク層11はハードウェアで実現され、トランザクション層12と、バス管理層13はファームウェアで実現される。
【0035】
物理層10は、バスとの物理的・電気的インターフェースを行う層であり、信号のエンコードとデコードを行うエンコード/デコード部10a、各ノード間のバス使用権の調停(アービトレーション)を行うバスアービトレーション部10b、バス上の媒体とのインターフェース動作を行うインターフェース部10cを含んでいる。
【0036】
リンク層11は、パケットの送受信動作等を行う層であり、送受信の際のサイクル制御を行うサイクル制御部11a、パケットの送信動作を行うパケット送信部11b、パケットの受信動作を行うパケット受信部11cを含んでいる。また、同期データを送受信するためのアイソクロナス転送が行われる場合、リンク層11とバスの間にアイソクロナスチャンネルが設定される。
【0037】
トランザクション層12は、上位のアプリケーションとリンク層11の間の通信処理を制御する層であり、リンク層11の動作を制御して指定されたノードとアドレスに対する読み出し又は書き込みを実行する。トランザクション層12では、特定アドレスのデータを読み取るリードトランザクション、特定アドレスにデータを書き込むライトトランザクション、特定アドレスを参照して所定の条件に合致したとき更新するロックトランザクションをそれぞれ発行する。
【0038】
バス管理層13は、物理層10、リンク層11、トランザクション層12の3層を制御し、ノード制御とバス資源管理のための基本的な機能を提供する。バス管理層13には、バスの管理を行うバスマネージャ13aと、アイソクロナスリソースの管理を行うアイソクロナス資源管理部13bと、CSR(Command and Status Register)アーキテクチャに基づいてノードを制御するノード制御部13cを含んでいる。
【0039】
上記のアイソクロナス資源管理部13bは、アイソクロナス転送の能力を有するノードに対し少なくとも1つ設定される上記IRMに対応する。このIRMは、CSRアーキテクチャに対応するCSR空間において、アイソクロナスリソースの管理に用いるレジスタを保有している。そして、CSR空間には、アイソクロナス転送に必要となるレジスタとして、CHANNELS_AVAILABLEレジスタとBANDWIDTH_AVAILABLEレジスタが設けられている。
【0040】
上記のCHANNELS_AVAILABLEレジスタは、アイソクロナスチャンネルの使用状況を表す64ビットのレジスタであり、各チャンネルが1であれば使用中であり、0であれば未使用であることを表す64チャンネル分のデータを保持している。また、上記のBANDWIDTH_AVAILABLEレジスタは、アイソクロナス転送に使用可能な帯域を示す数値を格納するレジスタであり、1600Mbpsの転送速度で32ビットのデータ転送に要する時間を1ユニット(約20nsec)とし、これを単位に表わされる。
【0041】
IEEE1394のバス上の各ノードがアイソクロナス転送を行う際は、適正なチャンネル及び帯域を確保する必要がある。そのため、ロックトランザクションを発行することにより、CHANNELS_AVAILABLEレジスタを更新し、更にBANDWIDTH_AVAILABLEレジスタを更新し、これによりチャンネル及び帯域を確保することができる。このとき、チャンネルと帯域が正常に確保される場合はロックトランザクションによるレジスタ更新に成功するが、チャンネル又は帯域が確保できない場合はロックトランザクションによるレジスタ更新に失敗することになる。
【0042】
次に図2は、IEEE1394のバス上に接続された複数の情報伝送機器が相互にデータを伝送可能なデータ伝送システムの概念を示す図である。IEEE1394では、各情報伝送機器どうしの従来の物理的な信号接続に代わり、論理的な信号接続を行うためのプラグの概念が導入される。よって、IEEE1394のバス上でデータを送受信する際は、各情報伝送機器の仮想的なプラグを介して制御される。
【0043】
図2においては、3台の情報伝送機器としてのAV機器21、22、23がIEEE1394上に接続されている場合を例に示している。各AV機器21〜23は、データ出力に用いる出力プラグとデータ入力に用いる入力プラグとを仮想的に備えており、特定のAV機器の出力プラグを経由してアイソクロナスデータがバス上に送出され、他のAV機器の入力プラグを経由してアイソクロナスデータを受け取ることによりデータ転送を行うことができる。
【0044】
図2に示すように、各AV機器21、22は、出力プラグの属性を制御する出力プラグ制御レジスタ(oPCR:output plug control register)と、AV機器のoPCRに共通の属性を制御する出力マスタープラグレジスタ(oMPR:output master plug register)を備えている。また、各AV機器21、23は、入力プラグの属性を制御する入力プラグ制御レジスタ(iPCR:input plug control register)と、AV機器のiPCRに共通の属性を制御する入力マスタープラグレジスタ(iMPR:input master plug register)を備えている。
【0045】
なお、1つのAV機器でプラグ数は最大31個まで設定可能であるため、oPCRとiPCRは、それぞれ1つのAV機器において0個から最大31個まで存在可能である。一方、1つのAV機器においてoPCRとiPCRが多数存在する場合であっても、oMPRとiMPRはそれぞれ1個存在するだけである。図2の例では、AV機器21はiMPR、iPCR、oMPR,oPCRをそれぞれ1個づつ持ち、AV機器22はiMPR、iPCR、oMPRをそれぞれ1個づつと2個のoPCRを持ち、AV機器23は1個のiMPRと2個のiPCRを持っているとともに、各AV機器21〜23のプラグ間を結ぶ2系統のアイソクロナスチャンネルが確立されていることがわかる。
【0046】
ここで、上記のoPCR及びiPCRのデータフォーマットについて図3と図4を用いて説明する。図3に示すように、oPCRのデータフォーマットは、出力プラグの接続がオン又はオフのいずれであるかを示すオンラインフラグと、出力プラグを経由する後述のbroadcastコネクションの個数を示すbroadcastコネクションカウンタと、出力プラグを経由する後述のPoint-to-pointコネクションの個数を示すPoint-to-pointコネクションカウンタと、将来の機能拡張用の予備領域と、アイソクロナスデータの転送に用いるチャンネルの番号を示すチャンネル番号と、データを転送する際の転送速度を表すデータ転送速度と、アイソクロナスデータに付加されるオーバーヘッド量を示すオーバーヘッドIDと、1サイクルごとに転送されるデータ量を示すペイロードを含んでいる。
【0047】
また、図4に示すように、iPCRのデータフォーマットは、入力プラグの接続がオン又はオフのいずれであるかを示すオンラインフラグと、入力プラグを経由する後述のbroadcastコネクションの個数を示すbroadcastコネクションカウンタと、入力プラグを経由する後述のPoint-to-pointコネクションの個数を示すPoint-to-pointコネクションカウンタと、将来の機能拡張用の2つの予備領域と、アイソクロナスデータの転送に用いるチャンネルの番号を示すチャンネル番号を含んでいる。
【0048】
なお、上述のoPCR及びiPCRのデータ内容を変更する場合、変更対象となるoPCR又はiPCRを所有するAV機器自らが変更することも可能であるとともに、他のAV機器がIEEE1394のバスを介してロックトランザクションを発行することにより変更することも可能である。このようなロックトランザクションを用いる場合、要求側から応答側にデータを転送するとともに、応答側の特定のアドレスでデータを処理した後、要求側に返送するという手順に従って処理が行われる。
【0049】
一方、上述した通り、各AV機器間のアイソクロナスデータの転送は、図2に示すように、IEEE1394のバス上に設定されたアイソクロナスチャンネルを経由して行われる。このアイソクロナスチャンネルは、各AV機器の入力プラグと出力プラグを結び付けるパスとして機能し、上述のPCRを適切に設定することにより所望のアイスクロナスチャンネルを設定することができる。各AV機器のアイソクロナスチャンネルへのコネクションの形態としては、Point-to-pointコネクションと、broadcastコネクションの2種類がある。
【0050】
Point-to-pointコネクションは、特定のAV機器の1つの出力プラグ(oPCR)と他のAV機器の1つの入力プラグ(iPCR)とを、1つのアイソクロナスチャンネルに結び付けるコネクションの形態である。なお、1つのプラグに既に存在するpoint-to-pointコネクションに対し、別のPoint-to-point コネクションを存在させることも可能である。
【0051】
また、Broadcastコネクションには、特定のAV機器の1つの出力プラグ(oPCR)を1つのアイソクロナスチャンネルに結び付けるコネクションの形態であるBroadcast-outコネクション、及び、特定のAV機器の1つの入力プラグ(iPCR)を1つのアイソクロナスチャンネルに結び付けるコネクションの形態であるBroadcast-inコネクションの2つがある。
【0052】
次に、本実施形態におけるIEEE1394バス上のデータ伝送システムでバスリセットが発生した場合の処理について説明する。データ伝送システムに対し、新たなノードがバスに接続されたり、接続中のノードがバスから外れたりする状況が生じた場合、バス上の全てのノードにバスリセット信号が伝送され、トポロジー情報はいったん全てクリアされ、状況の変化に応じた新たなトポロジーを構築するための初期化処理が実行される。
【0053】
バスリセットが発生すると、各ノードのコネクションの確立時に取得されたアイソクロナスリソースやプラグが全てリセットされ、コネクションが解除されることになるが、バスリセット発生タイミングから1秒間はアイソクロナスデータの転送が継続される。よって、各ノードは、バスリセットが発生してから1秒以内に、新たなトポロジー情報に対応してアイソクロナスリソースの確保と各プラグの更新を行い、コネクションを回復するための処理を行う必要がある。IEEE1394バス上におけるコネクション回復処理は多数のプロセスからなり、実際にはアイソクロナスリソースの確保やトランザクションによるレジスタ更新に失敗する場合も想定されるので、1秒間ではコネクションが回復できないものも残る場合がある。本実施形態では、後述するように合理的な手順によりバスリセット時の回復不可能なコネクションを最低限に抑えることができる。
【0054】
次に、図5〜15を参照して、本実施形態におけるバスリセット時のコネクション回復処理について具体的に説明する。ここで、本実施形態ではIEEE1394バス上のメモリ手段において各プラグのコネクション情報データベースを構成し、バスリセット時のコネクション回復処理において必要となる各種データを保持する。図5は、このようなコネクション情報データベースの構成を示す図である。図5に示すコネクション情報データベースは、本実施形態のコネクション情報記録手段としての役割を担い、各出力プラグに対応するoPCR情報と、各入力プラグに対応するiPCR情報と、各コネクションに対応するPoint-to-pointコネクション情報とを含んで構成される。
【0055】
図5(a)に示すoPCR情報は、Broadcast-outコネクションのステータスと、Broadcast-outコネクションの回復処理で実行すべき処理プロセスと、上記oPCR中のbroadcastコネクションカウンタ及びオーバーヘッドID(図3)を含んでいる。また、図5(b)に示すiPCR情報は、Broadcast-inコネクションのステータスと、iPCR中のbroadcastコネクションカウンタ(図4)を含んでいる。また、図5(c)に示すPoint-to-pointコネクション情報は、Point-to-pointコネクションのステータスと、Point-to-pointコネクションの回復処理で実行すべき処理プロセスと、送信側ノードのGUID及びプラグIDと、受信側ノードのGUID及びプラグIDと、oPCR中のデータ転送速度、オーバーヘッドID、ペイロード、チャンネル番号(図3)を含んでいる。
【0056】
コネクション情報データベースに含まれる各ステータスは、それぞれのコネクション回復処理に関するアイソクロナスリソースの状態に応じて変化し、それぞれ有効な状態であるときはVALID、無効な状態であるときはINVALD、不定状態であるときはUNKNOWN、コネクション回復処理の実行中の状態であるときはPENDINGの4つの値をとる。このステータスは、コネクションを確立する際、バス資源の管理状態を示すコネクション状態情報としての役割を担う。バスリセット直後、有効なコネクションが存在する場合には各ステータスがPENDINGにセットされる。
【0057】
また、oPCR情報とPoint-to-pointコネクション情報に含まれる処理プロセスは、各コネクション回復処理を細分化して分割実行される各々の処理プロセスのうち、実行すべき最新の処理プロセスを保持するパラメータである。更に、Point-to-pointコネクション情報に含まれるGUIDは、各AV機器に固有のIDであり、IEEE1394バス上に接続されたAV機器を特定するためのパラメータであり、CSRアーキテクチャで規定されるコンフィギュレーションROMに記述されている。バスリセット時のコネクション回復処理の際にGUIDを取得することにより、上記のノードIDとの対応関係を明確にできるが、具体的な処理については後述する。
【0058】
次に図6は、バスリセット時に特定のノードにおいて実行されるコネクション回復処理の概略を示すフローチャートである。このフローチャートは、図1のファームウェアの上位に位置する層で実行され、アプリケーションからのコネクション確立要求等を処理し、下位のファームウェアに伝える。つまり、アプリケーションと下位のファームウェアの間に位置するミドルウェアである。
【0059】
図6に示すように、まず、IEEE1394バス上のノード接続の変更に起因し、所定のタイミングでバスリセットが発生する(ステップS1)。そして、バスリセット時のコネクション回復処理を行うのに先立って、対象ノードのコネクション情報データベースの各ステータスを初期化する(ステップS2)。この場合、ステータスがVALIDであるときはPENDINGにセットし、ステータスがUNKNOWNであるときはINVALIDにセットし、ステータスがINVALID又はPENDINGであるときはその値を保持する。
【0060】
続いて、コネクション回復処理の実行順を登録する回復コネクションキューを初期化する(ステップS3)。この回復コネクションキューは、IEEE1394バス上の各ノードのファームウェア等で実現されるFIFOで構成され、コネクション回復処理に含まれる各処理を順次登録し、その実行順を制御する登録手段としての役割を担う。すなわち、本実施形態では対象ノードについて実行すべきコネクション回復処理として、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理に加え、GUID取得処理の4つの処理に大別している。よって、これら4つの処理をコード化して回復コネクションキューに必要に応じて登録し、登録された順序で順次実行するように制御される。そして、ステップS3の初期化時には、GUID取得処理、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理の順に回復コネクションキューに登録し、最初はこの順に従って各回復処理が実行される。
【0061】
次に、バスリセット時点からの経過時間を監視し、1秒が経過したか否かを判断する(ステップS4)。その結果、バスリセット時点から1秒経過していない場合は(ステップS4;NO)、続いてコネクション情報データベースのいずれかのステータスがPENDINGにセットされているか否かを判断する(ステップS5)。
【0062】
ステップS4、S5の判断の結果、バスリセット時点から1秒経過した場合(ステップS4;YES)、あるいは、PENDINGのステータスが存在しない場合には(ステップS5;NO)、全てのステータス中にUNKNOWNのステータスが所定数以上あるか否かを判断する(ステップS6)。その結果、UNKNOWNのステータスが所定数以上存在する場合は(ステップS6;YES)、所定の処置を行い(ステップS7)、図6の処理を終える。
【0063】
例えば、図6の処理を実行しているミドルウェアからバス資源の管理状態が異常でありコネクションの確立が失敗した旨をアプリケーションに通知することにより、これを受けたアプリケーションがミドルウェアにバスリセットを発生し、更にコネクションの確立を要求することができる。また、ミドルウェア自らバスリセットを発生して一度コネクションをリセットしてから、コネクションの確立が失敗した旨をアプリケーションに通知してもよい。また、ミドルウェア自らバスリセットを発生して一度コネクションをリセットし、バスリセット後にコネクションを回復した後、再度、要求されていたコネクションの確立までを行うようにしてもよい。
【0064】
これにより、各コネクション回復処理において不定の状態が多く、コネクションを正常に回復できないと判断される場合、コネクション回復処理をやり直すべくバスリセット発生により図6の処理を再度実行させることができる。一方、UNKNOWNのステータスが所定数に満たない場合は(ステップS6;NO)、ステップS7を行うことなく図6の処理を終え、回復されたコネクションによりデータ伝送を行うことができる。
【0065】
一方、ステップS5の判断の結果、PENDINGのステータスがあると判断された場合(ステップS5;YES)、上記の回復コネクションキューを参照し、その内容に応じた処理を実行する(ステップS8)。上述したように、回復コネクションキューに登録された実行順に従って、GUIDの取得処理(ステップS9)、Broadcast-outコネクションの回復処理(ステップS10)、Broadcast-inコネクションの回復処理(ステップS11)、Point-to-pointコネクションの回復処理(ステップS12)のいずれかを順次実行する。以下、これら4つの各処理についてそれぞれ説明する。
【0066】
まず、GUIDの取得処理(ステップS9)では、対象ノードのAV機器に設定された上記コンフィグレーションROMを読み出してGUIDの取得を行う。この時点で全てのノードについてのGUIDを取得した場合は、そのままステップS9を終える。一方、何らかの要因でGUIDを取得できないノードが残っている場合は、次の機会にGUIDを取得すべく、回復コネクションキューにGUIDの取得処理を登録する。
【0067】
次に、図7〜図10のフローチャートを用いて、ステップS10のBroadcast-outコネクションの回復処理について説明する。図7に示すように、回復コネクションキューに従ってBroadcast-outコネクションの回復処理が開始されると、コネクション情報データベースのoPCR情報にアクセスし、上記の処理プロセスによって判別される個別の処理を実行する(ステップS101)。Broadcast-outコネクションの回復処理は、処理プロセスが1から6まで計6つの個別の処理に分割されている。なお、処理プロセスの初期値は1に設定されているものとする。
【0068】
ステップS101の判断に基づき処理プロセス1が実行される場合は、対象ノードについてチャンネルの確保を実行する(ステップS102)。すなわち、CSR空間のCHANNELS_AVAILABLEレジスタにアクセスし、所望のチャンネルに対応して更新を行うことによりチャンネルが確保される。次いで、ステップS102の処理がタイムアウト又はデータエラーとなるか否かを判断する(ステップS103)。ステップS103の判断結果が「YES」である場合はチャンネルが確保できないので、これ以降の処理を行うことなくステップS121(図10)に移行する。なお、本実施形態では、タイムアウトを判定する経過時間を1サイクル=125μsecとして800サイクル(=100msec)に設定する。
【0069】
ステップS103の判断結果が「NO」であるときは、所望のチャンネルの確保に成功したか否かを判断する(ステップS104)。例えば、他のノードにより所望のチャンネルが既に使用されている場合は、そのチャンネルを確保することはできない。そして、チャンネルの確保に失敗したときは(ステップS104;NO)処理プロセスを2に設定し(ステップS105)、チャンネルの確保に成功したときは(ステップS104;YES)処理プロセスを3に設定する(ステップS106)。ステップS105又はステップS106を終えると、ステップS124(図10)に移行する。
【0070】
次に、ステップS101の判断に基づき処理プロセス2が実行される場合は、接続可能な出力プラグに対しoPCRのポーリングを実行する(ステップS107)。これは、処理プロセス1にてチャンネル確保に失敗した場合であっても、使用すべきチャンネルに対してオーバレイを行う可能性を考慮したものである。このオーバーレイは、ソースノードとoPCRが同一である場合、既に存在するそのoPCR上のコネクションに対して、別のコネクションを重ねたり、Point-to-pointコネクションの上にBroadcast-outコネクション又はPoint-to-pointコネクションを重ねて設定することである。ステップS107では、他のノードによりオーバーレイが行われることを想定し、各出力プラグのoPCRのPoint-to-pointコネクションカウンタがバスリセット後に更新されるか否かを監視すべく、oPCRのポーリングを行うものである。
【0071】
次いで、ステップS107でポーリングされたoPCRが更新されたか否かを判断する(ステップS108)。例えば、元々Point-to-pointコネクションの値が0であるとき更新されると値は1に変化する。ステップS108の判断結果が「NO」であるときは、ステップS124(図10)に移行する。一方、ステップS108の判断結果が「YES」であるときは、処理プロセスを4に設定する(ステップS109)。ステップS109を終えると、ステップS124(図10)に移行する。
【0072】
次に図8に示すように、ステップS101の判断に基づき処理プロセス3が実行される場合は、対象ノードについて帯域の確保を実行する(ステップS110)。すなわち、CSR空間のBANDWIDTH_AVAILABLEレジスタにアクセスし、転送に必要となる帯域に対応して更新を行うことにより帯域が確保される。次いで、ステップS110の処理がタイムアウト(800サイクル(=100msec)経過時点)又はデータエラーとなるか否かを判断する(ステップS111)。ステップS111の判断結果が「YES」であるときは、帯域が確保できないので、これ以降の処理を行うことなくステップS121に(図10)に移行する。
【0073】
一方、ステップS111の判断結果が「NO」であるときは、必要な帯域の確保に成功したか否かを判断する(ステップS112)。例えば、空いている帯域が必要な帯域に不足している場合は、その帯域を確保することはできない。そして、帯域の確保に成功したときは(ステップS112;YES)、処理プロセスを4に設定し(ステップS113)、帯域の確保に失敗したときは(ステップS112;NO)、処理プロセスを6に設定する(ステップS114)。ステップS113又はステップS114を終えると、ステップS124(図10)に移行する。
【0074】
次に、ステップS101の判断に基づき処理プロセス4が実行される場合は、対象ノードの出力プラグに対し、oPCRの更新を実行する(ステップS115)。すなわち、処理プロセス1及び3により確保されたチャンネル及び帯域に対応する値をoPCRのチャンネル番号やデータ転送速度に設定するとともに、broadcastコネクションカウンタをインクリメントする。そして、ステップS115の結果、oPCRの更新に成功したか否かを判断し(ステップS116)、判断結果が「YES」であるときは、ステップS122(図10)に移行し、判断結果が「NO」であるときは、処理プロセスを5に設定する(ステップS117)。ステップS117を終えると、ステップS124(図10)に移行する。
【0075】
次に図9に示すように、ステップS101の判断に基づき処理プロセス5が実行される場合は、ステップS112で確保された帯域の解放を実行する(ステップS118)。すなわち、処理プロセス4でoPCRの更新に失敗したため、この時点では所望のBroadcast-outコネクションを回復できないと判断され、確保した帯域をいったん解放すべくステップS118を実行するのである。その後、処理プロセスを6に設定し(ステップS119)、ステップS124(図10)に移行する。
【0076】
また、ステップS101の判断に基づき処理プロセス6が実行される場合は、ステップS102で確保されたチャンネルの解放を実行する(ステップS120)。すなわち、上述した処理プロセスと同様の理由により、確保したチャンネルをいったん解放すべくステップS120を実行するのである。この処理プロセス6に続いてステップS123(図10)に移行する。
【0077】
次に、Broadcast-outコネクションの回復処理において、各処理プロセス1〜6に後続する処理について図10のフローチャートを用いて説明する。図10におけるステップS121〜S124は、コネクション情報データベースの対象となるステータスに関する処理である。
【0078】
まず、処理プロセス1のステップS103(図7)又は処理プロセス3のステップS111(図8)から移行した場合は、ステータスをUNKNOWNにセットする(ステップS121)。この場合は、タイムアウト又はデータエラーと判断されたので、この時点で処理対象のコネクションが正常に回復できる否かが不定の状態にある。
【0079】
また、処理プロセス4のステップS116(図8)から移行した場合は、ステータスをVALIDにセットする(ステップS122)。この場合は、チャンネルと帯域の確保及びoPCRの更新に成功し、この時点で処理対象のコネクションが回復して有効な状態にある。
【0080】
また、処理プロセス6のステップS120(図9)から移行した場合は、ステータスをINVALIDにセットする(ステップS123)。この場合は、上述した理由でチャンネルと帯域を解放したので、この時点で処理対象のコネクションが回復できず無効な状態にある。
【0081】
また、各処理プロセス1〜6において、次に実行すべき処理プロセスの設定後に移行した場合、あるいは、処理プロセス2のステップS108(図7)から移行した場合は、ステータスを変えずに元の値を維持する(ステップS124)。この場合は、対象のコネクション回復処理を継続する必要があり、更に処理が進行した時点でステータスを更新すればよい。
【0082】
ステップS121〜S124に続いて、対象ノードの全ての出力プラグについてBroadcast-outコネクションの回復処理を終了したか否かを判断する(ステップS125)。その結果、未終了の出力プラグがある場合は(ステップS125;NO)、回復コネクションキューにBroadcast-outコネクションの回復処理を登録し(ステップS126)、図10の処理を終える。これにより、残存するBroadcast-outコネクションの回復処理については、後に回復コネクションキューの順序に従って図7〜10の処理が再度実行されることになる。一方、全ての出力プラグについて上記処理を終了した場合は(ステップS125;YES)、又はステップS126の終了後は、図11の処理を終えてステップS13(図6)に移行する。
【0083】
次に、図11のフローチャートを用いて、ステップS11のBroadcast-inコネクションの回復処理について説明する。ここでは、入力プラグについてのiPCRに関する処理を行うこととし、出力プラグを経由するBroadcastコネクションに対するチャンネル及び帯域の確保に関しては、上述のBroadcast-outコネクションの回復処理において実行されることになる。よって、Broadcast-inコネクションの回復処理は、Broadcast-outコネクションの回復処理のように複数の処理プロセスに細分化する必要はない。
【0084】
図11において、回復コネクションキューに従ってBroadcast-inコネクションの回復処理が開始されると、対象ノードの入力プラグに対し、iPCRの更新を実行する(ステップS201)。すなわち、受信すべきチャンネル番号に設定するとともに、broadcastコネクションカウンタをインクリメントする。続いて、ステップS201の結果、iPCRの更新に成功したか否かを判断する(ステップS202)。
【0085】
ステップS202の判断結果が「YES」となりiPCRの更新に成功した場合は、コネクション情報データベースの対象となるステータスをVALIDにセットする(ステップS203)。一方、ステップS202の判断結果が「NO」となりiPCRの更新に失敗したときは、上記ステータスをINVALIDにセットする(ステップS204)。そして、対象ノードの全ての入力プラグについてBroadcast-inコネクションの回復処理を終了したか否かを判断し(ステップS205)。その結果、未終了の入力プラグがある場合は(ステップS205;NO)、回復コネクションキューにBroadcast-inコネクションの回復処理を登録し(ステップS206)、図11の処理を終える。一方、全ての入力プラグについて上記処理を終了した場合は(ステップS205;YES)、ステップS206を行うことなく図11の処理を終える。これにより、残存するBroadcast-inコネクションの回復処理については、後に回復コネクションキューの順序に従って図11の処理が再度実行されることになる。
【0086】
次に、図12〜図15のフローチャートを用いて、ステップS12のPoint-to-pointコネクションの回復処理について説明する。図12に示すように、回復コネクションキューに従ってPoint-to-pointコネクションの回復処理が開始されると、コネクション情報データベースのPoint-to-pointコネクション情報にアクセスし、上記の処理プロセスによって判別される個別の処理を実行する(ステップS301)。Point-to-pointコネクションの回復処理は、処理プロセスが1から8までの計8つの個別の処理に分割され、上記のBroadcast-outコネクションの回復処理よりも更に多くなっている。この場合も、処理プロセスの初期値は1に設定されているものとする。
【0087】
図12に示すように、ステップS301の判断に基づき処理プロセス1が実行される場合は、Point-to-pointコネクションで必要なGUIDが既知であるか否かを判断する(ステップS302)。すなわち、Point-to-pointコネクションでは入力プラグと出力プラグの双方が存在するので、それぞれのノードのAV機器が判別可能であることが前提となるため、図6のステップS9に基づきGUIDが取得済みであることを確認するものである。または、バスリセット後に受信したアイソクロナスパケットから送信ノードを特定することで、バスリセット前に接続されていたAV機器と判別するようにしてもよい。その結果、GUIDが未知であるときは(ステップS302;NO)、これ以降の処理を行うことなくステップS333(図15)に移行する。
【0088】
一方、GUIDが既知であるときは(ステップS302;YES)、回復すべきPoint-to-pointコネクションで用いるチャンネルの確保を実行する(ステップS303)。すなわち、CSR空間のCHANNELS_AVAILABLEレジスタにアクセスし、上記のチャンネルに対応して更新を行うことによりチャンネルが確保される。次いで、ステップS303の処理がタイムアウト(800サイクル(=100msec)経過時点)又はデータエラーとなるか否かを判断する(ステップS304)。ステップS304の判断結果が「YES」である場合はチャンネルが確保できないので、これ以降の処理を行うことなくステップS330(図15)に移行する。
【0089】
ステップS304の判断結果が「NO」である場合は、所望のチャンネルの確保に成功したか否かを判断する(ステップS305)。その結果、チャンネルの確保に失敗したときは(ステップS305;NO)処理プロセスを2に設定し(ステップS306)、チャンネルの確保に成功したときは(ステップS305;YES)処理プロセスを3に設定する(ステップS307)。ステップS307を終えると、ステップS333(図15)に移行する。
【0090】
次に、ステップS301の判断に基づき処理プロセス2が実行される場合は、接続可能な出力プラグに対しoPCRのポーリングを実行する(ステップS308)。これは、Broadcast-outコネクションの回復処理の処理プロセス2と同様に、BroadcastコネクションとPoint-to-pointコネクションのオーバレイを考慮した処理である。すなわち、ステップS308では、他のノードによりオーバーレイが行われることを想定し、各出力プラグのoPCRのPoint-to-pointコネクションカウンタがバスリセット後に更新されるか否かを監視すべく、oPCRのポーリングを行うものである。
【0091】
次いで、ステップS308でポーリングされたoPCRが更新されたか否かを判断する(ステップS309)。そして、ステップS309の判断結果が「NO」であるときは、ステップS333(図15)に移行する。一方、ステップS309の判断結果が「YES」であるときは、処理プロセスを4に設定し(ステップS310)、ステップS333(図15)に移行する。
【0092】
次に図13に示すように、ステップS301の判断に基づき処理プロセス3が実行される場合は、転送に必要な帯域の確保を実行する(ステップS311)。すなわち、CSR空間のBANDWIDTH_AVAILABLEレジスタにアクセスし、転送に必要となる帯域に対応して更新を行うことにより帯域が確保される。次いで、ステップS311の処理がタイムアウト(800サイクル(=100msec)経過時点)又はデータエラーとなるか否かを判断する(ステップS312)。ステップS312の判断結果が「YES」であるときは、これ以降の処理を行うことなくステップS330(図15)に移行する。
【0093】
一方、ステップS312の判断結果が「NO」であるときは、必要な帯域の確保に成功したか否かを判断する(ステップS313)。そして、帯域の確保に成功したときは(ステップS313;YES)、処理プロセスを4に設定し(ステップS314)、帯域の確保に失敗したときは(ステップS313;NO)、処理プロセスを8に設定する(ステップS315)。ステップS314又はステップS315を終えると、ステップS333(図15)に移行する。
【0094】
次に、ステップS301の判断に基づき処理プロセス4が実行される場合は、Point-to-pointコネクションの送信側の出力プラグに対し、oPCRの更新を実行する(ステップS316)。ここでは、Point-to-pointコネクション確立側のノードが更新対象のノードと異なる場合を前提とする。この場合、更新対象のノードに対してトランザクションを発行することにより、処理プロセス1及び3により確保されたチャンネル及び帯域に対応する値をoPCRのチャンネル番号やデータ転送速度に設定するとともに、Point-to-pointコネクションカウンタをインクリメントする。そして、ステップS316の処理がタイムアウト(800サイクル(=100msec)経過時点)又はデータエラーとなるか否かを判断し(ステップS317)。判断結果が「YES」であるときは、これ以降の処理を行うことなくステップS331(図15)に移行する。
【0095】
一方、ステップS317の判断結果が「NO」であるときは、oPCRの更新に成功したか否かを判断する(ステップS318)。その結果、oPCRの更新に成功した場合は(ステップS318;YES)、処理プロセスを5に設定し(ステップS319)、oPCRの更新に失敗した場合は(ステップS318;NO)、処理プロセスを7に設定する(ステップS320)。ステップS319又はステップS320を終えると、ステップS333(図15)に移行する。
【0096】
次に図14に示すように、ステップS301の判断に基づき処理プロセス5が実行される場合は、Point-to-pointコネクションの受信側の入力プラグに対し、iPCRの更新を実行する(ステップS321)。上述したように、Point-to-pointコネクション確立側のノードが更新対象のノードと異なる場合を前提とする。この場合、更新対象のノードに対してトランザクションを発行することにより、処理プロセス1により確保されたチャンネルをiPCRのチャンネル番号に設定するとともに、Point-to-pointコネクションカウンタをインクリメントする。そして、ステップS321の処理がタイムアウト(800サイクル(=100msec)経過時点)又はデータエラーとなるか否かを判断し(ステップS322)。判断結果が「YES」であるときは、これ以降の処理を行うことなくステップS330(図15)に移行する。
【0097】
一方、ステップS322の判断結果が「NO」であるときは、iPCRの更新に成功したか否かを判断する(ステップS323)。その結果、iPCRの更新に成功した場合は(ステップS323;YES)、ステップS331(図15)に移行し、iPCRの更新に失敗した場合は(ステップS323;NO)、処理プロセスを6に設定する(ステップS324)。ステップS324を終えると、ステップS333(図15)に移行する。
【0098】
次に、ステップS301の判断に基づき処理プロセス6が実行される場合は、上記の処理プロセス4にて更新されたoPCRの解放を実行する(ステップS325)。これは、処理プロセス4において送信側の出力プラグに対しoPCRを更新したにもかかわらず、処理プロセス5において受信側の入力プラグに対するiPCRを更新できなかった場合の処理である。すなわち、この時点では所望のPoint-to-pointコネクションを回復できないと判断されるので、いったんoPCRの状態を元に戻すべくステップS325を実行するのである。その後は処理プロセスを7に設定し(ステップS326)、ステップS333(図15)に移行する。
【0099】
次に、ステップS301の判断に基づき処理プロセス7が実行される場合は、ステップS311で確保された帯域の解放を実行する(ステップS327)。これは、処理プロセス4において送信側の出力プラグに対するoPCRを更新できなかった場合、又は、処理プロセス5において受信側の入力プラグに対するiPCRを更新できなった場合の処理である。いずれの場合も、この時点では所望のPoint-to-pointコネクションを回復できないと判断され、確保した帯域をいったん解放すべくステップS327を実行するのである。その後、処理プロセスを8に設定し(ステップS328)、ステップS333(図15)に移行する。
【0100】
また、ステップS301の判断に基づき処理プロセス8が実行される場合は、ステップS303で確保されたチャンネルの解放を実行する(ステップS329)。すなわち、上述した処理プロセス7と同様の理由により、確保したチャンネルをいったん解放すべくステップS329を実行するのである。その後はステップS332(図15)に移行する。
【0101】
次に、Broadcast-inコネクションの回復処理において、各処理プロセス1〜8に後続する処理について図15のフローチャートを用いて説明する。図15におけるステップS330〜S333は、コネクション情報データベースの対象となるステータスに関する処理である。
【0102】
まず、処理プロセス1、3、4、5にてタイムアウト又はデータエラーと判断されて移行した場合は、ステータスをUNKNOWNにセットする(ステップS330)。上述したように、この時点では処理対象のコネクションが正常に回復できる否かが不定の状態にある。
【0103】
また、処理プロセス5のステップS323(図14)から移行した場合は、ステータスをVALIDにセットする(ステップS331)。この場合は、チャンネルと帯域の確保及びoPCRとiPCRの更新に成功し、この時点で処理対象のコネクションが回復して有効な状態にある。
【0104】
また、処理プロセス8のステップS329(図14)から移行した場合は、ステータスをINVALIDにセットする(ステップS332)。この場合は、上述した理由でチャンネルと帯域を解放したので、この時点で処理対象のコネクションが回復できず無効な状態にある。
【0105】
また、各処理プロセス1〜8において、次に実行すべき処理プロセスを設定後に移行した場合、あるいは、処理プロセス2のステップS309(図12)から移行した場合は、ステータスを変えずに元の値を維持する(ステップS333)。この場合は、コネクション回復処理を継続して実行する必要があり、更に処理が進行した時点でステータスを更新すればよい。
【0106】
ステップS330〜S333に続いて、対象ノードの全てのPoint-to-pointコネクションについて回復処理を終了したか否かを判断する(ステップS334)。その結果、未終了のPoint-to-pointコネクションがある場合は(ステップS334;NO)、回復コネクションキューにPoint-to-pointコネクションの回復処理を登録する(ステップS335)。これにより、残存するPoint-to-pointコネクションの回復処理については、後に回復コネクションキューの順序に従って図12〜15の処理が再度実行されることになる。一方、全てのPoint-to-pointコネクションについて上記処理を終了した場合(ステップS334;YES)、又はステップS335の終了後は、図15の処理を終えてステップS13(図6)に移行する。
【0107】
以上、図6のステップS8により実行順を制御される処理として、GUIDの取得処理、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理について、それぞれ説明を行った。次に図6に戻って、ステップS9〜S12に続いて、新たなバスリセットの発生の有無を検出する(ステップS13)。その結果、バスリセットの発生が検出されたときは(ステップS13;YES)、ステップS2に移行して再び初期化(ステップS3、S4)を行って最初から上記の処理を実行する。一方、バスリセットの発生が検出されないときは(ステップS13;NO)、ステップS4以降の処理を繰り返し実行する。
【0108】
このように本実施形態によれば、各ノードにおけるコネクション回復に関連する処理を大きく4つに分け、その実行順を回復コネクションキューにより制御するとともに、Broadcast-outコネクションの回復処理とPoint-to-pointコネクションの回復処理は、それぞれを細分化して複数の処理プロセスを分割実行するように制御する。このとき、処理プロセスで確保されるアイソクロナスリソースの管理状態をステータスにより逐次設定し、最終的にバス全体で不定状態のステータスが多い場合はバスをリセットしてコネクション回復処理を再度実行するようにしたので、アイソクロナスリソースが未使用のまま維持されることを防止し、バス資源を有効に利用することができる。
【0109】
なお、本実施形態では、バスリセット時のコネクション回復処理に対して本発明を適用する場合を説明したが、バスリセット時に限らず一般的なコネクション確立処理に対し広く本発明を適用することができる。
【0110】
また、本実施形態では、データ転送のインターフェース規格としてIEEE1394を採用したデータ伝送システムに対し本発明を適用した場合を説明したが、これに限られることなく、コネクションの確立が必要な各種データ伝送システムに対し、広く本発明を適用することができる。
【0111】
【発明の効果】
以上説明したように本発明によれば、データ伝送システムにおけるコネクションを確立処理に際し、それぞれのノードでコネクション状態情報を用いてバス資源が管理できる状態にあるか否かを判断し、コネクションが確立されたときに管理不能のバス資源が残った状態になることを回避し、バス資源を適正に割り当てて信頼性の高いデータ伝送システム、情報伝送装置、及び、コネクション確立方法を実現することができる。
【図面の簡単な説明】
【図1】IEEE1394のプロトコルの構成を示すブロック図である。
【図2】IEEE1394のバス上に接続された複数の情報伝送機器によるデータ伝送システムの概念を示す図である。
【図3】oPCRのデータフォーマットを示す図である。
【図4】iPCRのデータフォーマットを示す図である。
【図5】コネクション情報データベースの構成を示す図である
【図6】本実施形態に係るコネクション回復処理の概略を示すフローチャートである。
【図7】 Broadcast-outコネクションの回復処理を示す第1のフローチャートである。
【図8】 Broadcast-outコネクションの回復処理を示す第2のフローチャートである。
【図9】 Broadcast-outコネクションの回復処理を示す第3のフローチャートである。
【図10】 Broadcast-outコネクションの回復処理を示す第4のフローチャートである。
【図11】 Broadcast-inコネクションの回復処理を示すフローチャートである。
【図12】 Point-to-pointコネクションの回復処理を示す第1のフローチャートである。
【図13】 Point-to-pointコネクションの回復処理を示す第2のフローチャートである。
【図14】 Point-to-pointコネクションの回復処理を示す第3のフローチャートである。
【図15】 Point-to-pointコネクションの回復処理を示す第4のフローチャートである。
【符号の説明】
10…物理層
11…リンク層
12…トランザクション層
13…バス管理層
21〜23…AV機器
Claims (17)
- 複数の情報伝送機器がバス上のノードに接続され、各ノード間でコネクションを確立してデータを伝送するデータ伝送システムにおいて、
それぞれのノードにおけるコネクション確立処理を実行する際にコネクションの確立状態を示すコネクション状態情報を更新可能に保持し、
前記コネクション状態情報は、前記コネクション確立処理の結果に応じて更新され、且つ、コネクションを確立することができた有効状態と、コネクションを確立することができない無効状態と、コネクションを確立することができるか否かが不定である不定状態と、を少なくとも含み、
前記バス上で確立すべきコネクションのうち、少なくとも前記コネクション状態情報が不定状態に設定されたコネクションに対応するバス資源を解放することを特徴とするデータ伝送システム。 - 前記コネクションの種別に対応する複数のコネクション確立処理が設けられ、それぞれに対し前記コネクション状態情報が保持されることを特徴とする請求項1に記載のデータ伝送システム。
- 前記バス上で確立すべきコネクションのうち、前記不定状態に設定された前記コネクション状態情報が所定数以上存在する場合、バスリセットを発生させることを特徴とする請求項1又は請求項2に記載のデータ伝送システム。
- 前記コネクション確立処理には、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれ、それぞれの前記処理プロセスにおいてタイムアウト又はデータエラーが生じた場合、処理対象の前記コネクション状態情報を前記不定状態に設定することを特徴とする請求項1に記載のデータ伝送システム。
- 前記バスはIEEE1394規格に準拠したシリアルバスであり、前記複数のコネクション確立処理には、Broadcast-outコネクションの確立処理、Broadcast-inコネクションの確立処理、Point-to-pointコネクションの確立処理が含まれることを特徴とする請求項2に記載のデータ伝送システム。
- 前記複数のコネクション確立処理は、バスリセット発生に伴い確立されたコネクションが解除されたとき、所定時間が経過するまでに各ノードにおいて前記コネクションを回復するためのコネクション回復処理に対応し、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする請求項5に記載のデータ伝送システム。
- バス上のノードに接続された複数の情報伝送機器がデータを伝送するデータ伝送システムの前記各ノード間でコネクションを確立するコネクション確立方法において、
それぞれのノードにおけるコネクション確立処理を実行する際にコネクションの確立状態を示すコネクション状態情報を更新可能に保持し、
前記コネクション状態情報は、前記コネクション確立処理の結果に応じて更新され、且つ、コネクションを確立することができた有効状態と、コネクションを確立することができない無効状態と、コネクションを確立することができるか否かが不定である不定状態と、を少なくとも含み、
前記バス上で確立すべきコネクションのうち、少なくとも前記コネクション状態情報が不定状態に設定されたコネクションに対応するバス資源を解放することを特徴とするコネクション確立方法。 - 前記コネクションの種別に対応する複数のコネクション確立処理が設けられ、それぞれに対し前記コネクション状態情報が保持されることを特徴とする請求項7に記載のコネクション確立方法。
- 前記バス上で確立すべきコネクションのうち、前記不定状態に設定された前記コネクション状態情報が所定数以上存在する場合、バスリセットを発生させることを特徴とする請求項7又は請求項8に記載のコネクション確立方法。
- 前記コネクション確立処理には、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれ、それぞれの前記処理プロセスにおいてタイムアウト又はデータエラーが生じた場合、処理対象の前記コネクション状態情報を前記不定状態に設定することを特徴とする請求項7に記載のコネクション確立方法。
- 前記バスはIEEE1394規格に準拠したシリアルバスであり、前記複数のコネクション確立処理には、Broadcast-outコネクションの確立処理、Broadcast-inコネクションの確立処理、Point-to-pointコネクションの確立処理が含まれることを特徴とする請求項8に記載のコネクション確立方法。
- バス上のノードに接続可能で、他ノードとの間でコネクションを確立してデータを伝送する情報伝送装置において、
コネクション確立処理を実行する際にコネクションの確立状態を示すコネクション状態情報を更新可能に保持し、
前記コネクション状態情報は、前記コネクション確立処理の結果に応じて更新され、且つ、コネクションを確立することができた有効状態と、コネクションを確立することができない無効状態と、コネクションを確立することができるか否かが不定である不定状態と、を少なくとも含み、
前記コネクション状態情報が不定状態に設定されたコネクションに対応するバス資源を解放させるように制御することを特徴とする情報伝送装置。 - 前記コネクションの種別に対応する複数のコネクション確立処理が設けられ、それぞれに対し前記コネクション状態情報が保持されることを特徴とする請求項12に記載の情報伝送装置。
- 前記バス上で確立すべきコネクションのうち、前記不定状態に設定された前記コネクション状態情報が所定数以上存在する場合、バスリセットを発生させることを特徴とする請求項12又は請求項13に記載の情報伝送装置。
- 前記コネクション確立処理には、各ノードを結ぶチャンネルを確保する処理プロセスと、データ伝送に必要な帯域を確保する処理プロセスとが含まれ、それぞれの前記処理プロセスにおいてタイムアウト又はデータエラーが生じた場合、処理対象の前記コネクション状態情報を前記不定状態に設定することを特徴とする請求項12に記載の情報伝送装置。
- 前記バスはIEEE1394規格に準拠したシリアルバスであり、前記複数のコネクション確立処理には、Broadcast-outコネクションの確立処理、Broadcast-inコネクションの確立処理、Point-to-pointコネクションの確立処理が含まれることを特徴とする請求項13に記載の情報伝送装置。
- 前記複数のコネクション確立処理は、バスリセット発生に伴い確立されたコネクションが解除されたとき、所定時間が経過するまでに各ノードにおいて前記コネクションを回復するためのコネクション回復処理に対応し、Broadcast-outコネクションの回復処理、Broadcast-inコネクションの回復処理、Point-to-pointコネクションの回復処理が含まれることを特徴とする請求項16に記載の情報伝送装置。
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 | Necエンジニアリング株式会社 | パケット送受信装置及びそれに用いるパケット識別方法 |
KR100567309B1 (ko) | 2004-06-15 | 2006-04-04 | 삼성전자주식회사 | 데이터 헤더 오류 체크를 통한 버스 사용 효율 향상 방법 |
KR100581221B1 (ko) * | 2004-06-30 | 2006-05-22 | 삼성전자주식회사 | 테이프 배선 기판 제조 방법 |
WO2006044816A1 (en) * | 2004-10-14 | 2006-04-27 | 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 |
WO2010125655A1 (ja) * | 2009-04-28 | 2010-11-04 | パイオニア株式会社 | 制御装置、ネットワークシステム、送信装置、受信装置、制御方法及び制御プログラム |
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 | Ieee1394機器制御装置 |
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 |
---|---|
JP2002217907A (ja) | 2002-08-02 |
US7139853B2 (en) | 2006-11-21 |
EP1223712A2 (en) | 2002-07-17 |
US20020095505A1 (en) | 2002-07-18 |
EP1223712A3 (en) | 2005-01-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3277874B2 (ja) | Ieee1394ブリッジ | |
JP4143405B2 (ja) | 無線リンクを介してieee1394規格遠隔装置をieee1394規格装置のクラスタへ接続する方法 | |
US6810452B1 (en) | Method and system for quarantine during bus topology configuration | |
US6374316B1 (en) | Method and system for circumscribing a topology to form ring structures | |
JP2004363687A (ja) | 情報通信装置、そのシステム、その方法、そのプログラム、および、そのプログラムを記録した記録媒体 | |
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 | |
EP1391085B1 (en) | Method for managing a communication network comprising wireless links with more than two wireless devices | |
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) | Ieee 1394 기반의 양방향 비동기 연결 방법 | |
JP4611974B2 (ja) | Ieee1394バスの再初期化メッセージを転送する方法、及びかかる方法を実行する装置 | |
JP2003051824A (ja) | 通信方法、通信システム、プログラム及び記憶媒体 | |
JP5618805B2 (ja) | 通信装置、ネットワークシステム及び通信方法 | |
JPH11215132A (ja) | 情報処理装置および方法、並びに提供媒体 | |
JP4129603B2 (ja) | 情報処理装置および方法、並びに提供媒体 | |
EP1246400A1 (en) | Method for linking several communication busses using wireless links | |
JP4244474B2 (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 |