JP2005057397A - 移動端末を含むデータ通信ネットワークにおける信頼性のあるデータ送信を制御するための装置 - Google Patents

Abstract

【課題】 全体的にデータ配信の向上を図る。
【解決手段】 移動端末１００において、ＩＰレイヤ１０２に存在するモビリティインタフェース１０４は、ＩＰレイヤ１０２がデータ通信ネットワークへの接続ポイントの変更を開始するとき、通知信号ＨＯ.ＩＮＩＴ.ＬＯＣＡＬをトランスポートレイヤ１０３に送信し、ＩＰレイヤ１０２がデータ通信ネットワークへの接続ポイントの変更を終了したとき、通知信号ＨＯ.ＦＩＮＩ.ＬＯＣＡＬをトランスポートレイヤ１０３に送信する。これにより、信頼性のあるトランスポートプロトコルは、ネットワーク輻輳状況によるセッション中断と、一またはそれ以上の移動端末が関係する接続ポイントハンドオフ状況によるセッション中断とを区別することが可能になる。信頼性のあるトランスポートプロトコルがそのような区別を行うことができる場合、異なる状況に対して異なる反応を示すことができ、よって、全体的にデータ配信が向上する。
【選択図】 図１

Description

本発明は、パケット交換型データ通信ネットワークにおける移動通信端末およびデータ通信端末に用いられる装置に関する。特に、本発明は、パケット交換型データ通信ネットワークのインターネットワーキングにおけるパケットの配送に関する。さらには、開示した発明は、パケット交換型データ通信ネットワークへの接続ポイントを絶えず変更している通信端末つまり移動通信端末におけるセッションの連続性を保持するという課題に対処したものである。このような移動通信端末は、順序付けられたデータ配送を必要とするパケット交換型データ通信ネットワークにおける他のノードに対して一つまたは複数のデータフローを持つことがある。これらのデータフローは各々トランスポートセッションとして知られている。開示した発明は、移動通信端末が移動している間のトランスポートセッションの維持をより良く最適化する装置を提供することにより、そのような移動通信端末の動作を向上するものである。

今日のパケット交換型データ通信ネットワークのほとんどは、ノードの相互接続ネットワークを介してデータパケットをルーティングするインターネットプロトコル（ＩＰ）（非特許文献１、非特許文献２参照）を用いている。ＩＰは、異なるベンダの製造によるホストやルータの使用を許容し、ますます多様化するネットワークタイプをカバーし、サーバを妨害することなくネットワークの拡大を可能とし、セッションの上位レイヤおよびメッセージ指向サービスをサポートするように設計されている。しかし、ＩＰはフロー制御メカニズムを有していないため、順序付けられた信頼性のあるデータ配送を確実なものとするために、通常、ＩＰの上位で送信制御プロトコル（ＴＣＰ）（非特許文献３参照）やストリーム制御送信プロトコル（ＳＣＴＰ）（非特許文献４参照）などのトランスポートレイヤプロトコルが用いられている。伝統的なインターネット基盤におけるＴＣＰの性能を最適化するために、長年の間、様々なＴＣＰ輻輳制御アルゴリズムが開発されており、その多くはＳＣＴＰのような他のトランスポートプロトコルにも組み込まれている。これらは、インターネット技術標準化委員会（ＩＥＴＦ）によって規格化され（非特許文献５参照）、または、個人所有の知的財産権となっている（特許文献１〜特許文献４参照）。特許文献１は、ＴＣＰフローを終了し複数のゲートウェイ間のマルチフローをオープンしてＴＣＰ送信のスピードアップを図る中間ゲートウェイの使用を提唱している。この方法は、（終端間のＴＣＰフローを分断してしまうため）とても目立つものであり、これが効果的に機能するには、提案された方法が幅広く採用される必要がある。特許文献２は、ＴＣＰヘッダを判断して重複再送や重複確認応答を減らすことによりＴＣＰを最適化するスマートエージェントを中間ルータに組み込む。しかし、これは、ＩＰレイヤがペイロードを暗号化し、したがって中間ルータがＩＰよりも上位のプロトコルレイヤのヘッダをチェックできない場合には機能しない。これを克服するため、特許文献３および特許文献４は、ネットワークの状況に応じて端末におけるＴＣＰパラメータを制御することを提案している。上記の解決策はすべてネットワーク輻輳が発生した場合のＴＣＰの性能を考えている。輻輳は、通常、バケットの損失またはパケット往復時間の増加により検出される。しかし、通信端末の移動性を考慮した場合、もはやそうとは限らない。

無線技術の出現と普及により、ますます多くの端末が、異なるドメインをローミングし、トランスポートセッションの継続中に異なる時点でパケット交換型データ通信ネットワーク（例えば、インターネットなど）の異なる接続ポイントに接続するという意味において、移動端末となっている。このようなローミング機能は、ＩＰバージョンｖ４（ＩＰｖ４）（非特許文献１参照）におけるモバイルＩＰｖ４（非特許文献６参照）やＩＰバージョンｖ６（ＩＰｖ６）（非特許文献２参照）におけるモバイルＩＰｖ６（非特許文献７参照）などの解決策によって提供されている。モバイルＩＰでは、各データ通信端末（モバイルノードと呼ばれる）が恒久的なホームドメインを持っている。モバイルノードは、ホームネットワークに接続されると、ホームアドレスとして知られる恒久的なグローバルアドレスが割り当てられる。モバイルノードがアウェイの状態にある場合、つまり、ホーム以外の他のネットワークに接続されている場合には、通常、気付アドレスとして知られる一時的なグローバルアドレスが割り当てられる。モビリティサポートの考えは、モバイルノードがホーム以外の他のネットワークに接続されている場合であっても、ホームアドレスを通じて、当該モバイルノードにアクセスすることができ、その結果、パケット交換型データ通信ネットワーク内の他のノードは当該モバイルノードのホームアドレスによって当該モバイルノードを識別すれば足りるというものである。これは、非特許文献６および非特許文献７において、ホームエージェントとして知られるホームネットワークにおけるエンティティを導入して行われている。モバイルノードは、位置情報更新（Binding Update）として知られるメッセージを用いて、ホームエージェントに自己の気付アドレスを登録する。ホームエージェントは、モバイルノードのホームアドレスを宛先とするメッセージを傍受し、ＩＰカプセル化技術（つまり、ＩＰパケットを別のＩＰパケット内にカプセル化する技術）を用いて、そのパケットをモバイルノードの気付アドレスに転送する役割を負っている。

モバイルノードのホームエージェントでわかっている、そのようなホームアドレスと気付アドレスの結合によって、たとえモバイルノードがどこに位置していようともモバイルノードへのアクセスが可能になる。しかし、モバイルノードが前の接続ポイントを離れ、まだホームアドレスと新しい気付アドレスとの新しい結合が確立されていない（または、まだ新しい気付アドレスを受け取ってさえいない）状態の時がある。この間はモバイルノードにパケットを配送することができない。このため、トランスポートセッションは、トランスポートセッションパケットが通過するネットワークパスが全く混み合っていない場合であっても、パケットの往復時間の増加やパケット損失の増加に遭遇することがある。輻輳／受信窓を小さくしトランスポートプロトコルにおける再送タイムアウト値を大きくするという対処（これの元々の考えは、混雑したネットワークへのパケット投入速度を落として輻輳の緩和を図ることである）は、接続ポイントを切り替えたばかりの移動端末に対してはあまり適切に適用することができない。
T. Hasegawa, et al., "TCP communications speed improvement system", US 6535515, Mar 2003 G. Bellaton, et al., "Mechanism for dispatching packets via telecommunications network", US Pat 6473425, Oct 2002 S. Sen, et al., "TCP-aware agent sublayer (TAS) for robust TCP over wireless", US Pat 6208620, Mar 2001 J. Ruutu, et al., "Method and apparatus for adjustment of TCP sliding window with information about network conditions", US Pat 6219713, Apr 2001 DARPA, "Internet Protocol", IETF RFC 791, Sep 1981 S. Deering and R. Hinden, "Internet Protocol Version 6 (IPv6) Specification", IETF RFC 2460, Dec 1998 J. Postel, "Transmission Control Protocol", IETF RFC 793, Sep 1981 R. Stewart, et al., "Stream Control Transmission Protocol", IETF RFC 2960, Oct 2000 M. Allman, et al., "TCP Congestion Control", IETF RFC 2581, Apr 1999 C. E. Perkins, et al., "IP Mobility Support", IETF RCF 3344, Aug 2002 D. B. Johnson, C. E. Perkins, and J. Arkko, "Mobility Support in IPv6", Internet Draft: draft-ietf-mobileip-ipv6-21.txt, Work In Progress, Feb 2003

上記のように、信頼性のあるトランスポートレイヤプロトコル（ＴＣＰやＳＣＴＰなど）のために設計された既存の最適化技術および輻輳制御アルゴリズムは、送受信端末の移動性を考慮に入れていない。特許文献３は、無線ネットワーク上でのＴＣＰの利用に取り組んでいるが、その考察は、端末の移動性ではなく、損失が多く不安定な無線チャネルの性質に限定されている。特許文献３では、無線ネットワークのチャネル状況を検出するためにＴＣＰエージェントが端末に配置されている。そして、同エージェントは、例えば、輻輳および受信窓のサイズ、再送タイムアウト値など、ＴＣＰのパラメータを調整する。ＴＣＰ自体にもネットワーク状況を検出するメカニズムは組み込まれているが、通常、ＴＣＰがそのような状況を探知するにはもっと時間がかかる。したがって、特許文献３は、無線終端においてネットワーク輻輳に対するＴＣＰの反応を速くすることができる。

