JP3647815B2 - 通信方法および通信装置 - Google Patents
通信方法および通信装置 Download PDFInfo
- Publication number
- JP3647815B2 JP3647815B2 JP2002066010A JP2002066010A JP3647815B2 JP 3647815 B2 JP3647815 B2 JP 3647815B2 JP 2002066010 A JP2002066010 A JP 2002066010A JP 2002066010 A JP2002066010 A JP 2002066010A JP 3647815 B2 JP3647815 B2 JP 3647815B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- node
- destination
- bus
- information
- 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
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/26—Special purpose or proprietary protocols or architectures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、受け取ったパケット中の所定条件を具備するパケットのみを上位層に通知する通信方法および通信装置に関する。
【０００２】
【従来の技術】
ＩＥＥＥ１３９４−１９９５、ＩＥＥＥ１３９４ａ−２０００は高速シリアルバスの規格で、非同期転送（Asynchronous）と同期転送（Isochronous）の２種類の転送をサポートしている。
【０００３】
バスに接続されたノード間で非同期転送が行なわれる場合、リード要求ノードからリード要求パケットが送出され、リード応答ノードからリード応答パケットが送出される。リード要求パケットのヘッダ部分およびリード応答パケットのヘッダ部分の双方にデスティネイションＩＤ（destination_ID：パケットを受け取るべきノードのID）が格納されている。
【０００４】
バスに接続されている各ノードのリンク層では、バス上にパケットが存在すれば、物理層インタフェースを介してそのパケットを受け取り、そのパケットのヘッダ部分に格納されているデスティネイションIDと各ノードを識別するID（自己ノードID）とが一致するかを判定する。
【０００５】
両IDが一致する場合、パケット内の情報が上位層であるトランザクション（Transaction）層に通知される。
【０００６】
【発明が解決しようとする課題】
しかしながら、従来の技術には下記のような２つの問題点がある。まず、第１の問題点について説明する。ＩＥＥＥ１３９４では、ケーブルの挿抜によってノードの接続状態が変化するとバスリセットが発生し、各ノードのノードIDが変化する。各ノードの新たなノードIDは、ケーブルの挿抜によって発生するバスリセット後に続くツリー識別、自己識別の過程で決定される。また、全てのノードは機器の製造者等を特定するためにＥＵＩ−６４といわれる６４ビットの重複のないデータをコンフィギュレーションＲＯＭ内の特定アドレス領域に格納している。
【０００７】
ＩＥＥＥ１３９４をサポートしているＷｉｎｄｏｗｓ２０００のようなＯＳでは、バスリセット、ツリー識別、自己識別が完了すると、その後にバス上の各ノードは他のノードを識別するために、自己以外の全ノードのＥＵＩ−６４をリードする。特定ノードの特定アドレスへのリードトランザクションは、パケットのヘッダ部分にノードを特定するデスティネイションIDとアドレスを特定するデスティネイション・オフセットを格納して、リード要求パケットを送信することで開始する。これを受信したノードは、要求されたアドレスのデータをリード応答パケットに格納して返信する。かかるリード要求パケットの送信およびリード応答パケットの返信によって、リードトランザクションが終了する。バスリセット、ツリー識別、自己識別完了後、各ノードが、“全ノード数−１”個のリードトランザクションを送出する。
【０００８】
例えば、第１ノード、第２ノードおよび第３ノードが存在する場合、（１）第２ノードをデスティネイションＩＤとするリード要求パケットと、第３ノードをデスティネイションＩＤとするリード要求パケットとが、第１ノードから送出され、（２）第３ノードをデスティネイションＩＤとするリード要求パケットと、第１ノードをデスティネイションＩＤとするリード要求パケットとが、第２ノードから送出され、（３）第１ノードをデスティネイションＩＤとするリード要求パケットと、第２ノードをデスティネイションＩＤとするリード要求パケットとが、第３ノードから送出される。つまり、合計６個のリード要求パケットが送出される。
【０００９】
ＩＥＥＥ１３９４の上位プロトコル（例：ＡＶ／Ｃ（Audio-Video/Control）、ＳＢＰ（Serial Bus Protocol）−２、ＤＰＰ（Direct print protocol））を使用して、バスリセット前に特定の２ノード間でデータのやり取りを行っていた場合、バスリセット後にはノードIDが変化する可能性があるので、バスリセット後に各ノードのＥＵＩ−６４値をリードして、バスリセット前にやり取りを行っていた相手ノードを探すことになっている。この場合も、やり取りしていた相手ノードのＥＵＩ−６４値を記憶しておいて、かかるＥＵＩ−６４値と同一のＥＵＩ−６４値を有するノードが見つかるまでＥＵＩ−６４値をリード対象とするリードトランザクションを繰り返す。該当するＥＵＩ−６４値を有するノードを見つけたら、バスリセットによって中断されたトランザクションの続きを再開することができる。
【００１０】
バス上に６３ノード存在していて、各ノードがバスリセット後に、ノードIDを“０”から“全てのノード数−１”に変化させながら、ＥＵＩ−６４の格納されているアドレスを指定したリードトランザクションを全てのノードについて行うとすると、６２×６３回のリードトランザクションが行われることになる。
【００１１】
このようにバスリセット後は、ＥＵＩ−６４のリードトランザクションによりバスが混雑する可能性が高い。また、多数のノードからリードトランザクションを受けるとハングアップする可能性があるノードが存在する場合、バスリセット後のＥＵＩ−６４リードトランザクションの際にハングアップが発生する可能性が高い。
【００１２】
次に、第２の問題点について説明する。前記の如く、従来のリンク層は自己ノードIDとバス上のパケットのヘッダに含まれるデスティネイションIDとを比較して、両ＩＤが一致するパケットのみをTransaction層に通知する、つまり受信する。このため、例えば任意のノードａが特定のノードｂの状態を知りたい場合、ノードａ発ノードｂ宛てリード要求パケットがノードｂに到達し、かつノードｂ発ノードａ宛てリード応答パケットがノードａに到達しなければならない。ノードａ以外のノード（例えば、ノードｃ）がノードｂにリード要求パケットを送り、ノードｂからノードｃ宛てリード応答パケットがバスに送出されたとしても、ノードａのリンク層はノードｃ宛てリード応答パケットを上位層へ通知しない。ノードａが必要とする情報を有するリード応答パケットがノードａのリンク層に届いても、かかるリード応答パケットがノードａ宛ではないという理由によって、ノードａの上位層へは通知されない。
【００１３】
この結果、例えばあるノードｂに対して上位アプリケーションで接続状態を確立できるノード数が決まっており、かつ接続状態を確立できる最大数のノードが既にノードｂにログインしているために、ノードａがノードｂにログインできない場合、ノードｂと既に接続状態を確立しているノードのいずれかがその接続状態を解消するまで、ノードａはノードｂの状態を確認するためにリードトランザクションを繰り返さなければならない。
【００１４】
【課題を解決するための手段】
本発明の第１の特徴は、パケットを送受信し、所定のパケットに関する情報を上位層へ通知する通信方法であって、（ａ）第１パケットが第１条件を満たすかを調べて、前記第１パケットの情報を記憶するか否かを判断し、（ｂ）記憶すると判断した場合に前記第１パケットから第２条件として使用する情報を抽出し、（ｃ）第２パケットが前記第２条件を満たすかを調べて、前記第２パケットの情報を上位層に通知するか否かを判断し、（ｄ）通知すると判断した場合に前記第２パケットの情報を上位層に通知することにある。
【００１５】
かかる第１の特徴により、第１条件を満たす第１パケットから抽出された情報を、第２パケットを上位層へ通知するか否かを判断するための第２条件の一部または全部として使用することが可能となる。
【００１６】
【発明の実施の形態】
以下、図面に基づいて本発明の実施形態について説明する。なお、重複記載を避けるために、同一または類似の構成要素には、同一または類似の参照番号を付して説明を省略する。
【００１７】
図１に示すように、後述する実施形態において送受信されるリード要求パケットは、デスティネイション(destination)ＩＤ、トランザクションラベル(tlabel)、リトライコード(rt)、トランザクションコード(tcode)、プライオリティ(pri)、ソース(source)ＩＤ、デスティネイション・オフセット(destination offset)およびヘッダ(header)CRCの各フィールドを有する。
【００１８】
図２に示すように、後述する実施形態において送受信されるリード応答パケットは、デスティネイションＩＤ、トランザクションラベル、リトライコード、トランザクションコード、プライオリティ、ソースＩＤ、レスポンスコード(rcode)、予約(reserved)、クアドレット(quadlet data)およびヘッダCRCの各フィールドを有する。
【００１９】
図３に示すように、後述する実施形態におけるプロトコル層は、物理層、リンク層、トランザクション層、シリアルバス管理層および上位プロトコル層から成る。上位プロトコルには、ＡＶ／Ｃ(Audio Video Control)、ＳＢＰ (Serial Bus Protocol) −２、ＤＰＰ(Direct Print Protocol)が含まれる。
【００２０】
図４に示すように、後述する実施形態において、バスリセットが発生すると（Ｓ１）、ツリー構造の識別（Ｓ３）、自己識別（Ｓ５）およびＥＵＩ−６４リード（Ｓ７）が行われる。バスリセットは、ケーブルの挿抜などによって発生する。ツリー構造の識別によって、全ノードの各ポートが親ポートまたは子ポートとして特定される。ツリー構造の識別プロセスが完結すると、自己識別プロセスが始まる。自己識別中、各ノードから自己ＩＤパケットが送信され、ノードＩＤとバス上のノード数が確定する。そして、ノードの機器を特定するＥＵＩ−６４（拡張固有識別子）をリードすることで、ノードＩＤと機器の関連付けをする。ＥＵＩ−６４は、ノードベンダーＩＤ(node_vendor_ID)、チップＩＤハイ(chip_id_hi)およびチップＩＤロー(chip_id_lo)を連結することで生成される６４ビットの値である。
【００２１】
図５に示すように、自己識別後、各ノードにＩＤ番号が割り当てられる。図５は、ＩＤ＝１０のノードの子ポートとＩＤ＝５、６および９のノードの親ポートとが接続され、ＩＤ＝５のノードの子ポートとＩＤ＝３および４のノードの親ポートが接続され、ＩＤ＝３のノードの子ポートとＩＤ＝１および２のノードの親ポートが接続され、ＩＤ＝１のノードの子ポートとＩＤ＝０のノードの親ポートが接続され、ＩＤ＝９のノードの子ポートとＩＤ＝８のノードの親ポートが接続され、ＩＤ＝８のノードの子ポートとＩＤ＝７のノードの親ポートが接続されている例を示す。
【００２２】
図６に示すように、１０２４個まであるバスの一つ一つに６４個のノードで構成されるグループを割り当てる。各ノードは、２５６Ｔバイトのアドレス空間を持つ。各アドレス空間は、初期メモリ空間、プライベート空間および初期レジスタ空間に分割される。初期レジスタ空間は、ＣＳＲ（Control and Status Register）アーキテクチャ空間、シリアルバス空間、コンフィギュレーションＲＯＭ空間および初期ユニット空間に分割される。コンフィギュレーションＲＯＭ空間内に、ＥＵＩ−６４が記憶される。
【００２３】
図７に示すように、ＩＤ＝５のノードからＩＤ＝０のノードへリード要求パケットが送出されると、ＩＤ＝０のノードからＩＤ＝５のノードへリード応答パケットが送出される。同様に、ＩＤ＝６のノードからＩＤ＝０のノードへリード要求パケットが送出されると、ＩＤ＝０のノードからＩＤ＝６のノードへリード応答パケットが送出される。また、ＩＤ＝９のノードからＩＤ＝０のノードへリード要求パケットが送出されると、ＩＤ＝０のノードからＩＤ＝９のノードへリード応答パケットが送出される。さらに、ＩＤ＝３のノードからＩＤ＝０のノードへリード要求パケットが送出されると、ＩＤ＝０のノードからＩＤ＝３のノードへリード応答パケットが送出される。そして、ＩＤ＝０のノードから送出される上記４つのリード応答パケットに含まれるＥＵＩ−６４のデータは同一である。後述する実施形態においては、このような同一データを含む複数パケットの送出を不要にすることが可能になる。
【００２４】
図８に示すように、後述する実施形態において送受信されるライト要求パケットは、デスティネイションＩＤ、トランザクションラベル、リトライコード、トランザクションコード、プライオリティ、ソースＩＤ、デスティネイション・オフセット、クアドレットデータおよびヘッダCRCの各フィールドを有する。
【００２５】
＜第１の実施形態＞
第１の実施形態では、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、各ノードのノードＩＤとＥＵＩ−６４の対応関係を上位層へ通知することを可能とする。
【００２６】
図９は本発明の第１の実施形態におけるパケット送受信装置の構成を示すブロック図であり、図１０は本発明の第１の実施形態における処理の流れを示すフローチャートであり、図１１はノードＩＤとＥＵＩ−６４とをレジスタに格納した状態を示す図である。
【００２７】
図９に示すように、リンク層は、ＰＨＹ（物理層）インタフェース１１０、抽出部１２０、一致判定部１３０、制御部１４０、記憶部１５０、受信ＦＩＦＯ１７０、ホストインタフェース１８０、送信ＦＩＦＯ１９０を含む。
【００２８】
抽出部１２０は、バス上のパケットからデスティネイションＩＤ、デスティネイション・オフセット（送出先オフセット）、トランザクションコード、ソースＩＤ、トランザクションラベルを抽出する。これら用語の内容は、ＩＥＥＥ１３９４で定義されている。
【００２９】
記憶部１５０は、自己ノードＩＤ、ＥＵＩ−６４のアドレス、リード要求コード、リード応答コード、デスティネイションＩＤ、デスティネイション・オフセット、ソースＩＤ、トランザクションラベル等を記憶する。記憶部１５０としては、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）などが使用可能である。デスティネイションＩＤ、デスティネイション・オフセット等を物理的に１つのメモリに記憶させても良く、また物理的に分離した２以上のメモリに記憶させても良い。
【００３０】
一致判定部１３０は、例えばバス上のパケットから抽出されたデスティネイションＩＤと記憶部１５０に記憶されている自己ノードＩＤとを比較し、両ＩＤが一致したかどうかを示す信号を出力する。
【００３１】
制御部１４０は、抽出部１２０にバス上のパケットから何を抽出させるか、記憶部１５０に何を記憶させるか、一致判定部１３０に何と何を比較させるかを制御する。制御部１４０が抽出部１２０等をどのように制御するかの具体的内容は図１０のフローチャートに基づいて以下に説明する。
【００３２】
自己ノードＩＤ、ＥＵＩ−６４アドレス、リード要求トランザクションコードおよびリード応答トランザクションコードは、記憶部１５０に予め記憶されている。
【００３３】
図１０に示すように、まずflag=0を設定する（ステップＳ１０１）。具体的には、記憶部のflagレジスタに０を書き込む。そして、バス上にパケットが存在するかを調べる（ステップＳ１０３）。
【００３４】
ステップＳ１０３の結果がＹＥＳであるなら、パケットのデスティネイションＩＤが自己ノードＩＤと一致するかを調べる（ステップＳ１０５）。具体的には制御部１４０が、抽出部１２０にバス上のパケットからデスティネイションＩＤを抽出させ、一致判定部１３０に抽出されたデスティネイションＩＤと記憶されている自己ノードＩＤとを比較させる。
【００３５】
ステップＳ１０５の結果がＹＥＳであるなら、パケット内の情報をTransaction層に通知する（ステップＳ１０７）。つまり、受信ＦＩＦＯ１７０に受信イネーブル（Enable）信号を送る。
【００３６】
ステップＳ１０５の結果がＮＯであるなら、バス上のパケットのデスティネイション・オフセットがＥＵＩ−６４のアドレスであり、かつバス上のパケットのトランザクションコードがリード要求か（第１条件）を調べる（ステップＳ１０９）。具体的には、制御部１４０が、抽出部１２０にバス上のパケットからデスティネイション・オフセットとトランザクションコードを抽出させ、一致判定部１３０に（１）抽出されたデスティネイション・オフセットと記憶されているＥＵＩ−６４のアドレスとを比較させ、（２）抽出されたトランザクションコードと記憶されているリード要求コードとを比較させる。
【００３７】
ステップＳ１０９の結果がＹＥＳであるなら、バス上のパケット（第１パケット）のデスティネイションＩＤ、ソースＩＤ、トランザクションラベルを記憶し、かつflagに１を設定する（ステップＳ１１１）。具体的には、制御部１４０が、抽出部１４０にバス上のパケット（第１パケット）からデスティネイションＩＤ 、ソースＩＤ、トランザクションラベルを抽出させ、記憶部１５０のflagレジスタに１を、デスティネイションＩＤレジスタに抽出されたデスティネイションＩＤを、sourceレジスタに抽出されたソースＩＤを、トランザクションラベルレジスタに抽出されたトランザクションラベルを書き込む。そして、ステップＳ１０３に戻り、ステップＳ１０５、Ｓ１０９が繰り返される。
【００３８】
ステップＳ１０９の結果がＮＯであるなら、（１）flag＝１であり、かつ（２）バス上のパケットが、ステップＳ１１１で記憶されたリード要求パケットに対するリード応答パケットか（第２条件）を調べる（ステップＳ１１３）。
【００３９】
具体的には、
記憶部１５０のflagレジスタに１が書き込まれているかを調べ、
抽出部１２０に、バス上のパケット（第２パケット）からデスティネイションＩＤ、ソースＩＤ、トランザクションラベル、トランザクションコードを抽出させ、
一致判定部１３０に、（１）バス上の第２パケットのデスティネイションＩＤとステップＳ１１１で記憶された第１パケットのソースＩＤとを比較させ、（２）バス上の第２パケットのソースＩＤとステップＳ１１１で記憶された第１パケットのデスティネイションＩＤとを比較させ、（３）バス上の第２パケットのトランザクションラベルとステップＳ１１１で記憶された第１パケットのトランザクションラベルとを比較させ、（４）バス上の第２パケットのトランザクションコードと予め記憶されているリード応答コードとを比較させる。
【００４０】
ステップＳ１１３の結果がＮＯであるなら、バス上のパケットを無視する（ステップＳ１１５）。
【００４１】
ステップＳ１１３の結果がＹＥＳであるなら、バス上の第２パケット内の情報を上位層に通知し、flagの値を０に戻す（ステップＳ１１７）。具体的には、受信ＦＩＦＯ１７０に受信Enable信号を送り、記憶部１５０にflag=０を書き込む。
【００４２】
ステップＳ１１７後に、バス上のリード応答パケット内のソースＩＤ（図１１に示すノードＩＤ）とＥＵＩ―６４の値が図１１に示すように関連付けられて記憶部１５０のノードＩＤ／ＥＵＩ−６４対応表レジスタに記憶される。かかる処理を繰り返すことによって、バス上の全ノードのノードＩＤとＥＵＩ−６４の値との対応表を作成することができる。
【００４３】
上記の如く、第１の実施形態では、他ノード宛てリード応答パケットであっても、デスティネイション・オフセットがＥＵＩ―６４のアドレスであるリード要求パケットに対するリード応答パケットについては上位層へ通知する。その結果、各ノードが他のノードの情報を取得するためにバス上で送受信されなければならないパケット数が減少する。
【００４４】
例えば、第１のノードａと、第２のノードｂと、第３のノードｃとがバスを介してパケットを送受信することによって、各ノードが他のノードに関する情報を取得する場合を考える。従来はバスリセット後に下記の１２個のパケットがバスに送出されていた。
【００４５】
（１）ノードａからノードｂへのリード要求パケット、
（２）ノードｂからノードａへのリード応答パケット、
（３）ノードａからノードｃへのリード要求パケット、
（４）ノードｃからノードａへのリード応答パケット、
（５）ノードｂからノードｃへのリード要求パケット、
（６）ノードｃからノードｂへのリード応答パケット、
（７）ノードｂからノードａへのリード要求パケット、
（８）ノードａからノードｂへのリード応答パケット、
（９）ノードｃからノードａへのリード要求パケット、
（10）ノードａからノードｃへのリード応答パケット、
（11）ノードｃからノードｂへのリード要求パケット、
（12）ノードｂからノードｃへのリード応答パケット。
【００４６】
しかし、第１の実施形態によれば、バスリセット後に下記の６個のパケットがバスに送出されるだけで良い。
【００４７】
（１）ノードａからノードｂへのリード要求パケット、
（２）ノードｂからノードａへのリード応答パケット、
（３）ノードａからノードｃへのリード要求パケット、
（４）ノードｃからノードａへのリード応答パケット、
（５）ノードｂからノードａへのリード要求パケット、
（６）ノードａからノードｂへのリード応答パケット。
【００４８】
なぜなら、ノードｂからノードａへのリード応答パケットは、ノードｂに関する情報を、ノードａに通知するのみならず、ノードｃにも通知するからである。また、ノードｃからノードａへのリード応答パケットは、ノードｃに関する情報を、ノードａに通知するのみならず、ノードｂにも通知するからである。さらに、ノードａからノードｂへのリード応答パケットは、ノードａに関する情報を、ノードｂに通知するのみならず、ノードｃにも通知するからである。
【００４９】
上記の如く、第１の実施形態によれば、バスリセット後に各ノードが他の全てのノードに関する情報を取得するためにバスに送出されるパケット総数が減少するので、バスの混雑を緩和することができる。そして、パケット総数が減少すれば、各ノードが他のノードに関する情報を取得するまでに必要とする時間が短縮される。その結果、実際のデータを転送する状態に早く移ることができる。実際のデータとは、各ノード間の接続関係等を把握するために送受信されるデータではなく、各ノード間の接続関係等が把握された後に送受信されるデータを言い、映像データや音声データなどが含まれる。また、複数のノードからリードトランザクションを受けるとハングアップしてしまうような機器に関しては、リードトランザクションが減少する結果、ハングアップの確率が減る。
【００５０】
＜第２の実施形態＞
第２の実施形態では、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、バスリセット前にパケットを送受信していたノードのノードＩＤを上位層へ通知することを可能とする。具体的には、バスリセットの前後で変化しないＥＵＩ−６４の値に基づいて、バスリセット前にパケットを送受信していたノードのバスリセット後のノードＩＤを上位層へ通知する。
【００５１】
図１２は本発明の第２の実施形態におけるパケット送受信装置の構成を示すブロック図であり、図１３は本発明の第２の実施形態における処理の流れを示すフローチャートである。
【００５２】
自己ノードＩＤ、ＥＵＩ−６４アドレス、リード要求トランザクションコードおよびリード応答トランザクションコードは、記憶部に予め記憶されている。
【００５３】
図１３に示すように、第２の実施形態では、まずＥＵＩ−６４レジスタに値を設定する（ステップＳ２０１）。具体的には、バスリセット直前に受け取ったパケットを送出したノードのＥＵＩ−６４の値を記憶部２５０のＥＵＩ−６４レジスタに記憶する。前記の如く、バスリセットの前後で、各ノードのノードＩＤは変化しうるが、ＥＵＩ−６４の値は変化しない。
【００５４】
次に、flagに０を設定し（ステップＳ２０３）、バス上にパケットが存在するかを調べ（ステップＳ２０５）、パケットが存在する場合はそのパケットのデスティネイションＩＤが自己ノードIDと一致するかを調べる（ステップＳ２０７）。
【００５５】
ステップＳ２０７の結果がＹＥＳであるなら、パケット内の情報をTransaction層に通知する（ステップＳ２０９）。
【００５６】
ステップＳ２０７の結果がＮＯであるなら、バス上のパケットのデスティネイション・オフセットがＥＵＩ−６４のアドレスであり、かつバス上のパケットのトランザクションコードがリード要求であるか（第１条件）を調べる（ステップＳ２１１）。
【００５７】
ステップＳ２１１の結果がＹＥＳであるなら、バス上のパケット（第１パケット）のデスティネイションＩＤ、ソースＩＤ、トランザクションラベルを記憶し、かつflagに１を設定する（ステップＳ２１３）。そして、ステップＳ２０５に戻り、ステップＳ２０７、Ｓ２１１が繰り返される。
【００５８】
ステップＳ２１１の結果がＮＯであるなら、（１）flag＝１であり、かつ（２）バス上のパケット（第２パケット）が、記憶されたリード要求パケットに対するリード応答パケットであり、かつ（３）バス上のパケット（第２パケット）のＥＵＩ―６４の値がＥＵＩ―６４レジスタに設定された値と一致するか（第２条件）を調べる（ステップＳ２１５）。
【００５９】
具体的には、
記憶部２５０のflagレジスタに１が書き込まれているかを調べ、
抽出部１２０に、バス上のパケット（第２パケット）からデスティネイションＩＤ、ソースＩＤ、トランザクションラベル、トランザクションコードを抽出させ、
一致判定部１３０に、（１）バス上の第２パケットから抽出されたデスティネイションＩＤとステップＳ２１３で記憶された第１パケットのソースＩＤとを比較させ、（２）バス上の第２パケットから抽出されたソースＩＤとステップＳ２１３で記憶された第１パケットのデスティネイションＩＤとを比較させ、（３）バス上の第２パケットから抽出されたトランザクションラベルとステップＳ２１３で記憶された第１パケットのトランザクションラベルとを比較させ、（４）バス上の第２パケットから抽出されたトランザクションコードと予め記憶されているリード応答コードとを比較させ、（５）バス上の第２パケットのＥＵＩ―６４の値とステップＳ２０１でＥＵＩ―６４レジスタに設定された値とを比較させる。
【００６０】
ステップＳ２１５の結果がＮＯであるなら、バス上のパケットを無視する（ステップＳ２１７）。
【００６１】
ステップＳ２１５の結果がＹＥＳであるなら、バス上のパケットのソースＩＤを上位層に通知し、flagを０に戻す（ステップＳ２１９）。
【００６２】
第２の実施形態によれば、他ノード宛てリード応答パケットを格納することによって、バスリセット直前にパケットをやり取りしていた相手方ノードを見つけ出すことができる。
【００６３】
例えば、第１のノードａと、第２のノードｂと、第３のノードｃとが存在し、かつバスリセット直前にノードａとノードｂとがパケットをやり取りしていたとする。そして、バスリセットによってノードＩＤが変化し、ノードａがノードｘとなり、ノードｂがノードｙとなり、ノードｃがノードｚとなったとする。バスリセットによって中断されたパケットのやり取りを再開するためには、ノードｘはバスリセット前のノードｂがバスリセット後にノードｙとなったたことを認識する必要がある。
【００６４】
バスリセットによって各ノードのノードＩＤは変化しうるが、ＥＵＩ−６４の値は変化しないので、ノードｘはノードｂのＥＵＩ―６４の値とノードｙのＥＵＩ―６４の値とを比較することによって、ノードｙがバスリセット前のノードｂであることを認識しうる。
【００６５】
従来はノードｘがノードｙのＥＵＩ―６４の値を知るためには、デスティネイション・オフセットがＥＵＩ―６４アドレスであるノードｙ宛てリード要求パケットをノードｘがバスに送出し、このリード要求パケットに対してノードｙがノードｘ宛てリード応答パケットをバスに送出する必要があった。
【００６６】
しかし、第２の実施形態によれば、ノードｘは、（１）ノードｚからバスに送出されたノードｙ宛てリード要求パケットのデスティネイション・オフセットがＥＵＩ―６４のアドレスであること、および（２）このリード要求パケットに対してノードｙからバスに送出されたノードｚ宛てリード応答パケットのクアドレットデータとバスリセット前に記憶しておいたノードｂのＥＵＩ―６４の値とが一致することを確認することによって、ノードｙがバスリセット前のノードｂであることを認識しうる。
【００６７】
上記の如く、第２の実施形態によれば、（１）デスティネイション・オフセットがＥＵＩ―６４のアドレスであることをリード要求パケットの受信条件とし、（２−１）このリード要求パケットに対するリード応答パケットであること、および（２−２）かかるリード応答パケットのクアドレットデータが特定の値（ＥＵＩ―６４レジスタに設定されている値と等しい値）であることをリード応答パケットの受信条件とすることによって、他ノード宛てリード応答パケットからバスリセット直前にパケットを送受信していたノードのノードＩＤを知ることができる。また、複数のノードからリードトランザクションを受けるとハングアップしてしまうような機器に関しては、リードトランザクションが減少する結果、ハングアップの確率が減る。
【００６８】
＜第３の実施形態＞
第３の実施形態では、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、特定の上位プロトコルをサポートするノードのノードＩＤを上位層へ通知することを可能とする。
【００６９】
図１４は本発明の第３の実施形態におけるパケット送受信装置の構成を示すブロック図であり、図１５は本発明の第３の実施形態における処理の流れを示すフローチャートであり、図１６は本発明の第３の実施形態におけるコンフィギュレーションROMの構成を示す図である。
【００７０】
自己ノードＩＤ、コンフィギュレーションROMアドレス、リード要求トランザクションコードおよびリード応答トランザクションコードは、記憶部３５０に予め記憶されている。
【００７１】
図１５に示すように、第３の実施形態では、まず上位プロトコルレジスタに値を設定する（ステップＳ３０１）。具体的には、キー・タイプ、キー・ヴァリュウ、使用したい上位プロトコルをプロトコルレジスタに設定する。かかるレジスタの設定内容が同じプロトコルをサポートするノードを探し出すために使用される。キー・タイプはエントリー・ヴァリュウ(entry_value)の特性を定義し、キー・ヴァリュウは各ＲＯＭディレクトリ項目の内容と名前を特定する。コンフィギュレーションROMの構成例を図１６に示す。例えば”0x12”を２進数で表した”00010010”の上位２ビット”00”がキー・タイプを、下位６ビット”010010”がキー・ヴァリュウを表す。
次に、flagに０を設定し（ステップＳ３０３）、バス上にパケットが存在するかを調べ（ステップＳ３０５）、バス上にパケットが存在する場合はそのパケットのデスティネイションＩＤが自己ノードIDと一致するかを調べる（ステップＳ３０７）。
【００７２】
ステップＳ３０７の結果がＹＥＳであるなら、パケット内の情報をTransaction層に通知する（ステップＳ３０９）。
【００７３】
ステップＳ３０７の結果がＮＯであるなら、バス上のパケットのデスティネイション・オフセットがコンフィギュレーション ROMのアドレスであり、かつトランザクションコードがリード要求か（第１条件）を調べる（ステップＳ３１１）。
【００７４】
ステップＳ３１１の結果がＹＥＳであるなら、バス上のパケット（第１パケット）のデスティネイションＩＤ、ソースＩＤ、トランザクションラベルを記憶し、かつflagに１を設定する（ステップＳ３１３）。そして、ステップＳ３０５に戻り、ステップＳ３０７、Ｓ３１１が繰り返される。
【００７５】
ステップＳ３１１の結果がＮＯであるなら、（１）flag＝１であり、かつ（２）バス上のパケット（第２パケット）がステップＳ３１３で記憶されたリード要求パケットに対するリード応答パケットであり、かつ（３）バス上のパケット（第２パケット）のデータがステップＳ３０１で上位プロトコルレジスタに設定された値と一致するか（第２条件）を調べる（ステップＳ３１５）。
【００７６】
具体的には、
記憶部３５０のflagレジスタに１が書き込まれているかを調べ、
抽出部１２０に、バス上のパケット（第２パケット）からデスティネイションＩＤ、ソースＩＤ、トランザクションラベル、トランザクションコード、データを抽出させ、
一致判定部１３０に、（１）バス上の第２パケットから抽出されたデスティネイションＩＤとステップＳ３１３で記憶された第１パケットのソースＩＤとを比較させ、（２）バス上の第２パケットから抽出されたソースＩＤとステップＳ３１３で記憶された第１パケットのデスティネイションＩＤとを比較させ、（３）バス上の第２パケットから抽出されたトランザクションラベルとステップＳ３１３で記憶された第１パケットのトランザクションラベルとを比較させ、（４）バス上の第２パケットから抽出されたトランザクションコードと予め記憶されているリード応答コードとを比較させ、（５）バス上の第２パケットのデータとステップＳ３０１で設定された上位プロトコルレジスタの値とを比較させる。
【００７７】
ステップＳ３１５の結果がＮＯであるなら、バス上のパケットを無視する（ステップＳ３１７）。
【００７８】
ステップＳ３１５の結果がＹＥＳであるなら、バス上のパケットのソースＩＤを上位層に通知し、flagを０に戻す（ステップＳ３１９）。
【００７９】
図１６に示すように、コンフィギュレーションＲＯＭには、ＥＵＩ−６４以外にも機器の性能を示す情報が格納されている。上位プロトコル（ＡＶ／Ｃ、ＳＢＰ−２、ＤＰＰ等）のサポート状態などもそういった情報の１つである。
【００８０】
上記の如く、第３の実施形態によれば、（１）デスティネイション・オフセットがコンフィギュレーション ＲＯＭのアドレスであることをリード要求パケットの受信条件とし、（２−１）このリード要求パケットに対するリード応答パケットであること、および（２−２）クアドレットデータに含まれるキー・タイプとキー・ヴァリュウが特定の値であることをリード応答パケットの受信条件とすることによって、他ノード宛てリード応答パケットであっても、特定の上位プロトコルをサポートするノードのノードIDをソースＩＤとするリード応答パケットについては上位層へ通知することができる。
【００８１】
＜第４の実施形態＞
第４の実施形態では、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、特定のノードの状態を上位層へ通知することを可能とする。ノードの状態とは、所定の処理を実施中であるとか、所定の処理を終了したという状態を言い、例えばプリント処理が終了したという状態が含まれる。
【００８２】
図１７は本発明の第４の実施形態におけるパケット送受信装置の構成を示すブロック図であり、図１８は本発明の第４の実施形態における処理の流れを示すフローチャートである。
【００８３】
自己ノードＩＤ、リード要求トランザクションコードおよびリード応答トランザクションコードは、記憶部４５０に予め記憶されている。
【００８４】
図１８に示すように、第４の実施形態では、まずデスティネイションＩＤとデスティネイション・オフセットを設定する（ステップＳ４０１）。具体的には、状態を知りたいノードのノードＩＤを記憶部４５０のデスティネイションＩＤレジスタに記憶させ、状態を知りたいノードの状態レジスタのアドレスを記憶部４５０のデスティネイション・オフセットレジスタに記憶させる。
【００８５】
次に、flagに０を設定し（ステップＳ４０３）、バス上にパケットが存在するかを調べ（ステップＳ４０５）、パケットが存在する場合はそのパケットのデスティネイションＩＤが自分のノードIDと一致するかを調べる（ステップＳ４０７）。
【００８６】
ステップＳ４０７の結果がＹＥＳであるなら、パケット内の情報をTransaction層に通知する（ステップＳ４０９）。
【００８７】
ステップＳ４０７の結果がＮＯであるなら、（１）バス上のパケットのデスティネイションＩＤ とデスティネイション・オフセットとがステップＳ４０１でレジスタに記憶されたデスティネイションＩＤ とデスティネイション・オフセットとにそれぞれ一致し、かつ（２）バス上のパケットのトランザクションコードがリード要求であるか（第１条件）を調べる（ステップＳ４１１）。
【００８８】
ステップＳ４１１の結果がＹＥＳであるなら、バス上のパケット（第１パケット）のデスティネイションＩＤ、ソースＩＤ、トランザクションラベルを記憶し、かつflagに１を設定する（ステップＳ４１３）。そして、ステップＳ４０５に戻り、ステップＳ４０７、Ｓ４１１が繰り返される。
【００８９】
ステップＳ４１１の結果がＮＯであるなら、（１）flag＝１であり、かつ（２）バス上のパケットがステップＳ４１３で記憶されたリード要求パケットに対するリード応答パケットであるか（第２条件）を調べる（ステップＳ４１５）。
【００９０】
具体的には、
記憶部４５０のflagレジスタに１が書き込まれているかを調べ、
抽出部１２０に、バス上のパケット（第２パケット）からデスティネイションＩＤ、ソースＩＤ、トランザクションラベル、トランザクションコードを抽出させ、
一致判定部１３０に、（１）バス上の第２パケットから抽出されたデスティネイションＩＤとステップＳ４１３で記憶された第１パケットのソースＩＤとを比較させ、（２）バス上の第２パケットから抽出されたソースＩＤとステップＳ４１３で記憶された第１パケットのデスティネイションＩＤとを比較させ、（３）バス上の第２パケットから抽出されたトランザクションラベルとステップＳ４１３で記憶された第１パケットのトランザクションラベルとを比較させ、（４）バス上の第２パケットから抽出されたトランザクションコードと予め記憶されているリード応答コードとを比較させる。
【００９１】
ステップＳ４１５の結果がＮＯであるなら、バス上のパケットを無視する（ステップＳ４１７）。
【００９２】
ステップＳ４１５の結果がＹＥＳであるなら、バス上の第２パケットの状態の情報を上位層に通知し、flagを０に戻す（ステップＳ４１９）。
【００９３】
上記の如く、第４の実施形態によれば、（１）デスティネイションＩＤが特定のノードを示すこと、およびデスティネイション・オフセットが状態レジスタのアドレスであることとをリード要求パケットの受信条件とし、（２）このパケットに対する返答であることをリード応答パケットの受信条件とすることによって、他ノード宛てリード応答パケットであっても、特定のノードIDの状態レジスタから読み出されたクアドレットデータを包含しているリード応答パケットについては上位層へ通知することができる。
【００９４】
＜第５の実施形態＞
第５の実施形態も、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、特定のノードの状態を上位層へ通知することを可能とする。上記第１から第４の実施形態では他ノード宛てリード応答パケットから必要な情報を取得する。しかし、第５の実施形態では、他ノード宛てライト要求パケットまたはロック要求パケットから必要な情報を取得する。
【００９５】
図１９は本発明の第５の実施形態におけるリンク層の構成を示すブロック図であり、図２０は本発明の第５の実施形態における処理の流れを示すフローチャートである。
【００９６】
第５の実施形態は、あるノード（例えば、ノードｂ）に対して上位アプリケーションで接続状態を確立できるノード数が決まっていて、接続状態を確立できるノード数の最大数のノードが既にログインされているので、ログインできていない他のノード（例えば、ノードａ）が空きを待っている状態に関する。
【００９７】
自己ノードＩＤおよびライト要求トランザクションコードは、記憶部５５０に予め記憶されている。状態を知りたいノードには、同時に接続可能な最大数のノードが既に接続をしているものとする。
【００９８】
図２０に示すように、第５の実施形態では、まずデスティネイションＩＤとデスティネイション・オフセットを設定する（ステップＳ５０１）。具体的には、状態を知りたいノードのＩＤをデスティネイションＩＤレジスタに、状態を知りたいノードのログイン／ログアウトレジスタのアドレスをデスティネイション・オフセットレジスタに記憶させる。
【００９９】
次に、バス上にパケットが存在するかを調べ（ステップＳ５０３）、パケットが存在する場合はそのパケットのデスティネイションＩＤが自己ノードIDと一致するかを調べる（ステップＳ５０５）。
【０１００】
ステップＳ５０５の結果がＹＥＳであるなら、パケット内の情報をTransaction層に通知する（ステップＳ５０７）。
【０１０１】
ステップＳ５０５の結果がＮＯであるなら、バス上のパケットのデスティネイションＩＤ とデスティネイション・オフセットとがステップＳ５０１でレジスタに記憶されたデスティネイションＩＤ とデスティネイション・オフセットとにそれぞれ一致し、かつバス上のパケットがライト要求パケットかを調べる（ステップＳ５０９）。
【０１０２】
ステップＳ５０９の結果がＮＯであるなら、バス上のパケットを無視する（ステップＳ５１１）。
【０１０３】
ステップＳ５０９の結果がＹＥＳであるなら、状態の情報を上位層に通知する（ステップＳ５１３）。ここで「状態の情報」とは、ライト要求パケットによって書き込まれるデータのことである。ただし、書き込まれるデータの単位が１クアドレット(32bit)であって、１クアドレット以上のデータが書き込まれる場合、１つのライト要求パケットによって書き込まれるデータは、全データの一部となる。
【０１０４】
上記の如く、第５の実施形態によれば、デスティネイションＩＤが特定のノードを示すこと、およびデスティネイション・オフセットが特定のアドレスを指定することをライト要求パケットの受信条件とすることによって、他ノード宛てライト要求パケットであっても、特定ノードの特定アドレスに対するライト要求パケットについては当パケット内のクアドレットデータを上位層へ通知することができる。これによって、ある特定のノードｂに対して上位アプリケーションで接続状態を確立できるノード数が決まっていて、かつ接続状態を確立できるノード数だけ既にログインされているので、ノードａはノードｂにログインしているノードのいずれかがログアウトするのを待っている状態であっても、ノードａはノードｂの特定のアドレスの値を知ることができる。
【０１０５】
＜第５の実施形態の変形例＞
図２１は本発明の第５の実施形態の変形例におけるパケット送受信装置の構成を示すブロック図であり、図２２は本発明の第５の実施形態の変形例における処理の流れを示すフローチャートである。
【０１０６】
図２２に示すステップＳ５２１、Ｓ５２５、Ｓ５２７、Ｓ５２９はそれぞれ、図２０に示すステップＳ５０１、Ｓ５０３、Ｓ５０５、Ｓ５０７と同じであるから、説明を省略する。また、図２２に示すステップＳ５２３では、flagに０を設定する。
【０１０７】
ステップＳ５２７の結果がＮＯであるなら、バス上のパケットのデスティネイションＩＤ とデスティネイション・オフセットとがステップＳ５２１でレジスタに記憶されたデスティネイションＩＤ とデスティネイション・オフセットとにそれぞれ一致し、かつバス上のパケットのトランザクションコードを抽出し、そのトランザクションコードが記憶部に記憶されているロック要求トランザクションコードと一致するか（第１条件）を調べる（ステップＳ５３１）。
【０１０８】
ステップＳ５３１の結果がＹＥＳであるなら、バス上のパケット（第１パケット）のデスティネイションＩＤ、ソースＩＤ、トランザクションラベルを記憶し、かつflagに１を設定する（ステップＳ５３３）そして、ステップＳ５２５に戻り、ステップＳ５２７、Ｓ５３１が繰り返される。
【０１０９】
ステップＳ５３１の結果がＮＯであるなら、（１）flag＝１であり、かつ（２）バス上のパケット（第２パケット）がステップＳ５３３で記憶されたロック要求パケットに対するロック応答パケットであるか（第２条件）を調べる（ステップＳ５３５）。
【０１１０】
具体的には、
記憶部６５０のflagレジスタに１が書き込まれているかを調べ、
抽出部１２０に、バス上のパケット（第２パケット）からデスティネイションＩＤ、ソースＩＤ、トランザクションラベル、トランザクションコードを抽出させ、
一致判定部１３０に、（１）バス上の第２パケットから抽出されたデスティネイションＩＤとステップＳ５３３で記憶された第１パケットのソースＩＤとを比較させ 、（２）バス上の第２パケットから抽出されたソースＩＤとステップＳ５３３で記憶された第１パケットのデスティネイションＩＤとを比較させ、（３）バス上の第２パケットから抽出されたトランザクションラベルとステップＳ５３３で記憶された第１パケットのトランザクションラベルとを比較させ、（４）バス上の第２パケットから抽出されたトランザクションコードと予め記憶されているロック応答コードとを比較させる。
【０１１１】
ステップＳ５３５の結果がＮＯであるなら、バス上の第２パケットを無視する（ステップＳ５３７）。
【０１１２】
ステップＳ５３５の結果がＹＥＳであるなら、バス上の第２パケットの状態の情報を上位層に通知する（ステップＳ５３９）。かかる「状態の情報」は前述のステップＳ５１３における「状態の情報」と同じである。
【０１１３】
上記の如く、第５の実施形態の変形例によれば、（１）デスティネイションＩＤが特定のノードを示すこと、およびデスティネイション・オフセットが特定のアドレスを指定することをロック要求パケットの受信条件とし、（２）このロック要求パケットに対する応答パケットであることをロック応答パケットの受信条件とすることによって、他ノード宛てロック応答パケットであっても、特定ノードの特定アドレスに関するロック応答パケットについては当パケット内のクアドレットデータを上位層へ通知することができる。これによって、例えばノードａがノードｂによってロックされている場合であっても、ノードｃはノードａ発ノードｂ宛てロック応答パケットから、ノードａの状態の情報を取得することができる。
【０１１４】
【発明の効果】
上記の如く本発明の実施形態およびその変形例によれば、各ノードは自分宛ではないパケットであっても、上位層が必要とするパケットを上位層に通知することができる。このため、バスリセット後に構築された各ノードの新たな接続関係等を把握するためにバス上でやり取りされなければならないパケットの総数が減少し、バスの混雑が緩和される。また、そのような接続関係等を把握するために必要なパケット総数が減少すれば、そのような接続関係等の把握が早期に完了するので、実際のデータ転送などの状態に早期に移行することができる。
【図面の簡単な説明】
【図１】本発明の実施形態において送受信されるリード要求パケットのフォーマットを示す図である。
【図２】本発明の実施形態において送受信されるリード応答パケットのフォーマットを示す図である。
【図３】本発明の実施形態において使用されるＩＥＥＥ１３９４プロトコルの構成を示す図である。
【図４】バスリセットからＥＵＩ−６４リードまでの処理の流れを示すフローチャートである。
【図５】自己識別後のバス構成例を示す図である。
【図６】シリアルバスのアドレス指定とＥＵＩ−６４のアドレスとを示す図である。
【図７】ＥＵＩ−６４リードトランザクションの概念を示す図である。
【図８】本発明の実施形態において使用されるライト要求パケットのフォーマットを示す図である。
【図９】本発明の第１実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図１０】本発明の第１実施形態における処理の流れを示すフローチャートである。
【図１１】ノードＩＤとＥＵＩ−６４の対応表の概念図である。
【図１２】本発明の第２実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図１３】本発明の第２実施形態における処理の流れを示すフローチャートである。
【図１４】本発明の第３実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図１５】本発明の第３実施形態における処理の流れを示すフローチャートである。
【図１６】コンフィグレーションＲＯＭの構成例を示す図である。
【図１７】本発明の第４実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図１８】本発明の第４実施形態における処理の流れを示すフローチャートである。
【図１９】本発明の第５実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図２０】本発明の第５実施形態における処理の流れを示すフローチャートである。
【図２１】本発明の第５実施形態の変形例にかかるパケット送受信装置の構成を示すブロック図である。
【図２２】本発明の第５実施形態の変形例における処理の流れを示すフローチャートである。
【符号の説明】
１１０ ＰＨＹインタフェース
１２０ 抽出部
１３０ 一致判定部
１４０ 制御部
１５０ 記憶部
１７０ 受信ＦＩＦＯ
１８０ ホストインタフェース
１９０ 送信ＦＩＦＯ
【発明の属する技術分野】
本発明は、受け取ったパケット中の所定条件を具備するパケットのみを上位層に通知する通信方法および通信装置に関する。
【０００２】
【従来の技術】
ＩＥＥＥ１３９４−１９９５、ＩＥＥＥ１３９４ａ−２０００は高速シリアルバスの規格で、非同期転送（Asynchronous）と同期転送（Isochronous）の２種類の転送をサポートしている。
【０００３】
バスに接続されたノード間で非同期転送が行なわれる場合、リード要求ノードからリード要求パケットが送出され、リード応答ノードからリード応答パケットが送出される。リード要求パケットのヘッダ部分およびリード応答パケットのヘッダ部分の双方にデスティネイションＩＤ（destination_ID：パケットを受け取るべきノードのID）が格納されている。
【０００４】
バスに接続されている各ノードのリンク層では、バス上にパケットが存在すれば、物理層インタフェースを介してそのパケットを受け取り、そのパケットのヘッダ部分に格納されているデスティネイションIDと各ノードを識別するID（自己ノードID）とが一致するかを判定する。
【０００５】
両IDが一致する場合、パケット内の情報が上位層であるトランザクション（Transaction）層に通知される。
【０００６】
【発明が解決しようとする課題】
しかしながら、従来の技術には下記のような２つの問題点がある。まず、第１の問題点について説明する。ＩＥＥＥ１３９４では、ケーブルの挿抜によってノードの接続状態が変化するとバスリセットが発生し、各ノードのノードIDが変化する。各ノードの新たなノードIDは、ケーブルの挿抜によって発生するバスリセット後に続くツリー識別、自己識別の過程で決定される。また、全てのノードは機器の製造者等を特定するためにＥＵＩ−６４といわれる６４ビットの重複のないデータをコンフィギュレーションＲＯＭ内の特定アドレス領域に格納している。
【０００７】
ＩＥＥＥ１３９４をサポートしているＷｉｎｄｏｗｓ２０００のようなＯＳでは、バスリセット、ツリー識別、自己識別が完了すると、その後にバス上の各ノードは他のノードを識別するために、自己以外の全ノードのＥＵＩ−６４をリードする。特定ノードの特定アドレスへのリードトランザクションは、パケットのヘッダ部分にノードを特定するデスティネイションIDとアドレスを特定するデスティネイション・オフセットを格納して、リード要求パケットを送信することで開始する。これを受信したノードは、要求されたアドレスのデータをリード応答パケットに格納して返信する。かかるリード要求パケットの送信およびリード応答パケットの返信によって、リードトランザクションが終了する。バスリセット、ツリー識別、自己識別完了後、各ノードが、“全ノード数−１”個のリードトランザクションを送出する。
【０００８】
例えば、第１ノード、第２ノードおよび第３ノードが存在する場合、（１）第２ノードをデスティネイションＩＤとするリード要求パケットと、第３ノードをデスティネイションＩＤとするリード要求パケットとが、第１ノードから送出され、（２）第３ノードをデスティネイションＩＤとするリード要求パケットと、第１ノードをデスティネイションＩＤとするリード要求パケットとが、第２ノードから送出され、（３）第１ノードをデスティネイションＩＤとするリード要求パケットと、第２ノードをデスティネイションＩＤとするリード要求パケットとが、第３ノードから送出される。つまり、合計６個のリード要求パケットが送出される。
【０００９】
ＩＥＥＥ１３９４の上位プロトコル（例：ＡＶ／Ｃ（Audio-Video/Control）、ＳＢＰ（Serial Bus Protocol）−２、ＤＰＰ（Direct print protocol））を使用して、バスリセット前に特定の２ノード間でデータのやり取りを行っていた場合、バスリセット後にはノードIDが変化する可能性があるので、バスリセット後に各ノードのＥＵＩ−６４値をリードして、バスリセット前にやり取りを行っていた相手ノードを探すことになっている。この場合も、やり取りしていた相手ノードのＥＵＩ−６４値を記憶しておいて、かかるＥＵＩ−６４値と同一のＥＵＩ−６４値を有するノードが見つかるまでＥＵＩ−６４値をリード対象とするリードトランザクションを繰り返す。該当するＥＵＩ−６４値を有するノードを見つけたら、バスリセットによって中断されたトランザクションの続きを再開することができる。
【００１０】
バス上に６３ノード存在していて、各ノードがバスリセット後に、ノードIDを“０”から“全てのノード数−１”に変化させながら、ＥＵＩ−６４の格納されているアドレスを指定したリードトランザクションを全てのノードについて行うとすると、６２×６３回のリードトランザクションが行われることになる。
【００１１】
このようにバスリセット後は、ＥＵＩ−６４のリードトランザクションによりバスが混雑する可能性が高い。また、多数のノードからリードトランザクションを受けるとハングアップする可能性があるノードが存在する場合、バスリセット後のＥＵＩ−６４リードトランザクションの際にハングアップが発生する可能性が高い。
【００１２】
次に、第２の問題点について説明する。前記の如く、従来のリンク層は自己ノードIDとバス上のパケットのヘッダに含まれるデスティネイションIDとを比較して、両ＩＤが一致するパケットのみをTransaction層に通知する、つまり受信する。このため、例えば任意のノードａが特定のノードｂの状態を知りたい場合、ノードａ発ノードｂ宛てリード要求パケットがノードｂに到達し、かつノードｂ発ノードａ宛てリード応答パケットがノードａに到達しなければならない。ノードａ以外のノード（例えば、ノードｃ）がノードｂにリード要求パケットを送り、ノードｂからノードｃ宛てリード応答パケットがバスに送出されたとしても、ノードａのリンク層はノードｃ宛てリード応答パケットを上位層へ通知しない。ノードａが必要とする情報を有するリード応答パケットがノードａのリンク層に届いても、かかるリード応答パケットがノードａ宛ではないという理由によって、ノードａの上位層へは通知されない。
【００１３】
この結果、例えばあるノードｂに対して上位アプリケーションで接続状態を確立できるノード数が決まっており、かつ接続状態を確立できる最大数のノードが既にノードｂにログインしているために、ノードａがノードｂにログインできない場合、ノードｂと既に接続状態を確立しているノードのいずれかがその接続状態を解消するまで、ノードａはノードｂの状態を確認するためにリードトランザクションを繰り返さなければならない。
【００１４】
【課題を解決するための手段】
本発明の第１の特徴は、パケットを送受信し、所定のパケットに関する情報を上位層へ通知する通信方法であって、（ａ）第１パケットが第１条件を満たすかを調べて、前記第１パケットの情報を記憶するか否かを判断し、（ｂ）記憶すると判断した場合に前記第１パケットから第２条件として使用する情報を抽出し、（ｃ）第２パケットが前記第２条件を満たすかを調べて、前記第２パケットの情報を上位層に通知するか否かを判断し、（ｄ）通知すると判断した場合に前記第２パケットの情報を上位層に通知することにある。
【００１５】
かかる第１の特徴により、第１条件を満たす第１パケットから抽出された情報を、第２パケットを上位層へ通知するか否かを判断するための第２条件の一部または全部として使用することが可能となる。
【００１６】
【発明の実施の形態】
以下、図面に基づいて本発明の実施形態について説明する。なお、重複記載を避けるために、同一または類似の構成要素には、同一または類似の参照番号を付して説明を省略する。
【００１７】
図１に示すように、後述する実施形態において送受信されるリード要求パケットは、デスティネイション(destination)ＩＤ、トランザクションラベル(tlabel)、リトライコード(rt)、トランザクションコード(tcode)、プライオリティ(pri)、ソース(source)ＩＤ、デスティネイション・オフセット(destination offset)およびヘッダ(header)CRCの各フィールドを有する。
【００１８】
図２に示すように、後述する実施形態において送受信されるリード応答パケットは、デスティネイションＩＤ、トランザクションラベル、リトライコード、トランザクションコード、プライオリティ、ソースＩＤ、レスポンスコード(rcode)、予約(reserved)、クアドレット(quadlet data)およびヘッダCRCの各フィールドを有する。
【００１９】
図３に示すように、後述する実施形態におけるプロトコル層は、物理層、リンク層、トランザクション層、シリアルバス管理層および上位プロトコル層から成る。上位プロトコルには、ＡＶ／Ｃ(Audio Video Control)、ＳＢＰ (Serial Bus Protocol) −２、ＤＰＰ(Direct Print Protocol)が含まれる。
【００２０】
図４に示すように、後述する実施形態において、バスリセットが発生すると（Ｓ１）、ツリー構造の識別（Ｓ３）、自己識別（Ｓ５）およびＥＵＩ−６４リード（Ｓ７）が行われる。バスリセットは、ケーブルの挿抜などによって発生する。ツリー構造の識別によって、全ノードの各ポートが親ポートまたは子ポートとして特定される。ツリー構造の識別プロセスが完結すると、自己識別プロセスが始まる。自己識別中、各ノードから自己ＩＤパケットが送信され、ノードＩＤとバス上のノード数が確定する。そして、ノードの機器を特定するＥＵＩ−６４（拡張固有識別子）をリードすることで、ノードＩＤと機器の関連付けをする。ＥＵＩ−６４は、ノードベンダーＩＤ(node_vendor_ID)、チップＩＤハイ(chip_id_hi)およびチップＩＤロー(chip_id_lo)を連結することで生成される６４ビットの値である。
【００２１】
図５に示すように、自己識別後、各ノードにＩＤ番号が割り当てられる。図５は、ＩＤ＝１０のノードの子ポートとＩＤ＝５、６および９のノードの親ポートとが接続され、ＩＤ＝５のノードの子ポートとＩＤ＝３および４のノードの親ポートが接続され、ＩＤ＝３のノードの子ポートとＩＤ＝１および２のノードの親ポートが接続され、ＩＤ＝１のノードの子ポートとＩＤ＝０のノードの親ポートが接続され、ＩＤ＝９のノードの子ポートとＩＤ＝８のノードの親ポートが接続され、ＩＤ＝８のノードの子ポートとＩＤ＝７のノードの親ポートが接続されている例を示す。
【００２２】
図６に示すように、１０２４個まであるバスの一つ一つに６４個のノードで構成されるグループを割り当てる。各ノードは、２５６Ｔバイトのアドレス空間を持つ。各アドレス空間は、初期メモリ空間、プライベート空間および初期レジスタ空間に分割される。初期レジスタ空間は、ＣＳＲ（Control and Status Register）アーキテクチャ空間、シリアルバス空間、コンフィギュレーションＲＯＭ空間および初期ユニット空間に分割される。コンフィギュレーションＲＯＭ空間内に、ＥＵＩ−６４が記憶される。
【００２３】
図７に示すように、ＩＤ＝５のノードからＩＤ＝０のノードへリード要求パケットが送出されると、ＩＤ＝０のノードからＩＤ＝５のノードへリード応答パケットが送出される。同様に、ＩＤ＝６のノードからＩＤ＝０のノードへリード要求パケットが送出されると、ＩＤ＝０のノードからＩＤ＝６のノードへリード応答パケットが送出される。また、ＩＤ＝９のノードからＩＤ＝０のノードへリード要求パケットが送出されると、ＩＤ＝０のノードからＩＤ＝９のノードへリード応答パケットが送出される。さらに、ＩＤ＝３のノードからＩＤ＝０のノードへリード要求パケットが送出されると、ＩＤ＝０のノードからＩＤ＝３のノードへリード応答パケットが送出される。そして、ＩＤ＝０のノードから送出される上記４つのリード応答パケットに含まれるＥＵＩ−６４のデータは同一である。後述する実施形態においては、このような同一データを含む複数パケットの送出を不要にすることが可能になる。
【００２４】
図８に示すように、後述する実施形態において送受信されるライト要求パケットは、デスティネイションＩＤ、トランザクションラベル、リトライコード、トランザクションコード、プライオリティ、ソースＩＤ、デスティネイション・オフセット、クアドレットデータおよびヘッダCRCの各フィールドを有する。
【００２５】
＜第１の実施形態＞
第１の実施形態では、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、各ノードのノードＩＤとＥＵＩ−６４の対応関係を上位層へ通知することを可能とする。
【００２６】
図９は本発明の第１の実施形態におけるパケット送受信装置の構成を示すブロック図であり、図１０は本発明の第１の実施形態における処理の流れを示すフローチャートであり、図１１はノードＩＤとＥＵＩ−６４とをレジスタに格納した状態を示す図である。
【００２７】
図９に示すように、リンク層は、ＰＨＹ（物理層）インタフェース１１０、抽出部１２０、一致判定部１３０、制御部１４０、記憶部１５０、受信ＦＩＦＯ１７０、ホストインタフェース１８０、送信ＦＩＦＯ１９０を含む。
【００２８】
抽出部１２０は、バス上のパケットからデスティネイションＩＤ、デスティネイション・オフセット（送出先オフセット）、トランザクションコード、ソースＩＤ、トランザクションラベルを抽出する。これら用語の内容は、ＩＥＥＥ１３９４で定義されている。
【００２９】
記憶部１５０は、自己ノードＩＤ、ＥＵＩ−６４のアドレス、リード要求コード、リード応答コード、デスティネイションＩＤ、デスティネイション・オフセット、ソースＩＤ、トランザクションラベル等を記憶する。記憶部１５０としては、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）などが使用可能である。デスティネイションＩＤ、デスティネイション・オフセット等を物理的に１つのメモリに記憶させても良く、また物理的に分離した２以上のメモリに記憶させても良い。
【００３０】
一致判定部１３０は、例えばバス上のパケットから抽出されたデスティネイションＩＤと記憶部１５０に記憶されている自己ノードＩＤとを比較し、両ＩＤが一致したかどうかを示す信号を出力する。
【００３１】
制御部１４０は、抽出部１２０にバス上のパケットから何を抽出させるか、記憶部１５０に何を記憶させるか、一致判定部１３０に何と何を比較させるかを制御する。制御部１４０が抽出部１２０等をどのように制御するかの具体的内容は図１０のフローチャートに基づいて以下に説明する。
【００３２】
自己ノードＩＤ、ＥＵＩ−６４アドレス、リード要求トランザクションコードおよびリード応答トランザクションコードは、記憶部１５０に予め記憶されている。
【００３３】
図１０に示すように、まずflag=0を設定する（ステップＳ１０１）。具体的には、記憶部のflagレジスタに０を書き込む。そして、バス上にパケットが存在するかを調べる（ステップＳ１０３）。
【００３４】
ステップＳ１０３の結果がＹＥＳであるなら、パケットのデスティネイションＩＤが自己ノードＩＤと一致するかを調べる（ステップＳ１０５）。具体的には制御部１４０が、抽出部１２０にバス上のパケットからデスティネイションＩＤを抽出させ、一致判定部１３０に抽出されたデスティネイションＩＤと記憶されている自己ノードＩＤとを比較させる。
【００３５】
ステップＳ１０５の結果がＹＥＳであるなら、パケット内の情報をTransaction層に通知する（ステップＳ１０７）。つまり、受信ＦＩＦＯ１７０に受信イネーブル（Enable）信号を送る。
【００３６】
ステップＳ１０５の結果がＮＯであるなら、バス上のパケットのデスティネイション・オフセットがＥＵＩ−６４のアドレスであり、かつバス上のパケットのトランザクションコードがリード要求か（第１条件）を調べる（ステップＳ１０９）。具体的には、制御部１４０が、抽出部１２０にバス上のパケットからデスティネイション・オフセットとトランザクションコードを抽出させ、一致判定部１３０に（１）抽出されたデスティネイション・オフセットと記憶されているＥＵＩ−６４のアドレスとを比較させ、（２）抽出されたトランザクションコードと記憶されているリード要求コードとを比較させる。
【００３７】
ステップＳ１０９の結果がＹＥＳであるなら、バス上のパケット（第１パケット）のデスティネイションＩＤ、ソースＩＤ、トランザクションラベルを記憶し、かつflagに１を設定する（ステップＳ１１１）。具体的には、制御部１４０が、抽出部１４０にバス上のパケット（第１パケット）からデスティネイションＩＤ 、ソースＩＤ、トランザクションラベルを抽出させ、記憶部１５０のflagレジスタに１を、デスティネイションＩＤレジスタに抽出されたデスティネイションＩＤを、sourceレジスタに抽出されたソースＩＤを、トランザクションラベルレジスタに抽出されたトランザクションラベルを書き込む。そして、ステップＳ１０３に戻り、ステップＳ１０５、Ｓ１０９が繰り返される。
【００３８】
ステップＳ１０９の結果がＮＯであるなら、（１）flag＝１であり、かつ（２）バス上のパケットが、ステップＳ１１１で記憶されたリード要求パケットに対するリード応答パケットか（第２条件）を調べる（ステップＳ１１３）。
【００３９】
具体的には、
記憶部１５０のflagレジスタに１が書き込まれているかを調べ、
抽出部１２０に、バス上のパケット（第２パケット）からデスティネイションＩＤ、ソースＩＤ、トランザクションラベル、トランザクションコードを抽出させ、
一致判定部１３０に、（１）バス上の第２パケットのデスティネイションＩＤとステップＳ１１１で記憶された第１パケットのソースＩＤとを比較させ、（２）バス上の第２パケットのソースＩＤとステップＳ１１１で記憶された第１パケットのデスティネイションＩＤとを比較させ、（３）バス上の第２パケットのトランザクションラベルとステップＳ１１１で記憶された第１パケットのトランザクションラベルとを比較させ、（４）バス上の第２パケットのトランザクションコードと予め記憶されているリード応答コードとを比較させる。
【００４０】
ステップＳ１１３の結果がＮＯであるなら、バス上のパケットを無視する（ステップＳ１１５）。
【００４１】
ステップＳ１１３の結果がＹＥＳであるなら、バス上の第２パケット内の情報を上位層に通知し、flagの値を０に戻す（ステップＳ１１７）。具体的には、受信ＦＩＦＯ１７０に受信Enable信号を送り、記憶部１５０にflag=０を書き込む。
【００４２】
ステップＳ１１７後に、バス上のリード応答パケット内のソースＩＤ（図１１に示すノードＩＤ）とＥＵＩ―６４の値が図１１に示すように関連付けられて記憶部１５０のノードＩＤ／ＥＵＩ−６４対応表レジスタに記憶される。かかる処理を繰り返すことによって、バス上の全ノードのノードＩＤとＥＵＩ−６４の値との対応表を作成することができる。
【００４３】
上記の如く、第１の実施形態では、他ノード宛てリード応答パケットであっても、デスティネイション・オフセットがＥＵＩ―６４のアドレスであるリード要求パケットに対するリード応答パケットについては上位層へ通知する。その結果、各ノードが他のノードの情報を取得するためにバス上で送受信されなければならないパケット数が減少する。
【００４４】
例えば、第１のノードａと、第２のノードｂと、第３のノードｃとがバスを介してパケットを送受信することによって、各ノードが他のノードに関する情報を取得する場合を考える。従来はバスリセット後に下記の１２個のパケットがバスに送出されていた。
【００４５】
（１）ノードａからノードｂへのリード要求パケット、
（２）ノードｂからノードａへのリード応答パケット、
（３）ノードａからノードｃへのリード要求パケット、
（４）ノードｃからノードａへのリード応答パケット、
（５）ノードｂからノードｃへのリード要求パケット、
（６）ノードｃからノードｂへのリード応答パケット、
（７）ノードｂからノードａへのリード要求パケット、
（８）ノードａからノードｂへのリード応答パケット、
（９）ノードｃからノードａへのリード要求パケット、
（10）ノードａからノードｃへのリード応答パケット、
（11）ノードｃからノードｂへのリード要求パケット、
（12）ノードｂからノードｃへのリード応答パケット。
【００４６】
しかし、第１の実施形態によれば、バスリセット後に下記の６個のパケットがバスに送出されるだけで良い。
【００４７】
（１）ノードａからノードｂへのリード要求パケット、
（２）ノードｂからノードａへのリード応答パケット、
（３）ノードａからノードｃへのリード要求パケット、
（４）ノードｃからノードａへのリード応答パケット、
（５）ノードｂからノードａへのリード要求パケット、
（６）ノードａからノードｂへのリード応答パケット。
【００４８】
なぜなら、ノードｂからノードａへのリード応答パケットは、ノードｂに関する情報を、ノードａに通知するのみならず、ノードｃにも通知するからである。また、ノードｃからノードａへのリード応答パケットは、ノードｃに関する情報を、ノードａに通知するのみならず、ノードｂにも通知するからである。さらに、ノードａからノードｂへのリード応答パケットは、ノードａに関する情報を、ノードｂに通知するのみならず、ノードｃにも通知するからである。
【００４９】
上記の如く、第１の実施形態によれば、バスリセット後に各ノードが他の全てのノードに関する情報を取得するためにバスに送出されるパケット総数が減少するので、バスの混雑を緩和することができる。そして、パケット総数が減少すれば、各ノードが他のノードに関する情報を取得するまでに必要とする時間が短縮される。その結果、実際のデータを転送する状態に早く移ることができる。実際のデータとは、各ノード間の接続関係等を把握するために送受信されるデータではなく、各ノード間の接続関係等が把握された後に送受信されるデータを言い、映像データや音声データなどが含まれる。また、複数のノードからリードトランザクションを受けるとハングアップしてしまうような機器に関しては、リードトランザクションが減少する結果、ハングアップの確率が減る。
【００５０】
＜第２の実施形態＞
第２の実施形態では、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、バスリセット前にパケットを送受信していたノードのノードＩＤを上位層へ通知することを可能とする。具体的には、バスリセットの前後で変化しないＥＵＩ−６４の値に基づいて、バスリセット前にパケットを送受信していたノードのバスリセット後のノードＩＤを上位層へ通知する。
【００５１】
図１２は本発明の第２の実施形態におけるパケット送受信装置の構成を示すブロック図であり、図１３は本発明の第２の実施形態における処理の流れを示すフローチャートである。
【００５２】
自己ノードＩＤ、ＥＵＩ−６４アドレス、リード要求トランザクションコードおよびリード応答トランザクションコードは、記憶部に予め記憶されている。
【００５３】
図１３に示すように、第２の実施形態では、まずＥＵＩ−６４レジスタに値を設定する（ステップＳ２０１）。具体的には、バスリセット直前に受け取ったパケットを送出したノードのＥＵＩ−６４の値を記憶部２５０のＥＵＩ−６４レジスタに記憶する。前記の如く、バスリセットの前後で、各ノードのノードＩＤは変化しうるが、ＥＵＩ−６４の値は変化しない。
【００５４】
次に、flagに０を設定し（ステップＳ２０３）、バス上にパケットが存在するかを調べ（ステップＳ２０５）、パケットが存在する場合はそのパケットのデスティネイションＩＤが自己ノードIDと一致するかを調べる（ステップＳ２０７）。
【００５５】
ステップＳ２０７の結果がＹＥＳであるなら、パケット内の情報をTransaction層に通知する（ステップＳ２０９）。
【００５６】
ステップＳ２０７の結果がＮＯであるなら、バス上のパケットのデスティネイション・オフセットがＥＵＩ−６４のアドレスであり、かつバス上のパケットのトランザクションコードがリード要求であるか（第１条件）を調べる（ステップＳ２１１）。
【００５７】
ステップＳ２１１の結果がＹＥＳであるなら、バス上のパケット（第１パケット）のデスティネイションＩＤ、ソースＩＤ、トランザクションラベルを記憶し、かつflagに１を設定する（ステップＳ２１３）。そして、ステップＳ２０５に戻り、ステップＳ２０７、Ｓ２１１が繰り返される。
【００５８】
ステップＳ２１１の結果がＮＯであるなら、（１）flag＝１であり、かつ（２）バス上のパケット（第２パケット）が、記憶されたリード要求パケットに対するリード応答パケットであり、かつ（３）バス上のパケット（第２パケット）のＥＵＩ―６４の値がＥＵＩ―６４レジスタに設定された値と一致するか（第２条件）を調べる（ステップＳ２１５）。
【００５９】
具体的には、
記憶部２５０のflagレジスタに１が書き込まれているかを調べ、
抽出部１２０に、バス上のパケット（第２パケット）からデスティネイションＩＤ、ソースＩＤ、トランザクションラベル、トランザクションコードを抽出させ、
一致判定部１３０に、（１）バス上の第２パケットから抽出されたデスティネイションＩＤとステップＳ２１３で記憶された第１パケットのソースＩＤとを比較させ、（２）バス上の第２パケットから抽出されたソースＩＤとステップＳ２１３で記憶された第１パケットのデスティネイションＩＤとを比較させ、（３）バス上の第２パケットから抽出されたトランザクションラベルとステップＳ２１３で記憶された第１パケットのトランザクションラベルとを比較させ、（４）バス上の第２パケットから抽出されたトランザクションコードと予め記憶されているリード応答コードとを比較させ、（５）バス上の第２パケットのＥＵＩ―６４の値とステップＳ２０１でＥＵＩ―６４レジスタに設定された値とを比較させる。
【００６０】
ステップＳ２１５の結果がＮＯであるなら、バス上のパケットを無視する（ステップＳ２１７）。
【００６１】
ステップＳ２１５の結果がＹＥＳであるなら、バス上のパケットのソースＩＤを上位層に通知し、flagを０に戻す（ステップＳ２１９）。
【００６２】
第２の実施形態によれば、他ノード宛てリード応答パケットを格納することによって、バスリセット直前にパケットをやり取りしていた相手方ノードを見つけ出すことができる。
【００６３】
例えば、第１のノードａと、第２のノードｂと、第３のノードｃとが存在し、かつバスリセット直前にノードａとノードｂとがパケットをやり取りしていたとする。そして、バスリセットによってノードＩＤが変化し、ノードａがノードｘとなり、ノードｂがノードｙとなり、ノードｃがノードｚとなったとする。バスリセットによって中断されたパケットのやり取りを再開するためには、ノードｘはバスリセット前のノードｂがバスリセット後にノードｙとなったたことを認識する必要がある。
【００６４】
バスリセットによって各ノードのノードＩＤは変化しうるが、ＥＵＩ−６４の値は変化しないので、ノードｘはノードｂのＥＵＩ―６４の値とノードｙのＥＵＩ―６４の値とを比較することによって、ノードｙがバスリセット前のノードｂであることを認識しうる。
【００６５】
従来はノードｘがノードｙのＥＵＩ―６４の値を知るためには、デスティネイション・オフセットがＥＵＩ―６４アドレスであるノードｙ宛てリード要求パケットをノードｘがバスに送出し、このリード要求パケットに対してノードｙがノードｘ宛てリード応答パケットをバスに送出する必要があった。
【００６６】
しかし、第２の実施形態によれば、ノードｘは、（１）ノードｚからバスに送出されたノードｙ宛てリード要求パケットのデスティネイション・オフセットがＥＵＩ―６４のアドレスであること、および（２）このリード要求パケットに対してノードｙからバスに送出されたノードｚ宛てリード応答パケットのクアドレットデータとバスリセット前に記憶しておいたノードｂのＥＵＩ―６４の値とが一致することを確認することによって、ノードｙがバスリセット前のノードｂであることを認識しうる。
【００６７】
上記の如く、第２の実施形態によれば、（１）デスティネイション・オフセットがＥＵＩ―６４のアドレスであることをリード要求パケットの受信条件とし、（２−１）このリード要求パケットに対するリード応答パケットであること、および（２−２）かかるリード応答パケットのクアドレットデータが特定の値（ＥＵＩ―６４レジスタに設定されている値と等しい値）であることをリード応答パケットの受信条件とすることによって、他ノード宛てリード応答パケットからバスリセット直前にパケットを送受信していたノードのノードＩＤを知ることができる。また、複数のノードからリードトランザクションを受けるとハングアップしてしまうような機器に関しては、リードトランザクションが減少する結果、ハングアップの確率が減る。
【００６８】
＜第３の実施形態＞
第３の実施形態では、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、特定の上位プロトコルをサポートするノードのノードＩＤを上位層へ通知することを可能とする。
【００６９】
図１４は本発明の第３の実施形態におけるパケット送受信装置の構成を示すブロック図であり、図１５は本発明の第３の実施形態における処理の流れを示すフローチャートであり、図１６は本発明の第３の実施形態におけるコンフィギュレーションROMの構成を示す図である。
【００７０】
自己ノードＩＤ、コンフィギュレーションROMアドレス、リード要求トランザクションコードおよびリード応答トランザクションコードは、記憶部３５０に予め記憶されている。
【００７１】
図１５に示すように、第３の実施形態では、まず上位プロトコルレジスタに値を設定する（ステップＳ３０１）。具体的には、キー・タイプ、キー・ヴァリュウ、使用したい上位プロトコルをプロトコルレジスタに設定する。かかるレジスタの設定内容が同じプロトコルをサポートするノードを探し出すために使用される。キー・タイプはエントリー・ヴァリュウ(entry_value)の特性を定義し、キー・ヴァリュウは各ＲＯＭディレクトリ項目の内容と名前を特定する。コンフィギュレーションROMの構成例を図１６に示す。例えば”0x12”を２進数で表した”00010010”の上位２ビット”00”がキー・タイプを、下位６ビット”010010”がキー・ヴァリュウを表す。
次に、flagに０を設定し（ステップＳ３０３）、バス上にパケットが存在するかを調べ（ステップＳ３０５）、バス上にパケットが存在する場合はそのパケットのデスティネイションＩＤが自己ノードIDと一致するかを調べる（ステップＳ３０７）。
【００７２】
ステップＳ３０７の結果がＹＥＳであるなら、パケット内の情報をTransaction層に通知する（ステップＳ３０９）。
【００７３】
ステップＳ３０７の結果がＮＯであるなら、バス上のパケットのデスティネイション・オフセットがコンフィギュレーション ROMのアドレスであり、かつトランザクションコードがリード要求か（第１条件）を調べる（ステップＳ３１１）。
【００７４】
ステップＳ３１１の結果がＹＥＳであるなら、バス上のパケット（第１パケット）のデスティネイションＩＤ、ソースＩＤ、トランザクションラベルを記憶し、かつflagに１を設定する（ステップＳ３１３）。そして、ステップＳ３０５に戻り、ステップＳ３０７、Ｓ３１１が繰り返される。
【００７５】
ステップＳ３１１の結果がＮＯであるなら、（１）flag＝１であり、かつ（２）バス上のパケット（第２パケット）がステップＳ３１３で記憶されたリード要求パケットに対するリード応答パケットであり、かつ（３）バス上のパケット（第２パケット）のデータがステップＳ３０１で上位プロトコルレジスタに設定された値と一致するか（第２条件）を調べる（ステップＳ３１５）。
【００７６】
具体的には、
記憶部３５０のflagレジスタに１が書き込まれているかを調べ、
抽出部１２０に、バス上のパケット（第２パケット）からデスティネイションＩＤ、ソースＩＤ、トランザクションラベル、トランザクションコード、データを抽出させ、
一致判定部１３０に、（１）バス上の第２パケットから抽出されたデスティネイションＩＤとステップＳ３１３で記憶された第１パケットのソースＩＤとを比較させ、（２）バス上の第２パケットから抽出されたソースＩＤとステップＳ３１３で記憶された第１パケットのデスティネイションＩＤとを比較させ、（３）バス上の第２パケットから抽出されたトランザクションラベルとステップＳ３１３で記憶された第１パケットのトランザクションラベルとを比較させ、（４）バス上の第２パケットから抽出されたトランザクションコードと予め記憶されているリード応答コードとを比較させ、（５）バス上の第２パケットのデータとステップＳ３０１で設定された上位プロトコルレジスタの値とを比較させる。
【００７７】
ステップＳ３１５の結果がＮＯであるなら、バス上のパケットを無視する（ステップＳ３１７）。
【００７８】
ステップＳ３１５の結果がＹＥＳであるなら、バス上のパケットのソースＩＤを上位層に通知し、flagを０に戻す（ステップＳ３１９）。
【００７９】
図１６に示すように、コンフィギュレーションＲＯＭには、ＥＵＩ−６４以外にも機器の性能を示す情報が格納されている。上位プロトコル（ＡＶ／Ｃ、ＳＢＰ−２、ＤＰＰ等）のサポート状態などもそういった情報の１つである。
【００８０】
上記の如く、第３の実施形態によれば、（１）デスティネイション・オフセットがコンフィギュレーション ＲＯＭのアドレスであることをリード要求パケットの受信条件とし、（２−１）このリード要求パケットに対するリード応答パケットであること、および（２−２）クアドレットデータに含まれるキー・タイプとキー・ヴァリュウが特定の値であることをリード応答パケットの受信条件とすることによって、他ノード宛てリード応答パケットであっても、特定の上位プロトコルをサポートするノードのノードIDをソースＩＤとするリード応答パケットについては上位層へ通知することができる。
【００８１】
＜第４の実施形態＞
第４の実施形態では、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、特定のノードの状態を上位層へ通知することを可能とする。ノードの状態とは、所定の処理を実施中であるとか、所定の処理を終了したという状態を言い、例えばプリント処理が終了したという状態が含まれる。
【００８２】
図１７は本発明の第４の実施形態におけるパケット送受信装置の構成を示すブロック図であり、図１８は本発明の第４の実施形態における処理の流れを示すフローチャートである。
【００８３】
自己ノードＩＤ、リード要求トランザクションコードおよびリード応答トランザクションコードは、記憶部４５０に予め記憶されている。
【００８４】
図１８に示すように、第４の実施形態では、まずデスティネイションＩＤとデスティネイション・オフセットを設定する（ステップＳ４０１）。具体的には、状態を知りたいノードのノードＩＤを記憶部４５０のデスティネイションＩＤレジスタに記憶させ、状態を知りたいノードの状態レジスタのアドレスを記憶部４５０のデスティネイション・オフセットレジスタに記憶させる。
【００８５】
次に、flagに０を設定し（ステップＳ４０３）、バス上にパケットが存在するかを調べ（ステップＳ４０５）、パケットが存在する場合はそのパケットのデスティネイションＩＤが自分のノードIDと一致するかを調べる（ステップＳ４０７）。
【００８６】
ステップＳ４０７の結果がＹＥＳであるなら、パケット内の情報をTransaction層に通知する（ステップＳ４０９）。
【００８７】
ステップＳ４０７の結果がＮＯであるなら、（１）バス上のパケットのデスティネイションＩＤ とデスティネイション・オフセットとがステップＳ４０１でレジスタに記憶されたデスティネイションＩＤ とデスティネイション・オフセットとにそれぞれ一致し、かつ（２）バス上のパケットのトランザクションコードがリード要求であるか（第１条件）を調べる（ステップＳ４１１）。
【００８８】
ステップＳ４１１の結果がＹＥＳであるなら、バス上のパケット（第１パケット）のデスティネイションＩＤ、ソースＩＤ、トランザクションラベルを記憶し、かつflagに１を設定する（ステップＳ４１３）。そして、ステップＳ４０５に戻り、ステップＳ４０７、Ｓ４１１が繰り返される。
【００８９】
ステップＳ４１１の結果がＮＯであるなら、（１）flag＝１であり、かつ（２）バス上のパケットがステップＳ４１３で記憶されたリード要求パケットに対するリード応答パケットであるか（第２条件）を調べる（ステップＳ４１５）。
【００９０】
具体的には、
記憶部４５０のflagレジスタに１が書き込まれているかを調べ、
抽出部１２０に、バス上のパケット（第２パケット）からデスティネイションＩＤ、ソースＩＤ、トランザクションラベル、トランザクションコードを抽出させ、
一致判定部１３０に、（１）バス上の第２パケットから抽出されたデスティネイションＩＤとステップＳ４１３で記憶された第１パケットのソースＩＤとを比較させ、（２）バス上の第２パケットから抽出されたソースＩＤとステップＳ４１３で記憶された第１パケットのデスティネイションＩＤとを比較させ、（３）バス上の第２パケットから抽出されたトランザクションラベルとステップＳ４１３で記憶された第１パケットのトランザクションラベルとを比較させ、（４）バス上の第２パケットから抽出されたトランザクションコードと予め記憶されているリード応答コードとを比較させる。
【００９１】
ステップＳ４１５の結果がＮＯであるなら、バス上のパケットを無視する（ステップＳ４１７）。
【００９２】
ステップＳ４１５の結果がＹＥＳであるなら、バス上の第２パケットの状態の情報を上位層に通知し、flagを０に戻す（ステップＳ４１９）。
【００９３】
上記の如く、第４の実施形態によれば、（１）デスティネイションＩＤが特定のノードを示すこと、およびデスティネイション・オフセットが状態レジスタのアドレスであることとをリード要求パケットの受信条件とし、（２）このパケットに対する返答であることをリード応答パケットの受信条件とすることによって、他ノード宛てリード応答パケットであっても、特定のノードIDの状態レジスタから読み出されたクアドレットデータを包含しているリード応答パケットについては上位層へ通知することができる。
【００９４】
＜第５の実施形態＞
第５の実施形態も、自己ノード宛てパケットからではなく、他ノード宛てパケットから必要な情報を取得して、特定のノードの状態を上位層へ通知することを可能とする。上記第１から第４の実施形態では他ノード宛てリード応答パケットから必要な情報を取得する。しかし、第５の実施形態では、他ノード宛てライト要求パケットまたはロック要求パケットから必要な情報を取得する。
【００９５】
図１９は本発明の第５の実施形態におけるリンク層の構成を示すブロック図であり、図２０は本発明の第５の実施形態における処理の流れを示すフローチャートである。
【００９６】
第５の実施形態は、あるノード（例えば、ノードｂ）に対して上位アプリケーションで接続状態を確立できるノード数が決まっていて、接続状態を確立できるノード数の最大数のノードが既にログインされているので、ログインできていない他のノード（例えば、ノードａ）が空きを待っている状態に関する。
【００９７】
自己ノードＩＤおよびライト要求トランザクションコードは、記憶部５５０に予め記憶されている。状態を知りたいノードには、同時に接続可能な最大数のノードが既に接続をしているものとする。
【００９８】
図２０に示すように、第５の実施形態では、まずデスティネイションＩＤとデスティネイション・オフセットを設定する（ステップＳ５０１）。具体的には、状態を知りたいノードのＩＤをデスティネイションＩＤレジスタに、状態を知りたいノードのログイン／ログアウトレジスタのアドレスをデスティネイション・オフセットレジスタに記憶させる。
【００９９】
次に、バス上にパケットが存在するかを調べ（ステップＳ５０３）、パケットが存在する場合はそのパケットのデスティネイションＩＤが自己ノードIDと一致するかを調べる（ステップＳ５０５）。
【０１００】
ステップＳ５０５の結果がＹＥＳであるなら、パケット内の情報をTransaction層に通知する（ステップＳ５０７）。
【０１０１】
ステップＳ５０５の結果がＮＯであるなら、バス上のパケットのデスティネイションＩＤ とデスティネイション・オフセットとがステップＳ５０１でレジスタに記憶されたデスティネイションＩＤ とデスティネイション・オフセットとにそれぞれ一致し、かつバス上のパケットがライト要求パケットかを調べる（ステップＳ５０９）。
【０１０２】
ステップＳ５０９の結果がＮＯであるなら、バス上のパケットを無視する（ステップＳ５１１）。
【０１０３】
ステップＳ５０９の結果がＹＥＳであるなら、状態の情報を上位層に通知する（ステップＳ５１３）。ここで「状態の情報」とは、ライト要求パケットによって書き込まれるデータのことである。ただし、書き込まれるデータの単位が１クアドレット(32bit)であって、１クアドレット以上のデータが書き込まれる場合、１つのライト要求パケットによって書き込まれるデータは、全データの一部となる。
【０１０４】
上記の如く、第５の実施形態によれば、デスティネイションＩＤが特定のノードを示すこと、およびデスティネイション・オフセットが特定のアドレスを指定することをライト要求パケットの受信条件とすることによって、他ノード宛てライト要求パケットであっても、特定ノードの特定アドレスに対するライト要求パケットについては当パケット内のクアドレットデータを上位層へ通知することができる。これによって、ある特定のノードｂに対して上位アプリケーションで接続状態を確立できるノード数が決まっていて、かつ接続状態を確立できるノード数だけ既にログインされているので、ノードａはノードｂにログインしているノードのいずれかがログアウトするのを待っている状態であっても、ノードａはノードｂの特定のアドレスの値を知ることができる。
【０１０５】
＜第５の実施形態の変形例＞
図２１は本発明の第５の実施形態の変形例におけるパケット送受信装置の構成を示すブロック図であり、図２２は本発明の第５の実施形態の変形例における処理の流れを示すフローチャートである。
【０１０６】
図２２に示すステップＳ５２１、Ｓ５２５、Ｓ５２７、Ｓ５２９はそれぞれ、図２０に示すステップＳ５０１、Ｓ５０３、Ｓ５０５、Ｓ５０７と同じであるから、説明を省略する。また、図２２に示すステップＳ５２３では、flagに０を設定する。
【０１０７】
ステップＳ５２７の結果がＮＯであるなら、バス上のパケットのデスティネイションＩＤ とデスティネイション・オフセットとがステップＳ５２１でレジスタに記憶されたデスティネイションＩＤ とデスティネイション・オフセットとにそれぞれ一致し、かつバス上のパケットのトランザクションコードを抽出し、そのトランザクションコードが記憶部に記憶されているロック要求トランザクションコードと一致するか（第１条件）を調べる（ステップＳ５３１）。
【０１０８】
ステップＳ５３１の結果がＹＥＳであるなら、バス上のパケット（第１パケット）のデスティネイションＩＤ、ソースＩＤ、トランザクションラベルを記憶し、かつflagに１を設定する（ステップＳ５３３）そして、ステップＳ５２５に戻り、ステップＳ５２７、Ｓ５３１が繰り返される。
【０１０９】
ステップＳ５３１の結果がＮＯであるなら、（１）flag＝１であり、かつ（２）バス上のパケット（第２パケット）がステップＳ５３３で記憶されたロック要求パケットに対するロック応答パケットであるか（第２条件）を調べる（ステップＳ５３５）。
【０１１０】
具体的には、
記憶部６５０のflagレジスタに１が書き込まれているかを調べ、
抽出部１２０に、バス上のパケット（第２パケット）からデスティネイションＩＤ、ソースＩＤ、トランザクションラベル、トランザクションコードを抽出させ、
一致判定部１３０に、（１）バス上の第２パケットから抽出されたデスティネイションＩＤとステップＳ５３３で記憶された第１パケットのソースＩＤとを比較させ 、（２）バス上の第２パケットから抽出されたソースＩＤとステップＳ５３３で記憶された第１パケットのデスティネイションＩＤとを比較させ、（３）バス上の第２パケットから抽出されたトランザクションラベルとステップＳ５３３で記憶された第１パケットのトランザクションラベルとを比較させ、（４）バス上の第２パケットから抽出されたトランザクションコードと予め記憶されているロック応答コードとを比較させる。
【０１１１】
ステップＳ５３５の結果がＮＯであるなら、バス上の第２パケットを無視する（ステップＳ５３７）。
【０１１２】
ステップＳ５３５の結果がＹＥＳであるなら、バス上の第２パケットの状態の情報を上位層に通知する（ステップＳ５３９）。かかる「状態の情報」は前述のステップＳ５１３における「状態の情報」と同じである。
【０１１３】
上記の如く、第５の実施形態の変形例によれば、（１）デスティネイションＩＤが特定のノードを示すこと、およびデスティネイション・オフセットが特定のアドレスを指定することをロック要求パケットの受信条件とし、（２）このロック要求パケットに対する応答パケットであることをロック応答パケットの受信条件とすることによって、他ノード宛てロック応答パケットであっても、特定ノードの特定アドレスに関するロック応答パケットについては当パケット内のクアドレットデータを上位層へ通知することができる。これによって、例えばノードａがノードｂによってロックされている場合であっても、ノードｃはノードａ発ノードｂ宛てロック応答パケットから、ノードａの状態の情報を取得することができる。
【０１１４】
【発明の効果】
上記の如く本発明の実施形態およびその変形例によれば、各ノードは自分宛ではないパケットであっても、上位層が必要とするパケットを上位層に通知することができる。このため、バスリセット後に構築された各ノードの新たな接続関係等を把握するためにバス上でやり取りされなければならないパケットの総数が減少し、バスの混雑が緩和される。また、そのような接続関係等を把握するために必要なパケット総数が減少すれば、そのような接続関係等の把握が早期に完了するので、実際のデータ転送などの状態に早期に移行することができる。
【図面の簡単な説明】
【図１】本発明の実施形態において送受信されるリード要求パケットのフォーマットを示す図である。
【図２】本発明の実施形態において送受信されるリード応答パケットのフォーマットを示す図である。
【図３】本発明の実施形態において使用されるＩＥＥＥ１３９４プロトコルの構成を示す図である。
【図４】バスリセットからＥＵＩ−６４リードまでの処理の流れを示すフローチャートである。
【図５】自己識別後のバス構成例を示す図である。
【図６】シリアルバスのアドレス指定とＥＵＩ−６４のアドレスとを示す図である。
【図７】ＥＵＩ−６４リードトランザクションの概念を示す図である。
【図８】本発明の実施形態において使用されるライト要求パケットのフォーマットを示す図である。
【図９】本発明の第１実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図１０】本発明の第１実施形態における処理の流れを示すフローチャートである。
【図１１】ノードＩＤとＥＵＩ−６４の対応表の概念図である。
【図１２】本発明の第２実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図１３】本発明の第２実施形態における処理の流れを示すフローチャートである。
【図１４】本発明の第３実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図１５】本発明の第３実施形態における処理の流れを示すフローチャートである。
【図１６】コンフィグレーションＲＯＭの構成例を示す図である。
【図１７】本発明の第４実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図１８】本発明の第４実施形態における処理の流れを示すフローチャートである。
【図１９】本発明の第５実施形態にかかるパケット送受信装置の構成を示すブロック図である。
【図２０】本発明の第５実施形態における処理の流れを示すフローチャートである。
【図２１】本発明の第５実施形態の変形例にかかるパケット送受信装置の構成を示すブロック図である。
【図２２】本発明の第５実施形態の変形例における処理の流れを示すフローチャートである。
【符号の説明】
１１０ ＰＨＹインタフェース
１２０ 抽出部
１３０ 一致判定部
１４０ 制御部
１５０ 記憶部
１７０ 受信ＦＩＦＯ
１８０ ホストインタフェース
１９０ 送信ＦＩＦＯ
Claims (8)
- パケットを送受信し、所定のパケットに関する情報を上位層へ通知する通信方法であって、
（ａ）第１パケットのデスティネイション・オフセットが、第１の所定のアドレスを指し示し、
前記第１パケットのトランザクションコードが、リード要求を定義している、という第１条件が満たされるかを調べて、前記第１パケットの情報を記憶するか否かを判断し、
（ｂ）記憶すると判断した場合に前記第１パケットからデスティネイションＩＤ、ソースＩＤおよびトランザクションラベルを抽出し、
（ｃ）第２パケットのデスティネイションＩＤが、前記第１パケットのソースＩＤと一致し、
前記第２パケットのソースＩＤが、前記第１パケットのデスティネイションＩＤと一致し、
前記第２パケットのトランザクションラベルが、前記第１パケットのトランザクションラベルと一致し、
前記第２パケットのトランザクションコードが、リード応答を定義している、という第２条件が満たされるかを調べて、前記第２パケットの情報を上位層に通知するか否かを判断し、
（ｄ）通知すると判断した場合に前記第２パケットの情報を上位層に通知する、ことを特徴とする。 - 請求項１記載の通信方法であって、前記パケットの送受信がＩＥＥＥ１３９４規格に従って行われる。
- 請求項１又は２記載の通信方法であって、前記第１の所定のアドレスが、ＥＵＩ―６４のアドレスである。
- 請求項３記載の通信方法であって、ＥＵＩ−６４の値を予め記憶し、
（ｃ）前記第２条件に、前記第２パケットから送出先ノードに送られるデータの値が、予め記憶した前記ＥＵＩ−６４の値と一致することが含まれる。 - 請求項１ないし４記載の通信方法であって、前記上位層に通知される前記第２パケットの前記情報に前記第２パケットのソースＩＤが含まれる。
- 請求項１又は２記載の通信方法であって、キー・タイプ、キー・ヴァリュウおよび上位プロトコルを予め記憶し、
（ａ）前記第１の所定のアドレスが、コンフィギュレーションROMのアドレスであり、
（ｃ）前記第２条件に、前記第２パケットから送出先ノードに送られるデータの値が、予め記憶した前記キー・タイプ、前記キー・ヴァリュウおよび前記上位プロトコルと一致することが含まれる。 - 請求項１又は２記載の通信方法であって、デスティネイションＩＤおよびデスティネイション・オフセットを予め記憶し、
（ａ）前記第１条件に、
前記第１パケットのデスティネイションＩＤが、予め記憶した前記デスティネイションＩＤと一致し、
前記第１パケットのデスティネイション・オフセットが、予め記憶した前記デスティネイション・オフセットと一致することが含まれる。 - パケットを送受信し、所定のパケットに関する情報を上位層へ通知する通信方法であって、デスティネイションＩＤおよびデスティネイション・オフセットを予め記憶し、
（ａ）第１パケットのデスティネイションＩＤが、予め記憶した前記デスティネイションＩＤと一致し、
前記第１パケットのデスティネイション・オフセットが、予め記憶した前記デスティネイション・オフセットと一致し、
前記第１パケットのトランザクションコードが、ロック要求を定義している、という第１条件が満たされるかを調べて、前記第１パケットの情報を記憶するか否かを判断し、
（ｂ）前記第２条件として使用する情報が、前記第１パケットのデスティネイションＩＤ、ソースＩＤおよびトランザクションラベルであり、
（ｃ）第２パケットのデスティネイションＩＤが、前記第１パケットのソースＩＤと一致し、
前記第２パケットのソースＩＤが、前記第１パケットのデスティネイションＩＤと一致し、
前記第２パケットのトランザクションラベルが、前記第１パケットのトランザクションラベルと一致し、
前記第２パケットのトランザクションコードが、ロック応答を定義している、という第２条件が満たされるかを調べて、前記第２パケットの情報を上位層に通知するか否かを判断し、
（ｄ）通知すると判断した場合に前記第２パケットの情報を上位層に通知する、ことを特徴とする。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002066010A JP3647815B2 (ja) | 2002-03-11 | 2002-03-11 | 通信方法および通信装置 |
| US10/383,635 US7352742B2 (en) | 2002-03-11 | 2003-03-10 | Method and apparatus for transmitting to an upper layer of information included in a packet |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002066010A JP3647815B2 (ja) | 2002-03-11 | 2002-03-11 | 通信方法および通信装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003264560A JP2003264560A (ja) | 2003-09-19 |
| JP3647815B2 true JP3647815B2 (ja) | 2005-05-18 |
Family
ID=29198038
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002066010A Expired - Fee Related JP3647815B2 (ja) | 2002-03-11 | 2002-03-11 | 通信方法および通信装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7352742B2 (ja) |
| JP (1) | JP3647815B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2005157444A (ja) * | 2003-11-20 | 2005-06-16 | Toshiba Corp | Ｆｉｆｏ制御回路 |
| US8019779B2 (en) * | 2004-05-04 | 2011-09-13 | International Business Machines Corporation | Efficient locking protocol for sub-document concurrency control using prefix encoded node identifiers in XML databases |
| KR20050114021A (ko) * | 2004-05-31 | 2005-12-05 | 엘지전자 주식회사 | 비동기 이동통신시스템의 단문메시지 착신전환방법 |
| JP4784245B2 (ja) * | 2005-10-04 | 2011-10-05 | ソニー株式会社 | コンテンツ処理装置，サーバ装置，通信方法およびコンピュータプログラム |
| TWI446351B (zh) * | 2010-05-27 | 2014-07-21 | Wistron Corp | 資料寫入方法與電腦系統 |
| JP5618805B2 (ja) * | 2010-12-10 | 2014-11-05 | スパンションエルエルシー | 通信装置、ネットワークシステム及び通信方法 |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07105804B2 (ja) | 1992-04-22 | 1995-11-13 | 宮崎 誠一 | アドレス設定器 |
| US6219697B1 (en) | 1997-05-02 | 2001-04-17 | 3Com Corporation | Method and apparatus for operating the internet protocol over a high-speed serial bus |
| KR19990044988A (ko) * | 1997-11-25 | 1999-06-25 | 이데이 노부유끼 | 접속 상황 송신 장치, 접속 상황 표시 데이터 작성 장치 및 접속 상황 표시 방법 |
| JP2001103076A (ja) | 1999-09-29 | 2001-04-13 | Fujitsu Ltd | Ｉｅｅｅ１３９４バス解析方法及びインタフェース回路 |
| US6519544B1 (en) * | 1999-09-29 | 2003-02-11 | Fujitsu Limited | Method and apparatus for IEEE 1394 bus analysis |
| JP2001168915A (ja) * | 1999-12-10 | 2001-06-22 | Nec Corp | Ｉｐパケット転送装置 |
| US20040213237A1 (en) * | 2000-06-29 | 2004-10-28 | Toshikazu Yasue | Network authentication apparatus and network authentication system |
| US7164689B2 (en) * | 2000-12-05 | 2007-01-16 | Matsushita Electric Industrial Co., Ltd. | Multi-initiator control unit and method |
| JP2002247094A (ja) * | 2001-02-20 | 2002-08-30 | Pioneer Electronic Corp | パケット送出装置および方法 |
| JP4481518B2 (ja) * | 2001-03-19 | 2010-06-16 | 株式会社日立製作所 | 情報中継装置及び転送方法 |
-
2002
- 2002-03-11 JP JP2002066010A patent/JP3647815B2/ja not_active Expired - Fee Related
-
2003
- 2003-03-10 US US10/383,635 patent/US7352742B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20030210709A1 (en) | 2003-11-13 |
| US7352742B2 (en) | 2008-04-01 |
| JP2003264560A (ja) | 2003-09-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0930747A1 (en) | IEEE 1394 Serial bus system using a mapping table for identifying nodes having required capabilities to establish isochronous connections | |
| JP4278439B2 (ja) | 情報通信装置、そのシステム、その方法、そのプログラム、および、そのプログラムを記録した記録媒体 | |
| US6810452B1 (en) | Method and system for quarantine during bus topology configuration | |
| EP1051000B1 (en) | Method and device for allocating at least one routing identifier to at least one bridge in a network | |
| US6823408B2 (en) | Electronic equipment, and method for controlling state of physical layer circuit therefor | |
| CN100359881C (zh) | 用于通过透明网桥传输分组的地址分配方法和设备 | |
| WO2000057283A1 (en) | A method and system for circumscribing a topology to form ring structures | |
| JP3647815B2 (ja) | 通信方法および通信装置 | |
| US6647446B1 (en) | Method and system for using a new bus identifier resulting from a bus topology change | |
| EP1091523B1 (en) | Speed converter for IEEE-1394 serial bus network | |
| 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 | |
| US6502158B1 (en) | Method and system for address spaces | |
| US7580420B2 (en) | Interface circuit connecting a device with a bridge portal function to a communication bus | |
| US20010028656A1 (en) | Information signal processing apparatus and method | |
| JP3683227B2 (ja) | ローカルバスブリッジ | |
| WO2000057263A1 (en) | A method and system for a multi-phase net refresh on a bus bridge interconnect | |
| JP4502653B2 (ja) | パケット送受信装置及びそれに用いるパケット識別方法 | |
| JP3749625B2 (ja) | ノード管理方法、ネットワークアダプタ、及び記録媒体 | |
| JP4529231B2 (ja) | 電子機器 | |
| JP4062829B2 (ja) | シリアルインタフェース回路 | |
| JP2000013399A (ja) | ネットワーク機器識別方法 | |
| JP3365262B2 (ja) | 通信プロトコル処理装置 | |
| JP4244474B2 (ja) | 情報処理装置及び方法 | |
| KR19990076150A (ko) | 아이 트리플 이 1394 망에서의 노드 아이디 관리방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20040816 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040824 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041021 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041116 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050105 |
|
| 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: 20050201 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050209 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080218 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090218 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100218 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100218 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110218 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |