JP2016029847A

JP2016029847A - 通信システムと方法と装置

Info

Publication number: JP2016029847A
Application number: JP2015213913A
Authority: JP
Inventors: 創前佛; So Maebotoke; 田村　利之; Toshiyuki Tamura; 利之田村
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2013-07-04
Filing date: 2015-10-30
Publication date: 2016-03-03
Anticipated expiration: 2034-07-04
Also published as: US20160192263A1; RU2642477C1; US20180146406A1; KR20160043537A; EP2996393A4; US9883440B2; PH12017500046A1; CN105359581A; US20160174120A1; MX345250B; RU2669792C1; CN105611585B; EP3029992A2; BR112015032906A2; MX2016000202A; PH12016500439A1; PH12016500012B1; JP2016034164A; RU2602088C1; KR101663451B1

Abstract

【課題】コアネットワーク全体の設備コストの低減を図り、効率的なハンドオーバ機能を提供する。【解決手段】ローアクセスプライオリティ(Low Access Priority)の端末が該端末からのRRCコネクション要求がローアクセスプライオリティであることを示す情報であるLAPIをソース基地局に提供し、さらに前記ソース基地局を介してソースMMEにLAPIを通知して保持させ、ソースMMEは端末がハンドオーバする場合にソース基地局からHandover Requiredを受信し保持されたLAPIに基づき前記端末に専用のターゲットMMEを選択しForward Relocation Requestを送信する。【選択図】図１７

Description

［関連出願についての記載］
本発明は、日本国特許出願：特願２０１３−１４１１２７号（２０１３年７月４日出願）及び特願２０１３−１８７１０６号（２０１３年９月１０日出願）に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、通信システムと方法と装置に関する。

移動体通信システムのコアネットワークにおいては、様々な端末（移動機）に対して様々なサービスを提供するために、サービス毎に必要な機能を、コアネットワーク内のノードの全てが具備する必要がある。大規模移動体通信網等においては、コアネットワーク内に多くのノードが配備されている。端末は、位置登録毎に、コアネットワーク内のノードに分散して接続される。

このため、コアネットワーク内の全てのノードがサービス毎に必要な機能（サービス提供機能）を具備する必要がある。コアネットワーク内のノードにおいて一部のノードでも、当該サービス提供機能を具備していない場合には、端末に対してサービス継続性を保証することができなくなる。

なお、移動局が利用するサービスの種類に応じてパケット転送経路を最適化する構成として、例えば特許文献１には、移動局が外部網からのサービスを利用する場合、外部網に応じた特定のパケット転送装置を経由するようにパケット転送経路に制約を加え、移動局が移動通信ネットワークで提供されるサービスを利用する場合には、パケット転送経路に制約を与えない構成が開示されている。

特開２００３−３３８８３２号公報

以下に関連技術の分析を与える。

上記したように、コアネットワーク内の各ノードは、全てのサービス提供機能を具備することから、高機能・高性能を要求されることになる。結果として、各コアネットワークノードが高価なものとなっている。

例えば、３ＧＰＰ（３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ）で標準化されており、同報型配信を実現するベアラサービスであるＭＢＭＳ（ＭｕｌｔｉｍｅｄｉａＢｒｏａｄｃａｓｔＭｕｌｔｉｃａｓｔＳｅｒｖｉｃｅ）サービス（同時配信サービス）は、これに対応している移動機が比較的少ないため、サービス提供の機会は少ない。しかしながら、少数のＭＢＭＳユーザに対してサービスを提供しようとした場合、通信事業者としては、コアネットワーク内の全てのノードでＭＢＭＳ機能を具備しなければ、当該数のＭＢＭＳユーザに対してサービスを提供することは出来ない。

移動機のＭＢＭＳサービスの利用の要否に応じて、コアネットワークのノードを選択することができれば、通信事業者は、比較的に少数の高価なＭＢＭＳ対応コアネットワークノードと、多数の安価なＭＢＭＳ非対応コアネットワークノードを組み合わせて配備することで、全体の設備コストを効率化することが出来る（本発明者らの第１の知見）。

また、近年普及が進んでいる、３ＧＰＰにおけるマシン通信（ＭＴＣ：ＭａｃｈｉｎｅＴｙｐｅＣｏｍｍｕｎｉｃａｔｉｏｎ）デバイス（Ｍ２Ｍデバイス）は、通話等に用いる携帯電話端末やスマートフォン等の通常の端末（ハンドセット端末）とは、移動特性や要求される通信品質などが大きく異なる。ここで、マシン通信サービスとして、例えば自動販売機の在庫や課金の遠隔管理や、センサシスム等の遠隔監視制御、車両監視、スマートグリッド等のほか、多岐に渡ることが知られている。

しかしながら、通信事業者としては、全コアネットワークノードにおいて、ＭＴＣデバイスと、ハンドセット端末の双方を、問題なく接続できる能力・機能を具備しない場合には、ＭＴＣデバイスと、ハンドセット端末の双方に対してサービスを提供することが出来ない。

ＭＴＣデバイスとハンドセット端末を適切なコアネットワークノードに接続することができれば、通信事業者は、相対的に安価なハンドセット端末用コアネットワークノードと、相対的に安価なＭＴＣデバイス用コアネットワークノードとを組み合わせて配備することが出来る。ＭＴＣデバイスは、低アクセス優先情報、又は通信遅延に対する耐性情報をコアネットワークノードに通知する端末でもよい（本発明者らの第２の知見）。

これは、１つのノードでハンドセット端末と、ＭＴＣデバイスの両方に対応可能とした、相対的に高価なコアネットワークノードを配備するよりも、全体の設備コストを効率化することが出来る（本発明者らの第３の知見）。

したがって、本発明は、上記問題点を解決すべく創案されたものであり、その目的は、コアネットワーク全体の設備コストの低減を図り、効率的なハンドオーバ機能を提供する、システム、方法、装置を提供することにある。

前記課題を解決する本発明は、概略以下の構成とされる（ただし、以下に限定されない）。

本発明の１つの側面によれば、移動通信システムであって、端末（ＵＥ）と、ソースｅＮｏｄｅＢまたはソースＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）と、ターゲットｅＮｏｄｅＢと、特定の端末を専門に扱うコアネットワーク内のソースＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）またはソースＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳ（ＧｅｎｅｒａｌＰａｃｋｅｔＲａｄｉｏＳｅｒｖｉｃｅ）ＳｕｐｐｏｒｔＮｏｄｅ）と、前記特定の端末を専門に扱うコアネットワーク内のターゲットＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）と、ＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）サーバと、を有し、前記ソースｅＮｏｄｅＢまたは前記ソースＲＮＣが前記ターゲットｅＮｏｄｅＢにハンドオーバを開始し、前記ソースｅＮｏｄｅＢは前記ソースＭＭＥにＨａｎｄｏｖｅｒＲｅｑｕｉｒｅｄメッセージを送信し、あるいは、前記ソースＲＮＣが前記ソースＳＧＳＮにＲｅｌｏｃａｔｉｏｎＲｅｑｕｉｒｅｄメッセージを送信し、前記ソースＭＭＥまたは前記ソースＳＧＳＮは、前記ＤＮＳサーバを用いて前記ターゲットＭＭＥを選択する、移動通信システムが提供される。前記移動通信システムは、前記ターゲットＭＭＥの選択において前記特定の端末が保有するＬＡＰＩ（ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ）を用いてもよい。
あるいは、移動通信システムであって、端末（ＵＥ）と、ソースＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）またはソースｅＮｏｄｅＢと、ターゲットＲＮＣと、特定の端末を専門に扱うコアネットワーク内のソースＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳ（ＧｅｎｅｒａｌＰａｃｋｅｔＲａｄｉｏＳｅｒｖｉｃｅ）ＳｕｐｐｏｒｔＮｏｄｅ）またはソースＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）と、前記特定の端末を専門に扱うコアネットワーク内のターゲットＳＧＳＮと、ＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）サーバと、を有し、前記ソースＲＮＣまたは前記ソースｅＮｏｄｅＢが前記ターゲットＲＮＣにＲｅｌｏｃａｔｉｏｎを開始し、前記ソースＲＮＣが前記ソースＳＧＳＮにＲｅｌｏｃａｔｉｏｎＲｅｑｕｉｒｅｄメッセージを送信し、あるいは、前記ソースｅＮｏｄｅＢが前記ソースＭＭＥにＨａｎｄｏｖｅｒＲｅｑｕｉｒｅｄメッセージを送信し、前記ソースＳＧＳＮまたは前記ソースＭＭＥは、前記ＤＮＳサーバを用いて前記ターゲットＳＧＳＮを選択する、移動通信システムが提供される。前記移動通信システムは、前記ターゲットＳＧＳＮの選択において前記特定の端末が保有するＬＡＰＩ（ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ）を用いてもよい。

本発明の別の側面によれば、端末（ＵＥ）と、ソースｅＮｏｄｅＢまたはソースＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）と、ターゲットｅＮｏｄｅＢと、特定の端末を専用に扱うコアネットワーク内のソースＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）またはＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳ（ＧｅｎｅｒａｌＰａｃｋｅｔＲａｄｉｏＳｅｒｖｉｃｅ）ＳｕｐｐｏｒｔＮｏｄｅ）と、前記特定の端末を専門に扱うコアネットワーク内のターゲットＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）と、ＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）サーバと、を含む移動通信システムの通信方法であって、
前記ソースｅＮｏｄｅＢまたは前記ソースＲＮＣが前記ターゲットｅＮｏｄｅＢにハンドオーバを開始し、
前記ソースｅＮｏｄｅＢが前記ソースＭＭＥにＨａｎｄｏｖｅｒＲｅｑｕｉｒｅｄメッセージを送信し、あるいは、前記ソースＲＮＣが前記ＳＧＳＮにＲｅｌｏｃａｔｉｏｎＲｅｑｕｉｒｅｄメッセージを送信し、
前記ソースＭＭＥまたは前記ソースＳＧＳＮは、前記ＤＮＳサーバを用いて前記ターゲットＭＭＥを選択する、移動通信システムの通信方法が提供される。
あるいは、端末（ＵＥ）と、Ｒｅｌｏｃａｔｉｏｎ元のソースＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）またはソースｅＮｏｄｅＢと、Ｒｅｌｏｃａｔｉｏｎ先のターゲットＲＮＣと、特定の端末を専用に扱うコアネットワーク内のソースＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳ（ＧｅｎｅｒａｌＰａｃｋｅｔＲａｄｉｏＳｅｒｖｉｃｅ）ＳｕｐｐｏｒｔＮｏｄｅ）またはソースＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）と、前記特定の端末を専用に扱うコアネットワーク内のターゲットＳＧＳＮと、ＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）サーバと、を含む移動通信システムの通信方法であって、
前記ソースＲＮＣまたは前記ソースｅＮｏｄｅＢが前記ターゲットＲＮＣにＲｅｌｏｃａｔｉｏｎを開始し、
前記ソースＲＮＣが前記ソースＳＧＳＮにＲｅｌｏｃａｔｉｏｎＲｅｑｕｉｒｅｄメッセージを送信し、あるいは、前記ソースｅＮｏｄｅＢが前記ソースＭＭＥにＨａｎｄｏｖｅｒＲｅｑｕｉｒｅｄメッセージを送信し、
前記ソースＳＧＳＮまたは前記ソースＭＭＥが前記ＤＮＳサーバを用いて前記ターゲットＳＧＳＮを選択する、移動通信システムの通信方法が提供される。

本発明の別の側面によれば、移動通信システムに用いられ、ハンドオーバ機能を有する端末であって、ＬＡＰＩ（ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ）に関する情報を保有する手段と、前記端末に接続するソースｅＮｏｄｅＢまたはソースＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）からターゲットｅＮｏｄｅＢにハンドオーバする場合に、前記端末を専門に扱うコアネットワーク内のソースＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）またはソースＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳ（ＧｅｎｅｒａｌＰａｃｋｅｔＲａｄｉｏＳｅｒｖｉｃｅ）ＳｕｐｐｏｒｔＮｏｄｅ）に前記ＬＡＰＩを通知することにより前記端末を専門に扱うコアネットワーク内のターゲットＭＭＥの選択を指示する手段と、を有する、端末が提供される。
あるいは、移動通信システムに用いられ、ハンドオーバ機能を有する端末であって、ＬＡＰＩ（ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ）に関する情報を保有する手段と、前記端末に接続するソースｅＮｏｄｅＢまたはソースＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）からターゲットＲＮＣにハンドオーバする場合に、前記端末を専門に扱うコアネットワーク内のソースＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）またはソースＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳ（ＧｅｎｅｒａｌＰａｃｋｅｔＲａｄｉｏＳｅｒｖｉｃｅ）ＳｕｐｐｏｒｔＮｏｄｅ）に前記ＬＡＰＩを通知することにより前記端末を専門に扱うコアネットワーク内のターゲットＳＧＳＮの選択を指示する手段と、を有する、端末が提供される。

本発明によれば、コアネットワーク全体の設備コストの低減を図り、効率的なハンドオーバ機能を提供することができる。

本発明の第１の実施形態のシステム構成を例示する図である。本発明の第２の実施形態のシステム構成を例示する図である。本発明の第１の実施例のシーケンス例を例示する図である。本発明の第２の実施例のシーケンス例を例示する図である。本発明の第３の実施例のシーケンス例を例示する図である。本発明の第３の実施例のシーケンス例を例示する図である。本発明の第４の実施例のシーケンス例を例示する図である。本発明の第５の実施例のシーケンス例を例示する図である。本発明の第５の実施例のシーケンス例を例示する図である。本発明の第６の実施例のシーケンス例を例示する図である。本発明の第７の実施例のシーケンス例を例示する図である。本発明の第８の実施例のシーケンス例を例示する図である。本発明の第８の実施例のシーケンス例を例示する図である。本発明の第９の実施例のシーケンス例を例示する図である。本発明の第１０の実施例のシーケンス例を例示する図である。本発明の第１０の実施例のシーケンス例を例示する図である。本発明の第１１の実施例のシステム構成を例示する図である。本発明の第１１の実施例のシーケンス例を例示する図である。本発明の第１２の実施例のシステム構成を例示する図である。本発明の第１２の実施例のシステム構成を例示する図である。本発明の第１２の実施例のシーケンス例を示す図である。本発明の第１３、第１４の実施例のシーケンス例を示す図である。本発明の第１３、第１４の実施例のシーケンス例を示す図である。本発明の第１５の実施例のシーケンス例を示す図である。本発明の第１６の実施例のシーケンス例を示す図である。

本発明のいくつかの形態の１つによれば、移動体通信システムのコアネットワークが、端末のモビリティ管理ノードとして、前記端末が利用するサービス特性又は端末種別に応じて選択される特定モビリティ管理ノード（特定ＭＭＥ／特定ＳＧＳＮ）を備え、前記モビリティ管理ノードを跨ぐハンドオーバが起動されると、前記特定モビリティ管理ノードは、保持している、特定モビリティ管理ノード接続要求情報に応じて、ハンドオーバ先のモビリティ管理ノードを選択する。

コアネットワークが、端末に対して提供するサービス機能が異なる複数のノード（２１／２２、又は、１２１／１２２）を備え、加入者情報と端末情報に基づき、前記端末に接続するノードを、前記端末が利用するサービス特性又は端末種別に応じて、前記複数のノードから選択し、前記端末（１）と前記選択されたノードとが接続する。すなわち、コアネットワークでは、予め定められた特定のサービス提供機能を具備したノード（２２、又は１２２）と、当該特定のサービス提供機能を具備しないノード（２１、又は１２１）を、組み合わせて配備する。

このため、特定サービス提供機能に最適化したノードと、特定サービス提供機能自体を具備しないノードとに分離することが可能とされ、ノードのコストの低減を可能としている。

本発明によれば、移動体通信ネットワークにおいて、サービス特性や端末種別などの条件に応じて、端末が特定のコアネットワークノードに接続できるようにし、さらにハンドオーバを可能としたものである。

＜態様１＞
ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ：ユーザ装置、端末、移動機ともいう）から、アタッチリクエスト（ＡｔｔａｃｈＲｅｑｕｅｓｔ）を受信した、一般ＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ：モビリティ管理エンティティ）は、前記ＵＥを、特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ、ＳｐｅｃｉｆｉｃＭＭＥ）に接続するために、ｅＮｏｄｅＢ（ｅｖｏｌｖｅｄＮｏｄｅＢ：基地局装置）に対して、ＭＭＥ再選択要求信号（モビリティ管理エンティティ再選択要求信号）を送信する。なお、ＭＭＥ再選択要求信号は、ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓでもよい。ＬＡＰＩは、Ｍ２Ｍ通信を一般の音声データ通信よりも低い優先度に設定するものである。例えばＭＴＣデバイスがネットワークに位置登録や発信するたびにＬＡＰＩがネットワークに通知され（例えばＮＡＳ（Ｎｏｎ−ＡｃｃｅｓｓＳｔｒａｔｕｍ）プロトコルのアタッチ要求信号がＬＡＰＩを含む）、ｅＮｏｄｅＢ、ＭＭＥ、ＳＧＷ（ＳｅｒｖｉｎｇＧａｔｅｗａｙ）、ＰＧＷ（ＰＤＮ（ＰａｃｋｅｔＤａｔａＮｅｔｗｏｒｋｓ）Ｇａｔｅｗａｙ）等で保持される。またｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓは、例えばＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）ｃｏｎｎｅｃｔｉｏｎｒｅｑｕｅｓｔメッセージに設定され、ネットワークが過負荷（ｏｖｅｒｌｏａｄ）となった場合の制御を行うために導入されている（例えば３ＧＰＰＴｅｃｈｎｉｃａｌＳｐｅｃｉｆｉｃａｔｉｏｎ２３．３６８）。ＬＡＰＩ、又はｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓは、例えばＭＴＣデバイス（ＭＴＣ端末）がネットワークに通知する情報要素であり、これらの情報要素を基（目印）に、基地局（ｅＮｏｄｅＢ）でＭＭＥを特定するようにしてもよい。
基地局（ｅＮｏｄｅＢ）は、ローアクセスプライオリティ（ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙ）の端末（ＵＥ）に対して前記特定ＭＭＥを選択するようにしてもよい。前記ローアクセスプライオリティ（ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙ）の端末（ＵＥ）はＭＴＣ機能を有する端末である。前記ローアクセスプライオリティ（ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙ）構成の端末（ＵＥ）は、前記基地局にＲＲＣコネクション要求が前記ローアクセスプライオリティ（ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙ）であることを指示する情報（ＬＡＰＩ）を提供し、前記基地局（ｅＮｏｄｅＢ）は、前記端末からの情報（ＬＡＰＩ）を用いて、ローアクセスプライオリティ（ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙ）構成の端末（ＵＥ）を、前記特定ＭＭＥに向けるようにしてもよい。