しかしながら、移動端末が接続ポイントを変更して新たなアドレス結合を確立することに起因するパケット損失または遅延は、特許文献３のアルゴリズムまたはＴＣＰの内蔵メカニズムによって、ネットワーク輻輳の現象だと見られてしまう。したがって、実際はネットワーク輻輳など全く生じていないにもかかわらず、あたかもハンドオフを無事終了した後にネットワーク輻輳が生じたかのようになり、ＴＣＰセッションは性能低下に見舞われることになる。これは、ＴＣＰのみならず、例えばＳＣＴＰなど、確認応答フィードバックと輻輳制御アルゴリズムを用いる、ＩＰレイヤよりも上位の任意のトランスポートメカニズムにも影響を与える。

この問題を解決する簡単な方法は、移動端末にパケットバッファを設けて、移動端末が接続ポイントを変更している間は送信パケットを待ち行列に入れ、移動端末がアドレス結合の確立を完了すると、待ち行列に入っていたパケットを送信することである。しかし、この方法では、移動端末が無事ハンドオフを終了した後にパケットが一気に突然ネットワークに投入されるため、ネットワーク輻輳が生じ得る。また、大きな塊のデータが固定端末から移動端末に送信された場合、問題の解決にはならない。さらに、パケットバッファを無限に大きくすることはできず、適当な大きさのバッファを使用すれば移動端末における貴重な資源を消費してしまうことになる。

本発明の目的は、全体的にデータ配送を向上することができる、パケット交換型データ通信ネットワークにおける移動通信端末およびデータ通信端末に用いられる装置を提供することである。

上記の記載から明らかなように、トランスポートメカニズムがネットワーク輻輳の状況と端末移動の状況とを区別することが必要である。このことは、固定端末が移動端末と通信する場合もある以上、移動する通信端末のみに当てはまるものではなく、固定端末にも同様に当てはまる。固定端末の通信相手である移動端末の移動によってもパケット損失および／または遅延は発生する。開示した発明は、トランスポートプロトコルに対するインタフェースを設けることで、移動端末の移動をトランスポートプロトコルに通知する手段を提供する。また、本発明は、パケットの送信者がちょうど接続ポイントの変更を終了したことをパケットの受信者が推定できるように、移動端末が送信パケットにマーキングする手段を提供する。これにより、リモート端末は、輻輳制御アルゴリズムによって誤ってデータフローに対する輻輳制御が送信者に適用されることがないよう、適切な対応を採ることができる。

本発明は、パケット交換型データ通信ネットワーク上の信頼性のある送信プロトコルに対する追加のインタフェースを用いるものである。このインタフェースにより、信頼性のある送信プロトコルは、ネットワーク輻輳状況によるセッション中断と、一またはそれ以上の移動端末が関係する接続ポイントハンドオフ状況によるセッション中断とを区別することができる。このインタフェースは、他の輻輳制御アルゴリズムと共存することができ、実際、ハンドオフ中断からのより高速なリカバリーが可能となることで、性能を向上することができる。ハンドオフが無事終了したこと、または、ハンドオフが途中であることを伝えるため、トランスポートプロトコルに対して通知信号を送信する。この通知に基づいてトランスポートプロトコルは適切な対応を採ることができる。同様に、ある種のアプリケーション（特に、リアルタイムデータのストリーミングにかかわるもの）はトランスポートプロトコルから独立した独自の輻輳制御方法を実行するため、同様の通知をユーザアプリケーションに送ることもできる。

本発明によれば、信頼性のあるトランスポートプロトコルは、ネットワーク輻輳状況によるセッション中断と、一またはそれ以上の移動端末が関係する接続ポイントハンドオフ状況によるセッション中断とを区別することができる。信頼性のあるトランスポートプロトコルがそのような区別を行うことができる場合、異なる状況に対して異なる反応を示すことができ、したがって、全体的なデータ配送の向上を図ることができる。また、ユーザアプリケーションに対してもこの区別を知らせることができる。このようにして、たとえアプリケーションが信頼性のあるトランスポートプロトコルを用いていない場合であっても、アプリケーションデータの輻輳制御をも最適化することができる。開示した発明を適用し相互に通信を行う端末に対しては、端末がハンドオフを行った後の送信遅延が改善される。

本明細書には、移動端末を含むパケット交換型データ通信ネットワークにおける信頼性のあるデータ送信を制御するための装置が開示されている。開示した発明の理解を助けるため、以下の定義を用いる。

（ａ）「パケット」は、データネットワーク上で配送可能な任意のフォーマットの自己内包型のデータ単位である。「パケット」は、通常、「ヘッダ」部と「ペイロード」部の二つの部分から成る。「ペイロード」部は、配送するデータを含み、「ヘッダ」部は、パケットの配送を助けるための情報を含んでいる。「ヘッダ」部は、「パケット」の送信者と受信者をそれぞれ識別するため、ソースアドレスと宛先アドレスを持たなければならない。

（ｂ）「モバイルノード」は、パケット交換型データ通信ネットワークへの接続ポイントを変更するネットワーク構成要素である。これは、パケット交換型データ通信ネットワークへの接続ポイントを変更するエンドユーザ通信端末を指して用いられる。本明細書では、特に反対の明示がない限り、「モバイルノード」と「移動端末」の用語を同じ意味で使用する。

（ｃ）「トランスポートセッション」は、同一の論理データソースから同一の論理データシンクに生成される二つのエンドポイント間のデータの配送である。通常、送信側と受信側とで同一のプロトコルセットが用いられ、セッションの確立と解除が通常要求される。「トランスポートセッション」は、損失のない順序付けられたデータ配送が保証されている場合、信頼性がある。本明細書では、「トランスポートセッション」という用語は、反対の明示がない限り、「信頼性のあるトランスポートセッション」を暗黙的に意味するものとして用いる。

以下の記載においては、説明のため、本発明を完全に理解してもらうために、特定の番号、時間、構造その他のパラメータを示すものとする。しかし、本発明がこれら特定の詳細なくして実施され得ることは、当業者にとって明らかである。

（実施の形態1）
図１は、本発明の実施の形態１に係る移動端末の構成を示すブロック図である。図１に示す移動端末１００は、一つまたは複数の下位レイヤ１０１、ＩＰレイヤ１０２、トランスポートレイヤ１０３、およびモビリティインタフェース１０４から成る。下位レイヤ１０１は、ネットワーク層より下層の、すべてのプロトコル、ソフトウェアドライバ、および物理ネットワークインタフェースを包含した概念的ブロックである。言い換えれば、下位レイヤ１０１は、国際標準化機構（ＩＳＯ）の開放型システム間相互接続（ＯＳＩ）モデルにおける物理層（レイヤ１）およびデータリンク層（レイヤ２）を包含する。ＩＰレイヤ１０２は、パケットの受信およびパケットの送信を処理しパケットの経路を決定するプロトコルスタックにおけるソフトウェアモジュールである。これは、ＩＳＯのＯＳＩモデルにおけるネットワーク層（レイヤ３）、または、インターネットプロトコル（ＩＰ）環境では、ＩＰレイヤに相当する。ＩＰレイヤは移動する端末に存在するため、ＩＰレイヤ１０２はまたモビリティハンドオフを実行するための機能ロジックを有する。トランスポートレイヤ１０３は、信頼性のある順序付けられたデータ配送を提供するトランスポートプロトコルを実行するソフトウェアモジュールである。これはＯＳＩモデルにおけるトランスポート層（レイヤ４）に相当する。トランスポートレイヤ１０３内には、一またはそれ以上のトランスポートセッション１０５が存在し得る。各トランスポートセッション１０５は、移動端末１００とあるリモート端末との間の信頼性のある継続中の通信セッションに対応している。トランスポートセッション１０５は、通信端末のアドレス、および、各通信端末における通信セッションに関連するポート番号によって、一意に特定される。

下位レイヤ１０１、ＩＰレイヤ１０２、およびトランスポートレイヤ１０３は、ほとんどのネットワークノードのアーキテクチャに見出すことができる。本発明は、ＩＰレイヤ１０２内に、モビリティインタフェース１０４という構成要素を導入する。モビリティインタフェース１０４は、ＩＰレイヤ１０２が無事ハンドオフを終了する度に、参照番号１１３で示す信号パスを介して、トランスポートレイヤ１０３に対して通知を送信する役割を負っている。後で詳述するように、モビリティインタフェース１０４は、参照番号１１２で示す信号パスを介して、端末の移動性についてのトリガメッセージを受信することができる。参照番号１１０、１１１で示すデータパスは、受信データパケットおよび送信データパケットが通る通常のパスである。

ＩＰレイヤ１０２がハンドオフの実行を開始する度に、モビリティインタフェース１０４は、トランスポートレイヤ１０３に対して、ＨＯ.ＩＮＩＴ.ＬＯＣＡＬ（ハンドオフ開始）の通知を送信する。あるいは、多くの無線ネットワークインタフェースは、基地局との距離を推定し、ハンドオフを事前に予測することができる。モビリティインタフェース１０４は、下位レイヤ１０１から移動検出を受信することができ、トランスポートレイヤ１０３に対してＨＯ.ＩＮＩＴ.ＬＯＣＡＬの通知を送信する。トランスポートレイヤ１０３は、この通知を受信すると、適当な対応を採ることができる。同様に、ＩＰレイヤ１０２が無事ハンドオフを終了すると、モビリティインタフェース１０４は、トランスポートレイヤ１０３に対して、ＨＯ.ＦＩＮＩ.ＬＯＣＡＬ（ハンドオフ終了）の通知を送信する。トランスポートレイヤ１０３は、この通知を受信すると、対応する処置を採ることができる。以下、例を用いて説明する。

