Network authentication of user equipment access to edge data networks

Abstract

A network can authenticate a user equipment (UE) to access an edge data network. The network generates a first credential based on a second credential generated for a procedure between the UE and a cellular network corresponding to a network component; receives, in response to the UE transmitting an application registration request to a server associated with the edge data network, an identifier associated with the first credential from another network component; and retrieves the first credential based on the identifier. The network also receives a multi-access edge computing (MEC) authorization parameter, verifies the MEC authorization parameter, and transmits an authentication verification response to the second network component.

Description

Background Technology

[0001] User equipment (UE) can connect to an edge data network to access edge computing services. Edge computing refers to performing computation and data processing at the network that generates the data. To establish a connection to the edge data network, the UE may have to perform an authentication procedure through an edge configuration server (ECS). Summary of the Invention

[0002] Some exemplary embodiments relate to a method performed by a network component. The method includes generating a first credential based on a second credential, the second credential being for protocol generation between a user equipment (UE) and a cellular network corresponding to the network component; receiving an identifier associated with the first credential from another network component in response to the UE transmitting an application registration request to a server associated with an edge data network; retrieving the first credential based on the identifier; receiving multi-access edge computing (MEC) authorization parameters; verifying the MEC authorization parameters; and transmitting an authentication verification response to the second network component.

[0003] Other exemplary embodiments relate to a method performed by a network. The method includes generating a first credential based on a second credential, the second credential being generated for a protocol between a user equipment (UE) and a cellular network; receiving an identifier associated with the first credential from the server associated with the edge data network in response to the UE transmitting an application registration request to a server associated with an edge data network; retrieving the first credential based on the identifier; receiving multi-access edge computing (MEC) authorization parameters; verifying the MEC authorization parameters; and transmitting an authentication verification response to a second network component.

[0004] Another exemplary embodiment relates to a processor configured to perform operations. The operations include generating a first credential based on a second credential, the second credential being for protocol generation between a user equipment (UE) and a cellular network corresponding to the network component; receiving an identifier associated with the first credential from another network component in response to the UE transmitting an application registration request to a server associated with an edge data network; retrieving the first credential based on the identifier; receiving multi-access edge computing (MEC) authorization parameters; verifying the MEC authorization parameters; and transmitting an authentication verification response to the second network component. Attached Figure Description

[0005] Figure 1 Exemplary network arrangements according to various exemplary implementations are shown.

[0006] Figure 2 Exemplary UEs according to various exemplary implementations are shown.

[0007] Figure 3An architecture for enabling edge applications is shown according to various exemplary implementations.

[0008] Figure 4 Signaling diagrams of authentication and authorization procedures according to various exemplary implementations are shown. Detailed Implementation

[0009] The exemplary embodiments can be further understood with reference to the following description and related figures, wherein similar elements have the same reference numerals. The exemplary embodiments relate to implementing authentication and authentication procedures for accessing edge data networks.

[0010] The exemplary embodiments are described with respect to the UE. However, reference to the UE is provided for illustrative purposes only. The exemplary embodiments can be used with any electronic component capable of establishing a connection to a network and configured with hardware, software, and / or firmware for exchanging information and data with the network. Therefore, the UE as described herein is used to represent any suitable electronic component.

[0011] Furthermore, exemplary embodiments are described with reference to 5G New Radio (NR) networks. However, the reference to 5G NR networks is provided for illustrative purposes only. Exemplary embodiments can be used with any network that implements the functionality for edge computing described herein. Therefore, a 5G NR network as described herein can represent any network that includes functionality associated with edge computing.

[0012] The UE can access the edge data network via the 5G NR network. The edge data network can provide the UE with access to edge computing services. Edge computing refers to performing computation and data processing at the network that generates the data. Compared to traditional methods that utilize centralized architectures, edge computing is a distributed approach, where data processing is directed towards the network edge, closer to the end user. This allows for performance optimization and minimized latency.

[0013] Exemplary implementations are further described with reference to an Edge Configuration Server (ECS). The ECS performs operations related to authentication and authorization procedures for accessing the edge data network. However, reference to the ECS is provided for illustrative purposes only. Exemplary implementations can be used with any electronic component configured with hardware, software, firmware, and / or cloud computing capabilities for exchanging information with the UE. Therefore, the ECS described herein is used to represent any suitable electronic component.

