JPWO2010010693A1 - 垂直ハンドオフ方法、垂直ハンドオフシステム、ホームエージェント及びモバイルノード - Google Patents

Abstract

モバイルノードが静的な垂直ハンドオフの規則を有する場合には、垂直ハンドオフを要求するシグナリングのパケットサイズを減少する技術が開示され、その技術によればＰＭＩＰｖ６ドメイン５１１と通信可能なＩｆ１と、ＷｉＭＡＸ−Ｉｆ２とＷＬＡＮ−Ｉｆ３を有するＭＮ５００がＰＭＩＰｖ６ドメイン５１１内をローミングして、ＷｉＭＡＸ−Ｉｆ２又はＷＬＡＮ−Ｉｆ３が選択的にＷｉＭＡＸ又はＷＬＡＮに新しく接続する場合に、Ｉｆ１に関連するプリフィックスＰ１をＷｉＭＡＸ−Ｉｆ２とＷＬＡＮ−Ｉｆ３に移すことなく、前に接続していたＷｉＭＡＸ−Ｉｆ２又はＷＬＡＮ−Ｉｆ３から新しく接続するＷｉＭＡＸ−Ｉｆ２又はＷＬＡＮ−Ｉｆ３に一義的に移すプリフィックスＰ２をＬＭＡ／ＨＡ５１２に設定して、ＭＮ５００が送信する垂直ハンドオフのトリガメッセージ内にＩｆ２、Ｉｆ３のＩＤを含まないようにする。

Description

本発明は、複数のインタフェースを有するモバイルノードがローミングする場合に、モバイルノードのあるインタフェースに関連するプリフィックスを他のインタフェースに移す垂直ハンドオフ方法及び垂直ハンドオフシステムに関する。
本発明はまた、上記のモバイルノード及びそのホームエージェントに関する。

現在、多くの通信装置がＩＰｖ６（Internet Protocol version 6）を用いて通信を行っている。また 、モバイル装置に対してモビリティサポートを提供するために、ＩＥＴＦ（Internet Engineering Task Force）は、非特許文献１に示すようなＭＩＰｖ６（Mobility Support in IPv6）を開発している。非特許文献１におけるモビリティサポートは、ホームエージェント（ＨＡ）と呼ばれるエンティティをモバイルノード（ＭＮ）のホームネットワークに導入することにより実現している。ＭＮはＨＡに対し、外部リンクで取得した気付アドレス（ＣｏＡ）を、バインディング・アップデート（ＢＵ）メッセージと呼ばれるメッセージを用いて登録する。ＨＡはＢＵメッセージにより、ホームリンクで取得したアドレスであるホームアドレス（ＨｏＡ）とＭＮのＣｏＡの間にバインディング（位置情報）を生成することができる。ＨＡはバインディングにより、ＭＮのＨｏＡあてのメッセージをインタセプトし、ＭＮのＣｏＡあてのパケットにカプセル化して転送する。なお、このパケットカプセル化は、受信したパケットを新しいパケットのペイロードにセットする処理であり、パケットトンネル化として知られている。なお、ＭＩＰｖ６はＣｌｉｅｎｔであるＭＮがモビリティ管理を行うプロトコルであるため、ＣＭＩＰｖ６（Client Mobile IPv6）やＨＢＭ（Host Based Mobility）とも呼ばれる。

ＭＩＰｖ６における問題の１つは、ネットワーク接続（attachment）が変更するとき毎や、バインディングの有効期間が満了するときに、ＭＮがその１以上のＨＡと通信相手（Correspondent Node：ＣＮ）に対する登録を更新する必要があることにある。この更新により、高速で移動するＭＮが無線ネットワークに放出するシグナリングの負荷が増大する。さらに、ネットワーク接続（attachment）の変更毎にＣＮとの間で行うハンドオフ確立時間（経路最適化が使用されているとする）は、ネットワーク接続（attachment）の変更毎にＲＲ（Return Routability）メッセージとＢＵメッセージの送受信が必要となるため、多くの時間を要する。このため、フロー又はコネクションに関連するセッションの間、ハンドオフ確立にかなりの時間を要するので、ジッタやパケットロスが発生する。このようなジッタは、ＶｏＩＰ（Voice over IP）や、マルチメディア及びビデオストリーミングのようにリアルタイムなアプリケーションにとっては好ましくない。さらに、パケットロスは、重要なテキストやデータの情報を伝送するフローにとっては好ましくない。パケットロスはさらに、ＴＣＰ（Transmission Control Protocol）が重要なデータ、アプリケーションの転送に使用される場合、ＴＣＰのスループットを減少させる。

ＭＩＰｖ６の問題に注目すると、焦点は現在、ネットワークベースのローカル・モビリティ管理（Network-based Local Mobility-Management：ＮｅｔＬＭＭ）プロトコルにシフトされる。ＩＥＴＦのＮｅｔＬＭＭワーキンググループは、このプロトコルの作業を行っている。ネットワークベースのローカル・モビリティ管理は、地理的にローカルなネットワーク・セグメントに位置するＭＮのモビリティを、ＭＮそれ自体よりもネットワーク・エンティティにより管理することに言及している。

ＭＮにとって透過的なネットワークベースのローカル・モビリティ管理の目的を達成するために、ＭＮはローカルドメイン内のどこでも同じプリフィックスを参照することを必要とする。上記のプリフィックスは、ルーティング階層の上位に位置するルータから取得されなければならない。そのルータは望ましくは、ローカル・モビリティ管理の利点が取得可能なようにローカルドメイン内の全てのＭＮのデフォルト・ルーティングパスに位置する。上記のルータは、上記のプリフィックスのルートであって、上記のプリフィックスに対する到達性の情報すなわちルーティング情報（プリフィックスベースのルート）を有しなければならない。結果的に、このプリフィックスベースのルートは、ネットワーク・エンティティにより生成されなければならない。

ＮｅｔＬＭＭワーキンググループにより検討されている特別なネットワークベースのローカル・モビリティ管理プロトコルは、非特許文献２に開示されているＰＭＩＰｖ６（Proxy Mobile Internet Protocol version 6）である。ＰＭＩＰｖ６のプロトコルは主に、ＣＭＩＰｖ６（Client Mobile IPv6）スタックを有しない通常のＩＰｖ６ホストに対して、ネットワークのローカルな部分におけるモビリティ管理サービスを提供するために設計されており、ＮＢＭ（Network based Mobility）とも呼ばれる。にもかかわらず、ＰＭＩＰｖ６はＣＭＩＰｖ６スタックを有するノードにも有用である。その理由について説明すると、ＣＭＩＰｖ６スタックを有するＭＮが外部のＰＭＩＰｖ６ドメインに位置していて、そのローカルドメイン内のあるインタフェースを介して同じプリフィックス（外部のローカル・モビリティ・アンカー（ＬＭＡ）／ＨＡにおいてルーティングされる外部のＰＭＩＰｖ６ローカル・プリフィックス）を参照する場合、そのＭＮは如何なるグローバルな登録も実行する必要がない。さらに、上記のＣＭＩＰｖ６スタックを有するＭＮは、ホームドメイン内にローミングしたとき、地理的な位置を変更しているにもかかわらず、自身のホームネットワーク・プリフィックスを継続して参照して位置登録に参加する必要がない。なお、ＬＭＡとは、ＰＭＩＰv６を使用するＭＮの位置情報を管理するノードであり、その位置情報は後述するモバイル・アクセス・ゲートウェイ（ＭＡＧ）から登録される。また、ＬＭＡ／ＨＡとは、ＰＭＩＰｖ６におけるＬＭＡの機能とＭＩＰｖ６におけるＨＡの機能の両方を有するネットワークノードを指す。

以下に、非特許文献２に開示されているＰＭＩＰｖ６の概略を説明する。あるＭＮがあるＰＭＩＰｖ６ネットワークに接続（attach）したとき、そのＭＮは、モバイル・アクセス・ゲートウェイ（ＭＡＧ）とアソシエート中に、自身のネットワーク・アクセス識別子（ＮＡＩ）を提供する。ＭＡＧとは、ＭＮが直接に接続（attach）しているか又はＭＮが制御下にあるローカル・モビリティ・アンカー（ＬＭＡ）に対して、ＭＮのプロキシとしてローカルな登録を実行するルータ（プロキシノード）である。ＮＡＩは接続認証（Authentication）の目的のために、ＡＡＡ（Authentication, Authorization and Accounting）サーバに転送される。ＡＡＡサーバは、ＭＮのネットワーク接続（attachment）を資格認証（Authorize）すると、接続認証（Authentication）が成功したことをＭＡＧに通知するためにレスポンスを送り返す。上記のレスポンスでは、ＡＡＡサーバはさらに、ＬＭＡアドレスと、ＭＮがローカルドメイン内をローミング中に備える必要があるアドレス構成モード又は特別なポリシーのような幾つかのＭＮプロファイルを提供する。

ＭＡＧは上記のＭＮのパラメータを取得すると、プロキシＢＵ（ＰＢＵ）メッセージをＬＭＡに送信する。ＭＡＧはＰＢＵメッセージの応答であるプロキシ・バインディング確認（ＰＢＡ）メッセージから、ＭＮの接続（attach）しているインタフェースに関連するプリフィックスを取得した後、ホームリンク及びローカルホームリンクをエミュレートする。上記のようにＭＡＧが実行するＰＢＵメッセージすなわちローカルな登録は、このメッセージがＰＢＵメッセージであることを示すフラグのみを除いてＭＩＰｖ６のＢＵメッセージと同一である。ＰＢＵメッセージを実行することにより、ＭＮの到達性のステートがＬＭＡにおいて生成される。基本的には、ＬＭＡは、ＰＭＩＰｖ６ドメインで取得されたＭＮプリフィックスに対する到達性のステートを有し、このＭＮプリフィックスに対して到達可能なアドレスはＭＡＧのアドレスである。

ＭＮはステート有り又はステート無しのアドレス構成モードを用いて、ＰＭＩＰｖ６ドメインで受信したプリフィックスを用いてアドレスを構成する。各ＭＮはユニークなプリフィックスを取得するので、ＬＭＡにおけるプリフィックスベースのキャッシュは、ＭＮに十分に到達する。ＬＭＡに到着した各データパケットは、ＭＮに接続（connect）しているＭＡＧにトンネル化され、また、ＭＡＧに到着した各データパケットはＬＭＡにトンネル化される。ＭＡＧの近隣（neighbor）キャッシュテーブルは、ＭＮのＰＭＩＰｖ６ローカルアドレスと、ＭＮにパケットを伝送するのに使用されるリンク層アドレスをバインディングする。

非特許文献２に開示されているＰＭＩＰｖ６のプロトコルは、ＭＮに対して透過的なプロキシ・モビリティのサービスを提供するのに加えて、マルチホーミングのサービスを提供している。非特許文献２に記載されているマルチホーミング・サービスでは、複数のインタフェースを有するＭＮが全てのインタフェースを経由してＰＭＩＰｖ６ドメインに接続（attach）でき、また、レイヤ３のプロトコルを変更することなく、かつモビリティに関するシグナリングに参加することなくＰＭＩＰｖ６ドメイン内をローミングできる。基本的に、非特許文献２の現在のドラフトに記載されている方法では、マルチホーミングをサポートするために、ＬＭＡがＭＮのインタフェース毎にユニークなプリフィックスを与え、また、ＬＭＡがＭＮのインタフェースに関連するＰＭＩＰｖ６バインディングを個々のモビリティ・セッションとして維持する。ＰＭＩＰｖ６のマルチホーミングのプロトコルが保証すべきことは、複数のインタフェースを有するＭＮがローミングするときに、インタフェース毎に最初の接続（attach）中にユニークなプリフィックスを割り当てることと、完全に透過的なプロキシ・モビリティ管理サービスを提供するためには、上記のプリフィックスと、上記のプリフィックスを使用して確立されるセッションを、セッション品質を損なうことなく維持することである。

ここで、モビリティと、セルのレイアウト構造と、ＭＮの希望と、ＭＮの節電モード動作により、２つのハンドオフのイベントがある。１つ目は、ＭＮの特定のアクセス技術タイプのインタフェースがあるＭＡＧから切断（disconnect）し、そのインタフェースが移動して新しいＭＡＧに再接続（re-connect）する水平ハンドオフである。水平ハンドオフしているプリフィックスに関連するフローのセッションの連続性を維持するためには、ＭＮが水平ハンドオフ後に新しいＭＡＧに接続（attach）するときに同じプリフィックスを参照することが重要である。水平ハンドオフのイベントでは、ＬＭＡは同じプリフィックスを割り当てるために、次のＭＡＧ（新しいＭＡＧ）からのＰＢＵメッセージ内のインタフェース識別子又はアクセス技術タイプ（ＡＴＴ：Access Technology Type）と、ＰＢＵメッセージ内のハンドオフ識別子ＨＩ（＝３）のオプションを使用してもよい。このインタフェース識別子は、水平ハンドオフしているインタフェースの識別子か、又は新しいＭＡＧに接続（connect）中のインタフェースの識別子である。また、ＡＴＴは、接続するインタフェースの種類（セルラ、ＷｉＭＡＸ、ＷＬＡＮなど）を表す。一方、ハンドオフ識別子ＨＩは、指定する値によって、アドレスを維持するハンドオーバ接続であるか、アドレスを維持しない新規接続であるかなどを示すことができる。ここで重要な点は、水平ハンドオフの処理があまり複雑ではないことを理解すべきである。その理由は、ＬＭＡが、水平ハンドオフ中の新しいＰＢＵメッセージ内のインタフェース識別子又はＡＴＴを取得し、そのインタフェース識別子又はＡＴＴと同じ値を含むエントリをキャッシュ内で検索することにより同じプリフィックスを与えることができ、セッションの連続性が維持されるからである。また、ハンドオフ識別子ＨＩの値がハンドオーバであることを示す場合には、ＬＭＡは、自身が保持するＭＮに関する情報や、認証サーバやＭＮ情報管理サーバから取得した情報の中から、ＭＮに割り当てられているプレフィックスの情報を参照し、そのプレフィックスを再度ＭＮへ割り当てるべきと判断することができる。

しかしながら、ＬＭＡは理想的には、水平ハンドオフ用として上記のＨＩオプションを必要としない。その理由は、ＬＭＡが、新しいＭＡＧに接続（attach）しているインタフェースの識別子をキャッシュ内に存在するインタフェース識別子と単にマッチングするだけで水平ハンドオフを処理できるからである。非特許文献２には、水平ハンドオフをサポートするために複数の方法が示されている。しかし、水平ハンドオフをサポートする１つの方法は、その方法を他の方法に制限する必要はない。

次に、水平ハンドオフをサポートするために非特許文献２に記載されている幾つかの方法について簡単に説明する。もし、水平ハンドオフ中に参照される必要があるプリフィックスが新しいＰＢＵメッセージ内に添付されている場合、ＬＭＡは、そのプリフィックスに対するバインディングと、新しいＭＡＧに接続（connect）したインタフェース識別子と、ＮＡＩがキャッシュ内に存在するかをチェックする。もし存在する場合、ＬＭＡはＰＢＡメッセージで同じプリフィックスを割り当てる。

ところが、大抵の場合、水平ハンドオフを実行する際には、水平ハンドオフ後に参照するプリフィックスは、水平ハンドオフを実現するＰＢＵメッセージ内に添付する必要がない。水平ハンドオフ中のセッションの継続性を実現するためには、ＭＮは、プリフィックスなしでも、インタフェース識別子（Ｉｆ−ＩＤ）のオプションと、アクセス技術タイプ（ＡＴＴ：Access Technology Type）とＮＡＩを通知するだけで十分だからである。この場合、水平ハンドオフは、ＬＭＡが新しいＰＢＵメッセージ内のパラメータ（上記の新しいＭＡＧに接続（attach）したＩｆ−ＩＤ、ＡＴＴ及びＮＡＩ）と一致するパラメータを持つエントリが存在するか否かをチェックすることにより実行される。ＬＭＡが同じパラメータを持つエントリをキャッシュ内に発見した場合、そのキャッシュは、新しいＰＢＵメッセージ内の新しいエントリで更新される。ＬＭＡにおけるキャッシュ内の唯一の変更点は、ＰＢＵメッセージの気付アドレス（ＣｏＡ）が新しいＭＡＧに関連するＣｏＡに変更されることにある。この水平ハンドオフの詳細な動作は非特許文献２に記述されている。

ＭＮが実行するもう一つのタイプのハンドオフとして垂直ハンドオフ（Vertical hand-off）がある。非特許文献２に開示されている基本のドラフトには、１つの特定のタイプの垂直ハンドオフが記述されている。このタイプの垂直ハンドオフでは、ＭＮの特定のアクセス技術タイプ（ＡＴＴ）のインタフェースがあるＭＡＧから切断（disconnect）して、その切断したインタフェースに関連するフローが、電源がオンになってＰＭＩＰｖ６接続（attach）する別のアクセス技術タイプのインタフェースに移される。このタイプの垂直ハンドオフは多くの理由により発生することができる。その理由は、特定のアクセス技術タイプのドメインがカバーする範囲が不足していたり、ＭＮの希望であったり、ＭＮがあるインタフェースを節電のためにシャットダウンしたいからである。

水平ハンドオフ（horizontal hand-off）と比較して垂直ハンドオフが複雑な点は、ＬＭＡが垂直ハンドオフ用の正しいプリフィックスを与えるためには、ＭＮの別のインタフェースから行われる接続手続き（attach procedure）の中で提示されるパラメータが十分でないことにある。ここでの新しい接続（attachment）のパラメータとは、ＭＮの新しく電源がオンになったインタフェースのＩｆ−ＩＤ及びＡＴＴと、ＮＡＩとを意味する。ＭＮの複数のインタフェースが、ＬＭＡに接続（attach）しているＰＭＩＰｖ６バインディングを有する場合、垂直ハンドオフを実現するＰＢＵメッセージには、新しいインタフェースにハンドオフされるのに必要なプリフィックスか、又はシャットダウンするインタフェースのＩｆ−ＩＤを添付する必要がある。この理由は、ＬＭＡがどのプリフィックスが新しいインタフェースに移されるかを知得する必要があるからである。したがって、ＬＭＡに対し、シャットダウンするインタフェースを指示する情報を垂直ハンドオフ動作中に送信する必要がある。この情報は特に、同じＭＮの２つ以上のＰＭＩＰｖ６バインディングがＬＭＡに存在する場合に重要である。

ここで、ＭＮの接続（attach）しているインタフェースのパラメータ（上記の新しいＭＡＧに接続（attach）したＩｆ−ＩＤ、ＡＴＴ及びＮＡＩ）が十分な場合、つまり水平ハンドオフの場合は、通常のＰＭＩＰｖ６動作により実現可能である。したがって、水平ハンドオフを実現するためには、水平ハンドオフの接続（attachment）中にはさらに特別な情報（シャットダウンするインタフェースのＩＤ又は垂直ハンドオフで移動するプレフィックス／フローなど）は必要なく、問題はないことがわかる。

３ＧＰＰ（Third Generation Partnership Project）は、例えばワイヤレス・ローカルエリア・ネットワーク（ＷＬＡＮ）と、セルラネットワーク（第３世代（３Ｇ）、第３．９世代、第４世代、さらにはそれ以降の世代のセルラネットワーク）と、ＷｉＭＡＸ形式のワイヤレスのワイドエリア・ネットワーク（ＷＡＮ）のような種々の形式の無線アクセスネットワークを有するグローバルな異種ネットワーク構造について作業を行っている。なお、以下では３Ｇや３ＧＰＰが付加されている用語をいくつか用いているが、本明細書においてそれらはセルラであることを指しており、３Ｇに限らず、３．９Ｇや４Ｇ、さらにはそれ以降の世代を含むものとして用いている。グローバルな異種ネットワーク構造は、シームレスなモビリティを実現して、リアルタイムなビデオ、ＶｏＩＰ（Voice over IP）、情報、重要なデータなどの異種のアプリケーションサービスを高いサービス品質（Quality of Service）でサポートするのに有用である。非特許文献３には、ＰＭＩＰｖ６が３ＧＰＰローカルドメインにおけるローカル・モビリティ管理（ＬＭＭ）プロトコルとして採用されるであろうことが開示されている。３ＧＰＰローカルドメインは、３Ｇセルラネットワークと、信頼性のある又は信頼性のないＷＬＡＮアクセスネットワークと、ＷｉＭＡＸアクセスネットワークにより構成されるかもしれない。さらに、複数の異種のインタフェースを有するＭＮが３ＧＰＰローカルドメインをローミングして、種々の形式のインタフェースを介して同時接続（attach）してマルチホーミングを実現する必要がありそうである。また、他の従来技術としては、下記の特許文献１、２、３に開示されているものがある。

Yoshihiro Oba, "Mobility architecture using pre-authentication, pre-configuration and/or virtual soft-handoff", US Patent No. US 7,046, 647, B2, May 16, 2006. Raziq Yaqub, "Dynamic use of multiple IP network interfaces in mobile devices for packet loss prevention and bandwidth enhancement", US Patent No. US 20070140256A1, June 21, 2007. George Tsirtsis, et.al., "Wireless terminal methods and apparatus for establishing connections", US Patent No. US 20070081521A1, April 12, 2007.

Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. Gundavelli, S., et. al., "Proxy Mobile IPv6", Internet Engineering Task Force (IETF) Working Group Draft: draft-sgundave-mip6-proxymip6-02.txt, March 5, 2007. "3GPP System Architecture Evolution: Report on Technical Options and Conclusion", 3GPP TR 23.882, V1.12.0, October 2007.

図１２Ａ、図１２Ｂ、図１２Ｃ、図１２Ｄを参照して垂直ハンドオフの各種のケースについて詳しく説明する。図１２Ａ、図１２Ｂ、図１２Ｃ、図１２Ｄには４つのケースの垂直ハンドオフ動作が示されている。図１２Ａ、図１２Ｂに示す２つのケースは、ＭＮ１０Ａ、１０Ｂが共に２つのインタフェースＩｆ１、Ｉｆ２を有していて垂直ハンドオフを実行する場合を示し、図１２Ｃ、図１２Ｄに示す２つのケースは、ＭＮ１０Ｃ、１０Ｄが共に３つのインタフェースＩｆ１、Ｉｆ２、Ｉｆ３を有していて垂直ハンドオフを実行する場合を示す。

（ａ）まず、図１２Ａに示すケースの垂直ハンドオフについて説明する。ＭＮ１０Ａは、初期状態ではインタフェースＩｆ１のみがアクティブであって、リンク１７Ａ及びＭＡＧ１１Ａを経由してＬＭＡ／ＨＡ１３ＡにルーティングされるＰＭＩＰｖ６ドメインに接続（connect）されているものとする。次に、ＭＮ１０ＡがインタフェースＩｆ１をシャットダウンして、インタフェースＩｆ２の電源をオンにして垂直ハンドオフを実行するものとする。また、Ｌ２接続（attachment）か、又はルータ・ソリシテーションか又は他の手段によって、インタフェースＩｆ２がリンク１５Ａを経由して新しく接続（attach）するＭＡＧ１２Ａに対してこの垂直ハンドオフ指示が通知されるものとする。したがって、ＭＮ１０Ａが垂直ハンドオフ・ステートをＭＡＧ１２Ａに通知するものとする。

ここで理解すべき重要な点は、ＭＮ１０ＡがＭＡＧ１２Ａに接続（attach）するときに垂直ハンドオフがトリガされることにある（垂直ハンドオフ・トリガメッセージ１４Ａ）。さもなければ、インタフェースＩｆ２がＭＡＧ１２Ａを介してＬＭＡ／ＨＡ１３Ａに接続（attach）されているときに新しいプリフィックスが割り当てられてしまう。その理由は、ＬＭＡ／ＨＡ１３ＡがＭＮ１０Ａの希望（インタフェースＩｆ２を経由した垂直ハンドオフか又は新しい接続（attachment）か）を正確に知得しないからである。垂直ハンドオフのトリガメッセージ１４Ａで送信される唯一のパラメータがハンドオフ識別子（図のMN trigger→HI=2）である。トリガメッセージ１４Ａに続いて、ＬＭＡ／ＨＡ１３Ａは、ＭＡＧ１２Ａから送信されるＰＢＵメッセージ（不図示）で垂直ハンドオフの情報（ＨＩオプション＝２と、インタフェースＩｆ２に関連するインタフェース識別子のオプション）を受信する。

ＬＭＡ／ＨＡ１３Ａは、ＰＢＵメッセージを受信すると、インタフェースＩｆ１用としてＭＡＧ１１Ａに与えていたプリフィックスＰ１をインタフェースＩｆ２に割り当てる。ＭＡＧ１２Ａは、ＬＭＡ／ＨＡ１３ＡからのＰＢＡメッセージ（不図示）でプリフィックスＰ１を受信すると、プリフィックスＰ１をＲＡメッセージか又は何かのＡＣＫ信号のようなシグナリング１６ＡでインタフェースＩｆ２に送信する（図のResponse→(P1)）。

ここで理解すべき重要な点は、２つのインタフェースＩｆ１、Ｉｆ２を有するＭＮ１０Ａが垂直ハンドオフを実行する場合、ＬＭＡ／ＨＡ１３Ａにとって、正しいプリフィックスＰ１を垂直ハンドオフ中に割り当てるための情報としては、ハンドオフのトリガオプションすなわちＨＩオプションで十分であることにある。その理由は、ＭＡＧ１２Ａからの垂直ハンドオフ要求のオプションがＬＭＡ／ＨＡ１３Ａに到着したときのＬＭＡ／ＨＡ１３Ａのエントリが１つのみであるので、ＬＭＡ／ＨＡ１３Ａが垂直ハンドオフをインタフェースＩｆ２経由で要求されたときに、この１つのみのエントリに関連するプリフィックスＰ１を移す必要があると確信するからである。

（ｂ）図１２ＢはＭＮ１０ＢがインタフェースＩｆ１をシャットダウンして、そのフローを現在存在するインタフェースＩｆ２に移す場合を示す。インタフェースＩｆ２はこのシステムに既に接続（attach）されており、プリフィックスＰ２が割り当てられている。一方、インタフェースＩｆ１にはプリフィックスＰ１が割り当てられている。ここで図１２Ａと同様に、ＭＮ１０ＢがＭＡＧ１１Ｂ及びリンク１７Ｂから切断（disconnect）して（インタフェースＩｆ１をシャットダウンして）、リンク１５Ｂ及びＭＡＧ１２Ｂに既に接続（attach）しているインタフェースＩｆ２を経由して垂直ハンドオフを実行するものとする。ＭＡＧ１２Ｂは、インタフェースＩｆ２からの垂直ハンドオフのトリガメッセージ１４Ｂ（図のMN trigger→HI=2）を受信すると、ＬＭＡ／ＨＡ１３Ｂに送信する新しいメッセージ又はＰＢＵメッセージ（不図示）内にＨＩオプションを挿入する。このメッセージはまたインタフェースＩｆ２の識別子を含んでいてもよい。

ＬＭＡ／ＨＡ１３Ｂは、このメッセージを受信すると、インタフェースＩｆ２のＰＭＩＰｖ６バインディングに加えて、インタフェースＩｆ１に関連するバインディングが１つのみ存在するか否かをチェックして、１つのみの場合にプリフィックスＰ１をインタフェースＩｆ２に移す。基本的に、インタフェースＩｆ２のＰＭＩＰｖ６バインディングは、２つのプリフィックスＰ１、Ｐ２用のものを含む。ＬＭＡ／ＨＡ１３Ｂは、垂直ハンドオフのトリガの応答としてＡＣＫ信号（不図示）をＭＡＧ１２Ｂに送信する際にプリフィックスＰ１、Ｐ２を通知する。したがって、ＭＡＧ１２ＢはインタフェースＩｆ２に対して、プリフィックスＰ１、Ｐ２の両方を含む応答メッセージ１６Ｂ（図のResponse→(P1,P2)）を送信する。これが垂直ハンドオフの新しい想定例である。このような動作が発生する場合とは、ＭＮ１０Ｂがあるインタフェースを節電のためにシャットダウンして、そのフローを現在存在する他のインタフェースに移すときである。また、インタフェースＩｆ１が再びＭＡＧ１１Ｂ及びリンク１７Ｂに接続した際に、インタフェースＩｆ１から垂直ハンドオフを実行して、プリフィックスＰ１をインタフェースＩｆ１へ戻す場合には、インタフェースＩｆ１から送信する垂直ハンドオフのトリガメッセージ（不図示）の中には、移動するプリフィックスを指定するためにプリフィックスＰ１が存在し、ＭＡＧ１１Ｂは、ＨＩオプションとプリフィックスＰ１を含むＰＢＵメッセージ（不図示）をＬＭＡ／HA１３Ｂへ送信する。ＬＭＡ／ＨＡ１３Ｂは、このメッセージを受信すると、インタフェースＩｆ２のＰＭＩＰｖ６バインディングとして登録されているＰ１、Ｐ２のうち、ＰＢＵメッセージで指定されているプリフィックスＰ１を選択し、垂直ハンドオフのトリガの応答として、プリフィックスＰ１を含むＡＣＫ信号を送信する。したがって、ＭＡＧ１１Ｂは、インタフェースＩｆ１に対して、プリフィックスＰ１を含む応答メッセージ（不図示）を送信する。

（ｃ）次に図１２Ｃを参照して、３つのインタフェースＩｆ１、Ｉｆ２、Ｉｆ３を有するＭＮ１０Ｃが垂直ハンドオフを実行する場合について説明する。ＭＮ１０Ｃはまず、インタフェースＩｆ１、Ｉｆ２がそれぞれリンク１５Ｃ、１６Ｃ及びＭＡＧ１１Ｃ、１２Ｃを介してＬＭＡ／ＨＡ１４ＣにルーティングされるＰＭＩＰｖ６ドメインに接続（attach）して、プリフィックスＰ１、Ｐ２を参照しているものとする。一方、インタフェースＩｆ３は未接続である。以下、この状態を初期接続状態と言う。次に、ＭＮ１０ＣがインタフェースＩｆ２をシャットダウンし、また、インタフェースＩｆ３をアクティブ化して、インタフェースＩｆ２のフローをインタフェースＩｆ３に移す垂直ハンドオフを決定するものとする。

ＭＮ１０Ｃは、この垂直ハンドオフを実行してＭＡＧ１３Ｃをトリガする場合、図１２Ａ、図１２Ｂに示す場合より多くの情報をトリガメッセージ１８Ｃ内に含ませる必要がある。その情報としては、例えば垂直ハンドオフ・フラグ（オプションでもよい）と、シャットダウンしたインタフェースＩｆ２の識別子又はインタフェースＩｆ３経由で参照したいプリフィックスＰ２がある。トリガメッセージ１８Ｃで送信される垂直ハンドオフ・トリガ情報すなわちＨＩ情報は、単に１ビットで「垂直ハンドオフ」を指示することができる。しかしながら、ＭＡＧ１３ＣがＰＢＵメッセージ（不図示）をＬＭＡ／ＨＡ１４Ｃに送信するときには、この垂直ハンドオフ情報は、非特許文献２に記載されているような適切なオプション（ＨＩオプション）内に含ませる必要がある。

ここで、非特許文献２には、垂直ハンドオフのトリガを新しいＭＡＧすなわちＭＡＧ１３Ｃに与える方法が記載されていないことに注意すべきである。すなわち、異種のアクセス技術タイプ（ＡＴＴ）のドメインを跨がった垂直ハンドオフに対しては、ネットワーク側はこのステップをＭＮ側から通知されなければ検知できない。また、３ＧＰＰの構成においても、異種のＡＴＴのドメインを跨がったハンドオフに対して、ネットワーク側がハンドオフを開始することは考慮されていない。この理由は、ネットワーク側にとって他のＡＴＴのドメインから長いルーティングパスを経由してそのような行動をとることが困難であり、さらには、垂直ハンドオフがＭＮのあるプリフィックス（このプリフィックスはＡＴＴのドメインを経由して参照することが望ましい）に関連する動的な希望と節電などによる決定に基づいて実行されるからである。

図１２Ｃにおいて、ＭＮ１０Ｃがハンドオフのこれらのパラメータ（図のMN trigger→HI=2,If2-ID/P2）をＭＡＧ１３Ｃに与えると、ＭＡＧ１３ＣはこれらのパラメータをＰＢＵメッセージ（不図示）内のオプションにセットする。このオプションとは、インタフェースＩｆ２のＩｆ２−ＩＤが存在し、インタフェースＩｆ３のＩｆ３−ＩＤが存在し、ＡＴＴオプション及びＨＩオプション（ＨＩ＝２）が存在するということである。ＬＭＡ／ＨＡ１４Ｃは、このＰＢＵメッセージを受信すると、まず、このメッセージが垂直ハンドオフ（ＨＩ＝２）であると識別する。次いでＬＭＡ／ＨＡ１４Ｃは、ＰＢＵメッセージ内のインタフェースＩｆ２のＩｆ２−ＩＤを参照してＩｆ２−ＩＤのエントリがキャッシュに存在することを識別し、プリフィックスＰ２をインタフェースＩｆ３に移す。基本的に、インタフェースＩｆ３のキャッシュ内のエントリはプリフィックスＰ２に基づいて生成される。ＬＭＡ／ＨＡ１４ＣからＭＡＧ１３Ｃに送信されるＰＢＡメッセージ（不図示）によりプリフィックスＰ２が通知される。ＭＡＧ１３ＣはプリフィックスＰ２を受信すると、プリフィックスＰ２をＲＡメッセージやＡＣＫ信号のシグナリング１９ＣでＭＮ１０Ｃに送信する（図のResponse→(P2)）。

（ｄ）最後に、図１２Ｄに示す垂直ハンドオフについて説明する。ＭＮ１０Ｄは３つのインタフェースＩｆ１、Ｉｆ２、Ｉｆ３を有し、インタフェースＩｆ１、Ｉｆ２、Ｉｆ３はそれぞれ、リンク１５Ｄ及びＭＡＧ１１Ｄ、リンク１６Ｄ及びＭＡＧ１２Ｄ、リンク１７Ｄ及びＭＡＧ１３Ｄを介してＬＭＡ／ＨＡ１４ＤにルーティングされるＰＭＩＰｖ６ドメインに接続（connect）しており、それぞれプリフィックスＰ１、Ｐ２、Ｐ３を参照している。ＭＮ１０ＤがインタフェースＩｆ２の垂直ハンドオフを実行し、垂直ハンドオフのトリガメッセージ１８Ｄ（図のMN trigger→HI=2,If2-ID/P2）をＭＡＧ１３Ｄに送信するものとする。ＭＡＧ１３Ｄはトリガメッセージ１８Ｄを受信すると、ＰＢＵメッセージ（不図示）をＬＭＡ／ＨＡ１４Ｄに送信する。前述したように、ＰＢＵメッセージはインタフェースＩｆ２、Ｉｆ３のＩＤなどの多くのパラメータを含む。ＬＭＡ／ＨＡ１４Ｄは、インタフェースＩｆ３に接続（connect）されているＭＡＧ１３ＤからＰＢＵメッセージを受信すると、ＭＮ１０ＤがインタフェースＩｆ２の垂直ハンドオフを実行していてインタフェースＩｆ２のフローをインタフェースＩｆ３に移したいことを識別することができる。この場合、ＬＭＡ／ＨＡ１４Ｄが正しいプリフィックスＰ２、Ｐ３をＭＡＧ１３Ｄに与え、したがって、ＭＮ１０ＤがＭＡＧ１３Ｄからの応答メッセージ１９ＤでプリフィックスＰ２、Ｐ３を受信する（図のResponse→(P2,P3)）。

ここで重要な点は、インタフェースが２つの場合と、２つを超える場合の垂直ハンドオフ動作を区別することにある。インタフェースが２つの場合、垂直ハンドオフは単純であって、そのシグナリング負荷は水平ハンドオフの場合と非常に似ている。唯一の違いは、垂直ハンドオフのトリガメッセージ１８Ｄが重要であることである。インタフェースが２つを超える場合の垂直ハンドオフ動作の場合、シャットダウンするインタフェースＩｆ２の何かのステート情報が垂直ハンドオフ動作を開始するときに必要となる。

これまで述べたように、３つのインタフェースを有するモバイルノードがそのうちの２つのインタフェースに関するプリフィックスを固定して静的な垂直ハンドオフを行う際の主要な問題点は、シャットダウンしたインタフェースのインタフェース識別子や移動するプリフィックスを有するトリガメッセージを垂直ハンドオフの度に繰り返し送信する必要があることにある。また、２つのインタフェースを有するモバイルノードが、それぞれのインタフェースに割り当てられているプリフィックスを一方のインタフェースに集約しているときに、もう一方のインタフェースへプリフィックスを戻す際の主要な問題点は、そのプリフィックスを有するトリガメッセージを垂直ハンドオフの度に繰り返し送信する必要があることにある。このようなインタフェース識別子、及びプリフィックスは、そのビット長によりトリガメッセージのパケットサイズを増大し、さらに、トリガメッセージを送信するときのモバイルノードの消費電力や、シグナリングコストを増大させる。さらに、トリガメッセージのパケットサイズが増大すればするほど、無線帯域を多く使用する。

