Patent Description:
This section introduces aspects that may be helpful to facilitating a better understanding of the inventions.

Fourth generation (<NUM>) wireless mobile telecommunications technology, also known as Long Term Evolution (LTE) technology, was designed to provide high capacity mobile multimedia with high data rates particularly for human interaction. Next generation or fifth generation (<NUM>) technology is intended to be used not only for human interaction, but also for machine type communications in so-called Internet of Things (IoT) networks.

While <NUM> networks are intended to enable massive IoT services (e.g., very large numbers of limited capacity devices) and mission-critical IoT services (e.g., requiring high reliability), improvements over legacy mobile communication services are supported in the form of enhanced mobile broadband (eMBB) services intended to provide improved wireless Internet access for mobile devices.

In an example communication system, user equipment (<NUM> UE in a <NUM> network or, more broadly, a UE) such as a mobile terminal (subscriber) communicates over an air interface with a base station or access point referred to as a gNB in a <NUM> network or an eNB (evolved Node B) in an LTE network. The access point (e.g., gNB/eNB) is illustratively part of an access network of the communication system. For example, in a <NUM> network, the access network is referred to as a <NUM> System and is described in <NUM> Technical Specification (TS) <NUM>, V0. <NUM>, entitled "Technical Specification Group Services and System Aspects; System Architecture for the <NUM> System," the disclosure of which is incorporated by reference herein in its entirety. In an LTE network, the access network is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN). In general, the access point (e.g., gNB/eNB) provides access for the UE to a core network (CN), which then provides access for the UE to other UEs and/or a data network such as a packet data network (e.g., Internet).

Privacy is an important consideration in any communication system. Privacy is broadly addressed in <NUM> Technical Report (TR) <NUM>, V1. <NUM>, entitled "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on the security aspects of the next generation system (Release <NUM>)," the disclosure of which is incorporated by reference herein in its entirety. In particular, TR <NUM> identifies subscription (UE) privacy as one of the most important security areas to be addressed in <NUM> networks. The present invention provides subject-matter according to the independent claims.

Document <CIT> relates to a method and apparatus including units configured to send a request from a first network entity to a user equipment for an identifier and receive a message indicating that a public key is required from the user equipment by the first network entity. The method and apparatus also includes units configured to send, by the first network entity, the public key to the user equipment and receive an encrypted identifier by the first network entity, wherein upon authenticating the public key, the user equipment encrypts at least part of the identifier using the public key, thereby enabling further processing between the network entity and the user equipment.

Document<NPL> discloses adding a tag before the encrypted IMSI to indicate that this is a temporary IMSI.

Document <CIT> discloses a network node that indicates whether the network supports perfect forward secrecy (PFS) by setting a specific bit in a message to the UE.

The invention is defined by an independent method claim <NUM> (executed at the network), an independent method claim <NUM> (executed at the UE) and corresponding independent claims <NUM> (apparatus) and <NUM> (computer software product). Preferred embodiments are specified by the dependent claims.

While these and other techniques described herein can be applied to various communication networks, they are particularly suitable for <NUM> and next generation communication networks.

These and other features and advantages of embodiments described herein will become more apparent from the accompanying drawings and the following detailed description.

Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for managing authentication requests in a manner which protects the privacy of the user's subscription identity. It should be understood, however, that the scope of the claims is not limited to particular types of communication systems and/or processes disclosed. Embodiments can be implemented in a wide variety of other types of communication systems, using alternative processes and operations. For example, although illustrated in the context of wireless cellular systems utilizing 3GPP system elements such as an LTE Evolved Packet Core (EPC) and a 3GPP next generation system (<NUM>), the disclosed embodiments can be adapted in a straightforward manner to a variety of other types of communication systems including, but not limited to, WiMAX systems and Wi-Fi systems.

As mentioned above, privacy of subscription identifiers when communicating over the air interface between the user equipment and the network access point has been a significant issue for <NUM>/<NUM>/<NUM> networks. Efforts have been made in <NUM> networks to address this significant issue. Even if it is unavoidable that down bidding attacks (e.g., an attacker impersonates the user equipment to negotiate an inferior security capability with the network access point) may force a <NUM> UE to attach to a lower generation network, it is realized that there is a need to address these privacy demands.

The above-referenced TR <NUM> describes several solutions to provide privacy over the air interface that can be generally grouped in three solution classes:.

Note that, in one example, an International Mobile Subscriber Identity (IMSI) is a permanent subscription identifier (subscriber identity) of a UE. In one embodiment, the IMSI is a fixed <NUM>-digit length and consists of a <NUM>-digit Mobile Country Code (MCC), a <NUM>-digit Mobile Network Code (MNC), and a <NUM>-digit Mobile Station Identification Number (MSIN).

