User consent at the application enablement layer

Abstract

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

Description

Technical Field

[0001] This application relates to wireless networks, and more specifically, to technologies for user consent at the application enablement layer. Background Technology

[0002] Various 3GPP (3rd Generation Partnership Project) Technical Specifications (TS) mention the requirement to obtain user consent for information sharing. The aim is to improve user consent mechanisms to be compatible with the evolution architectures and signaling processes defined by these 3GPP TSs. Attached Figure Description

[0003] Figure 1 Examples of network environments based on some implementation schemes are provided.

[0004] Figure 2 Examples of access networks based on some implementation schemes are shown.

[0005] Figure 3 The registration process according to some implementation schemes is illustrated.

[0006] Figure 4 The discovery process based on some implementation schemes is illustrated.

[0007] Figure 5 The operational flow / algorithm structure according to some implementation schemes is illustrated.

[0008] Figure 6 Another operational flow / algorithm structure based on some implementation schemes is illustrated.

[0009] Figure 7 Another operational flow / algorithm structure based on some implementation schemes is illustrated.

[0010] Figure 8 Examples of devices based on some implementation schemes are shown. Detailed Implementation

[0011] The following detailed description refers to the accompanying drawings. The same reference numerals may be used to identify the same or similar elements in different drawings. In the following description, specific details, such as particular structures, architectures, interfaces, and techniques, are set forth for illustrative and non-limiting purposes to provide a thorough understanding of various aspects of the various embodiments. However, it will be apparent to those skilled in the art that various aspects of the various embodiments may be practiced in other examples departing from these specific details. In some cases, descriptions of well-known devices, circuits, and methods have been omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of this document, the phrases “A / B” and “A or B” refer to (A), (B), or (A and B); and the phrase “based on A” means “at least partially based on A,” for example, it can be “based solely on A” or it can be “partially based on A.”

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

[0013] As used herein, the term "circuit" refers to, is part of, or includes a hardware component configured to provide the described functionality. Hardware components may include electronic circuitry, logic circuitry, processors (shared, dedicated, or grouped) or memories (shared, dedicated, or grouped), application-specific integrated circuits (ASICs), field-programmable devices (FPDs) (e.g., field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), structured ASICs, or programmable system-on-a-chip (SoCs)), or digital signal processors (DSPs). In some embodiments, the circuit may execute one or more software or firmware programs to provide at least some of the described functionality. The term "circuit" may also refer to a combination of one or more hardware elements (or combinations of circuits used in electrical or electronic systems) and program code for executing the functionality. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuit.

[0014] As used herein, the term "processor circuit" means, is part of, or includes a circuit capable of sequentially and automatically performing a series of arithmetic or logical operations or recording, storing, or transmitting digital data. The term "processor circuit" may also refer to an application processor, baseband processor, central processing unit (CPU), graphics processing unit, single-core processor, dual-core processor, triple-core processor, quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions (such as program code, software modules, and / or functional procedures).

[0015] As used herein, the term "interface circuit" refers to, is part of, or includes a circuit that enables the exchange of information between two or more components or devices. The term "interface circuit" can refer to one or more hardware interfaces, such as buses, I / O interfaces, peripheral component interfaces, and network interface cards.

[0016] As used herein, the term "user equipment" or "UE" refers to equipment having radio communication capabilities that allow a user to access network resources within a communication network. The term "user equipment" or "UE" may be considered synonymous with and may be referred to as a client, mobile phone, 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" can include any type of wireless / wired equipment or any computing device that includes a wireless communication interface.

[0017] As used herein, the term "computer system" means any type of interconnected electronic device, computer device, or component thereof. Additionally, the term "computer system" or "system" may refer to various components of a computer that are communicatively coupled to each other. Furthermore, the term "computer system" or "system" may refer to multiple computer devices or multiple computing systems that are communicatively coupled to each other and configured to share computing resources or network resources.

[0018] As used herein, the term "resource" 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 equipment, mechanical equipment, memory space, processor / CPU time, processor / CPU utilization, processor and accelerator load, hardware time or utilization, power, input / output operations, port or network sockets, channel / link allocation, throughput, memory utilization, storage, network, database, and application or workload units. "Hardware resource" can refer to computing, storage, or network resources provided by physical hardware components. "Virtualized resource" can refer to computing, storage, or network resources provided by virtualization infrastructure to an application, device, or system. The terms "network resource" or "communication resource" can refer to resources accessible by a computer device / system via a communication network. The term "system resource" can refer to any kind of shared entity providing a service and can include computing or network resources. System resources can be considered as a coherent set of functions, network data objects, or services accessible through a server, wherein such system resources reside on a single host or multiple hosts and can be clearly identified.

[0019] As used herein, the term "channel" refers to any tangible or intangible transmission medium used to transmit data or data streams. The term "channel" may be synonymous or equivalent with "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," or any other similar term indicating a means or medium through which data is transmitted. Additionally, as used herein, the term "link" refers to a connection between two devices used for transmitting and receiving information.

[0020] As used in this article, the terms "instantiate" and "instantiate" refer to the creation of an instance. "Instance" also refers to the concrete occurrence of an object, which may occur, for example, during the execution of program code.

[0021] The term "connection" can refer to an established signaling relationship between two or more elements at a common communication protocol layer through a communication channel, link, interface, or reference point.

[0022] As used herein, the term "network element" 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 with or referred to as a networked computer, network hardware, network equipment, network node, or virtualized network function.

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

[0024] Various 3GPP TS documents mention the requirement to obtain user consent for information sharing. Some examples are provided below.

[0025] 3GPP TS 23.558 v18.4.0 (2023-09) describes the architecture for implementing edge applications. Clause AR-5.2.6.2-g of TS 23.558 specifies that "the application layer architecture should support [Edge Application Server (EAS)] obtaining user authorization to access sensitive user information (e.g., user location)." The user consent requirement for the EAS in AR-5.2.6.2-g is not supported in the current version.

