WO2011001628A1

WO2011001628A1 - コネクション管理方法、コネクション管理システム、移動端末、パケットデータゲートウェイ並びに移動管理ゲートウェイ

Info

Publication number: WO2011001628A1
Application number: PCT/JP2010/004164
Authority: WO
Inventors: 隆二杉崎; 池田　新吉; 啓吾阿相; 平野　純
Original assignee: パナソニック株式会社
Priority date: 2009-07-03
Filing date: 2010-06-23
Publication date: 2011-01-06
Also published as: US20120113959A1; JPWO2011001628A1; US8964697B2

Abstract

　複数のＩＰアドレスタイプを用いてパケットの送受信を行っている移動端末が、単一のＩＰアドレスのみパケットの送受信が許可されるアクセスネットワーク（シングルアドレスタイプコネクションネットワーク）にハンドオーバした場合、許可されなかったＩＰアドレスがハンドオーバ先のアクセスネットワークで廃棄されてしまうという問題があった。本発明に係る技術によれば、移動端末（ＵＥ１）が、シングルアドレスタイプコネクションネットワークにハンドオーバしたことを検知し、移動管理ゲートウェイ（ＰＧＷ５）と仮コネクションを確立した後、コアネットワークに存在するｅＰＤＧ８のアドレスを取得し、仮コネクションを用いて、ＰＤＮ経由でｅＰＤＧにＵＥのハンドオーバ前の通信状態を通知する。ｅＰＤＧはＰＧＷにハンドオーバ前のＵＥの通信状態を通知する。これにより、ハンドオーバ前におけるＵＥの通信状態が、ｅＰＤＧとＰＤＮを経由してＰＧＷとの間で確立される。

Description

コネクション管理方法、コネクション管理システム、移動端末、パケットデータゲートウェイ並びに移動管理ゲートウェイ

　本発明は、ＩＰ（Internet Protocol:インターネットプロトコル）を用いた通信を行う通信ノードが複数のアドレスタイプ（例えば、ＩＰｖ４（Internet Protocol version 4）アドレスとＩＰｖ６（Internet Protocol version 6）アドレス）を用いて通信を行う環境において、単一のアドレスタイプしか提供されないネットワークにハンドオーバしたときに、ハンドオーバ前に構築した複数アドレスタイプで通信可能なＰＤＮコネクション（Packet Data Network connection：パケットデータネットワークコネクション）を維持したままハンドオーバするための技術に関する。

　ＩＰネットワークにおけるＵＥの移動透過性を確保する技術として、３ＧＰＰ（Third Generation Partnership Project）アクセスネットワーク上ではＧＴＰ（GPRS Tunneling Protocol）、非３ＧＰＰ（Ｎｏｎ－３ＧＰＰ）アクセスネットワーク上では、ＤＳＭＩＰ（Dual Stack Mobile IP）、また、３ＧＰＰ及びＮｏｎ－３ＧＰＰの両方のアクセスネットワークで使用できるプロトコルとしてＰＭＩＰ（Proxy Mobile IP）が知られている（下記の非特許文献１又は非特許文献２を参照）。

　図１には、ＰＭＩＰを用いた通信ネットワークの構成の一例が図示されている。図１には、ＵＥ１（User Equipment；モバイルノード：Mobile Node（MN）とも呼ばれる）と、ＵＥ１の移動管理を担当するＭＭＥ７（Mobility Management Entity）と、ＵＥ１にデータを電波で送信する基地局（ｅＮＢ（eNode B）：不図示）と、基地局間のユーザデータ経路制御を行うＳＧＷ６（Serving Gateway；ＰＭＩＰにおけるＭＡＧ（Mobility Anchor Gateway）などとも呼ばれる）と、ＵＥ１へのアドレス付与やＳＧＷ６間のユーザデータ経路制御を行うＰＧＷ５（Packet Gateway；ＤＳＭＩＰにおけるホームエージェント（Home Agent：ＨＡ）やＰＭＩＰにおけるＬＭＡ（Local Mobility Anchor）などとも呼ばれる）と、Ｎｏｎ－３ＧＰＰアクセスネットワーク３においてＰＤＮコネクションを確立する機能を持ち、ＵＥ１とパケットの送受信をする際、ＵＥ１との間のパケット保護などを担当するｅＰＤＧ８（evolved Packet Data Gateway）と、ｅＰＤＧ８のＵＲＩ（Universal Resource Identifier）とＩＰアドレスとの組を保持するＤＮＳ（Domain Name System：ドメインネームシステム）サーバ９による構成が図示されている。なお、図１には、ＤＮＳサーバ９の接続形態は明示されていないが、ＤＮＳサーバ９は、コアネットワーク４や各アクセスネットワーク（３ＧＰＰアクセスネットワーク２やＮｏｎ－３ＧＰＰアクセスネットワーク３）からアクセス可能である。

　図１において、ＵＥ１が３ＧＰＰアクセスネットワーク２、コアネットワーク４を通って外部のネットワークと通信を行う際、ＵＥとＰＧＷ間でＰＤＮコネクションを確立する必要がある。ＵＥ１は、ＰＤＮコネクションの確立を通じて、ＰＧＷが割り当てたＩＰｖ４アドレス（ＩＰｖ４ホームアドレス（Home Address）又はＩＰｖ４ＨｏＡなどとも呼ぶ）、あるいはＩＰｖ６プレフィクス（ＩＰｖ６ホームプレフィクス（Home Prefix）などとも呼ぶ）を取得して、外部のネットワークと通信可能なＥＰＳベアラ（Evolved Packet System Bearer）を確立する。ＰＤＮコネクションの確立過程において、ＰＭＩＰが適用される場合は、ＳＧＷ６がプロキシバインディングアップデート（Proxy Binding Update:以降、ＰＢＵと呼ぶ）メッセージを用いて、ＵＥ１が在圏する局所情報（例えばＳＧＷのアドレスなど）をＰＧＷ５に通知することで、ＰＧＷ５は通知されたＵＥ１の在圏情報（以降、位置情報とも呼ぶ）と先に割り当てたＩＰｖ４ホームアドレス又はＩＰｖ６ホームプレフィクスなどとを関連付けたバインディングキャッシュエントリ（Binding Cache Entry：以降、ＢＣＥと呼ぶ）を作成し、バインディングキャッシュ（Binding Cache：以降ＢＣと呼ぶ）に保持する。

　ＰＧＷ５からＩＰｖ６プレフィックスを割り当てられた場合、ＵＥ１は割り当てられたＩＰｖ６プレフィックスからＩＥＴＦ（Internet Engineering Task Force）で規定される手順、すなわちＩＰアドレス自動生成手順などを用いてＩＰｖ６アドレスを生成する。このＩＰｖ６アドレスは、ＩＰｖ６ホームアドレスや、ＩＰｖ６ＨｏＡなどと呼ばれる。ＰＧＷ５は、ＢＣＥを参照して、受信したＵＥ１宛パケットの宛先アドレス（すなわちＩＰｖ４ホームアドレスあるいはＩＰｖ６ホームアドレス）とＢＣＥに登録されているＩＰアドレスを照らし合わせる。その結果、一致するＢＣＥが存在する場合には、ＰＧＷ５はＢＣＥに登録されているＩＰアドレスに対応するＵＥ１の位置情報を取り出し、ＳＧＷ６経由でＵＥ１へパケットを転送する。つまり、接続するネットワークが変わっても、ＳＧＷ６がＵＥ１の現在位置に関するネットワーク情報などをＰＧＷ５に通知し、ＰＧＷ５がＢＣＥを登録（更新）することで、ＵＥ１はネットワークをハンドオーバしてもＵＥ１のＨｏＡ宛てのメッセージを正しく受信することが可能となる。ＳＧＷ６は、一般的にネットワークを管理するオペレータ方針に基づいて定期的に、又はＵＥ１の移動に伴ったハンドオーバ時にＰＢＵメッセージを送信する。

　また、ＵＥ１は異なるＩＰバージョンのＨｏＡを同時に持つことが可能（例えば、ＩＰｖ６ＨｏＡ（あるいはＩＰｖ６プレフィクス）とＩＰｖ４ＨｏＡ）であり、ＵＥ１は各ＨｏＡを用いてパケットの送受信を行うことができる。例えば、ＵＥ１がＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを取得済みで、各ＨｏＡを用いてＰＧＷ５とパケットの送受信が可能な状態であれば、ＵＥ１はＰＧＷ５との間にＩＰｖ４ｖ６ＰＤＮＴｙｐｅ（ＰＤＮタイプ）のＰＤＮコネクションを持つ。若しくは、ＵＥ１はＩＰｖ４ＰＤＮＴｙｐｅのＰＤＮコネクションとＩＰｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを持ち、各ＨｏＡを用いてパケットの送受信を行うことができる。このＵＥ１のＰＤＮコネクションの情報は、ＭＭＥ７やＳＧＷ６が持つＥＰＳベアラコンテキスト（EPS Bearer Context）や、ＰＧＷ５が持つＰ－ＧＷコンテキスト（P-GW Context）に格納されており、これらのコンテキストを基にＵＥ１と各装置間でパケットの送受信が行われる。

　また、ＵＥ１がＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを持ち、パケットの送受信を行っている状態で、ＵＥ１がＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションをサポートしているネットワークにハンドオーバする際、ＥＰＳベアラコンテキストやＰ－ＧＷコンテキストが利用される。これにより、ハンドオーバ後もＵＥ１はＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションが維持され、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡに対応するベアラを用いてパケットの送受信が可能になる。

3GPP TS 23.401 V9.0.0，March 2009 3GPP TS 23.402 V9.0.0，March 2009

　しかしながら、ＵＥが複数のアドレスタイプを用いて外部ネットワークと通信している状態（ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを持ち、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立した状態）で、ＵＥがハンドオーバなどによってネットワークを移動した場合には、移動先のネットワークを管理しているオペレータの方針に基づいて単一のＰＤＮＴｙｐｅ（ＩＰｖ４ＰＤＮＴｙｐｅ又はＩＰｖ６ＰＤＮＴｙｐｅ）しか許可されないケースがある。これは、オペレータ方針による決定以外に、ＩＰｖ６アドレスの概念が存在しなかった世代の３ＧＰＰアクセスネットワーク、つまり、運用上、ＩＰｖ４アドレスのみを使用していた場合や、ＩＰｖ６の運用を開始していない場合なども上記ケースに含まれる。また、グローバルアドレスを前提とするサービスを提供するオペレータにおいては、ＩＰｖ４ではなくＩＰｖ６のみサポートする場合も考えられる。そのため、ハンドオーバ前では、ＵＥはＰＤＮコネクション内にＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信できる通信経路が存在している場合でも、例えばハンドオーバ先のネットワークがＩＰｖ６ＰＤＮＴｙｐｅしか許可していない場合（このようなネットワークを、シングルアドレスタイプコネクション対応ネットワーク、シングルアドレスタイプコネクションネットワーク、シングルアドレスタイプネットワークとも呼ぶ）には、ハンドオーバ処理の過程で、ＰＤＮコネクションのアドレスタイプがネットワーク側でＩＰｖ４ｖ６ＰＤＮＴｙｐｅからＩＰｖ６ＰＤＮＴｙｐｅに変更され、ＩＰｖ４ＨｏＡを用いたパケットの送受信ができなくなってしまう。

　さらに、このとき、ＵＥがハンドオーバ前に取得したＩＰｖ４ＨｏＡの情報も各装置が持つコンテキストから削除されてしまう。そのため、再びマルチアドレスタイプコネクション対応ネットワーク（例えばＩＰｖ４ｖ６ＰＤＮＴｙｐｅを確立可能なネットワーク、このようなネットワークを、マルチアドレスタイプコネクションネットワーク、マルチアドレスコネクションネットワークとも呼ぶ）にハンドオーバした際に、ＵＥは改めてＩＰｖ４ＨｏＡを取得し、取得したＩＰｖ４ＨｏＡを用いてパケットを送受信できる通信経路（ＥＰＳベアラあるいはＰＤＮコネクション）を確立しなければならない。

　なお、ここで、このＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを持ち、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを保持しているＵＥが、シングルアドレスタイプコネクション対応ネットワークにハンドオーバし、ＩＰｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションがオペレータ方針によって割り当てられるときに生じる問題を解決する方法が考えられる。つまり、ＩＰｖ６ＨｏＡを用いた通信とは別に、ＩＰｖ４ＨｏＡを用いたパケットの送受信をシングルアドレスタイプコネクション対応ネットワークにハンドオーバした後でも実現可能にする方法が考えられる。

　すなわち、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを持つＵＥがシングルアドレスタイプコネクションのみ対応ネットワークにハンドオーバした際、ＩＰｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションに変更されたことを検知する。続いて、ＩＰｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションとは別に、新しくＩＰｖ４ＰＤＮＴｙｐｅのＰＤＮコネクションの確立リクエストをＰＧＷに送る。ＰＤＮコネクションの確立後、ＩＰｖ４ＨｏＡを用いたパケットの送受信を可能にするものである。

　しかしながら、上記の方法では、ＵＥによってリクエストされたＩＰｖ４ＰＤＮＴｙｐｅのＰＤＮコネクションは、ＰＧＷを管理するオペレータ方針によって拒否される可能性があり、ハンドオーバ前のＩＰｖ４ＨｏＡを用いたパケットの送受信ができるとは限らないといった問題がある。

　なお、本明細書では、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを持つＵＥが、シングルアドレスタイプコネクション対応ネットワークにハンドオーバした際、ネットワーク側でＩＰｖ４ＨｏＡが放棄され、ＩＰｖ６ＨｏＡのみが維持される場合、つまり、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅからＩＰｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションに変更される場合を前提としているが、オペレータ方針などによってはＩＰｖ６ＨｏＡではなくＩＰｖ４ＨｏＡが維持される場合もある。このような場合には、ＩＰｖ４のＨｏＡではなくＩＰｖ６のＨｏＡが廃棄され、結果としてＩＰｖ４ｖ６ＰＤＮＴｙｐｅからＩＰｖ４ＰＤＮＴｙｐｅのＰＤＮコネクションに変更される場合もある。

　上記問題に鑑み、本発明では、ＵＥがＰＧＷとＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立済みで、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信を行っている状態で、ＵＥがシングルアドレスタイプコネクション対応ネットワークにハンドオーバした場合であっても、ＵＥが持つＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを維持し、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信ができるようにすることを目的とする。また、ＵＥが持つＩＰアドレス（ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡ）に関する情報をネットワーク側の各装置が保持し続けることで、再度ハンドオーバする場合であっても、特別な処理を必要とせずに、これらのアドレスを用いた通信セッションを維持できることを目的とする。

　上記目的を達成するため、本発明のコネクション管理方法は、複数のＩＰアドレスを用いて複数のパケットデータコネクションを確立可能な移動端末と、前記移動端末とパケットデータコネクションを確立するパケットデータゲートウェイと、前記移動端末とのパケット送受信に関するコネクション情報を管理する移動管理ゲートウェイからなる通信システムにおいて、前記移動端末が、複数のＩＰアドレスタイプを用いたパケット交換コネクションを確立可能なマルチアドレスタイプコネクションネットワークから、単一のＩＰアドレスタイプによる通信経路のみ確立可能なシングルアドレスタイプコネクションネットワークへハンドオーバする際のコネクション管理方法であって、
　前記移動端末が、前記マルチアドレスタイプコネクションネットワークから前記シングルアドレスタイプコネクションネットワークへハンドオーバしたことを検知する検知ステップと、
　前記移動端末が、前記検知ステップの結果に基づき、ハンドオーバ前の通信状態を維持するために仮のコネクションを前記移動管理ゲートウェイと確立する仮コネクション確立ステップと、
　前記移動端末が、前記仮コネクション確立ステップの後、前記仮のコネクションを用いて前記パケットデータゲートウェイにハンドオーバ前のパケットデータコネクションを維持するリクエストを送信するパケットゲートウェイへのリクエスト送信ステップと、
　前記リクエストを受信したパケットデータゲートウェイが、前記受信したリクエストを前記移動管理ゲートウェイに送信するか判断し、送信するリクエストだと判断した場合は前記移動管理ゲートウェイに前記受信したリクエストを送信する移動管理ゲートウェイへのリクエスト送信ステップと、
　前記移動管理ゲートウェイが、前記リクエストに含まれる情報を基に、前記移動端末とのパケット送受信に関するコネクション情報を修正する修正ステップとを、
　有する。
　この構成により、移動端末が、マルチアドレスタイプコネクション対応ネットワークからシングルアドレスタイプコネクション対応ネットワークにハンドオーバした場合であっても、マルチアドレスタイプコネクション対応ネットワークで利用していたコネクションがハンドオーバ後においても維持されるようになる。

　また、上記目的を達成するため、本発明のコネクション管理システムは、複数のＩＰアドレスを用いて複数のパケットデータコネクションを確立可能な移動端末と、前記移動端末とパケットデータコネクションを確立するパケットデータゲートウェイと、前記移動端末とのパケット送受信に関するコネクション情報を管理する移動管理ゲートウェイからなるコネクション管理システムであって、
　前記移動端末は、
　前記移動端末が、複数のＩＰアドレスタイプを用いたパケット交換コネクションを確立可能なマルチアドレスタイプコネクションネットワークから、単一のＩＰアドレスタイプによる通信経路のみ確立可能なシングルアドレスタイプコネクションネットワークへハンドオーバしたことを検知する検知手段と、
　前記移動端末が、前記検知手段の結果に基づき、ハンドオーバ前の通信状態を維持するために仮のコネクションを前記移動管理ゲートウェイと確立する仮コネクション確立手段と、
　前記移動端末が、前記仮コネクション確立後、前記仮コネクションを用いて前記パケットデータゲートウェイにハンドオーバ前のパケットデータコネクションを維持するリクエストを送信するパケットゲートウェイへのリクエスト送信手段と、
　を含み、
　前記パケットデータゲートウェイは、
　前記移動端末が送信したリクエストを受信する受信手段と、
　前記受信したリクエストを前記移動管理ゲートウェイに送信するか否かを判断する判断手段と、
　前記判断手段により送信すると判断した場合には、前記移動管理ゲートウェイに前記受信したリクエストを送信する移動管理ゲートウェイへの送信手段と、
　を含み、
　前記前記移動管理ゲートウェイは、
　前記パケットゲートウェイから送信されたリクエストを受信する受信手段と、
　前記受信したリクエストに含まれる情報を基に、前記移動端末とのパケット送受信に関するコネクション情報を修正する修正手段とを、
　有する。
　この構成により、移動端末が、マルチアドレスタイプコネクション対応ネットワークからシングルアドレスタイプコネクション対応ネットワークにハンドオーバした場合であっても、マルチアドレスタイプコネクション対応ネットワークで利用していたコネクションがハンドオーバ後においても維持されるようになる。