前記ｅＮｏｄｅＢは、前記特定ＭＭＥに、ＡｔｔａｃｈＲｅｑｕｅｓｔを再送することで、ＵＥを特定ＭＭＥへ接続している。

＜態様２＞
ＵＥからＡｔｔａｃｈＲｅｑｕｅｓｔを受信した一般ＭＭＥは、前記ＵＥを、特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）に接続するために、前記特定ＭＭＥに対して、ＭＭＥ変更要求信号（モビリティ管理エンティティ変更要求信号）を送信する。前記特定ＭＭＥは、アタッチ処理（ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅ）を継続することで、前記ＵＥを特定ＭＭＥへ接続している。

＜態様３＞
ＵＥからＡｔｔａｃｈＲｅｑｕｅｓｔを受信した一般ＭＭＥは、前記ＵＥを特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）に接続するために、前記特定ＭＭＥの識別子を付与したアタッチリジェクト（ＡｔｔａｃｈＲｅｊｅｃｔ）を、前記ＵＥに送信する。前記ＵＥは、ＡｔｔａｃｈＲｅｑｕｅｓｔに、特定ＭＭＥの識別子を付与して、再送信することで、前記ＵＥを、前記特定ＭＭＥへ接続している。

＜態様４＞
ＵＥは、特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）接続要求情報を付与したＲＲＣコネクションリクエスト（ＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）ＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ）（無線リソース接続要求）を、ｅＮｏｄｅＢに送信し、ＲＲＣコネクションリクエストを受信したｅＮｏｄｅＢは、ＲＲＣコネクション（ＲＲＣＣｏｎｎｅｃｔｉｏｎ）を確立した前記ＵＥからのＡｔｔａｃｈＲｅｑｕｅｓｔを、ＭＭＥに送信する際に、前記特定ＭＭＥを選択することで、前記ＵＥを前記特定ＭＭＥへ接続している。なお、特定ＭＭＥ接続要求情報は、ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓでもよい。ＬＡＰＩ、又はｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓは、例えばＭＴＣ端末がネットワークに通知する情報要素であり、これらの情報要素を基に基地局（ｅＮｏｄｅＢ）でＭＭＥを特定するようにしてもよい。

＜態様４−１＞
前記ＵＥから、特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）に接続するための特定ＭＭＥ接続要求情報を付与したＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）信号を受信した前記ｅＮｏｄｅＢは、前記特定ＭＭＥ接続要求情報をＳ１−ＡＰ信号にて特定ＭＭＥに通知する。

＜態様４−２＞
前記ｅＮｏｄｅＢから前記特定ＭＭＥ接続要求情報をＳ１−ＡＰ信号にて受信した特定ＭＭＥは、前記特定ＭＭＥ接続要求情報を保持する。

＜態様５＞
ＵＥとセッションを確立している一般ＭＭＥは、ｅＮｏｄｅＢと前記一般ＭＭＥとの間で確立されているＳ１コネクションの開放（Ｓ１Ｒｅｌｅａｓｅ）時に、次回にＭＭＥを選択する際に、特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）を選択するように、前記ｅＮｏｄｅＢに指示をし、その後、前記ＵＥが、位置管理エリア更新リクエスト（ＴＡ（ＴｒａｃｋｉｎｇＡｒｅａ）ＵｐｄａｔｅＲｅｑｕｅｓｔ）を送信した際に、前記ｅＮｏｄｅＢが前記特定ＭＭＥを選択することで、前記ＵＥを特定ＭＭＥへ接続している。

＜態様６＞
ＵＥからＡｔｔａｃｈＲｅｑｕｅｓｔを受信した一般ＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳ（ＧｅｎｅｒａｌＰａｃｋｅｔＲａｄｉｏＳｅｒｖｉｃｅ）ＳｕｐｐｏｒｔＮｏｄｅ：特許請求の範囲では「サービングＧＰＲＳサポートノード」と表記）は、前記ＵＥを特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）に接続するために、ＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ：無線ネットワークコントローラ）に、ＳＧＳＮ再選択要求信号を送信し、前記ＲＮＣは、前記特定ＳＧＳＮに、ＡｔｔａｃｈＲｅｑｕｅｓｔを再送することで、前記ＵＥを前記特定ＳＧＳＮへ接続している。なお、ＳＧＳＮ再選択要求信号は、ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓでもよい。すなわち、例えばＭＴＣ端末からネットワークに通知する、ＬＡＰＩ、ｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓ等の情報要素を基に、ＲＮＣでＳＧＳＮを特定するようにしてもよい。

＜態様７＞
ＵＥからＡｔｔａｃｈＲｅｑｕｅｓｔを受信した一般ＳＧＳＮは、前記ＵＥを特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）に接続するために、前記特定ＳＧＳＮにＳＧＳＮ変更要求信号を送信し、前記特定ＳＧＳＮはアタッチ処理（ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅ）を継続することで、前記ＵＥを前記特定ＳＧＳＮへ接続している。

＜態様８＞
ＵＥからＡｔｔａｃｈＲｅｑｕｅｓｔを受信した一般ＳＧＳＮは、前記ＵＥを特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）に接続するために、前記特定ＳＧＳＮの識別子を付与したアタッチリジェクト（ＡｔｔａｃｈＲｅｊｅｃｔを前記ＵＥに送信し、前記ＵＥは、ＡｔｔａｃｈＲｅｑｕｅｓｔに、特定ＳＧＳＮ識別子を付与して再送信することで、前記ＵＥを前記特定ＳＧＳＮへ接続している。

＜態様９＞
ＵＥは、特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）接続要求情報を付与したコネクションリクエスト（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ）をＲＮＣに送信し、該リクエストを受信したＲＮＣは、ＲＲＣコネクション（ＲＲＣＣｏｎｎｅｃｔｉｏｎ）を確立した前記ＵＥからのＡｔｔａｃｈＲｅｑｕｅｓｔをＳＧＳＮに送信する際に、前記特定ＳＧＳＮを選択することで、前記ＵＥを特定ＳＧＳＮへ接続している。なお、特定ＳＧＳＮ接続要求情報は、ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓでもよい。すなわち、例えばＭＴＣ端末からネットワークに通知する、ＬＡＰＩ、ｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓ等の情報要素を基にＲＮＣでＳＧＳＮを特定するようにしてもよい。

＜態様９−１＞
前記ＵＥから、特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）に接続するための前記特定ＳＧＳＮ接続要求情報を付与したＲＲＣ信号を受信した前記ＲＮＣは、前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて特定ＳＧＳＮに通知する。

＜態様９−２＞
前記ＲＮＣから前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて受信した特定ＳＧＳＮは、前記特定ＳＧＳＮ接続要求情報を保持する。

＜態様１０＞
ＵＥとセッションを確立している一般ＳＧＳＮは、Ｉｕ開放（ＩｕＲｅｌｅａｓｅ）時に、次回ＳＧＳＮ選択で特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）を選択するようにＲＮＣに指示をし、その後、前記ＵＥが、位置管理エリア更新リクエスト（ＲＡ（ＲｏｕｔｉｎｇＡｒｅａ）ＵｐｄａｔｅＲｅｑｕｅｓｔ）を送信した際に、ＲＮＣが特定ＳＧＳＮを選択することで、ＵＥを特定ＳＧＳＮへ接続している。

＜態様１１＞
ＭＭＥを跨ぐハンドオーバが起動されると前記特定ＭＭＥは、保持している前記特定ＭＭＥ接続要求情報に応じてハンドオーバ先のＭＭＥを選択する。なお、特定ＭＭＥ接続要求情報は、ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓ等の情報要素を基にＭＭＥを特定するようにしてもよい。

＜態様１１−１＞
前記特定ＭＭＥは、ハンドオーバ先のＭＭＥの選択を行う際、保持している前記特定ＭＭＥ接続要求情報を元にローカルコンフィグレーションで決定してもよい。あるいは、前記特定ＭＭＥは、保持しているローカルコンフィグレーションを用いてハンドオーバ先のＭＭＥを決定してもよい。

＜態様１１−２＞
前記特定ＭＭＥは、ハンドオーバ先のＭＭＥの選択を行う際、保持している前記特定ＭＭＥ接続要求情報を元にＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）サーバに問い合わせを行い、その結果としてＤＮＳサーバから受信したハンドオーバ先のＭＭＥの候補群の中から選択してもよい。

＜態様１１−３＞
加入者の位置情報、及び前記特定ＭＭＥ接続要求情報などを入力情報として、１つ又は複数のＭＭＥを提供可能なＤＮＳサーバ。

＜態様１１−４＞
ＭＭＥを跨ぐハンドオーバが起動された際、ハンドオーバ元前記特定ＭＭＥは保持している前記特定ＭＭＥ接続要求情報をハンドオーバ先の特定ＭＭＥに通知する。

＜態様１２＞
ＳＧＳＮを跨ぐハンドオーバが起動されると、前記特定ＳＧＳＮは、保持している前記特定ＳＧＳＮ接続要求情報に応じてハンドオーバ先のＳＧＳＮを選択する。なお、特定ＳＧＳＮ接続要求情報は、ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓ等の情報要素を基にＳＧＳＮを特定するようにしてもよい。

＜態様１２−１＞
前記特定ＳＧＳＮは、ハンドオーバ先のＳＧＳＮの選択を行う際、保持している前記特定ＳＧＳＮ接続要求情報を元にローカルコンフィグレーションで決定してもよい。あるいは、前記特定ＳＧＳＮは、保持しているローカルコンフィグレーションを用いてハンドオーバ先のＳＧＳＮを決定してもよい。

＜態様１２−２＞
前記特定ＳＧＳＮは、ハンドオーバ先のＳＧＳＮの選択を行う際、保持している前記特定ＳＧＳＮ接続要求情報を元にＤＮＳサーバに問い合わせを行い、その結果としてＤＮＳサーバから受信したハンドオーバ先のＳＧＳＮの候補群の中から選択してもよい。

＜態様１２−３＞
加入者の位置情報、及び前記特定ＳＧＳＮ接続要求情報などを入力情報として、１つ或いは複数のＳＧＳＮを提供可能なＤＮＳサーバ。

＜態様１２−４＞
ＳＧＳＮを跨ぐハンドオーバが起動された際、ハンドオーバ元前記特定ＳＧＳＮは保持している前記特定ＳＧＳＮ接続要求情報をハンドオーバ先特定ＳＧＳＮに通知する。

＜態様１３＞
ＭＭＥからＳＧＳＮに移動するハンドオーバが起動されると前記特定ＭＭＥは、保持している前記特定ＭＭＥ接続要求情報に応じてハンドオーバ先のＭＭＥを選択する。なお、特定ＭＭＥ接続要求情報は、ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓ等の情報要素を基にＭＭＥを特定するようにしてもよい。

＜態様１３−１＞
前記特定ＭＭＥは、ハンドオーバ先のＳＧＳＮの選択を行う際、保持している前記特定ＭＭＥ接続要求情報を元にローカルコンフィグレーションで決定してもよい。あるいは、前記特定ＭＭＥは、保持しているローカルコンフィグレーションを用いてハンドオーバ先のＳＧＳＮを決定してもよい。

＜態様１３−２＞
前記特定ＭＭＥは、ハンドオーバ先のＳＧＳＮの選択を行う際、保持している前記特定ＭＭＥ接続要求情報を元にＤＮＳサーバに問い合わせを行い、その結果としてＤＮＳサーバから受信したハンドオーバ先のＭＭＥの候補群の中から選択してもよい。

＜態様１３−３＞
ＭＭＥからＳＧＳＮに移動するハンドオーバが起動された際、ハンドオーバ元前記特定ＭＭＥは保持している前記特定ＭＭＥ接続要求情報をハンドオーバ先特定ＳＧＳＮに通知する。

＜態様１３−４＞
前記特定ＭＭＥ接続要求情報と、前記特定ＳＧＳＮ接続要求情報が区別無く、同一の情報として扱われるシステム。

＜態様１３−５＞
前記特定ＭＭＥ接続要求情報と、前記特定ＳＧＳＮ接続要求情報とが、それぞれ別の情報として扱われるシステム。

＜態様１４＞
ＳＧＳＮからＭＭＥに移動するハンドオーバが起動されると、前記特定ＳＧＳＮは、保持している前記特定ＳＧＳＮ接続要求情報に応じて、ハンドオーバ先のＭＭＥを選択する。なお、特定ＳＧＳＮ接続要求情報は、ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓ等の情報要素を基に、ＭＭＥを特定するようにしてもよい。

＜態様１４−１＞
前記特定ＳＧＳＮは、ハンドオーバ先のＭＭＥの選択を行う際、保持している前記特定ＳＧＳＮ接続要求情報を元にローカルコンフィグレーションで決定してもよい。あるいは、前記特定ＳＧＳＮは、保持しているローカルコンフィグレーションを用いてハンドオーバ先のＭＭＥを決定してもよい。

＜態様１４−２＞
前記特定ＳＧＳＮは、ハンドオーバ先のＭＭＥの選択を行う際、保持している前記特定ＳＧＳＮ接続要求情報を元にＤＮＳサーバに問い合わせを行い、その結果としてＤＮＳサーバから受信したハンドオーバ先のＭＭＥの候補群の中から選択してもよい。

＜態様１４−３＞
ＳＧＳＮからＭＭＥに移動するハンドオーバが起動された際、ハンドオーバ元前記特定ＳＧＳＮは保持している前記特定ＳＧＳＮ接続要求情報をハンドオーバ先特定ＭＭＥに通知する。

＜態様１４−４＞
前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報が区別無く同一の情報として扱われるシステム。

＜態様１４−５＞
前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報がそれぞれ別の情報として扱われるシステム。

＜態様１５＞
ＵＥは、特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）接続要求情報を付与したＲＲＣコネクションリクエスト（ＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）ＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ）（無線リソース接続要求）を、ｅＮｏｄｅＢに送信し、ＲＲＣコネクションリクエストを受信したｅＮｏｄｅＢは、ＲＲＣコネクション（ＲＲＣＣｏｎｎｅｃｔｉｏｎ）を確立した前記ＵＥからのＴｒａｃｋｉｎｇＡｒｅａＵｐｄａｔｅＲｅｑｕｅｓｔを、ｎｅｗＭＭＥに送信する際に、前記特定ＭＭＥを選択することで、前記ＵＥを前記特定ＭＭＥへ接続している。なお、特定ＭＭＥ接続要求情報は、ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓ等の情報要素を基にｅＮｏｄｅＢでＭＭＥを特定するようにしてもよい。

＜態様１５−１＞
前記ＵＥから、特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）に接続するための前記特定ＭＭＥ接続要求情報を付与したＲＲＣ信号を受信した前記ｅＮｏｄｅＢは、前記特定ＭＭＥ接続要求情報をＳ１−ＡＰ信号にて特定ＭＭＥに通知する。

＜態様１５−２＞
前記ｅＮｏｄｅＢから前記特定ＭＭＥ接続要求情報をＳ１−ＡＰ信号にて受信した特定ＭＭＥは、前記特定ＭＭＥ接続要求情報を保持する。

＜態様１５−３＞
前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報が区別無く同一の情報として扱われるシステム。

＜態様１５−４＞
前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報がそれぞれ別の情報として扱われるシステム。

＜態様１６＞
ＵＥは、特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）接続要求情報を付与したコネクションリクエスト（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ）をＲＮＣに送信し、該リクエストを受信したＲＮＣは、ＲＲＣコネクション（ＲＲＣＣｏｎｎｅｃｔｉｏｎ）を確立した前記ＵＥからのＲｏｕｔｉｎｇＡｒｅａＵｐｄａｔｅＲｅｑｕｅｓｔをｎｅｗＳＧＳＮに送信する際に、前記特定ＳＧＳＮを選択することで、前記ＵＥを特定ＳＧＳＮへ接続している。なお、特定ＳＧＳＮ接続要求情報は、ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ、又はｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓ等の情報要素を基にＲＮＣでＳＧＳＮを特定するようにしてもよい。

＜態様１６−１＞
前記ＵＥから、特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）に接続するための前記特定ＳＧＳＮ接続要求情報を付与したＲＲＣ信号を受信した前記ＲＮＣは、前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて特定ＳＧＳＮに通知する。

＜態様１６−２＞
前記ＲＮＣから前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて受信した特定ＳＧＳＮは、前記特定ＳＧＳＮ接続要求情報を保持する。

＜態様１６−３＞
前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報が区別無く同一の情報として扱われるシステム。

＜態様１６−４＞
前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報がそれぞれ別の情報として扱われるシステム。

上記態様１乃至１６に記載したように、本発明によれば、端末毎に接続するコアネットワークノードを、端末の利用するサービス特性に応じて選択して接続する構成としている。こうすることで、コアネットワークでは、特定のサービス提供機能を具備したノードと具備しないノードを、組み合わせて配備し、各ノードのうち、あるノードを特定サービス提供機能に最適化し、他のノードは当該特定サービス提供機能を具備しないという具合に差異を設けることで、ノードのコストの低減を図るようにしている。以下、図面を参照して、いくつかの実施形態と具体的な実施例に即して説明する。

