Using pseudonyms for access authentication over non-3gpp access

Abstract

Apparatuses, methods, and systems are disclosed for using pseudonyms for access authentication over non-3GPP access. An apparatus (500) includes a processor (505) and a transceiver (525) that communicates with a mobile communication network using a 3GPP access network and a non-3GPP access network. The processor (505) sends (705), via the 3GPP access network, a registration message to a first network function in the mobile communication network, the first authentication message including a first indicator for the apparatus (500) and a SUCI, where the first indicator includes an indication that the apparatus (500) has a capability for access authentication for non-3GPP access in an EPS. The processor (505) receives (710), in response to the registration message including the first indicator, a first identification pseudonym for the apparatus (500) and performs (715) access authentication via the non-3GPP access network using the first identification pseudonym.

Description

TECHNICAL FIELD

[0001] The subject matter disclosed herein relates generally to obtaining a pseudonym for access authentication through non-3GPP access technologies. BACKGROUND

[0002] The following definitions and abbreviations are herewith defined, at least some of which are referred to within the following description.

[0003] Third Generation Partnership Project (“3GPP”), Fifth Generation Core Network (“5GC”), 5G Mobility Management (“5GMM”), Access and Mobility Management Function (“AMF”), Access Point Name (“APN”), Access Stratum (“AS”), Access Network Information (“ANT”), Application Programming Interface (“API”), Data Network Name (“DNN”), Downlink (“DL”), Enhanced Mobile Broadband (“eMBB”), Evolved Node B (“eNB”), Evolved Packet Core (“EPC”), Evolved Packet System (“EPS”), Evolved UMTS Terrestrial Radio Access Network (“E-UTRAN”), Home Public Land Mobile Network (“HPLMN”), Home Subscriber Server (“HSS”), International Mobile Subscriber Identity (“IMSI”), IP Multimedia Subsystem (“IMS,” also known as “IP Multimedia Core Network Subsystem”), Internet Protocol (“IP”), Long Term Evolution (“LTE”), LTE Advanced (“LTE-A”), Medium Access Control (“MAC”), Mobile Network Operator (“MNO”), Mobility Management Entity (“MME”), Non-Access Stratum (“NAS”), Narrow Band (“NB”), Network Function (“NF”), Network Access Identifier (“NAI”), Next Generation (e.g., “NG”), New Radio (“NR”), Non-3GPP Access (“N3GA”), Operation and Maintenance (“O&M”), Operation and Support System (“OSS”), Policy Control Function (“PCF”), Physical (“PHY”), Public Land Mobile Network (“PLMN”), Radio Access Network (“RAN”), Radio Resource Control (“RRC”), Single Network Slice Template (“S-NST”), Single-PNI Access and Mobility Management Entity (“SAMME”), Single-PS Access and Mobility Management Entity (“SP-AMF”), Slice Template (“ST”), Subscriber Profile Repository (“SPR”), User Data Management (“UDM”), User Entity (“UE”), Uplink (“UL”), and next Generation (“NG”).5G) node B (“gNB”), next generation radio access network (“NG-RAN”), new radio (“NR”), policy control function (“PCF”), packet data network (“PDN”), packet data unit (“PDU”), PDN gateway (“PGW”), public land mobile network (“PLMN”), quality of service (“QoS”), radio access network (“RAN”), radio access technology (“RAT”), radio resource control (“RRC”), receive (“Rx”), security mode control (“SMC”), single network slice selection assistance information (“S-NSSAI”), serving gateway (“SGW”), session management function (“SMF”), subscription concealed identifier (“SUCI”), subscription permanent identifier (“SUPI”), transmission control protocol (“TCP”), transmit (“Tx”), trusted non-3GPP access network (“TNAN”), trusted non-3GPP access point (“TNAP”), trusted non-3GPP gateway function (“TNGF”), unified data management (“UDM”), user entity / equipment (mobile terminal) (“UE”), uplink (“UL”), user plane (“UP”), universal mobile telecommunications system (“UMTS”), user data management (“UDM”), user datagram protocol (“UDP”), user location information (“ULI”), user entity / equipment (“UE”), UE parameter update (“UPU”), visited public land mobile network (“VPLMN”), wireless local area network (“WLAN”), and worldwide interoperability for microwave access (“WiMAX”).

[0004] In certain embodiments, a 5G capable UE can access an evolved packet core (“EPC”, i.e., a 4G core network) via a non-3GPP access network. The identity used by the 5G UE for access authentication for non-3GPP access in EPS as defined in subclause 6 in 3GPP TS 33.402 v16.2.0 is currently sent in clear text. However, this violates the 5G requirement that the identity of the 5G UE must not be exposed. SUMMARY

[0005] One method for a remote unit (e.g., UE) to use a pseudonym for access authentication over a non-3GPP access includes sending, via a 3GPP access network, a registration message to a first network function in a mobile communication network, the first authentication message including a first indicator for the UE and a SUCI, where the first indicator includes an indication that the UE has a capability for access authentication for non-3GPP access in EPS. The method includes receiving, in response to the registration message including the first indicator, a first identity pseudonym for the UE, and performing access authentication over the non-3GPP access network using the first identity pseudonym.

[0006] A first network function (e.g., UDM) for a method for using pseudonyms for access authentication over non-3GPP access includes receiving a registration request from a remote unit, where the registration request contains a first indicator for the remote unit and a SUCI. The method includes obtaining an identification pseudonym for the remote unit and storing a mapping of the identification pseudonym to a subscriber identity of the remote unit in response to receiving the first indicator. The method includes sending the identification pseudonym to the remote unit, where the mobile communication network uses the identification pseudonym to authenticate the remote unit for non-3GPP access in an EPS.

[0007] A second network function (e.g., AAA server) for a method for using pseudonyms for access authentication over non-3GPP access includes receiving a first authentication message authenticating a remote unit with a mobile communication network via a non-3GPP access network, the first authentication message including a first identification pseudonym for the remote unit. Here, the first identification pseudonym is received by the remote unit during a previous registration with the mobile communication network via a 3GPP access network. The method includes retrieving an authentication vector for the first identification pseudonym, creating a second identification pseudonym for the remote unit, and storing the second identification pseudonym in the mobile communication network. The method includes sending a second authentication message to the remote unit and completing authentication with the remote unit. Here, the second authentication message includes the second identification pseudonym and a challenge packet derived from the authentication vector.

[0008] A UE for another method for using pseudonyms for access authentication over non-3GPP access includes sending a first authentication message to a second network function to authenticate with a mobile communication network via a non-3GPP access network. Here, the first authentication message includes a first identification pseudonym received by the UE during a previous registration with the mobile communication network via a 3GPP access network. The method includes receiving a second authentication message from the second network function in response to the first authentication message. Here, the second authentication message includes a challenge packet and a second identification pseudonym, where the second identification pseudonym is generated by the mobile communication network in response to the first authentication message including the first identification pseudonym. The method includes completing authentication with the mobile communication network using the challenge packet and locally storing the second identification pseudonym. BRIEF DESCRIPTION OF DRAWINGS

[0009] A more particular description of the embodiments briefly described above will be rendered by reference to specific embodiments illustrated in the drawings. It is appreciated that these drawings depict only some embodiments and are not to be considered limiting in scope. The embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[0010] FIG. 1 is a diagram illustrating one embodiment of a wireless communication system for using pseudonyms for access authentication over non-3GPP access;

[0011] Figure 2 is a signal flow diagram illustrating one embodiment of creating an identification pseudonym;

[0012] Figure 3 is a signal flow diagram illustrating one embodiment of creating an identification pseudonym;

[0013] Figure 4A is a signal flow diagram illustrating one embodiment of a first solution for TNGF reauthentication;

[0014] Figure 4B is a continuation of the process depicted in Figure 4A

[0015] Figure 4C is a continuation of the process depicted in Figure 4B

[0016] Figure 5 is a block diagram illustrating one embodiment of a user equipment device for access authentication using a pseudonym for access over non-3GPP access;

[0017] Figure 6 is a block diagram illustrating one embodiment of a network equipment device supporting access authentication using a pseudonym for access over non-3GPP access;

[0018] Figure 7 is a flow diagram illustrating one embodiment of a first method for access authentication using a pseudonym for access over non-3GPP access;

[0019] Figure 8 is a flow diagram illustrating one embodiment of a second method for access authentication using a pseudonym for access over non-3GPP access;

[0020] Figure 9 is a flow diagram illustrating one embodiment of a third method for access authentication using a pseudonym for access over non-3GPP access; and

[0021] Figure 10 is a flow diagram illustrating one embodiment of a fourth method for access authentication using a pseudonym for access over non-3GPP access. DETAILED DESCRIPTION

[0022] As those skilled in the art will appreciate, the various aspects of the embodiments can be embodied as a system, device, method or program product. Accordingly, the embodiments can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that can all generally be referred to herein as a "circuit," "module" or "system."

[0023] ​​For example, disclosed embodiments can be implemented as a hardware circuit comprising custom very-large-scale integration ("VLSI") or gate array circuitry, an off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Disclosed embodiments can also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like. As another example, disclosed embodiments can include one or more physical or logical blocks of executable code, which may, for example, be organized as an object, procedure, or function.

[0024] Furthermore, embodiments can take the form of a program product embodied in one or more computer readable storage devices having stored thereon machine-readable code, computer-readable code, and / or program code, which when executed by a machine, are capable of causing the machine to carry out aspects of the disclosed embodiments. The machine-readable code, computer-readable code, and / or program code can be stored in a storage device, which can be any device or combination of devices capable of storing such code and which can be specifically configured to store and / or execute code. The storage device can be tangible or intransitory. The storage device can not embody signals. In a certain embodiment, the storage device only employs signals for accessing code.

[0025] Any combination of one or more computer readable medium can be utilized. The computer readable medium can be a computer readable storage medium. The computer readable storage medium can be a storage device storing the code. The storage device can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

[0026] More specific examples (a non-exhaustive list) of the storage device would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory ("RAM"), a read-only memory ("ROM"), an erasable programmable read-only memory ("EPROM" or Flash memory), a portable compact disc read-only memory ("CD-ROM"), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium can be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0027] References in the specification to “one embodiment,” “an embodiment,” or similar language mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, appearances of the phrase “in one embodiment” or similar language in the specification do not necessarily refer to the same embodiment, unless specifically stated otherwise. The term “comprising” (and variations such as “comprise” or “comprises” or “having” or “including”) as used herein is used in the sense of “including, but not limited to,” and should be interpreted in the same manner as “including” or “containing” as these terms are used in their dictionary definitions. Unless otherwise noted, the term “or” as used herein is used in the inclusive sense, i.e., the term “or” means any one item from a list of items, as well as combinations of items from the list. Unless otherwise noted, the term “and” as used herein is used in the inclusive sense, i.e., the term “and” means all of the items in a list of items, as well as combinations of items from the list.

[0028] As used herein, a list with a conjunction of “and / or” includes any single item in the list or a combination of items in the list. For example, a list of A, B and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one or more of’ includes any single item in the list or a combination of items in the list. For example, one or more of A, B and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one of’ includes one and only one of any single item in the list. For example, “one of A, B, and C” includes only A, only B, or only C and excludes combinations of A, B, and C. As used herein, “a member selected from the group consisting of A, B, and C” includes one and only one of A, B, or C and excludes combinations of A, B, and C. As used herein, “a member selected from the group consisting of A, B, and C and combinations thereof’ includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C.

[0029] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail in order to avoid obscuring aspects of the embodiments.

[0030] The code can also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function / act specified in the schematic flowchart diagrams and / or schematic block diagrams.

[0031] The code can also be stored in a storage device that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the storage device produce an article of manufacture including instructions which implement the function / act specified in the schematic flowchart diagrams and / or schematic block diagrams.

[0032] The code can also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the code which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the schematic flowchart diagrams and / or schematic block diagrams.

[0033] The schematic flowchart diagrams and / or schematic block diagrams in the drawings show the architectural, functional and operational aspects of possible implementations of apparatuses, systems, methods and program products according to various embodiments. In this regard, each block in the schematic flowchart diagrams and / or schematic block diagrams can represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).

[0034] It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. Other steps and methods can be conceived that are equivalent in function, logic, or effect to those illustrated, with the noted referenced items.

[0035] The description of elements in each figure can refer to elements in previous figures. Like reference numbers in all figures indicate like elements, including like reference numbers for alternative embodiments of the same element.

[0036] Methods, apparatuses, and systems for using pseudonyms for access authentication over non-3GPP access are disclosed.

[0037] The procedure for authentication and key agreement in subclause 6.2 in 3GPP TS 33.402 v16.2.0 - which is mandatory for trusted non-3GPP access and optional for untrusted non-3GPP access - foresees that the UE can send its IMSI in clear text (i.e. unencrypted) to the AAA server in the core network over the air interface. Alternatively, the UE can send (in clear text) a pseudonym assigned to the UE in a previous run of the authentication procedure. The 5G UE is backwards compatible to earlier generations, but the security measures implemented in earlier technologies do not have the same level of security as in 5G, i.e. the security is lower than in 5G.

[0038] The resulting problem is a man-in-the-middle attack of a 5G capable UE to expose its secret subscriber identity when the 5G UE is to be authenticated to, e.g. an untrusted non-3GPP access to a 5GCN. As discussed above, the 5G (as the 4G UE) can send its secret subscriber identity either directly in the first message or as a reply to the identity request message. However, this 4G behavior of the 5G UE can violate the 5G requirements, which can require that its subscriber identity (e.g. SUPI - which can contain the IMSI) can need to be hidden in the first message or as a reply to the identity request message.

[0039] Described herein is a solution to the above problem of maintaining the confidentiality of the UE permanent subscriber identity of a 5G UE, while maintaining backwards compatibility to 4G systems and procedures. To prevent the disclosure of the UE permanent subscriber identity, the network (e.g. 5GCN) generates a pseudonym to use when performing access authentication over non-3GPP access. An example of a system architecture for using a pseudonym for access authentication over non-3GPP access is shown in Fig. 1. The procedure of receiving an initial pseudonym is shown in Figure 2 and Figure 3 An example of a procedure for using a pseudonym, such as an initial pseudonym, for access authentication is shown in Figures 4A to 4C

