COMMUNICATION DEVICE AND METHOD FOR COMMUNICATION DEVICE

Abstract

This disclosure defines a procedure for handling an authentication procedure during an Xn handover, more specifically, when an Xn handover occurs from a serving PLMN to another serving PLMN during the authentication procedure.

Description

[Technical field]

[0001] The present disclosure relates generally to wireless communications, and more particularly, in embodiments, to handling an authentication procedure when an Xn handover occurs from a serving PLMN to another serving PLMN during the authentication procedure. [Background technology]

[0002] The purpose of the primary authentication and key agreement procedure is to enable mutual authentication between the UE and the network, as specified in 3GPP TS 33.501 [5], and to provide keying material that can be used between the UE and the network in subsequent security procedures. AUSF , K SEAF , and K AMF is generated after a successful authentication procedure.

[0003] Two methods are defined. a)EAP based primary authentication and key agreement procedure. b)5G AKA based primary authentication and key agreement procedure.

[0004] The UE and AMF must support the EAP based primary authentication and key agreement procedure and the 5G AKA based primary authentication and key agreement procedure. If the authentication procedure fails in the network, the AMF returns an Authentication Reject message to the UE. The serving network name is used to calculate RES* and XRES* in the UE and UDM, respectively. If the verification of RES* and HRES* is successful in the AUSF, the AUSF considers the authentication procedure successful. The serving network name is used as the anchor key (K AUSF ) which binds the anchor key to the serving network by including the serving network identifier (SN Id). It ensures that the anchor key is specific to the authentication between the 5G core network and the UE by including the service code set to "5G". In 5G AKA, the serving network name has a similar purpose of binding the RES* and XRES* to the serving network. The SN Id identifies the serving PLMN. From the UE's perspective, it is the serving network that the network is authenticating to. In the case of UDM, it is the serving network sent by the AUSF.

[0005] Figure 1 shows the initiation of the authentication procedure and the selection of an authentication method. The SEAF may initiate authentication with the UE during the procedure of establishing a signaling connection with the UE according to the SEAF policy. Based on the SUPI, the UDM / ARPF needs to select an authentication method.

[0006] Figure 2 shows the 5G AKA authentication procedure.

[0007] Meanwhile, Figure 3 shows the Xn handover procedure. In a network deployment scenario, a Registration Area (RA) can be configured with one or more first Tracking Areas (TAs) served by PLMN ID=A and one or more second Tracking Areas (TAs) served by PLMN ID=B. When a UE in connected mode moves from a RAN belonging to a first TA to a RAN belonging to a second TA, the Xn handover procedure is performed. After the Xn handover procedure, the serving network of the UE and the network changes from PLMN ID=A to PLMN ID=B, but the AMF remains the same after the Xn handover procedure. [Prior art documents] [Non-patent literature]

[0008] [Non-Patent Document 1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". V16.0.0 (2019-06) [Non-Patent Document 2] 3GPP TS 23.501: "System architecture for the 5G System (5GS)". V16.6.0 (2020-09) [Non-Patent Document 3] 3GPP TS 23.502: “Procedures for the 5G System (5G”S)” V16.6.0 (2020-09) [Non-Patent Document 4] GPP TS 24.501: "Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3" V16.6.0 (2020-09) [Non-Patent Document 5] 3GPP TS 33.501: "Security architecture and procedures for 5G system" V16.4.0 (2020-09) [Non-Patent Document 6] 3GPP TS 33.102: "3G Security; Security architecture" V16.0.0 (2020-07) [Non-Patent Document 7] 3GPP TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)" V16.6.0 (2020-09) [Non-Patent Document 8] 3GPP TS 29.272: "Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol" V16.4.0 (2020-09) Summary of the Invention [Problem to be solved by the invention]

[0009] The AMF may initiate the authentication procedure at any time based on local policy. A possible scenario is that during an ongoing authentication procedure, an Xn handover takes place from one serving PLMN to another. In this scenario, the UE and the 5G core network (e.g. AUSF, UDM) are not synchronized with respect to the current serving PLMN. That is, the UE may maintain the PLMN after the Xn handover procedure has taken place, while the 5G core network may maintain the PLMN before the Xn handover procedure has taken place. This mismatch between the UE and the 5G core network may lead to a failure of the authentication procedure, and therefore the user will not be able to access services. [Means for solving the problem]

[0010] In a first aspect of the present disclosure, a method of a communications device is provided, the method comprising: performing a registration procedure for a user equipment (UE) to a first Public Land Mobile Network (PLMN); sending a first message to perform authentication of the UE, the first message including an identifier of the first PLMN; performing a handover procedure for the UE involving a change from the first PLMN to a second PLMN; receiving a second message, the second message including an identifier of the first PLMN; and sending an authentication request message to the user equipment, the authentication request message including the identifier of the first PLMN.

[0011] In a second aspect of the present disclosure, a method is provided for a user equipment (UE), the method comprising: performing a registration procedure with a first public land mobile network (PLMN); performing a handover procedure involving a change from the first PLMN to a second PLMN; receiving an authentication request message, the authentication request message including an identifier of the first PLMN; and performing an authentication procedure based on the identifier of the first PLMN.

[0012] In a third aspect of the present disclosure, a communications device comprises means for performing a registration procedure for a user equipment (UE) with a first Public Land Mobile Network (PLMN), means for sending a first message for performing authentication of the UE, the first message including an identifier of the first PLMN, means for performing a handover procedure of the UE involving a change from the first PLMN to a second PLMN, means for receiving a second message, the second message including an identifier of the first PLMN, and means for sending an authentication request message to the user equipment, the authentication request message including the identifier of the first PLMN.

[0013] In a fourth aspect of the present disclosure, a user equipment (UE) comprises means for performing a registration procedure for a first public land mobile network (PLMN), means for performing a handover procedure involving a change from the first PLMN to a second PLMN, means for receiving an authentication request message, the authentication request message including an identifier of the first PLMN, and means for performing an authentication procedure based on the identifier of the first PLMN.

[0014] In a fifth aspect of the present disclosure, a method of a communications device is provided, the method comprising: performing a registration procedure for a user equipment (UE) to a first public land mobile network (PLMN); sending a first message to perform authentication of the UE, the first message including an identifier of the first PLMN; performing a handover procedure for the UE involving a change from the first PLMN to a second PLMN; receiving a second message, the second message including an identifier of the second PLMN; determining whether the handover procedure occurred while authentication using the identifier of the first PLMN is in progress; and if the handover procedure occurred while authentication using the identifier of the first PLMN is in progress, sending an authentication request message to the UE, the authentication request message including the identifier of the first PLMN.

[0015] In a sixth aspect of the present disclosure, a communications device comprises: means for performing a registration procedure for a user equipment (UE) with a first public land mobile network (PLMN); means for sending a first message for performing authentication of the UE, the first message including an identifier of the first PLMN, means for performing a handover procedure of the UE involving a change from the first PLMN to a second PLMN, means for receiving a second message, the second message including an identifier of the second PLMN, means for determining whether the handover procedure occurred while authentication using the identifier of the first PLMN is in progress, and means for sending an authentication request message to the UE if the handover procedure occurred while authentication using the identifier of the first PLMN is in progress, the authentication request message including the identifier of the first PLMN.

[0016] In a seventh aspect of the present disclosure, a method of a communications device is provided, the method comprising: performing a registration procedure for a user equipment (UE) with a Public Land Mobile Network (PLMN); storing an identifier of the PLMN; and using the identifier for an authentication procedure of the UE.

[0017] In an eighth aspect of the present disclosure, a method is provided for a user equipment (UE), the method performing a registration procedure with a Public Land Mobile Network (PLMN), storing an identifier of the PLMN, and using the identifier for an authentication procedure of the UE.

[0018] In a ninth aspect of the present disclosure, a communications device comprises means for performing a registration procedure for a user equipment (UE) with a Public Land Mobile Network (PLMN), means for storing an identifier of the PLMN, and means for using the identifier for an authentication procedure of the UE.

[0019] In a tenth aspect of the present disclosure, a user equipment (UE) comprises means for performing a registration procedure with a Public Land Mobile Network (PLMN), means for storing an identifier of the PLMN, and means for using the identifier for an authentication procedure of the UE.

[0020] In an eleventh aspect of the present disclosure, a method of a communications device is provided, the method comprising: performing a registration procedure for a user equipment (UE) with a first Public Land Mobile Network (PLMN); receiving a first message during a handover procedure involving a change from the first PLMN to a second PLMN, the first message including an identifier of the second PLMN; and sending a second message to a Unified Data Management (UDM), the second message including an identifier of the second PLMN.

[0021] In a twelfth aspect of the present disclosure, a communications device comprises means for performing a registration procedure for a user equipment (UE) with respect to a first Public Land Mobile Network (PLMN); means for receiving a first message during a handover procedure involving a change from a first PLMN to a second PLMN; and means for transmitting a second message to a Unified Data Management (UDM), the first message including an identifier of the second PLMN, the second message including an identifier of the second PLMN.

[0022] In a thirteenth aspect of the present disclosure, a method of a communications device is provided, the method comprising: performing a registration procedure for a user equipment (UE) to a first public land mobile network (PLMN); sending a first message to authenticate the UE, the first message including an identifier of the first PLMN; performing a handover procedure involving a change from the first PLMN to a second PLMN; determining whether the handover has been performed while authentication is in progress; and sending a second message to authenticate the UE, the second message including an identifier of the second PLMN.

[0023] In a fourteenth aspect of the present disclosure, a communications device comprises means for performing a registration procedure for a user equipment (UE) with a first public land mobile network (PLMN), means for sending a first message for authenticating the UE, the first message including an identifier of the first PLMN, means for performing a handover procedure involving a change from the first PLMN to a second PLMN, means for determining whether the handover has been performed while authentication is in progress, and means for sending a second message to authenticate the UE, the second message including an identifier of the second PLMN.

[0024] In a fifteenth aspect of the present disclosure, a method of a communications device is provided, the method comprising: performing a registration procedure for a user equipment (UE) with a Public Land Mobile Network (PLMN); receiving a first message during a handover procedure involving a change from a first PLMN to a second PLMN, the first message including an identifier of the second PLMN; allocating a 5G Globally Unique Temporary Identifier (5G-GUTI) based on the identifier of the second PLMN when the first message is received; and transmitting the 5G-GUTI to the UE.

[0025] In a sixteenth aspect of the present disclosure, a communications device comprises: means for performing a registration procedure for a user equipment (UE) with a Public Land Mobile Network (PLMN); means for receiving a first message during a handover procedure involving a change from a first PLMN to a second PLMN, the first message including an identifier of the second PLMN, means for assigning a 5G Globally Unique Temporary Identifier (5G-GUTI) based on the identifier of the second PLMN when the first message is received; and means for transmitting the 5G-GUTI to the UE. [Brief description of the drawings]

[0026] [Figure 1] FIG. 1 is a general sequence diagram showing the initiation of an authentication procedure and the selection of an authentication method. [Diagram 2] Figure 2 is a general sequence diagram showing the authentication procedure for 5G AKA. [Diagram 3] FIG. 3 is a general sequence diagram showing a procedure of Xn handover. [Figure 4] Figure 4 shows the encoding of the SN id as an octet string. [Diagram 5] FIG. 5 is a sequence diagram illustrating an embodiment of a procedure for processing an authentication procedure involving an Xn handover. [Figure 6] FIG. 6 is a sequence diagram illustrating an embodiment of a procedure for processing an authentication procedure involving an Xn handover. [Figure 7] FIG. 7 is a sequence diagram illustrating one embodiment of a procedure for handling authentication procedures during an Xn handover. [Figure 8] FIG. 8 is a block diagram showing a schematic diagram of a UE. [Figure 9] FIG. 9 is a block diagram showing a schematic diagram of an (R)AN. [Figure 10] FIG. 10 is a block diagram showing a schematic diagram of the AMF. [Figure 11] FIG. 11 is a diagram showing an authentication procedure of EAP-AKA'. [Figure 12] FIG. 12 is a diagram showing the authentication procedure for 5G AKA. [Figure 13] FIG. 13 is a diagram showing an authentication procedure of EAP-AKA'. [Figure 14] FIG. 14 is a diagram showing the authentication procedure for 5G AKA. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] This disclosure provides a procedure for handling an authentication procedure during an Xn handover, and more specifically, defines the handling of the authentication procedure when an Xn handover occurs from one serving PLMN to another serving PLMN during the authentication procedure.