Note also that in an LTE network, the home subscriber server/function is called a Home Subscriber Server (HSS), and in a <NUM> network it is called User Data Management (UDM) which may also comprise an Authentication and Security Function (AUSF) and an Authentication Credential Repository and Processing Function (ARPF) as part of the UDM function.

While some illustrative embodiments are described herein from the perspective of the second solution class (i.e., the home network public key based solution), alternative embodiments may be implemented for the other two solution classes. See SA2 TS <NUM> and SA3 TR <NUM>, the disclosures of which are incorporated by reference herein in their entireties.

In the home network public key based solution, the home operator provides its public key to all home network subscribers. They will use it to encrypt the subscriber identity, which is, by way of example, the MSIN part of IMSI. Only the MSIN part needs to be encrypted, because MNC+MCC is needed by the serving network to route to the correct home network. Only the home HSS can decrypt the message because it possesses the private key that corresponds to the public key. Once the IMSI is identified, HSS/AuC (where AuC is the Authentication Center part of the HSS) will create authentication vectors (AVs) based on the distinct shared root key K between a user (subscriber) and the HSS/AuC. Similarly, in the <NUM> network, the UDM/ARPF creates the AV's requested via AUSF. AUSF and UDM could be co-located for optimization reasons.

An operator in his network may have implementations of multiple HSSs which allows him to manage distinct sets of users in different HSSs/UDMs. Because of the multiple HSSs, a Server Location Function (SLF) may be implemented in front of a set of HSSs. Note that SLF may also be referred to as a Subscriber Location Function. The SLF analyzes the authentication request for a user received from the MME/AMF and routes it to the correct HSS.

By way of example only, operation of the SLF is described in 3GPP TS <NUM> (Section <NUM>: "User identity to HSS resolution") entitled "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol (Release <NUM>)," the disclosure of which is incorporated by reference herein in its entirety. The SLF provides user identity (IMSI)-to-HSS resolution using a locally maintained subscriber profile database and routes the Diameter messages containing the user authentication requests, as a Diameter proxy to the chosen HSS. Note that, in <NUM>, similar functionality would also be requested if <NUM> core network protocols are different from Diameter, e.g., using http-proxies. In the following descriptions, it is assumed that the SLF is covering both the DRA (Diameter Routing Agent) based solution as per <NUM> or any other proxy related solution dependent on protocol decisions for the <NUM> core network.

It is realized herein that if the home operator uses an SLF to split its set of subscribers, the SLF would need to evaluate the received identifier first. Thus, in a <NUM> network with permanent subscriber identity (e.g., IMSI) encrypted by one of the methods, an SLF would need to take over the decryption of the MSIN part of the IMSI. Further, the SLF would need to keep a database of all subscribers' profiles with the routing information, i.e., a profile should map a subscriber's permanent identity (e.g., IMSI) to one of the HSSs in the network to forward the Authentication Request after decrypting the received (encrypted) IMSI. Therefore, it is advantageous to perform the decryption of the encrypted IMSI at the SLF instead of in the HSS. Hence, instead of an HSS storing the private key, now the SLF would need to store and use the network private key. An SLF is placed in the home operator's domain and considered trusted. In general, an SLF could be assumed in a large operator network. The usage of an SLF simplifies the new privacy management for the HSS/UDM in <NUM> networks up to the point that HSS/UDM is not changed at all for the protection of subscription identifiers over the air interface, but the SLF needs to perform the additional functionality of encrypted IMSI decryption and then perform the IMSI-to-HSS resolution.

Accordingly, illustrative embodiments as described herein address the issue of how the HSS/UDM or the SLF can efficiently deal with newly introduced privacy features, i.e., that the received attach request first needs to be decrypted. If this is not taken care of, the HSS/UDM or SLF would receive a request and attempt to process it wasting unnecessary computing resources.

Privacy will depend on country specific regulation, therefore HSS/UDM or SLF would need to be implemented to handle both cases of a request for authentication vectors, i.e., to process or forward a "normal" attach request if the <NUM> UE has not applied privacy or to process a "privacy" attach request.

In a first illustrative embodiment, the <NUM> UE, if it wants to protect its privacy, adds an identity privacy flag (i.e., privacy indicator) to indicate that the MSIN is provided in encrypted form.