[0040] It should be noted that even though the UE can behave as a 4G UE, it still has the same permanent identity or IMSI as a 5G UE, so the 5G requirement of not sending the permanent identity via clear text should apply here. Therefore, a dual-mode UE (e.g. a 5G UE that is also a 4G UE) should always register in a way that it obtains a temporary ID or hidden permanent ID for the registration in case the UE needs to do a 4G registration.

[0041] ​According to a first solution, a 5G UE can register with a 5GCN by using 3GPP access. The 5G UE can indicate its capability for access authentication for non-3GPP access in EPS during registration with the 5GCN by using 3GPP access. In one embodiment, the access authentication for non-3GPP access in EPS is as defined in subclause 6 in 3GPP TS 33.402. The indication of the capability for access authentication for non-3GPP access in EPS can be included as a value of a 5GMM capability information element (e.g., defined in 3GPP TS 24.501). The indication of the capability for access authentication for non-3GPP access in EPS can indicate to the network that the 5G UE can support the EAP-AKA' authentication method (e.g., defined in IETF RFC 5448).

[0042] The indication of the capability for access authentication for non-3GPP access in EPS can prompt the network to provide the UE with information about the accessibility of non-3GPP access networks for authentication for non-3GPP access in EPS. In one embodiment, the accessibility information can be conveyed to the 5G UE from the PCF via the AMF in the form of URSP rules. Receiving such information by the 5G UE can rely on the user subscription, where the PCF sends new URSP rules to the 5G UE if the user subscription allows it.

[0043] The indication of the capability for access authentication for non-3GPP access in EPS can trigger the UDM to create an initial pseudonym. For this procedure, the UDM can need to obtain the SUPI of the 5G UE from the SUCI (using the SIDF functionality provided by the UDM), which can have been used by the 5G UE at registration with the 5GCN. The SIDF can obtain the SUPI of the 5G UE from the SUCI by de-concealing the SUCI and provide it to the UDM.

[0044] In some embodiments, the creation of the initial pseudonym is performed locally at the UDM. The UDM can create the initial pseudonym based on the 5G UE's SUPI (where the SUPI type is IMSI) according to the techniques discussed herein and store the created initial pseudonym and the UE identifier (i.e., the 5G UE SUPI, the 5G UE SUPI of type IMSI, or the 5G UE IMSI) at a location of the mobile network that is accessible by the non-3GPP access network. For example, the UDM / UDR can store the 5G UE's SUPI and the created initial pseudonym in the HSS. In other embodiments, the creation of the initial pseudonym is performed by a AAA entity (e.g., a 3GPP AAA server). Here, the UDM sends a request to the AAA entity to create the initial pseudonym, which includes the 5G UE's IMSI to create the initial pseudonym, where the AAA entity can create the initial pseudonym based on the 5G UE's IMSI. Note that the AAA entity can be the same or different AAA entity as the 3GPP AAA server that performs the access authentication with the 5G UE for non-3GPP access in EPS.

[0045] One option for generating the initial pseudonym can be similar to the one-time token generation, and it can be based on a random number generator / hash function that can create a proper unique output for the initial pseudonym with the IMSI and any random number / random value as input.

[0046] Alternatively, the UDM (or AAA entity) can generate the initial pseudonym by encrypting the IMSI using any secret key (home network private / secret key) available in the UDM (or AAA entity). Further, the input to the encryption algorithm at the UDM / AAA can be the plaintext consisting of the compressed IMSI concatenated with a random number. The initial pseudonym can have the format of the IMSI.

[0047] The UDM can store the 5G UE's IMSI and the created initial pseudonym in the HSS. The UDR can store the 5G UE's SUPI, the 5G UE's SUPI where the SUPI type is IMSI, the 5G UE's IMSI, and the created initial pseudonym.

[0048] The UDM can provide the initial pseudonym in the subscription profile to the AMF, which can send the created initial pseudonym to the 5G UE in the registration accept message. Alternatively, the UDM can send the created initial pseudonym to the 5G UE by using the UE parameter update procedure, where the UE assigned parameters are updated by the network. The 5G UE can store the initial pseudonym to the non-volatile memory.

[0049] The 5G UE can use the initial pseudonym for access authentication for non-3GPP access in EPS, e.g., using the procedure defined in subclause 6 in 3GPP TS 33.402. The 5G UE can use the initial pseudonym for access authentication for non-3GPP access in EPS so as not to disclose its SUPI and / or IMSI. In one embodiment, the SUPI type is IMSI.

[0050] In the first solution, the 5G UE can also be a 4G UE or any other generation UE. As an example, if the 5G UE is also a 4G UE and is capable of performing EPC registration, the AAA server can create an initial pseudonym, which can be similar to a one-time token and can be based on a random number generator, which can create a proper unique output. The initial pseudonym can have the format of IMSI. The AAA server can store the IMSI of the UE and the created initial pseudonym in the HSS.

[0051] According to the second solution, after the UDM obtains the SUPI of the 5G UE from the SIDF, the UDM can send a request towards the HSS including the IMSI of the 5G UE for creating an initial pseudonym. In some embodiments, the creation of the initial pseudonym is performed locally at the HSS. The HSS can create the initial pseudonym based on the permanent identity of the 5G UE according to the techniques discussed herein and store the created initial pseudonym and the UE identifier (i.e., the 5G UE SUPI, the 5G UE SUPI of type IMSI, or the 5G UE IMSI). Alternatively, the HSS can interact with a AAA entity (e.g., a 3GPP AAA server) to create the initial pseudonym based on the IMSI of the 5G UE. Here, the HSS sends a request to the AAA entity to create an initial pseudonym, the request including the IMSI of the 5G UE for creating the initial pseudonym, where the AAA entity can create the initial pseudonym based on the IMSI of the 5G UE. Note that the AAA entity can be the same or different from the 3GPP AAA server that performs access authentication with the 5G UE for non-3GPP access in EPS.

[0052] One option for generating the initial pseudonym can be similar to one-time token generation and it can be based on a random number generator / hash function, which can create a proper unique output for the initial pseudonym with the IMSI and any random number / random value as input. Alternatively, the creation of the initial pseudonym can include encrypting the IMSI using any secret key (home network private / secret key) available in the HSS (or AAA). Further, the input to the encryption algorithm at the HSS can be a plaintext consisting of the compressed IMSI concatenated with a random number. The initial pseudonym can have the format of IMSI.

[0053] The HSS can store a matching pair of the SUPI of the 5G UE and the initial pseudonym. Alternatively, the HSS can store a matching pair of the IMSI of the 5G UE and the initial pseudonym. In one embodiment, the SUPI type of the 5G UE is IMSI. The HSS can send the identifier of the 5G UE (e.g., the SUPI of the 5G UE whose SUPI type is IMSI or the IMSI of the 5G UE) and the initial pseudonym to the UDM / UDR. The UDR can store the SUPI of the 5G UE whose SUPI type is IMSI, the IMSI of the 5G UE, and the created initial pseudonym.

[0054] In a second solution, the 5G UE can also be a 4G UE or any other generation UE. As an example, if the 5G UE is also a 4G UE and is capable of performing EPC registration, the AAA server can create an initial pseudonym, which can be similar to a one-time token and can be based on a random number generator, which can create a suitable unique output. The initial pseudonym can have the format of an IMSI. The AAA server can store the IMSI of the UE and the created initial pseudonym in the HSS.

[0055] According to a third solution, it is assumed that the initial pseudonym can be assigned to a 4G UE or a 5G UE (or any other generation UE) by means of a configuration, which can be, but is not limited to, using a UICC, USIM, SIM, or inside the ME. In all cases, the configuration can be done such that the UE or 5G UE stores the initial pseudonym in a non-volatile memory. The initial pseudonym can be stored in several UDM / UDRs, several 3GPP AAA servers, several AAA proxies, and several HSSs at the same time for an access authentication for non-3GPP access in EPS as defined in subclause 6 in TS 3GPP 33.402, or any other registration or configuration update.

[0056] According to a fourth solution, for an access authentication for non-3GPP access in EPS, the 5G UE can use a NAI, which can be constructed from the initial pseudonym, i.e., the pseudonym-NAI, for the EAP-AKA' procedure. In this solution, the 5G UE can have an initial pseudonym, e.g., according to one of the above solutions. When registering to the 5GCN by using a 3GPP access (e.g., discussed above in the first and second solutions), the 5G UE can receive an indication in the registrar accept message that the network has the capability for an access authentication for non-3GPP access in EPS.

[0057] 5G UE can receive an indication of network capabilities for access authentication for non-3GPP access in EPS as a value of a 5GS network feature support information element (e.g., defined in 3GPP TS 24.501). The network capabilities for access authentication for non-3GPP access in EPS can hint the 5G UE that it can need to use such authentication procedure to gain access to some, but not all, non-3GPP access networks. The network capabilities for access authentication for non-3GPP access in EPS can hint the 5G UE that it can need to use such authentication procedure to gain access to some services. The 5G UE can connect to a non-3GPP access for access authentication for non-3GPP access in EPS.

[0058] The pseudonym NAI can be prefixed with a special character (e.g., a single digit "7" as described in IETF RFC 5448 and 3GPP TS 23.003) to indicate the EAP-AKA' method for access authentication for non-3GPP access in EPS. As an example, if the initial pseudonym username is 7y34fa8123 and the IMSI is 234150999999999, then the NAI can be "7" <7y34fa8123> @nai.epc.mnc150.mcc234.3gppnetwork.org, where the prefix "7" indicates that the NAI is a pseudonym NAI for the EAP-AKA' procedure.

[0059] According to 3GPP TS 29.273, a non-3GPP access can use the Diameter Extensible Authentication Protocol (EAP) application (e.g., specified in IETF RFC 4072) for the SWa interface to send an NAI in an attribute-value pair ("AVP") user-name and an EAP payload in an EAP-Payload AVP towards a proxy AAA that can exist for authentication for non-3GPP access in EPS. The NAI in the AVP user-name and the EAP payload in the EAP-Payload AVP can be further sent towards a 3GPP AAA server by using the Diameter EAP application (e.g., as specified in IETF RFC 4072, according to 3GPP TS 29.273).

[0060] The 3GPP AAA server can extract the pseudonym from the NAI. If the 3GPP AAA can match the pseudonym to the IMSI of the 5G UE to determine the identity of the 5G UE, the 3GPP AAA can forward the IMSI to the HSS by using an AVP such as the user-name AVP (described in IETF RFC 4072). However, if the 3GPP AAA cannot match the pseudonym to the IMSI of the 5G UE to determine the identity of the 5G UE, the 3GPP AAA can forward the pseudonym to the HSS by using an AVP such as the user-name AVP, which can be a centralized network storage that has stored the matching IMSI of the 5G UE for the pseudonym. It should be noted that if the 5G UE is in a visited network, the 3GPP AAA can send the identity of the visited network by using a Diameter AVP such as the visited-network-identifier AVP (described in 3GPP TS 29.229).

[0061] Upon receiving the pseudonym, the HSS can match the pseudonym to the IMSI of the 5G UE that can have been stored at the time of creating the initial pseudonym to determine the identity (e.g., IMSI) of the 5G UE. The HSS can send the identity of the UE such as the IMSI to the 3GPP AAA by using an AVP such as the user-name AVP.

[0062] The 3GPP AAA can send the request for a new set of authentication vectors by using a Diameter AVP such as the SIP-Number-Auth-Items AVP (described in 3GPP TS 29.229). Because the authentication method is EAP-AKA', the 3GPP AAA can send the identity of the access network by using a Diameter AVP such as the ANID AVP (described in 3GPP TS 29.273). The 3GPP AAA can send the authentication method, which can be EAP-AKA', by using a Diameter AVP such as the SIP-Authentication-Scheme AVP (described in 3GPP TS 29.229).

[0063] The HSS can successfully generate one or more authentication vectors to be sent to the 3GPP AAA by using the information received from the 3GPP AAA. The HSS can send a success result code to the 3GPP AAA by using an AVP such as the Result-Code AVP (described in IETF RFC 4072). The HSS can send the number of one or more authentication vectors to the 3GPP AAA by using an AVP such as the SIP-Number-Auth-Items (described in 3GPP TS 29.229). The HSS can send the authentication data content to the 3GPP AAA by using grouped AVPs such as the SIP-Auth-Data-Item (described in 3GPP TS 29.229).

[0064] The grouped AVPs can include: an authentication method EAP-AKA' in an AVP such as the SIP-Authentication-Scheme; an authentication challenge RAND; a token AUTN in an AVP such as the SIP-Authenticate (described in 3GPP TS 29.229); an expected response XRES in an AVP such as the SIP-Authorization AVP (described in 3GPP TS 29.229); a confidentiality key CK' in an AVP such as the Confidentiality-Key AVP (described in 3GPP TS 29.229); and an integrity key IK' in an AVP such as the Integrity-key AVP (described in 3GPP TS 29.229).

[0065] Upon receiving the success response and authentication data from the HSS, the 3GPP AAA server can generate an MSK and an EMSK (e.g., as defined in IETF RFC 5448). The 3GPP AAA server can create a new pseudonym to match the IMSI of the 5G UE. The 3GPP AAA server can locally store the new pseudonym for future registration of the 5G UE to the 5GCN or future access authentication of the 5G UE for non-3GPP access in EPS. The 3GPP AAA server can store the 5G UE identity and create a binding with the stored pseudonym.

[0066] The 3GPP AAA server can forward the new pseudonym and the identity of the 5G UE, which can be, but is not limited to, the IMSI of the matching 5G UE, to the HSS. The HSS can be a centralized network storage that has already stored the identity of the 5G UE (e.g., the IMSI of the matching 5G UE) for the initial pseudonym. The HSS can replace those values with the new values if the HSS has already assigned corresponding values for those parameters. The HSS can be a centralized network storage if the 5G UE is served by different 3GPP AAA servers.

