User consent at application enablement layer

Abstract

The present application relates to devices and components including apparatus, systems, and methods for user consent at an application enablement layer of a network.

Description

USER CONSENT AT APPLICATION ENABLEMENT LAYERFIELD

[0001] This application relates to wireless network and, more specifically, to technologies for user consent at an application enablement layer.BACKGROUND

[0002] Various 3rd Generation Partnership Project (3GPP) Technical Specifications (TSs) refer to requirements to obtain user consent for information sharing. It is desired to improve user consent mechanisms that are compatible with developing architectures and signaling procedures defined by these 3GPP TSs.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] FIG. 1 illustrates a network environment in accordance with some embodiments.

[0004] FIG. 2 illustrates an access network in accordance with some embodiments.

[0005] FIG. 3 illustrates a registration procedure in accordance with some embodiments.

[0006] FIG. 4 illustrates a discovery procedure in accordance with some embodiments.

[0007] FIG. 5 illustrates an operational flow / algorithmic structure in accordance with some embodiments.

[0008] FIG. 6 illustrates another operational flow / algorithmic structure in accordance with some embodiments.

[0009] FIG. 7 illustrates another operational flow / algorithmic structure in accordance with some embodiments.

[0010] FIG. 8 illustrates a device in accordance with some embodiments.DETAILED DESCRIPTION

[0011] The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, and  techniques in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of the present document, the phrases “A / B” and “A or B” mean (A) , (B) , or (A and B) ; and the phrase “based on A” means “based at least in part on A, ” for example, it could be “based solely on A” or it could be “based in part on A. ”

[0012] The following is a glossary of terms that may be used in this disclosure.

[0013] The term “circuitry” as used herein refers to, is part of, or includes hardware components that are configured to provide the described functionality. The hardware components may include an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) or memory (shared, dedicated, or group) , an application specific integrated circuit (ASIC) , a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA) , a programmable logic device (PLD) , a complex PLD (CPLD) , a high-capacity PLD (HCPLD) , a structured ASIC, or a programmable system-on-a-chip (SoC) ) , or a digital signal processor (DSP) . In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

[0014] The term “processor circuitry” as used herein refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, or transferring digital data. The term “processor circuitry” may refer an application processor, baseband processor, a central processing unit (CPU) , a graphics processing unit, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, or functional processes.

[0015] The term “interface circuitry” as used herein refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces, for example, buses, I / O interfaces, peripheral component interfaces, and network interface cards.

[0016] The term “user equipment” or “UE” as used herein refers to a device with radio communication capabilities that may allow a user to access network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, 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. Furthermore, the term “user equipment” or “UE” may include any type of wireless / wired device or any computing device including a wireless communications interface.

[0017] The term “computer system” as used herein refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” or “system” may refer to multiple computer devices or multiple computing systems that are communicatively coupled with one another and configured to share computing or networking resources.

[0018] The term “resource” as used herein refers to a physical or virtual device, a physical or virtual component within a computing environment, or a physical or virtual component within a particular device, such as computer devices, mechanical devices, memory space, processor / CPU time, processor / CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input / output operations, ports or network sockets, channel / link allocation, throughput, memory usage, storage, network, database and applications, or workload units. A “hardware resource” may refer to compute, storage, or network resources provided by physical hardware elements. A “virtualized resource” may refer to compute, storage, or network resources provided by virtualization infrastructure to an application, device, or system. The term “network resource” or “communication resource” may refer to resources that are accessible by computer devices / systems via a communications network. The term “system resources” may refer to any kind of shared entities to provide  services and may include computing or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.

[0019] The term “channel” as used herein refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term “channel” may be synonymous with or equivalent to “communications channel, ” “data communications channel, ” “transmission channel, ” “data transmission channel, ” “access channel, ” “data access channel, ” “link, ” “data link, ” “carrier, ” “radio-frequency carrier, ” or any other like term denoting a pathway or medium through which data is communicated. Additionally, the term “link” as used herein refers to a connection between two devices for the purpose of transmitting and receiving information.

[0020] The terms “instantiate, ” “instantiation, ” and the like as used herein refers to the creation of an instance. An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code.

[0021] The term “connected” may mean that two or more elements, at a common communication protocol layer, have an established signaling relationship with one another over a communication channel, link, interface, or reference point.

[0022] The term “network element” as used herein refers to physical or virtualized equipment or infrastructure used to provide wired or wireless communication network services. The term “network element” may be considered synonymous to or referred to as a networked computer, networking hardware, network equipment, network node, or a virtualized network function.

[0023] The term “information element” refers to a structural element containing one or more fields. The term “field” refers to individual contents of an information element, or a data element that contains content. An information element may include one or more additional information elements.

[0024] Various 3GPP TSs refer to requirements to obtain user consent for information sharing. Some examples are provided as follows.

