PATENT DOCUMENT

Publication Number: US-11968530-B2
Application Number: US-202017593499-A
Country: US
Kind Code: B2

Title: Network authentication for user equipment access to an edge data network

Abstract:
A network may authenticate a user equipment (UE) to access an edge data network. The network generates a first credential based on a second credential, the second credential generated for a procedure between the UE and a cellular network corresponding to the network component, receives an identifier associated with the first credential from a further network component in response to the UE transmitting an application registration request to a server associated with an edge data network 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 a second network component.

Claims:
What is claimed: 
     
       1. A method, comprising:
 at an authentication server function (AUSF):
 generating a first credential based on a second credential, the second credential generated for a procedure between a user equipment (UE) and a cellular network corresponding to the AUSF; 
 receiving an identifier associated with the first credential from a network exposure function (NEF) 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 a multi-access edge computing (MEC) authorization parameter; 
 verifying the MEC authorization parameter; and 
 transmitting an authentication verification response to the NEF. 
 
 
     
     
       2. The method of  claim 1 , wherein the second credential is generated for a primary authentication procedure. 
     
     
       3. The method of  claim 2 , wherein the second credential is K AUSF . 
     
     
       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 generic 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 parameter includes:
 receiving an identifier associated with an edge enabler client (EEC) running on the UE; 
 generating a second instance of the MEC authorization parameter based the first credential and the identifier associated with the EEC; and 
 comparing the MEC authorization parameter and the second instance of the MEC authorization parameter. 
 
     
     
       8. The method of  claim 7 , wherein the second instance of the MEC authorization parameter is based on a hashing 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, comprising:
 at a cellular network:
 generating, by an authentication server function (AUSF), a first credential based on a second credential, the second credential generated for a procedure between a user equipment (UE) and the cellular network; 
 receiving, by the AUSF, an identifier associated with the first credential from a network exposure function (NEF) in response to the UE transmitting an application registration request to the server associated with an edge data network; 
 retrieving the first credential based on the identifier; 
 receiving a multi-access edge computing (MEC) authorization parameter; 
 verifying the MEC authorization parameter; and 
 transmitting, by the AUSF, an authentication verification response to the NEF. 
 
 
     
     
       11. The method of  claim 10 , wherein the second credential is is K AUSF . 
     
     
       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 parameter includes:
 receiving an identifier associated with an edge enabler client (EEC) running on the UE from the server associated with the edge data network; 
 generating a second instance of the MEC authorization parameter based the first credential and the identifier associated with the EEC; and 
 comparing the MEC authorization parameter and the second instance of the MEC authorization parameter. 
 
     
     
       15. The method of  claim 14 , wherein the second instance of the MEC authorization parameter is based on a hashing function. 
     
     
       16. The method of  claim 10 , wherein the server associated with the edge data network is an edge configuration server (ECS). 
     
     
       17. A processor of an authentication server function (AUSF), configured to perform operations comprising:
 generating a first credential based on a second credential, the second credential generated for a procedure between a user equipment (UE) and a cellular network corresponding to the network component; 
 receiving an identifier associated with the first credential from a network exposure function (NEF) 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 a multi-access edge computing (MEC) authorization parameter; 
 verifying the MEC authorization parameter; and 
 transmitting an authentication verification response to the NEF. 
 
     
     
       18. The processor of  claim 17 , wherein the second credential is K AUSF . 
     
     
       19. The processor 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 processor of  claim 17 , wherein the server associated with the edge data network is an edge configuration server (ECS).