[0026] Aspects not addressed by TS 23.558 include: whether and how user consent is obtained to share the UE identifier with a specific EAS or Edge Enabled Client (EEC); how user authorization / consent and application client (AC) authorization are ensured when calling functions opened by the EEC (to the AC), which in turn depends on functions opened by the network (e.g., location) via the Edge Enabled Server (EES) / Network Open Function (NEF); and how user or AC can consent, for example, to exposing location information in signaling to the network and using the AC's identifier (ID).

[0027] 3GPP TS 33.558 v18.0.1 (2023-01) describes security aspects for enabling edge applications in fifth-generation (5G) networks. Clause 5.1.3 of TS 33.558 provides the user consent requirement and statement: “If an EES trusted by the 3GPP core network is utilizing [5G core network (5GC)] services without a NEF, then the EES acts as the consent enforcement entity. Otherwise, if the EES is utilizing 5GC services via a NEF, then the NEF acts as the consent enforcement entity.”

[0028] 3GPP TS 33.501 v18.3.0 (2023-09) specifies the security architecture for 5G systems (5GS), which include 5GC and 5G New Radio (NR). Annex V of TS 33.501 states that "it is assumed that user consent is obtained from the end user. The end user is the subscriber itself or an authorized subscriber on behalf of the end user. Alternatively, the end user is authorized by the subscriber to provide consent. This means that user consent is always tied to subscription information." However, it should be noted that no specific method for obtaining such user content from the end user is specified within 3GPP. Annex V.3 of TS 33.501 states that "any network function (NF) considered as an enforcement point for user consent should support the retrieval of user consent parameters from the Unified Data Management (UDM)... The NF that obtains or examines the user consent parameters should treat the user consent parameters as valid until revoked."

[0029] 3GPP TS 23.222 v18.2.0 (2023-06) specifies aspects related to the Universal Application Programming Interface Framework (CAPIF). Clause 6.2.3 states that "Resource owners communicate with the authorization functions in the CAPIF Core Function [CCF] to provide and withdraw resource owner consent... API open functions (e.g., NEF, [Service Capability Open Function] SCEF) act as resource owner consent enforcement points as specified in 3GPP TS 33.501 [v18.3.0 (2023-09)] and interact with the authorization functions in the CCF via CAPIF-3. API open functions can retrieve resource owner consent parameters from the authorization functions."

[0030] 3GPP TS 23.434 v18.6.0 (2023-09) provides the architecture and aspects related to the Service Enablement Architecture Layer (SEAL). Clause 10.3.8 of TS 23.434 specifies that the Vertical Application Layer (VAL) "The server determines group information and the list of identities to which group announcements should be transmitted. This decision may be based on a list of authorized UEs and other criteria (e.g., user consent, service or vehicle driving profile)."

[0031] In previous networks, the point of access to the 3GPP core network via Application Function (AF) (e.g., via Network Open Function (NEF) or EES) provided a user consent enforcement point. With the introduction of the Application Enablement Layer, the EEC can pass user-sensitive or private information of the UE (e.g., from lower layers or the application layer) to the EES. However, existing TSs do not consider this a user consent enforcement point, even if the EEC may be serving multiple different applications (each potentially provided by a different application service provider). This can lead to the EEC blindly sharing user-sensitive or private information (e.g., user location, predicted location, user identity) with the Application Enablement Layer without proper user consent. For example, problems may arise if no user consent is provided for shared attributes, but the AC passes the attributes to the EEC and the EEC passes the attributes to the Enablement Layer without any checks. Embodiments of this disclosure describe processes for addressing these problems and deficiencies in current systems.

[0032] Figure 1 An architecture 100 according to some implementation schemes is illustrated. Architecture 100 includes a UE 104 coupled to a data network (DN) 112 via a core network 108 of a cellular network system. The UE 104 may also be coupled to the core network 108 via a radio access network (RAN) of the cellular network system; however, the RAN is not coupled to the core network 108. Figure 1This is clearly stated in the document. The core network 108 and the RAN can be collectively referred to as a cellular network system. In some implementations, the cellular network system may be a 3GPP system.

[0033] UE 104 may include AC 106 and an enabled client (EC) 120. Data network 112 may include AS 124 coupled to AC 116 at the user plane (e.g., application layer). Data network 112 may also include an enabled server (ES) 128 coupled to EC 120 of UE 104. EC 120 and ES 128 may communicate at the application enable layer, for which CN 108 enables the transport layer for the application enable layer. Although UE 104 is shown as having one EC (EC 120) and one AC (AC 116), in other embodiments, UE 104 may include multiple ECs or ACs, which may be dedicated to the same or different types of services.

[0034] In some implementations, architecture 100 may also include a configuration server (CS) 132 coupled to EC 120 and ES 128 at the application enablement layer.

[0035] EC 120 provides support functions for applications on UE 104, including retrieving configuration data from the application enablement layer and discovering ASs in DN 112. ES 128 provides EC 120 with services related to discovering and accessing resources in DN 112 (including ASs) or core network 108. CS 132 provides EC 120 with configuration information to enable the establishment of connections with DN 112 and ESs within DN 112.

[0036] In some implementations, architecture 100 may be an edge system in which EC 120 is an EEC, DN 112 is an Edge Data Network (EDN), AS 124 is an Edge Application Server (EAS), ES 128 is an EES, and CS 132 is an Edge Configuration Server (ECS). Unless otherwise described herein, the edge system may be similar to the edge system described in 3GPP TS 23.558.

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

[0038] While various implementations describe Architecture 100 for edge or SEAL services, the application enabling layer functionality provided by Architecture 100 can benefit 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 can be managed according to implementations of this disclosure. For example, some of these services may include the management of digital assets such as avatars (which are typically user-specific) and more precise user location requirements, including gestures and orientations.

[0039] Application layer entities and application enable layer entities (acting as the AF of core network 108) can interact with entities of core network 108. The AF can interact with entities of core network 108 directly as a trusted entity of core network 108 or via the NEF of core network 108 as an untrusted entity.

[0040] In some implementations, EC 120 may provide additional consent enforcement points. For example, EC 120 may receive a user request for service enablement from AC 116. To enable the service, EC 120 may send one or more Application Enable Layer (AEL) messages to ES 128 or CS 132. These messages may include user-sensitive or private information (e.g., user location, predicted location, user identity, or the application or configuration of UE 104). User-sensitive or private information may include information elements, attributes, etc., and may be collectively referred to herein as User Information (UI) parameters. Before sharing any UI parameters with ES 128 or CS 132, EC 120 may first determine that appropriate user consent has been obtained. This may be done based on one or more of the following aspects.

