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] This application generally relates to access networks, and more specifically, to session establishment by user equipment over multiple heterogeneous access networks. Background Technology

[0002] The statements in this section provide a description of the prior art, not an admission of it. User equipment (UEs), such as smartphones, tablets, laptops, computers, and smartwatches, typically have both wireless local area network (WLAN) connectivity (e.g., WLAN connectivity compliant with IEEE 802.11x) and radio access network connectivity (e.g., technologies fully or partially compliant with the 3GPP standards set, including EVDO, UMTS, HSPA, and LTE). The UE can therefore connect to the 3GPP Evolved Packet Core (EPC) network using both types of access technologies, consisting of 3GPP and non-3GPP access networks.

[0003] Typically, 3GPP access networks fully or partially comply with technologies specified in the 3GPP standards set, including, for example, GPRS, UMTS, EDGE, HSPA, LTE, and LTE-Advanced. Non-3GPP access networks fully or partially comply with technologies not specified in the 3GPP standards set. These technologies include, for example, cdma2000, WLAN (e.g., WLAN compliant with IEEE 802.11x), or fixed network technologies.

[0004] The 3GPP standards set specifies “non-3GPP” access technologies with different security mechanisms: untrusted access networks and trusted access networks. Untrusted access networks include those that may pose higher security risks (e.g., public WLANs or femtocell access networks). Trusted access networks include those that network operators have a trust level for from a security perspective and can directly interface with EPC networks.

[0005] One of the most important features of 5G systems in the new 5G standards set is the provision of an access-agnostic converged core network. This allows for support of different access network types, including 3GPP and non-3GPP access networks, via public access network and core network interfaces. Non-3GPP access networks (N3AN) are considered 5G access networks and are considered part of the 5G system (5GS).

[0006] For untrusted non-3GPP access, similar to NG-RAN nodes, the N3G access node N3IWF provides termination for signaling interfaces for the control plane and user plane, respectively. Therefore, 5G-enabled UEs can access the 5G core network by connecting to a non-3GPP access network serving as the 5G access network via the N3IWF. The N3IWF relays uplink and downlink control plane signaling between the UE and the AMF, enabling the UE to have a direct control plane signaling connection to the AMF. Additionally, the N3IWF provides a user plane connection between the UE and the UPF for PDU sessions via non-3GPP access networks.

[0007] When a UE registers to the 5G core via both a 3GPP access network and a non-3GPP access network, multiple Non-Access Stratum (NAS) connections can be active simultaneously. The UE can register in the same PLMN or different PLMNs. If a UE is accessing one PLMN via one type of access (e.g., 3GPP access) and another PLMN via another type of access (e.g., non-3GPP access), different primary authentications are performed. After registration, NAS connections can be served by different AMFs utilizing different security contexts. However, if a UE requests registration within the same serving network via different types of access networks, a common 5G NAS security context is created during the registration process using the first access type, 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". Issues arise when adding additional non-3GPP access network types in future discovery releases, such as trusted WLAN access, wired access, and MuLTEFire access. These different types of non-3GPP access networks require establishing separate NAS connections. However, for NAS connections across different types of non-3GPP access networks, there is currently only one NAS connection identifier, "1".

[0009] Therefore, there is a need to provide a system and method that supports NAS connectivity over various types of non-3GPP access networks. The implementation described herein also provides additional requirements and benefits. Summary of the Invention

[0010] This document describes implementation schemes for providing network services to unauthenticated user equipment. For example, various methods are described regarding session establishment for unauthenticated UEs in trusted non-3GPP access networks.

[0011] According to one embodiment, a user equipment is provided, the user equipment comprising: one or more transceivers configured to access a serving network via multiple access network types; a memory device configured to store a mapping table; and a processing means configured to: generate a request to register with the serving network via a first access network, wherein the request includes a first access network type of the first access network; receive a response indicating that a NAS connection establishment is accepted by the serving network, wherein the response includes 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 includes 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 means is further configured to: update the mapping table to include the first access network type, the NAS connection identifier, the access network identifier, and the serving network identifier. In some embodiments, the processing apparatus may further be configured to: generate a second request to register with the serving network through a second access network having a second access network type, wherein the second request includes the second access network type of the second access network; receive a response indicating that a connection establishment is accepted by the serving network, wherein the response includes 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 difference among: 3GPP access, untrusted non-3GPP access, trusted non-3GPP access, untrusted WLAN access, trusted WLAN access, or MuLTEFire access. In some embodiments, the processing apparatus may further be configured to: generate a third request to register with the serving network through a third access network having a third access network type, wherein the third request includes the third access network type of the third access network; receive a response indicating that a connection establishment is accepted by the serving network, wherein the response includes 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 differs from both the first and second access network types, and wherein the third access network type indicates a third distinct item among: 3GPP access, untrusted non-3GPP access, trusted non-3GPP access, untrusted WLAN access, trusted WLAN access, or MuLTEFire access. In some embodiments, the processing apparatus is further configured to use an existing NAS security context established via the first access network with the serving network. In some embodiments, the processing apparatus is further configured to: receive a request to perform authentication on a connection via the third access network; obtain a new NAS security context from the serving network via the third access network; establish a NAS connection via the third access network using the new NAS security context; activate the new NAS security context for both the first and second access networks; 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 serving network via multiple access network types; and a processing means configured to: generate a request to register with the serving network via the access network; and receive a registration rejection message, wherein the registration rejection message indicates that the serving network is not authorized. In some embodiments, the registration rejection message includes a reason information element, wherein the reason information element includes a value corresponding to "the serving network is not authorized". In some embodiments, the processing means is further configured to: abort registration with the serving network; and store the identifier of the serving network in a list of unauthorized serving networks ["a list of prohibited PLMNs"]. In some embodiments, the processing means is further configured to select another serving network for registration.

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