多くの場合、ベースとなるトランスポートプロトコル自体が、輻輳制御に類似した機能を実行するメカニズムを内蔵している。例えば、ＴＣＰやＳＣＴＰでは、確認応答を受信する往復時間を用いて再送タイムアウト値を予測する。主要な考えは、ネットワークが混雑している場合は、ＴＣＰまたはＳＣＴＰの送信レートを減速することである。しかし、移動端末がモビリティハンドオフを行う場合、これらのプロトコルの内蔵メカニズムは、（指数関数的な再送バックオフのため）再送タイムアウト値を指数関数的に増加させてしまう。この結果、ＴＣＰまたはＳＣＴＰセッションは、不必要に大きな再送タイムアウト値を有することになり、したがって、モビリティハンドオフ後にスループットが低下してしまう。

これを克服するために、図２に示す方法を用いることができる。ステップ１１００では、ＩＰレイヤ１０２がモビリティハンドオフの手順を開始する。そして、ステップ１２００では、モビリティインタフェース１０４が、トランスポートレイヤ１０３に対して、ＨＯ.ＩＮＩＴ.ＬＯＣＡＬの通知を送信する。そして、ステップ１３００では、トランスポートレイヤ１０３が、すべてのトランスポートセッション１０５に対して、プロトコルパラメータの調整を一時停止するように指示する。この一時停止は、ＩＰレイヤ１０２がハンドオフの手順を終了する（ステップ１４００）まで継続し、その終了後、モビリティインタフェース１０４は、トランスポートレイヤ１０３に対して、ＨＯ.ＦＩＮＩ.ＬＯＣＡＬの通知を送信する（ステップ１５００）。そして、ステップ１６００では、トランスポートレイヤ１０４が、トランスポートセッション１０５に対して、プロトコルパラメータの調整を再開するように指示する。

これを実現する一つの方法は、トランスポートレイヤ１０３に特別のフラグ変数を設定することである。フラグは、ＨＯ.ＩＮＩＴ.ＬＯＣＡＬ通知を受信すると設定され、ＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知を受信するとクリアされる。フラグ変数がクリアされると、トランスポートセッション１０５は通常通りに機能する。フラグ変数が設定されると、トランスポートセッション１０５はトランスポートプロトコルのパラメータの更新を停止する。

輻輳制御アルゴリズムを備えるトランスポートプロトコルに対しては、図３に示すフローチャートを用いることができる。図３において、ステップ１１００、ステップ１２００、ステップ１４００、およびステップ１５００は、図２のものと同一である。ステップ１３１０では、トランスポートレイヤ１０３は、ＨＯ.ＩＮＩＴ.ＬＯＣＡＬの通知を受信すると、トランスポートセッション１０５に対して、輻輳制御アルゴリズムの通常動作を一時停止するように指示する。この一時停止は、トランスポートレイヤ１０３がモビリティインタフェース１０４からＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知を受信するまで継続する。ステップ１６１０では、トランスポートレイヤ１０３は、トランスポートセッション１０５に対して、輻輳制御アルゴリズムの通常動作を再開するように指示する。

例えば、特許文献４では、現在のネットワーク状況に関して収集された情報に基づいて、ＴＣＰの窓サイズを調整する方法が提案されている。当該開示発明によれば、トランスポートレイヤ１０３およびトランスポートセッション１０５は、モビリティインタフェース１０４からＨＯ.ＩＮＩＴ.ＬＯＣＡＬ通知を受信した時より、ＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知を受信するまで、そのような調整を一時停止する。

ＨＯ.ＩＮＩＴ.ＬＯＣＡＬ通知の受信は、ネットワークの接続がしばらくの間、中断されることを意味するため、トランスポートレイヤ１０３は、ＨＯ.ＩＮＩＴ.ＬＯＣＡＬ通知を受信すると、トランスポートセッション１０５に対して、より小さな受信窓サイズを広告するように指示する。これは図４に記載の方法に示されている。図４において、ステップ１１００、ステップ１２００、ステップ１４００、およびステップ１５００は、図２のものと同一である。ステップ１３２０では、トランスポートレイヤ１０３は、トランスポートセッション１０５に対して、より小さな受信窓サイズを広告するように指示する。これにより、リモートトランスポートプロトコルは送信レートを低下させる。トランスポートレイヤ１０３がモビリティインタフェース１０４からＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知を受信すると（ステップ１５００）、ステップ１６２０に示すように、トランスポートレイヤ１０３は、トランスポートセッション１０５に対して、通常の窓サイズ、つまり、ＨＯ.ＩＮＩＴ.ＬＯＣＡＬ通知を受信する前の窓サイズを広告するように指示する。

上記のように、ＴＣＰ（および、他のいくつかのトランスポートプロトコル）では、再送タイムアウト値は変数である。移動端末がハンドオフに入る直前に長い再送タイムアウト時間が用いられていることがあり得る。ハンドオフ後、移動端末１００は、ネットワーク状況が以前よりも非常に良い、異なるネットワーク部分に位置し得る。再送期間を最後まで待つのは望ましいことではない。また、ハンドオフ中に新たなトランスポートセッション１０５が立ち上がることもあり得る。この場合、そのトランスポートセッション１０５は、ＨＯ.ＩＮＩＴ.ＬＯＣＡＬ通知の受信に対応する処置を何ら採っておらず、したがって、ハンドオフ中に再送タイムアウト値の調整および／または送信窓サイズの調整を継続していることがある。さらには、端末がＨＯ.ＩＮＩＴ.ＬＯＣＡＬ通知を送信できないようにしたり、または、簡単化のため、端末がＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知のみを行うようにすることもあり得る。これにより、トランスポートプロトコルは、ハンドオフ中に非常に大きな送信タイムアウト値または非常に小さな窓サイズを生じることになる。したがって、トランスポートレイヤ１０３は、先のＨＯ.ＩＮＩＴ.ＬＯＣＡＬ通知の受信の有無を問わず、ＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知を受信すると何らかの対応を採る必要がある。

これを行う一つの方法は、トランスポートレイヤ１０３がＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知を受信すると再送を開始することである。データの再送によって、ほとんどのトランスポートプロトコル、例えば、ＴＣＰやＳＣＴＰは、ネットワーク状況の探知を開始する。リモート（相手）側も、確認応答をもってこれに応じ、よって、トランスポートプロトコルに現在のネットワーク状況についてのフィードバックを与える。これにより、トランスポートプロトコルは、ハンドオフの後、再送タイマの終了を待つ必要なく、より早く正常な状態に戻ることができる。しかし、これは、トランスポートレイヤ１０３が多くのトランスポートセッション１０５を管理している場合、ネットワークトラフィックに大きなバーストをもたらし得る。したがって、トランスポートレイヤ１０３は、各トランスポートセッション１０５の再送を異なる遅延を用いてスケジューリングしたり、または、再送データのサイズを制限したりすることを望む場合がある。いずれにせよ、主要な考えは、トランスポートレイヤ１０３が、ＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知を受信した後、プロトコル内蔵再送タイムアウトトリガの発生を待つ必要なく、先に送信されたが応答されていないデータセグメントの再送を開始することである。これは図５に示されている。図５のステップ１４００およびステップ１５００は、図２のものと同一である。ステップ１６３０では、トランスポートレイヤ１０３は、ＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知を受信した後（ステップ１５００）、トランスポートセッション１０５に対して、再送をスケジューリングするように指示する。

同一の原理を念頭に、トランスポートレイヤ１０３は、ＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知を受信すると、確認応答の送信も開始することができる。これは図６に示されている。図６のステップ１４００およびステップ１５００は、図２のものと同一である。ステップ１６４０では、ＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知を受信した後（ステップ１５００）、トランスポートレイヤ１０３は、トランスポートセッション１０５に対して、二重の確認応答を送信するように指示する。確認応答メッセージは、リモートトランスポートプロトコルに応答の機会を与え、リモートトランスポートプロトコルを再送待機状態から脱却させることができる。通常、トランスポートプロトコルは、パケット受信後または送信タイムアウト後にのみ、確認応答を送信することができる。ここでは、トランスポートレイヤ１０３は、データの到着または送信タイムアウトを待つことなく、強制的にトランスポートプロトコルに確認応答を送信させる。先にデータを受信していない場合、（ＴＣＰやＳＣＴＰなど）ほとんどのトランスポートプロトコルは、ゼロデータの受信を示す確認応答メッセージを許容する。ここでは、この確認応答メッセージが送信される。すなわち、トランスポートレイヤ１０３は、先に確認応答が送信されている場合は、ＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知に応答して、トランスポートセッション１０５において先に送信された確認応答を再送し、先に送信された確認応答がない場合は、ＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知に応答して、トランスポートセッション１０５において受信されたデータがゼロであることを知らせる確認応答を送信する。

したがって、本実施の形態に開示した技術によれば、信頼性のあるトランスポートプロトコルは、ネットワーク輻輳状況によるセッション中断と、一またはそれ以上の移動端末が関係する接続ポイントハンドオフ状況によるセッション中断とを区別することが可能になる。このようにして、トランスポートプロトコルは異なる状況に対して異なる反応を示すことができ、したがって、全体的にデータ配送を向上することができる。

（実施の形態２）
ある状況では、輻輳制御がアプリケーションレベルで行われる。これは、特に、データが、ＴＣＰのような信頼性のあるトランスポートプロトコルではなく、例えば、ＵＤＰ（User Datagram Protocol）のような信頼性の低いトランスポートプロトコルを介して転送される音声／映像ストリーミングアプリケーションの場合に当てはまる。よって、アプリケーションは、データストリームのためのアプリケーション自らの速度制御を実行する。このような場合、モビリティインタフェース２０４はユーザアプリケーションに対しても同様に通知信号を送信することが望ましい。

