Method and apparatus for secure implementation of connectivity through heterogeneous access networks

Abstract

This application relates to session establishment by a user equipment through multiple heterogeneous access networks. In one aspect, the heterogeneous access networks can include 3GPP and non-3GPP access networks (106). The non-3GPP access networks (106) can include one or more trusted non-3GPP access networks (108) or one or more untrusted non-3GPP access networks (110).

Description

TECHNICAL FIELD

[0001] The present application relates generally to access networks, and more specifically, to session establishment by a user equipment over multiple heterogeneous access networks BACKGROUND

[0002] The statements in this section provide a description and do not constitute an admission as to the correctness or correctness of the prior art. A user equipment (UE), such as a smartphone, smart tablet, laptop, computer, smartwatch, etc., typically has both wireless local area network (WLAN) connectivity (e.g., WLAN connectivity conforming to IEEE 802.1 lx) and radio access network connectivity (e.g., technology conforming in whole or in part to the Third Generation Partnership Project (3GPP) set of standards, including EVDO, UMTS, HSPA, and LTE). The UE can thus connect to a 3GPP evolved packet core (EPC) network using two types of access technologies consisting of 3GPP access networks and non-3GPP access networks.

[0003] Generally, 3GPP access networks conform in whole or in part to technology specified by the 3GPP set of standards, including, for example, GPRS, UMTS, EDGE, HSPA, LTE, and LTE-Advanced. Non-3GPP access networks conform in whole or in part to technology not specified by the 3GPP set of standards. The technology includes, for example, cdma2000, WLAN (e.g., WLAN conforming to IEEE 802.1 lx), or fixed network technology.

[0004] The 3GPP set of standards specifies "non-3GPP" access technologies with different security mechanisms: untrusted access networks and trusted access networks. Untrusted access networks include access networks that can pose a higher security risk (e.g., public WLAN or femtocell access networks). Trusted access networks include access networks that the network operator has a level of trust from a security perspective and can directly interface with the EPC network.

[0005] In the new 5G standards set, one of the most important features of the 5G system is that the 5G system provides an access agnostic aggregation core network. Different access network types including 3GPP access and non-3GPP access can be supported via a common access network and core network interface. Non-3GPP access networks (N3ANs) are considered as 5G access networks and are considered as part of the 5G system (5GS).

[0006] For untrusted non-3GPP access, as for NG-RAN nodes, the N3G access node N3IWF provides termination of the signaling interfaces for the control plane and user plane, respectively. Thus, a 5G capable UE is able to access the 5G core network by connecting to a non-3GPP access network as a 5G access network via the N3IWF. The N3IWF relays uplink and downlink control plane signaling between the UE and the AMF, so that the UE has a direct control plane signaling connection to the AMF. In addition, the N3IWF provides a user plane connection between the UE and the UPF for PDU sessions over non-3GPP access networks.

[0007] When a UE is registered to the 5G core through both 3GPP access networks and non-3GPP access networks, multiple non-access stratum (NAS) connections can be active at the same time. The UE can be registered in the same PLMN or different PLMNs. If the UE is accessing one PLMN through one type of access (e.g., 3GPP access) and is accessing another PLMN through another type of access (e.g., non-3GPP access), different primary authentication is performed. After registration, the NAS connections can be served by different AMFs with different security contexts. However, if the UE requests registration in the same serving network through different types of access networks, one common 5G NAS security context is created through the first type of access during the registration procedure, and all NAS connections are served by the same AMF.

[0008] Currently, for 3GPP access, the NAS connection identifier is assumed to be “0”. For non-3GPP access, the NAS connection identifier is assumed to be “1”. There is a problem when additional non-3GPP access network types are added in future releases, e.g., trusted WLAN access, wired access, MuLteFire access, etc. These different types of non-3GPP access networks all need to establish separate NAS connections. However, there is currently only one NAS connection identifier “1” for NAS connections over different types of non-3GPP access networks.

[0009] Therefore, there is a need to provide a system and method that supports NAS connections over multiple different types of non-3GPP access networks. Embodiments described herein also provide other needs and benefits. SUMMARY

[0010] Embodiments described herein provide systems, apparatuses, methods, and / or computer program products for providing network services to unauthenticated user equipment. For example, various methods are described with respect to session establishment for unauthenticated UEs in trusted non-3GPP access networks.

[0011] According to an embodiment, a user equipment is provided, the user equipment comprising: one or more transceivers configured to access a service network through a plurality of access network types; a memory device configured to store a mapping table; and a processing device configured to: generate a request to register with the service network through a first access network, wherein the request comprises a first access network type of the first access network; receive a response indicating that a NAS connection setup is accepted by the service network, wherein the response comprises the first access network type and a NAS connection identifier; and update the mapping table to include the first access network type and the NAS connection identifier. In some embodiments, the first access network type comprises a value indicating at least one of: 3GPP access, untrusted non-3GPP access, trusted non-3GPP access, untrusted WLAN access, trusted WLAN access, or MuLteFire access. In some embodiments, the processing device is further configured to: update the mapping table to include the first access network type, the NAS connection identifier, an access network identifier, and a service network identifier. In some embodiments, the processing device can be further configured to: generate a second request to register with the service network through a second access network having a second access network type, wherein the second request comprises the second access network type of the second access network; receive a response indicating that a connection setup is accepted by the service network, wherein the response comprises the second access network type and a second NAS connection identifier; and update the mapping table to include the second access network type and the second NAS connection identifier. In some embodiments, the second access network type is different from the first access network type, and wherein the second access network type indicates a second different one of: 3GPP access, untrusted non-3GPP access, trusted non-3GPP access, untrusted WLAN access, trusted WLAN access, or MuLteFire access. In some embodiments, the processing device can be further configured to: generate a third request to register with the service network through a third access network having a third access network type, wherein the third request comprises the third access network type of the third access network; receive a response indicating that a connection setup is accepted by the service network, wherein the response comprises the third access network type and a third NAS connection identifier; and update the mapping table to include the third access network type and the third NAS connection identifier.In some embodiments, the third access network type is different from the first access network type and the second access network type, and wherein the third access network type indicates a third different one of: 3GPP access, untrusted non-3GPP access, trusted non-3GPP access, untrusted WLAN access, trusted WLAN access, or MuLteFire access. In some embodiments, the processing device is further configured to: use, with the service network, an existing NAS security context established through the first access network. In some embodiments, the processing device is further configured to: receive a request to perform authentication for a connection through the third access network; obtain a new NAS security context from the service network through the third access network; establish a NAS connection through the third access network using the new NAS security context; activate the new NAS security context for the first access network and the second access network; and delete a previous NAS security context.

[0012] According to another embodiment, a user equipment is provided, the user equipment comprising: one or more transceivers configured to access a service network through a plurality of access network types; a processing device configured to: generate a request to register with the service network through an access network; and receive a registration reject message, wherein the registration reject message indicates that the service network is not authorized. In some embodiments, the registration reject message comprises a cause information element, wherein the cause information element comprises a value corresponding to "service network not authorized". In some embodiments, the processing device is further configured to: abort registration with the service network; store an identity of the service network in a list of un-authorized service networks ["Forbidden PLMN List"]. In some embodiments, the processing device is further configured to select another service network for registration.

