Patent Description:
Wireless mobile communication technology uses various standards and protocols to transmit data between a base station and a wireless communication device. Wireless communication system standards and protocols can include, for example, 3rd Generation Partnership Project (3GPP) long term evolution (LTE) (e.g., <NUM>), 3GPP new radio (NR) (e.g., <NUM>), and IEEE <NUM> standard for wireless local area networks (WLAN) (commonly known to industry groups as Wi-Fi®).

As contemplated by the 3GPP, different wireless communication systems standards and protocols can use various radio access networks (RANs) for communicating between a base station of the RAN (which may also sometimes be referred to generally as a RAN node, a network node, or simply a node) and a wireless communication device known as a user equipment (UE). 3GPP RANs can include, for example, global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), and/or Next-Generation Radio Access Network (NG-RAN).

Each RAN may use one or more radio access technologies (RATs) to perform communication between the base station and the UE. For example, the GERAN implements GSM and/or EDGE RAT, the UTRAN implements universal mobile telecommunication system (UMTS) RAT or other 3GPP RAT, the E-UTRAN implements LTE RAT (sometimes simply referred to as LTE), and NG-RAN implements NR RAT (sometimes referred to herein as <NUM> RAT, <NUM> NR RAT, or simply NR). In certain deployments, the E-UTRAN may also implement NR RAT. In certain deployments, NG-RAN may also implement LTE RAT.

A base station used by a RAN may correspond to that RAN. One example of an E-UTRAN base station is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly denoted as evolved Node B, enhanced Node B, eNodeB, or eNB). One example of an NG-RAN base station is a next generation Node B (also sometimes referred to as a or g Node B or gNB).

A RAN provides its communication services with external entities through its connection to a core network (CN). For example, E-UTRAN may utilize an Evolved Packet Core (EPC), while NG-RAN may utilize a <NUM> Core Network (5GC).

"<NPL> describes the security enhancements on the support for Edge Computing in the <NUM> Core network and application architecture for enabling Edge Applications.

Various embodiments are described with regard to a UE. However, reference to a UE is merely provided for illustrative purposes. The example 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.

<FIG> illustrates an example architecture of a wireless communication system <NUM>, according to embodiments disclosed herein. The following description is provided for an example wireless communication system <NUM> that operates in conjunction with the LTE system standards and/or <NUM> or NR system standards as provided by 3GPP technical specifications.

As shown by <FIG>, wireless communication system <NUM> includes UE <NUM> and UE <NUM> (although any number of UEs may be used). In this example, UE <NUM> and UE <NUM> are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks), but may also comprise any mobile or non-mobile computing device configured for wireless communication.

UE <NUM> and UE <NUM> may be configured to communicatively couple with a RAN <NUM>. In embodiments, RAN <NUM> may be NG-RAN, E-UTRAN, etc. UE <NUM> and UE <NUM> utilize connections (or channels) (shown as connection <NUM> and connection <NUM>, respectively) with RAN <NUM>, each of which comprises a physical communications interface. RAN <NUM> can include one or more base stations, such as base station <NUM> and base station <NUM>, that enable connection <NUM> and connection <NUM>.

In this example, connection <NUM> and connection <NUM> are air interfaces to enable such communicative coupling, and may be consistent with RAT(s) used by RAN <NUM>, such as, for example, an LTE and/or NR.

In some embodiments, UE <NUM> and UE <NUM> may also directly exchange communication data via a sidelink interface <NUM>. UE <NUM> is shown to be configured to access an access point (shown as AP <NUM>) via connection <NUM>. By way of example, connection <NUM> can comprise a local wireless connection, such as a connection consistent with any IEEE <NUM> protocol, wherein AP <NUM> may comprise a Wi-Fi® router. In this example, AP <NUM> may be connected to another network (for example, the Internet) without going through a CN <NUM>.

In embodiments, UE <NUM> and UE <NUM> can be configured to communicate using orthogonal frequency division multiplexing (OFDM) communication signals with each other or with base station <NUM> and/or base station <NUM> over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, an orthogonal frequency division multiple access (OFDMA) communication technique (e.g., for downlink communications) or a single carrier frequency division multiple access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect.

In some embodiments, all or parts of base station <NUM> or base station <NUM> may be implemented as one or more software entities running on server computers as part of a virtual network. In addition, or in other embodiments, base station <NUM> or base station <NUM> may be configured to communicate with one another via interface <NUM>. In embodiments where wireless communication system <NUM> is an LTE system (e.g., when CN <NUM> is an EPC), interface <NUM> may be an X2 interface. The X2 interface may be defined between two or more base stations (e.g., two or more eNBs and the like) that connect to an EPC, and/or between two eNBs connecting to the EPC. In embodiments where wireless communication system <NUM> is an NR system (e.g., when CN <NUM> is a 5GC), interface <NUM> may be an Xn interface. The Xn interface is defined between two or more base stations (e.g., two or more gNBs and the like) that connect to 5GC, between a base station <NUM> (e.g., a gNB) connecting to 5GC and an eNB, and/or between two eNBs connecting to 5GC (e.g., CN <NUM>).

RAN <NUM> is shown to be communicatively coupled to CN <NUM>. CN <NUM> may comprise one or more network elements <NUM>, which are configured to offer various data and telecommunications services to customers/subscribers (e.g., users of UE <NUM> and UE <NUM>) who are connected to CN <NUM> via RAN <NUM>. The components of CN <NUM> may be implemented in one physical device or separate physical devices including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium).