　また、上記目的を達成するため、本発明の移動端末は、複数のＩＰアドレスを用いて複数のパケットデータコネクションを確立可能な移動端末であって、
　複数のＩＰアドレスタイプを用いたパケット交換コネクションを確立可能なマルチアドレスタイプコネクションネットワークから、単一のＩＰアドレスタイプによる通信経路のみ確立可能なシングルアドレスタイプコネクションネットワークへハンドオーバしたことを検知する検知手段と、
　前記検知手段の結果に基づき、ハンドオーバ前の通信状態を維持するために仮のコネクションを、前記移動端末とのパケット送受信に関するコネクション情報を管理する移動管理ゲートウェイと確立する仮コネクション確立手段と、
　前記仮コネクション確立後、前記仮コネクションを用いて前記移動端末とパケットデータコネクションを確立するパケットデータゲートウェイに対し、ハンドオーバ前のパケットデータコネクションを維持するリクエストを送信するパケットゲートウェイへのリクエスト送信手段とを、
　有する。
　この構成により、移動端末が、マルチアドレスタイプコネクション対応ネットワークからシングルアドレスタイプコネクション対応ネットワークにハンドオーバした場合であっても、マルチアドレスタイプコネクション対応ネットワークで利用していたコネクションがハンドオーバ後においても維持されるようになる。

　また、上記目的を達成するため、本発明のパケットデータゲートウェイは、複数のＩＰアドレスを用いて複数のパケットデータコネクションを確立可能な移動端末とパケットデータコネクションを確立するパケットデータゲートウェイであって、
　前記移動端末が送信したリクエストを受信する受信手段と、
　前記受信したリクエストを前記移動端末とのパケット送受信に関するコネクション情報を管理する前記移動管理ゲートウェイに送信するか否かを判断する判断手段と、
　前記判断手段により送信すると判断した場合には、前記移動管理ゲートウェイに前記受信したリクエストを送信する移動管理ゲートウェイへの送信手段とを、
　有する。
　この構成により、移動端末が、マルチアドレスタイプコネクション対応ネットワークからシングルアドレスタイプコネクション対応ネットワークにハンドオーバした場合であっても、マルチアドレスタイプコネクション対応ネットワークで利用していたコネクションがハンドオーバ後においても維持されるようになる。

　また、上記目的を達成するため、本発明の移動管理ゲートウェイは、複数のＩＰアドレスを用いて複数のパケットデータコネクションを確立可能な移動端末とのパケット送受信に関するコネクション情報を管理する移動管理ゲートウェイであって、
　前記移動端末とパケットデータコネクションを確立するパケットゲートウェイから送信されたリクエストを受信する受信手段と、
　前記受信したリクエストに含まれる情報を基に、前記移動端末とのパケット送受信に関するコネクション情報を修正する修正手段とを、
　有する。
　この構成により、移動端末が、マルチアドレスタイプコネクション対応ネットワークからシングルアドレスタイプコネクション対応ネットワークにハンドオーバした場合であっても、マルチアドレスタイプコネクション対応ネットワークで利用していたコネクションがハンドオーバ後においても維持されるようになる。

　本発明によれば、ＵＥがＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを持ち、複数のアドレス（例えば、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡ）を使用して外部ネットワークと通信している状態で、シングルアドレスタイプコネクション対応のネットワークにハンドオーバした場合でも、ＵＥは、ハンドオーバ前の通信状態をマッピングするために仮のＰＤＮコネクションをＰＧＷと確立し、その後、確立した仮のＰＤＮコネクションを用いて、ＰＤＮと、コアネットワークに存在するｅＰＤＧを経由してＰＧＷにPDN connection request procedureを実施することで、ＰＧＷから割り当てられた単一のＩＰバージョン以外のＩＰバージョンを用いたＰＤＮコネクションを確立することができる。つまり、ＵＥはシングルアドレスタイプコネクション対応ネットワークにハンドオーバした場合でも、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立することができる。その結果、ＵＥはハンドオーバ前に保持していたＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡをハンドオーバ後でも維持し、各ＨｏＡを用いたパケットの送受信を行うことが可能となる。

　また、ＵＥは、シングルアドレスタイプコネクション対応ネットワークにハンドオーバ後でも、ハンドオーバ前に保持していたＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡの維持が可能となるため、改めてハンドオーバする際も、新しく処理を必要とせずにハンドオーバ前から使用していた各ＨｏＡを使用し続けることが可能となる。

本発明の第１～第４の実施の形態並びに従来の技術に共通する通信システムの構成の一例を示す図本発明の第１の実施の形態におけるシングルアドレスタイプネットワークにおけるマルチアドレスコネクション確立手法の動作の一例を説明するためのシーケンスチャート本発明の第１～第４の実施の形態における移動端末（ＵＥ）の構成の一例を示す図本発明の第１～第４の実施の形態におけるＰＧＷの構成の一例を示す図本発明の第１～第４の実施の形態におけるＳＧＷの構成の一例を示す図本発明の第１～第４の実施の形態におけるｅＰＤＧの構成の一例を示す図本発明の第２の実施の形態におけるシングルアドレスタイプネットワークにおけるマルチアドレスコネクション確立手法の動作の一例を説明するためのシーケンスチャート本発明の第１の実施の形態において、移動端末（ＵＥ）がＭＭＥに送信するＰＤＮコネクションリクエストであるPDN Connectivity Requestメッセージのフォーマット例を示す図本発明の第２の実施の形態において、移動端末（ＵＥ）がターゲットＲＮＣに送信するHandover to UTRAN Completeメッセージのフォーマット例を示す図本発明の第２の実施の形態において、ターゲットＲＮＣがターゲットＳＧＳＮに送信するRelocation Completeメッセージのフォーマット例を示す図本発明の第２の実施の形態において、ターゲットＳＧＳＮがターゲットＳＧＷに送信するUpdate Bearer Completeメッセージのフォーマット例を示す図本発明の第１の実施の形態における移動端末（ＵＥ）の処理フローの一例を示すフローチャート本発明の第２の実施の形態に関連するＩｎｔｅｒＲＡＴハンドオーバ（Execution phase）技術における動作の一例を説明するためのシーケンスチャート本発明の第１の実施の形態におけるＰＧＷの処理フローの一例を示すフローチャート本発明の第３の実施の形態におけるシングルアドレスタイプネットワークにおけるマルチアドレスコネクション確立手法の動作の一例を説明するためのシーケンスチャート本発明の第３及び第４の実施の形態において、ＵＥがｅＰＤＧに送信するIKEv2 Authentication and Tunnel Setupメッセージのフォーマット例を示す図本発明の第３及び第４の実施の形態において、ｅＰＤＧがＰＧＷに送信するＰＢＵメッセージのフォーマット例を示す図本発明の第１の実施の形態におけるｅＰＤＧの処理フローの一例を示すフローチャート本発明の第３及び第４の実施の形態におけるｅＰＤＧの処理フローの一例を示すフローチャート本発明の第３の実施の形態における移動端末（ＵＥ）の処理フローの一例を示すフローチャート本発明の第４の実施の形態におけるシングルアドレスタイプコネクションのみ対応ネットワークにおけるマルチアドレスタイプコネクション確立手法の動作の一例を説明するためのシーケンスチャート本発明の第４の実施の形態における移動端末（ＵＥ）の処理フローの一例を示すフローチャート本発明の第３及び第４の実施の形態におけるＰＧＷの処理フローの一例を示すフローチャート

　以下、図面を参照しながら、本発明の第１～第４の実施の形態について説明する。まず、図１を参照しながら、本発明の第１～第４の実施の形態に共通するシステム構成について説明する。図１は、本発明の第１～第４の実施の形態に関するシステム構成の一例を示す図である。図１に図示されている通信システムは、少なくともＵＥ１、ＵＥ１が接続するコアネットワーク４、ＵＥ１のホームプレフィクスやホームアドレス、位置情報などを管理しているＰＧＷ５、ＵＥ１の移動管理を担当しているＭＭＥ７、ＵＥ１にデータを電波で送信する基地局（ｅＮｏｄｅＢとも呼ばれる、不図示）を統括するＳＧＷ６、Ｕｎｔｒｕｓｔｅｄ（信頼性の無い）Ｎｏｎ－３ＧＰＰアクセスネットワーク３上でＵＥ１へデータを送信する際、パケット保護をするためにＵＥ１とＳＡ（Security Association：セキュリティアソシエーション）を確立するｅＰＤＧ８、ＵＥ１からの要求に応じてｅＰＤＧ８のアドレスを提供するＤＮＳサーバ９、３ＧＰＰアクセスネットワーク２（以降、３Ｇアクセス２と呼ぶ）、Ｎｏｎ－３ＧＰＰアクセスネットワーク３（以降、Ｎ３Ｇアクセス３と呼ぶ）を有している。

　ＵＥ１は、少なくとも１つ以上の通信インタフェースを持ち、ＩＰｖ４とＩＰｖ６に対応しており、各ＩＰを使い分けし、３Ｇアクセス２／Ｎ３Ｇアクセス３を介してＰＧＷ５と両ＩＰバージョンに対応したＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立することができる。また、本来ｅＰＤＧ８は、ＵＥ１がＵｎｔｒｕｓｔｅｄＮ３Ｇアクセス３で通信する際に、パケットの保護を目的としたＳＡを確立するために必要な装置であるが、コアネットワークを経由することで３Ｇアクセス２からパケットを保護した通信を行うことも可能である。

　また、３Ｇアクセス２には、例えば、ＳＧＳＮやＧＧＳＮなどの３ＧＰＰシステムに固有の装置が配備されており、ＵＥ１がＰＧＷ５に接続するための機能をサポートしているが、図１では図示省略する。また、Ｎ３Ｇアクセス３においても、ＵＥ１がＰＧＷ５に接続するために必要となる機能をサポートする通信ノード（ＡＲ（Access Router：アクセスルータ）やＭＡＧなど）が配備されているが、これらの通信ノードも図１では図示省略する。

　上記の構成を有する通信システムにおいて、ＵＥ１はＰＭＩＰを用いて３Ｇアクセス２を介してＰＧＷとＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションが確立済みであり、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信を行っているものとする。なお、ＵＥ１の接続はＰＭＩＰに限定されるものではなく、例えばＧＴＰなどを用いて３Ｇアクセス２に接続されていてもよい。

　＜第１の実施の形態＞
　以下、本発明の第１の実施の形態におけるシステム動作の一例について、図２を用いて詳しく説明する。図２は、本発明の第１の実施の形態におけるシステム動作の一例を説明するためのシーケンス図である。図２には、少なくともＵＥ１、ＵＥ１と直接的にパケットの送受信を行うｅＮｏｄｅＢ（以降、ｅＮＢと呼ぶ）、ＵＥ１の移動管理を担当するＭＭＥ７、ｅＮＢを統括するＳＧＷ６、ＳＧＷ６を統括しＰＤＮへのゲートウェイの役割を担い、ＵＥ１の位置情報を管理するＰＧＷ５、ＵｎｔｒｕｓｔｅｄＮ３Ｇアクセス３におけるＰＤＮコネクションを確立する機能を持つ構成要素であるｅＰＤＧ８、ＵＥ１の課金コントロールなどを管理しているＰＣＲＦ（Policy Charging Rules Function）、ＵＥ１のサブスクリプション情報などを保持管理するＨＳＳ（Home Subscriber Server）による処理シーケンスの一例が図示されている。なお、各機能を代わりに担うことができる構成要素が存在する場合には、それらを用いてもよい。

　また、図２では、ＵＥはＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを持ち、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡ宛てのパケットを送受信可能な状態で、シングルアドレスコネクションにのみ対応するネットワーク（シングルアドレスタイプネットワーク）にハンドオーバした結果、ＩＰｖ６ＰＤＮＴｙｐｅが割り当てられることを想定している。

　図２には、ハンドオーバ前に取得したＩＰｖ４ＨｏＡを維持すると同時に、ＩＰｖ４ＨｏＡ宛てのパケットを送受信可能にするためのシーケンスが図示されている。ＵＥ１が、ｅＮＢのカバーするパケット転送エリアから超えそうになる場合、又は、オペレータ方針に基づいて異なるネットワークをＵＥ１に割り当てる場合などにおいて、現在ＵＥ１が接続されているｅＮＢが、ハンドオーバ先のアクセスネットワークに対してハンドオーバ処理を開始する（上記の非特許文献１を参照）。

　ＵＥ１は、ハンドオーバ前にＰＧＷ５とＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立しており、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信が可能であるが、シングルアドレスタイプネットワークにハンドオーバした結果、ハンドオーバ先のネットワークのオペレータ方針に基づいてＰＤＮＴｙｐｅがＩＰｖ４ｖ６ＰＤＮＴｙｐｅからＩＰｖ６ＰＤＮＴｙｐｅに変更される。つまり、ＵＥ１がハンドオーバ前に使用していたＩＰｖ４ＨｏＡ宛てのパケットがネットワーク側で放棄され、ＩＰｖ４ＨｏＡ宛てのパケットが転送されなくなる。また、ＵＥ１はＩＰｖ４ＨｏＡをソースアドレスとしたパケットをネットワーク側に送信できなくなる（ステップＳ１０１：Inter RATハンドオーバ）。

　なお、第１の実施の形態では、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションがＩＰｖ６ＰＤＮＴｙｐｅに変更され、ＩＰｖ４ＨｏＡ宛てのパケットが放棄される場合について説明するが、オペレータ方針によってはＩＰｖ４ＰＤＮＴｙｐｅに変更され、ＩＰｖ６ＨｏＡ宛てのパケットが放棄される場合も考えられる。このような場合においても、本発明は適用可能であり、本実施の形態において説明する方法と同様の方法により、所望の目的を達することができる。

　ステップＳ１０１でハンドオーバ（例えばＩｎｔｅｒＲＡＴ（Radio Access Technology）ハンドオーバ）した後、ＰＤＮＴｙｐｅが変更されたことを検知したＵＥ１は、ハンドオーバ前に使用していたＩＰｖ４ＨｏＡ宛てのパケットを受信するため（ＩＰｖ４ＨｏＡに対応するベアラを放棄しないため）の処理を実施するために、例えばＤＮＳサーバ９にｅＰＤＧ８のアドレスを問い合わせる（ステップＳ１０２：ePDG Discovery）。なお、ここでは、ＵＥ１はｅＰＤＧのアドレスを取得するためにＤＮＳサーバ９に問い合わせているが、ＵＥ１がＮ３Ｇアクセス３に接続していたときにｅＰＤＧ８のアドレスを記憶しておき、そのアドレス情報を再利用などしてもよい。

　続いて、ＵＥ１は、前記ステップＳ１０２で取得したｅＰＤＧ８のアドレスに対応するｅＰＤＧ８を介してＵＥ１とＰＧＷ５間でＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立する。ＵＥ１は、従来のUE_Requested_PDN_Connectivity_Procedure（上記の非特許文献１又は非特許文献２を参照）で用いるメッセージのＩＰヘッダにある宛て先アドレス（Destination address）をｅＰＤＧ８にして、手順を実施する（ステップＳ１０３：PDN Connectivity Request）。なお、UE_Requested_PDN_Connectivity_ProcedureのメッセージがｅＰＤＧ８に届くのであれば、ＩＰヘッダ以外の箇所にｅＰＤＧ８のアドレスを格納してもよい。

　なお、ｅＰＤＧ８を用いる理由は、ＵＥ１はｅＰＤＧ８を介してＰＧＷ５にＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立するためのリクエストメッセージを送信することで、ＵＥ１はハンドオーバ（ＨＯ）先ネットワークのオペレータ方針（例えば、ＩＰｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションのみ対応など）に依存せず、ＰＤＮコネクションを確立することができるためである。ここで、ＵＥ１からｅＰＤＧ８へリクエストを送信する理由は、ｅＰＤＧ８はＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立する機能を有するため、新規機能の追加が最小限で済むからである。なお、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立する機能を有する構成要素であれば、ｅＰＤＧの代わりとして使用してもよい。

　図８は、図２のステップＳ１０３においてＵＥ１がＭＭＥ７に送るPDN Connectivity Requestメッセージの一例を示す図である。ＵＥ１は、従来の標準的なPDN Connectivity Requestメッセージ１００１に加えて、Renew Indicationフィールド１００２、IP Addressフィールド１００３、Bearer IDフィールド１００４を設け、それぞれ所定の値をＭＭＥ７に通知することができる。また、標準的なPDN Connectivity Requestメッセージで規定されるＰＣＯ（Protocol Configuration Options）に各情報を付加してＭＭＥ７に通知してもよい。なお、本メッセージは、所定の情報を転送できるものであればPDN Connectivity Requestメッセージ以外のメッセージであってもよい。

　このとき、ＵＥ１はPDN Connectivity RequestメッセージのPDN TypeパラメータにIPv4v6 PDN Type、Request Typeにhandover（ハンドオーバ）、Renew Indicationフィールド１００２にＰＧＷが持つＥＰＳベアラコンテキストを更新することを示すRenew Indication値、IP Addressフィールド１００３にハンドオーバ後に割り当てられなかったＩＰｖ４ＨｏＡ、維持し続けたいベアラがある場合には、Bearer IDフィールド１００４にそのベアラに対応するBearer IDをセットする。なお、PDN TypeパラメータにＩＰｖ４ｖ６を格納して通知するだけで、ハンドオーバ前に使用していたＩＰｖ４ＨｏＡが維持でき、ＩＰｖ４ＨｏＡ宛てのパケットを送受信できるようであれば、追加したパラメータを送信する必要はない。また、他のパラメータも同様である。

　続いて、前記ステップＳ１０３でＵＥ１から送られてきたPDN Connectivity Requestメッセージを受信したＭＭＥ７は、従来通り（上記の非特許文献１を参照）の処理を施す。たとえば、前記PDN Connectivity Requestメッセージに格納されているPDN TypeからDual Address Bearer Flagをセットするなどの処理を施す。その後、ＭＭＥ７は、処理した結果を含むCreate Default Bearer RequestメッセージをＳＧＷ６に送信する（ステップＳ１０４：Create Default Bearer Request）。

　Create Default Bearer Requestメッセージを受信したＳＧＷ６は、ＰＣＲＦとの間で、一般的なUE requested PDN connectivity procedureと同様に、Gateway Control Session Establishment Procedureを実施する（ステップＳ１０５：Gateway Control Session Establishment Procedure）（上記の非特許文献２を参照）。