[0067] The 3GPP AAA server can perform an authorization challenge by sending an EAP-Request / AKA'-Challenge towards the 5G UE with the newly created pseudonym. The non-3GPP access network can send an EAP-Request / AKA'-Challenge towards the 5G UE that can contain the newly created pseudonym. The 5G UE can replace the initial pseudonym with the new pseudonym for future access authentication for non-3GPP access in EPS, e.g., as defined in subclause 6 in 3GPP TS 33.402, or any future access authentication.

[0068] During this non-3GPP registration, the 4G UE or 5G UE or any other generation UE can perform several periodic re-registrations due to, for example, time expiration or change of location or any other reason. Therefore, the 3GPP AAA server can create a new pseudonym that replaces the old pseudonym within the same non-3GPP registration.

[0069] Figure 1A A wireless communication system 100 for using pseudonyms for access authentication over non-3GPP access according to an embodiment of the present disclosure is depicted. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a 5G-RAN 115, and a mobile core network 140. The 5G-RAN 115 and the mobile core network 140 form a mobile communication network. The 5G-RAN 115 can consist of a 3GPP access network 120 containing at least one cellular base unit 121 and / or a non-3GPP access network 130 containing at least one access point 131. The remote units communicate using 3GPP communication links 123 with the 3GPP access network 120 and using non-3GPP communication links 133 with the non-3GPP access network 130. Even though only one remote unit 105, one 3GPP access network 120, one non-3GPP access network 130, one 5G-RAN 115, and one mobile core network 140 are illustrated, the wireless communication system 100 can include one or both of more remote units 105, more 3GPP access networks 120, more non-3GPP access networks 130, more 5G-RANs 115, and more mobile core networks 140. Figure 1AAlthough specific numbers of remote units 105, 3GPP access networks 120, cellular base unit 121, 3GPP communication links 123, non-3GPP access networks 130, access points 131, non-3GPP communication links 133, and mobile core networks 140 are depicted, one of skill in the art will recognize that any number of remote units 105, 3GPP access networks 120, cellular base unit 121, 3GPP communication links 123, non-3GPP access networks 130, access points 131, non-3GPP communication links 133, and mobile core networks 140 can be included in the wireless communication system 100.

[0070] In one implementation, the wireless communication system 100 is compliant with the 5G system specified in the 3GPP specifications. More generally, however, the wireless communication system 100 can implement some other open or proprietary communication network, such as LTE / EPC (known as “4G”), or WiMAX, among other networks. The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0071] In one embodiment, the remote units 105 can include computing devices, such as desktop, laptop, personal digital assistants (“PDAs”), tablet computers, smart phones, smart televisions (e.g., televisions with internet connectivity), smart appliances (e.g., appliances with internet connectivity), set-top boxes, game consoles, security systems (including security cameras), vehicle

[0072] The remote units 105 can communicate directly with one or more of the cellular base units 121 of the 3GPP access network 120 via uplink (“UL”) and downlink (“DL”) communication signals. The UL and DL communication signals can be carried over the 3GPP communication links 123. Similarly, the remote units 105 can communicate with one or more of the access points 131 of the non-3GPP access network 130 via UL and DL communication signals carried over the non-3GPP communication links 133. Here, the access networks 120 and 130 are intermediate networks that provide the remote units 105 with access to the mobile core network 140.

[0073] In some embodiments, the remote units 105 communicate with remote hosts (e.g., in a data network 150) via a network connection with the mobile core network 140. For example, an application 107 (e.g., a web browser, a streaming service client, a telephone / VoIP application) in a remote unit 105 can trigger the remote unit 105 to establish a PDU session (or other data connection) with the mobile core network 140 using the 5G-RAN 115 (e.g., the 3GPP access network 120 and / or the non-3GPP access network 130). The mobile core network 140 then relays traffic between the remote unit 105 and the remote host using the PDU session. Note that a remote unit 105 can establish one or more PDU sessions (or other data connections) with the mobile core network 140. A PDU session can be defined by its parameters: [DNN, Type, SSC mode].

[0074] The cellular base units 121 can be distributed over a geographic region. In certain embodiments, the cellular base units 121 can also be referred to as access terminals, bases, base stations, Node-Bs, eNBs, gNBs, Home Nodes-B, relay nodes, devices, or by any other terminology used in the art. The cellular base units 121 are generally part of a radio access network (“RAN”), such as the 3GPP access network 120, which can include one or more controllers that are

[0075] The cellular base units 121 can serve a number of remote units 105 within a serving area, for example, a cell or a cell sector, via 3GPP wireless communication links 123. The cellular base units 121 can communicate directly with one or more of the remote units 105 via communication signals. Generally, the cellular base units 121 transmit DL communication signals to serve the remote units 105 in the time, frequency, and / or spatial domain. Moreover, the DL communication signals can be carried over the 3GPP communication links 123. The 3GPP communication links 123 can be any suitable carrier in licensed or unlicensed radio frequency spectrum. The 3GPP communication links 123 facilitate communication between one or more of the remote units 105 and / or one or more of the cellular base units 121.

[0076] The non-3GPP access networks 130 can be distributed over a geographic region. Each non-3GPP access network 130 can serve multiple remote units 105 with a serving area. An access point 131 in a non-3GPP access network 130 can communicate directly with one or more remote units 105 by receiving UL communication signals and transmitting DL communication signals to serve the remote units 105 in the time, frequency, and / or spatial domain. Both DL and UL communication signals are carried over a non-3GPP communication link 133. The 3GPP communication links 123 and the non-3GPP communication links 133 can employ different frequencies and / or different communication protocols. In various embodiments, the access points 131 can communicate using unlicensed radio spectrum. The mobile core network 140 can provide service to the remote units 105 through the non-3GPP access networks 130, as described in more detail herein.

[0077] In some embodiments, the non-3GPP access networks 130 connect to the mobile core network 140 via an interworking entity 135. The interworking entity 135 provides interworking between the non-3GPP access networks 130 and the mobile core network 140. The interworking entity 135 supports connectivity via “N2” and “N3” interfaces. As depicted, both the 3GPP access networks 120 and the interworking entity 135 communicate with the AMF 143 using the “N2” interface. The 3GPP access networks 120 and the interworking entity 135 also communicate with the UPF 141 using the “N3” interface.

[0078] In certain embodiments, the non-3GPP access networks 130 can be controlled by the operator of the mobile core network 140 and can be able to directly access the mobile core network 140. Such non-3GPP AN deployments are referred to as “trusted non-3GPP access networks.” A non-3GPP access network 130 is considered “trusted” when it is operated by a 3GPP operator or a trusted partner and supports certain security features, such as strong air interface encryption. In contrast, a non-3GPP AN deployment that is not controlled by the operator (or a trusted partner) of the mobile core network 140, is not able to directly access the mobile core network 140, or does not support certain security features is referred to as an “untrusted” non-3GPP access network. An interworking entity 135 deployed in a trusted non-3GPP access network 130 can be referred to herein as a Trusted Network Gateway Function (“TNGF”). An interworking entity 135 deployed in an untrusted non-3GPP access network 130 can be referred to herein as a Non-3GPP Interworking Function (“N3IWF”). While depicted as part of the non-3GPP access network 130, the N3IWF can be part of the mobile core network 140 or can be located in the data network 150 in some embodiments.

[0079] In one embodiment, the mobile core network 140 is a 5G core (“5GC”) or an evolved packet core (“EPC”), which can be coupled to data networks 150, like the Internet and private data networks, as well as other data networks. A remote unit 105 can have a subscription or other account with the mobile core network 140. Each mobile core network 140 belongs to a single public land mobile network (“PLMN”). The present disclosure is not intended to be limited to the implementation of any particular wireless communication system architecture or protocol.

[0080] The mobile core network 140 includes several network functions (“NFs”). As depicted, the mobile core network 140 includes a number of user plane functions (“UPFs”). Here, the mobile core network 140 includes at least a UPF (“UPF”) 141.

[0081] The mobile core network 140 also includes a number of control plane functions including, but not limited to, an access and mobility management function (“AMF”) 143, an authentication server function (“AUSF”) 147, and a unified data management function / unified data repository function (“UDM / UDR”) 149. The mobile core network 140 also includes a home subscriber server (“HSS”) 151 and a 3GPP AAA server (“AAA-S”) 153, which provide authentication, authorization, policy control, and routing information to an access gateway or interworking function for non-3GPP access. Note that the AAA-S 153 can be merged and / or co-located with other network functions in the mobile core network 140. In certain embodiments, the mobile core network 140 can also include a session management function (“SMF”), a policy control function (“PCF”), a network repository function (“NRF”) (used by various NFs to discover and communicate with each other over APIs), or other NFs defined for the 5G core. While the depicted embodiment shows the UDM merged with the UDR, in other embodiments the UDM and UDR can be separate entities within the mobile core network 140.

[0082] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, wherein each mobile data connection utilizes a particular network slice. Here, a “network slice” refers to a portion of the mobile core network 140 that is optimized for certain types of business or communication services. A network instance can be identified by an S-NSSAI, while a set of network slices for which a remote unit 105 is authorized to use is identified by a NSSAI. In certain embodiments, the various network slices can include separate instances of network functions, such as the SMF and UPF 141. In some embodiments, different network slices can share some common network functions, such as the AMF 143. For ease of illustration, only a few network functions are shown in the mobile core network 140. Figure 1ADifferent network slices are not shown in FIG. 1, but their support is assumed.

[0083] Although a specific number and type of network functions are depicted in Figure 1A Although a specific number and type of network functions are depicted in

[0084] Although a specific number and type of network functions are depicted in Figure 1A Components of a 5G RAN and a 5G core network are depicted, but the described embodiments for using pseudonyms for access authentication over non-3GPP access apply to other types of communication networks and RATs, including IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA 2000, Bluetooth, ZigBee, Sigfoxx, etc. For example, in 4G / LTE variants involving an EPC, the AMF 143 can be mapped to an MME, the SMF to a control plane portion of a PGW and / or to an MME, the UPF 141 can be mapped to an SGW and a user plane portion of a PGW, the UDM / UDR 149 can be mapped to an HSS, etc.

[0085] As depicted, remote units 105 (e.g., UEs) can connect to a mobile core network (e.g., to a 5G mobile communication network) via two types of access: (1) via a 3GPP access network 120 and (2) via a non-3GPP access network 130. The first type of access (e.g., 3GPP access network 120) uses a type of wireless communication defined by 3GPP (e.g., NG-RAN), and the second type of access (e.g., non-3GPP access network 130) uses a type of wireless communication defined by non-3GPP (e.g., WLAN). The 5G-RAN 115 refers to any type of 5G access network that is capable of providing access to the mobile core network 140, including the 3GPP access network 120 and the non-3GPP access network 130.

[0086] In various embodiments, the remote unit 105 sends a special indicator to the mobile core network indicating that it supports access authentication for non-3GPP access networks 130 in EPS. In various embodiments, the remote unit 105 sends the indicator when registering with the mobile core network 140 via the 3GPP access network 120. Based on the special indicator, the mobile core network 140 generates and stores an initial pseudonym for the remote unit 105 and sends it to the remote unit 105. Thereafter, when performing access authentication for non-3GPP access networks 130 in EPS, the remote unit 105 sends the initial pseudonym so that its permanent subscriber identity is hidden.

[0087] Figure 1B A block diagram depicting an architecture of a remote unit 105 is shown. The remote unit 105 includes a UE domain 170, which includes a mobile equipment (“ME”) 171 and a universal integrated circuit card (“UICC”) 181.

[0088] The ME 171 includes a terminal equipment (“TE”) 173 and a mobile termination (“MT”) 175. The TE can be one or more devices that provide service to the user 107. For example, the TE 171 can be the portion of the remote unit 105 that generates user data in the uplink and processes user data in the downlink. The TE 171 can run one or more end-to-end applications with which the user 107 interacts.

[0089] The MT 175 performs radio-modem transport and related functions. For example, the MT 175 performs data and signaling messaging with the mobile communication network 177 (e.g., the RAN 115 and the mobile core network 140) over a radio interface (i.e., the wireless links 123 and / or 133). Functions performed by the MT 175 include radio transmission and switching, voice encoding and decoding, error detection and correction, signaling and access to the UICC 181. In some embodiments, the TE 173 and the MT 175 can be physically separable devices that are communicatively coupled (e.g., via a terminal adapter) to form the remote unit 105.

[0090] The UICC 181 includes subscription and / or account information for the remote unit 105. The UICC 181 securely stores and ensures the integrity of personal information, including a subscriber identity. Subscriber data stored in the UICC 181 can include a permanent subscriber identity (i.e., IMSI and / or SUPI) and one or more authentication keys. In various embodiments, the UICC 181 includes one or more subscriber / service identity applications, including but not limited to a Universal Subscriber Identity Module (“USIM”) application 183, a Subscriber Identity Module (“SIM”) application 185, and an IP Multimedia Services Identity Module (“ISIM”) 187. Note that different types of networks can require different protocols, different authentication procedures, different types of authentication / encryption keys, and / or different types of subscriber identities, so the UICC 181 can include different applications (e.g., USIM 183, SIM 185, etc.) to support access by the remote unit 105 to different network types. In certain embodiments, the UICC 181 is a removable IC card. In other embodiments, the UICC 181 is an embedded IC. Although only a single UICC 181 is depicted in FIG. 1, in other embodiments, the remote unit 105 can include multiple UICCs 181. Figure 1B In some embodiments, the remote unit 105 can be assigned or preconfigured with an initial pseudonym. For example, the initial pseudonym can be configured using the UICC 181, the USIM 183, the SIM 185, or within the ME 171. The initial pseudonym can be stored in one or more of the UDM / UDR 149, the 3GPP AAA server 153, the AAA proxy, and the HSS 151 at the same time for access authentication for non-3GPP access in EPS.