[0014] Figure 1An exemplary network arrangement 100 according to various exemplary embodiments is illustrated. The exemplary network arrangement 100 includes a UE 110. Those skilled in the art will understand that the UE 110 can be any type of electronic component configured to communicate via a network, such as a mobile phone, tablet computer, desktop computer, smartphone, phablet, embedded device, wearable device, Cat-M device, Cat-M1 device, MTC device, eMTC device, other types of Internet of Things (IoT) devices, etc. A practical network arrangement may include any number of UEs used by any number of users. Therefore, the example of a single UE 110 is provided merely for illustrative purposes.

[0015] UE 110 can be configured to communicate with one or more networks. In the example of network arrangement 100, the network with which UE 110 can wirelessly communicate is the 5G NR Radio Access Network (RAN) 120. However, UE 110 can also communicate with other types of networks (e.g., 5G cloud RAN, LTE RAN, traditional cellular networks, WLAN, etc.), and UE 110 can also communicate with networks via a wired connection. Regarding an exemplary implementation, UE 110 can establish a connection with the 5G NR RAN 120. Therefore, UE 110 may have a 5G NR chipset to communicate with the NR RAN 120.

[0016] The 5G NR RAN 120 can be part of a cellular network that can be deployed by network operators (e.g., Verizon, AT&T, Sprint, T-Mobile, etc.). The 5G NR RAN 120 may include, for example, cells or base stations (Node B, eNodeB, HeNB, eNBS, gNB, gNodeB, macrocell base stations, microcell base stations, small cell base stations, femtocell base stations, etc.) configured to send and receive communication traffic from UEs equipped with appropriate cellular chipsets.

[0017] In network deployment 100, the 5G NR RAN 120 includes cells 120A representing gNBs. However, actual network deployments can include any number of cells of different types, which are deployed by any number of RANs. Therefore, for illustrative purposes, only an example with a single cell 120A is provided.

[0018] UE 110 can connect to 5G NR-RAN 120 via cell 120A. Those skilled in the art will understand that any relevant procedures can be performed for UE 110 to connect to 5G NR-RAN 120. For example, as described above, 5G NR-RAN 120 can be associated with a specific cellular provider, where UE 110 and / or its user have protocol and credential information (e.g., stored on a SIM card). Upon detecting the presence of 5G NR-RAN 120, UE 110 can transmit the corresponding credential information to associate with 5G NR-RAN 120. More specifically, UE 110 can be associated with a specific cell (e.g., cell 120A). However, as described above, the reference to 5G NR-RAN 120 is for illustrative purposes, and any suitable type of RAN can be used.

[0019] Network deployment 100 also includes a cellular core network 130. The cellular core network 130 can be viewed as an interconnected collection of components or functions that manage the operation and traffic of the cellular network. In this example, components include an Authentication Server Function (AUSF) 131, Unified Data Management (UDM) 132, Session Management Function (SMF) 133, User Plane Function (UPF) 134, and Network Exposure Function (NEF) 135. However, a real cellular core network may include various other components performing any of a variety of different functions.

[0020] AUSF 131 can store data used for UE authentication and handle authentication-related functions. AUSF 131 may be equipped with one or more communication interfaces for communicating with other network components (e.g., network functions, RAN, UE, etc.). Exemplary embodiments are not limited to the AUSF performing the reference operations described above. Those skilled in the art will understand that AUSFs can perform various different types of operations. Furthermore, references to a single AUSF 131 are merely illustrative; actual network deployments may include any suitable number of AUSFs.

[0021] UDM 132 can perform operations related to processing subscription-related information to support network processing of communication sessions. UDM 132 may be equipped with one or more communication interfaces for communicating with other network components (e.g., network functions, RAN, UE, etc.). Exemplary embodiments are not limited to the UDM performing the aforementioned reference operations. Those skilled in the art will understand that various different types of operations can be performed by a UDM. Furthermore, references to a single UDM 132 are for illustrative purposes only; actual network deployments may include any appropriate number of UDMs.

[0022] SMF 133 performs operations related to session management, such as, but not limited to, session establishment, session release, IP address allocation, policy and Quality of Service (QoS) enforcement. SMF 133 may be equipped with one or more communication interfaces to communicate with other network components (e.g., network functions, RAN, UE, etc.). Exemplary embodiments are not limited to SMFs performing the aforementioned reference operations. Those skilled in the art will understand that various different types of operations can be performed by an SMF. Furthermore, references to a single SMF 133 are merely illustrative; actual network deployments may include any appropriate number of SMFs.