[0025] 3GPP TS 23.558 v18.4.0 (2023-09) describes an architecture for enabling Edge applications. Clause AR-5.2.6.2-g of TS 23.558 provides that the “application layer  architecture shall support [edge application servers (EASs) ] to obtain user's authorization in order to access to user's sensitive information (e.g. user's location) . ” EAS-obtained user consent requirement in AR-5.2.6.2-g is not supported in the current release.

[0026] Aspects not resolved by TS 23.558 include: whether and how user's consent is obtained to share the UE identifier with a particular EAS or edge enabler client (EEC) ; how to ensure user's authorization / consent as well as application client’s (AC’s ) authorization in invoking functions exposed by EEC (to AC) , which, in turn, relies on functions exposed by the network (e.g. Location) via edge enabler server (EES)  / network exposure function (NEF) ; and how the user or the AC can consent to, for example, the disclosure of location information and use of an identifier (ID) of the AC in the signaling towards the network.

[0027] 3GPP TS 33.558 v18.0.1 (2023-01) describes security aspects for enabling Edge applications in 5th Generation (5G) networks. Clause 5.1.3 of TS 33.558 provides user consent requirements and states: “If EES, trusted by the 3GPP Core Network, is utilizing [5G core network (5GC) ] services without NEF, the EES acts as the consent enforcing entity. Otherwise, if the EES is utilizing 5GC services via NEF, the NEF acts as the consent enforcing entity. ”

[0028] 3GPP TS 33.501 v18.3.0 (2023-09) specifies security architecture for a 5G system (5GS) , which includes 5GC and 5G new radio (NR) . Annex V of TS 33.501 states “It is assumed that the user consent is obtained from the end-users. The end-user (s) is the subscriber itself or authorize the subscriber to provide consent on behalf of the end-users. Alternatively, the end-users are authorized by the subscriber to provide the consent. That means user consent is always tied to the subscription information. ” It is noted, however, that how such user content is obtained from the end users is not specified within 3GPP. Annex V. 3 of TS 33.501 states that “ [any network function (NF) ] that is deemed an enforcement point for user consent shall support to retrieve the user consent parameters from the [unified data management (UDM) ] . . . NFs obtaining or checking the user consent parameters shall consider the user consent parameters as effective until revoked. ”

[0029] 3GPP TS 23.222 v18.2.0 (2023-06) specifies aspects related to a common application programming interface framework (CAPIF) . Clause 6.2.3 provides that the “resource owner communicates with the authorization function in the CAPIF core function [CCF] to provide and revoke resource owner consent. . . The API exposing function (e.g. NEF, [services capabilities exposure function] SCEF) acts as a resource owner consent  enforcement point as specified in 3GPP TS 33.501 [v18.3.0 (2023-09) ] and interacts with the authorization function in the CCF via CAPIF-3. The API exposing function can retrieve the resource owner consent parameters from the authorization function. ”

[0030] 3GPP TS 23.434 v18.6.0 (2023-09) provides architecture and aspects related to a service enabler architecture layer (SEAL) . Clause 10.3.8 of TS 23.434 provides that a vertical application layer (VAL) “server determines group information and the identity list to which the group announcement shall be sent. The decision can be based on the list of authorized UEs and other criteria (e.g. user consent, service, or vehicle driving profile) . ”

[0031] In previous networks, an application function’s (AF’s ) point of access into a 3GPP core network (for example, via a network exposure function (NEF) or EES) provides a user consent enforcement point. With the introduction of an application enabler layer, an EEC may pass user-sensitive or private information of a UE (for example, from the lower layers or application layer) to an EES. However, existing TSs do not consider this as a user consent enforcement point, even though the EEC could be serving multiple different applications, each potentially supplied from difference application service providers. This may lead to a concern that the EEC may blindly share user-sensitive or private information (e.g., user location, predicted location (s) , user identity) with the application enabler layer for which suitable user consent has not been obtained. For example, an issue may occur if user consent to share an attribute is not provided, but the AC sends the attribute to an EEC and the EEC sends the attribute to the enabler layer without any check. Embodiments of the present disclosure describe procedures to address these issues and gaps in current systems.

[0032] FIG. 1 illustrates an architecture 100 in accordance with some embodiments. The architecture 100 includes a UE 104 coupled with a data network (DN) 112 via a core network 108 of a cellular network system. The UE 104 may also be coupled with the core network 108 via a radio access network (RAN) of the cellular network system; however, the RAN is not explicitly shown in FIG. 1. The core network 108 and RAN may be generically referred to as a cellular network system. In some embodiments, the cellular network system may be a 3GPP system.

[0033] The UE 104 may include an AC 106 and an enabler client (EC) 120. The data network 112 may include an AS 124 that is coupled with the AC 116 at a user plane, for example, application layer. The data network 112 may also include an enabler server (ES) 128 that is coupled with the EC 120 of the UE 104. The EC 120 and the ES 128 may  communicate at an application enabler layer, for which, the CN 108 enables the transport layer for the application enabler layer. While the UE 104 is shown with one EC, EC 120, and one AC, AC 116, in other embodiments, the UE 104 may include a plurality of ECs or ACs, which may be dedicated to the same or different types of services.

[0034] In some embodiments, the architecture 100 may further include a configuration server (CS) 132 coupled with the EC 120 and ES 128 at the application enabler layer.

[0035] The EC 120 may provide supporting functions for applications on the UE 104 including retrieval of configuration data from the application enabler layer and discovery of ASs in the DN 112. The ES 128 may provide the EC 120 with services related to discovering and accessing resources in the DN 112, including ASs, or core network 108. The CS 132 may provide configuration information to the EC 120 to enable establishing a connection to the DN 112 and ESs within the DN 112.

[0036] In some embodiments, the architecture 100 may be an edge system in which the EC 120 is an EEC, the DN 112 is an edge data network (EDN) , the AS 124 is an edge application server (EAS) , the ES 128 is an EES, and the CS 132 is an edge configuration server (ECS) . Except as otherwise described herein, an edge system may be similar to that described in 3GPP TS 23.558.

[0037] In some embodiments, the architecture 100 may be a SEAL architecture in which the AC 116 is a vertical application layer client (VAL client) , the EC 120 is a SEAL client, the AS 124 is a vertical application layer server (VAL server) , and the ES 128 is a SEAL server. Except as otherwise described herein, a SEAL architecture may be similar to that described in 3GPP TS 24.434.

[0038] While various embodiments describe the architecture 100 being used for edge or SEAL services, the application enabler layer functionality provided by the architecture 100 may be beneficial to a variety of different or evolving services including, but not limited to, extended reality (XR) , metaverse services, or EDGEAPP phase 3 services. These services may include new types of user information that may be managed according to embodiments of the present disclosure. For example, some of these services may include management of digital assets such as avatar’s , which are typically user specific, and more precise user location requirements, including pose and orientation.

[0039] The application layer and application enablement layer entities (acting as AFs of the core network 108) can interact with entities of the core network 108. AFs may interact with the entities of the core network 108 either directly as trusted entities of the core network 108 or as untrusted entities via an NEF of the core network 108.

[0040] In some embodiments, the EC 120 may provide an additional consent enforcement point. For example, the EC 120 may receive a user request for enabler services from the AC 116. To provide the enabler services, the EC 120 may transmit one or more application enabler layer (AEL) messages to the ES 128 or CS 132. These messages may include user-sensitive or private information (e.g., user location, predicted location (s) , user identity, or applications or configurations of the UE 104) . The user-sensitive or private information may include information elements, attributes, etc. and may be generically referred to herein as user information (UI) parameters. Prior to sharing any UI parameters with the ES 128 or CS 132, the EC 120 may first determine that appropriate user consent has been obtained. This may be done in accordance with one or more of the following aspects.

[0041] In a first aspect, the EC 120 may obtain user consent attributes associated with sharing the UI parameters after receiving the request from the AC 116 but before sending the AEL message (s) . In some embodiments, the EC 120 may receive the user consent attributes from a trusted entity on the UE 104. For example, the AC 116 or another application of the UE 104 through which a user may provide consent may be considered as a trusted entity that may provide the EC 120 with the user consent attributes. In other embodiments, the EC 120 may receive the user consent attributes from the core network 108.

[0042] Clause 6.3.2 of TS 23.222 provides that an application programming interface (API) “invoker may be either an application on a server or an application on a UE. ” Thus, the EC 120, hosted on the UE 104, may act as an AF to invoke user consent checking capabilities of the core network 108. The user consent checking capabilities of the core network 108 (for example, the UDM subscription data management (SDM) service) may be used to obtain user consent attributes maintained by entities of the core network 108.

[0043] In some embodiments, there may be application enabler layer, or application layer, components to user consent that are not maintained or captured by the core network 108. For example, there may be separate sources for different components of an overall user consent. In these instances, the EC 120 may obtain the desired user consent from one or more sources. For example, the EC 120 may obtain one or more user consent components from AC  116, directly from core network 108, or indirectly from the core network through the ES 128 acting as its proxy. The different user consent components may be aligned, or combined, with one another to provide the EC 120 with requisite consent to share the UI parameters via AEL messages.

[0044] While some embodiments describe the EC 120 obtaining consent before transmitting the UI parameters to ES 128 or CS 132, in other embodiments, the EC 120 may obtain consent before transmitting UI parameters to AC 116 or another EC of the UE 104. For example, in some embodiments, the EC 120 may receive user consent indication from the ES 128 before passing UI parameters to the AC 116; or may receive user consent indication from the ES 128 or the AC 116 before passing UI parameters to another EC of the UE 104. When coming from the ES 128, the consent (and UI parameters) may be originating from a user associated with another UE. Thus, various embodiments describe the EC 120 being a consent enforcement point for situations in which the AC 116 is exposing information towards the enabler layer or the enabler layer exposing information towards the AC 116.

[0045] In a second aspect, rather than invoking secondary consent checking services after receiving a request and before passing on UI parameters, embodiments describe that an entity that provides the UI parameters also provides evidence (for example, a user-consent token) that suitable user consent has been obtained. With reference to the architecture 100, provision of UI parameters and user-consent token may be: from the AC 116 to the EC 120 (or vice versa) ; from the EC 120 to the ES 128 (or vice versa) ; from the ES to the AS 124 (or vice versa) ; or from the AC 116 to another EC (on the same or different UE) .

[0046] FIG. 2 illustrates an access operation 200 using a user-consent token according to the second aspect in accordance with some embodiments. The access operation 200 may include a user / application 204, the AC 116, and the EC 120 of the UE 104 securely obtaining a user-consent token from a network entity 208. The network entity 208 may represent one or more servers such as, for example, an authorization server, an identity server, a consent-granting server, etc. The network entity 208 may be disposed in the core network 108 or the DN 112.

[0047] The user / application 204 may refer to a user of the UE 104 or a user application (for example, a web browser) of the UE 104. Once obtained, the user-consent token may be used to enable the EC 120 to share UI parameters with the ES 128 in the process of performing an enabler service.

[0048] The EC 120 may obtain the user-consent token using an authorization protocol similar to a protocol described by Open Authorization (OAuth) 2.0, Internet Engineering Task Force (IETF) Request for Comments (RFC) 6749.

[0049] In message 1, the user / application 204 ( “resource owner” and “user-agent” in OAuth terminology) may initiate the process by sending a request to the AC 116 ( “client” in OAuth terminology) .

[0050] In message 2, the user / application 204 is requested to redirect and given an identifier of the AC 116 (client ID) .

[0051] In message 3, the user / application 204 may send a request to the network entity 208. The request may include the client ID and may be sent to a redirect uniform resource identifier (URI) .

[0052] In message 4, the network entity 208 may send an authorization request that requests the user / application 204 to provide authentication credentials.

[0053] In message 5, the user / application 204 may provide the requested authentication credentials.

[0054] In message 6, the network entity 208 may provide an authorization code.

[0055] In message 7, the user / application 204 may provide the authorization code to the AC 116.

[0056] In message 8, the AC 116 may send a user-consent token request to the network entity 208. The user-consent token request may include the authorization code and, possibly, other information. The other information may include additional credentials of the AC 116 (for example, client ID, a secret or shared key, etc. ) , UI parameter that is to be potentially shared in the enabler services, etc. The authorization / credentials provided in the user-consent token request may provide the network entity 208 with the indication that the AC 116 has adequate credentials to share the UI parameters.

[0057] In some embodiments, the user-consent token may indicate the AC 116 has authority to share a category of information. In other embodiments, the user-consent token may indicate the AC 116 has authority to share specific information, for example, one or more specific UI parameters.

[0058] The network entity 208 may confirm the authorization code and credentials are valid to permit the AC 116 to share the UI parameters and, in message 9, may provide a user-consent token to the AC 116.

[0059] Once the AC 116 acquires the user-consent token, the AC 116 may, in message 10, send a request with the user-consent token and the parameter. The user-consent token may provide a trusted indication, to the EC 120 ( “resource server” in OAuth terminology) , that the AC 116 has the necessary authorization (for example, user consent) to share the provided UI parameter with the EC 120 and that the EC 120 has the necessary authorization (for example, user consent) to share the provided UI parameter with the ES 128.

[0060] In message 11, the EC 120 may transmit an AEL request to the ES. The AEL request may include the UI parameter and, in some cases, the user-consent token.

[0061] In some embodiments, the user-consent token may use a format such as a JSON Web Token (JWT) format as defined in IETF RFC 7519 (May 2015) .

[0062] An example user-consent token based on a JWT format may be:

[0063] In this example, the “alg” and “type” may be considered a header, which indicates the encoded object is a JWT and is secured using a hash-based message authentication code (HMAC) secure hash algorithm (SHA) -256 algorithm. The payload, “scope” and “exp, ” may include various validated claims that may be used to pass an identity of authenticated users or  other relevant information between an identity provider and a service provider. The signature section, HMAC_SCH256, may securely validate the user-consent token. The signature can be used to check the header and payload have not been modified following issuance by the network entity 208, which may enable an entity (e.g., EC 120 or ES 128) to verify for itself that the token is valid without having to check with the token-issuing network entity 208.

[0064] As shown, the claims of the payload include: a scope claim “scope” and an expiration claim “exp. ” Except as otherwise described herein, the scope claim may be similar to that described in IETF RFC 9068 (October 2021) with respect to access tokens. The scope claim in the user-consent token may identify specific UI parameters (for example, UI parameter_1) (or category of parameters) to which the user-consent token applies. For security purposes, the user-consent token may be provided with a finite lifetime by including the expiration claim with a specific time in which the user-consent token expires. In other embodiments, the finite lifetime may be provided by other mechanisms such as, for example, or a time-to-live parameter, which may provide a number of times the user access token may be used or a time from issuance of the token before it expires.

[0065] While the JWT format is shown as one embodiment, other embodiments may include other formats. For example, the user-consent token may be a bearer token similar to that described in IETF RFC 6750 (October 2012) or a message authentication code (MAC) OAuth-v2-HTTP-MAC.

[0066] In some embodiments, the network entity 208 may issue refresh tokens that may be used by the AC 116 to obtain new user-consent tokens. For example, the user-consent token may be a single-use token, but the AC 116 may be provided with a predetermined number of refresh tokens that may be used to obtain the same predetermined number of single-use tokens.

[0067] In some embodiments, the AC 116 may obtain user-consent tokens from trusted entities other than the network entity 208. For example, the AC 116 may obtain a user-consent token from the user / application 204 or the AS 124. If the AC 116 obtains a user-consent token from the AS 124, the AS may deal with obtaining the user-consent token from the network entity 208. This may prevent a need for a procedure for the AC 116 to obtain the user-consent token. It may be desirable for the network entity 208 to be trusted by the EC 120 and independent from the AS 124, to avoid the AS 124 from spoofing the EC 120.

[0068] In some embodiments, user consent may be obtained from a user or indicated in a request message in a manner similar to how a user indicates tracking preferences when web browsing. For example, a request message may include the user-consent token in a header of a request message in a manner similar to how a user may indicate their tracking preferences in a do-not-track HTTP or global privacy control header.

[0069] In another example, user consent may be obtained / evidenced in a manner similar to an extension mechanism for domain name system (EDNS) client subnet (ECS) option used to help the resolution process select a service address near a client. In ECS, the client is not explicitly asked for consent for the mechanism to be used as it is acknowledged that the extension may reveal information about the client's location that the resolver would not otherwise be able to deduce. However, the client can be implemented in a manner to prevent the mechanism, e.g., by sending a zero-address ECS (e.g., voiding the IP address that would be included in the extension, preventing the DNS resolver determining client location) . While the ECS option does not provide that the user is explicitly asked for their consent, a similar process may be modified in accordance with various embodiment to ensure sufficient user consent is obtained.

[0070] FIG. 3 illustrates an AC registration procedure 300 in accordance with some embodiments. The AC registration procedure 300 may take place between the AC 116 and the EC 120. Except as otherwise noted herein, the AC registration procedure 300 may be similar to that described in section 8.14.2.2.2 of 3GPP TS 23.558.

[0071] The AC registration procedure 300 may include, at 304, the AC 116 obtaining a user-consent token. The user-consent token may be provided to the AC 116 from the user / application 204, the network entity 208, or some other entity as described elsewhere herein.

[0072] The AC registration procedure 300 may further include, at 308, the AC 116 sending an AC registration request to the EC 120. The AC registration request may include the user-consent token. The AC registration request, and included user-consent token, may be protected to ensure integrity of the user-consent token. The integrity protection of the user-consent token may come from the nature of the token itself, for example, by using the JWT format described above. Addition / alternative protections may be used to ensure the token’s integrity. In some embodiments, the user-consent token may be included in a security credential information element of the AC registration request. In some embodiments, the AC  registration request may include components such as shown below in Table 1. Except for the inclusion of the user-consent token, table 1 may be similar to Table 8.14.3.2-1 of TS 23.558.

[0073] Table 1

[0074] The AC registration procedure 300 may further include, at 312, the EC 120 may perform a validation and registration. The validation may include the EC 120 validating the AC registration request. For example, the EC 120 may validate the security credentials provided in the AC registration request. Upon successful validation, the EC 120 may register information provided in the AC registration request. The registration may be internal to the EC 120, in which EC 120 maintains the information, which may include UI parameters. In other embodiments, the registration may involve transmitting an AEL message to an ES 128. In either event, the EC 120 may only maintain / forward the UI parameters determined to be associated with the user-consent token that indicates sufficient consent to share has been obtained. If the registration request includes UI parameters for which an indication of suitable consent has not been provided, the EC 120 may reject the registration request.

[0075] After successful registration, the AC registration procedure 300 may further include, at 316, the EC 120 transmitting an AC registration response to the AC 116 to provide an indication of the successful registration. If the registration request includes UI parameters for which an indication of suitable consent has not been provided, the AC registration response may indicate the registration request is rejected.

[0076] FIG. 4 illustrates an EAS discovery procedure 400 in accordance with some embodiments. The EAS discovery procedure 400 may take place between the AC 116, the EC 120, and the ES 128. Except as otherwise noted herein, the EAS discovery procedure 400 may be similar to that described in section 8.3.2 of 3GPP TS 23.558.

[0077] The EAS discovery procedure 400 may include, at 404, the AC 116 obtaining a user-consent token. The user-consent token may be provided to the AC 116 from the user / application 204, the network entity 208, or some other entity as described elsewhere herein.

[0078] The EAS discovery procedure 400 may further include, at 408, the AC 116 transmitting an EAS discovery request to the EC 120. The EAS discovery request may include an AC profile (including, e.g., an ID of the AC 116) , an EAS characteristics list (for example, EAS discovery filters) , and the user-consent token (which may be in the AC profile in some embodiments) .

[0079] The EAS discovery procedure 400 may further include, at 412, the EC 120 checking the security credentials. For example, the EC 120 may determine whether the AC 116 has included the user-consent token for sharing the UI parameters. The EC 120 may verify the user access token before transmitting EAL messages for the EAS discovery procedure 400.

[0080] Upon determining the user-consent token is valid and indicates sufficient user consent for sharing the UI parameters, the EAS discovery procedure 400 may include the EC 120 transmitting, as an EAL message, an EAS discovery request to the ES 128 at 416. The EAS discovery request transmitted at 416 may include an EC ID, a UE ID, a UE location, EAS discovery filters including an AC profile if AC characteristics are included, the user-consent token, etc.

[0081] Upon receiving the EAS discovery request, the ES 128 may query the CN 108 for a location of the UE 104 in order to complete the EAS discovery. This query may rely on UI parameters (e.g., identity of the UE 104) . The user-consent token may be evidence of the user’s wish for the ES 128 to have knowledge of the UI parameters that may assist the ES 128 in making the most informed decision.

[0082] Upon determining the appropriate EAS, the EAS discovery procedure 400 may include the ES 128 sending an EAS discovery response at 420. The EAS discovery  response may include an EAS profile including, for example, an EAS ID and endpoint (for example, address) .

[0083] The EC 120 may forward the EAS discovery response to the AC 116 at 424. >

[0084] FIGs. 3 and 4 describe the AC registration and EAS discovery procedures that rely on user-consent tokens to provide an indication of user consent in accordance with the second aspect of this disclosure. However, these and other procedures may rely on the EC 120 obtaining user consent before sharing UI parameters in accordance with the first aspect of this disclosure.

[0085] FIG. 5 provides an operation flow / algorithmic structure 500 in accordance with some embodiments. The operation flow / algorithmic structure 500 may be performed by a UE such as, for example, UE 104, device 800, or components thereof, for example, processors 804.

[0086] The operation flow / algorithmic structure 500 may include, at 504, receiving a first request. In some embodiments, the first request may be received at an EC of a UE from an AC of the UE.

[0087] In some embodiments, EC may be an EEC and the first request may relate to edge services. For example, the first request may be an AC registration request or an EAS discovery request as described elsewhere herein. In another example, the first request may be an application context relocation request, which may be used by an AC to request that an application context / state be transferred from a source server (S-EAS) to a target application server (T-EAS) . In another example, the request may be an EEC services subscription request in which the AC requests to be updated on services offered by the EEC. In another example, the first request may be a UE ID request in which the AC requests a UE identifier that it can share with an EAS.

[0088] The operation flow / algorithmic structure 500 may further include, at 508, obtaining user-consent attributes. In some embodiments, the user-consent attributes may be obtained from a network entity. The network entity may be a network function of a cellular core network. In this case, the user-consent attributes may be obtained by invoking a UDM SDM service of the cellular core network. In other embodiments, the network entity may be outside of the cellular core network.

[0089] In some embodiments, the user-consent attributes may be obtained from an application client of the UE.

[0090] The operation flow / algorithmic structure 500 may further include, at 512, determining user consent associated with a parameter. The parameter may be a UI parameter and the user consent may be determined based on the user-consent attributes obtained at 508. The UI parameter may be a current location of a UE, a predicted location of the UE, a user identity, and identity of an application of the UE, or information of a user of another UE.

[0091] The operation flow / algorithmic structure 500 may further include, at 516, transmitting a second request. In some embodiments, the second request may be an AEL message transmitted to an ES or a CS.

[0092] In some embodiments, the second request may relate to edge services. For example, the second request may be a request to: retrieve configuration information to enable an exchange of application data between an AC and an EAS; discover an EAS in an EDN; detect a UE mobility event; expose an event of interest to an AC; or retrieve a UE ID.

[0093] In some embodiments, the second request may relate to SEAL services. For example, the second request may be associated with group management; configuration management; location management; identity management; key management; network resource management; notification management; network slice capability enablement; data delivery; or application data analytics enablement.

[0094] FIG. 6 provides an operation flow / algorithmic structure 600 in accordance with some embodiments. The operation flow / algorithmic structure 600 may be performed by a UE such as, for example, UE 104, device 800, or components thereof, for example, processors 804.

[0095] The operation flow / algorithmic structure 600 may include, at 604, obtaining a user-consent token. In some embodiments, the user-consent token may be obtained by an AC of the UE and may be used to indicate user consent that is associated with a parameter. The parameter may be a UI parameter. The UI parameter may be a current location of a UE, a predicted location of the UE, a user identity, and identity of an application of the UE, or information of a user of another UE.

[0096] In some embodiments, the user-consent token may be obtained from a user of the UE. In other embodiments, an authentication procedure may be performed with a network  entity. The user-consent token may then be received from the network entity based on the authentication operation.

[0097] The operation flow / algorithmic structure 600 may further include, at 608, providing a request with the user-consent token. The request may be provided to an enabler client of the UE. In some embodiments, the EC may be an EEC and the request may be an EAS discovery request, an application context relocation request, an EEC services subscription request, or a UE ID request.

[0098] In some embodiments, the request may be an AC registration request that is sent to an EEC. The user-consent token may be provided within a security credential information element of the AC registration request.

[0099] In some embodiments, the user-consent token may be obtained by an ES or CS. For example, an ES or CS may provide, to an EC, a UI parameter (e.g., a network-determined user location) along with the user-consent token. The EC may then verify the user-consent token provides sufficient consent to share the UI parameter with an AC that is on the same UE as the EC.

[0100] FIG. 7 provides an operation flow / algorithmic structure 700 in accordance with some embodiments. The operation flow / algorithmic structure 700 may be performed by a UE such as, for example, UE 104, device 800, or components thereof, for example, processors 804.

[0101] The operation flow / algorithmic structure 700 may include, at 704, receiving a user-consent token. In some embodiments, an EC may receive the user-consent token from an AC, an ES, or a CS. The user-consent token may be used to indicate user consent that is associated with a parameter. The parameter may be a UI parameter. The UI parameter may be a current location of a UE, a predicted location of the UE, a user identity, and identity of an application of the UE, or information of a user of another UE.

[0102] In some embodiments, the user-consent token may be received in a request such as an EAS discovery request, an application context relocation request, an EEC services subscription request, or a UE ID request. In some embodiments, the request may be an AC registration request that is sent to an EEC. The user-consent token may be provided within a security credential information element of the AC registration request.

[0103] The operation flow / algorithmic structure 700 may further include, at 708, generating a message. In embodiments in which the EC receives the user-consent token from the AC, the message may be an AEL message.

[0104] The operation flow / algorithmic structure 700 may further include, at 712, transmitting the message. In embodiments in which the message is an AEL message, the AEL message may be for edge services, SEAL services, metaverse services, or XR services.

[0105] In embodiments in which the EC is an EEC, the AEL message may be sent to an EES or an ECS. In these embodiments, the AEL message may be sent to retrieve configuration information to enable an exchange of application data between the AC and an EAS; discover an EAS in an EDN; detect a UE mobility event; expose an event of interest to the AC; or retrieve a UE identifier.

[0106] In embodiments in which the EC is a SEAL client, the AEL message may be sent to a SEAL server and may be associated with group management; configuration management; location management; identity management; key management; network resource management; notification management; network slice capability enablement; data delivery; or application data analytics enablement.

[0107] FIG. 8 illustrates a device 800 in accordance with some embodiments. The device 800 may be the UE 104, an entity of the core network 108, the AS 124, the ES 128, the CS 132, the network entity 208, or other node.

[0108] The device 800 may include processors 804, RF interface circuitry 808, memory / storage 812, user or CN interface 816, sensors 820, driver circuitry 822, power management integrated circuit (PMIC) 824, antenna structure 826, and battery 828. The components of the device 800 may be implemented as integrated circuits (ICs) , portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 8 is intended to show a high-level view of some of the components of the device 800. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

[0109] The components of the device 800 may be coupled with various other components over one or more interconnects 832, which may represent any type of interface, input / output, bus (local, system, or expansion) , transmission line, trace, optical connection,  etc. that allows various circuit components (on common or different chips or chipsets) to interact with one another.

[0110] The processors 804 may include processor circuitry such as, for example, baseband processor circuitry (BB) 804A, central processor unit circuitry (CPU) 804B, and graphics processor unit circuitry (GPU) 804C. The processors 804 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 812 to cause the device 800 to perform operations associated with user consent at the application enablement layer as described herein.

[0111] In some embodiments, the baseband processor circuitry 804A may access a communication protocol stack 836 in the memory / storage 812 to communicate over a 3GPP compatible network. In general, the baseband processor circuitry 804A may access the communication protocol stack to: perform user plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, and PDU layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and a non-access stratum layer. In some embodiments, the PHY layer operations may additionally / alternatively be performed by the components of the RF interface circuitry 808.

[0112] The baseband processor circuitry 804A may generate or process baseband signals or waveforms that carry information in 3GPP-compatible networks. In some embodiments, the waveforms for NR may be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and discrete Fourier transform spread OFDM (DFT-S-OFDM) in the uplink.

[0113] The memory / storage 812 may include one or more non-transitory, computer-readable media that includes instructions (for example, communication protocol stack 836) that may be executed by one or more of the processors 804 to cause the device 800 to perform various operations described herein. The memory / storage 812 include any type of volatile or non-volatile memory that may be distributed throughout the device 800. In some embodiments, some of the memory / storage 812 may be located on the processors 804 themselves (for example, L1 and L2 cache) , while other memory / storage 812 is external to the processors 804 but accessible thereto via a memory interface. The memory / storage 812 may include any suitable volatile or non-volatile memory such as, but not limited to, dynamic random access memory (DRAM) , static random access memory (SRAM) , erasable  programmable read only memory (EPROM) , electrically erasable programmable read only memory (EEPROM) , Flash memory, solid-state memory, or any other type of memory device technology.

[0114] The RF interface circuitry 808 may include transceiver circuitry and radio frequency front module (RFEM) that allows the device 800 to communicate with other devices over a radio access network. The RF interface circuitry 808 may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0115] In the receive path, the RFEM may receive a radiated signal from an air interface via antenna structure 826 and proceed to filter and amplify (with a low-noise amplifier) the signal. The signal may be provided to a receiver of the transceiver that down-converts the RF signal into a baseband signal that is provided to the baseband processor of the processors 804.

[0116] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier prior to the signal being radiated across the air interface via the antenna structure 826.

[0117] In various embodiments, the RF interface circuitry 808 may be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0118] The antenna structure 826 may include antenna elements to convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. The antenna elements may be arranged into one or more antenna panels. The antenna structure 826 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple-input, multiple-output communications. The antenna structure 826 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. The antenna structure 826 may have one or more panels designed for specific frequency bands including bands in FR1 or FR2.

[0119] The user or CN interface 816 may be a user interface that includes various input / output (I / O) devices designed to enable user interaction with the device 800. The user interface includes input device circuitry and output device circuitry. Input device circuitry  includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (for example, a reset button) , a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position (s) , or other like information. Output device circuitry may include any number or combinations of audio or visual display, including, inter alia, one or more simple visual outputs / indicators (for example, binary status indicators such as light emitting diodes “LEDs” and multi-character visual outputs, or more complex outputs such as display devices or touchscreens (for example, liquid crystal displays (LCDs) , LED displays, quantum dot displays, projectors, etc. ) , with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the device 800.

[0120] The user or CN interface 816 may be a CN interface that provides connectivity to a core network, for example, a core network 108, using a network interface protocol such as carrier Ethernet protocols, or some other suitable protocol. Network connectivity may be provided to / from the device 800 via a fiber optic or wireless backhaul. The CN interface may include one or more dedicated processors or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface may include multiple controllers to provide connectivity to other networks using the same or different protocols

[0121] The sensors 820 may include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information (sensor data) about the detected events to some other device, module, subsystem, etc. Examples of such sensors include, inter alia, inertia measurement units comprising accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems comprising 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (for example, thermistors) ; pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (for example, cameras or lensless apertures) ; light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like) ; depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other like audio capture devices; etc.