本発明は上記の問題点に鑑み、モバイルノードが静的な垂直ハンドオフの規則を有し、また３以上のインタフェースを有する場合には、垂直ハンドオフを要求するシグナリングのパケットサイズを減少することができる垂直ハンドオフ方法、垂直ハンドオフシステム、モバイルノード及びそのホームエージェントを提供することを目的とする。
本発明はまた、モバイルノードが２以上のインタフェースを有する場合にも、垂直ハンドオフのシグナリングを要求するパケットサイズを減少することができる垂直ハンドオフ方法、垂直ハンドオフシステム、モバイルノード及びそのホームエージェントを提供することを目的とする。

本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有するモバイルノードが前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する場合の垂直ハンドオフ方法であって、
前記第２又は第３のインタフェースが前記第２又は第３のネットワークへ垂直ハンドオフする前に使用していた、前記第１のインタフェースとは異なるプリフィックスを、前記垂直ハンドオフ後にも前記第２又は第３のインタフェースで継続的に使用するために、前記プリフィックスを前記モバイルノードのホームエージェントに設定するプリフィックス設定ステップと、
前記モバイルノードが前記新しく接続する第２又は第３のインタフェースから前記ホームエージェントに対して、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信するステップと、
前記ホームエージェントが前記トリガメッセージ内の前記垂直ハンドオフ・フラグを検知して、前記プリフィックス設定ステップにより設定されたプリフィックスを前記前に接続していた第２又は第３のインタフェースから前記新しく接続する第２又は第３のインタフェースに移すステップとを、
有するよう構成した。

本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有するモバイルノードが前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する垂直ハンドオフシステムであって、
前記第２又は第３のインタフェースが前記第２又は第３のネットワークへ垂直ハンドオフする前に使用していた、前記第１のインタフェースとは異なるプリフィックスを、前記垂直ハンドオフ後にも前記第２又は第３のインタフェースで継続的に使用するために、前記プリフィックスを前記モバイルノードのホームエージェントに設定するプリフィックス設定手段と、
前記モバイルノードが前記新しく接続する第２又は第３のインタフェースから前記ホームエージェントに対して、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信する手段と、
前記ホームエージェントが前記トリガメッセージ内の前記垂直ハンドオフ・フラグを検知して、前記プリフィックス設定手段により設定されたプリフィックスを前記前に接続していた第２又は第３のインタフェースから前記新しく接続する第２又は第３のインタフェースに移す手段とを、
有するよう構成した。

また本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有し、前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する垂直ハンドオフを行なうモバイルノードであって、
前記新しく接続する第２又は第３のインタフェースからモバイルノードのホームエージェントに対して、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信する手段を、
有するよう構成した。

また本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有するモバイルノードが前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する垂直ハンドオフシステムにおける前記モバイルノードのホームエージェントであって、
前記モバイルノードの第２又は第３のインタフェースが前記第２又は第３のネットワークへ垂直ハンドオフする前に使用していた、前記第１のインタフェースとは異なるプリフィックスを記憶するプリフィックス記憶手段と、
前記モバイルノードの前記新しく接続する前記第２又は第３のインタフェースから送信され、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを受信する手段と、
前記トリガメッセージ内の前記垂直ハンドオフ・フラグを検知して、前記プリフィックス記憶手段に記憶されたプリフィックスを、前記前に接続していた第２又は第３のインタフェースから前記新しく接続する第２又は第３のインタフェースに移す手段とを、
有するよう構成した。

上記構成により、垂直ハンドオフのトリガメッセージが新しく接続するインタフェースの識別子を含まないので、モバイルノードが静的な垂直ハンドオフの規則を有し、また３以上のインタフェースを有する場合には、垂直ハンドオフを要求するシグナリングのパケットサイズを減少することができる。

また、前記モバイルノードが、前記継続的に使用するプリフィックスを決定して前記ホームエージェントに設定することを特徴とする。
また、前記ホームエージェントが前記モバイルノードの移動経路を学習して前記継続的に使用するプリフィックスを決定することを特徴とする。

また本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有するモバイルノードが前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する場合の垂直ハンドオフ方法であって、
前記モバイルノードが、前記第２又は第３のインタフェースが前記第２又は第３のネットワークへ垂直ハンドオフする前に使用していた前記第１のインタフェースとは異なるプリフィックスを、前記垂直ハンドオフ後にも前記第２又は第３のインタフェースで継続的に使用するために、前記モバイルノードのプロキシノードに設定するプリフィックス設定ステップと、
前記プロキシノードの間で前記継続的に使用するプリフィックスを転送するステップと、
前記モバイルノードが前記新しく接続する第２又は第３のインタフェースから前記プロキシノードに対して、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信するステップと、
前記プロキシノードが前記トリガメッセージを受信して、前記継続的に使用するプリフィックスを前記ホームエージェントに通知するステップと、
前記ホームエージェントが前記通知されたプリフィックスを前記前に接続していた第２又は第３のインタフェースから前記新しく接続する第２又は第３のインタフェースに移すステップとを、
有する構成とした。

また本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１と第２のネットワークにそれぞれ接続可能な第１のインタフェースと第２のインタフェースとを有するモバイルノードが前記第１と第２のネットワーク内をローミングして、前記第２のインタフェースが前記第２のネットワークから切断して前記第２のネットワークに再接続する場合の垂直ハンドオフ方法であって、
前記第２のインタフェースが前記第２のネットワークへ垂直ハンドオフする前に使用していたプリフィックスを、前記垂直ハンドオフ後にも前記第２のインタフェースで継続的に使用するために、前記プリフィックスを前記モバイルノードのホームエージェントに設定するプリフィックス設定ステップと、
前記モバイルノードが前記新しく接続する第２のインタフェースから前記ホームエージェントに対して、垂直ハンドオフ・フラグを含みかつ前記継続的に使用するプリフィックスを含まない垂直ハンドオフのトリガメッセージを送信するステップと、
前記ホームエージェントが前記トリガメッセージ内の前記垂直ハンドオフ・フラグを検知して、前記第２のインタフェースが切断前に関連していたプリフィックスを前記新しく接続する第２のインタフェースに移すステップとを、
有する構成とした。

また本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１と第２のネットワークにそれぞれ接続可能なインタフェースとを有するモバイルノードが前記第１と第２のネットワーク内をローミングして、前記第２のインタフェースが前記第２のネットワークから切断して前記第２のネットワークに再接続する場合の垂直ハンドオフ方法であって、
前記モバイルノードが前記再接続時に前記第２のインタフェースから前記ホームエージェントに対して、前記第２のインタフェースが切断前に関連していたプリフィックスを前記第１のインタフェースに設定するか、又は前記第２のインタフェースに設定するかを指示する垂直ハンドオフ・フラグを含みかつ前記第２のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信するステップと、
前記ホームエージェントが前記トリガメッセージ内の前記垂直ハンドオフ・フラグに基づいて、前記第２のインタフェースが切断前に関連していたプリフィックスを前記第１又は第２のインタフェースに選択的に設定するステップとを、
有する構成とした。

また本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１と第２のネットワークにそれぞれ接続可能なインタフェースを少なくとも有するモバイルノードが前記第１のネットワークと第２のネットワーク内をローミングする場合に、前記第１のインタフェースに関連する第１のプリフィックスのパケットを前記第２のインタフェースに転送する垂直ハンドオフ方法であって、
前記モバイルノードが前記第１のインタフェースをシャットダウンする際に、前記第１のプリフィックスを前記第２のインタフェースにバインディングするよう前記モバイルノードのホームエージェントに設定するステップと、
前記ホームエージェントが前記第１のインタフェースあてのパケットを、前記バインディングに基づいて前記第２のインタフェースに転送するステップとを、
有する構成とした。

この構成により、モバイルノードが２以上のインタフェースを有する場合にも、垂直ハンドオフを要求するシグナリングのパケットサイズを減少することができる。

本発明によれば、モバイルノードが静的な垂直ハンドオフの規則を有し、また３以上のインタフェースを有する場合には、垂直ハンドオフを要求するシグナリングのパケットサイズを減少することができる。
本発明はまた、モバイルノードが２以上のインタフェースを有する場合にも、垂直ハンドオフを要求するシグナリングのパケットサイズを減少することができる。

第１の実施の形態の垂直ハンドオフシステム及び通信シーケンスの一例を示す説明図 図１の最適化要求メッセージの別の形態を示す説明図 図１の垂直ハンドオフの最適化要求メッセージ（Ｌ２メッセージの場合）のフォーマットの一例を示す説明図 図１の垂直ハンドオフの最適化要求メッセージ（新しいモビリティ拡張ヘッダを有するシグナリング・パケットの場合）のフォーマットの一例を示す説明図 図１の垂直ハンドオフの最適化要求メッセージ（ＢＵメッセージのパケットの場合）のフォーマットの一例を示す説明図 第１の実施の形態のモバイルノードの動作を説明するためのフローチャート 第１の実施の形態のモバイルノードの構成を機能的に示すブロック図 第１の実施の形態のＬＭＡ／ＨＡの動作を説明するためのフローチャート 第１の実施の形態のＬＭＡ／ＨＡの構成を機能的に示すブロック図 第４の実施の形態の垂直ハンドオフシステム及び通信シーケンスの一例を示す説明図 第４の実施の形態のモバイルノードの動作を説明するためのフローチャート 第５の実施の形態の垂直ハンドオフシステム及び通信シーケンスの一例を示す説明図 第６の実施の形態の垂直ハンドオフシステムの一例を示す構成図 図１１Ａにおける通信シーケンスの一例を示す説明図 垂直ハンドオフの種々のケース（モバイルノードのインタフェースが２つの場合の一例）を示す説明図 垂直ハンドオフの種々のケース（モバイルノードのインタフェースが２つの場合の別の一例）を示す説明図 垂直ハンドオフの種々のケース（モバイルノードのインタフェースが３つの場合の一例）を示す説明図 垂直ハンドオフの種々のケース（モバイルノードのインタフェースが３つの場合の別の一例）を示す説明図 第１の実施の形態が想定する垂直ハンドオフシステムの一例を示す説明図 第１の実施の形態が想定する他の垂直ハンドオフシステムを示す説明図 図１３における垂直ハンドオフ・トリガメッセージの一例を示す説明図

インタフェースが３つの場合の垂直ハンドオフの問題点については既に説明したが、基本的に、インタフェースが３以上の場合、垂直ハンドオフを実現するためには、シャットダウンするインタフェースのＩＤが必須となる。以下では、垂直ハンドオフのプロセス中の問題点について、図１３を参照してさらに説明する。また、合わせて本発明の実施の形態において想定している動作シナリオの一例を説明する。

＜想定例＞
図１３は本発明の第１の実施の形態が想定する通信システムを示す。図１３は、ＰＭＩＰｖ６ドメイン３１１内の垂直ハンドオフに関連する問題を理解するための図であって、ＰＭＩＰｖ６ドメイン３１１では、ＰＭＩＰｖ６のプロトコルが３ＧＰＰシステム・アーキテクチャ・エボリューション（ＳＡＥ）ローカルドメイン内に採用されている。ここで、ＭＮ３００が３つのインタフェースＩｆ１、Ｉｆ２、Ｉｆ３を有する場合の垂直ハンドオフについては、既に図１２Ｃ、図１２Ｄにおいて説明した。また、垂直ハンドオフを実現するためには、ＭＮ３００のシャットオフするインタフェースの識別子がＬＭＡ／ＨＡ３１２に与えられなければならない。ＭＮ３００がＰＭＩＰｖ６ドメイン３１１内をローミングする間に多くの垂直ハンドオフが発生する。なお、図１３及び、以降で用いる図１４、図１５では、便宜的にセルラネットワーク、ＷＬＡＮアクセスネットワーク、ＷｉＭＡＸアクセスネットワークを用いているが、図１３に示されているネットワークの構成やアクセスネットワークの種類、インタフェースの種類や数などはこれに限定される必要はなく、本発明が適用される範囲を逸脱しない限り任意の構成を想定することができる。また、第２の実施の形態以降で用いられている通信システムの図（図８、図１０）でも同様である。

さらに、図１３では、垂直ハンドオフのイベントは、３つの要素により発生する。１つ目は、同じアクセス技術タイプのネットワークが欠如していて、例えばＷｉＭＡＸインタフェースＩｆ２が通信するＷｉＭＡＸアクセスネットワーク３０１ａと３０３ａのセルが連続していないこと、また、ＷＬＡＮインタフェースＩｆ３が通信するＷＬＡＮアクセスネットワーク３０２ａが他のＷＬＡＮアクセスネットワークのセルと連続していないことによる。２つ目は、ＭＮ３００がマルチホーミングを実現するために複数のインタフェースの維持を希望することによる。例えば、セルラインタフェースＩｆ１が接続中であり、ＷｉＭＡＸインタフェースＩｆ２又はＷＬＡＮインタフェースＩｆ３のいずれかが新たにネットワークに接続した場合に、セルラインタフェースＩｆ１において確立していた複数のコネクションのうち、１つ又は複数の任意のコネクションを、ＷｉＭＡＸインタフェースＩｆ２又はＷＬＡＮインタフェースＩｆ３のどちらかへ選択的に移す場合などである。３つ目は、ＭＮ３００があるフローについてはあるアクセス技術タイプを希望することによる。以下に、垂直ハンドオフ規則について詳しく説明する。

図１３における想定として、ＭＮ３００が３ＧセルラインタフェースＩｆ１と、ＷｉＭＡＸインタフェースＩｆ２とＷＬＡＮインタフェースＩｆ３を有するものとする。また、ＬＭＡ／ＨＡ３１２がＰＭＩＰｖ６ドメイン３１１のアンカーポイントであるものとする。また、ＰＭＩＰｖ６ドメイン３１１の無線アクセス部分が３Ｇのセルによりフルにカバーされ、ＰＭＩＰｖ６ドメイン３１１がＬＭＡ／ＨＡ３１２においてルーティングされるものとする。さらに、３Ｇのセルが連続しており、かつＷＬＡＮアクセスネットワーク（以下、ＷＬＡＮドメイン）３０２ａとＷｉＭＡＸアクセスネットワーク（以下、ＷｉＭＡＸドメイン）３０１ａ、３０３ａが３ＧセルのＰＭＩＰｖ６ドメイン３１１のカバー範囲に存在するものとする。基本的に、３ＧセルのＰＭＩＰｖ６ドメイン３１１は連続しており、ＷｉＭＡＸドメイン３０１ａ、３０３ａ及びＷＬＡＮドメイン３０２ａは連続していないものとする。

この想定はあり得る。その理由は、ＭＮ３００が３ＧセルラインタフェースＩｆ１経由で３ＧセルのＰＭＩＰｖ６ドメイン３１１に接続（attach）しているが、ＰＭＩＰｖ６ドメイン３１１と異なるオペレータ又は外部のオペレータが非３ＧＰＰネットワーク（ＷｉＭＡＸドメイン３０１ａ、３０３ａ及びＷＬＡＮドメイン３０２ａ）を提供するため、また、非３ＧＰＰネットワークが協力してセルを連続的に配置することが困難であるために、ＭＮ３００が非３ＧＰＰネットワークには連続して接続（attach）しないかもしれないからである。

初期時点Ｔ０では、ＭＮ３００の３ＧセルラインタフェースＩｆ１がＭＡＧ／３ＧＰＰ３１３に接続（attach）し、かつＷｉＭＡＸインタフェースＩｆ２がＭＡＧ／ＷｉＭＡＸ３０１に接続（attach）している。このため、ＭＮ３００はＭＡＧ／３ＧＰＰ３１３、ＭＡＧ／ＷｉＭＡＸ３０１からそれぞれルータ広告（ＲＡ）メッセージ３０５、３０６を受信する。例えばＭＮ３００はＲＡメッセージ３０５、３０６でそれぞれプリフィックスＰ１、Ｐ２を参照する。ＭＮ３００は２つのインタフェースＩｆ１、Ｉｆ２を同時に使用するマルチホーミングを希望して、２つのインタフェースＩｆ１、Ｉｆ２を使用するものとする。

次にＭＮ３００が移動して、時点Ｔ１ではＷｉＭＡＸドメイン３０１ａのカバーする範囲がなくなり、ＷＬＡＮドメイン３０２ａのカバーする範囲のみとなる。この時点Ｔ２では、ＭＮ３００はマルチホーミングを実現するためには、ＷＬＡＮインタフェースＩｆ３経由の垂直ハンドオフを実行する必要がある。ここでのマルチホーミングとは、より高い帯域を実現することが可能な場合にはいつでも複数のインタフェースを使用することを意味する。また代わりに、時点Ｔ２では、ＭＮ３００はプリフィックスＰ２に関連するフローをＷｉＭＡＸ又はＷＬＡＮのアクセス技術タイプで参照することを希望して、ＷＬＡＮへの垂直ハンドオフを実行してもよい。ここで理解すべき重要な点は、前述したように垂直ハンドオフがＭＮ３００の希望で実行できることにある。ここで、当業者であれば、ＭＮ３００は、ＭＡＧ／ＷｉＭＡＸ３０１と接続（connect）されなくなったときに、ＭＡＧ／３ＧＰＰ３１３に対して垂直ハンドオフを実行しないことは明らかである。その理由は、ＭＮ３００が複数のインタフェースの使用を希望し、さらにプリフィックスＰ２に関連するフローをＷｉＭＡＸ経由又はＷＬＡＮ経由で送受信することを希望するからである。

ここで、ＭＮ３００がＷＬＡＮインタフェースＩｆ３経由で、ＷｉＭＡＸインタフェースＩｆ２の情報をＭＡＧ／ＷＬＡＮ３０２に提供してプリフィックスＰ２を参照するものとする。この場合、ＭＮ３００は時点Ｔ１では、ＭＡＧ／３ＧＰＰ３１３、ＭＡＧ／ＷＬＡＮ３０２からのそれぞれのＲＡメッセージ３０７、３０８でプリフィックスＰ１、Ｐ２を参照する。時点Ｔ１では、ＭＡＧ／３ＧＰＰ３１３は変更されていないので、３ＧセルラインタフェースＩｆ１に関連する垂直ハンドオフ動作は行われない。ここで理解すべき重要な点は、３Ｇセルが連続的であり、かつプリフィックスＰ１を使用するフロー（例えばＶｏＩＰ）は３ＧセルラインタフェースＩｆ１経由が望ましいので、プリフィックスＰ１の垂直ハンドオフは必要としないことにある。

次の時点Ｔ２では、ＭＮ３００がＷＬＡＮドメイン３０２ａの範囲から外れてＷｉＭＡＸドメイン３０３ａの範囲に入ったものとする。ただし、３ＧのＰＭＩＰｖ６ドメイン３１１の範囲内に未だ位置する。この場合、ＷＬＡＮインタフェースＩｆ３がＷＬＡＮドメイン３０２ａとの接続（connection）を失い、ＭＮ３００がＷｉＭＡＸインタフェースＩｆ２を使用してＷｉＭＡＸドメイン３０３ａに接続（connect）することを希望するものとする。時点Ｔ２では、ＭＮ３００はＭＡＧ／ＷｉＭＡＸ３０３に対して垂直ハンドオフを実行しなければならず、ＷｉＭＡＸインタフェースＩｆ２経由でプリフィックスＰ２を参照することを希望する。この場合、ＭＮ３００は垂直ハンドオフのトリガメッセージ（図１５で説明する）をＭＡＧ／ＷｉＭＡＸ３０３に送信する。基本的に、図１３に示す想定では、プリフィックスＰ１に関する垂直ハンドオフには問題がない。その理由は、ＰＭＩＰｖ６ドメイン３１１は大きなセルであって連続したカバー範囲であり、プリフィックスＰ１は３ＧセルラインタフェースＩｆ１経由で参照されるからである（図のＲＡメッセージ３０５、３０７、３０９）。プリフィックスＰ２のみがＷｉＭＡＸインタフェースＩｆ２とＷＬＡＮインタフェースＩｆ３の間でやり取りされる。

＜他の想定例＞
図１４に示すネットワーク構成は図１３とほぼ同じであるが、ＭＮ４００は、３ＧセルラインタフェースＩｆ１と、ＷＬＡＮインタフェースＩｆ２とＷｉＭＡＸインタフェースＩｆ３を有するものとする。また、ＭＮ４００の移動軌跡４０４は、ＷＬＡＮアクセスネットワーク４０１ａ（時点Ｔ０）→ＷｉＭＡＸネットワーク４０２ａ（時点Ｔ１）→ＷＬＡＮアクセスネットワーク４０３ａ（時点Ｔ２）である。ここで、図示省略されているが、初期時点Ｔ０の前の時点では、ＭＮ４００は、３ＧセルインタフェースＩｆ１がプリフィックスＰ１を、ＷＬＡＮインタフェースＩｆ２がプリフィックスＰ２を、ＷｉＭＡＸインタフェースＩｆ３がプリフィックスＰ３を参照しているものとし、初期時点Ｔ０では、不図示のＷｉＭＡＸネットワークがカバーする範囲から離れてＷＬＡＮアクセスネットワーク４０１ａに移動し、インタフェースＩｆ２に対して垂直ハンドオフを実行する。これにより、ＭＮ４００は、インタフェースＩｆ１がＲＡメッセージ４０５によってプリフィックスＰ１を参照し、インタフェースＩｆ２がＲＡメッセージ４０６によってプリフィックスＰ２、Ｐ３を参照する。

初期時点Ｔ０ではステート４１３で示すように、ＭＮ４００はＷｉＭＡＸインタフェースＩｆ３をシャットダウンして、プリフィックスＰ３のフローをＷＬＡＮインタフェースＩｆ２のＭＡＧ／ＷＬＡＮ４０１に垂直ハンドオフするものとする。基本的には、ＭＮ４００は希望のインタフェース（ここではＷＬＡＮインタフェースＩｆ２）に垂直ハンドオフするが、ＷＬＡＮインタフェースＩｆ２は、既に接続（connect）されているインタフェースである。したがって、ＭＮ４００はＭＡＧ／ＷＬＡＮ４０１からのＲＡメッセージ４０６で２つのプリフィックスＰ２、Ｐ３を参照する。なお、３ＧセルラインタフェースＩｆ１は、初期時点Ｔ０でも初期時点Ｔ０の前の時点から継続してプリフィックスＰ１を参照している。

ＭＮ４００がさらに移動してＷＬＡＮアクセスネットワーク４０１ａとの接続（connection）を失い、時点Ｔ１では、初期時点Ｔ０の前の時点で接続（connect）していたＷｉＭＡＸネットワーク４０２ａに移動したものとする。時点Ｔ１では、ＭＮ４００はＭＡＧ／３ＧＰＰ３１３ではなく、ＭＡＧ／ＷｉＭＡＸ４０２に垂直ハンドオフするものとする。ＭＮ４００はこの垂直ハンドオフのとき、ＷＬＡＮインタフェースＩｆ２の識別子又はプリフィックスＰ２、Ｐ３を垂直ハンドオフ・トリガメッセージ（図１５）でＭＡＧ／ＷｉＭＡＸ４０２に通知する必要がある。垂直ハンドオフが成功すると、ＭＮ４００はＭＡＧ／ＷｉＭＡＸ４０２からのＲＡメッセージ４０８を受信してプリフィックスＰ２、Ｐ３を参照する。また、ＭＮ４００はＭＡＧ／３ＧＰＰ３１３からのＲＡメッセージ４０７を受信してプリフィックスＰ１を継続して参照する。ここで、プリフィックスＰ１については垂直ハンドオフはなく、ＭＮ４００はプリフィックスＰ１については３ＧセルラインタフェースＩｆ１経由を希望し、３ＧセルラインタフェースＩｆ１については垂直ハンドオフを希望しないものとする。

次いでＭＮ４００がさらに移動して、時点Ｔ２でＷＬＡＮアクセスネットワーク４０３ａに接続（attach）し、また、ＷｉＭＡＸネットワーク４０２ａとの接続（connection）を失うものとする。時点Ｔ２でもＭＮ４００は垂直ハンドオフを実行する。この場合の垂直ハンドオフ・トリガメッセージもＷＬＡＮインタフェースＩｆ３に関する情報を含む。基本的に、この想定例では、プリフィックスＰ１については、３Ｇセルがカバーする範囲が連続しているので垂直ハンドオフを実行する必要はなく、プリフィックスＰ２、Ｐ３について垂直ハンドオフが実行される。

図１５は図１３における垂直ハンドオフ・トリガメッセージ２１６、２１８を示す。ＭＮ３００は初期時点Ｔ０では、３ＧインタフェースＩｆ１がＭＡＧ／３ＧＰＰ３１３に接続（attach）し、かつＷｉＭＡＸインタフェースＩｆ２がＭＡＧ／ＷｉＭＡＸ３０１に接続（attach）している。次の時点Ｔ１では、ＷｉＭＡＸインタフェースＩｆ２がＭＡＧ／ＷｉＭＡＸ３０１との接続（connection）を失い、ＷＬＡＮインタフェースＩｆ３がＭＡＧ／ＷＬＡＮ３０２を発見する。ここで、時点Ｔ１では、ＭＮ３００は３ＧネットワークではなくＷＬＡＮネットワーク経由でプリフィックスＰ２を参照することを希望するものとする。プリフィックスＰ２をＷＬＡＮインタフェースＩｆ３経由で参照するためには、ＭＮ３００はＷｉＭＡＸインタフェースＩｆ２のＩＤ（Ｉｆ２−ＩＤ）又はプリフィックスＰ２とＨＩ＝２をＭＡＧ／ＷＬＡＮ３０２あてのトリガメッセージ２１６で通知する必要がある。

同様に、ＭＮ３００はさらに移動して、時点Ｔ２ではＷＬＡＮインタフェースＩｆ３がＭＡＧ／ＷＬＡＮ３０２との接続（connection）を失い、ＷｉＭＡＸインタフェースＩｆ２がＭＡＧ／ＷｉＭＡＸ３０３を発見する。時点Ｔ２では、ＭＮ３００は３ＧネットワークではなくＷｉＭＡＸネットワーク経由でプリフィックスＰ２を希望する場合、ＷＬＡＮインタフェースＩｆ３のＩＤ（Ｉｆ３−ＩＤ）とＨＩ＝２をＭＡＧ／ＷｉＭＡＸ３０３あてのトリガメッセージ２１８で通知する必要がある。

図１５において垂直ハンドオフを行う際の主要な問題点は、６４ビットの長いインタフェース識別子又はプリフィックスを有するトリガメッセージ２１６、２１８を継続して送信する必要があることにある。なお以下では、垂直ハンドオフさせるプリフィックスを指定する情報として、ハンドオフ元となるインタフェースのインタフェース識別子を通知しているが、インタフェース識別子の代わりに垂直ハンドオフさせるプリフィックスそのものを用いてもよい。このようなインタフェース識別子は、トリガメッセージ２１６、２１８のパケットサイズを増大し、さらに、トリガメッセージ２１６、２１８を送信するときのＭＮ３００の消費電力や、ＭＮ３００のシグナリングコストを増大させる。さらに、トリガメッセージ２１６、２１８のパケットサイズが増大すればするほど、無線帯域を多く使用する。さらに、垂直ハンドオフのパラメータを送信するＰＢＵメッセージ内にも、シャットダウンするインタフェースの識別子が必要になり、コアネットワークのシグナリング負荷が増大する。したがって、ＭＮ３００が３つのインタフェースＩｆ１、Ｉｆ２、Ｉｆ３を有していて、固定のすなわち静的な希望により垂直ハンドオフを継続して実行する場合には不都合がある。

ここで理解すべき重要な点は、図１３、図１５における垂直ハンドオフのパターンが非常に静的であることにある。すなわち、ＭＮ３００は常に、プリフィックスＰ２のフローがＷＬＡＮ経由かＷｉＭＡＸ経由になるように希望している。基本的に、垂直ハンドオフの規則は、ＭＮ３００に関する限り静的であるので、パケットサイズが大きく、継続して送信されるトリガメッセージ２１６、２１８は最適化されることが望ましい。

従来技術として、特許文献１は、主に水平ハンドオフであるハンドオフを論じており、ハンドオフの遅延を減少することを目的としている。特許文献１に記載されているメカニズムは２つの部分より成っている。１つ目は、ターゲットのＩＥＥＥ８０２．１１ネットワークにおける前接続認証（pre-authentication）を早くすることであり、２つ目は、ターゲットのアクセスルータに接続（attach）する前に仮想のソフトハンドオフを実行することである。これは、ハンドオフの遅延を減少する別のタイプの最適化であり、垂直ハンドオフのシグナリングのパケットサイズを減少するのには役に立たない。また、たとえ垂直ハンドオフに適用しても、垂直ハンドオフの遅延を減少するだけである。

また、他の従来技術として、特許文献２に記載されている方法の目的は、複数のインタフェースを有するノードに関連する、異なる動作ステートの間のパーフォーマンスを向上させることにある。基本的に、ＭＮが動作中に、ハンドオフの間のパケットロスがモニタされ、適切なインタフェースの電源がオンになってパケットロスを減少させる。ここで、垂直ハンドオフ中のインタフェースに来るパケットを新しいインタフェースが受信してパケットロスを減少させるものと想定する。しかし、この方法をＰＭＩＰｖ６ドメインに適用しても、垂直ハンドオフが発生する必要があるか、又は水平ハンドオフを実行中の他のインタフェースに来るフローを新しいインタフェースが接続したＭＡＧが受信できる必要がある。特許文献２の方法の目的は、パケットロスを防止することにあり、垂直ハンドオフのシグナリングのパケットサイズを最適化することをターゲットとしてはいない。

また、他の従来技術として、特許文献３には、ＭＮがアクセスルータ（ＡＲ）と接続（connect）中及びハンドオフ中のＭＮからＡＲへのシグナリングを減少することが記載されている。この方法は、初期接続（attach）中とハンドオフ接続（attach）時のパケットサイズを減少することによりハンドオフの遅延を最適化する手段に特徴があると思われる。ただし、各接続（connect）時にはＭＮからＡＲへシグナリングする必要がある。これに対し、本発明の目的は、垂直ハンドオフのシグナリング内の省略可能な情報を除去することにある。以上説明したように、ＭＮが静的な垂直ハンドオフの規則を有し、また３以上のインタフェースを有する場合には、通常の垂直ハンドオフのシグナリングを継続することが効率的でないことは明らかである。

以下、図面を参照して本発明の実施の形態について説明する。
＜第１の実施の形態＞
まず、第１の実施の形態の概要について説明する。ＭＮがあるプリフィックスに対する自身の垂直ハンドオフの規則が静的であると知得すると、そのプリフィックスを一義的に使用するという規則をＬＭＡ／ＨＡに対して直接に又はプロキシ・エージェントを介してプリセットする。ＭＮは、ＭＮが３以上のインタフェースを有するときにも、インタフェース識別子を有しない垂直ハンドオフのトリガメッセージを送信するようにして、トリガメッセージのパケットサイズを減少する。図１は第１の実施の形態の垂直ハンドオフシステム及び通信シーケンスの一例を示す。図１に示すネットワーク構成は、図１３、図１５と同じであるので、詳細な説明は省略する。図１では、ＭＮ５００は３ＧセルラインタフェースＩｆ１と、ＷｉＭＡＸインタフェースＩｆ２とＷＬＡＮインタフェースＩｆ３の３つのインタフェースを有するものとする。ＭＮ５００はＭＡＧ／３ＧＰＰ５１３に対し、ＷｉＭＡＸドメインとＷＬＡＮドメインの間で一義的に使用されるプリフィックス（以下、浮動（floating）プリフィックスとも呼ぶ）に関するＭＮ５００の垂直ハンドオフ規則を通知する（図の５１６）。この情報はＭＡＧ／３ＧＰＰ５１３からＬＭＡ／ＨＡ５１２に転送される（図の５１７）。なお、ＭＮ５００がＭＡＧ／ＷｉＭＡＸ５０１又はＭＡＧ／ＷＬＡＮ５０２に接続している際に垂直ハンドオフ規則を通知してもよい。

＜Ｔ０＞
初期時点Ｔ０（ステート５１３）では、ＭＮ５００は３ＧセルラインタフェースＩｆ１がＰＭＩＰｖ６ドメイン５１１のＭＡＧ／３ＧＰＰ５１３に接続（attach）され、また、ＷｉＭＡＸインタフェースＩｆ２がＷｉＭＡＸアクセスネットワーク５０１ａ経由でＰＭＩＰｖ６ドメイン５１１のＭＡＧ／ＷｉＭＡＸ５０１に接続（attach）されているものとし、また、ＭＮ５００はプリフィックスＰ１をインタフェースＩｆ１経由のＲＡメッセージ５０５で、プリフィックスＰ２をインタフェースＩｆ２経由のＲＡメッセージ５０６で参照しているものとする。ここで、ＭＮ５００はプリフィックスＰ１、Ｐ２に対して固定の垂直ハンドオフ規則を設定したいものとする。基本的に、ＭＮ５００はプリフィックスＰ２をＷｉＭＡＸアクセスネットワーク５０１ａ、５０３ａ経由及びＷＬＡＮアクセスネットワーク５０２ａ経由のみで参照したい。この要求はプリフィックスＰ２を使用しているフローの性質によるものであるかもしれない。

このため、初期時点Ｔ０では、ＭＮ５００はその旨の垂直ハンドオフ情報の最適化要求メッセージ５１６（及び５１７）をＭＡＧ／３ＧＰＰ５１３経由でＬＭＡ／ＨＡ５１２に送信する。ＭＡＧ／３ＧＰＰ５１３あての最適化要求メッセージ５１６は、レイヤ２（Ｌ２）メッセージでもよく、レイヤ３（Ｌ３）メッセージでもよい。最適化要求メッセージ５１６（及び５１７）により、プリフィックスＰ２がＷｉＭＡＸアクセスネットワーク５０１ａ、５０３ａ経由及びＷＬＡＮアクセスネットワーク５０２ａ経由の浮動プリフィックスとして一義的に使用することがＬＭＡ／ＨＡ５１２に通知される。

基本的に、最適化要求メッセージ５１６（及び５１７）の意味は、ＷｉＭＡＸ側から垂直ハンドオフがトリガされると、プリフィックスＰ２がＷＬＡＮのバインディング側からＷｉＭＡＸのバインディング側に移され、ＷＬＡＮ側から垂直ハンドオフがトリガされると、プリフィックスＰ２がＷｉＭＡＸのバインディング側からＷＬＡＮのバインディング側に移されるということである。ＭＮ５００は、初期時点Ｔ０でＰＭＩＰｖ６ドメイン５１１内をローミングしているときにこのような静的な垂直ハンドオフを実行できるものと予測する。もし、ＭＮ５００が予測によりこのような静的な垂直ハンドオフを実行できない場合には、ＭＮ５００はＰＭＩＰｖ６のプロトコルの標準の垂直ハンドオフに戻し、また、ＬＭＡ／ＨＡ５１２はその処理方法を知得する。

ＭＡＧ／３ＧＰＰ５１３は最適化要求メッセージ５１６を受信すると、最適化要求メッセージ５１６の内容を別のシグナリング・メッセージ５１７でＬＭＡ／ＨＡ５１２に通知する。シグナリング・メッセージ５１７はＰＢＵメッセージでもよい。ＬＭＡ／ＨＡ５１２はシグナリング・メッセージ５１７を受信すると、プリフィックスＰ２がＷｉＭＡＸとＷＬＡＮとの間の垂直ハンドオフを実行するときの浮動プリフィックスであることを知得し、そのことを示すために、自身のバインディングキャッシュ内に特別なフラグを生成する。

＜時点Ｔ１＞
ＭＮ５００は、最適化要求メッセージ５１６を送信した後に軌跡５０４に沿って移動して、ＭＡＧ／ＷｉＭＡＸ５０１から切断（disconnect）され、ＭＡＧ／ＷＬＡＮ５０２に対する垂直ハンドオフを実行するものとする。このときのＭＡＧ／ＷＬＡＮ５０２あての垂直ハンドオフ・トリガメッセージ５１８は、ＨＩフラグ（＝２、ハンドオーバ接続であることを示す値）のみを必要とし、ＷＬＡＮインタフェースＩｆ２の識別子もプリフィックスＰ２も添付する必要はない。ＬＭＡ／ＨＡ５１２には、時点Ｔ０における最適化要求メッセージ５１６が既に通知されているためである。したがって、時点Ｔ０における最適化要求メッセージ５１６により、時点Ｔ１における垂直ハンドオフのシグナリングのパケットサイズを最適化できることがわかる。

