(57)【特許請求の範囲】
【請求項１】
Ｓｅｌｅｃｔｅｄ  ＩＰ  Ｔｒａｆｆｉｃ  Ｏｆｆｌｏａｄ（ＳＩＰＴＯ）アーキテクチャにおける通信方法であって、
モビリティマネージメント装置（ＭＭＥ）が、ユーザ装置からトラッキングエリア（ＴＡ）アップデート信号を受信することにより、ゲートウェイ装置の再選択が必要であると判断した場合、前記ＭＭＥが再アタッチすることを設定する第１の信号を前記ユーザ装置に送信し、
前記ユーザ装置は、前記第１の信号を受けて、再アタッチを行うための第２の信号を前記ＭＭＥに送信し、
前記ＭＭＥは、パケットデータネットワーク・ゲートウェイ装置（ＰＧＷ）の再選択を行う、ことを特徴とする通信方法。
【請求項２】
Ｓｅｌｅｃｔｅｄ  ＩＰ  Ｔｒａｆｆｉｃ  Ｏｆｆｌｏａｄ（ＳＩＰＴＯ）アーキテクチャにおける通信方法であって、
Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ（ＳＧＳＮ）が、ユーザ装置からルーチングエリア（ＲＡ）アップデート信号を受信することにより、ゲートウェイ装置の再選択が必要であると判断した場合、前記ＳＧＳＮが再アタッチすることを設定する第１の信号を前記ユーザ装置に送信し、
前記ユーザ装置は、前記第１の信号を受けて、再アタッチを行うための第２の信号を、前記ＳＧＳＮに送信し、
前記ＳＧＳＮは、Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ（ＧＧＳＮ）の再選択を行う、ことを特徴とする通信方法。
【請求項３】
Ｓｅｌｅｃｔｅｄ  ＩＰ  Ｔｒａｆｆｉｃ  Ｏｆｆｌｏａｄ（ＳＩＰＴＯ）アーキテクチャによる通信システムであって、
ユーザ装置と、モビリティマネージメント装置（ＭＭＥ）と、パケットデータネットワーク・ゲートウェイ装置（ＰＧＷ）とを備え、
前記ＭＭＥが、前記ユーザ装置からのトラッキングエリア（ＴＡ）アップデート信号を前記ＭＭＥで受信することにより、前記ＰＧＷの再選択が必要であると判断した場合、再アタッチすることを設定する第１の信号を送信し、
前記ユーザ装置が、前記第１の信号を受けて、再アタッチを行うための第２の信号を前記ＭＭＥに送信し、
前記ＭＭＥは、前記ＰＧＷの再選択を行う、ことを特徴とする通信システム。
【請求項４】
Ｓｅｌｅｃｔｅｄ  ＩＰ  Ｔｒａｆｆｉｃ  Ｏｆｆｌｏａｄ（ＳＩＰＴＯ）アーキテクチャによる通信システムであって、
ユーザ装置と、Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ（ＳＧＳＮ）と、Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ（ＧＧＳＮ）とを備え、
前記ＳＧＳＮが、前記ユーザ装置からのルーチングエリア（ＲＡ）アップデート信号を前記ＳＧＳＮで受信することにより、前記ＧＧＳＮの再選択が必要であると判断した場合、再アタッチすることを設定する第１の信号を送信し、
前記ユーザ装置が前記第１の信号を受けて、再アタッチを行うための第２の信号を前記ＳＧＳＮに送信し、
前記ＳＧＳＮは、前記ＧＧＳＮの再選択を行う、ことを特徴とする通信システム。
【請求項５】
Ｓｅｌｅｃｔｅｄ  ＩＰ  Ｔｒａｆｆｉｃ  Ｏｆｆｌｏａｄ（ＳＩＰＴＯ）アーキテクチャによる通信システムにおけるユーザ装置であって、
トラッキングエリア（ＴＡ）アップデート信号をモビリティマネージメント装置（ＭＭＥ）に送信することにより、該ＭＭＥから再アタッチすることを設定する第１の信号を受信し、
再アタッチを行うための第２の信号を前記ＭＭＥに送信することにより、パケットデータネットワーク・ゲートウェイ装置（ＰＧＷ）の再選択を行わせる、ことを特徴とするユーザ装置。
【請求項６】
Ｓｅｌｅｃｔｅｄ  ＩＰ  Ｔｒａｆｆｉｃ  Ｏｆｆｌｏａｄ（ＳＩＰＴＯ）アーキテクチャによる通信システムにおけるユーザ装置であって、
ルーチングエリア（ＲＡ）アップデート信号をＳｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ（ＳＧＳＮ）に送信することにより、前記ＳＧＳＮから再アタッチすることを設定する第１の信号を受信し、
再アタッチを行うための第２の信号を前記ＳＧＳＮに送信することにより、Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ（ＧＧＳＮ）の再選択を行わせる、ことを特徴とするユーザ装置。
【請求項７】
前記ＭＭＥに接続しているサービングゲートウェイ装置（ＳＧＷ）が前記ＰＧＷにセッション削除要求を送信し、
前記ＰＧＷが前記ＳＧＷにセッション削除応答を送信することにより、前記ＰＧＷの再選択を行う、ことを特徴とする請求項１記載の通信方法。
【請求項８】
前記ＭＭＥに接続しているサービングゲートウェイ装置（ＳＧＷ）をさらに備え、
前記ＳＧＷが前記ＰＧＷにセッション削除要求を送信し、
前記ＰＧＷが前記ＳＧＷにセッション削除応答を送信することにより、前記ＰＧＷの再選択を行う、ことを特徴とする請求項３記載の通信システム。
【請求項９】
前記ＭＭＥに接続しているサービングゲートウェイ装置（ＳＧＷ）が前記ＰＧＷにセッション削除要求を送信し、
前記ＰＧＷが前記ＳＧＷにセッション削除応答を送信することにより、前記ＰＧＷの再選択を行わせる、ことを特徴とする請求項５記載のユーザ装置。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願についての記載］
本発明は、日本国特許出願：特願２００９−２１７７５７号（２００９年９月１８日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、移動体通信システムに関し、特に、パケットデータネットワークへ端末を接続するゲートウェイの再選択の実現に好適なシステムと通信制御方法及びユーザ装置に関する。
【背景技術】
【０００２】
ＥＰＣ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）におけるベアラ管理は、Ａｌｗａｙｓ  ｏｎ（常時接続）の思想により、ＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ：ユーザ装置、あるいは「端末」ともいう）がＥＰＣにアタッチした際に最初に選択されたＰＧＷ（ＰＤＮ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ） Ｇａｔｅｗａｙ）をアンカーとしてＵＥがデタッチするまで固定的に使用する。この動作により、ＵＥがＥＰＣ内の移動を繰り返しても、ＰＧＷで払い出すＩＰ情報が変わらないため、サービスネットワーク（パケットデータネットワーク）からは、常時接続を前提としたサービスを提供することが出来る。
【０００３】
ＵＥがＥＰＣ内を移動した際には、ＳＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）がＵＥの移動に伴い再選択され、その度に、ＳＧＷとＰＧＷの間のベアラを更新（切断・再確立）することにより、ＵＥからＰＧＷまでの接続性を保障する。
【０００４】
一般的に、ＰＧＷの選択は、ＳＧＷと物理的に近距離であるか、あるいは、ネットワークトポロジー的に近いＰＧＷが選択される。
【０００５】
ただし、初めに選択されたＰＧＷは、ＵＥが長距離の移動を繰り返す場合や、長距離移動した後、遠地に留まった場合などでは、ＳＧＷとＰＧＷ間の距離（物理的距離、ネットワークトポロジー的な距離）が離れてしまい、ネットワークとして効率が悪くなる。それによって、ユーザデータの伝送遅延やＥＰＣ内のネットワークリソースが非効率に消費されるといった問題があった。
【０００６】
例えば海外から成田空港に入国した際には、概ね、成田空港で携帯電話移動機の電源を投入してＥＰＣにアタッチすることから、成田空港に近いＰＧＷが選択される。ただし、入国後は、東京、大阪、札幌、福岡と移動する場合がある。したがって、各移動後は、成田空港に近いＰＧＷは最も効率的なＰＧＷではなくなる。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
以下に本願発明者達による分析を与える。これまでのＥＰＣネットワークでは、Ａｌｗａｙｓ  Ｏｎの原則から、アタッチ時に確立したデフォルト・ベアラに対しては、デタッチ時までは、削除・再確立されることはない。また、ＵＥの移動等により、ベアラを切り替える場合にも、アタッチ時に選択されたＰＧＷがアンカーとして固定されている。
【０００８】
このため、ＵＥが長距離を移動した場合等、アタッチ時に選択したＰＧＷとの接続を維持することが、ＥＰＣネットワーク上、非効率となるという問題がある。
【０００９】
そこで、ＵＥが長距離を移動した場合などに、そのＵＥが在圏エリアから外部ネットワーク（サービスネットワーク）に対して接続する際、最適なＰＧＷを再選択する方式が求められる（本願発明者達による分析結果）。
【００１０】
したがって、本発明の目的は、端末（ＵＥ）が在圏エリアから外部ネットワークに対して接続する際、最適なゲートウェイノードを再選択可能とするシステム、方法を提供することにある。
【課題を解決するための手段】
【００１１】
本発明によれば、Ｓｅｌｅｃｔｅｄ  ＩＰ  Ｔｒａｆｆｉｃ  Ｏｆｆｌｏａｄ（ＳＩＰＴＯ）アーキテクチャにおける通信方法であって、ユーザ装置がＥＰＳ  Ｃｏｎｎｅｃｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ（ＥＣＭ）−ＩＤＬＥ状態にあるときに、前記ユーザ装置がアタッチする箇所に物理的又はトポロジー的に近いゲートウェイ装置を選択する通信方法が提供される。
【００１２】
本発明によれば、Ｓｅｌｅｃｔｅｄ  ＩＰ  Ｔｒａｆｆｉｃ  Ｏｆｆｌｏａｄ（ＳＩＰＴＯ）アーキテクチャによる通信システムであって、ユーザ装置がＥＰＳ  Ｃｏｎｎｅｃｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ（ＥＣＭ）−ＩＤＬＥ状態にあるときに、前記ユーザ装置がアタッチする箇所に物理的又はトポロジー的に近いゲートウェイ装置を選択する通信システムが提供される。
【００１３】
本発明によれば、Ｓｅｌｅｃｔｅｄ  ＩＰ  Ｔｒａｆｆｉｃ  Ｏｆｆｌｏａｄ（ＳＩＰＴＯ）アーキテクチャによる通信システムにおけるユーザ装置であって、前記ユーザ装置がＥＰＳ  Ｃｏｎｎｅｃｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ（ＥＣＭ）−ＩＤＬＥ状態にあるときに、前記ユーザ装置がアタッチする箇所に物理的又はトポロジー的に近いゲートウェイ装置を選択させるユーザ装置が提供される。
【発明の効果】
【００１４】
本発明によれば、ユーザ装置が在圏エリアから外部ネットワーク（サービスネットワーク）に対して接続する際に、最適なゲートウェイノードを再選択可能とする。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施形態のシステム全体構成を示す図である。
【図２】比較例を説明する図である。
【図３】本発明を説明する図である。
【図４】比較例のシーケンスを示す図である。
【図５】本発明の第１の実施形態のシーケンスを示す図である。
【図６】本発明の第２の実施形態のシーケンスを示す図である。
【図７】本発明の第３の実施形態のシーケンスを示す図である。
【図８】本発明の第４の実施形態のシーケンスを示す図である。
【図９】本発明の第５の実施形態の構成を示す図である。
【図１０】本発明の第６の実施形態の構成を示す図である。
【図１１】本発明の第５の実施形態のシーケンスを示す図である。
【図１２】本発明の第６の実施形態のシーケンスを示す図である。
【図１３】本発明の第７の実施形態のシーケンスを示す図である。
【図１４】本発明の第８の実施形態のシーケンスを示す図である。
【発明を実施するための形態】
【００１６】
本発明の実施形態について説明する。本発明の一態様に係るシステムは、ＥＰＣにおいて、ユーザ装置（ＵＥ）の移動に合わせて、ＰＧＷ（ＰＤＮ  Ｇａｔｅｗａｙ）を再選択し、デフォルト・ベアラを再確立することにより、ユーザデータの伝送遅延改善やＥＰＣ内のネットワークリソースの効率化を実現する。
【００１７】
また、現在、３ＧＰＰ標準化では、ＬＩＰＡ（Ｌｏｃａｌ  ＩＰ  Ａｃｃｅｓｓ）、ＳＩＰＴＯ（Ｓｅｌｅｃｔｅｄ  ＩＰ  Ｔｒａｆｆｉｃ  Ｏｆｆｌｏａｄ）等と称し、ユーザトラヒックをＥＰＣに取り込まず、ＵＥの在圏する無線アクセス（Ｒａｄｉｏ  ａｃｃｅｓｓ）網から、直接、外部パケット網にアクセスさせる技術が検討されている。
本発明を、ＬＩＰＡ、及びＳＩＰＴＯアーキテクチャと連携させることにより、更に効果的なネットワークリソースの効率化が実現することが可能となる。
【００１８】
本発明の一態様のシステムは、既にＥＰＣにアタッチしている状況にあるＵＥに対し、ＰＧＷの再選択を行う。
【００１９】
通常、ＥＰＣのベアラは、ＵＥがＥＰＣネットワークにアタッチ(登録)した際に最初に選択されたＰＧＷをアンカーとして、ＵＥがデタッチ（登録削除）するまで、固定的に使用する仕様となっている。しかしながら、ＵＥが長い距離を移動した際などには、最初に選択されたＰＧＷが最も効率の良い外部網向けゲートウェイ装置では無くなる場合が多々ある。
【００２０】
本発明の一態様においては、ＵＥがアイドル状態（Ｉｄｌｅ）の場合などに、ＰＧＷを再選択、変更することにより、ＵＥとＰＧＷ間のパス（ベアラ）の最適化を行うことが可能となる。
【００２１】
本発明の一態様においては、ＵＥがパケット通信を行っていない場合（Ｉｄｌｅ  ｍｏｄｅ）に、ＰＧＷ再選択を含めて、デフォルト・ベアラの再確立を行うことにより、ユーザエクスペリエンスを損なう事なく、ＵＥ−ＰＧＷ間のネットワークリソースの最適化を行う。
【００２２】
例えばＵＥがＳＧＷを跨ぐ移動をした場合の動作について説明する。図２は、比較例として、本発明を適用しない場合を説明する図である。図２において、ＵＥは、図の左側のＳＧＷ６１に対してアタッチしているので、左側のＳＧＷ６１に物理的距離、ネットワークトポロジー的な距離が近いＰＧＷ７１が最初に選択され接続パス１が設定される。その後、ＵＥが大きく移動したとしても、左側のＰＧＷ７１を使い続けることとなるので、ＵＥ−ＰＧＷ間のパスは、非効率的な接続パス２で接続される。
【００２３】
一方、図３は、本発明を適用した場合において、ＵＥがＳＧＷを跨ぐ移動をした場合を説明する図である。図３において、ＵＥは、左側のＳＧＷ６１に対してアタッチしているので、ＳＧＷ６１に物理的距離、ネットワークトポロジー的な距離が近いＰＧＷ７１が、最初に選択され接続パス３が設定される。その後、ＥＰＣは、ＵＥが大きく移動したこと等をトリガーに、ＵＥと外部ネットワーク（サービスネットワーク）の接続性について、再吟味を行う。再吟味の結果、右側のＰＧＷ７２の方が左側のＰＧＷ７１より効率的な接続（ＵＥ−ＰＧＷパス）が提供できるものと判断し、ＵＥ−ＰＧＷ間のパスは、接続パス３から、接続パス４に変更され、効率的な接続の提供が可能となる。以下、実施形態に即して説明する。
【００２４】
＜実施形態１＞
図１は、本実施形態のネットワークシステムの構成を示す図である。ネットワークの基本構成自体は、従来のＥＰＣネットワーク構成と変わらない。
【００２５】
図１において、ＵＥ１〜ＵＥ３は、携帯電話移動機である。ｅＮｏｄｅＢ（ｅｖｏｌｖｅｄ  Ｎｏｄｅ  Ｂ）１１〜１２は、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）の基地局、更に、ＮｏｄｅＢ２１、及びＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）３１は、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｙｓｔｅｍ）システムで採用された、無線アクセス（Ｒａｄｉｏ  ａｃｃｅｓｓ）用の装置を示す。
【００２６】
ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）４１は、ＥＰＣで導入されたモビリティを管理する装置である。
【００２７】
ＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）５１は、ＵＭＴＳ用に用いる在圏装置であり、接続形態により、ユーザープレーンを扱う場合と扱わない場合とがある。
【００２８】
ＳＧＳＮがユーザープレーンを扱わない場合、そのユーザープレーンは、ＳＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｅｗａｙ）とＲＮＣ間に設定される。
【００２９】
ＳＧＷ６１、６２は、在圏でユーザープレーンを扱う装置である。ＰＧＷ７１、７２は、外部網（図中にはサービスネットワーク８１）とＥＰＣを接続するゲートウェイ装置である。
【００３０】
本実施形態の動作を説明する。ＵＥが移動することで行われるトラッキングエリア（ＴＡ：Ｔｒａｃｋｉｎｇ  Ａｒｅａ）のアップデート手順（ＴＡ  Ｕｐｄａｔｅ  Ｐｒｏｃｅｄｕｒｅ）について、はじめに、本発明を適用しない比較例を説明しておく。
【００３１】
図４は、ＳＧＷの変更を伴うＴＡアップデートの場合を示す図（比較例）である。なお、ＵＥがアイドル状態（非接続状態）のとき、どのトラッキングエリア（位置登録エリア）に属するかが管理され、どのセルに在圏するかは管理されない。
【００３２】
ＭＭＥは、ＵＥからのＴＡアップデート要求（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）を受信し、ＳＧＷの変更が必要だと判断した場合、変更先ＳＧＷであるＳＧＷ（２）に、セッション生成要求（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する。
【００３３】
ＳＧＷ（２）は、ＰＧＷ（１）に、ベアラ修正要求（Ｍｏｄｉｆｙ  Ｂｅａｒｅｒ  Ｒｅｑｕｅｓｔ）を送信し、ＰＧＷ（１）に対して、接続先ＳＧＷを変更したことを通知する。
【００３４】
ＰＧＷ（１）は、ベアラ・コンテキスト（ｂｅａｒｅｒ  ｃｏｎｔｅｘｔ）情報の更新が完了したら、ベアラ修正応答（Ｍｏｄｉｆｙ  Ｂｅａｒｅｒ  Ｒｅｓｐｏｎｓｅ）をＳＧＷ（２）に通知する。
【００３５】
ＳＧＷ（２）は、ＰＧＷ（１）からのベアラ修正応答（Ｍｏｄｉｆｙ  Ｂｅａｒｅｒ  Ｒｅｓｐｏｎｓｅ）を受けて、ＭＭＥへ、セッション生成応答（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を通知する。
【００３６】
ＭＭＥは、ＳＧＷ（２）からのセッション生成応答（正常応答）を受けて、変更元のＳＧＷであるＳＧＷ（１）に対して、セッション削除要求（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）を通知する。
【００３７】
ＳＧＷ（１）は、ベアラ・コンテキスト（ｂｅａｒｅｒ  ｃｏｎｔｅｘｔ）を削除後に、ＭＭＥに対して、セッション削除応答（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を送信する。
【００３８】
ＭＭＥは、ＳＧＷ（１）からのセッション削除応答（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を受け、ＵＥに対して、ＴＡ（Ｔｒａｃｋｉｎｇ  Ａｒｅａ）アクセプト（ＴＡ  Ａｃｃｅｐｔ）を送信する。
【００３９】
図４に示した比較例に対して、本発明の一実施形態においては、図５に示すシーケンス動作が行われる。図５を参照して、本発明の一実施形態のシーケンスを説明する。
【００４０】
ＭＭＥは、ＵＥからＴＡアップデート要求（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）を受信し、ＳＧＷの変更が必要であると判断した場合、変更先ＳＧＷであるＳＧＷ（２）に対して、セッション生成要求（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する。
【００４１】
このとき、ＭＭＥがＰＧＷの再配置が必要であると判断した場合、ＭＭＥは、効率的に外部ネットワーク（サービスネットワーク）に接続可能なＰＧＷ（２）を選択し、セッション生成要求（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）に、ＰＧＷを示すアドレス情報を設定する。
【００４２】
また、新たなＰＧＷアドレスを受信したＳＧＷ（２）は、ＰＧＷ（２）に対して、セッション生成要求（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する。
【００４３】
ＰＧＷ（２）は、ＳＧＷ（２）からのセッション生成要求（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）を受け、ベアラ・コンテキスト（ｂｅａｒｅｒ  ｃｏｎｔｅｘｔ）を生成する。また、ＰＧＷ（２）は、ＵＥに対して、新たなユーザ用ＩＰアドレスを付与する。ＰＧＷ（２）は、新たなユーザ用ＩＰアドレスのアサイン、及び、ベアラ・コンテキスト（ｂｅａｒｅｒ  ｃｏｎｔｅｘｔ）の生成が完了したら、セッション生成応答（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）をＳＧＷ（２）に通知する。
【００４４】
ＳＧＷ（２）は、ＰＧＷ（２）からのセッション生成応答（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を受け、ＰＧＷ（１）に対して、セッション削除要求（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する。
【００４５】
ＰＧＷ（１）は、ベアラ・コンテキスト（Ｂｅａｒｅｒ  Ｃｏｎｔｅｘｔ）を削除し、ＳＧＷ（２）に対して、セッション削除応答（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を送信する。
【００４６】
ＳＧＷ（２）は、ＰＧＷ（１）からのセッション削除応答（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を受けて、ＭＭＥへ、セッション生成応答（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を通知する。
【００４７】
ＭＭＥはＳＧＷ（２）からの正常応答を受けて、変更元のＳＧＷであるＳＧＷ（１）に対して、セッション削除要求（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）を通知する。
【００４８】
ＳＧＷ（１）は、ベアラ・コンテキスト（Ｂｅａｒｅｒ  Ｃｏｎｔｅｘｔ）を削除した後に、ＭＭＥに、セッション削除応答（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を送信する。
【００４９】
ＭＭＥはそれを受けてＵＥへ、ＴＡアップデートアクセプト（ＴＡ  Ｕｐｄａｔｅ  Ａｃｃｅｐｔ）を送信する。ＴＡ  Ｕｐｄａｔｅ  Ａｃｃｅｐｔには、新たにユーザに付与されたＩＰアドレス情報が設定されＵＥに通知される。
【００５０】
上記説明では、ＳＧＷ−ＰＧＷ間で、ＧＴＰｖ２（ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）  Ｔｕｎｎｅｌｉｎｇ  Ｐｒｏｔｏｃｏｌ  ｖ２）プロトコルを用いた例に即して説明したが、ＰＭＩＰｖ６（Ｐｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰｖ６）を用いたケースでも、同様の機能を実現することが出来る。
【００５１】
ＳＧＷ−ＰＧＷ間でＰＭＩＰｖ６を用いる場合、Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ／Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔの代わりに、Ｐｒｏｘｙ  Ｂｉｎｄｉｎｇ  Ｕｐｄａｔｅを用いる。また、Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ／Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅの代わりに、ｒｏｘｙ  Ｂｉｎｄｉｎｇ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔを用いる。
【００５２】
ＰＧＷの再選択を行うためのシーケンスは、図５に示した通りであるが、上記機能を実現するためには、ＭＭＥにて、適切なタイミングで、ＰＧＷ再選択を行う必要がある。
【００５３】
ＵＥがパケット通信を行っている場合、サービスネットワークに接続しているＰＧＷを変更しようとすると、ＵＥの通信先にとってＩＰアドレス等の情報が変わってしまうため、結果的にＵＥが行っているパケット通信を切断してしまうことになる。従って、図５で示した動作は、ＵＥがパケット通信を行っていないとき（ＥＣＭ（ＥＰＳ  Ｃｏｎｎｅｃｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ）−ＩＤＬＥ時）に、ＰＧＷ再選択を行う必要がある。
【００５４】
図５では、ＳＧＷが変更された場合の動作について記述したが、ＳＧＷが変更されない場合であっても、基本的な動作は同様である。図５に示したメッセージ・シーケンスは、ＳＧＷ−ＰＧＷ間がＧＴＰプロトコルで構成されている場合のメッセージ名で説明しているが、ＳＧＷ−ＰＧＷ間が、ＰＭＩＰ（Ｐｒｏｘｙ  Ｍｏｂｉｌｅ  ＩＰ）プロトコルで構成された場合であっても同様の効果を得ることが可能である。
【００５５】
また、図５において、ＭＭＥをＳＧＳＮと置き換えることにより、アクセス網がＵＭＴＳである場合のＰＧＷの再選択動作となる。
【００５６】
以上説明したように、本実施形態においては、以下記載の作用効果を奏する。
【００５７】
ＵＥの在圏位置をベースとしたＰＧＷの選択が可能となる。ＵＥと物理的に近距離、或いはネットワークトポロジー的に近いＰＧＷが選択・接続されるため、効率的な接続により、ネットワーク・リソースの最適化が可能となる。
【００５８】
ＵＥ−ＰＧＷ間の効率的なパス接続により、ユーザデータ伝送の遅延の改善が可能となる。
【００５９】
ＬＩＰＡ、ＳＩＰＴＯアーキテクチャと連携して動作させることにより、ユーザデータを全くＥＰＣに取り込むことなく、パケット通信サービスを提供することが可能となる。このため、移動体通信オペレータは、ＥＰＣのネットワーク装置の負荷を低減することが可能となる。
【００６０】
＜実施形態２＞
本発明の第２の実施形態について、図６を参照して説明する。端末（ＵＥ）が発信したＴＡアップデート要求（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）をＭＭＥが受信した際、ＭＭＥは、当該ＵＥが接続されるＰＧＷが妥当かの吟味を行う。
【００６１】
図６では、ＵＥがＰＧＷ（１）と接続されている状況を示している（ＵＥとＰＧＷ（１）間でＥＰＳベアラ確立：ＥＰＳ  ｂｅａｒｅｒ  ｏｒｉｇｉｎａｌｌｙ  ｅｓｔａｂｌｉｓｈｅｄ）。
【００６２】
ＭＭＥが、他の適当なＰＧＷを再選択が必要と判断した場合、ＭＭＥは、ＴＡアップデート要求（ＴＡ  Ｕｐｄａｔｅ  ｒｅｑｕｅｓｔ）に対して、再アタッチ（ＡＴＴＡＣＨ）を促す理由値（ｃａｕｓｅ値）を設定して、ＵＥに対して、ＴＡアップデート・リジェクト（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｊｅｃｔ）を送信する。
【００６３】
ＵＥは、ＭＭＥからのＴＡアップデート・リジェクト（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｊｅｃｔ）に応答して、アタッチ（ＡＴＴＡＣＨ）信号を、ＭＭＥに送信する。これを受け、ＭＭＥは、ＰＧＷの選択ロジックを新たに起動することが可能となる。その結果、適当なＰＧＷの再選択が行われる。
【００６４】
図６の例では、ＰＧＷ（２）が再選択され、ＰＧＷ（２）に向けた接続処理の例が記述されている。すなわち、ＭＭＥからのセッション生成要求（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）がＳＧＷ（２）に送信され、ＳＧＷ（２）からセッション生成要求がＰＧＷ（２）に送信される。ＰＧＷ（２）からのセッション生成の応答（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を受けたＳＧＷ（２）は、ＭＭＥにセッション生成応答を送信する。ＭＭＥは、セッション削除要求（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）をＳＧＷ（１）に送信する。ＳＧＷ（１）は、セッション削除の応答（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）をＭＭＥに返す。これを受け、ＭＭＥは、ＴＡアップデートの完了を通知するＴＡ  Ｕｐｄａｔｅ  Ａｃｃｅｐｔを端末（ＵＥ）に返す。
【００６５】
本実施形態においては、以下の作用効果を奏する。
【００６６】
ＵＥにインパクトを与えずに、前記第１の実施形態を得ることができる。また、ＥＰＣに対しても、最小の変更で実現可能となる。
【００６７】
＜実施形態３＞
本発明の第３の実施形態について、図７を参照して以下に説明する。本発明の第３の実施形態は、通常のＴＡアップデート手順に対して、若干の変更が施されている。
【００６８】
図７に示したシーケンスは、通常のＴＡアップデート手順であるが、本実施形態の変更点として、ＭＭＥからＵＥに対してＴＡアップデート手順の完了を通知する。
【００６９】
図７を参照すると、ＵＥからのＴＡアップデート要求（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）を受けたＭＭＥは、ＳＧＷ（２）に対してセッション生成要求（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）、ＳＧＷ（２）からＰＧＷ（１）にベアラ修正要求（Ｍｏｄｉｆｙ  Ｂｅａｅｒ  Ｒｅｑｕｅｓｔ）が送信され、ＳＧＷ（２）からのセッション生成応答（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を受けたＭＭＥは、ＳＧＷ（１）に対してセッション削除要求（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）を送信し、ＳＧＷ（１）からセッション削除応答（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｃｅ）を受けたＭＭＥは、ＵＥにＴＡアップデートアクセプト（ＴＡ  Ｕｐｄａｔｅ  Ａｃｃｅｐｔ（ＰＤＮ））を送信している。
【００７０】
本実施形態においては、ＴＡ  Ｕｐｄａｔｅ  Ａｃｃｅｐｔ信号に、新たな情報（すなわち、図７における、ＴＡ  Ｕｐｄａｔｅ  Ａｃｃｅｐｔ（ＰＤＮ）の「ＰＤＮ」）を追加し、現在接続中にあるパケットデータネットワーク（ＰＤＮ）の再接続を促す構成としている。
【００７１】
新たな情報（ＰＤＮ）が付加された、ＴＡアップデートアクセプト（ＴＡ  Ｕｐｄａｔｅ  Ａｃｃｅｐｔ）信号を受信したＵＥは、指定された情報を基に、再接続するＰＤＮ（パケットデータネットワーク）（複数のＰＤＮが付加される場合も有る）を認識し、当該ＰＤＮに対して、
ＵＥ  ｒｅｑｕｅｓｔｅｄ  ＰＤＮ  Ｄｉｓｃｏｎｎｅｃｔｉｏｎ処理（ＵＥが要求したＰＤＮの切断処理）、
ＵＥ  ｒｅｑｕｅｓｔｅｄ  ＰＤＮ  ｃｏｎｎｅｃｔｉｖｉｔｙ処理（ＵＥが要求したＰＤＮの接続処理）、
を起動し、パケットデータネットワーク（ＰＤＮ）の再接続を行う。
【００７２】
このパケットデータネットワーク（ＰＤＮ）の再接続では、ＭＭＥにて、ＰＧＷの選択ロジックを新たに起動することが可能となるため、結果的に適当なＰＧＷの再選択が必要となる。
【００７３】
図７には、ＳＧＷが変更された場合の動作について記載されているが、ＳＧＷが変更されない場合であっても、基本的な動作は同様である。
【００７４】
本実施形態の作用効果を説明する。
【００７５】
本実施形態においては、アタッチ（ＡＴＴＡＣＨ）処理（再アタッチ）を起動せずに、ＰＧＷの再接続を可能としている。
【００７６】
ＡＴＴＡＣＨ処理を起動するということは、複数のＰＤＮ接続がある場合、全てのＰＤＮ接続に対して、ＰＧＷ再選択処理が起動され、比較的大きな規模の処理を起動することになる。
【００７７】
これに対して、本実施形態は、必要なＰＧＷの再選択のみを、ＥＰＣ起動で行うことが可能となる。
【００７８】
＜実施形態４＞
本発明の第４の実施形態について、図８を参照して説明する。本発明の第４の実施形態においては、ＵＥが行うＴＡアップデート手順と非依存で、ＥＰＣ（ＭＭＥ）が任意のタイミングで起動することが可能なＰＧＷの再選択を行う。ＭＭＥが接続中、ＰＧＷの再選択が必要と判断した場合、ＵＥに対して、ページ（Ｐａｇｅ）信号を送信し、ＵＥとの接続を試みる。
【００７９】
この際、オプションとして、ページ（Ｐａｇｅ）信号に、ｃａｕｓｅ情報（理由情報）が追加されている（図８のＰａｇｅ（ｃａｕｓｅ）参照）。ＵＥは、このＰａｇｅ信号（ｃａｕｓｅ情報付きのＰａｇｅ信号）を無視することが許容されている。これは、この処理が、反復的に実行されたことによるＵＥのバッテリー消耗を回避すること等を目的とした対策である。
【００８０】
本来、Ｐａｇｅ信号は、着信呼をＵＥに通知するために用いる信号であるのに対して、本実施形態において、ＰＧＷの再選択が必要なときに送信されるＰａｇｅ信号は、ＥＰＣ内の接続パス効率化のためのものであり、必須の動作ではないといえる。このＰａｇｅ信号を受けたＵＥは、ＭＭＥとの通信のために、サービス要求（Ｓｅｒｖｉｃｅ  ｒｅｑｕｅｓｔ）信号をＭＭＥに向けて送信する。ＭＭＥからのディアクティベートベアラ要求（Ｄｅａｃｔｉｖａｔｅ  Ｂｅａｒｅｒ  ｒｅｑｕｅｓｔ）がＭＭＥからｅＮｏｄｅＢへ送信され、ｅＮｏｄｅからＲＲＣ  ｃｏｎｎｅｃｔｉｏｎ  ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎを送信し、ＵＥからＲＲＣ  ｃｏｎｎｅｃｔｉｏｎ  ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎの完了通知を受けると、ｅＮｏｄｅＢはＭＭＥにディアクティベートベアラ応答（Ｄｅａｃｔｉｖａｔｅ  Ｂｅａｒｅｒ  ｒｅｓｐｏｎｓｅ）を送る。
【００８１】
その後、ＭＭＥは、ＰＧＷの再選択が必要なパケットデータネットワーク（ＰＤＮ）接続を切断することにより、ＵＥからのＵＥの要求になるパケットデータネットワーク接続（ＵＥ  ｒｅｑｕｅｓｔｅｄ  ＰＤＮ  ｃｏｎｎｅｃｔｉｖｉｔｙ）手順の誘発を行う。
【００８２】
この手順の実行により、ＭＭＥにて、ＰＧＷの選択ロジックを新たに起動することが可能となるため、結果的に、適当なＰＧＷの再選択が必要となる。この手順は、ＥＰＣ（ＭＭＥ）が任意のタイミングで、ＰＧＷの再選択を起動することが可能であるが、そのトリガーとして、Ｏ＆Ｍ（Ｏｐｅｒａｔｉｏｎ  ＆  Ｍａｉｎｔｅｎａｎｃｅ）、ＬＩＰＡ、ＳＩＰＴＯ接続の有無などが適用できる。
【００８３】
本実施形態においては、ＭＭＥが任意のタイミングでＰＧＷの再選択を可能となるという作用効果を奏する。
【００８４】
＜実施形態５＞
本発明を、ＬＩＰＡ、ＳＩＰＴＯアーキテクチャに利用した例を説明する。図９および図１０は、本発明の実施形態の構成を示す図である。
【００８５】
図９を参照すると、ＵＥ１〜３は、携帯電話移動機である。ｅＮｏｄｅＢ１１〜１２は、ＬＴＥの基地局である。更に、ＮｏｄｅＢ２１、及び、ＲＮＣ３１は、ＵＭＴＳシステムで採用された、無線アクセス（Ｒａｄｉｏ  ａｃｃｅｓｓ）用の装置である。ＭＭＥ４１は、ＥＰＣで導入されたモビリティを管理する装置である。ＳＧＳＮ５１は、ＵＭＴＳ用に用いる在圏装置であり、接続形態により、ユーザープレーンを扱う場合と扱わない場合がある。ＳＧＳＮがユーザープレーンを扱わない場合のユーザープレーンは、ＳＧＷとＲＮＣ間に設定される。
【００８６】
ＳＧＷ６１、６２は、在圏でユーザープレーンを扱う装置であり、ＰＧＷ７１、７２は、外部網（図９では、サービスネットワーク８１）とＥＰＣを接続するゲートウェイ装置である。更に、ＬＰＧＷ（Ｌｏｃａｌ  ＰＧＷ）９１〜９２は、ｅＮｏｄｅＢと混在しているか、ｅＮｏｄｅＢに極めて近い位置に存在し、サービスネットワーク８１との接続を可能とするゲートウェイ装置である。
【００８７】
図１０において、ＵＥ１〜２は、携帯電話移動機である。ＮｏｄｅＢ２１〜２２、及びＲＮＣ３１〜３２は、ＵＭＴＳシステムで採用された無線アクセス（Ｒａｄｉｏ  ａｃｃｅｓｓ）用の装置である。ＳＧＳＮ６１〜６２は、ＵＭＴＳ用に用いる在圏装置であり、接続形態により、ユーザープレーンを扱う場合と扱わない場合がある。ＳＧＳＮがユーザープレーンを扱わない場合のユーザープレーンは、ＧＧＳＮとＲＮＣ間に設定される。特に、ＧＧＳＮとＲＮＣ間にユーザープレーンを設定する形態を、「ダイレクトトンネル接続」と呼ぶ。
【００８８】
ＧＧＳＮ７１〜７２は、外部網（図１０では、サービスネットワーク８１）とＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）網を接続するゲートウェイ装置である。
【００８９】
更に、ＬＧＧＳＮ（Ｌｏｃａｌ  ＧＧＳＮ（Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）１０１〜１０２は、ＲＮＣ（Ｒａｄｉｏ  Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌｌｅｒ）と混在しているか、ＲＮＣに極めて近い位置に存在し、サービスネットワーク８１との接続を可能とするゲートウェイ装置である。
【００９０】
図９に示した構成の第５の実施形態の動作について、図１１のシーケンス図を用いて説明する。
【００９１】
ＭＭＥはＵＥからのＴＡアップデート要求（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）を受信するが、ＬＩＰＡ、ＳＩＰＴＯアーキテクチャの場合、ｅＮｏｄｅＢから、ＭＭＥ間のＴＡアップデート要求（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）信号の伝送は、Ｓ１−ＡＰメッセージ上にカプセル化（ｅｎｃａｐｓｕｌａｔｅｄ）される。
【００９２】
その際、ｅＮｏｄｅＢは、Ｓ１−ＡＰメッセージ上で、ＬＩＰＡ、ＳＩＰＴＯアーキテクチャによるＰＤＮ接続の設定が可能であることの通知を、ＭＭＥに向けて行う。
【００９３】
ＭＭＥは、ＳＧＷの変更が必要であると判断した場合、変更先ＳＧＷであるＳＧＷ（２）に、セッション生成要求（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する。
【００９４】
このとき、ＭＭＥは、ＬＰＧＷへの再配置が必要であると判断した場合には、効率的に外部ネットワーク（サービスネットワーク８１）に接続可能なＬＰＧＷを、ＭＭＥが選択し、セッション生成要求（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）に、ＰＧＷを示すアドレス情報を設定する。ただし、前述のＳ１−ＡＰメッセージ上で、ＬＩＰＡ、ＳＩＰＴＯアーキテクチャによるＰＤＮ接続の設定が可能であることの通知は、あくまで一例であり、ＭＭＥが他の情報で新たなＰＧＷの再選択の必要性を判断することも可能である。
【００９５】
また、新たなＰＧＷアドレスを受信したＳＧＷ（２）は、ＬＰＧＷに対してセッション生成要求（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）を送信し、ＬＰＧＷは、セッション生成要求（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）を受けて、ベアラ・コンテキスト（Ｂｅａｒｅｒ  Ｃｏｎｔｅｘｔ）を生成する。
【００９６】
また、ＬＰＧＷは、ＵＥに対して、新たなユーザ用ＩＰアドレスを付与する。
【００９７】
ＬＰＧＷは、新たなユーザ用ＩＰアドレスのアサイン、及びベアラ・コンテキスト（Ｂｅａｒｅｒ  Ｃｏｎｔｅｘｔ）の生成が完了すると、セッション生成応答（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）をＳＧＷ（２）に通知する。
【００９８】
セッション生成応答（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を受け、ＳＧＷ（２）は、ＰＧＷ（１）に対して、セッション削除要求（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）を送信する。
【００９９】
ＰＧＷ（１）は、ベアラ・コンテキスト（Ｂｅａｒｅｒ  Ｃｏｎｔｅｘｔ）を削除し、ＳＧＷ（２）に対して、セッション削除応答（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を送信する。
【０１００】
ＳＧＷ（２）はセッション削除応答（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を受けて、ＭＭＥに対してセッション生成応答（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を通知する。
【０１０１】
ＭＭＥは、ＬＰＧＷからの正常応答を受けて、変更元のＳＧＷであるＳＧＷ（１）に対して、セッション削除要求（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）を通知する。
【０１０２】
ＳＧＷ（１）は、ベアラ・コンテキスト（Ｂｅａｒｅｒ  Ｃｏｎｔｅｘｔ）を削除した後に、ＭＭＥに対して、セッション削除応答（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を送信する。
【０１０３】
ＭＭＥはセッション削除応答（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）を受け、ＵＥに対して、ＴＡ受理（ＴＡ  Ａｃｃｅｐｔ）を送信する。このＴＡ  Ａｃｃｅｐｔには、新たにユーザに付与されたＩＰアドレス情報が設定され、ＵＥに通知される。
【０１０４】
上記説明では、ＳＧＷ−ＰＧＷ間で、ＧＴＰｖ２プロトコルを用いた例に即して説明したが、ＰＭＩＰｖ６を用いた場合でも、同様の機能を実現することが出来る。
【０１０５】
その場合、セッション生成要求（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）／セッション削除要求（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）の代わりに、
Ｐｒｏｘｙ  Ｂｉｎｄｉｎｇ  Ｕｐｄａｔｅを用いる。また、セッション生成応答（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）／セッション削除応答（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）の代わりに、プロキシバインディングアクノリッジメント（Ｐｒｏｘｙ  Ｂｉｎｄｉｎｇ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を用いる。
【０１０６】
ＬＰＧＷ再選択を行うためのシーケンスは、図１１で示した通りであるが、上記機能を実現するには、ＭＭＥにて、適切なタイミングで、ＰＧＷの再選択を行う必要がある。
【０１０７】
ＵＥがパケット通信を行っている場合、サービスネットワークに接続しているＰＧＷを変更しようとすると、ＵＥの通信先にとって、ＩＰアドレス等の情報が変わってしまうことになる。このため、結果的にＵＥが行っているパケット通信を切断することになる。従って、図１１に示したシーケンス動作は、ＵＥがパケット通信を行っていないとき（ＥＣＭ−ＩＤＬＥ時）にＰＧＷの再選択を行う必要がある。
【０１０８】
図１１は、ＳＧＷが変更された場合の動作について記述したが、ＳＧＷが変更されない場合であっても、基本的な動作は同様である。図１１のメッセージ・シーケンスは、ＳＧＷ−ＰＧＷ間がＧＴＰプロトコルで構成されている場合のメッセージ名で説明しているが、ＳＧＷ−ＰＧＷ間がＰＭＩＰプロトコルで構成された場合であっても、同様の効果を得ることが可能である。
【０１０９】
また、図１１において、ＭＭＥをＳＧＳＮに、ｅＮｏｄｅＢをＲＮＣと置き換えることにより、アクセス網が、ＵＭＴＳである場合のＰＧＷの再選択動作の説明となる。
【０１１０】
上記したように、本実施形態によれば、ＬＰＧＷを再選択することにより、ユーザトラヒックをＥＰＣに取り込むことなく、パケット通信を提供することが可能となる。このため、移動体通信オペレータは、ＥＰＣのネットワーク装置の負荷を低減することが可能となる。
【０１１１】
＜実施形態６＞
本発明の第６の実施形態について説明する。本実施形態の構成は、図９に示した装置構成とされる。本実施形態の動作について、図１２を参照して説明する。
【０１１２】
ＭＭＥは、ＵＥからのＴＡアップデート要求（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）を受信する。ＬＩＰＡ、ＳＩＰＴＯアーキテクチャの場合、ｅＮｏｄｅＢからＭＭＥ間のＴＡアップデート要求（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）信号の伝送は、Ｓ１−ＡＰメッセージ上に、カプセル化される。その際のＳ１−ＡＰメッセージ上で、ＬＩＰＡ、ＳＩＰＴＯアーキテクチャによるＰＤＮ接続の設定が可能であることの通知を、ｅＮｏｄｅＢは、ＭＭＥに向けて行う。
【０１１３】
ＭＭＥは、当該ＵＥが接続されるＰＧＷが妥当かの吟味を行う。ただし、前述のＳ１−ＡＰメッセージ上で、ＬＩＰＡ、ＳＩＰＴＯアーキテクチャによるＰＤＮ接続の設定が可能であることの通知は、あくまで一例であり、ＭＭＥが他の情報で新たなＰＧＷの再選択の必要性を判断することも可能である。
【０１１４】
図１２では、ＵＥが、ＰＧＷ（１）と接続されている状況を示している（ＵＥｔｏＰＧＷ（１）間のＥＰＳ  ｂｅａｒｅｒ  ｏｒｉｇｉｎａｌｌｙ  ｅｓｔａｂｌｉｓｈｅｄ）。ＭＭＥが、ＬＰＧＷの再選択が必要と判断した場合、ＭＭＥは、ＴＡアップデート要求（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）に対して、再アタッチ（ＡＴＴＡＣＨ）を促すｃａｕｓｅ値を設定して、ＵＥに対して、ＴＡアップデート・リジェクト（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｊｅｃｔ）を返送する。
【０１１５】
ＵＥは、ＴＡアップデート・リジェクト（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｊｅｃｔ）に誘発され、ＡＴＴＡＣＨ信号をＭＭＥに送信する。このＡＴＴＡＣＨ信号の伝送も、Ｓ１−ＡＰメッセージ上にカプセル化される。ｅＮｏｄｅＢは、その際のＳ１−ＡＰメッセージ上で、ＬＩＰＡ、ＳＩＰＴＯアーキテクチャによるＰＤＮ接続の設定が可能であることの通知を、ＭＭＥに向けて行う。
【０１１６】
ＭＭＥは、ＰＧＷの選択ロジックを新たに起動することが可能となるため、結果的にＬＰＧＷの再選択が必要となる。
【０１１７】
図１２では、ＬＰＧＷが再選択され、ＬＰＧＷに向けた接続処理の例が記述されている。ＭＭＥからＳＧＷ（２）、ＬＰＧＷへのセッション生成要求（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）、ＬＰＧＷからＳＧＷ（２）、ＭＭＥへのセッション生成応答（Ｃｒｅａｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）、ＭＭＥからＳＧＷ（１）へのセッション削除要求（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｑｕｅｓｔ）、ＳＧＷ（１）からＭＭＥへのセッション削除応答（Ｄｅｌｅｔｅ  Ｓｅｓｓｉｏｎ  Ｒｅｓｐｏｎｓｅ）、ＭＭＥからＵＥへのＴＡアップデート受理の送信が行われる。
【０１１８】
上記の通り、本実施形態によれば、ＬＰＧＷを再選択することにより、ユーザトラヒックをＥＰＣに取り込むことなく、パケット通信を提供することが可能となる。このため、移動体通信オペレータは、ＥＰＣのネットワーク装置の負荷を低減することが可能となる。
【０１１９】
＜実施形態７＞
本発明の第７の実施形態について説明する。本実施形態の構成は、図９に示した装置構成とされる。本実施形態の動作について、図１３を参照して説明する。本実施形態は、通常のＴＡアップデート手順に対して、変更を加えている。
【０１２０】
ＭＭＥはＵＥからのＴＡアップデート要求（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）を受信するが、ＬＩＰＡ、ＳＩＰＴＯアーキテクチャの場合、ｅＮｏｄｅＢからＭＭＥ間のＴＡアップデート要求（ＴＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）信号の伝送は、Ｓ１−ＡＰメッセージ上にカプセル化される。
【０１２１】
その際のＳ１−ＡＰメッセージ上で、ＬＩＰＡ、ＳＩＰＴＯアーキテクチャによるＰＤＮ接続の設定が可能であることの通知をＭＭＥに向けて行う。ただし、前述のＳ１−ＡＰメッセージ上で、ＬＩＰＡ、ＳＩＰＴＯアーキテクチャによるＰＤＮ接続の設定が可能であることの通知は、あくまで一例であり、ＭＭＥが他の情報で新たなＰＧＷの再選択の必要性を判断することも可能である。
【０１２２】
ＭＭＥからＵＥに対してＴＡアップデート手順の完了を通知するＴＡアップデートアクセプト信号（ＴＡ  ＵＰｄａｔｅ  Ａｃｃｅｐｔ）に新たな情報（図１３では、ＰＤＮ）を追加し、現在接続中にあるパケットデータネットワーク（ＰＤＮ）の再接続を促す。新たな情報が付加されたがＴＡ  Ｕｐｄａｔｅ  Ａｃｃｅｐｔ信号を受信したＵＥは、指定された情報を元に再接続するＰＤＮ（複数のＰＤＮの場合も有）を認識し、当該ＰＤＮに対して、従来のＵＥの要求になるパケットデータネットワーク接続（ＵＥ  ｒｅｑｕｅｓｔｅｄ  ＰＤＮ  Ｄｉｓｃｏｎｎｅｃｔｉｏｎ処理、ＵＥ  ｒｅｑｕｅｓｔｅｄ  ＰＤＮ  ｃｏｎｎｅｃｔｉｖｉｔｙ）処理を起動し、パケットデータネットワーク（ＰＤＮ）の再接続を実行する。
【０１２３】
このパケットデータネットワーク（ＰＤＮ）の再接続では、ＭＭＥにてＰＧＷの選択ロジックを新たに起動することが可能となるため、結果的にＬＰＧＷの再選択が必要となる。
【０１２４】
図１３では、ＳＧＷが変更された場合の動作について記述したが、ＳＧＷが変更されない場合であっても、基本的な動作は、同様である。
【０１２５】
上記の通り、本実施形態によれば、ＬＰＧＷを再選択することにより、ユーザトラヒックをＥＰＣに取り込むことなくパケット通信を提供することが可能となる。このため、移動体通信オペレータは、ＥＰＣのネットワーク装置の負荷を低減することが可能となる。
【０１２６】
＜実施形態８＞
本発明の第８の実施形態について説明する。本実施形態の構成は、図１０に示した装置構成とされる。本実施形態の動作について、図１４を参照して説明する。
【０１２７】
ＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）は、ＵＥからのＲＡ（ルーチングエリア）アップデート要求（ＲＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）を受信するが、ＬＩＰＡ、ＳＩＰＴＯアーキテクチャの場合、ＮｏｄｅＢからＳＧＳＮ間のＲＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ信号の伝送は、ＲＡＮＡＰ（Ｒaｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ  Ａｃｃｅｓｓ  Ｐａｒｔ）メッセージ上にカプセル化される。その際のＲＡＮＡＰメッセージ上で、ＲＲＣは、ＬＩＰＡ、ＳＩＰＴＯアーキテクチャによるＰＤＮ接続の設定が可能であることの通知を、ＳＧＳＮに向けて行う。
【０１２８】
ＳＧＳＮは、当該ＵＥが接続されるＧＧＳＮ（Ｇａｔｅｗａｙ  ＧＰＲＳ  Ｓｕｐｐｏｒｔ  Ｎｏｄｅ）が妥当かの吟味を行う。ただし、前述のＲＡＮＡＰメッセージ上で、ＬＩＰＡ、ＳＩＰＴＯアーキテクチャによるＰＤＮ接続の設定が可能であることの通知は、あくまで一例であり、ＳＧＳＮが他の情報で新たなＰＧＷの再選択の必要性を判断することも可能である。
【０１２９】
図１４では、ＵＥがＧＧＳＮと接続されている状況を示している（ＵＥとＧＧＳＮ間でＧＴＰトンネル接続が確立：図１４の「ＧＴＰ  Ｔｕｎｎｅｌｉｎｇ  ｏｒｉｇｉｎａｌｌｙ  ｅｓｔａｂｌｉｓｈｅｄ」参照）。
【０１３０】
ＳＧＳＮが、ＬＧＧＳＮとの再選択が必要と判断した場合、ＳＧＳＮは、ＲＡアップデート要求（ＲＡ  Ｕｐｄａｔｅ  Ｒｅｑｕｅｓｔ）に対して、再アタッチ（ＡＴＴＡＣＨ）を促す理由値（ｃａｕｓｅ値）を設定して、ＵＥに対して、ＲＡアップデート・リジェクト信号（ＲＡ  Ｕｐｄａｔｅ  Ｒｅｊｅｃｔ）を返送する。
【０１３１】
ＵＥは、ＲＡアップデート・リジェクト信号（ＲＡ  Ｕｐｄａｔｅ  Ｒｅｊｅｃｔ）に誘発され、ＡＴＴＡＣＨ信号を、ＳＧＳＮに対して送信し、ＧＰＲＳ網に再アタッチ（ＡＴＴＡＣＨ）を試みる。ＳＧＳＮは、ＲＡアップデート要求（Ｕｐｄａｔａ  ＲＡ  ｒｅｑｕｅｓｔ）をＨＬＲ（Ｈｏｍｅ  Ｌｏｃａｔｉｏｎ  Ｒｅｇｉｓｔｅｒ）に送信し、ＨＬＲからＧＧＳＮに、インサート・サブスクライバ・データ（Ｉｎｓｅｒｔ  Ｓｕｂｓｃｒｉｖｅｒ  ｄａｔａ）が送信され、ＧＧＳＮは、インサート・サブスクライバ・データ肯定応答（Ｉｎｓｅｒｔ  Ｓｕｂｓｃｒｉｖｅｒ  ｄａｔａ  ａｃｋ）をＨＬＲに返す。この肯定応答（ａｃｋ）を受けＨＬＲはＲＡアップデート応答（Ｕｐｄａｔａ  ＲＡ   ｒｅｓｐｏｎｓｅ）をＳＧＳＮに返す。ＳＧＳＮは、ＡＴＴＡＣＨの受理（ＡＴＴＡＣＨ  Ａｃｃｅｐｔ）をＵＥに返す。
【０１３２】
その後、ＵＥは、ＰＤＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｐｒｏｔｏｃｏｌ）接続を要求するＰＤＰコンテキストアクティベート要求（Ａｃｔｉｖａｔｅ  ＰＤＰ  ｃｏｎｔｅｘｔ  ｒｅｑｕｅｓｔ）を、ＳＧＳＮに対して送信する。
【０１３３】
ＰＤＰコンテキストアクティベート要求（Ａｃｔｉｖａｔｅ  ＰＤＰ  ｃｏｎｔｅｘｔ  ｒｅｑｕｅｓｔ）を受信したＳＧＳＮは、ＬＧＧＳＮへの接続の妥当性を判断し、妥当であると判断した場合には、ＬＧＧＳＮに向けて、ＧＴＰ（ＧＰＲＳ  Ｔｕｎｎｅｌｉｎｇ  Ｐｒｏｔｏｃｏｌ）トンネルの作成を行う（Ｃｒｅａｔｅ  ＰＤＰ  ｃｏｎｔｅｘｔ  ｒｅｑｕｅｓｔ）。ＬＧＧＳＮからＳＧＳＮに対して、Ｃｒｅａｔｅ  ＰＤＰ  ｃｏｎｔｅｘｔ  ｒｅｓｐｏｎｓｅが返送され、ＳＧＳＮからＵＥに、ＰＤＰコンテキストアクティベート応答（Ａｃｔｉｖａｔｅ  ＰＤＰ  ｃｏｎｔｅｘｔ  ｒｅｓｐｏｎｓｅ）が返送され、ＵＥとＬＧＧＳＮの接続が可能となる。
【０１３４】
上記した本実施形態によれば、ＬＧＧＳＮを再選択することにより、ユーザトラヒックをＧＰＲＳ網に取り込むことなく、パケット通信を提供することが可能となる。このため、移動体通信オペレータは、ＧＰＲＳのネットワーク装置の負荷を低減することが可能となる。
【０１３５】
本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素（各請求項の各要素、各実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
【符号の説明】
【０１３６】
１、２、３  ＵＥ（ユーザ装置、端末）
１１、１２  ｅＮｏｄｅＢ
２１  ＮｏｄｅＢ
３１  ＲＮＣ
４１  ＭＭＥ
６１、６２  ＳＧＷ
５１  ＳＧＳＮ
７１、７２  ＰＧＷ
８１  サービスネットワーク
９１、９２  ＬＰＧＷ
１０１、１０２  ＬＧＧＳＮ
【図１】
0005413996.tif 000002
【図２】
0005413996.tif 000003
【図３】
0005413996.tif 000004
【図４】
0005413996.tif 000005
【図５】
0005413996.tif 000006
【図６】
0005413996.tif 000007
【図７】
0005413996.tif 000008
【図８】
0005413996.tif 000009
【図９】
0005413996.tif 000010
【図１０】
0005413996.tif 000011
【図１１】
0005413996.tif 000012
【図１２】
0005413996.tif 000013
【図１３】
0005413996.tif 000014
【図１４】
0005413996.tif 000015