[0028] To further clarify the advantages and features of the present disclosure, a more particular description of the present disclosure will be rendered by reference to specific embodiments thereof which are illustrated in the accompanying drawings, It is to be understood that these drawings depict only typical embodiments of the disclosure and therefore are not to be considered limiting of scope.

[0029] The present disclosure will now be explained with further specifics and details using the accompanying figures.

[0030] Additionally, those skilled in the art will appreciate that elements in the figures may be simply illustrated and not necessarily drawn to scale. Furthermore, with respect to the configuration of a device, one or more components of the device may be represented in the figures by generic symbols, and the figures may show only the specific details pertinent to understanding the embodiments of the present disclosure, so as not to obscure the figures with details that will be readily apparent to one of ordinary skill in the art having the benefit of the description herein.

[0031] For the purposes of promoting an understanding of the principles of the disclosure, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended. Such modifications and further modifications in the illustrated systems, and further applications of the principles of the disclosure which would normally occur to one skilled in the art, are to be construed as being within the scope of the disclosure.

[0032] overview Here, the service network will be described.

[0033] Serving Network Name The serving network name is used to derive the anchor key, which generally serves two purposes: - Bind the anchor key to a serving network by including a serving network identifier (SN Id). -By including the service code set to “5G”, it is made clear that the anchor key is specific to the authentication between the 5G core network and the UE.

[0034] In the 5G AKA based primary authentication and key agreement procedure, the serving network name has a similar purpose of binding RES* and XRES* to a serving network. The serving network name is the concatenation of the service code and the SN Id with a separator ":", such that the service code precedes the SN Id.

[0035] NOTE: Parameters like "Access Network Type" are not used for the Serving Network Name as they are related to 5G Core procedures that are access network independent. The SN Id identifies the serving PLMN and is defined as the SNN-network-identifier in 3GPP TS 24.501 [4], except for standalone non-public networks.

[0036] UE constructs serving network name The UE constructs the serving network name as follows: -The service code will be "5G." - Let the network identifier be the SN Id of the authenticating network. - Concatenate the service code and the SN Id with the separator ":".

[0037] SEAF's Serving Network Name Construction The SEAF constructs the serving network name as follows: -The service code will be "5G." - The network identifier is the SN Id of the serving network to which the AUSF sends the authentication data. - Concatenate the service code and the SN Id with the separator ":".

[0038] The AUSF obtains the serving network name from the SEAF. Before using the serving network name, the AUSF verifies that the SEAF is authorized to use the serving network name.

[0039] All the embodiments are also applicable to the EAP based primary authentication and agreement procedure.

[0040] In this disclosure, unless otherwise specified, primary "authentication and key agreement procedure" means either "EAP based primary authentication and agreement procedure" or "5G AKA based primary authentication and key agreement procedure."

[0041] In this disclosure, unless otherwise specified, the term "authentication procedure" means either "EAP based primary authentication and agreement procedure" or "5G AKA based primary authentication and key agreement procedure."

[0042] The term AMF in this disclosure can be interpreted as SEAF. The term KAUSF can be interpreted as Kausf or K AUSF The term KSEAF can be interpreted as SEAF The term KAMF can be interpreted as AMF The following embodiment is not limited to 5GS, and can be applied to communication systems other than 5GS, such as EPS AKA.

[0043] When the following embodiment is applied to an EPS, the following substitutions are required.

[0044] Step replacement -Replace "5G AKA based primary authentication and key agreement procedure" with "EPS AKA procedure". -Replace the 'Xn handover procedure' with the 'X2-based handover procedure'.

[0045] Node name replacement -Replace AMF and SEAF with MME. -Replace UDM and ARPF with HSS. -Replace AUSF with HSS.

[0046] Message replacement -Replace the Registration Request message with either an Attach Request message or a Tracking Area Update message. -N2 Replace Path Switch Request with Path Switch Request message. -Replace the Nausf_UEAuthentication_Authenticate Request message with the Authentication Information Request message defined in 3GPP TS 29.272 [8]. -Replace the Nudm_UEAuthentication_Get Request message with the Authentication Information Request message defined in 3GPP TS 29.272 [8]. -Replace the combination of the Nausf_UEAuthentication_Authenticate Request message and the Nudm_UEAuthentication_Get Request message with the Authentication Information Request message defined in 3GPP TS 29.272 [8]. -Replace the Nudm_Authentication_Get Response message with the Authentication Information Answer message defined in 3GPP TS 29.272 [8]. -Replace the Nausf_UEAuthentication_Authenticate Response with the Authentication Information Answer message defined in 3GPP TS 29.272 [8]. -Replace the combination of the Nudm_Authentication_Get Response message and the Nausf_UEAuthentication_Authenticate Response message with the Authentication Information Answer message defined in 3GPP TS 29.272 [8].

[0047] Parameter Substitution -Replace SUCI and SUPI with IMSI. -Replace 5G-GUTI with GUTI or 4G-GUTI. -Replace ngKSI with KSI. -Replace Serving Network Name with Serving Network Identity as shown in Figure 4. The Serving Network identity (SN-Id) is used to derive the KASME in the UE and MME. The coding of the MCC and MNC digits is defined in 3GPP TS 24.301 [7].

[0048] In addition to the above examples, the procedures, node names, messages, and parameters of 5GS can also be replaced with the corresponding procedures, corresponding node names, corresponding messages, and corresponding parameters in EPS.

[0049] In the following embodiment, the UE receives the first K based on the PLMN ID=A. AUSF and a second K based on PLMN ID=B AUSF The two K's AUSF The UE calculates the first K AUSF Using the first K AUSF If the security procedure using K fails, the UE shall use the second K in the security procedure. AUSF Using the first K AUSF otherwise, the UE deletes the second K AUSF The same method is applied to the EPS case, so ASME Calculate and use.

[0050] 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 belongs. The systems, methods, and examples provided herein are illustrative only and are not intended to be limiting.

[0051] The terms "comprises", "comprising", or other variations are intended to cover a non-exclusive inclusion, and a process or method comprising a list of steps may not include only those steps, but may include other steps not expressly listed in such process or method. Similarly, the term "comprises~a" followed by one or more devices or entities or subsystems or elements or structures or components does not preclude the presence of other devices, subsystems, elements, structures, components, additional devices, additional subsystems, additional elements, additional structures or additional components, unless there are more constraints. The appearance of the phrases "embodiments", "other embodiments", and similar terms throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0052] In the following specification and claims, reference will be made to a number of terms, which shall be defined to have the following meanings: The singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise.

[0053] As used herein, information is associated with data and knowledge because data is meaningful information and represents values ​​attributed to parameters. Furthermore, knowledge refers to an understanding of an abstract or concrete concept. It should be noted that this example system has been simplified to facilitate explanation of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other devices, systems, and configurations may be used in addition to or in place of the system to implement the embodiments disclosed herein, and all such embodiments are contemplated as being within the scope of this disclosure.

[0054] Embodiment 1 (Solution 1)

[0055] The network sends the serving network name to the UE in an Authentication Request message and uses the serving network name to calculate security parameters (e.g., RES* and Anchor Key (e.g., KAUSF)).

[0056] Figures 5 and 6 explain the process of the authentication procedure when an Xn handover with PLMN change occurs during the authentication procedure. In the 5G AKA based primary authentication and key agreement procedure, the serving network name has a similar purpose of binding RES* and XRES* to the serving network.

[0057] Note that Figure 6 is a continuation of the bottom of Figure 5.

[0058] The detailed processing of the embodiment will be described below.

[0059] 0. The UE and the network (e.g. RAN, AMF, etc.) perform a registration procedure. Then, the UE is registered to the PLMN with PLMN ID=A. PLMN ID is an identifier or identity that identifies a PLMN. "PLMN ID=A" means that the PLMN ID is "A" or the PLMN ID is set to "A". In other words, the UE is registered to the PLMN identified by the PLMN ID which is "A". The registration area includes at least two Tracking Areas (TA1 provided by PLMN ID=A and TA2 provided by PLMN ID=B). "PLMN ID=B" means that the PLMN ID is "B" or the PLMN ID is set to "B". This registration area is assigned to the UE during the registration procedure.

[0060] 1. The UE initiates a service request procedure. The UE establishes an RRC connection in a cell with PLMN ID=A. After the RRC connection is established, the UE sends a Service request message to the AMF.

[0061] Note that the Service request message in step 1 can be any NAS message.

[0062] 2. The AMF receives a Service request message from the UE. The AMF may then initiate the authentication procedure of the UE (e.g., based on local policy) by sending a Nausf_UEAuthentication_Authenticate Request (SUPI, SN name=PLMN ID=A) to the AUSF. "SN name=PLMN ID=A" means that the SN name is a PLMN ID that is "A" or the SN name is a PLMN ID set to "A". In other words, "SN name=PLMN ID=A" means that the SN name identifies a PLMN identified by a PLMN ID that is "A" or a PLMN with a PLMN ID that is "A". In other words, the AMF informs the AUSF that the SN name is a PLMN ID that is "A".

[0063] 3. When the AUSF receives the Nausf_UEAuthentication_Authenticate Request message, it sends a Nudm_UEAuthentication_Get Request (SUCI or SUPI, SN name = PLMN ID = A) to the UDM. That is, the AUSF notifies the UDM that the SN name is the PLMN ID "A".

[0064] 4. An Xn handover procedure is triggered in the network to handover the UE to a cell served by PLMN ID=B in TA2. For example, an Xn handover may be triggered when the UE moves from TA1 to TA2.

[0065] 4-1. During the Xn handover procedure, the UE sends an RRC message (e.g., an RRC Reconfiguration Complete message) to the target RAN, the RRC message including PLMN ID=B as the selected PLMN-Identity. For example, the UE selects PLMN ID=B as the selected PLMN-Identity before sending the RRC message (e.g., an RRC Reconfiguration Complete message).