[0023] UPF 134 performs operations related to Packet Data Unit (PDU) session management. For example, UPF 134 can facilitate connectivity between UE 110 and edge data network 170. UPF 134 may be equipped with one or more communication interfaces for communicating with other networks and / or network components (e.g., network functions, RAN, UE, etc.). Exemplary embodiments are not limited to UPFs performing the aforementioned reference operations. Those skilled in the art will understand that various different types of operations can be performed by a UPF. Furthermore, reference to a single UPF 134 is merely illustrative, and actual network deployments may include any suitable number of UPFs.

[0024] The NEF 135 is typically responsible for securely exposing the services and capabilities provided by the 5G NR-RAN 120 network functions. The NEF 135 may be equipped with one or more communication interfaces to communicate with other network components (e.g., network functions, RAN, UE, etc.). Exemplary embodiments are not limited to the NEF performing the aforementioned reference operations. Those skilled in the art will understand that various different types of operations can be performed by the NEF. Furthermore, the reference to a single NEF 135 is merely illustrative; actual network deployments may include any appropriate number of NEFs.

[0025] Network deployment 100 also includes the Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network services backbone 160. Cellular core network 130 manages traffic flowing between the cellular network and the Internet 140. IMS 150 can generally be described as an architecture for delivering multimedia services to UE 110 using IP protocols. IMS 150 can communicate with cellular core network 130 and Internet 140 to provide multimedia services to UE 110. Network services backbone 160 communicates directly or indirectly with Internet 140 and cellular core network 130. Network services backbone 160 can generally be described as a set of components (e.g., servers, network storage deployments, etc.) that implement a set of services that can be used to extend the functionality of UE 110 to communicate with various networks.

[0026] Furthermore, network deployment 100 includes an edge data network 170 and an edge configuration server (ECS) 180. An exemplary implementation scheme is described regarding the authentication and authorization procedures between UE 110 and ECS 180. The following will discuss... Figure 3 The Edge Data Network 170 and ECS 180 are described in more detail.

[0027] Figure 2 An exemplary UE 110 according to various exemplary embodiments is shown. Reference will be made to... Figure 1 The network layout 100 is used to describe UE 110. UE 110 may include a processor 205, a memory layout 210, a display device 215, an input / output (I / O) device 220, a transceiver 225, and other components 230. Other components 230 may include, for example, audio input devices, audio output devices, power sources, data acquisition devices, ports for electrically connecting UE 110 to other electronic devices, etc.

[0028] Processor 205 can be configured to execute various types of software. For example, the processor can execute application client 235 and edge enabler client (EEC) 240. Application client 235 can perform operations related to an application running on UE 110, which exchanges application data with a server via a network. EEC 224 can perform operations related to establishing a connection to edge data network 170. Application client 235 and EEC 240 are described below. Figure 4 Let's discuss this in more detail.

[0029] The software mentioned above, executed by processor 205, is merely exemplary. The functionality associated with the software may also be represented as a separate integrated component of UE 110, or as a modular component coupled to UE 110, such as an integrated circuit with or without firmware. For example, the integrated circuit may include an input circuitry for receiving signals and a processing circuitry for processing signals and other information. The engine may also be embodied as a single application or multiple separate applications. Furthermore, in some UEs, the functionality described for processor 205 is distributed among two or more processors, such as a baseband processor and an application processor. Exemplary implementations can be implemented according to any of these or other configurations of the UE.

[0030] Memory arrangement 210 may be a hardware component configured to store data related to operations performed by UE 110. Display device 215 may be a hardware component configured to display data to a user, while I / O device 220 may be a hardware component enabling user input. Display device 215 and I / O device 220 may be separate components or may be integrated together (such as a touchscreen). Transceiver 225 may be a hardware component configured to establish connections with 5G NR-RAN 120, LTE-RAN (not shown), legacy RAN (not shown), WLAN (not shown), etc. Therefore, transceiver 225 may operate on multiple different frequencies or channels (e.g., a set of consecutive frequencies).

[0031] Figure 3 An architecture 300 for enabling edge applications is illustrated according to various exemplary embodiments. Reference will be made to... Figure 1 The network layout 100 is used to describe the architecture 200.