[0041] In a first aspect, EC 120 may obtain user consent attributes associated with shared UI parameters after receiving a request from AC 116 but before transmitting the AEL message. In some implementations, EC 120 may receive the user consent attributes from a trusted entity on UE 104. For example, the user may be considered a trusted entity that can provide user consent attributes to EC 120 via AC 116 of the UE 104 to which consent is provided, or through another application. In other implementations, EC 120 may receive user consent attributes from core network 108.

[0042] Clause 6.3.2 of TS 23.222 specifies that the application programming interface (API) "can be an application on a server or an application on the UE". Therefore, EC 120 hosted on UE 104 can act as an AF to invoke the user consent checking capabilities of core network 108. The user consent checking capabilities of core network 108 (e.g., UDM Subscription Data Management (SDM) service) can be used to obtain user consent attributes maintained by entities of core network 108.

[0043] In some implementations, there may be application enablement layer components or application layer components of user consent that are not maintained or captured by the core network 108. For example, separate sources may exist for different components of overall user consent. In these instances, EC 120 may obtain the desired user consent from one or more sources. For example, EC 120 may obtain one or more user consent components from the core network, either from AC 116, directly from the core network 108, or indirectly from the core network via ES 128 acting as a proxy for that EC. Different user consent components may be aligned or combined to provide the necessary consent to EC 120, thereby sharing UI parameters via AEL messages.

[0044] While some implementations describe EC 120 obtaining consent before sending UI parameters to ES 128 or CS 132, in other implementations, EC 120 may obtain consent before sending UI parameters to AC 116 or another EC of UE 104. For example, in some implementations, EC 120 may receive a user consent instruction from ES 128 before passing UI parameters to AC 116; or it may receive a user consent instruction from ES 128 or AC 116 before passing UI parameters to another EC of UE 104. When from ES 128, consent (and UI parameters) may originate from a user associated with another UE. Therefore, various implementations describe EC 120 as a consent enforcement point for situations where AC 116 opens information to the enable layer or the enable layer opens information to AC 116.

[0045] In the second aspect, the implementation describes that the entity providing the UI parameters also provides evidence that appropriate user consent has been obtained (e.g., a user consent token), instead of invoking a secondary consent check service after receiving the request and before passing the UI parameters. Referring to architecture 100, the provision of the UI parameters and the user consent token can be: from AC 116 to EC 120 (or vice versa); from EC 120 to ES 128 (or vice versa); from ES to AS 124 (or vice versa); or from AC 116 to another EC (on the same or different UEs).

[0046] Figure 2An access operation 200 using a user consent token according to a second aspect is illustrated according to some implementation schemes. Access operation 200 may include the user / application 204, AC 116, and EC 120 of UE 104 securely obtaining a user consent token from network entity 208. Network entity 208 may represent one or more servers, such as, for example, an authorization server, an identity server, a consent granting server, etc. Network entity 208 may be located in core network 108 or DN 112.

[0047] User / Application 204 can refer to a user of UE 104 or a user application of UE 104 (e.g., a web browser). Once obtained, the user consent token can be used to enable EC 120 to share UI parameters with ES 128 during the execution of enabling services.

[0048] EC 120 can use an authorization protocol similar to that described in Open Authorization (OAuth) 2.0 (Internet Engineering Task Force (IETF) Request for Notes (RFC) 6749) to obtain a user consent token.

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

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

[0051] In message 3, user / application 204 may send a request to network entity 208. This request may include the client ID and may be sent to a redirected Uniform Resource Identifier (URI).

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

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

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

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

[0056] In message 8, AC 116 may transmit a user consent token request to network entity 208. The user consent token request may include an authorization code and possibly other information. This other information may include additional credentials of AC 116 (e.g., client ID, secret or shared key, etc.), UI parameters that will potentially be shared in enabling services, etc. The authorization / credentials provided in the user consent token request indicate to network entity 208 that AC 116 has sufficient credentials to share UI parameters.

[0057] In some implementations, a user consent token may indicate to AC 116 permission to share a category of information. In other implementations, a user consent token may indicate to AC 116 permission to share specific information (e.g., one or more specific UI parameters).

[0058] Network entity 208 can verify that the authorization code and credentials are valid to allow AC 116 to share UI parameters, and in message 9, it can provide AC 116 with a user consent token.

[0059] Once AC 116 obtains the user consent token, it can transmit a request with the user consent token and parameters in message 10. The user consent token provides a trusted indication to EC 120 (the "resource server" in OAuth terminology) that AC 116 has the necessary authorization (e.g., user consent) to share the provided UI parameters with EC 120, and that EC 120 has the necessary authorization (e.g., user consent) to share the provided UI parameters with ES128.

[0060] In message 11, EC 120 may send an AEL request to ES. The AEL request may include UI parameters and, in some cases, a user consent token.

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

[0062] A sample user consent token based on the JWT format could be:

[0063] In this example, "alg" and "type" can be considered headers indicating that the encoded object is a JWT and is protected using the Hash-based Message Authentication Code (HMAC) Secure Hash Algorithm (SHA)-256. The payload "scope" and "exp" can include various verified claims that can be used to transmit the identity of an authenticated user or other relevant information between the identity provider and the service provider. The signature portion, HMAC_SCH256, securely verifies the user's consent token. The signature can be used to check that the header and payload have not been modified after being issued by network entity 208, allowing entities (e.g., EC 120 or ES 128) to verify the validity of the token for themselves without having to check with the token-issuing network entity 208.

[0064] As shown in the figure, the payload declaration includes a scope declaration "scope" and an expiration declaration "exp". Unless otherwise described herein, the scope declaration may resemble the scope declaration described in IETF RFC 9068 (October 2021) regarding access tokens. The scope declaration in a user consent token may identify the specific UI parameter (e.g., UIparameter_1) (or parameter category) to which the user consent token applies. For security purposes, a limited validity period may be provided to the user consent token by including an expiration declaration with a specific time when the user consent token expires. In other implementations, the limited validity period may be provided by other mechanisms, such as, for example, a lifetime parameter that provides the number of times the user access token can be used or the time from the token's issuance to its expiration.

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

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