[0066] 4-2. During the Xn handover procedure, the target RAN (e.g., Target gNB) sends to the AMF an N2 Path switch request message including or containing PLMN ID=B (i.e., an N2 Path switch request including a PLMN ID of "B"). For example, the PLMN ID is included in the E-UTRA CGI parameter included in the User Location Information parameter.

[0067] 5. When UDM receives the Nudm_UEAuthentication_Get Request message, it generates (or calculates) an XRES* based on the serving PLMN name PLMN ID=A. That is, UDM generates an XRES* based on the PLMN ID being "A".

[0068] 6. The UDM derives (or calculates) the KAUSF based on the serving PLMN name PLMN ID=A. That is, the UDM derives the KAUSF based on the PLMN ID being “A”.

[0069] 7.UDM sends Nudm_Authentication_Get Response (SUPI, 5G HE AV, SN for authentication=PLMN ID=A) to AUSF. Serving Network (SN) with authentication=PLMN ID=A is an optional parameter. "SN for authentication =PLMN ID=A" means that SN for authentication is the PLMN ID of "A" or SN for authentication is the PLMN ID set to "A". That is, SN for authentication indicates the PLMN ID used in the authentication procedure (e.g., SN for authentication indicates the PLMN ID used to calculate RES* by the UE and derive KAUSF by the UE).

[0070] 8. AUSF stores XRES*. AUSF generates 5G AV from 5GHE AV, HXRES from XRES*, and KSEAF from KAUSF.

[0071] 9. The AUSF sends a Nausf_UEAuthentication_Authenticate Response (5G SE AV (RAND, AUTN, HXRES*, SN for authentication=PLMN ID=A) to the AMF. Serving Network (SN) for authentication is an optional parameter. The AUSF may send Serving Network (SN) for authentication when it receives Serving Network (SN) for authentication from the UDM.

[0072] 10. Upon receiving the Nausf_UEAuthentication_Authenticate Response, the AMF sends an Authentication Request message containing (ngKSI, ABBA, RAND, AUTN and SN for authentication=PLMN ID=A). The SN for authentication is the SN name sent from the AMF to the AUSF in step 2. In one example, the SN for authentication is the same as the one received from the AUSF in the Nausf_UEAuthentication_Authenticate Response message in step 9.

[0073] 11.When the UE receives the Authentication Request message, the UE verifies the AUTN. After the AUTN verification is successful, the UE calculates (or generates) RES* using SN for authentication=PLMN ID=A. That is, the UE calculates RES* based on the PLMN ID which is "A".

[0074] 12. The UE derives (or generates) KAUSF using SN for authentication = PLMN ID = A. That is, the UE derives KAUSF based on the PLMN ID being "A". The UE stores KAUSF and uses it when needed for security procedures (e.g. derivation of security key KSEAF).

[0075] 13. The UE sends an authentication response message containing RES* to the AMF.

[0076] 14.When the AMF receives an authentication response message from the UE, it derives HRES* from RES* and compares HRES* with HXRES*.

[0077] 15. If the comparison is successful, the AMF sends a Nausf_UEAuthentication_Authenticate Request message including RES* to the AUSF.

[0078] 16. When the AUSF receives a Nausf_UEAuthentication_Authenticate Request message containing RES*, it compares RES* with XRES*.

[0079] 17. If the comparison is successful, then in AUSF, KSEAF is calculated from KAUSF.

[0080] 18. The AUSF sends a Nausf_UEAuthentication_Authenticate Response message including Result, SUPI, and KSEAF to the AMF. The Result includes the result of the authentication procedure based on the comparison of RES* and XRES* in the AUSF. That is, the Result may be information indicating the result of the authentication procedure based on the comparison of RES* and XRES* in the AUSF.

[0081] 19. Upon receiving the Nausf_UEAuthentication_Authenticate Response message, the AMF checks the Result (e.g., the AMF checks the information element (IE) indicating the Result). If the Result indicates that the authentication was successful, the AMF continues with the service request procedure triggered by step 1.

[0082] 20. The AMF may initiate a new authentication procedure towards the AUSF by sending the Nausf_UEAuthentication_Authenticate Response message with PLMN ID=B according to the procedures described in 3GPP TS 33.501 [5]. After successful completion of the authentication procedure, the UE and the UDM / AUSF are synchronized with the same KAUSF created during the new authentication procedure. For example, the UE and the UDM / AUSF are synchronized with the same KAUSF created based on PLMN ID=B (i.e., PLMN ID is "B").

[0083] In one example, in step 1, the UE is in connected mode and at least a user plane bearer (Dedicated Radio Bearer) is established. The AMF decides to perform an authentication procedure according to local policy. In this case, the authentication procedure is started independently of receiving a NAS message from the UE.

[0084] Variation 1 of Solution 1

[0085] As an example, when the AMF receives an N2 Path switch request message from a target RAN with PLMN ID=B, it can understand that the authentication procedure initiated in step 2 is associated with PLMN ID=A while the latest PLMN ID=B. For example, based on sending a Nausf_UEAuthentication_Authenticate Request in step 2 and receiving an N2 Path switch request message from a target RAN with PLMN ID=B in step 4-2, the AMF can determine and understand whether an Xn handover with PLMN change has occurred during the progress of the authentication procedure. That is, the AMF understands the mismatch of PLMN IDs (one is the latest one and the other is the one used for the authentication procedure). In this case, the AMF memorizes this mismatch and sets PLMN ID=A as the SN for authentication when the AMF sends an Authentication Request message to the UE in step 10. Then, the AMF sends an Authentication Request message including the SN for authentication indicating the PLMN ID set to "A". In this example, neither the UDM nor the AUSF needs to process the SN for authentication.

[0086] Variation 2 of Solution 1

[0087] In step 0, when the UE is registered with the AMF for the first time, the UE and the AMF store the serving PLMN ID with which the UE is registered. This serving PLMN ID is stored in the UE and the AMF as the SN for authentication while the UE is registered with the AMF. If the UE is registered in a different registration area but served by the same AMF, the UE and the AMF may update the SN for authentication. The UE and the AMF use the SN name based on this SN for authentication in subsequent authentication procedures triggered by the AMF. In this embodiment, the SN for authentication is the PLMN ID=A used by the UE and the AMF in the authentication procedures from step 2 to step 18. Note that in this variant 2, the SN for authentication parameters in steps 7, 9, and 10 are not required.

[0088] Variation 3 of Solution 1

[0089] In one example, regardless of whether the UE authentication procedure is in progress, the AMF sends a message including a new serving PLMN ID=B to the UDM during the Xn handover procedure with PLMN change or after the Xn handover procedure with PLMN change is successful. For example, the AMF may send a message including information indicating that the new serving PLMN ID is "B" to the UDM when the AMF receives an N2 Path switch request message including a PLMN ID set to "B" during the Xn handover procedure with PLMN change. Further, for example, the AMF may send a message including information indicating that the new serving PLMN ID is "B" to the UDM after the AMF sends an N2 Path switch request ack (acknowledgement) message in response to receiving the N2 Path switch request message including the PLMN ID set to "B". Upon receiving the message, the UDM updates the UE's current serving PLMN to PLMN ID=B. The UDM may take some action when the UE's serving PLMN is changed to PLMN ID=B. That is, the UDM updates the serving PLMN ID of the UE to the PLMN ID that is "B". For example, the UDM may trigger a Steering of Roaming (SoR) procedure for the UE to send a new preferred PLMN list to the UE, or may trigger a UE Parameter Update (UPU) procedure.

[0090] Variation 4 of Solution 1

[0091] In one example, after the authentication procedure is successfully completed (after step 18), the AMF sends a message (e.g., Nudm_UECM_Registration service) including PLMN ID=B to the UDM to update the UDM with the new serving PLMN of the UE. That is, the AMF sends a message including information indicating that the new serving PLMN ID is "B" to the UDM. When the UDM receives this message, it updates the serving PLMN ID of the UE to PLMN ID=B. That is, the UDM updates the serving PLMN ID of the UE to the PLMN ID which is "B".

[0092] Variation 5 of Solution 1

[0093] As an example, when the UE receives an Authentication Request message from the AMF in step 10, if the UE has a valid 5G-GUTI, it checks whether the MCC and MNC parts of the latest PLMN ID (e.g., PLMN ID=B) sent in an RRC message (e.g., RRC Reconfiguration Complete message) to the target RAN in step 4-1 are the same as the MCC and MNC parts of the 5G-GUTI. If the MCC and MNC parts are not the same, the UE constructs a Serving Network Name (i.e., SN for authentication) using the MCC and MNC parts of the 5G-GUTI according to 3GPP TS 33.501 [5], performs the calculation (or generation) of RES* in step 11 using the Serving Network Name constructed based on the MCC and MNC parts of the 5G-GUTI, and performs the derivation (or generation) of KAUSF in step 12 using the Serving Network Name constructed based on the MCC and MNC parts of the 5G-GUTI.

[0094] Variation 6 of Solution 1

[0095] As an example, when the UE receives an Authentication Request message from the MME in step 10 for the EPS AKA procedure in EPS, the UE checks whether the MCC and MNC parts of the latest PLMN ID (e.g., PLMN ID=B) sent in an RRC message (e.g., RRC Connection Reconfiguration Complete message) to the target RAN in step 4-1, if there is a valid 4G-GUTI, are the same as the MCC and MNC parts of the 4G-GUTI. If the MCC and MNC parts are not the same, the UE uses the MCC and MNC parts of the 4G-GUTI to construct a Serving Network Identity (i.e., SN for authentication), uses the Serving Network Identity constructed based on the MCC and MNC parts of the 4G-GUTI to calculate (or generate) RES* in step 11, and uses the Serving Network Identity constructed based on the MCC and MNC parts of the 4G-GUTI to derive (or generate) KASME in step 12, as shown in FIG.

[0096] Variation 7 of Solution 1

[0097] In one example, when the AMF receives a Nausf_UEAuthentication_Authenticate Response message from the AUSF in step 9, the AMF checks whether the MCC and MNC parts of the latest PLMN ID (e.g., PLMN ID=B) received in the N2 Path switch request message in step 4-2 are the same as the MCC and MNC parts of the 5G-GUTI if there is a valid 5G-GUTI. If the MCC and MNC parts are not the same, the AMF sends a Nausf_UEAuthentication_Authenticate Request message (SUCI or SUPI, SN name=PLMN ID=B) to the AUSF to initiate a new authentication procedure with SN name=PLMN ID=B. "SN name=PLMN ID=B" means that the SN name is the PLMN ID that is "B" or the SN name is the PLMN ID that is set to "B". In other words, "SN name=PLMN ID=B" means that the SN name identifies a PLMN identified by a PLMN ID that is "B" or identifies a PLMN that has a PLMN that is "B." In other words, the AMF notifies the AUSF that the SN name is a PLMN ID that is "B."

[0098] The AMF does not proceed with the authentication procedure started in step 2, i.e. the AMF aborts the authentication procedure started in step 2.

[0099] Variation 8 of Solution 1

[0100] In one example, when the MME receives an Authentication Information Answer message from the HSS in step 9 or a combination of steps 7 and 9, the MME checks whether the MCC and MNC parts of the latest PLMN ID received in the Path switch request message in step 4-2 are the same as the MCC and MNC parts of the 4G-GUTI if there is a valid 4G-GUTI. If the MCC and MNC parts are not the same, the MME sends an Authentication Information Request message (IMSI, SN id=PLMN ID=B) to the HSS to initiate a new authentication procedure with SN id=PLMN ID=B. "SN id=PLMN ID=B" means that the SN id is a PLMN ID that is "B" or the SN id is a PLMN ID that is set to "B". In other words, "SN id=PLMN ID=B" means that the SN id identifies the PLMN identified by the PLMN ID that is "B" or the PLMN with the PLMN ID that is "B". That is, the MME informs the HSS that the SN id is the PLMN ID "B".

[0101] The MME does not proceed with the authentication started in step 2, i.e. the MME aborts the authentication procedure started in step 2.

[0102] Embodiment 2 (Solution 2)

[0103] If the AMF detects that 1) authentication is in progress and 2) an Xn handover with PLMN change has occurred, the AMF initiates the authentication procedure.