[0032] An exemplary implementation of the authentication and authorization procedure between EEC 240 and ECS 180 for UE 110 is described. Successful completion of the exemplary procedure precedes the flow of application data traffic between edge data network 170 and UE 110. Architecture 300 provides a general example of the types of components that can interact with each other when UE 110 is configured to exchange application data traffic with edge data network 170. The following will discuss... Figure 4 Signaling diagram 400 provides a specific example of an exemplary authentication and authorization procedure.

[0033] Architecture 300 includes UE 110, core network 130, and edge data network 170. UE 110 can establish a connection to edge data network 170 via core network 130 and various other components (e.g., cell 120a, 5G NR RAN 120, network functions, etc.).

[0034] In architecture 300, various components are shown connected via reference points labeled edge-x (e.g., edge-1, edge-2, edge-3, edge-4, edge-5, edge-6, edge-7, edge-8, etc.). Those skilled in the art will understand that each of these reference points (e.g., connections, interfaces) is defined in the 3GPP specification. Exemplary architecture arrangement 300 uses these reference points in the manner they are defined in the 3GPP specification. Furthermore, while these interfaces are referred to as reference points throughout the specification, it should be understood that these interfaces do not need to be direct wired or wireless connections; for example, these interfaces may communicate via intermediate hardware and / or software components. For example, UE 110 exchanges communication with gNB 120A. However, in architecture 300, UE 110 is shown having a connection to ECS 180. However, this connection is not a direct communication link between UE 110 and ECS 180. Instead, it is a connection facilitated by the intervention of hardware and software components. Therefore, throughout the specification, the terms “connection,” “reference point,” and “interface” are used interchangeably to describe the interfaces between the various components in architecture 300 and network layout 100.

[0035] During operation, application data traffic 305 can flow between the application client 235 running on UE 110 and the edge application server (EAS) 172 of the edge data network 170. EAS 172 can be accessed via the core network 130 through an uplink classifier (CL) and branch point (NP) or any other suitable means. Those skilled in the art will understand the various types of operation and configurations associated with the application client and the EAS. The operations performed by these components are beyond the scope of the exemplary embodiment. Rather, these components are included in the description of architecture 300 to demonstrate that an exemplary authentication and authorization procedure between UE 110 and ECS 180 can precede the flow of application data traffic 305 between UE 110 and the edge data network 170.

[0036] EEC 240 can be configured to provide support functions for application client 235. For example, EEC 240 can perform concept-related operations such as, but not limited to, the discovery of EAS (e.g., EAS172) available in the edge data network, and the retrieval and configuration of configuration information enabling the exchange of application data traffic 305 between application client 235 and EAS172. To distinguish EEC 240 from other EECs, EEC 240 can be associated with a globally unique value (e.g., EEC ID) that identifies EEC 240. Furthermore, while a reference to a single application client 235 and EEC 240 is provided for illustrative purposes only, UE 110 can be equipped with any appropriate number of application clients and EECs.

[0037] Edge data network 170 may also include an edge enabler server (EES) 174. EES 174 may be configured to provide support functions to EEC 240 running on EAS 172 and UE 110. For example, EES 174 may perform concept-related operations such as, but not limited to, configuring to enable the exchange of application data traffic 305 between UE 110 and EAS 172, and providing EAS 172-related information to EEC 235 running on UE 110. Those skilled in the art will understand the various types of operations and configurations associated with EES. Furthermore, reference to edge data network 170 including a single EAS 172 and a single EES 174 is provided for illustrative purposes only. In a real-world deployment scenario, the edge data network may include any suitable EAS and EES that interact with any number of UEs.

[0038] ECS180 can be configured to provide support functions for enabling EEC 240 to connect to EES174. For example, ECS180 can perform concept-related operations such as, but not limited to, configuring edge configuration information to EEC 240. Edge configuration information may include information for enabling EEC 240 to connect to EES174 (e.g., service area information) and information for establishing a connection to EES174 (e.g., Uniform Resource Identifier (URI)). Those skilled in the art will understand the various types of operations and configurations associated with ECS.