[0014] According to another embodiment, a user equipment may be provided, the user equipment comprising: a transceiver configured to communicate with one or more types of access networks; and a processing means configured to generate a SUCI by: determining one of a plurality of SUPI formats; determining one of a plurality of identifier types for a subscriber identifier; determining a scheme output based on the subscriber identifier using a protection scheme; and constructing the SUCI including a SUPI format value, an identifier value type, and the scheme output. In some embodiments, one of the plurality of identifier types for the subscriber identifier includes one of the following: SUCI, 5G-GUTI, IMEI, 5G-S-TMSI, IMEISV, MAC address, or device identifier. In some embodiments, one of the plurality of SUPI formats includes at least one of the following: IMSI, IMSI-based NAI, non-IMSI-based NAI, or MF-NAI. In some embodiments, the processing means 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 the SUCI structure.

[0015] According to another embodiment, an apparatus may be provided, the apparatus comprising: at least one processor and at least one memory including computer program instructions, the at least one memory and the computer program instructions being configured, together with the at least one processor, to cause the apparatus to at least: generate a request to register with a serving network via an access network; receive a registration rejection message, wherein the registration rejection message indicates that the serving network is not authorized by the apparatus's local network; and, in response to receiving the registration rejection message indicating that the serving network is not authorized by the apparatus's local network, enter a deregistration state, such that the apparatus is configured to request registration with another serving network. In some embodiments, the registration rejection message includes a reason information element, wherein the reason information element includes a value indicating that the serving network is not authorized by the apparatus's local network. In some embodiments, the at least one processor is further configured to: abort registration with the serving network; and store the identifier 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 other serving network for registration. In some embodiments, the registration rejection message indicates that the serving network is not authorized by the apparatus's local network for 3GPP access to the serving network. In some implementations, the at least one processor is further configured to: in response to receiving a registration rejection message indicating that the service network is not authorized by the device's local network, set the fifth-generation system (5GS) update status to 5U2 not updated.

[0016] According to another embodiment, an apparatus may be provided, the apparatus comprising: at least one processor and at least one memory including computer program instructions, the at least one memory and the computer program instructions being configured, together with the at least one processor, to cause the apparatus to at least: receive an authentication request for a user equipment to access a serving network, wherein the authentication request includes an identifier of the serving network and a subscriber identifier; determine whether the serving network is authorized; and, if the serving network is not authorized, generate an authentication response, wherein the authentication response indicates that the serving network is not authorized by a core network associated with the apparatus. In some embodiments, the authentication response includes a cause information element, wherein the cause information element includes a value indicating that the serving network is not authorized by the core network.

[0017] According to another embodiment, an apparatus may be provided, the apparatus comprising: at least one processor and at least one memory including computer program instructions, the at least one memory and the computer program instructions being configured, together with the at least one processor, to cause the apparatus to at least: communicate with a core network via a selected type of access network; and construct a subscription hiding identifier for identifying the apparatus during communication with the core network and the selected type of access network, the subscription hiding 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 the 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 one of the protection schemes pre-configured for the subscription permanent identifier. In some embodiments, the subscription permanent identifier includes one of the following: 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 subscription hiding identifier is transmitted to the core network as a mobile identifier parameter having an identifier type field indicating the subscription hiding identifier identifier type. In some embodiments, the mobile identification parameter includes a fifth-generation system (5GS) mobile identification parameter, and the subscription hidden identifier (SUCI) identifier type includes a SUCI identifier type. In some embodiments, the subscription permanent identifier format type value of the subscription hidden identifier is encoded in the subscription permanent identifier (SUPI) format field of the 5GS mobile identification parameter.

[0018] According to another embodiment, an apparatus may be provided, the apparatus comprising: at least one processor and at least one memory including computer program instructions, the at least one memory and the computer program instructions being configured, together with the at least one processor, to cause the apparatus to at least: receive a subscription hiding identifier from a user equipment via a selected type of access network, the subscription hiding 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 one of the protection schemes pre-configured for the subscription permanent identifier; and, during communication with the user equipment via the selected type of access network, identify the user equipment at least based on the subscription hiding identifier. In some embodiments, the subscription permanent identifier includes one of the following: 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, together with the at least one processor, to cause the device to at least: identify the subscriber identifier format type from an IMSI or network-specific identifier type based at least on the corresponding subscription persistent identifier format type value. In some embodiments, the subscription hidden identifier is received by the device as a mobile identification parameter having an identifier type field indicating the subscription hidden identifier identifier type. In some embodiments, the mobile identification parameter includes a fifth-generation system (5GS) mobile identification parameter, and the subscription hidden identifier (SUCI) identifier type includes a SUCI identifier type. In some embodiments, the subscription persistent identifier format type value of the subscription hidden identifier is encoded in the subscription persistent identifier (SUPI) format field of the 5GS mobile identification parameter. Attached Figure Description

[0019] Figure 1 The following are schematic block diagrams illustrating implementation schemes for types of access networks for evolved packet core networks that are fully or partially compliant with the 3GPP (3rd Generation Partnership Project) standards set or other types of Internet Protocol (IP) data packet core network standards, based on some implementation schemes described herein.

[0020] Figure 2 The following are schematic block diagrams illustrating implementation schemes for 5G system architectures for non-3GPP access, based on some of the implementation schemes described in this article.

[0021] Figure 3 The following is a schematic block diagram illustrating an implementation scheme for a UE to access a 5G system through multiple heterogeneous access networks, based on some implementation schemes described in this article.

[0022] Figure 4 Based on some implementation schemes described in this paper, a logical flowchart of an implementation scheme for an authentication and key negotiation message flow between the UE and core network functions is illustrated.

[0023] Figure 5 The following is a schematic block diagram illustrating an implementation of a mapping table from service network and access type to NAS connection, based on some implementation schemes described in this article.

[0024] Figure 6 The following is a schematic block diagram illustrating an implementation scheme for the content of a registration request message, based on some of the implementation schemes described in this document;

[0025] Figure 7 The following is a schematic block diagram illustrating an implementation scheme for the access type information element in the registration request message, based on some implementation schemes described in this article;