[0104] The process of the authentication procedure during Xn handover is shown in Figure 7.

[0105] The detailed process of the embodiment will be described below.

[0106] 0. The UE and the network (e.g. RAN, AMF, etc.) perform a registration procedure. And the UE is registered to a PLMN with PLMN ID=A. "PLMN ID=A" means that the PLMN ID is "A" or the PLMN ID is set to "A". That is, the UE is registered to a PLMN identified by the PLMN ID which is "A". The registration area includes at least two Tracking Areas (TA1 provided by PLMN ID=A and TA2 provided by PLMN ID=B). "PLMN ID=B" means that the PLMN ID is "B" or the PLMN ID is set to "B". This registration area is assigned to the UE during the registration procedure.

[0107] 1. The UE initiates a service request procedure. The UE establishes an RRC connection in a cell with PLMN ID=A. After the RRC connection is established, the UE sends a Service request message to the AMF.

[0108] Note that the Service request message in step 1 can be any NAS message.

[0109] 2. The AMF receives a Service request message from the UE. Then, the AMF may initiate the authentication procedure (e.g., according to local policy) of the UE by sending a Nausf_UEAuthentication_Authenticate Request (SUPI, SN name=PLMN ID=A) to the AUSF. "SN name=PLMN ID=A" means that the SN name is the PLMN ID that is "A" or the SN name is the PLMN ID that is set to "A". That is, the AMF informs the AUSF that the SN name is the PLMN ID that is "A".

[0110] 3. When the AUSF receives the Nausf_UEAuthentication_Authenticate Request message, it sends a Nudm_UEAuthentication_Get Request (SUCI or SUPI, SN name=PLMN ID=A) to the UDM. That is, the AUSF notifies the UDM that the SN name is the PLMN ID "A".

[0111] 4. An Xn handover procedure is triggered in the network, and the UE is handed over to a serving cell with PLMN ID=B in TA2. For example, an Xn handover may be triggered when the UE moves from TA1 to TA2.

[0112] 4-1. During the Xn handover procedure, the UE sends an RRC message (e.g., an RRC Reconfiguration Complete message) to the target RAN, including PLMN ID=B as the selected PLMN-Identity. For example, the UE selects PLMN ID=B as the selected PLMN-Identity before sending an RRC message (e.g., an RRC Reconfiguration Complete message).

[0113] 4-2. During the Xn handover procedure, the target RAN (e.g., the target gNB) sends an N2 Path switch request message including or containing PLMN ID=B (i.e., the N2 Path switch request message includes a PLMN ID that is "B") to the AMF. For example, the PLMN ID is included in the E-UTRA CGI parameter included in the User Location Information parameter.

[0114] 5. If the AMF detects during the authentication procedure that the UE has moved to a PLMN identified by PLMN ID=B due to an Xn handover with PLMN change, it initiates a new authentication procedure towards the AUSF / UDM using SN name=PLMN ID=B. For example, the AMF may detect (or determine) that the UE has moved to a PLMN identified by a PLMN ID that is "B" by receiving an N2 Path switch request message including a PLMN ID set to "B" in step 4-2 during the authentication procedure initiated in step 2. Also, for example, the AMF may detect (or determine) that the UE has moved to a PLMN identified by a PLMN ID that is "B" by sending an N2 Path switch request ack (acknowledgement) message in response to receiving an N2 Path switch request message including a PLMN ID set to "B" in step 4-2 during the authentication procedure initiated in step 2. Further, for example, if the AMF detects (or determines) that an Xn handover with PLMN change has occurred while the authentication procedure is in progress based on sending a Nausf_UEAuthentication_Authenticate Request in step 2 and receiving an N2 Path switch request message from the target RAN with PLMN ID=B in step 4-2, the AMF may then initiate a new authentication procedure for the AUSF / UDM using SN name=PLMN ID=B.

[0115] 6. The AMF sends a Nausf_UEAuthentication_Authenticate Request message (SUCI or SUPI, SN name=PLMN ID=B) to the AUSF to initiate a new authentication procedure with SN name=PLMN ID=B. "SN name=PLMN ID=B" means that the SN name is a PLMN ID that is "B" or the SN name is a PLMN ID that is set to "B". In other words, "SN name=PLMN ID=B" means that the SN name identifies a PLMN identified by a PLMN ID that is "B" or a PLMN with a PLMN ID that is "B". That is, the AMF informs the AUSF that the SN name is a PLMN ID that is "B". The AMF does not proceed with the authentication procedure started in step 2. That is, the AMF aborts the authentication procedure started in step 2.

[0116] In one example, the AMF initiates a new authentication procedure when it receives a response message (e.g., Nausf_UEAuthentication_Authenticate Response) from the AUSF in response to the Nausf_UEAuthentication_Authenticate Request message (SUCI or SUPI, SN name=PLMN ID=A) in step 2. In this case, the AMF ignores and discards the Nausf_UEAuthentication_Authenticate Response message in response to the Nausf_UEAuthentication_Authenticate Request message (SUCI or SUPI, SN name=PLMN ID=A) in step 2.

[0117] From step 6 onwards, a new authentication procedure based on SN name=PLMN ID=B (i.e., PLMN ID is "B") proceeds between the UE and the network.

[0118] Variation 1 of Solution 2

[0119] In one example, in step 5, when the AMF determines that the serving PLMN has changed to PLMN ID=B when it receives the N2 PATH SWITCH REQUEST message, after the completion of the Xn handover procedure, the AMF allocates a new 5G-GUTI based on PLMN ID=B (i.e., the MCC and MNC parts of PLMN ID=B are assigned to the MCC and MNC of 5G-GUTI). For example, after sending the N2 Path switch request ack (acknowledgement) message, the AMF allocates a new 5G-GUTI based on PLMN ID=B. Then, the AMF sends the new 5G-GUTI to the UE in a CONFIGURATION UPDATE COMMAND message, and after receiving the CONFIGURATION UPDATE COMPLETE message, the AMF sends a Nausf_UEAuthentication_Authenticate Request message (SUCI or SUPI, SN name=PLMN ID=B) to the AUSF to initiate a new authentication procedure. If the UE receives an Authentication Request message after completing the generic UE configuration update command procedure, the UE shall use the MCC and MNC parts of the GUTI to determine the AUSF And calculate the SN name for calculating RES*.

[0120] Variation 2 of Solution 2

[0121] In one example, in step 5, when the MME determines that the serving PLMN has changed to PLMN ID=B when it receives the PATH SWITCH REQUEST message, after the X2 handover procedure is completed, the MME allocates a new 4G-GUTI based on PLMN ID=B (i.e., the MCC and MNC parts of PLMN ID=B are assigned to the MCC and MNC of 4G-GUTI). For example, the MME allocates a new 4G-GUTI based on PLMN ID=B after sending a Path switch request ack (acknowledgement) message. Then, the MME sends the new 4G-GUTI to the UE in a GUTI reallocation command message, and after receiving a GUTI reallocation complete message, the AMF initiates a new authentication procedure by sending an authentication data request including a SN ID based on PLMN ID=B to the HSS. If the UE receives an Authentication Request message after the completion of the GUTI-reallocation procedure, the UE uses the MCC and MNC parts of the 4G-GUTI to reallocate the 4G-GUTI to the HSS. ASME Calculate the SN ID for the calculation.

[0122] Variation 3 of Solution 2

[0123] In one example, regardless of whether the UE authentication procedure is in progress, if the AMF determines that the serving PLMN has changed to PLMN ID=B when it receives an N2 PATH SWITCH REQUEST message, after the Xn handover procedure is completed, the AMF allocates a new 5G-GUTI based on PLMN ID=B (i.e., the MCC and MNC parts of PLMN ID=B are assigned to the MCC and MNC of the 5G-GUTI). For example, after sending an N2 Path switch request ack (acknowledgement) message, the AMF allocates a new 5G-GUTI based on PLMN ID=B. Then, the AMF sends the new 5G-GUTI to the UE in a CONFIGURATION UPDATE COMMAND message to synchronize the latest PLMN ID and the 5G-GUTI associated with the latest PLMN ID.

[0124] Variation 4 of Solution 2

[0125] In one example, regardless of whether the UE authentication procedure is in progress, when the MME receives a PATH SWITCH REQUEST message, if it determines that the serving PLMN has changed to PLMN ID=B, after the completion of the X2 handover procedure, the MME allocates a new 4G-GUTI based on PLMN ID=B (i.e., the MCC and MNC parts of PLMN ID=B are assigned to the MCC and MNC of the 4G-GUTI). For example, after sending a Path switch request ack (acknowledgement) message, the MME allocates a new 4G-GUTI based on PLMN ID=B. Then, the MME sends the new 4G-GUTI to the UE in a GUTI reallocation command message to synchronize the latest PLMN ID and the 4G-GUTI associated with the latest PLMN ID.

[0126] User equipment (UE)

[0127] FIG. 10 is a block diagram illustrating the main components of a UE (800). As shown, the UE (800) includes a transceiver circuit (802) operable to transmit signals to and receive signals from connected nodes via one or more antennas (801). Although not necessarily shown in FIG. 10, the UE of course has all the usual functionality (such as a user interface) of a conventional mobile device, which may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in memory and / or downloaded, for example, over a telecommunications network or from a removable data storage device (RMD).

[0128] The controller (804) controls the operation of the UE according to software stored in the memory (805). The software includes, among other things, an operating system and a communication control module having at least a transceiver control module. The communication control module (using its transceiver control submodule) is responsible for handling (generating / sending / receiving) signaling and uplink / downlink data packets between the UE and other nodes, such as base stations / (R)AN nodes, MME, AMF (and other core network nodes), etc. Such signaling may include, for example, appropriately formatted signaling messages related to connection establishment and maintenance (e.g. RRC connection establishment and RRC messages), messages related to periodic location updates (e.g. tracking area update, paging area updates, location area update), etc. Such signaling may also include, for example, in the receiving case, broadcast information (e.g. Master Information and System Information).