It is to be appreciated that the privacy indicator, in addition to being an "explicit" privacy indicator such as a flag or field, can alternatively be an "implicit" privacy indicator. By implicit privacy indicator, it is meant that the privacy feature is conveyed by the UE to a network element/function via the algorithm used to encrypt the message. Thus, the network element/function receiving the message from the UE is informed of the privacy feature by the fact that the message is encrypted with a particular encryption algorithm. This also applies to a null-encryption scheme. In a null-encryption scheme, the input equals the output, and the SUPI (Subscription Permanent Identifier of the UE) is unencrypted, i.e., a format-preserved scheme. One could interpret this as the SUPI (or IMSI) is always encrypted, but if no privacy is "switched on," then the null-encryption is used. Thus, the privacy indicator would implicitly reside in the algorithm scheme used (e.g., null-encryption or an algorithm that actually encrypts a message).

It could be suggested that the HSS or SLF, even without this privacy indicator, will figure out after the first attempt to solve the request and, if encrypted, to attempt the decryption. But one key reason to have such an indication specified is that this saves processing time and fewer resources are needed. Thus, in this first illustrative embodiment, the SLF can make the decision on the processing by looking at this flag. If not set, the SLF will assume the provided IMSI is unencrypted, will do the IMSI-to-HSS resolution, and will forward to the correct HSS/UDM, i.e., compatibility with <NUM> operation is maintained. If the flag is set, the SLF will recognize that the provided IMSI is encrypted and use the network private key to decrypt the MSIN part to form the real unencrypted IMSI, perform the IMSI-to-HSS resolution and then forward the Authentication Request to the correct HSS/UDM. If no SLF is used, the same principle can be used by the HSS/UDM. That is, HSS/UDM has to check whether the <NUM> UE has set a flag and then decide whether decryption is needed.

This first illustrative embodiment can be applied to a <NUM> UE attaching via a <NUM> RAN (Radio Access Network) to a <NUM> core network (CN). However, 3GPP has identified, as the immediate deployment scenario, that the <NUM> UE should attach via a <NUM> RAN to a <NUM> CN. If the UE sets the indicator, the <NUM> CN would need to be enhanced to understand the identity privacy flag or other privacy indicator.

From a network architecture perspective for the operator with an evolving <NUM> network to <NUM>, both <NUM> and <NUM> access and core networks need to be supported for a considerable time. This means that current <NUM> HSS needs to be supported while supporting new <NUM> HSS functions of decrypting an encrypted MSIN. In accordance with embodiments, placing an SLF capable of identifying an encrypted MSIN and decrypting it before routing the authentication request to an HSS helps to manage the coexistence of <NUM> and <NUM> core in an operator network. Enhancing the SLF to support the new identity <NUM> privacy feature is more advantageous than enhancing the HSS. If the HSS is enhanced, then in a large network with multiple HSSs, all the HSSs need to be updated together with capability to decrypt an encrypted IMSI. This may be more tedious to handle compared to solving the problem in a single central node (e.g., the SLF). Advantageously, with the first illustrative embodiment, a bidding down attack in <NUM> (to <NUM>) would not be beneficial if the same feature is also deployed in <NUM> whereby an enhanced SLF is used to achieve this feature.

In a second illustrative embodiment, another privacy indicator is provided that the operator could decide to add, e.g., to the network Master Information Block (MIB) % System Information Block (SIB) broadcast, to indicate to the <NUM> UE that the network will be able to handle a privacy-protected identifier, e.g., a flag that indicates that privacy is expected, possible to process, or desired. It is then up to the <NUM> UE implemented/configured policy, whether to attach at all to a network, if this indicator is not sent. The indicator on the <NUM>/<NUM> network side would be to indicate regulation needs per country/region, i.e., switch on/off privacy. Note, while the UE is roaming in a visiting network, even though the UE authentication request from the visiting network is forwarded to the home network, for which the identity privacy indicator (first illustrative embodiment above) is described, there is a need to make adaptations to the serving network as well. The MME/SEAF (SEAF is a Security Anchor Function) has to handle the enhanced initial attach message from the UE, form the UE Authentication Request message, and route it to the home network for requesting the AV. If the subscription identifier is encrypted, the size of the message field for the encrypted IMSI may be different from today's <NUM> IMSI field (depending on the solution class chosen).

Note that the visiting network can also indicate its availability and, if applicable, its non-usage of privacy. This information can be broadcast, for example, as part of the SIB or other information block, or sent as an explicit request message to each UE.

In a third illustrative embodiment, the UE is configured to manage a privacy indicator that can be set to prohibit a <NUM> UE from responding to IMSI paging. Thus, if the UE wants to attach to the network and the network requests its real identity, a privacy-configured <NUM> UE configured with this privacy indicator would not answer.

