Method and device for avoiding key mismatch under condition of parallel authentication

Abstract

Methods, apparatus, and computer readable media for avoiding key mismatch in the case of parallel authentication are disclosed. A method performed at a user equipment (UE) includes receiving, from a network node, a request to perform authentication with a home network (HN) of the UE over a first mobile communication network connection of the UE; determining whether there is another authentication performed with the HN on a second mobile communication network connection for the UE; and there is another authentication performed with the HN on the second mobile communication network connection, delaying authentication on the first mobile communication network connection or denying the request.

Description

Technical Field

[0001] Embodiments of the present disclosure generally relate to the security of cellular communication terminals and mobile communication networks, and more particularly to methods and apparatuses for avoiding key mismatches between a cellular communication terminal and its home network in the case of parallel authentication. Background Art

[0002] Before initiating communication with a cellular communication network (such as a fifth generation (5G) system), a cellular communication terminal (also referred to as a user equipment (UE)) needs to perform a primary authentication and register with its home public land mobile network (HPLMN). The primary authentication can achieve mutual authentication between the UE and the HN, and provide key materials, including a key K that can be used between the UE and the HPLMN (and the UE's serving network) in subsequent security processes. AUSF and other keys derived from K AUSF The key K AUSF is established between the UE and the HPLMN according to the primary authentication process. It is stipulated in the protocol that the UE and the HPLMN should use the latest K AUSF resulting from a successfully completed latest primary authentication, regardless of the access network type (3GPP or non-3GPP GPP) on which it is generated.

[0003] However, there remains a possibility that two separate security processes are executed in parallel on two different non-access stratum (NAS) connections between the UE and the HPLMN. Running two separate security processes concurrently in parallel may lead to a race condition and a mismatch between the security contexts in the UE and the HPLMN. The security context is created by the primary authentication. In this case, which K AUSF from separate primary authentications for two different NAS connections is considered the latest one in the HPLMN and the UE is a problem. Summary of the Invention

[0004] This Summary of the Invention is provided to introduce a simplified concept of the present invention. This Summary of the Invention is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0005] According to a first aspect of the present disclosure, there is provided an apparatus at a user equipment (UE). The apparatus includes at least one processor and at least one memory storing instructions which, when executed on the at least one processor, cause the apparatus to at least: receive, from a network node, a request to perform authentication with a home network (HN) of the UE on a first mobile communication network connection of the UE; determine whether there is another authentication being performed with the HN on a second mobile communication network connection for the UE; and when there is another authentication with the HN being performed on the second mobile communication network connection, delay the authentication on the first mobile communication network connection or reject the request.

[0006] According to a second aspect of the present disclosure, there is provided an apparatus at a unified data management (UDM) node in a home network (HN) of a user equipment (UE). The apparatus includes at least one processor and at least one memory storing instructions which, when executed on the at least one processor, cause the apparatus to at least: receive, from an authentication server function (AUSF) node, a request to extract an authentication vector for authentication between the HN and the UE on a first mobile communication network connection of the UE; determine whether there is another authentication being performed with the HN on a second mobile communication network connection for the UE; and when there is another authentication with the HN being performed on the second mobile communication network connection, delay the extraction of the authentication vector or reject the request.

[0007] According to a third aspect of the present disclosure, there is provided a method performed at a user equipment (UE). The method includes: receiving, from a network node, a request to perform authentication with a home network (HN) of the UE on a first mobile communication network connection of the UE; determining whether there is another authentication being performed with the HN on a second mobile communication network connection for the UE; and when there is another authentication with the HN being performed on the second mobile communication network connection, delaying the authentication on the first mobile communication network connection or rejecting the request.

[0008] According to a fourth aspect of the present disclosure, there is provided a method performed at a unified data management (UDM) node in a home network (HN) of a user equipment (UE). The method includes: receiving, from an authentication server function (AUSF) node, a request to extract an authentication vector for authentication between the HN and the UE on a first mobile communication network connection; determining whether there is another authentication being performed with the HN on a second mobile communication network connection for the UE; and when there is another authentication with the HN being performed on the second mobile communication network connection, delaying the extraction of the authentication vector or rejecting the request.

[0009] According to a fifth aspect of the present disclosure, there is provided a computer-readable storage medium having instructions stored thereon, which when executed by at least one processor, cause the at least one processor to execute the method according to any one of the third aspects.

[0010] According to a sixth aspect of the present disclosure, there is provided a computer program product including instructions which, when executed by at least one processor, cause the at least one processor to execute the method according to any one of the fourth aspects.

[0011] According to a seventh aspect of the present disclosure, there is provided a device implemented at an Authentication and Key Management of Application Anchor Function (AAnF). The device includes at least one processor and at least one memory storing instructions which, when executed by at least one processor, cause the device to at least: receive, from an Authentication Server Function (AUSF) node, first Application Authentication and Key Management (AKMA) key material for an application of a User Equipment (UE) and a first identifier of a first Serving Public Land Mobile Network (PLMN) or a first Serving Standalone Non-Public Network (SNPN) that provides a first mobile communication network connection for the application; store the first AKMA key material according to the PLMN or SNPN based on the first identifier; receive, from the AUSF node, second AKMA key material for the application and a second identifier of a second Serving PLMN or a second Serving SNPN that provides a second mobile communication network connection for the application; store the second AKMA key material according to the PLMN or SNPN based on the second identifier, and retain the stored first AKMA key material; receive, from an Application Function (AF) node, a request for an application key for the application of the UE, wherein the request indicates an identifier of the PLMN or SNPN; select AKMA key material from the first AKMA key material and the second AKMA key material according to the identifier of the PLMN or SNPN indicated by the request; and provide an application key corresponding to the selected AKMA key material to the AF node.

[0012] According to an eighth aspect of the present disclosure, there is provided a device implemented at an Application Function (AF) node. The device includes: at least one processor and at least one memory storing instructions which, when executed by the at least one processor, cause the device to at least: receive a session request for a requested application from a User Equipment (UE); determine an identifier of a Serving Public Land Mobile Network (PLMN) or a Serving Standalone Non-Public Network (SNPN) that provides a mobile communication network connection for the session; and send a request for an application key for the session to the Authentication and Key Management of an Application Anchor Function (AAnF) node. The request indicates the identifier of the Serving PLMN or the Serving SNPN.

[0013] According to a ninth aspect of the present disclosure, another apparatus implemented at a user equipment (UE) is provided. The apparatus includes: at least one processor and at least one memory storing instructions which, when executed by the at least one processor, cause the apparatus to at least: send a session request for a session from an application function (AF) node. The request includes an identifier of a serving public land mobile network (PLMN) or a serving standalone non-public network (SNPN) that provides a mobile communication network connection for the session.

[0014] According to a tenth aspect of the present disclosure, a method performed at a function authentication and key management of an application anchor node (AAnF) is provided. The method includes: receiving, from an authentication server function (AUSF) node, first authentication and application key management (AKMA) key material for an application of a user equipment (UE) and a first identifier of a first serving public land mobile network (PLMN) or a first serving standalone non-public network (SNPN) that provides a first mobile communication network connection for the application; storing the first AKMA key material according to the PLMN or SNPN based on the first identifier; receiving, from the AUSF node, second AKMA key material and a second identifier of a second serving PLMN or a second serving SNPN that provides a second mobile communication network connection for the application; storing the second AKMA key material according to the PLMN or SNPN based on the second identifier, and maintaining the stored first AKMA key material; receiving, from an application function (AF) node, a request for an application key for an application of the UE, where the request indicates an identifier of a PLMN or an SNPN; selecting AKMA key material from the first AKMA key material and the second AKMA key material according to the identifier of the PLMN or SNPN indicated by the request; and providing the application key corresponding to the selected AKMA key material to the AF node.

[0015] According to an eleventh aspect of the present disclosure, a method performed at an application function (AF) node is provided. The method includes: receiving, from a user equipment (UE), a session request for an application session; determining an identifier of a serving public land mobile network (PLMN) or a serving standalone non-public network (SNPN) that provides a mobile communication network connection for the session; and sending a request for an application key for the session to the authentication and key management of an application anchor function (AAnF) node. The request indicates an identifier of a serving PLMN or a serving SNPN.

[0016] According to a twelfth aspect of the present disclosure, another method performed at a user equipment UE is provided. The method includes: sending a session request for a session from an application function (AF) node. The request includes an identifier of a serving public land mobile network (PLMN) or a serving standalone non-public network (SNPN) that provides a mobile communication network connection for the session.

[0017] According to a thirteenth aspect of the present disclosure, there is provided a computer-readable storage medium having instructions stored thereon, which when executed by at least one processor, cause the at least one processor to execute the method according to any one of the tenth aspect.

[0018] According to a fourteenth aspect of the present disclosure, there is provided a computer program product including instructions, which when executed by at least one processor, cause the at least one processor to execute the method according to any one of the eleventh aspect.

[0019] According to a fifteenth aspect of the present disclosure, there is provided a computer program product including instructions, which when executed by at least one processor, cause the at least one processor to execute the method according to any one of the twelfth aspect.

