JP6460102B2 - コントロールノード及びネットワークノード並びにこれらにより行われる方法 - Google Patents

コントロールノード及びネットワークノード並びにこれらにより行われる方法 Download PDF

Info

Publication number
JP6460102B2
JP6460102B2 JP2016528981A JP2016528981A JP6460102B2 JP 6460102 B2 JP6460102 B2 JP 6460102B2 JP 2016528981 A JP2016528981 A JP 2016528981A JP 2016528981 A JP2016528981 A JP 2016528981A JP 6460102 B2 JP6460102 B2 JP 6460102B2
Authority
JP
Japan
Prior art keywords
relocation
mme
message
procedure
target
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016528981A
Other languages
English (en)
Other versions
JPWO2015198508A1 (ja
Inventor
孝法 岩井
孝法 岩井
創 前佛
創 前佛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Publication of JPWO2015198508A1 publication Critical patent/JPWO2015198508A1/ja
Application granted granted Critical
Publication of JP6460102B2 publication Critical patent/JP6460102B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/12—Reselecting a serving backbone network switching or routing node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/14—Backbone network devices

Description

本明細書の開示は、移動通信ネットワークに関し、特にコアネットワークにおける移動端末のモビリティ管理及びベアラ管理に関する。
非特許文献１は、Third Generation Partnership Project（3GPP）のパケット交換ドメイン、つまりEvolved Packet System（EPS）の機能アーキテクチャを規定している。具体的には、非特許文献１は、Attach手順、Tracking Area Update（TAU）手順、Service Request手順、S1 Release手順、Globally Unique Temporary Identity (GUTI) Reallocation手順、Detach手順、Dedicated bearer activation手順、Bearer modification手順、X2-based handover手順、及びS1-based handover手順を含む、EPSにおける移動端末のモビリティ管理、セッション管理、及びハンドオーバのための様々な手順を規定している。
本件の発明者等は、外部のコントロールノード（e.g., Software-Defined Network（SDN）コントローラ、Network Function Virtualization（NFV）コントローラ、Operations Support System（OSS）、又はElement Management System（EMS））からの指示に従ってMobility Management Entity（MME）の処理を他のMMEにリロケーションすることについて検討を行った。なお、MMEは、コアネットワークすなわちEvolved Packet Core（EPC）に配置され、コアネットワークにアタッチ済み（i.e., EMM-REGISTERED state）である複数の移動端末（User Equipments（UEs））のモビリティ管理及びベアラ管理を行う。モビリティ管理は、UEの現在位置を追跡する（keep track）するために使用され、UEに関するモビリティ管理コンテキスト（MM context）を維持することを含む。ベアラ管理は、UEがEvolved Universal Terrestrial Radio Access Network（E-UTRAN）及びEPCを経由して外部ネットワーク（Packet Data Network（PDN））と通信するためのEPSベアラの確立を制御し、UEに関するEPS bearer contextを維持することを含む。
本件発明者等は、MMEにおけるモビリティ管理及びベアラ管理を外部のコントロールノードの指示に基づいてリロケーションすることは、コアネットワークの仮想化技術の利用が広がるのにともなってその需要が高まると予想している。仮想化されたコアネットワーク（Virtualized EPC等と呼ばれる）は、サーバ仮想化技術及びネットワーク仮想化技術を利用し、コアネットワークのコントロールプレーン若しくはデータプレーン又はこれら両方を抽象化する。すなわち、仮想化されたコアネットワークでは、コアネットワークノード（例えば、MME、Serving Gateway（S-GW）/PDN Gateway（P-GW）のコントロールプレーン、及びS/P-GWのデータプレーン）は、サーバー・プールに設定された仮想マシン、又は物理的なスイッチ群に設定された仮想ルータとして実現される。
現在の3GPP仕様書は、UEがトラッキングエリア間又はeNodeB間を跨って移動したことに起因して、この移動したUEのモビリティ管理及びベアラ管理をOld MME（又はSource MME）からNew MME（又はTarget MME）にリロケートする手順を規定している。具体的には、Old MMEによって管轄されているトラッキングエリアからNew MMEによって管轄されているトラッキングエリアにアイドル状態（i.e., EPS Connection Management (ECM)-IDLE state）のUEが移動したことに伴って、TAU手順において当該UEのモビリティ管理及びベアラ管理がOld MMEからNew MMEにリロケートされる。さらに、Source MMEによって制御されるSource eNodeBからTarget MMEによって制御されるTarget eNodeBにコネクテッド状態（i.e., ECM-CONNECTED state）のUEが移動したことに伴って、S1-based Handover手順において当該UEのモビリティ管理及びベアラ管理がSource MMEからTarget MMEにリロケートされる。
しかしながら、現在の3GPP仕様書は、EPCが主導して又はEPCに結合されたコントロールノード（e.g., SDNコントローラ、NFVコントローラ、OSS、又はEMS）が主導して、UEの移動に関わらずにUEのモビリティ管理及びベアラ管理をMME間でリロケートすることについて規定していない。したがって、本明細書に開示される実施形態が達成しようとする目的の１つは、コアネットワークにアタッチ済みである複数の移動端末（e.g., UEs）のモビリティ管理及びベアラ管理を、これら移動端末の移動に関わらず、ネットワークノード（e.g., MME）間でリロケートできるようにすることに寄与する装置、方法、及びプログラムを提供することである。なお、この目的は、本明細書に開示される実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。
第１の態様では、コアネットワークに結合して使用されるコントロールノードにより行われる方法は、前記コアネットワーク内に配置されて前記コアネットワークにアタッチ済みである複数の移動端末のモビリティ管理及びベアラ管理を行う第１のネットワークノードに関するリロケーション指示メッセージを送信することを含む。前記リロケーション指示メッセージは、前記第１のネットワークノードから少なくとも１つの第２のネットワークノードへの前記複数の移動端末のうち少なくとも１つのための前記モビリティ管理及び前記ベアラ管理のリロケーションを引き起こす。
第２の態様では、コアネットワーク内に配置されたネットワークノードにより行われる方法は、（ａ）前記コアネットワークにアタッチ済みである複数の移動端末のモビリティ管理及びベアラ管理を行うこと、（ｂ）前記コアネットワークに結合されたコントロールノードからリロケーション指示メッセージを受信すること、及び前記リロケーション指示メッセージに従って、前記ネットワークノードから前記コアネットワーク内の少なくとも１つの他のノードへの前記複数の移動端末のうち少なくとも１つのための前記モビリティ管理及び前記ベアラ管理のリロケーションを行うことを含む。
第３の態様では、コアネットワークに結合して使用されるコントロールノードは、メモリと、前記メモリに結合され、上述の第１の態様に係る方法を実行するよう構成されたプロセッサとを含む。
第４の態様では、コアネットワーク内に配置されたネットワークノードは、メモリと、前記メモリに結合され、上述の第２の態様に係る方法を実行するよう構成されたプロセッサとを含む。
第５の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第１の態様に係る方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。
第６の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第２の態様に係る方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。
上述の態様は、コアネットワークにアタッチ済みである複数の移動端末（e.g., UEs）のモビリティ管理及びベアラ管理を、これら移動端末の移動に関わらず、ネットワークノード（e.g., MME）間でリロケートできるようにすることに寄与する装置、方法、及びプログラムを提供することができる。
本発明の実施形態に係る移動通信ネットワークの構成例を示す図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 本発明の実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。 Paging messageの一例を示す図である。 Paging messageの一例を示す図である。 RRC Connection Release messageの一例を示す図である。 本発明の実施形態に係るMMEの構成例を示すブロック図である。 本発明の実施形態に係るUEの構成例を示すブロック図である。 本発明の実施形態に係るeNodeBの構成例を示すブロック図である。
以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。
＜第１の実施形態＞
図１は、本実施形態に係る移動通信ネットワークの構成例を示している。当該移動通信ネットワークは通信サービス、例えば音声通信若しくはパケットデータ通信又はこれら両方を提供する。本実施形態では、当該移動通信ネットワークがEPS（つまりLong Term Evolution（LTE）システム又はLTE-Advancedシステム）であるとして説明する。
図１に示されたネットワークは、E-UTRAN１１０、及びEPC１２０を含む。E-UTRAN１１０は、移動端末（UE）１１１及びeNodeB１１２を含む。EPC１２０は、ソースMME１２１Ｓ、ターゲットMME１２１Ｔ、Home Subscriber Server（HSS）１２２、S-GW１２３、及びP-GW１２４を含む。
ソースMME１２１Ｓ、ターゲットMME１２１Ｔ及びHSS１２２は、コントロールプレーンのノード又はエンティティである。ソースMME１２１Ｓ及びターゲットMME１２１Ｔは、UE１１１を含む複数のUE（UEs）のモビリティ管理及びベアラ管理を行うことができる。既に説明したように、モビリティ管理は、UEの現在位置を追跡する（keep track）するために使用され、UEに関するモビリティ管理コンテキスト（MM context）を維持することを含む。ベアラ管理は、EPSベアラの確立を制御し、UEに関するEPS bearer contextを維持することを含む。HSS１２２は、UE１１１を含むUEsの加入者情報を管理する。
S-GW１２３及びP-GW１２４は、ユーザープレーンのパケット転送ノードであり、ユーザーデータ（つまり、Internet Protocol（IP）パケット）を転送する。S-GW１２３は、E-UTRAN１１０とのゲートウェイであり、S1-Uインタフェースを介してeNodeB１１２に接続される。P-GW１２４は、Packet Data Network（PDN）１３０とのゲートウェイであり、SGiインタフェースを介してPDN１３０に接続される。PDN１３０は、インターネットのような外部ネットワークであってもよいし、EPC１２０を管理するオペレータによって提供されるIPサービス（e.g., IP Multimedia Subsystem (IMS)サービス）のためのネットワークであってもよい。
さらに、ソースMME１２１Ｓは、EPC１２０の外部に配置されたコントロールノード１４２と制御インタフェース１４１を介して接続されている。コントロールノード１４２は、例えば、SDNコントローラ、NFVコントローラ、OSS、若しくはEMS、又はこれらの任意の組み合わせである。ソースMME１２１Ｓは、コントロールノード１４２からの指示に従って、EPC１２０にアタッチ済みのUEs（つまり、EMM-REGISTERED stateのUEs）のモビリティ管理及びベアラ管理をターゲットMME１２１Ｔにリロケートするよう構成されている。言い換えると、ソースMME１２１Ｓは、UE１１１がセル間又はトラキングエリア間を移動したか否か関わらず、UE１１１のモビリティ管理及びベアラ管理をターゲットMME１２１Ｔにリロケートすることができる。モビリティ管理及びベアラ管理のリロケーションは、MM context及びEPS Bearer contextの維持をソースMME１２１Ｓに代わってターゲットMME１２１Ｔが行うことを意味する。
図２は、本実施形態に係るモビリティ管理コンテキスト及びベアラコンテキストのリロケーション手順の具体例を示すシーケンス図である。ステップＳ１１では、ソースMME１２１Ｓは、EPC１２０にアタッチ済みのUEs（つまり、EMM-REGISTERED stateのUEs）のモビリティ管理及びベアラ管理を行っている。
ステップＳ１２では、コントロールノード１４２は、コンテキスト・リロケーション指示（Context Relocation Command）メッセージをソースMME１２１Ｓに送信する。リロケーション指示メッセージは、ソースMME１２１Ｓから少なくとも１つのターゲットMME１２１Ｔへの、UEsに関するモビリティ管理及びベアラ管理のリロケーションを引き起こす。リロケーション指示メッセージは、少なくとも１つのターゲットMME１２１Ｔの識別子を示すリロケーションポリシを含む。ターゲットMME１２１Ｔの識別子は、例えば、Globally Unique MME Identity（GUMMEI）、MME Identifier（MMEI）、又はMME Code（MMEC）であってもよい。GUMMEIは、MMEをグローバルに一意に特定するために使用され、Public Land Mobile Network Identifier（PLMN ID）及びMMEIから構成される。MMEIは、１つのPLMN内でMMEを一意に特定するために使用され、MME Group Identifier（MMEGI）及びMMECから構成される。MMECは、１つのMMEグループ内でMMEを一意に特定するために使用される８ビットコードである。
リロケーションポリシは、ソースMME１２１Ｓから少なくとも１つのターゲットMME１２１Ｔにリロケートされるべきモビリティ管理及びベアラ管理の処理量を示してもよい。モビリティ管理及びベアラ管理の処理量は、UE数、プロセッサリソースの使用量、メモリリソースの使用量、シグナリングの発生数、若しくはトラフィック量、又はこれらの任意の組み合わせとして指定されてもよい。
リロケーションポリシは、リロケーションに対する時間的な制約を示してもよい。具体的には、リロケーションポリシは、リロケーションの開始時間、リロケーションの終了時間、又はリロケーションの実行が許可される期間を示してもよい。
リロケーションポリシは、ソースMME１２１ＳからターゲットMME１２１Ｔへのリロケーションを行うために複数のシグナリング手順が利用できる場合に、これら複数のシグナリング手順のうちいずれを用いるべきかを示してもよい。複数のシグナリング手順は、例えば、シグナリング量を抑えた手順、シグナリング量は大きいが短時間でリロケーションを完了できる手順、アイドル状態（ECM-IDLE state）のUEだけをリロケーション対象とする手順、コネクテッド状態（ECM-CONNECTED state）のUEをリロケーションの対象とする手順などを含んでもよい。モビリティ管理及びベアラ管理をターゲットMME１２１Tにリロケートするためのシグナリング手順の具体例は後述する。
例えば、コントロールノード１４２は、ソースMME１２１Ｓの負荷を取得し、ソースMME１２１Ｓの負荷に基づいてリロケーションの必要性を判定し、ソースMME１２１Ｓの負荷に基づいてリロケーションポリシを決定してもよい。
図２に戻り説明を続ける。ステップＳ１３では、ソースMME１２１Ｓは、リロケーション指示メッセージに示されたリロケーションポリシに従って、モビリティ管理及びベアラ管理をターゲットMME１２１Tにリロケートするためのシグナリング手順を開始する。当該シグナリング手順の具体例は後述する。
ステップＳ１４では、ソースMME１２１Ｓは、リロケーションを完了したことを示すコンテキスト・リロケーション完了（Context Relocation Complete）メッセージをコントロールノード１４２に送信する。
ステップＳ１５では、ターゲットMME１２１Ｔは、ソースMME１２１Ｓから引き継いだモビリティ管理及びベアラ管理を実行し、UEsのMM context及びEPS bearer contextを維持する。
なお、上述の説明では、コントロールノード１４２からの指示に基づくモビリティ管理及びベアラ管理のリロケーションが複数のUEを対象として行われる例を説明した。しかしながら、コントロールノード１４２からの指示に基づく当該リロケーションは、１つのUEを対象として行われてもよい。
以上の説明から理解されるように、本実施形態では、コントロールノード１４２は、リロケーション指示メッセージをソースMME１２１Ｓに送信するよう構成されている。さらに、ソースMME１２１Ｓは、コントロールノード１４２から受信したリロケーション指示メッセージに従って、UE１１１のモビリティ管理及びベアラ管理をターゲットMME１２１Ｔにリロケートするよう構成されている。したがって、本実施形態によれば、ターゲットMME１２１Ｔは、UE１１１がセル間又はトラキングエリア間を移動したか否か関わらず、UE１１１のモビリティ管理及びベアラ管理をターゲットMME１２１Ｔにリロケートすることができる。
なお、コントロールノード１４２は、他のコントロールノード（仲介ノード）を介して、ソースMME１２１Ｓ又はターゲットMME１２１Ｔにリロケーションを指示してもよい。言い換えると、コントロールノード１４２はソースMME１２１Ｓに関するリロケーション指示メッセージを他のコントロールノード（仲介ノード）に送信し、他のコントロールノード（仲介ノード）はリロケーション指示メッセージに基づいてソースMME１２１Ｓ又はターゲットMME１２１Ｔにリロケーションを指示してもよい。例えば、他のコントロールノード（仲介ノード）は、コントロールノード１４２から受信したリロケーション指示メッセージに従って、ソースMME１２１Ｓ及びターゲットMME１２１Ｔのための設定情報を生成してもよく、ソースMME１２１Ｓ及びターゲットMME１２１Ｔが解読可能な制御メッセージを生成してもよい。この場合、例えば、コントロールノード１４２は、OSS、SDNコントローラ、又はNFVコントローラであってもよく、他のコントロールノード（仲介ノード）は、EMSであってもよい。
さらに、ソースMME１２１ＳからターゲットMME１２１Ｔへのモビリティ管理及びベアラ管理のリロケーション手順は、S-GWのリロケーション（又は変更（change））を伴ってもよい。S-GWのリロケーションは、ソースMME１２１Ｓによって管理されていたUE１１１のEPSベアラの経路（つまり、S1ベアラ及びS5/S8ベアラの終端点）をS-GW１２３から他のS-GWに変更することを意味する。
一例において、ターゲットMME１２１Ｔは、自身が有するS-GWセレクション機能に基づいて自発的にS-GWを選択してもよい。これに代えて、リロケーション先のS-GW（ターゲットS-GWと呼ぶ）は、コントロールノード１４２によって指定されてもよい。すなわち、コントロールノード１４２は、ソースMME１２１Ｓに送信するコンテキスト・リロケーション指示メッセージの中にターゲットS-GWの指定を含めてもよい。この場合、ソースMME１２１Ｓは、リロケーション手順（図２のステップＳ１３）において、ターゲットS-GWのアドレスをターゲットMME１２１Ｔに知らせてもよい。
続いて以下では、モビリティ管理及びベアラ管理をターゲットMME１２１Ｔにリロケートするためのシグナリング手順の具体例の１つを説明する。図３Ａ及び３Ｂのシーケンス図は、リロケーションのためのシグナリング手順の一例を示している。図３Ａ及び３Ｂの手順は、図２のステップＳ１３において行われることができる。すなわち、ソースMME１２１Ｓは、コントロールノード１４２からのコンテキスト・リロケーション指示メッセージの受信に応答して、図３Ａ及び３Ｂに示されたシグナリング手順を開始してもよい。図３Ａ及び３Ｂに示されたシグナリング手順は、UE１１１がコネクテッド状態（ECM-CONNECTED state）であるときに開始される。
ステップＳ１０１では、ソースMME１２１Ｓは、UE１１１のMM context及びEPS bearer contextをターゲットMME１２１Ｔに送信する。この送信には、MME間のS10インタフェースにおいて送信されるGPRS Tunnelling Protocol for the Control Plane（GTP-C）メッセージを利用することができる。例えば、図３Ａに示されているように、Forward Relocation Requestメッセージ又はそれを改変したものが使用されてもよい。Forward Relocation Requestメッセージは、S1-based handover手順においてソースMMEからターゲットMMEに送信されるメッセージである。ステップＳ１０１のForward Relocation Requestメッセージは、S1-based handover では無くContext Relocationのために送信されるメッセージであることを示す情報要素を含んでもよい。
ステップＳ１０２では、ターゲットMME１２１Ｔは、ソースMME１２１Ｓから受信したUE１１１のMM context及びEPS bearer contextを自身のメモリ又はストレージ（不図示）に格納する。さらに、ターゲットMME１２１Ｔは、UE１１１のMM context及びEPS bearer contextの受信に応答して、S-GW１２３において保持されているUE１１１のEPS bearer contextの更新をS-GW１２３に要求する。この要求は、UE１１１のEPS bearerを管理する新たなMME、つまりターゲットMME１２１ＴのIPアドレス及びMME TEIDを示す。この要求の送信には、MME１２１ＴとS-GW１２３の間のS11インタフェースにおいて送信されるGTP-Cメッセージを使用することができる。例えば、図３Ａに示されているように、Modify Bearer Requestメッセージ又はそれを改変したものが使用されてもよい。
ステップＳ１０３では、S-GW１２３は、UE１１１のEPS bearer contextに関して保持されているMMEのIPアドレス及びMME TEIDを更新し、応答メッセージ（例えば、Modify Bearer Responseメッセージ）をターゲットMME１２１Ｔに送信する。
ステップＳ１０４では、ターゲットMME１２１Ｔは、UE１１１のモビリティ管理及びベアラ管理の引き継ぎを受け入れたことをソースMME１２１Ｓに通知する。この通知の送信には、MME間のS10インタフェースにおいて送信されるGTP-Cメッセージを使用することができる。例えば、図３Ａに示されているように、Forward Relocation Responseメッセージ又はそれを改変したものが使用されてもよい。あるいは、Forward Relocation Complete Notificationメッセージ又はそれを改変したものが使用されてもよい。
ステップＳ１０４の通知メッセージは、ターゲットMME１２１ＴによってUE１１１に割り当てられた一時識別子、すなわちMME Mobile Subscriber Identity（M-TMSI）、SAE Temporary Mobile Subscriber Identity（S-TMSI）、又はGlobally Unique Temporary UE Identity（GUTI）を含む。M-TMSIは、１つのMME（ターゲットMME１２１Ｔ）内においてユニークな一時識別子である。S-TMSIは、１つのMME グループ内においてユニークな一時識別子であり、MMEC及びM-TMSIから構成される。GUTIは、グローバルにユニークな一時識別子であり、GUMMEI及びM-TMSIから構成される。
ステップＳ１０５では、ソースMME１２１Ｓは、ステップＳ１０４のメッセージに対する承認（Acknowledge）メッセージをターゲットMME１２１Ｔに送信する。当該承認メッセージの送信には、MME間のS10インタフェースにおいて送信されるGTP-Cメッセージを使用することができる。当該承認メッセージは、Forward Relocation Complete Acknowledgeメッセージ又はそれを改変したものであってもよい。
ステップＳ１０６〜Ｓ１０９は、MMEの変更をHSS１２２に知らせるために行われる。ステップＳ１０６〜Ｓ１０９は、通常のTAU手順においてMMEの変更をHSS知らせるための手順と同様であってもよい。また、MMEの変更は、図３Ａ及び３Ｂに示されたリロケーション手順の終了後に行われる通常のTAU手順においてHSS１２２に知らせることもできる。したがって、ステップＳ１０６〜Ｓ１０９は、省略されてもよい。
ステップＳ１０６では、ターゲットMME１２１Ｔは、UE１１１に関するMMEの変更をHSS１２２に知らせるためのメッセージを送信する。当該メッセージの送信には、MME１２１ＴとHSS１２２の間のS6aインタフェースにおいて送信されるDiameterメッセージを使用することができる。図３Ａに示されているように、通常のTAU手順と同様に、Update Location Requestメッセージが使用されてもよい。
ステップＳ１０７では、HSS１２２は、UE１１１に関するMM context及びEPS bearer contextが削除可能であることを知らせるために、Cancel LocationメッセージをソースMME１２１Ｓに送信する。Cancel Locationメッセージは、UE１１１のInternational Mobile Subscriber Identity（IMSI）を示す。ステップＳ１０８では、ソースMME１２１Ｓは、UE１１１に関するMM context及びEPS bearer contextを必要に応じて削除する。そして、ソースMME１２１Ｓは、Cancel Location AckメッセージをHSS１２２に送信する。Cancel Location Ackメッセージは、UE１１１のInternational Mobile Subscriber Identity（IMSI）を示す。ステップＳ１０９では、HSS１２２は、Update Location AckメッセージをターゲットMME１２１Ｔに送信することにより、Update Location Requestを承認する。
ステップＳ１１０では、eNodeB１１２とターゲットMME１２１Ｔの間でUE１１１に関するシグナリングを開始するために、ターゲットMME１２１Ｔは、ターゲットMME１２１Ｔによって割り当てられたMME UE S1AP IDをeNodeB１１２に通知する。この通知は、ターゲットMME１２１ＴとeNodeB１１２の間のS1-MMEインタフェースにおいて送信されるS1APメッセージを使用して送信されてもよい。ターゲットMME１２１Ｔは、例えば、改変されたHandover Requestメッセージ、改良されたE-RAB Modify Requestメッセージ、又は改良されたUE Context Modification Requestメッセージを使用してもよい。
ステップＳ１１１では、eNodeB１１２は、ステップＳ１１０のメッセージに対する承認（Acknowledge）メッセージをターゲットMME１２１Ｔに送信する。当該承認メッセージの送信には、S1-MMEインタフェースにおいて送信されるS1APメッセージを使用することができる。当該承認メッセージは、Handover Request Ackメッセージ、E-RAB Modify Responseメッセージ、若しくはUE Context Modification Responseメッセージ、又はそれらを改変したものであってもよい。
ステップＳ１１２では、ソースMME１２１Ｓは、リロケーション後の新たなMME（つまり、ターゲットMME１２１Ｔ）のIDをUE１１１に知らせる。さらに、ソースMME１２１Ｓは、ターゲットMME１２１ＴによってUE１１１に割り当てられた一時識別子をUE１１１に知らせる。具体的には、ソースMME１２１Ｓは、ターゲットMME１２１ＴのGUMMEIとターゲットMME１２１ＴによってUE１１１に割り当てられたM-TMSIとから構成されるGUTIをUE１１１に知らせればよい。
ステップＳ１１２では、ソースMME１２１Ｓは、以下のように動作してもよい。まず、ターゲットMME１２１ＴがステップＳ１１１のメッセージを受信した後に例えばHandover Commandメッセージ（又は他のMME間のメッセージ）を利用してリロケーションが完了したことをソースMME１２１Ｓに通知し、次に、ソースMME１２１Ｓが当該通知を受けた後にステップＳ１１２のメッセージを送信してもよい。
ステップＳ１１２では、Non-Access Stratum（NAS）メッセージが使用されてもよい。NASメッセージは、E-UTRAN１１０で終端されること無く、UE１１１とMME１２１Ｓの間で透過的に送受信される。例えば、図３Ｂに示されているように、GUTI Reallocation Commandメッセージが使用されてもよい。あるいは、新規のNASメッセージが定義されて使用されてもよい。
ステップＳ１１３では、UE１１１は、ターゲットMME１２１Ｔによって割り当てられた新たなGUTIをソースMME１２１Ｓから受信する。そして、UE１１１は、自身が管理しているregistered MME情報を当該新たなGUTIを用いて更新する。UE１１１は、GUTIの受信が完了したことを示すNASメッセージ（e.g., GUTI Reallocation Completeメッセージ）をソースMME１２１Ｓに送信する。ターゲットMME１２１Ｔを示すように更新されたregistered MME情報は、これ以降のRRCメッセージ及びNASメッセージ（TAU Request、Service Request等）の送信の際に使用される。ステップＳ１１３においてNASメッセージ（e.g., GUTI Reallocation Completeメッセージ）を受けたソースMME１２１Ｓは、UE１１１に対するリロケーションの通知が完了したことをターゲットMME１２１Ｔに知らせてもよい。
図３Ａ及び３Ｂの例は一例である。例えば、ステップＳ１１０では、ターゲットMME１２１Ｔの代わりにソースMME１２１Ｓが、ターゲットMME１２１Ｔによって割り当てられたMME UE S1AP IDをeNodeB１１２に通知してもよい。さらに、ステップＳ１１２では、ソースMME１２１Ｓの代わりにターゲットMME１２１Ｔが、ターゲットMME１２１ＴのID（e.g., GUMMEI）又はUE一時識別子（e.g., GUTI）をUE１１１に知らせてもよい。
また、上述の図３Ａ及び３Ｂに示されたソースMME１２１ＳからターゲットMME１２１Ｔへのリロケーション手順では、セキュリティ鍵（Security Key）に関する情報（例えば、KeNB、KeNB*、Next Hop Chaining Count(NHCC)、Next-Hop(NH)）を更新せずに、UE１１１がソースMME１２１Ｓに帰属（レジストレーション）していたときに使用していたものを再利用してもよい。あるいは、ソースMME１２１Ｓ（又はターゲットMME１２１Ｔ）は、ハンドオーバの場合のように新たなSecurity Keyに関する情報を導出し、これをeNodeB１１２を介してUE１１１に通知してもよい。
Security Keyに関する情報を更新せずに再利用する場合、ステップＳ１１２では、ソースMME１２１ＳがNAS: GUTI Reallocation Commandメッセージ（又は新規のNASメッセージ）をS1APメッセージでeNodeB１１２に送信し、eNodeB１１２が当該GUTI Reallocation CommandメッセージをRRC Connection ReconfigurationメッセージでUE１１１に送信してもよい。一方、Security Keyに関する情報を更新する場合、ステップＳ１１２では、ソースMME１２１ＳがNAS: GUTI Reallocation Commandメッセージ（又は新規のNASメッセージ）をS1APメッセージでeNodeB１１２に送信し、eNodeB１１２が当該GUTI Reallocation CommandメッセージをmobilityControlInfo IEを含むRRC Connection ReconfigurationメッセージでUE１１１に送信してもよい。
ステップＳ１１２では、ソースMME１２１Ｓの代わりにターゲットMME１２１Ｔが新たなGUTIをUE１１１に知らせてもよい。例えば、ソースMME１２１Ｓは、新たなGUTIを示すGUTI Reallocation CommandメッセージをUE１１１に送信してもよい。この場合、UE１１１は、ステップＳ１１３において、GUTIの受信が完了したことを示すNASメッセージ（e.g., GUTI Reallocation Completeメッセージ）をターゲットMME１２１Ｔに送信してもよい。
モビリティ管理及びベアラ管理をソースMME１２１ＳからターゲットMME１２１Ｔにリロケートするためのシグナリング手順の他の例は、以下の複数の実施形態において説明される。
＜第２の実施形態＞
本実施形態は、第１の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順の具体例を説明する。本実施形態に係る移動通信ネットワークの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。図４のシーケンス図は、リロケーションのためのシグナリング手順の一例を示している。図４の手順は、図２のステップＳ１３において行われることができる。すなわち、ソースMME１２１Ｓは、コントロールノード１４２からのコンテキスト・リロケーション指示メッセージの受信に応答して、図４に示されたシグナリング手順を開始してもよい。図４に示されたシグナリング手順は、UE１１１がアイドル状態（ECM-IDLE state）であるときに開始される。図４の手順では、ソースMME１２１Ｓは、UE１１１にリロケーションを知らせるために、Network triggered Service Request手順を利用する。
すなわち、ステップＳ２０１では、ソースMME１２１Ｓは、UE１１１のトラッキングエリア内に位置するeNodeB１１２を含む複数のeNodeBに対してページングメッセージを送信する（S1AP: Paging）。ステップＳ２０２では、eNodeB１１２は、S1AP Pagingを受信し、RRC: Paging messageを作成し、RRC: Paging messageをPaging control channel (PCCH)、Paging channel (PCH)、及びPhysical downlink shared channel (PDSCH)において送信する。このRRC: Paging messageは、ソースMME１２１ＳがUEに割り当てていた一時識別子（つまり、S-TMSI）を宛先とする。
ステップＳ２０３では、UE１１１は、ページングの受信に応答して、UE triggered Service Request手順を開始する。ステップＳ２０３の完了により、UE１１１は、コネクテッド状態（ECM-CONNECTED state）となる。ステップＳ２０４では、ソースMME１２１Ｓは、UE１１１がコネクテッド状態（ECM-CONNECTED state）に対応したリロケーション手順を開始する。ステップＳ２０４では、ソースMME１２１Ｓは、図３Ａ及び３Ｂに示された手順を行ってもよい。
図４の手順によれば、アイドル状態（ECM-IDLE state）のUEの１１１のモビリティ管理及びベアラ管理をリロケーションすることができる。
＜第３の実施形態＞
本実施形態は、第１の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順の具体例を説明する。本実施形態に係る移動通信ネットワークの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。図５のシーケンス図は、リロケーションのためのシグナリング手順の一例を示している。図５の手順は、図２のステップＳ１３において行われることができる。すなわち、ソースMME１２１Ｓは、コントロールノード１４２からのコンテキスト・リロケーション指示メッセージの受信に応答して、図５に示されたシグナリング手順を開始してもよい。図５に示されたシグナリング手順は、UE１１１がアイドル状態（ECM-IDLE state）であるときに開始される。図５の手順では、ソースMME１２１Ｓは、ページング手順を用いて、ターゲットMME１２１ＴのID（つまり、GUMMEI、MMEI、又はMMEC）を含むUE一時識別子（つまり、S-TMSI又はGUTI）をアイドル状態のUE１１１に送信する。
ステップＳ２２１では、ソースMME１２１Ｓは、EPC１２０にアタッチ済み（i.e., EMM-REGISTERED state）のUE１１１のモビリティ管理サービス及びベアラ管理サービスをターゲットMME１２１Ｔにリロケートする。ステップＳ２２１で行われる手順は、図３ＡのステップＳ１０１〜Ｓ１０５で行われる手順と同様であってもよい。ステップＳ２２２では、ターゲットMME１２１Ｔは、MMEの変更をHSS１２２に知らせる。ステップＳ２２２で行われる手順は、通常のTAU手順においてMMEの変更をHSS知らせるための手順と同様であってよく、すなわち図３ＡのステップＳ１０６〜Ｓ１０９で行われる手順と同様であってもよい。また、図３ＡのステップＳ１０６〜Ｓ１０９に関して説明したのと同様に、ステップＳ２２２は省略されてもよい。
ステップＳ２２３及びＳ２２４では、ソースMME１２１Ｓは、リロケーション後の新たなMME（つまり、ターゲットMME１２１Ｔ）のIDと、ターゲットMME１２１ＴによってUE１１１に割り当てられたUE一時識別子とをUE１１１に知らせる。具体的には、ソースMME１２１Ｓは、ターゲットMME１２１ＴによってUE１１１に割り当てられたGUTIをUE１１１に知らせればよい。図５の例では、新たなGUTIをUE１１１に知らせるためにページングが使用される。
すなわち、ステップＳ２２３では、ソースMME１２１Ｓは、eNodeB１１２を含むトラッキングエリア内の複数のeNodeBに対してページングメッセージを送信する（S1AP: Paging）。当該ページングメッセージは、ソースMME１２１ＳがUEに割り当てていた一時識別子（つまり、S-TMSI）を宛先とし、且つターゲットMME１２１ＴによってUE１１１に割り当てられた新たなGUTIを示す。ステップＳ２２４では、eNodeB１１２は、S1AP Pagingを受信し、RRC: Paging messageを作成し、RRC: Paging messageをPaging control channel (PCCH)、Paging channel (PCH)、及びPhysical downlink shared channel (PDSCH)において送信する。このRRC: Paging messageは、ソースMME１２１ＳがUEに割り当てていた一時識別子（つまり、S-TMSI）を宛先とし、且つターゲットMME１２１ＴによってUE１１１に割り当てられたGUTIを示す。
UE１１１は、ステップＳ２２４のページングメッセージを受信し、自身が管理しているregistered MME情報をターゲットMME１２１Ｔによって割り当てられた新たなGUTIを用いて更新する。ターゲットMME１２１Ｔを示すように更新されたregistered MME情報は、これ以降のRRCメッセージ及びNASメッセージ（TAU Request、Service Request等）の送信の際に使用される。例えば、図５のステップＳ２２５〜Ｓ２２７に示されるように、UE１１１は、Service Requestメッセージ、及びService Requestメッセージを送信するためのRRCコネクションの確立手順において、ターゲットMME１２１Ｔによって割り当てられたGUTI、又はこれから導き出されるS-TMSI若しくはGUMMEIを使用する。
ここで、上述のページングメッセージ（RRC: Paging message）によってリロケーションをUE１１１に通知するために、例えば、Paging message内に新たな情報要素（e.g., relocationIndication）を定義し、eNodeB１１２が当該relocationIndicationを有効にしてUE１１１に送信してもよい。例えば、relocatioIndicationは、ターゲットMME１２１Ｔによって新たにUE１１１に割り当てられたGUTIを示す。図２１及び２２は、ターゲットMME１２１Ｓによって割り当てられたGUTIを示すrelocatioIndicationを含むように拡張されたPaging messageの構成の具体例を示している。
図２１は、eNodeBが、リロケーションの対象となるUEに対してのみrelocationIndication-rXYZを含む、つまり当該IEがTrueに設定されたPaging messageを送信する。UEは、例えばPaging messageで通知されるPagingUE-Identity（例えばs-TMSI）が自身に割り当てられているものと一致した場合、relocationIndication-rXYZが含まれるか否かを確認し、relocationIndication-rXYZが含まれている場合には、上述のリロケーション手順を実行する。
一方、図２２は、eNodeBが、リロケーションの対象となる１つ以上のUEに対して一斉にリロケーションの指示を行う場合の例である。例えば、当該Paging messageは、リロケーションの為だけのPaging messageとして使用することが考えられる。eNodeBは、リロケーションの対象となるUEのPagingUE-Identity（のリスト）をPaging messageに含めると共に、relocationIndication-rXYZをPaging messageに含めて（つまり、Trueに設定して）当該Paging messageを送信する。この場合も、UEは、例えばPaging messageで通知されるPagingUE-Identity（例えばs-TMSI）が自身に割り当てられているものと一致した場合、relocationIndication-rXYZが含まれるか否かを確認し、relocationIndication-rXYZが含まれている場合には、上述のリロケーション手順を実行する。なお、図２１及び図２２のrelocationIndicationのpostfix 「-rXYZ」は当該IEが規定される仕様のリリース番号を意味し、説明の便宜上示されている。したがって、relocationIndication-rXYZは、上述の説明のrelocationIndicationと同様の意味である。
図５に戻って説明を続ける。ステップＳ２２５では、UE１１１は、ターゲットMME１２１Ｔによって割り当てられた新たなGUTIから導き出されたS-TMSIをUE Identityとして示すRRC Connection RequestメッセージをRRCコネクションの確立手順においてeNodeB１１２に送信する。ステップＳ２２６では、UE１１１は、当該新たなGUTIから導き出されたGUMMEIをRegistered MME情報として示すRRC Connection Setup CompleteメッセージをRRCコネクションの確立手順においてeNodeB１１２に送信する。このRRC Connection Setup Completeメッセージは、NASメッセージ、つまりここではService Requestメッセージ、をカプセル化している。ステップＳ２２７では、eNodeB１１２は、RRC Connection Setup CompleteメッセージからService Requestメッセージを取り出し、ステップＳ２２５で受信していたS-TMSIに基づいてターゲットMME１２１Ｔを選択し、Service Requestメッセージ及びS-TMSIを含むS1AP: Initial UE MessageをターゲットMME１２１Ｔに送信する。
図５の手順によれば、既存のページングメッセージのフォーマットを改変し、既存のページングの仕組みを流用してUE１１１に対してモビリティ管理及びベアラ管理のリロケーションが発生したことを知らせることができる。
なお、図５の手順は、ステップＳ２２３のページングメッセージの送信をソースMME１２１Ｓの代わりにターゲットMME１２１Ｔが行うよう改変されてもよい。
＜第４の実施形態＞
本実施形態は、第１の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順の具体例を説明する。本実施形態に係る移動通信ネットワークの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。図６のシーケンス図は、リロケーションのためのシグナリング手順の一例を示している。図６の手順は、図２のステップＳ１３において行われることができる。すなわち、ソースMME１２１Ｓは、コントロールノード１４２からのコンテキスト・リロケーション指示メッセージの受信に応答して、図６に示されたシグナリング手順を開始してもよい。図６に示されたシグナリング手順は、UE１１１がアイドル状態（ECM-IDLE state）であるときに開始される。図６の手順では、ソースMME１２１Ｓは、UE１１１にリロケーションを知らせるためにNetwork triggered Service Request手順を利用する。
ステップＳ２４１及びＳ２４２で行われる手順は、図５のステップＳ２２１及びＳ２２２で行われる手順と同様である。ステップＳ２４２は省略されてもよい。
ステップＳ２４３では、ソースMME１２１Ｓは、アイドル状態のUE１１１とシグナルするために、Network triggered Service Request手順を開始する。すなわち、ステップＳ２４３では、ソースMME１２１Ｓは、UE１１１のトラッキングエリア内に位置するeNodeB１１２を含む複数のeNodeBに対してページングメッセージを送信する（S1AP: Paging）。ステップＳ２４４では、eNodeB１１２は、S1AP Pagingを受信し、RRC: Paging messageを送信する。このRRC: Paging messageは、ソースMME１２１ＳがUEに割り当てていた一時識別子（つまり、S-TMSI）を宛先とする。
ステップＳ２４５では、UE１１１は、ページングの受信に応答して、UE triggered Service Request手順を開始する。ステップＳ２４５の完了により、UE１１１は、コネクテッド状態（ECM-CONNECTED state）となる。
ステップＳ２４６では、ソースMME１２１Ｓは、リロケーション後の新たなMME（つまり、ターゲットMME１２１Ｔ）のIDをUE１１１に知らせる。さらに、ソースMME１２１Ｓは、ターゲットMME１２１ＴによってUE１１１に割り当てられた一時識別子をUE１１１に知らせる。具体的には、ソースMME１２１Ｓは、ターゲットMME１２１ＴによってUE１１１に割り当てられたGUTIをUE１１１に知らせればよい。ステップＳ２４６では、NASメッセージが使用されてもよい。例えば、図６に示されているように、GUTI Reallocation Commandメッセージが使用されてもよい。あるいは、新規のNASメッセージが定義されて使用されてもよい。
ステップＳ２４７では、UE１１１は、ターゲットMME１２１Ｔによって割り当てられた新たなGUTIをソースMME１２１Ｓから受信する。そして、UE１１１は、自身が管理しているregistered MME情報を当該新たなGUTIを用いて更新する。UE１１１は、GUTIの受信が完了したことを示すNASメッセージ（e.g., GUTI Reallocation Completeメッセージ）をソースMME１２１Ｓに送信する。ターゲットMME１２１Ｔを示すように更新されたregistered MME情報は、これ以降のRRCメッセージ及びNASメッセージ（TAU Request、Service Request等）の送信の際に使用される。
ソースMME１２１Ｓは、ステップＳ２４７のUE１１１からのNASメッセージの受信を条件として、自身が保持しているUE１１１に関するコンテキストを削除してもよい。
図６の手順によれば、Network triggered Service Request手順を利用して、モビリティ管理及びベアラ管理のリロケーションが発生したことをUE１１１に知らせることができる。
なお、図６の手順は、ステップＳ２４３のページングメッセージの送信及びステップＳ２４６のGUTIのUEへの通知をソースMME１２１Ｓの代わりにターゲットMME１２１Ｔが行うよう改変されてもよい。
さらに、図６の手順は、ソースMME１２１Ｓ又はターゲットMME１２１Ｔによるページングを開始せずに、UE triggered Service Request手順においてUE１１１からService Requestメッセージを受信したときにリロケーションをUE１１１に通知するよう改変されてもよい。この場合、ソースMME１２１Ｓは、UE１１２からService Requestメッセージを受信し、且つリロケーション（ターゲットMME１２１Ｔによって割り当てられたGUTI）のUE１１１への通知が完了するまで、UEが１１１のコンテキストを保持し続ける。
＜第５の実施形態＞
本実施形態は、第１の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順の具体例を説明する。本実施形態に係る移動通信ネットワークの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。図７のシーケンス図は、リロケーションのためのシグナリング手順の一例を示している。図７の手順は、図２のステップＳ１３において行われることができる。すなわち、ソースMME１２１Ｓは、コントロールノード１４２からのコンテキスト・リロケーション指示メッセージの受信に応答して、図７に示されたシグナリング手順を開始してもよい。図７の手順では、ソースMME１２１Ｓは、MME始動のデタッチ手順（MME-initiated Detach procedure）の間に、ターゲットMME１２１ＴのID（つまり、GUMMEI、MMEI、又はMMEC）をUE１１１に送信する。
ステップＳ３０１では、ソースMME１２１Ｓは、UE１１１に対してDetach Requestメッセージを送信する。当該Detach Requestメッセージは、ターゲットMME１２１ＴのIDを含む。ターゲットMME１２１ＴのIDは、GUMMEI、MMEI、又はMMECであってもよい。ステップＳ３０２では、ステップＳ３０１でのDetach Requestメッセージの送信に引き続いてMME-initiated Detach procedureが行われる。
UE１１１は、Detach RequestメッセージからターゲットMME１２１ＴのID又はUE一時識別子（e.g., GUMMEI、MMEI、又はMMEC）を取り出し、これを保存する。Detach Requestメッセージから取り出されたターゲットMME１２１ＴのID又はUE一時識別子は、次回のアタッチ手順におけるRRCメッセージ及びNASメッセージ（Attach Request）の送信の際に使用される。
ステップＳ３０３〜Ｓ３０６は、UE１１１がEPC１２０に再びアタッチするための手順を示している。ステップＳ３０３では、UE１１１は、ランダム値をUE Identityとして示すRRC Connection RequestメッセージをRRCコネクションの確立手順においてeNodeB１１２に送信する。ステップＳ３０４では、UE１１１は、ターゲットMME１２１TのGUMMEIをRegistered MME情報として示すRRC Connection Setup CompleteメッセージをRRCコネクションの確立手順においてeNodeB１１２に送信する。RRC Connection Setup Completeメッセージは、NASメッセージ、つまりここではAttach Requestメッセージ、をカプセル化している。ステップＳ３０５では、eNodeB１１２は、RRC Connection Setup CompleteメッセージからAttach Requestメッセージを取り出し、RRC Connection Setup Completeメッセージに含まれるGUMMEIに基づいてターゲットMME１２１Ｔを選択し、Attach Requestメッセージを含むS1AP: Initial UE MessageをターゲットMME１２１Ｔに送信する。ステップＳ３０６では、ステップＳ３０５でのAttach Requestメッセージの送信に引き続いてAttach procedureが行われる。
なお、ステップＳ３０５においてeNodeB１１２がMMEセレクション機能に基づく自発的なMME選択を行わないようにするために、ステップＳ３０４のRRC Connection Setup Completeメッセージは、MMEセレクション機能に基づくMME選択が不要であることを明示的に示してもよい。
図７の手順によれば、UE１１１がEPC１２０から一度デタッチした後に再アタッチすることで、UE１１１のモビリティ管理及びベアラ管理をターゲットMME１２１Ｔに引き継ぐことができる。
＜第６の実施形態＞
本実施形態は、第１の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順の具体例を説明する。本実施形態に係る移動通信ネットワークの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。図８のシーケンス図は、リロケーションのためのシグナリング手順の一例を示している。図８の手順は、図２のステップＳ１３において行われることができる。すなわち、ソースMME１２１Ｓは、コントロールノード１４２からのコンテキスト・リロケーション指示メッセージの受信に応答して、図８に示されたシグナリング手順を開始してもよい。図８に示されたシグナリング手順は、UE１１１がアイドル状態（ECM-IDLE state）であるときに開始される。図８の手順では、ソースMME１２１Ｓは、UE１１１にリロケーションを知らせるために、UE１１１からのService Requestメッセージに対してService Rejectメッセージを返信するよう動作する。
ステップＳ３２１及びＳ３２２で行われる手順は、図５のステップＳ２２１及びＳ２２２で行われる手順と同様である。ステップＳ３２２は省略されてもよい。
ステップＳ３２３では、ソースMME１２１Ｓは、UE１１１からService Requestメッセージを受信する。ステップＳ３２３では、ソースMME１２１Ｓは、当該Service Requestメッセージの受信に応答して、Service Rejectメッセージを返信する。当該Service Rejectメッセージは、ターゲットMME１２１Ｔの識別子（e.g., GUMEI、MMEI、又はMMEC）、又はターゲットMME１２１ＴによってUE１１１に割り当てられた新たなUE一時識別子（e.g., S-TMSI又はGUTI）を示す。
UE１１１は、Service Rejectメッセージを受信する。そして、UE１１１は、自身が管理しているregistered MME情報をService Rejectメッセージを用いて通知された新たなGUMEI及びGUTI等で更新する。ターゲットMME１２１Ｔを示すように更新されたregistered MME情報は、これ以降のRRCメッセージ及びNASメッセージ（Attach Request、TAU Request、Service Request等）の送信の際に使用される。
図８の手順では、Service Rejectメッセージを受信したUE１１１は、Attach手順を開始する。ステップＳ３２５〜Ｓ３２７で行われる手順は、図７のステップＳ３０３〜Ｓ３０５で行われる手順と同様である。
図８の手順によれば、Service Rejectメッセージを利用して、モビリティ管理及びベアラ管理のリロケーションが発生したことをUE１１１に知らせることができる。また、図８の手順によれば、ソースMME１２１ＳからターゲットMME１２１Ｔへのリロケーションを任意の機会に行っておき、UE１１１からEPC１２０へのアクセスがあったときにリロケーションの発生をUE１１１に知らせることができる。
なお、図８の手順は、UE１１１によるService Requestメッセージの送信（ステップＳ３２３）を促すために、ソースMME１２１ＳがUE１１１をページングするよう改変されてもよい。
さらに、図８の手順は、ターゲットMME１２１Ｔの識別子（e.g., GUMEI、MMEI、又はMMEC）、又はターゲットMME１２１ＴによってUE１１１に割り当てられた新たなUE一時識別子（e.g., S-TMSI又はGUTI）をUE１１１に通知するために、Service Rejectメッセージとは異なる他のNASメッセージを利用するように改変されてもよい。例えば、GUTI Reallocation Commandメッセージが使用されてもよい。あるいは、新規のNASメッセージが定義されて使用されてもよい。
さらにまた、図８の手順は、Service Rejectメッセージ又はこれに代わるNASメッセージを受信した場合に、UE１１１がAttach手順ではなくService Request手順を開始するよう改変されてもよい。
＜第７の実施形態＞
本実施形態は、第１の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順の具体例を説明する。本実施形態に係る移動通信ネットワークの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。図９のシーケンス図は、リロケーションのためのシグナリング手順の一例を示している。図９の手順は、図２のステップＳ１３において行われることができる。すなわち、ソースMME１２１Ｓは、コントロールノード１４２からのコンテキスト・リロケーション指示メッセージの受信に応答して、図９に示されたシグナリング手順を開始してもよい。図９の手順では、ソースMME１２１Ｓは、S1 Release手順の間に、ターゲットMME１２１ＴのID（つまり、GUMMEI、MMEI、又はMMEC）を含むUE一時識別子（つまり、S-TMSI又はGUTI）をUE１１１に送信する。
ステップＳ４０１では、ソースMME１２１Ｓは、UE１１１のための全てのS1-Uベアラの解放（release）を要求するRelease Access Bearers RequestメッセージをS-GW１２３に送信する。ステップＳ４０２では、S-GW１２３は、UE１１１のためのeNodeBに関する情報（つまり、S1-Uベアラに関する情報）の全てを解放し、Release Access Bearers ResponseメッセージをソースMME１２１Ｓに送信する。
ステップＳ４０３及びＳ４０４で行われる手順は、図５のステップＳ２２１及びＳ２２２で行われる手順と同様である。ステップＳ４０４は省略されてもよい。
ステップＳ４０５及びＳ４０６では、ソースMME１２１Ｓは、リロケーション後の新たなMME（つまり、ターゲットMME１２１Ｔ）のIDと、ターゲットMME１２１ＴによってUE１１１に割り当てられたUE一時識別子とをUE１１１に知らせる。具体的には、ソースMME１２１Ｓは、ターゲットMME１２１ＴによってUE１１１に割り当てられた新たなGUTIをUE１１１に知らせればよい。図９の例では、新たなGUTIをUE１１１に知らせるために、RRCコネクションのリリースのためeNodeB１１２から送信されるRRCメッセージ（つまり、RRC: RRC Connection Releaseメッセージ）が使用される。
すなわち、ステップＳ４０５では、ソースMME１２１Ｓは、コネクテッド状態（ECM-CONNECTED状態）のUE１１１が現在接続しているeNodeB１１２に対して、S1AP: S1 UE Context Release Commandメッセージを送信する。このS1 UE Context Release Commandメッセージは、ターゲットMME１２１ＴによってUE１１１に割り当てられた新たなGUTIを示す。ステップＳ４０６では、eNodeB１１２は、RRC Connection ReleaseメッセージをUE１１１に送信する。このRRC Connection Releaseメッセージは、ターゲットMME１２１Ｔによって割り当てられた新たなGUTIを示す。
UE１１１は、ステップＳ４０６のRRC Connection Releaseメッセージを受信し、自身が管理しているregistered MME情報をターゲットMME１２１Ｔによって割り当てられた新たなGUTIを用いて更新する。ターゲットMME１２１Ｔを示すように更新されたregistered MME情報は、これ以降のRRCメッセージ及びNASメッセージ（TAU Request、Service Request等）の送信の際に使用される。例えば、図９のステップＳ４０７に示されるように、UE１１１は、TAU Requestメッセージ、及びTAU Requestメッセージを送信するためのRRCコネクションの確立手順において、ターゲットMME１２１Ｔによって割り当てられたGUTI、又はこれから導き出されるS-TMSI若しくはGUMMEIを使用する。
ステップＳ４０７では、UE１１１は、ターゲットMME１２１Ｔによって割り当てられた新たなGUTIから導き出されたGUMMEIをRegistered MME情報として示すRRC Connection Setup CompleteメッセージをRRCコネクションの確立手順においてeNodeB１１２に送信する。このRRC Connection Setup Completeメッセージは、NASメッセージ、つまりここではTAU Requestメッセージ、をカプセル化している。ステップＳ４０８では、eNodeB１１２は、RRC Connection Setup CompleteメッセージからTAU Requestメッセージを取り出し、RRC Connection Setup Completeメッセージに含まれるGUMMEIに基づいてターゲットMME１２１Ｔを選択し、TAU Requestメッセージを含むS1AP: Initial UE MessageをターゲットMME１２１Ｔに送信する。
図９の手順によれば、既存のS1 Release手順、並びにS1 UE Context Release Commandメッセージ及びRRC Connection Releaseメッセージのメッセージフォーマットを改変することで、UE１１１に対してモビリティ管理及びベアラ管理のリロケーションが発生したことを知らせることができる。
ここで、RRC Connection Releaseメッセージのフォーマットは、例えば図２３に示すように改変されてもよい。つまり、図２３は、RRC Connection Releaseメッセージの改変されたフォーマットの一例を示している。図２３の例では、RRC ConnectionのRelease causeに、MME relocationの指示を示す（意味する）relocationMMEというcause valueが追加されている。UE１１１は、RRC Connection ReleaseメッセージのRelease causeがrelocationMMEに設定されていたら、上記の動作を実行するようにしてもよい。なお、relocationMMEは一例であり、MME relocationを指示するものであれば、例えばMMErelocation、relocationRequired、re-registeredRequired、registrationUpdate、registrationUpdateRequired、GUTIupdate、GUTIupdateRequired、などでもよい。
＜第８の実施形態＞
本実施形態は、第１の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順の具体例を説明する。本実施形態に係る移動通信ネットワークの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。図１０Ａ及び１０Ｂのシーケンス図は、リロケーションのためのシグナリング手順の一例を示している。図１０Ａ及び１０Ｂの手順は、図２のステップＳ１３において行われることができる。すなわち、ソースMME１２１Ｓは、コントロールノード１４２からのコンテキスト・リロケーション指示メッセージの受信に応答して、図１０Ａ及び１０Ｂに示されたシグナリング手順を開始してもよい。図１０Ａ及び１０Ｂの手順では、ソースMME１２１Ｓは、Tracking Area Update（TAU）手順の間に、ターゲットMME１２１ＴのID（つまり、GUMMEI、MMEI、又はMMEC）を含むUE一時識別子（つまり、S-TMSI又はGUTI）をUE１１１に送信する。
ステップＳ５０１では、UE１１１は、ソースMME１２１Ｓに登録されており、アイドル状態（ECM-IDLE state）である。そして、UE１１１は、周期的TAUタイマ（periodic TAU timer）の満了に応じて、現在のTracking Area Identity（TAI）をソースMME１２１Ｓに知らせるためにTAU RequestメッセージをソースMME１２１Ｓに送信する。このTAU Requestメッセージは、そのupdate type によって“Periodic Updating”であることを示す。
ステップＳ５０２では、ソースMME１２１Ｓは、UE１１１からのTAU Requestメッセージのintegrity checkを行う。integrity checkが失敗した場合、ソースMME１２１Ｓは、UE１１１に関するAuthentication and NAS Security Setupを行う。
ステップＳ５０３では、ソースMME１２１Ｓは、UE１１１のMM context及びEPS bearer contextをターゲットMME１２１Ｔに送信する。この送信には、MME間のS10インタフェースにおいて送信されるGTP-Cメッセージを利用することができる。例えば、図１０Ａに示されているように、Forward Relocation Requestメッセージ又はそれを改変したものが使用されてもよい。ステップＳ５０３のForward Relocation Requestメッセージは、S1-based handover では無くContext Relocationを伴うTAUのために送信されるメッセージであることを示す情報要素を含んでもよい。
ステップＳ５０４では、ターゲットMME１２１Ｔは、ソースMME１２１Ｓから受信したUE１１１のMM context及びEPS bearer contextを自身のメモリ又はストレージ（不図示）に格納する。さらに、ターゲットMME１２１Ｔは、UE１１１のMM context及びEPS bearer contextの受信に応答して、S-GW１２３において保持されているUE１１１のEPS bearer contextの更新をS-GW１２３に要求する。この要求の送信には、MME１２１ＴとS-GW１２３の間のS11インタフェースにおいて送信されるGTP-Cメッセージを使用することができる。例えば、図１０Ａに示されているように、Modify Bearer Requestメッセージ又はそれを改変したものが使用されてもよい。
ステップＳ５０４のGTP-Cメッセージ（例えば、Modify Bearer Requestメッセージ）は、UE１１１のEPS bearerを管理する新たなMME、つまりターゲットMME１２１ＴのIPアドレス及びMME TEIDを示す。さらに、この要求は、UE１１１の現在位置情報（つまり、E-UTRAN Cell Global Identifier（ECGI）及びTracking Area Identity （TAI））を示す。
S-GW１２３は、ターゲットMME１２１ＴからUE１１１の現在位置情報（ECGI及びTAI）を受信し、UE１１１のECGI及びTAIが変化したかを確認する。もし変化した場合、UE１１１は、Modify Bearer RequestメッセージをP-GW１２４に送信する（ステップＳ５０５）。P-GW１２４は、UE１１１のEPS bearer contextに含まれるUE１１１の現在位置情報を更新し、Modify Bearer ResponseメッセージをS-GW１２３に送信する（ステップＳ５０６）。ステップＳ５０７では、S-GW１２３は、応答メッセージ（例えば、Modify Bearer Responseメッセージ）をターゲットMME１２１Ｔに送信する。
ステップＳ５０７〜Ｓ５１１は、MMEの変更をHSS１２２に知らせるために行われる。ステップＳ５０７〜Ｓ５１１の手順は、通常のTAU手順においてMMEの変更をHSS知らせるための手順と同様であってもよく、したがって図３ＡのステップＳ１０６〜Ｓ１０９の手順と同様であってもよい。
ステップＳ５１２では、ターゲットMME１２１Ｔは、UE１１１のモビリティ管理及びベアラ管理の引き継ぎを受け入れたことをソースMME１２１Ｓに通知する。この通知の送信には、MME間のS10インタフェースにおいて送信されるGTP-Cメッセージを使用することができる。例えば、図１０Ｂに示されているように、Forward Relocation Responseメッセージ又はそれを改変したものが使用されてもよい。あるいは、Forward Relocation Complete Notificationメッセージ又はそれを改変したものが使用されてもよい。
ステップＳ５１２の通知メッセージは、ターゲットMME１２１ＴによってUE１１１に割り当てられた一時識別子、すなわちM-TMSI、S-TMSI、又はGUTIを含む。
ステップＳ５１３では、ソースMME１２１Ｓは、ステップＳ５１２のメッセージに対する承認（Acknowledge）メッセージをターゲットMME１２１Ｔに送信する。当該承認メッセージの送信には、MME間のS10インタフェースにおいて送信されるGTP-Cメッセージを使用することができる。当該承認メッセージは、Forward Relocation Complete Acknowledgeメッセージ又はそれを改変したものであってもよい。
ステップＳ５１４では、ソースMME１２１Ｓは、TAU Acceptメッセージを用いて、リロケーション後の新たなMME（つまり、ターゲットMME１２１Ｔ）のIDをUE１１１に知らせる。さらに、ソースMME１２１Ｓは、ターゲットMME１２１ＴによってUE１１１に割り当てられた一時識別子をUE１１１に知らせる。具体的には、ソースMME１２１Ｓは、ターゲットMME１２１ＴのGUMMEIとターゲットMME１２１ＴによってUE１１１に割り当てられたM-TMSIとから構成されるGUTIをUE１１１に知らせればよい。
UE１１１は、TAU Acceptメッセージを受信し、ターゲットMME１２１Ｔによって割り当てられた新たなGUTIをTAU Acceptメッセージから取り出し、自身が管理しているregistered MME情報を当該新たなGUTIを用いて更新する。そして、ステップＳ５１５では、UE１１１は、新たなGUTIを受け取ったことを知らせるために、TAU CompleteメッセージをソースMME１２１Ｓに送信する。ターゲットMME１２１Ｔを示すように更新されたregistered MME情報は、ステップＳ５１５より後のRRCメッセージ及びNASメッセージ（TAU Request、Service Request等）の送信の際に使用される。
図１０Ａ及び１０Ｂの手順によれば、既存のTAU手順を改変することで、UE１１１に対してモビリティ管理及びベアラ管理のリロケーションが発生したことを知らせることができる。
＜第９の実施形態＞
本実施形態は、第１の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順の具体例を説明する。本実施形態に係る移動通信ネットワークの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。図１１のシーケンス図は、リロケーションのためのシグナリング手順の一例を示している。図１１の手順は、図２のステップＳ１３において行われることができる。すなわち、ソースMME１２１Ｓは、コントロールノード１４２からのコンテキスト・リロケーション指示メッセージの受信に応答して、図１１に示されたシグナリング手順を開始してもよい。
図１１の手順では、ソースＭＭＥ１２１Ｓ又はターゲットMME１２１Ｔは、EPC１２０にアタッチ済みであり（i.e., EMM-REGISTERED state）且つアイドル状態（i.e., ECM-IDLE State）のUE１１１からソースMME１２１Ｓ宛てのNASメッセージをターゲットMME１２１ＴにリダイレクトするようeNodeB１１２に指示する。そして、eNodeB１１２は、ソースMME１２１Ｓ又はターゲットMME１２１Ｔからの指示に従って、ソースMME１２１Ｓを指定するRRCパラメータを含むRRCメッセージと共にUE１１１から受信したNASメッセージをターゲットMME１２１Ｔにリダイレクトするよう動作する。
ステップＳ６０１及びＳ６０２で行われる手順は、図５のステップＳ２２１及びＳ２２２で行われる手順と同様である。ステップＳ６０２は省略されてもよい。
ステップＳ６０３では、ターゲットMME１２１Ｔは、ソースMME１２１Ｓ宛てのNASメッセージをターゲットMME１２１ＴにリダイレクトするようeNodeB１１２に指示する。この指示の送信には、MME１２１ＴとeNodeB１１２の間のS1-MMEインタフェースにおいて送信されるS1APメッセージを使用することができる。例えば、図１１に示されているように、新規メッセージ（S1AP: Redirection Commandメッセージ）が使用されてもよい。S1AP: Redirection Commandメッセージは、ソースMME１２１ＳとターゲットMME１２１Ｔの関連付けを示す。例えば、S1AP: Redirection Commandメッセージは、ソースMME１２１Ｓ及びターゲットMME１２１ＴのIDs（つまり、GUMMEIs、MMEIs、又はMMECs）を含んでもよい。あるいは、ステップＳ６０３では、既存のS1APメッセージ（e.g., MME Configuration Updateメッセージ）又はそれを改変したものが使用されてもよい。
eNodeB１１２は、S1AP: Redirection Commandメッセージを受信し、ソースMME１２１Ｓ宛てのNASメッセージをターゲットMME１２１Ｔにリダイレクトするよう設定する。ステップＳ６０４では、eNodeB１１２は、リダイレクト指示を受け取ったことを知らせるためのS1APメッセージ（S1AP: Redirection Completeメッセージ）をソースMME１２１Ｓに送信する。
ステップＳ６０５〜Ｓ６０６は、NAS: TAU Requestメッセージをカプセル化しているRRC Connection Setup Completeメッセージを受信したときの動作を示している。すなわち、eNodeB１１２は、ソースMME１２１ＳのGUMMEIを指定するRRCパラメータを含むRRC Connection Setup Completeメッセージを受信する（ステップＳ５０６）。次に、eNodeB１１２は、当該RRC Connection Setup CompleteメッセージからTAU Requestメッセージを取り出し、当該RRC Connection Setup Completeメッセージに含まれるソースMME１２１ＳのGUMMEIがリダイレクションのためにターゲットMME１２１のGUMMEIに対応付けられていることを判定する。そして、eNodeB１１２は、ターゲットMME１２１Ｔを選択し、TAU Requestメッセージを含むS1AP: Initial UE MessageをターゲットMME１２１Ｔに送信する（ステップＳ６０６）。
上述した図３（図３Ａ及び３Ｂ）〜図１０（図１０Ａ及び１０Ｂ）のリロケーション手順は、UE単位で実行される。したがって、シグナリング量は図１１の手順に比べて多いけれども、図３（図３Ａ及び３Ｂ）〜図１０（図１０Ａ及び１０Ｂ）のリロケーション手順は、ソースMME１２１ＳからターゲットMME１２１Ｔにリロケートする負荷をUE単位で調整することができる利点がある。一方、図１１のリロケーション手順は、ソースMME１２１Ｓによって行われていた全てのUEsのモビリティ管理及びベアラ管理をまとめてターゲットMME１２１Ｔに移転する。しかしながら、図１１のリロケーション手順のシグナリング量は、図３（図３Ａ及び３Ｂ）〜図１０（図１０Ａ及び１０Ｂ）のリロケーション手順のそれに比べて小さくなることが期待できる。さらに、図１１の手順によれば、モビリティ管理及びベアラ管理のリロケーションをUE１１１に通知する必要がなく、当該リロケーションをEPC１２０及びeNodeB１１２において完了することができる。したがって、図１１の手順は、UE１１１に新たな機能を追加することなく、モビリティ管理及びベアラ管理のリロケーションを行うことができる利点がある。
なお、図１１は、ターゲットMME１２１ＴがeNodeB１１２にリダイレクトを指示する例を示した。しかしながら、ターゲットMME１２１Ｔの代わりにソースMME１２１ＳがeNodeB１１２にリダイレクトを指示してもよい。
＜第１０の実施形態＞
本実施形態は、第１の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順の具体例を説明する。本実施形態に係る移動通信ネットワークの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。図１２のシーケンス図は、リロケーションのためのシグナリング手順の一例を示している。図１２の手順は、図２のステップＳ１３において行われることができる。すなわち、ソースMME１２１Ｓは、コントロールノード１４２からのコンテキスト・リロケーション指示メッセージの受信に応答して、図１２に示されたシグナリング手順を開始してもよい。
図１２の手順では、ソースＭＭＥ１２１Ｓは、EPC１２０にアタッチ済みであり（i.e., EMM-REGISTERED state）且つアイドル状態（i.e., ECM-IDLE State）のUE１１１からソースMME１２１Ｓ宛てのNASメッセージ（e.g., TAU Requestメッセージ、Service Requestメッセージ）を受信する。そして、UE１１１がリロケーションの対象であった場合に、当該NASメッセージをターゲットMME１２１ＴにリダイレクトするようeNodeB１１２に指示する。eNodeB１１２は、ソースMME１２１Ｓからの指示に従って、当該NASメッセージをターゲットMME１２１Ｔにリダイレクトするよう動作する。
ステップＳ６２１及びＳ６２２で行われる手順は、図５のステップＳ２２１及びＳ２２２で行われる手順と同様である。ステップＳ６２２は省略されてもよい。ステップＳ６２１及びＳ６２２の完了後、ソースMME１２１Ｓは、例えば所定のタイマの満了を条件として、リロケーションの対象とされたUE１１１を含むUEsのコンテキストを削除してもよい。ただし、ソースMME１２１Ｓは、リロケーションを実行したことを記憶しておく。ソースMME１２１Ｓは、リロケーションの対象とされたUEsのID（M-TMSI又はS-TMSI）を記憶しておいてもよい。
ステップＳ６２４では、UE１１１は、NASメッセージ（e.g., TAU Requestメッセージ、Service Requestメッセージ）を送信する。なお、UE１１１はリロケーションの発生を知らない。したがって、当該NASメッセージをカプセル化しているRRC Connection Setup Completeメッセージは、ソースMME１２１ＳのGUMMEIをRegistered MME情報として示す。また、これに先立って送信されるRRC Connection Requestメッセージは、ソースMME１２１によって割り当てられたS-TMSIをUE Identityとして示す（ステップＳ６２３）。このため、ステップＳ６２５では、eNodeB１１２は、UE１１１から受信した当該NASメッセージをソースMME１２１Ｓに送信する。
ステップＳ６２６では、ソースMME１２１Ｓは、ターゲットMME１２１Ｔへのリロケーションが行われたこと又はUE１１１が当該リロケーションの対象であったことを判定し、当該NASメッセージをターゲットMME１２１ＴにリダイレクトするようeNodeB１１２に指示する。この指示の送信には、MME１２１ＳとeNodeB１１２の間のS1-MMEインタフェースにおいて送信されるS1APメッセージを使用することができる。例えば、図１２に示されているように、新規メッセージ（S1AP: Redirection Commandメッセージ）が使用されてもよい。S1AP: Redirection Commandメッセージは、UE１１１からのNASメッセージがターゲットMME１２１Ｔにリダイレクトされるべきであることを示す。あるいは、ステップＳ６２６では、既存のS1APメッセージ（e.g., MME Configuration Updateメッセージ）又はそれを改変したものが使用されてもよい。
ステップＳ６２７では、eNodeB１１２は、S1AP: Redirection Commandメッセージを受信する、そして、eNodeB１１２は、ステップＳ６２４で受信したソースMME１２１Ｓ宛てのNASメッセージをターゲットMME１２１Ｔにリダイレクトする。
ステップＳ６２７の後、ターゲットMME１２１Ｔは、UE１１１からのNASメッセージに基づく手順（e.g., TAU手順、Service Request手順）を行う。この手順の間に、ターゲットMME１２１Ｔは、ターゲットMME１２１Ｔによって割り当てた新たなUE一時識別子（i.e., GUTI）をUE１１１に知らせるとよい。新たなUE一時識別子（i.e., GUTI）の送信には、TAU Acceptメッセージ又はGUTI Reallocation Commandメッセージ等のNASメッセージを使用することができる。これにより、UE１１１は、これ以降のRRCメッセージ及びNASメッセージ（TAU Request、Service Request等）の送信の際に、ターゲットMME１２１Ｔによって割り当てられた一時識別子（GUTI）を使用することができる。
図１２の手順によれば、モビリティ管理及びベアラ管理のリロケーションをEPC１２０において完了することができる。また、図１２の手順は、UE１１１に新たな機能を追加することなく、モビリティ管理及びベアラ管理のリロケーションを行うことができる。さらに図１１の手順と比較すると、図１２の手順は、UE単位でのリロケーションを行うことができる利点がある。言い換えると、図１２の手順は、ソースMME１２１Ｓによって行われていたUEsのモビリティ管理及びベアラ管理の一部（一部のUEs）のみをターゲットMME１２１Ｔに移転することができる。
＜第１１の実施形態＞
本実施形態は、第１の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順の具体例を説明する。本実施形態に係る移動通信ネットワークの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。図１３のシーケンス図は、リロケーションのためのシグナリング手順の一例を示している。図１３の手順は、図２のステップＳ１３において行われることができる。すなわち、ソースMME１２１Ｓは、コントロールノード１４２からのコンテキスト・リロケーション指示メッセージの受信に応答して、図１３に示されたシグナリング手順を開始してもよい。
図１３の手順では、ソースＭＭＥ１２１Ｓは、EPC１２０にアタッチ済みであり（i.e., EMM-REGISTERED state）且つアイドル状態（i.e., ECM-IDLE State）のUE１１１からソースMME１２１Ｓ宛てのNASメッセージ（e.g., TAU Requestメッセージ、Service Requestメッセージ）を受信する。そして、UE１１１がリロケーションの対象であった場合に、当該NASメッセージをターゲットMME１２１Ｔに転送する要動作する。
ステップＳ７０１及びＳ７０２で行われる手順は、図５のステップＳ２２１及びＳ２２２で行われる手順と同様である。ステップＳ７０２は省略されてもよい。ステップＳ７０１及びＳ７０２の完了後、ソースMME１２１Ｓは、例えば所定のタイマの満了を条件として、リロケーションの対象とされたUE１１１を含むUEsのコンテキストを削除してもよい。ただし、ソースMME１２１Ｓは、リロケーションを実行したことを記憶しておく。ソースMME１２１Ｓは、リロケーションの対象とされたUEsのID（M-TMSI又はS-TMSI）を記憶しておいてもよい。
ステップ７０３では、UE１１１は、NASメッセージ（e.g., TAU Requestメッセージ、Service Requestメッセージ）を送信する。なお、UE１１１はリロケーションの発生を知らない。したがって、当該NASメッセージをカプセル化しているRRC Connection Setup Completeメッセージは、ソースMME１２１ＳのGUMMEIをRegistered MME情報として示す。また、これに先立って送信されるRRC Connection Requestメッセージは、ソースMME１２１によって割り当てられたS-TMSIをUE Identityとして示す。このため、ステップＳ７０３のNASメッセージは、eNodeB１１２によってソースMME１２１Ｓに送信される。
ステップＳ７０４では、ソースMME１２１Ｓは、ターゲットMME１２１Ｔへのリロケーションが行われたこと又はUE１１１が当該リロケーションの対象であったことを判定し、当該NASメッセージをターゲットMME１２１Ｔに転送する。この転送には、MME間のS10インタフェースにおいて送信されるGTP-Cメッセージを使用することができる。
ステップＳ７０５では、ターゲットMME１２１Ｔは、UE１１１からのNASメッセージに基づく手順（e.g., TAU手順、Service Request手順）を行う。
ステップＳ７０６では、ターゲットMME１２１Ｔは、ターゲットMME１２１Ｔによって割り当てられた新たなGUTIをUE１１１に知らせる。新たなGUTIの送信には、TAU Acceptメッセージ又はGUTI Reallocation Commandメッセージ等のNASメッセージを使用することができる。これにより、UE１１１は、これ以降のRRCメッセージ及びNASメッセージ（TAU Request、Service Request等）の送信の際に、ターゲットMME１２１Ｔによって割り当てられた新たなGUTIを使用することができる。なお、ステップＳ７０６の新たなGUTIの通知は、ステップＳ７０６の前に行われてもよい。
ステップＳ７０７では、UE１１１は、GUTIを受信したことを示す応答メッセージ（e.g., TAU Acceptメッセージ、GUTI Reallocation Completeメッセージ）を送信する。
図１３の手順によれば、ソースMME１２１ＳからターゲットMME１２１Ｔへのリロケーションを任意の機会に行っておき、UE１１１からEPC１２０へのアクセスがあったときにリロケーションの発生をUE１１１に知らせることができる。
＜第１２の実施形態＞
本実施形態は、第１の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順の具体例を説明する。本実施形態に係る移動通信ネットワークの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。図１４Ａ及び１４Ｂのシーケンス図は、リロケーションのためのシグナリング手順の一例を示している。図１４Ａ及び１４Ｂの手順は、図２のステップＳ１３において行われることができる。すなわち、ソースMME１２１Ｓは、コントロールノード１４２からのコンテキスト・リロケーション指示メッセージの受信に応答して、図１４Ａ及び１４Ｂに示されたシグナリング手順を開始してもよい。
図１４Ａ及び１４Ｂの手順では、ソースＭＭＥ１２１Ｓは、EPC１２０にアタッチ済みであり（i.e., EMM-REGISTERED state）且つアイドル状態（i.e., ECM-IDLE State）のUE１１１からソースMME１２１Ｓ宛てのNASメッセージ（e.g., TAU Requestメッセージ、Service Requestメッセージ）を受信する。そして、UE１１１がリロケーションの対象であるためにUE１１１のコンテキストを削除していた場合、ソースMME１２１Ｓは、UE１１１を管理している現在のMMEを知るためにHSS１２２に問い合わせる。
ステップＳ８０１及びＳ８０２で行われる手順は、図５のステップＳ２２１及びＳ２２２で行われる手順と同様である。ただし、MMEの変更をHSS１２２に知らせるために、Ｓ８０２は必ず行われる。
ステップ８０３では、UE１１１は、NASメッセージ（e.g., TAU Requestメッセージ、Service Requestメッセージ）を送信する。なお、UE１１１はリロケーションの発生を知らない。したがって、当該NASメッセージをカプセル化しているRRC Connection Setup Completeメッセージは、ソースMME１２１ＳのGUMMEIをRegistered MME情報として示す。また、これに先立って送信されるRRC Connection Requestメッセージは、ソースMME１２１によって割り当てられたS-TMSIをUE Identityとして示す。このため、ステップＳ８０３のNASメッセージは、eNodeB１１２によってソースMME１２１Ｓに送信される。
ステップＳ８０４では、ソースMME１２１Ｓは、UE１１１からのNASメッセージを受信し、UE１１１に関するコンテキスト（MM context、EPS Bearer context）を保持していないことを検出する。そして、当該検出に応じて、ソースMME１２１Ｓは、UE１１１のIMSIをUE１１１に問い合わせる。この問い合わせには、NAS: Identity Requestメッセージを利用することができる。ステップＳ８０５では、UE１１１は自身のIMSIを示すNASメッセージ（e.g., Identity Responseメッセージ）を送信する。
ステップＳ８０６では、ソースMME１２１Ｓは、UE１１１を管理しているMMEをHSS１２２に問い合わせるために、UE１１１から受信したIMSIをHSS１２２に送信する。当該問い合わせには、MME１２１ＳとHSS１２２の間の66aインタフェースにおいて送信されるDiameterメッセージを使用することができる。図１４Ｂに示されているように、新規Diameterメッセージ（DIAMETER: MME-ID Requestメッセージ）が使用されてもよい。ステップＳ８０７では、HSS１２２は、UE１１１を管理するターゲットMME１２１ＴのID（e.g., GUMMEI、MMEI、又はMMEC）を示す応答メッセージをソースMME１２１Ｓに送信する。
ステップＳ８０８では、ソースMME１２１Ｓは、UE１１１に割り当てられた一時識別子（e.g., GUTI、S-TMSI、又はM-TMSI）をターゲットMME１２１Ｔに問い合わせる。当該問い合わせには、MME間のS10インタフェースにおいて送信されるGTP-Cメッセージを使用することができる。ステップＳ８０９では、ターゲットMME１２１Ｔは、ターゲットMME１２１ＴによってUE１１１に割り当てられた一時識別子（e.g., GUTI、S-TMSI、又はM-TMSI）を示す応答メッセージをソースMME１２１Ｓに送信する。
ステップＳ８１０では、ソースMME１２１Ｓは、リロケーション後の新たなMME（つまり、ターゲットMME１２１Ｔ）のIDをUE１１１に知らせる。さらに、ソースMME１２１Ｓは、ターゲットMME１２１ＴによってUE１１１に割り当てられた一時識別子をUE１１１に知らせる。具体的には、ソースMME１２１Ｓは、ターゲットMME１２１ＴによってUE１１１に割り当てられたGUTIをUE１１１に知らせればよい。ステップＳ８１０では、NASメッセージが使用されてもよい。例えば、図１４Ｂに示されているように、GUTI Reallocation Commandメッセージが使用されてもよい。あるいは、新規のNASメッセージが定義されて使用されてもよい。
ステップＳ８１１では、UE１１１は、ターゲットMME１２１Ｔによって割り当てられた新たなGUTIをソースMME１２１Ｓから受信する。そして、UE１１１は、自身が管理しているregistered MME情報を当該新たなGUTIを用いて更新する。UE１１１は、GUTIの受信が完了したことを示すNASメッセージ（e.g., GUTI Reallocation Completeメッセージ）をソースMME１２１Ｓに送信する。ターゲットMME１２１Ｔを示すように更新されたregistered MME情報は、これ以降のRRCメッセージ及びNASメッセージ（TAU Request、Service Request等）の送信の際に使用される。例えば、UE１１１は、新たなTAU手順又はService Request手順をターゲットMME１２１Ｔとの間で行ってもよい（ステップＳ８１２）。
図１４Ａ及び１４Ｂの手順によれば、ソースMME１２１ＳからターゲットMME１２１Ｔへのリロケーションを任意の機会に行っておき、UE１１１からEPC１２０へのアクセスがあったときにリロケーションの発生をUE１１１に知らせることができる。さらに、ソースMME１２１Ｓは、リロケーション先のMMEのIDを記憶してく必要がない。
図１４Ａ及び１４Ｂの手順は、適宜改変されてもよい。例えば、図１４Ａ及び１４Ｂに示されたソースMME１２１ＳがターゲットMME１２１ＴのIDを知るためにHSS１２２に問い合わせる手順は、図１２に示されたソースMME１２１ＳによるNASメッセージのリダイレクション指示（ステップＳ６２６）のために使用されてもよい。また、図１４Ａ及び１４Ｂに示されたソースMME１２１ＳがHSS１２２に問い合わせる手順は、図１３に示されたソースMME１２１ＳによるNASメッセージの転送（ステップＳ７０４）のために使用されてもよい。
＜第１３の実施形態＞
本実施形態は、第１４の実施形態で説明されたリロケーション手順の変形例を説明する。図１５Ａは、図１４Ａの変形を示す。ステップＳ８２１及びＳ８２２は、図１４ＡのステップＳ８０１及びＳ８０２と同様である。
ステップＳ８２３は、UE１１１から送信されるNASメッセージがリロケーション・フラグを示す点が図１４ＡのステップＳ８０３と異なる。リロケーション・フラグは、UE１１１がリロケーションの対象とされた可能性があることを示す。ソースMME１２１Ｓは、リロケーション（ステップＳ８２１）の実行に先立って、リロケーションが行われる可能性があることUE１１１に通知しておく。当該通知をソースMME１２１Ｓから受信していた場合、UE１１１は、リロケーション・フラグがセットされたNASメッセージを送信する。
ソースMME１２１Ｓは、UE１１１に関するコンテキストを保持しておらず且つUE１１１からのNASメッセージにおいてリロケーション・フラグがセットされている場合に、ソースMME１２１Ｓは、UE１１１のIMSIをUE１１１に問い合わせる（ステップＳ８２４）。ステップＳ８２４及びＳ８２５は、図１４ＡのステップＳ８０４及びＳ８０５と同様である。さらに、ステップＳ８２５に引き続いて、図１４Ｂに示された手順が実行される。これに対して、UE１１１に関するコンテキストを保持しておらず且つリロケーション・フラグがセットされていない場合は、ソースMME１２１Ｓはリジェクトメッセージ（e.g., TAU Rejectメッセージ、Service Rejectメッセージ）をUE１１１に返信する。
図１５Ａの手順によれば、ソースMME１２１Ｓは、HSS１２２への問い合わせを含むステップＳ８２４以降の手順を実行する対象とするべきUEを限定することができる。
＜第１４の実施形態＞
本実施形態は、第１の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順の具体例を説明する。本実施形態に係る移動通信ネットワークの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。図１６のシーケンス図は、リロケーションのためのシグナリング手順の一例を示している。図１６の手順は、図２のステップＳ１３において行われることができる。すなわち、ソースMME１２１Ｓは、コントロールノード１４２からのコンテキスト・リロケーション指示メッセージの受信に応答して、図１６に示されたシグナリング手順を開始してもよい。
ステップＳ９０１〜Ｓ９０４では、ソースMME１２１Ｓがリロケーションを実行し、リロケーション後のターゲットMME１２１Ｔによって割り当てられたUE一時識別子（e.g., GUTI）がUE１１１に通知される。ステップＳ９０１〜Ｓ９０４は、図１０Ａ及び１０Ｂに示されたTAU手順の間にUE一時識別子をUE１１１に通知する手順と同様である。しかしながら、ステップＳ９０１〜Ｓ９０４は、他の手順（e.g., 図５、図６、図８、又は図９の手順）に置き換えられてもよい。
図１６の手順のポイントは、ステップＳ９０３においてプライマリGUTI及びセカンダリGUTIがUE１１１に通知される点にある。ここでは、プライマリGUTIはターゲットMME１２１Ｔによって割り当てられたGUTIを指定し、セカンダリGUTIはソースMME１２１Ｓによって割り当てられたGUTIを指定する。UE１１１は、プライマリGUTIを優先的に使用し、プライマリGUTIを用いたシグナリング（e.g., TAU手順、Service Request手順）が失敗した場合にセカンダリGUTIを使用する。一方、ソースMME１２１Ｓは、リロケーションを行った後も所定のタイマが満了するまでUE１１１のコンテキストを保持しておく。これにより、リロケーションに伴う何らかの不具合に起因してプライマリMMEとしてのターゲットMME１２１ＴがUE１１１のアクセスを拒絶した場合であっても、セカンダリMMEとしてのソースMME１２１ＳがUE１１１のアクセスを受け付けることができる。
例えば、UE１１１は、ターゲットMME１２１Ｔに対してTAU Requestメッセージを送信する（ステップＳ９０５）。しかしながら、ターゲットMME１２１Ｔは、何らかの不具合のためにUE１１１のコンテキストを保持しておらず、TAU RejectメッセージをUE１１１に返信する（ステップＳ９０６）。プライマリMME（ターゲットMME１２１Ｔ）との通信に失敗したUE１１１は、セカンダリMME（ソースMME１２１Ｓ）との通信を試みる（ステップＳ９０７）。ソースMME１２１ＳがUE１１１のコンテキストをまだ保持している場合、ソースMME１２１Ｓは、UE１１１との通信を開始するとともに、改めてリロケーション（e.g., ステップＳ９０１〜Ｓ９０４）を実行すればよい。
＜第１５の実施形態＞
本実施形態は、第１４の実施形態の変形例を説明する。図１７は、本実施形態に係るリロケーションのためのシグナリング手順の一例を示している。本実施形態では、第１４の実施形態と同様に、UE１１１のモビリティ管理及びベアラ管理のリロケーションが行われ、プライマリGUTI及びセカンダリGUTIがUE１１１に通知される（ステップＳ９２１〜Ｓ９２４）。ソースMME１２１Ｓは、リロケーションを行った後も所定のタイマが満了するまでUE１１１のコンテキストを保持しておく。
ステップＳ９２５では、UE１１１は、TAU Requestメッセージを送信する。このとき、TAU Requestメッセージを運ぶために使用されるConnection Setup Completeメッセージは、Registered MME情報としてプライマリMME（ターゲットMME１２１Ｔ）のGUMMEI及びセカンダリMME（ソースMME１２１Ｓ）のGUMMEIを示す。ステップＳ９２６では、eNodeB１１２は、プライマリMMEに指定されたターゲットMME１２１Ｔに対してTAU Requestメッセージを転送する。
ステップＳ９２７では、ターゲットMME１２１Ｔは、何らかの不具合のためにUE１１１のコンテキストを保持していないために、リジェクトメッセージを送信する。当該リジェクトメッセージは、UE１１１ではなくeNodeB１１２に送信される。当該リジェクトメッセージの送信には、S1APメッセージを使用することができる。リジェクトメッセージを受信した場合、eNodeB１１２は、セカンダリMMEに指定されたソースMME１２１Ｓに対してTAU Requestメッセージを転送する。ソースMME１２１ＳがUE１１１のコンテキストをまだ保持している場合、ソースMME１２１Ｓは、UE１１１との通信を開始するとともに、改めてリロケーション（e.g., ステップＳ９０１〜Ｓ９０４）を実行すればよい。
図１７の手順によれば、図１６の手順と同様に、リロケーションに伴う何らかの不具合に起因してプライマリMMEとしてのターゲットMME１２１ＴがUE１１１のアクセスを拒絶した場合であっても、セカンダリMMEとしてのソースMME１２１ＳがUE１１１のアクセスを受け付けることができる。
＜第１６の実施形態＞
本実施形態は、第１４の実施形態の変形例を説明する。図１８Ａ〜１８Ｃは、本実施形態に係るリロケーションのためのシグナリング手順の一例を示している。本実施形態では、第１４及び第１５の実施形態と同様に、UE１１１に対してプライマリGUTI及びセカンダリGUTIが通知される。プライマリGUTIは、ターゲットMME１２１ＴによってUE１１１に割り当てられたGUTIである。ただし、本実施形態では、セカンダリGUTIは、ソースMME１２１Ｓ及びターゲットMME１２１Ｔのいずれとも異なるセカンダリMME８２１によってUE１１１に割り当てられたGUTIである。すなわち、本実施形態では、ソースMME１２１Ｓは、UE１１１のコンテキストをターゲットMME１２１Ｔに移すと共に、これをセカンダリMME８２１にも移しておく。したがって、ターゲットMME１２１はプライマリ・ターゲットMMEと呼ぶことができ、セカンダリMME８２１はセカンダリ・ターゲットMMEと呼ぶことができる。
ステップＳ９４１及びＳ９４２では、ソースMME１２１ＳからターゲットMME１２１Ｔへのリロケーションが行われる。なお、図１８Ａは、TAU手順の間にリロケーションを行うケースを示しているが、これまでに多くの具体例を示したことから明らかであるように、他の手順（e.g., 図５、図６、図８、又は図９の手順）に置き換えられてもよい。
ステップＳ９４３では、ソースMME１２１Ｓは、UE１１１のコンテキストをセカンダリMME８２１にも送信する。当該送信には、MME間のS10インタフェースにおいて送信されるGTP-Cメッセージ（e.g., Forward Relocation Requestメッセージ）を使用することができる。ステップＳ９４４では、セカンダリMME８２１は、返信メッセージ（e.g., Forward Relocation Responseメッセージ）をソースMME１２１Ｓに送信する。当該返信メッセージは、セカンダリMME８２１によってUE１１１に割り当てられたGUTIを示す。
ステップＳ９４５では、ソースMME１２１Ｓは、プライマリGUTI及びセカンダリGUTIを示すNASメッセージ（e.g., TAU Acceptメッセージ）をUE１１１に送信する。ここでは、プライマリGUTIはターゲットMME１２１Ｔによって割り当てられたGUTIを指定し、セカンダリGUTIはセカンダリMME８２１によって割り当てられたGUTIを指定する。ステップＳ９４６では、UE１１１は、新たなGUTIを受け取ったことを知らせるために、TAU CompleteメッセージをソースMME１２１Ｓに送信する。
ステップＳ９４７及びＳ９４８は、図１６のステップＳ９０５及びＳ９０６と同様である。すなわち、UE１１１は、ターゲットMME１２１Ｔに対してTAU Requestメッセージを送信する（ステップＳ９４７）。しかしながら、ターゲットMME１２１Ｔは、何らかの不具合のためにUE１１１のコンテキストを保持しておらず、TAU RejectメッセージをUE１１１に返信する（ステップＳ９４８）。プライマリMME（ターゲットMME１２１Ｔ）との通信に失敗したUE１１１は、セカンダリMME８２１との通信を試みる（ステップＳ９４９）。
セカンダリMME８２１は、UE１１１からのNASメッセージ（e.g., TAU Requestメッセージ）の受信に応答して、S-GW１２３において保持されているUE１１１のEPS bearer contextの更新をS-GW１２３に要求する（ステップＳ９５０）。この要求は、UE１１１のEPS bearerを管理する新たなMME、つまりセカンダリMME８２１のIPアドレス及びMME TEIDを示す。さらに、UE１１１からのNASメッセージがTAU Requestメッセージである場合、この要求は、UE１１１の現在位置情報（つまり、E-UTRAN Cell Global Identifier（ECGI）及びTracking Area Identity （TAI））を示す。この要求の送信には、MME８２１とS-GW１２３の間のS11インタフェースにおいて送信されるGTP-Cメッセージを使用することができる。例えば、図１８Ｂに示されているように、Modify Bearer Requestメッセージ又はそれを改変したものが使用されてもよい。
S-GW１２３は、セカンダリMME８２１からUE１１１の現在位置情報（ECGI及びTAI）を受信し、UE１１１のECGI及びTAIが変化したかを確認する。もし変化した場合、UE１１１は、Modify Bearer RequestメッセージをP-GW１２４に送信する（ステップＳ９５１）。P-GW１２４は、UE１１１のEPS bearer contextに含まれるUE１１１の現在位置情報を更新し、Modify Bearer ResponseメッセージをS-GW１２３に送信する（ステップＳ９５２）。ステップＳ９５３では、S-GW１２３は、応答メッセージ（例えば、Modify Bearer Responseメッセージ）をセカンダリMME８２１に送信する。
ステップＳ９５４〜Ｓ９５７は、MMEの変更をHSS１２２に知らせるために行われる。ステップＳ９５４〜Ｓ９５７の手順は、通常のTAU手順においてMMEの変更をHSS知らせるための手順と同様であってもよく、したがって図３ＡのステップＳ１０６〜Ｓ１０９の手順と同様であってもよい。
ステップＳ９５８では、セカンダリMME８２１は、TAU AcceptメッセージをUE１１１に送信する。当該TAU Acceptメッセージは、セカンダリMME８２１によって割り当てられたGUTIがプライマリGUTIとして指定されることを示してもよい。これにより、UE１１１は、次回のNASメッセージの送信をターゲットMME１２１ＴではなくセカンダリMME８２１に対して優先的に行うことができる。ステップＳ９５８のTAU AcceptメッセージがプライマリGUTIの変更（又はプライマリMMEの変更）を示す場合、UE１１１は、プライマリGUTIの変更を受け入れたことを知らせるために、TAU CompleteメッセージをセカンダリMME８２１に送信する（ステップＳ９５９）。
図１８Ａ〜１８Ｃの手順によれば、ソースMME１２１ＳからターゲットMME１２１Ｔへのモビリティ管理及びベアラ管理のリロケーションが何らかの原因で失敗した場合であっても、セカンダリMME８２１に保持されているUEコンテキストを利用することができる。したがって、リロケーションの失敗を効果的に防ぐことができる。
＜第１７の実施形態＞
本実施形態は、S-GWのリロケーションを伴うMMEリロケーション手順について説明する。図１９Ａ及び１９Ｂのシーケンス図は、ソースS-GW１２３ＳからターゲットS-GW１２３Ｔへのリロケーションを伴うMMEリロケーション手順の一例を示している。図１９Ａ及び１９Ｂに示された手順は、図３Ａ及び３Ｂに示された手順の変形であって、UE１１１がコネクテッド状態（ECM-CONNECTED state）であるときに開始される。UE１１１がコネクテッド状態であるときのS-GWのリロケーションは、S-GWリロケーションを伴うS1-based handover手順におけるS-GWのリロケーションと同一又は類似する手順で行われてもよい。
ステップＳ１００１では、図３ＡのステップＳ１０１と同様に、ソースMME１２１Ｓは、UE１１１のMM context及びEPS bearer contextをターゲットMME１２１Ｔに送信する。この送信には、GTP-Cメッセージを利用することができる。例えば、図１９Ａに示されているように、Forward Relocation Requestメッセージ又はそれを改変したものが使用されてもよい。さらに、ステップＳ１００１のGTP-Cメッセージは、ターゲットS-GW１２３Ｔの指定を含んでもよい。
ステップＳ１００２では、図３ＡのステップＳ１０２と同様に、ターゲットMME１２１Ｔは、ソースMME１２１Ｓから受信したUE１１１のMM context及びEPS bearer contextを自身のメモリ又はストレージ（不図示）に格納する。さらに、ターゲットMME１２１Ｔは、ソースS-GW１２３ＳからターゲットS-GW１２３Tへのリロケーションを開始する。なお、UE１１１がコネクテッド状態であるときのS-GWのリロケーションは、S-GWリロケーションを伴うS1-based handover手順におけるS-GWのリロケーションと同一又は類似する手順で行えばよい。すなわち、ターゲットMME１２１Ｔは、S5/S8ベアラの設定要求をターゲットS-GW１２３Ｔに送信する。このS5/S8ベアラの設定要求は、ベアラコンテキスト、アップリンクトラフィックのためのP-GW１２４のP-GW１２４のアドレス及びTEID、並びにダウンリンクトラフィックのためのeNodeB１１２のアドレス及びTEIDを含む。このS5/S8ベアラの設定要求は、S1-based handover手順で使用されるメッセージと同様に、Create Session Requestメッセージであってもよい。
ステップＳ１００３では、ターゲットS-GW１２３Ｔは、UE１１１のためのS1 uplink (UL) TEID及びS5/S8 downlink (DL) TEIDを生成する。そして、ターゲットS-GW１２３Ｔは、ターゲットS-GW１２３Ｔのアドレス及びS5/S8 DL TEIDをP-GW１２４に知らせる。ターゲットS-GW１２３Ｔは、ターゲットS-GW１２３Ｔのアドレス及びS5/S8 DL TEIDを含むModify Bearer RequestメッセージをP-GW１２４に送信してもよい。
ステップＳ１００４では、P-GW１２４は、自身が保持するコンテキストを更新し、Modify Bearer ResponseメッセージをターゲットS-GW１２３Ｔに送信する。
ステップＳ１００５では、ターゲットS-GW１２３Ｔは、Create Session ResponseメッセージをターゲットMME１２１Ｔに返信する。このCreate Session Responseメッセージは、ユーザープレーンに関するターゲットS-GW１２３Ｔのアドレス及びS1 UL TEIDを示す。
ステップＳ１００６では、ターゲットMME１２１Ｔは、ターゲットMME１２１Ｔによって割り当てられたMME UE S1AP IDをeNodeB１１２に通知する。さらに、ターゲットMME１２１Ｔは、ユーザープレーンに関するターゲットS-GW１２３Ｔのアドレス及びS1 UL TEID（つまり、S1-U SGW F-TEID）をeNodeB１１２に通知する。これらの通知は、例えば、改変されたHandover Requestメッセージ、改良されたInitial Context Setup Requestメッセージ、改良されたE-RAB Modify Requestメッセージ、又は改良されたUE Context Modification Requestメッセージを使用してターゲットMME１２１ＴからeNodeB１１２に送信されてもよい。
ステップＳ１００７では、eNodeB１１２は、自身が保持するコンテキストを更新し、承認（Acknowledge）メッセージをターゲットMME１２１Ｔに送信する。当該承認メッセージは、ダウンリンクトラフィックのためのeNodeB１１２のアドレス及びTEID（つまり、S1-U eNodeB F-TEID）を示してもよい。当該承認メッセージは、改変されたHandover Request Ackメッセージ、改良されたInitial Context Setup Responseメッセージ、改良されたE-RAB Modify Responseメッセージ、又は改良されたUE Context Modification Responseメッセージであってもよい。
もしダウンリンクトラフィックのためのS1-U eNodeB F-TEIDが更新された場合、ターゲットMME１２１Ｔは、更新されたS1-U eNodeB F-TEID を示すModify Bearer RequestメッセージをターゲットS-GW１２３Ｔに送信する（ステップＳ１００８）。ステップＳ１００９では、ターゲットS-GW１２３Ｔは、コンテキストを更新し、Modify Bearer ResponseメッセージをターゲットMME１２１Ｔに送信する。S1-U eNodeB F-TEIDが更新されない場合、ステップＳ１００８及びＳ１００９は省略されてもよい。
ステップＳ１０１０では、図３ＡのステップＳ１０４と同様に、ターゲットMME１２１Ｔは、UE１１１のモビリティ管理及びベアラ管理の引き継ぎを受け入れたことをソースMME１２１Ｓに通知する。ステップＳ１０１０の通知メッセージは、ターゲットMME１２１ＴによってUE１１１に割り当てられた一時識別子、すなわちM-TMSI、S-TMSI、又はGUTIを含む。この通知メッセージの送信には、Forward Relocation Responseメッセージ又はそれを改変したものが使用されてもよい。あるいは、Forward Relocation Complete Notificationメッセージ又はそれを改変したものが使用されてもよい。
ステップＳ１０１１では、図３ＡのステップＳ１０５と同様に、ソースMME１２１Ｓは、ステップＳ１０１０のメッセージに対する承認（Acknowledge）メッセージをターゲットMME１２１Ｔに送信する。当該承認メッセージは、Forward Relocation Complete Acknowledgeメッセージ又はそれを改変したものであってもよい。
ステップＳ１０１２〜Ｓ１０１５は、MMEの変更をHSS１２２に知らせるために行われる。ステップＳ１０１２〜Ｓ１０１５で行われる手順は、図３ＡのステップＳ１０６〜Ｓ１０９で行われる手順と同様である。また、ステップＳ１０１２〜Ｓ１０１５は、省略されてもよい。
ステップＳ１０１６では、ソースMME１２１Ｓは、UE１１１に関するベアラコンテキストの削除を要請するためにDelete Session RequestメッセージをソースS-GW１２３Ｓに送信する。ステップＳ１０１７では、ソースS-GW１２３Ｓは、UE１１１に関するベアラコンテキストを削除し、Delete Session ResponseメッセージをソースMME１２１Ｓに返信する。
ステップＳ１０１８及びＳ１０１９で行われる手順は、図３ＢのステップＳ１１２及びＳ１１３で行われる手順と同様である。
図１９Ａ及び１９Ｂの手順によれば、コネクテッド状態（ECM-CONNECTED state）のUE１１１に関して、S-GWのリロケーションを伴うMMEリロケーション手順を行うことができる。
＜第１８の実施形態＞
本実施形態は、S-GWのリロケーションを伴うMMEリロケーション手順について説明する。図２０のシーケンス図は、ソースS-GW１２３ＳからターゲットS-GW１２３Ｔへのリロケーションン（又はS-GW change）を伴うMMEリロケーション手順の一例を示している。図２０に示された手順は、図５に示された手順の変形であって、UE１１１がアイドル状態（ECM-IDLE state）であるときに開始される。UE１１１がアイドル状態であるときのS-GWのリロケーションは、S-GWリロケーション（又はS-GW change）を伴うTAU手順におけるS-GWのリロケーションと同一又は類似する手順で行われてもよい。
ステップＳ１１２１では、ソースMME１２１Ｓは、EPC１２０にアタッチ済み（i.e., EMM-REGISTERED state）のUE１１１のモビリティ管理サービス及びベアラ管理サービスをターゲットMME１２１Ｔにリロケートする。ステップＳ１１２１で行われる手順は、図１９Ａ及び１９ＢのステップＳ１００１〜Ｓ１００５並びにＳ１０１０〜Ｓ１０１１で行われる手順と同様であってもよい。
ステップＳ１１２２では、ターゲットMME１２１Ｔは、MMEの変更をHSS１２２に知らせる。ステップＳ１１２２で行われる手順は、通常のTAU手順においてMMEの変更をHSS知らせるための手順と同様であってよく、すなわち図３ＡのステップＳ１０６〜Ｓ１０９で行われる手順と同様であってもよい。また、ステップＳ１１２２は省略されてもよい。
ステップＳ１１２３〜Ｓ１１２７で行われる手順は、図５のステップＳ２２３〜Ｓ２２７で行われる手順と同様である。
図２０の手順によれば、アイドル状態（ECM-IDLE state）のUE１１１に関して、S-GWのリロケーションを伴うMMEリロケーション手順を行うことができる。
なお、図２０は、アイドル状態のUE１１１に関するS-GWリロケーション（又はS-GW change）を伴うMMEリロケーション手順を説明するために、ページングを用いる図５の手順を改変した手順を示した。図２０を用いて説明されたS-GWリロケーション（又はS-GW change）は、第４〜第１６の実施形態で説明された他の手順においても図２０と同様に利用されることができる。
最後に上述の第１〜第１８の実施形態に係るソースMME１２１Ｓ、ターゲットMME１２１Ｔ、セカンダリMME８２１、UE１１１、及びeNodeB１１２の構成例について説明する。図２４は、ソースMME１２１Ｓの構成例を示している。ターゲットMME１２１Ｔ及びセカンダリMME８２１の構成も図２４の構成例と同様であってもよい。
図２４を参照すると、MME１２１Ｓは、ネットワークインタフェース１２１０、プロセッサ１２１１、及びメモリ１２１２を含む。ネットワークインタフェース１２１０は、他のネットワークノード（e.g., eNodeB１１２、ターゲットMME１２１Ｔ、HSS１２２、S-GW１２３）と通信するために使用される。ネットワークインタフェース１２１０は、例えば、IEEE 802.3 seriesに準拠したネットワークインタフェースカード（NIC）を含んでもよい。
プロセッサ１２１１は、メモリ１２１２からソフトウェア（コンピュータプログラム）を読み出して実行することで、通信制御（e.g.,モビリティ管理及びベアラ管理）を実行する。プロセッサ１２１１は、例えば、マイクロプロセッサ、Micro Processing Unit（MPU）、又はCentral Processing Unit（CPU）であってもよい。プロセッサ１２１１は、複数のプロセッサを含んでもよい。
メモリ１２１２は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、例えば、マスクRead Only Memory（MROM）、Programmable ROM（PROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの組合せである。また、メモリ１２１２は、プロセッサ１２１１から物理的に離れて配置されたストレージを含んでもよい。この場合、プロセッサ１２１１は、ネットワークインタフェース１２１０又は図示されていない他のI/Oインタフェースを介してメモリ１２１２にアクセスしてもよい。
図２４の例では、メモリ１２１２は、S1-MMEモジュール１２１３、S6aモジュール１２１４、S10モジュール１２１５、S11モジュール１２１６、NASモジュール１２１７、EPS Mobility Management（EMM）及びEPS Session Management（ESM）モジュール１２１８、及びOperation and Maintenance（OAM）モジュール１２１９を含むソフトウェアモジュール群を格納するために使用される。OAMモジュール１２１９は、上述の実施形態で説明されたコントロールノード１４２との通信とリロケーションを制御するための命令群およびデータを含む。プロセッサ１２１１は、OAMモジュール１２１９をメモリ１２１２から読み出して実行することで、上述の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順に関するソースMME１２１Ｓの動作を行うことができる。
図２５は、UE１１１の構成例を示している。図２５を参照すると、UE１１１は、無線トランシーバ１１１０、プロセッサ１１１１、及びメモリ１１１２を含む。無線トランシーバ１１１０は、eNodeB１１２と通信するよう構成されている。
プロセッサ１１１１は、メモリ１１１２からソフトウェア（コンピュータプログラム）を読み出して実行することで、RRC及びNASメッセージの送受信を含む通信制御を行う。プロセッサ１１１１は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ１１１１は、複数のプロセッサを含んでもよい。
メモリ１１１２は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、例えば、MROM、PROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの組合せである。
図２５の例では、メモリ１１１２は、RRCモジュール１１１３及びNASモジュール１１１４を含むソフトウェアモジュール群を格納するために使用される。プロセッサ１１１１はRRCモジュール１１１３及びNASモジュール１１１４をメモリ１１１２から読み出して実行することで、上述の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順に関するUE１１１の動作を行うことができる。
図２６は、eNodeB１１２の構成例を示している。図２６を参照すると、eNodeB１１２は、無線トランシーバ１１２０、ネットワークインタフェース１１２１、プロセッサ１１２２、及びメモリ１１２３を含む。無線トランシーバ１１２０は、UE１１１と通信するよう構成されている。ネットワークインタフェース１１２１は、E-UTRAN１１０内の他のeNodeB、並びにEPC１２０内のノード（MME１２１Ｓ、MME１２１Ｔ、及びS-GW１２３等）と通信するために使用される。
プロセッサ１１２２は、メモリ１１２３からソフトウェア（コンピュータプログラム）を読み出して実行することで、RRC及びRadio Resource Management（RRM）を含む通信制御、並びに上述の実施形態で説明されたeNodeB１１２の動作を行う。プロセッサ１１２２は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ１１２２は、複数のプロセッサを含んでもよい。
メモリ１１２３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。揮発性メモリは、例えば、SRAM若しくはDRAM又はこれらの組み合わせである。不揮発性メモリは、例えば、MROM、PROM、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの組合せである。また、メモリ１１２３は、プロセッサ１１２２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１１２２は、ネットワークインタフェース１１２１又は図示されていない他のI/Oインタフェースを介してメモリ１１２３にアクセスしてもよい。
図２６の例では、メモリ１１２３は、RRCモジュール１１２４、RRMモジュール１１２５、X2モジュール１１２６、及びS1-MMEモジュール１１２７を含むソフトウェアモジュール群を格納するために使用される。RRCモジュール１１２４及びS1-MMEモジュール１１２７は、受信したRRCメッセージにカプセル化されているNASメッセージをMMEに転送する処理を実行するための命令群およびデータを含む。プロセッサ１１２２は、RRCモジュール１１２４及びS1-MMEモジュール１１２７をメモリ１１２３から読み出して実行することで、上述の実施形態で説明されたモビリティ管理及びベアラ管理のリロケーション手順に関するeNodeB１１２の動作を行うことができる。
図２４〜図２６を用いて説明したように、上述の実施形態に係るソースMME１２１Ｓ、ターゲットMME１２１Ｔ、セカンダリMME８２１、UE１１１、及びeNodeB１１２が有するプロセッサの各々は、シーケンス図等を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。
このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、Compact Disc Read Only Memory（CD-ROM）、CD-R、CD-R/W、半導体メモリ（例えば、マスクROM、Programmable ROM（PROM）、Erasable PROM（EPROM）、フラッシュROM、Random Access Memory（RAM））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
＜その他の実施形態＞
図２〜図２０に示されたリロケーション手順は、適宜変形することができる。例えば、図２〜図２０は、ソースMME１２１Ｓがコントロールノード１４２からリロケーション指示メッセージを受信する例を示した。しかしながら、ソースMME１２１Ｓの代わりにターゲットMME１２１Ｔがコントロールノード１４２からリロケーション指示メッセージを受信し、リロケーション手順を開始してもよい。
また、図３（図３Ａ及び３Ｂ）及び図５等は、ターゲットMME１２１ＴのID（e.g., GUMMEI）又はターゲットMME１２１Ｔによって割り当てられたUE一時識別子（e.g., GUTI）をソースMME１２１ＳがUE１１１に知らせる例を示した。しかしながら、ソースMME１２１Ｓの代わりにターゲットMME１２１Ｔが、ターゲットMME１２１ＴのID又はUE一時識別子をUE１１１に知らせてもよい。
また、上述の実施形態では、主にEPSに関する具体例を用いて説明を行った。しかしながら、これらの実施形態は、その他の移動通信システム、例えば、Universal Mobile Telecommunications System（UMTS）、3GPP2 CDMA2000システム（1xRTT、High Rate Packet Data（HRPD））、Global System for Mobile communications（GSM（登録商標））/General packet radio service（GPRS）システム、及びモバイルWiMAXシステム等に適用されてもよい。
さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。
この出願は、２０１４年６月２４日に出願された日本出願特願２０１４−１２８８２２を基礎とする優先権を主張し、その開示の全てをここに取り込む。
１１０ Evolved Universal Terrestrial Radio Access Network (E-UTRAN)
１１１ User Equipment (UE)
１１２ eNodeB
１２１Ｓ Source Mobility Management Entity (MME)
１２１Ｔ Target MME
１２２ Home Subscriber Server (HSS)
１２３ Serving Gateway (S-GW)
１２４ Packet Data Network Gateway (P-GW)
１２０ Evolved Packet Core (EPC)
１３０ Packet Data Network (PDN)
１４１ 制御インタフェース
１４２ コントロールノード
１１１１、１１２２、１２１１ プロセッサ
１１１２、１１２３、１２１２ メモリ

Claims (9)

  1. コアネットワーク内に配置されるネットワークノードであって、
    前記コアネットワークにアタッチ済みである複数の移動端末のモビリティ管理及びベアラ管理を行う手段、
    前記コアネットワークに結合されたコントロールノードからリロケーション指示メッセージを受信する手段、及び
    前記リロケーション指示メッセージに従って、前記ネットワークノードから前記コアネットワーク内の少なくとも１つの他のノードへの前記複数の移動端末のうち少なくとも１つのための前記モビリティ管理及び前記ベアラ管理のリロケーションを行う手段、
    を備え、
    前記リロケーション指示メッセージは、リロケーションポリシを含み、
    前記リロケーションポリシは、前記少なくとも１つの第２のネットワークノードの識別子を含む、
    ネットワークノード。
  2. 前記リロケーションポリシは、前記ネットワークノードから前記少なくとも１つの他のネットワークノードにリロケートされるべき前記モビリティ管理及び前記ベアラ管理の処理量を示す、請求項１に記載のネットワークノード。
  3. 前記リロケーションポリシは、前記リロケーションに対する時間的な制約を示す、請求項１又は２に記載のネットワークノード。
  4. 前記リロケーションポリシは、前記リロケーションを行うための複数のシグナリング手順のうちいずれを用いるべきかを示す、請求項１〜３のいずれか１項に記載のネットワークノード。
  5. 前記コアネットワークは、Third Generation Partnership Project（3GPP）のEvolved Packet Core（EPC）を含み、
    前記ネットワークノード及び前記他のノードの各々は、Mobility Management Entity（MME）である、
    請求項１〜４のいずれか１項に記載のネットワークノード。
  6. 前記コントロールノードは、Software-Defined Network（SDN）コントローラ、Network Function Virtualization（NFV）コントローラ、Operations Support System（OSS）、又はElement Management System（EMS）である、請求項１〜５のいずれか１項に記載のネットワークノード。
  7. コアネットワークに結合して使用されるコントロールノードであって、
    前記コアネットワーク内に配置されて前記コアネットワークにアタッチ済みである複数の移動端末のモビリティ管理及びベアラ管理を行う第１のネットワークノードに関するリロケーション指示メッセージを送信する手段を備え、
    前記リロケーション指示メッセージは、前記第１のネットワークノードから少なくとも１つの第２のネットワークノードへの前記複数の移動端末のうち少なくとも１つのための前記モビリティ管理及び前記ベアラ管理のリロケーションを引き起こし、
    前記リロケーション指示メッセージは、リロケーションポリシを含み、
    前記リロケーションポリシは、前記少なくとも１つの第２のネットワークノードの識別子を含む、
    コントロールノード。
  8. コアネットワーク内に配置されたネットワークノードによって行われる方法であって、
    前記コアネットワークにアタッチ済みである複数の移動端末のモビリティ管理及びベアラ管理を行うこと、
    前記コアネットワークに結合されたコントロールノードからリロケーション指示メッセージを受信すること、及び
    前記リロケーション指示メッセージに従って、前記ネットワークノードから前記コアネットワーク内の少なくとも１つの他のノードへの前記複数の移動端末のうち少なくとも１つのための前記モビリティ管理及び前記ベアラ管理のリロケーションを行うこと、
    前記リロケーション指示メッセージは、リロケーションポリシを含み、
    前記リロケーションポリシは、前記少なくとも１つの第２のネットワークノードの識別子を含む、
    を備え、方法。
  9. コアネットワーク内に配置されたネットワークノードによって行われる方法をコンピュータに行わせるためのプログラムであって、
    前記方法は、
    前記コアネットワークにアタッチ済みである複数の移動端末のモビリティ管理及びベアラ管理を行うこと、
    前記コアネットワークに結合されたコントロールノードからリロケーション指示メッセージを受信すること、及び
    前記リロケーション指示メッセージに従って、前記ネットワークノードから前記コアネットワーク内の少なくとも１つの他のノードへの前記複数の移動端末のうち少なくとも１つのための前記モビリティ管理及び前記ベアラ管理のリロケーションを行うこと、
    を備え、
    前記リロケーション指示メッセージは、リロケーションポリシを含み、
    前記リロケーションポリシは、前記少なくとも１つの第２のネットワークノードの識別子を含む、
    プログラム。
JP2016528981A 2014-06-24 2015-03-05 コントロールノード及びネットワークノード並びにこれらにより行われる方法 Active JP6460102B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2014128822 2014-06-24
JP2014128822 2014-06-24
PCT/JP2015/001192 WO2015198508A1 (ja) 2014-06-24 2015-03-05 コントロールノード及びネットワークノード並びにこれらにより行われる方法

Publications (2)

Publication Number Publication Date
JPWO2015198508A1 JPWO2015198508A1 (ja) 2017-04-27
JP6460102B2 true JP6460102B2 (ja) 2019-01-30

Family

ID=54937622

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016528981A Active JP6460102B2 (ja) 2014-06-24 2015-03-05 コントロールノード及びネットワークノード並びにこれらにより行われる方法

Country Status (5)

Country Link
US (1) US10512011B2 (ja)
EP (1) EP3163943B1 (ja)
JP (1) JP6460102B2 (ja)
CN (1) CN106471846B (ja)
WO (1) WO2015198508A1 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10070357B2 (en) * 2014-09-25 2018-09-04 Intel IP Corporation Smooth UE transfer within an evolved packet core
CN106332222A (zh) * 2015-07-02 2017-01-11 北京三星通信技术研究有限公司 一种网络选择的方法和基站
WO2017099464A1 (ko) * 2015-12-07 2017-06-15 엘지전자 주식회사 이동성 관리 객체에 의한 s1 연결 해제 수행 방법 및 이동성 관리 객체와, 기지국에 의한 s1 연결 해제 수행 방법 및 기지국
CN106993329A (zh) * 2016-01-21 2017-07-28 中兴通讯股份有限公司 寻呼的方法、装置及系统
EP3468253B1 (en) * 2016-07-01 2021-04-14 Huawei Technologies Co., Ltd. Switching method and device
RU2707741C1 (ru) 2016-07-01 2019-11-29 Телефонактиеболагет Лм Эрикссон (Пабл) Системы и способы регистрации пользовательского устройства (ue)
GB2552845A (en) * 2016-08-12 2018-02-14 Nec Corp Communication system
US10219193B2 (en) * 2016-08-22 2019-02-26 Samsung Electronics Co., Ltd. Method and apparatus for providing services of network to terminal by using slice
CN108616868B (zh) * 2017-01-09 2020-03-06 电信科学技术研究院 一种终端空闲态的处理方法及装置
US11032695B2 (en) * 2017-03-20 2021-06-08 Telefonaktiebolaget Lm Ericsson (Publ) Methods and arrangements for transferring management of wireless devices between core network nodes of a wireless communication network
CN108738077B (zh) * 2017-04-25 2023-09-01 华为技术有限公司 一种负荷迁移的方法、装置和系统
CN110679199B (zh) * 2017-05-23 2024-04-02 瑞典爱立信有限公司 为用户平面会话获得cn/ran端点对的决定的网络节点及方法
FR3072537A1 (fr) * 2017-10-17 2019-04-19 Orange Procede de basculement d'un equipement de gestion dans un reseau de telecommunications
CN113891430A (zh) * 2017-11-28 2022-01-04 华为技术有限公司 一种通信的方法、装置及系统
CN114980226A (zh) * 2018-06-26 2022-08-30 华为技术有限公司 重定向的方法、通信系统和通信装置
CN114902711A (zh) * 2020-01-03 2022-08-12 三星电子株式会社 用于在边缘计算系统中调整应用上下文重定位的方法和装置

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4221200B2 (ja) * 2002-08-19 2009-02-12 日本電気通信システム株式会社 移動体通信システムにおける負荷分散システム及び交換装置
CN100584093C (zh) 2006-08-15 2010-01-20 华为技术有限公司 一种在移动通信系统中转移用户设备的方法及系统
CN101400153B (zh) * 2007-09-27 2013-01-16 北京三星通信技术研究有限公司 用户设备通过hnb接入系统直接通信的方法
EP2079253A1 (en) * 2008-01-09 2009-07-15 Panasonic Corporation Non-3GPP to 3GPP network handover optimizations
CN101541040B (zh) 2008-03-21 2012-04-25 华为技术有限公司 一种过载处理的方法及装置
JP5042248B2 (ja) 2009-01-22 2012-10-03 株式会社日立製作所 移動体通信システム、呼制御サーバ及びアクセスゲートウェイ装置
WO2010112037A1 (en) 2009-03-31 2010-10-07 Telefonaktiebolaget Lm Ericsson (Publ). Redistribution of terminals
EP2416606A4 (en) 2009-03-31 2012-11-14 Ericsson Telefon Ab L M DEVICE AND METHOD FOR DISPLAYING WCDMA MOBILE STATIONS IN THE MANNER OF THE LOWEST PACKAGE LOSS
CN103096294B (zh) * 2009-06-10 2015-09-23 华为技术有限公司 控制隧道标识分配的方法、装置和系统
US9668293B2 (en) 2009-08-25 2017-05-30 Telefonaktiebolaget Lm Ericsson (Publ) Relocation of mobility anchor for nomadic subscribers
KR101078639B1 (ko) 2009-09-30 2011-11-01 삼성전자주식회사 이종 망간의 핸드오버 장치 및 그 방법
US8331938B2 (en) * 2009-11-23 2012-12-11 Telefonaktiebolaget L M Ericsson (Publ) Moving user equipment without service interruption
US8331224B2 (en) * 2009-11-23 2012-12-11 Telefonaktiebolaget L M Ericsson (Publ) Self-management of mobility management entity (MME) pools
US20110235505A1 (en) * 2010-03-29 2011-09-29 Hitachi, Ltd. Efficient deployment of mobility management entity (MME) with stateful geo-redundancy
ES2540991T3 (es) 2010-05-11 2015-07-15 Nec Europe Ltd. Método para manejar el fallo de una MME en un sistema de paquetes evolucionado
US20130136047A1 (en) 2010-08-17 2013-05-30 Nec Europe Ltd. Sleeping epc for energy saving in lte
US8848516B2 (en) * 2010-09-15 2014-09-30 Telefonaktiebolaget L M Ericsson (Publ) Methods and apparatus for relocating and restoring connections through a failed serving gateway and traffic offloading
US8578035B2 (en) * 2010-09-27 2013-11-05 Telefonaktiebolaget Lm Ericsson (Publ) Technique for relocating a serving gateway associated to a user equipment
ES2544102T3 (es) 2011-04-06 2015-08-27 Nec Europe Ltd. Método y un sistema para distribución de contexto de equipo de usuario en un sistema de paquetes evolucionado
EP3703418A3 (en) * 2011-06-24 2020-11-18 Vodafone IP Licensing limited Telecommunication networks
CN102868994A (zh) * 2011-07-08 2013-01-09 北京三星通信技术研究有限公司 一种支持用户设备ue移动性的方法
WO2013016842A1 (en) * 2011-08-01 2013-02-07 Telefonaktiebolaget L M Ericsson (Publ) Method, apparatus and system for moving wireless terminals in mobility management serving node pool
US8971268B2 (en) 2011-08-24 2015-03-03 Lg Electronics Inc. Method and apparatus for transmitting uplink data associated with MTC device trigger function
WO2013048193A1 (en) * 2011-09-28 2013-04-04 Lg Electronics Inc. Method and apparatus for transmitting establishment cause value in wireless communication system
EP3324671A1 (en) * 2011-09-30 2018-05-23 Nec Corporation Communication system, method, and apparatus
CN103096404B (zh) * 2011-11-04 2018-07-13 北京三星通信技术研究有限公司 支持组切换的方法及设备
CN108770024B (zh) * 2011-11-04 2023-05-26 北京三星通信技术研究有限公司 支持组切换的方法及设备
JP6031529B2 (ja) 2011-11-22 2016-11-24 エスシーエー アイピーエルエー ホールディングス インコーポレイテッド モバイル通信システム、モバイル通信ネットワーク、インフラストラクチャ機器、モビリティマネージャ、方法およびコンピュータプログラム
GB2497074A (en) 2011-11-22 2013-06-05 Sca Ipla Holdings Inc A virtual mobility manager stores context information for an offline communications terminal
GB2497073A (en) 2011-11-22 2013-06-05 Sca Ipla Holdings Inc A virtual mobility manager stores context information for an offline communications terminal
JP6203177B2 (ja) * 2012-08-02 2017-09-27 三菱電機株式会社 通信システム
EP2908583B1 (en) * 2012-10-10 2019-02-27 LG Electronics Inc. Method for processing paging and method for relaying downlink data
CN104581652B (zh) * 2013-10-15 2018-12-07 华为技术有限公司 消息处理方法、选择mme的方法和装置
US20150195326A1 (en) 2014-01-03 2015-07-09 Qualcomm Incorporated Detecting whether header compression is being used for a first stream based upon a delay disparity between the first stream and a second stream
CN104853344B (zh) * 2014-02-17 2019-10-29 中兴通讯股份有限公司 一种选择分流网关的方法和控制器
CN106465214B (zh) * 2014-06-24 2019-11-05 日本电气株式会社 网络节点、移动终端、基站和在其中执行的方法

Also Published As

Publication number Publication date
CN106471846B (zh) 2020-01-07
EP3163943B1 (en) 2020-01-08
JPWO2015198508A1 (ja) 2017-04-27
EP3163943A1 (en) 2017-05-03
WO2015198508A1 (ja) 2015-12-30
US10512011B2 (en) 2019-12-17
EP3163943A4 (en) 2017-12-27
CN106471846A (zh) 2017-03-01
US20170195926A1 (en) 2017-07-06

Similar Documents

Publication Publication Date Title
JP6460102B2 (ja) コントロールノード及びネットワークノード並びにこれらにより行われる方法
JP6460103B2 (ja) ネットワークノード、移動端末、及び基地局、並びにこれらにより行われる方法
JP6621152B2 (ja) ベアラ管理装置、及び通信方法
WO2015140848A1 (ja) 制御装置、基地局装置、無線端末、及び隣接関係テーブルの更新方法
WO2016035230A1 (ja) モビリティ管理及びベアラ管理を移転するための方法及び装置
JP5091205B2 (ja) 移動通信方法、移動通信システム及び移動局
RU2543945C1 (ru) Способ мобильной связи, узел управления мобильными устройствами и устройство обслуживающего шлюза
WO2013029245A1 (zh) 一种承载的处理方法、系统及装置
EP3703462B1 (en) COMMUNICATION METHODS AND, A COMMUNICATIONS APPARATUS, A COMMUNICATIONS SYSTEM, A COMPUTER 
READABLE STORAGE MEDIUM, AND A COMPUTER PROGRAM PRODUCT
WO2012016546A1 (zh) 一种用户设备的寻呼处理方法及设备
EP3139677B1 (en) Method and device for user device to save power
EP3403428B1 (en) Central node management of ue context
EP3457750B1 (en) Ue context resume

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161201

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180208

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20181016

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181120

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20181204

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181217

R150 Certificate of patent or registration of utility model

Ref document number: 6460102

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150