Given the above-described privacy indicators, a wide variety of network configurations can be employed to implement the privacy indicators. <FIG> depict some of these network configurations. However, it is to be appreciated that embodiments are not limited to the network configurations illustrated herein or otherwise described below. <FIG> shows a communication system <NUM> within which illustrative embodiments are implemented. It is to be understood that the elements shown in communication system <NUM> are intended to represent main functions provided within the system, e.g., UE access functions, mobility management functions, serving gateway functions, etc. As such, the blocks shown in <FIG> reference specific elements in LTE and <NUM> networks that provide the main functions. However, other network elements may be used to implement some or all of the main functions represented. Also, it is to be understood that not all functions of an LTE or <NUM> network are depicted in <FIG>. Rather, functions that facilitate an explanation of illustrative embodiments are represented.

Accordingly, as shown, communication system <NUM> comprises user equipment (UE) <NUM> that communicates via an air interface <NUM> with an access point (eNB/gNB) <NUM>. The UE <NUM> may be a mobile station, and such a mobile station may comprise, by way of example, a mobile telephone, a computer, or any other type of communication device. In an LTE-V2X implementation, one or more UEs may be deployed in a given vehicle. The term "user equipment" as used herein is therefore intended to be construed broadly, so as to encompass a variety of different types of mobile stations, subscriber stations or, more generally, communication devices, including examples such as a combination of a data card inserted in a laptop or other equipment (e.g., a vehicle). Such communication devices are also intended to encompass devices commonly referred to as access terminals.

In one embodiment, UE <NUM> is comprised of a Universal Integrated Circuit Card (UICC) and Mobile Equipment (ME). The UICC is the user-dependent part of the UE and contains at least one Universal Subscriber Identity Module (USIM) and appropriate application software. The USIM securely stores the International Mobile Subscriber Identity (IMSI) number and its related key, which are used to identify and authenticate subscribers to access networks. The ME is the user-independent part of the UE and contains terminal equipment (TE) functions and various mobile termination (MT) functions.

The access point <NUM> is illustratively part of an access network of the communication system <NUM>. Such an access network may comprise, for example, an E--UTRAN or <NUM> System (or mixed) having a plurality of base stations and one or more associated radio network control functions. The base stations and radio network control functions may be logically separate entities, but in a given embodiment may be implemented in the same physical network element, such as, for example, a base station router or femto cellular access point.

The access point <NUM> in this illustrative embodiment is operatively coupled to a mobility management function <NUM>. In an LTE network, the function is typically implemented by a Mobility Management Element (MME), while in a <NUM> network, the function is implemented by an Access and Mobility Management Function (AMF). Although not expressly shown, SEAF can be implemented with the AMF connecting a UE with the mobility management. A mobility management function, as used herein, is the element or function in the CN part of the communication system that manages, among other network operations, access and authentication operations with the UE (through the access point <NUM>).

The MME/AMF <NUM> in this illustrative embodiment is operatively coupled to an SLF <NUM>. In illustrative embodiments, SLF <NUM> is configured as described above to respond to one or more privacy indicators that are set in messages it receives. As described above, SLF <NUM> may decrypt a subscriber identity or simply forward the encrypted information to the appropriate home network of UE <NUM>, depending on the one or more privacy indicators. Thus, as shown, SLF <NUM> is operatively coupled to a plurality of HSSs/UDMs <NUM>-<NUM>, <NUM>-<NUM>,. These HSSs/UDMs represent the home networks of UEs that may attach to the communication system <NUM>. SLF <NUM> is configured to provide the UE information to the appropriate HSS/UDM <NUM>.

The access point <NUM> is also operatively coupled to a serving gateway function <NUM> (e.g., Serving Gateway (SGW) in an LTE network, and Session Management Function (SMF) in a <NUM> network), which is operatively coupled to a Packet Data Network (PDN) Gateway (PGW) <NUM>. PGW <NUM> is operatively coupled to a Packet Data Network, e.g., Internet <NUM>. MME/AMF <NUM> and SLF <NUM> may be considered part of a CN. MME/AMF <NUM> and SLF <NUM> can also be part of a serving network. Further typical operations and functions of such network elements are not described here since they are not the focus of the illustrative embodiments and may be found in appropriate 3GPP LTE or <NUM> documentation.

It is to be appreciated that this particular arrangement of system elements is an example only, and other types and arrangements of additional or alternative elements can be used to implement a communication system in other embodiments. For example, in other embodiments, the system <NUM> may comprise authentication elements, as well as other elements not expressly shown herein.