＜実施形態１＞
図１は、本発明の実施形態１を説明する図である。実施形態１として、ＥＰＣ（ＥｖｏｌｖｅｄＰａｃｋｅｔＣｏｒｅ）において、Ａｔｔａｃｈ時に、ＵＥと特定ＭＭＥを接続させる構成について説明する。

図１において、ＵＥ１（ユーザ装置）は、例えば携帯電話端末（移動機）を示す。あるいは、例えば上記したＭＴＣデバイス、ＭＢＭＳ対応端末等であってもよい。

ｅＮｏｄｅＢ１１は、ＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ）の基地局装置である。

ＭＭＥ２１、２２は、ＥＰＣで導入されたモビリティを管理する装置である。ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、ＵＥ１を接続させたい特定ＭＭＥであり、一般ＭＭＥ（２１）は、それ以外のＭＭＥである。特に制限されないが、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、例えばマシン通信（ＭＴＣ）サービスと、対応端末（Ｍ２Ｍデバイス）向けにカスタマイズした構成（例えばネットワーク制御を扱うＣ−Ｐｌａｎｅを補強）のＭＭＥとして構成される。あるいは、ＭＢＭＳ対応のＭＭＥとして構成してもよい。

ＨＳＳ（ＨｏｍｅＳｕｂｓｃｒｉｂｅｒＳｅｒｖｅｒ）３１は、加入者情報を保持するデータベースである。

Ｓ−ＧＷ（ＳｅｒｖｉｎｇＧａｔｅＷａｙ）４１、及びＰ−ＧＷ（ＰａｃｋｅｔｄａｔａｎｅｔｗｏｒｋＧａｔｅＷａｙ:ＰＤＮ−ＧＷともいう）５１は、ユーザプレーンを扱う装置である。

サービスネットワーク６１は、外部ネットワークを示す。

図１において、ｅＮｏｄｅＢが無線アクセスネットワーク（ＲＡＮ：ＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）、ＭＭＥ、Ｓ−ＧＷ、Ｐ−ＧＷ等がコアネットワーク（ＣＮ：ＣｏｒｅＮｅｔｗｏｒｋ）に対応する。

以下、上記した実施形態１について、制御方式が互いに相違した、いくつかの実施例を説明する。実施例１−５は上記態様１−５にそれぞれ対応する。

＜実施例１＞
図３は、実施例１の動作例を説明するためのシーケンス図である。図３において、
ＵＥは図１のＵＥ１、
ｅＮｏｄｅＢは図１のｅＮｏｄｅＢ１１、
一般ＭＭＥは図１の一般ＭＭＥ２１、
ＣｕｓｔｏｍｉｚｅｄＭＭＥは、図１のＣｕｓｔｏｍｉｚｅｄＭＭＥ（特定ＭＭＥ）２２、
ＳｅｒｖｉｎｇＧＷは、図１のＳ−ＧＷ４１、
ＰＤＮＧＷは、図１のＰ−ＧＷ５１、
ＨＳＳは、図１のＨＳＳ３１にそれぞれ対応する。

ＰＣＲＦは、ポリシと課金ルール機能（ＰｏｌｉｃｙａｎｄＣｈａｒｇｉｎｇＲｕｌｅｓＦｕｎｃｔｉｏｎ）である。また、ＥＩＲ（ＥｑｕｉｐｍｅｎｔＩｄｅｎｔｉｔｙＲｅｇｉｓｔｅｒ）は、ＩＭＥＩ（ＩｎｔｅｒｎａｔｉｏｎａｌＭｏｂｉｌｅＥｑｕｉｐｍｅｎｔＩｄｅｎｔｉｔｙ）等を保持し、ＭＭＥとＳ１３インタフェースで接続される。

なお、図３において、例えば「１．ＡｔｔａｃｈＲｅｑｕｅｓｔ」は、ＵＥからｅＮｏｄｅＢへのＡｔｔａｃｈＲｅｑｕｅｓｔの送信がシーケンス１であることを表わしている。図のＵＥの参照符号１（構成要素の参照符号）とは異なることを区別するため、以下の説明では、このシーケンス番号１を、「ＡｔｔａｃｈＲｅｑｕｅｓｔ（１）」のように、括弧書きで表記する。他のシーケンス番号についても同様とする。また、図４以降のシーケンス図についても同様の表記とする。なお、図３は、３ＧＰＰＴＳ２３．４０１のＦｉｇｕｒｅ５．３．２．１−１：Ａｔｔａｃｈｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１５．３．２の記載が参照される。以下、図１及び図３を参照して、動作シーケンスを説明する。

図３を参照すると、ＵＥ１が、ＡｔｔａｃｈＲｅｑｕｅｓｔ（１）を送信すると、まず、ｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１は、ＭＭＥに、ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）を中継する。

この時、ｅＮｏｄｅＢ１１は、ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）を一般ＭＭＥ２１に転送するべきか、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に転送するべきか、一意に決定することが出来ない。そのため、ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）は、ｅＮｏｄｅＢ１１から一般ＭＭＥ２１に転送される場合がある。

一般ＭＭＥ２１では、ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）を受信した後、ＩｄｅｎｔｉｔｙＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（４、５ｂ）にて、ＵＥ１から、端末情報（ＭＥＩｄｅｎｔｉｔｙ）を取得する。

なお、一般ＭＭＥ２１は、ＭＥＩｄｅｎｔｉｔｙＣｈｅｃｋＲｅｑｕｅｓｔ（５ｂ）をＥＩＲに送り、ＥＩＲはＭＤＩｄｅｎｔｉｔｙＣｈｅｃｋＡｃｋを一般ＭＭＥに返す。更に、ＨＳＳ３１と連携して、認証及び加入者プロファイルの取得を行う。すなわち、認証、加入者プロファイル取得まで、一般ＭＭＥ２１で行う。

端末情報及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に接続するべきか判断する。

一般ＭＭＥ２１に接続する場合、通常のＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続する。

ＵＥ１を、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に接続する場合、一般ＭＭＥ２１は、ｅＮｏｄｅＢ１１に対して、ＭＭＥ再選択を指示するために、ＭＭＥ選択信号：ＭＭＥｒｅ−ｓｅｌｅｃｔｉｏｎＣｏｍｍａｎｄ（本実施形態で新規に導入した、Ｓ１ＡＰ（Ｓ１アプリケーション）信号）を送信する。

この時、一般ＭＭＥ２１は、ＭＭＥｒｅ−ｓｅｌｅｃｔｉｏｎＣｏｍｍａｎｄ信号に、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２の識別子（例えばＧＵＭＭＥＩ（ＧｌｏｂａｌｌｙＵｎｉｑｕｅＭＭＥＩｄｅｎｔｉｔｙ））を設定する。すなわち、コアネットワーク内でベアラ生成前にｅＮｏｄｅＢに再選択要求を送信し、新たなＭＭＥ選択に必要な情報（ＧＵＭＭＥＩ）を載せる。ＭＭＥは、ＵＥが、ｒｅ−ｓｅｌｅｃｔｉｏｎ対象であるか否かを判断する機能を具備する。

ｅＮｏｄｅＢ１１は、ＭＭＥｒｅ−ｓｅｌｅｃｔｉｏｎＣｏｍｍａｎｄ信号を受信すると、この信号に設定された識別子に従って、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２を選択し、ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）をＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に転送する。特定ＭＭＥ２２では、ＡｔｔａｃｈＲｅｑｕｅｓｔのＮＡＳ（Ｎｏｎ−ＡｃｃｅｓｓＳｔｒａｔｕｍ）パラメータ（ＵＥとＭＭＥ間の認証に用いられる）が必要であるため、ｅＮｏｄｅＢ１１で再送する。ｅＮｏｄｅＢ１１では、ＮＡＳメッセージを保持する機能が必要である。

新ＭＭＥ（＝ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２）では、旧ＭＭＥ（＝一般ＭＭＥ）を特定できないため、コンテキスト（Ｃｏｎｔｅｘｔ）を、旧ＭＭＥ（＝一般ＭＭＥ）から引き継ぐことはできない。そのため、新ＭＭＥ（＝ＣｕｓｔｏｍｉｚｅｄＭＭＥＭＭＥ２２）では、再度、認証／加入者プロファイルの取得を行う必要がある。

ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、ＡｔｔａｃｈＲｅｑｕｅｓｔ信号を受信した後、ＩｄｅｎｔｉｔｙＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅにて端末情報を取得し、更にＨＳＳ３１と連携して、認証及び加入者プロファイルの取得を行う。すなわち、一般ＭＭＥ２１と同様の処理を行う。

端末情報及び加入者プロファイルを取得したＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、ＵＥ１を、一般ＭＭＥ２１に接続するべきか、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に接続するべきか判断する。

ここでは、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、ｅＮｏｄｅＢ１１で再選択された後である為、ＭＭＥｒｅ−ｓｅｌｅｃｔｉｏｎＣｏｍｍａｎｄ信号を送信せずに、通常のＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続する。すなわち、
・ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２からＨＳＳ３１へのＵｐｄａｔｅＬｏｃａｔｉｏｎＲｅｑｕｅｓｔ（８）の送信、
・ＨＳＳ３１からＣｕｓｔｏｍｉｚｅｄＭＭＥ２２へのＵｐｄａｔｅＬｏｃａｔｉｏｎＡｃｋ（１１）の送信、
・ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２からＳ−ＧＷ４１へのＣｒｅａｔｅＳｅｓｓｉｏｎＲｅｑｕｅｓｔ（１２）の送信、
・Ｓ−ＧＷ４１からＰ−ＧＷ５１へのＣｒｅａｔｅＳｅｓｓｉｏｎＲｅｑｕｅｓｔ（１２）の送信、
・Ｐ−ＧＷ５１とＰＣＲＦでのＰＣＥＦ（ＰｏｌｉｃｙａｎｄＣｈａｒｇｉｎｇＲｕｌｅｓＦｕｎｃｔｉｏｎ）ＩｎｉｔｉａｔｅｄＩＰ−ＣＡＮ（ＩＰＣｏｎｎｅｃｔｉｖｉｔｙＡｃｃｅｓｓＮｅｔｗｏｒｋ）ＳｅｓｓｉｏｎＥｓｔａｂｌｉｓｈｍｅｎｔ／Ｍｏｄｉｆｉｃａｔｉｏｎ手順（１４）、
・Ｐ−ＧＷ５１からＳ−ＧＷ４１へのＣｒｅａｔｅＳｅｓｓｉｏｎＲｅｓｐｏｎｃｅ（１５）の送信、
・Ｐ−ＧＷ５１からＳ−ＧＷ４１へのＦｉｒｓｔＤｏｗｎＬｉｎｋＤａｔａの送信（ハンドオーバ（ＨＯ）でない場合）、
・Ｓ−ＧＷ４１からＣｕｓｔｏｍｉｚｅｄＭＭＥ２２へのＣｒｅａｔｅＳｅｓｓｉｏｎＲｅｓｐｏｎｃｅ（１６）の送信、
・ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２からｅＮｏｄｅＢ１１へのＩｎｉｔｉａｌＣｏｎｔｅｘｔＳｅｔｕｐＲｅｑｕｅｓｔ／ＡｔｔａｃｈＡｃｃｅｐｔ（１７）の送信、
・ｅＮｏｄｅＢ１１からＵＥ１へのＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ（１８）の送信、
・ＵＥ１からｅＮｏｄｅＢ１１へのＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ（１９）の送信、
・ｅＮｏｄｅＢ１１からＣｕｓｔｏｍｉｚｅｄＭＭＥ２２へのＩｎｉｔｉａｎｌＣｏｎｔｅｘｔＳｅｔｕｐＲｅｓｐｏｎｃｅ（２０）の送信、
・ＵＥ１からｅＮｏｄｅＢ１１へのＤｉｒｅｃｔＴｒａｎｓｆｅｒ（２１）の送信、
・ｅＮｏｄｅＢ１１からＣｕｓｔｏｍｉｚｅｄＭＭＥ２２へのＡｔｔａｃｈＣｏｍｐｌｅｔｅ（２２）の送信、
・ＵＥ１からＳ−ＧＷ４１、Ｐ−ＧＷ５１へのＦｉｒｓｔＵｐｌｉｎｋｄａｔａの送信、
・ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２からＳ−ＧＷ４１へのＭｏｄｉｆｙＢｅａｅｒＲｅｑｕｅｓｔ（２３）の送信、
・Ｓ−ＧＷ４１からＰ−ＧＷ５１ヘのＭｏｄｉｆｙＢｅａｅｒＲｅｑｕｅｓｔ（２３ａ）の送信、
・Ｐ−ＧＷ５１からＳ−ＧＷ４１へのＭｏｄｉｆｙＢｅａｅｒＲｅｓｐｏｎｃｅ（２３ｂ）の送信、
・Ｓ−ＧＷ４１からＣｕｓｔｏｍｉｚｅｄＭＭＥ２２へのＭｏｄｉｆｙＢｅａｅｒＲｅｓｐｏｎｃｅ（２４）の送信、
・Ｐ−ＧＷ５１、Ｓ−ＧＷ４１からＵＥ１への最初のダウンリンクデータ（ＦｉｒｓｔＤｏｗｎｌｉｎｋｄａｔａ）の送信、
が行われる。

また、一般ＭＭＥ２１及びＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、ＵＥ１を、どのＭＭＥに接続させるべきか判断する機能を具備するが、この判断は、
ＵＥ１からの情報、例えば、
・ＩＭＳＩ（ＩｎｔｅｒｎａｔｉｏｎａｌＭｏｂｉｌｅＳｕｂｓｃｒｉｂｅｒＩｄｅｎｔｉｔｙ：国際移動体加入者識別番号）、
・ＩＭＥＩ（ＩｎｔｅｒｎａｔｉｏｎａｌＭｏｂｉｌｅＥｑｕｉｐｍｅｎｔＩｄｅｎｔｉｔｙ：国際移動体装置識別番号（端末識別番号））、
・ＵＥｎｅｔｗｏｒｋｃａｐａｂｉｌｉｔｙ、
・ＭＳｎｅｔｗｏｒｋｃａｐａｂｉｌｉｔｙ、
・Ｍｏｂｉｌｅｓｔａｔｉｏｎｃｌａｓｓｍａｒｋ２、
・Ｍｏｂｉｌｅｓｔａｔｉｏｎｃｌａｓｓｍａｒｋ３、
・Ｄｅｖｉｃｅｐｒｏｐｅｒｔｉｅｓ、又は、
・ＡＰＮ（ＡｃｃｅｓｓＰｏｉｎｔＮａｍｅ）、又は、
・ＭＴＣグループを識別するＩＤ、又は、
・ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ、又は、
・ｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓ、又は、
・今後追加されるＡｔｔａｃｈＲｅｑｕｅｓｔ、また、ＴＡＵｐｄａｔｅＲｅｑｕｅｓｔなどのその他のＮＡＳ信号の新規パラメータ、又は、
・これらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ（ＰｕｂｌｉｃｌａｎｄＭｏｂｉｌｅＮｅｔｗｏｒｋ）−ｉｄなど）、
ＨＳＳ３１からの情報、例えば、
・Ｆｅａｔｕｒｅ−Ｌｉｓｔ、
・ＡＰＮ（ＡｃｃｅｓｓＰｏｉｎｔＮａｍｅ）、又は、
・今後追加されるＵｐｄａｔｅＬｏｃａｔｉｏｎＡｎｓｗｅｒ／ＩｎｓｅｒｔＳｕｂｓｃｒｉｂｅｒＤａｔａＲｅｑｕｅｓｔ信号の新規パラメータ、又は、
・これらのパラメータを構成する一部分の識別子、
のいずれか、もしくは複数、
を組み合わせた上で行う。

また、図３では、図示されていないが、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に対して、一般ＭＭＥ２１に接続すべきＵＥ１からのＡｔｔａｃｈＲｅｑｕｅｓｔ信号が転送された場合も、同様の手段で、ｅＮｏｄｅＢ１１に対して、ＭＭＥ再選択を促すことが可能である。

以上説明したように、本実施形態においては、ＭＭＥがｅＮｏｄｅＢに対してＭＭＥ再選択を指示し、ｅＮｏｄｅＢはそれを受けてＭＭＥを再選択した上で、アタッチ処理（ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅ）を継続することにより、ＵＥを適切なＭＭＥにＡｔｔａｃｈさせることができる。

＜実施例２＞
実施例２として、ＥＰＣ（ＥｖｏｌｖｅｄＰａｃｋｅｔＣｏｒｅ）において、Ａｔｔａｃｈ時にＵＥとＣｕｓｔｏｍｉｚｅｄＭＭＥを接続させる別の例を説明する。実施例２のシステム構成は、実施例１と同様である。

図４は、実施例２の動作例を示すシーケンス図である。なお、図４は、３ＧＰＰＴＳ２３．４０１のＦｉｇｕｒｅ５．３．２．１−１：Ａｔｔａｃｈｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１５．３．２の記載が参照される。以下、図１及び図４を参照して動作を説明する。

ＵＥ１がＡｔｔａｃｈＲｅｑｕｅｓｔ（１）を送信すると、ｅＮｏｄｅＢ１１が受信し、ＭＭＥにＡｔｔａｃｈＲｅｑｕｅｓｔ（２）を中継する。この時、ｅＮｏｄｅＢ１１は、ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）を一般ＭＭＥ２１に転送するべきか、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＭＭＥ２１に転送される場合がある。

一般ＭＭＥ２１では、ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）を受信した後、ＩｄｅｎｔｉｔｙＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（５ｂ）にて、端末情報（ＭＥＩｄｅｎｔｉｔｙ）を取得し、更に、ＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。すなわち、認証、加入者プロファイルまでは一般ＭＭＥ２１で行う。

端末情報、及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に接続するべきか判断する。一般ＭＭＥ２１に接続する場合、通常のＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続する。

ＵＥ１をＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に接続する場合、一般ＭＭＥ２１は、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に対して、ＭＭＥ変更を指示するために、ＭＭＥ変更要求信号（ＭＭＥＣｈａｎｇｅＲｅｑｕｅｓｔ）（本実施例で新規に導入した、ＧＴＰ（ＧＰＲＳＴｕｎｎｅｌｌｉｎｇＰｒｏｔｏｃｏｌ）信号）を送信する。

