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

通信システムと方法と装置 Download PDF

Info

Publication number
WO2015002290A1
WO2015002290A1 PCT/JP2014/067891 JP2014067891W WO2015002290A1 WO 2015002290 A1 WO2015002290 A1 WO 2015002290A1 JP 2014067891 W JP2014067891 W JP 2014067891W WO 2015002290 A1 WO2015002290 A1 WO 2015002290A1
Authority
WO
WIPO (PCT)
Prior art keywords
mobility management
node
specific
terminal
mme
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2014/067891
Other languages
English (en)
French (fr)
Inventor
創 前佛
田村　利之
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to UAA201600857A priority Critical patent/UA116025C2/uk
Priority to CN201480038357.7A priority patent/CN105359581A/zh
Priority to RU2016103470/07A priority patent/RU2602088C1/ru
Priority to KR1020167003159A priority patent/KR101651807B1/ko
Priority to MX2016001671A priority patent/MX349184B/es
Priority to BR112015032906A priority patent/BR112015032906A2/pt
Priority to MX2016000202A priority patent/MX345250B/es
Priority to KR1020167026957A priority patent/KR20160117641A/ko
Priority to JP2015525288A priority patent/JP5862840B2/ja
Application filed by NEC Corp filed Critical NEC Corp
Priority to EP14820719.4A priority patent/EP2996393A4/en
Priority to BR122016004704-0A priority patent/BR122016004704A2/pt
Priority to KR1020167009283A priority patent/KR101663451B1/ko
Priority to KR1020187013659A priority patent/KR20180053436A/ko
Priority to US14/902,656 priority patent/US9883440B2/en
Publication of WO2015002290A1 publication Critical patent/WO2015002290A1/ja
Priority to PH12016500012A priority patent/PH12016500012B1/en
Anticipated expiration legal-status Critical
Priority to US15/061,120 priority patent/US20160192263A1/en
Priority to PH12016500439A priority patent/PH12016500439A1/en
Priority to PH12017500046A priority patent/PH12017500046B1/en
Priority to US15/840,649 priority patent/US20180146406A1/en
Priority to PH12018502264A priority patent/PH12018502264A1/en
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0007—Control or signalling for completing the hand-off for multicast or broadcast services, e.g. MBMS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0016—Hand-off preparation specially adapted for end-to-end data sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H04W36/0064—Transmission or use of information for re-establishing the radio link of control information between different access points
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0055—Transmission or use of information for re-establishing the radio link
    • H04W36/0072—Transmission or use of information for re-establishing the radio link of resource information of target access point
    • 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
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/34—Reselection control
    • H04W36/36—Reselection control by user or terminal equipment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • 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 invention is based on Japanese patent applications: Japanese Patent Application No. 2013-141127 (filed on July 4, 2013) and Japanese Patent Application No. 2013-187106 (filed on September 10, 2013). It is assumed that the description is incorporated in this document by reference.
  • the present invention relates to a communication system, method and apparatus.
  • a core network of a mobile communication system in order to provide various services to various terminals (mobile devices), it is necessary that all the nodes in the core network have functions necessary for each service. .
  • many nodes are arranged in a core network. Terminals are distributed and connected to nodes in the core network for each location registration.
  • Patent Document 1 As a configuration for optimizing the packet transfer path according to the type of service used by the mobile station, for example, in Patent Document 1, when a mobile station uses a service from an external network, a specific specification corresponding to the external network is used. A configuration is disclosed in which restrictions are imposed on the packet transfer path so as to pass through the packet transfer apparatus, and when the mobile station uses a service provided by the mobile communication network, no restrictions are imposed on the packet transfer path.
  • each node in the core network has all the service providing functions, it is required to have high functionality and high performance. As a result, each core network node is expensive.
  • MBMS Multimedia Broadcast Multicast Service
  • 3GPP 3rd Generation Partnership Project
  • MBMS Multimedia Broadcast Multicast Service
  • the service provider provides the service to the number of MBMS users. I can't do it.
  • the telecommunications carrier can use a relatively small number of expensive MBMS-compatible core network nodes and a large number of inexpensive MBMS services.
  • the overall equipment cost can be made efficient (first knowledge of the present inventors).
  • machine communication (MTC: Machine Type Communication) devices (M2M devices) in 3GPP which have been spreading in recent years, are different from normal terminals (handset terminals) such as mobile phone terminals and smartphones used for calls and the like. And required communication quality vary greatly.
  • machine communication services such as remote management of vending machine inventory and billing, remote monitoring and control of sensor systems, vehicle monitoring, smart grids, and the like.
  • the service is provided to both the MTC device and the handset terminal. Cannot be provided.
  • the communication carrier combines the relatively inexpensive core network node for the handset terminal and the relatively inexpensive core network node for the MTC device. Can be deployed.
  • the MTC device may be a terminal that notifies the core network node of low access priority information or communication delay tolerance information (second knowledge of the present inventors).
  • the present invention was created to solve the above-mentioned problems, and the object of the present invention is to provide a system, method, and apparatus for reducing the facility cost of the entire core network and providing an efficient handover function. It is to provide.
  • the present invention for solving the above problems is generally configured as follows (however, it is not limited to the following).
  • a core network of a mobile communication system includes, as a mobility management node of a terminal, a specific mobility management node selected according to a service characteristic or a terminal type used by the terminal, Provided by the communication system that, when a handover across the mobility management nodes is activated, the specific mobility management node selects a handover destination mobility management node according to the specific mobility management node connection request information held Is done.
  • the core network of the mobile communication system is provided with a specific mobility management node selected according to a service characteristic or a terminal type used by the terminal as a mobility management node of the terminal,
  • a communication method is provided in which the specific mobility management node selects a handover destination node according to the specific mobility management node connection request information held.
  • a specific mobility management node device having a mobility management function of a terminal and selected according to a service characteristic or a terminal type used by the terminal, wherein the mobility management node is When the crossing handover is activated, a mobility management node device is provided in which the specific mobility management node selects a handover destination mobility management node according to the held specific mobility management node connection request information.
  • the equipment cost of the entire core network can be reduced, and an efficient handover function can be provided.
  • the core network includes a plurality of nodes (21/22 or 121/122) having different service functions to be provided to the terminal, and the node connected to the terminal is based on the subscriber information and the terminal information.
  • the terminal (1) and the selected node are connected by selecting from the plurality of nodes according to the service characteristics or terminal type used by the terminal. That is, in the core network, a node (22 or 122) having a predetermined specific service providing function and a node (21 or 121) not having the specific service providing function are deployed in combination.
  • a terminal in a mobile communication network, can be connected to a specific core network node according to conditions such as service characteristics and terminal type, and further a handover is possible.
  • a general MME Mobility Management Entity
  • a UE User Equipment: also referred to as a user equipment, a terminal, or a mobile device
  • a specific MME Customerized MME
  • an MME reselection request signal (mobility management entity reselection request signal) is transmitted to eNodeB (evolved NodeB: base station apparatus).
  • the MME reselection request signal may be a low access priority indication (LAPI) or a delay tolerant access.
  • LAPI sets M2M communication to a lower priority than general voice data communication.
  • the LAPI is notified to the network (for example, the attach request signal of the NAS (Non-Access Stratum) protocol includes LAPI), eNodeB, MME, SGW (Serving Gateway), PGW (PDN (Packet Data Networks) Gateway) or the like.
  • the delay tolerant access is set in, for example, an RRC (Radio Resource Control) connection request message, and is introduced to perform control when the network is overloaded (for example, 3GPP Technical Specification. 23). .
  • RRC Radio Resource Control
  • LAPI or delay tolerant access is an information element notified to the network by an MTC device (MTC terminal), for example, and the base station (eNodeB) may specify the MME based on these information elements (marks). Good.
  • the base station (eNodeB) may select the specific MME for a terminal (UE) having a low access priority.
  • the terminal (UE) having the low access priority is a terminal having an MTC function.
  • a terminal (UE) having a low access priority configuration provides information (LAPI) indicating that the RRC connection request is the low access priority to the base station, and the base station (UE) has a low access priority (low access priority) configuration.
  • the station (eNodeB) may use the information (LAPI) from the terminal to direct a terminal (UE) having a low access priority configuration to the specific MME.
  • the eNodeB connects the UE to the specific MME by retransmitting the Attach Request to the specific MME.
  • the general MME that has received the Attach Request from the UE transmits an MME change request signal (mobility management entity change request signal) to the specific MME in order to connect the UE to the specific MME (Customized MME).
  • the specific MME connects the UE to the specific MME by continuing an attach process (Attach Procedure).
  • the general MME that has received the Attach Request from the UE transmits an attach reject (Attach Reject) to which the identifier of the specific MME is attached in order to connect the UE to the specific MME (Customized MME).
  • the UE attaches the identifier of the specific MME to the Attach Request and retransmits the UE, thereby connecting the UE to the specific MME.
  • the UE transmits an RRC connection request (RRC (Radio Resource Control) Connection Request) (radio resource connection request) with specific MME (Customized MME) connection request information to the eNodeB, and the eNodeB that has received the RRC connection request.
  • RRC Radio Resource Control
  • MME Customerized MME
  • the UE is connected to the specific MME by selecting the specific MME when transmitting an Attach Request from the UE that has established an RRC connection to the MME.
  • the specific MME connection request information may be low access priority indication (LAPI) or delay tolerant access.
  • LAPI or delay tolerant access is, for example, an information element notified to the network by the MTC terminal, and the base station (eNodeB) may specify the MME based on these information elements.
  • ⁇ Aspect 4-1> The eNodeB that has received the RRC (Radio Resource Control) signal with the specific MME connection request information for connecting to the specific MME (Customized MME) from the UE receives the specific MME connection request information using the S1-AP signal. Notify specific MME.
  • RRC Radio Resource Control
  • a general SGSN (Serving GPRS (General Packet Radio Service) Support Node: indicated as “serving GPRS support node” in the claims) that receives the Attach Request from the UE is used to connect the UE to a specific SGSN (Customized SGSN).
  • an SGSN reselection request signal is transmitted to an RNC (Radio Network Controller), and the RNC retransmits an Attach Request to the specific SGSN, thereby connecting the UE to the specific SGSN.
  • the SGSN reselection request signal may be a low access priority indication (LAPI) or a delay tolerant access. That is, for example, the SGSN may be specified by the RNC based on information elements such as LAPI and delay tolerant access notified from the MTC terminal to the network.
  • LAPI low access priority indication
  • the general SGSN that has received the Attach Request from the UE transmits an SGSN change request signal to the specific SGSN in order to connect the UE to the specific SGSN (Customized SGSN), and the specific SGSN continues the attach process (Attach Procedure). By doing so, the UE is connected to the specific SGSN.
  • the general SGSN that has received the Attach Request from the UE transmits an attach reject (Attach Reject) to which the identifier of the specific SGSN is attached in order to connect the UE to a specific SGSN (Customized SGSN).
  • the UE is connected to the specific SGSN by attaching the specific SGSN identifier to the Attach Request and retransmitting.
  • the UE transmits a connection request (RRC Connection Request) with specific SGSN (Customized SGSN) connection request information to the RNC, and the RNC that has received the request receives an Attach from the UE that has established the RRC connection (RRC Connection).
  • RRC Connection Request a connection request
  • specific SGSN Customerized SGSN
  • Attach an Attach from the UE that has established the RRC connection
  • the UE is connected to the specific SGSN by selecting the specific SGSN.
  • the specific SGSN connection request information may be a low access priority indication (LAPI) or a delay tolerant access. That is, for example, the SGSN may be specified by the RNC based on information elements such as LAPI and delay tolerant access notified from the MTC terminal to the network.
  • LAPI low access priority indication
  • the RNC that has received the RRC signal to which the specific SGSN connection request information for connecting to the specific SGSN (Customized SGSN) is sent from the UE notifies the specific SGSN of the specific SGSN connection request information with an Iu signal.
  • the general SGSN that has established a session with the UE instructs the RNC to select a specific SGSN (Customized SGSN) in the next SGSN selection at the time of Iu Release (Iu Release).
  • a specific SGSN Customerized SGSN
  • Iu Release Iu Release
  • the RNC selects a specific SGSN, thereby connecting the UE to the specific SGSN.
  • the specific MME selects a handover destination MME according to the specific MME connection request information held.
  • the specific MME connection request information may be low access priority indication (LAPI) or delay tolerant access.
  • LAPI low access priority indication
  • the MME may be specified based on information elements such as LAPI and delay tolerant access notified from the MTC terminal to the network.
  • the specific MME may determine a local configuration based on the stored specific MME connection request information. Alternatively, the specific MME may determine the MME of the handover destination using the held local configuration.
  • ⁇ Aspect 11-2> When the specific MME selects a handover destination MME, the specific MME makes an inquiry to a DNS (Domain Name System) server based on the held specific MME connection request information, and as a result, the handover destination received from the DNS server. You may select from the candidate group of MME.
  • DNS Domain Name System
  • a DNS server capable of providing one or a plurality of MMEs using, as input information, subscriber location information and the specific MME connection request information.
  • the specific SGSN selects a handover destination SGSN according to the stored specific SGSN connection request information.
  • the specific SGSN connection request information may be a low access priority indication (LAPI) or a delay tolerant access.
  • LAPI low access priority indication
  • the SGSN may be specified based on information elements such as LAPI and delay tolerant access notified from the MTC terminal to the network.
  • the specific SGSN may be determined in a local configuration based on the specific SGSN connection request information held when selecting a SGSN as a handover destination. Alternatively, the specific SGSN may determine the SGSN of the handover destination using the held local configuration.
  • a DNS server capable of providing one or a plurality of SGSNs by using subscriber location information and the specific SGSN connection request information as input information.
  • the specific MME selects a handover destination MME in accordance with the specific MME connection request information held.
  • the specific MME connection request information may be low access priority indication (LAPI) or delay tolerant access.
  • LAPI low access priority indication
  • the MME may be specified based on information elements such as LAPI and delay tolerant access notified from the MTC terminal to the network.
  • the specific MME may determine a local configuration based on the specific MME connection request information held when selecting the SGSN of the handover destination. Alternatively, the specific MME may determine the SGSN of the handover destination using the held local configuration.
  • ⁇ Aspect 13-2> When the specific MME selects a handover destination SGSN, the specific MME makes an inquiry to the DNS server based on the stored specific MME connection request information, and as a result, a candidate group of handover destination MMEs received from the DNS server. You may choose from.
  • the specific SGSN selects a handover destination MME according to the specific SGSN connection request information held.
  • the specific SGSN connection request information may be a low access priority indication (LAPI) or a delay tolerant access.
  • LAPI low access priority indication
  • the MME may be specified based on information elements such as LAPI and delay tolerant access notified from the MTC terminal to the network.
  • the specific SGSN may determine a local configuration based on the specific SGSN connection request information held when selecting the MME as the handover destination. Alternatively, the specific SGSN may determine the MME of the handover destination using the held local configuration.
  • the UE transmits an RRC connection request (RRC (Radio Resource Control) Connection Request) (radio resource connection request) with specific MME (Customized MME) connection request information to the eNodeB, and the eNodeB that has received the RRC connection request.
  • RRC Radio Resource Control
  • MME Customerized MME
  • the UE is connected to the specific MME by selecting the specific MME when transmitting a Tracking Area Update Request from the UE that has established an RRC connection to the new MME.
  • the specific MME connection request information may be low access priority indication (LAPI) or delay tolerant access.
  • LAPI low access priority indication
  • the MNode may be specified by the eNodeB based on information elements such as LAPI and delay tolerant access notified from the MTC terminal to the network.
  • ⁇ Aspect 15-1> The eNodeB that has received the RRC signal with the specific MME connection request information for connecting to the specific MME (Customized MME) from the UE notifies the specific MME by the S1-AP signal of the specific MME connection request information. To do.
  • the UE transmits a connection request (RRC Connection Request) to which specific SGSN (Customized SGSN) connection request information is added to the RNC, and the RNC that has received the request transmits the RRC connection (RRC Connection) from the UE that has established the RRC connection.
  • RRC Connection Request a connection request
  • the RNC When transmitting the Area Update Request to the new SGSN, the UE is connected to the specific SGSN by selecting the specific SGSN.
  • the specific SGSN connection request information may be a low access priority indication or a delay tolerant access. In this case, for example, the SGSN may be specified by the RNC based on information elements such as LAPI and delay tolerant access notified from the MTC terminal to the network.
  • the RNC that has received the RRC signal to which the specific SGSN connection request information for connecting to the specific SGSN (Customized SGSN) is sent from the UE notifies the specific SGSN of the specific SGSN connection request information with an Iu signal.
  • the core network node connected to each terminal is selected and connected according to the service characteristics used by the terminal.
  • the core network nodes that have a specific service providing function and nodes that do not have a specific service providing function are deployed in combination, and one of the nodes is optimized for the specific service providing function.
  • the specific service providing function is not provided, the cost of the node is reduced.
  • FIG. 1 is a diagram for explaining Embodiment 1 of the present invention.
  • Embodiment 1 a configuration for connecting a UE and a specific MME at the time of Attach in EPC (Evolved Packet Core) will be described.
  • EPC Evolved Packet Core
  • UE1 (user device) indicates, for example, a mobile phone terminal (mobile device).
  • mobile device mobile phone terminal
  • MTC device mobile phone terminal
  • MBMS compatible terminal or the like
  • the eNodeB 11 is a LTE (Long Term Evolution) base station device.
  • the MMEs 21 and 22 are devices that manage mobility introduced by EPC.
  • the customized MME 22 is a specific MME to which the UE 1 is to be connected, and the general MME (21) is another MME.
  • the Customized MME 22 is configured as an MME having a configuration customized for a machine communication (MTC) service and a corresponding terminal (M2M device) (for example, a C-Plane that handles network control is reinforced). Or you may comprise as MME corresponding to MBMS.
  • MTC machine communication
  • M2M device for example, a C-Plane that handles network control is reinforced.
  • the HSS (Home Subscriber Server) 31 is a database that holds subscriber information.
  • the S-GW (Serving Gateway) 41 and the P-GW (Packet data network Gateway: PDN-GW) 51 are devices that handle the user plane.
  • the service network 61 indicates an external network.
  • eNodeB corresponds to a radio access network (RAN: Radio Access Network), and MME, S-GW, P-GW, and the like correspond to a core network (CN: Core Network).
  • RAN Radio Access Network
  • CN Core Network
  • Example 1-5 corresponds to Embodiment 1-5, respectively.
  • FIG. 3 is a sequence diagram for explaining an operation example of the first embodiment.
  • the UE is UE1 in FIG.
  • the eNodeB is the eNodeB 11 in FIG.
  • the general MME is a general MME 21 in FIG.
  • the Customized MME is a customized MME (specific MME) 22 in FIG.
  • Serving GW is S-GW 41 in FIG.
  • the PDN GW is a P-GW 51 in FIG.
  • the HSS corresponds to the HSS 31 in FIG.
  • PCRF Policy and Charging Rules Function
  • An EIR Equipment Identity Register
  • IMEI International Mobile Equipment Identity
  • Attach Request indicates that the transmission of the Attach Request from the UE to the eNodeB is sequence 1.
  • this sequence number 1 is expressed in parentheses as "Attach Request (1)". .
  • FIG. 3 is based on FIG. 5.3.2.1-1: Attach procedure of 3GPP TS23.401, and the sequence number follows that figure. For details of each sequence, refer to the description of TS23.401 5.3.2.
  • an operation sequence will be described with reference to FIGS. 1 and 3.
  • Attach Request (1) when UE1 transmits Attach Request (1), first, eNodeB 11 receives, and eNodeB 11 relays Attach Request (2) to MME.
  • the eNodeB 11 cannot uniquely determine whether the Attach Request (2) should be transferred to the general MME 21 or the Customized MME 22. Therefore, the Attach Request (2) may be transferred from the eNodeB 11 to the general MME 21.
  • terminal information (ME Identity) is acquired from UE 1 by Identity Request / Response (4, 5b).
  • the general MME 21 sends ME Identity Check Request (5b) to the EIR, and the EIR returns MD Identity Check Ack to the general MME. Further, in cooperation with the HSS 31, authentication and acquisition of a subscriber profile are performed. That is, authentication and subscriber profile acquisition are performed by the general MME 21.
  • the general MME 21 that has acquired the terminal information and the subscriber profile determines whether the UE 1 should be connected to the general MME 21 or the customized MME 22.
  • the general MME 21 instructs the eNodeB 11 to perform MME reselection with the MME selection signal: MME re-selection command (S1AP (S1AP newly introduced in this embodiment). Application) signal).
  • the general MME 21 sets the identifier of the Customized MME 22 (for example, GUMEI (Globally Unique MME Identity)) in the MME re-selection Command signal. That is, a reselection request is transmitted to the eNodeB before bearer generation in the core network, and information (GUMMEI) necessary for new MME selection is carried.
  • the MME has a function of determining whether or not the UE is a re-selection target.
  • the eNodeB 11 When the eNodeB 11 receives the MME re-selection Command signal, the eNodeB 11 selects the Customized MME 22 according to the identifier set in this signal, and transfers the Attach Request (2) to the Customized MME 22.
  • the specific MME 22 needs an Attach Request NAS (Non-Access Stratum) parameter (used for authentication between the UE and the MME), and therefore retransmits at the eNodeB 11.
  • the eNodeB 11 needs a function for holding a NAS message.
  • the Customized MME 22 After receiving the Attach Request signal, the Customized MME 22 acquires terminal information through the Identity Request / Response, and further performs authentication and subscriber profile acquisition in cooperation with the HSS 31. That is, the same processing as the general MME 21 is performed.
  • the Customized MME 22 that has acquired the terminal information and the subscriber profile determines whether the UE 1 should be connected to the general MME 21 or to the Customized MME 22.
  • the Customized MME 22 is after being reselected by the eNodeB 11, the normal Attach Procedure is continued without transmitting the MME re-selection Command signal. That is, -Transmission of Update Location Request (8) from Customized MME 22 to HSS 31. -Transmission of Update Location Ack (11) from HSS 31 to Customized MME 22.
  • the general MME 21 and the customized MME 22 have a function of determining which MME the UE 1 should be connected to.
  • Information from UE1 for example IMSI (International Mobile Subscriber Identity), IMEI (International Mobile Equipment Identity: International Mobile Equipment Identification Number (terminal identification number)), ⁇ UE network capability, ⁇ MS network capability, ⁇ Mobile station classmark 2, ⁇ Mobile station classmark 3, ⁇ Device properties, or -APN (Access Point Name), or -ID that identifies the MTC group, or ⁇ Low access priority indication, or -Delay tolerant access, or ⁇ Attach Request to be added in the future, new parameters of other NAS signals such as TA Update Request, or ⁇ Partial identifiers constituting these parameters (PLMN (Public Land Mobile Network) -id included in IMSI), Information from the HSS 31, for example ⁇ Feature-List, -APN (Access Point Name), or ⁇ New parameter of Update Location Answer / Insert Subscriber Data Request signal added in the future, or The identifiers of
  • the MME instructs the eNodeB to reselect the MME, and the eNodeB receives it and reselects the MME, and then continues the attach process (Attach Procedure).
  • the UE can be attached to the appropriate MME.
  • Example 2 As a second embodiment, another example in which the UE and the customized MME are connected at the time of Attach in EPC (Evolved Packet Core) will be described.
  • the system configuration of the second embodiment is the same as that of the first embodiment.
  • FIG. 4 is a sequence diagram illustrating an operation example of the second embodiment. Note that FIG. 4 is based on FIG. 5.3.2.1-1: Attach procedure of 3GPP TS23.401, and the sequence number follows that figure. For details of each sequence, refer to the description of TS23.401 5.3.2. The operation will be described below with reference to FIGS.
  • eNodeB 11 When UE1 transmits Attach Request (1), eNodeB 11 receives it and relays Attach Request (2) to MME. At this time, the eNodeB 11 cannot uniquely determine whether the Attach Request (2) should be transferred to the general MME 21 or the Customized MME 22. Therefore, it may be transferred to the general MME 21.
  • terminal information (ME Identity) is acquired at Identity Request / Response (5b), and authentication and subscriber profile are acquired in cooperation with HSS 31. . That is, authentication and subscriber profile are performed by the general MME 21.
  • the general MME 21 that has acquired the terminal information and the subscriber profile determines whether the UE 1 should be connected to the general MME 21 or the customized MME 22.
  • the normal Attach Procedure is continued.
  • the general MME 21 When connecting the UE1 to the Customized MME 22, the general MME 21 sends an MME change request signal (MME Change Request) (GTP (GPRS Tunneling newly introduced in this embodiment) to instruct the Customized MME 22 to change the MME. Protocol) signal).
  • MME Change Request MME Change Request
  • GTP GPRS Tunneling newly introduced in this embodiment
  • the general MME 21 sets the context information generated by the terminal authentication or the acquisition of the subscriber profile in the MME Change Request signal.
  • the Customized MME 22 When the Customized MME 22 receives the MME change request signal (MME Change Request), it retains the context information set in the MME change request signal and introduces the MME Change Response signal (newly introduced in this embodiment) to the general MME 21.
  • the GTP signal is transmitted.
  • the Customized MME 22 transmits an Update Location Request signal (8) to the HSS 31 to notify the HSS 31 that the MME has been changed.
  • the Update Location Request is re-executed by the Customized MME 22. Subsequent Attach Procedures will be implemented with the Customized MME22.
  • the customized MME 22 can omit re-authentication if the security context information received from the general MME 21 is valid.
  • Customized MME 22 continues the attach process (Attach Procedure), and the eNodeB 11 receives the Initial Context Setup Request / Attach Accept (17) from the Customized MME 22.
  • Initial Context Setup Request / Attach Accept (17) is a response to the Attach Request (2) received by the general MME 21. It should be noted that a function capable of receiving a response (Response) from another MME with respect to the general MME 21 needs to be implemented in the eNodeB 11.
  • the general MME 21 and the customized MME 22 have a function of determining which MME the UE 1 should be connected to, but this function is the same as that of the first embodiment.
  • the general MME instructs the Customized MME to change the MME, and the Customized MME changes the MME in response to this, and then continues the Attach Procedure to A suitable MME can be attached.
  • Example 3 As a third embodiment, an example in which a UE and a customized MME are connected at the time of Attach in EPC will be described.
  • the system configuration of the third embodiment is the same as that of the first embodiment.
  • FIG. 5 and 6 are sequence diagrams for explaining an operation example of the third embodiment. 5 and 6 are based on FIG. 5.3.2.1-1: Attach procedure of 3GPP TS23.401, and the sequence numbers are as shown in FIG. For details of each sequence, refer to the description of TS23.401 5.3.2. Hereinafter, the operation will be described with reference to FIG. 1, FIG. 5, and FIG.
  • eNodeB 11 When UE1 transmits Attach Request (1), eNodeB 11 first receives, and Attach Request (2) is transferred from eNodeB 11 to the MME. At this time, the eNodeB 11 cannot uniquely determine whether the Attach Request (2) should be transferred to the general MME 21 or the Customized MME 22. Therefore, it may be transferred to the general MME 21.
  • terminal information (ME Identity) is acquired by Identity Request / Response (5b). Further, the general MME 21 performs authentication and acquisition of a subscriber profile in cooperation with the HSS 31.
  • the general MME 21 that has acquired the terminal information and the subscriber profile determines whether the UE 1 should be connected to the general MME 21 or the customized MME 22.
  • the normal Attach Procedure is continued.
  • the general MME 21 When connecting the UE1 to the customized MME 22, the general MME 21 transmits an attach reject message to the UE 1 without continuing the Attach Procedure. That is, the general MME 21 transmits an Initial Context Setup Request / Attach Reject (17) to the eNodeB 11.
  • the general MME 21 can select the parameter indicating the reattach (re-attach) to the Attach Reject signal (new parameter introduced in the present embodiment) and the Customized MME 22 at the time of re-attach.
  • GUTI Globally Unique Temporary Identity
  • the GUTI parameter is composed of GUMMEI and M-TMSI (Temporary Mobile Station Identity).
  • MMEI includes MCC (Mobile Country Code), MNC (Mobile Network Code), and MME Identifier.
  • the Attach Request (1) in which the GUTI is set according to the parameter indicating the re-attach set in the Attach-Reject signal and the GUTI parameter. (Attach by GUTI) is transmitted to the eNodeB 11.
  • the eNodeB 11 determines an appropriate MME from the GUMMEI included in the GUTI, and transfers the Attach Request (2) to the Customized MME 22.
  • the UE 1 is equipped with a function that accepts a GUTI with an Attach Reject signal and uses the GUTI instructed by the Attach reject when transmitting a re-attach (Attach Request (1) in FIG. 6).
  • the MME is equipped with a function for determining whether or not this UE is a Re-Selection target.
  • the Customized MME 22 continues the normal Attach Procedure. However, although it is an Attach Request with GUTI set, the Customized MME 22 itself does not hold context information.
  • the Customized MME 22 acquires terminal information through Identity Request / Response (4), and further performs authentication and subscriber profile acquisition in cooperation with the HSS 31.
  • the general MME 21 and the customized MME 22 have a function of determining which MME the UE 1 should be connected to, but this function is the same as that of the first embodiment.
  • the general MME instructs the UE to perform MME reselection, and the UE specifies the Customized MME, and then continues the Attach Procedure to A suitable MME can be attached.
  • FIG. 7 is a sequence diagram for explaining an operation example of the fourth embodiment. Note that FIG. 7 is based on FIG. 5.3.2.1-1: Attach procedure of 3GPP TS23.401, and the sequence number follows that figure. For details of each sequence, refer to the description of TS23.401 5.3.2. The operation will be described below with reference to FIGS.
  • RRC Connection with eNodeB11 is established.
  • UE1 first transmits an RRC Connection Request signal to eNodeB11.
  • the UE 1 uses this parameter to indicate that a connection to the Customized MME 22 is required (a new value of the User Identity, Establishment Cause, or a new parameter (a value or a parameter newly introduced in this embodiment), or
  • a part of identifiers PLMN-id (Public Land Mobile Network Identity) included in IMSI) that configures these parameters is set.
  • UE1 notifies eNodeB that it is possible to connect to the Customized MME via RRC Connection Request.
  • New parameter of RRC Connection Request (establishment factor indicating the cause of the establishment of the cause of the RRC Connection Request) New Value or new parameter) is implemented.
  • the eNodeB 11 When the eNodeB 11 receives the RRC Connection Request signal, the eNodeB 11 stores that the UE 1 should be connected to the Customized MME 22 and continues the subsequent RRC Connection Procedure.
  • eNodeB 11 After the RRC connection is established, when UE1 transmits Attach Request (1), eNodeB 11 receives it. At this time, the eNodeB 11 transfers the Attach Request (2) to the Customized MME 22 based on the information stored when the RRC Connection Request (1) is received (UE1 should be connected to the Customized MME 22). *
  • Attach Request (2) a new parameter of RRC Connection Request notifying that connection to the Customized MME received by RRC Connection Request is possible (new Value or new parameter of Establishment Cause 11) is set in eNodeB11 by eNodeB11. Be notified.
  • the Customized MME 22 receives the new parameter of the RRC Connection Request (new parameter of the RRC Connection Request) or the new parameter of the RV Connection Request that is received by the RRC Connection Request received at the Attach Request (2) or the new parameter of the RRC Connection Request or the new parameter of the V .
  • the UE 1 has a function of instructing the eNodeB 11 which of the general MME 21 and the customized MME 22 should be connected.
  • the instruction to eNodeB 11 is not an identifier that can uniquely select MME, but information such as MME type or service type. .
  • the eNodeB 11 has a function of determining which MME the UE 1 should be connected to.
  • the MME is selected by the user ID (User Identity) in the RRC Connection Request, the new value of the communication establishment factor (Establishment Cause), or a new parameter, or an identifier of a part of these parameters. Any one or a combination of two or more is performed.
  • the new parameter includes an ID for identifying the MTC group, an APN, and the like.
  • the UE instructs the eNodeB to select the MME, and the eNodeB receives the request and designates the Customized MME, and then continues the Attach Procedure to appropriately select the UE.
  • MME can be attached.
  • Example 5 As a fifth embodiment, an example will be described in which the UE and the customized MME are connected during tracking area update (TA Update) in EPC.
  • the configuration of the fifth embodiment is the same as that of the first embodiment.
  • FIG. 8 and 9 are sequence diagrams for explaining an operation example of the fifth embodiment.
  • FIG. 8 is based on FIG. 5.3.5-1: S1 Release Procedure of 3GPP TS23.401. Reference is made to TS23.401 5.3.5.
  • FIG. 9 is based on FIG. 5.3.3.1-1: Tracking Area Update procedure with Serving GW change. Reference is made to 3GPP TS 23.401 5.3.3. The operation will be described with reference to FIGS. 1, 8, and 9 (and a part of FIG. 3).
  • eNodeB 11 When UE1 transmits an Attach Request (1 in FIG. 3), eNodeB 11 first receives, and the Attach Request is relayed from eNodeB 11 to the MME (see 2 in FIG. 3).
  • the eNodeB 11 cannot uniquely determine whether the Attach Request should be transferred to the general MME 21 or the Customized MME 22. Therefore, the Attach Request may be transferred to the general MME 21.
  • the general MME 21 After receiving the Attach Request, the general MME 21 acquires terminal information through Identity Request / Response (see 4 in FIG. 3), and further performs authentication and acquisition of the subscriber profile in cooperation with the HSS 31.
  • the general MME 21 that has acquired the terminal information and the subscriber profile determines whether the UE 1 should be connected to the general MME 21 or the customized MME 22. Thereafter, the normal Attach Procedure is continued. When connecting to the general MME 21, the process is completed here.
  • the general MME21 When connecting the UE1 to the customized MME22, the general MME21 performs S1 Release as shown in FIG. 8 in order to cause the UE1 to perform tracking area update (TA Update). At this time, the general MME 21 transmits the S1 UE Context Release Command (4) to the eNodeB 11.
  • the general MME 21 is an S1 UE Context Release Command (4), and indicates an MME to be selected when the eNodeB establishes an S1 Connection with the MME next by an MME identifier (eg, GUMEI).
  • MME identifier eg, GUMEI
  • the parameter for instructing eNodeB to specify GUMMEI for specifying the next MME at the time of S1 Release for load balancing TAU activation is a new parameter.
  • the eNodeB 11 continues to hold the MME identifier as information for the next MME selection while holding the session information for the UE 1 even after the completion of the S1 Release.
  • MME Identifier MME identifier
  • the Customized MME 22 continues the normal TA Update Procedure after receiving the TAU Request (3).
  • the Customized MME 22 transmits a Context Request (4) to the general MME 21 and receives a response Context Response (5).
  • the Customized MME 22 When the S-GW is relocated, the Customized MME 22 sends a Context Acknowledge (7) including an instruction to change the S-GW to the general MME, and the Customized MME 22 selects a new S-GW 41 (new Serving GW). Then, the Customized MME 22 transmits a Create Request Request (8) to the new S-GW 41.
  • the new S-GW 41 (new Serving GW) sends a Modify Bearer Request (9) to the P-GW 51, and when the response is received from the P-GW 51, the new S-GW creates the Create Session Response ( 11) is returned to the Customized MME 22.
  • the Customized MME 22 transmits the Update Location (12) to the HSS 31.
  • the general MME 21 that has received the Cancel Location (13) from the HSS 31 deletes the MM context, and transmits an acknowledgment (Cancel Location Ack) (14) to the HSS 31.
  • An affirmative response (Updata Location Ack) (17) to the Updata Location (12) is transmitted from the HSS 31 to the Customized MME 22.
  • the general MME 21 transmits a Delete Session Request (18) to the old S-GW 41 (old Serving GW), and a response (19) is transmitted from the old S-GW 41 (old Serving GW) to the general MME 21.
  • the TAU Accept (20) is transmitted from the Customized MME 22 to the UE1.
  • the UE1 When the GUTI is included in the TAU Accept (20), the UE1 returns a TAU Complete (21) to the Customized MME 22 to acknowledge the received signal TAU Accept (20).
  • the general MME 21 and the customized MME 22 have a function of determining which MME the UE 1 should be connected to, but this function is the same as that of the first embodiment.
  • TA Update Procedure is used in the procedure of FIG. 9, but the feature of this embodiment is that the eNodeB 11 selects an MME. For this reason, for example, it is also possible to use other procedures (Procedure) for re-establishing S1 Connection such as Service Request.
  • the general MME instructs the eNodeB to re-select the MME, and the eNodeB receives the request and designates the Customized MME at the next MME selection, and then continues the procedure (Procedure). By doing so, the UE can be connected to an appropriate MME.
  • FIG. 2 is a diagram illustrating a system configuration of the second embodiment.
  • UE 101 is, for example, a mobile phone terminal (mobile device).
  • a mobile phone terminal mobile device
  • the above-described MTC device, MBMS compatible terminal, or the like may be used.
  • Node B 111 and RNC (Radio Network Controller) 171 represent radio access devices employed in the UMTS system.
  • General SGSN 121 and Customized SGSN 122 are in-zone devices used for UMTS and may or may not handle the user plane depending on the connection form.
  • the user plane when the SGSN does not handle the user plane is set between the S-GW and the RNC.
  • the HLR (Home Location Register) 131 is a database that holds subscriber information.
  • GGSN General Packet Radio Service Support Node: expressed as “gateway GPRS support node” in claims
  • the service network 161 indicates an external network (data packet network).
  • the Node B 111 and the RNC 171 correspond to the radio access networks RAN, SGSN, GGSN and the like to the core network.
  • FIG. 10 is a sequence diagram for explaining an operation example of the sixth embodiment and is based on 3GPP TS 23.060 6.5 FIG.
  • the MS Mobile Station
  • the UE 101 in FIG. RAN Radio Access Network
  • the general SGSN is a general SGSN 121 in FIG.
  • the Customized SGSN (specific SGSN) is a customized SGSN (specific SGSN) 122 in FIG.
  • the GGSN is the GGSN 141 in FIG.
  • the HLR corresponds to the HLR 131 in FIG.
  • VLR Mobile Switching Center
  • EIR Equipment Identifier Register
  • Node B 111 When UE 101 (MS) transmits Attach Request (1), Node B 111 first receives and forwards Attach Request (1) to RNC 171. The RNC 171 forwards Attach Request (1) to the SGSN. At this time, the RNC 171 cannot uniquely determine whether the Attach Request should be transferred to the general SGSN 121 or the Customized SGSN 122. Therefore, it may be transferred to the general SGSN 121.
  • the terminal information is acquired by Identity Request / Response (3), and further, in cooperation with the HLR 131, the authentication and the subscriber profile are acquired.
  • the general SGSN 121 is used until authentication and subscriber profile acquisition.
  • the general SGSN 121 that has acquired the terminal information and the subscriber profile determines whether the UE 101 should be connected to the general SGSN 121 or the customized SGSN 122.
  • the normal Attach Procedure is continued.
  • the general SGSN 121 transmits an SGSN re-selection command (a RANAP signal newly introduced in this embodiment) to instruct the RNC 171 to perform SGSN reselection.
  • the general SGSN 121 sets an identifier (for example, RAI (Routing Area Identifier), NRI (Network Resource Identifier), etc.) that identifies the Customized SGSN 122 in the SGSN re-selection Command signal. That is, the general SGSN 121 requests the RNC 171 to re-select the SGSN, and puts information (RAI) necessary for selecting the specific SGSN 122 at that time. In the case of reselection in the same pool, NRI may be used.
  • the SGSN has a function of determining whether the UE 101 is a re-selection target.
  • the RNC 171 When the RNC 171 receives the SGSN re-selection Command signal, the RNC 171 selects the Customized SGSN 122 according to the identifier set in this signal and transfers Attach Request (1). Since the specific SGSN 122 requires an Attach Request NAS (Non Access Stratum) parameter, the RNC 171 resends the Attach Request.
  • the RNC 171 has a function for holding a NAS message.
  • the customized SGSN 122 acquires terminal information by Identity Request / Response, and further performs authentication and subscriber profile acquisition in cooperation with the HLR 131. That is, the same processing as the general SGSN 121 is performed.
  • the customized SGSN 122 that has acquired the terminal information and the subscriber profile determines whether the UE 101 should be connected to the general SGSN 121 or the customized SGSN 122.
  • the RNC 171 since the RNC 171 re-selects, the normal Attach Procedure is continued without transmitting the SGSN re-selection Command signal.
  • the general SGSN 121 and the customized SGSN 122 have a function of determining which SGSN the UE 101 should be connected to, but this determination is based on information from the UE 101 (for example, -IMSI (International Mobile Subscriber Identity), ⁇ IMEI, ⁇ UE network capability, ⁇ MS network capability, ⁇ Mobile station classmark 2, ⁇ Mobile station classmark 3, ⁇ Device properties, -APN (Access Point Name), or -ID that identifies the MTC group, or ⁇ Low access priority indication, or -Delay tolerant access, or -New parameters of other NAS signals such as Attach Request or TA Update Request to be added in the future, or partial identifiers constituting these parameters (PLMN-id etc.
  • HLR 131 Information from the HLR 131 (eg, Feature-List, ⁇ APN, -ID that identifies the MTC group, or ⁇ New parameter of Update Location Answer / Insert Subscriber Data Request signal added in the future, or ⁇ Partial identifiers that make up these parameters) Any one or a combination of the above is performed.
  • the SGSN instructs the RNC to perform SGSN reselection, and the RNC reselects the SGSN in response to the instruction, and then continues the Attach Procedure to appropriately select the UE. Attach to any SGSN.
  • Example 7 As Example 7, an example in which a UE and a specific SGSN are connected during Attach in UMTS will be described.
  • the configuration of the seventh embodiment is the same as that of the sixth embodiment.
  • FIG. 11 is a sequence diagram for explaining an operation example of the seventh embodiment. The operation will be described with reference to FIGS.
  • Node B 111 When UE 101 transmits Attach Request (1), first, Node B 111 receives and forwards it to RNC 171. RNC 171 forwards this to SGSN. At this time, the RNC 171 cannot uniquely determine whether the Attach Request should be transferred to the general SGSN 121 or the Customized SGSN 122. Therefore, it may be transferred to the general SGSN 121.
  • the general SGSN 121 After receiving the Attach Request, the general SGSN 121 acquires terminal information through the Identity Request / Response, and further performs authentication and subscriber profile acquisition in cooperation with the HLR 131. The general SGSN 121 is used until authentication and subscriber profile acquisition.
  • the general SGSN 121 that has acquired the terminal information and the subscriber profile determines whether the UE 101 should be connected to the general SGSN 121 or the customized SGSN 122.
  • the normal Attach Procedure is continued.
  • the general SGSN 121 When connecting the UE 101 to the Customized SGSN 122, the general SGSN 121 transmits an SGSN Change Request (a GTP signal newly introduced in the present embodiment) to instruct the Customized SGSN 122 to change the SGSN.
  • an SGSN Change Request (a GTP signal newly introduced in the present embodiment) to instruct the Customized SGSN 122 to change the SGSN.
  • the general SGSN 121 sets the context information generated by the mobile device authentication or the acquisition of the subscriber profile in the SGSN Change Request signal. That is, when the SGSN change is requested from the general SGSN 121 to the customized SGSN 122, the context is notified to a new SGSN (Customized SGSN 122).
  • the SGSN has a function for determining whether the UE 101 is a re-selection target.
  • the SGSN Change Request signal holds the context information set in the SGSN Change Request signal, and the SGSN Change Response signal (GTP newly introduced in the present embodiment, to the general SGSN 121). Signal).
  • the Customized SGSN 122 transmits an Update Location signal (8) to the HLR 131 to notify the HLR 131 that the SGSN has been changed.
  • the customized SGSN 122 can omit re-authentication if the security context information received from the general SGSN 121 is valid.
  • the Customized SGSN 122 continues the Attach Procedure, and the RNC 171 receives the Attach Accept signal (9) from the Customized SGSN 122. After that, the normal Attach Procedure is continued.
  • the general SGSN 121 and the customized SGSN 122 have a function of determining which SGSN the UE 101 should be connected to, but this function is the same as that of the sixth embodiment.
  • the general SGSN instructs the specific SGSN to change the SGSN, and the specific SGSN changes the SGSN in response to the instruction, and then continues the attach process (Attach Procedure).
  • Attach Procedure the attach process
  • Example 8> As an eighth embodiment, an example in which a UE and a specific SGSN are connected at the time of Attach in UMTS will be described.
  • the configuration of the eighth embodiment is the same as that of the sixth embodiment.
  • 12 and 13 are sequence diagrams for explaining an operation example of the eighth embodiment. The operation will be described with reference to FIG. 2, FIG. 12, and FIG.
  • Node B 111 When UE 101 (MS) transmits Attach Request (1), Node B 111 first receives it and forwards it to RNC 171. The RNC 171 forwards this to the SGSN. At this time, the RNC 171 cannot uniquely determine whether the Attach Request should be transferred to the general SGSN 121 or the Customized SGSN 122. Therefore, it may be transferred to the general SGSN 121.
  • the general SGSN 121 After receiving the Attach Request (1), the general SGSN 121 acquires terminal information through Identity Request / Response (3), and further performs authentication and subscriber profile acquisition in cooperation with the HLR 131.
  • the general SGSN 121 that has acquired the terminal information and the subscriber profile determines whether the UE 101 should be connected to the general SGSN 121 or the customized SGSN 122.
  • the normal Attach Procedure is continued.
  • the general SGSN 121 When connecting the UE 101 to the Customized SGSN 122, the general SGSN 121 transmits an Attach Reject signal (9) to the UE 101 without continuing the Attach Procedure.
  • the general SGSN 121 includes a parameter for instructing a reattach (re-attach) to the Attach Reject signal, and a RAI (Routing Area Identity) parameter (in this embodiment) so that the RNC 171 can select the Customized SGSN 122 at the time of re-attach.
  • RAI Ring Area Identity
  • the UE 101 needs to have a function of accepting RAI by using Attach Reject and using RAI instructed by “reject” during Re-attach.
  • the SGSN has a function of determining whether the UE 101 is a re-selection target.
  • (1) is transmitted to the RNC 171 (Re-Attach by P-TMSI (Packet Temporary Mobile Subscriber Indentifier)).
  • P-TMSI Packet Temporary Mobile Subscriber Indentifier
  • the RNC 171 determines an appropriate SGSN from the RAI, and transfers the Attach Request to the Customized SGSN 122.
  • Customized SGSN 122 continues the normal Attach Procedure.
  • the Customized SGSN 122 itself does not hold context information. For this reason, after receiving the Attach Request signal (1), terminal information is acquired by Identity Request / Response (3), and further, authentication and subscriber profile acquisition are performed in cooperation with the HLR 131.
  • the general SGSN 121 and the customized SGSN 122 have a function of determining which SGSN the UE 101 should be connected to, but this function is the same as that of the sixth embodiment.
  • the general SGSN instructs the UE to re-select the SGSN, and the UE specifies the specific SGSN in response to the instruction, and then continues the Attach Procedure to An appropriate SGSN can be attached.
  • Example 9 As Example 9, an example in which a UE and a specific SGSN are connected at the time of Attach in UMTS will be described.
  • the configuration of the ninth embodiment is the same as that of the sixth embodiment.
  • FIG. 14 is a sequence diagram illustrating an operation example of the ninth embodiment. The operation will be described with reference to FIGS.
  • RRC Connection with the RNC 171 is established.
  • the UE 101 first transmits an RRC connection request signal to the RNC 171.
  • the UE 101 uses a parameter indicating that connection to the Customized SGSN 122 is required for the RRC Connection Request signal (a new value of User Identity, Establishment Cause, or a new parameter (a new value or parameter introduced in this embodiment). ) Or a part of identifiers (PLMN-id included in IMSI) constituting these parameters).
  • the RNC 171 When the RNC 171 receives the RRC Connection Request signal, the RNC 171 stores that the UE 101 should be connected to the Customized SGSN 122 and continues the subsequent RRC Connection Procedure.
  • the Node B 111 After the RRC Connection is established, when the UE 101 transmits Attach Request (1), the Node B 111 first receives and forwards it to the RNC 171.
  • RNC 171 forwards this to SGSN.
  • the RNC 171 forwards the Attach Request signal to the Customized SGSN 122 from the information stored when the RRC Connection Request signal is received.
  • Attach Request a parameter indicating that connection to the Customized SGSN 122 received at the RRC Connection Request is required (User Identity, Establishment Cause New Value, or a new parameter (new value or parameter introduced in this example). ), Or a part of identifiers constituting these parameters (PLMN-id included in the IMSI) is set by the RNC 171 and notified to the Customized SGSN 122.
  • the Customized SGSN 122 continues the normal Attach Procedure after receiving the Attach Request.
  • the Customized SGSN 122 is a parameter received by the Attach Request indicating that it needs to be connected to the Customized SGSN 122 (the parameter received by the RNC 171 in the RRC Connection Request, and is set to the UserId, the UserId.
  • a new value or a new parameter (a new value or parameter introduced in the present embodiment) or a part of an identifier (PLMN-id included in the IMSI) constituting these parameters is held.
  • the UE 101 has a function of instructing the RNC 171 which of the general SGSN 121 and the customized SGSN 122 should be connected to, but at this time, the UE 101 holds all the SGSN information on the core network. Since it cannot be performed, the instruction to the RNC 171 is not an identifier for uniquely selecting the SGSN but information such as an SGSN type or a service type.
  • the RNC 171 has a function of determining which SGSN the UE 101 should be connected to. As described above, this determination is based on the new value of User Identity, Establishment Cause, or a new parameter (introduced in this embodiment). New values or parameters), or a part of identifiers constituting these parameters, or a combination of a plurality of identifiers.
  • the new parameter includes an ID for identifying the MTC group, an APN, and the like.
  • the UE 101 instructs the RNC 171 to select an SGSN, and the RNC 171 receives the instruction and designates a specific SGSN, and then continues the Attach Procedure.
  • the UE 101 can be attached to an appropriate SGSN.
  • Example 10 As Example 10, an example in which a UE and a specific SGSN are connected at the time of RA Update in UMTS will be described.
  • the configuration of the tenth embodiment is the same as that of the sixth embodiment.
  • 15 and 16 are sequence diagrams for explaining an operation example of the tenth embodiment. Hereinafter, the operation will be described with reference to FIGS. 2, 15, 16, and 10.
  • the Node B 111 When the UE 101 transmits an Attach Request (see 1 in FIG. 10), the Node B 111 first receives it and transfers it to the RNC 171. RNC 171 forwards this to SGSN. At this time, the RNC 171 cannot uniquely determine whether the Attach Request should be transferred to the general SGSN 121 or the Customized SGSN 122. Therefore, it may be transferred to the general SGSN 121.
  • the general SGSN 121 After receiving the Attach Request, the general SGSN 121 acquires terminal information through the Identity Request / Response (see 3 in FIG. 10), and further performs authentication and acquisition of the subscriber profile in cooperation with the HLR 131.
  • the general SGSN 121 that has acquired the terminal information and the subscriber profile determines whether the UE 101 should be connected to the general SGSN 121 or the customized SGSN 122.
  • the normal Attach Procedure is continued.
  • the general SGSN 121 When connecting the UE 101 to the customized SGSN 122, the general SGSN 121 performs Iu Release as shown in FIG. 15 in order to cause the UE 101 to perform RA (Routing Area) Update.
  • the general SGSN 121 transmits an IU Release Command signal to the RNC 171 (see 4 in FIG. 15).
  • the general SGSN 121 indicates an SGSN that should be selected when the RNC establishes an Iu Connection with the SGSN next by an SGSN identifier (for example, RAI, NRI, etc.) using an IU Release Command signal.
  • NRI may be used in the same pool.
  • the RNC 171 continues to hold the SGSN identifier as information for next SGSN selection while holding the session information for the UE 101 even after the completion of the Iu Release.
  • UE 101 When Iu Release is performed (after transmission of IU Release Complete (6) from RNC 171 to general SGSN 121), UE 101 then transmits RAU (RA Update) Request (2) as shown in FIG.
  • the Node B 111 receives the RAU Request (2), and the Node B 111 transfers the RAU Request (3) to the RNC 171.
  • RNC 171 forwards this to SGSN. At this time, since the RNC 171 has already been released, the SGSN is selected and the Iu Connection is established.
  • the RNC 171 selects the Customized SGSN 122 according to the SGSN identifier indicated by the IU Release Command signal received from the general SGSN 121.
  • the RNC has a function of holding the next RAI for each UE.
  • the Customized SGSN 122 continues the normal RA Update Procedure after receiving the RAU Request. Since the P-TMSI (RAI) on the NAS indicates a general SGSN that is an old SGSN, Context is acquired.
  • RAU P-TMSI
  • the general SGSN 121 and the customized SGSN 122 have a function of determining which SGSN the UE 101 should be connected to, but this function is the same as that of the sixth embodiment.
  • the RA Update Procedure is used in the procedure of FIG. 16, but the RNC 171 is used for SGSN selection.
  • the Iu Connection such as PDP Context Activation is reestablished. It can also be realized by using Procedure.
  • the general SGSN instructs the RNC to perform SGSN reselection, and the RNC receives this and designates a specific SGSN at the next SGSN selection, and then continues the procedure.
  • the UE can be connected to the appropriate SGSN.
  • FIG. 17 is a diagram illustrating a configuration (system configuration) of the eleventh embodiment.
  • a handover source eNodeB (Source eNodeB) 202 and a handover destination target eNodeB (Target eNodeB) 203 are provided as a RAN (Radio Access Network) that includes the UE 201 and is wirelessly connected to the UE 201.
  • RAN Radio Access Network
  • the CN (Core Network) includes a source MME (Source MME) 204, a target MME (Target MME) 205, a source SGW (Source SGW) 206, a target SGW (Target SGW) 207, a DNS server 209, an HSS 211, and a PGW 208, and a PGW 208.
  • a source MME (Source MME) 204
  • a target MME target MME
  • a source SGW Source SGW
  • target SGW target SGW
  • DNS server 209 an HSS 211
  • PGW 208 Packet Control Protocol
  • PGW 208 Packet Control Protocol
  • Handover Required (2) includes information such as Target TAI (Tracking Area Identity).
  • the Source MME 204 determines execution of an inter-MME handover (Inter MME handover) from the above information to the target MME (Target MME) 205.
  • the Target MME 205 is determined using the specific MME connection request information held by the Source MME 204.
  • the specific MME connection request information held by the source MME 204 is, for example, the eNodeB 202 that has received the RRC signal to which the specific MME connection request information for connecting to the specific MME (Customized MME) is received from the UE 201.
  • the S1-AP signal notifies the source MME 204, which is a specific MME, and holds it in the source MME 204.
  • the target MME 205 (handover destination MME), it may be determined using the local configuration held in the source MME 204 based on the specific MME connection request information held in the source MME 204.
  • the local configuration is, for example, information (configuration information) set by an operator and internally managed and held by the device (MME) (for example, when an MTC subscriber (MTC terminal) performs handover, Including information according to the moving area of the handover destination).
  • the specific MME connection request information is APN (Access Point Name)
  • local information local configuration
  • LAPI Low Access Priority Indication
  • the MME of the handover destination Make a selection.
  • the Target MME 205 may be determined using the local configuration held by the Source MME 204.
  • the Source MME 204 sets specific MME connection request information together with location information such as Target TAI (Tracking Area Identity), and determines the Target MME 205 by performing “DNS Query” on the DNS server 209. You may do it.
  • Target TAI Tracking Area Identity
  • the Source MME 204 When the Source MME 204 decides to execute the Inter MME handover to the Target MME 205, the Source MME 204 sends a Forward Relocation Request (3) to the Target MME 205. At that time, the source MME 204 may set the specific MME connection request information held by the source MME 204 in the forward relocation request (3).
  • Target MME 205 executes a further Inter MME handover, it becomes possible to select a specific MME (Customized MME) using the specific MME connection request information held in the Target MME 205.
  • Inter MME handover processing is performed according to the related technology.
  • Example 12 As Example 12, an example of SRNS (Serving Radio Network Subsystem) relocation (handover) across a specific SGSN (Customized SGSN) in UMTS will be described. 19 and 20 are diagrams for explaining the twelfth embodiment. FIG. 21 is a sequence diagram for explaining an operation example of the twelfth embodiment.
  • SRNS Serving Radio Network Subsystem
  • a UE 301 is provided, and a handover source RNC (Target RNC) 302 and a target RNC (Target RNC) 303 as a handover destination are provided as a RAN (Radio Access Network) that is wirelessly connected to the UE 301.
  • the CN Core Network
  • the CN includes a source SGSN (Source SGSN) 304, a target SGSN (Target SGSN) 305, a source SGW (Source SGW) 306, a target SGW (Target SGW) 307, a DNS server 309, an HSS 311, and a PGW 308.
  • FIG. 21 is based on FIG. 39: SRNS Relocation Procedure of 3GPP TS 23.060, and the sequence number follows that figure. For details of each sequence, refer to the description of 3GPP TS 23.060 6.9.2.2.1 (however, in FIG. 39 of 3GPP TS 23.060, the terminal is MS (Mobile Station). In FIG. 21, it is UE).
  • FIG. 20 shows a case where the CN is configured by EPC.
  • the operation of the present embodiment is effective in the configuration shown in FIGS. is there. 20 is different from the CN of FIG. 19 in that the source SGW (Source SGW) 306 and the target SGW (Target SGW) 307 are not provided in the CN of FIG. 19, and that the GGSN 408 is provided instead of the PGW 308 of FIG. is doing.
  • Source SGW Source SGW
  • Tiget SGW target SGW
  • the source RNC 402 When the source RNC 402 detects, for example, signal degradation in the connection with the UE 401, it transmits Relocation Required (2) to the Source SGSN 404.
  • Relocation Required (2) includes information such as Target ID.
  • the Source SGSN 404 determines execution of inter SGSN SRNS (Serving Radio Network Subsystem) relocation to the Target SGSN 405 from the information.
  • SGSN SRNS Serving Radio Network Subsystem
  • the Target SGSN 405 is determined using the specific SGSN connection request information held by the Source SGSN 404.
  • the specific SGSN connection request information held by the Source SGSN 404 is the RNC 403 that has received the RRC (Radio Resource Control) signal with the specific SGSN connection request information for connecting to the specific SGSN (Customized SGSN) from the UE 401.
  • the specific SGSN connection request information is notified to the source SGSN 404, which is the specific SGSN, by an Iu signal, and held in the source SGSN 404.
  • the target SGSN 405 may be determined by local configuration based on the specific SGSN connection request information held in the Source SGSN 404. Or you may determine using the local configuration which Source SGSN404 holds. Alternatively, the Source SGSN 404 may determine the Target SGSN 405 by setting specific SGSN connection request information together with location information such as a Target ID and performing DNS Query to the DNS server 409.
  • the Source SGSN 404 When the source SGSN 404 decides to execute the inter SGSN SRNS relocation to the Target SGSN 405, the Source SGSN 404 transmits a Forward Relocation Request (3) to the Target SGSN 405.
  • the Source SGSN 404 may set specific SGSN connection request information held by the Source SGSN 404 in this signal (Forward Relocation Request).
  • Target SGSN 405 can select a specific SGSN (Customized SGSN) using specific SGSN connection request information when executing further inter SGSN SRNS relocation.
  • a specific SGSN Customerized SGSN
  • inter SGSN SRNS relocation processing is performed according to the related technology.
  • FIG. 22 is a diagram illustrating the configuration of the thirteenth embodiment.
  • the UE 501 includes a source eNodeB (Source eNodeB) 502 and a target RNC (Target RNC) 503 as a RAN (Radio Access Network) that is wirelessly connected to the UE 501.
  • Source eNodeB Source eNodeB
  • target RNC Target RNC
  • a CN (Core Network) includes a source MME (Source MME) 504, a target SGSN (Target SGSN) 505, an SGW 506, a DNS server 508, an HSS 510, and a PGW 507, and is connected to the service network 509 via the PGW 507.
  • FIG. 23 is a sequence diagram for explaining an operation example of the thirteenth embodiment. Note that FIG. 23 is based on FIG. 5.5.2.1.2-2: E-UTRAN to UTRAN Iu mode Inter RAT HO, preparation phase of 3GPP TS23.401, and the sequence numbers are the same as those in FIG. For details of each sequence, refer to the description of TS23.401 5.5.2.2.1.2.
  • the source eNodeB 502 detects signal degradation in the connection with the UE 501, the source eNodeB 502 transmits Handover Required (2) to the source MME 504.
  • Information such as Target TAI (Tracking area ID) is included in Handover Required (2), and Source MME 504 performs Inter RAT (Radio Access Technology) execution to Target SGSN 505 from that information.
  • Target TAI Track Area ID
  • Inter RAT Radio Access Technology
  • the Target SGSN 505 is determined using the specific MME connection request information held by the Source MME 504.
  • the target SGSN 505 may be determined by local configuration based on specific MME connection request information. Or you may determine using the local configuration which Source MME504 holds. Further, the Source MME 504 may determine the Target SGSN 505 by setting specific MME connection request information together with location information such as a Target ID and performing a DNS query to the DNS server 508.
  • the Source MME 504 decides to execute the Inter RAT handover to the Target SGSN 505, the Source MME 504 sends a Forward Relocation Request (3) to the Target SGSN 505.
  • the source MME 504 may set specific MME connection request information held by the source MME 504 in this signal.
  • the Target SGSN 505 can select a specific MME (Customized MME) by using the specific MME connection request information when executing further Inter RAT handover.
  • Inter RAT handover processing is performed according to the related technology.
  • Example 14 As Example 14, an example in which a specific SGSN (Customized SGSN) is handed over to a specific MME (Customized MME) in EPC will be described.
  • the configuration of the fourteenth embodiment is shown in FIG. 22, but the direction of handover is reversed.
  • a sequence for explaining an operation example of the fourteenth embodiment is basically shown in FIG. SGSN and MME, and RNC and eNodeB The description (operation sequence) is reversed (becomes sequence operation in the reverse direction).
  • FIG. 24 is a sequence diagram for explaining an operation example of the fifteenth embodiment. Note that FIG. 24 is based on FIG. 5.3.3.1-1: Tracking Area Update procedure with Serving GW change of 3GPP TS 23.401, and the sequence numbers are the same as those in FIG. For details of each sequence, refer to the description of TS23.401 5.3.3. The operation will be described below with reference to FIGS.
  • RRC Radio Resource Control
  • the UE 1 uses a parameter indicating that the RRC Connection Request signal needs to be connected to the Customized MME 22 (User Identity, Establishment Cause New Value, or a new parameter (value or parameter newly introduced in this embodiment)).
  • a partial identifier PLMN-id included in the IMSI that configures these parameters is set.
  • UE1 implements a new RRC Connection Request parameter (new value or new parameter of Establishment Cause) that notifies the eNodeB that it can be connected to the Customized MME in the RRC Connection Request.
  • RRC Connection Request parameter new value or new parameter of Establishment Cause
  • the eNodeB 11 When the eNodeB 11 receives the RRC Connection Request signal, the eNodeB 11 stores that the UE 1 should be connected to the Customized MME 22 and continues the subsequent RRC Connection Procedure.
  • the eNodeB 11 When the UE1 transmits the TAU Request (2) after the RRC connection is established, the eNodeB 11 receives it. At this time, the eNodeB 11 transfers the TAU Request (3) from the information stored when the RRC Connection Request is received to the Customized MME 22. In the TAU Request (3), a new parameter (Evaluation Cause New Value 11 or New parameter B of Establishment Cause) that indicates that connection to a specific MME (Customized MME) received by the RRC Connection Request is possible is made. It is set and notified to the Customized MME 22.
  • a new parameter (Evaluation Cause New Value 11 or New parameter B of Establishment Cause) that indicates that connection to a specific MME (Customized MME) received by the RRC Connection Request is possible is made. It is set and notified to the Customized MME 22.
  • the Customized MME 22 after receiving the TAU Request (3), the normal TAU Procedure is continued.
  • the Customized MME 22 notifies the fact that it can be connected to the specific MME (Customized MME) received in the RRC Connection Request set in the received TAU Request (3), and a new parameter (EstablishmentVest New in the RRC Connection Request). Or a new parameter).
  • the UE 1 has a function of instructing the eNodeB 11 which of the general MME 21 and the specific MME (Customized MME) 22 should be connected.
  • the instruction to eNodeB 11 is not an identifier that can uniquely select MME, but information such as MME type or service type. .
  • the eNodeB 11 has a function of determining which MME the UE 1 should be connected to.
  • the MME is selected by the user ID (User Identity) in the RRC Connection Request, the new value of the communication establishment factor (Establishment Cause), or a new parameter, or an identifier of a part of these parameters. Any one or a combination of two or more is performed.
  • the new parameter includes an ID for identifying the MTC group, an APN, and the like.
  • the UE instructs the eNodeB to select the MME, and the eNodeB receives the request and designates the Customized MME, and then continues the TAU Procedure to appropriately set the UE.
  • the location can be registered with the MME.
  • FIG. 25 is a sequence diagram illustrating an operation example of the sixteenth embodiment. Note that FIG. 25 is based on FIG. 36: Iu mode RA Update procedure of 3GPP TS 23.060, and the sequence numbers are in accordance with FIG. For details of each sequence, refer to the description of TS 23.060 6.9.2 (in FIG. 36 of 3GPP TS 23.060, the terminal is an MS, but in FIG. 25, it is a UE). The operation will be described below with reference to FIGS.
  • the UE 101 first establishes RRC Connection with RNC 171 in order to transmit Routing Area Update Request to SGSN. In order to establish the RRC connection, the UE 101 first transmits an RRC connection request signal to the RNC 171.
  • the UE 101 uses a parameter indicating that connection to the Customized SGSN 122 is required for the RRC Connection Request signal (a new value of User Identity, Establishment Cause, or a new parameter (a new value or parameter introduced in this embodiment). ) Or a part of identifiers (PLMN-id included in IMSI) constituting these parameters).
  • the RNC 171 When the RNC 171 receives the RRC Connection Request signal, the RNC 171 stores that the UE 101 should be connected to the Customized SGSN 122 and continues the subsequent RRC Connection Procedure.
  • the Node B 111 After the RRC Connection is established, when the UE 101 transmits the Routing Area Update Request (1), the Node B 111 first receives the data and forwards it to the RNC 171.
  • the RNC 171 forwards this to SGSN.
  • the RNC 171 transfers the Routing Area Update Request signal to the Customized SGSN 122 from the information stored when the RRC Connection Request signal is received.
  • a parameter indicating that it is necessary to connect to the Customized SGSN 122 received at the RRC Connection Request (a new value of the User Identity, Establishment Cause, or a new parameter introduced in this example) Or a part of identifiers (PLMN-id included in the IMSI)) set by the RNC 171 and notified to the Customized SGSN 122.
  • the Customized SGSN 122 continues the normal Routing Area Update Procedure after receiving the Routing Area Update Request.
  • the Customized SGSN 122 is a parameter that is set in the received Routing Area Update Request indicating that it needs to be connected to the Customized SGSN 122 (User Identity, Establishment Cause new value or new parameter introduced in this example) Value or parameters), or a part of identifiers constituting these parameters (PLMN-id included in IMSI).
  • the UE 101 has a function of instructing the RNC 171 which of the general SGSN 121 and the customized SGSN 122 should be connected to, but at this time, the UE 101 holds all the SGSN information on the core network. Since it cannot be performed, the instruction to the RNC 171 is not an identifier for uniquely selecting the SGSN but information such as an SGSN type or a service type.
  • the RNC 171 has a function of determining which SGSN the UE 101 should be connected to. As described above, this determination is based on a new value of the User Identity, Establishment Cause, or a new parameter (a new parameter introduced in this embodiment). Or a part of identifiers constituting these parameters, or a combination of a plurality of identifiers.
  • the new parameter includes an ID for identifying the MTC group, an APN, and the like.
  • the UE 101 instructs the RNC 171 to select the SGSN, and the RNC 171 receives this instruction, specifies a specific SGSN, and then continues the Routing Area Update Procedure.
  • the UE 101 can be registered in an appropriate SGSN.
  • MTC Machine Type Communication
  • CN node an efficient node for the MTC device
  • the service is provided only by a specific CN node.
  • a specific UE is connected to a node that is a collocated MME and SGW.
  • MME and SGW are collocated, the implementation of the SMS conversion process is facilitated. .
  • MMEs are allocated according to terminal type (CSFB (CS Fallback) terminal, VoLTE terminal, etc.).
  • CSFB CS Fallback
  • 3G or 2G
  • VoLTE Voice over LTE
  • VoLTE Voice over LTE
  • the CSFB terminal needs to interwork with the MSC.
  • the VoLTE terminal needs to interwork with IMS.
  • the MSC that has been previously attached is allowed to select the collocated MME.
  • UE 11 eNodeB 21 General MME 22 Customized MME 31 HSS 41 S-GW (Serving GW) 50 HSS 51 P-GW (PDN GW) 61 Service network 101 UE (MS) 111 NodeB 121 General SGSN 122 Customized SGSN 131 HLR 141 GGSN 161 Service network 171 RNC 201 UE 202 Source eNodeB 203 Target eNodeB 204 Source MME 205 Target MME 206 Source SGW 207 Target SGW 208 PGW (PDN GW) 209 DNS server 210 Service Network 211 HSS 301 UE 302 Source RNC 303 Target RNC 304 Source SGSN 305 Target SGSN 306 Source SGW 307 Target SGW 308 PGW (PDN GW) 309 DNS server 310 Service Network 311 HSS 401 UE 402 Source RNC 403 Target RNC 404 Source SGSN 405 Target SGSN 408 GGSN 409 DNS server 410 service network 411 HSS 501

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Medical Preparation Storing Or Oral Administration Devices (AREA)