[0013] According to another embodiment, an authentication server function in a node of a core network, comprising: a transceiver configured to communicate with one or more other nodes in the core network; a processing device configured to: receive an authentication request for a UE requesting access to a service network, wherein the authentication request comprises an identifier of the service network and a subscriber identity; and determine that the service network is not authorized; and generate an authentication response, wherein the authentication response indicates that the service network is not authorized. In some embodiments, the authentication response can comprise a cause information element, wherein the cause information element comprises a value corresponding to "service network not authorized".

[0014] According to another embodiment, a user equipment can be provided that includes a transceiver configured to communicate with one or more types of access networks; a processing device configured to generate a SUCI by determining one of a plurality of SUPI formats; determining one of a plurality of types of identities of a subscriber identifier; determining a scheme output from the subscriber identifier using a protection scheme; and constructing the SUCI to include a SUPI format value, an identity value type, and the scheme output. In some embodiments, the one of the plurality of types of identities of the subscriber identifier includes one of a SUCI, a 5G-GUTI, an IMEI, a 5G-S-TMSI, an IMEISV, a MAC address, or a device identity. In some embodiments, the one of the plurality of SUPI formats includes at least one of an IMSI, an IMSI-based NAI, a non-IMSI-based NAI, or an MF-NAI. In some embodiments, the processing device is further configured to generate the SUCI by selecting one of a plurality of network types and including a network type indicator of the selected network type in a SUCI structure.

[0015] According to another embodiment, an apparatus can be provided that includes at least one processor and at least one memory including computer program instructions, the at least one memory and the computer program instructions configured to, with the at least one processor, cause the apparatus at least to generate a request to register with a serving network over an access network; receive a registration reject message, wherein the registration reject message indicates that the serving network is not authorized by a home network of the apparatus; and in response to receiving the registration reject message indicating that the serving network is not authorized by the home network of the apparatus, enter a de-registration state such that the apparatus is configured to request registration with another serving network. In some embodiments, the registration reject message includes a cause information element, wherein the cause information element includes a value indicating that the serving network is not authorized by the home network of the apparatus. In some embodiments, the at least one processor is further configured to abort registration with the serving network; and store an identification of the serving network in a list of unauthorized serving networks. In some embodiments, the at least one processor is further configured to select the another serving network for registration. In some embodiments, the registration reject message indicates that the serving network is not authorized by the home network of the apparatus for third generation partnership project (3GPP) access to the serving network. In some embodiments, the at least one processor is further configured to, in response to receiving the registration reject message indicating that the serving network is not authorized by the home network of the apparatus, set a fifth generation system (5GS) update status to 5U2 not updated.

[0016] According to another embodiment, an apparatus can be provided that comprises at least one processor and at least one memory including computer program instructions, the at least one memory and the computer program instructions configured to, with the at least one processor, cause the apparatus at least to receive an authentication request that a user equipment requests to access a service network, wherein the authentication request comprises an identifier of the service network and a subscriber identity; determine whether the service network is authorized; and generate an authentication response in a case that the service network is not authorized, wherein the authentication response indicates that the service network is not authorized by a core network associated with the apparatus. In some embodiments, the authentication response comprises a cause information element, wherein the cause information element comprises a value that indicates that the service network is not authorized by the core network.

[0017] According to another embodiment, an apparatus can be provided that comprises at least one processor and at least one memory including computer program instructions, the at least one memory and the computer program instructions configured to, with the at least one processor, cause the apparatus at least to communicate with a core network via a selected type of access network; and construct a subscription concealed identifier for identifying the apparatus during communication with the core network and the selected type of access network, the subscription concealed identifier comprising at least: a subscription permanent identifier format type value corresponding to one of a plurality of subscription permanent identifier format types, the subscription permanent identifier format type value being associated with a subscription permanent identifier; a protection scheme identifier corresponding to one of a plurality of protection schemes pre-configured for the subscription permanent identifier; and a scheme output derived from the subscription permanent identifier using the one of the protection schemes pre-configured for the subscription permanent identifier. In some embodiments, the subscription permanent identifier comprises one of: an International Mobile Subscriber Identity (IMSI) or a network specific identifier type, the corresponding subscription permanent identifier format type value thereby allowing identification of the subscriber identifier format type from the IMSI or the network specific identifier type. In some embodiments, the subscription concealed identifier is transmitted to the core network as a mobile identity parameter, the mobile identity parameter having an identity type field indicating a subscription concealed identifier identity type. In some embodiments, the mobile identity parameter comprises a Fifth Generation System (5GS) mobile identity parameter, and the subscription concealed identifier (SUCI) identity type comprises a SUCI identity type. In some embodiments, the subscription permanent identifier format type value of the subscription concealed identifier is encoded in a subscription permanent identifier (SUPI) format field of the 5GS mobile identity parameter.

[0018] According to another embodiment, an apparatus can be provided that includes at least one processor and at least one memory including computer program instructions, the at least one memory and the computer program instructions configured to, with the at least one processor, cause the apparatus at least to receive, from a user equipment via a selected type of access network, a subscription concealed identifier comprising at least: a subscription permanent identifier format type value corresponding to one of a plurality of subscription permanent identifier format types, the subscription permanent identifier format type value being associated with a subscription permanent identifier; a protection scheme identifier corresponding to one of a plurality of protection schemes pre-configured for the subscription permanent identifier; and a scheme output derived from the subscription permanent identifier using the one of the protection schemes pre-configured for the subscription permanent identifier; and identify the user equipment based at least on the subscription concealed identifier during communication with the user equipment via the selected type of access network. In some embodiments, the subscription permanent identifier comprises one of: an International Mobile Subscriber Identity (IMSI) or a network specific identifier type, the corresponding subscription permanent identifier format type value thereby allowing identification of the subscriber identifier format type from the IMSI or network specific identifier type. In some embodiments, the at least one memory and the computer program instructions are configured to, with the at least one processor, cause the apparatus at least to identify the subscriber identifier format type from the IMSI or network specific identifier type based at least on the corresponding subscription permanent identifier format type value. In some embodiments, the subscription concealed identifier is received by the apparatus as a mobile identity parameter having an identity type field indicating a subscription concealed identifier identity type. In some embodiments, the mobile identity parameter comprises a Fifth Generation System (5GS) mobile identity parameter and the subscription concealed identifier (SUCI) identity type comprises a SUCI identity type. In some embodiments, the subscription permanent identifier format type value of the subscription concealed identifier is encoded in a subscription permanent identifier (SUPI) format field of the 5GS mobile identity parameter. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 According to some embodiments described herein, a schematic block diagram of an embodiment of a type of access network for an Evolved Packet Core that is fully or partially compliant with a Third Generation Partnership Project (3GPP) set of standards or other type of Internet Protocol (IP) data packet core network standard is illustrated;

[0020] Figure 2 According to some embodiments described herein, a schematic block diagram of an embodiment of a 5G System architecture for non-3GPP access is illustrated;

[0021] Figure 3 A schematic block diagram illustrating an embodiment of a method for a UE to access a 5G system through multiple heterogeneous access networks according to some embodiments described herein;

[0022] Figure 4 A logical flow diagram illustrating an embodiment of a method for authentication and key agreement message flow between a UE and core network functions when the UE initiates initial registration through access network type A according to some embodiments described herein;

[0023] Figure 5 A schematic block diagram illustrating an embodiment of a mapping table of service networks and access types to NAS connections according to some embodiments described herein;

[0024] Figure 6 A schematic block diagram illustrating an embodiment of the contents of a registration request message according to some embodiments described herein;

[0025] Figure 7 A schematic block diagram illustrating an embodiment of an access type information element in a registration request message according to some embodiments described herein;