　このステップＳ１０５におけるGateway Control Session Establishment Procedure完了後、ＵＥのＩＰアドレスが入手できなかった場合、図２の（Ａ）（ステップＳ１０６～ステップＳ１１１）を実施する。また、図２の（Ａ）（ステップＳ１０６～ステップＳ１１１）を実施する際は、図２の（Ｂ）を実施しない。また、Gateway Control Session Establishment Procedureを実施した結果、ＳＧＷがＵＥのＩＰアドレスを取得できた場合、ＳＧＷは図２の（Ａ）（ステップＳ１０６～ステップＳ１１１）を実施せずに、図２の（Ｂ）を実施する。

　なお、ＵＥ１がホームネットワーク外にいて、ＵＥ１がアクセスするＳＧＷ６がホームネットワークのＰＣＲＦ（ｈＰＣＲＦ（home PCRF）と呼ばれることもある）と直接アクセスできない場合には、移動先のネットワークにあるＰＣＲＦ（ｖＰＣＲＦ（visited PCRF）と呼ばれることもある）を中継して、ｈＰＣＲＦとGateway Control Session Establishment Procedureを実施する。

　続いて、ＳＧＷ６は前記ステップＳ１０４でＭＭＥ７から送られてきたCreate Default Bearer Requestメッセージで指示されたｅＰＤＧ８にProxy Binding Update（以降、ＰＢＵと呼ぶ）メッセージを送信する。このとき、Create Default Bearer Requestメッセージに格納されていたPDN Type、Request Type、Bearer ID、EPS Bearer Context Renew Indicationフラグも一緒にｅＰＤＧに送信する（ステップＳ１０６：Proxy Binding Update）。なお、所定の情報を転送できるものであればＰＢＵメッセージ以外のメッセージであってもよい。

　ＰＢＵメッセージを受信したｅＰＤＧ８は、特別な処理を実施せずに、前記ＰＢＵメッセージで指定されたＰＧＷ５へ転送する（ステップＳ１０７：Proxy Binding Update ePDG）。ＰＢＵメッセージを受信したＰＧＷ５は、ＰＢＵメッセージに格納されていたPDN Typeなどの情報を基に、ＰＧＷ５自身が持つＥＰＳベアラコンテキストの中身を更新する。ＥＰＳベアラコンテキストを更新した結果、ＵＥ１がハンドオーバ前に保持していたＩＰｖ４ＨｏＡがＥＰＳベアラコンテキストに登録され、ハンドオーバ前に使用していたＩＰｖ４ＨｏＡを維持することが可能となる。なお、ＰＢＵメッセージにBearer IDが格納されていた場合は、ＩＰｖ４ＨｏＡの処理と同様に、ＰＧＷ５が持つＥＰＳベアラコンテキストに登録され、Bearer IDに対応するハンドオーバ前に使用していたベアラを維持することが可能となる。

　ＥＰＳベアラコンテキストの更新後、ＰＧＷ５は、ＵＥ１から送られてきたＰＤＮコネクション確立リクエストが、既にＵＥ１がコネクション確立済みのＰＤＮ（ＡＰＮ（Access Point Name））であるかを確認し、コネクション確立済みではないＰＤＮの場合には、ＰＧＷ５はIP-CAN Session Establishment ProcedureをＰＣＲＦと実施する（ステップＳ１０８：IP-CAN Session Establishment Procedure）。なお、この場合には、次ステップ（ステップＳ１０９）のPCEF-Initiated IP-CAN Session Modification Procedureは実施しない。

　一方、ＵＥ１が既にＰＤＮコネクションが確立済みであるＰＤＮ（ＡＰＮ）の場合には、ステップＳ１０８のIP-CAN Session Establishment Procedureは実施せずに、PCEF-Initiated IP-CAN Session Modification ProcedureをＰＣＥＦと実施する（ステップＳ１０９：PCEF-Initiated IP-CAN Session Modification Procedure）。

　続いて、ＰＧＷ５はｅＰＤＧ８にProxy Binding Ack（以降、ＰＢＡと呼ぶ）メッセージを返信する。このＡＣＫは、Create Default Bearer Responseメッセージのパラメータ（PDN Type、EPS Bearer IDなど）を含む（ステップＳ１１０：Proxy Binding Ack ePDG）。ステップＳ１１０のProxy Binding Ackを受信したｅＰＤＧ８は、特別な処理を実施せずに、前記ＰＢＡメッセージで指定されたＳＧＷ６に転送する（ステップＳ１１１：Proxy Binding Ack）。前記ＰＢＡメッセージを受信したＳＧＷ６は、前記ＰＢＡメッセージ内に格納されているPDN Typeなどの情報を含めたCreate Default Bearer ResponseメッセージをＭＭＥ７に送信する（ステップＳ１１２：Create Default Bearer Response）。なお、以降の処理（図２に図示されている各シーケンス）は従来の方法と同じであり、説明は省略する（詳細は、上記の非特許文献１と非特許文献２を参照）。

　次に、本発明を実施するための移動端末（ＵＥ１）の構成について説明する。以下、図３を参照しながら、本発明の第１～第４の実施の形態におけるＵＥ１の構成について説明する。図３は、本発明の第１～第４の実施の形態におけるＵＥの構成の一例を示す図である。

　図３において、ＵＥ１はアクセスネットワーク（３Ｇアクセス又はＮ３Ｇアクセス）とそれぞれ接続して下位レイヤにおける通信処理を行う第１無線通信部１０１、第１無線通信部１０１の上位でＩＰなどのパケット通信処理を実施するパケット処理部１０２、ＤＮＳサーバ９への問い合わせメッセージを送信し、その応答として受信した結果から所定のアドレス情報を取得するＤＮＳクライアント処理部１０５、本発明における特徴的な処理を実施する接続制御部１０６、ハンドオーバをしたかどうか判断するハンドオーバ判断部１０３、ハンドオーバや初期接続（Initial Attach）時にネットワークから割り当てられたＰＤＮＴｙｐｅがリクエストしたＰＤＮＴｙｐｅと一致するか判断するＰＤＮＴｙｐｅ判断部１０４を少なくとも有する。なお、第１無線通信部１０１以外に、第２、第３無線通信部と複数の無線通信部をＵＥ１が搭載することも想定している。各無線通信部は、３Ｇアクセス２又はＮ３Ｇアクセス３のいずれに接続するものであってもよく、さらには一方の無線通信部（例えば、第１無線通信部１０１）が同時に３Ｇアクセス２とＮ３Ｇアクセス３に接続するものであってもよい。

　本発明の第１の実施の形態においては、一例として、ＵＥ１が１つの無線通信部（第１無線通信部１０１）を有し、３Ｇアクセス２に対し、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立し、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信可能であるものとして説明する。

　次に、図３に図示されている構成を有するＵＥの処理フローについて、本発明における特徴的な処理を実施する接続制御部１０６に係る処理を中心に、図１０を用いて詳しく説明する。なお、ＵＥ１は、既に第１無線通信部１０１を介して３Ｇアクセス２を介して、ＰＧＷ５と接続済みであり、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立済みの状態で、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信可能な状態であるものとする。さらに、その状態でＵＥ１はシングルアドレスタイプネットワークにハンドオーバを行うものとする。

　図１０は、本発明の第１の実施の形態におけるＵＥ１の処理フローの一例を示すフロー図である。最初に、ＵＥ１はｅＮＢの判断により生じるハンドオーバに関する情報を第１無線通信部１０１から受信する。その後、ＵＥ１は、ＵＥ１内に構成されるハンドオーバ判断部１０３によって、ハンドオーバがされたことを検知する。なお、ＵＥ１は、ハンドオーバに関する情報を接続制御部１０６経由でハンドオーバ判断部１０３に転送し、ハンドオーバが生じたことを検知してもよい（ステップＳ１００１：Inter RATハンドオーバ）。

　ハンドオーバ処理が実施されたことを確認した後、接続制御部１０６は、ハンドオーバしたことによってネットワークから割り当てられたＰＤＮＴｙｐｅがハンドオーバ前のＰＤＮＴｙｐｅ（ＩＰｖ４ｖ６ＰＤＮＴｙｐｅ）と一致しているかＰＤＮＴｙｐｅ判断部１０４に確認指示をする。今回は、ＵＥ１がハンドオーバ前にマルチアドレスコネクション（ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクション）を確立済みであるため、シングルアドレスコネクション（ＩＰｖ６（ＩＰｖ４）ＰＤＮＴｙｐｅのＰＤＮコネクション）に変更されていないか確認する（ステップＳ１００２）。

　ハンドオーバ前に、ＵＥ１が保持していたＰＤＮＴｙｐｅと一致している場合は、特別な処理をせず、従来通りハンドオーバ後の処理を行う。一方、ハンドオーバ前のＰＤＮＴｙｐｅと異なる場合、つまりハンドオーバ前にＵＥ１はＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを持っていたが、ハンドオーバ後にはＩＰｖ６ＰＤＮＴｙｐｅなどのシングルアドレスコネクションタイプが割り当てられた場合、接続制御部１０６はｅＰＤＧ８のアドレスを探索するため、ＤＮＳクライアント処理部１０５に指示する（ステップＳ１０１０）。

　続いて、ＵＥ１はコアネットワークにあるｅＰＤＧ８を中継してＰＧＷ５とＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立する処理を開始する。まず、ＵＥ１は、ＭＭＥ７へ送信するPDN Connectivity RequestメッセージのパラメータであるPDN TypeをＩＰｖ４ｖ６ＰＤＮＴｙｐｅにセットしてメッセージを作成するように、ＵＥ１内に構成される接続制御部１０６からパケット処理部１０２へ指示する（ステップＳ１０１１）。さらに、同メッセージのパラメータであるRequest Typeに“handover”、維持し続けたいＩＰアドレスをIP Addressフィールド、維持し続けたいベアラがあれば、そのベアラに対応するBearer IDをBearer IDフィールド、そしてこれらのパラメータをＰＧＷ５が持つＥＰＳベアラコンテキストで更新することを指示するIndicationをRenew Indicationフィールドにセットするように接続制御部１０６からパケット処理部１０２へ指示する（ステップＳ１０１２～ステップＳ１０１５）。その後、ＵＥ１は各パラメータがセットされたPDN Connectivity RequestメッセージをＭＭＥ７に送信する（ステップＳ１０１６）。なお、ステップＳ１０１１からステップＳ１０１５の処理する順番は入れ替わってもよい。また、これらのＩＰアドレスなどのパラメータ以外で、維持し続けたいＩＰアドレスなどを通知できるパラメータやフィールドがある場合には、IP Addressフィールドを用いる必要はない。

　ネットワーク側は、オペレータ方針と、ＵＥ１から送信されたPDN Connectivity Requestメッセージに基づいて、ＥＰＳベアラコンテキスト内のＰＤＮコネクションのＰＤＮＴｙｐｅをＩＰｖ６ＰＤＮからＩＰｖ４ｖ６に変更する。ＥＰＳベアラコンテキストの更新処理を終えたＰＧＷ５は、更新結果をCreate Default Bearer ResponseメッセージとしてＳＧＷ６へ返信する。最終的には、ｅＮＢからRRC Connection ReconfigurationメッセージとしてＵＥ１に返信される（ステップＳ１０１７）。

　RRC Connection Reconfigurationメッセージを受信したＵＥ１は、RRC Connection Reconfiguration CompleteメッセージをｅＮＢに返信する（ステップＳ１０１８）。続いて、ＵＥ１はＮＡＳ（Non-Access Stratum）レイヤでPDN Connectivity Completeメッセージを作成し、Direct TransferメッセージとしてｅＮＢに送信する（ステップＳ１０１９）。この結果、ＵＥ１はシングルアドレスタイプネットワークにハンドオーバした際も、ハンドオーバ前のＰＤＮコネクション状態を維持したまま、通信可能となる。

　次に、本発明を実施するためのＰＧＷの構成について説明する。以下、図４を参照しながら、本発明の第１～第４の実施の形態におけるＰＧＷの構成について説明する。図４は、本発明の第１～第４の実施の形態におけるＰＧＷの構成の一例を示す図である。図４において、ＰＧＷ５は、コアネットワークと接続して下位レイヤにおける通信処理を行う通信部５０１、通信部５０１の上位でＩＰなどのパケット通信処理を実施するパケット処理部５０２、ＵＥ１がハンドオーバしたときにＥＰＳベアラコンテキストのＩＰアドレスを一時的に保持するなどの処理を行うハンドオーバ処理部５０３、ＵＥ１からＰＤＮコネクションリクエストが来たときに処理するＰＤＮコネクション確立処理部５０４、ＵＥ１から送られてくるＰＤＮコネクションリクエストメッセージをＰＧＷ５又はｅＰＤＧ８のどちらに送るのか判断する宛先アドレス処理部５０５、本発明における特徴的な処理を実施する接続制御部５０６を少なくとも有する。

　次に、図４に図示されている構成を有するＰＧＷ５の処理フローについて、本発明における特徴的な処理を実施する接続制御部５０６に係る処理を中心に、図１２を用いて詳しく説明する。なお、ＰＧＷ５は、既に通信部５０１を介し、３Ｇアクセス２に接続済みであるものとする。加えて、ＰＧＷ５は、既にＩＰｖ４ｖ６ＰＤＮＴｙｐｅコネクションを確立しているＵＥ１とパケットの送受信を行っている状態とする。またＵＥ１は、シングルアドレスタイプネットワークにハンドオーバを行うものとする。

　図１２は、本発明の第１の実施の形態におけるＰＧＷ５の処理フローの一例を示すフロー図である。最初に、ＰＧＷ５はｅＮＢの判断によって起こるＵＥ１のハンドオーバに関するメッセージを通信部５０１から受信する。その後、ＰＧＷ５はハンドオーバ処理部５０３によって、ＵＥ１のハンドオーバを処理し、ＵＥ１に関する位置情報を更新する（ステップＳ２００１：Inter RATハンドオーバ）。その後、ＰＧＷ５は、ＵＥ１によってＰＤＮコネクション維持を目的としたメッセージを含むＰＢＵメッセージをｅＰＤＧ８から受信する（ステップＳ２００２）。ＰＢＵメッセージを受信したＰＧＷ５は、ＰＢＵメッセージ内にＵＥ１のＥＰＳベアラコンテキストを更新することを示すRenew Indicationが格納されているか確認する（ステップＳ２００３）。

　前記ＰＢＵメッセージにRenew Indicationが格納されていない場合は、ＰＧＷ５は特別な処理をせずに一般的なＰＤＮコネクションリクエストだと判断し、従来通りの処理を実施する。一方、Renew Indicationが格納されている場合、ＰＧＷ５は受信したＰＢＵメッセージ内に格納されているＩＰｖ４ＨｏＡを取り出す（ステップＳ２００５）。続いて、ＰＧＷ５は同ＰＢＵメッセージ内にBearer IDが格納されている場合、ＰＢＵメッセージからBearer IDを取り出す（ステップＳ２００６）。なお、ステップＳ２００５とステップＳ２００６の処理する順番は、入れ替わってもよい。

　その後、ＰＧＷ５は前記ＰＢＵメッセージから取り出したＩＰｖ４ＨｏＡとBearer IDを、ＰＧＷ５自身が持つＰ－ＧＷコンテキストに追加して更新する（ステップＳ２００７）。続いて、ＰＧＷ５は、ＵＥ１がリクエストしてきた本ＰＤＮコネクションリクエストは、既にＵＥ１が確立済みであるＰＤＮに対してかどうかを確認する。なお、確認する手段として、PDN Connectivity Requestに格納されているＡＰＮ（Access Point Name）を識別子として判断してもよい（ステップＳ２００８）。既に確立済みのＰＤＮに対してのPDN Connectivity Requestでない場合には、ＰＧＷ５はＰＣＲＦに対し、PCEF-Initiated IP-CAN Session Modification Procedureを開始する（ステップＳ２０１０）。

　一方、既に確立済みのＰＤＮに対してのPDN Connectivity Requestである場合には、ＰＧＷ５はハンドオーバ（ＨＯ）後のUE re-establishes PDN Connectivity Procedureであるかどうかを確認する（ステップＳ２０２０）。確認する手段として、ＰＢＵメッセージ内に格納されているHandover Indicatorに“handover”が格納されているかを確認することで判断してもよい。なお、このHandover Indicator以外にハンドオーバ後であるかどうかを確認する手段がある場合には、その方法を用いてもよい。

　ハンドオーバ後のUE re-establishes PDN Connectivity Procedureでない場合には、ＰＧＷ５は特別な処理をせずに終了する。一方、ハンドオーバ後のue re-establishes PDN Connectivity Procedureである場合には、ＰＧＷ５はＰＣＲＦとIP-CAN Session Establishment Procedureを開始する（ステップＳ２０２１）。この結果、ＰＧＷ５はＵＥ１に対して、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立することとなる。

　次に、本発明を実施するためのＳＧＷ６の構成について説明する。以下、図５を参照しながら、本発明の第１～第４の実施の形態におけるＳＧＷ６の構成について説明する。図５は、本発明の第１～第４の実施の形態におけるＳＧＷ６の構成の一例を示す図である。図５において、ＳＧＷ６は、ＰＧＷ５やＭＭＥ７などと下位レイヤにおける通信処理を行う通信部６０１、通信部６０１の上位でＩＰなどのパケット通信処理を実施するパケット処理部６０２、ＵＥ１がハンドオーバをした際に生じるＰＤＮコネクション廃棄を回避するリクエストなどを処理するハンドオーバ処理部６０３、ＵＥ１から送られてくるＰＤＮコネクションリクエストメッセージをＰＧＷ５又はｅＰＤＧ８のどちらに送るのか判断する宛先アドレス処理部６０４、本発明における特徴的な処理を実施する接続制御部６０５を少なくとも有する。

　次に、本発明を実施するためのｅＰＤＧ８の構成について説明する。以下、図６を参照しながら、本発明の第１～第４の実施の形態におけるｅＰＤＧ８の構成について説明する。図６は、本発明の第１～第４の実施の形態におけるｅＰＤＧ８の構成の一例を示す図である。

　図６において、ｅＰＤＧ８は、ＰＧＷ５などと下位レイヤにおける通信処理を行う通信部８０１、通信部８０１の上位でＩＰなどのパケット通信処理を実施するパケット処理部８０２、ＵＥ１とＰＧＷ５間でＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションが確立された後、ｅＰＤＧ８から直接ＵＥ１にパケットを送信するのか、ＰＧＷ５を中継してＵＥ１にパケットを送信するのか判断するルート判断部８０３、ＰＢＵメッセージがどのプロトコルで送られてきたか判断するプロトコル判断部８０４、受信したメッセージがＰＢＵメッセージかどうかを判断するメッセージ判断部８０５、本発明における特徴的な処理を実施する接続制御部８０６を少なくとも有する。

