JP5500320B2 - 通信システムと方法と装置 - Google Patents

Description

（関連出願についての記載）
本発明は、日本国特許出願：特願２０１１−２１７３８４号（２０１１年９月３０日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。

本発明は、通信システムと方法と装置に関する。

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

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

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

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

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

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

例えば、３ＧＰＰ（3rd Generation Partnership Project）で標準化されており、同報型配信を実現するベアラサービスであるＭＢＭＳ（Multimedia Broadcast Multicast Service）サービス（同時配信サービス）は、これに対応している移動機が比較的少ないため、サービス提供の機会は少ない。しかしながら、少数のＭＢＭＳユーザに対してサービスを提供しようとした場合、通信事業者としては、コアネットワーク内の全てのノードでＭＢＭＳ機能を具備しなければ、当該数のＭＢＭＳユーザに対してサービスを提供することは出来ない。

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

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

コアネットワークノードにおいて、例えばＭＴＣ対応のノードは、通常ノードと比べ、制御信号数が多く、ユーザデータが少ないという端末(ＭＴＣデバイス）の収容に適した構成（例えばユーザ・データをやり取りするユーザ・プレーンの性能は抑えてコストを低減し、その分、制御信号系のコントロールプレーンを高性能化する等）に特化（Customize）されている。したがって、通信事業者としては、全コアネットワークノードにおいて、ＭＴＣデバイスと、ハンドセット端末の双方を、問題なく接続できる能力・機能を具備しない場合には、ＭＴＣデバイスと、ハンドセット端末の双方に対してサービスを提供することが出来ない。同様のことがＭＢＭＳサービスについてもいえる。

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

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

したがって、本発明は、上記問題点を解決すべく創案されたものであり、その目的は、システム全体の設備コストを効率化し、コストの低減を図る、システム、方法、装置を提供することにある。

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

本発明の１つの側面によれば、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）に関する機能をサポートする端末（ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）又はＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ））と、基地局と、特定の（Ｓｐｅｃｉｆｉｃ：スペシフィックな）ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）又はＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）と、を含み、前記機能をサポートする端末が、ＲＲＣコネクションリクエスト（ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｃｅ Ｃｏｎｔｒｏｌ） ｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔ）が前記機能を含むものであることを指示する情報を、前記基地局に提供する手段を含み、前記基地局が、前記機能をサポートする端末によって提供された前記指示情報を用いて、前記機能をサポートする端末を、前記特定の（Ｓｐｅｃｉｆｉｃ：スペシフィックな）ＭＭＥ又はＳＧＳＮへと導くか選択する手段（前記端末を前記特定のＭＭＥ又はＳＧＳＮへの接続に導く（向かわせる）、前記特定のＭＭＥ又はＳＧＳＮを選択する）を含む移動通信システムが提供される。

本発明の別の側面によれば、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）に関する機能をサポートする端末（ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）又はＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ））と、基地局と、特定の（Ｓｐｅｃｉｆｉｃ：スペシフィックな）ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）又はＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）とを少なくとも含む移動通信システムの通信方法であって、前記機能をサポートする端末が、ＲＲＣコネクションリクエスト（ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｃｅ Ｃｏｎｔｒｏｌ） ｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔ）が前記機能を含むものであることを指示する情報を、前記基地局に提供し、
前記基地局は、前記機能をサポートする端末によって提供された前記指示情報を用いて前記機能をサポートする端末を、前記特定の（Ｓｐｅｃｉｆｉｃ：スペシフィックな）ＭＭＥ又はＳＧＳＮへと導くか選択する（前記端末を前記特定のＭＭＥ又はＳＧＳＮへの接続に導く（向かわせる）、前記特定のＭＭＥ又はＳＧＳＮを選択する）、通信方法が提供される。

本発明の別の側面によれば、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）に関する機能をサポートする端末（ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）又はＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ））と、 特定の（Ｓｐｅｃｉｆｉｃ：スペシフィックな）ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）又はＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）と、を少なくとも含む移動通信システムに用いられる基地局であって、 前記機能をサポートする端末から、ＲＲＣコネクションリクエスト（ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｃｅ Ｃｏｎｔｒｏｌ）ｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔ）が前記機能を含むものであることを指示する情報を受信する手段と、前記機能をサポートする端末によって提供された前記指示情報を用いて前記機能をサポートする端末を、前記特定の（Ｓｐｅｃｉｆｉｃ：スペシフィックな）ＭＭＥ又はＳＧＳＮへと導くか選択する手段（前記端末を前記特定のＭＭＥ又はＳＧＳＮへの接続に導く（向かわせる）、前記特定のＭＭＥ又はＳＧＳＮを選択する）と、を含む基地局が提供される。本発明の別の側面によれば、基地局と、特定の（Ｓｐｅｃｉｆｉｃ：スペシフィックな）ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）又はＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）とを少なくとも含む移動通信システムに用いられ、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）に関する機能をサポートする端末（ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）又はＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ））であって、ＲＲＣコネクションリクエスト（ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｃｅ Ｃｏｎｔｒｏｌ） ｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔ）が前記機能を含むものであることを指示する情報を、前記基地局に提供する手段と、前記基地局に提供された前記指示情報を用いて、前記基地局に、前記機能をサポートする端末を、前記特定の（Ｓｐｅｃｉｆｉｃ：スペシフィックな）ＭＭＥ又はＳＧＳＮへと導くようにするか選択させる手段（前記端末を前記特定のＭＭＥ又はＳＧＳＮへの接続に導くようにする（向かわせる）、前記特定のＭＭＥ又はＳＧＳＮを選択させる）と、を含む端末が提供される。

本発明によれば、コアネットワークシステム全体の設備コストを効率化し、コストの低減を図ることができる。

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

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

このように、本発明によれば、端末に接続するノードを、特定サービス提供機能に最適化したノードと、特定サービス提供機能自体を具備しないノードとに分けて設置することにより、コアネットワークの全てのノードに全てのサービスに対応した能力・機能を実装する場合と比べて、システム全体のコストの低減を可能としている。

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

＜態様１＞
ＵＥ（User Equipment：ユーザ装置、端末、移動機ともいう）から、アタッチリクエスト（Attach Request）を受信した、一般ＭＭＥ（Mobility Management Entity：モビリティ管理エンティティ）は、加入者情報と端末情報に基づき、前記ＵＥが特定サービスを利用するタイプのＵＥの場合、前記ＵＥを、特定ＭＭＥ（Customized MME）に接続するために、ｅＮｏｄｅＢ（evolved NodeB：基地局装置）に対して、ＭＭＥ再選択要求信号（モビリティ管理エンティティ再選択要求信号）を送信する。

前記ｅＮｏｄｅＢは、前記特定ＭＭＥに、アタッチ要求（Attach Request）を再送することで、ＵＥを特定ＭＭＥへ接続している。

＜態様２＞
ＵＥからアタッチ要求（Attach Request）を受信した一般ＭＭＥは、前記ＵＥを、特定ＭＭＥ（Customized MME）に接続するために、前記特定ＭＭＥに対して、ＭＭＥ変更要求信号（モビリティ管理エンティティ変更要求信号）を送信する。前記特定ＭＭＥは、アタッチ処理（Attach Procedure）を継続することで、前記ＵＥを特定ＭＭＥへ接続する。

＜態様３＞
ＵＥからアタッチ要求（Attach Request）を受信した一般ＭＭＥは、前記ＵＥを特定ＭＭＥ（Customized MME）に接続するために、前記特定ＭＭＥの識別子を付与したアタッチリジェクト（Attach Reject）を、前記ＵＥに送信する。前記ＵＥは、アタッチ要求（Attach Request）に、特定ＭＭＥの識別子を付与して、再送信することで、前記ＵＥを、前記特定ＭＭＥへ接続している。

＜態様４＞
ＵＥは、特定ＭＭＥ（Customized MME/Specific MME）接続要求情報を付与したＲＲＣコネクションリクエスト（RRC(Radio Resource Control)Connection Request）（無線リソース接続要求）を、ｅＮｏｄｅＢに送信し、ＲＲＣコネクションリクエストを受信したｅＮｏｄｅＢは、ＲＲＣコネクション（RRC Connection）を確立した前記ＵＥからのアタッチ要求（Attach Request）を、ＭＭＥに送信する際に、前記特定ＭＭＥを選択することで、前記ＵＥを前記特定ＭＭＥへ接続している。

＜態様５＞
ＵＥとセッションを確立している一般ＭＭＥは、ｅＮｏｄｅＢと前記一般ＭＭＥとの間で確立されているＳ１コネクションの開放（S1 Release）時に、次回にＭＭＥを選択する際に、特定ＭＭＥ（Customized MME）を選択するように、前記ｅＮｏｄｅＢに指示をし、その後、前記ＵＥが、位置管理エリア更新リクエスト（TA(Tracking Area) Update Request）を送信した際に、前記ｅＮｏｄｅＢが前記特定ＭＭＥを選択することで、前記ＵＥを特定ＭＭＥへ接続している。

＜態様６＞
ＵＥからアタッチ要求（Attach Request）を受信した一般ＳＧＳＮ（Serving GPRS(General Radio Packet Service) Support Node：請求の範囲では「サービングＧＰＲＳサポートノード」と表記）は、加入者情報と端末情報に基づき、前記ＵＥが特定サービスを利用するタイプのＵＥの場合、前記ＵＥを特定ＳＧＳＮ（Customized SGSN）に接続するために、ＲＮＣ（Radio Network Controller：無線ネットワークコントローラ）に、ＳＧＳＮ再選択要求信号を送信し、前記ＲＮＣは、前記特定ＳＧＳＮに、アタッチ要求（Attach Request）を再送することで、前記ＵＥを前記特定ＳＧＳＮへ接続している。

＜態様７＞
ＵＥからアタッチ要求（Attach Request）を受信した一般ＳＧＳＮは、前記ＵＥを特定ＳＧＳＮ（Customized SGSN）に接続するために、前記特定ＳＧＳＮにＳＧＳＮ変更要求信号を送信し、前記特定ＳＧＳＮはアタッチ処理（Attach Procedure）を継続することで、前記ＵＥを前記特定ＳＧＳＮへ接続している。

＜態様８＞
ＵＥからアタッチ要求（Attach Request）を受信した一般ＳＧＳＮは、前記ＵＥを特定ＳＧＳＮ（Customized SGSN）に接続するために、前記特定ＳＧＳＮの識別子を付与したアタッチリジェクト（Attach Reject）を前記ＵＥに送信し、前記ＵＥは、アタッチ要求（Attach Request）に、特定ＳＧＳＮ識別子を付与して再送信することで、前記ＵＥを前記特定ＳＧＳＮへ接続している。

＜態様９＞
ＵＥは、特定ＳＧＳＮ（Customized SGSN）接続要求情報を付与したコネクションリクエスト（RRC Connection Request）をＲＮＣに送信し、該リクエストを受信したＲＮＣは、ＲＲＣコネクション（RRC Connection）を確立した前記ＵＥからのAttach RequestをＳＧＳＮに送信する際に、前記特定ＳＧＳＮを選択することで、前記ＵＥを特定ＳＧＳＮへ接続している。

＜態様１０＞
ＵＥとセッションを確立している一般ＳＧＳＮは、Ｉｕ開放（Iu Release）時に、次回ＳＧＳＮ選択で特定ＳＧＳＮ（Customized SGSN）を選択するようにＲＮＣに指示をし、その後、前記ＵＥが、位置管理エリア更新リクエスト（RA(Routing Area) Update Request）を送信した際に、ＲＮＣが特定ＳＧＳＮを選択することで、ＵＥを特定ＳＧＳＮへ接続している。

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

＜実施形態１＞
図１は、本発明の実施形態１を説明する図である。実施形態１として、ＥＰＣ（Evolved Packet Core）において、アタッチ（Attach）時に、ＵＥと特定ＭＭＥ（Customized MME）を接続させる構成について説明する。

図１において、ＵＥ１（ユーザ装置）は、特定ＭＭＥ（Customized MME）からのサービス提供を受ける端末、例えば、上記したＭＴＣデバイス、あるいは、ＭＢＭＳ対応端末等であってもよい。なお、ＵＥ１が、携帯電話端末やスマートフォン等の通常のサービスを利用する通常の携帯端末（例えばＭＴＣやＭＢＭＳ等の特定のサービス非対応の端末）場合には、一般ＭＭＥに接続される。また、後述するように、通常の携帯端末（例えばＭＴＣやＭＢＭＳ等の特定のサービス非対応の端末）からのAttach要求に対して、特定ＭＭＥ（Customized MME）が選択された場合、ＭＭＥの再選択が行われ、一般ＭＭＥに再接続される。

ｅＮｏｄｅＢ１１は、ＬＴＥ（Long Term Evolution）の基地局装置である。

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

ＨＳＳ（Home Subscriber Server）３１は、加入者情報を保持するデータベースである。

Ｓ−ＧＷ（Serving GateWay）４１、及びＰ−ＧＷ（Packet data network GateWay）５１は、ユーザプレーンを扱う装置である。

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

図１において、ｅＮｏｄｅＢが無線アクセスネットワーク（RAN: Radio Access Network）、ＭＭＥ、Ｓ−ＧＷ、Ｐ−ＧＷ等がコアネットワーク（CN: Core Network）に対応する。

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

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

ＰＣＲＦは、ポリシと課金ルール機能（Policy Charging Rules Function）である。また、ＥＩＲ（Equipment Identity Register）は、ＩＭＥＩ（International Mobile Equipment Identity）等を保持し、ＭＭＥとＳ１３インタフェースで接続される。

なお、図３において、例えば「１．Attach Request」は、ＵＥからｅＮｏｄｅＢへのアタッチ要求（Attach Request）の送信がシーケンス１であることを表わしている。図のＵＥの参照符号１（構成要素の参照符号）とは異なることを区別するため、以下の説明では、このシーケンス番号１を、「Attach Request（１）」のように、括弧書きで表記する。他のシーケンス番号についても同様とする。また、図４以降のシーケンス図についても同様の表記とする。なお、図３は、3GPP TS23.401のFigure 5.3.2.1-1: Attach procedureに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は3GPP TS23.401 5.3.2の記載が参照される。以下、図１及び図３を参照して、動作シーケンスを説明する。

図３を参照すると、ＵＥ１が、アタッチ要求（Attach Request）（１）を送信すると、まず、ｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１は、ＭＭＥに、アタッチ要求（Attach Request）（２）を中継する。

この時、ｅＮｏｄｅＢ１１は、アタッチ要求（Attach Request）（２）を一般ＭＭＥ２１に転送するべきか、Customized MME２２に転送するべきか、一意に決定することが出来ない。そのため、アタッチ要求（Attach Request）（２）は、ｅＮｏｄｅＢ１１から一般ＭＭＥ２１に転送される場合がある。

一般ＭＭＥ２１では、アタッチ要求（Attach Request）（２）を受信した後、Identity Request/Response（４、５ｂ）にて、ＵＥ１から、端末情報（ME Identity）を取得する。

なお、一般ＭＭＥ２１は、ME Identity Check Request（５ｂ）をＥＩＲに送り、ＥＩＲはME Identity Check Ack（不図示）を一般ＭＭＥに返す。更に、ＨＳＳ３１と連携して、認証及び加入者プロファイルの取得を行う。すなわち、認証、加入者プロファイル取得まで、一般ＭＭＥ２１で行う。

端末情報及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、Customized MME２２に接続するべきか判断する。

一般ＭＭＥ２１に接続する場合、通常のアタッチ処理（Attach Procedure）を継続する。

ＵＥ１を、Customized MME２２に接続する場合、一般ＭＭＥ２１は、ｅＮｏｄｅＢ１１に対して、ＭＭＥ再選択を指示するために、ＭＭＥ選択信号（MME再選択コマンド）：MME re-selection Command（本実施形態で新規に導入した、Ｓ１ＡＰ（Ｓ１ アプリケーション）信号）を送信する。

この時、一般ＭＭＥ２１は、MME re-selection Command信号に、Customized MME２２の識別子（例えばＧＵＭＭＥＩ（Globally Unique MME Identity)）を設定する。すなわち、コアネットワーク内でベアラ生成前にｅＮｏｄｅＢに再選択要求を送信し、新たなＭＭＥ選択に必要な情報（ＧＵＭＭＥＩ）を載せる。ＭＭＥは、ＵＥが、re-selection対象であるか否かを判断する機能を具備する。