図７は、本発明の実施の形態２に係る移動端末の構成を示すブロック図である。図７に示す移動端末２００の構成要素はほとんど実施の形態１で説明した移動端末１００のものと同一であり、したがって、同一の構成要素には同一の参照番号を付し、その詳細な説明は省略する。移動端末２００は、ＩＰレイヤ１０２に存在する一つのモビリティインタフェース２０４、および、一または複数のアプリケーション２０６で構成されている。モビリティインタフェース２０４は、実施の形態１に記載したモビリティインタフェース１０４のすべての機能を有し、さらに参照番号２１５で示す信号パスを介して、アプリケーション２０６に対して通知を送信する追加機能を有する。アプリケーション２０６は、リモート側（離れた相手）と通信するネットワークプロトコルスタックを用いるすべてのアプリケーションを含んでいる。アプリケーション２０６とネットワークプロトコルスタックの間で送受信されるデータは、参照番号２１４で示すデータパスを介して受け渡される。あるアプリケーションがモビリティインタフェース２０４によって送信される通知の利用を望む場合、モビリティインタフェース２０４とアプリケーション２０６の間に参照番号２１５で示す信号パスが開設されるように、システムコールを行い、または、特別のファイル／デバイスを開くことによって、この通知の利用が可能になる。

図８は、モビリティインタフェース２０４が用いる方法を示すフローチャートである。図８のステップ１１００およびステップ１４００は、実施の形態１で説明した図２に示すものと同一である。移動端末２００のＩＰレイヤ１０２がハンドオフの手順を開始する度に（ステップ１１００）、モビリティインタフェース２０４は、アプリケーション２０６に対して、ＨＯ.ＩＮＩＴ.ＬＯＣＡＬ通知を送信する（ステップ２２００）。同様に、ハンドオフの手順が終了すると（ステップ１４００）、モビリティインタフェース２０４は、アプリケーション２０６に対して、ＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知を送信する（ステップ２５００）。アプリケーションに特有の性質のため、上記通知を受信した時にアプリケーション２０６が具体的にステップ２３００およびステップ２６００で何を行うかは、本明細書の対象外である。あり得る対応は、ＨＯ.ＩＮＩＴ.ＬＯＣＡＬ通知を受信すると送信レートを落とし、ＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知を受信すると送信レートを元に戻すことである。

したがって、本実施の形態によれば、移動端末に存在し輻輳制御メカニズムを有するアプリケーションもまた、ネットワーク輻輳状況によるセッション中断と、一またはそれ以上の移動端末が関係する接続ポイントハンドオフ状況によるセッション中断とを区別することができる。このようにして、アプリケーションは、異なる状況に対して対応するアクションを採ることにより、全体的にデータ配送を向上することができる。

（実施の形態３）
ある移動端末がハンドオフを行っているとき、本発明の実施の形態１および実施の形態２に記載した方法および装置を用いることにより、トランスポートセッションへの影響を最小にすることができる。しかし、移動端末と通信を行うデータ通信端末もまた、移動端末がハンドオフを行うとき、連続した期間、突然のパケット損失に直面することになる。この状況もまた、トランスポートプロトコルによってネットワーク輻輳状態と誤って解釈される場合がある。したがって、モビリティハンドオフを行う移動端末が、自己がアクティブなトランスポートセッションを持つ他のノードに対して、このハンドオフについて通知することは有益である。これが本発明の実施の形態３の目的である。

図９は、本発明の実施の形態３に係る移動端末およびデータ通信端末の構成を示すブロック図である。移動端末３００は、パケット交換型データ通信ネットワークを介してデータ端末３２０と通信を行っており、移動端末３００とデータ端末３２０の間には少なくとも一つのトランスポートセッションが存在している。図９に示す移動端末３００の構成要素はほとんど実施の形態１で説明した移動端末１００のものと同一であり、したがって、同一の構成要素には同一の参照番号を付し、その詳細な説明は省略する。移動端末３００は、ＩＰレイヤ１０２に存在する一つのモビリティインタフェース３０４を有する。モビリティインタフェース３０４は、実施の形態１に記載したモビリティインタフェース１０４のすべての機能を有し、さらに送信データパケットにハンドオフ通知を埋め込む追加機能を有する。移動端末３００がハンドオフの手順を開始するとき、モビリティインタフェース３０４は、送信パケットのＩＰパケットヘッダにユニークな表示を挿入する。このユニークな表示は、パケットヘッダの所定の位置に配置される特別のビットセットや、パケットヘッダのオプションフィールドにおける所定値などの形を取ることができる。このような表示は、受信者に対して、送信者（つまり、移動端末３００）がまもなくハンドオフの手順を開始することを通知するのに役立つ。同様に、移動端末３００がハンドオフの手順を終了したとき、モビリティインタフェース３０４は、送信パケットのＩＰパケットヘッダにユニークな表示を挿入する。このような表示は、受信者に対して、送信者（つまり、移動端末３００）がハンドオフの手順がちょうど終了したことを通知するのに役立つ。

注意すべき点は、移動端末３００は、通常、ハンドオフ中にパケットを送信することができないため、表示の送信パケットへの埋め込みを、ハンドオフ開始の少し前（例えば、１秒前）に行わなければならないことである。これは、実際にハンドオフが行われる前に、モビリティインタフェース３０４が、ハンドオフが行われることについての予告を受けることができる場合にのみ可能である。また、モビリティインタフェース３０４は、ハンドオフを終了した移動端末３００の表示を、ハンドオフ終了の少し後（例えば、１秒後）に、送信パケットに埋め込む必要がある。これにより、誤った情報の受信者への送信が防止される。

あるいは、モビリティインタフェース３０４は、ハンドオフ開始の表示を送信するとき、パケットヘッダに何らかのタイミング情報も挿入することができる。タイミング情報により、受信者は、いつ送信者（つまり、移動端末３００）がハンドオフに入るのかを判断することができる。これは、受信者が送信者と同一のタイムフレーム上にあるよう、ＮＴＰ（Network Time Protocol）のような標準タイムスタンプに基づいて行われ得る。このため、受信者は、いつアクションを採れば良いかを正確に知ることができる。別の有益なタイミング情報は、ハンドオフにかかるであろう推定時間である。これにより、受信者は、いつ移動端末３００が接続を回復するかの見込みを正確に知ることができる。これは、受信者が、移動端末がハンドオフを終了したことを知るのにパケット（このパケットはＩＰのようなベストエフォート型のパケット交換型ネットワークにおいてはネットワークによって破棄される場合がある）に埋め込まれた表示に頼る必要がないということを意味するため、極めて有益である。したがって、埋め込まれた表示は以下のフォーマットを取ることができる。

Embed_Handoff_Indication {
Indication_Type; /* specify the type of indication: start_handoff, or end_handoff */
Start_Time; /* time when handoff is to start */
End_Time; /* estimated time when handoff will be completed */
}
Indication_Typeは、どの種類の表示であるか、つまり、ハンドオフ開始表示か、ハンドオフ終了表示かを一意に特定する。ハンドオフ開始表示の場合は、ハンドオフが開始される推定時刻とハンドオフが終了する推定時刻とをそれぞれ示すStart_TimeとEnd_Timeのオプションフィールドが存在していても良い。

このような表示が有益であるためには、受信者が受信パケットに埋め込まれた表示を検出して適切なアクションを採ることができなければならない。本発明は、実施の形態３に係る装置であるデータ端末３２０を明記する。

図９に示すデータ端末３２０は、一つまたは複数の下位レイヤ３２１、ＩＰレイヤ３２２、トランスポートレイヤ３２３、およびモビリティインタフェース３２４から成る。下位レイヤ３２１は、ネットワーク層より下層の、すべてのプロトコル、ソフトウェアドライバ、および物理ネットワークインタフェースを包含した概念的ブロックである。言い換えれば、下位レイヤ３２１は、ＩＳＯのＯＳＩモデルにおける物理層（レイヤ１）およびデータリンク層（レイヤ２）を包含する。ＩＰレイヤ３２２は、パケットの受信およびパケットの送信を処理しパケットの経路を決定するプロトコルスタックにおけるソフトウェアモジュールである。これは、ＩＳＯのＯＳＩモデルにおけるネットワーク層（レイヤ３）、または、インターネットプロトコル（ＩＰ）環境では、ＩＰレイヤに相当する。トランスポートレイヤ３２３は、信頼性のある順序付けられたデータ配送を提供するトランスポートプロトコルを実行するソフトウェアモジュールである。これはＯＳＩモデルにおけるトランスポート層（レイヤ４）に相当する。トランスポートレイヤ３２３内には、一またはそれ以上のトランスポートセッション３２５が存在し得る。各トランスポートセッション３２５は、データ端末３２０とあるリモート端末との間の信頼性のある継続中の通信セッションに対応している。トランスポートセッション３２５は、通信端末のアドレス、および、各通信端末における通信セッションに関連するポート番号によって、一意に特定される。モビリティインタフェース３２４は、ＩＰレイヤ３２２に存在して受信データパケットを検査する。これらのパケットのいずれかに移動端末３００で記載した埋込表示が入っている場合、モビリティインタフェース３２４は、トランスポートレイヤ３２３に対して、参照番号３３３で示す信号パスを用いて通知を送信する。参照番号３３０、３３１で示すデータパスは、受信データパケットおよび送信データパケットが通る通常のパスである。

モビリティインタフェース３２４は、受信パケットの送信者がハンドオフの手順を開始しようとしていることを示す、受信パケットに埋め込まれた表示を検出すると、トランスポートレイヤ３２３に対して通知を送信する。この通知は、ＨＯ.ＩＮＩＴ.ｘの形を取る。ここで、ｘは送信者の識別子（例えば、ＩＰアドレス）である。トランスポートレイヤ３２３は、この通知を受信すると、ｘで特定されるリモート端末と通信を行うトランスポートセッションに対して関係アクションを採ることができる。同様に、モビリティインタフェース３２４は、受信パケットの送信者がハンドオフの手順をちょうど終了したことを示す、受信パケットに埋め込まれた表示を検出すると、トランスポートレイヤ３２３に対して、通知を送信する。この通知は、ＨＯ.ＦＩＮＩ.ｘの形を取る。ここで、ｘは送信者の識別子である。トランスポートレイヤ３２３は、ｘで特定される端末と通信を行うトランスポートセッションに対して関係アクションを採ることができる。