[0020] It should be understood that the summary section is not intended to identify key or essential features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Through the following description, other features of the present disclosure will become readily understandable. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Some example embodiments will now be described with reference to the drawings, wherein:

[0022] Figure 1 An example scenario of a mismatch between security contexts is shown;

[0023] Figure 2 An example process according to a first embodiment of the present disclosure is shown;

[0024] Figure 3 Another example process according to a second embodiment of the present disclosure is shown;

[0025] Figure 4 Another example process according to a third embodiment of the present disclosure is shown;

[0026] Figure 5 is a flowchart depicting a method according to an embodiment of the present disclosure;

[0027] Figure 6 is a flowchart depicting a method according to an embodiment of the present disclosure;

[0028] Figure 7 is a flowchart depicting a method according to an embodiment of the present disclosure;

[0029] Figure 8 is a flowchart depicting a method according to an embodiment of the present disclosure;

[0030] Figure 9 is a flowchart depicting a method according to an embodiment of the present disclosure; and

[0031] Figure 10 Shows a simplified block diagram of a device according to an embodiment of the present disclosure. Detailed implementation

[0032] Some example embodiments will now be described in more detail below with reference to the accompanying drawings, in which some but not all embodiments are shown. In fact, the example embodiments may take many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like reference numerals always refer to like elements.

[0033] References in this disclosure to "an embodiment", "embodiment", "example embodiment", etc., indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an example embodiment, it is considered within the knowledge of those skilled in the art to combine such feature, structure, or characteristic with other embodiments, whether or not explicitly described.

[0034] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.

[0035] As used herein, the terms "data", "content", "information", and similar terms may be used interchangeably to refer to data capable of being sent, received, and / or stored according to embodiments of the present invention. Accordingly, no such terms should be used to limit the spirit and scope of the embodiments of the present invention.

[0036] As used in this application, the term "circuit" may refer to one or more or all of the following: a) Only a hardware circuit implementation (e.g., only an implementation within an analog and / or digital circuit), and b) A combination of a hardware circuit and software, such as (if applicable): (i) A combination of an analog and / or digital hardware circuit and software / firmware, and (ii) Any portion of a hardware processor (including a digital signal processor), software, and memory having software, which work together to enable a device such as a mobile phone or a server to perform various functions; and c) A hardware circuit and / or processor that requires software (e.g., firmware) for operation, such as a microprocessor or a portion of a microprocessor, but the software may be absent when not required for operation.

[0037] This definition of "circuit" applies to all uses of the term in this application (including any claims). As another example, as used in this application, the term "circuit" also encompasses implementations of only hardware circuits or processors (or multiple processors) or a portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term "circuit" also covers, for example and if applicable to a particular claim element, a baseband integrated circuit or a processor integrated circuit for a mobile device or a similar integrated circuit in a server, a cellular network device, or other computing or network device.

[0038] As defined herein, "computer-readable storage medium," which refers to a non-transitory physical storage medium (e.g., a volatile or non-volatile memory device), can be distinguished from "computer-readable transmission medium," which refers to an electromagnetic signal. Such media can take many forms, including but not limited to non-transitory computer-readable storage media (e.g., non-volatile media, volatile media) and transmission media. Transmission media include, for example, coaxial cables, copper wires, fiber optic cables, and carrier waves that travel through space without wires or cables, such as acoustic and electromagnetic waves, including radio, optical, and infrared waves. Signals include artificial transient changes in amplitude, frequency, phase, polarization, or other physical properties transmitted through a transmission medium. Examples of non-transitory computer-readable media include magnetic computer-readable media (e.g., floppy disks, hard disks, magnetic tapes, any other magnetic media), optical computer-readable media (e.g., compact disc read-only memory (CD-ROM), digital versatile disc (DVD), Blu-ray disc, etc.), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), FLASH-EPROM, or any other non-transitory medium from which a computer can read. The term computer-readable storage medium is used herein to refer to any computer-readable medium other than a transmission medium. However, it should be understood that in cases where an embodiment is described as using a computer-readable storage medium, in alternative embodiments, other types of computer-readable media can be substituted for or used in addition to the computer-readable storage medium.

[0039] Certain embodiments will be described hereinafter in connection with a cellular communication terminal (or user equipment (UE)), which is capable of performing cellular communication over a radio access via a cell, a base station, a WiFi access point, or a similar wireless transmitter and / or receiver node, thereby providing an access point for a radio access system. The radio access system can be arranged to allow a mobile communication network connection to be established between the UE and the UE's home network or a network entity of the home network. The radio access system can be a 3GPP access system or a non-3GPP access system. The home network can be a public land mobile network (PLMN) or a stand-alone non-public network (SNPN).

[0040] A cellular communication terminal or UE may include any suitable device capable of at least receiving data for cellular communication. For example, the cellular communication terminal or UE may be a handheld data processing device equipped with a radio receiver, data processing, and user interface means. Non-limiting examples include a mobile phone or a mobile station (MS) referred to as a "smartphone", a portable computer (such as a laptop or tablet computer) equipped with a wireless interface card or other wireless interface facilities, a personal data assistant (PDA) equipped with wireless communication capabilities, or any combination thereof. Additional examples include wearable wireless devices, such as devices integrated with a watch or smartwatch, glasses, helmets, hats, clothing, headphones with cellular connectivity, jewelry, etc., a universal serial bus (USB) stick with cellular capabilities, a modem data card, a machine type device, or any combination thereof.

[0041] According to the protocol for cellular communication, before initiating communication with a cellular communication network (such as a fifth-generation (5G) system), the cellular communication terminal or UE needs to perform primary authentication and register with its home network (such as a home PLMN or a home SNPN). Keys to be used for application layer security will be derived based on the key generated in the primary authentication (e.g., key K AUSF and other keys derived from K AUSF , such as key K AKMA ). A security context will be created by the primary authentication.

[0042] Traditionally, there are two cases where a UE can register multiple times in the serving networks of different PLMNs or in the serving networks of the same PLMN. The first case is that the UE registers with one PLMN serving network through a specific type of access (e.g., 3GPP) and registers with another PLMN serving network through another type of access (e.g., non-3GPP). The second case is that the UE registers in the same AMF in the same PLMN serving network through 3GPP access and non-3GPP access.

[0043] In both cases, the UE shall establish two NAS connections with its home network. The UE shall independently maintain and use two different 5G security contexts, one for the serving network of each PLMN. Each NAS security context shall be established separately via a successful primary authentication procedure with the HPLMN. If the Universal Subscriber Identity Module (USIM) or Universal Integrated Circuit Card (UICC) of the UE supports 5G parameter storage, the Mobile Equipment (ME) of the UE may store the two different 5G security contexts on the Universal Subscriber Identity Module (USIM) of the UE. If the USIM / UICC does not support 5G parameter storage, the ME may store the two different 5G security contexts in the ME non-volatile memory. The two different 5G security contexts are both current 5G security contexts.

[0044] Both the UE and the HPLMN shall use the latest K resulting from the latest successfully completed primary authentication, AUSF irrespective of the access network type (3GPP or non-3GPP) through which the UE was generated. Even if the UE has deregistered from that access but has registered via another access, the HPLMN shall retain the latest K generated during the successfully completed primary authentication on the given access. AUSF .

[0045] In 3GPP Release 19, due to the 5G system supporting upper layer handover, split, and switching of UE traffic (e.g., belonging to the same data session) across two 3GPP access links, there may be more cases of multiple registrations, assuming a single subscription to only one PLMN, including the following scenarios: · Single PLMN, PLMN plus Standalone Non-Public Network (SNPN), two PLMNs · The same or different 3GPP Radio Access Technologies (RATs) (e.g., New Radio (NR) or Non-Terrestrial Network (NTN), plus one of NR, NTN, or Long Term Evolution (LTE))

[0046] Note that the NTN here can refer to NR-based satellite access, including different orbits (e.g., Geostationary Earth Orbit (GEO), Medium Earth Orbit (MEO), Low Earth Orbit (LEO)).