[0026] Figure 8 The following is a schematic block diagram illustrating an implementation scheme for the access type value of the access type information element in the registration request message, based on some implementation schemes described in this article.

[0027] Figure 9 Based on some implementation schemes described in this paper, a logical flowchart of an implementation scheme for a method of UE registration via access network type C when reusing an existing NAS security context is illustrated.

[0028] Figure 10 Based on some implementation schemes described in this article, a schematic block diagram is shown of an implementation scheme for a service network and a mapping table of access types to NAS connections after registration using access type A, access type B, and access type C.

[0029] Figure 11 This is a logic flowchart of an implementation of a method for a UE to register via access network type C when initiating a new authentication, based on some implementation schemes described in this document;

[0030] Figure 12 Based on some implementation schemes described in this article, a schematic block diagram is shown of an implementation scheme for a service network and a mapping table of access types to NAS connections after registration using access type A, access type B, and access type C.

[0031] Figure 13The following is a logical flowchart illustrating an implementation method for a UE to register via access network type A when a service network authorization failure has occurred, based on some implementation schemes described in this article.

[0032] Figure 14 The following is a schematic block diagram illustrating an implementation scheme for the 5GMM cause information element, based on some implementation schemes described in this article;

[0033] Figure 15 Based on some implementation schemes described in this article, a schematic block diagram of the implementation scheme for the cause value of the 5GMM cause information element is shown;

[0034] Figure 16 The following is a schematic block diagram illustrating an implementation scheme for enabling the Subscription Hidden Identifier (SUCI) to enable new information fields with different SUCI structures, based on some implementation schemes described herein.

[0035] Figure 17 Based on some implementation schemes described in this article, schematic block diagrams are shown of implementation schemes for the identifier types supported by the new information field for subscribing to hidden identifiers (SUCI);

[0036] Figure 18 Based on some implementation schemes described in this article, a schematic block diagram of an implementation scheme for the general SUCI subscriber identifier format is illustrated;

[0037] Figure 19 The following are schematic block diagrams illustrating implementations of the SUCI subscriber identifier format when the SUPI format is IMSI or IMSI-based NAI, based on some of the implementations described herein.

[0038] Figure 20 The following is a schematic block diagram illustrating an implementation scheme of the SUCI subscriber identifier format when the SUPI format is a non-IMSI-based NAI and the identifier type is "SUCI" based on some implementation schemes described in this article.

[0039] Figure 21 The following is a schematic block diagram illustrating an implementation of the SUCI subscriber identifier format when the SUPI format is a non-IMSI-based NAI and the NTI is assigned a reserved global PLMN ID, based on some implementations described herein.

[0040] Figure 22 The following is a schematic block diagram illustrating an implementation scheme of the SUCI subscriber identifier format when the identifier type is “SUCI” and the SUPI format is “MF-NAI”, based on some implementation schemes described in this article.

[0041] Figure 23The following are schematic diagrams illustrating implementation schemes for the SUCI identifier type, based on some of the implementation schemes described in this article;

[0042] Figure 24 Schematic block diagrams of example user equipment implementation schemes are illustrated based on some implementation schemes described in this article;

[0043] Figure 25 Based on some implementation schemes described in this article, schematic block diagrams of example AMF node implementation schemes are illustrated; and

[0044] Figure 26 A schematic block diagram of an example N3IWF implementation is shown based on some of the implementation schemes described in this article. Detailed Implementation

[0045] The description and accompanying drawings illustrate only the principles of various embodiments. Therefore, it will be understood that those skilled in the art will be able to design various arrangements that, while not expressly described or shown herein, embody the principles herein and in the claims and fall within the spirit and scope of this disclosure. Furthermore, all examples listed herein are intended primarily for illustrative purposes only to aid the reader in understanding the principles of the embodiments and the inventive concepts made by the inventors to further their understanding in the art, and should be construed as not being limited to these specifically listed examples and conditions. Moreover, all statements herein referencing principles, aspects, and embodiments, as well as specific examples thereof, are intended to cover their equivalents.

[0046] For convenience, some of the abbreviations described in this article will be expanded 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 Negotiation

[0054] AMF core access and mobility management functions

[0055] AUSF Authentication Server Functionality

[0056] EAP Extensible Authentication Protocol

[0057] HPLMN Local 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-Connection Mode

[0064] MNC Mobile Network Code

[0065] N3IWF Non-3GPP Interoperability Function

[0066] NAI Network Access Identifier

[0067] NAS Non-Access Layer

[0068] Key set identifier in ngKSI 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 Connection Mode

[0075] SMC Safe Mode Command

[0076] SUCI subscription hidden identifier

[0077] SUPI subscription permanent identifier

[0078] UDM Unified Data Management

[0079] UE User Equipment

[0080] UICC General Integrated Circuit Card

[0081] USIM UMTS subscriber identification mobile

[0082] This document describes one or more embodiments of systems and methods for providing network services to unauthenticated user equipment. For example, various methods for establishing sessions for unauthenticated UEs in non-3GPP access networks are described.

[0083] Figure 1 This diagram illustrates a schematic block diagram of an implementation scheme for an access network type that fully or partially conforms to the 3rd Generation Partnership Project (3GPP) standards set or other types of Internet Protocol (IP) data packet core network standards. This architecture is described in more detail in the technical standard 3GPP TS 23.402V14.2.0 (December 2016), entitled "3rd Generation Partnership Project; Technical Specification Group Services and Systems Aspects; Architecture Enhancements for Non-3GPP Access," which is incorporated herein by reference.

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

[0085] Trusted non-3GPP access network 108 is an operator-built or operator-supported wireless local area network (WLAN), such as an IEEE 802.11x compliant WLAN network with encryption and secure authentication methods. In one implementation, trusted non-3GPP access network 108 supports the following example features: 802.1x-based authentication, which in turn requires encryption of the radio access network (RAN); 3GPP-based network access using EAP methods for authentication; and IPv4 and / or IPv6 protocols. However, operators may determine that other types of non-3GPP access networks with different types of security will be considered trusted. Untrusted non-3GPP access network 110 includes non-3GPP access networks that are unknown to the operator or do not include supported authentication standards. For example, untrusted non-3GPP access networks may include home or public WLANs, such as IEEE 802.11x compliant WLAN networks open to public, home, or other non-operator-managed networks of a different origin.