この時、一般ＭＭＥ２１は、ＭＭＥＣｈａｎｇｅＲｅｑｕｅｓｔ信号に、端末認証や加入者プロファイルの取得によって生成したコンテキスト（ｃｏｎｔｅｘｔ）情報を設定する。

ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、ＭＭＥ変更要求信号（ＭＭＥＣｈａｎｇｅＲｅｑｕｅｔ）を受信すると、該ＭＭＥ変更要求信号に設定されたｃｏｎｔｅｘｔ情報を保持し、一般ＭＭＥ２１に対して、ＭＭＥＣｈａｎｇｅＲｅｓｐｏｎｓｅ信号（本実施例で新規に導入した、ＧＴＰ信号）を送信する。

その後、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、ＨＳＳ３１に対して、ＵｐｄａｔｅＬｏｃａｔｉｏｎＲｅｑｕｅｓｔ信号（８）を送信し、ＭＭＥが変更されたことをＨＳＳ３１に通知する。

ＨＳＳ３１に対して、ＭＭＥの変更ＭＭＥを通知するため、ＵｐｄａｔｅＬｏｃａｔｉｏｎＲｅｑｕｅｓｔをＣｕｓｔｏｍｉｚｅｄＭＭＥ２２で再実施する。以降のＡｔｔａｃｈＰｒｏｃｅｄｕｒｅはＣｕｓｔｏｍｉｚｅｄＭＭＥ２２で実施する。

また、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、一般ＭＭＥ２１から受け取ったセキュリティ・コンテキスト（ｓｅｃｕｒｉｔｙｃｏｎｔｅｘｔ）情報が有効であれば、再認証を省略することが出来る。

その後、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、アタッチ処理（ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅ）を継続し、ｅＮｏｄｅＢ１１は、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２から、ＩｎｉｔｉａｌＣｏｎｔｅｘｔＳｅｔｕｐＲｅｑｕｅｓｔ／ＡｔｔａｃｈＡｃｃｅｐｔ（１７）を受信する。

ＩｎｉｔｉａｌＣｏｎｔｅｘｔＳｅｔｕｐＲｅｑｕｅｓｔ／ＡｔｔａｃｈＡｃｃｅｐｔ（１７）は、一般ＭＭＥ２１で受けたＡｔｔａｃｈＲｅｑｕｅｓｔ（２）に対する応答である。なお、一般ＭＭＥ２１とは、別のＭＭＥからの応答（Ｒｅｓｐｏｎｃｅ）を受信できる機能がｅＮｏｄｅＢ１１に実装されている必要がある。

その後は、通常のアタッチ処理（ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅ）を継続する。

また、一般ＭＭＥ２１、及びＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、ＵＥ１を、どのＭＭＥに接続させるべきか判断する機能を具備するが、この機能は、実施例１と同様である。

また、図４には、図示されていないが、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に対して、一般ＭＭＥ２１に接続するべきＵＥ１からのＡｔｔａｃｈＲｅｑｕｅｓｔ信号が転送された場合も、同様の手段で一般ＭＭＥ２１にＭＭＥ変更を促すことが可能である。

以上説明したように、本実施例においては、一般ＭＭＥがＣｕｓｔｏｍｉｚｅｄＭＭＥに対してＭＭＥ変更を指示し、ＣｕｓｔｏｍｉｚｅｄＭＭＥはそれを受けてＭＭＥを変更した上で、ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＭＭＥにＡｔｔａｃｈさせることができる。

＜実施例３＞
実施例３として、ＥＰＣにおいてＡｔｔａｃｈ時に、ＵＥとＣｕｓｔｏｍｉｚｅｄＭＭＥを接続させる例を説明する。実施例３のシステム構成は、実施例１と同様である。

図５、図６は、実施例３の動作例を説明するシーケンス図である。なお、図５、６は、３ＧＰＰＴＳ２３．４０１のＦｉｇｕｒｅ５．３．２．１−１：Ａｔｔａｃｈｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１５．３．２の記載が参照される。以下、図１及び図５、図６を参照して動作を説明する。

ＵＥ１がＡｔｔａｃｈＲｅｑｕｅｓｔ（１）を送信すると、まずｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１からＡｔｔａｃｈＲｅｑｕｅｓｔ（２）がＭＭＥに転送される。この時、ｅＮｏｄｅＢ１１は、ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）を、一般ＭＭＥ２１に転送するべきか、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＭＭＥ２１に転送される場合がある。

一般ＭＭＥ２１では、ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）を受信した後、ＩｄｅｎｔｉｔｙＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（５ｂ）にて端末情報（ＭＥＩｄｅｎｔｉｔｙ）を取得する。更に、一般ＭＭＥ２１は、ＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。

端末情報及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に接続するべきか判断する。一般ＭＭＥ２１に接続する場合、通常のＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続する。

ＵＥ１を、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に接続する場合、一般ＭＭＥ２１は、ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続せずに、ＵＥ１に対してアタッチリジェクト（ＡｔｔａｃｈＲｅｊｅｃｔ）メッセージを送信する。すなわち、一般ＭＭＥ２１はＩｎｉｔｉａｌＣｏｎｔｅｘｔＳｅｔｕｐＲｅｑｕｅｓｔ／ＡｔｔａｃｈＲｅｊｅｃｔ（１７）をｅＮｏｄｅＢ１１に送信する。

この時、一般ＭＭＥ２１は、ＡｔｔａｃｈＲｅｊｅｃｔ信号に、再アタッチ（ｒｅ−ａｔｔａｃｈ）を指示するパラメータ（本実施例で導入した、新規パラメータ）、及び、ｒｅ−ａｔｔａｃｈ時に、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２を、ｅＮｏｄｅＢ１１が選択できるように、ＧＵＭＭＥＩ（ＧｌｏｂａｌｌｙＵｎｉｑｕｅＭＭＥｉｄｅｎｔｉｆｉｅｒ）を含むＧＵＴＩ（ＧｌｏｂａｌｌｙＵｎｉｑｕｅＴｅｍｐｏｒａｒｙＩｄｅｎｔｉｆｙ）パラメータ（本実施例で導入した、新規パラメータ）を設定する。ＧＵＴＩパラメータは、ＧＵＭＭＥＩとＭ−ＴＭＳＩ（ＴｅｍｐｏｒａｙＭｏｂｉｌｅＳｔａｔｉｏｎＩｄｅｎｔｉｔｙ）から構成される。ＭＭＥＩは、ＭＣＣ（ＭｏｂｉｌｅＣｏｕｎｔｒｙＣｏｄｅ）とＭＮＣ（ＭｏｂｉｌｅＮｅｔｗｏｒｋＣｏｄｅ）とＭＭＥＩｄｅｎｔｉｆｉｅｒから構成される。これらは本実施例で導入した新規なパラメータであるが、ｅＮｏｄｅＢ１１は、透過（ｔｒａｎｓｐａｒｅｎｔ）であるため、ｅＮｏｄｅＢ１１には影響はない。

ＵＥ１は、ｅＮｏｄｅＢ１１からＡｔｔａｃｈＲｅｊｅｃｔ信号を受信すると、図６に示すように、Ａｔｔａｃｈ−Ｒｅｊｅｃｔ信号に設定されたｒｅ−ａｔｔａｃｈを指示するパラメータ、及び、ＧＵＴＩパラメータに従って、ＧＵＴＩを設定したＡｔｔａｃｈＲｅｑｕｅｓｔ（１）（ＧＵＴＩによるＡｔｔａｃｈ）を、ｅＮｏｄｅＢ１１に送信する。この時、ｅＮｏｄｅＢ１１は、ＧＵＴＩに含まれるＧＵＭＭＥＩから適切なＭＭＥを判断し、ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）を、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に転送する。

なお、ＵＥ１には、ＡｔｔａｃｈＲｅｊｅｃｔ信号にてＧＵＴＩを受け付け、ｒｅ−ａｔｔａｃｈ（図６のＡｔｔａｃｈＲｅｑｕｅｓｔ（１））送信時に、Ａｔｔａｃｈｒｅｊｅｃｔで指示されたＧＵＴＩを使用する機能が実装されている。ＭＭＥは、このＵＥがＲｅ−Ｓｅｌｅｃｔｉｏｎ対象か判断する機能が実装されている。

その後、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は通常のＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続する。ただし、ＧＵＴＩが設定されたＡｔｔａｃｈＲｅｑｕｅｓｔだが、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２自身は、ｃｏｎｔｅｘｔ情報を保持していない。

このため、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、ＡｔｔａｃｈＲｅｑｕｅｓｔ信号を受信した後、ＩｄｅｎｔｉｔｙＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（４）にて、端末情報を取得し、更にＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。

また、一般ＭＭＥ２１及びＣｕｓｔｏｍｉｚｅｄＭＭＥ２２はＵＥ１をどのＭＭＥに接続させるべきか判断する機能を具備するが、この機能は、前記実施例１と同様である。

また、図５及び図６では、図示されていないが、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に対して、一般ＭＭＥ２１に接続するべきＵＥ１からのＡｔｔａｃｈＲｅｑｕｅｓｔ信号が転送された場合も、同様にして、ＵＥ１にＭＭＥ再選択を促すことが可能である。

以上説明したように、本実施例においては、一般ＭＭＥがＵＥに対してＭＭＥ再選択を指示し、ＵＥはそれを受けてＣｕｓｔｏｍｉｚｅｄＭＭＥを指定した上で、ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＭＭＥにＡｔｔａｃｈさせることができる。

＜実施例４＞
実施例４として、ＥＰＣにおいてＡｔｔａｃｈ時にＵＥとＣｕｓｔｏｍｉｚｅｄＭＭＥを接続させる例を説明する。実施例４の構成は実施例１と同様である。図７は、実施例４の動作例を説明するためのシーケンス図である。なお、図７は、３ＧＰＰＴＳ２３．４０１のＦｉｇｕｒｅ５．３．２．１−１：Ａｔｔａｃｈｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１５．３．２の記載が参照される。以下、図１及び図７を参照して動作を説明する。

ＵＥ１がＡｔｔａｃｈＲｅｑｕｅｓｔ（１）をＭＭＥに送信する為に、まずｅＮｏｄｅＢ１１とのＲＲＣＣｏｎｎｅｃｔｉｏｎの確立を行う。ＲＲＣＣｏｎｎｅｃｔｉｏｎ確立のために、ＵＥ１は、まずｅＮｏｄｅＢ１１にＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ信号を送信する。

この時、ＵＥ１は、本信号にＣｕｓｔｏｍｉｚｅｄＭＭＥ２２への接続を必要とすることを示すパラメータ（ＵｓｅｒＩｄｅｎｔｉｔｙ、ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で新規に導入した値又はパラメータ）、又は、これらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ（ＰｕｂｌｉｃＬａｎｄＭｏｂｉｌｅＮｅｔｗｏｒｋＩｄｅｎｔｉｔｙ）等））を設定する。

ＵＥ１は、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔにてｅＮｏｄｅＢに、ＣｕｓｔｏｍｉｚｅｄＭＭＥに接続可能であることを通知するＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔの新規パラメータ（ｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔを発信した原因を示す情報要素（通信確立要因）)の新規Ｖａｌｕｅ若しくは新規パラメータ）が実装される。

ｅＮｏｄｅＢ１１は、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ信号を受信したとき、ＵＥ１がＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に接続すべきことを記憶し、その後のＲＲＣＣｏｎｎｅｃｔｉｏｎＰｒｏｃｅｄｕｒｅを継続する。

ＲＲＣＣｏｎｎｅｃｔｉｏｎ確立後、ＵＥ１がＡｔｔａｃｈＲｅｑｕｅｓｔ（１）を送信すると、ｅＮｏｄｅＢ１１が受信する。この時、ｅＮｏｄｅＢ１１は、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ（１）の受信した時に記憶した情報（ＵＥ１がＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に接続すべきこと）から、ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）を、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に転送する。

ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）には、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔにて受信したＣｕｓｔｏｍｉｚｅｄＭＭＥに接続可能であることを通知するＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔの新規パラメータ（ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）がｅＮｏｄｅＢ１１によって設定されＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に通知される。

ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２では、ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）を受信した後、通常のＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続する。ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）で受信した、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔにて受信したＣｕｓｔｏｍｉｚｅｄＭＭＥに接続可能であることを通知するＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔの新規パラメータ（ｅｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）を保持する。

また、ＵＥ１は、一般ＭＭＥ２１及びＣｕｓｔｏｍｉｚｅｄＭＭＥ２２のどちらのＭＭＥに接続するべきかを、ｅＮｏｄｅＢ１１に指示する機能を具備する。この時、ＵＥ１はコアネットワーク上の全てＭＭＥの情報を保持することは出来ないので、ｅＮｏｄｅＢ１１への指示は、ＭＭＥを一意に選択できる識別子ではなく、ＭＭＥ種別、若しくはサービス種別等の情報が用いられる。

また、ｅＮｏｄｅＢ１１は、ＵＥ１をどのＭＭＥに接続させるべきか判断する機能を具備している。

ｅＮｏｄｅＢ１１において、ＭＭＥの選択は、前述のとおり、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ内のユーザＩＤ（ＵｓｅｒＩｄｅｎｔｉｔｙ）、通信確立要因（ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅ）の新規Ｖａｌｕｅ、又は新規パラメータ、又はこれらのパラメータを構成する一部分の識別子のいずれか、若しくは複数を組み合わせて行う。新規パラメータにはＭＴＣグループを識別するＩＤ、ＡＰＮなども含む。

以上説明したように、本実施例においては、ＵＥがｅＮｏｄｅＢに対してＭＭＥ選択を指示し、ｅＮｏｄｅＢはそれを受けてＣｕｓｔｏｍｉｚｅｄＭＭＥを指定した上で、ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＭＭＥにＡｔｔａｃｈさせることができる。

＜実施例５＞
実施例５として、ＥＰＣにおいて、トラッキングエリア更新（ＴＡＵｐｄａｔｅ）時に、ＵＥとＣｕｓｔｏｍｉｚｅｄＭＭＥを接続させる例を説明する。実施例５の構成は、実施例１と同様である。

図８、図９は、実施例５の動作例を説明するためのシーケンス図である。なお、図８は、３ＧＰＰＴＳ２３．４０１のＦｉｇｕｒｅ５．３．５−１：Ｓ１ＲｅｌｅａｓｅＰｒｏｃｅｄｕｒｅに基づく。ＴＳ２３．４０１５．３．５が参照される。図９は、Ｆｉｇｕｒｅ５．３．３．１−１：ＴｒａｃｋｉｎｇＡｒｅａＵｐｄａｔｅｐｒｏｃｅｄｕｒｅｗｉｔｈＳｅｒｖｉｎｇＧＷｃｈａｎｇｅに基づく。３ＧＰＰＴＳ２３．４０１５．３．３が参照される。図１、図８、図９（及び図３の一部）を参照して、動作を説明する。

ＵＥ１がＡｔｔａｃｈＲｅｑｕｅｓｔを送信すると（図３の１）、まずｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１からＡｔｔａｃｈＲｅｑｕｅｓｔがＭＭＥに中継される（図３の２参照）。

この時、ｅＮｏｄｅＢ１１は、ＡｔｔａｃｈＲｅｑｕｅｓｔを一般ＭＭＥ２１に転送するべきか、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に転送するべきか、一意に決定することが出来ない。そのため、ＡｔｔａｃｈＲｅｑｕｅｓｔが一般ＭＭＥ２１に転送される場合がある。

一般ＭＭＥ２１ではＡｔｔａｃｈＲｅｑｕｅｓｔを受信した後、ＩｄｅｎｔｉｔｙＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（図３の４参照）にて端末情報を取得し、更に、ＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。

端末情報及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に接続するべきか判断する。その後、通常のＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続する。一般ＭＭＥ２１に接続する場合は、ここで処理が完了する。

ＵＥ１を、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に接続する場合、一般ＭＭＥ２１はＵＥ１に対して、トラッキングエリア更新（ＴＡＵｐｄａｔｅ）を行わせるために、図８に示すように、Ｓ１Ｒｅｌｅａｓｅを行う。この時、一般ＭＭＥ２１はｅＮｏｄｅＢ１１に、Ｓ１ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅＣｏｍｍａｎｄ（４）を送信する。

一般ＭＭＥ２１は、Ｓ１ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅＣｏｍｍａｎｄ（４）で、次にｅＮｏｄｅＢがＭＭＥとＳ１Ｃｏｎｎｅｃｔｉｏｎを確立するときに選択するべきＭＭＥを、ＭＭＥ識別子（例えばＧＵＭＭＥＩ）で指示する。ＬｏａｄＢａｌａｎｃｉｎｇＴＡＵ起動のためのＳ１Ｒｅｌｅａｓｅ時に、ｅＮｏｄｅＢに対して、次のＭＭＥを指定するＧＵＭＭＥＩを指示するためのパラメータは新規パラメータである。この時、ｅＮｏｄｅＢ１１は、Ｓ１Ｒｅｌｅａｓｅ完了後もＵＥ１に対するセッション情報を保持している間、次回ＭＭＥ選択の為の情報として、ＭＭＥ識別子を保持し続ける。

Ｓ１Ｒｅｌｅａｓｅが行われると、次にＵＥ１は、図９に示すように、ＴＡＵＲｅｑｕｅｓｔ（２）を送信する。ＴＡＵＲｅｑｕｅｓｔ（２）を、まずｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１からＴＡＵＲｅｑｕｅｓｔ（３）がＭＭＥに転送される。この時、ｅＮｏｄｅＢ１１は、Ｓ１Ｒｅｌｅａｓｅ済みの状態であることから、ＭＭＥ選択を行い、Ｓ１Ｃｏｎｎｅｃｔｉｏｎを確立する。ｅＮｏｄｅＢは、Ｓ１Ｒｅｌｅａｓｅ時にｏｌｄＭＭＥ（＝一般ＭＭＥ）から指示されたＧＵＭＭＥＩに従ってＣｕｓｔｏｍｉｚｅｄＭＭＥを選択する（※ｅＮｏｄｅＢはＵＥ毎に次のＧＵＭＭＥＩを保持する機能を有する）。

