"複数のアクセスネットワークを備えている異種モバイルネットワークに接続するモバイルノードであって、前記複数のアクセスネットワークの少なくとも1つのアクセスネットワークにおけるアクセスポイントから、前記アクセスポイントのアイデンティティについての情報を含んでいるブロードキャストメッセージを受信し、単位時間あたりに受信した前記アクセスポイントごとの前記ブロードキャストメッセージの数についての情報を取得する手段と、前記アクセスポイントから受信した前記ブロードキャストメッセージの数が所定の第1のしきい値を超えている場合、前記モバイルノードが接続している第1のアクセスネットワークに位置する第1のネットワークエンティティに対して、第2のアクセスネットワークに位置する第2のネットワークエンティティとQoS状態に関する通信を行うことを要求する手段と、を備えているモバイルノード。請求項1に記載のモバイルノードと、前記モバイルノードが接続している第1のアクセスネットワークに位置する第1のネットワークエンティティとを具備する通信システムであって、前記第1のネットワークエンティティは、前記モバイルノードに関連するコンテキスト情報を前記第1のアクセスネットワーク内の少なくとも一つのソースエンティティから収集し、前記収集したコンテキスト情報を第2のアクセスネットワークに位置する第2のネットワークエンティティに転送する通信システム。前記第1のネットワークエンティティと前記第2のネットワークエンティティとの通信は、セキュリティアソシエーションの早期確立をトリガするために実行される請求項2に記載の通信システム。複数のアクセスネットワークを備えている異種モバイルネットワークに接続するための方法であって、前記複数のアクセスネットワークの少なくとも1つのアクセスネットワークにおけるアクセスポイントから、前記アクセスポイントのアイデンティティについての情報を含んでいるブロードキャストメッセージを受信し、単位時間あたりに受信した前記アクセスポイントごとの前記ブロードキャストメッセージの数についての情報を取得するステップと、前記アクセスポイントから受信した前記ブロードキャストメッセージの数が所定の第1のしきい値を超えている場合、前記モバイルノードが接続している第1のアクセスネットワークに位置する第1のネットワークエンティティに対して、第2のアクセスネットワークに位置する第2のネットワークエンティティとQoS状態に関する通信を行うことを要求するステップと、を備えている方法。前記第1のネットワークエンティティが、前記モバイルノードに関連するコンテキスト情報を前記第1のアクセスネットワーク内の少なくとも一つのソースエンティティから収集するステップと、前記収集したコンテキスト情報を前記第1のネットワークエンティティから前記第2のネットワークエンティティに転送するステップとを、さらに具備する請求項4に記載の方法。前記第1のネットワークエンティティと前記第2のネットワークエンティティとの前記通信は、セキュリティアソシエーションの早期確立をトリガするために実行される請求項4または請求項5に記載の方法。添付の図面は、本発明の原理を説明することを目的として、本明細書に組み込まれており、本明細書の一部を形成している。これらの図面は、本発明を構築および使用する方法を図解および説明した例に、本発明を制限するものではないことを理解されたい。さらなる特徴および利点は、添付の図面に図解されている本発明の以下のさらに具体的な説明から明らかになるであろう。以下では、本発明の例示的な実施形態について図面を参照しながら説明する。図面において、同一相当の要素および構造は同一相当の参照数字によって示してある。以下では、一般性を失うことなく、コンテキスト転送プロトコルの例の場合について本発明を説明する。しかしながら、本発明は、例えばモバイルIPv6の高速ハンドオーバFasthandoversforMobileIPv6RajeevKoodliのFastHandoversforMobileIPv6IETFInternetDraftdraftietfmipshopfastmipv603txtOctober2004など、アクセスルータからアクセスルータにコンテキストを伝え、かつ両方のアクセスルータ間のSAを必要とする任意のプロトコルに適用することができる。上述したように、コンテキスト転送マネージャCTMアーキテクチャは、異種ネットワークにおいてドメイン間でコンテキストを転送する場合、特に、異なるアクセスルータ間で別のドメインへのハンドオーバが可能である場合に有利である。コンテキスト転送マネージャは、別のドメインとの単一のインタフェースを提供し、従って、ドメイン間SAの数が最小になり、コンテキストの変換、AAAサーバなど、さまざまなエンティティからのコンテキストの収集、および集合化aggregationを処理することができる。図3は、アクセスルータ間での直接的なコンテキスト転送と、コンテキスト転送マネージャを通じてのコンテキスト転送とを示している。アクセスネットワークAN1104は、AR1102と、別のAR301とを備えている。AN2105は、AR2103と、さらなるAR301とを備えている。モバイルノード101は、ネットワークのそれぞれと通信することができる。いま、MN101は、AR1を通じてAN1と通信している間に移動し、AN2のサービスエリアに入り、AN1のサービスエリアから出ようとしている。ハンドオーバが必要であり、ハンドオーバの間に、実行中のアプリケーションのコンテキストをAR1からAR2に転送しなければならない。図3aにおいては、コンテキストはAR1からAR2に直接的に転送される。ドメインAN1およびAN2の境界を超えてのアクセスルータ間のSAが要求される。それと同時に、さらなるモバイルノードのサービスに関連する、別のAR301同士の間のそのようなSAがさらに存在しうる。図3bにおいては、ドメインあたり1つのコンテキスト転送マネージャCTM302,303が、このコンテキスト転送を処理する。従って、進行中のコンテキスト転送のすべてのインスタンスに対して、AN104とAN105との間に必要なSAは1つのみである。しかしながら、コンテキスト転送プロトコルでは、コンテキスト転送マネージャの使用がサポートされない。この場合、専用のコンテキスト転送管理CTMエンティティを通じてコンテキストコンテキスト転送プロトコルの場合にはCTDメッセージをルーティングするという課題は、IP層ルーティングを使用することによって解決することができる。この手法の欠点は、下層のルーティングインフラストラクチャが影響されることと、コンテキストの集合化が不可能であることである。さらには、この場合、コンテキスト転送マネージャが処理中のコンテキストを操作できるようにするため、ルータ警告オプションが必要となる。従って、アプリケーション層ルーティングを使用する。ソースAR102は、CTARメッセージをソースCTM302に転送し、ソースCTM302が、ソースARおよびさまざまなソースエンティティ例:AAA1認証、許可、アカウンティングエンティティ1304からのコンテキストを要求する。コンテキストを操作した後、CTM302は、コンテキストを集合化CTDメッセージにおいて、アプリケーション層においてターゲットCTM303に転送し、それによりターゲットCTM303がそのコンテキストを操作することができる。最後に、ターゲットCTM303は、コンテキストを各ターゲットエンティティ例:AAA2305、AR2103に転送する。ソースCTM302は、受信したCTARメッセージからターゲットARのIPアドレスを認識する。ターゲットCTMがコンテキストをターゲットARに転送することができるように、ソースCTMは、ターゲットARのIPアドレスをターゲットCTM303に提供することが要求される。このことは、ターゲットARのIPアドレスを含んでいる新しいフィールドをCTDメッセージに追加することによって達成される。図4は、コンテキスト転送プロトコルおよびコンテキスト転送マネージャを使用してのプロアクティブ型のドメイン間コンテキスト転送の場合のシグナリングの流れを示している。ステップ400において、CTM1302およびCTM2303は、それぞれの能力についてと、それぞれのアクセスネットワークAN1104およびAN2105の能力についての情報を交換する。これらの情報には、サポートされるコンテキストフォーマットについての情報を含めることができる。図1とは異なり、AR1102は、ステップ403において受信したCTARメッセージを、ステップ404において、CTM1302に転送する。CTM1302は、ステップ405において、すべてのソースエンティティ102,401からコンテキストを集め、ステップ405において、CTDメッセージをCTM2303に転送する。このとき、CTDメッセージは、追加のフィールドとして、ターゲットAR103のIPアドレスを含んでいる。さらに、AN1およびAN2が、それぞれの無線インタフェースに異なる技術を採用している、あるいはコアネットワークまたはアグリゲーションネットワークaggregationnetworkにおけるパケット転送に異なる技術を採用している場合、ステップ412において、コンテキストの少なくとも一部を、AN1においてサポートされているフォーマットから、AN2においてサポートされている別のフォーマットに変換する。この変換は、CTDメッセージを送る前にCTM1において行う、または、CTDメッセージを受信した後にCTM2において行うことができる。CTM2は、ステップ407において、コンテキストのタイプに基づいて自身が決定する対応するターゲットエンティティ103,402に、コンテキストを転送する。ステップ408において、CTM2303は、CTDRメッセージをCTM1302に送ることによって、CTDメッセージの受信に対して肯定応答を返すことができる。ハンドオーバの後、ステップ409において、モバイルノードはCTARメッセージをAR2に送る。AR2は、ステップ410において、そのメッセージをCTM2に転送し、CTM2は、許可トークンの有効性をもう一度検証し、検証が成功した場合に、そのコンテキストを組み込むようにターゲットエンティティに知らせる。あるいは、CTM2は、トークンの有効性を検証が成功したときにのみ、コンテキストをターゲットエンティティに送ることができる。この場合、ターゲットエンティティはコンテキストをただちに組み込むことができる。なお、このCTARメッセージには、前のARのIPアドレスと、モバイルノードが前のARにアタッチされていた時点におけるモバイルノードのIPアドレスとが含まれる。最後に、ステップ411において、AR2は、コンテキスト転送のステータスについて、CTAAメッセージを送ることによってモバイルノードに知らせることができる。図5は、リアクティブ型のコンテキスト転送の場合の対応するシグナリングの流れを示している。この場合、ステップ501において、MN101からCTARメッセージをAR2103に送り、ステップ502において、AR2103は、そのメッセージをCTM2303に転送する。ステップ503において、CTM2303は、CTM1302からのコンテキスト転送をCT-Reqメッセージによって要求し、このCT-Reqメッセージは、MN101の前のAN1に登録されている間のIPアドレスと、肯定応答と要求とを一致させるためのシーケンス番号SNと、許可トークンと、転送するコンテキストのタイプとを指定している。ステップ504において、CTM1302は、すべてのソースエンティティ102,401からコンテキストを集め、ステップ505において、CTDメッセージをCTM2303に転送する。この場合には、ターゲットARのIPアドレスの追加のフィールドはCTDメッセージに必要なく、なぜなら、ターゲットCTMはモバイルノードからCTARメッセージを受信し、このメッセージにターゲットARのIPアドレスが含まれているためである。ステップ506において、CTM2は、コンテキストのタイプに基づいて自身が決定する対応するターゲットエンティティ103,402に、コンテキストを転送する。プロアクティブ型のステップと同様に、ステップ507において、CTM2303は、CTDRメッセージをCTM1302に送ることによって、CTDメッセージの受信に対する肯定応答を返すことができ、ステップ508において、コンテキスト転送のステータスについて、CTAAメッセージを送ることによってMN101に知らせることができる。プロアクティブ型のコンテキスト転送の場合と同様に、CTDメッセージによってコンテキストを送る前にCTM1において、あるいは、CTDメッセージを受信した後にCTM2において、ステップ412において、コンテキストの少なくとも一部を、要求される別のフォーマットに変換することができる。ここまで説明したプロセスでは、コンテキストを必ずCTMを通じてルーティングする。このことは、ドメイン間ハンドオーバの場合に望ましいが、ドメイン内ハンドオーバの場合には必要なく、コンテキスト転送経路が長くなるため、結果としてパフォーマンスが低下する。これを防ぐため、ハンドオーバのタイプに応じてコンテキスト転送経路を選択する。ドメイン内ハンドオーバとドメイン間ハンドオーバとを個別に扱うことによって、ハンドオーバのパフォーマンスが向上する。ドメイン間ハンドオーバの場合には、ドメイン間SAの数を最小にし、コンテキストの変換などを可能にするため、コンテキスト転送マネージャを通じた経路を使用すべきである。ドメイン内ハンドオーバの場合には、代わりに、アクセスルータからアクセスルータへのコンテキスト転送経路を使用すべきであり、なぜなら、コンテキスト転送マネージャは必要なく、アクセスルータ間の直接的な経路の方が短いためである。どちらのタイプドメイン内またはドメイン間のハンドオーバが存在しているかを、ソースARおよびソースCTMが協働して判定する。ソースARは、ターゲットARへのSAが存在する場合、コンテキスト自体を転送することができる。ターゲットARへのSAが存在しない場合、ソースARは、CTARメッセージをソースCTMに転送し、ソースCTMは、ターゲットARのIPアドレスが自身のドメインに含まれているかを単独で判定する。従って、コンテキスト転送マネージャが自身のドメインのすべてのアクセスルータのIPアドレスまたはアドレス空間を認識していることを前提とする。コンテキスト転送マネージャは、ターゲットARが自身と同じドメイン内でない場合、ドメイン間ハンドオーバが存在するものと結論し、コンテキスト自体を転送する。ターゲットARが同じドメイン内である場合、ドメイン内ハンドオーバであると想定する。この場合、コンテキスト転送マネージャは、CTARメッセージをソースARに戻すことができ、ソースARは、ターゲットARへのSAを確立してコンテキストを転送することができる。提案するこの解決策では、コンテキスト転送プロトコルのメッセージフォーマットを修正する必要はないが、アクセスルータの状態マシンを修正する必要がある。図6は、プロアクティブ型のコンテキスト転送の場合に前のARにおいて行われる上記手順のフローチャートを示している。アクセスルータは、ステップ601においてCTARメッセージを受信した後、ステップ602において、許可トークンの有効性を検証する。検証が失敗する場合、ステップ603において、アクセスルータは、エラーコードを含んでいるCTAAメッセージを送ることによってモバイルノードに知らせる。検証が成功する場合、ステップ604において、前のARは、ターゲットARへのSAが存在しているかを調べる。存在している場合ケース1、ドメイン内ハンドオーバであると想定し、ステップ605において、前のARは、CTDメッセージを使用してコンテキストを転送することができる。ターゲットARがCTDRメッセージオプションによって受信に対する肯定応答を返すまで、ステップ605およびステップ606において転送を繰り返す。ここまで説明したプロセスは、修正されていないコンテキスト転送プロトコルのプロセスとまったく同じである。ステップ604において、次のARへのSAが存在しないことが検出される場合、通常ではコンテキスト転送を取り消す。本発明において提案する修正形態では、ステップ607において、前のARが、CTARメッセージがモバイルノードから受信されたかコンテキスト転送マネージャから受信されたかを調べる。これは、例えば、CTARメッセージ内のIPソースアドレスまたは新しいフラグに基づいて判定することができる。CTARメッセージがコンテキスト転送マネージャから受信されていた場合、ドメイン内コンテキスト転送が必要であると想定し、この目的のため、ステップ609において、ソースpARからターゲットnARへのSAを確立する。CTARメッセージがモバイルノードから受信されていた場合ケース2、前のARは、ドメイン間ハンドオーバを想定し、ステップ608において、自身のコンテキスト転送マネージャにCTARメッセージを転送する。コンテキスト転送マネージャは、自身のドメイン内のすべてのアクセスルータのIPアドレスまたはアドレス空間を認識しており、従って、ドメイン内ハンドオーバが存在するのかドメイン間ハンドオーバが存在するのかを判定することができる。後者の場合、コンテキスト転送マネージャは、コンテキスト転送自体を実行する。すなわち、コンテキスト転送マネージャは、CT-reqメッセージを使用して前のARおよびその他のエンティティからコンテキストを集め、集合化CTDメッセージをターゲットCTMに送る。このCTDメッセージには、ターゲットARのIPアドレスの新しいフィールドが含まれている図4のステップ406を参照。このとき、ターゲットCTMのアドレスは、例えば、ターゲットARのIPアドレスから導くことによって、ソースCTMに既知であるものと想定する。さらには、両方のコンテキスト転送マネージャ間にSAが存在するものと想定するSAを自動的に確立する方法については後述する。ターゲットCTMは、CTDメッセージを受信すると、CTDメッセージを使用して、個々のコンテキストを対応するターゲットエンティティに転送する。このとき、特定のタイプのコンテキストに対応するターゲットエンティティのIPアドレス例:AAAコンテキストに対応するAAAサーバのIPアドレスは、例えば事前に設定することによって、あるいは例えばデータベースへの追加のシグナリングによって、ターゲットCTMに既知であるものと想定する。コンテキスト転送マネージャは、ドメイン内ハンドオーバが存在すると判定した場合、CTARメッセージを前のARに戻すことができ、前のARは、修正されていないコンテキスト転送プロトコルの場合のように、次のARへのSAを確立しステップ609、コンテキストを転送するステップ605ケース3。以上に説明した解決策は、リアクティブ型の場合にも同様に適用することができる。本発明は、コンテキスト転送マネージャの階層にも同様に適用することができる。ネットワークがマルチホーム化されている場合、特定の状況では、ソースネットワークとターゲットネットワークとの間の直接的な経路以外の経路例えば、ソースネットワークとターゲットネットワークの両方が、低帯域幅で相互接続されている外部ネットワークである場合、ホームネットワークを通じての経路の方が、トポロジ的に短いことがあり、あるいは容量capacityが大きいことがある。この場合、ソースネットワークのコンテキスト転送マネージャがコンテキストをホームネットワークを通じてターゲットCTMにルーティングするならば、パフォーマンスが高まる。最適なパフォーマンスのため、ソースCTMは、明示的なプローブメッセージを送ることによって、または該当するコンテキスト転送のメッセージを受動的に使用することによって、代替経路のコンテキスト転送の時間長を測定することができる。この情報を使用することにより、次のコンテキスト転送にとっての最良の経路を選択することができる。以下では、コンテキスト転送マネージャ間のSAを早期に確立する、および早期に取り消すメカニズムを提案する。レイヤ2識別子を含んでいるブロードキャストメッセージの受信数に基づいて、候補のコンテキスト転送マネージャを決定する。以下では、これらのメッセージをビーコンと称する。基本的な考え方として、隣接するドメインのアクセスポイントからモバイルノードが受信するレイヤ2ビーコン中の情報を使用して、コンテキスト転送マネージャ間のSAの早期確立および早期取消しをトリガする。モバイルノードは、これらのビーコン自体をカウントするか、あるいは、ネットワークに定期的にメッセージを送り、ネットワークがモバイルノードの代わりにビーコンをカウントする。カウントは単位時間あたりとして行う、すなわち、カウントは本質的には割合であり、ビーコンが受信されなくなると低減する。ビーコンカウントの状態を、アクセスポイントのMACアドレスごとに維持する。モバイルノードの信号強度により、ハンドオーバが差し迫っていることが示され、しきい値Aを超えた場合、対応するアクセスポイントに対してCARDプロトコルを開始する。さらには、CARD応答メッセージによって、対応するコンテキスト転送マネージャ間のSAの確立をトリガする。第2のしきい値Bを超えた場合、ソースCTMは、ビーコンカウントがしきい値Bを超えたアクセスポイントに対応するSAを除き、すべてのSAを取り消す。取り消せるのは使用されていないSAのみであるため、コンテキスト転送マネージャは、特定のコンテキスト転送の進行に関する何らかの状態情報を維持する必要がある。提案するしきい値の比較を使用することにより、最も可能性の高いSAが残り、リソースが無駄にならない。さらには、SAを確立することによる追加のハンドオーバレイテンシなしに、コンテキスト転送をただちに開始することができる。図7は、このプロセスを示している。ステップ704において、MN101を、アクセスネットワーク1AN1104におけるAP1102に関連付ける。ステップ705において、MN101は、AN2105におけるAP2103からと、AN3703におけるAP3702から、ビーコンを受信する。カウントステップ706において、両方のアクセスポイントのビーコンカウントがしきい値Aを超えたため、ステップ707において、CTM1とCTM2との間と、CTM1とCTM3との間とにSAを確立する。カウントステップ708において、AP2のビーコンカウントがしきい値Bを超えた後、ステップ709において、AN3へのSAを取り消す。その後、ステップ710においてAN2へのコンテキスト転送を実行するとき、SAはすでに存在しており、ステップ711において実際のハンドオーバを行うとき、AN2における各ネットワークエンティティにコンテキストがすでに組み込まれている。なお、現在のIEEE802.11仕様では、STAが関連付けられている以外のアクセスポイントが異なるチャネル/周波数においてビーコンを送信する場合、これらのビーコンを受信することができない。しかしながら、それ以外の無線技術、あるいはIEEE802.11の将来的な仕様では、このことがサポートされうる。また、アクセスポイントが異なる時間間隔でビーコンを送る場合、ビーコンカウントを比較するエンティティは、公平な比較を行う例:正規化を使用することができるように、特定のアクセスポイントに設定されている間隔を認識していなければならない。図8のフローチャートは、上記方法のステップ群をさらに詳しく示している。ステップ704において、モバイルノード/UEをAP1に関連付ける。モバイルノード/UEは、AP1に関連付けられている間、ステップ705において、他のアクセスポイントまたはアクセスルータからのビーコンを絶え間なく、または間欠的に受信する。次の2つのステップについては、2つの代替ステップが存在する。最初の代替ステップにおいては、ステップ801において、モバイルノード/UEが、受信したビーコンに関するメッセージをAP1に送り、AP1は、それらのメッセージをCTM1に転送することができる。ステップ802において、AP1またはCTM1のいずれかが、APiそれぞれについて、単位時間あたりに受信されたビーコンを個別にカウントする。このステップには、上述したように、異なるアクセスポイントのビーコン送信の割合に関する正規化を含めることができる。もう1つの代替ステップにおいては、ステップ803において、モバイルノードがカウントを行い、ステップ804において、その結果をAP1に送り、最初の代替ステップと同様に、AP1はその結果をCTM1に転送することができる。この場合にも、カウントステップには正規化演算を含めることができる。あるいは、アクセスポイントまたはコンテキスト転送マネージャにおいて正規化を行うことができる。以降のステップは、AP1またはCTM1において実行することができる。しかしながら、S709およびステップ707以外のすべてのステップは、モバイルノードにおいて実行することもできる。その場合、モバイルノードは、ステップ801またはステップ804の代わりに、コンテキスト転送マネージャにステップ707もしくはステップ709、またはその両方を実行させるメッセージをコンテキスト転送マネージャに送る。ステップ805において、AP1とは異なる特定のAPiを選択する。ステップ806において、そのAPiについて、正規化された単位時間あたりのビーコンカウントが所定の上限Aを超えているかを調べる。超えていない場合、ステップ709において、APiの無線アクセスドメインANiにおけるCTM1からCTMiへのセキュリティアソシエーションSAがもし存在するならば、そのSAが現在使用されておらず、かつ別のモバイルノードに対して使用されることが予測されない限りは、そのSAを取り消す。次いで、本方法はステップ810に進み、処理すべきさらなるアクセスポイントが存在しているかを調べる。存在している場合、ステップ811において、次のAPiを選択し、そのAPiに対して、ステップ806以降を繰り返す。ステップ805~ステップ811のそのインスタンスにおいてすべてのアクセスポイントを処理したら、本方法はビーコンの受信ステップ705に戻る。ステップ806をもう一度参照し、APiの正規化された単位時間あたりのビーコンカウントが上限Aを超える場合、ステップ808において、任意の他のAPjの正規化された単位時間あたりのビーコンカウントが、上述した上限Bを超えるかを調べる。あるいは、このとき、Bの値とは異なる別の上限値Cを選択することができる。ステップ808の条件が満たされない場合、本方法は、さきのAPiがハンドオーバの候補である可能性が高いと結論し、ステップ707において、ハンドオーバの場合におけるコンテキスト転送を処理するためのSAとして、ANiにおけるCTM1からCTMiへのSAがまだ存在していなければ、このSAを確立する。このようにして、ハンドオーバを完了するのに要する時間が短縮される。ステップ808をもう一度参照し、正規化された単位時間あたりのビーコンカウントが上限BまたはCそれぞれを超える少なくとも1つのAPjが見つかった場合、別の強力なハンドオーバ候補が存在すると結論する。上限Bが、APiの正規化された単位時間あたりのビーコンカウントとは無関係の固定値として定義されている場合には、ステップ809において、APiの正規化された単位時間あたりのビーコンカウントも上限Bを超えているかを調べる。超えている場合、APiおよびAPjの両方が強力なハンドオーバ候補であると判定し、本方法はステップ707に進み、CTM1からCTMiへのSAがまだ存在していなければ、このSAを確立する。APiの正規化された単位時間あたりのビーコンカウントが上限Bを超えていない場合、APjの方がAPiよりもずっと強力なハンドオーバ候補であることと、次のハンドオーバにおいてCTM1からCTMiへの既存のSAは必要ないこととを結論する。従って、そのようなSAが存在するならば、そのSAが現在使用されておらず、かつ別のモバイルノードに対して使用されることが予測されない限りは、ステップ709において、そのSAを取り消す。このことは、シグナリングオーバヘッドコンテキスト転送マネージャにおける処理電力を必要とし、ネットワークの負荷につながるが低減するという利点を有する。ステップ808がYESである場合をもう一度参照し、上限Bが、APiの正規化された単位時間あたりのビーコンカウントよりも特定の値だけ大きい値として定義されている場合、チェックステップ809は不要であり、本方法は、ステップ709に直接進む。いずれの場合も、本方法は、次いでステップ810に進み、上述したように、処理すべき別のAPiが存在するかを調べる。1つの代替形態においては、ステップ809における上限を、ステップ808における上限BまたはCそれぞれとは異なる値Dとして選択することができる。それぞれ異なる上限B、C、Dを選択することにより、ハンドオーバの時間短縮とシグナリングオーバヘッドの低減との間の最適な妥協点が達成されるように、SAの平均生存時間を調整することが可能となる。アクセスポイントまたはアクセスルータAPiへのハンドオーバの可能性に応じて、コンテキストを転送する、あるいはデータトンネルをプロアクティブに確立するなど、さらなるアクションをトリガするためのさらなるしきい値を定義することができる。コンテキスト転送マネージャ302,303は、上述した機能を実行するロジックエンティティである。これらのマネージャは、物理的には、専用サーバ内、ネットワークノード例:ゲートウェイ内、またはその他のネットワークエンティティ例:AAAサーバ304,305内に配置することができる。図9は、上述したコンテキスト転送マネージャCTMとして使用できるサーバ900の例示的な構造を示している。このサーバは、少なくとも1つのネットワークインタフェース902と、中央処理ユニット901と、不揮発性データストレージ903とを備えている。CPU901は、プロセッサまたはコントローラと、作業メモリRAMとを備えている。CPU901は、上に詳しく説明したコンテキスト転送マネージャのタスクを実行するように構成されている。上述した方法におけるコンテキスト転送マネージャのタスクは、ハードウェアロジックに実装する、またはCPUのプロセッサまたはコントローラにおいて実行されるソフトウェアに実装することができる。混合型の実装形態も可能である。上述した方法のステップ群をサーバ900に実行させる命令を含んでいるプログラムは、不揮発性メモリ903に格納しておくことができ、このメモリは、ハードディスク、光ディスク、磁気テープ、または不揮発性半導体メモリ例:フラッシュメモリとすることができる。サーバ900は、図に示した以外のユニットとして、キーボードやディスプレイ、さらなるネットワークインタフェースなどをさらに備えていることができ、これらは、上述したコンテキスト転送マネージャのタスクにとって必須ではなく、従ってオプションである。サーバ900は、ネットワークノードと同じ場所に配置する、または個別のエンティティ中に用意することができる。"