[0129] (R)AN Node

[0130] FIG. 9 is a block diagram illustrating the main components of an exemplary (R)AN node (900), e.g., a base station ("eNB" in LTE, "gNB" in 5G). As shown, the (R)AN node includes transceiver circuitry (902) operable to transmit signals to and receive signals from connected UEs via one or more antennas (901), and to transmit signals to and receive signals from other network nodes (directly or indirectly) via a network interface (903). A controller (904) controls the operation of the (R)AN node according to software stored in memory (905). The software may be pre-installed in the memory and / or may be downloaded, e.g., via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system and a communications control module having at least a transceiver control module.

[0131] The Communication Control module (using its Transceiver Control sub-module) is responsible for handling (generating / sending / receiving) signaling (e.g., directly or indirectly) between the (R)AN node and other nodes, e.g., UE, MME, AMF, etc. Signaling may include, for example, appropriately formatted signaling messages related to radio connectivity and location procedures (for a particular UE), in particular connection establishment and maintenance (e.g., RRC connection establishment and other RRC messages), messages related to periodic location updates (e.g., Tracking Area Updates, Paging Area Updates, Location Area Updates), S1 AP messages and NG AP messages (i.e., messages with N2 reference point), etc. Such signaling may also include, for example, broadcast information (e.g., Master Info and System Info), if sent.

[0132] The controller (904), if implemented, is also configured (by software or hardware) to handle related tasks such as UE mobility estimate and / or moving trajectory estimation.

[0133] AMF

[0134] FIG. 10 is a block diagram showing the main components of the AMF (1000). The AMF (1000) is included in the 5GC. As shown, the AMF (1000) includes a transceiver circuit (1001) operable to transmit signals to and receive signals from other nodes (including UEs) via a network interface (1004). The controller (1002) controls the operation of the AMF (1000) according to software stored in the memory (1003). The software may be pre-installed in the memory (1003) and / or may be downloaded, for example, via a telecommunications network or from a removable data storage device (RMD). The software includes, among other things, an operating system and a communication control module having at least a transceiver control module.

[0135] The Communication Control module (using its Transceiver Control sub-module) is responsible for handling (generating / sending / receiving) signaling (directly or indirectly) between the AMF and other nodes, e.g., UEs, base stations / (R)AN nodes (e.g., "gNBs" or "eNBs"), etc. Such signaling may include, e.g., appropriately formatted signaling messages related to the procedures described herein, e.g., NG AP messages (i.e., messages over the N2 reference point) for conveying NAS messages to and from the UE, etc.

[0136] User Equipment (or "UE", "mobile station", "mobile device", "wireless device") in this disclosure is an entity connected to a network via a radio interface. The UE in this specification is not limited to a dedicated communication device, but may be any device having the communication function as the UE described in this specification, such as:

[0137] The terms "User Equipment (UE)" (as the term is used in 3GPP), "mobile station", "mobile device" and "wireless equipment" are generally intended to be synonymous with each other and may refer to standalone mobile stations such as terminals, mobile phones, smartphones, tablets, cellular IoT terminals, IoT devices, etc. It will be understood that the terms "UE" and "wireless terminal" also encompass equipment that is stationary for extended periods of time.

[0138] The UE may be, for example, production or manufacturing equipment and / or energy-related machinery (e.g. equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power plants; nuclear power plants; batteries; nuclear systems and / or related equipment; heavy electrical equipment; pumps including vacuum pumps; compressors; fans; blowers; hydraulic equipment; pneumatic equipment; metal processing machinery; manipulators; robots and their application systems; tools; dies or molds; rolls; conveying equipment; lifting equipment; material handling equipment; textile machinery; sewing machines; printing and / or related machinery; paper processing machinery; chemical machinery; mining and / or construction machinery and / or related equipment; agricultural, forestry and fishing machinery and implements; safety and / or environmental protection equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubrication equipment; valves; pipe fittings; and / or application systems of the aforementioned equipment or machinery).

[0139] A UE may also be, for example, a transportation device (including, by way of example, vehicles, automobiles, motorcycles, bicycles, trains, buses, carts, rickshaws, ships and other watercraft, airplanes, rockets, satellites, drones, balloons, etc.).

[0140] Furthermore, the UE may be, for example, a device for information communication (for example, an electronic computer and related devices, a communication device and related devices, an electronic component, etc.).

[0141] The UE may also be, for example, a refrigerator, a refrigerator application product and device, commercial and service equipment, a vending machine, an automatic service machine, an office machine and device, or a consumer electric or electronic machine (for example, an audio device, a video device, a speaker, a radio, a television, an oven range, a rice cooker, a coffee maker, a dishwasher, a washing machine, a dryer, an electric fan, a ventilation fan and related products, a vacuum cleaner, etc.).

[0142] A UE may also be, for example, an electronic application system or device (including, by way of example only, x-ray systems, particle accelerators, radioactive application devices, sonic devices, electromagnetic application devices, power application devices, etc.).

[0143] A UE may also be, for example, an electronic lamp, a lighting fixture, a measuring instrument, an analyzer, a tester, or a surveying or sensing instrument (e.g., a surveying instrument or a sensing instrument such as: a smoke detector; a motion sensor; a radio frequency tag, etc.), a watch or clock, laboratory equipment, optical equipment, medical equipment and / or systems, a weapon, an item of edge, a hand tool, etc.

[0144] A UE may also be, for example, a personal digital assistant or related device with wireless communication capabilities, such as a wireless card or module designed for attachment or insertion into other electronic equipment (e.g., personal computers, electrical measuring equipment).

[0145] The UE may also be part of a device or system that provides applications, services, and solutions in the Internet of Things (IoT), for example using wired and wireless communication technologies. IoT devices (or things) include appropriate electronics, software, sensors, network connections, etc. that enable the devices to collect and exchange data with each other and with other communicating devices. IoT devices may also include automated devices that follow stored software instructions in their internal memory. IoT devices may operate without the need for human supervision or attention. IoT devices may be stationary devices and / or may remain inactive for long periods of time. IoT devices may be implemented as part of (typically) stationary devices. IoT devices may be embedded in non-stationary devices (e.g. vehicles) or attached to animals or people being monitored / tracked.

[0146] It will be appreciated that IoT technology can be implemented on any communication device that can be connected to a communication network to send and receive data without regard to control by human input or software instructions stored in memory.

[0147] It will be understood that an IoT device may also be referred to as a Machine Type Communication (MTC) device, or a Machine to Machine (M2M) communication device, or a Narrow Band-IoT (NB-IoT) UE. It will also be understood that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed below in Table 3 (source: 3GPP TS 22.368 Annex B, the contents of which are incorporated herein by reference). This list is not exhaustive but is intended to provide example machine type communication applications.

[0148] Table 1: Some examples of machine-type communication applications. [Table 1]

[0149] Examples of applications, services, and solutions include MVNO (Mobile Virtual Network Operator) services, emergency wireless communication systems, PBX (Private Branch eXchange) systems, PHS / digital cordless telephone systems, POS (Point of sale) systems, advertising systems, MBMS (Multimedia Broadcast and Multicast Service), V2X (Vehicle to Everything) systems, train radio systems, location information related services, disaster / emergency wireless communication services, community services, video distribution services, Femto cell application services, VoLTE (Voice over LTE) services, billing services, radio on-demand services, roaming services, behavior monitoring services, communication carrier / communication network selection services, function restriction services, PoC (Proof of Concept) services, personal information management services, ad hoc networks / DTN (Delay Tolerant Networking) services, and the like.

[0150] It should be noted that the above-mentioned UE categories are merely examples of applications of the concepts and exemplary embodiments described herein, and that these concepts and embodiments are not limited to the above-mentioned UEs, and various modifications may be made thereto.

[0151] The whole or part of the embodiments disclosed above can be described as follows, but is not limited thereto.

[0152] 6.1.3 Authentication Procedure 6.1.3.1 EAP-AKA' authentication procedure EAP-AKA' is specified in RFC5448

[12] . The 3GPP 5G profile of EAP-AKA' is described in Annex F of the standard. Editor's Note: References to RFC 5448 will be superseded by the Internet-Draft referenced in

[67] when it becomes an RFC. The choice of using EAP-AKA' is described in Section 6.1.2 of this document. Figure 6.1.3.1-1: EAP-AKA' authentication procedure (see Figure 11 of this application) The EAP-AKA' authentication procedure works as follows, see also Figure 6.1.3.1-1 (see Figure 11 of this application): 1. The UDM / ARPF shall first generate an authentication vector as defined in TS 33.102[9] with the Authentication Management Field (AMF) separation bit = 1. Then, the UDM / ARPF shall calculate CK' and IK' according to Annex A of the standard and replace CK and IK with CK' and IK'. 2. The UDM shall then send this converted authentication vector AV' (RAND, AUTN, XRES, CK', IK') to the AUSF that received the Nudm_UEAuthentication_Get Request, using the Nudm_UEAuthentication_Get Response message, together with indicating that AV' is to be used for EAP-AKA'. NOTE: The exchange of Nudm_UEAuthentication_Get Request and Nudm_UEAuthentication_Get Response messages between the AUSF and UDM / ARPF described in the previous section is<network name> With the exception of the input parameter to the key derivation, which is the value of , the "network name" is the same as for trusted access using EAP-AKA' described in TS 33.402

[11] , section 6.2, step 10. The "network name" is a concept from RFC 5448

[12] ; it is conveyed in the AT_KDF_INPUT attribute of EAP-AKA'.<network name> The value of the parameter is not defined in RFC 5448

[12] but is defined in 3GPP specifications: for EPS it is defined as "access network identity" in TS 24.302

[71] , and for 5G it is defined as "serving network name" in clause 6.1.1.4 of this document. If a SUCI was included in the Nudm_UEAuthentication_Get Request, the UDM includes a SUPI in the Nudm_UEAuthentication_Get Response. The AUSF and the UE then perform the procedures described in RFC 5448

