JP2001333136A

JP2001333136A - 通信装置、データ通信システム、通信制御方法、記憶媒体

Info

Publication number: JP2001333136A
Application number: JP2000148886A
Authority: JP
Inventors: Takuya Tsujimoto; 卓哉辻本
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2000-05-19
Filing date: 2000-05-19
Publication date: 2001-11-30

Abstract

(57)【要約】【課題】、受信側ノードのパケット処理能力にあわせ
た送信側ノードのパケット送信を可能とし、リトライ間
隔と回数を適切に設定することにより、無効なトラフィ
ックを低減して、バスシステム全体のパフォーマンスを
向上させる。【解決手段】ネットワーク上のノード間で非同期転送
モードによってデータを授受するための通信制御方法
は、非同期転送モードで送信したパケットの受信側ノー
ドの受信状況を判断して(Ｓ101,Ｓ102,Ｓ103)、パケッ
トが受信できないとき送信側ノードが再度、同一データ
パケットを送信する（Ｓ107)。再送によるパケットの再
送回数をカウントして、その値が設定回数以上のとき
(Ｓ106）、送信側ノードは再送パケットではない次に送
信すべき新規パケットの送信分から、パケットの再送間
隔を変更する(Ｓ116,Ｓ117)。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、シリアルバスイン
タフェース、特にＩＥＥＥ１３９４の規格に準拠したイ
ンタフェースを持つ通信装置、通信システムおよび通信
制御方法に関するものである。

【０００２】

【従来の技術】近年シリアルバスインタフェースが、信
号線が少ないこと、ケーブルが細いこと、コネクタが小
さいこと、ＩＤやターミネータ等の設定が不要なこと、
活線挿抜が可能なこと、等時性のあるデータ転送（アイ
ソクロナス転送）が可能なことなどの優れた特徴をもつ
ことから脚光を浴びてきている。

【０００３】特にＩＥＥＥ１３９４のシリアルバスイン
タフェースは、動画像等の大容量データの高速伝送が可
能であること、バスアーキテクチャによってメモリアク
セスが可能であること、ホットプラグインやプラグアン
ドプレイが可能であること、およびピア・ツー・ピア接
続が可能であることなどの特徴を持つことによって、パ
ーソナルコンピュータだけでなく家庭内のＡＶ機器（デ
ィジタルビデオカメラ等）やそれ以外の機器への適用が
盛んに進められている。

【０００４】また、更なる高速化や長距離化に対応した
新たな規格の策定も現在精力的に進められている。

【０００５】ＩＥＥＥ１３９４では、周期的に連続した
時間の中である一定の帯域を保証しエラー発生時に再送
手続きを行わないデータ転送モードであるアイソクロナ
ス転送と、帯域の保証はしないがエラー発生時には再送
手続きにより確実なデータの転送を保証する転送モード
であるアシンクロナス転送という二つの転送モードを備
えている。ディジタルビデオカメラなどに見られる大容
量の動画像データの転送にはアイソクロナス転送が、ス
トレージデバイスやプリンタ、スキャナなどのデータ落
ちが許されないデバイスへの転送にはアシンクロナス転
送が使用される。転送モードの優先順位としてはアイソ
クロナス転送の方が高いため、アシンクロナス転送はア
イソクロナス転送で使用してない余った帯域を使うこと
になる。またアシンクロナス転送では受信側ノードがパ
ケットを受信できない状態のとき（ビジー状態）、パケ
ットを再送することを可能とするリトライプロトコルを
備えている。

【０００６】

【発明が解決しようとする課題】しかしながら上述した
従来の技術においては、ＩＥＥＥ１３９４のバスインタ
フェースにそれこそ様々な種類のデバイスが接続される
ため、異なるパケット受信処理能力を持つデバイス間で
通信を行う際に以下のような問題が発生することにな
る。

【０００７】例えば、受信側ノードのパケット処理能力
以上の頻度（もしくは間隔）でパケットを連続して送信
した場合、受信側ノードは受信したパケットを処理して
いる最中に次のパケットを受信することになり、最終的
には処理が間に合わずビジー状態となる。また受信側ノ
ードがビジー状態になっているときに、確実な転送を行
うためパケットの再送（リトライ）を頻繁に行えば、無
効なトラフィックの増大をうむことになる。これはある
ひとつのデータを送るのに通常は１回のパケット送信で
済む場合を考えれば、ビジーの状態にも関わらず同じデ
ータを何回も繰り返し送信するということから理解でき
よう。アイソクロナス転送の合間の余った帯域を使用す
る転送モードであるアシンクロナス転送を使ってこのよ
うな無用なパケットを複数送信することはシステム全体
のパフォーマンスをも下げることにつながる。かといっ
てリトライを行わなければ確実なデータの転送を行うこ
とはできない。

【０００８】これらはアシンクロナス転送を行う際、各
々のノードでパケットを受信処理する時間が異なるから
で、さらにその受信側ノードの処理時間に関する情報を
送信側ノードが把握する手段を持たないことも原因の一
つであると考えられる。

【０００９】また、トランザクションレイヤで管理する
リトライ処理がＬＩＮＫチップなどのハードウエアによ
って実現されている場合は、リトライパケットの送信間
隔が短いために直ぐにリトライオーバーとなり、アプリ
ケーションレイヤで再度トランザクションを発行するべ
きか否か、つまりアプリケーションレイヤで管理するリ
トライ処理（同一のデータを扱っていてもトランザクシ
ョンとしＨては別のものとなる）を行なうかどうかの判
断が求められるが一つのトランザクションが受信ノード
がビジーのために短い時間内で受信失敗に終わることか
らのみでは、相手ノードの処理能力を測ることは困難で
ある。

【００１０】リトライ回数が多ければ、他のデバイスが
使用する帯域を圧迫し、逆に少なければ転送が成功する
確実性を下げることにつながるなど、パケットの送信と
帯域の有効利用を同時に満足することは困難である。

【００１１】

【課題を解決するための手段】上記の課題を解決するべ
く、本発明にかかる通信装置等においては、主として、
受信側ノードのパケット処理能力にあわせた送信側ノー
ドのパケット送信を可能とし、リトライ間隔と回数を適
切に設定することにより、無効なトラフィックを低減し
て、バスシステム全体のパフォーマンスを向上させるこ
とを目的とするものである。

【００１２】また、予め受信側ノードからアシンクロナ
ス転送によるパケット受信時の処理能力もしくは処理時
間を把握しておく必要や手間が不要となり、ＩＥＥＥ１
３９４プロトコルの範囲内でより確実なパケット送信を
行なうことも可能とする。

【００１３】上記課題を解決して、その目的を達成する
べく、本発明にかかる通信装置、通信制御方法、データ
通信システム及び記憶媒体は主として以下のような構成
を備えることを特徴とする。

【００１４】すなわち、ネットワーク上のノード間で非
同期転送モードによってデータを授受する通信装置は、
非同期転送モードで送信したパケットの受信側ノードの
受信状況を判断する手段と、前記送信したパケットが受
信できないとき送信側ノードが再度、同一データパケッ
トを送信する再送手段と、前記再送手段によるパケット
の再送回数をカウントする手段と、前記再送回数をカウ
ントする手段によるカウント値が設定回数以上のとき、
送信側ノードは再送パケットではない次に送信すべき新
規パケットの送信分から、パケットの再送間隔を変更す
る手段と、を備えることを特徴とする。

【００１５】あるいは、ネットワーク上のノード間で非
同期転送モードによってデータを授受する通信装置は、
非同期転送モードで送信したパケットの受信側ノードの
受信状況を判断する手段と、前記送信したパケットが受
信できないとき、アプリケーションレイヤの管理で再度
同一データパケットを送信する再送手段と、前記再送手
段によるパケットの再送回数をカウントする手段と、前
記再送回数をカウントする手段によるカウント値が設定
回数以上のとき、送信側ノードは再送パケットではない
次に送信すべき新規パケットの送信分から、トランザク
ションレイヤの管理でパケットの再送間隔を変更する手
段と、を備えることを特徴とする。

【００１６】あるいは、ネットワーク上のノード間で非
同期転送モードによってデータを授受する通信装置は、
非同期転送モードで送信したパケットの受信側ノードの
受信状況を判断する手段と、前記送信したパケットが受
信できないとき、アプリケーションレイヤの管理で再度
同一データパケットを送信する再送手段と、前記再送手
段によるパケットの再送回数をカウントする手段と、前
記再送回数をカウントする手段によるカウント値が設定
回数以上のとき、送信側ノードは再送パケットではない
次に送信すべき新規パケットの送信分から、前記再送手
段によって送信されるパケットの再送間隔を変更する手
段と、を備えることを特徴とする。

【００１７】あるいは、ネットワーク上のノード間で非
同期転送モードによってデータを授受する通信装置は、
バスリセットを検出するための手段と、前記検出手段に
よる検出に従い、ネットワークのコンフィグレーション
を判断する構成判断手段と、前記構成判断手段の判断に
より、バスが２つのノードで構成される場合もしくは、
ノード数が２を超える場合で、かつ、そのバスを構成す
るノードの中にバスマネージャ若しくはアイソクロナス
リソースマネージャの機能を有するノードが存在しない
場合は、トランザクションレイヤで管理するリトライ回
数をプロトコルで規定された最大値に設定する手段と、
を備えることを特徴とする。

【００１８】あるいは、ネットワーク上のノード間で非
同期転送モードによってデータを授受する通信装置は、
非同期転送モードで送信されたパケットを連続して受信
して格納する受信バッファと、前記受信バッファに格納
できるパケットの個数情報を予め格納しておく格納手段
と、前記格納された個数情報に従いパケットの送信を制
御する手段と、を備えることを特徴とする。

【００１９】あるいは、ネットワーク上のノード間で非
同期転送モードによってデータを授受する通信装置は、
非同期転送モードで送信されたパケットを連続して受信
して格納する受信バッファと、前記受信バッファのサイ
ズを予め格納しておく格納手段と、前記格納されたバッ
ファのサイズに従ってパケットの送信を制御する送信制
御手段と、を備えることを特徴とする。

【００２０】あるいは、ネットワーク上のノード間で非
同期転送モードによってデータを授受する通信装置は、
非同期転送モードで送信するパケットの受信側ノードに
おける処理能力情報を予め格納しておく記憶手段と、前
記予め格納された処理能力情報に基づき、送信したパケ
ットの処理状況を判定する判定手段と、前記判定手段の
判定に従い、パケットの送信を制御する制御手段と、を
備えることを特徴とする。

【００２１】あるいは、ネットワーク上のノード間で非
同期転送モードによってデータを授受する通信装置は、
特定のトランザクションリクエストに基づくパケット送
信からレスポンスパケットを受信するまでの時間を計測
する計測手段と、前記計測手段による計測時間から受信
側ノードの処理能力を推定する推定手段と、前記推定手
段による処理能力の推定結果に従って、パケットの送信
を制御する制御手段と、を備えることを特徴とする。

【００２２】また、ネットワーク上のノード間で非同期
転送モードによってデータを授受するための通信制御方
法は、非同期転送モードで送信されたパケットの受信側
ノードの受信状況を判断する工程と、前記送信されたパ
ケットが受信できないとき送信側ノードが再度、同一デ
ータパケットを送信する再送工程と、前記再送工程によ
るパケットの再送回数をカウントする工程と、前記再送
回数をカウントする工程によるカウント値が設定回数以
上のとき、送信側ノードは再送パケットではない次に送
信すべき新規パケットの送信分から、パケットの再送間
隔を変更する工程と、を備えることを特徴とする。

【００２３】あるいは、ネットワーク上のノード間で非
同期転送モードによってデータを授受する通信制御方法
は、非同期転送モードで送信されたパケットの受信側ノ
ードの受信状況を判断する工程と、前記送信されたパケ
ットが受信できないとき、アプリケーションレイヤの管
理で再度同一データパケットを送信する再送工程と、前
記再送工程によるパケットの再送回数をカウントする工
程と、前記再送回数をカウントする工程によるカウント
値が設定回数以上のとき、送信側ノードは再送パケット
ではない次に送信すべき新規パケットの送信分から、ト
ランザクションレイヤの管理でパケットの再送間隔を変
更する工程と、を備えることを特徴とする。

【００２４】あるいは、ネットワーク上のノード間で非
同期転送モードによってデータを授受する通信制御方法
は、非同期転送モードで送信されたパケットの受信側ノ
ードの受信状況を判断する工程と、前記送信されたパケ
ットが受信できないとき、アプリケーションレイヤの管
理で再度同一データパケットを送信する再送工程と、前
記再送手段によるパケットの再送回数をカウントする工
程と、前記再送回数をカウントする工程によるカウント
値が設定回数以上のとき、送信側ノードは再送パケット
ではない次に送信すべき新規パケットの送信分から、前
記再送工程によって送信されるパケットの再送間隔を変
更する工程と、を備えることを特徴とする。

【００２５】あるいは、ネットワーク上のノード間で非
同期転送モードによってデータを授受する通信制御方法
は、バスリセットを検出するための工程と、前記検出工
程による検出に従い、ネットワークのコンフィグレーシ
ョンを判断する構成判断工程と、前記構成判断工程の判
断により、バスが２つのノードで構成される場合もしく
は、ノード数が２を超える場合で、かつ、そのバスを構
成するノードの中にバスマネージャ若しくはアイソクロ
ナスリソースマネージャの機能を有するノードが存在し
ない場合は、トランザクションレイヤで管理するリトラ
イ回数をプロトコルで規定された最大値に設定する工程
と、を備えることを特徴とする。

【００２６】あるいは、ネットワーク上のノード間で非
同期転送モードによってデータを授受するための通信制
御方法は、非同期転送モードで送信されたパケットを連
続して受信して受信バッファに格納する工程と、前記受
信バッファに格納できるパケットの個数情報を予めメモ
リに格納しておく格納工程と、前記格納された個数情報
に従いパケットの送信を制御する工程と、を備えること
を特徴とする。

【００２７】あるいは、ネットワーク上のノード間で非
同期転送モードによってデータを授受する通信制御方法
は、非同期転送モードで送信されたパケットを連続して
受信して受信バッファに格納する工程と、前記受信バッ
ファのサイズを予めメモリに格納しておく格納工程と、
前記格納されたバッファのサイズに従ってパケットの送
信を制御する送信制御工程と、を備えることを特徴とす
る。

【００２８】あるいは、ネットワーク上のノード間で非
同期転送モードによってデータを授受するための通信制
御方法は、非同期転送モードで送信するパケットの受信
側ノードにおける処理能力情報を予めメモリに格納して
おく記憶工程と、前記予めメモリに格納された処理能力
情報に基づき、送信したパケットの処理状況を判定する
判定工程と、前記判定工程の判定に従い、パケットの送
信を制御する制御工程と、を備えることを特徴とする。

【００２９】あるいは、ネットワーク上のノード間で非
同期転送モードによってデータを授受するための通信制
御方法は、特定のトランザクションリクエストに基づく
パケット送信からレスポンスパケットを受信するまでの
時間を計測する計測工程と、前記計測工程による計測時
間から受信側ノードの処理能力を推定する推定工程と、
前記推定工程による処理能力の推定結果に従って、パケ
ットの送信を制御する制御工程と、を備えることを特徴
とする。

【００３０】また、データ通信システムは、ネットワー
ク上のノード間で非同期転送モードによってデータを送
信する上記のいずれかに記載の通信装置と、前記通信装
置によって送信されたデータを受信処理する装置と、を
有する。

【００３１】また、ネットワーク上のノード間で非同期
転送モードによってデータを授受するための通信制御方
法をコンピュータで実行するためのプログラムコードを
格納した記憶媒体であって、該プログラムコードが、上
記のいずれかに記載の通信制御方法の工程のコードを有
することを特徴とする。

【００３２】

【発明の実施の形態】（第１実施形態）本発明の実施形
態を図に従って説明する。図１は、第１実施形態におけ
るリトライ間隔および送信間隔設定処理の流れを示すフ
ローチャートである。

【００３３】ステップＳ１０１では、バスのアービトレ
ーションによってバスの占有が許可された場合に受信側
ノードに対して非同期、つまりアシンクロナス転送によ
るパケットの送信を行う。

【００３４】ステップＳ１０２では、受信側ノードが送
信したパケットを受け取れない、つまりビジーの状態か
どうかを判断する。判断は送信したパケットに対するＡ
ＣＫで行う。ビジーの場合はステップＳ１０６へ、受信
側ノードがパケットを受け取れた場合はステップＳ１０
３へすすむ。

【００３５】ステップＳ１０３では、戻ってきたＡＣＫ
からエラーが発生したかどうかを判断する。具体的には
データがエラーだったかどうか、ＡＣＫが戻ってきたか
どうかなど正常にパケットを受け取れたかどうかで処理
を分岐させる。正常にパケットを受け取ったというコン
プリートのＡＣＫおよびパケットは受け取ったけれど処
理は保留中であるというペンディングのＡＣＫを受け取
ったときはステップＳ１０５へ、エラーが発生したとき
はステップＳ１０４へすすむ。

【００３６】ステップＳ１０４では、エラーの処理を行
う。受け取ったＡＣＫから判断してエラーだとわかった
ときは、トランザクションレイヤからその上位レイヤで
あるアプリケーションレイヤにその旨伝える。アプリケ
ーションレイヤは再度データを送信するなどのリカバリ
ーの処理を行う。

【００３７】ステップＳ１０５では、一つ前にアシンク
ロナス転送モードでパケットを送信した送信先ノードに
対して続けて送信するデータがあるかどうかを判断す
る。送信するデータがまだ存在する場合はステップＳ１
０１へ戻り再び受信側ノードに対してアシンクロナス転
送でパケットを送信する。同一ノードに対して送信する
データがない場合は、このリトライおよび送信間隔設定
処理を終了する。

【００３８】ステップＳ１０６では、リトライの回数が
次の再送で何回目になるのかを把握し、その回数がＮ回
以上になるかどうかを判断する。Ｎは２以上の自然数で
上限はＩＥＥＥ１３９４の規格にあるリトライ値の最大
値（１５）以下の各ノードで設定した値となる。ここで
は例としてＮ＝２として考える。Ｎ＝２となるのは次の
リトライで２回目の再送なので、既に同じパケットを２
回送信しているということである。（１回目は普通の送
信、２回目は初めてのリトライである。）リトライ回数
が次回でＮ回となる場合はステップＳ１０８へ、Ｎ回未
満の時はステップＳ１０７へすすむ。

【００３９】１回目の通常のパケット送信でビジーとな
り、次のリトライでもビジーの場合には、受信側ノード
は次のどれかの状態にあると考えられる。

【００４０】一つ目はデバイス自身がビジーになってし
まったためパケットが受信できない状態である。例とし
て相手ノードをプリンタとして考えてみる。プリントデ
ータの転送の際に印字部での処理がインタフェースのス
ループットに比べて遅いと、印字部でいくらかのバッフ
ァを持っていたとしても処理が間に合わず、印字部がデ
ータをある程度受け入れられる状態になるまでインタフ
ェースからの入力を制限するようになる。

【００４１】二つ目は以前に送信したパケットの処理が
まだ済んでいない場合である。一つ前に送信元ノードか
ら送ったパケット、もしくはたまたま送信側ノードから
送られるパケット受信前に別のノードから送られたパケ
ットを処理し切れていない場合などがそれに当たる。受
信側ノードがアシンクロナス転送によるパケットを格納
できるＦＩＦＯを一つしか持たず、その前に受信したパ
ケットをＦＩＦＯから抜き出す前に次のパケットを受信
しようとした場合がそれに該当する。

【００４２】三つ目は受信側ノードで致命的なエラーが
発生して受信不能に陥った場合である。この三つ目は何
らかの手段をこうじてデバイスが正常動作をする状態に
戻してやる必要があるが、一つ目および二つ目の場合
は、受信側ノードのパケット処理時間および能力と送信
側ノードのパケット送信タイミングまたは送信間隔のミ
スマッチによるものである。本特許はこの二つの状態を
解消し、システム全体としてのパフォーマンスを向上さ
せるものである。

【００４３】ステップＳ１０７では、受信側ノードへ同
一パケットを再度送信するリトライ処理を行う。

【００４４】ステップＳ１０８では、ステップＳ１０７
と同様にリトライ処理を行う。

【００４５】ステップＳ１０９では、ステップＳ１０２
と同様に受信側ノードが送信したパケットを受け取れな
い、つまりビジーの状態かどうかを判断する。ビジーの
場合はステップＳ１１２へ、受信側ノードがパケットを
受け取れた場合はステップＳ１１０へすすむ。

【００４６】ステップＳ１１０では、ステップＳ１０３
と同様に戻ってきたＡＣＫからエラーが発生したかどう
かを判断する。正常にパケットを受け取ったもしくは保
留中の場合はステップＳ１１５へ、エラーが発生したと
きはステップＳ１１１へすすむ。

【００４７】ステップＳ１１１では、ステップＳ１０４
と同様にエラーの処理を行う。

【００４８】ステップＳ１１２では、これらか行おうと
しているリトライの回数が各ノードで設定したリトライ
回数の最大値を越えるかどうか、つまりリトライオーバ
ーとなるかどうかを判断する。リトライオーバーの場合
はステップＳ１１３へすすみ、まだリトライ可能な場合
はステップＳ１０８へ戻りパケットの再送を行う。

【００４９】ステップＳ１１３では、トランザクション
レイヤで管理しているリトライの回数を超えても受信側
ノードがパケットを受け取れないビジーの状態であるの
を受けて、アプリケーションレイヤのレベルでリトライ
を行うかどうか、つまり同じデータを別のトランザクシ
ョンとして相手ノードに送信するかどうかを判断する。
アプリケーションレベルでのリトライを行う場合はステ
ップＳ１１４の処理を終えた後、ステップＳ１０１へ戻
り、パケットの送信を行う。リトライを行わない場合は
ステップＳ１１５へすすむ。

【００５０】ステップＳ１１４では、受信側ノードへ同
一パケットを再度送信するリトライ処理を行うための準
備を行う。具体的にはアプリケーションレイヤで何度の
リトライを行ったかという情報の格納をする。その後、
パケットの送信処理を行うステップＳ１０１へ戻る。

【００５１】ステップＳ１１５では、ステップＳ１０５
と同様に一つ前にアシンクロナス転送モードでパケット
を送信した送信先ノードに対して、続けて送信するデー
タがあるかどうかを判断する。送信するデータがまだ存
在する場合はステップＳ１１６ヘすすみ、同一ノードに
対して送信するデータがない場合にはステップＳ１１７
へすすむ。

【００５２】ステップＳ１１６では、同一ノードに対し
て送信すべきデータがまだ存在することを受けて、次回
のトランザクション発行時から通常の転送を行う際のパ
ケットの送信間隔およびビジーの際のトランザクション
レイヤで管理するべき再送（リトライ）間隔を設定す
る。この設定はＮ回以上のリトライを行った特定ノード
に対してのみ行われる。具体的には複数の再送および送
信間隔時間の設定値をテーブルとして持ち、現在設定さ
れている再送および送信間隔時間よりも大きい値を設定
する。もしくは何度のリトライを行ったか（トランザク
ションレベルおよびアプリケーションレベルのリトライ
を含めて）等の情報をもとに、現在設定されている値よ
りも大きな値を計算し設定することも可能である。再送
を行うまでの時間を長くとることで最終的に再度のリト
ライによっても相手ノードにパケットを送信できないな
どの状態を防ぐことができる可能性も高くなる。また、
同一ノードに対して上記判断ルーチンを通るたびにさら
に大きな値を設定することも可能である。

【００５３】ステップＳ１１７では、ステップＳ１１６
と同一の手法により、次回トランザクション発行時から
ビジーの際のトランザクションレイヤで管理するべきリ
トライの間隔を設定する。

【００５４】これらの処理過程を経ることで、受信側ノ
ードの処理能力にあわせたパケット送信が可能となり、
無効なトラフィックを低減し、バスシステム全体のパフ
ォーマンスを向上させられる。

【００５５】図２は、ＩＥＥ１３９４の各レイヤの構成
図である。この構成は以下に示す実施形態全てにおいて
共通の構成であり、第２実施形態以降の説明においては
重複するので省略する。

【００５６】２０１は、ＩＥＥＥ１３９４インタフェー
スに対応するノードである。図に示されるように、ハー
ドウェアとファームウェアおよびソフトウェアに分けら
れ、さらにそれぞれの部分は以下に説明される２０２か
ら２０６の各レイヤによって構成される。ここでのハー
ドウェアは実質的なインタフェースチップを示してい
る。

【００５７】２０２は、ＰＨＹレイヤもしくはフィジカ
ルレイヤ（物理層）と呼ばれるＩＥＥＥ１３９４インタ
フェース上の信号を直接ドライブする機能を実現するＬ
ＳＩである。

【００５８】２０３は、ＩＥＥＥ１３９４の規格上でＬ
ＩＮＫレイヤもしくはリンクレイヤ（リンク層）と呼ば
れる機能と、トランザクションレイヤ２０４およびＰＨ
Ｙレイヤ２０２とのインタフェースとを備えたＬＳＩで
ある。

【００５９】２０４は、トランザクションレイヤと呼ば
れるＩＥＥＥ１３９４インタフェースに対して実際のオ
ペレーションを管理・実行するドライバである。このレ
イヤで、ＩＥＥＥ１３９４インタフェース上で行われる
リード／ライト／ロックのトランザクションを管理す
る。また後述する受信側ノードがビジーの場合の再送
（リトライ）要求もこのレイヤで管理する。

【００６０】このトランザクションレイヤで管理するべ
きリトライ機能をリンクレイヤ２０３の中に実装してい
るＬＳＩも存在する（つまりビジーの場合にはハードウ
ェアが指定した回数分だけ自動的にリトライを行ってく
れる）が、今後の説明では、トランザクションレイヤで
管理するリトライはトランザクションレイヤを構成する
ファームウェアによって実現することを想定する。また
ハードウェアでリトライを行う場合についても後ほど説
明する。

【００６１】２０５は、シリアルバスマネージメント
（ＳＢＭ）を行うレイヤで、ＩＥＥＥ１３９４インタフ
ェースの管理用ドライバである。ＣＳＲ（コントロール
アンドステータスレジスタ）およびコンフィグレーショ
ンＲＯＭの実装・管理を行うノードコントローラ機能の
他、オプションとしてアイソクロナスリソースマネージ
ャおよびバスマネージャの機能を有する。

【００６２】２０６は、ＩＥＥＥ１３９４インタフェー
スを利用した各種デバイスの機能、例えばプリンタやス
キャナやディジタルビデオカメラ等の機能を実現するソ
フトウェアと、トランザクションレイヤおよびシリアル
バスマネージメントレイヤとのインタフェースを備えた
アプリケーションソフトウェアである。

【００６３】図３は、第１実施形態におけるトランザク
ションレイヤ内の機能ブロック図である。

【００６４】この図に示されているのはトランザクショ
ンレイヤのすべての機能ではなく、本発明に必要なもし
くは使用する機能に限定されている。

【００６５】３０１は、トランザクションレイヤを構成
するファームウェアとのやりとりをするためのＬＩＮＫ
Ｉ／Ｆである。実際にはファームウェアがリンクレイ
ヤを実現するＬＳＩのレジスタにアクセスしたり、割り
込みを受けることによってやりとりを行う。

【００６６】３０２は、ＡＣＫ処理部である。送信した
パケットに対してどのようなＡＣＫが戻ってきたのかを
判断する。具体的にはＡＣＫがコンプリートの場合とペ
ンディングの場合はアプリケーションレイヤにある送信
リクエスト部３０３へ、エラーの場合はアプリケーショ
ンレイヤにあるエラー処理部３０５へ、ビジーの場合は
カウンタ３０７へ伝えられる。

【００６７】３０３は、先に転送したパケットが正常に
受信されたことを受けて次のパケットを送信するか否か
を決定する送信リクエスト部である。ＩＥＥＥ１３９４
インタフェース上に接続されたデバイスに対して転送す
るデータが存在する場合は、送信のリクエストを発行す
る。

【００６８】３０４は、送信リクエスト部３０３からの
要求を受けてパケットを生成し、相手ノードに対して送
信する送信処理部である。ここで生成されたパケットは
ＬＩＮＫＩ／Ｆ３０１を経由してバス上に流れる。

【００６９】３０５は、先に転送したパケットの送信に
際してデータエラーやＡＣＫが返らなかったことを受け
てエラーの処理を行う。

【００７０】３０６は、アプリケーションレイヤレベル
で再度同一のパケットを送信するかどうかを判断、決定
するアプリケーションリトライ処理部である。再度パケ
ットを送信する場合は送信リクエスト部３０３にその要
求を伝える。

【００７１】３０７は、現在行っているトランザクショ
ンに対して何回のリトライ処理が行われた（もしくはこ
れから行うか）をカウントするカウンタである。

【００７２】３０８は、カウンタ３０７の値をもとに再
送間隔および送信間隔の値を新たに設定し直すかどうか
を判断する判断制御部である。そのアルゴリズムについ
ては図１の説明で述べているので省略する。判断制御部
ではその他に、ビジーによるリトライアクションの実行
を伝えたり、ビジーの回数が最大再送回数を超えたとき
にはアプリケーションリトライ処理部３０６に伝える。

【００７３】３０９は、リトライ処理部である。前回送
信したのと同一パケットを相手ノードに対して送信す
る。

【００７４】３１０は、再送および送信の間隔を規定す
るためのタイマである。タイマの発するタイミングで送
信処理部３０４およびリトライ処理部３０９はパケット
を送出する。

【００７５】３１１は、再送間隔および送信間隔を設定
する。設定方法に関しては既に図１の説明で述べている
ので省略する。

【００７６】３１２は、再送間隔および送信間隔を設定
するための値を格納したテーブルである。テーブルに持
つ値は予め規定してもいいし、後から設定してもよい。

【００７７】この構成はトランザクションレイヤで管理
するリトライをファームウェアによって実現することを
想定している。そこで先程述べたように自動的にリトラ
イするハードウェア（例えばリンクチップ等）を使用す
る場合を考えてみる。

【００７８】リトライ回数を設定してハードウェアが自
動的に再送を行う構成をとる場合でも、タイマ等を利用
することでその送信タイミングをファームウェアで制御
可能な構成であれば本実施形態を実現することが可能で
ある。チップの仕様により、ある定められた間隔でしか
送信できない場合には、アプリケーションレイヤで管理
するリトライのみ考慮してパケットの送信間隔を制御す
ることになる。もしくは、ハードウェアによるリトライ
回数を０にセットし、リトライオーバーの割り込みを受
けてソフトウェアでトランザクションレイヤで管理する
リトライを行う構成にすること可能である。

【００７９】さらには、リトライ回数を実質的に増やす
対応も考えられる。

【００８０】図４は第１実施形態における再送間隔およ
び送信間隔を示す模式図である。

【００８１】（ａ）は本発明を利用しない場合のアシン
クロナス転送によるパケット送信を図示したものであ
る。

【００８２】４０１は、アシンクロナス転送のパケット
である。Ｙ軸として書かれているのは時間軸で４０１の
パケットは便宜的にＭ−１番目のパケットとする。パケ
ットの送信が正常に終了した場合、次のパケットを送信
するまでの時間をＴ１とする。

【００８３】４０２は、受信側ノードがビジーの場合の
再送パケットである。その前のＭ番目のパケット送信が
ビジーなのを受けて再送される。再送されるまでの時間
をＴ２とする。この例では３回のリトライを行うものと
し、３回目のリトライ後次のデータを送信しているもの
とする。リトライ終了から次のパケットを送信するまで
の間隔はＴ１である。

【００８４】（ｂ）は本実施形態を適用した場合のパケ
ット送信を図示したものである。この例ではビジーの際
のリトライ間隔を変更した後の状態を示している。具体
的には再送までの時間がＴ２からＴ３に変更されてお
り、この場合はＴ２＜Ｔ３である。またリトライ終了か
ら次のパケットを送信するまでの間隔はＴ１と変わらな
い。これは設定変更時に同一ノードに対して送信すべき
データがない場合の例である。また、送信すべきデータ
が存在する場合においてもその前のリトライ処理の際、
アプリケーションレイヤで管理するリトライを行うかど
うか判断するところまで処理がいかない、つまりリトラ
イオーバーが発生する前に正常にパケットを送信できた
場合にも図のように送信間隔を変更する必要はない。

【００８５】（ｃ）は、（ｂ）と同様に本実施形態を適
用した場合で、送信の間隔を変更した後の状態を示して
いる。具体的には送信までの時間がＴ１からＴ４に変更
されており、この場合はＴ１＜Ｔ４である。またビジー
の際のリトライ間隔はＴ２と変わらない。これは図３の
説明の最後で述べたようにハードウェアでビジーの際の
リトライを行う構成を考えたものである。

【００８６】（ｄ）は、（ｂ）、（ｃ）と同様に本実施
形態を適用した場合で、ビジーの際のリトライ間隔およ
びパケット送信間隔の両方を変更した後の状態を示した
ものである。

【００８７】このように（ａ）の場合と比べて、（ｂ）
〜（ｄ）のどの例でもあるスパンを考えた場合にはパケ
ットの送信数が減っていることがわかる。

【００８８】以上説明してきたように本実施形態の構成
によって、受信側ノードの処理能力にあわせたパケット
送信が可能となり、無効なトラフィックを低減し、バス
システム全体のパフォーマンスを向上させることが可能
になる。

【００８９】またＩＥＥＥ１３９４プロトコルの範囲内
でより確実なパケット送信を行うことが可能になる。ま
たこれらの実現に際し、予め受信側ノードからアシンク
ロナス転送によるパケット受信時の処理能力もしくは処
理時間を把握しておく必要も手間もいらない。

【００９０】（第２実施形態）第２実施形態を図面に従
って説明する。図５は第２実施形態における送信間隔、
リトライ間隔および送信間隔設定処理の流れを示すフロ
ーチャートである。

【００９１】ステップＳ５０１では、バスのアービトレ
ーションによってバスの占有が許可された場合に受信側
ノードに対して非同期、つまりアシンクロナス転送によ
るパケットの送信を行う。

【００９２】ステップＳ５０２では、受信側ノードが送
信したパケットを受け取れない、つまりビジーの状態か
どうかを判断する。判断は送信したパケットに対するＡ
ＣＫで行う。ビジーの場合はステップＳ５０３へ処理を
進め、受信側ノードがパケットを受け取れた場合はステ
ップＳ５０９へ処理を進める。

【００９３】ステップＳ５０３では、今回で何回目のリ
トライ処理になるかをカウントする。ここでのリトライ
処理はトランザクションレイヤが管理するレベルのもの
である。

【００９４】ステップＳ５０４では、ステップＳ５０３
でカウントしたカウント値が各ノードで設定した１トラ
ンザクションのリトライ回数を超えるかどうか、つま
り、リトライオーバーになるか否かを判断する。

【００９５】リトライオーバーの場合はステップＳ５０
６に処理を進め、更にリトライが可能な場合は処理をス
テップＳ５０５へ進める。

【００９６】ステップＳ５０５では、受信側ノードへ同
一パケットを再送信するリトライ処理を実行する。その
後、リトライ処理によって再送されたパケットが無事受
信されたか否かの判断はステップＳ５０２で行なう。

【００９７】ステップＳ５０６では、今回のリトライ処
理が何回目の処理になるかをカウントする。ここでの処
理はアプリケーションレイヤが管理するレベルのもので
ある。

【００９８】ステップＳ５０７では、ステップＳ５０６
でカウントした値がアプリケーションレイヤで管理する
リトライの最大回数を超えるかどうか（リトライ回数を
超えるか）否かを判断する。リトライオーバーの場合は
ステップＳ５０８へ進み、更にリトライが可能な場合
は、ステップＳ５０１へ戻りパケットの送信を行なう。

【００９９】ステップＳ５０８では、アプリケーション
レベルで行なったリトライにも関わらず、受信側ノード
がビジーの場合は、その送るべきデータの転送を中止す
るか、受信側ノードが何らかのエラーによって独自に復
旧できないと判断してリセットのコマンドを送信する
か、それとも全てのパケットを受信不能としてバスリセ
ットの処理を行なう。

【０１００】ステップＳ５０９では、戻ってきたＡＣＫ
からエラーが発生したかどうかを判断する。具体的には
データがエラーだったかどうか、ＡＣＫが戻ってきたか
どうかなど正常にパケットを受け取れたかどうかで処理
を分岐させる。正常にパケットを受け取ったというコン
プリートのＡＣＫおよびパケットは受け取ったけれど処
理は保留中であるというペンディングのＡＣＫを受け取
ったときはステップ１０５へ、エラーが発生したときは
ステップＳ５１０へ進む。

【０１０１】ステップＳ５１０では、エラーの処理を行
う。受け取ったＡＣＫから判断してエラーだとわかった
ときは、トランザクションレイヤからその上位レイヤで
あるアプリケーションレイヤにその旨伝える。アプリケ
ーションレイヤは再度データを送信するなどのリカバリ
ーの処理を行う。

【０１０２】ステップＳ５１１では、最終的に送信した
パケットがどうなったか、送信が成功したのか、失敗し
たのか等の状況を把握する。

【０１０３】ステップＳ５１２では、ステップＳ５０６
でカウントしたリトライ回数がこの段階でＮ回以上かを
判断する。

【０１０４】Ｎは２以上の自然数であり、上限はＩＥＥ
Ｅ１３９４規格では決められていない。ここでは、例と
してＮ＝２として考える。Ｎ＝２となるケースは、２回
目の再送であり、同じパケットをアプリケーションレベ
ルで２回送信していることになる（１回目は通常の送信
であり、２回目は最初のリトライ送信である）。

【０１０５】１回目の送信要求に対して、受信側のノー
ドがビジーの場合はトランザクションレイヤを複数回行
なう。トランザクションレイヤレベルの最大のリトライ
回数を３回とすると、実際には、合計６回の同一データ
の送信を行なっていることになる。

【０１０６】リトライ回数がＮ回以上の場合はステップ
Ｓ５１３に処理を進め、Ｎ回未満の場合は処理をステッ
プＳ５１４に進める。

【０１０７】1回目の通常のパケット送信でビジー状態
でリトライオーバーとなり、次のリトライでもビジー状
態でパケット送信が成功しない場合には、受信側のノー
ドの状態が次のいずれかの状態であると判断される。

【０１０８】一つ目の状態として、デバイス自身がビジ
ーとなってしまったため、パケットが受信できない状態
となっている。

【０１０９】例えば、相手ノードをプリンタとしたと
き、プリントデータの転送の際に印刷部での処理がイン
タフェースのスループットに比べて遅いと、印刷部でい
くらかのバッファを持っていたとしても処理が間に合わ
ず、印刷部がデータをある程度受け入れられる状態にな
るまで、インタフェースからの入力を制限するようにな
る。

【０１１０】二つ目の状態として、以前に送信したパケ
ットの処理が未だ済んでいない場合である。一つ前に送
信元ノードから送ったパケットが未だに処理されていな
い場合などが該当する。すなわち、受信側ノードがアシ
ンクロナス転送によるパケットを格納できるＦＩＦＯを
１つしか持たず、その前に受信したパケットをＦＩＦＯ
から抜き出す処理をする前に、次のパケットを受信しよ
うとした場合である。

【０１１１】三つ目の状態として、受信側で致命的なエ
ラーが発生して受信不能になった場合である。この３つ
目の場合は、何らかの手段（例えば、バスリセット等）
を施して、デバイスが、正常に動作する状態に戻してや
る必要があるが、一つ目、二つ目の場合は、受信側ノー
ドのパケット処理時間及び能力、送信側のパケット送信
タイミングまたは、送信間隔のミスマッチによるもので
ある。

【０１１２】本発明は、この二つの状態を解消し、シス
テム全体としてのパフォーマンスを向上させるものであ
る。

【０１１３】ステップＳ５１３では、次回のトランザク
ション発行時から通常の転送を行なう際のパケット送信
間隔、アプリケーションレイヤで管理するべき再送（リ
トライ）の送信間隔及び送信回数をそれぞれ任意に変更
し、設定する。

【０１１４】この設定は、Ｎ回以上のアプリケーション
レイヤで管理するリトライを行なった特定ノードに対し
てのみ行なう。具体的には、複数の送信間隔、再送間隔
及び再送回数の設定値をテーブルとして備え、現在設定
されている値よりも大きい値を設定する。また、現在設
定されている値よりも大きな任意の値を計算し、設定す
ることも可能である。

【０１１５】テーブルを利用する場合も、計算により求
める場合も、ステップＳ５１１で把握したパケットの送
信状況、つまり、トランザクションレベル及びアプリケ
ーションレベルのリトライを含めて何回のリトライ処理
を行なったか、最終的にパケット送信が成功したか否か
等の情報を基に設定を行なう。

【０１１６】再送を行なうまでの時間を長くとることで
最終的に再度のリトライによっても相手ノードにパケッ
トを送信できないなどの状態を防ぐことができる可能性
も高くなる。

【０１１７】また、同一ノードに対して、上記判断ルー
チンを通る度に、更に大きな値を設定することも可能で
ある。

【０１１８】ステップＳ５１４では、一つ前にアシンク
ロナス転送モードでパケット送信した送信ノードに対し
て続けて送信するデータがあるかどうかを判断する。送
信するデータがまだ存在する場合はステップＳ５０１へ
戻り再び受信側ノードに対してアシンクロナス転送でパ
ケットを送信する。同一ノードに対して送信するデータ
がない場合には、このリトライ及び送信間隔設定処理を
終了する。

【０１１９】これらの処理過程を経ることで、受信側ノ
ードの処理能力に合わせたパケット送信が可能となり、
無効なトラフィックを低減させてシステム全体のパフォ
ーマンスを向上させることができる。

【０１２０】ＩＥＥ１３９４の各レイヤの構成は第１実
施形態と共通（図２）であるので詳細な説明は省略す
る。

【０１２１】図６は、第２実施形態におけるトランザク
ションレイヤ内の機能ブロック図である。この図に示さ
れているのはトランザクションレイヤのすべての機能で
はなく、本実施形態に必要なもの、もしくは使用する機
能に限定されている。

【０１２２】６０１は、トランザクションレイヤを構成
するファームウェアとのやりとりをするためのＬＩＮＫ
Ｉ／Ｆである。実際にはファームウェアがリンクレイ
ヤを実現するＬＳＩのレジスタにアクセスしたり、割り
込みを受けることによってやりとりを行う。

【０１２３】６０２は、ＡＣＫ処理部である。送信した
パケットに対してどのようなＡＣＫが戻ってきたのかを
判断する。具体的にはＡＣＫがコンプリートの場合とペ
ンディングの場合はアプリケーションレイヤにある送信
リクエスト部６０３へ、エラーの場合はアプリケーショ
ンレイヤにあるエラー処理部６０５へ、ビジーの場合は
カウンタ６０６へ伝えられる。

【０１２４】６０３は、先に転送したパケットが正常に
受信されたことを受けて次のパケットを送信するか否か
を決定する送信リクエスト部である。ＩＥＥＥ１３９４
インタフェース上に接続されたデバイスに対して転送す
るデータが存在する場合は、送信のリクエストを発行す
る。

【０１２５】６０４は、送信リクエスト部６０３からの
要求を受けてパケットを生成し、相手ノードに対して送
信する送信処理部である。ここで生成されたパケットは
ＬＩＮＫＩ／Ｆ６０１を経由してバス上に流れる。

【０１２６】６０５は、先に転送したパケットの送信に
際してデータエラーやＡＣＫが返らなかったことを受け
てエラーの処理を行う。

【０１２７】６０６は、現在行っているトランザクショ
ンに対して何回のリトライ処理が行われた（若しくはこ
れから行うか）をカウントするカウンタである。

【０１２８】６０７は、カウンタ６０６の値とノードに
設定された最大再送回数値を比較して、再送回数（カウ
ンタ値）が最大回数値を超えたときはリトライオーバー
であると判断し、その後の処理をアプリケーションレイ
ヤに任せる。

【０１２９】６０８は、リトライ処理部である。前回送
信したのと同一パケットを相手ノードに対して送信す
る。但し、これは、トランザクションレイヤが管理する
再送とは異なり、同一のデータであるが、別のトランザ
クション（トランザクションラベルが異なる別のパケッ
ト送信）となる。

【０１３０】６０９は、現在行なっているデータ転送に
対して何回のリトライオーバーが発生したかをカウント
するカウンタである。

【０１３１】６１０は、アプリケーションレベルで再度
同一のパケットを送信するか否かを判断、決定するアプ
リケーションリトライ制御部である。再度パケットを送
信する場合は送信リクエスト部６０３にその要求を伝え
る。他に送信したパケットがエラーだったときに再送す
るかどうかの判断も行なう。本実施形態にかかる発明の
最も重要な送信間隔、再送間隔及び再送回数値を変更す
るかどうかの判断も行なうが、処理の内容に関しては図
５の説明で既に説明済みであるので省略する。

【０１３２】６１１は、送信間隔、再送間隔及び再送回
数値を設定する。設定方法に関しては既に図５で説明済
みであるので省略する。

【０１３３】６１２は、送信間隔、再送間隔及び再送回
数値を設定するための値を格納したテーブルである。テ
ーブルに格納する値は予め規定してもよいし、後から設
定してもよい。

【０１３４】６１３は、送信及び再送の間隔を規定する
ためのタイマである。タイマの発するタイミングで送信
リクエスト部６０３は送信処理部に送信のリクエストを
行なう。

【０１３５】以上説明してきたこれらの構成は、トラン
ザクションレイヤで管理するリトライをハードウエアに
よって実現することを想定している。そこで、先に説明
したようにファームウエアで逐次リトライする場合を考
える。ファームウエアでリトライ処理する構成であれ
ば、この実施形態の中でアプリケーションレイヤで管理
するリトライ処理を制御したのと同じようにトランザク
ションレイヤで管理するリトライ処理、つまり、リトラ
イの間隔や回数を制御することができる。その場合の判
断、および設定の処理は複雑になるが、よりきめこまか
な設定が可能となる。

【０１３６】図７は、第２実施形態における再送間隔お
よび送信間隔を示す模式図である。

【０１３７】（ａ）は本実施形態に拠らない場合のアシ
ンクロナス転送によるパケット送信を図示したものであ
る。

【０１３８】７０１は、アシンクロナス転送のパケット
である。Ｙ軸として書かれているのは時間軸で７０１の
パケットは便宜的にＭ−１番目のパケットとする。パケ
ットの送信が正常に終了した場合、次のパケットを送信
するまでの時間をＴ１とする。実際には送信側ノードが
送信要求を出すまでの時間がＴ１で、バスのアービトレ
ーションによってパケットの送信が許可されなければそ
れ以上の時間がかかる場合もある。

【０１３９】７０２は、受信側ノードがビジーの場合の
再送パケットである。その前のＭ番目のパケット送信が
ビジーなのを受けて再送される。再送されるまでの時間
をＴ２とする（図はＭ＋１番目のパケットのところで指
示している）。この例では３回のリトライを行うものと
し、３回目のリトライが失敗したために、リトライオー
バーの処理が施され、アプリケーションレベルのリトラ
イを行なう。このリトライがＭ＋１にパケットに相当す
る。リトライ終了から次のパケット送信までの時間間隔
は同じくＴ１である。つまり、Ｔ１の間隔で送信要求が
だされるものとする。アプリケーションレベルのリトラ
イの細大回数を仮に１回とする。

【０１４０】（ｂ）は本実施形態を適用した場合のパケ
ット送信を図示したものである。この例では、アシンク
ロナスパケットの送信を要求する間隔を変更した後の状
態を示している。具体的には、パケットの送信までの時
間がＴ１からＴ３に変更されており、この場合はＴ１よ
り長い時間Ｔ１＜Ｔ３と変更される。

【０１４１】また、トランザクションレベルのリトライ
の間隔はＴ２と変わらない。これは本実施形態におい
て、トランザクションレイヤで管理するリトライが、ハ
ードウエアによって自動的に行われることを想定してい
るからである。

【０１４２】（ｃ）は、（ｂ）と同様に本実施形態を適
用した場合で、送信の間隔を変更した後の状態を示して
いる。具体的には送信までの時間がＴ１からＴ４に変更
されており、この場合はＴ１＜Ｔ４である。通常のパケ
ット送信要求の間隔はＴ１として変更はない。また、ビ
ジーの際のリトライ間隔もＴ２と変わらない。

【０１４３】（ｄ）は、（ｂ）、（ｃ）と同様に本実施
形態を適用した場合で、アプリケーションレベルのリト
ライ回数を変更した後の状態を示している。具体的には
アプリケーションが管理するリトライ回数の最大値を１
回から２回に変更している。（ｄ）の設定では、パケッ
トの送信間隔（送信要求間隔及び再送間隔）に関係のあ
る値は変わらない。

【０１４４】（ｅ）は，（ｂ），（ｃ），及び（ｄ）と
同様に本実施形態を適用した場合で、通常のパケット送
信間隔、アプリケーションレイヤで管理するリトライの
再送間隔及び再送回数のそれぞれを任意に変更した後の
状態を示したものである。また、（ｂ）、（ｃ）の図に
は示されていないが、トランザクションレイヤで管理す
るリトライの制御をファームウエアですることが可能な
場合はリトライ間隔Ｔ２の時間も変更することが可能と
なり、より細かな設定が可能になる。このように（ａ）
の場合と比べて、（ｂ）〜（ｅ）のどの例でも。パケッ
トの送信数が減っていることが図面より容易に理解する
ことができる。

【０１４５】以上説明してきたように本実施形態の構成
によって、受信側ノードの処理能力にあわせたパケット
送信が可能となり、無効なトラフィックを低減し、バス
システム全体のパフォーマンスを向上させることが可能
になる。

【０１４６】特にトランザクションレイヤで管理するリ
トライ処理がＬＩＮＫチップなどのハードウエアによっ
て実現されているため制御内容が制限される場合に有効
である。

【０１４７】また、これらの実現に際し、予め受信側ノ
ードからアシンクロナス転送によるパケット受信の処理
能力もしくは処理時間を把握しておく必要もない。

【０１４８】（第３実施形態）本発明にかかる第３実施
形態を図に従って説明する。図８は、第３実施形態にお
けるリトライ回数設定処理の流れを示すフローチャート
である。

【０１４９】ここでは、バスを構成するノードの数や種
類によってリトライ回数を設定する手順について説明す
る。

【０１５０】ステップＳ８０１では、新たなデバイスが
バスに接続されたり、その逆に取り除かれたりする活線
挿抜による動作やデバイスの電源投入などによって発生
するバスリセット信号を検知する。

【０１５１】ステップＳ８０２では、ツリー識別の後に
各ノードから送信されてくるセルフＩＤパケットを受信
する。自ノードのセルフＩＤパケットに関しては他ノー
ドに対して送信した旨がＰＨＹレイヤからノードコント
ローラ（ＳＢＭ：シリアルバスマネージャの機能の一
部）に通知される。これによって自ノードのフィジカル
ＩＤを知ることができる。

【０１５２】ステップＳ８０３では、セルフＩＤパケッ
トを受信した数をカウントし、バスがいくつのノードで
構成されているかを示す値を用意する。このためにはセ
ルフＩＤパケットの数に自ノードの数１をプラスする必
要がある。また、セルフＩＤパケットのフィールドに含
まれるフィジカルＩＤやスピードやポート数などの各種
情報を必要に応じて格納する。一般には、アイソクロナ
スリソースマネージャ以上の機能を持つノードが実現で
きればいい能力である。

【０１５３】ステップＳ８０４では、ステップＳ８０３
でカウントしたカウント値が２であるかどうか、つまり
バスが自ノードの他には１つのデバイスだけが接続され
るだけの２つのノードで構成されているかを判断する。
ノード数が２の場合はステップＳ８０５へすすみ、３以
上のノードでバスが構成されていると判断された場合は
ステップＳ８０６へすすむ。

【０１５４】ステップＳ８０５では、バスが２つのノー
ドで構成されているのをうけて、トランザクションレイ
ヤで管理するリトライ処理におけるリトライ回数を、そ
れぞれのノードで採用しているリトライプロトコルで規
定している最大値に設定する。リトライ回数として最大
値を設定するのは、データのやりとりを行う相手が１つ
しかないからで、複数回のリトライパケットの転送に必
要な帯域の確保は容易であると思われる。

【０１５５】仮に相手ノードがビジーであるにも関わら
ず無駄なパケットを送り続けることで、相手ノードが利
用したい帯域までこちら側が使用することになっても、
１対１に接続されているノード間でお互いに大容量のデ
ータ転送を同じタイミングで行うことなどあまり考えら
れない。

【０１５６】これはＰＣとプリンタを接続した構成を考
えれば一目瞭然で、ＰＣから大容量のプリントデータを
送信しているときにプリンタ側から同じように大容量の
データを送信してくることを想像してみればよい。ＩＥ
ＥＥ１３９４インタフェースではシングルフェーズとデ
ュアルフェーズの２種類のリトライプロトコルが定義さ
れている。シングルフェーズの最大リトライ回数は１５
回、デュアルフェーズの最大リトライ回数は７回であ
る。

【０１５７】この実施形態では、対象とするノードが採
用しているリトライプロトコルをシングルフェーズのも
のとする。よって最大リトライ回数を１５回に設定す
る。設定はＳＢＭが管理するＣＳＲ（コントロールアン
ドステータスレジスタ）の中のＢＵＳＹ＿ＴＩＭＥＯＵ
Ｔレジスタに反映される。具体的にはretry_limitフィ
ールドの値をＦＨに設定する。デュアルフェーズリトラ
イプロトコルを採用している場合は同じレジスタのseco
nd_Iimitフィールドの値を７Ｈに設定する。

【０１５８】この実施形態では、本来トランザクション
レイヤで制御するビジーの時のパケットの再送、つまり
リトライ処理をリンクチップが行うことを想定してい
る。

【０１５９】上記レジスタに値を反映させるのと同時
に、リンクチップのレジスタ（リンクチップが自動的に
行うリトライの回数を設定するためもの）等にも値を書
き込む。ここではトランザクションレイヤで管理するリ
トライ回数を設定しているが、アプリケーションレイヤ
で管理するリトライの回数、つまりトランザクションレ
イヤでのリトライが失敗（リトライオーバー）に終わっ
て、さらに上位のレイヤで同じデータを送信する仕組み
によって再送される回数を変更、設定することも可能で
ある。

【０１６０】また、リトライ回数の初期値が最大値とな
るように設定されている場合は、改めて値を設定するよ
うなことはしないで設定処理をスキップする。

【０１６１】ステップＳ８０６では、バスを構成する３
つ以上のノードの中にアイソクロナスリソースマネージ
ャもしくはバスマネージャとなるノードが存在するのか
どうかを判断する。具体的には、送信されてきたセルフ
ＩＤパケットの中のｌ(Link_active)ビットが１（リン
クがアクティブ）のノードのうち、ｃ(Contender)ビッ
トに１が立てられているものがアイソクロナスリソース
マネージャもしくはそれ以上の機能を持つバスマネージ
ャ候補なのでそれらを把握する。ｌおよびｃビットに共
に１が立てられているノードが存在しなければ、アイソ
クロナスリソースマネージャもしくはバスマネージャと
なるノードがこのバス上には存在しないと判断する。

【０１６２】ちなみに存在する場合はそれらのノードが
候補となるが、ビットを立ててきたノードが複数存在す
る場合には、最もフィジカルＩＤが大きいノードがアイ
ソクロナスリソースマネージャもしくはバスマネージャ
となる。アイソクロナスリソースマネージャもしくはバ
スマネージャの機能を持つノードが存在しない場合はス
テップＳ８０５へすすみ、存在する場合はステップＳ８
０７へすすむ。アイソクロナスリソースマネージャもし
くは以上の機能を持つバスマネージャが存在しないこと
は、すなわちアイソクロナス転送を行うノードが存在し
ないことを意味し、常に一定期間帯域を占有するノード
が存在しないので、アシンクロナス転送を行うのに十分
な帯域が確保されていると判断することができる。

【０１６３】ステップＳ８０７では、バスを構成してい
るノードの種類、ここではアイソクロナスノード（アイ
ソクロナスパケットの送受信を行う機能を持つノード）
かトランザクションノード（パケットの送受信はアシン
クロナス転送のみのノード）かを識別するためのパケッ
トを送信する。種類を識別するためにはいくつかの方法
があるが、具体的には以下の３つの手段のうちいずれか
もしくは複数を選択してパケットの送信を行う。

【０１６４】その一つはコンフィグレーションＲＯＭの
bus_info_blockの中のｉｓｃビットが１かどうかをリー
ドトランザクションで読む方法である。ｉｓｃビットは
そのノードがアイソクロナス動作をサポートしているか
どうかを示すビットで、このビットに１が立っている場
合はアイソクロナスノードであることがわかる（ただし
そのノードがアイソクロナス転送モードをサポートして
いるというだけで必ずしもアイソクロナス転送用にリソ
ースを獲得しているわけではない）。

【０１６５】二つ目は同じくコンフィグレーションＲＯ
Ｍ内に定義されているそのノードの情報を示す値をリー
ドトランザクションを使用して読む方法である。この情
報はコンブィグレーションＲＯＭ内のNode_Uniqu_Idも
しくはVendor_Depend_Infomationに定義される。

【０１６６】ただしこの情報は、すべてのノードが情報
を同じフォーマットで格納しているとは限らないため、
各デバイスクラスで定義されているフォーマットにあわ
せて情報を読むことが必要となる。上記は各ノードに対
してリードトランザクションを行うことで格納されてい
るノード情報を把握するというものであるが、これとは
別にアイソクロナスリソースマネージャのレジスタにア
クセスして現在どの程度の帯域がアイソクロナス転送を
使用するために割り当てられているかという情報からリ
トライ回数を規定する手段もありこれが三つ目である。

【０１６７】ステップＳ８０８では、ステップＳ８０７
で送信したリードトランザクションに対するレスポンス
データから、バスに接続されているノードの種別を識
別、判断する。

【０１６８】ステップＳ８０９では、ステップＳ８０７
およびステップＳ８０８で行ったノードの種類を識別す
る処理がバスを構成する自ノードを除くすべてのノード
に対して行われたどうかを判断する。既にすべてのノー
ドの情報を獲得し識別できている場合はステップＳ８１
０へすすみ、まだ情報を把握していないノードがある場
合はステップＳ８０７へ戻りそのノードに対してパケッ
トを送信する。

【０１６９】ステップＳ８１０では、ノードを種類別に
カウントする。つまりバス構成するノードのうち、アイ
ソクロナスノードがいくつで、トランザクションノード
がいくつであるのかをそれぞれカウントする。

【０１７０】ステップＳ８１１では、トランザクション
レイヤで管理するリトライ処理におけるリトライ回数を
求めて設定する。リトライ回数はステップＳ８１０でカ
ウントしたそれぞれの種類のノード数の関係から演算す
る方法と、アイソクロナスリソースマネージャ以上の機
能を有するノードが持つ使用する帯域を示したレジスタ
の値から演算する方法がある。

【０１７１】ここでは具体的な演算方法は示さないが、
演算結果をそのまま設定できるようなプログラムを用意
してもいいし、ノードをカウントした直接の値もしくは
その値から求めた演算結果をパラメータとしてテーブル
に代入しリトライ回数を定めてもよい。新たに設定しよ
うとする値と現在設定されている値が同じ場合は処理を
スキップする。また、ステップＳ８０５と同様にアプリ
ケーションレイヤで管理するリトライ処理に関しても変
更・設定することが可能である。リトライ値の設定手順
に関してはステップＳ８０５で説明しているのでここで
は省略する。

【０１７２】ステップＳ８１２では、ステップＳ８０５
もしくはステップＳ８１１で設定したリトライ回数値と
そのノードのリトライ回数の初期設定値が異なり、かつ
新たな値を設定する前にリトライ回数を設定してあるＣ
ＳＲのBUSY_TIMEOUTレジスタに他ノードからアクセスが
あったかどうかを判断する。レジスタへのアクセス（リ
ード）があった場合にはステップＳ８１３へすすみ、ア
クセスがない場合はリトライ回数設定処理を終了する。
この処理はレジスタをリードされたときの値とその後に
設定した値との食い違いが出ることを防ぐために行われ
る。

【０１７３】ステップＳ８１３では、ステップＳ８１２
で食い違いが発生したことをうけてバスリセットを発生
させる。その場合のレジスタの設定値は初期値ではな
く、ステップＳ８０５もしくはステップＳ８１１で設定
した値となる。また自ノードが発生させたバスリセット
に対しては図８を使用して説明してきたリトライ回数設
定処理はスキップするものとする。これらの処理過程を
経ることで、受信側ノードの処理能力に関わらずバスの
システム構成にあわせたパケット送信が可能となり、無
効なトラフィックを低減し、バスシステム全体のパフォ
ーマンスを向上させられる。

【０１７４】尚、ここで、本実施形態によって解決しよ
うとしている課題について分析してみる。相手ノードに
対して通常にパケットを送信したにも関わらず相手側ノ
ードからビジーのＡＣＫが帰ってきた場合は次のどれか
の状態にあると考えられる。

【０１７５】一つ目はデバイス自身がビジーになってし
まったためパケットが受信できない状態である。例とし
て相手ノードをプリンタとして考え。プリントデータの
転送の際に印字部での処理がインタフェースのスループ
ットに比べて遅いと、印字部でいくらかのバッファを持
っていたとしても処理が間に合わず、印字部がデータを
ある程度受け入れられる状態になるまでインタフェース
からの入力を制限するようになる。これはインタフェー
ス部分の処理が間に合っても、それ以外の部分の処理が
間に合わない場合が該当する。

【０１７６】二つ目は以前に送信したパケットの処理が
まだ済んでいない場合である。一つ前に送信元ノードか
ら送ったパケット、もしくはたまたま送信側ノードから
送られるパケット受信前に別のノードから送られたパケ
ットを処理し切れていない場合などがそれに当たる。受
信側ノードがアシンクロナス転送によるパケットを格納
できるＦＩＦＯを一つしか持たず、その前に受信したパ
ケットをＦＩＦＯから抜き出す処理をする前に次のパケ
ットを受信しようとした場合がそれに該当する。つまり
インタフェース部分の処理自体が間に合わない場合であ
る。

【０１７７】三つ目は受信側ノードで致命的なエラーが
発生して受信不能に陥った場合である。この三つ目の場
合には何らかの手段（例えばバスリセットやコマンドに
よるリセットもしくはユーザー自らがマニュアル操作で
リカバリーする等）をこうじてデバイスが正常動作をす
る状態に戻してやる必要があるが、一つ目および二つ目
の場合は、受信側ノードのパケット処理時間および能力
と送信側ノードのパケット送信タイミングまたは送信回
数のミスマッチによるものである。

【０１７８】一般には、相手ノードがビジーとなっても
受信できるまで送信し続けられれば相手の処理能力を気
にせず確実なパケットの転送を行うことができるわけで
あるが、無駄なパケットの転送は他のデバイスの帯域も
使用してしまうためその見極めは難しい。本実施形態は
これらの課題をバスの構成状況によってリトライ回数を
変えることで解消する。その結果、帯域の有効利用がは
かられ、システム全体としてのパフォーマンスが向上す
る。

【０１７９】図９は、第３実施形態におけるトランザク
ションレイヤ、シリアルバスマネージメントレイヤおよ
びアプリケーションレイヤ内の機能ブロック図である。

【０１８０】この図に示しているのはトランザクション
レイヤ、シリアルバスマネージメントレイヤおよびアプ
リケーションレイヤのすべての機能ではなく、本実施形
態に必要かもしくは使用する機能に限定している。

【０１８１】９０１は、トランザクションレイヤを構成
するファームウェアとのやりとりをするためのＬＩＮＫ
Ｉ／Ｆである。ファームウェアがリンクレイヤを実現
するＬＳＩのレジスタにアクセスしたり、ＰＨＹチップ
からの信号に対応した割り込みを受けることによってや
りとりを行う。

【０１８２】９０２は、セルフＩＤパケット受信処理部
である。バスリセット後に各ノードから送信されるセル
フＩＤパケットをＬＩＮＫＩ／Ｆ９０１から受けと
る。

【０１８３】９０３は、受信したセルフＩＤパケットの
数をカウントするカウンタである。自ノードのセルフＩ
ＤパケットはセルフＩＤパケット受信部９０２では受け
とれないので、バスを構成するノードの総数はカウント
値は受信したセルフＩＤパケットの数プラス１として考
える。

【０１８４】９０４では、セルフＩＤパケットのフィー
ルドに含まれるフィジカルＩＤやスピードやポート数な
どの各種情報を必要に応じて格納する情報格納部であ
る。また、ｌ(Link_active)ビットとｃ(Contender)ビッ
トがともに１となっているノードを確認することによっ
て、アイソクロナスリソースマネージャもしくはそれ以
上の機能を持つバスマネージャとなる可能性のあるノー
ドがどれなのかを把握する。

【０１８５】９０５は、カウンタ９０３および情報格納
部９０４からの情報によってトランザクションレイヤで
管理するリトライの回数を定めるリトライ回数設定処理
部である。処理内容については図８で説明したので詳細
は省略するが、判断もしくは演算によって得られた設定
値を後述するレジスタ９０６に格納したり、バスを構成
するノードの種類を識別するためのリードトランザクシ
ョンを行うように後述の送信リクエスト部９０７に要求
を出したり、アプリケーションレイヤで管理するリトラ
イの回数を設定したりする。またリトライ関連の設定が
されているレジスタへのアクセスがあった場合にはバス
リセットを発生させるための要求をＰＨＹチップに対し
て行う。

【０１８６】９０６は、ノードが備えるＣＳＲのうちリ
トライプロトコルの種類やリトライ回数を規定している
レジスタである。リトライ回数設定処理部９０５によっ
て設定された値を反映させる。また、本実施形態ではト
ランザクションレイヤで管理するリトライ処理をリンク
チップによって実現することを想定しているため、リン
クチップのリトライ回数を規定するレジスタ（こちらは
物理的なレジスタ）にも同様に新たに設定した値をセッ
トする。

【０１８７】９０７は、他ノードに対してパケットの送
信を行うためのリクエストを発行する送信リクエスト部
である。ＩＥＥＥ１３９４インタフェース上に接続され
たノードに対して転送するデータが存在する場合は送信
のリクエストを発行する。

【０１８８】また後述するアプリケーションレイヤで管
理するリトライの実現するためのパケット送信要求があ
った場合にも９０８は、送信リクエスト部９０７からの
要求を受けてパケットを生成し、相手ノードに対して送
信する送信処理部である。ここで生成されたパケットは
ＬＩＮＫＩ／Ｆ９０１、不図示のＰＨＹチップを経由
してバス上に流れる。

【０１８９】９０９は、送信処理部９０８から送られた
パケットに対するレスポンスパケットを受信する受信処
理部である。受信したパケットの中に含まれる他ノード
の情報、具体的にはアイソクロナスノードかどうかを判
断するための情報を得る。

【０１９０】９１０は、ＡＣＫ処理部である。送信した
パケットに対してどのようなＡＣＫが返ってきたのかを
判断する。ＡＣＫがコンプリートとペンディングの場合
はアプリケーションレイヤにある送信リクエスト部９０
７へ、エラーの場合はアプリケーションレイヤにあるエ
ラー処理部９１２へ、ビジーの場合はカウンタ９１３へ
伝える。

【０１９１】９１１は、送信リクエスト部９０７が相手
ノードに対してさらに送信するデータを持っている場
合、送信リクエスト部９０７からの要求を受けてパケッ
トを生成し、相手ノードに対して送信する送信処理部で
ある。処理内容は送信処理部９０８と同じである。

【０１９２】９１２では、先に転送したパケットの送信
に際してデータエラーやＡＣＫが返らなかったことを受
けてエラーの処理を行う。

【０１９３】９１３は、現在行っているトランザクショ
ンに対して何回のリトライ処理が行われたか（もしくは
これから行うか）をカウントするカウンタである。

【０１９４】９１４では、カウンタ９１３の値とノード
に設定された最大リトライ回数との値を比較して、リト
ライ回数（カウンタ値）が最大リトライ回数の値を超え
たときにはリトライオーバーであると判断し、その後の
処理をアプリケーションレイヤに任せる。

【０１９５】９１５は、トランザクションレイヤ管理の
リトライを行うリトライ処理部である。本構成ではリト
ライオーバーが発生するまではリンクチップによって自
動的にリトライパケットが送出されるものとする。

【０１９６】９１６は、アプリケーションレイヤレベル
で再度同一のパケットを送信するかどうかを判断、決定
するアプリケーションリトライ処理制御部である。再度
パケットを送信する場合は送信リクエスト部９０７にそ
の要求を伝える。

【０１９７】他には送信したパケットがエラーだったと
きに再送をするかどうかの判断も行う。

【０１９８】以上説明してきたこれらの構成は、トラン
ザクションレイヤで管理するリトライをハードウェアに
よって実現することを想定している。そこで先程述べた
ようにファームウェアで逐次リトライする場合を考えて
みる。ファームウェアでリトライ処理をする構成であれ
ば、ハードウェアによって自動的にリトライ処理をする
場合に比べてリトライパケットを送出する間隔が長くな
るため、リトライ回数として設定する値がハードウェア
構成の場合と同じであればトータルとして同じパケット
を送り続ける時間が長くなり、それだけパケットの受信
が成功する確率が高くなる。

【０１９９】また、送出する間隔をソフトウェアで制御
することによってリトライ回数を少なく設定してもリト
ライを行う間の時間を同じくらいにすることも可能であ
る。その場合ハードウェアによるリトライ処理に比べて
ＣＰＵ負荷は大きくなるが、その分よりきめの細かな設
定を行うことができる。

【０２００】（第４実施形態）第４実施形態を図に従っ
て説明する。図１０は、システムの概要を示すブロック
図である。ここでは送信側ノードおよび受信側ノードに
必要な機能とその構成の概略ついて説明する。

【０２０１】１１０１は、ＩＥＥＥ１３９４インタフェ
ースに対応する受信側ノードである。ここでは仮にプリ
ンタ機能を持ったデバイスを想定する。図に示されるよ
うに、１１０２から１１０６の各レイヤ、プリンタ機能
１１０７および受信バッファ１１０８によって構成され
る。

【０２０２】１１０２は、ＰＨＹレイヤもしくはフィジ
カルレイヤ（物理層）と呼ばれるＩＥＥＥ１３９４イン
タフェース上の信号を直接ドライブする機能を実現する
ＬＳＩと、ＬＩＮＫレイヤ（リンク層）の機能を実現す
るＬＳＩによって構成されるＩＥＥＥ１３９４インタフ
ェース制御部である。送信側ノード１１１０から送られ
てきたプリントデータの受信処理やバスの構成などを行
う。また後述する受信バッファ１１０８へのパケット格
納も行う。

【０２０３】１１０３は、トランザクションレイヤと呼
ばれるＩＥＥＥ１３９４インタフェースに対して実際の
オペレーションを管理・実行するドライバである。この
レイヤで、ＩＥＥＥ１３９４インタフェース上で行われ
るリード／ライト／ロックのトランザクションを管理す
る。また受信側ノードがビジーの場合の再送（リトラ
イ）要求もこのレイヤで管理する。このトランザクショ
ンレイヤで管理するべきリトライ機能を実装しているＬ
ＳＩも存在する。つまりビジーの場合には指定した回数
分だけ自動的にリトライを行ってくれるハードウェアに
よって構成される機能を持つ。

【０２０４】本実施形態では、本来トランザクションレ
イヤで制御するビジーの時のパケットの再送（リトラ
イ）を行う機能もＩＥＥＥ１３９４インタフェース制御
部１１０２で実現することを想定する。また後述する受
信バッファ１１０８が再び受信可能な状態になったとき
その状態をデータ送信側ノードに伝えるためのトランザ
クションを発行する。

【０２０５】１１０４は、シリアルバスマネージメント
（ＳＢＭ）を行うレイヤで、ＩＥＥＥ１３９４インタフ
ェースの管理用ドライバによって構成されるノードコン
トローラである。機能としてはＣＳＲ（コントロールア
ンドステータスレジスタ）およびコンフィグレーション
ＲＯＭの実装・管理を行う。また、セルフＩＤパケット
の受信に伴う他ノード情報の管理も取り扱う。ＳＢＭ
は、ノードコントローラ以外の機能としてアイソクロナ
スリソースマネージャおよびバスマネージャの機能を持
つことが可能であるが、オプションであるため本受信側
ノード１１０１ではその機能は有さない。

【０２０６】１１０５は、ＩＳＯ／ＩＥＣ１３２１３で
定義されているノードの持つ各種情報を格納したコンフ
ィグレーションＲＯＭである。コンフィグレーションＲ
ＯＭには、ミニマルフォーマット(Minimal Format)とゼ
ネラルフォーマット(GeneralFormat)の２つの種類のフ
ォーマットが存在する。ミニマルフォーマットはメーカ
を識別するnode_vendor_id情報のみを持つ。ゼネラルフ
ォーマットはそれ以外にBus_info_BlockとRoot_Directo
ryと呼ばれる追加情報を持つ。本受信ノード１１０１は
ゼネラルフォーマットを持ち、図１２に示されるノード
ユニークＩＤリーフの中に受信可能パケット個数情報を
示す値を格納している。

【０２０７】１１０６は、１ＥＥＥ１３９４インタフェ
ースを利用した各種デバイスの機能、例えばプリンタや
スキャナやディジタルビデオカメラ等の機能を実現する
ソフトウェアと、トランザクションレイヤおよびノード
コントローラとのインタフェースを備えたアプリケーシ
ョンソフトウェアである。プリントデータのコマンド解
析やプリンタの記録部の制御等も行う。

【０２０８】１１０７は、アプリケーションレイヤ１１
０６のソフトウェアもしくは不図示のハードウェアによ
って制御されるプリンタの機能である。受信したプリン
トデータの印字を行う。

【０２０９】１１０８は、他ノードから送信されてきた
パケットを格納する受信バッファである。一般には同期
転送モードであるアイソクロナス転送用、非同期転送モ
ードであるアシンクロナス転送用にそれぞれバッファを
持つがここではアシンクロナス転送用受信バッファに特
定して説明を行う。ＩＥＥＥ１３９４インタフェース制
御部１１０２を構成するリンクチップはパケット受信用
のＦＩＦＯを持ち、受信されたパケットは自動もしくは
不図示のＣＰＵのコントロールによってＦＩＦＯから受
信バッファに格納される。

【０２１０】受信バッファはメモリ上の一部にその領域
を確保され、受信可能な最大データペイロードサイズの
ブロックを複数本分持つ構成や（その場合は受信したパ
ケットのデータサイズが小さい場合には１ブロックの中
に空きの領域ができる）、確保したメモリ領域に使用で
きる分だけパケットを順に格納していく構成をとること
ができる。

【０２１１】本実施形態では、前者であるメモリを複数
ブロックに分けてその一つ一つに受信したパケットを格
納する構成をとるものとする。またそのブロックの本数
（受信可能パケット個数）をここでは仮にＮとする。Ｎ
本すべての受信ブロックにパケットを格納してしまう
と、そのパケットの処理が終了しない限りバッファの空
きがなくなるため次のパケットを受信することができな
い。この状態をデバイスビジーという。実際にはマージ
ンをみて受信バッファのブロックがＮ本より若干少ない
数まで埋まったらビジーとする場合もある。受信側ノー
ドは、連続して同一ノードからパケットを受信している
場合、その受信したパケットの処理が終わりバッファが
空き状態になり、再び連続して受信可能になったらその
旨を送信側ノードに伝える機能を有する。

【０２１２】これは不図示のＣＰＵが受信バッファを監
視して空き状態になったら通知することによって実現す
る。トランザクションレイヤは受信バッファが空いたこ
とを受けて、受信側ノードの状態を伝える情報を格納し
たデータを持つパケットを送信側ノードに送信する。パ
ケットを送信するタイミングは、上記で説明したように
受信したパケットの処理が終了しすべてのバッファが空
いた状態になったときの他に、まだすべての処理が終了
していない状態でも、こちらの状態を伝えそれに基づい
て送信側ノードが再びパケットを送信してくるまでの間
に処理が終了し、バッファが空くと予想されるタイミン
グであっても構わない。

【０２１３】１１０９は、ＩＥＥＥ１３９４インタフェ
ースのケーブルである。このケーブル内には２組のツイ
ストペアケーブル（一方がＡ、他方がＢと称される信号
線）と１組の電源ペアケーブルのあわせて６本のケーブ
ルがクロスしている。

【０２１４】１１１０は、ＩＥＥＥ１３９４インタフェ
ースに対応する送信側ノードである。ここでは仮に受信
側ノード１１０１であるプリンタにプリントデータを送
信するＰＣ（パーソナルコンピュータ）を想定する。Ｐ
Ｃが本来持つ機能の他に、図に示されるように、以下に
説明される１１１１から１１１４の各機能ブロックを有
する。

【０２１５】１１１１は、受信側ノード１１０１の１０
２と同じＩＥＥＥ１３９４インタフェース制御部であ
る。

【０２１６】１１１２は、受信側ノード１１０１から送
られたレスポンスパケットおよび相手ノードからのＡＣ
Ｋを受信処理する受信部である。リードのレスポンスパ
ケットの場合は、受信したパケットの中に含まれる受信
側ノード１１０１の情報、具体的にはコンフィグレーシ
ョンＲＯＭに格納された受信可能パケット個数情報を
得、その情報は送信制御処理部１１１３に送られる。ま
た、ＡＣＫの処理では、送信したパケットに対してどの
ようなＡＣＫが返ってきたのかを判断し、そのＡＣＫご
とに、例えばビジーの場合にはリトライ処理を行うなど
の適切な処理を行う。

【０２１７】１１１３は、受信側ノード１１０１の受信
可能パケット個数情報から、連続して送信することが可
能なパケット個数を設定して送信のリクエストを発行し
たり、受信側ノードから再び連続送信が可能な状態にあ
ることを伝えるパケットを受信することにより連続送信
を再開するなど各種送信制御を行う送信制御処理部であ
る。パケットを連続して送信することが可能であると予
想される個数の設定は、受信可能パケット個数情報（値
はＮ）に基づいて行われる。その際受信可能パケット個
数情報（Ｎ）をそのまま使用して連続送信パケット個数
をＮと設定する場合の他、他のノードからのパケット受
信を考慮して連続送信パケット個数をＮ−α（αは任意
の自然数）としたり、パケットの受信中にも受信処理が
行われ続けていることを考慮して、連続送信の最後のパ
ケットの受信時にはさらにいくつかのパケットが受信可
能であると判断して連続送信パケット個数をＮ＋β（β
は任意の自然数）とすることも可能である。

【０２１８】このα、βの値を設定するためには、例え
ばバスを構成するノード数やアシンクロナス転送を頻繁
に行う可能性のあるデバイスの個数（これらは受信した
セルフＩＤパケットの個数や他ノードのコンフィグレー
ションＲＯＭ情報から取得）、それから受信側ノードの
パケット受信処理時間（受信側ノードのコンフィグレー
ションＲＯＭ情報から取得・判断）などの情報を利用す
る。受信側ノードのパケット受信処理時間情報は特にプ
ロトコル上規定されてるものではないので必要があれば
独自に用意する必要がある。

【０２１９】一回の連続転送ですべてのデータを送信で
きない場合は、再びパケットの送信を行う必要がある。
パケット送信の再開は、受信側ノードから送信された再
び受信バッファが空きになり受信可能の状態になったと
いうことを伝えるパケットを受信し、その内容を把握す
ることによって行われる。

【０２２０】１１４は、ＩＥＥＥ１３９４インタフェー
スのバス上に接続されたノードに対してパケットを送信
する送信部である。受信側ノード１０１に対して転送す
べきデータが存在する場合は連続してパケットを送信す
る。またトランザクションレイヤで管理するリトライパ
ケットの送信も行う。ここで生成、送信されたパケット
はＩＥＥＥ１３９４インタフェース制御部１１１１を経
由してバス上に流れる。

【０２２１】このように、送信側ノード１１１０はまず
受信側ノード１１０１のコンフィグレーションＲＯＭ１
１０５に格納されている受信可能パケット個数情報をリ
ードトランザクションによって獲得し、それに基づいて
連続したパケットの送信を行うことになる。さらに連続
したパケット送信を行う場合には、受信側ノードから送
られてくる受信側ノードのステータス情報（具体的には
受信バッファが空きとなり、再び連続転送が可能な状態
であるという情報）に基づいて制御を行う。

【０２２２】なおここで、本実施形態によって解決しよ
うとしている課題について再度分析してみる。

【０２２３】相手ノードに対して通常にパケットを送信
したにも関わらず相手側ノードからビジーのＡＣＫが帰
ってきた場合には次の何れかの状態にあると考えられ
る。一つ目はデバイス自身がビジーになってしまったた
めパケットが受信できない状態である。

【０２２４】例として相手ノードをプリンタとして考え
てみる。プリントデータの転送の際に印字部での処理が
インタフェースのスループットに比べて遅いと、印字部
でいくらかのバッファを持っていたとしても処理が間に
合わず、印字部がデータをある程度受け入れられる状態
になるまでインタフェースからの入力を制限するように
なる。これはインタフェース部分の処理が間に合って
も、それ以外の部分の処理が間に合わない場合が該当す
る。二つ目は以前に送信したパケットの処理がまだ済ん
でいない場合である。

【０２２５】一つ前に送信側ノードから送ったパケッ
ト、もしくはたまたま送信側ノードから送られるパケッ
ト受信前に別のノードから送られたパケットを処理し切
れていない場合などがそれに当たると考えられる。受信
側ノードがアシンクロナス転送によるパケットを格納で
きるＦＩＦＯを一つしか持たず、その前に受信したパケ
ットをＦＩＦＯから抜き出す処理をする以前に次のパケ
ットを受信しようと試みた場合がそれに該当する。

【０２２６】つまりインタフェース部分の処理自体が間
に合わない場合である。三つ目は受信側ノードで致命的
なエラーが発生して受信不能に陥った場合である。この
三つ目の場合には何らかの手段（例えばバスリセットや
コマンドによるリセットもしくはユーザー自らがマニュ
アル操作でリカバリーする等の手段）をこうじてデバイ
スが正常動作を行うことができる状態に戻してやる必要
があるが、一つ目および二つ目の場合は、受信側ノード
のパケット処理時間もしくは処理能力と、送信側ノード
のパケット送信タイミングまたは送信回数のミスマッチ
によるものである。

【０２２７】一般には、相手ノードがビジーとなっても
受信できるまで送信し続けられれば相手の処理能力を気
にせず確実なパケットの転送を行うことはできるが、無
駄なパケットの転送は他のデバイスの帯域も使用してし
まうためその見極めは難しい。

【０２２８】無論プロトコル上も最大許される再送回数
は規定されている。本特許はこれらの課題を、受信側ノ
ードの受信能力（受信可能パケット個数もしくはバッフ
ァサイズ）にあわせて送信側ノードの連続して送信する
パケットの個数を変更することで解消する。その結果、
帯域の有効利用がはかられるとともに、システム全体と
してのパフォーマンスも向上する。

【０２２９】図１１は、第４実施形態における処理の流
れを示したフローチャートである。ここでは、送信ノー
ドが受信ノードの受信可能パケット個数情報を獲得し、
パケットの連続送信の制御を行なう過程について説明す
る。

【０２３０】ステップＳ１２０１では、送信側ノードは
受信側ノードに対して、リードトランザクションのリク
エストを行なう。具体的には、受信側ノードの有するコ
ンフィグレーションＲＯＭの内容、特に、受信可能なパ
ケット情報を獲得するために情報が格納されているアド
レスを指定してパケットを送信する。

【０２３１】ステップＳ１２０２では、ステップＳ１２
０１で送信したリクエストに対するレスポンスを受信し
する。これによって、コンフィグレーションＲＯＭ内の
情報を獲得する。

【０２３２】ステップＳ１２０３では、受信側ノードの
コンフィグレーションＲＯＭ内に受信可能なパケットの
個数を示す情報が有るか否かを判断する。指定したアド
レスに目的の情報がない場合は処理を終了する。情報が
存在する場合はステップＳ１２０４に処理を進め、送信
制御を行なう。

【０２３３】ステップＳ１２０４では、受信可能パケッ
ト個数情報（本実施形態では、最大で何個のパケットを
受信して、格納することができるか否かという情報をい
う）に基づいて、送信側ノードの送信制御値、具体的に
は連続したパケットの送信を行なう個数（回数）などの
制御パラメータを設定し、受信ノードに対して連続して
送信を行なう。

【０２３４】ステップＳ１２０５では、受信側ノードに
対して、更に送信するべきデータが存在しているかどう
かを判断する。未だ他に送信するべきデータがある場合
は処理をステップＳ１２０６へ進め、送信が終了してい
る場合は処理を終了する。

【０２３５】ステップＳ１２０６では、受信側ノードが
それ以前に送信したパケットの終了を終えて再び連続し
たパケットを受信するだけの受信バッファの空き容量を
確保できたか否かを判断する。具体的には、受信可能な
状態になったことを伝えるパケットを受信側ノードから
受信して判断する。このパケットを受け取っていない場
合は、受信ができない状態であり、待機状態となり再度
ステップＳ１２０６の処理を繰り返し行なう。

【０２３６】尚、一般には、特定のノードに対して送信
を行なう際に、上記で説明した処理を行なえばよい。同
時に複数のノードに対して、送信を行なうことは一般的
ではないが、あるノードに対して、連続したデータの転
送終了後に別のノードに対して同様な処理を行なう際
は、その都度受信可能パケット個数情報の獲得処理を行
なうか、それとも最初にバスを構成する全てのノードの
受信可能パケット情報を獲得後、その情報をテーブルに
格納し、必要に応じて設定を変更することになる。

【０２３７】図１２は、第４実施形態における受信可能
パケット個数情報を格納するノードユニークＩＤリーフ
のフォーマットである。ここでは、受信可能パケット個
数情報がどのようにコンフィグレーションＲＯＭ内に格
納されているのかを示す。

【０２３８】ノードユニークＩＤは８バイトで構成され
ており、その先頭３バイトで機器の発売元（ベンダ）の
カンパニーＩＤを示す。このカンパニーＩＤはＩＥＥＥ
によって定められている。ノードユニークＩＤの残りの
５バイトの内容についてはベンダが自由に定めることが
できる。

【０２３９】１３０１は、カンパニーＩＤである。

【０２４０】１３０２は、ベンダが自由に定めることが
できる５バイトのうち４バイトで、機種名やシリアル番
号等の機器情報を定めている。ここでは特にその内容に
ついては重要でないので触れないことにする。

【０２４１】１３０３は、本実施形態の特徴である受信
可能パケット個数情報である。具体的には、そのノード
が受信することのできる最大のパケット数を定めてい
る。ここでは１バイトでその情報を表現しているが、必
要に応じてそのバイト数を変更することも可能である。
仮に受信バッファが、２Ｋｂｙｔｅｓのデータを格納で
きるブロックを８本持っていた場合は、この値は０８Ｈ
となる。

【０２４２】以上説明してきたように本発明にかかる実
施形態の構成によって、受信側ノードの処理能力にあわ
せたパケットの送信が可能となる。また理想的には１回
でパケット送信を成功させることが可能になることによ
ってリトライ回数を減らし、無効なトラフィックを低減
させることもできる。それによってバスシステム全体の
パフォーマンスを向上させることが可能になると同時に
より確実なパケットの転送を行うことができる。

【０２４３】（第５実施形態）第５実施形態を図に従っ
て説明する。パケットの連続送信を行う際の判断基準と
なる情報の格納されている場所が異なることを除いて第
４実施形態と同じ構成のため、同じ部分の説明は省略す
る。情報を利用する際の内容は異なるため説明する。

【０２４４】図１３は、第５実施形態における受信バッ
ファサイズを格納するベンダ依存情報のフォーマットで
ある。ここでは、受信バッファサイズがどのようにコン
フィグレーションＲＯＭ内のベンダ依存情報に格納され
ているのかを示す。ベンダ依存情報は特にそのフォーマ
ットが規定されておらず、ベンダが自由に定義すること
ができるフィールドを提供している。

【０２４５】１４０１は、メーカ名（ベンダ名）を格納
している。

【０２４６】１４０２は、機種名を格納している。上記
１４０１、１４０２は必須な事項ではないので特に取り
上げなくてもよい。上記値の他に製品のバージョン番号
を示してもよい。

【０２４７】１４０３は、本実施形態の特徴である受信
バッファサイズ情報である。具体的にはそのノードが受
信したパケットを格納することができるバッファのサイ
ズを定めている。ここでは１バイトでその情報を表現し
ているが、必要に応じてそのバイト数を変更することも
可能である。仮に受信バッファが、１６Ｋｂｙｔｅｓの
受信バッファを持っていた場合は、単位を１Ｋｂｙｔｅ
とすると１０Ｈとなる。

【０２４８】送信側ノードは、この受信バッファサイズ
情報と自ノードが送信する際のデータペイロードサイズ
から、連続して送信可能な回数を設定する。具体的には
受信バッファサイズをデータペイロードサイズで割った
値が基準となり、連続送信可能なパケット数を設定す
る。

【０２４９】以上説明してきたように本発明の構成によ
って、受信側ノードの処理能力にあわせたパケット送信
が可能となり、バスシステム全体のパフォーマンスを向
上させることができる。特に受信側ノードの処理能力を
示す指標として受信バッファサイズが用いられる場合の
送信制御に有効である。

【０２５０】（第６実施形態）本発明の第６実施形態を
図に従って説明する。図１４は、第６実施形態における
システムの概要を示すブロック図である。

【０２５１】ここでは送信側ノードおよび受信側ノード
に必要な機能とその構成の概略について説明する。

【０２５２】１５０１は、ＩＥＥＥ１３９４インタフェ
ースに対応する受信側ノードである。ここでは仮にプリ
ンタ槻能を持ったデバイスを想定する。図に示されるよ
うに、以下に説明される１５０２から１５０６の各レイ
ヤおよびプリンタ機能１５０７によって構成される。

【０２５３】１５０２は、ＰＨＹレイヤもしくはフィジ
カルレイヤ（物理層）と呼ばれるＩＥＥＥ１３９４イン
タフェース上の信号を直接ドライブする機能を実現する
ＬＳＩとＬＩＮＫレイヤ（リンク層）の機能を実現する
ＬＳＩによって構成されるＩＥＥＥ１３９４インタフェ
ース制御部である。送信側ノード１５０９から送られて
きたプリントデータの受信処理やバスの構成などを行
う。

【０２５４】１５０３は、トランザクションレイヤと呼
ばれるＩＥＥＥ１３９４インタフェースに対して実際の
オペレーションを管理・実行するドライバである。この
レイヤで、ＩＥＥＥ１３９４インタフェース上で行われ
るリード／ライト／ロックのトランザクションを管理す
る。また受信側ノードがビジーの場合の再送（リトラ
イ）要求もこのレイヤで管理する。このトランザクショ
ンレイヤで管理するべきリトライ機能を実装しているＬ
ＳＩも存在する。

【０２５５】つまりビジーの場合にはハードウェアが指
定した回数分だけ自動的にリトライを行ってくれる。本
実施形態では、本来トランザクションレイヤで制御する
ビジーの時のパケットの再送（リトライ）を行う機能も
ＩＥＥＥ１３９４インタフェース制御部１５０２で実現
することを想定する。それとは別にファームウェアでリ
トライを行う場合についても後ほど説明する。

【０２５６】１５０４は、シリアルバスマネージメント
（ＳＢＭ）を行うレイヤで、ＩＥＥＥ１３９４インタフ
ェースの管理用ドライバによって構成されるノードコン
トローラである。機能としてはＣＳＲ（コントロールア
ンドステータスレジスタ）およびコンフィグレーション
ＲＯＭの実装・管理を行う。また、セルフＩＤパケット
の受信に伴う他ノード情報の管理も取り扱う。ＳＢＭは
その他にノードコントローラ以外の機能としてアイソク
ロナスリソースマネージャおよびバスマネージャの機能
を持つが、オプションであるため本受信側ノード１５０
１ではその機能を有さない。

【０２５７】１５０５は、ＩＳＯ／ＩＥＣ１３２１３で
定義されているノードの持つ各種情報を格納したコンフ
ィグレーションＲＯＭである。コンフィグレーションＲ
ＯＭには、ミニマルフォーマット(Minimal Format)とゼ
ネラルフォーマット(GeneralFomat)の２つの種類のフォ
ーマットが存在する。ミニマルフォーマットはメーカを
識別するnode_vendor_id情報のみを持つ。ゼネラルフォ
ーマットはそれ以外にBus_info_BlockとRoot_Directory
と呼ばれる追加情報を持つ。本受信ノード１０１はゼネ
ラルフォーマットを持ち、図１６に示されるノードユニ
ークＩＤリーフの中に受信処理能力を示す値としてその
処理時間を格納しているものとする。

【０２５８】１５０６は、ＩＥＥＥ１３９４インタフェ
ースを利用した各種デバイスの機能、例えばプリンタや
スキャナやディジタルビデオカメラ等の機能を実現する
ソフトウェアと、トランザクションレイヤおよびノード
コントローラとのインタフェースを備えたアプリケーシ
ョンソフトウェアである。プリントデータのコマンド解
析やプリンタの記録部の制御等も行う。

【０２５９】１５０７は、アプリケーションレイヤ１５
０６のソフトウェアもしくは不図示のハードウェアによ
って制御されるプリンタの機能である。受信したプリン
トデータの印字を行う。

【０２６０】１５０８は、ＩＥＥＥ１３９４インタフェ
ースのケーブルである。このケーブル内には２組のツイ
ストペアケーブル（一方がＡ、他方がＢと称される信号
線）と１組の電源ペアケーブルのあわせて６本のケーブ
ルがクロスしている。

【０２６１】１５０９は、ＩＥＥＥ１３９４インタフェ
ースに対応する送信側ノードである。ここでは仮に受信
側ノード１５０１であるプリンタにプリントデータを送
信するＰＣ（コンピュータ）を想定する。図に示される
ように、以下に説明される１５１０から１１５の各機能
ブロックを有する。

【０２６２】１５１０は、受信側ノード１５０１の１５
０２と同じＩＥＥＥ１３９４インタフェース制御部であ
る。

【０２６３】１５１１は、受信側ノード１５０１から送
られたレスポンスパケットおよび相手ノードからのＡＣ
Ｋを受信する受信処理部である。リードのレスポンスパ
ケットの場合、受信したパケットの中に含まれる受信側
ノード１５０１の情報、具体的にはコンフィグレーショ
ンＲＯＭに格納された受信処理能力を示す情報を得る。
また、ＡＣＫの処理では、送信したパケットに対してど
のようなＡＣＫが返ってきたのかを判断し、そのＡＣＫ
ごと適切な処理を行う。

【０２６４】１５１２は、受信側ノード１５０１の受信
処理能力を示す値から、パケットを送信する際の各種制
御値を設定する送信制御値設定部である。具体的には受
信処理能力に合わせて、連続してパケットを送信する際
の送信間隔、受信側ノード１５０１がビジーの場合に行
われる再送処理における再送（リトライ）パケットの送
信間隔、およびトランザクションレイヤやアプリケーシ
ョンで管理される再送処理における再送（リトライ）回
数などの設定値を変更する。ここで変更された設定値に
従って送信処理部１５１３および再送処理部１５１４は
送信処理を行う。

【０２６５】１５１３は、受信側ノード１５０１へパケ
ットを送信する送信処理部である。ＩＥＥＥ１３９４イ
ンタフェースのバス上に接続されたノードに対して転送
すべきデータが存在する場合は送信のリクエストを発行
する。またアプリケーションレイヤで管理するリトライ
の実現するためのパケット送信要求があった場合にも同
様にリクエストを発行する。ここで生成、送信されたパ
ケットはＩＥＥＥ１３９４インタフェース制御部１５１
０を経由してバス上に流れる。

【０２６６】１５１４は、受信側ノード１５０１がビジ
ーであった場合の再送処理を行う再送処理部である。こ
の中には、現在行われているトランザクションに対して
何回のリトライ処理が行われたかをカウントするカウン
タや、カウンタ値とノードに設定された最大リトライ回
数との値を比較して、リトライ回数（カウンタ値）が最
大リトライ回数の値を超えたときにはリトライオーバー
であると判断する判断部や、トランザクションレイヤ管
理のリトライを行うリトライ処理部や、アプリケーショ
ンレイヤレベルで再度同一のパケットを送信するかどう
かを判断、決定するアプリケーションリトライ処理制御
部などの機能を有する。

【０２６７】本構成ではリトライオーバーが発生するま
ではリンクチップ（ＩＥＥＥ１３９４インタフェース制
御部１５１０）によって自動的にリトライパケットが送
出されるものとする。

【０２６８】ＩＥＥＥ１３９４インタフェースではトラ
ンザクションレイヤ管理のリトライプロトコルとしてシ
ングルフェーズとデュアルフェーズの２種類が定義され
ている。シングルフェーズの最大リトライ回数は１５
回、デュアルフェーズの最大リトライ回数は７回であ
る。本実施形態では、対象とするノードが採用している
リトライプロトコルをシングルフェーズのものとする。

【０２６９】よって最大リトライ回数は１５回である。
リトライ回数の設定はノードコントローラが管理するＣ
ＳＲ（コントロールアンドステータスレジスタ）の中の
BUSY_TIMEOUTレジスタに反映される。具体的にはretry_
limitフィールドの値を所望の値に設定する（デュアル
フェーズリトライプロトコルを採用している場合は同じ
レジスタのsecond_limitフィールドの値を設定する）。

【０２７０】本実施形態では、本来トランザクションレ
イヤで制御するビジーの時のパケットの再送、つまりリ
トライ処理をリンクチップが行うことを想定しているた
め上記レジスタ（ＣＳＲ）に値を反映させるのと同時
に、リンクチップのレジスタ（リンクチップが自動的に
行うリトライの回数を設定するためのもの、ＩＥＥＥ１
３９４インタフェース制御部１５１０が有する）にも値
を書き込む。

【０２７１】トランザクションレイヤで管理するリトラ
イ回数の設定のみならず、アプリケーションレイヤで管
理するリトライの回数、つまりトランザクションレイヤ
でのリトライが失敗（リトライオーバー）に終わること
によって、さらに上位のレイヤで同じデータを送信する
仕組みによって再送される回数を変更、設定することも
可能である。

【０２７２】１５１５は、パケットの送信間隔およびリ
トライ間隔を制御するために用いられるタイマーであ
る。本実施形態ではトランザクションレイヤ管理のリト
ライはハードウェアで行われるためタイマーは使用しな
いが、これから説明するファームウェアで実現する場合
には使用することになる。

【０２７３】以上説明してきた構成は、トランザクショ
ンレイヤで管理するリトライをハードウェアによって実
現することを想定している。そこで先程述べたようにフ
ァームウェアで逐次リトライする場合を考えてみる。フ
ァームウェアでリトライ処理をする構成であれば、ハー
ドウェアによって自動的にリトライ処理をする場合に比
べてリトライパケットを送出する間隔が長くなるため、
リトライ回数として設定する値がハードウェア構成の場
合と同じであればトータルとして同じパケットを送り続
ける時間が長くなり、それだけパケットの受信が成功す
る確率が高くなる（逆に一つのパケット送信が終了する
までの時間が長くなる可能性もある）。また、送出する
間隔をソフトウェアで制御することによってリトライ回
数を少なく設定してもリトライを行う間の時間を同じく
らいにすることも可能である。その場合ハードウェアに
よるリトライ処理に比べてＣＰＵ負荷は大きくなるが、
その分よりきめの細かな設定を行うことができる。

【０２７４】このように、送信側ノード１５０９はまず
受信側ノード１５０１のコンフィグレーションＲＯＭ１
５０５に格納されている受信処理能力指数（本実施形態
では１パケットを受信処理する時間）をリードトランザ
クションによって獲得し、それに基づいてパケットを送
信する間隔、再送の間隔および再送回数を制御すること
になる。

【０２７５】図１５は第６実施形態における処理の流れ
を示したフローチャートである。

【０２７６】ここでは、送信側ノードが受信処理能力情
報を獲得し送信制御を行うためのパラメータを設定する
工程を説明する。

【０２７７】ステップＳ１６０１では、送信側ノードが
受信側ノードに対してリードトランザクションのリクエ
ストを行う。具体的には、受信側ノードの持つコンフィ
グレーションＲＯＭの内容、特に受信処理能力を示す値
を獲得するために能力値が格納されているアドレスを指
定してパケットを送信する。

【０２７８】ステップＳ１６０２では、ステップＳ１６
０１で送信したリクエストに対するレスポンスを受信す
る。これによってコンフィグレーションＲＯＭ内の情報
を獲得する。

【０２７９】ステップＳ１６０３では、受信側ノードの
コンフィグレーションＲＯＭ内に受信能力を示す情報が
あるかどうかを判断する。指定したアドレスに目的の情
報がない場合はステップＳ１６０５へ処理を進め、情報
が存在する場合はステップＳ１６０４へすすむ。

【０２８０】ステップＳ１６０４では、受信処理能力情
報（本実施形態では１パケットを受信処理するのに必要
な時間）に基づいて送信側ノードの送信制御値、具体的
にはパケットの送信間隔、再送間隔および再送回数など
の制御パラメータの値を設定する。

【０２８１】ステップＳ１６０５では、バスを構成する
すべてのノードに対して受信処理能力情報の獲得動作を
行ったかどうかを判断する。まだ他にリードトランザク
ションによるコンフィグレーションＲＯＭ内の情報取得
を行っていないノードが存在する場合はステップＳ１６
０１へ戻り、すべてのノードに対して確認動作を行って
いる場合は処理を終了する。

【０２８２】なお、一般には特定のノードに対して送信
を行う際に上記処理（ステップＳ１６０１からステップ
Ｓ１６０４）を行えばよい。

【０２８３】同時に複数のノードに対して送信を行うこ
とは考えられないが、あるノードへの連続したデータの
転送終了後に別のノードに対して同様な処理を行う際
は、そのたびに上記受信処理能力情報の獲得動作を行う
か、それとも最初にバスを構成するすべてのノードの受
信処理能力情報を得てその情報をテーブルに格納し、必
要なときに設定し直すことになる。

【０２８４】図１６は、第６実施形態における処理時間
（もしくは処理能力を示す値）を格納するノードユニー
クＩＤリーフのフォーマットである。

【０２８５】ここでは、受信処理能力を示す値がどのよ
うにコンフィグレーションＲＯＭ内に格納されているの
かを示す。ノードユニークＩＤは８バイトで構成されて
おり、その先頭３バイトで機器の発売元〈ベンダ）のカ
ンパニーＩＤを示す。このカンパニーＩＤはＩＥＥＥに
よって定められている。ノードユニークＩＤの残りの５
バイトの内容についてはベンダが自由に定めることがで
きる。

【０２８６】１６１０は、カンパニーＩＤである。

【０２８７】１６２０は、ベンダが自由に定めることが
できる５バイトのうち３バイトで、機種名やシリアル番
号等の機器情報を定めている。ここでは特にその内容に
ついては重要ではないので触れない。

【０２８８】１６３０は、本実施形態の特徴である受信
処理能力を示す値である。具体的には１パケットの受信
処理に必要な時間を定めている。後述するライトトラン
ザクション時の処理時間とリードトランザクション時の
処理時間の二つの処理時間を表す値を格納している。

【０２８９】１６４０は、ライトトランザクションによ
るパケット受信時の受信処理時間を示す値である。本実
施形態では受信側ノードはプリンタデバイスなので、こ
の値が必要となるのは送信側ノードがプリントデータを
送信してくる場合である。つまりこの値は、送信側ノー
ドから送られてくるプリントデータを受信側ノードで処
理するのに必要な時間（１パケット処理時）を示してお
り、これよりも短い間隔でパケットを送信しても何れデ
バイスがビジーになる可能性のあることを示している。

【０２９０】１６５０は、リードトランザクションによ
るパケット受信時の受信処理時間を示す値である。受信
側ノードがプリンタデバイスの場合は、ＣＳＲとコンフ
ィグレーションＲＯＭのリードやデバイスのステータス
取得の他には使用されることは少なく連続しての使用も
考えづらいが、これがスキャナデバイスでＰＣ側が画像
データの取り込みの制御を行うような場合にはこの値が
有効となってくる。

【０２９１】つまりこの値は、受信側ノードが用意する
スキャナ読みとり画像データの送信に必要な時間（１パ
ケット処理時）を示しており、これよりも短い間隔でパ
ケットを送信することはそれより前に送信したリードリ
クエストに対するレスポンスが返る前に次のリードリク
エストを発行することになる（レスポンスが返ってから
のリクエスト発行であれば何ら問題はない）。

【０２９２】１６４０および１６５０で示される受信処
理時間は、ある時間を単位とした値として示される。例
えば処理時間の単位を１ｍｓｅｃとした場合を考えてみ
る。仮に２ｍｓｅｃで１パケットを処理することが可能
なデバイスであればその値は０２Ｈとなる。また、処理
時間の単位をサイクルスタートパケット周期、つまり１
２５μｓｅｃとした場合には以上の能力を有するデバイ
スであれば１０Ｈとなる。

【０２９３】以上説明してきたように本発明にかかる実
施形態の構成によって、受信側ノードの処理能力にあわ
せたパケット送信が可能となり、それによって無効なト
ラフィックを低減し、かつ使わない帯域も有効活用する
ことで、バスシステム全体のパフォーマンスを向上させ
ることが可能になる。

【０２９４】（第７実施形態）第７実施形態を図に従っ
て説明する。本実施形態は受信処理能力情報の格納され
ている場所およびフォーマットが異なることを除いて第
６実施形態と同じ構成のため、同じ部分の説明は省略す
る。

【０２９５】図１７は、第７実施形態における処理時間
（もしくは処理能力を示す値）を格納するベンダ依存情
報のフォーマットである。

【０２９６】ここでは、受信処理能力を示す値がどのよ
うにコンフィグレーションＲＯＭ内のベンダ依存情報に
格納されているのかを示す。ベンダ依存情報は特にその
フォーマットが規定されておらず、ベンダが自由に定義
することができるフィールドを提供している。

【０２９７】１７０１は、メーカ名（ベンダ名）を格納
している。

【０２９８】１７０２は、機種名を格納している。１７
０１、１７０２は必須な事項ではないので特に取り上げ
なくてもよい。これらの値の他に製品のバージョン番号
を示してもよい。

【０２９９】１７０３は、ライトトランザクションによ
るパケット受信時の受信処理能力を示す値である。第６
実施形態の図１６で説明した構成とは値の格納に割り当
てられているバイト数が異なっている。１バイトごとに
受信処理能力値を示していることには変わりはないが、
４バイトがそれぞれ送信されてくるパケットのデータペ
イロードサイズに対応している。

【０３００】受信側ノードであるプリンタデバイスが４
００Ｍｂｐｓ対応のノードで２Ｋｂｙｔｅｓやペイロー
ドサイズを持つパケットの受信が可能だとしても、送信
側ノードも同じとは限らないし何らかの都合で最大のペ
イロードサイダでの送信ができない場合もある。そこで
ペイロードサイズに合わせた受信処理能力値を用意して
ある。

【０３０１】図では２Ｋ、１Ｋ、５１２、および４バイ
ト（１クワドレット）のデータペイロードサイズに合わ
せた受信処理能力値を格納しているが、さらに細かく設
定することも可能であるし、逆に２Ｋと１Ｋの場合だけ
選択して格納することもできる。

【０３０２】１７０４は、リードトランザクションによ
るパケット受信時の受信処理能力を示す値である。構成
は１７０３と同じであるのでここでの説明は省略する。

【０３０３】本実施形態ではライトトランザクション、
リードトランザクションとも同じバイト数を確保したが
必ずしも同じにする必要はない。また、受信処理能力値
として第６実施形態では処理時間を定めていたが、処理
能力を示す指標をもって表現することも可能である。具
体的には割り当てられているビット数分（この例では１
バイト）の段階で表現することが可能であるが、仮に１
６段階（０から１５まで）で表現すると４ビットの情報
で済む。

【０３０４】５００μｓｅｃ以下が０、５００〜１００
０μｓｅｃが１、１０００〜１５００μｓｅｃが２のよ
うに５００μｓｅｃごとに指標を規定すれば、実施形態
１の図３で説明したデバイスは２ｍｓｅｃごとにパケッ
トを処理できる能力を持つので値は３Ｈ（０３Ｈ）とな
る。

【０３０５】以上説明してきたように本発明にかかる実
施形態の構成によって、受信側ノードの処理能力にあわ
せたパケット送信が可能となり、それによって無効なト
ラフィックを低減し、かつ使わない帯域も有効活用する
ことで、バスシステム全体のパフォーマンスを向上させ
ることが可能になる。

【０３０６】特に送信側のデータペイロードサイズに合
わせて送信制御を行うことが可能である。

【０３０７】また、受信処理能力値に処理時間ではなく
何らかの指標を用いることで能力値を示すビット数を減
らすことができる。

【０３０８】（第８実施形態）図１８は、第８実施形態
におけるシステムの概要を示すブロック図である。

【０３０９】ここでは送信側ノードおよび受信側ノード
に必要な機能とその構成の概略ついて説明する。

【０３１０】１８０１は、ＩＥＥＥ１３９４インタフェ
ースに対応する受信側ノードである。ここでいう受信側
ノードとは、本特許の機能の一つである送信制御を行え
る機能を持つノードを送信側ノードとした場合の相手側
となるノードのことである。本実施形態では仮にプリン
タ機能を持ったデバイスを想定する。図に示されるよう
に、以下に説明される１８０２から１８０６の各レイ
ヤ、プリンタ機能１８０７および受信バッファ１８０８
によって構成される。

【０３１１】１８０２は、ＰＨＹレイヤもしくはフィジ
カルレイヤ（物理層）と呼ばれるＩＥＥＥ１３９４イン
タフェース上の信号を直接ドライブする機能を有するＬ
ＳＩと、ＬＩＮＫレイヤ（リンク層）の機能を有するＬ
ＳＩおよびそれらのチップを直接制御するドライバソフ
トウェアによって構成されるＩＥＥＥ１３９４インタフ
ェース制御部である。

【０３１２】送信側ノード１８１０から送られてきたパ
ケットの受信や相手ノードへのパケット送信の他、バス
構成する際必要となる機能を持つ。ＬＩＮＫチップは受
信用、送信用およびアイソクロナス用、アシンクロナス
用にＦＩＦＯを持ち、アシンクロナスパケット受信用Ｆ
ＩＦＯに格納された受信パケットは後述する受信バッフ
ァ１８０８へ引き抜かれ格納される。

【０３１３】１８０３は、トランザクションレイヤと呼
ばれるＩＥＥＥ１３９４インタフェースに対して実際の
オペレーションを管理・実行するドライバである。この
レイヤで、ＩＥＥＥ１３９４インタフェース上で行われ
るアシンクロナス転送によるリード／ライト／ロックの
各トランザクションを管理する。また受信側ノード１８
０１がビジーの場合の再送（リトライ）処理もこのレイ
ヤで管理する。このリトライ処理は本来トランザクショ
ンレイヤ１８０３で管理すべきものであるが、この機能
を実装しているＬＳＩも存在する。

【０３１４】つまりビジーの場合には予め指定した回数
分だけ自動的にリトライ動作を行うハードウェアを実装
している。本実施形態では、本来トランザクションレイ
ヤ１８０３で制御すべきビジー状態の時のパケットの再
送（リトライ）を行う機能を、ＩＥＥＥ１３９４インタ
フェース制御部１８０２で実現することを想定する。

【０３１５】１８０４は、シリアルバスマネージメント
（ＳＢＭ）を行うレイヤで、ＩＥＥＥ１３９４インタフ
ェースの管理用ドライバによって構成されるノードコン
トローラと呼ばれるブロックである。機能としてはＣＳ
Ｒ（コントロールアンドステータスレジスタ）およびコ
ンフィグレーションＲＯＭ１８０５の実装・管理を行
う。

【０３１６】また、セルフＩＤパケットの受信に伴う他
ノード情報の管理も取り扱う。ＳＢＭは、ノードコント
ローラ以外の機能としてアイソクロナス・リソース・マ
ネージャおよびバス・マネージャの機能を持つことが可
能であるが、オプションであるため本実施形態の受信側
ノード１８０１ではその機能は有さない。

【０３１７】１８０５は、ＩＳＯ／ＩＥＣ１３２１３で
定義されている、ノードの持つ各種情報を格納したコン
フィグレーションＲＯＭである。

【０３１８】コンフィグレーションＲＯＭには、ミニマ
ルフォーマット(Minimal Format)とゼネラルフォーマッ
ト(General Fomat)の２種類のフォーマットが存在す
る。ミニマルフォーマットはメーカを識別するnode_ven
dor_id情報のみを持つ。ゼネラルフォーマットはそれ以
外にBus_info_BlockとRoot_Directoryと呼ばれる追加情
報を持つ。本実施形態の受信ノード１８０１はゼネラル
フォーマットのコンフィグレーションＲＯＭ１８０５を
有する。

【０３１９】１８０６は、ＩＥＥＥ１３９４インタフェ
ースを利用した各種デバイスの機能、例えばプリンタや
スキャナやディジタルビデオカメラ等の機能を実現する
ソフトウェアと、トランザクションレイヤおよびノード
コントローラとのインタフェース部分を備えたアプリケ
ーションソフトウェア（アプリケーションレイヤ）であ
る。本実施形態ではプリンタデバイスを想定しているた
め、プリントデータのコマンド解析やプリンタの記録部
の制御等を行う機能を有する。

【０３２０】１８０７は、アプリケーションレイヤ１８
０６のソフトウェアもしくは不図示のハードウェアによ
って制御されるプリンタの機能である。受信したプリン
トデータの印字を行う。

【０３２１】１８０８は、他ノードから送信されてきた
パケットを格納する受信バッファである。一般には同期
転送モードであるアイソクロナス転送用、非同期転送モ
ードであるアシンクロナス転送用にそれぞれバッファを
持つが、ここではアシンクロナス転送用受信バッファに
特定して説明を行う。またここでは説明しないが送信デ
ータを格納する送信バッファも不図示ではあるが存在し
ている（物理的には受信バッファ１８０８と同じメモリ
上に構成される）。

【０３２２】ＩＥＥＥ１３９４インタフェース制御部１
８０２の構成要素であるＬＩＮＫチップはパケット受信
用のＦＩＦＯを持ち、受信されたパケットは自動もしく
は不図示のＣＰＵのコントロールによってＦＩＦＯから
受信バッファに引き抜かれ格納される。

【０３２３】受信バッファはメモリ上の一部にその領域
を確保され、受信可能な最大データペイロードサイズの
ブロックを複数本分持つ構成や（その場合は受信したパ
ケットのデータサイズが小さい場合には１ブロックの中
に空きの領域ができる）、確保したメモリ領域に使用で
きる分だけパケットを順に格納していく構成などをとる
ことができる。

【０３２４】本実施形態では、前者であるメモリを複数
ブロックに分けてその一つ一つに受信したパケットを格
納する構成をとるものとする。またそのブロックの本数
（受信可能パケット個数）をここでは仮にＮとする。

【０３２５】Ｎ本すべての受信ブロックにパケットを格
納した場合はそのパケットの処理が終了しない限り、本
実施形態だとプリンタデバイスを想定しているためプリ
ンタに対して受信したデータを吐き出さない限り、バッ
ファの空きがなくなるために次のパケットを受信するこ
とができない（受信したパケットをＦＩＦＯから受信バ
ッファ１８０８に引き抜けないため）。この状態をデバ
イスビジーという。実際にはマージンをみて、受信バッ
ファのブロックがＮ本より若干少ない数まで埋まったら
ソフトウェアでビジーと制御する場合もある。

【０３２６】１８０９は、ＩＥＥＥ１３９４インタフェ
ースのケーブルである。このケーブル内には２組のツイ
ストペアケーブル（一方がＡ、他方がＢと称される信号
線）と１組の電源ペアケーブルをあわせた６本のケーブ
ルがクロスしている。

【０３２７】１８１０は、ＩＥＥＥ１３９４インタフェ
ースに対応する送信側ノードである。ここでは仮に受信
側ノード１８０１であるプリンタにプリントデータを送
信するＰＣ（パーソナルコンピュータ）を想定する。Ｐ
Ｃが本来持つ機能の他、図に示されるように、以下に説
明される１８１１から１８１６の各機能ブロックを有す
る。

【０３２８】１８１１は、受信側ノード１８０１の１８
０２と同じＩＥＥＥ１３９４インタフェース制御部であ
る。１８０２と異なるのは後述するタイマー１８１５の
制御機能を有することである。タイマー１８１５の起動
および停止の処理はリクエストパケットの送信およびレ
スポンスパケットの受信をトリガーに自動的に行われ
る。

【０３２９】１８１２は、相手側である受信側ノード１
８０１から送られてきたリクエストパケットやレスポン
スパケットの受信処理および相手ノードから受けたＡＣ
Ｋ信号を処理する受信部である。トランザクションレイ
ヤおよびノードコントローラの一部の機能を実装する。
ＡＣＫの処理では、送信したパケットに対してどのよう
なＡＣＫが返ってきたのかを判断し、そのＡＣＫごと、
例えばビジーの場合にはリトライ処理を、エラーの場合
は上位レイヤに伝えるなど適切な判断、処理を行う。

【０３３０】１８１３は、ＩＥＥＥ１３９４インタフェ
ースのバス上に接続されたノードに対してパケットを送
信する送信部である。

【０３３１】受信側ノード１８０１に対して転送すべき
データが存在する場合はパケットの送信を行う。またト
ランザクションレイヤで管理するリトライパケットの送
信も行う（実際にはＩＥＥＥ１３９４インタフェース制
御部１８１１のＬＩＮＫチップによって自動的に行われ
る）。ここで生成、送信されたパケットはＩＥＥＥ１３
９４インタフェース制御部１８１１を経由してバス上に
流れる。

【０３３２】１８１４は、トランザクションリクエスト
によるパケットの送信を起点として相手ノードがレスポ
ンスパケットを返してくるまでの時間の計測結果から相
手側ノード（受信側ノード１８０１）のパケット受信処
理能力を推定する処理能力推定部である。単純な場合だ
と受信側ノード１８０１のパケット処理時間を計測時間
と同等と見なして、それ以上短い間隔でパケットを送信
した場合には受信側ノード１８０１の処理能力を上まわ
ることになる（デバイスビジーになる）と判断する。つ
まり計測時間より短い間隔ではパケットを連続送信しな
いように送信間隔を設定するよう判断する。

【０３３３】実際にはバスに接続されたノードの個数
や、そのノードのうちアイソクロナス転送を行うノード
がいくつあるかなどの様々な情報も加味して処理能力値
を判断する。判断は各種パラメータによる演算処理でも
行えるし、テーブルによっても行える。

【０３３４】１８１５は、リクエストパケットの送信か
らレスポンスパケットの受信までの時間を計測するタイ
マーである。タイマー１８１５の起動を有効にするかど
うかの設定は処理能力推定部１８１４がＩＥＥＥ１３９
４インタフェース制御部１８１１を介して行う。実際の
タイマー１８１５の起動、停止、カウンタ値のクリアは
ＩＥＥＥ１３９４インタフェース制御部１８１１が行
う。時間計測のために専用のハードウェアタイマーを設
けることもできるが、ここでは分割トランザクションの
ためのスプリットタイムアウトを監視するためのタイマ
ーを利用する。それによって特別な準備がないノードで
も同様の計測を簡単に行うことができる。タイマー１８
１５は、レスポンスパケット受信時にカウント値を他の
レジスタに格納し、自動的に値をクリアする機能を有す
る。また、カウンタ値のクリアをマニュアル操作でも行
えるようにし、その切り換えも設定できる。

【０３３５】１８１６は、処理能力推定部１８１４で判
断した受信側ノード１８０１の受信処理能力推定情報か
ら、パケットを連続して送信する際のパケット送信間
隔、受信側ノード１８０１がビジーになった場合のリト
ライ処理（トランザクションレイヤおよびアプリケーシ
ョンレイヤ管理のリトライ処理両方）におけるリトライ
回数とリトライパケットの送信間隔の設定を行う送信制
御処理部である。

【０３３６】ここで送信側ノードにおいてどのように制
御がなされていくかを簡単に説明する。送信側ノード１
８１０は、まず受信側ノード１８０１のコンフィグレー
ションＲＯＭ１８０５に格納されている情報を、リード
トランザクションによって獲得するためパケットを送信
する。

【０３３７】その際リードリクエストのパケット送信と
同じタイミングでタイマー１８１５を起動する。受信側
ノード１８０１は受信処理を終えてレスポンスパケット
を送信するが、そのレスポンスパケットの受信時にタイ
マーを停止させ、カウンタ値（実際にはパケットを送信
してからレスポンスパケットが返るまでの時間）を把握
する。同一のノードに対して連続してパケットの送信を
行う場合、たとえばプリンタやスキャナデバイスのよう
に大容量のデータ送信が必要となる場合には、パケット
を連続して送信する際の送信間隔を計測時間から推定し
た処理能力値に基づいて設定する。また併せてリトライ
の回数やリトライパケットの送信間隔も規定する。

【０３３８】上記動作は、受信側ノード１８０１のコン
フィグレーションＲＯＭ１８０５の内容をリードトラン
ザクションによって読み込む際に受信処理能力を測ろう
とするもので、特別のパケット送信をすることなく、通
常のパケットのやりとりの中で目的を実現できるという
メリットがある。ここではリードトランザクションを使
用して時間測定をする場合について説明しているが、こ
れがライトトランザクションやロックトランザクション
であっても同様の目的を達成することができる。ライト
トランザクションの場合は、データペイロードサイズと
して任意の値を設定することによって、より実際の転送
の状況に近い環境でパケット送信を行うことができる。

【０３３９】受信側ノード１８０１では、指定されたオ
フセットアドレスが無効であるなどして実際には受信し
たデータの処理まで行われない可能性もあるが、ＬＩＮ
ＫチップのＦＩＦＯにそれなりに大きなサイズのパケッ
トを受信して、それを受信バッファ１８０８に格納する
までの処理は行われるため、インタフェースの処理能力
を測るには十分である。

【０３４０】送信側ノード１８１０がアイソクロナス・
ノードでかつ受信側ノード１８０１がアイソクロナス・
リソース・マネージャの機能を持つノードである場合に
は、ロックトランザクションを使用することも可能であ
る。アイソクロナス転送を行うノードは、実際に転送を
行う前にアイソクロナス転送用のバンド幅とチャネルを
それぞれ獲得する必要がある。

【０３４１】バンド幅とチャネル獲得はアイソクロナス
・リソース・マネージャの実装するレジスタに対するロ
ックトランザクションによって行われる。この獲得動作
を行う際処理能力をはかるための時間測定を行うことが
できる。リード、ライトおよびロックの各トランザクシ
ョンでは各々性格も異なるため、同じ計測時間が得られ
たとしても処理能力としては異なる判断を下すこともで
きる。

【０３４２】図１９は第８実施形態における処理の流れ
を示したフローチャートである。

【０３４３】ここでは、送信側ノードが受信側ノードに
対してリードリクエストのパケットを送信し、レスポン
スパケットを受信することで処理能力推定し、その判断
結果に基づきパケットの連続送信の制御を行う過程につ
いて説明する。図１８のところでも説明したが、リード
リクエストのパケット送信だけではなく、ライトやロッ
クのリクエストによるパケット送信でも同様の効果を上
げられる。

【０３４４】ステップＳ１９０１では、送信側ノードは
受信側ノードに対してリードトランザクションのリクエ
ストを行う。具体的には、受信側ノードの持つコンフィ
グレーションＲＯＭ１８０５の内容を獲得するために情
報が格納されているアドレスを指定してパケットを送信
する。

【０３４５】ステップＳ１９０２では、タイマー１８１
５を起動する。フローチャートでは表現上Ｓ１９０１で
リクエストのパケットを送信してからタイマー１８１５
を起動するように示されているが、実際にはパケット送
信と同時にタイマー１８１５を起動する。

【０３４６】ステップＳ１９０３では、送信したリクエ
ストに対するＡＣＫ信号を受信する。ステップＳ１９０
１のパケット送信ではリードトランザクションをリクエ
ストしたため分割トランザクションとなることが予想さ
れる。その場合通常であればACK_pendingが戻ってくる
ので受信したＡＣＫ信号がpendingであるかどうかを判
断する。ACK_pendingの場合はステップＳ１９０４へす
すみ、それ以外を受信した場合はステップＳ１９０９へ
すすむ。

【０３４７】ステップＳ１９０４では、ステップＳ１９
０１で行ったリクエストに対するレスポンスのパケット
を受信する。これによってコンフィグレーションＲＯＭ
１８０５内の情報を獲得する。

【０３４８】ステップＳ１９０５では、ステップＳ１９
０２で起動したタイマー１８１５を停止する。こちらも
表現上レスポンスパケットを受信してからタイマー１８
１５を停止するよう示されているが、実際にはレスポン
スパケット受信と同時にタイマー１８１５を停止する。

【０３４９】ステップＳ１９０６では、停止したタイマ
ー１８１５からカウント値を取得する。本実施形態で
は、タイマー１８１５停止と同時にその値を別のレジス
タに格納し、タイマー１８１５自体のカウント値はクリ
アする。格納されたカウント値は処理能力推定部１８１
４で用いられる。

【０３５０】ステップＳ１９０７では、取得したカウン
タ値、実際にはパケットを送信してからレスポンスが返
ってくるまでの時間を元に受信側ノード１８０１のパケ
ット受信処理能力を推定する。

【０３５１】ステップＳ１９０８では、受信処理能力の
判断に基づいて送信側ノードの送信制御値、具体的には
連続したパケットの送信を行う場合のパケット送信間隔
やリトライ回数やリトライパケットの送信間隔の値を設
定し、受信側ノード１８０１に対して連続した送信を行
う場合に備える。

【０３５２】ステップＳ１９０９では、ステップＳ１９
０３でACK_pending以外を受信した、つまりエラーやビ
ジーの状態であるのを受けてタイマー１８１５を停止す
る。またこのときステップＳ１９０１でリクエストした
トランザクションが失敗したと判断しエラー処理を行
う。転送のリカバリー（アプリケーションレイヤで管理
するレベルの再送処理）は行わない。

【０３５３】ステップＳ１９１０では、再度パケットを
送信するかどうか判断する。これはＳ１９０１と同じ内
容のリクエストを行ってもいいし、別のトランザクショ
ンとして向じリードのリクエストでもアドレスを変えた
り、トランザクション自体の種類をリードからライトや
ロックに変更して送信することもできる。それらを含め
て再度何らかのパケットを送信する場合はステップＳ１
９１１へすすみ、そうでない場合は処理を終了する。

【０３５４】ステップＳ１９１１では、再度リクエスト
パケットを送信する。その後の処理はＳ１９０２以降と
同じである。

【０３５５】なお、一般には特定のノードに対して連続
送信を行う必要がある場合に限って上記処理を行えばよ
い。

【０３５６】同時に複数のノードに対して送信を行うこ
とは普通考えられないが、あるノードへの連続したデー
タの転送終了後に別のノードに対して同様な処理を行う
場合は、そのたびに上記受信処理能力の推定、判断の処
理を行うか、それともバスを構成する初期の段階で、す
べてのノードの受信処理能力情報をテーブルに格納し、
必要なときに設定し直すか選択することが可能である。

【０３５７】図２０は、第８実施形態におけるパケット
フロー（リードトランザクション）である。

【０３５８】ここでは、図１９と同じく送信側ノードが
受信側ノードに対してリードリクエストのパケットを送
信し、レスポンスパケットを受信することで処理能力推
定し、その判断結果に基づきパケットの連続送信の制御
を行う全体のプロセスについて説明する。

【０３５９】ステップＳ２００１では、送信制御処理部
１８１６が送信部１８１３に対してリードリクエストを
発行する。具体的には受信側ノード１８０１のコンフィ
グレーションＲＯＭ１８１５の情報を読むためのパケッ
ト送信のリクエストを行う。

【０３６０】ステップＳ２００２では、ＩＥＥＥ１３９
４インタフェース制御部（ＬＩＮＫおよびＰＨＹチッ
プ）１８１１からパケットが送信されるのと同時にタイ
マー１８１５を起動する。

【０３６１】ステップＳ２００３では、受信したリード
リクエストパケットに対して受信側ノードのインタフェ
ース制御部１８０２が自動的にＡＣＫ（ペンディング）
を返す。

【０３６２】ステップＳ２００４では、受信したリード
パケットがコンフィグレーションＲＯＭのリードである
ため、ノードコントローラが指定アドレスの値をレスポ
ンスとして返す準備を行う。図に記載のＴ２という時間
はリードリクエストパケットを受信してからレスポンス
を返すまでの時間、つまり受信処理時間に当たる。

【０３６３】ステップＳ２００５では、レスポンスデー
タの生成後ＩＥＥＥ１３９４インタフェース制御部１８
０２を介してレスポンスパケットを送信するリクエスト
を発行する。

【０３６４】ステップＳ２００６では、レスポンスパケ
ットの受信に対してＬＩＮＫチップが自動的にＡＣＫ
（完了）を返す。

【０３６５】ステップＳ２００７では、レスポンスパケ
ット受信と同時に起動していたタイマー１８１５を停止
する。Ｔ２はリクエストパケットを送信してからレスポ
ンスパケットを受信するまでの時間となる。

【０３６６】ステップＳ２００８では、タイマー１８１
５のカウント値を処理能力推定部１８１４に伝える。

【０３６７】ステップＳ２００９では、処理能力推定部
１８１４が受信側ノード１８０１が１パケット受信処理
したときの能力を推定する。

【０３６８】ステップＳ２０１０では、送信制御処理部
１８１６が推定した受信処理能力値に基づいて送信制御
のための各種パラメータを設定する。

【０３６９】ステップＳ２０１１は、連続したデータ送
信の最初のパケットリクエストである。

【０３７０】ステップＳ２０１２は、連続したデータ送
信の２番目のパケットリクエストである。

【０３７１】ステップＳ２０１１以降連続したパケット
の送信が行われるものとする。

【０３７２】３１３は、パケットリクエストの間隔であ
る。送信制御処理部１８１６で設定した値に基づいて、
連続したパケットの送信を行う。Ｔ３はパケットの送信
間隔である。

【０３７３】以上説明してきたように本実施形態の構成
によって、受信側ノードには特別な準備をすることなく
受信処理能力にあわせたパケットの送信が可能となる。
送信制御を行う側のノードも、分割トランザクションの
ためのスプリットタイムアウト監視用のハードウェアタ
イマーによって時間計測を行うため、それ専用のハード
ウェアを用意する必要がない。

【０３７４】また相手ノードのコンフィグレーションＲ
ＯＭのリード時に時間計測を行うような場合には、計測
のための特別なパケットの送信を行う必要がない。さら
には理想的には１回のパケット送信で転送が終了するた
め、ビジーによる転送の失敗など無効なトラフィックを
低減させることができる。それによってバスシステム全
体のパフォーマンスの向上が可能になると同時に、より
確実なパケットの転送を行うことができる。

【０３７５】

【他の実施形態】なお、本発明は、複数の機器（例えば
ホストコンピュータ、インタフェイス機器、リーダ、プ
リンタなど）から構成されるシステムに適用しても、一
つの機器からなる装置（例えば、複写機、ファクシミリ
装置など）に適用してもよい。

【０３７６】また、本発明の目的は、前述した実施形態
の機能を実現するソフトウェアのプログラムコードを記
録した記憶媒体（または記録媒体）を、システムあるい
は装置に供給し、そのシステムあるいは装置のコンピュ
ータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納された
プログラムコードを読み出し実行することによっても、
達成されることは言うまでもない。

【０３７７】この場合、記憶媒体から読み出されたプロ
グラムコード自体が前述した実施形態の機能を実現する
ことになり、そのプログラムコードを記憶した記憶媒体
は本発明を構成することになる。

【０３７８】また、コンピュータが読み出したプログラ
ムコードを実行することにより、前述した実施形態の機
能が実現されるだけでなく、そのプログラムコードの指
示に基づき、コンピュータ上で稼働しているオペレーテ
ィングシステム（ＯＳ）などが実際の処理の一部または
全部を行い、その処理によって前述した実施形態の機能
が実現される場合も含まれることは言うまでもない。

【０３７９】さらに、記憶媒体から読み出されたプログ
ラムコードが、コンピュータに挿入された機能拡張カー
ドやコンピュータに接続された機能拡張ユニットに備わ
るメモリに書込まれた後、そのプログラムコードの指示
に基づき、その機能拡張カードや機能拡張ユニットに備
わるＣＰＵなどが実際の処理の一部または全部を行い、
その処理によって前述した実施形態の機能が実現される
場合も含まれることは言うまでもない。

【０３８０】本発明にかかる通信制御方法をコンピュー
タで実行するためのプログラムを記憶した記憶媒体に
は、先に説明した（図１，図５、図８、図１１、図１
５、図１９、図２０に示す）フローチャートに対応する
プログラムコードが格納されることになる。

【０３８１】

【発明の効果】以上説明したように、本発明によれば以
下のいずれかの効果をあげることができる。

【０３８２】受信側ノードのパケット処理能力にあわせ
た送信側ノードのパケット送信が可能となる。

【０３８３】リトライ間隔と回数を適切に設定すること
により、無効なトラフィックを低減することが可能とな
り、バスシステム全体のパフォーマンスを向上させるこ
とが可能となる。

【０３８４】また、予め受信側ノードからアシンクロナ
ス転送によるパケット受信時の処理能力もしくは処理時
間を把握しておく必要や手間が不要となり、ＩＥＥＥ１
３９４プロトコルの範囲内でより確実なパケット送信を
行なえる。

【０３８５】上記の効果はＬＩＮＫチップなどのハード
ウエアによった構成においても、トランザクションレイ
ヤによるリトライ処理によって同様の効果が得られる。

【０３８６】コンフィグレーションＲＯＭの内容に基づ
き、通常の通信オペレーション内で処理時間の計測が可
能となり、処理時間の計測のための特別なパケット送信
が不要となる。

【０３８７】また、スプリットタイムアウト監視用タイ
マーを使用することで、送信ノード側でも特別なハード
ウエアを準備することなくパケット受信の確率を向上さ
せることが可能となる。

【図面の簡単な説明】

【図１】第１の実施形態におけるリトライ間隔および送
信間隔設定処理の流れを示すフローチャートである。

【図２】ＩＥＥＥ１３９４の各レイヤの構成図である。

【図３】第１実施形態におけるトランザクションレイヤ
内の機能ブロック図である。

【図４】第１実施形態における再送間隔および送信間隔
を示す模式図である。

【図５】第２実施形態における送信間隔、リトライ間隔
および送信間隔設定処理の流れを示すフローチャートで
ある。

【図６】第２実施形態におけるトランザクションレイヤ
内の機能ブロック図である。

【図７】第２実施形態における再送間隔および送信間隔
を示す模式図である。

【図８】第３実施形態におけるリトライ回数設定処理の
流れを示すフローチャートである。

【図９】第３実施形態におけるトランザクションレイ
ヤ、シリアルバスマネージメントレイヤおよびアプリケ
ーションレイヤ内の機能ブロック図である。

【図１０】第４実施形態のシステムの概要を示すブロッ
ク図である。

【図１１】第４実施形態における処理の流れを示したフ
ローチャートである。

【図１２】第４実施形態における受信可能パケット個数
情報を格納するノードユニークＩＤリーフのフォーマッ
トである。

【図１３】第５実施形態における受信バッファサイズを
格納するベンダ依存情報のフォーマットである。

【図１４】第６実施形態におけるシステムの概要を示す
ブロック図である。

【図１５】第６実施形態における処理の流れを示したフ
ローチャートである。

【図１６】第６実施形態における処理時間（もしくは処
理能力を示す値）を格納するノードユニークＩＤリーフ
のフォーマットである。

【図１７】第７実施形態における処理時間（もしくは処
理能力を示す値）を格納するベンダ依存情報のフォーマ
ットである。

【図１８】第８実施形態におけるシステムの概要を示す
ブロック図である。

【図１９】第８実施形態における処理の流れを示したフ
ローチャートである。

【図２０】第８実施形態におけるパケットフロー（リー
ドトランザクション）である。

───────────────────────────────────────────────────── フロントページの続きＦターム(参考） 5K032 BA04 CC03 CC04 CC12 CD01 DA01 DA12 DB20 DB26 5K033 AA01 BA04 CB03 CB04 CC01 DA01 DA12 DA13 DB13 DB16 5K034 AA01 DD01 EE11 FF02 FF12 FF15 FF18 GG02 GG06 HH01 HH02 HH11 HH12 HH48 HH49 HH50 HH53 HH65 MM03 MM12 NN12 NN13 NN22 NN26 PP03

Claims

【特許請求の範囲】

【請求項１】ネットワーク上のノード間で非同期転送
モードによってデータを授受する通信装置であって、非同期転送モードで送信したパケットの受信側ノードの
受信状況を判断する手段と、前記送信したパケットが受信できないとき送信側ノード
が再度、同一データパケットを送信する再送手段と、前記再送手段によるパケットの再送回数をカウントする
手段と、前記再送回数をカウントする手段によるカウント値が設
定回数以上のとき、送信側ノードは再送パケットではな
い次に送信すべき新規パケットの送信分から、パケット
の再送間隔を変更する手段と、を備えることを特徴とする通信装置。
【請求項２】ネットワーク上のノード間で非同期転送
モードによってデータを授受する通信装置であって、非同期転送モードで送信したパケットの受信側ノードの
受信状況を判断する手段と、前記送信したパケットが受信できないとき、アプリケー
ションレイヤの管理で再度同一データパケットを送信す
る再送手段と、前記再送手段によるパケットの再送回数をカウントする
手段と、前記再送回数をカウントする手段によるカウント値が設
定回数以上のとき、送信側ノードは再送パケットではな
い次に送信すべき新規パケットの送信分から、トランザ
クションレイヤの管理でパケットの再送間隔を変更する
手段と、を備えることを特徴とする通信装置。
【請求項３】ネットワーク上のノード間で非同期転送
モードによってデータを授受する通信装置であって、非同期転送モードで送信したパケットの受信側ノードの
受信状況を判断する手段と、前記送信したパケットが受信できないとき、アプリケー
ションレイヤの管理で再度同一データパケットを送信す
る再送手段と、前記再送手段によるパケットの再送回数をカウントする
手段と、前記再送回数をカウントする手段によるカウント値が設
定回数以上のとき、送信側ノードは再送パケットではな
い次に送信すべき新規パケットの送信分から、前記再送
手段によって送信されるパケットの再送間隔を変更する
手段と、を備えることを特徴とする通信装置。
【請求項４】前記再送間隔を変更する手段は、変更可
能な設定値を複数個、予め有することを特徴とする請求
項１乃至３のいずれかに記載の通信装置。
【請求項５】前記再送間隔を変更する手段は、タイマ
ーを使用して前記再送間隔を設定することを特徴とする
請求項１乃至３のいずれかに記載の通信装置。
【請求項６】前記再送間隔を変更する手段は、前記再
送間隔の設定をバスに接続されたノード単位に行うこと
を特徴とする請求項１乃至３のいずれかに記載の通信装
置。
【請求項７】前記再送間隔を変更する手段は、送信に
おける再送の回数および送信成功の可否を基準ととして
再送間隔の設定を行うことを特徴とする請求項１乃至３
のいずれかに記載の通信装置。
【請求項８】ネットワーク上のノード間で非同期転送
モードによってデータを授受する通信装置であって、バスリセットを検出するための手段と、前記検出手段による検出に従い、ネットワークのコンフ
ィグレーションを判断する構成判断手段と、前記構成判断手段の判断により、バスが２つのノードで
構成される場合もしくは、ノード数が２を超える場合
で、かつ、そのバスを構成するノードの中にバスマネー
ジャ若しくはアイソクロナスリソースマネージャの機能
を有するノードが存在しない場合は、トランザクション
レイヤで管理するリトライ回数をプロトコルで規定され
た最大値に設定する手段と、を備えることを特徴とする通信装置。
【請求項９】前記最大値として設定されるリトライ回
数はシングルフェーズリトライプロトコルを採用する場
合は１５回であることを特徴とする請求項８に記載の通
信装置。
【請求項１０】前記最大値として設定されるリトライ
回数はデュアルフェーズリトライプロトコルを採用する
場合は７回であることを特徴とする請求項８に記載の通
信装置。
【請求項１１】前記リトライ回数の初期値はプロトコ
ルで規定した最大値を設定することを特徴とする請求項
８に記載の通信装置。
【請求項１２】データ転送に周期的に連続した時間に
おいて、一定の帯域を保証してエラー発生時に再送手続
を行なわない周期転送モードを使用する通信装置は、前
記リトライ回数の初期値としてプロトコルで規定された
最大値未満の値を設定することを特徴とする請求項８に
記載の通信装置。
【請求項１３】前記構成判断手段によるネットワーク
コンフィグレーションに従いリトライ処理におけるパケ
ットの再送間隔及び再送回数をトランザクションレイヤ
もしくはアプリケーションレイヤの管理に切り替えるこ
とを特徴とする請求項８に記載の通信装置。
【請求項１４】前記構成判断手段はデータ転送として
非同期転送モードを使用するのか、同期転送モードを使
用するのかによって、バスに接続したデバイスの種類を
判別することを特徴とする請求項８に記載の通信装置。
【請求項１５】前記非同期転送モードを使用するデバ
イスには、ストレージ、プリンタ、スキャナのうちいず
れか一つを含むことを特徴とする請求項１４に記載の通
信装置。
【請求項１６】前記同期転送モードを使用するデバイ
スには、デジタルビデオカメラ、オーディオ、ＤＶＤ、
デジタルＴＶのうちいずれか一つを含むことを特徴とす
る請求項１４に記載の通信装置。
【請求項１７】ネットワーク上のノード間で非同期転
送モードによってデータを授受する通信装置であって、非同期転送モードで送信されたパケットを連続して受信
して格納する受信バッファと、前記受信バッファに格納できるパケットの個数情報を予
め格納しておく格納手段と、前記格納された個数情報に従いパケットの送信を制御す
る手段と、を備えることを特徴とする通信装置。
【請求項１８】ネットワーク上のノード間で非同期転
送モードによってデータを授受する通信装置であって、非同期転送モードで送信されたパケットを連続して受信
して格納する受信バッファと、前記受信バッファのサイズを予め格納しておく格納手段
と、前記格納されたバッファのサイズに従ってパケットの送
信を制御する送信制御手段と、を備えることを特徴とする通信装置。
【請求項１９】前記受信バッファに格納されている受
信パケット数を管理するための管理手段を備え、該管理手段は前記受信バッファがパケットを受信可能か
否かを判断し、受信可能な場合は前記送信制御手段に受
信可能である旨を報知することを特徴とする請求項１７
または１８に記載の通信装置。
【請求項２０】前記送信制御手段は、前記報知に従い
パケットの送信を制御することを特徴とする請求項１９
に記載の通信装置。
【請求項２１】前記管理手段は、バッファサイズ若し
くは最大の受信可能パケットの個数の条件に従って前記
受信バッファを管理することを特徴とする請求項１９に
記載の通信装置。
【請求項２２】前記バッファサイズ若しくは最大の受
信可能パケットの個数の条件はコンフィグレーションＲ
ＯＭに格納されているデータであることを特徴とする請
求項２１に記載の通信装置。
【請求項２３】前記管理手段は、受信したパケットの
処理が全て完了した後に、受信可能である旨を前記送信
制御手段に報知することを特徴とする請求項２０に記載
の通信装置。
【請求項２４】ネットワーク上のノード間で非同期転
送モードによってデータを授受する通信装置であって、非同期転送モードで送信するパケットの受信側ノードに
おける処理能力情報を予め格納しておく記憶手段と、前記予め格納された処理能力情報に基づき、送信したパ
ケットの処理状況を判定する判定手段と、前記判定手段の判定に従い、パケットの送信を制御する
制御手段と、を備えることを特徴とする通信装置。
【請求項２５】前記処理能力情報は、受信側ノードに
おけるパケットの処理時間であることを特徴とする請求
項２４に記載の通信装置。
【請求項２６】前記処理能力情報は、コンフィグレー
ションＲＯＭのノードユニークＩＤリーフに格納されて
いることを特徴とする請求項２４または２５に記載の通
信装置。
【請求項２７】前記処理能力情報は、コンフィグレー
ションＲＯＭのベンダ依存情報として格納されているこ
とを特徴とする請求項２４または２５に記載の通信装
置。
【請求項２８】前記処理時間の１サイクル単位時間
は、１２５μ秒であることを特徴とする請求項２５に記
載の通信装置。
【請求項２９】前記処理能力情報は、受信パケットに
関するリードトランザクションとライトトランザクショ
ンの２種類の値を有することを特徴とする請求項２４に
記載の通信装置。
【請求項３０】前記処理能力情報は、異なるデータペ
イロードサイズごとに値を有することを特徴とする請求
項２４に記載の通信装置。
【請求項３１】前記処理能力情報は、受信パケットに
関するリードトランザクションとライトトランザクショ
ンの２種類の値を有することを特徴とする請求項２４に
記載の通信装置。
【請求項３２】前記処理能力情報は、受信パケットに
関するリードトランザクションとライトトランザクショ
ンの２種類の値を有することを特徴とする請求項２４に
記載の通信装置。
【請求項３３】前記制御手段は、同一ノードに対して
連続したパケットを送信する際の送信間隔を制御するこ
とを特徴とする請求項２４に記載の通信装置。
【請求項３４】前記制御手段は、同一ノードに対して
連続したパケットを送信する際のリトライ間隔を制御す
ることを特徴とする請求項２４に記載の通信装置。
【請求項３５】前記制御手段は、同一ノードに対して
連続したパケットを送信する際のリトライ回数を制御す
ることを特徴とする請求項２４に記載の通信装置。
【請求項３６】前記制御手段は、ＩＥＥＥ１３９４プ
ロトコルのトランザクションレイヤ及びアプリケーショ
ンレイヤで前記送信間及びリトライ間隔を制御すること
を特徴とする請求項２４に記載の通信装置。
【請求項３７】ネットワーク上のノード間で非同期転
送モードによってデータを授受する通信装置であって、特定のトランザクションリクエストに基づくパケット送
信からレスポンスパケットを受信するまでの時間を計測
する計測手段と、前記計測手段による計測時間から受信側ノードの処理能
力を推定する推定手段と、前記推定手段による処理能力の推定結果に従って、パケ
ットの送信を制御する制御手段と、を備えることを特徴とする通信装置。
【請求項３８】前記特定のトランザクションリクエス
トは、リードトランザクション、ライトトランザクショ
ン、ロックトランザクションのいずれかであることを特
徴とする請求項３７に記載の通信装置。
【請求項３９】前記特定のトランザクションリクエス
トがリードトランザクションの場合は、受信側ノードの
コンフィグレーションＲＯＭから情報の読取りを行なう
ためのトランザクションが利用されることを特徴とする
請求項３８または３８に記載の通信装置。
【請求項４０】前記特定のトランザクションリクエス
トがライトトランザクションの場合は、データペイロー
ドサイズを任意にすることが可能であることを特徴とす
る請求項３８または３９に記載の通信装置。
【請求項４１】送信側ノードがアイソクロナス・ノー
ドであり、かつ、受信側ノードがアイソクロナス・リソ
ース・マネージャである場合は、アイソクロナス転送を
行なうための前準備であるバンド幅とチャンネルを獲得
するためのロックトランザクションを利用することを特
徴とする請求項３７または３８に記載の通信装置。
【請求項４２】前記計測手段は、分割トランザクショ
ンのスプリットタイムアウトを監視するためのハードウ
エアタイマであることを特徴とする請求項３７に記載の
通信装置。
【請求項４３】前記計測手段は、前記リクエストパケ
ット送信時に起動して、レスポンスパケット受信時に停
止することを特徴とする請求項３７に記載の通信装置。
【請求項４４】前記計測手段は、停止時に計測時間を
メモリに保存した後に、該計測時間をリセットすること
を特徴とする請求項３７に記載の通信装置。
【請求項４５】前記制御手段は、パケットの送信間隔
を制御することを特徴とする請求項３７に記載の通信装
置。
【請求項４６】前記制御手段は、リトライパケットの
送信間隔を制御することを特徴とする請求項３７に記載
の通信装置。
【請求項４７】前記制御手段は、パケットのリトライ
回数を制御することを特徴とする請求項３７に記載の通
信装置。
【請求項４８】前記制御手段は、トランザクションレ
イヤ及びアプリケーションレイヤの各々で、前記リトラ
イ回数及び送信間隔を制御することを特徴とする請求項
３７に記載の通信装置。
【請求項４９】前記送信ノードと受信ノードのデータ
通信はＩＥＥＥ１３９４インタフェースを使用すること
を特徴とする請求項１乃至４８のいずれかに記載の通信
装置。
【請求項５０】ネットワーク上のノード間で非同期転
送モードによってデータを授受するための通信制御方法
であって、非同期転送モードで送信されたパケットの受信側ノード
の受信状況を判断する工程と、前記送信されたパケットが受信できないとき送信側ノー
ドが再度、同一データパケットを送信する再送工程と、前記再送工程によるパケットの再送回数をカウントする
工程と、前記再送回数をカウントする工程によるカウント値が設
定回数以上のとき、送信側ノードは再送パケットではな
い次に送信すべき新規パケットの送信分から、パケット
の再送間隔を変更する工程と、を備えることを特徴とする通信制御方法。
【請求項５１】ネットワーク上のノード間で非同期転
送モードによってデータを授受する通信制御方法であっ
て、非同期転送モードで送信されたパケットの受信側ノード
の受信状況を判断する工程と、前記送信されたパケットが受信できないとき、アプリケ
ーションレイヤの管理で再度同一データパケットを送信
する再送工程と、前記再送工程によるパケットの再送回数をカウントする
工程と、前記再送回数をカウントする工程によるカウント値が設
定回数以上のとき、送信側ノードは再送パケットではな
い次に送信すべき新規パケットの送信分から、トランザ
クションレイヤの管理でパケットの再送間隔を変更する
工程と、を備えることを特徴とする通信制御方法。
【請求項５２】ネットワーク上のノード間で非同期転
送モードによってデータを授受する通信制御方法であっ
て、非同期転送モードで送信されたパケットの受信側ノード
の受信状況を判断する工程と、前記送信されたパケットが受信できないとき、アプリケ
ーションレイヤの管理で再度同一データパケットを送信
する再送工程と、前記再送手段によるパケットの再送回数をカウントする
工程と、前記再送回数をカウントする工程によるカウント値が設
定回数以上のとき、送信側ノードは再送パケットではな
い次に送信すべき新規パケットの送信分から、前記再送
工程によって送信されるパケットの再送間隔を変更する
工程と、を備えることを特徴とする通信制御方法。
【請求項５３】前記送信ノードと受信ノードのデータ
通信はＩＥＥＥ１３９４インタフェースを使用すること
を特徴とする請求項５０に記載の通信制御方法。
【請求項５４】前記再送間隔を変更する工程は、タイ
マーを使用して前記再送間隔を設定することを特徴とす
る請求項５０に記載の通信制御方法。
【請求項５５】前記再送間隔を変更する工程は、前記
再送間隔の設定をバスに接続されたノード単位に行うこ
とを特徴とする請求項５０に記載の通信制御方法。
【請求項５６】前記再送間隔を変更する工程は、送信
における再送の回数および送信成功の可否を基準ととし
て再送間隔の設定を行うことを特徴とする請求項５０に
記載の通信制御方法。
【請求項５７】ネットワーク上のノード間で非同期転
送モードによってデータを授受する通信制御方法であっ
て、バスリセットを検出するための工程と、前記検出工程による検出に従い、ネットワークのコンフ
ィグレーションを判断する構成判断工程と、前記構成判断工程の判断により、バスが２つのノードで
構成される場合もしくは、ノード数が２を超える場合
で、かつ、そのバスを構成するノードの中にバスマネー
ジャ若しくはアイソクロナスリソースマネージャの機能
を有するノードが存在しない場合は、トランザクション
レイヤで管理するリトライ回数をプロトコルで規定され
た最大値に設定する工程と、を備えることを特徴とする通信制御方法。
【請求項５８】前記最大値として設定されるリトライ
回数はシングルフェーズリトライプロトコルを採用する
場合は１５回であることを特徴とする請求項５７に記載
の通信制御方法。
【請求項５９】前記最大値として設定されるリトライ
回数はデュアルフェーズリトライプロトコルを採用する
場合は７回であることを特徴とする請求項５７に記載の
通信装置。
【請求項６０】前記リトライ回数の初期値はプロトコ
ルで規定した最大値を設定することを特徴とする請求項
５７に記載の通信制御方法。
【請求項６１】データ転送に周期的に連続した時間に
おいて、一定の帯域を保証してエラー発生時に再送手続
を行なわない周期転送モードを使用する通信制御方法
は、前記リトライ回数の初期値としてプロトコルで規定
された最大値未満の値を設定することを特徴とする請求
項５７に記載の通信制御方法。
【請求項６２】前記構成判断工程によるネットワーク
コンフィグレーションに従いリトライ処理におけるパケ
ットの再送間隔及び再送回数をトランザクションレイヤ
もしくはアプリケーションレイヤの管理に切り替えるこ
とを特徴とする請求項５７に記載の通信制御方法。
【請求項６３】ネットワーク上のノード間で非同期転
送モードによってデータを授受するための通信制御方法
であって、非同期転送モードで送信されたパケットを連続して受信
して受信バッファに格納する工程と、前記受信バッファに格納できるパケットの個数情報を予
めメモリに格納しておく格納工程と、前記格納された個数情報に従いパケットの送信を制御す
る工程と、を備えることを特徴とする通信制御方法。
【請求項６４】ネットワーク上のノード間で非同期転
送モードによってデータを授受する通信制御方法であっ
て、非同期転送モードで送信されたパケットを連続して受信
して受信バッファに格納する工程と、前記受信バッファのサイズを予めメモリに格納しておく
格納工程と、前記格納されたバッファのサイズに従ってパケットの送
信を制御する送信制御工程と、を備えることを特徴とする通信制御方法。
【請求項６５】前記受信バッファに格納されている受
信パケット数を管理するための管理工程を備え、該管理工程は前記受信バッファがパケットを受信可能か
否かを判断し、受信可能な場合は前記送信制御工程に受
信可能である旨を報知することを特徴とする請求項６３
または６４に記載の通信制御方法。
【請求項６６】前記送信制御工程は、前記報知に従い
パケットの送信を制御することを特徴とする請求項６５
に記載の通信制御方法。
【請求項６７】前記管理工程は、バッファサイズ若し
くは最大の受信可能パケットの個数の条件に従って前記
受信バッファを管理することを特徴とする請求項６５に
記載の通信制御方法。
【請求項６８】前記管理工程は、受信したパケットの
処理が全て完了した後に、受信可能である旨を前記送信
制御工程に報知することを特徴とする請求項６６に記載
の通信制御方法。
【請求項６９】ネットワーク上のノード間で非同期転
送モードによってデータを授受するための通信制御方法
であって、非同期転送モードで送信するパケットの受信側ノードに
おける処理能力情報を予めメモリに格納しておく記憶工
程と、前記予めメモリに格納された処理能力情報に基づき、送
信したパケットの処理状況を判定する判定工程と、前記判定工程の判定に従い、パケットの送信を制御する
制御工程と、を備えることを特徴とする通信制御方法。
【請求項７０】前記処理能力情報は、受信側ノードに
おけるパケットの処理時間であることを特徴とする請求
項６９に記載の通信制御方法。
【請求項７１】前記処理能力情報は、コンフィグレー
ションＲＯＭのノードユニークＩＤリーフに格納されて
いることを特徴とする請求項６９または７０に記載の通
信制御方法。
【請求項７２】前記処理能力情報は、コンフィグレー
ションＲＯＭのベンダ依存情報として格納されているこ
とを特徴とする請求項６９または７０に記載の通信制御
方法。
【請求項７３】前記処理時間の１サイクル単位時間
は、１２５μ秒であることを特徴とする請求項７０に記
載の通信制御方法。
【請求項７４】前記処理能力情報は、受信パケットに
関するリードトランザクションとライトトランザクショ
ンの２種類の値を有することを特徴とする請求項６９に
記載の通信制御方法。
【請求項７５】前記処理能力情報は、異なるデータペ
イロードサイズごとに値を有することを特徴とする請求
項６９に記載の通信制御方法。
【請求項７６】前記処理能力情報は、受信パケットに
関するリードトランザクションとライトトランザクショ
ンの２種類の値を有することを特徴とする請求項６０に
記載の通信制御方法。
【請求項７７】前記処理能力情報は、受信パケットに
関するリードトランザクションとライトトランザクショ
ンの２種類の値を有することを特徴とする請求項６９に
記載の通信制御方法。
【請求項７８】前記制御工程は、同一ノードに対して
連続したパケットを送信する際の送信間隔の制御である
ことを特徴とする請求項６９に記載の通信制御方法。
【請求項７９】前記制御工程は、同一ノードに対して
連続したパケットを送信する際のリトライ間隔を制御す
ることを特徴とする請求項６９に記載の通信制御方法。
【請求項８０】前記制御工程は、同一ノードに対して
連続したパケットを送信する際のリトライ回数を制御す
ることを特徴とする請求項６９に記載の通信制御方法。
【請求項８１】前記制御工程は、ＩＥＥＥ１３９４プ
ロトコルのトランザクションレイヤ及びアプリケーショ
ンレイヤで前記送信間及びリトライ間隔を制御すること
を特徴とする請求項６９に記載の通信制御方法。
【請求項８２】ネットワーク上のノード間で非同期転
送モードによってデータを授受するための通信制御方法
であって、特定のトランザクションリクエストに基づくパケット送
信からレスポンスパケットを受信するまでの時間を計測
する計測工程と、前記計測工程による計測時間から受信側ノードの処理能
力を推定する推定工程と、前記推定工程による処理能力の推定結果に従って、パケ
ットの送信を制御する制御工程と、を備えることを特徴とする通信制御方法。
【請求項８３】前記特定のトランザクションリクエス
トは、リードトランザクション、ライトトランザクショ
ン、ロックトランザクションのいずれかであることを特
徴とする請求項８２に記載の通信制御方法。
【請求項８４】前記特定のトランザクションリクエス
トがリードトランザクションの場合は、受信側ノードの
コンフィグレーションＲＯＭから情報の読取りを行なう
ためのトランザクションが利用されることを特徴とする
請求項８４または８３に記載の通信制御方法。
【請求項８５】前記特定のトランザクションリクエス
トがライトトランザクションの場合は、データペイロー
ドサイズを任意にすることが可能であることを特徴とす
る請求項８２または８３に記載の通信制御方法。
【請求項８６】送信側ノードがアイソクロナス・ノー
ドであり、かつ、受信側ノードがアイソクロナス・リソ
ース・マネージャである場合は、アイソクロナス転送を
行なうための前準備であるバンド幅とチャンネルを獲得
するためのロックトランザクションを利用することを特
徴とする請求項８２または８３に記載の通信制御方法。
【請求項８７】前記計測工程は、分割トランザクショ
ンのスプリットタイムアウトを監視するためのハードウ
エアタイマを利用して計測処理することを特徴とする請
求項８２に記載の通信制御方法。
【請求項８８】前記計測工程は、前記リクエストパケ
ット送信時に前記ハードウエアタイマを起動して、レス
ポンスパケット受信時に該タイマを停止することを特徴
とする請求項８２に記載の通信制御方法。
【請求項８９】前記計測工程は、レスポンスパケット
受信時に該タイマを停止する時に計測時間をメモリに保
存した後に、該計測時間をリセットすることを特徴とす
る請求項８２に記載の通信制御方法。
【請求項９０】前記制御工程は、パケットの送信間隔
を制御することを特徴とする請求項８２に記載の通信制
御方法。
【請求項９１】前記制御工程は、リトライパケットの
送信間隔を制御することを特徴とする請求項８２に記載
の通信制御方法。
【請求項９２】前記制御工程は、パケットのリトライ
回数を制御することを特徴とする請求項８２に記載の通
信制御方法。
【請求項９３】前記制御工程は、トランザクションレ
イヤ及びアプリケーションレイヤの各々で、前記リトラ
イ回数及び送信間隔を制御することを特徴とする請求項
８２に記載の通信制御方法。
【請求項９４】ネットワーク上のノード間で非同期転
送モードによってデータを送信する請求項１乃至４９の
いずれかに記載の通信装置と、前記通信装置によって送信されたデータを受信処理する
装置と、を有するデータ通信システム。
【請求項９５】前記データを受信処理する装置にはプ
リンタが含まれれることを特徴とする請求項９４に記載
のデータ通信システム。
【請求項９６】ネットワーク上のノード間で非同期転
送モードによってデータを授受するための通信制御方法
をコンピュータで実行するためのプログラムコードを格
納した記憶媒体であって、該プログラムコードが、請求項５０乃至９３のいずれかに記載の通信制御方法の
工程のコードを有することを特徴とする記憶媒体。