Accordingly, the <FIG> arrangement is just one example configuration of a wireless cellular system, and numerous alternative configurations of system elements may be used. For example, although only single UE, eNB/gNB, MME/AMF, SLF, SGW/SMF and PGW elements are shown in the <FIG> embodiment, this is for simplicity and clarity of description only. A given alternative embodiment may of course include larger numbers of such system elements, as well as additional or alternative elements of a type commonly associated with conventional system implementations.

It is also to be noted that while <FIG> illustrates system elements as singular functional blocks, the various subnetworks that make up the <NUM> network are partitioned into so-called network slices. Network slices (network partitions) comprise a series of function sets (i.e., function chains) for each corresponding service type using network function virtualization (NFV) on a common physical infrastructure. The network slices are instantiated as needed for a given service, e.g., eMBB service, massive IoT service (e.g., V2X service), and mission-critical loT service. A network slice or function is thus instantiated when an instance of that network slice or function is created. In some embodiments, this involves installing or otherwise running the network slice or function on one or more host devices of the underlying physical infrastructure. UE <NUM> is configured to access one or more of these services via eNB/gNB <NUM>.

<FIG> shows a more detailed view of SLF <NUM> and one HSS/UDM <NUM> in an illustrative embodiment. Each HSS/UDM <NUM> (<NUM>-<NUM>, <NUM>-<NUM>,. , <NUM>-N) in <FIG> can be configured as shown in <FIG>. The SLF <NUM> comprises a processor <NUM> coupled to a memory <NUM> and interface circuitry <NUM>. The processor <NUM> of the SLF <NUM> includes an authentication processing module <NUM> that may be implemented at least in part in the form of software executed by the processor <NUM>. The authentication processing module <NUM> performs authentication operations of the processes described in conjunction with subsequent figures and otherwise herein. The memory <NUM> of the SLF <NUM> includes an authentication storage module <NUM> that stores authentication and related data generated or otherwise used during authentication operations.

The HSS/UDM <NUM> comprises a processor <NUM> coupled to a memory <NUM> and interface circuitry <NUM>. The processor <NUM> of the HSS/UDM <NUM> includes an authentication processing module <NUM> that may be implemented at least in part in the form of software executed by the processor <NUM>. The authentication processing module <NUM> performs the authentication operations of the processes described in conjunction with subsequent figures and otherwise herein. The memory <NUM> of the HSS/UDM <NUM> includes an authentication storage module <NUM> that stores authentication and related data generated or otherwise used during authentication operations.

The processors <NUM> and <NUM> of the respective SLF <NUM> and HSS/UDM <NUM> may comprise, for example, microprocessors, application-specific integrated circuits (ASICs), digital signal processors (DSPs) or other types of processing devices, as well as portions or combinations of such elements.

The memories <NUM> and <NUM> of the respective SLF <NUM> and HSS/UDM <NUM> may be used to store one or more software programs that are executed by the respective processors <NUM> and <NUM> to implement at least a portion of the functionality described herein. For example, authentication operations and other functionality as described in conjunction with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by processors <NUM> and <NUM>.

A given one of the memories <NUM> or <NUM> may therefore be viewed as an example of what is more generally referred to herein as a computer program product or still more generally as a processor-readable storage medium that has executable program code embodied therein. Other examples of processor-readable storage media may include disks or other types of magnetic or optical media, in any combination. Illustrative embodiments can include articles of manufacture comprising such computer program products or other processor-readable storage media.

The memory <NUM> or <NUM> may more particularly comprise, for example, an electronic random access memory (RAM) such as static RAM (SRAM), dynamic RAM (DRAM) or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memories such as flash memory, magnetic RAM (MRAM), phase-change RAM (PC-RAM) or ferroelectric RAM (FRAM). The term "memory" as used herein is intended to be broadly construed, and may additionally or alternatively encompass, for example, a read-only memory (ROM), a disk-based memory, or other type of storage device, as well as portions or combinations of such devices.

The interface circuitries <NUM> and <NUM> of the respective SLF <NUM> and HSS/UDM <NUM> illustratively comprise transceivers or other communication hardware or firmware that allows the associated system elements to communicate with one another in the manner described herein.

It is apparent from <FIG> that SLF <NUM> is configured for communication with HSS/UDM <NUM> and vice-versa via their respective interface circuitries <NUM> and <NUM>. This communication involves SLF <NUM> sending data to the HSS/UDM <NUM>, and the HSS/UDM <NUM> sending data to the SLF <NUM>. However, in alternative embodiments, other network elements may be operatively coupled between the SLF and the HSS/UDM. The term "data" as used herein is intended to be construed broadly, so as to encompass any type of information that may be sent between user equipment and a core network via a base station element including, but not limited to, identity data, authentication data, control data, audio, video, multimedia, etc..