上記のように、モビリティインタフェース３０４は、パケットヘッダにタイミング情報をも埋め込むことができる。この場合、受信側のモビリティインタフェース３２４は、すぐにトランスポートレイヤ３２３に対してＨＯ.ＩＮＩＴ.ｘ通知を送信する代わりに、タイミング情報を利用してＨＯ.ＩＮＩＴ.ｘ通知とＨＯ.ＦＩＮＩ.ｘ通知のスケジューリングを行うことができる。モビリティインタフェース３２４は、受信パケットヘッダにあるEmbed_Handoff_IndicationのStart_Timeフィールドにより指定された時刻においてＨＯ.ＩＮＩＴ.ｘ通知を送信することができる。また、モビリティインタフェース３２４は、受信パケットヘッダにあるEmbed_Handoff_IndicationのEnd_Timeフィールドにより指定された時刻においてＨＯ.ＦＩＮＩ.ｘ通知を送信することができる。

図１０は、データ端末３２０の一つの動作例を示すフローチャートである。ステップ３１００では、モビリティインタフェース３２４は、送信者ｘがまもなくモビリティハンドオフの手順を開始することを示す、受信パケットに含まれる埋込表示を検出する。そして、ステップ３２００では、モビリティインタフェース３２４は、トランスポートレイヤ３２３に対して、ＨＯ.ＩＮＩＴ.ｘの通知を送信する。そして、ステップ３３００では、トランスポートレイヤ３２３は、ｘで特定されるリモート端末と通信を行うすべてのトランスポートセッション３２５に対して、プロトコルパラメータの調整を一時停止するように指示する。この一時停止は、ステップ３４００に示すように、モビリティインタフェース３２４が、送信者ｘがモビリティハンドオフの手順を終了したことを示す、受信パケット内の埋込表示を検出するまで継続する。そして、モビリティインタフェース３２４は、トランスポートレイヤ３２３に対して、ＨＯ.ＦＩＮＩ.ｘ通知を送信する（ステップ３５００）。そして、ステップ３６００では、トランスポートレイヤ３２３は、ｘで特定されるリモート端末と通信を行うトランスポートセッション３２５に対して、プロトコルパラメータの調整を再開するように指示する。

図１１は、データ端末３２０の第二の動作例を示す別のフローチャートである。図１１におけるステップ３１００、ステップ３２００、ステップ３４００、およびステップ３５００は、図１０のものと同様であり、その詳細な説明は省略する。トランスポートレイヤ３２３は、モビリティインタフェース３２４からＨＯ.ＩＮＩＴ.ｘ通知を受信すると（ステップ３２００）、ステップ３３１０に示すように、ｘで特定されるリモート端末と通信を行うすべてのトランスポートセッション３２５に対して、すべての輻輳制御アルゴリズムの動作を一時停止するように指示する。この一時停止は、トランスポートレイヤ３２３がＨＯ.ＦＩＮＩ.ｘ通知を受信するまで継続する（ステップ３５００）。そして、ステップ３６１０では、トランスポートレイヤ３２３は、ｘで特定されるリモート端末と通信を行うトランスポートセッション３２５に対して、輻輳制御アルゴリズムの動作を再開するように指示する。

図１２は、データ端末３２０の第三の動作例を示す、さらに別のフローチャートである。これは、トランスポートレイヤ３２３がＨＯ.ＦＩＮＩ.ｘ通知のみに基づいて独立のアクションを採る場合である。図１２におけるステップ３４００およびステップ３５００は、図１０のものと同様であり、その詳細な説明は省略する。トランスポートレイヤ３２３は、モビリティインタフェース３２４からＨＯ.ＦＩＮＩ.ｘ通知を受信すると（ステップ３５００）、ステップ３６３０に示すように、ｘで特定されるリモート端末と通信を行うすべてのトランスポートセッション３２５に対して、先に送信したが応答されていないデータセグメントの再送をスケジューリングするように指示する。データを再送することによって、ほとんどのトランスポートプロトコルは、ネットワーク状況の探知を開始する。リモート（相手）側も、確認応答をもってこれに応じ、よって、トランスポートプロトコルに現在のネットワーク状況についてのフィードバックを与える。これにより、トランスポートプロトコルは、ハンドオフの後、再送タイマの終了を待つ必要なく、より早く正常な状態に戻ることができる。ネットワークトラフィックにおける大きなバーストを回避するため、トランスポートレイヤ３２３は、各トランスポートセッション３２５の再送を異なる遅延を用いてスケジューリングしたり、または、再送データのサイズを制限したりすることを望む場合がある。いずれにせよ、主要な考えは、トランスポートレイヤ３２３が、ＨＯ.ＦＩＮＩ.ｘ通知を受信した後、プロトコル内蔵再送タイムアウトトリガの発生を待つ必要なく、端末ｘと通信を行うトランスポートセッション３２５における、先に送信されたが応答されていないデータセグメントの再送を開始することである。

注意すべき点は、端末ｘがハンドオフを開始するということはハンドオフ中にはデータを一切送信しないということを意味するため、ＨＯ.ＩＮＩＴ.ｘ通知を受信した時にトランスポートセッション３２５が窓サイズを小さくするのはそれほど有益なことではない。同様に、ＨＯ.ＦＩＮＩ.ｘ通知を受信した時にトランスポートセッション３２５が二重の確認応答を送信するのも、それほど有益なことではない。これは、端末ｘが、ハンドオフ終了後すぐに再送を開始することが予想されるからである。

当業者にとって、本実施の形態に記載したデータ端末３２０が固定端末でも移動端末でも良いことは明らかである。実際、本実施の形態に記載したデータ端末３２０および移動端末３００を組み合わせて一つの装置にすることは、いたって簡単である。

したがって、本実施の形態に開示した技術によれば、移動端末と通信を行うデータ端末における信頼性のあるトランスポートプロトコルは、ネットワーク輻輳状況によるセッション中断と、一つまたはそれ以上の移動端末が関係する接続ポイントハンドオフ状況によるセッション中断とを区別することが可能になる。このようにして、トランスポートプロトコルは異なる状況に対して異なる反応を示すことができ、よって、全体的にデータ配送を向上することができる。

（実施の形態４）
ある状況では、輻輳制御がアプリケーションレベルで行なわれる。これは、特に、データが、ＴＣＰのような信頼性のあるトランスポートプロトコルでなく、例えば、ＵＤＰのような信頼性の低いトランスポートプロトコルを介して転送される音声／映像ストリーミングアプリケーションの場合に当てはまる。よって、アプリケーションは、データストリームのためのアプリケーション自らの速度制御を実行する。このような場合、モビリティインタフェース４２４はユーザアプリケーションに対しても同様に通知信号を送信することが望ましい。

図１３は、本発明の実施の形態４に係るデータ端末の構成を示すブロック図である。図１３に示すデータ端末４２０の構成要素はほとんど実施の形態３で説明したデータ端末３２０のものと同一であり、したがって、同一の構成要素には同一の参照番号を付し、その詳細な説明は省略する。データ端末４２０は、ＩＰレイヤ３３２に存在する一つのモビリティインタフェース４２４、および、一つまたは複数のアプリケーション４２６で構成されている。モビリティインタフェース４２４は、実施の形態３に記載したモビリティインタフェース３２４のすべての機能を有し、さらに参照番号４３５で示す信号パスを介して、アプリケーション４２６に対して通知を送信する追加機能を有する。アプリケーション４２６は、リモート側と通信するネットワークプロトコルスタックを用いるすべてのアプリケーションを含んでいる。アプリケーション４２６とネットワークプロトコルスタックの間で送受信されるデータは、参照番号４３４で示すデータパスを介して受け渡される。あるアプリケーションがモビリティインタフェース４２４によって送信される通知の利用を望む場合、モビリティインタフェース４２４とアプリケーション４２６の間に参照番号４３５で示す信号パスが開設されるように、システムコールを行い、または、特別のファイル／デバイスを開くことによって、この通知の利用が可能になる。

図１４は、モビリティインタフェース４２４が用いる方法を示すフローチャートである。ステップ４１００では、モビリティインタフェース４２４は、送信者ｘがまもなくモビリティハンドオフの手順を開始することを示す、受信パケットに含まれる埋込表示を検出する。そして、ステップ４２００では、モビリティインタフェース４２４は、アプリケーション４２６に対して、ＨＯ.ＩＮＩＴ.ｘの通知を送信する。そして、ステップ４３００では、アプリケーション４２６は、ＨＯ.ＩＮＩＴ.ｘの受信に対してアプリケーションに特有のアクションを実行する。そして、モビリティインタフェース４２４は、ステップ４４００に示すように、送信者ｘがモビリティハンドオフの手順を終了したことを示す、受信パケット内の埋込表示を検出すると、アプリケーション４２６に対して、ＨＯ.ＦＩＮＩ.ｘ通知を送信する（ステップ４５００）。そして、ステップ４６００では、アプリケーション４２６は、ＨＯ.ＦＩＮＩ.ｘの受信に対してアプリケーションに特有のアクションを実行する。アプリケーションに特有の性質のため、上記通知を受信した時にアプリケーション４２６が具体的にステップ４３００およびステップ４６００で何を行うかは、本明細書の対象外である。あり得るアクションは、ＨＯ.ＩＮＩＴ.ｘ通知を受信すると端末ｘへの送信レートを落とし、ＨＯ.ＦＩＮＩ.ｘ通知を受信すると端末ｘへの送信レートを元に戻すことである。