[12] until the AUSF is ready to send EAP-Success. If the subscriber has an AKMA subscription, the UDM shall include an AKMA indication in the Nudm_UEAuthentication_Get Response. 3. The AUSF shall send the EAP-Request / AKA'-Challenge message to the SEAF in a Nausf_UEAuthentication_Authenticate Response message. 4. The SEAF shall transparently forward the EAP-Request / AKA'-Challenge message to the UE in the NAS message Authentication Request message. The ME shall forward the RAND and AUTN received in the EAP-Request / AKA'-Challenge message to the USIM. This message shall include the ngKSI and ABBA parameters. In fact, the SEAF shall include the ngKSI and ABBA parameters in every EAP-Authentication request message. The ngKSI is used by the UE and the AMF to identify the partial native security context that is created in case of successful authentication. The SEAF shall set the ABBA parameter as defined in Annex A.7.1. During EAP authentication, the values ​​of the ngKSI and ABBA parameters sent by the SEAF to the UE shall not be changed. If the Xn handover to the new serving network is successfully completed during the authentication procedure, the AMF shall include the SN name sent in the Nausf_UEAuthentication_Authenticate Request message in the Authentication Request message. NOTE1: The SEAF needs to understand that the authentication method used is an EAP method by evaluating the type of authentication method based on the Nausf_UEAuthentication_Authenticate Response message. 5. Upon receiving RAND and AUTN, the USIM shall verify the freshness of AV' by checking if it can accept the AUTN as described in TS 33.102 [9]. If so, the USIM shall calculate the response RES. The USIM shall return RES, CK and IK to the ME. If the USIM calculates Kc (i.e., GPRS Kc) from CK and IK using conversion function c3 as described in TS 33.102 [9] and sends it to the ME, the ME shall ignore such GPRS Kc and shall not store the GPRS Kc in the USIM or ME. The ME shall derive CK' and IK' according to Annex A.3. If the UE receives an SN name in the authentication request message, the UE shall use that SN name to calculate RES and K'. AUSF shall be calculated. If validation of the AUTN at the USIM fails, the USIM and ME shall proceed as described in clause 6.1.3.3. 6. The UE shall send an EAP-Response / AKA'-Challenge message to the SEAF in the NAS message Auth-Resp message. 7. The SEAF shall transparently forward the EAP-Response / AKA'-Challenge message to the AUSF in a Nausf_UEAuthentication_Authenticate Request message. 8. The AUSF shall validate the message and if the AUSF successfully validates this message it shall proceed as follows, otherwise it shall return an error to the SEAF. The AUSF shall inform the UDM of the authentication result (see section 6.1.4 of this document for details on linking authentication confirmation). 9. The AUSF and the UE may exchange EAP-Request / AKA'-Notification and EAP-Response / AKA'-Notification messages via the SEAF, which shall forward these messages transparently. NOTE 2: The EAP Notification, described in RFC 3748

[27] , and the EAP-AKA Notification, described in RFC 4187

[21] , may be used at any time during the EAP-AKA exchange to indicate the success of the protection or if the EAP server detects an error in the received EAP-AKA response. 10. The AUSF derives the EMSK from CK' and IK' as described in RFC 5448

[12] and Annex F. The AUSF divides the most significant 256 bits of the EMSK into K AUSF and then, as described in Section A.6. AUSF From K SEAF The AUSF shall send an EAP Success message in a Nausf_UEAuthentication_Authenticate Response to the SEAF, which shall forward it transparently to the UE. The Nausf_UEAuthentication_Authenticate Response message shall SEAF If the AUSF received a SUCI from the SEAF when authentication was initiated (see section 6.1.2 of this document), the AUSF shall also include the SUPI in the Nausf_UEAuthentication_Authenticate Response message. NOTE 3: For lawful interception, it is necessary but not sufficient that the AUSF transmits SUPI to the SEAF. SEAF From K AMF By including the SUPI as an input parameter to the key derivation, additional guarantees regarding the accuracy of the SUPI are achieved by the serving network from both the home network and UE sides. 11. The SEAF shall send an EAP Success message to the UE in an N1 message. This message shall also include the ngKSI and ABBA parameters. The SEAF shall set the ABBA parameters as defined in Annex A.7.1. NOTE 4: Step 11 can be a NAS Security Mode Command or an Authentication Result. NOTE 5: The ABBA parameters are included to enable bidding down protection, a security feature that may be introduced later. The key received in the Nausf_UEAuthentication_Authenticate Response message is an anchor key, K SEAF Thereafter, SEAF shall SEAF , ABBA parameters and SUPI, K AMF Upon receiving an EAP-Success message, the UE shall derive the EMSK from CK' and IK' as described in RFC 5448 and Annex F. The ME shall convert the most significant 256 bits of the EMSK into K AUSF Then, in the same way as AUSF, SEAF The UE shall calculate K SEAF , ABBA parameters, and SUPI to K AMF We shall derive: NOTE 6: As an implementation option, after receiving an EAP message enabling the calculation of the EMSK, the UE creates a temporary security context as described in step 11. If the UE receives EAP Success, it converts this temporary security context into a partial security context. If the EAP authentication fails, the UE deletes the temporary security context. Further procedures performed by the AUSF upon receiving a successfully validated EAP-Response / AKA'-Challenge message are described in Section 6.1.4 of this document. If the EAP-Response / AKA'-Challenge message is not successfully verified, the subsequent behavior of the AUSF is determined by the home network's policy. If AUSF and SEAF determine that the authentication is successful, SEAF will AMF will be provided to AMF. 6.1.3.2 5G AKA Authentication Procedure 6.1.3.2.0 5G AKA 5G AKA enhances the EPS AKA

[10] by providing the home network with proof of successful authentication of the UE from the visited network. The proof is sent from the visited network in an Authentication Confirmation message. The choice of using 5G AKA is described in Section 6.1.2 of this document. NOTE 1: 5G AKA does not support requesting multiple 5G AVs, nor does SEAF pre-fetching 5G AVs from the home network for future use. Figure 6.1.3.2-1: 5G AKA Authentication Procedure (see Figure 12 of this application) The 5G AKA authentication procedure works as follows, see also Figure 6.1.3.2-1 (see Figure 12 of this application): 1. For each Nudm_Authenticate_Get Request, the UDM / ARPF shall create a 5G HE AV. The UDM / ARPF does this by generating an AV with the Authentication Management Field (AMF) separation bit set to "1", as defined in TS 33.102 [9]. The UDM / ARPF then AUSF(according to Annex A.2) and calculates XRES* (according to Annex A.4). Finally, the UDM / ARPF calculates RAND, AUTN, XRES*, and K AUSF The 5G HE AV shall be created from 2. The UDM shall then return the 5G HE AV to the AUSF, indicating that the 5G HE AV will be used for the 5G AKA in the Nudm_UEAuthentication_Get Response. If a SUCI was included in the Nudm_UEAuthentication_Get Request, the UDM shall include a SUPI in the Nudm_UEAuthentication_Get Response after deciphering the SUCI by the SIDF. If the subscriber has an AKMA subscription, the UDM shall include an AKMA indication in the Nudm_UEAuthentication_Get Response. 3. The AUSF shall temporarily store the XRES* together with the received SUCI or SUPI. 4. The AUSF then calculates HXRES* from XRES* (according to Annex A.5) and AUSF From K SEAF Calculate (according to Annex A.6) XRES* to HXRES*, K AUSF 5G HE AV K SEAF By replacing it with, 5G AV is generated from 5G HE AV received from UDM / ARPF. 5. After that, AUSF SEAF and returns the 5G SE AV (RAND, AUTN, HXRES*) to the SEAF in the Nausf_UEAuthentication_Authenticate Response. 6. The SEAF shall send RAND, AUTN to the UE in the NAS message Authentication Request. This message contains the AMFThe message shall also contain the ngKSI used to identify the serving network and the partial native security context that will be created in case of successful authentication. This message shall also contain the ABBA parameters. The SEAF shall set the ABBA parameters defined in Annex A.7.1. If the Xn handover to a new serving network is successfully completed during the authentication procedure, the AMF shall include in the Authentication Request message the SN name sent in the Nausf_UEAuthentication_Authenticate Request message. The ME shall forward the RAND and AUTN received in the NAS message Authentication Request to the USIM. NOTE 2: The ABBA parameter is included to enable the bid-down protection of the security feature. 7. On receiving RAND and AUTN, the USIM shall verify the freshness of the received values ​​by checking if the AUTN is acceptable as described in TS 33.102 [9]. If so, the USIM shall calculate the response RES. The USIM shall return RES, CK and IK to the ME. If the USIM calculates Kc (i.e., GPRS Kc) from CK and IK using conversion function c3 as described in TS 33.102 [9] and sends it to the ME, the ME shall ignore such GPRS Kc and shall not store the GPRS Kc in the USIM or ME. The ME shall then calculate RES* from RES according to Annex A.4. The ME shall calculate K from CK||IK according to clause A.2. AUSF The ME shall calculate K in accordance with A.6. AUSF From K SEAFThe ME accessing 5G shall check that the "separation bit" in the AMF field of the AUTN is set to 1 during authentication. The "separation bit" is bit 0 in the AMF field of the AUTN. If the UE receives an SN name in the authentication request message, the UE shall use the SN name to calculate the RES and K. AUSF Calculate. NOTE 3: This separation bit in the AMF field of the AUTN cannot be used for operator-specific purposes, as explained in TS 33.102 [9], Annex F. 8. The UE shall return RES* to the SEAF in the NAS message Authentication Response. 9. The SEAF then calculates HRES* from RES* according to Annex A.5 and the SEAF compares HRES* and HXRES*. If they match, the SEAF considers the authentication successful from the serving network's point of view. If they do not match, the SEAF proceeds as described in clause 6.1.3.2.2. If the RES* is not received by the SEAF, without reaching the UE, the SEAF considers the authentication failed and indicates failure to the AUSF. 10. The SEAF sends the RES* received from the UE to the AUSF in a Nausf_UEAuthentication_Authenticate Request message. 11. If the AUSF receives a Nausf_UEAuthentication_Authenticate Request message with RES* as authentication confirmation, it may check whether the 5G AV has expired. If the 5G AV has expired, the AUSF may consider the authentication to have failed from the home network's perspective. If the authentication is successful, the AUSF shall AUSFThe AUSF shall compare the received RES* with the stored XRES*. If RES* and XRES* are equal, the AUSF shall consider the authentication successful from the home network's point of view. The AUSF shall notify the UDM of the authentication result (see section 6.1.4 of this document for linking with the authentication confirmation). 12. The AUSF shall indicate to the SEAF in the Nausf_UEAuthentication_Authenticate Response whether the authentication was successful from the home network's point of view. If the authentication was successful, SEAF shall be sent to the SEAF in the Nausf_UEAuthentication_Authenticate Response. If the AUSF receives a SUCI from the SEAF in the authentication request (see section 6.1.2 of this document) and the authentication is successful, the AUSF shall also include the SUPI in the Nausf_UEAuthentication_Authenticate Response message. If authentication is successful, the key K received in the Nausf_UEAuthentication_Authenticate Response message SEAF shall be an anchor key in the sense of the key hierarchy specified in Section 6.2 of this document. SEAF , ABBA parameters, and SUPI, according to Annex A.7 AMF The SEAF is derived from ngKSI and K AMF shall be provided to the AMF. If SUCI is used for this certification, SEAF will SEAF After receiving the Nausf_UEAuthentication_Authenticate Response message containing the ngKSI and SUPI, the AMF AMF only the SUPI is provided; no communication services will be provided to the UE until the SUPI is recognized by the serving network. Subsequent steps performed by the AUSF after the authentication procedure are described in Section 6.1.4 of this document. 6.1.3 Authentication Procedure 6.1.3.1 EAP-AKA' authentication procedure EAP-AKA' is specified in RFC5448

[12] . The 3GPP 5G profile of EAP-AKA' is described in Annex F of the standard. Editor's Note: References to RFC 5448 will be superseded by the Internet-Draft referenced in