[0026] Figure 8 A schematic block diagram illustrating an embodiment of access type values for an access type information element in a registration request message according to some embodiments described herein;

[0027] Figure 9 A logical flow diagram illustrating an embodiment of a method for registration by a UE through access network type C when reusing an existing NAS security context according to some embodiments described herein;

[0028] Figure 10 A schematic block diagram illustrating an embodiment of a mapping table of service networks and access types to NAS connections after registration with access type A, access type B, and access type C according to some embodiments described herein;

[0029] Figure 11 A logical flow diagram illustrating an embodiment of a method for registration by a UE through access network type C when initiating a new authentication according to some embodiments described herein;

[0030] Figure 12 A schematic block diagram illustrating an embodiment of a mapping table of service networks and access types to NAS connections after registration with access type A, access type B, and access type C according to some embodiments described herein;

[0031] Figure 13A logical flow diagram illustrating an embodiment of a method of registration by a UE over an access network type A when a service network authorization failure has occurred, is illustrated in accordance with some embodiments described herein;

[0032] Figure 14 A schematic block diagram illustrating an embodiment of a 5GMM cause information element is illustrated in accordance with some embodiments described herein;

[0033] Figure 15 A schematic block diagram illustrating an embodiment of a cause value of a 5GMM cause information element is illustrated in accordance with some embodiments described herein;

[0034] Figure 16 A schematic block diagram illustrating an embodiment of a new information field for enabling different Subscription Concealed Identifier (SUCI) structures for SUCI is illustrated in accordance with some embodiments described herein;

[0035] Figure 17 A schematic block diagram illustrating an embodiment of the identity types supported by a new information field for Subscription Concealed Identifier (SUCI) is illustrated in accordance with some embodiments described herein;

[0036] Figure 18 A schematic block diagram illustrating an embodiment of a generic SUCI subscriber identity format is illustrated in accordance with some embodiments described herein;

[0037] Figure 19 A schematic block diagram illustrating an embodiment of a SUCI subscriber identity format when the SUPI format is IMSI or IMSI-based NAI is illustrated in accordance with some embodiments described herein;

[0038] Figure 20 A schematic block diagram illustrating an embodiment of a SUCI subscriber identity format when the SUPI format is non-IMSI-based NAI and the identity type is “SUCI” is illustrated in accordance with some embodiments described herein;

[0039] Figure 21 A schematic block diagram illustrating an embodiment of a SUCI subscriber identity format when the SUPI format is non-IMSI-based NAI and the NTI is assigned a reserved global PLMN ID is illustrated in accordance with some embodiments described herein;

[0040] Figure 22 A schematic block diagram illustrating an embodiment of a SUCI subscriber identity format when the identity type is “SUCI” and the SUPI format is “MF-NAI” is illustrated in accordance with some embodiments described herein;

[0041] Figure 23A schematic block diagram illustrating an embodiment of a SUCI identity type according to some embodiments described herein;

[0042] Figure 24 A schematic block diagram illustrating an embodiment of an example user equipment according to some embodiments described herein;

[0043] Figure 25 A schematic block diagram illustrating an embodiment of an example AMF node according to some embodiments described herein; and

[0044] Figure 26 A schematic block diagram illustrating an embodiment of an example N3IWF according to some embodiments described herein. DETAILED DESCRIPTION

[0045] The description and drawings merely illustrate the principles of the various embodiments. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the disclosure and fall within its spirit and scope. Furthermore, all examples recited herein are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the embodiments and the concepts contributed by the inventor(s) to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the disclosure, as well as specific examples thereof, are intended to encompass equivalents thereof.

[0046] For convenience, certain abbreviations are set forth below:

[0047] 5GC 5G core

[0048] 5GS 5G system

[0049] 5G-AN 5G access network

[0050] 5G-GUTI 5G globally unique temporary identifier

[0051] 5G-S-TMSI 5G S temporary mobile subscription identifier

[0052] 5QI 5G QoS identifier

[0053] AKA authentication and key agreement

[0054] AMF core access and mobility management function

[0055] AUSF authentication server function

[0056] EAP extensible authentication protocol

[0057] HPLMN Home Public Land Mobile Network

[0058] IKEv2 Internet Key Exchange version 2

[0059] IMSI International Mobile Subscriber Identity

[0060] IMEI International Mobile Equipment Identity

[0061] IPsec Internet Protocol Security

[0062] MCC Mobile Country Code

[0063] MCM Multi-Connectivity Mode

[0064] MNC Mobile Network Code

[0065] N3IWF Non-3GPP Interworking Function

[0066] NAI Network Access Identifier

[0067] NAS Non-Access Stratum

[0068] ngKSI Key Set Identifier in 5G System

[0069] NHN-ID Neutral Host Network ID

[0070] PDN Packet Data Network

[0071] PLMN Public Land Mobile Network

[0072] QoS Quality of Service

[0073] SA Security Association

[0074] SCM Single-Connectivity Mode

[0075] SMC Security Mode Command

[0076] SUCI Subscription Concealed Identifier

[0077] SUPI Subscription Permanent Identifier

[0078] UDM Unified Data Management

[0079] UE User Equipment

[0080] UICC Universal Integrated Circuit Card

[0081] USIM UMTS Subscriber Identity Mobile

[0082] One or more embodiments providing systems and methods for providing network services to unauthenticated user equipment are described herein. For example, various methods for unauthenticated UE session establishment in non-3GPP access networks are described.

[0083] Figure 1 A schematic block diagram illustrating an embodiment of a type of access network for an Evolved Packet Core that is fully or partially compliant with a set of Third Generation Partnership Project (3GPP) standards or other types of Internet Protocol (IP) data packet core network standards is shown. This architecture is described in more detail in technical standard 3GPP TS 23.402 V14.2.0, entitled "Third Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for Non-3GPP Access," dated December 2016, which is incorporated herein by reference.

[0084] In the 3GPP architecture, the EPC network 100 is communicatively coupled to one or more access networks 102. In embodiments, the access networks 102 can include one or more 3GPP access networks 104 or one or more non-3GPP access networks 106. The 3GPP access networks 104 are fully or partially compliant with technologies specified by the set of 3GPP standards and include, for example, GPRS, UMTS, EDGE, HSPA, LTE, and LTE-Advanced. The non-3GPP access networks 106 are fully or partially compliant with technologies not specified by the set of 3GPP standards. The non-3GPP access networks 106 can also be specified in the set of 3GPP standards. The non-3GPP access networks 106 can include one or more trusted non-3GPP access networks 108 or one or more untrusted non-3GPP access networks 110.

[0085] The trusted non-3GPP access networks 108 are operator-built or operator-supported wireless local area networks (WLANs), such as IEEE 802.1 lx compliant WLAN networks with encryption and security authentication methods. In one embodiment, the trusted non-3GPP access networks 108 support the following example features: 802. lx based authentication, which in turn requires encryption to the radio access network (RAN); 3GPP based network access using EAP methods for authentication; and IPv4 and / or IPv6 protocols. However, the operator can determine that other types of non-3GPP access networks with different types of security will be considered trusted. The untrusted non-3GPP access networks 110 include non-3GPP access networks that are not known or do not include supported authentication standards by the operator. For example, the untrusted non-3GPP access networks can include home or public WLANs, such as IEEE 802.1 lx compliant WLAN networks that are publicly, home, or another origin and managed non-operator open.

