(57)【要約】【課題】ＳＳＣＯＰプロトコルに基づくデータの送受信において、送信要求が廃棄されるのを緩和すること。【解決手段】データ送信装置１は、受け付けた送信要求のメッセージを送信用バッファに格納する。送信用バッファは、１個の送信要求に対して１個使われる。データ送信装置１は、複数の送信用バッファにそれぞれ格納されたメッセージを１単位のデータに束ねて送信する。その際、データ送信装置１は、束ねられたメッセージを格納していた送信用バッファを解放し、メッセージを格納していない状態とする。データ受信装置２は、複数のメッセージが束ねられたデータを受信し、そのデータから元の複数のメッセージを取り出す。【選択図】図１
2009272776.tif 000002
【特許請求の範囲】
【請求項１】
ＳＳＣＯＰプロトコルに基づいてデータを送信するデータ送信装置において、
メッセージの送信要求を格納する複数の送信用バッファと、
複数の前記送信用バッファのそれぞれに格納された前記送信要求を１単位のデータに束ねる統合手段と、
複数の前記送信要求が束ねられた１単位の前記データを送信する送信手段と、
を備えることを特徴とするデータ送信装置。
【請求項２】
前記送信要求を格納している前記送信用バッファの数、前記送信要求を格納していない前記送信用バッファの数および送信ウィンドウ数のいずれかに基づいて輻輳状態の発生を判断する判定手段、をさらに備え、
前記統合手段は、前記判定手段により輻輳状態の発生中であると判断されたときに、複数の前記送信要求を１単位のデータに束ねることを特徴とする請求項１に記載のデータ送信装置。
【請求項３】
ＳＳＣＯＰプロトコルに基づいてデータを受信するデータ受信装置において、
データを受信する受信手段と、
前記受信手段により受信された前記データから複数のメッセージを取り出す分割手段と、
前記分割手段により分割された複数の前記メッセージをそれぞれ格納する受信用バッファと、
を備えることを特徴とするデータ受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ＳＳＣＯＰ（Ｓｅｒｖｉｃｅ  Ｓｐｅｃｉｆｉｃ  Ｃｏｎｎｅｃｔｉｏｎ  Ｏｒｉｅｎｔｅｄ  Ｐｒｏｔｏｃｏｌ）プロトコルに基づいてデータの送受信を行うデータ送信装置およびデータ受信装置に関する。
【背景技術】
【０００２】
ＳＳＣＯＰプロトコルにおいては、受信装置から送信装置に、データの送信を許可するクレジットが与えられる。送信装置は、そのクレジットの範囲内でシーケンスデータ（以下、ＳＤ−ＰＤＵとする。ＳＤ−ＰＤＵ：Ｓｅｑｕｅｎｃｅｄ  Ｄａｔａ  Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）を受信装置へ送信する（例えば、非特許文献１参照。）。
【０００３】
ところで、従来、送信データを所定長さの複数のパケットに分け、各パケットにそれぞれヘッダを付加して、送信側から受信側に送信するデータ送信方法が公知である。このようなデータ送信方法において、送信データのサイズとヘッダサイズの合計サイズと受信側の受信可能データサイズを比較し、合計サイズが受信可能データサイズよりも小さい場合には、送信データを一つのパケットとして受信側に送信する方法が提案されている（例えば、特許文献１参照。）。
【０００４】
【特許文献１】特開平１１−１８７０６８号公報
【非特許文献１】社団法人情報通信技術委員会、「ＪＴ−Ｑ２１１０  広帯域ＩＳＤＮ  ＡＡＬサービス依存  コネクション型プロトコル（ＳＳＣＯＰ）」、第１．１版、１９９６年２月６日制定、ｐ．３１
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来のＳＳＣＯＰプロトコルに基づくデータの送受信では、次のような問題点がある。送信装置は、複数の送信用バッファを有する。その数は、送信装置の設計段階で決められている。送信装置は、受信装置からデータ送信の許可が与えられないと、その許可が与えられるまで、上位レイヤーからの送信要求を送信用バッファに格納して保持する。送信用バッファは、１個の送信要求に対して１個使われる。従って、短い信号の送信要求を格納した送信用バッファには、空き領域が残ることになる。用意された全ての送信用バッファが使われてしまうと、個々の送信用バッファに空き領域があっても、新たな送信要求を格納することができないため、それ以降の送信要求は破棄されてしまう。従って、輻輳状態などのように、受信装置からデータ送信の許可が与えられない状況では、全ての送信用バッファに１個ずつ送信要求が格納された状態となり、破棄される送信要求が増えてしまう。
【０００６】
一方、前記特許文献１に開示されたデータ送信方法は、１個の大きな送信データを分割して送信側から受信側へ送信する際に、その送信データが受信側の受信可能データサイズよりも小さければ、送信データを分割しないで送信するというものである。つまり、ＳＳＣＯＰプロトコルに基づくデータの送受信において、送信用バッファを使い果たしたことによる送信要求の破棄を緩和または防止することはできない。
【０００７】
この発明は、上述した従来技術による問題点を解消するため、ＳＳＣＯＰプロトコルに基づくデータの送受信において、送信要求が廃棄されるのを緩和することができるデータ送信装置およびデータ受信装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述した課題を解決し、目的を達成するため、このデータ送信装置およびデータ受信装置は、送信側に、複数の送信用バッファ、統合手段および送信手段を備え、受信側に、受信手段、分割手段および受信用バッファを備えることを要件とする。送信用バッファは、メッセージの送信要求を格納する。統合手段は、複数の送信用バッファのそれぞれに格納された送信要求を１単位のデータに束ねる。送信手段は、複数の送信要求が束ねられた１単位のデータを送信する。受信手段は、送信手段により送信されたデータを受信する。分割手段は、受信手段により受信されたデータから複数のメッセージを取り出す。受信用バッファは、分割手段により分割された複数のメッセージをそれぞれ格納する。
【０００９】
また、送信側に判定手段があり、送信側において、送信要求を格納している送信用バッファの数、送信要求を格納していない送信用バッファの数および送信ウィンドウ数のいずれかに基づいて輻輳状態の発生を判断するようにしてもよい。この場合、統合手段は、判定手段により輻輳状態の発生中であると判断されたときに、複数の送信要求を１単位のデータに束ねるようにしてもよい。
【００１０】
このデータ送信装置およびデータ受信装置によれば、ＳＳＣＯＰプロトコルに基づくデータの送受信において、データ送信装置は、複数の送信用バッファにそれぞれ格納されたメッセージを１単位のデータに束ね、個々のメッセージを格納していた送信用バッファを解放し、複数のメッセージを束ねたデータを送信する。データ受信装置は、複数のメッセージが束ねられたデータを受信し、そのデータから元の複数のメッセージを取り出す。従って、送信用バッファが実質的に増えることになる。
【発明の効果】
【００１１】
このデータ送信装置およびデータ受信装置によれば、ＳＳＣＯＰプロトコルに基づくデータの送受信において、送信用バッファが実質的に増えることによって、送信要求が廃棄されるのを緩和することができるという効果を奏する。
【発明を実施するための最良の形態】
【００１２】
以下に添付図面を参照して、このデータ送信装置およびデータ受信装置の好適な実施の形態を詳細に説明する。
【００１３】
（概略）
図１は、実施の形態にかかるデータ送受信システムの概略を示す説明図である。図１に示すように、ＳＳＣＯＰプロトコルに基づくデータの送受信において、データ送信装置１は、受け付けた送信要求のメッセージを送信用バッファに格納する。送信用バッファは、１個の送信要求に対して１個使われる。データ送信装置１は、複数の送信用バッファにそれぞれ格納されたメッセージを１単位のデータに束ねて送信する。その際、データ送信装置１は、束ねられたメッセージを格納していた送信用バッファを解放し、メッセージを格納していない状態とする。データ受信装置２は、複数のメッセージが束ねられたデータ（以下、マルチメッセージデータとする）を受信し、そのデータから元の複数のメッセージを取り出す。
【００１４】
図１に示す例を用いて、具体的に説明する。データ送信装置１は、第１〜第３の送信要求（送信要求＃１〜＃３）を受け付ける。それによって、送信用バッファの残りの数は、１０個から３個減って７個になる。そして、データ送信装置１は、送信要求＃１〜＃３を束ねて、１個のシーケンスデータ（ＳＤ）にする。その際、送信用バッファが２個解放されるので、送信用バッファの残りの数は、７個から２個増えて９個になる。そして、データ送信装置１は、３個のメッセージを束ねたシーケンス番号（ＮＳ）５のシーケンスデータ（ＳＤ）を、第５シーケンスデータ信号（信号＃５）としてデータ受信装置２へ送信する。それによって、送信ウィンドウ数は、５個から１個減って４個になる。
【００１５】
続いて、データ送信装置１は、第４〜第５の送信要求（送信要求＃４〜＃５）をシーケンス番号（ＮＳ）６のシーケンスデータ（ＳＤ）に束ね、第６シーケンスデータ信号（信号＃６）としてデータ受信装置２へ送信する。さらに続いて、データ送信装置１は、第６〜第９の送信要求（送信要求＃６〜＃９）をシーケンス番号（ＮＳ）７のシーケンスデータ（ＳＤ）に束ね、第７シーケンスデータ信号（信号＃７）としてデータ受信装置２へ送信する。ここまでで、送信用バッファの残りの数は７個となり、送信ウィンドウ数は２個となる。データ送信装置１は、一定周期ごとに、または一定数のシーケンスデータを送信するたびに、データ受信装置２へ状態要求信号（ＰＯＬＬ）を送信する。
【００１６】
図１に示す例では、データ送信装置１は、第７シーケンスデータ信号（信号＃７）の送信に続いて、ポールシーケンス番号（ＮＰＳ）２の第２状態要求信号を送信し、次に送信する予定のシーケンスデータのシーケンス番号（ＮＳ）が８であることをデータ受信装置２に通知する。データ受信装置２は、第２状態要求信号に応答して、データ送信装置１へ状態要求回答信号（ＳＴＡＴ）を送信する。この状態要求回答信号（ＳＴＡＴ）では、ポールシーケンス番号（ＮＰＳ）２の第２状態要求信号に対する応答であり、次受信期待シーケンスデータのシーケンス番号（ＮＲ）が８であり、受信不許可シーケンスデータのシーケンス番号（ＮＭＲ）が１０であることが通知されている。
【００１７】
データ送信装置１は、状態要求回答信号（ＳＴＡＴ）の受信により、シーケンス番号（ＮＳ）７のシーケンスデータまで無事に送達できたことを確認し、前回の図示しない状態要求回答信号（ＳＴＡＴ）の受信後に使用中の送信用バッファを解放する。送信ウィンドウ数は、受信不許可シーケンスデータのシーケンス番号（ＮＭＲ）の値に基づいて増減する。図１に示す例では、受信不許可シーケンスデータのシーケンス番号（ＮＭＲ）の値が、前回の状態要求回答信号（ＳＴＡＴ）のときと同じであるとするので、送信ウィンドウ数は、変わらずに２個のままである。
【００１８】
続いて、データ送信装置１は、第１０〜第１２の送信要求（送信要求＃１０〜＃１２）をシーケンス番号（ＮＳ）８のシーケンスデータ（ＳＤ）に束ね、第８シーケンスデータ信号（信号＃８）としてデータ受信装置２へ送信する。さらに続いて、データ送信装置１は、第１３〜第１６の送信要求（送信要求＃１３〜＃１６）をシーケンス番号（ＮＳ）９のシーケンスデータ（ＳＤ）に束ね、第９シーケンスデータ信号（信号＃９）としてデータ受信装置２へ送信する。ここまでで、送信用バッファの残りの数は８個となり、送信ウィンドウ数は０個となる。
【００１９】
続いて、データ送信装置１は、ポールシーケンス番号（ＮＰＳ）３の第３状態要求信号を送信し、次に送信する予定のシーケンスデータのシーケンス番号（ＮＳ）が１０であることをデータ受信装置２に通知する。データ受信装置２は、第３状態要求信号に応答して、ポールシーケンス番号（ＮＰＳ）３の第３状態要求信号に対する応答であり、次受信期待シーケンスデータのシーケンス番号（ＮＲ）が１０であり、受信不許可シーケンスデータのシーケンス番号（ＮＭＲ）が１１であることをデータ送信装置１に通知する。
【００２０】
データ送信装置１は、状態要求回答信号（ＳＴＡＴ）の受信により、シーケンス番号（ＮＳ）９のシーケンスデータまで無事に送達できたことを確認し、第２状態要求信号に対する前回の状態要求回答信号（ＳＴＡＴ）の受信後に使用中の送信用バッファを解放する。それによって、送信用バッファの残りの数は、８個から２個増えて１０個となる。また、受信不許可シーケンスデータのシーケンス番号（ＮＭＲ）が前回の１０から１増えて１１になっているので、送信ウィンドウ数が直前の０個から１個増えて１個となる。なお、図１に示す例は、一例であり、これに限定されるものではない。
【００２１】
（データ送信装置の構成）
図２は、実施の形態にかかるデータ送受信システムの構成を示すブロック図である。図２に示すように、データ送信装置１は、送信用バッファプール１１、送信処理部１２およびユーザ部１３を備えている。送信用バッファプール１１には、複数の送信用バッファ１４が設けられている。送信処理部１２には、判定部１５、統合部１６および送信部１７が設けられている。
【００２２】
送信用バッファ１４は、上位レイヤーから送られてくる送信要求のメッセージを格納して保持する。判定部１５は、全送信用バッファ１４のうち、メッセージを格納している送信用バッファ１４の数（以下、使用バッファ数とする）もしくはメッセージを格納していない送信用バッファ１４の数（以下、残りバッファ数とする）、または送信ウィンドウ数に基づいて、輻輳状態の発生を判断する。判定部１５は、例えば後述する判定処理のプログラムをプロセッサで実行することにより実現される。統合部１６は、判定部１５により輻輳状態の発生中であると判断されたときに、複数の送信用バッファ１４のそれぞれに格納されたメッセージを１単位のデータに束ねる。統合部１６は、例えば後述する統合処理のプログラムをプロセッサで実行することにより実現される。送信部１７は、統合部１６により束ねられた複数のメッセージからなるマルチメッセージデータを送信する。ユーザ部１３は、例えば、データ送信を要求するアプリケーションである。
【００２３】
（データのフレームフォーマット）
上述したように、複数のメッセージを１個のデータに束ねて送信するため、従来のＳＳＣＯＰプロトコルにおけるデータのフレームフォーマットを拡張する必要がある。この拡張したフレームフォーマットについて説明する。
【００２４】
図３は、実施の形態にかかるフレームフォーマットを示す説明図である。図４は、従来のＳＳＣＯＰプロトコルにおけるフレームフォーマットを示す説明図である。ここでは、［ｎ＋１］個（ｎは、自然数）のメッセージが束ねられるとする。図３に示すように、実施の形態にかかるフレームフォーマット（以下、拡張フォーマットとする）３は、束ねられるメッセージ（メッセージ＃０〜＃ｎ）ごとにサブフレームを有する。各サブフレームは、情報フィールド（情報＃０〜＃ｎ）３１、パディングフィールド（ＰＡＤ＃０〜＃ｎ）３２、マルチパッド長フィールド（ＰＬＭ＃０〜＃ｎ）３３、予約フィールド３４およびメッセージ長フィールド（ｌｅｎｇｔｈ＃０〜＃ｎ）３５を有する。
【００２５】
情報フィールド３１、パディングフィールド３２および予約フィールド３４は、それぞれ、従来のフレームフォーマット４における情報フィールド４１、パディングフィールド（ＰＡＤ）４２および予約フィールド４４と同様である。マルチパッド長フィールド３３は、図４に示す従来のフレームフォーマット４におけるパッド長フィールド（ＰＬ）４３と同様である。ただし、ｉを０〜ｎの整数とすると、メッセージ＃ｉのマルチパッド長フィールド（ＰＬＭ＃ｉ）３３には、メッセージ＃ｉのサブフレーム内にあるパディングのオクテット数が格納される。また、メッセージ＃ｉのメッセージ長フィールド（ｌｅｎｇｔｈ＃ｎ）３５には、メッセージ＃ｉのサブフレームのメッセージ長が格納される。
【００２６】
また、拡張フォーマット３は、パッド長フィールド（ＰＬ）３６、予約フィールド３７、識別フィールド（Ｍ）３８、ＰＤＵタイプフィールド３９およびシーケンス番号フィールド（ＮＳ）４０を有する。パッド長フィールド３６、予約フィールド３７、ＰＤＵタイプフィールド３９およびシーケンス番号フィールド３０は、それぞれ、従来のフレームフォーマット４におけるパッド長フィールド４３、予約フィールド４４、ＰＤＵタイプフィールド４５およびシーケンス番号フィールド４０と同様である。ただし、拡張フォーマット３においては、パッド長フィールド３６に格納されている値は、無効として扱われる。識別フィールド３８には、マルチメッセージデータであるか否かを示す値が格納される。例えば、識別フィールド３８には、マルチメッセージデータである場合に“１”が格納され、マルチメッセージデータでない場合（従来同様のシーケンスデータ）に“０”が格納される。
【００２７】
（統合処理の説明）
図５は、実施の形態にかかる統合処理を説明するフローチャートである。図５に示すように、統合処理が開始されると、統合部１６は、次の処理を行う。まず、統合対象の最初のメッセージにポインタを設定する（ステップＳ１）。次いで、メッセージ長の合計値を０に設定する（ステップＳ２）。
【００２８】
次いで、最初のメッセージについて、マルチパッド長を求め、パディングフィールド（ＰＡＤ＃ｉ）３２およびマルチパッド長フィールド（ＰＬＭ＃ｉ）３３にそれぞれパディングおよびマルチパッド長を設定する（ステップＳ３）。次いで、最初のメッセージについて、メッセージ長フィールド（ｌｅｎｇｔｈ＃ｉ）３５にメッセージ長を設定する（ステップＳ４）。ここで、メッセージ長には、マルチパッド長が含まれる。
【００２９】
次いで、最初のメッセージを追加できるか否かを判断する（ステップＳ５）。最初のメッセージのメッセージ長は、１回で送信することができるデータ長よりも小さいので、常にメッセージの追加が可能となる（ステップＳ５：Ｙｅｓ）。次いで、メッセージ長の合計値（最初は０）に、最初のメッセージのメッセージ長を加算して、新たなメッセージ長の合計値とする（ステップＳ６）。
【００３０】
次いで、ポインタが設定されたメッセージが最初のメッセージであるか否かを判断するが、最初のメッセージであるので（ステップＳ７：Ｙｅｓ）、次のメッセージがあるか否かを判断する（ステップＳ１０）。次のメッセージがない場合（ステップＳ１０：Ｎｏ）、データは最初のメッセージだけであるので、識別フィールド３８に、マルチメッセージデータでないことを示す値（例えば“０”）を設定し（ステップＳ１２）、処理を終了する。
【００３１】
一方、次のメッセージがある場合（ステップＳ１０：Ｙｅｓ）、次のメッセージにポインタを設定する（ステップＳ１１）。そして、ステップＳ３に戻る。新たにポインタが設定されたメッセージについて、上述したように、パディングフィールド（ＰＡＤ＃ｉ）３２、マルチパッド長フィールド（ＰＬＭ＃ｉ）３３およびメッセージ長フィールド（ｌｅｎｇｔｈ＃ｉ）３５を設定する（ステップＳ３、ステップＳ４）。
【００３２】
次いで、メッセージを追加できるか否かを判断する。既に設定されているメッセージ長の合計値に、新たにポインタが設定されたメッセージのメッセージ長を加算した値が、１回で送信可能なデータ長の値以下になる場合に、メッセージを追加することができる。そうでない場合には、メッセージを追加することができない。次のメッセージを追加できない場合（ステップＳ５：Ｎｏ）、データは最初のメッセージだけであるので、識別フィールド３８に、マルチメッセージデータでないことを示す値（例えば“０”）を設定し（ステップＳ１２）、処理を終了する。
【００３３】
一方、次のメッセージを追加できる場合（ステップＳ５：Ｙｅｓ）、既に設定されているメッセージ長に、追加するメッセージのメッセージ長を加算してメッセージ長の合計値を更新する（ステップＳ６）。次いで、ポインタが設定されたメッセージが最初のメッセージであるか否かを判断するが、最初のメッセージではないので（ステップＳ７：Ｎｏ）、ポインタが設定されたメッセージ＃ｉを、前回ポインタが設定されたメッセージ＃ｉ−１の最後の位置にコピーする（ステップＳ８）。そして、ポインタが設定されたメッセージ＃ｉを格納している送信用バッファ１４を解放し、送信用バッファプール１１に返却する（ステップＳ９）。
【００３４】
次いで、次のメッセージがあるか否かを判断する（ステップＳ１０）。次のメッセージがある場合（ステップＳ１０：Ｙｅｓ）、ステップＳ１１に進む。以後、次のメッセージを追加できなくなるまで（ステップＳ５：Ｎｏ）、または次のメッセージがなくなるまで（ステップＳ１０：Ｎｏ）、ステップＳ３〜ステップＳ１１を繰り返す。ステップＳ５で次のメッセージを追加できなくなるか、またはステップＳ１０で次のメッセージがなくなると、識別フィールド３８に、マルチメッセージデータであることを示す値（例えば、“１”）を設定し（ステップＳ１２）、処理を終了する。
【００３５】
（判定処理の説明）
判定部１５が行う判定処理は、次の第１〜第５のいずれでもよい。
【００３６】
（第１判定処理の説明）
図６は、実施の形態にかかる第１判定処理を説明するフローチャートである。第１判定処理は、使用バッファ数を監視し、使用バッファ数が第１閾値未満から第１閾値以上になると輻輳状態になると判断し、使用バッファ数が第２閾値よりも大きい値から第２閾値以下になると輻輳状態から復旧すると判断するものである。図６に示すように、第１判定処理が開始されると、判定部１５は、まず、輻輳状態であるか否かを示すフラグがオンであるかオフであるかを判断する（ステップＳ２１）。このフラグは、例えば、輻輳状態であるときにオンとなり、輻輳状態でないときにオフとなる。
【００３７】
フラグがオフである場合（ステップＳ２１：Ｎｏ）、使用バッファ数が第１閾値以上であるか否かを判断する（ステップＳ２２）。使用バッファ数が第１閾値未満である場合（ステップＳ２２：Ｎｏ）、処理を終了する。使用バッファ数が第１閾値以上である場合（ステップＳ２２：Ｙｅｓ）、フラグをオンにして（ステップＳ２３）、処理を終了する。
【００３８】
一方、フラグがオンである場合（ステップＳ２１：Ｙｅｓ）、使用バッファ数が第２閾値以下であるか否かを判断する（ステップＳ２４）。例えば、第２閾値は第１閾値よりも小さい。使用バッファ数が第２閾値を超える場合（ステップＳ２４：Ｎｏ）、処理を終了する。使用バッファ数が第２閾値以下である場合（ステップＳ２４：Ｙｅｓ）、フラグをオフにして（ステップＳ２５）、処理を終了する。この第１判定処理は、送信要求を受信するたびに、実施される。
【００３９】
図７および図８は、それぞれ、第１閾値を用いた輻輳発生判定および第２閾値を用いた輻輳復旧判定を説明する説明図である。図７には、第１閾値を例えば１０とした例が示されている。図８には、第２閾値を例えば５とした例が示されている。図７に示すように、判定部１５は、輻輳が発生していないときには、使用バッファ数が第１閾値未満（０〜９）から第１閾値以上（１０以上）になると輻輳発生と判断する。また、図８に示すように、判定部１５は、輻輳が発生しているときには、使用バッファ数が第２閾値を超える値（６以上）から第２閾値以下（０〜５）になると輻輳復旧と判断する。このように、輻輳状態の判定には、ヒステリシスがある。
【００４０】
（第２判定処理の説明）
図９は、実施の形態にかかる第２判定処理を説明するフローチャートである。第２判定処理では、一定の周期で使用バッファ数を保存する。この周期を保存周期とする。第２判定処理は、前回の保存周期における使用バッファ数と今回の保存周期における使用バッファ数を比較し、その増加分が第１閾値以上であるときに輻輳予測条件を満たしたとし、この輻輳予測条件を１周期または連続した複数周期間満たしたときに、次の保存周期を輻輳状態になると予測するものである。輻輳状態からの復旧に関しては、例えば前記第１判定処理と同様である。
【００４１】
図９に示すように、第２判定処理が開始されると、判定部１５は、まず、輻輳状態であるか否かを示すフラグがオンであるかオフであるかを判断する（ステップＳ３１）。このフラグは、例えば、輻輳状態であるときにオンとなり、輻輳状態でないときにオフとなる。フラグがオフである場合（ステップＳ３１：Ｎｏ）、前回の保存周期における使用バッファ数に対する現在の保存周期における使用バッファ数の増加分を算出する（ステップＳ３２）。次いで、使用バッファ数の増加分が第１閾値以上であるか否かを判断する（ステップＳ３３）。
【００４２】
使用バッファ数の増加分が第１閾値以上である場合（ステップＳ３３：Ｙｅｓ）、使用バッファ数の増加分が第１閾値以上であることを検出した回数を１だけインクリメントする（ステップＳ３４）。次いで、その検出回数が第３閾値以上であるか否かを判断する（ステップＳ３５）。検出回数が第３閾値以上である場合（ステップＳ３５：Ｙｅｓ）、フラグをオンにし（ステップＳ３６）、検出回数を０にクリアする（ステップＳ３７）。そして、現在の保存周期における使用バッファ数を前回の保存周期における使用バッファ数に設定することによって、前回の保存周期における使用バッファ数を更新し（ステップＳ３８）、処理を終了する。
【００４３】
一方、使用バッファ数の増加分が第１閾値未満である場合（ステップＳ３３：Ｎｏ）、検出回数を０にクリアし（ステップＳ３９）、現在の保存周期における使用バッファ数で前回の保存周期における使用バッファ数を更新する（ステップＳ３８）。そして、処理を終了する。また、フラグがオンである場合（ステップＳ３１：Ｙｅｓ）、前記第１判定処理と同様に、使用バッファ数が第２閾値を超える場合（ステップＳ４０：Ｎｏ）、フラグをそのままにしてステップＳ３８へ進み、使用バッファ数が第２閾値以下である場合（ステップＳ４０：Ｙｅｓ）、フラグをオフにして（ステップＳ４１）、ステップＳ３８へ進む。そして、前回の保存周期における使用バッファ数を更新し（ステップＳ３８）、処理を終了する。この第２判定処理は、一定周期ごと、例えば保存周期ごとに実施される。
【００４４】
図１０は、第１閾値が３であり、第３閾値が１である場合の輻輳発生判定を説明する説明図である。図１０に示すように、前回の保存周期における使用バッファ数が４であり、現在の保存周期における使用バッファ数が７である場合に、判定部１５は、輻輳発生と判断する。
【００４５】
図１１は、第１閾値が３であり、第３閾値が２である場合の輻輳発生判定を説明する説明図である。図１１に示すように、前回の保存周期における使用バッファ数が２であり、現在の保存周期における使用バッファ数が５であり、さらにその次の保存周期における使用バッファ数が８である場合に、判定部１５は、輻輳発生と判断する。一方、前回の保存周期における使用バッファ数が２であり、現在の保存周期における使用バッファ数が５であっても、その次の保存周期における使用バッファ数がさらに３以上増えない場合には、判定部１５は、輻輳状態でないと判断する。
【００４６】
（第３判定処理の説明）
図１２は、実施の形態にかかる第３判定処理を説明するフローチャートである。第３判定処理では、上位レイヤーからの送信要求数をある一定の周期で計測する。この周期を送信要求数計測単位時間とする。また、ある一定の連続する送信要求数計測単位時間ごとに、計測値を加算する。この計測値を加算する期間を、予測値算出単位時間とする。また、予測値算出単位時間内の加算により得られた値の平均値を、次の送信要求数計測単位時間内に発生する送信要求数の予測値とする。第３判定処理は、送信要求数の予測値が送信ウィンドウ数よりも大きくなると輻輳状態になると判断し、送信要求数の予測値が送信ウィンドウ数以下になると輻輳状態から復旧すると判断するものである。
【００４７】
図１２に示すように、第３判定処理が開始されると、判定部１５は、まず、送信要求数計測単位時間内に発生した送信要求数を計測し、記録する（ステップＳ５１）。次いで、予測値算出単位時間内に発生した送信要求数を加算する（ステップＳ５２）。次いで、輻輳等の原因により予測値算出単位時間内に処理しきれずに滞留している送信要求があるか否かを判断する（ステップＳ５３）。滞留している送信要求がある場合（ステップＳ５３：Ｙｅｓ）、ステップＳ５２で得た送信要求数の加算値に、さらに滞留中の送信要求数を加算して（ステップＳ５４）、ステップＳ５５へ進む。滞留中の送信要求がない場合（ステップＳ５３：Ｎｏ）、そのままステップＳ５５へ進む。
【００４８】
次いで、予測値算出単位時間における送信要求数の加算値を、予測値算出単位時間内の送信要求数計測単位時間の数で除算し、送信要求数の平均値を求め、その平均値を送信要求数の予測値とする（ステップＳ５５）。次いで、送信要求数の予測値が送信ウィンドウ数よりも大きいか否かを判断する（ステップＳ５６）。送信要求数の予測値が送信ウィンドウ数よりも大きい場合（ステップＳ５６：Ｙｅｓ）、フラグをオンにして（ステップＳ５７）、処理を終了する。送信要求数の予測値が送信ウィンドウ数以下である場合（ステップＳ５６：Ｎｏ）、フラグをオフにして（ステップＳ５８）、処理を終了する。ここで、このフラグは、例えば、輻輳状態であるときにオンとなり、輻輳状態でないときにオフとなる。この第３判定処理は、一定周期ごと、例えば送信要求数計測単位時間ごとに実施される。
【００４９】
図１３は、予測値算出単位時間を送信要求数計測単位時間の３倍の時間とした場合の輻輳発生判定を説明する説明図である。図１３に示すように、Ｔ１の予測値算出単位時間において、１５（＝０＋８＋７）個の送信要求数が発生しているので、Ｔ２の送信要求数計測単位時間内の送信要求数の予測値は５（＝１５÷３）個となる。この場合、実線で示すグラフのように、送信ウィンドウ数が例えば４であれば、送信要求数の予測値の方が大きいので、Ｔ２の送信要求数計測単位時間内では輻輳発生と判断する。一方、破線で示すグラフのように、送信ウィンドウ数が例えば７であれば、送信要求数の予測値の方が小さいので、Ｔ２の送信要求数計測単位時間内では輻輳状態でないと判断する。
【００５０】
図１４は、滞留中の送信要求がある場合の輻輳発生判定を説明する説明図である。滞留中の送信要求がある場合には、その滞留中の送信要求の数もＴ１の予測値算出単位時間内の送信要求数に加算する。従って、滞留中の送信要求数が２であれば、Ｔ１の予測値算出単位時間内の送信要求数は、１７（＝８＋７＋２）となり、Ｔ２の送信要求数計測単位時間内の送信要求数の予測値は、小数点以下を切り上げると６（＝１７÷３）個となる。
【００５１】
（第４判定処理の説明）
図１５は、実施の形態にかかる第４判定処理を説明するフローチャートである。第４判定処理は、送信ウィンドウ数が０になると輻輳状態になると判断し、送信ウィンドウ数が第１閾値以上になるか、または残りバッファ数が第２閾値以上になると輻輳状態から復旧すると判断するものである。図１５に示すように、第４判定処理が開始されると、判定部１５は、まず、輻輳状態であるか否かを示すフラグがオンであるかオフであるかを判断する（ステップＳ６１）。このフラグは、例えば、輻輳状態であるときにオンとなり、輻輳状態でないときにオフとなる。
【００５２】
フラグがオフである場合（ステップＳ６１：Ｎｏ）、送信ウィンドウ数が０以下であるか否かを判断する（ステップＳ６２）。送信ウィンドウ数が０よりも大きい場合（ステップＳ６２：Ｎｏ）、処理を終了する。送信ウィンドウ数が０以下である場合（ステップＳ６２：Ｙｅｓ）、フラグをオンにして（ステップＳ６３）、処理を終了する。
【００５３】
一方、フラグがオンである場合（ステップＳ６１：Ｙｅｓ）、送信ウィンドウ数が第１閾値以上であるか否かを判断する（ステップＳ６４）。送信ウィンドウ数が第１閾値以上である場合（ステップＳ６４：Ｙｅｓ）、フラグをオフにして（ステップＳ６５）、処理を終了する。送信ウィンドウ数が第１閾値未満である場合（ステップＳ６４：Ｎｏ）、残りバッファ数が第２閾値以上であるか否かを判断する（ステップＳ６６）。残りバッファ数が第２閾値以上である場合（ステップＳ６６：Ｙｅｓ）、フラグをオフにして（ステップＳ６５）、処理を終了する。残りバッファ数が第２閾値未満である場合（ステップＳ６６：Ｎｏ）、処理を終了する。この第４判定処理は、送信要求を受信するたびに、実施される。
【００５４】
（第５判定処理の説明）
図１６は、実施の形態にかかる第５判定処理を説明するフローチャートである。図１７は、受信側の処理能力と閾値の関係を示す図表である。第５判定処理は、データ受信装置２の処理能力に応じて閾値を変更し、残りバッファ数がその閾値よりも小さくなると輻輳状態になると判断し、残りバッファ数がその閾値以上になると輻輳状態から復旧すると判断するものである。データ送信装置１は、シーケンスデータ（ＳＤ）を送信する際に、その送信時刻Ｔｓｄとその時点での送信ウィンドウ数Ｗｓｄを記録しておく。また、データ送信装置１は、データ受信装置２から状態要求回答信号（ＳＴＡＴ）を受信する際に、その受信時刻Ｔｓｔと、状態要求回答信号の受信によって更新された送信ウィンドウ数Ｗｓｔを記録しておく。
【００５５】
図１６に示すように、第５判定処理が開始されると、判定部１５は、まず、送信ウィンドウ数が最大値に戻っているか否かを判断する（ステップＳ７１）。送信ウィンドウ数が最大値に戻っていない場合（ステップＳ７１：Ｎｏ）、記録してあるシーケンスデータ（ＳＤ）の送信時刻Ｔｓｄおよびそのときの送信ウィンドウ数Ｗｓｄと、状態要求回答信号の受信時刻Ｔｓｔおよび更新後の送信ウィンドウ数Ｗｓｔを用いて次式の計算を行い、時間当たりの処理メッセージ数ΔＷを求める（ステップＳ７２）。
ΔＷ＝（Ｗｓｔ−Ｗｓｄ）／（Ｔｓｔ−Ｔｓｄ）
【００５６】
次いで、時間当たりの処理メッセージ数ΔＷの値に応じて（ステップＳ７３）、図１７に示す表に従って閾値を設定する（ステップＳ７４〜ステップＳ７７）。例えば、時間当たりの処理メッセージ数ΔＷが０個〜ａ個である場合、閾値をＡに設定する（ステップＳ７４）。時間当たりの処理メッセージ数ΔＷが［ａ＋１］個〜ｂ個である場合、閾値をＢに設定する（ステップＳ７５）。時間当たりの処理メッセージ数ΔＷが［ｂ＋１］個〜ｃ個である場合、閾値をＣに設定する（ステップＳ７６）。時間当たりの処理メッセージ数ΔＷが［ｃ＋１］個〜最大値である場合、閾値をＤに設定する（ステップＳ７７）。また、ステップＳ７１で送信ウィンドウ数が最大値に戻っている場合も（ステップＳ７１：Ｙｅｓ）、閾値をＤに設定する（ステップＳ７８）。ここで、例えば、ａ＜ｂ＜ｃであり、Ａ＞Ｂ＞Ｃ＞Ｄである。
【００５７】
次いで、残りバッファ数が、ステップＳ７４〜ステップＳ７８で設定された閾値よりも小さいか否かを判断する（ステップＳ７９）。残りバッファ数が閾値よりも小さい場合（ステップＳ７９：Ｙｅｓ）、フラグをオンにして（ステップＳ８０）、処理を終了する。残りバッファ数が閾値以上である場合（ステップＳ７９：Ｎｏ）、フラグをオフにして（ステップＳ８１）、処理を終了する。ここで、このフラグは、例えば、輻輳状態であるときにオンとなり、輻輳状態でないときにオフとなる。この第５判定処理は、データ受信装置２から状態要求回答信号（ＳＴＡＴ）を受信するたびに実施される。
【００５８】
なお、ステップＳ７４〜ステップＳ７８において閾値を、送信用バッファ１４の全数に対する残りバッファ数の割合で設定し、ステップＳ７９において残りバッファ数の割合と閾値を比較するようにしてもよい。また、閾値を、送信用バッファ１４の全数に対する使用バッファ数の割合で設定し、使用バッファ数の割合と閾値を比較するようにしてもよい。
【００５９】
（データ受信装置の構成）
図２に示すように、データ受信装置２は、受信用バッファプール２１、受信処理部２２およびユーザ部２３を備えている。受信用バッファプール２１には、複数の受信用バッファ２４が設けられている。受信処理部２２には、受信部２５および分割部２６が設けられている。受信部２５は、データ送信装置１から送信されてきたデータを受信する。分割部２６は、受信部２５により受信されたデータから、データ送信装置１において束ねられた複数のメッセージを取り出す。分割部２６は、例えば後述する分割処理のプログラムをプロセッサで実行することにより実現される。受信用バッファ２４は、受信部２５により受信されたデータ、および分割部２６により取り出された個々のメッセージを格納する。ユーザ部２３は、例えば、データを受信するアプリケーションである。
【００６０】
（分割処理の説明）
図１８は、実施の形態にかかる分割処理を説明するフローチャートである。図１８に示すように、分割処理が開始されると、分割部２６は、次の処理を行う。まず、メッセージ数を１に設定する（ステップＳ９１）。次いで、分割処理対象のデータの識別フィールド３８を参照し、このデータがマルチメッセージデータであるか否かを判断する（ステップＳ９２）。マルチメッセージデータでない場合（ステップＳ９２：Ｎｏ）、処理を終了する。一方、マルチメッセージデータである場合（ステップＳ９２：Ｙｅｓ）、受信用バッファプール２１から受信用バッファ２４を捕捉する（ステップＳ９３）。
【００６１】
次いで、捕捉したバッファに、メッセージ長フィールド（ｌｅｎｇｔｈ＃ｉ）３５の値の長さ分だけメッセージをコピーする（ステップＳ９４）。次いで、メッセージ長の合計値から、バッファにコピーしたメッセージのメッセージ長を減算して、新たなメッセージ長の合計値とする（ステップＳ９５）。次いで、メッセージ数を１だけ更新する（ステップＳ９６）。次いで、メッセージ長の合計値が次のメッセージのメッセージ長と同じであるか否かを判断する（ステップＳ９７）。同じでなければ（ステップＳ９７：Ｎｏ）、ステップＳ９３に戻り、ステップＳ９３〜ステップＳ９７を繰り返し、順次、バッファにメッセージ数を１個ずつコピーしていく。メッセージ長の合計値が次のメッセージのメッセージ長と同じになると（ステップＳ９７：Ｙｅｓ）、処理を終了する。
【００６２】
以上説明したように、本実施の形態によれば、データ送信装置１は、複数の送信用バッファ１４にそれぞれ格納されたメッセージを１単位のデータに束ねてマルチメッセージデータとして送信し、個々のメッセージを格納していた送信用バッファ１４を解放する。データ受信装置２は、マルチメッセージデータを受信し、そのデータから元の複数のメッセージを取り出す。従って、送信用バッファ１４が実質的に増えることになるので、送信要求が廃棄されるのを緩和することができる。また、１回のデータ送信で複数のメッセージを送ることができるので、同一の信号量でも、負荷に対する耐力を向上させることができる。また、同時に複数のメッセージを送るので、従来よりも早く送信を完了させることができる。また、受信側で輻輳状態が発生していることを的確に判断することができるので、より一層、効率よく輻輳を緩和したり、送信要求が廃棄されるのを緩和することができる。また、実質的に従来と同数の送信用バッファが設けられていればよい場合には、送信用バッファの数を従来よりも少なくすることができるので、コストを削減することができる。
【００６３】
以上において本発明は、上述した実施の形態に限らず、種々変更可能である。例えば、判定部１５、統合部１６および分割部２６は、ソフトウェアにより実現されるとしたが、ハードウェアによって実現されてもよい。また、判定処理、統合処理および分割処理の各プログラムは、上述した例に限らない。また、拡張フォーマット３は、上述した例に限らない。また、輻輳状態が発生していないときでも複数のメッセージを１単位のデータに束ねて送信するようにしてもよい。また、第１判定処理において、第１閾値と第２閾値が同じでもよい。
【００６４】
上述した実施の形態に関し、さらに以下の付記を開示する。
【００６５】
（付記１）ＳＳＣＯＰプロトコルに基づいてデータを送信するデータ送信装置において、メッセージの送信要求を格納する複数の送信用バッファと、複数の前記送信用バッファのそれぞれに格納された前記送信要求を１単位のデータに束ねる統合手段と、複数の前記送信要求が束ねられた１単位の前記データを送信する送信手段と、を備えることを特徴とするデータ送信装置。
【００６６】
（付記２）前記送信要求を格納している前記送信用バッファの数、前記送信要求を格納していない前記送信用バッファの数および送信ウィンドウ数のいずれかに基づいて輻輳状態の発生を判断する判定手段、をさらに備え、前記統合手段は、前記判定手段により輻輳状態の発生中であると判断されたときに、複数の前記送信要求を１単位のデータに束ねることを特徴とする付記１に記載のデータ送信装置。
【００６７】
（付記３）前記判定手段は、前記送信要求を格納している前記送信用バッファの数が第１閾値未満から前記第１閾値以上になると輻輳発生と判断し、前記送信要求を格納している前記送信用バッファの数が第２閾値を超える値から前記第２閾値以下になると輻輳復旧と判断することを特徴とする付記２に記載のデータ送信装置。
【００６８】
（付記４）前記判定手段は、所定の周期ごとに前記送信要求を格納している前記送信用バッファの数の増加分を求め、前記増加分が第１閾値未満から前記第１閾値以上になる状態が１回または連続して所定回数発生すると輻輳発生と判断し、前記送信要求を格納している前記送信用バッファの数が第２閾値を超える値から前記第２閾値以下になると輻輳復旧と判断することを特徴とする付記２に記載のデータ送信装置。
【００６９】
（付記５）前記判定手段は、過去に発生した前記送信要求の数および処理待ちの前記送信要求の数に基づいて、次に発生する前記送信要求の予測値を求め、前記予測値が前記送信ウィンドウ数よりも大きいときに輻輳発生と判断し、前記予測値が前記送信ウィンドウ数以下であるときに輻輳復旧と判断することを特徴とする付記２に記載のデータ送信装置。
【００７０】
（付記６）前記判定手段は、前記送信ウィンドウ数が０になると輻輳発生と判断し、前記送信ウィンドウ数が第１閾値以上になるかまたは前記送信要求を格納していない前記送信用バッファの数が第２閾値以上になると輻輳復旧と判断することを特徴とする付記２に記載のデータ送信装置。
【００７１】
（付記７）前記判定手段は、前記送信要求の単位時間あたりの処理数に基づいて閾値を求め、前記送信要求を格納していない前記送信用バッファの数が前記閾値よりも小さいときに輻輳発生と判断し、前記送信要求を格納していない前記送信用バッファの数が前記閾値以上であるときに輻輳復旧と判断することを特徴とする付記２に記載のデータ送信装置。
【００７２】
（付記８）前記統合手段は、前記データのフレームフォーマットを、束ねられる前記送信要求ごとに情報フィールドおよび前記送信要求のメッセージ長を格納するメッセージ長フィールドを有するサブフレームと、複数の前記送信要求が束ねられていることを示す識別フィールドと、を備えたフォーマットに拡張し、前記送信要求を束ねるごとに前記メッセージ長フィールドの値を加算し、該加算値が許容値以下となるように、複数の前記送信要求を束ね、前記識別フィールドに、複数の前記送信要求が束ねられていることを示す値を格納することを特徴とする付記１〜７のいずれか一つに記載のデータ送信装置。
【００７３】
（付記９）前記統合手段は、束ねた前記送信要求が格納されていた前記送信用バッファを解放することを特徴とする付記８に記載のデータ送信装置。
【００７４】
（付記１０）ＳＳＣＯＰプロトコルに基づいてデータを受信するデータ受信装置において、データを受信する受信手段と、前記受信手段により受信された前記データから複数のメッセージを取り出す分割手段と、前記分割手段により分割された複数の前記メッセージをそれぞれ格納する受信用バッファと、を備えることを特徴とするデータ受信装置。
【００７５】
（付記１１）前記データは、前記メッセージごとに情報フィールドおよび前記メッセージのメッセージ長を格納するメッセージ長フィールドを有するサブフレームと、複数の前記メッセージが束ねられていることを示す識別フィールドと、を備え、前記分割手段は、前記識別フィールドに、複数の前記メッセージが束ねられていることが示されている場合に、前記データを前記メッセージ長フィールドの値ごとに個々の前記メッセージに分割し、前記メッセージを分割するごとに前記メッセージ長フィールドの値の合計値から分割した前記メッセージの前記メッセージ長フィールドの値を減算し、前記合計値が残りの前記メッセージの前記メッセージ長フィールドの値に等しくなるまで、分割を繰り返すことを特徴とする付記１０に記載のデータ受信装置。
【００７６】
（付記１２）ＳＳＣＯＰプロトコルに基づいてデータの送受信を行うデータ送受信システムにおいて、メッセージの送信要求を格納する複数の送信用バッファと、複数の前記送信用バッファのそれぞれに格納された前記送信要求を１単位のデータに束ねる統合手段と、複数の前記送信要求が束ねられた１単位の前記データを送信する送信手段と、前記送信手段により送信された前記データを受信する受信手段と、前記受信手段により受信された前記データから複数のメッセージを取り出す分割手段と、前記分割手段により分割された複数の前記メッセージをそれぞれ格納する受信用バッファと、を備えることを特徴とするデータ送受信システム。
【００７７】
（付記１３）前記送信要求を格納している前記送信用バッファの数、前記送信要求を格納していない前記送信用バッファの数および送信ウィンドウ数のいずれかに基づいて輻輳状態の発生を判断する判定手段、をさらに備え、前記統合手段は、前記判定手段により輻輳状態の発生中であると判断されたときに、複数の前記送信要求を１単位のデータに束ねることを特徴とする付記１２に記載のデータ送受信システム。
【図面の簡単な説明】
【００７８】
【図１】実施の形態にかかるデータ送受信システムの概略を示す説明図である。
【図２】実施の形態にかかるデータ送受信システムの構成を示すブロック図である。
【図３】実施の形態にかかるフレームフォーマットを示す説明図である。
【図４】従来のフレームフォーマットを示す説明図である。
【図５】実施の形態にかかる統合処理を説明するフローチャートである。
【図６】実施の形態にかかる第１判定処理を説明するフローチャートである。
【図７】第１判定処理における輻輳発生判定を説明する説明図である。
【図８】第１判定処理における輻輳復旧判定を説明する説明図である。
【図９】実施の形態にかかる第２判定処理を説明するフローチャートである。
【図１０】第２判定処理における輻輳発生判定を説明する説明図である。
【図１１】第２判定処理における輻輳発生判定を説明する説明図である。
【図１２】実施の形態にかかる第３判定処理を説明するフローチャートである。
【図１３】第３判定処理における輻輳発生判定を説明する説明図である。
【図１４】第３判定処理における輻輳発生判定を説明する説明図である。
【図１５】実施の形態にかかる第４判定処理を説明するフローチャートである。
【図１６】実施の形態にかかる第５判定処理を説明するフローチャートである。
【図１７】第５判定処理における受信側の処理能力と閾値の関係を示す図表である。
【図１８】実施の形態にかかる分割処理を説明するフローチャートである。
【符号の説明】
【００７９】
１  データ送信装置
２  データ受信装置
３  フレームフォーマット
１４  送信用バッファ
１５  判定手段
１６  統合手段
１７  送信手段
２４  受信用バッファ
２５  受信手段
２６  分割手段
３１  情報フィールド
３５  メッセージ長フィールド
３８  識別フィールド
【図１】
2009272776.tif 000003
【図２】
2009272776.tif 000004
【図３】
2009272776.tif 000005
【図４】
2009272776.tif 000006
【図５】
2009272776.tif 000007
【図６】
2009272776.tif 000008
【図７】
2009272776.tif 000009
【図８】
2009272776.tif 000010
【図９】
2009272776.tif 000011
【図１０】
2009272776.tif 000012
【図１１】
2009272776.tif 000013
【図１２】
2009272776.tif 000014
【図１３】
2009272776.tif 000015
【図１４】
2009272776.tif 000016
【図１５】
2009272776.tif 000017
【図１６】
2009272776.tif 000018
【図１７】
2009272776.tif 000019
【図１８】
2009272776.tif 000020