[0086] Fifth-generation wireless, or 5G, is another set of protocols that is the latest version of cellular technology, designed to significantly improve the speed and responsiveness of wireless networks. The term 5G was initially defined by the ITU IMT-2020 standard, which requires a theoretical peak download capacity 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-phase system architecture of 5G systems, which includes network slicing. Technical Specification (TS) 23.502 defines the processes of 5G systems. Technical Specification (TS) 23.503 defines the policy and charging control framework for 5G systems.

[0087] In 5G systems, 5G access networks may include, for example, Next Generation (NG) Radio Access Networks (NG-RAN) as described in 3GPP TS 38.300. Additionally, 5G access networks may include untrusted non-3GPP access networks, where UEs may connect to the 5G core network, for example, via secure IPSec / IKE tunnels terminated on non-3GPP Interoperability Functions (N3IWF). Non-3GPP access networks (N3AN) are considered 5G access networks and are considered part of the 5G system (5GS).

[0088] For untrusted non-3GPP access, the access node, including the N3IWF, provides termination for the N2 and N3 signaling interfaces, respectively, for the control plane and user plane. 5G-enabled UEs access the 5G core network by connecting to the non-3GPP access network (which serves as the 5G access network) via the N3IWF. The N3IWF relays uplink and downlink control plane NAS (N1) signaling between the UE and the 5G core network, enabling the UE to have a direct NAS signaling connection to the core network. Additionally, the N3IWF provides a user plane connection between the UE and the core network for PDU sessions via the non-3GPP access network.

[0089] Figure 2 The illustration shows a schematic block diagram of an implementation scheme for a 5G system architecture for non-3GPP access. This architecture is described in more detail in the technical standard 3GPP TS 23.501 (Release 15) (December 2017), entitled "System Architecture for the 5G System," which is incorporated herein by reference.

[0090] Non-3GPP access networks connect to the 5G core network via non-3GPP interoperability functions (N3IWF). The N3IWF interfaces with the 5G core network's control plane (CP) and user plane (UP) functions via the N2 and N3 interfaces, respectively. The UE establishes an IPSec tunnel with the N3IWF to attach to the 5G core network through the untrusted non-3GPP access network. During the IPSec tunnel establishment process, the UE is authenticated by the 5G core network and attached to it. Further details regarding the UE's attachment to the 5G core network via untrusted non-3GPP access are described in 3GPP TS 23.502 (Release 15) (December 2017), entitled "Procedures for the 5G System," and the technical standard described therein is incorporated herein by reference.

[0091] 5G systems include a local public terrestrial mobile network or an equivalent local PLMN (HPLMN-5G), including Access and Mobility Management Functions (AMF). AMF provides termination of the RAN control plane interface (N2) and the NAS (N1) protocol set, as well as NAS encryption and integrity protection. AMF also provides registration and connection management. AMF can include various functions to support non-3GPP access networks. For example, AMF can provide support for the N2 interface control protocol via N3IWF and support for NAS signaling with the UE via N3IWF. Additionally, AMF can provide support for authentication of UEs connected via N3IWF, and mobility management, authentication, and separate security context states for UEs connected via non-3GPP access or simultaneously via 3GPP and non-3GPP access.

[0092] The Session Management Function (SMF) includes session management functionalities such as session establishment, modification, and publication, including tunnel maintenance between the UPF and AN nodes. 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] User plane function (UPF) provides external PDU session interconnection points and packet routing and forwarding to the data network. UPF also supports the user plane portion of policy rule enforcement, such as gating, redirection, and traffic redirection.

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

[0095] In untrusted, non-3GPP access scenarios, the N3IWF's functionality includes supporting IPsec tunnel establishment with the UE. The N3IWF 204 terminates the IKEv2 / IPsec protocol with the UE 200 via the NWu interface and relays the information required to authenticate the UE 200 and authorize its access to the 5G core network via the N2 interface. The N3IWF provides termination for 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 handles N2 signaling related to PDU sessions and QoS from the SMF (relayed by the AMF). The N3IWF also provides IPsec Security Association (IPsec SA) establishment to support PDU session traffic. The N3IWF also provides uplink and downlink user plane packets relaying between the UE and the UPF.

[0096] Figure 3 The diagram illustrates a schematic block diagram of an implementation scheme for a UE to access a 5G system through multiple heterogeneous access networks. These heterogeneous access networks include, for example, 3GPP access, untrusted WLAN access, and non-3GPP access. When the UE registers with the 5G core through both 3GPP and non-3GPP access networks, multiple control plane NAS signaling connections are simultaneously active between the UE and the AMF.

[0097] When a UE establishes a secure connection, it sends a "Registration Request" message to the AMF / SEAF. This Registration Request message includes a 5GS Mobile Identifier (IE) containing the 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 for the AUSSF. The SEAF also includes the serving network name in the 5G-AIR message. After receiving the 5G-AIR message from the SEAF, the AUSSF prepares an "Auth-Info-Req" ​​message and sends it to the UDM / ARPF. The UDM / ARPF first generates an authentication vector with the Authentication Management Field (AMF) separator bit set to 1. The UDM / ARPF then calculates CK' and IK'. The ARPF then sends (RAND, AUTN, XRES, CK', IK') to the AUSSF using an 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. SEAF transparently forwards the EAP request / AKA challenge message to the UE within the NAS message Auth-Req. After receiving a response to the Auth-Req message from the UE, SEAF forwards the EAP response to AUSF, and AUSF verifies the response using stored information. If verification is successful, AUSF sends EAP-SUCCESS and the anchor key to SEAF, which then responds to the UE with EAP-SUCCESS. If AUSF receives SUCI from SEAF when initiating authentication, AUSF also includes SUPI along with the EAP-SUCCESS message.