[0086] Another set of protocols for the fifth generation wireless, or 5G, is the latest version of cellular technology, designed to offer improved speed and responsiveness of wireless networks. The term 5G was initially defined by the ITU IMT-2020 standard, which calls for a theoretical peak download speed of 20 gigabits. More recently, the industry standards organization 3GPP is defining the 5G architecture and protocols. For example, Technical Specification (TS) 23.501 defines the second stage system architecture for the 5G system, including network slicing. Technical Specification (TS) 23.502 defines the procedures for the 5G system. Technical Specification (TS) 23.503 defines the policy and charging control framework for the 5G system.

[0087] In a 5G system, a 5G access network can include, for example, a Next Generation (NG) Radio Access Network (NG-RAN) as described in 3GPP TS 38.300. In addition, a 5G access network can include untrusted non-3GPP access networks, in which a UE can connect to a 5G core network, for example, via a secure IPSec / IKE tunnel terminated over a non-3GPP interworking function (N3IWF). The non-3GPP access network (N3AN) is considered a 5G access network and is considered part of the 5G system (5GS).

[0088] For untrusted non-3GPP access, an access node including N3IWF provides termination of N2 and N3 signaling interfaces for the control plane and user plane, respectively. A UE with 5G capabilities accesses the 5G core network by connecting to a non-3GPP access network (as a 5G access network) via N3IWF. The N3IWF relays uplink and downlink control plane NAS (N1) signaling between the UE and the 5G core network, making it possible for the UE to have a direct NAS signaling connection to the core network. In addition, the N3IWF provides a user plane connection between the UE and the core network for PDU sessions over the non-3GPP access network.

[0089] Figure 2 A schematic block diagram illustrating an embodiment of a 5G system architecture for non-3GPP access is shown. This architecture is described in more detail in Technical Standard 3GPP TS 23.501 (Release 15), entitled "System Architecture for the 5G System," dated December 2017, which is incorporated by reference herein.

[0090] A non-3GPP access network connects to the 5G core network through a non-3GPP interworking function (N3IWF). The N3IWF interfaces the 5G core network control plane (CP) and user plane (UP) functions via the N2 and N3 interfaces, respectively. A UE establishes an IPSec tunnel with the N3IWF to attach to the 5G core network through an untrusted non-3GPP access network. The UE is authenticated by the 5G core network during the IPSec tunnel establishment procedure and attaches to the 5G core network. Further details of UE attachment to the 5G core network through an untrusted non-3GPP access are described in 3GPP TS 23.502 (Release 15), Procedures for the 5G System, December 2017, which is incorporated herein by reference.

[0091] A 5G system includes a home public land mobile network or equivalent local PLMN (HPLMN-5G) that includes an access and mobility management function (AMF). The AMF provides termination of RAN control plane interface (N2) and termination of the NAS (N1) protocol set, as well as NAS ciphering and integrity protection. The AMF also provides registration and connection management. The AMF can include various functions to support non-3GPP access networks. For example, the AMF can provide support for N2 interface control protocols through the N3IWF and support for NAS signaling with UEs through the N3IWF. In addition, the AMF can provide support for authentication of UEs connected through the N3IWF and mobility management, authentication, and separate security context state for UEs connected via non-3GPP access or simultaneously via 3GPP and non-3GPP access.

[0092] A session management function (SMF) includes session management functionality, such as session establishment, modification, and release, including tunnel maintenance between UPF and AN node. The SMF also provides UE IP address allocation and management (including optional authorization) and DHCPv4 (server and client) and DHCPv6 (server and client) functionality.

[0093] A user plane function (UPF) provides external PDU session interworking point to data networks and packet routing and forwarding. The UPF also supports user plane part of policy rule enforcement, such as gating, redirection, traffic steering, etc.

[0094] A Policy Control Function (PCF) supports a unified policy framework to govern network behavior. A Unified Data Management (UDM) includes support for generating 3GPP AKA authentication credentials, access authorization based on subscription data (e.g., roaming restrictions), and management of registration of service NFs for a UE (e.g., storing a service AMF for a UE, storing a service SMF for a PDU session of a UE). The UDM also provides SMS and subscription management. To provide this functionality, the UDM uses subscription data (including authentication data) that can be stored in a UDR. An AUSF provides authentication server functionality (AUSF).

[0095] In the case of untrusted non-3GPP access, the functionality of the N3IWF includes support for IPsec tunnel establishment with the UE. The N3IWF 204 terminates the IKEv2 / IPsec protocol with the UE 200 over the NWu interface and relays information needed to authenticate the UE 200 and authorize its access to the 5G core network over the N2 interface. The N3IWF provides termination of the N2 and N3 interfaces for the control plane and user plane, respectively, for the 5G core network. The N3IWF relays uplink and downlink control plane NAS (N1) signaling between the UE and the AMF. The N3IWF provides handling of N2 signaling related to PDU sessions and QoS from the SMF (relayed by the AMF). The N3IWF also provides establishment of IPsec security associations (IPsec SAs) to support PDU session traffic. The N3IWF also provides relaying of uplink and downlink user plane packets between the UE and the UPF.

[0096] Figure 3 A schematic block diagram illustrating an embodiment of a UE accessing a 5G system through multiple heterogeneous access networks is shown. The multiple heterogeneous access networks include, for example, 3GPP access, untrusted WLAN access, and non-3GPP access. When the UE is registered to the 5G core through both a 3GPP access network and a non-3GPP access network, multiple control plane NAS signaling connections are simultaneously active between the UE and the AMF.

[0097] When the UE establishes a secure connection, it sends a "Registration Request" message to the AMF / SEAF. The registration request message includes a 5GS mobile identity IE containing SUCI, 5G-GUTI or IMEI. After receiving the registration request message from the UE, the AMF / SEAF prepares an "Authentication Initiation Request" (5G-AIR) message to the AUSF. The SEAF also includes the service network name into the 5G-AIR message. After receiving the 5G-AIR message from the SEAF, the AUSF prepares an "Auth-Info-Req" message and sends to the UDM / ARPF. The UDM / ARPF first generates an authentication vector with the authentication management field (AMF) separate bit = 1. The UDM / ARPF then calculates CK' and IK'. After that, the ARPF sends (RAND, AUTN, XRES, CK', IK') to the AUSF using the Auth-Info-Rsp message. The AUSF responds to the SEAF by sending a 5G-AIA message, which in turn includes an EAP Request / AKA' challenge message. The SEAF forwards the EAP Request / AKA' challenge message to the UE in a NAS message Auth-Req message transparently. After receiving the response to the Auth-Req message from the UE, the SEAF forwards the EAP response to the AUSF, and the AUSF verifies the response with the stored information. If the verification is successful, the AUSF sends an EAP-SUCCESS and anchor keys to the SEAF, which in turn responds to the UE with the EAP-SUCCESS. If the AUSF receives a SUCI from the SEAF when initiating authentication, the AUSF also includes the SUPI while sending the EAP-SUCCESS message.

[0098] If the UE is accessing one PLMN through one type of access (e.g. 3GPP access) and another PLMN through another type of access (e.g. non-3GPP access), different primary authentication is performed. After registration, the NAS connections are served by different AMFs with different security contexts. However, as shown, the UE can request registration in the same service network (e.g. the same HPLMN-5G) through different types of access. All NAS connections of the UE are then served by the same AMF. Figure 3