[0047] For the PLMN plus PLMN / SNPN scenario, the two serving PLMN networks can be managed by the same operator or by different operators (assuming there is a service agreement between them). Three different registration scenarios that can be considered for the above cases are listed below. - The UE registers twice in the same serving PLMN; - The UE is registered on two serving PLMNs (denoted as PLMN#1 and PLMN#2 respectively) or two independent NPNs (SNPNs) (SNPN#1 and SNPN#2); - The UE is registered on two PLMNs (denoted as PLMN#1 and PLMN#2), or registered on one PLMN and one SNPN.

[0048] For all these cases, at the HPLMN of the UE, only one K AUSF (from the latest primary authentication on radio access (3GPP or non-3GPP GPP)) is stored, and this K AUSF will be used for UE parameter update (UPU), applied authentication and key management (AKMA), and roaming bootstrapping (SoR), etc.

[0049] In some cases, the concurrent operation of security procedures may lead to a mismatch between the security context in the network and the UE. Therefore, traditionally, it is stipulated in the protocol that the UE should not trigger registrations for 3GPP access and non-3GPP access simultaneously. Then, only sequential triggering of registrations is allowed. In this regard, if the UE is performing a registration through a first access and intends to perform a registration through another access in the same PLMN (for example, 3GPP access and the selected non-3GPP interworking function (N3IWF), trusted non-3GPP gateway function (TNGF), or wired access gateway function (W-AGF) are in the same PLMN), the UE should not initiate a registration through another access before the registration process on the first access is completed.

[0050] For example, when two different NAS connections terminate at the same AMF, if security procedures are run in parallel on two different NAS connections simultaneously, it may lead to a race condition and mismatch between the security context in the HPLMN and the UE. To avoid such mismatches, the following rules stipulated in 3GPP TS33.501 V17.6.0 should be followed: 1. In the case where another primary authentication or NAS security mode command (SMC) process is ongoing on a parallel NAS connection, the security anchor function (SEAF) or access and mobility management function (AMF) should not initiate a primary authentication or NAS SMC process. The authentication process should be performed on one NAS signaling connection at a time, followed by the NAS SMC process using the new 5G security context. 2. When the AMF has sent a NAS security mode command to the UE to use a new K AMF and receives a security context transfer request message for the UE from another AMF, the AMF should wait for the completion of the NAS SMC process (for example, receiving NAS security mode complete) before transferring the security context. 3. Before the primary authentication on the first NAS connection is completed, the UE shall not initiate NAS registration to the AMF of the same network via the second NAS connection.

[0051] However, it is still possible to run security procedures in parallel and concurrently. For example, due to various conditions, two primary authentication and key agreement (AKA) procedures can run in parallel for a single UE on different PLMNs. For example, when the UE performs the following procedures: - Perform a mobility registration update (MRU) procedure via 3GPP access in PLMN A, and the primary AKA is involved in the MRU; and - Perform an initial registration procedure via non-3GPP access in PLMN B, and the primary AKA is involved in the initial registration.

[0052] In this case, there may be a mismatch of K AUSF between the UE and its home network (HN). For example, when the UE receives the security mode command message from PLMN A via 3GPP access later than from PLMN B via non-3GPP access, even though the AUSF in the HN indicates that the authentication of the SEAF for PLMN A is successful earlier than the SEAF authentication for PLMN B. From the perspective of the UE or the HN, the KAUSF agreed upon by PLMN B or PLMN A respectively is the latest.

[0053] Figure 1 Shows an example scenario where two security procedures run in parallel, resulting in a mismatch between security contexts.

[0054] At step 110, a primary authentication (denoted as the first primary authentication) is successfully performed between the UE 101 and its HPLMN 104' via the first AMF 102 (denoted as AMF#1) (e.g., using the AUSF 104). At this time, the first visited PLMN 102' (denoted as VPLMN#1) is the serving PLMN that provides the first radio access to the UE 101. For example, when the UE 101 attempts to register to VPLMN#1, e.g., by sending a registration request to the AMF 102, the first primary authentication will be triggered. According to the first primary authentication, a key K AUSF (denoted as K AUSF(1) ) will be generated, and a security context can be created. As an embodiment, the first radio access can be 3GPP access. Then, a 3GPP security context (i.e., NAS context) can be created from the first primary authentication. After the first primary authentication is successfully completed, the 3GPP security context will be available in the UE 101 and the AMF#1 102, and K AUSF(1) will be available at the UE 101 and the AUSF 104.

[0055] At step 120, the UE 101 may initiate another primary authentication (denoted as a second primary authentication with the HPLMN 104') via the second AMF 103 (denoted as AMF#2). For example, the UE 101 may attempt to register with the second visited PLMN 103' (denoted as VPLMN#2), for example, by sending an initial registration request to AMF#2. Then, the second primary authentication may be triggered to create a security context for AMF#2. The UE 101 is able to perform cellular communications on two different radio accesses simultaneously. At step 120, the second visited PLMN 102' provides the UE 101 with a second radio access, while the first radio access is still maintained. A different K will be generated from the second primary authentication. AUSF (denoted as K AUSF(2) ). In an embodiment, the second radio access may be a non-3GPP access, such as a radio access according to Wi-Fi, Wireless Local Access Network (WLAN) technology, or the like.

[0056] Because the security context is not transferred between different PLMNs, PLMN#1 is not aware that the second primary authentication is ongoing on VPLMN#2. While the second primary authentication is ongoing, another primary authentication (denoted as the third primary authentication) may be triggered to UE 101 by VPLMN#1, as shown in step 130. For example, AMF#1 may decide to re-authenticate UE 101. The re-authentication may be triggered by the UDM in HPLMN 104' (e.g., triggered by a service request procedure). The original latest key K generated for the first radio access AUSF(1) Will remain in use in the HPLMN 104'.

[0057] Then, as shown in step 140, a parallel master authentication will occur, resulting in the most recent K AUSF mismatch or out of sync. In other words, determine which K AUSF (K generated from the second primary authentication AUSF(2) K is still generated from the first primary authentication AUSFξ(1) ) is considered to be the latest K in the UE 101 and the HPLMN 104' (eg, AUSF 104) AUSF For example, if UE 101 sends an authentication response message for the third primary authentication to VPLMN#1 via 3GPP access (first radio access) later than sending an authentication response message for the second primary authentication to VPLMN#2 via non-3GPP access (second access), but AMF#1 invokes the Nausf service of HPLMN 104' earlier than AMF#2, UE 101 may AUSF(1) (from 3GPP access) as the latest one, and HPLMN 104' may AUSF(2)(From non-3GPP access) is considered the most recent one. Parallel primary authentication may also lead to the problem of sequence number (SQN) out-of-sync in the 5G case (which can be solved by the UE 101 using the parameter AUTS), or may lead to the failure of the Extensible Authentication Protocol (EAP) authentication in the case of EAP-AKA (if the AUSF 104 cannot correctly process the two authentication requests), because EAP is a "lock-step" protocol.

[0058] Due to the most recent K between the HPLMN and the UE AUSF This mismatch (or out-of-sync) of will cause the UE 101 to be unable to access the service. This will lead to out-of-sync in the authentication and application key management (AKMA) use cases, because other keys of AKMA depend on the key K used in the AUSF 104 and the UE 101 AUSF . The mismatch of K between the HPLMN and the UE AUSF results in errors in SOR, UPU, and AKMA.

[0059] When one authentication is triggered by the UE and the other is triggered by the home network, the current specifications of the 3rd Generation Partnership Project (3GPP) do limit this problem.

[0060] Note that the above problems are described for two different types of radio access, but the problem also applies to two radio accesses of the same 3GPP type. For example, in the access traffic steering, handover, split (ATSSS) use case of 3GPP Release 19, the UE can be connected to two radio access network (RAN) nodes simultaneously for the same 3GPP access. In this case, the problem will be more prominent.

[0061] The present disclosure proposes several solutions to this problem. According to the first embodiment, a UDM-based solution is provided, in which if there is another ongoing authentication for the UE, the UDM in the HN delays the authentication of the current request of the UE. In this solution, the primary authentication involves the Unified Data Repository (UDR). On the contrary, in the current specifications, the UDR is not involved in the primary authentication (for example, as shown in step 2 of 3GPP TS33.501 V17.6.0 Figure 6 .1.3.1-1). It is only the UDM, and the primary authentication involves the Authentication Credential Repository and Processing Function (ARPF).

[0062] In this solution, when the primary authentication is executed or completed, the UDR can maintain the temporary state information for the primary authentication (e.g., indicating the authentication temporary state). For example, when the UDM receives a request for an authentication vector for the primary authentication from the AUSF, the UDM can store the temporary state information in the UDR. The temporary state information indicates the state of the UE's primary authentication, i.e., the authentication is in progress. In another example, after the UDM sends the requested authentication vector (AV) (e.g., including RAND, AUTN, XRES, CK’, IK’) to the AUSF (the UDM receives an authentication extraction request from the AUSF), the UDM can send and store the temporary state information in the UDR. For example, when an AKA challenge for the primary authentication is triggered, the UDM can send and store the temporary state information in the UDR.

[0063] In an embodiment, one UDM can include several UDM instances. For example, the routing indicator in the UE's Subscription Concealed Identifier (SUCI) can be used to identify the correct UDM instance capable of serving the UE. In this case, the UDM instance identified for the UE (denoted as UDM1) can send the temporary state information to the UDR.

[0064] Therefore, when an authentication extraction request for the primary authentication on the mobile communication network connection of the UE is received at the UDM in the UE's home network (e.g., at the UDM instance (e.g., at the same UDM1 or another UDM instance denoted as UDM2)), the UDM (or UDM2) can first check the authentication status of the UE in the UDR. The mobile communication network connection is connected to the UE via a first radio access, and the first radio access can be non-3GPP access or 3GPP access. If it is found that another authentication on another mobile communication network connection of the UE is in progress, UDM2 can delay the currently requested authentication, e.g., until the other authentication has been completed. The other mobile communication network connection can be connected to the UE via a radio access, which can be different from or the same as the first radio access. In the example, UDM2 can delay providing the authentication vector (AV) to the AUSF, e.g., for a few seconds. In another example, UDM2 can notify the AMF of the ongoing authentication, e.g., using a new error code, so that the AMF can also delay the currently requested authentication. Alternatively, if it is found that another authentication of the UE is in progress, UDM2 can reject the currently requested authentication. In this way, the currently requested authentication will not be executed in parallel with the ongoing authentication, thus avoiding a mismatch of keys (such as K AUSF ) between the UE and its home network.

[0065] According to the second embodiment, a UE-based solution is provided, where the UE delays the currently requested authentication if there is another ongoing authentication. In this solution, when the UE is requested to perform a primary authentication for a first mobile communication network connection, the UE will determine whether another authentication on a second mobile communication network connection for the UE is ongoing. For example, the 5G Mobility Management (5GMM) sublayer for the first radio access in the UE will check another 5GMM sublayer for the second mobile communication network connection before performing the requested primary authentication. If the primary authentication on the second mobile communication network connection is ongoing, the 5GMM sublayer for the first mobile communication network connection can delay the requested primary authentication to wait for the authentication on the second mobile communication network connection to complete.

[0066] In one example, if the UE needs to send an authentication response message on the current access to the PLMN (e.g., in response to an authentication request for the primary authentication on the first mobile communication network connection of the UE) and the primary authentication and key agreement procedure (e.g., on the second mobile communication network connection of the UE) is ongoing via another access on a different PLMN, the UE can send the authentication response message after the primary authentication and key agreement procedure on the different PLMN is completed.

[0067] Alternatively, the UE can reject the requested authentication. If another authentication is ongoing, the UE can generate an error code in response to the authentication request. For example, the UE can send an authentication failure message indicating the reason for the failure (e.g., the authentication performed on the second mobile communication network connection). In this way, a mismatch of keys (e.g., K AUSF ) between the UE and its home network can be avoided.

[0068] In a scenario where the UE is attached to two RAN nodes and the two RAN nodes are connected to two AMFs, the above UDP-based solution can be applied in the same way as in a scenario where the first and second radio access types are different (i.e., one is 3GPP access and the other is non-3GPP access). If the two RAN nodes are connected to the same AMF, the AMF can ensure that the requested authentication is delayed until the ongoing authentication is completed.

[0069] According to the third embodiment, a solution that requires an AKMA for each PLMN or SNPN is provided. Note that requiring an AKMA for each PLMN or SNPN is only for protection as it does not comply with the current standard of storing only one K AUSF (the latest K AUSF ). In this solution, the UE and its home network derive the applied AKMA key material (such as K AUSF from the valid K AKMAand the AKMA temporary identifier (A-TID)), and the service PLMN or service SNPN delivers the services of the application through this. The AKMA key material can be stored in the authentication and key management for the application anchor function node (AAnF). For example, if an application running on the UE (denoted as application X) requests KAKMA and A-TID, and the services of application X are delivered via the serving PLMN (denoted as PLMN A), the UE derives K AKMA from K AKMA and A-TID, and then provides K AKMA and A-TID to application X. Application X can also be an application in the application layer. Application X can also be the "upper layer" above the system layer. The home network (e.g., AUSF) can store the K AKMA and A-TID of application A into the AAnF based on the identifier of PLMN A. In a similar manner, another K AKMA and A-TID of an application derived from another KAUSF of another serving PLMN (PLMN B) can also be stored into the AAnF, while the K AKMA and A-TID of application A are still stored or maintained in the AAnF.

[0070] When the AF requests the application key of the application (i.e., K AF ) from the AAnF, the AF can also indicate the identifier (e.g., ID) of the serving PLMN or service SNPN that provides radio access for the application. For example, in the application session establishment request message, the UE can indicate its serving PLMN or service SNPN ID to the AF. The ID can be sent to the AAnF together with the key request for K AF . Alternatively, the AF can know the UE serving PLMN or service SNPN through other means. In the example, the AF can determine which PLMN or SNPN should be selected for the UE based on the policies of the home network. In response, the AAnF can select K AUSF generated from the K of the serving PLMN or service SNPN, and then provide K AKMA derived from the selected K AKMA to the AF. In this way, although the latest K AF maintained in its home network (e.g., in the AUSF) may be different from the latest K AUSF maintained in the UE, the AF can obtain the same application key as the application key derived in the UE (e.g., K AUSF ). Therefore, the UE will be able to access the services by using these application keys. AF )

[0071] Now refer to Figure 2, an example process 200 according to the first embodiment is shown. At step 210a, a primary authentication is successfully performed between the UE 101 and its HPLMN 104' via the first AMF 102 (denoted as AMF#1). At this time, the first visited PLMN 102' (denoted as VPLMN#1) is the serving PLMN that provides the first radio access to the UE 101. For example, when the UE 101 attempts to register to VPLMN#1, for example, by sending a registration request to the AMF 102, the first primary authentication will be triggered.

[0072] As shown in step 210b, after the first primary authentication is successfully completed, a NAS connection is established between the UE 101 and AMF#1 102. The 3GPP security context The NAS context created from the first primary authentication can be available in the UE 101 and AMF#1 102. On the UE side, the 3GPP security context is stored in the ME or USIM / UICC (for example, as the EF file EF5GS3GPPNSC). The content of this context may include the key K with an associated key set identifier AMF , UE security capabilities, uplink and downlink NAS COUNT values, as specified in Appendix C of 3GPP TS24.501 V18.0.1.

[0073] Then, in process 220, the UE 101 can initiate another primary authentication (denoted as the second primary authentication with the HPLMN 104) via the second AMF 103 (denoted as AMF#2) belonging to the second visited PLMN 103' (denoted as VPLMN#2). As shown in step 220a, the UE 101 uses the SUCI of the UE 101 to initiate a registration request for non-3GPP radio access to the second AMF#2 103 (denoted as AMF#2). At step 220b, AMF#2 forwards the authentication request to the AUSF 104. This request may include the SUCI of the UE 101 and the SN-Name identifying the PLMN 103'. Then, the AUSF 104 retrieves the authentication vector from the UDM 205 after SUCI de-concealment. Through SUCI de-concealment, the SUPI of the UE 101 can be obtained.

[0074] According to an embodiment of the present disclosure, after providing the authentication vector to the AUSF 104, the UDM 205 may store temporary status information in the UDR 206 indicating that the status of the primary authentication (i.e., the second authentication) for the UE is in progress. As shown in step 220d, the UDM instance 205-2 (denoted as UDM instance #2) assigned for the second authentication may send the temporary status information, for example, indicating "ongoing authentication" in the UDR 206, as well as the UDM instance #2, the serving network name (SNN), and the SUPI of the UE 101. At step 220e, the authentication status of the UE 101 updated by the UDM instance #2 and the temporary status information indicating "ongoing authentication" may be stored in the UDR 206. After updating the authentication in the UDR 206, an AKA challenge may be sent to the UE 101 via AMF#2, as shown in step 220f.

[0075] In parallel, in process 230, before the second authentication in process 220 is completed, an additional primary authentication (denoted as the third primary authentication) may be triggered to the UE 101 by the VPLMN#1. Since the AMF#1 belonging to the VPLMN#1 (to which the UE 101 is connected via the 3GPP radio access) is not aware of the ongoing second authentication in another access (non-3GPP GPP), the AMF#1 may trigger re-authentication for the same SUPI (i.e., the UE 101). As shown in step 230a, the AMF#1 decides to re-authenticate the UE and thus decides to extract the authentication vector (AV) from the UDM 205. The AMF#1 may send an authentication request message to the HPLMN 104’ to extract the AV, as shown in step 230b.

[0076] Then, at step 230c, in response to the authentication request message, the AUSF 104 attempts to retrieve the AV from the UDM 205. For example, the AUSF 104 may send an authentication extraction request to the UDM instance 205-1 (denoted as UDM instance #1) assigned for the third authentication. Then, the UDM instance #1 may check the status of the ongoing authentication of the UE 101 from the UDR 206. It will be found that there is another authentication (i.e., the second primary authentication) for the non-3GPP radio access of the UE 101 that is in progress. Then, the UDM instance #1 may delay the current authentication request from the AMF#1, as shown in step 330c. In an alternative embodiment, the UDM instance #1 may reject the current authentication request from the AMF#1, as shown in step 340c. Thus, the AMF#1 may re-trigger the re-authentication later.

[0077] Once the non-3GPP access authentication (the second primary authentication) is completed, the temporary status information of the second primary authentication in the UDR 206 can be reset, for example, by the UDM instance #2, as shown in step 240. Then, other 3GPP access authentications will be allowed when requested, or it will be resumed if it was held. In one example, the UDM instance #1 can periodically check the temporary status information for the second primary authentication and, once it finds that the temporary status information is reset, notify the AMF #1 to re-trigger the re-authentication. As another example, the UDM instance #2 can notify the UDM instance #1 that the second primary authentication is completed, so that the UDM instance #1 can notify the AMF #1 to re-trigger the re-authentication.

[0078] It can be understood that although the above call flow 200 is for parallel authentication of different radio accesses, it is also applicable to the case of 3GPP access involving multiple RAN nodes (with multiple registrations), such as the ATSSS use case in 3GPP Release 19. In the embodiments of those use cases, both the first radio access and the second radio access are 3GPP accesses.

[0079] Now referring to Figure 3 , an example process 300 according to the second embodiment is shown. At step 310a, a primary authentication (also denoted as the first primary authentication) is successfully performed between the UE 301 and its HPLMN 104' via the first AMF 102 (denoted as AMF #1). At this time, the first visited PLMN 102' (denoted as VPLMN #1) is the serving PLMN that provides the first radio access to the UE 301. For example, when the UE 301 attempts to register to the VPLMN #1, for example, by sending a registration request to the AMF #1 102, the first primary authentication will be triggered.

[0080] As shown in step 310b, after the first primary authentication is successfully completed, a NAS connection is established between the UE 401 and the AMF #1 102. The 3GPP security context (i.e., the NAS context created from the first primary authentication) can be available in the UE 401 and the AMF #1 102. On the UE side, the 3GPP security context is stored in the ME or USIM / UICC (e.g., as the EF file EF5GS3GPPNSC). The content of this context can include the key K with an associated key set identifier AMF , the UE security capabilities, the uplink and downlink NAS COUNT values, as specified in Appendix C of 3GPP TS 24.501 V18.0.1.

[0081] Then, in process 320, the UE 301 may initiate another primary authentication (denoted as the second primary authentication with the HPLMN 104) via the second AMF 103 (denoted as AMF#2) belonging to the second visited PLMN 103' (denoted as VPLMN#2). As shown in step 320a, the UE 301 uses the SUCI of the UE 301 to initiate a registration request for non-3GPP radio access to the second AMF#2 103. At step 320c, the AMF#2 forwards the authentication request to the AUSF 104. The request may include the SUCI of the UE 101 and the service network (SN) name identifying the PLMN 103'. Then, at step 320d, after the SUCI de-concealment, the SUPI of the UE201 can be obtained, and the AUSF 104 may retrieve the authentication vector of the UE 301 from the UDM 305 (e.g., from the UDM instance 305-2 (denoted as UDM instance #2) assigned for the second authentication). The AUSF 104 may send an AKA challenge to the UE.

[0082] According to an embodiment of the present disclosure, the 5GMM sublayer in the UE 301 stores an indication of the authentication status as "in progress" for the second authentication, e.g., when the second authentication is triggered, as shown in step 320b.

[0083] In parallel, in process 330, before the second authentication in process 320 is completed, another primary authentication (denoted as the third primary authentication) may be triggered for the UE301 via VPLMN#1. Since the AMF#1 belonging to VPLMN#1 (to which the UE 301 is connected via 3GPP radio access) is not aware of the ongoing second authentication in the other access (non-3GPP GPP), the AMF#1 may trigger re-authentication for the same SUPI (i.e., the UE 301). As shown in step 330a, the AMF#1 decides to re-authenticate the UE and thus decides to extract the authentication vector (AV) from the UDM 305. The AMF#1 may send an authentication request message to the HPLMN 104' to extract the AV, as shown in step 330b.

[0084] At step 330c, in response to the authentication request message, the AUSF 104 extracts the AV from the UDM 305 (e.g., from the UDM instance 305-1 (denoted as UDM instance #1) assigned for the third authentication). Then, the AKA process will be triggered, where an AKA challenge is sent to the UE 301 via the AMF#1, as shown in step 330d.

[0085] According to an embodiment of the present disclosure, the UE 301 will not pass the AKA challenge to its USIM / UICC. In response to the AKA challenge, the UE 301 will determine whether another authentication for the second radio access of the UE is in progress. In this regard, the 5GMM sublayer may check the authentication status of other mobile communication network connections of the UE 301. In the case where it is found that the status of the second authentication is "in progress", the UE 301 may decide to delay the current third authentication, as shown in step 330e. It will delay the current request until the non-3GPP access authentication triggered by step 2 is completed. In other words, the 5GMM sublayer t passes the AKA challenge to the USIM / UICC of the UE because the authentication status of the second mobile communication network connection is "authenticating". Alternatively, in the case where it is found that the status of the second authentication is "in progress", the UE 301 may decide to reject the AKA challenge, as shown in step 330f. Therefore, the current third authentication will be rejected. Therefore, the AMF may re-trigger the authentication later.

[0086] Although not shown, once the second authentication is completed, the authentication status of the second authentication in the UE 301 will be reset so that other authentications (e.g., the third authentication) will be allowed when requested or resumed if it is held.

[0087] Now referring to Figure 4 , an example process 400 for avoiding key mismatch in the case of parallel authentication according to a third embodiment is shown. At step 410, a first primary authentication is successfully performed between the UE 401 and its HPLMN 104' via the first AMF 102 (denoted as AMF#1). At this time, the first visited PLMN 102' (denoted as VPLMN#1) is the serving PLMN providing the first radio access to the UE 401. The UE 401 is registered to VPLMN#1. Then, the AUSF 104 may generate keys K AUSF and K AKMA from the first primary authentication, and push the generated K AKMA (denoted as K AKMA(1) ) to the AAnF 407, as shown in step 415. The key K AKMA is generated per PLMN. Therefore, in step 415, the identity (ID) of VPLMN#1 may be sent to the AAnF 407 together with K AKMA(1) . At step 420, the AAnF 407 will store and hold the K AKMA(1) of the PLMN per PLMN based on the ID of VPLMN#1.

[0088] In step 425, the UE 401 registers with the second visited PLMN 103' (denoted as VPLMN#2). Then, a second primary authentication is successfully performed between the UE 401 and its HPLMN 104' via the second AMF 103 (denoted as AMF#2). According to the second primary authentication, the AUSF 104 can generate the keys K AUSF and K AKMA , and push the generated K AKMA (denoted as K AKMA(2) ) together with the ID of VPLMN#2 to the AUSF 407, as shown in step 430. Then, at step 435, the AAnF 407 stores and maintains this K AKMA(2) for each PLMN based on the ID of VPLMN#2. Different from the traditional method, both K AKMA(1) and K AKMA(2) will be maintained in the AAnF 407.

[0089] When the UE 401 requests an application session from the AF 408 (as shown in step 440), the PLMN through which it accesses the application can be determined. In one example, the UE 401 can provide the PLMN ID in the session request. Alternatively, the AF 408 can determine the serving PLMN of the UE through other means, as shown in step 445. In another example, the HPLMN 104’ can select the VPLMN as the serving PLMN for the application according to the HPLMN policy, and then notify the AF 408 of the ID of the selected PLMN.

[0090] Then, the AF 408 sends a request for the application key of the application (i.e., K AF ) to the AAnF 407. The ID of the serving PLMN of the application is included in the request, as shown in step 450.

[0091] In response, the AAnF 406 selects the corresponding K AKMA based on the ID at step 455, and then provides the application key K AKMA derived from the selected K AF to the AF 408 at step 460.

[0092] Figure 5 is a flowchart depicting a method 500 according to an embodiment of the present disclosure. The method 500 can be implemented at the UE, and the UE can be any suitable mobile communication device. For example, the method 500 can be implemented at the UE 301 as shown in Figure 3 .

[0093] As shown in block 510, the method 500 includes, by the UE (such as the UE 301), from a network node (such as Figure 3The AMF shown #1) receives a request to perform authentication with the home network (HN) of the UE (such as a PLMN or SNPN) on the first mobile communication network connection of the UE. The authentication can be primary authentication or other authentication between the UE and the core network.

[0094] Method 500 further includes determining whether another authentication with the HN is being performed on a second mobile communication network connection for the UE, as shown in block 520. The second mobile communication network connection can be a parallel connection whose authentication is triggered before the first mobile communication network connection. In an example, the mobility management sublayer of the UE can store an indication of the authentication status of each mobile communication network connection of the UE. When the authentication of a mobile communication network connection is triggered, the authentication status of the mobile communication network connection can be set to indicate that its authentication is in progress. When the authentication of the mobile communication network connection is completed, its authentication status can be reset to indicate that its authentication is completed.

[0095] Method 500 further includes delaying the authentication on the first mobile communication network connection or rejecting the request when another authentication with the HN is being performed on the second mobile communication network connection, as shown in block 530. In some embodiments, the authentication on the first mobile communication network connection can be delayed until the other authentication is completed.

[0096] In some embodiments, method 500 can further include: when another authentication is being performed, rejecting the authentication on the first mobile communication network connection and returning an error code to the network node.

[0097] In some embodiments, method 500 can further include: when another authentication is being performed, holding the authentication on the first mobile communication network connection until the other authentication is completed without notifying the network node. This is similar to a synchronous or blocking application programming interface (API) or functional mode.

[0098] In some embodiments, method 500 can further include: holding the authentication on the first mobile communication network connection and immediately sending a response to the network node to inform the network node and the home network that another authentication has not been completed. At the same time, method 500 can further include: setting an expected timer in the response. Alternatively, the timer can also be set on the network side. It is similar to an asynchronous or non-blocking API or functional mode.

[0099] In some embodiments, method 500 can further include: holding the authentication until timeout and then sending an authentication failure notification with an error code to the network node.

[0100] Although Figure 5 not shown, method 500 further includes performing the authentication on the first mobile communication network connection when there is no other authentication with the HN being performed on the second mobile communication network connection.

[0101] In one embodiment, after deciding to delay authentication, the UE may also set a timer for timing when to end the delayed authentication. The duration of the timer may be the expected end time of the second authentication (which may be determined by the UE), or it may be a predefined value, e.g., as specified in the protocol. Then, when the timer expires, the UE may attempt to resume the delayed authentication. When the timer expires and the delayed authentication cannot be resumed, e.g., it is determined that another authentication is still in progress when the timer expires, the UE may reject the request.

[0102] In one embodiment, after deciding to delay authentication, the UE may send a notification to the network node, which notifies the network node and the HN that the authentication on the first mobile communication network connection will be delayed. For example, the UE may send a response to the request, and the notification may be included in the response. Then, the network node and the HN will know that the authentication has not been completed. A timer may also be set in the response for timing when to end the delay of the authentication. Alternatively, the timer may also be set on the network side.

[0103] In one embodiment, after deciding to reject authentication, the UE may send an error code to the network node, which indicates that the request is rejected because another authentication is being executed.

[0104] Figure 6 is a flowchart depicting a method 600 according to an embodiment of the present disclosure. The method 600 may be implemented at a unified data management node or a network function entity, which may be any suitable communication device. For example, the method 600 may be implemented at the UDM 205. It can be understood that the method 600 may be implemented at other network nodes or devices.

[0105] As shown in block 610, the method 600 includes receiving, from an AUSF node, a request to extract an authentication vector for authentication between an HN (such as a PLMN or an SNPN) and the UE on the first mobile communication network connection of the UE, as shown in block 610; determining whether there is another authentication with the HN being executed on the second mobile communication network connection of the UE, as shown in block 620; and when there is another authentication with the HN being executed on the second mobile communication network connection, delaying the extraction of the authentication vector or rejecting the request, as shown in block 630. The extraction of the authentication vector or the rejection of the request may be delayed until another authentication has been completed.

[0106] In an embodiment, method 600 may further include sending, when another authentication is being performed, temporary status information for the other authentication to a UDR (such as UDR 206), indicating that the other authentication is in progress, such that the temporary status information is stored in the UDR. When the other authentication is completed, the UDM may reset the temporary status information to indicate that the other authentication is completed. The UDM may determine whether the temporary status information indicates that another authentication is in progress by checking the temporary status information stored in the UDR.

[0107] Although not shown in Figure 6 method 600 may further include: providing the requested authentication vector to the AUSF node when no other authentication with the HN is being performed on the second mobile communication network connection.

[0108] In some embodiments, method 600 may further include: rejecting the authentication on the first mobile communication network connection and returning an error code to the AUSF node when another authentication is being performed.

[0109] In some embodiments, method 600 may further include: holding the authentication on the first mobile communication network connection until the other authentication is completed without notifying the AUSF node. It is similar to a synchronous or blocking API or functional mode.

[0110] In some embodiments, method 600 may further include: holding the authentication on the first mobile communication network connection and immediately sending a response to the AUSF node to inform the AUSF node that the other authentication is not yet completed. At the same time, method 600 may further include: setting an expected timer in the response. Alternatively, the timer may also be set at the AUSF node. It is similar to an asynchronous or non-blocking API or functional mode.

[0111] In some embodiments, method 600 may further include: holding the authentication until timeout and then sending an authentication failure notification with an error code to the AUSF node.

[0112] In an embodiment, after deciding to delay the authentication, the UDM may also set a timer for timing when to end the delay of the authentication. The timer duration may be the expected end time of the second authentication (which may be determined by the UDM), or may be a predefined value, for example, as specified in the protocol. Then, when the timer expires, the UDM may attempt to check whether the other authentication is completed. If it is determined that the other authentication is still in progress when the timer expires, the UDM may reject the request.

[0113] In one embodiment, method 600 may further include, after deciding to delay authentication, sending a notification to the AUSF node that authentication on the first mobile communication network connection will be delayed. For example, the UDM may send a response to the request, and the notification may be included in the response. Then, the AUSF will know that the authentication has not been completed. A timer may also be set in the response to time the delay of when the authentication ends. Alternatively, the timer may be set in the AUSF node.

[0114] In one embodiment, after deciding to reject authentication, the UDM may send an error code to the AUSF node, which indicates that the request is rejected because another authentication is being performed.

[0115] Figure 7 is a flowchart depicting method 700 according to an embodiment of the present disclosure. Method 700 may be implemented at the application authentication and key management of an anchor function node or a network function entity (which may be any suitable communication device). For example, method 700 may be implemented at the AAnF 407. It can be understood that method 700 may be implemented at other network nodes or devices.

[0116] As shown in block 710, method 700 includes: receiving, from the AUSF node, first AKMA key material for an application of a UE, and a first identifier of a first serving PLMN or a first serving SNPN that provides a first mobile communication network connection for the application, as shown in block 710; and storing the first AKMA key material according to the PLMN or SNPN based on the first identifier, as shown in block 720.

[0117] Method 700 further includes receiving, from the AUSF node, second AKMA key material for the application and a second identifier of a second serving PLMN or a second serving SNPN that provides a second mobile communication network connection for the application, as shown in block 730; and storing the second AKMA key material according to the PLMN or SNPN based on the second identifier while maintaining the stored first AKMA key material, as shown in block 740.

[0118] Method 700 further includes receiving a request for an application key for an application of a UE from an AF node. The request indicates an identifier of a PLMN or an SNPN, as shown in block 750; selecting AKMA key material from the first AKMA key material and the second AKMA key material according to the identifier of the PLMN or SNPN indicated by the request, as shown in block 760; and providing an application key corresponding to the selected AKMA key material to the AF node.

[0119] Figure 8is a flowchart depicting a method 800 according to an embodiment of the present disclosure. The method 800 may be implemented at an application function node or a network function entity, which may be any suitable communication device. For example, the method 800 may be implemented at the AF 408. It will be appreciated that the method 700 may be implemented at other network nodes or devices.

[0120] As shown in block 810, the method 800 includes: receiving a session request for a requested application from a UE; determining an identifier of a serving PLMN or SNPN that provides a mobile communication network connection for the session, as shown in block 820; and sending a request for an application key for the session to an AAnF node (such as the AAnF 407). The request indicates the identifier of the serving PLMN or SNPN.

[0121] Figure 9 is a flowchart depicting a method 900 according to an embodiment of the present disclosure. The method 900 may be implemented at a UE, which may be any suitable mobile communication device. For example, the method 900 may be implemented at the UE 401 as Figure 4 shown. As shown in block 910, the method 900 includes sending a session request for a session from an AF node (such as the AF 408). The request includes an identifier of a serving PLMN or SNPN that provides a mobile communication network connection for the session.

[0122] Now referring to Figure 10 , Figure 10 shows a simplified block diagram of an apparatus 1000 that may be embodied in or as a mobile communication device (e.g., an interactive sensing UE) or a network node (e.g., a non-action sensing server). The apparatus 1000 may include at least one processor 1001, such as a data processor (DP), and at least one memory (MEM) 1002 coupled to the at least one processor 1001. The apparatus 1000 may also include one or more transmitters TX, one or more receivers RX 1003, or one or more transceivers coupled to the one or more processors 1001 for wireless and / or wired communication.

[0123] Although not shown, the apparatus 1000 may have at least one communication interface. For example, the communication interface may be at least one antenna or transceiver, as Figure 10 shown. The communication interface may represent any interface necessary for communicating with other network entities.

[0124] As a non-limiting example, the processor 1001 may be of any type suitable for the local technical environment and may include one or more of the following: a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture.

[0125] As a non-limiting example, MEMS 1002 can be of any type suitable for the local technical environment and can be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory.

[0126] MEM 1002 stores a program (PROG) 1004. PROG 1004 can include instructions that, when executed on an associated processor 1001, enable the device 1000 to operate in accordance with embodiments of the present disclosure, such as to perform one of methods 800 and 900. The combination of at least one processor 1001 and at least one MEM 1002 can form a processing circuit or device 1005 suitable for implementing various embodiments of the present disclosure.

[0127] Various embodiments of the present disclosure can be implemented by a computer program executable by one or more processors 1001, software, firmware, hardware, or a combination thereof.

[0128] In general, the various exemplary embodiments can be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. For example, some aspects can be implemented in hardware, while other aspects can be implemented in firmware or software executable by a controller, microprocessor, or other computing device, but the present invention is not limited thereto. Although the various aspects of the example embodiments of the present disclosure can be shown and described as block diagrams, flowcharts, or using some other graphical representation, it is well understood that, as a non-limiting example, the blocks, devices, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuits or logic, general hardware or a controller or other computing device, or some combination thereof.

[0129] Accordingly, it should be understood that at least some aspects of the example embodiments of the present disclosure can be practiced in various components such as integrated circuit chips and modules. It should thus be appreciated that the exemplary embodiments of the present invention can be implemented in a device embodied as an integrated circuit, where the integrated circuit can include circuitry (and possibly firmware) for embodying at least one or more of a data processor, a digital signal processor, a baseband circuit, and a radio frequency circuit that can be configured to operate in accordance with the exemplary embodiments of the present invention.

[0130] It should be understood that at least some aspects of the exemplary embodiments of the present disclosure may be embodied in computer-executable instructions executed by one or more computers or other devices, such as in one or more program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., which perform specific tasks or implement specific abstract data types when executed by a processor in a computer or other device. The computer-executable instructions may be stored on a computer-readable medium, such as a non-transitory computer-readable medium, such as a hard disk, an optical disk, a removable storage medium, a solid-state memory, a RAM, etc. As will be understood by those skilled in the art, the functions of the program modules may be combined or distributed as needed in various embodiments. In addition, the functionality may be embodied in whole or in part in firmware or hardware equivalents, such as integrated circuits, field-programmable gate arrays (FPGAs), etc.

[0131] In addition, although the operations are depicted in a particular order, this should not be construed as requiring that the operations be performed in the particular order shown or in sequential order, or that all of the illustrated operations be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately or in any suitable sub-combination in multiple embodiments.

[0132] The terms used herein are for the purpose of describing particular embodiments only and are not intended to limit the exemplary embodiments. As used herein, the singular forms "a", "an" and "the" are also intended to include the plural forms unless the context clearly indicates otherwise. It will be further understood that the terms "comprises", "comprising", "has", "having", "includes" and / or "including" when used herein specify the presence of the stated features, elements and / or components, etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0133] As used herein, the phrase "at least one of A and B" or "at least one of A or B" should be understood to mean "only A, only B, or both A and B". The phrase "A and / or B" should be understood to mean "only A, only B, or both A and B".

[0134] This disclosure includes any novel feature or combination of features disclosed herein or any generalization thereof. Various modifications and variations of the foregoing exemplary embodiments of this disclosure may become apparent to those of ordinary skill in the relevant art in view of the foregoing description when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the scope of the non-limiting and exemplary embodiments of this disclosure.

Claims

1. A device, comprising: at least one processor; and at least one memory storing instructions which, when executed by the at least one processor, cause the device to at least: receive, from a network node, a request to perform authentication with the home network (HN) of the device on a first mobile communication network connection of the device; determine whether another authentication with the HN is being performed on a second mobile communication network connection for the device; and when another authentication with the HN is being performed on the second mobile communication network connection, delay the authentication on the first mobile communication network connection or reject the request.

2. The device according to claim 1, wherein the instructions, when executed by the at least one processor, further cause the device to at least: when another authentication with the HN is not being performed on the second mobile communication network connection, perform the authentication on the first mobile communication network connection.

3. The device according to claim 1 or 2, wherein the instructions, when executed by the at least one processor, further cause the device to delay the authentication on the first mobile communication network connection at least by: delaying the authentication on the first mobile communication network connection until the other authentication is completed.

4. The device according to any one of claims 1 to 3, wherein the instructions, when executed by the at least one processor, further cause the device to delay the authentication on the first mobile communication network connection at least by: sending a notification to the network node to inform the HN that the authentication on the first mobile communication network connection will be delayed.

5. The device according to any one of claims 1 to 4, wherein the instructions, when executed by the at least one processor, further cause the device to delay the authentication on the first mobile communication network connection at least by: setting a timer for timing when to end the delay of the authentication.

6. The device according to claim 5, wherein the instructions, when executed by the at least one processor, further cause the device to at least: when it is determined that the other authentication is still in progress when the timer expires, reject the request.

7. The device according to any one of claims 1 to 6, wherein the instructions, when executed by the at least one processor, further cause the device to reject the request at least by: sending an error code to the network node, the error code indicating that the request is rejected due to the other authentication being performed.

8. The device according to any one of claims 1 to 7, wherein the instructions, when executed by the one or more processors, further cause the device to at least: when the other authentication is being performed, set an indication of the authentication status in the device to indicate that the other authentication is in progress.

9. The device according to claim 8, wherein the instructions, when executed by the one or more processors, further cause the device to at least: when the other authentication is completed, reset the indication of the authentication status to indicate that the other authentication is completed.

10. The apparatus according to any one of claims 8 to 9, wherein when the instructions are executed by the at least one processor, the apparatus is further caused to at least: Check the indication of the authentication status to determine whether the other authentication is in progress.

11. The apparatus according to any one of claims 8 to 10, wherein the indication of the authentication status is maintained in the mobility management sublayer of the apparatus.

12. The apparatus according to any one of claims 1 to 11, wherein the authentication for the first mobile communication network connection is triggered by a network node in the HN, and the other authentication for the second mobile communication network connection is triggered by the apparatus.

13. The apparatus according to any one of claims 1 to 12, wherein the request is an authentication and key agreement (AKA) challenge from an authentication server function (AUSF) node in the HN for the primary authentication on the first mobile communication network connection.

14. The apparatus according to claim 13, wherein delaying the authentication on the first mobile communication network connection comprises: Delaying the use of the AKA challenge to generate the authentication key K AUSF .

15. The apparatus according to any one of claims 1 to 14, wherein the HN is a home public land mobile network or a subscription-independent non-public network (SNPN).

16. An apparatus implemented at a unified data management (UDM) node in a home network (HN) of a user equipment (UE), the apparatus comprising: At least one processor; And At least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least: Receive, from an authentication server function (AUSF) node, a request to extract an authentication vector for authentication between the HN and the UE on a first mobile communication network connection of the UE; Determine whether another authentication with the HN is being performed on a second mobile communication network connection of the UE; And When another authentication with the HN is being performed on the second mobile communication network connection, delay the extraction of the authentication vector or reject the request.

17. The apparatus according to claim 16, wherein when the instructions are executed by the at least one processor, the apparatus is further caused to at least: When another authentication with the HN is not being performed on the second mobile communication network connection, provide the requested authentication vector to the AUSF node.

18. The apparatus according to any one of claims 16 to 17, wherein when the instructions are executed by the at least one processor, the apparatus is further caused to delay the extraction of the authentication vector at least by: Delaying the extraction of the authentication vector until the other authentication is completed.

19. The apparatus according to any one of claims 16 to 18, wherein when the instructions are executed by the at least one processor, the apparatus is further caused to delay the extraction of the authentication vector at least by: Sending a notification to the AUSF node that the authentication on the first mobile communication network connection will be delayed.

20. The apparatus according to any one of claims 16 to 19, wherein when the instructions are executed by the at least one processor, the apparatus further delays the extraction of the authentication vector at least by: Setting a timer for timing the delay of when to end the extraction.

21. The apparatus according to claim 20, wherein when the instructions are executed by the at least one processor, the apparatus further at least: When it is determined that the other authentication is still in progress when the timer expires, reject the request.

22. The apparatus according to any one of claims 16 to 21, wherein when the instructions are executed by the at least one processor, the apparatus further rejects the request at least by: Sending an error code to the AUSF node, the error code indicating that the request is rejected because the other authentication is being executed.

23. The apparatus according to any one of claims 16 to 22, wherein when the instructions are executed by the at least one processor, the apparatus further at least: When the other authentication is being executed, send temporary status information for the other authentication to a unified data repository (UDR) such that the temporary status information is stored in the UDR, the temporary status information indicating that the other authentication is in progress.

24. The apparatus according to claim 23, wherein when an authentication and key agreement (AKA) challenge for the other authentication is triggered, the temporary status information is sent to the UDR.

25. The apparatus according to any one of claims 23 to 24, wherein when the instructions are executed by the one or more processors, the apparatus further at least: When the other authentication is completed, reset the temporary status information to indicate that the other authentication is completed.

26. The apparatus according to any one of claims 23 to 25, wherein when the instructions are executed by the at least one processor, the apparatus further at least: Check the temporary status information stored in the UDR to determine whether the temporary status information indicates that the other authentication is in progress.

27. The apparatus according to any one of claims 23 to 26, wherein when the instructions are executed by the at least one processor, the apparatus further at least: Send at least one of the following information and the temporary status information to the UDR: An identifier of a UDM instance for the second mobile communication network connection, An identifier of a serving network of the second mobile communication network connection, or An identifier of the UE.

28. The apparatus according to any one of claims 15 to 27, wherein the authentication for the first mobile communication network connection is triggered by the UDM node, and the other authentication for the second mobile communication network connection is triggered by the UE.

29. The apparatus according to any one of claims 16 to 28, wherein the authentication vector will be used for primary authentication on the first mobile communication network connection.

30. The apparatus according to any one of claims 16 to 29, wherein the HN is a home public land mobile network or a subscribed standalone non-public network.

31. A method performed at a user equipment (UE), the method comprising: Receiving, from a network node, a request to perform authentication with a home network (HN) of the UE on a first mobile communication network connection of the UE; Determining whether another authentication with the HN is being performed on a second mobile communication network connection for the UE; And When another authentication with the HN is being performed on the second mobile communication network connection, delaying the authentication on the first mobile communication network connection or rejecting the request.

32. The method according to claim 31, further comprising: When another authentication with the HN is not being performed on the second mobile communication network connection, performing the authentication on the first mobile communication network connection.

33. The method according to claim 31 or 32, wherein delaying the authentication on the first mobile communication network connection comprises: Delaying the authentication on the first mobile communication network connection until the other authentication is completed.

34. The method according to any one of claims 31 to 33, wherein delaying the authentication on the first mobile communication network connection comprises: Sending a notification to the network node to inform the HN that the authentication on the first mobile communication network connection will be delayed.

35. The method according to any one of claims 31 to 34, wherein delaying the authentication on the first mobile communication network connection comprises: Setting a timer for timing when to end the delay of the authentication.

36. The method according to claim 35, wherein delaying the authentication on the first mobile communication network connection comprises: When it is determined that the other authentication is still in progress when the timer expires, rejecting the request.

37. The method according to any one of claims 31 to 36, wherein rejecting the request comprises: Sending an error code to the network node, the error code indicating that the request is rejected because the other authentication is being performed.

38. The method according to any one of claims 31 to 37, further comprising: When the other authentication is being performed, setting an indication of the authentication status in the UE to indicate that the other authentication is in progress.

39. The method according to claim 38, further comprising: When the other authentication is completed, resetting the indication of the authentication status to indicate that the other authentication is completed.

40. The method according to any one of claims 38 to 39, further comprising: Checking the indication of the authentication status to determine whether the other authentication is in progress.

41. A method performed at a unified data management (UDM) node in a home network (HN) of a user equipment (UE), the method comprising: Receive a request from an Authentication Server Function (AUSF) node to extract an authentication vector for authentication between the HN and the UE on the first mobile communication network connection of the UE; Determine whether another authentication with the HN is being performed on the second mobile communication network connection of the UE; And When another authentication with the HN is being performed on the second mobile communication network connection, delay the extraction of the authentication vector or reject the request.

42. The method according to claim 41, further comprising: When another authentication with the HN is not being performed on the second mobile communication network connection, provide the requested authentication vector to the AUSF node.

43. The method according to any one of claims 41 to 42, wherein delaying the extraction of the authentication vector comprises: Delaying the extraction of the authentication vector until the other authentication is completed.

44. The method according to any one of claims 41 to 43, wherein delaying the extraction of the authentication vector comprises: Send a notification to the AUSF node that the authentication on the first mobile communication network connection will be delayed.

45. The method according to any one of claims 41 to 44, wherein delaying the extraction of the authentication vector comprises: Set a timer for timing when to end the delay of the extraction.

46. The method according to any one of claims 41 to 45, further comprising: When it is determined that the other authentication is still in progress when the timer expires, reject the request.

47. The method according to any one of claims 41 to 46, wherein rejecting the request comprises: Send an error code to the AUSF node, the error code indicating that the request is rejected because the other authentication is being performed.

48. The method according to any one of claims 41 to 47, further comprising: When the other authentication is being performed, send temporary status information for the other authentication to a Unified Data Repository (UDR) such that the temporary status information is stored in the UDR, the temporary status information indicating that the other authentication is in progress.

49. The method according to claim 48, further comprising: When the other authentication is completed, reset the temporary status information to indicate that the other authentication is completed.

50. The method according to any one of claims 48 to 49, further comprising: Check the temporary status information stored in the UDR to determine whether the temporary status information indicates that the other authentication is in progress.

51. A computer-readable medium having computer program code thereon, which when executed on a computer causes the computer to perform the method according to any one of claims 31 to 40.

52. A computer-readable medium having computer program code thereon, which when executed on a computer causes the computer to perform the method according to any one of claims 41 to 50.

53. A device implemented at an authentication and key management for an Application Anchor Function (AAnF) node, the device comprising: At least one processor; And At least one memory storing instructions which, when executed by the at least one processor, cause the device to at least: Receive from an Authentication Server Function (AUSF) node a first Application Authentication and Key Management (AKMA) key material for an application of a User Equipment (UE) and a first identifier of a first Serving Public Land Mobile Network (PLMN) or a first Serving Standalone Non-Public Network (SNPN) that provides a first mobile communication network connection for the application; Store the first AKMA key material according to the PLMN or SNPN based on the first identifier; Receive from the AUSF node a second AKMA key material for the application and a second identifier of a second Serving PLMN or a second Serving SNPN that provides a second mobile communication network connection for the application; Store the second AKMA key material according to the PLMN or SNPN based on the second identifier and maintain the stored first AKMA key material; Receive from an Application Function (AF) node a request for an application key for the application of the UE, wherein the request indicates an identifier of a PLMN or SNPN; Select an AKMA key material from the first AKMA key material and the second AKMA key material according to the identifier of the PLMN or SNPN indicated by the request; And Provide the AF node with an application key corresponding to the selected AKMA key material.

54. The device according to claim 53, wherein the request includes an identifier of a PLMN or SNPN.

55. The apparatus according to claim 53 or 54, wherein the AKMA key material comprises K AKMA and an AKMA temporary identifier.

56. A device implemented at an Application Function (AF) node, the device comprising: At least one processor; And At least one memory storing instructions which, when executed by the at least one processor, cause the device to at least: Receive from a User Equipment (UE) a session request for a requested application; Determine an identifier of a Serving Public Land Mobile Network (PLMN) or a Serving Standalone Non-Public Network (SNPN) that provides a mobile communication network connection for the session; Send a request for an application key for the session to an authentication and key management for an Application Anchor Function (AAnF) node, wherein the request indicates the identifier of the Serving PLMN or the Serving SNPN.

57. The device according to claim 54, wherein the request includes the identifier of the Serving PLMN or the Serving SNPN.

58. The device according to claim 56, wherein the instructions, when executed by the at least one processor, further cause the device to at least: Determine which PLMN or SNPN will be selected as the Serving PLMN or the Serving SNPN.

59. A device implemented at a User Equipment (UE), the device comprising: At least one processor; And At least one memory storing instructions which, when executed by the at least one processor, cause the device to at least: Send a session request for a session from an Application Function (AF) node; Wherein the request includes an identifier of a Serving Public Land Mobile Network (PLMN) or a Serving Standalone Non-Public Network (SNPN) that provides a mobile communication network connection for the session.

60. A method performed at authentication and key management for an Application Anchor Function (AAnF) node, the method comprising: Receiving, from an Authentication Server Function (AUSF) node, first Application Authentication and Key Management (AKMA) key material for an application of a User Equipment (UE) and a first identifier of a first Serving Public Land Mobile Network (PLMN) or a first Serving Standalone Non-Public Network (SNPN) that provides a first mobile communication network connection for the application; Storing the first AKMA key material according to the PLMN or SNPN based on the first identifier; Receiving, from the AUSF node, second AKMA key material for the application and a second identifier of a second Serving PLMN or a second Serving SNPN that provides a second mobile communication network connection for the application; Storing the second AKMA key material according to the PLMN or SNPN based on the second identifier and maintaining the stored first AKMA key material; Receiving, from an Application Function (AF) node, a request for an application key for the application of the UE, wherein the request indicates an identifier of a PLMN or SNPN; Selecting AKMA key material from the first AKMA key material and the second AKMA key material according to the identifier of the PLMN or SNPN indicated by the request; Providing an application key corresponding to the selected AKMA key material to the AF node.

61. A method performed at an Application Function (AF) node, the method comprising: Receiving, from a User Equipment (UE), a session request for a requested application; Determining an identifier of a Serving Public Land Mobile Network (PLMN) or a Serving Standalone Non-Public Network (SNPN) that provides a mobile communication network connection for the session; Sending a request for an application key for the session to authentication and key management for an Application Anchor Function (AAnF) node, wherein the request indicates the identifier of the Serving PLMN or the Serving SNPN.

62. A method performed at a User Equipment (UE), the method comprising: Sending a session request for a session from an Application Function (AF) node; Wherein the request includes an identifier of a Serving Public Land Mobile Network (PLMN) or a Serving Standalone Non-Public Network (SNPN) that provides a mobile communication network connection for the session.

63. A computer-readable medium having computer program code thereon which, when executed on a computer, causes the computer to perform the method according to claim 60.

64. A computer-readable medium having computer program code thereon, which, when executed on a computer, causes the computer to perform the method according to claim 61.

65. A computer-readable medium having computer program code thereon, which, when executed on a computer, causes the computer to perform the method according to claim 62.

Images