[0039] In network deployment 100 and enabled architecture 300, the ECS180 is shown outside the edge data network 170 and core network 130. However, this is provided for illustrative purposes only. The ECS180 can be deployed in any suitable virtual and / or physical location (e.g., within a mobile network operator's domain or a third-party domain) and implemented via any suitable combination of hardware, software, and / or firmware.

[0040] As indicated above, the interaction between the EEC 240 running on the ECS 180 and the UE 110 can occur before the flow of application data traffic 305. An exemplary implementation involves authentication and authorization procedures between the UE 110 and the ECS 180.

[0041] Figure 4 Signaling diagram 400 illustrates authentication and authorization procedures according to various exemplary implementations. (The remaining text appears to be unrelated and likely refers to a separate topic.) Figure 3 Enable architecture 300, Figure 2 UE 110 and Figure 1 The network layout 100 is used to describe the signaling diagram 400.

[0042] Signaling diagram 400 includes UE 110, AUSF 131, UDM 132, NEF 135, and ECS 180. As will be described in more detail below, credentials generated by the primary authentication procedure (e.g., K...) AUSF This can provide the basis for the credentials of the exemplary authentication and authorization procedures described herein.

[0043] Those skilled in the art will understand that the primary authentication procedures (e.g., 5G AKA, EAP-AKA, etc.) typically refer to the authentication procedure between UE110 and core network 130. During the procedure, AUSF 131 can generate credentials K via authentication vector generation. AUSF Then, K AUSF It can be used for further operations within the main certification process. K AUSF Some features include: i) the ability to share K between UE 110 and the Home Public Land Mobile Network (HPLMN) AUSF (e.g., AUSF 131). AUSF , and ii)K AUSF It can provide the foundation for subsequent 5G key hierarchy structures.

[0044] Signaling diagram 400 assumes that UE 110 and core network 130 have successfully executed the main authentication procedure, and the credentials (K) AUSF () is available. However, only for illustrative purposes is an option for K. AUSF For reference, exemplary implementations can be applied to, in addition to, K. AUSF Any 3GPP credentials or information of a similar type other than or in place of them.

[0045] Furthermore, for the purposes of signaling diagram 400, it can be assumed that the credentials generated by the primary authentication cannot be sent outside the operator's network. Additionally, it can be assumed that UE 110 has discovered the edge data network 170 and is permitted to initiate this exemplary edge computing authentication and authorization procedure.

[0046] In 405, UE 110 performs primary authentication over the network. As indicated above, the procedure may result in the sharing of credentials (K) between UE 110 and AUSF 131. AUSF However, exemplary implementations are not limited to K. AUSF The use of this parameter can be achieved by utilizing any other appropriate parameters.

[0047] In 410, UE 110 generates and stores one or more credentials. Throughout the specification, these credentials may be referred to as "K". edge "and "K edgeID However, regarding "K" edge "and "K edge The "ID" is for illustrative purposes only and can be used with any appropriate credentials or parameters.

[0048] In this example, credential K edge Key Derivation Functions (KDFs) can be used to generate them. Those skilled in the art will understand that a KDF can be, for example, the KDF defined in Appendix B.2.0 of 3GPP Technical Specification (TS) 33.220 or any other function of similar type.

[0049] Credentials K edge Available from credential K AUSF Export. For example, the input key for KDF could be K... AUSF When exporting K edge In this case, the following parameters can also be used for KDF: FC, P0, L0. Here, FC can represent a parameter used to distinguish different instances of KDF. The value of FC can be any appropriate value assigned by a 3GPP-based entity. The Subscription Permanent Identifier (SUPI) or any other identifier associated with UE 110 (e.g., General Public Subscription Identifier (GPSI)) can be used for P0. The length of the P0 parameters (e.g., SUPI, GPSI, etc.) can be used for L0.

[0050] K edgeID The parameter can be used to uniquely identify K. edge Parameter. K edgeID Parameters can be generated in any suitable manner. As mentioned above, it can be assumed that credentials generated by primary authentication cannot be sent outside the operator's network. Therefore, K edge It can be sent outside the carrier's network. However, K edgeID The parameter can be sent outside this network because it is not a credential but a unique identifier for K. edgeID The parameters of the parameters. K will be described in more detail below. edgeID The use of parameters.

[0051] In section 415, AUSF 131 generates and stores one or more credentials. Here, AUSF 131 generates the same credentials as those generated by UE 110 in section 410. Therefore, in this example, AUSF 131 can also generate credential K. edge and K edgeID Due to credential K AUSF Shared between UE 110 and AUSF 131, UE 110 and AUSF 131 can independently generate the same credentials. However, regarding K... AUSF Provided for illustrative purposes only, any appropriate type of information may be used to provide the basis for one or more credentials generated in 410 and 415.