ｅＮｏｄｅＢ１１は、MME re-selection Command信号を受信すると、この信号に設定された識別子に従って、Customized MME２２を選択し、アタッチ要求（Attach Request）（２）をCustomized MME２２に転送する。特定ＭＭＥ２２では、アタッチ要求（Attach Request）のＮＡＳ（Non-Access Stratum）パラメータ（ＵＥとＭＭＥ間の認証に用いられる）が必要であるため、ｅＮｏｄｅＢ１１で再送する。ｅＮｏｄｅＢ１１では、ＮＡＳメッセージを保持する機能が必要である。

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

Customized MME２２は、アタッチ要求（Attach Request）信号を受信した後、アイデンティティ要求／応答（Identity Request/Response）にて端末情報を取得し、更にＨＳＳ３１と連携して、認証及び加入者プロファイルの取得を行う。すなわち、一般ＭＭＥ２１と同様の処理を行う。

端末情報及び加入者プロファイルを取得したCustomized MME２２は、ＵＥ１を、一般ＭＭＥ２１に接続するべきか、Customized MME２２に接続するべきか判断する。

ここでは、Customized MME２２は、ｅＮｏｄｅＢ１１で再選択された後である為、MME re-selection Command信号を送信せずに、通常のアタッチ処理（Attach Procedure）を継続する。すなわち、
・Customized MME２２からＨＳＳ３１へのアプデート・ロケーション（位置更新）要求（Update Location Request）（８）の送信、
・ＨＳＳ３１からCustomized MME２２へのアプデート・ロケーション肯定応答（Update Location Ack）（１１）の送信、
・Customized MME２２からＳ−ＧＷ４１へのクリエイト・セッション要求（Create Session Request）（１２）の送信、
・Ｓ−ＧＷ４１からＰ−ＧＷ５１へのクリエイト・セッション要求（Create Session Request）（１２）の送信、
・Ｐ−ＧＷ４１によるPCEF Initiated IP-CAN Session Establishment/Modification（１４）、
・Ｐ−ＧＷ５１からＳ−ＧＷ４１へのクリエイト・セッション応答（Create Session Response）（１５）の送信、
・Ｐ−ＧＷ５１からＳ−ＧＷ４１への最初のダウンリンクデータ（First Down Link Data）の送信 （ハンドオーバ（ＨＯ）でない場合）、
・Ｓ−ＧＷ４１からＳ−ＧＷ４１へのクリエイト・セッション応答（Create Session Response）（１６）の送信、
・一般ＭＭＥ２２からｅＮｏｄｅＢ１１へのイニシャル・コンテキスト・セットアップ要求／アタッチ受理（Initial Context Setup Request/Attach Accept）（１７）の送信、
・ｅＮｏｄｅＢ１１からＵＥ１へのRRCコネクション再構成（RRC Connection Reconfiguration）（１８）の送信、
・ＵＥ１からｅＮｏｄｅＢ１１へのRRCコネクション再構成完了（RRC Connection Reconfiguration Complete）（１９）の送信、
・ｅＮｏｄｅＢ１１からCustomized MME２２へのイニシャル・コンテキスト・セットアップ応答（Initial Context Setup Response）（２０）の送信、
・ＵＥ１からｅＮｏｄｅＢへのダイレクト転送（Direct Transfer）（２１）、
・ｅＮｏｄｅＢ１１からCustomized MME２２へのアタッチ完了（Attach Complete）（２２）の送信、
・ＵＥ１からＳ−ＧＷ４１、Ｐ−ＧＷ５１への最初のアップリンクデータ（First Uplink Data）の送信、
・Customized MME２２からＳ−ＧＷ４１への修正ベアラ要求（Modify Bearer Request）（２３）の送信、
・Ｓ−ＧＷ４１からＰＣＥＦヘの修正ベアラ要求（Modify Bearer Request）（２３ａ）の送信、
・ＰＣＥＦからＳ−ＧＷ４１への修正ベアラ応答（Modify Bearer Response）（２３ｂ）の送信、
・Ｓ−ＧＷ４１からCustomized MME２２への修正ベアラ応答（Modify Bearer Response）（２４）の送信、
・Ｐ−ＧＷ５１、Ｓ−ＧＷ４１からＵＥ１への最初のダウンリンクデータ（First Downlink data）の送信が行われる。

また、一般ＭＭＥ２１及びCustomized MME２２は、ＵＥ１を、どのＭＭＥに接続させるべきか判断する機能を具備するが、この判断は、
ＵＥ１からの情報、例えば、
・ＩＭＳＩ（International Mobile Subscriber Identity：国際移動体加入者識別番号）、
・ＩＭＥＩ（International Mobile Equipment Identity： 国際移動体装置識別番号（端末識別番号））、
・UE network capability、
・MS network capability、
・Mobile station classmark 2、
・Mobile station classmark 3、
・Device properties、または、
・今後追加されるアタッチ要求（Attach Request）信号の新規パラメータ、または、
・これらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ（Public land Mobile Network）−ｉｄなど）、
ＨＳＳ３１からの情報、例えば、
・Feature-List、
・APN（Access Point Name）、または
・今後追加される位置更新回答／加入者データ挿入要求（Update Location Answer/Insert Subscriber Data Request）信号の新規パラメータ、または、
・これらのパラメータを構成する一部分の識別子、
のいずれか、もしくは複数を組み合わせた上で行う。

また、本実施例において、Customized MME２２に対して、一般ＭＭＥ２１に接続すべきＵＥ１からのアタッチ要求（Attach Request）信号が転送された場合も、同様の手段で、Customized MME２２からｅＮｏｄｅＢ１１に対して、一般ＭＭＥ２１のＭＭＥ再選択を促すことが可能である。例えば、ＵＥ１が通常の携帯端末（例えばＭＴＣやＭＢＭＳ等の特別なサービス非対応の通常の携帯端末）である場合、該ＵＥ１が一旦、Customized MME２２に接続された場合には、一般ＭＭＥ２１が再選択され、一般ＭＭＥ２１からのサービスが提供される。

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

＜実施例２＞
実施例２として、ＥＰＣ（Evolved Packet Core）において、Attach時にＵＥとCustomized MMEを接続させる別の例を説明する。実施例２のシステム構成は、実施例１と同様である。

図４は、実施例２の動作例を示すシーケンス図である。なお、図４は、3GPP TS23.401のFigure 5.3.2.1-1: Attach procedureに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、3GPP TS23.401 5.3.2の記載が参照される。以下、図１及び図４を参照して動作を説明する。