上記のように、モビリティインタフェース３０４は、パケットヘッダにタイミング情報をも埋め込むことができる。この場合、受信側のモビリティインタフェース４２４は、すぐにＨＯ.ＩＮＩＴ.ｘ通知を送信する代わりに、タイミング情報を利用してＨＯ.ＩＮＩＴ.ｘ通知とＨＯ.ＦＩＮＩ.ｘ通知のスケジューリングを行うことができる。モビリティインタフェース４２４は、受信パケットヘッダにあるEmbed_Handoff_IndicationのStart_Timeフィールドにより指定された時刻においてＨＯ.ＩＮＩＴ.ｘ通知を送信することができる。また、モビリティインタフェース４２４は、受信パケットヘッダにあるEmbed_Handoff_IndicationのEnd_Timeフィールドにより指定された時刻においてＨＯ.ＦＩＮＩ.ｘ通知を送信することができる。

当業者にとって、本実施の形態に記載したデータ端末４２０が固定端末でも移動端末でもよいことは明らかである。実際、本実施の形態に記載したデータ端末４２０および移動端末３００を組み合わせて一つの装置にすることは、いたって簡単である。

したがって、本実施の形態によれば、移動端末と通信を行うデータ端末もまた、ネットワーク輻輳状況によるセッション中断と、一またはそれ以上の移動端末が関係する接続ポイントハンドオフ状況によるセッション中断とを区別することができる。このようにして、アプリケーションは、異なる状況に対して対応するアクションを採ることにより、全体的にデータ配送を向上することができる。

（実施の形態５）
上記は、移動端末がハンドオフの表示をＩＰパケットヘッダに埋め込む場合を示している。代わりに、そのような表示をトランスポートセッションヘッダに挿入することも可能である。これにより、移動端末は、ハンドオフ状況とネットワーク輻輳状況とを区別することができる。これが本発明の実施の形態５の目的である。

図１５は、本発明の実施の形態５に係る移動端末およびデータ通信端末の構成を示すブロック図である。移動端末５００は、パケット交換型データ通信ネットワークを介してデータ端末５２０と通信を行っており、移動端末５００とデータ端末５２０の間には少なくとも一つのトランスポートセッションが存在している。図１５に示す移動端末５００の構成要素はほとんど実施の形態１で説明した移動端末１００のものと同一であり、したがって、同一の構成要素には同一の参照番号を付し、その詳細な説明は省略する。移動端末５００は、一つのトランスポートレイヤ５０３を有する。このトランスポートレイヤ５０３は、信頼性のある順序付けられたデータ配送を提供するトランスポートプロトコルを実行するソフトウェアモジュールである。これは、ＯＳＩモデルにおけるトランスポート層（レイヤ４）に相当する。トランスポートレイヤ５０３内には、一つまたはそれ以上のトランスポートセッション５０５が存在し得る。各トランスポートセッション５０５は、移動端末５００とあるリモート端末との間の信頼性のある継続中の通信セッションに対応している。トランスポートセッション５０５は、通信端末のアドレス、および、各通信端末における通信セッションに関連するポート番号によって、一意に特定される。

トランスポートレイヤ５０３およびトランスポートセッション５０５と、本発明の実施の形態１に記載したトランスポートレイヤ１０３およびトランスポートセッション１０５との相違点は、トランスポートレイヤ５０３からの指示により、トランスポートセッション５０５が、ハンドオフ通知を送信パケットのトランスポートセッションヘッダに埋め込むことである。トランスポートレイヤ５０３は、モビリティインタフェース１０４からＨＯ.ＩＮＩＴ.ＬＯＣＡＬ通知を受信すると、すべてのトランスポートセッション５０５に対して、次の送信パケットのトランスポートセッションヘッダにユニークな表示を埋め込むように指示する。このユニークな表示は、トランスポートセッションヘッダの所定の位置に配置される特別のビットセットや、トランスポートセッションヘッダのオプションフィールドにおける所定値などの形を取ることができる。このような表示は、受信者に対して、送信者（つまり、移動端末５００）がまもなくハンドオフの手順を開始することを通知するのに役立つ。同様に、トランスポートレイヤ５０３は、モビリティインタフェース１０４からＨＯ.ＦＩＮＩ.ＬＯＣＡＬ通知を受信すると、すべてのトランスポートセッション５０５に対して、次の送信パケットのトランスポートセッションヘッダにユニークな表示を埋め込むように指示する。このような表示は、受信者に対して、送信者（つまり、移動端末５００）がハンドオフの手順をちょうど終了したことを通知するのに役立つ。

あるいは、トランスポートセッション５０５は、ハンドオフ開始の表示を送信するとき、トランスポートセッションヘッダに何らかのタイミング情報も挿入することができる。タイミング情報により、受信者は、いつ送信者（つまり、移動端末５００）がハンドオフに入るのかを判断することができる。これは、受信者が送信者と同一のタイムフレーム上にあるよう、ＮＴＰ（Network Time Protocol）のような標準タイムスタンプに基づいて行われ得る。このため、受信者は、いつアクションを採れば良いかを正確に知ることができる。別の有益なタイミング情報は、ハンドオフにかかるであろう推定時間である。これにより、受信者は、いつ移動端末５００が接続を回復するかの見込みを正確に知ることができる。これは、受信者が、移動端末がハンドオフを終了したことを知るのにパケット（このパケットはＩＰのようなベストエフォート型のパケット交換型ネットワークにおいてはネットワークによって破棄される場合がある）に埋め込まれた表示に頼る必要がないということを意味するため、極めて有益である。したがって、埋め込まれた表示は以下のフォーマットを取ることができる。

Embed_Handoff_Indication {
Indication_Type; /* specify the type of indication: start_handoff, or end_handoff */
Start_Time; /* time when handoff is to start */
End_Time; /* estimated time when handoff will be completed */
}
Indication_Typeは、どの種類の表示であるか、つまり、ハンドオフ開始表示か、ハンドオフ終了表示かを一意に特定する。ハンドオフ開始表示の場合は、ハンドオフが開始される推定時刻とハンドオフが終了する推定時刻とをそれぞれ示すStart_TimeとEnd_Timeのオプションフィールドが存在していても良い。

このような表示が有益であるためには、受信者が受信パケットに埋め込まれた表示を検出して適切なアクションを採ることができなければならない。本発明は、実施の形態５に係る装置であるデータ端末５２０を明記する。

図１５に示すデータ端末５２０は、一つまたは複数の下位レイヤ３２１、ＩＰレイヤ３２２、およびトランスポートレイヤ５２３から成る。データ端末５２０の構成要素はほとんど本発明の実施の形態３に記載したデータ端末３２０のものと同一である。よって、同一の構成要素には同一の参照番号を付し、その詳細な説明は行わない。主たる相違点は、データ端末５２０がモビリティインタフェースを持たないことであり、また、移動端末５００において説明したように、トランスポートレイヤ５２３のトランスポートセッション５２５が、受信パケットのトランスポートセッションヘッダに特別に埋め込まれた表示を検出するように設計されていることである。通知が検出されると、トランスポートセッション５２５は適切なアクションを採る。図１６、図１７、および図１８は、三つのそのような方法を示している。

図１６は、データ端末５２０で用いることができる一つの方法を示すフローチャートである。ステップ５１００では、トランスポートセッション５２５は、ｘで特定される端末が送信した受信データセグメントのトランスポートセッションヘッダに埋め込まれた表示を検出する。この表示は、送信者がモビリティハンドオフの手順を開始しようとしていることを示している。そして、ステップ５３００では、トランスポートセッション５２５は、（端末ｘと通信を行う）セッションに対するプロトコルパラメータの調整を一時停止する。この一時停止は、ステップ５４００において、トランスポートセッション５２５が、送信者がモビリティハンドオフの手順を終了したことを示す、ｘで特定される端末が送信した受信データセグメントのトランスポートセッションヘッダに埋め込まれた表示を検出するまで継続する。そして、ステップ５６００では、トランスポートセッション５２５は、（端末ｘと通信を行う）セッションに対するプロトコルパラメータの調整を再開する。

図１７は、データ端末５２０で用いることができる第二の方法を示す別のフローチャートである。ステップ５１００およびステップ５４００は、図１６のものと同一であるため、同一のステップには同一の参照番号を付し、その詳細な説明は省略する。ステップ５３１０では、トランスポートセッション５２５は、送信者（端末ｘ）がモビリティハンドオフを開始しようとしていることを示す、受信データセグメントのトランスポートセッションヘッダに埋め込まれた表示を検出した後、（端末ｘと通信を行う）セッションに対する輻輳制御アルゴリズムの動作を一時停止する。そして、ステップ５６１０では、トランスポートセッション５２５は、送信者（端末ｘ）がモビリティハンドオフを終了したことを示す、受信データセグメントのトランスポートセッションヘッダに埋め込まれた表示を検出した後、（端末ｘと通信を行う）セッションに対する輻輳制御アルゴリズムの動作を再開する。

図１８は、データ端末５２０で用いることができる第三の方法を示す、さらに別のフローチャートである。これは、トランスポートセッション５２５が、送信者がモビリティハンドオフを終了したことを示す埋込表示のみに対して反応する場合である。図１８におけるステップ５４００は図１６のものと同一であるため、同一の参照番号を付し、詳細な説明を省略する。ステップ５６３０では、トランスポートセッション５２５は、送信者（端末ｘ）がモビリティハンドオフを終了したことを示す、受信データセグメントのトランスポートセッションヘッダに埋め込まれた表示を検出した後、先に送信されたが応答されていないデータセグメントの再送のスケジューリングを行う。データを再送することによって、ほとんどのトランスポートプロトコルは、ネットワーク状況の探知を開始する。リモート（相手）側も、確認応答をもってこれに応じ、よって、トランスポートプロトコルに現在のネットワーク状況についてのフィードバックを与える。これにより、トランスポートプロトコルは、ハンドオフの後、再送タイマの終了を待つ必要なく、より早く正常な状態に戻ることができる。