ＭＡＧ／ＷＬＡＮ５０２は、垂直ハンドオフ・トリガメッセージ５１８を受信すると、ＨＩオプション（＝２）と、ＡＴＴオプションを含むＰＢＵメッセージ５１９をＬＭＡ／ＨＡ５１２に送信する。ＬＭＡ／ＨＡ５１２は、ＰＢＵメッセージ５１９を受信すると、まず、ＮＡＩにより識別されるＭＮ５００が、特定のアクセス技術タイプ（ＡＴＴ）により参照される浮動プリフィックスに対して特別な要求を有するか否かをチェックする。また、ＬＭＡ／ＨＡ５１２は、ＰＢＵメッセージ５１９を受信すると、ＡＴＴオプションに基づいてＰＢＵメッセージ５１９がＷＬＡＮのアクセス技術タイプのネットワークから来たものであることを識別して、ＷｉＭＡＸのプリフィックスを移す必要があることを識別し、さらにプリフィックスＰ２を識別する。そして、ＰＢＵメッセージ５１９に対するＰＢＡメッセージ（不図示）でプリフィックスＰ２がＭＡＧ／ＷＬＡＮ５０２に移される。したがって、ＭＮ５００は、ＬＭＡ／ＨＡ５１２がプリフィックスＰ２を識別するためにＷｉＭＡＸインタフェースＩｆ３の識別子についての情報を与えることなく、プリフィックスＰ２を参照する。なお、時点Ｔ０として、ＭＮ５００の３ＧＰＰインタフェースＩｆ１がＭＡＧ／３ＧＰＰ５１３に接続して２つのコネクション（ＰＤＮ（Packet Data Network）コネクション）を確立しており、それぞれのコネクションに対してプリフィックスＰ１とＰ２が割り当てられている状態であってもよい。この場合、時点Ｔ０では、３ＧセルラインタフェースＩｆ１で確立されているコネクションののうち、Ｐ２が割り当てられているコネクションをＷＬＡＮインタフェースＩｆ２又はＷｉＭＡＸインタフェースＩｆ３へ移すコネクション（浮動コネクション）であることを示すために、ＭＮ５００は、Ｐ２が割り当てられているコネクションに関連付けられる識別情報（コネクションＩＤ）を含む最適化要求メッセージをＭＡＧ／３ＧＰＰ５１３経由、又は直接ＬＭＡ／ＨＡ５１２に登録する。なお、識別情報としては、本実施の形態で述べているように、プリフィックスを用いてもよい。そして、時点Ｔ１及び後述する時点Ｔ２では、ＷＬＡＮインタフェースＩｆ２又はＷｉＭＡＸインタフェースＩｆ３から垂直ハンドオフ・トリガメッセージが送信され、プリフィックスＰ２が割り当てられているコネクションのみが移される。また、３ＧＰＰネットワークへのコネクション確立手続中に、プリフィックスＰ２がＷＬＡＮインタフェースＩｆ２及びＷｉＭＡＸインタフェースＩｆ３で使用する浮動プリフィックスであることがＭＮ５００に通知されてもよい。この通知を受けたＭＮ５００は、ＷＬＡＮインタフェースＩｆ２、ＷｉＭＡＸインタフェースＩｆ３で垂直ハンドオフ・トリガメッセージを送信する際には、プリフィックスＰ２を含める必要がないと判断する。なお、３ＧＰＰインタフェースＩｆ１上で複数のコネクションが確立されており、そのうちの特定のコネクションをＷＬＡＮインタフェースＩｆ２又はＷｉＭＡＸインタフェースＩｆ３へ移すというシナリオは、本発明の第２の実施の形態以降に対しても適用することができる。

＜時点Ｔ２＞
ＭＮ５００がＷｉＭＡＸアクセスネットワーク５０３ａに移動して、ＭＡＧ／３ＧＰＰ５１３、ＭＡＧ／ＷｉＭＡＸ５０３からのＲＡメッセージ５１３、５１０を受信したときの動作も同様であり、ＭＮ５００はＷｉＭＡＸインタフェースＩｆ３から、ＨＩフラグ（＝２）のみの垂直ハンドオフ・トリガメッセージ５１８をＭＡＧ／ＷｉＭＡＸ５０３に送信し、また、ＭＡＧ／ＷｉＭＡＸ５０３はＨＩフラグとＡＴＴオプションを含むＰＢＵメッセージ５２２をＬＭＡ／ＨＡ５１２に送信する。ＬＭＡ／ＨＡ５１２の処理は、時点Ｔ１の場合と同様であるので、詳細な説明は省略する。なお、ＭＮ５００は、そのフローに対して上記の固定の静的な垂直ハンドオフ規則を必要としない場合には、その規則を削除するための明示的なメッセージをＬＭＡ／ＨＡ５１２に送信する。

＜最適化要求メッセージ５１６の他の形態＞
図２は、（１）Ｌ２の最適化要求メッセージ５１６及びＬ３のＰＢＵメッセージ５１７と、他の例として、（２）ＭＮ５００がＬＭＡ／ＨＡ５１２に直接に送信する最適化要求メッセージ５０６Ｂを示す。
（１）Ｌ２の最適化要求メッセージ５１６は、初期のＬ２アソシエーション時に送信することができ、Ｌ３のシグナリング・メッセージ５１７は、Ｌ２確立が成功した後に送信することができる。ＭＡＧ／３ＧＰＰ５１３は、Ｌ２の最適化要求メッセージ５１６内の浮動プリフィックスを参照する必要はなく、単に最適化要求メッセージ５１６の内容をシグナリング・メッセージ５１７としてＰＢＵメッセージでＬＭＡ／ＨＡ５１２に転送すればよいだけである。この場合、最適化要求メッセージ５１６の内容がＰＢＵメッセージ５１７の新しいタイプのモビリティ・オプションとして埋め込まれるか、又は新しいモビリティ・メッセージのヘッダの新しいフィールドにより浮動プリフィックスとアクセス技術タイプが送信される。なお、最適化要求メッセージ５１６は、ＲＳ（Router Solicitation）メッセージや、ＮＳ（Neighbor Solicitation）メッセージ、あるいはＢＵメッセージや、ＦＢＵ（Fast Binding Update）メッセージなどのＬ３メッセージであってもよい。

（２）別の形態として、ＭＮ５００がＭＡＧ／３Ｇ５１３に問い合わせてＬＭＡ／ＨＡ５１２のアドレスを取得した後、図のようにＬＭＡ／ＨＡ５１２に直接に最適化要求メッセージ５０６Ｂを送信する。この方法は、ＭＡＧ／３Ｇ５１３の処理がやや軽減される。ＭＮ５００がＬＭＡ／ＨＡ５１２のアドレスを取得する他の方法として、ＭＮ５００がＡＡＡサーバ（不図示）に問い合わせる方法がある。ここで理解すべき重要な点は、ＭＮ５００がホームのＰＭＩＰｖ６ドメイン内５１１に位置していてホームプリフィックスを３ＧセルラインタフェースＩｆ１が参照する場合、この直接の最適化要求メッセージ５０６Ｂは、新しいモビリティヘッダのメッセージ拡張ヘッダを有するメッセージでもよい。また、ＭＮ５００が外部のドメインに位置している場合、メッセージ５０６Ｂは、新しいオプションを有するＢＵメッセージでもよい。また、ＬＭＡ／ＨＡとの間でやり取りされるＩＫＥ（Internet Key Exchange）やＩＰＳｅｃ（IP security）などのシグナリングを用いてもよい。例えば、３ＧセルラインタフェースＩｆ１がセルラネットワーク５１１に接続する際に行う接続手続き（Attach Procedure）や接続更新手続きの中でこの要求を通知してもよい。また、ＷＬＡＮインタフェースＩｆ２やＷｉＭＡＸインタフェースＩｆ３などがＮｏｎ３ＧＰＰネットワークに接続した際に行う接続手続きや接続更新手続きの中でこの要求を通知してもよい。さらに別の形態として、ＭＮ５００がネットワーク・トラフィックに関する情報を有する場合には、別のインタフェース、例えばＷＬＡＮインタフェースＩｆ２又はＷｉＭＡＸインタフェースＩｆ３を選択して、最適化要求メッセージ５１６を送信するインタフェースとして使用することができる。

図２に示す最適化要求メッセージ５０６ＢをＭＮ５００がＬＭＡ／ＨＡ５１２に直接に送信できる場合とは、ＬＭＡ／ＨＡ５１２がＭＮ５００のＭＩＰｖ６ホームエージェントであってＭＮ５００がＬＭＡ／ＨＡ５１２のアドレス情報を有する場合である。ＭＮ５００がＬＭＡ／ＨＡ５１２のアドレスを知得していない場合、ＭＮ５００は、接続（attach）しているＭＡＧ／３ＧＰＰ５１３、又はＡＡＡサーバ、ＤＮＳなどを利用してＬＭＡ／ＨＡ５１２のアドレスを取得する必要がある。ここで理解すべき重要な点は、ＬＭＡ／ＨＡ５１２がＭＮ５００のＭＩＰｖ６ホームエージェントである場合にのみＬＭＡ／ＨＡ５１２への直接の通知による効果があることにある。なお、ＬＭＡ／ＨＡ５１２がＭＮ５００のＭＩＰｖ６ホームエージェントでない場合であっても、ＭＮ５００がＬＭＡ／ＨＡ５１２のアドレスを取得するための手段・シグナリングが利用できる場合は、それらを用いてＬＭＡ／ＨＡ５１のアドレスを取得した後に、最適化要求メッセージ５０６Ｂを送信してもよい。ＭＮ５００がＬＭＡ／ＨＡ５１２のアドレスを知得している場合には、ＬＭＡ／ＨＡ５１２への直接の通知は、ＭＡＧ／３ＧＰＰ５１３の負荷を減少することができる。

＜最適化要求メッセージのフォーマット＞
最適化要求メッセージ５１６、５０６Ｂの詳細な３つの構成例を図３Ａ、図３Ｂ、図３Ｃを参照して説明する。
（ａ）図３Ａに示すフレーム５０７Ｅは、最適化要求メッセージ５１６がＬ２メッセージである場合のフレーム構造を示し、先頭から順次、開始フラグ（Flag）５００Ｅと、アドレス（Address）５０１Ｅと、制御（Control）５０２Ｅと、プロトコルＩＤ（Protocol ID）５０３Ｅと、情報（Information）５０４Ｅと、ＦＣＳ（Frame Check Sequence）５０５Ｅと終了フラグ（Flag）５０６Ｅの各フィールドにより構成されている。

開始フラグ５００Ｅはフレーム５０７Ｅの先頭を示すフラグであり、２番目のフィールドのアドレス５０１Ｅは、ＭＡＣ（Media Access Control）アドレスであって、Ｌ２パケットの送信元アドレスとあて先アドレスを含む。例えば送信元アドレスはＭＮ５００のインタフェースＩｆ１のＭＡＣアドレスであり、あて先アドレスはＭＡＧ／３ＧＰＰ５１３のイングレス・インタフェース（不図示）のＭＡＣアドレスである。３番目のフィールドの制御５０２Ｅは、使用されているフレームのタイプを識別するための情報であって、受信側がこのＬ２のフレーム５０７Ｅを正しく処理するために重要である。基本的に、制御５０２Ｅは、フレーム５０７Ｅのタイプすなわち最適化要求メッセージ５１６のタイプを識別するために使用される。

４番目のフィールドのプロトコルＩＤ５０３Ｅは、上位の層で発生するパケットのみに対する値であって、メッセージ５１７がＬ２で発生する場合にはオール０である。ただし、メッセージ５１６がＬ２で発生することができても、メッセージ５１６を送信する決定と、メッセージ５１６内に埋め込まれている関連パラメータは、Ｌ３から来なければならない。次のフィールドの情報５０４Ｅは、垂直ハンドオフ時に一義的に使用する浮動プリフィックスと、垂直ハンドオフ時のアクセス技術タイプ（例えばＷｉＭＡＸか又はＷＬＡＮの識別子）を含む。情報５０４Ｅの後にＦＣＳ５０５Ｅのフィールドが続き、ＦＣＳ５０５Ｅは、フレームチェックシーケンスフィールドであり、フレーム５０７Ｅが誤りなく伝送（誤りが識別及び訂正）されているか否かを確認するために送信側と受信側により計算される。最後のフィールドの終了フラグ５０６Ｅは、フレーム５０７Ｅのデリミタとして、基本的にはフレーム５０７Ｅの終了を識別するために使用される。ここで、フレーム５０７Ｅの構造は、本発明を逸脱しない範囲で図３Ａに示す構造と同じである必要はない。さらには、本発明を逸脱しない範囲で、最適化要求メッセージ５１６として、図３Ａに示したＬ２メッセージの代わりにＬ３メッセージを用いてもよい。例えば、ＮＳ（Neighbor Solicitation）メッセージやＲＳ（Router Solicitation）メッセージ、さらには、ＩＫＥｖ２メッセージやモビリティヘッダを含むメッセージ（ＢＵメッセージや、新しいタイプのモビリティヘッダ）であってもよい。なお、モビリティヘッダを含むメッセージである場合、後述する図３Ｂ又は図３Ｃに示されるような構造を用いてもよい。

前述したように、ＭＮ５００は最適化要求メッセージ５１６を送信するためのパケットをＬ３で送信することもできる（図２の５０６Ｂ）。Ｌ３のシグナリングが使用される場合には、ＭＮ５００は新しいモビリティ拡張ヘッダか又は新しいモビリティ・オプション付きのＢＵメッセージを使用することができる。

（ｂ）図３Ｂは、新しいモビリティ拡張ヘッダ（New Mobility extension Header）５１０Ｅを有するシグナリング・パケット５１５Ｅを示す。パケット５１５Ｅについて以下に詳しく説明する。パケット５１５Ｅの最初のヘッダは、標準のＩＰｖ６ヘッダ（IPv6 Header）５０８Ｅであり、ＩＰｖ６ヘッダ５０８Ｅは、ＭＮ５００のＨｏＡ又はＣｏＡがセットされる送信元アドレスと、ＬＭＡ／ＨＡ５１２のアドレスがセットされるあて先アドレスを含む。パケット５１５Ｅの次のヘッダは接続認証ヘッダ（Authentication Header）５０９Ｅであり、ＭＮ５００とＬＭＡ／ＨＡ５１２の間で交換されたセキュリティ・キーにより署名された接続認証データを有する。ヘッダ５０９Ｅは望ましいフィールドであるが、必須ではない。

第３のヘッダが新しいモビリティ拡張ヘッダ５１０Ｅであり、ヘッダ５１０Ｅは最初に標準のモビリティ拡張ヘッダ（Standard fields of mobility extension Header）５１１Ｅを有し、標準のモビリティ拡張ヘッダ５１１Ｅは、プロトコル番号、モビリティ・ヘッダタイプ、チェックサムなどを含む。新しいモビリティ拡張ヘッダ５１０Ｅはさらに３つの標準のフィールド５１２Ｅ、５１３Ｅ、５１４Ｅを有する。第１のフィールド（Floating Prefix）５１２Ｅは、垂直ハンドオフ時に一義的に使用する浮動プリフィックスを示す。もし多くの浮動プリフィックスがある場合にはこのフィールド５１２Ｅは大きくなる。ただし、複数の浮動プリフィックスがある場合には、その数を示すフィールドがメッセージ内にあるべきである。次のフィールド（Access Technology type 1）５１３Ｅは、垂直ハンドオフ時の第１のアクセス技術タイプ（ＷＬＡＮ）を示し、３番目のフィールド（Access Technology type 2）５１４Ｅは、垂直ハンドオフ時の第２のアクセス技術タイプ（ＷｉＭＡＸ）を示す。ここで、新しいモビリティ拡張ヘッダ５１０Ｅのフィールドを構成する方法は多く存在することを強調したい。ただし、ここでは、望ましい１つの方法であるパケット５１５Ｅを示す。

（ｃ）図３Ｃは、最適化要求メッセージを送信するための第３の例としてＢＵメッセージのパケット５２３Ｅの構造を示す。図３Ｂと同様に、パケット５２３Ｅの最初のヘッダはＩＰｖ６ヘッダ（IPv6 Header）５１６Ｅであり、次のヘッダは望ましくは接続認証ヘッダ（Authentication Header）５１７Ｅである。接続認証ヘッダ５１７Ｅの後にＢＵモビリティ拡張ヘッダ（Binding Update mobility extension Header）５１８Ｅが続く。ヘッダ５１８Ｅの最初のフィールドは標準のＢＵ拡張ヘッダ（Standard fields of binding update extension Header）５１９Ｅであり、例えば存続期間、シーケンス番号などのＢＵ内の標準の全てのフィールドを含む。

標準のＢＵ拡張ヘッダ５１９Ｅの後に新しいオプション・フィールド（Floating Prefix）５２０Ｅ、（Access Technology type 1）５２１Ｅ、（Access Technology type 2）５２２Ｅが設けられている。図３Ｂと同様に、最初のオプション・フィールド（Floating Prefix）５２０Ｅは、垂直ハンドオフ時に一義的に使用する浮動プリフィックスを示す。また、２番目のオプション・フィールド（Access Technology type 1）５２１Ｅは、垂直ハンドオフ時の第１のアクセス技術タイプ（ＷＬＡＮ）を示し、３番目のオプション・フィールド（Access Technology type 2）５２２Ｅは、垂直ハンドオフ時の第２のアクセス技術タイプ（ＷｉＭＡＸ）を示す。なお、浮動プリフィックスが適用されるインタフェースを示すために含まれているＡＴＴフィールドは、必ずしも２つである必要はなく、適用されるインタフェースが１つしかない場合は１つだけ含まれ、３つ以上のインタフェースに対して適用される場合は、３つ以上含まれる。

＜ＭＮの動作＞
次に図４を参照してＭＮ５００の動作を説明する。ＭＮ５００はまず、ステップ５００Ａにおいて特定のアクセス技術タイプ（ＡＴＴ）経由で一定の時間、受信したい特定のフロー（プリフィックス）があるか否かをチェックする。もしＮＯであればステップ５０４Ａに分岐して、通常のＰＭＩＰｖ６の垂直ハンドオフを実行して、ＨＩ＝２と、垂直ハンドオフするインタフェースの識別子（Ｉｆ−ＩＤ）を含む垂直ハンドオフ・トリガメッセージを送信する。

他方、ステップ５００ＡにおいてＹＥＳであればステップ５０１Ａに進み、前述した最適化要求メッセージ５１６を送信する前に、そのプリフィックスを希望のＡＴＴ（ＷＬＡＮとＷｉＭＡＸ）経由で参照することが可能か否かをチェックする。ここで、ＭＮ５００は、接続中のドメインに関連するセル構造（以前に接続したネットワーク情報等）の情報を記憶している場合、ステップ５０１Ａにおいて、そのセル構造の情報を参照して、上記のチェックを実行してもよい。もしＹＥＳであればステップ５０２Ａに進んで、浮動プリフィックスを通知するための最適化要求メッセージ５１６を送信し、次いで終了する。このとき、浮動プリフィックスは、ＭＮ５００の安定している接続インタフェースを使用して通知される。

なお、ステップ５０１Ａは必ずしも実行する必要はない。また、ステップ５００Ａを開始するトリガとして、ＬＭＡ／ＨＡ５１２やＡＡＡサーバ等のネットワーク・エンティティから、浮動プリフィックスを選択することを要求する通知を受けた場合に、ステップ５００Ａで、ＭＮ５００が保持するプリフィックスの中から特定のＡＴＴで参照したいプリフィックスを選択するようにしてもよい。また、ＭＮ５００が保持するプリフィックスの中で、特定のプリフィックスを移動する垂直ハンドオーバが一定回数以上発生した場合に、そのプリフィックスを浮動プリフィックスとして選択するようにしてもよい。また、お互いが補完する関係にあるアクセスネットワークが存在する場合には、それらのアクセスネットワーク間で移動させるプリフィックスを選択し、そのプリフィックスを浮動プリフィックスとして登録してもよい。さらには、ＬＭＡ／ＨＡ５１２やＡＡＡサーバから、明示的に浮動プリフィックスを通知され、そのプリフィックスを浮動プリフィックスとして使用すると判断した場合に、その判断結果を通知するためのメッセージとして最適化要求メッセージ５１６を送信することを判断してもよい。また、ＭＮ５００の移動頻度や接続状態に応じて、浮動プリフィックスを選択してもよい。この場合、一定時間の間に発生するハンドオーバの回数（垂直ハンドオフ・トリガメッセージ５１８の送信回数）があらかじめ決められた回数を上回る場合に、浮動プリフィックスを選択し、最適化要求メッセージ５１６を送信することを判断してもよい。これにより、送信頻度が高い垂直ハンドオフ・トリガメッセージ５１８のパケットサイズを減少させることができる。

他方、ステップ５０１ＡにおいてＮＯであればステップ５０３Ａに分岐し、上記の所望のセル構造の情報をＬＭＡ／ＨＡ５１２又は不図示のＭＩＨ（Media Independent Hand-off）サーバから取得可能か否かチェックする。そして、もしＹＥＳであればステップ５０２Ａに進んで、浮動プリフィックスを通知するための最適化要求メッセージ５１６を送信する。ここで理解すべき重要な点は、ステップ５０３ＡにおけるＭＮ５００の判定が、何かの既に構成されている情報に基づくべきであることにある。例えばＭＮ５００は、ＭＩＨサーバを有するドメインに関する情報を有するかもしれないし、また、そのようなドメインではＬＭＡ／ＨＡ５１２がセルのタイプやセル構造の情報を有するかもしれない。ステップ５０３ＡにおいてＮＯであればステップ５０４Ａに分岐して、通常のＰＭＩＰｖ６の垂直ハンドオフ・トリガメッセージを送信する。

＜ＭＮの構成＞
次に図５を参照してＭＮ５００の構成について説明する。図５はＭＮ５００の構成を機能的に示すブロック図である。ここで、図５では、ＭＮ５００がＭＩＰｖ６モビリティ管理ユニット５０４Ｄを有するように記載されているが、第１の実施の形態のＭＮ５００は、単にＩＰｖ６ホストであるＭＮや、マルチホーミングをサポートする機能を有するＭＮを含む全てのタイプのＭＮに適用することができる。さらに、レイヤ２のプロトコルスタックにプリフィックスとそのプリフィックスに関連するフローの知性を与えた場合、レイヤ３を変更せずにレイヤ２に適用することができる。

図５に示すＭＮ５００はＭＩＰｖ６の機能的構成を示し、３つの主要なモジュールとして下位層プロトコル・モジュール５０６Ｄと、レイヤ３プロトコル・モジュール５０２Ｄと、上位層プロトコル・モジュール５０１Ｄを有する。下位層プロトコル・モジュール５０６Ｄは、ＭＮ５００のインタフェースＩｆ１、Ｉｆ２、Ｉｆ３に直接に関連している複数の下位レイヤ（層）プロトコルモジュール（不図示）を有し、例えばそのモジュールの数とインタフェースの数は同じである。下位層プロトコル・モジュール５０６Ｄはまた、インタフェースＩｆ１、Ｉｆ２、Ｉｆ３用の信号変調、コード化、圧縮、メディアアクセスコントロール及びリンク層コントロールなどを含む基本的なデータ通信に必要な全ての物理層とリンク層の機能を有する。

下位層プロトコル・モジュール５０６Ｄはさらに、２つの異なるアクセス技術タイプの間の垂直ハンドオフ用として１つのプリフィックスを浮動プリフィックスとして割り当てるための最適化要求メッセージ５１６をサポートする下位層垂直ハンドオフ・トリガユニット５０７Ｄを有する。基本的には、レイヤ３の垂直ハンドオフ決定ユニット５０５Ｄが最適化要求メッセージ５１６、及び垂直ハンドオフ・トリガメッセージ５１８の送信を決定すると、この情報及び関連するパラメータがインタフェース５０８Ｄを経由してトリガユニット５０７Ｄに送られる。最適化要求メッセージ５１６をＭＡＧ／３ＧＰＰ５１３に送信するレイヤは、実際にはトリガユニット５０７Ｄによるレイヤ２である。なお、最適化要求メッセージは必ずしもレイヤ２に備える必要はなく、本発明の範囲を逸脱しない範囲でレイヤ３に備えることができることは明らかである。トリガユニット５０７Ｄは、レイヤ３で決定された情報を含む最適化要求メッセージ５１６、及び垂直ハンドオフ・トリガメッセージ５１８を直接にＭＡＧ／３ＧＰＰ５１３に送信する。トリガユニット５０７Ｄから送信される最適化要求メッセージ５１６、及び垂直ハンドオフ・トリガメッセージ５１８のあて先アドレスとしては、ＭＡＧ／３ＧＰＰ５１３のリンク層アドレスが使用される。

もし、垂直ハンドオフ・トリガユニット５０７Ｄがレイヤ３プロトコル・モジュール５０２Ｄに備えられている場合には、最適化要求メッセージ５１６のパケットのあて先アドレスとして、ＭＡＧ／３ＧＰＰ５１３のリンクローカルアドレスがセットされて下位層プロトコル・モジュール５０６Ｄに送られる。この場合の下位層プロトコル・モジュール５０６Ｄの主な機能は、そのパケットをレイヤ２を用いてカプセル化することである。

レイヤ３プロトコル・モジュール５０２Ｄは３つのサブモジュールとして、ＩＰｖ６ルーティング・ユニット５０３Ｄと、ＭＩＰｖ６モビリティ管理ユニット５０４Ｄと、上記の垂直ハンドオフ決定ユニット５０５Ｄを有する。主要な機能であるＩＰｖ６ルーティング・ユニット５０３Ｄは、主にパケット・ルーティング、アドレス構成、近隣発見（neighbor discovery）などを実行する。ＭＩＰｖ６モビリティ管理ユニット５０４ＤはＭＮ５００の１又は複数のインタフェースのモビリティ管理を処理する。垂直ハンドオフ決定ユニット５０５Ｄは、最適化要求メッセージ５１６で送信される垂直ハンドオフ用のプリフィックスと必要なパラメータを決定する。

また、垂直ハンドオフ決定ユニット５０５Ｄは、垂直ハンドオフ・トリガメッセージ５１８を送信することを決定する。具体的な処理内容としては、垂直ハンドオフを実行する際に、垂直ハンドオフ・トリガメッセージ５１８を送信するインタフェース（ハンドオフ先となるインタフェース）が接続しているネットワークが、最適化要求メッセージ５１６で登録したアクセス技術タイプに該当するネットワークであるか否かを確認し、該当するネットワークである場合には、垂直ハンドオフ・トリガメッセージ５１８の中に、送信に使用するインタフェースのインタフェース識別子を含めない垂直ハンドオフ・トリガメッセージ５１８を生成し、送信する。一方、登録したアクセス技術タイプに該当しないネットワークである場合には、垂直ハンドオフ・トリガメッセージ５１８の中に、送信に使用するインタフェースのインタフェース識別子を含めた垂直ハンドオフ・トリガメッセージ５１８を生成し、送信する。

さらに詳しく言えば、垂直ハンドオフ決定ユニット５０５Ｄは、ネットワークとの接続が切断されたインタフェース、あるいはネットワークとの接続が切断されそうなインタフェースがあるときに、そのインタフェースが接続しているネットワーク、あるいは接続していたネットワークが、最適化要求メッセージ５１６で登録したアクセス技術タイプに該当するネットワークであるか否かを確認する。その結果、該当するネットワークであった場合には、同じ最適化要求メッセージ５１６で登録した別のアクセス技術タイプへ接続しているインタフェースが存在するか否かを確認し、存在する場合には、そのインタフェースを垂直ハンドオフ・トリガメッセージの送信に使用するインタフェースとして選択し、選択したインタフェースのインタフェース識別子を含まない垂直ハンドオフ・トリガメッセージ５１８を生成し、送信する。一方、存在しない場合には、同じ最適化要求メッセージ５１６で登録していない他のネットワークへ接続しているインタフェースを使用し、そのインタフェースのインタフェース識別子を含む垂直ハンドオフ・トリガメッセージ５１８を送信する。

また別の決定方法として、垂直ハンドオフ決定ユニット５０５Ｄは、ネットワークに新たに接続したインタフェース、あるいはネットワークと新たに接続されそうなインタフェースがあるときに、そのインタフェースが接続しているネットワーク、あるいは接続しそうなネットワークが、最適化要求メッセージ５１６で登録したアクセス技術タイプに該当するネットワークであるか否かを確認する。その結果、該当するネットワークであった場合には、同じ最適化要求メッセージ５１６で登録した別のアクセス技術タイプへ接続しているインタフェースが存在するか否かを確認し、存在する場合には、ネットワークに新たに接続したインタフェースを垂直ハンドオフ・トリガメッセージの送信に使用するインタフェースとして選択し、選択したインタフェースのインタフェース識別子を含まない垂直ハンドオフ・トリガメッセージ５１８を生成し、送信する。一方、存在しない場合には、同じ最適化要求メッセージ５１６で登録していない他のネットワークへ接続しているインタフェースを使用し、そのインタフェースのインタフェース識別子を含む垂直ハンドオフ・トリガメッセージ５１８を送信する。上位層プロトコル・モジュール５０１Ｄは、トランスポート層やアプリケーション層のプロトコルを実行する。

＜ＬＭＡ／ＨＡの動作＞
次に図６を参照してＬＭＡ／ＨＡ５１２の動作について説明する。ＬＭＡ／ＨＡ５１２はまず、ＭＡＧからのＰＢＵメッセージを受信するとステップ５００Ｃの処理を実行する。ステップ５００ＣではそのＰＢＵメッセージが、ＬＭＡ／ＨＡ５１２に対して登録する垂直ハンドオフ規則が含まれていない通常の垂直ハンドオフ・トリガメッセージに関するものか否かをチェックする。もしＹＥＳであればステップ５０２Ｃに分岐して、通常の垂直ハンドオフ処理を実行し、バインディングキャッシュ・エントリをチェックしてＭＮ５００の古いインタフェースに関連するプリフィックスを新しいインタフェースに与える。

ステップ５００ＣにおいてＮＯであればステップ５０１Ｃに進んで、そのＰＢＵメッセージが、浮動プリフィックスに対する静的な垂直ハンドオフのための規則を含む新しい最適化要求メッセージか否かをチェックする。もしＹＥＳであればステップ５０３Ｃに分岐して、受信メッセージ内の浮動プリフィックスとアクセス技術タイプ（ＷＬＡＮ及びＷｉＭＡＸ）をバインディングキャッシュに登録する。ここで、ＬＭＡ／ＨＡ５１２は浮動プリフィックスとアクセス技術タイプを登録するために、バインディングキャッシュ・エントリ内に新しいフィールドを生成することができるが、ＬＭＡ／ＨＡ５１２がいかに登録するかは、構成次第である。

ステップ５０１ＣにおいてＮＯであればステップ５０４Ｃに進んで、そのＰＢＵメッセージが、最適化要求メッセージを受信して浮動プリフィックスに対する静的及び固定の垂直ハンドオフ規則を設定した後の垂直ハンドオフ・トリガメッセージか否かをチェックし、もしＹＥＳであればステップ５０５Ｃに分岐する。ステップ５０５Ｃでは、静的及び固定の垂直ハンドオフ規則を設定したＭＮであるか否か、また、ＷＬＡＮ経由でトリガされた垂直ハンドオフに対応するＷｉＭＡＸのバインディングが存在するか否か、又はその逆をチェックして、全てＹＥＳであれば、ＷＬＡＮ−ＷｉＭＡＸ間の垂直ハンドオフ時に一義的に使用する浮動プリフィックスを割り当てる。

他方、ステップ５０４ＣにおいてＮＯであればステップ５０６Ｃに進み、そのＰＢＵメッセージが、静的及び固定の垂直ハンドオフ規則の破棄を要求するメッセージか否かをチェックし、もしＹＥＳであればその垂直ハンドオフ規則を破棄し、また、ステップ５０２Ｃに進んで通常の垂直ハンドオフ処理を実行する。また、ステップ５０６ＣにおいてＮＯであればステップ５０７Ｃに進み、特別な方法による静的な垂直ハンドオフ処理を実行する。

＜ＬＭＡ／ＨＡの構成＞
次に図７を参照してＬＭＡ／ＨＡ５１２の構成について説明する。図７はＬＭＡ／ＨＡ５１２の構成を機能的に示すブロック図である。ＬＭＡ／ＨＡ５１２はレイヤ３プロトコル・モジュール５０１Ｆと、レイヤ３より下位の層の下位層プロトコル・モジュール５０６Ｆを有する。下位層プロトコル・モジュール５０６Ｆは、全てのデータリンク層とベースバンドレベルの機能を有する。レイヤ３プロトコル・モジュール５０１Ｆは４つのサブモジュールとして、ＰＭＩＰｖ６モビリティ管理ユニット５０２Ｆと、ＩＰｖ６ルーティング・ユニット５０３Ｆと、ＭＩＰｖ６モビリティ管理ユニット５０４Ｆと、垂直ハンドオフ・サポートユニット５０５Ｆを有する。ここで、図面では、これらのモジュール５０１Ｆ、５０６Ｆ及びユニット５０２Ｆ、５０３Ｆ、５０４Ｆ、５０５Ｆの間にはインタフェースが示されていないが、実際には存在する。

ＩＰｖ６ルーティング・ユニット５０３Ｆは、パケット・ルーティング、アドレス構成、近隣発見などの標準のＩＰｖ６のメカニズムを担当する。ＭＩＰｖ６モビリティ管理ユニット５０４Ｆは、ＭＩＰｖ６のホームエージェントと同様なメカニズムを担当し、例えばＣＭＩＰｖ６のＢＵメッセージの処理、そのＢＵメッセージに対するＡＣＫ信号（ＢＡメッセージ）の送信、データパケットのトンネル化、バインディングキャッシュの維持などを実行する。ＰＭＩＰｖ６モビリティ管理ユニット５０２Ｆは基本的に、ＰＭＩＰｖ６（非特許文献２）に開示されているＬＭＡの機能を備えている。このユニット５０２Ｆに関連する機能とは、種々のオプション（ＨＩオプション、アクセス技術オプションなど）を有するＰＢＵメッセージの処理、そのＰＢＵメッセージに対するＡＣＫ信号（ＰＢＡメッセージ）の送信、ＰＭＩＰｖ６ドメインに加入しているＭＮからのアップリンク・パケット及びダウンリンク・パケットの処理などである。ここで理解すべき重要な点は、ＰＭＩＰｖ６モビリティ管理ユニット５０２ＦとＭＩＰｖ６モビリティ管理ユニット５０４Ｆは、それぞれ基本的な機能が異なっているが、１つに結合したモジュールで構成し、また、ＰＭＩＰｖ６キャッシュとＣＭＩＰｖ６キャッシュの両方を１つのバインディングキャッシュが有するように構成することができることである。なおユニット５０２Ｆ、５０４Ｆを備えるには多くの方法があり、制限するものではない。

最後の垂直ハンドオフ・サポートユニット５０５Ｆは、最適化要求メッセージ５１６を処理して、１以上のＭＮ５００に関連する浮動プリフィックスに関する処理結果をＰＭＩＰｖ６キャッシュにセットする。ユニット５０５Ｆはさらに、ＭＮ５００が静的な垂直ハンドオフ規則を破棄するときにＭＮ５００から送信されるメッセージを処理する。ユニット５０５Ｆはさらに、垂直ハンドオフが実行されるときに、ＰＭＩＰｖ６モビリティ管理ユニット５０２Ｆから、浮動プリフィックスを割り当てるための問い合わせを受ける。この問い合わせにおけるパラメータとは、ＭＮ５００の現在のアクセス技術タイプと、垂直ハンドオフがトリガされたアクセス技術タイプと、浮動プリフィックスなどである。ユニット５０５Ｆはこれらのパラメータから、垂直ハンドオフの間に与えるプリフィックスを決定してＰＭＩＰｖ６モビリティ管理ユニット５０２Ｆに通知する。基本的に、浮動プリフィックスの割り当てについての決定は、垂直ハンドオフ・サポートユニット５０５Ｆが行うが、浮動プリフィックスを通知するＰＢＡメッセージは、ＰＭＩＰｖ６モビリティ管理ユニット５０２Ｆにより構成される。

本発明の第１の実施の形態により、最適化要求メッセージ５１６で継続的に使用するプリフィックスを登録したＭＮ５００は、垂直ハンドオフを実行する際に送信する垂直ハンドオフ・トリガメッセージの中に、移動させるプリフィックスを明示的に含める必要がなくなるという効果が得られる。