[0122] The driver circuitry 822 may include software and hardware elements that operate to control particular devices that are embedded in the device 800, attached to the  device 800, or otherwise communicatively coupled with the device 800. The driver circuitry 822 may include individual drivers allowing other components to interact with or control various input / output (I / O) devices that may be present within, or connected to, the device 800. For example, driver circuitry 822 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of the sensors 820 and control and allow access to the sensors 820, drivers to obtain actuator positions of electro-mechanic components or control and allow access to the electro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

[0123] The PMIC 824 may manage power provided to various components of the device 800. In particular, with respect to the processors 804, the PMIC 824 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0124] In some embodiments, the PMIC 824 may control, or otherwise be part of, various power saving mechanisms of the device 800. For example, if the platform UE is in an RRC_Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device 800 may power down for brief intervals of time and thus save power. If there is no data traffic activity for an extended period of time, then the device 800 may transition off to an RRC_Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 800 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device 800 may not receive data in this state; in order to receive data, it must transition back to RRC_Connected state. An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours) . During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.

[0125] A battery 828 may power the device 800, although in some examples the device 800 may be mounted or deployed in a fixed location, and may have a power supply coupled to an electrical grid. The battery 828 may be a lithium-ion battery or a metal-air  battery such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in vehicle-based applications, the battery 2828 may be a typical lead-acid automotive battery.