[0098] If a UE is accessing a PLMN via one type of access (e.g., 3GPP access) and accessing another PLMN via another type of access (e.g., non-3GPP access), different primary authentications are performed. After registration, the NAS connection is served by different AMF services utilizing different security contexts. However, as... Figure 3 As shown, a UE can request registration in the same serving 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.

[0099] Currently, when a UE registers with a serving network through different types of access, the allocation of the NAS connection identifier is hard-coded. For example, the 3GPP TSG#80 plenary meeting approved the completion of the standalone (SA) release 15 (REL-15) of the 5G specification, which was released 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 hard-coded allocation of connection identifiers does not present problems in REL-15 because only one type of non-3GPP access is supported, such as untrusted WLAN access. However, it is foreseeable that future releases will add additional non-3GPP access network types, such as trusted WLAN access, wired access, MuLTEFire access, etc. Different types of non-3GPP access networks each require the establishment of separate NAS connections. Depending on the network configuration and the UE's service subscription, a UE can connect to multiple access networks simultaneously, for example, such as... Figure 2 The diagram shows connections to both a 3GPP access network and multiple non-3GPP access networks. In this case, using the same NAS connection identifier for connections across different non-3GPP access networks will not work.

[0100] Additionally, different access types can be activated in different orders. For example, it's possible that the UE first receives authentication through one of the non-3GPP access networks and establishes the NAS security context before registering via a 3GPP access network. Alternatively, the UE may register via multiple non-3GPP access networks instead of through a 3GPP access network. Therefore, a more flexible binding between serving network and access type pairs and NAS connectivity is required.

[0101] For a UE to verify that it is connected to a serving network authorized to provide services to the UE, the serving network needs to be verified by the local network during the authentication (AKA) process. This verification is implicit because it is assumed that the serving network is authorized if the basic authentication and key negotiation processes have been successfully completed. However, failure conditions should not be implicit and need to be explicitly defined.

[0102] Finally, in 5G systems, the subscriber identifier is called the Subscription Persistent Identifier (SUPI). The SUPI can be defined in either IMSI or NAI format. To ensure subscriber privacy, the SUPI should not be transmitted in plaintext over the 5G RAN and is wirelessly hidden using a Subscription Hidden Identifier (SUCI). The SUCI is generated using a protection scheme with an original public key that has been securely supplied under the control of the local network. Only the subscription identifier portion of the SUPI is hidden, while the local network identifier portion of the SUPI needs to remain explicit for routing purposes.

[0103] Routing information can differ depending on the access network type. For 3GPP access networks, the Mobile Country Code (MCC) and 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 access 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). NHAMI is a reserved global value that is the same for all MuLteFire networks that enable NHN access mode. The encoding of SUCI information elements needs to be defined in a generic manner to enable SUCI to support the use of other types of network and subscriber identifier formats as mobile identifiers during the authentication process.

[0104] It is also assumed that both IMSI and NAI formats can be used for SUPI. For SUCI mode output, if the subscription identifier is in IMSI format, then MSIN corresponds to the representation, while if the subscription identifier is in NAI format, then the username corresponds to the representation. For IMSI-based NAI, the user identifier portion of the NAI also consists of numbers, therefore additional encoding rules are required to distinguish between IMSI format, NAI format, and other possible types of subscriber identifier formats in the SUCI information element definition.

[0105] The one or more implementations described herein provide systems and methods for implementing concurrent secure connections over multiple heterogeneous access networks. New methods and protocol enhancements are described to allow UEs to include access types during registration and to track concurrent NAS connections mapped over heterogeneous access networks. New systems and methods for handling serving network authentication failures are also described. Further descriptions of new systems and methods, as well as protocol enhancements, are provided to support the use of NAIs as a type of subscription identifier, and the future scalability of subscription identifiers to support MuLteFire access networks and private networks.

[0106] 1. Implementation Plan - The UE includes the access type during registration and the ability to track concurrent NAS connections mapped through heterogeneous access networks.

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

[0108] Figure 4 This diagram illustrates a logical flowchart of an implementation of a method for the authentication and key negotiation message flow between the UE and core network functions when the UE initiates initial registration via access network type A. The NAS message shown between the UE and the AMF can be tunneled via an IPsec tunnel if access network type A is an untrusted non-3GPP access. For example, by initiating an initial Internet Key Exchange (IKE) protocol 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 the first of several network types, including 3GPP access, trusted non-3GPP access, untrusted non-3GPP access, untrusted WLAN access, trusted WLAN access, MuLTEFire access, etc.

[0109] When a UE initiates initial registration via access network type A, the UE includes the access type in the registration request message. The UE sends a registration request message to the AMF. The AMF is co-located with the Security Anchor Function (SEAF), which acts as the security anchor 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. The SEAF includes the subscription ID, service network name, and access type in the Nausf_UEAuthentication_Authenticate request.

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