＜第２の実施の形態＞
次に、同じ図１を参照して第２の実施の形態について説明する。ここで、第１の実施の形態では、ＬＭＡ／ＨＡ５１２は、ＭＮ５００からの最適化要求メッセージ５１６により、ＭＮ５００の静的な垂直ハンドオフ規則を検知して垂直ハンドオフ・トリガメッセージのパケットサイズを最適化しているが、第２の実施の形態におけるＬＭＡ／ＨＡ５１２は、最適化要求メッセージ５１６を受信することなく、自らの判断で垂直ハンドオフ・トリガメッセージのパケットサイズを最適化する。第２の実施の形態では、ＬＭＡ／ＨＡ５１２は常に、プリフィックスＰ２がＷｉＭＡＸとＷＬＡＮのアクセス技術タイプを経由してハンドオフされることを注目及び学習してＭＮ５００の意図を予測し、ＭＮ５００に対して、シャットダウンするインタフェースの識別子を垂直ハンドオフ・トリガメッセージで通知しないように通知する。基本的に、ＬＭＡ／ＨＡ５１２は、ＭＮ５００の意図を識別して、ＬＭＡ／ＨＡ５１２が自ら静的な垂直ハンドオフ規則を決定し、ＭＮ５００に通知する。なお、情報サーバが保持するＭＮ５００に関する情報の中に静的な垂直ハンドオフ規則が含まれていてもよい。この場合、ＬＭＡ／ＨＡ５１２は情報サーバから取得した情報を基に、ＭＮ５００に静的な垂直ハンドオフ規則を通知する。

第２の実施の形態の主要な利点は、ＭＮ５００の処理（最適化要求メッセージ５１６の送信）を省略することにある。

＜第３の実施の形態＞
次に、第３の実施の形態について説明する。第３の実施の形態では、図１において、ＭＮ５００が静的な垂直ハンドオフ規則（最適化要求メッセージ５１６）をＭＮ５００のプロキシノードであるＭＡＧ／ＷｉＭＡＸ５０１又はＭＡＧ／３ＧＰＰ５１３に通知して、ＭＡＧ５０１又は５１３がその規則を他のＭＡＧ５０２、５０３にＣＴ（context transfer）で転送するものとする。ＭＮ５００は、静的な垂直ハンドオフ規則をドメイン５１１に通知することを決定すると、最初に例えばＭＡＧ／ＷｉＭＡＸ５０１に通知する。前述したように、最適化要求メッセージ５１６では、ＭＮ５００がＷＬＡＮ経由又はＷｉＭＡＸ経由で一義的に参照したいプリフィックスＰ２が通知される。このプリフィックスＰ２の情報をＭＡＧ／ＷｉＭＡＸ５０１に通知する想定に加えて、さらにＭＮ５００が次のアクセスルータ（ＡＲ）であるＭＡＧ／ＷＬＡＮ５０２の識別子を転送する。次のＡＲの識別子とは、ＷＬＡＮのＥＳＳＩＤ（Extended Service Set ID）と同様な何かの識別子である。したがって、ＭＡＧ／ＷｉＭＡＸ５０１はこの識別子を用いて、次のＭＡＧ／ＷＬＡＮ５０２のＩＰｖ６アドレスを識別する。基本的に、垂直ハンドオフ規則は、垂直ハンドオフの間は継続して与えられる必要がないが、次のＡＲの情報が古いＭＡＧ／ＷｉＭＡＸ５０１に与えられなければならない。したがって、新しいＭＡＧ５０２、５０３に送信されるトリガメッセージのパケットサイズを減少できるが、ＭＮ５００が次のＭＡＧ／ＷＬＡＮ５０２に垂直ハンドオフ規則の情報を送信するのはあまり有用ではない。ただし、完全にネットワーク制御の垂直ハンドオフが確立されている場合に有用である。

＜第４の実施の形態＞
次に図８を参照して第４の実施の形態について説明する。図８に示すネットワーク構成では、ＭＮ６００がインタフェースとして、３ＧセルラインタフェースＩｆ１とＷＬＡＮインタフェースＩｆ２の２つのインタフェースを有し、また、ＭＮ６００が軌跡６０４に沿って移動する際にＷＬＡＮインタフェースＩｆ２が接続（attach）するＷＬＡＮアクセスネットワーク６０１ａ、６０２ａ、６０３ａが連続していないことを想定している。このため、ＭＮ６００のＷＬＡＮインタフェースＩｆ２は、時点Ｔ０ではＷＬＡＮアクセスネットワーク６０１ａ及びＭＡＧ／ＷＬＡＮ６０１に接続（attach）し、時点Ｔ１ではＷＬＡＮアクセスネットワーク６０１ａ及びＭＡＧ／ＷＬＡＮ６０１との接続（connection）を失い、時点Ｔ２では次のＷＬＡＮアクセスネットワーク６０２ａ及びＭＡＧ／ＷＬＡＮ６０２に再び接続（attach）し、時点Ｔ３ではＷＬＡＮアクセスネットワーク６０２ａ及びＭＡＧ／ＷＬＡＮ６０２との接続（connection）を失い、時点Ｔ４では次のＷＬＡＮアクセスネットワーク６０３ａ及びＭＡＧ／ＷＬＡＮ６０３に再び接続（attach）するものとする。なお、本実施の形態におけるインタフェースＩｆ１、インタフェースＩｆ２は、任意のアクセス技術タイプでよい。例えば、３ＧセルラインタフェースＩｆ１はＷｉＭＡＸインタフェースＩｆ３であってもよいし、さらには、ＷＬＡＮインタフェースＩｆ２はＷｉＭＡＸインタフェースＩｆ３であってもよい。

＜時点Ｔ０＞
時点Ｔ０におけるＭＮ６００は、３ＧセルラインタフェースＩｆ１及びＭＡＧ／３ＧＰＰ６１８経由のＲＡメッセージ６０５でプリフィックスＰ１を参照し、また、ＷＬＡＮインタフェースＩｆ２及びＭＡＧ／ＷＬＡＮ６０１経由のＲＡメッセージ６０６でプリフィックスＰ２を参照している。
＜時点Ｔ１＞
次にＭＮ６００が軌跡６０４に沿って移動して、時点Ｔ１ではＷＬＡＮインタフェースＩｆ２がＭＡＧ／ＷＬＡＮ６０１との接続（connection）を失う。この場合、ＭＮ６００は、ＨＩフラグ（＝２）のみを有する垂直ハンドオフ・トリガメッセージ６２１を３ＧセルラインタフェースＩｆ１経由でＭＡＧ／３ＧＰＰ６１８に送信する必要がある。

ここで理解すべき重要な点は、ＭＮ６００が２つのインタフェースＩｆ１、Ｉｆ２のみを有するので、ＭＮ６００が垂直ハンドオフ・トリガメッセージ６２１をＭＡＧ／３ＧＰＰ６１８に送信するときにＷＬＡＮインタフェースＩｆ２の識別子の情報をメッセージ６２１で通知することなく、プリフィックスＰ２が３ＧセルラインタフェースＩｆ１に移されることにある。この理由は、ＬＭＡ／ＨＡ６１９では、ＭＡＧ／３ＧＰＰ６１８から不図示の新しいＰＢＵメッセージ（ＨＩ＝２）が到着したときには、ＭＡＧ／ＷＬＡＮ６０１及びＭＮ６００に関する１つのバインディングキャッシュ・エントリのみが存在するからである。このため、時点Ｔ１では、ＭＮ６００はトリガメッセージ６２１の送信後に、ＭＡＧ／３ＧＰＰ６１８から受信するＲＡメッセージ６０７でプリフィックスＰ１、Ｐ２を参照する。なお、不図示ではあるが、時点Ｔ０において、ＭＮ６００は、プリフィックスＰ２を浮動プリフィックスとして指定した最適化要求メッセージをＭＡＧ／３ＧＰＰ６１８経由で、又は直接ＬＭＡ／ＨＡ６１９へ送信する。また、時点Ｔ０として、ＭＮ６００の３ＧＰＰインタフェースＩｆ１がＭＡＧ／３ＧＰＰ６１８に接続して２つのコネクション（ＰＤＮ（Packet Data Network）コネクション）を確立しており、それぞれのコネクションに対してプリフィックスＰ１とＰ２が割り当てられている状態であってもよい。この場合、時点Ｔ０では、３ＧセルラインタフェースＩｆ１で確立されているコネクションののうち、Ｐ２が割り当てられているコネクションをＷＬＡＮインタフェースＩｆ２へ移すコネクション（浮動コネクション）であることを示すために、ＭＮ６００は、Ｐ２が割り当てられているコネクションに関連付けられる識別情報（コネクションＩＤ）を含む最適化要求メッセージをＬＭＡ／ＨＡ６１９に送信し、登録する。なお、識別情報としては、プリフィックスＰ２を用いてもよい。そして、時点Ｔ２、Ｔ４では、ＷＬＡＮインタフェースＩｆ２から垂直ハンドオフ・トリガメッセージが送信され、プリフィックスＰ２が割り当てられているコネクションのみが移される。また、３ＧＰＰネットワークへのコネクション確立手続中に、プリフィックスＰ２がＷＬＡＮインタフェースＩｆ２で使用する浮動プリフィックスであることがＭＮ６００に通知されてもよい。この通知を受けたＭＮ６００は、ＷＬＡＮインタフェースＩｆ２、ＷｉＭＡＸインタフェースＩｆ３で垂直ハンドオフ・トリガメッセージを送信する際には、プリフィックスＰ２を含める必要がないと判断する。

＜時点Ｔ２＞
ここで、ＭＮ６００が軌跡６０４に沿ってさらに移動して、時点Ｔ２で新しいＷＬＡＮアクセスネットワーク６０２ａのＭＡＧ／ＷＬＡＮ６０２を発見したとき、ＭＮ６００がプリフィックスＰ２用の垂直ハンドオフを希望するものとする。なお、この想定では基本的に、ＭＮ６００は常に（一義的に）、プリフィックスＰ２をＷＬＡＮインタフェースＩｆ２経由で希望し、また、プリフィックスＰ１を３ＧセルラインタフェースＩｆ１経由で希望するものとする。したがって、ＭＮ６００は時点Ｔ２では、ＭＡＧ／ＷＬＡＮ６０２における垂直ハンドオフをトリガして、垂直ハンドオフ・トリガメッセージ６２２でプリフィックスＰ２をＭＡＧ／ＷＬＡＮ６０２に通知する。ここでのトリガメッセージ６２２は新しいタイプの信号である。その理由は、３ＧセルラインタフェースＩｆ１経由で得られたプリフィックスＰ１、Ｐ２からプリフィックスＰ２を選択してＷＬＡＮインタフェースＩｆ２に移すからである。

ここで理解すべき重要な点は、この動作が非特許文献２に記載されている動作と異なることである。図８に示す第４の実施の形態では、ＭＮ６００が３ＧセルラインタフェースＩｆ１に関連する他のプリフィックスＰ１を移すことなく、ＷＬＡＮインタフェースＩｆ２経由で参照したいプリフィックスＰ２を垂直ハンドオフする。この動作では、ＭＮ６００が垂直ハンドオフ・トリガメッセージ６２２内に新しいＨＩフラグを使用し、ＬＭＡ／ＨＡ６１９がこの新しいＨＩフラグとプリフィックスＰ２を参照して正しいプリフィックスＰ２をＰＢＡメッセージ（不図示）でＭＡＧ／ＷＬＡＮ６０２に通知する必要がある。

ここで理解すべき重要な点は、ＨＩフラグが上記の新しい値にセットされない場合、ＬＭＡ／ＨＡ６１９がＭＡＧ／ＷＬＡＮ６０２からのＰＢＵメッセージ（不図示）を非特許文献２に記載されている通常の動作で処理して、プリフィックスＰ１、Ｐ２の両方をＭＡＧ／ＷＬＡＮ６０２に割り当てることである。非特許文献２のドラフトによれば、２つのインタフェースＩｆ１、Ｉｆ２を有するＭＮ６００がＷＬＡＮ経由の垂直ハンドオフを実行するときには、３ＧセルラインタフェースＩｆ１に関連する全てのプリフィックスがＷＬＡＮインタフェースＩｆ２にハンドオーバされる。基本的に、ＰＭＩＰｖ６のベースのドラフトによれば、現在登録されているインタフェースに関連する全てのプリフィックスを垂直ハンドオフ中に新しいインタフェースに移す。したがって、この想定では、ＭＮ６００が２つのインタフェースＩｆ１、Ｉｆ２を有する場合、あるプリフィックスを移すときには新しいＨＩオプションが必要である。このため、特定のプリフィックスＰ２を必要とするＭＮ６００の希望をＬＭＡ／ＨＡ６１９に指示する必要があり、プリフィックスＰ２と新しいＨＩオプションがＭＡＧ／ＷＬＡＮ６０２でＰＢＵメッセージ（不図示）に挿入されてＬＭＡ／ＨＡ６１９に送信される。なお時点Ｔ２においてトリガメッセージ６２２を受けた際に、ＬＭＡ／ＨＡ６１９の判断で、３ＧセルラインタフェースＩｆ１に割り当てられているプリフィックスＰ１、Ｐ２のうち、以前ＷＬＡＮインタフェースに割り当てられていたプリフィックスであるＰ２を選択してＭＮ６００へ割り当ててもよい。この場合、ＬＭＡ／ＨＡ６１９は、プリフィックスＰ２が３ＧセルラインタフェースＩｆ１に移された後でも、Ｐ２が以前ＷＬＡＮインタフェースＩｆ２に割り当てられていたものであることを記憶しておく。これにより、ＭＮ６００はトリガメッセージ６２２に新しいＨＩフラグを使用する必要がなくなる。なお、ＭＮ６００は、３Ｇネットワーク上のＡＮＤＳＦ（Access Network Discovery and Selection Function）サーバから取得しているハンドオーバ情報（Inter-system mobility policy、Access Network Discovery information）の中に、ＷＬＡＮインタフェースＩｆ２に割り当てられたプリフィックスを、垂直ハンドオーバ後も引き続き使用するプリフィックス（浮動プリフィックス）として使用することが明記されている場合には、移動させるプリフィックスを示す情報（インタフェース識別子又はプリフィックスＰ２）を含めずにトリガメッセージ６２２を送信する。これにより、トリガメッセージ６２２のメッセージサイズを減らすことができる。

＜時点Ｔ３＞
さらなる想定として、ＭＮ６００がＰＭＩＰｖ６ドメイン６２０内をローミングして、時点Ｔ３でＷＬＡＮインタフェースＩｆ２が再びＷＬＡＮアクセスネットワーク６０２ａとの接続（connection）を失い、ＭＮ６００はインタフェースＩｆ１が接続（connect）されるのみとする。ここでも同様に、ＭＮ６００は希望のプリフィックスＰ２と新しいＨＩオプションを用いてプリフィックスＰ２の垂直ハンドオフを実行する。

この新しいフラグは、１つのプリフィックス、又は複数のプリフィックスが選択された１つのプリフィックス・グループに対する３ＧネットワークとＷＬＡＮの間の垂直ハンドオフする場合に特徴がある。ここで、３ＧネットワークとＷＬＡＮの間の垂直ハンドオフでは、通常の垂直ハンドオフ・フラグ（ＨＩ＝２）が使用される。本実施の形態の利点とは、垂直ハンドオフするプリフィックスが選択され、この選択されたプリフィックスに対してのみ垂直ハンドオフがトリガされる。本実施の形態は、ＭＮ６００が２つのインタフェースＩｆ１、Ｉｆ２を有する場合の新しい方法である。その理由は、垂直ハンドオフするインタフェースＩｆ２の識別子を通知する必要がないからであり、このため、トリガメッセージのパケットサイズを減少することができる。

＜ＭＮの処理＞
図９を参照してＭＮ６００の動作を説明する。まず、ステップ６００Ａにおいて例えばＷＬＡＮ経由で参照したい特定のプリフィックスがあるか否かをチェックする。もしＮＯであればステップ６０３Ａに分岐して、垂直ハンドオフする必要がある場合に通常の垂直ハンドオフ処理を実行し、次いでステップ６００Ａに戻る。すなわちステップ６０３Ａでは、２つのインタフェースＩｆ１、Ｉｆ２用のＨＩ＝２付きの垂直ハンドオフ・トリガメッセージを送信する。基本的に、インタフェースが２つの場合、インタフェースＩｆ１、Ｉｆ２の識別子は送信する必要はなく、ＰＢＵメッセージはＨＩオプションのみで十分である。

ステップ６００ＡにおいてＹＥＳであればステップ６０２Ａに進み、その参照したいプリフィックスと新しいＨＩオプションで垂直ハンドオフをトリガ（トリガメッセージを送信）し、次いでステップ６０１Ａに進む。ステップ６００ＡにおいてＮＯであればステップ６０１Ａに分岐し、その特定のプリフィックスをＷＬＡＮ経由で参照したいという希望がまだあるか否かをチェックする。例えばある音声コールがその特定のプリフィックスを使用して開始する場合には、ステップ６０１Ａの判定はＹＥＳとなってステップ６０３Ａに進み、通常の垂直ハンドオフ処理を実行する。また、ステップ６０１Ａの判定がＮＯの場合にはステップ６００Ａに戻る。

＜第５の実施の形態＞
次に図１０を参照して第５の実施の形態について説明する。図１０に示すネットワーク構成は図８とほぼ同じであるが、ＭＮ７００がインタフェースとして、３ＧセルラインタフェースＩｆ１とＷＬＡＮインタフェースＩｆ２の２つのインタフェースを有し、また、ＭＮ７００が軌跡７０４に沿って移動する際にＷＬＡＮインタフェースＩｆ２が接続（attach）するＷＬＡＮアクセスネットワーク７０１ａ、７０２ａ、７０３ａが連続していることを想定している。このため、ＭＮ７００のＷＬＡＮインタフェースＩｆ２は、時点Ｔ０ではＭＡＧ／ＷＬＡＮ７０１に接続（attach）し、時点Ｔ１ではＭＡＧ／ＷＬＡＮ７０１からＭＡＧ／ＷＬＡＮ７０２へ接続（connection）を切り替え、時点Ｔ２では次のＭＡＧ／ＷＬＡＮ７０２に接続（attach）し、時点Ｔ３ではＭＡＧ／ＷＬＡＮ７０２からＭＡＧ／ＷＬＡＮ７０３へ接続（connection）を切り替え、時点Ｔ４では次のＭＡＧ／ＷＬＡＮ７０３に接続（attach）するものとする。なお、本実施の形態におけるインタフェースＩｆ１、インタフェースＩｆ２は、任意のアクセス技術タイプでよい。例えば、３ＧセルラインタフェースＩｆ１はＷｉＭＡＸインタフェースＩｆ２であってもよいし、さらには、ＷＬＡＮインタフェースＩｆ２はＷｉＭＡＸインタフェースＩｆ３であってもよい。

第４、第５の実施の形態の違いを以下に示す。第４の実施の形態では、プリフィックスＰ２が垂直ハンドオフの間にＭＡＧ／３ＧＰＰ６１８からＭＡＧ／ＷＬＡＮ６０２に通知されない場合には、ＬＭＡ／ＨＡ６１９がプリフィックスＰ１、Ｐ２をＷＬＡＮインタフェースＩｆ２に送信する。一方、第５の実施の形態では、このような継続的なシグナリングを減少する。その理由は、第５の実施の形態においても、２つのインタフェースＩｆ１、Ｉｆ２の垂直ハンドオフ規則が非常に静的であり、ＭＮ６００が非常に静的なパターンで垂直ハンドオフを実行しているからである。この規則では、ＭＮ６００がＷＬＡＮに到達すると常にプリフィックスＰ２を移している。

そこで、第５の実施の形態では、時点Ｔ０におけるＭＮ７００は、この静的な規則を知得すると、垂直ハンドオフの最適化要求メッセージ７０５をＭＡＧ／３ＧＰＰ７０７に送信する。ＭＡＧ／３ＧＰＰ７０７は、メッセージ７０５の内容をシグナリング・メッセージ７０６でＬＭＡ／ＨＡ７１８に転送する。メッセージ７０５は送信情報として、例えばＭＮ７００がＷＬＡＮに到達したときにはプリフィックスＰ２がＷＬＡＮインタフェースＩｆ２に移されること、さもなければ３ＧセルラインタフェースＩｆ１に移されることを希望している旨の垂直ハンドオフ情報を含む。つまり、ＭＮ７００は、浮動プリフィックスとしてプリフィックスＰ２が設定された最適化要求メッセージを送信する。ＭＮ７００がトリガメッセージ７０５でＬＭＡ／ＨＡ７１８に希望する主な内容は、垂直ハンドオフ・トリガメッセージがＷＬＡＮインタフェースＩｆ２経由で来たときにはプリフィックスＰ２をＷＬＡＮインタフェースＩｆ２に移し、また、垂直ハンドオフ・トリガメッセージが３ＧセルラインタフェースＩｆ１経由で来たときにはプリフィックスＰ２を３ＧセルラインタフェースＩｆ１に移すことである。この場合、最適化要求メッセージ７０５、及びシグナリング・メッセージ７０６には、プリフィックスＰ２を継続的に利用するインタフェースとして、３ＧインタフェースＩｆ１とＷＬＡNインタフェースＩｆ２の情報が含まれる。このルールがプリセットされると、ＭＮ７００はＰＭＩＰｖ６ドメイン７１９内をローミング中には、プリフィックスＰ２を有する垂直ハンドオフ・トリガメッセージを継続して送信する必要がない。なお、時点Ｔ０として、ＭＮ７００の３ＧＰＰインタフェースＩｆ１がＭＡＧ／３ＧＰＰ７０７に接続して２つのコネクション（ＰＤＮ（Packet Data Network）コネクション）を確立しており、それぞれのコネクションに対してプリフィックスＰ１とＰ２が割り当てられている状態であってもよい。この場合、時点Ｔ０では、３ＧセルラインタフェースＩｆ１で確立されているコネクションののうち、Ｐ２が割り当てられているコネクションをＷＬＡＮインタフェースＩｆ２へ移すコネクション（浮動コネクション）であることを示すために、ＭＮ７００は、Ｐ２が割り当てられているコネクションに関連付けられる識別情報（コネクションＩＤ）をＬＭＡ／ＨＡに登録する。なお、識別情報としては、本実施の形態で述べているように、プリフィックスＰ２を用いてもよい。そして、時点Ｔ２、Ｔ４では、ＷＬＡＮインタフェースＩｆ２から垂直ハンドオフ・トリガメッセージが送信され、プリフィックスＰ２が割り当てられているコネクションのみが移される。また、３ＧＰＰネットワークへのコネクション確立手続中に、プリフィックスＰ２がＷＬＡＮインタフェースＩｆ２で使用する浮動プリフィックスであることがＭＮ５００に通知されてもよい。この通知を受けたＭＮ５００は、ＷＬＡＮインタフェースＩｆ２で垂直ハンドオフ・トリガメッセージを送信する際には、プリフィックスＰ２を含める必要がないと判断する。

なお、最適化要求メッセージ７０５として、継続的に使用するプリフィックスのみを指定して、アクセス技術タイプ（ＡＴＴ）を含まない最適化要求メッセージ７０５を用いてもよい。この場合、ＬＭＡ／ＨＡ７１８は、垂直ハンドオフ・トリガメッセージを送信したインタフェースのアクセス技術タイプにかかわらず、最適化要求メッセージ７０５で指定されたプリフィックスを、移動するプリフィックスとして選択する。また、最適化要求メッセージ７０５には、通知するプリフィックスが、継続的に使用するプリフィックスであり、かつアクセス技術タイプに依存しないプリフィックスであることを示すために、フラグ等をメッセージに含めてもよい。つまり、３ＧインタフェースＩｆ１で使用しているプリフィックスＰ１を浮動プリフィックスとして指定してよく、通信中のフローに応じて任意のプリフィックスを浮動プリフィックスとして選択し、指定することが可能となる。

ＭＮ７００はＰＭＩＰｖ６ドメイン７１９内をローミング中に、時点Ｔ１、Ｔ２、Ｔ３などでそれぞれ垂直ハンドオフ・トリガメッセージを送信する。例えば時点Ｔ１では、ＨＩフラグが２の垂直ハンドオフ・トリガメッセージ７０８を３ＧセルラインタフェースＩｆ１経由でＬＭＡ／ＨＡ７１８に送信する。ＨＩフラグが２の場合とは通常動作を表し、したがって、ＬＭＡ／ＨＡ７１８はＨＩフラグ＝２を参照すると、ＭＡＧ／３ＧＰＰ７０７あてのＰＢＡメッセージ（不図示）でプリフィックスＰ１、Ｐ２を割り当てる。

ＭＮ７００はさらに移動して、時点Ｔ２では垂直ハンドオフするときには、プリフィックスＰ２も他のプリフィックスも通知する必要がなく、単に新しいＨＩフラグ付きの垂直ハンドオフ・トリガメッセージ７１２をＷＬＡＮインタフェースＩｆ２経由でＭＡＧ／ＷＬＡＮ７０２に送信すればよいだけである。ＬＭＡ／ＨＡ７１８は、この新しいＨＩフラグを、ＭＡＧ／ＷＬＡＮ７０２からＰＢＵメッセージ７１０で参照すると、同じくＰＢＵメッセージ７１０に含まれているアクセス技術タイプ（ＷＬＡＮ）が、最適化要求メッセージで登録されたアクセス技術タイプに該当する場合に、プリフィックスＰ２をＭＡＧ／ＷＬＡＮ７０２あてのＰＢＡメッセージ７１１で割り当てる。したがって、ＭＮ７００はプリフィックスＰ２をＭＡＧ／ＷＬＡＮ７０２からのＲＡメッセージ７０９で参照する。この新しいＨＩフラグにより、ＭＮ７００は垂直ハンドオフ規則の変更を明示的に記述する必要がない。垂直ハンドオフ規則が変更されると、ＨＩフラグが２の垂直ハンドオフ・トリガメッセージを送信する通常動作に移行する。ここで、当業者であれば、ＨＩフラグの数値は本発明の範囲を限定するものではないことは明らかである。ＨＩフラグの数値は、ＩＡＮＡ（Inter net Assigned Number Association）のような機関によって定義される。

なお、最適化要求メッセージで登録されたプリフィックスＰ２が、アクセス技術タイプに限定されないプリフィックスであり、かつ継続的に使用するプリフィックスとして登録されている場合には、新しいＨＩフラグを含むＰＢＵメッセージ７１０を受信したＬＭＡ／ＨＡ７１８は、アクセス技術タイプにかかわらず、プリフィックスＰ２をＭＡＧ／ＷＬＡＮ７０２あてのＰＢＡメッセージ７１１で割り当てる。なお、この場合ＨＩフラグが２の通常の垂直ハンドオフ・トリガメッセージであってもよい。これにより、ＭＮ７００は、最適化要求メッセージ７０５にアクセス技術タイプを含める必要がない。ＭＡＧ／ＷＬＡＮ７０２も同様に、ＰＢＵメッセージ７１０にアクセス技術タイプを含める必要がなくなる。なお、ＬＭＡ／ＨＡ７１８が、従来のＨＩフラグの値がセットされた垂直ハンドオフ・トリガメッセージ７１２であっても、プリフィックスを含まないトリガメッセージを受信したときに、プリセットされたルールに基づいたプリフィックスの選択が求められていることを認識することができる場合は、新しいＨＩフラグの値を用いる必要はない。

本発明の第５の実施の形態におけるＭＮ７００の構成は、本発明の第１の実施の形態におけるＭＮ５００の構成とほぼ同様であるため説明を省略する。なお、本発明の第５の実施の形態で想定しているＭＮ７００の２つのインタフェースは、ＭＮ７００が有する３つ以上のインタフェースのうちの２つであってもよい。また、アクセス技術タイプに限定されないプリフィックスで、かつ継続的に使用するプリフィックスとしてプリフィックスＰ２を登録するための最適化要求メッセージ７０５を用いる方法は、本発明の第1の実施の形態にも適用可能である。本発明の第５の実施の形態により、最適化要求メッセージ７０５で継続的に使用するプリフィックスを登録したＭＮ７００は、垂直ハンドオフを実行する際に送信する垂直ハンドオフ・トリガメッセージの中に、移動させるプリフィックスを明示的に含める必要がなくなるという効果が得られる。

＜第６の実施の形態＞
次に図１１Ａ及び図１１Ｂを参照して第６の実施の形態について説明する。図１１Ａは、ＭＮ８００が４つのインタフェースＩｆ１、Ｉｆ２、Ｉｆ３、Ｉｆ４を有し、また、ＬＭＡ／ＨＡ８０５にルーティングされるＰＭＩＰｖ６ドメインに接続（attach）されていることを示す。ここで、ＭＮ８００はプリフィックスＰ１をインタフェースＩｆ１及びＭＡＧ８０１経由で、プリフィックスＰ２をインタフェースＩｆ２及びＭＡＧ８０２経由で、プリフィックスＰ３をインタフェースＩｆ３及びＭＡＧ８０３経由で、プリフィックスＰ４をインタフェースＩｆ４及びＭＡＧ８０４経由で参照しているものとする。

今、ＭＮ８００は、インタフェースＩｆ１をシャットダウンすることを決定すると、最初のステップでは、垂直ハンドオフ・トリガメッセージ８０６（図のMN trigger→HI=2, If1）をインタフェースＩｆ２経由でＭＡＧ８０２に送信してプリフィックスＰ１を通知する。ＬＭＡ／ＨＡ８０５は、このトリガメッセージ８０６をＰＢＵメッセージ（不図示）で受信すると、ＰＢＡメッセージ（不図示）で応答をＭＡＧ８０２に送信し、ＭＡＧ８０２は応答メッセージ８０７（図のResponse→P1,P2）をＭＮ８００に送信する。基本的に、ＭＮ８００は応答メッセージ８０７でプリフィックスＰ１、Ｐ２の両方を参照する。ここで、何らかの理由で、ＭＮ８００がローミング中に、インタフェースＩｆ２の垂直ハンドオフを実行しなければならない場合、ＭＮ８００は再び、プリフィックスＰ１の情報又はインタフェースＩｆ２の識別子を継続して送信する必要がある。したがって、この送信情報を最適化する必要がある。

そこで、プリフィックスＰ１の情報を除去して、プリフィックスＰ１に関する情報がシステム内のどのＭＡＧにも維持されないようにする。図１１Ｂはその例を示す。基本的に、ＭＮ８１０は、プリフィックスＰ１を他のプリフィックスＰ２、Ｐ３、Ｐ４へバインドするためのメッセージ８１６をＬＭＡ／ＨＡ８１５に送信する。このため、プリフィックスＰ１用のルーティング・ステートがシステム内のどのＭＡＧにも維持されず、プリフィックスＰ１については垂直ハンドオフする必要がない。ただし、代わりに、ＭＮ８１０がプリフィックスＰ１のフローを送受信するために何らかのトンネル化手順が必要になる。プリフィックスＰ１のフローは、プリフィックスＰ２に関連するアドレスあてにトンネル化されて適切にルーティングされる。この方法による主な利点とは、プリフィックスＰ１に関するステートをシステム内のどのＭＡＧにも維持する必要がないことにある。ただし、プリフィックスＰ１に関連するアドレスあてのパケットを受信するためにトンネル化が必要になる。

以上、本発明について実施の形態を参照して説明したが、当業者であれば、本発明を逸脱しない種々の変形が可能であることは明らかである。例えば、本発明の実施の形態の説明に用いた各ネットワーク構成図に記載されているシステムとして、３ＧＰＰ−ＬＴＥ（the Third Generation Partnership Project Long Term Evolution ）プロジェクトが作業を行っているＳＡＥ（System Architecture Evolution）を想定することができる。図１に示すシステムとＳＡＥの間の関係をマッチングさせると、ＬＭＡ／ＨＡは、３ＧＰＰネットワーク内に存在するＰＤＮ−ＧＷ（Packet Data Network Gateway）であり、ＭＡＧ／３ＧＰＰはＳ−ＧＷ（Serving Gateway）である。また、ＭＡＧ／ＷｉＭＡＸはＮｏｎ３ＧＰＰネットワーク内に存在するｅＰＤＧ（Evolved Packet Data Gateway）であり、さらに、ＭＡＧ／ＷＬＡＮはＮｏｎ３ＧＰＰネットワーク内に存在するＡＧＷ（Access Gateway）であり、ＭＮはＵＥ（User Equipment）である。この場合、３ＧＰＰネットワークでは、ＧＴＰ（Generic Tunnelling Protocol）又はＰＭＩＰ（ＰＭＩＰ：Proxy Mobile IP）を使用してＬＭＡ／ＨＡへ接続し、Ｎｏｎ３ＧＰＰネットワークでは、ＰＭＩＰを使用してＬＭＡ／ＨＡへ接続される。３ＧＰＰネットワークにおいて、ＧＴＰを使用していても、本発明の実施の形態で説明した手法を適用することができる。また、例えば上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用などが可能性としてあり得る。

本発明は、モバイルノードが静的な垂直ハンドオフの規則を有する場合には、垂直ハンドオフを要求するシグナリングのパケットサイズを減少することができるという効果を有し、ＰＭＩＰｖ６のプロトコルが３ＧＰＰサービス・アーキテクチャ・イボリューション（ＳＡＥ）ローカルドメイン内に採用されたＰＭＩＰｖ６ドメインなどに利用することができる。

本発明は、複数のインタフェースを有するモバイルノードがローミングする場合に、モバイルノードのあるインタフェースに関連するプリフィックスを他のインタフェースに移す垂直ハンドオフ方法及び垂直ハンドオフシステムに関する。
本発明はまた、上記のモバイルノード及びそのホームエージェントに関する。

現在、多くの通信装置がＩＰｖ６（Internet Protocolversion 6）を用いて通信を行っている。また 、モバイル装置に対してモビリティサポートを提供するために、ＩＥＴＦ（Internet Engineering Task Force）は、非特許文献１に示すようなＭＩＰｖ６（Mobility Supportin IPv6）を開発している。非特許文献１におけるモビリティサポートは、ホームエージェント（ＨＡ）と呼ばれるエンティティをモバイルノード（ＭＮ）のホームネットワークに導入することにより実現している。ＭＮはＨＡに対し、外部リンクで取得した気付アドレス（ＣｏＡ）を、バインディング・アップデート（ＢＵ）メッセージと呼ばれるメッセージを用いて登録する。ＨＡはＢＵメッセージにより、ホームリンクで取得したアドレスであるホームアドレス（ＨｏＡ）とＭＮのＣｏＡの間にバインディング（位置情報）を生成することができる。ＨＡはバインディングにより、ＭＮのＨｏＡあてのメッセージをインタセプトし、ＭＮのＣｏＡあてのパケットにカプセル化して転送する。なお、このパケットカプセル化は、受信したパケットを新しいパケットのペイロードにセットする処理であり、パケットトンネル化として知られている。なお、ＭＩＰｖ６はＣｌｉｅｎｔであるＭＮがモビリティ管理を行うプロトコルであるため、ＣＭＩＰｖ６（Client Mobile IPv6）やＨＢＭ（Host Based Mobility）とも呼ばれる。

ＭＩＰｖ６における問題の１つは、ネットワーク接続（attachment）が変更するとき毎や、バインディングの有効期間が満了するときに、ＭＮがその１以上のＨＡと通信相手（Correspondent Node：ＣＮ）に対する登録を更新する必要があることにある。この更新により、高速で移動するＭＮが無線ネットワークに放出するシグナリングの負荷が増大する。さらに、ネットワーク接続（attachment）の変更毎にＣＮとの間で行うハンドオフ確立時間（経路最適化が使用されているとする）は、ネットワーク接続（attachment）の変更毎にＲＲ（Return Routability）メッセージとＢＵメッセージの送受信が必要となるため、多くの時間を要する。このため、フロー又はコネクションに関連するセッションの間、ハンドオフ確立にかなりの時間を要するので、ジッタやパケットロスが発生する。このようなジッタは、ＶｏＩＰ（Voice over IP）や、マルチメディア及びビデオストリーミングのようにリアルタイムなアプリケーションにとっては好ましくない。さらに、パケットロスは、重要なテキストやデータの情報を伝送するフローにとっては好ましくない。パケットロスはさらに、ＴＣＰ（Transmission Control Protocol）が重要なデータ、アプリケーションの転送に使用される場合、ＴＣＰのスループットを減少させる。

ＭＩＰｖ６の問題に注目すると、焦点は現在、ネットワークベースのローカル・モビリティ管理（Network-based Local Mobility-Management：ＮｅｔＬＭＭ）プロトコルにシフトされる。ＩＥＴＦのＮｅｔＬＭＭワーキンググループは、このプロトコルの作業を行っている。ネットワークベースのローカル・モビリティ管理は、地理的にローカルなネットワーク・セグメントに位置するＭＮのモビリティを、ＭＮそれ自体よりもネットワーク・エンティティにより管理することに言及している。