ＭＭＥの選択において、ｅＮｏｄｅＢ１１は、一般ＭＭＥ２１から受信したＳ１ＵＥＣｏｎｔｅｘｔＲｅｌｅａｓｅＣｏｍｍａｎｄ信号で指示されたＧＵＭＭＥＩのＭＭＥ識別子（ＭＭＥＩｄｅｎｔｉｆｉｅｒ）に従い、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２を選択する。ＮＡＳ上のＧＵＴＩ（ＧＵＭＭＥＩ）は、ｏｌｄＭＭＥ（＝一般ＭＭＥ）を示しているのでｃｏｎｔｅｘｔ取得が可能である。

ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、ＴＡＵＲｅｑｕｅｓｔ（３）を受信した後、通常のＴＡＵｐｄａｔｅＰｒｏｃｅｄｕｒｅを継続する。ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、一般ＭＭＥ２１にＣｏｎｔｅｘｔＲｅｑｕｅｓｔ（４）を送信し、その応答ＣｏｎｔｅｘｔＲｅｓｐｏｎｃｅ（５）を受け取る。

ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、Ｓ−ＧＷがリロケート（ｒｅｌｏｃａｔｅ）した場合、一般ＭＭＥにＳ−ＧＷの変更指示を含むＣｏｎｔｅｘｔＡｃｋｎｏｗｌｅｄｇｅ（７）を送信し、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２が新たなＳ−ＧＷ４１（ｎｅｗＳｅｒｖｉｎｇＧＷ）を選択すると、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、新たなＳ−ＧＷ４１に、ＣｒｅａｔｅＳｅｓｓｈｏｎＲｅｑｕｅｓｔ（８）を送信する。

これを受けて新たなＳ−ＧＷ４１（ｎｅｗＳｅｒｖｉｎｇＧＷ）は、ＭｏｄｉｆｙＢｅａｒｅｒＲｅｑｕｅｓｔ（９）をＰ−ＧＷ５１に送信し、その応答をＰ−ＧＷ５１から受けると、新たなＳ−ＧＷはＣｒｅａｔｅＳｅｓｓｉｏｎＲｅｓｐｏｎｃｅ（１１）をＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に返す。

ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２はＵｐｄａｔｅＬｏｃａｔｉｏｎ（１２）をＨＳＳ３１に送信する。

ＨＳＳ３１からＣａｎｃｅｌＬｏｃａｔｉｏｎ（１３）を受け取った一般ＭＭＥ２１は、ＭＭコンテキストを削除し、肯定応答（ＣａｎｃｅｌＬｏｃａｔｉｏｎＡｃｋ）（１４）をＨＳＳ３１に送信する。ＨＳＳ３１からのＣｕｓｔｏｍｉｚｅｄＭＭＥ２２にＵｐｄａｔａＬｏｃａｔｉｏｎ（１２）に対する肯定応答（ＵｐｄａｔａＬｏｃａｔｉｏｎＡｃｋ）（１７）が送信される。

一般ＭＭＥ２１は、旧Ｓ−ＧＷ４１（ｏｌｄＳｅｒｖｉｎｇＧＷ）にＤｅｌｅｔｅＳｅｓｓｉｏｎＲｅｑｕｅｓｔ（１８）を送信し、その応答（１９）が、旧Ｓ−ＧＷ４１（ｏｌｄＳｅｒｖｉｎｇＧＷ）から一般ＭＭＥ２１に送信される。

ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２からＵＥ１にＴＡＵＡｃｃｅｓｐｔ（２０）が送信される。

ＴＡＵＡｃｃｅｐｔ（２０）にＧＵＴＩが含まれる場合、ＵＥ１は、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に対して、ＴＡＵＣｏｍｐｌｅｔｅ（２１）を返すことで、受信した信号ＴＡＵＡｃｃｅｓｐｔ（２０）の肯定応答とする。

一般ＭＭＥ２１及びＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、ＵＥ１をどのＭＭＥに接続させるべきか判断する機能を具備するが、この機能は実施例１と同様である。

また、図８及び図９では、図示していないが、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に対して一般ＭＭＥ２１に接続するべきＵＥ１からのＡｔｔａｃｈＲｅｑｕｅｓｔ信号が転送された場合も、同様の手段でＵＥ１にＭＭＥ再選択を促すことが可能である。

また、本実施例では、図９の手順にて、ＴＡＵｐｄａｔｅＰｒｏｃｅｄｕｒｅを用いたが、本実施例での特徴は、ｅＮｏｄｅＢ１１でＭＭＥの選択を行うことである。このため、例えば、ＳｅｒｖｉｃｅＲｅｑｕｅｓｔ等、Ｓ１Ｃｏｎｎｅｃｔｉｏｎを再確立するための、その他の手続き（Ｐｒｏｃｅｄｕｒｅ）を用いても実現可能である。

以上説明したように、本実施例においては、一般ＭＭＥがｅＮｏｄｅＢに対してＭＭＥ再選択を指示し、ｅＮｏｄｅＢはそれを受けて次回ＭＭＥ選択時にＣｕｓｔｏｍｉｚｅｄＭＭＥを指定した上で、手続き（Ｐｒｏｃｅｄｕｒｅ）を継続することにより、ＵＥを適切なＭＭＥに接続させることができる。

＜実施形態２＞
実施形態２として、ＵＭＴＳ（ＵｎｉｖｅｒｓａｌＭｏｂｉｌｅＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓＳｙｓｔｅｍ）においてＡｔｔａｃｈ時にＵＥと特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）を接続させる例を説明する。図２は、実施形態２のシステム構成を例示する図である。

ＵＥ１０１は、例えば携帯電話端末（移動機）である。あるいは、例えば上記したＭＴＣデバイス、ＭＢＭＳ対応端末等であってもよい。

ＮｏｄｅＢ１１１及びＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）１７１は、ＵＭＴＳシステムで採用された無線アクセス（Ｒａｄｉｏａｃｃｅｓｓ）用の装置を表している。

一般ＳＧＳＮ１２１、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２は、ＵＭＴＳ用に用いる在圏装置であり、接続形態により、ユーザープレーンを扱う場合と扱わない場合がある。ＳＧＳＮがユーザープレーンを扱わない場合のユーザープレーンは、Ｓ−ＧＷとＲＮＣ間に設定される。

ＨＬＲ（ＨｏｍｅＬｏｃａｔｉｏｎＲｅｇｉｓｔｅｒ）１３１は、加入者情報を保持するデータベースである。

ＧＧＳＮ（ＧａｔｅｗａｙＧＰＲＳ（ＧｅｎｅｒａｌＰａｃｋｅｔＲａｄｉｏＳｅｒｖｉｃｅ）ＳｕｐｐｏｒｔＮｏｄｅ：特許請求の範囲では「ゲートウェイＧＰＲＳサポートノード」と表記）１４１は、外部網と接続するゲートウェイ装置である。サービスネットワーク１６１は、外部網（データパケットネットワーク）を示す。

図２において、ＮｏｄｅＢ１１１とＲＮＣ１７１は無線アクセスネットワークＲＡＮ、ＳＧＳＮ、ＧＧＳＮ等はコアネットワークに対応する。

以下、実施形態２について、制御方式の相違したいくつかの実施例を説明する。以下の実施例６−１０は上記態様６−１０にそれぞれ対応する。

＜実施例６＞
図１０は、実施例６の動作例を説明するためのシーケンス図であり、３ＧＰＰＴＳ２３．０６０６．５Ｆｉｇ２２に基づく。

図１０において、
ＭＳ（ＭｏｂｉｌｅＳｔａｔｉｏｎ）は、図２のＵＥ１０１、
ＲＡＮ（ＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）は、図２のＮｏｄｅＢ１１１とＲＮＣ１７１、
一般ＳＧＳＮは、図２の一般ＳＧＳＮ１２１、
ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ（特定ＳＧＳＮ）は、図２のＣｕｓｔｏｍｉｚｅｄＳＧＳＮ（特定ＳＧＳＮ）１２２、
ＧＧＳＮは、図２のＧＧＳＮ１４１、
ＨＬＲは、図２のＨＬＲ１３１に対応している。

ＭＳＣ（ＭｏｂｉｌｅＳｗｉｔｃｈｉｎｇＣｅｎｔｅｒ）／ＶＬＲ（ＶｉｓｉｔｏｒＬｏｃａｔｉｏｎＲｅｇｉｓｔｅｒ）のＶＬＲはＨＬＲ以外のＣＳサービス用のローケーションレジスタである。ＥＩＲ（ＥｑｕｉｐｍｅｎｔＩｄｅｎｔｉｆｉｅｒＲｅｇｉｓｔｅｒ）は有効な移動装置の識別子を保持する。

図２、図１０を参照して動作を説明する。なお、以下では、図１０のＭＳを、図２のＵＥ１０１に読み替えて説明する。

ＵＥ１０１（ＭＳ）がＡｔｔａｃｈＲｅｑｕｅｓｔ（１）を送信すると、まずＮｏｄｅＢ１１１が受信し、ＡｔｔａｃｈＲｅｑｕｅｓｔ（１）をＲＮＣ１７１に転送する。ＲＮＣ１７１は、ＡｔｔａｃｈＲｅｑｕｅｓｔ（１）をＳＧＳＮに転送する。この時、ＲＮＣ１７１は、ＡｔｔａｃｈＲｅｑｕｅｓｔを一般ＳＧＳＮ１２１に転送するべきか、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。

一般ＳＧＳＮ１２１では、ＡｔｔａｃｈＲｅｑｕｅｓｔを受信した後、ＩｄｅｎｔｉｔｙＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（３）にて端末情報を取得し、更にＨＬＲ１３１と連携して、認証及び加入者プロファイルの取得を行う。認証、加入者プロファイル取得まで、一般ＳＧＳＮ１２１で実施する。

端末情報及び加入者プロファイルを取得した一般ＳＧＳＮ１２１は、ＵＥ１０１を一般ＳＧＳＮ１２１に接続するべきか、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に接続するべきか判断する。一般ＳＧＳＮ１２１に接続する場合、通常のＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続する。

ＵＥ１０１を、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に接続する場合、一般ＳＧＳＮ１２１は、ＲＮＣ１７１に対して、ＳＧＳＮ再選択を指示するために、ＳＧＳＮｒｅ−ｓｅｌｅｃｔｉｏｎＣｏｍｍａｎｄ（本実施例で新規に導入した、ＲＡＮＡＰ信号）を送信する。この時、一般ＳＧＳＮ１２１はＳＧＳＮｒｅ−ｓｅｌｅｃｔｉｏｎＣｏｍｍａｎｄ信号にＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２を特定する識別子（例えばＲＡＩ（ＲｏｕｔｉｎｇＡｒｅａＩｄｅｎｔｉｆｉｅｒ）、ＮＲＩ（ＮｅｔｗｒｏｋＲｅｓｏｕｒｃｅＩｄｅｎｔｉｆｉｅｒ）など）を設定する。すなわち、一般ＳＧＳＮ１２１は、ＲＮＣに１７１対して、ＳＧＳＮ再選択要求し、その際、特定ＳＧＳＮ１２２の選択に必要な情報（ＲＡＩ）を載せる。なお、同一プール内での再選択の場合は、ＮＲＩでよい。ＳＧＳＮは、ＵＥ１０１が、ｒｅ−ｓｅｌｅｃｔｉｏｎ対象か判断する機能を有する。

ＲＮＣ１７１は、ＳＧＳＮｒｅ−ｓｅｌｅｃｔｉｏｎＣｏｍｍａｎｄ信号を受信すると、本信号に設定された識別子に従ってＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２を選択し、ＡｔｔａｃｈＲｅｑｕｅｓｔ（１）を転送する。特定ＳＧＳＮ１２２でＡｔｔａｃｈＲｅｑｕｅｓｔのＮＡＳ（ＮｏｎＡｃｃｅｓｓＳｔｒａｔｕｍ）パラメータが必要なので、ＲＮＣ１７１でＡｔｔａｃｈＲｅｑｕｅｓｔを再送する。ＲＮＣ１７１ではＮＡＳメッセージを保持する機能が実装されている。

新たなＳＧＳＮ（＝ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）では旧ＳＧＳＮ（＝一般ＳＧＳＮ）を特定できないため、コンテキスト（ｃｏｎｔｅｘｔ）を引き継ぐことができない。そのため、新たなＳＧＳＮでも認証／加入者プロファイル取得を行う必要がある。ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２は、ＡｔｔａｃｈＲｅｑｕｅｓｔ（２）を受信した後、ＩｄｅｎｔｉｔｙＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅにて端末情報を取得し、更にＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。つまり、一般ＳＧＳＮ１２１と同様の処理を行う。

端末情報及び加入者プロファイルを取得したＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２は、ＵＥ１０１を、一般ＳＧＳＮ１２１に接続するべきか、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に接続するべきか判断する。ここでは、ＲＮＣ１７１で再選択された後の為、ＳＧＳＮｒｅ−ｓｅｌｅｃｔｉｏｎＣｏｍｍａｎｄ信号を送信せずに、通常のＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続する。

また、一般ＳＧＳＮ１２１及びＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２はＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この判断はＵＥ１０１からの情報（例えば、
・ＩＭＳＩ（ＩｎｔｅｒｎａｔｉｏｎａｌＭｏｂｉｌｅＳｕｂｓｃｒｉｂｅｒＩｄｅｎｔｉｔｙ）、
・ＩＭＥＩ、
・ＵＥｎｅｔｗｏｒｋｃａｐａｂｉｌｉｔｙ、
・ＭＳｎｅｔｗｏｒｋｃａｐａｂｉｌｉｔｙ、
・Ｍｏｂｉｌｅｓｔａｔｉｏｎｃｌａｓｓｍａｒｋ２、
・Ｍｏｂｉｌｅｓｔａｔｉｏｎｃｌａｓｓｍａｒｋ３、
・Ｄｅｖｉｃｅｐｒｏｐｅｒｔｉｅｓ、
・ＡＰＮ（ＡｃｃｅｓｓＰｏｉｎｔＮａｍｅ）、又は、
・ＭＴＣグループを識別するＩＤ、又は、
・ｌｏｗａｃｃｅｓｓｐｒｉｏｒｉｔｙｉｎｄｉｃａｔｉｏｎ、又は、
・ｄｅｌａｙｔｏｌｅｒａｎｔａｃｃｅｓｓ、又は、
・今後追加されるＡｔｔａｃｈＲｅｑｕｅｓｔ、又は、ＴＡＵｐｄａｔｅＲｅｑｕｅｓｔなどのその他のＮＡＳ信号の新規パラメータ、又は、これらのパラメータを構成する一部分の識別子※ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等）、
ＨＬＲ１３１からの情報（例えば
・Ｆｅａｔｕｒｅ−Ｌｉｓｔ、
・ＡＰＮ、
・ＭＴＣグループを識別するＩＤ、又は、
・又は今後追加されるＵｐｄａｔｅＬｏｃａｔｉｏｎＡｎｓｗｅｒ／ＩｎｓｅｒｔＳｕｂｓｃｒｉｂｅｒＤａｔａＲｅｑｕｅｓｔ信号の新規パラメータ、又は、
・これらのパラメータを構成する一部分の識別子）
のいずれか、若しくは複数を組み合わせて行う。

また、図１０では明示していないが、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に対して一般ＳＧＳＮ１２１に接続するべきＵＥ１０１からのＡｔｔａｃｈＲｅｑｕｅｓｔ信号が転送された場合も、同様の手段でＲＮＣ１７１にＭＭＥ再選択を促すことが可能である。

以上説明したように、本実施例においては、ＳＧＳＮがＲＮＣに対してＳＧＳＮ再選択を指示し、ＲＮＣはそれを受けてＳＧＳＮを再選択した上で、ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＳＧＳＮにＡｔｔａｃｈさせることができる。

＜実施例７＞
実施例７として、ＵＭＴＳにおいてＡｔｔａｃｈ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例７の構成は実施例６と同様である。図１１は、実施例７の動作例を説明するためのシーケンス図である。図２、図１１を参照して動作を説明する。

ＵＥ１０１が、ＡｔｔａｃｈＲｅｑｕｅｓｔ（１）を送信すると、まず、ＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。ＲＮＣ１７１はこれをＳＧＳＮに転送する。この時、ＲＮＣ１７１は、ＡｔｔａｃｈＲｅｑｕｅｓｔを一般ＳＧＳＮ１２１に転送するべきか、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。

一般ＳＧＳＮ１２１では、ＡｔｔａｃｈＲｅｑｕｅｓｔを受信した後、ＩｄｅｎｔｉｔｙＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅにて端末情報を取得し、更に、ＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。認証、加入者プロファイル取得まで、一般ＳＧＳＮ１２１で実施する。

ＵＥ１０１をＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に接続する場合、一般ＳＧＳＮ１２１は、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に対してＳＧＳＮ変更を指示するために、ＳＧＳＮＣｈａｎｇｅＲｅｑｕｅｓｔ（本実施形態で新規に導入した、ＧＴＰ信号）を送信する。