[0126] As described above, one aspect of the present technology is the gathering and use of data available from specific and legitimate sources to improve delivery of services for a user. The present disclosure contemplates that in some instances, this gathered data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data can include demographic data, location-based data, online identifiers, telephone numbers, email addresses, home addresses, data or records relating to a user’s health or level of fitness (e.g., vital signs measurements, medication information, exercise information) , date of birth, or any other personal information.

[0127] The present disclosure contemplates that those entities responsible for the collection, analysis, disclosure, transfer, storage, or other use of such personal information data will comply with well-established privacy policies and / or privacy practices. In particular, such entities would be expected to implement and consistently apply privacy practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. Such information regarding the use of personal data should be prominent and easily accessible by users, and should be updated as the collection and / or use of data changes. Personal information from users should be collected for legitimate uses only. Further, such collection / sharing should occur only after receiving the consent of the users or other legitimate basis specified in applicable law. Additionally, such entities should consider taking any needed steps for safeguarding and securing access to such personal information data and ensuring that others with access to the personal information data adhere to their privacy policies and procedures. Further, such entities can subject themselves to evaluation by third parties to certify their adherence to widely accepted privacy policies and practices. In addition, policies and practices should be adapted for the particular types of personal information data being collected and / or accessed and adapted to applicable laws and standards, including jurisdiction-specific considerations that may serve to impose a higher standard. For instance, in the US, collection of or access to certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA) ; whereas health data in other countries may be subject to other regulations and policies and should be handled accordingly.

