WO2025089797A1

WO2025089797A1 - Systems and methods for protecting privacy of the subscriber permanent identity

Info

Publication number: WO2025089797A1
Application number: PCT/KR2024/016203
Authority: WO
Inventors: Rohini RAJENDRAN; Nivedya Parambath Sasi; Rajavelsamy Rajadurai; Varini Gupta; Debabrata Das
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2023-10-23
Filing date: 2024-10-23
Publication date: 2025-05-01
Anticipated expiration: 2026-04-23

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. Embodiments herein disclose a method for handling a privacy of a user equipment (UE). The method includes receiving, by a first network function entity in a roaming hub, an authenticate request message from a second network function entity in a first network domain. Further, the method includes sharing, by the first network function entity in the roaming hub, the authenticate request message to an Authentication Server Function (AUSF) entity in a second network domain. Further, the method includes receiving, by the first network function entity in the roaming hub, an authenticate response message from the AUSF entity in the second network domain based on the authenticate request message. Further, the method includes sharing, by the first network function entity in the roaming hub, the authenticate response message to the second network function entity in the first network domain.

Description

SYSTEMS AND METHODS FOR PROTECTING PRIVACY OF THE SUBSCRIBER PERMANENT IDENTITY

Embodiments disclosed herein relate to wireless communication networks and more particularly to managing security of subscriber identities in wireless communication networks, when a user is roaming.

5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in "Sub 6GHz" bands such as 3.5GHz, but also in "Above 6GHz" bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

Moreover, there has been ongoing standardization in air interface architecture/protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture/service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

Fifth-generation wireless Mobile Roaming Revisited (5GMRR) defines Roaming Hub (RH) in document NG.132-v3.01. The RH provides a set of services to client Mobile Network Operator (MNOs) to facilitate deployment and operation of roaming and interworking services, often in a selectable type set of options. Functions and operations like Roaming Value-Added Services (RVAS), routing, filtering, testing, troubleshooting, billing, invoicing, and dispute management are provided by RHs in 5GS roaming to preserve a range of services currently provided to client MNOs. In roaming ecosystem, the RH is a separate entity that acts like a Visited Public Mobile Network (VPMN) for Home Public Mobile Network (HPMNs), and the HPMN for the VPMNs. Client MNOs (clients of the roaming hub) have one roaming hub agreement with the RH to have roaming relations with participating client MNOs. Hence, to avoid fraud and to ensure consistency, the RH should not manipulate content, format or any information related to traffic transmitted through its solution. Unless manipulation is explicitly required within Global System for Mobile Communications (GSMA) specifications or required by local regulations and laws, or subject to arrangements made between two parties as shown in FIG. 1A.

As per 3rd Generation Partnership Project (3GPP) specification, application layer security needs to be applied, in case of intermediate hops provided with an ability to read and/or modify N32-f traffic. To allow a public roaming hub to work smoothly, an operator can choose a security profile that allows the roaming hub to handle all its administrative tasks, e.g., all Information Element (IEs) necessary for public roaming hub to fulfil its task are sent in clear from an initiating operator network Security Edge Protection Proxy (SEPP) to a receiving operator network SEPP. However, the current 5G system does not appear to serve some of the new set of requirements by the received LS bundle, i.e., support the roaming hub to initialize its own control messages or allow the roaming hub to modify the messages or some of the IE. Specific enhancements to existing solutions may be helpful to support 5G standalone (SA) deployments in parallel with the 3GPP process starting with an SA1 study and following supporting work efforts. 3GPP SA3 interprets the roaming hub architecture proposed by 5GMRR as depicted in FIG. 1B.

The proposed architecture (detailed in S3-232155) calls for an intermediate mini-core proxying user plane and control plane and interacting with visited and the home networks. For example, in the purposes of a "user plane bandwidth control" service. Even without considering security on an inter-operator interconnect, the proposed architecture appears to be incompatible with the current 5G architecture.

Currently 3GPP (SA1) has agreed on a requirement that the 5G system should allow the Roaming services provider to be able to originate and modify messages. In the case of the RH has the capability of initiating its own control plane messages or has the capability to modify the messages between the PLMNs as part of any operation, then there can be possibility of mismatch between the SN ID used in the Home PLMN and the SN ID used in the UE for the key derivation procedure. In such case the authentication fails for inbound roamer UE where an intermediary is present between a HPLMN and a VPLMN.

FIG. 1C illustrates an SN ID mismatch. For example, a home operator for the UE is the first operator and a UE roamed to a second operator in the UE. Herein, as the first operator and the second operator do not have a direct roaming agreement between them, the second operator forwards the UE to an intermediary roaming hub, which is a third operator. The Roaming Hub (RH), which is a third operator and has a roaming agreement with the Home PLMN (i.e., the first Operator), modifies the SN ID from "second" to "third" for the roaming operation and sends the authentication request to the home PLMN. If the UE uses the SN ID as second and the HPLMN (204) uses the SN ID as third operator, the authentication procedure fails, as the keys are different. In such cases, there needs to be a mechanism for the RH to ensure that the home PLMN and the UE uses the same SN ID as the third operator (modified by the RH) for the key derivation. Therefore, there is a need for a secure way of indicating the SN ID to the UDM and to the UE by the RH.

Unified Data Management (UDM) may not be aware of the serving PLMN of the User Equipment (UE) (VPLMN ID or its equivalent) to authorise the UE to allow roaming, as the UDM is aware or have roaming agreement with the Roaming Hub and not with the VPLMN directly (VPLMN may have roaming agreement with the Roaming Hub). In case, the UDM needs to authorise the UE to allow roaming in the VPLMN, then the UDM needs to know the Roaming Hub details in addition to VPLMN ID to authorise. There is a need for a method to let the UDM know the Roaming Hub details.

Access to the network requires subscriber authentication (verification of the subscriber authenticity by the network), which is done by primary authentication mechanism in 5G system. The UE has to send the subscription permanent identifier (SUPI in 5G) to the network, so that the network can identify the subscriber. This permanent subscription identifier was sent in clear until 4G leading to various security and privacy related attacks (tracking of the subscriber, targeted Denial-of-service (DoS) attacks, like so). In 5G, privacy and mitigation of the security attacks are achieved, even before performing the authentication and key agreement (AKA) authentication procedure, by encrypting the SUPI before transmitting using a Home network (HN) public key, which is stored in the Universal Subscriber Identity Module (USIM) or in the Mobile Equipment (ME).

The subscription identifier SUPI contains sensitive subscriber and subscription information, thus it should not be transferred in clear text except for parts necessary for proper functioning of the system, i.e. routing information in the form of Mobile Country Code (MCC) and Mobile Network Code (MNC) to identify the HN. The subscriber privacy enablement is under the control of the home network of the subscriber. So to provide privacy, the UE generates and transmits the Subscription Concealed Identifier (SUCI) using a protection scheme, i.e. one of the Elliptic Curve Integrated Encryption Scheme (ECIES) profiles or null-scheme (as detailed in 3GPP TS 33.501), with the public key that was securely provisioned in control of the home network. The UE constructs the SUCI from the protection scheme identifier, the home network public key identifier, the home network identifier and the protection scheme-output that represents the output of a public key protection scheme. The SUCI will contain routing information in the clear, which is the mobile network and mobile country code of the home network, as well as potentially some routing information within the home network, where the home network is so large that it needs to be segmented. At the home network, de-concealment of the SUPI from SUCI is done by the Subscription Identifier De-concealing Function (SIDF) that is located at the Authentication Credential Repository and Processing Function/Unified Data Management (ARPF/UDM). To meet the Lawful Intercept (LI) requirements along with privacy, binding of SUPI to the derivation of the K_AMFis performed.

FIG. 2A depicts the 5G authentication procedure. The UE (206) sends a registration request (N1 message) to the SEAF/AMF that contains a concealed identifier SUCI or 5G-Globally Unique Temporary UE Identity (5G-GUTI) where 5G-GUTI is a temporary identity assigned by the network during a previous session. On receiving a registration request from the UE, the SEAF/AMF sends an authentication request (Nausf_UEAuthentication_Authenticate Request) message to the AUSF with the serving network name (SNN) and either SUPI, if available and 5G-GUTI is valid, or SUCI. Upon receiving the authentication request, the AUSF checks whether the requesting SEAF/AMF is authorized, if the serving network is authorized, the AUSF sends authentication information request (Nudm_UEAuthentication_Get Request) to UDM/ARPF/SIDF which includes the SUCI or SUPI and the Serving Network Name (SNN). The SIDF is invoked to de-conceal the SUPI from SUCI. Based on SUPI and the subscription data, the UDM/ARPF choose the authentication method to be used and the rest procedure follows as specified in TS 33.501.

Further, when the UE (206) cannot be identified by means of a temporary identity (5G-GUTI), the subscriber identification mechanism may be invoked by the serving network. In particular, it should be used when the serving network cannot retrieve the SUPI based on the 5G-GUTI by which the subscriber identifies itself on the radio path.

FIG. 2B depicts the process of querying the subscriber identity by the AMF. The mechanism is initiated by the AMF that requests the UE (206) to send its SUCI. The UE (206) calculates a fresh SUCI from SUPI using the Home Network Public Key, and respond with Identity Response carrying the SUCI. The UE (206) shall implement a mechanism to limit the frequency at which the UE (206) responds with a fresh SUCI to an Identity Request for a given 5G-GUTI. The AMF may initiate authentication with AUSF to receive SUPI, as specified in FIG. 1A.

If the UE (206) registers for Emergency Services and receives an Identity Request, the UE (206) uses the null-scheme for generating the SUCI in the Identity Response.

With the increasing security challenges in 5G and future generation, a new cyber security model "Zero-Trust" is being adapted in the network. Following the zero-trust model for authentication and authorization of UE (206) in 5G system, in roaming scenario, when the UE (206) initiates the authentication procedure in the serving/visited PLMN (VPLMN) (202), the UE (206) provides the UE (206) identifier SUCI and/or 5G-GUTI and/or GPSI as described in FIGs. 2A and 2B. In a zero-trust network, if a Subscription Permanent Identifier (SUPI) is available in clear text to the Serving/Visited Network, it can potentially lead to security threats, like privacy breach of the subscriber, UE location tracking, targeted cybersecurity attacks, like so. Further, even if 5G-GUTI and/or GPSI is known, it would be easier for the VPLMN (202) to get the SUPI. With the evolution of the roaming architectures (Roaming Hub) and Core network (PLMN hosting Non-Public network (Private network hosted by the PLMN, Edge computing), distributed CN (multi-site CN)), it is not recommended to share the permanent Identity of the subscriber to the network functions (NFs) in the other security domains or in the untrusted roaming network (HPLMN trust Roaming Hub & Roaming Hub trust VPLMN, however, there is no direct trust relationship between the HPLMN (204) and the VPLMN (202), in this case HPLMN (204) need to consider the VPLMN (202) as untrusted network (at least from SUPI/IMSI/permanent Identity perspective)).

The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

The principal object of embodiments herein is to disclose systems and methods for protecting a subscriber's privacy from one or more security threats, during a roaming scenario or when one or more than one Network Functions (NFs) are placed in different security domains.

Another object of embodiments herein is to disclose methods and systems for assigning a one or more new Temporary/pseudonym Identifier to the UE for (International and/or national) roaming scenario and/or when one or more than one NFs are placed in different security domains.

Another object of embodiments herein is to disclose methods and systems for assigning a one or more new temporary/pseudonym identifier every time UE purchases a new (International and/or national) roaming subscription.

Another object of embodiments herein is to disclose methods and systems for mapping by the Home Network (HN), the assigned new temporary/pseudonym identifier with the UE identifier (at least one of SUCI, SUPI, 5G-GUTI, and GPSI) assigned by HPLMN and/or by the VPLMN.

Another object of embodiments herein is to disclose methods and systems for ensuring that the UE uses these newly assigned temporary/pseudonym identifier during roaming and in any circumstances UE or hPLMN should not reveal the UE identifier (SUCI/SUPI, 5G-GUTI, GPSI) assigned by HPLMN, to the VPLMN in roaming scenario and/or to the Non-Public Network.

Another object of embodiments herein is to disclose methods and systems for determining and assigning validity of the assigned temporary/pseudonym identifier.

Another object of embodiments herein is to disclose methods and systems for revoking the assigned temporary/pseudonym identifier when the validity is expired and/or reallocate the temporary/pseudonym identifier when validity is about to expire and/or expired.