　次に、図６に図示されている構成を有するｅＰＤＧ８の処理フローについて、本発明における特徴的な処理を実施する接続制御部８０６に係る処理を中心に、図１５を用いて詳しく説明する。なお、ｅＰＤＧ８は、既に通信部８０１を介し、コアネットワーク４を介してＰＧＷ５と接続済みであり、ＵＥ１のＰＤＮコネクションリクエストを含むパケットの送受信可能な状態であるものとする。また、その状態で、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを持つＵＥ１がシングルアドレスタイプネットワークにハンドオーバを行うものとする。

　図１５は、本発明の第１の実施の形態におけるｅＰＤＧ８の処理フローの一例を示すフロー図である。最初に、ＵＥ１がＩＰｖ４ｖ６ＰＤＮＴｙｐｅを持ち、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信を行っている状態で、シングルアドレスタイプネットワークにハンドオーバしたとき、ハンドオーバ前における通信状態の維持を目的とした処理を実施することで、ＳＧＷ６から送られてくるＰＢＵメッセージをｅＰＤＧ８が持つ通信部８０１で受信する（ステップＳ３００１）。

　ＰＢＵメッセージを受信したｅＰＤＧ８は、ｅＰＤＧ８が持つ通信部８０１からパケット処理部８０２にＰＢＵメッセージを転送する。その後、パケット処理部８０２からプロトコル判断部８０４へ転送され、送られてきたＰＢＵメッセージが、ｅＰＤＧ８のサポートするプロトコルのメッセージであるかどうか判断する（ステップＳ３００２）。このとき、パケット処理部８０２から直接プロトコル判断部８０４へ転送するのではなく、接続制御部８０６を介してメッセージを転送してもよい。

　なお、一般的に、ｅＰＤＧ８はＮ３Ｇアクセス３で使用される装置であり、ＣＭＩＰ（Client Mobile IP：ＭＩＰと呼ばれることもある）とＰＭＩＰが実装されている（上記の非特許文献２を参照）。ＵＥ１が３Ｇアクセス２でＰＭＩＰを用いてｅＰＤＧ８にアクセスすることは問題ないが、３Ｇアクセス２でＧＴＰを用いており、３Ｇアクセス２経由でｅＰＤＧ８にＰＢＵメッセージを送る場合は、ｅＰＤＧ８が持つプロトコル判断部８０４でＧＴＰをサポートしておく必要がある。

　ｅＰＤＧ８がサポートしているプロトコルによるメッセージだと判断した場合、プロトコル判断部８０４から接続制御部８０６を介し、メッセージ判断部８０５へ転送され、送られてきたＰＢＵメッセージがどのようなメッセージであるか判断する（ステップＳ３０１１）。なお、ＳＧＷ６は、ＰＢＵメッセージではなく、新規メッセージなどを用いてＵＥ１のＰＤＮコネクションリクエスト情報（例えば、ＰＤＮＴｙｐｅなど）を通知する場合もあり、どのようなメッセージであるか判断する必要がある。

　受信したメッセージが、ＰＤＮコネクションリクエストに関するメッセージだと判断された場合は、メッセージ判断部８０５から接続制御部８０６を介してパケット処理部へ８０２転送し、Proxy Binding Update ePDGメッセージを作成する（ステップＳ３０１２）。Proxy Binding Update ePDGメッセージに格納されるパラメータは、ＰＢＵメッセージに格納されていたパラメータ（例えば、ＰＤＮＴｙｐｅやＡＰＮなど）と基本的には同じであるが、ｅＰＤＧ８が特別に格納したいパラメータがある場合は、格納できるようにする。作成したProxy Binding Update ePDGメッセージは、パケット処理部８０２から通信部８０１に転送され、ＰＧＷ５に送信される（ステップＳ３０１３）。その後、ｅＰＤＧ８は、Proxy Binding Update ePDGメッセージの返信であるProxy Binding Ack ePDGメッセージを通信部８０１で受信する（ステップＳ３０１４）。受信したProxy Binding Ack ePDGメッセージは、通信部８０１からパケット処理部８０２を介して、接続制御部８０６へ転送される。

　続いて、Proxy Binding Update ePDGメッセージが正常に処理されているかどうかProxy Binding Ack ePDGメッセージから確認する（ステップＳ３０２１）。正常に終了されていたら、パケット処理部８０２にＰＢＡメッセージを作成するように指示し、ＰＢＡメッセージを作成する（ステップＳ３０２２）。ＰＢＡメッセージを作成後、パケット処理部８０２から通信部８０１を介して、ＰＢＵメッセージの返信としてＰＢＡメッセージをＳＧＷ６に送信する（ステップＳ３０２３）。また、ＵＥ１とｅＰＤＧ８間にパケットを送受信できる通信経路が確立されている場合（例えば、ＵｎｔｒｕｓｔｅｄＮ３Ｇアクセス）、ＳＧＷ６にＰＢＡメッセージを送信する前に、ルート判断部８０３にｅＰＤＧ８から直接ＵＥ１にパケットを送信するのか、ＰＧＷ５を中継してＵＥ１にパケットを送信するのか問い合わせてから、ＰＢＡメッセージを送信するルートを決めてもよい。ＰＢＡメッセージ送信の最適なルートを選択することによって、ＰＧＷ５を含む３Ｇアクセス２で機能する装置の処理負荷軽減や、パケットの伝送時間が短縮される可能性がある。

　第１の実施の形態に基づいて処理することで、ＵＥ１は、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信を行っている状態で、シングルアドレスコネクションのみに対応しているネットワークにハンドオーバしたとき、オペレータ方針に依存せずにハンドオーバ前に保持していたＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを維持することができる。つまり、ＵＥ１は、従来であれば放棄されてしまうアドレス（第１の実施の形態ではＩＰｖ４ＨｏＡ）宛てのパケット転送が放棄されずに、シングルアドレスタイプネットワークにハンドオーバすることができる。これにより、ＵＥ１は、ハンドオーバ前から受信していたパケットをハンドオーバ後のネットワークでも受信することが可能となり、改めてマルチアドレスタイプコネクション対応ネットワークへＵＥ１がハンドオーバする際も特別な処理を実施せずに、ＰＤＮコネクション（ＩＰｖ４ｖ６ＰＤＮＴｙｐｅ）を維持することができる。

　＜第２の実施の形態＞
　次に、本発明の第２の実施の形態におけるシステム動作の一例について、図７を用いて詳しく説明する。図７は、本発明の第２の実施の形態におけるシステム動作の一例を説明するためのシーケンス図である。図７は、少なくともＵＥ１、ＵＥ１と直接的にパケットの送受信を行うｅＮＢ、ＵＥ１の移動管理を担当するＭＭＥ７、ｅＮＢを統括するＳＧＷ６、ＳＧＷ６を統括しＰＤＮへのゲートウェイの役割を担い、ＵＥ１の位置情報を管理するＰＧＷ５、ＵＥ１の課金コントロールなどを管理しているＰＣＲＦ、ＵＥ１のサブスクリプション情報などを保持管理するＨＳＳによる処理シーケンスの一例が図示されている。なお、各機能を代わりに担うことができる構成要素が存在する場合には、それらを用いてもよい。

　また、図７では、ＩＰｖ６ＰＤＮＴｙｐｅが割り当てられることを想定しており、ＩＰｖ６ＨｏＡに加えて、ＩＰｖ４ＨｏＡ宛てのパケットも受信するためのシーケンスが図示されている。ＵＥ１が、ｅＮＢのカバーするパケット転送エリアから超えそうになる場合、又はオペレータ方針に基づいて異なるネットワークをＵＥ１に割り当てる場合などにおいて、現在ＵＥ１が接続されているｅＮＢが、ハンドオーバ先のアクセスネットワークに対してハンドオーバ処理を開始する（上記の非特許文献１を参照）。

　ＵＥ１は、ハンドオーバ前にＰＧＷ５とＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立しており、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信を行っているが、シングルアドレスタイプネットワークにハンドオーバした結果、ハンドオーバ先のネットワークのオペレータ方針に基づいて、ＵＥ１のＰＤＮＴｙｐｅはＩＰｖ４ｖ６ＰＤＮＴｙｐｅからＩＰｖ６ＰＤＮＴｙｐｅに変更される。つまり、ＵＥ１がハンドオーバ前に使用していたＩＰｖ４ＨｏＡ宛てのパケットがネットワーク側で放棄され、ＩＰｖ４ＨｏＡ宛てのパケットが転送されなくなる。また、ＵＥ１はＩＰｖ４ＨｏＡをソースアドレスとしたパケットをネットワーク側に送信できなくなる（ステップＳ２０１：Inter RATハンドオーバ）。

　なお、第２の実施の形態では、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションがＩＰｖ６ＰＤＮＴｙｐｅに変更され、ＩＰｖ４ＨｏＡ宛てのパケットが放棄される場合について説明するが、オペレータ方針によってはＩＰｖ４ＰＤＮＴｙｐｅに変更され、ＩＰｖ６ＨｏＡ宛てのパケットが放棄される場合も考えられる。このような場合においても、本発明は適用可能であり、本実施の形態において説明する方法と同様の方法により、所望の目的を達することができる。

　なお、このシングルアドレスタイプネットワークとは、オペレータ方針に基づいて、ＩＰｖ４とＩＰｖ６に対応しているものの、ＩＰｖ４又はＩＰｖ６のいずれか一方のみを使用することが許可されたネットワークである場合と、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅの概念が検討されず、ＩＰｖ４又はＩＰｖ６のいずれか一方のみにしか対応していないネットワークである場合がある。後者の場合、ＵＥ１はネットワークから割り当てられたシングルアドレスコネクション以外に、割り当てられなかったアドレスに対応するＰＤＮコネクションを新たに確立することを目的としたＰＤＮコネクションリクエストメッセージをネットワークに送信するかもしれない（上記の非特許文献２を参照）。

　その結果を受け、ＵＥ１はハンドオーバ前に使用していたＩＰｖ４ＨｏＡ宛てのパケットを受信するためにｅＮＢを中継してＳＧＷ６、ＰＧＷ５が持つＥＰＳベアラコンテキストを更新し、ＩＰｖ４ＨｏＡ宛てのパケットがＵＥ１に届くように指示するIPv4 Address Requestメッセージを送信する（ステップＳ２０２：IPv4 Address Request）。

　なお、図７のステップＳ２０２においてＵＥ１がｅＮＢに送るIPv4 Address Requestメッセージのフォーマットには、第１の実施の形態で用いたPDN Connectivity Requestメッセージのフォーマット（図８に図示されているメッセージのフォーマット）と同一のものを利用することが可能であり、ここでは説明を省略する。

　前記IPv4 Address Requestメッセージを受信したｅＮＢは、メッセージを変更せずにＳＧＷ６へ転送する（ステップＳ２０３：IPv4 Address Request）。ｅＮＢから送られてきたIPv4 Address Requestメッセージを受信したＳＧＷ６は、前記IPv4 Address Requestメッセージに格納されているパラメータ（例えば、ＩＰｖ４ＨｏＡなど）を基に、ＳＧＷ６自身が持つＥＰＳベアラコンテキストを修正する。修正した結果、ＵＥ１がハンドオーバしたことで転送されなくなったＩＰｖ４ＨｏＡ宛てのパケットが転送できるように更新され、ハンドオーバ前のようなＥＰＳベアラコンテキストの状態に戻る。また、並行して、ｅＮＢから受信したIPv4 Address Requestメッセージを変更せずにＰＧＷ５へ転送する（ステップＳ２０４：IPv4 Address Request）。

　ＳＧＷ６から送られてきたIPv4 Address Requestメッセージを受信したＰＧＷ５は、前記IPv4 Address Requestメッセージに格納されているパラメータ（例えば、ＩＰｖ４ＨｏＡなど）を基に、ＰＧＷ５自身が持つＥＰＳベアラコンテキストを修正する。その結果、ＵＥ１に関する最新のＥＰＳベアラコンテキストが登録され、後にＵＥ１がハンドオーバする際であっても、現在アクティブであるＰＤＮコネクション状態を引き継ぐことが可能となる（ステップＳ２０５：ＥＰＳベアラコンテキストを更新）。なお、IPv4 Address RequestメッセージにBearer IDが格納されている場合は、ハンドオーバ前に使用していたBearer IDに対応するベアラをハンドオーバ後でも使用することが可能となる。その後、ＰＧＷ５はIPv4 Address Requestメッセージに対する返信メッセージとして、IPv4 Address ResponseメッセージをｅＮＢに返信する（ステップＳ２０６：IPv4 Address Response）。ＳＧＷ６からIPv4 Address Responseメッセージを受信したｅＮＢは、IPv4 Address ResponseメッセージをＵＥ１へ転送する（ステップＳ２０７：IPv4 Address Response）。

　なお、ステップＳ２０４及びＳ２０５において、ＥＰＳベアラコンテキストを更新している処理があるが、ＰＧＷ５がＩＰｖ４ＨｏＡ宛てに届いたメッセージに対して、宛先ヘッダのアドレス（ＩＰｖ４ＨｏＡに相当）をＵＥ１のＩＰｖ６ＨｏＡに書き換えるか、若しくはヘッダを従来のメッセージに追加することで、ＥＰＳベアラコンテキストが更新された旨をＵＥ１に通知してもよい。また、ＩｎｔｅｒＲＡＴハンドオーバ処理中に、ＵＥ１があらかじめネットワーク側に対して、割り当てないＩＰｖ４ＰＤＮＴｙｐｅを維持するように通知することでＩＰｖ４ＨｏＡ宛てのメッセージをＵＥ１に届けるように指示してもよい。具体的にどのように行うかについて、図１１を用いて説明する。

　図１１は、マルチコネクション対応のネットワークからシングルアドレスタイプネットワークへハンドオーバしたときのシーケンス図の一部である。ＵＥ１が、ターゲットＲＮＣ（Target RNC（Radio Network Controller））にHandover to UTRAN completeメッセージを送信する際に、ターゲットＳＧＳＮ（Target SGSN（Serving GPRS Support Node））、ＳＧＷ６、ＰＧＷ５の各々が持つＥＰＳベアラコンテキストからＩＰｖ４ＨｏＡ関連のＰＤＮコネクション情報を削除しないことを指示するフラグと、削除してほしくないベアラがある場合には、そのベアラに対応するBearer IDをHandover to UTRAN completeメッセージに追加する。

　図９Ａは、図１１のステップＳ３５１においてＵＥ１がターゲットＲＮＣに送るHandover to UTRAN completeメッセージの一例を示す図である。ＵＥ１は、従来の標準的なHandover to UTRAN completeメッセージ２００１に加えて、Non-Release Indicationフィールド２００２、Bearer IDフィールド２００３を設け、それぞれ所定の値をターゲットＲＮＣに通知することができる。なお、本メッセージは、所定の情報を転送できるものであればHandover to UTRAN completeメッセージ以外のメッセージであってもよい。

　前記Handover to UTRAN completeメッセージを受信したターゲットＲＮＣは、ハンドオーバ前の情報がターゲットＲＮＣに移行完了したことを通知するために送るRelocation Completeメッセージに、Handover to UTRAN completeメッセージで受信したNon-Release IndicationとBearer IDを追加してターゲットＳＧＳＮに送信する。

　図９Ｂは、図１１のステップＳ３５２においてターゲットＲＮＣがターゲットＳＧＳＮに送るRelocation Completeメッセージの一例を示す図である。ターゲットＲＮＣは、従来の標準的なRelocation Completeメッセージ２１０１に加えて、Non-Release Indicationフィールド２１０２、Bearer IDフィールド２１０３を設け、それぞれ所定の値をターゲットＳＧＳＮに通知することができる。なお、本メッセージは、所定の情報を転送できるものであればRelocation Completeメッセージ以外のメッセージであってもよい。

　Relocation Completeメッセージを受信したターゲットＳＧＳＮは、今ターゲットＳＧＳＮがＵＥによって確立された全てのＥＰＳベアラコンテキストに対して応答可能であるということを示すUpdate Bearer RequestメッセージにRelocation Completeメッセージで受信したパラメータ（Non-Relocation IndicationやBearer ID）を追加して、ターゲットＳＧＷ（Target SGW）に送信する。

　図９Ｃは、図１１のステップＳ３５３においてターゲットＳＧＳＮがターゲットＳＧＷに送るUpdate Bearer Requestメッセージの一例を示す図である。ターゲットＳＧＳＮは、従来の標準的なUpdate Bearer Requestメッセージ２２０１に加えて、Non-Release Indicationフィールド２２０２、Bearer IDフィールド２２０３を設け、それぞれ所定の値をターゲットＳＧＷに通知することができる。なお、本メッセージは、所定の情報を転送できるものであればUpdate Bearer Requestメッセージ以外のメッセージであってもよい。

　その後は、一般的なハンドオーバ処理が実施される。その結果、ＳＧＳＮとＳＧＷ６、ＰＧＷ５はＥＰＳベアラコンテキストからＩＰｖ４ＨｏＡ関連のＰＤＮコネクション情報を削除せず、また、ＳＧＷ５は、ＩＰｖ４ＨｏＡ宛てに送られてきたパケットを廃棄せずに、ＵＥに通知することが可能となる。

　＜第３の実施の形態＞
　以下、本発明の第３の実施の形態におけるシステム動作の一例について、図１３を用いて詳しく説明する。図１３は、本発明の第３の実施の形態におけるシステム動作の一例を説明するためのシーケンス図である。なお、図１３では、ＵＥ１はＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを持ち、そのＰＤＮコネクションにおいてＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信をしている状態が図示されている。また、ＵＥ１がシングルアドレスタイプネットワークにハンドオーバした結果、ＩＰｖ６ＰＤＮＴｙｐｅが割り当てられることを想定しており、ハンドオーバ前に取得したＩＰｖ４ＨｏＡを維持すると同時に、ＩＰｖ４ＨｏＡ宛てのパケットを送受信可能にするためのシーケンスが図示されている。