[0052] In 420, EEC 240 receives one or more credentials generated by UE 110. For example, EEC 240 can retrieve K from the memory arrangement 210 of UE 110. edge and K edgeID Alternatively, these credentials may be provided to EEC 240 through another process executed by processor 205.

[0053] In section 425, EEC 240 generates Multi-Access Edge Computing (MEC) licensing parameters. Throughout the specification, these parameters may be referred to as MEC. EEC The authorization parameter can use K. edge It is generated using the EEC ID associated with EEC 240. For example, MEC EEC The parameters can be generated using the SHA-256 hash function. (This is part of the MEC export process.) EEC When defining parameters, P0 and P1 can be used to form the input parameters S. Here, P0 represents K. edge And P1 represents the EEC ID. Input S can be equal to the cascaded P0||P1. MEC EEC The parameters are identified by the N least significant bits of the output of the SHA-246 function, for example, 32-bit, 64-bit, etc.

[0054] In step 430, UE 110 sends an application registration request to ECS180. The application registration request may include, but is not limited to, EEC ID, MEC... EEC and K edgeID This message can be sent via the Non-Access Layer (NAS), the user plane, or any other suitable means.

[0055] In section 435, the ECS180 sends an authentication verification message to the NEF 135 for verification. This authentication verification message may include information similar to an application registration request (e.g., EEC ID, MEC...). EEC and K edgeID (The content of)

[0056] In 440, NEF 135 can send authentication verification messages to UDM 132 for MEC. EEC Verification. In 445, UDM 132 (and / or AUSF 131) can use K edgeID Search K edgc And K can be used edge MEC with EEC ID verification EEC In other words, UDM 132 (and / or AUSF 131) can access data based on its stored data and K. edgeID The association is used to retrieve the credentials generated in 410 and verify the received MEC. EECUDM 132 (and / or AUSF 131) can then generate MEC. EEC An independent and distinct second instance. If MEC EEC The second instance matches the MEC received in 435. EEC If the stored K is true, then the verification process is successful. In this example, the verification process is successful. However, in real-world scenarios, if the stored K... edge The instance could not be found or MEC EEC The second instance does not match the MEC received in 435. EEC If so, the verification process has failed, and UE 110 may not be able to successfully complete the exemplary authentication and authorization procedure.

[0057] In 450, UDM 132 can send an authentication verification response to NEF 135. In this example, the verification process is successful. Therefore, the authentication verification response can indicate a successful verification process. In other embodiments, an indication of a failed verification process or the absence of an authentication verification response can indicate to NEF 135 that the authentication verification was unsuccessful.

[0058] The operations described above in sections 440-450 are presented as being performed by UDM 132. However, in real-world scenarios, these operations may be performed by AUSF 131, a combination of AUSF 131 and UDM 132, or by any other suitable network component. Therefore, in signaling diagram 400, the retrieval and verification process in section 445 is shown as being associated with both AUSF 131 and UDM 132.

[0059] In section 455, NEF 135 sends an indication to ECS 180 of the authentication verification response (e.g., success / failure) provided by UDM 132. Based on the verification result, ECS 170 decides whether to accept or reject the authentication request.

[0060] In 460, ECS180 sends an authentication accept or authentication reject message to UE 110 (e.g., EEC 240). An authentication accept message may indicate that UE 110 is allowed to attempt access to edge data network 170 and / or EAS172. An authentication reject message may indicate that UE 110 is not allowed to attempt access to edge data network 170 and / or EAS172.

[0061] After the authentication acceptance message is received, various signaling procedures can be performed between UE 110 (e.g., application client 235, EEC 240, etc.) and edge data network 170 (e.g., EAS172, EEC 174, etc.) to establish a connection that can be used to exchange application data traffic between UE 110 and edge data network 170. For example, a PDU session establishment procedure can be initiated.

[0062] Those skilled in the art will understand that the exemplary embodiments described above can be implemented with any suitable software or hardware configuration or combination thereof. Exemplary hardware platforms for implementing the exemplary embodiments may include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, and mobile devices with operating systems such as iOS, Android, etc. Exemplary embodiments of the methods described above may be embodied as programs comprising lines of code stored on a non-transitory computer-readable storage medium, which, at compile time, can be executed on a processor or microprocessor.

[0063] Although this patent application describes various combinations of various embodiments, each with different features, those skilled in the art will understand that any feature of an embodiment can be combined with features of other embodiments or features that are not functionally or logically inconsistent with the operation or function of the device of the disclosed embodiment of the invention in any manner not explicitly denied.