[0111] Upon receiving the Nudm_UEAuthentication_Get request, UDM / ARPF selects an authentication method based on the subscription data. For example, a modified EAP-AKA mutual authentication type protocol (e.g., EAP-AKA as 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 executed between the UE and AUSF.

[0112] UDM / ARPF generates an authentication vector and sends this authentication vector AV'(RAND, AUTN, XRES, CK', IK') to AUSF. AUSF receives a Nudm_UEAuthentication_Get request from the authentication vector. UDM / ARPF also uses the Nudm_UEAuthentication_Get response message to convey an indication that the authentication vector AV' will be used for EAP-AKA'.

[0113] AUSF and UE then proceed with the EAP request / AKA' challenge exchange. AUSF derives the KAUSF and KSEAF keys and includes the EAP success message and KSEAF in the Nausf_UEAuthentication_Authenticate response message, which is then sent to AMF / SEAF.

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

[0115] Upon completion of the process, the mapping table from service network and access type to NAS connection is updated to include connection information for access network type A, as follows: Figure 5 As shown.

[0116] Figure 5The diagram illustrates a schematic block diagram of an implementation scheme for a mapping table from serving network and access type to NAS connection. 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 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 A and the UE. Therefore, the mapping table stores the NAS connection identifier, access network type, network identifier, and access network identifier for each NAS connection.

[0117] Figure 6 The diagram illustrates a schematic block diagram of an implementation scheme for the registration request message content. The UE sends a registration request message to the AMF via the access network to initiate initial registration. The registration request message includes the access network information element "Access Type." 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 The diagram illustrates a schematic block diagram of an implementation scheme for the access type information element in a registration request message. The access type is a Type 1 information element.

[0119] Figure 8 The diagram illustrates a schematic block diagram of an implementation scheme for the access type value of the access type information element in a registration request message. In this implementation, access types include 3GPP access, untrusted non-3GPP access, trusted non-3GPP access, untrusted WLAN access, trusted WLAN access, and MuLTEFire access. Alternative or additional access types may be included in the access type information element of the registration message.

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

[0121] When a UE initiates subsequent registration through a different type of access network (e.g., access type C), and the UE has already been authenticated by the network and is served by the same AMF in the same serving network, the AMF may decide not to run a new authentication process, regardless of whether it has a available security context for use.

[0122] Figure 9 The diagram illustrates a logical flowchart of an implementation of a method for a UE to register via access network type C when reusing an existing NAS security context. In this example, it is assumed that the UE has already established a NAS connection with access network types A and B. Note that if access network type C is an untrusted non-3GPP access, the NAS messages displayed between the UE and the AMF will be tunneled via an IPsec tunnel.

[0123] When a UE initiates subsequent registration through another access network with access network type C, the UE includes the access type in the registration request message. The AMF may decide to reuse an existing security context. A new NAS connection is created using the available generic 5G NAS security context. The NAS security context is updated using parameters specific to the new NAS connection. Upon completion of this process, the mapping table of serving networks and access types to NAS connections is updated to include connection information for access network C, such as... Figure 10 As shown.

[0124] Figure 10 The diagram illustrates a schematic block diagram of an implementation scheme for a service network and access type-to-NAS connection mapping table after registration using 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 through the 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 AMF.

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

[0126] When a UE initiates subsequent registration via access type C, if the UE has already been authenticated by the network of the same serving network, the AMF can decide to run the authentication and key negotiation process again. This is because the UE is served by a different AMF or because the security algorithm has been changed.

[0127] Figure 11 This is a logical flowchart of an implementation scheme for a method used by a UE to register via access network type C when initiating a new authentication. In this example, it is assumed that the UE has already established a NAS connection using access network types A and B. Note that if access network type C is an untrusted non-3GPP access, the NAS message displayed between the UE and the AMF will be tunneled via an IPsec tunnel.

[0128] When a UE initiates subsequent registration via access network type C, the UE includes the access type in the registration request message. The AMF decides to run the authentication and key negotiation process again. The AMF may decide to run the authentication and key negotiation process again because the UE is served by a different AMF or because the security algorithm has changed. When the authentication and key negotiation process is complete, the AMF initiates a new NAS security mode command to the UE to activate a new derived 5G NAS security context regarding access type C.

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

[0130] Figure 12 The diagram illustrates a schematic block diagram of an implementation scheme for a service network and access type-to-NAS connection mapping table after registration using 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 through the 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 AMF.

[0131] 2. Implementation Plan - Service Network Authorization Failed

[0132] For a UE to verify that it is connected to an authorized service network providing services to the UE, the service network needs to be verified by the local network during the AKA process. If the service network is authorized, the AKA process will continue, and if the main authentication and key negotiation process has been successfully completed, it means that the service network is authorized.

[0133] However, if the service network is not authorized, the authentication process will stop, and AUSF will send an authentication response to AMF indicating that authentication failed because the service network was not authorized.

[0134] Figure 13The diagram illustrates a logical flowchart of an implementation method for a UE to register via access network type A when a serving network authorization failure has occurred. Note that if access network type A is an untrusted non-3GPP access, NAS messages between the UE and the AMF will be tunneled via an IPsec tunnel.

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

[0136] Service network authorization failure differs from other PLMN-related failures. This failure is not due to UE subscription or access restrictions (e.g., due to operator restrictions), but rather to a service network failure related to security authentication / authorization. Currently, there is no cause code for this type of failure.

[0137] One fault code associated with PLMN failures is "PLMN Not Allowed," but this fault code indicates a rejection to the UE due to subscription or operator-determined restrictions. This fault code is: Reason #11 – PLMN Not Allowed. This 5GMM reason is sent to the UE if it requests service or initiates a deregistration request in a PLMN that disallows UE operation via subscription or due to operator-determined restrictions.

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

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

[0140] For example, when a serving network authorization failure occurs, the UE can abort the initial registration process with the PLMN, store the PLMN identifier in the "forbidden PLMN list," set the 5GS update status to 5U2 NOT UPDATED, and enter the state 5GMM-DEREGISTERED.PLMN-SEARCH to perform PLMN selection. Therefore, a new 5GMM rejection reason is needed to indicate "serving network not authorized."

[0141] Figure 14 The diagram illustrates a schematic block diagram of an implementation of the 5GMM reason information element. The 5GMM reason information element indicates the reason why the network rejects a 5GMM request from the UE. This information element includes a new 5GMM rejection reason to indicate "Serving network not authorized". For example, a new rejection could be included as a new reason code #73 to signal to the UE that serving network authorization failed. The new reason code is used if the authentication process cannot continue because the serving network is not authorized.

[0142] Figure 15 The diagram illustrates a schematic block diagram of the implementation scheme for the cause value of the 5GMM cause information element. The cause value has been updated to include the new cause #73 - Serving network not authorized. This 5GMM cause is sent to the UE if the UE initiates registration with the serving network and the serving network authorization fails.

[0143] After authentication with the serving network fails, the UE receives a registration rejection for 3GPP access due to the 5GMM reason "Serving network not authorized". The UE then aborts the initial registration process, stores the PLMN identifier in the "Forbidden PLMN List", sets the 5GS update status to 5U2 NOT UPDATED, and enters the state 5GMM-DEREGISTERED.PLMN-SEARCH to perform PLMN selection. The UE is thus able to select another PLMN.

[0144] 3. Implementation Plan - Methodology and Protocol Enhancements to support the use of NAI as a type of subscription identifier and to support future scalability of subscription identifiers to support MuLteFire and private networks.

[0145] a) Define a new field “SUPI Format” to allow different subscriber identifier types / formats to be used as subscriber identifiers.