[0099] ​Currently, the assignment of the NAS connection identifier is hardcoded when a UE is registered in a serving network over different types of accesses. For example, 3GPP TSG#80 Plenary approved the completion of the standalone (SA) Release 15 (REL-15) of the 5G specification, which was published on July 15, 2018 and is incorporated herein by reference. In REL-15, for 3GPP access, the NAS connection identifier is assumed to be “0”. For non-3GPP access, the NAS connection identifier is assumed to be “1”. This assignment of hardcoded connection identifiers did not exhibit problems in Rel-15, since only one type of non-3GPP access was supported, e.g. untrusted WLAN access. However, it is foreseen that additional non-3GPP access network types will be added in future releases, e.g. trusted WLAN access, wired access, MuLteFire access, etc. Each of the different types of non-3GPP access network needs to establish a separate NAS connection. Depending on the network configuration and UE service subscription, a UE can be simultaneously connected to multiple access networks, e.g. as shown in Figure 2

[0100] In addition, different access types can be activated in different order. For example, it is possible that a UE receives authentication first over one of the non-3GPP access networks and establishes the NAS security context before the UE registers via the 3GPP access network. In another possibility, the UE registers via multiple non-3GPP access networks instead of over the 3GPP access network. Therefore, a more flexible binding between the serving network and the access type to the NAS connection is needed.

[0101] In order for a UE to verify that it has connected to a serving network that is authorized to provide services to the UE, the serving network needs to be verified by the home network in the authentication (AKA) procedure. The verification is implicit, since it is assumed that the serving network is authorized if the basic authentication and key agreement procedure has been successfully completed. However, the failure cases should not be implicit and need to be explicitly defined.

[0102] ​Finally, in 5G systems, the subscriber identifier is referred to as the Subscription Permanent Identifier (SUPI). The SUPI can be defined in IMSI or NAI format. To ensure subscriber privacy, the SUPI shall not be transmitted in clear over the 5G RAN and is wirelessly concealed by using a Subscription Concealed Identifier (SUCI). The SUCI is generated using a protection scheme with a raw public key that has been securely provisioned in control of the home network. Only the subscription identifier part of the SUPI is concealed, while the home network identifier part of the SUPI needs to remain clear for routing purposes.

[0103] For different access network types, the routing information can not be the same. For 3GPP access networks, the Mobile Country Code (MCC) and the Mobile Network Code (MNC) can be part of the routing information. However, for non-3GPP access networks, different network identifiers and routing information can be used. For example, for MuLteFire type of access networks, the network identifier and routing information is based on the Neutral Host Network-ID (NHN-ID), the Participating Service Provider-ID (PSP-ID), and the Neutral Host Access Mode Indicator (NHAMI). The NHAMI is a reserved global value that is the same for all MuLteFire networks that enable the NHN access mode. The encoding of the SUCI information element needs to be defined in a generic way to enable SUCI to support other types of network and subscriber identifier formats as mobile identities in the authentication procedure.

[0104] It is also assumed that both IMSI and NAI formats can be used for the SUPI, and for the SUCI mode output, if the subscription identifier is in IMSI format, the MSIN corresponds to the representation, and if the subscription identifier is in NAI format, the username corresponds to the representation. For IMSI based NAI, the user identifier part of the NAI is also composed of digits, so additional encoding rules are needed to distinguish between the IMCI format, the NAI format, and possibly other types of subscriber identifier formats in the SUCI information element definition.

[0105] One or more embodiments described herein provide systems and methods for enabling concurrent secure connectivity over multiple heterogeneous access networks. New methods and protocol enhancements are described to allow a UE to include the access type during registration and to track concurrent NAS connections mapped over heterogeneous access networks. New systems and methods are also described for handling service network authentication failures. New systems and methods and protocol enhancements are further described to support the use of NAI as one type of subscription identifier, and future extensibility of the subscription identifier to support MuLteFire access networks and private networks.

[0106] 1. Embodiment - UE includes access type during registration and capability to track concurrent NAS connections mapped through heterogeneous access networks

[0107] a) The UE initiates initial registration through access type A.

[0108] Figure 4 A logical flow diagram illustrating an embodiment of a method for authentication and key agreement message flow between a UE and core network functions when the UE initiates initial registration through access network type A. The NAS messages shown between the UE and the AMF can be tunneled via an IPsec tunnel in case access network type A is untrusted non-3GPP access. For example, by initiating an Internet Key Exchange (IKE) protocol initial exchange (e.g., as described in IETF RFC 7296, “Internet Key Exchange Protocol Version 2 (IKEv2”) (October 2014), the UE can establish an IPsec Security Association (SA) with the selected N3IWF. In this example, access network type A is a first type of network among multiple types of networks, including 3GPP access, trusted non-3GPP access, untrusted non-3GPP access, untrusted WLAN access, trusted WLAN access, MuLteFire access, etc.

[0109] When the UE initiates initial registration through access network type A, the UE includes the access type in the registration request message. The UE sends the registration request message to the AMF. The AMF is collocated with a Security Anchor Function (SEAF), which acts as an anchor for security in the 5G system. Upon receiving the registration request message, the AMF / SEAF initiates authentication by sending a Nausf_UEAuthentication_Authenticate request message to the AUSF to initiate the Nausf_UEAuthentication service. The SEAF includes the subscription ID, the service network name, and the access type in the Nausf_UEAuthentication_Authenticate request.

[0110] Upon receiving the Nausf_UEAuthentication_Authenticate request message, the AUSF compares the received service network name with the expected service network name. If the requesting SEAF in the service network is authorized to use the service network name, the AUSF sends a Nudm_UEAuthentication_Get request to the UDM, which includes the subscription ID, the service network name, and the access type.

[0111] Upon receiving the Nudm_UEAuthentication_Get request, the UDM / ARPF selects an authentication method based on the subscription data. By way of example, the EAP-AKA' mutual authentication type protocol modified herein (e.g., EAP-AKA' described in IETF RFC 5448, “Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA’), dated March 5, 2018, and incorporated herein by reference) can be performed between the UE and the AUSF.

[0112] The UDM / ARPF generates an authentication vector and sends this authentication vector AV’ (RAND, AUTN, XRES, CK’, IK’) to the AUSF from which the Nudm_UEAuthentication_Get request was received. The UDM / ARPF also transmits an indication that the authentication vector AV’ will be used for EAP-AKA’ using the Nudm_UEAuthentication_Get response message.

[0113] The AUSF and the UE then proceed with the EAP Request / AKA’ Challenge exchange. The AUSF derives the KAUSF and KSEAF keys and includes the EAP Success message and KSEAF in the Nausf_UEAuthentication_Authenticate response message and sends the response message to the AMF / SEAF.

[0114] Upon receiving the Nausf_UEAuthentication_Authenticate response message, the AMF / SEAF derives the KAMF key. The AMF then initiates a security mode command procedure to send the security context and security algorithm information to the UE. The UE receives the security mode command and derives the NAS security context and sends a security mode command complete message to the AMF.

[0115] Upon completion of the procedure, the mapping table of service networks and access types to NAS connections is updated to include the connection information for access network type A, as shown in the following table. Figure 5

[0116] Figure 5 ​A schematic block diagram illustrating an embodiment of a mapping table of service networks and access types to NAS connections. In this example, the mapping table is updated to include connection information for a first type of access network, e.g. access network type A. The mapping table is updated after the UE registers through the access network. The table includes an access network type, a network identifier, and an access network identifier. The mapping table also includes a NAS connection identifier for a NAS connection between the access network type A and the UE. Thus, the mapping table stores a NAS connection identifier, an access network type, a network identifier, and an access network identifier for each NAS connection.