Abstract

　本発明はコアネットワーク全体の設備コストの低減を図り、効率的なハンドオーバ機能を提供する。端末からのRRCコネクション要求のLAPI(low access priority indication）情報を用いて基地局は、特定モビリティ管理ノードを選択する。

Description

通信システムと方法と装置
　［関連出願についての記載］
　本発明は、日本国特許出願：特願２０１３－１４１１２７号（２０１３年７月４日出願）及び特願２０１３－１８７１０６号（２０１３年９月１０日出願）に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
　本発明は、通信システムと方法と装置に関する。
　移動体通信システムのコアネットワークにおいては、様々な端末（移動機）に対して様々なサービスを提供するために、サービス毎に必要な機能を、コアネットワーク内のノードの全てが具備する必要がある。大規模移動体通信網等においては、コアネットワーク内に多くのノードが配備されている。端末は、位置登録毎に、コアネットワーク内のノードに分散して接続される。
　このため、コアネットワーク内の全てのノードがサービス毎に必要な機能（サービス提供機能）を具備する必要がある。コアネットワーク内のノードにおいて一部のノードでも、当該サービス提供機能を具備していない場合には、端末に対してサービス継続性を保証することができなくなる。
　なお、移動局が利用するサービスの種類に応じてパケット転送経路を最適化する構成として、例えば特許文献１には、移動局が外部網からのサービスを利用する場合、外部網に応じた特定のパケット転送装置を経由するようにパケット転送経路に制約を加え、移動局が移動通信ネットワークで提供されるサービスを利用する場合には、パケット転送経路に制約を与えない構成が開示されている。
特開２００３－３３８８３２号公報
　以下に関連技術の分析を与える。
　上記したように、コアネットワーク内の各ノードは、全てのサービス提供機能を具備することから、高機能・高性能を要求されることになる。結果として、各コアネットワークノードが高価なものとなっている。
　例えば、３ＧＰＰ（３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ　Ｐｒｏｊｅｃｔ）で標準化されており、同報型配信を実現するベアラサービスであるＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ　Ｂｒｏａｄｃａｓｔ　Ｍｕｌｔｉｃａｓｔ　Ｓｅｒｖｉｃｅ）サービス（同時配信サービス）は、これに対応している移動機が比較的少ないため、サービス提供の機会は少ない。しかしながら、少数のＭＢＭＳユーザに対してサービスを提供しようとした場合、通信事業者としては、コアネットワーク内の全てのノードでＭＢＭＳ機能を具備しなければ、当該数のＭＢＭＳユーザに対してサービスを提供することは出来ない。
　移動機のＭＢＭＳサービスの利用の要否に応じて、コアネットワークのノードを選択することができれば、通信事業者は、比較的に少数の高価なＭＢＭＳ対応コアネットワークノードと、多数の安価なＭＢＭＳ非対応コアネットワークノードを組み合わせて配備することで、全体の設備コストを効率化することが出来る（本発明者らの第１の知見）。
　また、近年普及が進んでいる、３ＧＰＰにおけるマシン通信（ＭＴＣ：Ｍａｃｈｉｎｅ　Ｔｙｐｅ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ）デバイス（Ｍ２Ｍデバイス）は、通話等に用いる携帯電話端末やスマートフォン等の通常の端末（ハンドセット端末）とは、移動特性や要求される通信品質などが大きく異なる。ここで、マシン通信サービスとして、例えば自動販売機の在庫や課金の遠隔管理や、センサシスム等の遠隔監視制御、車両監視、スマートグリッド等のほか、多岐に渡ることが知られている。
　しかしながら、通信事業者としては、全コアネットワークノードにおいて、ＭＴＣデバイスと、ハンドセット端末の双方を、問題なく接続できる能力・機能を具備しない場合には、ＭＴＣデバイスと、ハンドセット端末の双方に対してサービスを提供することが出来ない。
　ＭＴＣデバイスとハンドセット端末を適切なコアネットワークノードに接続することができれば、通信事業者は、相対的に安価なハンドセット端末用コアネットワークノードと、相対的に安価なＭＴＣデバイス用コアネットワークノードとを組み合わせて配備することが出来る。ＭＴＣデバイスは、低アクセス優先情報、又は通信遅延に対する耐性情報をコアネットワークノードに通知する端末でもよい（本発明者らの第２の知見）。
　これは、１つのノードでハンドセット端末と、ＭＴＣデバイスの両方に対応可能とした、相対的に高価なコアネットワークノードを配備するよりも、全体の設備コストを効率化することが出来る（本発明者らの第３の知見）。
　したがって、本発明は、上記問題点を解決すべく創案されたものであり、その目的は、コアネットワーク全体の設備コストの低減を図り、効率的なハンドオーバ機能を提供する、システム、方法、装置を提供することにある。
　前記課題を解決する本発明は、概略以下の構成とされる（ただし、以下に限定されない）。
　本発明の１つの側面によれば、移動体通信システムのコアネットワークが、端末のモビリティ管理ノードとして、前記端末が利用するサービス特性又は端末種別に応じて選択される特定モビリティ管理ノードを備え、
　前記モビリティ管理ノードを跨ぐハンドオーバが起動されると、前記特定モビリティ管理ノードは、保持している、特定モビリティ管理ノード接続要求情報に応じて、ハンドオーバ先のモビリティ管理ノードを選択する、通信システムが提供される。
　本発明の別の側面によれば、移動体通信システムのコアネットワークに、端末のモビリティ管理ノードとして、前記端末が利用するサービス特性又は端末種別に応じて選択される特定モビリティ管理ノードを設け、前記モビリティ管理ノードを跨ぐハンドオーバが起動されると、前記特定モビリティ管理ノードは、保持している、特定モビリティ管理ノード接続要求情報に応じて、ハンドオーバ先のノードを選択する、通信方法が提供される。
　本発明の別の側面によれば、端末のモビリティ管理機能を有し、前記端末が利用するサービス特性又は端末種別に応じて選択される特定のモビリティ管理ノード装置であって、前記モビリティ管理ノードを跨ぐハンドオーバが起動されると、前記特定モビリティ管理ノードは、保持している、特定モビリティ管理ノード接続要求情報に応じて、ハンドオーバ先のモビリティ管理ノードを選択する、モビリティ管理ノード装置が提供される。
　本発明によれば、コアネットワーク全体の設備コストの低減を図り、効率的なハンドオーバ機能を提供することができる。
本発明の第１の実施形態のシステム構成を例示する図である。 本発明の第２の実施形態のシステム構成を例示する図である。 本発明の第１の実施例のシーケンス例を例示する図である。 本発明の第２の実施例のシーケンス例を例示する図である。 本発明の第３の実施例のシーケンス例を例示する図である。 本発明の第３の実施例のシーケンス例を例示する図である。 本発明の第４の実施例のシーケンス例を例示する図である。 本発明の第５の実施例のシーケンス例を例示する図である。 本発明の第５の実施例のシーケンス例を例示する図である。 本発明の第６の実施例のシーケンス例を例示する図である。 本発明の第７の実施例のシーケンス例を例示する図である。 本発明の第８の実施例のシーケンス例を例示する図である。 本発明の第８の実施例のシーケンス例を例示する図である。 本発明の第９の実施例のシーケンス例を例示する図である。 本発明の第１０の実施例のシーケンス例を例示する図である。 本発明の第１０の実施例のシーケンス例を例示する図である。 本発明の第１１の実施例のシステム構成を例示する図である。 本発明の第１１の実施例のシーケンス例を例示する図である。 本発明の第１２の実施例のシステム構成を例示する図である。 本発明の第１２の実施例のシステム構成を例示する図である。 本発明の第１２の実施例のシーケンス例を示す図である。 本発明の第１３、第１４の実施例のシーケンス例を示す図である。 本発明の第１３、第１４の実施例のシーケンス例を示す図である。 本発明の第１５の実施例のシーケンス例を示す図である。 本発明の第１６の実施例のシーケンス例を示す図である。
　本発明のいくつかの形態の１つによれば、移動体通信システムのコアネットワークが、端末のモビリティ管理ノードとして、前記端末が利用するサービス特性又は端末種別に応じて選択される特定モビリティ管理ノード（特定ＭＭＥ／特定ＳＧＳＮ）を備え、前記モビリティ管理ノードを跨ぐハンドオーバが起動されると、前記特定モビリティ管理ノードは、保持している、特定モビリティ管理ノード接続要求情報に応じて、ハンドオーバ先のモビリティ管理ノードを選択する。
　コアネットワークが、端末に対して提供するサービス機能が異なる複数のノード（２１／２２、又は、１２１／１２２）を備え、加入者情報と端末情報に基づき、前記端末に接続するノードを、前記端末が利用するサービス特性又は端末種別に応じて、前記複数のノードから選択し、前記端末（１）と前記選択されたノードとが接続する。すなわち、コアネットワークでは、予め定められた特定のサービス提供機能を具備したノード（２２、又は１２２）と、当該特定のサービス提供機能を具備しないノード（２１、又は１２１）を、組み合わせて配備する。
　このため、特定サービス提供機能に最適化したノードと、特定サービス提供機能自体を具備しないノードとに分離することが可能とされ、ノードのコストの低減を可能としている。
　本発明によれば、移動体通信ネットワークにおいて、サービス特性や端末種別などの条件に応じて、端末が特定のコアネットワークノードに接続できるようにし、さらにハンドオーバを可能としたものである。
＜態様１＞　
　ＵＥ（Ｕｓｅｒ　Ｅｑｕｉｐｍｅｎｔ：ユーザ装置、端末、移動機ともいう）から、アタッチリクエスト（Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ）を受信した、一般ＭＭＥ（Ｍｏｂｉｌｉｔｙ　Ｍａｎａｇｅｍｅｎｔ　Ｅｎｔｉｔｙ：モビリティ管理エンティティ）は、前記ＵＥを、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ、Ｓｐｅｃｉｆｉｃ　ＭＭＥ）に接続するために、ｅＮｏｄｅＢ（ｅｖｏｌｖｅｄ　ＮｏｄｅＢ：基地局装置）に対して、ＭＭＥ再選択要求信号（モビリティ管理エンティティ再選択要求信号）を送信する。なお、ＭＭＥ再選択要求信号は、ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ　ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓでもよい。ＬＡＰＩは、Ｍ２Ｍ通信を一般の音声データ通信よりも低い優先度に設定するものである。例えばＭＴＣデバイスがネットワークに位置登録や発信するたびにＬＡＰＩがネットワークに通知され（例えばＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）プロトコルのアタッチ要求信号がＬＡＰＩを含む）、ｅＮｏｄｅＢ、ＭＭＥ、ＳＧＷ（Ｓｅｒｖｉｎｇ　Ｇａｔｅｗａｙ）、ＰＧＷ（ＰＤＮ（Ｐａｃｋｅｔ　Ｄａｔａ　Ｎｅｔｗｏｒｋｓ）　Ｇａｔｅｗａｙ）等で保持される。またｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓは、例えばＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）　ｃｏｎｎｅｃｔｉｏｎ　ｒｅｑｕｅｓｔメッセージに設定され、ネットワークが過負荷（ｏｖｅｒｌｏａｄ）となった場合の制御を行うために導入されている（例えば３ＧＰＰ　Ｔｅｃｈｎｉｃａｌ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　２３．３６８）。ＬＡＰＩ、又はｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓは、例えばＭＴＣデバイス（ＭＴＣ端末）がネットワークに通知する情報要素であり、これらの情報要素を基（目印）に、基地局（ｅＮｏｄｅＢ）でＭＭＥを特定するようにしてもよい。
　基地局（ｅＮｏｄｅＢ）は、ローアクセスプライオリティ（ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ）の端末（ＵＥ）に対して前記特定ＭＭＥを選択するようにしてもよい。前記ローアクセスプライオリティ（ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ）の端末（ＵＥ）はＭＴＣ機能を有する端末である。前記ローアクセスプライオリティ（ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ）構成の端末（ＵＥ）は、前記基地局にＲＲＣコネクション要求が前記ローアクセスプライオリティ（ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ）であることを指示する情報（ＬＡＰＩ）を提供し、前記基地局（ｅＮｏｄｅＢ）は、前記端末からの情報（ＬＡＰＩ）を用いて、ローアクセスプライオリティ（ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ）構成の端末（ＵＥ）を、前記特定ＭＭＥに向けるようにしてもよい。
　前記ｅＮｏｄｅＢは、前記特定ＭＭＥに、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔを再送することで、ＵＥを特定ＭＭＥへ接続している。
＜態様２＞　
　ＵＥからＡｔｔａｃｈ　Ｒｅｑｕｅｓｔを受信した一般ＭＭＥは、前記ＵＥを、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）に接続するために、前記特定ＭＭＥに対して、ＭＭＥ変更要求信号（モビリティ管理エンティティ変更要求信号）を送信する。前記特定ＭＭＥは、アタッチ処理（Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅ）を継続することで、前記ＵＥを特定ＭＭＥへ接続している。
＜態様３＞　
　ＵＥからＡｔｔａｃｈ　Ｒｅｑｕｅｓｔを受信した一般ＭＭＥは、前記ＵＥを特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）に接続するために、前記特定ＭＭＥの識別子を付与したアタッチリジェクト（Ａｔｔａｃｈ　Ｒｅｊｅｃｔ）を、前記ＵＥに送信する。前記ＵＥは、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔに、特定ＭＭＥの識別子を付与して、再送信することで、前記ＵＥを、前記特定ＭＭＥへ接続している。
＜態様４＞　
　ＵＥは、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）接続要求情報を付与したＲＲＣコネクションリクエスト（ＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ）（無線リソース接続要求）を、ｅＮｏｄｅＢに送信し、ＲＲＣコネクションリクエストを受信したｅＮｏｄｅＢは、ＲＲＣコネクション（ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ）を確立した前記ＵＥからのＡｔｔａｃｈ　Ｒｅｑｕｅｓｔを、ＭＭＥに送信する際に、前記特定ＭＭＥを選択することで、前記ＵＥを前記特定ＭＭＥへ接続している。なお、特定ＭＭＥ接続要求情報は、ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ　ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓでもよい。ＬＡＰＩ、又はｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓは、例えばＭＴＣ端末がネットワークに通知する情報要素であり、これらの情報要素を基に基地局（ｅＮｏｄｅＢ）でＭＭＥを特定するようにしてもよい。
＜態様４－１＞　
　前記ＵＥから、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）に接続するための特定ＭＭＥ接続要求情報を付与したＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）信号を受信した前記ｅＮｏｄｅＢは、前記特定ＭＭＥ接続要求情報をＳ１－ＡＰ信号にて特定ＭＭＥに通知する。
＜態様４－２＞　
　前記ｅＮｏｄｅＢから前記特定ＭＭＥ接続要求情報をＳ１－ＡＰ信号にて受信した特定ＭＭＥは、前記特定ＭＭＥ接続要求情報を保持する。
＜態様５＞　
　ＵＥとセッションを確立している一般ＭＭＥは、ｅＮｏｄｅＢと前記一般ＭＭＥとの間で確立されているＳ１コネクションの開放（Ｓ１　Ｒｅｌｅａｓｅ）時に、次回にＭＭＥを選択する際に、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）を選択するように、前記ｅＮｏｄｅＢに指示をし、その後、前記ＵＥが、位置管理エリア更新リクエスト（ＴＡ（Ｔｒａｃｋｉｎｇ　Ａｒｅａ）　Ｕｐｄａｔｅ　Ｒｅｑｕｅｓｔ）を送信した際に、前記ｅＮｏｄｅＢが前記特定ＭＭＥを選択することで、前記ＵＥを特定ＭＭＥへ接続している。
＜態様６＞　
　ＵＥからＡｔｔａｃｈ　Ｒｅｑｕｅｓｔを受信した一般ＳＧＳＮ（Ｓｅｒｖｉｎｇ　ＧＰＲＳ（Ｇｅｎｅｒａｌ　Ｐａｃｋｅｔ　Ｒａｄｉｏ　Ｓｅｒｖｉｃｅ）　Ｓｕｐｐｏｒｔ　Ｎｏｄｅ：特許請求の範囲では「サービングＧＰＲＳサポートノード」と表記）は、前記ＵＥを特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）に接続するために、ＲＮＣ（Ｒａｄｉｏ　Ｎｅｔｗｏｒｋ　Ｃｏｎｔｒｏｌｌｅｒ：無線ネットワークコントローラ）に、ＳＧＳＮ再選択要求信号を送信し、前記ＲＮＣは、前記特定ＳＧＳＮに、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔを再送することで、前記ＵＥを前記特定ＳＧＳＮへ接続している。なお、ＳＧＳＮ再選択要求信号は、ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ　ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓでもよい。すなわち、例えばＭＴＣ端末からネットワークに通知する、ＬＡＰＩ、ｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓ等の情報要素を基に、ＲＮＣでＳＧＳＮを特定するようにしてもよい。
＜態様７＞　
　ＵＥからＡｔｔａｃｈ　Ｒｅｑｕｅｓｔを受信した一般ＳＧＳＮは、前記ＵＥを特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）に接続するために、前記特定ＳＧＳＮにＳＧＳＮ変更要求信号を送信し、前記特定ＳＧＳＮはアタッチ処理（Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅ）を継続することで、前記ＵＥを前記特定ＳＧＳＮへ接続している。
＜態様８＞　
　ＵＥからＡｔｔａｃｈ　Ｒｅｑｕｅｓｔを受信した一般ＳＧＳＮは、前記ＵＥを特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）に接続するために、前記特定ＳＧＳＮの識別子を付与したアタッチリジェクト（Ａｔｔａｃｈ　Ｒｅｊｅｃｔを前記ＵＥに送信し、前記ＵＥは、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔに、特定ＳＧＳＮ識別子を付与して再送信することで、前記ＵＥを前記特定ＳＧＳＮへ接続している。
＜態様９＞　
　ＵＥは、特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）接続要求情報を付与したコネクションリクエスト（ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ）をＲＮＣに送信し、該リクエストを受信したＲＮＣは、ＲＲＣコネクション（ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ）を確立した前記ＵＥからのＡｔｔａｃｈ　ＲｅｑｕｅｓｔをＳＧＳＮに送信する際に、前記特定ＳＧＳＮを選択することで、前記ＵＥを特定ＳＧＳＮへ接続している。なお、特定ＳＧＳＮ接続要求情報は、ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ　ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓでもよい。すなわち、例えばＭＴＣ端末からネットワークに通知する、ＬＡＰＩ、ｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓ等の情報要素を基にＲＮＣでＳＧＳＮを特定するようにしてもよい。
＜態様９－１＞　
　前記ＵＥから、特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）に接続するための前記特定ＳＧＳＮ接続要求情報を付与したＲＲＣ信号を受信した前記ＲＮＣは、前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて特定ＳＧＳＮに通知する。
＜態様９－２＞　
　前記ＲＮＣから前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて受信した特定ＳＧＳＮは、前記特定ＳＧＳＮ接続要求情報を保持する。
＜態様１０＞　
　ＵＥとセッションを確立している一般ＳＧＳＮは、Ｉｕ開放（Ｉｕ　Ｒｅｌｅａｓｅ）時に、次回ＳＧＳＮ選択で特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）を選択するようにＲＮＣに指示をし、その後、前記ＵＥが、位置管理エリア更新リクエスト（ＲＡ（Ｒｏｕｔｉｎｇ　Ａｒｅａ）　Ｕｐｄａｔｅ　Ｒｅｑｕｅｓｔ）を送信した際に、ＲＮＣが特定ＳＧＳＮを選択することで、ＵＥを特定ＳＧＳＮへ接続している。
＜態様１１＞　
　ＭＭＥを跨ぐハンドオーバが起動されると前記特定ＭＭＥは、保持している前記特定ＭＭＥ接続要求情報に応じてハンドオーバ先のＭＭＥを選択する。なお、特定ＭＭＥ接続要求情報は、ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ　ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓ等の情報要素を基にＭＭＥを特定するようにしてもよい。
＜態様１１－１＞　
　前記特定ＭＭＥは、ハンドオーバ先のＭＭＥの選択を行う際、保持している前記特定ＭＭＥ接続要求情報を元にローカルコンフィグレーションで決定してもよい。あるいは、前記特定ＭＭＥは、保持しているローカルコンフィグレーションを用いてハンドオーバ先のＭＭＥを決定してもよい。
＜態様１１－２＞　
　前記特定ＭＭＥは、ハンドオーバ先のＭＭＥの選択を行う際、保持している前記特定ＭＭＥ接続要求情報を元にＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）サーバに問い合わせを行い、その結果としてＤＮＳサーバから受信したハンドオーバ先のＭＭＥの候補群の中から選択してもよい。
＜態様１１－３＞　
　加入者の位置情報、及び前記特定ＭＭＥ接続要求情報などを入力情報として、１つ又は複数のＭＭＥを提供可能なＤＮＳサーバ。
＜態様１１－４＞　
　ＭＭＥを跨ぐハンドオーバが起動された際、ハンドオーバ元前記特定ＭＭＥは保持している前記特定ＭＭＥ接続要求情報をハンドオーバ先の特定ＭＭＥに通知する。
＜態様１２＞　
　ＳＧＳＮを跨ぐハンドオーバが起動されると、前記特定ＳＧＳＮは、保持している前記特定ＳＧＳＮ接続要求情報に応じてハンドオーバ先のＳＧＳＮを選択する。なお、特定ＳＧＳＮ接続要求情報は、ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ　ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓ等の情報要素を基にＳＧＳＮを特定するようにしてもよい。
＜態様１２－１＞　
　前記特定ＳＧＳＮは、ハンドオーバ先のＳＧＳＮの選択を行う際、保持している前記特定ＳＧＳＮ接続要求情報を元にローカルコンフィグレーションで決定してもよい。あるいは、前記特定ＳＧＳＮは、保持しているローカルコンフィグレーションを用いてハンドオーバ先のＳＧＳＮを決定してもよい。
＜態様１２－２＞　
　前記特定ＳＧＳＮは、ハンドオーバ先のＳＧＳＮの選択を行う際、保持している前記特定ＳＧＳＮ接続要求情報を元にＤＮＳサーバに問い合わせを行い、その結果としてＤＮＳサーバから受信したハンドオーバ先のＳＧＳＮの候補群の中から選択してもよい。
＜態様１２－３＞　
　加入者の位置情報、及び前記特定ＳＧＳＮ接続要求情報などを入力情報として、１つ或いは複数のＳＧＳＮを提供可能なＤＮＳサーバ。
＜態様１２－４＞　
　ＳＧＳＮを跨ぐハンドオーバが起動された際、ハンドオーバ元前記特定ＳＧＳＮは保持している前記特定ＳＧＳＮ接続要求情報をハンドオーバ先特定ＳＧＳＮに通知する。
＜態様１３＞　
　ＭＭＥからＳＧＳＮに移動するハンドオーバが起動されると前記特定ＭＭＥは、保持している前記特定ＭＭＥ接続要求情報に応じてハンドオーバ先のＭＭＥを選択する。なお、特定ＭＭＥ接続要求情報は、ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ　ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓ等の情報要素を基にＭＭＥを特定するようにしてもよい。
＜態様１３－１＞　
　前記特定ＭＭＥは、ハンドオーバ先のＳＧＳＮの選択を行う際、保持している前記特定ＭＭＥ接続要求情報を元にローカルコンフィグレーションで決定してもよい。あるいは、前記特定ＭＭＥは、保持しているローカルコンフィグレーションを用いてハンドオーバ先のＳＧＳＮを決定してもよい。
＜態様１３－２＞　
　前記特定ＭＭＥは、ハンドオーバ先のＳＧＳＮの選択を行う際、保持している前記特定ＭＭＥ接続要求情報を元にＤＮＳサーバに問い合わせを行い、その結果としてＤＮＳサーバから受信したハンドオーバ先のＭＭＥの候補群の中から選択してもよい。
＜態様１３－３＞　
　ＭＭＥからＳＧＳＮに移動するハンドオーバが起動された際、ハンドオーバ元前記特定ＭＭＥは保持している前記特定ＭＭＥ接続要求情報をハンドオーバ先特定ＳＧＳＮに通知する。
＜態様１３－４＞　
　前記特定ＭＭＥ接続要求情報と、前記特定ＳＧＳＮ接続要求情報が区別無く、同一の情報として扱われるシステム。
＜態様１３－５＞　
　前記特定ＭＭＥ接続要求情報と、前記特定ＳＧＳＮ接続要求情報とが、それぞれ別の情報として扱われるシステム。
＜態様１４＞　
　ＳＧＳＮからＭＭＥに移動するハンドオーバが起動されると、前記特定ＳＧＳＮは、保持している前記特定ＳＧＳＮ接続要求情報に応じて、ハンドオーバ先のＭＭＥを選択する。なお、特定ＳＧＳＮ接続要求情報は、ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ　ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓ等の情報要素を基に、ＭＭＥを特定するようにしてもよい。
＜態様１４－１＞　
　前記特定ＳＧＳＮは、ハンドオーバ先のＭＭＥの選択を行う際、保持している前記特定ＳＧＳＮ接続要求情報を元にローカルコンフィグレーションで決定してもよい。あるいは、前記特定ＳＧＳＮは、保持しているローカルコンフィグレーションを用いてハンドオーバ先のＭＭＥを決定してもよい。
＜態様１４－２＞　
　前記特定ＳＧＳＮは、ハンドオーバ先のＭＭＥの選択を行う際、保持している前記特定ＳＧＳＮ接続要求情報を元にＤＮＳサーバに問い合わせを行い、その結果としてＤＮＳサーバから受信したハンドオーバ先のＭＭＥの候補群の中から選択してもよい。
＜態様１４－３＞　
　ＳＧＳＮからＭＭＥに移動するハンドオーバが起動された際、ハンドオーバ元前記特定ＳＧＳＮは保持している前記特定ＳＧＳＮ接続要求情報をハンドオーバ先特定ＭＭＥに通知する。
＜態様１４－４＞　
　前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報が区別無く同一の情報として扱われるシステム。
＜態様１４－５＞　
　前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報がそれぞれ別の情報として扱われるシステム。
＜態様１５＞　
　ＵＥは、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）接続要求情報を付与したＲＲＣコネクションリクエスト（ＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ）（無線リソース接続要求）を、ｅＮｏｄｅＢに送信し、ＲＲＣコネクションリクエストを受信したｅＮｏｄｅＢは、ＲＲＣコネクション（ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ）を確立した前記ＵＥからのＴｒａｃｋｉｎｇ　Ａｒｅａ　Ｕｐｄａｔｅ　Ｒｅｑｕｅｓｔを、ｎｅｗ　ＭＭＥに送信する際に、前記特定ＭＭＥを選択することで、前記ＵＥを前記特定ＭＭＥへ接続している。なお、特定ＭＭＥ接続要求情報は、ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ　ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓ等の情報要素を基にｅＮｏｄｅＢでＭＭＥを特定するようにしてもよい。
＜態様１５－１＞　
　前記ＵＥから、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）に接続するための前記特定ＭＭＥ接続要求情報を付与したＲＲＣ信号を受信した前記ｅＮｏｄｅＢは、前記特定ＭＭＥ接続要求情報をＳ１－ＡＰ信号にて特定ＭＭＥに通知する。
＜態様１５－２＞　
　前記ｅＮｏｄｅＢから前記特定ＭＭＥ接続要求情報をＳ１－ＡＰ信号にて受信した特定ＭＭＥは、前記特定ＭＭＥ接続要求情報を保持する。
＜態様１５－３＞　
　前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報が区別無く同一の情報として扱われるシステム。
＜態様１５－４＞　
　前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報がそれぞれ別の情報として扱われるシステム。
＜態様１６＞　
　ＵＥは、特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）接続要求情報を付与したコネクションリクエスト（ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ）をＲＮＣに送信し、該リクエストを受信したＲＮＣは、ＲＲＣコネクション（ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ）を確立した前記ＵＥからのＲｏｕｔｉｎｇ　Ａｒｅａ　Ｕｐｄａｔｅ　Ｒｅｑｕｅｓｔをｎｅｗ　ＳＧＳＮに送信する際に、前記特定ＳＧＳＮを選択することで、前記ＵＥを特定ＳＧＳＮへ接続している。なお、特定ＳＧＳＮ接続要求情報は、ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ　ｉｎｄｉｃａｔｉｏｎ、又はｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓでもよい。この場合、例えばＭＴＣ端末からネットワークに通知するＬＡＰＩ、ｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓ等の情報要素を基にＲＮＣでＳＧＳＮを特定するようにしてもよい。
＜態様１６－１＞　
前記ＵＥから、特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）に接続するための前記特定ＳＧＳＮ接続要求情報を付与したＲＲＣ信号を受信した前記ＲＮＣは、前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて特定ＳＧＳＮに通知する。
＜態様１６－２＞　
　前記ＲＮＣから前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて受信した特定ＳＧＳＮは、前記特定ＳＧＳＮ接続要求情報を保持する。
＜態様１６－３＞　
　前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報が区別無く同一の情報として扱われるシステム。
＜態様１６－４＞　
　前記特定ＭＭＥ接続要求情報と前記特定ＳＧＳＮ接続要求情報がそれぞれ別の情報として扱われるシステム。
　上記態様１乃至１６に記載したように、本発明によれば、端末毎に接続するコアネットワークノードを、端末の利用するサービス特性に応じて選択して接続する構成としている。こうすることで、コアネットワークでは、特定のサービス提供機能を具備したノードと具備しないノードを、組み合わせて配備し、各ノードのうち、あるノードを特定サービス提供機能に最適化し、他のノードは当該特定サービス提供機能を具備しないという具合に差異を設けることで、ノードのコストの低減を図るようにしている。以下、図面を参照して、いくつかの実施形態と具体的な実施例に即して説明する。
＜実施形態１＞
　図１は、本発明の実施形態１を説明する図である。実施形態１として、ＥＰＣ（Ｅｖｏｌｖｅｄ　Ｐａｃｋｅｔ　Ｃｏｒｅ）において、Ａｔｔａｃｈ時に、ＵＥと特定ＭＭＥを接続させる構成について説明する。
　図１において、ＵＥ１（ユーザ装置）は、例えば携帯電話端末（移動機）を示す。あるいは、例えば上記したＭＴＣデバイス、ＭＢＭＳ対応端末等であってもよい。
　ｅＮｏｄｅＢ１１は、ＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）の基地局装置である。
　ＭＭＥ２１、２２は、ＥＰＣで導入されたモビリティを管理する装置である。Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、ＵＥ１を接続させたい特定ＭＭＥであり、一般ＭＭＥ（２１）は、それ以外のＭＭＥである。特に制限されないが、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、例えばマシン通信（ＭＴＣ）サービスと、対応端末（Ｍ２Ｍデバイス）向けにカスタマイズした構成（例えばネットワーク制御を扱うＣ－Ｐｌａｎｅを補強）のＭＭＥとして構成される。あるいは、ＭＢＭＳ対応のＭＭＥとして構成してもよい。
　ＨＳＳ（Ｈｏｍｅ　Ｓｕｂｓｃｒｉｂｅｒ　Ｓｅｒｖｅｒ）３１は、加入者情報を保持するデータベースである。
　Ｓ－ＧＷ（Ｓｅｒｖｉｎｇ　ＧａｔｅＷａｙ）４１、及びＰ－ＧＷ（Ｐａｃｋｅｔ　ｄａｔａ　ｎｅｔｗｏｒｋ　ＧａｔｅＷａｙ:ＰＤＮ－ＧＷともいう）５１は、ユーザプレーンを扱う装置である。
　サービスネットワーク６１は、外部ネットワークを示す。
　図１において、ｅＮｏｄｅＢが無線アクセスネットワーク（ＲＡＮ：Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ）、ＭＭＥ、Ｓ－ＧＷ、Ｐ－ＧＷ等がコアネットワーク（ＣＮ：Ｃｏｒｅ　Ｎｅｔｗｏｒｋ）に対応する。
　以下、上記した実施形態１について、制御方式が互いに相違した、いくつかの実施例を説明する。実施例１－５は上記態様１－５にそれぞれ対応する。
＜実施例１＞
　図３は、実施例１の動作例を説明するためのシーケンス図である。図３において、
　ＵＥは図１のＵＥ１、
　ｅＮｏｄｅＢは図１のｅＮｏｄｅＢ１１、
　一般ＭＭＥは図１の一般ＭＭＥ２１、
　Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥは、図１のＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ（特定ＭＭＥ）２２、
　Ｓｅｒｖｉｎｇ　ＧＷは、図１のＳ－ＧＷ４１、
　ＰＤＮ　ＧＷは、図１のＰ－ＧＷ５１、
　ＨＳＳは、図１のＨＳＳ３１にそれぞれ対応する。
　ＰＣＲＦは、ポリシと課金ルール機能（Ｐｏｌｉｃｙ　ａｎｄ　Ｃｈａｒｇｉｎｇ　Ｒｕｌｅｓ　Ｆｕｎｃｔｉｏｎ）である。また、ＥＩＲ（Ｅｑｕｉｐｍｅｎｔ　Ｉｄｅｎｔｉｔｙ　Ｒｅｇｉｓｔｅｒ）は、ＩＭＥＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｍｏｂｉｌｅ　Ｅｑｕｉｐｍｅｎｔ　Ｉｄｅｎｔｉｔｙ）等を保持し、ＭＭＥとＳ１３インタフェースで接続される。
　なお、図３において、例えば「１．Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ」は、ＵＥからｅＮｏｄｅＢへのＡｔｔａｃｈ　Ｒｅｑｕｅｓｔの送信がシーケンス１であることを表わしている。図のＵＥの参照符号１（構成要素の参照符号）とは異なることを区別するため、以下の説明では、このシーケンス番号１を、「Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）」のように、括弧書きで表記する。他のシーケンス番号についても同様とする。また、図４以降のシーケンス図についても同様の表記とする。なお、図３は、３ＧＰＰ　ＴＳ２３．４０１のＦｉｇｕｒｅ　５．３．２．１－１：　Ａｔｔａｃｈ　ｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１　５．３．２の記載が参照される。以下、図１及び図３を参照して、動作シーケンスを説明する。
　図３を参照すると、ＵＥ１が、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）を送信すると、まず、ｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１は、ＭＭＥに、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）を中継する。
　この時、ｅＮｏｄｅＢ１１は、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）を一般ＭＭＥ２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に転送するべきか、一意に決定することが出来ない。そのため、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）は、ｅＮｏｄｅＢ１１から一般ＭＭＥ２１に転送される場合がある。
　一般ＭＭＥ２１では、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）を受信した後、Ｉｄｅｎｔｉｔｙ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（４、５ｂ）にて、ＵＥ１から、端末情報（ＭＥ　Ｉｄｅｎｔｉｔｙ）を取得する。
　なお、一般ＭＭＥ２１は、ＭＥ　Ｉｄｅｎｔｉｔｙ　Ｃｈｅｃｋ　Ｒｅｑｕｅｓｔ（５ｂ）をＥＩＲに送り、ＥＩＲはＭＤ　Ｉｄｅｎｔｉｔｙ　Ｃｈｅｃｋ　Ａｃｋ　を一般ＭＭＥに返す。更に、ＨＳＳ３１と連携して、認証及び加入者プロファイルの取得を行う。すなわち、認証、加入者プロファイル取得まで、一般ＭＭＥ２１で行う。
　端末情報及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に接続するべきか判断する。
　一般ＭＭＥ２１に接続する場合、通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。
　ＵＥ１を、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に接続する場合、一般ＭＭＥ２１は、ｅＮｏｄｅＢ１１に対して、ＭＭＥ再選択を指示するために、ＭＭＥ選択信号：ＭＭＥ　ｒｅ－ｓｅｌｅｃｔｉｏｎ　Ｃｏｍｍａｎｄ（本実施形態で新規に導入した、Ｓ１ＡＰ（Ｓ１　アプリケーション）信号）を送信する。
　この時、一般ＭＭＥ２１は、ＭＭＥ　ｒｅ－ｓｅｌｅｃｔｉｏｎ　Ｃｏｍｍａｎｄ信号に、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２の識別子（例えばＧＵＭＭＥＩ（Ｇｌｏｂａｌｌｙ　Ｕｎｉｑｕｅ　ＭＭＥ　Ｉｄｅｎｔｉｔｙ））を設定する。すなわち、コアネットワーク内でベアラ生成前にｅＮｏｄｅＢに再選択要求を送信し、新たなＭＭＥ選択に必要な情報（ＧＵＭＭＥＩ）を載せる。ＭＭＥは、ＵＥが、ｒｅ－ｓｅｌｅｃｔｉｏｎ対象であるか否かを判断する機能を具備する。
　ｅＮｏｄｅＢ１１は、ＭＭＥ　ｒｅ－ｓｅｌｅｃｔｉｏｎ　Ｃｏｍｍａｎｄ信号を受信すると、この信号に設定された識別子に従って、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２を選択し、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）をＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に転送する。特定ＭＭＥ２２では、Ａｔｔａｃｈ　ＲｅｑｕｅｓｔのＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）パラメータ（ＵＥとＭＭＥ間の認証に用いられる）が必要であるため、ｅＮｏｄｅＢ１１で再送する。ｅＮｏｄｅＢ１１では、ＮＡＳメッセージを保持する機能が必要である。
　新ＭＭＥ（＝Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２）では、旧ＭＭＥ（＝一般ＭＭＥ）を特定できないため、コンテキスト（Ｃｏｎｔｅｘｔ）を、旧ＭＭＥ（＝一般ＭＭＥ）から引き継ぐことはできない。そのため、新ＭＭＥ（＝Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥＭＭＥ２２）では、再度、認証／加入者プロファイルの取得を行う必要がある。
　Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ信号を受信した後、Ｉｄｅｎｔｉｔｙ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅにて端末情報を取得し、更にＨＳＳ３１と連携して、認証及び加入者プロファイルの取得を行う。すなわち、一般ＭＭＥ２１と同様の処理を行う。
　端末情報及び加入者プロファイルを取得したＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、ＵＥ１を、一般ＭＭＥ２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に接続するべきか判断する。
　ここでは、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、ｅＮｏｄｅＢ１１で再選択された後である為、ＭＭＥ　ｒｅ－ｓｅｌｅｃｔｉｏｎ　Ｃｏｍｍａｎｄ信号を送信せずに、通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。すなわち、
・Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２からＨＳＳ３１へのＵｐｄａｔｅ　Ｌｏｃａｔｉｏｎ　Ｒｅｑｕｅｓｔ（８）の送信、
・ＨＳＳ３１からＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２へのＵｐｄａｔｅ　Ｌｏｃａｔｉｏｎ　Ａｃｋ（１１）の送信、
・Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２からＳ－ＧＷ４１へのＣｒｅａｔｅ　Ｓｅｓｓｉｏｎ　Ｒｅｑｕｅｓｔ（１２）の送信、
・Ｓ－ＧＷ４１からＰ－ＧＷ５１へのＣｒｅａｔｅ　Ｓｅｓｓｉｏｎ　Ｒｅｑｕｅｓｔ（１２）の送信、
・Ｐ－ＧＷ５１とＰＣＲＦでのＰＣＥＦ（Ｐｏｌｉｃｙ　ａｎｄ　Ｃｈａｒｇｉｎｇ　Ｒｕｌｅｓ　Ｆｕｎｃｔｉｏｎ）　Ｉｎｉｔｉａｔｅｄ　ＩＰ－ＣＡＮ（ＩＰ　Ｃｏｎｎｅｃｔｉｖｉｔｙ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ）　Ｓｅｓｓｉｏｎ　Ｅｓｔａｂｌｉｓｈｍｅｎｔ／Ｍｏｄｉｆｉｃａｔｉｏｎ手順（１４）、　
・Ｐ－ＧＷ５１からＳ－ＧＷ４１へのＣｒｅａｔｅ　Ｓｅｓｓｉｏｎ　Ｒｅｓｐｏｎｃｅ（１５）の送信、
・Ｐ－ＧＷ５１からＳ－ＧＷ４１へのＦｉｒｓｔ　Ｄｏｗｎ　Ｌｉｎｋ　Ｄａｔａの送信　（ハンドオーバ（ＨＯ）でない場合）、
・Ｓ－ＧＷ４１からＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２へのＣｒｅａｔｅ　Ｓｅｓｓｉｏｎ　Ｒｅｓｐｏｎｃｅ（１６）の送信、
・Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２からｅＮｏｄｅＢ１１へのＩｎｉｔｉａｌ　Ｃｏｎｔｅｘｔ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔ／Ａｔｔａｃｈ　Ａｃｃｅｐｔ（１７）の送信、
・ｅＮｏｄｅＢ１１からＵＥ１へのＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（１８）の送信、
・ＵＥ１からｅＮｏｄｅＢ１１へのＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｃｏｍｐｌｅｔｅ（１９）の送信、
・ｅＮｏｄｅＢ１１からＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２へのＩｎｉｔｉａｎｌ　Ｃｏｎｔｅｘｔ　Ｓｅｔｕｐ　Ｒｅｓｐｏｎｃｅ（２０）の送信、
・ＵＥ１からｅＮｏｄｅＢ１１へのＤｉｒｅｃｔ　Ｔｒａｎｓｆｅｒ（２１）の送信、
・ｅＮｏｄｅＢ１１からＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２へのＡｔｔａｃｈ　Ｃｏｍｐｌｅｔｅ（２２）の送信、
・ＵＥ１からＳ－ＧＷ４１、Ｐ－ＧＷ５１へのＦｉｒｓｔ　Ｕｐｌｉｎｋ　ｄａｔａの送信、
・Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２からＳ－ＧＷ４１へのＭｏｄｉｆｙ　Ｂｅａｅｒ　Ｒｅｑｕｅｓｔ（２３）の送信、
・Ｓ－ＧＷ４１からＰ－ＧＷ５１ヘのＭｏｄｉｆｙ　Ｂｅａｅｒ　Ｒｅｑｕｅｓｔ（２３ａ）の送信、
・Ｐ－ＧＷ５１からＳ－ＧＷ４１へのＭｏｄｉｆｙ　Ｂｅａｅｒ　Ｒｅｓｐｏｎｃｅ（２３ｂ）の送信、
・Ｓ－ＧＷ４１からＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２へのＭｏｄｉｆｙ　Ｂｅａｅｒ　Ｒｅｓｐｏｎｃｅ（２４）の送信、
・Ｐ－ＧＷ５１、Ｓ－ＧＷ４１からＵＥ１への最初のダウンリンクデータ（Ｆｉｒｓｔ　Ｄｏｗｎｌｉｎｋ　ｄａｔａ）の送信、
が行われる。　
　また、一般ＭＭＥ２１及びＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、ＵＥ１を、どのＭＭＥに接続させるべきか判断する機能を具備するが、この判断は、
ＵＥ１からの情報、例えば、
・ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｍｏｂｉｌｅ　Ｓｕｂｓｃｒｉｂｅｒ　Ｉｄｅｎｔｉｔｙ：国際移動体加入者識別番号）、
・ＩＭＥＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｍｏｂｉｌｅ　Ｅｑｕｉｐｍｅｎｔ　Ｉｄｅｎｔｉｔｙ：　国際移動体装置識別番号（端末識別番号））、
・ＵＥ　ｎｅｔｗｏｒｋ　ｃａｐａｂｉｌｉｔｙ、
・ＭＳ　ｎｅｔｗｏｒｋ　ｃａｐａｂｉｌｉｔｙ、
・Ｍｏｂｉｌｅ　ｓｔａｔｉｏｎ　ｃｌａｓｓｍａｒｋ　２、
・Ｍｏｂｉｌｅ　ｓｔａｔｉｏｎ　ｃｌａｓｓｍａｒｋ　３、
・Ｄｅｖｉｃｅ　ｐｒｏｐｅｒｔｉｅｓ、又は、
・ＡＰＮ（Ａｃｃｅｓｓ　Ｐｏｉｎｔ　Ｎａｍｅ）、又は、
・ＭＴＣグループを識別するＩＤ、又は、
・ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ　ｉｎｄｉｃａｔｉｏｎ、又は、
・ｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓ、又は、
・今後追加されるＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ、また、ＴＡ　Ｕｐｄａｔｅ　Ｒｅｑｕｅｓｔなどのその他のＮＡＳ信号の新規パラメータ、又は、
・これらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ（Ｐｕｂｌｉｃ　ｌａｎｄ　Ｍｏｂｉｌｅ　Ｎｅｔｗｏｒｋ）－ｉｄなど）、
ＨＳＳ３１からの情報、例えば、
・Ｆｅａｔｕｒｅ－Ｌｉｓｔ、
・ＡＰＮ（Ａｃｃｅｓｓ　Ｐｏｉｎｔ　Ｎａｍｅ）、又は、
・今後追加されるＵｐｄａｔｅ　Ｌｏｃａｔｉｏｎ　Ａｎｓｗｅｒ／Ｉｎｓｅｒｔ　Ｓｕｂｓｃｒｉｂｅｒ　Ｄａｔａ　Ｒｅｑｕｅｓｔ信号の新規パラメータ、又は、
・これらのパラメータを構成する一部分の識別子、
のいずれか、もしくは複数、
を組み合わせた上で行う。
　また、図３では、図示されていないが、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に対して、一般ＭＭＥ２１に接続すべきＵＥ１からのＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ信号が転送された場合も、同様の手段で、ｅＮｏｄｅＢ１１に対して、ＭＭＥ再選択を促すことが可能である。
　以上説明したように、本実施形態においては、ＭＭＥがｅＮｏｄｅＢに対してＭＭＥ再選択を指示し、ｅＮｏｄｅＢはそれを受けてＭＭＥを再選択した上で、アタッチ処理（Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅ）を継続することにより、ＵＥを適切なＭＭＥにＡｔｔａｃｈさせることができる。
＜実施例２＞
　実施例２として、ＥＰＣ（Ｅｖｏｌｖｅｄ　Ｐａｃｋｅｔ　Ｃｏｒｅ）において、Ａｔｔａｃｈ時にＵＥとＣｕｓｔｏｍｉｚｅｄ　ＭＭＥを接続させる別の例を説明する。実施例２のシステム構成は、実施例１と同様である。
　図４は、実施例２の動作例を示すシーケンス図である。なお、図４は、３ＧＰＰ　ＴＳ２３．４０１のＦｉｇｕｒｅ　５．３．２．１－１：　Ａｔｔａｃｈ　ｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１　５．３．２の記載が参照される。以下、図１及び図４を参照して動作を説明する。
　ＵＥ１がＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）を送信すると、ｅＮｏｄｅＢ１１が受信し、ＭＭＥにＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）を中継する。この時、ｅＮｏｄｅＢ１１は、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）を一般ＭＭＥ２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＭＭＥ２１に転送される場合がある。
　一般ＭＭＥ２１では、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）を受信した後、Ｉｄｅｎｔｉｔｙ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（５ｂ）にて、端末情報（ＭＥ　Ｉｄｅｎｔｉｔｙ）を取得し、更に、ＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。すなわち、認証、加入者プロファイルまでは一般ＭＭＥ２１で行う。
　端末情報、及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に接続するべきか判断する。一般ＭＭＥ２１に接続する場合、通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。
　ＵＥ１をＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に接続する場合、一般ＭＭＥ２１は、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に対して、ＭＭＥ変更を指示するために、ＭＭＥ変更要求信号（ＭＭＥ　Ｃｈａｎｇｅ　Ｒｅｑｕｅｓｔ）（本実施例で新規に導入した、ＧＴＰ（ＧＰＲＳ　Ｔｕｎｎｅｌｌｉｎｇ　Ｐｒｏｔｏｃｏｌ）信号）を送信する。
　この時、一般ＭＭＥ２１は、ＭＭＥ　Ｃｈａｎｇｅ　Ｒｅｑｕｅｓｔ信号に、端末認証や加入者プロファイルの取得によって生成したコンテキスト（ｃｏｎｔｅｘｔ）情報を設定する。
　Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、ＭＭＥ変更要求信号（ＭＭＥ　Ｃｈａｎｇｅ　Ｒｅｑｕｅｔ）を受信すると、該ＭＭＥ変更要求信号に設定されたｃｏｎｔｅｘｔ情報を保持し、一般ＭＭＥ２１に対して、ＭＭＥ　Ｃｈａｎｇｅ　Ｒｅｓｐｏｎｓｅ信号（本実施例で新規に導入した、ＧＴＰ信号）を送信する。
　その後、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、ＨＳＳ３１に対して、Ｕｐｄａｔｅ　Ｌｏｃａｔｉｏｎ　Ｒｅｑｕｅｓｔ信号（８）を送信し、ＭＭＥが変更されたことをＨＳＳ３１に通知する。
　ＨＳＳ３１に対して、ＭＭＥの変更ＭＭＥを通知するため、Ｕｐｄａｔｅ　Ｌｏｃａｔｉｏｎ　ＲｅｑｕｅｓｔをＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２で再実施する。以降のＡｔｔａｃｈ　ＰｒｏｃｅｄｕｒｅはＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２で実施する。
　また、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、一般ＭＭＥ２１から受け取ったセキュリティ・コンテキスト（ｓｅｃｕｒｉｔｙ　ｃｏｎｔｅｘｔ）情報が有効であれば、再認証を省略することが出来る。
　その後、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、アタッチ処理（Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅ）を継続し、ｅＮｏｄｅＢ１１は、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２から、Ｉｎｉｔｉａｌ　Ｃｏｎｔｅｘｔ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔ／Ａｔｔａｃｈ　Ａｃｃｅｐｔ（１７）を受信する。
　Ｉｎｉｔｉａｌ　Ｃｏｎｔｅｘｔ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔ／Ａｔｔａｃｈ　Ａｃｃｅｐｔ（１７）は、一般ＭＭＥ２１で受けたＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）に対する応答である。なお、一般ＭＭＥ２１とは、別のＭＭＥからの応答（Ｒｅｓｐｏｎｃｅ）を受信できる機能がｅＮｏｄｅＢ１１に実装されている必要がある。
　その後は、通常のアタッチ処理（Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅ）を継続する。
　また、一般ＭＭＥ２１、及びＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、ＵＥ１を、どのＭＭＥに接続させるべきか判断する機能を具備するが、この機能は、実施例１と同様である。
　また、図４には、図示されていないが、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に対して、一般ＭＭＥ２１に接続するべきＵＥ１からのＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ信号が転送された場合も、同様の手段で一般ＭＭＥ２１にＭＭＥ変更を促すことが可能である。
　以上説明したように、本実施例においては、一般ＭＭＥがＣｕｓｔｏｍｉｚｅｄ　ＭＭＥに対してＭＭＥ変更を指示し、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥはそれを受けてＭＭＥを変更した上で、Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＭＭＥにＡｔｔａｃｈさせることができる。
＜実施例３＞
　実施例３として、ＥＰＣにおいてＡｔｔａｃｈ時に、ＵＥとＣｕｓｔｏｍｉｚｅｄ　ＭＭＥを接続させる例を説明する。実施例３のシステム構成は、実施例１と同様である。
　図５、図６は、実施例３の動作例を説明するシーケンス図である。なお、図５、６は、３ＧＰＰ　ＴＳ２３．４０１のＦｉｇｕｒｅ　５．３．２．１－１：　Ａｔｔａｃｈ　ｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１　５．３．２の記載が参照される。以下、図１及び図５、図６を参照して動作を説明する。
　ＵＥ１がＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）を送信すると、まずｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１からＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）がＭＭＥに転送される。この時、ｅＮｏｄｅＢ１１は、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）を、一般ＭＭＥ２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＭＭＥ２１に転送される場合がある。
　一般ＭＭＥ２１では、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）を受信した後、Ｉｄｅｎｔｉｔｙ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（５ｂ）にて端末情報（ＭＥ　Ｉｄｅｎｔｉｔｙ）を取得する。更に、一般ＭＭＥ２１は、ＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。
　端末情報及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に接続するべきか判断する。一般ＭＭＥ２１に接続する場合、通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。
　ＵＥ１を、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に接続する場合、一般ＭＭＥ２１は、Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続せずに、ＵＥ１に対してアタッチリジェクト（Ａｔｔａｃｈ　Ｒｅｊｅｃｔ）メッセージを送信する。すなわち、一般ＭＭＥ２１はＩｎｉｔｉａｌ　Ｃｏｎｔｅｘｔ　Ｓｅｔｕｐ　Ｒｅｑｕｅｓｔ／Ａｔｔａｃｈ　Ｒｅｊｅｃｔ（１７）をｅＮｏｄｅＢ１１に送信する。
　この時、一般ＭＭＥ２１は、Ａｔｔａｃｈ　Ｒｅｊｅｃｔ信号に、再アタッチ（ｒｅ－ａｔｔａｃｈ）を指示するパラメータ（本実施例で導入した、新規パラメータ）、及び、ｒｅ－ａｔｔａｃｈ時に、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２を、ｅＮｏｄｅＢ１１が選択できるように、ＧＵＭＭＥＩ（Ｇｌｏｂａｌｌｙ　Ｕｎｉｑｕｅ　ＭＭＥ　ｉｄｅｎｔｉｆｉｅｒ）を含むＧＵＴＩ（Ｇｌｏｂａｌｌｙ　Ｕｎｉｑｕｅ　Ｔｅｍｐｏｒａｒｙ　Ｉｄｅｎｔｉｆｙ）パラメータ（本実施例で導入した、新規パラメータ）を設定する。ＧＵＴＩパラメータは、ＧＵＭＭＥＩとＭ－ＴＭＳＩ（Ｔｅｍｐｏｒａｙ　Ｍｏｂｉｌｅ　Ｓｔａｔｉｏｎ　Ｉｄｅｎｔｉｔｙ）から構成される。ＭＭＥＩは、ＭＣＣ（Ｍｏｂｉｌｅ　Ｃｏｕｎｔｒｙ　Ｃｏｄｅ）とＭＮＣ（Ｍｏｂｉｌｅ　Ｎｅｔｗｏｒｋ　Ｃｏｄｅ）とＭＭＥ　Ｉｄｅｎｔｉｆｉｅｒから構成される。これらは本実施例で導入した新規なパラメータであるが、ｅＮｏｄｅＢ１１は、透過（ｔｒａｎｓｐａｒｅｎｔ）であるため、ｅＮｏｄｅＢ１１には影響はない。
　ＵＥ１は、ｅＮｏｄｅＢ１１からＡｔｔａｃｈ　Ｒｅｊｅｃｔ信号を受信すると、図６に示すように、Ａｔｔａｃｈ－Ｒｅｊｅｃｔ信号に設定されたｒｅ－ａｔｔａｃｈを指示するパラメータ、及び、ＧＵＴＩパラメータに従って、ＧＵＴＩを設定したＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）（ＧＵＴＩによるＡｔｔａｃｈ）を、ｅＮｏｄｅＢ１１に送信する。この時、ｅＮｏｄｅＢ１１は、ＧＵＴＩに含まれるＧＵＭＭＥＩから適切なＭＭＥを判断し、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）を、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に転送する。
　なお、ＵＥ１には、Ａｔｔａｃｈ　Ｒｅｊｅｃｔ信号にてＧＵＴＩを受け付け、ｒｅ－ａｔｔａｃｈ（図６のＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１））送信時に、Ａｔｔａｃｈ　ｒｅｊｅｃｔで指示されたＧＵＴＩを使用する機能が実装されている。ＭＭＥは、このＵＥがＲｅ－Ｓｅｌｅｃｔｉｏｎ対象か判断する機能が実装されている。
　その後、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。ただし、ＧＵＴＩが設定されたＡｔｔａｃｈ　Ｒｅｑｕｅｓｔだが、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２自身は、ｃｏｎｔｅｘｔ情報を保持していない。
　このため、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ信号を受信した後、Ｉｄｅｎｔｉｔｙ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（４）にて、端末情報を取得し、更にＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。
　また、一般ＭＭＥ２１及びＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２はＵＥ１をどのＭＭＥに接続させるべきか判断する機能を具備するが、この機能は、前記実施例１と同様である。
　また、図５及び図６では、図示されていないが、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に対して、一般ＭＭＥ２１に接続するべきＵＥ１からのＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ信号が転送された場合も、同様にして、ＵＥ１にＭＭＥ再選択を促すことが可能である。
　以上説明したように、本実施例においては、一般ＭＭＥがＵＥに対してＭＭＥ再選択を指示し、ＵＥはそれを受けてＣｕｓｔｏｍｉｚｅｄ　ＭＭＥを指定した上で、Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＭＭＥにＡｔｔａｃｈさせることができる。
＜実施例４＞
　実施例４として、ＥＰＣにおいてＡｔｔａｃｈ時にＵＥとＣｕｓｔｏｍｉｚｅｄ　ＭＭＥを接続させる例を説明する。実施例４の構成は実施例１と同様である。図７は、実施例４の動作例を説明するためのシーケンス図である。なお、図７は、３ＧＰＰ　ＴＳ２３．４０１のＦｉｇｕｒｅ　５．３．２．１－１：　Ａｔｔａｃｈ　ｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１　５．３．２の記載が参照される。以下、図１及び図７を参照して動作を説明する。
　ＵＥ１がＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）をＭＭＥに送信する為に、まずｅＮｏｄｅＢ１１とのＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎの確立を行う。ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ確立のために、ＵＥ１は、まずｅＮｏｄｅＢ１１にＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ信号を送信する。
　この時、ＵＥ１は、本信号にＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２への接続を必要とすることを示すパラメータ（Ｕｓｅｒ　Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で新規に導入した値又はパラメータ）、又は、これらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ－ｉｄ（Ｐｕｂｌｉｃ　Ｌａｎｄ　Ｍｏｂｉｌｅ　Ｎｅｔｗｏｒｋ　Ｉｄｅｎｔｉｔｙ）等））を設定する。
　ＵＥ１は、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　ＲｅｑｕｅｓｔにてｅＮｏｄｅＢに、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥに接続可能であることを通知する　ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔの新規パラメータ（ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅ（ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔを発信した原因を示す情報要素（通信確立要因）)の新規Ｖａｌｕｅ若しくは新規パラメータ）が実装される。
　ｅＮｏｄｅＢ１１は、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ信号を受信したとき、ＵＥ１がＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に接続すべきことを記憶し、その後のＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｐｒｏｃｅｄｕｒｅを継続する。
　ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ確立後、ＵＥ１がＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）を送信すると、ｅＮｏｄｅＢ１１が受信する。この時、ｅＮｏｄｅＢ１１は、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ（１）の受信した時に記憶した情報（ＵＥ１がＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に接続すべきこと）から、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）を、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に転送する。　
　Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）には、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔにて受信したＣｕｓｔｏｍｉｚｅｄ　ＭＭＥに接続可能であることを通知するＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔの新規パラメータ（Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）がｅＮｏｄｅＢ１１によって設定されＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に通知される。
　Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２では、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）を受信した後、通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）で受信した、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔにて受信したＣｕｓｔｏｍｉｚｅｄ　ＭＭＥに接続可能であることを通知するＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔの新規パラメータ（ｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）を保持する。
　また、ＵＥ１は、一般ＭＭＥ２１及びＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２のどちらのＭＭＥに接続するべきかを、ｅＮｏｄｅＢ１１に指示する機能を具備する。この時、ＵＥ１はコアネットワーク上の全てＭＭＥの情報を保持することは出来ないので、ｅＮｏｄｅＢ１１への指示は、ＭＭＥを一意に選択できる識別子ではなく、ＭＭＥ種別、若しくはサービス種別等の情報が用いられる。
　また、ｅＮｏｄｅＢ１１は、ＵＥ１をどのＭＭＥに接続させるべきか判断する機能を具備している。
　ｅＮｏｄｅＢ１１において、ＭＭＥの選択は、前述のとおり、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ内のユーザＩＤ（Ｕｓｅｒ　Ｉｄｅｎｔｉｔｙ）、通信確立要因（Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅ）の新規Ｖａｌｕｅ、又は新規パラメータ、又はこれらのパラメータを構成する一部分の識別子のいずれか、若しくは複数を組み合わせて行う。新規パラメータにはＭＴＣグループを識別するＩＤ、ＡＰＮなども含む。
　以上説明したように、本実施例においては、ＵＥがｅＮｏｄｅＢに対してＭＭＥ選択を指示し、ｅＮｏｄｅＢはそれを受けてＣｕｓｔｏｍｉｚｅｄ　ＭＭＥを指定した上で、Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＭＭＥにＡｔｔａｃｈさせることができる。
＜実施例５＞
　実施例５として、ＥＰＣにおいて、トラッキングエリア更新（ＴＡ　Ｕｐｄａｔｅ）時に、ＵＥとＣｕｓｔｏｍｉｚｅｄ　ＭＭＥを接続させる例を説明する。実施例５の構成は、実施例１と同様である。
　図８、図９は、実施例５の動作例を説明するためのシーケンス図である。なお、図８は、３ＧＰＰ　ＴＳ２３．４０１のＦｉｇｕｒｅ　５．３．５－１：　Ｓ１　Ｒｅｌｅａｓｅ　Ｐｒｏｃｅｄｕｒｅに基づく。ＴＳ２３．４０１　５．３．５が参照される。図９は、Ｆｉｇｕｒｅ　５．３．３．１－１：　Ｔｒａｃｋｉｎｇ　Ａｒｅａ　Ｕｐｄａｔｅ　ｐｒｏｃｅｄｕｒｅ　ｗｉｔｈ　Ｓｅｒｖｉｎｇ　ＧＷ　ｃｈａｎｇｅに基づく。３ＧＰＰ　ＴＳ２３．４０１　５．３．３が参照される。図１、図８、図９（及び図３の一部）を参照して、動作を説明する。
　ＵＥ１がＡｔｔａｃｈ　Ｒｅｑｕｅｓｔを送信すると（図３の１）、まずｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１からＡｔｔａｃｈ　ＲｅｑｕｅｓｔがＭＭＥに中継される（図３の２参照）。
　この時、ｅＮｏｄｅＢ１１は、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔを一般ＭＭＥ２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に転送するべきか、一意に決定することが出来ない。そのため、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔが一般ＭＭＥ２１に転送される場合がある。
　一般ＭＭＥ２１ではＡｔｔａｃｈ　Ｒｅｑｕｅｓｔを受信した後、Ｉｄｅｎｔｉｔｙ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（図３の４参照）にて端末情報を取得し、更に、ＨＳＳ３１と連携して認証及び加入者プロファイルの取得を行う。
　端末情報及び加入者プロファイルを取得した一般ＭＭＥ２１は、ＵＥ１を一般ＭＭＥ２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に接続するべきか判断する。その後、通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。一般ＭＭＥ２１に接続する場合は、ここで処理が完了する。
　ＵＥ１を、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に接続する場合、一般ＭＭＥ２１はＵＥ１に対して、トラッキングエリア更新（ＴＡ　Ｕｐｄａｔｅ）を行わせるために、図８に示すように、Ｓ１　Ｒｅｌｅａｓｅを行う。この時、一般ＭＭＥ２１はｅＮｏｄｅＢ１１に、Ｓ１　ＵＥ　Ｃｏｎｔｅｘｔ　Ｒｅｌｅａｓｅ　Ｃｏｍｍａｎｄ（４）を送信する。
一般ＭＭＥ２１は、Ｓ１　ＵＥ　Ｃｏｎｔｅｘｔ　Ｒｅｌｅａｓｅ　Ｃｏｍｍａｎｄ（４）で、次にｅＮｏｄｅＢがＭＭＥとＳ１　Ｃｏｎｎｅｃｔｉｏｎを確立するときに選択するべきＭＭＥを、ＭＭＥ識別子（例えばＧＵＭＭＥＩ）で指示する。Ｌｏａｄ　Ｂａｌａｎｃｉｎｇ　ＴＡＵ起動のためのＳ１　Ｒｅｌｅａｓｅ時に、ｅＮｏｄｅＢに対して、次のＭＭＥを指定するＧＵＭＭＥＩを指示するためのパラメータは新規パラメータである。この時、ｅＮｏｄｅＢ１１は、Ｓ１　Ｒｅｌｅａｓｅ完了後もＵＥ１に対するセッション情報を保持している間、次回ＭＭＥ選択の為の情報として、ＭＭＥ識別子を保持し続ける。
　Ｓ１　Ｒｅｌｅａｓｅが行われると、次にＵＥ１は、図９に示すように、ＴＡＵ　Ｒｅｑｕｅｓｔ（２）を送信する。ＴＡＵ　Ｒｅｑｕｅｓｔ（２）を、まずｅＮｏｄｅＢ１１が受信し、ｅＮｏｄｅＢ１１からＴＡＵ　Ｒｅｑｕｅｓｔ（３）がＭＭＥに転送される。この時、ｅＮｏｄｅＢ１１は、Ｓ１　Ｒｅｌｅａｓｅ済みの状態であることから、ＭＭＥ選択を行い、Ｓ１　Ｃｏｎｎｅｃｔｉｏｎを確立する。ｅＮｏｄｅＢは、Ｓ１　Ｒｅｌｅａｓｅ時にｏｌｄ　ＭＭＥ（＝一般ＭＭＥ）から指示されたＧＵＭＭＥＩに従ってＣｕｓｔｏｍｉｚｅｄ　ＭＭＥを選択する（※ｅＮｏｄｅＢはＵＥ毎に次のＧＵＭＭＥＩを保持する機能を有する）。
　ＭＭＥの選択において、ｅＮｏｄｅＢ１１は、一般ＭＭＥ２１から受信したＳ１　ＵＥ　Ｃｏｎｔｅｘｔ　Ｒｅｌｅａｓｅ　Ｃｏｍｍａｎｄ信号で指示されたＧＵＭＭＥＩのＭＭＥ識別子（ＭＭＥ　Ｉｄｅｎｔｉｆｉｅｒ）に従い、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２を選択する。ＮＡＳ上のＧＵＴＩ（ＧＵＭＭＥＩ）は、ｏｌｄ　ＭＭＥ（＝一般ＭＭＥ）を示しているのでｃｏｎｔｅｘｔ取得が可能である。
　Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、ＴＡＵ　Ｒｅｑｕｅｓｔ（３）を受信した後、通常のＴＡ　Ｕｐｄａｔｅ　Ｐｒｏｃｅｄｕｒｅを継続する。Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、一般ＭＭＥ２１にＣｏｎｔｅｘｔ　Ｒｅｑｕｅｓｔ（４）を送信し、その応答Ｃｏｎｔｅｘｔ　Ｒｅｓｐｏｎｃｅ（５）を受け取る。
　Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、Ｓ－ＧＷがリロケート（ｒｅｌｏｃａｔｅ）した場合、一般ＭＭＥにＳ－ＧＷの変更指示を含むＣｏｎｔｅｘｔ　Ａｃｋｎｏｗｌｅｄｇｅ（７）を送信し、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２が新たなＳ－ＧＷ４１（ｎｅｗ　Ｓｅｒｖｉｎｇ　ＧＷ）を選択すると、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、新たなＳ－ＧＷ４１に、Ｃｒｅａｔｅ　Ｓｅｓｓｈｏｎ　Ｒｅｑｕｅｓｔ（８）を送信する。
　これを受けて新たなＳ－ＧＷ４１（ｎｅｗ　Ｓｅｒｖｉｎｇ　ＧＷ）は、Ｍｏｄｉｆｙ　Ｂｅａｒｅｒ　Ｒｅｑｕｅｓｔ（９）をＰ－ＧＷ５１に送信し、その応答をＰ－ＧＷ５１から受けると、新たなＳ－ＧＷはＣｒｅａｔｅ　Ｓｅｓｓｉｏｎ　Ｒｅｓｐｏｎｃｅ　（１１）をＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に返す。
　Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２はＵｐｄａｔｅ　Ｌｏｃａｔｉｏｎ（１２）をＨＳＳ３１に送信する。
　ＨＳＳ３１からＣａｎｃｅｌ　Ｌｏｃａｔｉｏｎ（１３）を受け取った一般ＭＭＥ２１は、ＭＭコンテキストを削除し、肯定応答（Ｃａｎｃｅｌ　Ｌｏｃａｔｉｏｎ　Ａｃｋ）（１４）をＨＳＳ３１に送信する。ＨＳＳ３１からのＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２にＵｐｄａｔａ　Ｌｏｃａｔｉｏｎ（１２）に対する肯定応答（Ｕｐｄａｔａ　Ｌｏｃａｔｉｏｎ　Ａｃｋ）（１７）が送信される。
　一般ＭＭＥ２１は、旧Ｓ－ＧＷ４１（ｏｌｄ　Ｓｅｒｖｉｎｇ　ＧＷ）にＤｅｌｅｔｅ　Ｓｅｓｓｉｏｎ　Ｒｅｑｕｅｓｔ（１８）を送信し、その応答（１９）が、旧Ｓ－ＧＷ４１（ｏｌｄ　Ｓｅｒｖｉｎｇ　ＧＷ）から一般ＭＭＥ２１に送信される。
　Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２からＵＥ１にＴＡＵ　Ａｃｃｅｓｐｔ（２０）が送信される。
　ＴＡＵ　Ａｃｃｅｐｔ（２０）にＧＵＴＩが含まれる場合、ＵＥ１は、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に対して、ＴＡＵ　Ｃｏｍｐｌｅｔｅ（２１）を返すことで、受信した信号ＴＡＵ　Ａｃｃｅｓｐｔ（２０）の肯定応答とする。
　一般ＭＭＥ２１及びＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、ＵＥ１をどのＭＭＥに接続させるべきか判断する機能を具備するが、この機能は実施例１と同様である。
　また、図８及び図９では、図示していないが、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に対して一般ＭＭＥ２１に接続するべきＵＥ１からのＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ信号が転送された場合も、同様の手段でＵＥ１にＭＭＥ再選択を促すことが可能である。
　また、本実施例では、図９の手順にて、ＴＡ　Ｕｐｄａｔｅ　Ｐｒｏｃｅｄｕｒｅを用いたが、本実施例での特徴は、ｅＮｏｄｅＢ１１でＭＭＥの選択を行うことである。このため、例えば、Ｓｅｒｖｉｃｅ　Ｒｅｑｕｅｓｔ等、Ｓ１　Ｃｏｎｎｅｃｔｉｏｎを再確立するための、その他の手続き（Ｐｒｏｃｅｄｕｒｅ）を用いても実現可能である。
　以上説明したように、本実施例においては、一般ＭＭＥがｅＮｏｄｅＢに対してＭＭＥ再選択を指示し、ｅＮｏｄｅＢはそれを受けて次回ＭＭＥ選択時にＣｕｓｔｏｍｉｚｅｄ　ＭＭＥを指定した上で、手続き（Ｐｒｏｃｅｄｕｒｅ）を継続することにより、ＵＥを適切なＭＭＥに接続させることができる。
＜実施形態２＞
　実施形態２として、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ　Ｍｏｂｉｌｅ　Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ｓｙｓｔｅｍ）においてＡｔｔａｃｈ時にＵＥと特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）を接続させる例を説明する。図２は、実施形態２のシステム構成を例示する図である。
　ＵＥ１０１は、例えば携帯電話端末（移動機）である。あるいは、例えば上記したＭＴＣデバイス、ＭＢＭＳ対応端末等であってもよい。
　ＮｏｄｅＢ１１１及びＲＮＣ（Ｒａｄｉｏ　Ｎｅｔｗｏｒｋ　Ｃｏｎｔｒｏｌｌｅｒ）１７１は、ＵＭＴＳシステムで採用された無線アクセス（Ｒａｄｉｏ　ａｃｃｅｓｓ）用の装置を表している。
　一般ＳＧＳＮ１２１、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２は、ＵＭＴＳ用に用いる在圏装置であり、接続形態により、ユーザープレーンを扱う場合と扱わない場合がある。ＳＧＳＮがユーザープレーンを扱わない場合のユーザープレーンは、Ｓ－ＧＷとＲＮＣ間に設定される。
　ＨＬＲ（Ｈｏｍｅ　Ｌｏｃａｔｉｏｎ　Ｒｅｇｉｓｔｅｒ）１３１は、加入者情報を保持するデータベースである。
　ＧＧＳＮ（Ｇａｔｅｗａｙ　ＧＰＲＳ（Ｇｅｎｅｒａｌ　Ｐａｃｋｅｔ　Ｒａｄｉｏ　Ｓｅｒｖｉｃｅ）　Ｓｕｐｐｏｒｔ　Ｎｏｄｅ：特許請求の範囲では「ゲートウェイＧＰＲＳサポートノード」と表記）１４１は、外部網と接続するゲートウェイ装置である。サービスネットワーク１６１は、外部網（データパケットネットワーク）を示す。
　図２において、ＮｏｄｅＢ１１１とＲＮＣ１７１は無線アクセスネットワークＲＡＮ、ＳＧＳＮ、ＧＧＳＮ等はコアネットワークに対応する。
　以下、実施形態２について、制御方式の相違したいくつかの実施例を説明する。以下の実施例６－１０は上記態様６－１０にそれぞれ対応する。
＜実施例６＞
　図１０は、実施例６の動作例を説明するためのシーケンス図であり、３ＧＰＰ　ＴＳ　２３．０６０　６．５　Ｆｉｇ　２２に基づく。
　図１０において、
　ＭＳ（Ｍｏｂｉｌｅ　Ｓｔａｔｉｏｎ）は、図２のＵＥ１０１、
　ＲＡＮ（Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ）は、図２のＮｏｄｅＢ１１１とＲＮＣ１７１、
　一般ＳＧＳＮは、図２の一般ＳＧＳＮ１２１、
　Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ（特定ＳＧＳＮ）は、図２のＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ（特定ＳＧＳＮ）１２２、
　ＧＧＳＮは、図２のＧＧＳＮ１４１、
　ＨＬＲは、図２のＨＬＲ１３１に対応している。
　ＭＳＣ（Ｍｏｂｉｌｅ　Ｓｗｉｔｃｈｉｎｇ　Ｃｅｎｔｅｒ）／ＶＬＲ（Ｖｉｓｉｔｏｒ　Ｌｏｃａｔｉｏｎ　Ｒｅｇｉｓｔｅｒ）のＶＬＲはＨＬＲ以外のＣＳサービス用のローケーションレジスタである。ＥＩＲ（Ｅｑｕｉｐｍｅｎｔ　Ｉｄｅｎｔｉｆｉｅｒ　Ｒｅｇｉｓｔｅｒ）は有効な移動装置の識別子を保持する。　
　図２、図１０を参照して動作を説明する。なお、以下では、図１０のＭＳを、図２のＵＥ１０１に読み替えて説明する。
　ＵＥ１０１（ＭＳ）がＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）を送信すると、まずＮｏｄｅＢ１１１が受信し、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）をＲＮＣ１７１に転送する。ＲＮＣ１７１は、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）をＳＧＳＮに転送する。この時、ＲＮＣ１７１は、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔを一般ＳＧＳＮ１２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。
　一般ＳＧＳＮ１２１では、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔを受信した後、Ｉｄｅｎｔｉｔｙ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（３）にて端末情報を取得し、更にＨＬＲ１３１と連携して、認証及び加入者プロファイルの取得を行う。認証、加入者プロファイル取得まで、一般ＳＧＳＮ１２１で実施する。
　端末情報及び加入者プロファイルを取得した一般ＳＧＳＮ１２１は、ＵＥ１０１を一般ＳＧＳＮ１２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に接続するべきか判断する。一般ＳＧＳＮ１２１に接続する場合、通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。
　ＵＥ１０１を、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に接続する場合、一般ＳＧＳＮ１２１は、ＲＮＣ１７１に対して、ＳＧＳＮ再選択を指示するために、ＳＧＳＮ　ｒｅ－ｓｅｌｅｃｔｉｏｎ　Ｃｏｍｍａｎｄ（本実施例で新規に導入した、ＲＡＮＡＰ信号）を送信する。この時、一般ＳＧＳＮ１２１はＳＧＳＮ　ｒｅ－ｓｅｌｅｃｔｉｏｎ　Ｃｏｍｍａｎｄ信号にＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２を特定する識別子（例えばＲＡＩ（Ｒｏｕｔｉｎｇ　Ａｒｅａ　Ｉｄｅｎｔｉｆｉｅｒ）、ＮＲＩ（Ｎｅｔｗｒｏｋ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ）など）を設定する。すなわち、一般ＳＧＳＮ１２１は、ＲＮＣに１７１対して、ＳＧＳＮ再選択要求し、その際、特定ＳＧＳＮ１２２の選択に必要な情報（ＲＡＩ）を載せる。なお、同一プール内での再選択の場合は、ＮＲＩでよい。ＳＧＳＮは、ＵＥ１０１が、ｒｅ－ｓｅｌｅｃｔｉｏｎ対象か判断する機能を有する。
　ＲＮＣ１７１は、ＳＧＳＮ　ｒｅ－ｓｅｌｅｃｔｉｏｎ　Ｃｏｍｍａｎｄ信号を受信すると、本信号に設定された識別子に従ってＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２を選択し、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）を転送する。特定ＳＧＳＮ１２２でＡｔｔａｃｈ　ＲｅｑｕｅｓｔのＮＡＳ（Ｎｏｎ　Ａｃｃｅｓｓ　Ｓｔｒａｔｕｍ）パラメータが必要なので、ＲＮＣ１７１でＡｔｔａｃｈ　Ｒｅｑｕｅｓｔを再送する。ＲＮＣ１７１ではＮＡＳメッセージを保持する機能が実装されている。
　新たなＳＧＳＮ（＝Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）では旧ＳＧＳＮ（＝一般ＳＧＳＮ）を特定できないため、コンテキスト（ｃｏｎｔｅｘｔ）を引き継ぐことができない。そのため、新たなＳＧＳＮでも認証／加入者プロファイル取得を行う必要がある。Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２は、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（２）を受信した後、Ｉｄｅｎｔｉｔｙ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅにて端末情報を取得し、更にＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。つまり、一般ＳＧＳＮ１２１と同様の処理を行う。
　端末情報及び加入者プロファイルを取得したＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２は、ＵＥ１０１を、一般ＳＧＳＮ１２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に接続するべきか判断する。ここでは、ＲＮＣ１７１で再選択された後の為、ＳＧＳＮ　ｒｅ－ｓｅｌｅｃｔｉｏｎ　Ｃｏｍｍａｎｄ信号を送信せずに、通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。
　また、一般ＳＧＳＮ１２１及びＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２はＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この判断はＵＥ１０１からの情報（例えば、
・ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｍｏｂｉｌｅ　Ｓｕｂｓｃｒｉｂｅｒ　Ｉｄｅｎｔｉｔｙ）、
・ＩＭＥＩ、
・ＵＥ　ｎｅｔｗｏｒｋ　ｃａｐａｂｉｌｉｔｙ、
・ＭＳ　ｎｅｔｗｏｒｋ　ｃａｐａｂｉｌｉｔｙ、
・Ｍｏｂｉｌｅ　ｓｔａｔｉｏｎ　ｃｌａｓｓｍａｒｋ　２、
・Ｍｏｂｉｌｅ　ｓｔａｔｉｏｎ　ｃｌａｓｓｍａｒｋ　３、
・Ｄｅｖｉｃｅ　ｐｒｏｐｅｒｔｉｅｓ、
・ＡＰＮ（Ａｃｃｅｓｓ　Ｐｏｉｎｔ　Ｎａｍｅ）、又は、
・ＭＴＣグループを識別するＩＤ、又は、
・ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ　ｉｎｄｉｃａｔｉｏｎ、又は、
・ｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓ、又は、
・今後追加されるＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ、又は、ＴＡ　Ｕｐｄａｔｅ　Ｒｅｑｕｅｓｔなどのその他のＮＡＳ信号の新規パラメータ、又は、これらのパラメータを構成する一部分の識別子※ＩＭＳＩに含まれるＰＬＭＮ－ｉｄ等）、
ＨＬＲ１３１からの情報（例えば
・Ｆｅａｔｕｒｅ－Ｌｉｓｔ、
・ＡＰＮ、
・ＭＴＣグループを識別するＩＤ、又は、
・又は今後追加されるＵｐｄａｔｅ　Ｌｏｃａｔｉｏｎ　Ａｎｓｗｅｒ／Ｉｎｓｅｒｔ　Ｓｕｂｓｃｒｉｂｅｒ　Ｄａｔａ　Ｒｅｑｕｅｓｔ信号の新規パラメータ、又は、
・これらのパラメータを構成する一部分の識別子）
のいずれか、若しくは複数を組み合わせて行う。
　また、図１０では明示していないが、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に対して一般ＳＧＳＮ１２１に接続するべきＵＥ１０１からのＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ信号が転送された場合も、同様の手段でＲＮＣ１７１にＭＭＥ再選択を促すことが可能である。
　以上説明したように、本実施例においては、ＳＧＳＮがＲＮＣに対してＳＧＳＮ再選択を指示し、ＲＮＣはそれを受けてＳＧＳＮを再選択した上で、Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＳＧＳＮにＡｔｔａｃｈさせることができる。
＜実施例７＞
　実施例７として、ＵＭＴＳにおいてＡｔｔａｃｈ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例７の構成は実施例６と同様である。図１１は、実施例７の動作例を説明するためのシーケンス図である。図２、図１１を参照して動作を説明する。
　ＵＥ１０１が、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）を送信すると、まず、ＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。ＲＮＣ１７１はこれをＳＧＳＮに転送する。この時、ＲＮＣ１７１は、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔを一般ＳＧＳＮ１２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。
　一般ＳＧＳＮ１２１では、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔを受信した後、Ｉｄｅｎｔｉｔｙ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅにて端末情報を取得し、更に、ＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。認証、加入者プロファイル取得まで、一般ＳＧＳＮ１２１で実施する。
　端末情報及び加入者プロファイルを取得した一般ＳＧＳＮ１２１は、ＵＥ１０１を一般ＳＧＳＮ１２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に接続するべきか判断する。一般ＳＧＳＮ１２１に接続する場合、通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。
　ＵＥ１０１をＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に接続する場合、一般ＳＧＳＮ１２１は、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に対してＳＧＳＮ変更を指示するために、ＳＧＳＮ　Ｃｈａｎｇｅ　Ｒｅｑｕｅｓｔ（本実施形態で新規に導入した、ＧＴＰ信号）を送信する。
　この時、一般ＳＧＳＮ１２１は、ＳＧＳＮ　Ｃｈａｎｇｅ　Ｒｅｑｕｅｓｔ信号に、移動機認証や加入者プロファイルの取得によって生成したｃｏｎｔｅｘｔ情報を設定する。すなわち、一般ＳＧＳＮ１２１からＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に、ＳＧＳＮ　ｃｈａｎｇｅを要求する際に、ｃｏｎｔｅｘｔを新たなＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２）に通知する。ＳＧＳＮはＵＥ１０１がｒｅ－ｓｅｌｅｃｔｉｏｎ対象か判断する機能が実装されている。
　Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２は、ＳＧＳＮ　Ｃｈａｎｇｅ　Ｒｅｑｕｅｓｔ信号を受信すると、ＳＧＳＮ　Ｃｈａｎｇｅ　Ｒｅｑｕｅｓｔ信号に設定されたコンテキスト（ｃｏｎｔｅｘｔ）情報を保持し、一般ＳＧＳＮ１２１に対して、ＳＧＳＮ　Ｃｈａｎｇｅ　Ｒｅｓｐｏｎｓｅ信号（本実施形態で新規に導入した、ＧＴＰ信号）を送信する。
　その後、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２は、ＨＬＲ１３１に対して、Ｕｐｄａｔｅ　Ｌｏｃａｔｉｏｎ信号（８）を送信し、ＳＧＳＮが変更されたことをＨＬＲ１３１に通知する。
　また、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２は、一般ＳＧＳＮ１２１から受け取ったセキュリティ・コンテキスト（ｓｅｃｕｒｉｔｙ　ｃｏｎｔｅｘｔ）情報が有効であれば、再認証を省略することが出来る。
　その後、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２は、Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続し、ＲＮＣ１７１は、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２からＡｔｔａｃｈ　Ａｃｃｅｐｔ信号（９）を受信する。その後は、通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。
　また、一般ＳＧＳＮ１２１及びＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２は、ＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この機能は実施例６と同様である。
　また、図１１では、図示されていないが、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に対して一般ＳＧＳＮ１２１に接続するべきＵＥ１０１からのＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ信号が転送された場合も、同様の手段で一般ＳＧＳＮ１２１にＳＧＳＮ変更を促すことが可能である。
　以上説明したように、本実施例においては、一般ＳＧＳＮが特定ＳＧＳＮに対してＳＧＳＮ変更を指示し、特定ＳＧＳＮはそれを受けてＳＧＳＮを変更した上で、アタッチ処理（Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅ）を継続することにより、ＵＥを適切なＳＧＳＮに、Ａｔｔａｃｈさせることができる。
＜実施例８＞
　実施例８として、ＵＭＴＳにおいてＡｔｔａｃｈ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例８の構成は実施例６と同様である。図１２、図１３は、実施例８の動作例を説明するためのシーケンス図である。図２、図１２、図１３を参照して動作を説明する。
　ＵＥ１０１（ＭＳ）が、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）を送信すると、まずＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。ＲＮＣ１７１は、これをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＡｔｔａｃｈ　Ｒｅｑｕｅｓｔを一般ＳＧＳＮ１２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。
　一般ＳＧＳＮ１２１では、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）を受信した後、Ｉｄｅｎｔｉｔｙ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（３）にて端末情報を取得し、更に、ＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。
　端末情報及び加入者プロファイルを取得した一般ＳＧＳＮ１２１は、ＵＥ１０１を一般ＳＧＳＮ１２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に接続するべきか判断する。一般ＳＧＳＮ１２１に接続する場合、通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。
　ＵＥ１０１をＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に接続する場合、一般ＳＧＳＮ１２１は、Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続せずに、ＵＥ１０１に対してＡｔｔａｃｈ　Ｒｅｊｅｃｔ信号（９）を送信する。
　この時、一般ＳＧＳＮ１２１はＡｔｔａｃｈ　Ｒｅｊｅｃｔ信号に、再アタッチ（ｒｅ－ａｔｔａｃｈ）を指示するパラメータと、ｒｅ－ａｔｔａｃｈ時に、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２を、ＲＮＣ１７１が選択できるようＲＡＩ（Ｒｏｕｔｉｎｇ　Ａｒｅａ　Ｉｄｅｎｔｉｔｙ）パラメータ（本実施形態で新規に導入した、パラメータ）を設定する。これらは本実施例で導入した新規なパラメータであるが、ＲＮＣ１７１では、透過であるため影響はない。
　ＵＥ１０１は、Ａｔｔａｃｈ　ＲｅｊｅｃｔでＲＡＩを受け付け、Ｒｅ－ａｔｔａｃｈ時に、ｒｅｊｅｃｔで指示されたＲＡＩを使用する機能が必要である。ＳＧＳＮはＵＥ１０１がｒｅ－ｓｅｌｅｃｔｉｏｎ対象か判断する機能を有する。
　ＵＥ１０１は、Ａｔｔａｃｈ　Ｒｅｊｅｃｔ信号（９）を受信すると、該Ａｔｔａｃｈ　Ｒｅｊｅｃｔ信号（９）に設定されたｒｅ－ａｔｔａｃｈを指示するパラメータ及びＲＡＩパラメータに従って、図１３に示すように、ＲＡＩを設定したＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ信号（１）を、ＲＮＣ１７１に送信する（Ｐ－ＴＭＳＩ（Ｐａｃｋｅｔ　Ｔｅｍｐｏｒａｒｙ　Ｍｏｂｉｌｅ　Ｓｕｂｓｃｒｉｂｅｒ　Ｉｎｄｅｎｔｉｆｉｅｒ）によるＲｅ－Ａｔｔａｃｈ）。この時、ＲＮＣ１７１は、ＲＡＩから適切なＳＧＳＮを判断し、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔを、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に転送する。
　その後、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２は、通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。
　ただし、ＲＡＩが設定されたＡｔｔａｃｈ　Ｒｅｑｕｅｓｔであるが、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２自身は、ｃｏｎｔｅｘｔ情報を保持していない。このため、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ信号（１）を受信した後、Ｉｄｅｎｔｉｔｙ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ（３）にて、端末情報を取得し、更にＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。
　また、一般ＳＧＳＮ１２１及びＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２はＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この機能は実施例６と同様である。
　また、図１２及び図１３では、図示されていないが、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に対して一般ＭＭＥ１２１に接続するべきＵＥ１０１からのＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ信号が転送された場合も、同様の手段で、ＵＥ１０１に、ＭＭＥの再選択を促すことが可能である。
　以上説明したように、本実施例においては、一般ＳＧＳＮがＵＥに対してＳＧＳＮ再選択を指示し、ＵＥはそれを受けて特定ＳＧＳＮを指定した上で、Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＳＧＳＮにＡｔｔａｃｈさせることができる。
＜実施例９＞
　実施例９として、ＵＭＴＳにおいてＡｔｔａｃｈ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例９の構成は実施例６と同様である。図１４は、実施例９の動作例を説明するシーケンス図である。図２及び図１４を参照して動作を説明する。
　ＵＥ１０１がＡｔｔａｃｈ　ＲｅｑｕｅｓｔをＳＧＳＮに送信する為に、まずＲＮＣ１７１とのＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎの確立を行う。ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ確立の為、ＵＥ１０１は、まずＲＮＣ１７１にＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ信号を送信する。
　この時、ＵＥ１０１は、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ信号に、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（Ｕｓｅｒ　Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ－ｉｄ等））を設定する。
　ＲＮＣ１７１は、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ信号を受信したとき、ＵＥ１０１がＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に接続するべきことを記憶し、その後のＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｐｒｏｃｅｄｕｒｅを継続する。
　ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ確立後、ＵＥ１０１がＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ（１）を送信すると、まず、ＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。
　ＲＮＣ１７１は、これをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ信号の受信時に記憶した情報から、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔ信号を、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に転送する。Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔには、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔにて受信したＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（Ｕｓｅｒ　Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ－ｉｄ等））がＲＮＣ１７１によって設定されＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に通知される。
　Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２では、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔを受信した後、通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２は、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔで受信した、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（ＲＮＣ１７１がＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔにて受信し、Ａｔｔａｃｈ　Ｒｅｑｕｅｓｔに設定したパラメータであって、Ｕｓｅｒ　Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ－ｉｄ等））を保持する。
　また、ＵＥ１０１は、一般ＳＧＳＮ１２１、及びＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２のどちらのＳＧＳＮに接続するべきかをＲＮＣ１７１に指示する機能を具備するが、この時、ＵＥ１０１は、コアネットワーク上の全てＳＧＳＮの情報を保持することは出来ないので、ＲＮＣ１７１への指示は、ＳＧＳＮを一意に選択できる識別子ではなく、ＳＧＳＮ種別若しくはサービス種別等の情報である。
　また、ＲＮＣ１７１は、ＵＥ１０１を、どのＳＧＳＮに接続させるべきか判断する機能を具備するが、この判断は、前述のとおり、Ｕｓｅｒ　Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子のいずれか、若しくは複数を組み合わせて行う。新規パラメータにはＭＴＣグループを識別するＩＤ、ＡＰＮなども含む。
　以上説明したように、本実施例においては、ＵＥ１０１がＲＮＣ１７１に対してＳＧＳＮの選択を指示し、ＲＮＣ１７１は、この指示を受けて、特定ＳＧＳＮを指定した上で、Ａｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。かかる構成により、ＵＥ１０１を適切なＳＧＳＮにＡｔｔａｃｈさせることができる。
＜実施例１０＞
　実施例１０として、ＵＭＴＳにおいてＲＡ　Ｕｐｄａｔｅ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例１０の構成は、実施例６と同様である。図１５、図１６は、実施例１０の動作例を説明するためのシーケンス図である。以下、図２、図１５、図１６、及び図１０の一部を参照して、動作を説明する。
　ＵＥ１０１がＡｔｔａｃｈ　Ｒｅｑｕｅｓｔを送信すると（図１０の１参照）、まずＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。ＲＮＣ１７１はこれをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＡｔｔａｃｈ　Ｒｅｑｕｅｓｔを一般ＳＧＳＮ１２１に転送するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に転送するべきか、一意に決定することが出来ない。そのため、一般ＳＧＳＮ１２１に転送される場合がある。
　一般ＳＧＳＮ１２１ではＡｔｔａｃｈ　Ｒｅｑｕｅｓｔを受信した後、Ｉｄｅｎｔｉｔｙ　Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅにて端末情報を取得し（図１０の３参照）、更にＨＬＲ１３１と連携して認証及び加入者プロファイルの取得を行う。
　端末情報及び加入者プロファイルを取得した一般ＳＧＳＮ１２１は、ＵＥ１０１を一般ＳＧＳＮ１２１に接続するべきか、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に接続するべきか判断する。一般ＳＧＳＮ１２１に接続する場合、通常のＡｔｔａｃｈ　Ｐｒｏｃｅｄｕｒｅを継続する。
　ＵＥ１０１をＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に接続する場合、一般ＳＧＳＮ１２１はＵＥ１０１に対して、ＲＡ（Ｒｏｕｔｉｎｇ　Ａｒｅａ）　Ｕｐｄａｔｅを行わせるために、図１５に示すように、Ｉｕ　Ｒｅｌｅａｓｅを行う。
　この時、一般ＳＧＳＮ１２１は、ＲＮＣ１７１にＩＵ　Ｒｅｌｅａｓｅ　Ｃｏｍｍａｎｄ信号を送信する（図１５の４参照）。一般ＳＧＳＮ１２１は、ＩＵ　Ｒｅｌｅａｓｅ　Ｃｏｍｍａｎｄ信号にて、次にＲＮＣがＳＧＳＮとＩｕ　Ｃｏｎｎｅｃｔｉｏｎを確立するときに選択するべき、ＳＧＳＮをＳＧＳＮ識別子（例えばＲＡＩ、ＮＲＩ等）で指示する。なお、同一プール内の場合、ＮＲＩでもよい。
　ＲＮＣ１７１は、Ｉｕ　Ｒｅｌｅａｓｅ完了後も、ＵＥ１０１に対するセッション情報を保持している間、次回ＳＧＳＮ選択の為の情報として、ＳＧＳＮ識別子を保持し続ける。
　Ｉｕ　Ｒｅｌｅａｓｅが行われると（ＲＮＣ１７１から一般ＳＧＳＮ１２１へのＩＵ　Ｒｅｌｅａｓｅ　Ｃｏｍｐｌｅｔｅ（６）の送信後）、次に、図１６に示すように、ＵＥ１０１はＲＡＵ（ＲＡ　Ｕｐｄａｔｅ）　Ｒｅｑｕｅｓｔ（２）を送信する。
　ＲＡＵ　Ｒｅｑｕｅｓｔ（２）を、まず、ＮｏｄｅＢ１１１が受信し、ＮｏｄｅＢ１１１は、ＲＡＵ　Ｒｅｑｕｅｓｔ（３）をＲＮＣ１７１に転送する。
　ＲＮＣ１７１はこれをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＩｕ　Ｒｅｌｅａｓｅ済みの状態なので、ＳＧＳＮ選択を行い、Ｉｕ　Ｃｏｎｎｅｃｔｉｏｎを確立する。
　ＳＧＳＮ選択において、ＲＮＣ１７１は、一般ＳＧＳＮ１２１から受信したＩＵ　Ｒｅｌｅａｓｅ　Ｃｏｍｍａｎｄ信号で指示されたＳＧＳＮ識別子に従い、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２を選択する。ＲＮＣはＩｕ　Ｒｅｌｅａｓｅ時にｏｌｄ　ＳＧＳＮ（＝一般ＳＧＳＮ）から指示されたＲＡＩ（若しくはＮＲＩ）に従ってＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮを選択。なお、ＲＮＣはＵＥ毎に次のＲＡＩを保持する機能を有する。
　Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２は、ＲＡＵ　Ｒｅｑｕｅｓｔを受信した後、通常のＲＡ　Ｕｐｄａｔｅ　Ｐｒｏｃｅｄｕｒｅを継続する。ＮＡＳ上のＰ－ＴＭＳＩ（ＲＡＩ）は旧ＳＧＳＮである一般ＳＧＳＮを示しているので、Ｃｏｎｔｅｘｔを取得する。
　また、一般ＳＧＳＮ１２１及びＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２はＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この機能は実施例６と同様である。
　また、図１５及び図１６では図示されていないが、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に対して一般ＳＧＳＮ１２１に接続するべきＵＥ１０１からのＡｔｔａｃｈ　Ｒｅｑｕｅｓｔ信号が転送された場合も、同様の手段でＵＥ１０１にＭＭＥ再選択を促すことが可能である。
　また、本実施例では、図１６の手順にて、ＲＡ　Ｕｐｄａｔｅ　Ｐｒｏｃｅｄｕｒｅを用いたが、ＲＮＣ１７１でＳＧＳＮ選択を行うためのものであることから、例えばＰＤＰ　Ｃｏｎｔｅｘｔ　Ａｃｔｉｖａｔｉｏｎ等Ｉｕ　Ｃｏｎｎｅｃｔｉｏｎを再確立する、その他のＰｒｏｃｅｄｕｒｅを用いても実現可能である。
　以上説明したように、本実施例においては、一般ＳＧＳＮがＲＮＣに対してＳＧＳＮ再選択を指示し、ＲＮＣはそれを受けて次回ＳＧＳＮ選択時に特定ＳＧＳＮを指定した上で、Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＳＧＳＮに接続させることができる。
＜実施例１１＞
　実施例１１として、ＥＰＣにおいて、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）を跨いだハンドオーバの例を説明する。図１７は、実施例１１の構成（システム構成）を例示する図である。図１７を参照すると、ＵＥ２０１を備え、ＵＥ２０１と無線接続するＲＡＮ（Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ）として、ハンドオーバ元のソースｅＮｏｄｅＢ（Ｓｏｕｒｃｅ　ｅＮｏｄｅＢ）２０２とハンドオーバ先のターゲットｅＮｏｄｅＢ（Ｔａｒｇｅｔ　ｅＮｏｄｅＢ）２０３を備えている。ＣＮ（Ｃｏｒｅ　Ｎｅｔｗｏｒｋ）は、ソースＭＭＥ（Ｓｏｕｒｃｅ　ＭＭＥ）２０４、ターゲットＭＭＥ（Ｔａｒｇｅｔ　ＭＭＥ）２０５、ソースＳＧＷ（Ｓｏｕｒｃｅ　ＳＧＷ）２０６、ターゲットＳＧＷ（Ｔａｒｇｅｔ　ＳＧＷ）２０７、ＤＮＳサーバ２０９、ＨＳＳ２１１、ＰＧＷ２０８を備え、ＰＧＷ２０８からサービスネットワーク２１０に接続される。この例では、ハンドオーバのソースＭＭＥ２０４とターゲットＭＭＥ２０５は、ともに特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）である。図１８は、実施例１１の動作例（シーケンス動作）を説明するためのシーケンス図である。なお、図１８は、３ＧＰＰ　ＴＳ２３．４０１のＦｉｇｕｒｅ　５．５．１．２．２－１：　Ｓ１－ｂａｓｅｄ　ｈａｎｄｏｖｅｒに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１　５．５．１．２．２の記載が参照される。以下、図１７及び図１８を参照して動作を説明する。
　ハンドオーバ元のソースｅＮｏｄｅＢ（Ｓｏｕｒｃｅ　ｅＮｏｄｅＢ）２０２が、ＵＥ２０１との接続において信号劣化を検出すると、Ｈａｎｄｏｖｅｒ　Ｒｅｑｕｉｒｅｄ（２）を、ソースＭＭＥ（Ｓｏｕｒｃｅ　ＭＭＥ）２０４に送信する。Ｈａｎｄｏｖｅｒ　Ｒｅｑｕｉｒｅｄ（２）には、Ｔａｒｇｅｔ　ＴＡＩ（Ｔｒａｃｋｉｎｇ　Ａｒｅａ　Ｉｄｅｎｔｉｔｙ）などの情報が含まれている。Ｓｏｕｒｃｅ　ＭＭＥ２０４は、前記情報から、ターゲットＭＭＥ（Ｔａｒｇｅｔ　ＭＭＥ）２０５への、ＭＭＥ間ハンドオーバ（Ｉｎｔｅｒ　ＭＭＥ　ｈａｎｄｏｖｅｒ）の実行を判断する。
　この実施例では、Ｓｏｕｒｃｅ　ＭＭＥ２０４がＴａｒｇｅｔ　ＭＭＥ２０５を決定する際に、Ｓｏｕｒｃｅ　ＭＭＥ２０４が保持している特定ＭＭＥ接続要求情報を用いてＴａｒｇｅｔ　ＭＭＥ２０５を決定する。なお、Ｓｏｕｒｃｅ　ＭＭＥ２０４が保持する特定ＭＭＥ接続要求情報は、ＵＥ２０１から特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）に接続するための特定ＭＭＥ接続要求情報を付与したＲＲＣ信号を受信したｅＮｏｄｅＢ２０２が該特定ＭＭＥ接続要求情報を例えばＳ１－ＡＰ信号にて特定ＭＭＥであるＳｏｕｒｃｅ　ＭＭＥ２０４に通知し、Ｓｏｕｒｃｅ　ＭＭＥ２０４で保持しているものである。
　Ｔａｒｇｅｔ　ＭＭＥ２０５（ハンドオーバ先のＭＭＥ）の決定において、Ｓｏｕｒｃｅ　ＭＭＥ２０４で保持している特定ＭＭＥ接続要求情報を元に、Ｓｏｕｒｃｅ　ＭＭＥ２０４で保持するローカルコンフィグレーションを用いて決定しても良い。なお、ローカルコンフィグレーションは、例えばオペレータによって設定され、装置（ＭＭＥ）で内部的に管理保持する情報（コンフィグレーション情報）である（例えばＭＴＣ加入者（ＭＴＣ端末）がハンドオーバする際に、ＭＴＣグループとハンドオーバ先の移動エリアに応じた情報等を含む）。例えば特定ＭＭＥ接続要求情報がＡＰＮ（Ａｃｃｅｓｓ　Ｐｏｉｎｔ　Ｎａｍｅ）とした場合、ＡＰＮを元に、例えばＬＡＰＩ（Ｌｏｗ　Ａｃｃｅｓｓ　Ｐｒｉｏｒｉｔｙ　Ｉｎｄｉｃａｔｉｏｎ）の数値に対応するローカルな情報（ローカルコンフィグレーション）で、ハンドオーバ先のＭＭＥの選択を行う。あるいは、Ｓｏｕｒｃｅ　ＭＭＥ２０４で保持するローカルコンフィグレーションを用いてＴａｒｇｅｔ　ＭＭＥ２０５を決定するようにしても良い。
　また、Ｓｏｕｒｃｅ　ＭＭＥ２０４は、Ｔａｒｇｅｔ　ＴＡＩ（Ｔｒａｃｋｉｎｇ　Ａｒｅａ　Ｉｄｅｎｔｉｔｙ）等の位置情報と共に、特定ＭＭＥ接続要求情報を設定し、ＤＮＳサーバ（ＤＮＳ　ｓｅｒｖｅｒ）２０９に、「ＤＮＳ　Ｑｕｅｒｙ」を行う事で、Ｔａｒｇｅｔ　ＭＭＥ２０５を決定しても良い。
　Ｓｏｕｒｃｅ　ＭＭＥ２０４がＴａｒｇｅｔ　ＭＭＥ２０５へのＩｎｔｅｒ　ＭＭＥ　ｈａｎｄｏｖｅｒの実行を決定すると、Ｓｏｕｒｃｅ　ＭＭＥ２０４はＴａｒｇｅｔ　ＭＭＥ２０５に対して、フォアワードリロケーション要求（Ｆｏｒｗａｒｄ　Ｒｅｌｏｃａｔｉｏｎ　Ｒｅｑｕｅｓｔ）（３）を送信する。その際、Ｓｏｕｒｃｅ　ＭＭＥ２０４は、フォアワードリロケーション要求（３）に、Ｓｏｕｒｃｅ　ＭＭＥ２０４が保持している特定ＭＭＥ接続要求情報を設定しても良い。
　Ｔａｒｇｅｔ　ＭＭＥ２０５は、更なるＩｎｔｅｒ　ＭＭＥ　ｈａｎｄｏｖｅｒを実行する際、Ｔａｒｇｅｔ　ＭＭＥ２０５で保持する特定ＭＭＥ接続要求情報を利用して特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）の選択が可能になる。
　これ以降のシーケンスについては、関連技術にしたがってＩｎｔｅｒ　ＭＭＥ　ｈａｎｄｏｖｅｒ処理が実施される。
＜実施例１２＞
　実施例１２として、ＵＭＴＳにおいて特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ)を跨いだＳＲＮＳ（Ｓｅｒｖｉｎｇ　Ｒａｄｉｏ　Ｎｅｔｗｏｒｋ　Ｓｕｂｓｙｓｔｅｍ）　ｒｅｌｏｃａｔｉｏｎ（ハンドオーバー）の例を説明する。図１９、図２０は、実施例１２を説明するための図である。図２１は、実施例１２の動作例を説明するためのシーケンス図である。
　図１９を参照すると、ＵＥ３０１を備え、ＵＥ３０１と無線接続するＲＡＮ（Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ）として、ハンドオーバ元のソースＲＮＣ（Ｓｏｕｒｃｅ　ＲＮＣ）３０２、ハンドオーバ先のターゲットＲＮＣ（Ｔａｒｇｅｔｅ　ＲＮＣ）３０３を備えている。ＣＮ（Ｃｏｒｅ　Ｎｅｔｗｏｒｋ）は、ソースＳＧＳＮ（Ｓｏｕｒｃｅ　ＳＧＳＮ）３０４、ターゲットＳＧＳＮ（Ｔａｒｇｅｔ　ＳＧＳＮ）３０５、ソースＳＧＷ（Ｓｏｕｒｃｅ　ＳＧＷ）３０６、ターゲットＳＧＷ（Ｔａｒｇｅｔ　ＳＧＷ）３０７、ＤＮＳサーバ３０９、ＨＳＳ３１１、ＰＧＷ３０８を備え、ＰＧＷ３０８を介してサービスネットワーク３１０に接続される。この例では、ハンドオーバのソースＳＧＳＮ３０４とターゲットＳＧＳＮ３０５は、ともに特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）である。なお、図２１は、３ＧＰＰ　ＴＳ２３．０６０のＦｉｇｕｒｅ　３９：ＳＲＮＳ　Ｒｅｌｏｃａｔｉｏｎ　Ｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は同図に従う。各シーケンスの詳細は、３ＧＰＰ　ＴＳ２３．０６０　６．９．２．２．１の記載が参照される（ただし、３ＧＰＰ　ＴＳ２３．０６０のＦｉｇｕｒｅ　３９では、端末はＭＳ（Ｍｏｂｉｌｅ　Ｓｔａｔｉｏｎ）とされているが、図２１ではＵＥである）。
　以下、図２０及び図２１を参照して動作を説明する。図１９は、ＣＮがＥＰＣで構成される場合であるが、この実施例１２の動作に関して特に差異が無い事より、本実施例の動作は、図１９、及び図２０で示される構成で有効である。図２０では、ＣＮにおいて、図１９のＣＮにおいて、ソースＳＧＷ（Ｓｏｕｒｃｅ　ＳＧＷ）３０６、ターゲットＳＧＷ（Ｔａｒｇｅｔ　ＳＧＷ）３０７がない点、図１９のＰＧＷ３０８の代わりに、ＧＧＳＮ４０８が配設されている点が相違している。
　Ｓｏｕｒｃｅ　ＲＮＣ４０２が、ＵＥ４０１との接続において例えば信号劣化を検出すると、Ｒｅｌｏｃａｔｉｏｎ　Ｒｅｑｕｉｒｅｄ（２）をＳｏｕｒｃｅ　ＳＧＳＮ４０４に送信する。Ｒｅｌｏｃａｔｉｏｎ　Ｒｅｑｕｉｒｅｄ（２）には、Ｔａｒｇｅｔ　ＩＤなどの情報が含まれている。Ｓｏｕｒｃｅ　ＳＧＳＮ４０４は、その情報からＴａｒｇｅｔ　ＳＧＳＮ４０５へのｉｎｔｅｒ　ＳＧＳＮ　ＳＲＮＳ（Ｓｅｒｖｉｎｇ　Ｒａｄｉｏ　Ｎｅｔｗｏｒｋ　Ｓｕｂｓｙｓｔｅｍ）　ｒｅｌｏｃａｔｉｏｎの実行を判断する。
　この実施例では、Ｓｏｕｒｃｅ　ＳＧＳＮ４０４がＴａｒｇｅｔ　ＳＧＳＮ４０５を決定する際に、Ｓｏｕｒｃｅ　ＳＧＳＮ４０４が保持している特定ＳＧＳＮ接続要求情報を用いてＴａｒｇｅｔ　ＳＧＳＮ４０５を決定する。Ｓｏｕｒｃｅ　ＳＧＳＮ４０４が保持している特定ＳＧＳＮ接続要求情報は、ＵＥ４０１から、特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）に接続するための特定ＳＧＳＮ接続要求情報を付与したＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）信号を受信したＲＮＣ４０３が、前記特定ＳＧＳＮ接続要求情報をＩｕ信号にて特定ＳＧＳＮであるＳｏｕｒｃｅ　ＳＧＳＮ４０４に通知し、Ｓｏｕｒｃｅ　ＳＧＳＮ４０４で保持しているものである。Ｔａｒｇｅｔ　ＳＧＳＮ４０５の決定は、Ｓｏｕｒｃｅ　ＳＧＳＮ４０４で保持している前記特定ＳＧＳＮ接続要求情報を元にローカルコンフィグレーションで決定するようにしてもよい。あるいは、Ｓｏｕｒｃｅ　ＳＧＳＮ４０４が保持するローカルコンフィグレーションを用いて決定しても良い。あるいは、Ｓｏｕｒｃｅ　ＳＧＳＮ４０４は、Ｔａｒｇｅｔ　ＩＤなどの位置情報と共に特定ＳＧＳＮ接続要求情報を設定し、ＤＮＳ　ｓｅｒｖｅｒ４０９にＤＮＳ　Ｑｕｅｒｙする事で、Ｔａｒｇｅｔ　ＳＧＳＮ４０５を決定しても良い。
　Ｓｏｕｒｃｅ　ＳＧＳＮ４０４がＴａｒｇｅｔ　ＳＧＳＮ４０５へのｉｎｔｅｒ　ＳＧＳＮ　ＳＲＮＳ　ｒｅｌｏｃａｔｉｏｎの実行を決定すると、Ｓｏｕｒｃｅ　ＳＧＳＮ４０４はＴａｒｇｅｔ　ＳＧＳＮ４０５に対して、Ｆｏｒｗａｒｄ　Ｒｅｌｏｃａｔｉｏｎ　Ｒｅｑｕｅｓｔ（３）を送信する。Ｓｏｕｒｃｅ　ＳＧＳＮ４０４は、この信号（Ｆｏｒｗａｒｄ　Ｒｅｌｏｃａｔｉｏｎ　Ｒｅｑｕｅｓｔ）に、Ｓｏｕｒｃｅ　ＳＧＳＮ４０４が保持している特定ＳＧＳＮ接続要求情報を設定しても良い。
　Ｔａｒｇｅｔ　ＳＧＳＮ４０５は、更なるｉｎｔｅｒ　ＳＧＳＮ　ＳＲＮＳ　ｒｅｌｏｃａｔｉｏｎを実行する際、特定ＳＧＳＮ接続要求情報を利用して特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）の選択が可能になる。
　これ以降のシーケンスについては、関連技術にしたがって、ｉｎｔｅｒ　ＳＧＳＮ　ＳＲＮＳ　ｒｅｌｏｃａｔｉｏｎ処理が実施される。
＜実施例１３＞
　実施例１３として、ＥＰＣにおいて特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）から特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）にハンドオーバする例を説明する。図２２は、実施例１３の構成を例示する図である。図２２を参照すると、ＵＥ５０１と、ＵＥ５０１に無線接続するＲＡＮ（Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｎｅｔｗｏｒｋ）としてソースｅＮｏｄｅＢ（Ｓｏｕｒｃｅ　ｅＮｏｄｅＢ）５０２、ターゲットＲＮＣ（Ｔａｒｇｅｔｅ　ＲＮＣ）５０３を備えている。ＣＮ（Ｃｏｒｅ　Ｎｅｔｗｏｒｋ）は、ソースＭＭＥ（Ｓｏｕｒｃｅ　ＭＭＥ）５０４、ターゲットＳＧＳＮ（Ｔａｒｇｅｔ　ＳＧＳＮ）５０５、ＳＧＷ５０６、ＤＮＳサーバ５０８、ＨＳＳ５１０、ＰＧＷ５０７を備え、ＰＧＷ５０７を介してサービスネットワーク５０９に接続される。図２３は、実施例１３の動作例を説明するためのシーケンス図である。なお、図２３は、３ＧＰＰ　ＴＳ２３．４０１のＦｉｇｕｒｅ　５．５．２．１．２－２：　Ｅ－ＵＴＲＡＮ　ｔｏ　ＵＴＲＡＮ　Ｉｕ　ｍｏｄｅ　Ｉｎｔｅｒ　ＲＡＴ　ＨＯ，ｐｒｅｐａｒａｔｉｏｎ　ｐｈａｓｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１　５．５．２．１．２の記載が参照される。
　以下、図２２及び図２３を参照して動作を説明する。Ｓｏｕｒｃｅ　ｅＮｏｄｅＢ５０２が、ＵＥ５０１との接続において信号劣化を検出すると、Ｈａｎｄｏｖｅｒ　Ｒｅｑｕｉｒｅｄ（２）をＳｏｕｒｃｅ　ＭＭＥ５０４に送信する。Ｈａｎｄｏｖｅｒ　Ｒｅｑｕｉｒｅｄ（２）には、Ｔａｒｇｅｔ　ＴＡＩ（Ｔｒａｃｋｉｎｇ　ａｒｅａ　ＩＤ）などの情報が含まれており、Ｓｏｕｒｃｅ　ＭＭＥ５０４は、その情報からＴａｒｇｅｔ　ＳＧＳＮ５０５へのＩｎｔｅｒ　ＲＡＴ（Ｒａｄｉｏ　Ａｃｃｅｓｓ　Ｔｅｃｈｎｏｌｏｇｙ）　ｈａｎｄｏｖｅｒの実行を判断する。
　この実施例では、Ｓｏｕｒｃｅ　ＭＭＥ５０４がＴａｒｇｅｔ　ＳＧＳＮ　５０５を決定する際に、Ｓｏｕｒｃｅ　ＭＭＥ５０４が保持している特定ＭＭＥ接続要求情報を用いてＴａｒｇｅｔ　ＳＧＳＮ５０５を決定する。Ｔａｒｇｅｔ　ＳＧＳＮ５０５の決定は、特定ＭＭＥ接続要求情報を元にローカルコンフィグレーションで決定しても良い。あるいは、Ｓｏｕｒｃｅ　ＭＭＥ５０４が保持するローカルコンフィグレーションを用いて決定しても良い。また、Ｓｏｕｒｃｅ　ＭＭＥ５０４は、Ｔａｒｇｅｔ　ＩＤなどの位置情報と共に特定ＭＭＥ接続要求情報を設定し、ＤＮＳ　ｓｅｒｖｅｒ５０８にＤＮＳ　Ｑｕｅｒｙする事で、Ｔａｒｇｅｔ　ＳＧＳＮ５０５を決定しても良い。
　Ｓｏｕｒｃｅ　ＭＭＥ５０４がＴａｒｇｅｔ　ＳＧＳＮ５０５へのＩｎｔｅｒ　ＲＡＴ　ｈａｎｄｏｖｅｒの実行を決定すると、Ｓｏｕｒｃｅ　ＭＭＥ５０４は、Ｔａｒｇｅｔ　ＳＧＳＮ５０５に対して、Ｆｏｒｗａｒｄ　Ｒｅｌｏｃａｔｉｏｎ　Ｒｅｑｕｅｓｔ（３）を送信する。Ｓｏｕｒｃｅ　ＭＭＥ５０４は、この信号に、Ｓｏｕｒｃｅ　ＭＭＥ５０４が保持している特定ＭＭＥ接続要求情報を設定しても良い。Ｔａｒｇｅｔ　ＳＧＳＮ５０５は、更なるＩｎｔｅｒ　ＲＡＴ　ｈａｎｄｏｖｅｒを実行する際、特定ＭＭＥ接続要求情報を利用して、特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）の選択が可能になる。
　これ以降のシーケンスについては、関連技術にしたがったＩｎｔｅｒ　ＲＡＴ　ｈａｎｄｏｖｅｒ処理が実施される。
＜実施例１４＞
　実施例１４として、ＥＰＣにおいて特定ＳＧＳＮ（Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ）から特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ)にハンドオーバする例を説明する。実施例１４の構成は、図２２に示されるが、ハンドオーバの方向が逆になる。また、実施例１４の動作例を説明するためのシーケンスも、基本的に、図２３において、
ＳＧＳＮとＭＭＥ、及び、
ＲＮＣとｅＮｏｄｅＢ
の記述（動作シーケンス）が逆転する（逆方向のシーケンス動作となる）だけである。
＜実施例１５＞
　実施例１５として、ＥＰＣにおいてＴｒａｃｋｉｎｇ　Ａｒｅａ　Ｕｐｄａｔｅ（ＴＡＵ）時に、ＵＥと特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）を接続させる例を説明する。実施例１５の構成は実施例１と同様である。図２４は、実施例１５の動作例を説明するためのシーケンス図である。なお、図２４は、３ＧＰＰ　ＴＳ２３．４０１のＦｉｇｕｒｅ　５．３．３．１－１：　Ｔｒａｃｋｉｎｇ　Ａｒｅａ　Ｕｐｄａｔｅ　ｐｒｏｃｅｄｕｒｅ　ｗｉｔｈ　Ｓｅｒｖｉｎｇ　ＧＷ　ｃｈａｎｇｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．４０１　５．３．３の記載が参照される。以下、図１及び図２４を参照して動作を説明する。
　ＵＥ１がＴＡＵ　Ｒｅｑｕｅｓｔ（３）をＭＭＥに送信する為に、まず、ｅＮｏｄｅＢ１１とのＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）　Ｃｏｎｎｅｃｔｉｏｎの確立を行う。ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ確立のために、ＵＥ１は、まずｅＮｏｄｅＢ１１にＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ信号を送信する。
　この時、ＵＥ１は、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ信号にＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２への接続を必要とすることを示すパラメータ（Ｕｓｅｒ　Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で新規に導入した値又はパラメータ）、又は、これらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ－ｉｄ等））を設定する。
　ＵＥ１は、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　ＲｅｑｕｅｓｔにてｅＮｏｄｅＢに、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥに接続可能であることを通知する　ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔの新規パラメータ（Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）が実装される。
　ｅＮｏｄｅＢ１１は、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ信号を受信したとき、ＵＥ１がＣｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に接続するべきことを記憶し、その後のＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｐｒｏｃｅｄｕｒｅを継続する。
　ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ確立後、ＵＥ１がＴＡＵ　Ｒｅｑｕｅｓｔ（２）を送信すると、ｅＮｏｄｅＢ１１が受信する。この時、ｅＮｏｄｅＢ１１は、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔの受信時に記憶した情報から、ＴＡＵ　Ｒｅｑｕｅｓｔ（３）を、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に転送する。ＴＡＵ　Ｒｅｑｕｅｓｔ（３）には、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔにて受信した特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）に接続可能であることを通知するＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔの新規パラメータ（Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）が、ｅＮｏｄｅＢ１１によって設定され、Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２に通知される。
　Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２では、ＴＡＵ　Ｒｅｑｕｅｓｔ（３）を受信した後、通常のＴＡＵ　Ｐｒｏｃｅｄｕｒｅを継続する。Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ２２は、受信したＴＡＵ　Ｒｅｑｕｅｓｔ（３）に設定された、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔにて受信した特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）に接続可能であることを通知する　ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔの新規パラメータ（Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅの新規Ｖａｌｕｅ若しくは新規パラメータ）を保持する。
　また、ＵＥ１は、一般ＭＭＥ２１、及び特定ＭＭＥ（Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ）２２のどちらのＭＭＥに接続するべきかを、ｅＮｏｄｅＢ１１に指示する機能を具備する。この時、ＵＥ１はコアネットワーク上の全てＭＭＥの情報を保持することは出来ないので、ｅＮｏｄｅＢ１１への指示は、ＭＭＥを一意に選択できる識別子ではなく、ＭＭＥ種別、若しくはサービス種別等の情報が用いられる。
　また、ｅＮｏｄｅＢ１１は、ＵＥ１をどのＭＭＥに接続させるべきか判断する機能を具備している。
　ｅＮｏｄｅＢ１１において、ＭＭＥの選択は、前述のとおり、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ内のユーザＩＤ（Ｕｓｅｒ　Ｉｄｅｎｔｉｔｙ）、通信確立要因（Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅ）の新規Ｖａｌｕｅ、又は新規パラメータ、又はこれらのパラメータを構成する一部分の識別子のいずれか、若しくは複数を組み合わせて行う。新規パラメータにはＭＴＣグループを識別するＩＤ、ＡＰＮなども含む。
　以上説明したように、本実施例においては、ＵＥがｅＮｏｄｅＢに対してＭＭＥ選択を指示し、ｅＮｏｄｅＢはそれを受けてＣｕｓｔｏｍｉｚｅｄ　ＭＭＥを指定した上で、ＴＡＵ　Ｐｒｏｃｅｄｕｒｅを継続することにより、ＵＥを適切なＭＭＥに位置登録させることができる。
＜実施例１６＞
　実施例１６として、ＵＭＴＳにおいてＲｏｕｔｉｎｇ　Ａｒｅａ　Ｕｐｄａｔｅ時にＵＥと特定ＳＧＳＮを接続させる例を説明する。実施例１６の構成は実施例６と同様である。図２５は、実施例１６の動作例を説明するシーケンス図である。なお、図２５は、３ＧＰＰ　ＴＳ２３．０６０のＦｉｇｕｒｅ　３６：　Ｉｕ　ｍｏｄｅ　ＲＡ　Ｕｐｄａｔｅ　ｐｒｏｃｅｄｕｒｅに基づいており、シーケンス番号は、同図に従う。各シーケンスの詳細は、ＴＳ２３．０６０　６．９．２の記載が参照される（３ＧＰＰ　ＴＳ２３．０６０のＦｉｇｕｒｅ　３６では、端末はＭＳとされているが、図２５では、ＵＥである）。以下、図２及び図２５を参照して動作を説明する。
　ＵＥ１０１がＲｏｕｔｉｎｇ　Ａｒｅａ　Ｕｐｄａｔｅ　ＲｅｑｕｅｓｔをＳＧＳＮに送信する為に、まずＲＮＣ１７１とのＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎの確立を行う。ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ確立の為、ＵＥ１０１は、まずＲＮＣ１７１にＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ信号を送信する。
　この時、ＵＥ１０１は、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ信号に、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（Ｕｓｅｒ　Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ－ｉｄ等））を設定する。
　ＲＮＣ１７１は、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ信号を受信したとき、ＵＥ１０１がＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に接続するべきことを記憶し、その後のＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｐｒｏｃｅｄｕｒｅを継続する。
　ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ確立後、ＵＥ１０１がＲｏｕｔｉｎｇ　Ａｒｅａ　Ｕｐｄａｔｅ　Ｒｅｑｕｅｓｔ（１）を送信すると、まず、ＮｏｄｅＢ１１１が受信し、これをＲＮＣ１７１に転送する。
　ＲＮＣ１７１は、これをＳＧＳＮに転送する。この時、ＲＮＣ１７１はＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔ信号の受信時に記憶した情報から、Ｒｏｕｔｉｎｇ　Ａｒｅａ　Ｕｐｄａｔｅ　Ｒｅｑｕｅｓｔ信号を、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に転送する。Ｒｏｕｔｉｎｇ　Ａｒｅａ　Ｕｐｄａｔｅ　Ｒｅｑｕｅｓｔには、ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ　Ｒｅｑｕｅｓｔにて受信した、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（Ｕｓｅｒ　Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅの新規Ｖａｌｕｅ、又は、新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又は、これらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ－ｉｄ等））がＲＮＣ１７１によって設定されＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２に通知される。
　Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２では、Ｒｏｕｔｉｎｇ　Ａｒｅａ　Ｕｐｄａｔｅ　Ｒｅｑｕｅｓｔを受信した後、通常のＲｏｕｔｉｎｇ　Ａｒｅａ　Ｕｐｄａｔｅ　Ｐｒｏｃｅｄｕｒｅを継続する。Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２は、受信したＲｏｕｔｉｎｇ　Ａｒｅａ　Ｕｐｄａｔｅ　Ｒｅｑｕｅｓｔに設定された、Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２への接続を必要とすることを示すパラメータ（Ｕｓｅｒ　Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子（ＩＭＳＩに含まれるＰＬＭＮ－ｉｄ等））を保持する。
　また、ＵＥ１０１は、一般ＳＧＳＮ１２１、及びＣｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ１２２のどちらのＳＧＳＮに接続するべきかをＲＮＣ１７１に指示する機能を具備するが、この時、ＵＥ１０１は、コアネットワーク上の全てＳＧＳＮの情報を保持することは出来ないので、ＲＮＣ１７１への指示は、ＳＧＳＮを一意に選択できる識別子ではなく、ＳＧＳＮ種別若しくはサービス種別等の情報である。
　また、ＲＮＣ１７１は、ＵＥ１０１をどのＳＧＳＮに接続させるべきか判断する機能を具備するが、この判断は、前述のとおり、Ｕｓｅｒ　Ｉｄｅｎｔｉｔｙ、Ｅｓｔａｂｌｉｓｈｍｅｎｔ　Ｃａｕｓｅの新規Ｖａｌｕｅ、又は新規パラメータ（本実施例で導入した新規の値又はパラメータ）、又はこれらのパラメータを構成する一部分の識別子のいずれか、若しくは複数を組み合わせて行う。新規パラメータにはＭＴＣグループを識別するＩＤ、ＡＰＮなども含む。
　以上説明したように、本実施例においては、ＵＥ１０１がＲＮＣ１７１に対してＳＧＳＮの選択を指示し、ＲＮＣ１７１は、この指示を受けて、特定ＳＧＳＮを指定した上で、Ｒｏｕｔｉｎｇ　Ａｒｅａ　Ｕｐｄａｔｅ　Ｐｒｏｃｅｄｕｒｅを継続する。かかる構成により、ＵＥ１０１を適切なＳＧＳＮに位置登録させることができる。
　以下、上記した実施形態、実施例において、コアネットワーク（ＣＮ）ノードを選択するいくつかの事例について説明する。
　ＭＴＣ（Ｍａｃｈｉｎｅ　Ｔｙｐｅ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ）デバイス（Ｍ２Ｍデバイス）を特定ＣＮノード（ＭＴＣデバイス向けに効率化したノード）に接続させる。
　ＭＢＭＳ利用ユーザを特定ＣＮノード（ＭＢＭＳ対応ＣＮノード）に接続させる。
　その他、新規サービスを小規模スタートさせるために、特定ＣＮノードのみでサービス提供する。
　特定のＵＥを、ＭＭＥとＳＧＷをコロケート（ｃｏｌｌｏｃａｔｅ）したノードに接続させる。特に制限されないが、例えば少量のデータトラヒックを、ＳＭＳ（Ｓｈｏｒｔ　Ｍｅｓｓａｇｅ　Ｓｅｒｖｉｃｅ）に載せ換えてＵＥに送信する場合、ＭＭＥとＳＧＷをコロケート（ｃｏｌｌｏｃａｔｅ）していると、ＳＭＳ変換処理の実装が容易化する。
　また、端末種別（ＣＳＦＢ（ＣＳ　Ｆａｌｌｂａｃｋ）端末とＶｏＬＴＥ端末等）でＭＭＥを振り分ける。ＣＳＦＢ（ＣＳ　Ｆａｌｌｂａｃｋ）は、ＬＴＥ接続中に、ＣＳ（Ｃｉｒｃｕｉｔ　Ｓｗｉｔｃｈｅｄ）サービス発着信があると、３Ｇ（又は２Ｇ）に無線を切り替える機能である。ＶｏＬＴＥ（Ｖｏｉｃｅ　ｏｖｅｒ　ＬＴＥ）は、ＬＴＥ上で音声（等ＣＳで提供していた）サービスを提供する機能である。なお、ＣＳＦＢ端末は、ＭＳＣとのインターワークが必要である。ＶｏＬＴＥ端末はＩＭＳとのインターワークが必要である。ＣＳＦＢで、先にアタッチしているＭＳＣに、コロケート（ｃｏｌｌｏｃａｔｅ）したＭＭＥを選択させる。
　なお、上記の特許文献の開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素の多様な組み合わせないし選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
１　ＵＥ
１１　ｅＮｏｄｅＢ
２１　一般ＭＭＥ
２２　Ｃｕｓｔｏｍｉｚｅｄ　ＭＭＥ
３１　ＨＳＳ
４１　Ｓ－ＧＷ（Ｓｅｒｖｉｎｇ　ＧＷ）
５０　ＨＳＳ
５１　Ｐ－ＧＷ（ＰＤＮ　ＧＷ）
６１　サービスネットワーク
１０１　ＵＥ（ＭＳ）
１１１　ＮｏｄｅＢ
１２１　一般ＳＧＳＮ
１２２　Ｃｕｓｔｏｍｉｚｅｄ　ＳＧＳＮ
１３１　ＨＬＲ
１４１　ＧＧＳＮ
１６１　サービスネットワーク
１７１　ＲＮＣ
２０１　ＵＥ
２０２　Ｓｏｕｒｃｅ　ｅＮｏｄｅＢ
２０３　Ｔａｒｇｅｔ　ｅＮｏｄｅＢ
２０４　Ｓｏｕｒｃｅ　ＭＭＥ
２０５　Ｔａｒｇｅｔ　ＭＭＥ
２０６　Ｓｏｕｒｃｅ　ＳＧＷ
２０７　Ｔａｒｇｅｔ　ＳＧＷ
２０８　ＰＧＷ（ＰＤＮ　ＧＷ）
２０９　ＤＮＳ　ｓｅｒｖｅｒ
２１０　サービスネットワーク
２１１　ＨＳＳ
３０１　ＵＥ
３０２　Ｓｏｕｒｃｅ　ＲＮＣ
３０３　Ｔａｒｇｅｔ　ＲＮＣ
３０４　Ｓｏｕｒｃｅ　ＳＧＳＮ
３０５　Ｔａｒｇｅｔ　ＳＧＳＮ
３０６　Ｓｏｕｒｃｅ　ＳＧＷ
３０７　Ｔａｒｇｅｔ　ＳＧＷ
３０８　ＰＧＷ（ＰＤＮ　ＧＷ）
３０９　ＤＮＳ　ｓｅｒｖｅｒ
３１０　サービスネットワーク
３１１　ＨＳＳ
４０１　ＵＥ
４０２　Ｓｏｕｒｃｅ　ＲＮＣ
４０３　Ｔａｒｇｅｔ　ＲＮＣ
４０４　Ｓｏｕｒｃｅ　ＳＧＳＮ
４０５　Ｔａｒｇｅｔ　ＳＧＳＮ
４０８　ＧＧＳＮ
４０９　ＤＮＳ　ｓｅｒｖｅｒ
４１０　サービスネットワーク
４１１　ＨＳＳ
５０１　ＵＥ
５０２　Ｓｏｕｒｃｅ　ｅＮｏｄｅＢ
５０３　Ｔａｒｇｅｔ　ＲＮＣ
５０４　Ｓｏｕｒｃｅ　ＭＭＥ
５０５　Ｔａｒｇｅｔ　ＳＧＳＮ
５０６　ＳＧＷ
５０７　ＰＧＷ（ＰＤＮ　ＧＷ）
５０８　ＤＮＳ　ｓｅｒｖｅｒ
５０９　サービスネットワーク