ＭＮにとって透過的なネットワークベースのローカル・モビリティ管理の目的を達成するために、ＭＮはローカルドメイン内のどこでも同じプリフィックスを参照することを必要とする。上記のプリフィックスは、ルーティング階層の上位に位置するルータから取得されなければならない。そのルータは望ましくは、ローカル・モビリティ管理の利点が取得可能なようにローカルドメイン内の全てのＭＮのデフォルト・ルーティングパスに位置する。上記のルータは、上記のプリフィックスのルートであって、上記のプリフィックスに対する到達性の情報すなわちルーティング情報（プリフィックスベースのルート）を有しなければならない。結果的に、このプリフィックスベースのルートは、ネットワーク・エンティティにより生成されなければならない。

ＮｅｔＬＭＭワーキンググループにより検討されている特別なネットワークベースのローカル・モビリティ管理プロトコルは、非特許文献２に開示されているＰＭＩＰｖ６（Proxy Mobile InternetProtocol version 6）である。ＰＭＩＰｖ６のプロトコルは主に、ＣＭＩＰｖ６（Client Mobile IPv6）スタックを有しない通常のＩＰｖ６ホストに対して、ネットワークのローカルな部分におけるモビリティ管理サービスを提供するために設計されており、ＮＢＭ（Network based Mobility）とも呼ばれる。にもかかわらず、ＰＭＩＰｖ６はＣＭＩＰｖ６スタックを有するノードにも有用である。その理由について説明すると、ＣＭＩＰｖ６スタックを有するＭＮが外部のＰＭＩＰｖ６ドメインに位置していて、そのローカルドメイン内のあるインタフェースを介して同じプリフィックス（外部のローカル・モビリティ・アンカー（ＬＭＡ）／ＨＡにおいてルーティングされる外部のＰＭＩＰｖ６ローカル・プリフィックス）を参照する場合、そのＭＮは如何なるグローバルな登録も実行する必要がない。さらに、上記のＣＭＩＰｖ６スタックを有するＭＮは、ホームドメイン内にローミングしたとき、地理的な位置を変更しているにもかかわらず、自身のホームネットワーク・プリフィックスを継続して参照して位置登録に参加する必要がない。なお、ＬＭＡとは、ＰＭＩＰv６を使用するＭＮの位置情報を管理するノードであり、その位置情報は後述するモバイル・アクセス・ゲートウェイ（ＭＡＧ）から登録される。また、ＬＭＡ／ＨＡとは、ＰＭＩＰｖ６におけるＬＭＡの機能とＭＩＰｖ６におけるＨＡの機能の両方を有するネットワークノードを指す。

以下に、非特許文献２に開示されているＰＭＩＰｖ６の概略を説明する。あるＭＮがあるＰＭＩＰｖ６ネットワークに接続（attach）したとき、そのＭＮは、モバイル・アクセス・ゲートウェイ（ＭＡＧ）とアソシエート中に、自身のネットワーク・アクセス識別子（ＮＡＩ）を提供する。ＭＡＧとは、ＭＮが直接に接続（attach）しているか又はＭＮが制御下にあるローカル・モビリティ・アンカー（ＬＭＡ）に対して、ＭＮのプロキシとしてローカルな登録を実行するルータ（プロキシノード）である。ＮＡＩは接続認証（Authentication）の目的のために、ＡＡＡ（Authentication, Authorization and Accounting）サーバに転送される。ＡＡＡサーバは、ＭＮのネットワーク接続（attachment）を資格認証（Authorize）すると、接続認証（Authentication）が成功したことをＭＡＧに通知するためにレスポンスを送り返す。上記のレスポンスでは、ＡＡＡサーバはさらに、ＬＭＡアドレスと、ＭＮがローカルドメイン内をローミング中に備える必要があるアドレス構成モード又は特別なポリシーのような幾つかのＭＮプロファイルを提供する。

ＭＡＧは上記のＭＮのパラメータを取得すると、プロキシＢＵ（ＰＢＵ）メッセージをＬＭＡに送信する。ＭＡＧはＰＢＵメッセージの応答であるプロキシ・バインディング確認（ＰＢＡ）メッセージから、ＭＮの接続（attach）しているインタフェースに関連するプリフィックスを取得した後、ホームリンク及びローカルホームリンクをエミュレートする。上記のようにＭＡＧが実行するＰＢＵメッセージすなわちローカルな登録は、このメッセージがＰＢＵメッセージであることを示すフラグのみを除いてＭＩＰｖ６のＢＵメッセージと同一である。ＰＢＵメッセージを実行することにより、ＭＮの到達性のステートがＬＭＡにおいて生成される。基本的には、ＬＭＡは、ＰＭＩＰｖ６ドメインで取得されたＭＮプリフィックスに対する到達性のステートを有し、このＭＮプリフィックスに対して到達可能なアドレスはＭＡＧのアドレスである。

ＭＮはステート有り又はステート無しのアドレス構成モードを用いて、ＰＭＩＰｖ６ドメインで受信したプリフィックスを用いてアドレスを構成する。各ＭＮはユニークなプリフィックスを取得するので、ＬＭＡにおけるプリフィックスベースのキャッシュは、ＭＮに十分に到達する。ＬＭＡに到着した各データパケットは、ＭＮに接続（connect）しているＭＡＧにトンネル化され、また、ＭＡＧに到着した各データパケットはＬＭＡにトンネル化される。ＭＡＧの近隣（neighbor）キャッシュテーブルは、ＭＮのＰＭＩＰｖ６ローカルアドレスと、ＭＮにパケットを伝送するのに使用されるリンク層アドレスをバインディングする。

非特許文献２に開示されているＰＭＩＰｖ６のプロトコルは、ＭＮに対して透過的なプロキシ・モビリティのサービスを提供するのに加えて、マルチホーミングのサービスを提供している。非特許文献２に記載されているマルチホーミング・サービスでは、複数のインタフェースを有するＭＮが全てのインタフェースを経由してＰＭＩＰｖ６ドメインに接続（attach）でき、また、レイヤ３のプロトコルを変更することなく、かつモビリティに関するシグナリングに参加することなくＰＭＩＰｖ６ドメイン内をローミングできる。基本的に、非特許文献２の現在のドラフトに記載されている方法では、マルチホーミングをサポートするために、ＬＭＡがＭＮのインタフェース毎にユニークなプリフィックスを与え、また、ＬＭＡがＭＮのインタフェースに関連するＰＭＩＰｖ６バインディングを個々のモビリティ・セッションとして維持する。ＰＭＩＰｖ６のマルチホーミングのプロトコルが保証すべきことは、複数のインタフェースを有するＭＮがローミングするときに、インタフェース毎に最初の接続（attach）中にユニークなプリフィックスを割り当てることと、完全に透過的なプロキシ・モビリティ管理サービスを提供するためには、上記のプリフィックスと、上記のプリフィックスを使用して確立されるセッションを、セッション品質を損なうことなく維持することである。

ここで、モビリティと、セルのレイアウト構造と、ＭＮの希望と、ＭＮの節電モード動作により、２つのハンドオフのイベントがある。１つ目は、ＭＮの特定のアクセス技術タイプのインタフェースがあるＭＡＧから切断（disconnect）し、そのインタフェースが移動して新しいＭＡＧに再接続（re-connect）する水平ハンドオフである。水平ハンドオフしているプリフィックスに関連するフローのセッションの連続性を維持するためには、ＭＮが水平ハンドオフ後に新しいＭＡＧに接続（attach）するときに同じプリフィックスを参照することが重要である。水平ハンドオフのイベントでは、ＬＭＡは同じプリフィックスを割り当てるために、次のＭＡＧ（新しいＭＡＧ）からのＰＢＵメッセージ内のインタフェース識別子又はアクセス技術タイプ（ＡＴＴ：Access Technology Type）と、ＰＢＵメッセージ内のハンドオフ識別子ＨＩ（＝３）のオプションを使用してもよい。このインタフェース識別子は、水平ハンドオフしているインタフェースの識別子か、又は新しいＭＡＧに接続（connect）中のインタフェースの識別子である。また、ＡＴＴは、接続するインタフェースの種類（セルラ、ＷｉＭＡＸ、ＷＬＡＮなど）を表す。一方、ハンドオフ識別子ＨＩは、指定する値によって、アドレスを維持するハンドオーバ接続であるか、アドレスを維持しない新規接続であるかなどを示すことができる。ここで重要な点は、水平ハンドオフの処理があまり複雑ではないことを理解すべきである。その理由は、ＬＭＡが、水平ハンドオフ中の新しいＰＢＵメッセージ内のインタフェース識別子又はＡＴＴを取得し、そのインタフェース識別子又はＡＴＴと同じ値を含むエントリをキャッシュ内で検索することにより同じプリフィックスを与えることができ、セッションの連続性が維持されるからである。また、ハンドオフ識別子ＨＩの値がハンドオーバであることを示す場合には、ＬＭＡは、自身が保持するＭＮに関する情報や、認証サーバやＭＮ情報管理サーバから取得した情報の中から、ＭＮに割り当てられているプレフィックスの情報を参照し、そのプレフィックスを再度ＭＮへ割り当てるべきと判断することができる。

しかしながら、ＬＭＡは理想的には、水平ハンドオフ用として上記のＨＩオプションを必要としない。その理由は、ＬＭＡが、新しいＭＡＧに接続（attach）しているインタフェースの識別子をキャッシュ内に存在するインタフェース識別子と単にマッチングするだけで水平ハンドオフを処理できるからである。非特許文献２には、水平ハンドオフをサポートするために複数の方法が示されている。しかし、水平ハンドオフをサポートする１つの方法は、その方法を他の方法に制限する必要はない。

次に、水平ハンドオフをサポートするために非特許文献２に記載されている幾つかの方法について簡単に説明する。もし、水平ハンドオフ中に参照される必要があるプリフィックスが新しいＰＢＵメッセージ内に添付されている場合、ＬＭＡは、そのプリフィックスに対するバインディングと、新しいＭＡＧに接続（connect）したインタフェース識別子と、ＮＡＩがキャッシュ内に存在するかをチェックする。もし存在する場合、ＬＭＡはＰＢＡメッセージで同じプリフィックスを割り当てる。

ところが、大抵の場合、水平ハンドオフを実行する際には、水平ハンドオフ後に参照するプリフィックスは、水平ハンドオフを実現するＰＢＵメッセージ内に添付する必要がない。水平ハンドオフ中のセッションの継続性を実現するためには、ＭＮは、プリフィックスなしでも、インタフェース識別子（Ｉｆ−ＩＤ）のオプションと、アクセス技術タイプ（ＡＴＴ：Access Technology Type）とＮＡＩを通知するだけで十分だからである。この場合、水平ハンドオフは、ＬＭＡが新しいＰＢＵメッセージ内のパラメータ（上記の新しいＭＡＧに接続（attach）したＩｆ−ＩＤ、ＡＴＴ及びＮＡＩ）と一致するパラメータを持つエントリが存在するか否かをチェックすることにより実行される。ＬＭＡが同じパラメータを持つエントリをキャッシュ内に発見した場合、そのキャッシュは、新しいＰＢＵメッセージ内の新しいエントリで更新される。ＬＭＡにおけるキャッシュ内の唯一の変更点は、ＰＢＵメッセージの気付アドレス（ＣｏＡ）が新しいＭＡＧに関連するＣｏＡに変更されることにある。この水平ハンドオフの詳細な動作は非特許文献２に記述されている。

ＭＮが実行するもう一つのタイプのハンドオフとして垂直ハンドオフ（Vertical hand-off）がある。非特許文献２に開示されている基本のドラフトには、１つの特定のタイプの垂直ハンドオフが記述されている。このタイプの垂直ハンドオフでは、ＭＮの特定のアクセス技術タイプ（ＡＴＴ）のインタフェースがあるＭＡＧから切断（disconnect）して、その切断したインタフェースに関連するフローが、電源がオンになってＰＭＩＰｖ６接続（attach）する別のアクセス技術タイプのインタフェースに移される。このタイプの垂直ハンドオフは多くの理由により発生することができる。その理由は、特定のアクセス技術タイプのドメインがカバーする範囲が不足していたり、ＭＮの希望であったり、ＭＮがあるインタフェースを節電のためにシャットダウンしたいからである。

水平ハンドオフ（horizontal hand-off）と比較して垂直ハンドオフが複雑な点は、ＬＭＡが垂直ハンドオフ用の正しいプリフィックスを与えるためには、ＭＮの別のインタフェースから行われる接続手続き（attach procedure）の中で提示されるパラメータが十分でないことにある。ここでの新しい接続（attachment）のパラメータとは、ＭＮの新しく電源がオンになったインタフェースのＩｆ−ＩＤ及びＡＴＴと、ＮＡＩとを意味する。ＭＮの複数のインタフェースが、ＬＭＡに接続（attach）しているＰＭＩＰｖ６バインディングを有する場合、垂直ハンドオフを実現するＰＢＵメッセージには、新しいインタフェースにハンドオフされるのに必要なプリフィックスか、又はシャットダウンするインタフェースのＩｆ−ＩＤを添付する必要がある。この理由は、ＬＭＡがどのプリフィックスが新しいインタフェースに移されるかを知得する必要があるからである。したがって、ＬＭＡに対し、シャットダウンするインタフェースを指示する情報を垂直ハンドオフ動作中に送信する必要がある。この情報は特に、同じＭＮの２つ以上のＰＭＩＰｖ６バインディングがＬＭＡに存在する場合に重要である。

ここで、ＭＮの接続（attach）しているインタフェースのパラメータ（上記の新しいＭＡＧに接続（attach）したＩｆ−ＩＤ、ＡＴＴ及びＮＡＩ）が十分な場合、つまり水平ハンドオフの場合は、通常のＰＭＩＰｖ６動作により実現可能である。したがって、水平ハンドオフを実現するためには、水平ハンドオフの接続（attachment）中にはさらに特別な情報（シャットダウンするインタフェースのＩＤ又は垂直ハンドオフで移動するプレフィックス／フローなど）は必要なく、問題はないことがわかる。

３ＧＰＰ（Third Generation Partnership Project）は、例えばワイヤレス・ローカルエリア・ネットワーク（ＷＬＡＮ）と、セルラネットワーク（第３世代（３Ｇ）、第３．９世代、第４世代、さらにはそれ以降の世代のセルラネットワーク）と、ＷｉＭＡＸ形式のワイヤレスのワイドエリア・ネットワーク（ＷＡＮ）のような種々の形式の無線アクセスネットワークを有するグローバルな異種ネットワーク構造について作業を行っている。なお、以下では３Ｇや３ＧＰＰが付加されている用語をいくつか用いているが、本明細書においてそれらはセルラであることを指しており、３Ｇに限らず、３．９Ｇや４Ｇ、さらにはそれ以降の世代を含むものとして用いている。グローバルな異種ネットワーク構造は、シームレスなモビリティを実現して、リアルタイムなビデオ、ＶｏＩＰ（Voice over IP）、情報、重要なデータなどの異種のアプリケーションサービスを高いサービス品質（Quality of Service）でサポートするのに有用である。非特許文献３には、ＰＭＩＰｖ６が３ＧＰＰローカルドメインにおけるローカル・モビリティ管理（ＬＭＭ）プロトコルとして採用されるであろうことが開示されている。３ＧＰＰローカルドメインは、３Ｇセルラネットワークと、信頼性のある又は信頼性のないＷＬＡＮアクセスネットワークと、ＷｉＭＡＸアクセスネットワークにより構成されるかもしれない。さらに、複数の異種のインタフェースを有するＭＮが３ＧＰＰローカルドメインをローミングして、種々の形式のインタフェースを介して同時接続（attach）してマルチホーミングを実現する必要がありそうである。また、他の従来技術としては、下記の特許文献１、２、３に開示されているものがある。

Yoshihiro Oba, "Mobility architecture using pre-authentication, pre-configuration and/or virtual soft-handoff", US Patent No. US 7,046,647, B2, May 16, 2006. Raziq Yaqub, "Dynamic use of multiple IP network interfaces in mobile devicesfor packet loss prevention and bandwidth enhancement", US Patent No. US 20070140256A1, June 21, 2007. George Tsirtsis, et.al., "Wireless terminalmethods and apparatus for establishing connections", US Patent No. US 20070081521A1, April 12, 2007.

Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Supportin IPv6", InternetEngineering Task ForceRequest For Comments3775, June 2004. Gundavelli, S., et. al., "Proxy Mobile IPv6", InternetEngineering Task Force(IETF) Working GroupDraft: draft-sgundave-mip6-proxymip6-02.txt, March 5, 2007. "3GPP System Architecture Evolution: Report on Technical Optionsand Conclusion", 3GPP TR 23.882,V1.12.0, October 2007.

図１２Ａ、図１２Ｂ、図１２Ｃ、図１２Ｄを参照して垂直ハンドオフの各種のケースについて詳しく説明する。図１２Ａ、図１２Ｂ、図１２Ｃ、図１２Ｄには４つのケースの垂直ハンドオフ動作が示されている。図１２Ａ、図１２Ｂに示す２つのケースは、ＭＮ１０Ａ、１０Ｂが共に２つのインタフェースＩｆ１、Ｉｆ２を有していて垂直ハンドオフを実行する場合を示し、図１２Ｃ、図１２Ｄに示す２つのケースは、ＭＮ１０Ｃ、１０Ｄが共に３つのインタフェースＩｆ１、Ｉｆ２、Ｉｆ３を有していて垂直ハンドオフを実行する場合を示す。

（ａ）まず、図１２Ａに示すケースの垂直ハンドオフについて説明する。ＭＮ１０Ａは、初期状態ではインタフェースＩｆ１のみがアクティブであって、リンク１７Ａ及びＭＡＧ１１Ａを経由してＬＭＡ／ＨＡ１３ＡにルーティングされるＰＭＩＰｖ６ドメインに接続（connect）されているものとする。次に、ＭＮ１０ＡがインタフェースＩｆ１をシャットダウンして、インタフェースＩｆ２の電源をオンにして垂直ハンドオフを実行するものとする。また、Ｌ２接続（attachment）か、又はルータ・ソリシテーションか又は他の手段によって、インタフェースＩｆ２がリンク１５Ａを経由して新しく接続（attach）するＭＡＧ１２Ａに対してこの垂直ハンドオフ指示が通知されるものとする。したがって、ＭＮ１０Ａが垂直ハンドオフ・ステートをＭＡＧ１２Ａに通知するものとする。

ここで理解すべき重要な点は、ＭＮ１０ＡがＭＡＧ１２Ａに接続（attach）するときに垂直ハンドオフがトリガされることにある（垂直ハンドオフ・トリガメッセージ１４Ａ）。さもなければ、インタフェースＩｆ２がＭＡＧ１２Ａを介してＬＭＡ／ＨＡ１３Ａに接続（attach）されているときに新しいプリフィックスが割り当てられてしまう。その理由は、ＬＭＡ／ＨＡ１３ＡがＭＮ１０Ａの希望（インタフェースＩｆ２を経由した垂直ハンドオフか又は新しい接続（attachment）か）を正確に知得しないからである。垂直ハンドオフのトリガメッセージ１４Ａで送信される唯一のパラメータがハンドオフ識別子（図のMN trigger→HI=2）である。トリガメッセージ１４Ａに続いて、ＬＭＡ／ＨＡ１３Ａは、ＭＡＧ１２Ａから送信されるＰＢＵメッセージ（不図示）で垂直ハンドオフの情報（ＨＩオプション＝２と、インタフェースＩｆ２に関連するインタフェース識別子のオプション）を受信する。

ＬＭＡ／ＨＡ１３Ａは、ＰＢＵメッセージを受信すると、インタフェースＩｆ１用としてＭＡＧ１１Ａに与えていたプリフィックスＰ１をインタフェースＩｆ２に割り当てる。ＭＡＧ１２Ａは、ＬＭＡ／ＨＡ１３ＡからのＰＢＡメッセージ（不図示）でプリフィックスＰ１を受信すると、プリフィックスＰ１をＲＡメッセージか又は何かのＡＣＫ信号のようなシグナリング１６ＡでインタフェースＩｆ２に送信する（図のResponse→(P1)）。

ここで理解すべき重要な点は、２つのインタフェースＩｆ１、Ｉｆ２を有するＭＮ１０Ａが垂直ハンドオフを実行する場合、ＬＭＡ／ＨＡ１３Ａにとって、正しいプリフィックスＰ１を垂直ハンドオフ中に割り当てるための情報としては、ハンドオフのトリガオプションすなわちＨＩオプションで十分であることにある。その理由は、ＭＡＧ１２Ａからの垂直ハンドオフ要求のオプションがＬＭＡ／ＨＡ１３Ａに到着したときのＬＭＡ／ＨＡ１３Ａのエントリが１つのみであるので、ＬＭＡ／ＨＡ１３Ａが垂直ハンドオフをインタフェースＩｆ２経由で要求されたときに、この１つのみのエントリに関連するプリフィックスＰ１を移す必要があると確信するからである。

（ｂ）図１２ＢはＭＮ１０ＢがインタフェースＩｆ１をシャットダウンして、そのフローを現在存在するインタフェースＩｆ２に移す場合を示す。インタフェースＩｆ２はこのシステムに既に接続（attach）されており、プリフィックスＰ２が割り当てられている。一方、インタフェースＩｆ１にはプリフィックスＰ１が割り当てられている。ここで図１２Ａと同様に、ＭＮ１０ＢがＭＡＧ１１Ｂ及びリンク１７Ｂから切断（disconnect）して（インタフェースＩｆ１をシャットダウンして）、リンク１５Ｂ及びＭＡＧ１２Ｂに既に接続（attach）しているインタフェースＩｆ２を経由して垂直ハンドオフを実行するものとする。ＭＡＧ１２Ｂは、インタフェースＩｆ２からの垂直ハンドオフのトリガメッセージ１４Ｂ（図のMN trigger→HI=2）を受信すると、ＬＭＡ／ＨＡ１３Ｂに送信する新しいメッセージ又はＰＢＵメッセージ（不図示）内にＨＩオプションを挿入する。このメッセージはまたインタフェースＩｆ２の識別子を含んでいてもよい。

ＬＭＡ／ＨＡ１３Ｂは、このメッセージを受信すると、インタフェースＩｆ２のＰＭＩＰｖ６バインディングに加えて、インタフェースＩｆ１に関連するバインディングが１つのみ存在するか否かをチェックして、１つのみの場合にプリフィックスＰ１をインタフェースＩｆ２に移す。基本的に、インタフェースＩｆ２のＰＭＩＰｖ６バインディングは、２つのプリフィックスＰ１、Ｐ２用のものを含む。ＬＭＡ／ＨＡ１３Ｂは、垂直ハンドオフのトリガの応答としてＡＣＫ信号（不図示）をＭＡＧ１２Ｂに送信する際にプリフィックスＰ１、Ｐ２を通知する。したがって、ＭＡＧ１２ＢはインタフェースＩｆ２に対して、プリフィックスＰ１、Ｐ２の両方を含む応答メッセージ１６Ｂ（図のResponse→(P1,P2)）を送信する。これが垂直ハンドオフの新しい想定例である。このような動作が発生する場合とは、ＭＮ１０Ｂがあるインタフェースを節電のためにシャットダウンして、そのフローを現在存在する他のインタフェースに移すときである。また、インタフェースＩｆ１が再びＭＡＧ１１Ｂ及びリンク１７Ｂに接続した際に、インタフェースＩｆ１から垂直ハンドオフを実行して、プリフィックスＰ１をインタフェースＩｆ１へ戻す場合には、インタフェースＩｆ１から送信する垂直ハンドオフのトリガメッセージ（不図示）の中には、移動するプリフィックスを指定するためにプリフィックスＰ１が存在し、ＭＡＧ１１Ｂは、ＨＩオプションとプリフィックスＰ１を含むＰＢＵメッセージ（不図示）をＬＭＡ／HA１３Ｂへ送信する。ＬＭＡ／ＨＡ１３Ｂは、このメッセージを受信すると、インタフェースＩｆ２のＰＭＩＰｖ６バインディングとして登録されているＰ１、Ｐ２のうち、ＰＢＵメッセージで指定されているプリフィックスＰ１を選択し、垂直ハンドオフのトリガの応答として、プリフィックスＰ１を含むＡＣＫ信号を送信する。したがって、ＭＡＧ１１Ｂは、インタフェースＩｆ１に対して、プリフィックスＰ１を含む応答メッセージ（不図示）を送信する。

（ｃ）次に図１２Ｃを参照して、３つのインタフェースＩｆ１、Ｉｆ２、Ｉｆ３を有するＭＮ１０Ｃが垂直ハンドオフを実行する場合について説明する。ＭＮ１０Ｃはまず、インタフェースＩｆ１、Ｉｆ２がそれぞれリンク１５Ｃ、１６Ｃ及びＭＡＧ１１Ｃ、１２Ｃを介してＬＭＡ／ＨＡ１４ＣにルーティングされるＰＭＩＰｖ６ドメインに接続（attach）して、プリフィックスＰ１、Ｐ２を参照しているものとする。一方、インタフェースＩｆ３は未接続である。以下、この状態を初期接続状態と言う。次に、ＭＮ１０ＣがインタフェースＩｆ２をシャットダウンし、また、インタフェースＩｆ３をアクティブ化して、インタフェースＩｆ２のフローをインタフェースＩｆ３に移す垂直ハンドオフを決定するものとする。

ＭＮ１０Ｃは、この垂直ハンドオフを実行してＭＡＧ１３Ｃをトリガする場合、図１２Ａ、図１２Ｂに示す場合より多くの情報をトリガメッセージ１８Ｃ内に含ませる必要がある。その情報としては、例えば垂直ハンドオフ・フラグ（オプションでもよい）と、シャットダウンしたインタフェースＩｆ２の識別子又はインタフェースＩｆ３経由で参照したいプリフィックスＰ２がある。トリガメッセージ１８Ｃで送信される垂直ハンドオフ・トリガ情報すなわちＨＩ情報は、単に１ビットで「垂直ハンドオフ」を指示することができる。しかしながら、ＭＡＧ１３ＣがＰＢＵメッセージ（不図示）をＬＭＡ／ＨＡ１４Ｃに送信するときには、この垂直ハンドオフ情報は、非特許文献２に記載されているような適切なオプション（ＨＩオプション）内に含ませる必要がある。

ここで、非特許文献２には、垂直ハンドオフのトリガを新しいＭＡＧすなわちＭＡＧ１３Ｃに与える方法が記載されていないことに注意すべきである。すなわち、異種のアクセス技術タイプ（ＡＴＴ）のドメインを跨がった垂直ハンドオフに対しては、ネットワーク側はこのステップをＭＮ側から通知されなければ検知できない。また、３ＧＰＰの構成においても、異種のＡＴＴのドメインを跨がったハンドオフに対して、ネットワーク側がハンドオフを開始することは考慮されていない。この理由は、ネットワーク側にとって他のＡＴＴのドメインから長いルーティングパスを経由してそのような行動をとることが困難であり、さらには、垂直ハンドオフがＭＮのあるプリフィックス（このプリフィックスはＡＴＴのドメインを経由して参照することが望ましい）に関連する動的な希望と節電などによる決定に基づいて実行されるからである。

図１２Ｃにおいて、ＭＮ１０Ｃがハンドオフのこれらのパラメータ（図のMN trigger→HI=2,If2-ID/P2）をＭＡＧ１３Ｃに与えると、ＭＡＧ１３ＣはこれらのパラメータをＰＢＵメッセージ（不図示）内のオプションにセットする。このオプションとは、インタフェースＩｆ２のＩｆ２−ＩＤが存在し、インタフェースＩｆ３のＩｆ３−ＩＤが存在し、ＡＴＴオプション及びＨＩオプション（ＨＩ＝２）が存在するということである。ＬＭＡ／ＨＡ１４Ｃは、このＰＢＵメッセージを受信すると、まず、このメッセージが垂直ハンドオフ（ＨＩ＝２）であると識別する。次いでＬＭＡ／ＨＡ１４Ｃは、ＰＢＵメッセージ内のインタフェースＩｆ２のＩｆ２−ＩＤを参照してＩｆ２−ＩＤのエントリがキャッシュに存在することを識別し、プリフィックスＰ２をインタフェースＩｆ３に移す。基本的に、インタフェースＩｆ３のキャッシュ内のエントリはプリフィックスＰ２に基づいて生成される。ＬＭＡ／ＨＡ１４ＣからＭＡＧ１３Ｃに送信されるＰＢＡメッセージ（不図示）によりプリフィックスＰ２が通知される。ＭＡＧ１３ＣはプリフィックスＰ２を受信すると、プリフィックスＰ２をＲＡメッセージやＡＣＫ信号のシグナリング１９ＣでＭＮ１０Ｃに送信する（図のResponse→(P2)）。

（ｄ）最後に、図１２Ｄに示す垂直ハンドオフについて説明する。ＭＮ１０Ｄは３つのインタフェースＩｆ１、Ｉｆ２、Ｉｆ３を有し、インタフェースＩｆ１、Ｉｆ２、Ｉｆ３はそれぞれ、リンク１５Ｄ及びＭＡＧ１１Ｄ、リンク１６Ｄ及びＭＡＧ１２Ｄ、リンク１７Ｄ及びＭＡＧ１３Ｄを介してＬＭＡ／ＨＡ１４ＤにルーティングされるＰＭＩＰｖ６ドメインに接続（connect）しており、それぞれプリフィックスＰ１、Ｐ２、Ｐ３を参照している。ＭＮ１０ＤがインタフェースＩｆ２の垂直ハンドオフを実行し、垂直ハンドオフのトリガメッセージ１８Ｄ（図のMN trigger→HI=2,If2-ID/P2）をＭＡＧ１３Ｄに送信するものとする。ＭＡＧ１３Ｄはトリガメッセージ１８Ｄを受信すると、ＰＢＵメッセージ（不図示）をＬＭＡ／ＨＡ１４Ｄに送信する。前述したように、ＰＢＵメッセージはインタフェースＩｆ２、Ｉｆ３のＩＤなどの多くのパラメータを含む。ＬＭＡ／ＨＡ１４Ｄは、インタフェースＩｆ３に接続（connect）されているＭＡＧ１３ＤからＰＢＵメッセージを受信すると、ＭＮ１０ＤがインタフェースＩｆ２の垂直ハンドオフを実行していてインタフェースＩｆ２のフローをインタフェースＩｆ３に移したいことを識別することができる。この場合、ＬＭＡ／ＨＡ１４Ｄが正しいプリフィックスＰ２、Ｐ３をＭＡＧ１３Ｄに与え、したがって、ＭＮ１０ＤがＭＡＧ１３Ｄからの応答メッセージ１９ＤでプリフィックスＰ２、Ｐ３を受信する（図のResponse→(P2,P3)）。

ここで重要な点は、インタフェースが２つの場合と、２つを超える場合の垂直ハンドオフ動作を区別することにある。インタフェースが２つの場合、垂直ハンドオフは単純であって、そのシグナリング負荷は水平ハンドオフの場合と非常に似ている。唯一の違いは、垂直ハンドオフのトリガメッセージ１８Ｄが重要であることである。インタフェースが２つを超える場合の垂直ハンドオフ動作の場合、シャットダウンするインタフェースＩｆ２の何かのステート情報が垂直ハンドオフ動作を開始するときに必要となる。

これまで述べたように、３つのインタフェースを有するモバイルノードがそのうちの２つのインタフェースに関するプリフィックスを固定して静的な垂直ハンドオフを行う際の主要な問題点は、シャットダウンしたインタフェースのインタフェース識別子や移動するプリフィックスを有するトリガメッセージを垂直ハンドオフの度に繰り返し送信する必要があることにある。また、２つのインタフェースを有するモバイルノードが、それぞれのインタフェースに割り当てられているプリフィックスを一方のインタフェースに集約しているときに、もう一方のインタフェースへプリフィックスを戻す際の主要な問題点は、そのプリフィックスを有するトリガメッセージを垂直ハンドオフの度に繰り返し送信する必要があることにある。このようなインタフェース識別子、及びプリフィックスは、そのビット長によりトリガメッセージのパケットサイズを増大し、さらに、トリガメッセージを送信するときのモバイルノードの消費電力や、シグナリングコストを増大させる。さらに、トリガメッセージのパケットサイズが増大すればするほど、無線帯域を多く使用する。

本発明は上記の問題点に鑑み、モバイルノードが静的な垂直ハンドオフの規則を有し、また３以上のインタフェースを有する場合には、垂直ハンドオフを要求するシグナリングのパケットサイズを減少することができる垂直ハンドオフ方法、垂直ハンドオフシステム、モバイルノード及びそのホームエージェントを提供することを目的とする。
本発明はまた、モバイルノードが２以上のインタフェースを有する場合にも、垂直ハンドオフのシグナリングを要求するパケットサイズを減少することができる垂直ハンドオフ方法、垂直ハンドオフシステム、モバイルノード及びそのホームエージェントを提供することを目的とする。

本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有するモバイルノードが前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する場合の垂直ハンドオフ方法であって、
前記第２又は第３のインタフェースが前記第２又は第３のネットワークへ垂直ハンドオフする前に使用していた、前記第１のインタフェースとは異なるプリフィックスを、前記垂直ハンドオフ後にも前記第２又は第３のインタフェースで継続的に使用するために、前記プリフィックスを前記モバイルノードのホームエージェントに設定するプリフィックス設定ステップと、
前記モバイルノードが前記新しく接続する第２又は第３のインタフェースから前記ホームエージェントに対して、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信するステップと、
前記ホームエージェントが前記トリガメッセージ内の前記垂直ハンドオフ・フラグを検知して、前記プリフィックス設定ステップにより設定されたプリフィックスを前記前に接続していた第２又は第３のインタフェースから前記新しく接続する第２又は第３のインタフェースに移すステップとを、
有するよう構成した。

本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有するモバイルノードが前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する垂直ハンドオフシステムであって、
前記第２又は第３のインタフェースが前記第２又は第３のネットワークへ垂直ハンドオフする前に使用していた、前記第１のインタフェースとは異なるプリフィックスを、前記垂直ハンドオフ後にも前記第２又は第３のインタフェースで継続的に使用するために、前記プリフィックスを前記モバイルノードのホームエージェントに設定するプリフィックス設定手段と、
前記モバイルノードが前記新しく接続する第２又は第３のインタフェースから前記ホームエージェントに対して、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信する手段と、
前記ホームエージェントが前記トリガメッセージ内の前記垂直ハンドオフ・フラグを検知して、前記プリフィックス設定手段により設定されたプリフィックスを前記前に接続していた第２又は第３のインタフェースから前記新しく接続する第２又は第３のインタフェースに移す手段とを、
有するよう構成した。

また本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有し、前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する垂直ハンドオフを行なうモバイルノードであって、
前記新しく接続する第２又は第３のインタフェースからモバイルノードのホームエージェントに対して、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信する手段を、
有するよう構成した。

また本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有するモバイルノードが前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する垂直ハンドオフシステムにおける前記モバイルノードのホームエージェントであって、
前記モバイルノードの第２又は第３のインタフェースが前記第２又は第３のネットワークへ垂直ハンドオフする前に使用していた、前記第１のインタフェースとは異なるプリフィックスを記憶するプリフィックス記憶手段と、
前記モバイルノードの前記新しく接続する前記第２又は第３のインタフェースから送信され、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを受信する手段と、
前記トリガメッセージ内の前記垂直ハンドオフ・フラグを検知して、前記プリフィックス記憶手段に記憶されたプリフィックスを、前記前に接続していた第２又は第３のインタフェースから前記新しく接続する第２又は第３のインタフェースに移す手段とを、
有するよう構成した。

上記構成により、垂直ハンドオフのトリガメッセージが新しく接続するインタフェースの識別子を含まないので、モバイルノードが静的な垂直ハンドオフの規則を有し、また３以上のインタフェースを有する場合には、垂直ハンドオフを要求するシグナリングのパケットサイズを減少することができる。

また、前記モバイルノードが、前記継続的に使用するプリフィックスを決定して前記ホームエージェントに設定することを特徴とする。
また、前記ホームエージェントが前記モバイルノードの移動経路を学習して前記継続的に使用するプリフィックスを決定することを特徴とする。

また本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有するモバイルノードが前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する場合の垂直ハンドオフ方法であって、
前記モバイルノードが、前記第２又は第３のインタフェースが前記第２又は第３のネットワークへ垂直ハンドオフする前に使用していた前記第１のインタフェースとは異なるプリフィックスを、前記垂直ハンドオフ後にも前記第２又は第３のインタフェースで継続的に使用するために、前記モバイルノードのプロキシノードに設定するプリフィックス設定ステップと、
前記プロキシノードの間で前記継続的に使用するプリフィックスを転送するステップと、
前記モバイルノードが前記新しく接続する第２又は第３のインタフェースから前記プロキシノードに対して、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信するステップと、
前記プロキシノードが前記トリガメッセージを受信して、前記継続的に使用するプリフィックスを前記ホームエージェントに通知するステップと、
前記ホームエージェントが前記通知されたプリフィックスを前記前に接続していた第２又は第３のインタフェースから前記新しく接続する第２又は第３のインタフェースに移すステップとを、
有する構成とした。