ＵＥ１がアタッチ要求（Attach Request）（１）を送信すると、ｅＮｏｄｅＢ１１が受信し、ＭＭＥにアタッチ要求（Attach Request）（２）を中継する。この時、ｅＮｏｄｅＢ１１は、アタッチ要求（Attach Request）（２）を一般ＭＭＥ２１に転送するべきか、Customized MME２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＭＭＥ２１に転送される場合がある。

一般ＭＭＥ２１では、アタッチ要求（Attach Request）（２）を受信した後、アイデンティティ要求／応答（Identity Request/Response）（５ｂ）にて、端末情報（ME Identity）を取得し、更に、ＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。すなわち、認証、加入者プロファイルまでは一般ＭＭＥ２１で行う。

端末情報、及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、Customized MME２２に接続するべきか判断する。一般ＭＭＥ２１に接続する場合、通常のアタッチ処理（Attach Procedure）を継続する。

ＵＥ１をCustomized MME２２に接続する場合、一般ＭＭＥ２１は、Customized MME２２に対して、ＭＭＥ変更を指示するために、ＭＭＥ変更要求信号（MME Change Request）（本実施例で新規に導入した、ＧＴＰ（GPRS Tunneling Protocol)信号）を送信する。

この時、一般ＭＭＥ２１は、ＭＭＥ変更要求信号（MME Change Request）に、端末認証や加入者プロファイルの取得によって生成したコンテキスト（context）情報を設定する。

Customized MME２２は、ＭＭＥ変更要求信号（MME Change Request）を受信すると、該ＭＭＥ変更要求信号に設定されたcontext情報を保持し、一般ＭＭＥ２１に対して、ＭＭＥ変更応答（MME Change Response）信号（本実施例で新規に導入した、ＧＴＰ信号）を送信する。

その後、Customized MME２２は、ＨＳＳ３１に対して、アップデートロケーション要求（Update Location Request）（８）を送信し、ＭＭＥが変更されたことをＨＳＳ３１に通知する。

ＨＳＳ３１に対して、ＭＭＥの変更ＭＭＥを通知するため、アップデートロケーション要求（Update Location Request）をCustomized MME２２で再実施する。以降のアタッチ処理（Attach Procedure）はCustomized MME２２で実施する。

また、Customized MME２２は、一般ＭＭＥ２１から受け取ったセキュリティ・コンテキスト（security context）情報が有効であれば、再認証を省略することが出来る。

その後、Customized MME２２は、アタッチ処理（Attach Procedure）を継続し、ｅＮｏｄｅＢ１１は、Customized MME２２から、イニシャル・コンテキスト・セットアップ要求／アタッチ受理（Initial Context Setup Request/Attach Accept）（１７）を受信する。

イニシャル・コンテキスト・セットアップ要求／アタッチ受理（Initial Context Setup Request/Attach Accept）（１７）は、一般ＭＭＥ２１で受けたAttach Request（２）に対する応答である。なお、一般ＭＭＥ２１とは、別のＭＭＥからの応答（Response）を受信できる機能がｅＮｏｄｅＢ１１に実装されている必要がある。

その後は、通常のアタッチ処理（Attach Procedure）を継続する。

また、一般ＭＭＥ２１、及びCustomized MME２２は、ＵＥ１を、どのＭＭＥに接続させるべきか判断する機能を具備するが、この機能は、実施例１と同様である。

また、本実施例において、Customized MME２２に対して、一般ＭＭＥ２１に接続するべきＵＥ１からのアタッチ要求（Attach Request）信号が転送された場合も、同様の手段で一般ＭＭＥ２１にＭＭＥ変更を促すことが可能である。例えばＵＥ１が通常の携帯端末（例えばＭＴＣやＭＢＭＳ等の特別なサービス非対応の通常の携帯端末）である場合、該ＵＥ１が一旦、Customized MME２２に接続された場合には、Customized MME２において、ＭＭＥ変更要求信号（MME Change Request）を一般ＭＭＥ２１に送信することで、一般ＭＭＥ２１の再選択が行われ、一般ＭＭＥ２１からのサービスが提供される。

以上説明したように、本実施例においては、一般ＭＭＥがCustomized MMEに対してＭＭＥ変更を指示し、Customized MMEはそれを受けてＭＭＥを変更した上で、アタッチ処理（Attach Procedure）を継続することにより、ＵＥを適切なＭＭＥにアタッチ（Attach）させることができる。

＜実施例３＞
実施例３として、ＥＰＣにおいてアタッチ（Attach）時に、ＵＥとCustomized MMEを接続させる例を説明する。実施例３のシステム構成は、実施例１と同様である。

図５、図６は、実施例３の動作例を説明するシーケンス図である。なお、図５、６は、3GPP TS23.401のFigure 5.3.2.1-1: Attach procedureに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、3GPP TS23.401 5.3.2の記載が参照される。以下、図１及び図５、図６を参照して動作を説明する。

ＵＥ１がアタッチ要求（Attach Request）（１）を送信すると、まずｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１からアタッチ要求（Attach Request）（２）がＭＭＥに転送される。この時、ｅＮｏｄｅＢ１１は、アタッチ要求（Attach Request）（２）を、一般ＭＭＥ２１に転送するべきか、Customized MME２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＭＭＥ２１に転送される場合がある。

一般ＭＭＥ２１では、アタッチ要求（Attach Request）（２）を受信した後、アイデンティファイ要求／応答（Identity Request/Response）（５ｂ）にて端末情報（ME Identity）を取得する。更に、一般ＭＭＥ２１は、ＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。

端末情報及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、Customized MME２２に接続するべきか判断する。一般ＭＭＥ２１に接続する場合、通常のアタッチ処理（Attach Procedure）を継続する。

ＵＥ１を、Customized MME２２に接続する場合、一般ＭＭＥ２１は、アタッチ処理（Attach Procedure）を継続せずに、ＵＥ１に対してアタッチリジェクト（Attach Reject）メッセージを送信する。すなわち、一般ＭＭＥ２１はイニシャル・コンテキスト・セットアップ要求／アタッチ拒否（Initial Context Setup Request/Attach Reject）（１７）をｅＮｏｄｅＢ１１に送信する。

この時、一般ＭＭＥ２１は、アタッチ拒否（Attach Reject）信号に、再アタッチ（re-attach）を指示するパラメータ（本実施例で導入した、新規パラメータ）、及び、再アタッチ（re-attach）時に、Customized MME２２を、ｅＮｏｄｅＢ１１が選択できるように、ＧＵＭＭＥＩ（Globally Unique MME identifier）を含むＧＵＴＩ（Globally Unique Temporary Identity(Identifier)）パラメータ（本実施例で導入した、新規パラメータ）を設定する。ＧＵＴＩパラメータは、ＧＵＭＭＥＩとＭ−ＴＭＳＩ（Temporary Mobile Station Identity）から構成される、ＭＭＥＩは、ＭＣＣ（Mobile Country Code）とＭＮＣ（Mobile Network Code）とMME Identifierから構成される。これらは本実施例で導入した新規なパラメータであるが、ｅＮｏｄｅＢ１１は、透過であるため、ｅＮｏｄｅＢ１１には影響はない。

ＵＥ１は、ｅＮｏｄｅＢ１１からアタッチ拒否（Attach Reject）信号を受信すると、図６に示すように、アタッチ拒否（Attach-Reject）信号に設定された再アタッチ（re-attach）を指示するパラメータ、及び、ＧＵＴＩパラメータに従って、ＧＵＴＩを設定したアタッチ要求（Attach Request）（１）（ＧＵＴＩによるAttach）を、ｅＮｏｄｅＢ１１に送信する。この時、ｅＮｏｄｅＢ１１は、ＧＵＴＩに含まれるＧＵＭＭＥＩから適切なＭＭＥを判断し、アタッチ要求（Attach Request）（２）を、Customized MME２２に転送する。

なお、ＵＥ１には、アタッチ拒否（Attach Reject）信号にてＧＵＴＩを受け付け、再アタッチ（re-attach）（図６のAttach Request（１））送信時に、アタッチ拒否（Attach reject）で指示されたＧＵＴＩを使用する機能が実装されている。ＭＭＥは、このＵＥが再選択（Re-Selection）対象か判断する機能が実装されている。

その後、Customized MME２２は通常のアタッチ処理（Attach Procedure）を継続する。ただし、ＧＵＴＩが設定されたアタッチ要求（Attach Request）だが、Customized MME２２自身は、context情報を保持していない。

このため、Customized MME２２は、アタッチ処理（Attach Request）信号を受信した後、アイデンティファイ要求／応答（Identity Request/Response）（４）にて、端末情報を取得し、更にＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。

また、一般ＭＭＥ２１及びCustomized MME２２はＵＥ１をどのＭＭＥに接続させるべきか判断する機能を具備するが、この機能は、前記実施例１と同様である。

また、本実施例においては、Customized MME２２に対して、一般ＭＭＥ２１に接続するべきＵＥ１からのアタッチ要求（Attach Request）信号が転送された場合も、同様にして、ＵＥ１にＭＭＥ再選択を促すことが可能である。すなわち、ＵＥ１が通常の携帯端末（例えばＭＴＣやＭＢＭＳ等の特別なサービス非対応の通常の携帯端末）である場合、該ＵＥ１が、一旦Customized MME２２に接続された場合には、該Customized MME２２は、ＵＥ１にアタッチ拒否（Attach Reject）信号を送信してＵＥ１に一般ＭＭＥ２１の再選択を促し、ＵＥ１が再アタッチ要求信号を送信することで、一般ＭＭＥ２１が再選択され、一般ＭＭＥ２１からのサービスが提供される。

以上説明したように、本実施例においては、一般ＭＭＥがＵＥに対してＭＭＥ再選択を指示し、ＵＥはそれを受けてCustomized MMEを指定した上で、アタッチ処理（Attach Procedure）を継続することにより、ＵＥを適切なＭＭＥにアタッチ（Attach）させることができる。

＜実施例４＞
実施例４として、ＥＰＣにおいて、アタッチ（Attach）時にＵＥとCustomized MMEを接続させる例を説明する。実施例４の構成は実施例１と同様である。図７は、実施例４の動作例を説明するためのシーケンス図である。なお、図７は、3GPP TS23.401のFigure 5.3.2.1-1: Attach procedureに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、3GPP TS23.401 5.3.2の記載が参照される。以下、図１及び図７を参照して動作を説明する。

ＵＥ１がアタッチ要求（Attach Request）（１）をＭＭＥに送信する為に、まずｅＮｏｄｅＢ１１とのRRCコネクション（RRC Connection）の確立を行う。RRCコネクション要求（RRC Connection）確立のために、ＵＥ１は、まずｅＮｏｄｅＢ１１にRRCコネクション要求（RRC Connection Request）信号を送信する。

この時、ＵＥ１は、本信号にCustomized MME２２への接続を必要とすることを示すパラメータ（User Identity、establishment Causeの新規Ｖａｌｕｅ、または新規パラメータ（本実施例で新規に導入した値又はパラメータ）、又は、これらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））を設定する。

ＵＥ１は、RRCコネクション要求（RRC Connection Request）にてｅＮｏｄｅＢに、Customized MMEに接続可能であることを通知するために、RRCコネクション要求（RRC Connection Request）の新規パラメータ（establishment Causeの新規Ｖａｌｕｅ若しくは新規パラメータ）が実装される。