この時、一般ＳＧＳＮ１２１は、ＳＧＳＮＣｈａｎｇｅＲｅｑｕｅｓｔ信号に、移動機認証や加入者プロファイルの取得によって生成したｃｏｎｔｅｘｔ情報を設定する。すなわち、一般ＳＧＳＮ１２１からＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に、ＳＧＳＮｃｈａｎｇｅを要求する際に、ｃｏｎｔｅｘｔを新たなＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２）に通知する。ＳＧＳＮはＵＥ１０１がｒｅ−ｓｅｌｅｃｔｉｏｎ対象か判断する機能が実装されている。

ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２は、ＳＧＳＮＣｈａｎｇｅＲｅｑｕｅｓｔ信号を受信すると、ＳＧＳＮＣｈａｎｇｅＲｅｑｕｅｓｔ信号に設定されたコンテキスト（ｃｏｎｔｅｘｔ）情報を保持し、一般ＳＧＳＮ１２１に対して、ＳＧＳＮＣｈａｎｇｅＲｅｓｐｏｎｓｅ信号（本実施形態で新規に導入した、ＧＴＰ信号）を送信する。

その後、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２は、ＨＬＲ１３１に対して、ＵｐｄａｔｅＬｏｃａｔｉｏｎ信号（８）を送信し、ＳＧＳＮが変更されたことをＨＬＲ１３１に通知する。

また、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２は、一般ＳＧＳＮ１２１から受け取ったセキュリティ・コンテキスト（ｓｅｃｕｒｉｔｙｃｏｎｔｅｘｔ）情報が有効であれば、再認証を省略することが出来る。

その後、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２は、ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続し、ＲＮＣ１７１は、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２からＡｔｔａｃｈＡｃｃｅｐｔ信号（９）を受信する。その後は、通常のＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続する。

また、一般ＳＧＳＮ１２１及びＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２は、ＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この機能は実施例６と同様である。

また、図１１では、図示されていないが、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に対して一般ＳＧＳＮ１２１に接続するべきＵＥ１０１からのＡｔｔａｃｈＲｅｑｕｅｓｔ信号が転送された場合も、同様の手段で一般ＳＧＳＮ１２１にＳＧＳＮ変更を促すことが可能である。

以上説明したように、本実施例においては、一般ＳＧＳＮが特定ＳＧＳＮに対してＳＧＳＮ変更を指示し、特定ＳＧＳＮはそれを受けてＳＧＳＮを変更した上で、アタッチ処理（ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅ）を継続することにより、ＵＥを適切なＳＧＳＮに、Ａｔｔａｃｈさせることができる。

＜実施例８＞
実施例８として、ＵＭＴＳにおいてＡｔｔａｃｈ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例８の構成は実施例６と同様である。図１２、図１３は、実施例８の動作例を説明するためのシーケンス図である。図２、図１２、図１３を参照して動作を説明する。

ＵＥ１０１（ＭＳ）が、ＡｔｔａｃｈＲｅｑｕｅｓｔ（１）を送信すると、まずＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。ＲＮＣ１７１は、これをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＡｔｔａｃｈＲｅｑｕｅｓｔを一般ＳＧＳＮ１２１に転送するべきか、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。

一般ＳＧＳＮ１２１では、ＡｔｔａｃｈＲｅｑｕｅｓｔ（１）を受信した後、ＩｄｅｎｔｉｔｙＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（３）にて端末情報を取得し、更に、ＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。

ＵＥ１０１をＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に接続する場合、一般ＳＧＳＮ１２１は、ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続せずに、ＵＥ１０１に対してＡｔｔａｃｈＲｅｊｅｃｔ信号（９）を送信する。

この時、一般ＳＧＳＮ１２１はＡｔｔａｃｈＲｅｊｅｃｔ信号に、再アタッチ（ｒｅ−ａｔｔａｃｈ）を指示するパラメータと、ｒｅ−ａｔｔａｃｈ時に、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２を、ＲＮＣ１７１が選択できるようＲＡＩ（ＲｏｕｔｉｎｇＡｒｅａＩｄｅｎｔｉｔｙ）パラメータ（本実施形態で新規に導入した、パラメータ）を設定する。これらは本実施例で導入した新規なパラメータであるが、ＲＮＣ１７１では、透過であるため影響はない。

ＵＥ１０１は、ＡｔｔａｃｈＲｅｊｅｃｔでＲＡＩを受け付け、Ｒｅ−ａｔｔａｃｈ時に、ｒｅｊｅｃｔで指示されたＲＡＩを使用する機能が必要である。ＳＧＳＮはＵＥ１０１がｒｅ−ｓｅｌｅｃｔｉｏｎ対象か判断する機能を有する。

ＵＥ１０１は、ＡｔｔａｃｈＲｅｊｅｃｔ信号（９）を受信すると、該ＡｔｔａｃｈＲｅｊｅｃｔ信号（９）に設定されたｒｅ−ａｔｔａｃｈを指示するパラメータ及びＲＡＩパラメータに従って、図１３に示すように、ＲＡＩを設定したＡｔｔａｃｈＲｅｑｕｅｓｔ信号（１）を、ＲＮＣ１７１に送信する（Ｐ−ＴＭＳＩ（ＰａｃｋｅｔＴｅｍｐｏｒａｒｙＭｏｂｉｌｅＳｕｂｓｃｒｉｂｅｒＩｎｄｅｎｔｉｆｉｅｒ）によるＲｅ−Ａｔｔａｃｈ）。この時、ＲＮＣ１７１は、ＲＡＩから適切なＳＧＳＮを判断し、ＡｔｔａｃｈＲｅｑｕｅｓｔを、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に転送する。

その後、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２は、通常のＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続する。

ただし、ＲＡＩが設定されたＡｔｔａｃｈＲｅｑｕｅｓｔであるが、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２自身は、ｃｏｎｔｅｘｔ情報を保持していない。このため、ＡｔｔａｃｈＲｅｑｕｅｓｔ信号（１）を受信した後、ＩｄｅｎｔｉｔｙＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（３）にて、端末情報を取得し、更にＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。

また、一般ＳＧＳＮ１２１及びＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２はＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この機能は実施例６と同様である。

また、図１２及び図１３では、図示されていないが、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に対して一般ＭＭＥ１２１に接続するべきＵＥ１０１からのＡｔｔａｃｈＲｅｑｕｅｓｔ信号が転送された場合も、同様の手段で、ＵＥ１０１に、ＭＭＥの再選択を促すことが可能である。

以上説明したように、本実施例においては、一般ＳＧＳＮがＵＥに対してＳＧＳＮ再選択を指示し、ＵＥはそれを受けて特定ＳＧＳＮを指定した上で、ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＳＧＳＮにＡｔｔａｃｈさせることができる。

＜実施例９＞
実施例９として、ＵＭＴＳにおいてＡｔｔａｃｈ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例９の構成は実施例６と同様である。図１４は、実施例９の動作例を説明するシーケンス図である。図２及び図１４を参照して動作を説明する。

ＵＥ１０１がＡｔｔａｃｈＲｅｑｕｅｓｔをＳＧＳＮに送信する為に、まずＲＮＣ１７１とのＲＲＣＣｏｎｎｅｃｔｉｏｎの確立を行う。ＲＲＣＣｏｎｎｅｃｔｉｏｎ確立の為、ＵＥ１０１は、まずＲＮＣ１７１にＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ信号を送信する。

この時、ＵＥ１０１は、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ信号に、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（ＵｓｅｒＩｄｅｎｔｉｔｙ、ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））を設定する。

ＲＮＣ１７１は、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ信号を受信したとき、ＵＥ１０１がＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に接続するべきことを記憶し、その後のＲＲＣＣｏｎｎｅｃｔｉｏｎＰｒｏｃｅｄｕｒｅを継続する。

ＲＲＣＣｏｎｎｅｃｔｉｏｎ確立後、ＵＥ１０１がＡｔｔａｃｈＲｅｑｕｅｓｔ（１）を送信すると、まず、ＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。

ＲＮＣ１７１は、これをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ信号の受信時に記憶した情報から、ＡｔｔａｃｈＲｅｑｕｅｓｔ信号を、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に転送する。ＡｔｔａｃｈＲｅｑｕｅｓｔには、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔにて受信したＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（ＵｓｅｒＩｄｅｎｔｉｔｙ、ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））がＲＮＣ１７１によって設定されＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に通知される。

ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２では、ＡｔｔａｃｈＲｅｑｕｅｓｔを受信した後、通常のＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続する。ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２は、ＡｔｔａｃｈＲｅｑｕｅｓｔで受信した、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（ＲＮＣ１７１がＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔにて受信し、ＡｔｔａｃｈＲｅｑｕｅｓｔに設定したパラメータであって、ＵｓｅｒＩｄｅｎｔｉｔｙ、ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））を保持する。

また、ＵＥ１０１は、一般ＳＧＳＮ１２１、及びＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２のどちらのＳＧＳＮに接続するべきかをＲＮＣ１７１に指示する機能を具備するが、この時、ＵＥ１０１は、コアネットワーク上の全てＳＧＳＮの情報を保持することは出来ないので、ＲＮＣ１７１への指示は、ＳＧＳＮを一意に選択できる識別子ではなく、ＳＧＳＮ種別若しくはサービス種別等の情報である。

また、ＲＮＣ１７１は、ＵＥ１０１を、どのＳＧＳＮに接続させるべきか判断する機能を具備するが、この判断は、前述のとおり、ＵｓｅｒＩｄｅｎｔｉｔｙ、ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子のいずれか、若しくは複数を組み合わせて行う。新規パラメータにはＭＴＣグループを識別するＩＤ、ＡＰＮなども含む。

以上説明したように、本実施例においては、ＵＥ１０１がＲＮＣ１７１に対してＳＧＳＮの選択を指示し、ＲＮＣ１７１は、この指示を受けて、特定ＳＧＳＮを指定した上で、ＡｔｔａｃｈＰｒｏｃｅｄｕｒｅを継続する。かかる構成により、ＵＥ１０１を適切なＳＧＳＮにＡｔｔａｃｈさせることができる。

＜実施例１０＞
実施例１０として、ＵＭＴＳにおいてＲＡＵｐｄａｔｅ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例１０の構成は、実施例６と同様である。図１５、図１６は、実施例１０の動作例を説明するためのシーケンス図である。以下、図２、図１５、図１６、及び図１０の一部を参照して、動作を説明する。

ＵＥ１０１がＡｔｔａｃｈＲｅｑｕｅｓｔを送信すると（図１０の１参照）、まずＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。ＲＮＣ１７１はこれをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＡｔｔａｃｈＲｅｑｕｅｓｔを一般ＳＧＳＮ１２１に転送するべきか、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。

一般ＳＧＳＮ１２１ではＡｔｔａｃｈＲｅｑｕｅｓｔを受信した後、ＩｄｅｎｔｉｔｙＲｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅにて端末情報を取得し（図１０の３参照）、更にＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。

ＵＥ１０１をＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に接続する場合、一般ＳＧＳＮ１２１はＵＥ１０１に対して、ＲＡ（ＲｏｕｔｉｎｇＡｒｅａ）Ｕｐｄａｔｅを行わせるために、図１５に示すように、ＩｕＲｅｌｅａｓｅを行う。

この時、一般ＳＧＳＮ１２１は、ＲＮＣ１７１にＩＵＲｅｌｅａｓｅＣｏｍｍａｎｄ信号を送信する（図１５の４参照）。一般ＳＧＳＮ１２１は、ＩＵＲｅｌｅａｓｅＣｏｍｍａｎｄ信号にて、次にＲＮＣがＳＧＳＮとＩｕＣｏｎｎｅｃｔｉｏｎを確立するときに選択するべき、ＳＧＳＮをＳＧＳＮ識別子（例えばＲＡＩ、ＮＲＩ等）で指示する。なお、同一プール内の場合、ＮＲＩでもよい。

ＲＮＣ１７１は、ＩｕＲｅｌｅａｓｅ完了後も、ＵＥ１０１に対するセッション情報を保持している間、次回ＳＧＳＮ選択の為の情報として、ＳＧＳＮ識別子を保持し続ける。

ＩｕＲｅｌｅａｓｅが行われると（ＲＮＣ１７１から一般ＳＧＳＮ１２１へのＩＵＲｅｌｅａｓｅＣｏｍｐｌｅｔｅ（６）の送信後）、次に、図１６に示すように、ＵＥ１０１はＲＡＵ（ＲＡＵｐｄａｔｅ）Ｒｅｑｕｅｓｔ（２）を送信する。

ＲＡＵＲｅｑｕｅｓｔ（２）を、まず、ＮｏｄｅＢ１１１が受信し、ＮｏｄｅＢ１１１は、ＲＡＵＲｅｑｕｅｓｔ（３）をＲＮＣ１７１に転送する。

ＲＮＣ１７１はこれをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＩｕＲｅｌｅａｓｅ済みの状態なので、ＳＧＳＮ選択を行い、ＩｕＣｏｎｎｅｃｔｉｏｎを確立する。

ＳＧＳＮ選択において、ＲＮＣ１７１は、一般ＳＧＳＮ１２１から受信したＩＵＲｅｌｅａｓｅＣｏｍｍａｎｄ信号で指示されたＳＧＳＮ識別子に従い、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２を選択する。ＲＮＣはＩｕＲｅｌｅａｓｅ時にｏｌｄＳＧＳＮ（＝一般ＳＧＳＮ）から指示されたＲＡＩ（若しくはＮＲＩ）に従ってＣｕｓｔｏｍｉｚｅｄＳＧＳＮを選択。なお、ＲＮＣはＵＥ毎に次のＲＡＩを保持する機能を有する。

ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２は、ＲＡＵＲｅｑｕｅｓｔを受信した後、通常のＲＡＵｐｄａｔｅＰｒｏｃｅｄｕｒｅを継続する。ＮＡＳ上のＰ−ＴＭＳＩ（ＲＡＩ）は旧ＳＧＳＮである一般ＳＧＳＮを示しているので、Ｃｏｎｔｅｘｔを取得する。

また、図１５及び図１６では図示されていないが、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に対して一般ＳＧＳＮ１２１に接続するべきＵＥ１０１からのＡｔｔａｃｈＲｅｑｕｅｓｔ信号が転送された場合も、同様の手段でＵＥ１０１にＭＭＥ再選択を促すことが可能である。

また、本実施例では、図１６の手順にて、ＲＡＵｐｄａｔｅＰｒｏｃｅｄｕｒｅを用いたが、ＲＮＣ１７１でＳＧＳＮ選択を行うためのものであることから、例えばＰＤＰＣｏｎｔｅｘｔＡｃｔｉｖａｔｉｏｎ等ＩｕＣｏｎｎｅｃｔｉｏｎを再確立する、その他のＰｒｏｃｅｄｕｒｅを用いても実現可能である。

以上説明したように、本実施例においては、一般ＳＧＳＮがＲＮＣに対してＳＧＳＮ再選択を指示し、ＲＮＣはそれを受けて次回ＳＧＳＮ選択時に特定ＳＧＳＮを指定した上で、Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＳＧＳＮに接続させることができる。

＜実施例１１＞
実施例１１として、ＥＰＣにおいて、特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）を跨いだハンドオーバの例を説明する。図１７は、実施例１１の構成（システム構成）を例示する図である。図１７を参照すると、ＵＥ２０１を備え、ＵＥ２０１と無線接続するＲＡＮ（ＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）として、ハンドオーバ元のソースｅＮｏｄｅＢ（ＳｏｕｒｃｅｅＮｏｄｅＢ）２０２とハンドオーバ先のターゲットｅＮｏｄｅＢ（ＴａｒｇｅｔｅＮｏｄｅＢ）２０３を備えている。ＣＮ（ＣｏｒｅＮｅｔｗｏｒｋ）は、ソースＭＭＥ（ＳｏｕｒｃｅＭＭＥ）２０４、ターゲットＭＭＥ（ＴａｒｇｅｔＭＭＥ）２０５、ソースＳＧＷ（ＳｏｕｒｃｅＳＧＷ）２０６、ターゲットＳＧＷ（ＴａｒｇｅｔＳＧＷ）２０７、ＤＮＳサーバ２０９、ＨＳＳ２１１、ＰＧＷ２０８を備え、ＰＧＷ２０８からサービスネットワーク２１０に接続される。この例では、ハンドオーバのソースＭＭＥ２０４とターゲットＭＭＥ２０５は、ともに特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）である。図１８は、実施例１１の動作例（シーケンス動作）を説明するためのシーケンス図である。なお、図１８は、３ＧＰＰＴＳ２３．４０１のＦｉｇｕｒｅ５．５．１．２．２−１：Ｓ１−ｂａｓｅｄｈａｎｄｏｖｅｒに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１５．５．１．２．２の記載が参照される。以下、図１７及び図１８を参照して動作を説明する。

ハンドオーバ元のソースｅＮｏｄｅＢ（ＳｏｕｒｃｅｅＮｏｄｅＢ）２０２が、ＵＥ２０１との接続において信号劣化を検出すると、ＨａｎｄｏｖｅｒＲｅｑｕｉｒｅｄ（２）を、ソースＭＭＥ（ＳｏｕｒｃｅＭＭＥ）２０４に送信する。ＨａｎｄｏｖｅｒＲｅｑｕｉｒｅｄ（２）には、ＴａｒｇｅｔＴＡＩ（ＴｒａｃｋｉｎｇＡｒｅａＩｄｅｎｔｉｔｙ）などの情報が含まれている。ＳｏｕｒｃｅＭＭＥ２０４は、前記情報から、ターゲットＭＭＥ（ＴａｒｇｅｔＭＭＥ）２０５への、ＭＭＥ間ハンドオーバ（ＩｎｔｅｒＭＭＥｈａｎｄｏｖｅｒ）の実行を判断する。

この実施例では、ＳｏｕｒｃｅＭＭＥ２０４がＴａｒｇｅｔＭＭＥ２０５を決定する際に、ＳｏｕｒｃｅＭＭＥ２０４が保持している特定ＭＭＥ接続要求情報を用いてＴａｒｇｅｔＭＭＥ２０５を決定する。なお、ＳｏｕｒｃｅＭＭＥ２０４が保持する特定ＭＭＥ接続要求情報は、ＵＥ２０１から特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）に接続するための特定ＭＭＥ接続要求情報を付与したＲＲＣ信号を受信したｅＮｏｄｅＢ２０２が該特定ＭＭＥ接続要求情報を例えばＳ１−ＡＰ信号にて特定ＭＭＥであるＳｏｕｒｃｅＭＭＥ２０４に通知し、ＳｏｕｒｃｅＭＭＥ２０４で保持しているものである。