Another object of embodiments herein is to disclose methods and systems for maintaining the mapping of the assigned temporary/pseudonym identifier and permanent identifiers of the subscriber with the timestamp, in the HN to support lawful interception/enforcement procedures, as the mapping is required for Charging Data Record (CDR), network surveillance tasks, trace-back actions and error diagnostic research actions by the PLMN/Government agencies.

Another object of embodiments herein is to ensure the same SN ID for key derivation by Roaming Hub (RH).

These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating at least one embodiment and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit thereof, and the embodiments herein include all such modifications.

Embodiments herein disclose a method for handling a privacy of a user equipment (UE). The method includes receiving, by a first network function entity in a roaming hub, an authenticate request message from a second network function entity in a first network domain. Further, the method includes sharing, by the first network function entity in the roaming hub, the authenticate request message to an Authentication Server Function (AUSF) entity in a second network domain. Further, the method includes receiving, by the first network function entity in the roaming hub, an authenticate response message from the AUSF entity in the second network domain based on the authenticate request message. Further, the method includes sharing, by the first network function entity in the roaming hub, the authenticate response message to the second network function entity in the first network domain.

Embodiments herein disclose a method for handling a privacy of a user equipment (UE). The method includes receiving, by at least one of: an UDM entity, a UE authentication get a request message from an AUSF entity. Further, the method includes determining, by at least one of: the UDM entity, whether a roaming hub identifier (RH ID) is included in the authenticate request message. Further, the method includes verifying, by the UDM entity, whether the UE is allowed to access at least one of the roaming hub and the second network domain in response to determining that the roaming hub identifier (RH ID) is included in the authenticate request message. Further, the method includes performing, the UDM entity one of: storing the RH ID in response to determining that the UE is allowed to access at least one of the roaming hub and the second network domain, and sending a reject cause in an authenticate response message in response to determining that the UE is not allowed to access at least one of the roaming hub and the second network domain.

Embodiments herein disclose a method for handling a privacy of a user equipment (UE). The method includes receiving, by an UDM entity, a UE authentication get request message from an AUSF entity. Further, the method includes determining, by the UDM entity, whether a SUCI is received in the UE authentication get request message. Further, the method includes de-concealing, by the UDM entity, a home network assigned SUPI in response to determining that the SUCI is received in the UE authentication get request message. Further, the method includes deriving, by the UDM entity, a temporary SUPI for the UE in roaming. Further, the method includes storing, by the UDM entity a mapping between the home network assigned SUPI and the derived SUPI. Further, the method includes sending, by the UDM entity, a UE authentication get response message to the AUSF entity, wherein the UE authentication get response message comprises the home network assigned SUPI, the derived SUPI and a freshness parameter.

Embodiments herein disclose a method for handling a privacy of a user equipment (UE). The method includes sending, by an AUSF entity, a UE authentication get request message to at least one of: an UDM entity. Further, the method includes receiving, by the AUSF entity, a UE authentication get response message from at least one of: the UDM entity based on the UE authentication get request message, wherein the UE authentication get response message comprises a home network assigned SUPI, a derived temporary SUPI and a freshness parameter. Further, the method includes storing, by the AUSF entity, a mapping between the home network assigned SUPI and the derived temporary SUPI based on the UE authentication get response message. Further, the method includes sending, by the AUSF entity, a UE Authentication message comprising at least one of: the freshness parameter and the derived temporary SUPI to a SEAF entity.

Embodiments herein disclose a first network function entity in a roaming hub. The first network function entity includes a privacy handling controller coupled with a processor and a memory. The privacy handling controller is configured to receive an authenticate request message from a second network function entity in a first network domain. Further, the privacy handling controller is configured to share the authenticate request message to an Authentication Server Function (AUSF) entity in a second network domain. Further, the privacy handling controller is configured to receive an authenticate response message from the AUSF entity in the second network domain based on the authenticate request message. Further, the privacy handling controller is configured to share the authenticate response message to the second network function entity in the first network domain.

Embodiments herein disclose a network entity including a privacy handling controller coupled with a processor and a memory. The privacy handling controller is configured to receive a UE authentication get request message from an AUSF entity. Further, the privacy handling controller is configured to de-conceal a SUCI based on a UE authentication get request message. Further, the privacy handling controller is configured to determine whether a roaming hub identifier (RH ID) is included in the authenticate request message. Further, the privacy handling controller is configured to verify whether the UE is allowed to access at least one of the roaming hub and the second network domain in response to determining that the roaming hub identifier (RH ID) is included in the authenticate request message. In an embodiment, the privacy handling controller is configured to store the RH ID in response to determining that the UE is allowed to access at least one of the roaming hub and the second network domain. In another embodiment, the privacy handling controller is configured to send a reject cause in an authenticate response message in response to determining that the UE is not allowed to access at least one of the roaming hub and the second network domain.

In an embodiment, the network entity comprises a UDM entity.

Embodiments herein disclose a network entity including a privacy handling controller coupled with a processor and a memory. The privacy handling controller is configured to receive a UE authentication get request message from an AUSF entity. Further, the privacy handling controller is configured to determine whether a SUCI is received in the UE authentication get request message. Further, the privacy handling controller is configured to de-conceal a home network assigned SUPI in response to determining that the SUCI is received in the UE authentication get request message. Further, the privacy handling controller is configured to derive a temporary SUPI for the UE in roaming. Further, the privacy handling controller is configured to store a mapping between the home network assigned SUPI and the derived SUPI. Further, the privacy handling controller is configured to send a UE authentication get response message to the AUSF entity, wherein the UE authentication get response message comprises the home network assigned SUPI, the derived SUPI and a freshness parameter.

In an embodiment, the network entity comprises a UDM entity.

Embodiments herein disclose an AUSF entity includes a privacy handling controller coupled with a processor and a memory. The privacy handling controller is configured to send a UE authentication get request message to at least one of: an UDM entity. Further, the privacy handling controller is configured to receive a UE authentication get response message from the UDM entity based on the UE authentication get request message, wherein the UE authentication get response message comprises a home network assigned SUPI, a derived SUPI and a freshness parameter. Further, the privacy handling controller is configured to store a mapping between the home network assigned SUPI and the derived SUPI based on the UE authentication get response message. Further, the privacy handling controller is configured to send a UE Authentication message comprising at least one of: the freshness parameter and the derived SUPI to a SEAF entity.

Embodiments of the present disclosure provides methods and apparatus for protecting a subscriber's privacy from one or more security threats during a roaming scenario or when one or more than one Network Functions (NFs) are placed in different security domains.

Embodiments herein are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the various figures. The embodiments herein will be better understood from the following description with reference to the following illustratory drawings. Embodiments herein are illustrated by way of examples in the accompanying drawings, and in which:

FIG.1A illustrates an existing Roaming hub model and a roaming contractual relations;

FIG. 1B illustrates an existing roaming hub architecture;

FIG. 1C illustrates a SN ID mismatch;

FIG. 2A depicts the 5G authentication procedure, according to existing arts;

FIG. 2B depicts the process of querying the subscriber identity by the AMF, according to existing arts;

FIG. 3 illustrates an exemplary flowchart of a method for indicating modified SN Id by RH to UDM in accordance with the embodiments of the present disclosure;

FIG. 4 illustrates an exemplary flowchart of a method for gNB broadcasting modified SN ID to a UE in accordance with the embodiments of the present disclosure;

FIG. 5 illustrates an exemplary flowchart of a method for Message flow between SEPPs in presence of the RH, in accordance with the embodiments of the present disclosure;

FIG. 6 illustrates an exemplary flowchart of a first intermediary presents between VPLMN and HPLMN, while RH routing authentication request in accordance with the embodiments of the present disclosure; and

FIG. 7 illustrates an exemplary flowchart of a second intermediary presents between VPLMN and the HPLMN, while Authorization of RH and/or VPLMN ID by UDM in accordance with the embodiments of the present disclosure.

FIG. 8 depicts the 5G authentication procedure, wherein a Subscription Roaming Identifier is assigned and the UE using the assigned Subscription Roaming Identifier for authentication in VPLMN/serving PLMN, according to embodiments as disclosed herein;

FIG. 9 depicts a 5G authentication procedure, wherein UDM and UE derives SUPITemp and the UE uses the derived SUPITemp for authentication in VPLMN/serving PLMN, according to embodiments as disclosed herein;

FIG. 10 depicts a 5G authentication procedure, wherein the AUSF and UE derives SUPITemp and the UE using the derived SUPITemp for authentication in VPLMN/serving PLMN, according to embodiments as disclosed herein;

FIG. 11 depicts the 5G authentication procedure, wherein the UDM and UE is (pre)-configured with SUPITemp in an indexed manner and the UE uses the indicated indexed SUPITemp for key derivation in VPLMN/serving PLMN, according to embodiments as disclosed herein;

FIG. 12 depicts the 5G authentication procedure, wherein UDM and UE is (pre)-configured with SUPITemp in indexed manner and the UE uses the indexed SUPITemp for registration and authentication in VPLMN/serving PLMN, according to embodiments as disclosed herein;

FIG. 13 depicts the process of initiating an authentication procedure including SUPITemp and selection of authentication method, when the UE is in VPLMN/serving PLMN, according to embodiments as disclosed herein;

FIG. 14 depicts the UE Parameter Update (UPU)/Steering of Roaming (SoR) procedure, wherein the UDM and UE are (pre)-configured with SUPITemp in an indexed manner and the UE uses the indexed SUPITemp for registration and authentication in VPLMN/serving PLMN, according to embodiments as disclosed herein;

FIG. 15 depicts the 5G NAS procedure, wherein the UE receives the SUPITemp and uses the received SUPITemp for registration and authentication in VPLMN/serving PLMN, according to embodiments as disclosed herein;

FIG. 16 depicts an example 5G NAS procedure, where the UE receives the SUPITemp in NAS SMC and uses the received SUPITemp for registration and authentication in VPLMN/serving PLMN, according to embodiments as disclosed herein; and

FIG. 17 depicts an example of Key Derivation Function (KDF) inputs, according to embodiments as disclosed herein, according to embodiments as disclosed herein.

FIG. 18 is a flow chart illustrating a method, implemented by the first network function entity in the roaming hub, for handling the privacy of the UE, according to embodiments as disclosed herein.

FIG. 19 is a flow chart illustrating a method, implemented by the UDM entity, an ARPF entity, and a SIDF entity, for handling the privacy of the UE, according to embodiments as disclosed herein.

FIG. 20 is a flow chart illustrating a method, implemented by the UDM entity, an ARPF entity, and a SIDF entity, for handling the privacy of the UE, according to embodiments as disclosed herein.

FIG. 21 is a flow chart illustrating a method, implemented by the AUSF entity, for handling the privacy of the UE, according to embodiments as disclosed herein;

FIG. 22 shows various hardware components of the first network function entity, according to embodiments as disclosed herein;

FIG. 23 shows various hardware components of the network entity, according to embodiments as disclosed herein; and

FIG. 24 shows various hardware components of the AUSF entity, according to embodiments as disclosed herein.

The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

The words/phrases "exemplary", "example", "illustration", "in an instance", "and the like", "and so on", "etc.", "etcetera", "e.g.,", "i.e.," are merely used herein to mean "serving as an example, instance, or illustration. Any embodiment or implementation of the present subject matter described herein using the words/phrases "exemplary", "example", "illustration", "in an instance", "and the like", "and so on", "etc.", "etcetera", "e.g.," , "i.e.," is not necessarily to be construed as preferred or advantageous over other embodiments.

Embodiments herein may be described and illustrated in terms of blocks which carry out a described function or functions.　These blocks, which may be referred to herein as managers, units, modules, hardware components or the like, are physically implemented by analog and/or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits and the like, and may optionally be driven by a firmware. The circuits may, for example, be embodied in one or more semiconductor chips, or on substrate supports such as printed circuit boards and the like.　The circuits constituting a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware to perform some functions of the block and a processor to perform other functions of the block.　Each block of the embodiments may be physically separated into two or more interacting and discrete blocks without departing from the scope of the disclosure.　Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the disclosure.

It should be noted that elements in the drawings are illustrated for the purposes of this description and ease of understanding and may not have necessarily been drawn to scale. For example, the flowcharts/sequence diagrams illustrate the method in terms of the steps required for understanding of aspects of the embodiments as disclosed herein. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the present embodiments so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Furthermore, in terms of the system, one or more components/modules which comprise the system may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the present embodiments so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

The accompanying drawings are used to help easily understand various technical features and it should be understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the present disclosure should be construed to extend to any modifications, equivalents, and substitutes in addition to those which are particularly set out in the accompanying drawings and the corresponding description. Usage of words such as first, second, third etc., to describe components/elements/steps is for the purposes of this description and should not be construed as sequential ordering/placement/occurrence unless specified otherwise.

The embodiments herein achieve systems and methods for protecting a subscriber's privacy from one or more security threats, during a roaming scenario or when one or more than one NFs are placed in different security domains.

Referring now to the drawings, and more particularly to FIGS. 3 through 24, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.

FIG. 3 illustrates an exemplary flowchart of a method for indicating modified SN Id by RH to UDM in accordance with the embodiments of the present disclosure The method includes several steps as described below.

In zeroth step, a UE (206) sends registration request message to the VPLMN (202) and the Access & Mobility Management Function (AMF) (V-AMF)/SEAF (N1 message). The message contains either Subscription Concealed Identifier (SUCI) or 5G- Globally Unique Temporary Identity (GUTI).

Further, in first step, as the VPLMN (202) does not have a direct roaming agreement with home PLMN, upon receiving a registration request from the UE, SEAF/AMF in the VPLMN (202) sends a Nausf UE Authentication Authenticate Request message to an NF in Rh. The NF acts as Authentication Server Function (AUSF) for AMF/SEAF in the VPLMN (202), while it acts as AMF/SEAF for the AUSF in the HPLMN (204). The message includes serving network name (SNN) and either Subscription Permanent Identifier (SUPI), if available and 5G-GUTI is valid, or SUCI. Also, the SNN is a concatenation of service code and the Serving Network Identity (SN Id) in which the UE (206) is currently roamed (e.g. 5G:mnc012.mcc404.3gppnetwork.org) i.e., the SN ID is the PLMN ID of the VPLMN (202) where the UE (206) is currently roaming.

Further, in the second step, upon receiving the authentication request, the AUSF in the RH checks whether the requesting SEAF is authorized to use the SNN based on the roaming agreement. In case of allowing, the RH may decide to forward the authentication request message to the Home PLMN by checking the roaming agreement. Due to the operational requirement and/or need, the RH may modify the SN ID received in the Authentication request message from the SEAF/AMF in the VPLMN (202) to its own SN ID. In an embodiment, the RH performs the mapping of SN ID 1 to SN ID 2 (SN ID1: SN ID2). In another embodiment, the RH performs the concatenation of SN IDs i.e., SN ID = SN ID1||SN ID2. In another embodiment, the RH may act as a home PLMN for the requesting VPLMN (202).

Further, in the third step, the RH sends an SN ID change notification message to the home PLMN (UDM). The message includes SUCI/SUPI and a mapping of the associated SN ID to RH's own SN ID (i.e., SN ID1: SN ID2). Upon receiving the SN ID change notification message from the RH, the UDM stores the modified SN ID and/or the mapping of the associated SN ID to the RHs SN ID (i.e., SN ID1: SN ID2) with the corresponding SUCI/SUPI in its database to use later for the input to Key Derivation Function (KDF) for security key derivation procedure.

In an embodiment, after receiving the Nausf UE Authentication Authenticate Request message from the VPLMN (202), no modification is performed to the existing IE. Whereas the RH adds an additional IE to the received payload message without modifying the existing IE and forwards the request message to a Broad Forward Security Edge Protection Proxy (SEPP) of HPMLMN. This additionally added IE indicates the SN ID of the RH associated with the SN ID of the VPLMN (202), where the UE (206) is currently camped on (i.e., SN ID1: SN ID 2). In an embodiment, the NF may be for e.g., AUSF, AMF, SMF and any other possible entities which adds a new IE to indicate the SN ID change to the cSEPP of the HPLMN (204).

In an embodiment, the Roaming Hub adds a modification instruction to the received PRINS message indicating that it intends to modify the Serving Network Name to its own ID in the payload received from VPLMN SEPP.

In an embodiment, the message forwarded from RH pSEPP to HPLMN cSEPP is represented as follows:

Payload message

SN ID1

SN ID2

In another embodiment, the message forwarded from RH pSEPP to HPLMN cSEPP is represented as follows:

3gpp-Sbi-Originating-Network-Id

SN ID2

Original Message		[SN ID2]
Protected Payload	Clear Text Encapsulated Message

In another embodiment, JavaScript Object Notation (JSON) representation of a reformatted HTTP message is reused as described in TS 29.573, except the addition (or modification instruction) of the SN ID of the RH.

In an embodiment, if the sending NF or the Service Communication Proxy (SCP) inserts 3gpp-Sbi-Originating-Network-Id header in signalling message (service/subscription request or notification message), the sending SEPP may compare the PLMN ID in the 3gpp-Sbi-Originating-Network-Id header in the received signalling message with the PLMN ID(s) that the sending SEPP represents by its certificate as described in TS 33.501. Additionally, the message adds an IE to indicate the SN ID of the RH (to be used for further key derivation).

In case of Protocol for N32 Interconnect Security (PRINS) is used by a roaming hub, the roaming hub may use the same N32-f connection between the roaming hub and the adjacent PLMNs for the PLMNs accessed via the roaming hub as specified in clause 5.9.3 of TS 33.501. In that case, the PRINS may provide an origin authentication and the originating PLMN_ID and additionally the association of the SN IDs (i.e., SN ID1: SN ID2) and/or the SN ID of the RH.

Further, in fourth step, the RH sends the Nausf UE Authentication Authenticate Request message to the Home AUSF via the SEPP. The message includes the serving network name (SNN) and either SUPI, if available and 5G-GUTI is valid, or SUCI. The serving network name includes the modified SN ID (i.e., SN ID of the RH).

Further, in fifth step, upon receiving the authenticate request, the authentication procedure follows as described in TS 33.501. The AUSF sends the Nudm_UEAuthentication_Get Request to the UDM by including the following information:

▶ SUCI or SUPI;

▶ the serving network name (includes the SN ID of the RH);

▶ if received from SEAF, Disaster Roaming service indication.

In an embodiment, AUSF and/or AMF and/or any other possible entities may send the modified SN ID (i.e., the SN ID of the RH) to the cSEPP of the Home PLMN. In case of the roaming hub needs to originate a message rather than modify it, the originating roaming hub inserts an empty reformatted Data IE, and patches may be based on an empty reformatted Data JSON element, and this added empty reformatted Data IE may be reply protected.

In case if the roaming hub needs to modify the SN Id, the originating roaming hub inserts a reformatted Data IE that includes the SN Id of the originating Roaming Hub, and the patches may be based on the newly added reformatted Data IE, and this added empty reformatted Data IE may be reply protected.

Further, in the sixth step, upon reception of the Nudm_UEAuthentication_Get Request, the UDM invokes SIDF if a SUCI is received. SIDF may de-conceal SUCI to gain SUPI before UDM may process the request. Based on SUPI, the UDM/ARPF may choose the authentication method as described in TS 33.501.

Further, in the seventh step, in case the selected authentication method is Extensible Authentication Protocol EAP AKA', then authentication procedure is followed as discussed in RFC 5448 except the authentication vector (AV) derivation at the UDM/ARPF. The UDM/ARPF first generates an AV with AMF separation bit = 1 and generates CK' and IK' from CK, IK and SNN.

In case the selected authentication method is 5G AKA, then the UDM/ARPF derives the KAUSF from CK, IK and SNN and generates the 5G Home Environment AV (5G HE AV) where the 5G HE AV contains the RAND, AUTN, XRES*, and the root key KAUSF. 5G HE AV (Authentication Vector) is sent to the AUSF in the Nudm_UEAuthentication_Get Response message.

CK' and IK' derivation function: While deriving CK' and IK' the KDF of TS 33.402 clause A.2 is used with the following exception as described in TS 33.501: the serving network name (specified in clause 6.1.1.4) may be used as the value of access network identity (P0). The serving network name is the concatenation of the service code and the SN Id (SN Id of the RH).

KAUSF derivation function: The procedure applies to 5G AKA only. While deriving a K_AUSF from CK, IK and the serving network name when producing authentication vectors, and when the UE (206) computes KAUSF during 5G AKA, the following parameters may be used to form the input S to the KDF:

▶ FC = 0x6A;

▶ P0 = serving network name (includes the SN Id of the RH);

▶ L0 = length of the serving network name (variable length as specified in 24.501 [35]);

▶ P1 = SQN

AK,

▶ L1 = length of SQN

AK (i.e., 0x00 0x06).

The XOR of the Sequence Number (SQN) and the Anonymity Key (AK) is sent to the UE (206) as a part of the Authentication Token (AUTN), see TS 33.102. If AK is not used, AK may be treated in accordance with TS 33.102, i.e., as 000...0. The serving network name may be constructed as specified in clause 6.1.1.4 with the exception that instead of using the SN Id of the PLMN where the UE (206) is camped, it is preferred to use the SN Id of the RH (roaming Hub). The KEY input KEY be equal to the concatenation CK || IK of CK and IK. The AUSF derives the KSEAF (anchor key) from K_AUSF.

Further, in the eighth step, the UDM/ARPF subsequently sends this transformed AV (RAND, AUTN, XRES, CK', IK') to the AUSF with an indication that the AV is to be used for EAP-AKA'. Further, the AUSF uses the received AV from the UDM to generate/derive the K_AUSF root key at the network side. The AUSF stores the K_AUSF and XRES* until expiry.

Further, in ninth step, upon performing the root key generation, the AUSF sends the Nausf_UEAuthentication_Authenticate Request to the RH (AUSF) via the SEPP. This message includes the Authentication vectors and the

Further, in tenth step, the AUSF (in the RH) sends challenge message to the SEAF (in the VPLMN (202)) in a Nausf UE Authentication Authenticate Response message with K_SEAF, AUTN and RAND. In case of 5G AKA HXRES* is also sent. In an embodiment, the AUSF (in the RH) also sends the SN ID of the roaming Hub in the challenge message additionally to the K_SEAF, AUTN and RAND.

RES* and XRES* derivation function: The derivation of RES* and XRES is as described in TS 33.501 with the exception that the SN Id used is the SN Id of the RH and not the SN Id of the VPLMN (202) where the UE (206) is currently camped on. The SN Id is the PLMN ID of the roaming hub who is provider the roaming subscription to the inbound roamer UE.

When deriving RES* from RES, RAND, and serving network name in the UE (206) and when deriving XRES* from XRES, RAND, and the serving network name in the ARPF, the following parameters may be used to form the input S to the KDF.

o FC = 0x6B,

o P0 = serving network name (including the SN Id of the RH),

o L0 = length of the serving network name (variable length as specified in 24.501 [35]),

o P1 = RAND,

o L1 = length of RAND (i.e., 0x00 0x10),

o P2 = RES or XRES,

o L2 = length RES or XRES (i.e., variable length between 0x00 0x04 and 0x00 0x10).

o The input key may be equal to the concatenation CK || IK of CK and IK.

The serving network name may be constructed as specified in clause 6.1.1.4.

The (X)RES* is identified with the 128 least significant bits of the output of the KDF.

FIG. 4 illustrates an exemplary flowchart of a method for gNB broadcasting modified SN ID to the UE (206), in accordance with the embodiments of the present disclosure.

In zeroth step, the AMF, and the Next Generation Node B (gNB) performs the NG SETUP REQUEST RESPONSE procedure as specified in clause 8.7.1 in TS 38.413. The NG-RAN node initiates the procedure by sending an NG SETUP REQUEST message including the appropriate data to the AMF. The AMF responds with an NG SETUP RESPONSE message including the appropriate data. Additionally in the NG SETUP RESPONSE message, the AMF sends the SN ID (SN ID of the RH) to the UE. In another embodiment, the AMF sends the SN ID of the RH (to be broadcasted to the UE (206) for further key derivation) in the INITIAL CONTEXT SETUP message and gNB stores the received SN ID from the AMF. In another embodiment, OAM configures the supported PLMN Id (which includes the SN Id, if roaming hub is supported) in the gNB.

Further, in the first step, in case of the UE (206) acquires a MIB or a SIB1 or an SI message in a serving cell as described in clause 5.2.2.3 of TS 38.331, the UE (206) may store the PLMN-Identity included in the PLMN-Identity Info List received from the gNB. During the broadcast, the gNB includes the PLMN ID as the SN ID of the RH received from the AMF. In another embodiment, the PLMN-Identity Info List IE in SIB1 as specified in TS 38.331 includes the SN Id of the Roaming Hub. The PLMN identities and associated information contained in this IE is provided in the same order as broadcast in SIB1.This field is used to transfer plmn-Identity Info List in SIB1 of the SCell and the UE (206) uses this field to translate the plmn-Index in MCCH of SCell to PLMN Identity as specified in TS 38.331.

Further, in second step, the AMF/SEAF initiates the Authentication request message to the RH as detailed in first method of this disclosure.

