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

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

Info

Publication number
WO2015198508A1
WO2015198508A1 PCT/JP2015/001192 JP2015001192W WO2015198508A1 WO 2015198508 A1 WO2015198508 A1 WO 2015198508A1 JP 2015001192 W JP2015001192 W JP 2015001192W WO 2015198508 A1 WO2015198508 A1 WO 2015198508A1
Authority
WO
WIPO (PCT)
Prior art keywords
relocation
mme
message
procedure
network
Prior art date
Application number
PCT/JP2015/001192
Other languages
English (en)
French (fr)
Inventor
孝法 岩井
創 前佛
Original Assignee
日本電気株式会社
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 日本電気株式会社 filed Critical 日本電気株式会社
Priority to US15/321,686 priority Critical patent/US10512011B2/en
Priority to EP15811393.6A priority patent/EP3163943B1/en
Priority to CN201580034412.XA priority patent/CN106471846B/zh
Priority to JP2016528981A priority patent/JP6460102B2/ja
Publication of WO2015198508A1 publication Critical patent/WO2015198508A1/ja

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

Definitions

  • the present disclosure relates to a mobile communication network, and particularly to mobility management and bearer management of mobile terminals in a core network.
  • Non-Patent Document 1 defines the packet architecture of Third Generation Partnership Project (3GPP), that is, the functional architecture of Evolved Packet System (EPS). Specifically, Non-Patent Document 1 includes an Attach procedure, Tracking Area Update (TAU) procedure, Service Request procedure, S1SRelease procedure, Globally Unique Temporary Identity (GUTI) Reallocation procedure, Detach procedure, Dedicated bearer activation procedure, Bearer modification It defines various procedures for mobility management, session management, and handover of mobile terminals in EPS, including procedures, X2-based handover procedures, and S1-based handover procedures.
  • 3GPP Third Generation Partnership Project
  • EPS Evolved Packet System
  • Non-Patent Document 1 includes an Attach procedure, Tracking Area Update (TAU) procedure, Service Request procedure, S1SRelease procedure, Globally Unique Temporary Identity (GUTI) Reallocation procedure, Detach procedure, Dedicated bearer activation procedure, Bearer modification It defines various procedures for mobility management, session management, and handover of mobile
  • MME mobility management entity
  • EPC EvolvedvolvePacket Core
  • UEs User Equipments
  • EMM-REGISTERED state a mobility management context
  • Bearer management controls the establishment of EPS bearers for UE to communicate with external networks (Packet Data Network (PDN)) via Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and EPC. including maintaining the context.
  • PDN Packet Data Network
  • E-UTRAN Evolved Universal Terrestrial Radio Access Network
  • EPC Evolved Universal Terrestrial Radio Access Network
  • a virtualized core network (referred to as Virtualized EPC etc.) uses server virtualization technology and network virtualization technology to abstract the control plane and / or data plane of the core network.
  • core network nodes for example, MME, Serving Gateway (S-GW) / PDN Gateway (P-GW) control plane, and S / P-GW data plane
  • S-GW Serving Gateway
  • P-GW PDN Gateway
  • S / P-GW data plane are servers.
  • the mobility management and bearer management of the moved UE is changed from Old MME (or Source MME) to New MME (or Target because the UE has moved between tracking areas or between eNodeBs.
  • MME specifies the relocation procedure. Specifically, as the UE in the idle state (ie, EPS Connection Management (ECM) -IDLE state) moves from the tracking area under the jurisdiction of Old MME to the tracking area under the jurisdiction of New MME, In the TAU procedure, the mobility management and bearer management of the UE are relocated from the Old MME to the New MME.
  • ECM EPS Connection Management
  • the UE in the connected state moves from the Source “eNodeB” controlled by the Source “MME” to the Target “eNodeB” controlled by the Target “MME”
  • the mobility of the UE in the S1-based Handover procedure Management and bearer management are relocated from Source MME to Target MME.
  • one of the objects that the embodiments disclosed herein intend to achieve is to perform mobility management and bearer management of a plurality of mobile terminals (eg, UEs) attached to the core network. It is to provide an apparatus, a method, and a program that contribute to enabling relocation between network nodes (eg, MME) regardless of movement. It should be noted that this object is only one of a plurality of objects that the embodiments disclosed herein intend to achieve. Other objects or problems and novel features will become apparent from the description of the present specification or the accompanying drawings.
  • a method performed by a control node used in combination with a core network includes mobility management and bearer management of a plurality of mobile terminals that are arranged in the core network and attached to the core network. Sending a relocation indication message for the first network node to perform.
  • the relocation indication message causes relocation of the mobility management and the bearer management for at least one of the plurality of mobile terminals from the first network node to at least one second network node.
  • a method performed by a network node arranged in a core network includes (a) performing mobility management and bearer management of a plurality of mobile terminals already attached to the core network; Receiving a relocation indication message from a control node coupled to a core network, and at least one of the plurality of mobile terminals from the network node to at least one other node in the core network according to the relocation indication message Relocation of the mobility management and the bearer management for one.
  • a control node used in conjunction with a core network includes a memory and a processor coupled to the memory and configured to perform the method according to the first aspect described above.
  • a network node located in the core network includes a memory and a processor coupled to the memory and configured to perform the method according to the second aspect described above.
  • the program includes a group of instructions (software code) for causing the computer to perform the method according to the first aspect when read by the computer.
  • the program includes a group of instructions (software code) for causing the computer to perform the method according to the second aspect described above when read by the computer.
  • the mobility management and bearer management of a plurality of mobile terminals (eg, UEs) attached to the core network can be relocated between network nodes (eg, MME) regardless of the movement of these mobile terminals. It is possible to provide an apparatus, a method, and a program that contribute to the above.
  • FIG. 1 shows a configuration example of a mobile communication network according to the present embodiment.
  • the mobile communication network provides communication services such as voice communication and / or packet data communication.
  • the mobile communication network will be described as EPS (that is, Long Term Evolution (LTE) system or LTE-Advanced system).
  • the network shown in FIG. 1 includes E-UTRAN 110 and EPC 120.
  • the E-UTRAN 110 includes a mobile terminal (UE) 111 and an eNodeB 112.
  • the EPC 120 includes a source MME 121S, a target MME 121T, a Home / Subscriber / Server (HSS) 122, an S-GW 123, and a P-GW 124.
  • HSS Home / Subscriber / Server
  • the source MME 121S, the target MME 121T, and the HSS 122 are control plane nodes or entities.
  • the source MME 121S and the target MME 121T can perform mobility management and bearer management of a plurality of UEs (UEs) including the UE 111.
  • mobility management is used to keep track of the UE's current location (keep track) and includes maintaining a mobility management context (MM context) for the UE.
  • Bearer management includes controlling the EPS bearer establishment and maintaining an EPS bearer context for the UE.
  • the HSS 122 manages subscriber information of UEs including the UE 111.
  • the S-GW 123 and the P-GW 124 are user plane packet transfer nodes, and transfer user data (that is, Internet Protocol (IP) packets).
  • the S-GW 123 is a gateway to the E-UTRAN 110, and is connected to the eNodeB 112 via the S1-U interface.
  • the P-GW 124 is a gateway to the Packet Data Network (PDN) 130 and is connected to the PDN 130 via the SGi interface.
  • the PDN 130 may be an external network such as the Internet, or may be a network for an IP service (e.g., IP Multimedia Subsystem (IMS) service) provided by an operator who manages the EPC 120.
  • IP IP Multimedia Subsystem
  • the source MME 121S is connected to the control node 142 arranged outside the EPC 120 via the control interface 141.
  • the control node 142 is, for example, an SDN controller, an NFV controller, an OSS, an EMS, or any combination thereof.
  • the source MME 121S is configured to relocate the mobility management and bearer management of UEs attached to the EPC 120 (that is, UEs in the EMM-REGISTERED state) to the target MME 121T according to an instruction from the control node 142.
  • the source MME 121S can relocate the mobility management and bearer management of the UE 111 to the target MME 121T regardless of whether or not the UE 111 moves between cells or between tracking areas.
  • Relocation of mobility management and bearer management means that the target MME 121T performs maintenance of MM context and EPS Bearer context instead of the source MME 121S.
  • FIG. 2 is a sequence diagram illustrating a specific example of the mobility management context and bearer context relocation procedure according to the present embodiment.
  • the source MME 121S performs mobility management and bearer management of UEs already attached to the EPC 120 (that is, UEs in EMM-REGISTERED state).
  • the control node 142 transmits a context relocation instruction (Context Relocation Command) message to the source MME 121S.
  • the relocation indication message causes the mobility management and bearer management relocation for UEs from the source MME 121S to the at least one target MME 121T.
  • the relocation instruction message includes a relocation policy indicating an identifier of at least one target MME 121T.
  • the identifier of the target MME 121T may be, for example, Globally Unique MME Identity (GUMMEI), MME Identifier (MMEI), or MME Code (MMEC).
  • GUMMEI is used to uniquely identify an MME globally, and is composed of Public Land Mobile Network Identifier (PLMN ID) and MMEI.
  • PLMN ID Public Land Mobile Network Identifier
  • MMEGI MME Group Identifier
  • MMEC is an 8-bit code used to uniquely identify an MME within one MME group.
  • the relocation policy may indicate the throughput of mobility management and bearer management to be relocated from the source MME 121S to at least one target MME 121T.
  • the amount of processing for mobility management and bearer management may be specified as the number of UEs, the amount of processor resources used, the amount of memory resources used, the number of signaling occurrences, the amount of traffic, or any combination thereof.
  • the relocation policy may indicate a time constraint on the relocation. Specifically, the relocation policy may indicate a relocation start time, a relocation end time, or a period during which relocation execution is permitted.
  • the relocation policy may indicate which of the plurality of signaling procedures should be used when a plurality of signaling procedures can be used to perform relocation from the source MME 121S to the target MME 121T.
  • a plurality of signaling procedures include, for example, a procedure in which the amount of signaling is suppressed, a procedure in which relocation can be completed in a short time with a large amount of signaling, a procedure in which only UEs in an idle state (ECM-IDLE state) are targeted for relocation, and a connected state ( It may include a procedure for relocating a UE in ECM-CONNECTED state.
  • ECM-IDLE state idle state
  • It may include a procedure for relocating a UE in ECM-CONNECTED state.
  • control node 142 may acquire the load of the source MME 121S, determine the necessity of relocation based on the load of the source MME 121S, and determine the relocation policy based on the load of the source MME 121S.
  • the source MME 121S starts a signaling procedure for relocating mobility management and bearer management to the target MME 121T according to the relocation policy indicated in the relocation instruction message.
  • a specific example of the signaling procedure will be described later.
  • step S14 the source MME 121S transmits a context relocation complete (Context Relocation Complete) message to the control node 142 indicating that the relocation has been completed.
  • a context relocation complete Context Relocation Complete
  • step S15 the target MME 121T executes the mobility management and bearer management taken over from the source MME 121S, and maintains the MM context and EPS bearer context of the UEs.
  • the control node 142 is configured to transmit a relocation instruction message to the source MME 121S. Furthermore, the source MME 121S is configured to relocate the mobility management and bearer management of the UE 111 to the target MME 121T according to the relocation instruction message received from the control node 142. Therefore, according to the present embodiment, the target MME 121T can relocate the mobility management and bearer management of the UE 111 to the target MME 121T regardless of whether or not the UE 111 moves between cells or between tracking areas.
  • control node 142 may instruct relocation to the source MME 121S or the target MME 121T via another control node (mediation node).
  • the control node 142 transmits a relocation instruction message regarding the source MME 121S to another control node (mediation node), and the other control node (mediation node) instructs relocation to the source MME 121S or the target MME 121T based on the relocation instruction message.
  • another control node (mediation node) may generate setting information for the source MME 121S and the target MME 121T according to the relocation instruction message received from the control node 142, and the control that can be decoded by the source MME 121S and the target MME 121T.
  • a message may be generated.
  • the control node 142 may be an OSS, an SDN controller, or an NFV controller
  • the other control node (mediation node) may be an EMS.
  • the relocation procedure for mobility management and bearer management from the source MME 121S to the target MME 121T may involve relocation (or change) of the S-GW.
  • the relocation of S-GW means that the path of the EPS bearer of UE 111 managed by the source MME 121S (that is, the termination point of S1 bearer and S5 / S8 bearer) is changed from S-GW123 to another S-GW. To do.
  • the target MME 121T may spontaneously select an S-GW based on the S-GW selection function that the target MME 121T has.
  • the relocation destination S-GW (referred to as target S-GW) may be designated by the control node 142. That is, the control node 142 may include the designation of the target S-GW in the context relocation instruction message transmitted to the source MME 121S.
  • the source MME 121S may inform the target MME 121T of the address of the target S-GW in the relocation procedure (step S13 in FIG. 2).
  • FIGS. 3A and 3B show an example of a signaling procedure for relocation.
  • the procedure of FIGS. 3A and 3B can be performed in step S13 of FIG. That is, the source MME 121S may initiate the signaling procedure shown in FIGS. 3A and 3B in response to receiving the context relocation indication message from the control node 142.
  • the signaling procedure shown in FIGS. 3A and 3B starts when the UE 111 is in the connected state (ECM-CONNECTED state).
  • step S101 the source MME 121S transmits the MM context and EPS bearer context of the UE 111 to the target MME 121T.
  • a GPRS Tunnelling Protocol for the Control Plane (GTP-C) message transmitted at the S10 interface between MMEs can be used.
  • GTP-C GPRS Tunnelling Protocol for the Control Plane
  • a Forward Relocation Request message or a modified version thereof may be used.
  • the Forward Relocation Request message is a message transmitted from the source MME to the target MME in the S1-based handover procedure.
  • the Forward Relocation Request message in step S101 may include an information element indicating that the message is transmitted for Context Relocation instead of S1-based handover.
  • the target MME 121T stores the MM context and EPS bearer context of the UE 111 received from the source MME 121S in its own memory or storage (not shown). Further, the target MME 121T requests the S-GW 123 to update the EPS bearer context of the UE111 held in the S-GW123 in response to the reception of the MM context and the EPS bearer context of the UE111.
  • This request indicates the new MME that manages the EPS bearer of the UE 111, that is, the IP address and MME TEID of the target MME 121T.
  • This request can be transmitted using a GTP-C message transmitted on the S11 interface between the MME 121T and the S-GW 123. For example, as shown in FIG. 3A, a Modify Bearer Request message or a modified version thereof may be used.
  • step S103 the S-GW 123 updates the MME IP address and MME TEID held for the EPS bearer context of the UE 111, and transmits a response message (for example, Modify Bearer Response message) to the target MME 121T.
  • a response message for example, Modify Bearer Response message
  • step S104 the target MME 121T notifies the source MME 121S that it has accepted the handover of the mobility management and bearer management of the UE 111.
  • a GTP-C message transmitted on the S10 interface between the MMEs can be used.
  • a Forward Relocation Response message or a modified version thereof may be used.
  • a Forward Relocation Complete Notification message or a modified version thereof may be used.
  • the notification message in step S104 includes a temporary identifier assigned to the UE 111 by the target MME 121T, that is, MME Mobile Subscriber Identity (M-TMSI), SAE Temporary Mobile Subscriber Identity (S-TMSI), or Globally Unique Temporary UE Identity (GUTI).
  • M-TMSI MME Mobile Subscriber Identity
  • S-TMSI SAE Temporary Mobile Subscriber Identity
  • GUI Globally Unique Temporary UE Identity
  • M-TMSI is a unique temporary identifier within one MME (target MME 121T).
  • S-TMSI is a temporary identifier that is unique within one MME group, and is composed of MMEC and M-TMSI.
  • GUTI is a globally unique temporary identifier and is composed of GUMMEI and M-TMSI.
  • step S105 the source MME 121S transmits an acknowledge message for the message in step S104 to the target MME 121T.
  • the GTP-C message transmitted on the S10 interface between the MMEs can be used for transmitting the approval message.
  • the acknowledgment message may be a Forward Relocation Complete Acknowledge message or a modified version thereof.
  • Steps S106 to S109 are performed to notify the HSS 122 of the MME change. Steps S106 to S109 may be the same as the procedure for notifying the HSS of the MME change in the normal TAU procedure. The change of MME can also be notified to the HSS 122 in a normal TAU procedure performed after the relocation procedure shown in FIGS. 3A and 3B is completed. Therefore, steps S106 to S109 may be omitted.
  • step S106 the target MME 121T transmits a message for notifying the HSS 122 of the change of the MME related to the UE 111.
  • a Diameter message transmitted on the S6a interface between the MME 121T and the HSS 122 can be used.
  • an Update Location Request message may be used, similar to a normal TAU procedure.
  • the HSS 122 transmits a Cancel location message to the source MME 121S in order to notify that the MM context and the EPS bearer context regarding the UE 111 can be deleted.
  • the Cancel-Location message indicates the UE 111 International Mobile Subscriber Identity (IMSI).
  • the source MME 121S deletes the MM context and EPS bearer context related to the UE 111 as necessary. Then, the source MME 121S transmits a Cancel ⁇ Location Ack message to the HSS 122.
  • the Cancel-Location-Ack message indicates the International Mobile-Subscriber Identity (IMSI) of the UE 111.
  • the HSS 122 approves Update Location Request by sending an Update Location Ack message to the target MME 121T.
  • step S110 in order to start signaling related to the UE 111 between the eNodeB 112 and the target MME 121T, the target MME 121T notifies the eNodeB 112 of the MME UE S1AP ID assigned by the target MME 121T.
  • This notification may be sent using an S1AP message sent on the S1-MME interface between the target MME 121T and the eNodeB 112.
  • the target MME 121T may use, for example, a modified Handover Request message, an improved E-RAB Modify Request message, or an improved UE Context Modification Request message.
  • step S111 the eNodeB 112 transmits an acknowledge message for the message in step S110 to the target MME 121T.
  • an S1AP message transmitted through the S1-MME interface can be used for the transmission of the approval message.
  • the approval message may be a Handover Request Ack message, an E-RAB Modify Response message, a UE Context Modification Response message, or a modified version thereof.
  • the source MME 121S notifies the UE 111 of the ID of the new MME after relocation (that is, the target MME 121T). Furthermore, the source MME 121S notifies the UE 111 of the temporary identifier assigned to the UE 111 by the target MME 121T. Specifically, the source MME 121S may inform the UE 111 of the GUTI composed of the GUMMEI of the target MME 121T and the M-TMSI assigned to the UE 111 by the target MME 121T.
  • the source MME 121S may operate as follows. First, after the target MME 121T receives the message in step S111, the source MME 121S is notified that the relocation has been completed using, for example, a Handover command message (or a message between other MMEs), and then the source MME 121S notifies The message of step S112 may be transmitted after receiving.
  • a Handover command message or a message between other MMEs
  • a Non-Access Stratum (NAS) message may be used.
  • the NAS message is transmitted and received transparently between the UE 111 and the MME 121S without being terminated by the E-UTRAN 110.
  • NAS Non-Access Stratum
  • a GUTI Reallocation Command message may be used.
  • a new NAS message may be defined and used.
  • step S113 the UE 111 receives a new GUTI assigned by the target MME 121T from the source MME 121S. Then, the UE 111 updates the registered MME information managed by the UE 111 using the new GUTI. The UE 111 transmits a NAS message (e.g., “GUTI” Reallocation ”Complete message) indicating that the reception of GUTI is completed to the source MME 121S.
  • the registered MME information updated to indicate the target MME 121T is used in subsequent transmissions of RRC messages and NAS messages (TAU Request, Service Request, etc.).
  • the source MME 121S that has received the NAS message (e.g., “GUTI” Reallocation ”Complete message) in step S113 may notify the target MME 121T that the relocation notification to the UE 111 is completed.
  • the source MME 121S may notify the eNodeB 112 of the MME UE S1AP ID assigned by the target MME 121T.
  • the target MME 121T may notify the UE 111 of the ID (e.g., GUMMEI) or the UE temporary identifier (e.g., GUTI) of the target MME 121T instead of the source MME 121S.
  • the ID e.g., GUMMEI
  • the UE temporary identifier e.g., GUTI
  • information on the security key (Security Key) (for example, KeNB, KeNB *, Next Hop Chaining Count (NHCC), Next-Hop (NH)) may be reused without updating (NH)) that was used when the UE 111 belonged to the source MME 121S (registration).
  • the source MME 121S (or the target MME 121T) may derive information on a new Security Key as in the case of handover, and notify the UE 111 via the eNodeB 112.
  • the source MME 121S When reusing without updating the information about Security Key, in step S112, the source MME 121S sends a NAS: GUTI Reallocation Command message (or a new NAS message) to the eNodeB 112 with an S1AP message, and the eNodeB 112 receives the GUTI Reallocation Command message. May be transmitted to the UE 111 with an RRC Connection Reconfiguration message.
  • the source MME 121S transmits a NAS: GUTI Reallocation Command message (or a new NAS message) to the eNodeB 112 using an S1AP message, and the eNodeB 112 sends the GUTI Reallocation Command message to mobilityControlInfo IE. May be transmitted to the UE 111 with an RRC Connection Reconfiguration message.
  • the target MME 121T may notify the UE 111 of a new GUTI instead of the source MME 121S.
  • the source MME 121S may transmit a GUTI Reallocation Command message indicating a new GUTI to the UE 111.
  • the UE 111 may transmit a NAS message (e.g., GUTI Reallocation Complete message) indicating that reception of GUTI is completed to the target MME 121T in step S113.
  • a NAS message e.g., GUTI Reallocation Complete message
  • the configuration example of the mobile communication network according to the present embodiment may be the same as that shown in FIG. 1 described with respect to the first embodiment.
  • the sequence diagram of FIG. 4 shows an example of a signaling procedure for relocation.
  • the procedure of FIG. 4 can be performed in step S13 of FIG. That is, the source MME 121S may start the signaling procedure shown in FIG. 4 in response to receiving the context relocation indication message from the control node 142.
  • the signaling procedure shown in FIG. 4 is started when the UE 111 is in an idle state (ECM-IDLE state).
  • ECM-IDLE state idle state
  • the source MME 121S uses a Network triggered Service Request procedure to notify the UE 111 of the relocation.
  • step S201 the source MME 121S transmits a paging message to a plurality of eNodeBs including the eNodeB 112 located in the tracking area of the UE 111 (S1AP: Paging).
  • step S202 the eNodeB 112 receives S1AP Paging, creates RRC: Paging message, and transmits RRC: Paging message in Paging control channel (PCCH), Paging channel (PCH), and Physical downlink shared channel (PDSCH).
  • This RRC: “Paging” message is addressed to the temporary identifier (ie, S-TMSI) assigned to the UE by the source MME 121S.
  • step S203 the UE 111 starts a UE triggered Service Request procedure in response to receiving the paging.
  • the UE 111 Upon completion of step S203, the UE 111 enters a connected state (ECM-CONNECTED state).
  • step S204 the source MME 121S starts the relocation procedure in which the UE 111 corresponds to the connected state (ECM-CONNECTED state).
  • step S204 the source MME 121S may perform the procedure shown in FIGS. 3A and 3B.
  • the mobility management and bearer management of the UE 111 in the idle state (ECM-IDLE state) can be relocated.
  • the configuration example of the mobile communication network according to the present embodiment may be the same as that shown in FIG. 1 described with respect to the first embodiment.
  • the sequence diagram of FIG. 5 shows an example of a signaling procedure for relocation.
  • the procedure of FIG. 5 can be performed in step S13 of FIG. That is, the source MME 121S may start the signaling procedure shown in FIG. 5 in response to receiving the context relocation instruction message from the control node 142.
  • the signaling procedure shown in FIG. 5 is started when the UE 111 is in an idle state (ECM-IDLE state).
  • ECM-IDLE state idle state
  • the source MME 121S uses the paging procedure to send a UE temporary identifier (ie, S-TMSI or GUTI) including the ID of the target MME 121T (ie, GUMMEI, MMEI, or MMEC) to the idle UE 111.
  • a UE temporary identifier ie, S-TMSI or GUTI
  • the ID of the target MME 121T ie, GUMMEI, MMEI, or MMEC
  • step S221 the source MME 121S relocates the mobility management service and bearer management service of the UE 111 that has been attached to the EPC 120 (i.e., “EMM-REGISTERED” state) to the target MME 121T.
  • the procedure performed in step S221 may be the same as the procedure performed in steps S101 to S105 in FIG. 3A.
  • step S222 the target MME 121T notifies the HSS 122 of the change of the MME.
  • the procedure performed in step S222 may be the same as the procedure for notifying HSS of the MME change in the normal TAU procedure, that is, similar to the procedure performed in steps S106 to S109 in FIG. 3A. Also, step S222 may be omitted as described with respect to steps S106 to S109 in FIG. 3A.
  • the source MME 121S notifies the UE 111 of the ID of the new MME after relocation (that is, the target MME 121T) and the UE temporary identifier assigned to the UE 111 by the target MME 121T.
  • the source MME 121S may inform the UE 111 of the GUTI assigned to the UE 111 by the target MME 121T.
  • paging is used to inform the UE 111 of a new GUTI.
  • the source MME 121S transmits a paging message to a plurality of eNodeBs in the tracking area including the eNodeB 112 (S1AP: Paging).
  • the paging message indicates a new GUTI assigned to the UE 111 by the target MME 121T, with the temporary identifier (ie, S-TMSI) assigned to the UE by the source MME 121S as the destination.
  • the eNodeB 112 receives S1AP Paging, creates RRC: Paging message, and transmits RRC: Paging message in Paging control channel (PCCH), Paging channel (PCH), and Physical downlink shared channel (PDSCH).
  • This RRC: Paging message indicates a GUTI assigned to the UE 111 by the target MME 121T with the temporary identifier (ie, S-TMSI) assigned to the UE by the source MME 121S as the destination.
  • the UE111 receives the paging message of step S224, and updates the registered MME information managed by itself using the new GUTI assigned by the target MME121T.
  • the registered MME information updated to indicate the target MME 121T is used in subsequent transmissions of RRC messages and NAS messages (TAU Request, Service Request, etc.). For example, as shown in steps S225 to S227 of FIG. 5, the UE 111 receives the Service_Request message and the GUTI assigned by the target MME 121T in the procedure for establishing the RRC connection for transmitting the Service / Request message, or derived from this.
  • a new information element eg, relocationIndication
  • the eNodeB 112 enables the relocationIndication.
  • relocatioIndication indicates a GUTI newly assigned to the UE 111 by the target MME 121T.
  • 21 and 22 show a specific example of the configuration of the Paging message expanded to include the relocatioIndication indicating the GUTI allocated by the target MME 121S.
  • FIG. 21 shows that the eNodeB transmits a Paging message including relocationIndication-rXYZ only to the UE to be relocated, that is, the IE is set to True.
  • the UE checks whether the relocationIndication-rXYZ is included, and includes the relocationIndication-rXYZ If so, perform the relocation procedure described above.
  • FIG. 22 shows an example in which the eNodeB instructs the relocation to one or more UEs to be relocated all at once.
  • the Paging message may be used as a Paging message only for relocation.
  • the eNodeB includes the Paging UE-Identity (list thereof) of the UE to be relocated in the Paging message, and includes the relocationIndication-rXYZ in the Paging message (that is, set to True) and transmits the Paging message.
  • relocationIndication-rXYZ when the PagingUE-Identity (for example, s-TMSI) notified by Paging message matches that assigned to the UE, the UE checks whether or not relocationIndication-rXYZ is included, and relocationIndication If -rXYZ is included, perform the relocation procedure described above. 21 and FIG. 22, “relocationIndication” postfix “-rXYZ” means the release number of the specification in which the IE is defined, and is shown for convenience of explanation. Therefore, relocationIndication-rXYZ has the same meaning as relocationIndication in the above description.
  • the UE 111 transmits an RRCeConnection Request message indicating the S-TMSI derived from the new GUTI assigned by the target MME 121T as UE Identity to the eNodeB 112 in the RRC connection establishment procedure.
  • the UE 111 transmits an RRCeConnection Setup Complete message indicating the GUMMEI derived from the new GUTI as Registered MME information to the eNodeB 112 in the RRC connection establishment procedure.
  • This RRC Connection Setup Complete message encapsulates a NAS message, in this case, a Service Request message.
  • step S227 the eNodeB 112 extracts the Service request message from the RRC Connection Setup message, selects the target MME 121T based on the S-TMSI received in Step S225, and includes the S1AP: Service Initial including the Service Request message and S-TMSI.
  • UE Message is sent to the target MME 121T.
  • the procedure of FIG. 5 may be modified so that the target MME 121T transmits the paging message in step S223 instead of the source MME 121S.
  • the configuration example of the mobile communication network according to the present embodiment may be the same as that shown in FIG. 1 described with respect to the first embodiment.
  • the sequence diagram of FIG. 6 shows an example of a signaling procedure for relocation.
  • the procedure of FIG. 6 can be performed in step S13 of FIG. That is, the source MME 121S may start the signaling procedure shown in FIG. 6 in response to receiving the context relocation indication message from the control node 142.
  • the signaling procedure shown in FIG. 6 is started when the UE 111 is in an idle state (ECM-IDLE state).
  • ECM-IDLE state idle state
  • the source MME 121S uses the Network triggered Service Request procedure to inform the UE 111 of the relocation.
  • steps S241 and S242 are the same as the procedure performed in steps S221 and S222 in FIG. Step S242 may be omitted.
  • step S243 the source MME 121S starts a Network-triggered Service request procedure in order to signal the UE 111 in an idle state. That is, in step S243, the source MME 121S transmits a paging message to a plurality of eNodeBs including the eNodeB 112 located in the tracking area of the UE 111 (S1AP: Paging). In step S244, the eNodeB 112 receives S1AP Paging and transmits RRC: Paging message. This RRC: “Paging” message is addressed to the temporary identifier (ie, S-TMSI) assigned to the UE by the source MME 121S.
  • S-TMSI temporary identifier
  • step S245 the UE 111 starts a UE triggered Service Request procedure in response to receiving the paging. Upon completion of step S245, the UE 111 enters a connected state (ECM-CONNECTED state).
  • the source MME 121S notifies the UE 111 of the ID of the new MME after relocation (that is, the target MME 121T). Furthermore, the source MME 121S notifies the UE 111 of the temporary identifier assigned to the UE 111 by the target MME 121T. Specifically, the source MME 121S may inform the UE 111 of the GUTI assigned to the UE 111 by the target MME 121T.
  • a NAS message may be used. For example, as shown in FIG. 6, a GUTI Reallocation Command message may be used. Alternatively, a new NAS message may be defined and used.
  • step S247 the UE 111 receives a new GUTI allocated by the target MME 121T from the source MME 121S. Then, the UE 111 updates the registered MME information managed by the UE 111 using the new GUTI. The UE 111 transmits a NAS message (e.g., “GUTI” Reallocation ”Complete message) indicating that the reception of GUTI is completed to the source MME 121S.
  • the registered MME information updated to indicate the target MME 121T is used in subsequent transmissions of RRC messages and NAS messages (TAU Request, Service Request, etc.).
  • the source MME 121S may delete the context regarding the UE 111 held by the source MME 121S on condition that the NAS message is received from the UE 111 in step S247.
  • the target MME 121T performs the transmission of the paging message in step S243 and the notification to the GUTI UE in step S246 instead of the source MME 121S.
  • the procedure of FIG. 6 may be modified to notify the UE 111 of the relocation when the Service request message is received from the UE 111 in the UE triggered Service request procedure without starting paging by the source MME 121S or the target MME 121T.
  • the source MME 121S receives the Service Request message from the UE 112, and the UE continues to hold the 111 context until the relocation (GUTI allocated by the target MME 121T) notification to the UE 111 is completed.
  • FIG. 7 shows an example of a signaling procedure for relocation.
  • the procedure of FIG. 7 can be performed in step S13 of FIG. That is, the source MME 121S may start the signaling procedure shown in FIG. 7 in response to receiving the context relocation instruction message from the control node 142.
  • the procedure of FIG. 7 can be performed in step S13 of FIG. That is, the source MME 121S may start the signaling procedure shown in FIG. 7 in response to receiving the context relocation instruction message from the control node 142.
  • the source MME 121 ⁇ / b> S transmits the ID of the target MME 121 ⁇ / b> T (that is, GUMMEI, MMEI, or MMEC) to the UE 111 during the MME-initiated Detach procedure.
  • step S301 the source MME 121S transmits a Detach request message to the UE 111.
  • the Detach Request message includes the ID of the target MME 121T.
  • the ID of the target MME 121T may be GUMMEI, MMEI, or MMEC.
  • step S302 MME-initiated Detach procedure is performed following transmission of the Detach Request message in step S301.
  • UE 111 extracts the ID or UE temporary identifier (e.g., GUMMEI, MMEI, or MMEC) of the target MME 121T from the Detach Request message and saves it.
  • the ID or UE temporary identifier of the target MME 121T extracted from the Detach Request message is used when transmitting the RRC message and NAS message (Attach Request) in the next attach procedure.
  • Steps S303 to S306 show a procedure for the UE 111 to attach to the EPC 120 again.
  • the UE 111 transmits an RRC Connection Request message indicating a random value as UE Identity to the eNodeB 112 in the RRC connection establishment procedure.
  • the UE 111 transmits an RRC ConnectionBSetup Complete message indicating the GUMMEI of the target MME 121T as Registered MME information to the eNodeB 112 in the RRC connection establishment procedure.
  • the RRC Connection Setup Complete message encapsulates the NAS message, that is, the Attach Request message here.
  • step S305 the eNodeB 112 extracts the Attach Request message from the RRC Connection To Setup Complete message, selects the target MME 121T based on the GUMMEI included in the RRC Connection Setup Complete message, and selects the S1AP: Initial UE UE Message including the Attach Request message as the target MME 121T. Send to.
  • step S306 following the transmission of the Attach Request message in step S305, Attach procedure is performed.
  • the RRC Connection Setup Complete message in step S304 clearly indicates that MME selection based on the MME selection function is unnecessary. May also be shown.
  • the mobility management and bearer management of the UE 111 can be taken over by the target MME 121T by reattaching the UE 111 once detached from the EPC 120.
  • FIG. 8 shows an example of a signaling procedure for relocation.
  • the procedure of FIG. 8 can be performed in step S13 of FIG. That is, the source MME 121S may start the signaling procedure shown in FIG. 8 in response to receiving the context relocation instruction message from the control node 142.
  • the signaling procedure shown in FIG. 8 is started when the UE 111 is in an idle state (ECM-IDLE state).
  • ECM-IDLE state idle state
  • the source MME 121S operates to return a Service Reject message to the Service Request message from the UE 111 in order to notify the UE 111 of the relocation.
  • steps S321 and S322 are the same as the procedure performed in steps S221 and S222 in FIG. Step S322 may be omitted.
  • the source MME 121S receives a Service request message from the UE 111.
  • the source MME 121S returns a Service Reject message in response to receiving the Service Request message.
  • the Service Reject message indicates an identifier (e.g., GUMEI, MMEI, or MMEC) of the target MME 121T or a new temporary UE identifier (e.g., S-TMSI or GUTI) assigned to the UE 111 by the target MME 121T.
  • the UE111 receives the Service Reject message. Then, the UE 111 updates the registered MME information managed by the UE 111 with new GUMEI and GUTI notified by using the Service Reject message.
  • the registered MME information updated to indicate the target MME 121T is used in subsequent transmissions of RRC messages and NAS messages (Attach request, TAU request, Service request, etc.).
  • the UE 111 that has received the Service Reject message starts the Attach procedure.
  • the procedure performed in steps S325 to S327 is the same as the procedure performed in steps S303 to S305 in FIG.
  • the procedure of FIG. 8 may be modified so that the source MME 121S pages the UE 111 in order to prompt the UE 111 to transmit the Service request message (step S323).
  • the procedure of FIG. 8 notifies the UE 111 of the target MME 121T identifier (eg, GUMEI, MMEI, or MMEC) or a new UE temporary identifier (eg, S-TMSI or GUTI) assigned to the UE 111 by the target MME 121T.
  • the target MME 121T identifier eg, GUMEI, MMEI, or MMEC
  • a new UE temporary identifier eg, S-TMSI or GUTI
  • the procedure of FIG. 8 may be modified so that the UE 111 starts the Service request procedure instead of the Attach procedure when receiving the Service message or a NAS message instead.
  • FIG. 9 shows an example of a signaling procedure for relocation.
  • the procedure of FIG. 9 can be performed in step S13 of FIG. That is, the source MME 121S may start the signaling procedure shown in FIG. 9 in response to receiving the context relocation instruction message from the control node 142.
  • the procedure of FIG. 9 can be performed in step S13 of FIG. That is, the source MME 121S may start the signaling procedure shown in FIG. 9 in response to receiving the context relocation instruction message from the control node 142.
  • the source MME 121S transmits a UE temporary identifier (that is, S-TMSI or GUTI) including the ID of the target MME 121T (that is, GUMMEI, MMEI, or MMEC) to the UE 111 during the S1 Release procedure. .
  • a UE temporary identifier that is, S-TMSI or GUTI
  • the ID of the target MME 121T that is, GUMMEI, MMEI, or MMEC
  • step S401 the source MME 121S transmits a ReleaseReAccess Bearers Request message to the S-GW 123 requesting release of all S1-U bearers for the UE 111.
  • step S402 the S-GW 123 releases all information related to the eNodeB for the UE 111 (that is, information related to the S1-U bearer), and transmits a ReleaseReAccess Bearers Response message to the source MME 121S.
  • steps S403 and S404 are the same as the procedure performed in steps S221 and S222 in FIG. Step S404 may be omitted.
  • the source MME 121S notifies the UE 111 of the ID of the new MME after relocation (that is, the target MME 121T) and the UE temporary identifier assigned to the UE 111 by the target MME 121T.
  • the source MME 121S may inform the UE 111 of the new GUTI assigned to the UE 111 by the target MME 121T.
  • an RRC message that is, RRC: RRC Connection Release message transmitted from the eNodeB 112 for releasing the RRC connection is used.
  • step S405 the source MME 121S transmits an S1AP: S1 UE Context Release Command message to the eNodeB 112 to which the UE 111 in the connected state (ECM-CONNECTED state) is currently connected.
  • This S1 UE Context Release Command message indicates a new GUTI assigned to the UE 111 by the target MME 121T.
  • step S406 the eNodeB 112 transmits an RRC Connection Release message to the UE 111.
  • This RRC Connection Release message indicates a new GUTI assigned by the target MME 121T.
  • the UE 111 receives the RRC Connection Release message in step S406 and updates the registered MME information managed by itself using the new GUTI assigned by the target MME 121T.
  • the registered MME information updated to indicate the target MME 121T is used in subsequent transmissions of RRC messages and NAS messages (TAU Request, Service Request, etc.).
  • the UE 111 uses the GUTI allocated by the target MME 121T in the procedure for establishing the TAUGURequest message and the RRC connection for transmitting the TAUTARequest message, or the S- Use TMSI or GUMMEI.
  • step S407 the UE 111 transmits an RRC connection setup message indicating the GUMMEI derived from the new GUTI assigned by the target MME 121T as Registered MME information to the eNodeB 112 in the RRC connection establishment procedure.
  • the RRC Connection Setup Complete message encapsulates a NAS message, that is, a TAU Request message here.
  • the eNodeB 112 extracts the TAU Request message from the RRC Connection Setup Complete message, selects the target MME 121T based on the GUMMEI included in the RRC Connection Setup Complete message, and selects the S1AP: Initial Initial UE message including the TAU Request message as the target MME 121T. Send to.
  • mobility management and bearer management relocation has occurred for the UE 111 by modifying the existing S1 Release procedure and the message format of the S1 UE Context Release Command message and RRC Connection Release message. Can be informed.
  • the format of the RRC Connection Release message may be modified as shown in FIG. 23, for example. That is, FIG. 23 shows an example of a modified format of the RRC Connection Release message.
  • a cause value of relocationMME indicating (meaning) an instruction of MME relocation is added to ReleaseRecause of RRC Connection.
  • the UE 111 may perform the above operation when the Release cause of the RRC Connection Release message is set to relocationMME.
  • RelocationMME is an example, and may be MMErelocation, relocationRequired, re-registeredRequired, registrationUpdate, registrationUpdateRequired, GUTIupdate, GUTIupdateRequired, etc., as long as it indicates MME relocation.
  • FIGS. 10A and 10B show an example of a signaling procedure for relocation.
  • the procedure of FIGS. 10A and 10B can be performed in step S13 of FIG. That is, the source MME 121S may initiate the signaling procedure shown in FIGS. 10A and 10B in response to receiving the context relocation indication message from the control node 142.
  • the procedure of FIGS. 10A and 10B can be performed in step S13 of FIG. That is, the source MME 121S may initiate the signaling procedure shown in FIGS. 10A and 10B in response to receiving the context relocation indication message from the control node 142.
  • the source MME 121S performs a UE temporary identifier (ie, S-TMSI or GUTI) including the ID (ie, GUMMEI, MMEI, or MMEC) of the target MME 121T during the Tracking Area Update (TAU) procedure. ) To UE111.
  • a UE temporary identifier ie, S-TMSI or GUTI
  • ID ie, GUMMEI, MMEI, or MMEC
  • step S501 the UE 111 is registered in the source MME 121S and is in an idle state (ECM-IDLE state). Then, in response to the expiration of the periodic TAU timer (periodicMETAU ⁇ ⁇ timer), the UE 111 transmits a TAU Request message to the source MME 121S to inform the source MME 121S of the current Tracking Area Identity (TAI).
  • TAU Request message indicates “Periodic Updating” by its update type.
  • step S502 the source MME 121S performs integrity check of the TAU request message from the UE 111.
  • the integrity check fails, the source MME 121S performs Authentication and NAS Security Setup for the UE 111.
  • the source MME 121S transmits the MM context and EPS bearer context of the UE 111 to the target MME 121T.
  • a GTP-C message transmitted in the S10 interface between the MMEs can be used.
  • a Forward Relocation Request message or a modified version thereof may be used.
  • the Forward Relocation Request message in step S503 may include an information element indicating that it is a message transmitted for TAU with Context Relocation instead of S1-based handover.
  • the target MME 121T stores the MM context and EPS bearer context of the UE 111 received from the source MME 121S in its own memory or storage (not shown). Further, the target MME 121T requests the S-GW 123 to update the EPS bearer context of the UE111 held in the S-GW123 in response to the reception of the MM context and the EPS bearer context of the UE111.
  • This request can be transmitted using a GTP-C message transmitted on the S11 interface between the MME 121T and the S-GW 123. For example, as shown in FIG. 10A, a Modify Bearer Request message or a modified version thereof may be used.
  • the GTP-C message in Step S504 indicates the new MME that manages the EPS bearer of the UE 111, that is, the IP address and MME TEID of the target MME121T. Further, this request indicates the current location information of the UE 111 (that is, E-UTRAN Cell Global Identifier (ECGI) and Tracking Area Identity (TAI)).
  • ECGI E-UTRAN Cell Global Identifier
  • TAI Tracking Area Identity
  • the S-GW 123 receives the current location information (ECGI and TAI) of the UE 111 from the target MME 121T, and confirms whether the ECGI and TAI of the UE 111 have changed. If changed, the UE 111 transmits a Modify Bearer Request message to the P-GW 124 (step S505).
  • the P-GW 124 updates the current location information of the UE 111 included in the EPS bearer context of the UE 111, and transmits a Modify Bearer Response message to the S-GW 123 (step S506).
  • the S-GW 123 transmits a response message (for example, Modify Bearer Response message) to the target MME 121T.
  • Steps S507 to S511 are performed to notify the HSS 122 of the MME change.
  • the procedure of steps S507 to S511 may be the same as the procedure for notifying the HSS of the MME change in the normal TAU procedure, and thus may be the same as the procedure of steps S106 to S109 in FIG. 3A.
  • step S512 the target MME 121T notifies the source MME 121S that the handover of the mobility management and bearer management of the UE 111 has been accepted.
  • a GTP-C message transmitted on the S10 interface between the MMEs can be used.
  • a Forward Relocation Response message or a modified version thereof may be used.
  • a Forward Relocation Complete Notification message or a modified version thereof may be used.
  • the notification message in step S512 includes a temporary identifier assigned to the UE 111 by the target MME 121T, that is, M-TMSI, S-TMSI, or GUTI.
  • step S513 the source MME 121S transmits an acknowledge message for the message in step S512 to the target MME 121T.
  • the GTP-C message transmitted on the S10 interface between the MMEs can be used for transmitting the approval message.
  • the acknowledgment message may be a Forward Relocation Complete Acknowledge message or a modified version thereof.
  • the source MME 121S notifies the UE 111 of the ID of the new MME after relocation (that is, the target MME 121T) using the TAU Accept message. Furthermore, the source MME 121S notifies the UE 111 of the temporary identifier assigned to the UE 111 by the target MME 121T. Specifically, the source MME 121S may inform the UE 111 of the GUTI composed of the GUMMEI of the target MME 121T and the M-TMSI assigned to the UE 111 by the target MME 121T.
  • the UE 111 receives the TAU Accept message, extracts a new GUTI assigned by the target MME 121T from the TAU Accept message, and updates the registered MME information managed by itself by using the new GUTI.
  • the UE 111 transmits a TAU Complete message to the source MME 121S in order to notify that a new GUTI has been received.
  • the registered MME information updated to indicate the target MME 121T is used when transmitting RRC messages and NAS messages (TAU Request, Service Request, etc.) after step S515.
  • FIG. 11 shows an example of a signaling procedure for relocation.
  • the procedure of FIG. 11 can be performed in step S13 of FIG. That is, the source MME 121S may start the signaling procedure shown in FIG. 11 in response to the reception of the context relocation instruction message from the control node 142.
  • the source MME 121S or the target MME 121T is attached to the EPC 120 (ie, “EMM-REGISTERED” state) and is idle (ie, “ECM-IDLE” State).
  • ENodeB 112 is instructed to redirect to Then, the eNodeB 112 operates to redirect the NAS message received from the UE 111 together with the RRC message including the RRC parameter designating the source MME 121S to the target MME 121T according to the instruction from the source MME 121S or the target MME 121T.
  • steps S601 and S602 are the same as the procedure performed in steps S221 and S222 in FIG. Step S602 may be omitted.
  • the target MME 121T instructs the eNodeB 112 to redirect the NAS message addressed to the source MME 121S to the target MME 121T.
  • an S1AP message transmitted in the S1-MME interface between the MME 121T and the eNodeB 112 can be used.
  • a new message (S1AP: “Redirection” Command message) may be used.
  • the S1AP: Redirection Command message indicates the association between the source MME 121S and the target MME 121T.
  • the S1AP: Redirection Command message may include IDs (that is, GUMMEIs, MMEIs, or MMECs) of the source MME 121S and the target MME 121T.
  • IDs that is, GUMMEIs, MMEIs, or MMECs
  • an existing S1AP message e.g., MME Configuration Update message
  • a modified version thereof may be used.
  • ENodeB 112 receives the S1AP: “Redirection” Command message and sets the NAS message addressed to the source MME 121S to be redirected to the target MME 121T.
  • the eNodeB 112 transmits an S1AP message (S1AP: “Redirection” Complete message) for notifying that the redirect instruction has been received to the source MME 121S.
  • Steps S605 to S606 show operations when an RRC Connection Setup message encapsulating the NAS: TAU Request message is received. That is, the eNodeB 112 receives the RRC Connection Setup Complete message including the RRC parameter that specifies the GUMMEI of the source MME 121S (step S506). Next, the eNodeB 112 extracts a TAU request message from the RRC Connection Setup message, and determines that the GUMMEI of the source MME 121S included in the RRC Connection Setup message is associated with the GUMMEI of the target MME 121 for redirection. To do. Then, the eNodeB 112 selects the target MME 121T and transmits S1AP: Initial UE Message including the TAU Request message to the target MME 121T (step S606).
  • FIG. 3 The above-described relocation procedure shown in FIG. 3 (FIGS. 3A and 3B) to FIG. 10 (FIGS. 10A and 10B) is executed in units of UEs. Therefore, although the amount of signaling is large compared to the procedure of FIG. 11, the relocation procedure of FIG. 3 (FIGS. 3A and 3B) to FIG. 10 (FIGS. 10A and 10B) has the load to relocate from the source MME 121S to the target MME 121T in UE units. There are advantages that can be adjusted. On the other hand, the relocation procedure of FIG. 11 collectively transfers the mobility management and bearer management of all UEs performed by the source MME 121S to the target MME 121T. However, the signaling amount of the relocation procedure of FIG.
  • FIG. 11 can be expected to be smaller than that of the relocation procedure of FIG. 3 (FIGS. 3A and 3B) to FIG. 10 (FIGS. 10A and 10B). Furthermore, according to the procedure of FIG. 11, it is not necessary to notify the UE 111 of the relocation of mobility management and bearer management, and the relocation can be completed in the EPC 120 and the eNodeB 112. Therefore, the procedure in FIG. 11 has an advantage that mobility management and bearer management relocation can be performed without adding a new function to the UE 111.
  • FIG. 11 shows an example in which the target MME 121T instructs the eNodeB 112 to redirect.
  • the source MME 121S may instruct the eNodeB 112 to redirect instead of the target MME 121T.
  • FIG. 12 shows an example of a signaling procedure for relocation.
  • the procedure of FIG. 12 can be performed in step S13 of FIG. That is, the source MME 121S may start the signaling procedure shown in FIG. 12 in response to receiving the context relocation instruction message from the control node 142.
  • the source MME 121S is attached to the EPC 120 (ie, “EMM-REGISTERED” state) and is idle (ie, “ECM-IDLE” State) from the UE 111 to the source MME 121S (eg, “TAU” Request message). , Service Request message).
  • EPC 120 ie, “EMM-REGISTERED” state
  • ECM-IDLE ECM-IDLE
  • TAU Transmission Authentication Request message
  • Service Request message Service Request message.
  • the eNodeB 112 is instructed to redirect the NAS message to the target MME 121T.
  • the eNodeB 112 operates to redirect the NAS message to the target MME 121T in accordance with an instruction from the source MME 121S.
  • steps S621 and S622 are the same as the procedure performed in steps S221 and S222 in FIG. Step S622 may be omitted.
  • the source MME 121S may delete the context of the UEs including the UE 111 that is the target of relocation, for example, on the condition that a predetermined timer expires. However, the source MME 121S stores that the relocation has been executed.
  • the source MME 121S may store the ID (M-TMSI or S-TMSI) of the UEs that are targeted for relocation.
  • step S624 the UE 111 transmits a NAS message (e.g., “TAU” Request message, Service “Request message”).
  • a NAS message e.g., “TAU” Request message, Service “Request message”.
  • the UE 111 does not know the occurrence of relocation. Therefore, the RRC Connection Setup Complete message encapsulating the NAS message indicates the GUMMEI of the source MME 121S as Registered MME information. Further, the RRC Connection Request message transmitted prior to this indicates S-TMSI assigned by the source MME 121 as UE Identity (step S623). For this reason, in step S625, the eNodeB 112 transmits the NAS message received from the UE 111 to the source MME 121S.
  • step S626 the source MME 121S determines that the relocation to the target MME 121T has been performed or that the UE 111 is the target of the relocation, and instructs the eNodeB 112 to redirect the NAS message to the target MME 121T.
  • This instruction can be transmitted using an S1AP message transmitted on the S1-MME interface between the MME 121S and the eNodeB 112.
  • a new message S1AP: “Redirection” Command message
  • the S1AP: “Redirection” Command message indicates that the NAS message from the UE 111 should be redirected to the target MME 121T.
  • an existing S1AP message e.g., MME Configuration Update message
  • a modified version thereof may be used.
  • step S627 the eNodeB 112 receives the S1AP: “Redirection” Command message, and the eNodeB 112 redirects the NAS message addressed to the source MME 121S received in step S624 to the target MME 121T.
  • the target MME 121T performs a procedure (e.g., TAU procedure, Service Request procedure) based on the NAS message from the UE 111.
  • the target MME 121T may inform the UE 111 of the new UE temporary identifier (i.e., GUTI) assigned by the target MME 121T.
  • a NAS message such as a TAU Accept message or a GUTI Reallocation Command message can be used.
  • UE111 can use the temporary identifier (GUTI) allocated by the target MME121T at the time of transmission of subsequent RRC messages and NAS messages (TAU Request, Service Request, etc.).
  • the procedure of FIG. 12 can perform relocation of mobility management and bearer management without adding a new function to the UE 111. Furthermore, compared with the procedure of FIG. 11, the procedure of FIG. 12 has an advantage that relocation can be performed in units of UE. In other words, the procedure of FIG. 12 can transfer only a part of UEs mobility management and bearer management (partial UEs) performed by the source MME 121S to the target MME 121T.
  • FIG. 13 shows an example of a signaling procedure for relocation.
  • the procedure of FIG. 13 can be performed in step S13 of FIG. That is, the source MME 121S may start the signaling procedure shown in FIG. 13 in response to receiving the context relocation indication message from the control node 142.
  • the source MME 121S is attached to the EPC 120 (ie, “EMM-REGISTERED” state) and is idle (ie, “ECM-IDLE” State) from the UE 111 to the source MME 121S (eg, “TAU” Request message). , Service Request message). Then, when the UE 111 is a target for relocation, an operation is required to transfer the NAS message to the target MME 121T.
  • steps S701 and S702 are the same as the procedure performed in steps S221 and S222 in FIG. Step S702 may be omitted.
  • the source MME 121S may delete the context of the UEs including the UE 111 that is the target of relocation, for example, on the condition that a predetermined timer expires. However, the source MME 121S stores that the relocation has been executed.
  • the source MME 121S may store the ID (M-TMSI or S-TMSI) of the UEs that are targeted for relocation.
  • the UE 111 transmits a NAS message (e.g., “TAU” Request message, Service “Request message”).
  • a NAS message e.g., “TAU” Request message, Service “Request message”.
  • the UE 111 does not know the occurrence of relocation. Therefore, the RRC Connection Setup Complete message encapsulating the NAS message indicates the GUMMEI of the source MME 121S as Registered MME information.
  • the RRC Connection Request message transmitted prior to this indicates the S-TMSI assigned by the source MME 121 as UE Identity. For this reason, the NAS message in step S703 is transmitted to the source MME 121S by the eNodeB 112.
  • step S704 the source MME 121S determines that relocation to the target MME 121T has been performed or that the UE 111 is the target of the relocation, and transfers the NAS message to the target MME 121T.
  • a GTP-C message transmitted on the S10 interface between the MMEs can be used.
  • step S705 the target MME 121T performs a procedure (e.g., TAU procedure, Service.Request procedure) based on the NAS message from the UE 111.
  • a procedure e.g., TAU procedure, Service.Request procedure
  • step S706 the target MME 121T notifies the UE 111 of the new GUTI allocated by the target MME 121T.
  • a NAS message such as a TAU Accept message or GUTI ⁇ Reallocation Command message can be used.
  • the UE 111 can use the new GUTI assigned by the target MME 121T when transmitting subsequent RRC messages and NAS messages (TAU Request, Service Request, etc.).
  • the notification of the new GUTI in step S706 may be performed before step S706.
  • step S707 the UE 111 transmits a response message (e.g., TAU Accept message, GUTI Reallocation Complete message) indicating that GUTI has been received.
  • a response message e.g., TAU Accept message, GUTI Reallocation Complete message
  • relocation from the source MME 121S to the target MME 121T is performed at an arbitrary opportunity, and the UE 111 can be notified of the occurrence of relocation when the UE 111 accesses the EPC 120.
  • FIGS. 14A and 14B show an example of a signaling procedure for relocation.
  • the procedure of FIGS. 14A and 14B can be performed in step S13 of FIG. That is, the source MME 121S may initiate the signaling procedure shown in FIGS. 14A and 14B in response to receiving the context relocation indication message from the control node 142.
  • the source MME 121S is attached to the EPC 120 (ie, EMM-REGISTERED state) and is idle (ie, ECM-IDLE State) from the UE 111 to the source MME 121S (eg, ⁇ TAU). Request message, Service Request message). If the UE 111 context has been deleted because the UE 111 is a relocation target, the source MME 121S inquires of the HSS 122 to know the current MME managing the UE 111.
  • steps S801 and S802 are the same as the procedure performed in steps S221 and S222 in FIG. However, S802 is always performed in order to notify the HSS 122 of the change of the MME.
  • the UE 111 transmits a NAS message (e.g., TAU Request message, Service Request message).
  • a NAS message e.g., TAU Request message, Service Request message.
  • the UE 111 does not know the occurrence of relocation. Therefore, the RRC Connection Setup Complete message encapsulating the NAS message indicates the GUMMEI of the source MME 121S as Registered MME information.
  • the RRC Connection Request message transmitted prior to this indicates the S-TMSI assigned by the source MME 121 as UE Identity. Therefore, the NAS message in step S803 is transmitted to the source MME 121S by the eNodeB 112.
  • step S804 the source MME 121S receives the NAS message from the UE 111 and detects that the context (MM context, EPS Bearer context) related to the UE 111 is not held. And according to the said detection, source MME121S inquires UE111 about IMSI of UE111. For this inquiry, a NAS: “Identity” Request message can be used. In step S805, the UE 111 transmits a NAS message (e.g., “Identity” Response message) indicating its own IMSI.
  • a NAS message e.g., “Identity” Response message
  • the source MME 121S transmits the IMSI received from the UE 111 to the HSS 122 in order to inquire the HME 122 of the MME managing the UE 111.
  • a Diameter message transmitted on the 66a interface between the MME 121S and the HSS 122 can be used.
  • a new Diameter message (DIAMETER: “MME-ID” Request message) may be used.
  • the HSS 122 transmits a response message indicating the ID (e.g., GUMMEI, MMEI, or MMEC) of the target MME 121T that manages the UE 111 to the source MME 121S.
  • the ID e.g., GUMMEI, MMEI, or MMEC
  • the source MME 121S inquires of the target MME 121T about the temporary identifier (e.g., GUTI, S-TMSI, or M-TMSI) assigned to the UE 111.
  • the temporary identifier e.g., GUTI, S-TMSI, or M-TMSI
  • a GTP-C message transmitted on the S10 interface between the MMEs can be used.
  • the target MME 121T transmits a response message indicating the temporary identifier (e.g., GUTI, S-TMSI, or M-TMSI) assigned to the UE 111 by the target MME 121T to the source MME 121S.
  • the source MME 121S notifies the UE 111 of the ID of the new MME after relocation (that is, the target MME 121T). Furthermore, the source MME 121S notifies the UE 111 of the temporary identifier assigned to the UE 111 by the target MME 121T. Specifically, the source MME 121S may inform the UE 111 of the GUTI assigned to the UE 111 by the target MME 121T.
  • a NAS message may be used. For example, as shown in FIG. 14B, a GUTI ⁇ Reallocation Command message may be used. Alternatively, a new NAS message may be defined and used.
  • step S811 the UE 111 receives a new GUTI assigned by the target MME 121T from the source MME 121S. Then, the UE 111 updates the registered MME information managed by the UE 111 using the new GUTI. The UE 111 transmits a NAS message (e.g., “GUTI” Reallocation ”Complete message) indicating that the reception of GUTI is completed to the source MME 121S.
  • the registered MME information updated to indicate the target MME 121T is used in subsequent transmissions of RRC messages and NAS messages (TAU Request, Service Request, etc.). For example, the UE 111 may perform a new TAU procedure or Service Request procedure with the target MME 121T (step S812).
  • the relocation from the source MME 121S to the target MME 121T is performed at an arbitrary opportunity, and when the UE 111 accesses the EPC 120, the occurrence of the relocation can be notified to the UE 111. Furthermore, the source MME 121S does not need to store the relocation destination MME ID.
  • 14A and 14B may be modified as appropriate.
  • the procedure in which the source MME 121S shown in FIGS. 14A and 14B queries the HSS 122 to know the ID of the target MME 121T is used for the NAS message redirection instruction (step S626) by the source MME 121S shown in FIG. May be.
  • 14A and 14B may be used for the NAS message transfer (step S704) by the source MME 121S shown in FIG.
  • FIG. 15A shows a variation of FIG. 14A. Steps S821 and S822 are the same as steps S801 and S802 in FIG. 14A.
  • Step S823 differs from Step S803 in FIG. 14A in that the NAS message transmitted from the UE 111 indicates a relocation flag.
  • the relocation flag indicates that the UE 111 may be targeted for relocation.
  • the source MME 121S notifies the UE 111 that the relocation may be performed prior to the execution of the relocation (step S821).
  • the UE 111 transmits a NAS message in which the relocation flag is set.
  • the source MME 121S When the source MME 121S does not hold the context regarding the UE 111 and the relocation flag is set in the NAS message from the UE 111, the source MME 121S inquires of the UE 111 about the IMSI of the UE 111 (step S824). Steps S824 and S825 are the same as steps S804 and S805 of FIG. 14A. Further, following step S825, the procedure shown in FIG. 14B is executed. On the other hand, when the context regarding the UE 111 is not held and the relocation flag is not set, the source MME 121S returns a reject message (e.g., TAU Reject message, Service Reject message) to the UE 111.
  • a reject message e.g., TAU Reject message, Service Reject message
  • the source MME 121S can limit the UEs that are to be subjected to the procedure after step S824 including the inquiry to the HSS 122.
  • FIG. 16 shows an example of a signaling procedure for relocation.
  • the procedure of FIG. 16 can be performed in step S13 of FIG. That is, the source MME 121S may start the signaling procedure shown in FIG. 16 in response to receiving the context relocation instruction message from the control node 142.
  • steps S901 to S904 the source MME 121S executes relocation, and the UE temporary identifier (e.g., GUTI) assigned by the target MME 121T after the relocation is notified to the UE 111.
  • Steps S901 to S904 are the same as the procedure for notifying the UE 111 of the UE temporary identifier during the TAU procedure shown in FIGS. 10A and 10B. However, steps S901 to S904 may be replaced with other procedures (e.g., procedures in FIG. 5, FIG. 6, FIG. 8, or FIG. 9).
  • the primary GUTI specifies the GUTI assigned by the target MME 121T
  • the secondary GUTI specifies the GUTI assigned by the source MME 121S.
  • the UE 111 preferentially uses the primary GUTI, and uses the secondary GUTI when signaling using the primary GUTI (e.g., TAU procedure, Service Request procedure) fails.
  • the source MME 121S holds the context of the UE 111 until the predetermined timer expires even after performing the relocation. Thereby, even if the target MME 121T as the primary MME rejects the access of the UE 111 due to some trouble associated with the relocation, the source MME 121S as the secondary MME can accept the access of the UE 111.
  • the UE 111 transmits a TAU request message to the target MME 121T (step S905).
  • the target MME 121T does not hold the context of the UE 111 due to some malfunction, and returns a TAU Reject message to the UE 111 (step S906).
  • the UE 111 that has failed to communicate with the primary MME (target MME 121T) tries to communicate with the secondary MME (source MME 121S) (step S907).
  • the source MME 121S may start communication with the UE 111 and perform relocation (e.g., steps S901 to S904) again.
  • FIG. 17 shows an example of a signaling procedure for relocation according to the present embodiment.
  • mobility management and bearer management relocation of the UE 111 are performed, and the primary GUTI and the secondary GUTI are notified to the UE 111 (steps S921 to S924).
  • the source MME 121S holds the UE 111 context until a predetermined timer expires even after performing the relocation.
  • step S925 the UE 111 transmits a TAU request message.
  • the Connection Setup Complete message used to carry the TAU Request message indicates the GUMMEI of the primary MME (target MME 121T) and the GUMMEI of the secondary MME (source MME 121S) as Registered MME information.
  • the eNodeB 112 transfers the TAU Request message to the target MME 121T designated as the primary MME.
  • the target MME 121T transmits a reject message because it does not hold the context of the UE 111 due to some malfunction.
  • the reject message is transmitted not to the UE 111 but to the eNodeB 112.
  • An S1AP message can be used to send the reject message.
  • the eNodeB 112 transfers the TAU Request message to the source MME 121S designated as the secondary MME.
  • the source MME 121S may start communication with the UE 111 and perform relocation (e.g., steps S901 to S904) again.
  • FIG. 18A to 18C show an example of a signaling procedure for relocation according to this embodiment.
  • the primary GUTI and the secondary GUTI are notified to the UE 111 as in the fourteenth and fifteenth embodiments.
  • the primary GUTI is a GUTI assigned to the UE 111 by the target MME 121T.
  • the secondary GUTI is a GUTI assigned to the UE 111 by the secondary MME 821 that is different from both the source MME 121S and the target MME 121T.
  • the source MME 121S moves the context of the UE 111 to the target MME 121T and also moves it to the secondary MME 821. Therefore, the target MME 121 can be called a primary target MME, and the secondary MME 821 can be called a secondary target MME.
  • steps S941 and S942 relocation from the source MME 121S to the target MME 121T is performed.
  • FIG. 18A shows a case where relocation is performed during the TAU procedure. As is clear from the fact that many specific examples have been shown so far, other procedures (eg, FIG. 5, FIG. 6) are shown. , FIG. 8 or FIG. 9).
  • the source MME 121S also transmits the UE 111 context to the secondary MME 821.
  • a GTP-C message e.g., “Forward” Relocation ”Request message
  • the secondary MME 821 transmits a reply message (e.g., “Forward” Relocation ”Response message) to the source MME 121S.
  • the reply message indicates the GUTI assigned to the UE 111 by the secondary MME 821.
  • step S945 the source MME 121S transmits a NAS message (e.g., “TAU” Accept message) indicating the primary GUTI and the secondary GUTI to the UE 111.
  • a NAS message e.g., “TAU” Accept message
  • the primary GUTI designates the GUTI assigned by the target MME 121T
  • the secondary GUTI designates the GUTI assigned by the secondary MME 821.
  • step S946 the UE 111 transmits a TAU Complete message to the source MME 121S in order to notify that a new GUTI has been received.
  • Steps S947 and S948 are the same as steps S905 and S906 in FIG. That is, the UE 111 transmits a TAU Request message to the target MME 121T (step S947). However, the target MME 121T does not hold the context of the UE 111 due to some malfunction, and returns a TAU Reject message to the UE 111 (step S948). The UE 111 that has failed to communicate with the primary MME (target MME 121T) attempts to communicate with the secondary MME 821 (step S949).
  • the secondary MME 821 In response to receiving the NAS message (e.g., “TAU” Request message) from the UE 111, the secondary MME 821 requests the S-GW 123 to update the EPS “bearer” context of the UE 111 held in the S-GW 123 (step S950).
  • This request indicates the new MME that manages the EPS bearer of the UE 111, that is, the IP address and MME TEID of the secondary MME 821.
  • the NAS message from the UE 111 is a TAU Request message
  • this request indicates the current location information of the UE 111 (that is, E-UTRAN Cell Global Identifier (ECGI) and Tracking Area Identity (TAI)).
  • ECGI E-UTRAN Cell Global Identifier
  • TAI Tracking Area Identity
  • the GTP-C message transmitted in the S11 interface between the MME 821 and the S-GW 123 can be used for transmitting this request.
  • the S-GW 123 receives the current location information (ECGI and TAI) of the UE 111 from the secondary MME 821 and confirms whether the ECGI and TAI of the UE 111 has changed. If changed, the UE 111 transmits a Modify Bearer Request message to the P-GW 124 (step S951). The P-GW 124 updates the current location information of the UE 111 included in the EPS bearer context of the UE 111, and transmits a Modify Bearer Response message to the S-GW 123 (step S952). In step S953, the S-GW 123 transmits a response message (for example, Modify Bearer Response message) to the secondary MME 821.
  • a response message for example, Modify Bearer Response message
  • Steps S954 to S957 are performed to notify the HSS 122 of the MME change.
  • the procedure of steps S954 to S957 may be the same as the procedure for notifying HSS of the MME change in the normal TAU procedure, and thus may be the same as the procedure of steps S106 to S109 in FIG. 3A.
  • the secondary MME 821 transmits a TAU Accept message to the UE 111.
  • the TAU Accept message may indicate that the GUTI assigned by the secondary MME 821 is designated as the primary GUTI.
  • the UE 111 can preferentially transmit the next NAS message to the secondary MME 821 instead of the target MME 121T. If the TAU Accept message in step S958 indicates a change in the primary GUTI (or a change in the primary MME), the UE 111 transmits a TAU Complete message to the secondary MME 821 to notify that the change in the primary GUTI has been accepted (step S959). ).
  • FIGS. 19A and 19B show an example of an MME relocation procedure involving relocation from the source S-GW 123S to the target S-GW 123T.
  • the procedure shown in FIGS. 19A and 19B is a modification of the procedure shown in FIGS. 3A and 3B, and is started when the UE 111 is in the connected state (ECM-CONNECTED state).
  • the S-GW relocation when the UE 111 is in the connected state may be performed in the same or similar procedure as the S-GW relocation in the S1-based handover procedure involving S-GW relocation.
  • step S1001 as in step S101 of FIG. 3A, the source MME 121S transmits the MM ⁇ context and EPS bearer context of the UE 111 to the target MME 121T.
  • a GTP-C message can be used for this transmission.
  • a Forward Relocation Request message or a modified version thereof may be used.
  • the GTP-C message in step S1001 may include designation of the target S-GW 123T.
  • step S1002 as in step S102 of FIG. 3A, the target MME 121T stores the MM context and EPS bearer context of the UE 111 received from the source MME 121S in its own memory or storage (not shown). Further, the target MME 121T starts relocation from the source S-GW 123S to the target S-GW 123T.
  • the S-GW relocation when the UE 111 is in the connected state may be performed in the same or similar procedure as the S-GW relocation in the S1-based handover procedure involving S-GW relocation. That is, the target MME 121T transmits an S5 / S8 bearer setting request to the target S-GW 123T.
  • This S5 / S8 bearer setup request includes the bearer context, the P-GW 124 address and TEID of the P-GW 124 for uplink traffic, and the eNodeB 112 address and TEID for downlink traffic.
  • This S5 / S8 bearer setting request may be a Create Session Request message, similar to the message used in the S1-based handover procedure.
  • the target S-GW 123T In step S1003, the target S-GW 123T generates S1 uplink (UL) TEID and S5 / S8 downlink (DL) TEID for UE111. Then, the target S-GW 123T informs the P-GW 124 of the address of the target S-GW 123T and S5 / S8 DL TEID. The target S-GW 123T may transmit a Modify Bearer Request message including the address of the target S-GW 123T and S5 / S8 DL TEID to the P-GW 124.
  • step S1004 the P-GW 124 updates the context held by itself and transmits a Modify Bearer Response message to the target S-GW 123T.
  • step S1005 the target S-GW 123T returns a Create Session Response message to the target MME 121T.
  • This Create Session Response message indicates the address of the target S-GW 123T related to the user plane and the S1 UL UL TEID.
  • the target MME 121T notifies the eNodeB 112 of the MME UE S1AP ID assigned by the target MME 121T. Further, the target MME 121T notifies the eNodeB 112 of the address of the target S-GW 123T related to the user plane and S1 UL TEID (that is, S1-U SGW F-TEID). These notifications may be sent from the target MME 121T to the eNodeB 112 using, for example, a modified Handover Request message, an improved Initial Context Setup Request message, an improved E-RAB Modify Request message, or an improved UE Context Modification Request message. May be sent to.
  • the eNodeB 112 updates the context held by itself and transmits an Acknowledge message to the target MME 121T.
  • the acknowledgment message may indicate the eNodeB 112 address and TEID for downlink traffic (ie, S1-U1-eNodeB F-TEID).
  • the approval message may be a modified Handover Request Ack message, an improved Initial Context Setup Response message, an improved E-RAB Modify Response message, or an improved UE Context Modification Response message.
  • the target MME 121T sends a Modify Bearer Request message indicating the updated S1-U eNodeB F-TEID to the target S-GW 123T (step S1008).
  • the target S-GW 123T updates the context and transmits a Modify Bearer Response message to the target MME 121T. If S1-U eNodeB F-TEID is not updated, steps S1008 and S1009 may be omitted.
  • step S1010 as in step S104 of FIG. 3A, the target MME 121T notifies the source MME 121S that it has accepted the handover of mobility management and bearer management of the UE 111.
  • the notification message in step S1010 includes a temporary identifier assigned to the UE 111 by the target MME 121T, that is, M-TMSI, S-TMSI, or GUTI.
  • a Forward-Relocation-Response message or a modified version thereof may be used.
  • a Forward Relocation Complete Notification message or a modified version thereof may be used.
  • step S1011 the source MME 121S transmits an acknowledge message for the message in step S1010 to the target MME 121T, as in step S105 of FIG. 3A.
  • the acknowledgment message may be a Forward Relocation Complete Acknowledge message or a modified version thereof.
  • Steps S1012 to S1015 are performed to notify the HSS 122 of the MME change.
  • the procedure performed in steps S1012 to S1015 is the same as the procedure performed in steps S106 to S109 in FIG. 3A. Steps S1012 to S1015 may be omitted.
  • step S1016 the source MME 121S transmits a Delete Session Request message to the source S-GW 123S in order to request deletion of the bearer context related to the UE 111.
  • step S1017 the source S-GW 123S deletes the bearer context regarding the UE 111, and returns a Delete Session Response message to the source MME 121S.
  • steps S1018 and S1019 are the same as the procedure performed in steps S112 and S113 in FIG. 3B.
  • the MME relocation procedure with S-GW relocation can be performed for the UE 111 in the connected state (ECM-CONNECTED state).
  • FIG. 20 shows an example of the MME relocation procedure with relocation (or S-GW change) from the source S-GW 123S to the target S-GW 123T.
  • the procedure shown in FIG. 20 is a modification of the procedure shown in FIG. 5 and starts when the UE 111 is in an idle state (ECM-IDLE state).
  • the S-GW relocation when the UE 111 is in an idle state may be performed in the same or similar procedure as the S-GW relocation in the TAU procedure with S-GW relocation (or S-GW change).
  • step S1121 the source MME 121S relocates the mobility management service and bearer management service of the UE 111 attached to the EPC 120 (i.e., “EMM-REGISTERED” state) to the target MME 121T.
  • the procedure performed in step S1121 may be the same as the procedure performed in steps S1001 to S1005 and S1010 to S1011 in FIGS. 19A and 19B.
  • step S1122 the target MME 121T notifies the HSS 122 of the MME change.
  • the procedure performed in step S1122 may be the same as the procedure for notifying the HSS of the MME change in the normal TAU procedure, that is, similar to the procedure performed in steps S106 to S109 in FIG. 3A. Further, step S1122 may be omitted.
  • steps S1123 to S1127 is the same as the procedure performed in steps S223 to S227 in FIG.
  • the MME relocation procedure accompanied by the relocation of the S-GW can be performed for the UE 111 in the idle state (ECM-IDLE state).
  • FIG. 20 shows a procedure obtained by modifying the procedure of FIG. 5 using paging in order to explain the MME relocation procedure with S-GW relocation (or S-GW change) related to the idle UE 111.
  • the S-GW relocation (or S-GW change) described with reference to FIG. 20 can be used in the same manner as FIG. 20 in the other procedures described in the fourth to sixteenth embodiments.
  • FIG. 24 illustrates a configuration example of the source MME 121S.
  • the configurations of the target MME 121T and the secondary MME 821 may be the same as the configuration example of FIG.
  • the MME 121S includes a network interface 1210, a processor 1211, and a memory 1212.
  • the network interface 1210 is used to communicate with other network nodes (e.g., eNodeB 112, target MME 121T, HSS 122, S-GW 123).
  • the network interface 1210 may include, for example, a network interface card (NIC) compliant with IEEE 802.3 series.
  • NIC network interface card
  • the processor 1211 executes communication control (e.g., mobility management and bearer management) by reading and executing software (computer program) from the memory 1212.
  • the processor 1211 may be, for example, a microprocessor, a Micro Processing Unit (MPU), or a Central Processing Unit (CPU).
  • the processor 1211 may include a plurality of processors.
  • the memory 1212 is configured by a combination of a volatile memory and a nonvolatile memory.
  • the volatile memory is, for example, Static Random Access Memory (SRAM), Dynamic RAM (DRAM), or a combination thereof.
  • the nonvolatile memory is, for example, a mask Read Only Memory (MROM), Programmable ROM (PROM), flash memory, hard disk drive, or a combination thereof.
  • the memory 1212 may include storage that is physically separated from the processor 1211. In this case, the processor 1211 may access the memory 1212 via the network interface 1210 or another I / O interface not shown.
  • the memory 1212 includes an S1-MME module 1213, an S6a module 1214, an S10 module 1215, an S11 module 1216, a NAS module 1217, an EPS Mobility Management (EMM) and an EPS) Session Management (ESM) module 1218, and an Operation Used to store software modules including and maintenance (OAM) module 1219.
  • the OAM module 1219 includes instructions and data for controlling communication and relocation with the control node 142 described in the above embodiment.
  • the processor 1211 can read out and execute the OAM module 1219 from the memory 1212 to perform the operation of the source MME 121S related to the mobility management and bearer management relocation procedure described in the above-described embodiment.
  • FIG. 25 illustrates a configuration example of the UE 111.
  • UE 111 includes a wireless transceiver 1110, a processor 1111, and a memory 1112.
  • Wireless transceiver 1110 is configured to communicate with eNodeB 112.
  • the processor 1111 performs communication control including transmission and reception of RRC and NAS messages by reading and executing software (computer program) from the memory 1112.
  • the processor 1111 may be, for example, a microprocessor, MPU, or CPU.
  • the processor 1111 may include a plurality of processors.
  • the memory 1112 is configured by a combination of a volatile memory and a nonvolatile memory.
  • the volatile memory is, for example, SRAM or DRAM or a combination thereof.
  • the non-volatile memory is, for example, an MROM, PROM, flash memory, hard disk drive, or a combination thereof.
  • the memory 1112 is used to store a software module group including the RRC module 1113 and the NAS module 1114.
  • the processor 1111 reads out the RRC module 1113 and the NAS module 1114 from the memory 1112 and executes them, so that the UE 111 can perform operations related to the mobility management and bearer management relocation procedures described in the above embodiment.
  • FIG. 26 shows a configuration example of the eNodeB 112.
  • the eNodeB 112 includes a wireless transceiver 1120, a network interface 1121, a processor 1122, and a memory 1123.
  • Wireless transceiver 1120 is configured to communicate with UE 111.
  • the network interface 1121 is used to communicate with other eNodeBs within the E-UTRAN 110 and nodes within the EPC 120 (MME 121S, MME 121T, S-GW 123, etc.).
  • the processor 1122 reads out and executes software (computer program) from the memory 1123, thereby performing communication control including RRC and Radio Resource Management (RRM) and the operation of the eNodeB 112 described in the above-described embodiment.
  • the processor 1122 may be, for example, a microprocessor, MPU, or CPU.
  • the processor 1122 may include a plurality of processors.
  • the memory 1123 is configured by a combination of a volatile memory and a nonvolatile memory.
  • the volatile memory is, for example, SRAM or DRAM or a combination thereof.
  • the non-volatile memory is, for example, an MROM, PROM, flash memory, hard disk drive, or a combination thereof.
  • the memory 1123 may include a storage disposed away from the processor 1122. In this case, the processor 1122 may access the memory 1123 via the network interface 1121 or another I / O interface not shown.
  • the memory 1123 is used to store a software module group including the RRC module 1124, the RRM module 1125, the X2 module 1126, and the S1-MME module 1127.
  • the RRC module 1124 and the S1-MME module 1127 include an instruction group and data for executing processing for transferring the NAS message encapsulated in the received RRC message to the MME.
  • the processor 1122 can perform the operation of the eNodeB 112 related to the mobility management and bearer management relocation procedures described in the above-described embodiments by reading the RRC module 1124 and the S1-MME module 1127 from the memory 1123 and executing them.
  • each of the processors included in the source MME 121S, the target MME 121T, the secondary MME 821, the UE 111, and the eNodeB 112 uses the algorithm described using the sequence diagram and the like.
  • One or more programs including instructions for causing a computer to execute are executed.
  • Non-transitory computer readable media include various types of tangible storage media (tangible storage medium). Examples of non-transitory computer-readable media are magnetic recording media (eg flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (eg magneto-optical discs), Compact Disc Read Only Memory (CD-ROM), CD-ROM R, CD-R / W, semiconductor memory (for example, mask ROM, Programmable ROM (PROM), Erasable PROM (EPROM), flash ROM, Random Access Memory (RAM)).
  • the program may also be supplied to the computer by various types of temporary computer-readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves.
  • the temporary computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.
  • FIGS. 2 to 20 show examples in which the source MME 121S receives a relocation instruction message from the control node 142.
  • the target MME 121T may receive a relocation instruction message from the control node 142 and start the relocation procedure.
  • FIG. 5 and the like show an example in which the source MME 121S notifies the UE 111 of the ID (eg, TGUMMEI) of the target MME 121T or the UE temporary identifier (eg, GUTI) assigned by the target MME 121T. It was. However, instead of the source MME 121S, the target MME 121T may notify the UE 111 of the ID or UE temporary identifier of the target MME 121T.
  • the ID eg, TGUMMEI
  • UE temporary identifier eg, GUTI
  • UMTS Universal Mobile Telecommunications System
  • HRPD High Rate Packet Data
  • GSM Global System for Mobile Communications
  • GPRS General packet radio service
  • Evolved Universal Terrestrial Radio Access Network 111 User Equipment (UE) 112 eNodeB 121S Source Mobility Management Entity (MME) 121T Target MME 122 Home Subscriber Server (HSS) 123 Serving Gateway (S-GW) 124 Packet Data Network Gateway (P-GW) 120 Evolved Packet Core (EPC) 130 Packet Data Network (PDN) 141 Control interface 142 Control node 1111, 1122, 1211 Processor 1112, 1123, 1212 Memory

Abstract

　コアネットワーク（１２０）に結合して使用されるコントロールノード（１４２）は、コアネットワーク（１２０）内に配置されてコアネットワーク（１２０）にアタッチ済みである複数の移動端末（１１１）のためのモビリティ管理及びベアラ管理を行う第１のネットワークノード（１２１Ｓ）に関するリロケーション指示メッセージを送信するよう動作する。当該リロケーション指示メッセージは、第１のネットワークノード（１２１Ｓ）から少なくとも１つの第２のネットワークノード（１２１Ｔ）への複数の移動端末（１１１）のうち少なくとも１つのためのモビリティ管理及びベアラ管理のリロケーションを引き起こす。これにより、例えば、複数の移動端末のモビリティ管理及びベアラ管理を、これら移動端末の移動に関わらず、ネットワークノード間でリロケートできるようにすることに寄与できる。

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 (22)

  1. 　コアネットワークに結合して使用されるコントロールノードによって行われる方法であって、
    　前記コアネットワーク内に配置されて前記コアネットワークにアタッチ済みである複数の移動端末のモビリティ管理及びベアラ管理を行う第１のネットワークノードに関するリロケーション指示メッセージを送信することを備え、
    　前記リロケーション指示メッセージは、前記第１のネットワークノードから少なくとも１つの第２のネットワークノードへの前記複数の移動端末のうち少なくとも１つのための前記モビリティ管理及び前記ベアラ管理のリロケーションを引き起こす、
    方法。
  2. 　前記リロケーション指示メッセージは、リロケーションポリシを含み、
    　前記リロケーションポリシは、前記少なくとも１つの第２のネットワークノードの識別子を含む、
    請求項１に記載の方法。
  3. 　前記リロケーションポリシは、前記第１のネットワークノードから前記少なくとも１つの第２のネットワークノードにリロケートされるべき前記モビリティ管理及び前記ベアラ管理の処理量を示す、請求項２に記載の方法。
  4. 　前記リロケーションポリシは、前記リロケーションに対する時間的な制約を示す、請求項２又は３に記載の方法。
  5. 　前記リロケーションポリシは、前記リロケーションを行うための複数のシグナリング手順のうちいずれを用いるべきかを示す、請求項２～４のいずれか１項に記載の方法。
  6. 　前記第１のネットワークノードの負荷を取得すること、
    　前記負荷に基づいて前記リロケーションポリシを決定すること、
    をさらに備える、請求項２～５のいずれか１項に記載の方法。
  7. 　前記送信することは、前記第１のネットワークノードを制御する他のコントロールノードに、前記リロケーション指示メッセージを送信することを備え、
    　前記他のコントロールノードは、前記第１のネットワークノード又は前記第２のネットワークノードに前記リロケーションを指示する、
    請求項１～６のいずれか１項に記載の方法。
  8. 　前記コアネットワークは、Third Generation Partnership Project（3GPP）のEvolved Packet Core（EPC）を含み、
    　前記第１及び第２のネットワークノードの各々は、Mobility Management Entity（MME）である、
    請求項１～７のいずれか１項に記載の方法。
  9. 　前記コントロールノードは、Software-Defined Network（SDN）コントローラ、Network Function Virtualization（NFV）コントローラ、Operations Support System（OSS）、又はElement Management System（EMS）である、請求項１～８のいずれか１項に記載の方法。
  10. 　前記リロケーションは、前記複数の移動端末のうち少なくとも１つに関するモビリティ管理コンテキスト及びベアラコンテキストの維持を前記第１のネットワークノードに代わって前記第２のネットワークノードが行うことを含む、請求項１～９のいずれか１項に記載の方法。
  11. 　コアネットワーク内に配置されたネットワークノードによって行われる方法であって、
    　前記コアネットワークにアタッチ済みである複数の移動端末のモビリティ管理及びベアラ管理を行うこと、
    　前記コアネットワークに結合されたコントロールノードからリロケーション指示メッセージを受信すること、及び
    　前記リロケーション指示メッセージに従って、前記ネットワークノードから前記コアネットワーク内の少なくとも１つの他のノードへの前記複数の移動端末のうち少なくとも１つのための前記モビリティ管理及び前記ベアラ管理のリロケーションを行うこと、
    を備える方法。
  12. 　前記リロケーション指示メッセージは、リロケーションポリシを含み、
    　前記リロケーションポリシは、前記少なくとも１つの第２のネットワークノードの識別子を含む、
    請求項１１に記載の方法。
  13. 　前記リロケーションポリシは、前記ネットワークノードから前記少なくとも１つの他のネットワークノードにリロケートされるべき前記モビリティ管理及び前記ベアラ管理の処理量を示す、請求項１２に記載の方法。
  14. 　前記リロケーションポリシは、前記リロケーションに対する時間的な制約を示す、請求項１２又は１３に記載の方法。
  15. 　前記リロケーションポリシは、前記リロケーションを行うための複数のシグナリング手順のうちいずれを用いるべきかを示す、請求項１２～１４のいずれか１項に記載の方法。
  16. 　前記コアネットワークは、Third Generation Partnership Project（3GPP）のEvolved Packet Core（EPC）を含み、
    　前記ネットワークノード及び前記他のノードの各々は、Mobility Management Entity（MME）である、
    請求項１１～１５のいずれか１項に記載の方法。
  17. 　前記コントロールノードは、Software-Defined Network（SDN）コントローラ、Network Function Virtualization（NFV）コントローラ、Operations Support System（OSS）、又はElement Management System（EMS）である、請求項１１～１６のいずれか１項に記載の方法。
  18. 　前記リロケーションは、前記複数の移動端末のうち少なくとも１つに関するモビリティ管理コンテキスト及びベアラコンテキストの維持を前記ネットワークノードに代わって前記他のノードが行うことを含む、請求項１１～１７のいずれか１項に記載の方法。
  19. 　コアネットワークに結合して使用されるコントロールノードであって、
    　メモリと、
    　前記メモリに結合され、請求項１～１０のいずれか１項に記載の方法を実行するよう構成されたプロセッサと、
    を備えるコントロールノード。
  20. 　コアネットワーク内に配置されるネットワークノードであって、
    　メモリと、
    　前記メモリに結合され、請求項１１～１８のいずれか１項に記載の方法を実行するよう構成されたプロセッサと、
    を備えるネットワークノード。
  21. 　請求項１～１０のいずれか１項に記載の方法をコンピュータに行わせるためのプログラムを格納した非一時的なコンピュータ可読媒体。
  22. 　請求項１１～１８のいずれか１項に記載の方法をコンピュータに行わせるためのプログラムを格納した非一時的なコンピュータ可読媒体。
PCT/JP2015/001192 2014-06-24 2015-03-05 コントロールノード及びネットワークノード並びにこれらにより行われる方法 WO2015198508A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US15/321,686 US10512011B2 (en) 2014-06-24 2015-03-05 Control node, network node, and methods performed therein
EP15811393.6A EP3163943B1 (en) 2014-06-24 2015-03-05 Control node and network node, and method carried out using these
CN201580034412.XA CN106471846B (zh) 2014-06-24 2015-03-05 控制节点、网络节点和在其中执行的方法
JP2016528981A JP6460102B2 (ja) 2014-06-24 2015-03-05 コントロールノード及びネットワークノード並びにこれらにより行われる方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2014-128822 2014-06-24
JP2014128822 2014-06-24

Publications (1)

Publication Number Publication Date
WO2015198508A1 true WO2015198508A1 (ja) 2015-12-30

Family

ID=54937622

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/001192 WO2015198508A1 (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)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017125025A1 (zh) * 2016-01-21 2017-07-27 中兴通讯股份有限公司 寻呼的方法、装置、系统及存储介质
JP2020504541A (ja) * 2017-04-25 2020-02-06 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． 負荷再配置方法、装置、およびシステム

Families Citing this family (14)

* 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 北京三星通信技术研究有限公司 一种网络选择的方法和基站
US20200267800A1 (en) * 2015-12-07 2020-08-20 Lg Electronics Inc. Method for performing s1 connection release by mobility management object, mobility management object, method for performing s1 connection release by base station, and base station
EP3468253B1 (en) * 2016-07-01 2021-04-14 Huawei Technologies Co., Ltd. Switching method and device
AU2017289322B2 (en) * 2016-07-01 2020-09-10 Telefonaktiebolaget Lm Ericsson (Publ) Systems and methods for user equipment (UE) registration
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
WO2018217142A1 (en) * 2017-05-23 2018-11-29 Telefonaktiebolaget Lm Ericsson (Publ) Core network node and method therein for obtaining a decision of a cn/ ran endpoint pair for user plane session in a radio communications network
FR3072537A1 (fr) * 2017-10-17 2019-04-19 Orange Procede de basculement d'un equipement de gestion dans un reseau de telecommunications
CN109842906B (zh) * 2017-11-28 2021-10-15 华为技术有限公司 一种通信的方法、装置及系统
CN110650499B (zh) 2018-06-26 2022-04-29 华为技术有限公司 重定向的方法、通信系统和通信装置
EP4061033A4 (en) * 2020-01-03 2023-01-11 Samsung Electronics Co., Ltd. METHOD AND APPARATUS FOR ADJUSTING APPLICATION CONTEXT DATA IN AN EDGE COMPUTATION SYSTEM

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004080433A (ja) * 2002-08-19 2004-03-11 Nec Commun Syst Ltd 移動体通信システムにおける負荷分散システム、端末仮想接続方法、及び交換装置
EP2265054A1 (en) * 2008-03-21 2010-12-22 Huawei Technologies Co., Ltd. Overload processing method and apparatus
JP2011211710A (ja) * 2010-03-29 2011-10-20 Hitachi Ltd ステートフルな（通信状態を維持する）地理的冗長性を有するモビリティ管理エンティティ（ｍｍｅ）の効率的な配備
JP2013530581A (ja) * 2010-05-11 2013-07-25 エヌイーシー ヨーロッパ リミテッド Ｌｔｅ／ｅｐｃネットワークにおけるｍｍｅの障害を処理する方法

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
JP5042248B2 (ja) 2009-01-22 2012-10-03 株式会社日立製作所 移動体通信システム、呼制御サーバ及びアクセスゲートウェイ装置
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
WO2010112037A1 (en) 2009-03-31 2010-10-07 Telefonaktiebolaget Lm Ericsson (Publ). Redistribution of terminals
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 삼성전자주식회사 이종 망간의 핸드오버 장치 및 그 방법
US8331224B2 (en) * 2009-11-23 2012-12-11 Telefonaktiebolaget L M Ericsson (Publ) Self-management of mobility management entity (MME) pools
US8331938B2 (en) * 2009-11-23 2012-12-11 Telefonaktiebolaget L M Ericsson (Publ) Moving user equipment without service interruption
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
DK2622908T3 (en) * 2010-09-27 2017-03-06 ERICSSON TELEFON AB L M (publ) RELOCATION OF A SERVING GATEWAY ASSOCIATED WITH A USER DEVICE
WO2012136812A1 (en) 2011-04-06 2012-10-11 Nec Europe Ltd. Method and a system for distributing of user equipment context in an evolved packet system
EP2538719B1 (en) * 2011-06-24 2020-03-11 Vodafone IP Licensing limited Telecommunication networks
CN102868994A (zh) * 2011-07-08 2013-01-09 北京三星通信技术研究有限公司 一种支持用户设备ue移动性的方法
US9185595B2 (en) * 2011-08-01 2015-11-10 Telefonaktiebolaget L M Ericsson (Publ) Method, apparatus and system for moving wireless terminals in mobility management serving node pool
WO2013028026A2 (en) 2011-08-24 2013-02-28 Lg Electronics Inc. Method and apparatus for transmitting uplink data associated with mtc device trigger function
US9532278B2 (en) * 2011-09-28 2016-12-27 Lg Electronics Inc. Method and apparatus for transmitting establishment cause value in wireless communication system
WO2013047822A1 (ja) * 2011-09-30 2013-04-04 日本電気株式会社 通信システムと方法と装置
CN103096404B (zh) * 2011-11-04 2018-07-13 北京三星通信技术研究有限公司 支持组切换的方法及设备
CN108770024B (zh) * 2011-11-04 2023-05-26 北京三星通信技术研究有限公司 支持组切换的方法及设备
GB2497074A (en) 2011-11-22 2013-06-05 Sca Ipla Holdings Inc A virtual mobility manager stores context information for an offline communications terminal
WO2013076455A1 (en) 2011-11-22 2013-05-30 Sca Ipla Holdings Inc Paging off-line state terminals
GB2497073A (en) 2011-11-22 2013-06-05 Sca Ipla Holdings Inc A virtual mobility manager stores context information for an offline communications terminal
WO2014021447A1 (ja) * 2012-08-02 2014-02-06 三菱電機株式会社 通信システム
KR101612683B1 (ko) * 2012-10-10 2016-04-26 엘지전자 주식회사 페이징 처리 방법 및 다운링크 데이터 전달 방법
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 中兴通讯股份有限公司 一种选择分流网关的方法和控制器
WO2015198509A1 (ja) * 2014-06-24 2015-12-30 日本電気株式会社 ネットワークノード、移動端末、及び基地局、並びにこれらにより行われる方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004080433A (ja) * 2002-08-19 2004-03-11 Nec Commun Syst Ltd 移動体通信システムにおける負荷分散システム、端末仮想接続方法、及び交換装置
EP2265054A1 (en) * 2008-03-21 2010-12-22 Huawei Technologies Co., Ltd. Overload processing method and apparatus
JP2011211710A (ja) * 2010-03-29 2011-10-20 Hitachi Ltd ステートフルな（通信状態を維持する）地理的冗長性を有するモビリティ管理エンティティ（ｍｍｅ）の効率的な配備
JP2013530581A (ja) * 2010-05-11 2013-07-25 エヌイーシー ヨーロッパ リミテッド Ｌｔｅ／ｅｐｃネットワークにおけるｍｍｅの障害を処理する方法

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017125025A1 (zh) * 2016-01-21 2017-07-27 中兴通讯股份有限公司 寻呼的方法、装置、系统及存储介质
JP2020504541A (ja) * 2017-04-25 2020-02-06 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． 負荷再配置方法、装置、およびシステム
JP2021108500A (ja) * 2017-04-25 2021-07-29 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． 負荷再配置方法、装置、およびシステム
JP7097894B2 (ja) 2017-04-25 2022-07-08 華為技術有限公司 負荷再配置方法、装置、およびシステム
JP7136964B2 (ja) 2017-04-25 2022-09-13 華為技術有限公司 負荷再配置方法、装置、およびシステム
US11540172B2 (en) 2017-04-25 2022-12-27 Huawei Technologies Co., Ltd. Load relocation in a communications network
US11950136B2 (en) 2017-04-25 2024-04-02 Huawei Technologies Co., Ltd. Load relocation in a communications network

Also Published As

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

Similar Documents

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

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15811393

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2016528981

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 15321686

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2015811393

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2015811393

Country of ref document: EP