(57)【要約】【課題】データ転送装置及びヘルスチェックデータ処理方法に関し、データ転送のトラフィック量により影響されるヘルスチェック応答遅延を少なくし、ヘルスチェックの監視タイマのタイムアウト最適値を容易に決定可能にする。【解決手段】ヘルスチェックデータを送信する側で、ヘルスチェックデータに付与するエラーチェック符号として、ユーザ通信データ用のＣＲＣ符号と異なるヘルスチェックデータ固有のＣＲＣ符号を付与し、受信側では、受信データに対して、ユーザ通信データ用のＣＲＣ符号でエラーチェック（７−５）し、エラーが検出された場合に、ヘルスチェックデータ固有のＣＲＣ符号で二重ＣＲＣチェック（１−１）を行い、チェック結果が正常であれば、受信データがヘルスチェックデータであると判定してヘルスチェックを検出（１−２）し、ヘルスチェック応答を処理待ちキューの先頭又は優先的な順序位置に配置（１−４）して格納する。【選択図】図１
2008199432.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ通信データにエラーチェック符号を付与して転送するデータ転送装置において、
ヘルスチェックデータを送信する側のデータ転送装置には、ヘルスチェックデータに付与するエラーチェック符号として、受信側のデータ転送装置における前記ユーザ通信データ用のエラーチェック符号によるエラーチェックでエラーが検出されるエラーチェック符号であって、ヘルスチェックデータ固有の識別符号を、ヘルスチェックデータに付与して送信する手段を備え、
ヘルスチェックデータを受信する側のデータ転送装置には、受信パケットに対して、前記ユーザ通信データ用のエラーチェック符号によるエラーチェックを行った後に、該エラーチェックでエラーが検出された受信データに対して、ヘルスチェックデータ固有の識別符号が付与された受信データであるか否かを判定する手段と、該ヘルスチェックデータ固有の識別符号が付与された受信データを、受信データ処理待ちキューの先頭又は他の受信データより優先的な順序位置に配置して格納する手段と、を備えたことを特徴とするデータ転送装置。
【請求項２】
前記ヘルスチェックデータ固有の識別符号として、前記ユーザ通信データ用のエラーチェック符号と異なるＣＲＣ符号を用いたことを特徴とする請求項１に記載のデータ転送装置。
【請求項３】
前記ヘルスチェックデータ固有の識別符号として、前記ユーザ通信データ用のエラーチェック符号によるエラーチェックの対象範囲と異なるデータ範囲をエラーチェックの対象範囲とするＣＲＣ符号を用いたことを特徴とする請求項１に記載のデータ転送装置。
【請求項４】
前記ヘルスチェックデータ固有の識別符号として、ヘルスチェックデータの所定位置の固定データを用い、受信データの所定位置のデータを該固定データと比較してヘルスチェックデータを識別することを特徴とする請求項１に記載のデータ転送装置。
【請求項５】
ユーザ通信データにエラーチェック符号を付与して転送し、定期的にヘルスチェックデータを送受するデータ転送装置間のヘルスチェックデータ処理方法において、
前記ヘルスチェックデータを送信する側のデータ転送装置では、ヘルスチェックデータに付与するエラーチェック符号として、受信側のデータ転送装置における前記ユーザ通信データ用のエラーチェック符号によるエラーチェックでエラーが検出されるエラーチェック符号であって、ヘルスチェックデータ固有の識別符号を、ヘルスチェックデータに付与して送信し、
前記ヘルスチェックデータを受信する側のデータ転送装置では、受信データに対して、前記ユーザ通信データ用のエラーチェック符号によるエラーチェックを行った後に、該エラーチェックでエラーが検出された受信データに対して、ヘルスチェックデータ固有の識別符号が付与された受信データであるか否かを判定し、該ヘルスチェックデータ固有の識別符号が付与された受信データを、受信データ処理待ちキューの先頭又は他の受信データより優先的な順序位置に配置して格納することを特徴とするヘルスチェックデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ転送装置及びヘルスチェックデータ処理方法に関し、特に、データ転送装置間で送受される障害検出用のヘルスチェックデータを、遅滞なく処理するデータ転送装置及びヘルスチェックデータ処理方法に関する。
【背景技術】
【０００２】
へルスチェックは、複数の装置間で互いに相手装置が正常に動作していることを確認するために、定期的に相手装置に対してヘルスチェックデータを送り、該相手装置から受信される該ヘルスチェックデータに対する応答データ及び応答時間を基に相手装置の正常性を判断する技術として用いられる。
【０００３】
図６に従来のへルスチェックの動作シーケンスを示す。同図に示すように、相手装置Ｂから自装置Ａ宛てにヘルスチェックデータ６−１が送信されると、自装置Ａでは該ヘルスチェックデータ６−１を受信データキュー６−２の最後尾に格納し、既に受信され受信データキュー６−１に格納済みの受信データを、該受信データキュー６−１からＦＩＦＯ（First-In First-Out）方式で先頭のものから順に取り出し、順番に処理する。そのため、受信データキュー６−２での待ち時間による処理遅延が発生する。
【０００４】
上記の受信データの処理のフローを図７に示す。同図に示すように、受信回路で受信データパケットの同期確立（７−１）の後、該受信データが自装置宛てか否かを判定し（７−２）、自装置宛ての場合、ＤＭＡ等による転送処理を経由して該受信データをメモリ装置に転送する（７−４）。自装置宛てでない場合、該受信データは破棄する（７−３）。
【０００５】
メモリ装置へ転送された自装置宛ての受信データに対して、ＣＲＣ（Cyclic Redundancy Check）符号のエラーチェック、フレーミングエラーチェック等のエラーチェック処理を行い、該受信データが正常か異常かの判定を行う（７−５）。ＣＲＣ符号等のエラーが検出された受信データは破棄する（７−６）。なお、エラーチェックの結果は、通常、受信回路からＣＰＵへの割り込み要求（ＩＲＱ）により通知される。
【０００６】
エラーチェックの結果が“正常（ＯＫ）”でかつ当該受信データの受信前に既受信データが存在する場合、当該受信データは、ＦＩＦＯ方式の受信データキューを経由するパケット処理部に引き渡され処理される（７−７）。
【０００７】
パケット処理部では、受信データキューに格納されている既受信データパケットの有無を判定し（７−８）、受信データパケットが有る場合、当該受信データパケットをＦＩＦＯ方式の受信データキューへ格納する。従って、当該受信データは受信データキュー内部に留保され、既受信データの処理完了待ちとなる（７−９）。
【０００８】
受信データキューに格納されている既受信データが無くなったとき、当該受信データパケットの処理が開始される（７−１０）。この場合、既受信データパケット数が多いほど、当該受信データパケットが処理されるまでの待ち時間が長大化し、ヘルスチェックデータのように、パケット受信からデータ処理を完了して相手装置へ応答データを返送し、該応答データが相手装置に到着するまでの時間が規定されている場合、受信データキューでの待ち時間による遅延が問題となる。
【０００９】
上記受信データキューでの待ち時間による遅延について待ち行列モデルを用いて説明する。待ち行列モデルは、以下の各パラメータを用いて次の計算式で評価することが可能である。但し、簡単化のため、伝送路上でのデータ転送時間は処理時間に比べて微小であるため無視し、トラフィックは一方向のみとする。
【００１０】
まず、ヘルスチェックデータ（メッセージ）が他の受信データと共に処理されるまでの平均待ち時間を計算する。ここで、Ｔｗは平均待ち時間（ヘルスチェックデータが処理されるまでの待ち時間の期待値）、Ｔｓは平均サービス時間（処理システム上で受信データ（メッセージ）を処理する時間の平均値、ρは平均利用率（受信データの処理混雑具合を表す係数）、λは平均到着率（単位時間に到着する受信データ（メッセージ）数）、μは平均サービス率（単位時間で処理可能な受信データ（メッセージ）数の平均値）であるとすると、
Ｔｗ＝（ρ／１−ρ）＊Ｔｓ、ρ＝λ／μ  ・・・・（１）
となり、グラフで示すと図８のようになる。
【００１１】
具体例として、通常時の受信データの到着間隔Ｔａが５００ｍｓで、平均サービス時間Ｔｓが２００ｍｓの処理システムにおける、ヘルスチェック監視タイマのタイムアウト値として最適な値の目安を考える。このとき、Ｔｓ（平均サービス時間）＝０．２であり、受信データ（メッセージ）の増加により、Ｔａ（データの到着間隔）が０．５から０．３へ変化した場合のＴｗ（平均待ち時間）の変化は次のようになる。
【００１２】
通常時は、Ｔａ（データの平均到着時間）は０．５、Ｔｓ（平均サービス時間）は０．２である。この場合、λ（平均到着率）＝１／Ｔａ＝２、μ（平均サービス率）＝１／Ｔｓ＝５であるため、ρ（平均利用率）＝λ（平均到着率）／μ（平均サービス率）＝０．４となり、Ｔｗ（平均待ち時間）＝（０．４／０．６）＊０．２＝０．１３となる。
【００１３】
データ転送量などのトラフィックの増大などにより、Ｔａ（データの平均到着間隔）が０．３となった場合、λ（平均到着率）＝１／Ｔａ＝３．３、μ（平均サービス率）＝５であることから、ρ（平均利用率）＝λ（平均到着率）／μ（平均サービス率）＝３．３／５＝０．６６となり、Ｔｗ（平均待ち時間）＝（０．６６／０．３４）＊０．２＝０．３８８となる。
【００１４】
上記の求めた値から、通常時では、ヘルスチェック監視タイマのタイムアウト値として０．１３以上とする必要があり、トラフィックの増大を考慮すると、該タイムアウト値は０．３８８以上としなければならない。更に、処理時間Ｔｓや平均待ち時間Ｔｗのマージンを考慮する一方、ヘルスチェックの早期確認の必要性から、ヘルスチェック監視タイマのタイムアウト値を、如何に最適に設定するかが課題となる。
【００１５】
本発明に関連する先行技術文献として、下記の特許文献１には、ヘルスチェック信号を受信すると、送信中のデータが有っても、ヘルスチェック応答要求に応じて該送信を中断し、ヘルスチェック応答を優先して送出する技術が公開されている。また、下記の特許文献２には、相手からのアプリケーションデータの受信中は、ヘルスチェック受信監視時間を延長し、これにより、ヘルスチェックデータの監視タイムアウトが発生しないようにした技術が公開されている。
【００１６】
また、下記の特許文献３には、ヘルスチェック信号を所定周期で送出し、受信側より応答が無いときには、受信側にて障害が発生したものと判定し、受信側にて所定期間に亘ってヘルスチェック信号が受信されない場合には、送信側にて障害が発生したものと判定する技術について公開されている。
【特許文献１】特開平０３−０１９０５７号公報
【特許文献２】特開昭６３−１０４５４４号公報
【特許文献３】特開昭６２−１７５８３６
【発明の開示】
【発明が解決しようとする課題】
【００１７】
データ転送装置では、装置間又は装置内部のデータ転送機能の正常性の確認のため、ヘルスチェックと称するデータのやり取りを実行する。この場合、本来の通信サービス用のユーザデータの転送量が増大すると、ヘルスチェックデータが受信から解析処理に引き渡されるまで、受信データキューに留保され、ヘルスチェックに対する応答までに長時間を要することとなり、最悪の場合、ヘルスチェックの応答未返送によるヘルスチェック異常（監視タイマのタイムアウト）と判定されるケースが発生してしまう。
【００１８】
従来のヘルスチェックでは、この監視タイマのタイムアウト値としての最適な値が、データ転送のトラフィック量等の影響によって変動してしまうため、実測値等を基にマージンを含んだ凡その目安の値として設定するよりほかなく、最適な値を決定することができないものであった。本発明は、データ転送のトラフィック量により影響されるヘルスチェック応答処理遅延を少なくし、ヘルスチェックの監視タイマのタイムアウト最適値を容易に決定することができるデータ転送装置及びヘルスチェックデータ処理方法を提供する。
【課題を解決するための手段】
【００１９】
上記課題を解決するために、本発明は、ユーザ通信データにエラーチェック符号を付与して転送するデータ転送装置において、ヘルスチェックデータを送信する側のデータ転送装置には、ヘルスチェックデータに付与するエラーチェック符号として、受信側のデータ転送装置における前記ユーザ通信データ用のエラーチェック符号によるエラーチェックでエラーが検出されるエラーチェック符号であって、ヘルスチェックデータ固有の識別符号を、ヘルスチェックデータに付与して送信する手段を備え、ヘルスチェックデータを受信する側のデータ転送装置には、受信パケットに対して、前記ユーザ通信データ用のエラーチェック符号によるエラーチェックを行った後に、該エラーチェックでエラーが検出された受信データに対して、ヘルスチェックデータ固有の識別符号が付与された受信データであるか否かを判定する手段と、該ヘルスチェックデータ固有の識別符号が付与された受信データを、受信データ処理待ちキューの先頭又は他の受信データより優先的な順序位置に配置して格納する手段と、を備えたことを特徴とする。
【００２０】
また、前記ヘルスチェックデータ固有の識別符号として、前記ユーザ通信データ用のエラーチェック符号と異なるＣＲＣ符号を用いたことを特徴とする。また、前記ヘルスチェックデータ固有の識別符号として、前記ユーザ通信データ用のエラーチェック符号によるエラーチェックの対象範囲と異なるデータ範囲をエラーチェックの対象範囲とするＣＲＣ符号を用いたことを特徴とする。また、前記ヘルスチェックデータ固有の識別符号として、ヘルスチェックデータの所定位置の固定データを用い、受信データの所定位置のデータを該固定データと比較してヘルスチェックデータを識別することを特徴とする。
【発明の効果】
【００２１】
本発明によれば、データ転送装置において、エラーチェック符号を利用してヘルスチェックデータを受信側装置で識別可能にし、受信側装置でヘルスチェックデータを他の受信データキューに格納されている処理待ちの受信データより優先して処理することにより、ヘルスチェック応答を、受信データキューに格納されている処理待ちの受信データ数に影響されることなく、直ちに返送することができ、データ転送のトラフィック量の影響による処理遅延が少なく、ヘルスチェックの監視タイマのタイムアウト最適値を精度良く容易に決定することが可能となる。
【００２２】
また、ＣＲＣ符号等のエラーチェック符号は、イーサネット（登録商標）やＡＴＭ（Asynchronous Transfer Mode）など代表的な通信プロトコルの転送データに付与されるものであり、本発明では該ＣＲＣ符号等のエラーチェック符号の二重チェックを行ってヘルスチェックデータを受信側装置で識別するため、それら汎用の通信プロトコルのデータ転送装置に容易に適用することができる。
【発明を実施するための最良の形態】
【００２３】
一般的なデータ転送装置におけるデータ受信時のフローは図７で説明したように、受信データの同期確立後、自装置宛ての受信データをＤＭＡ等経由でメモリ装置に転送し、受信データが正常か異常かをＣＲＣエラー又はフレーミングエラー等のエラーチェックを行い、該チェック結果は、該当処理部にＣＰＵの割り込みによって通知される。
【００２４】
受信データがヘルスチェックデータであっても、該ヘルスチェックデータの受信以前に受信データが存在する場合は、該ヘルスチェックデータは受信データキューに格納され、既受信データの処理の完了の後に該ヘルスチェックデータが処理されるため、ヘルスチェックの応答が遅れることとなる。
【００２５】
そこで本発明では、受信データキューへの格納前に全ての受信データに対して行われるＣＲＣエラー又はフレーミングエラー等のエラーチェックの処理において、ヘルスチェックデータを他のユーザデータ等の受信データと区別して抽出し、該抽出したヘルスチェックデータを、受信データキューの先頭又は優先的な順序位置に格納するようにしたものである。
【００２６】
上記の機能を実現するために、ヘルスチェックデータに対して、ＣＲＣ符号等のエラーチェック符号として、受信側でエラーが検出される符号であって、且つ、ヘルスチェックデータ固有の識別符号を、ヘルスチェックデータに付与して送信し、受信側では、受信データのエラーチェックにより、異常データと判定された受信データに対して、更に、本来の異常データとヘルスチェックデータとを区別するために、以下の処理を行う。
【００２７】
前述の図７の破線で囲んだステップ７−５、７−６及び７−７から成る処理を、図１の（ａ）及び（ｂ）に示すように、ＣＲＣ符号チェックによる受信データの正常／異常の判定（７−５）の後、異常と判定された受信データに対して、更に、ヘルスチェックデータパケットに対して付与された固有のＣＲＣ符号による二重のＣＲＣ符号チェック（１−１）を行う。
【００２８】
上記二重のＣＲＣ符号チェック（１−１）の結果が“正常”と判定された場合、該受信データがヘルスチェックデータであると認識し、ＣＰＵに対して割り込み要求（ＩＲＱ）を発生する（１−２）。該二重のＣＲＣ符号チェック（１−１）の結果が“異常”と判定された場合、該受信データはヘルスチェックデータではなく、従来どおりの異常受信データとして該受信データを破棄する割り込み要求（ＩＲＱ）を発生する（７−６）。
【００２９】
このように、受信データに対して二重のＣＲＣ符号チェックを行い、ヘルスチェックデータに対しては、最初のＣＲＣ符号チェックで必ず異常と判定されるＣＲＣ符号を付与してトラップ発生要因とし、二回目のＣＲＣ符号チェックでヘルスチェックデータとして認識されるよう、ヘルスチェックデータ固有のＣＲＣ符号を付与することにより、本来の受信データの正常性確認機能を保有したまま、ヘルスチェックデータを認識する機能を追加する。
【００３０】
上記二重のＣＲＣ符号チェック（１−１）で正常と判定され、ヘルスチェックデータが検出されると、ＣＰＵに対する割り込み要求（ＩＲＱ）を発生し（１−２）、該割り込み要求（ＩＲＱ）により、図１の（ｂ）に示すように、ヘルスチェック応答（処理に応じてヘルスチェック結果を確認し応答とする）をキューに格納する準備をし（１−３）、準備した応答を、受信データキューの既受信データ（未送信データ）の先頭に配置する（１−４）。
【００３１】
なお、上記割り込み要求の発生（１−２）によるヘルスチェック処理は、その処理パターンにより、処理に要する時間が異なる。データ転送装置においては、受信処理系の優先度が最も高く、割り込み処理の延長にてヘルスチェック処理を実行しても特に問題は生じないが、他によりハイレベルの割り込み処理が要求される場合には、該割り込み処理の優先度に応じて、ヘルスチェック応答の受信データキューへの配置位置を調整する構成とすることができる。
【００３２】
パケット処理部では、受信データキューに格納されている既受信データの有無を判定し（７−８）、受信データが有る場合、当該受信データをＦＩＦＯ方式で先頭から取り出して処理し、ヘルスチェック応答データは該受信データキュー先頭又は優先的な順序位置に配置されているので、他の既受信データ数により影響される処理待ち時間の遅延を伴うことなく、速やかに送信することが可能となる。
【００３３】
但し、上記の最初のＣＲＣ符号チェック（７−５）で“異常”と判定された場合、エラーチェックデータ統計情報としてのＣＲＣエラーカウンタは増加させず、二回目のＣＲＣ符号チェック（１−１）で“異常”と判定されたときに、エラーチェックデータ統計情報としてのＣＲＣエラーカウンタを増加させる。
【００３４】
二回目のＣＲＣ符号チェック（１−１）でヘルスチェックデータを識別する手法として、以下のような４通りの手法を用いることができる。
（１）最初のＣＲＣ符号チェック（７−５）と同一のＣＲＣ符号チェック方式を用い、チェックするデータの対象範囲を変えてチェックする。
（２）ＣＲＣ符号チェック方式として種類の異なる二つの方式（例えばＣＲＣ−３２，ＣＲＣ−１６等）を用意し、ヘルスチェックデータとユーザデータとで異なるＣＲＣ符号方式を適用する。
（３）ユーザデータと異なるＣＲＣ符号をヘルスチェックデータに付与して送信し、受信側で異常を検出した後、ヘルスチェックデータ用のＣＲＣ符号で再計算して正常性を確認し、ヘルスチェックデータを識別する。
（４）ヘルスチェックデータがパラメータ（変数）を含まない固定データである場合、受信装置側で該固定データ及びその配置位置を記憶しておき、受信データにおける該配置位置のデータを、受信装置で記憶している固定データと比較し、その一致検出によりヘルスチェックデータを識別する。
【００３５】
図１の（ｃ）にエラーチェック符号を付与した転送データのフォーマットを示す。データ転送時は、送信データ（フレーム、パケットなど）の正常性を保証するために、ＣＲＣ符号、チェックサム符号等のエラーチェック符号を送信データに付加して送信し、受信側で該エラーチェック符号を基に受信データをチェックし、異常が検出された場合、該受信データを破棄又は再送要求を行う。
【００３６】
本発明では、例えば、ユーザデータには第２のＣＲＣ方式の符号を付与し、ヘルスチェックデータには第１のＣＲＣ方式の符号を付与して送信し、受信側で受信データを第２のＣＲＣ方式でチェックして異常を検出した後、第１のＣＲＣ方式でチェックし、チェック結果が“正常（ＯＫ）”であれば、ヘルスチェックデータであると識別する。
【００３７】
本発明による受信処理の全体フローを図２に示す。図２において、図７に示した従来の受信処理と同一の処理には同一の符号を付し、また、図１で説明した処理と同一の処理には同一の符号を付し、重複した説明を省略する。本発明による受信処理の全体フローは、図６に示す破線で囲んだ従来の受信処理を、図１に示す処理で置き換えたものである。
【実施例】
【００３８】
本発明の実施例として、図３に示すように、データ転送装置２台の場合の構成例について説明する。同図に示すように、データ送受信装置３−１からヘルスチェックデータパケットをデータ送受信装置３−２に送信し、データ送受信装置３−２から該ヘルスチェックデータパケットに対するヘルスチェック応答をデータ送受信装置３−１に返送する。ここで伝送媒体は一例としてイーサネット（登録商標）であるとする。
【００３９】
上記構成例におけるヘルスチェックの処理の流れを図４を参照して説明する。まず、受信時の処理の流れについて説明する。データ送受信装置３−２において、受信データが一般ユーザデータであってもヘルスチェックデータであっても、受信回路及びＤＭＡ回路を通してデータの正常性チェック（ＣＲＣ符号チェック）を実行し、受信データをメモリ内のバッファに格納する（４−１）。そのとき、受信（送信）バッファ制御機構によって、ディスクリプタによる受信データの先頭、受信ステイタス（正常、異常）、制御フラグが管理される。
【００４０】
該受信データの正常性チェックで異常が検出されたときには、ＣＰＵに対する割り込み（トラップ）を発生させ、該当するベクタテーブルのエントリに登録されたＣＲＣエラートラップ処理部をコールする（４−２）。ＣＲＣエラートラップ処理部では、バッファから受信データを読み出し（４−３）、該受信データに対して二回目のＣＲＣ符号チェックを行う（４−４）。
【００４１】
二回目のＣＲＣ符号チェックの結果で正常な場合、ヘルスチェック良否を判断し、ヘルスチェック応答が、以下に述べる送信処理を経てデータ送受信装置（３−１）に返送される。ＣＲＣ符号チェックの結果が異常のときは該受信データを廃棄する。受信データがヘルスチェックに該当しない場合にのみ、統計上としてのＣＲＣチェック異常発生回数を加算する。ＣＲＣ符号方式としてはイーサネット（登録商標）におけるＣＲＣ−３２の生成多項式を使用することができる。
【００４２】
送信時は、ＣＲＣ符号方式の多項式を変更する必要はなく、ＣＲＣ−３２を使用する。但し、演算対象は異なる。送信時は送信用のディスクリプタ内のフラグにより、送信データキューの先頭にヘルスチェック応答を配置する（４−５）。フラグは２種使用し、第１のフラグはＤＭＡ転送処理中フラグ、第２のフラグを最終フラグとして使用する。
【００４３】
最も先頭に近い第１のフラグがオフのディスクリプタに対して、第２のフラグをオフとして、その次のディスクリプタエントリーにヘルスチェック応答パケットをチェインし、その後、第２のフラグをオフにしたフラグをオンにして、送信ＤＭＡを再起動する（４−６）。
【００４４】
この処理により、図５（ａ）に示すように、２つの未送信パケットがそのディスクリプタ５−１及び５−２によってこの順番で先頭からチェインされている場合、同図（ｂ）に示すように、ヘルスチェック応答のディスクリプタ５−３が、先頭の未送信パケットのディスクリプタ５−１の次に配され、次の未送信パケットのディスクリプタ５−２の前に割り込んでチェインされ、ヘルスチェック応答が受信（送信）データキューの先頭又は優先的な順序位置に配置される。ヘルスチェック応答パケットの送信終了後は、通常の受信パケット処理に復帰する（４−７）。
【図面の簡単な説明】
【００４５】
【図１】本発明によるヘルスチェックデータの識別及びキューへの格納を示す図である。
【図２】本発明による受信処理の全体フローを示す図である。
【図３】本発明の実施例の構成例を示す図である。
【図４】本発明の実施例のヘルスチェックの処理の流れを示す図である。
【図５】本発明の実施例のヘルスチェック応答のチェイン組み込みを示す図である。
【図６】従来のへルスチェックの動作シーケンスを示す図である。
【図７】従来の受信データの処理のフローを示す図である。
【図８】ヘルスチェックデータが処理されるまでの平均待ち時間のグラフである。
【符号の説明】
【００４６】
１−１  二重ＣＲＣチェック処理
１−２  ヘルスチェック検出処理
１−３  ヘルスチェック応答をキューに準備する処理
１−４  準備した応答を未送信データの先頭に配置する処理
【図１】
2008199432.tif 000003
【図２】
2008199432.tif 000004
【図３】
2008199432.tif 000005
【図４】
2008199432.tif 000006
【図５】
2008199432.tif 000007
【図６】
2008199432.tif 000008
【図７】
2008199432.tif 000009
【図８】
2008199432.tif 000010