　図１３には、少なくともＵＥ１、ＵｎｔｒｕｓｔｅｄＮ３Ｇアクセス３におけるＰＤＮコネクションを確立する機能を持つ構成要素であるｅＰＤＧ８、ＵＥ１の位置情報を管理するＰＧＷ５、ＵＥ１の課金コントロールなどを管理しているＰＣＲＦ、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断するＵＥ認証サーバであるＡＡＡ（Authentication, authorization and Accounting）サーバ、ＵＥ１のサブスクリプション情報などを保持管理するＨＳＳによる処理シーケンスの一例が図示されている。なお、各機能を代わりに担うことができる構成要素が存在する場合には、それらを用いてもよい。また、ＡＡＡサーバとＨＳＳは、物理的又は論理的に同一の装置に実装されるものであってもよく、以降、ＡＡＡサーバとＨＳＳを説明の都合上まとめてＡＡＡ／ＨＳＳと呼ぶこともある。

　ＵＥ１が、ｅＮＢのカバーするパケット転送エリアを超えそうになる場合、又はオペレータ方針に基づいて異なるｅＮＢをＵＥ１に割り当てる場合（例えば、ＵＥ１に適したｅＮＢの検知など）、ｅＮＢは新しいｅＮＢをＵＥ１に割り当てるためにハンドオーバ処理を開始する。

　ＵＥ１は、ハンドオーバ前にＰＧＷ５とＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立しており、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信を行っているが、シングルアドレスタイプネットワークにハンドオーバした結果、ハンドオーバ先のネットワークのオペレータ方針に基づいてＩＰｖ４ｖ６ＰＤＮＴｙｐｅからＩＰｖ６ＰＤＮＴｙｐｅに変更される。つまり、ＵＥ１がハンドオーバ前に使用していたＩＰｖ４ＨｏＡが放棄され、ＩＰｖ４ＨｏＡ宛てのパケットが転送されなくなる。また、ＵＥ１はＩＰｖ４ＨｏＡをソースアドレスとしたパケットをネットワーク側に送信できなくなる（ステップＳ３０１：Inter RATハンドオーバ）。

　なお、第３の実施の形態の説明では、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションがＩＰｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションに変更され、ＩＰｖ６ＨｏＡ宛てのパケットのみが転送される場合について説明するが、オペレータ方針によってはＩＰｖ４ＰＤＮＴｙｐｅのＰＤＮコネクションに変更され、ＩＰｖ４ＨｏＡ宛てのパケットのみが転送される場合も考えられる。このような場合においても、本発明は適用可能であり、本実施の形態において説明する方法と同様の方法により、所望の目的を達することができる。

　ステップＳ３０１でハンドオーバ（例えばＩｎｔｅｒＲＡＴハンドオーバ）した後、ＰＤＮＴｙｐｅが変更されたことを検知したＵＥ１は、ハンドオーバ前に使用していたＩＰｖ４ＨｏＡ宛てのパケットを受信することを目的とした処理を実施する。例えばＤＮＳサーバ９にｅＰＤＧ８のアドレスを問い合わせる（ステップＳ３０２：ePDG Discovery）。なお、ここでは、ＵＥ１はｅＰＤＧ８のアドレスを取得するためにＤＮＳサーバ９に問い合わせているが、ＵＥ１がＮ３Ｇアクセス３に接続していたときにｅＰＤＧ８のアドレスを記憶しておき、そのアドレス情報を再利用などしてもよい。

　なお、ｅＰＤＧ８を用いる理由は、現状のコアネットワークに存在する構成要素に対しての新機能の追加が最小限で済むからである。また、ｅＰＤＧ８同等の変更で済む場合には、ｅＰＤＧ８の代わりに他の構成要素を用いてもよい。

　ｅＰＤＧ８のアドレスを取得したＵＥ１は、３Ｇアクセス３上でＰＧＷ５を経由し、さらにＰＤＮを経由してｅＰＤＧ８とIKEv2 Authentication and Tunnel Setupを行う（ステップＳ３０３：IKEv2 Authentication and Tunnel Setup）。なお、ｅＰＤＧ８は本来、ＵＥ１がＮ３Ｇアクセス３を利用するときに用いられるコアネットワーク上の装置であるが、第３の実施の形態のように３Ｇアクセス２を用いながらＰＤＮ経由でｅＰＤＧ８にハンドオーバ処理などをする際は、ＵＥ１によるＰＤＮコネクション確立リクエストであるとｅＰＤＧ８が認識できるようにパラメータをセットする必要がある。例えば、ＡＴＴ（Access Technology Type）に３ＧＩＰアドレスに対応する値をセットするなどが挙げられる。

　なお、本ステップＳ３０３は、従来、ＵｎｔｒｕｓｔｅｄＮ３Ｇアクセス３におけるＵＥ１とｅＰＤＧ８間で交換されるメッセージの保護を目的としているが、第３の実施の形態ではｅＰＤＧ８からＰＤＮ経由でＵＥ１とメッセージを交換するため、要求されるセキュリティレベルによっては省略することも可能である。

　ＵＥ１は、IKEv2 Authentication and Tunnel Setupの処理中にｅＰＤＧ８へ送るメッセージに、ＵＥ１がハンドオーバ前の状態を維持したいことを示すために、ＥＰＳベアラコンテキストの更新要求を示すRenew Indication、ハンドオーバ前のＰＤＮＴｙｐｅ（第３の実施の形態ではＩＰｖ４ｖ６ＰＤＮＴｙｐｅ）、ハンドオーバした結果、廃棄されたＩＰｖ４ＨｏＡ、維持したいベアラがある場合には、そのベアラに対応するBearer IDを追加し、ｅＰＤＧ８に送信する。なお、ＵＥ１は、IKEv2 Authentication and Tunnel Setup処理中にｅＰＤＧ８へ送るメッセージ以外に、上記パラメータをｅＰＤＧ８へ通知する手段があれば、他のメッセージを用いてもよい。

　図１４Ａは、図１３におけるステップＳ３０３においてＵＥ１がｅＰＤＧ８に送るIKEv2 Authentication and Tunnel Setupにおけるメッセージの一例を示す図である。ＵＥ１は、従来の標準的なIKEv2 Authentication and Tunnel Setupにおいて送信するメッセージ３００１に加えて、Renew Indicationフィールド３００２、PDN Typeフィールド３００３、IP Addressフィールド３００４、Bearer IDフィールド３００５を設け、それぞれ所定の値をｅＰＤＧ８に通知することができる。なお、本メッセージは、所定の情報を転送できるものであればIKEv2 Authentication and Tunnel Setupにおけるメッセージ以外のメッセージであってもよい。例えば、Renew Indicationフィールド３００２の代わりに一般的なIKEv2メッセージのHandover Indicationフィールドを使用してもよい。また、PDN Typeフィールド３００３やIP Addressフィールド３００４の代わりに、一般的なIKEv2メッセージのＣＦＧリクエストにＰＤＮＴｙｐｅや廃棄されるＩＰｖ４アドレスを格納してもよい。

　続いて、ｅＰＤＧ８はＰＧＷ５情報の取得、ＵＥ１の認証などを行うために、ＡＡＡ／ＨＳＳとAuthentication and Authorizationを実施する（ステップＳ３０４：Authentication and Authorization）。その後、ｅＰＤＧ８はＰＧＷ５に対して、ハンドオーバインディケータ（HO Indicator）やＡＴＴなど通知するためにＰＢＵメッセージを送信する（ステップＳ３０５：Proxy Binding Update）。なお、ｅＰＤＧ８は本来、ＵＥ１がＮ３Ｇアクセス３を利用するときに用いられるコアネットワーク４上の装置であるが、第３の実施の形態のように３Ｇアクセス２を用いながらＰＤＮ経由でｅＰＤＧ８にハンドオーバ処理などをする際は、ＵＥ１によるＰＤＮコネクション確立リクエストであるとＰＧＷ５が認識できるようにパラメータをセットする必要がある。例えば、ＡＴＴに３ＧＩＰアドレスに対応する値をセットするなどが挙げられる。

　図１４Ｂは、図１３のステップＳ３０５においてｅＰＤＧ８がＰＧＷ５に送るＰＢＵメッセージの一例を示す図である。ｅＰＤＧ８は、従来の標準的なＰＢＵメッセージ３１０１に加えて、Renew Indicationフィールド３１０２、PDN Typeフィールド３１０３、IP Addressフィールド３１０４、Bearer IDフィールド３１０５を設け、それぞれ所定の値をＰＧＷ５に通知することができる。

　Renew Indicationフィールド３１０２には、ＰＧＷ５が持つＥＰＳベアラコンテキストで、ＵＥ１のＰＤＮコネクション情報更新を示す値が格納される。PDN Typeフィールド３１０３には、ＵＥ１がリクエストするＰＤＮＴｙｐｅ（第３の実施の形態では、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅ）が格納される。IP Addressフィールド３１０４には、ＵＥ１がハンドオーバした際、ハンドオーバ前に割り当てられていたＩＰアドレス以外のアドレスを格納する（第３の実施の形態では、ＩＰｖ４アドレス）。Bearer IDフィールド３１０５には、ＵＥ１が維持したいベアラが存在するときに、そのベアラに対応するBearer IDが格納される。これらの情報を基に、ＰＧＷ５は、ＰＧＷ５自身が持つＥＰＳベアラコンテキストを更新する。このとき、ＰＧＷ５は、ハンドオーバ前から使用していて、ハンドオーバ時にもＰＤＮコネクションで使用しているＩＰｖ６アドレスもＩＰｖ４アドレスと一緒に追加する。なお、新規に追加するそれぞれの値を従来の標準的なＰＢＵメッセージにあるAdditional Parameterフィールドに格納してもよい。また、本メッセージは、所定の情報を転送できるものであればＰＢＵメッセージ以外のメッセージであってもよい。

　続いて、ＰＧＷ５はＰＣＲＦとIP-CAN Session Establishment Procedureを実施する（ステップＳ３０６：IP-CAN Session Establishment Procedure）。さらに、ＰＧＷ５は、ＵＥ１が持つＰＤＮコネクションに関連するＰＧＷ５の識別子（PGW Identity）とＡＰＮをＡＡＡ／ＨＳＳに通知するために、Update PGW Addressメッセージ交換を行う（ステップＳ３０７：Update PGW Address）。更に続いて、ＰＧＷ５はｅＰＤＧ８から送られてきたＰＢＵメッセージに格納されている情報に基づいてＢＣＥを作成し、ＵＥ１に割り当てるＩＰアドレスなどが格納されたＰＢＡメッセージをｅＰＤＧ８に返信する（ステップＳ３０８：Proxy Binding Ack）。なお、一般的なｅＰＤＧ８の使用方法（Ｎ３Ｇアクセス３におけるｅＰＤＧ８の接続手法）では、このステップＳ３０８でＰＧＷ５がＵＥ１に割り当てるＩＰアドレスを決めるが、第３の実施の形態のように３Ｇアクセス３とＰＤＮを経由してｅＰＤＧ８にアクセスし、ハンドオーバ処理などを行う場合では、特にこのステップでＵＥ１に割り当てるＩＰアドレスを決める必要はない。

　続いて、ｅＰＤＧ８は、ＰＢＡメッセージを受信し、ＰＢＵ処理が成功したと判断したら、この段階でＵＥ１に認証されたこととなる（ステップＳ３０９：IPSec Tunnel Setup Completion）。続いて、ｅＰＤＧ８は、ＵＥ１に割り当てるＩＰアドレスやＰＤＮに関連する識別子（identity）などを格納した最後のIKEv2メッセージをＵＥ１に送信する（ステップＳ３１０：IKEv2（IP Address Configuration））。ステップＳ３１０の完了後、ＵＥ１とｅＰＤＧ８間でＩＰｓｅｃトンネル（IPsec tunnel）が確立され、ｅＰＤＧ８とＰＧＷ５間でＰＭＩＰトンネル（PMIP tunnel）が確立される。その結果、ＵＥ１がハンドオーバ前から保持していたＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡが維持され、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションが再確立される（ステップＳ３１１：IPSec and PMIPv6 Tunnels）。

　次に、図３に図示されている構成を有するＵＥ１の処理フローについて、本発明における特徴的な処理を実施する接続制御部１０６に係る処理を中心に、図１７を用いて詳しく説明する。なお、ＵＥ１は、既に第１無線通信部１０１を介して３Ｇアクセス２を介して、ＰＧＷ５と接続済みであり、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立済みの状態で、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信可能な状態であるものとする。さらに、その状態でＵＥ１はシングルアドレスタイプネットワークにハンドオーバを行うものとする。

　図１７は、本発明の第３の実施の形態におけるＵＥ１の処理フローの一例を示すフロー図である。最初に、ＵＥ１はｅＮＢの判断により生じるハンドオーバに関する情報を第１無線通信部１０１から受信する。その後、ＵＥ１は、パケット処理部１０２を経由してハンドオーバ判断部１０３に転送され、ハンドオーバ判断部１０３によって、ハンドオーバがされたことを検知する。なお、ＵＥ１は、ハンドオーバに関する情報を接続制御部１０１経由でハンドオーバ判断部１０３に転送し、ハンドオーバが生じたことを検知してもよい（ステップＳ１５０１：Inter RATハンドオーバ）。

　ハンドオーバ処理が実施されたことを確認した後、接続制御部１０４は、ハンドオーバしたことによってネットワークから割り当てられたＰＤＮＴｙｐｅがハンドオーバ前のＰＤＮＴｙｐｅ（ＩＰｖ４ｖ６ＰＤＮＴｙｐｅ）と一致しているかＰＤＮＴｙｐｅ判断部１０４に確認指示をする。今回は、ＵＥ１がハンドオーバ前にマルチアドレスコネクション（ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクション）を確立済みであるため、シングルアドレスコネクション（ＩＰｖ６（ＩＰｖ４）ＰＤＮＴｙｐｅのＰＤＮコネクション）に変更されていないか確認する（ステップＳ１５０２）。

　ハンドオーバ前に、ＵＥ１が保持していたＰＤＮＴｙｐｅと一致している場合は、特別な処理をせず、従来通りハンドオーバ後の処理を行う。一方、ハンドオーバ前のＰＤＮＴｙｐｅと異なる場合、つまりハンドオーバ前にＵＥ１はＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを持っていたが、ハンドオーバ後にはＩＰｖ６ＰＤＮＴｙｐｅなどのシングルアドレスコネクションタイプが割り当てられた場合、接続制御部１０６はｅＰＤＧ８のアドレスを探索するため、ＤＮＳクライアント処理部１０５に指示する（ステップＳ１５１１）。

　ｅＰＤＧ８のアドレスを取得したＵＥ１は、ＰＤＮを経由してｅＰＤＧ８にアクセスし、ＰＧＷ５とＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立する処理を開始する。まず、ＵＥ１はＰＤＮを経由してｅＰＤＧ８へ送信するIKEv2 Authentication and Tunnel SetupメッセージのパラメータであるPDN TypeをＩＰｖ４ｖ６ＰＤＮＴｙｐｅにセットしてメッセージを作成するように、ＵＥ１内に構成される接続制御部１０６からパケット処理部１０２へ指示する（ステップＳ１５１２）。さらに、同メッセージのパラメータであるRequest Typeに“handover”、維持し続けたいＩＰアドレスをIP Addressフィールド、維持し続けたいベアラがあれば、そのベアラに対応するBearer IDをBearer IDフィールド、そしてこれらのパラメータをＰＧＷ５が持つＥＰＳベアラコンテキストで更新することを指示するIndicationをRenew Indicationフィールドにセットするように接続制御部１０６からパケット処理部１０２へ指示する（ステップＳ１５１３～ステップＳ１５１６）。その後、ＵＥは各パラメータがセットされたIKEv2 Authentication and Tunnel SetupメッセージをｅＰＤＧ８に送信する（ステップＳ１５１７）。なお、ステップＳ１５１２からステップＳ１５１６の処理する順番は入れ替わってもよい。また、ステップＳ１５１２からステップＳ１５１５で用いるパラメータがｅＰＤＧ８に通知できれば、IKEv2 Authentication and Tunnel Setupメッセージでなくてもよい。なお、上記説明ではRequest Typeに“handover”をセットすると記載したが、ＵＥが維持したいＩＰアドレスをIP Addressフィールドにセットすることで代用してもよい。すなわち、ＵＥが維持したいIPアドレスをIP Addressフィールドにセットすることで、ハンドオーバを指示してもよい。

　ネットワーク側は、オペレータ方針と、ＵＥ１から送信されたIKEv2 Authentication and Tunnel Setupメッセージに基づいて、ＥＰＳベアラコンテキスト内のＰＤＮコネクションのＰＤＮＴｙｐｅをＩＰｖ６ＰＤＮからＩＰｖ４ｖ６に変更する。ＥＰＳベアラコンテキストの更新処理を終えたＰＧＷ５は、更新結果をＰＢＡメッセージとしてｅＰＤＧ８へ返信し、最終的にＰＤＮ経由でｅＰＤＧ８からIKEv2メッセージとしてＵＥ１に返信される（ステップＳ１５１７）。この結果、ＵＥ１はＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを持ち、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを保持している状態で、シングルアドレスタイプネットワークにハンドオーバした際も、ハンドオーバ前のＰＤＮコネクション状態を維持したまま、通信可能となる。

　次に、図４に図示されている構成を有するＰＧＷ５の処理フローについて、本発明における特徴的な処理を実施する接続制御部５０６に係る処理を中心に、図２０を用いて詳しく説明する。なお、ＰＧＷ５は、既に通信部５０１を介し、３Ｇアクセス２に接続済みであるものとする。加えて、ＰＧＷ５は、既にＩＰｖ４ｖ６ＰＤＮＴｙｐｅコネクションを確立しているＵＥ１とパケットの送受信を行っている状態とする。またＵＥ１は、シングルアドレスタイプネットワークにハンドオーバを行うものとする。

　図２０は、本発明の第３の実施の形態（更には、後述の第４の実施の形態）におけるＰＧＷ５の処理フローの一例を示すフロー図である。最初に、ＰＧＷ５はｅＮＢの判断によって起こるＵＥ１のハンドオーバに関するメッセージを通信部５０１から受信する。その後、パケット処理部５０２を介して、ＰＧＷ５はハンドオーバ処理部５０３によって、ＵＥ１のハンドオーバを処理し、ＵＥ１に関する位置情報を更新する（ステップＳ４５０１：Inter RATハンドオーバ）。なお、ハンドオーバ処理中にＵＥ１から割り当てられないＩＰｖ４ＨｏＡを他ＵＥ１に割り当てないような指示がある場合には、ＰＧＷ５はそのＩＰｖ４アドレスは他ＵＥ１に割り当てずに一時的に保持する。