注意すべき点は、リモート端末がハンドオフの手順を開始するということはハンドオフ中にはデータを一切送信しないということを意味するため、トランスポートセッション５２５が、リモート端末がハンドオフの手順を開始しようとしていることを検出した時に、窓サイズを小さくするのは、それほど有益なことではない。同様に、トランスポートセッション５２５が、リモート端末がハンドオフの手順を終了したことを検出した時に、二重の確認応答を送信するのもまた、それほど有益なことではない。これは、リモート端末が、ハンドオフ終了後すぐに再送を開始することが予想されるからである。

当業者にとって、本実施の形態に記載したデータ端末５２０が固定端末でも移動端末でも良いことは明らかである。実際、本実施の形態に記載したデータ端末５２０および移動端末５００を組み合わせて一つの装置にすることは、いたって簡単である。

したがって、本実施の形態によれば、移動端末と通信を行うデータ端末におけるトランスポートプロトコルは、ネットワーク輻輳状況によるセッション中断と、一つまたはそれ以上の移動端末が関係する接続ポイントハンドオフ状況によるセッション中断とを区別することが可能になる。このようにして、トランスポートプロトコルは異なる状況に対して異なる反応を示すことができ、よって、全体的にデータ配送を向上することができる。

以下は、本発明の各実施の形態に開示した顕著な特徴を要約するのに役立つ。図１９は、ハンドオーバ中に、移動端末のトランスポートレイヤ、または、トランスポートレイヤおよびアプリケーションにより開始されるアクティブなセッションのサイクルを示している。トランスポートレイヤ、または、トランスポートレイヤおよびアプリケーションの通常のアクティブセッション（ＨＭＳＣ０１）において、移動端末は、順にＨＭＳＣ０２、モビリティインタフェースを介してハンドオフを開始する。状態ＨＭＳＣ０３における、ＨＯ.ＩＮＩＴ.ＸＸで表されるメッセージは、移動端末がモビリティインタフェースを介してハンドオフが開始されたことがトランスポートレイヤ、または、トランスポートレイヤおよびアプリケーションに通知されていることを示している。上位レイヤがＨＯ.ＩＮＩＴ.ＸＸを必要としない場合、ＨＭＳＣはＨＭＳＣ０２からＨＭＳＣ０４に直接進むことができる。ＨＯ.ＩＮＩＴ.ＸＸは、通知メッセージ、つまり、実施の形態１および実施の形態２に記載したＨＯ.ＩＮＩＴ.ＬＯＣＡＬ、ならびに、実施の形態３、実施の形態４、および実施の形態５に記載したＨＯ.ＩＮＩＴ.ｘを表している。この二種類のメッセージのいずれかを受信すると、トランスポートレイヤ、または、トランスポートレイヤおよびアプリケーションは、異なるＨＯ.ＩＮＩＴ.ＬＯＣＡＬおよびＨＯ.ＩＮＩＴ.ｘの通知の例で示した上記パラグラフに記載した必要なハンドオーバ開始手順を実行する（ＨＭＳＣ０４）。

ハンドオフを終了すると、ＨＭＳＣ０５に表すように、移動端末は、モビリティインタフェースを介してハンドオフの終了通知を送信する。ＨＭＳＣ０５におけるアブストラクトメッセージタイプであるＨＯ.ＦＩＮＩ.ＸＸは、実施の形態１および実施の形態２に記載したＨＯ.ＦＩＮＩ.ＬＯＣＡＬ、ならびに、実施の形態３、実施の形態４、および実施の形態５に記載したＨＯ.ＦＩＮＩ.ｘと同等である。無事ハンドオフを終了すると、ＨＭＳＣ０８に示すように、先のパラグラフで言及したＨＯ.ＦＩＮＩ.ＬＯＣＡＬおよびＨＯ.ＦＩＮＩ.ｘメッセージにそれぞれ基づいて、トランスポートレイヤ、または、トランスポートレイヤおよびアプリケーションにおいて、いくつかの調整を実行する。例えば、ＨＭＳＣ０６およびＨＭＳＣ０７に示すようにハンドオフがタイムアウトまたは失敗となった場合は、ＨＭＳＣ０９において、トランスポートレイヤ、または、トランスポートレイヤおよびアプリケーションは、アクティブセッションを終了する。

本発明は、パケット交換型データ通信ネットワークにおける移動通信端末およびデータ通信端末に適用することができる。

本発明の実施の形態１に係る移動端末の構成を示すブロック図 本発明の実施の形態１に係る移動端末におけるモビリティインタフェースおよびトランスポートレイヤによって実行される動作を示すフローチャート 本発明の実施の形態１に係る移動端末におけるモビリティインタフェースおよびトランスポートレイヤによって実行される動作を示すフローチャート 本発明の実施の形態１に係る移動端末におけるモビリティインタフェースおよびトランスポートレイヤによって実行される動作を示すフローチャート 本発明の実施の形態１に係る移動端末におけるモビリティインタフェースおよびトランスポートレイヤによって実行される動作を示すフローチャート 本発明の実施の形態１に係る移動端末におけるモビリティインタフェースおよびトランスポートレイヤによって実行される動作を示すフローチャート 本発明の実施の形態２に係る移動端末の構成を示すブロック図 本発明の実施の形態２に係る移動端末におけるモビリティインタフェースおよびアプリケーションによって実行される動作を示すフローチャート 本発明の実施の形態３に係るデータ通信ネットワークを介して通信する移動端末およびデータ通信端末の構成を示すブロック図 本発明の実施の形態３に係るデータ端末におけるモビリティインタフェースおよびトランスポートレイヤによって実行される動作を示すフローチャート 本発明の実施の形態３に係るデータ端末におけるモビリティインタフェースおよびトランスポートレイヤによって実行される動作を示すフローチャート 本発明の実施の形態３に係るデータ端末におけるモビリティインタフェースおよびトランスポートレイヤによって実行される動作を示すフローチャート 本発明の実施の形態４に係るデータ通信ネットワークを介して通信する移動端末およびデータ通信端末の構成を示すブロック図 本発明の実施の形態４に係るデータ端末におけるモビリティインタフェースおよびアプリケーションによって実行される動作を示すフローチャート 本発明の実施の形態５に係るデータ通信ネットワークを介して通信する移動端末およびデータ通信端末の構成を示すブロック図 本発明の実施の形態５に係るデータ端末におけるトランスポートレイヤによって実行される動作を示すフローチャート 本発明の実施の形態５に係るデータ端末におけるトランスポートレイヤによって実行される動作を示すフローチャート 本発明の実施の形態５に係るデータ端末におけるトランスポートレイヤによって実行される動作を示すフローチャート モビリティインタフェースによって開始されたハンドオフ中の、アクティブなトランスポートレイヤ、または、トランスポートレイヤおよびアプリケーションセッションの間に起こり得る一連のメッセージシーケンスを示すハイレベルメッセージシーケンスチャート

符号の説明

１００、２００、３００、５００ 移動端末
１０１、３２１ 下位レイヤ
１０２、３２２ ＩＰレイヤ
１０３、３２３、５０３、５２３ トランスポートレイヤ
１０４、２０４、３０４、３２４、４２４ モビリティインタフェース
１０５、３２５、５０５、５２５ トランスポートセッション
２０６、４２６ アプリケーション
３２０、４２０、５２０ データ端末

Claims (21)

1. パケット交換型データ通信ネットワークにおける移動通信端末に用いられる装置であって、前記移動通信端末は前記データ通信ネットワークへの接続ポイントを変更することができ、前記装置は、
   前記データ通信ネットワークにアクセスするためのネットワークインタフェース、ならびに、前記ネットワークインタフェースを動作させるのに必要なソフトウェアおよびハードウェアを有する下位レイヤと、
   パケットの送受信を処理し、パケットの経路を決定するインターネットプロトコル（ＩＰ）レイヤと、
   トランスポートセッションとして知られる複数のデータフローに分割されたデータを確実にかつ順序付けて配送するトランスポートレイヤと、各トランスポートセッションは前記移動通信端末とリモート端末の間のデータ交換にかかわる、
   前記ＩＰレイヤに存在し、前記ＩＰレイヤが前記データ通信ネットワークへの接続ポイントの変更を開始するとき、および、前記ＩＰレイヤが前記データ通信ネットワークへの接続ポイントの変更を終了したとき、前記トランスポートレイヤに対して通知信号を送信するモビリティインタフェースと、
   を有する。