[0067] In some implementations, AC 116 may obtain a user consent token from a trusted entity other than network entity 208. For example, AC 116 may obtain a user consent token from user / application 204 or AS 124. If AC 116 obtains a user consent token from AS 124, then AS can process obtaining a user consent token from network entity 208. This avoids the need for AC 116 to obtain a user consent token. It may be desirable for network entity 208 to be trusted by EC 120 and independent of AS 124 to prevent AS 124 from deceiving EC 120.

[0068] In some implementations, user consent can be obtained from the user, or it can be indicated in the request message in a manner similar to how a user indicates tracking preferences while browsing the web. For example, the request message can include a user consent token in its header, similar to how a user can indicate their tracking preferences in a non-tracking HTTP or global privacy control header.

[0069] In another example, user consent can be obtained / provided in a manner similar to the extension mechanism used for the EDNS client subnet (ECS) option, which helps the resolution process select a service address near the client. In ECS, the client is not explicitly asked for consent to the mechanism because the extension reveals information about the client's location that the resolver cannot infer otherwise. However, the client can prevent this mechanism, for example, by sending a zero-address ECS (e.g., invalidating the IP address to be included in the extension, thus preventing the DNS resolver from determining the client's location). While the ECS option does not mandate explicit user consent, similar processes can be modified according to various implementations to ensure sufficient user consent is obtained.

[0070] Figure 3 An AC registration process 300 according to some implementation schemes is illustrated. The AC registration process 300 may occur between AC 116 and EC120. Unless otherwise indicated herein, the AC registration process 300 may be similar to the AC registration process described in section 8.14.2.2.2 of 3GPP TS 23.558.

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

[0072] At 308, the AC registration process 300 may further include AC 116 transmitting an AC registration request to EC 120. The AC registration request may include a user consent token. The AC registration request and the included user consent token may be protected to ensure the integrity of the user consent token. The integrity protection of the user consent token may, for example, come from the nature of the token itself by using the JWT format described above. Additional / optional protection may be used to ensure the integrity of the token. In some embodiments, the user consent token may be included in the security credential information element of the AC registration request. In some embodiments, the AC registration request may include components such as those shown in Table 1 below. In addition to including the user consent token, Table 1 may also be similar to Table 8.14.3.2-1 of TS 23.558.

[0073]

[0074] Table 1 The AC registration process 300 may further include, at 312, EC 120 performing verification and registration. Verification may include EC 120 verifying the AC registration request. For example, EC 120 may verify the security credentials provided in the AC registration request. Upon successful verification, EC 120 may register the information provided in the AC registration request. Registration may occur within EC 120, where EC 120 maintains information that may include UI parameters. In other embodiments, registration may involve sending an AEL message to ES 128. In either case, EC 120 may only maintain / forward UI parameters that are determined to be associated with a user consent token indicating that sufficient consent to the sharing has been obtained. If the registration request includes UI parameters for which no indication of appropriate consent has yet been provided, EC 120 may reject the registration request.

[0075] Following successful registration, the AC registration process 300 may further include, at 316, EC 120 sending an AC registration response to AC 116 to provide an indication of successful registration. If the registration request includes UI parameters for which no indication of appropriate consent has yet been provided, the AC registration response may indicate that the registration request was rejected.

[0076] Figure 4 An EAS discovery process 400 according to some implementation schemes is illustrated. The EAS discovery process 400 may occur between AC 116, EC120, and ES 128. Unless otherwise indicated herein, the EAS discovery process 400 may be similar to the EAS discovery process described in section 8.3.2 of 3GPP TS 23.558.

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

[0078] At 408, the EAS discovery process 400 may also include AC 116 sending an EAS discovery request to EC 120. The EAS discovery request may include an AC profile (including, for example, the ID of AC 116), a list of EAS features (e.g., EAS discovery filters), and a user consent token (in some implementations, this may be in the AC profile).

[0079] The EAS discovery process 400 may also include, at 412, EC 120 checking security credentials. For example, EC 120 may determine whether AC 116 has included a user consent token for sharing UI parameters. EC 120 may verify the user access token before sending the EAL message for the EAS discovery process 400.

[0080] Upon determining that the user consent token is valid and indicating sufficient user consent for sharing UI parameters, the EAS discovery process 400 may include: at 416, EC 120 sending an EAS discovery request as an EAL message to ES 128. The EAS discovery request sent at 416 may include EC ID, UE ID, UE location, EAS discovery filters including AC profiles (if AC features are included), user consent token, etc.

[0081] Upon receiving an EAS discovery request, ES 128 may query CN 108 for the location of UE 104 in order to complete EAS discovery. This query may rely on UI parameters (e.g., the identity of UE 104). A user consent token can be evidence that the user wants ES 128 to know UI parameters that can assist ES 128 in making the most informed decision.

[0082] When determining the appropriate EAS, the EAS discovery process 400 may include: at 420, ES 128 transmitting an EAS discovery response. The EAS discovery response may include an EAS profile, which includes, for example, an EAS ID and an endpoint (e.g., an address).

[0083] At position 424, EC 120 can forward the EAS discovery response to AC 116.

[0084] Figure 3 and Figure 4An AC registration process and an EAS discovery process, which rely on user consent tokens to provide instructions for user consent according to the second aspect of this disclosure, are described. However, according to the first aspect of this disclosure, these and other processes may rely on EC 120 to obtain user consent before sharing UI parameters.

[0085] Figure 5 An operation flow / algorithm structure 500 is provided according to some implementation schemes. The operation flow / algorithm structure 500 can be executed by a UE (such as, for example, UE 104, device 800, or a component of device 800 (e.g., processor 804)).

[0086] The operation flow / algorithm structure 500 may include: at 504, receiving a first request. In some implementations, the first request may be received from the UE's AC at the UE's EC.