　なお、本発明の第３及び第４の実施の形態におけるＰＧＷ５の処理フローを１つの図にまとめている都合上、ステップＳ４５０２の処理も図示されている。このステップＳ４５０２の処理は、本発明の第３の実施の形態では実行されず、後述の第４の実施の形態においてのみ実行されるものである。したがって、本発明の第３の実施の形態では、上記ステップＳ４５０１の処理後、ステップＳ４５０２は行われずに、続くステップＳ４５０３が実行される。

　その後、ＰＧＷ５は、ｅＰＤＧ８から送られてくるＵＥ１のＰＤＮコネクション維持を目的としたメッセージを含むＰＢＵメッセージを通信部５０１で受信する（ステップＳ４５０３）。ＰＢＵメッセージを受信したＰＧＷ５は、ＰＢＵメッセージ内にＵＥ１のＥＰＳベアラコンテキストを更新することを示すRenew Indicationが格納されているか否かについて、パケット処理部５０２を介してＰＤＮコネクション確立処理部５０４へ転送して、確認する（ステップＳ４５０４）。

　Renew Indicationが格納されていない場合は、ＰＧＷ５は特に処理せずに一般的なＰＤＮコネクションリクエストだと判断し、従来通りの処理を実施する。一方、Renew Indicationが格納されている場合、ＰＧＷ５は接続制御部５０６からパケット処理部５０２へＰＣＲＦとIP-CAN Session Establishment Procedureを実施するように指示し、実施する（ステップＳ４５１１）。続いて、ＰＧＷ５は、前記ステップＳ４５０３で受信したＰＢＵメッセージ内に格納されているＰＤＮＴｙｐｅとＩＰｖ４ＨｏＡ、格納されている場合はBearer IDを所定のフィールドから取り出す（ステップＳ４５１２～ステップＳ４５１４）。なお、ステップＳ４５１２からステップＳ４５１４の処理する順番は、入れ替わってもよい。

　その後、ＰＧＷ５はＰＢＵメッセージから取り出したＰＤＮＴｙｐｅとＩＰｖ４ＨｏＡ、Bearer IDを、ＰＧＷ５自身が持つＰ－ＧＷコンテキストに追加して更新する（ステップＳ４５１５）。続いて、ＰＧＷ５は、ＡＡＡ／ＨＳＳサーバにＰＧＷ識別子（PGW Identity）と、ＵＥ１のＰＤＮコネクションに関連するＡＰＮを送信する。この送信した情報は、ＨＳＳで登録される（ステップＳ４５１６）。続いて、ＰＧＷ５はｅＰＤＧ８から送られてきたＰＢＵメッセージの処理した結果を、ＰＢＡメッセージ内に格納し、ｅＰＤＧ８に送信する（ステップＳ４５１７）。なお、前記ステップＳ４５１５で行ったＰ－ＧＷコンテキストの更新処理は、前記ステップＳ４５１６終了後に行ってもよい。この結果、ＰＧＷ５はＵＥ１に対して、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立することとなる。

　次に、図６に図示されている構成を有するｅＰＤＧ８の処理フローについて、本発明における特徴的な処理を実施する接続制御部８０６に係る処理を中心に、図１６を用いて詳しく説明する。なお、ｅＰＤＧ８は、既に通信部を介し、コアネットワーク４を介してＰＧＷ５と接続済みであり、ＵＥ１のＰＤＮコネクションリクエストを含むパケットの送受信可能な状態であるものとする。また、その状態で、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを持つＵＥ１がシングルアドレスタイプネットワークにハンドオーバを行うものとする。

　図１６は、本発明の第３の実施の形態におけるｅＰＤＧ８の処理フローの一例を示すフロー図である。最初に、ＵＥ１がＩＰｖ４ｖ６ＰＤＮＴｙｐｅを持ち、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信を行っている状態で、シングルアドレスタイプネットワークにハンドオーバしたとき、ハンドオーバ前における通信状態の維持を目的とした処理を実施することで、ＰＤＮ経由で送られてくるIKEv2 Authentication and Tunnel SetupメッセージをｅＰＤＧ８が持つ通信部８０１で受信する（ステップＳ３５０１）。

　通信部８０１で受信したメッセージは、通信部８０１からパケット処理部８０２を介して、メッセージ判断部８０５へ転送され、送られてきたＰＢＵメッセージがどのようなメッセージであるか判断する（ステップＳ３５０２）。なお、ＵＥ１は、IKEv2 Authentication and Tunnel Setupメッセージではなく、新規メッセージなどを用いてＵＥのＰＤＮコネクションリクエスト情報（例えば、ＰＤＮＴｙｐｅなど）を通知する場合もあり、どのようなメッセージであるか判断する必要がある。

　受信したメッセージが、ＰＤＮコネクションリクエストに関するメッセージだと判断された場合は、メッセージ判断部８０５から接続制御部８０６を介してパケット処理部８０２へ転送し、ＰＢＵメッセージを作成する（ステップＳ３５１１）。ＰＢＵメッセージに格納されるパラメータは、ステップＳ３５１１のIKEv2 Authentication and Tunnel Setupメッセージに格納されていたパラメータ（例えば、ＰＤＮＴｙｐｅやＡＰＮなど）と基本的には同じであるが、ｅＰＤＧ８が特別に格納したいパラメータがある場合は、格納できるようにする。

　作成したＰＢＵメッセージは、パケット処理部８０２から通信部８０１に転送され、ＰＧＷ５に送信される（ステップＳ３５１２）。その後、ＰＢＵメッセージの返信であるＰＢＡメッセージを通信部８０１で受信する（ステップＳ３５１３）。受信したＰＢＡメッセージは、通信部８０１からパケット処理部８０２を介して、接続制御部８０６へ転送される。続いて、ＰＢＵメッセージが正常に処理されているかどうかをＰＢＡメッセージから確認する（ステップＳ３５２１）。正常に終了されていたら、接続制御部８０６からパケット処理部８０２にＩＫＥｖ２メッセージを作成するように指示し、ＩＫＥｖ２メッセージを作成する（ステップＳ３５２２）。ＩＫＥｖ２メッセージを作成後、パケット処理部８０２から通信部８０１を介して、ＩＫＥｖ２メッセージの返信としてＩＫＥｖ２メッセージをＰＤＮ経由でＵＥ１に送信する（ステップＳ３５２３）。

　また、ＵＥ１とｅＰＤＧ８間にパケットを送受信できる通信経路が確立されている場合（例えば、ＵｎｔｒｕｓｔｅｄＮ３Ｇアクセス３）、ＰＤＮ経由でＵＥ１にＩＫＥｖ２メッセージを送信する前に、ルート判断部８０３にｅＰＤＧ８から直接ＵＥ１にパケットを送信するのか、ＰＤＮ経由でＵＥ１にパケットを送信するのか問い合わせてから、ＩＫＥｖ２メッセージを送信するルートを決めてもよい。ＩＫＥｖ２メッセージ送信の最適なルートを選択することによって、ＰＧＷ５を含む３Ｇアクセス２で機能する装置の処理負荷軽減や、パケットの伝送時間が短縮される可能性がある。

　第３の実施の形態に基づいて処理することで、ＵＥ１はＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを持ち、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを保持している状態で、ＵＥ１がシングルアドレスタイプネットワークにハンドオーバしたとき、オペレータ方針に依存せずにハンドオーバ前に保持していたＩＰアドレス（ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡに相当）を維持することができる。つまり、第３の実施の形態では、ＵＥ１は、ＩＰｖ４ＨｏＡが放棄されず、そしてＩＰｖ４ＨｏＡ宛てのパケットが放棄されずにシングルアドレスタイプネットワークにハンドオーバすることができる。これにより、ＵＥ１はハンドオーバ前から受信していたパケットをハンドオーバ後のネットワークでも受信することが可能となり、改めてマルチアドレスタイプコネクション対応ネットワークへＵＥ１がハンドオーバする際も特別な処理を実施せずに、ＩＰｖ４ｖ６ＰＤＮコネクションを維持し、さらにＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを維持することができる。

　＜第４の実施の形態＞
　以下、本発明の第４の実施の形態におけるシステム動作の一例について、図１８を用いて詳しく説明する。図１８は、本発明の第４の実施の形態におけるシステム動作の一例を説明するためのシーケンス図である。なお、図１８では、ＵＥ１はＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを持ち、そのＰＤＮコネクションにおいてＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信をしている状態で、かつ、ＵＥ１がシングルアドレスタイプネットワークにハンドオーバした結果、ＩＰｖ６ＰＤＮＴｙｐｅが割り当てられることを想定している。また、ＵＥ１がハンドオーバ前に取得したＩＰｖ４ＨｏＡを維持することにより、ＩＰｖ４ＨｏＡ宛てのパケットを引き続き送受信可能にするためのシーケンスが図示されている。

　図１８には、ＵＥ１、ＵＥ１と直接的にパケットの送受信を行うｅＮｏｄｅＢ（ｅＮＢ）、ＵＥ１の移動管理を担当するＭＭＥ７、ｅＮＢ間のユーザデータ経路制御を行うＳＧＷ６、ＳＧＷ６間のユーザデータ経路制御を行い、ＰＤＮへのゲートウェイの役割を担いＵＥの位置情報を管理するＰＧＷ（移動管理ゲートウェイとも称する）５、ＵｎｔｒｕｓｔｅｄＮ３Ｇアクセス３におけるＰＤＮコネクションを確立するための構成要素であるｅＰＤＧ（evolved Packet Data Gateway；パケットデータゲートウェイとも称する）８、ＵＥ１の課金コントロールなどを管理しているＰＣＲＦ（Policy Charging Rules Function）、ＵＥ１による各アクセスネットワーク使用を許可してもよいかを判断する認証サーバであるＡＡＡ（Authentication, authorization and Accounting）サーバ、及びＵＥ１のサブスクリプション情報などを保持管理するＨＳＳ（Home Subscriber Server）で構成されるシステムの動作の一例のシーケンスが図示されている。なお、各機能を代わりに担うことができる構成要素が存在する場合には、それらを用いてもよい。また、ＡＡＡサーバとＨＳＳは、物理的又は論理的に同一の装置に実装されるものであってもよく、以降、ＡＡＡサーバとＨＳＳを説明の都合上まとめてＡＡＡ／ＨＳＳと呼ぶこともある。

　ＵＥ１がｅＮＢのカバーするパケット転送エリアを超えそうになる場合、又はｅＮＢがオペレータ方針に基づいて異なるｅＮＢをＵＥ１に割り当てる場合に（例えば、ＵＥ１に適したｅＮＢの検知など）、ｅＮＢは新しいｅＮＢをＵＥ１に割り当てるためにハンドオーバ処理を開始する。

　ＵＥ１は、ハンドオーバ前にＰＧＷ５とＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立しており、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信を行っているが、シングルアドレスタイプネットワークにハンドオーバした結果、ハンドオーバ先のネットワークのオペレータ方針に基づいてＩＰｖ４ｖ６ＰＤＮＴｙｐｅからＩＰｖ６ＰＤＮＴｙｐｅに変更される。つまり、ＵＥ１がハンドオーバ前に使用していたＩＰｖ４ＨｏＡが破棄され、ＩＰｖ４ＨｏＡ宛てのパケットが転送されなくなる。また、ＵＥはＩＰｖ４ＨｏＡをソースアドレスとしたパケットをネットワーク側に送信できなくなる（ステップＳ４０１：Inter RATハンドオーバ）。また、前記Inter RAT ハンドオーバ処理中に、ＵＥ１がＰＧＷ５に対して、ＵＥ１がハンドオーバ前に使用していたＩＰｖ４ＨｏＡを一定期間廃棄しないように指示してもよい。ＵＥ１が、この指示をすることで、そのＩＰｖ４ＨｏＡがＵＥ１に割り当てられない期間に、確実に他の端末などにそのアドレスを割り当てないようになる。

　なお、第４の実施の形態の説明では、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションがＩＰｖ６ＰＤＮコネクションに変更され、ＩＰｖ６ＨｏＡ宛てのパケットのみが転送される場合について説明するが、ＩＰｖ４ｖ６ＰＤＮコネクションが、オペレータ方針によってはＩＰｖ４ＰＤＮＴｙｐｅのＰＤＮコネクションに変更され、ＩＰｖ４ＨｏＡ宛てのパケットのみが転送される場合も考えられる。このような場合においても、本発明は適用可能であり、本実施の形態において説明する方法と同様の方法により、所望の目的を達することができる。

　ステップＳ４０１でハンドオーバ（例えばＩｎｔｅｒＲＡＴハンドオーバ）した後、ＰＤＮＴｙｐｅが変更されたことを検知したＵＥ１は、ハンドオーバ前に使用していたＩＰｖ４ＨｏＡを用いたパケットの送受信を継続させることを目的とした処理を実施するために、仮のＰＤＮコネクション（以降、仮ＰＤＮコネクションとも呼ぶ）を確立する。この仮のＰＤＮコネクションは、ＵＥ１のハンドオーバ前の通信状態をマッピングするために確立される。つまり、ハンドオーバ前の通信状態を維持するために確立される。

　ここで、ＵＥ１は、ハンドオーバ処理の過程でＰＤＮＴｙｐｅの変更通知を受けてＰＤＮＴｙｐｅの変更を検知してもよいし、ハンドオーバによってＩＰｖ４ＨｏＡを用いた通信に使用していたＥＰＳベアラが確立されなかったことを契機としてＰＤＮＴｙｐｅの変更（すなわちＩＰｖ４アドレスの割り当てが許可されなかったこと）を検知してもよい。あるいは、ハンドオーバ直後にＩＰｖ４ＨｏＡを用いたパケットの送信を行い、失敗した場合にＰＤＮＴｙｐｅの変更（すなわちＩＰｖ４アドレスの割り当てが許可されなかったこと）を検知してもよいし、ＩＰｖ４ＨｏＡ宛のパケットが一定期間受信されなかったことを契機にＰＤＮＴｙｐｅの変更を検知してもよい。

　ＵＥ１は、ハンドオーバによって確立されたＩＰｖ６ＰＤＮコネクションとは別に、ＩＰｖ６ＰＤＮＴｙｐｅの仮ＰＤＮコネクションを確立する（ステップＳ４０２：UE requested PDN Connectivity Procedure）。そして、仮ＰＤＮコネクション確立時に取得したＩＰｖ６プレフィクスから、ＩＰｖ６アドレスを生成する（ステップＳ４０３：ＩＰアドレス生成）。ステップＳ４０２におけるUE requested PDN Connectivity Procedure実施後、ＵＥ１は、ハンドオーバ前に使用していたＩＰｖ４ＨｏＡ宛てのパケットを受信することを目的とした処理を実施するために、ｅＰＤＧ８を探索する。例えばＤＮＳサーバ９にｅＰＤＧ８のアドレスを問い合わせる（ステップ４０４：ePDG Discovery）。なお、ここではｅＰＤＧ８のアドレスを取得するためにＤＮＳサーバ９に問い合わせているが、ＵＥ１がＮ３Ｇアクセス３に接続していたときにｅＰＤＧ８のアドレスを記憶しておき、そのアドレス情報を再利用などしてもよいし、あらかじめｅＰＤＧ８の情報を保持しておいてそれを利用してもよい（例えばＳＩＭカードやＲＯＭ内にあらかじめ登録しておくなど）。

　なお、ｅＰＤＧ８を用いる理由は、ｅＰＤＧ８はＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立できる機能を実装しており、現状のコアネットワークに存在する構成要素に対しての新機能の追加が不要あるいは最小限で済む点にある。なお、ｅＰＤＧ８同等の変更で済む場合や、既に同等の機能を有している場合には、ｅＰＤＧ８の代わりに他の構成要素を用いてもよい。

　ｅＰＤＧ８のアドレスを取得したＵＥ１は、３Ｇアクセス２上でＰＧＷ５を経由し、さらにＰＤＮを経由してｅＰＤＧ８とIKEv2 Authentication and Tunnel Setupを行う（ステップＳ４０５：IKEv2 Authentication and Tunnel Setup）。なお、本ステップＳ４０５は、要求されるセキュリティレベルによっては省略することも可能である。なぜなら、本ステップＳ４０５は、従来のＵｎｔｒｕｓｔｅｄＮ３ＧアクセスにおけるＵＥ１とｅＰＤＧ８間で交換されるメッセージの保護を目的としているが、第４の実施の形態ではｅＰＤＧ８からＰＤＮ経由でＵＥとメッセージを交換するため一定のセキュリティが確保されるからである。あるいは、本ステップＳ４０５によってネゴシエートされる暗号・認証プロトコルとしてヌル（ｎｕｌｌ）暗号を採択させてもよい。これも上記の理由に基づくものであり、既にＵＥ１はセキュリティの確保された３Ｇアクセス２からｅＰＤＧ８にアクセスしているので、更なるセキュリティ処理を省略させることにより、ＵＥ１並びにｅＰＤＧ８などのネットワーク装置の負荷を低減することができる。

　ＵＥ１は、IKEv2 Authentication and Tunnel SetupにおいてｅＰＤＧ８へ送るメッセージに、ＵＥ１がハンドオーバ前の状態の維持を要求することを示すために、ＥＰＳベアラコンテキストの更新要求を示すRenew Indication、ハンドオーバ前のＰＤＮＴｙｐｅ（すなわちＩＰｖ４ｖ６ＰＤＮＴｙｐｅ）、ハンドオーバ後のＰＤＮコネクションには引き継がれていなかったＩＰｖ４ＨｏＡと引き継がれていたＩＰｖ６プレフィクスをメッセージに含めて送信する。さらに、ＵＥ１は、ベアラ単位で維持したい場合には、そのベアラに対応するBearer IDを追加し、ｅＰＤＧ８に送信する。

　なお、ＵＥ１は、IKEv2 Authentication and Tunnel Setup処理中にｅＰＤＧ８へ送るメッセージ以外に、上記パラメータをｅＰＤＧ８へ通知する手段があれば、他のメッセージを用いてもよい。その一例として、ＩＫＥｖ２プロトコルのＣＦＧリクエストでは、ＩＰｖ４、若しくはＩＰｖ６アドレスを要求することができるので、ＣＦＧリクエストメッセージの中でＩＰアドレスタイプを指定し、そこからＰＤＮＴｙｐｅを通知してもよい。また、例えばＰＤＮＴｙｐｅがメッセージに格納されていれば、ＥＰＳベアラコンテキストの更新要求を指示するとｅＰＤＧ８へ伝えることができる。その場合には、Renew Indicationを格納する必要はない。さらには、上記パラメータのうち、特に、従来ｅＰＤＧ８に送付することのなかったRenew IndicationやBearer IDについては、ＵＥ１とＰＧＷ５間で情報交換するためのＰＣＯを用いて直接ＰＧＷ５に通知してもよい。