Further, in third step, upon receiving the Authentication Response message from the home PLMN, the RH sends the Authentication response message to the AMF/SEAF as detailed in the first method of this disclosure.

Further, in fourth step, steps four to seven are as followed as described in TS 33.501, with the following exception: instead of using the SN ID of the VPLMN (SN ID1), the SN ID of the RH (SN ID2) received during SIB broadcast by the gNB is used for further key derivation at the UE.

RES* and XRES* derivation function

While deriving RES* from RES, RAND, and serving network name in the UE (206) and when deriving XRES* from XRES, RAND, and the serving network name in the ARPF, the following parameters may be used to form the input S to the KDF.

o FC = 0x6B,

o P0 = serving network name (SN ID as the RH PLMN ID),

o L0 = length of the serving network name (variable length as specified in 24.501),

o P1 = RAND,

o L1 = length of RAND (i.e., 0x00 0x10),

o P2 = RES or XRES,

The input key may be equal to the concatenation CK || IK of CK and IK. The serving network name may be constructed as specified in clause 6.1.1.4. of TS 33.501. The serving network name is the concatenation of a service code and the SN Id (SN ID of the RH) with a separation character ":" such that the service code prepends the SN Id. The (X)RES* is identified with the 128 least significant bits of the output of the KDF as defined in TS 33.501.

FIG. 5 illustrates an exemplary flowchart of a method for Message flow between SEPPs in presence of the RH, in accordance with the embodiments of the present disclosure.

In zeroth step, the UDM is configured with the list of PLMN Ids the Roaming Hub can support. The UDM also updates this information to the AUSF and AUSF stores the mapping of SN ID in its database.

Further, in first step, the VPLMN (202) may not have a direct roaming agreement with the home PLMN, upon receiving a registration request from the UE (206), the SEAF/AMF in the VPLMN (202) sends a Nausf UE Authentication Authenticate Request message to the Rh AUSF. The message includes the 3gpp-Sbi-Intermediary-Network-Id and either SUPI, if available and 5G-GUTI is valid, or SUCI.

Further, in second step, upon receiving the authentication request, the AUSF and/or AUSF-P (AUSF proxy) in the RH checks whether the requesting SEAF is authorized to use the SNN based on the roaming agreement. If allowed, the RH decides to send the authentication request message to the Home PLMN by checking the roaming agreement. Due to the operational requirement and/or needs, the RH modifies the SN ID received in the Authentication request message from the SEAF/AMF to its own SN ID. The received 3gpp-Sbi-Originating-Network-Id part of the header is modified by the RH as 3gpp-Sbi-Intermediary-Network-Id by adding the Roaming Hub's SN Id. In an embodiment, the RH decrypts JWE encrypted 3gpp-Sbi-Originating-Network-Id header using its private key and perform the header modification and/or new reformatted IE addition.

Further, in third step, the AUSF and/or AUSF-P (AUSF proxy) sends/forwards the Nausf_UEAuthentication_Get Request to the AUSF in the HPLMN (204). This message includes the SUPI/SUCI and the 3gpp-Sbi-Intermediary-Network-Id (the Roaming Hubs ID).

Further, in the fourth step, the AUSF in the HPLMN (204) sends the Nudm_UEAuthentication_Get Request to the UDM in the HPLMN (204). This message includes the SUPI/SUCI and the 3gpp-Sbi-Intermediary-Network-Id (the Roaming hubs ID). The UDM verifies the received SN ID matching with the supporting SN ID lists of the RH received in step 0.

Further, in the fifth step, upon the verification of SN ID is successful, the security procedure may be performed as defined in TS 33.501 except that the SN ID of the roaming hub is used in the key derivation procedure instead of SN ID of the VPLMN (202). In an embodiment, the IPX and/or Roaming hub inserts the header 3gpp-Sbi-Intermediary-Network-Id by adding the PLMN ID and/or SN ID of the Roaming Hub additional to the PLMN ID of the VPLMN (202) in the header.

Two intermediary presents between VPLMN (202) and the HPLMN (204), in accordance with the embodiments of the present disclosure. In case of two intermediary present between VPLMN (202) and the HPLMN (204), that the 'left' Client operator has an agreement with its adjacent 'left' RH provider about the set of roaming partners being served as defined in NG.132-v3.0-1. In the case of 2 RHs in cascade, by default the Client operator has no insight which remote 'right' RH provider is used by its adjacent RH provider for which roaming partners. However, per contract the Client operator may agree with its RH provider about the use of a specific remote RH provider for specific roaming partners.

FIG. 6 illustrates an exemplary flowchart of a first intermediary presents between the VPLMN (202) and the HPLMN (204), while RH routing authentication request in accordance with the embodiments of the present disclosure. The method includes several steps as described below.

In first step, upon receiving a registration request from the UE, the SEAF/AMF in the VPLMN (202) sends an Nausf UE Authentication Authenticate Request message to the Rh AUSF. The message includes the Serving Network Name (SNN) and either SUPI, if available and 5G-GUTI is valid, or SUCI. The SNN is a concatenation of service code and the Serving Network Identity (SN Id) in which the UE (206) is currently roamed into.

In second step, the roaming hub (RH 1) decides to route the Authentication request from VPLMN-1 AMF/SEAF to RH 2 due to some operational needs and/or based on the local configuration and/or based on the roaming agreements with the operators. In an embodiment, between the AUSF proxies of RHs the messages are routed and forwarded.

In third step, the RH 1 sends the routing indication to the RH 2 including the SN ID, UE ID, and IP address.

In fourth step, the RH 1 re-directs the Authentication request to the RH 2. In between the RHs, a TLS and/or PRINS mechanism/protocols may be used. In an embodiment, the Authentication, Authorization and Accounting (AAA) requester in the RH 1 requests the AAA server in the RH2 to perform the authentication procedure for the inbound roamer UE. In another embodiment, an open interconnect is used between the VPLMN (202) and the HPLMN (204) and the routing may be performed.

In fifth step, the RH 2 has a roaming agreement with the Home PLMN and the RH 2 sends the authentication request to the AUSF in the home PLMN. The RH sends the SN change indication to the Home PLMN. This message includes the SN id (Serving network ID) of the RH2 and not the SN ID of the VPLMN (202) in which the UE (206) is camped on. The SN ID is further used during the key derivations for authenticating the UE. By sending this indication, the RH 2 verifies that the same SN ID is used by home PLMN and the roaming UE.

In sixth step, the authentication procedures and key derivation follows between the AUSF/UDM in the home PLMN, and the UE (206) as described in the

alternative

1 and 2 of the present disclosure.

FIG. 7 illustrates an exemplary flowchart of a second intermediary presents between the VPLMN (202) and the HPLMN (204), while Authorization of RH and/or VPLMN ID by UDM in accordance with the embodiments of the present disclosure. The SEPP/SCP/NFc (for example, NEF/AMF/SEAF) provides the Roaming Hub details to the AUSF in the HPLMN (204) and HPLMN AUSF provides the Roaming Hub details to the UDM. On receiving the Nudm_UEAuthentication Get request, with the Roaming hub details, the UDM checks whether the roaming hub is allowed to serve the UE (maybe in addition to the VPLMN authorization check). The method includes several steps as described below.

In first step, the UE (206) sends initial NAS (Registration) request to the network via NG-RAN. The NG-RAN sends the request to the serving network's AMF.