[0128] Despite the foregoing, the present disclosure also contemplates embodiments in which users selectively block the use of, or access to, personal information data. That is, the present disclosure contemplates that hardware and / or software elements can be provided to prevent or block access to such personal information data. For example, as described, user consent to disclose UI parameters is within the control of the user. If such consent is withheld, unauthorized disclosure of the UI parameters is blocked.

[0129] Moreover, it is the intent of the present disclosure that personal information data should be managed and handled in a way to minimize risks of unintentional or unauthorized access or use. Risk can be minimized by limiting the collection of data and deleting data once it is no longer needed. In addition, and when applicable, including in certain health related applications, data de-identification can be used to protect a user’s privacy. De-identification may be facilitated, when appropriate, by removing identifiers, controlling the amount or specificity of data stored (e.g., collecting location data at city level rather than at an address level) , controlling how data is stored (e.g., aggregating data across users) , and / or other methods such as differential privacy.

[0130] Therefore, although the present disclosure broadly covers use of user information to implement one or more various disclosed embodiments, the present disclosure also contemplates that the various embodiments can also be implemented without the need for accessing such user information. That is, the various embodiments of the present technology are not rendered inoperable due to the lack of all or a portion of such user information. For example, content can be selected and delivered to users based on aggregated non-personal information data or a bare minimum amount of personal information, such as the content being handled only on the user’s device or other non-personal information available to the content delivery services.