また本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１と第２のネットワークにそれぞれ接続可能な第１のインタフェースと第２のインタフェースとを有するモバイルノードが前記第１と第２のネットワーク内をローミングして、前記第２のインタフェースが前記第２のネットワークから切断して前記第２のネットワークに再接続する場合の垂直ハンドオフ方法であって、
前記第２のインタフェースが前記第２のネットワークへ垂直ハンドオフする前に使用していたプリフィックスを、前記垂直ハンドオフ後にも前記第２のインタフェースで継続的に使用するために、前記プリフィックスを前記モバイルノードのホームエージェントに設定するプリフィックス設定ステップと、
前記モバイルノードが前記新しく接続する第２のインタフェースから前記ホームエージェントに対して、垂直ハンドオフ・フラグを含みかつ前記継続的に使用するプリフィックスを含まない垂直ハンドオフのトリガメッセージを送信するステップと、
前記ホームエージェントが前記トリガメッセージ内の前記垂直ハンドオフ・フラグを検知して、前記第２のインタフェースが切断前に関連していたプリフィックスを前記新しく接続する第２のインタフェースに移すステップとを、
有する構成とした。

また本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１と第２のネットワークにそれぞれ接続可能なインタフェースとを有するモバイルノードが前記第１と第２のネットワーク内をローミングして、前記第２のインタフェースが前記第２のネットワークから切断して前記第２のネットワークに再接続する場合の垂直ハンドオフ方法であって、
前記モバイルノードが前記再接続時に前記第２のインタフェースから前記ホームエージェントに対して、前記第２のインタフェースが切断前に関連していたプリフィックスを前記第１のインタフェースに設定するか、又は前記第２のインタフェースに設定するかを指示する垂直ハンドオフ・フラグを含みかつ前記第２のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信するステップと、
前記ホームエージェントが前記トリガメッセージ内の前記垂直ハンドオフ・フラグに基づいて、前記第２のインタフェースが切断前に関連していたプリフィックスを前記第１又は第２のインタフェースに選択的に設定するステップとを、
有する構成とした。

また本発明は上記目的を達成するために、
共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１と第２のネットワークにそれぞれ接続可能なインタフェースを少なくとも有するモバイルノードが前記第１のネットワークと第２のネットワーク内をローミングする場合に、前記第１のインタフェースに関連する第１のプリフィックスのパケットを前記第２のインタフェースに転送する垂直ハンドオフ方法であって、
前記モバイルノードが前記第１のインタフェースをシャットダウンする際に、前記第１のプリフィックスを前記第２のインタフェースにバインディングするよう前記モバイルノードのホームエージェントに設定するステップと、
前記ホームエージェントが前記第１のインタフェースあてのパケットを、前記バインディングに基づいて前記第２のインタフェースに転送するステップとを、
有する構成とした。

この構成により、モバイルノードが２以上のインタフェースを有する場合にも、垂直ハンドオフを要求するシグナリングのパケットサイズを減少することができる。

本発明によれば、モバイルノードが静的な垂直ハンドオフの規則を有し、また３以上のインタフェースを有する場合には、垂直ハンドオフを要求するシグナリングのパケットサイズを減少することができる。
本発明はまた、モバイルノードが２以上のインタフェースを有する場合にも、垂直ハンドオフを要求するシグナリングのパケットサイズを減少することができる。

第１の実施の形態の垂直ハンドオフシステム及び通信シーケンスの一例を示す説明図 図１の最適化要求メッセージの別の形態を示す説明図 図１の垂直ハンドオフの最適化要求メッセージ（Ｌ２メッセージの場合）のフォーマットの一例を示す説明図 図１の垂直ハンドオフの最適化要求メッセージ（新しいモビリティ拡張ヘッダを有するシグナリング・パケットの場合）のフォーマットの一例を示す説明図 図１の垂直ハンドオフの最適化要求メッセージ（ＢＵメッセージのパケットの場合）のフォーマットの一例を示す説明図 第１の実施の形態のモバイルノードの動作を説明するためのフローチャート 第１の実施の形態のモバイルノードの構成を機能的に示すブロック図 第１の実施の形態のＬＭＡ／ＨＡの動作を説明するためのフローチャート 第１の実施の形態のＬＭＡ／ＨＡの構成を機能的に示すブロック図 第４の実施の形態の垂直ハンドオフシステム及び通信シーケンスの一例を示す説明図 第４の実施の形態のモバイルノードの動作を説明するためのフローチャート 第５の実施の形態の垂直ハンドオフシステム及び通信シーケンスの一例を示す説明図 第６の実施の形態の垂直ハンドオフシステムの一例を示す構成図 図１１Ａにおける通信シーケンスの一例を示す説明図 垂直ハンドオフの種々のケース（モバイルノードのインタフェースが２つの場合の一例）を示す説明図 垂直ハンドオフの種々のケース（モバイルノードのインタフェースが２つの場合の別の一例）を示す説明図 垂直ハンドオフの種々のケース（モバイルノードのインタフェースが３つの場合の一例）を示す説明図 垂直ハンドオフの種々のケース（モバイルノードのインタフェースが３つの場合の別の一例）を示す説明図 第１の実施の形態が想定する垂直ハンドオフシステムの一例を示す説明図 第１の実施の形態が想定する他の垂直ハンドオフシステムを示す説明図 図１３における垂直ハンドオフ・トリガメッセージの一例を示す説明図

インタフェースが３つの場合の垂直ハンドオフの問題点については既に説明したが、基本的に、インタフェースが３以上の場合、垂直ハンドオフを実現するためには、シャットダウンするインタフェースのＩＤが必須となる。以下では、垂直ハンドオフのプロセス中の問題点について、図１３を参照してさらに説明する。また、合わせて本発明の実施の形態において想定している動作シナリオの一例を説明する。

＜想定例＞
図１３は本発明の第１の実施の形態が想定する通信システムを示す。図１３は、ＰＭＩＰｖ６ドメイン３１１内の垂直ハンドオフに関連する問題を理解するための図であって、ＰＭＩＰｖ６ドメイン３１１では、ＰＭＩＰｖ６のプロトコルが３ＧＰＰシステム・アーキテクチャ・エボリューション（ＳＡＥ）ローカルドメイン内に採用されている。ここで、ＭＮ３００が３つのインタフェースＩｆ１、Ｉｆ２、Ｉｆ３を有する場合の垂直ハンドオフについては、既に図１２Ｃ、図１２Ｄにおいて説明した。また、垂直ハンドオフを実現するためには、ＭＮ３００のシャットオフするインタフェースの識別子がＬＭＡ／ＨＡ３１２に与えられなければならない。ＭＮ３００がＰＭＩＰｖ６ドメイン３１１内をローミングする間に多くの垂直ハンドオフが発生する。なお、図１３及び、以降で用いる図１４、図１５では、便宜的にセルラネットワーク、ＷＬＡＮアクセスネットワーク、ＷｉＭＡＸアクセスネットワークを用いているが、図１３に示されているネットワークの構成やアクセスネットワークの種類、インタフェースの種類や数などはこれに限定される必要はなく、本発明が適用される範囲を逸脱しない限り任意の構成を想定することができる。また、第２の実施の形態以降で用いられている通信システムの図（図８、図１０）でも同様である。

さらに、図１３では、垂直ハンドオフのイベントは、３つの要素により発生する。１つ目は、同じアクセス技術タイプのネットワークが欠如していて、例えばＷｉＭＡＸインタフェースＩｆ２が通信するＷｉＭＡＸアクセスネットワーク３０１ａと３０３ａのセルが連続していないこと、また、ＷＬＡＮインタフェースＩｆ３が通信するＷＬＡＮアクセスネットワーク３０２ａが他のＷＬＡＮアクセスネットワークのセルと連続していないことによる。２つ目は、ＭＮ３００がマルチホーミングを実現するために複数のインタフェースの維持を希望することによる。例えば、セルラインタフェースＩｆ１が接続中であり、ＷｉＭＡＸインタフェースＩｆ２又はＷＬＡＮインタフェースＩｆ３のいずれかが新たにネットワークに接続した場合に、セルラインタフェースＩｆ１において確立していた複数のコネクションのうち、１つ又は複数の任意のコネクションを、ＷｉＭＡＸインタフェースＩｆ２又はＷＬＡＮインタフェースＩｆ３のどちらかへ選択的に移す場合などである。３つ目は、ＭＮ３００があるフローについてはあるアクセス技術タイプを希望することによる。以下に、垂直ハンドオフ規則について詳しく説明する。

図１３における想定として、ＭＮ３００が３ＧセルラインタフェースＩｆ１と、ＷｉＭＡＸインタフェースＩｆ２とＷＬＡＮインタフェースＩｆ３を有するものとする。また、ＬＭＡ／ＨＡ３１２がＰＭＩＰｖ６ドメイン３１１のアンカーポイントであるものとする。また、ＰＭＩＰｖ６ドメイン３１１の無線アクセス部分が３Ｇのセルによりフルにカバーされ、ＰＭＩＰｖ６ドメイン３１１がＬＭＡ／ＨＡ３１２においてルーティングされるものとする。さらに、３Ｇのセルが連続しており、かつＷＬＡＮアクセスネットワーク（以下、ＷＬＡＮドメイン）３０２ａとＷｉＭＡＸアクセスネットワーク（以下、ＷｉＭＡＸドメイン）３０１ａ、３０３ａが３ＧセルのＰＭＩＰｖ６ドメイン３１１のカバー範囲に存在するものとする。基本的に、３ＧセルのＰＭＩＰｖ６ドメイン３１１は連続しており、ＷｉＭＡＸドメイン３０１ａ、３０３ａ及びＷＬＡＮドメイン３０２ａは連続していないものとする。

この想定はあり得る。その理由は、ＭＮ３００が３ＧセルラインタフェースＩｆ１経由で３ＧセルのＰＭＩＰｖ６ドメイン３１１に接続（attach）しているが、ＰＭＩＰｖ６ドメイン３１１と異なるオペレータ又は外部のオペレータが非３ＧＰＰネットワーク（ＷｉＭＡＸドメイン３０１ａ、３０３ａ及びＷＬＡＮドメイン３０２ａ）を提供するため、また、非３ＧＰＰネットワークが協力してセルを連続的に配置することが困難であるために、ＭＮ３００が非３ＧＰＰネットワークには連続して接続（attach）しないかもしれないからである。

初期時点Ｔ０では、ＭＮ３００の３ＧセルラインタフェースＩｆ１がＭＡＧ／３ＧＰＰ３１３に接続（attach）し、かつＷｉＭＡＸインタフェースＩｆ２がＭＡＧ／ＷｉＭＡＸ３０１に接続（attach）している。このため、ＭＮ３００はＭＡＧ／３ＧＰＰ３１３、ＭＡＧ／ＷｉＭＡＸ３０１からそれぞれルータ広告（ＲＡ）メッセージ３０５、３０６を受信する。例えばＭＮ３００はＲＡメッセージ３０５、３０６でそれぞれプリフィックスＰ１、Ｐ２を参照する。ＭＮ３００は２つのインタフェースＩｆ１、Ｉｆ２を同時に使用するマルチホーミングを希望して、２つのインタフェースＩｆ１、Ｉｆ２を使用するものとする。

次にＭＮ３００が移動して、時点Ｔ１ではＷｉＭＡＸドメイン３０１ａのカバーする範囲がなくなり、ＷＬＡＮドメイン３０２ａのカバーする範囲のみとなる。この時点Ｔ２では、ＭＮ３００はマルチホーミングを実現するためには、ＷＬＡＮインタフェースＩｆ３経由の垂直ハンドオフを実行する必要がある。ここでのマルチホーミングとは、より高い帯域を実現することが可能な場合にはいつでも複数のインタフェースを使用することを意味する。また代わりに、時点Ｔ２では、ＭＮ３００はプリフィックスＰ２に関連するフローをＷｉＭＡＸ又はＷＬＡＮのアクセス技術タイプで参照することを希望して、ＷＬＡＮへの垂直ハンドオフを実行してもよい。ここで理解すべき重要な点は、前述したように垂直ハンドオフがＭＮ３００の希望で実行できることにある。ここで、当業者であれば、ＭＮ３００は、ＭＡＧ／ＷｉＭＡＸ３０１と接続（connect）されなくなったときに、ＭＡＧ／３ＧＰＰ３１３に対して垂直ハンドオフを実行しないことは明らかである。その理由は、ＭＮ３００が複数のインタフェースの使用を希望し、さらにプリフィックスＰ２に関連するフローをＷｉＭＡＸ経由又はＷＬＡＮ経由で送受信することを希望するからである。

ここで、ＭＮ３００がＷＬＡＮインタフェースＩｆ３経由で、ＷｉＭＡＸインタフェースＩｆ２の情報をＭＡＧ／ＷＬＡＮ３０２に提供してプリフィックスＰ２を参照するものとする。この場合、ＭＮ３００は時点Ｔ１では、ＭＡＧ／３ＧＰＰ３１３、ＭＡＧ／ＷＬＡＮ３０２からのそれぞれのＲＡメッセージ３０７、３０８でプリフィックスＰ１、Ｐ２を参照する。時点Ｔ１では、ＭＡＧ／３ＧＰＰ３１３は変更されていないので、３ＧセルラインタフェースＩｆ１に関連する垂直ハンドオフ動作は行われない。ここで理解すべき重要な点は、３Ｇセルが連続的であり、かつプリフィックスＰ１を使用するフロー（例えばＶｏＩＰ）は３ＧセルラインタフェースＩｆ１経由が望ましいので、プリフィックスＰ１の垂直ハンドオフは必要としないことにある。

次の時点Ｔ２では、ＭＮ３００がＷＬＡＮドメイン３０２ａの範囲から外れてＷｉＭＡＸドメイン３０３ａの範囲に入ったものとする。ただし、３ＧのＰＭＩＰｖ６ドメイン３１１の範囲内に未だ位置する。この場合、ＷＬＡＮインタフェースＩｆ３がＷＬＡＮドメイン３０２ａとの接続（connection）を失い、ＭＮ３００がＷｉＭＡＸインタフェースＩｆ２を使用してＷｉＭＡＸドメイン３０３ａに接続（connect）することを希望するものとする。時点Ｔ２では、ＭＮ３００はＭＡＧ／ＷｉＭＡＸ３０３に対して垂直ハンドオフを実行しなければならず、ＷｉＭＡＸインタフェースＩｆ２経由でプリフィックスＰ２を参照することを希望する。この場合、ＭＮ３００は垂直ハンドオフのトリガメッセージ（図１５で説明する）をＭＡＧ／ＷｉＭＡＸ３０３に送信する。基本的に、図１３に示す想定では、プリフィックスＰ１に関する垂直ハンドオフには問題がない。その理由は、ＰＭＩＰｖ６ドメイン３１１は大きなセルであって連続したカバー範囲であり、プリフィックスＰ１は３ＧセルラインタフェースＩｆ１経由で参照されるからである（図のＲＡメッセージ３０５、３０７、３０９）。プリフィックスＰ２のみがＷｉＭＡＸインタフェースＩｆ２とＷＬＡＮインタフェースＩｆ３の間でやり取りされる。

＜他の想定例＞
図１４に示すネットワーク構成は図１３とほぼ同じであるが、ＭＮ４００は、３ＧセルラインタフェースＩｆ１と、ＷＬＡＮインタフェースＩｆ２とＷｉＭＡＸインタフェースＩｆ３を有するものとする。また、ＭＮ４００の移動軌跡４０４は、ＷＬＡＮアクセスネットワーク４０１ａ（時点Ｔ０）→ＷｉＭＡＸネットワーク４０２ａ（時点Ｔ１）→ＷＬＡＮアクセスネットワーク４０３ａ（時点Ｔ２）である。ここで、図示省略されているが、初期時点Ｔ０の前の時点では、ＭＮ４００は、３ＧセルインタフェースＩｆ１がプリフィックスＰ１を、ＷＬＡＮインタフェースＩｆ２がプリフィックスＰ２を、ＷｉＭＡＸインタフェースＩｆ３がプリフィックスＰ３を参照しているものとし、初期時点Ｔ０では、不図示のＷｉＭＡＸネットワークがカバーする範囲から離れてＷＬＡＮアクセスネットワーク４０１ａに移動し、インタフェースＩｆ２に対して垂直ハンドオフを実行する。これにより、ＭＮ４００は、インタフェースＩｆ１がＲＡメッセージ４０５によってプリフィックスＰ１を参照し、インタフェースＩｆ２がＲＡメッセージ４０６によってプリフィックスＰ２、Ｐ３を参照する。

初期時点Ｔ０ではステート４１３で示すように、ＭＮ４００はＷｉＭＡＸインタフェースＩｆ３をシャットダウンして、プリフィックスＰ３のフローをＷＬＡＮインタフェースＩｆ２のＭＡＧ／ＷＬＡＮ４０１に垂直ハンドオフするものとする。基本的には、ＭＮ４００は希望のインタフェース（ここではＷＬＡＮインタフェースＩｆ２）に垂直ハンドオフするが、ＷＬＡＮインタフェースＩｆ２は、既に接続（connect）されているインタフェースである。したがって、ＭＮ４００はＭＡＧ／ＷＬＡＮ４０１からのＲＡメッセージ４０６で２つのプリフィックスＰ２、Ｐ３を参照する。なお、３ＧセルラインタフェースＩｆ１は、初期時点Ｔ０でも初期時点Ｔ０の前の時点から継続してプリフィックスＰ１を参照している。

ＭＮ４００がさらに移動してＷＬＡＮアクセスネットワーク４０１ａとの接続（connection）を失い、時点Ｔ１では、初期時点Ｔ０の前の時点で接続（connect）していたＷｉＭＡＸネットワーク４０２ａに移動したものとする。時点Ｔ１では、ＭＮ４００はＭＡＧ／３ＧＰＰ３１３ではなく、ＭＡＧ／ＷｉＭＡＸ４０２に垂直ハンドオフするものとする。ＭＮ４００はこの垂直ハンドオフのとき、ＷＬＡＮインタフェースＩｆ２の識別子又はプリフィックスＰ２、Ｐ３を垂直ハンドオフ・トリガメッセージ（図１５）でＭＡＧ／ＷｉＭＡＸ４０２に通知する必要がある。垂直ハンドオフが成功すると、ＭＮ４００はＭＡＧ／ＷｉＭＡＸ４０２からのＲＡメッセージ４０８を受信してプリフィックスＰ２、Ｐ３を参照する。また、ＭＮ４００はＭＡＧ／３ＧＰＰ３１３からのＲＡメッセージ４０７を受信してプリフィックスＰ１を継続して参照する。ここで、プリフィックスＰ１については垂直ハンドオフはなく、ＭＮ４００はプリフィックスＰ１については３ＧセルラインタフェースＩｆ１経由を希望し、３ＧセルラインタフェースＩｆ１については垂直ハンドオフを希望しないものとする。

次いでＭＮ４００がさらに移動して、時点Ｔ２でＷＬＡＮアクセスネットワーク４０３ａに接続（attach）し、また、ＷｉＭＡＸネットワーク４０２ａとの接続（connection）を失うものとする。時点Ｔ２でもＭＮ４００は垂直ハンドオフを実行する。この場合の垂直ハンドオフ・トリガメッセージもＷＬＡＮインタフェースＩｆ３に関する情報を含む。基本的に、この想定例では、プリフィックスＰ１については、３Ｇセルがカバーする範囲が連続しているので垂直ハンドオフを実行する必要はなく、プリフィックスＰ２、Ｐ３について垂直ハンドオフが実行される。

図１５は図１３における垂直ハンドオフ・トリガメッセージ２１６、２１８を示す。ＭＮ３００は初期時点Ｔ０では、３ＧインタフェースＩｆ１がＭＡＧ／３ＧＰＰ３１３に接続（attach）し、かつＷｉＭＡＸインタフェースＩｆ２がＭＡＧ／ＷｉＭＡＸ３０１に接続（attach）している。次の時点Ｔ１では、ＷｉＭＡＸインタフェースＩｆ２がＭＡＧ／ＷｉＭＡＸ３０１との接続（connection）を失い、ＷＬＡＮインタフェースＩｆ３がＭＡＧ／ＷＬＡＮ３０２を発見する。ここで、時点Ｔ１では、ＭＮ３００は３ＧネットワークではなくＷＬＡＮネットワーク経由でプリフィックスＰ２を参照することを希望するものとする。プリフィックスＰ２をＷＬＡＮインタフェースＩｆ３経由で参照するためには、ＭＮ３００はＷｉＭＡＸインタフェースＩｆ２のＩＤ（Ｉｆ２−ＩＤ）又はプリフィックスＰ２とＨＩ＝２をＭＡＧ／ＷＬＡＮ３０２あてのトリガメッセージ２１６で通知する必要がある。

同様に、ＭＮ３００はさらに移動して、時点Ｔ２ではＷＬＡＮインタフェースＩｆ３がＭＡＧ／ＷＬＡＮ３０２との接続（connection）を失い、ＷｉＭＡＸインタフェースＩｆ２がＭＡＧ／ＷｉＭＡＸ３０３を発見する。時点Ｔ２では、ＭＮ３００は３ＧネットワークではなくＷｉＭＡＸネットワーク経由でプリフィックスＰ２を希望する場合、ＷＬＡＮインタフェースＩｆ３のＩＤ（Ｉｆ３−ＩＤ）とＨＩ＝２をＭＡＧ／ＷｉＭＡＸ３０３あてのトリガメッセージ２１８で通知する必要がある。

図１５において垂直ハンドオフを行う際の主要な問題点は、６４ビットの長いインタフェース識別子又はプリフィックスを有するトリガメッセージ２１６、２１８を継続して送信する必要があることにある。なお以下では、垂直ハンドオフさせるプリフィックスを指定する情報として、ハンドオフ元となるインタフェースのインタフェース識別子を通知しているが、インタフェース識別子の代わりに垂直ハンドオフさせるプリフィックスそのものを用いてもよい。このようなインタフェース識別子は、トリガメッセージ２１６、２１８のパケットサイズを増大し、さらに、トリガメッセージ２１６、２１８を送信するときのＭＮ３００の消費電力や、ＭＮ３００のシグナリングコストを増大させる。さらに、トリガメッセージ２１６、２１８のパケットサイズが増大すればするほど、無線帯域を多く使用する。さらに、垂直ハンドオフのパラメータを送信するＰＢＵメッセージ内にも、シャットダウンするインタフェースの識別子が必要になり、コアネットワークのシグナリング負荷が増大する。したがって、ＭＮ３００が３つのインタフェースＩｆ１、Ｉｆ２、Ｉｆ３を有していて、固定のすなわち静的な希望により垂直ハンドオフを継続して実行する場合には不都合がある。

ここで理解すべき重要な点は、図１３、図１５における垂直ハンドオフのパターンが非常に静的であることにある。すなわち、ＭＮ３００は常に、プリフィックスＰ２のフローがＷＬＡＮ経由かＷｉＭＡＸ経由になるように希望している。基本的に、垂直ハンドオフの規則は、ＭＮ３００に関する限り静的であるので、パケットサイズが大きく、継続して送信されるトリガメッセージ２１６、２１８は最適化されることが望ましい。

従来技術として、特許文献１は、主に水平ハンドオフであるハンドオフを論じており、ハンドオフの遅延を減少することを目的としている。特許文献１に記載されているメカニズムは２つの部分より成っている。１つ目は、ターゲットのＩＥＥＥ８０２．１１ネットワークにおける前接続認証（pre-authentication）を早くすることであり、２つ目は、ターゲットのアクセスルータに接続（attach）する前に仮想のソフトハンドオフを実行することである。これは、ハンドオフの遅延を減少する別のタイプの最適化であり、垂直ハンドオフのシグナリングのパケットサイズを減少するのには役に立たない。また、たとえ垂直ハンドオフに適用しても、垂直ハンドオフの遅延を減少するだけである。

また、他の従来技術として、特許文献２に記載されている方法の目的は、複数のインタフェースを有するノードに関連する、異なる動作ステートの間のパーフォーマンスを向上させることにある。基本的に、ＭＮが動作中に、ハンドオフの間のパケットロスがモニタされ、適切なインタフェースの電源がオンになってパケットロスを減少させる。ここで、垂直ハンドオフ中のインタフェースに来るパケットを新しいインタフェースが受信してパケットロスを減少させるものと想定する。しかし、この方法をＰＭＩＰｖ６ドメインに適用しても、垂直ハンドオフが発生する必要があるか、又は水平ハンドオフを実行中の他のインタフェースに来るフローを新しいインタフェースが接続したＭＡＧが受信できる必要がある。特許文献２の方法の目的は、パケットロスを防止することにあり、垂直ハンドオフのシグナリングのパケットサイズを最適化することをターゲットとしてはいない。

また、他の従来技術として、特許文献３には、ＭＮがアクセスルータ（ＡＲ）と接続（connect）中及びハンドオフ中のＭＮからＡＲへのシグナリングを減少することが記載されている。この方法は、初期接続（attach）中とハンドオフ接続（attach）時のパケットサイズを減少することによりハンドオフの遅延を最適化する手段に特徴があると思われる。ただし、各接続（connect）時にはＭＮからＡＲへシグナリングする必要がある。これに対し、本発明の目的は、垂直ハンドオフのシグナリング内の省略可能な情報を除去することにある。以上説明したように、ＭＮが静的な垂直ハンドオフの規則を有し、また３以上のインタフェースを有する場合には、通常の垂直ハンドオフのシグナリングを継続することが効率的でないことは明らかである。

以下、図面を参照して本発明の実施の形態について説明する。
＜第１の実施の形態＞
まず、第１の実施の形態の概要について説明する。ＭＮがあるプリフィックスに対する自身の垂直ハンドオフの規則が静的であると知得すると、そのプリフィックスを一義的に使用するという規則をＬＭＡ／ＨＡに対して直接に又はプロキシ・エージェントを介してプリセットする。ＭＮは、ＭＮが３以上のインタフェースを有するときにも、インタフェース識別子を有しない垂直ハンドオフのトリガメッセージを送信するようにして、トリガメッセージのパケットサイズを減少する。図１は第１の実施の形態の垂直ハンドオフシステム及び通信シーケンスの一例を示す。図１に示すネットワーク構成は、図１３、図１５と同じであるので、詳細な説明は省略する。図１では、ＭＮ５００は３ＧセルラインタフェースＩｆ１と、ＷｉＭＡＸインタフェースＩｆ２とＷＬＡＮインタフェースＩｆ３の３つのインタフェースを有するものとする。ＭＮ５００はＭＡＧ／３ＧＰＰ５１３に対し、ＷｉＭＡＸドメインとＷＬＡＮドメインの間で一義的に使用されるプリフィックス（以下、浮動（floating）プリフィックスとも呼ぶ）に関するＭＮ５００の垂直ハンドオフ規則を通知する（図の５１６）。この情報はＭＡＧ／３ＧＰＰ５１３からＬＭＡ／ＨＡ５１２に転送される（図の５１７）。なお、ＭＮ５００がＭＡＧ／ＷｉＭＡＸ５０１又はＭＡＧ／ＷＬＡＮ５０２に接続している際に垂直ハンドオフ規則を通知してもよい。

＜Ｔ０＞
初期時点Ｔ０（ステート５１３）では、ＭＮ５００は３ＧセルラインタフェースＩｆ１がＰＭＩＰｖ６ドメイン５１１のＭＡＧ／３ＧＰＰ５１３に接続（attach）され、また、ＷｉＭＡＸインタフェースＩｆ２がＷｉＭＡＸアクセスネットワーク５０１ａ経由でＰＭＩＰｖ６ドメイン５１１のＭＡＧ／ＷｉＭＡＸ５０１に接続（attach）されているものとし、また、ＭＮ５００はプリフィックスＰ１をインタフェースＩｆ１経由のＲＡメッセージ５０５で、プリフィックスＰ２をインタフェースＩｆ２経由のＲＡメッセージ５０６で参照しているものとする。ここで、ＭＮ５００はプリフィックスＰ１、Ｐ２に対して固定の垂直ハンドオフ規則を設定したいものとする。基本的に、ＭＮ５００はプリフィックスＰ２をＷｉＭＡＸアクセスネットワーク５０１ａ、５０３ａ経由及びＷＬＡＮアクセスネットワーク５０２ａ経由のみで参照したい。この要求はプリフィックスＰ２を使用しているフローの性質によるものであるかもしれない。

このため、初期時点Ｔ０では、ＭＮ５００はその旨の垂直ハンドオフ情報の最適化要求メッセージ５１６（及び５１７）をＭＡＧ／３ＧＰＰ５１３経由でＬＭＡ／ＨＡ５１２に送信する。ＭＡＧ／３ＧＰＰ５１３あての最適化要求メッセージ５１６は、レイヤ２（Ｌ２）メッセージでもよく、レイヤ３（Ｌ３）メッセージでもよい。最適化要求メッセージ５１６（及び５１７）により、プリフィックスＰ２がＷｉＭＡＸアクセスネットワーク５０１ａ、５０３ａ経由及びＷＬＡＮアクセスネットワーク５０２ａ経由の浮動プリフィックスとして一義的に使用することがＬＭＡ／ＨＡ５１２に通知される。

基本的に、最適化要求メッセージ５１６（及び５１７）の意味は、ＷｉＭＡＸ側から垂直ハンドオフがトリガされると、プリフィックスＰ２がＷＬＡＮのバインディング側からＷｉＭＡＸのバインディング側に移され、ＷＬＡＮ側から垂直ハンドオフがトリガされると、プリフィックスＰ２がＷｉＭＡＸのバインディング側からＷＬＡＮのバインディング側に移されるということである。ＭＮ５００は、初期時点Ｔ０でＰＭＩＰｖ６ドメイン５１１内をローミングしているときにこのような静的な垂直ハンドオフを実行できるものと予測する。もし、ＭＮ５００が予測によりこのような静的な垂直ハンドオフを実行できない場合には、ＭＮ５００はＰＭＩＰｖ６のプロトコルの標準の垂直ハンドオフに戻し、また、ＬＭＡ／ＨＡ５１２はその処理方法を知得する。

ＭＡＧ／３ＧＰＰ５１３は最適化要求メッセージ５１６を受信すると、最適化要求メッセージ５１６の内容を別のシグナリング・メッセージ５１７でＬＭＡ／ＨＡ５１２に通知する。シグナリング・メッセージ５１７はＰＢＵメッセージでもよい。ＬＭＡ／ＨＡ５１２はシグナリング・メッセージ５１７を受信すると、プリフィックスＰ２がＷｉＭＡＸとＷＬＡＮとの間の垂直ハンドオフを実行するときの浮動プリフィックスであることを知得し、そのことを示すために、自身のバインディングキャッシュ内に特別なフラグを生成する。

＜時点Ｔ１＞
ＭＮ５００は、最適化要求メッセージ５１６を送信した後に軌跡５０４に沿って移動して、ＭＡＧ／ＷｉＭＡＸ５０１から切断（disconnect）され、ＭＡＧ／ＷＬＡＮ５０２に対する垂直ハンドオフを実行するものとする。このときのＭＡＧ／ＷＬＡＮ５０２あての垂直ハンドオフ・トリガメッセージ５１８は、ＨＩフラグ（＝２、ハンドオーバ接続であることを示す値）のみを必要とし、ＷＬＡＮインタフェースＩｆ２の識別子もプリフィックスＰ２も添付する必要はない。ＬＭＡ／ＨＡ５１２には、時点Ｔ０における最適化要求メッセージ５１６が既に通知されているためである。したがって、時点Ｔ０における最適化要求メッセージ５１６により、時点Ｔ１における垂直ハンドオフのシグナリングのパケットサイズを最適化できることがわかる。

ＭＡＧ／ＷＬＡＮ５０２は、垂直ハンドオフ・トリガメッセージ５１８を受信すると、ＨＩオプション（＝２）と、ＡＴＴオプションを含むＰＢＵメッセージ５１９をＬＭＡ／ＨＡ５１２に送信する。ＬＭＡ／ＨＡ５１２は、ＰＢＵメッセージ５１９を受信すると、まず、ＮＡＩにより識別されるＭＮ５００が、特定のアクセス技術タイプ（ＡＴＴ）により参照される浮動プリフィックスに対して特別な要求を有するか否かをチェックする。また、ＬＭＡ／ＨＡ５１２は、ＰＢＵメッセージ５１９を受信すると、ＡＴＴオプションに基づいてＰＢＵメッセージ５１９がＷＬＡＮのアクセス技術タイプのネットワークから来たものであることを識別して、ＷｉＭＡＸのプリフィックスを移す必要があることを識別し、さらにプリフィックスＰ２を識別する。そして、ＰＢＵメッセージ５１９に対するＰＢＡメッセージ（不図示）でプリフィックスＰ２がＭＡＧ／ＷＬＡＮ５０２に移される。したがって、ＭＮ５００は、ＬＭＡ／ＨＡ５１２がプリフィックスＰ２を識別するためにＷｉＭＡＸインタフェースＩｆ３の識別子についての情報を与えることなく、プリフィックスＰ２を参照する。なお、時点Ｔ０として、ＭＮ５００の３ＧＰＰインタフェースＩｆ１がＭＡＧ／３ＧＰＰ５１３に接続して２つのコネクション（ＰＤＮ（Packet Data Network）コネクション）を確立しており、それぞれのコネクションに対してプリフィックスＰ１とＰ２が割り当てられている状態であってもよい。この場合、時点Ｔ０では、３ＧセルラインタフェースＩｆ１で確立されているコネクションののうち、Ｐ２が割り当てられているコネクションをＷＬＡＮインタフェースＩｆ２又はＷｉＭＡＸインタフェースＩｆ３へ移すコネクション（浮動コネクション）であることを示すために、ＭＮ５００は、Ｐ２が割り当てられているコネクションに関連付けられる識別情報（コネクションＩＤ）を含む最適化要求メッセージをＭＡＧ／３ＧＰＰ５１３経由、又は直接ＬＭＡ／ＨＡ５１２に登録する。なお、識別情報としては、本実施の形態で述べているように、プリフィックスを用いてもよい。そして、時点Ｔ１及び後述する時点Ｔ２では、ＷＬＡＮインタフェースＩｆ２又はＷｉＭＡＸインタフェースＩｆ３から垂直ハンドオフ・トリガメッセージが送信され、プリフィックスＰ２が割り当てられているコネクションのみが移される。また、３ＧＰＰネットワークへのコネクション確立手続中に、プリフィックスＰ２がＷＬＡＮインタフェースＩｆ２及びＷｉＭＡＸインタフェースＩｆ３で使用する浮動プリフィックスであることがＭＮ５００に通知されてもよい。この通知を受けたＭＮ５００は、ＷＬＡＮインタフェースＩｆ２、ＷｉＭＡＸインタフェースＩｆ３で垂直ハンドオフ・トリガメッセージを送信する際には、プリフィックスＰ２を含める必要がないと判断する。なお、３ＧＰＰインタフェースＩｆ１上で複数のコネクションが確立されており、そのうちの特定のコネクションをＷＬＡＮインタフェースＩｆ２又はＷｉＭＡＸインタフェースＩｆ３へ移すというシナリオは、本発明の第２の実施の形態以降に対しても適用することができる。

＜時点Ｔ２＞
ＭＮ５００がＷｉＭＡＸアクセスネットワーク５０３ａに移動して、ＭＡＧ／３ＧＰＰ５１３、ＭＡＧ／ＷｉＭＡＸ５０３からのＲＡメッセージ５１３、５１０を受信したときの動作も同様であり、ＭＮ５００はＷｉＭＡＸインタフェースＩｆ３から、ＨＩフラグ（＝２）のみの垂直ハンドオフ・トリガメッセージ５１８をＭＡＧ／ＷｉＭＡＸ５０３に送信し、また、ＭＡＧ／ＷｉＭＡＸ５０３はＨＩフラグとＡＴＴオプションを含むＰＢＵメッセージ５２２をＬＭＡ／ＨＡ５１２に送信する。ＬＭＡ／ＨＡ５１２の処理は、時点Ｔ１の場合と同様であるので、詳細な説明は省略する。なお、ＭＮ５００は、そのフローに対して上記の固定の静的な垂直ハンドオフ規則を必要としない場合には、その規則を削除するための明示的なメッセージをＬＭＡ／ＨＡ５１２に送信する。