[0091] As discussed above, in some embodiments, the remote unit 105 can be assigned or preconfigured with an initial pseudonym. For example, the initial pseudonym can be configured using the UICC 181, the USIM 183, the SIM 185, or within the ME 171. The initial pseudonym can be stored in one or more of the UDM / UDR 149, the 3GPP AAA server 153, the AAA proxy, and the HSS 151 at the same time for access authentication for non-3GPP access in EPS.

[0092] Figure 2 A process 200 for creating and storing an initial pseudonym is depicted in accordance with an embodiment of the present disclosure. The process 200 involves a UE 205 (e.g., one embodiment of the remote unit 105) registering with a 5G core network 210 in a HPLMN using 3GPP access (i.e., the 3GPP access network 120). The 5GC 210 includes an AMF 211 (e.g., one embodiment of the AMF 143) interacting with a HSS 217 (e.g., one embodiment of the HSS 151), an AUSF 213 (e.g., one embodiment of the AUSF 147), and a UDM 215 (e.g., one embodiment of the UDM / UDR 149).

[0093] In the procedure 200, a 5G UE 205 with the capability for access authentication for non-3GPP access in EPS (e.g., as defined in subclause 6 in 3GPP TS 33.402) registers with the 5GC 210 and obtains an initial pseudonym that the 5G UE 205 stores to non-volatile memory. As used herein, “access authentication for non-3GPP access in EPS” refers to authentication for accessing (i.e., non-3GPP access network 130) and receiving an IP address. After that, the UE will register with the 5GCN network by means of NAS signaling, where the UE will be authenticated by the 5GCN. While Figure 2 The description of the procedure 200 uses the term “5G UE,” but the procedure 200 is not limited to 5G UEs and can be applied to any UE or device.

[0094] The procedure 200 begins at step 1 with the UE 205 registering with the 5GC 210 by using a 3GPP access technology (see block 211). At registration, the UE 205 can indicate to the network that it supports access authentication for non-3GPP access in EPS. In certain embodiments, this is done by the UE 205 using a 5GMM capability information element, which can be inserted in a REGISTRATION REQUEST message that can be used by the UE 205 to register with the 5GS. In certain embodiments, if the UE 205 is not preconfigured with a pseudonym, the UE 205 only indicates to the network that it supports authentication for non-3GPP access in EPS. The UE 205 registration can be an initial registration, which can be, but is not limited to, the UE 205 can have just initiated a first registration with the 5GC 210. The UE 205 registration can be a mobility and periodic update registration, which can be, but is not limited to, due to expiration of a timer or change of location.

[0095] Upon the UE 205 registering with the 5GS and indicating to the network that it supports access authentication for non-3GPP access in EPS, the AMF 211 can locate the AUSF 213 and the UDM 215 for UE 205 authentication. The AMF 211 can initiate authentication of the UE 205 that can have used its SUCI for the registration.

[0096] The AMF 211 can send an Nausf_UEAuthentication_Authenticate request that can contain the SUCI of the UE 205 towards the AUSF 213. Upon receiving the Nausf_UEAuthentication_Authenticate request containing the SUCI of the UE 205, the AUSF 213 can send an Nudm_UEAuthentication_Get request containing the SUCI of the UE 205 towards the UDM 215.

[0097] In some embodiments, the UDM 215 locally creates the initial pseudonym, as depicted in Option A. In other embodiments, the UDM 215 interacts with the AAA entity 219 to create the initial pseudonym, as depicted in Option B.

[0098] At step 2 (Option A), the UDM 215 can create the initial pseudonym (see block 223). The UDM 215 can obtain the identity of the UE 205, such as the SUPI, the SUPI with the SUPI type IMSI, or the IMSI, from the SUCI to evaluate whether a pseudonym assigned for this identity already exists. The UDM 215 can create the initial pseudonym even if the UE 205 already has a pseudonym from a previous registration performed by the UE 205.

[0099] At step 3a (Option B), the UDM 215 sends a create pseudonym request message to the AAA entity 219 containing the permanent identity of the UE 205 (see messaging 225). The AAA entity 219 creates the initial pseudonym and sends it to the UDM 215 (see messaging 227). It should be noted that the AAA entity 219 can be the same or a different AAA entity as the 3GPP AAA server that performs access authentication with 5G UEs for non-3GPP access in EPS.

[0100] The initial pseudonym can be created based on the SUPI of the UE 205, the SUPI of the UE 205 with the SUPI type IMSI, or the IMSI of the UE 205, or based on a random number generator that creates an appropriate unique output, but is not limited thereto. Alternatively, the initial pseudonym can be created by the UDM 215 or the AAA entity 219 by encrypting the IMSI by its private / secret key.

[0101] The initial pseudonym can have the format of an IMSI. The created initial pseudonym can be locally stored in the UDM 215 (e.g., where the UDM 215 is combined with or co-located with a UDR) together with the identity of the UE 205.

[0102] At step 4, the UDM 215 stores the created initial pseudonym and the identity of the UE 205 in a centralized network storage, which can be the HSS 217. The mapping of the pseudonym to the UE identity is stored for future registration of the UE 205 to the 5GC 210 or future access authentication of the UE 205 for non-3GPP access in EPS. Examples of the UE identity stored with the pseudonym include, but are not limited to, the matching SUPI of the UE 205, the SUPI of the UE 205 of type IMSI, and the IMSI of the UE 205. The UDM 215 sends a storage request message (e.g., a store pseudonym request) containing the created initial pseudonym and the identity of the UE 205 (see messaging 229).

[0103] The HSS 217 can be accessible from several UDMs 215 or several 3GPP AAA for obtaining this information. If the HSS 217 has already assigned corresponding values for these parameters, the HSS 217 can replace those values with the most recent values it has obtained from the UDM 215. It should be noted that the stored mapping can be accessible to both 3GPP access networks and non-3GPP access networks.

[0104] In certain embodiments of option B, the AAA entity 219 can send the created initial pseudonym and the UE identity directly to the HSS 217. In such embodiments, the UDM 215 does not need to send a store pseudonym request to the HSS 217. Instead, the AAA entity 219 sends the store pseudonym request to the HSS 217.

[0105] At step 5, the HSS 217 can acknowledge to the UDM 215 the storage of the created initial pseudonym and the identity of the UE 205 (see messaging 229). In some embodiments, the HSS 217 can reject the storage request, e.g., due to having an existing value already stored. If the HSS 217 rejects the storage of the created initial pseudonym and the identity of the UE 205, the HSS 217 can provide the UDM 215 with the corresponding value that already exists. Alternatively, in case the HSS 217 receives the store pseudonym request from the AAA entity 219, then the HSS 217 can acknowledge to the AAA entity 219 the storage of the created initial pseudonym and the identity of the US 205.

[0106] At step 6, the UDM 215 initiates a UE parameter update (“UPU”) procedure and sends the created initial pseudonym to the UE 205 (see block 231). The UDM 215 can send a Nudm_UEAuthentication_Get response containing the initial pseudonym along with authentication parameters to the AUSF 213. The AUSF 213 can initiate a challenge for authentication of the UE 205 by sending a Nausf_UEAuthentication_Authenticate response towards the UE 205 via the AMF 211. Once the AUSF 213 receives the response of the UE 205 in the Nausf_UEAuthentication_Authenticate request via the AMF 211, the AUSF 213 can send a Nausf_UEAuthentication_Authenticate response containing the initial pseudonym along with a success result code towards the AMF 211.

[0107] The AMF 211 can send the initial pseudonym to the UE 205 by using a payload container with a payload container type information element with a value of “UE 205 parameter update transparent container”. In an alternative to step 6, the UDM 215 can provide the initial pseudonym in the subscription profile to the AMF 211, which can send the created initial pseudonym to the UE 205 in the registration accept message. The payload container can be sent to the UE 205 in the registration accept message, which can be sent by the network to the UE 205 or update the configuration data by any message.

[0108] At step 7, the UE 205 can store the created initial pseudonym or any other pseudonym received from the network for access authentication for non-3GPP access in the EPS in a non-volatile memory (see block 233). If the UE 205 already has a present pseudonym in the non-volatile memory, the UE 205 can replace the already present pseudonym with the new pseudonym obtained from the network in message 6.

[0109] Figure 3 A procedure 300 for creating and storing an initial pseudonym according to an embodiment of the disclosure is depicted. The procedure 300 involves the UE 205, the 5GC 210, the AMF 211, the AUSF 213, the UDM 215, and the HSS 217. The procedure 300 presents an alternative to the procedure 200 discussed above. While the UDM 215 generates the initial pseudonym in the procedure 200, in the procedure 300, it is the HSS 217 that generates the initial pseudonym.

[0110] In the procedure 300, a 5G UE 205 with the capability for access authentication for non-3GPP access in EPS (e.g., as defined in subclause 6 in 3GPP TS 33.402) registers with the 5GC 210 and obtains an initial pseudonym that the 5G UE 205 stores to non-volatile memory. While Figure 3 The description of the procedure 200 uses the term“5G UE,” but the procedure 200 is not limited to 5G UEs and can be applied to any UE or device.

[0111] The procedure 300 begins at step 1 with the UE 205 can register with a 5GCN by using a 3GPP access technology (see block 221). At registration, the UE 205 can indicate to the network that it supports access authentication for non-3GPP access in EPS, as described above with reference to Figure 2 , step 1.

[0112] Upon the UE registering with the 5GS and indicating to the network that it supports access authentication for non-3GPP access in EPS, the AMF 211 can locate the AUSF 213 and UDM 215 for UE 205 authentication, as described above with reference to Figure 2 .

[0113] At step 2, the UDM 215 can send the SUPI of the UE 205, with the SUPI type being IMSI and / or the IMSI, to the HSS 217 and can request the HSS 217 to create an initial pseudonym (see messaging 301). The UDM 215 can obtain the identity of the UE 205, such as the SUPI, the SUPI with the SUPI type IMSI, or the IMSI, from the SUCI to evaluate whether a pseudonym already exists that is assigned for the identity.

[0114] In some embodiments, the HSS 217 locally creates the initial pseudonym, as depicted in option A. In other embodiments, the HSS 217 interacts with the AAA entity 219 to create the initial pseudonym, as depicted in option B.

[0115] At step 3 (option A), the HSS 217 can locally create the initial pseudonym (see block 303). The created initial pseudonym can be created even if the UE 205 already has a pseudonym from a previous registration performed by the UE 205.

[0116] At step 4a (option B), the HSS 217 sends a create pseudonym request message to the AAA entity 219, the request containing the permanent identity of the UE 205 (see messaging 305). At step 4b, the AAA entity 219 creates an initial pseudonym and sends it to the HSS 217 (see messaging 307). It should be noted that the AAA entity 219 can be the same or a different AAA entity as the 3GPP AAA server performing access authentication with 5G UEs for non-3GPP access in EPS.

[0117] The initial pseudonym can be created based on the SUPI of the UE 205, the SUPI of the type IMSI of the UE 205, or the IMSI of the UE 205 or based on a random number generator that creates an appropriate unique output but not limited to this. Alternatively, the initial pseudonym is created by the HSS 217 or the AAA entity 219 by encrypting the IMSI with its private / secret key.

[0118] The initial pseudonym can have the format of the IMSI. The created initial pseudonym can be stored locally in the HSS 217 together with the identity of the UE 205. The HSS 217, which can be a centralized network storage, can store the created initial pseudonym and the identity of the UE 205, which can be but not limited to the matching SUPI of the UE 205, the SUPI of the type IMSI of the UE 205, or the IMSI of the UE 205. The HSS 217 can use these stored identity of the UE 205 and initial pseudonym for future UE registration to the 5GCN or future UE access authentication for non-3GPP access in EPS. The HSS 217 can be accessible from several UDMs 215 or several 3GPP AAA to obtain this information. The HSS 217 can replace those values with the newly created initial pseudonym if the HSS 217 has already assigned corresponding values for these parameters.

[0119] At step 5, the HSS 217 can send the initial pseudonym and the identity of the UE 205 to the UDM 215 / UDR (see messaging 309). The UDR can store the identity of the UE 205, which can be but not limited to the matching SUPI of the UE 205, the SUPI of the type IMSI of the UE 205, or the IMSI of the UE 205, and the created initial pseudonym.

[0120] At step 6, the UDM sends the initial pseudonym inside the registration accept message to the UE (see block 311). The UDM 215 can send a Nudm_UEAuthentication_Get response to the AUSF 213 containing the initial pseudonym along with the authentication parameters. The AUSF 213 can initiate the challenge for authentication of the UE 205 by sending a Nausf_UEAuthentication_Authenticate response towards the UE 205 via the AMF 211. Once the AUSF 213 receives the response of the UE 205 in the Nausf_UEAuthentication_Authenticate request via the AMF 211, the AUSF 213 can send a Nausf_UEAuthentication_Authenticate response towards the AMF 211 containing the initial pseudonym along with a success result code. The AMF 211 can send the initial pseudonym to the UE 205 by using a payload container with a payload container type information element with a value of “UE parameter update transparent container”. The payload container can be sent to the UE 205 in the registration accept message which can be sent by the network to the UE 205 or update the configuration data by any message. Alternatively, the UDM 215 can initiate the UE parameter update procedure to send the initial pseudonym to the UE 205.

[0121] At step 7, the UE 205 can store the created initial pseudonym or any other pseudonym received from the network for access authentication for non-3GPP access in EPS in the non-volatile memory (see block 233). If the UE 205 already has a pseudonym present in the non-volatile memory, the UE 205 can replace the already present pseudonym with the new pseudonym obtained from the network in message 6.

[0122] Figures 4A to 4C A procedure 400 for using pseudonyms for access authentication over non-3GPP access according to an embodiment of the disclosure is depicted. The procedure 400 illustrates a first solution for TNGF reauthentication involving the UE 205, a non-3GPP access 401 (i.e., one embodiment of the non-3GPP access network 130), a AAA proxy 403 located in the VPLMN, a 3GPP AAA server 405 located in the HPLMN in the EPC, and the HSS 217 located in the HPLMN in the EPC. In the most typical case, the non-3GPP access network 210 is a WLAN access network compliant with IEEE 802.11 specifications.