Claims (30)

  1. 　移動体通信システムのコアネットワークが、端末のモビリティ管理ノードとして、前記端末が利用するサービス特性又は端末種別に応じて選択される特定モビリティ管理ノードを備え、
    　モビリティ管理ノードを跨ぐハンドオーバが起動されると、前記特定モビリティ管理ノードは、保持している、特定モビリティ管理ノード接続要求情報に応じて、ハンドオーバ先のモビリティ管理ノードを選択する、通信システム。
  2. 　前記特定モビリティ管理ノードは、ハンドオーバ先のモビリティ管理ノードの選択を行う際、保持している前記特定モビリティ管理ノード接続要求情報を元にローカルコンフィグレーションを用いて決定するか、又は、保持しているローカルコンフィグレーションを用いて決定する、請求項１記載の通信システム。
  3. 　前記特定モビリティ管理ノードは、ハンドオーバ先のモビリティ管理ノードの選択を行う際、保持している前記特定モビリティ管理ノード接続要求情報を元に、ＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）サーバに問い合わせを行い、前記問い合わせの結果として、前記ＤＮＳサーバから受信したハンドオーバ先のモビリティ管理ノードの候補群の中からモビリティ管理ノードを選択する、請求項１記載の通信システム。
  4. 　前記端末から、前記特定モビリティ管理ノードに接続するための前記特定モビリティ管理ノード接続要求情報を付与した第１の信号（ＲＲＣ信号）を受信した基地局装置は、前記特性モビリティ管理ノード接続要求情報を第２の信号（Ｓ１－ＡＰ信号）にて、特定モビリティ管理ノードに通知する、請求項１記載の通信システム。
  5. 　前記基地局装置から、前記特定モビリティ管理ノード接続要求情報を第２の信号（Ｓ１－ＡＰ信号）にて受信した特定モビリティ管理ノードは、前記特定モビリティ管理ノード接続要求情報を保持する請求項４記載の通信システム。
  6. 　前記前記モビリティ管理ノードを跨ぐハンドオーバは、
    モビリティ管理エンティティ・ノード（ＭＭＥ）間のハンドオーバ、
    サービングＧＰＲＳ（Ｇｅｎｅｒａｌ　Ｐａｃｋｅｔ　Ｒａｄｉｏ　Ｓｅｒｖｉｃｅ）サポートノード（ＳＧＳＮ）間のハンドオーバ、
    ＭＭＥからＳＧＳＮへのハンドオーバ、
    ＳＧＳＮからＭＭＥへのハンドオーバ
    の少なくとも１つを含む、請求項１記載の通信システム。
  7. 　前記端末とセッションを確立している、一般モビリティ管理ノードは、基地局装置と前記一般モビリティ管理ノードとの間で確立されている、Ｓ１コネクションの開放（Ｓ１　Ｒｅｌｅａｓｅ）時に、次回にモビリティ管理ノードを選択する際に、前記特定モビリティ管理ノードを選択するように前記基地局装置に指示し、その後、前記端末が、位置管理エリア更新リクエスト（ＴＡ（Ｔｒａｃｋｉｎｇ　Ａｒｅａ）　Ｕｐｄａｔｅ　Ｒｅｑｕｅｓｔ）を送信した際に、前記基地局装置が、前記特定モビリティ管理ノードを選択することで、前記端末を、前記特定モビリティ管理ノードへ接続する、請求項１記載の通信システム。
  8. 　前記端末から、前記特定モビリティ管理ノードである特定ＳＧＳＮに接続するための前記特定ＳＧＳＮ接続要求情報を付与した第１の信号（ＲＲＣ信号）を受信した前記ＲＮＣは、前記特定ＳＧＳＮ接続要求情報を第２の信号（Ｉｕ信号）にて、特定ＳＧＳＮに通知する請求項１記載の通信システム。
  9. 　ＲＮＣ（Ｒａｄｉｏ　Ｎｅｔｗｏｒｋ　Ｃｏｎｔｒｏｌｌｅｒ）から、特定ＳＧＳＮ接続要求情報を第２の信号（Ｉｕ信号）にて受信した特定ＳＧＳＮは、前記特定ＳＧＳＮ接続要求情報を保持する請求項８記載の通信システム。
  10. 　前記端末からのアタッチ要求を、基地局装置を介して受信した、前記一般モビリティ管理ノードである第１のモビリティ管理エンティティ・ノードは、前記端末を、前記第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する前記特定モビリティ管理ノードである第２のモビリティ管理エンティティ・ノードに接続するために、前記基地局装置に対して、モビリティ管理エンティティ再選択要求信号を送信し、
    　前記基地局装置は、前記第２のモビリティ管理エンティティ・ノードにアタッチ要求を再送することで、前記端末を前記第２のモビリティ管理エンティティ・ノードに接続する、請求項１記載の通信システム。
  11. 　前記端末からのアタッチ要求を、基地局装置を介して受信した一般モビリティ管理ノードである第１のモビリティ管理エンティティ・ノードは、前記端末を、前記第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する前記特定モビリティ管理ノードである第２のモビリティ管理エンティティ・ノードに接続するために、前記第２のモビリティ管理エンティティ・ノードに対して、モビリティ管理エンティティ変更要求信号を送信し、前記第２のモビリティ管理エンティティ・ノードが、前記アタッチ要求に対するアタッチ処理手順を継続することで、前記端末を前記第２のモビリティ管理エンティティ・ノードへ接続する請求項１記載の通信システム。
  12. 　前記端末からのアタッチ要求を、基地局装置を介して受信した一般モビリティ管理ノードである第１のモビリティ管理エンティティ・ノードは、前記端末を、前記第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する前記特定モビリティ管理ノードである第２のモビリティ管理エンティティ・ノードに接続するために、前記第２のモビリティ管理エンティティ・ノードの識別子を付与したアタッチリジェクトを前記端末に送信し、
    　前記端末は、アタッチ要求に、前記第２のモビリティ管理エンティティ・ノードの識別子を付与して再送信し、前記第２のモビリティ管理エンティティ・ノードに接続する、請求項１記載の通信システム。
  13. 　前記端末は、一般モビリティ管理ノードである第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する前記特定モビリティ管理ノードである第２のモビリティ管理エンティティ・ノードへの接続要求情報を付与したＲＲＣコネクション（ＲＲＣ　Ｃｏｎｎｅｃｔｉｏｎ）要求を、基地局装置に送信し、
    　前記ＲＲＣコネクションリクエストを受信した前記基地局装置は、ＲＲＣコネクションを確立した前記端末からのアタッチ要求をモビリティ管理エンティティに送信する際に、前記第２のモビリティ管理エンティティ・ノードを選択し、前記端末を前記第２のモビリティ管理エンティティ・ノードに接続する、請求項１記載の通信システム。
  14. 　前記端末とセッションを確立している一般モビリティ管理ノードである第１のモビリティ管理エンティティ・ノードは、基地局装置と前記第１のモビリティ管理エンティティ・ノードとの間で確立されているコネクションの開放時に、次回のモビリティ管理エンティティの選択で前記第１のモビリティ管理エンティティ・ノードが提供するサービスと異なるサービスを提供する前記特定モビリティ管理ノードである第２のモビリティ管理エンティティ・ノードを選択するように、前記基地局装置に対して指示し、
    　前記端末が位置管理エリア更新要求を前記基地局装置に送信した際に、前記基地局装置は、前記第２のモビリティ管理エンティティ・ノードを選択し、前記端末を前記第２のモビリティ管理エンティティ・ノードに接続する、請求項１記載の通信システム。
  15. 　前記端末からのアタッチ要求を、無線ネットワークコントローラを介して受信した前記一般モビリティ管理ノードである第１のサービングＧＰＲＳ（Ｇｅｎｅｒａｌ　Ｐａｃｋｅｔ　Ｒａｄｉｏ　Ｓｅｒｖｉｃｅ）サポートノードは、前記端末を、前記第１のサービングＧＰＲＳサポートノードが提供するサービスと異なるサービスを提供する前記特定モビリティ管理ノードである第２のサービングＧＰＲＳサポートノードに接続するために、前記無線ネットワークコントローラに、サービングＧＰＲＳサポートノード再選択要求信号を送信し、
    　前記無線ネットワークコントローラは、前記第２のサービングＧＰＲＳサポートノードにアタッチ要求を再送することで、前記端末を第２のサービングＧＰＲＳサポートノードに接続する、請求項１記載の通信システム。
  16. 　前記端末からのアタッチ要求を、無線ネットワークコントローラを介して受信した一般モビリティ管理ノードである第１のサービングＧＰＲＳ（Ｇｅｎｅｒａｌ　Ｐａｃｋｅｔ　Ｒａｄｉｏ　Ｓｅｒｖｉｃｅ）サポートノード（ＳＧＳＮ）は、前記端末を、前記第１のサービングＧＰＲＳサポートノードが提供するサービスと異なるサービスを提供する前記特定モビリティ管理ノードである第２のサービングＧＰＲＳサポートノードに接続するために、前記第２のサービングＧＰＲＳサポートノードに、サービングＧＰＲＳサポートノード変更要求信号を送信し、
    　前記第２のサービングＧＰＲＳサポートノードが、前記アタッチ要求に対するアタッチ処理を継続することで、前記端末を、前記第２のサービングＧＰＲＳサポートノードに接続する、請求項１記載の通信システム。
  17. 　前記端末からのアタッチ要求を、無線ネットワークコントローラを介して受信した一般モビリティ管理ノードである第１のサービングＧＰＲＳ（Ｇｅｎｅｒａｌ　Ｐａｃｋｅｔ　Ｒａｄｉｏ　Ｓｅｒｖｉｃｅ）サポートノード（ＳＧＳＮ）は、前記端末を、前記第１のサービングＧＰＲＳサポートノードが提供するサービスと異なるサービスを提供する前記特定モビリティ管理ノードである第２のサービングＧＰＲＳサポートノードに接続するために、前記第２のサービングＧＰＲＳサポートノードの識別子を付与したアタッチリジェクトを前記端末に送信し、
    　前記端末は、アタッチ要求に、前記第２のサービングＧＰＲＳサポートノードの識別子を付与して再送信して前記端末を前記第２のサービングＧＰＲＳサポートノードに接続する、請求項１記載の通信システム。
  18. 　前記端末は、一般モビリティ管理ノードである第１のサービングＧＰＲＳ（Ｇｅｎｅｒａｌ　Ｐａｃｋｅｔ　Ｒａｄｉｏ　Ｓｅｒｖｉｃｅ）サポートノードが提供するサービスと異なるサービスを提供する前記特定モビリティ管理ノードである第２のサービングＧＰＲＳサポートノード）への接続要求情報を付与したＲＲＣ（Ｒａｄｉｏ　Ｒｅｓｏｕｒｃｅ　Ｃｏｎｔｒｏｌ）コネクション要求を、無線ネットワークコントローラに送信し、
    　前記ＲＲＣコネクションリクエストを受信した前記無線ネットワークコントローラは、ＲＲＣコネクションを確立した前記端末からのアタッチ要求をサービングＧＰＲＳサポートノードに送信する際に、前記第２のサービングＧＰＲＳサポートノードを選択し、前記端末を前記第２のサービングＧＰＲＳサポートノードに接続する、請求項１記載の通信システム。
  19. 　前記端末とセッションを確立している一般モビリティ管理ノードである第１のサービングＧＰＲＳ（Ｇｅｎｅｒａｌ　Ｐａｃｋｅｔ　Ｒａｄｉｏ　Ｓｅｒｖｉｃｅ）サポートノードは、前記第１のサービングＧＰＲＳ（Ｇｅｎｅｒａｌ　Ｐａｃｋｅｔ　Ｒａｄｉｏ　Ｓｅｒｖｉｃｅ）サポートノードと無線ネットワークコントローラ間で確立されているコネクションの開放時に、次回のサービングＧＰＲＳサポートノードの選択で、前記第１のサービングＧＰＲＳサポートノードが提供するサービスと異なるサービスを提供する前記特定モビリティ管理ノードである第２のサービングＧＰＲＳサポートノードを選択するように、前記無線ネットワークコントローラに指示を出し、
    　前記端末が位置管理エリア更新要求を前記無線ネットワークコントローラに送信した際に、前記無線ネットワークコントローラは、前記第２のサービングＧＰＲＳサポートノードを選択し、前記端末を第２のサービングＧＰＲＳサポートノードに接続する、請求項１記載の通信システム。
  20. 　移動体通信システムのコアネットワークに、端末のモビリティ管理ノードとして、前記端末が利用するサービス特性又は端末種別に応じて選択される特定モビリティ管理ノードを設け、
    　前記モビリティ管理ノードを跨ぐハンドオーバが起動されると、前記特定モビリティ管理ノードは、保持している、特定モビリティ管理ノード接続要求情報に応じて、ハンドオーバ先のノードを選択する、通信方法。
  21. 　前記特定モビリティ管理ノードは、ハンドオーバ先のモビリティ管理ノードの選択を行う際、保持している前記特定モビリティ管理ノード接続要求情報を元にローカルコンフィグレーションを用いて決定するか、又は、保持しているローカルコンフィグレーションを用いて決定する、請求項２０記載の通信方法。
  22. 　前記特定モビリティ管理ノードは、ハンドオーバ先のモビリティ管理ノードの選択を行う際、保持している前記特定モビリティ管理ノード接続要求情報を元に、ＤＮＳサーバに問い合わせを行い、その結果として、前記ＤＮＳサーバから受信したハンドオーバ先のモビリティ管理ノードの候補群の中から選択する、請求項２０記載の通信方法。
  23. 　前記端末から、前記特定モビリティ管理ノードに接続するための前記特定モビリティ管理ノード接続要求情報を付与した第１の信号（ＲＲＣ信号）を受信した無線アクセスノードは、前記特性モビリティ管理ノード接続要求情報を第２の信号（Ｓ１－ＡＰ信号）にて特定モビリティ管理ノードに通知する、請求項２０記載の通信方法。
  24. 　前記基地局装置から前記特定モビリティ管理ノード接続要求情報を第２の信号（Ｓ１－ＡＰ信号）にて受信した特定モビリティ管理ノードは、前記特定モビリティ管理ノード接続要求情報を保持する請求項２０記載の通信方法。
  25. 　端末のモビリティ管理機能を有し、前記端末が利用するサービス特性又は端末種別に応じて選択される特定のモビリティ管理ノード装置であって、前記モビリティ管理ノードを跨ぐハンドオーバが起動されると、前記特定モビリティ管理ノードは、保持している、特定モビリティ管理ノード接続要求情報に応じて、ハンドオーバ先のモビリティ管理ノードを選択する、モビリティ管理ノード装置。
  26. 　端末が利用するサービス特性又は端末種別に応じて選択される特定のモビリティ管理ノードに接続され、
    　モビリティ管理ノードを跨ぐハンドオーバが起動されると、前記特定モビリティ管理ノードは、保持している、特定モビリティ管理ノード接続要求情報に応じて、ハンドオーバ先のモビリティ管理ノードを選択する前記モビリティ管理ノードに接続される端末。
  27. 　前記モビリティ管理エンティティ再選択要求信号は、ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ　ｉｎｄｉｃａｔｉｏｎ（ＬＡＰＩ）、又はｄｅｌａｙ　ｔｏｌｅｒａｎｔ　ａｃｃｅｓｓを含む、請求項１０記載の通信システム。
  28. 　端末（ＵＥ）と、
    　基地局（ｅＮｏｄｅＢ）と、
    　前記端末が利用するサービス特性又は端末種別に応じて選択される特定ＭＭＥと、
    　を備え、
    　前記基地局（ｅＮｏｄｅＢ）が、ローアクセスプライオリティ（ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ）の端末（ＵＥ）に対して、前記特定ＭＭＥを選択する、通信システム。
  29. 　ローアクセスプライオリティ（ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ）構成の端末（ＵＥ）と、
    　基地局（ｅＮｏｄｅＢ）と、
    　前記端末が利用するサービス特性又は端末種別に応じて選択される特定ＭＭＥと、
    　を備え、
    　前記ローアクセスプライオリティ（ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ）構成の端末（ＵＥ）は、前記基地局（ｅＮｏｄｅＢ）にＲＲＣコネクション要求が前記ローアクセスプライオリティ（ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ）であることを指示する情報（ＬＡＰＩ）を提供し、
    　前記基地局（ｅＮｏｄｅＢ）は、前記端末からの情報（ＬＡＰＩ）を用いて、ローアクセスプライオリティ（ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ）構成の端末（ＵＥ）を、前記特定ＭＭＥに向ける、通信システム。
  30. 　前記ローアクセスプライオリティ（ｌｏｗ　ａｃｃｅｓｓ　ｐｒｉｏｒｉｔｙ）の端末（ＵＥ）はＭＴＣ機能を有する端末である、請求項２８又は２９記載の通信システム。