[0117] Figure 6 A schematic block diagram illustrating an embodiment of the content of a registration request message. The UE sends a registration request message to an AMF through an access network to start an initial registration. The registration request message includes an information element "Access Type" of the access network. The purpose of the Access Type information element is to indicate the access type used to send downlink signaling or user data to the UE.

[0118] Figure 7 A schematic block diagram illustrating an embodiment of the Access Type information element in a registration request message. The Access Type is a type 1 information element.

[0119] Figure 8 A schematic block diagram illustrating an embodiment of the Access Type values of the Access Type information element in a registration request message. In an embodiment, the Access Type includes 3GPP access, untrusted non-3GPP access, trusted non-3GPP access, untrusted WLAN access, trusted WLAN access, and MuLteFire access. Alternative or additional access types can be included in the Access Type information element in the registration message.

[0120] b1) The UE initiates a subsequent registration through access type C and reuses the existing NAS security context

[0121] When the UE initiates a subsequent registration through another type of access network, e.g. access type C, and the UE has already been authenticated through the network and is served by the same AMF in the same service network, the AMF can decide not to run a new authentication of whether it has a usable security context for use.

[0122] Figure 9 A logic flow diagram illustrating an embodiment of a method of registration by a UE through an access network type C while reusing an existing NAS security context. In this example, it is assumed that the UE has established NAS connections with access network type A and access network type B. Note that if the access network type C is untrusted non-3GPP access, the NAS messages shown between the UE and the AMF will be tunneled via an IPsec tunnel.

[0123] When the UE initiates a subsequent registration over another access network with access network type C, the UE includes the access type in the registration request message. The AMF can decide to reuse the existing security context. A new NAS connection is created using the available generic 5G NAS security context. The NAS security context is updated with parameters specific to the new NAS connection. At the completion of the procedure, the mapping table of service network and access type to NAS connection is updated to include the connection information for access network C as shown. Figure 10

[0124] Figure 10 A schematic block diagram illustrating an embodiment of a mapping table of service network and access type to NAS connection after registration with access type A, access type B, and access type C. In this example, the mapping table is updated to include connection information for access type C. The mapping table is updated after the UE registers over an access network. The table includes the access network type, network identifier, and access network identifier. The mapping table also includes a NAS connection identifier for the NAS connection between access network type C and the UE. The NAS connection identifier is "2". The mapping table can be stored in the UE and AMF and / or at other functions or nodes such as the AUSF.

[0125] b2) The UE initiates a subsequent registration over access network type C and initiates a new authentication

[0126] When the UE initiates a subsequent registration over access type C, the AMF can decide to run the authentication and key agreement procedure again if the UE has been network authenticated by the same service network, because the UE is served by a different AMF or due to the security algorithms have changed.

[0127] Figure 11 is a logical flow diagram of an embodiment of a method for registration by a UE over access network type C when initiating a new authentication. In this example, it is assumed that the UE has established NAS connections with access network type A and access network type B. Note that if access network type C is untrusted non-3GPP access, the NAS messages shown between the UE and the AMF will be tunneled via an IPsec tunnel.

[0128] ​When the UE initiates a subsequent registration over access network type C, the UE includes the access type in the registration request message. The AMF decides to run the authentication and key agreement procedure again. The AMF can decide to run the authentication and key agreement procedure again because the UE is served by a different AMF or because the security algorithm has changed. When the authentication and key agreement procedure is completed, the AMF initiates a new NAS security mode command to the UE to activate a new derived 5G NAS security context for access type C.

[0129] A new NAS connection is created using the new derived 5G NAS security context. The NAS security context is updated with parameters specific to the new NAS connection. The AMF then triggers additional NAS SMC procedures for all other access types in order to activate a new 5G NAS security context for each existing access type. Upon successful NAS SMC procedure over other access types, both the UE and the AMF will delete the old NAS security context. Upon completion of the procedures, the mapping table of serving network and access type to NAS connection is updated to include the connection information for access network type C as shown in Figure 12

[0130] Figure 12 A schematic block diagram illustrating an embodiment of a mapping table of serving network and access type to NAS connection after registration with access type A, access type B, and access type C. In this example, the mapping table is updated to include connection information for access type C. The mapping table is updated after the UE registers over an access network. The table includes an access network type, a network identifier, and an access network identifier. The mapping table also includes a NAS connection identifier for the NAS connection between access network type C and the UE. The NAS connection identifier is "2". The mapping table can be stored in the UE and the AMF and / or at other functions or nodes such as the AUSF.

[0131] 2. Embodiment - Serving network authorization failure

[0132] In order for the UE to verify that it is connected to a serving network that is authorized to provide services to the UE, the serving network needs to be verified by the local network in the AKA procedure. If the serving network is authorized, the AKA procedure will continue and if the primary authentication and key agreement procedure has been successfully completed, it means that the serving network is authorized.

[0133] However, if the serving network is not authorized, the authentication procedure will stop and the AUSF will send an authentication response to the AMF to indicate that the authentication failed due to the serving network not being authorized.

[0134] Figure 13 ​A logic flow diagram illustrating an embodiment of a method for registration by a UE over an access network type A when a service network authorization failure has occurred. Note that if the access network type A is an untrusted non-3GPP access, the NAS messages between the UE and the AMF will be tunneled via an IPsec tunnel.

[0135] Upon receiving the Nausf_UEAuthentication_Authenticate request message, the AUSF compares the received service network name with the expected service network name. If the requesting SEAF in the service network is not authorized to use the service network name, the AUSF responds with “service network not authorized” in the Nausf_UEAuthentication_Authenticate response.

[0136] The service network authorization failure is different from other PLMN related failures. It is not a failure due to UE subscription or access restrictions (e.g. due to operator barring), but a failure due to security verification / authorization of the service network. Currently, there is no cause code for such a failure case.

[0137] One failure code related to PLMN failures is “PLMN not allowed”, but the failure represents a rejection to the UE due to subscription or operator determined restrictions. This failure code is: Cause #11 - PLMN not allowed. This 5GMM cause is sent to the UE if the UE requests a service or the network initiates a deregistration request in a PLMN that is not allowed to operate the UE by subscription or due to operator determined barring.

[0138] When the UE receives a rejection due to “PLMN not allowed”, the UE needs to set the 5GS update status to “5U3 ROAMING NOT ALLOWED”, reset the registration attempt counter, delete its security context, any 5G-GUTI, last visited registered TAI, TAI list, ngKSI, list of equivalent PLMNs, and also store the PLMN identity in the “barred PLMN list”.

[0139] However, when a service network authorization failure occurs, the UE does not need to reset its update status to 5U3 ROAMING NOT ALLOWED, assuming the failure is not a failure related to UE subscription or access restrictions, and can immediately attempt to select another PLMN. Therefore, it is more appropriate to define a new cause code for this different case, as the UE can take different actions.

[0140] For example, when a service network authorization failure occurs, the UE can abort the initial registration procedure towards the PLMN, store the PLMN identity in the "Forbidden PLMN list", set the 5GS update status to 5U2 NOT UPDATED, and enter the state 5GMM-DEREGISTERED.PLMN-SEARCH in order to perform PLMN selection. Therefore, a new 5GMM reject cause is needed to indicate "service network not authorized".

[0141] Figure 14 A schematic block diagram illustrating an embodiment of the 5GMM cause information element is shown. The 5GMM cause information element indicates the reason for which the network rejects a 5GMM request from the UE. A new 5GMM reject cause is included in this information element to indicate "service network not authorized". For example, the new reject can be included as a new cause code #73 to signal to the UE that the service network authorization failure. The new cause code is used if the authentication procedure cannot continue because the service network is not authorized.