[0123] The process 400 represents an example of a process in which a 5G UE having a capability for access authentication for non-3GPP access in EPS, as defined in subclause in TS 3GPP 33.402, performs access authentication for non-3GPP access in EPS. While the terminology 5G UE is used in the illustration, the process is not limited to 5G UEs and can be applied to UEs or devices from any generation of 3GPP technology.

[0124] At Figure 4A , the process 400 begins at step 0 with the UE 205 deciding to connect to a non-3GPP access network, e.g., using the "Access Authentication for Non-3GPP Access in EPS" procedure as defined in subclause in TS 3GPP 33.402 (see block 407).

[0125] At step 1, the UE 205 first establishes a layer-2 (L2) connection with an access point in the non-3GPP access 401 (see messaging 409). In the case of an IEEE 802.11 WLAN, this L2 connection corresponds to an 802.11 association.

[0126] At steps 2-3, an EAP procedure is initiated by an authenticator in the non-3GPP access 401. EAP messages are encapsulated into layer-2 packets, e.g., into IEEE 802.11 / 802. lx packets. The authenticator in the non-3GPP access 401 sends an EAP Request / Identity message to the UE 205 (see messaging 411) and the UE 205 sends a Network Access Identifier ("NAI") in an EAP Response / Identity message (see messaging 413) in response.

[0127] In various embodiments, the UE 205 sends its identity in an NAI format (specified in 3GPP TS 23.003, for example) "username@realm". Note that when the UE 205 is using a pseudonym username instead of a permanent username, the UE 205 selects the realm name portion similarly to how it selects the realm portion when using a permanent username.

[0128] In various embodiments, the NAI contains an initial pseudonym assigned to the UE 205, e.g., as shown in Figure 2 or Figure 3 In other embodiments, the NAI can contain a pseudonym that can have been assigned to the UE 205 in a previous run of the authentication procedure. In addition, the NAI can indicate EAP-AKA' as the authentication method for access authentication for non-3GPP access in EPS.

[0129] At step 4, the non-3GPP access 401 can route the message to the appropriate 3GPP AAA server 405 based on the domain part of the NAI. Routing the message to the appropriate 3GPP AAA server 405 can be as described in 3GPP TS 23.003. The routing path can include one or several AAA proxies 403 (see messaging 415). The identity of the access type and the access network in which the authenticator resides can be included in the Diameter message by the authenticator. In case of roaming, the visited network AAA proxy 403 can include the visited network identifier in the same Diameter message. The access network identity for the access network type can be carried in the Diameter message so that the UE 205 and the HSS 217 use the same access network identity as input for key derivation.

[0130] At step 5, the 3GPP AAA server 405 can receive the EAP-Response / Identity message containing the subscriber identity and the access type over the SWa / SWd interface (see messaging 417). Upon receiving the EAP-Response / Identity message, if the 3GPP AAA server 405 knows the IMSI of the UE 205 associated with the username of this pseudonym (the format of the pseudonym-NAI is NAI = pseudonym_username@domain), the 3GPP AAA server 405 can be able to determine whether the UE 205 has been authenticated by this 3GPP AAA server 405 in a previous EAP-AKA' authentication. In case of roaming, the 3GPP AAA server 405 can also receive the visited network identifier in the same Diameter message carrying the EAP-Response / Identity message.

[0131] At step 6, the 3GPP AAA server 405 can identify the subscriber as a candidate for authentication with EAP-AKA' based on the received identity in the EAP-Response / AKA' Identity message. The 3GPP AAA server 405 can extract the pseudonym username from the NAI. If the UE 205 indicates that it supports EAP-AKA', the 3GPP AAA server 405 can check whether it has an unused authentication vector with authentication management field separation bit = 1 and a matching access network identifier available for this subscriber. If not, a new set of authentication vectors can be retrieved from the HSS 217.

[0132] If the 3GPP AAA server 405 can match the pseudonym username to the IMSI of the UE 205 to determine the identity of the UE 205, it can forward to the HSS 217 in the request for authentication vector. If the 3GPP AAA server 405 cannot match the pseudonym username to the IMSI of the UE 205 to determine the identity of the UE 205, the 3GPP AAA server 405 can forward the pseudonym username to the HSS 217, which can have stored the matching IMSI of the UE 205 for the pseudonym username at the time of the request for authentication vector (see messaging 419). If a new set of authentication vectors is requested, the 3GPP AAA server 405 can send to the HSS 217 the identity of the visited network and the authentication method (which can be EAP-AKA') in case the UE 205 is in a visited network.

[0133] At step 7a, the HSS 217 can match the pseudonym username to the IMSI, which can have been stored at the time of creation on the initial pseudonym, to determine the identity of the UE 205 (see block 421).

[0134] Continuing with reference to Figure 4B At step 7b, the HSS 217 can run the AKA algorithm in response to the request from the 3GPP AAA server 405 (see block 423). Upon receiving an indication from the 3GPP AAA server 405 that the authentication vector is for EAP-AKA', the HSS 217 can generate an authentication vector with the authentication management field separation bit = 1. The HSS 217 can transform this authentication vector into a new authentication vector by computing CK' and IK', where the access network identity can be one of the input parameters.

[0135] At step 7c, the HSS 217 can send the transformed authentication vector to the 3GPP AAA server 405 (see messaging 423). Here, the HSS 217 can send to the 3GPP AAA the identity of the UE 205, such as the IMSI.

[0136] At step 8, the 3GPP AAA server 405 can create a new pseudonym username to match the IMSI of the UE 205 (see block 427). The 3GPP AAA server 405 can store the new pseudonym username locally for future registration of the UE 205 or future access authentication of the UE 205 for non-3GPP access in the EPS. In addition, new key material MSK and EMSK can be derived from CK' and IK' (e.g., according to IETF RFC 5448).

[0137] At step 9, the 3GPP AAA server 405 can forward the new pseudonym username to the HSS 217, which can be a centralized network store that has stored the matching IMSI of the UE 205 for the pseudonym username (see messaging 429). If the HSS 217 has already assigned corresponding values for these parameters, the HSS 217 can replace those values with the new values.

[0138] At step 10, the 3GPP AAA server 405 can send the RAND, AUTN, message authentication code, and new pseudonym username in an EAP Request / AKA'-Challenge message toward the UE 205 in the access network (see messaging 431). The 3GPP AAA server 405 can include the access network identity in the message.

[0139] At step 11, upon receiving the new pseudonym username, the UE 205 can replace the initial pseudonym username or any other pseudonym username used for EAP-AKA' authentication with the new pseudonym username for future access authentication for non-3GPP access in the EPS (see block 433). The UE 205 can verify that the AUTN is correct and thus can authenticate the access network by its identity.

[0140] At step 12, the UE can send an EAP Response / AKA'-Challenge toward the 3GPP AAA server 405 (see messaging 435).

[0141] Continuing to refer to Figure 4C At step 13, the 3GPP AAA server 405 can check the received parameters from the UE in the EAP Response / AKA'-Challenge and derive the master session key (MSK). The 3GPP AAA server 405 can send an EAP Success message to the non-3GPP access 401, which in turn can forward the EAP Success to the UE 205 (see messaging 437). Note that the 3GPP AAA server 405 sends the MSK to the non-3GPP access 401, but the non-3GPP access 401 does not send the MSK to the UE 205. Instead, the UE 205 derives its own copy of the MSK.

[0142] At step 14, a security establishment can be performed between the UE 205 and the non-3GPP access network 401, e.g., using a key derived from the MSK (see messaging 439). At step 15, upon security establishment, the UE 205 can request an IP Request Allocation, which can be assigned by the non-3GPP access 401 (see messaging 441).

[0143] Figure 5Steps x1, x2, x3 and x4 in FIG. 5 refer to the future when the UE 205 is not assigned any IP address and it can connect to the non-3GPP access 401 for access authentication for non-3GPP access in EPS. Similar to steps 2-3 above, at steps x1 and x2, the UE 205 can receive an EAP Request / Identity message and send an EAP Response / Identity message in response (see messaging 443, 445). Here, the UE 205 can send its identity in NAI format, which can contain a new pseudonym. Similar to steps 4-5 above, at steps x3 and x4, the non-3GPP access 401 sends the NAI to the 3GPP AAA server 405 via the proxy AAA server 403 when the UE 205 is roaming in a VPLMN (see messaging 447, 449).

[0144] Figure 5 One embodiment of a user equipment apparatus 500, in accordance with embodiments of the present disclosure, is depicted. The user equipment apparatus 500 can be one embodiment of the remote unit 105 and / or UE 205. Further, the user equipment apparatus 500 can include a processor 505, a memory 510, an input device 515, an output device 520, a transceiver 525. In some embodiments, the input device 515 and the output device 520 are combined into a single device, such as a touch screen. In certain embodiments, the user equipment apparatus 500 can not include any input device 515 and / or output device 520. Note that the input device 515 and the output device 520 can be part of a TE domain of the user equipment apparatus 500, while the transceiver 525 can be part of a MT domain of the user equipment apparatus 500.

[0145] As depicted, the transceiver 525 includes at least one transmitter 530 and at least one receiver 535. Here, the transceiver 525 communicates with a mobile core network (e.g., 5GC) via an access network. Further, the transceiver 525 can support at least one network interface 540. Here, the at least one network interface 540, e.g., the “Uu interface,” facilitates communications with a RAN node. Additionally, the at least one network interface 540 can include interfaces for communicating with an AMF, an SMF, and / or a UPF (e.g., N1, N2, and / or N3 interfaces).

[0146] In one embodiment, the processor 505 can include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 505 can be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, the processor 505 executes instructions stored in the memory 510 to perform methods and routines described herein. The processor 505 is communicably coupled to the memory 510, the input device 515, the output device 520, and the transceiver 525.

[0147] In various embodiments, the processor 505 controls the user equipment apparatus 500 to implement the above-described UE behaviors. In some embodiments, via the transceiver 525, the processor 505 transmits, to a first network function (i.e., an AMF) in a mobile communication network via a 3GPP access network, a registration message, the first authentication message including a first indicator for the user equipment apparatus 500 and a SUCI. Here, the first indicator includes an indication that the user equipment apparatus 500 has a capability for access authentication for non-3GPP access in an EPS. The processor 505 receives, in response to the registration message including the first indicator (e.g., from a UDM or a HSS), a first identification pseudonym (i.e., an initial pseudonym) for the user equipment apparatus 500 and performs access authentication via a non-3GPP access network using the first identification pseudonym.

[0148] In some embodiments, the indication that the remote unit has a capability for access authentication for non-3GPP access in an EPS includes a 5GMM capability information element. In some embodiments, the processor 505 determines whether an identification pseudonym is preconfigured prior to transmitting the registration message. In such embodiments, the processor 505 includes the first indicator in response to determining that no identification pseudonym is preconfigured.

[0149] In one embodiment, a UDM in the mobile communication network generates the first identification pseudonym. In another embodiment, a HSS in the mobile communication network generates the first identification pseudonym. In a further embodiment, a AAA server is in the mobile communication network. In various embodiments, the mobile communication network stores the first identification pseudonym locally at the HSS.

[0150] In various embodiments, the processor 505 performs access authentication via the non-3GPP access network using the first identity pseudonym by sending a first authentication message (e.g., EAP Response / AKA’ Identity message) to a second network function (i.e., 3GPP AAA server) to authenticate with the mobile communication network via the non-3GPP access network. Here, the first authentication message includes the first identity pseudonym (i.e., pseudonym-NAI containing the initial pseudonym). The processor 505 receives a second authentication message (e.g., EAP Request / AKA’-Challenge message) from the second network function (e.g., 3GPP AAA-S) in response to the first authentication message, the second authentication message including a challenge packet and a second identity pseudonym (e.g., AAA sends EAP-Request / AKA’-Challenge with newly created pseudonym). Here, the mobile communication network generates the second identity pseudonym (i.e., new pseudonym) in response to the first authentication message including the first identity pseudonym (e.g., initial pseudonym or another previously received pseudonym). The processor 505 completes authentication with the mobile communication network using the challenge packet (i.e., the user equipment device 500 verifies that the AUTN is correct and sends EAP Response / AKA’-Challenge toward the 3GPP AAA-S) and locally stores the second identity pseudonym (i.e., new pseudonym).

[0151] In some embodiments, the second network function includes a AAA-S in the mobile communication network. In certain embodiments, the AAA-S generates the second identity pseudonym in response to the first authentication message including the first identity pseudonym. In some embodiments, locally storing the second identity pseudonym includes replacing the first identity pseudonym with the second identity pseudonym. In some embodiments, the first identity pseudonym and the second identity pseudonym are one-time tokens used to convey the permanent subscriber identity of the user equipment device 500 in a hidden manner.

[0152] In one embodiment, the memory 510 is a computer readable storage medium. In some embodiments, the memory 510 includes both volatile and nonvolatile computer storage media. For example, the memory 510 can include both a RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”), and a nonvolatile computer storage medium. In some embodiments, the memory 510 includes nonvolatile computer storage media only. For example, the memory 510 can include a hard disk drive, a flash drive, or any other appropriate nonvolatile computer storage device. In some embodiments, the memory 510 includes both volatile and nonvolatile computer storage media.

[0153] In some embodiments, the memory 510 stores data relating to using pseudonyms for access authentication over non-3GPP access, e.g., stores subscriber identities, identifies pseudonyms, security keys, IP addresses, etc. In certain embodiments, the memory 510 also stores program code and related data, such as an operating system (“OS”) or other controller algorithms and one or more software applications that run on the user equipment device 500.

[0154] In one embodiment, the input device 515 can include any known computer input device, including a touch panel, buttons, a keyboard, a pen, a microphone, etc. In some embodiments, the input device 515 can be integrated with the output device 520, e.g., as a touch screen or similar touch-sensitive display. In some embodiments, the input device 515 includes a touch screen such that text can be input using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, the input device 515 includes two or more different devices, such as a keyboard and a touch panel.

