JP3733767B2

JP3733767B2 - node

Info

Publication number: JP3733767B2
Application number: JP843299A
Authority: JP
Inventors: 麻衣子播磨; 英雄土屋; 利明笹森
Original assignee: Omron Corp
Current assignee: Omron Corp
Priority date: 1999-01-14
Filing date: 1999-01-14
Publication date: 2006-01-11
Anticipated expiration: 2019-01-14
Also published as: JP2000209242A

Description

【０００１】
【産業上の利用分野】
本発明は、ノードに関するもので、より具体的には複数のノードをスイッチングハブにスター型に接続し、ノード間でフレームの送受信を行うＣＳＭＡ／ＣＤ方式のＬＡＮにおける送信時間間隔の制御の改良に関する。
【０００２】
【従来の技術】
図１は、一般的なスイッチングハブ１を利用したスター型ＬＡＮ（イーサネット等）のネットワーク構成の一例を示している。同図に示すように、複数のノード２は、スイッチングハブ１にスター型に接続されている。そして、各ノード２は、スイッチングハブ１との間で送信パケットの送受を行うようになっており、スイッチングハブ１は、受け取った送信パケットが他のノード宛ての場合には、その宛先のノード２に対して当該送信パケットを転送することにより、ノード２間の送信パケットの送受信を行うようになる。
【０００３】
そして、ＣＳＭＡ／ＣＤ方式のような衝突検出型のプロトコルでは、ネットワークを伝送する送信パケットが増大すると、衝突が発生しネットワークの帯域を減少してしまう。そこで、通常これを回避するために送信パケット量を制限するようになっている。そして、一例として衝突が発生した場合にスイッチングハブ１が、各ノード２に対して輻輳制御のパケットを送信し、そのパケットを受信した各ノード２が一定時間パケットの送信を停止するような制御を行うものがある。
【０００４】
【発明が解決しようとする課題】
しかしながら、上記した従来の装置では以下に示す問題があった。すなわち、輻輳制御が解除されると、各ノードがいっせいに送信を開始するおそれがあり、そうすると再度パケットの衝突が発生することになる。したがって、輻輳制御が頻繁に発生してしまうという問題がある。
【０００５】
また、頻繁にパケットを送信するノードが存在する場合に、係るノードにだけ送信権が渡り、他のノードがパケットを送信することができなくなるおそれもある。
【０００６】
本発明は、上記した背景に鑑みてなされたもので、その目的とするところは、上記した問題点を解決し、輻輳制御解除後にいっせいに各ノードがパケットを送信することによる衝突の再発生にともなう輻輳制御の頻繁な発生を未然に防止し、また、特定のノードに送信権が与えられ続けることも無く、全ノードに送信権が渡るようにネットワークトラフィックを適正化することのできるノードを提供することにある。
【０００７】
【課題を解決するための手段】
上記した目的を達成するために、本発明に係るノードは、フロー制御を行うネットワーク用のノードであって、輻輳制御パケットの受信を検出する検出手段（実施の形態では、「輻輳制御パケット判別部７」に相当）と、その検出手段で検出した輻輳制御パケットの受信回数に基づいて、送信待ち時間を調整する調整手段（実施の形態では、「輻輳制御パケット処理部１１」に対応）を備えて構成した（請求項１）。これを実現するのが第１の実施の形態である。
【０００８】
また、別の解決手段としては、輻輳制御パケットの受信を検出する検出手段と、その検出手段で検出した輻輳制御パケットの受信間隔を求める手段（実施の形態では、「パケット間隔測定部１４」に相当）と、前記求めた受信間隔に基づいて、送信待ち時間を調整する調整手段（実施の形態では、「送信待ち時間設定部１５」等に対応）を備えるように構成するようにしても良い（請求項２）。これを実現するのが第２の実施の形態である。
【０００９】
すなわち、フロー制御を行うネットワークでは、輻輳が発生した場合に、各ノードが接続されるスイッチングバス（「集線装置」とも称する）から各ノードに対して輻輳制御パケットが送信される。したがって、この輻輳制御パケットを受信しない場合には、各ノードは各自のタイミングで自由にパケットを送信することができ、また、輻輳制御パケットを受信した場合には、送信待ち時間経過後でなければパケット送信できなくなる。そして、本発明では、係る送信待ち時間をノード側で可変・調整することを特徴としている。
【００１０】
すなわち、ネットワーク内でのパケットの伝送が混んでいるほど輻輳制御パケットが頻繁に発生される。そこで、請求項１では、輻輳制御パケットの受信回数に基づいて送信待ち時間を調整するようにした。つまり、受信回数が多くなるほど送信待ち時間を増加させることにより、混み具合に応じて待ち時間が調整される。
【００１１】
また、ここでいう受信回数は、単純に絶対値としての受信回数でも良いし、一定時間内での相対的な値でも良い。さらには、例えば実施の形態で示すように、一定の条件に合致すると、一旦増加した送信待ち時間を減らす機能を付加するとなお良い。すなわち、輻輳制御パケットが受信しなくなると、ネットワーク効率を考慮し、送信待ち時間は短い方が良い。このとき、直ぐに送信待ち時間を戻すのではなく、徐々に短くするのがよい。つまり、直ぐに０にして即送信の状態にすると、再度輻輳が発生するおそれが高いからである。そこで、発生回数等を考慮し、徐々に短くするとよい。
【００１２】
さらには、本発明は具体的に受信回数を覚えている必要はない。つまり、実施の形態のように受信する都度送信待ち時間を増加するというように、必ずしも回数と送信時間を関連付けておかなくても良い。もちろん、現在までの受信回数を記憶し、その受信回数に応じた送信待ち時間に設定するようにしても良い。また、その場合に、受信回数は、積算値ではなく、一定の条件で減算していく（例えば、実施の形態のように、輻輳制御パケットを受信すること無く連続して所定数送信が成功する等）ようにするとよい。
【００１３】
また、受信間隔が長い場合には、ネットワークが比較的空いていると判断できる。そこで請求項２では、例えば受信間隔が長い場合には送信待ち時間間隔を短くし、受信間隔が短い場合には送信待ち時間間隔を長くする。
【００１４】
本発明に係るノードは、例えば、ネットワークに接続される各種装置、つまり、ネットワーク通信機能を持った機器であり、一例としてＦＡ等における各種制御機器やセンサ等を接続し、協調制御，同期制御などをするためのネットワーク（ＬＡＮ）等に接続されるものがある。そして、ノードの具体例としては、例えば一般的なＰＬＣや、センサターミナル、Ｉ／Ｏターミナル等がある。さらには、パソコン等の各種の端末や中継装置も含む。もちろん、ＦＡ用に限ることはなく、各種のネットワークに接続されるものが含まれるのは言うまでもない。
【００１５】
【実施の形態】
以下、本発明の好適な一実施の形態を説明する。まず通信システムの実施の形態の全体の構成は、図１に示す従来のものと同様である。つまり、スイッチングハブ１に対して複数のノード２が伝送路３を介してスター状に接続され、各ノード２は、所望のノード２に対してパケットを送信する際に、スイッチングハブ１を経由して行うようになっている。そして、本発明では、ノード２の内部構造を改良している。
【００１６】
まず、スイッチングハブ１は、図２に示すように構成されている。同図に示すように、伝送路３に接続される物理層ＩＦ１ａを介してパケットを送受信する。この物理層ＩＦ１ａが接続される伝送路３の先には、個々のノード２が接続されている。そして、物理層ＩＦ１ａの上位には、切替イーサネットコントローラ（中継部）１ｂが接続され、物理層ＩＦ１ａを介して受信したパケットは、切替イーサネットコントローラ１ｂに渡され、所望のノードに接続された物理層ＩＦ１ａに転送される。
【００１７】
また、実際には直接転送されるのではなく、切替イーサネットコントローラ１ｂが受け取ったパケットは、そのパケットに格納された優先度情報にしたがって一旦低優先度バッファ１ｃと高優先度バッファ１ｄのいずれかに格納される。そして、係るバッファ１ｃ，１ｄに格納されたパケットは、所定の順で呼び出され、切替イーサネットコントローラ１ｂが、そのパケットの宛先ノードに対応する物理層ＩＦ１ａに送る。このとき、高優先度バッファ１ｄに格納されたパケットを優先的に処理するようになる。
【００１８】
さらに、フロー制御機能部１ｅを有している。このフロー制御機能部１ｅは、低優先度バッファ１ｃ並びに高優先度バッファ１ｄを監視し、バッファが一杯になると、その旨切替イーサネットコントローラ１ｂに送る。すると、切替イーサネットコントローラ１ｂは、すべての物理層ＩＦ１ａに対して輻輳制御パケットを送信し、各ノードへ送信一時停止を要求するようになっている。
【００１９】
そして、このスイッチングハブ１の機能をフローチャートで示すと、図３に示すようになる。すなわち、パケット受信をした（ＳＴ１）ならば、その受信したパケットをバッファ１ｃ，１ｄに格納する。次いで、フロー制御機能部１ｅが稼動し、バッファがフルであるかを判断し（ＳＴ３）、フルの場合にはフロー制御をすべく輻輳制御パケットを送信する（ＳＴ４）。その後、次の受信に備えるべくステップ１に戻る。なお、図示したフローチャートは、本発明に関係する部分のみ示しており、実際には、バッファがフルでない場合には、いずれかのバッファに格納されたパケットを送信する処理等が実行されるのはもちろんである。また、図示の例では、低優先度バッファ１ｃと高優先度バッファ１ｄを持ち、優先度情報にしたがって送信順を制御できる形式のものを示したが、本発明はこれに限ることはなく、優先度情報に対応しないネットワークに接続されるノードにも適用することができる。
【００２０】
また、本発明に係るノード２の第１の実施の形態としては、図４に示すように構成されている。すなわち、イーサネットコントローラ５を介して伝送路３上を伝送されてきた自己宛てのパケットをデータ受信部６が受信する。この受信したパケットは、検出手段たる輻輳制御パケット判定部７に送られ、そこにおいて輻輳制御パケットか通常のデータパケットであるかを判断する。そして、データパケットの場合にはその受信したパケットを上位ＩＦ部８に送り、そこにおいて受け取ったデータ内容に応じた適宜処理等をする。
【００２１】
一方、パケットを送信する場合には、その送信するパケットが上位ＩＦ部８から送信データキュー９に与えられる。そして、データ送信部１０は送信要求にしたがって、送信データキュー９の先頭から順にイーサネットコントローラ５を介してパケットを送信する。係る基本構成は従来と同様であるので、その詳細な説明を省略する。
【００２２】
ここで本発明では、輻輳制御パケット処理部１１を設け、輻輳制御パケットを受信した場合にノード２側で輻輳に伴う送信待ち時間（パケット送信時間間隔）を決定し、データ送信部１０は輻輳制御パケット処理部１１で決定された送信待ち時間にしたがって一定時間（内蔵する送信待ちタイマ１０ａにより計測）分の間隔を空け、送信するようにしている。
【００２３】
そして、輻輳制御パケット処理部１１は、輻輳制御パケットを受信すること無く連続して送信できた回数を計数する送信カウンタ１２と、その送信カウンタ１２の計数結果並びに輻輳制御パケットの受信回数に基づいて送信待ち時間を決定する送信待ち時間設定部１３とを有している。つまり、輻輳制御パケット判別部７から輻輳制御パケット処理部１１に対して与えられる輻輳制御パケットの検出信号は、送信待ち時間設定部１３と送信カウンタ１２に与えられ、データ送信部１０から送信カウンタ１２に対して送信情報（送信したことを報知）が与えられるようになっている。そして、送信カウンタ１２は、送信情報を受信するごとにカウンタを１インクリメントし、輻輳制御パケット判別部７から検出信号を受信するとカウンタ値を０にリセットするようになっている。
【００２４】
そして、送信待ち時間設定部１３の基本的な処理アルゴリズムとしては、輻輳制御パケットを受信するごとに、送信待ち時間を増加していき、輻輳制御パケットを受信しない間に送信が一定回数連続して行えた場合（送信カウンタ１２のカウンタ値が基準値に達した場合）には、送信待ち時間を減少させるようにする。そして、本形態では、基準時間ａを設定し、係る基準時間単位で増加・減少を行うようにした。
【００２５】
具体的な例を示すと、例えば図５（ａ）に示すように、通常は要求を受けると即時に送信をする。そして、フロー制御（輻輳制御パケット）を受信すると、その受信した時からタイマを駆動し、送信待ち時間ａだけ計時する。そして、その送信待ち時間の間に要求を受けると、その送信待ち時間を経過後に送信するようになる。また、同図（ｂ）に示すように、送信の最中にフロー制御を受けた場合には、送信終了後にタイマをスタートして送信待ち時間ａを計測する。
【００２６】
また、同図（ｃ）に示すように、すでに輻輳を生じ基準時間ａの送信待ち時間でもって送信をしている場合に、さらにフロー制御を受けた場合には、送信待ち時間を基準時間ａだけ増加させる。つまり、次の送信待ち時間は２ａとなる。さらに、同図（ｄ）に示すように、すでに送信終了後の送信待ち時間計測中にフロー制御を受けた場合には、その計測中に送信待ち時間をａだけ増やすことはなく、当初に設定した待ち時間（この場合にはａ）だけ経過後に送信を行い、係る送信の次の送信待ち時間の際に反映させる（図示の場合には２ａにする）。
【００２７】
このような処理を行うことにより、フロー制御を受けつづけていると、送信待ち時間を徐々に増やすように各ノード側で対応するので、輻輳の発生が抑制される。しかも、フロー制御を受けなくなるまで送信待ち時間を増加させるということは、換言すると、その時のネットワークトラフィックにとって最適な、つまり、輻輳を生じさせない最短（あるいはそれに近い）の送信時間間隔でパケットを送信していることになる。さらに、各ノードに送信権が行き渡るようになる。
【００２８】
一方、このように送信待ち時間で送信をしていた場合に、その後のネットワークの状態が変化し、ネットワーク上を伝送されるパケットが減少し、設定した送信待ち時間では余裕があり過ぎるようになると、ネットワーク効率が低下する。そこで、フロー制御を受けなくなったならば、送信待ち時間を減少させるように制御する機能も持たせている。つまり、図６（ａ）に示すように、所定回数（この例では３回）連続してフロー制御を受けること無く送信できた場合に、基準時間ａだけ送信待ち時間を減らすようにした（図示の例では、２ａからａに短縮している）。もちろん、短くした結果フロー制御が発せられたならば再度送信待ち時間を増加すれば良い。このようにすることにより、常に最適なネットワークトラフィックを実現できる。
【００２９】
さらにまた、同図（ｂ）に示すように、送信待ち時間の間に要求が無くタイムアウトし（２回目の送信の後）、その時間経過後に要求があった場合には、即時に送信を開始するようにする。その場合に、その送信後の送信待ち時間は、前回と同じ（２ａ）になる。但し、すでに３回連続してフロー制御を受けること無く送信している場合に、もちろん基準時間ａだけ減少した時間となる（図示の場合には、４番目の送信のあとの送信待ち時間がａに減少する）。
【００３０】
そして、係る処理を行うための処理フローは図７以降に示すようになる。すなわち、パケット受信に伴う処理は図７，図８となり、要求を受けた発信に伴う処理は図９に示すようになる。まず、パケット受信に伴う処理としては、初期設定として送信待ちタイマ１０ａの送信待ちタイマ値及び送信カウンタ値を０にセットする（ＳＴ１０，１１）。
【００３１】
ここで、送信待ちタイマ値は、送信待ちタイマ１０ａの作動時間であり、ここで決定されるタイマ値にしたがって送信待ちタイマ１０ａは稼動し、タイムアウトするとパケットを送信するようになる。したがって、タイマ＝０の場合には、要求があると同時にパケットの送信をすることになる。また、送信カウンタ値は、フロー制御を受けること無く連続してパケットを送信することのできた回数である。
【００３２】
そして、パケットを受信したならば（ＳＴ１２）、それが輻輳制御パケット（フロー制御）であるか否かを判断する（ＳＴ１３）。この判断は、輻輳制御パケット判別部７が実行する。そして、輻輳制御パケットでない場合には、ステップ１２に戻り、次のパケット受信に備える。
【００３３】
一方、輻輳制御パケットの場合には、ステップ１４に進み、送信待ちタイマ値を１単位時間（ａ）増加する。つまり、初期値は０としているのでタイマ値はａになる。したがって、送信待ちタイマ値がａのときに輻輳制御パケットを受信すると、タイマ値は２ａとなる。ここで決定されたタイマ値が、最終的に送信待ちタイマ１０ａにセットされる。その後、送信完了カウンタを０にクリアする（ＳＴ１５）。
【００３４】
次いで、現在送信中か否かを判断し（ＳＴ１６）、送信中の場合には、その送信の終了後に送信タイマをスタートさせる（ＳＴ１７）。つまり、データ送信機能部１０（送信待ちタイマ１０ａ）に対して、タイマスタート命令を発する。そして、この命令を受けた送信待ちタイマ１０ａは、ステップ１４で設定したタイマ値だけ計時し、タイムアウトする。そして、係る処理は、図５（ｂ），（ｃ）などに対応する。
【００３５】
一方、送信中でない場合には、送信待ちタイマ１０ａが作動中か否かを判断する（ＳＴ１８）。そして、送信タイマが作動していないときには、直ぐに送信待ちタイマをスタートさせる（ＳＴ１９）。係る処理は、図５（ａ）に示した状態に対応する。
【００３６】
さらにまた、送信待ちタイマ１０ａが作動中の場合には、次の送信終了後に送信待ちタイマ１０ａをスタートさせる（ＳＴ２０）。つまり、図５（ｄ）に示した状態に対応する。そして、図７，図８に示すフローチャートのうち、ステップ１２，１３を除き、輻輳制御パケット処理部１１の機能を示している。
【００３７】
また、ノードの送信に伴う処理は、図９に示すように、送信待ちパケットの有無を判断し（キューに存在し、また要求が発せられることからわかる）、ある場合には、送信待ちタイマーがタイムアウトになっているか否かを判断し、タイムアウトになっている場合には、パケットを送信する（ＳＴ２１〜ＳＴ２３）。したがって、タイマ値が０であったり、すでにタイムアウトしている場合には、要求とともに即時にパケットを送信することになり、また、タイマ作動中の場合には、タイマアウトを待ってパケットを送信することになる。
【００３８】
そして、パケット送信が完了したならば、送信完了カウンタのカウンタ値を１加算し（ＳＴ２４）、さらに、送信完了カウンタのカウンタ値が所定回数（本形態では、「３回」）に達したか否かを判断し（ＳＴ２５）、達している場合にはステップ２６に進み、送信完了カウンタを０にクリアするとともに、送信待ちタイマ値を１単位時間（ａ）だけ減少させる（ＳＴ２６，ＳＴ２７）。これは、図６（ａ）中、送信待ち時間が「２ａ」から「ａ」に減少された状態に対応する。その後、送信待ちタイマを再スタートさせる（ＳＴ２８）。係る処理が、送信終了後に直ぐに送信待ちタイマをスタートする各種の例に対応する。
【００３９】
また、本実施の形態の送信時間間隔増加の仕組みを一連の流れに沿って示すと、図１０のようになる。つまり、当初は要求があると即送信し（２回目まで）、２番目の送信の後フロー制御を受信すると、そこから送信時間間隔（ａ）だけタイマで計測する。そして、そのタイムアウト前に要求があったので、タイムアウトを待って送信（３番目）する。
【００４０】
次いで、その３番目の送信後、自動的に送信時間間隔（ａ）だけタイマを計測する。そして、タイムアウト後に要求があると、即送信（４番目）をする。この４番目の送信の最中にフロー制御を受信すると、送信時間間隔はａだけ加算され、合計２ａとなるので、送信終了後２ａだけタイマで計測し、その間送信待ちとなり、タイムアウト後に送信（５番目）する。
【００４１】
この５番目の送信時にはフロー制御がかからなかったので、次の送信待ち時間も２ａのままとなる。また、送信待ち時間中にフロー制御があっても、それが反映されるのはその次であるので、６番目の送信も５番目の送信終了後２ａだけ待った後行われ、６番目の送信後の送信待ち時間が３ａになる。
【００４２】
一方、送信時間間隔減少の仕組みを一連の流れに沿って示すと、図１１のようになる。まず、同図（ａ）に示すように、現在の送信時間間隔が３ａとし、連続して３回送信する間にフロー制御がかからなかった場合には、その次の回からは送信時間間隔をａだけ減らして２ａとする。そしてさらに３回連続してフロー制御を受けること無く送信が行えた場合には、次の送信時間間隔はａとなる。
【００４３】
また、同図（ｂ）に示すように、送信時間間隔３ａだけ待って送信を行った後にそのまま次の送信時間間隔３ａを待つ。この時、要求がかからずにタイムアウトした場合には、次の要求があると即送信する。この点は、図１０における４番目の送信のときと同様である。また、このようにタイムアウトした後、即送信を行ったような場合でも、送信完了カウンタはクリアされないので、図１１（ｂ）における４番目の送信の際には、それまでにすでに３回連続してフロー制御を受けることなく送信しているため、送信時間間隔は２ａに減少している。
【００４４】
上記したように、本実施の形態では、送信待ち時間の減少は、ノードからのパケット送信の頻度によっても調整される。つまり、比較的頻繁にパケット送信するノードは、頻繁にパケット送信しないノードに比べて送信待ち時間の減少が早く行われる。このように、輻輳制御パケットが送られなくなってからの送信待ち時間の減少タイミングが各ノードでずれるので、より確実に解除後のパケットの再衝突のおそれが可及的に抑制され、また、各ノードの発送タイミングに応じた送信待ち時間が設定されることにより、より効率的な伝送ができる。
【００４５】
図１２は、本発明に係るノードの第２の実施の形態を示している。同図に示すように、輻輳制御パケット処理部１１′の内部構造が異なっている。すなわち、パケット間隔測定部１４と、送信待ち時間設定部１５を有している。パケット間隔測定部１４は、輻輳制御パケット判別部７から受け取った輻輳パケットの検出信号によりオン／オフするタイマを備え、輻輳パケットを受信する間隔を計測するようになっている。
【００４６】
そして、送信待ち時間設定部１５は、パケット間隔測定部１４で測定した輻輳パケット受信間隔に基づいて送信待ち時間を設定するようになっている。つまり、輻輳パケット受信間隔が長い場合には、ネットワークが込み合っていないので輻輳待ち時間を短くして迅速にパケット送信が可能になるように制御し、輻輳パケット受信間隔が短い場合には、ネットワークが込み合っているので輻輳待ち時間を長くし輻輳の発生を抑制するように制御するようにしている。そして、具体的には、図１３〜図１５に示すフローチャートのようになっている。
【００４７】
すなわち、まず、初期設定として送信待ちタイマ値を０にするとともに、輻輳パケット受信間隔、つまり、パケット間隔測定部１４内の受信タイマを０にする（ＳＴ３１，３２）。その後、受信タイマをスタートする（ＳＴ３３）。
【００４８】
次いで、パケットの受信を待ち（ＳＴ３４）、パケットを受信したならばそれが輻輳制御パケットであるか否かを判断する（ＳＴ３５）。そして、輻輳制御パケットの場合には、受信タイマをストップし（ＳＴ３６）、前回輻輳制御パケットを受信してから今回受信するまでの受信時間間隔を求め、その受信時間間隔が基準時間ｔより小さいか否かを判断する（ＳＴ３７）。なお、実際には、受信タイマのタイマ値を読むことにより、受信時間間隔は求められる。
【００４９】
そして、受信時間間隔が基準値ｔより短い場合には、送信待ちタイマ値を１単位時間だけ増加し（ＳＴ３８）、逆に受信時間間隔が基準値ｔより長い場合には、送信待ちタイマ値を１単位時間だけ減少する（ＳＴ３９）ような制御を行う。その後、次の輻輳パケット受信時間間隔の監視を行うべく、輻輳制御パケット受信時間間隔を０にセットした後（ＳＴ４０）、受信タイマをスタートさせる（ＳＴ４１）。
【００５０】
次いで、現在送信中か否かを判断し（ＳＴ４２）、送信中の場合には、その送信の終了後に送信タイマをスタートさせる（ＳＴ４３）。つまり、データ送信機能部１０（送信待ちタイマ１０ａ）に対して、タイマスタート命令を発する。そして、この命令を受けた送信待ちタイマ１０ａは、ステップ３８またはＳＴ３９で設定したタイマ値だけ計時し、タイムアウトする。一方、送信中でない場合には、送信待ちタイマ１０ａが作動中か否かを判断する（ＳＴ４４）。そして、送信タイマが作動していないときには、直ぐに送信待ちタイマをスタートさせる（ＳＴ４５）。また、送信タイマが作動中の場合には、次の送信終了後に送信待ちタイマをスタートする。その後、ステップ３４に戻り、上記した各処理（輻輳パケットの受信時間間隔の監視並びにその受信間隔に基づく送信待ちタイマ値の設定）を繰り返し行う。
【００５１】
一方、送信処理は図１６に示すように、送信待ちパケットの有無を判断し（キューに存在し、また要求が発せられることからわかる）、ある場合には、送信待ちタイマがタイムアウトになっているか否かを判断し、タイムアウトになっている場合には、パケットを送信する（ＳＴ５１〜ＳＴ５３）。したがって、タイマ値が０であったり、すでにタイムアウトしている場合には、要求とともに即時にパケットを送信することになり、また、タイマ作動中の場合には、タイムアウトを待ってパケットを送信することになる。そして、送信後は次の送信の要求に備えて送信待ちタイマをスタートさせる（ＳＴ５４）。
【００５２】
【発明の効果】
以上のように、本発明に係るノードでは、輻輳制御パケットの受信回数や、受信間隔の状態に基づいて、ノード側で送信待ち時間を設定・制御するようにしたので、待ち時間も固定ではなく、その時のネットワークの状況に応じた値にセットされる。つまり、混んでいる場合には、比較的長く送信待ち時間を設定し、それに基づいて動作することにより、輻輳制御パケットが発生されるのを抑制することができる。
【００５３】
また、輻輳制御パケットの発生状況に応じて送信待ち時間を設定することにより、例えば輻輳制御解除後も、徐々に送信待ち時間を短くしていくような制御をすることにより、輻輳制御解除後にいっせいに各ノードがパケットを送信することによる衝突の再発生にともなう輻輳制御の頻繁な発生を未然に防止することができる。よって、特定のノードに送信権が与えられ続けることも無く、全ノードに送信権が渡るようにネットワークトラフィックを適正化することができる。
【図面の簡単な説明】
【図１】フロー制御を行うネットワーク構成の一例を示す図である。
【図２】フロー制御を行うネットワークに接続されるスイッチングバスの内部構造の一例を示す図である。
【図３】そのスイッチングバスの機能の一部を示すフローチャートである。
【図４】本発明に係るノードの第１の実施の形態を示す図である。
【図５】そのノードの機能を説明する図である。
【図６】そのノードの機能を説明する図である。
【図７】そのノードの機能を説明するフローチャートである。
【図８】そのノードの機能を説明するフローチャートである。
【図９】そのノードの機能を説明するフローチャートである。
【図１０】作用を説明する図（その１）である。
【図１１】作用を説明する図（その２）である。
【図１２】本発明に係るノードの第１の実施の形態を示す図である。
【図１３】そのノードの機能を説明するフローチャートである。
【図１４】そのノードの機能を説明するフローチャートである。
【図１５】そのノードの機能を説明するフローチャートである。
【図１６】そのノードの機能を説明するフローチャートである。
【符号の説明】
１スイッチングハブ
２ノード
３伝送路
５イーサネットコントローラ
６データ受信部
７輻輳制御パケット判別部
８上位ＩＦ部
９送信データキュー
１０データ通信部
１０ａ送信待ちタイマ
１１輻輳制御パケット処理部
１２送信カウンタ
１３送信待ち時間設定部
１４パケット間隔測定部
１５送信待ち時間設定部[0001]
[Industrial application fields]
The present invention relates to a node, and more specifically, to improvement of transmission time interval control in a CSMA / CD LAN in which a plurality of nodes are connected to a switching hub in a star shape and frames are transmitted and received between the nodes. .
[0002]
[Prior art]
FIG. 1 shows an example of a network configuration of a star LAN (Ethernet or the like) using a general switching hub 1. As shown in the figure, the plurality of nodes 2 are connected to the switching hub 1 in a star shape. Each node 2 transmits / receives a transmission packet to / from the switching hub 1. When the received transmission packet is addressed to another node, the switching hub 1 receives the destination node 2. The transmission packet is transferred between the nodes 2 by transferring the transmission packet.
[0003]
In a collision detection type protocol such as the CSMA / CD system, when the number of transmission packets transmitted through the network increases, a collision occurs and the bandwidth of the network decreases. Therefore, in order to avoid this, the amount of transmitted packets is usually limited. As an example, when a collision occurs, the switching hub 1 transmits a congestion control packet to each node 2, and each node 2 that receives the packet stops the transmission of the packet for a certain period of time. There is something to do.
[0004]
[Problems to be solved by the invention]
However, the conventional apparatus described above has the following problems. That is, when congestion control is released, there is a possibility that the nodes start transmission at the same time, and then packet collision occurs again. Therefore, there is a problem that congestion control frequently occurs.
[0005]
In addition, when there is a node that frequently transmits a packet, there is a possibility that the transmission right is passed only to that node, and other nodes cannot transmit the packet.
[0006]
The present invention has been made in view of the above-described background, and the object of the present invention is to solve the above-described problems and to reoccurrence of a collision caused by each node transmitting a packet at the same time after canceling congestion control. Providing a node that can prevent frequent occurrence of congestion control and can optimize network traffic so that transmission rights are passed to all nodes without being given transmission rights to specific nodes. There is.
[0007]
[Means for Solving the Problems]
In order to achieve the above object, a node according to the present invention is a network node that performs flow control, and includes detection means for detecting reception of a congestion control packet (in the embodiment, a “congestion control packet determination unit”). And an adjusting means (in the embodiment, corresponding to the “congestion control packet processing unit 11”) for adjusting the transmission waiting time based on the number of times of reception of the congestion control packet detected by the detecting means. (Claim 1). This is realized in the first embodiment.
[0008]
As another solution means, a detecting means for detecting the reception of the congestion control packet and a means for obtaining the reception interval of the congestion control packet detected by the detecting means (in the embodiment, the “packet interval measuring section 14” And an adjusting means (in the embodiment, corresponding to “transmission waiting time setting unit 15”, etc.) for adjusting the transmission waiting time based on the obtained reception interval. (Claim 2). This is realized in the second embodiment.
[0009]
That is, in a network that performs flow control, when congestion occurs, a congestion control packet is transmitted to each node from a switching bus (also referred to as “line concentrator”) to which each node is connected. Therefore, when this congestion control packet is not received, each node can freely transmit the packet at its own timing, and when the congestion control packet is received, it must be after the transmission waiting time has elapsed. Packet transmission becomes impossible. In the present invention, the transmission waiting time is variable / adjusted on the node side.
[0010]
That is, congestion control packets are frequently generated as the transmission of packets in the network is congested. Therefore, in claim 1, the transmission waiting time is adjusted based on the number of times of receiving the congestion control packet. That is, the waiting time is adjusted according to the degree of congestion by increasing the transmission waiting time as the number of receptions increases.
[0011]
The number of receptions here may be simply the number of receptions as an absolute value or a relative value within a certain time. Further, for example, as shown in the embodiment, it is better to add a function of reducing the transmission waiting time once increased when a certain condition is met. That is, when the congestion control packet is not received, it is better that the transmission waiting time is short in consideration of network efficiency. At this time, it is preferable to gradually shorten the transmission waiting time instead of immediately returning the transmission waiting time. That is, if it is immediately set to 0 and immediately transmitted, there is a high possibility that congestion will occur again. In view of this, the number of occurrences should be taken into consideration and gradually shortened.
[0012]
Furthermore, the present invention need not specifically remember the number of receptions. In other words, it is not always necessary to associate the number of times with the transmission time so that the transmission waiting time is increased every time reception is performed as in the embodiment. Of course, the number of receptions up to now may be stored, and the transmission waiting time may be set according to the number of receptions. In this case, the number of receptions is not an integrated value but is subtracted under a certain condition (for example, a predetermined number of transmissions succeed without receiving a congestion control packet as in the embodiment). Etc.)
[0013]
When the reception interval is long, it can be determined that the network is relatively free. Accordingly, in claim 2, for example, when the reception interval is long, the transmission waiting time interval is shortened, and when the reception interval is short, the transmission waiting time interval is lengthened.
[0014]
The node according to the present invention is, for example, various devices connected to a network, that is, a device having a network communication function, and as an example, connects various control devices and sensors in FA and the like, and performs cooperative control, synchronous control, etc. Some are connected to a network (LAN) or the like. Specific examples of the node include a general PLC, a sensor terminal, an I / O terminal, and the like. Furthermore, various terminals such as personal computers and relay devices are also included. Of course, it is not limited to the FA, and it goes without saying that those connected to various networks are included.
[0015]
Embodiment
Hereinafter, a preferred embodiment of the present invention will be described. First, the overall configuration of the embodiment of the communication system is the same as the conventional one shown in FIG. That is, a plurality of nodes 2 are connected to the switching hub 1 in a star shape via the transmission path 3, and each node 2 passes through the switching hub 1 when transmitting a packet to the desired node 2. To do. In the present invention, the internal structure of the node 2 is improved.
[0016]
First, the switching hub 1 is configured as shown in FIG. As shown in the figure, packets are transmitted and received through the physical layer IF 1 a connected to the transmission path 3. Each node 2 is connected to the end of the transmission path 3 to which the physical layer IF 1a is connected. A switching Ethernet controller (relay unit) 1b is connected to the upper layer of the physical layer IF 1a, and a packet received via the physical layer IF 1a is passed to the switching Ethernet controller 1b and connected to a desired node. It is transferred to IF1a.
[0017]
Also, the packet received by the switching Ethernet controller 1b is not actually transferred directly, but is temporarily stored in either the low priority buffer 1c or the high priority buffer 1d according to the priority information stored in the packet. Stored. The packets stored in the buffers 1c and 1d are called in a predetermined order, and the switching Ethernet controller 1b sends the packets to the physical layer IF 1a corresponding to the destination node of the packets. At this time, the packet stored in the high priority buffer 1d is preferentially processed.
[0018]
Furthermore, it has a flow control function unit 1e. The flow control function unit 1e monitors the low-priority buffer 1c and the high-priority buffer 1d, and when the buffer is full, sends it to the switching Ethernet controller 1b. Then, the switching Ethernet controller 1b transmits a congestion control packet to all the physical layer IFs 1a and requests each node to temporarily stop transmission.
[0019]
The function of the switching hub 1 is shown in a flowchart as shown in FIG. That is, if a packet is received (ST1), the received packet is stored in the buffers 1c and 1d. Next, the flow control function unit 1e is activated to determine whether the buffer is full (ST3). If the buffer is full, a congestion control packet is transmitted to perform flow control (ST4). Thereafter, the process returns to step 1 to prepare for the next reception. Note that the illustrated flowchart shows only the portion related to the present invention. In actuality, when the buffer is not full, the process of transmitting the packet stored in one of the buffers is executed. Of course. In the illustrated example, the low priority buffer 1c and the high priority buffer 1d are provided and the transmission order can be controlled according to the priority information. However, the present invention is not limited to this, and priority is given. It can also be applied to a node connected to a network that does not support degree information.
[0020]
Further, the first embodiment of the node 2 according to the present invention is configured as shown in FIG. That is, the data receiving unit 6 receives a packet addressed to itself that has been transmitted on the transmission path 3 via the Ethernet controller 5. The received packet is sent to the congestion control packet determination unit 7 serving as detection means, where it is determined whether the packet is a congestion control packet or a normal data packet. In the case of a data packet, the received packet is sent to the upper IF unit 8, where appropriate processing or the like is performed according to the received data content.
[0021]
On the other hand, when transmitting a packet, the packet to be transmitted is given to the transmission data queue 9 from the upper IF unit 8. Then, the data transmission unit 10 transmits packets via the Ethernet controller 5 in order from the top of the transmission data queue 9 according to the transmission request. Since such a basic configuration is the same as that of the prior art, its detailed description is omitted.
[0022]
Here, in the present invention, the congestion control packet processing unit 11 is provided, and when the congestion control packet is received, the transmission waiting time (packet transmission time interval) accompanying the congestion is determined on the node 2 side, and the data transmitting unit 10 performs the congestion control. According to the transmission waiting time determined by the packet processing unit 11, an interval of a fixed time (measured by the built-in transmission waiting timer 10a) is provided and transmission is performed.
[0023]
Then, the congestion control packet processing unit 11 counts the transmission counter 12 that counts the number of times of continuous transmission without receiving the congestion control packet, the counting result of the transmission counter 12, and the number of times of reception of the congestion control packet. A transmission waiting time setting unit 13 for determining a transmission waiting time. That is, the detection signal of the congestion control packet given from the congestion control packet determination unit 7 to the congestion control packet processing unit 11 is given to the transmission waiting time setting unit 13 and the transmission counter 12, and the data transmission unit 10 sends the transmission counter 12. Is provided with transmission information (notification of transmission). The transmission counter 12 increments the counter by 1 each time transmission information is received, and resets the counter value to 0 when a detection signal is received from the congestion control packet determination unit 7.
[0024]
The basic processing algorithm of the transmission waiting time setting unit 13 is to increase the transmission waiting time each time a congestion control packet is received, and transmission is continued a certain number of times while the congestion control packet is not received. If it is possible (when the counter value of the transmission counter 12 reaches the reference value), the transmission waiting time is decreased. In this embodiment, the reference time a is set, and the increase / decrease is performed in units of the reference time.
[0025]
As a specific example, for example, as shown in FIG. 5 (a), normally, when a request is received, transmission is performed immediately. When the flow control (congestion control packet) is received, the timer is driven from the time when the flow control (congestion control packet) is received, and only the transmission waiting time a is counted. And if a request is received during the transmission waiting time, it will transmit after the transmission waiting time passes. Also, as shown in FIG. 4B, when flow control is received during transmission, a timer is started after transmission is completed, and transmission waiting time a is measured.
[0026]
Further, as shown in FIG. 5C, when the congestion has already occurred and transmission is performed with the transmission waiting time of the reference time a, and the flow control is further performed, the transmission waiting time is set to the reference time a. Only increase. That is, the next transmission waiting time is 2a. Furthermore, as shown in FIG. 4D, when flow control has already been received during transmission waiting time measurement after the end of transmission, the transmission waiting time is not increased by a during the measurement, and is initially set. The transmission is performed after elapse of the waiting time (a in this case), and is reflected at the time of the transmission waiting time next to the transmission (in the illustrated case, 2a).
[0027]
By performing such processing, if the flow control is continued, each node side responds so as to gradually increase the transmission waiting time, thereby suppressing the occurrence of congestion. In addition, increasing the transmission waiting time until it is not subject to flow control means that the packet is transmitted at the shortest (or close) transmission time interval that is optimal for the network traffic at that time, that is, without causing congestion. Will be. Further, the transmission right is distributed to each node.
[0028]
On the other hand, if the transmission wait time is transmitted in this way, the subsequent network status changes, the number of packets transmitted over the network decreases, and there is too much room for the set transmission wait time. , Network efficiency decreases. Therefore, a function is also provided to control so as to reduce the transmission waiting time if the flow control is not received. That is, as shown in FIG. 6A, the transmission waiting time is reduced by the reference time a when the transmission can be continued without being subjected to flow control for a predetermined number of times (three times in this example) (shown in the figure). In this example, the length is shortened from 2a to a). Of course, if flow control is issued as a result of shortening, the transmission waiting time may be increased again. In this way, optimal network traffic can always be realized.
[0029]
Furthermore, as shown in FIG. 5B, when there is no request during the transmission waiting time (after the second transmission), if there is a request after that time elapses, transmission starts immediately. To do. In that case, the transmission waiting time after the transmission is the same (2a) as the previous time. However, when the transmission is already performed three times without being subjected to flow control, of course, the time is reduced by the reference time a (in the illustrated case, the transmission waiting time after the fourth transmission is a To decrease).
[0030]
A processing flow for performing such processing is as shown in FIG. That is, the processes accompanying the packet reception are as shown in FIGS. First, as processing associated with packet reception, the transmission waiting timer value and the transmission counter value of the transmission waiting timer 10a are set to 0 as an initial setting (ST10, 11).
[0031]
Here, the transmission waiting timer value is the operating time of the transmission waiting timer 10a. The transmission waiting timer 10a operates according to the timer value determined here, and transmits a packet when timed out. Therefore, when timer = 0, a packet is transmitted simultaneously with a request. The transmission counter value is the number of times packets can be transmitted continuously without receiving flow control.
[0032]
If a packet is received (ST12), it is determined whether or not it is a congestion control packet (flow control) (ST13). This determination is performed by the congestion control packet determination unit 7. If it is not a congestion control packet, the process returns to step 12 to prepare for reception of the next packet.
[0033]
On the other hand, in the case of a congestion control packet, the process proceeds to step 14 where the transmission waiting timer value is increased by one unit time (a). That is, since the initial value is 0, the timer value is a. Therefore, if the congestion control packet is received when the transmission waiting timer value is a, the timer value becomes 2a. The timer value determined here is finally set in the transmission waiting timer 10a. Thereafter, the transmission completion counter is cleared to 0 (ST15).
[0034]
Next, it is determined whether or not transmission is currently being performed (ST16). If transmission is in progress, a transmission timer is started after the end of the transmission (ST17). That is, a timer start command is issued to the data transmission function unit 10 (transmission waiting timer 10a). Upon receiving this command, the transmission waiting timer 10a times out the timer value set in step 14 and times out. Such processing corresponds to FIGS. 5B and 5C.
[0035]
On the other hand, if not transmitting, it is determined whether the transmission waiting timer 10a is operating (ST18). When the transmission timer is not operating, the transmission waiting timer is immediately started (ST19). Such processing corresponds to the state shown in FIG.
[0036]
Furthermore, when the transmission waiting timer 10a is in operation, the transmission waiting timer 10a is started after the end of the next transmission (ST20). That is, it corresponds to the state shown in FIG. The functions of the congestion control packet processing unit 11 are shown except for steps 12 and 13 in the flowcharts shown in FIGS.
[0037]
In addition, as shown in FIG. 9, the process associated with the transmission of the node determines whether or not there is a packet waiting for transmission (it can be seen from the queue and the request is issued). It is determined whether or not a timeout has occurred, and if the timeout has occurred, a packet is transmitted (ST21 to ST23). Therefore, if the timer value is 0 or it has already timed out, the packet is sent immediately with the request, and if the timer is operating, the packet is sent after waiting for the timer to expire. It will be.
[0038]
Then, when packet transmission is completed, the counter value of the transmission completion counter is incremented by 1 (ST24), and whether or not the counter value of the transmission completion counter has reached a predetermined number of times (in this embodiment, “3 times”). (ST25), if YES, the process proceeds to step 26, where the transmission completion counter is cleared to 0 and the transmission waiting timer value is decreased by one unit time (a) (ST26, ST27). This corresponds to a state in which the transmission waiting time is reduced from “2a” to “a” in FIG. Thereafter, the transmission waiting timer is restarted (ST28). Such processing corresponds to various examples in which a transmission waiting timer is started immediately after transmission is completed.
[0039]
FIG. 10 shows the transmission time interval increase mechanism of the present embodiment along a series of flows. That is, when there is a request at the beginning, it is transmitted immediately (until the second time), and when the flow control is received after the second transmission, only the transmission time interval (a) is measured from there. Then, since there is a request before the timeout, it waits for the timeout and transmits (third).
[0040]
Then, after the third transmission, the timer is automatically measured for the transmission time interval (a). When there is a request after the timeout, the transmission is performed immediately (fourth). When the flow control is received during the fourth transmission, the transmission time interval is added by a, and the total becomes 2a. Therefore, after the transmission is completed, the timer is measured only for 2a. Th).
[0041]
Since flow control was not applied at the time of the fifth transmission, the next transmission waiting time remains 2a. Even if there is flow control during the transmission waiting time, it is reflected next time, so the sixth transmission is also performed after waiting for 2a after the end of the fifth transmission, and after the sixth transmission. The transmission waiting time becomes 3a.
[0042]
On the other hand, a mechanism for decreasing the transmission time interval is shown along a series of flows as shown in FIG. First, as shown in FIG. 5A, if the current transmission time interval is 3a and flow control is not applied during three consecutive transmissions, the transmission time interval starts from the next time. Is reduced by a to 2a. If transmission can be performed three times consecutively without receiving flow control, the next transmission time interval is a.
[0043]
Also, as shown in FIG. 5B, after waiting for the transmission time interval 3a and performing transmission, the next transmission time interval 3a is waited as it is. At this time, if the request times out without taking a request, the next request is transmitted immediately. This is the same as in the fourth transmission in FIG. In addition, even when immediate transmission is performed after timeout in this way, the transmission completion counter is not cleared, so at the time of the fourth transmission in FIG. Therefore, the transmission time interval is reduced to 2a.
[0044]
As described above, in this embodiment, the decrease in the transmission waiting time is also adjusted by the frequency of packet transmission from the node. That is, a node that transmits packets relatively frequently has a shorter transmission waiting time than a node that does not frequently transmit packets. In this way, since the decrease timing of the transmission waiting time after the congestion control packet is not sent is shifted at each node, the possibility of packet re-collision after release is more reliably suppressed as much as possible. By setting the transmission waiting time according to the node dispatch timing, more efficient transmission can be performed.
[0045]
FIG. 12 shows a second embodiment of the node according to the present invention. As shown in the figure, the internal structure of the congestion control packet processing unit 11 ′ is different. That is, it has a packet interval measuring unit 14 and a transmission waiting time setting unit 15. The packet interval measurement unit 14 includes a timer that is turned on / off by a congestion packet detection signal received from the congestion control packet determination unit 7, and measures the interval at which the congestion packet is received.
[0046]
The transmission wait time setting unit 15 sets the transmission wait time based on the congestion packet reception interval measured by the packet interval measurement unit 14. In other words, when the congestion packet reception interval is long, the network is not crowded, so the congestion waiting time is shortened to control packet transmission quickly, and when the congestion packet reception interval is short, the network Since it is crowded, the congestion waiting time is lengthened to control the occurrence of congestion. Specifically, the flowcharts shown in FIGS. 13 to 15 are used.
[0047]
That is, first, as an initial setting, the transmission waiting timer value is set to 0, and the congestion packet reception interval, that is, the reception timer in the packet interval measurement unit 14 is set to 0 (ST31, 32). Thereafter, the reception timer is started (ST33).
[0048]
Next, it waits for reception of a packet (ST34). If a packet is received, it is determined whether it is a congestion control packet (ST35). In the case of a congestion control packet, the reception timer is stopped (ST36), a reception time interval from the previous reception of the congestion control packet to the reception of this time is obtained, and is the reception time interval smaller than the reference time t? It is determined whether or not (ST37). In practice, the reception time interval can be obtained by reading the timer value of the reception timer.
[0049]
When the reception time interval is shorter than the reference value t, the transmission waiting timer value is increased by one unit time (ST38). Conversely, when the reception time interval is longer than the reference value t, the transmission waiting timer value is increased. Control is performed so as to decrease by one unit time (ST39). Thereafter, in order to monitor the next congestion packet reception time interval, the congestion control packet reception time interval is set to 0 (ST40), and then the reception timer is started (ST41).
[0050]
Next, it is determined whether transmission is currently being performed (ST42). If transmission is in progress, a transmission timer is started after the end of the transmission (ST43). That is, a timer start command is issued to the data transmission function unit 10 (transmission waiting timer 10a). Upon receiving this command, the transmission waiting timer 10a times out by the timer value set in step 38 or ST39 and times out. On the other hand, when not transmitting, it is determined whether the transmission waiting timer 10a is operating (ST44). When the transmission timer is not operating, the transmission waiting timer is immediately started (ST45). When the transmission timer is operating, the transmission waiting timer is started after the next transmission is completed. Thereafter, the process returns to step 34, and the above-described processes (monitoring of the reception time interval of the congestion packet and setting of a transmission waiting timer value based on the reception interval) are repeated.
[0051]
On the other hand, as shown in FIG. 16, the transmission process determines whether or not there is a packet waiting to be transmitted (as can be seen from the fact that it exists in the queue and the request is issued). It is determined whether or not the packet has timed out, and a packet is transmitted (ST51 to ST53). Therefore, if the timer value is 0 or it has already timed out, the packet will be sent immediately with the request, and if the timer is active, the packet will be sent after the timeout. become. After transmission, a transmission waiting timer is started in preparation for the next transmission request (ST54).
[0052]
【The invention's effect】
As described above, in the node according to the present invention, the transmission waiting time is set and controlled on the node side based on the number of times of reception of the congestion control packet and the state of the reception interval, so the waiting time is not fixed. The value is set according to the network status at that time. In other words, when it is crowded, it is possible to suppress the occurrence of the congestion control packet by setting the transmission waiting time relatively long and operating based on it.
[0053]
In addition, by setting the transmission waiting time according to the congestion control packet generation status, for example, after the congestion control is canceled, the transmission waiting time is gradually shortened so that after the congestion control is canceled, It is possible to prevent frequent occurrence of congestion control due to reoccurrence of collision caused by each node transmitting a packet. Therefore, the network traffic can be optimized so that the transmission right is passed to all nodes without continuing to be given the transmission right to a specific node.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating an example of a network configuration for performing flow control.
FIG. 2 is a diagram showing an example of an internal structure of a switching bus connected to a network that performs flow control.
FIG. 3 is a flowchart showing a part of the function of the switching bus.
FIG. 4 is a diagram showing a first exemplary embodiment of a node according to the present invention.
FIG. 5 is a diagram illustrating the function of the node.
FIG. 6 is a diagram illustrating the function of the node.
FIG. 7 is a flowchart illustrating the function of the node.
FIG. 8 is a flowchart for explaining the function of the node;
FIG. 9 is a flowchart for explaining the function of the node;
FIG. 10 is a diagram (part 1) for explaining the operation;
FIG. 11 is a diagram (part 2) for explaining the operation;
FIG. 12 is a diagram showing a first exemplary embodiment of a node according to the present invention.
FIG. 13 is a flowchart illustrating the function of the node.
FIG. 14 is a flowchart for explaining the function of the node;
FIG. 15 is a flowchart for explaining the function of the node;
FIG. 16 is a flowchart for explaining the function of the node;
[Explanation of symbols]
1 Switching hub
2 nodes
3 Transmission path
5 Ethernet controller
6 Data receiver
7 Congestion control packet discriminator
8 Upper IF section
9 Transmission data queue
10 Data communication department
10a Transmission wait timer
11 Congestion control packet processor
12 Transmission counter
13 Transmission waiting time setting part
14 Packet interval measurement unit
15 Transmission waiting time setting section

Claims

A network node that performs flow control,
Detecting means for detecting reception of a congestion control packet;
A node comprising adjusting means for adjusting the transmission waiting time based on the number of times of reception of the congestion control packet detected by the detecting means;

A network node that performs flow control,
Detecting means for detecting reception of a congestion control packet;
Means for obtaining a reception interval of the congestion control packet detected by the detecting means;
A node comprising adjusting means for adjusting a transmission waiting time based on the obtained reception interval;