2. 前記トランスポートレイヤは、前記ＩＰレイヤが前記データ通信ネットワークへの接続ポイントの変更を開始する旨の前記モビリティインタフェースからの通知に応答して、トランスポートセッションに関連するプロトコルパラメータの調整を一時停止し、また、前記ＩＰレイヤが前記データ通信ネットワークへの接続ポイントの変更を終了した旨の前記モビリティインタフェースからの通知を受信したとき、トランスポートセッションに関連するプロトコルパラメータの調整を再開する、請求項１記載の装置。
3. 前記トランスポートレイヤは、前記ＩＰレイヤが前記データ通信ネットワークへの接続ポイントの変更を開始する旨の前記モビリティインタフェースからの通知に応答して、トランスポートセッションに関連する輻輳制御メカニズムの動作を一時停止し、また、前記ＩＰレイヤが前記データ通信ネットワークへの接続ポイントの変更を終了した旨の前記モビリティインタフェースからの通知を受信したとき、一時停止した輻輳制御メカニズムの動作を再開する、請求項１記載の装置。
4. 前記トランスポートレイヤは、前記ＩＰレイヤが前記データ通信ネットワークへの接続ポイントの変更を開始する旨の前記モビリティインタフェースからの通知に応答して、トランスポートセッションに関連する、より小さな受信窓サイズを広告し、また、前記ＩＰレイヤが前記データ通信ネットワークへの接続ポイントの変更を終了した旨の前記モビリティインタフェースからの通知を受信したとき、元の受信窓サイズを広告する、請求項１記載の装置。
5. 前記トランスポートレイヤは、前記ＩＰレイヤが前記データ通信ネットワークへの接続ポイントの変更を終了した旨の前記モビリティインタフェースからの通知に応答して、再送タイムアウトの発生を待たずに、トランスポートセッションにおいてデータを再送する、請求項１記載の装置。
6. 前記トランスポートレイヤは、先に確認応答が送信されている場合、前記ＩＰレイヤが前記データ通信ネットワークへの接続ポイントの変更を終了した旨の前記モビリティインタフェースからの通知に応答して、トランスポートセッションにおいて先に送信された肯確認応答を再送する、請求項１記載の装置。
7. 前記トランスポートレイヤは、先に確認応答が送信されていない場合、前記ＩＰレイヤが前記データ通信ネットワークへの接続ポイントの変更を終了した旨の前記モビリティインタフェースからの通知に応答して、トランスポートセッションにおいて受信されたデータがゼロであることを知らせる確認応答を送信する、請求項１記載の装置。
8. リモートアプリケーションとの間でデータの送受信を行い、前記トランスポートレイヤから独立した自己の輻輳制御アルゴリズムを実行するアプリケーション、をさらに有し、
   前記モビリティインタフェースは、前記ＩＰレイヤが前記データ通信ネットワークへの接続ポイントの変更を開始するとき、および、前記ＩＰレイヤが前記データ通信ネットワークへの接続ポイントの変更を終了したとき、前記トランスポートレイヤおよび前記アプリケーションに対して前記通知信号を送信する、
   請求項１記載の装置。
9. 前記モビリティインタフェースは、前記ＩＰレイヤが接続ポイントの変更を開始するとき、送信パケットに通知信号を挿入して、パケットの受信者に対し、送信者が接続ポイントの変更を開始する旨を通知し、また、前記ＩＰレイヤが接続ポイントの変更を終了したとき、送信パケットに通知信号を挿入して、パケットの受信者に対し、送信者が接続ポイントの変更を終了した旨を通知する、請求項１記載の装置。
10. パケット交換型データ通信ネットワークにおけるデータ通信端末に用いられる装置であって、前記データ通信ネットワークにおける前記データ通信端末のいくつかは前記データ通信ネットワークへの接続ポイントを変更することができ、前記装置は、
    前記データ通信ネットワークにアクセスするためのネットワークインタフェース、ならびに、前記ネットワークインタフェースを動作させるのに必要なソフトウェアおよびハードウェアを有する下位レイヤと、
    パケットの送受信を処理し、パケットの経路を決定するインターネットプロトコル（ＩＰ）レイヤと、
    トランスポートセッションとして知られる複数のデータフローに分割されたデータを確実にかつ順序付けて配送するトランスポートレイヤと、各トランスポートセッションは前記データ通信端末とリモート端末の間のデータ交換にかかわる、
    前記ＩＰレイヤに存在し、受信データパケットに請求項９記載の挿入通知信号が含まれているかを調べ、受信パケットの送信者が、自ら前記データ通信ネットワークへの接続ポイントの変更を開始することを知らせているとき、および、受信パケットの送信者が、自ら前記データ通信ネットワークへの接続ポイントの変更を終了したことを知らせているとき、前記トランスポートレイヤに対して、受信パケットの送信者のＩＤと一緒に通知信号を送信するモビリティインタフェースと、
    を有する。
11. 前記トランスポートレイヤは、前記リモート端末が前記データ通信ネットワークへの接続ポイントの変更を開始する旨の前記モビリティインタフェースからの通知に応答して、前記リモート端末と通信するトランスポートセッションに関連するプロトコルパラメータの調整を一時停止し、また、前記リモート端末が前記データ通信ネットワークへの接続ポイントの変更を終了した旨の前記モビリティインタフェースからの通知を受信したとき、前記リモート端末と通信するトランスポートセッションに関連するプロトコルパラメータの調整を再開する、請求項１０記載の装置。
12. 前記トランスポートレイヤは、前記リモート端末が前記データ通信ネットワークへの接続ポイントの変更を開始する旨の前記モビリティインタフェースからの通知に応答して、前記リモート端末と通信するトランスポートセッションに関連する輻輳制御メカニズムの動作を一時停止し、また、前記リモート端末が前記データ通信ネットワークへの接続ポイントの変更を終了した旨の前記モビリティインタフェースからの通知を受信したとき、前記リモート端末と通信するトランスポートセッションに関連する、一時停止した輻輳制御メカニズムの動作を再開する、請求項１０記載の装置。
13. 前記トランスポートレイヤは、前記リモート端末が前記データ通信ネットワークへの接続ポイントの変更を終了した旨の前記モビリティインタフェースからの通知を受信したとき、前記リモート端末と通信するトランスポートセッションにおける再送タイムアウトの発生を待たずに、前記トランスポートセッションにおいてデータを再送する、請求の範囲１０に記載の装置。
14. リモートアプリケーションとの間でデータの送受信を行い、前記トランスポートレイヤから独立した自己の輻輳制御アルゴリズムを実行するアプリケーション、をさらに有し、
    前記モビリティインタフェースは、受信パケットの送信者が、自ら前記データ通信ネットワークへの接続ポイントの変更を開始することを知らせているとき、および、受信パケットの送信者が、自ら前記データ通信ネットワークへの接続ポイントの変更を終了したことを知らせているとき、前記トランスポートレイヤおよび前記アプリケーションに対して、受信パケットの送信者のＩＤと一緒に前記通知信号を送信する、
    請求項１０記載の装置。
15. 前記トランスポートレイヤは、前記ＩＰレイヤが接続ポイントの変更を開始する旨の通知信号を前記モビリティインタフェースから受信したとき、送信パケットのトランスポートプロトコルヘッダに通知信号を挿入して、パケットの受信者に対し、送信者が接続ポイントの変更を開始する旨を通知し、また、前記ＩＰレイヤが接続ポイントの変更を終了した旨の通知信号を前記モビリティインタフェースから受信したとき、送信パケットのトランスポートプロトコルヘッダに通知信号を挿入して、パケットの受信者に対し、送信者が接続ポイントの変更を終了した旨を通知する、請求項１記載の装置。
16. パケット交換型データ通信ネットワークにおけるデータ通信端末に用いられる装置であって、前記データ通信ネットワークにおける前記データ通信端末のいくつかは前記データ通信ネットワークへの接続ポイントを変更することができ、前記装置は、
    前記データ通信ネットワークにアクセスするためのネットワークインタフェース、ならびに、前記ネットワークインタフェースを動作させるのに必要なソフトウェアおよびハードウェアを有する下位レイヤと、
    パケットの送受信を処理し、パケットの経路を決定するインターネットプロトコル（ＩＰ）レイヤと、
    トランスポートセッションとして知られる複数のデータフローに分割されたデータを確実にかつ順序付けて配送し、受信データパケットに請求項１５記載の挿入通知信号が含まれているかを調べるトランスポートレイヤと、各トランスポートセッションは前記データ通信端末とリモート端末の間のデータ交換にかかわる、
    を有する。
17. 前記トランスポートレイヤは、送信者が前記データ通信ネットワークへの接続ポイントの変更を開始することを知らせる、受信パケットのトランスポートプロトコルヘッダに挿入された通知が、トランスポートセッションにより検出されたとき、トランスポートセッションに関連するプロトコルパラメータの調整を一時停止し、また、同じ送信者が前記データ通信ネットワークへの接続ポイントの変更を終了したことを知らせる、受信パケットのトランスポートプロトコルヘッダに挿入された通知が、トランスポートセッションにより検出されたとき、トランスポートセッションに関連するプロトコルパラメータの調整を再開する、請求項１６記載の装置。
18. 前記トランスポートレイヤは、送信者が前記データ通信ネットワークへの接続ポイントの変更を開始することを知らせる、受信パケットのトランスポートプロトコルヘッダに挿入された通知が、トランスポートセッションにより検出されたとき、トランスポートセッションに関連する輻輳制御メカニズムの動作を一時停止し、また、同じ送信者が前記データ通信ネットワークへの接続ポイントの変更を終了したことを知らせる、受信パケットのトランスポートプロトコルヘッダに挿入された通知が、トランスポートセッションにより検出されたとき、トランスポートセッションに関連する、一時停止した輻輳制御メカニズムの動作を再開する、請求項１６記載の装置。
19. 前記トランスポートレイヤは、送信者が前記データ通信ネットワークへの接続ポイントの変更を終了したことを知らせる、受信パケットのトランスポートプロトコルヘッダに挿入された通知が、トランスポートセッションにより検出されたとき、再送タイムアウトの発生を待たずに、トランスポートセッションにおいてデータを再送する、請求項１６記載の装置。
20. 前記挿入通知信号は、
    前記通知が、送信者が接続ポイントの変更を開始することを知らせるものであることを一義的に示す通知タイプと、
    送信者が接続ポイントの変更を開始する推定時刻と、
    接続ポイントの変更が終了する推定時刻と、
    のフィールドを含む、請求項９記載の装置。
21. 前記挿入通知信号は、
    前記通知が、送信者が接続ポイントの変更を開始することを知らせるものであることを一義的に示す通知タイプと、
    送信者が接続ポイントの変更を開始する推定時刻と、
    接続ポイントの変更が終了する推定時刻と、
    のフィールドを含む、請求項１５記載の装置。

Images