[0146] A globally unique 5G Subscription Permanent Identifier (SUPI) is assigned to each user in the 5G system and 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 5G Systems," dated March 26, 2018, and incorporated herein by reference in Release 15. The following have been identified as valid SUPI types: IMSI and NAI.

[0147] When a device has not yet been assigned a 5G-GUTI (5G Globally Unique Temporary Identifier), the SUCI is a partially encrypted SUPI used in the process of associating with the 5G system. A SUCI is typically created by encrypting the MSIN (Mobile Subscriber Identifier) ​​component of the subscriber's IMSI.

[0148] The UE generates the SUCI using the original public key securely provided in the control of the local network. The protection scheme uses the original public key of the local network. As specified in the protection scheme, the UE constructs the scheme input based on the subscription identifier portion of the SUPI (e.g., applying a certain padding scheme). The UE then executes the protection scheme with the constructed scheme input as input and outputs the scheme output. The UE does not hide the local network identifier, such as the Mobile Country Code (MCC) or Mobile Network Code (MNC). The UE then generates the SUCI, which includes the local network identifier, the local network public key, and the scheme output.

[0149] However, assuming both IMSI and NAI formats can be used with SUPI, for SUCI mode output, if the subscription identifier is in IMSI format, then MSIN corresponds to the representation, while if the subscription identifier is in NAI format, then the username corresponds to the representation. For IMSI-based NAI, the subscriber identifier portion of the NAI also consists of numbers, thus requiring additional encoding rules to distinguish between IMSI format, NAI format, and other possible types of subscriber identifier formats defined in the SUCI information element definition.

[0150] Figure 16The diagram illustrates a schematic block diagram of an implementation scheme for enabling Subscription Hidden Identifiers (SUCIs) to utilize new information fields with different SUCI structures. Using these new information fields, the mobile identification format for SUPIs and SUCIs can be customized based on the SUPI identification type / format used. For example, for IMSIs, the network identifier is based on the MNC / MCC. For IMSI-based NAIs, the network identifier is also based on the MNC / MCC. For non-IMSI-based NAIs, 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 / hardcoded global MCC / MNC value. For MuLteFire NAIs (MF-NAIs), the network identifier is based on a special reserved / hardcoded global MCC / MNC, Neutral Host Network ID (NHN-ID), and Participating Service Provider ID (PSP-ID).

[0151] Figure 17 The diagram illustrates an implementation scheme for the identifier types supported by the new information field for Subscription Hidden Identifier (SUCI). The new SUCI information field enables different identifier types to be used as subscriber identifiers. Identifier types may include SUCI, 5G-GUTI, IMEI, 5G-S-TMSI, IMEISV, MAC address, or device identifier. Device identifiers may include, for example, UDI, ODIN, Bluetooth ID, serial number, etc. Alternative or additional identifier types can also be defined.

[0152] Figure 18 The diagram illustrates a schematic block diagram of an implementation scheme for the General SUCI Subscriber Identifier format. The SUCI Subscriber Identifier structure includes a Network Type Indicator (NTI). The Local Network Identifier and Routing Identifier can differ for different access network types. The scheme output field contains a hidden subscriber identifier generated using a protection scheme.

[0153] Figure 19 The diagram illustrates a schematic block diagram of an implementation scheme for the SUCI subscriber identifier format when the SUPI format is IMSI or IMSI-based NAI. This diagram illustrates the 5GS mobile identification information element format when the identifier 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 20This diagram illustrates a schematic block diagram of an implementation scheme for the SUCI subscriber identifier format when the SUPI format is a non-IMSI-based NAI and the identifier type is "SUCI". It also illustrates an example of the 5GS mobile identification information element format when the identifier type is "SUCI" and the SUPI format is a "non-IMSI-based NAI". The network identifier and routing information are network-specific. The value in the Network Type Indicator (NTI) field indicates the type of network.

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

[0156] Figure 22 The diagram illustrates a schematic block diagram of the SUCI subscriber identifier format implementation when the identifier 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). NHAMI is a reserved global value that is the same for all MuLteFire networks with NHN access mode enabled.

[0157] Figure 23 A schematic block diagram illustrating an implementation scheme for the SUCI identifier type is shown. The table below describes various examples of additional encoding used for the SUCI identifier type.

[0158] Figure 24 The illustration shows a schematic block diagram of an embodiment of example user equipment 220. User equipment (UE) 220 may include a smartphone, smart tablet, laptop, smartwatch, PC, TV, or other device. Additional or alternative components and functions may be included within UE 220. Furthermore, one or more of the functions and components shown herein may be absent or combined with other components or functions.

[0159] UE 220 includes a processing device 2600 and a memory device 2602, both configured to perform one or more of the functions described herein with respect to UE 220. Memory device 2602 may include a managed object 2604 that stores application programs and operation instructions that control the processing device 2600 to perform the various functions described herein. Memory device 2602 may also store a mapping table 2650 for service network and access type to NAS connection. UE 220 may also include a UICC 2606, which includes a USIM 2608 for storing IMSIs.