It is to be appreciated that the particular arrangement of components shown in <FIG> is an example only, and numerous alternative configurations may be used in other embodiments. For example, the user equipment and mobility management function can be configured to incorporate additional or alternative components and to support other communication protocols.

Other system elements, such as UE <NUM>, eNB/gNB <NUM>, MME/AMF <NUM>, SGW/SMF <NUM>, and PGW <NUM>, may each also be configured to include components such as a processor, memory and network interface. These elements need not be implemented on separate stand-alone processing platforms, but could instead, for example, represent different functional portions of a single common processing platform. Such a processing platform may additionally comprise at least portions of an eNB/gNB and an associated radio network control function.

<FIG> illustrate message flows and network configurations within which one or more of the above-described privacy indicators can be implemented. These message flows and network configurations are understood to be illustrative embodiments.

<FIG> illustrates a high-level UE authentication procedure <NUM> in LTE using unencrypted IMSI, SLF and multiple HSS, in accordance with one illustrative embodiment.

More particularly, <FIG> shows UE <NUM>, RAN <NUM>, MME <NUM>, SLF <NUM>, HSS1 <NUM>-<NUM> and HSS2 <NUM>-<NUM>. Although only two HSSs are depicted, any number of HSS may be implemented in accordance with the embodiments described herein. In step <NUM> of the UE authentication procedure flow of <FIG>, UE <NUM> sends an attach request (IMSI) through RAN <NUM> to MME <NUM>. In step <NUM>, MME <NUM> then sends an authentication request (IMSI) to SLF <NUM>. In step <NUM>, SLF <NUM> selects an HSS based on IMSI mapping to HSS. In step <NUM>, SLF <NUM> sends the authentication request (IMSI) to the selected HSS, which as indicated in <FIG>, is HSS1 <NUM>-<NUM>. In step <NUM>, HSS1 <NUM>-<NUM> generates authentication vectors (AVs) based on a root key. In step <NUM>, HSS1 <NUM>-<NUM> sends an authentication response (AVs) to SLF <NUM>, and in step <NUM>, SLF <NUM> sends the authentication response (AVs) to MME <NUM>. The authentication response may comprise a random challenge (RAND), an authentication token (AUTN) and a key set identifier (KSI). In step <NUM>, MME <NUM> sends an attach response to UE <NUM> through RAN <NUM>.

<FIG> illustrates a high-level UE authentication procedure <NUM> in <NUM> using encrypted IMSI, SLF and multiple UDM. Performing the IMSI decryption at the SLF instead of the UDM helps to maintain the core authentication functions unchanged, in accordance with one illustrative embodiment. As used herein, the acronym EAP refers to Extensible Authentication Protocol, and the acronym AKA refers to Authentication and Key Agreement.

More particularly, <FIG> shows UE <NUM>, (R)AN <NUM>, AMF <NUM>, SLF <NUM>, AUSF/UDM <NUM>-<NUM> and AUSF/UDM <NUM>-<NUM>. Although only two AUSF/UDMs are depicted, any number of AUSF/UDMs may be implemented in accordance with the embodiments described herein. In step <NUM> of the UE authentication procedure flow of <FIG>, UE <NUM> sends a registration request (encrypted IMSI) through (R)AN <NUM> to AMF <NUM>. Note that by referring to encrypted IMSI, this can refer to the portion of the IMSI that is typically encrypted, e.g., MSIN, or all or other parts of IMSI. In step <NUM>, AMF <NUM> sends an authentication request (encrypted IMSI) to SLF <NUM>. Step <NUM> includes sub-steps 3a and 3b. In step 3a, SLF <NUM> decrypts the encrypted IMSI. In one embodiment, SLF <NUM> decrypts the encrypted IMSI using a provisioned certificate. In step 3b, SLF <NUM> selects an HSS based on IMSI mapping to UDM. In step <NUM>, SLF <NUM> sends the authentication request (IMSI) to the selected UDM, which as indicated in <FIG>, is AUSF/UDM <NUM>-<NUM>. In step <NUM>, AUSF/UDM <NUM>-<NUM> generates authentication vectors (AVs) based on a root key. In step <NUM>, AUSF/UDM <NUM>-<NUM> initiates EAP AKA' authentication or EAP AKA* authentication (AKA* refers to AKA with increased home control). In step <NUM>, AUSF/UDM <NUM>-<NUM> sends an authentication response (AVs) to SLF <NUM>, and in step <NUM>, SLF <NUM> sends the authentication response (AVs) to AMF <NUM>. In step <NUM>, AMF <NUM> sends an authentication request to UE <NUM> through (R)AN <NUM>.