ｅＮｏｄｅＢ１１は、RRCコネクション要求（RRC Connection Request）信号を受信したとき、ＵＥ１がCustomized MME２２に接続するべきことを記憶し、その後のRRCコネクション処理（RRC Connection Procedure）を継続する。

RRC Connection確立後、ＵＥ１がアタッチ要求（Attach Request）（１）を送信すると、ｅＮｏｄｅＢ１１が受信する。この時、ｅＮｏｄｅＢ１１は、RRCコネクション要求（RRC Connection Request）（１）の受信時に記憶した情報から、アタッチ要求（Attach Request）（２）を、Customized MME２２に転送する。

Customized MME２２では、アタッチ要求（Attach Request）（２）を受信した後、通常のAttach Procedureを継続する。

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

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

ｅＮｏｄｅＢ１１において、ＭＭＭの選択は、前述のとおり、RRCコネクション要求（RRC Connection Request）のメッセージ内のユーザＩＤ（User Identity）、通信確立要因（Establishment Cause）の新規Ｖａｌｕｅ、又は新規パラメータ、又はこれらのパラメータを構成する一部分の識別子のいずれか、若しくは複数を組み合わせて行う。

以上説明したように、本実施例においては、ＵＥがｅＮｏｄｅＢに対してＭＭＥ選択を指示し、ｅＮｏｄｅＢはそれを受けてCustomized MMEを指定した上で、アタッチ処理（Attach Procedure）を継続することにより、ＵＥを適切なＭＭＥにアタッチ（Attach）させることができる。

＜実施例５＞
実施例５として、ＥＰＣにおいて、トラッキングエリア更新（TA Update）時に、ＵＥとCustomized MMEを接続させる例を説明する。実施例５の構成は、実施例１と同様である。

図８、図９は、実施例５の動作例を説明するためのシーケンス図である。なお、図８は、3GPP TS23.401のFigure 5.3.5-1: S1 Release Procedureに基づく。3GPP TS23.401 5.3.5が参照される。図９は、Figure 5.3.3.1-1: Tracking Area Update procedure with Serving GW changeに基づく。3GPP TS23.401 5.3.3が参照される。図１、図８、図９（及び図３の一部）を参照して、動作を説明する。

ＵＥ１がアタッチ要求（Attach Request）を送信すると（図３の１参照）、まずｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１からアタッチ要求（Attach Request）がＭＭＥに中継される（図３の２参照）。

この時、ｅＮｏｄｅＢ１１は、アタッチ要求（Attach Request）を一般ＭＭＥ２１に転送するべきか、Customized MME２２に転送するべきか、一意に決定することが出来ない。そのため、アタッチ要求（Attach Request）が一般ＭＭＥ２１に転送される場合がある。

一般ＭＭＥ２１ではアタッチ要求（Attach Request）を受信した後、アイデンティティ要求／応答（Identity Request/Response）（図３の４、５ｂ参照）にて端末情報を取得し、更に、ＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。

端末情報及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、Customized MME２２に接続するべきか判断する。その後、通常のAttach Procedureを継続する。一般ＭＭＥ２１に接続する場合は、ここで処理が完了する。

ＵＥ１を、Customized MME２２に接続する場合、一般ＭＭＥ２１はＵＥ１に対して、トラッキングエリア更新（TA Update）を行わせるために、図８に示すように、S1解放（S1 Release）を行う。この時、一般ＭＭＥ２１はｅＮｏｄｅＢ１１に、S1 UE Context Release Command（４）を送信する。

一般ＭＭＥ２１は、S1 UE Context Release Command（４）で、次にｅＮｏｄｅＢがＭＭＥとS1コネクション（S1 Connection）を確立するときに選択するべきＭＭＥを、ＭＭＥ識別子（例えばＧＵＭＭＥＩ）で指示する。ロードバランシングTAU（Load Balancing TAU）起動のためのS1解放（S1 Release）時に、ｅＮｏｄｅＢに対して、次のＭＭＥを指定するＧＵＭＭＥＩを指示するためのパラメータは新規パラメータである。この時、ｅＮｏｄｅＢ１１は、S1解放（S1 Release）完了後もＵＥ１に対するセッション情報を保持している間、次回ＭＭＥ選択の為の情報として、ＭＭＥ識別子を保持し続ける。

S1 Releaseが行われると、次にＵＥ１は、図９に示すように、ＴＡＵ要求（TAU Request）（２）を送信する。ＵＥ１からのＴＡＵ要求（TAU Request）（２）を、まずｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１からＴＡＵ要求（ＴＡＵ Ｒｅｑｕｅｓｔ）（３）がＭＭＥに転送される。この時、ｅＮｏｄｅＢ１１は、S1解放（S1 Release）済みの状態であることから、ＭＭＥ選択を行い、S1コネクション（Ｓ１ Ｃｏｎｎｅｃｔｉｏｎ）を確立する。ｅＮｏｄｅＢ１１は、S1解放（S1 Release）時に、旧ＭＭＥ(ｏｌｄ ＭＭＥ)（＝一般ＭＭＥ）から指示されたＧＵＭＭＥＩに従ってCustomized MMEを選択する。ここで、ｅＮｏｄｅＢ１１はＵＥ毎に次のＧＵＭＭＥＩを保持する機能を有する。

ＭＭＥの選択において、ｅＮｏｄｅＢ１１は、一般ＭＭＥ２１から受信したS1 UE Context Release Command信号で指示されたＧＵＭＭＥＩのＭＭＥ識別子（MME Identifier）に従い、Customized MME２２を選択する。ＮＡＳ上のＧＵＴＩ（ＧＵＭＭＥＩ）は、ｏｌｄ ＭＭＥ（＝一般ＭＭＥ）を示しているのでｍコンテキストの取得が可能である。

Customized MME２２は、ＴＡＵ要求（TAU Request）（３）を受信した後、通常のＴＡ更新処理（TA Update Procedure）を継続する。Customized MME２２は、一般ＭＭＥ２１にコンテキスト要求（Context Request）（４）を送信し、コンテキスト応答（Context Response）（５）を受け取る。

Customized MME２２は、Ｓ−ＧＷがリロケート（ｒｅｌｏｃａｔｅ）した場合、一般ＭＭＥにＳ−ＧＷの変更指示を含むコンテキストアクノリッジ（Context Acknowledge）（７）を送信し、Customized MME２２が新たなＳ−ＧＷ４１（new Serving GW）を選択すると、Customized MME２２は、新たなＳ−ＧＷ４１に、クリエイトセッション要求（Create Session Request）（８）を送信する。

これを受けて新たなＳ−ＧＷ４１（new Serving GW）は、修正ベアラ要求（Modify Bearer Request）（９）をＰ−ＧＷ５１に送信し、その応答をＰ−ＧＷ５１から受けると、新たなＳ−ＧＷはクリエイトセッション応答（Create Session Response）（１１）をCustomized MME２２に返す。

Customized MME２２はアップデートロケーション（Update Location）（１２）をＨＳＳ３１に送信する。

ＨＳＳ３１から一般ＭＭＥ２１にキャンセルロケーション（Cancel Location）（１３）を受け取った一般ＭＭＥ２１は、ＭＭコンテキストを削除し、アップデートロケーション肯定応答（Update Location Ack）（１４）をＨＳＳ３１に送信する。ＨＳＳ３１からのCustomized MME２２に、アップデートロケーション（Update Location）（１２）に対するアップデートロケーション肯定応答（Update Location Ack）（１７）が送信される。

一般ＭＭＥ２１は、旧Ｓ−ＧＷ４１（old Serving GW）にデリート（削除）セッション要求（Delete Session Request）（１８）を送信し、その応答（１９）が、旧Ｓ−ＧＷ４１（ｏｌｄ Ｓｅｒｖｉｎｇ ＧＷ）から一般ＭＭＥ２１に送信される。

Customized MME２２からＵＥ１にＴＡＵ受理（TAU Accespt）（２０）が送信される。

ＴＡＵ受理（TAU Accept）（２０）にＧＵＴＩが含まれる場合、ＵＥ１は、Customized MME２２に対して、ＴＡＵ完了（TAU Complete）（２１）を返すことで、受信した信号ＴＡＵ受理（TAU Accept）（２０）の肯定応答とする。

一般ＭＭＥ２１及びCustomized MME２２は、ＵＥ１をどのＭＭＥに接続させるべきか判断する機能を具備するが、この機能は実施例１と同様である。

また、本実施例において、上記と同様の手段で、一般ＭＭＥ２１に接続すべきＵＥ１（例えば通常の携帯端末（例えばＭＴＣやＭＢＭＳ等の特別なサービス非対応の通常の携帯端末）からのＴＡ更新要求（TA Update Request）を受信したｅＮｏｄｅＢ１１において、一般ＭＭＥを選択することで、該ＵＥ１を一般ＭＭＥ２１へ接続し、一般ＭＭＥ２１からのサービスが提供される。

また、本実施例では、図９の手順にて、ＴＡ更新処理（TA Update Procedure）を用いたが、本実施例での特徴は、ｅＮｏｄｅＢ１１でＭＭＥの選択を行うことである。このため、例えば、サービス要求（Service Request）等、S1コネクション（S1 Connection）を再確立するための、その他の手続き（Procedureでも）実現可能である。

以上説明したように、本実施例においては、一般ＭＭＥがｅＮｏｄｅＢに対してＭＭＥ再選択を指示し、ｅＮｏｄｅＢはそれを受けて次回ＭＭＥ選択時にCustomized MMEを指定した上で、処理（Procedure）を継続することにより、ＵＥを適切なＭＭＥに接続させることができる。

＜実施形態２＞
実施形態２として、ＵＭＴＳ（Universal Mobile Telecommunications System）においてアタッチ（Attach）時にＵＥと特定ＳＧＳＮ（Customized SGSN）を接続させる例を説明する。図２は、実施形態２のシステム構成を示す図である。

ＵＥ１０１は、特定ＳＧＳＮ（Customized SGSN）からのサービス提供を受ける端末、例えば、上記したＭＴＣデバイス、あるいは、ＭＢＭＳ対応端末等であってもよい。なお、ＵＥ１０１が、携帯電話端末やスマートフォン等の通常のサービスを利用する通常の携帯端末（例えばＭＴＣやＭＢＭＳ等の特定のサービス非対応の端末）場合には、一般ＳＧＳＮに接続される。また、後述するように、通常の携帯端末（例えばＭＴＣやＭＢＭＳ等の特定のサービス非対応の端末）からのAttach要求に対して、特定ＳＧＳＮ（Customized SGSN）が選択された場合、ＳＧＳＮの再選択が行われ、一般ＳＧＳＮに再接続される。

ＮｏｄｅＢ１１１及びＲＮＣ（Radio Network Controller）１７１は、ＵＭＴＳシステムで採用された無線アクセス（Radio access）用の装置を表している。

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

ＨＬＲ（Home Location Register）１３１は、加入者情報を保持するデータベースである。

ＧＧＳＮ（Gateway GPRS(General Radio Packet Service) Support Node：請求の範囲では「ゲートウエイＧＰＲＳサポートノード」と表記）１４１は、外部網と接続するゲートウェイ装置である。サービスネットワーク１６１は、外部網（データパケットネットワーク）を示す。

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

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