[0064] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0065] It will be apparent to those skilled in the art that various modifications can be made to this disclosure without departing from its spirit or scope. Therefore, this disclosure is intended to cover all modifications and variations thereof, provided that such modifications and variations are within the scope of the appended claims and their equivalents.

Claims

1. A method performed at a network component, comprising: The first credential is generated based on the second credential, wherein the second credential is generated for the protocol between the user equipment (UE) and the cellular network corresponding to the network component; In response to the UE transmitting an application registration request to a server associated with the edge data network, an identifier associated with the first credential is received from another network component; Retrieve the first credential based on the identifier; Receive Multi-Access Edge Computing (MEC) authorization parameters; Verify the MEC authorization parameters; as well as Transmit the authentication and verification response to the second network component.

2. The method of claim 1, wherein the second credential is generated for a primary authentication procedure, and the primary authentication procedure refers to the authentication procedure between the UE and the core network.

3. The method of claim 2, wherein the primary authentication procedure includes an Authentication Server Function (AUSF), and the second credential is .

4. The method of claim 1, wherein the first credential is further based on an identifier associated with the UE or other shared information between the UE and the cellular network.

5. The method of claim 4, wherein the identifier associated with the UE is one of a Subscription Permanent Identifier (SUPI) or a General Public Subscription Identifier (GPSI).

6. The method of claim 1, wherein the first credential is further based on a key derivation function.

7. The method of claim 1, wherein verifying the MEC authorization parameters comprises: Receive the identifier associated with the Edge Enabler Client (EEC) running on the UE; A second instance of the MEC authorization parameters is generated based on the first credential and the identifier associated with the EEC; as well as Compare the MEC authorization parameters with the second instance of the MEC authorization parameters.

8. The method of claim 7, wherein the second instance of the MEC authorization parameter is based on a hash function.

9. The method of claim 1, wherein the server associated with the edge data network is an edge configuration server (ECS).

10. A method performed at a cellular network, comprising: A first credential is generated based on a second credential, wherein the second credential is generated for the protocol between the user equipment (UE) and the cellular network. In response to the UE transmitting an application registration request to a server associated with the edge data network, the UE receives an identifier associated with the first credential from the server associated with the edge data network; Retrieve the first credential based on the identifier; Receive Multi-Access Edge Computing (MEC) authorization parameters; Verify the MEC authorization parameters; as well as Transmit the authentication and verification response to the second network component.

11. The method of claim 10, wherein the second credential is generated for a primary authentication procedure, the primary authentication procedure including an Authentication Server Function (AUSF), and the second credential is Furthermore, the main authentication procedure refers to the authentication procedure between the UE and the core network.

12. The method of claim 10, wherein the first credential is further based on an identifier associated with the UE or other shared information between the UE and the cellular network.

13. The method of claim 10, wherein the first credential is further based on a key derivation function.

14. The method of claim 10, wherein verifying the MEC authorization parameters comprises: Receive an identifier associated with the Edge Enabler Client (EEC) running on the UE from the server associated with the edge data network; A second instance of the MEC authorization parameters is generated based on the first credential and the identifier associated with the EEC; as well as Compare the MEC authorization parameters with the second instance of the MEC authorization parameters.

15. The method of claim 14, wherein the second instance of the MEC authorization parameter is based on a hash function.

16. The method of claim 10, wherein the server associated with the edge data network is an edge configuration server (ECS).

17. An electronic device comprising a processor configured to perform operations, the operations including: The first credential is generated based on the second credential, wherein the second credential is generated for the protocol between the user equipment (UE) and the cellular network corresponding to the network component; In response to the UE transmitting an application registration request to a server associated with the edge data network, an identifier associated with the first credential is received from another network component; Retrieve the first credential based on the identifier; Receive Multi-Access Edge Computing (MEC) authorization parameters; Verify the MEC authorization parameters; as well as Transmit the authentication and verification response to the second network component.

18. The electronic device of claim 17, wherein the second credential is generated for a primary authentication procedure, the primary authentication procedure including an Authentication Server Function (AUSF), and the second credential is Furthermore, the main authentication procedure refers to the authentication procedure between the UE and the core network.

19. The electronic device of claim 17, wherein the first credential is further based on an identifier associated with the UE or other shared information between the UE and the cellular network.

20. The electronic device of claim 17, wherein the server associated with the edge data network is an edge configuration server (ECS).

Images