[0087] In some implementations, the EC may be an EEC, and the first request may involve an edge service. 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 the AC to request the transfer of application context / state from the source server (S-EAS) to the target application server (T-EAS). In yet another example, the request may be an EEC service subscription request, in which the AC requests updates on services provided by the EEC. In yet another example, the first request may be a UE ID request, in which the AC requests its UE identifier, which can be shared with the EAS.

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

[0089] In some implementations, user consent attributes can be obtained from the UE's application client.

[0090] The operation flow / algorithm structure 500 may further include: at 512, determining user consent associated with parameters. Parameters may be UI parameters, and user consent may be determined based on user consent attributes obtained at 508. UI parameters may be the UE's current location, the UE's predicted location, the user's identity, the identity of the UE's application, or information about another UE's user.

[0091] The operation flow / algorithm structure 500 may also include: at 516, sending a second request. In some implementations, the second request may be an AEL message sent to ES or CS.

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

[0093] In some implementations, the second request may involve 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 slicing capability enabling; data delivery; or application data analytics enabling.

[0094] Figure 6 An operation flow / algorithm structure 600 is provided according to some implementation schemes. The operation flow / algorithm structure 600 can be executed by a UE (such as, for example, UE 104, device 800, or a component of device 800 (e.g., processor 804)).

[0095] The operation flow / algorithm structure 600 may include: at 604, obtaining a user consent token. In some implementations, the user consent token may be obtained by the UE's AC and can be used to indicate user consent associated with parameters. Parameters may be UI parameters. UI parameters may be the UE's current location, the UE's predicted location, the user's identity, the identity of the UE's application, or information about another UE's user.

[0096] In some implementations, a user consent token can be obtained from the UE's user. In other implementations, an authentication process can be performed with a network entity. The user consent token can then be received from the network entity based on the authentication operation.

[0097] The operation flow / algorithm structure 600 may further include: at 608, providing a request with a user consent token. This request may be provided to the UE's enabled client. In some implementations, the EC may be an EEC, and the request may be an EAS discovery request, an application context relocation request, an EEC service subscription request, or a UE ID request.

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

[0099] In some implementations, the user consent token may be obtained by the ES or CS. For example, the ES or CS may provide the EC with UI parameters (e.g., the user's location determined by the network) and the user consent token. The EC can then verify that the user consent token provides sufficient consent to share UI parameters with the AC on the same UE as the EC.

[0100] Figure 7 An operation flow / algorithm structure 700 is provided according to some implementation schemes. The operation flow / algorithm structure 700 can be executed by a UE (such as, for example, UE 104, device 800, or a component of device 800 (e.g., processor 804)).

[0101] The operation flow / algorithm structure 700 may include: at 704, receiving a user consent token. In some implementations, the EC may receive the user consent token from the AC, ES, or CS. The user consent token can be used to indicate user consent associated with parameters. Parameters may be UI parameters. UI parameters may be the UE's current location, the UE's predicted location, the user's identity, the identity of the UE's application, or information about another UE's user.

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

[0103] The operation flow / algorithm structure 700 may also include: at 708, generating a message. In an implementation where the EC receives a user consent token from the AC, this message may be an AEL message.

[0104] The operation flow / algorithm structure 700 may also include: at 712, sending a message. In an implementation where the message is an AEL message, the AEL message can be used for edge services, SEAL services, metaverse services, or XR services.

[0105] In implementations where the EC is the EEC, AEL messages can be transmitted to the EES or ECS. In these implementations, AEL messages can be transmitted to: retrieve configuration information to enable the exchange of application data between the AC and EAS; discover the EAS in the EDN; detect UE mobility events; expose events of interest to the AC; or retrieve the UE identifier.

[0106] In an implementation where EC is a SEAL client, AEL messages can be delivered to the SEAL server and can be associated with: group management; configuration management; location management; identity management; key management; network resource management; notification management; network slicing capability enabling; data delivery; or application data analytics enabling.

[0107] Figure 8 Device 800 is illustrated according to some implementation schemes. Device 800 may be UE 104, an entity of core network 108, AS 124, ES 128, CS 132, network entity 208, or other nodes.

[0108] Device 800 may include a processor 804, an RF interface circuit 808, a memory / storage device 812, a user or CN interface 816, a sensor 820, a drive circuit 822, a power management integrated circuit (PMIC) 824, an antenna structure 826, and a battery 828. The components of device 800 may be implemented as integrated circuits (ICs), portions of integrated circuits, discrete electronic devices or other modules, logic components, hardware, software, firmware, or combinations thereof. Figure 8 The block diagram 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 arrangements of the components shown may occur in other specific implementations.

[0109] The components of device 800 can be coupled to a variety of other components via one or more interconnects 832, which can represent any type of interface, input / output, bus (local, system, or extension), transmit line, trace, optical connection, etc., allowing various circuit components (on common or different chips or chipsets) to interact with each other.

[0110] Processor 804 may include processor circuitry, such as, for example, baseband processor circuitry (BB) 804A, central processing unit circuitry (CPU) 804B, and graphics processing unit circuitry (GPU) 804C. Processor 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 device 812) to cause device 800 to perform operations as described herein associated with user consent at the application enable layer.

[0111] In some implementations, the baseband processor circuit 804A can access the communication protocol stack 836 in the memory / storage device 812 to communicate over a 3GPP-compliant network. Generally, the baseband processor circuit 804A can access the communication protocol stack to perform user plane functions at the PHY, MAC, RLC, PDCP, SDAP, and PDU layers; and control plane functions at the PHY, MAC, RLC, PDCP, RRC, and non-access layers. In some implementations, PHY layer operations may additionally / optionally be performed by components of the RF interface circuit 808.

[0112] The baseband processor circuit 804A can generate or process baseband signals or waveforms carrying information in a 3GPP-compliant network. In some implementations, the waveforms used for NR can be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and Discrete Fourier Transform Extended OFDM (DFT-S-OFDM) in the uplink.