[0155] In one embodiment, the output device 520 can include any known electronically controllable display or display device. The output device 520 is designed to output visual, audible, and / or tactile signals. In some embodiments, the output device 520 includes an electronic display capable of outputting visual data to a user. For example, the output device 520 can include, but is not limited to, an LCD display, a LED display, an OLED display, a projector, or similar display device capable of outputting images, text, etc. to a user. As another, non-limiting, example, the output device 520 can include a wearable display such as a smart watch, smart glasses, a heads-up display, and the like. Further, the output device 520 can be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, etc.

[0156] In certain embodiments, the output device 520 includes one or more speakers for producing sound. For example, the output device 520 can produce an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device 520 includes one or more haptic devices for producing vibrations, motion, or other tactile feedback. In some embodiments, all or portions of the output device 520 can be integrated with the input device 515. For example, the input device 515 and output device 520 can form a touch screen or similar touch-sensitive display. In other embodiments, all or portions of the output device 520 can be located in proximity to the input device 515.

[0157] As discussed above, the transceiver 525 communicates with one or more network functions of a mobile communication network via one or more access networks. The transceiver 525 operates under the control of the processor 505 to transmit messages, data, and other signals and also to receive messages, data, and other signals. For example, the processor 505 can selectively activate the transceiver (or portions thereof) at particular times in order to send and receive messages.

[0158] The transceiver 525 can include one or more transmitters 530 and one or more receivers 535. Although only one transmitter 530 and one receiver 535 are illustrated, the user equipment apparatus 500 can have any suitable number of transmitters 530 and receivers 535. Further, the transmitter(s) 530 and the receiver(s) 535 can be any suitable type of transmitters and receivers. In one embodiment, the transceiver 525 includes a first transmitter / receiver pair for communicating with a mobile communication network over licensed radio spectrum and a second transmitter / receiver pair for communicating with the mobile communication network over unlicensed radio spectrum.

[0159] In certain embodiments, the first transmitter / receiver pair for communicating with a mobile communication network over licensed radio spectrum and the second transmitter / receiver pair for communicating with the mobile communication network over unlicensed radio spectrum can be combined into a single transceiver unit, such as a single chip that performs functions for both licensed and unlicensed radio spectrum. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair can share one or more hardware components. For example, certain transceivers 525, transmitters 530, and receivers 535 can be implemented as physically separate components that access shared hardware resources and / or software resources, such as, for example, the network interface 540.

[0160] In various embodiments, the one or more transmitters 530 and / or the one or more receivers 535 can be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an ASIC, or other type of hardware component. In certain embodiments, the one or more transmitters 530 and / or the one or more receivers 535 can be implemented and / or integrated into a multi-chip module. In some embodiments, other components, such as the network interface 540, or other hardware components / circuits, can be integrated with any number of transmitters 530 and / or receivers 535 into a single chip. In such embodiments, the transmitters 530 and receivers 535 can be logically configured as a transceiver 525 that uses one or more common control signals or as modular transmitters 530 and receivers 535 that are implemented in the same hardware chip or multi-chip module.

[0161] Figure 6One embodiment of a network equipment apparatus 600 in accordance with embodiments of the present disclosure is depicted. In some embodiments, the network equipment apparatus 600 can be one embodiment of a TNGF (i.e., TNGF1 and / or TNGF2). In other embodiments, the network equipment apparatus 600 can be one embodiment of an AMF. Further, the network equipment apparatus 600 can include a processor 605, a memory 610, an input device 615, an output device 620, a transceiver 625. In some embodiments, the input device 615 and the output device 620 are combined into a single device, such as a touch screen. In certain embodiments, the network equipment apparatus 600 can not include any input device 615 and / or output device 620.

[0162] As depicted, the transceiver 625 includes at least one transmitter 630 and at least one receiver 635. Here, the transceiver 625 communicates with one or more remote units 105. Additionally, the transceiver 625 can support at least one network interface 640, such as the N1, N2, and N3 interfaces depicted in FIG. 1. In some embodiments, the transceiver 625 supports a first interface for communications with a RAN node (i.e., cellular base unit 121 and / or non-3GPP access point 131), a second interface for communications with one or more network functions in a mobile core network (e.g., 5GC and / or EPC), and a third interface for communications with a remote unit (e.g., UE).

[0163] In one embodiment, the processor 605 can include any known controller capable of executing computer-readable instructions and / or capable of performing logical operations. For example, the processor 605 can be a microcontroller, a microprocessor, a central processing unit (“CPU”), a graphics processing unit (“GPU”), an auxiliary processing unit, a field programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, the processor 605 executes instructions stored in the memory 610 to perform methods and routines described herein. The processor 605 is communicatively coupled to the memory 610, the input device 615, the output device 620, and the transceiver 625.

[0164] In various embodiments, the processor 605 controls the network equipment apparatus 600 to implement the UDM behavior described above. In some embodiments, via the network interface 640, the processor 605 receives, from a UE (i.e., remote unit 105), a registration request, where the registration request contains a first indicator for the UE and a SUCI. The processor 605 obtains an identity pseudonym for the UE in response to receiving the first indicator and stores a mapping of the identity pseudonym to a subscriber identity of the UE. The processor 605 sends the identity pseudonym to the UE, where the identity pseudonym is used by the mobile communication network to authenticate the UE for non-3GPP access in an EPS.

[0165] In some embodiments, the first indicator includes an indication that the UE has a capability for access authentication for non-3GPP access in the EPS and a subscriber identity of the UE. In certain embodiments, the indication that the UE has a capability for access authentication for non-3GPP access in the EPS includes a 5GMM capability information element. In some embodiments, the identity pseudonym includes a one-time token for conveying the UE's permanent subscriber identity in a concealed manner.

[0166] In some embodiments, the identity pseudonym is created using at least one of: a SUPI and an IMSI of the UE. In one embodiment, creating the identity pseudonym includes encrypting the subscriber identifier. In one embodiment, creating the identity pseudonym includes using a random number generator and the subscriber identity to generate a unique value. In one embodiment, creating the identity pseudonym includes using a hash function and the subscriber identity to generate a hash value. In one embodiment, creating the identity pseudonym includes sending the subscriber identity to a HSS in the mobile communication network and receiving the identity pseudonym from the HSS. In another embodiment, creating the identity pseudonym includes sending the subscriber identity to a AAA server in the mobile communication network and receiving the identity pseudonym from the AAA server.

[0167] In some embodiments, the network equipment apparatus 600 includes a UDM. In such embodiments, storing the mapping of the identity pseudonym to the permanent subscriber identity of the UE includes sending the identity pseudonym to a home subscriber server in the mobile communication network. In one embodiment, sending the identity pseudonym to the UE includes sending the identity pseudonym in a registration accept message. In another embodiment, sending the identity pseudonym to the UE includes initiating a UPU procedure in which the identity pseudonym is sent to the UE within UPU data.

[0168] In various embodiments, the processor 605 controls the network equipment apparatus 600 to implement the AAA-S behavior described above. In some embodiments, via the network interface 640, the processor 605 receives a first authentication message authenticating a remote unit (i.e., a UE) with a mobile communication network via a non-3GPP access network, the first authentication message including a first identity pseudonym (e.g., an initial pseudonym) for the remote unit. Here, the first identity pseudonym is received by the remote unit during a previous registration with the mobile communication network via a 3GPP access network. The processor 605 retrieves an authentication vector for the first identity pseudonym, creates a second identity pseudonym (i.e., a new pseudonym) for the remote unit, and stores the second identity pseudonym in the mobile communication network. The processor 605 sends a second authentication message to the remote unit and completes authentication with the remote unit. Here, the second authentication message includes the second identity pseudonym and a challenge packet derived from the authentication vector.

[0169] In some embodiments, the first identification pseudonym and the second identification pseudonym are both one-time tokens used to convey the remote unit's permanent subscriber identity in a concealed manner, wherein the first and second identification pseudonyms are mapped to the remote unit's permanent subscriber identity. In some embodiments, retrieving the authentication vector includes sending the first identification pseudonym to a HSS in the mobile communication network and receiving the remote unit's permanent subscriber identity, wherein the HSS stores a mapping of the first identification pseudonym to the remote unit's permanent subscriber identity. In certain embodiments, storing the second identification pseudonym includes sending the second identification pseudonym to the HSS.

[0170] In some embodiments, the second identification pseudonym is created using at least one of: the remote unit's subscriber permanent identifier and an international mobile subscriber identity. In one embodiment, creating the second identification pseudonym includes encrypting the remote unit's permanent subscriber identity. In one embodiment, creating the second identification pseudonym includes using a random number generator and the remote unit's permanent subscriber identity to generate a unique value. In one embodiment, creating the second identification pseudonym includes using a hash function and the remote unit's permanent subscriber identity to generate a hash value. In certain embodiments, storing the second identification pseudonym includes replacing the first identification pseudonym with the second identification pseudonym.

[0171] In one embodiment, the processor 605 receives a request from a HSS in the mobile communication network to create an identification pseudonym for a remote unit (i.e., UE). Here, the request can include the remote unit's permanent subscriber identity. In response, the processor 605 creates an initial pseudonym and sends the created identification pseudonym to the HSS. In another embodiment, the processor 605 receives a request from a UDM in the mobile communication network to create an identification pseudonym for a remote unit (i.e., UE). Here, the request can include the remote unit's permanent subscriber identity. In response, the processor 605 creates an initial pseudonym and sends the created identification pseudonym to the UDM.

[0172] In one embodiment, the memory 610 is a computer readable storage medium. In some embodiments, the memory 610 includes volatile computer storage media. For example, the memory 610 can include a RAM, including dynamic RAM ("DRAM"), synchronous dynamic RAM ("SDRAM"), and / or static RAM ("SRAM"). In some embodiments, the memory 610 includes non-volatile computer storage media. For example, the memory 610 can include a hard disk drive, a flash memory, or any other suitable non-volatile computer storage device. In some embodiments, the memory 610 includes both volatile and non-volatile computer storage media.

[0173] In some embodiments, the memory 610 stores data relating to using pseudonyms for access authentication over non-3GPP access, e.g., stores subscriber identities, identifies pseudonyms, security keys, IP addresses, UE contexts, etc. In certain embodiments, the memory 610 also stores program code and related data, such as an operating system (“OS”) or other controller algorithms running on the network equipment apparatus 600, and one or more software applications.

[0174] In one embodiment, the input device 615 can include any known computer input device including a touch panel, buttons, a keyboard, a pen, a microphone, etc. In some embodiments, the input device 615 can be integrated with the output device 620, for example, as a touch screen or similar touch-sensitive display. In some embodiments, the input device 615 includes a touch screen such that text can be input using a virtual keyboard displayed on the touch screen and / or by handwriting on the touch screen. In some embodiments, the input device 615 includes two or more different devices, such as a keyboard and a touch panel.

[0175] In one embodiment, the output device 620 can include any known electronically controllable display or display device. The output device 620 can be designed to output visual, audible, and / or tactile signals. In some embodiments, the output device 620 includes an electronic display capable of outputting visual data to a user. For example, the output device 620 can include, but is not limited to, an LCD display, a LED display, an OLED display, a projector, or similar display device capable of outputting images, text, etc., to a user. As another, non-limiting, example, the output device 620 can include a wearable display such as a smart watch, smart glasses, a heads-up display, or the like. Further, the output device 620 can be a component of a smart phone, a personal digital assistant, a television, a table computer, a notebook (laptop) computer, a personal computer, a vehicle dashboard, or the like.

[0176] In certain embodiments, the output device 620 includes one or more speakers for producing sound. For example, the output device 620 can produce an audible alert or notification (e.g., a beep or chime). In some embodiments, the output device 620 includes one or more haptic devices for producing vibrations, motion, or other tactile feedback. In some embodiments, all or portions of the output device 620 can be integrated with the input device 615. For example, the input device 615 and output device 620 can form a touch screen or similar touch-sensitive display. In other embodiments, all or portions of the output device 620 can be located near the input device 615.

[0177] The transceiver 625 can communicate with one or more remote units and / or with one or more interworking functions providing access to one or more PLMNs, as discussed above. The transceiver 625 can also communicate with one or more network functions, e.g., in the mobile core network 140. The transceiver 625 operates under the control of the processor 605 to transmit and to receive messages, data, and other signals. For example, the processor 605 can selectively activate the transceiver (or portions thereof) for message transmission and reception at particular times.

[0178] The transceiver 625 can include one or more transmitters 630 and one or more receivers 635. In certain embodiments, the one or more transmitters 630 and / or the one or more receivers 635 can share transceiver hardware and / or circuitry. For example, the one or more transmitters 630 and / or the one or more receivers 635 can share antennas, antenna tuners, amplifiers, filters, oscillators, mixers, modulators / demodulators, power sources, and so forth. In one embodiment, the transceiver 625 implements multiple logical transceivers using different communication protocols or protocol stacks, while using common physical hardware.

[0179] Figure 7 One embodiment of a method 700 for using pseudonyms for access authentication over non-3GPP access is depicted in accordance with the embodiments of the present disclosure. In various embodiments, the method 700 is performed by a UE, such as the remote unit 105, the UE 205, and / or the user equipment apparatus 500, described above. In some embodiments, the method 700 is performed by a processor, such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0180] The method 700 starts and sends 705 a registration message to a first network function of a mobile communication network via a 3GPP access network, the first authentication message including a first indicator for the apparatus and a SUCI. Here, the first indicator includes an indication that the apparatus has a capability for access authentication for non-3GPP access in an EPS. The method 700 includes receiving 710 a first identification pseudonym for the apparatus in response to the registration message including the first indicator. The method 700 includes performing 715 access authentication via a non-3GPP access network using the first identification pseudonym. The method 700 ends.