＜実施例６＞
図１０は、実施例６の動作例を説明するためのシーケンス図であり、3GPP TS 23.060 6.5 Fig. 22に基づく。

図１０において、
ＭＳ（Mobile Station）は、図２のＵＥ１０１、
ＲＡＮ（Radio Access Network；無線アクセスネットワーク）は、図２のＮｏｄｅＢ１１７１とＲＮＣ１７１、
一般ＳＧＳＮは、図２の一般ＳＧＳＮ１２１、
Customized SGSNは，図２のCustomized SGSN（特定ＳＧＳＮ）１２２、
ＧＧＳＮは図２のＧＧＳＮ１４１、
ＨＬＲは、図２のＨＬＲ１３１である。

ＭＳＣ（Mobile Switching Center）／ＶＬＲ（Visitor Location Register）のＶＬＲはＨＬＲ以外のＣＳサービス用のロケーションレジスタである。ＥＩＲ（Equipment Identifier Register）は有効な移動装置の識別子を保持する。

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

ＵＥ１０１（ＭＳ）がアタッチ要求（Attach Request）（１）を送信すると、まずＮｏｄｅＢ１１１が受信し、アタッチ要求（Attach Request）（１）をＲＮＣ１７１に転送する。ＲＮＣ１７１は、アタッチ要求（Attach Request）（１）をＳＧＳＮに転送する。この時、ＲＮＣ１７１は、アタッチ要求（Attach Request）を一般ＳＧＳＮ１２１に転送するべきか、Customized SGSN１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。

一般ＳＧＳＮ１２１では、アタッチ要求（Attach Request）を受信した後、アイデンティティ要求／応答（Identity Request/Response）（３、４）にて端末情報を取得し、更にＨＬＲ１３１と連携して、認証及び加入者プロファイルの取得を行う。認証、加入者プロファイル取得まで、一般ＳＧＳＮ１２１で実施する。

端末情報及び加入者プロファイルを取得した一般ＳＧＳＮ１２１は、ＵＥ１０１を一般ＳＧＳＮ１２１に接続するべきか、Customized SGSN１２２に接続するべきか判断する。一般ＳＧＳＮ１２１に接続する場合、通常のアタッチ処理（Attach Procedure）を継続する。