Further, in second step, the AMF/SEAF in the serving network (i.e., VPLMN (202)) initiates the primary authentication by sending in Nausf_UEAuthentication_Authenticate request message to the AUSF in the HPLMN (204) via one or more Roaming Intermediaries (or Roaming Hubs). The NFc (for example, AMF/SEAF/SCP/SEPP/NEF) in the VPLMN (202) may include along with this request, the Roaming Hub name (SN ID#2) identifier(ies). Roaming Intermediaries/Hubs is an entity that provides roaming related services between the PLMNs/MNOs.

In an embodiment, the sending NF (for example, NEF/AMF/SCF/SEAF/SEPP) of the VPLMN (202) includes the Roaming Hub PLMN ID in the 3gpp-Sbi-Originating-Network-Id header and/or in the 3gpp-Sbi-RH-Network-Id header along with the Nausf_UEAuthentication_Authenticate request message. In an embodiment, the NF of the VPLMN (202) identifies the Roaming hub (1st or 2nd intermediary) based on the local configuration and/or routing information for the UE's HPLMN.

In an embodiment, the NF (for example, NEF/AMF/SCF/SEAF/SEPP) of the RH includes the Roaming Hub PLMN ID in the 3gpp-Sbi-Originating-Network-Id header and/or in the 3gpp-Sbi-RH-Network-Id header along with the Nausf_UEAuthentication_Authenticate request message before sending/forwarding it to the HPLMN (204).

In an embodiment, if an NF (for example, NEF/AMF/SCF/SEAF/SEPP) of the VPLMN (202) and/or RH supports multiple PLMN-IDs, which includes Roaming Hub IDs also, then the sending NF includes the Roaming Hub PLMN ID in the 3gpp-Sbi-Originating-Network-Id header on behalf of the roaming hub which the message is sent. The NF identifies the Roaming hub (1st or 2nd intermediary) based on the local configuration and/or routing information for the UE's HPLMN.

Further, in third step, in case the RH identifier along with the Nausf_UE Authentication_Authenticate request received from SEAF/AMF/NEF/SEPP/SCP, then the AUSF includes the RH identifier along with the Nudm_UEAuthentication_Get Request message to the UDM. The SEPP in the HPLMN (204) includes the RH identifier along with the Nausf_UEAuthentication_Authenticate request received from the SEPP of VPLMN (202)/Roaming Hub/ IPx provider.

Further, in fourth step, UDM de-conceals SUCI, and if the RH Identifier is included in the Nudm_UEAuthentication_Get Request message, then it verifies whether the UE (SUPI) is allowed to access the RH and/or the VPLMN (202). If the UE (206) is allowed to access the RH and/or the VPLMN (202), then the UDM stores the RH ID and proceed further with the procedures as specified in TS 33.501.

Further, in fifth step, in case, the UE (206) is not allowed to access the RH and/or the VPLMN (202), then the UDM includes "Reject" in Nudm_UEAuthentication_Get Response message to AUSF, and does not proceed further in authentication procedure, for example, selection of authentication method and generation of authentication vector, like so.

Further, in sixth step, in case there is "Reject" in Nudm_UEAuthentication_Get Response message from UDM, then the AUSF forwards the same to the AMF/SEAF in Nausf_UEAuthentication_Authenticate response message.

Further, in seventh step, in case there is "Reject" in the Nausf_UE Authentication_Authenticate response message from the AUSF, then the AMF rejects the UE's registration request by sending the Registration Reject message with an appropriate cause value, to the UE.

In an embodiment, the steps can also be performed as follows:

▶ During N32c connection setup, the SEPPs in the VPLMN (202) and the HPLMN (204) negotiate the parameters that can be modified and/or added by the Intermediaries. The list of parameters includes the Serving Network Name.

▶ -AMF/SEAF in the VPLMN (202) sends Nausf_UEAuthentication_Authenticate request to AUSF in the HPLMN (204). The request includes the SUCI/SUPI of the UE, and the Serving Network Name. The request is routed via the Roaming Hub.

▶ 2. An NF in Roaming Hub acts like AUSF to AMF/SEAF in the VPLMN (202) and like AMF/SEAF to AUSF in the HPLMN (204). The NF adds a new HTTP Header or JSON IE (e.g. 3gpp-Intermediary-ServingNetworkName) in the request and sends Nausf_UEAuthentication_Authenticate request to AUSF in the HPLMN (204).

▶ 3. The AUSF in HPLMN (204), upon receiving the request, determines if the NF in Roaming Hub is allowed to use the Serving Network Name as present in the request. If the request contains a new HTTP Header or JSON IE (e.g. 3gpp-Intermediary-ServingNetworkName), this value contained in this new header/IE is used to perform the validation.

▶ 4. If allowed, the AUSF proceeds with Authentication Vector retrieval from the UDM. The request contains the original Serving Network Name sent by the AMF/SEAF in the VPLMN (202), as well as the new IE/header inserted by the Roaming Hub. The information inserted by the Roaming Hub is only used by the UDM to validate roaming agreements. Else, it uses the original Serving Network Name in key generation etc.

▶ 5. Procedure continues as defined in 3GPP TS 33.501.

The temporary/pseudonym identifier (SUPI_Temp) or the Subscription temporary Identifier (SUTI) or Subscription Roaming Identifier or network access GPSI, is a temporary identifier used in the 3GPP Systems to identify a mobile device/User Equipment (UE) and its associated subscription information. SUTI/ SUPI_Temp is used instead of the IMSI to ensure the privacy of the mobile subscriber, during roaming scenario and/or when one or more than one NFs are placed in different security domains. The Home Network assigns the SUTI/ SUPI_Temp to the UE (206) or SUTI/ SUPI_Tempis derived/generated by the HN and the UE, which is then used to identify the UE (206) for the duration of the connection or until its assigned lifetime expires.

Embodiments herein disclose systems and methods for protecting a subscriber's privacy from one or more security threats, during a roaming scenario or when one or more than one NFs are placed in different security domains.

Embodiments herein disclose methods and systems for assigning a new Temporary/pseudonym Identifier to the UE (206) for (International and/or national) roaming scenario and/or when one or more than one NFs are placed in different security domains.

Embodiments herein disclose methods and systems for assigning a new temporary/pseudonym identifier every time UE (206) purchases a new (International and/or national) roaming subscription.

Embodiments herein disclose methods and systems for mapping by the HN, the assigned new temporary/pseudonym identifier with the UE identifier (at least one of: SUCI, SUPI, 5G-GUTI, GPSI, and the like) assigned by the HPLMN (204) and/or the VPLMN (202).

Embodiments herein disclose methods and systems for ensuring that the UE (206) uses these newly assigned temporary/pseudonym identifier during roaming and in any circumstances the UE (206) or the HPLMN (204) should not reveal the permanent identifier of the UE (SUPI), to the VPLMN (202) in the roaming scenario and/or to the NPN and/or to the NFs in different security domain.

Embodiments herein disclose methods and systems for determining and assigning validity of the assigned temporary/pseudonym identifier.

Embodiments herein disclose methods and systems for revoking the assigned temporary/pseudonym identifier when the validity is expired and/or reallocate the temporary/pseudonym identifier when validity is about to expire.

Embodiments herein disclose methods and systems for maintaining the mapping of the assigned temporary/pseudonym identifier and permanent identifiers of the subscriber with the timestamp, in the HN to support lawful interception/enforcement procedures, as the mapping is required for Charging Data Record (CDR), network surveillance tasks, trace-back actions and error diagnostic research actions by the PLMN/Government agencies.

Procedure to provide SUPI_Temp temporary/pseudonym identifier to the UE:

FIG. 8 depicts the 5G authentication procedure, wherein a Subscription Roaming Identifier (temporary/pseudonym subscriber identifier, SUPITemp or SUTI (Subscription Temporary Identifier) or network access GPSI) is assigned and the UE (206) using the assigned Subscription Roaming Identifier for authentication in the VPLMN (202)/serving PLMN. In an embodiment herein, the network/MNO/HPLMN (204) assigns a temporary/pseudonym subscriber identifier to the UE. The UE (206) uses the SUPITemp temporary/pseudonym subscriber identifier during registration and authentication in roaming scenario or accessing the NPN or Edge network. In step 1, consider that the UE (206) is in roaming in the visited PLMN and/or seeking NPN network access. The UE (206) has the subscription for roaming in visited PLMN and/or access to the NPN.

In steps 2 & 3, the UDM is in possession with the subscription data of the UE. When the customer UE (206) activates its roaming subscription and/or when try to access the NPN, the HN UDM assigns a temporary/pseudonym subscriber identifier i.e., Subscriber Roaming Identifier (SUPI_Temp) to the UE. In an embodiment herein, the HN provisions the temporary/pseudonym subscriber identifier to the UE (206) using the Over-the-Air (OTA) procedure. In an embodiment herein, the UICC/USIM is configured with one or more than one temporary/pseudonym subscriber identifier(s).

In step 4, when the UE (206) initiates registration request from the VPLMN (202) and/or from NPN and/or from any PLMN other than HPLMN, it determines the temporary/pseudonym subscriber identifier, generates the SUCI of the determined temporary/pseudonym subscriber identifier (concealed [SUPI_Temp]) and includes it in the Registration Request message.

In an embodiment, the UE (206) always uses GPSI for initial registration procedure when in roaming.

In step 5, the SEAF/AMF may initiate an authentication with the UE (206) during any procedure establishing a signalling connection with the UE, according to the SEAF/AMF's policy. The SEAF/AMF invokes the Nausf_UEAuthentication service by sending a Nausf_UEAuthentication_Authenticate Request message to the AUSF whenever the SEAF/AMF wishes to initiate an authentication. The Nausf_UEAuthentication_Authenticate Request message includes/contains: Concealed[SUPI_Temp] along with other possible parameters.

In an embodiment herein, USIM/ME uses same public/private key pair as used for SUPI protection and de-concealment of the SUCI for concealment and de-concelament of SUPI_Temp.

The SEAF/AMF includes the concealed[SUPI_Temp] in Nausf_UEAuthentication_Authenticate Request along with other required parameters.

Upon receiving the Nausf_UEAuthentication_Authenticate Request message, the AUSF check that the requesting SEAF/AMF in the serving network is authorized and forwards the request to the UDM.

In step 6, the Nudm_UEAuthentication_Get Request sent from AUSF to UDM includes the concealed[SUPI_Temp] along with the other required parameters. In step 7, on receiving the Nudm_UEAuthentication_Get Request, the UDM shall invoke SIDF if a SUCI is received. SIDF shall de-conceal SUPI_Temp. In step 8, the UDM verifies if the de-concealed SUPI_Tempmaps the HN assigned UE identifier (SUPI/5G-GUTI/GPSI). In an embodiment herein, the UDM has the mapping of SUPI_Tempand SUPI/5G-GUTI/GPSI as part of subscription data. In step 9, based on SUPI_Temp, the UDM/ARPF chooses the authentication method. In steps 10-20, the UDM/ARPF generates an authentication vector (AV). The procedure follows as specified in 6.1.3 of 3GPP TS 33.501. Instead of SUPI, AUSF provides the SUPI_Temp to the vAMF as subscription identifier of the UE (206) to be used.

UDM and UE derives SUPITemp from SUPI:

FIG. 9 depicts a 5G authentication procedure, wherein the UDM and the UE (206) derive SUPI_Temp and the UE (206) uses the derived SUPI_Temp for authentication in the VPLMN (202)/serving PLMN or in NPN. In an embodiment herein, the UDM and the UE (206) derives a temporary/pseudonym subscriber identifier (SUPI_Temp) and uses the SUPI_Temp temporary/pseudonym subscriber identifier for key derivation and further procedure during registration and authentication in roaming scenario or accessing the NPN or Edge network.

In step 1, consider that the UE (206) is in roaming in the visited PLMN and/or seeking NPN network access. The UE (206) sends the Registration Request NAS message to the SEAF/AMF in the serving network, containing either a SUCI (generated using the SUPI) or a 5G Globally Unique Temporary UE Identifier (5G-GUTI) along with other possible parameters.

In step 2, on receiving the registration request, the SEAF/AMF invokes primary authentication by sending authentication request (i.e., Nausf_UEAuthentication_Authenticate request) to the AUSF in the home network containing the received SUCI and its serving network name (SNN).

In step 3, the AUSF verifies the SNN in the authentication request to check if it is the same as the expected serving name. If the verification is successful, it sends an authentication data request i.e., Nudm_UEAuthentication_Get request to the UDM, including the received SUCI and SN Id along with other possible parameters.

In step 4, on receiving the Nudm_UEAuthentication_Get Request, the UDM invokes SIDF if a SUCI is received. The SIDF de-conceals SUPI. The UDM/ARPF chooses the authentication method. In an embodiment herein, the UDM derives temporary/pseudonym SUPI (SUPI_Temp) for the UE in roaming. In an embodiment herein, the SUPI_Tempderivation includes at least one of the inputs: SUPI, SN ID, Freshness parameter like so with the root key K and/or CK and/or IK and/or CK' and/or IK' and/or K_AUSF.In an embodiment herein, a freshness parameter is included to ensure that distinct SUPI_Tempis derived each time. The freshness parameter can be a counter (monotonically incremented each time for new SUPI_Temp derivation), random number like so. In an embodiment herein, each SUPI_Tempis allocated an expiration time to keep track of validity of the SUPI_Temp.In an embodiment herein, generated SUPI_Tempis valid within the VPLMN (202) (SNN/SN ID) serving the UE. The UDM/ARPF generates an authentication vector (AV). In an embodiment herein, the UDM stores the mapping between the HN assigned SUPI and the derived SUPI_Temp for Charging purpose, network surveillance tasks, trace-back actions and error diagnostic research actions by the PLMN/Government agencies, like so. In an embodiment herein, the UDM stores the mapping between the HN assigned SUPI and the derived SUPI_Temp along with the timestamp in the HPLMN (204) as part of subscription data and/or in the charging system and/or in the monitoring system and/or in the UDR and/or in a dedicated NF and/or in the Binding Support Function (BSF).

In step 5, the procedure follows as specified in 6.1.3 of TS 33.501. The UDM provides the SUPI, SUPI_Tempand freshness parameter along with other possible parameters to the AUSF in Nudm_UEAuthentication_Get Response message. In step 6, the AUSF may store the mapping between SUPI and SUPI_Temp. In steps 7 & 8, the AUSF sends the authentication challenge message to the SEAF/AMF in a Nausf_UEAuthentication_Authenticate Response message including the freshness parameter along with other necessary parameters like AV(s). The SEAF/AMF transparently forward the Challenge message to the UE (206) in a NAS message Authentication Request message along with other possible parameters. In step 9, the UE (206) calculates the SUPI_Temp in the same way as the UDM as specified in step 4 and uses the derived SUPI_Tempfor further procedure, derivation of K_AMF, charging like so. In steps 10, 11 & 12, the procedure follows as specified in 6.1.3 of TS 33.501. Instead of SUPI AUSF provides the SUPI_Temp to the vAMF/SEAF as subscription identifier of the UE. In an embodiment herein, the vAMF uses SUPI_Temp for further procedure, derivation of K_AMF, book keeping, like so.

AUSF and UE derives SUPITemp from SUPI:

FIG. 10 depicts a 5G authentication procedure, wherein the AUSF and the UE (206) derive SUPI_Temp and the UE (206) using the derived SUPI_Temp for authentication in the VPLMN (202)/serving PLMN. In an embodiment herein, the AUSF and the UE (206) derives a temporary/pseudonym subscriber identifier (SUPI_Temp) and uses the SUPI_Temp for key derivation and for further procedure during registration and authentication in roaming scenario and/or accessing the NPN and/or Edge network.

In step 1, the UE (206) is in roaming in the visited PLMN and/or seeking NPN network access. The UE (206) sends the Registration Request NAS message to the SEAF/AMF in the serving network, containing either a SUCI (generated using the SUPI) or a 5G Globally Unique Temporary UE Identifier (5G-GUTI) along with other possible parameters.

In step 2, on receiving the registration request, the SEAF/AMF invokes primary authentication by sending authentication request (i.e., Nausf_UEAuthentication_Authenticate request) to the AUSF in the home network containing the received SUCI and its serving network name (SNN) along with other possible parameters.

In step 3, the AUSF verifies the SNN in the authentication request to check if it is the same as the expected serving name. If the verification is successful, it sends an authentication data request i.e., Nudm_UEAuthentication_Get request to the UDM, including the received SUCI and SN Id.

In step 4, on receiving the Nudm_UEAuthentication_Get Request, the UDM invokes SIDF if a SUCI is received. SIDF de-conceals SUPI. The UDM/ARPF chooses the authentication method.

In step 5, the UDM provides the temporary/pseudonym identifier indication to the AUSF in Nudm_UEAuthentication_Get Response message along with the other necessary parameters. In an embodiment herein, the temporary/pseudonym identifier (temporary/pseudonym SUPI) indication is sent to indicate the AUSF to use and/or derive SUPI_Tempfor the further procedure during authentication and key derivation.

In step 6, the AUSF sends the authentication challenge message to the SEAF/AMF in a Nausf_UEAuthentication_Authenticate Response message including a freshness parameter along with other necessary parameters like AV(s).

In step 7, the SEAF/AMF transparently forward the Challenge message to the UE (206) in a NAS message Authentication Request message along with other possible parameters.

In step 8, on receiving the freshness parameter in the Authentication request message, the UE (206) derives temporary/pseudonym SUPI (SUPI_Temp). In an embodiment herein, the SUPI_Tempderivation includes at least one of the inputs: SUPI, SN ID, received Freshness parameter like so with the root key K and/or CK and/or IK and/or CK' and/or IK' and/or K_AUSF.In an embodiment herein, freshness parameter is included to ensure that distinct SUPI_Tempis derived each time. The freshness parameter can be a counter (monotonically incremented each time for new SUPI_Temp derivation), random number like so. In an embodiment herein, each SUPI_Tempis allocated an expiration time to keep track of validity of the SUPI_Temp.In an embodiment herein, generated SUPI_Tempis valid within the VPLMN (202) (SNN/SN ID) serving the UE. In an embodiment herein, AUSF may store the mapping between the HN assigned SUPI and the derived SUPI_Temp for Charging purpose, network surveillance tasks, trace-back actions and error diagnostic research actions by the PLMN and/or Government agencies, like so.

In steps 9-12, the procedure follows as specified in 6.1.3 of TS 33.501. The AUSF derives temporary/pseudonym SUPI (SUPI_Temp) in the same way as the UE (206) (in step 8). In an embodiment herein, freshness parameter is included to ensure that distinct SUPI_Tempis derived each time. The freshness parameter can be a counter (monotonically incremented each time for new SUPI_Temp derivation), random number like so. In an embodiment herein, each SUPI_Tempis allocated an expiration time to keep track of validity of the SUPI_TempIn an embodiment herein, generated SUPI_Tempis valid within the VPLMN (202) (SNN/SN ID) serving the UE. In an embodiment herein, instead of SUPI of the UE, the AUSF provides the SUPI_Temp to the vAMF as subscription identifier of the UE. In an embodiment herein, the vAMF uses SUPI_Temp for further procedure, derivation of K_AMF like so.

In step 13, the AUSF shares the SUPI_Tempas part of Nudm_Authentication_result confirmation request along with the other necessary parameters to the UDM.

In step 14, the UDM stores the mapping between SUPI and the SUPI_Temp as part of authentication results along with other parameters like authentication result, timestamp, and the serving network name.

In an embodiment herein, AUSF and/or UDM stores the mapping between the HN assigned SUPI and the derived SUPI_Temp along with the timestamp in the HPLMN (204) as part of subscription data and/or in the charging system and/or in the monitoring system and/or in the UDR and/or in a dedicated NF and/or in the BSF.

UE is (pre)-configured with more than one SUPITemp based on indexed manner:

FIG. 11 depicts the 5G authentication procedure, wherein the UDM and UE (206) is (pre)-configured with SUPI_Tempin an indexed manner and the UE (206) uses the indicated indexed SUPI_Temp for identification and/or for other procedures like key derivation in the VPLMN (202)/serving PLMN. In an embodiment herein, the UDM and the UE (206) are pre-configured with one or more than one temporary/pseudonym subscriber identifier (SUPI_Temp) in an indexed manner (in addition to the SUPI) and uses the SUPI_Temp for key derivation and further procedure during authentication and key derivation in roaming scenario or accessing the NPN or Edge network. In an embodiment herein, UE/UICC and the UDM is (pre)configured by the network/MNO/hPLMN (204) with more than one SUPI_Tempto be used during roaming or accessing the NPN or Edge network. In an embodiment herein, the UE subscription profile in the HN (maybe in the UDM) is configured with one or more than one SUPI(s). In an embodiment herein, all the SUPI(s) (pre)-configured in the UE (206) and the UDM subscription profile are indexed monotonically. The 0^th index being the primary SUPI (SUPI_index0) which is utilized when the UE (206) is in HPLMN (204). The other SUPI_Temp to be used during roaming or as configured (for NPN) are indexed further as: SUPI_index1,SUPI_index1,SUPI_index3,like so. In an embodiment herein, these indexed SUPIs are configured when the UE (206) purchases the roaming subscription or when obtaining the contract to access the NPN. In an embodiment herein, the SUPI used in non-roaming scenario is termed as primary SUPI and other temporary/pseudonym SUPI(s) to be used during roaming is termed as secondary SUPI(s). In an embodiment herein, the one or more SUPI(s) are indexed to identify the SUPI(s) in further procedures by the UE (206) and the network/HPLMN (204). In an embodiment herein, the one or more SUPI(s) are assigned with an identifier which is used to identify the SUPI(s) in further procedures by the UE (206) and the network/HPLMN (204). The UE (206) uses the primary SUPI and generates SUCI and uses it for initiating the registration procedure.

In step 1, when the UE (206) initiates registration request from the VPLMN (202) and/or from NPN and/or from any PLMN other than HPLMN, then the UE (206) sends the Registration Request NAS message to the SEAF/AMF in the serving network, containing either a SUCI (derived using the primary SUPI) or a 5G Globally Unique Temporary UE Identifier (5G-GUTI) along with other possible parameters.

In step 2, on receiving the registration request, the SEAF/AMF invokes primary authentication by sending authentication request message i.e., Nausf_UEAuthentication_Authenticate request message to the AUSF in the home network, including the received SUCI and its serving network name (SNN) along with other possible parameters.

In step 4, on receiving the Nudm_UEAuthentication_Get Request, the UDM invokes SIDF if a SUCI is received. SIDF de-conceals SUPI. The UDM/ARPF chooses the authentication method based on the SUPI. In an embodiment herein, the UDM selects one of the SUPI_Temp(for example., SUPI_index1) based on the Serving Network Name (SNN) and stores it as part of subscription profile as SUPI in use. The UDM/ARPF generates an authentication vector (AV). In an embodiment herein, the UDM maps the SUPI in use (i.e., SUPI_index1) with the de-concealed SUPI (primary SUPI/SUPI_index0) as part of subscription profile.

In step 5, the procedure follows as specified in 6.1.3 of TS 33.501. The UDM provides the SUPI in use along with its index (index1) to the AUSF in Nudm_UEAuthentication_Get Response message along with other possible parameters. In embodiment herein, UDM also provides the primary SUPI to the AUSF.

In step 6, the AUSF may stores the mapping between primary SUPI and SUPI_index1.The AUSF sends the authentication challenge message to the SEAF/AMF in a Nausf_UEAuthentication_Authenticate Response message including the index value (index1) along with other necessary parameters like AV(s).

In step 7, the SEAF/AMF transparently forward the Challenge message to the UE (206) in a NAS message Authentication Request message.

In step 8, on receiving the index1 in the Authentication request message, the UE (206) selects the SUPI_index1 (which is indexed as index1) as SUPI in use to derive the K_AMFand in further procedure.

In steps 9-12, the procedure follows as specified in 6.1.3 of TS 33.501. Instead of SUPI, the AUSF provides the SUPI_index1 to the vAMF as subscription identifier of the UE (206) to be used in roaming. In an embodiment herein, the vAMF uses SUPI_index1 for further procedure, derivation of K_AMF like so.

UE is (pre)-configured with more than one SUPITemp and uses concealed SUPITemp in registration request:

FIG. 12 depicts the 5G authentication procedure, wherein UDM and UE (206) is (pre)-configured with SUPI_Tempin indexed manner and the UE (206) uses the indexed SUPI_Temp for registration and authentication in the VPLMN (202) /serving PLMN. In an embodiment herein, the UDM and the UE (206) are pre-configured with one or more than one temporary/pseudonym subscriber identifier (SUPI_Temp) in an indexed manner and uses the SUPI_Temp for key derivation and further procedure during authentication and key derivation in roaming scenario or accessing the NPN or Edge network.

In an embodiment herein, UE/UICC and the UDM are (pre)configured by the network/MNO/HPLMN (204) with more than one SUPI_Tempto be used during roaming or accessing the NPN or Edge network. In an embodiment herein, the UE subscription profile is configured with one or more than one SUPI(s). In an embodiment herein, all the SUPI(s) (pre)-configured in the UE (206) and the UDM subscription profile are indexed monotonically as: SUPI_index1,SUPI_index1,SUPI_index3,like so. In an embodiment herein, these indexed SUPIs are configured when the UE (206) purchases the roaming subscription. In an embodiment herein, the one or more SUPI(s) are indexed to identify the SUPI(s) in further procedures by the UE (206) and the network/HPLMN (204). In an embodiment herein, the one or more SUPI(s) are assigned with an identifier which is used to identify the SUPI(s) in further procedures by the UE (206) and the network/HPLMN (204). The UE (206) uses the secondary SUPI and uses it for initiating the registration procedure.

In step 1, the UE (206) is in roaming in the visited PLMN. In an embodiment herein, the UE (206) sends the Registration Request NAS message to the SEAF/AMF in the serving network, containing either a SUCI (this concealed SUPI is concealed SUPI_Temp/secondary SUPI) or a 5G Globally Unique Temporary UE Identifier (5G-GUTI).

In step 2, on receiving the registration request, the SEAF/AMF invokes primary authentication by sending authentication request i.e., Nausf_UEAuthentication_Authenticate request to the AUSF in the home network containing the received SUCI (this concealed SUPI is concealed SUPI_Temp/secondary SUPI) and its serving network name (SNN).

In step 3, the AUSF verifies the SNN in the authentication request to check if it is the same as the expected serving name. If the verification is successful, it sends an authentication data request i.e., Nudm_UEAuthentication_Get request to the UDM, including the received SUCI (this concealed SUPI is concealed SUPI_Temp/secondary SUPI) and SN ID.

In step 4. On receiving the Nudm_UEAuthentication_Get Request, the UDM invokes SIDF if a SUCI (this concealed SUPI is concealed SUPI_Temp/secondary SUPI) is received. SIDF de-conceals SUPI. The UDM/ARPF chooses the authentication method. The UDM/ARPF generates an authentication vector (AV).

Steps 5 & 6 follow the procedure as specified in 6.1.3 of TS 33.501. The UDM provides the secondary SUPI in use to the AUSF in Nudm_UEAuthentication_Get Response message. In step 6, instead of primary SUPI, the AUSF provides the secondary SUPI to the vAMF as subscription identifier of the UE (206) to be used in roaming. In an embodiment herein, the UE (206) and vAMF uses secondary SUPI for further procedure, derivation of K_AMF like so.

UE using SUPITemp as such to be identified in serving PLMN:

FIG. 13 depicts the process of initiating an authentication procedure including SUPI_Temp and selection of authentication method, when the UE (206) is in the VPLMN (202) /serving PLMN. In an embodiment herein, the network/MNO/hPLMN (204) assigns a temporary/pseudonym subscriber identifier to the UE. The UE (206) uses the temporary/pseudonym subscriber identifier during registration and authentication in roaming scenario. In an embodiment herein, the format of SUPI_Temp includes: [random number]||MCC||MNC.

In step 1, consider that the UE (206) is in roaming in the visited PLMN. The UE (206) has the subscription for roaming in visited PLMN or accessing the NPN or Edge network.

In steps 2 & 3, the UDM is in possession with the subscription data of the UE (206) in roaming. When the customer UE activates its roaming subscription the HN UDM assigns a temporary/pseudonym subscriber identifier i.e., Subscriber Roaming Identifier (SUPI_Temp) to the UE.

In step 4, the UE (206) initiates registration request. The request includes the newly assigned SUPI_Temp (temporary/pseudonym identifier) in the Registration Request.

In step 5, the SEAF/AMF may initiate an authentication with the UE (206) during any procedure establishing a signalling connection with the UE, according to the SEAF/AMF's policy. The SEAF/AMF invokes the Nausf_UEAuthentication service by sending a Nausf_UEAuthentication_Authenticate Request message to the AUSF whenever the SEAF/AMF wishes to initiate an authentication. The Nausf_UEAuthentication_Authenticate Request message contains the SUPI_Temp. on receiving the Nausf_UEAuthentication_Authenticate Request message, the AUSF checks that the requesting SEAF/AMF in the serving network is authorized and forwards the request to the UDM.

In step 6, the Nudm_UEAuthentication_Get Request sent from AUSF to UDM includes the SUPI_Temp along with the other required parameters.

In step 7, on receiving the Nudm_UEAuthentication_Get Request, in an embodiment the UDM verifies if the SUPI_Temp maps the HN assigned UE identifier (SUPI/5G-GUTI/GPSI). In an embodiment herein, the UDM has the mapping of SUPI_Temp and SUPI/5G-GUTI/GPSI as part of subscription data.

In step 8, based on SUPI_Temp, the UDM/ARPF chooses the authentication method.

The UE (206) and the UDM are configured with temporary/pseudonym when it purchases roaming subscription and is still in hPLMN (non-roaming) during UPU/SoR update procedure:

FIG. 14 depicts the UE Parameter Update/Steering of Roaming procedure, wherein the UDM and the UE (206) are (pre)-configured with SUPI_Tempin an indexed manner and the UE (206) uses the indexed SUPI_Temp for registration and authentication in the VPLMN (202)/serving PLMN.

In an embodiment herein, the UE/UICC and the UDM are (pre)-configured by the network/MNO/HPLMN (204) with more than one SUPI_Tempwhen the UE (206) purchases the subscription for roaming or accessing the NPN or Edge network. In an embodiment herein, the UE subscription profile is configured with one or more than one SUPI(s). In an embodiment herein, all the SUPI(s) (pre)-configured in the UE (206) and in the UDM subscription profile are indexed monotonically. The 0^th index being the primary SUPI (SUPI_index0) which is utilized when the UE (206) is in hPLMN (204). The other SUPI_Temp to be used during roaming are indexed further as: SUPI_index1,SUPI_index1,SUPI_index3,like so.

In an embodiment herein, these indexed SUPIs are configured when the UE (206) purchases the roaming subscription. In an embodiment herein, the SUPI used in non-roaming scenario is termed as primary SUPI and other temporary/pseudonym SUPI(s) to be used during roaming is termed as secondary SUPI(s).

In an embodiment herein, the one or more SUPI(s) are indexed to identify the SUPI(s) in further procedures by the UE (206) and the network/hPLMN (204).

In an embodiment herein, the one or more SUPI(s) are assigned with an identifier which is used to identify the SUPI(s) in further procedures by the UE (206) and the network/hPLMN (204). The UE (206) uses the temporary/pseudonym SUPI and generates SUCI and uses it for initiating the registration procedure during roaming or when accessing the NPN.

In steps 1-3, the UDM decides to perform UE Parameter Update (UPU) or Steering of Roaming (SoR) list update. In step 4, the UDM provides the AMF with the protected temporary/pseudonym SUPI (SUPI_Temp) and/or index1 (associated with SUPI_Temp1) in Nudm_SDM_notification message along with other possible parameters. In step 5, the AMF provides the received protected temporary/pseudonym SUPI (SUPI_Temp) and/or index1 (associated with SUPI_Temp1) to the UE (206) in DL NAS transport message along with other possible parameters during configuration update procedure.

In step 6, On receiving the DL NAS Transport message, the UE (206) shall calculate the UPU-MAC-I_AUSF as specified in clause 6.15.2.1 of TS 33.501. If the UE (206) receives HN protected SUPI_Temp1 in the DL NAS transport message, it stores the SUPI_Temp1, then the UE (206) uses the SUPI_Temp1 and derives the concealed SUPI_Temp1 when it required to use the SUPI during roaming and/or in the NPN. In an embodiment herein, if the UE (206) receives the index it will select/determine the corresponding SUPI_Tempand uses the concealed SUPI_Temp1 when it required to use the SUPI during roaming and/or in the NPN.

In steps 7-9, the procedure follows UPU or SoR procedure as defined in TS 33.501. In another embodiment herein, when the UE (206) purchases the subscription for roaming, the UDM sends a temporary/pseudonym identifier indication in Nudm_SDM_notification message along with a freshness parameter. The UDM and the UE (206) derive the SUPI_Tempsame as specified in one of the embodiments enclosed herein. In an embodiment herein, the derived SUPI_Tempis used during registration and authentication in roaming scenario.

The UE and UDM is configured with temporary/pseudonym when they purchase roaming subscription and is still in HPLMN (non-roaming) (204) during NAS procedure:

FIG. 15 depicts the 5G NAS procedure, wherein the UE (206) receives the SUPI_Temp and uses the received SUPI_Temp for registration and authentication in the VPLMN (202)/serving PLMN.

In an embodiment herein, the UE/UICC and the UDM are (pre)-configured by the network/MNO/hPLMN (204) with more than one SUPI_Tempwhen the UE (206) purchases the subscription for roaming. In an embodiment herein, the UE subscription profile is configured with one or more than one SUPI(s). In an embodiment herein, all the SUPI(s) (pre)-configured in the UE (206) and the UDM subscription profile are indexed monotonically. The 0^th index being the primary SUPI (SUPI_index0) which is utilized when the UE (206) is in the hPLMN (204). The other SUPI_Temp to be used during roaming are indexed further as: SUPI_index1,SUPI_index1,SUPI_index3,like so. In an embodiment herein, these indexed SUPIs are configured when the UE purchases the roaming subscription. In an embodiment herein, the SUPI used in non-roaming scenario is termed as primary SUPI and other temporary/pseudonym SUPI(s) to be used during roaming is termed as secondary SUPI(s). In an embodiment herein, the one or more SUPI(s) are indexed to identify the SUPI(s) in further procedures by the UE (206) and the network/hPLMN (204). In an embodiment herein, the one or more SUPI(s) are assigned with an identifier which is used to identify the SUPI(s) in further procedures by the UE (206) and the network/hPLMN (204). The UE (206) uses the temporary/pseudonym SUPI and generates SUCI and uses it for initiating the registration procedure during roaming.

In step 1, based on the trigger and/or occurrence of an event, the UE (206) initiates the NAS procedure with the AMF (as specified in TS 23.502) (for example, based on the TAI change, the UE (206) initiates mobility registration procedure).

In step 2, the network is configured one or more than one SUPI_Tempwhen the UE (206) purchases the subscription for roaming. Based on the network policy, the AMF provides the SUPI_Temp and/or the index value to the UE in a NAS response message for the received NAS request message.

In step 3, if the UE (206) receives SUPI_Temp1 in the in NAS message it uses the SUPI_Temp1 and uses the concealed SUPI_Temp1 when initiating registration and authentication during roaming. In an embodiment herein, if the UE (206) receives the index it will select the corresponding SUPI_Tempuses the concealed SUPI_Temp1 when initiating registration and authentication during roaming.

FIG. 16 depicts an example 5G NAS procedure, where the UE (206) receives the SUPI_Temp in NAS SMC and uses the received SUPI_Temp for registration and authentication in the VPLMN (202)/serving PLMN.

Temporary/pseudonym Identifier allocation and format:

The home network allocates a home-based temporary/pseudonym identifier (SUPI_Temp) for the UE:

a. The home network can control how often the temporary/pseudonym identifiers should be refreshed. In an embodiment herein, the UE (206) is assigned new temporary/pseudonym id each time it roams to the serving network.

b. SUPI privacy protection is provided by having and using a temporary/pseudonym identifier allocated by the home network in the VPLMN (202). This home network based temporary/pseudonym identifier can be used during communication between the serving network and the home network to identify the subscriber without exchanging the SUPI.

c. The format of the temporary/pseudonym Id is Unique within the HPLMN (204) at any point of time and could include information that helps the home network and the serving network to easily reach the UE (206) and also identifies the UEs Home network.

The home network allocates the temporary/pseudonym identifier (SUPITemp) for the UE (206) during:

- Registration procedure (initial registration and/or mobility registration, like so)

- SoR procedure

- UPU procedure

- Over The Air procedure

In an embodiment herein, the home network can implement a dedicated "Random Number Generator" for generating temporary/pseudonym identifier (SUPI_Temp). "Random Number Generator" the range of identifiers. Table 4 depicts an example format of a temporary/pseudonym identifier.

MCC

MNC

Random Number

Temporary/pseudonym Identifier derivation and re-allocation:

In an embodiment herein, FIG. 17 depicts an example of Key Derivation Function inputs. In an embodiment herein, the input to the key derivation function is Key, SUPI, SN Id, Freshness parameter and other possible parameters. In an embodiment herein, a timestamp is included as input to the KDF for deriving distinct SUPI_Temp for every derivation.

In an embodiment herein, the SUPI_Tempis associated with a timer Txyz, which determines the validity of the SUPI_Temp for a roaming UE. When the timer wraps around the network and the UE (206) invalidates the SUPI_Temp in use. After invalidation of SUPI_Temp,the UE (206) and UDM considers the next SUPI_Tempas per the index and/or derives the new SUPI_Tempwith new freshness parameter as described in one of the embodiments enclosed herein.

In an embodiment, it is proposed to re-use T₃₅₁₉ for validity of the SUPI_Temp.

In an embodiment herein, the MNO/the HPLMN (204) sets the validity or expiration of one or more SUPI_Temp,this validity could be per day based and/or a month based and/or year based. For example, if the UE (206) roams back to same location it can reuse the same SUPI_Tempas per a month and/or a year validity.

In another embodiment herein, the SUPI_Temp could be valid throughout the roaming subscription expires.

In another embodiment herein, the SUPI_Temp could be valid for the connection (valid between registered and deregistered state and/or until the UE (206) moves out of the VPLMN (202)/NPN).

In an embodiment herein, the home network maintains a periodicity timer for SUPI_Temp,a new SUPI_Tempis derived and/or a new SUPI_Tempis selected in a periodic manner, when there is need for change in SUPI_Tempthe network indicates the UE (206) and sends a freshness parameter and/or index associated with new SUPI_Tempas described in one of the embodiments enclosed herein.

In an embodiment herein, when the Subscription Concealed Identifier (SUCI) uses a protection scheme (i.e. one of the Elliptic Curve Integrated Encryption Scheme (ECIES) profiles is used (not the null-scheme)), then the UE (206) uses the SUPI to generate the SUCI (if SUPI_Temp is not available or not determined) and includes it in the Registration message. After that, the UE (206) uses the SUPI_Temp(provided or indicated using index by the home network after/during initial registration procedure) instead of SUPI, in the VPLMN (202) or in the NPN, whenever SUPI is required.

In an embodiment herein, when the Subscription Concealed Identifier (SUCI) uses a null-scheme, then the UE (206) uses only the SUPI_Temp to generate the SUCI and includes it in the Registration message, if available in the UE (206) or determined by the UE.

FIG. 18 is a flow chart illustrating a method, implemented by the first network function entity in the roaming hub, for handling the privacy of the UE.

At S1802, the method includes receiving, by the first network function entity in the roaming hub, the authenticate request message from the second network function entity in the first network domain. At S1804, the method includes sharing, by the first network function entity in the roaming hub, the authenticate request message to the AUSF entity in a second network domain. At S1806, the method includes receiving, by the first network function entity in the roaming hub, an authenticate response message from the AUSF entity in the second network domain based on the authenticate request message. At S1808, the method includes sharing, by the first network function entity in the roaming hub, the authenticate response message to the second network function entity in the first network domain.

FIG. 19 is a flow chart (S1900) illustrating a method, implemented by the UDM entity, an ARPF entity, and a SIDF entity, for handling the privacy of the UE, according to embodiments as disclosed herein.

At S1902, the method includes receiving, by the UDM entity, a UE authentication get request message from an AUSF entity. At S1904, the method includes determining, by the UDM entity whether a roaming hub identifier (RH ID) is included in the authenticate request message.

At S1906, the method includes verifying, by the UDM entity, whether the UE (206) is allowed to access at least one of the roaming hub and the second network domain in response to determining that the roaming hub identifier (RH ID) is included in the authenticate request message. At S19108, the method includes sending a reject cause in an authenticate response message in response to determining that the UE (206) is not allowed to access at least one of the roaming hub and the second network domain. At S1910, the method includes storing the RH ID in response to determining that the UE (206) is allowed to access at least one of the roaming hub and the second network domain.

FIG. 20 is a flow chart (S2000) illustrating a method, implemented by the UDM entity, an ARPF entity, and a SIDF entity, for handling the privacy of the UE, according to embodiments as disclosed herein.

At S2002, the method includes receiving, by at least one of: the UDM entity, the ARPF entity, and the SIDF entity, the UE authentication get request message from the AUSF entity. At S2004, the method includes determining, by at least one of: the UDM entity, the ARPF entity, and the SIDF entity, whether the SUCI is received in the UE authentication get request message. At S2006, the method includes de-concealing, by at least one of: the UDM entity, the ARPF entity, and the SIDF entity, a home network assigned SUPI in response to determining that the SUCI is received in the UE authentication get request message.

At S2008, the method includes deriving, by at least one of: the UDM entity, the ARPF entity, and the SIDF entity, a temporary SUPI for the UE (206) in roaming. At S2010, the method includes storing, by at least one of: the UDM entity, the ARPF entity, and the SIDF entity, a mapping between the home network assigned SUPI and the derived SUPI. At S2012, the method includes sending, by at least one of: the UDM entity, the ARPF entity, and the SIDF entity, a UE authentication get response message to the AUSF entity, wherein the UE authentication get response message comprises the home network assigned SUPI, the derived temporary SUPI and a freshness parameter.

FIG. 21 is a flow chart (2100) illustrating a method, implemented by the AUSF entity, for handling the privacy of the UE, according to embodiments as disclosed herein.

At S2102, the method includes sending, by the AUSF entity, the UE authentication get request message to the UDM entity. At S2104, the method includes receiving, by the AUSF entity, a UE authentication get response message from the UDM entity based on the UE authentication get request message, wherein the UE authentication get response message comprises a home network assigned SUPI, a derived SUPI and a freshness parameter. At S2106, the method includes storing, by the AUSF entity, a mapping between the home network assigned SUPI and the derived SUPI based on the UE authentication get response message. At S2108, the method includes sending, by the AUSF entity, a UE Authentication message comprising at least one of: the freshness parameter and the derived SUPI to a SEAF entity.

FIG. 22 shows various hardware components of the first network function entity (2200), according to embodiments as disclosed herein. The first network function entity can be, for example, but not limited to the AMF entity, a SEAF entity, an AUSF entity, a SCP entity, and a SEPP entity.

In an embodiment, the first network function entity (2200) includes a processor (2210), a communicator (2220), a memory (2230), and a privacy handling controller (2240). The processor (2210) is coupled with the communicator (2220), the memory (2230) and the privacy handling controller (2240).

The privacy handling controller (2240) receives the authenticate request message from a second network function entity in the first network domain. The second network function entity is at least one of an AMF entity, a SEAF entity, a SCP entity and a SEPP entity. Further, the privacy handling controller (2240) shares the authenticate request message to an Authentication Server Function (AUSF) entity in a second network domain. The authenticate request message includes at least one of: a Subscriber Concealed Identifier (SUCI), a Serving Network Name identifier, a Roaming Network Name identifier, a VPLMN identifier, and a Roaming Hub-Network- identifier.

The first network domain is a Visited Public Land Mobile Network (VPLMN) (202) and the second network domain is a Home Public Land Mobile Network (HPLMN) (204).

Further, the privacy handling controller (2240) receives an authenticate response message from the AUSF entity in the second network domain based on the authenticate request message. The authenticate response message from the AUSF entity in the second network domain is generated by sending a UE authentication get request message to at least one of: a Unified data management (UDM) entity, an Authentication Credential Repository and Processing Function (ARPF) entity, and a Subscription Identifier De-concealing Function (SIDF) entity from the AUSF entity, determining whether a roaming hub identifier (RH ID) is included in the authenticate request message, verifying whether the UE (206) is allowed to access at least one of the roaming hub and the second network domain in response to determining that the roaming hub identifier (RH ID) is included in the authenticate request message; and performing one of: storing the RH ID at the UDM entity in response to determining that the UE (206) is allowed to access at least one of the roaming hub and the second network domain, and sending a reject cause in an authenticate response message in response to determining that the UE (206) is not allowed to access at least one of the roaming hub and the second network domain.

Further, the privacy handling controller (2240) shares the authenticate response message to the second network function entity in the first network domain.

The privacy handling controller (2240) is physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware.

Further, the processor (2210) is configured to execute instructions stored in the memory (2230) and to perform various processes. The communicator (2220) is configured for communicating internally between internal hardware components and with external devices via one or more networks. The memory (2230) also stores instructions to be executed by the processor (2210). The memory (2230) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (2230) may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory (2230) is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

Although the FIG. 22 shows various hardware components of the first network function entity (2200) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the first network function entity (2200) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function in the first network function entity (2200).

FIG. 23 shows various hardware components of the network entity (2300), according to embodiments as disclosed herein. The network entity includes at least one of: the UDM entity, the ARPF entity, and the SIDF entity. In an embodiment, the network entity (2300) includes a processor (2310), a communicator (2320), a memory (2330), and a privacy handling controller (2340). The processor (2310) is coupled with the communicator (2320), the memory (2330) and the privacy handling controller (2340).

In an embodiment, the privacy handling controller (2340) receives the UE authentication get request message from the AUSF entity. Further, the privacy handling controller (2340) de-conceals a SUCI based on a UE authentication get request message. Further, the privacy handling controller (2340) determines whether a roaming hub identifier (RH ID) is included in the authenticate request message. Further, the privacy handling controller (2340) verifies whether the UE (206) is allowed to access at least one of the roaming hub and the second network domain in response to determining that the roaming hub identifier (RH ID) is included in the authenticate request message. Further, the privacy handling controller (2340) stores the RH ID in response to determining that the UE (206) is allowed to access at least one of the roaming hub and the second network domain. In another embodiment, the privacy handling controller (2340) sends a reject cause in an authenticate response message in response to determining that the UE (206) is not allowed to access at least one of the roaming hub and the second network domain.

In another embodiment, the privacy handling controller (2340) receives the UE authentication get request message from the AUSF entity. Further, the privacy handling controller (2340) determines whether the SUCI is received in the UE authentication get request message. Further, the privacy handling controller (2340) de-conceals the home network assigned SUPI in response to determining that the SUCI is received in the UE authentication get request message. Further, the privacy handling controller (2340) derives the temporary SUPI for the UE in roaming. Further, the privacy handling controller (2340) stores the mapping between the home network assigned SUPI and the derived SUPI. Further, the privacy handling controller (2340) sends the UE authentication get response message to the AUSF entity, wherein the UE authentication get response message comprises the home network assigned SUPI, the derived SUPI and a freshness parameter.

The privacy handling controller (2340) is physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware.

Further, the processor (2310) is configured to execute instructions stored in the memory (2330) and to perform various processes. The communicator (2320) is configured for communicating internally between internal hardware components and with external devices via one or more networks. The memory (2330) also stores instructions to be executed by the processor (2310). The memory (2330) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (2330) may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory (2330) is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

Although the FIG. 23 shows various hardware components of the network entity (2300) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the network entity (2300) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function in the network entity (2300).

FIG. 24 shows various hardware components of the AUSF entity (2400), according to embodiments as disclosed herein. In an embodiment, the AUSF entity (2400) includes a processor (2410), a communicator (2420), a memory (2430), and a privacy handling controller (2440). The processor (2410) is coupled with the communicator (2420), the memory (2430) and the privacy handling controller (2440).

The privacy handling controller (2440) sends a UE authentication get request message to at least one of: the UDM entity, the ARPF entity, and the SIDF entity. Further, the privacy handling controller (2440) receives a UE authentication get response message from at least one of: the UDM entity, the ARPF entity, and the SIDF entity based on the UE authentication get request message. The UE authentication get response message includes a home network assigned SUPI, a derived SUPI and a freshness parameter. Further, the privacy handling controller (2440) stores a mapping between the home network assigned SUPI and the derived SUPI based on the UE authentication get response message. The mapping between the home network assigned SUPI and the derived SUPIisstored along with a timestamp in the HPLMN (204) as part of subscription data. Further, the privacy handling controller (2440) sends a UE Authentication message comprising at least one of: the freshness parameter and the derived SUPI to a SEAF entity. The derivation of the temporary SUPI includes at least one of SUPI, a SN ID, freshness parameter and a root key. The freshness parameter is included to ensure that the distinct derived SUPIis derived each time. The freshness parameter is at least one of: a counter and a random number.

The privacy handling controller (2440) is physically implemented by analog or digital circuits such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, or the like, and may optionally be driven by firmware.

Further, the processor (2410) is configured to execute instructions stored in the memory (2430) and to perform various processes. The communicator (2420) is configured for communicating internally between internal hardware components and with external devices via one or more networks. The memory (2430) also stores instructions to be executed by the processor (2410). The memory (2430) may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories. In addition, the memory (2430) may, in some examples, be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagated signal. However, the term "non-transitory" should not be interpreted that the memory (2430) is non-movable. In certain examples, a non-transitory storage medium may store data that can, over time, change (e.g., in Random Access Memory (RAM) or cache).

Although the FIG. 24 shows various hardware components of the AUSF entity (2400) but it is to be understood that other embodiments are not limited thereon. In other embodiments, the AUSF entity (2400) may include less or more number of components. Further, the labels or names of the components are used only for illustrative purpose and does not limit the scope of the invention. One or more components can be combined together to perform same or substantially similar function in the AUSF entity (2400).

The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements. The network elements include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

The embodiment disclosed herein describes systems and methods for protecting a subscriber's privacy from one or more security threats, during a roaming scenario or when one or more than one the NFs are placed in different security domains. Therefore, it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The method is implemented in at least one embodiment through or together with a software program written in e.g., Very high speed integrated circuit Hardware Description Language (VHDL) another programming language, or implemented by one or more VHDL or several software modules being executed on at least one hardware device. The hardware device can be any kind of portable device that can be programmed. The device may also include means which could be e.g., hardware means like e.g., an ASIC, or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. The method embodiments described herein could be implemented partly in hardware and partly in software. Alternatively, the invention may be implemented on different hardware devices, e.g., using a plurality of CPUs.

The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the embodiments as described herein.

Claims

A method performed by a first network function entity in a roaming hub for handling a privacy of a user equipment (UE), comprising:

receiving an authenticate request message from a second network function entity in a first network domain;

sharing the authenticate request message to an Authentication Server Function (AUSF) entity in a second network domain;

receiving an authenticate response message from the AUSF entity in the second network domain based on the authenticate request message; and

sharing the authenticate response message to the second network function entity in the first network domain.
The method of claim 1, wherein the authenticate response message from the AUSF entity in the second network domain is generated by:

sending a UE authentication get request message to at least one of a Unified data management (UDM) entity from the AUSF entity;

determining whether a roaming hub identifier (RH ID) is included in the authenticate request message;

verifying whether the UE is allowed to access at least one of the roaming hub or the second network domain in response to determining that the roaming hub identifier (RH ID) is included in the authenticate request message; and

performing one of:

storing the RH ID at the UDM entity in response to determining that the UE is allowed to access at least one of the roaming hub or the second network domain, or

sending a reject cause in an authenticate response message in response to determining that the UE is not allowed to access at least one of the roaming hub and the second network domain.
The method of claim 1, wherein verifying that the UE is allowed to access at least one of the roaming hub or the second network domain in response to determining the roaming hub identifier (RH ID) is included in the authenticate request message.
The method of claim 1, wherein the first network domain is a Visited Public Land Mobile Network (VPLMN) and the second network domain is a Home Public Land Mobile Network (HPLMN).
The method of claim 1, wherein the authenticate request message comprises at least one of a Subscriber Concealed Identifier (SUCI), a Serving Network Name identifier, a Roaming Network Name identifier, a VPLMN identifier, or a Roaming Hub-Network- identifier.
The method of claim 1, wherein the first network function entity is at least one of an Access and Mobility Management Function (AMF) entity, a Security Anchor Function (SEAF) entity, an Authentication Server Function (AUSF) entity, a Service Communication Proxy (SCP) entity, or a Security Edge Protection Proxy (SEPP) entity,

and wherein the second network function entity is at least one of an AMF entity, a SEAF entity, a SCP entity or a SEPP entity.
A first network function entity in a roaming hub, the first network function entity comprising:

a processor;

a memory; and

a controller, coupled with the processor and the memory, configured to:

receive an authenticate request message from a second network function entity in a first network domain,

share the authenticate request message to an Authentication Server Function (AUSF) entity in a second network domain,

receive an authenticate response message from the AUSF entity in the second network domain based on the authenticate request message, and

share the authenticate response message to the second network function entity in the first network domain.
The first network function entity of claim 7, wherein the authenticate response message from the AUSF entity in the second network domain is generated by:

sending a UE authentication get request message to at least one of a Unified data management (UDM) entity from the AUSF entity;

determining whether a roaming hub identifier (RH ID) is included in the authenticate request message;

verifying whether the UE is allowed to access at least one of the roaming hub or the second network domain in response to determining that the roaming hub identifier (RH ID) is included in the authenticate request message; and

performing one of:

storing the RH ID at the UDM entity in response to determining that the UE is allowed to access at least one of the roaming hub or the second network domain, or

sending a reject cause in an authenticate response message in response to determining that the UE is not allowed to access at least one of the roaming hub or the second network domain.
The first network function entity of claim 7, wherein verifying that the UE is allowed to access at least one of the roaming hub or the second network domain in response to determining the roaming hub identifier (RH ID) is included in the authenticate request message.
The first network function entity of claim 7, wherein the first network domain is a Visited Public Land Mobile Network (VPLMN) and the second network domain is a Home Public Land Mobile Network (HPLMN).
The first network function entity of claim 7, wherein the authenticate request message comprises at least one of a Subscriber Concealed Identifier (SUCI), a Serving Network Name identifier, a Roaming Network Name identifier, a VPLMN identifier, or a Roaming Hub-Network- identifier.
The first network function entity of claim 7, wherein the first network function entity is at least one of an Access and Mobility Management Function (AMF) entity, a Security Anchor Function (SEAF) entity, an Authentication Server Function (AUSF) entity, a Service Communication Proxy (SCP) entity, or a Security Edge Protection Proxy (SEPP) entity, and

wherein the second network function entity is at least one of an AMF entity, a SEAF entity, a SCP entity or a SEPP entity.