PCT/JP2014/067891 2013-07-04 2014-07-04 通信システムと方法と装置 Ceased WO2015002290A1 (ja)

Priority Applications (20)

Application Number Priority Date Filing Date Title
UAA201600857A UA116025C2 (uk) 2013-07-04 2014-04-07 Система, спосіб і пристрій зв'язку
BR122016004704-0A BR122016004704A2 (pt) 2013-07-04 2014-07-04 Sistema, método e aparelho de comunicação
KR1020167003159A KR101651807B1 (ko) 2013-07-04 2014-07-04 통신 시스템, 방법, 및 장치
MX2016001671A MX349184B (es) 2013-07-04 2014-07-04 Sistema de comunicación, método y aparato.
BR112015032906A BR112015032906A2 (pt) 2013-07-04 2014-07-04 sistema, método e aparelho de comunicação
MX2016000202A MX345250B (es) 2013-07-04 2014-07-04 Sistema de comunicación, método y aparato.
KR1020167026957A KR20160117641A (ko) 2013-07-04 2014-07-04 통신 시스템, 방법, 및 장치
KR1020187013659A KR20180053436A (ko) 2013-07-04 2014-07-04 통신 시스템, 방법, 및 장치
RU2016103470/07A RU2602088C1 (ru) 2013-07-04 2014-07-04 Система, способ и устройство связи
EP14820719.4A EP2996393A4 (en) 2013-07-04 2014-07-04 Communication system, method, and device
KR1020167009283A KR101663451B1 (ko) 2013-07-04 2014-07-04 통신 시스템, 방법, 및 장치
CN201480038357.7A CN105359581A (zh) 2013-07-04 2014-07-04 通信系统、方法和装置
JP2015525288A JP5862840B2 (ja) 2013-07-04 2014-07-04 通信システムと方法と装置
US14/902,656 US9883440B2 (en) 2013-07-04 2014-07-04 System, method, and apparatus for establishing a connection between a terminal and a network node
PH12016500012A PH12016500012B1 (en) 2013-07-04 2016-01-04 Communication system, method, and apparatus
US15/061,120 US20160192263A1 (en) 2013-07-04 2016-03-04 Communication system, method, and apparatus
PH12016500439A PH12016500439A1 (en) 2013-07-04 2016-03-08 Communication system, method, and device
PH12017500046A PH12017500046B1 (en) 2013-07-04 2017-01-06 Communication system, method, and device
US15/840,649 US20180146406A1 (en) 2013-07-04 2017-12-13 Communication system, method, and apparatus
PH12018502264A PH12018502264A1 (en) 2013-07-04 2018-10-25 Communication system, method, and device

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2013-141127 2013-07-04
JP2013141127 2013-07-04
JP2013187106 2013-09-10
JP2013-187106 2013-09-10

