JP4906610B2 - 移動ノードおよびパケットデータサービングノード - Google Patents
移動ノードおよびパケットデータサービングノード Download PDFInfo
- Publication number
- JP4906610B2 JP4906610B2 JP2007173961A JP2007173961A JP4906610B2 JP 4906610 B2 JP4906610 B2 JP 4906610B2 JP 2007173961 A JP2007173961 A JP 2007173961A JP 2007173961 A JP2007173961 A JP 2007173961A JP 4906610 B2 JP4906610 B2 JP 4906610B2
- Authority
- JP
- Japan
- Prior art keywords
- address
- packet data
- data serving
- sip
- domain
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
本発明は、次世代無線ネットワークにおける異種ローミングのための柔軟なモビリティ（mobility）フレームワークに関し、特に、次世代無線ネットワークにおける異種ローミングのための柔軟なモビリティを実現する移動ノードおよびパケットデータサービングノードに関する。
無線インターネットにおける通信事業者は異なるモビリティ機能を有し、移動クライアントも異なるモビリティ機能を有し得る。すなわち、ＩＭＳ（IP Multimedia Subsystem）およびＭＭＤ（Multimedia Domain）ネットワークは、モビリティ環境において異種性が存在する。例えば、ある通信事業者はＭＩＰｖ６（Mobile IP version 6）のような、移動ノードによって制御される移動プロトコルをサポートし、ある通信事業者はＰＭＩＰｖ６（Proxy Mobile IP version 6）のような、ネットワークによって制御される移動プロトコルをサポートし、ある場合には移動ノードにはモビリティスタックが設けられており、ある場合にはそれは設けられていない。アプリケーションに基づく場合には、移動ノードはアプリケーション層のモビリティプロトコルを用いる。
3GPP2 X.S0013-002-A v1.0: "All-IP Core Network Multimedia Domain; IP Multimedia Subsystem - Stage 2", November 2005 3GPP2 X.S0013-004-A v1.0: "All-IP Core Network Multimedia Domain: IP Multimedia Call Control based on SIP and SDP - Stage 3", November 2005 IETF RFC3775 "Mobility Support in IPv6"
3GPP2 X.S0013-002-A v1.0: "All-IP Core Network Multimedia Domain; IP Multimedia Subsystem - Stage 2", November 2005 3GPP2 X.S0013-004-A v1.0: "All-IP Core Network Multimedia Domain: IP Multimedia Call Control based on SIP and SDP - Stage 3", November 2005 IETF RFC3775 "Mobility Support in IPv6"
従って、現在の異種モビリティ環境において異なる無線通信事業者の間でシームレスなローミングサポートするために、異なるモビリティをサポートするネットワーク間でシームレスなモビリティをサポートする柔軟なモビリティフレームワークが存在しない。通信事業者間のローミングを実現可能にするために、柔軟なモビリティフレームワークを設けることが重要である。
本発明の第１形態による移動ノードは、パケットデータサービングノードとのセッションを確立後、同一ドメインのホームエージェントから前記パケットデータサービングノードが取得した第１アドレスを取得するアドレス取得手段と、前記第１アドレスのプレフィックスと自ら生成した第１および第２インタフェースＩＤを用いて第２および第３アドレスを生成するアドレス生成手段と、前記生成した第２および第３アドレスを前記パケットデータサービングノードに通知するアドレス通知手段と、前記第１、第２、第３アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信する通信手段と、を具備し、前記アドレス生成手段は、ハンドオフにより同一ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１および第２インタフェースＩＤを用いて第２および第３アドレスを生成する。
本発明の第１形態によるパケットデータサービングノードは、移動ノードとのセッションを確立後、同一ドメインのホームエージェントから第１アドレスを取得して前記移動ノードに割り当てるアドレス割り当て手段と、前記移動ノードから通知された第２および第３アドレスを前記同一ドメインのホームエージェントに登録するアドレス登録手段と、を具備する。
本発明の第１形態によれば、移動ノードとパケットデータサービングノードとのセッションが確立されると、パケットデータサービングノードのアドレス割り当て手段は同一ドメインのホームエージェントから第１アドレスを取得して移動ノードに割り当て、移動ノードのアドレス取得手段は第１アドレスを取得し、移動ノードのアドレス生成手段は第１アドレスのプレフィックスと自ら生成した第１および第２インタフェースＩＤを用いて第２および第３アドレスを生成し、移動ノードのアドレス通知手段は生成した第２および第３アドレスをパケットデータサービングノードに通知し、パケットデータサービングノードのアドレス登録手段は移動ノードから通知された第２および第３アドレスを同一ドメインのホームエージェントに登録し、移動ノードの通信手段は第１、第２、第３アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信し、移動ノードのアドレス生成手段は、ハンドオフにより同一ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１および第２インタフェースＩＤを用いて第２および第３アドレスを生成する。
したがって、ハンドオフ前後で第１、第２、第３アドレスは変わらない。
なお、本発明の第１形態には、ハンドオフがホームドメインで行われる場合と訪問先ドメインで行われる場合の両方が含まれる。
したがって、ハンドオフ前後で第１、第２、第３アドレスは変わらない。
なお、本発明の第１形態には、ハンドオフがホームドメインで行われる場合と訪問先ドメインで行われる場合の両方が含まれる。
本発明の第２形態による移動ノードは、第１アドレスを保持するアドレス保持手段と、パケットデータサービングノードとのセッションを確立後、同一ドメインのホームエージェントから前記パケットデータサービングノードが取得した第２アドレスを取得するアドレス取得手段と、前記取得した第２アドレスを前記同一ドメインのホームエージェントに登録するアドレス登録手段と、前記第２アドレスのプレフィックスと自ら生成した第１インタフェースＩＤを用いて第３アドレスを生成するアドレス生成手段と、前記生成した第３アドレスを前記パケットデータサービングノードに通知するアドレス通知手段と、前記第１、第２、第３アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信する通信手段と、を具備し、前記アドレス生成手段は、ハンドオフにより同一ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１インタフェースＩＤを用いて第３アドレスを生成する。
本発明の第２形態によるパケットデータサービングノードは、移動ノードとのセッションを確立後、同一ドメインのホームエージェントから第２アドレスを取得して前記移動ノードに割り当てるアドレス割り当て手段と、前記移動ノードから通知された第３アドレスを前記同一ドメインのホームエージェントに登録するアドレス登録手段と、を具備する。
本発明の第２形態によれば、移動ノードのアドレス保持手段は第１アドレスを保持し、移動ノードとパケットデータサービングノードとのセッションが確立されると、パケットデータサービングノードのアドレス割り当て手段は同一ドメインのホームエージェントから第２アドレスを取得して移動ノードに割り当て、移動ノードのアドレス取得手段は第２アドレスを取得し、移動ノードのアドレス登録手段は取得した第２アドレスを同一ドメインのホームエージェントに登録し、移動ノードのアドレス生成手段は第２アドレスのプレフィックスと自ら生成した第１インタフェースＩＤを用いて第３アドレスを生成し、移動ノードのアドレス通知手段は生成した第３アドレスをパケットデータサービングノードに通知し、パケットデータサービングノードのアドレス登録手段は移動ノードから通知された第３アドレスを同一ドメインのホームエージェントに登録し、移動ノードの通信手段は第１、第２、第３アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信し、移動ノードのアドレス生成手段は、ハンドオフにより同一ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１インタフェースＩＤを用いて第３アドレスを生成する。
したがって、ハンドオフ前後で第１、第２、第３アドレスは変わらない。
したがって、ハンドオフ前後で第１、第２、第３アドレスは変わらない。
本発明の第３形態による移動ノードは、訪問先ドメインのパケットデータサービングノードとのセッションを確立後、ホームドメインのホームエージェントから前記パケットデータサービングノードが取得した第１アドレスを取得するアドレス取得手段と、前記第１アドレスのプレフィックスと自ら生成した第１および第２インタフェースＩＤを用いて第３および第４アドレスを生成するアドレス生成手段と、前記生成した第３および第４アドレスを前記パケットデータサービングノードに通知するアドレス通知手段と、前記第１、第３、第４アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信する通信手段と、を具備し、前記アドレス生成手段は、ハンドオフにより前記訪問先ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１および第２インタフェースＩＤを用いて第３および第４アドレスを生成する。
本発明の第３形態によるパケットデータサービングノードは、他のドメインをホームドメインとする移動ノードとのセッションを確立後、同一ドメインのホームエージェントから第２アドレスを取得するとともに、前記移動ノードのホームドメインのホームエージェントから第１アドレスを取得し、前記第１アドレスを前記移動ノードに割り当てるアドレス割り当て手段と、前記移動ノードから通知された第３および第４アドレスを前記同一ドメインのホームエージェントに登録するアドレス登録手段と、を具備する。
本発明の第３形態によれば、他のドメインをホームドメインとする移動ノードと訪問先ドメインのパケットデータサービングノードとのセッションが確立されると、パケットデータサービングノードのアドレス割り当て手段は同一ドメインのホームエージェントから第２アドレスを取得するとともに、移動ノードのホームドメインのホームエージェントから第１アドレスを取得し、第１アドレスを移動ノードに割り当て、移動ノードのアドレス取得手段は第１アドレスを取得し、移動ノードのアドレス生成手段は第１アドレスのプレフィックスと自ら生成した第１および第２インタフェースＩＤを用いて第３および第４アドレスを生成し、移動ノードのアドレス通知手段は生成した第３および第４アドレスをパケットデータサービングノードに通知し、パケットデータサービングノードのアドレス登録手段は移動ノードから通知された第３および第４アドレスを同一ドメインのホームエージェントに登録し、移動ノードの通信手段は第１、第３、第４アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信し、移動ノードのアドレス生成手段は、ハンドオフにより訪問先ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１および第２インタフェースＩＤを用いて第３および第４アドレスを生成する。
したがって、ハンドオフ前後で第１、第２、第３アドレスは変わらない。
したがって、ハンドオフ前後で第１、第２、第３アドレスは変わらない。
本発明の第４形態による移動ノードは、第１アドレスを保持するアドレス保持手段と、訪問先ドメインのパケットデータサービングノードとのセッションを確立後、前記訪問先ドメインのホームエージェントから前記パケットデータサービングノードが取得した第２アドレスを取得するアドレス取得手段と、前記第２アドレスをホームドメインのホームエージェントに登録するアドレス登録手段と、前記第２アドレスのプレフィックスと自ら生成した第１インタフェースＩＤを用いて第３アドレスを生成するアドレス生成手段と、前記生成した第３アドレスを前記パケットデータサービングノードに通知するアドレス通知手段と、前記第１、第２、第３アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信する通信手段と、を具備し、前記アドレス生成手段は、ハンドオフにより前記訪問先ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１インタフェースＩＤを用いて第３アドレスを生成する。
本発明の第４形態によるパケットデータサービングノードは、他のドメインをホームドメインとする移動ノードとのセッションを確立後、同一ドメインのホームエージェントから第２アドレスを取得して前記移動ノードに割り当てるアドレス割り当て手段と、前記移動ノードから通知された第３アドレスを前記同一ドメインのホームエージェントに登録するアドレス登録手段と、を具備する。
本発明の第４形態によれば、移動ノードのアドレス保持手段は第１アドレスを保持し、他のドメインをホームドメインとする移動ノードと訪問先ドメインのパケットデータサービングノードとのセッションが確立されると、パケットデータサービングノードのアドレス割り当て手段は同一ドメインのホームエージェントから第２アドレスを取得して移動ノードに割り当て、移動ノードのアドレス取得手段は第２アドレスを取得し、移動ノードのアドレス登録手段は第２アドレスをホームドメインのホームエージェントに登録し、移動ノードのアドレス生成手段は第２アドレスのプレフィックスと自ら生成した第１インタフェースＩＤを用いて第３アドレスを生成し、移動ノードのアドレス通知手段は生成した第３アドレスをパケットデータサービングノードに通知し、パケットデータサービングノードのアドレス登録手段は移動ノードから通知された第３アドレスを同一ドメインのホームエージェントに登録し、移動ノードの通信手段は第１、第２、第３アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信し、移動ノードのアドレス生成手段は、ハンドオフにより訪問先ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１インタフェースＩＤを用いて第３アドレスを生成する。
したがって、ハンドオフ前後で第１、第２、第３アドレスは変わらない。
したがって、ハンドオフ前後で第１、第２、第３アドレスは変わらない。
次世代無線ネットワークにおける移動ノードは、異なる種類の移動のシナリオを含むローミングの配下に置かれ得る。これらの移動の種類は、ホームドメインまたは訪問先ドメインに限定することが可能である。移動ノードがホームドメインから離れて訪問先ドメインに存在するとき、移動ノードはローミングモードにあると定義する。移動ノードがローミングモードにあるとき、移動ノードは、同一の通信事業者ドメインに属する２つのサブネットワーク間で移動するか、または１つの通信事業者ドメインからもう１つの通信事業者ドメインに移動することが可能である。ローミングのシナリオにおいて任意の移動ノードは、ネットワークの構成要素および移動ノードのスタックにおいてサポートされるモビリティの種類、移動ノードにおいてサポートされるアプリケーションの種類、およびベアラマネージャを変更することを含むローカルドメイン内または訪問先ドメイン内の移動の種類のような、いくつかのレベルの異種性の配下に置かれ得る。また、訪問先ドメインに存在するとき、加入者はその恒久的ＩＰアドレスが訪問先の通信事業者ネットワークにさらされることを好まない。
本発明は、メディア（ユーザデータ）およびシグナリングが複数の異なるＩＰアドレスを用いる複数ＩＰアドレス付与アプローチを採用することによって、メディアのためのＩＰアドレス隠蔽に関する課題を解決する包括的な解決策を提供する。また、移動ノードにおいてサポートされるアプリケーションの異種性（例えば、ＳＩＰ（Session Initiation Protocol）をベースとする、または、ＳＩＰをベースとしない）、移動ノードおよびネットワークにおいて利用可能なモビリティサポートの種類、移動ノードがホームネットワークおよび訪問先ネットワークにおいて行う移動の種類のような他のいくつかのパラメータを検討する。以下で説明するフレームワークは、利用可能なモビリティの種類、サポートされるアプリケーション、およびネットワーク間の移動の種類を含む各々の可能な組み合わせについての解決策を与えることが可能である。
本発明は、ホームローカル、訪問先ローカル、グローバルモビリティ、および組み合わせのような異なる種類のローミングに有益な一連の解決策を与える。主として、シンプルＩＰ、プロキシＭＩＰｖ６、およびクライアントＭＩＰｖ６のような３種類のモビリティ動作を含み、柔軟な方法でシームレスなモビリティサポートを提供することが可能な解決策を構築する。このフレームワークは、移動ノードの移動パターン、移動ノードおよびネットワークのモビリティ機能、およびサポートされるアプリケーションの種類に基づいて用いることが可能なアプリケーション層、ネットワーク層、およびローカルモビリティプロトコルの組み合わせを用いる。例えば、ＭＩＰｖ６およびプロキシＭＩＰのようなネットワーク層のモビリティプロトコルは、要求されるシームレスなモビリティを提供することができないローミングの場合に、アプリケーション層の解決策を用いることが可能である。この解決策は、ドメイン間およびドメイン内のグローバルおよびローカルなモビリティを含む通信事業者間のローミングをサポートするために有効である。
図１はローミングのシナリオを表わす。通信事業者ネットワークは、訪問先（visited）ネットワークとともにホームネットワークにおいて移動ノードにシームレスなモビリティを提供することを計画している。通信中の移動ノードは、ホームドメインまたは訪問先ドメイン内での移動に基づく異なる種類のモビリティの配下に置かれ得る。ホームローカルモビリティは、ホームドメイン内の２つの異なるレイヤ３接続点の間で移動ノードが移動することとして定義される。移動ノードがホームネットワークからもう１つの通信事業者ネットワークに移動するとき、その移動はグローバルモビリティとして定義される。移動ノードが新たな通信事業者ネットワークに存在するとき、複数の種類のハンドオフの配下に置かれる。通信事業者ネットワークは多数のサブネットワークに分けることができ、各サブネットワークには訪問先ベアラマネージャ（Visited Bearer Manager）Ｖ−ＢＭと呼ぶベアラマネージャが設けられている。
同様に、移動ノードは、ホームネットワークから離れている間に、１つの通信事業者ネットワークからもう１つの通信事業者ネットワークに移動することも可能である。この場合には、各通信事業者ネットワークは個々のベアラマネージャが設けられる。
以下、移動ノードが通信事業者ネットワークに存在する間にシームレスなモビリティを提供することに焦点を合わせ、かつローカルモビリティに限定して検討する。このシナリオを訪問先ローカルモビリティと定義する。
同様に、移動ノードは、ホームネットワークから離れている間に、１つの通信事業者ネットワークからもう１つの通信事業者ネットワークに移動することも可能である。この場合には、各通信事業者ネットワークは個々のベアラマネージャが設けられる。
以下、移動ノードが通信事業者ネットワークに存在する間にシームレスなモビリティを提供することに焦点を合わせ、かつローカルモビリティに限定して検討する。このシナリオを訪問先ローカルモビリティと定義する。
図２は訪問先グローバルモビリティを表わし、ＭＮ（Mobile Node（移動ノード））が既に訪問先ドメインに存在するが、そのドメイン内で１つのサブネットワークからもう１つのサブネットワークに移動する典型的なグローバルモビリティのシナリオを表わす。この場合において、各サブネットワークは個々の訪問先ベアラマネージャまたはホームエージェントを有する。
図３は訪問先グローバルモビリティを表わし、移動ノードが２つのＶ−ＢＭの間で移動するドメイン間ローミングである。
図４は訪問先グローバルモビリティを表わし、移動ノードは既に訪問先ドメインに存在するが、１つの通信事業者ネットワークからもう１つの通信事業者ネットワークに移動する。これを訪問先グローバルモビリティと呼ぶ。
図３は訪問先グローバルモビリティを表わし、移動ノードが２つのＶ−ＢＭの間で移動するドメイン間ローミングである。
図４は訪問先グローバルモビリティを表わし、移動ノードは既に訪問先ドメインに存在するが、１つの通信事業者ネットワークからもう１つの通信事業者ネットワークに移動する。これを訪問先グローバルモビリティと呼ぶ。
上述した移動の種類は次の通りである。
・ホームローカルモビリティ
− 移動ノードの移動はホームドメインに限定される。
・訪問先ローカルモビリティ
− 移動ノードは訪問先ドメインに存在し、その移動は訪問先ドメインに限定される。
・グローバルモビリティ
− 移動ノードはホームドメインから訪問先ドメインに移動する。
− 移動ノードは１つの訪問先ベアラドメイン（ｖ−ＢＭ１）からもう１つの訪問先ベアラドメイン（ｖ−ＶＭ２）に移動することが可能である。
− 移動ノードは、ホームネットワークから離れている間に、１つの通信事業者ネットワークからもう１つの通信事業者ネットワークに移動することが可能である。
− ここでは範囲外である。
・ホームローカルモビリティ
− 移動ノードの移動はホームドメインに限定される。
・訪問先ローカルモビリティ
− 移動ノードは訪問先ドメインに存在し、その移動は訪問先ドメインに限定される。
・グローバルモビリティ
− 移動ノードはホームドメインから訪問先ドメインに移動する。
− 移動ノードは１つの訪問先ベアラドメイン（ｖ−ＢＭ１）からもう１つの訪問先ベアラドメイン（ｖ−ＶＭ２）に移動することが可能である。
− 移動ノードは、ホームネットワークから離れている間に、１つの通信事業者ネットワークからもう１つの通信事業者ネットワークに移動することが可能である。
− ここでは範囲外である。
上記は、移動ノードがそのローミングの間に配下に置かれ得る移動の種類を表わす。移動ノードの移動がそのホームドメイン内に限定されるとき、ホームローカルモビリティと呼ぶ。移動ノードがホームドメインから離れ、通信事業者ドメインに移動するとき、グローバルモビリティと呼ぶ。この移動の間に、移動ノードは、Ａ−ＩＭＳ（Advances to IMS）をベースとするネットワークまたはＭＭＤをベースとするネットワークであり得る通信事業者ドメインに移動することが可能である。また、目標とするネットワークがホームドメインにおいてサポートされるのと同種のモビリティをサポートしないことも大いにあり得る。一旦、移動ノードが訪問先ネットワークに存在し、さらなる移動に従うとき、訪問先ベアラマネージャが変わらない限り訪問先ローカルモビリティと呼ぶ。
グローバルモビリティのいくつかの種類が存在し得る。グローバルモビリティの第１形態は、移動ノードがそのホームネットワークから新たな通信事業者ネットワークに移動するときである。グローバルモビリティの第２形態は、移動ノードが同一の通信事業者ネットワーク内で１つの訪問先ベアラドメインからもう１つのベアラドメインに移動するときを含む。グローバルモビリティの第３形態は、ホームネットワークから離れている間に、移動ノードが１つの通信事業者ネットワークからもう１つの通信事業者ネットワークに移動するときを含む。この場合、各ネットワークに１つの、２つのＶＭが存在すると考えることが自然である。
グローバルモビリティのいくつかの種類が存在し得る。グローバルモビリティの第１形態は、移動ノードがそのホームネットワークから新たな通信事業者ネットワークに移動するときである。グローバルモビリティの第２形態は、移動ノードが同一の通信事業者ネットワーク内で１つの訪問先ベアラドメインからもう１つのベアラドメインに移動するときを含む。グローバルモビリティの第３形態は、ホームネットワークから離れている間に、移動ノードが１つの通信事業者ネットワークからもう１つの通信事業者ネットワークに移動するときを含む。この場合、各ネットワークに１つの、２つのＶＭが存在すると考えることが自然である。
モビリティスタック（移動性機能を実現するためのプロトコルスタック）は次の通りである。
・シンプルＩＰｖ６
− ＭＮがＰＤＳＮ（Packet Data Serving Node（パケットデータサービングノード））間を移動するとき、一時的なアドレスが変化する。
− １つはＳＩＰシグナリングのためであり、他はメディアのためである。
・［ＭＮ］ＭＩＰスタックなし
・［ネットワーク］ＨＡ（Home Agent（ホームエージェント））なし
・アプリケーションをベースとするモビリティが必要である（例えばＳＩＰモビリティ）
・ＣＭＩＰｖ６（Client Mobile IP version 6）
− ＭＮがＰＤＳＮ間を移動するとき、ＣｏＡ（Care of Address（気付アドレス））は変化するが、ＨｏＡ（Home Address（ホームアドレス））は変化しない。
− 静的ＨｏＡはＳＩＰシグナリングのためであり、一時的なＨｏＡはメディアのためである。
・［ＭＮ］ＭＩＰスタック
・［ネットワーク］ＨＡ
・ＰＭＩＰｖ６（Proxy Mobile IP version 6）
− ＭＮがＰＤＳＮ間を移動するとき、ＣｏＡは変化するが、ＨｏＡは変化しない。
− 静的ＨｏＡはＳＩＰシグナリングのためであり、一時的なＨｏＡはメディアのためである。
・［ＭＮ］ＭＩＰスタックなし
・［ネットワーク］ＨＡおよびＰＤＳＮにおけるＰＭＡ（Proxy Mobile Agent（プロキシモバイルエージェント））
・シンプルＩＰｖ６
− ＭＮがＰＤＳＮ（Packet Data Serving Node（パケットデータサービングノード））間を移動するとき、一時的なアドレスが変化する。
− １つはＳＩＰシグナリングのためであり、他はメディアのためである。
・［ＭＮ］ＭＩＰスタックなし
・［ネットワーク］ＨＡ（Home Agent（ホームエージェント））なし
・アプリケーションをベースとするモビリティが必要である（例えばＳＩＰモビリティ）
・ＣＭＩＰｖ６（Client Mobile IP version 6）
− ＭＮがＰＤＳＮ間を移動するとき、ＣｏＡ（Care of Address（気付アドレス））は変化するが、ＨｏＡ（Home Address（ホームアドレス））は変化しない。
− 静的ＨｏＡはＳＩＰシグナリングのためであり、一時的なＨｏＡはメディアのためである。
・［ＭＮ］ＭＩＰスタック
・［ネットワーク］ＨＡ
・ＰＭＩＰｖ６（Proxy Mobile IP version 6）
− ＭＮがＰＤＳＮ間を移動するとき、ＣｏＡは変化するが、ＨｏＡは変化しない。
− 静的ＨｏＡはＳＩＰシグナリングのためであり、一時的なＨｏＡはメディアのためである。
・［ＭＮ］ＭＩＰスタックなし
・［ネットワーク］ＨＡおよびＰＤＳＮにおけるＰＭＡ（Proxy Mobile Agent（プロキシモバイルエージェント））
上記は、モビリティの解決策を、シンプルＩＰ、ＣＭＩＰ、ＰＭＩＰのような３つの主要なカテゴリーに分類する。シンプルＩＰの場合において、ＳＩＰをベースとするモビリティのようなアプリケーション層のモビリティスタックを除いて、移動ノードにモビリティスタックは存在しない。各移動ノードはＳＩＰスタックを有すると考えられるので、アプリケーション層のモビリティをサポートするために追加のスタックは必要ない。
ＣＭＩＰｖ６はクライアントモバイルＩＰｖ６である。この場合、クライアントはホームエージェントに加えてモバイルＩＰスタックを有する。移動ノードがＣＭＩＰを用いるとき、移動ノードはその気付アドレスが変化したときにホームエージェントにＭＩＰ登録を送信する責任を有する。ＣＭＩＰを実現するために、ネットワーク構成要素は要求されるモビリティに関するシグナリングをサポートすべきである。移動ノードは２つの異なるＩＰアドレスを用いることが可能であり、１つはＳＩＰシグナリングのため、１つはメディアのためである。
第３の種類のモビリティサポートはＰＭＩＰｖ６を用いることである。この場合、移動ノードのＨｏＡは変化しないが、ＣｏＡは移動ノードがＰＤＳＮ間を移動するとき変化し得る。ＰＭＩＰｖ６の場合、ＳＩＰシグナリングのために静的ＨｏＡが用いられ、メディアのために一時的なＨｏＡが用いられる。移動ノードにＭＩＰスタックが存在しないためにＣｏＡは変化し得るが、各ＰＤＳＮにＰＭＡが存在する。通常、ＰＭＡは各ＰＤＳＮに存在する。
ＣＭＩＰｖ６はクライアントモバイルＩＰｖ６である。この場合、クライアントはホームエージェントに加えてモバイルＩＰスタックを有する。移動ノードがＣＭＩＰを用いるとき、移動ノードはその気付アドレスが変化したときにホームエージェントにＭＩＰ登録を送信する責任を有する。ＣＭＩＰを実現するために、ネットワーク構成要素は要求されるモビリティに関するシグナリングをサポートすべきである。移動ノードは２つの異なるＩＰアドレスを用いることが可能であり、１つはＳＩＰシグナリングのため、１つはメディアのためである。
第３の種類のモビリティサポートはＰＭＩＰｖ６を用いることである。この場合、移動ノードのＨｏＡは変化しないが、ＣｏＡは移動ノードがＰＤＳＮ間を移動するとき変化し得る。ＰＭＩＰｖ６の場合、ＳＩＰシグナリングのために静的ＨｏＡが用いられ、メディアのために一時的なＨｏＡが用いられる。移動ノードにＭＩＰスタックが存在しないためにＣｏＡは変化し得るが、各ＰＤＳＮにＰＭＡが存在する。通常、ＰＭＡは各ＰＤＳＮに存在する。
アプリケーションをベースとするモビリティにおけるアプリケーションの種類は次の通りである。
Ａ） ＳＩＰをベースとするＲＴＰ（Real-time Transport Protocol）／ＵＤＰ（例えば、ＶｏＩＰ（Voice-over-IP））
Ｂ） ＳＩＰをベースとしないＲＴＰ／ＵＤＰ（例えば、ＩＰ／ＴＶ（Internet Protocol/TeleVision）のためのＲＴＳＰ（Real Time Streaming Protocol））
Ｃ） ＳＩＰをベースとするＴＣＰ／ＩＰ（例えば、chattcp）
Ｄ） ＳＩＰをベースとしないＴＣＰ／ＩＰ（例えば、ftp、telnet）
Ａ） ＳＩＰをベースとするＲＴＰ（Real-time Transport Protocol）／ＵＤＰ（例えば、ＶｏＩＰ（Voice-over-IP））
Ｂ） ＳＩＰをベースとしないＲＴＰ／ＵＤＰ（例えば、ＩＰ／ＴＶ（Internet Protocol/TeleVision）のためのＲＴＳＰ（Real Time Streaming Protocol））
Ｃ） ＳＩＰをベースとするＴＣＰ／ＩＰ（例えば、chattcp）
Ｄ） ＳＩＰをベースとしないＴＣＰ／ＩＰ（例えば、ftp、telnet）
上記は、移動ノードがサポート可能なアプリケーションの種類を表わす。各々のアプリケーションの種類は遅延およびパケット損失に関して異なる性能要件を有する。トランスポートの種類によってアプリケーションは基本的にＴＣＰ／ＩＰおよびＲＴＰ／ＵＤＰの２種類に分けることができる。ＳＩＰをベースとするシグナリングを用いてセッションが確立されるならば、アプリケーションはＳＩＰをベースとする。ＳＩＰをベースとするセッションの例はVoice-over-IPおよびchattcpである。Voice-over-IPはＲＴＰ／ＵＤＰをベースとするが、chattcpはＴＣＰをベースとする。同様に、ＩＰ／ＴＶのようなＳＩＰをベースとしないＲＴＰ／ＵＤＰアプリケーションが存在し得る。また、ftpおよびtelnetのようなＳＩＰをベースとしないＴＣＰ／ＩＰアプリケーションが存在する。
表１は、移動ノード、ホームドメイン、訪問先ドメインのそれぞれについて、可能なモビリティ機能を表わす。
ローミング環境において、クライアントおよびネットワークは異なる種類のモビリティ機能を有し得る。例えば、移動ノードはモビリティスタックのないシンプルＩＰであり得る。または、移動ノードはアプリケーション層のＳＩＰモビリティが設けられることが可能であり、または、クライアントモバイルＩＰｖ６スタックが設けられることが可能である。クライアントのモビリティ機能をサポートするために、ネットワークも適切に配備される必要がある。従って、ネットワークは基本的なルーティングサポートを除いてモビリティをサポートしないか、または、ＭＩＰｖ６またはプロキシＭＩＰのいずれかをサポートするかである。ネットワークにおけるＭＩＰｖ６サポートの利益を得るために、クライアントもＣＭＩＰｖ６スタックが設けられる必要がある。しかし、ネットワークがＰＭＩＰをサポートしないならば、シンプルＩＰまたはＳＩＰモビリティのいずれかをサポートするクライアントは相互動作することができる。
移動ノード、すなわち端末のモビリティプロトコルにはシンプルＩＰとＣＭＩＰ（クライアントモバイルＩＰ）があり、ネットワークのモビリティ機能にはこれらに加えてＰＭＩＰ（プロキシモバイルＩＰ）がある。組み合わせのケースを表２に示す。
以下、表２に示す組み合わせのうち、ホームドメインでのローカルモビリティに関してケース１〜４を説明し、訪問先ドメインでのローカルモビリティに関してケース５〜８を説明する。
以下、図面および明細書中の「hMN」、「hDHCP」、「hPDSN」、「hP-CSCF」、「hS-CSCF」、「hI-CSCF」、「hHA」は、それぞれホームドメインに存在する、ＭＮ、ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバ、ＰＤＳＮ、Ｐ−ＣＳＣＦ（Proxy Call Session Control Function（プロキシコールセッション制御機能））サーバ、Ｓ−ＣＳＣＦ（Serving Call Session Control Function（サービングコールセッション制御機能））サーバ、Ｉ−ＣＳＣＦ（Interrogate Call State Control Function（問合せコールセッション制御機能））サーバ、ＨＡを意味し、「hTemp」、「hHoA」、「hCoA」は、それぞれホームドメインにおいて割り当てられた、一時的ＩＰアドレス、ホームアドレス、気付アドレスを意味する。同様に、「vMN」、「vDHCP」、「vPDSN」、「vP-CSCF」、「vS-CSCF」、「vI-CSCF」、「vHA」は、それぞれ訪問先ドメインに存在する、ＭＮ、ＤＨＣＰサーバ、ＰＤＳＮ、Ｐ−ＣＳＣＦサーバ、Ｓ−ＣＳＣＦサーバ、Ｉ−ＣＳＣＦサーバ、ＨＡを意味し、「vTemp」、「vHoA」、「vCoA」は、それぞれ訪問先ドメインにおいて割り当てられた、一時的ＩＰアドレス、ホームアドレス、気付アドレスを意味する。
以下、図面および明細書中の「hMN」、「hDHCP」、「hPDSN」、「hP-CSCF」、「hS-CSCF」、「hI-CSCF」、「hHA」は、それぞれホームドメインに存在する、ＭＮ、ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバ、ＰＤＳＮ、Ｐ−ＣＳＣＦ（Proxy Call Session Control Function（プロキシコールセッション制御機能））サーバ、Ｓ−ＣＳＣＦ（Serving Call Session Control Function（サービングコールセッション制御機能））サーバ、Ｉ−ＣＳＣＦ（Interrogate Call State Control Function（問合せコールセッション制御機能））サーバ、ＨＡを意味し、「hTemp」、「hHoA」、「hCoA」は、それぞれホームドメインにおいて割り当てられた、一時的ＩＰアドレス、ホームアドレス、気付アドレスを意味する。同様に、「vMN」、「vDHCP」、「vPDSN」、「vP-CSCF」、「vS-CSCF」、「vI-CSCF」、「vHA」は、それぞれ訪問先ドメインに存在する、ＭＮ、ＤＨＣＰサーバ、ＰＤＳＮ、Ｐ−ＣＳＣＦサーバ、Ｓ−ＣＳＣＦサーバ、Ｉ−ＣＳＣＦサーバ、ＨＡを意味し、「vTemp」、「vHoA」、「vCoA」は、それぞれ訪問先ドメインにおいて割り当てられた、一時的ＩＰアドレス、ホームアドレス、気付アドレスを意味する。
以下では次の点を前提条件として検討する。
・メディア用のＩＰアドレスはアプリケーション毎に割り当てられる。
・ＭＮとＨＡとの間でメディア用のモバイルＩＰｖ６トンネルは用いない。これは、CDMA2000に属する高速なデータ通信規格の１つであるEV-DO Rev.A（CDMA2000 1xEV-DO Revision A（IS-856-A））において、そのカプセル化によるオーバヘッドがメディアストリームに大きく影響するためである。
・メディア用のＩＰアドレスはアプリケーション毎に割り当てられる。
・ＭＮとＨＡとの間でメディア用のモバイルＩＰｖ６トンネルは用いない。これは、CDMA2000に属する高速なデータ通信規格の１つであるEV-DO Rev.A（CDMA2000 1xEV-DO Revision A（IS-856-A））において、そのカプセル化によるオーバヘッドがメディアストリームに大きく影響するためである。
＜ケース１＞
図５を参照し、ケース１（ＭＮ：シンプルＩＰ、ホームドメイン：シンプルＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＭＮはｈＰＤＳＮ１とのセッションを確立後、ＩＰアドレスhTemp#1を取得する（図５の（１））。続いてＰ−ＣＳＣＦサーバ（ｈＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｈＤＨＣＰ）へ問い合わせを行う（図５の（２））。これと同時にｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhTemp#2とhTemp#3を構築する（図５の（３））。ｈＭＮは、ＳＩＰシグナリングアドレスにはhTemp#1（図５の（４））、ＳＩＰのメディアアドレスにはhTemp#2、非ＳＩＰ系アプリケーションにはhTemp#3をそれぞれ用いる。
なお、hTemp#2、hTemp#3の生成は、以下で図６を参照して説明するように、それぞれ、ＳＩＰのメディア、非ＳＩＰ系アプリケーションで用いる前であれば、ＤＨＣＰサーバへの問い合わせと同時に行わなくてもよい。
図５を参照し、ケース１（ＭＮ：シンプルＩＰ、ホームドメイン：シンプルＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＭＮはｈＰＤＳＮ１とのセッションを確立後、ＩＰアドレスhTemp#1を取得する（図５の（１））。続いてＰ−ＣＳＣＦサーバ（ｈＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｈＤＨＣＰ）へ問い合わせを行う（図５の（２））。これと同時にｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhTemp#2とhTemp#3を構築する（図５の（３））。ｈＭＮは、ＳＩＰシグナリングアドレスにはhTemp#1（図５の（４））、ＳＩＰのメディアアドレスにはhTemp#2、非ＳＩＰ系アプリケーションにはhTemp#3をそれぞれ用いる。
なお、hTemp#2、hTemp#3の生成は、以下で図６を参照して説明するように、それぞれ、ＳＩＰのメディア、非ＳＩＰ系アプリケーションで用いる前であれば、ＤＨＣＰサーバへの問い合わせと同時に行わなくてもよい。
図６はケース１のシーケンスを示す。
ｈＭＮはｈＰＤＳＮ１とのセッションを確立後（LCP/CHAP）、ＩＰアドレスhTemp#1を取得する（IPv6CP (hTemp#1 Interface-ID), RA (hTemp#1 Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hP-CSCF)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhTemp#2とhTemp#3を構築する。hTemp#1はＳＩＰシグナリングアドレス、hTemp#2はＳＩＰのメディア用アドレス、hTemp#3は非ＳＩＰ系アプリケーションに使用される（SIP Registration (hTemp#1), SIP INVITE (SIP Signaling: hTemp#1, Media: hTemp#2), IP data (SIP: hTemp#2, non-SIP: hTemp#3)）。
ｈＭＮはｈＰＤＳＮ１とのセッションを確立後（LCP/CHAP）、ＩＰアドレスhTemp#1を取得する（IPv6CP (hTemp#1 Interface-ID), RA (hTemp#1 Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hP-CSCF)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhTemp#2とhTemp#3を構築する。hTemp#1はＳＩＰシグナリングアドレス、hTemp#2はＳＩＰのメディア用アドレス、hTemp#3は非ＳＩＰ系アプリケーションに使用される（SIP Registration (hTemp#1), SIP INVITE (SIP Signaling: hTemp#1, Media: hTemp#2), IP data (SIP: hTemp#2, non-SIP: hTemp#3)）。
本ケースではアプリケーションレイヤでのモビリティを行わない限り、ハンドオフ時にはＩＰアドレスが変わるため、一度切断される。すなわち、ｈＭＮがハンドオフすると、
ｈＭＮはｈＰＤＳＮ２とのセッションを確立後（LCP/CHAP）、ＩＰアドレスhTemp#4を取得する（IPv6CP (hTemp#4 Interface-ID), RA (hTemp#4 Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hP-CSCF)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhTemp#5とhTemp#6を構築する。hTemp#4はＳＩＰシグナリングアドレス、hTemp#5はＳＩＰのメディア用アドレス、hTemp#6は非ＳＩＰ系アプリケーションに使用される（SIP Registration (hTemp#4), SIP INVITE (SIP Signaling: hTemp#4, Media: hTemp#5), IP data (SIP: hTemp#5, non-SIP: hTemp#6)）。
以上のように、ケース１では、ホームドメイン内でハンドオフすると、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わる。
ｈＭＮはｈＰＤＳＮ２とのセッションを確立後（LCP/CHAP）、ＩＰアドレスhTemp#4を取得する（IPv6CP (hTemp#4 Interface-ID), RA (hTemp#4 Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hP-CSCF)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhTemp#5とhTemp#6を構築する。hTemp#4はＳＩＰシグナリングアドレス、hTemp#5はＳＩＰのメディア用アドレス、hTemp#6は非ＳＩＰ系アプリケーションに使用される（SIP Registration (hTemp#4), SIP INVITE (SIP Signaling: hTemp#4, Media: hTemp#5), IP data (SIP: hTemp#5, non-SIP: hTemp#6)）。
以上のように、ケース１では、ホームドメイン内でハンドオフすると、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わる。
＜ケース２＞
図７はケース２（ＭＮ：シンプルＩＰ、ホームドメイン：ＰＭＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＰＤＳＮ１はｈＭＮとのセッションを確立後、ＩＰアドレスhHoA#1を取得するため、PMIP BU（Proxy MIP Binding Update）をｈＨＡへ送出する（図７の（１））。ｈＨＡはｈＰＤＳＮ１への応答にhHoA#1アドレスを含める。ｈＰＤＳＮ１はｈＭＮへhHoA#1を割り当てる（図７の（２））。続いてＰ−ＣＳＣＦサーバ（ｈＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｈＤＨＣＰ）へ問い合わせを行う（図７の（３））。これと同時にｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhHoA#2とhHoA#3を構築する（図７の（４））。続いてｈＭＮはhHoA#2とhHoA#3の情報をｈＰＤＳＮ１へ伝え、ｈＰＤＳＮ１はこれらのアドレスをｈＨＡへ登録する（図７の（５）、ｈＰＤＳＮ１からｈＨＡへPMIP BUを送出してhHoA#2とhHoA#3を通知する）。ｈＭＮは、ＳＩＰシグナリングアドレスにはhHoA#1（図７の（６））、ＳＩＰのメディアアドレスにはhHoA#2、非ＳＩＰ系アプリケーションにはhHoA#3をそれぞれ用いる。
なお、hHoA#2、hHoA#3の生成は、以下で図８を参照して説明するように、それぞれ、ＳＩＰのメディア、非ＳＩＰ系アプリケーションで用いる前であれば、ＤＨＣＰサーバへの問い合わせと同時に行わなくてもよい。
図７はケース２（ＭＮ：シンプルＩＰ、ホームドメイン：ＰＭＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＰＤＳＮ１はｈＭＮとのセッションを確立後、ＩＰアドレスhHoA#1を取得するため、PMIP BU（Proxy MIP Binding Update）をｈＨＡへ送出する（図７の（１））。ｈＨＡはｈＰＤＳＮ１への応答にhHoA#1アドレスを含める。ｈＰＤＳＮ１はｈＭＮへhHoA#1を割り当てる（図７の（２））。続いてＰ−ＣＳＣＦサーバ（ｈＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｈＤＨＣＰ）へ問い合わせを行う（図７の（３））。これと同時にｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhHoA#2とhHoA#3を構築する（図７の（４））。続いてｈＭＮはhHoA#2とhHoA#3の情報をｈＰＤＳＮ１へ伝え、ｈＰＤＳＮ１はこれらのアドレスをｈＨＡへ登録する（図７の（５）、ｈＰＤＳＮ１からｈＨＡへPMIP BUを送出してhHoA#2とhHoA#3を通知する）。ｈＭＮは、ＳＩＰシグナリングアドレスにはhHoA#1（図７の（６））、ＳＩＰのメディアアドレスにはhHoA#2、非ＳＩＰ系アプリケーションにはhHoA#3をそれぞれ用いる。
なお、hHoA#2、hHoA#3の生成は、以下で図８を参照して説明するように、それぞれ、ＳＩＰのメディア、非ＳＩＰ系アプリケーションで用いる前であれば、ＤＨＣＰサーバへの問い合わせと同時に行わなくてもよい。
図８はケース２のシーケンスを示す。
ｈＰＤＳＮ１はｈＭＮとのセッションを確立後（LCP/CHAP）、PMIP BUをｈＨＡへ送出し、ｈＨＡはｈＰＤＳＮ１への応答にhHoA#1アドレスを含める（PMIP Reg./Reply (hHoA#1)）。ｈＰＤＳＮ１はｈＭＮへhHoA#1を割り当てる（IPv6CP (hHoA#1 Interface-ID), RA (hHoA Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hP-CSCF)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhHoA#2とhHoA#3を構築する。続いてｈＭＮはhHoA#2とhHoA#3の情報をｈＰＤＳＮ１へ伝え、ｈＰＤＳＮ１はこれらのアドレスをｈＨＡへ登録する（図８には示さない）。hHoA#1はＳＩＰシグナリングアドレス、hHoA#2はＳＩＰのメディア用アドレス、hHoA#3は非ＳＩＰ系アプリケーションに使用される（SIP Registration (hHoA#1), SIP INVITE (SIP Signaling: hHoA#1, Media: hHoA#2), IP data (SIP: hHoA#2, non-SIP: hHoA#3)）。
ｈＰＤＳＮ１はｈＭＮとのセッションを確立後（LCP/CHAP）、PMIP BUをｈＨＡへ送出し、ｈＨＡはｈＰＤＳＮ１への応答にhHoA#1アドレスを含める（PMIP Reg./Reply (hHoA#1)）。ｈＰＤＳＮ１はｈＭＮへhHoA#1を割り当てる（IPv6CP (hHoA#1 Interface-ID), RA (hHoA Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hP-CSCF)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhHoA#2とhHoA#3を構築する。続いてｈＭＮはhHoA#2とhHoA#3の情報をｈＰＤＳＮ１へ伝え、ｈＰＤＳＮ１はこれらのアドレスをｈＨＡへ登録する（図８には示さない）。hHoA#1はＳＩＰシグナリングアドレス、hHoA#2はＳＩＰのメディア用アドレス、hHoA#3は非ＳＩＰ系アプリケーションに使用される（SIP Registration (hHoA#1), SIP INVITE (SIP Signaling: hHoA#1, Media: hHoA#2), IP data (SIP: hHoA#2, non-SIP: hHoA#3)）。
本ケースではｈＨＡを用いることにより、ハンドオフが可能である。ハンドオフ後も同じインタフェースＩＤを構築することでアドレスを継続使用できる。すなわち、ｈＭＮがハンドオフし、ｈＰＤＳＮ２とのセッションを確立すると（LCP/CHAP）、ｈＰＤＳＮ２はPMIP BUをｈＨＡへ送出し、ｈＨＡはｈＰＤＳＮ２への応答にhHoA#1アドレスを含める（PMIP Reg./Reply (hHoA#1)）。ｈＰＤＳＮ２はｈＭＮへhHoA#1を割り当てる（IPv6CP (hHoA#1 Interface-ID), RA (hHoA Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hP-CSCF)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと、ハンドオフ前と同じインタフェースＩＤを用い、アドレスhHoA#2とhHoA#3を構築する。続いてｈＭＮはhHoA#2とhHoA#3の情報をｈＰＤＳＮ２へ伝え、ｈＰＤＳＮ２はこれらのアドレスをｈＨＡへ登録する（図８には示さない）。hHoA#1はＳＩＰシグナリングアドレス、hHoA#2はＳＩＰのメディア用アドレス、hHoA#3は非ＳＩＰ系アプリケーションに使用される（IP data (SIP: hHoA#2, non-SIP: hHoA#3)）。
以上のように、ケース２では、ホームドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。すなわち、シームレスなハンドオフがサポートされる。
以上のように、ケース２では、ホームドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。すなわち、シームレスなハンドオフがサポートされる。
＜ケース３＞
図９はケース３（ＭＮ：ＣＭＩＰ、ホームドメイン：ＰＭＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＭＮはＣＭＩＰをサポートする移動ノードとしてホームアドレスhHoA#1を保持し、もしくは下位レイヤにて割り当てられている。ｈＰＤＳＮ１はｈＭＮとのセッションを確立後、ＩＰアドレスhHoA#2を取得するため、PMIP BU（Proxy MIP Binding Update）をｈＨＡへ送出する（図９の（１））。ｈＨＡはｈＰＤＳＮ１への応答にhHoA#2アドレスを含める。ｈＰＤＳＮ１はｈＭＮへhHoA#2を割り当てる（図９の（２））。続いてＰ−ＣＳＣＦサーバ（ｈＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｈＤＨＣＰ）へ問い合わせを行う（図９の（３））。また、ｈＭＮはCMIP BUをｈＨＡへ送出してhHoA#2を登録する（図９の（４））。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhHoA#3を構築する（図９の（５））。続いてｈＭＮはhHoA#3の情報をｈＰＤＳＮ１へ伝え、ｈＰＤＳＮ１はこのアドレスをｈＨＡへ登録する（図９の（６）、ｈＰＤＳＮ１からｈＨＡへPMIP BUを送出してhHoA#3を通知する）。ｈＭＮは、ＳＩＰシグナリングアドレスにはhHoA#1（図９の（７））、ＳＩＰのメディアアドレスにはhHoA#2、非ＳＩＰ系アプリケーションにはhHoA#3をそれぞれ用いる。
なお、hHoA#3の生成は、以下で図１０を参照して説明するように、非ＳＩＰ系アプリケーションで用いる前までに行えばよい。
図９はケース３（ＭＮ：ＣＭＩＰ、ホームドメイン：ＰＭＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＭＮはＣＭＩＰをサポートする移動ノードとしてホームアドレスhHoA#1を保持し、もしくは下位レイヤにて割り当てられている。ｈＰＤＳＮ１はｈＭＮとのセッションを確立後、ＩＰアドレスhHoA#2を取得するため、PMIP BU（Proxy MIP Binding Update）をｈＨＡへ送出する（図９の（１））。ｈＨＡはｈＰＤＳＮ１への応答にhHoA#2アドレスを含める。ｈＰＤＳＮ１はｈＭＮへhHoA#2を割り当てる（図９の（２））。続いてＰ−ＣＳＣＦサーバ（ｈＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｈＤＨＣＰ）へ問い合わせを行う（図９の（３））。また、ｈＭＮはCMIP BUをｈＨＡへ送出してhHoA#2を登録する（図９の（４））。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhHoA#3を構築する（図９の（５））。続いてｈＭＮはhHoA#3の情報をｈＰＤＳＮ１へ伝え、ｈＰＤＳＮ１はこのアドレスをｈＨＡへ登録する（図９の（６）、ｈＰＤＳＮ１からｈＨＡへPMIP BUを送出してhHoA#3を通知する）。ｈＭＮは、ＳＩＰシグナリングアドレスにはhHoA#1（図９の（７））、ＳＩＰのメディアアドレスにはhHoA#2、非ＳＩＰ系アプリケーションにはhHoA#3をそれぞれ用いる。
なお、hHoA#3の生成は、以下で図１０を参照して説明するように、非ＳＩＰ系アプリケーションで用いる前までに行えばよい。
図１０はケース３のシーケンスを示す。
ｈＰＤＳＮ１はｈＭＮとのセッションを確立すると（LCP/CHAP）、PMIP BUをｈＨＡへ送出し、ｈＨＡはｈＰＤＳＮ１への応答にhHoA#2アドレスを含める（PMIP Reg./Reply (hHoA#2)）。ｈＰＤＳＮ１はｈＭＮへhHoA#2を割り当てる（IPv6CP (hHoA#2 Interface-ID), RA (hHoA Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hHA, hP-CSCF)）。また、ｈＭＮはCMIP BUをｈＨＡへ送出してhHoA#2を登録する（CMIP Update (CoA: hHoA#2)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhHoA#3を構築する。続いてｈＭＮはhHoA#3の情報をｈＰＤＳＮ１へ伝え、ｈＰＤＳＮ１はこのアドレスをｈＨＡへ登録する（図１０には示さない）。hHoA#1はＳＩＰシグナリングアドレス、hHoA#2はＳＩＰのメディア用アドレス、hHoA#3は非ＳＩＰ系アプリケーションに使用される（SIP Registration (hHoA#1), SIP INVITE (SIP Signaling: hHoA#1, Media: hHoA#2), IP data (SIP: hHoA#2, non-SIP: hHoA#3)）。
ｈＰＤＳＮ１はｈＭＮとのセッションを確立すると（LCP/CHAP）、PMIP BUをｈＨＡへ送出し、ｈＨＡはｈＰＤＳＮ１への応答にhHoA#2アドレスを含める（PMIP Reg./Reply (hHoA#2)）。ｈＰＤＳＮ１はｈＭＮへhHoA#2を割り当てる（IPv6CP (hHoA#2 Interface-ID), RA (hHoA Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hHA, hP-CSCF)）。また、ｈＭＮはCMIP BUをｈＨＡへ送出してhHoA#2を登録する（CMIP Update (CoA: hHoA#2)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhHoA#3を構築する。続いてｈＭＮはhHoA#3の情報をｈＰＤＳＮ１へ伝え、ｈＰＤＳＮ１はこのアドレスをｈＨＡへ登録する（図１０には示さない）。hHoA#1はＳＩＰシグナリングアドレス、hHoA#2はＳＩＰのメディア用アドレス、hHoA#3は非ＳＩＰ系アプリケーションに使用される（SIP Registration (hHoA#1), SIP INVITE (SIP Signaling: hHoA#1, Media: hHoA#2), IP data (SIP: hHoA#2, non-SIP: hHoA#3)）。
本ケースではｈＨＡを用いることにより、ハンドオフが可能である。ハンドオフ後も同じインタフェースＩＤを構築することでアドレスを継続使用できる。すなわち、ｈＭＮがハンドオフし、ｈＰＤＳＮ２とのセッションを確立すると（LCP/CHAP）、ｈＰＤＳＮ２はPMIP BUをｈＨＡへ送出し、ｈＨＡはｈＰＤＳＮ２への応答にhHoA#2アドレスを含める（PMIP Reg./Reply (hHoA#2)）。ｈＰＤＳＮ２はｈＭＮへhHoA#2を割り当てる（IPv6CP (hHoA#2 Interface-ID), RA (hHoA#2 Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hHA, hP-CSCF)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと、ハンドオフ前と同じインタフェースＩＤを用い、アドレスhHoA#3を構築する。続いてｈＭＮはhHoA#3の情報をｈＰＤＳＮ２へ伝え、ｈＰＤＳＮ２はこのアドレスをｈＨＡへ登録する（図１０には示さない）。hHoA#1はＳＩＰシグナリングアドレスに使用され、hHoA#2はＳＩＰのメディア用アドレス、hHoA#3は非ＳＩＰ系アプリケーションに使用される（IP data (SIP: hHoA#2, non-SIP: hHoA#3)）。
すなわち、ＣＭＩＰはＳＩＰのためのハンドオフをサポートし、ＰＭＩＰはメディアのためハンドオフをサポートする。
以上のように、ケース３では、ホームドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。すなわち、シームレスなハンドオフがサポートされる。
すなわち、ＣＭＩＰはＳＩＰのためのハンドオフをサポートし、ＰＭＩＰはメディアのためハンドオフをサポートする。
以上のように、ケース３では、ホームドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。すなわち、シームレスなハンドオフがサポートされる。
＜ケース４＞
図１１はケース４（ＭＮ：ＣＭＩＰ、ホームドメイン：ＣＭＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＭＮはＣＭＩＰをサポートする移動ノードとしてホームアドレスhHoA#1を保持している、もしくは下位レイヤにて割り当てられている。ｈＰＤＳＮ１はｈＭＮへhCoA#2を割り当てる（図１１の（１））。続いてＰ−ＣＳＣＦサーバ（ｈＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｈＤＨＣＰ）へ問い合わせを行う（図１１の（２））。これと同時にｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhTemp#3を構築する（図１１の（３））。ｈＭＮは、ｈＨＡへhCoA#2の情報を登録するため、CMIP BU（CMIP Binding Update）をｈＨＡへ送出する（図１１の（４））。ｈＭＮは、ＳＩＰシグナリングアドレスにはhHoA#1（図１１の（５））、ＳＩＰのメディアアドレスにはhCoA#2、非ＳＩＰ系アプリケーションにはhTemp#3をそれぞれ用いる。
なお、hTemp#3の生成は、以下で図１２を参照して説明するように、非ＳＩＰ系アプリケーションで当該アドレスを用いる前であれば、ＤＨＣＰサーバへの問い合わせと同時に行わなくてもよい。
図１１はケース４（ＭＮ：ＣＭＩＰ、ホームドメイン：ＣＭＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＭＮはＣＭＩＰをサポートする移動ノードとしてホームアドレスhHoA#1を保持している、もしくは下位レイヤにて割り当てられている。ｈＰＤＳＮ１はｈＭＮへhCoA#2を割り当てる（図１１の（１））。続いてＰ−ＣＳＣＦサーバ（ｈＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｈＤＨＣＰ）へ問い合わせを行う（図１１の（２））。これと同時にｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhTemp#3を構築する（図１１の（３））。ｈＭＮは、ｈＨＡへhCoA#2の情報を登録するため、CMIP BU（CMIP Binding Update）をｈＨＡへ送出する（図１１の（４））。ｈＭＮは、ＳＩＰシグナリングアドレスにはhHoA#1（図１１の（５））、ＳＩＰのメディアアドレスにはhCoA#2、非ＳＩＰ系アプリケーションにはhTemp#3をそれぞれ用いる。
なお、hTemp#3の生成は、以下で図１２を参照して説明するように、非ＳＩＰ系アプリケーションで当該アドレスを用いる前であれば、ＤＨＣＰサーバへの問い合わせと同時に行わなくてもよい。
図１２はケース４のシーケンスを示す。
ｈＰＤＳＮ１はｈＭＮとのセッションを確立すると（LCP/CHAP）、ｈＭＮへhCoA#2を割り当てる（IPv6CP (hCoA#2 Interface-ID), RA (hCoA#2 Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hHA, hP-CSCF)）。ｈＭＮはｈＨＡへhCoA#2の情報を登録するため、CMIP BUをｈＨＡへ送出してhCoA#2を登録する（CMIP Update (CoA: hCoA#2)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhTemp#3を構築する。hHoA#1はＳＩＰシグナリングアドレス、hCoA#2はＳＩＰのメディア用アドレス、hTemp#3は非ＳＩＰ系アプリケーションに使用される（SIP Registration (hHoA#1), SIP INVITE (SIP Signaling: hHoA#1, Media: hCoA#2), IP data (SIP: hCoA#2, non-SIP: hTemp#3)）。
ｈＰＤＳＮ１はｈＭＮとのセッションを確立すると（LCP/CHAP）、ｈＭＮへhCoA#2を割り当てる（IPv6CP (hCoA#2 Interface-ID), RA (hCoA#2 Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hHA, hP-CSCF)）。ｈＭＮはｈＨＡへhCoA#2の情報を登録するため、CMIP BUをｈＨＡへ送出してhCoA#2を登録する（CMIP Update (CoA: hCoA#2)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhTemp#3を構築する。hHoA#1はＳＩＰシグナリングアドレス、hCoA#2はＳＩＰのメディア用アドレス、hTemp#3は非ＳＩＰ系アプリケーションに使用される（SIP Registration (hHoA#1), SIP INVITE (SIP Signaling: hHoA#1, Media: hCoA#2), IP data (SIP: hCoA#2, non-SIP: hTemp#3)）。
本ケースではｈＨＡが存在するものの、無線区間には帯域幅制限のためモバイルＩＰトンネルを使用できない。したがって、メディアに使用するアドレスではホームアドレスを使用しないため、ハンドオフ後は新たにＩＰアドレスを取得する。すなわち、ｈＭＮがハンドオフし、ｈＰＤＳＮ２とのセッションを確立すると（LCP/CHAP）、ｈＰＤＳＮ２はｈＭＮへhCoA#4を割り当てる（IPv6CP (hCoA#4 Interface-ID), RA (hCoA#4 Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hHA, hP-CSCF)）。ｈＭＮはｈＨＡへhCoA#4の情報を登録するため、CMIP BUをｈＨＡへ送出する（CMIP Update (CoA: hCoA#4)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスhTemp#5を構築する。hHoA#1はＳＩＰシグナリングアドレス、hCoA#4はＳＩＰのメディア用アドレス、hTemp#5は非ＳＩＰ系アプリケーションに使用される（IP data (SIP: hCoA#2, non-SIP: hTemp#3)）。
以上のように、ケース４では、ホームドメイン内でハンドオフすると、ＳＩＰシグナリングアドレスは変わらないが、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わる。
以上のように、ケース４では、ホームドメイン内でハンドオフすると、ＳＩＰシグナリングアドレスは変わらないが、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わる。
＜ケース５＞
図１３はケース５（ＭＮ：シンプルＩＰ、ホームドメイン：シンプルＩＰ、訪問先ドメイン：シンプルＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＭＮはシンプルＩＰをサポートする移動ノードとして動作している。ｖＰＤＳＮ１はvTemp#1をｈＭＮへ割り当てる（図１３の（１））。続いてＰ−ＣＳＣＦサーバ（ｖＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｖＤＨＣＰ）へ問い合わせを行う（図１３の（２））。これと同時にｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスvTemp#2とvTemp#3を構築する（図１３の（３））。ＳＩＰシグナリングアドレスにはvTemp#1（図１３の（４））、ＳＩＰのメディアアドレスにはvTemp#2、非ＳＩＰ系アプリケーションにはvTemp#3をそれぞれ用いる。
なお、vTemp#2、vTemp#3の生成は、以下で図１４を参照して説明するように、それぞれ、ＳＩＰのメディア、非ＳＩＰ系アプリケーションで用いる前であれば、ＤＨＣＰサーバへの問い合わせと同時に行わなくてもよい。
図１３はケース５（ＭＮ：シンプルＩＰ、ホームドメイン：シンプルＩＰ、訪問先ドメイン：シンプルＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＭＮはシンプルＩＰをサポートする移動ノードとして動作している。ｖＰＤＳＮ１はvTemp#1をｈＭＮへ割り当てる（図１３の（１））。続いてＰ−ＣＳＣＦサーバ（ｖＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｖＤＨＣＰ）へ問い合わせを行う（図１３の（２））。これと同時にｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスvTemp#2とvTemp#3を構築する（図１３の（３））。ＳＩＰシグナリングアドレスにはvTemp#1（図１３の（４））、ＳＩＰのメディアアドレスにはvTemp#2、非ＳＩＰ系アプリケーションにはvTemp#3をそれぞれ用いる。
なお、vTemp#2、vTemp#3の生成は、以下で図１４を参照して説明するように、それぞれ、ＳＩＰのメディア、非ＳＩＰ系アプリケーションで用いる前であれば、ＤＨＣＰサーバへの問い合わせと同時に行わなくてもよい。
図１４はケース５のシーケンスを示す。
ｖＰＤＳＮ１はｈＭＮとのセッションを確立すると（LCP/CHAP）、vTemp#1をｈＭＮへ割り当てる（IPv6CP (vTemp#1 Interface-ID), RA (vTemp#1 Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (vP-CSCF)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスvTemp#2とvTemp#3を構築する。vTemp#1はＳＩＰシグナリングアドレス、vTemp#2はＳＩＰのメディア用アドレス、vTemp#3は非ＳＩＰ系アプリケーションに使用される（SIP Registration (vTemp#1), SIP INVITE (SIP Signaling: vTemp#1, Media: vTemp#2), IP data (SIP: vTemp#2, non-SIP: vTemp#3)）。
ｖＰＤＳＮ１はｈＭＮとのセッションを確立すると（LCP/CHAP）、vTemp#1をｈＭＮへ割り当てる（IPv6CP (vTemp#1 Interface-ID), RA (vTemp#1 Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (vP-CSCF)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスvTemp#2とvTemp#3を構築する。vTemp#1はＳＩＰシグナリングアドレス、vTemp#2はＳＩＰのメディア用アドレス、vTemp#3は非ＳＩＰ系アプリケーションに使用される（SIP Registration (vTemp#1), SIP INVITE (SIP Signaling: vTemp#1, Media: vTemp#2), IP data (SIP: vTemp#2, non-SIP: vTemp#3)）。
本ケースではシンプルＩＰのため、ハンドオフ後は新たにＩＰアドレスを取得する。すなわち、ｈＭＮがハンドオフし、ｖＰＤＳＮ２とのセッションを確立すると（LCP/CHAP）、ｖＰＤＳＮ２はvTemp#4をｈＭＮへ割り当てる（IPv6CP (vTemp#4 Interface-ID), RA (vTemp#4 Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (ｈP-CSCF)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスvTemp#5とvTemp#6を構築する。vTemp#4はＳＩＰシグナリングアドレス、vTemp#5はＳＩＰのメディア用アドレス、vTemp#6は非ＳＩＰ系アプリケーションに使用される（SIP Registration (vTemp#4), SIP INVITE (SIP Signaling: vTemp#4, Media: vTemp#5), IP data (SIP: vTemp#5, non-SIP: vTemp#6)）。
以上のように、ケース５では、訪問先ドメイン内でハンドオフすると、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わる。
以上のように、ケース５では、訪問先ドメイン内でハンドオフすると、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わる。
＜ケース６＞
図１５はケース６（ＭＮ：シンプルＩＰ、ホームドメイン：シンプルＩＰ、訪問先ドメイン：ＰＭＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＭＮはシンプルＩＰをサポートする移動ノードとして動作している。ｖＰＤＳＮ１はｖＨＡへPMIP BUを送出してvHoA#1を取得し（図１５の（１））、ｈＭＮへ割り当てる（図１５の（２））。続いてＰ−ＣＳＣＦサーバ（ｖＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｖＤＨＣＰ）へ問い合わせを行う（図１５の（３））。これと同時にｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスvHoA#2とvHoA#3を構築する（図１５の（４））。続いてｈＭＮはvHoA#2とvHoA#3の情報をｖＰＤＳＮ１へ伝え、ｖＰＤＳＮ１はこれらのアドレスをｖＨＡへ登録する（図５の（５））。ＳＩＰシグナリングアドレスにはvHoA#1（図１５の（６））、ＳＩＰのメディアアドレスにはvHoA#2、非ＳＩＰ系アプリケーションにはvHoA#3をそれぞれ用いる。
なお、vHoA#2、vHoA#3の生成は、以下で図１６を参照して説明するように、それぞれ、ＳＩＰのメディア、非ＳＩＰ系アプリケーションで用いる前であれば、ＤＨＣＰサーバへの問い合わせと同時に行わなくてもよい。
図１５はケース６（ＭＮ：シンプルＩＰ、ホームドメイン：シンプルＩＰ、訪問先ドメイン：ＰＭＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＭＮはシンプルＩＰをサポートする移動ノードとして動作している。ｖＰＤＳＮ１はｖＨＡへPMIP BUを送出してvHoA#1を取得し（図１５の（１））、ｈＭＮへ割り当てる（図１５の（２））。続いてＰ−ＣＳＣＦサーバ（ｖＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｖＤＨＣＰ）へ問い合わせを行う（図１５の（３））。これと同時にｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスvHoA#2とvHoA#3を構築する（図１５の（４））。続いてｈＭＮはvHoA#2とvHoA#3の情報をｖＰＤＳＮ１へ伝え、ｖＰＤＳＮ１はこれらのアドレスをｖＨＡへ登録する（図５の（５））。ＳＩＰシグナリングアドレスにはvHoA#1（図１５の（６））、ＳＩＰのメディアアドレスにはvHoA#2、非ＳＩＰ系アプリケーションにはvHoA#3をそれぞれ用いる。
なお、vHoA#2、vHoA#3の生成は、以下で図１６を参照して説明するように、それぞれ、ＳＩＰのメディア、非ＳＩＰ系アプリケーションで用いる前であれば、ＤＨＣＰサーバへの問い合わせと同時に行わなくてもよい。
図１６はケース６のシーケンスを示す。
ｖＰＤＳＮ１はｈＭＮとのセッションを確立すると（LCP/CHAP）、ｖＨＡへPMIP BU（PMIP Binding Update）を送出してvHoA#1を取得し（PMIP Reg./Reply (vHoA#1)）、ｈＭＮへ割り当てる（IPv6CP (vHoA#1 Interface-ID), RA (vHoA Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (vP-CSCF)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスvHoA#2とvHoA#3を構築する。続いてｈＭＮはvHoA#2とvHoA#3の情報をｖＰＤＳＮ１へ伝え、ｖＰＤＳＮ１はこれらのアドレスをｖＨＡへ登録する（PMIP Update (vHoA#2), PMIP Update (vHoA#3)）。vHoA#1はＳＩＰシグナリングアドレス、vHoA#2はＳＩＰのメディア用アドレス、vHoA#3は非ＳＩＰ系アプリケーションに使用される（SIP Registration (vHoA#1), SIP INVITE (SIP Signaling: vHoA#1, Media: vHoA#2), IP data (SIP: vHoA#2, non-SIP: vHoA#3)）。
ｖＰＤＳＮ１はｈＭＮとのセッションを確立すると（LCP/CHAP）、ｖＨＡへPMIP BU（PMIP Binding Update）を送出してvHoA#1を取得し（PMIP Reg./Reply (vHoA#1)）、ｈＭＮへ割り当てる（IPv6CP (vHoA#1 Interface-ID), RA (vHoA Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (vP-CSCF)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスvHoA#2とvHoA#3を構築する。続いてｈＭＮはvHoA#2とvHoA#3の情報をｖＰＤＳＮ１へ伝え、ｖＰＤＳＮ１はこれらのアドレスをｖＨＡへ登録する（PMIP Update (vHoA#2), PMIP Update (vHoA#3)）。vHoA#1はＳＩＰシグナリングアドレス、vHoA#2はＳＩＰのメディア用アドレス、vHoA#3は非ＳＩＰ系アプリケーションに使用される（SIP Registration (vHoA#1), SIP INVITE (SIP Signaling: vHoA#1, Media: vHoA#2), IP data (SIP: vHoA#2, non-SIP: vHoA#3)）。
本ケースではｈＭＮはシンプルＩＰをサポートするが、ＰＭＩＰが訪問先ドメインでサポートされているためハンドオフが可能である。ハンドオフ後はハンドオフ前と同じインタフェースＩＤを用いることで同じＩＰアドレスを構築する。すなわち、ｈＭＮがハンドオフし、ｖＰＤＳＮ２とのセッションを確立すると（LCP/CHAP）、ｖＰＤＳＮ２はｖＨＡへPMIP BU（PMIP Binding Update）を送出してvHoA#1を取得し（PMIP Reg./Reply (vHoA#1)）、ｈＭＮへ割り当てる（IPv6CP (vHoA#1 Interface-ID), RA (vHoA Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (ｈP-CSCF)）。ｈＭＮは取得済みのＩＰｖ６プレフィックスと、ハンドオフ前と同じインタフェースＩＤを用い、アドレスvHoA#2とvHoA#3を構築する。続いてｈＭＮはvHoA#2とvHoA#3の情報をｖＰＤＳＮ２へ伝え、ｖＰＤＳＮ２はこれらのアドレスをｖＨＡへ登録する（PMIP Update (vHoA#2, vHoA#3)）。vHoA#1はＳＩＰシグナリングアドレス、vHoA#2はＳＩＰのメディア用アドレス、vHoA#3は非ＳＩＰ系アプリケーションに使用される（IP data (SIP: vHoA#2, non-SIP: vHoA#3)）。
以上のように、ケース６では、訪問先ドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。すなわち、シームレスなハンドオフがサポートされる。
以上のように、ケース６では、訪問先ドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。すなわち、シームレスなハンドオフがサポートされる。
＜ケース７＞
図１７はケース７（ＭＮ：シンプルＩＰ、ホームドメイン：ＰＭＩＰ、訪問先ドメイン：ＰＭＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＭＮはシンプルＩＰをサポートする移動ノードとして動作している。ｖＰＤＳＮ１はｖＨＡとｈＨＡへPMIP BU（PMIP Binding Update）を送出してvHoA#2とhHoA#1をそれぞれ取得し（図１７の（１）および（１’））、hHoA#1をｈＭＮへ割り当てる（図１７の（２））。また、vHoA#1のプレフィックスも割り当てる。続いてＰ−ＣＳＣＦサーバ（ｈＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｈＤＨＣＰ）へ問い合わせを行う（図１７の（３））。これと同時にｈＭＮは取得済みのvHoA#1と同じＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスvHoA#3とvHoA#4を構築する（図１７の（４））。続いてｈＭＮはvHoA#3とvHoA#4の情報をｖＰＤＳＮ１へ伝え、ｖＰＤＳＮ１はこれらのアドレスをｖＨＡへ登録する（図５の（５））。ＳＩＰシグナリングアドレスにはhHoA#1（図１７の（６））、ＳＩＰのメディアアドレスにはvHoA#3、非ＳＩＰ系アプリケーションにはvHoA#4をそれぞれ用いる。
なお、vHoA#3、vHoA#4の生成は、以下で図１８を参照して説明するように、それぞれ、ＳＩＰのメディア、非ＳＩＰ系アプリケーションで用いる前であれば、ＤＨＣＰサーバへの問い合わせと同時に行わなくてもよい。
なお、vHoA IP#2は使用されない。ＰＭＡ（ＰＤＳＮ）は２つのＨＡにプレフィックスを通知する必要がある。
図１７はケース７（ＭＮ：シンプルＩＰ、ホームドメイン：ＰＭＩＰ、訪問先ドメイン：ＰＭＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＭＮはシンプルＩＰをサポートする移動ノードとして動作している。ｖＰＤＳＮ１はｖＨＡとｈＨＡへPMIP BU（PMIP Binding Update）を送出してvHoA#2とhHoA#1をそれぞれ取得し（図１７の（１）および（１’））、hHoA#1をｈＭＮへ割り当てる（図１７の（２））。また、vHoA#1のプレフィックスも割り当てる。続いてＰ−ＣＳＣＦサーバ（ｈＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｈＤＨＣＰ）へ問い合わせを行う（図１７の（３））。これと同時にｈＭＮは取得済みのvHoA#1と同じＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスvHoA#3とvHoA#4を構築する（図１７の（４））。続いてｈＭＮはvHoA#3とvHoA#4の情報をｖＰＤＳＮ１へ伝え、ｖＰＤＳＮ１はこれらのアドレスをｖＨＡへ登録する（図５の（５））。ＳＩＰシグナリングアドレスにはhHoA#1（図１７の（６））、ＳＩＰのメディアアドレスにはvHoA#3、非ＳＩＰ系アプリケーションにはvHoA#4をそれぞれ用いる。
なお、vHoA#3、vHoA#4の生成は、以下で図１８を参照して説明するように、それぞれ、ＳＩＰのメディア、非ＳＩＰ系アプリケーションで用いる前であれば、ＤＨＣＰサーバへの問い合わせと同時に行わなくてもよい。
なお、vHoA IP#2は使用されない。ＰＭＡ（ＰＤＳＮ）は２つのＨＡにプレフィックスを通知する必要がある。
図１８はケース７のシーケンスを示す。
ｖＰＤＳＮ１はｈＭＮとのセッションを確立すると（LCP/CHAP）、ｖＨＡとｈＨＡへPMIP BUを送出してvHoA#2とhHoA#1をそれぞれ取得し（PMIP Reg./Reply (vHoA#2), PMIP Reg./Reply (hHoA#1)）、hHoA#1をｈＭＮへ割り当てる（IPv6CP (hHoA#1 Interface-ID)）。また、vHoA#1のプレフィックスも割り当てる（RA (hHoA, vHoA Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hP-CSCF)）。ｈＭＮは取得済みのvHoA#1と同じＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスをvHoA#3とvHoA#4構築する。続いてｈＭＮはvHoA#3とvHoA#4の情報をｖＰＤＳＮ１へ伝え、ｖＰＤＳＮ１はこれらのアドレスをｖＨＡへ登録する（PMIP Update (vHoA#3), PMIP Update (vHoA#4)）。
ｖＰＤＳＮ１はｈＭＮとのセッションを確立すると（LCP/CHAP）、ｖＨＡとｈＨＡへPMIP BUを送出してvHoA#2とhHoA#1をそれぞれ取得し（PMIP Reg./Reply (vHoA#2), PMIP Reg./Reply (hHoA#1)）、hHoA#1をｈＭＮへ割り当てる（IPv6CP (hHoA#1 Interface-ID)）。また、vHoA#1のプレフィックスも割り当てる（RA (hHoA, vHoA Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hP-CSCF)）。ｈＭＮは取得済みのvHoA#1と同じＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、アドレスをvHoA#3とvHoA#4構築する。続いてｈＭＮはvHoA#3とvHoA#4の情報をｖＰＤＳＮ１へ伝え、ｖＰＤＳＮ１はこれらのアドレスをｖＨＡへ登録する（PMIP Update (vHoA#3), PMIP Update (vHoA#4)）。
本ケースではｈＭＮはシンプルＩＰをサポートするが、ＰＭＩＰが訪問先ドメインでサポートされているためハンドオフが可能である。ハンドオフ後はハンドオフ前と同じインタフェースＩＤを用いることで同じＩＰアドレスを構築する。すなわち、ｈＭＮがハンドオフし、ｖＰＤＳＮ２とのセッションを確立すると（LCP/CHAP）、ｖＰＤＳＮ２はｖＨＡとｈＨＡへPMIP BUを送出してvHoA#2とhHoA#1をそれぞれ取得し（PMIP Reg./Reply (vHoA#2), PMIP Reg./Reply (hHoA#1)）、hHoA#1をｈＭＮへ割り当てる（IPv6CP (hHoA#1 Interface-ID)）。また、vHoA#1のプレフィックスも割り当てる（RA (hHoA, vHoA Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hP-CSCF)）。ｈＭＮは取得済みのvHoA#1と同じＩＰｖ６プレフィックスと、ハンドオフ前と同じインタフェースＩＤを用い、アドレスvHoA#3とvHoA#4を構築する。続いてｈＭＮはvHoA#3とvHoA#4の情報をｖＰＤＳＮ２へ伝え、ｖＰＤＳＮ２はこれらのアドレスをｖＨＡへ登録する（PMIP Update (vHoA#3, vHoA#4)）。hHoA#1はＳＩＰシグナリングアドレス、vHoA#3はＳＩＰのメディア用アドレス、vHoA#4は非ＳＩＰ系アプリケーションに使用される（IP data (SIP: vHoA#3, non-SIP: vHoA#4)）。
以上のように、ケース７では、訪問先ドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。すなわち、シームレスなハンドオフがサポートされる。
以上のように、ケース７では、訪問先ドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。すなわち、シームレスなハンドオフがサポートされる。
＜ケース８＞
図１９はケース８（ＭＮ：ＣＭＩＰ、ホームドメイン：ＰＭＩＰ、訪問先ドメイン：ＰＭＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＭＮはＣＭＩＰをサポートする移動ノードとしてホームアドレスhHoA#1を保持している、もしくは下位レイヤにて割り当てられている。ｖＰＤＳＮ１はｖＨＡへPMIP BU（PMIP Binding Update）を送出してvHoA#2を取得し（図１９の（１））、ｈＭＮへ割り当てる（図１９の（２））。続いてＰ−ＣＳＣＦサーバ（ｈＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｈＤＨＣＰ）へ問い合わせを行う（図１９の（３））。ｈＭＮはｈＨＡへCMIP BUを送出してvHoA#2を登録する（図１９の（４））。ｈＭＮは取得済みのvHoA#2と同じＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、vHoA#3を構築する（図１９の（５））。ｖＰＤＳＮ１はｖＨＡへPMIP BUを送出してvHoA#3を通知する（図１９の（６））。ＳＩＰシグナリングアドレスにはhHoA#1（図１９の（７））、ＳＩＰのメディアアドレスにはvHoA#2、非ＳＩＰ系アプリケーションにはvHoA#3をそれぞれ用いる。
図１９はケース８（ＭＮ：ＣＭＩＰ、ホームドメイン：ＰＭＩＰ、訪問先ドメイン：ＰＭＩＰ）における移動ノードのＩＰアドレス取得手順を示す。
ｈＭＮはＣＭＩＰをサポートする移動ノードとしてホームアドレスhHoA#1を保持している、もしくは下位レイヤにて割り当てられている。ｖＰＤＳＮ１はｖＨＡへPMIP BU（PMIP Binding Update）を送出してvHoA#2を取得し（図１９の（１））、ｈＭＮへ割り当てる（図１９の（２））。続いてＰ−ＣＳＣＦサーバ（ｈＰ−ＣＳＣＦ）のアドレスを取得するためにｈＭＮはＤＨＣＰサーバ（ｈＤＨＣＰ）へ問い合わせを行う（図１９の（３））。ｈＭＮはｈＨＡへCMIP BUを送出してvHoA#2を登録する（図１９の（４））。ｈＭＮは取得済みのvHoA#2と同じＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、vHoA#3を構築する（図１９の（５））。ｖＰＤＳＮ１はｖＨＡへPMIP BUを送出してvHoA#3を通知する（図１９の（６））。ＳＩＰシグナリングアドレスにはhHoA#1（図１９の（７））、ＳＩＰのメディアアドレスにはvHoA#2、非ＳＩＰ系アプリケーションにはvHoA#3をそれぞれ用いる。
図２０はケース８のシーケンスを示す。
ｖＰＤＳＮ１はｈＭＮとのセッションを確立すると（LCP/CHAP）、ｖＨＡへPMIP BUを送出してvHoA#2を取得し（PMIP Reg./Reply (vHoA#2)）、ｈＭＮへ割り当てる（IPv6CP (vHoA#2 Interface-ID), RA (hHoA, vHoA Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hHA, hP-CSCF)）。ｈＭＮはｈＨＡへCMIP BUを送出してvHoA#2を登録する（CMIP Update (CoA: vHoA#2)）。ｈＭＮは自らインタフェースＩＤを確立するがvHoA#2を取得済みであるので、このインタフェースＩＤは使用しない。ｖＰＤＳＮ１はｖＨＡへPMIP BUを送出してvHoA#2を通知する（PMIP Update (vHoA#2)）。ｈＭＮは取得済みのvHoA#2と同じＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、vHoA#3を構築する。続いてｈＭＮはvHoA#3の情報をｖＰＤＳＮ１へ伝え、ｖＰＤＳＮ１はこのアドレスをｖＨＡへ登録する（PMIP Update (vHoA#3)）。hHoA#1はＳＩＰシグナリングアドレス、vHoA#2はＳＩＰのメディア用アドレス、vHoA#3は非ＳＩＰ系アプリケーションに使用される（SIP Registration (hHoA#1), SIP INVITE (SIP Signaling: hHoA#1, Media: vHoA#2), IP data (SIP: vHoA#2, non-SIP: vHoA#3)）。
ｖＰＤＳＮ１はｈＭＮとのセッションを確立すると（LCP/CHAP）、ｖＨＡへPMIP BUを送出してvHoA#2を取得し（PMIP Reg./Reply (vHoA#2)）、ｈＭＮへ割り当てる（IPv6CP (vHoA#2 Interface-ID), RA (hHoA, vHoA Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hHA, hP-CSCF)）。ｈＭＮはｈＨＡへCMIP BUを送出してvHoA#2を登録する（CMIP Update (CoA: vHoA#2)）。ｈＭＮは自らインタフェースＩＤを確立するがvHoA#2を取得済みであるので、このインタフェースＩＤは使用しない。ｖＰＤＳＮ１はｖＨＡへPMIP BUを送出してvHoA#2を通知する（PMIP Update (vHoA#2)）。ｈＭＮは取得済みのvHoA#2と同じＩＰｖ６プレフィックスと自ら確立したインタフェースＩＤを用い、vHoA#3を構築する。続いてｈＭＮはvHoA#3の情報をｖＰＤＳＮ１へ伝え、ｖＰＤＳＮ１はこのアドレスをｖＨＡへ登録する（PMIP Update (vHoA#3)）。hHoA#1はＳＩＰシグナリングアドレス、vHoA#2はＳＩＰのメディア用アドレス、vHoA#3は非ＳＩＰ系アプリケーションに使用される（SIP Registration (hHoA#1), SIP INVITE (SIP Signaling: hHoA#1, Media: vHoA#2), IP data (SIP: vHoA#2, non-SIP: vHoA#3)）。
本ケースではｖＨＡを用いることにより、ハンドオフが可能である。ハンドオフ後はハンドオフ前と同じインタフェースIDを用いることで同じIPアドレスを構築する。すなわち、ｈＭＮがハンドオフし、ｖＰＤＳＮ２とのセッションを確立すると（LCP/CHAP）、ｖＰＤＳＮ２はｖＨＡへPMIP BUを送出してvHoA#2を取得し（PMIP Reg./Reply (vHoA#2)）、ｈＭＮへ割り当てる（IPv6CP (vHoA#2 Interface-ID), RA (hHoA, vHoA Prefix)）。続いてＰ−ＣＳＣＦサーバのアドレスを取得するためにｈＭＮはＤＨＣＰサーバへ問い合わせを行う（DHCP Inform (hHA, hP-CSCF)）。ｈＭＮは自らインタフェースＩＤを確立するがvHoA#2を取得済みであるので、このインタフェースＩＤは使用しない。ｈＭＮは取得済みのvHoA#2と同じＩＰｖ６プレフィックスと、ハンドオフ前と同じインタフェースＩＤを用い、vHoA#3を構築する。続いてｈＭＮはvHoA#2とvHoA#3の情報をｖＰＤＳＮ２へ伝え、ｖＰＤＳＮ２はこれらのアドレスをｖＨＡへ登録する（PMIP Update (vHoA#2, vHoA#3)）。hHoA#1はＳＩＰシグナリングアドレス、vHoA#2はＳＩＰのメディア用アドレス、vHoA#3は非ＳＩＰ系アプリケーションに使用される（IP data (SIP: vHoA#2, non-SIP: vHoA#3)）。
以上のように、ケース８では、訪問先ドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。すなわち、シームレスなハンドオフがサポートされる。
以上のように、ケース８では、訪問先ドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。すなわち、シームレスなハンドオフがサポートされる。
＜各ケースのまとめ＞
以上から、ケース２、３、６、７、８は、移動ノードのローカルモビリティを実現する。
表３は、以上の異なるケースの詳細を表わす。表３において、「ホームドメイン」の欄は、ホームドメインでのハンドオフ前のＩＰアドレスを表わし、「ホームローカルモビリティ」の欄は、ホームドメインでのハンドオフ後のＩＰアドレスを表わし、「訪問先ドメイン」の欄は、訪問先ドメインでのハンドオフ前のＩＰアドレスを表わし、「訪問先ローカルモビリティ」の欄は、訪問先ドメインでのハンドオフ後のＩＰアドレスを表わす。
以上から、ケース２、３、６、７、８は、移動ノードのローカルモビリティを実現する。
表３は、以上の異なるケースの詳細を表わす。表３において、「ホームドメイン」の欄は、ホームドメインでのハンドオフ前のＩＰアドレスを表わし、「ホームローカルモビリティ」の欄は、ホームドメインでのハンドオフ後のＩＰアドレスを表わし、「訪問先ドメイン」の欄は、訪問先ドメインでのハンドオフ前のＩＰアドレスを表わし、「訪問先ローカルモビリティ」の欄は、訪問先ドメインでのハンドオフ後のＩＰアドレスを表わす。
表３の最上段に記載されたケース４では、図１１、図１２を参照して説明したように、ホームドメイン内でハンドオフすると、ＳＩＰシグナリングアドレスは変わらないが、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わる。
次に、表３の上から２段目に記載されたケース５では、図１３、図１４を参照して説明したように、訪問先ドメイン内でハンドオフすると、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わる。
なお、表２からも分かるように、ケース５とケース１は移動ノードとホームドメインについてのプロトコルが共通であるので、表３のケース５の「ホームドメイン」、「ホームローカルモビリティ」の欄は、ケース１のハンドオフ前後のＩＰアドレスが記載されている。
ケース１では、図５、図６を参照して説明したように、ホームドメイン内でハンドオフすると、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わる。
なお、表２からも分かるように、ケース５とケース１は移動ノードとホームドメインについてのプロトコルが共通であるので、表３のケース５の「ホームドメイン」、「ホームローカルモビリティ」の欄は、ケース１のハンドオフ前後のＩＰアドレスが記載されている。
ケース１では、図５、図６を参照して説明したように、ホームドメイン内でハンドオフすると、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わる。
次に、表３の上から３段目に記載されたケース６では、図１５、図１６を参照して説明したように、訪問先ドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。
なお、表２からも分かるように、ケース６とケース１は移動ノードとホームドメインについてのプロトコルが共通であるので、表３のケース６の「ホームドメイン」、「ホームローカルモビリティ」の欄は、ケース１のハンドオフ前後のＩＰアドレスが記載されている。これについては上述した通りである。
なお、表２からも分かるように、ケース６とケース１は移動ノードとホームドメインについてのプロトコルが共通であるので、表３のケース６の「ホームドメイン」、「ホームローカルモビリティ」の欄は、ケース１のハンドオフ前後のＩＰアドレスが記載されている。これについては上述した通りである。
次に、表３の下から３段目に記載されたケース７では、図１７、図１８を参照して説明したように、訪問先ドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。
なお、表２からも分かるように、ケース７とケース２は移動ノードとホームドメインについてのプロトコルが共通であるので、表３のケース７の「ホームドメイン」、「ホームローカルモビリティ」の欄は、ケース２のハンドオフ前後のＩＰアドレスが記載されている。
ケース２では、図７、図８を参照して説明したように、ホームドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。
なお、表２からも分かるように、ケース７とケース２は移動ノードとホームドメインについてのプロトコルが共通であるので、表３のケース７の「ホームドメイン」、「ホームローカルモビリティ」の欄は、ケース２のハンドオフ前後のＩＰアドレスが記載されている。
ケース２では、図７、図８を参照して説明したように、ホームドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。
次に、表３の下から２段目に記載されたケース８では、図１９、図２０を参照して説明したように、訪問先ドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。
なお、表２からも分かるように、ケース８とケース３は移動ノードとホームドメインについてのプロトコルが共通であるので、表３のケース８の「ホームドメイン」、「ホームローカルモビリティ」の欄は、ケース３のハンドオフ前後のＩＰアドレスが記載されている。
ケース３では、図９、図１０を参照して説明したように、ホームドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。
なお、表２からも分かるように、ケース８とケース３は移動ノードとホームドメインについてのプロトコルが共通であるので、表３のケース８の「ホームドメイン」、「ホームローカルモビリティ」の欄は、ケース３のハンドオフ前後のＩＰアドレスが記載されている。
ケース３では、図９、図１０を参照して説明したように、ホームドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。
次に、表３の最下段に記載されたケース９は説明を省略したが、訪問先ドメイン内でハンドオフしても、ＳＩＰシグナリングアドレス、ＳＩＰのメディア用アドレス、非ＳＩＰ系アプリケーションのアドレスは変わらない。
なお、表２からも分かるように、ケース９とケース３は移動ノードとホームドメインについてのプロトコルが共通であるので、表３のケース９の「ホームドメイン」、「ホームローカルモビリティ」の欄は、ケース３のハンドオフ前後のＩＰアドレスが記載されている。これについては上述した通りである。
なお、表２からも分かるように、ケース９とケース３は移動ノードとホームドメインについてのプロトコルが共通であるので、表３のケース９の「ホームドメイン」、「ホームローカルモビリティ」の欄は、ケース３のハンドオフ前後のＩＰアドレスが記載されている。これについては上述した通りである。
なお、グローバルモビリティに関する課題は次の通りである。
・３種類のグローバルモビリティが存在し得る。
− これについては図２、図３を参照して説明した。
・新たなベアラＩＰアドレスを伝達するプロトコルが必要である。
− それはＡ−ＩＭＳにおけるＳＩＰまたはＣＭＩＰとすることが可能である。
− ＭＭＤの場合、ＰＭＩＰとすることが可能であるが、ＰＭＩＰはホームドメインにおけるホームエージェントへのバインディング更新をサポートしなければならない。
− この場合、訪問先ドメインにおけるＰＭＩＰとホームネットワークにおけるホームエージェントとの間で適切なセキュリティアソシエーションを有する必要がある。
・３種類のグローバルモビリティが存在し得る。
− これについては図２、図３を参照して説明した。
・新たなベアラＩＰアドレスを伝達するプロトコルが必要である。
− それはＡ−ＩＭＳにおけるＳＩＰまたはＣＭＩＰとすることが可能である。
− ＭＭＤの場合、ＰＭＩＰとすることが可能であるが、ＰＭＩＰはホームドメインにおけるホームエージェントへのバインディング更新をサポートしなければならない。
− この場合、訪問先ドメインにおけるＰＭＩＰとホームネットワークにおけるホームエージェントとの間で適切なセキュリティアソシエーションを有する必要がある。
なお、Ａ−ＩＭＳとＩＭＤネットワークとの間の移動に関する課題は次の通りである。
・モビリティインフラのサポートはＡ−ＩＭＳとＩＭＤネットワークとの間で異なり得る。
− ＭＭＤクライアントはＣＭＩＰをサポートしないことがあり得る。
− Ａ−ＩＭＳクライアントはクライアントにＣＭＩＰスタックを常に必要とする。
− ＭＭＤドメインとＡ−ＩＭＳドメインとの間のモビリティを助ける解決策が必要である。
・モビリティインフラのサポートはＡ−ＩＭＳとＩＭＤネットワークとの間で異なり得る。
− ＭＭＤクライアントはＣＭＩＰをサポートしないことがあり得る。
− Ａ−ＩＭＳクライアントはクライアントにＣＭＩＰスタックを常に必要とする。
− ＭＭＤドメインとＡ−ＩＭＳドメインとの間のモビリティを助ける解決策が必要である。
ＨＡ ホームエージェント
ＭＮ 移動ノード
ＰＤＳＮ パケットデータサービングノード
Ｖ−ＢＭ 訪問先ベアラマネージャ
ＭＮ 移動ノード
ＰＤＳＮ パケットデータサービングノード
Ｖ−ＢＭ 訪問先ベアラマネージャ
Claims (8)
- パケットデータサービングノードとのセッションを確立後、同一ドメインのホームエージェントから前記パケットデータサービングノードが取得した第１アドレスを取得するアドレス取得手段と、
前記第１アドレスのプレフィックスと自ら生成した第１および第２インタフェースＩＤを用いて第２および第３アドレスを生成するアドレス生成手段と、
前記生成した第２および第３アドレスを前記パケットデータサービングノードに通知するアドレス通知手段と、
前記第１、第２、第３アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信する通信手段と、
を具備し、
前記アドレス生成手段は、ハンドオフにより同一ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１および第２インタフェースＩＤを用いて第２および第３アドレスを生成する移動ノード。 - 移動ノードとの間でセッションを確立するパケットデータサービングノードであって、
前記移動ノードは、
前記パケットデータサービングノードとのセッションを確立後、同一ドメインのホームエージェントから前記パケットデータサービングノードが取得した第１アドレスを取得するアドレス取得手段と、
前記第１アドレスのプレフィックスと自ら生成した第１および第２インタフェースＩＤを用いて第２および第３アドレスを生成するアドレス生成手段と、
前記生成した第２および第３アドレスを前記パケットデータサービングノードに通知するアドレス通知手段と、
前記第１、第２、第３アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信する通信手段と、
を具備し、
前記アドレス生成手段は、ハンドオフにより同一ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１および第２インタフェースＩＤを用いて第２および第３アドレスを生成し、
前記パケットデータサービングノードは、
前記移動ノードとのセッションを確立後、同一ドメインのホームエージェントから前記第１アドレスを取得して前記移動ノードに割り当てるアドレス割り当て手段と、
前記移動ノードから通知された前記第２および第３アドレスを前記同一ドメインのホームエージェントに登録するアドレス登録手段と、
を具備するパケットデータサービングノード。 - 第１アドレスを保持するアドレス保持手段と、
パケットデータサービングノードとのセッションを確立後、同一ドメインのホームエージェントから前記パケットデータサービングノードが取得した第２アドレスを取得するアドレス取得手段と、
前記取得した第２アドレスを前記同一ドメインのホームエージェントに登録するアドレス登録手段と、
前記第２アドレスのプレフィックスと自ら生成した第１インタフェースＩＤを用いて第３アドレスを生成するアドレス生成手段と、
前記生成した第３アドレスを前記パケットデータサービングノードに通知するアドレス通知手段と、
前記第１、第２、第３アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信する通信手段と、
を具備し、
前記アドレス生成手段は、ハンドオフにより同一ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１インタフェースＩＤを用いて第３アドレスを生成する移動ノード。 - 移動ノードとの間でセッションを確立するパケットデータサービングノードであって、
前記移動ノードは、
第１アドレスを保持するアドレス保持手段と、
前記パケットデータサービングノードとのセッションを確立後、同一ドメインのホームエージェントから前記パケットデータサービングノードが取得した第２アドレスを取得するアドレス取得手段と、
前記取得した第２アドレスを前記同一ドメインのホームエージェントに登録するアドレス登録手段と、
前記第２アドレスのプレフィックスと自ら生成した第１インタフェースＩＤを用いて第３アドレスを生成するアドレス生成手段と、
前記生成した第３アドレスを前記パケットデータサービングノードに通知するアドレス通知手段と、
前記第１、第２、第３アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信する通信手段と、
を具備し、
前記アドレス生成手段は、ハンドオフにより同一ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１インタフェースＩＤを用いて第３アドレスを生成し、
前記パケットデータサービングノードは、
前記移動ノードとのセッションを確立後、同一ドメインのホームエージェントから前記第２アドレスを取得して前記移動ノードに割り当てるアドレス割り当て手段と、
前記移動ノードから通知された前記第３アドレスを前記同一ドメインのホームエージェントに登録するアドレス登録手段と、
を具備するパケットデータサービングノード。 - 訪問先ドメインのパケットデータサービングノードとのセッションを確立後、ホームドメインのホームエージェントから前記パケットデータサービングノードが取得した第１アドレスを取得するアドレス取得手段と、
前記第１アドレスのプレフィックスと自ら生成した第１および第２インタフェースＩＤを用いて第３および第４アドレスを生成するアドレス生成手段と、
前記生成した第３および第４アドレスを前記パケットデータサービングノードに通知するアドレス通知手段と、
前記第１、第３、第４アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信する通信手段と、
を具備し、
前記アドレス生成手段は、ハンドオフにより前記訪問先ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１および第２インタフェースＩＤを用いて第３および第４アドレスを生成する移動ノード。 - 移動ノードとの間でセッションを確立するパケットデータサービングノードであって、
前記移動ノードは、
訪問先ドメインの前記パケットデータサービングノードとのセッションを確立後、ホームドメインのホームエージェントから前記パケットデータサービングノードが取得した第１アドレスを取得するアドレス取得手段と、
前記第１アドレスのプレフィックスと自ら生成した第１および第２インタフェースＩＤを用いて第３および第４アドレスを生成するアドレス生成手段と、
前記生成した第３および第４アドレスを前記パケットデータサービングノードに通知するアドレス通知手段と、
前記第１、第３、第４アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信する通信手段と、
を具備し、
前記アドレス生成手段は、ハンドオフにより前記訪問先ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１および第２インタフェースＩＤを用いて第３および第４アドレスを生成し、
前記パケットデータサービングノードは、
他のドメインをホームドメインとする前記移動ノードとのセッションを確立後、同一ドメインのホームエージェントから第２アドレスを取得するとともに、前記移動ノードのホームドメインのホームエージェントから前記第１アドレスを取得し、前記第１アドレスを前記移動ノードに割り当てるアドレス割り当て手段と、
前記移動ノードから通知された前記第３および第４アドレスを前記同一ドメインのホームエージェントに登録するアドレス登録手段と、
を具備するパケットデータサービングノード。 - 第１アドレスを保持するアドレス保持手段と、
訪問先ドメインのパケットデータサービングノードとのセッションを確立後、前記訪問先ドメインのホームエージェントから前記パケットデータサービングノードが取得した第２アドレスを取得するアドレス取得手段と、
前記第２アドレスをホームドメインのホームエージェントに登録するアドレス登録手段と、
前記第２アドレスのプレフィックスと自ら生成した第１インタフェースＩＤを用いて第３アドレスを生成するアドレス生成手段と、
前記生成した第３アドレスを前記パケットデータサービングノードに通知するアドレス通知手段と、
前記第１、第２、第３アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信する通信手段と、
を具備し、
前記アドレス生成手段は、ハンドオフにより前記訪問先ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１インタフェースＩＤを用いて第３アドレスを生成する移動ノード。 - 移動ノードとの間でセッションを確立するパケットデータサービングノードであって、
前記移動ノードは、
第１アドレスを保持するアドレス保持手段と、
訪問先ドメインの前記パケットデータサービングノードとのセッションを確立後、前記訪問先ドメインのホームエージェントから前記パケットデータサービングノードが取得した第２アドレスを取得するアドレス取得手段と、
前記第２アドレスをホームドメインのホームエージェントに登録するアドレス登録手段と、
前記第２アドレスのプレフィックスと自ら生成した第１インタフェースＩＤを用いて第３アドレスを生成するアドレス生成手段と、
前記生成した第３アドレスを前記パケットデータサービングノードに通知するアドレス通知手段と、
前記第１、第２、第３アドレスを、それぞれＳＩＰシグナリング、ＳＩＰメディア、非ＳＩＰ系アプリケーションのためのアドレスに使用して通信する通信手段と、
を具備し、
前記アドレス生成手段は、ハンドオフにより前記訪問先ドメインの他のパケットデータサービングノードとのセッションを確立すると、ハンドオフ前と同じ第１インタフェースＩＤを用いて第３アドレスを生成し、
前記パケットデータサービングノードは、
他のドメインをホームドメインとする前記移動ノードとのセッションを確立後、同一ドメインのホームエージェントから前記第２アドレスを取得して前記移動ノードに割り当てるアドレス割り当て手段と、
前記移動ノードから通知された前記第３アドレスを前記同一ドメインのホームエージェントに登録するアドレス登録手段と、
を具備するパケットデータサービングノード。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US87676506P | 2006-12-22 | 2006-12-22 | |
| US60/876,765 | 2006-12-22 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2008160791A JP2008160791A (ja) | 2008-07-10 |
| JP4906610B2 true JP4906610B2 (ja) | 2012-03-28 |
Family
ID=39661130
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007173961A Expired - Fee Related JP4906610B2 (ja) | 2006-12-22 | 2007-07-02 | 移動ノードおよびパケットデータサービングノード |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4906610B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9083713B2 (en) * | 2008-12-08 | 2015-07-14 | Qualcomm Incorporated | Apparatus and method for providing mobility to IMS sessions in mobile IP networks |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002290445A (ja) * | 2001-03-28 | 2002-10-04 | Seiko Epson Corp | 通信インタフェース自動切り替え方法および通信インタフェース自動切り替えシステム |
| JP4289030B2 (ja) * | 2002-07-30 | 2009-07-01 | パナソニック株式会社 | 移動管理方法および移動端末 |
-
2007
- 2007-07-02 JP JP2007173961A patent/JP4906610B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2008160791A (ja) | 2008-07-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8625551B2 (en) | Flexible mobility framework for heterogeneous roaming in next generation wireless networks | |
| CN1761359B (zh) | 移动通信控制方法和移动通信控制系统 | |
| US7533160B2 (en) | Provisioning server information in a mobile station | |
| US8792420B2 (en) | Multimedia communication using co-located care of address for bearer traffic | |
| US8363598B2 (en) | Method and apparatus for obtaining server information in a wireless network | |
| US20060176907A1 (en) | Communication equipment, communication control equipment, and communication system | |
| US8885553B2 (en) | Packet routing method, proxy server and apparatus | |
| JP4906610B2 (ja) | 移動ノードおよびパケットデータサービングノード | |
| US20050243840A1 (en) | Method of communication | |
| Thanh et al. | mSCTP-based proxy in support of multimedia session continutity and QoS for IMS-based networks | |
| Chiba et al. | Mobility management schemes for heterogeneity support in next generation wireless networks | |
| JP4725751B2 (ja) | パケット転送システムおよび方法、システムを構成する装置ならびにプログラムと記録媒体 | |
| KR100490130B1 (ko) | 무선 이동통신 네트워크에서 에스아이피 프로토콜 및에스아이피 모빌리티 에이전트 수단을 이용한 이동성 관리방법 및 시스템 | |
| KR100652984B1 (ko) | 계층적 ｓｉｐ 기반의 이동성 관리 시스템 및 방법 | |
| Dutta et al. | A-IMS architecture analysis and experimental IPv6 testbed | |
| Dutta et al. | Multimedia SIP sessions in a mobile heterogeneous access environment | |
| Park et al. | Soft handover mechanism for IPTV service over wireless networks | |
| Kim et al. | mSCTP connection setup method to mobile node using connection setup proxy | |
| Munasinghe et al. | Group mobility management for vehicular area networks roaming between heterogeneous networks | |
| Chiba et al. | Trombone Routing Mitigation |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20100201 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20110629 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110705 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20111003 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20111213 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20120110 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20150120 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4906610 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |