(57)【要約】【課題】  通常のＴＣＰヘッダ以外のヘッダを用いることなく、通常のＴＣＰと同様の制御を行うマルチホーム対応トランスポートプロトコルを実現する。【解決手段】  本発明に係る通信端末１０は、複数のパスの各々に係るＴＣＰ制御情報を管理するパス情報管理部１２と、送信すべきデータを分割して生成したセグメントを記憶する送信セグメント管理部１１と、送信セグメント管理部１１からセグメントを抽出して受信端末３０に対して送信するセグメント送信部１３とを具備する。送信セグメント管理部１１は、ＴＣＰ制御情報に基づいて、セグメントと該セグメントの送信に用いられるパスとを関連付けて記憶することによって、該セグメントに対する送信予約を行う。セグメント送信部１３は、送信セグメント管理部１１からセグメントのみを抽出して、該セグメントに関連付けられているパスを介して該セグメントを前記受信端末に送信する。【選択図】  図１
2007043678.tif 000002
【特許請求の範囲】
【請求項１】
複数のパスを同時に用いて、データを受信端末に送信可能な通信端末であって、
前記複数のパスの各々に係るＴＣＰ制御情報を管理するように構成されているパス情報管理部と、
受信端末に対して送信すべきデータを分割して生成したセグメントを記憶するように構成されている送信セグメント管理部と、
前記送信セグメント管理部から前記セグメントを抽出して前記受信端末に対して送信するように構成されているセグメント送信部とを具備し、
前記送信セグメント管理部は、前記ＴＣＰ制御情報に基づいて、前記セグメントと該セグメントの送信に用いられるパスとを関連付けて記憶することによって、該セグメントに対する送信予約を行うように構成されており、
前記セグメント送信部は、前記送信セグメント管理部から前記セグメントのみを抽出して、該セグメントに関連付けられているパスを介して該セグメントを前記受信端末に送信するように構成されていることを特徴とする通信端末。
【請求項２】
前記セグメントに係る送達確認信号が、該セグメントの送信に用いられたパスと同一のパスを介して受信された場合、全ての送信セグメント管理部の中で、送達確認信号を受信していないセグメントの最小のシーケンス番号より小さいシーケンス番号を有するセグメントを前記送信セグメント管理部から削除するように構成されているセグメント受信部を具備することを特徴とする請求項１に記載の通信端末。
【請求項３】
前記送信セグメント管理部は、タイムアウトを検出した場合、送達確認信号を受信していない全てのセグメントに対する送信予約を取り消し、再度、前記ＴＣＰ制御情報に基づいて、該セグメントに対する送信予約を行うように構成されている請求項１又は２に記載の通信端末。
【請求項４】
前記送信セグメント管理部は、選択送達確認信号を受信した最大のセグメントと、次に送達確認信号を受信すべきセグメントとの間に、送達確認信号を受信していないセグメントが所定数以上ある場合、選択送達確認信号を受信した最大のセグメントのシーケンス番号以下のシーケンス番号で送達確認信号を受信していないセグメント、及び、未送信のセグメントに対する送信予約を取り消し、再度、前記ＴＣＰ制御情報に基づいて、該セグメントに対する送信予約を行うように構成されている請求項１又は２に記載の通信端末。
【請求項５】
前記セグメント送信部は、近隣通信端末との間でアドホックネットワークを形成し、該アドホックネットワーク内の前記パスを介して前記セグメントを送信するように構成されていることを特徴とする請求項１乃至４のいずれか一項に記載の通信端末。
【請求項６】
複数のパスを同時に用いて、送信端末からデータを受信可能な通信端末であって、
前記複数のパスの各々に係るＴＣＰ制御情報を管理するように構成されているパス情報管理部と、
前記複数のパスを介して、前記データを分割して生成されたセグメントを受信するように構成されているセグメント受信部と、
受信した前記セグメントを、該セグメントが送信されたパスごとに記憶するように構成されている受信セグメント管理部と、
前記ＴＣＰ制御情報に基づいて、各パスを介したセグメントの受信結果を通知するための送達確認信号を送信するように構成されているセグメント送信部とを具備することを特徴とする通信端末。
【請求項７】
前記送達確認信号は、前記パスを介して受信に成功したセグメントのシーケンス番号を通知するように構成されていることを特徴とする請求項６に記載の通信端末。
【請求項８】
同一のパスを介してシーケンス番号が連続する複数のセグメントが受信されている場合、前記送達確認信号は、該複数のセグメントの受信結果についてまとめて通知するように構成されていることを特徴とする請求項６に記載の通信端末。
【請求項９】
前記セグメント受信部は、近隣通信端末との間でアドホックネットワークを形成し、該アドホックネットワーク内の前記パスを介して前記セグメントを受信するように構成されていることを特徴とする請求項６乃至８のいずれか一項に記載の通信端末。
【請求項１０】
送信端末が、複数のパスを同時に用いて、データを受信端末に送信する通信方法であって、
前記送信端末が、前記複数のパスごとに管理されているＴＣＰ制御情報に基づいて、前記受信端末に対して送信すべきデータを分割して生成したセグメントと、該セグメントの送信に用いられるパスとを関連付けて送信セグメント管理部に記憶することによって、該セグメントに対する送信予約を行う工程と、
前記送信端末が、前記送信セグメント管理部から前記セグメントのみを抽出して、該セグメントに関連付けられているパスを介して該セグメントを前記受信端末に送信する工程と、
前記受信端末が、受信した前記セグメントを、該セグメントが送信されたパスごとに管理すると共に、前記複数のパスごとに管理されているＴＣＰ制御情報に基づいて、各パスを介したセグメントの受信結果を通知するための送達確認信号を送信する工程と、
前記送信端末が、前記セグメントに係る送達確認信号が、該セグメントの送信に用いられたパスと同一のパスを介して受信された場合、該セグメント及び該セグメントに関連付けられているパスを前記送信セグメント管理部から削除する工程とを有することを特徴とする通信方法。
【請求項１１】
前記送信端末及び前記受信端末が、近隣通信端末との間でアドホックネットワークを形成する工程を有し、
前記送信端末は、生成した前記セグメントを、前記アドホックネットワーク内の前記パスを介して前記受信端末に対して送信し、
前記受信端末は、前記アドホックネットワーク内の前記パスを介して前記セグメントを受信することを特徴とする請求項１０に記載の通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信端末が、複数のパスを同時に用いて、データを受信端末に送信する通信方法、及び、かかる通信方法を実現する通信端末に関する。
【背景技術】
【０００２】
従来、マルチホーム対応トランスポートプロトコル（Ｍｕｌｔｉ-Ｐａｔｈ  ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ））を用いた通信方法、すなわち、送信端末が、複数のパスを同時に用いてデータを受信端末に送信する通信方法として、非特許文献１乃至３に記載されている技術が知られている。
【非特許文献１】ＲＦＣ２９６０、「ＳＣＴＰ（Ｓｔｒｅａｍ  Ｃｏｎｔｒｏｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｐｒｏｔｏｃｏｌ）」
【非特許文献２】「Ａ  ｔｒａｎｓｐｏｒｔ  ｌａｙｅｒ  ａｐｐｒｏａｃｈ  ｆｏｒ  ｉｍｐｒｏｖｉｎｇ  ｅｎｄ-ｔｏ-ｅｎｄ  ｐｅｒｆｏｒｍａｎｃｅ  ａｎｄ  ｒｏｂｕｓｔｎｅｓｓ  ｕｓｉｎｇ  ｒｅｄｕｎｄａｎｔ  ｐａｔｈｓ．」、Ａｒｖｉｎｄ  Ｋｒｉｓｈｎａｍｕｒｔｈｙ、Ｌａｒｒｙ  Ｐｅｔｅｒｓｏｎ、Ｍｉｎｇ  Ｚｈａｎｇ、Ｊｕｎｗｅｎ  Ｌａｉ、Ｒａｎｄｏｌｐｈ  Ｗａｎｇ著、ＵＳＥＮＩＸ’  ０４、９９〜１１２頁、２００４年６月
【非特許文献３】「Ａ  ｔｒａｎｓｐｏｒｔ  ｌａｙｅｒ  ａｐｐｒｏａｃｈ  ｆｏｒ  ａｃｈｉｅｖｉｎｇ  ａｇｇｒｅｇａｔｅ  ｂａｎｄｗｉｄｔｈ  ｏｎ  ｍｕｌｔｉ-ｈｏｍｅｄ  ｍｏｂｉｌｅ  ｈｏｓｔｓ．」、Ｈｕｎｇ-Ｙｕｎ  Ｈｅｌｅｈ、Ｒａｇｈｕｐａｔｈｙ  Ｓｉｖａｋｕｍａｒ著、ＡＣＭ  Ｍｏｂｉｃｏｍ’  ０２、２００２年９月
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、非特許文献１に提案されているマルチホーム対応トランスポートプロトコルを用いた通信方法は、最も通信状態の良い１つのパスのみを用いて通信を行い、障害時の迂回経路としてその他のパスを利用するように構成されているため、複数のパスを同時に利用して通信を行うことはできないという問題点があった。
【０００４】
これに対して、非特許文献２及び３に提案されている技術は、送信端末と受信端末との間に存在する複数のパスを同時に利用して通信を行うことができる。
【０００５】
しかしながら、非特許文献２に提案されている技術では、通常のＴＣＰヘッダの上位に新たなヘッダを必要とすることから、非特許文献２に提案されているプロトコルを備えていない通信端末との間で通信を行うことができないという問題点があった。
【０００６】
この点、非特許文献３に提案されている技術では、通常のＴＣＰヘッダのみを利用して、送信端末と受信端末との間に存在する複数のパスを同時に利用して通信を行うこと（すなわち、マルチホーム接続）を実現するように構成されている。
【０００７】
しかしながら、非特許文献３に提案されている技術では、ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ：送達確認信号）を送信するためのパス（ＡＣＫパス）が１つしか利用できないため、利用しているＡＣＫパスに障害が発生すると、全てのパスにおいて影響を受けると共に、それぞれのパスが非対称となる（パケットを送信したパスとＡＣＫを受信するパスが異なる）ため、ＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）が正確に計測されないという問題点があった。
【０００８】
さらに、非特許文献３に提案されている技術では、Ｃ-ＡＣＫ（Ｃｕｍｕｌａｔｉｖｅ  ＡＣＫ）を利用することができない等の問題があり、パス単位では、通常のＴＣＰと同等の制御を行うことができないという問題点があった。
【０００９】
本発明は、以上の点に鑑みてなされたもので、本発明に係る技術を適用していない受信端末との間であっても通信を可能とするために、通常のＴＣＰヘッダ以外のヘッダを用いることなく、複数のＡＣＫパスを利用することで対称なパスを用いて正確なＲＴＴを計測すると共に、Ｃｕｍｕｌａｔｉｖｅ  ＡＣＫを改良することによって、通常のＴＣＰと同様の制御を行うことができるマルチホーム対応トランスポートプロトコルを実現する通信方法及び通信端末を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の第１の特徴は、複数のパスを同時に用いて、データを受信端末に送信可能な通信端末であって、前記複数のパスの各々に係るＴＣＰ制御情報を管理するように構成されているパス情報管理部と、受信端末に対して送信すべきデータを分割して生成したセグメントを記憶するように構成されている送信セグメント管理部と、前記送信セグメント管理部から前記セグメントを抽出して前記受信端末に対して送信するように構成されているセグメント送信部とを具備し、前記送信セグメント管理部は、前記ＴＣＰ制御情報に基づいて、前記セグメントと該セグメントの送信に用いられるパスとを関連付けて記憶することによって、該セグメントに対する送信予約を行うように構成されており、前記セグメント送信部は、前記送信セグメント管理部から前記セグメントのみを抽出して、該セグメントに関連付けられているパスを介して該セグメントを前記受信端末に送信するように構成されていることを要旨とする。
【００１１】
かかる発明によれば、セグメントの送信が、通常のＴＣＰヘッダのみを用いて行われるように構成されているため、本発明に係る技術を適用していない受信端末がとの間であっても通信を行うことができる。
【００１２】
本発明の第１の特徴において、前記セグメントに係る送達確認信号が、該セグメントの送信に用いられたパスと同一のパスを介して受信された場合、全ての送信セグメント管理部の中で、送達確認信号を受信していないセグメントの最小のシーケンス番号より小さいシーケンス番号を有するセグメントを前記送信セグメント管理部から削除するように構成されているセグメント受信部を具備してもよい。
【００１３】
本発明の第１の特徴において、前記送信セグメント管理部が、タイムアウトを検出した場合、送達確認信号を受信していない全てのセグメントに対する送信予約を取り消し、再度、前記ＴＣＰ制御情報に基づいて、該セグメントに対する送信予約を行うように構成されていてもよい。
【００１４】
本発明の第１の特徴において、前記送信セグメント管理部が、選択送達確認信号を受信した最大のセグメントと、次に送達確認信号を受信すべきセグメントとの間に、送達確認信号を受信していないセグメントが所定数以上ある場合、選択送達確認信号を受信した最大のセグメントのシーケンス番号以下のシーケンス番号で送達確認信号を受信していないセグメント、及び、未送信のセグメントに対する送信予約を取り消し、再度、前記ＴＣＰ制御情報に基づいて、該セグメントに対する送信予約を行うように構成されていてもよい。
【００１５】
本発明の第１の特徴において、前記セグメント送信部が、近隣通信端末との間でアドホックネットワークを形成し、該アドホックネットワーク内の前記パスを介して前記セグメントを送信するように構成されていてもよい。
【００１６】
かかる発明によれば、近隣通信端末との間で形成されたアドホックネットワーク内のパスを利用することによって、複数のインターフェースを持たない通信端末においても、送信端末と受信端末との間に存在する複数のパスを同時に利用して通信を行うこと（すなわち、仮想的にマルチホーム接続）を実現することができる。
【００１７】
本発明の第２の特徴は、複数のパスを同時に用いて、送信端末からデータを受信可能な通信端末であって、前記複数のパスの各々に係るＴＣＰ制御情報を管理するように構成されているパス情報管理部と、前記複数のパスを介して、前記データを分割して生成されたセグメントを受信するように構成されているセグメント受信部と、受信した前記セグメントを、該セグメントが送信されたパスごとに記憶するように構成されている受信セグメント管理部と、前記ＴＣＰ制御情報に基づいて、各パスを介したセグメントの受信結果を通知するための送達確認信号を送信するように構成されているセグメント送信部とを具備することを要旨とする。
【００１８】
本発明の第２の特徴において、前記送達確認信号が、前記パスを介して受信に成功したセグメントのシーケンス番号を通知するように構成されていてもよい。
【００１９】
かかる発明によれば、パケットを受信したパスに対してＡＣＫを送信するように構成されているため、ＲＴＴを正確に計測することができ、Ｃ-ＡＣＫを改良することによって各パスに対して通常のＴＣＰ制御と同等の制御を行うことができる。
【００２０】
本発明の第２の特徴において、同一のパスを介してシーケンス番号が連続する複数のセグメントが受信されている場合、前記送達確認信号が、該複数のセグメントの受信結果についてまとめて通知するように構成されていてもよい。
【００２１】
かかる発明によれば、複数のＡＣＫ（送達確認信号）を送信することができるので（例えば、Ｃ-ＡＣＫを利用することができるので）、送信するＡＣＫの数を削減することができる。
【００２２】
本発明の第２の特徴において、前記セグメント受信部が、近隣通信端末との間でアドホックネットワークを形成し、該アドホックネットワーク内の前記パスを介して前記セグメントを受信するように構成されていてもよい。
【００２３】
本発明の第３の特徴は、送信端末が、複数のパスを同時に用いて、データを受信端末に送信する通信方法であって、前記送信端末が、前記複数のパスごとに管理されているＴＣＰ制御情報に基づいて、前記受信端末に対して送信すべきデータを分割して生成したセグメントと、該セグメントの送信に用いられるパスとを関連付けて送信セグメント管理部に記憶することによって、該セグメントに対する送信予約を行う工程と、前記送信端末が、前記送信セグメント管理部から前記セグメントのみを抽出して、該セグメントに関連付けられているパスを介して該セグメントを前記受信端末に送信する工程と、前記受信端末が、受信した前記セグメントを、該セグメントが送信されたパスごとに管理すると共に、前記複数のパスごとに管理されているＴＣＰ制御情報に基づいて、各パスを介したセグメントの受信結果を通知するための送達確認信号を送信する工程と、前記送信端末が、前記セグメントに係る送達確認信号が、該セグメントの送信に用いられたパスと同一のパスを介して受信された場合、該セグメント及び該セグメントに関連付けられているパスを前記送信セグメント管理部から削除する工程とを有することを要旨とする。
【００２４】
本発明の第３の特徴において、前記送信端末及び前記受信端末が、近隣通信端末との間でアドホックネットワークを形成する工程を有し、前記送信端末は、生成した前記セグメントを、前記アドホックネットワーク内の前記パスを介して前記受信端末に対して送信し、前記受信端末は、前記アドホックネットワーク内の前記パスを介して前記セグメントを受信してもよい。
【発明の効果】
【００２５】
以上説明したように、本発明によれば、通常のＴＣＰヘッダ以外のヘッダを用いることなく、通常のＴＣＰと同様の制御を行うことができるマルチホーム対応トランスポートプロトコルを実現する通信方法及び通信端末を提供することができる。
【発明を実施するための最良の形態】
【００２６】
（本発明の第１の実施形態に係る通信端末の構成）
図１に、本発明の第１の実施形態に係る通信端末（送信端末１０及び受信端末３０）を具備する通信システムの一例を示す。図１に示すように、本実施形態では、３つのパス＃１乃至＃３を同時に用いて、送信端末１０から受信端末３０に対して、データを送信する環境を想定している。
【００２７】
かかるデータとして、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＰＯＰ３（Ｐｏｓｔ  Ｏｆｆｉｃｅ  Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  ３）等のアプリケーションデータが想定される。
【００２８】
また、かかるデータは、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）等のデータベース言語で適用可能であり、ＮＦＳ（Ｎｅｔｗｏｒｋ  Ｆｉｌｅ  Ｓｙｓｔｅｍ）等のネットワーク越しのファイルアクセスで適用可能であり、ＳＳＨ（Ｓｅｃｕｒｅ  ＳＨｅｌｌ）やＳＳＬ（Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔ  Ｌａｙｅｒ）やＥｔｈｅｒｎｅｔ（登録商標）  ｏｖｅｒ  ＴＣＰ/ＩＰ等のＶＰＮ（Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ）等、ＴＣＰを用いたあらゆる通信に適用可能である。
【００２９】
図１に示すように、本実施形態に係る受信端末３０は、ＷＡＮ（Ｗｉｒｅｌｅｓｓ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）における３Ｇ対応のインターフェースと、ＷＬＡＮ（Ｗｉｒｅｌｅｓｓ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）におけるＩＥＥＥ８０２.１１ｂ対応のインターフェースと、ＷＰＡＮ（Ｗｉｒｅｌｅｓｓ  Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）におけるＢｌｕｅｔｏｏｔｈ（登録商標）対応のインターフェース等といった複数の無線インターフェースを具備する（マルチホーム接続に対応可能な）ように構成されている。
【００３０】
そして、本実施形態に係る受信端末３０は、複数のインターフェースによって確立される複数のパス＃１乃至＃３を同時に用いて、送信端末１０から送信されるデータを受信するように構成されている。
【００３１】
一方、図１の例では、本実施形態に係る送信端末１０は、有線インターフェースを具備するだけで、複数の無線インターフェースを具備していない。
【００３２】
しかしながら、通常のＴＣＰにおいて、パス（一般的なＴＣＰコネクション）は、［（送信者のＩＰアドレス，ポート番号），（受信者のＩＰアドレス，ポート番号）］の４つのアドレスによって判別される。
【００３３】
したがって、本実施形態に係る送信端末１０も、複数のパス＃１乃至＃３を同時に用いて、受信端末３０に対してデータ（を構成するセグメント）を送信する必要がある以上、上述のパス＃１乃至＃３を判別できる（マルチホーム接続に対応可能な）ように構成されている。
【００３４】
図２に示すように、本実施形態に係る送信端末１０は、アプリケーション機能部１０ａと、送信セグメント管理部１１と、パス情報管理部１２と、セグメント送信部１３と、セグメント受信部１４とを具備している。
【００３５】
アプリケーション機能部１０ａは、送信セグメント管理部１１に対して、アプリケーションで用いられるデータを送信するように指示するものである。
【００３６】
ここで、アプリケーション機能部１０ａは、データを送信するパスとして、複数のパスの組を明示的に指定することができるように構成されていてもよい。
【００３７】
また、アプリケーション機能部１０ａは、データを送信するパスとして、代表パスを指定し、他のパスは、自動的に追加させるように構成されていてもよい。
【００３８】
送信セグメント管理部１１は、受信端末３０に対して送信すべきデータを分割して生成したセグメントを記憶する送信バッファによって構成されている。
【００３９】
また、送信セグメント管理部１１は、パスごとに「ＴＣＰ-ＣＢ：ＴＣＰ  Ｃｏｎｔｒｏｌ  Ｂｌｏｃｋ」によって管理されているＴＣＰ制御情報に基づいて、生成されたセグメントと、当該セグメントの送信に用いられるパス（変数「ｐａｔｈ」）とを関連付けて記憶することによって、当該セグメントに対する送信予約を行うように構成されている。
【００４０】
具体的には、送信セグメント管理部１１は、図３に示すように、アプリケーション機能部１０ａから渡された受信端末３０に送信すべきデータをＰＤＵ（Ｐｒｏｔｏｃｏｌ  ＤａｔａＵｎｉｔ）単位に分割し、分割された各データに対して、通常のＴＣＰヘッダを付与してセグメントを形成する。ここで、ＴＣＰヘッダは、通常のＴＣＰで用いられるＴＣＰヘッダであるものとする。
【００４１】
また、送信セグメント管理部１１は、形成された当該セグメントに対して、当該セグメントを管理するための特別のヘッダを付与して管理するように構成されている。
【００４２】
かかる特別のヘッダは、図３に示すように、「ｐａｔｈ」、「ｓａｃｋ」、「ｐ＿ｓｅｑ」、「ｎｅｘｔ」等といった変数や、「ｒｓｖ」フラグ等といったフラグを含むように構成されている。
【００４３】
ここで、変数「ｐ＿ｓｅｑ」は、パスごとに割り振られたセグメントのシーケンス番号を示す。
【００４４】
なお、ＴＣＰでは、シーケンス番号を、「バイトオーダー」で表現するのが一般的であるが、本明細書では、簡略化のため「シーケンスオーダー」で表現するものとする。
【００４５】
また、変数「ｐａｔｈ」は、当該セグメントの送信に用いられるパスの識別情報を示し、変数「ｓａｃｋ」は、当該セグメントに対するＡＣＫの受信に用いられたパスの識別情報を示す。また、変数「ｎｅｘｔ」は、当該セグメントの次に参照すべきセグメントを示す。
【００４６】
「ｒｓｖ」フラグは、当該セグメントに対する送信予約が行われている状態を示すフラグである（かかる状態である場合「１」）。
【００４７】
さらに、送信セグメント管理部１１は、次に予約すべきデータ開始位置を示す「ｒｓｖ＿ｎｘｔ」という変数を管理している。
【００４８】
また、送信セグメント管理部１１は、タイムアウトを検出した場合、ＡＣＫ（送達確認信号）を受信していない全てのセグメントに対する送信予約を取り消し、再度、ＴＣＰ-ＣＢ（ＴＣＰ制御情報）に基づいて、当該セグメントに対する送信予約を行うように構成されている。
【００４９】
また、送信セグメント管理部１１は、ＳＡＣＫブロック（選択送達確認信号）を受信した最大のセグメント（「ｍａｘ＿ｓａｃｋ」）と、次にＡＣＫ（送達確認信号）を受信すべきセグメント（「ｒｃｖ＿ｎｘｔ」）との間に、ＡＣＫ（送達確認信号）を受信していないセグメントが所定数（例えば、３つ）以上ある場合、ＳＡＣＫブロック（選択送達確認信号）を受信した最大のセグメントのシーケンス番号以下のシーケンス番号でＡＣＫ（送達確認信号）を受信していないセグメント、及び、未送信のセグメントに対する送信予約を取り消し、再度、ＴＣＰ-ＣＢ（ＴＣＰ制御情報）に基づいて、当該セグメントに対する送信予約を行うように構成されている。
【００５０】
パス情報管理部１２は、複数のパス情報管理部＃１乃至＃３によって、複数のパス＃１乃至＃３の各々に係るＴＣＰ-ＣＢ（ＴＣＰ制御情報）を管理するように構成されている。なお、各パスは、［（送信者のＩＰアドレス，ポート番号），（受信者のＩＰアドレス，ポート番号）］の４つのアドレスによって判別される。
【００５１】
具体的には、各パス情報管理部＃ｎは、図４に示すように、「ｒｔｔ」、「ｔ＿ｔｉｍｅｒ」、「ｔ＿ｓｅｑ」、「ｃｗｎｄ」、「ｓｓｔｈｒｅｓｈ」、「ｒｃｖ＿ｎｘｔ」、「ｓｎｄ＿ｎｘｔ」、「ｒｓｖ＿ｎｕｍ」、「ｓｎｄ＿ｎｕｍ」、「ｍａｘ＿ｓａｃｋ」等といった変数を含むＴＣＰ-ＣＢ（ｎ）を管理するように構成されている。
【００５２】
なお、かかるＴＣＰ-ＣＢ（ｎ）には、さらに「ｔ＿ｓｔａｔｅ」や「ｔ＿ｆｌａｇｓ」等といったＴＣＰコネクションを維持するための様々な情報が確保されていてもよい。
【００５３】
ここで、「ｒｔｔ」は、計測されたラウンドトリップタイムであり、「ｔ＿ｔｉｍｅｒ」は、「ｒｔｔ」を元に計算されたタイムアウト値であり、「ｔ＿ｓｅｑ」は、「ｒｔｔ」の計測に用いられるセグメントのシーケンス番号であり、「ｃｗｎｄ」は、輻輳ウィンドウであり、「ｓｓｔｈｒｅｓｈ」は、「Ｓｌｏｗ  Ｓｔａｒｔ  Ｔｈｒｅｓｈｏｌｄ」であり、「ｒｃｖ＿ｎｘｔ」は、次に受信を期待するセグメントのシーケンス番号であり、「ｓｎｄ＿ｎｘｔ」は、次に送信するセグメントのシーケンス番号であり、「ｒｓｖ＿ｎｕｍ」は、予約済みのデータ量であり、「ｓｎｄ＿ｎｕｍ」は、送信済みのデータ量であり、「ｍａｘ＿ｓａｃｋ」は、当該パスで送信されたセグメントにおいて、ＡＣＫ又はＳＡＣＫオプションによって通知された最大のシーケンス番号である。
【００５４】
セグメント送信部１３は、送信セグメント管理部１１からセグメントを抽出して、当該セグメントに関連付けられているパスを介して当該セグメントを受信端末３０に対して送信するように構成されている。
【００５５】
また、セグメント送信部１３は、特定のセグメントのロストが検出された場合、当該セグメントについて再送信を行うように構成されている。
【００５６】
セグメント受信部１４は、セグメントに係るＡＣＫ（送達確認信号）が、当該セグメントの送信に用いられたパスと同一のパスを介して受信された場合、全ての送信セグメント管理部１１の中で、ＡＣＫ（送達確認信号）を受信していないセグメントの最小のシーケンス番号より小さいシーケンス番号を有するセグメントを送信セグメント管理部１１から削除するように構成されている。
【００５７】
図５に示すように、本実施形態に係る受信端末３０は、アプリケーション機能部３０ａと、セグメント受信部３１と、パス情報管理部３２と、受信セグメント管理部３３と、セグメント送信部３４とを具備している。
【００５８】
セグメント受信部３１は、送信端末１０から複数のパス＃１乃至＃３を介してセグメントを受信し、受信したセグメントのそれぞれを［（送信者のＩＰアドレス，ポート番号），（受信者のＩＰアドレス，ポート番号）］の４つのアドレスに基づいて、特定のパス情報管理部＃１乃至＃３に送信するように構成されている。
【００５９】
パス情報管理部３２は、複数のパス情報管理部＃１乃至＃３によって、複数のパス＃１乃至＃３の各々に係るＴＣＰ-ＣＢ（ＴＣＰ制御情報）を管理するように構成されている。なお、各パスは、［（送信者のＩＰアドレス，ポート番号），（受信者のＩＰアドレス，ポート番号）］の４つのアドレスによって判別される。
【００６０】
具体的には、各パス情報管理部＃ｎは、図６に示すように、「ｄｅｌ＿ｔｉｍｅｒ」、「ｄｅｌ＿ａｃｋ」、「ｒｃｖ＿ｎｘｔ」、「ｐ＿ｓａｃｋ１」、「ｐ＿ｓａｃｋ２」、「ｐ＿ｓａｃｋ３」等といった変数を含むＴＣＰ-ＣＢ（ｎ）を管理するように構成されている。
【００６１】
なお、かかるＴＣＰ-ＣＢ（ｎ）には、さらに、ＴＣＰコネクションを維持するための様々な情報が確保されていてもよい。
【００６２】
ここで、「ｄｅｌ＿ｔｉｍｅｒ」は、ＡＣＫの送信を遅らせるためのタイマであり、「ｄｅｌ＿ａｃｋ」は、「ｄｅｌ＿ｔｉｍｅｒ」満了時のＡＣＫに用いられるシーケンス番号であり、「ｒｃｖ＿ｎｘｔ」は、次に受信を期待するセグメントのシーケンス番号であり、「ｐ＿ｓａｃｋｎ」は、ｎ番目のブロックに記入するシーケンス番号である。
【００６３】
受信セグメント管理部３３は、受信したセグメントを、当該セグメントが送信されたパスごとに管理するように構成されている。
【００６４】
具体的には、受信セグメント管理部３３は、図７に示すように、パス情報管理部１２から送信された各セグメントに対して、当該セグメントを管理するための特別のヘッダを付与して管理するように構成されている受信バッファである。
【００６５】
かかる特別のヘッダは、図７に示すように、「ｐａｔｈ」等といった変数を含むように構成されている。
【００６６】
ここで、変数「ｐａｔｈ」は、当該セグメントの送信に用いられるパスの識別情報を示す。
【００６７】
さらに、受信セグメント管理部３３は、最初に受信したセグメントが記憶されている開始位置を示す「ｒｃｖ＿ｂｕｆ＿ｆｉｒｓｔ」という変数を管理している。
【００６８】
なお、受信セグメント管理部３３は、変数「ｒｃｖ＿ｂｕｆ＿ｆｉｒｓｔ」によって示されるセグメントから、アプリケーション機能部３０ａに送信するように構成されている。
【００６９】
セグメント送信部３４は、パスごとに管理されているＴＣＰ-ＣＢ（ＴＣＰ制御情報）に基づいて、各パスを介したセグメントの受信結果を通知するためのＡＣＫ（送達確認信号）を送信するように構成されている。
【００７０】
なお、かかるＡＣＫには、後述するように、ＲＦＣ２０１８で定義されているＳＡＣＫ（Ｓｅｌｅｃｔｉｖｅ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）オプションが付与されている。
【００７１】
ここで、ＡＣＫに付与されたＳＡＣＫオプションは、各パスを介して受信に成功したセグメントのシーケンス番号を通知するように構成されている。
【００７２】
また、セグメント送信部３４は、同一のパス内でシーケンス番号が連続する複数のセグメントが受信されている場合、当該複数のセグメントの受信結果についてまとめて通知する送達確認信号（Ｃ-ＡＣＫ）を送信するように構成されていてもよい。
【００７３】
（本発明の第１の実施形態に係る通信端末の動作）
以下、図８乃至図１５を参照して、本発明の第１の実施形態に係る通信端末の動作について説明する。
【００７４】
第１に、図８及び図９を参照して、本実施形態に係る送信端末１０が、複数のパス＃１乃至＃３を同時に用いて、データを受信端末３０に送信する動作について説明する。
【００７５】
図８に示すように、ステップＳ１０１において、送信端末１０の送信セグメント管理部１１は、アプリケーション機能部１０ａから渡されたデータをＭＴＵ単位に分割する。
【００７６】
ステップＳ１０２において、送信セグメント管理部１１は、ＭＴＵ単位に分割されたそれぞれのデータにＴＣＰヘッダを付与してセグメントを形成して、上述の特別のヘッダ（図３参照）を付与して管理する。
【００７７】
ここで、送信セグメント管理部１１は、各変数及びフラグに、初期値として「０」を設定する。
【００７８】
ステップＳ１０３において、送信セグメント管理部１１は、パス情報管理部１２によって管理されている全てのパスに係るＴＣＰ-ＣＢ内の変数「ｒｓｖ＿ｎｕｍ」を監視しており、変数「ｒｓｖ＿ｎｕｍ」が、変数「ｍａｘ＿ｂｕｒｓｔ」を下回っている場合、先頭のデータ（変数「ｒｓｖ＿ｎｘｔ」によって示されるデータ）に対して送信予約を行う。
【００７９】
ここで、変数「ｍａｘ＿ｂｕｒｓｔ」は、ＡＣＫ受信時に一度に送信することのできる最大のセグメントのデータ量（セグメント数）を示す。なお、変数「ｍａｘ＿ｂｕｒｓｔ」は、全てのパス（インターフェース）で共通の変数である。
【００８０】
そして、送信セグメント管理部１１は、送信セグメント管理部１１の先頭データ（「変数「ｒｓｖ＿ｎｘｔ」によって示されるデータ」から、「ｒｓｖ」フラグが設定されていないセグメントに対して送信予約を行い、パス情報管理部１２は、送信予約を行ったセグメントのデータ量を、当該セグメントの送信に用いるパスに対応するＴＣＰ-ＣＢにおける変数「ｒｓｖ＿ｎｕｍ」に追加する。
【００８１】
なお、予約されたセグメントは、変数「ｎｅｘｔ」によって結ばれており、各セグメントに付与された特別なヘッダ内の変数「ｎｅｘｔ」を辿ることによって、次に予約されているセグメントを辿ることができる。
【００８２】
ここで、変数「ｒｓｖ＿ｎｕｍ」に既に値が設定されていた場合は、送信セグメント管理部１１は、「ｃｗｎｄ」−「ｒｓｖ＿ｎｕｍ」に該当する分のセグメントに対してのみ送信予約を行う。
【００８３】
つまり、送信セグメント管理部１１は、変数「ｒｓｖ＿ｎｕｍ」＝変数「ｃｗｎｄ」となるように、セグメントに対する送信予約を行うように構成されている。
【００８４】
ただし、ＡＣＫ内の広告ウィンドウ値が、全てのパス情報管理部＃ｎによって管理される変数「ｃｗｎｄ」の合計（Σｃｗｎｄ）よりも小さい場合は、送信セグメント管理部１１は、変数「ｒｓｖ＿ｎｕｍ」が、「ＡＣＫ内の広告ウィンドウ値×ｃｗｎｄ／Σｃｗｎｄ」を超えないようにする。
【００８５】
送信セグメント管理部１１は、かかる送信予約が完了した場合、上述の特別のヘッダにおける「ｒｓｖ」フラグに「１」を設定し、送信予約を行ったパスの識別情報を上述のヘッダにおける変数「ｐａｔｈ」に設定する。
【００８６】
ここで、パス情報管理部１２は、変数「ｓｎｄ＿ｎｘｔ」に設定されている位置よりも前に位置するセグメントについて送信予約が行われた場合、変数「ｓｎｄ＿ｎｘｔ」に、送信予約を行ったセグメントの次のセグメントの開始位置を設定する。
【００８７】
パス情報管理部１２は、変数「ｒｃｖ＿ｎｘｔ」が変数「ｓｎｄ＿ｎｘｔ」を下回った場合、同様に、変数「ｒｃｖ＿ｎｘｔ」に「ｓｎｄ＿ｎｘｔ」に設定されている値を設定する。
【００８８】
ステップＳ１０４において、セグメント送信部１３は、複数のパス＃１乃至＃３を同時に用いて、送信予約が行われているセグメントを、順次、受信端末３０に送信する。
【００８９】
なお、セグメント送信部１３は、「ｃｗｎｄ」−「ｓｎｄ＿ｎｕｍ」＞０の場合は、変数「ｓｎｄ＿ｎｘｔ」によって示されるセグメントから順に送信を行う。
【００９０】
ここで、変数「ｓｎｄ＿ｎｕｍ」は、該当パスにおいて送信済みでＡＣＫを受け取っていないセグメント数である。
【００９１】
また、セグメント送信部１３が、特定のパスを介してセグメントを送信した場合、パス情報管理部１２は、当該特定のパスに係るＴＣＰ-ＣＢにおける変数「ｒｓｖ＿ｎｕｍ」から送信したセグメントのデータ量を減じて、当該特定のパスに係るＴＣＰ-ＣＢにおける変数「ｓｎｄ＿ｎｕｍ」へ送信したセグメントのデータ量を追加する。
【００９２】
セグメント送信部１３が、セグメントを送信する毎に、パス情報管理部１２は、変数「ｎｅｘｔ」を辿り、次のセグメントの開始位置を、変数「ｓｎｄ＿ｎｘｔ」に設定する。
【００９３】
なお、セグメント送信部１３が、セグメントを送信する際に、変数「ｔ_ｔｉｍｅｒ」が設定されていない場合には、パス情報管理部１２は、変数「ｔ_ｔｉｍｅｒ」に、変数「ｒｔｔ」等から計算される新たタイムアウト値を設定し、変数「ｔ_ｓｅｑ」に、送信されたセグメントのシーケンス番号（ｓｅｑ）を設定する。
【００９４】
図９に、送信端末１０が、パス＃１を介してセグメント＃４を送信した場合における上述の特別のヘッダ及びＴＣＰ-ＣＢの一例を示す。
【００９５】
かかる場合、送信セグメント管理部１１においてセグメント＃４に付与されている特別のヘッダでは、変数「ｐａｔｈ」＝１、変数「ｓａｃｋ」＝０、「ｒｓｖ」フラグ＝０、変数「ｎｅｘｔ」＝０と設定されている。
【００９６】
また、パス＃１に係るＴＣＰ-ＣＢ（１）では、変数「ｒｃｖ＿ｎｘｔ」＝１、変数「ｓｎｄ＿ｎｘｔ」＝４、変数「ｒｓｖ＿ｎｕｍ」＝１、変数「ｓｎｄ＿ｎｕｍ」＝１と設定されている。
【００９７】
第２に、図１０及び図１１を参照して、本実施形態に係る送信端末１０が、ＡＣＫを受信する動作について説明する。
【００９８】
図１０に示すように、ステップＳ３０１において、送信端末１０のセグメント受信部１４は、受信端末３０から送信されたＡＣＫを受信して、当該ＡＣＫを受信したパスの［（送信者のＩＰアドレス，ポート番号），（受信者のＩＰアドレス，ポート番号）］の４つのアドレスに基づいて、当該ＡＣＫを適切なパス情報管理部＃ｎに転送する。
【００９９】
図１１の例では、送信端末１０のセグメント受信部１４は、受信端末３０から受信したＡＣＫ（Ａ）又は（Ｂ）を、当該ＡＣＫ（Ａ）又は（Ｂ）を受信したパス＃１を管理するパス情報管理部＃１に転送する。
【０１００】
ここで、図１１に示すＡＣＫ（Ａ）は、未だ受信していないセグメントのうち最もシーケンス番号が小さいセグメントは「セグメント＃１」であることを通知するものである。
【０１０１】
また、図１１に示すＡＣＫ（Ｂ）は、未だ受信していないセグメントのうち最もシーケンス番号が小さいセグメントは「セグメント＃２」であることを通知し、また、ＳＡＣＫオプションによって、セグメント＃７の受信に成功したことを通知するものである。
【０１０２】
なお、ＡＣＫは、１つのＳＡＣＫオプションによって、複数のセグメントの受信に成功したことを通知するように構成されていてもよい。
【０１０３】
ステップＳ３０２において，パス情報管理部＃ｎは、受信したＡＣＫ及びＳＡＣＫオプションによって受信側への到着が報告されたセグメントについては、特別のヘッダにおける変数「ｓａｃｋ」に、当該パス情報管理部＃ｎによって管理されているパスの識別情報を設定するように、送信セグメント管理部１１に指示する。
【０１０４】
なお、変数「ｓａｃｋ」に設定されているパスの識別情報と変数「ｐａｔｈ」に設定されているパスの識別情報とが一致した場合、他のＡＣＫを受信した際に、変数「ｓａｃｋ」を上書きしない。
【０１０５】
図１１の例では、パス情報管理部＃１は、ＡＣＫ（Ａ）によって受信が成功したことを通知されたセグメント＃１に付与されている特別のヘッダにおける変数「ｓａｃｋ」に、パス＃１の識別情報を設定するように、送信セグメント管理部１１に指示する。
【０１０６】
また、図１１の例では、パス情報管理部＃１は、ＡＣＫ（Ｂ）のＳＡＣＫオプションによって受信が成功したことを通知されたセグメント＃７に付与されている特別のヘッダにおける変数「ｓａｃｋ」に、パス＃１の識別情報を設定するように、送信セグメント管理部１１に指示する。
【０１０７】
ステップＳ３０３において、パス情報管理部＃ｎは、当該ＴＣＰ-ＣＢ（ｎ）における変数「ｒｃｖ＿ｎｘｔ」と、ＡＣＫ又はＳＡＣＫオプションによって通知されているセグメントのシーケンス番号（ｓｅｑ）とを比較する。
【０１０８】
変数「ｒｃｖ＿ｎｘｔ」が、当該ｓｅｑ（ＡＣＫ）よりも小さい場合、或いは、 ＳＡＣＫブロックによって、変数「ｒｃｖ＿ｎｘｔ」に該当するセグメントの受信が通知されなかった場合、本動作はステップＳ３０４に進む。それ以外の場合は、本動作はステップＳ３０５に進む。
【０１０９】
図１１の例では、ＴＣＰ-ＣＢ（ｎ）における変数「ｒｃｖ＿ｎｘｔ」には、「セグメント＃１のシーケンス番号」が設定されているので、パス情報管理部＃１が、ＡＣＫ（Ａ）を受信した場合、本動作はステップＳ３０５に進む。
【０１１０】
ステップＳ３０５において、パス情報管理部＃ｎは、当該ＴＣＰ-ＣＢ（ｎ）における変数「ｒｃｖ＿ｎｘｔ」によって指定されるセグメントに係る特別のヘッダ内の変数「ｓａｃｋ」が変数「ｐａｔｈ」と一致するか否かの判断を行う。
【０１１１】
ステップＳ３０５において、当該ＴＣＰ-ＣＢ（ｎ）における変数「ｒｃｖ＿ｎｘｔ」によって指定されるセグメントに係る特別のヘッダ内の変数「ｓａｃｋ」が変数「ｐａｔｈ」と一致する場合、ステップＳ３０６において、変数「ｒｃｖ＿ｎｘｔ」に設定するセグメントを、当該ＴＣＰ-ＣＢ（ｎ）における変数「ｎｅｘｔ」に従って次に移動する。
【０１１２】
図１１の場合、ＡＣＫ（Ａ）の受信によって、変数「ｒｃｖ＿ｎｘｔ」には、セグメント＃４が設定される（セグメント＃１に付与された特別のヘッダ内の変数「ｎｅｘｔ」は、パス＃１で次に送信されるセグメントを指すため）。この処理は、変数「ｓａｃｋ」が、変数「ｐａｔｈ」に一致しないセグメントが見つけられるまで続けられる。
【０１１３】
一方、ステップＳ３０５で、変数「ｓａｃｋ」が、変数「ｐａｔｈ」に一致しないセグメントが見つかった場合、ステップＳ３０７において、変数「ｒｃｖ＿ｎｘｔ」が更新されたか否かの判断を行う。
【０１１４】
変数「ｒｃｖ＿ｎｘｔ」が更新されていた場合、ステップＳ３０８において、変数「ｔ＿ｔｉｍｅｒ」をキャンセルし、ステップＳ３０９において、全てのパス情報管理部において、最小の変数「ｒｃｖ＿ｎｘｔ」までのセグメントを送信セグメント管理部１１から削除する。
【０１１５】
ステップＳ３０８は、ステップＳ３０７の次に、ステップＳ３０８ａで、変数「ｒｃｖ＿ｎｘｔ」に相当するセグメントの変数「ｐ＿ｓｅｑ」がパス情報管理部１２が管理する変数「ｔ＿ｓｅｑ」に相当するセグメントの変数「ｐ＿ｓｅｑ」を上回っていた場合キャンセルされる。
【０１１６】
一方、ステップＳ３０９は、ステップＳ３０８の有無に関わらず、ステップＳ３０８の後に必ず実行される。
【０１１７】
一方、ＡＣＫ（Ｂ）を受信した場合、図１１の例では、ＴＣＰ−ＣＢ（ｎ）における変数「ｒｃｖ＿ｎｘｔ」は、セグメント＃４（ＡＣＫ（Ａ）の受信によって、変数「ｒｃｖ＿ｎｘｔ」は更新されている。ＳＡＣＫオプションの１ｓｔブロックは、セグメント＃７を通知しているが、変数「ｒｃｖ＿ｎｘｔ」に設定されているセグメント＃４を含んでいないため、本動作はステップＳ３０４へ移動する。）であり、ＡＣＫ又はＳＡＣＫオプションによって受信側への到着が報告されていないため、本動作はステップＳ３０４へ移動する。
【０１１８】
ステップＳ３０４では、当該パスで送信したセグメントについて、変数「ｓａｃｋ」に設定されているパスの識別情報と変数「ｐａｔｈ」に設定されているパスの識別情報とが一致するセグメントの最大のシーケンス番号を、当該ＴＣＰ-ＣＢ（ｎ）における変数「ｍａｘ＿ｓａｃｋ」に設定する。
【０１１９】
図１１の例では、ＡＣＫ（Ｂ）を受け取った場合、当該ＴＣＰ-ＣＢ（ｎ）における変数「ｍａｘ＿ｓａｃｋ」には、セグメント＃７が設定される。
【０１２０】
次に、ステップＳ３１０において、変数「ｍａｘ＿ｓａｃｋ」と変数「ｒｃｖ＿ｎｘｔ」との間に、変数「ｓａｃｋ」が設定されていないセグメントが、いくつあるか数える。かかる計算は、変数「ｒｃｖ＿ｎｘｔ」と変数「ｍａｘ＿ｓａｃｋ」と変数「ｐ＿ｓｅｑ」を参照することで容易に行うことができる。
【０１２１】
かかるセグメントが３つ以上あった場合は、ステップＳ３１１において、変数「ｍａｘ＿ｓａｃｋ」以下で、当該パスから送信したセグメントのうち、変数「ｓａｃｋ」が設定されていないセグメント、及び、変数「ｓｎｄ＿ｎｘｔ」以上で、当該パスに予約されているセグメントの「ｒｓｖ」フラグを消去して、再送モードへ移行する（変数「ｓｎｄ＿ｎｘｔ」以上で予約済みのセグメントとは、送信予約が行われているが未だ送信されていないセグメントのことである。)
図１１の例の場合、セグメント＃４、＃５、＃６のセグメントの「ｒｓｖ」フラグが消去される。
【０１２２】
同時に、ステップＳ３１２において、当該初期化結果に基づいて、ＴＣＰ-ＣＢ（ｎ）において、変数「ｒｓｖ＿ｎｕｍ」、変数「ｓｎｄ＿ｎｕｍ」、変数「ｓｎｄ＿ｎｘｔ」を更新する。
【０１２３】
なお、ＡＣＫ受信によってではなく、変数「ｔ＿ｔｉｍｅｒ」の満了によっても再送モードに移行する。この場合の動作は、ステップＳ３１１から始まる。但し、ステップＳ３１１では、変数「ｍａｘ＿ｓａｃｋ」以下であったところが、変数「ｔ＿ｔｉｍｅｒ」の満了は、変数「ｓｎｄ＿ｎｘｔ」以下となる。
【０１２４】
第３に、図１１及び図１２を参照して、本実施形態に係る送信端末１０の「再送モード」における動作について説明する。
【０１２５】
図１２に示すように、ステップＳ４０１において、送信端末１０において、「再送モード」が起動される。この際、パス情報管理部＃ｎは、ＴＣＰ-ＣＢ（ｎ）において、変数「ｃｗｎｄ」の半分の値を、変数「ｓｓｔｈｒｅｓｈ」に設定するとともに、変数「ｃｗｎｄ」に「１」を設定する。
【０１２６】
なお、パス情報管理部＃ｎは、無線種別を考慮して、当該変数「ｃｗｎｄ」及び当該変数「ｓｓｔｈｒｅｓｈ」を設定するように構成されていてもよい。
【０１２７】
ステップＳ４０３において、送信セグメント管理部１１は、各パス情報管理部＃ｎによって管理されているＴＣＰ-ＣＢ（ＴＣＰ制御情報）に基づいて、再度、当該セグメントに対する送信予約を行う。
【０１２８】
ここで、複数のパスを利用している場合は、変数「ｐａｔｈ」に示されているパスの識別情報と異なるパスで送信予約を行う（変数「ｐａｔｈ」で示されているパスによってセグメントがロストしているので、再度そのパスを利用すると、再度ロストする可能性が高いので、セグメントの再送時には新たなパスを利用する）。
【０１２９】
ここで、送信セグメント管理部１１は、送信予約を行ったセグメントに付与されている特別のヘッダにおいて、変数「ｐａｔｈ」及び「ｒｓｖ」フラグを設定し、パス情報管理部＃ｎ、ＴＣＰ-ＣＢ（ｎ）における変数「ｒｓｖ＿ｎｕｍ」を更新する。
【０１３０】
ステップＳ４０４において、セグメント送信部１３は、上述のステップＳ１０４の動作と同様に、複数のパス＃１乃至＃３を同時に用いて、送信予約が行われているセグメントを、順次、受信端末３０に送信する。
【０１３１】
ここで、セグメント送信部１３が、特定のパスを介してセグメントを送信した場合、送信セグメント管理部１１は、当該セグメントに係る特別のヘッダにおける「ｓｎｄ」フラグに「１」を設定し、パス情報管理部１２は、当該特定のパスに係るＴＣＰ-ＣＢにおける変数「ｒｓｖ＿ｎｕｍ」から送信したセグメントのデータ量を減じて、当該特定のパスに係るＴＣＰ-ＣＢにおける変数「ｓｎｄ＿ｎｕｍ」へ送信したセグメントのデータ量を追加する。
【０１３２】
セグメント送信部１３が、セグメントを送信する毎に、パス情報管理部１２は、当該セグメントより後ろに位置するセグメントの中から選択された「ｒｓｖ」フラグに「１」が設定されている特別のヘッダを有するセグメントの開始位置を、変数「ｓｎｄ＿ｎｘｔ」に設定する。
【０１３３】
なお、セグメント送信部１３が、セグメントを送信する際に、変数「ｔ_ｔｉｍｅｒ」が設定されていない場合には、パス情報管理部１２は、変数「ｔ_ｔｉｍｅｒ」に、変数「ｒｔｔ」等から計算される新たタイムアウト値を設定し、変数「ｔ_ｓｅｑ」に、送信されたセグメントのシーケンス番号（ｓｅｑ）を設定する。
【０１３４】
第４に、図１３乃至図１５を参照して、本実施形態に係る受信端末３０が、送信端末１０によって送信されたセグメントを受信する動作について説明する。
【０１３５】
図１３に示すように、ステップＳ５０１において、受信端末３０のセグメント受信部３１は、受信したセグメントを、当該セグメントを受信したパスの［（送信者のＩＰアドレス，ポート番号），（受信者のＩＰアドレス，ポート番号）］の４つのアドレスに基づいて、適切なパス情報管理部＃ｎに転送する。
【０１３６】
ここで、受信セグメント管理部３３は、パス情報管理部＃ｎから転送されたセグメントに特別のヘッダを付与して管理する。なお、受信セグメント管理部３３は、受信したセグメントのシーケンス番号順に、当該セグメントを管理するように構成されていてもよい。
【０１３７】
ここで、受信セグメント管理部３３は、当該セグメントに付与された特別のヘッダにおいて、当該パスで、当該セグメントの一つ前に受信されたセグメントの特別のヘッダの変数「ｎｅｘｔ」に当該セグメントを設定する。
【０１３８】
セグメント送信部３４は、ステップＳ５０２において、受信セグメント管理部３３によって受信されたセグメントに対するＡＣＫを生成し、ステップＳ５０３において、かかるＡＣＫに付与するために、ＳＡＣＫオプションを生成する。
【０１３９】
ここで、ＳＡＣＫオプションにおける１ｓｔブロックは、今回受信したセグメントを含むブロックを示し、ＳＡＣＫオプションにおける２ｎｄブロックは、今回受信したセグメントと同一のパスを介して前回受信したセグメントを示し、ＳＡＣＫオプションにおける３ｒｄブロックは、今回受信したセグメントと同一のパスを介して前々回受信したセグメントを示す。
【０１４０】
図１４の例では、パス＃１を介してセグメント＃１０が受信された場合に生成されるＡＣＫ（Ａ）に付与されるＳＡＣＫオプションでは、１ｓｔブロックに「セグメント＃１０の識別情報」が設定され、２ｎｄブロックに「セグメント＃８の識別情報」が設定され、３ｒｄブロックに「セグメント＃３、＃４の識別情報（３-４）」が設定される。
【０１４１】
なお、かかる場合、従来のＳＡＣＫオプションでは、３ｒｄブロックに「セグメント＃６の識別情報」が設定される。
【０１４２】
また、図１４の例では、パス＃ｎを介してセグメント＃１１が受信された場合に生成されるＡＣＫ（Ｂ）に付与されるＳＡＣＫオプションでは、１ｓｔブロックに「セグメント＃１０、＃１１の識別情報（１０-１１）」が設定され、２ｎｄブロックに「セグメント＃６の識別情報」が設定され、３ｒｄブロックに「セグメント＃３、＃４の識別情報（３-４）」が設定される。
【０１４３】
なお、かかる場合、従来のＳＡＣＫオプションでは、２ｎｄブロックに「セグメント＃８の識別情報」が設定され、３ｒｄブロックに「セグメント＃６の識別情報」が設定される。
【０１４４】
ステップＳ５０４において、パス情報管理部＃ｎは、変数「ｒｃｖ＿ｎｘｔ」を参照することで、同じパスを介したセグメントの受信が連続しているか否かについて判定する。
【０１４５】
連続している場合、本動作はステップＳ５０５に進み、連続していない場合、本動作はステップＳ５０６に進む。
【０１４６】
ステップＳ５０５において、パス情報管理部＃ｎは、ＴＣＰ-ＣＢ（ｎ）において、変数「ｒｃｖ＿ｎｘｔ」に、受信した当該セグメントの次のセグメントの識別情報を設定し、変数「ｄｅｌ＿ａｃｋ」に、ステップＳ５０２で生成したＡＣＫによって通知されるセグメント（未だ受信していないセグメントのうち最もシーケンス番号が小さいセグメント）の識別情報を設定し、変数「ｐ＿ｓａｃｋ１〜３」に、ステップＳ５０３で生成したＳＡＣＫオプションの各ブロックによって通知されるセグメントの識別情報を設定する。
【０１４７】
また、パス情報管理部＃ｎは、ＴＣＰ-ＣＢ（ｎ）において、変数「ｄｅｌ＿ｔｉｍｅｒ」を起動する。
【０１４８】
変数「ｄｅｌ＿ｔｉｍｅｒ」が満了する間に、新たなセグメントを受信しなかった場合、変数「ｄｅｌ＿ａｃｋ」の値が返される（新たなセグメントを受信した場合、変数「ｄｅｌ＿ｔｉｍｅｒ」は、キャンセルされる）。
【０１４９】
ステップＳ５０５に入る前に、ステップＳ５０５ａで、ＡＣＫが記憶されているか否かを判断し、記憶されている場合は、ステップＳ５０６に移動し、記憶されていない場合は、ステップＳ５０５に移動する。
【０１５０】
ステップＳ５０６において、セグメント送信部３４は、ＴＣＰ-ＣＢ（ｎ）における変数「ｐ＿ｓａｃｋ１〜３」に基づいて、ＡＣＫを生成して送信する。かかる場合、パス情報管理部＃ｎは、必要に応じて、ＴＣＰ-ＣＢ（ｎ）における変数「ｒｃｖ＿ｎｘｔ」を更新する。
【０１５１】
図１５の例では、セグメント送信部３４は、セグメント＃６、＃７について、同一のパス＃２を介して連続して受信しているので、セグメント＃６、＃７の受信成功について、２つのＡＣＫによって通知するのではなく、１つのＡＣＫによって通知するように構成されている。
【０１５２】
（本発明の第１の実施形態に係る通信端末の作用・効果）
本実施形態に係る通信端末によれば、セグメントの送信が、通常のＴＣＰヘッダのみを用いて行われるように構成されているため、本発明に係る技術を適用していない受信端末３０がとの間であっても通信を行うことができる。
【０１５３】
本実施形態に係る通信端末によれば、複数のパスを介してＡＣＫを送信するように構成されているため、ＲＴＴを正確に計測することができ、各パスに対して通常のＴＣＰ制御と同等の制御を行うことができる。
【０１５４】
本実施形態に係る通信端末によれば、複数のＡＣＫ（送達確認信号）をまとめて送信することができるので（例えば、Ｃ-ＡＣＫをサポートすることができるので）、送信するＡＣＫの数を削減することができる。
【０１５５】
（変更例１）
図１６及び図１７を参照して、本発明の変更例１について説明する。
【０１５６】
図１６に示すように、変更例１に係る送信端末Ａのセグメント受信部１３は、近隣通信端末Ｂ乃至Ｅとの間でアドホックネットワークを形成し、当該アドホックネットワーク内のパス＃１乃至＃３を介してセグメントを送信するように構成されている。
【０１５７】
なお、送信端末Ａは、論文「Ａ  ｈｙｂｒｉｄ  Ａｐｐｒｏａｃｈ  ｔｏ  Ｉｎｔｅｒｎｅｔ  Ｃｏｎｎｅｃｔｉｖｉｔｙ  ｆｏｒ  Ｍｏｂｉｌｅ  Ａｄ  Ｈｏｃ  Ｎｅｔｗｏｒｋｓ（Ｐ．Ｒａｔａｎｃｈａｎｄａｎｉ  ａｎｄ  Ｒ．Ｋｒａｖｅｔｓ著、Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＩＥＥＥ  ＷＣＮＣ、２００３年）」や、論文「Ｉｎｔｅｒｎｅｔ  Ｃｏｎｎｅｃｔｉｖｉｔｙ  ｆｏｒ  Ａｄ  Ｈｏｃ  Ｎｅｔｗｏｒｋｓ（Ｙ．Ｓｕｎ、Ｅ．Ｂｅｌｄｉｎｇ-Ｒｏｙｅｒ、Ｃ．Ｐｅｒｋｉｎｓ著、Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｊｏｕｒｎａｌ  ｏｆ  Ｗｉｒｅｌｅｓｓ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｎｅｔｗｏｒｋｓ、ｓｐｅｃｉａｌ  ｉｓｓｕｅ  ｏｎ  Ｍｏｂｉｌｅ  Ａｄ  Ｈｏｃ  Ｎｅｔｗｏｒｋｓ（ＭＡＮＥＴｓ）：Ｓｔａｎｄａｒｄｓ、Ｒｅｓｅａｒｃｈ、Ａｐｐｌｉｃａｔｉｏｎｓ、９（２）、２００２年４月）」等に記載された技術を用いて、固定ネットワークとのゲートウェイとなる端末Ｃ乃至Ｅについて予め知っておく必要がある。
【０１５８】
図１７に示すように、送信端末Ａが、パス＃１を介して、宛先アドレスとして「送信端末Ｆのアドレス」を設定し、送信元アドレスとして「受信端末Ａのアドレス」を設定した第１のヘッダを含む第１のパケットを用いて、受信端末Ｆ宛てのセグメントを送信する場合を想定する。
【０１５９】
第１に、送信端末Ａは、宛先アドレスとして「送信端末Ｅのアドレス」を設定し、送信元アドレスとして「受信端末Ａのアドレス」を設定した第２のヘッダによって第１のパケットをカプセル化した第２のパケットを、端末Ｅに対して送信する。
【０１６０】
第２に、端末Ｅは、受信した第２のパケットに内包された第１のパケットを、宛先アドレスとして「送信端末Ｆのアドレス」を設定し、送信元アドレスとして「受信端末Ｅのアドレス」を設定した第３のヘッダによって再度カプセル化した第３のパケットを、受信端末Ｆに対して送信する。
【０１６１】
第３に、受信端末Ｆは、第３のパケットのヘッダに基づいて、当該セグメントが送信されたパスを判別する。図１７の例では、受信端末Ｆは、第１のヘッダ及び第３のヘッダを参照することで、パスＦ→Ｅ→Ａを判別することができる。
【０１６２】
なお、変更例１に係る受信端末Ｆのセグメント送信部３４も、変更例１に係る送信端末Ａのセグメント送信部１３と同様に、近隣通信端末との間でアドホックネットワークを形成し、該アドホックネットワーク内の前記パスを介して前記セグメントを受信するように構成されていてもよい。
【０１６３】
本実施形態に係る通信端末によれば、近隣通信端末との間で形成されたアドホックネットワーク内のパスを利用することによって、複数のインターフェースを持たない通信端末においても、送信端末と受信端末との間に存在する複数のパスを同時に利用して通信を行うこと（すなわち、マルチホーム接続）を実現することができる。
【０１６４】
また、受信端末が、上述のような変更例１に対応する機能を具備していない場合であっても、ＲＦＣ３７７５に規定されている「Ｍｏｂｉｌｅ  ＩＰ」機能を備えている場合、送信端末が、パケットを用いてセグメントを送信する際に、当該パケットを送信したインターフェースに該当するアドレスに対するＢＵ（Ｂｉｎｄｉｎｇ  Ｕｐｄａｔｅ）を付加することで、ＡＣＫが返ってくるインターフェースを操作し、さらに、ＳＡＣＫオプションの１ｓｔブロックを参照することにより、セグメント受信部１４が、適切なパス情報管理部＃ｎに、受信したＡＣＫを送信することが可能となり、受信端末が上述のような変更例１に対応する機能を具備した場合と同様のメリットを享受することが可能となる。
【図面の簡単な説明】
【０１６５】
【図１】本発明の第１の実施形態に係る通信端末を含む通信システムの全体構成図である。
【図２】本発明の第１の実施形態に係る通信端末（送信端末）の機能ブロック図である。
【図３】本発明の第１の実施形態に係る通信端末（送信端末）の送信セグメント管理部の管理内容の一例を示す図である。
【図４】本発明の第１の実施形態に係る通信端末（送信端末）のパス情報管理部の管理内容の一例を示す図である。
【図５】本発明の第１の実施形態に係る通信端末（受信端末）の機能ブロック図である。
【図６】本発明の第１の実施形態に係る通信端末（受信端末）のパス情報管理部の管理内容の一例を示す図である。
【図７】本発明の第１の実施形態に係る通信端末（受信端末）の受信セグメント管理部の管理内容の一例を示す図である。
【図８】本発明の第１の実施形態に係る通信端末（送信端末）がセグメントを送信する動作を示すフローチャートである。
【図９】本発明の第１の実施形態に係る通信端末（送信端末）がセグメントを送信する動作を説明するための図である。
【図１０】本発明の第１の実施形態に係る通信端末（送信端末）がＡＣＫを受信する動作を示すフローチャートである。
【図１１】本発明の第１の実施形態に係る通信端末（送信端末）がＡＣＫを受信する動作を説明するための図である。
【図１２】本発明の第１の実施形態に係る通信端末（送信端末）における再送モードの動作を示すフローチャートである。
【図１３】本発明の第１の実施形態に係る通信端末（受信端末）における受信動作を示すフローチャートである。
【図１４】本発明の第１の実施形態に係る通信端末（受信端末）における受信動作を説明するための図である。
【図１５】本発明の第１の実施形態に係る通信端末（受信端末）における受信動作を説明するための図である。
【図１６】本発明の変更例１に係る通信端末を説明するための図である。
【図１７】本発明の変更例１に係る通信端末を説明するための図である。
【符号の説明】
【０１６６】
１０…送信端末
１０ａ、３０ａ…アプリケーション機能部
１１…送信セグメント管理部
１２、３２…パス情報管理部
１３、３４…セグメント送信部
１４、３１…セグメント受信部
３０…受信端末
３３…受信セグメント管理部
【図１】
2007043678.tif 000003
【図２】
2007043678.tif 000004
【図３】
2007043678.tif 000005
【図４】
2007043678.tif 000006
【図５】
2007043678.tif 000007
【図６】
2007043678.tif 000008
【図７】
2007043678.tif 000009
【図８】
2007043678.tif 000010
【図９】
2007043678.tif 000011
【図１０】
2007043678.tif 000012
【図１１】
2007043678.tif 000013
【図１２】
2007043678.tif 000014
【図１３】
2007043678.tif 000015
【図１４】
2007043678.tif 000016
【図１５】
2007043678.tif 000017
【図１６】
2007043678.tif 000018
【図１７】
2007043678.tif 000019