In embodiments, CN <NUM> may be an EPC, and RAN <NUM> may be connected with CN <NUM> via an S1 interface <NUM>. In embodiments, S1 interface <NUM> may be split into two parts, an S1 user plane (S1-U) interface, which carries traffic data between base station <NUM> or base station <NUM> and a serving gateway (S-GW), and the S1-MME interface, which is a signaling interface between base station <NUM> or base station <NUM> and mobility management entities (MMEs).

In embodiments, CN <NUM> may be a 5GC, and RAN <NUM> may be connected with CN <NUM> via an NG interface <NUM>. In embodiments, NG interface <NUM> may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between base station <NUM> or base station <NUM> and a user plane function (UPF), and the S1 control plane (NG-C) interface, which is a signaling interface between base station <NUM> or base station <NUM> and access and mobility management functions (AMFs).

Generally, an application server <NUM> may be an element offering applications that use internet protocol (IP) bearer resources with CN <NUM> (e.g., packet switched data services). Application server <NUM> can also be configured to support one or more communication services (e.g., VoIP sessions, group communication sessions, etc.) for UE <NUM> and UE <NUM> via CN <NUM>. Application server <NUM> may communicate with CN <NUM> through an IP communications interface <NUM>.

AKA procedures involve mutual authentication between a UE and the network to derive cryptographic keys that protect user-plane and control-plane data. Each <NUM>, <NUM>, and <NUM> generation defines some authentication method to allow authorized users to access network and reject unauthorized users. The 3GPP standards define evolved packet system-AKA (EPS-AKA) for <NUM> LTE systems. Similarly, the following three authentication methods are defined for <NUM> systems: <NUM>-AKA (<NUM>-AKA); extensible authentication protocol-AKA (EAP-AKA'); and extensible authentication protocol - transport layer security (EAP-TLS).

<FIG> illustrates a service based architecture <NUM> in a <NUM> system, according to one embodiment. 3GPP has proposed service based architecture <NUM> for core network with new network entities and new services to support a unified authentication framework. This framework makes the <NUM>-AKA procedure suitable for both open and access-network agnostic using three authentication methods, <NUM>-AKA, EAP-AKA', and EAP-TLS. The framework allows multiple security contexts which can be established with one authentication execution, allowing the UE to move from a 3GPP access network to a non-3GPP network without having to be reauthenticated.

As described in 3GPP TS <NUM>, service based architecture <NUM> comprises network functions such as an NSSF <NUM>, a NEF <NUM>, an NRF <NUM>, a PCF <NUM>, a UDM <NUM>, an AUSF <NUM>, an AMF <NUM>, an SMF <NUM>, and an AAnF <NUM>, for communication with a UE <NUM>, a (R)AN <NUM>, a UPF <NUM>, and a DN <NUM>. The NFs and NF services can communicate directly, referred to as Direct Communication, or indirectly via a SCP <NUM>, referred to as Indirect Communication. <FIG> also shows corresponding service-based interfaces including Nutm, Naf, Nudm, Npcf, Nsmf, Nnrf, Namf, Nnef, Nnssf, Nausf, and Naanf, as well as reference points N1, N2, N3, N4, and N6. A few example functions provided by the NFs shown in <FIG> are described below.

NSSF <NUM> supports functionality such as: selecting the set of Network Slice instances serving the UE; determining the Allowed NSSAI and, if needed, mapping to the Subscribed S-NSSAIs; determining the Configured NSSAI and, if needed, the mapping to the Subscribed S-NSSAIs; and/or determining the AMF Set to be used to serve the UE, or, based on configuration, a list of candidate AMF(s), possibly by querying the NRF.

A network exposure function (NEF), e.g., NEF <NUM>, supports exposure of capabilities and events. NF capabilities and events may be securely exposed by NEF <NUM> (e.g., for 3rd party, Application Functions, and/or Edge Computing). NEF <NUM> may store/retrieve information as structured data using a standardized interface (Nudr) to a UDR. NEF <NUM> may also secure provision of information from an external application to 3GPP network and may provide for the Application Functions to securely provide information to the 3GPP network (e.g., expected UE behavior, 5GLAN group information, and service specific information), wherein NEF <NUM> may authenticate and authorize and assist in throttling the Application Functions. NEF <NUM> may provide translation of internal-external information by translating between information exchanged with the AF and information exchanged with the internal network function. For example, NEF <NUM> translates between an AF-Service-Identifier and internal <NUM> Core information such as DNN and S-NSSAI. NEF <NUM> may handle masking of network and user sensitive information to external AF's according to the network policy. NEF <NUM> may receive information from other network functions (based on exposed capabilities of other network functions), and stores the received information as structured data using a standardized interface to a UDR. The stored information can be accessed and re-exposed by NEF <NUM> to other network functions and Application Functions, and used for other purposes such as analytics. For external exposure of services related to specific UE(s), NEF <NUM> may reside in the home public land mobile network (HPLMN). Depending on operator agreements, NEF <NUM> in the HPLMN may have interface(s) with NF(s) in the VPLMN. When a UE is capable of switching between EPC and 5GC, an SCEF+NEF may be used for service exposure.

NRF <NUM> supports service discovery function by receiving an NF Discovery Request from an NF instance or SCP and providing the information of the discovered NF instances to the NF instance or SCP. NRF <NUM> may also support P-CSCF discovery (specialized case of AF discovery by SMF), maintains the NF profile of available NF instances and their supported services, and/or notify about newly registered/updated/ deregistered NF instances along with its NF services to the subscribed NF service consumer or SCP. In the context of Network Slicing, based on network implementation, multiple NRFs can be deployed at different levels such as a PLMN level (the NRF is configured with information for the whole PLMN), a shared-slice level (the NRF is configured with information belonging to a set of Network Slices), and/or a slice-specific level (the NRF is configured with information belonging to an S-NSSAI). In the context of roaming, multiple NRFs may be deployed in the different networks, wherein the NRF(s) in the Visited PLMN (known as the vNRF) are configured with information for the visited PLMN, and wherein the NRF(s) in the Home PLMN (known as the hNRF) are configured with information for the home PLMN, referenced by the vNRF via an N27 interface.

PCF <NUM> supports a unified policy framework to govern network behavior. PCF <NUM> provides policy rules to Control Plane function(s) to enforce them. PCF <NUM> accesses subscription information relevant for policy decisions in a Unified Data Repository (UDR). PCF <NUM> may access the UDR located in the same PLMN as the PCF.

UDM <NUM> supports generation of AKA Authentication Credentials, User Identification Handling (e.g., storage and management of subscription permanent identifier (SUPI) for each subscriber in the <NUM> system), de-concealment of a privacy-protected subscription concealed identifier (SUCI), access authorization based on subscription data (e.g., roaming restrictions), UE's Serving NF Registration Management (e.g., storing serving AMF for UE, storing serving SMF for UE's PDU Session), service/session continuity (e.g., by keeping SMF/DNN assignment of ongoing sessions, MT-SMS delivery, Lawful Intercept Functionality (especially in outbound roaming cases where a UDM is the only point of contact for LI), subscription management, SMS management, 5GLAN group management handling, and/or external parameter provisioning (Expected UE Behavior parameters or Network Configuration parameters). To provide such functionality, UDM <NUM> uses subscription data (including authentication data) that may be stored in a UDR, in which case a UDM implements the application logic and may not require an internal user data storage and several different UDMs may serve the same user in different transactions. UDM <NUM> may be located in the HPLMN of the subscribers it serves, and may access the information of the UDR located in the same PLMN. UDM <NUM> may be similar to an HSS/HLR entity and hosts functions related to data management, such as the authentication credential repository and processing function (ARPF), which selects an authentication method based on subscriber identity and configured policy and computes the authentication data and keys for the authentication server function (AUSF) in some embodiments.

The subscription identifier de-concealing function (SIDF) decrypts a SUCI to obtain its long-term identity known as the SUPI, e.g., the IMSI. In <NUM>, a subscriber long-term identity is transmitted over the radio interfaces in an encrypted form. More specifically, a public key-based encryption is used to protect the SUPI. Therefore, only the SIDF has access to the private key associated with a public key distributed to UEs for encrypting their SUPIs.

AF <NUM> interacts with the Core Network to provide services that, for example, support the following: application influence on traffic routing; accessing NEF <NUM>; interacting with the Policy framework for policy control; and/or IMS interactions with 5GC. Based on operator deployment, Application Functions considered to be trusted by the operator can be allowed to interact directly with relevant Network Functions. Application Functions not allowed by the operator to access directly the Network Functions may use the external exposure framework via NEF <NUM> to interact with relevant Network Functions.

AUSF <NUM> supports authentication for 3GPP access and untrusted non-3GPP access. AUSF <NUM> may also provide support for Network Slice-Specific Authentication and Authorization. It is within a home network and performs authentication with a UE. It makes the decision on UE authentication, and may uses a backend for computing the authentication data and keys when <NUM>-AKA or EAP-AKA' is used.

AMF <NUM> supports termination of RAN CP interface (N2), termination of NAS (N1) for NAS ciphering and integrity protection, registration management, connection management, reachability management, Mobility Management, lawful intercept (for AMF events and interface to LI System), transport for SM messages between UE and SMF, transparent proxy for routing SM messages, Access Authentication, Access Authorization, transport for SMS messages between UE and SMSF, security anchor function (SEAF), Location Services management for regulatory services, transport for Location Services messages between UE and LMF as well as between RAN and LMF, EPS Bearer ID allocation for interworking with EPS, UE mobility event notification, Control Plane CIoT 5GS Optimization, User Plane CIoT 5GS Optimization, provisioning of external parameters (Expected UE Behavior parameters or Network Configuration parameters), and/or Network Slice-Specific Authentication and Authorization. Some or all of the AMF functionalities may be supported in a single instance of AMF <NUM>. Regardless of the number of Network functions, in certain embodiments there is only one NAS interface instance per access network between the UE and the CN, terminated at one of the Network functions that implements at least NAS security and Mobility Management. AMF <NUM> may also include policy related functionalities. AMF <NUM> receives connection and session related information from the User Equipment (UE) (N1/N2) for handling connection and mobility management tasks.

The SEAF resides within serving network (closely with AMF) and acts as "middleman" during the authentication process between a UE and its home network. It can reject an authentication from the UE, but it relies on the UE's home network to accept the authentication.

A non-3GPP interworking Function (N3IWF) is an entity which acts as a VPN server to allow the UE to access the <NUM> core over untrusted, non-3GPP networks through IPsec tunnels. There can be multiple security contexts can be established with one authentication execution, allowing the UE to move from a 3GPP access network to a non-3GPP network without having to be reauthenticated.

In addition to the functionalities described above, AMF <NUM> may include the following functionality to support non-3GPP access networks: support of N2 interface with N3IWF/TNGF, over which some information (e.g., 3GPP Cell Identification) and procedures (e.g., Handover related) defined over 3GPP access may not apply, and non-3GPP access specific information may be applied that do not apply to 3GPP accesses; support of NAS signaling with a UE over N3IWF/TNGF, wherein some procedures supported by NAS signaling over 3GPP access may be not applicable to untrusted non-3GPP (e.g., Paging) access; support of authentication of UEs connected over N3IWF/TNGF; management of mobility, authentication, and separate security context state(s) of a UE connected via a non-3GPP access or connected via a 3GPP access and a non-3GPP access simultaneously; support a coordinated RM management context valid over a 3GPP access and a Non 3GPP access; and/or support dedicated CM management contexts for the UE for connectivity over non-3GPP access. Not all of the above functionalities may be required to be supported in an instance of a Network Slice.

SMF <NUM> supports Session Management (e.g., Session Establishment, modify and release, including tunnel maintain between UPF and AN node), UE IP address allocation & management (including optional Authorization) wherein the UE IP address may be received from a UPF or from an external data network, DHCPv4 (server and client) and DHCPv6 (server and client) functions, functionality to respond to Address Resolution Protocol requests and/or IPv6 Neighbor Solicitation requests based on local cache information for the Ethernet PDUs (e.g., the SMF responds to the ARP and/or the IPv6 Neighbor Solicitation Request by providing the MAC address corresponding to the IP address sent in the request), selection and control of User Plane functions including controlling the UPF to proxy ARP or IPv6 Neighbor Discovery or to forward all ARP/IPv6 Neighbor Solicitation traffic to the SMF for Ethernet PDU Sessions, traffic steering configuration at the UPF to route traffic to proper destinations, <NUM> VN group management (e.g., maintain the topology of the involved PSA UPFs, establish and release the N19 tunnels between PSA UPFs, configure traffic forwarding at UPF to apply local switching, and/or N6-based forwarding or N19-based forwarding), termination of interfaces towards Policy control functions, lawful intercept (for SM events and interface to LI System), charging data collection and support of charging interfaces, control and coordination of charging data collection at the UPF, termination of SM parts of NAS messages, Downlink Data Notification, Initiator of AN specific SM information sent via AMF over N2 to AN, determination of SSC mode of a session, Control Plane CIoT 5GS Optimization, header compression, acting as I-SMF in deployments where I-SMF can be inserted/removed/relocated, provisioning of external parameters (Expected UE Behavior parameters or Network Configuration parameters), P-CSCF discovery for IMS services, roaming functionality (e.g., handle local enforcement to apply QoS SLAs (VPLMN), charging data collection and charging interface (VPLMN), and/or lawful intercept (in VPLMN for SM events and interface to LI System), interaction with external DN for transport of signaling for PDU Session authentication/authorization by external DN, and/or instructing UPF and NG-RAN to perform redundant transmission on N3/N9 interfaces. Some or all of the SMF functionalities may be supported in a single instance of a SMF. However, in certain embodiments, not all of the functionalities are required to be supported in an instance of a Network Slice. In addition to the functionalities, the SMF <NUM> may include policy related functionalities.

SCP <NUM> includes one or more of the following functionalities: Indirect Communication; Delegated Discovery; message forwarding and routing to destination NF/NF services; communication security (e.g., authorization of the NF Service Consumer to access the NF Service Producer's API), load balancing, monitoring, overload control, etc.; and/or optionally interact with the UDR, to resolve the UDM Group ID/UDR Group ID/AUSF Group ID/PCF Group ID/CHF Group ID/HSS Group ID based on UE identity (e.g., SUPI or IMPI/IMPU). Some or all of the SCP functionalities may be supported in a single instance of an SCP. In certain embodiments, SCP <NUM> may be deployed in a distributed manner and/or more than one SCP can be present in the communication path between NF Services. SCPs can be deployed at PLMN level, shared-slice level, and slice-specific level. It may be left to operator deployment to ensure that SCPs can communicate with relevant NRFs.

UE <NUM> may include a device with radio communication capabilities. For example, UE <NUM> may comprise a smartphone (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks). UE <NUM> may also comprise any mobile or non-mobile computing device, such as Personal Data Assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device including a wireless communications interface. A UE may also be referred to as a client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, or reconfigurable mobile device. UE <NUM> may comprise an IoT UE, which can comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections. An IoT UE can utilize technologies (e.g., M2M, MTC, or mMTC technology) for exchanging data with an MTC server or device via a PLMN, other UEs using ProSe or D2D communications, sensor networks, or IoT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An IoT network describes interconnecting IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure). The IoT UEs may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate the connections of the IoT network.

UE <NUM> may be configured to connect or communicatively couple with (R)AN <NUM> through a radio interface <NUM>, which may be a physical communication interface or layer configured to operate with cellular communication protocols such as a GSM protocol, a CDMA network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a UMTS protocol, a 3GPP LTE protocol, a <NUM> protocol, a NR protocol, and the like. For example, UE <NUM> and (R)AN <NUM> may use a Uu interface (e.g., an LTE-Uu interface) to exchange control plane data via a protocol stack comprising a PHY layer, a MAC layer, an RLC layer, a PDCP layer, and an RRC layer. A DL transmission may be from (R)AN <NUM> to the UE <NUM> and a UL transmission may be from UE <NUM> to (R)AN <NUM>. UE <NUM> may further use a sidelink to communicate directly with another UE (not shown) for D2D, P2P, and/or ProSe communication. For example, a ProSe interface may comprise one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

(R)AN <NUM> can include one or more access nodes, which may be referred to as base stations (BSs), NodeBs, evolved NodeBs (eNBs), next Generation NodeBs (gNB), RAN nodes, controllers, transmission reception points (TRPs), and so forth, and can comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell). (R)AN <NUM> may include one or more RAN nodes for providing macrocells, picocells, femtocells, or other types of cells. A macrocell may cover a relatively large geographic area (e.g., several kilometers in radius) and may allow unrestricted access by UEs with service subscription. A picocell may cover a relatively small geographic area and may allow unrestricted access by UEs with service subscription. A femtocell may cover a relatively small geographic area (e.g., a home) and may allow restricted access by UEs having an association with the femtocell (e.g., UEs in a Closed Subscriber Group (CSG), UEs for users in the home, etc.).

Although not shown, multiple RAN nodes (such as (R)AN <NUM>) may be used, wherein an Xn interface is defined between two or more nodes. In some implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. The Xn-U may provide non-guaranteed delivery of user plane PDUs and support/provide data forwarding and flow control functionality. The Xn-C may provide management and error handling functionality, functionality to manage the Xn-C interface; mobility support for UE <NUM> in a connected mode (e.g., CM-CONNECTED) including functionality to manage the UE mobility for connected mode between one or more (R)AN nodes. The mobility support may include context transfer from an old (source) serving (R)AN node to new (target) serving (R)AN node; and control of user plane tunnels between old (source) serving (R)AN node to new (target) serving (R)AN node.

UPF <NUM> may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point of interconnect to DN <NUM>, and a branching point to support multi-homed PDU session. UPF <NUM> may also perform packet routing and forwarding, packet inspection, enforce user plane part of policy rules, lawfully intercept packets (UP collection); traffic usage reporting, perform QoS handling for user plane (e.g. packet filtering, gating, UL/DL rate enforcement), perform Uplink Traffic verification (e.g., SDF to QoS flow mapping), transport level packet marking in the uplink and downlink, and downlink packet buffering and downlink data notification triggering. UPF <NUM> may include an uplink classifier to support routing traffic flows to a data network. DN <NUM> may represent various network operator services, Internet access, or third party services. DN <NUM> may include, for example, an application server.

<FIG> also shows an example of a network model of AKMA, as well as the interfaces between network function and nodes. AKMA anchor function (AAnF), AAnF <NUM>, is shown deployed as a standalone function. Other embodiments may collocate an AAnF with AUSF <NUM> or with NEF <NUM>, according to operators' deployment scenarios. AAnF <NUM> is the anchor function in the HPLMN that generates the key material to be used between UE <NUM> and AF <NUM> and maintains UE AKMA contexts. AAnF <NUM> enables the AKMA Anchor Key (KAKMA) derivation for AKMA service. Before invoking AKMA service, UE <NUM> shall have successfully registered to the <NUM> core, which results in KAUSF being stored at AUSF <NUM> and UE <NUM> after a successful <NUM> primary authentication. Additional details of AKMA are described later with reference to <FIG> and <FIG>.

<FIG> shows a <NUM>-AKA primary authentication procedure. There are two phases in <NUM> AKA/EAP-AKA': initiation procedure and authentication procedure.

In the initiation procedure, a UE sends identification to SEAF in VPLMN. SEAF sends the authentication request to AUSF in HPLMN. The AUSF provides an authorization request to the UDM/ARPF/SIDF.

The authentication procedure entails authentication vector generation, in which the AV includes the RAND, authentication token (AUTN), expected response (XRES*), and KAUSF. The KAUSF may be securely stored in the AUSF based on the home operator's policy on using such key. The AUSF derives the KSEAF (anchor key) from KAUSF and sends the challenge message to the SEAF. At receipt of the RAND and AUTN, the universal subscriber identity module (USIM) computes a response RES and returns RES, CK, IK to the UE. The mobile equipment (ME) compute RES* from RES and sends it back. The SEAF computes HRES* from RES* and compares HRES* with HXRES*. If successful, it forwards RES* to the AUSF. The AUSF compares the received RES* with the stored XRES*, if succeed, the authentication is successful and AUSF indicate to SEAF.

A UE generates KAUSF by itself. If the UE is a genuine UE, then it is able to generate the correct KAUSF, which is same with the one generated by the network (UDM/ARPF). Details on KAUSF generation are available in 3GPP TS <NUM>, clause <NUM>. <NUM>, in which the UE generates the KAUSF after receiving necessary parameters from the network.

<FIG> shows a key hierarchy in <NUM>. KAUSF is common between UE and AUSF in the home network and is the basis of the subsequent key hierarchy. KAUSF is not delivered, but generated separately by a UE and network. Since a UE and the network have the same root key, they generate the same KAUSF. And the parameters used for calculating the KAUSF are delivered from the network to the UE.

<FIG> shows a message sequence <NUM> for deriving KAKMA after primary authentication (see e.g., <FIG>), as described in 3GPP TS <NUM>. AKMA is based on KAUSF and, after AKMA procedure, a UE <NUM> and an AAnF <NUM> will both possess the KAKMA and A-KID information.

<FIG> shows an AKMA key hierarchy. The key hierarchy includes the following keys: KAUSF, KAKMA, and KAF. KAUSF is generated by AUSF. The KAKMA is derived by a ME and an AUSF from KAUSF. The KAF is a key derived by an ME and an AAnF from KAKMA.

<FIG> shows an architecture <NUM> for enabling edge applications, as described in 3GPP TS <NUM>. An edge data network (EDN), EDN <NUM>, is a local data network. Edge application server(s) (EAS), EAS <NUM>, and edge enabler server(s), EES <NUM>, are contained within EDN <NUM>. An edge configuration server (ECS), ECS <NUM>, provides configurations related to EES <NUM>, including details of EDN <NUM> hosting EES <NUM>. A UE <NUM> contains application client(s) <NUM> and an edge enabler client (EEC), EEC <NUM>. EAS <NUM>, EES <NUM>, and ECS <NUM> may interact with a 3GPP core network <NUM>.

ECS <NUM> provides supporting functions needed for EEC <NUM> to connect with EES <NUM>. Functionalities of ECS <NUM> include provisioning of edge configuration information to EEC <NUM>. The edge configuration information includes the following: information for EEC <NUM> to connect to EES <NUM>, e.g., service area information applicable to local area data network (LADN); and information for establishing a connection with EES <NUM>, such as a uniform resource identifier (URI).

EEC <NUM> provides supporting functions needed for application client(s). Functionalities of EEC <NUM> include the following: retrieval and provisioning of configuration information to enable the exchange of application data traffic with EAS <NUM>; and discovery of EASes <NUM> available in EDN <NUM>.

An EEC ID is a globally unique value that identifies EECs. One or more EEC(s) may be located in a UE.

This disclosure also addresses some technical approaches and security concerns for AKMA in edge applications. Initially, it is noted that the EEC ID may be allocated by the global authorities, such GSMA, ITU, 3GPP, and the like. It is assumed an EES has stored all the EEC IDs under its control and delivers those EEC IDs to every EEC during the registration procedure in the application layer. An NEF has access to the EEC IDs under some EES when the NEF has interfaces with those EDNs. In the current SA3 3GPP TR <NUM>, there are AKMA based solutions for authentication between EEC and ECS/EES. A security concern is that, AKMA is per UE, which means one UE only has one KAKMA with the AAnF. However, there will be more than one EEC in one UE, so when AKMA is used for the authentication for EEC, some adaptation is described to achieve the authentication. This disclosure proposes techniques for authentication between EEC and ECS/EAS based on AKMA, which in some embodiments functionally entails a combination of the EEC ID and AKMA.

<FIG> shows authentication <NUM> between EEC and ECS/EES based on AKMA through AAnF. The "/" means that the functions described below for an ECS could also be performed by an EES.

Initially, a UE <NUM> performs primary authentication <NUM> with the network. KAUSF is known by UE <NUM> and AUSF <NUM> in a home network. UE <NUM> generates <NUM>AKMA and A-KID following AKMA procedure in 3GPP TS <NUM>, and stores them securely.

An AAnF <NUM> generates <NUM>AKMA and A-KID following AKMA procedure in 3GPP TS <NUM>, and stores them securely.

An EEC, such as EEC <NUM> fetches <NUM> the KAKMA and generates Kedge from KAKMA and EEC ID. In this way, there is one KAKMA and multiple Kedge in every UE. An EEC also computes <NUM> MACEEC using the KAKMA and EEC ID.

UE <NUM> sends <NUM> an application registration request message (including EEC ID, MACEEC, A-KID paramters) to an ECS <NUM>. Whether this message is sent using NAS or user plane is optional. Also note, that an EES <NUM> could perform similar authentication functions as those described for ECS <NUM>.

ECS <NUM> sends <NUM> an authentication verification (including EEC ID, MACEEC, A-KID parameters) to AAnF <NUM> for verification.

AAnF <NUM> retrieves <NUM>AKMA using A-KID, and calculates Kedge and then verifies MACEEC using the Kedge and EEC ID parameters.

If AAnF <NUM> has a successful verification, then AAnF <NUM> sends <NUM> an authentication verification response (success) message back to ECS <NUM>, otherwise, AAnF <NUM> sends an authentication verification response (fail) message to ECS <NUM>.

Based on the verification results, ECS <NUM> decides whether to accept or reject the authentication request, and sends <NUM> an authentication request accept/rejection message to EEC <NUM> in UE <NUM>.

UE <NUM> and AAnF <NUM> have a same method to generate Kedge based on KAKMA. In some embodiments to derive Kedge, it is generated using a key derivation function (KDF) defined in Annex B. <NUM> of 3GPP TS <NUM>(V17.

When deriving a Kedge from KAKMA, the following parameters are used to form the input string S to the KDF: FC = xxxx, which is allocated by 3GPP specifications (B <NUM> in TS <NUM>, Annex B); P0 = EEC ID; L0 = length of <EEC ID>. The input key, KEY, shall be KAKMA in some embodiments. In another embodiment to derive Kedge, it is equal to (KAKMA||EEC ID), i.e., a concatenation of these two parameters. For example, KAKMA is <NUM> (binary), EEC ID is <NUM> (binary), then KAKMA||EEC ID would be <NUM>. In the third embodiment to derive Kedge, it is equal to (KAKMA XOR EEC ID), i.e., a XOR calculation of these two parameters. Other logic operations ("OR") are also possible, in case the length of the Kedge is the same with KAKMA.

To calculate MACEEC, when deriving it in the UE and AAnF, the following parameters are used to form the input string S to the SHA-<NUM> hashing algorithm: P0 = KAKMA and P1 = EEC ID. The input string S is equal to the concatenation P0||P1 (of the P0 and P1). The MACEEC is identified with the N least significant bits of the output of the SHA-<NUM> function. N could be <NUM> or <NUM> bits, or other lengths, in some embodiments.

<FIG> shows a method <NUM>, performed by a UE configured to communicate in a <NUM> network, of authentication between an EEC of the UE and an ECS or an EAS (ECS/EAS)) based on an architecture for authentication and key management for applications (AKMA). In block <NUM>, method <NUM> performs primary authentication with the <NUM> network to obtain a KAUSF. In block <NUM>, method <NUM> generates a KAKMA and an A-KID. In block <NUM>, method <NUM> provides to the EEC the KAKMA and an EEC identifier (ID) for the EEC to generate a Kedge, the KAKMA and the EEC ID being used by the EEC to compute a MACEEC. In block <NUM>, method <NUM> sends to the ECS or the EAS an application registration request, the application registration request including the EEC ID, the MACEEC, and the A-KID.

Embodiments contemplated herein include an apparatus comprising means to perform one or more elements of method <NUM>. This apparatus may be, for example, an apparatus of a UE (such as a wireless device <NUM> that is a UE, as described herein).

Embodiments contemplated herein include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of method <NUM>. This non-transitory computer-readable media may be, for example, a memory of a UE (such as a memory <NUM> of a wireless device <NUM> that is a UE, as described herein).

Embodiments contemplated herein include an apparatus comprising logic, modules, or circuitry to perform one or more elements of method <NUM>. This apparatus may be, for example, an apparatus of a UE (such as a wireless device <NUM> that is a UE, as described herein).

Embodiments contemplated herein include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of method <NUM>. This apparatus may be, for example, an apparatus of a UE (such as a wireless device <NUM> that is a UE, as described herein).

Embodiments contemplated herein include a signal as described in or related to one or more elements of method <NUM>.

Embodiments contemplated herein include a computer program or computer program product comprising instructions, wherein execution of the program by a processor is to cause the processor to carry out one or more elements of method <NUM>. The processor may be a processor of a UE (such as a processor(s) <NUM> of a wireless device <NUM> that is a UE, as described herein). These instructions may be, for example, located in the processor and/or on a memory of the UE (such as a memory <NUM> of a wireless device <NUM> that is a UE, as described herein).

<FIG> illustrates a system <NUM> for performing signaling <NUM> between a wireless device <NUM> and a network device <NUM>, according to embodiments disclosed herein. System <NUM> may be a portion of a wireless communications system as herein described. Wireless device <NUM> may be, for example, a UE of a wireless communication system. Network device <NUM> may be, for example, a base station (e.g., an eNB or a gNB) of a wireless communication system.

Wireless device <NUM> may include one or more processor(s) <NUM>. Processor(s) <NUM> may execute instructions such that various operations of wireless device <NUM> are performed, as described herein. Processor(s) <NUM> may include one or more baseband processors implemented using, for example, a central processing unit (CPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a controller, a field programmable gate array (FPGA) device, another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein.

Wireless device <NUM> may include a memory <NUM>. Memory <NUM> may be a non-transitory computer-readable storage medium that stores instructions <NUM> (which may include, for example, the instructions being executed by processor(s) <NUM>). Instructions <NUM> may also be referred to as program code or a computer program. Memory <NUM> may also store data used by, and results computed by, processor(s) <NUM>.

Wireless device <NUM> may include one or more transceiver(s) <NUM> that may include radio frequency (RF) transmitter and/or receiver circuitry that use antenna(s) <NUM> of wireless device <NUM> to facilitate signaling (e.g., signaling <NUM>) to and/or from wireless device <NUM> with other devices (e.g., network device <NUM>) according to corresponding RATs.

Wireless device <NUM> may include one or more antenna(s) <NUM> (e.g., one, two, four, or more). For embodiments with multiple antenna(s) <NUM>, wireless device <NUM> may leverage the spatial diversity of such multiple antenna(s) <NUM> to send and/or receive multiple different data streams on the same time and frequency resources. This behavior may be referred to as, for example, multiple input multiple output (MIMO) behavior (referring to the multiple antennas used at each of a transmitting device and a receiving device that enable this aspect). MIMO transmissions by wireless device <NUM> may be accomplished according to precoding (or digital beamforming) that is applied at wireless device <NUM> that multiplexes the data streams across antenna(s) <NUM> according to known or assumed channel characteristics such that each data stream is received with an appropriate signal strength relative to other streams and at a desired location in the spatial domain (e.g., the location of a receiver associated with that data stream). Certain embodiments may use single user MIMO (SU-MIMO) methods (where the data streams are all directed to a single receiver) and/or multi user MIMO (MU-MIMO) methods (where individual data streams may be directed to individual (different) receivers in different locations in the spatial domain).

In certain embodiments having multiple antennas, wireless device <NUM> may implement analog beamforming techniques, whereby phases of the signals sent by antenna(s) <NUM> are relatively adjusted such that the (joint) transmission of antenna(s) <NUM> can be directed (this is sometimes referred to as beam steering).

Wireless device <NUM> may include one or more interface(s) <NUM>. Interface(s) <NUM> may be used to provide input to or output from wireless device <NUM>. For example, a wireless device <NUM> that is a UE may include interface(s) <NUM> such as microphones, speakers, a touchscreen, buttons, and the like in order to allow for input and/or output to the UE by a user of the UE. Other interfaces of such a UE may be made up of made up of transmitters, receivers, and other circuitry (e.g., other than transceiver(s) <NUM>/antenna(s) <NUM> already described) that allow for communication between the UE and other devices and may operate according to known protocols (e.g., Wi-Fi®, Bluetooth®, and the like).

Wireless device <NUM> may include an authentication module <NUM>. authentication module <NUM> may be implemented via hardware, software, or combinations thereof. For example, authentication module <NUM> may be implemented as a processor, circuit, and/or instructions <NUM> stored in memory <NUM> and executed by processor(s) <NUM>. In some examples, authentication module <NUM> may be integrated within processor(s) <NUM> and/or transceiver(s) <NUM>. For example, authentication module <NUM> may be implemented by a combination of software components (e.g., executed by a DSP or a general processor) and hardware components (e.g., logic gates and circuitry) within processor(s) <NUM> or transceiver(s) <NUM>.

Authentication module <NUM> may be used for various aspects of the present disclosure, for example, aspects of <FIG>. For instance, authentication module <NUM> is configured to perform method <NUM>.

Network device <NUM> may include one or more processor(s) <NUM>. Processor(s) <NUM> may execute instructions such that various operations of network device <NUM> are performed, as described herein. Processor(s) <NUM> may include one or more baseband processors implemented using, for example, a CPU, a DSP, an ASIC, a controller, an FPGA device, another hardware device, a firmware device, or any combination thereof configured to perform the operations described herein.

Network device <NUM> may include a memory <NUM>. Memory <NUM> may be a non-transitory computer-readable storage medium that stores instructions <NUM> (which may include, for example, the instructions being executed by processor(s) <NUM>). Instructions <NUM> may also be referred to as program code or a computer program. Memory <NUM> may also store data used by, and results computed by, processor(s) <NUM>.

Network device <NUM> may include one or more transceiver(s) <NUM> that may include RF transmitter and/or receiver circuitry that use antenna(s) <NUM> of network device <NUM> to facilitate signaling (e.g., signaling <NUM>) to and/or from network device <NUM> with other devices (e.g., wireless device <NUM>) according to corresponding RATs.

Network device <NUM> may include one or more antenna(s) <NUM> (e.g., one, two, four, or more). In embodiments having multiple antenna(s) <NUM>, network device <NUM> may perform MIMO, digital beamforming, analog beamforming, beam steering, etc., as has been described.

Network device <NUM> may include one or more interface(s) <NUM>. Interface(s) <NUM> may be used to provide input to or output from network device <NUM>. For example, a network device <NUM> that is a base station may include interface(s) <NUM> made up of transmitters, receivers, and other circuitry (e.g., other than transceiver(s) <NUM>/antenna(s) <NUM> already described) that enables the base station to communicate with other equipment in a core network, and/or that enables the base station to communicate with external networks, computers, databases, and the like for purposes of operations, administration, and maintenance of the base station or other equipment operably connected thereto.

Network device <NUM> may include an authentication module <NUM>. Authentication module <NUM> may be implemented via hardware, software, or combinations thereof. For example, authentication module <NUM> may be implemented as a processor, circuit, and/or instructions <NUM> stored in memory <NUM> and executed by processor(s) <NUM>. In some examples, authentication module <NUM> may be integrated within processor(s) <NUM> and/or transceiver(s) <NUM>. For example, authentication module <NUM> may be implemented by a combination of software components (e.g., executed by a DSP or a general processor) and hardware components (e.g., logic gates and circuitry) within processor(s) <NUM> or transceiver(s) <NUM>.

authentication module <NUM> may be used for various aspects of the present disclosure, for example, aspects of <FIG>. For instance, authentication module <NUM> is configured to perform any of the functions of any of AAnFs <NUM>, ECS <NUM>, or EES <NUM>.

For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and/or methods as set forth herein. For example, a baseband processor as described herein in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth herein. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth herein.

Any of the above described embodiments may be combined with any other embodiment (or combination of embodiments), unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

Embodiments and implementations of the systems and methods described herein may include various operations, which may be embodied in machine-executable instructions to be executed by a computer system. A computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components that include specific logic for performing the operations or may include a combination of hardware, software, and/or firmware.

It should be recognized that the systems described herein include descriptions of specific embodiments. These embodiments can be combined into single systems, partially combined into other systems, split into multiple systems or divided or combined in other ways. In addition, it is contemplated that parameters, attributes, aspects, etc. of one embodiment can be used in another embodiment. The parameters, attributes, aspects, etc. are merely described in one or more embodiments for clarity, and it is recognized that the parameters, attributes, aspects, etc. can be combined with or substituted for parameters, attributes, aspects, etc. of another embodiment unless specifically disclaimed herein.

Claim 1:
A method, performed by a user equipment, UE, (<NUM>, <NUM>) configured to communicate in a <NUM> network, of authentication between an edge enabler client, EEC, (<NUM>, <NUM>) of the UE (<NUM>, <NUM>) and an edge configuration server, ECS, (<NUM>, <NUM>) or an edge enabler server, EES, (<NUM>, <NUM>) based on an architecture for authentication and key management for applications, AKMA, the method comprising:
performing primary authentication with the <NUM> network to obtain a KAUSF
generating a KAKMA and an A-KID;
providing to the EEC (<NUM>, <NUM>) the KAKMA and an EEC identifier, ID, for the EEC (<NUM>, <NUM>) to generate a Kedge, the KAKMA and the EEC ID being used by the EEC (<NUM>, <NUM>) to compute a MACEEC; and
sending to the ECS (<NUM>, <NUM>) or the EES (<NUM>, <NUM>) an application registration request, the application registration request including the EEC ID, the MACEEC, and the A-KID.