　図１８のステップＳ４０５においてＵＥ１がｅＰＤＧ８に送るIKEv2 Authentication and Tunnel Setupにおけるメッセージのフォーマットは、上述した図１４Ａに図示されているメッセージのフォーマットを用いることが可能である。すなわち、ＵＥ１は、従来の標準的なIKEv2 Authentication and Tunnel Setupにおいて送信するメッセージ３００１に加えて、Renew Indicationフィールド３００２、PDN Typeフィールド３００３、IP Addressフィールド３００４、及びBearer IDフィールド３００５を設け、それぞれ所定の値をｅＰＤＧ８に通知することができる。なお、本メッセージは、所定の情報を転送できるものであれば上記したフィールド以外のフィールドを用いてもよい。例えば、Renew Indicationフィールドの代わりに一般的なＩＫＥｖ２メッセージのHandover Indicationフィールドを使用してもよい。また、PDN TypeフィールドやIP Addressフィールドの代わりに、一般的なＩＫＥｖ２メッセージのＣＦＧリクエストにＰＤＮＴｙｐｅやＩＰｖ４ＨｏＡ、ＩＰｖ６プレフィクスを格納してもよい。

　続いて、ｅＰＤＧ８は、ＰＧＷ５情報の取得、ＵＥ１の認証などを行うために、ＡＡＡ／ＨＳＳとAuthentication and Authorizationを実施する（ステップＳ４０６：Authentication and Authorization）。その後、ｅＰＤＧ８はＰＧＷ５に対して、ハンドオーバインディケータ（HO Indicator）やＡＴＴなど通知するためにＰＢＵメッセージを送信する（ステップＳ４０７：Proxy Binding Update）。なお、ｅＰＤＧ８は本来、ＵＥ１がＮ３Ｇアクセス３を利用するときに用いられるコアネットワーク４内に位置する装置であるが、第４の実施の形態のように３Ｇアクセス２を用いながらＰＤＮ経由でｅＰＤＧ８にハンドオーバ処理などをする際は、例えば、ＡＴＴに３ＧＩＰアドレスに対応する値をセットする必要がある。

　図１８のステップＳ４０７においてｅＰＤＧ８がＰＧＷ５に送るＰＢＵメッセージのフォーマットは、上述した図１４Ｂに図示されているメッセージのフォーマットを用いることが可能である。すなわち、ｅＰＤＧ８は、従来の標準的なＰＢＵメッセージ３１０１に対してRenew Indicationフィールド３１０２、PDN Typeフィールド３１０３、IP Addressフィールド３０１４、及びBearer IDフィールド３１０５を加え、それぞれ所定の値をＰＧＷ５に通知することができる。

　Renew Indicationフィールド３１０２には、ＰＧＷ５が持つＥＰＳベアラコンテキストで、ＵＥ１のＰＤＮコネクション情報更新を示す値が格納される。PDN Typeフィールド３１０３には、ＵＥ１がリクエストするＰＤＮＴｙｐｅ（すなわちＩＰｖ４ｖ６ＰＤＮＴｙｐｅ）が格納される。IP Addressフィールド３１０４には、ＵＥ１がハンドオーバした際、ハンドオーバ前に割り当てられていたＩＰアドレスを格納する（すなわち、ＩＰｖ４ＨｏＡ、ＩＰｖ６プレフィクス）。Bearer IDフィールド３１０５には、ＵＥ１がベアラ毎に維持したいか否かについて判断した結果、維持したいベアラが存在する場合に、そのベアラに対応するBearer IDが格納される。これらの情報を基に、ＰＧＷ５は、ＰＧＷ５自身が持つＥＰＳベアラコンテキストを更新する。

　なお、新規に追加するそれぞれの値を従来の標準的なＰＢＵメッセージにあるAdditional Parameterフィールドに格納してもよい。例えば、Renew Indicationフィールド３１０２の代わりにＰＢＵメッセージのAdditional Parameterフィールドを使用してもよい。PDN Typeフィールド、IP Addressフィールド、Bearer IDフィールドも同様である。また、本メッセージは、所定の情報を転送できるものであればＰＢＵメッセージ以外のメッセージであってもよい。

　続いて、ＰＧＷ５はＰＣＲＦとIP-CAN Session Establishment Procedureを実施する（ステップＳ４０８：IP-CAN Session Establishment Procedure）。続いて、ＰＧＷ５は、ＵＥ１が持つＰＤＮコネクションに関連するＰＧＷ５の識別子（PGW Identity）とＡＰＮをＡＡＡ／ＨＳＳに通知するために、Update PGW Addressメッセージ交換を行う（ステップＳ４０９：Update PGW Address）。続いて、ＰＧＷ５はｅＰＤＧ８から送られてきたＰＢＵメッセージに格納されている情報に基づいてＢＣＥを作成し、ＵＥ１に割り当てるＩＰアドレス（ＩＰｖ４ＨｏＡ、ＩＰｖ６ホームプレフィクスに相当）などが格納されたＰＢＡメッセージをｅＰＤＧ８に返信する（ステップＳ４１０：Proxy Binding Ack）。続いて、ｅＰＤＧ８は、ＰＢＡメッセージを受信し、ＰＧＷ５におけるバインディング処理が成功したと判断したら、ＵＥ１とのトンネルセットアップを完了する（ステップＳ４１１：IPSec Tunnel Setup Completion）。続いて、ｅＰＤＧ８は、ＵＥ１に割り当てるＩＰアドレスやＰＤＮに関連する識別子（Identity）などを格納したＩＫＥｖ２の完了メッセージをＰＤＮ経由でＵＥ１に送信する（ステップＳ４１２：IKEv2（IP Address Configuration））。

　ステップＳ４１２の完了後、ＵＥ１とｅＰＤＧ８間でＩＰｓｅｃトンネルが確立される。また、ｅＰＤＧ８とＰＧＷ５間でＰＭＩＰトンネルが確立される（ＧＴＰプロトコルが適用される場合はＧＴＰトンネル）。これにより、ＵＥ１はｅＰＤＧ８経由でＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立して、ハンドオーバ前に割り当てられていたＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡ（ホームプレフィクス）を維持できるようになり、セッションを継続することができる（ステップＳ４１３：IPSec and PMIPv6 Tunnels）。

　ここで、先にハンドオーバによって確立されたＰＤＮコネクション（ＩＰｖ６ＰＤＮＴｙｐｅのＰＤＮコネクション、以降、本ＰＤＮコネクション１とも呼ぶ）を用いずに、仮のＰＤＮコネクション（以降、仮ＰＤＮコネクションとも呼ぶ）を確立する目的は、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅの本ＰＤＮコネクションを確実に確立させることにある（第１の目的）。例えば、本ＰＤＮコネクション上にｅＰＤＧ８経由で同じ本ＰＤＮコネクションを確立しようとすると、ＰＧＷ５は、当初のハンドオーバによって直接ＰＧＷ５と確立した本ＰＤＮコネクション（以降、ベースコネクションと呼ぶ）を、ｅＰＤＧ８経由で確立中のＰＤＮコネクションにハンドオーバさせる処理を開始するため、結果としてベースコネクションが解放され、ｅＰＤＧ８経由の本ＰＤＮコネクションも事実上解放あるいは利用できない状態でリソースだけが残ることになり、極めて非効率な結果を招くことになる。

　また、別の目的として、仮ＰＤＮコネクション上にｅＰＤＧ８経由で本ＰＤＮコネクションを確立することによって生成されるＩＰトンネル（ＩＰｓｅｃトンネル）の内側アドレスと外側アドレスの重複を回避することにある（第２の目的）。例えば、本ＰＤＮコネクション上にｅＰＤＧ８経由で同じ本ＰＤＮコネクションを確立しようとすると、ＩＰトンネルの内側アドレスと外側アドレスに同一のＩＰｖ６アドレスを適用することになり、ＵＥ１並びにＰＧＷ５においてパケット送受信の際に混乱を生じさせることになる。

　ここで、第１の目的において説明した問題が解決される場合、例えば、ｅＰＤＧ８経由で本ＰＤＮコネクションを確立できた場合に、ベースコネクションの解放を抑制することができる場合は（例えば、ＰＧＷ５やＵＥ１によるＥＰＳベアラリリースを停止させ、かつＰＧＷ５が管理するＢＣに、当該ＰＤＮコネクションに対してＳＧＷ６とｅＰＤＧ８のそれぞれに関する２つのＢＣＥを登録させる）、ＵＥ１に割り当てられたＩＰｖ６プレフィクスから異なるＩＰｖ６アドレス（さらには、これまでの通信において使用していないか、先の使用から十分な時間が経過するなど、セッションが既に完了していると判断できるもの）を生成して、それをベースコネクション上でｅＰＤＧ８とＩＰトンネルを確立する際のローカルアドレスとして使用する。これにより、ＩＰトンネルの内外アドレスの重複を回避することができ、１つのＰＤＮコネクション（本ＰＤＮコネクション）だけで、所望の目的を達成することができ、消費リソース（ベアラリソース、アドレス資源など）の低減を図ることができる。なお、このとき、ＵＥ１とＰＧＷ５においてパケットのルーティングについて留意することとしては、ベースコネクションに適用するＩＰｖ６アドレスを用いたパケットは、ベースコネクションを通じて送信されるようにルーティングテーブルを設定することである（例えば、ＰＧＷ５においてはホストエントリを設定、ＵＥ１においてはソースルーティング設定を行う）。それ以外のＩＰｖ６プレフィクスに対しては、ｅＰＤＧ８経由の本ＰＤＮコネクションを通じて送信されるよう設定する（あるいはデフォルト設定を本ＰＤＮコネクション向けに設定することで、当該ＩＰｖ６プレフィクス向けの設定を割愛してもよい）。また、ＰＧＷ５においては、当該ＩＰｖ６プレフィクスに対する課金を、ベースコネクションとそれ以外で区別してもよい。すなわち、ベースコネクションに適用したＩＰｖ６アドレスと、それ以外で課金などの用途で実施しているパケットカウントを区別してもよい。

　次に、図３に図示されている構成を有するＵＥ１の処理フローについて、本発明における特徴的な処理を実施する接続制御部１０６に係る処理を中心に、図１９を用いて詳しく説明する。なお、ＵＥ１は、既に第１無線通信部１０１により３Ｇアクセス２を介して、ＰＧＷ５と接続済みであるものとする。なお、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクション、すなわちマルチアドレスタイプコネクションを確立済みの状態で、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信可能な状態であるものとする。さらに、その状態でＵＥ１はシングルアドレスタイプコネクションにのみ対応するネットワーク（シングルアドレスタイプコネクションのネットワーク）にハンドオーバを行うものとする。

　図１９は、本発明の第４の実施の形態におけるＵＥの処理フローの一例を示すフロー図である。最初に、ＵＥ１はｅＮＢの判断により生じるハンドオーバに関する情報を第１無線通信部１０１から受信する。その後、ＵＥ１は、パケット処理部１０２を経由してハンドオーバ判断部１０３に転送され、ハンドオーバ判断部１０３によって、ハンドオーバがされたことを検知する。なお、ＵＥ１は、ハンドオーバに関する情報を接続制御部１０６経由でハンドオーバ判断部１０３に転送し、ハンドオーバが生じたことを検知してもよい（ステップＳ４００１：Inter RATハンドオーバ）。

　ハンドオーバ処理が実施されたことを確認した後、接続制御部１０６は、ハンドオーバしたことによってネットワークから割り当てられたＰＤＮＴｙｐｅがハンドオーバ前のＰＤＮ　Ｔｙｐｅ（ＩＰｖ４ｖ６ＰＤＮＴｙｐｅ）と一致しているかＰＤＮＴｙｐｅ判断部１０４に確認指示をする。今回は、ＵＥ１がハンドオーバ前にマルチアドレスタイプコネクション（ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクション）を確立済みであるため、シングルアドレスコネクション（ＩＰｖ６（ＩＰｖ４）ＰＤＮＴｙｐｅのＰＤＮコネクション）に変更されていないか確認する（ステップＳ４００２）。

　ハンドオーバ前に、ＵＥ１が保持していたＰＤＮＴｙｐｅと一致している場合は、特別な処理をせず、従来通りハンドオーバ後の処理を行う。一方、ハンドオーバ前のＰＤＮＴｙｐｅと異なる場合、つまりハンドオーバ前にＵＥ１はＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを持っていたが、ハンドオーバ後にはＩＰｖ６ＰＤＮＴｙｐｅなどのシングルアドレスタイプコネクションが割り当てられた場合、仮のＰＤＮコネクション確立リクエストであるUE requested PDN Connectivity Procedureを実施するためにパケット処理部１０２を介して第１無線通信部１０１を経て、ＰＧＷ５などとメッセージ交換を行う。これにより、ハンドオーバによって確立されたＩＰｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションとは別に新しくＩＰｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立される（ステップＳ４０１１）。

　続いて、ＵＥ１はＰＧＷ５から新しいＩＰｖ６プレフィックスを取得し、ＩＰｖ６アドレスを生成する（ステップＳ４０１２）。ＰＤＮコネクション確立後、ＵＥ１の接続制御部１０６はｅＰＤＧ８のアドレスを探索するため、ＤＮＳクライアント処理部１０５に指示する（ステップＳ４０１３）。なお、他の機能を用いてｅＰＤＧ８のアドレスを取得可能であれば、ＤＮＳクライアント処理部１０５あるいはＤＮＳを利用せずにｅＰＤＧ８のアドレスを取得してもよい。例えば、Ｎ３Ｇアクセス３に接続時に利用していたｅＰＤＧ８のアドレスを記憶しておき、そのｅＰＤＧ８のアドレスを利用してもよい。

　ｅＰＤＧ８のアドレスを取得したＵＥ１は、ＰＤＮを経由してｅＰＤＧ８にアクセスし、ＰＧＷ５とＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立する処理を開始する。まず、ＵＥ１は、ＰＤＮを経由してｅＰＤＧ８へ送信するIKEv２ Authentication and Tunnel SetupメッセージのパラメータであるＰＤＮＴｙｐｅをＩＰｖ４ｖ６ＰＤＮＴｙｐｅにセットしてメッセージ作成するように、ＵＥ１内に構成される接続制御部１０６からパケット処理部１０２へ指示する。さらに、同メッセージのパラメータであるRequest Typeに“handover”、維持し続けたいＩＰアドレスをIP Addressフィールド、維持し続けたいベアラがあれば、そのベアラに対応するBearer IDをBearer IDフィールド、及びこれらのパラメータをＰＧＷ５が持つＥＰＳベアラコンテキストで更新することを指示するIndicationをRenew Indicationフィールドにセットするように接続制御部１０６からパケット処理部１０２へ指示する（ステップＳ４０１４～ステップＳ４０１７）。

　前記パケット処理完了後、ＵＥ１は各パラメータがセットされたIKEv２ Authentication and Tunnel SetupメッセージをｅＰＤＧ８に送信する（ステップＳ４０１８）。なお、ステップＳ４０１４からステップＳ４０１７の処理する順番は入れ替わってもよい。また、ステップＳ４０１４からステップＳ４０１７で用いるパラメータがｅＰＤＧ８に通知できれば、IKEv２ Authentication and Tunnel Setupメッセージ以外の手段を用いてもよい。

　ネットワーク側は、オペレータ方針と、ＵＥ１から送信されたIKEv2 Authentication and Tunnel Setupメッセージに基づいて、ＥＰＳベアラコンテキスト内のＰＤＮコネクションのＰＤＮＴｙｐｅをＩＰｖ６ＰＤＮからＩＰｖ４ｖ６に変更する。また、IKEv２ Authentication and Tunnel SetupメッセージのIP Addressフィールドに格納されていたアドレス（本発明の第４の実施の形態では、ＩＰｖ４ＨｏＡ）を利用可能に変更する。ＥＰＳベアラコンテキストの更新処理を終えたＰＧＷ５は、更新結果をＰＢＡメッセージとしてｅＰＤＧ８へ返信し、最終的にＰＤＮ経由でｅＰＤＧ８からＩＫＥｖ２メッセージとしてＵＥ１に返信される（ステップＳ４０１９）。

　この結果、ＵＥ１はＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを持ち、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを保持している状態で、シングルアドレスタイプネットワークにハンドオーバした際も、ハンドオーバ前のＰＤＮコネクション状態を維持したまま、通信可能となる。

　次に、図４に図示されている構成を有するＰＧＷ５の処理フローについて、本発明における特徴的な処理を実施する接続制御部１０６に係る処理を中心に、図２０を用いて詳しく説明する。なお、ＰＧＷ５は、既に通信部５０１を介し、３Ｇアクセス２に接続済みであるものとする。加えて、ＰＧＷ５は、既にＩＰｖ４ｖ６ＰＤＮＴｙｐｅコネクションを確立しているＵＥ１とパケットの送受信を行っている状態で、ＵＥ１がシングルアドレスタイプネットワークにハンドオーバを行うものとする。

　図２０は、本発明の第４の実施の形態におけるＰＧＷの処理フローの一例を示すフロー図である。なお、以下では、上述の第３の実施の形態を説明した場合と同一の処理フローを参照しながら説明する。最初に、ＰＧＷ５はｅＮＢの判断によって起こるＵＥ１のハンドオーバに関するメッセージを通信部５０１から受信する。その後、パケット処理部５０２を介して、ＰＧＷ５はハンドオーバ処理部５０３によって、ＵＥ１のハンドオーバを処理し、ＵＥ１に関する位置情報を更新する（ステップＳ４５０１：Inter RATハンドオーバ）。なお、ハンドオーバ処理中にＵＥ１から割り当てられないＩＰｖ４ＨｏＡを他ＵＥ１に割り当てないような指示がある場合には、ＰＧＷ５はそのＩＰｖ４アドレスを他ＵＥに割り当てずに一時的に保持する。

　その後、ＰＧＷ５は、ＵＥ１からのＰＤＮコネクション確立リクエストを通信部５０１で受信し、ＰＤＮコネクション確立処理部５０４に転送し、リクエストに応じてＰＤＮコネクションを確立する。本発明の第４の実施の形態では、ＵＥ１と新たにＩＰｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立する（ステップＳ４５０２）。

　その後、ＰＧＷ５は、ｅＰＤＧ８から送られてくるＵＥ１のＰＤＮコネクション維持の要求を含むＰＢＵメッセージを通信部５０１で受信する（ステップＳ４５０３）。ＰＢＵメッセージを受信したＰＧＷ５は、ＰＢＵメッセージ内にＵＥ１のＥＰＳベアラコンテキストを更新することを示すRenew Indicationが格納されているか否かについて、ＰＢＵメッセージをパケット処理部５０２を介してＰＤＮコネクション確立処理部５０４に転送し、確認する（ステップＳ４５０４）。

