+

WO2010092764A1 - Procédé de connexion à une passerelle, système de contrôle d'une connexion à une passerelle, et équipement utilisateur - Google Patents

Procédé de connexion à une passerelle, système de contrôle d'une connexion à une passerelle, et équipement utilisateur Download PDF

Info

Publication number
WO2010092764A1
WO2010092764A1 PCT/JP2010/000551 JP2010000551W WO2010092764A1 WO 2010092764 A1 WO2010092764 A1 WO 2010092764A1 JP 2010000551 W JP2010000551 W JP 2010000551W WO 2010092764 A1 WO2010092764 A1 WO 2010092764A1
Authority
WO
WIPO (PCT)
Prior art keywords
gateway
pgw
mobile terminal
connection
code
Prior art date
Application number
PCT/JP2010/000551
Other languages
English (en)
Japanese (ja)
Inventor
隆二 杉崎
新吉 池田
啓吾 阿相
ゲナディ ベレブ
イェンス バッハマン
Original Assignee
パナソニック株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニック株式会社 filed Critical パナソニック株式会社
Priority to US13/201,042 priority Critical patent/US20120020343A1/en
Priority to JP2010550437A priority patent/JPWO2010092764A1/ja
Publication of WO2010092764A1 publication Critical patent/WO2010092764A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/17—Selecting a data network PoA [Point of Attachment]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/005—Multiple registrations, e.g. multihoming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Definitions

  • the present invention relates to a gateway connection method, a gateway connection control system, and a mobile terminal for controlling a connection destination when a communication node performing communication using IP (Internet Protocol: Internet Protocol) connects to a PGW (PDN Gateway).
  • IP Internet Protocol
  • PGW Packet Gateway
  • UE User Equipment
  • MIPv6 Mobile IPv6
  • IF IF
  • FIG. 1 shows an example of the configuration of a communication network using MIPv6.
  • PGW 5 home agent in MIPv6 terms: Home agent: in MIPv6
  • UE1 also called Mobile Node in MIPv6: Mobile Node (MN)
  • UE1's location information care-of address; also called Care-of Address (CoA)
  • HA Home Agent
  • I-PGW 5a or T-PGW 5b I-PGW 5a or T-PGW 5b (described later)
  • AAA Authentication, Authorization and Authorization
  • UE authentication server that determines whether to permit each access network to be used by UE1.
  • DNS Domain Name System: Domain Name System
  • URI Universal Resource Identifier
  • the AAA server 8a and the HSS 8b may be physically or logically mounted on the same device, and hereinafter, the AAA server 8a and the HSS 8b may be collectively referred to as AAA / HSS 8 for convenience of explanation. is there. Further, although the connection mode of the DNS server 9 is not explicitly shown in FIG. 1, the DNS server 9 can be accessed from the core network 4 and each access network (3GPP access network 2 or Non-3GPP access network 3 described later). It is.
  • UE 1 performs binding update (BU) and a home address (Home Address: hereinafter referred to as HoA) valid on the home link, and CoA acquired in the movement destination network which is the external link. Notify the PGW 5 using a call) message.
  • the PGW 5 intercepts the packet sent to the HoA of the UE 1 by registering and holding the correspondence between the notified two addresses (HoA, CoA) in the binding cache (Binding Cash: hereinafter referred to as BC). And transfer to the corresponding UE1's CoA.
  • the UE 1 notifies the PGW 5 of the CoA using the BU message periodically or when the CoA is changed.
  • UE1 can always receive packets addressed to the HoA of UE1 regardless of whether the home link is in or out.
  • Non-Patent Document 1 discloses a method of allocating PGW 5 in a standardization project (3rd Generation Partnership Project: hereinafter referred to as 3GPP) of a mobile communication system.
  • 3GPP 3rd Generation Partnership Project
  • UE 1 when connecting to a new access network, uses UE1's in the new access network based on the URI indicating PGW 5 accommodating itself.
  • the IP address of PGW 5 that manages location information is acquired from DNS server 9.
  • PGW 5 PGW 5 holding the binding cache entry of UE 1
  • PGW 5 PGW 5 holding the binding cache entry of UE 1
  • the PGW 5 different from the PGW 5 to which the UE 1 is connected may be presented by the DNS server 9.
  • Non-Patent Document 1 discloses a PGW 5 switching method (PDN GW reallocation procedure).
  • PDN GW reallocation procedure disclosed in Non-Patent Document 1, UE 1 once initiates connection to a different PGW 5 presented by DNS server 9, but based on the information provided by AAA / HSS 8 during the connection process.
  • the UE 1 can reconnect to the notified PGW 5 (the already connected PGW 5).
  • I-PGW Intelligent PGW
  • T-PGW target PGW
  • the T-PGW 5 b is a PGW 5 to which the UE 1 originally wants to connect when the UE 1 connects to a new access network. Even when the UE 1 is connected to a new access network, by setting the connection destination to the T-PGW 5 b, it is possible to receive the benefit of using multiple CoAs for communication.
  • the AAA / HSS 8 allocates the T-PGW 5 a, so that the UE 1 can connect to It becomes possible to unify PGW5 irrespective of the access network of
  • Non-Patent Document 1 The PDN GW reallocation procedure disclosed in Non-Patent Document 1 is bootstrapping for establishing a Security Association (hereinafter referred to as SA) for protecting packet communication between UE 1 and PGW 5 ( Bootstrapping: hereinafter referred to as BS) procedure.
  • SA Security Association
  • BS Bootstrapping: hereinafter referred to as BS
  • FIG. 12 is a sequence diagram for illustrating a BS procedure in the prior art.
  • FIG. 12 shows an example of the illustrated BS procedure in the system configuration shown in FIG.
  • UE 1 implements PGW 5 and BS presented from DNS server 9.
  • identification information hereinafter referred to as PGW Identity
  • PGW Identity identification information of the AAA server 8a that permits connection to the core network 4 and the PGW 5 in which the UE 1 is accommodated if there is an access point name (Access Point Name: Interaction with the HSS 8 b that manages the APN, etc.).
  • the UE 1 executes PGW discovery procedure, and acquires the address of PGW 5 (corresponding to I-PGW 5 a in FIG. 1) (step S 9001).
  • the APN of the PDN Packet Domain Network, not shown in FIG. 12
  • the DNS server 9 the address of the PGW 5 (T-PGW 5 b).
  • the UE 1 stores the held APN of the T-PGW 5 b in the inquiry message, and transmits the inquiry message to the DNS server 9.
  • the DNS server 9 searches the PGW 5 based on the APN sent from the UE 1 and notifies the UE 1 of the state of the network (load state, operator setting, and dynamic based on the current state of the UE 1 as well as the DNS database). Due to various reasons such as not holding information, the address of a different PGW 5 (I-PGW 5 a) may be returned to UE 1 instead of the address of T-PGW 5 b desired by UE 1.
  • the UE 1 starts SA establishment for the address of the PGW 5 (here, corresponding to the I-PGW 5 a) received from the DNS server 9 (start of IKE_SA_INIT sequence, step S 9002).
  • An IKE SA IKE Security Association
  • the UE 1 transmits an IKE_AUTH Request message protected using the generated IKE SA to the PGW 5 (step S 9003).
  • the IKE_AUTH Request message includes the identifier of the UE 1 (eg, NAI: Network Access Identifier).
  • the PGW 5 generates an authentication request message (Authentication-Request / Identity) for the UE 1 based on the parameters described in the acquired IKE_AUTH Request message, and transmits it to the AAA server 8a (step S9004).
  • the AAA server 8a authenticates the UE 1 based on the user profile (User Profile) and authentication vector (Authentication Vector: AV) acquired from the HSS 8b (step S9005), and permits connection to the core network 4 via the PGW 5 It is determined whether the UE 1 may be present, and the result is notified to the PGW 5 using an EAP-Request / AKA-Challenge message (step S9006). If it is determined that the UE 1 can connect to the network, the EAP-Request / AKA-Challenge message transmitted in step S9006 includes challenge information necessary for establishing an SA used between the PGW 5 and the UE 1 thereafter. ing.
  • the PGW 5 transmits an IKE_AUTH Response message including the EAP-Request / AKA-Challenge message acquired from the AAA server 8a to the UE 1 (step S9007). Subsequently, response information corresponding to the challenge information is transmitted from the UE 1 to the AAA server 8a (steps S9008 and S9009), and a master key (sometimes called MSK, key or key information) necessary for SA establishment, or The keying material (keying material) is distributed to the PGW 5 (steps S9010, S9011). An SA between the UE 1 and the PGW 5 is established using this MSK (steps S9012 to 14). Then, BU / BA (Binding Acknowledgment) exchanged between the UE 1 and the PGW 5 is protected using the established SA (steps S9015 to S17).
  • the PGW 5 (corresponding to the T-PGW 5b) that is different in HSS 8b from the PGW 5 (corresponding to the I-PGW 5a) that started the BS in step S9006 is PGW 5 via the AAA server 8a.
  • I-PGW 5a can be notified.
  • the PGW 5 (T-PGW 5 b) completes the BS processing with the subsequent UE 1 (to step S 9014), and subsequently in the binding processing performed with the UE 1 (specifically, it is transmitted in step S 9016)
  • the UE 1 is notified of the address of the PGW 5 (corresponding to the T-PGW 5 b) notified from the HSS 8 b) (step S9016).
  • the UE 1 upon receiving the address of the PGW 5 (T-PGW 5 b) which the user wants to connect originally, transmits a BU whose lifetime is set to 0 in order to cancel the binding with the PGW 5 (I-PGW 5 a) (step S9017) , BS process for connecting to the notified PGW 5 (T-PGW 5 b) and binding process (BU / BA exchange) are started again. Specifically, the UE 1 performs the process from step S 9002 in FIG. 12 again on the T-PGW 5 b.
  • PGW 5 in the case of a newly connected or handover-destination access network, PGW 5 (I-PGW 5 a) different from PGW 5 (T-PGW 5 b) already connected and originally desired to be connected is allocated.
  • a gateway connection method, a gateway connection control system, and a mobile terminal which enable UE to perform connection switching to a desired PGW 5 in a short time while suppressing resource consumption in the system Do.
  • a mobile terminal connectable to a plurality of access networks via a plurality of communication interfaces, and a plurality of gateways accommodating the mobile terminal and performing mobility management
  • a gateway connection method for connecting the mobile terminal to a desired gateway Detecting that the mobile terminal is already connected to the first gateway via a home link and acquires an address of the second gateway from the DNS server when connecting to a different access network;
  • the mobile terminal upon receiving the result of the detection step, inquiring of the second gateway about the accommodation status of the mobile terminal;
  • the second gateway confirming the accommodation status of the mobile terminal; Sending a connection indication to the first gateway if the second gateway determines that the mobile terminal is not accommodated;
  • the second gateway transmitting a standby instruction to the mobile terminal; Starting the connection process to the mobile terminal by the first gateway; Have.
  • the mobile terminal is accommodated in the PGW at the beginning of the connection.
  • the gateway connection control system of the present invention includes a plurality of mobile terminals connectable to a plurality of access networks via a plurality of communication interfaces, and a plurality of mobility managements accommodating the mobile terminals.
  • Gateway connection control system consisting of The mobile terminal is connected to the first gateway via the home link, and detects that it has acquired the address of the second gateway from the DNS server when connecting to a different access network, In response to the result of the detection step, the mobile terminal inquires the second gateway about the accommodation status of the mobile terminal.
  • the second gateway confirms the accommodation status of the mobile terminal, When the second gateway determines that the mobile terminal is not accommodated, the second gateway transmits a connection instruction to the first gateway, The second gateway transmits a standby instruction to the mobile terminal; When the first gateway starts connection processing to the mobile terminal, The mobile terminal is configured to connect to a desired gateway. Thereby, in the access network of the new connection or the handover destination, even when PGW 5 different from the PGW that is already connected and originally desired to be connected is allocated to the mobile terminal, the mobile terminal is accommodated in the PGW at the initial connection. By confirming the situation, it is possible to early determine whether or not the mobile terminal is the PGW that really wants to be connected, and it is not necessary to clear the state of the AAA server, and establish the connection with the desired PGW in a short time. Will be able to
  • the mobile terminal of the present invention is a mobile terminal connectable to a plurality of access networks via a plurality of communication interfaces, and a plurality of mobile terminals are accommodated to perform mobility management.
  • a mobile terminal capable of connecting to a desired one of the plurality of gateways when connecting to a communication system including a gateway, A means for detecting that the second gateway address has been obtained from the DNS server when connected to the first gateway via the home link and connected to a different access network; A means for inquiring the second gateway detected the accommodation status of the mobile terminal; A means for receiving a standby instruction from the second gateway when the second gateway confirms the accommodation status of the mobile terminal and determines that the second gateway does not accommodate the mobile terminal; , Connection from the second gateway to the first gateway when the accommodation condition of the mobile terminal is confirmed by the second gateway and it is determined that the second gateway does not accommodate the mobile terminal Means for transmitting an instruction, and for performing connection processing with the mobile terminal initiated by the first gateway based on the connection instruction; Have.
  • a mobile terminal connectable to a plurality of access networks via a plurality of communication interfaces, and a plurality of mobility managements accommodating the mobile terminal.
  • a gateway connection method for connecting the mobile terminal to a desired gateway in a communication system comprising a gateway, the method comprising: Detecting that the mobile terminal is already connected to the first gateway via a home link and acquires an address of the second gateway from the DNS server when connecting to a different access network; The mobile terminal receives the result of the detection step, starts connection processing to the second gateway, performs mutual authentication with the authentication server, and generates key information generated with the second gateway.
  • the second gateway After the completion of the exchange of the key information, the second gateway notifies the mobile terminal of the address of the first gateway; The mobile terminal initiating connection processing to the first gateway; Obtaining from the authentication server the key information generated by the mutual authentication by the first gateway; Connecting the mobile terminal to the first gateway by reusing the key information generated by the mutual authentication. Have.
  • the PGW different from the desired PGW is By reusing key information created upon connection to the desired PGW, the mobile terminal can establish connection with the desired PGW in a short time.
  • a gateway connection control system comprising: a mobile terminal connectable to a plurality of access networks via a plurality of communication interfaces; and a plurality of gateways accommodating the mobile terminals and performing mobility management.
  • the mobile terminal is connected to the first gateway via the home link, and detects that it has acquired the address of the second gateway from the DNS server when connecting to a different access network, The mobile terminal receives the result of the detection step, starts connection processing to the second gateway, performs mutual authentication with the authentication server, and generates key information generated with the second gateway.
  • the second gateway notifies the mobile terminal of the address of the first gateway,
  • the mobile terminal starts connection processing to the first gateway,
  • the first gateway acquires the key information generated by the mutual authentication from the authentication server;
  • the mobile terminal is configured to reuse the key information generated by the mutual authentication and to connect to the first gateway.
  • the mobile terminal of the present invention is a mobile terminal connectable to a plurality of access networks via a plurality of communication interfaces, and a plurality of mobile terminals are accommodated to perform mobility management
  • a mobile terminal capable of connecting to a desired one of the plurality of gateways when connecting to a communication system including a gateway,
  • the PGW different from the desired PGW is By reusing key information created upon connection to the desired PGW, the mobile terminal can establish connection with the desired PGW in a short time.
  • the present invention it is possible to unify and quickly unify PGWs that manage CoAs of mobile terminals using multiple CoAs, and as a result, the mobile terminal benefits from communication using multiple CoAs. You will be able to enjoy it reliably and quickly. Further, according to the present invention, in the access network of the new connection or the handover destination, even when a PGW different from the PGW already connected and originally desired to be connected is assigned to the mobile terminal, the PGW is initially connected. By confirming the accommodation status of the mobile terminal in, it is possible to early determine whether or not the mobile terminal is a PGW that really wants to be connected, and it is unnecessary to clear the state of the AAA server, and the desired PGW and short time Connection can be established.
  • the desired PGW in the access network of a new connection or handover destination, even when a PGW different from a PGW already connected and originally desired to be connected is assigned to a mobile terminal, the desired PGW and Enables the mobile terminal to establish a connection with the desired PGW in a short time by reusing the key information created in the connection with the different PGW in the connection to the desired PGW become.
  • a diagram showing an example of the configuration of a communication system common to the first to fourth embodiments of the present invention and the prior art. Sequence chart for explaining an example of the operation of the gateway connection method in the first embodiment of the present invention The figure which shows an example of a structure of the mobile terminal (UE) in the 1st-4th embodiment of this invention. Flowchart showing an example of the processing flow of the mobile terminal (UE) in the first embodiment of the present invention In the first embodiment of the present invention, a diagram showing a format example of an IKE_AUTH Request message transmitted by the mobile terminal (UE) to the PGW (I-PGW).
  • Flow chart showing an example of processing flow of PGW in the first embodiment of the present invention The figure which shows an example of a structure of the AAA server in the 1st-4th embodiment of this invention.
  • FIG. 1 is a diagram showing an example of a system configuration common to the first to fourth embodiments of the present invention.
  • the communication system illustrated in FIG. 1 includes at least the UE1, the core network 4 to which the UE1 is connected, and the T-PGW 5b that manages the UE1's home prefix, home address, location information (CoA), and the like.
  • the AAA server 8a performing access authentication to the core network 4 of UE1, the identifier (identity) of the T-PGW 5a to which the UE1 is connected, the HSS 8b managing and storing the APN, and the PGW 5 address in response to a request from the UE1. It has a DNS server 9 to be provided, a 3GPP access network 2 (hereinafter also referred to as 3G access 2), and a non-3GPP (non-3GPP) access network 3 (hereinafter also referred to as N3G access 3).
  • 3G access 2 hereinafter also referred to as 3G access 2
  • N3G access 3 non-3GPP (non-3GPP) access network 3
  • UE 1 has at least two or more communication interfaces, one of which can be connected to 3G access 2 and the other to N3G access 3.
  • the plurality of communication interfaces may be simultaneously connected to 3G access 2 or connected to N3G access 3.
  • the UE 1 can connect to the core network 4 via each access network (3G access 2, N3G access 3), and attach to either the I-PGW 5a or the T-PGW 5b.
  • the UE 1 can also connect to the DNS server 9 via at least the N3G access 3.
  • DNS server 9 different from DNS server 9 connectable via N3G access 3 may be deployed in 3G access 2
  • 3G The DNS query via Access 2 and the DNS query via N3G Access 3 do not always give the same result.
  • 3G access 2 for example, a device specific to a 3GPP system such as Serving GW, MME, SGSN, GGSN, etc. is deployed, and a function for UE1 to connect to PGW 5 is supported.
  • a device specific to a 3GPP system such as Serving GW, MME, SGSN, GGSN, etc.
  • MME Mobility Management Entity
  • SGSN Serving GW
  • GGSN Serving GPP
  • GGSN GGSN
  • illustration is omitted in FIG.
  • N3G access 3G access 3 communication nodes (such as access router and MAG for distributing CoA to UE1) that support the function required for UE1 to connect to PGW 5 are deployed, but these communication nodes are also The illustration is omitted in FIG.
  • the UE 1 has established connection with the T-PGW 5 b via the 3G access 2 and the core network 4.
  • the connection via 3G access 2 for example, PMIP (see Non-Patent Document 5 above) is used, so UE1 can not know the address of T-PGW 5b (see Non-Patent Document 1).
  • the address of the T-PGW 5b is database-managed together with the identifier of the UE 1 for the purpose of proper connection management of the UE 1 and state management of the network.
  • FIG. 2 is a sequence diagram for explaining an example of the system operation in the first embodiment of the present invention.
  • An example of a processing sequence by the AAA server 8a which carries out the authentication processing, and the HSS 8b which holds and manages subscription information of the UE 1 and the like is shown.
  • the UE 1 attaches to the N3G access 3 for a new connection or handover, and decides to connect via the core network 4 with the PGW 5 by MIPv6 (or DSMIP).
  • MIPv6 or DSMIP
  • UE 1 uses a standard method (for example, the non-patent mentioned above) from APN which is an identifier of connection destination network PDN, HA-APN for identifying PGW 5, etc.
  • the home agent name (FQDN: Fully Qualified Domain Name) is constructed according to the method described in the document 6 or the like, and the DNS server 9 is inquired.
  • the DNS server 9 sends back an appropriate PGW address to the UE 1 (step S3001: PDN GW search).
  • the UE 1 starts BS processing to the acquired PGW address.
  • the IKE_SA_INIT procedure is performed on the PGW address acquired in step S3001 (step S3002: IKE_SA_INIT).
  • step S3001 UE1 acquires an address of I-PGW 5a different from already connected T-PGW 5b, and BS processing is also started between UE1 and I-PGW 5a.
  • the UE 1 wants to connect to the already connected T-PGW 5 b, but can not confirm whether the PGW address presented by the DNS server 9 is that of the T-PGW 5 b. This is because the connection via 3G access uses, for example, PMIP, and UE 1 can not know the address of T-PGW 5 b. The UE 1 also knows that the desired PGW address may sometimes not be obtained in PGW address acquisition by DNS. Furthermore, since it is clear that there is no other means for acquiring the PGW address (the address of T-PGW 5b) in N3G access 3, at the start of IKE authentication processing to be performed following IKE_SA_INIT in step S3002. Then, request for confirmation whether the PGW 5 (here, I-PGW 5a) initiating BS processing is the desired PGW 5 (ie, T-PGW 5b).
  • the UE 1 adds a home prefix (assigned at the time of connection via 3G access 2) held by the UE 1 to the IKE_AUTH Request message transmitted after the IKE_SA_INIT procedure in step S3002 is completed and transmitted.
  • Step S3003 IKE_AUTH Request.
  • the I-PGW 5a extracts the home prefix from the message, and checks whether it is a home prefix already registered in the binding cache in its own node (accommodation status) (step S3004: Containment status confirmation).
  • FIG. 5A is a diagram showing a format example of an IKE_AUTH Request message transmitted by the UE 1 to the I-PGW 5a in step S3003 of FIG.
  • the UE 1 can notify the home prefix by providing a Home Prefix field 502 in addition to the conventional standard IKE_AUTH Request message 501, and inserting the home prefix held by the UE 1 therein.
  • the home prefix may be notified to the I-PGW 5a by describing the home prefix in Configuration Payload in which the MIP6_HOME_PREFIX attribute is set in the standard IKE_AUTH Request message.
  • adding the home prefix to the IKE_AUTH Request message implies a request for confirmation of the accommodation status, but also adds the home prefix to the IKE_AUTH Request message and the accommodation status confirmation flag (not shown in FIG. 5A).
  • the I-PGW 5a may be explicitly requested to confirm the accommodation status.
  • the I-PGW 5a can perform processing for confirming the accommodation status of the UE 1 in the binding cache managed by the own node, and can notify the UE 1 of a more reliable result.
  • the PGW5 that accommodates the UE1 is an individual one (T-PGW5a and I-PGW5b) by adding the accommodation status check flag, but the home prefix distributed to the UE1 in each PGW5 is the same operation. Connection can be integrated to the same PGW 5 (T-PGW 5 b) also below.
  • step S3001 it is assumed that UE1 acquires the address of I-PGW 5a different from T-PGW 5b already connected, but UE1 acquires the address of T-PGW 5 already connected.
  • the case is also conceivable.
  • PGW5 to which UE1 is connected is I-PGW5a (that is, I-PGW5a and T-PGW5b are identical).
  • I-PGW5a that is, I-PGW5a and T-PGW5b are identical.
  • I-PGW5a is a response message to the IKE_AUTH Request message (eg, IKE_AUTH, since I-PGW 5a is not T-PGW 5b that UE1 wants to connect to.
  • a response message etc. including an accommodation status result (decision result), an identifier UE_BS_Identity for identifying the implementation of this BS, and an operation instruction are transmitted to the UE 1 (step S3005: IKE_AUTH_Response).
  • the accommodation status of whether or not the home prefix of UE1 exists in the binding cache of the own node is described.
  • UE_BS_Identity is information for correctly receiving BS processing from the T-PGW 5b described later, and is, for example, a numerical value designated by the I-PGW 5a, and its application will be described later.
  • -Transfer of PGW_BS_Identity is not required, and there is also a method for effectively using communication resources. Since the BS processing from the T-PGW 5b described later is performed in the operation instruction, an indicator for not performing reconnection or processing completion is stored even if this BS ends unsuccessfully.
  • the I-PGW 5a also supports GTP (GPRS Tunneling Protocol) based on the 3GPP standard
  • GTP GPRS Tunneling Protocol
  • PMIP or GTP is used for the connection via the 3G access of the UE 1 and the T-PGW 5 b.
  • MIP or DSMIP is used for the connection via the N3G access this time, bootstrapping processing is started toward the I-PGW 5a.
  • a database for example, PMIP binding cache
  • PMIP binding cache for performing position management of UE1 used in PMIP or GTP
  • the I-PGW 5a checks not only the management database (MIP binding cache) used in DSMIP / MIP when checking whether the home prefix sent by UE1 is registered in the binding cache.
  • PMIP binding cache managed by I-PGW 5a or managed by another node managed by I-PGW 5a, further managed by another node arranged in the same domain as I-PGW 5a, or for GTP It is also desirable to check the location management database.
  • FIG. 5B is a diagram showing a format example of an IKE_AUTH Response message as an example of a response message transmitted by the I-PGW 5a to the UE 1 in step S3005 of FIG.
  • the I-PGW 5a can provide a determination result field 602, an operation indication field 603, and a UE_BS_Identity field 604, and can notify UE1 of predetermined values.
  • Notify Payload defined in the standard IKEv2 protocol may be added to a standard IKE_AUTH Response message, the determination result may be described, and the result may be notified to UE1.
  • the response message may be any message other than the IKE_AUTH Response message as long as it can transfer predetermined information.
  • the home prefix sent by the above UE1 is a binding cache, provided that the I-PGW 5a assigns a home prefix different from that requested by the UE1 according to the standard home prefix assignment mechanism. The same operation may be performed as when not registered.
  • the UE 1 having received this response message confirms that the I-PGW 5 a is not likely to be the desired PGW 5 of the UE 1 with reference to the determination result field, and continues with the desired T-PGW 5 b with reference to the operation indication field. Confirm that the BS process is started from and save the value (UE_BS_Identity) described in the UE_BS_Identity field.
  • UE_BS_Identity the value described in the UE_BS_Identity field.
  • the UE 1 may transition to the sleep mode to reduce power consumption. Also, when it is confirmed from the determination result that the UE 1 is not connected to the PGW 5 desired, the UE 1 may determine that the BS processing from the desired T-PGW 5 b is started subsequently, which causes the operation to be performed.
  • the instruction field can be omitted to effectively utilize the communication band.
  • the I-PGW 5a transmits a Home Prefix confirmation request message to the AAA server 8a (Step S3006: Home Prefix confirmation request).
  • the Home Prefix confirmation request message contains at least information such as the User ID (NAI etc.) of UE1, the home prefix (Home Prefix), UE_BS_Identity identical to the one notified to UE1, UE address (CoA), transfer instruction, etc. .
  • the transfer instruction causes the AAA server 8a to cause the T-PGW 5b to perform the BS processing for the UE1 when the PGW 5 (T-PGW 5b) that manages and holds the home prefix of the UE 1 is found in response to this message. This is effective, in particular, in the case where a conventional Authentication-Request / Identity message or the like is extended and used as a Home Prefix confirmation request message.
  • the I-PGW 5a transmits a Home Prefix confirmation request message to the AAA server 8a to transmit a BS instruction to the T-PGW 5b, and also the Home Prefix confirmation request message for all devices including the T-PGW 5b. May be broadcast. Similarly, if the I-PGW 5a knows the address of the T-PGW 5b, or if there are some indications for the address of the T-PGW 5b, unicast or multicast a Home Prefix confirmation request message. It is also good.
  • the I-PGW 5a may transmit an IKE_AUTH Response message (sent in step S3005 of FIG. 2) and a Home Prefix confirmation request message (sent in step S3006 of FIG. 2) according to the present invention in any order. That is, in the above description, the IKE_AUTH Response is sent first and the Home Prefix confirmation request message is sent later, but the opposite may be possible. For example, the transmission order may be determined in view of network delay. For example, the Home Prefix confirmation request may be sent first in view of the high processing load by the network side device, or the BS processing from the T-PGW 5b is not transmitted to the UE 1 prior to the IKE_AUTH Response. Thus, IKE_AUTH Response may be sent first to ensure that the state transition of UE 1 operates properly.
  • FIG. 6A is a diagram showing an example of a Home Prefix confirmation request message transmitted by the I-PGW 5a to the AAA server 8a in step S3006 of FIG.
  • the I-PGW 5a sets the destination address field 1001 to the address of the AAA server 8a, the source address field 1002 to its own address, the transfer instruction field 1003 to transfer the value (for example, “1” or TRUE), and the Home Prefix field 1004 to UE1.
  • Home prefix value the same UE_BS_Identity value as notified to UE 1 in the UE_BS_Identity field 1005, the address (CoA) of UE 1 in the UE address field 1006, and transmits it to the AAA server 8a.
  • the Home Prefix confirmation request message may include the User ID of UE1, which makes it possible to more reliably search for the T-PGW 5b to which UE1 is connected, and switches UE1 according to the present invention It becomes possible to control whether or not to carry out the process with the authentication of the UE 1 and the operator can think of it as a new chargeable service.
  • the AAA server 8a that has received the Home Prefix confirmation request message detects the T-PGW 5b accommodating the UE 1 based on the identifiers such as User ID and Home Prefix, and requests the Home Prefix confirmation to the detected T-PGW 5b.
  • a reply message is sent (step S3007: Home Prefix confirmation request response).
  • the Home Prefix confirmation request reply message at least the User ID, the UE address, the UE_BS_Identity, and the BS indicator are described.
  • the UE address the same address of UE1 as described in the Home Prefix confirmation request message is described.
  • the BS indicator a value for instructing the T-PGW 5b to start the BS process for the address of the UE 1 described in the UE address is described (for example, “1”, TRUE, etc.).
  • FIG. 6B is a view showing an example of a Home Prefix confirmation request reply message transmitted by the AAA server 8a to the T-PGW 5b in step S3007 of FIG.
  • the AAA server 8a sets the destination address field 1101 the address of the T-PGW 5b, the source address field 1102 its own address, the BS instruction field 1103 a value instructing start of BS processing (for example, “1” or TRUE), the UE address field 1104
  • the address of UE1 (the value acquired in the Home Prefix confirmation request message is copied), and the value acquired in the Home Prefix confirmation request message is described in the UE_BS_Identity field 1105 and transmitted to the T-PGW 5b.
  • the Home Prefix confirmation request message may include the User ID of the UE 1, whereby the T-PGW 5 b can more reliably identify the UE 1.
  • the UE address may be the address acquired by the UE 1 through the 3G access 2, that is, the home address or home prefix. This may be described by the UE 1, or when the AAA server 8a or the HSS 8b describes when receiving a Home Prefix confirmation request message or when transmitting a Home Prefix confirmation request reply message. It is also good.
  • the T-PGW 5b may start BS processing in unicast, multicast, or anycast to a predetermined address of the home prefix, The entire home prefix may be broadcast to initiate BS processing.
  • the I-PGW 5a may transmit a Home Prefix confirmation request message to the HSS 8b.
  • the AAA server 8a it is not necessary for the AAA server 8a to acquire the state of the UE 1 from the HSS 8b, and processing time can be reduced.
  • the operation performed by the AAA server 8a in the above description is performed in the HSS 8b, and the Home Prefix confirmation request reply message is also transmitted from the HSS 8b to the T-PGW 5b directly or through an indirect node. Will be transferred.
  • the I-PGW 5a may transmit a Home Prefix confirmation request message to the range in which the I-PGW 5a can transmit, or broadcast transmission, multicast transmission, unicast transmission, anycast to the PGW 5 in a predetermined range. Any of transmission (in particular, transmission to a home agent anycast address constructed based on the UE 1 home prefix) may be performed. As a result, message transfer via the AAA server 8a or HSS 8b can be reduced, and the load on the AAA server 8a or HSS 8b can be reduced. In particular, when performing unicast communication, the number of processed messages in the entire system is reduced. be able to.
  • the I-PGW 5a When the I-PGW 5a directly transmits an instruction to the T-PGW 5b, the I-PGW 5a acquires the address of the T-PGW 5b from the AAA server 8a in advance. At this time, the authentication process for the UE 1 may be performed in the AAA server 8 a because the T-PGW 5 b is obtained for the UE 1. Also, the message for direct instruction may be a Home Prefix confirmation request message or a Home Prefix confirmation request reply message.
  • the I-PGW 5a transmits the Home Prefix confirmation request message (in some cases, a Home Prefix confirmation request reply message) to the AAA server 8a or HSS 8b, or directly to the T-PGW 5b.
  • the Home Prefix confirmation request message in some cases, a Home Prefix confirmation request reply message
  • the PGW resource can be effectively used.
  • the I-PGW 5a can not release the status for the I-PGW 5a and the UE 1 unless the step S9017 of FIG. 12 is completed (more precisely, after the step S9017) It is necessary to terminate and release the SA established between UE1 and I-PGW 5a).
  • the T-PGW 5b Upon receiving the Home Prefix confirmation request reply message, the T-PGW 5b confirms from the User ID etc. that it is the UE 1 accommodated by itself, and further that the BS indicator is an instruction to start the BS process addressed to the UE 1 After confirmation, a first IKE_SA_INIT message is sent to the UE address to start BS processing (step S3008: IKE_SA_INIT_1).
  • the first IKE_SA_INIT message includes at least an identifier T-PGW_BS_Identity generated by the T-PGW 5 b for identifying the implementation of the present BS.
  • FIG. 7A is a diagram showing an example of a first IKE_SA_INIT message transmitted by the T-PGW 5b to the UE 1 in step S3008 of FIG.
  • the T-PGW 5b sets up a BS identifier field for T-PGW (T-PGW_BS_Identity field) 2002 after the conventional standard IKE_SA_INIT message 2001 (the IKE_SA_INIT message sent by the Initiator to the Responder first), in which T -At least the BS identifier T-PGW_BS_Identity for T-PGW for identifying the implementation of the present BS acquired by the PGW 5b is described and transmitted.
  • the UE 1 that has received the first IKE_SA_INIT message from the T-PGW 5b confirms the value of the T-PGW_BS_Identity field of the message, and the UE_BS_Identity value previously acquired from the I-PGW 5a (included in the IKE_AUTH_Response received in step S3005) Performs predetermined verification described later using the existing UE_BS_Identity), recognizes that it is a BS processing request from the T-PGW 5b requested when the verification result is successful, and transmits an IKE_SA_INIT message in response (step S3009) : IKE_SA_INIT_2).
  • the UE 1 describes the previously acquired UE_BS_Identity in the IKE_SA_INIT message to be transmitted and transmits it.
  • the T-PGW 5 b it is possible to indicate to the T-PGW 5 b that the response is from the UE 1 that has requested the trigger of this BS processing, and to confirm that BS processing is being performed between correct nodes.
  • FIG. 7B is a diagram showing an example of a second IKE_SA_INIT message transmitted by the UE 1 to the T-PGW 5 b in step S3009 of FIG.
  • the UE 1 describes at least the BS identifier UE_BS_Identity for UE for identifying the implementation of the present BS acquired from the I-PGW 5a, following the conventional standard IKE_SA_INIT (IKE_SA_INIT message sent by the Responder to the Initiator first). And send.
  • any IKE_SA_INIT message may be used as the IKE_SA_INIT message exchanged between the UE 1 and the T-PGW 5b in steps S3008 and S3009, as long as BS_Identity (T-PGW_BS_Identity and UE_BS_Identity) transmitted by each can be exchanged correctly.
  • the subsequent BS processing (the remainder of IKE_SA_INIT and the processing after step S3010) can be performed by using the conventional standard processing to obtain UE1 and T SA establishment between PGW 5b can be achieved.
  • the UE 1 may set an IKE_SA_INIT reception waiting timer from the T-PGW 5 b for the purpose of facilitating recovery when the IKE_SA_INIT_ 1 message from the T-PGW 5 b can not be received in step S 3008.
  • the timer is set, for example, to a predetermined value when the UE 1 receives an IKE_AUTH Response message according to the present invention in step S3005.
  • the timer value may be arbitrarily set by the UE 1, or may be designated from a network device such as the I-PGW 5a via an IKE_AUTH Response message or the like.
  • the information used as UE_BS_Identity, T-PGW_BS_Identity is, for example, a hash value generated based on a value shared by UE1 and PGW5, a randomly generated value, an address of I-PGW 5a, etc.
  • UE1 and PGW5 If it is a value (code
  • UE_BS_Identity is generated by the I-PDW 5a and transmitted to the UE 1 (step S3005 in FIG. 2) and is transmitted via the AAA server 8b or directly to the T-PGW 5b. (Step S3006 in FIG. 2).
  • the T-PGW 5 b generates a T-PGW_BS_Identity corresponding to the received UE_BS_Identity, and transmits an IKE_SA_INIT_1 message including the generated T-PGW_BS_Identity to the UE 1 (step S 3008 in FIG. 2).
  • the UE 1 having received the IKE_SA_INIT message derives T-PGW_BS_Identity corresponding to UE_BS_Identity (UE_BS_Identity included in the IKE_AUTH Response received at step S3005 in FIG. 2) in advance from the I-PGW 5a, and receives T-PGW_BS_Identity PGW_BS_Identity (T-PGW_BS_Identity included in IKE_SA_INIT_1 received in step S3008 of FIG. 2) is compared.
  • UE 1 may recognize that it is a BS processing request from T-PGW 5 b made as a result of transmitting an IKE_SA_INIT message including Home Prefix to I-PGW 5 a.
  • T-PGW_BS_Identity a hash value obtained from UE_BS_Identity may be used as T-PGW_BS_Identity, or table information indicating correspondence between UE_BS_Identity and T-PGW_BS_Identity may be used. May be In this case, the table information may be acquired from an information server or the like in the 3G network, or may be preset in the UE 1 by the operator. Moreover, UE1 may acquire T-PGW_BS_Identity corresponding to UE_BS_Identity by inquiring to an information server. When a hash function is used, security can be enhanced because both UE_BS_Identity and T-PGW_BS_Identity use a high-level encryption algorithm.
  • UE_BS_Identity is generated by I-PGW 5a and T-PGW_BS_Identity is generated by T-PGW 5b, but for example, both UE_BS_Identity and T-PGW_BS_Identity may be generated by I-PGW 5a.
  • the I-PGW 5a transmits the UE_BS_Identity to the UE 1, and also transmits the T-PGW_BS_Identity corresponding to the UE_BS_Identity to the T-PGW 5b directly or via the AAA server 8b.
  • the T-PGW 5b transmits an IKE_SA_INIT_1 message including the received T-PGW_BS_Identity to the UE 1 so that the UE 1 can confirm whether it is a BS processing request from the T-PGW 5b.
  • UE_BS_Identity and / or T-PGW_BS_Identity may be generated by devices other than I-PGW 5a, for example, UE1, T-PGW 5b, AAA / HSS 8, and each BS_Identity may be generated by different devices.
  • UE 1 includes BS_Identity (BS_Identity included in IKE_AUTH Response received in step S3005 in FIG. 2) in advance from BS_Identity (IKE_SA_INIT_1 received in step S3008 in FIG. 2). And, if identical, it recognizes that it is a BS processing request from the T-PGW 5b. Similarly, the T-PGW 5 b compares the BS_Identity notified from the AAA / HSS 8 with the BS_Identity notified from the UE 1, and recognizes the response from the desired UE 1 if they are identical.
  • UE1 can know T-PGW_BS_Identity corresponding to UE_BS_Identity, but as described above, UE1 and PGW5 can be shared from any BS_Identity If you have a table that can obtain the BS_Identity of, you do not need to send both BS_Identity. Similarly, if devices other than UE1 and PGW5 hold the above table and UE1 and PGW5 can access, there is no need to send both BS_Identity. In addition, you may set not the said table but a fixed value which can not be changed by instruction
  • UE_BS_Identity and / or T-PGW_BS_Identity can be generated by using a shared key generated by the IKE_SA_INIT message, using an arbitrary function (eg, a random function, etc.), or existing One way is to specify it as an index to use the value. Each usage will be described in detail below.
  • the shared key may be UE_BS_Identity, and T-PGW_BS_Identity may be newly generated. As described above, when the generated shared key is used, the time to generate a new BS_Identity is shortened.
  • a method of generating UE_BS_Identity and / or T-PGW_BS_Identity using an arbitrary function may be employed.
  • an arbitrary function for example, a random function or the like.
  • UE_BS_Identity is “HPLMN ID”
  • HPLMN ID HPLMN ID
  • the first IKE_SA_INIT message (IKE_SA_INIT_1 message in step S3008 of FIG. 2) of the BS process started from T-PGW 5b is A problem may occur in that the UE 1 is not reached, resulting in failure in connection with the T-PGW 5 b.
  • UE 1 can detect the presence or absence of NAT at the initial stage of BS processing (see, for example, Non-Patent Document 7).
  • the presence or absence of NAT can be detected at the same stage also in the I-PGW 5a. Therefore, this problem can be solved by the following two methods.
  • the I-PGW 5a that detects that NAT is deployed in the N3G access 3 sends a Home Prefix confirmation request message (for example, using the transfer indication field) from the T-PGW 5b. Include an indication that BS processing is performed via 3G Access 2. This instruction is carried over to the Home Prefix confirmation request reply message (for example, by using a BS indication field), and is transferred to the T-PGW 5b.
  • the above explicit instruction can be made unnecessary by describing the home prefix of UE 1 in the UE address, Processing and message resources can be effectively used.
  • the T-PGW 5b starts BS processing to the home prefix addressed to the above instruction or described in the UE address.
  • BS processing is started to be addressed to the home prefix of the UE 1 that the UE holds and manages, without referring to the address described in the UE address.
  • the home address of UE1 is clear, you may start BS process to a home address.
  • I-PGW 5a detects NAT, BS processing from T-PGW 5b is performed via 3G access 2 in IKE_AUTH Response (IKE_AUTH Response transmitted in step S3005 of FIG. 2) to be transmitted to UE1. You may be notified to wait, as it will come.
  • IKE_AUTH Response transmitted in step S3005 of FIG. 2
  • UE 1 when the communication interface connected to 3G access 2 has transitioned to the idle mode, UE 1 performs processing such as spontaneously transitioning to the active mode to start BS processing from T-PGW 5b (specifically, Can be prepared to receive the IKE_SA_INIT message) immediately, and the connection can be further speeded up.
  • processing such as spontaneously transitioning to the active mode to start BS processing from T-PGW 5b (specifically, Can be prepared to receive the IKE_SA_INIT message) immediately, and the connection can be further speeded up.
  • UE 1 which has detected that NAT is deployed requests I-PGW 5 a to start BS processing via 3G access 2 in IKE_AUTH Request (step S 3003 in FIG. 2).
  • the I-PGW 5a implements the first method described above.
  • FIG. 3 is a diagram showing an example of the configuration of the UE 1 in the first embodiment of the present invention.
  • UE1 is connected to an access network (3G access 2 or N3G access 3) to perform first-order communication unit 101 and second radio communication unit 102 for performing communication processing in the lower layer, and first and second radios.
  • a packet processing unit 103 that performs packet communication processing such as IP on the upper side of the communication units 101 and 102, a BS processing unit 104 that performs BS (bootstrap) processing between UE1 and PGW 5, and an inquiry message to DNS server 9
  • the DNS client processing unit 105 acquires predetermined address information from the result received as a response, the connection control unit 106 which executes the characteristic processing in the present invention, BU / BA exchange etc.
  • the first and second wireless communication units 101 and 102 may be connected to either the 3G access 2 or the N3G access 3, and one of the wireless communication units (for example, the first wireless communication unit 101). ) May be connected to 3G Access 2 and N3G Access 3 simultaneously.
  • UE 1 has two wireless communication units, and one wireless communication unit (first wireless communication unit 101) uses 3G access 2 and the other wireless communication unit
  • the (second wireless communication unit 102) will be described as connecting to the N3G access 3.
  • the process flow of the UE 1 having the configuration illustrated in FIG. 3 will be described in detail with reference to FIG. 4, centering on the process related to the connection control unit 106 that implements the process characteristic of the present invention.
  • the UE 1 has already been connected to the 3G access 2 (home link) via the first wireless communication unit 101, and is connected to the T-PGW 5b.
  • FIG. 4 is a flowchart showing an example of a process flow of the UE 1 in the first embodiment of the present invention.
  • the connection control unit 106 first instructs the second wireless communication unit 102 to start connection in order to start the attach (connection) process to the N3G access 3 (step S5002).
  • the second wireless communication unit 102 performs connection processing in accordance with the connection procedure in the N3G access 3.
  • the DNS client processing unit 105 is instructed to start the search to search for the address of the PGW 5 connected via the N3G access 3 (step S5003).
  • connection control section 106 uses an APN that is an identifier of connection destination network PDN, an HA-APN for identifying PGW 5 or the like according to a standard method (for example, , A non-patent document 6 etc.), a home agent name (FQDN) is constructed, and notified to the DNS client processing unit 105.
  • the DNS client processing unit 105 transmits a DNS query describing the notified home agent name to the DNS server 9 via the packet processing unit 103 and the second wireless communication unit 102.
  • a DNS response is received from the DNS server 9 via the second wireless communication unit 102 and the packet processing unit 103, and the PGW address acquired from the DNS response is transferred to the connection control unit 106.
  • connection control unit 106 is already connected to the home link via the first wireless communication unit 101 (via 3G access 2), establishes a different connection link based on DSMIP or MIPv6, and tries to connect to PGW 5 It is determined whether the three conditions, that is, that the connection destination PGW address has been acquired by DNS, are satisfied (step S5004). If any one of the conditions is not satisfied, the connection control unit 106 instructs the BS processing unit 104 to start standard BS processing for the acquired PGW address. For example, the BS processing unit 104 performs standard BS processing as shown in steps S9002 to S9014 of FIG. 12 (step S5040), and then performs PGW 5 (I-PGW 5a) and BU / BA exchange based on DSMIP or MIPv6. It carries out (step S5041).
  • the connection control unit 106 instructs the BS processing unit 104 to start the BS processing according to the present invention for the acquired PGW address.
  • the BS processing unit 104 starts an IKE_SA_INIT process, which is a procedure for constructing an IKE SA, for the PGW address (the address of the I-PGW 5a) notified from the connection control unit 106 (step S5005).
  • IKE_SA_INIT process is completed and the IKE SA is established, the BS processing unit 104 describes the Home Prefix (Home Prefix) acquired at the time of connection to the home link in the IKE_AUTH Request message and transmits it (Step S5006).
  • the PGW 5 as the transmission destination of the IKE_AUTH Request message can be made to confirm the accommodation status of its own node, and whether the PGW 5 to be connected from now on already accommodates itself, ie via the home link It can check if it is a connected PGW 5 or not.
  • the standard IKE_AUTH Request message in the prior art already has a field for describing the home prefix, and this field can be utilized in the present invention as well.
  • a flag or A directive may be provided explicitly. Note that such a flag or indicator can be explicitly provided even when the field for describing the home prefix is not shared.
  • the IKE_AUTH Request message is transmitted from the BS processing unit 104 to the PGW 5 via the packet processing unit 103 and the second wireless communication unit 102.
  • the PGW 5 transmits an IKE_AUTH Response message to the UE 1 as a response, and the IKE_AUTH Response message is transferred to the BS processing unit 104 via the second wireless communication unit 102 and the packet processing unit 103 (step S5007).
  • the BS processing unit 104 notifies the connection control unit 106 of the parameters (at least the determination result, UE_BS_Identity, operation instruction) described in the IKE_AUTH Response, and the connection control unit 106 evaluates the determination result and operation instruction (step S5008) .
  • connection control section 106 instructs BS processing section 104 to perform the remaining BS processing based on the conventional standard BS procedure. Instruct to continue execution.
  • the BS processing unit 104 executes the remaining BS processing, that is, steps S9008 to S9014 shown in FIG. 12 (step 5030), and subsequently performs BU / BA exchange based on PGW 5 and DSMIP or MIPv6 (step S5031).
  • the connection control unit 106 notifies the UE_BS_Identity notified by the IKE_AUTH Response.
  • the corresponding T-PGW_BS_Identity is uniquely generated (for example, hash calculation is performed using UE_BS_Identity as the original data), or T-PGW_BS_Identity corresponding to UE_BS_Identity is acquired from the database (step S5010).
  • UE_BS_Identity and T-PGW_BS_Identity have been described when the communication system according to the present invention was described, and thus the description will be omitted here.
  • UE_BS_Identity and T-PGW_BS_Identity exist and it is described that the communication system and the mobile terminal operate on the premise of their existence, one of them is not defined according to the usage of BS_Identity described above. Even in this case, the UE 1 can select or modify the operation as appropriate.
  • connection control unit 106 recognizes that the BS processing from the PGW 5 (T-PGW 5 b) that it desires to connect is started in response to the operation instruction being “standby”, from the outside
  • the BS processing unit 104 is set in a state where it can receive IKE_SA_INIT (step S5011).
  • the connection control unit 106 may clear or reset the state and data related to the BS processing with the PGW 5 (I-PGW 5 a) which has already been started by the BS processing unit 104. As a result, it is not necessary to hold the state and data related to the connection with the I-PGW 5a, which will not be required in the future, and resources can be effectively used.
  • state data regarding connection with I-PGW 5a is intentionally held and held. If it becomes necessary to connect to I-PGW 5a as a result, it can be resumed from the middle of BS processing (at least IKE SA is held and implemented from IKE_AUTH Request). It is enough).
  • BS processing for UE1 is started in the T-PGW 5b, and the first message of IKE_SA_INIT (denoted as step S3008: IKE_SA_INIT_1 in FIG. 2) is delivered to UE1.
  • the first IKE_SA_INIT message from T-PGW 5b is transferred to BS processing unit 104 via second wireless communication unit 102 and packet processing unit 103, and BS processing unit 104 confirms that it is an IKE_SA_INIT message from T-PGW 5b.
  • T-PGW_BS_Identity included in the message is transferred to connection control section 106.
  • the acquired T-PGW_BS_Identity is the same as that generated or acquired based on UE_BS_Identity described in the IKE_AUTH Response previously received in step S5007 (same value, same attribute, within predetermined threshold, predetermined (E.g., verification of identity, etc.) via the function of (1) (step S5012).
  • T-PGW_BS_Identity is included in the IKE_SA_INIT message, and processing in the case of performing evaluation by determining correlation with UE_BS_Identity described in the IKE_AUTH Response message is described. It is possible to determine whether the received IKE_SA_INIT message is a BS processing request from the T-PGW 5b by various methods depending on the usage of BS_Identity described above.
  • connection control unit 106 discards the received IKE_SA_INIT message.
  • the connection control unit 106 instructs the BS processing unit 104 to reject, and the BS processing unit 104 discards or rejects the message according to the instruction (step S5020).
  • UE_BS_Identity is stored in the second IKE_SA_INIT message (IKE_SA_INIT_2 transmitted in step S3009 of FIG. 2) to be transmitted as a response. It instructs the BS processing unit 104 to transmit (step S5013).
  • the BS processing unit 104 transmits a second IKE_SA_INIT message storing UE_BS_Identity to the T-PGW 5b according to the instruction.
  • the T-PGW 5b Upon receipt of this IKE_SA_INIT message, the T-PGW 5b uses the UE_BS_Identity stored in the message to verify whether it is a response from the intended UE 1, and if the verification is correctly completed, the subsequent BS processing is T- It is continuously executed with the PGW 5b (step S5014).
  • the connection control unit 106 instructs the MIP processing unit 107 to implement BUIP and BA exchange based on DSMIP or MIPv6 with the T-PGW 5b, and the MIP processing unit 107 executes the T-PGW 5b and BU / BA.
  • the BA exchange is performed (step S5015).
  • FIG. 8 is a diagram showing an example of the configuration of the PGW 5 in the first embodiment of the present invention.
  • the PGW 5 is connected to the core network 4, and a communication unit 201 that performs communication processing in the lower layer, a packet processing unit 202 that performs packet communication processing such as IP above the communication unit, and between UE 1 and PGW 5.
  • Processing unit 203 that performs the bootstrap process, an AAA client processing unit 204 that acquires an inquiry message to the AAA server 8a, and a BS instruction to the UE 1, and a connection control unit 205 that performs characteristic processing according to the present invention.
  • the MIP processing unit 206 that performs mobility management processing such as BU / BA exchange based on DSMIP or MIPv6 to the PGW 5.
  • the PGW 5 is already connected to the 3G access 2 (home link) via the communication unit 201. Moreover, PGW 5 which UE 1 first attempts to attach (connection) processing is assumed to be I-PGW 5 a.
  • FIG. 9 is a flow chart showing an example of the processing flow of the PGW 5 in the first embodiment of the present invention.
  • PGW 5 according to the present invention waits for BS from UE 1 to establish SA with UE 1.
  • an IKE_SA_INIT message is sent from the UE 1 (step S 6002).
  • the IKE_AUTH Request message (which includes the UE1's Home Prefix)
  • the I-PGW 5a is a binding cache of the Home Prefix stored in the message that the I-PGW 5a has. It is confirmed whether it is registered in (step S6003).
  • the I-PGW 5a checks not only the management database (MIP binding cache) used in DSMIP / MIP when checking whether the home prefix sent by UE1 is registered in the binding cache.
  • PMIP binding cache managed by I-PGW 5a (or managed by another node managed by I-PGW 5a, further managed by another node arranged in the same domain as I-PGW 5a), or for GTP It is also desirable to check the location management database.
  • the I-PGW 5a generates (acquires) UE_BS_Identity (step S6010). There are several methods for generating UE_BS_Identity as described above. Then, the I-PGW 5a generates an operation instruction for instructing the T-PGW 5b, which manages the Home Prefix stored in the IKE_SA_INIT message, to cause the UE 1 to perform BS (step S6011). Then, the Home Prefix received in the IKE_SA_INIT message, the generated UE_BS_Identity, and the operation instruction are transmitted to the AAA server 8a (step S6012). Note that the T-PGW 5b may be searched and identified by the AAA server 8a or the HSS 8b, or may be searched and identified by the I-PGW 5a.
  • the I-PGW 5a generates an operation instruction to the UE 1 for transmission to the UE 1 separately from the direction of the AAA server 8a (step S6013). Then, a Prefix determination result (for example, False, '1', etc.) indicating that the Home Prefix is different, the generated UE_BS_Identity, and an operation instruction to the UE 1 are transmitted to the UE 1 (step S6014).
  • a Prefix determination result for example, False, '1', etc.
  • the transmission processing (transmission to UE1) of the operation instruction in steps S6013 and S6014 is performed after the transmission processing (transmission to AAA server 8b) of the operation instruction in steps S6011 and S6012.
  • the order of these transmission processes is not particularly limited, and may be performed in any order or in parallel.
  • step S6003 when the Home Prefix stored in the IKE_AUTH Request message is registered in the binding cache possessed by the I-PGW 5a (step S6003), standard BS processing is executed (step S6030), and after the SA is established, from UE1. The BA is exchanged for the sent BU (step S6031).
  • PGW 5 When PGW 5 works not as I-PGW 5 a but as T-PGW 5 b, it receives a Home Prefix confirmation request reply message instead of the IKA_SA_INIT message (step S 6004). In this case, the T-PGW 5b generates (acquires) T-PGW_BS_Identity from the received UE_BS_Identity (step S6020). Then, the T-PGW 5 b transmits an IKE_SA_INIT_ 1 message storing the generated T-PGW_BS_Identity to the UE 1 (step S 6021).
  • the T-PGW 5b When the T-PGW 5b receives the IKE_SA_INIT_2 message, which is expected to be a reply of the IKE_SA_INIT_1 message, it uses the UE_BS_Identity transferred from the AAA server 8a (UE_BS_Identity included in the Home Prefix confirmation request reply message received in step S6004). Then, it matches BS_Identity stored in the IKE_SA_INIT_2 message (step S6022). If there is a match, standard BS processing is subsequently performed to establish an SA between the UE 1 and the T-PGW 5 b (step S 6040). Then, after establishing the SA, the BA is exchanged for the BU sent from the UE 1 (step S 6041).
  • the Home Prefix confirmation request reply message received in step S6004 may contain T-PGW_BS_Identity or other types of values, but these values may also be used in this case as well. , It is possible to match the BS_Identity contained in the IKE_SA_INIT_2 message.
  • FIG. 10 is a diagram showing an example of the configuration of the AAA server 8a according to the first embodiment of this invention.
  • the AAA server 8a and the HSS 8b may be physically or logically mounted on the same device.
  • the configuration shown in FIG. 10 may be mounted on the HSS 8b.
  • the AAA server 8a is connected to the core network 4 and performs communication processing in the lower layer, the communication unit 301, packet processing unit 302 for performing packet communication processing such as IP in the upper layer of the communication unit, , At least an authentication / authorization processing unit 304 for performing authentication / authorization processing of the UE 1 corresponding to a protocol such as DSMIP or MIPv6.
  • the AAA server 8a is already connected to the core network 4 via the communication unit 301.
  • PGW5 which UE1 tries attachment (connection) process first is set to I-PGW5a.
  • FIG. 11 is a flow chart showing an example of the processing flow of the AAA server 8a in the first embodiment of the present invention.
  • the AAA server 8a according to the present invention waits for a Home Prefix confirmation request message sent from the PGW 5.
  • a Home Prefix confirmation request message is sent from the I-PGW 5 a (step S 7002).
  • the AAA server 8a having received this message confirms whether or not the operation instruction is stored in the Home Prefix confirmation request message, and further confirms whether the operation instruction is a transfer instruction (step S7010).
  • the AAA server 8a inquires of the HSS 8b whether the Home Prefix stored in the Home Prefix confirmation request message is registered in the subscription data (Subscription data) of the HSS 8b. .
  • the HSS 8b refers to the subscription data to check whether the target Home Prefix is registered, and if registered, the address of the T-PGW 5b that manages the target Home Prefix is an AAA server.
  • the AAA server 8a confirms whether the address of the T-PGW 5b is stored in the message returned from the HSS 8b (step S7012).
  • a BS instruction is generated to BS the UE 1 (step S 7013). Then, the address of UE1, UE_BS_Identity sent from I-PGW 5a, and the BS instruction generated in step S7013 are transmitted to T-PGW 5b (step S7014).
  • step S7012 if the address of the T-PGW 5b is not stored in the message returned from the HSS 8b (step S7012), or if the transfer instruction is not stored in the Home Prefix confirmation request message (step S7010), the I- The result (for example, False, '1', etc.) is sent back to the PGW 5a (step S7030).
  • the Authentication-Request / Identity message is received from the PGW 5 instead of the Home Prefix confirmation request message (step S7020)
  • the User Profile user profile
  • the AVs Authentication
  • Vectors Request and acquire an authentication vector (step S7021).
  • the AAA server 8a After acquiring the User Profile and AVs, the AAA server 8a sends back an EAP-Request / AKA-Challenge message to the PGW 5 (step S7022).
  • the AAA server 8a receives the EAP-Response / AKA-Challenge message which is the reply of the EAP-Request / AKA-Challenge message (step S7023), and the Authentication-Answer / EAP-Success + keying material (the key) which is the reply. Material) A message is sent back to the PGW 5 (step S7024).
  • FIG. 13 is a sequence diagram for illustrating an example of the system operation in the second embodiment of the present invention.
  • FIG. 13 is a UE authentication server that determines whether at least the UE 1 and the UE 1 are not originally intended to connect, the I-PGW 5 a, and the UE 1 may use the access network by the T-PGW 5 b and the UE 1 originally desired to connect. It is composed of the AAA server 8a and the user information data server HSS 8b, and an example of the processing sequence is illustrated.
  • Steps S9101 to S9105 of the processing flow of the second embodiment of the present invention are the same as steps S9001 to S9005 (shown in FIG. 12) of the PDN GW reallocation procedure of the prior art.
  • the I-PGW 5a receives the EAP-Request / AKA-Challenge message to acquire the address of the T-PGW 5b (FIG. 12).
  • step S9006 it is at the time of BU / BA exchange implemented after SA establishment between UE1 and I-PGW 5a that the presence (address) of T-PGW 5b is actually notified to UE1 (step in FIG. 12) 9016).
  • the I-PGW 5a receives the EAP-Request / AKA-Challenge message from the AAA server 8a by the I-PGW 5a shown in FIG. 13 (at step S9106 When, for example, the address of T-PGW 5b is acquired in step S9107, the address of T-PGW 5b is inserted into the IKE_AUTH Response message (or other messages may be used) transmitted to UE 1 in step S9107, for example. The UE 1 is notified of the address of the T-PGW 5 b acquired in step S 9106.
  • the address of the T-PGW 5 b is notified to the UE 1 while the UE 1 is performing connection authentication with the I-PGW 5 a. This is because when the UE 1 attaches (connects) to the N3G access 3, access authentication (step S9100 in FIG. 13) by the core network 4 has already been performed, and the T-PGW 5b to the UE 1 is backed by the authentication result. This is because the notification permission of the address is determined.
  • the UE 1 performs T at an earlier stage (eg, the stage of extracting the address of the T-PGW 5b from the IKE_AUTH Response message) compared to the prior art.
  • -It becomes possible to grasp the address of PGW 5b, and it becomes possible to recognize that it is going to connect to PGW 5 (I-PGW 5a) different from the desired PGW 5 (T-PGW 5b).
  • UE 1 can start processing (S9202 to S9214: standard BS) to redo T-PGW 5b instead of I-PGW 5a and BS at an earlier stage compared to the prior art.
  • the UE 1 and the T-PGW 5 b can carry out BU / BA exchange (steps S9215, S9216)).
  • AAA server 8a is in a state of waiting for reception of response information after transmitting challenge information to UE1, and in a state where a considerable amount of state regarding UE1 is held. It is in. Therefore, as illustrated in FIG. 13, the UE 1 cancels the status waiting of the AAA server 8a by transmitting a message corresponding to the IKE_AUTH Request in step S9108, and receives the message corresponding to the IKE_AUTH Response in step S9112. It may be necessary to confirm that the BS processing in progress has been completed (steps S9108 to S9112).
  • the UE 1 performs the process of canceling the state wait of the AAA server 8a in steps S9108 to S9112.
  • the connection process with the T-PGW 5b in steps S9202 to S9216 may be performed.
  • the time required to establish an SA between the UE 1 and the T-PGW 5 b can be shortened by the time until receiving a message equivalent to the IKE_AUTH Response, which is a reply for the cancellation of the state waiting of the AAA server 8 a.
  • FIG. 14 is a first sequence diagram for explaining an example of the system operation in the third embodiment of the present invention.
  • FIG. 14 is a UE authentication server that determines whether at least UE1 and I-PGW 5a, which UE1 originally intended to connect, T-PGW 5b, which UE1 originally desires to connect, may permit each access network use by UE1.
  • An example of a processing sequence by a certain AAA server 8a and a user information data server HSS 8b is illustrated.
  • the address of the T-PGW 5b is an MSK created after the IKE_AUTH message exchange is completed, that is, the UE 1 and the AAA server 8b successfully authenticate each other with the UE 1 and the I-PGW 5a.
  • a PGW switching method in the case of being notified after being exchanged between will be described.
  • FIG. 14 an example of the system operation in the third embodiment of the present invention illustrated in FIG. 14 will be described in comparison with the PDN GW reallocation procedure (the processing flow illustrated in FIG. 12) of the related art.
  • steps S10001 to S10009 of the processing flow according to the third embodiment of the present invention are the same as steps S9001 to S9009 (shown in FIG. 12) of the PDN GW reallocation procedure of the prior art, and therefore the description is omitted. .
  • the AAA server 8a processes the EAP-Response message sent from the UE1 via the I-PGW 5a, and the UE1 and I-PGW5a. And the address of the T-PGW 5b to be switched to for the UE 1 to the I-PGW 5a (FIG. 12, step S9010). ).
  • an Authentication-Answer message in which UE_BS_Identity is further added to the address of MSK and T-PGW 5 b transmitted from the AAA server 8 a to I-PGW 5 a is transmitted to I-PGW 5 a (FIG. 14, step S10010).
  • FIG. 18B is a diagram showing a format example of an Authentication-Answer message as an example of the response message that the AAA server 8a transmits to the I-PGW 5a in step S10010 of FIG.
  • the AAA server 8a provides an MSK (key) field 4102 and a BS identifier field (UE_BS_Identity / T-PGW_BS_Identity) 4103 in addition to the conventional standard Authentication-Answer message 4101.
  • the MSK (key) field 4102 is a field for transmitting a key used between the UE 1 and the I-PGW 5 a to the I-PGW 5 a.
  • the AAA server 8a may store the MSK in the MSK (key) field 4102, or may store the MSK in the Authentication-Answer message 4101 without using the MSK (key) field 4102.
  • the response message may not include the MSK (key) field 4102.
  • the BS identifier field 4103 can notify the PGW 5 of UE_BS_Identity and T-PGW_BS_Identity depending on usage.
  • BS_Identity may be described in the existing payload of a standard Authentication-Answer message, and PGW 5 may be notified of it.
  • the response message may be a message other than the Authentication-Answer message as long as it can transfer predetermined information.
  • steps S10011 to S10013 of the processing flow of the third embodiment of the present invention are the same as steps S9011 to S9013 (shown in FIG. 12) of the PDN GW reallocation procedure of the prior art, and therefore the description will be omitted.
  • the I-PGW 5a transmits the address of the T-PGW 5b to the UE 1 (FIG. 12, step S9014).
  • the address of the T-PGW 5b and the UE_BS_Identity notified from the AAA server 8a will be IKE_AUTH Response
  • the message is put on a message and notified to the UE 1 (FIG. 14, step S10014).
  • FIG. 17B is a diagram showing a format example of an IKE_AUTH Response message as an example of a message transmitted by the T-PGW 5b to the UE 1 in step S10014 in FIG.
  • the T-PGW 5 b can provide a BS identifier (UE_BS_Identity / T-PGW_BS_Identity) field 3102 in addition to the conventional standard IKE_AUTH Response message 3101 and can notify the respective values to the UE 1.
  • BS_Identity UE_BS_Identity or T-PGW_BS_Identity can be notified to the PGW 5 depending on usage.
  • T-PGW_BS_Identity may be described by appending Notify Payload defined in the standard IKEv2 protocol (see Non-Patent Document 7 above) to a standard IKE_AUTH Response message, and the UE 1 may be notified of this.
  • this response message may be a message other than the IKE_AUTH Response message as long as it can transfer predetermined information, but may be sent simultaneously with the transmission of the IKE_AUTH Response message or later than the IKE_AUTH Response message. desirable.
  • the I-PGW 5a after the MSK is exchanged between the UE1 and the I-PGW 5a by the IKE_AUTH message exchange (FIG. 14, steps S10012, S10013), the I-PGW 5a notifies the UE1 of the address of the T-PGW 5b (for example, , The notification by the IKE_AUTH Response message in step S10014) is performed, but when the authentication of UE1 by the AAA server 8a succeeds (that is, the AAA server 8a completes the authentication of UE1 based on the challenge information received in step S10009) It is also possible for the network side to notify the UE 1 of the address of the T-PGW 5b at the time of In this case, after the processing of the challenge information received in step S10009 is completed, the address of the T-PGW 5b may be stored in an arbitrary message (for example, the messages in steps S10010 and S10012) and notified to the UE1.
  • UE1 starts BS processing in order to establish an SA between UE1 and T-PGW 5b.
  • the UE 1 and the T-PGW 5 b perform an IKE_SA_INIT message exchange between the UE 1 and the T-PGW 5 b to generate a shared key between the UE 1 and the T-PGW 5 b in order to protect the IKE_AUTH message performing UE 1 authentication (FIG. 14) , Step S10101).
  • UE1 creates an IKE_AUTH Request message, encrypts it using the shared key between UE1 and T-PGW 5b that was previously generated through IKE_SA_INIT message exchange, and sends it to T-PGW 5b.
  • MSK key
  • UE1 and AAA which were necessary in the prior art, are required later.
  • Mutual authentication with the server 8a can be omitted. Therefore, the UE 1 stores a Reuse Indicator indicating reuse of the previously generated MSK in the IKE_AUTH Request message, and transmits the Reuse Indicator to the T-PGW 5 b (FIG. 14, step S 10102).
  • the Reuse indicator may generate the I-PGW 5a or the AAA server 8a or the like in the process of the bootstrap process between the UE 1 and the I-PGW 5a and notify the UE 1 of this.
  • the AAA server 8a generates and notifies the UE 1 so that the network system including the AAA server 8a or the AAA server 8a can make an assertion to the UE 1 to support or permit the reuse of the key.
  • UE 1 it is possible to request the reuse of the key with certainty, and in turn, it is possible to more reliably finish the switching connection with the desired T-PGW 5 b in a short time.
  • PGW 5 when the AAA server 8a generates and notifies Reuse Indicator, but PGW 5 of the domain or core network 4 does not support or permit it (for example, because it is not permitted for roaming UE 1), PGW 5 is Reuse.
  • the Indicator may be removed and not notified to UE1.
  • HPLMN Home Public Land Mobile Network
  • VPN Visited Public Land Mobile Network
  • the UE 1 stores UE_BS_Identity in the IKE_AUTH Request message (FIG. 14, step S10102).
  • FIG. 17A is a diagram showing a format example of an IKE_AUTH Request message as an example of a message transmitted by the UE 1 to the T-PGW 5b in step S10102 of FIG.
  • the UE 1 can provide a Reuse Indicator field 3002 and a UE BS identifier (UE_BS_Identity) field 3003 in addition to the conventional standard IKE_AUTH Request message 3001, and can notify the T-PGW 5b of the respective values.
  • Notify Payload defined in the standard IKEv2 protocol may be added to a standard IKE_AUTH Request message to describe Reuse Indicator and notify the UE1. Note that this message may be a message other than the IKE_AUTH Request message as long as predetermined information can be transferred.
  • the T-PGW 5b transfers the Reuse indicator and UE_BS_Identity included in the IKE_AUTH Request message sent from the UE 1 to the AAA server 8a (FIG. 14, Step S10103). Note that even if Reuse Indicator and UE BS Identity notify T-PGW 5b via the IKE_SA_INIT message, T-PGW 5b notifies the AAA server 8a of the same parameter in parallel with the exchange of the IKE SA INIT message. Good.
  • FIG. 18A is a view showing a format example of an Authentication-Request message as an example of a message transmitted by the T-PGW 5b to the AAA server 8a in step S10103 of FIG.
  • the T-PGW 5b can provide a Reuse Indicator field 4002 and a UE BS identifier (UE_BS_Identity) field 4003 in addition to the conventional standard Authentication-Request message 4001, and can notify the AAA server 8a of the respective values.
  • Reuse Indicator and UE_BS_Identity may be described in the existing payload of a standard Authentication-Request message, and notified to the AAA server 8a.
  • This message may be a message other than the Authentication-Request message as long as it can transfer predetermined information.
  • the AAA server 8a receives the Reuse indicator transferred from the T-PGW 5b, and determines that the reuse of MSK at the time of establishing the SA between the UE 1 and the I-PGW 5a is requested first, and the AAA server The MSK corresponding to UE_BS_Identity held by 8a is notified to the T-PGW 5b.
  • UE_BS_Identity may be replaced with a parameter (eg, User ID or the like) that can confirm that the UE 1 has completed the full authentication once.
  • T-PGW_BS_Identity corresponding to UE_BS_Identity is also notified (FIG. 14, step S10104).
  • T-PGW_BS_Identity may be generated by the AAA server 8a itself, or when a database server (not shown) on the network holding the BS_Identity list is installed, the database server is inquired and the UE BS is checked. T-PGW BS_Identity corresponding to Identity may be acquired and used.
  • the T-PGW 5b notifies the AAA server 8a of its own information (for example, an IP address, an identifier of the PGW 5, etc.) through step S10103.
  • the AAA server 8a it can be confirmed that this connection request is a switching connection request to the T-PGW 5b instructed to the UE 1 earlier, and reuse of MSK can be correctly authorized.
  • FIG. 18B is a diagram showing a format example of an Authentication-Answer message as an example of a message that the AAA server 8a transmits to the T-PGW 5b in step S10104 of FIG.
  • the AAA server 8a provides an MSK (key) field 4102 and a BS identifier field (UE_BS_Identity / T-PGW_BS_Identity) 4103 in addition to the conventional standard Authentication-Answer message 4101.
  • the MSK (key) field 4102 stores the MSK generated between the UE 1 and the I-PGW 5a. Note that this MSK may be stored in a field that stores the MSK in the standard Authentication-Answer message 4101.
  • the BS identifier field 4103 can notify the PGW 5 of UE_BS_Identity and T-PGW_BS_Identity depending on usage.
  • BS_Identity may be described in the existing payload of a standard Authentication-Answer message, and notified to the T-PGW 5b.
  • the response message may be a message other than the Authentication-Answer message as long as it can transfer predetermined information.
  • the T-PGW 5b reuses the AUTH parameter value generated using the MSK notified from the AAA server 8a (in practice, it is generated at the SA establishment between the UE 1 and the I-PGW 5a).
  • the UE 1 since the UE 1 has already generated the MSK through the steps S10012 to S10014, it is sufficient to convey only the success of the authentication in the step S10105 (that the reuse of the MSK has been approved at the same time as the success of the authentication). Because it is also a notification of).
  • FIG. 17B is a diagram showing a format example of an IKE_AUTH Response message as an example of a message transmitted by the T-PGW 5b to the UE 1 in step S10105 of FIG.
  • the T-PGW 5 b can provide a BS identifier (BS_Identity) field 3102 in addition to the conventional standard IKE_AUTH Response message 3101 and can notify the respective values to the UE 1.
  • BS_Identity BS identifier
  • T-PGW_BS_Identity may be described by appending Notify Payload defined in the standard IKEv2 protocol (see Non-Patent Document 7 above) to a standard IKE_AUTH Response message, and the UE 1 may be notified of this.
  • the response message may be any message other than the IKE_AUTH Response message as long as it can transfer predetermined information.
  • the UE 1 that has received the IKE AUTH Response message verifies the correlation between UE_BS_Identity and T-PGW_BS_Identity, and if it can confirm that it corresponds correctly, it implements BU / BA exchange with T-PGW 5 b (FIG. 14, step) S10201).
  • UE_BS_Identity and T-PGW_BS_Identity described above are useful for simple mutual authentication between UE 1 and AAA server 8a, when such mutual authentication is unnecessary or when mutual authentication can be performed separately. May omit these BS_Identities.
  • the AAA server 8a can hold the state for the UE 1 even after the instruction to switch to the T-PGW 5b, the Reuse Indicator notified by the UE 1 can be omitted.
  • the AAA server 8a can identify the UE 1 based on the User ID or the like, extract key data based on the stored state for the UE 1, and notify the T-PGW 5b of the key data.
  • step S10014 when there is a record in which UE1 performed SA establishment with other PGW5 in the past, the switching request of PGW5 with respect to UE1 (namely notification of the address of switching destination PGW5 (T-PGW5b)) precedes step S10014 described above It is also possible to implement (for example, step S10007 in FIG. 14).
  • the UE 1 transmits the Reuse Indicator transmitted in step S10102 in the IKE AUTH Request message of step S10003.
  • the I-PGW 5a referring to this Reuse Indicator acquires the key already established for the UE 1 from the AAA server 8a in the process of steps S10004 to S10006 in the process of steps S10004 to S10006 (at this time, simultaneously the switching destination) You will also get the PGW 5 address). Then, the I-PGW 5a transmits the IKE_AUTH response message (that is, the message equivalent to the IKE_AUTH response message transmitted in step S10105 described above) including the address of the switching destination PGW 5 in step S10007 to the UE1.
  • the IKE_AUTH response message that is, the message equivalent to the IKE_AUTH response message transmitted in step S10105 described above
  • the UE 1 can reuse the key established in the past to obtain the address of the switching destination PGW 5 at high speed, and even if the PGW 5 which is not originally intended to be connected is allocated, the switching connection to the desired PGW 5 Can be implemented at high speed.
  • the AAA server 8a may notify the T-PGW 5b of the generated MSK at the timing (FIG. 14, step S10010) instructing switching to the T-PGW 5b. Specifically, this will be described with reference to FIG.
  • FIG. 15 is a second sequence diagram for explaining an example of the system operation in the third embodiment of the present invention.
  • UE1 which is not originally intended to connect
  • T-PGW 5b that UE 1 originally desires to connect
  • a UE authentication server which determines whether or not the use of each access network by UE 1 may be permitted.
  • An example of a processing sequence by a certain AAA server 8a and a user information data server HSS 8b is illustrated.
  • Steps S11001 to S11010 of the process flow of FIG. 15 are the same as steps S10001 to S10010 of the process flow of FIG.
  • the AAA server 8a can notify the T-PGW 5b of the MSK.
  • the process of transmitting the Authentication-Answer message storing the UE_BS_Identity to the I-PGW 5a simultaneously with the SA establishment process between the UE 1 and the I-PGW 5a.
  • the MSK generated in the process and T-PGW_BS_Identity corresponding to UE_BS_Identity are transmitted to the T-PGW 5b (FIG. 15, step S11011).
  • FIG. 19 is a diagram showing a format example of a BS_Identity notification message as an example of a message that the AAA server 8a transmits to the T-PGW 5b in step S11011 of FIG.
  • the AAA server 8a has the destination address field 5001 the address of the T-PGW 5b, the source address field 5002 its own address, the MSK (key) field 5003 the MSK generated between the UE1 and the I-PGW 5a, the UE address field 5004
  • the address of UE1 corresponding to MSK for example, CoA of UE1
  • T-PGW_BS_Identity corresponding to UE_BS_Identity is described in T-PGW_BS_Identity field 5005, and T-PGW 5b is transmitted.
  • the BS_Identity notification message may include the User ID of UE1, which makes it easy to determine whether or not the full authentication has been completed for UE1 when T-PGW 5b receives an IKE_AUTH Request message from UE1. It becomes possible to match UE1 more reliably.
  • the T-PGW 5b Upon receiving the IKE_AUTH Request message (corresponding to step S10102 in FIG. 15) storing Reuse indicator and UE_BS_Identity, the T-PGW 5b sends back to the UE1 an IKE_AUTH Response message storing the T-PGW_BS_Identity received from the AAA server 8a in step S11011. (FIG. 15, step S11103). Note that the T-PGW 5b may check whether the UE_BS_Identity received in step S11102 and the T-PGW_BS_Identity received in step S11011 correspond correctly (eg, hash value verification, BS_Identity list on the network).
  • the T-PGW 5b does not have to store and notify the MSK in the IKE_AUTH Response message transmitted in step S11103.
  • the T-PGW 5b stores the MSK in the IKE_AUTH Response message transmitted in step S11103. It may notify UE1 so that UE1 can grasp MSK certainly.
  • the format example of the IKE_AUTH Response message which is an example of the response message transmitted from the T-PGW 5b to the UE 1 in step S11103 of FIG. 15, is illustrated in FIG. 17B, and the format of the IKE_AUTH Response message in step S10105 of FIG. Description is omitted because it is identical to the example.
  • the UE 1 Upon receiving the IKE AUTH Response message, the UE 1 verifies the correlation between UE_BS_Identity and T-PGW_BS_Identity, and if it is confirmed that the correspondence is correct, executes the BU / BA exchange with T-PGW 5b (FIG. 15, step) S11201). Thus, when the UE 1 switches to the T-PGW 5 b by connecting the AAA server 8 a in advance to notify the T-PGW 5 b of the MSK, the T-PGW 5 b acquires the MSK from the AAA server 8 a. Fast switching connection is possible.
  • the T-PGW 5 b When the T-PGW 5 b receives / processes the IKE_AUTH Request message from the UE 1 before the AAA server 8 a notifies the T-PGW 5 b of the MSK, the T-PGW 5 b again performs the full authentication process for the UE 1 as an AAA server. It will require 8a, which will increase the time required for connection. In order to avoid this, the UE 1 transmits an IKE_AUTH Request message including the Reuse indicator described in FIG. 14 to the T-PGW 5 b (FIG. 15, step S 11102), and the T-PGW 5 b has to acquire the MSK from the AAA server 8 a. For example, the AAA server 8a may be inquired. As a result, the MSK can be more reliably reused, and the switching connection can be speeded up.
  • the above-described UE_BS_Identity and T-PGW_BS_Identity are used to perform simple mutual authentication between the UE1 and the AAA server 8a, or in the AAA server 8a, the T-PGW 5b to which the connection request from the UE1 is instructed earlier. Although it is useful to determine whether it is for switching connection to or for connecting to a new PGW 5 and to ensure that MSK reuse is performed, when such mutual authentication is not necessary. Or, if mutual authentication can be performed separately, compare the APN (Access Point Name) etc. included in the connection request from UE 1 in AAA 8a with the one notified in the previous connection request (via I-PGW 5a), etc. In cases such as where it is possible to confirm that this connection request is due to switching to T-PGW 5b by the method of It is also possible to omit the BS_Identity.
  • APN Access Point Name
  • the T-PGW 5b can obtain a key for the UE 1 from the AAA server 8a before receiving an IKE_AUTH Request message from the UE 1, and can recognize key reuse at this point in time. Therefore, the Reuse Indicator notified by the UE 1 can also be omitted.
  • the notification from the AAA server 8a is delayed from the arrival of the IKE_AUTH Request message from the UE 1, and the key is reused for the T-PGW 5b instead of the process based on the conventional sequence. It is useful to add Reuse Indicator to promote processing based on sequence.
  • the UE 1 may be notified of the address of the T-PGW 5b which is the switching destination PGW 5 during connection with the I-PGW 5a (step S9107 in FIG. 13). ).
  • the UE 1 executes steps S9108 to S9112 to eliminate the state of the AAA server 8a, but the authentication process (MSK generation) by the AAA server 8a in substantially this step section It is considered that the shortening of the processing time is generally larger if the authentication data (MSK etc.) is reused at the time of switching connection with the T-PGW 5b by completing the above.
  • step S9108 of FIG. 13 the authentication process may continue. That is, although the process after step S9108 in FIG. 13 is replaced with step S10008 in FIG. 14, since the address of T-PGW 5b has already been notified to UE1 in step S9107, notification is made again in step S10014 in FIG. There is no need.
  • the configuration of the mobile terminal (UE1) in the third embodiment of the present invention is the same as the configuration (see FIG. 3) of the mobile terminal (UE1) in the first and second embodiments of the present invention. I omit explanation.
  • FIG. 16 is a diagram showing an example of the configuration of UE 1 in the third embodiment of the present invention, and UE 1 has already been connected to 3G access 2 (home link) via first radio communication unit 101. , T-PGW 5b is assumed to be connected.
  • the connection control unit 106 first instructs the second wireless communication unit 102 to start connection in order to start the attach (connection) process to the N3G access 3 (step S12001).
  • the second wireless communication unit 102 performs connection processing in accordance with the connection procedure in the N3G access 3.
  • the DNS client processing unit 105 is instructed to start the search in order to search for the address of the PGW 5 connected via the N3G access 3 (step S12002).
  • connection control section 106 uses an APN that is an identifier of connection destination network PDN, an HA-APN for identifying PGW 5 or the like according to a standard method (for example, , A non-patent document 6 etc.), a home agent name (FQDN) is constructed, and notified to the DNS client processing unit 105.
  • the DNS client processing unit 105 transmits a DNS query describing the notified home agent name to the DNS server 9 via the packet processing unit 103 and the second wireless communication unit 102. Further, as a response, a DNS response is received from the DNS server 9 via the second wireless communication unit 102 and the packet processing unit 103, and the PGW address acquired from the DNS response is transferred to the connection control unit 106 (step S12003).
  • the connection control unit 106 instructs the BS processing unit 104 to start general BS processing for the acquired PGW address.
  • the BS processing unit 104 starts an IKE_SA_INIT process, which is a procedure for constructing an IKE SA, for the PGW address (the address of the I-PGW 5a) notified from the connection control unit 106 (step S12004).
  • IKE_SA_INIT process is completed and the IKE SA is established, the BS processing unit 104 transmits an IKE_AUTH Request message (step S12005).
  • the IKE_AUTH Request message is transmitted from the BS processing unit 104 to the I-PGW 5a via the packet processing unit 103 and the second wireless communication unit 102.
  • the I-PGW 5a transmits an IKE_AUTH Response message to the UE 1 as a response to the IKE_AUTH Request message, and the IKE_AUTH Response message received by the UE 1 is transferred to the BS processing unit 104 via the second wireless communication unit 102 and the packet processing unit 103. (Step S12006).
  • the UE 1 When the SA between the UE 1 and the I-PGW 5 a is established, the UE 1 is informed that switching from the I-PGW 5 a to the T-PGW 5 b is necessary. Specifically, the address for the T-PGW 5b serving as the switching destination PGW 5 and the authentication data for the UE 1 by the AAA server 8a completed via the I-PGW 5a can be reused upon switching connection to the T-PGW 5b. It is confirmed whether UE_BS_Identity has been received (step S12007).
  • the UE 1 when the UE 1 receives the address of the T-PGW 5 b and the UE_BS_Identity, the UE 1 starts a switch connection to the T-PGW 5 b. That is, SA establishment with T-PGW 5 b is started.
  • the UE 1 performs an IKE_SA_INIT message exchange with the T-PGW 5b (step S12010).
  • UE 1 reuses MSK generated by establishing SA with I-PGW 5a in order to shorten connection time by omitting full authentication conventionally performed in establishing SA with T-PGW 5b. Is generated (step 12011). The order of the processes of step S12010 and step S12011 may be reversed. The UE 1 stores the generated Reuse Indicator and the previously acquired UE_BS_Identity in the IKE_AUTH Request message, and transmits the message to the T-PGW 5 b (step S12012).
  • the T-PGW 5 b When the T-PGW 5 b receives the IKE_AUTH Request message in which the Reuse Indicator and the UE_BS_Identity are stored, the T-PGW 5 b transfers the message to the AAA server 8 a.
  • the AAA server 8a receives the IKE_AUTH Request message transferred from the T-PGW 5b, it confirms that the Reuse Indicator and the UE_BS_Identity are stored, and generates an MSK generated when the UE 1 connects via the I-PGW 5a. And T-PGW_BS_Identity corresponding to UE_BS_Identity, for example, by notifying the T-PGW 5b by an Authentication-Answer message.
  • the AAA server 8a may notify the T-PGW 5b of MSK and T-PGW_BS_Identity as a response to the IKE_AUTH Request message (corresponding to the first sequence shown in FIG. 14), from the response to the IKE_AUTH Request message.
  • the MSK and T-PGW_BS_Identity may be notified to the T-PGW 5b first (corresponding to the second sequence illustrated in FIG. 15).
  • the T-PGW 5b notified of the MSK and T-PGW_BS_Identity stores the T-PGW_BS_Identity in the IKE_AUTH Response message and transmits it to the UE 1, and the UE 1 receives it (step S12013).
  • the UE 1 confirms whether the BS_Identity stored in the IKE_AUTH Response message corresponds to the UE_BS_Identity (step S12014).
  • T-PGW_BS_Identity corresponding to UE_BS_Identity may be generated and held at an arbitrary timing, or may be generated at the timing of step S12014 (for example, Hash function, use of database server holding BS_Identity list, etc.)
  • the T-PGW_BS_Identity sent from the T-PGW 5 b matches the T-PGW_BS_Identity generated by the UE 1, the T / P GW 5 b and the BU / BA exchange are performed, and the process ends (step S 12020). On the other hand, if they do not match, the UE 1 discards the received IKE_AUTH Response message (step S12021).
  • the UE 1 transmits the IKE_AUTH_Request message storing the Reuse Indicator and the UE_BS_Identity to T. -It is desirable to send to PGW 5b.
  • the BS_Identity notification (FIG. 15, step S11011) from the AAA server 8a to the T-PGW 5b is delayed or lost, and the T-PGW 5b reuses the key data (MSK) (omission of full authentication).
  • MSK key data
  • the UE 1 uses the address of User Identity and UE 1 instead of the Reuse Indicator. It does not have to be generated in step S12011 or stored in the IKE_AUTH_Request message in step S12012.
  • this connection request is made by a method such as comparing the APN (Access Point Name) and the like included in the connection request from the UE 1 in the AAA server 8a with the one notified by the previous connection request (via I-PGW 5a).
  • APN Access Point Name
  • UE_BS_Identity is no longer required, and notification to UE1 is not performed in step S12007 of FIG.
  • the UE 1 may execute the standard BS processing on the T-PGW 5 b (not shown in FIG. 16), whereby the reuse of MSK is performed by the judgment on the network side, and the T-PGW 5 b Switching connection can be completed in a short time.
  • UE_BS_Identity and T-PGW_BS_Identity used in the third embodiment of the present invention, various combinations are possible as in the first embodiment described above. That is, in the third embodiment of the present invention, UE_BS_Identity may be compared with T-PGW_BS_Identity using, for example, UE_BS_Identity and T-PGW_BS_Identity corresponding to this UE_BS_Identity, and either one of the BS_Identities may be compared. May be used, or BS_Identity may not be used.
  • UE_BS_Identity or T-PGW_BS_Identity for example, a hash value generated based on a value shared by UE1 and PGW5, or randomly generated It is possible to use a value (code) that can be recognized by UE1 and PGW5, such as the determined value or the address of the I-PGW 5a (but not limited to these). Also in the third embodiment of the present invention, UE_BS_Identity and T-PGW_BS_Identity may be generated by PGW 5, AAA server 8a, or another communication device.
  • the MSK used in the third embodiment of the present invention is the same as the MSK defined in RFC by the Internet Engineering Tast Force (IETF), which is an organization that standardizes the technology used on the Internet. It may be defined separately.
  • IETF Internet Engineering Tast Force
  • FIG. 20 is a first sequence diagram for explaining an example of system operation in the fourth embodiment of the present invention.
  • UE1 I-PGW 5a that UE1 originally did not intend to connect
  • T-PGW 5b that UE1 originally wanted to connect
  • UE authentication server that determines whether it is permitted to use each access network by UE1.
  • An example of a processing sequence by a certain AAA server 8a and a user information data server HSS 8b is illustrated.
  • the address of the T-PGW 5b generates an MSK after completion of the IKE_AUTH message exchange, that is, the UE 1 and the AAA server 8b generate a mutual authentication (authentication of the UE 1 by the AAA server 8b). Then, the AUTH parameters created using that MSK are exchanged between the UE 1 and the I-PGW 5a, and each other is authenticated (for example, using the AUTH parameters stored in the IKE_AUTH message, the IKE_SA_INIT message PGW switching method when notified after authentication of UE1 and PGW5) or confirmation of authentication method by confirming correctness of IKE_SA_INIT message (source UE1 and PGW5), key confirmation, etc. Will be explained.
  • steps S13001 to S13009 of the processing flow according to the fourth embodiment of the present invention and steps S9001 to S9009 (shown in FIG. 12) of the PDN GW reallocation procedure of the prior art are the same, and thus the description thereof is omitted.
  • a key Master Session key: hereinafter referred to as MSK
  • MSK Master Session key
  • the address of the PGW 5b is transmitted to the I-PGW 5a (corresponding to the PGW 5 in FIG. 12) (FIG. 12, step S9010).
  • an Authentication-Answer message in which UE_BS_Identity is further added to the address of MSK and T-PGW 5 b transmitted from AAA server 8 a to I-PGW 5 a is transmitted to I-PGW 5 a (FIG. 20, step S13010).
  • this UE_BS_Identity proves that the UE 1 has performed full authentication with the I-PGW 5a (for example, when the presence or absence of the association with the T-PGW_BS_Identity possessed by the AAA server 8a or UE_BS_Identity is encrypted, It is used to check if it is possible, etc., but it may be omitted if identification can be made using UE1's unique information (eg, IMSI (International Mobile Subscriber Identity) etc.).
  • IMSI International Mobile Subscriber Identity
  • the response message transmitted by the AAA server 8a to the I-PGW 5a in step S13010 in FIG. 20 is the same as the message (shown in FIG. 18B) used in step S10010 in FIG. 14 in the third embodiment of the present invention. Omit.
  • the response message may be a message other than the Authentication-Answer message as long as it can transfer predetermined information.
  • steps S13011 to S13013 of the processing flow of the fourth embodiment of the present invention are the same as steps S9011 to S9013 (shown in FIG. 12) of the PDN GW reallocation procedure of the prior art, and therefore the description will be omitted.
  • the I-PGW 5a transmits the address of the T-PGW 5b to the UE 1 (FIG. 12, step S9014).
  • UE_BS_Identity notified from the AAA server 8a is added to the IKE_AUTH Response message in addition to the address of the T-PGW 5b conventionally transmitted from the AAA server 8a to the I-PGW 5a. It notifies the UE 1 (FIG. 20, step S13014).
  • the I-PGW 5a does not receive UE_BS_Identity from the AAA server 8a in step S13010, it may not be stored in this IKE_AUTH Response message.
  • FIG. 17B a format example of the IKE_AUTH Response message will be described using FIG. 17B as an example of a message transmitted by the T-PGW 5b to the UE 1 in step S13014 of FIG.
  • the T-PGW 5 b can provide a BS identifier (BS_Identity) field 3102 in addition to the conventional standard IKE_AUTH Response message 3101 and can notify the respective values to the UE 1. Also, Notify Payload defined in a standard IKEv2 protocol (see Non-Patent Document 7 above) may be added to a standard IKE_AUTH Response message to describe UE_BS_Identity etc. and notify the UE1. Note that this response message may be a message other than the IKE_AUTH Response message as long as it can transfer predetermined information, but may be sent simultaneously with the transmission of the IKE_AUTH Response message or later than the IKE_AUTH Response message. desirable.
  • BS_Identity BS identifier
  • the UE_I and the I-PGW 5a are mutually authenticated by the IKE_AUTH message exchange (FIG. 20, steps S13013, S13014) (eg, the IKE_SA_INIT message (the transmission source using the AUTH parameter stored in the IKE_AUTH message) I-PGW5a to UE1 after authenticating UE1 and PGW5 that are the same or after confirming the authentication method by confirming the correctness of the IKE_SA_INIT message (source UE1 and PGW5), etc.
  • the IKE_AUTH message exchange eg, the IKE_SA_INIT message (the transmission source using the AUTH parameter stored in the IKE_AUTH message)
  • I-PGW5a to UE1 after authenticating UE1 and PGW5 that are the same or after confirming the authentication method by confirming the correctness of the IKE_SA_INIT message (source UE1 and PGW5), etc.
  • the authentication of the UE 1 by the AAA server 8a succeeds (ie, the challenge information received in step S13009 AAA server 8a is UE1 based on Once) completing the authentication, it is also possible from the network side notifies the address of the T-PGW5b against UE1.
  • the address of the T-PGW 5b may be stored in an arbitrary message (for example, the message in step S13012) and notified to the UE1.
  • UE1 starts BS processing in order to establish an SA between UE1 and T-PGW 5b.
  • UE1 and T-PGW 5b perform IKE_SA_INIT message exchange between UE1 and T-PGW 5b to protect the IKE_AUTH message between UE1 and T-PGW 5b, and a shared key between UE1 and T-PGW 5b (eg, SKEYSEED) and the like are generated and obtained (FIG. 20, step S13101) (see the above-mentioned non-patent document 7).
  • UE 1 and T-PGW 5b After generating the shared key between UE1 and T-PGW 5b, UE 1 and T-PGW 5b generate keys (eg, SK_ei, SK_er) used for packet encryption using the shared key (the non-patent mentioned above) Reference 7 and Non-Patent Document 8).
  • keys eg, SK_ei, SK_er
  • the shared key the non-patent mentioned above
  • Reference 7 and Non-Patent Document 8 Non-Patent Document 8
  • a method of generating a key or the like used for packet encryption when a key or the like used for packet encryption can be generated using a method other than the IKE_SA_INIT message exchange, another method may be used.
  • UE1 creates an IKE_AUTH Request message, encrypts it using the key between UE1 and T-PGW 5b that was previously generated through IKE_SA_INIT message exchange, and sends it to T-PGW 5b.
  • UE1 and AAA which were necessary in the prior art, are required later.
  • the mutual authentication between the servers 8a (steps S13005 to S13009 in FIG. 20) and the generation of MSK (step S13010 in FIG. 20) can be omitted.
  • the UE 1 stores the Reuse Indicator indicating reuse of the previously generated MSK and the UE_BS_Identity received from the I-PGW 5a in the IKE_AUTH Request message and transmits it to the T-PGW 5b (FIG. 20, step S13102).
  • the Reuse indicator may generate the I-PGW 5a or the AAA server 8a or the like in the process of the bootstrap process between the UE 1 and the I-PGW 5a and notify the UE 1 of this.
  • the AAA server 8a generates and notifies the UE 1 so that the network system including the AAA server 8a or the AAA server 8a can make an assertion to the UE 1 to support or permit the reuse of the key.
  • UE 1 it is possible to request the reuse of the key with certainty, and in turn, it is possible to more reliably finish the switching connection with the desired T-PGW 5 b in a short time.
  • PGW 5 may remove the Reuse Indicator and not notify the UE 1.
  • the key reuse is supported or permitted in the home network (HPLMN: Home Public Land Mobile Network) of UE1, it is supported in the visited network (VPLMN: Visited Public Land Mobile Network) of UE1. It will be possible to cope with cases where it is not done or not allowed.
  • UE_BS_Identity enables the AAA server 8a to identify that it is BS processing from the UE 1 that has already completed mutual authentication with the AAA server 8a through the I-PGW 5a at the time of BS processing via the T-PGW 5b later. Is stored in the IKE_AUTH Request message. Reuse Indicator may be omitted if the purpose of Reuse Indicator can be achieved by using UE_BS_Identity. Conversely, if the purpose of UE_BS_Identity can be achieved by using Reuse Indicator, UE_BS_Identity may be omitted.
  • the message transmitted by the UE 1 to the T-PGW 5b in step S13102 of FIG. 20 is the message used in step 10102 of FIG. 14 in the third embodiment of the present invention (example format of IKE_AUTH Request message illustrated in FIG. 17A). Since it is the same as the above, the explanation is omitted. Also, Reuse Indicator or UE_BS_Identity may be described by adding Notify Payload or the like defined in the standard IKEv2 protocol (see Non-Patent Document 7 above) to a standard IKE_AUTH Request message and notified to UE1. . Note that this message may be a message other than the IKE_AUTH Request message as long as predetermined information can be transferred.
  • the T-PGW 5b transfers the Reuse indicator and UE_BS_Identity included in the IKE_AUTH Request message sent from the UE 1 to the AAA server 8a (FIG. 20, step S13103).
  • Reuse Indicator and UE_BS_Identity may be such that the UE 1 notifies the T-PGW 5 b through the IKE_SA_INIT message, and the T-PGW 5 b notifies the AAA server 8 a of the same parameter in parallel with the exchange of the IKE_SA_INIT message.
  • the message transmitted by the T-PGW 5b to the AAA server 8a in step S13103 of FIG. 20 is the message used in step S10103 of FIG. 14 in the third embodiment of the present invention (the Authentication-Request message illustrated in FIG. 18A).
  • the description is omitted because it is the same as the format example).
  • Reuse Indicator and UE_BS_Identity may be described in the existing payload of a standard Authentication-Request message, and notified to the AAA server 8a.
  • This message may be a message other than the Authentication-Request message as long as it can transfer predetermined information.
  • the AAA server 8a receives the Reuse indicator transferred from the T-PGW 5b, and determines that the reuse of MSK at the time of establishing the SA between the UE 1 and the I-PGW 5a is requested first, and the AAA server The MSK corresponding to UE_BS_Identity held by 8a is notified to the T-PGW 5b.
  • UE_BS_Identity may be replaced with a parameter (for example, IMSI or the like) that can confirm that the UE1 has already completed full authentication.
  • T-PGW_BS_Identity corresponding to UE_BS_Identity is also notified (FIG. 20, step S13104).
  • T-PGW_BS_Identity may be generated by the AAA server 8a itself, or when a database server (not shown) on the network holding the BS_Identity list is installed, the database server is inquired and the UE BS is checked. T-PGW BS_Identity corresponding to Identity may be acquired and used.
  • the T-PGW 5b notifies the AAA server 8a of its own information (for example, an IP address, an identifier of the PGW 5, etc.) through step S13103.
  • the AAA server 8a it can be confirmed that this connection request is a switching connection request to the T-PGW 5b instructed to the UE 1 earlier, and reuse of MSK can be correctly authorized.
  • the message transmitted by the AAA server 8a to the T-PGW 5b in step S13104 of FIG. 20 is the message used in step S10104 of FIG. 14 in the third embodiment of the present invention (the Authentication-Answer message shown in FIG. 18B).
  • the description is omitted because it is the same as the format example).
  • the response message may be a message other than the Authentication-Answer message as long as it can transfer predetermined information.
  • the T-PGW 5b notifies the UE 1 that the T-PGW_BS_Identity received from the AAA server 8a, the authentication success (the authentication of the UE 1 by the AAA server 8a), and the reuse of the MSK have been approved (FIG. 20). , Step S13105).
  • FIG. 17C is a diagram showing a format example of the IKE_AUTH Response message transmitted in step S13105 of FIG.
  • the T-PGW 5b can provide a BS identifier (UE_BS_Identity / T-PGW_BS_Identity) field 3202 and a Success Reuse Indicator field 3203, and can notify the respective values to the UE1.
  • BS identifier UE_BS_Identity / T-PGW_BS_Identity
  • T-PGW 5b adds Notify Payload defined in the standard IKEv2 protocol (see Non-Patent Document 7 above) to a standard IKE_AUTH Response message to indicate MSK reuse and T-PGW_BS_Identity. It may notify UE1. Alternatively, the UE 1 may be notified of MSK reuse by using the standard IKEv2 protocol EAP Success in the standard IKE_AUTH Response message. Note that this response message may be a message other than the IKE_AUTH Response message as long as the message enables the UE 1 to confirm MSK reuse.
  • This T-PGW_BS_Identity is used by the UE 1 to correctly identify that the AAA server 8a that has granted MSK reuse is the same node as previously authenticated the UE 1 when connecting to the I-PGW 5a.
  • the UE 1 confirms that the reuse of the MSK has been approved from the IKE_AUTH Response message sent from the T-PGW 5 b (for example, as judged from the value stored in the Success Reuse Indicator field 3203).
  • the UE 1 generates an AUTH parameter using the MSK generated in step S13013 of FIG.
  • the UE 1 stores the generated AUTH parameter in the IKE_AUTH Request message, and transmits it to the T-PGW 5 b (FIG. 20, step S 13106).
  • the UE1 when the UE1 does not hold or can not use the MSK generated when establishing the SA with the I-PGW 5a, for example, it may query the AAA server 8a or the like to acquire the MSK, or the UE1 You may generate the same MSK again by yourself.
  • the T-PGW 5b authenticates the UE 1 that has sent the IKE_AUTH Request message (eg, authenticates the IKE_SA_INIT message (the sender UE1) using the AUTH parameter stored in the IKE_AUTH Request message, or the IKE_SA_INIT message (at the sender) Confirmation of the authentication method by confirming the correctness of a certain UE 1), confirmation of the key, etc.
  • the T-PGW 5b transmits to the UE1 an IKE_AUTH Response message storing the AUTH parameter created using the MSK received from the AAA server 8a (FIG. 20, step S13107).
  • the T-PGW 5b creates the AUTH parameter in this step S13107 using the MSK sent from the AAA server 8a, if it can be stored, for example, step S13104 or later (MSK reception or later), at any timing. You may create it.
  • the UE 1 authenticates the T-PGW 5 b that has sent the IKE_AUTH Response message (eg, authenticates the IKE_SA_INIT message (the transmission source T-PGW 5 b) using the AUTH parameter stored in the IKE_AUTH Response message, or the IKE_SA_INIT message Confirmation of the authentication method by confirming the accuracy of the T-PGW 5b) that is the transmission source, confirmation of the key, etc.).
  • the AUTH parameter created by the UE 1 in step S13106 the key information acquired in step S13101 (for example, shared key, public key of communication partner, etc.) ) May be used.
  • the UE 1 When the UE 1 is able to authenticate the T-PGW 5b (eg, authenticate the IKE_SA_INIT message (the transmission source T-PGW 5b) using the AUTH parameter stored in the IKE_AUTH Response message, or the IKE_SA_INIT message (at the transmission source)
  • An SA is established between the UE 1 and the T-PGW 5 b, such as confirmation of an authentication method by confirming the correctness of a certain T-PGW 5 b), confirmation of a key, etc.
  • the IKE_AUTH Response message information necessary for the SA established between the UE 1 and the T-PGW 5 b is sent.
  • the T-PGW 5 b creates the AUTH parameter using the MSK in step S 13105 and notifies the UE 1 of the AUTH parameter first to authenticate the T-PGW 5 b first (for example, the AUTH parameter stored in the IKE_AUTH Response message) To authenticate the IKE_SA_INIT message (source T-PGW 5b), or to confirm the authentication method by confirming the accuracy of the IKE_SA_INIT message (source T-PGW 5b), or to confirm the key, etc. Then, the UE 1 may notify the T-PGW 5 b of the AUTH parameter.
  • authentication between the UE1 and the T-PGW 5b for example, authentication of the IKE_SA_INIT message (source UE1 or PGW5) using the AUTH parameter stored in the IKE_AUTH message, or IKE_SA_INIT message (source UE1) Or the confirmation of the authentication method by confirming the correctness of PGW 5), the confirmation of the key, etc.
  • one of UE 1 and T-PGW 5b authenticates (for example, using the AUTH parameter stored in the IKE_AUTH message)
  • By authenticating the IKE_SA_INIT message (sending source UE1 or PGW5) or confirming the authentication method by confirming the accuracy of the IKE_SA_INIT message (sending source UE1 or PGW5, etc., etc.) When SA can be established, or for processing load reduction of UE1 or T-PGW 5b, etc. , It may be only one only one to authenticate. Moreover, as long as it is possible to authenticate the UE 1 and the T-PGW 5
  • the UE 1 that has received the IKE_AUTH_Response message performs BU / BA exchange with the T-PGW 5 b (FIG. 20, step S 13201).
  • UE_BS_Identity and T-PGW_BS_Identity described above are useful for simple mutual authentication between UE 1 and AAA server 8a, when such mutual authentication is unnecessary or when mutual authentication can be performed separately. May omit these BS_Identities.
  • the AAA server 8a can hold the state for the UE 1 even after the instruction to switch to the T-PGW 5b, the Reuse Indicator notified by the UE 1 can be omitted.
  • the AAA server 8a identifies UE1 based on UE1's fixed information (for example, IMSI etc.) and extracts key data (for example, MSK etc.) based on the stored state for UE1. , T-PGW 5b can be notified.
  • IMSI etc. fixed information
  • MSK key data
  • T-PGW 5b can be notified.
  • the switching request of PGW5 with respect to UE1 precedes step S13014 explained above
  • the switching request of PGW5 with respect to UE1 precedes step S13014 explained above
  • the UE 1 includes the Reuse Indicator transmitted in step S13102 in the IKE AUTH Request message in step S13003 and transmits it.
  • the I-PGW 5a referring to this Reuse Indicator acquires the key already established for the UE 1 from the AAA server 8a in the process of steps S13004 to S13006 in the same procedure as steps S13103 and S13104 (at this time, simultaneously the switching destination). You will also get the PGW 5 address). Then, the I-PGW 5a transmits the IKE_AUTH response message (that is, the message equivalent to the IKE_AUTH response message transmitted in step S13105 described above) including the address of the switching destination PGW 5 in step S13007 to the UE1.
  • the IKE_AUTH response message that is, the message equivalent to the IKE_AUTH response message transmitted in step S13105 described above
  • the UE 1 can reuse the key established in the past to obtain the address of the switching destination PGW 5 at high speed, and even if the PGW 5 which is not originally intended to be connected is allocated, the switching connection to the desired PGW 5 Can be implemented at high speed.
  • the AAA server 8a may notify the T-PGW 5b of the generated MSK at the timing (FIG. 20, step S13010) instructing switching to the T-PGW 5b. Specifically, this will be described with reference to FIG.
  • FIG. 21 is a second sequence diagram for explaining an example of the system operation in the fourth embodiment of the present invention.
  • FIG. 21 is a UE authentication server that determines whether at least UE1 and I-PGW 5a that UE1 originally does not intend to connect and T-PGW 5b that UE1 originally wants to connect may use each access network by UE1.
  • An example of a processing sequence by a certain AAA server 8a and a user information data server HSS 8b is illustrated.
  • Steps S14001 to S14010 of the process flow of FIG. 21 are the same as steps S13001 to S13010 of the process flow of FIG.
  • the AAA server 8a can notify the T-PGW 5b of the MSK.
  • the process of transmitting the Authentication-Answer message storing the UE_BS_Identity to the I-PGW 5a simultaneously with the SA establishment process between the UE 1 and the I-PGW 5a.
  • the MSK generated in the process and T-PGW_BS_Identity corresponding to UE_BS_Identity are transmitted to the T-PGW 5b (FIG. 21, step S14011).
  • the message sent by the AAA server 8a to the T-PGW 5b in step S14011 of FIG. 21 is the message used in step S11011 of FIG. 15 in the third embodiment of the present invention (the format of the BS_Identity notification message shown in FIG. Since it is the same as that of the example), the description is omitted.
  • a conventional Authentication-Request / Identity message or the like may be extended and used as the BS_Identity notification message.
  • the BS_Identity notification message may include fixed information (for example, IMSI etc.) of the UE1, whereby when the T-PGW 5b receives the IKE_AUTH Request message from the UE1, the UE1 for which full authentication has been completed for the UE1.
  • the UE address field 5004 used in this IKE_AUTH Response message may be omitted.
  • Steps S14012 to S14102 of the processing flow of FIG. 21 are the same as steps S13011 to S13102 of the processing flow of FIG.
  • the T-PGW 5b that has received the IKE_AUTH Request message (FIG. 21, step S14102) in which the Reuse indicator and UE_BS_Identity are stored is the T-PGW_BS_Identity received from the AAA server 8a in step S14011 and the MSK re-establishment between UE1 and T-PGW 5b
  • An IKE_AUTH Response message storing a parameter indicating permission of use (for example, the value of the Success Reuse Indicator field 3203) is sent back to the UE 1 (FIG. 21, step S14103).
  • the T-PGW 5 b may check whether the UE_BS_Identity received in step S 14102 and the T-PGW_BS_Identity received in step S 14011 correspond correctly (eg, hash value verification, BS_Identity list on the network) Such as querying the database that manages Further, since the UE 1 holds the MSK generated when establishing the SA with the I-PGW 5a, the T-PGW 5b does not have to store and notify the MSK in the IKE_AUTH Response message transmitted in step S14103.
  • the T-PGW 5b stores the MSK in the IKE_AUTH Response message transmitted in step S14103. It may notify UE1 so that UE1 can grasp MSK certainly. Also, not the MSK but the material for generating the MSK may be notified.
  • the T-PGW 5b can provide a BS identifier (UE_BS_Identity / T-PGW_BS_Identity) field 3202 and a Success Reuse Indicator field 3203, and can notify the respective values to the UE1. Also, T-PGW 5b adds Notify Payload defined in the standard IKEv2 protocol (see Non-Patent Document 7 above) to a standard IKE_AUTH Response message to indicate MSK reuse and T-PGW_BS_Identity. It may notify UE1.
  • the UE 1 may be notified of MSK reuse by using the standard IKEv2 protocol EAP Success in the standard IKE_AUTH Response message.
  • this response message may be a message other than the IKE_AUTH Response message as long as the message enables the UE 1 to confirm MSK reuse.
  • an MSK field may be provided in this message (not shown).
  • the UE 1 having received the IKE_AUTH Response message determines, for example, from the value stored in the Success Reuse Indicator field 3203 of the IKE_AUTH Response message, whether or not the MSK generated when establishing an SA with the I-PGW 5a can be reused.
  • an AUTH parameter is created using the MSK generated when establishing the SA with the I-PGW 5 a.
  • the UE 1 transmits an IKE_AUTH Request message storing the created AUTH parameter to the T-PGW 5 b (FIG. 21, step S 14104).
  • UE1 notified I-PGW5a of the AUTH parameter before (in step S14014) it may reuse the AUTH parameter created at that time.
  • the T-PGW 5b Upon receiving the IKE_AUTH Request message, the T-PGW 5b creates an AUTH parameter using the MSK received from the AAA server 8a in step S14011. Subsequently, the T-PGW 5 b authenticates the UE 1 that has transmitted the IKE_AUTH Request message (eg, authenticates the IKE_SA_INIT message (the UE 1 that is the transmission source using the AUTH parameter stored in the IKE_AUTH Request message) or the IKE_SA_INIT message (Confirmation of the authentication method by confirming the correctness of the UE1 that is the transmission source, confirmation of the key, etc.)
  • the T-PGW 5 b When the T-PGW 5 b authenticates the UE 1 (for example, authenticates the IKE_SA_INIT message (the transmission source UE 1) using the AUTH parameter stored in the IKE_AUTH Request message, or the IKE_SA_INIT message (the transmission source UE 1) When the confirmation of the authentication method by confirming the correctness, the confirmation of the key, and the like are successful), the T-PGW 5b transmits an IKE_AUTH Response message to the UE 1 (FIG. 21, step S14105).
  • the T-PGW 5b authenticates the IKE_SA_INIT message (the transmission source UE1) using the authentication of the UE1 (for example, the AUTH parameter stored in the IKE_AUTH Request message, or the IKE_SA_INIT message (the transmission source UE1). After confirmation of the authentication method by confirming the correctness, confirmation of the key, etc.), the AUTH parameter created by the T-PGW 5b is stored in the IKE_AUTH Response message.
  • the T-PGW 5 b can authenticate the UE 1 without using the MSK sent from the AAA server 8 a (for example, using the AUTH parameter stored in the IKE_AUTH Request message, the IKE_SA_INIT message (the UE 1 serving as the transmission source) ) Or when confirmation of the authentication method by confirming the correctness of the IKE_SA_INIT message (source UE1) or when the key can be confirmed, even if the authentication method without MSK is used. Good.
  • the T-PGW 5b creates the AUTH parameter stored in this IKE_AUTH Response message in step S14105, but may create it at any timing after receiving the MSK from the AAA server 8a in step S14011.
  • T-PGW 5 b authenticates UE 1 (eg, authenticates the IKE_SA_INIT message (source UE 1) using the AUTH parameter stored in the IKE_AUTH Request message, or the IKE_SA_INIT message (source UE 1).
  • UE 1 authenticates the IKE_SA_INIT message (source UE 1) using the AUTH parameter stored in the IKE_AUTH Request message, or the IKE_SA_INIT message (source UE 1).
  • confirmation can be performed without using this AUTH parameter If so, other methods may be used to confirm the accuracy.
  • the UE 1 that has received the IKE_AUTH Response message authenticates the T-PGW 5 b that has sent the IKE_AUTH Response message (for example, using the AUTH parameter stored in the IKE_AUTH Response message, the IKE_SA_INIT message (the transmission source T-PGW 5 b Authentication, or confirmation of the authentication method by confirming the correctness of the IKE_SA_INIT message (T-PGW 5b that is the transmission source), key confirmation, etc.).
  • the UE 1 may use the AUTH parameter used in step S14104 or the key information acquired in step S14101 (for example, the shared key, the public key of the communication counterpart, etc.).
  • authentication of the T-PGW 5b by the UE 1 for example, authentication of the IKE_SA_INIT message (transmission source T-PGW 5b) using the AUTH parameter stored in the IKE_AUTH Response message) or IKE_SA_INIT message (transmission source T- Confirmation of the authentication method by confirming the correctness of PGW 5 b), confirmation of the key, etc.
  • authentication of UE 1 by T-PGW 5 b eg, IKE_SA_INIT message (transmission using the AUTH parameter stored in the IKE_AUTH Request message) If the SA can be established only by authenticating the original UE1) or confirming the authentication method by confirming the correctness of the IKE_SA_INIT message (source UE1) or the key confirmation, or It may be omitted to reduce processing load.
  • UE1 can authenticate T-PGW5b, without using MSK which UE1 has (For example, it can authenticate using UE_BS_Identity which UE1 has, and the presence or absence of T-PGW_BS_Identity which T-PGW5b has, etc. In the case of), a method of authentication without using MSK may be used.
  • the UE 1 performs BU / BA exchange with the T-PGW 5 b (FIG. 21, step S 14201).
  • the T-PGW 5 b acquires the MSK from the AAA server 8 a. Fast switching connection is possible.
  • the T-PGW 5 b When the T-PGW 5 b receives / processes the IKE_AUTH Request message from the UE 1 before the AAA server 8 a notifies the T-PGW 5 b of the MSK, the T-PGW 5 b again performs the full authentication process for the UE 1 as an AAA server. It will require 8a, which will increase the time required for connection. In order to avoid this, the UE 1 transmits an IKE_AUTH Request message including the Reuse indicator described in FIG. 14 to the T-PGW 5 b (FIG. 21, step S 14102), and the T-PGW 5 b must acquire the MSK from the AAA server 8 a. For example, the AAA server 8a may be inquired. As a result, MSK can be more reliably reused, and the switching connection can be speeded up.
  • UE_BS_Identity and T-PGW_BS_Identity described above perform simple mutual authentication between UE1 and AAA server 8a (for example, spoofed UE1 fake UE1 has unauthorized access to T-PGW 5b, UE1 and T Or, in the AAA server 8a, whether the connection request from the UE 1 this time is due to the switching connection to the T-PGW 5b instructed earlier, or the new PGW 5). It is useful to determine whether it is for connecting to or ensure that MSK reuse is performed. On the other hand, if such mutual authentication is not necessary, or if mutual authentication can be performed separately, APN (Access Point Name) etc.
  • APN Access Point Name
  • connection request from UE 1 in AAA 8a will be the previous connection request (via I-PGW 5a) If it is possible to confirm that the present connection request is due to switching to the T-PGW 5b or the like by a method such as comparison with the one notified in the above, these BS_Identities can be omitted.
  • UE_BS_Identity and T-PGW_BS_Identity described above are also useful when multiple PDN GW real locations occur. For example, when attach processing is performed with PGW (I-PGW 5a) which UE 1 discovered first, PDN GW reallocation occurs, and UE 1 receives the address of PGW 5 (I'-PGW) from I-PGW 5a. However, in the case of another PGW 5 different from the T-PGW 5 b to which the UE 1 tries to establish an SA again, the I′-PGW is different from the T-PGW 5 b to which the UE 1 is connected by 3G access 2.
  • UE 1 tries to establish an SA by reusing I′-PGW and MSK, but there is a possibility that the address of PGW 5 (T-PGW 5 b) is notified again from AAA server 8 a.
  • T-PGW 5 b the address of PGW 5
  • UE1 When this UE1 performs attach processing with T-PGW 5b, UE1 generates MSK generated when establishing SA with I-PGW 5a, or when establishing SA between UE1 and I'-PGW You may reuse MSK.
  • UE 1 may use UE_BS_Identity and T-PGW_BS_Identity to indicate which MSK to reuse.
  • the T-PGW 5b can obtain a key (for example, MSK) for the UE 1 from the AAA server 8a before receiving the IKE_AUTH Request message from the UE 1, and at this point, reuse the key. Since it can recognize, Reuse Indicator which UE1 notifies can also be omitted. However, as described above, it is also assumed that the notification from the AAA server 8a is delayed from the arrival of the IKE_AUTH Request message from the UE 1, and the key is reused for the T-PGW 5b instead of the process based on the conventional sequence. It is useful to add Reuse Indicator to promote processing based on sequence.
  • a key for example, MSK
  • the UE 1 may be notified of the address of the T-PGW 5b which is the switching destination PGW 5 during connection with the I-PGW 5a (step S9107 in FIG. 13). ).
  • the UE 1 executes steps S9108 to S9112 to eliminate the state of the AAA server 8a, but the authentication process (MSK generation) by the AAA server 8a in substantially this step section It is considered that the shortening of the processing time is generally larger if the authentication data (MSK etc.) is reused at the time of switching connection with the T-PGW 5b by completing the above.
  • Step S13008 of FIG. 20 (or Step S14008 of FIG. 21)
  • the authentication process may be continued without requesting the status cancellation of the AAA server 8a. That is, although the process after step S9108 in FIG. 13 is replaced with step S13008 in FIG. 20 (or in step S14008 in FIG. 21), the address of T-PGW 5b has already been sent to UE1 in step S13007 (or step S14007). Since the notification is made, it is not necessary to notify again in step S13014 of FIG. 20 (or step S14015 of FIG. 21).
  • the PDN GW reallocation occurs by reusing the shared key (for example, SKEYSEED etc.) (see the above non-patent document 7) generated between the UE1 and the PGW 5 other than reusing the MSK
  • the step of generating / acquiring the shared key or the like (for example, corresponding to step S13101 in FIG. 20) can be omitted.
  • PDN GW reallocation occurs, and UE1 establishes SA with I-PGW 5a (steps S13001 to S13014 in FIG. 20), and UE1 tries to establish SA with T-PGW 5b received from I-PGW 5a.
  • the step of generating the shared key between the UE 1 and the T-PGW 5b is omitted. be able to.
  • the UE 1 may simply notify the T-PGW 5b of a message indicating the reuse of the shared key and omit other messages. it can.
  • the shared key between UE1 and PGW5 for example, SKEYSEED etc.
  • MSK the shared key
  • the step of key generation may be omitted. In this case, by switching whether to newly generate or reuse a key, the security level is increased, and the possibility of information leakage by a node attempting to intercept key information between the UE 1 and the PGW 5 can be reduced.
  • UE1 stores an AUTH parameter created using MSK generated at the time of establishing SA with I-PGW 5a in the IKE_AUTH Request message (FIG. 20, step S13102) indicating reuse of MSK, and T -PGW 5b may be notified. Specifically, this will be described with reference to FIG.
  • FIG. 24 is a third sequence diagram for illustrating an example of system operation in the fourth embodiment of the present invention.
  • FIG. 24 is a UE authentication server that determines whether at least UE1 and I-PGW 5a that UE1 originally does not intend to connect and T-PGW 5b that UE1 originally wants to connect may use each access network by UE1.
  • An example of a processing sequence by a certain AAA server 8a and a user information data server HSS 8b is illustrated.
  • Steps S17001 to S17101 of the process flow of FIG. 24 are the same as steps S13001 to S13101 of the process flow of FIG.
  • the UE 1 transmits, to the T-PGW 5 b, an IKE_AUTH Request message including a Reuse Indicator or the like in which reuse of the MSK is indicated.
  • the UE 1 also stores the AUTH parameter created using the MSK generated when establishing the SA with the I-PGW 5 a and notifies the T-PGW 5 b of the AUTH parameter (FIG. 24, step S 17102).
  • T-PGW 5b indicates that, when it is confirmed that the AUTH parameter is stored in the IKE_AUTH Request message, UE 1 does not use EAP (Extended Authentication Protocol), but indicates a method of establishing SA using IKEv2 protocol in general. (See Non-Patent Document 7 mentioned above).
  • T-PGW 5b is the AAA server
  • An Authentication-Request message storing the Reuse Indicator and UE_BS_Identity received in step S17102 is sent to 8a (FIG. 24, step S17103).
  • T-PGW 5 b can confirm that UE 1 indicates MSK reuse by storing the AUTH parameter in the IKE_AUTH Request message and notifying T-PGW 5 b without using the Reuse Indicator.
  • Reuse Indicator can be omitted.
  • UE_BS_Identity can also be omitted when the AAA server 8a can acquire the MSK generated when the UE 1 establishes the SA with the I-PGW 5a by using the unique information (for example, IMSI etc.) of the UE 1 .
  • Step S17104 of the processing flow of FIG. 24 is the same as step S13104 of the processing flow of FIG.
  • the T-PGW 5 b that has received the MSK from the AAA server 8 a in step S 17104 authenticates the UE 1 that has sent the IKE_AUTH Request message in which the AUTH parameter is stored (for example, using the AUTH parameter stored in the IKE_AUTH Request message) Authentication of IKE_SA_INIT message (source UE1) or confirmation of authentication method by confirming correctness of IKE_SA_INIT message (source UE1), key confirmation, etc.
  • the T-PGW 5 b can authenticate the UE 1 without using the MSK received from the AAA server 8 a, it is not necessary to use the MSK. Further, in this case, the authentication process of the UE 1 may be performed after step S17102.
  • the T-PGW 5 b may use the MSK received from the AAA server 8 a, or may use the AUTH parameter calculated using the received MSK.
  • the T-PGW 5b calculates an AUTH parameter using the MSK received from the AAA server 8a, stores it in the IKE_AUTH Response message, and transmits it to the UE 1 (FIG. 24, step S17105).
  • the AUTH parameter may be calculated before authenticating UE1.
  • the T-PGW 5b stores the T-PGW_BS_Identity received together with the MSK in step S17104 in the IKE_AUTH Response message and transmits it to the UE1.
  • the UE 1 Upon receiving the IKE_AUTH Response message in which the AUTH parameter and the T-PGW_BS_Identity are stored, the UE 1 authenticates the T-PGW 5 b (for example, using the AUTH parameter stored in the IKE_AUTH Response message, the IKE_SA_INIT message (the sender T- Authentication of PGW 5b) or confirmation of authentication method by confirming accuracy of IKE_SA_INIT message (source T-PGW 5b), confirmation of key, etc.).
  • the UE 1 performs BU / BA exchange with the T-PGW 5 b (FIG. 24, step S 17201).
  • the AAA server 8a notifies the I-PGW 5a of the IP address of the T-PGW 5b (FIG. 21, step S14010) at the same time.
  • FIG. 25 is a fourth sequence diagram for illustrating an example of system operation in the fourth embodiment of the present invention.
  • FIG. 25 is a UE authentication server that determines whether at least UE1 and I-PGW 5a that UE1 originally does not intend to connect and T-PGW 5b that UE1 originally wants to connect may use each access network by UE1.
  • An example of a processing sequence by a certain AAA server 8a and a user information data server HSS 8b is illustrated.
  • Steps S18001 to S18101 of the process flow of FIG. 25 are the same as steps S14001 to S14101 of the process flow of FIG.
  • the UE 1 transmits, to the T-PGW 5 b, an IKE_AUTH Request message including a Reuse Indicator or the like in which reuse of the MSK is indicated.
  • the AUTH parameter created using the MSK generated when the UE 1 establishes the SA with the I-PGW 5a is stored and notified to the T-PGW 5b (FIG. 25, step S18102).
  • T-PGW 5 b can confirm that UE 1 indicates MSK reuse by storing the AUTH parameter in the IKE_AUTH Request message and notifying T-PGW 5 b without using the Reuse Indicator.
  • Reuse Indicator can be omitted.
  • T-PGW5b can confirm that the reuse of MSK generated when UE1 establishes SA with I-PGW5a by using unique information (for example, IMSI etc.) of UE1 can be confirmed.
  • UE_BS_Identity can also be omitted.
  • the T-PGW 5b Upon receiving the IKE_AUTH Request message including the AUTH parameter etc., the T-PGW 5b authenticates the IKE_SA_INIT message (the UE1 which is the transmission source) using the authentication of the UE1 (for example, using the AUTH parameter stored in the IKE_AUTH Request message, or IKE_SA_INIT The confirmation of the authentication method by confirming the correctness of the message (the transmission source UE1), the confirmation of the key, and the like are performed.
  • the T-PGW 5 b may use the MSK received from the AAA server 8 a, or may use the AUTH parameter calculated using the received MSK.
  • the T-PGW 5b may authenticate the UE1 using other than the MSK.
  • the T-PGW 5 b creates an AUTH parameter using the MSK received from the AAA server 8 a.
  • the AUTH parameter may be calculated before authenticating UE1. Then, the UE1 transmits, to the UE1, an IKE_AUTH Response message storing the created AUTH parameter, the parameter necessary for establishing the SA between the UE1 and the T-PGW 5b, and the like (FIG. 25, step S18103).
  • T-PGW 5b sets T-PGW_BS_Identity to It can be omitted.
  • the UE 1 Upon receipt of the IKE_AUTH Response message in which the AUTH parameters and the like are stored, the UE 1 authenticates the T-PGW 5b (for example, authenticates the IKE_SA_INIT message (the T-PGW 5b as the transmission source using the AUTH parameter stored in the IKE_AUTH Response message). Alternatively, the confirmation of the authentication method by confirming the correctness of the IKE_SA_INIT message (the transmission source T-PGW 5b), the confirmation of the key, etc. are performed. If the T-PGW 5 b has been authenticated, the UE 1 performs BU / BA exchange with the T-PGW 5 b (FIG. 25, step S 18201).
  • the AUTH parameter created using the MSK generated when the UE 1 establishes the SA with the I-PGW 5 a in step S 17102 or S 18102 is T-PGW 5 b.
  • the T-PGW 5b can determine that the UE 1 desires to establish an SA with the T-PGW 5b using the general IKEv2 protocol rather than the BS processing using the EAP. Also, by receiving Reuse Indicator or a parameter equivalent to Reuse Indicator, T-PGW 5b can confirm that UE 1 wishes to reuse MSK generated when SA is established with I-PGW 5a, AAA It becomes possible to transmit the AUTH parameter created using the MSK received from the server 8a to the UE1.
  • the UE 1 and the T-PGW 5b omit the messages (for example, steps S13106 to S13107 in FIG. 20 and steps S14104 to S14105 in FIG. 21) required in the process flow of FIG. Can be established.
  • the configuration of the mobile terminal (UE1) in the fourth embodiment of the present invention is the same as the configuration (see FIG. 3) of the mobile terminal (UE1) in the first to third embodiments of the present invention. I omit explanation.
  • FIGS. 22 and 26 are diagrams showing an example of the configuration of UE 1 in the fourth embodiment of the present invention, where UE 1 has already connected to 3G access 2 (home link) via the first wireless communication unit 101. And connected to the T-PGW 5b.
  • Steps S15001 to S15013 in the process flow of UE1 in FIG. 22 are the same as steps S12001 to S12013 in the process flow of UE1 in FIG.
  • the UE 1 checks whether the T-PGW_BS_Identity sent from the T-PGW 5 b and the T-PGW_BS_Identity generated / obtained by the UE 1 match or are related (step S 15014). Then, it is checked whether permission for reuse of the MSK (for example, whether or not EAP Success is stored in the IKE_AUTH Response message (step S13105 in FIG. 20, etc.)) is indicated (step S15105).
  • permission for reuse of the MSK for example, whether or not EAP Success is stored in the IKE_AUTH Response message (step S13105 in FIG. 20, etc.)
  • UE1 sends an AUTH parameter for sending to T-PGW 5b, I-PGW 5a and SA. Created using the generated MSK (step S15120). On the other hand, if they do not match, the UE 1 discards the received IKE_AUTH Response message (FIG. 22, step S 15040).
  • the UE 1 transmits an IKE_AUTH Request message storing the AUTH parameter generated in step S15120 to the T-PGW 5b (FIG. 22, step S15121). Then, the UE 1 receives the IKE_AUTH Response message sent from the T-PGW 5 b (FIG. 22, step S15122).
  • the UE 1 authenticates the T-PGW 5 b that transmitted the IKE_AUTH Response message in step S 15122 (eg, authenticates the IKE_SA_INIT message (T-PGW 5 b as the transmission source using the AUTH parameter stored in the IKE_AUTH Response message), or IKE_SA_INIT
  • the confirmation of the authentication method by confirming the correctness of the message (the transmission source T-PGW 5b), the confirmation of the key, etc. are performed (FIG. 22, step S15123).
  • the UE 1 can authenticate the T-PGW 5 b (for example, authenticate the IKE_SA_INIT message (the transmission source T-PGW 5 b) using the AUTH parameter stored in the IKE_AUTH Response message, or the IKE_SA_INIT message (the transmission source)
  • the BU / BA exchange with T-PGW 5b is performed (FIG. 22, step S15130).
  • the IKE_AUTH Response message received from the T-PGW 5 b is discarded (FIG. 22, step S 15040).
  • T-PGW 5b for example, when T-PGW_BS_Identity is stored
  • T-PGW 5b for example, an IKE_AUTH Response message, for example.
  • step S15123 can be omitted, and the BU / BA exchange is performed with the T-PGW 5b.
  • step S15123 may be omitted.
  • step S15030 If UE1 does not store the address of T-PGW 5b and UE_BS_Identity in the IKE_AUTH Response message received in step S15006, it means that switching of PGW 5 has not been requested, so the established SA
  • the BU-BA exchange with I-PGW 5a is performed using FIG. 22 (step S15030).
  • the UE 1 when the UE 1 notifies the T-PGW 5b of the AUTH parameter (for example, step S17102 in FIG. 24 and step S18102 in FIG. 25), After UE1 exchanges T-PGW 5b and IKE_SA_INIT message as shown in FIG. 26 (FIG. 26, step S19010), the Reuse Indicator is generated and the AUTH parameter is generated using MSK generated when SA is established with I-PGW 5a. Generate Note that the order in which steps S19011 and S19012 are processed may be reversed.
  • the UE 1 transmits an IKE_AUTH Request message storing the generated Reuse Indicator and the AUTH parameter to the T-PGW 5 b (FIG. 26, Step S19013).
  • the UE 1 authenticates the T-PGW 5b (FIG. 26, step S19015).
  • the UE 1 performs BU / BA exchange with the T-PGW 5 b (FIG. 26, step S19020).
  • the configuration of the PGW 5 in the fourth embodiment of the present invention is the same as the configuration (see FIG. 8) of the PGW 5 in the first to third embodiments of the present invention, and thus the description thereof is omitted.
  • connection control unit 205 that implements the characteristic process in the present invention will be mainly described using FIG. 23A, FIG. 23B and FIG. explain in detail.
  • the PGW 5 is already connected to the 3G access 2 (home link) via the communication unit 201.
  • PGW 5 which UE 1 first attempts to attach (connection) processing is assumed to be I-PGW 5 a.
  • FIG. 23A is a flow chart showing an example of a processing flow of the PGW 5 as the I-PGW 5 a in the fourth embodiment of the present invention.
  • the PGW 5 according to the present invention waits for BS processing from the UE 1 (for example, step S 13002, step S 13003, etc. in FIG. 20) to establish an SA with the UE 1.
  • the UE 1 starts attach processing with the I-PGW 5 a according to the connection procedure.
  • UE1 When UE1 connects to, for example, N3G access 3 and PGW 5 (I-PGW 5a) different from PGW 5 (T-PGW 5b) that UE 1 desires to connect is allocated from DNS etc., UE 1 attaches to I-PGW 5a ) PDN GW reallocation occurs according to the judgment of the network side (for example, AAA server 8 a or PGW 5 etc.) while processing (instruction to switch PGW 5 (for example, address of T-PGW 5 b etc.) is notified to UE 1) (FIG. 23A, step S16001).
  • the network side for example, AAA server 8 a or PGW 5 etc.
  • the AAA server 8a determines the PDN GW reallocation in step S9010 (or the previous step) in FIG. 14 and notifies the PGW of the address of the T-PGW 5b (above See Non-Patent Document 2). Therefore, also in the fourth embodiment of the present invention, for convenience of explanation, the AAA server 8a determines the PDN GW real location.
  • the I-PGW 5a receives the address of the T-PGW 5b to which the PGW 5 is switched, the MSK used between the UE1 and the I-PGW 5a, and the AAA server 8a once A certificate (for example, UE_BS_Identity etc.) that proves full authentication is received from the AAA server 8a (FIG. 23A, step S16002).
  • a certificate for example, UE_BS_Identity etc.
  • a certificate that proves that the AAA server 8a has fully authenticated the UE 1 once is taken as UE_BS_Identity.
  • the I-PGW 5a authenticates the UE 1 (for example, authenticates the IKE_SA_INIT message (the transmission source UE 1) using the AUTH parameter stored in the IKE_AUTH Request message, or the IKE_SA_INIT message (the transmission source UE 1) In order to confirm the authentication method by confirming the correctness of the key, to confirm the key, etc. (step S13013 in FIG.
  • the UE 1 authenticates the I-PGW 5a (for example, the AUTH parameter stored in the IKE_AUTH Request message) In order to authenticate the IKE_SA_INIT message (source UE1) using the or to confirm the authentication method by confirming the correctness of the IKE_SA_INIT message (source UE1), the key, etc.
  • the AUTH parameter is created using the MSK received from the server 8a (FIG. 23A, step S160) 3).
  • the I-PGW 5 b authenticates the UE 1 (for example, authenticates the IKE_SA_INIT message (the transmission source UE 1) using the AUTH parameter stored in the IKE_AUTH Request message, or the accuracy of the IKE_SA_INIT message (the transmission source UE 1) If an authentication method is confirmed or a key is confirmed, the address of the T-PGW 5b and an IKE_AUTH Response message storing UE_BS_Identity are transmitted to the UE 1 (FIG. 23A, step S16004).
  • FIG. 23B is a flow chart showing an example of a processing flow of the PGW 5 as the T-PGW 5 b in the fourth embodiment of the present invention.
  • the UE 1 that has received the address of the T-PGW 5b detects that PDN GW reallocation has occurred. Subsequently, the UE 1 transmits an IKE_SA_INIT message to start an attach (connection) process with the T-PGW 5 b.
  • the T-PGW 5b receives the IKE_SA_INIT message sent from the UE 1 (FIG. 23B, step S16010). Subsequently, the T-PGW 5 b uses the nonces stored in the IKE_SA_INIT message and the shared key (for example, SKEYSEED) generated and acquired by the Diffie-Hellman key exchange performed at the time of the IKE_SA_INIT message exchange.
  • a key for example, SK_ei or SK_er
  • encrypting a packet used between the PGW 5b is generated (FIG. 23B, step S16011).
  • parameters for example, each other's public key, etc.
  • parameters for example, each other's public key, etc.
  • the key generation used between the UE 1 and the T-PGW 5 b may use keys other than those shared by the Nonces and Diffie-Hellman key exchanges, and is not limited to these.
  • the T-PGW 5b receives the IKE_AUTH Request message sent from the UE 1 (FIG. 23B, step S16012).
  • the T-PGW 5 b corresponds to a value (for example, Reuse key etc.) indicating reuse of MSK stored in Reuse Indicator field 3002 of the IKE_AUTH Request message received from UE 1 or a value indicating reuse of MSK. Are stored (FIG. 23B, step S16013).
  • Authentication-Request / Identity message storing Reuse key and UE_BS_Identity received in step S16012 is stored in AAA. It transmits to the server 8a (FIG. 23B, step S16100).
  • the AAA server 8a transmits the MS_K and T-PGW_BS_Identity corresponding to UE_BS_Identity sent from the T-PGW 5b to the T-PGW 5b.
  • a key (for example, SK_e, SK_i, etc.) used for data encryption etc. is transferred from the I-PGW 5a to the AAA server 8a, and a key used for data encryption etc.
  • the key information (for example, SK_e, SK_i, etc.) may also be sent to the T-PGW 5b at the same time as long as it is determined that the key information may be reused.
  • the T-PGW 5 b receives, from the AAA server 8 a, an Authentication_Answer message in which the MSK, the T-PGW_BS_Identity, and the like are stored (FIG. 23B, step S 16101). Subsequently, the T-PGW 5b creates an AUTH parameter using the MSK received from the AAA server 8a (FIG. 23B, step S16102). At the same time as indicating that MSK can be reused, the T-PGW 5b transmits to the UE 1 an IKE_AUTH Response message storing T-PGW_BS_Identity for the purpose of preventing spoofing of the T-PGW 5b, etc. (FIG. 23B, step S16103). .
  • the UE 1 After confirming that the MSK can be reused, the UE 1 creates an AUTH parameter using the MSK that the UE 1 has. Subsequently, the UE 1 transmits an IKE_AUTH Request message storing the AUTH parameter to the T-PGW 5 b. The T-PGW 5b receives the IKE_AUTH Response message from the UE 1 (FIG. 23B, step S16104).
  • the T-PGW 5 b authenticates the UE 1 that has sent the IKE_AUTH Response message (eg, authenticates the IKE_SA_INIT message (the UE 1 that is the sender) using the AUTH parameter stored in the IKE_AUTH Request message, or the IKE_SA_INIT message (Confirmation of the authentication method by confirming the correctness of the UE 1 as the transmission source, confirmation of the key, etc.) (FIG. 23B, step S16105).
  • the T-PGW 5b may use the AUTH parameter created in step S16102 as a comparison target.
  • UE1 is authenticated (for example, IKE_SA_INIT message (UE1 which is a transmission source) is authenticated using the AUTH parameter stored in the IKE_AUTH Request message. Alternatively, it may be generated immediately before the confirmation of the authentication method by confirming the correctness of the IKE_SA_INIT message (the transmission source UE 1), the confirmation of the key, and the like.
  • the AUTH parameter may be generated immediately before the step S16200 at which the T-PGW 5b transmits the AUTH parameter to the UE 1.
  • T-PGW 5b authenticates the IKE_SA_INIT message (source UE1) using the authentication of UE1 (for example, the AUTH parameter stored in the IKE_AUTH Request message, or the accuracy of the IKE_SA_INIT message (source UE1)
  • the T-PGW 5b transmits an IKE_AUTH Response message including the AUTH parameter and the like created in step S16102 to the UE 1 (FIG. 23B, step S16200).
  • the T-PGW 5 b performs BU / BA exchange with the UE 1 (FIG. 23B, step S16201).
  • the T-PGW 5 b can not authenticate the UE 1, the BS process is ended.
  • the T-PGW 5b is notified of the AUTH parameter by the IKE_AUTH Request message from the UE 1 immediately after the IKE_SA_INIT message exchange (for example, in FIG. 24).
  • the T-PGW 5b checks whether the AUTH parameter is stored in the IKE_AUTH Request message sent from the UE 1 (FIG. 27, step S20013).
  • the T-PGW 5b transmits, to the AAA server 8a, an Authentication-Request message storing the Reuse key and the UE_BS_Identity received from the UE 1 (FIG. 27, step S20100).
  • the T-PGW 5b receives, from the AAA server 8a, an Authentication-Response message in which the MSK and the T-PGW_BS_Identity are stored (FIG. 27, step S20101).
  • the T-PGW 5b creates an AUTH parameter using the received MSK (FIG. 27, step S20102).
  • the T-PGW 5b authenticates the UE 1 (FIG. 27, step S20103).
  • UE1 may be authenticated using the MSK received in step S20101 or the AUTH parameter generated in step S20102 (for example, the AUTH parameter sent from UE1 and the T-PGW 5b) Such as comparing generated AUTH parameters).
  • the processing order of step S 20102 and step S 20103 may be switched.
  • an IKE_AUTH Response message storing the AUTH parameter and T-PGW_BS_Identity generated by the T-PGW 5 b is transmitted to the UE 1 (FIG. 27, step S 20110). Subsequently, the T-PGW 5 b performs BU / BA exchange with the UE 1 (FIG. 27, step S20111).
  • PGW 5 (corresponding to I-PGW 5 a) different from PGW 5 (corresponding to T-PGW 5 b) already established by UE 1 is assigned, and Also, compared to the prior art PDN GW reallocation procedure, the switch connection to the T-PGW 5b can be completed in a short time. That is, UE1 and T-PGW 5b reuse MSK created at the time of SA establishment of UE1 and I-PGW 5a to establish SA between UE1 and T-PGW 5b, whereby UE1 can obtain desired PGW 5 (T- Connection with PGW 5 b) can be established in a short time.
  • the MSK used in the fourth embodiment of the present invention is the same as the MSK defined in RFC by the Internet Engineering Tast Force (IETF), which is an organization that standardizes the technology used on the Internet. It may be defined separately.
  • IETF Internet Engineering Tast Force
  • the UE 1 performs T_IKE_AUTH_Request message storing Reuse Indicator and UE_BS_Identity. -It is desirable to send to PGW 5b.
  • the BS_Identity notification (FIG. 21, step S14011) from the AAA server 8a to the T-PGW 5b is delayed or lost, and the T-PGW 5b reuses key data (MSK) (omission of full authentication).
  • MSK key data
  • the AAA server 8a notifies the T-PGW 5b of information such as MSK in advance in the second sequence illustrated in FIG. 21, the BS_Identity notification from the AAA server 8a to the T-PGW 5b (FIG. If it is guaranteed that the system does not delay or lose step S14011) as a system, UE1 uses Reuse Indicator instead of Reuse Indicator, as shown in FIG. It does not have to be generated in step S15011 or stored in the IKE_AUTH_Request message in step S15012.
  • this connection request is made by a method such as comparing the APN (Access Point Name) and the like included in the connection request from the UE 1 in the AAA server 8a with the one notified by the previous connection request (via I-PGW 5a).
  • APN Access Point Name
  • UE_BS_Identity is no longer required, and notification to UE1 is not performed in step S15007 in FIG.
  • the UE 1 may execute the standard BS processing on the T-PGW 5 b (not shown in FIG. 22), whereby the reuse of the MSK is performed by the judgment on the network side, and to the T-PGW 5 b. Switching connection can be completed in a short time.
  • UE_BS_Identity and T-PGW_BS_Identity used in the fourth embodiment of the present invention, various combinations are possible as in the first embodiment described above. That is, in the fourth embodiment of the present invention, UE_BS_Identity may be compared with T-PGW_BS_Identity using, for example, UE_BS_Identity and T-PGW_BS_Identity corresponding to this UE_BS_Identity, either one of the BS_Identities may be performed. May be used, or BS_Identity may not be used.
  • UE_BS_Identity and T-PGW_BS_Identity for example, a hash value generated based on a value shared by UE1 and PGW5, or randomly generated It is possible to use a value (code) that can be recognized by UE1 and PGW5, such as the determined value or the address of the I-PGW 5a (but not limited to these). Also in the fourth embodiment of the present invention, UE_BS_Identity and T-PGW_BS_Identity may be generated by the PGW 5, the AAA server 8a, or another communication device.
  • LSI Large Scale Integration
  • IC Integrated Circuit
  • super LSI ultra LSI depending on the degree of integration.
  • the method of circuit integration is not limited to LSI's, and implementation using dedicated circuitry or general purpose processors is also possible.
  • a programmable field programmable gate array FPGA
  • a reconfigurable processor that can reconfigure connection and setting of circuit cells in the LSI may be used.
  • the gateway connection method, the gateway connection control system, and the mobile terminal of the present invention can reliably and quickly unify PGW 5 which manages CoAs of mobile terminals using a plurality of CoAs.
  • the mobile terminal can It has the effect of being able to reap the benefits of communication using multiple CoAs reliably and quickly, and a mobile terminal having multiple communication interfaces can use these multiple communication interfaces via different access networks. It is applicable to the technology to access a given gateway.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne une technologie qui permet, lorsqu'un équipement utilisateur doté de multiples interfaces de communication se connecte à un réseau d'accès, une connexion de l'équipement utilisateur à une PGW cible rapidement et en peu de temps, même dans les cas où une PGW autre que la PGW souhaitée a été attribuée. Grâce à la technologie, lorsque l'équipement utilisateur (UE) (1) effectue un traitement d'amorçage (BS) sur un réseau d'accès (accès N3G (3)), le point d'accès PGW (I-PGW (5a)) est notifié de l'adresse d'une autre interface de communication qui est déjà connectée à une PGW cible (T-PGW (5b)). Si la I-PGW ne gère pas cette adresse, le traitement est effectué de façon à commencer le traitement BS à partir de la T-PGW qui gère cette adresse sur l'équipement utilisateur. De plus, si l'équipement utilisateur est connecté à une I-PGW non cible par un accès N3G, lorsque la connexion passe de l'I-PGW à la T-PGW cible, une demande est effectuée pour réutiliser la clé qui a été échangée avec l'I-PGW.
PCT/JP2010/000551 2009-02-13 2010-01-29 Procédé de connexion à une passerelle, système de contrôle d'une connexion à une passerelle, et équipement utilisateur WO2010092764A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/201,042 US20120020343A1 (en) 2009-02-13 2010-01-29 Gateway connection method, gateway connection control system, and user equipment
JP2010550437A JPWO2010092764A1 (ja) 2009-02-13 2010-01-29 ゲートウェイ接続方法及びゲートウェイ接続制御システム並びに移動端末

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
JP2009031883 2009-02-13
JP2009-031883 2009-02-13
JP2009061990 2009-03-13
JP2009-061990 2009-03-13
JP2009193595 2009-08-24
JP2009-193595 2009-08-24

Publications (1)

Publication Number Publication Date
WO2010092764A1 true WO2010092764A1 (fr) 2010-08-19

Family

ID=42561613

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/000551 WO2010092764A1 (fr) 2009-02-13 2010-01-29 Procédé de connexion à une passerelle, système de contrôle d'une connexion à une passerelle, et équipement utilisateur

Country Status (3)

Country Link
US (1) US20120020343A1 (fr)
JP (1) JPWO2010092764A1 (fr)
WO (1) WO2010092764A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012060021A1 (fr) * 2010-11-05 2012-05-10 Telefonaktiebolaget L M Ericsson (Publ) Serveur d'enregistrement, appareil passerelle et procédé permettant de fournir une valeur secrète à des dispositifs
WO2013004905A1 (fr) * 2011-07-07 2013-01-10 Nokia Corporation Accès de confiance à un réseau local sans fil
KR101338486B1 (ko) 2010-12-21 2013-12-10 주식회사 케이티 Ｉ-ｗｌａｎ의 게이트웨이 및 그의 호 추적 방법
JP2020511095A (ja) * 2017-03-17 2020-04-09 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 通信ネットワーク内での使用のためのネットワークノード、通信デバイス、およびそれらを動作させる方法
JP2022515681A (ja) * 2019-01-11 2022-02-21 日本電気株式会社 通信ネットワークにおける鍵再利用を可能にするための方法及び装置

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101718096B1 (ko) * 2009-12-01 2017-03-20 삼성전자주식회사 무선통신 시스템에서 인증방법 및 시스템
CN102196407B (zh) * 2010-03-18 2015-09-16 中兴通讯股份有限公司 锚定鉴权器重定位方法及系统
WO2013164465A1 (fr) * 2012-05-04 2013-11-07 Telefonaktiebolaget L M Ericsson (Publ) Procédé et appareil de gestion des connexions pdn
RU2621973C2 (ru) * 2013-01-04 2017-06-08 Хуавэй Текнолоджиз Ко., Лтд. Способ, устройство и система для выбора pdn-шлюза
EP3086599A4 (fr) * 2013-12-20 2017-06-07 Kyocera Corporation Procédé de commande de la communication, dispositif passerelle et terminal utilisateur
JP2015194947A (ja) * 2014-03-31 2015-11-05 ソニー株式会社 情報処理装置及びコンピュータプログラム
CN105338511B (zh) * 2014-06-25 2019-08-16 华为技术有限公司 网络拓扑隐藏方法和设备
WO2016169003A1 (fr) * 2015-04-22 2016-10-27 华为技术有限公司 Procédé, appareil et système permettant d'autoriser un nom de point d'accès
US11223507B2 (en) * 2017-04-18 2022-01-11 Qualcomm Incorporated Payload with synchronization information
CN112514436B (zh) * 2018-08-02 2024-04-19 瑞典爱立信有限公司 发起器和响应器之间的安全的、被认证的通信
US11032743B1 (en) * 2019-11-30 2021-06-08 Charter Communications Operating, Llc Methods and apparatus for supporting devices of different types using a residential gateway
WO2023226956A1 (fr) * 2022-05-25 2023-11-30 华为技术有限公司 Dispositif réseau et système de communication

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008045438A1 (fr) * 2006-10-10 2008-04-17 Lucent Technologies Inc. Procédé de transfert de paquet pour ip mobile de proxy
WO2008063488A1 (fr) * 2006-11-20 2008-05-29 Lucent Technologies, Inc. Optimisation d'un trajet à mobilité régulée par le réseau pour architecture d'émetteur-récepteur d'une station de base ip

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3688830B2 (ja) * 1995-11-30 2005-08-31 株式会社東芝 パケット転送方法及びパケット処理装置
JPH10178421A (ja) * 1996-10-18 1998-06-30 Toshiba Corp パケット処理装置、移動計算機装置、パケット転送方法及びパケット処理方法
US20070208864A1 (en) * 2002-10-21 2007-09-06 Flynn Lori A Mobility access gateway
US7499401B2 (en) * 2002-10-21 2009-03-03 Alcatel-Lucent Usa Inc. Integrated web cache
CN1265607C (zh) * 2003-12-08 2006-07-19 华为技术有限公司 无线局域网中业务隧道建立的方法
DE102004045147A1 (de) * 2004-09-17 2006-03-23 Fujitsu Ltd., Kawasaki Einstellungsinformations-Verteilungsvorrichtung, Verfahren, Programm und Medium, Authentifizierungseinstellungs-Transfervorrichtung, Verfahren, Programm und Medium und Einstellungsinformations-Empfangsprogramm
TWI305462B (en) * 2005-12-29 2009-01-11 Ind Tech Res Inst Method and system for secure authentication in a wireless network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008045438A1 (fr) * 2006-10-10 2008-04-17 Lucent Technologies Inc. Procédé de transfert de paquet pour ip mobile de proxy
WO2008063488A1 (fr) * 2006-11-20 2008-05-29 Lucent Technologies, Inc. Optimisation d'un trajet à mobilité régulée par le réseau pour architecture d'émetteur-récepteur d'une station de base ip

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012060021A1 (fr) * 2010-11-05 2012-05-10 Telefonaktiebolaget L M Ericsson (Publ) Serveur d'enregistrement, appareil passerelle et procédé permettant de fournir une valeur secrète à des dispositifs
CN103190130A (zh) * 2010-11-05 2013-07-03 瑞典爱立信有限公司 用于向设备提供秘密值的注册服务器、网关装置和方法
US9154487B2 (en) 2010-11-05 2015-10-06 Telefonaktiebolaget L M Ericsson (Publ) Registration server, gateway apparatus and method for providing a secret value to devices
KR101338486B1 (ko) 2010-12-21 2013-12-10 주식회사 케이티 Ｉ-ｗｌａｎ의 게이트웨이 및 그의 호 추적 방법
WO2013004905A1 (fr) * 2011-07-07 2013-01-10 Nokia Corporation Accès de confiance à un réseau local sans fil
JP2020511095A (ja) * 2017-03-17 2020-04-09 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 通信ネットワーク内での使用のためのネットワークノード、通信デバイス、およびそれらを動作させる方法
JP2022515681A (ja) * 2019-01-11 2022-02-21 日本電気株式会社 通信ネットワークにおける鍵再利用を可能にするための方法及び装置
JP7456444B2 (ja) 2019-01-11 2024-03-27 日本電気株式会社 ネットワーク装置の方法
US12107950B2 (en) 2019-01-11 2024-10-01 Nec Corporation Method and a device for enabling key re-usage in a communication network

Also Published As

Publication number Publication date
US20120020343A1 (en) 2012-01-26
JPWO2010092764A1 (ja) 2012-08-16

Similar Documents

Publication Publication Date Title
WO2010092764A1 (fr) Procédé de connexion à une passerelle, système de contrôle d'une connexion à une passerelle, et équipement utilisateur
US8964695B2 (en) Optimization of handovers to untrusted non-3GPP networks
JP5554342B2 (ja) アクセスネットワークへの接続又はハンドオーバの後のセキュアトンネルの確立
US7805605B2 (en) Server, terminal control device and terminal authentication method
JP4291272B2 (ja) ホームエージェントと共に移動ノードのホームアドレスを登録する方法
EP2774402B1 (fr) Sécurisation de communications de données dans un réseau de communication
US9686669B2 (en) Method of configuring a mobile node
KR102390380B1 (ko) 비인증 사용자에 대한 3gpp 진화된 패킷 코어로의 wlan 액세스를 통한 긴급 서비스의 지원
US20040157585A1 (en) Mobile communication network system and mobile terminal authentication method
JP2010530680A (ja) モバイルノードのためのアクセスネットワーク−コアネットワーク間信頼関係検出
EP2151142B1 (fr) Procédés et appareil pour envoyer des paquets de données à destination/en provenance de noeuds mobiles
EP2218270A2 (fr) Système et procédé pour authentifier un transfert de contexte
CN102007752A (zh) 当改变了移动性管理方案时的归属代理发现
JP4768720B2 (ja) ネットワークにアクセスするユーザ端末に対してジェネリック認証アーキテクチャーを応用して管理する方法及びシステム
US20070242638A1 (en) Fast Network Attachment
EP2241074A1 (fr) Procédé et appareil à utiliser dans un réseau de communications
TWI627870B (zh) 通訊系統中閘道器節點之選擇
EP2235892A1 (fr) Procédé et appareil destinés à rediriger un agent local
KR100879986B1 (ko) 모바일 네트워크 시스템 및 그 시스템의 핸드오버 방법
Kulkarni et al. Mobile IPv4 dynamic home agent (HA) assignment
US9137661B2 (en) Authentication method and apparatus for user equipment and LIPA network entities
Laurent-Maknavicius et al. Inter-domain security for mobile Ipv6
KR101588646B1 (ko) 무선통신시스템의 인증 방법 및 시스템
Liu et al. The untrusted handover security of the S-PMIPv6 on LTE-A
KR20080099991A (ko) 이동통신 시스템에서 프록시 이동 인터넷 프로토콜을이용한 이동 단말의 이동성 관리 방법 및 시스템

Legal Events

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

Ref document number: 10741044

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010550437

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13201042

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 10741044

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载