[0113] Memory / storage device 812 may include one or more non-transitory computer-readable media, including instructions (e.g., a communication protocol stack 836) that can be executed by one or more processors in processor 804 to cause device 800 to perform the various operations described herein. Memory / storage device 812 includes any type of volatile or non-volatile memory that can be distributed throughout device 800. In some embodiments, some memory / storage devices 812 may be located on processor 804 itself (e.g., L1 cache and L2 cache), while other memory / storage devices 812 may be located external to processor 804 but accessible via a memory interface. Memory / storage device 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] RF interface circuitry 808 may include transceiver circuitry and a radio frequency front-end module (RFEM) that allows device 800 to communicate with other devices via a radio access network. RF interface circuitry 808 may include various components arranged in the transmit or receive path. These components may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0115] In the receiving path, the RFEM can receive the radiated signal from the air interface via antenna structure 826, and continue to filter and amplify the signal (using a low-noise amplifier). The RF signal can be provided to the receiver of the transceiver, which downconverts the signal into a baseband signal that is provided to the baseband processor of processor 804.

[0116] In the transmission path, the transceiver's transmitter up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM can then amplify the RF signal using a power amplifier before it is radiated across the air interface via antenna structure 826.

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

[0118] Antenna structure 826 may include antenna elements for converting electrical signals into radio waves to travel through the air and for converting received radio waves back into electrical signals. These antenna elements may be arranged in one or more antenna panels. Antenna structure 826 may have omnidirectional, directional, or combinations thereof antenna panels to enable beamforming and multiple-input multiple-output communication. Antenna structure 826 may include microstrip antennas, patch antennas, phased array antennas, printed antennas fabricated on the surface of one or more printed circuit boards, etc. Antenna structure 826 may have one or more panels designed for a specific frequency band included in FR1 or FR2.

[0119] User or CN interface 816 can be a user interface that includes various input / output (I / O) devices designed to enable user interaction with device 800. The user interface includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual components for accepting input, particularly one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, or a headset. Output device circuitry includes any physical or virtual components for displaying information or otherwise conveying information, such as sensor readings, actuator positions, or other similar information. Output device circuitry can include any number or combination of audio or visual displays, particularly one or more simple visual outputs / indicators (e.g., binary status indicators such as light-emitting diodes "LEDs," and multi-character visual outputs), or more complex outputs such as display devices or touchscreens (e.g., liquid crystal displays (LCDs), LED displays, quantum dot displays, projectors, etc.), where the output of characters, graphics, multimedia objects, etc., is generated or produced by the operation of device 800.

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

[0121] Sensor 820 may include a device, module, or subsystem designed to detect events or changes in its environment and transmit information (sensor data) about the detected events to another device, module, subsystem, etc. Examples of such sensors include, in particular: inertial measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS) including 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless aperture sensors); light detection and ranging sensors; proximity sensors (e.g., infrared radiation detectors, etc.); depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other similar audio capture devices; and so on.

[0122] The driving circuitry 822 may include software and hardware elements that operate to control a specific device embedded in, attached to, or otherwise communicatively coupled to the device 800. The driving circuitry 822 may include various drivers that allow other components to interact with or control various input / output (I / O) devices that may exist within or be connected to the device 800. For example, the driving circuitry 822 may include: a display driver for controlling and allowing access to a display device; a touchscreen driver for controlling and allowing access to a touchscreen interface; a sensor driver for acquiring sensor readings of a sensor 820 and controlling and allowing access to the sensor 820; a driver for acquiring actuator positions of electromechanical components or controlling and allowing access to electromechanical components; a camera driver for controlling and allowing access to an embedded image capture device; and an audio driver for controlling and allowing access to one or more audio devices.

[0123] The PMIC 824 manages the power supplied to various components of the device 800. Specifically, relative to the processor 804, the PMIC 824 controls power source selection, voltage scaling, battery charging, or DC-DC conversion.

[0124] In some implementations, the PMIC 824 can be controlled or otherwise integrated into various power-saving mechanisms of the device 800. For example, if the platform UE is in the RRC_Connected state, where it remains connected to the RAN node as it anticipates receiving traffic soon, then after a period of inactivity, the platform UE can enter a state known as Discontinuous Receive Mode (DRX). During this state, the device 800 can power down for short intervals to conserve power. If there is no data traffic activity over a longer period, the device 800 can transition to the RRC_Idle state, where the device disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 800 enters a very low-power state and performs paging, where it periodically wakes up again to listen to the network and then power down again. The device 800 can not receive data in this state; to receive data, the UE must transition back to the RRC_Connected state. Additional power-saving modes can render the device unusable from the network for periods exceeding the paging interval (from seconds to hours). During this period, the device is completely unable to connect to the network and can be completely powered off. Any data transmitted during this time will cause significant delays, which are assumed to be acceptable.

[0125] Battery 828 can power device 800, but in some examples, device 800 may be mounted or deployed in a fixed location and may have a power source coupled to the power grid. 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, etc. In some specific implementations, such as in vehicle-based applications, battery 828 may be a typical lead-acid automotive battery.

[0126] As described above, one aspect of the present invention is to collect and use data available from specific and legitimate sources to improve service delivery to users. This disclosure contemplates that, in some instances, the collected data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data may include demographic data, location-based data, online identifiers, telephone numbers, email addresses, home addresses, data or records related to a user's health or fitness level (e.g., vital sign measurements, medication information, exercise information), date of birth, or any other personal information.

[0127] This disclosure anticipates that entities responsible for collecting, analyzing, disclosing, transmitting, storing, or otherwise using such personal information data will comply with established privacy policies and / or privacy practices. Specifically, it is expected that such entities will implement and consistently apply privacy practices generally recognized as meeting or exceeding industry or governmental requirements for protecting user privacy. Such information regarding the use of personal data should be highlighted and easily accessible to users, and should be updated as data collection and / or use change. Users' personal information should be collected only for lawful use. Furthermore, such collection / sharing should only occur after receiving user consent or other lawful grounds provided for in applicable law. Additionally, such entities should consider taking any necessary steps to protect and safeguard the right to access such personal information data and ensure that other entities with access to personal information data comply with their privacy policies and procedures. Furthermore, such entities may be subject to third-party assessments to demonstrate their compliance with widely accepted privacy policies and practices. Moreover, policies and practices should be tailored to the specific types of personal information data collected and / or accessed, and made applicable to applicable laws and standards, including jurisdiction-specific considerations that may allow for the application of higher standards. For example, in the United States, the collection 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); while health data in other countries may be subject to other regulations and policies and should be handled accordingly.