＜最適化要求メッセージ５１６の他の形態＞
図２は、（１）Ｌ２の最適化要求メッセージ５１６及びＬ３のＰＢＵメッセージ５１７と、他の例として、（２）ＭＮ５００がＬＭＡ／ＨＡ５１２に直接に送信する最適化要求メッセージ５０６Ｂを示す。
（１）Ｌ２の最適化要求メッセージ５１６は、初期のＬ２アソシエーション時に送信することができ、Ｌ３のシグナリング・メッセージ５１７は、Ｌ２確立が成功した後に送信することができる。ＭＡＧ／３ＧＰＰ５１３は、Ｌ２の最適化要求メッセージ５１６内の浮動プリフィックスを参照する必要はなく、単に最適化要求メッセージ５１６の内容をシグナリング・メッセージ５１７としてＰＢＵメッセージでＬＭＡ／ＨＡ５１２に転送すればよいだけである。この場合、最適化要求メッセージ５１６の内容がＰＢＵメッセージ５１７の新しいタイプのモビリティ・オプションとして埋め込まれるか、又は新しいモビリティ・メッセージのヘッダの新しいフィールドにより浮動プリフィックスとアクセス技術タイプが送信される。なお、最適化要求メッセージ５１６は、ＲＳ（Router Solicitation）メッセージや、ＮＳ（Neighbor Solicitation）メッセージ、あるいはＢＵメッセージや、ＦＢＵ（Fast Binding Update）メッセージなどのＬ３メッセージであってもよい。

（２）別の形態として、ＭＮ５００がＭＡＧ／３Ｇ５１３に問い合わせてＬＭＡ／ＨＡ５１２のアドレスを取得した後、図のようにＬＭＡ／ＨＡ５１２に直接に最適化要求メッセージ５０６Ｂを送信する。この方法は、ＭＡＧ／３Ｇ５１３の処理がやや軽減される。ＭＮ５００がＬＭＡ／ＨＡ５１２のアドレスを取得する他の方法として、ＭＮ５００がＡＡＡサーバ（不図示）に問い合わせる方法がある。ここで理解すべき重要な点は、ＭＮ５００がホームのＰＭＩＰｖ６ドメイン内５１１に位置していてホームプリフィックスを３ＧセルラインタフェースＩｆ１が参照する場合、この直接の最適化要求メッセージ５０６Ｂは、新しいモビリティヘッダのメッセージ拡張ヘッダを有するメッセージでもよい。また、ＭＮ５００が外部のドメインに位置している場合、メッセージ５０６Ｂは、新しいオプションを有するＢＵメッセージでもよい。また、ＬＭＡ／ＨＡとの間でやり取りされるＩＫＥ（Internet Key Exchange）やＩＰＳｅｃ（IP security）などのシグナリングを用いてもよい。例えば、３ＧセルラインタフェースＩｆ１がセルラネットワーク５１１に接続する際に行う接続手続き（Attach Procedure）や接続更新手続きの中でこの要求を通知してもよい。また、ＷＬＡＮインタフェースＩｆ２やＷｉＭＡＸインタフェースＩｆ３などがＮｏｎ３ＧＰＰネットワークに接続した際に行う接続手続きや接続更新手続きの中でこの要求を通知してもよい。さらに別の形態として、ＭＮ５００がネットワーク・トラフィックに関する情報を有する場合には、別のインタフェース、例えばＷＬＡＮインタフェースＩｆ２又はＷｉＭＡＸインタフェースＩｆ３を選択して、最適化要求メッセージ５１６を送信するインタフェースとして使用することができる。

図２に示す最適化要求メッセージ５０６ＢをＭＮ５００がＬＭＡ／ＨＡ５１２に直接に送信できる場合とは、ＬＭＡ／ＨＡ５１２がＭＮ５００のＭＩＰｖ６ホームエージェントであってＭＮ５００がＬＭＡ／ＨＡ５１２のアドレス情報を有する場合である。ＭＮ５００がＬＭＡ／ＨＡ５１２のアドレスを知得していない場合、ＭＮ５００は、接続（attach）しているＭＡＧ／３ＧＰＰ５１３、又はＡＡＡサーバ、ＤＮＳなどを利用してＬＭＡ／ＨＡ５１２のアドレスを取得する必要がある。ここで理解すべき重要な点は、ＬＭＡ／ＨＡ５１２がＭＮ５００のＭＩＰｖ６ホームエージェントである場合にのみＬＭＡ／ＨＡ５１２への直接の通知による効果があることにある。なお、ＬＭＡ／ＨＡ５１２がＭＮ５００のＭＩＰｖ６ホームエージェントでない場合であっても、ＭＮ５００がＬＭＡ／ＨＡ５１２のアドレスを取得するための手段・シグナリングが利用できる場合は、それらを用いてＬＭＡ／ＨＡ５１のアドレスを取得した後に、最適化要求メッセージ５０６Ｂを送信してもよい。ＭＮ５００がＬＭＡ／ＨＡ５１２のアドレスを知得している場合には、ＬＭＡ／ＨＡ５１２への直接の通知は、ＭＡＧ／３ＧＰＰ５１３の負荷を減少することができる。

＜最適化要求メッセージのフォーマット＞
最適化要求メッセージ５１６、５０６Ｂの詳細な３つの構成例を図３Ａ、図３Ｂ、図３Ｃを参照して説明する。
（ａ）図３Ａに示すフレーム５０７Ｅは、最適化要求メッセージ５１６がＬ２メッセージである場合のフレーム構造を示し、先頭から順次、開始フラグ（Flag）５００Ｅと、アドレス（Address）５０１Ｅと、制御（Control）５０２Ｅと、プロトコルＩＤ（Protocol ID）５０３Ｅと、情報（Information）５０４Ｅと、ＦＣＳ（Frame Check Sequence）５０５Ｅと終了フラグ（Flag）５０６Ｅの各フィールドにより構成されている。

開始フラグ５００Ｅはフレーム５０７Ｅの先頭を示すフラグであり、２番目のフィールドのアドレス５０１Ｅは、ＭＡＣ（Media Access Control）アドレスであって、Ｌ２パケットの送信元アドレスとあて先アドレスを含む。例えば送信元アドレスはＭＮ５００のインタフェースＩｆ１のＭＡＣアドレスであり、あて先アドレスはＭＡＧ／３ＧＰＰ５１３のイングレス・インタフェース（不図示）のＭＡＣアドレスである。３番目のフィールドの制御５０２Ｅは、使用されているフレームのタイプを識別するための情報であって、受信側がこのＬ２のフレーム５０７Ｅを正しく処理するために重要である。基本的に、制御５０２Ｅは、フレーム５０７Ｅのタイプすなわち最適化要求メッセージ５１６のタイプを識別するために使用される。

４番目のフィールドのプロトコルＩＤ５０３Ｅは、上位の層で発生するパケットのみに対する値であって、メッセージ５１７がＬ２で発生する場合にはオール０である。ただし、メッセージ５１６がＬ２で発生することができても、メッセージ５１６を送信する決定と、メッセージ５１６内に埋め込まれている関連パラメータは、Ｌ３から来なければならない。次のフィールドの情報５０４Ｅは、垂直ハンドオフ時に一義的に使用する浮動プリフィックスと、垂直ハンドオフ時のアクセス技術タイプ（例えばＷｉＭＡＸか又はＷＬＡＮの識別子）を含む。情報５０４Ｅの後にＦＣＳ５０５Ｅのフィールドが続き、ＦＣＳ５０５Ｅは、フレームチェックシーケンスフィールドであり、フレーム５０７Ｅが誤りなく伝送（誤りが識別及び訂正）されているか否かを確認するために送信側と受信側により計算される。最後のフィールドの終了フラグ５０６Ｅは、フレーム５０７Ｅのデリミタとして、基本的にはフレーム５０７Ｅの終了を識別するために使用される。ここで、フレーム５０７Ｅの構造は、本発明を逸脱しない範囲で図３Ａに示す構造と同じである必要はない。さらには、本発明を逸脱しない範囲で、最適化要求メッセージ５１６として、図３Ａに示したＬ２メッセージの代わりにＬ３メッセージを用いてもよい。例えば、ＮＳ（Neighbor Solicitation）メッセージやＲＳ（Router Solicitation）メッセージ、さらには、ＩＫＥｖ２メッセージやモビリティヘッダを含むメッセージ（ＢＵメッセージや、新しいタイプのモビリティヘッダ）であってもよい。なお、モビリティヘッダを含むメッセージである場合、後述する図３Ｂ又は図３Ｃに示されるような構造を用いてもよい。

前述したように、ＭＮ５００は最適化要求メッセージ５１６を送信するためのパケットをＬ３で送信することもできる（図２の５０６Ｂ）。Ｌ３のシグナリングが使用される場合には、ＭＮ５００は新しいモビリティ拡張ヘッダか又は新しいモビリティ・オプション付きのＢＵメッセージを使用することができる。

（ｂ）図３Ｂは、新しいモビリティ拡張ヘッダ（New Mobilityextension Header）５１０Ｅを有するシグナリング・パケット５１５Ｅを示す。パケット５１５Ｅについて以下に詳しく説明する。パケット５１５Ｅの最初のヘッダは、標準のＩＰｖ６ヘッダ（IPv6 Header）５０８Ｅであり、ＩＰｖ６ヘッダ５０８Ｅは、ＭＮ５００のＨｏＡ又はＣｏＡがセットされる送信元アドレスと、ＬＭＡ／ＨＡ５１２のアドレスがセットされるあて先アドレスを含む。パケット５１５Ｅの次のヘッダは接続認証ヘッダ（Authentication Header）５０９Ｅであり、ＭＮ５００とＬＭＡ／ＨＡ５１２の間で交換されたセキュリティ・キーにより署名された接続認証データを有する。ヘッダ５０９Ｅは望ましいフィールドであるが、必須ではない。

第３のヘッダが新しいモビリティ拡張ヘッダ５１０Ｅであり、ヘッダ５１０Ｅは最初に標準のモビリティ拡張ヘッダ（Standard fields of mobility extension Header）５１１Ｅを有し、標準のモビリティ拡張ヘッダ５１１Ｅは、プロトコル番号、モビリティ・ヘッダタイプ、チェックサムなどを含む。新しいモビリティ拡張ヘッダ５１０Ｅはさらに３つの標準のフィールド５１２Ｅ、５１３Ｅ、５１４Ｅを有する。第１のフィールド（Floating Prefix）５１２Ｅは、垂直ハンドオフ時に一義的に使用する浮動プリフィックスを示す。もし多くの浮動プリフィックスがある場合にはこのフィールド５１２Ｅは大きくなる。ただし、複数の浮動プリフィックスがある場合には、その数を示すフィールドがメッセージ内にあるべきである。次のフィールド（Access Technology type 1）５１３Ｅは、垂直ハンドオフ時の第１のアクセス技術タイプ（ＷＬＡＮ）を示し、３番目のフィールド（Access Technology type 2）５１４Ｅは、垂直ハンドオフ時の第２のアクセス技術タイプ（ＷｉＭＡＸ）を示す。ここで、新しいモビリティ拡張ヘッダ５１０Ｅのフィールドを構成する方法は多く存在することを強調したい。ただし、ここでは、望ましい１つの方法であるパケット５１５Ｅを示す。

（ｃ）図３Ｃは、最適化要求メッセージを送信するための第３の例としてＢＵメッセージのパケット５２３Ｅの構造を示す。図３Ｂと同様に、パケット５２３Ｅの最初のヘッダはＩＰｖ６ヘッダ（IPv6 Header）５１６Ｅであり、次のヘッダは望ましくは接続認証ヘッダ（Authentication Header）５１７Ｅである。接続認証ヘッダ５１７Ｅの後にＢＵモビリティ拡張ヘッダ（Binding Update mobilityextension Header）５１８Ｅが続く。ヘッダ５１８Ｅの最初のフィールドは標準のＢＵ拡張ヘッダ（Standard fieldsof binding updateextension Header）５１９Ｅであり、例えば存続期間、シーケンス番号などのＢＵ内の標準の全てのフィールドを含む。

標準のＢＵ拡張ヘッダ５１９Ｅの後に新しいオプション・フィールド（Floating Prefix）５２０Ｅ、（AccessTechnology type 1）５２１Ｅ、（Access Technology type 2）５２２Ｅが設けられている。図３Ｂと同様に、最初のオプション・フィールド（Floating Prefix）５２０Ｅは、垂直ハンドオフ時に一義的に使用する浮動プリフィックスを示す。また、２番目のオプション・フィールド（Access Technology type 1）５２１Ｅは、垂直ハンドオフ時の第１のアクセス技術タイプ（ＷＬＡＮ）を示し、３番目のオプション・フィールド（Access Technology type 2）５２２Ｅは、垂直ハンドオフ時の第２のアクセス技術タイプ（ＷｉＭＡＸ）を示す。なお、浮動プリフィックスが適用されるインタフェースを示すために含まれているＡＴＴフィールドは、必ずしも２つである必要はなく、適用されるインタフェースが１つしかない場合は１つだけ含まれ、３つ以上のインタフェースに対して適用される場合は、３つ以上含まれる。

＜ＭＮの動作＞
次に図４を参照してＭＮ５００の動作を説明する。ＭＮ５００はまず、ステップ５００Ａにおいて特定のアクセス技術タイプ（ＡＴＴ）経由で一定の時間、受信したい特定のフロー（プリフィックス）があるか否かをチェックする。もしＮＯであればステップ５０４Ａに分岐して、通常のＰＭＩＰｖ６の垂直ハンドオフを実行して、ＨＩ＝２と、垂直ハンドオフするインタフェースの識別子（Ｉｆ−ＩＤ）を含む垂直ハンドオフ・トリガメッセージを送信する。

他方、ステップ５００ＡにおいてＹＥＳであればステップ５０１Ａに進み、前述した最適化要求メッセージ５１６を送信する前に、そのプリフィックスを希望のＡＴＴ（ＷＬＡＮとＷｉＭＡＸ）経由で参照することが可能か否かをチェックする。ここで、ＭＮ５００は、接続中のドメインに関連するセル構造（以前に接続したネットワーク情報等）の情報を記憶している場合、ステップ５０１Ａにおいて、そのセル構造の情報を参照して、上記のチェックを実行してもよい。もしＹＥＳであればステップ５０２Ａに進んで、浮動プリフィックスを通知するための最適化要求メッセージ５１６を送信し、次いで終了する。このとき、浮動プリフィックスは、ＭＮ５００の安定している接続インタフェースを使用して通知される。

なお、ステップ５０１Ａは必ずしも実行する必要はない。また、ステップ５００Ａを開始するトリガとして、ＬＭＡ／ＨＡ５１２やＡＡＡサーバ等のネットワーク・エンティティから、浮動プリフィックスを選択することを要求する通知を受けた場合に、ステップ５００Ａで、ＭＮ５００が保持するプリフィックスの中から特定のＡＴＴで参照したいプリフィックスを選択するようにしてもよい。また、ＭＮ５００が保持するプリフィックスの中で、特定のプリフィックスを移動する垂直ハンドオーバが一定回数以上発生した場合に、そのプリフィックスを浮動プリフィックスとして選択するようにしてもよい。また、お互いが補完する関係にあるアクセスネットワークが存在する場合には、それらのアクセスネットワーク間で移動させるプリフィックスを選択し、そのプリフィックスを浮動プリフィックスとして登録してもよい。さらには、ＬＭＡ／ＨＡ５１２やＡＡＡサーバから、明示的に浮動プリフィックスを通知され、そのプリフィックスを浮動プリフィックスとして使用すると判断した場合に、その判断結果を通知するためのメッセージとして最適化要求メッセージ５１６を送信することを判断してもよい。また、ＭＮ５００の移動頻度や接続状態に応じて、浮動プリフィックスを選択してもよい。この場合、一定時間の間に発生するハンドオーバの回数（垂直ハンドオフ・トリガメッセージ５１８の送信回数）があらかじめ決められた回数を上回る場合に、浮動プリフィックスを選択し、最適化要求メッセージ５１６を送信することを判断してもよい。これにより、送信頻度が高い垂直ハンドオフ・トリガメッセージ５１８のパケットサイズを減少させることができる。

他方、ステップ５０１ＡにおいてＮＯであればステップ５０３Ａに分岐し、上記の所望のセル構造の情報をＬＭＡ／ＨＡ５１２又は不図示のＭＩＨ（Media Independent Hand-off）サーバから取得可能か否かチェックする。そして、もしＹＥＳであればステップ５０２Ａに進んで、浮動プリフィックスを通知するための最適化要求メッセージ５１６を送信する。ここで理解すべき重要な点は、ステップ５０３ＡにおけるＭＮ５００の判定が、何かの既に構成されている情報に基づくべきであることにある。例えばＭＮ５００は、ＭＩＨサーバを有するドメインに関する情報を有するかもしれないし、また、そのようなドメインではＬＭＡ／ＨＡ５１２がセルのタイプやセル構造の情報を有するかもしれない。ステップ５０３ＡにおいてＮＯであればステップ５０４Ａに分岐して、通常のＰＭＩＰｖ６の垂直ハンドオフ・トリガメッセージを送信する。

＜ＭＮの構成＞
次に図５を参照してＭＮ５００の構成について説明する。図５はＭＮ５００の構成を機能的に示すブロック図である。ここで、図５では、ＭＮ５００がＭＩＰｖ６モビリティ管理ユニット５０４Ｄを有するように記載されているが、第１の実施の形態のＭＮ５００は、単にＩＰｖ６ホストであるＭＮや、マルチホーミングをサポートする機能を有するＭＮを含む全てのタイプのＭＮに適用することができる。さらに、レイヤ２のプロトコルスタックにプリフィックスとそのプリフィックスに関連するフローの知性を与えた場合、レイヤ３を変更せずにレイヤ２に適用することができる。

図５に示すＭＮ５００はＭＩＰｖ６の機能的構成を示し、３つの主要なモジュールとして下位層プロトコル・モジュール５０６Ｄと、レイヤ３プロトコル・モジュール５０２Ｄと、上位層プロトコル・モジュール５０１Ｄを有する。下位層プロトコル・モジュール５０６Ｄは、ＭＮ５００のインタフェースＩｆ１、Ｉｆ２、Ｉｆ３に直接に関連している複数の下位レイヤ（層）プロトコルモジュール（不図示）を有し、例えばそのモジュールの数とインタフェースの数は同じである。下位層プロトコル・モジュール５０６Ｄはまた、インタフェースＩｆ１、Ｉｆ２、Ｉｆ３用の信号変調、コード化、圧縮、メディアアクセスコントロール及びリンク層コントロールなどを含む基本的なデータ通信に必要な全ての物理層とリンク層の機能を有する。

下位層プロトコル・モジュール５０６Ｄはさらに、２つの異なるアクセス技術タイプの間の垂直ハンドオフ用として１つのプリフィックスを浮動プリフィックスとして割り当てるための最適化要求メッセージ５１６をサポートする下位層垂直ハンドオフ・トリガユニット５０７Ｄを有する。基本的には、レイヤ３の垂直ハンドオフ決定ユニット５０５Ｄが最適化要求メッセージ５１６、及び垂直ハンドオフ・トリガメッセージ５１８の送信を決定すると、この情報及び関連するパラメータがインタフェース５０８Ｄを経由してトリガユニット５０７Ｄに送られる。最適化要求メッセージ５１６をＭＡＧ／３ＧＰＰ５１３に送信するレイヤは、実際にはトリガユニット５０７Ｄによるレイヤ２である。なお、最適化要求メッセージは必ずしもレイヤ２に備える必要はなく、本発明の範囲を逸脱しない範囲でレイヤ３に備えることができることは明らかである。トリガユニット５０７Ｄは、レイヤ３で決定された情報を含む最適化要求メッセージ５１６、及び垂直ハンドオフ・トリガメッセージ５１８を直接にＭＡＧ／３ＧＰＰ５１３に送信する。トリガユニット５０７Ｄから送信される最適化要求メッセージ５１６、及び垂直ハンドオフ・トリガメッセージ５１８のあて先アドレスとしては、ＭＡＧ／３ＧＰＰ５１３のリンク層アドレスが使用される。

もし、垂直ハンドオフ・トリガユニット５０７Ｄがレイヤ３プロトコル・モジュール５０２Ｄに備えられている場合には、最適化要求メッセージ５１６のパケットのあて先アドレスとして、ＭＡＧ／３ＧＰＰ５１３のリンクローカルアドレスがセットされて下位層プロトコル・モジュール５０６Ｄに送られる。この場合の下位層プロトコル・モジュール５０６Ｄの主な機能は、そのパケットをレイヤ２を用いてカプセル化することである。

レイヤ３プロトコル・モジュール５０２Ｄは３つのサブモジュールとして、ＩＰｖ６ルーティング・ユニット５０３Ｄと、ＭＩＰｖ６モビリティ管理ユニット５０４Ｄと、上記の垂直ハンドオフ決定ユニット５０５Ｄを有する。主要な機能であるＩＰｖ６ルーティング・ユニット５０３Ｄは、主にパケット・ルーティング、アドレス構成、近隣発見（neighbor discovery）などを実行する。ＭＩＰｖ６モビリティ管理ユニット５０４ＤはＭＮ５００の１又は複数のインタフェースのモビリティ管理を処理する。垂直ハンドオフ決定ユニット５０５Ｄは、最適化要求メッセージ５１６で送信される垂直ハンドオフ用のプリフィックスと必要なパラメータを決定する。

また、垂直ハンドオフ決定ユニット５０５Ｄは、垂直ハンドオフ・トリガメッセージ５１８を送信することを決定する。具体的な処理内容としては、垂直ハンドオフを実行する際に、垂直ハンドオフ・トリガメッセージ５１８を送信するインタフェース（ハンドオフ先となるインタフェース）が接続しているネットワークが、最適化要求メッセージ５１６で登録したアクセス技術タイプに該当するネットワークであるか否かを確認し、該当するネットワークである場合には、垂直ハンドオフ・トリガメッセージ５１８の中に、送信に使用するインタフェースのインタフェース識別子を含めない垂直ハンドオフ・トリガメッセージ５１８を生成し、送信する。一方、登録したアクセス技術タイプに該当しないネットワークである場合には、垂直ハンドオフ・トリガメッセージ５１８の中に、送信に使用するインタフェースのインタフェース識別子を含めた垂直ハンドオフ・トリガメッセージ５１８を生成し、送信する。

さらに詳しく言えば、垂直ハンドオフ決定ユニット５０５Ｄは、ネットワークとの接続が切断されたインタフェース、あるいはネットワークとの接続が切断されそうなインタフェースがあるときに、そのインタフェースが接続しているネットワーク、あるいは接続していたネットワークが、最適化要求メッセージ５１６で登録したアクセス技術タイプに該当するネットワークであるか否かを確認する。その結果、該当するネットワークであった場合には、同じ最適化要求メッセージ５１６で登録した別のアクセス技術タイプへ接続しているインタフェースが存在するか否かを確認し、存在する場合には、そのインタフェースを垂直ハンドオフ・トリガメッセージの送信に使用するインタフェースとして選択し、選択したインタフェースのインタフェース識別子を含まない垂直ハンドオフ・トリガメッセージ５１８を生成し、送信する。一方、存在しない場合には、同じ最適化要求メッセージ５１６で登録していない他のネットワークへ接続しているインタフェースを使用し、そのインタフェースのインタフェース識別子を含む垂直ハンドオフ・トリガメッセージ５１８を送信する。

また別の決定方法として、垂直ハンドオフ決定ユニット５０５Ｄは、ネットワークに新たに接続したインタフェース、あるいはネットワークと新たに接続されそうなインタフェースがあるときに、そのインタフェースが接続しているネットワーク、あるいは接続しそうなネットワークが、最適化要求メッセージ５１６で登録したアクセス技術タイプに該当するネットワークであるか否かを確認する。その結果、該当するネットワークであった場合には、同じ最適化要求メッセージ５１６で登録した別のアクセス技術タイプへ接続しているインタフェースが存在するか否かを確認し、存在する場合には、ネットワークに新たに接続したインタフェースを垂直ハンドオフ・トリガメッセージの送信に使用するインタフェースとして選択し、選択したインタフェースのインタフェース識別子を含まない垂直ハンドオフ・トリガメッセージ５１８を生成し、送信する。一方、存在しない場合には、同じ最適化要求メッセージ５１６で登録していない他のネットワークへ接続しているインタフェースを使用し、そのインタフェースのインタフェース識別子を含む垂直ハンドオフ・トリガメッセージ５１８を送信する。上位層プロトコル・モジュール５０１Ｄは、トランスポート層やアプリケーション層のプロトコルを実行する。

＜ＬＭＡ／ＨＡの動作＞
次に図６を参照してＬＭＡ／ＨＡ５１２の動作について説明する。ＬＭＡ／ＨＡ５１２はまず、ＭＡＧからのＰＢＵメッセージを受信するとステップ５００Ｃの処理を実行する。ステップ５００ＣではそのＰＢＵメッセージが、ＬＭＡ／ＨＡ５１２に対して登録する垂直ハンドオフ規則が含まれていない通常の垂直ハンドオフ・トリガメッセージに関するものか否かをチェックする。もしＹＥＳであればステップ５０２Ｃに分岐して、通常の垂直ハンドオフ処理を実行し、バインディングキャッシュ・エントリをチェックしてＭＮ５００の古いインタフェースに関連するプリフィックスを新しいインタフェースに与える。

ステップ５００ＣにおいてＮＯであればステップ５０１Ｃに進んで、そのＰＢＵメッセージが、浮動プリフィックスに対する静的な垂直ハンドオフのための規則を含む新しい最適化要求メッセージか否かをチェックする。もしＹＥＳであればステップ５０３Ｃに分岐して、受信メッセージ内の浮動プリフィックスとアクセス技術タイプ（ＷＬＡＮ及びＷｉＭＡＸ）をバインディングキャッシュに登録する。ここで、ＬＭＡ／ＨＡ５１２は浮動プリフィックスとアクセス技術タイプを登録するために、バインディングキャッシュ・エントリ内に新しいフィールドを生成することができるが、ＬＭＡ／ＨＡ５１２がいかに登録するかは、構成次第である。

ステップ５０１ＣにおいてＮＯであればステップ５０４Ｃに進んで、そのＰＢＵメッセージが、最適化要求メッセージを受信して浮動プリフィックスに対する静的及び固定の垂直ハンドオフ規則を設定した後の垂直ハンドオフ・トリガメッセージか否かをチェックし、もしＹＥＳであればステップ５０５Ｃに分岐する。ステップ５０５Ｃでは、静的及び固定の垂直ハンドオフ規則を設定したＭＮであるか否か、また、ＷＬＡＮ経由でトリガされた垂直ハンドオフに対応するＷｉＭＡＸのバインディングが存在するか否か、又はその逆をチェックして、全てＹＥＳであれば、ＷＬＡＮ−ＷｉＭＡＸ間の垂直ハンドオフ時に一義的に使用する浮動プリフィックスを割り当てる。

他方、ステップ５０４ＣにおいてＮＯであればステップ５０６Ｃに進み、そのＰＢＵメッセージが、静的及び固定の垂直ハンドオフ規則の破棄を要求するメッセージか否かをチェックし、もしＹＥＳであればその垂直ハンドオフ規則を破棄し、また、ステップ５０２Ｃに進んで通常の垂直ハンドオフ処理を実行する。また、ステップ５０６ＣにおいてＮＯであればステップ５０７Ｃに進み、特別な方法による静的な垂直ハンドオフ処理を実行する。

＜ＬＭＡ／ＨＡの構成＞
次に図７を参照してＬＭＡ／ＨＡ５１２の構成について説明する。図７はＬＭＡ／ＨＡ５１２の構成を機能的に示すブロック図である。ＬＭＡ／ＨＡ５１２はレイヤ３プロトコル・モジュール５０１Ｆと、レイヤ３より下位の層の下位層プロトコル・モジュール５０６Ｆを有する。下位層プロトコル・モジュール５０６Ｆは、全てのデータリンク層とベースバンドレベルの機能を有する。レイヤ３プロトコル・モジュール５０１Ｆは４つのサブモジュールとして、ＰＭＩＰｖ６モビリティ管理ユニット５０２Ｆと、ＩＰｖ６ルーティング・ユニット５０３Ｆと、ＭＩＰｖ６モビリティ管理ユニット５０４Ｆと、垂直ハンドオフ・サポートユニット５０５Ｆを有する。ここで、図面では、これらのモジュール５０１Ｆ、５０６Ｆ及びユニット５０２Ｆ、５０３Ｆ、５０４Ｆ、５０５Ｆの間にはインタフェースが示されていないが、実際には存在する。

ＩＰｖ６ルーティング・ユニット５０３Ｆは、パケット・ルーティング、アドレス構成、近隣発見などの標準のＩＰｖ６のメカニズムを担当する。ＭＩＰｖ６モビリティ管理ユニット５０４Ｆは、ＭＩＰｖ６のホームエージェントと同様なメカニズムを担当し、例えばＣＭＩＰｖ６のＢＵメッセージの処理、そのＢＵメッセージに対するＡＣＫ信号（ＢＡメッセージ）の送信、データパケットのトンネル化、バインディングキャッシュの維持などを実行する。ＰＭＩＰｖ６モビリティ管理ユニット５０２Ｆは基本的に、ＰＭＩＰｖ６（非特許文献２）に開示されているＬＭＡの機能を備えている。このユニット５０２Ｆに関連する機能とは、種々のオプション（ＨＩオプション、アクセス技術オプションなど）を有するＰＢＵメッセージの処理、そのＰＢＵメッセージに対するＡＣＫ信号（ＰＢＡメッセージ）の送信、ＰＭＩＰｖ６ドメインに加入しているＭＮからのアップリンク・パケット及びダウンリンク・パケットの処理などである。ここで理解すべき重要な点は、ＰＭＩＰｖ６モビリティ管理ユニット５０２ＦとＭＩＰｖ６モビリティ管理ユニット５０４Ｆは、それぞれ基本的な機能が異なっているが、１つに結合したモジュールで構成し、また、ＰＭＩＰｖ６キャッシュとＣＭＩＰｖ６キャッシュの両方を１つのバインディングキャッシュが有するように構成することができることである。なおユニット５０２Ｆ、５０４Ｆを備えるには多くの方法があり、制限するものではない。

最後の垂直ハンドオフ・サポートユニット５０５Ｆは、最適化要求メッセージ５１６を処理して、１以上のＭＮ５００に関連する浮動プリフィックスに関する処理結果をＰＭＩＰｖ６キャッシュにセットする。ユニット５０５Ｆはさらに、ＭＮ５００が静的な垂直ハンドオフ規則を破棄するときにＭＮ５００から送信されるメッセージを処理する。ユニット５０５Ｆはさらに、垂直ハンドオフが実行されるときに、ＰＭＩＰｖ６モビリティ管理ユニット５０２Ｆから、浮動プリフィックスを割り当てるための問い合わせを受ける。この問い合わせにおけるパラメータとは、ＭＮ５００の現在のアクセス技術タイプと、垂直ハンドオフがトリガされたアクセス技術タイプと、浮動プリフィックスなどである。ユニット５０５Ｆはこれらのパラメータから、垂直ハンドオフの間に与えるプリフィックスを決定してＰＭＩＰｖ６モビリティ管理ユニット５０２Ｆに通知する。基本的に、浮動プリフィックスの割り当てについての決定は、垂直ハンドオフ・サポートユニット５０５Ｆが行うが、浮動プリフィックスを通知するＰＢＡメッセージは、ＰＭＩＰｖ６モビリティ管理ユニット５０２Ｆにより構成される。

本発明の第１の実施の形態により、最適化要求メッセージ５１６で継続的に使用するプリフィックスを登録したＭＮ５００は、垂直ハンドオフを実行する際に送信する垂直ハンドオフ・トリガメッセージの中に、移動させるプリフィックスを明示的に含める必要がなくなるという効果が得られる。

＜第２の実施の形態＞
次に、同じ図１を参照して第２の実施の形態について説明する。ここで、第１の実施の形態では、ＬＭＡ／ＨＡ５１２は、ＭＮ５００からの最適化要求メッセージ５１６により、ＭＮ５００の静的な垂直ハンドオフ規則を検知して垂直ハンドオフ・トリガメッセージのパケットサイズを最適化しているが、第２の実施の形態におけるＬＭＡ／ＨＡ５１２は、最適化要求メッセージ５１６を受信することなく、自らの判断で垂直ハンドオフ・トリガメッセージのパケットサイズを最適化する。第２の実施の形態では、ＬＭＡ／ＨＡ５１２は常に、プリフィックスＰ２がＷｉＭＡＸとＷＬＡＮのアクセス技術タイプを経由してハンドオフされることを注目及び学習してＭＮ５００の意図を予測し、ＭＮ５００に対して、シャットダウンするインタフェースの識別子を垂直ハンドオフ・トリガメッセージで通知しないように通知する。基本的に、ＬＭＡ／ＨＡ５１２は、ＭＮ５００の意図を識別して、ＬＭＡ／ＨＡ５１２が自ら静的な垂直ハンドオフ規則を決定し、ＭＮ５００に通知する。なお、情報サーバが保持するＭＮ５００に関する情報の中に静的な垂直ハンドオフ規則が含まれていてもよい。この場合、ＬＭＡ／ＨＡ５１２は情報サーバから取得した情報を基に、ＭＮ５００に静的な垂直ハンドオフ規則を通知する。

第２の実施の形態の主要な利点は、ＭＮ５００の処理（最適化要求メッセージ５１６の送信）を省略することにある。

＜第３の実施の形態＞
次に、第３の実施の形態について説明する。第３の実施の形態では、図１において、ＭＮ５００が静的な垂直ハンドオフ規則（最適化要求メッセージ５１６）をＭＮ５００のプロキシノードであるＭＡＧ／ＷｉＭＡＸ５０１又はＭＡＧ／３ＧＰＰ５１３に通知して、ＭＡＧ５０１又は５１３がその規則を他のＭＡＧ５０２、５０３にＣＴ（context transfer）で転送するものとする。ＭＮ５００は、静的な垂直ハンドオフ規則をドメイン５１１に通知することを決定すると、最初に例えばＭＡＧ／ＷｉＭＡＸ５０１に通知する。前述したように、最適化要求メッセージ５１６では、ＭＮ５００がＷＬＡＮ経由又はＷｉＭＡＸ経由で一義的に参照したいプリフィックスＰ２が通知される。このプリフィックスＰ２の情報をＭＡＧ／ＷｉＭＡＸ５０１に通知する想定に加えて、さらにＭＮ５００が次のアクセスルータ（ＡＲ）であるＭＡＧ／ＷＬＡＮ５０２の識別子を転送する。次のＡＲの識別子とは、ＷＬＡＮのＥＳＳＩＤ（Extended Service Set ID）と同様な何かの識別子である。したがって、ＭＡＧ／ＷｉＭＡＸ５０１はこの識別子を用いて、次のＭＡＧ／ＷＬＡＮ５０２のＩＰｖ６アドレスを識別する。基本的に、垂直ハンドオフ規則は、垂直ハンドオフの間は継続して与えられる必要がないが、次のＡＲの情報が古いＭＡＧ／ＷｉＭＡＸ５０１に与えられなければならない。したがって、新しいＭＡＧ５０２、５０３に送信されるトリガメッセージのパケットサイズを減少できるが、ＭＮ５００が次のＭＡＧ／ＷＬＡＮ５０２に垂直ハンドオフ規則の情報を送信するのはあまり有用ではない。ただし、完全にネットワーク制御の垂直ハンドオフが確立されている場合に有用である。

＜第４の実施の形態＞
次に図８を参照して第４の実施の形態について説明する。図８に示すネットワーク構成では、ＭＮ６００がインタフェースとして、３ＧセルラインタフェースＩｆ１とＷＬＡＮインタフェースＩｆ２の２つのインタフェースを有し、また、ＭＮ６００が軌跡６０４に沿って移動する際にＷＬＡＮインタフェースＩｆ２が接続（attach）するＷＬＡＮアクセスネットワーク６０１ａ、６０２ａ、６０３ａが連続していないことを想定している。このため、ＭＮ６００のＷＬＡＮインタフェースＩｆ２は、時点Ｔ０ではＷＬＡＮアクセスネットワーク６０１ａ及びＭＡＧ／ＷＬＡＮ６０１に接続（attach）し、時点Ｔ１ではＷＬＡＮアクセスネットワーク６０１ａ及びＭＡＧ／ＷＬＡＮ６０１との接続（connection）を失い、時点Ｔ２では次のＷＬＡＮアクセスネットワーク６０２ａ及びＭＡＧ／ＷＬＡＮ６０２に再び接続（attach）し、時点Ｔ３ではＷＬＡＮアクセスネットワーク６０２ａ及びＭＡＧ／ＷＬＡＮ６０２との接続（connection）を失い、時点Ｔ４では次のＷＬＡＮアクセスネットワーク６０３ａ及びＭＡＧ／ＷＬＡＮ６０３に再び接続（attach）するものとする。なお、本実施の形態におけるインタフェースＩｆ１、インタフェースＩｆ２は、任意のアクセス技術タイプでよい。例えば、３ＧセルラインタフェースＩｆ１はＷｉＭＡＸインタフェースＩｆ３であってもよいし、さらには、ＷＬＡＮインタフェースＩｆ２はＷｉＭＡＸインタフェースＩｆ３であってもよい。