ＴａｒｇｅｔＭＭＥ２０５（ハンドオーバ先のＭＭＥ）の決定において、ＳｏｕｒｃｅＭＭＥ２０４で保持している特定ＭＭＥ接続要求情報を元に、ＳｏｕｒｃｅＭＭＥ２０４で保持するローカルコンフィグレーションを用いて決定しても良い。なお、ローカルコンフィグレーションは、例えばオペレータによって設定され、装置（ＭＭＥ）で内部的に管理保持する情報（コンフィグレーション情報）である（例えばＭＴＣ加入者（ＭＴＣ端末）がハンドオーバする際に、ＭＴＣグループとハンドオーバ先の移動エリアに応じた情報等を含む）。例えば特定ＭＭＥ接続要求情報がＡＰＮ（ＡｃｃｅｓｓＰｏｉｎｔＮａｍｅ）とした場合、ＡＰＮを元に、例えばＬＡＰＩ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙＩｎｄｉｃａｔｉｏｎ）の数値に対応するローカルな情報（ローカルコンフィグレーション）で、ハンドオーバ先のＭＭＥの選択を行う。あるいは、ＳｏｕｒｃｅＭＭＥ２０４で保持するローカルコンフィグレーションを用いてＴａｒｇｅｔＭＭＥ２０５を決定するようにしても良い。

また、ＳｏｕｒｃｅＭＭＥ２０４は、ＴａｒｇｅｔＴＡＩ（ＴｒａｃｋｉｎｇＡｒｅａＩｄｅｎｔｉｔｙ）等の位置情報と共に、特定ＭＭＥ接続要求情報を設定し、ＤＮＳサーバ（ＤＮＳｓｅｒｖｅｒ）２０９に、「ＤＮＳＱｕｅｒｙ」を行う事で、ＴａｒｇｅｔＭＭＥ２０５を決定しても良い。

ＳｏｕｒｃｅＭＭＥ２０４がＴａｒｇｅｔＭＭＥ２０５へのＩｎｔｅｒＭＭＥｈａｎｄｏｖｅｒの実行を決定すると、ＳｏｕｒｃｅＭＭＥ２０４はＴａｒｇｅｔＭＭＥ２０５に対して、フォアワードリロケーション要求（ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ）（３）を送信する。その際、ＳｏｕｒｃｅＭＭＥ２０４は、フォアワードリロケーション要求（３）に、ＳｏｕｒｃｅＭＭＥ２０４が保持している特定ＭＭＥ接続要求情報を設定しても良い。

ＴａｒｇｅｔＭＭＥ２０５は、更なるＩｎｔｅｒＭＭＥｈａｎｄｏｖｅｒを実行する際、ＴａｒｇｅｔＭＭＥ２０５で保持する特定ＭＭＥ接続要求情報を利用して特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）の選択が可能になる。

これ以降のシーケンスについては、関連技術にしたがってＩｎｔｅｒＭＭＥｈａｎｄｏｖｅｒ処理が実施される。

＜実施例１２＞
実施例１２として、ＵＭＴＳにおいて特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ)を跨いだＳＲＮＳ（ＳｅｒｖｉｎｇＲａｄｉｏＮｅｔｗｏｒｋＳｕｂｓｙｓｔｅｍ）ｒｅｌｏｃａｔｉｏｎ（ハンドオーバー）の例を説明する。図１９、図２０は、実施例１２を説明するための図である。図２１は、実施例１２の動作例を説明するためのシーケンス図である。

図１９を参照すると、ＵＥ３０１を備え、ＵＥ３０１と無線接続するＲＡＮ（ＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）として、ハンドオーバ元のソースＲＮＣ（ＳｏｕｒｃｅＲＮＣ）３０２、ハンドオーバ先のターゲットＲＮＣ（ＴａｒｇｅｔｅＲＮＣ）３０３を備えている。ＣＮ（ＣｏｒｅＮｅｔｗｏｒｋ）は、ソースＳＧＳＮ（ＳｏｕｒｃｅＳＧＳＮ）３０４、ターゲットＳＧＳＮ（ＴａｒｇｅｔＳＧＳＮ）３０５、ソースＳＧＷ（ＳｏｕｒｃｅＳＧＷ）３０６、ターゲットＳＧＷ（ＴａｒｇｅｔＳＧＷ）３０７、ＤＮＳサーバ３０９、ＨＳＳ３１１、ＰＧＷ３０８を備え、ＰＧＷ３０８を介してサービスネットワーク３１０に接続される。この例では、ハンドオーバのソースＳＧＳＮ３０４とターゲットＳＧＳＮ３０５は、ともに特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）である。なお、図２１は、３ＧＰＰＴＳ２３．０６０のＦｉｇｕｒｅ３９：ＳＲＮＳＲｅｌｏｃａｔｉｏｎＰｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は同図に従う。各シーケンスの詳細は、３ＧＰＰＴＳ２３．０６０６．９．２．２．１の記載が参照される（ただし、３ＧＰＰＴＳ２３．０６０のＦｉｇｕｒｅ３９では、端末はＭＳ（ＭｏｂｉｌｅＳｔａｔｉｏｎ）とされているが、図２１ではＵＥである）。

以下、図２０及び図２１を参照して動作を説明する。図１９は、ＣＮがＥＰＣで構成される場合であるが、この実施例１２の動作に関して特に差異が無い事より、本実施例の動作は、図１９、及び図２０で示される構成で有効である。図２０では、ＣＮにおいて、図１９のＣＮにおいて、ソースＳＧＷ（ＳｏｕｒｃｅＳＧＷ）３０６、ターゲットＳＧＷ（ＴａｒｇｅｔＳＧＷ）３０７がない点、図１９のＰＧＷ３０８の代わりに、ＧＧＳＮ４０８が配設されている点が相違している。

ＳｏｕｒｃｅＲＮＣ４０２が、ＵＥ４０１との接続において例えば信号劣化を検出すると、ＲｅｌｏｃａｔｉｏｎＲｅｑｕｉｒｅｄ（２）をＳｏｕｒｃｅＳＧＳＮ４０４に送信する。ＲｅｌｏｃａｔｉｏｎＲｅｑｕｉｒｅｄ（２）には、ＴａｒｇｅｔＩＤなどの情報が含まれている。ＳｏｕｒｃｅＳＧＳＮ４０４は、その情報からＴａｒｇｅｔＳＧＳＮ４０５へのｉｎｔｅｒＳＧＳＮＳＲＮＳ（ＳｅｒｖｉｎｇＲａｄｉｏＮｅｔｗｏｒｋＳｕｂｓｙｓｔｅｍ）ｒｅｌｏｃａｔｉｏｎの実行を判断する。

この実施例では、ＳｏｕｒｃｅＳＧＳＮ４０４がＴａｒｇｅｔＳＧＳＮ４０５を決定する際に、ＳｏｕｒｃｅＳＧＳＮ４０４が保持している特定ＳＧＳＮ接続要求情報を用いてＴａｒｇｅｔＳＧＳＮ４０５を決定する。ＳｏｕｒｃｅＳＧＳＮ４０４が保持している特定ＳＧＳＮ接続要求情報は、ＵＥ４０１から、特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）に接続するための特定ＳＧＳＮ接続要求情報を付与したＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）信号を受信したＲＮＣ４０３が、前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて特定ＳＧＳＮであるＳｏｕｒｃｅＳＧＳＮ４０４に通知し、ＳｏｕｒｃｅＳＧＳＮ４０４で保持しているものである。ＴａｒｇｅｔＳＧＳＮ４０５の決定は、ＳｏｕｒｃｅＳＧＳＮ４０４で保持している前記特定ＳＧＳＮ接続要求情報を元にローカルコンフィグレーションで決定するようにしてもよい。あるいは、ＳｏｕｒｃｅＳＧＳＮ４０４が保持するローカルコンフィグレーションを用いて決定しても良い。あるいは、ＳｏｕｒｃｅＳＧＳＮ４０４は、ＴａｒｇｅｔＩＤなどの位置情報と共に特定ＳＧＳＮ接続要求情報を設定し、ＤＮＳｓｅｒｖｅｒ４０９にＤＮＳＱｕｅｒｙする事で、ＴａｒｇｅｔＳＧＳＮ４０５を決定しても良い。

ＳｏｕｒｃｅＳＧＳＮ４０４がＴａｒｇｅｔＳＧＳＮ４０５へのｉｎｔｅｒＳＧＳＮＳＲＮＳｒｅｌｏｃａｔｉｏｎの実行を決定すると、ＳｏｕｒｃｅＳＧＳＮ４０４はＴａｒｇｅｔＳＧＳＮ４０５に対して、ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ（３）を送信する。ＳｏｕｒｃｅＳＧＳＮ４０４は、この信号（ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ）に、ＳｏｕｒｃｅＳＧＳＮ４０４が保持している特定ＳＧＳＮ接続要求情報を設定しても良い。

ＴａｒｇｅｔＳＧＳＮ４０５は、更なるｉｎｔｅｒＳＧＳＮＳＲＮＳｒｅｌｏｃａｔｉｏｎを実行する際、特定ＳＧＳＮ接続要求情報を利用して特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）の選択が可能になる。

これ以降のシーケンスについては、関連技術にしたがって、ｉｎｔｅｒＳＧＳＮＳＲＮＳｒｅｌｏｃａｔｉｏｎ処理が実施される。

＜実施例１３＞
実施例１３として、ＥＰＣにおいて特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）から特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）にハンドオーバする例を説明する。図２２は、実施例１３の構成を例示する図である。図２２を参照すると、ＵＥ５０１と、ＵＥ５０１に無線接続するＲＡＮ（ＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）としてソースｅＮｏｄｅＢ（ＳｏｕｒｃｅｅＮｏｄｅＢ）５０２、ターゲットＲＮＣ（ＴａｒｇｅｔｅＲＮＣ）５０３を備えている。ＣＮ（ＣｏｒｅＮｅｔｗｏｒｋ）は、ソースＭＭＥ（ＳｏｕｒｃｅＭＭＥ）５０４、ターゲットＳＧＳＮ（ＴａｒｇｅｔＳＧＳＮ）５０５、ＳＧＷ５０６、ＤＮＳサーバ５０８、ＨＳＳ５１０、ＰＧＷ５０７を備え、ＰＧＷ５０７を介してサービスネットワーク５０９に接続される。図２３は、実施例１３の動作例を説明するためのシーケンス図である。なお、図２３は、３ＧＰＰＴＳ２３．４０１のＦｉｇｕｒｅ５．５．２．１．２−２：Ｅ−ＵＴＲＡＮｔｏＵＴＲＡＮＩｕｍｏｄｅＩｎｔｅｒＲＡＴＨＯ，ｐｒｅｐａｒａｔｉｏｎｐｈａｓｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１５．５．２．１．２の記載が参照される。

以下、図２２及び図２３を参照して動作を説明する。ＳｏｕｒｃｅｅＮｏｄｅＢ５０２が、ＵＥ５０１との接続において信号劣化を検出すると、ＨａｎｄｏｖｅｒＲｅｑｕｉｒｅｄ（２）をＳｏｕｒｃｅＭＭＥ５０４に送信する。ＨａｎｄｏｖｅｒＲｅｑｕｉｒｅｄ（２）には、ＴａｒｇｅｔＴＡＩ（ＴｒａｃｋｉｎｇａｒｅａＩＤ）などの情報が含まれており、ＳｏｕｒｃｅＭＭＥ５０４は、その情報からＴａｒｇｅｔＳＧＳＮ５０５へのＩｎｔｅｒＲＡＴ（ＲａｄｉｏＡｃｃｅｓｓＴｅｃｈｎｏｌｏｇｙ）ｈａｎｄｏｖｅｒの実行を判断する。

この実施例では、ＳｏｕｒｃｅＭＭＥ５０４がＴａｒｇｅｔＳＧＳＮ５０５を決定する際に、ＳｏｕｒｃｅＭＭＥ５０４が保持している特定ＭＭＥ接続要求情報を用いてＴａｒｇｅｔＳＧＳＮ５０５を決定する。ＴａｒｇｅｔＳＧＳＮ５０５の決定は、特定ＭＭＥ接続要求情報を元にローカルコンフィグレーションで決定しても良い。あるいは、ＳｏｕｒｃｅＭＭＥ５０４が保持するローカルコンフィグレーションを用いて決定しても良い。また、ＳｏｕｒｃｅＭＭＥ５０４は、ＴａｒｇｅｔＩＤなどの位置情報と共に特定ＭＭＥ接続要求情報を設定し、ＤＮＳｓｅｒｖｅｒ５０８にＤＮＳＱｕｅｒｙする事で、ＴａｒｇｅｔＳＧＳＮ５０５を決定しても良い。

ＳｏｕｒｃｅＭＭＥ５０４がＴａｒｇｅｔＳＧＳＮ５０５へのＩｎｔｅｒＲＡＴｈａｎｄｏｖｅｒの実行を決定すると、ＳｏｕｒｃｅＭＭＥ５０４は、ＴａｒｇｅｔＳＧＳＮ５０５に対して、ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ（３）を送信する。ＳｏｕｒｃｅＭＭＥ５０４は、この信号に、ＳｏｕｒｃｅＭＭＥ５０４が保持している特定ＭＭＥ接続要求情報を設定しても良い。ＴａｒｇｅｔＳＧＳＮ５０５は、更なるＩｎｔｅｒＲＡＴｈａｎｄｏｖｅｒを実行する際、特定ＭＭＥ接続要求情報を利用して、特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）の選択が可能になる。

これ以降のシーケンスについては、関連技術にしたがったＩｎｔｅｒＲＡＴｈａｎｄｏｖｅｒ処理が実施される。

＜実施例１４＞
実施例１４として、ＥＰＣにおいて特定ＳＧＳＮ（ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ）から特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ)にハンドオーバする例を説明する。実施例１４の構成は、図２２に示されるが、ハンドオーバの方向が逆になる。また、実施例１４の動作例を説明するためのシーケンスも、基本的に、図２３において、
ＳＧＳＮとＭＭＥ、及び、
ＲＮＣとｅＮｏｄｅＢ
の記述（動作シーケンス）が逆転する（逆方向のシーケンス動作となる）だけである。

＜実施例１５＞
実施例１５として、ＥＰＣにおいてＴｒａｃｋｉｎｇＡｒｅａＵｐｄａｔｅ（ＴＡＵ）時に、ＵＥと特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）を接続させる例を説明する。実施例１５の構成は実施例１と同様である。図２４は、実施例１５の動作例を説明するためのシーケンス図である。なお、図２４は、３ＧＰＰＴＳ２３．４０１のＦｉｇｕｒｅ５．３．３．１−１：ＴｒａｃｋｉｎｇＡｒｅａＵｐｄａｔｅｐｒｏｃｅｄｕｒｅｗｉｔｈＳｅｒｖｉｎｇＧＷｃｈａｎｇｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１５．３．３の記載が参照される。以下、図１及び図２４を参照して動作を説明する。

ＵＥ１がＴＡＵＲｅｑｕｅｓｔ（３）をＭＭＥに送信する為に、まず、ｅＮｏｄｅＢ１１とのＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）Ｃｏｎｎｅｃｔｉｏｎの確立を行う。ＲＲＣＣｏｎｎｅｃｔｉｏｎ確立のために、ＵＥ１は、まずｅＮｏｄｅＢ１１にＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ信号を送信する。

この時、ＵＥ１は、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ信号にＣｕｓｔｏｍｉｚｅｄＭＭＥ２２への接続を必要とすることを示すパラメータ（ＵｓｅｒＩｄｅｎｔｉｔｙ、ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で新規に導入した値又はパラメータ）、又は、これらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））を設定する。

ＵＥ１は、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔにてｅＮｏｄｅＢに、ＣｕｓｔｏｍｉｚｅｄＭＭＥに接続可能であることを通知するＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔの新規パラメータ（ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）が実装される。

ｅＮｏｄｅＢ１１は、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ信号を受信したとき、ＵＥ１がＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に接続するべきことを記憶し、その後のＲＲＣＣｏｎｎｅｃｔｉｏｎＰｒｏｃｅｄｕｒｅを継続する。

ＲＲＣＣｏｎｎｅｃｔｉｏｎ確立後、ＵＥ１がＴＡＵＲｅｑｕｅｓｔ（２）を送信すると、ｅＮｏｄｅＢ１１が受信する。この時、ｅＮｏｄｅＢ１１は、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔの受信時に記憶した情報から、ＴＡＵＲｅｑｕｅｓｔ（３）を、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に転送する。ＴＡＵＲｅｑｕｅｓｔ（３）には、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔにて受信した特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）に接続可能であることを通知するＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔの新規パラメータ（ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）が、ｅＮｏｄｅＢ１１によって設定され、ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２に通知される。

ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２では、ＴＡＵＲｅｑｕｅｓｔ（３）を受信した後、通常のＴＡＵＰｒｏｃｅｄｕｒｅを継続する。ＣｕｓｔｏｍｉｚｅｄＭＭＥ２２は、受信したＴＡＵＲｅｑｕｅｓｔ（３）に設定された、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔにて受信した特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）に接続可能であることを通知するＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔの新規パラメータ（ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）を保持する。

また、ＵＥ１は、一般ＭＭＥ２１、及び特定ＭＭＥ（ＣｕｓｔｏｍｉｚｅｄＭＭＥ）２２のどちらのＭＭＥに接続するべきかを、ｅＮｏｄｅＢ１１に指示する機能を具備する。この時、ＵＥ１はコアネットワーク上の全てＭＭＥの情報を保持することは出来ないので、ｅＮｏｄｅＢ１１への指示は、ＭＭＥを一意に選択できる識別子ではなく、ＭＭＥ種別、若しくはサービス種別等の情報が用いられる。