[0142] Figure 15 A schematic block diagram illustrating an embodiment of the cause values of the 5GMM cause information element is shown. The cause values are updated to include the new cause #73 - service network not authorized. This 5GMM cause is sent to the UE if the UE initiates registration to the service network and the service network authorization failure.

[0143] After authentication failure at the service network, the UE receives a registration reject for 3GPP access with the 5GMM cause "service network not authorized". The UE then aborts the initial registration procedure, stores the PLMN identity in the "Forbidden PLMN list", sets the 5GS update status to 5U2 NOT UPDATED, and enters the state 5GMM-DEREGISTERED.PLMN-SEARCH in order to perform PLMN selection. The UE can therefore select another PLMN.

[0144] 3. Embodiment - Method and protocol enhancements to support the use of NAI as one type of subscription identifier and support future extensibility of the subscription identifier to support MuLteFire and private networks

[0145] a) Define a new field "SUPI Format" to enable different subscriber identity types / formats to be used as the subscriber identifier

[0146] A globally unique 5G subscription permanent identifier (SUPI) is assigned to each user in the 5G system and is provided in the UDM / UDR. The SUPI is used only within the 3GPP system and its privacy is specified in 3GPP TS 33.501, Security architecture and procedures for the 5G system, Release 15, dated March 26, 2018, incorporated herein by reference. The following have been identified as valid SUPI types: IMSI and NAI.

[0147] A SUCI is a partially encrypted SUPI used in procedures associated with the 5G system when the device has not been assigned a 5G-GUTI (5G globally unique temporary identity). The SUCI is typically created by encrypting the MSIN (mobile subscriber identification number) component of the subscriber's IMSI.

[0148] The UE uses the raw public key that is securely provisioned in control of the home network to produce the SUCI. The protection scheme uses the raw public key of the home network. The UE constructs the scheme input (e.g., applies some padding scheme) from the subscription identifier part of the SUPI as specified by the protection scheme. The UE then executes the protection scheme with the constructed scheme input as input and the output as the scheme output. The UE does not conceal the home network identifier, e.g., the mobile country code (MCC) or the mobile network code (MNC). The UE then produces the SUCI that includes the home network identifier, the identifier of the home network public key, and the scheme output.

[0149] However, assuming that both IMSI and NAI formats can be used for SUPI, for the SUCI mode output, if the subscription identifier is in IMSI format, the MSIN corresponds to the representation, and if the subscription identifier is in NAI format, the username corresponds to the representation. For IMSI-based NAI, the subscriber identifier part of the NAI is also composed of digits, so additional encoding rules are needed to distinguish between the IMCI format, the NAI format, and possible other types of subscriber identifier formats in the SUCI information element definition.

[0150] Figure 16A schematic block diagram illustrating an embodiment of new information fields for enabling different SUCI structures for a Subscription Concealed Identifier (SUCI). Using the new information fields, the mobile identity format of the SUPI and SUCI can be customized based on the SUPI identity type / format used. For example, for IMSI, the network identifier is based on MNC / MCC. For IMSI-based NAI, the network identifier is also based on MNC / MCC. For non-IMSI-based NAI, the network identifier is based on a generic network type indicator and an operator or enterprise specific network identifier, where the network type indicator can be based on a special reserved / hard-coded global MCC / MNC value. For MuLteFire NAI (MF-NAI), the network identifier is based on a special reserved / hard-coded global MCC / MNC, a neutral host network ID (NHN-ID), and a participating service provider ID (PSP-ID).

[0151] Figure 17 A schematic block diagram illustrating an embodiment of identity types supported by new information fields for a Subscription Concealed Identifier (SUCI). The new SUCI information fields enable different identity types to be used for the subscriber identifier. The identity types can include SUCI, 5G-GUTI, IMEI, 5G-S-TMSI, IMEISV, MAC address, or device identity. The device identity can include, for example, UDI, ODIN, Bluetooth id, serial number, etc. Alternative or additional identity types can also be defined.

[0152] Figure 18 A schematic block diagram illustrating an embodiment of a generic SUCI subscriber identity format. The SUCI subscriber identity structure includes a network type indicator (NTI). The local network identifier and routing identifier can be different for different access network types. The scheme output field contains the concealed subscriber identifier generated using a protection scheme.

[0153] Figure 19 A schematic block diagram illustrating an embodiment of a SUCI subscriber identity format when the SUPI format is IMSI or IMSI-based NAI. This illustrates the 5GS mobile identity information element format when the identity type is “SUCI” and the SUPI format is “IMSI” or “IMSI-based NAI”. For 3GPP access networks, the local network identifier contains the PLMN ID (MCC and MNC). The mobile country code (MCC) and mobile network code (MNC) can be part of the routing information.

[0154] Figure 20A diagram illustrates a schematic block diagram of an embodiment of SUCI subscriber identity format when the SUPI format is non-IMSI based NAI and the identity type is "SUCI". This illustrates an example of 5GS mobile identity information element format when the identity type is "SUCI" and the SUPI format is "non-IMSI based NAI". The network identifier and routing information are network specific. The value in the network type indicator (NTI) field is used to indicate the type of network.

[0155] Figure 21 A diagram illustrates a schematic block diagram of an embodiment of SUCI subscriber identity format when the SUPI format is non-IMSI based NAI and the NTI is assigned a reserved global PLMN ID. The network type indicator can be a reserved global value in the PLMN ID (MCC / MNC) when the SUPI format is "non-IMSI based NAI".

[0156] Figure 22 A diagram illustrates a schematic block diagram of an embodiment of SUCI subscriber identity format when the identity type is "SUCI" and the SUPI format is "MF-NAI". For MuLteFire networks, the network identifier and routing information are based on the neutral host network ID (NHN-ID), participating service provider ID (PSP-ID), and neutral host access mode indicator (NHAMI). The NHAMI is a reserved global value that is the same for all MuLteFire networks that enable NHN access mode.

[0157] Figure 23 A diagram illustrates a schematic block diagram of an embodiment of SUCI identity type. The table illustrates various examples of additional encoding for SUCI identity type.

[0158] Figure 24 A diagram illustrates a schematic block diagram of an embodiment of example user equipment 220. User equipment (UE) 220 can comprise a smartphone, smart tablet, laptop, smartwatch, PC, TV, or other device. Additional or alternative components and functionality can be included within UE 220. Additionally, one or more of the functions and components shown herein can not exist or can be combined with other components or functions.

[0159] The UE 220 includes a processing device 2600 and a memory device 2602 configured to perform one or more of the functions described herein with respect to the UE 220. The memory device 2602 can include a managed object 2604 that stores applications and operating instructions that control the processing device 2600 to perform the various functions described herein. The memory device 2602 can also store a mapping table 2650 of service networks and access types to NAS connections. The UE 220 can also include a UICC 2606 that includes a USIM 2608 for storing an IMSI.

[0160] The UE 220 can further include a Bluetooth transceiver 2610, a WLAN (IEEE 802. l lx compliant) transceiver 2612, a mobile RF (3G / 4G / 5G) transceiver 2614, and a GPS 2616. The WLAN transceiver 2612 can be used as a non-3GPP access interface to a WLAN network. The UE 220 can further include a user interface 2618, an AC adapter 2620, a battery module 2622, a USB transceiver 2624, and an Ethernet port 2628.