<FIG> illustrates a procedure <NUM> for a mixed core architecture of UDM and HSS to support <NUM> LTE and <NUM> networks, in accordance with one illustrative embodiment. IMSI decryption at SLF helps to manage both cores.

More particularly, <FIG> shows UE <NUM>, gNB <NUM>, AMF/MME <NUM>, SLF <NUM>, AUSF/UDMs <NUM>-<NUM> and <NUM>-<NUM>, and HSS <NUM>. Although only two AUSF/UDMs are depicted, any number of AUSF/UDMs may be implemented in accordance with the embodiments described herein.

In step <NUM> of the procedure of <FIG>, UE <NUM> sends an attach request (encrypted IMSI) through gNB <NUM> to AMF/MME <NUM>. Note that by referring to encrypted IMSI, this can refer to the portion of the IMSI that is typically encrypted, e.g., MSIN, or all or other parts of IMSI. In step <NUM>, AMF/MME <NUM> then sends an authentication request (encrypted IMSI) to SLF <NUM>. Step <NUM> includes sub-steps 3a and 3b. In step 3a, SLF <NUM> decrypts the encrypted IMSI. In one embodiment, SLF <NUM> decrypts the encrypted IMSI using a provisioned certificate. In step 3b, SLF <NUM> selects an HSS based on IMSI mapping to HSS. In step <NUM>, SLF <NUM> sends the authentication request (IMSI) to the selected HSS, HSS <NUM>, through AUSF/UDMs <NUM>-<NUM> and <NUM>-<NUM>. In step <NUM>, HSS <NUM> generates authentication vectors (AVs) based on a root key. In step <NUM>, HSS <NUM> sends an authentication response (AVs) to SLF <NUM> through AUSF/UDMs <NUM>-<NUM> and <NUM>-<NUM>, and in step <NUM>, SLF <NUM> sends the authentication response (AVs) to AMF/MME <NUM>. In step <NUM>, AMF/MME <NUM> sends an attach response to UE <NUM> through gNB <NUM>.

<FIG> illustrates a high-level UE authentication procedure <NUM> in <NUM> using encrypted IMSI, SLF and multiple UDM, in accordance with an illustrative embodiment. Performing the IMSI decryption at the SLF instead of the UDM helps to maintain the core authentication functions unchanged.

More particularly, <FIG> shows UE <NUM>, (R)AN <NUM>, AMF <NUM>, AUSF <NUM>, SLF <NUM>, and UDMs <NUM>-<NUM> and <NUM>-<NUM>. Although only two UDMs are depicted, any number of UDMs may be implemented in accordance with the embodiments described herein. In step <NUM> of the high-level UE authentication procedure flow of <FIG>, UE <NUM> sends a registration request (encrypted IMSI) through (R)AN <NUM> to AMF <NUM>. Note that by referring to encrypted IMSI, this can refer to the portion of the IMSI that is typically encrypted, e.g., MSIN, or all or other parts of IMSI. In step <NUM>, AMF <NUM> then sends an authentication request (encrypted IMSI) to AUSF <NUM>. In step <NUM>, AUSF <NUM> sends the authentication request (encrypted IMSI) to SLF <NUM>. In step 3a, SLF <NUM> decrypts the encrypted IMSI. In one embodiment, SLF <NUM> decrypts the encrypted IMSI using a provisioned certificate. In step 3b, SLF <NUM> selects an HSS based on IMSI mapping to UDM. In step <NUM>, SLF <NUM> sends the authentication request (IMSI) to the selected UDM, which as indicated in <FIG> is UDM <NUM>-<NUM>. In step <NUM>, UDM <NUM>-<NUM> generates authentication vectors (AVs) based on a root key. In step <NUM>, UDM <NUM>-<NUM> sends an authentication response (AVs) to SLF <NUM>, and in step <NUM>, SLF <NUM> sends the authentication response (AVs) to AUSF <NUM>. In step <NUM>, AUSF <NUM> initiates EAP AKA' authentication or EAP AKA* authentication. In step <NUM>, AUSF <NUM> sends the authentication response to AMF <NUM>. In step <NUM>, AMF <NUM> sends an authentication request to UE <NUM> through (R)AN <NUM>.