[67] when it becomes an RFC. The choice of using EAP-AKA' is described in Section 6.1.2 of this document. Figure 6.1.3.1-1: EAP-AKA' authentication procedure (see Figure 13 of this application) The EAP-AKA' authentication procedure works as follows, see also Figure 6.1.3.1-1 (see Figure 13 of this application): 1. The UDM / ARPF shall first generate an authentication vector as defined in TS 33.102[9] with the Authentication Management Field (AMF) separation bit = 1. Then, the UDM / ARPF shall calculate CK' and IK' according to Annex A of the standard and replace CK and IK with CK' and IK'. 2. The UDM shall then send this converted authentication vector AV' (RAND, AUTN, XRES, CK', IK') to the AUSF that received the Nudm_UEAuthentication_Get Request, using the Nudm_UEAuthentication_Get Response message, together with indicating that AV' is to be used for EAP-AKA'. NOTE: The exchange of Nudm_UEAuthentication_Get Request and Nudm_UEAuthentication_Get Response messages between the AUSF and UDM / ARPF described in the previous section is<network name> With the exception of the input parameter to the key derivation, which is the value of , the "network name" is the same as for trusted access using EAP-AKA' described in TS 33.402

[11] , section 6.2, step 10. The "network name" is a concept from RFC 5448

[12] ; it is conveyed in the AT_KDF_INPUT attribute of EAP-AKA'.<network name> The value of the parameter is not defined in RFC 5448

[12] but is defined in 3GPP specifications: for EPS it is defined as "access network identity" in TS 24.302

[71] , and for 5G it is defined as "serving network name" in clause 6.1.1.4 of this document. If a SUCI was included in the Nudm_UEAuthentication_Get Request, the UDM includes a SUPI in the Nudm_UEAuthentication_Get Response. The AUSF and the UE then perform the procedures described in RFC 5448

[12] until the AUSF is ready to send EAP-Success. If the subscriber has an AKMA subscription, the UDM shall include an AKMA indication in the Nudm_UEAuthentication_Get Response. 3. The AUSF shall send the EAP-Request / AKA'-Challenge message to the SEAF in a Nausf_UEAuthentication_Authenticate Response message. 4. The SEAF shall transparently forward the EAP-Request / AKA'-Challenge message to the UE in the NAS message Authentication Request message. The ME shall forward the RAND and AUTN received in the EAP-Request / AKA'-Challenge message to the USIM. This message shall include the ngKSI and ABBA parameters. In fact, the SEAF shall include the ngKSI and ABBA parameters in every EAP-Authentication request message. The ngKSI is used by the UE and the AMF to identify the partial native security context that is created in case of successful authentication. The SEAF shall set the ABBA parameter as defined in Annex A.7.1. During EAP authentication, the values ​​of the ngKSI and ABBA parameters sent by the SEAF to the UE shall not be changed. If the Xn handover to a new serving network is successfully completed during the authentication procedure, the AMF shall include in the Authentication Request message the SN name corresponding to the current serving network. If the SEAF determines that the Xn handover to the new serving network has been successful while the authentication procedure is in progress, the AMF aborts the current ongoing authentication procedure, initiates a new authentication procedure, and uses the new serving network name in the new authentication procedure. NOTE1: The SEAF needs to understand that the authentication method used is an EAP method by evaluating the type of authentication method based on the Nausf_UEAuthentication_Authenticate Response message. 5. When the USIM receives RAND and AUTN, it shall verify the freshness of AV' by checking if it can accept the AUTN as described in TS 33.102 [9]. If so, the USIM shall calculate the response RES. The USIM shall return RES, CK, and IK to the ME. If the USIM calculates Kc (i.e., GPRS Kc) from CK and IK using conversion function c3 as described in TS 33.102 [9] and sends it to the ME, the ME shall ignore such GPRS Kc and shall not store the GPRS Kc in the USIM or ME. The ME shall derive CK' and IK' according to Annex A.3. When the UE receives the SN name in the authentication request message, the UE shall use the SN name to calculate RES and K'. AUSF shall be calculated. If validation of the AUTN at the USIM fails, the USIM and the ME shall proceed as described in clause 6.1.3.3. 6. The UE shall send an EAP-Response / AKA'-Challenge message to the SEAF in the NAS message Auth-Resp message. 7. The SEAF shall transparently forward the EAP-Response / AKA'-Challenge message to the AUSF in a Nausf_UEAuthentication_Authenticate Request message. 8. The AUSF shall validate the message and if the AUSF successfully validates this message it shall proceed as follows, otherwise it shall return an error to the SEAF. The AUSF shall inform the UDM of the authentication result (see Section 6.1.4 of this document for details on link authentication checks). 9. The AUSF and the UE may exchange EAP-Request / AKA'-Notification and EAP-Response / AKA'-Notification messages via the SEAF, which shall forward these messages transparently. NOTE 2: The EAP Notification, described in RFC 3748

[27] , and the EAP-AKA Notification, described in RFC 4187

[21] , may be used at any time during the EAP-AKA exchange to indicate the outcome of the protection or if the EAP server detects an error in the received EAP-AKA response. 10. The AUSF derives the EMSK from CK' and IK' as described in RFC 5448

[12] and Annex F. The AUSF divides the most significant 256 bits of the EMSK into K AUSF and then, as described in A.6., K AUSF From K SEAF The AUSF shall send an EAP Success message in a Nausf_UEAuthentication_Authenticate Response to the SEAF, which shall forward it transparently to the UE. The Nausf_UEAuthentication_Authenticate Response message shall SEAF If the AUSF received a SUCI from the SEAF when authentication was initiated (see section 6.1.2 of this document), the AUSF shall also include the SUPI in the Nausf_UEAuthentication_Authenticate Response message. NOTE 3: For lawful interception, it is necessary but not sufficient that the AUSF transmits SUPI to the SEAF. SEAF From K AMF By including the SUPI as an input parameter to the key derivation, additional guarantees regarding the accuracy of the SUPI are achieved by the serving network from both the home network and UE sides. 11. The SEAF shall send an EAP Success message to the UE in an N1 message. This message shall also include the ngKSI and ABBA parameters. The SEAF shall set the ABBA parameters as defined in Annex A.7.1. NOTE 4: Step 11 can be a NAS Security Mode Command or an Authentication Result. NOTE 5: The ABBA parameters are included to enable bid-down protection for security features that may be introduced later. The key received in the Nausf_UEAuthentication_Authenticate Response message is an anchor key, K SEAF Thereafter, SEAF shall SEAF , ABBA parameters and SUPI, K AMF Upon receiving the EAP-Success message, the UE shall derive the EMSK from CK' and IK' as described in RFC 5448 and Annex F. The ME shall denote the most significant 256 bits of the EMSK as K AUSF Then, in the same way as AUSF, SEAF The UE shall calculate K SEAF , ABBA parameters, and SUPI to K AMF We shall derive: NOTE 6: As an implementation option, after receiving an EAP message enabling the calculation of the EMSK, the UE creates a temporary security context as described in step 11. If the UE receives EAP Success, it converts this temporary security context into a partial security context. If the EAP authentication fails, the UE deletes the temporary security context. Further procedures performed by the AUSF upon receiving a successfully validated EAP-Response / AKA'-Challenge message are described in Section 6.1.4 of this document. If the EAP-Response / AKA'-Challenge message is not successfully verified, the subsequent behavior of the AUSF is determined by the home network's policy. If AUSF and SEAF determine that the authentication is successful, SEAF will AMF will be provided to AMF. 6.1.3.2 5G AKA Authentication Procedure 6.1.3.2.0 5G AKA 5G AKA enhances the EPS AKA

[10] by providing the home network with proof of successful authentication of the UE from the visited network. The proof is sent from the visited network in an Authentication Confirmation message. The choice of using 5G AKA is described in Section 6.1.2 of this document. NOTE 1: 5G AKA does not support requesting multiple 5G AVs, nor does SEAF prefetch 5G AVs from the home network for future use. Figure 6.1.3.2-1: 5G AKA Authentication Procedure (see Figure 14 of this application) The 5G AKA authentication procedure works as follows, see also Figure 6.1.3.2-1 (see Figure 14 of this application): 1. For each Nudm_Authenticate_Get Request, the UDM / ARPF shall create a 5G HE AV. The UDM / ARPF does this by generating an AV with the Authentication Management Field (AMF) separation bit set to "1", as defined in TS 33.102 [9]. The UDM / ARPF then AUSF(according to Annex A.2) and calculates XRES* (according to Annex A.4). Finally, the UDM / ARPF calculates RAND, AUTN, XRES*, and K AUSF The 5G HE AV shall be created from 2. The UDM shall then return the 5G HE AV to the AUSF, indicating that the 5G HE AV will be used for the 5G AKA in the Nudm_UEAuthentication_Get Response. If a SUCI was included in the Nudm_UEAuthentication_Get Request, the UDM shall include a SUPI in the Nudm_UEAuthentication_Get Response after deciphering the SUCI by the SIDF. If the subscriber has an AKMA subscription, the UDM shall include an AKMA indication in the Nudm_UEAuthentication_Get Response. 3. The AUSF shall temporarily store the XRES* together with the received SUCI or SUPI. 4. The AUSF then calculates HXRES* from XRES* (according to Annex A.5) and AUSF From K SEAF Calculate (according to Annex A.6) XRES* to HXRES*, K AUSF 5G HE AV K SEAF By replacing it with, 5G AV is generated from 5G HE AV received from UDM / ARPF. 5. After that, AUSF SEAF and returns the 5G SE AV (RAND, AUTN, HXRES*) to the SEAF in the Nausf_UEAuthentication_Authenticate Response. 6. The SEAF shall send RAND, AUTN to the UE in the NAS message Authentication Request. This message contains the AMFThe message shall also contain the ngKSI used to identify the current serving network and the partial native security context that will be created in case of successful authentication. This message shall also contain the ABBA parameters. The SEAF shall set the ABBA parameters as defined in Annex A.7.1. If the Xn handover to a new serving network is successfully completed during the authentication procedure, the AMF shall include in the Authentication Request message the SN name corresponding to the current serving network. The ME shall forward the RAND and AUTN received in the NAS message Authentication Request to the USIM. If the SEAF determines that the Xn handover to a new serving network has been successful while an authentication procedure is in progress, the AMF shall abort the current ongoing authentication procedure, initiate a new authentication procedure and use the new serving network name in the new authentication procedure. NOTE 2: The ABBA parameter is included to enable the bid-down protection of the security feature. 7. On receiving RAND and AUTN, the USIM shall verify the freshness of the received values ​​by checking if the AUTN is acceptable as described in TS 33.102 [9]. If so, the USIM shall calculate the response RES. The USIM shall return RES, CK and IK to the ME. If the USIM calculates Kc (i.e., GPRS Kc) from CK and IK using conversion function c3 as described in TS 33.102 [9] and sends it to the ME, the ME shall ignore such GPRS Kc and shall not store the GPRS Kc in the USIM or ME. The ME shall then calculate RES* from RES according to Annex A.4. The ME shall calculate K from CK||IK according to clause A.2. AUSF The ME shall calculate K in accordance with A.6. AUSF From K SEAFThe ME accessing 5G shall check that the "separation bit" in the AMF field of the AUTN is set to 1 during authentication. The "separation bit" is bit 0 in the AMF field of the AUTN. If the UE receives an SN name in the authentication request message, the UE shall use the SN name to calculate the RES and K. AUSF Calculate. NOTE 3: This separation bit in the AMF field of the AUTN cannot be used for operator-specific purposes, as explained in TS 33.102 [9], Annex F. 8. The UE shall return RES* to the SEAF in the NAS message Authentication Response. 9. The SEAF then calculates HRES* from RES* according to Annex A.5 and the SEAF compares HRES* and HXRES*. If they match, the SEAF considers the authentication successful from the serving network's point of view. If they do not match, the SEAF proceeds as described in clause 6.1.3.2.2. If the RES* is not received by the SEAF, without reaching the UE, the SEAF considers the authentication failed and indicates failure to the AUSF. 10. The SEAF sends the RES* received from the UE to the AUSF in a Nausf_UEAuthentication_Authenticate Request message. 11. If the AUSF receives a Nausf_UEAuthentication_Authenticate Request message with RES* as authentication confirmation, it may check whether the 5G AV has expired. If the 5G AV has expired, the AUSF may consider the authentication to have failed from the home network's perspective. If the authentication is successful, the AUSF shall AUSFThe AUSF shall compare the received RES* with the stored XRES*. If RES* and XRES* are equal, the AUSF shall consider the authentication successful from the home network's point of view. The AUSF shall inform the UDM of the authentication result (see section 6.1.4 of this document for the link with the authentication confirmation). 12. The AUSF shall indicate to the SEAF in the Nausf_UEAuthentication_Authenticate Response whether the authentication was successful from the home network's point of view. If the authentication was successful, SEAF shall be sent to the SEAF in the Nausf_UEAuthentication_Authenticate Response. If the AUSF receives a SUCI from the SEAF in the authentication request (see section 6.1.2 of this document) and the authentication is successful, the AUSF shall also include the SUPI in the Nausf_UEAuthentication_Authenticate Response message. If authentication is successful, the key K received in the Nausf_UEAuthentication_Authenticate Response message SEAF shall be an anchor key in the sense of the key hierarchy specified in Section 6.2 of this document. SEAF , ABBA parameters, and SUPI, according to Annex A.7 AMF The SEAF is derived from ngKSI and K AMF shall be provided to the AMF. If SUCI is used for this certification, SEAF will SEAF After receiving the Nausf_UEAuthentication_Authenticate Response message containing the ngKSI and SUPI, the AMF AMF only the SUPI is provided; no communication services will be provided to the UE until the SUPI is recognized by the serving network. Subsequent steps performed by the AUSF after the authentication procedure are described in Section 6.1.4 of this document.