ＵＥ１０１を、Customized SGSN１２２に接続する場合、一般ＳＧＳＮ１２１は、ＲＮＣ１７１に対して、ＳＧＳＮ再選択を指示するために、ＳＧＳＮ再選択コマンド（SGSN re-selection Command）（本実施例で新規に導入した、ＲＡＮＡＰ信号）を送信する。この時、一般ＳＧＳＮ１２１はＳＧＳＮ再選択コマンド（SGSN re-selection Command）信号にCustomized SGSN１２２を特定する識別子（例えばＲＡＩ(Routing Area Identifier）、ＮＲＩ（Network Resource Identifier）など）を設定する。すなわち、一般ＳＧＳＮ１２１は、ＲＮＣに１７１対して、ＳＧＳＮ再選択要求し、その際、特定ＳＧＳＮ１２２の選択に必要な情報（ＲＡＩ）を載せる。なお、同一プール内での再選択の場合は、ＮＲＩでよい。ＳＧＳＮは、ＵＥ１０１が、再選択（re-selection）対象か判断する機能を有する。

ＲＮＣ１７１は、ＳＧＳＮ再選択コマンド（SGSN re-selection Command）信号を受信すると、本信号に設定された識別子に従ってCustomized SGSN１２２を選択し、アタッチ要求（Attach Request）（１）を転送する。特定ＳＧＳＮ１２２でアタッチ要求（Attach Request）のＮＡＳ（Non Access Stratum）パラメータが必要なので、ＲＮＣ１７１でアタッチ要求（Attach Request）を再送する。ＲＮＣ１７１ではＮＡＳメッセージを保持する機能が実装されている。

新たなＳＧＳＮ（＝Customized SGSN）では旧ＳＧＳＮ（＝一般ＳＧＳＮ）を特定できないため、コンテキスト（context）を引き継ぐことができない。そのため、新たなＳＧＳＮでも認証／加入者プロファイル取得を行う必要がある。Customized SGSN１２２は、アタッチ要求（Attach Request）（２）を受信した後、アイデンティティ要求／応答（Identity Request/Response）にて端末情報を取得し、更にＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。つまり、一般ＳＧＳＮ１２１と同様の処理を行う。

端末情報及び加入者プロファイルを取得したCustomized SGSN１２２は、ＵＥ１０１を、一般ＳＧＳＮ１２１に接続するべきか、Customized SGSN（０２２）に接続するべきか判断する。ここでは、ＲＮＣ１７１で再選択された後の為、ＳＧＳＮ再選択コマンド（SGSN re-selection Command）信号を送信せずに、通常のアタッチ処理（Attach Procedure）を継続する。

また、一般ＳＧＳＮ１２１及びCustomized SGSN１２２はＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この判断はＵＥ１０１からの情報（例えば、
・ＩＭＳＩ（International Mobile Subscriber Identity）、
・ＩＭＥＩ、
・UE network capability、
・MS network capability、
・Mobile station classmark ２、
・Mobile station classmark ３、
・Device properties、又は今後追加されるアタッチ要求（Attach Request）信号の新規パラメータ、又はこれらのパラメータを構成する一部分の識別子※ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等）、
ＨＬＲ１３１からの情報（例えば
・Feature-List、
・APN、
・又は今後追加される位置更新回答／加入者データ挿入要求（Update Location Answer/Insert Subscriber Data Request）信号の新規パラメータ、又は、
・これらのパラメータを構成する一部分の識別子）
のいずれか、若しくは複数を組み合わせて行う。

また、本実施例において、Customized SGSN１２２に対して一般ＳＧＳＮ１２１に接続するべきＵＥ１０１からのアタッチ要求（Attach Request）信号が転送された場合も、同様の手段でＲＮＣ１７１にＳＧＳＮ再選択を促すことが可能である。ＵＥ１０１が通常の携帯端末（例えばＭＴＣやＭＢＭＳ等の特定のサービス非対応の端末）の場合、Customized SGSN１２２に接続すると、Customized SGSN１２２は、ＲＮＣ１７１にＳＧＳＮ再選択を促し、一般ＳＧＳＮ１２１が再選択され、一般ＳＧＳＮ１２１からのサービスが提供される。

以上説明したように、本実施例においては、ＳＧＳＮがＲＮＣに対してＳＧＳＮ再選択を指示し、ＲＮＣはそれを受けてＳＧＳＮを再選択した上で、アタッチ処理（Attach Procedure）を継続することにより、ＵＥを適切なＳＧＳＮにアタッチ（Attach）させることができる。

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

ＵＥ１０１が、アタッチ要求（Attach Request）（１）を送信すると、まず、ＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。ＲＮＣ１７１はこれをＳＧＳＮに転送する。この時、ＲＮＣ１７１は、アタッチ要求（Attach Request）を一般ＳＧＳＮ１２１に転送するべきか、Customized SGSN１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。

一般ＳＧＳＮ１２１では、アタッチ要求（Attach Request）を受信した後、アイデンティティ要求／応答（Identity Request/Response）にて端末情報を取得し、更に、ＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。認証、加入者プロファイル取得まで、一般ＳＧＳＮ１２１で実施する。

端末情報及び加入者プロファイルを取得した一般ＳＧＳＮ１２１は、ＵＥ１０１を一般ＳＧＳＮ１２１に接続するべきか、Customized SGSN１２２に接続するべきか判断する。一般ＳＧＳＮ１２１に接続する場合、通常のアタッチ処理（Attach Procedure）を継続する。

ＵＥ１０１をCustomized SGSN１２２に接続する場合、一般ＳＧＳＮ１２１は、Customized SGSN１２２に対してＳＧＳＮ変更を指示するために、SGSN Change Request（本実施形態で新規に導入した、ＧＴＰ信号）を送信する。

この時、一般ＳＧＳＮ１２１は、ＳＧＳＮ変更要求（SGSN Change Request）信号に、移動機認証や加入者プロファイルの取得によって生成したコンテキスト（context）情報を設定する。すなわち、一般ＳＧＳＮ１２１からCustomized SGSN１２２に、ＳＧＳＮ変更（SGSN Change）を要求する際に、コンテキストを新たなＳＧＳＮ（Customized SGSN１２２）に通知する。ＳＧＳＮはＵＥ１０１が再選択（re-selection）対象か判断する機能が実装されている。

Customized SGSN１２２は、ＳＧＳＮ変更要求（SGSN Change Request）信号を受信すると、ＳＧＳＮ変更要求（SGSN Change Request）信号に設定されたコンテキスト（context）情報を保持し、一般ＳＧＳＮ１２１に対して、ＳＧＳＮ変更応答（SGSN Change Response）信号（本実施形態で新規に導入した、ＧＴＰ信号）を送信する。

その後、Customized SGSN１２２は、ＨＬＲ１３１に対して、アップデートロケーション（Update Location）信号（８）を送信し、ＳＧＳＮが変更されたことをＨＬＲ１３１に通知する。

また、Customized SGSN１２２は、一般ＳＧＳＮ１２１から受け取ったセキュリティ・コンテキスト（security context）情報が有効であれば、再認証を省略することが出来る。

その後、Customized SGSN１２２は、アタッチ処理（Attach Procedure）を継続し、ＲＮＣ１７１は、Customized SGSN１２２からアタッチ受理（Attach Accept）信号（９）を受信する。その後は、通常のAttach Procedureを継続する。

また、一般ＳＧＳＮ１２１及びCustomized SGSN１２２は、ＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この機能は実施例６と同様である。

また、本実施例において、Customized SGSN１２２に対して一般ＳＧＳＮ１２１に接続するべきＵＥ１０１からのアタッチ要求（Attach Request）信号が転送された場合も、同様の手段で一般ＳＧＳＮ１２１にＳＧＳＮ変更を促すことが可能である。ＵＥ１０１が通常の携帯端末（例えばＭＴＣやＭＢＭＳ等の特定のサービス非対応の端末）の場合、Customized SGSN１２２に接続すると、Customized SGSN１２２において、一般ＳＧＳＮ１２１が再選択され、一般ＳＧＳＮ１２１からのサービスが提供される。

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

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

ＵＥ１０１（ＭＳ）が、アタッチ要求（Attach Request）（１）を送信すると、まずＮｏｄｅＢ１１１が受信し、該アタッチ要求をＲＮＣ１７１に転送する。ＲＮＣ１７１は、該アタッチ要求をＳＧＳＮに転送する。この時、ＲＮＣ１７１は該アタッチ要求（Attach Request）を一般ＳＧＳＮ１２１に転送するべきか、Customized SGSN１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。

一般ＳＧＳＮ１２１では、アタッチ要求（Attach Request）（１）を受信した後、アイデンティティ要求／応答（Identity Request/Response）（３）にて端末情報を取得し、更に、ＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。

端末情報及び加入者プロファイルを取得した一般ＳＧＳＮ１２１は、ＵＥ１０１を一般ＳＧＳＮ１２１に接続するべきか、Customized SGSN１２２に接続するべきか判断する。一般ＳＧＳＮ１２１に接続する場合、通常のアタッチ処理（Attach Procedure）を継続する。

ＵＥ１０１をCustomized SGSN１２２に接続する場合、一般ＳＧＳＮ１２１は、アタッチ処理（Attach Procedure）を継続せずに、ＵＥ１０１に対してアタッチ拒否（Attach Reject信号）（９）を送信する。

この時、一般ＳＧＳＮ１２１はアタッチ拒否（Attach Reject）信号に、再アタッチ（re-attach）を指示するパラメータと、再アタッチ（re-attach）時に、Customized SGSN１２２を、ＲＮＣ１７１が選択できるようＲＡＩ（Routing Area Identity）パラメータ（本実施形態で新規に導入した、パラメータ）を設定する。これらは本実施例で導入した新規なパラメータであるが、ＲＮＣ１７１では、透過であるため影響はない。

ＵＥに１０１は、アタッチ拒否（Attach Reject）でＲＡＩを受け付け、再アタッチ（Re-attach）時に、アタッチの拒否（Reject）で指示されたＲＡＩを使用する機能が必要である。ＳＧＳＮはＵＥ１０１が再選択（re-selection）対象か判断する機能を有する。

ＵＥ１０１は、アタッチ拒否（Attach Reject）信号（９）を受信すると、該アタッチ拒否信号（９）に設定された再アタッチ（re-attach）を指示するパラメータ及びＲＡＩパラメータに従って、図１３に示すように、ＲＡＩを設定したアタッチ要求（Attach Request）信号（１）を、ＲＮＣ１７１に送信する（Ｐ−ＴＭＳＩ（Packet Temporary Mobile Subscriber Identifier）による再アタッチ）。この時、ＲＮＣ１７１は、ＲＡＩから適切なＳＧＳＮを判断し、アタッチ要求を、Customized SGSN１２２に転送する。

その後、Customized SGSN１２２は、通常のアタッチ処理（Attach Procedure）を継続する。

ただし、ＲＡＩが設定されたアタッチ要求（Attach Request）であるが、Customized SGSN１２２自身は、コンテキスト情報を保持していない。このため、アタッチ要求（Attach Request）信号（１）を受信した後、アンデンティティ要求／応答（Identity Request/Response）（３）にて、端末情報を取得し、更にＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。

また、一般ＳＧＳＮ１２１及びCustomized SGSN１２２はＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この機能は実施例６と同様である。

また、本実施例において、Customized SGSN１２２に対して一般ＳＧＳＮ（１２１）に接続するべきＵＥ１０１からのアタッチ要求（Attach Request）信号が転送された場合も、同様の手段でＵＥ１０１にＳＧＳＮ再選択を促すことが可能である。ＵＥ１０１が通常の携帯端末（例えばＭＴＣやＭＢＭＳ等の特定のサービス非対応の端末）の場合、Customized SGSN１２２に接続すると、Customized SGSN１２２は、ＵＥ１０１に対してアタッチ拒否（Attach Reject）信号を送信してＵＥ１０１に一般ＳＧＳＮ１２１の再選択を促し、ＵＥ１０１が再アタッチ要求（Attach Request）信号を送信することで、一般ＳＧＳＮ１２１が再選択され、一般ＳＧＳＮ１２１からのサービスが提供される。

以上説明したように、本実施例においては、一般ＳＧＳＮがＵＥに対してＳＧＳＮ再選択を指示し、ＵＥはそれを受けて特定ＳＧＳＮを指定した上で、アタッチ処理（Attach Procedure）を継続することにより、ＵＥを適切なＳＧＳＮにアタッチ（Attach）させることができる。

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

ＵＥ１０１がアタッチ要求（Attach Request）をＳＧＳＮに送信する為に、まずＲＮＣ１７１とのRRCコネクション（RRC Connection）の確立を行う。RRCコネクション（RRC Connection）確立の為、ＵＥ１０１は、まずＲＮＣ１７１にRRCコネクション要求（RRC Connection Request）信号を送信する。

この時、ＵＥ１０１は、RRCコネクション要求（RRC Connection Request）信号に、Customized SGSN１２２への接続を必要とすることを示すパラメータ（User Identity、establishment Causeの新規Value、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ−ｉｄ等））を設定する。

ＲＮＣ１７１は、RRCコネクション要求（RRC Connection Request）信号を受信したとき、ＵＥ１０１がCustomized SGSN１２２に接続するべきことを記憶し、その後のRRCコネクション処理（RRC Connection Procedure）を継続する。

RRCコネクション（RRC Connection）確立後、ＵＥ１０１がアタッチ要求（Attach Request）（１）を送信すると、まず、ＮｏｄｅＢ１１１が受信し、アタッチ要求（Attach Request）をＲＮＣ１７１に転送する。

ＲＮＣ１７１は、アタッチ要求（Attach Request）をＳＧＳＮに転送する。この時、ＲＮＣ１７１はRRCコネクション要求（RRC Connection Request）信号の受信時に記憶した情報から、アタッチ要求（Attach Request）信号を、Customized SGSN１２２に転送する。

Customized SGSN１２２では、アタッチ要求（Attach Request）信号を受信した後、通常のアタッチ処理（Attach Procedure）を継続する。

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

また、ＲＮＣ１７１は、ＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この判断は、前述のとおり、ユーザアイデンティ・イスタブリッシュメント原因（User Identity、establishment Cause）の新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又は、これらのパラメータを構成する一部分の識別子のいずれか、若しくは複数を組み合わせて行う。

以上説明したように、本実施例においては、ＵＥ１０１がＲＮＣ１７１に対してＳＧＳＮの選択を指示し、ＲＮＣ１７１は、この指示を受けて、特定ＳＧＳＮを指定した上で、アタッチ処理（Attach Procedure）を継続する。かかる構成により、ＵＥ１０１を適切なＳＧＳＮにアタッチ（Attach）させることができる。

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

ＵＥ１０１がアタッチ要求（Attach Request）を送信すると（図１０の１．参照）、まずＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。ＲＮＣ１７１はこれをＳＧＳＮに転送する。この時、ＲＮＣ１７１はアタッチ要求（Attach Request）を一般ＳＧＳＮ１２１に転送するべきか、Customized SGSN（１２）に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。

一般ＳＧＳＮ１２１ではアタッチ要求（Attach Request）を受信した後、アイデンティティ要求／応答（Identity Request/Response）にて端末情報を取得し（図１０の３、５．参照）、更にＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。

端末情報及び加入者プロファイルを取得した一般ＳＧＳＮ１２１は、ＵＥ１０１を一般ＳＧＳＮ１２１に接続するべきか、Customized SGSN１２２に接続するべきか判断する。一般ＳＧＳＮ１２１に接続する場合、通常のアタッチ処理（Attach Procedure）を継続する。

ＵＥ１０１をCustomized SGSN１２２に接続する場合、一般ＳＧＳＮ１２１はＵＥ１０１に対して、ＲＡ（Routing Area）アプデート（Update）を行わせるために、図１５に示すように、Ｉｕ解放（Iu Release）を行う。

この時、一般ＳＧＳＮ１２１は、ＲＮＣ１７１にＩｕ解放コマンド（Iu Release Command）信号（図１５の４）を送信する。一般ＳＧＳＮ１２１は、Ｉｕ解放コマンド（Iu Release Command）信号にて、次にＲＮＣがＳＧＳＮとＩｕコネクション（Iu Connection）を確立するときに選択するべき、ＳＧＳＮをＳＧＳＮ識別子（例えばＲＡＩ、ＮＲＩ等）で指示する。なお、同一プール内の場合、ＮＲＩでもよい。

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

Ｉｕ解放（Iu Release）が行われると（ＲＮＣ１７１から一般ＳＧＳＮ１２１へのＩｕ解放完了（IU Release Complete）（６）の送信後）、次に、図１６に示すように、ＵＥ１０１はＲＡＵ要求（RA Update Request）（２）を送信する。

ＲＡＵ要求（RAU Request）（２）を、まず、ＮｏｄｅＢ１１１が受信し、ＮｏｄｅＢ１１１は、ＲＡＵ要求（RAU Request）（３）をＲＮＣ１７１に転送する。

ＲＮＣ１７１はＲＡＵ要求をＳＧＳＮに転送する。この時、ＲＮＣ１７１はＩｕ解放（c）済みの状態なので、ＳＧＳＮ選択を行い、Ｉｕコネクション（Iu Connection）を確立する。

ＳＧＳＮ選択において、ＲＮＣ１７１は、一般ＳＧＳＮ１２１から受信したＩｕ解放コマンド（Iu Release Command）信号で指示されたＳＧＳＮ識別子に従い、Customized SGSN１２２を選択する。ＲＮＣはＩｕ解放（Iu Release）時にｏｌｄ ＳＧＳＮ（＝一般ＳＧＳＮ）から指示されたＲＡＩ（若しくはＮＲＩ）に従ってCustomized SGSNを選択する。なお、ＲＮＣは、ＵＥ毎に次のＲＡＩを保持する機能を有する。

Customized SGSN１２２は、ＲＡＵ要求を受信した後、通常のＲＡ更新処理（RA Update Procedure）を継続する。ＮＡＳ上のＰ−ＴＭＳＩ（ＲＡＩ）は旧ＳＧＳＮである一般ＳＧＳＮを示しているので、コンテキストを取得する。

また、一般ＳＧＳＮ１２１及びCustomized SGSN１２２はＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この機能は実施例６と同様である。

また、本実施例において、上記と同様の手段で、一般ＭＭＥ２１に接続すべきＵＥ１０１（例えば通常の携帯端末（例えばＭＴＣやＭＢＭＳ等の特別なサービス非対応の通常の携帯端末）からのＲＡアップデート要求（RA Update Request））を受信したＲＮＣ１７において一般ＳＧＳＮ１２１を選択することで、ＵＥ１０１を一般ＳＧＳＮ１２１に接続し、一般ＳＧＳＮ１２１からのサービスが提供される。

また、本実施例では、図１６の手順にて、ＲＡアップデート処理（RA Update Procedure）を用いたが、本実施例では、ＲＮＣ１７１でＳＧＳＮ選択を行う部分であるので、例えば、PDP Context Activation等、Ｉｕコネクション（Iu Connection）を再確立するその他の処理（Procedure）でも実現可能である。

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

以下に、前記した各実施例の相違点について説明する。

＜モバイルネットワーク＞
実施例１−５は、例えばＬＴＥ（Long Term Evolution）（無線アクセスネットワークは、Ｅ−ＵＴＲＡＮ（Evolved-Universal Terrestrial Radio Access Network）、コアネットワークはＥＰＣ）、
実施例６−１０は、例えば３Ｇ（3rd Generation）である（無線アクセスネットワークはＵＴＲＡＮ（Universal Terrestrial Radio Access Network）、コアネットワークはＧＰＳＲ）。

＜実現方式＞
Ａ）実施例１と６：アタッチ処理（ＲＡＮ（Radio Access Network：無線アクセスネットワークでのリトライ）。

Ｂ）実施例２と７：アタッチ処理（コアネットワーク（ＣＮ）のインターワーク）。

Ｃ）実施例３と７：端末によるリトライ。

Ｄ）実施例４と８：コアネットワーク（ＣＮ）の選択。

Ｅ）実施例５と１０：位置管理エリア更新（ＲＡＵ／ＴＡＵ）。

＜影響範囲（実装のために修正が必要な対象）＞
Ａ）実施例１と６：ＲＡＮ（無線アクセスネットワーク）とＣＮ（コアネットワーク）。

Ｂ）実施例２と７：ＣＮ（ＲＡＮ）。

Ｃ）実施例３と８：端末とＣＮ。

Ｄ）実施例４と９：端末とＲＡＮ。

Ｅ）実施例５と１０：ＲＡＮとＣＮ。

＜実装のメリット等＞
Ａ）実施例１と６：端末への機能追加が不要。ＲＡＮへの機能追加必要。

Ｂ）実施例２と７：端末への機能追加不要。ＲＡＮへの機能追加も不要となる場合がある。実施例の中で信号量が最も少ない。

Ｃ）実施例３と８：ＲＡＮへの機能追加不要。端末、ＣＮへの機能追加は容易。ただし、アタッチリジェクトにより時間が掛かる。

Ｄ）実施例４と９：ＣＮへの機能追加不要。ＲＡＮでの機能追加は他の実施例よりも多い。ＲＡＮがＣＮ選択のためにＣＮリストを保持管理する必要がある。ＨＬＲ／ＨＳＳアクセス前なので、ＣＮ選択の判断に用いる情報が限定される。

Ｅ）実施例５と１０：端末に機能追加不要。契約変更等でアタッチ後のＣＮ再選択が可能。

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

ＭＴＣ（Machine Type Communication）デバイス（Ｍ２Ｍデバイス）を特定ＣＮノード（ＭＴＣデバイス向けに効率化したノード）に接続させる。

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

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

＜ＬＴＥにおける事例＞
特定のＵＥを、ＭＭＥとＳＧＷをコロケート（collocate）したノードに接続させる。特に制限されないが、例えば少量データトラヒックを、ＳＭＳ（Short Message Service）に載せ換えてＵＥに送信する場合、ＭＭＥとＳＧＷをコロケート（collocate）していると、ＳＭＳ変換処理の実装が容易化する。

また、端末種別（ＣＳＦＢ（CS Fallback）端末とＶｏＬＴＥ端末等）でＭＭＥを振り分ける。ＣＳＦＢ（CS Fallback）は、ＬＴＥ接続中に、ＣＳ（Circuit Switched）サービス発着信があると、３Ｇ（又は２Ｇ）に無線を切り替える機能。ＶｏＬＴＥ（Voice over LTE）は、ＬＴＥ上で音声（等ＣＳで提供していた）サービスを提供する機能である。なお、ＣＳＦＢ端末は、ＭＳＣとのインターワークが必要である。ＶｏＬＴＥ端末はＩＭＳ（IP Multimedia Subsystem）とのインターワークが必要である。ＣＳＦＢで、先にアタッチ（Attach）しているＭＳＣ（Mobile Switching Center）にコロケート（collocate）したＭＭＥを選択させる。

なお、上記の特許文献の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素（各請求項の各要素、各実施例の各要素、各図面の各要素等を含む）の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
上記実施形態及び実施例の開示の少なくとも１部は、特に制限されないが、以下のように付記される。
（付記１）
移動体通信システムのコアネットワークが、端末のモビリティを管理するノードとして、前記端末に対して提供するサービス機能が異なる複数のノードを備え、加入者情報と端末情報とに基づき、前記複数のノードの中から前記端末に接続するノードを、前記端末が利用するサービス特性又は端末種別に応じて選択し、前記端末を前記選択されたノードに接続する、通信システム。
（付記２）
前記端末からのアタッチ要求を、基地局装置を介して受信した第１のモビリティ管理エンティティ・ノードは、前記端末を、前記第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する第２のモビリティ管理エンティティ・ノードに接続するために、前記基地局装置に対して、モビリティ管理エンティティ再選択要求信号を送信し、
前記基地局装置は、前記第２のモビリティ管理エンティティ・ノードにアタッチ要求を再送することで、前記端末を前記第２のモビリティ管理エンティティ・ノードに接続する、付記１記載の通信システム。
（付記３）
前記端末からのアタッチ要求を、基地局装置を介して受信した第１のモビリティ管理エンティティ・ノードは、前記端末を、前記第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する第２のモビリティ管理エンティティ・ノードに接続するために、前記第２のモビリティ管理エンティティ・ノードに対して、モビリティ管理エンティティ変更要求信号を送信し、
前記第２のモビリティ管理エンティティ・ノードが、前記アタッチ要求に対するアタッチ処理手順を継続することで、前記端末を前記第２のモビリティ管理エンティティ・ノードへ接続する付記１記載の通信システム。
（付記４）
前記端末からのアタッチ要求を、基地局装置を介して受信した第１のモビリティ管理エンティティ・ノードは、
前記端末を、前記第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する第２のモビリティ管理エンティティ・ノードに接続するために、前記第２のモビリティ管理エンティティ・ノードの識別子を付与したアタッチリジェクトを前記端末に送信し、
前記端末は、アタッチ要求に、前記第２のモビリティ管理エンティティ・ノードの識別子を付与して再送信し、前記第２のモビリティ管理エンティティ・ノードに接続する、付記１記載の通信システム。
（付記５）
前記端末は、第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する第２のモビリティ管理エンティティ・ノードへの接続要求情報を付与したＲＲＣコネクション（RRC Connection）要求を、基地局装置に送信し、
前記ＲＲＣコネクションリクエストを受信した前記基地局装置は、ＲＲＣコネクションを確立した前記端末からのアタッチ要求をモビリティ管理エンティティに送信する際に、前記第２のモビリティ管理エンティティ・ノードを選択し、前記端末を前記第２のモビリティ管理エンティティ・ノードに接続する、付記１記載の通信システム。
（付記６）
前記端末とセッションを確立している第１のモビリティ管理エンティティ・ノードは、基地局装置と前記第１のモビリティ管理エンティティ・ノードとの間で確立されているコネクションの開放時に、次回のモビリティ管理エンティティの選択で前記第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する第２のモビリティ管理エンティティ・ノードを選択するように、前記基地局装置に対して指示し、
前記端末が位置管理エリア更新要求を前記基地局装置に送信した際に、前記基地局装置は、前記第２のモビリティ管理エンティティ・ノードを選択し、前記端末を前記第２のモビリティ管理エンティティ・ノードに接続する、付記１記載の通信システム。
（付記７）
前記端末からのアタッチ要求を、無線ネットワークコントローラを介して受信した第１のサービングＧＰＲＳ（General Packet Radio Service）サポートノードは、前記端末を、前記第１のサービングＧＰＲＳサポートノードが提供するサービスと異なるサービスを提供する第２のサービングＧＰＲＳサポートノードに接続するために、前記無線ネットワークコントローラに、サービングＧＰＲＳサポートノード再選択要求信号を送信し、
前記無線ネットワークコントローラは、前記第２のサービングＧＰＲＳサポートノードにアタッチ要求を再送することで、前記端末を第２のサービングＧＰＲＳサポートノードに接続する、付記１記載の通信システム。
（付記８）
前記端末からのアタッチ要求を、無線ネットワークコントローラを介して受信した第１のサービングＧＰＲＳ（General Packet Radio Service）サポートノード（ＳＧＳＮ）は、前記端末を、前記第１のサービングＧＰＲＳサポートノードが提供するサービスと異なるサービスを提供する第２のサービングＧＰＲＳサポートノードに接続するために、前記第２のサービングＧＰＲＳサポートノードに、サービングＧＰＲＳサポートノード変更要求信号を送信し、
前記第２のサービングＧＰＲＳサポートノードが、前記アタッチ要求に対するアタッチ処理を継続することで、前記端末を、前記第２のサービングＧＰＲＳサポートノードに接続する、付記１記載の通信システム。
（付記９）
前記端末からのアタッチ要求を、無線ネットワークコントローラを介して受信した第１のサービングＧＰＲＳ（General Packet Radio Service）サポートノード（ＳＧＳＮ）は、前記端末を、前記第１のサービングＧＰＲＳサポートノードが提供するサービスと異なるサービスを提供する第２のサービングＧＰＲＳサポートノードに接続するために、前記第２のサービングＧＰＲＳサポートノードの識別子を付与したアタッチリジェクトを前記端末に送信し、
前記端末は、アタッチ要求に、前記第２のサービングＧＰＲＳサポートノードの識別子を付与して再送信して前記端末を前記第２のサービングＧＰＲＳサポートノードに接続する、付記１記載の通信システム。
（付記１０）
前記端末は、第１のサービングＧＰＲＳ（General Packet Radio Service）サポートノードが提供するサービスと異なるサービスを提供する第２のサービングＧＰＲＳサポートノードへの接続要求情報を付与したＲＲＣ（Radio Resource Control）コネクション要求を、無線ネットワークコントローラに送信し、
前記ＲＲＣコネクションリクエストを受信した前記無線ネットワークコントローラは、ＲＲＣコネクションを確立した前記端末からのアタッチ要求をサービングＧＰＲＳサポートノードに送信する際に、前記第２のサービングＧＰＲＳサポートノードを選択し、前記端末を前記第２のサービングＧＰＲＳサポートノードに接続する、付記１記載の通信システム。
（付記１１）
前記端末とセッションを確立している第１のサービングＧＰＲＳ（General Packet Radio Service）サポートノードは、前記第１のサービングＧＰＲＳ（General Packet Radio Service）サポートノードと無線ネットワークコントローラ間で確立されているコネクションの開放時に、次回のサービングＧＰＲＳサポートノードの選択で、前記第１のサービングＧＰＲＳサポートノードが提供するサービスと異なるサービスを提供する第２のサービングＧＰＲＳサポートノードを選択するように、前記無線ネットワークコントローラに指示を出し、
前記端末が位置管理エリア更新要求を前記無線ネットワークコントローラに送信した際に、前記無線ネットワークコントローラは、前記第２のサービングＧＰＲＳサポートノードを選択し、前記端末を第２のサービングＧＰＲＳサポートノードに接続する、付記１記載の通信システム。
（付記１２）
移動体通信システムのコアネットワークに、端末のモビリティを管理するノードとして、前記端末に対して提供するサービス機能が異なる複数のノードを配し、
加入者情報と端末情報とに基づき、前記複数のノードの中から、前記端末に接続するノードを、前記端末が利用するサービス特性又は端末種別に応じて選択し、
前記端末を前記選択されたノードに接続する、通信方法。
（付記１３）
前記端末からのアタッチ要求を、基地局装置を介して受信した第１のモビリティ管理エンティティ・ノードは、前記端末を、前記第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する第２のモビリティ管理エンティティ・ノードに接続するために、前記基地局装置に対して、モビリティ管理エンティティ再選択要求信号を送信し、前記基地局装置は、前記第２のモビリティ管理エンティティ・ノードにアタッチ要求を再送することで、前記端末を前記第２のモビリティ管理エンティティ・ノードに接続する、付記１２記載の通信方法。
（付記１４）
前記端末からのアタッチ要求を、基地局装置を介して受信した第１のモビリティ管理エンティティ・ノードは、前記端末を、前記第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する第２のモビリティ管理エンティティ・ノードに接続するために、前記第２のモビリティ管理エンティティ・ノードに対して、モビリティ管理エンティティ変更要求信号を送信し、
前記第２のモビリティ管理エンティティ・ノードは、前記アタッチ要求に対する処理手順を継続することで、前記端末を前記第２のモビリティ管理エンティティ・ノードへ接続する付記１２記載の通信方法。
（付記１５）
前記端末からのアタッチ要求を、基地局装置を介して受信した第１のモビリティ管理エンティティ・ノードは、
前記端末を、前記第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する第２のモビリティ管理エンティティ・ノードに接続するために、前記第２のモビリティ管理エンティティ・ノードの識別子を付与したアタッチリジェクトを前記端末に送信し、
前記端末は、アタッチ要求に、前記第２のモビリティ管理エンティティ・ノードの識別子を付与して再送信し、前記第２のモビリティ管理エンティティ・ノードに接続する、付記１２記載の通信方法。
（付記１６）
前記端末は、第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する第２のモビリティ管理エンティティ・ノードへの接続要求情報を付与したＲＲＣコネクションリクエスト（RRC(Radio Resource Control) Connection Request）を基地局装置に送信し、
前記ＲＲＣコネクションリクエストを受信した前記基地局装置は、ＲＲＣコネクションを確立した前記端末からのアタッチ要求をモビリティ管理エンティティに送信する際に、前記第２のモビリティ管理エンティティ・ノードを選択し、前記端末を前記第２のモビリティ管理エンティティ・ノードに接続する、付記１２記載の通信方法。
（付記１７）
前記端末とセッションを確立している第１のモビリティ管理エンティティ・ノードは、基地局装置と前記第１のモビリティ管理エンティティ・ノードとの間で確立されているコネクションの開放時に、次回のモビリティ管理エンティティの選択で前記第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する第２のモビリティ管理エンティティ・ノードを選択するように、前記基地局装置に対して指示し、
前記端末が位置管理エリア更新要求を前記基地局装置に送信した際に、前記基地局装置は、前記第２のモビリティ管理エンティティ・ノードを選択し、前記端末を前記第２のモビリティ管理エンティティ・ノードに接続する、付記１２記載の通信方法。
（付記１８）
前記端末からのアタッチ要求を、無線ネットワークコントローラを介して受信した第１のサービングＧＰＲＳ（General Packet Radio Service）サポートノード（ＳＧＳＮ）は、前記端末を、前記第１のサービングＧＰＲＳサポートノードが提供するサービスと異なるサービスを提供する第２のサービングＧＰＲＳサポートノードに接続するために、無線ネットワークコントローラに、サービングＧＰＲＳサポートノード再選択要求信号を送信し、
前記無線ネットワークコントローラは、前記第２のサービングＧＰＲＳサポートノードにアタッチ要求を再送し、前記端末を第２のサービングＧＰＲＳサポートノードに接続する、付記１２記載の通信方法。
（付記１９）
前記端末からのアタッチ要求を、無線ネットワークコントローラを介して受信した第１のサービングＧＰＲＳ（General Packet Radio Service）サポートノード（ＳＧＳＮ）は、前記端末を、前記第１のサービングＧＰＲＳサポートノードが提供するサービスと異なるサービスを提供する第２のサービングＧＰＲＳサポートノードに接続するために、前記第２のサービングＧＰＲＳサポートノードに、サービングＧＰＲＳサポートノード変更要求信号を送信し、
前記第２のサービングＧＰＲＳサポートノードはアタッチ処理を継続することで、前記端末を、前記第２のサービングＧＰＲＳサポートノードに接続する、付記１２記載の通信方法。
（付記２０）
前記端末からのアタッチ要求を、無線ネットワークコントローラを介して受信した第１のサービングＧＰＲＳ（General Packet Radio Service）サポートノード（ＳＧＳＮ）は、前記端末を、前記第１のサービングＧＰＲＳサポートノードが提供するサービスと異なるサービスを提供する第２のサービングＧＰＲＳサポートノードに接続するために、前記第２のサービングＧＰＲＳサポートノードの識別子を付与したアタッチリジェクトを前記端末に送信し、
前記端末は、アタッチ要求に、前記第２のサービングＧＰＲＳサポートノードの識別子を付与して再送信し、前記端末を前記第２のサービングＧＰＲＳサポートノードに接続する、付記１２記載の通信方法。
（付記２１）
前記端末は、第１のサービングＧＰＲＳサポートノードが提供するサービスと異なるサービスを提供する第２のサービングＧＰＲＳサポートノードへの接続要求情報を付与したＲＲＣコネクション要求（RRC(Radio Resource Control) Connection Request）を無線ネットワークコントローラに送信し、
前記ＲＲＣコネクションリクエストを受信した前記無線ネットワークコントローラは、ＲＲＣコネクションを確立した前記端末からのアタッチ要求をサービングＧＰＲＳサポートノード（ＳＧＳＮ）に送信する際に、前記第２のサービングＧＰＲＳサポートノードを選択し、前記端末を、前記第２のサービングＧＰＲＳサポートノードに接続する、付記１２記載の通信方法。
（付記２２）
前記端末とセッションを確立している第１のサービングＧＰＲＳ（General Packet Radio Service）サポートノードは、前記第１のサービングＧＰＲＳ（General Packet Radio Service）サポートノードと無線ネットワークコントローラとの間で確立されているコネクションの開放時に、次回のサービングＧＰＲＳサポートノードの選択で、前記第１のサービングＧＰＲＳサポートノードが提供するサービスと異なるサービスを提供する第２のサービングＧＰＲＳサポートノードを選択するように前記無線ネットワークコントローラに指示を出し、
前記端末がルーチングエリア更新要求を前記無線ネットワークコントローラに送信した際に、前記無線ネットワークコントローラは、前記第２のサービングＧＰＲＳサポートノードを選択し、前記端末を第２のサービングＧＰＲＳサポートノードに接続する、付記１２記載の通信方法。
（付記２３）
端末のモビリティを管理する一のモビリティ管理ノード装置に対して、
加入者情報と端末情報とに基づき、前記端末が利用するサービス特性又は端末種別に対応した、別のモビリティ管理ノード装置を選択し、
前記端末と前記選択された別のモビリティ管理ノード装置を接続するように制御する、ノード装置。
（付記２４）
付記２３のノード装置が、移動体通信システムの無線アクセスネットワーク又はコアネットワーク上のノード装置である、ノード装置。
（付記２５）
端末のモビリティを管理するコアネットワークノードとして、予め定められた特定端末以外の一般端末向けの一般ＭＭＥ(Mobility Management Entity)又は一般ＳＧＳＮ(Serving GPRS Support Node)に加え、
予め定められた所定のサービスを前記特定端末に提供する機能を具備するか、又は、予め定められた機種の前記特定端末への対応に特化した特定ＭＭＥ（Customized MME）又は特定ＳＧＳＮ(Customized SGSN)を備え、
前記一般ＭＭＥ又は一般ＳＧＳＮ、又は、前記特定端末は、前記特定端末の接続するノードとして、前記特定ＭＭＥ又は前記特定ＳＧＳＮを選択する、通信システム。

１ ＵＥ
１１ ｅＮｏｄｅＢ
２１ 一般ＭＭＥ
２２ Customized MME
３１ ＨＳＳ
４１ Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ ＧＷ）
５１ Ｐ−ＧＷ（ＰＤＮ ＧＷ）
６１ サービスネットワーク
１０１ ＵＥ（ＭＳ）
１１１ ＮｏｄｅＢ
１２１ 一般ＳＧＳＮ
１２２ Customized SGSN
１３１ ＨＬＲ
１４１ ＧＧＳＮ
１６１ サービスネットワーク
１７１ ＲＮＣ

Claims (6)

1. ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）に関する機能を有する端末（ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）又はＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ））と、
   基地局と、
   特定の（スペシフィックな）ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）又はＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔ Ｎｏｄｅ）と、
   を含み、
   前記機能を有する端末が、
   ＲＲＣコネクションリクエスト（ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｃｅ Ｃｏｎｔｒｏｌ） ｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔ）にて、前記ＭＴＣに対応する前記端末に関する予め定められた所定の情報を、前記基地局に提供する手段を含み、
   前記基地局が、
   前記機能を有する端末によって提供された前記情報を用いて、前記機能を有する端末を、前記特定の（スペシフィックな）ＭＭＥ又はＳＧＳＮへと導くか選択する手段を含む、
   ことを特徴とする移動通信システム。
2. ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）に関する機能を有する端末（ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）又はＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ））と、
   特定の（スペシフィックな）ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）又はＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔ Ｎｏｄｅ）と、を少なくとも含む移動通信システムに用いられる基地局であって、
   前記機能を有する端末から、ＲＲＣコネクションリクエスト（ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｃｅ Ｃｏｎｔｒｏｌ） ｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔ）にて、前記ＭＴＣに対応する前記端末に関する予め定められた所定の情報を受信する手段と、
   前記機能を有する端末によって提供された前記情報を用いて前記機能を有する端末を、前記特定の（スペシフィックな）ＭＭＥ又はＳＧＳＮへと導くか選択する手段と、
   を含む、ことを特徴とする基地局。
3. 基地局と、特定の（スペシフィックな）ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）又はＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔ Ｎｏｄｅ）とを少なくとも含む移動通信システムに用いられ、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）に関する機能を有する端末（ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）又はＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ））であって、
   ＲＲＣコネクションリクエスト（ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｃｅ Ｃｏｎｔｒｏｌ） ｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔ）にて、前記ＭＴＣに対応する前記端末に関する予め定められた所定の情報を、前記基地局に提供する手段と、
   前記基地局に提供された前記情報を用いて、前記基地局に、前記機能を有する端末を、前記特定の（スペシフィックな）ＭＭＥ又はＳＧＳＮへと導くようにするか選択させる手段と、
   を含む、ことを特徴とする端末。
4. ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）に関する機能を有する端末（ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）又はＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ））と、基地局と、特定の（スペシフィックな）ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）又はＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔ Ｎｏｄｅ）とを少なくとも含む移動通信システムの通信方法であって、
   前記機能を有する端末が、ＲＲＣコネクションリクエスト（ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｃｅ Ｃｏｎｔｒｏｌ） ｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔ）にて、前記ＭＴＣに対応する前記端末に関する予め定められた所定の情報を、前記基地局に提供し、
   前記基地局は、前記機能を有する端末によって提供された前記情報を用いて前記機能を有する端末を、前記特定の（スペシフィックな）ＭＭＥ又はＳＧＳＮへと導くか選択する、ことを特徴とする、移動通信システムの通信方法。
5. ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）に関する機能を有する端末（ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）又はＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ））と、特定の（スペシフィックな）ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）又はＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔ Ｎｏｄｅ）とを少なくとも含む移動通信システムに用いられる基地局の通信方法であって、
   前記機能を有する端末から、ＲＲＣコネクションリクエスト（ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｃｅ Ｃｏｎｔｒｏｌ） ｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔ）にて、前記ＭＴＣに対応する前記端末に関する予め定められた所定の情報を受信し、
   前記機能を有する端末によって提供された前記情報を用いて前記機能を有する端末を、前記特定の（スペシフィックな）ＭＭＥ又はＳＧＳＮへと導くか選択する、
   ことを特徴とする、基地局の通信方法。
6. 基地局と、特定の（スペシフィックな）ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）又はＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔ Ｎｏｄｅ）とを少なくとも含む移動通信システムに用いられ、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）に関する機能を有する端末（ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）又はＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ））の通信方法であって、
   ＲＲＣコネクションリクエスト（ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｃｅ Ｃｏｎｔｒｏｌ） ｃｏｎｎｅｃｔｉｏｎ ｒｅｑｕｅｓｔ）にて、前記ＭＴＣに対応する前記端末に関する予め定められた所定の情報を、前記基地局に提供し、
   前記基地局に提供された前情報を用いて、前記基地局に、前記機能を有する端末を、前記特定の（スペシフィックな）ＭＭＥ又はＳＧＳＮへと導くようにするか選択させる、
   ことを特徴とする、端末の通信方法。