Description:
BACKGROUND 
     A user equipment (UE) may connect to an edge data network to access edge computing services. Edge computing refers to performing computing and data processing at the network where the data is generated. To establish a connection with the edge data network, the UE may have to perform an authentication procedure with an edge configuration server (ECS). 
     SUMMARY 
     Some exemplary embodiments are related to a method performed by a network component. The method includes generating a first credential based on a second credential, the second credential generated for a procedure between a user equipment (UE) and a cellular network corresponding to the network component, receiving an identifier associated with the first credential from a further 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 a multi-access edge computing (MEC) authorization parameter, verifying the MEC authorization parameter and transmitting an authentication verification response to a second network component. 
     Other exemplary embodiments are related to a method performed by a network. The method includes generating a first credential based on a second credential, the second credential generated for a procedure between a user equipment (UE) and the cellular network, receiving an identifier associated with the first credential from a server associated with an edge data network in response to the UE transmitting an application registration request to the server associated with an edge data network, retrieving the first credential based on the identifier, receiving a multi-access edge computing (MEC) authorization parameter, verifying the MEC authorization parameter and transmitting an authentication verification response to a second network component. 
     Still further exemplary embodiments are related to a processor configured to perform operations. The operations include generating a first credential based on a second credential, the second credential generated for a procedure between a user equipment (UE) and a cellular network corresponding to the network component, receiving an identifier associated with the first credential from a further 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 a multi-access edge computing (MEC) authorization parameter, verifying the MEC authorization parameter and transmitting an authentication verification response to a second network component. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG.  1    shows an exemplary network arrangement according to various exemplary embodiments. 
         FIG.  2    shows an exemplary UE according to various exemplary embodiments. 
         FIG.  3    shows an architecture for enabling edge applications according to various exemplary embodiments. 
         FIG.  4    shows a signaling diagram for an authentication and authorization procedure according to various exemplary embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     The exemplary embodiments may be further understood with reference to the following description and the related appended drawings, wherein like elements are provided with the same reference numerals. The exemplary embodiments relate to implementing an authentication and authentication procedure for access to an edge data network. 
     The exemplary embodiments are described with regard to a UE. However, reference to a UE is merely provided for illustrative purposes. The exemplary embodiments may be utilized with any electronic component that may establish a connection to a network and is configured with the hardware, software, and/or firmware to exchange information and data with the network. Therefore, the UE as described herein is used to represent any appropriate electronic component. 
     In addition, the exemplary embodiments are described with regard to a 5G New Radio (NR) network. However, reference to a 5G NR network is merely provided for illustrative purposes. The exemplary embodiments may be utilized with any network that implements the functionalities described herein for edge computing. Therefore, the 5G NR network as described herein may represent any network that includes the functionalities associated with edge computing. 
     The UE may access an edge data network via a 5G NR network. The edge data network may provide the UE with access to edge computing services. Edge computing refers to performing computing and data processing at the network where the data is generated. In contrast to legacy approaches that utilize a centralized architecture, edge computing is a distributed approach where data processing is localized towards the network edge, closer to the end user. This allows performance to be optimized and latency to be minimized. 
     The exemplary embodiments are further described with regard to an edge configuration server (ECS). The ECS may perform operations related to the authentication and authorization procedure for access to an edge data network. However, reference to an ECS is merely provided for illustrative purposes. The exemplary embodiments may be utilized with any electronic component that is configured with the hardware, software, firmware and/or cloud computing functionality to exchange information with the UE. Therefore, the ECS as described herein is used to represent any appropriate electronic component. 
       FIG.  1    shows an exemplary network arrangement  100  according to various exemplary embodiments. The exemplary network arrangement  100  includes UE  110 . Those skilled in the art will understand that the UE  110  may be any type of electronic component that is configured to communicate via a network, e.g., mobile phones, tablet computers, desktop computers, smartphones, phablets, embedded devices, wearables, Cat-M devices, Cat-M1 devices, MTC devices, eMTC devices, other types of Internet of Things (IoT) devices, etc. An actual network arrangement may include any number of UEs being used by any number of users. Thus, the example of a single UE  110  is only provided for illustrative purposes. 
     The UE  110  may be configured to communicate with one or more networks. In the example of the network configuration  100 , the network with which the UE  110  may wirelessly communicate is a 5G NR radio access network (RAN)  120 . However, the UE  110  may also communicate with other types of networks (e.g. 5G cloud RAN, an LTE RAN, a legacy cellular network, a WLAN, etc.) and the UE  110  may also communicate with networks over a wired connection. With regard to the exemplary embodiments, the UE  110  may establish a connection with the 5G NR RAN  120 . Therefore, the UE  110  may have a 5G NR chipset to communicate with the NR RAN  120 . 
     The 5G NR RAN  120  may be a portion of a cellular network that may be deployed by a network carrier (e.g., Verizon, AT&amp;T, Sprint, T-Mobile, etc.). The 5G NR RAN  120  may include, for example, cells or base stations (Node Bs, eNodeBs, HeNBs, eNBS, gNBs, gNodeBs, macrocells, microcells, small cells, femtocells, etc.) that are configured to send and receive traffic from UEs that are equipped with the appropriate cellular chip set. 
     In network arrangement  100 , the 5G NR RAN  120  includes a cell  120 A that represents a gNB. However, an actual network arrangement may include any number of different types of cells being deployed by any number of RANs. Thus, the example of a single cell  120 A is merely provided for illustrative purposes. 
     The UE  110  may connect to the 5G NR-RAN  120  via the cell  120 A. Those skilled in the art will understand that any association procedure may be performed for the UE  110  to connect to the 5G NR-RAN  120 . For example, as discussed above, the 5G NR-RAN  120  may be associated with a particular cellular provider where the UE  110  and/or the user thereof has a contract and credential information (e.g., stored on a SIM card). Upon detecting the presence of the 5G NR-RAN  120 , the UE  110  may transmit the corresponding credential information to associate with the 5G NR-RAN  120 . More specifically, the UE  110  may associate with a specific cell (e.g., the cells  120 A). However, as mentioned above, reference to the 5G NR-RAN  120  is merely for illustrative purposes and any appropriate type of RAN may be used. 
     The network arrangement  100  also includes a cellular core network  130 . The cellular core network  130  may be considered to be the interconnected set of components or functions that manage the operation and traffic of the cellular network. In this example, the components include an authentication server function (AUSF)  131 , a unified data management (UDM)  132 , a session management function (SMF)  133 , a user plane function (UPF)  134  and network exposure function (NEF)  135 . However, an actual cellular core network may include various other components performing any of a variety of different functions. 
     The AUSF  131  may store data for authentication of UEs and handle authentication-related functionality. The AUSF  131  may be equipped with one or more communication interfaces to communicate with other network components (e.g., network functions, RANs, UEs, etc.). The exemplary embodiments are not limited to a AUSF that performs the above reference operations. Those skilled in the art will understand the variety of different types of operations a AUSF may perform. Further, reference to a single AUSF  131  is merely for illustrative purposes, an actual network arrangement may include any appropriate number of AUSFs. 
     The UDM  132  may perform operations related to handling subscription-related information to support the network&#39;s handling of communication sessions. The UDM  132  may be equipped with one or more communication interfaces to communicate with other network components (e.g., network functions, RANs, UEs, etc.). The exemplary embodiments are not limited to an UDM that performs the above reference operations. Those skilled in the art will understand the variety of different types of operations a UDM may perform. Further, reference to a single UDM  132  is merely for illustrative purposes, an actual network arrangement may include any appropriate number of UDMs. 
     The 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, etc. The SMF  133  may be equipped with one or more communication interfaces to communicate with other network components (e.g., network functions, RANs, UEs, etc.). The exemplary embodiments are not limited to an SMF that performs the above reference operations. Those skilled in the art will understand the variety of different types of operations a SMF may perform. Further, reference to a single SMF  133  is merely for illustrative purposes, an actual network arrangement may include any appropriate number of SMFs. 
     The UPF  134  performs operations related packet data unit (PDU) session management. For example, the UPF  134  may facilitate a connection between the UE  110  and the edge data network  170 . The UPF  134  may be equipped with one or more communication interfaces to communicate with other networks and/or network components (e.g., network functions, RANs, UEs, etc.). The exemplary embodiments are not limited to an UPF that performs the above reference operations. Those skilled in the art will understand the variety of different types of operations an UPF may perform. Further, reference to a single UPF  134  is merely for illustrative purposes, an actual network arrangement may include any appropriate number of UPFs. 
     The NEF  135  is generally responsible for securely exposing the services and capabilities provided by 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, RANs, UEs, etc.). The exemplary embodiments are not limited to a NEF that performs the above reference operations. Those skilled in the art will understand the variety of different types of operations a NEF may perform. Further, reference to a single NEF  135  is merely for illustrative purposes, an actual network arrangement may include any appropriate number of NEFs. 
     The network arrangement  100  also includes the Internet  140 , an IP Multimedia Subsystem (IMS)  150 , and a network services backbone  160 . The cellular core network  130  manages the traffic that flows between the cellular network and the Internet  140 . The IMS  150  may be generally described as an architecture for delivering multimedia services to the UE  110  using the IP protocol. The IMS  150  may communicate with the cellular core network  130  and the Internet  140  to provide the multimedia services to the UE  110 . The network services backbone  160  is in communication either directly or indirectly with the Internet  140  and the cellular core network  130 . The network services backbone  160  may be generally described as a set of components (e.g., servers, network storage arrangements, etc.) that implement a suite of services that may be used to extend the functionalities of the UE  110  in communication with the various networks. 
     In addition, the network arrangement  100  includes an edge data network  170  and an edge configuration server (ECS)  180 . The exemplary embodiments are described with regard to implementing an authentication and authorization procedure between the UE  110  and the ECS  180 . The edge data network  170  and an ECS  180  will be described in more detail below with regard to  FIG.  3   . 
       FIG.  2    shows an exemplary UE  110  according to various exemplary embodiments. The UE  110  will be described with regard to the network arrangement  100  of  FIG.  1   . The UE  110  may include a processor  205 , a memory arrangement  210 , a display device  215 , an input/output (I/O) device  220 , a transceiver  225  and other components  230 . The other components  235  may include, for example, an audio input device, an audio output device, a power supply, a data acquisition device, ports to electrically connect the UE  110  to other electronic devices, etc. 
     The processor  205  may be configured to execute various types of software. For example, the processor may execute an application client  235  and an edge enabler client (EEC)  240 . The application client  235  may perform operations related to an application running on the UE  110  exchanging application data with a server via a network. The EEC  224  may perform operations related to establishing a connection to the edge data network  170 . The application client  235  and the EEC  240  are discussed in more detail below with regard to  FIG.  4   . 
     The above referenced software being executed by the processor  205  is only exemplary. The functionality associated with the software may also be represented as a separate incorporated component of the UE  110  or may be a modular component coupled to the UE  110 , e.g., an integrated circuit with or without firmware. For example, the integrated circuit may include input circuitry to receive signals and processing circuitry to process the signals and other information. The engines may also be embodied as one application or separate applications. In addition, in some UEs, the functionality described for the processor  205  is split among two or more processors such as a baseband processor and an applications processor. The exemplary embodiments may be implemented in any of these or other configurations of a UE. 
     The memory arrangement  210  may be a hardware component configured to store data related to operations performed by the UE  110 . The display device  215  may be a hardware component configured to show data to a user while the I/O device  220  may be a hardware component that enables the user to enter inputs. The display device  215  and the I/O device  220  may be separate components or integrated together such as a touchscreen. The transceiver  225  may be a hardware component configured to establish a connection with the 5G NR-RAN  120 , an LTE-RAN (not pictured), a legacy RAN (not pictured), a WLAN (not pictured), etc. Accordingly, the transceiver  225  may operate on a variety of different frequencies or channels (e.g., set of consecutive frequencies). 
       FIG.  3    shows an architecture  300  for enabling edge applications according to various exemplary embodiments. The architecture  200  will be described with regard to the network arrangement  100  of  FIG.  1   . 
     The exemplary embodiments will be described with regard to an authentication and authorization procedure between the EEC  240  of the UE  110  and the ECS  180 . Successful completion of the exemplary procedure may precede the flow of application data traffic between the edge data network  170  and the UE  110 . The architecture  300  provides a general example of the type of components that may interact with one another when the UE  110  is configured to exchange application data traffic with the edge data network  170 . A specific example of the exemplary authentication and authorization procedure will be provided below with regard to the signaling diagram  400  of  FIG.  4   . 
     The architecture  300  includes the UE  110 , the core network  130  and the edge data network  170 . The UE  110  may establish a connection to the edge data network  170  via the core network  130  and various other components (e.g., cell  120 A, the 5G NR RAN  120 , network functions, etc.). 
     In the architecture  300 , the various components are shown as being 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, etc.) are defined in the 3GPP Specifications. The exemplary architecture arrangement  300  is using these reference points in the manner in which they are defined in the 3GPP Specifications. Furthermore, while these interfaces are termed reference points throughout this description, it should be understood that these interfaces are not required to be direct wired or wireless connections, e.g., the interfaces may communicate via intervening hardware and/or software components. To provide an example, the UE  110  exchanges communications with the gNB  120 A. However, in the architecture  300  the UE  110  is shown as having a connection to the ECS  180 . However, this connection is not a direct communication link between the UE  110  and the ECS  180 . Instead, this is a connection that is facilitated by intervening hardware and software components. Thus, throughout this description the terms “connection,” “reference point” and “interface” may be used interchangeably to describe the interfaces between the various components in the architecture  300  and the network arrangement  100 . 
     During operation, application data traffic  305  may flow between the application client  235  running on the UE  110  and the edge application server (EAS)  172  of the edge data network  170 . The EAS  172  may be accessed through the core network  130  via uplink classifiers (CL) and branching points (NP) or in any other appropriate manner. Those skilled in the art will understand the variety of different types of operations and configurations relevant to an application client and an EAS. The operations performed by these components are beyond the scope of the exemplary embodiments. Instead, these components are included in the description of the architecture  300  to demonstrate that the exemplary authentication and authorization procedure between the UE  110  and the ECS  180  may precede the flow of application data traffic  305  between the UE  110  and the edge data network  170 . 
     The EEC  240  may be configured to provide supporting functions for the application client  235 . For example, the EEC  240  may perform operations related to concepts such as, but not limited to, the discovery of EASs that are available in an edge data network (e.g., EAS  172 ) and the retrieval and provisioning of configuration information that may enable the exchange of the application data traffic  305  between the application client  235  and the EAS  172 . To differentiate the EEC  240  from other EECs, the EEC  240  may be associated with a globally unique value (e.g., EEC ID) that identifies the EEC  240 . Further, reference to a single application client  235  and EEC  240  is merely provided for illustrative purposes, the UE  110  may be equipped with any appropriate number of application clients and EECs. 
     The edge data network  170  may also include an edge enabler server (EES)  174 . The EES  174  may be configured to provide supporting functions to the EAS  172  and the EEC  240  running on the UE  110 . For example, the EES  174  may perform operations related to concepts such as, but not limited to, provisioning configuration to enable the exchange of the application data traffic  305  between the UE  110  and the EAS  172  and providing information related to the EAS  172  to the EEC  235  running on the UE  110 . Those skilled in the art will understand the variety of different types of operations and configurations relevant to an EES. Further, reference to the edge data network  170  including a single EAS  172  and a single EES  174  is merely provided for illustrative purposes. In an actual deployment scenario, an edge data network may include any appropriate EASs and EESs interacting with any number of UEs. 
     The ECS  180  may be configured to provide supporting functions for the EEC  240  to connect the EES  174 . For example, the ECS  180  may perform operations related to concepts such as, but not limited to, provisioning of edge configuration information to the EEC  240 . The edge configuration information may include the information for the EEC  240  to connect to the EES  174  (e.g., service area information, etc.) and the information for establishing a connection with the EES  174  (e.g., uniform resource identifier (URI). Those skilled in the art will understand the variety of different types of operations and configurations relevant to an ECS. 
     In the network architecture  100  and the enabling architecture  300 , the ECS  180  is shown as being outside of the edge data network  170  and the core network  130 . However, this is merely provided for illustrative purposes. The ECS  180  may be deployed in any appropriate virtual and/or physical location (e.g., within the mobile network operator&#39;s domain or within a third party domain) and implemented via any appropriate combination of hardware, software and/or firmware. 
     As indicated above, the interaction between the ECS  180  and the EEC  240  running on the UE  110  may occur prior to the flow of the application data traffic  305 . The exemplary embodiments relate to an authentication and authorization procedure between the UE  110  and the ECS  180 . 
       FIG.  4    shows a signaling diagram  400  for an authentication and authorization procedure according to various exemplary embodiments. The signaling diagram  400  will be described with regard to the enabling architecture  300  of  FIG.  3   , the UE  110  of  FIG.  2    and the network arrangement  100  of  FIG.  1   . 
     The signaling diagram  400  includes the UE  110 , the AUSF  131 , the UDM  132 , the NEF  135 , and the ECS  180 . As will be described in more detail below, the credentials generated by primary authentication procedure (e.g., K AUSF ) may provide the basis for the for credentials of the exemplary authentication and authorization procedure described herein. 
     Those skilled in the art will understand that the primary authentication procedure (e.g., 5G AKA, EAP-AKA, etc.) generally refers to an authentication procedure between the UE  110  and the core network  130 . During the procedure, the AUSF  131  may generate a credential K AUSF  via authentication vector generation. The K AUSF  may then be used for further operations of the primary authentication procedure. Some characteristics of the K AUSF  include, i) the K AUSF  may be shared between the UE  110  and AUSF of the home public land mobile network (HPLMN) (e.g., AUSF  131 ) and ii) the K AUSF  may provide the basis of the subsequent 5G key hierarchy. 
     The signaling diagram  400  assumes that the UE  110  and the core network  130  have already successfully performed the primary authentication procedure and the credential (K AUSF ) is available. However, reference to K AUSF  is merely provided for illustrative purposes, the exemplary embodiments may apply to any similar type of 3GPP credential or information being used in in addition or instead of K AUSF . 
     In addition, for the purposes of the signaling diagram  400 , it may be considered that the credentials generated by primary authentication cannot be sent outside of the carrier&#39;s network. Further, it may also be considered that the UE  110  has already discovered the edge data network  170  and is permitted to initiate this exemplary edge computing authentication and authorization procedure. 
     In  405 , the UE  110  performs primary authentication with the network. As indicated above, the procedure may result in the credential (K AUSF ) being shared between the UE  110  and the AUSF  131 . However, the exemplary embodiments are not limited to the use of K AUSF , any other appropriate parameters may be utilized. 
     In  410 , the UE  110  generates and stores one or more credentials. Throughout this description, these credentials may be referred to as “K edge ” and “K edge ID.” However, reference to “K edge ” and “K edge ID” is merely for illustrative purposes, any appropriate credentials or parameters may be utilized. 
     In this example, the credential K edge  may be generated using a key derivation function (KDF). Those skilled in the art will understand that the KDF may be, for example, the KDF defined in Annex B.2.0 of 3GPP Technical Specification (TS) 33.220 or any other similar type of function. 
     The credential K edge  may be derived from credential K AUSF . For example, the input key for the KDF may be the K AUSF . When deriving K edge , the following parameters may also be used for the KDF: FC, P0, L0. Here, FC may represent a parameter used to distinguish between different instances of the KDF. The value for FC may be any appropriate value allocated by a 3GPP based entity. The Subscription permanent identifier (SUPI) or any other identifier associated with the UE  110  (e.g., generic public subscription identifier (GPSI), etc.) may be used for P0. The length of the P0 parameter (e.g., SUPI, GPSI, etc.) may be used for L0. 
     The K edge ID parameter may be used to uniquely identify a K edge  parameter. The K edge ID parameter may be generated in any appropriate manner. As described above, it may be considered that the credentials generated by primary authentication cannot be sent outside of the carrier&#39;s network. Thus, the K edge  may not be sent outside of the carrier network. However, the K edge ID parameter may be sent outside the network since it is not a credential but rather a parameter that uniquely identifies the K edge ID parameter. The use of the K edge ID parameter will be described in greater detail below. 
     In  415 , the AUSF  131  generates and stores one or more credentials. Here, the AUSF  131  generates the same credentials generated by the UE  110  in  410 . Thus, in this example, the AUSF  131  may also generate the credentials K edge  and K edge ID. Since the credential K AUSF  is shared between the UE  110  and the AUSF  131 , the UE  110  and the AUSF  131  may independently generate the same credentials. However, reference to K AUSF  is merely provided for illustrative purposes, any appropriate type of information may be used to provide the basis for the one or more credentials generated in  410  and  415 . 
     In  420 , the EEC  240  receives the one or more credentials generated by the UE  110 . For example, the EEC  240  may retrieve K edge  and K edge ID from the memory arrangement  210  of the UE  110  or these credentials may be provided to the EEC  240  by another process executed by the processor  205 . 
     In  425 , the EEC  240  may generate a multi-access edge computing (MEC) authorization parameter. Throughout this description, this parameter may be referred to as MEC EEC . The authorization parameter may be generated using K edge  and the EEC ID associated with the EEC  240 . For example, the MEC EEC  parameter may be generated using the SHA-256 hashing function. When deriving the MEC EEC  parameter, P0 and P1 may be used to form the input parameter S. Here, P0 represents K edge  and P1 represents the EEC ID. The input S may be equal to the concatenation P0∥P1. The MEC EEC  parameter is identified with the N least significant bits of the output of the SHA-246 function, e.g., 32 bits, 64 bits, etc. 
     In  430 , the UE  110  sends an application registration request to the ECS  180 . The application registration request may include information such as, but not limited to, EEC ID, MEC EEC  and the K edge ID. This message may be sent via non-access stratum (NAS), the user plane or in any other appropriate manner. 
     In  435 , the ECS  180  sends authentication verification message to the NEF  135  for verification. The authentication verification message may include contents similar to the application registration request (e.g., EEC ID, MEC EEC  and the K edge ID). 
     In  440 , the NEF  135  may send an authentication verification message to the UDM  132  for MEC EEC  verification. In  445 , the UDM  132  (and/or the AUSF  131 ) may retrieve K edge  using the K edge ID and may verify the MEC EEC  using the K edge  and the EEC ID. In other words, the UDM  132  (and/or the AUSF  131 ) may verify the received MEC EEC  by retrieving the credential generated in  410  based on its stored association to K edge ID. The UDM  132  (and/or the AUSF  131 ) may then generate a second, independent and distinct, instance of MEC EEC . If the second instance of MEC EEC  matches the MEC EEC  received in  435 , the verification process is a success. In this example, the verification process is a success. However, in an actual operating scenario, if a stored instance of K edge  cannot be found or the second instance of MEC EEC  does not match the MEC EEC  received in  435  the verification process has failed and the UE  110  may be unable to successfully complete the exemplary authentication and authorization procedure. 
     In  450 , the UDM  132  may send an authentication verification response to the NEF  135 . In this example, the verification process was a success. Thus, the authentication verification response may indicate a successful verification process. In other embodiments, an indication that the verification process failed or the lack of authentication verification response may indicate to the NEF  135  that authentication verification was not successful. 
     The operations described above in  440 - 450  were described above as being performed by the UDM  132 . However, in an actual operation scenario, these operations may be performed by the AUSF  131 , a combination of the AUSF  131  and the UDM  132  or by any other appropriate one or more network components. Thus, in the signaling diagram  400  the retrieval and verification process in  445  are shown as being associated with both the AUSF  131  and the UDM  132 . 
     In  455 , the NEF  135  sends an indication of the authentication verification response (e.g., success/fail) provided by the UDM  132  to the ECS  180 . Based on the verification result, the ECS  170  decides whether to accept or reject the authentication request. 
     In  460 , the ECS  180  sends an authentication accept or authentication reject message to the UE  110  (e.g., the EEC  240 ). The authentication accept message may indicate that the UE  110  is permitted to attempt to access the edge data network  170  and/or the EAS  172 . The authentication reject message may indicate that the UE  110  is not permitted to attempt to access the edge data network  170  and/or the EAS  172 . 
     Subsequent to the authentication accept message, various signaling may be performed between the UE  110  (e.g., the application client  235 , the EEC  240 , etc.) and the edge data network  170  (e.g., the EAS  172 , the EEC  174 , etc.) to establish a connection that may be used to exchange application data traffic between the UE  110  and edge data network  170 . To provide an example, a PDU session establishment procedure may be initiated. 
     Those skilled in the art will understand that the above-described exemplary embodiments may be implemented in any suitable software or hardware configuration or combination thereof. An exemplary hardware platform for implementing the exemplary embodiments may include, for example, an Intel x86 based platform with compatible operating system, a Windows OS, a Mac platform and MAC OS, a mobile device having an operating system such as iOS, Android, etc. The exemplary embodiments of the above described method may be embodied as a program containing lines of code stored on a non-transitory computer readable storage medium that, when compiled, may be executed on a processor or microprocessor. 
     Although this application described various embodiments each having different features in various combinations, those skilled in the art will understand that any of the features of one embodiment may be combined with the features of the other embodiments in any manner not specifically disclaimed or which is not functionally or logically inconsistent with the operation of the device or the stated functions of the disclosed embodiments. 
     It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users. 
     It will be apparent to those skilled in the art that various modifications may be made in the present disclosure, without departing from the spirit or the scope of the disclosure. Thus, it is intended that the present disclosure cover modifications and variations of this disclosure provided they come within the scope of the appended claims and their equivalent.

Metadata:
Filing Date: 20200806
Publication Date: 20240423
Grant Date: 20240423
Priority Date: 20200806
Inventors: GUO, SHU
ZHANG, DAWEI
XU, FANGLI
HU, HAIJING
LIANG, HUARUI
AGNEL, Mona
ROSSBACH, Ralf
VAMANAN, Sudeep Manithara
YANG, XIANGYING
CHEN, YUQIN
Assignee: APPLE INC
CPC Classifications: [{"code": "H04W12/068", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04W60/00", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W12/06", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04W12/068", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04W12/08", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04W60/00", "inventive": true, "first": false, "tree": "[]"}]
Family ID: 80119822