　Renew Indicationが格納されていない場合は、ＰＧＷ５は特別な処理をせずに一般的なＰＤＮコネクションリクエストだと判断し、従来通りの処理を実施する。一方、Renew Indicationが格納されている場合、ＰＧＷ５は接続制御部５０６からパケット処理部５０２へＰＣＲＦとIP-CAN Session Establishment Procedureを実施するように指示し、実施する（ステップＳ４５１１）。続いて、ＰＧＷ５は、前記ステップＳ４５０３で受信したＰＢＵメッセージ内に格納されているＰＤＮＴｙｐｅとＩＰｖ４ＨｏＡ、格納されている場合はBearer IDを所定のフィールドから取り出す（ステップＳ４５１２～ステップＳ４５１４）。なお、ステップＳ４５１２からステップＳ４５１４の処理する順番は、入れ替わってもよい。

　その後、ＰＧＷ５はＰＢＵメッセージから取り出したＰＤＮＴｙｐｅとＩＰｖ４ＨｏＡ、Bearer IDを、ＰＧＷ５自身が持つＵＥ１とのパケット送受信に関するコネクション情報であるＰ－ＧＷコンテキストに追加して更新する（ステップＳ４５１５）。続いて、ＰＧＷ５は、ＡＡＡ／ＨＳＳサーバにＰＧＷ識別子（PGW Identity）と、ＵＥ１のＰＤＮコネクションに関連するＡＰＮを送信する。この送信した情報は、ＨＳＳで登録される（ステップＳ４５１６）。続いて、ＰＧＷ５はｅＰＤＧ８から送られてきたＰＢＵメッセージの処理した結果を、ＰＢＡメッセージ内に格納し、ｅＰＤＧ８に送信する（ステップＳ４５１７）。なお、前記ステップＳ４５１５で行ったＰ－ＧＷコンテキストの更新処理は、前記ステップＳ４５１６終了後に行ってもよい。この結果、ＰＧＷ５はＵＥ１との間にＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを確立することとなる。

　次に、図６に図示されている構成を有するｅＰＤＧ８の処理フローについて、本発明における特徴的な処理を実施する接続制御部８０６に係る処理を中心に、図１６を用いて詳しく説明する。なお、ｅＰＤＧ８は、既に通信部によりコアネットワーク４を介して、ＰＧＷ５と接続済みであり、ＵＥ１のＰＤＮコネクションリクエスト（ＰＤＮコネクション確立リクエスト）を含むパケットの送受信可能な状態であるものとする。また、その状態で、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを持つＵＥ１がシングルアドレスタイプコネクションのネットワークにハンドオーバを行うものとする。

　図１６は、第４の実施の形態におけるｅＰＤＧの処理フローの一例を示すフロー図である。なお、以下では、上述の第３の実施の形態を説明した場合と同一の処理フローを参照しながら説明する。最初に、ＵＥ１がＩＰｖ４ｖ６ＰＤＮＴｙｐｅを持ち、ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを用いてパケットの送受信を行っている状態で、シングルアドレスタイプコネクションネットワークにハンドオーバした場合について説明する。ｅＰＤＧ８は、ハンドオーバ前における通信状態の維持を目的とした処理を実施することで、ＰＤＮ経由で送られてくるIKEv2 Authentication and Tunnel Setupメッセージを通信部８０１で受信する（ステップＳ３５０１）。

　通信部８０１で受信したメッセージは、通信部８０１からパケット処理部８０２を介して、メッセージ判断部８０５へ転送される。次に、メッセージ判断部８０５は送られてきたＰＢＵメッセージがどのようなメッセージであるか判断する（ステップＳ３５０２）。ＵＥ１は、IKEv2 Authentication and Tunnel Setupメッセージではなく、新規メッセージなどを用いてＵＥ１のＰＤＮコネクションリクエスト情報（例えば、ＰＤＮＴｙｐｅなど）を通知する場合もあり、どのようなメッセージであるか判断する必要がある。

　受信したメッセージが、ＰＤＮコネクションリクエストに関するメッセージだと判断された場合は、メッセージ判断部８０５から接続制御部８０６を介してパケット処理部８０２へ転送される。次にパケット処理部はＰＢＵメッセージを作成する（ステップＳ３５１１）。ＰＢＵメッセージに格納されるパラメータは、ステップＳ３５１１のIKEv2 Authentication and Tunnel Setupメッセージに格納されていたパラメータ（例えば、ＰＤＮＴｙｐｅやＡＰＮなど）と基本的には同じであるが、ｅＰＤＧ８が特別に格納したいパラメータがある場合は、そのパラメータが格納され得る。

　作成されたＰＢＵメッセージは、パケット処理部８０２から通信部８０１に転送され、ＰＧＷ５に送信される（ステップＳ３５１２）。その後、ｅＰＤＧ８はＰＢＵメッセージの返信であるＰＢＡメッセージを通信部８０１により受信する（ステップＳ３５１３）。受信したＰＢＡメッセージは、通信部８０１からパケット処理部８０２を介して、接続制御部８０６へ転送される。続いて、ＰＢＵメッセージが正常に処理されているかどうかを受信したＰＢＡメッセージに基づき確認する（ステップＳ３５２１）。正常に終了されていたら、接続制御部８０６からパケット処理部８０２にＩＫＥｖ２メッセージを作成するように指示し、ＩＫＥｖ２メッセージを作成する（ステップＳ３５２２）。ＩＫＥｖ２メッセージを作成後、パケット処理部８０２から通信部８０１を介して、ＩＫＥｖ２メッセージの返信としてＩＫＥｖ２メッセージをＰＤＮ経由でＵＥ１に送信する（ステップＳ３５２３）。

　第４の実施の形態に基づいて処理することで、ＵＥ１はＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを持ち、ＩＰｖ４ｖ６ＰＤＮＴｙｐｅのＰＤＮコネクションを保持している状態で、ＵＥ１がシングルアドレスタイプコネクションネットワークにハンドオーバしたとき、オペレータ方針に依存せずにハンドオーバ前に保持していたＩＰアドレス（ＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡに相当）を維持することができる。つまり、第４の実施の形態では、ＵＥ１は、ＩＰｖ４ＨｏＡが破棄されず、そしてＩＰｖ４ＨｏＡ宛てのパケットが放棄されずにシングルアドレスタイプコネクションネットワークにハンドオーバすることができる。これにより、ＵＥ１はハンドオーバ前から受信していたパケットをハンドオーバ後のネットワークでも受信することが可能となる。また、改めてマルチアドレスタイプコネクション対応ネットワークへＵＥ１がハンドオーバする際も、ＩＰｖ４ｖ６ＰＤＮコネクションを維持し、さらにＩＰｖ４ＨｏＡとＩＰｖ６ＨｏＡを維持することが可能になる。

　なお、本発明の第４の実施の形態において、ハンドオーバ前に割り当てられていたＩＰｖ４ＨｏＡが破棄ないし廃棄されると記載したが、実際には、当該ＩＰｖ４ＨｏＡは、所定の期間は他のＵＥ１に対して割り当てられることなく、実質、当該ＵＥ１に対してプリザーブされた状態のものを指している。したがって、ＵＥ１が再度割り当てを要求することで、ＰＧＷ５によって同一のアドレスがＵＥ１に割り当てられる（再割り当て）。

　また、本発明の第４の実施の形態では、シングルアドレスタイプネットワークにハンドオーバした際の処理についてのみ説明したが、シングルアドレスタイプネットワークからマルチアドレスタイプコネクションネットワークにハンドオーバする際、若しくはＰＤＮコネクションをデタッチ（破棄ないし廃棄）する際、ＵＥ１とＰＧＷ５は、仮のＰＤＮコネクションも含めて、デタッチ処理する必要がある（上記の非特許文献１と非特許文献２を参照）。

　なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

　また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

　さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。

　本発明は、１つ以上の通信インタフェースで複数のＩＰアドレスタイプを用いて、複数の通信経路を確立している移動端末が、単一のＩＰアドレスタイプによる単一の通信経路しか許可されないネットワークにハンドオーバした際にでも、複数のＩＰアドレスタイプを用いて、複数の通信経路を確立することができるようになるという効果を有しており、１つ以上の通信インタフェースで複数のＩＰアドレスタイプを用いて、複数の通信経路を確立している移動端末が、ネットワーク移動する際に用いる技術に適用可能である。

Claims

　複数のＩＰアドレスを用いて複数のパケットデータコネクションを確立可能な移動端末と、前記移動端末とパケットデータコネクションを確立するパケットデータゲートウェイと、前記移動端末とのパケット送受信に関するコネクション情報を管理する移動管理ゲートウェイからなる通信システムにおいて、前記移動端末が、複数のＩＰアドレスタイプを用いたパケット交換コネクションを確立可能なマルチアドレスタイプコネクションネットワークから、単一のＩＰアドレスタイプによる通信経路のみ確立可能なシングルアドレスタイプコネクションネットワークへハンドオーバする際のコネクション管理方法であって、
　前記移動端末が、前記マルチアドレスタイプコネクションネットワークから前記シングルアドレスタイプコネクションネットワークへハンドオーバしたことを検知する検知ステップと、
　前記移動端末が、前記検知ステップの結果に基づき、ハンドオーバ前の通信状態を維持するために仮のコネクションを前記移動管理ゲートウェイと確立する仮コネクション確立ステップと、
　前記移動端末が、前記仮コネクション確立ステップの後、前記仮のコネクションを用いて前記パケットデータゲートウェイにハンドオーバ前のパケットデータコネクションを維持するリクエストを送信するパケットゲートウェイへのリクエスト送信ステップと、
　前記リクエストを受信したパケットデータゲートウェイが、前記受信したリクエストを前記移動管理ゲートウェイに送信するか判断し、送信するリクエストだと判断した場合は前記移動管理ゲートウェイに前記受信したリクエストを送信する移動管理ゲートウェイへのリクエスト送信ステップと、
　前記移動管理ゲートウェイが、前記リクエストに含まれる情報を基に、前記移動端末とのパケット送受信に関するコネクション情報を修正する修正ステップとを、
　有するコネクション管理方法。
　前記検知ステップの後、前記移動端末が、ハンドオーバ前のＰＤＮＴｙｐｅとハンドオーバ後のＰＤＮＴｙｐｅが一致しているか否かを判断し、一致していない場合に前記仮コネクション確立ステップを行う請求項１に記載のコネクション管理方法。
　前記仮コネクション確立ステップは、前記移動端末が現在使用しているアドレスと異なるアドレスを用いて、前記移動管理ゲートウェイとの間に仮のコネクションを確立するものである請求項１に記載のコネクション管理方法。
　前記パケットデータゲートウェイへのリクエスト送信ステップは、前記移動端末が、前記仮のコネクションを用いてパケットデータネットワークを経由して前記パケットデータゲートウェイへのリクエストを送信するものである請求項１に記載のコネクション管理方法。
　前記移動管理ゲートウェイへのリクエスト送信ステップは、前記パケットデータゲートウェイが、前記移動端末から受信したメッセージがＰＤＮコネクション確立リクエストに関するメッセージであると判断した場合に、前記移動管理ゲートウェイへのリクエストを送信するものである請求項１に記載のコネクション管理方法。
　前記修正ステップは、前記移動管理ゲートウェイが、前記パケットゲートウェイから受信したメッセージに含まれるＰＤＮＴｙｐｅに関する情報を基に前記コネクション情報を修正するものである請求項１に記載のコネクション管理方法。
　複数のＩＰアドレスを用いて複数のパケットデータコネクションを確立可能な移動端末と、前記移動端末とパケットデータコネクションを確立するパケットデータゲートウェイと、前記移動端末とのパケット送受信に関するコネクション情報を管理する移動管理ゲートウェイからなるコネクション管理システムであって、
　前記移動端末は、
　前記移動端末が、複数のＩＰアドレスタイプを用いたパケット交換コネクションを確立可能なマルチアドレスタイプコネクションネットワークから、単一のＩＰアドレスタイプによる通信経路のみ確立可能なシングルアドレスタイプコネクションネットワークへハンドオーバしたことを検知する検知手段と、
　前記移動端末が、前記検知手段の結果に基づき、ハンドオーバ前の通信状態を維持するために仮のコネクションを前記移動管理ゲートウェイと確立する仮コネクション確立手段と、
　前記移動端末が、前記仮コネクション確立後、前記仮コネクションを用いて前記パケットデータゲートウェイにハンドオーバ前のパケットデータコネクションを維持するリクエストを送信するパケットゲートウェイへのリクエスト送信手段と、
　を含み、
　前記パケットデータゲートウェイは、
　前記移動端末が送信したリクエストを受信する受信手段と、
　前記受信したリクエストを前記移動管理ゲートウェイに送信するか否かを判断する判断手段と、
　前記判断手段により送信すると判断した場合には、前記移動管理ゲートウェイに前記受信したリクエストを送信する移動管理ゲートウェイへの送信手段と、
　を含み、
　前記前記移動管理ゲートウェイは、
　前記パケットゲートウェイから送信されたリクエストを受信する受信手段と、
　前記受信したリクエストに含まれる情報を基に、前記移動端末とのパケット送受信に関するコネクション情報を修正する修正手段とを、
　有するコネクション管理システム。
　複数のＩＰアドレスを用いて複数のパケットデータコネクションを確立可能な移動端末であって、
　複数のＩＰアドレスタイプを用いたパケット交換コネクションを確立可能なマルチアドレスタイプコネクションネットワークから、単一のＩＰアドレスタイプによる通信経路のみ確立可能なシングルアドレスタイプコネクションネットワークへハンドオーバしたことを検知する検知手段と、
　前記検知手段の結果に基づき、ハンドオーバ前の通信状態を維持するために仮のコネクションを、前記移動端末とのパケット送受信に関するコネクション情報を管理する移動管理ゲートウェイと確立する仮コネクション確立手段と、
　前記仮コネクション確立後、前記仮コネクションを用いて前記移動端末とパケットデータコネクションを確立するパケットデータゲートウェイに対し、ハンドオーバ前のパケットデータコネクションを維持するリクエストを送信するパケットゲートウェイへのリクエスト送信手段とを、
　有する移動端末。
　前記検知手段によるハンドオーバの検知の後、ハンドオーバ前のＰＤＮＴｙｐｅとハンドオーバ後のＰＤＮＴｙｐｅが一致しているか否かを判断し、一致していない場合に前記仮コネクション確立手段により仮コネクションの確立を指示する判断手段をさらに有する請求項８に記載の移動端末。
　前記仮コネクション確立手段は、前記移動端末が現在使用しているアドレスと異なるアドレスを用いて、前記移動管理ゲートウェイとの間に仮のコネクションを確立するものである請求項８に記載の移動端末。
　前記パケットデータゲートウェイへのリクエスト送信手段は、前記移動端末が、前記仮のコネクションを用いてパケットデータネットワークを経由して前記パケットデータゲートウェイへのリクエストを送信するものである請求項８に記載の移動端末。
　前記パケットデータゲートウェイへのリクエスト送信手段は、ハンドオーバ前のパケットデータコネクションを維持するリクエストに、ハンドオーバ前のＰＤＮＴｙｐｅを含める手段をさらに有する請求項８に記載の移動端末。
　前記パケットデータゲートウェイへのリクエスト送信手段は、ハンドオーバ前のパケットデータコネクションを維持するリクエストに、ハンドオーバ前のRenew Indicationを含める手段をさらに有する請求項８に記載の移動端末。
　前記仮コネクション確立手段は、前記仮コネクションを確立する前に、前記移動端末が現在使用しているアドレスと異なるアドレスを取得する手段をさらに有する請求項８に記載の移動端末。
　シングルアドレスタイプコネクションネットワークへハンドオーバする際のメッセージ交換中に、ハンドオーバ前に使用していたＩＰアドレスを一定期間廃棄しないように前記移動管理ゲートウェイに指示する手段をさらに有する請求項８に記載の移動端末。
　複数のＩＰアドレスを用いて複数のパケットデータコネクションを確立可能な移動端末とパケットデータコネクションを確立するパケットデータゲートウェイであって、
　前記移動端末が送信したリクエストを受信する受信手段と、
　前記受信したリクエストを前記移動端末とのパケット送受信に関するコネクション情報を管理する前記移動管理ゲートウェイに送信するか否かを判断する判断手段と、
　前記判断手段により送信すると判断した場合には、前記移動管理ゲートウェイに前記受信したリクエストを送信する移動管理ゲートウェイへの送信手段とを、
　有するパケットデータゲートウェイ。
　前記判断手段は、前記移動端末から受信したリクエストであるIKEv2 Authentication and Tunnel Setupメッセージのパラメータを基に前記移動管理ゲートウェイにリクエストを送信するか否かを判断するものである請求項１６に記載のパケットデータゲートウェイ。
　前記IKEv2 Authentication and Tunnel Setupメッセージのパラメータは、Renew Indicationである請求項１７に記載のパケットデータゲートウェイ。
　前記IKEv2 Authentication and Tunnel Setupメッセージのパラメータは、ＰＤＮＴｙｐｅである請求項１７に記載のパケットデータゲートウェイ。
　前記判断手段により送信すると判断した場合には、前記移動管理ゲートウェイに前記受信したリクエストを送信する移動管理ゲートウェイへの送信手段を有し、
　前記移動管理ゲートウェイへの送信手段は、前記移動端末から受信したリクエストに含まれる前記移動管理ゲートウェイのアドレス宛に前記移動管理ゲートウェイへのリクエストを送信する請求項１６に記載のパケットデータゲートウェイ。
　複数のＩＰアドレスを用いて複数のパケットデータコネクションを確立可能な移動端末とのパケット送受信に関するコネクション情報を管理する移動管理ゲートウェイであって、
　前記移動端末とパケットデータコネクションを確立するパケットゲートウェイから送信されたリクエストを受信する受信手段と、
　前記受信したリクエストに含まれる情報を基に、前記移動端末とのパケット送受信に関するコネクション情報を修正する修正手段とを、
　有する移動管理ゲートウェイ。
　前記修正手段は、前記受信したリクエストにRenew Indicationが含まれるか否かを確認し、含まれている場合に前記移動端末とのパケット送受信に関するコネクション情報を修正する請求項２１に記載の移動管理ゲートウェイ。
　前記修正手段は、前記受信したリクエストに含まれるＩＰアドレスを前記移動端末とのパケット送受信に関するコネクション情報の修正に反映させる手段をさらに有する請求項２１に記載の移動管理ゲートウェイ。