[0128] Regardless of the foregoing, this disclosure also anticipates implementation schemes for users to selectively block the use or access to personal information data. That is, this disclosure anticipates providing hardware and / or software components to prevent or block access to such personal information data. For example, as described, user consent to the disclosure of UI parameters is within the user's control. If such consent is denied, unauthorized disclosure of the UI parameters is prevented.

[0129] Furthermore, the intent of this disclosure is that personal information data should be managed and processed in a manner that minimizes the risk of unintentional or unauthorized access or use. Once data is no longer needed, this risk can be minimized by restricting data collection and deleting data. Additionally, and where applicable, including in certain health-related applications, data deidentification can be used to protect user privacy. Deidentification can be facilitated, where appropriate, by removing identifiers, controlling the amount or specificity of stored data (e.g., collecting location data at the city level rather than the address level), controlling how data is stored (e.g., aggregating data among users), and / or other methods (such as differentiated privacy).

[0130] Therefore, while this disclosure broadly covers the use of user information to implement one or more of the various disclosed embodiments, it is also contemplated that various embodiments can be implemented without access to such user information. That is, various embodiments of the present invention are not rendered inoperable due to the absence of all or part of such user information. For example, content can be selected and delivered to the user based on aggregated non-personal information data or an absolute minimum amount of personal information, such as content disposed solely on the user's device or other non-personal information available for content delivery services.

[0131] For one or more embodiments, at least one of the components illustrated in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, or methods described in the Embodiments section below. For example, the baseband circuitry described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more embodiments described below. Similarly, circuitry associated with the UE, base station, or network element described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more embodiments described in the Embodiments section below.

[0132] Example Further exemplary implementations are provided in the following sections.

[0133] Example 1 includes a method comprising: receiving a first request from a first entity at an enabled client of a user equipment (UE); obtaining user consent attributes based on the first request; determining user consent associated with a parameter based on the user consent attributes; and sending a second request including the parameter to a second entity based on the first request and the determination of the user consent associated with the parameter.

[0134] Example 2 includes the method according to Example 1 or some other embodiment of this document, wherein obtaining the user consent attribute includes obtaining the user consent attribute from a network entity.

[0135] Example 3 includes the method according to Example 2 or some other embodiment herein, wherein the network entity is a network function of the cellular core network, and the attribute for obtaining user consent includes enabling the client to: as an application function, invoke the unified data management (UDM) subscription data management (SDM) service of the cellular core network.

[0136] Example 4 includes the method according to Example 2 or some other embodiment herein, wherein the network entity is outside the cellular core network.

[0137] Example 5 includes the method according to Example 1 or some other embodiment herein, wherein the first entity is an enable server or a configuration server, and the second entity is the application client of the UE.

[0138] Example 6 includes the method according to Example 1 or some other embodiment herein, wherein the first entity is the application client of the UE and the second entity is an enable server or a configuration server.

[0139] Example 7 includes the method according to Example 6 or some other embodiment of this document, wherein obtaining the user consent attribute includes obtaining the user consent attribute from the application client.

[0140] Example 8 includes the method according to Example 6 or some other embodiment herein, wherein the enabling client includes an edge-enabled client, and the enabling server or configuration server includes an edge-enabled server or an edge configuration server.

[0141] Example 9 includes the method described according to Example 8 or some other embodiment herein, wherein the first request is a registration request, an edge application server discovery request, an application context relocation request, an edge enabled client (EEC) service subscription request, or a UE identifier request.

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

[0143] Example 11 includes the method according to Example 6 or some other embodiment herein, wherein the enabling client includes a vertical industry Service Enabled Architecture Layer (SEAL) client, and the enabling server or configuration server is a SEAL server.

[0144] Example 12 includes the method according to Example 11 or some other embodiment herein, wherein the second request is associated with: group management; configuration management; location management; identity management; key management; network resource management; notification management; network slicing capability enabling; data transfer; or application data analytics enabling.

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

[0146] Example 14 includes a method comprising: obtaining a user consent token from a first entity to indicate user consent associated with parameters; and providing a request to an enabling client of a user equipment (UE) having the user consent token and the parameters, wherein the first entity is an application client, an enabling server, or a configuration server of the UE.

[0147] Example 15 includes the method according to Example 14 or some other embodiment herein, wherein obtaining the user consent token includes: obtaining the user consent token from a user of the UE.

[0148] Example 16 includes the method according to Example 14 or some other embodiment herein, the method further comprising: performing an authentication process with a network entity; and receiving the user consent token from the network entity based on the authentication process.

[0149] Example 17 includes the method according to Example 14 or some other embodiment herein, wherein the enabling client is an edge-enabled client and the request is an edge application server discovery request, an application context relocation request, an edge-enabled client (EEC) service subscription request, or a UE identifier request.

[0150] Example 18 includes the method according to Example 14 or some other embodiment herein, wherein the enabling client is an edge-enabled 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 includes: receiving an AC registration response from the edge-enabled client.

[0151] Example 19 includes a method comprising: receiving, at an enabling client, a user consent token from a first entity indicating user consent associated with parameters; generating a message having the parameters; and sending the message to a second entity.

[0152] Example 20 includes the method according to Example 19 or some other embodiment herein, wherein the first entity is an enabling server or a configuration server, and the second entity is an application client.

[0153] Example 21 includes the method according to Example 19 or some other embodiment herein, wherein the first entity is an application client, the second entity is an enable server or configuration server, and the message is an application enable layer message.

[0154] Example 22 includes the method according to Example 21 or some other embodiment herein, wherein the enabling client is an edge-enabled client, and the method further includes: receiving a request including the user consent token, wherein the request is an edge application server discovery request, an application context relocation request, an edge-enabled client (EEC) service subscription request, or a UE identifier request.

[0155] Example 23 includes the method according to Example 21 or some other embodiment herein, wherein the enabling client is an edge-enabled client, and the method further includes: receiving an application client (AC) registration request from the application client, wherein the user consent token is included in the security credential information element of the AC registration request.