以上説明したように、本実施例においては、ＵＥがｅＮｏｄｅＢに対してＭＭＥ選択を指示し、ｅＮｏｄｅＢはそれを受けてＣｕｓｔｏｍｉｚｅｄＭＭＥを指定した上で、ＴＡＵＰｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＭＭＥに位置登録させることができる。

＜実施例１６＞
実施例１６として、ＵＭＴＳにおいてＲｏｕｔｉｎｇＡｒｅａＵｐｄａｔｅ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例１６の構成は実施例６と同様である。図２５は、実施例１６の動作例を説明するシーケンス図である。なお、図２５は、３ＧＰＰＴＳ２３．０６０のＦｉｇｕｒｅ３６：ＩｕｍｏｄｅＲＡＵｐｄａｔｅｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．０６０６．９．２の記載が参照される（３ＧＰＰＴＳ２３．０６０のＦｉｇｕｒｅ３６では、端末はＭＳとされているが、図２５では、ＵＥである）。以下、図２及び図２５を参照して動作を説明する。

ＵＥ１０１がＲｏｕｔｉｎｇＡｒｅａＵｐｄａｔｅＲｅｑｕｅｓｔをＳＧＳＮに送信する為に、まずＲＮＣ１７１とのＲＲＣＣｏｎｎｅｃｔｉｏｎの確立を行う。ＲＲＣＣｏｎｎｅｃｔｉｏｎ確立の為、ＵＥ１０１は、まずＲＮＣ１７１にＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ信号を送信する。

ＲＲＣＣｏｎｎｅｃｔｉｏｎ確立後、ＵＥ１０１がＲｏｕｔｉｎｇＡｒｅａＵｐｄａｔｅＲｅｑｕｅｓｔ（１）を送信すると、まず、ＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。

ＲＮＣ１７１は、これをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔ信号の受信時に記憶した情報から、ＲｏｕｔｉｎｇＡｒｅａＵｐｄａｔｅＲｅｑｕｅｓｔ信号を、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に転送する。ＲｏｕｔｉｎｇＡｒｅａＵｐｄａｔｅＲｅｑｕｅｓｔには、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔにて受信した、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（ＵｓｅｒＩｄｅｎｔｉｔｙ、ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの新規Ｖａｌｕｅ、又は、新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又は、これらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））がＲＮＣ１７１によって設定されＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２に通知される。

ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２では、ＲｏｕｔｉｎｇＡｒｅａＵｐｄａｔｅＲｅｑｕｅｓｔを受信した後、通常のＲｏｕｔｉｎｇＡｒｅａＵｐｄａｔｅＰｒｏｃｅｄｕｒｅを継続する。ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２は、受信したＲｏｕｔｉｎｇＡｒｅａＵｐｄａｔｅＲｅｑｕｅｓｔに設定された、ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（ＵｓｅｒＩｄｅｎｔｉｔｙ、ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））を保持する。

また、ＲＮＣ１７１は、ＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この判断は、前述のとおり、ＵｓｅｒＩｄｅｎｔｉｔｙ、ＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子のいずれか、若しくは複数を組み合わせて行う。新規パラメータにはＭＴＣグループを識別するＩＤ、ＡＰＮなども含む。

以上説明したように、本実施例においては、ＵＥ１０１がＲＮＣ１７１に対してＳＧＳＮの選択を指示し、ＲＮＣ１７１は、この指示を受けて、特定ＳＧＳＮを指定した上で、ＲｏｕｔｉｎｇＡｒｅａＵｐｄａｔｅＰｒｏｃｅｄｕｒｅを継続する。かかる構成により、ＵＥ１０１を適切なＳＧＳＮに位置登録させることができる。

以下、上記した実施形態、実施例において、コアネットワーク（ＣＮ）ノードを選択するいくつかの事例について説明する。

ＭＴＣ（ＭａｃｈｉｎｅＴｙｐｅＣｏｍｍｕｎｉｃａｔｉｏｎ）デバイス（Ｍ２Ｍデバイス）を特定ＣＮノード（ＭＴＣデバイス向けに効率化したノード）に接続させる。

ＭＢＭＳ利用ユーザを特定ＣＮノード（ＭＢＭＳ対応ＣＮノード）に接続させる。

その他、新規サービスを小規模スタートさせるために、特定ＣＮノードのみでサービス提供する。

特定のＵＥを、ＭＭＥとＳＧＷをコロケート（ｃｏｌｌｏｃａｔｅ）したノードに接続させる。特に制限されないが、例えば少量のデータトラヒックを、ＳＭＳ（ＳｈｏｒｔＭｅｓｓａｇｅＳｅｒｖｉｃｅ）に載せ換えてＵＥに送信する場合、ＭＭＥとＳＧＷをコロケート（ｃｏｌｌｏｃａｔｅ）していると、ＳＭＳ変換処理の実装が容易化する。

また、端末種別（ＣＳＦＢ（ＣＳＦａｌｌｂａｃｋ）端末とＶｏＬＴＥ端末等）でＭＭＥを振り分ける。ＣＳＦＢ（ＣＳＦａｌｌｂａｃｋ）は、ＬＴＥ接続中に、ＣＳ（ＣｉｒｃｕｉｔＳｗｉｔｃｈｅｄ）サービス発着信があると、３Ｇ（又は２Ｇ）に無線を切り替える機能である。ＶｏＬＴＥ（ＶｏｉｃｅｏｖｅｒＬＴＥ）は、ＬＴＥ上で音声（等ＣＳで提供していた）サービスを提供する機能である。なお、ＣＳＦＢ端末は、ＭＳＣとのインターワークが必要である。ＶｏＬＴＥ端末はＩＭＳとのインターワークが必要である。ＣＳＦＢで、先にアタッチしているＭＳＣに、コロケート（ｃｏｌｌｏｃａｔｅ）したＭＭＥを選択させる。

なお、上記の特許文献の開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。

１ＵＥ
１１ｅＮｏｄｅＢ
２１一般ＭＭＥ
２２ＣｕｓｔｏｍｉｚｅｄＭＭＥ
３１ＨＳＳ
４１Ｓ−ＧＷ（ＳｅｒｖｉｎｇＧＷ）
５０ＨＳＳ
５１Ｐ−ＧＷ（ＰＤＮＧＷ）
６１サービスネットワーク
１０１ＵＥ（ＭＳ）
１１１ＮｏｄｅＢ
１２１一般ＳＧＳＮ
１２２ＣｕｓｔｏｍｉｚｅｄＳＧＳＮ
１３１ＨＬＲ
１４１ＧＧＳＮ
１６１サービスネットワーク
１７１ＲＮＣ
２０１ＵＥ
２０２ＳｏｕｒｃｅｅＮｏｄｅＢ
２０３ＴａｒｇｅｔｅＮｏｄｅＢ
２０４ＳｏｕｒｃｅＭＭＥ
２０５ＴａｒｇｅｔＭＭＥ
２０６ＳｏｕｒｃｅＳＧＷ
２０７ＴａｒｇｅｔＳＧＷ
２０８ＰＧＷ（ＰＤＮＧＷ）
２０９ＤＮＳｓｅｒｖｅｒ
２１０サービスネットワーク
２１１ＨＳＳ
３０１ＵＥ
３０２ＳｏｕｒｃｅＲＮＣ
３０３ＴａｒｇｅｔＲＮＣ
３０４ＳｏｕｒｃｅＳＧＳＮ
３０５ＴａｒｇｅｔＳＧＳＮ
３０６ＳｏｕｒｃｅＳＧＷ
３０７ＴａｒｇｅｔＳＧＷ
３０８ＰＧＷ（ＰＤＮＧＷ）
３０９ＤＮＳｓｅｒｖｅｒ
３１０サービスネットワーク
３１１ＨＳＳ
４０１ＵＥ
４０２ＳｏｕｒｃｅＲＮＣ
４０３ＴａｒｇｅｔＲＮＣ
４０４ＳｏｕｒｃｅＳＧＳＮ
４０５ＴａｒｇｅｔＳＧＳＮ
４０８ＧＧＳＮ
４０９ＤＮＳｓｅｒｖｅｒ
４１０サービスネットワーク
４１１ＨＳＳ
５０１ＵＥ
５０２ＳｏｕｒｃｅｅＮｏｄｅＢ
５０３ＴａｒｇｅｔＲＮＣ
５０４ＳｏｕｒｃｅＭＭＥ
５０５ＴａｒｇｅｔＳＧＳＮ
５０６ＳＧＷ
５０７ＰＧＷ（ＰＤＮＧＷ）
５０８ＤＮＳｓｅｒｖｅｒ
５０９サービスネットワーク

Claims

移動通信システムであって、
ローアクセスプライオリティ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙ )の端末が、前記端末からのＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙＩｎｄｉｃａｔｉｏｎ）をソース基地局(ｅＮｏｄｅＢ)に提供し、さらに前記ソース基地局を介してソースＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）に前記ＬＡＰＩを通知して保持させる手段と、
前記ソースＭＭＥは、前記端末がハンドオーバする場合に、前記ソース基地局からＨａｎｄｏｖｅｒＲｅｑｕｉｒｅｄを受信し、前記ソースＭＭＥに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＭＭＥを選択し、前記ターゲットＭＭＥにフォワードリロケーション要求（ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ）を送信する手段と、
を有する移動通信システム。
移動通信システムであって、
ローアクセスプライオリティ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙ )の端末が、前記端末からのＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙＩｎｄｉｃａｔｉｏｎ）をソースＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）に提供し、さらに前記ソースＲＮＣを介してソースＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳＳｕｐｐｏｒｔＮｏｄｅ）に前記ＬＡＰＩを通知して保持させる手段と、
前記ソースＳＧＳＮは、前記端末がハンドオーバする場合に、前記ソースＲＮＣからＲｅｌｏｃａｔｉｏｎＲｅｑｕｉｒｅｄを受信し、前記ソースＳＧＳＮに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＳＧＳＮを選択し、前記ターゲットＳＧＳＮにフォワードリロケーション要求（ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ）を送信する手段と、
を有する移動通信システム。
移動通信システムに用いられるＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）であって、
ソースＭＭＥが、ローアクセスプライオリティ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙ )の端末からソース基地局(ｅＮｏｄｅＢ)に提供されたＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙＩｎｄｉｃａｔｉｏｎ）を前記ソース基地局を介して受信し、保持する手段と、
前記ソースＭＭＥが、前記端末がハンドオーバする場合に、前記ソース基地局よりＨａｎｄｏｖｅｒＲｅｑｕｉｒｅｄを受信して、前記ソースＭＭＥに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＭＭＥを選択し、前記ターゲットＭＭＥにフォワードリロケーション要求（ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ）を送信する手段と、
を有するＭＭＥ。
移動通信システムに用いられるＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳＳｕｐｐｏｒｔＮｏｄｅ）であって、
ソースＳＧＳＮが、ローアクセスプライオリティ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙ )の端末からソースＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）に提供されたＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙＩｎｄｉｃａｔｉｏｎ）を前記ソースＲＮＣを介して受信し、保持する手段と、
前記ソースＳＧＳＮが、前記端末がハンドオーバする場合に、前記ソースＲＮＣよりＲｅｌｏｃａｔｉｏｎＲｅｑｕｉｒｅｄを受信して、前記ソースＳＧＳＮに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＳＧＳＮを選択し、前記ターゲットＳＧＳＮにフォワードリロケーション要求（ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ）を送信する手段と、
を有するＳＧＳＮ。
移動通信システムに用いられるローアクセスプライオリティ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙ )の端末であって、
ＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙＩｎｄｉｃａｔｉｏｎ )を保有する手段と、
前記ＬＡＰＩをソース基地局(ｅＮｏｄｅＢ)に提供し、さらに前記ソース基地局を介してソースＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）に前記ＬＡＰＩを通知し、前記ソースＭＭＥに前記ＬＡＰＩを保持させる手段と、
を有し、
前記端末がハンドオーバする場合に、前記ソース基地局が前記ソースＭＭＥにＨａｎｄｏｖｅｒＲｅｑｕｉｒｅｄを送信し、前記ソースＭＭＥが前記ソースＭＭＥに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＭＭＥを選択し、前記ターゲットＭＭＥにフォワードリロケーション要求（ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ）を送信する端末。
移動通信システムに用いられるローアクセスプライオリティ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙ )の端末であって、
ＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙＩｎｄｉｃａｔｉｏｎ )を保有する手段と、
前記ＬＡＰＩをソースＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）に提供し、さらにソースＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳＳｕｐｐｏｒｔＮｏｄｅ）に前記ＬＡＰＩを通知して前記ソースＳＧＳＮに前記ＬＡＰＩを保持させる手段と、を有し、
前記端末がハンドオーバする場合に、前記ソースＲＮＣが前記ソースＳＧＳＮにＲｅｌｏｃａｔｉｏｎＲｅｑｕｉｒｅｄを送信し、前記ソースＳＧＳＮが前記ソースＳＧＳＮに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＳＧＳＮを選択し、前記ターゲットＳＧＳＮにフォワードリロケーション要求（ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ）を送信する端末。
移動通信システムの通信方法であって、
ローアクセスプライオリティ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙ )の端末が、前記端末からのＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙＩｎｄｉｃａｔｉｏｎ）をソース基地局(ｅＮｏｄｅＢ)に提供し、さらに前記ソース基地局を介してソースＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）に前記ＬＡＰＩを通知して保持させ、
前記ソースＭＭＥは、前記端末がハンドオーバする場合に、前記ソース基地局からＨａｎｄｏｖｅｒＲｅｑｕｉｒｅｄを受信し、前記ソースＭＭＥに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＭＭＥを選択し、前記ターゲットＭＭＥにフォワードリロケーション要求（ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ）を送信する、移動通信システムの通信方法。
移動通信システムの通信方法であって、
ローアクセスプライオリティ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙ )の端末が、前記端末からのＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙＩｎｄｉｃａｔｉｏｎ）をソースＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）に提供し、さらに前記ソースＲＮＣを介してソースＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳＳｕｐｐｏｒｔＮｏｄｅ）に前記ＬＡＰＩを通知して保持させ、
前記ソースＳＧＳＮは、前記端末がハンドオーバする場合に、前記ソースＲＮＣからＲｅｌｏｃａｔｉｏｎＲｅｑｕｉｒｅｄを受信し、前記ソースＳＧＳＮに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＳＧＳＮを選択し、前記ターゲットＳＧＳＮにフォワードリロケーション要求（ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ）を送信する、移動通信システムの通信方法。
移動通信システムに用いられるＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）の通信方法であって、
ソースＭＭＥが、ローアクセスプライオリティ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙ )の端末からソース基地局（ｅＮｏｄｅＢ）に提供されたＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙＩｎｄｉｃａｔｉｏｎ）を前記ソース基地局を介して受信して保持し、
前記ソースＭＭＥが、前記端末がハンドオーバする場合に、前記ソース基地局よりＨａｎｄｏｖｅｒＲｅｑｕｉｒｅｄを受信して、前記ソースＭＭＥに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＭＭＥを選択し、前記ターゲットＭＭＥにフォワードリロケーション要求（ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ）を送信する、ＭＭＥの通信方法。
移動通信システムに用いられるＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳＳｕｐｐｏｒｔＮｏｄｅ）の通信方法であって、
ソースＳＧＳＮが、ローアクセスプライオリティ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙ )の端末からソースＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）に提供されたＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙＩｎｄｉｃａｔｉｏｎ）を前記ソースＲＮＣを介して受信して保持し、
前記ソースＳＧＳＮが、前記端末がハンドオーバする場合に、前記ソースＲＮＣよりＲｅｌｏｃａｔｉｏｎＲｅｑｕｉｒｅｄを受信して、前記ソースＳＧＳＮに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＳＧＳＮを選択し、前記ターゲットＳＧＳＮにフォワードリロケーション要求（ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ）を送信する、ＳＧＳＮの通信方法。
移動通信システムに用いられるローアクセスプライオリティ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙ )の端末の通信方法であって、
ＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙＩｎｄｉｃａｔｉｏｎ )を保有し、
前記ＬＡＰＩをソース基地局(ｅＮｏｄｅＢ)に提供し、さらにソースＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）に前記ＬＡＰＩを通知して前記ソースＭＭＥに前記ＬＡＰＩを保持させ、
前記端末がハンドオーバする場合に、前記ソース基地局が前記ソースＭＭＥにＨａｎｄｏｖｅｒＲｅｑｕｉｒｅｄを送信し、前記ソースＭＭＥが前記ソースＭＭＥに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＭＭＥを選択し、前記ターゲットＭＭＥにフォワードリロケーション要求（ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ）を送信する、端末の通信方法。
移動通信システムに用いられるローアクセスプライオリティ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙ )の端末の通信方法であって、
ＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）コネクション要求が前記ローアクセスプライオリティであることを示す情報であるＬＡＰＩ（ＬｏｗＡｃｃｅｓｓＰｒｉｏｒｉｔｙＩｎｄｉｃａｔｉｏｎ )を保有し、
前記ＬＡＰＩをソースＲＮＣ（ＲａｄｉｏＮｅｔｗｏｒｋＣｏｎｔｒｏｌｌｅｒ）に提供し、さらにソースＳＧＳＮ（ＳｅｒｖｉｎｇＧＰＲＳＳｕｐｐｏｒｔＮｏｄｅ）に前記ＬＡＰＩを通知して前記ソースＳＧＳＮに前記ＬＡＰＩを保持させ、
前記端末がハンドオーバする場合に、前記ソースＲＮＣが前記ソースＳＧＳＮにＲｅｌｏｃａｔｉｏｎＲｅｑｕｉｒｅｄを送信し、前記ソースＳＧＳＮが前記ソースＳＧＳＮに保持された前記ＬＡＰＩに基づき前記端末に専用のターゲットＳＧＳＮを選択し、前記ターゲットＳＧＳＮにフォワードリロケーション要求（ＦｏｒｗａｒｄＲｅｌｏｃａｔｉｏｎＲｅｑｕｅｓｔ）を送信する、端末の通信方法。