Related Child Applications (3)

Application Number Title Priority Date Filing Date
US14/902,656 A-371-Of-International US9883440B2 (en) 2013-07-04 2014-07-04 System, method, and apparatus for establishing a connection between a terminal and a network node
US15/061,120 Continuation US20160192263A1 (en) 2013-07-04 2016-03-04 Communication system, method, and apparatus
US15/840,649 Continuation US20180146406A1 (en) 2013-07-04 2017-12-13 Communication system, method, and apparatus

Publications (1)

Publication Number Publication Date
WO2015002290A1 true WO2015002290A1 (ja) 2015-01-08

Family

ID=52143859

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/067891 Ceased WO2015002290A1 (ja) 2013-07-04 2014-07-04 通信システムと方法と装置

Country Status (13)

Country Link
US (3) US9883440B2 (ja)
EP (2) EP2996393A4 (ja)
JP (4) JP5862840B2 (ja)
KR (4) KR101651807B1 (ja)
CN (2) CN105359581A (ja)
BR (2) BR122016004704A2 (ja)
CL (2) CL2015003718A1 (ja)
MX (2) MX349184B (ja)
MY (2) MY162436A (ja)
PH (4) PH12016500012B1 (ja)
RU (4) RU2602088C1 (ja)
UA (2) UA116025C2 (ja)
WO (1) WO2015002290A1 (ja)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016144106A (ja) * 2015-02-04 2016-08-08 日本電気株式会社 通信装置、通信システム、通信方法及びプログラム
WO2016125493A1 (ja) * 2015-02-04 2016-08-11 日本電気株式会社 通信システム
JP2017038323A (ja) * 2015-08-13 2017-02-16 株式会社Ｎｔｔドコモ 基地局、管理装置及び接続方法
JP2018506892A (ja) * 2015-01-13 2018-03-08 日本電気株式会社 Ｎａｓメッセージをリルートするための通信装置、コアネットワークノード、システム、コンピュータプログラム及び方法
CN107925862A (zh) * 2015-08-14 2018-04-17 日本电气株式会社 通信系统
WO2018142263A1 (en) * 2017-02-03 2018-08-09 Nokia Technologies Oy Method and system for selection of an access and mobility management function in an access network environment
CN108464036A (zh) * 2015-11-06 2018-08-28 交互数字专利控股公司 使用增强型专用核心网络（dnc）选择的方法、核心网络实体和无线发射/接收单元（wtru）
JP2020519076A (ja) * 2017-04-28 2020-06-25 オッポ広東移動通信有限公司Ｇｕａｎｇｄｏｎｇ Ｏｐｐｏ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．， Ｌｔｄ． 輻輳処理のための方法及び機器
JPWO2021241156A1 (ja) * 2020-05-26 2021-12-02
JP2022033964A (ja) * 2017-04-28 2022-03-02 オッポ広東移動通信有限公司 輻輳処理のための方法及び機器

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3198926A4 (en) * 2014-09-26 2017-10-25 Telefonaktiebolaget LM Ericsson (publ) Managing overload in at least one core network
US9807669B1 (en) * 2014-10-24 2017-10-31 Sprint Communications Company L.P. Identifying communication paths based on packet data network gateway status reports
JP2016122887A (ja) * 2014-12-24 2016-07-07 富士通株式会社 無線基地局、無線デバイス、無線通信システム、及び、無線通信制御方法
CN106332222A (zh) 2015-07-02 2017-01-11 北京三星通信技术研究有限公司 一种网络选择的方法和基站
EP3509337B1 (en) * 2015-08-14 2021-06-02 Telefonaktiebolaget LM Ericsson (publ) A node and method for managing a packet data network connection
EP3364695B1 (en) 2015-11-19 2022-03-30 SK Telecom Co., Ltd. Methods for selecting core network in mobile communication system
US9749773B2 (en) 2015-12-04 2017-08-29 At&T Intellectual Property I, L.P. Core network selection function in a radio access network for machine-to-machine (M2M) communications
KR102468945B1 (ko) * 2016-03-08 2022-11-21 삼성전자 주식회사 핸드오버를 지원하는 방법 및 장치
US10243860B2 (en) * 2016-04-05 2019-03-26 Nokia Technologies Oy Method and apparatus for end-to-end QoS/QoE management in 5G systems
US10567495B2 (en) 2016-11-16 2020-02-18 Cisco Technology, Inc. Application based intelligent edge computing in a low power wide area network environment
EP3557905A4 (en) * 2016-12-15 2020-08-12 LG Electronics Inc. -1- METHOD FOR PERFORMING A HANDOVER IN A WIRELESS COMMUNICATION SYSTEM AND DEVICE FOR IT
US10299184B1 (en) * 2017-03-28 2019-05-21 Sprint Communications Company L.P. Reselection of optimal network elements
US10021557B1 (en) 2017-08-18 2018-07-10 Verizon Patent And Licensing Inc. Universal GUTI for simplified device onboarding
US9998896B1 (en) 2017-08-18 2018-06-12 Verizon Patent And Licensing Inc. Dedicated APN access using default network access key for profile download
US10952052B2 (en) 2017-10-11 2021-03-16 Blackberry Limited Method and system for dynamic APN selection
JP7030533B2 (ja) 2018-01-15 2022-03-07 キオクシア株式会社 インプリント装置、インプリント方法、及び半導体装置の製造方法
US11310038B2 (en) * 2018-03-02 2022-04-19 Nitto Denko Corporation System and method for securing data communication between computers
JPWO2019193879A1 (ja) * 2018-04-05 2021-04-15 株式会社Ｎｔｔドコモ ユーザ装置、ネットワーク装置及び無線通信方法
US11076321B2 (en) * 2018-10-11 2021-07-27 Cisco Technology, Inc. Selecting 5G non-standalone architecture capable MME during registration and handover
US11290951B2 (en) 2019-02-12 2022-03-29 Cisco Technology, Inc. Providing optimal packet data network gateway selection for 5G network environments upon initial user equipment attachment via a WiFi evolved packet data gateway
CN111954269B (zh) * 2019-05-15 2022-11-01 华为技术有限公司 一种承载修改方法及接入网设备
JP6896793B2 (ja) * 2019-05-27 2021-06-30 本田技研工業株式会社 情報処理装置
WO2021014328A1 (en) * 2019-07-19 2021-01-28 Reliance Jio Infocomm Limited System and method for supporting standalone 5g radio with legacy network
KR20210125380A (ko) * 2020-04-08 2021-10-18 삼성전자주식회사 무선 통신 시스템에서 음성 핸드오버 지원 방법 및 장치
US20220286853A1 (en) * 2021-03-03 2022-09-08 At&T Intellectual Property I, L.P. Mobility management for aggressive devices

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003338832A (ja) 2002-05-22 2003-11-28 Nec Corp パケット転送経路の最適化方法及びパケット転送装置並びにプログラム
JP2012110051A (ja) * 2006-08-23 2012-06-07 Nec Corp 移動通信システム及びコアネットワークノード選択方法並びにそれに用いる基地局及び無線端末
WO2013047822A1 (ja) * 2011-09-30 2013-04-04 日本電気株式会社 通信システムと方法と装置
JP2013516857A (ja) * 2010-01-08 2013-05-13 アルカテル−ルーセント マシンタイプ通信におけるグループベースのモビリティ最適化の方法およびデバイス

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2000245676A1 (en) 2000-05-22 2001-12-03 Nokia Corporation System and method for providing a connection in a communication network
NO20014064D0 (no) * 2001-08-21 2001-08-21 Ericsson Telefon Ab L M Fremgangsmate for handtering av en mobil abonnent i et telekommunikasjonssystem
WO2006062338A1 (en) * 2004-12-09 2006-06-15 Samsung Electronics Co., Ltd. Method and system for relocating serving radio network controller in a network sharing system
AU2007222104A1 (en) * 2006-03-08 2007-09-13 Interdigital Technology Corporation Method and apparatus for supporting handoff and serving radio network subsystem relocation procedures in a single tunnel GPRS-based wireless communication system
US20070254667A1 (en) * 2006-04-28 2007-11-01 Joanna Jokinen Inter-MME handover in evolved communication systems
US20090023448A1 (en) 2007-02-21 2009-01-22 Qualcomm Incorporated Method and apparatus for inter-system handover
CN101309500B (zh) 2007-05-15 2011-07-20 华为技术有限公司 不同无线接入技术间切换时安全协商的方法和装置
KR101547544B1 (ko) * 2008-09-24 2015-08-27 삼성전자주식회사 펨토 기지국으로의 핸드 오버를 위한 통신 시스템 및 이를 위한 방법
EP2353337B1 (en) * 2008-11-17 2018-10-03 Cisco Technology, Inc. Dynamic load balancing in a communication network
CN101420724B (zh) * 2008-11-20 2011-02-02 华为技术有限公司 信息传输方法、移动管理设备和网络系统
US8964697B2 (en) 2009-07-03 2015-02-24 Panasonic Intellectual Property Management Co., Ltd. Connection management method, connection management system, mobile terminal, packet data gateway and mobile management gateway
KR20110020161A (ko) * 2009-08-21 2011-03-02 엘지전자 주식회사 이동통신 네트워크 내에서 제어 평면(Ｃｏｎｔｒｏｌ Ｐｌａｎｅ)을 담당하는 서버 및 ＳＩＰＴＯ 기반의 세션을 제어하는 방법
CN102056138B (zh) 2009-11-05 2016-08-03 中兴通讯股份有限公司 本地ip访问连接的管理方法及装置
KR101609580B1 (ko) * 2010-02-10 2016-04-07 삼성전자주식회사 무선 통신 시스템 및 그의 사용자 단말기와 이동성 관리 엔티티 간 연결 방법
CN102469543B (zh) * 2010-11-05 2015-09-16 中兴通讯股份有限公司 接纳控制方法、装置及系统
WO2012062193A1 (zh) * 2010-11-08 2012-05-18 中兴通讯股份有限公司 Mtc切换中的拥塞控制方法及装置、系统
WO2012137402A1 (ja) * 2011-04-04 2012-10-11 パナソニック株式会社 セル選択方法、セル選択システム、通信デバイス及び基地局
WO2012147291A1 (ja) 2011-04-28 2012-11-01 パナソニック株式会社 通信ノード及びネットワークノード
US8625534B2 (en) * 2011-05-20 2014-01-07 At&T Intellectual Property I, L.P. Throughput for inter-radio access technology handover
EP2723116B1 (en) 2011-06-14 2017-08-16 Nec Corporation Mobile communication system, control method for same and non-transitory computer-readable medium in which control program is stored
CN103733683A (zh) * 2011-08-11 2014-04-16 交互数字专利控股公司 移动中继切换
US9681480B2 (en) * 2011-08-19 2017-06-13 Interdigital Patent Holdings, Inc. Method and apparatus for using non-access stratum procedures in a mobile station to access resources of component carriers belonging to different radio access technologies
CN102984775B (zh) * 2011-09-06 2015-12-16 普天信息技术研究院有限公司 无线接入网络信息管理信息的获取方法
JP5922902B2 (ja) 2011-09-30 2016-05-24 日本信号株式会社 無線通信ネットワークシステムの同期方法
EP2608567A1 (en) * 2011-12-13 2013-06-26 Panasonic Corporation Device triggering and congestion control
CN104185973B (zh) 2012-01-20 2017-09-22 三星电子株式会社 用于设定数据发送的优先级的方法和设备
JP5229403B1 (ja) * 2012-01-26 2013-07-03 日本電気株式会社 移動局、移動局の制御方法、移動通信システム、移動管理装置、及びプログラム
KR101565102B1 (ko) 2012-04-04 2015-11-02 주식회사 케이티 이중 우선순위 어플리케이션을 갖는 기계 형태 통신 장치에 대한 접속 제어 방법 및 장치
EP2693800A1 (en) * 2012-08-03 2014-02-05 Panasonic Corporation Radio Resource Managment for Dual Priority Access
US9055520B2 (en) 2012-12-19 2015-06-09 Cisco Technology, Inc. Systems, methods and media for mobile management entity (MME) selection by Evolved Node B (eNodeB)
TW201442527A (zh) 2013-01-11 2014-11-01 Interdigital Patent Holdings 使用者平面壅塞管理
US20160029278A1 (en) * 2013-03-07 2016-01-28 Nokia Solutions And Networks Oy Handover of mobility management entity for load balancing

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003338832A (ja) 2002-05-22 2003-11-28 Nec Corp パケット転送経路の最適化方法及びパケット転送装置並びにプログラム
JP2012110051A (ja) * 2006-08-23 2012-06-07 Nec Corp 移動通信システム及びコアネットワークノード選択方法並びにそれに用いる基地局及び無線端末
JP2013516857A (ja) * 2010-01-08 2013-05-13 アルカテル−ルーセント マシンタイプ通信におけるグループベースのモビリティ最適化の方法およびデバイス
WO2013047822A1 (ja) * 2011-09-30 2013-04-04 日本電気株式会社 通信システムと方法と装置

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"SA2, LS on LAPI for NNSF", 3GPP TSG-SA WG2#97, S2-132325, 31 May 2013 (2013-05-31), pages 2 - 132325, XP050709463, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_97_Busan/Docs/S2-132325.zip> *
3GPP TS 23.401 V12.1.0, June 2013 (2013-06-01), pages 45 - 49, XP055250274 *
See also references of EP2996393A4

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10631356B2 (en) 2015-01-13 2020-04-21 Nec Corporation Communication apparatus, core network node, system, computer program and methods for rerouting NAS-messages
JP2018506892A (ja) * 2015-01-13 2018-03-08 日本電気株式会社 Ｎａｓメッセージをリルートするための通信装置、コアネットワークノード、システム、コンピュータプログラム及び方法
WO2016125493A1 (ja) * 2015-02-04 2016-08-11 日本電気株式会社 通信システム
JPWO2016125493A1 (ja) * 2015-02-04 2017-11-16 日本電気株式会社 通信システム
JP2016144106A (ja) * 2015-02-04 2016-08-08 日本電気株式会社 通信装置、通信システム、通信方法及びプログラム
JP2017038323A (ja) * 2015-08-13 2017-02-16 株式会社Ｎｔｔドコモ 基地局、管理装置及び接続方法
WO2017026531A1 (ja) * 2015-08-13 2017-02-16 株式会社Ｎｔｔドコモ 基地局、管理装置及び接続方法
CN107926079A (zh) * 2015-08-13 2018-04-17 株式会社Ntt都科摩 基站、管理装置以及连接方法
US10674564B2 (en) 2015-08-13 2020-06-02 Ntt Docomo, Inc. Base station, management apparatus and connection method
CN107925862A (zh) * 2015-08-14 2018-04-17 日本电气株式会社 通信系统
JP2022062250A (ja) * 2015-08-14 2022-04-19 日本電気株式会社 無線アクセスネットワークノード、ユーザ機器、及び、方法
JP2019146246A (ja) * 2015-08-14 2019-08-29 日本電気株式会社 通信システム
JP2018523431A (ja) * 2015-08-14 2018-08-16 日本電気株式会社 通信システム
JP2020162151A (ja) * 2015-08-14 2020-10-01 日本電気株式会社 通信システム
JP7031696B2 (ja) 2015-08-14 2022-03-08 日本電気株式会社 通信システム
US12335802B2 (en) 2015-11-06 2025-06-17 Interdigital Patent Holdings, Inc. Methods, apparatus, and systems using Enhanced Dedicated Core Network (DCN) selection
US11071031B2 (en) 2015-11-06 2021-07-20 Interdigital Patent Holdings, Inc. Methods, apparatus, and systems using enhanced dedicated core network (DCN) selection
US11689979B2 (en) 2015-11-06 2023-06-27 Interdigital Patent Holdings, Inc. Methods, apparatus, and systems using enhanced dedicated core network (DCN) selection
CN108464036A (zh) * 2015-11-06 2018-08-28 交互数字专利控股公司 使用增强型专用核心网络（dnc）选择的方法、核心网络实体和无线发射/接收单元（wtru）
US10555253B2 (en) 2017-02-03 2020-02-04 Nokia Technologies Oy Method and system for selection of an access and mobility management function in an access network environment
WO2018142263A1 (en) * 2017-02-03 2018-08-09 Nokia Technologies Oy Method and system for selection of an access and mobility management function in an access network environment
US11405824B2 (en) 2017-04-28 2022-08-02 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Congestion processing method and device
JP2022033964A (ja) * 2017-04-28 2022-03-02 オッポ広東移動通信有限公司 輻輳処理のための方法及び機器
JP7286741B2 (ja) 2017-04-28 2023-06-05 オッポ広東移動通信有限公司 輻輳処理のための方法及び機器
US11991559B2 (en) 2017-04-28 2024-05-21 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Congestion processing method and device
JP2020519076A (ja) * 2017-04-28 2020-06-25 オッポ広東移動通信有限公司Ｇｕａｎｇｄｏｎｇ Ｏｐｐｏ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．， Ｌｔｄ． 輻輳処理のための方法及び機器
JPWO2021241156A1 (ja) * 2020-05-26 2021-12-02
JP7478823B2 (ja) 2020-05-26 2024-05-07 株式会社Ｎｔｔドコモ 端末装置及び端末装置の制御方法