[0181] Figure 8One embodiment of a method 800 for using pseudonyms for access authentication over non-3GPP access according to embodiments of the disclosure is depicted. In various embodiments, the method 800 is performed by a subscription and user data manager such as the UDM / UDR 149, UDM 215, and / or network equipment apparatus 600 described above. In some embodiments, the method 800 is performed by a processor such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0182] The method 800 begins and receives 805 a registration request from a remote unit, where the registration request includes a first indicator for the apparatus and a SUCI. The method 800 includes obtaining 810 an identification pseudonym for the remote unit in response to receiving the first indicator.

[0183] The method 800 includes storing 815 a mapping of the identification pseudonym to a subscriber identity of the remote unit. The method 800 includes sending 820 the identification pseudonym to the remote unit, where the mobile communication network uses the identification pseudonym to authenticate the remote unit for non-3GPP access in an EPS. The method 800 ends.

[0184] Figure 9 One embodiment of a method 900 for using pseudonyms for access authentication over non-3GPP access according to embodiments of the disclosure is depicted. In various embodiments, the method 900 is performed by an authentication server such as the AUSF 146, 3GPP AAA server 405, and / or network equipment apparatus 600 described above. In some embodiments, the method 900 is performed by a processor such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0185] The method 900 begins and receives 905 a first authentication message from a remote unit authenticating with a mobile communication network via a non-3GPP access network, the first authentication message including a first identification pseudonym for the remote unit. Here, the first identification pseudonym is received by the remote unit during a prior registration with the mobile communication network via a 3GPP access network.

[0186] The method 900 includes retrieving 910 an authentication vector for the first identification pseudonym. The method 900 includes creating 915 a second identification pseudonym for the remote unit. The method 900 includes storing 920 the second identification pseudonym in the mobile communication network.

[0187] The method 900 includes sending 925 a second authentication message to the remote unit, the second authentication message including the second identification pseudonym and a challenge packet derived from the authentication vector. The method 900 includes completing 930 authentication with the remote unit. The method 900 ends.

[0188] Figure 10One embodiment of a method 1000 for using pseudonyms for access authentication over non-3GPP access according to embodiments of the disclosure is depicted. In various embodiments, the method 1000 is performed by a UE such as the remote unit 105, the UE 205, and / or the user equipment apparatus 500, described above. In some embodiments, the method 1000 is performed by a processor such as a microcontroller, a microprocessor, a CPU, a GPU, an auxiliary processing unit, a FPGA, or the like.

[0189] The method 1000 begins and transmits 1005 a first authentication message to a second network function to authenticate with a mobile communication network via a non-3GPP access network, the first authentication message including a first identification pseudonym received by the apparatus during a previous registration with the mobile communication network via a 3GPP access network.

[0190] The method 1000 includes receiving 1010 a second authentication message from the second network function in response to the first authentication message, the second authentication message including a challenge packet and a second identification pseudonym, the second identification pseudonym generated by the mobile communication network in response to the first authentication message including the first identification pseudonym.

[0191] The method 1000 includes completing 1015 authentication with the mobile communication network using the challenge packet. The method 1000 includes locally storing 1020 the second identification pseudonym. The method 1000 ends.

[0192] A first apparatus for using pseudonyms for access authentication over non-3GPP access according to embodiments of the disclosure is disclosed. The first apparatus can be implemented by a UE such as the remote unit 105, the UE 205, and / or the user equipment apparatus 500. The first apparatus includes a processor and a transceiver that communicates with a mobile communication network using a 3GPP access network and a non-3GPP access network. The processor transmits a registration message to a first network function in the mobile communication network via the 3GPP access network, the first authentication message including a first indicator for the first apparatus and a SUCI, wherein the first indicator includes an indication that the first apparatus has a capability for access authentication for non-3GPP access in an EPS. The processor receives a first identification pseudonym for the first apparatus in response to the registration message including the first indicator and performs access authentication via the non-3GPP access network using the first identification pseudonym.

[0193] In some embodiments, the indication of the capability of the remote unit for access authentication for non-3GPP access in the EPS includes a 5GMM capability information element. In some embodiments, the processor determines whether an identity pseudonym is preconfigured prior to sending the registration message. In such embodiments, the processor includes a first indicator in response to determining that no identity pseudonym is preconfigured. In some embodiments, the first identity pseudonym is a one-time token for conveying a permanent subscriber identity of the first apparatus in a concealed manner.

[0194] In one embodiment, the UDM in the mobile communication network generates the first identity pseudonym. In another embodiment, the HSS in the mobile communication network generates the first identity pseudonym. In a further embodiment, the AAA server is in the mobile communication network. In various embodiments, the mobile communication network stores the first identity pseudonym locally at least at the UDM and the HSS.

[0195] In some embodiments, performing the access authentication via the non-3GPP access network using the first identity pseudonym includes the processor sending a first authentication message to a second network function to authenticate with the mobile communication network via the non-3GPP access network, the first authentication message including the first identity pseudonym. The processor receives a second authentication message from the second network function in response to the first authentication message, the second authentication message including a challenge packet and a second identity pseudonym. Here, the mobile communication network generates the second identity pseudonym in response to the first authentication message including the first identity pseudonym. The processor completes the authentication with the mobile communication network using the challenge packet and stores the second identity pseudonym locally.

[0196] In some embodiments, the second network function includes a AAA server in the mobile communication network. In certain embodiments, the AAA server generates the second identity pseudonym in response to the first authentication message including the first identity pseudonym. In some embodiments, storing the second identity pseudonym locally includes replacing the first identity pseudonym with the second identity pseudonym.

[0197] Disclosed herein is a first method for using pseudonyms for access authentication over non-3GPP access according to embodiments of the disclosure. The first method can be performed by a UE, such as the remote unit 105, the UE 205, and / or the user equipment apparatus 500. The first method includes sending a registration message to a first network function in a mobile communication network via a 3GPP access network, the first authentication message including a first indicator for the UE and a SUCI, where the first indicator includes an indication that the UE has a capability for access authentication for non-3GPP access in the EPS. The first method includes receiving a first identity pseudonym for the UE in response to the registration message including the first indicator, and performing the access authentication via the non-3GPP access network using the first identity pseudonym.

[0198] In some embodiments, the indication of the remote unit's capability for access authentication for non-3GPP access in an EPS includes a 5GMM capability information element. In some embodiments, the first method includes determining whether an identity pseudonym is preconfigured prior to sending the registration message. In such embodiments, the first indicator is included in the registration message in response to determining that no identity pseudonym is preconfigured. In some embodiments, the first identity pseudonym is a one-time token for conveying a permanent subscriber identity of the UE in a concealed manner.

[0199] In one embodiment, the UDM in the mobile communication network generates the first identity pseudonym. In another embodiment, the HSS in the mobile communication network generates the first identity pseudonym. In a further embodiment, the AAA server is in the mobile communication network. In various embodiments, the mobile communication network locally stores the first identity pseudonym at least at the UDM and the HSS.

[0200] In some embodiments, performing access authentication via the non-3GPP access network using the first identity pseudonym includes sending a first authentication message to a second network function to authenticate with the mobile communication network via the non-3GPP access network, the first authentication message including the first identity pseudonym. The access authentication includes receiving a second authentication message from the second network function in response to the first authentication message, the second authentication message including a challenge packet and a second identity pseudonym. Here, the mobile communication network generates the second identity pseudonym in response to the first authentication message including the first identity pseudonym. The access authentication includes completing authentication with the mobile communication network using the challenge packet, and locally storing the second identity pseudonym.

[0201] In some embodiments, the second network function includes a AAA server in the mobile communication network. In certain embodiments, the AAA server generates the second identity pseudonym in response to the first authentication message including the first identity pseudonym. In some embodiments, locally storing the second identity pseudonym includes replacing the first identity pseudonym with the second identity pseudonym.

[0202] Disclosed herein is a second apparatus for using pseudonyms for access authentication over non-3GPP access according to embodiments of the disclosure. The second apparatus can be implemented by a subscription and user data manager such as the UDM / UDR 149, the UDM 215, and / or the network equipment apparatus 600. The second apparatus includes a processor and a network interface that communicates with a mobile communication network. The processor receives a registration request from a remote unit (i.e., a UE), where the registration request contains a first indicator for the remote unit and a SUCI. The processor obtains an identity pseudonym for the remote unit in response to receiving the first indicator, and stores a mapping of the identity pseudonym to a subscriber identity of the remote unit. The processor sends the identity pseudonym to the remote unit, where the mobile communication network uses the identity pseudonym to authenticate the remote unit for non-3GPP access in an EPS.

[0203] In some embodiments, the first indicator includes an indication that the remote unit has a capability for access authentication for non-3GPP access in an EPS and a subscriber identity of the remote unit. In certain embodiments, the indication that the remote unit has a capability for access authentication for non-3GPP access in an EPS includes a 5GMM capability information element. In some embodiments, the identity pseudonym includes a one-time token for conveying a permanent subscriber identity of the remote unit in a concealed manner.

[0204] In some embodiments, the identity pseudonym is created using at least one of: a SUPI and an IMSI of the remote unit. In one embodiment, creating the identity pseudonym includes encrypting a subscriber identifier. In one embodiment, creating the identity pseudonym includes using a random number generator and a subscriber identity to generate a unique value. In one embodiment, creating the identity pseudonym includes using a hash function and a subscriber identity to generate a hash value. In one embodiment, creating the identity pseudonym includes sending the subscriber identity to a HSS in a mobile communication network and receiving the identity pseudonym from the HSS. In another embodiment, creating the identity pseudonym includes sending the subscriber identity to a AAA server in a mobile communication network and receiving the identity pseudonym from the AAA server.

[0205] In some embodiments, the second apparatus includes a UDM. In such embodiments, storing a mapping of the identity pseudonym to a permanent subscriber identity of the remote unit includes sending the identity pseudonym to a home subscriber server in a mobile communication network. In one embodiment, sending the identity pseudonym to the remote unit includes sending the identity pseudonym in a registration accept message. In another embodiment, sending the identity pseudonym to the remote unit includes initiating a UPU procedure, wherein the identity pseudonym is sent to the remote unit within UPU data.

[0206] Disclosed herein is a second method for using a pseudonym for access authentication over non-3GPP access according to embodiments of the disclosure. The second method can be performed by a subscription and user data manager such as the UDM / UDR 149, the UDM 215, and / or the network equipment apparatus 600. The second method includes receiving a registration request from a remote unit, wherein the registration request contains a first indicator for the remote unit and a SUCI. The second method includes obtaining an identity pseudonym for the remote unit in response to receiving the first indicator, and storing a mapping of the identity pseudonym to a subscriber identity of the remote unit. The second method includes sending the identity pseudonym to the remote unit, wherein the mobile communication network uses the identity pseudonym to authenticate the remote unit for non-3GPP access in an EPS.

[0207] In some embodiments, the first indicator includes an indication that the remote unit has a capability for access authentication for non-3GPP access in an EPS and a subscriber identity of the remote unit. In certain embodiments, the indication that the remote unit has a capability for access authentication for non-3GPP access in an EPS includes a 5GMM capability information element. In some embodiments, the identification pseudonym includes a one-time token for conveying a permanent subscriber identity of the remote unit in a concealed manner.

[0208] In some embodiments, the identification pseudonym is created using at least one of: a SUPI and an IMSI of the remote unit. In one embodiment, creating the identification pseudonym includes encrypting a subscriber identifier. In one embodiment, creating the identification pseudonym includes using a random number generator and the subscriber identity to generate a unique value. In one embodiment, creating the identification pseudonym includes using a hash function and the subscriber identity to generate a hash value. In one embodiment, creating the identification pseudonym includes sending the subscriber identity to a HSS in the mobile communication network and receiving the identification pseudonym from the HSS. In another embodiment, creating the identification pseudonym includes sending the subscriber identity to a AAA server in the mobile communication network and receiving the identification pseudonym from the AAA server.

[0209] In some embodiments, the subscription and user data manager is a UDM. In such embodiments, storing a mapping of the identification pseudonym to the permanent subscriber identity of the remote unit includes sending the identification pseudonym to a home subscriber server in the mobile communication network. In one embodiment, sending the identification pseudonym to the remote unit includes sending the identification pseudonym in a registration accept message. In another embodiment, sending the identification pseudonym to the remote unit includes initiating a UPU procedure, wherein the identification pseudonym is sent to the remote unit within UPU data.

[0210] Disclosed herein is a third apparatus for using pseudonyms for access authentication over non-3GPP access according to embodiments of the disclosure. The third apparatus can be implemented by an authentication server such as the AUSF 146, the 3GPP AAA server 405, and / or the network equipment apparatus 600. The third processor includes a processor and a network interface that communicates with a mobile communication network. The processor receives a first authentication message authenticating a remote unit with the mobile communication network via a non-3GPP access network, the first authentication message including a first identification pseudonym for the remote unit. Here, the first identification pseudonym is received by the remote unit during a previous registration with the mobile communication network via a 3GPP access network. The processor retrieves an authentication vector for the first identification pseudonym, creates a second identification pseudonym for the remote unit, and stores the second identification pseudonym in the mobile communication network. The processor sends a second authentication message to the remote unit and completes authentication with the remote unit. Here, the second authentication message includes the second identification pseudonym and a challenge packet derived from the authentication vector.

[0211] In some embodiments, the first and second identity pseudonyms are both one-time tokens used to convey the remote unit's permanent subscriber identity in a concealed manner, wherein the first and second identity pseudonyms are mapped to the remote unit's permanent subscriber identity. In some embodiments, retrieving the authentication vector includes sending the first identity pseudonym to a HSS in the mobile communication network and receiving the remote unit's permanent subscriber identity, wherein the HSS stores a mapping of the first identity pseudonym to the remote unit's permanent subscriber identity. In certain embodiments, storing the second identity pseudonym includes sending the second identity pseudonym to the HSS.