[0156] Example 24 includes the method described according to Example 21 or some other embodiment herein, wherein the enabling client includes a vertical industry Service Enablement Architecture Layer (SEAL) client, the enabling 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 slicing capability enablement; data delivery; or application data analytics enablement.

[0157] Another embodiment may include an apparatus comprising one or more elements for performing the method described or associated with any of Embodiments 1 to 24 or any other method or process described herein.

[0158] Another embodiment may include one or more non-transitory computer-readable media, the one or more non-transitory computer-readable media including instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of the method or any other method or process described herein according to any one of embodiments 1 to 24.

[0159] Another embodiment may include an apparatus comprising one or more elements for performing the methods described or associated with any one of Embodiments 1 to 24 or any other methods or processes described herein.

[0160] Another embodiment may include the methods, techniques or processes described or associated with any one of embodiments 1 to 24 or any part or component thereof.

[0161] Another embodiment may include an apparatus comprising: one or more processors; and one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process described or associated with any one or more of embodiments 1 to 24.

[0162] Another embodiment may include signals described or associated with any one of embodiments 1 to 24 or any part or component thereof.

[0163] Another embodiment may include datagrams, information elements, packets, frames, segments, PDUs, or messages as described or associated with any one of embodiments 1 to 24 or any part or component thereof, or otherwise described in this disclosure.

[0164] Another embodiment may include a signal encoded with data as described or associated with any one of embodiments 1 to 24 or a portion or component thereof, or otherwise described in this disclosure.

[0165] Another embodiment may include signals encoded as datagrams, IEs, packets, frames, segments, PDUs, or messages as described or associated with any one of embodiments 1 to 24 or any part or component thereof, or otherwise described in this disclosure.

[0166] Another embodiment may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process described or associated with any one or a portion thereof according to Embodiments 1 to 24.

[0167] Another embodiment may include a computer program comprising instructions, wherein execution of the program by a processing element will cause the processing element to perform a method, technique, or process described or associated with any one or a portion thereof according to Embodiments 1 to 24.

[0168] Another embodiment may include signals in a wireless network as shown and described herein.

[0169] Another embodiment may include a method for communicating in a wireless network as shown and described herein.

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

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

[0172] Unless otherwise expressly stated, any embodiment described above may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific embodiments is illustrative and descriptive, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. In view of the teachings above, modifications and variations are possible, or modifications and variations may be obtained from practice of various embodiments.

[0173] Although the above embodiments have been described in considerable detail, many variations and modifications will become apparent to those skilled in the art once the above disclosure is fully understood. It is intended that the following claims be construed as encompassing all such variations and modifications.

Claims

1. A method, the method comprising: Receive the first request from the first entity at the user equipment (UE) enabled client; Based on the first request, obtain the user's consent attributes; Determine user consent associated with the parameters based on the aforementioned user consent attributes; as well as Based on the first request and the determination of the user's consent associated with the parameter, a second request including the parameter is sent to the second entity.

2. The method of claim 1, wherein obtaining the user consent attribute includes obtaining the user consent attribute from a network entity.

3. The method of claim 2, wherein the network entity is a network function of a cellular core network, and the attribute for obtaining user consent includes the enabling client: As an application function, it invokes the 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 the cellular core network.

5. The method according to claim 1 or 2, wherein the first entity is an enabling server or a configuration server, and the second entity is the application client of the UE.

6. The method according to claim 1 or 2, wherein the first entity is the application client of the UE, and the second entity is an enable server or a configuration server.

7. The method of claim 6, wherein obtaining the user consent attribute includes obtaining the user consent attribute from the application client.

8. The method of claim 6, wherein the enabling client includes an edge-enabled client, and the enabling server or configuration server includes an edge-enabled 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 enabled client (EEC) service subscription request, or a UE identifier request.

10. The method of claim 8, wherein the second request is used for: retrieving configuration information to enable the exchange of application data between the application client and the edge application server; discovering the edge application server in the edge data network; detecting UE mobility events; making events of interest available to the application client; or retrieving the UE identifier.

11. The method of claim 6, wherein the enabling client includes a vertical industry service enablement architecture layer (SEAL) client, and the enabling server 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 slicing capability enabling; data transmission; or application data analysis enabling.

13. The method according to claim 1 or 2, wherein the parameter is the current location of the UE, the predicted location of the UE, the user identity, the identity of the 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 used to indicate user consent associated with the parameters; and A request containing the user consent token and the parameters is provided to the enabled client of the user equipment (UE). The entity mentioned therein is the UE's application client, enable server, or configuration server.

15. The computer-readable medium of claim 14, wherein the user consent token is obtained from the user of the UE.

16. One or more computer-readable media according to claim 14 or 15, wherein the instructions, when executed, further cause the entity to: Perform the authentication process with network entities; and The user consent token is received from the network entity based on the authentication process.

17. The one or more computer-readable media of claim 14 or 15, wherein the enabling client is an edge-enabled client, and the request is an edge application server discovery request, an application context relocation request, an edge-enabled client (EEC) service subscription request, or a UE identifier request.

18. One or more computer-readable media according to claim 14 or 15, wherein the enabling client is an edge-enabled 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 instruction, when executed, further causes the entity to: Receive AC registration response from the edge-enabled client.

19. An apparatus having a circuit configured to enable a client, the enabling client being used for: Receive a user consent token from the first entity, indicating the user's consent associated with the parameter; Generate a message with the parameters described; as well as The message is sent to the second entity.

20. The apparatus of claim 19, wherein the first entity is an enabling 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 enable server or a configuration server, and the message is an application enable layer message.

22. The apparatus of claim 21, wherein the enabling client is an edge-enabled client, wherein the enabling client is further configured to: Receive a request including the user consent token, wherein the request is an edge application server discovery request, an application context relocation request, an edge enabled client (EEC) service subscription request, or a UE identifier request.

23. The apparatus of claim 21, wherein the enabling client is an edge-enabled client, the enabling client further being configured to: The application client receives an application client (AC) registration request, wherein the user consent token is included in the security credential information element of the AC registration request.

24. The apparatus of claim 21, wherein the enabling client includes a vertical industry Service Enablement Architecture Layer (SEAL) client, the enabling 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 slicing capability enabling; data delivery; or application data analytics enabling.

Images