Also Published As

Publication number Publication date
KR20160117641A (ko) 2016-10-10
CL2015003718A1 (es) 2016-07-08
KR101651807B1 (ko) 2016-08-26
MY162436A (en) 2017-06-15
US9883440B2 (en) 2018-01-30
MY157550A (en) 2016-06-16
PH12016500012A1 (en) 2016-04-18
CN105359581A (zh) 2016-02-24
EP3029992A2 (en) 2016-06-08
JP2016029847A (ja) 2016-03-03
KR101663451B1 (ko) 2016-10-06
MX345250B (es) 2017-01-23
MX2016000202A (es) 2016-03-09
RU2600131C1 (ru) 2016-10-20
US20160192263A1 (en) 2016-06-30
PH12016500012B1 (en) 2016-04-18
EP2996393A1 (en) 2016-03-16
UA117761C2 (uk) 2018-09-25
BR112015032906A2 (pt) 2017-05-23
US20160174120A1 (en) 2016-06-16
JP2017050895A (ja) 2017-03-09
JP5862840B2 (ja) 2016-02-16
CN105611585B (zh) 2018-03-02
PH12016500439B1 (en) 2016-07-04
PH12017500046A1 (en) 2018-01-29
PH12016500439A1 (en) 2016-07-04
KR20180053436A (ko) 2018-05-21
PH12018502264A1 (en) 2019-05-15
US20180146406A1 (en) 2018-05-24
RU2669792C1 (ru) 2018-10-16
CL2016000582A1 (es) 2016-09-23
JP2016034164A (ja) 2016-03-10
JPWO2015002290A1 (ja) 2017-02-23
UA116025C2 (uk) 2018-01-25
KR20160022387A (ko) 2016-02-29
EP3029992A3 (en) 2016-07-20
EP2996393A4 (en) 2017-01-18
CN105611585A (zh) 2016-05-25
MX349184B (es) 2017-07-17
JP5862830B1 (ja) 2016-02-16
PH12017500046B1 (en) 2018-01-29
RU2642477C1 (ru) 2018-01-25
BR122016004704A2 (pt) 2018-05-02
KR20160043537A (ko) 2016-04-21
RU2602088C1 (ru) 2016-11-10

Similar Documents

Publication Publication Date Title
JP5862830B1 (ja) 通信システムと方法と装置
JP6308279B2 (ja) 通信システムと方法と装置

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201480038357.7

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2014820719

Country of ref document: EP

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

Ref document number: 14820719

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015525288

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 139450140003010163

Country of ref document: IR

WWE Wipo information: entry into national phase

Ref document number: 122016004704

Country of ref document: BR

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 14902656

Country of ref document: US

Ref document number: 12016500012

Country of ref document: PH

WWE Wipo information: entry into national phase

Ref document number: MX/A/2016/000202

Country of ref document: MX

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112015032906

Country of ref document: BR

WWE Wipo information: entry into national phase

Ref document number: IDP00201600680

Country of ref document: ID

ENP Entry into the national phase

Ref document number: 20167003159

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: A201600857

Country of ref document: UA

ENP Entry into the national phase

Ref document number: 2016103470

Country of ref document: RU

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: IDP00201602294

Country of ref document: ID

WWE Wipo information: entry into national phase

Ref document number: 12017500046

Country of ref document: PH

ENP Entry into the national phase

Ref document number: 112015032906

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20151229