[0212] In some embodiments, the second identity pseudonym is created using at least one of: the remote unit's subscriber permanent identifier and an international mobile subscriber identity. In one embodiment, creating the second identity pseudonym includes encrypting the remote unit's permanent subscriber identity. In one embodiment, creating the second identity pseudonym includes using a random number generator and the remote unit's permanent subscriber identity to generate a unique value. In one embodiment, creating the second identity pseudonym includes using a hash function and the remote unit's permanent subscriber identity to generate a hash value. In certain embodiments, storing the second identity pseudonym includes replacing the first identity pseudonym with the second identity pseudonym.

[0213] In one embodiment, the processor receives a request from a HSS in the mobile communication network to create an identity pseudonym for a remote unit (i.e., UE). Here, the request can include the remote unit's permanent subscriber identity. In response, the processor creates an initial pseudonym and sends the created identity pseudonym to the HSS. In another embodiment, the processor receives a request from a UDM in the mobile communication network to create an identity pseudonym for a remote unit (i.e., UE). Here, the request can include the remote unit's permanent subscriber identity. In response, the processor creates an initial pseudonym and sends the created identity pseudonym to the UDM.

[0214] Disclosed herein is a third method for using pseudonyms for access authentication over non-3GPP access according to embodiments of the disclosure. The third method can be performed by an authentication server such as the AUSF 146, the 3GPP AAA server 405, and / or the network equipment apparatus 600. The third method includes receiving a first authentication message authenticating a remote unit with a mobile communication network via a non-3GPP access network, the first authentication message including a first identification pseudonym for the remote unit. Here, the first identification pseudonym is received by the remote unit during a previous registration with the mobile communication network via a 3GPP access network. The third method includes retrieving an authentication vector for the first identification pseudonym, creating a second identification pseudonym for the remote unit, and storing the second identification pseudonym in the mobile communication network. The third method includes sending a second authentication message to the remote unit and completing authentication with the remote unit. Here, the second authentication message includes the second identification pseudonym and a challenge packet derived from the authentication vector.

[0215] In some embodiments, the first and second identification pseudonyms are both one-time tokens for conveying a permanent subscriber identity of the remote unit in a concealed manner, wherein the first and second identification pseudonyms are mapped to the permanent subscriber identity of the remote unit. In some embodiments, retrieving the authentication vector includes sending the first identification pseudonym to a HSS in the mobile communication network and receiving the permanent subscriber identity of the remote unit, wherein the HSS stores a mapping of the first identification pseudonym to the permanent subscriber identity of the remote unit. In certain embodiments, storing the second identification pseudonym includes sending the second identification pseudonym to the HSS.

[0216] In some embodiments, the second identification pseudonym is created using at least one of: a subscriber permanent identifier of the remote unit and an international mobile subscriber identity. In one embodiment, creating the second identification pseudonym includes encrypting the permanent subscriber identity of the remote unit. In one embodiment, creating the second identification pseudonym includes using a random number generator and the permanent subscriber identity of the remote unit to generate a unique value. In one embodiment, creating the second identification pseudonym includes using a hash function and the permanent subscriber identity of the remote unit to generate a hash value. In certain embodiments, storing the second identification pseudonym includes replacing the first identification pseudonym with the second identification pseudonym.

[0217] In one embodiment, the third method includes receiving a request from a HSS in a mobile communication network to create an identification pseudonym for a remote unit (i.e., UE). Here, the request can include a permanent subscriber identity of the remote unit. In response, the third method includes creating an initial pseudonym and sending the created identification pseudonym to the HSS. In another embodiment, the third method includes receiving a request from a UDM in a mobile communication network to create an identification pseudonym for a remote unit (i.e., UE). Here, the request can include a permanent subscriber identity of the remote unit. In response, the third method includes creating an initial pseudonym and sending the created identification pseudonym to the UDM.

[0218] Disclosed herein is a fourth apparatus for using pseudonyms for access authentication over non-3GPP access according to embodiments of the disclosure. The fourth apparatus can be implemented by a UE such as the remote unit 105, the UE 205, and / or the user equipment apparatus 500. The fourth apparatus includes a processor and a transceiver that communicates with a mobile communication network using a 3GPP access network and a non-3GPP access network. The processor sends a first authentication message to a second network function to authenticate with the mobile communication network via the non-3GPP access network. Here, the first authentication message includes a first identification pseudonym received by the fourth apparatus during a previous registration with the mobile communication network via the 3GPP access network. The processor receives a second authentication message from the second network function in response to the first authentication message. Here, the second authentication message includes a challenge packet and a second identification pseudonym, where the second identification pseudonym is generated by the mobile communication network in response to the first authentication message including the first identification pseudonym. The processor completes authentication with the mobile communication network using the challenge packet and locally stores the second identification pseudonym.

[0219] In certain embodiments, locally storing the second identification pseudonym includes replacing the first identification pseudonym with the second identification pseudonym. In certain embodiments, the first identification pseudonym and the second identification pseudonym are one-time tokens used to convey a permanent subscriber identity of the fourth apparatus in a concealed manner. In certain embodiments, the second network function includes a AAA server in the mobile communication network, where the AAA server generates the second identification pseudonym in response to the first authentication message including the first identification pseudonym. Here, the mobile communication network locally stores the first identification pseudonym and the second identification pseudonym.

[0220] In some embodiments, the previous registration with the mobile communication network includes the processor sending a registration message to a first network function in the mobile communication network via the 3GPP access network and receiving a first identification pseudonym for the fourth apparatus in response to the registration message including a first indicator. In such embodiments, the first authentication message includes the first indicator and a SUCI for the fourth apparatus, where the first indicator includes an indication that the fourth apparatus has a capability for access authentication for non-3GPP access in an EPS.

[0221] In certain embodiments, the indication of the capability of the remote unit for access authentication for non-3GPP access in EPS includes a 5GMM capability information element. In some embodiments, the processor determines whether an identity pseudonym is preconfigured prior to sending the registration message, wherein the processor includes a first indicator in response to determining that no identity pseudonym is preconfigured.

[0222] In some embodiments, a UDM in the mobile communication network generates the first identity pseudonym. In other embodiments, a HSS in the mobile communication network generates the first identity pseudonym.

[0223] Disclosed herein is a fourth method for using pseudonyms for access authentication over non-3GPP access according to embodiments of the disclosure. The fourth method can be performed by a UE, such as the remote unit 105, the UE 205, and / or the user equipment apparatus 500. The fourth method includes sending a first authentication message to a second network function to authenticate with a mobile communication network via a non-3GPP access network. Here, the first authentication message includes a first identity pseudonym received by the UE during a previous registration with the mobile communication network via a 3GPP access network. The fourth method includes receiving a second authentication message from the second network function in response to the first authentication message. Here, the second authentication message includes a challenge packet and a second identity pseudonym, wherein the second identity pseudonym is generated by the mobile communication network in response to the first authentication message including the first identity pseudonym. The fourth method includes completing authentication with the mobile communication network using the challenge packet and locally storing the second identity pseudonym.

[0224] In certain embodiments, locally storing the second identity pseudonym includes replacing the first identity pseudonym with the second identity pseudonym. In certain embodiments, the first identity pseudonym and the second identity pseudonym are one-time tokens used to convey a permanent subscriber identity of the UE in a concealed manner. In certain embodiments, the second network function includes a AAA server in the mobile communication network, wherein the AAA server generates the second identity pseudonym in response to the first authentication message including the first identity pseudonym. Here, the mobile communication network locally stores the first identity pseudonym and the second identity pseudonym.

[0225] In some embodiments, the previous registration with the mobile communication network includes the UE sending a registration message to a first network function in the mobile communication network via a 3GPP access network and receiving a first identity pseudonym for the UE in response to the registration message including a first indicator. In such embodiments, the first authentication message includes the first indicator for the UE and a SUCI, wherein the first indicator includes an indication that the UE has a capability for access authentication for non-3GPP access in EPS.

[0226] In certain embodiments, the indication of the remote unit's capability for access authentication for non-3GPP access in the EPS includes a 5GMM capability information element. In some embodiments, the fourth method includes determining whether an identity pseudonym is preconfigured prior to sending the registration message, wherein the first indicator is included in the registration message in response to determining that no identity pseudonym is preconfigured.

[0227] In some embodiments, a UDM in the mobile communication network generates the first identity pseudonym. In other embodiments, a HSS in the mobile communication network generates the first identity pseudonym.

[0228] Embodiments can be practiced in other specific forms. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the application is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A user equipment (UE) comprising: a processor; and a memory coupled to the processor, the processor configured to cause the UE to: determine whether an identity pseudonym is preconfigured; send, via a third generation partnership project (3GPP) access network, a registration message to a first network function in a mobile communication network, the registration message comprising a first indicator for the UE and a subscription concealed identifier (SUCI), wherein the first indicator comprises an indication that the UE has a capability for access authentication for non-3GPP access in an evolved packet system (EPS), and wherein the processor is configured to cause the UE to include the first indicator in response to determining that no identity pseudonym is preconfigured; receive, in response to the registration message comprising the first indicator, a first identity pseudonym for the UE; and perform access authentication via a non-3GPP access network using the first identity pseudonym. The first identity pseudonym is a one-time token for conveying a subscriber permanent identifier (SUPI) of the UE in a concealed manner.

2. The UE of claim 1, wherein, The indication comprises a fifth generation mobility management (5GMM) capability information element.

3. The UE of claim 1, wherein, To perform access authentication via the non-3GPP access network using the first identity pseudonym, the processor is configured to:

4. The UE of claim 1, wherein, send, to a second network function, a first authentication message to authenticate with the mobile communication network via the non-3GPP access network, the first authentication message comprising the first identity pseudonym; receive, from the second network function in response to the first authentication message, a second authentication message comprising a challenge packet and a second identity pseudonym, complete authentication with the mobile communication network using the challenge packet; and store the second identity pseudonym locally. The second network function comprises an authentication, authorization, and accounting (AAA) server in the mobile communication network, and wherein storing the second identity pseudonym locally comprises replacing the first identity pseudonym with the second identity pseudonym.

5. The UE of claim 4, wherein, 6. A unified data management (UDM) apparatus comprising: a processor; and a memory coupled to the processor, the processor configured to cause the UDM to: receive, from a user equipment (UE), a registration request, wherein the registration request contains a first indicator for the UE and a subscription concealed identifier (SUCI); obtain, in response to receiving the first indicator, an identity pseudonym for the UE, wherein the identity pseudonym is usable to authenticate the UE for non-3GPP access in an evolved packet system (EPS); store a mapping of the identity pseudonym to a subscriber identity of the UE; initiate a UE parameter update (UPU) procedure; and send, to the UE within UPU data, the identity pseudonym. The first indicator comprises an indication that the UE has a capability for access authentication for non-3GPP access in an evolved packet system (EPS) and a subscriber identity of the UE. The indication comprises a fifth generation mobility management (5GMM) capability information element.

7. The UDM apparatus of claim 6, wherein, The identity pseudonym comprises a one-time token for conveying a subscriber permanent identifier (SUPI) of the UE in a concealed manner.

8. The UDM device of claim 7, wherein, ​ 9. The UDM device of claim 6, wherein, ​ 10. The UDM device of claim 6, wherein, To obtain the identity pseudonym, the processor is configured to create the identity pseudonym using a subscriber permanent identifier (SUPI) of the UE, an international mobile subscriber identifier (IMSI) of the UE, or a combination thereof.

11. The UDM device of claim 6, wherein, To obtain the identity pseudonym, the processor is configured to encrypt the subscriber identity, generate a unique value using a random number generator and the subscriber identity, generate a hash value using a hash function and the subscriber identity, or a combination thereof.

12. The UDM device of claim 6, wherein, To obtain the identity pseudonym, the processor is configured to send the subscriber identity to one of a home subscriber server (HSS) and an authentication server in a mobile communication network, and receive the identity pseudonym from the one of the HSS and the authentication server.

13. The UDM device of claim 6, wherein, To store the mapping of the identity pseudonym to a subscriber permanent identifier (SUPI) of the UE, the processor is configured to send the identity pseudonym to a home subscriber server (HSS) in a mobile communication network.

14. The UDM device of claim 9, wherein, To send the identity pseudonym to the UE, the processor is configured to send the identity pseudonym in a registration accept message.

15. An authentication, authorization, and accounting (AAA) server comprising: a processor; and a memory coupled to the processor, the processor configured to cause the AAA server to: receive a first authentication message authenticating a user equipment (UE) with a mobile communication network via a non-3GPP access network, the first authentication message including a first identity pseudonym for the UE, wherein the first identity pseudonym is received by the UE during a previous registration with the mobile communication network via a third generation partnership project (3GPP) access network; retrieve an authentication vector for the first identity pseudonym; create a second identity pseudonym for the UE; store the second identity pseudonym in the mobile communication network; forward the second identity pseudonym to a home subscriber server (HSS); send a second authentication message to the UE, the second authentication message including the second identity pseudonym and a challenge packet derived from the authentication vector; and complete authentication with the UE.

16. The AAA server of claim 15, wherein, The first and second identity pseudonyms are each a one-time token for conveying a subscriber permanent identifier (SUPI) of the UE in a hidden manner, wherein the first and second identity pseudonyms are mapped to the SUPI of the UE, and wherein to store the second identity pseudonym, the processor is configured to replace the first identity pseudonym with the second identity pseudonym.

17. The AAA server of claim 15, wherein, To retrieve the authentication vector, the processor is configured to cause the AAA server to send the first identity pseudonym to the HSS in the mobile communication network and receive a subscriber permanent identifier (SUPI) of the UE, wherein the HSS stores a mapping of the first identity pseudonym to the SUPI of the UE, and wherein to store the second identity pseudonym, the processor is configured to cause the AAA server to send the second identity pseudonym to the HSS.

18. The AAA server of claim 15, wherein, The second identification pseudonym is created using at least one of: a subscriber permanent identifier of the UE and an international mobile subscriber identity.

19. The AAA server of claim 15, wherein, To create the second identification pseudonym, the processor is configured to encrypt a subscriber permanent identifier SUPI of the UE, generate a unique value using a random number generator and the SUPI of the UE, and / or generate a hash value using a hash function and the SUPI of the UE.

Images