[0161] The UE 220 can further include a digital camera 2630, a touch screen controller 2632, a speaker 2634, and a microphone 2636. The UE 220 can also include a power management unit 2638. One or more internal communication buses (not shown) can communicatively couple one or more of the components of the UE 220.

[0162] Figure 25 A schematic block diagram illustrating an embodiment of an example AMF node is shown. The AMF node can be integrated with other nodes in a 5G core network. Additional or alternative components and functionality can be included within the AMF node. In addition, one or more of the functions and components shown herein can be absent or combined with other components or functionality or nodes. The AMF node includes a processing device 2700 and a memory device 2702 configured to perform one or more of the functions described herein. The AMF node can include a network interface 2704 including ports for interfacing with other network nodes in a 5GC network.

[0163] Figure 26A schematic block diagram illustrating an embodiment of an example N3IWF is shown. The N3IWF can be an access point in a wireless local area network, a gateway in a local area network, etc. The N3IWF can be integrated with other nodes in the access network. Additional or alternative components and functionality can be included within the N3IWF. In addition, one or more of the functions and components shown herein can be absent or combined with other components or functions. The N3IWF includes a processing device 2800 and a memory device 2802, which are configured to perform one or more of the functions described herein. The N3IWF can include a first network interface 2804 (e.g., an Ethernet port, an IP port) for interfacing with other network nodes in a 5GC network. The N3IWF can also include one or more other types of interfaces for communicating with UEs, such as a WLAN transceiver 2806 (e.g., of an IEEE 802. lx WLAN type network). The N3IWF can also include a mobile RF transceiver 2808 that is compliant with a cellular air interface. The UE 220 can communicate with the N3IWF using one or more of the WLAN transceiver 2806 or the mobile RF transceiver 2808.

[0164] A processing device as described herein includes at least one processing device, such as a microprocessor, microcontroller, digital signal processor, microcomputer, central processing unit, field programmable gate array, programmable logic device, state machine, logic circuitry, analog circuitry, digital circuitry, and / or any device that manipulates signals (analog and / or digital) based on hard coding of the circuitry and / or operational instructions. A memory device is a non-transitory memory device and can be internal or external memory, and the memory can be a single memory device or multiple memory devices. The memory device can be read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, cache memory, and / or any non-transitory memory device that stores digital information. The term “module” is used in the description of one or more of the embodiments herein. A module includes one or more processing devices and / or one or more non-transitory memory devices, which are operable to perform one or more functions as can be described herein. A module can operate independently and / or in conjunction with other modules, and can utilize processing devices and / or memory of other modules and / or operational instructions of other modules. As also used herein, a module can contain one or more sub-modules, each of which can be one or more modules.

[0165] As can be used herein, the term "operable to" or "configurable to" indicates that an element includes one or more of circuits, instructions, modules, data, inputs, outputs, and so forth to perform one or more of the corresponding functionality described or necessary to perform the corresponding functionality, and can also include inferred coupling to one or more other items to perform the corresponding functionality described or necessary to perform the corresponding functionality. As can also be used herein, the terms "coupled," "coupled to," "connected to," and / or "connected" or "interconnected" include direct connection or linkage between nodes / devices and / or indirect connection between nodes / devices via intervening items (for example, items including, but not limited to, components, elements, circuits, modules, nodes, devices, network elements, and so forth) in the same manner as "connected to" or "connected."

[0166] Note that aspects of the present disclosure can be described as processes depicted as flow charts, structural diagrams, or block diagrams. Although the processes can be described in a sequential order, many of the operations can be performed in parallel, or concurrently, or in any suitable order. Additionally, the order of the operations can be re-arranged. A process will terminate when its operations are completed. A process can correspond in some aspects to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, termination of the process corresponds to return of the function to the calling function or main function.

[0167] The various features of the present disclosure described herein can be implemented in different systems and devices without departing from the present disclosure. It should be noted that the foregoing aspects of the present disclosure are merely examples and are not to be construed as limiting the present disclosure. The description of aspects of the present disclosure is intended to be illustrative, and not to limit the scope of the claims. As such, the present teachings can be readily applied to other types of devices and the many alternatives, modifications, and variations thereof.

[0168] In the foregoing specification, certain representative aspects of the application are described. However, the application can be practiced without resorting to the details specifically set forth in the foregoing description. The specification and drawings are to be regarded in an illustrative, rather than a restrictive, sense. Modifications are intended in the scope of the present application. Therefore, the scope of the application should be determined not with reference to the description of the examples, but should be given with reference to the appended claims and their legal equivalents. For example, components and / or elements of any of the devices claims can be assembled or otherwise operated in a variety of permutations, and thus the application should not be limited to the specific configurations described herein, but rather the scope of the claims should be given the broadest interpretation under the laws of patenting.

[0169] Moreover, some of the benefits, other advantages, and solutions to problems have been set forth above in the description of particular embodiments; however, any one or more of the benefits, advantages, solutions to problems, or any element of any of the claims can be achieved by a process, method, article, composition, or apparatus other than the particular embodiments described above. Accordingly, the claims should not be construed as limited to any of the particular embodiments set forth above and should be construed to include all possible embodiments and their equivalents that are within the spirit and scope of the claims.

[0170] As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," "contains," "containing," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, composition, or apparatus that comprises, includes, has, contains, or contains one or more elements, does not include an element not expressly recited. Except as specifically stated, the order or sequence of any process or method having the same or similar elements, or to practicing or using the same or similar elements, is not limited to that specifically recited except as specifically stated. No portion of the disclosure of the application can be construed as an admission that the application is not entitled to antedate such disclosure.

[0171] Further, reference to an element in the singular is not intended to mean "one and only one" unless specifically stated, but rather "one or more." Unless specifically stated otherwise, the term "some" refers to one or more. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether these disclosure is explicitly recited in the claims. No claim element is to be construed as a means plus function unless the element is expressly recited using the phrase "means for." The benefits, advantages, and solutions to problems have been described above with regard to particular embodiments. No element, process, or step in these embodiments is intended to be installed or implemented in a way that is considered by those of ordinary skill in the art to be not normally done. No element, process, or step should be interpreted to be an implied "means-plus-function" or "step-plus-function" clause unless such clause is expressly recited in the claims using the language "means for" or "step for."

Claims

1. A user equipment comprising: a transceiver configured to communicate with one or more types of access networks; a processing device configured to produce a subscription concealed identifier (SUCI) by: determining one of a plurality of subscription permanent identifier (SUPI) formats, wherein the plurality of SUPI formats comprises at least one of: an IMSI, an IMSI-based NAI, a non-IMSI-based NAI, or an MF-NAI; determining a scheme output from a subscriber identifier using a protection scheme; and constructing the SUCI to include the scheme output and a SUPI format field containing a value indicating the determined one of the SUPI formats.

2. The user equipment of claim 1, wherein the subscriber identifier is a SUPI.

3. The user equipment of claim 1, wherein the processing device is configured to produce the SUCI by also determining one of a plurality of types of identification for the subscriber identifier.

4. The user equipment of claim 1, wherein the one of a plurality of types of identification for the subscriber identifier comprises one of: a SUCI, a 5G-GUTI, an IMEI, a 5G-S-TMSI, an IMEISV, a MAC address, or a device identity.

5. The user equipment of claim 1, wherein the user equipment is configured to send the SUCI to an access network as part of a mobile identity information element, wherein the mobile identity information element includes a value indicating that the type of identification is a SUCI.

6. The user equipment of claim 1, wherein the SUCI includes a local network identifier and a routing identifier.

Images