[0160] UE 220 may further include a Bluetooth transceiver 2610, a WLAN (IEEE 802.11x 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. UE 220 may further include a user interface 2618, an AC adapter 2620, a battery module 2622, a USB transceiver 2624, and an Ethernet port 2628.

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

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

[0163] Figure 26The illustration shows a schematic block diagram of an example N3IWF implementation. The N3IWF can be an access point in a wireless local area network (WLAN), a gateway in a WLAN, etc. The N3IWF can be integrated with other nodes in the access network. Additional or alternative components and functions may be included within the N3IWF. Furthermore, one or more of the functions and components shown herein may be absent or combined with other components or functions. The N3IWF includes a processing device 2800 and a memory device 2802, both configured to perform one or more of the functions described herein. The N3IWF may 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 may also include one or more other types of interfaces for communicating with the UE, such as a WLAN transceiver 2806 (e.g., compliant with IEEE 802.1x WLAN type networks). The N3IWF may also include a mobile RF transceiver 2808 compliant with a cellular air interface. UE 220 can communicate with N3IWF using one or more of WLAN transceiver 2806 or mobile RF transceiver 2808.

[0164] The processing means described herein includes at least one processing means, such as a microprocessor, microcontroller, digital signal processor, microcomputer, central processing unit, field-programmable gate array, programmable logic device, state machine, logic circuit, analog circuit, digital circuit, and / or any means of manipulating signals (analog and / or digital) based on hard-coded circuit and / or operating instructions. The memory means is a non-transitory memory means and may be internal or external memory, and may be a single memory means or multiple memory means. The memory means may 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 means storing digital information. The term "module" is used in the description of embodiments of one or more of the elements herein. A module includes one or more processing means and / or one or more non-transitory memory means operable to perform one or more functions as described herein. A module may operate independently and / or in conjunction with other modules, and may utilize the processing means and / or memory of other modules and / or the operating instructions of other modules. As used in this article, a module may contain one or more submodules, and each submodule may be one or more modules.

[0165] As may be used herein, the terms “operable to” or “configurable to” indicate that an element includes one or more of circuits, instructions, modules, data, inputs, outputs, etc., to perform one or more of the described or necessary corresponding functions, and may also include inferred coupling to one or more other items to perform the described or necessary corresponding functions. As may also be used herein, the terms “coupled,” “coupled to,” “connected to,” and / or “connected” or “interconnected” include direct connections or links between nodes / devices, and / or indirect connections between nodes / devices via intermediate items (e.g., items include, but are not limited to, components, elements, circuits, modules, nodes, devices, network elements, etc.). As may be further used herein, inferred connections (i.e., inferred connections between one element and another) include direct and indirect connections between two items in the same manner as “connected to.”

[0166] Please note that aspects of this disclosure may be described herein as processes depicted as schematic diagrams, flowcharts, structural diagrams, or block diagrams. Although a flowchart may describe operations as a sequential process, many operations within an operation can be executed in parallel or simultaneously. Furthermore, the order of operations can be rearranged. A process terminates upon completion of its operations. A process may correspond to a method, function, procedure, subroutine, subroutine, etc. When a process corresponds to a function, the termination of the process corresponds to the function returning to the calling function or the main function.

[0167] Various features of the present disclosure described herein can be implemented in different systems and apparatuses without departing from this disclosure. It should be noted that the foregoing aspects of this disclosure are merely illustrative and should not be construed as limiting the scope of the disclosure. The descriptions of various aspects of this disclosure are intended to be illustrative and not to limit the scope of the claims. Therefore, the teachings can be readily applied to other types of apparatuses, and many alternatives, modifications, and variations will be apparent to those skilled in the art.

[0168] In the foregoing description, certain representative aspects of the invention have been described with reference to specific examples. However, various modifications and changes may be made without departing from the scope of the invention as set forth in the claims. This description and drawings are illustrative rather than restrictive, and modifications are intended to be included within the scope of the invention. Therefore, the scope of the invention should be determined by the claims and their legal equivalents, and not merely by the described examples. For instance, any components and / or elements listed in the device claims may be assembled or otherwise operatively configured in various arrangements, and are therefore not limited to the specific configurations listed in the claims.

[0169] Furthermore, certain benefits, other advantages, and solutions to problems have been described above with respect to specific embodiments; however, no benefit, advantage, solution to a problem, or element that may lead to or make more apparent any particular benefit, advantage, or solution, should be construed as a key, necessary, or essential feature or component of any or all claims.

[0170] As used herein, the terms “comprising,” “having,” or any variation thereof are intended to mean a non-exclusive inclusion, such that a process, method, article, composition, or apparatus that comprises a list of elements includes not only those elements listed but also other elements not expressly listed or inherent to such process, method, article, composition, or apparatus. Unless otherwise specifically stated, other combinations and / or modifications of the above-described structures, arrangements, applications, proportions, elements, materials, or components used in the practice of this invention may be altered or otherwise particularly adapted to specific environments, manufacturing specifications, design parameters, or other operational requirements without departing from its general principles.

[0171] Furthermore, unless otherwise stated, reference to an element in the singular is not intended to mean "one and only one," but rather "one or more." Unless otherwise expressly stated, the term "some" means one or more. All structural and functional equivalents of elements throughout the various aspects described in this disclosure that are known or will be known hereafter by one of ordinary skill in the art are expressly incorporated herein by reference and are intended to be covered by the claims. Moreover, whether or not this disclosure is expressly recited in the claims, it is not intended to contribute the disclosure herein to the general public. Pursuant to 35 U.SC §112(f), no claim element should be construed as an element of the "apparatus with additional function" type, unless the element is expressly stated using the phrase "apparatus for..." or, in a method claim, the element is stated using the phrase "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 generate a subscription hidden identifier (SUCI) in the following manner: Determine one of a plurality of subscription persistent identifier (SUPI) formats, wherein the plurality of SUPI formats include at least one of the following: IMSI, IMSI-based NAI, non-IMSI-based NAI, or MF-NAI; The scheme output is determined based on the subscriber identifier using the protection scheme; and Construct a SUCI that includes the scheme output and a SUPI format field containing an indication of the determined SUPI format value.

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

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

4. The user equipment of claim 1, wherein one of the multiple types of identifiers used for the subscriber identifier includes one of the following: SUCI, 5G-GUTI, IMEI, 5G-S-TMSI, IMEISV, MAC address, or device identifier.

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

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

Images