[0131] 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, or methods as set forth in the example section below. For example, the baseband circuitry 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 below. For another example, circuitry associated with a UE, base station, or network element 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 below in the example section.

[0132] Examples

[0133] In the following sections, further exemplary embodiments are provided.

[0134] Example 1 includes a method comprising: receiving, at an enabler client of a user equipment (UE) , a first request from a first entity; obtaining, based on the first request, user-consent attributes; determining, based on the user-consent attributes, user consent associated with a parameter; and transmitting, to a second entity based on the first request and determination of the user consent with the parameter, a second request that includes the parameter.

[0135] Example 2 includes the method of example 1 or some other example herein, wherein obtaining the user-consent attributes includes obtaining the user-consent attributes from a network entity.

[0136] Example 3 includes the method of example 2 or some other example herein, wherein the network entity is a network function of a cellular core network and said obtaining user-consent attributes comprises the enabler client: invoking, as an application function, a unified data management (UDM) subscription data management (SDM) service of the cellular core network.

[0137] Example 4 includes the method of example 2 or some other example herein, wherein the network entity is outside of a cellular core network.

[0138] Example 5 includes the method of example 1 or some other example herein, wherein the first entity is an enabler or configuration server and the second entity is an application client of the UE.

[0139] Example 6 includes the method of example 1 or some other example herein, wherein the first entity is an application client of the UE and the second entity is an enabler or configuration server.

[0140] Example 7 includes the method of example 6 or some other example herein, wherein obtaining the user-consent attributes includes obtaining the user-consent attributes from the application client.

[0141] Example 8 includes the method of example 6 or some other example herein, wherein the enabler client comprises an edge enabler client and the enabler or configuration server comprises an edge enabler server or an edge configuration server.

[0142] Example 9 includes the method of example 8 or some other example herein, wherein the first request is a registration request, an edge application server discovery request, an application context relocation request, an edge enabler client (EEC) services subscription request, or a UE identifier request.

[0143] Example 10 includes the method of example 8 or some other example herein, wherein the second request is to: retrieve configuration information to enable an exchange of application data between the application client and an edge application server; discover an edge application server in an edge data network; detect a UE mobility event; expose an event of interest to the application client; or retrieve a UE identifier.

[0144] Example 11 includes the method of example 6 or some other example herein, wherein the enabler client comprises a service enabler architecture layer for verticals (SEAL) client and the enabler or configuration server is a SEAL server.

[0145] Example 12 includes the method of example 11 or some other example herein, wherein the second request is associated with: group management; configuration management; location management; identity management; key management; network resource management; notification management; network slice capability enablement; data delivery; or application data analytics enablement.

[0146] Example 13 includes the method of example 1 or some other example herein, wherein the parameter is a current location of the UE, a predicted location of the UE, a user identity, an identity of an application of the UE, or information of a user of another UE.

[0147] Example 14 includes a method comprising: obtaining, by a first entity, a user-consent token to indicate user consent associated with a parameter; and providing, to an enabler client of a user equipment (UE) , a request with the user-consent token and the parameter, wherein the first entity is an application client of the UE, an enabler server, or a configuration server.

[0148] Example 15 includes the method of example 14 or some other example herein, wherein obtaining the user-consent token comprises: obtaining the user-consent token from a user of the UE.

[0149] Example 16 includes the method of example 14 or some other example herein, further comprising: performing an authentication procedure with a network entity; and receiving, from the network entity, the user-consent token based on the authentication procedure.

[0150] Example 17 includes the method of example 14 or some other example herein, wherein the enabler client is an edge enabler client and the request is an edge application server discovery request, an application context relocation request, an edge enabler client (EEC) services subscription request, or a UE identifier request.

[0151] Example 18 includes the method of example 14 or some other example herein, wherein the enabler client is an edge enabler client, the request is an application client (AC) registration request, the user-consent token is provided within a security credential information element of the AC registration request, and the method further comprises: receiving, from the edge enabler client, an AC registration response.

[0152] Example 19 includes a method comprising: receiving, at an enabler client from a first entity, a user-consent token to indicate user consent associated with a parameter; generating a message with the parameter; and transmitting the message to a second entity.

[0153] Example 20 includes the method of example 19 or some other example herein, wherein the first entity is an enabler server or a configuration server and the second entity is an application client.

[0154] Example 21 includes the method of example 19 or some other example herein, wherein the first entity is an application client, the second entity is an enabler server or configuration server, and the message is an application enabler layer message.

[0155] Example 22 includes the method of example 21 or some other example herein, wherein the enabler client is an edge enabler client and the method further comprises: receiving a request that includes the user-consent token, wherein the request is an edge application server discovery request, an application context relocation request, an edge enabler client (EEC) services subscription request, or a UE identifier request.