<FIG> illustrates a procedure <NUM> for a UE accessing the <NUM> network via non-3GPP access (WLAN) and authentication, in accordance with an illustrative embodiment. As used herein, the acronym AN refers access network, the acronym NAI refers to Network Access Identifier and the acronym SUPI refers to the Serialized Unique Product Identifier of the UE.

More particularly, <FIG> shows UE <NUM>, Non 3GPP AN <NUM>, AMF <NUM>, AUSF <NUM> and UDM <NUM>. In step <NUM> of the procedure of <FIG>, UE <NUM> sends a registration request through Non 3GPP AN <NUM> to AMF <NUM>. In step <NUM>, AMF <NUM> sends an authentication request (NAI, [EAP]) to AUSF <NUM>. AUSF <NUM> decides an authentication type (e.g., EAP AKA' authentication or EAP AKA* authentication), and acts as an EAP server and performs EAP AKA' authentication or EAP AKA* authentication. In step <NUM>, security material is retrieved from UDM <NUM> based on the NAI. In step <NUM>, AUSF <NUM> send an authentication response ([EAP]) to AMF <NUM>, which initiates UE Authentication at step <NUM>. As shown, during UE Authentication, AMF <NUM> sends an authentication request (SUPI, [EAP]) to AUSF <NUM>. Several authentication request messages may be required between UE <NUM> and AUSF <NUM> (via AMF <NUM>) depending on the chosen EAP authentication method. Upon successful UE authentication, AUSF <NUM> sends AMF <NUM> an authentication response ([EAP], Key). The Key is a security key that may be used by AMF <NUM> to generate Non-Access Stratum (NAS), Control Plane (CP) and User Plane (UP) specific security keys.

Techniques discussed herein provide one or more privacy indicators for authentication requests in communication systems. For example, such privacy indicators can be controlled (e.g., set) by using one or more bits in an information element or flag that is transmitted to elements of a communication system. Furthermore, methods and mechanisms are provided that address how the home network of user equipment and other elements/functions in the core network (e.g., a server location function) can efficiently process the one or more privacy indicators. Advantageously, the one or more privacy indicators save wasted computing resources in the one or more network configurations in which they are implemented.

It is to be appreciated that the naming of identifiers mentioned herein, e.g., IMSI, etc., are for illustrative purposes only. That is, an identifier for a UE may have different names or acronyms in different protocols and standards for different communication network technologies. As such, none of the specific names or acronyms given to these identifiers herein are intended to limit embodiments in any manner.

As indicated previously, the embodiments are not limited to the LTE or <NUM> context and the disclosed techniques can be adapted in a straightforward manner to a wide variety of other communication system contexts including, but not limited to, other 3GPP systems and non-3GPP systems which employ identity (e.g., IMSI or equivalent) in the identity request process.

The processor, memory, controller and other components of a user equipment or base station element of a communication system as disclosed herein may include well-known circuitry suitably modified to implement at least a portion of the identity request functionality described above.

As mentioned above, embodiments may be implemented in the form of articles of manufacture each comprising one or more software programs that are executed by processing circuitry of user equipment, base stations or other elements of a communication system. Conventional aspects of such circuitry are well known to those skilled in the art and therefore will not be described in detail herein. Also, embodiments may be implemented in one or more ASICS, FPGAs or other types of integrated circuit devices, in any combination. Such integrated circuit devices, as well as portions or combinations thereof, are examples of "circuitry" as that term is used herein. A wide variety of other arrangements of hardware and associated software or firmware may be used in implementing the illustrative embodiments.

Claim 1:
A method comprising:
determining, at an element or function in a wireless communication network, one or more first privacy features supported by the wireless communication network;
sending, from the element or function, to a user equipment (<NUM>) of the wireless communication network, a message comprising an indication of the one or more first privacy features supported by the wireless communication network;
receiving, at the element or function, from the user equipment (<NUM>), a registration request comprising a subscription identifier for a subscriber of the wireless communication network associated with the user equipment (<NUM>), the registration request further comprising one or more second privacy indicators; and
determining one or more second privacy features of the user equipment (<NUM>) for processing the registration request based on the one or more second privacy indicators in the registration request;
wherein the message comprises a System Information Message comprising a Master Information Block or a System Information Block, the System Information Message further comprising one or more first privacy indicators selected based on the determined one or more first privacy features, the one or more first privacy indicators comprising an indication of whether the wireless communication network is configured to handle the privacy-protected subscription identifiers in registration requests,
the one or more first privacy features supported by the wireless communication network comprise an ability of the element or function to handle privacy-protected subscription identifiers, and
the one or more second privacy indicators comprise a field indicating whether the subscription identifier in the registration request is privacy-protected.