[0153] Abbreviation For the purposes of this document, TR 21.905 [1] and the abbreviations listed below apply. Abbreviations defined in this document take precedence over definitions in TR 21.905 [1] if the same abbreviation is used. 4G-GUTI 4G Globally Unique Temporary UE Identity 5GC 5G Core Network 5GLAN 5G Local Area Network 5GS 5G System 5G-AN 5G Access Network 5G-AN PDB 5G Access Network Packet Delay Budget 5G-EIR 5G-Equipment Identity Register 5G-GUTI 5G Globally Unique Temporary Identifier 5G-BRG 5G Broadband Residential Gateway 5G-CRG 5G Cable Residential Gateway 5G GM 5G Grand Master 5G-RG 5G Residential Gateway 5G-S-TMSI 5G S-Temporary Mobile Subscription Identifier 5G VN 5G Virtual Network 5QI 5G QoS Identifier AF Application Function AMF Access and Mobility Management Function AS Access Stratum ATSSS Access Traffic Steering, Switching, Splitting ATSSS-LL ATSSS Low-Layer AUSF Authentication Server Function AUTN Authentication token BMCA Best Master Clock Algorithm BSF Binding Support Function CAG Closed Access Group CAPIF Common API Framework for 3GPP northbound APIs CHF Charging Function CN PDB Core Network Packet Delay Budget CP Control Plane DAPS Dual Active Protocol Stacks DL Downlink DN Data Network DNAI DN Access Identifier DNN Data Network Name DRX Discontinuous Reception DS-TT Device-side TSN translator ePDG evolved Packet Data Gateway EBI EPS Bearer Identity EPS Evolved Packet System EUI Extended Unique Identifier FAR Forwarding Action Rule FN-BRG Fixed Network Broadband RG FN-CRG Fixed Network Cable RG FN-RG Fixed Network RG FQDN Fully Qualified Domain Name GFBR Guaranteed Flow Bit Rate GMLC Gateway Mobile Location Centre GPSI Generic Public Subscription Identifier GUAMI Globally Unique AMF Identifier GUTI Globally Unique Temporary UE Identity HR Home Routed (roaming) IAB Integrated access and backhaul IMEI / TAC IMEI Type Allocation Code IPUPS Inter PLMN UP Security I-SMF Intermediate SMF I-UPF Intermediate UPF LADN Local Area Data Network LBO Local Break Out (roaming) LMF Location Management Function LoA Level of Automation LPP LTE Positioning Protocol LRF Location Retrieval Function MCC Mobile country code MCX Mission Critical Service MDBV Maximum Data Burst Volume MFBR Maximum Flow Bit Rate MICO Mobile Initiated Connection Only MNC Mobile Network Code MPS Multimedia Priority Service MPTCP Multi-Path TCP Protocol N3IWF Non-3GPP InterWorking Function N5CW Non-5G-Capable over WLAN NAI Network Access Identifier NEF Network Exposure Function NF Network Function NGAP Next Generation Application Protocol NID Network identifier NPN Non-Public Network NR New Radio NRF Network Repository Function NSI ID Network Slice Instance Identifier NSSAA Network Slice-Specific Authentication and Authorization NSSAAF Network Slice-Specific Authentication and Authorization Function NSSAI Network Slice Selection Assistance Information NSSF Network Slice Selection Function NSSP Network Slice Selection Policy NW-TT Network-side TSN translator NWDAF Network Data Analytics Function PCF Policy Control Function PDB Packet Delay Budget PDR Packet Detection Rule PDU Protocol Data Unit PEI Permanent Equipment Identifier PER Packet Error Rate PFD Packet Flow Description PNI-NPN Public Network Integrated Non-Public Network PPD Paging Policy Differentiation PPF Paging Proceed Flag PPI Paging Policy Indicator PSA PDU Session Anchor PTP Precision Time Protocol QFI QoS Flow Identifier QoE Quality of Experience RACS Radio Capabilities Signalling optimisation (R)AN (Radio) Access Network RG Residential Gateway RIM Remote Interference Management RQA Reflective QoS Attribute RQI Reflective QoS Indication RSN Redundancy Sequence Number SA NR Standalone New Radio SBA Service Based Architecture SBI Service Based Interface SCP Service Communication Proxy SD Slice Differentiator SEAF Security Anchor Functionality SEPP Security Edge Protection Proxy SMF Session Management Function SMSF Short Message Service Function SN Sequence Number SN name Serving Network Name SNPN Stand-alone Non-Public Network S-NSSAI Single Network Slice Selection Assistance Information SSC Session and Service Continuity SSCMSP Session and Service Continuity Mode Selection Policy SST Slice / Service Type SUCI Subscription Concealed Identifier SUPI Subscription Permanent Identifier SV Software Version TNAN Trusted Non-3GPP Access Network TNAP Trusted Non-3GPP Access Point TNGF Trusted Non-3GPP Gateway Function TNL Transport Network Layer TNLA Transport Network Layer Association TSC Time Sensitive Communication TSCAI TSC Assistance Information TSN Time Sensitive Networking TSN GM TSN Grand Master TSP Traffic Steering Policy TT TSN Translator TWIF Trusted WLAN Interworking Function UCMF UE radio Capability Management Function UDM Unified Data Management UDR Unified Data Repository UDSF Unstructured Data Storage Function UL Uplink UL CL Uplink Classifier UPF User Plane Function URLLC Ultra Reliable Low Latency Communication URRP-AMF UE Reachability Request Parameter for AMF URSP UE Route Selection Policy VID VLAN Identifier VLAN Virtual Local Area Network W-5GAN Wireline 5G Access Network W-5GBAN Wireline BBF Access Network W-5GCAN Wireline 5G Cable Access Network W-AGF Wireline Access Gateway Function

[0154] definition For the purposes of this document, 3GPP TR 21.905 [1] and the following terms and definitions apply. Terms defined in this document take precedence over definitions in 3GPP TR 21.905 [1] if the same term exists.

[0155] Although the present invention has been particularly shown and described with reference to exemplary embodiments, the present invention is not limited to these embodiments, and it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the present invention as defined in the claims.

[0156] This application is based on and claims the benefit of priority to Indian Patent Application No. 202011047284 filed on October 29, 2020, the disclosure of which is incorporated herein by reference in its entirety. [Explanation of symbols]

[0157] 800UE 801 Antenna 802 Transmitter / Receiver Circuit 803 User Interface 804 Controller 805 Memory 900 (R)AN nodes 901 Antenna 902 Transmitter / receiver circuit 903 Network Interface 904 Controller 905 Memory 1000 AMF 1001 Transmitter / receiver circuit 1002 Controller 1003 Memory 1004 Network Interface

Claims

1. means for performing a registration procedure for the user equipment to a first Public Land Mobile Network (PLMN); means for transmitting a first message to an Authentication Server Function (AUSF) for performing authentication of the user equipment, the first message including an identifier of the first PLMN; means for performing a handover procedure of the user equipment involving a change from the first PLMN to a second PLMN; means for receiving a second message including an identifier of the first PLMN; means for transmitting to the user equipment an authentication request message including an identifier of the first PLMN; A communication device comprising:

2. means for receiving a third message indicating that the authentication is complete; means for transmitting the second PLMN identifier to a Unified Data Management (UDM) for updating the first PLMN identifier; The communication device of claim 1 .

3. means for receiving a third message including an identifier of the second PLMN; A means for checking whether a Mobile Country Code (MCC) and a Mobile Network Code (MNC) included in an identifier of the second PLMN are the same as the MCC and MNC included in the 5G-GUTI when the communication device holds a 5G Globally Unique Temporary Identifier (5G-GUTI); means for transmitting a fourth message to the AUSF for authenticating the user equipment, the fourth message including the identifier of the second PLMN, when the MCC and MNC included in the identifier of the second PLMN are not the same as the MCC and MNC included in the 5G-GUTI; The communication device of claim 1 .

4. performing a registration procedure for the user equipment with a first Public Land Mobile Network (PLMN); Sending a first message to an Authentication Server Function (AUSF) for performing authentication of the user equipment, the first message including an identifier of the first PLMN; performing a handover procedure of the user equipment involving a change from the first PLMN to a second PLMN; receiving a second message including an identifier of the first PLMN; sending an authentication request message to the user equipment, the message including an identifier of the first PLMN; Method of communication device.

Images