＜時点Ｔ０＞
時点Ｔ０におけるＭＮ６００は、３ＧセルラインタフェースＩｆ１及びＭＡＧ／３ＧＰＰ６１８経由のＲＡメッセージ６０５でプリフィックスＰ１を参照し、また、ＷＬＡＮインタフェースＩｆ２及びＭＡＧ／ＷＬＡＮ６０１経由のＲＡメッセージ６０６でプリフィックスＰ２を参照している。
＜時点Ｔ１＞
次にＭＮ６００が軌跡６０４に沿って移動して、時点Ｔ１ではＷＬＡＮインタフェースＩｆ２がＭＡＧ／ＷＬＡＮ６０１との接続（connection）を失う。この場合、ＭＮ６００は、ＨＩフラグ（＝２）のみを有する垂直ハンドオフ・トリガメッセージ６２１を３ＧセルラインタフェースＩｆ１経由でＭＡＧ／３ＧＰＰ６１８に送信する必要がある。

ここで理解すべき重要な点は、ＭＮ６００が２つのインタフェースＩｆ１、Ｉｆ２のみを有するので、ＭＮ６００が垂直ハンドオフ・トリガメッセージ６２１をＭＡＧ／３ＧＰＰ６１８に送信するときにＷＬＡＮインタフェースＩｆ２の識別子の情報をメッセージ６２１で通知することなく、プリフィックスＰ２が３ＧセルラインタフェースＩｆ１に移されることにある。この理由は、ＬＭＡ／ＨＡ６１９では、ＭＡＧ／３ＧＰＰ６１８から不図示の新しいＰＢＵメッセージ（ＨＩ＝２）が到着したときには、ＭＡＧ／ＷＬＡＮ６０１及びＭＮ６００に関する１つのバインディングキャッシュ・エントリのみが存在するからである。このため、時点Ｔ１では、ＭＮ６００はトリガメッセージ６２１の送信後に、ＭＡＧ／３ＧＰＰ６１８から受信するＲＡメッセージ６０７でプリフィックスＰ１、Ｐ２を参照する。なお、不図示ではあるが、時点Ｔ０において、ＭＮ６００は、プリフィックスＰ２を浮動プリフィックスとして指定した最適化要求メッセージをＭＡＧ／３ＧＰＰ６１８経由で、又は直接ＬＭＡ／ＨＡ６１９へ送信する。また、時点Ｔ０として、ＭＮ６００の３ＧＰＰインタフェースＩｆ１がＭＡＧ／３ＧＰＰ６１８に接続して２つのコネクション（ＰＤＮ（Packet Data Network）コネクション）を確立しており、それぞれのコネクションに対してプリフィックスＰ１とＰ２が割り当てられている状態であってもよい。この場合、時点Ｔ０では、３ＧセルラインタフェースＩｆ１で確立されているコネクションののうち、Ｐ２が割り当てられているコネクションをＷＬＡＮインタフェースＩｆ２へ移すコネクション（浮動コネクション）であることを示すために、ＭＮ６００は、Ｐ２が割り当てられているコネクションに関連付けられる識別情報（コネクションＩＤ）を含む最適化要求メッセージをＬＭＡ／ＨＡ６１９に送信し、登録する。なお、識別情報としては、プリフィックスＰ２を用いてもよい。そして、時点Ｔ２、Ｔ４では、ＷＬＡＮインタフェースＩｆ２から垂直ハンドオフ・トリガメッセージが送信され、プリフィックスＰ２が割り当てられているコネクションのみが移される。また、３ＧＰＰネットワークへのコネクション確立手続中に、プリフィックスＰ２がＷＬＡＮインタフェースＩｆ２で使用する浮動プリフィックスであることがＭＮ６００に通知されてもよい。この通知を受けたＭＮ６００は、ＷＬＡＮインタフェースＩｆ２、ＷｉＭＡＸインタフェースＩｆ３で垂直ハンドオフ・トリガメッセージを送信する際には、プリフィックスＰ２を含める必要がないと判断する。

＜時点Ｔ２＞
ここで、ＭＮ６００が軌跡６０４に沿ってさらに移動して、時点Ｔ２で新しいＷＬＡＮアクセスネットワーク６０２ａのＭＡＧ／ＷＬＡＮ６０２を発見したとき、ＭＮ６００がプリフィックスＰ２用の垂直ハンドオフを希望するものとする。なお、この想定では基本的に、ＭＮ６００は常に（一義的に）、プリフィックスＰ２をＷＬＡＮインタフェースＩｆ２経由で希望し、また、プリフィックスＰ１を３ＧセルラインタフェースＩｆ１経由で希望するものとする。したがって、ＭＮ６００は時点Ｔ２では、ＭＡＧ／ＷＬＡＮ６０２における垂直ハンドオフをトリガして、垂直ハンドオフ・トリガメッセージ６２２でプリフィックスＰ２をＭＡＧ／ＷＬＡＮ６０２に通知する。ここでのトリガメッセージ６２２は新しいタイプの信号である。その理由は、３ＧセルラインタフェースＩｆ１経由で得られたプリフィックスＰ１、Ｐ２からプリフィックスＰ２を選択してＷＬＡＮインタフェースＩｆ２に移すからである。

ここで理解すべき重要な点は、この動作が非特許文献２に記載されている動作と異なることである。図８に示す第４の実施の形態では、ＭＮ６００が３ＧセルラインタフェースＩｆ１に関連する他のプリフィックスＰ１を移すことなく、ＷＬＡＮインタフェースＩｆ２経由で参照したいプリフィックスＰ２を垂直ハンドオフする。この動作では、ＭＮ６００が垂直ハンドオフ・トリガメッセージ６２２内に新しいＨＩフラグを使用し、ＬＭＡ／ＨＡ６１９がこの新しいＨＩフラグとプリフィックスＰ２を参照して正しいプリフィックスＰ２をＰＢＡメッセージ（不図示）でＭＡＧ／ＷＬＡＮ６０２に通知する必要がある。

ここで理解すべき重要な点は、ＨＩフラグが上記の新しい値にセットされない場合、ＬＭＡ／ＨＡ６１９がＭＡＧ／ＷＬＡＮ６０２からのＰＢＵメッセージ（不図示）を非特許文献２に記載されている通常の動作で処理して、プリフィックスＰ１、Ｐ２の両方をＭＡＧ／ＷＬＡＮ６０２に割り当てることである。非特許文献２のドラフトによれば、２つのインタフェースＩｆ１、Ｉｆ２を有するＭＮ６００がＷＬＡＮ経由の垂直ハンドオフを実行するときには、３ＧセルラインタフェースＩｆ１に関連する全てのプリフィックスがＷＬＡＮインタフェースＩｆ２にハンドオーバされる。基本的に、ＰＭＩＰｖ６のベースのドラフトによれば、現在登録されているインタフェースに関連する全てのプリフィックスを垂直ハンドオフ中に新しいインタフェースに移す。したがって、この想定では、ＭＮ６００が２つのインタフェースＩｆ１、Ｉｆ２を有する場合、あるプリフィックスを移すときには新しいＨＩオプションが必要である。このため、特定のプリフィックスＰ２を必要とするＭＮ６００の希望をＬＭＡ／ＨＡ６１９に指示する必要があり、プリフィックスＰ２と新しいＨＩオプションがＭＡＧ／ＷＬＡＮ６０２でＰＢＵメッセージ（不図示）に挿入されてＬＭＡ／ＨＡ６１９に送信される。なお時点Ｔ２においてトリガメッセージ６２２を受けた際に、ＬＭＡ／ＨＡ６１９の判断で、３ＧセルラインタフェースＩｆ１に割り当てられているプリフィックスＰ１、Ｐ２のうち、以前ＷＬＡＮインタフェースに割り当てられていたプリフィックスであるＰ２を選択してＭＮ６００へ割り当ててもよい。この場合、ＬＭＡ／ＨＡ６１９は、プリフィックスＰ２が３ＧセルラインタフェースＩｆ１に移された後でも、Ｐ２が以前ＷＬＡＮインタフェースＩｆ２に割り当てられていたものであることを記憶しておく。これにより、ＭＮ６００はトリガメッセージ６２２に新しいＨＩフラグを使用する必要がなくなる。なお、ＭＮ６００は、３Ｇネットワーク上のＡＮＤＳＦ（Access Network Discovery and Selection Function）サーバから取得しているハンドオーバ情報（Inter-system mobility policy、Access Network Discovery information）の中に、ＷＬＡＮインタフェースＩｆ２に割り当てられたプリフィックスを、垂直ハンドオーバ後も引き続き使用するプリフィックス（浮動プリフィックス）として使用することが明記されている場合には、移動させるプリフィックスを示す情報（インタフェース識別子又はプリフィックスＰ２）を含めずにトリガメッセージ６２２を送信する。これにより、トリガメッセージ６２２のメッセージサイズを減らすことができる。

＜時点Ｔ３＞
さらなる想定として、ＭＮ６００がＰＭＩＰｖ６ドメイン６２０内をローミングして、時点Ｔ３でＷＬＡＮインタフェースＩｆ２が再びＷＬＡＮアクセスネットワーク６０２ａとの接続（connection）を失い、ＭＮ６００はインタフェースＩｆ１が接続（connect）されるのみとする。ここでも同様に、ＭＮ６００は希望のプリフィックスＰ２と新しいＨＩオプションを用いてプリフィックスＰ２の垂直ハンドオフを実行する。

この新しいフラグは、１つのプリフィックス、又は複数のプリフィックスが選択された１つのプリフィックス・グループに対する３ＧネットワークとＷＬＡＮの間の垂直ハンドオフする場合に特徴がある。ここで、３ＧネットワークとＷＬＡＮの間の垂直ハンドオフでは、通常の垂直ハンドオフ・フラグ（ＨＩ＝２）が使用される。本実施の形態の利点とは、垂直ハンドオフするプリフィックスが選択され、この選択されたプリフィックスに対してのみ垂直ハンドオフがトリガされる。本実施の形態は、ＭＮ６００が２つのインタフェースＩｆ１、Ｉｆ２を有する場合の新しい方法である。その理由は、垂直ハンドオフするインタフェースＩｆ２の識別子を通知する必要がないからであり、このため、トリガメッセージのパケットサイズを減少することができる。

＜ＭＮの処理＞
図９を参照してＭＮ６００の動作を説明する。まず、ステップ６００Ａにおいて例えばＷＬＡＮ経由で参照したい特定のプリフィックスがあるか否かをチェックする。もしＮＯであればステップ６０３Ａに分岐して、垂直ハンドオフする必要がある場合に通常の垂直ハンドオフ処理を実行し、次いでステップ６００Ａに戻る。すなわちステップ６０３Ａでは、２つのインタフェースＩｆ１、Ｉｆ２用のＨＩ＝２付きの垂直ハンドオフ・トリガメッセージを送信する。基本的に、インタフェースが２つの場合、インタフェースＩｆ１、Ｉｆ２の識別子は送信する必要はなく、ＰＢＵメッセージはＨＩオプションのみで十分である。

ステップ６００ＡにおいてＹＥＳであればステップ６０２Ａに進み、その参照したいプリフィックスと新しいＨＩオプションで垂直ハンドオフをトリガ（トリガメッセージを送信）し、次いでステップ６０１Ａに進む。ステップ６００ＡにおいてＮＯであればステップ６０１Ａに分岐し、その特定のプリフィックスをＷＬＡＮ経由で参照したいという希望がまだあるか否かをチェックする。例えばある音声コールがその特定のプリフィックスを使用して開始する場合には、ステップ６０１Ａの判定はＹＥＳとなってステップ６０３Ａに進み、通常の垂直ハンドオフ処理を実行する。また、ステップ６０１Ａの判定がＮＯの場合にはステップ６００Ａに戻る。

＜第５の実施の形態＞
次に図１０を参照して第５の実施の形態について説明する。図１０に示すネットワーク構成は図８とほぼ同じであるが、ＭＮ７００がインタフェースとして、３ＧセルラインタフェースＩｆ１とＷＬＡＮインタフェースＩｆ２の２つのインタフェースを有し、また、ＭＮ７００が軌跡７０４に沿って移動する際にＷＬＡＮインタフェースＩｆ２が接続（attach）するＷＬＡＮアクセスネットワーク７０１ａ、７０２ａ、７０３ａが連続していることを想定している。このため、ＭＮ７００のＷＬＡＮインタフェースＩｆ２は、時点Ｔ０ではＭＡＧ／ＷＬＡＮ７０１に接続（attach）し、時点Ｔ１ではＭＡＧ／ＷＬＡＮ７０１からＭＡＧ／ＷＬＡＮ７０２へ接続（connection）を切り替え、時点Ｔ２では次のＭＡＧ／ＷＬＡＮ７０２に接続（attach）し、時点Ｔ３ではＭＡＧ／ＷＬＡＮ７０２からＭＡＧ／ＷＬＡＮ７０３へ接続（connection）を切り替え、時点Ｔ４では次のＭＡＧ／ＷＬＡＮ７０３に接続（attach）するものとする。なお、本実施の形態におけるインタフェースＩｆ１、インタフェースＩｆ２は、任意のアクセス技術タイプでよい。例えば、３ＧセルラインタフェースＩｆ１はＷｉＭＡＸインタフェースＩｆ２であってもよいし、さらには、ＷＬＡＮインタフェースＩｆ２はＷｉＭＡＸインタフェースＩｆ３であってもよい。

第４、第５の実施の形態の違いを以下に示す。第４の実施の形態では、プリフィックスＰ２が垂直ハンドオフの間にＭＡＧ／３ＧＰＰ６１８からＭＡＧ／ＷＬＡＮ６０２に通知されない場合には、ＬＭＡ／ＨＡ６１９がプリフィックスＰ１、Ｐ２をＷＬＡＮインタフェースＩｆ２に送信する。一方、第５の実施の形態では、このような継続的なシグナリングを減少する。その理由は、第５の実施の形態においても、２つのインタフェースＩｆ１、Ｉｆ２の垂直ハンドオフ規則が非常に静的であり、ＭＮ６００が非常に静的なパターンで垂直ハンドオフを実行しているからである。この規則では、ＭＮ６００がＷＬＡＮに到達すると常にプリフィックスＰ２を移している。

そこで、第５の実施の形態では、時点Ｔ０におけるＭＮ７００は、この静的な規則を知得すると、垂直ハンドオフの最適化要求メッセージ７０５をＭＡＧ／３ＧＰＰ７０７に送信する。ＭＡＧ／３ＧＰＰ７０７は、メッセージ７０５の内容をシグナリング・メッセージ７０６でＬＭＡ／ＨＡ７１８に転送する。メッセージ７０５は送信情報として、例えばＭＮ７００がＷＬＡＮに到達したときにはプリフィックスＰ２がＷＬＡＮインタフェースＩｆ２に移されること、さもなければ３ＧセルラインタフェースＩｆ１に移されることを希望している旨の垂直ハンドオフ情報を含む。つまり、ＭＮ７００は、浮動プリフィックスとしてプリフィックスＰ２が設定された最適化要求メッセージを送信する。ＭＮ７００がトリガメッセージ７０５でＬＭＡ／ＨＡ７１８に希望する主な内容は、垂直ハンドオフ・トリガメッセージがＷＬＡＮインタフェースＩｆ２経由で来たときにはプリフィックスＰ２をＷＬＡＮインタフェースＩｆ２に移し、また、垂直ハンドオフ・トリガメッセージが３ＧセルラインタフェースＩｆ１経由で来たときにはプリフィックスＰ２を３ＧセルラインタフェースＩｆ１に移すことである。この場合、最適化要求メッセージ７０５、及びシグナリング・メッセージ７０６には、プリフィックスＰ２を継続的に利用するインタフェースとして、３ＧインタフェースＩｆ１とＷＬＡNインタフェースＩｆ２の情報が含まれる。このルールがプリセットされると、ＭＮ７００はＰＭＩＰｖ６ドメイン７１９内をローミング中には、プリフィックスＰ２を有する垂直ハンドオフ・トリガメッセージを継続して送信する必要がない。なお、時点Ｔ０として、ＭＮ７００の３ＧＰＰインタフェースＩｆ１がＭＡＧ／３ＧＰＰ７０７に接続して２つのコネクション（ＰＤＮ（Packet Data Network）コネクション）を確立しており、それぞれのコネクションに対してプリフィックスＰ１とＰ２が割り当てられている状態であってもよい。この場合、時点Ｔ０では、３ＧセルラインタフェースＩｆ１で確立されているコネクションののうち、Ｐ２が割り当てられているコネクションをＷＬＡＮインタフェースＩｆ２へ移すコネクション（浮動コネクション）であることを示すために、ＭＮ７００は、Ｐ２が割り当てられているコネクションに関連付けられる識別情報（コネクションＩＤ）をＬＭＡ／ＨＡに登録する。なお、識別情報としては、本実施の形態で述べているように、プリフィックスＰ２を用いてもよい。そして、時点Ｔ２、Ｔ４では、ＷＬＡＮインタフェースＩｆ２から垂直ハンドオフ・トリガメッセージが送信され、プリフィックスＰ２が割り当てられているコネクションのみが移される。また、３ＧＰＰネットワークへのコネクション確立手続中に、プリフィックスＰ２がＷＬＡＮインタフェースＩｆ２で使用する浮動プリフィックスであることがＭＮ５００に通知されてもよい。この通知を受けたＭＮ５００は、ＷＬＡＮインタフェースＩｆ２で垂直ハンドオフ・トリガメッセージを送信する際には、プリフィックスＰ２を含める必要がないと判断する。

なお、最適化要求メッセージ７０５として、継続的に使用するプリフィックスのみを指定して、アクセス技術タイプ（ＡＴＴ）を含まない最適化要求メッセージ７０５を用いてもよい。この場合、ＬＭＡ／ＨＡ７１８は、垂直ハンドオフ・トリガメッセージを送信したインタフェースのアクセス技術タイプにかかわらず、最適化要求メッセージ７０５で指定されたプリフィックスを、移動するプリフィックスとして選択する。また、最適化要求メッセージ７０５には、通知するプリフィックスが、継続的に使用するプリフィックスであり、かつアクセス技術タイプに依存しないプリフィックスであることを示すために、フラグ等をメッセージに含めてもよい。つまり、３ＧインタフェースＩｆ１で使用しているプリフィックスＰ１を浮動プリフィックスとして指定してよく、通信中のフローに応じて任意のプリフィックスを浮動プリフィックスとして選択し、指定することが可能となる。

ＭＮ７００はＰＭＩＰｖ６ドメイン７１９内をローミング中に、時点Ｔ１、Ｔ２、Ｔ３などでそれぞれ垂直ハンドオフ・トリガメッセージを送信する。例えば時点Ｔ１では、ＨＩフラグが２の垂直ハンドオフ・トリガメッセージ７０８を３ＧセルラインタフェースＩｆ１経由でＬＭＡ／ＨＡ７１８に送信する。ＨＩフラグが２の場合とは通常動作を表し、したがって、ＬＭＡ／ＨＡ７１８はＨＩフラグ＝２を参照すると、ＭＡＧ／３ＧＰＰ７０７あてのＰＢＡメッセージ（不図示）でプリフィックスＰ１、Ｐ２を割り当てる。

ＭＮ７００はさらに移動して、時点Ｔ２では垂直ハンドオフするときには、プリフィックスＰ２も他のプリフィックスも通知する必要がなく、単に新しいＨＩフラグ付きの垂直ハンドオフ・トリガメッセージ７１２をＷＬＡＮインタフェースＩｆ２経由でＭＡＧ／ＷＬＡＮ７０２に送信すればよいだけである。ＬＭＡ／ＨＡ７１８は、この新しいＨＩフラグを、ＭＡＧ／ＷＬＡＮ７０２からＰＢＵメッセージ７１０で参照すると、同じくＰＢＵメッセージ７１０に含まれているアクセス技術タイプ（ＷＬＡＮ）が、最適化要求メッセージで登録されたアクセス技術タイプに該当する場合に、プリフィックスＰ２をＭＡＧ／ＷＬＡＮ７０２あてのＰＢＡメッセージ７１１で割り当てる。したがって、ＭＮ７００はプリフィックスＰ２をＭＡＧ／ＷＬＡＮ７０２からのＲＡメッセージ７０９で参照する。この新しいＨＩフラグにより、ＭＮ７００は垂直ハンドオフ規則の変更を明示的に記述する必要がない。垂直ハンドオフ規則が変更されると、ＨＩフラグが２の垂直ハンドオフ・トリガメッセージを送信する通常動作に移行する。ここで、当業者であれば、ＨＩフラグの数値は本発明の範囲を限定するものではないことは明らかである。ＨＩフラグの数値は、ＩＡＮＡ（Inter net AssignedNumber Association）のような機関によって定義される。

なお、最適化要求メッセージで登録されたプリフィックスＰ２が、アクセス技術タイプに限定されないプリフィックスであり、かつ継続的に使用するプリフィックスとして登録されている場合には、新しいＨＩフラグを含むＰＢＵメッセージ７１０を受信したＬＭＡ／ＨＡ７１８は、アクセス技術タイプにかかわらず、プリフィックスＰ２をＭＡＧ／ＷＬＡＮ７０２あてのＰＢＡメッセージ７１１で割り当てる。なお、この場合ＨＩフラグが２の通常の垂直ハンドオフ・トリガメッセージであってもよい。これにより、ＭＮ７００は、最適化要求メッセージ７０５にアクセス技術タイプを含める必要がない。ＭＡＧ／ＷＬＡＮ７０２も同様に、ＰＢＵメッセージ７１０にアクセス技術タイプを含める必要がなくなる。なお、ＬＭＡ／ＨＡ７１８が、従来のＨＩフラグの値がセットされた垂直ハンドオフ・トリガメッセージ７１２であっても、プリフィックスを含まないトリガメッセージを受信したときに、プリセットされたルールに基づいたプリフィックスの選択が求められていることを認識することができる場合は、新しいＨＩフラグの値を用いる必要はない。

本発明の第５の実施の形態におけるＭＮ７００の構成は、本発明の第１の実施の形態におけるＭＮ５００の構成とほぼ同様であるため説明を省略する。なお、本発明の第５の実施の形態で想定しているＭＮ７００の２つのインタフェースは、ＭＮ７００が有する３つ以上のインタフェースのうちの２つであってもよい。また、アクセス技術タイプに限定されないプリフィックスで、かつ継続的に使用するプリフィックスとしてプリフィックスＰ２を登録するための最適化要求メッセージ７０５を用いる方法は、本発明の第1の実施の形態にも適用可能である。本発明の第５の実施の形態により、最適化要求メッセージ７０５で継続的に使用するプリフィックスを登録したＭＮ７００は、垂直ハンドオフを実行する際に送信する垂直ハンドオフ・トリガメッセージの中に、移動させるプリフィックスを明示的に含める必要がなくなるという効果が得られる。

＜第６の実施の形態＞
次に図１１Ａ及び図１１Ｂを参照して第６の実施の形態について説明する。図１１Ａは、ＭＮ８００が４つのインタフェースＩｆ１、Ｉｆ２、Ｉｆ３、Ｉｆ４を有し、また、ＬＭＡ／ＨＡ８０５にルーティングされるＰＭＩＰｖ６ドメインに接続（attach）されていることを示す。ここで、ＭＮ８００はプリフィックスＰ１をインタフェースＩｆ１及びＭＡＧ８０１経由で、プリフィックスＰ２をインタフェースＩｆ２及びＭＡＧ８０２経由で、プリフィックスＰ３をインタフェースＩｆ３及びＭＡＧ８０３経由で、プリフィックスＰ４をインタフェースＩｆ４及びＭＡＧ８０４経由で参照しているものとする。

今、ＭＮ８００は、インタフェースＩｆ１をシャットダウンすることを決定すると、最初のステップでは、垂直ハンドオフ・トリガメッセージ８０６（図のMN trigger→HI=2, If1）をインタフェースＩｆ２経由でＭＡＧ８０２に送信してプリフィックスＰ１を通知する。ＬＭＡ／ＨＡ８０５は、このトリガメッセージ８０６をＰＢＵメッセージ（不図示）で受信すると、ＰＢＡメッセージ（不図示）で応答をＭＡＧ８０２に送信し、ＭＡＧ８０２は応答メッセージ８０７（図のResponse→P1,P2）をＭＮ８００に送信する。基本的に、ＭＮ８００は応答メッセージ８０７でプリフィックスＰ１、Ｐ２の両方を参照する。ここで、何らかの理由で、ＭＮ８００がローミング中に、インタフェースＩｆ２の垂直ハンドオフを実行しなければならない場合、ＭＮ８００は再び、プリフィックスＰ１の情報又はインタフェースＩｆ２の識別子を継続して送信する必要がある。したがって、この送信情報を最適化する必要がある。

そこで、プリフィックスＰ１の情報を除去して、プリフィックスＰ１に関する情報がシステム内のどのＭＡＧにも維持されないようにする。図１１Ｂはその例を示す。基本的に、ＭＮ８１０は、プリフィックスＰ１を他のプリフィックスＰ２、Ｐ３、Ｐ４へバインドするためのメッセージ８１６をＬＭＡ／ＨＡ８１５に送信する。このため、プリフィックスＰ１用のルーティング・ステートがシステム内のどのＭＡＧにも維持されず、プリフィックスＰ１については垂直ハンドオフする必要がない。ただし、代わりに、ＭＮ８１０がプリフィックスＰ１のフローを送受信するために何らかのトンネル化手順が必要になる。プリフィックスＰ１のフローは、プリフィックスＰ２に関連するアドレスあてにトンネル化されて適切にルーティングされる。この方法による主な利点とは、プリフィックスＰ１に関するステートをシステム内のどのＭＡＧにも維持する必要がないことにある。ただし、プリフィックスＰ１に関連するアドレスあてのパケットを受信するためにトンネル化が必要になる。

以上、本発明について実施の形態を参照して説明したが、当業者であれば、本発明を逸脱しない種々の変形が可能であることは明らかである。例えば、本発明の実施の形態の説明に用いた各ネットワーク構成図に記載されているシステムとして、３ＧＰＰ−ＬＴＥ（the Third Generation Partnership Project Long Term Evolution ）プロジェクトが作業を行っているＳＡＥ（System Architecture Evolution）を想定することができる。図１に示すシステムとＳＡＥの間の関係をマッチングさせると、ＬＭＡ／ＨＡは、３ＧＰＰネットワーク内に存在するＰＤＮ−ＧＷ（Packet Data Network Gateway）であり、ＭＡＧ／３ＧＰＰはＳ−ＧＷ（Serving Gateway）である。また、ＭＡＧ／ＷｉＭＡＸはＮｏｎ３ＧＰＰネットワーク内に存在するｅＰＤＧ（Evolved Packet Data Gateway）であり、さらに、ＭＡＧ／ＷＬＡＮはＮｏｎ３ＧＰＰネットワーク内に存在するＡＧＷ（Access Gateway）であり、ＭＮはＵＥ（User Equipment）である。この場合、３ＧＰＰネットワークでは、ＧＴＰ（Generic Tunnelling Protocol）又はＰＭＩＰ（ＰＭＩＰ：Proxy Mobile IP）を使用してＬＭＡ／ＨＡへ接続し、Ｎｏｎ３ＧＰＰネットワークでは、ＰＭＩＰを使用してＬＭＡ／ＨＡへ接続される。３ＧＰＰネットワークにおいて、ＧＴＰを使用していても、本発明の実施の形態で説明した手法を適用することができる。また、例えば上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用などが可能性としてあり得る。

本発明は、モバイルノードが静的な垂直ハンドオフの規則を有する場合には、垂直ハンドオフを要求するシグナリングのパケットサイズを減少することができるという効果を有し、ＰＭＩＰｖ６のプロトコルが３ＧＰＰサービス・アーキテクチャ・イボリューション（ＳＡＥ）ローカルドメイン内に採用されたＰＭＩＰｖ６ドメインなどに利用することができる。

Claims (15)

1. 共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有するモバイルノードが前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する場合の垂直ハンドオフ方法であって、
   前記第２又は第３のインタフェースが前記第２又は第３のネットワークへ垂直ハンドオフする前に使用していた、前記第１のインタフェースとは異なるプリフィックスを、前記垂直ハンドオフ後にも前記第２又は第３のインタフェースで継続的に使用するために、前記プリフィックスを前記モバイルノードのホームエージェントに設定するプリフィックス設定ステップと、
   前記モバイルノードが前記新しく接続する第２又は第３のインタフェースから前記ホームエージェントに対して、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信するステップと、
   前記ホームエージェントが前記トリガメッセージ内の前記垂直ハンドオフ・フラグを検知して、前記プリフィックス設定ステップにより設定されたプリフィックスを前記前に接続していた第２又は第３のインタフェースから前記新しく接続する第２又は第３のインタフェースに移すステップとを、
   有する垂直ハンドオフ方法。
2. 前記プリフィックス設定ステップは、前記モバイルノードが、前記継続的に使用するプリフィックスを決定して前記ホームエージェントに設定することを特徴とする請求項１に記載の垂直ハンドオフ方法。
3. 前記プリフィックス設定ステップは、前記ホームエージェントが前記モバイルノードの移動経路を学習して前記継続的に使用するプリフィックスを決定することを特徴とする請求項１に記載の垂直ハンドオフ方法。
4. 共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有するモバイルノードが前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する垂直ハンドオフシステムであって、
   前記第２又は第３のインタフェースが前記第２又は第３のネットワークへ垂直ハンドオフする前に使用していた、前記第１のインタフェースとは異なるプリフィックスを、前記垂直ハンドオフ後にも前記第２又は第３のインタフェースで継続的に使用するために、前記プリフィックスを前記モバイルノードのホームエージェントに設定するプリフィックス設定手段と、
   前記モバイルノードが前記新しく接続する第２又は第３のインタフェースから前記ホームエージェントに対して、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信する手段と、
   前記ホームエージェントが前記トリガメッセージ内の前記垂直ハンドオフ・フラグを検知して、前記プリフィックス設定手段により設定されたプリフィックスを前記前に接続していた第２又は第３のインタフェースから前記新しく接続する第２又は第３のインタフェースに移す手段とを、
   有する垂直ハンドオフシステム。
5. 前記プリフィックス設定手段は、前記モバイルノードが、前記継続的に使用するプリフィックスを決定して前記ホームエージェントに設定することを特徴とする請求項４に記載の垂直ハンドオフシステム。
6. 前記プリフィックス設定手段は、前記ホームエージェントが前記モバイルノードの移動経路を学習して前記継続的に使用するプリフィックスを決定することを特徴とする請求項４に記載の垂直ハンドオフシステム。
7. 共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有し、前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する垂直ハンドオフを行なうモバイルノードであって、
   前記新しく接続する第２又は第３のインタフェースからモバイルノードのホームエージェントに対して、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信する手段を、
   有するモバイルノード。
8. 前記第２又は第３のインタフェースが前記第２又は第３のネットワークへ垂直ハンドオフする前に使用していた、前記第１のインタフェースとは異なるプリフィックスを、前記垂直ハンドオフ後にも前記第２又は第３のインタフェースで継続的に使用することを決定して前記ホームエージェントに設定することを特徴とする請求項７に記載のモバイルノード。
9. 共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有するモバイルノードが前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する垂直ハンドオフシステムにおける前記モバイルノードのホームエージェントであって、
   前記モバイルノードの第２又は第３のインタフェースが前記第２又は第３のネットワークへ垂直ハンドオフする前に使用していた、前記第１のインタフェースとは異なるプリフィックスを記憶するプリフィックス記憶手段と、
   前記モバイルノードの前記新しく接続する前記第２又は第３のインタフェースから送信され、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを受信する手段と、
   前記トリガメッセージ内の前記垂直ハンドオフ・フラグを検知して、前記プリフィックス記憶手段に記憶されたプリフィックスを、前記前に接続していた第２又は第３のインタフェースから前記新しく接続する第２又は第３のインタフェースに移す手段とを、
   有するホームエージェント。
10. 前記プリフィックス記憶手段は、前記モバイルノードの第２又は第３のインタフェースが前記第２又は第３のネットワークへ垂直ハンドオフする前後で継続的に使用するプリフィックスとして、前記モバイルノードにより決定されて通知されたプリフィックスを記憶することを特徴とする請求項９に記載のホームエージェント。
11. 前記プリフィックス記憶手段は、前記モバイルノードが継続的に使用するプリフィックスとして、ホームエージェントが前記モバイルノードの移動経路を学習して決定したプリフィックスを記憶することを特徴とする請求項９に記載のホームエージェント。
12. 共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１乃至第３のネットワークにそれぞれ接続可能な第１乃至第３のインタフェースを有するモバイルノードが前記第１乃至第３のネットワーク内をローミングして、前記第２又は第３のインタフェースが選択的に前記第２又は第３のネットワークに新しく接続する場合の垂直ハンドオフ方法であって、
    前記モバイルノードが、前記第２又は第３のインタフェースが前記第２又は第３のネットワークへ垂直ハンドオフする前に使用していた前記第１のインタフェースとは異なるプリフィックスを、前記垂直ハンドオフ後にも前記第２又は第３のインタフェースで継続的に使用するために、前記モバイルノードのプロキシノードに設定するプリフィックス設定ステップと、
    前記プロキシノードの間で前記継続的に使用するプリフィックスを転送するステップと、
    前記モバイルノードが前記新しく接続する第２又は第３のインタフェースから前記プロキシノードに対して、垂直ハンドオフ・フラグを含みかつ前記新しく接続する第２又は第３のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信するステップと、
    前記プロキシノードが前記トリガメッセージを受信して、前記継続的に使用するプリフィックスを前記ホームエージェントに通知するステップと、
    前記ホームエージェントが前記通知されたプリフィックスを前記前に接続していた第２又は第３のインタフェースから前記新しく接続する第２又は第３のインタフェースに移すステップとを、
    有する垂直ハンドオフ方法。
13. 共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１と第２のネットワークにそれぞれ接続可能な第１のインタフェースと第２のインタフェースとを有するモバイルノードが前記第１と第２のネットワーク内をローミングして、前記第２のインタフェースが前記第２のネットワークから切断して前記第２のネットワークに再接続する場合の垂直ハンドオフ方法であって、
    前記第２のインタフェースが前記第２のネットワークへ垂直ハンドオフする前に使用していたプリフィックスを、前記垂直ハンドオフ後にも前記第２のインタフェースで継続的に使用するために、前記プリフィックスを前記モバイルノードのホームエージェントに設定するプリフィックス設定ステップと、
    前記モバイルノードが前記新しく接続する第２のインタフェースから前記ホームエージェントに対して、垂直ハンドオフ・フラグを含みかつ前記継続的に使用するプリフィックスを含まない垂直ハンドオフのトリガメッセージを送信するステップと、
    前記ホームエージェントが前記トリガメッセージ内の前記垂直ハンドオフ・フラグを検知して、前記第２のインタフェースが切断前に関連していたプリフィックスを前記新しく接続する第２のインタフェースに移すステップとを、
    有する垂直ハンドオフ方法。
14. 共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１と第２のネットワークにそれぞれ接続可能なインタフェースとを有するモバイルノードが前記第１と第２のネットワーク内をローミングして、前記第２のインタフェースが前記第２のネットワークから切断して前記第２のネットワークに再接続する場合の垂直ハンドオフ方法であって、
    前記モバイルノードが前記再接続時に前記第２のインタフェースから前記ホームエージェントに対して、前記第２のインタフェースが切断前に関連していたプリフィックスを前記第１のインタフェースに設定するか、又は前記第２のインタフェースに設定するかを指示する垂直ハンドオフ・フラグを含みかつ前記第２のインタフェースの識別子を含まない垂直ハンドオフのトリガメッセージを送信するステップと、
    前記ホームエージェントが前記トリガメッセージ内の前記垂直ハンドオフ・フラグに基づいて、前記第２のインタフェースが切断前に関連していたプリフィックスを前記第１又は第２のインタフェースに選択的に設定するステップとを、
    有する垂直ハンドオフ方法。
15. 共通の管理ノードにより管理されたプロキシモバイルＩＰが提供される第１と第２のネットワークにそれぞれ接続可能なインタフェースを少なくとも有するモバイルノードが前記第１のネットワークと第２のネットワーク内をローミングする場合に、前記第１のインタフェースに関連する第１のプリフィックスのパケットを前記第２のインタフェースに転送する垂直ハンドオフ方法であって、
    前記モバイルノードが前記第１のインタフェースをシャットダウンする際に、前記第１のプリフィックスを前記第２のインタフェースにバインディングするよう前記モバイルノードのホームエージェントに設定するステップと、
    前記ホームエージェントが前記第１のインタフェースあてのパケットを、前記バインディングに基づいて前記第２のインタフェースに転送するステップとを、
    有する垂直ハンドオフ方法。