[0156] Example 23 includes the method of example 21 or some other example herein, wherein the enabler client is an edge enabler client, and the method further comprises: receiving an application client (AC) registration request from the application client, wherein  the user-consent token is included within a security credential information element of the AC registration request.

[0157] Example 24 includes the method of example 21 or some other example herein, wherein the enabler client comprises a service enabler architecture layer for verticals (SEAL) client, the enabler server or configuration server is a SEAL server, and the AEL message is a request associated with: group management; configuration management; location management; identity management; key management; network resource management; notification management; network slice capability enablement; data delivery; or application data analytics enablement.

[0158] Another example may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples 1–24, or any other method or process described herein.

[0159] Another example may 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 a method described in or related to any of examples 1–24, or any other method or process described herein.

[0160] Another example may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples 1–24, or any other method or process described herein.

[0161] Another example may include a method, technique, or process as described in or related to any of examples 1–24, or portions or parts thereof.

[0162] Another example may 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 the method, techniques, or process as described in or related to any of examples 1–24, or portions thereof.

[0163] Another example may include a signal as described in or related to any of examples 1–24, or portions or parts thereof.

[0164] Another example may include a datagram, information element, packet, frame, segment, PDU, or message as described in or related to any of examples 1–24, or portions or parts thereof, or otherwise described in the present disclosure.

[0165] Another example may include a signal encoded with data as described in or related to any of examples 1–24, or portions or parts thereof, or otherwise described in the present disclosure.

[0166] Another example may include a signal encoded with a datagram, IE, packet, frame, segment, PDU, or message as described in or related to any of examples 1–24, or portions or parts thereof, or otherwise described in the present disclosure.

[0167] Another example may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is to cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1–24, or portions thereof.

[0168] Another example may include a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out the method, techniques, or process as described in or related to any of examples 1–24, or portions thereof.

[0169] Another example may include a signal in a wireless network as shown and described herein.

[0170] Another example may include a method of communicating in a wireless network as shown and described herein.

[0171] Another example may include a system for providing wireless communication as shown and described herein.

[0172] Another example may include a device for providing wireless communication as shown and described herein.

[0173] Any of the above-described examples may be combined with any other example (or combination of examples) , 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.

[0174] Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

1.A method comprising:receiving, at an enabler client of a user equipment (UE) , a first request from a first entity;obtaining, based on the first request, user-consent attributes;determining, based on the user-consent attributes, user consent associated with a parameter; andtransmitting, to a second entity based on the first request and determination of the user consent with the parameter, a second request that includes the parameter.2.The method of claim 1, wherein obtaining the user-consent attributes includes obtaining the user-consent attributes from a network entity.3.The method of claim 2, wherein the network entity is a network function of a cellular core network and said obtaining user-consent attributes comprises the enabler client:invoking, as an application function, a unified data management (UDM) subscription data management (SDM) service of the cellular core network.4.The method of claim 2, wherein the network entity is outside of a cellular core network.5.The method of claim 1 or 2, wherein the first entity is an enabler server or configuration server and the second entity is an application client of the UE.6.The method of claim 1 or 2, wherein the first entity is an application client of the UE and the second entity is an enabler server or configuration server.7.The method of claim 6, wherein obtaining the user-consent attributes includes obtaining the user-consent attributes from the application client.8.The method of claim 6, wherein the enabler client comprises an edge enabler client and the enabler or configuration server comprises an edge enabler server or an edge configuration server.9.The method of claim 8, wherein the first request is a registration request, an edge application server discovery request, an application context relocation request, an edge enabler client (EEC) services subscription request, or a UE identifier request.10.The method of claim 8, wherein the second request is to: retrieve configuration information to enable an exchange of application data between the application client and an edge application server; discover an edge application server in an edge data network; detect a UE mobility event; expose an event of interest to the application client; or retrieve a UE identifier.11.The method of claim 6, wherein the enabler client comprises a service enabler architecture layer for verticals (SEAL) client and the enabler or configuration server is a SEAL server.12.The method of claim 11, wherein the second request is associated with: group management; configuration management; location management; identity management; key management; network resource management; notification management; network slice capability enablement; data delivery; or application data analytics enablement.13.The method of claim 1 or 2, wherein the parameter is a current location of the UE, a predicted location of the UE, a user identity, an identity of an application of the UE, or information of a user of another UE.14.One or more computer-readable media having instructions that, when executed, cause an entity to:obtain a user-consent token to indicate user consent associated with a parameter; andprovide, to an enabler client of a user equipment (UE) , a request with the user-consent token and the parameter,wherein the entity is an application client of the UE, an enabler server, or a configuration server.15.The one or more computer-readable media of claim 14, wherein the user-consent token is to be obtained from a user of the UE.16.The one or more computer-readable media of claim 14 or 15, wherein the instructions, when executed, further cause the entity to:perform an authentication procedure with a network entity; andreceive, from the network entity, the user-consent token based on the authentication procedure.17.The one or more computer-readable media of claim 14 or 15, wherein the enabler client is an edge enabler client and the request is an edge application server discovery request, an application context relocation request, an edge enabler client (EEC) services subscription request, or a UE identifier request.18.The one or more computer-readable media of claim 14 or 15, wherein the enabler client is an edge enabler client, the request is an application client (AC) registration request, the user-consent token is provided within a security credential information element of the AC registration request, and the instructions, when executed, further cause the entity to:receive, from the edge enabler client, an AC registration response.19.An apparatus having circuitry configured to implement an enabler client to:receive, from a first entity, a user-consent token to indicate user consent associated with a parameter;generate a message with the parameter; andtransmit the message to a second entity.20.The apparatus of claim 19, wherein the first entity is an enabler server or a configuration server and the second entity is an application client.21.The apparatus of claim 19 or 20, wherein the first entity is an application client, the second entity is an enabler server or configuration server, and the message is an application enabler layer message.22.The apparatus of claim 21, wherein the enabler client is an edge enabler client, wherein the enabler client is further to:receive a request that includes the user-consent token, wherein the request is an edge application server discovery request, an application context relocation request, an edge enabler client (EEC) services subscription request, or a UE identifier request.23.The apparatus of claim 21, wherein the enabler client is an edge enabler client is further to:receive an application client (AC) registration request from the application client, wherein the user-consent token is included within a security credential information element of the AC registration request.24.The apparatus of claim 21, wherein the enabler client comprises a service enabler architecture layer for verticals (SEAL) client, the enabler server or configuration server is a SEAL server, and the AEL message is a request associated with: group management; configuration management; location management; identity management; key management; network resource management; notification management; network slice capability enablement; data delivery; or application data analytics enablement.

Images