Consent management procedure for wireless devices

Abstract

Methods, systems, and devices for wireless communication are described. A user equipment (UE) may send a consent profile registration request to a network entity, the consent profile registration request identifying a user identifier. The UE may send an agreement profile to the network entity based at least in part on the agreement profile registration request, the agreement profile including one or more agreement types of the user identifier that configure one or more agreement parameters of the user identifier at least on a per user basis.

Description

[0001] Cross-references

[0002] This patent application claims priority to U.S. patent application No. 17 / 825,946, entitled “CONSENT MANAGEMENT PROCEDURES FOR WIRELESS DEVICES,” filed by Kumar et al. on May 26, 2022, which is assigned to the assignee of this application. Technical Field

[0003] The following relates to wireless communications, including consent management procedures. Background Art

[0004] Wireless communication systems are widely deployed to provide various types of communication content, such as voice, video, packet data, messaging, broadcast, etc. These systems may be able to support communication with multiple users by sharing available system resources (e.g., time, frequency, and power). Examples of such multiple access systems include fourth generation (4G) systems (such as long term evolution (LTE) systems, advanced LTE (LTE-A) systems, or LTE-A Pro systems) and fifth generation (5G) systems (which may be referred to as new radio (NR) systems). These systems may employ techniques such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or discrete Fourier transform spread orthogonal frequency division multiplexing (DFT-S-OFDM). A wireless multiple access communication system may include one or more base stations, each of which supports wireless communication for a communication device, which may be referred to as a user equipment (UE). Summary of the invention

[0005] The described technology relates to improved methods, systems, devices and apparatuses that support consent management procedures. For example, the described technology provides a consent platform implemented in a wireless network, which improves the consent management of user data. For example, various aspects of the technology described herein provide a consent platform that implements various network functions (e.g., network functions implemented at least to some extent via a network entity). The consent platform may include a data governance server (DGS), which provides an interface to a user or end user to manage user consent and query the network about active data processing and other data governance procedures. The consent platform may include a subscription-based consent profile storage device (e.g., a unified data repository (UDR)), which hosts one or more consent profiles on a per-subscription basis within the network (e.g., within a network operator cloud network, a user equipment (UE) cloud, a core network, etc.). The consent profiles in the UDR can be made available to different network functions and services via unified data management (UDM). The consent platform may include a consent profile storage device (e.g., an end-user data repository (EUDR)) shared across subscriptions, which hosts the consent profiles on a per-user (e.g., per-end-user) basis and / or on a per-user per-device basis within the network. The consent profiles stored in the EUDR may be implemented as part of the UDR or separately from the UDR. Similarly, the end-user data manager (EUDM) may be implemented as part of the UDM or separate from the UDM, where references to the (E)UDM refer to either configuration (e.g., a configuration implemented as part of the UDM or separate from the UDM). The consent platform may include a consent management function (CMF) that manages user consent within the network in real time (e.g., dynamically).

[0006] For example, a first network entity (e.g., a network entity coupled to an (E)UDM in this example) may identify, store, or otherwise manage aspects of a consent profile for a user identifier (ID), such as an identifier associated with a user / end-user. Broadly speaking, the consent profile may include one or more consent types for the user ID. In some aspects, each consent type may configure consent parameters for the user identifier broadly, such as on a per-user or end-user basis. The first network entity may receive, obtain, or otherwise identify a request indicating the user identifier from a second network entity (e.g., a CMF in this example). In some aspects, the request may carry or otherwise convey a request for an access level to a data provider for at least one consent type. Thus, the first network entity may send, provide, or otherwise output a response indicating the access level to the second network entity. For example, the first network entity may use one or more of the consent types of the consent profile to identify or otherwise determine the access level, if any, of the data provider to the user data. The response may indicate the access level and the consent parameters of the consent type in response to the request.

[0007] In some examples, a first network entity (e.g., a network entity coupled to the DGS in this example) may receive, obtain, or otherwise identify a consent profile registration request. The network entity may receive or otherwise obtain the request from the user (such as from a user equipment (UE) or other device of the user). In some examples, the request may carry or otherwise convey an indication of a user ID. In this example, the first network entity may receive or otherwise obtain the consent profile (e.g., from the UE) in response to the request. The consent profile may include a consent type for the user ID, which configures consent parameters for the user ID on a per-user basis. The first network device may send or otherwise provide the consent profile to a second network entity (e.g., (E)UDM in this example). Thus, the DGS may collaborate with the (E)UDM to supply a consent profile for the user ID.

[0008] In some examples, the device of the user (e.g., one of the UE or other devices of the user) may include a data governance client (DGC) (e.g., operating at an application layer within the wireless network) that supports consent management functions for the user. For example, the UE may send or otherwise provide the consent profile registration request to a network entity (e.g., a network entity coupled to the DGS in this example). The UE may send or otherwise provide the consent profile to the network entity in response to the request.

[0009] In some examples, a first network entity (e.g., a network entity coupled to a CMF in this example) may receive or otherwise obtain a first request requesting access to the user data. The first request may be obtained from a data provider (such as a data provider within the network or separate from the network). The data provider (e.g., alone or in combination with one or more consumers of the user data) may correspond to or otherwise be associated with a consent type for a user ID. The first network entity may send or otherwise provide a second request indicating the user ID and requesting an access level for the user identifier (e.g., the access level of the data provider or the data consumer initiating the first request). The second request may be provided to a second network entity (e.g., UDM / EUDM in this example). The first network entity may receive or otherwise obtain a first response indicating the requested access level from the second network entity, and send or otherwise provide a second response indicating the access level to the data provider.

[0010] A method for wireless communication at a first network entity is described. The method may include: identifying a consent profile for a user ID, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID on at least a per-user basis; receiving a request from a second network entity, the request indicating the user ID and requesting an access level for a data provider corresponding to at least one of the one or more consent types; and sending a response to the second network entity indicating the access level based on the request and the one or more consent parameters for at least one consent type.

[0011] An apparatus for wireless communication at a first network entity is described. The apparatus may include a processor, a memory coupled to the processor, and instructions stored in the memory. The instructions may be executed by the processor to cause the apparatus to: identify a consent profile for a user ID, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID on at least a per-user basis; receive a request from a second network entity, the request indicating the user ID and requesting an access level for a data provider corresponding to at least one of the one or more consent types; and send a response indicating the access level to the second network entity based on the request and the one or more consent parameters of at least one consent type.

[0012] Another apparatus for wireless communication at a first network entity is described. The apparatus may include: means for identifying a consent profile for a user ID, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID on at least a per-user basis; means for receiving a request from a second network entity, the request indicating the user ID and requesting an access level for a data provider corresponding to at least one of the one or more consent types; and means for sending a response indicating the access level to the second network entity based on the request and the one or more consent parameters for at least one consent type.

[0013] A non-transitory computer-readable medium storing code for wireless communication at a first network entity is described. The code may include instructions executable by a processor to: identify a consent profile for a user ID, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID on at least a per-user basis; receive a request from a second network entity, the request indicating the user ID and requesting an access level for a data provider corresponding to at least one of the one or more consent types; and send a response indicating the access level to the second network entity based on the request and the one or more consent parameters of at least one consent type.

[0014] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, means, or instructions for storing the consent profile and the subscription ID of the user ID in a UDM entity, wherein the first network entity includes the UDM entity.

[0015] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, components, or instructions for storing a subscription ID for the user ID in a UDM entity and storing a consent profile for the user ID in an end-user UDM entity, wherein the first network entity includes the end-user UDM entity.

[0016] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, components, or instructions for receiving a consent profile ID from a third network entity associated with the first network entity, wherein a consent profile identifying a user ID may be based on receiving the consent profile ID.

[0017] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the consent profile ID maps the consent profile at the UE to a user associated with the user ID.

[0018] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, components, or instructions for: receiving an update message identifying updated parameters of at least one of the one or more consent types; and updating the one or more consent parameters of at least one consent type of the consent profile based on the update message.

[0019] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the update message may be received from a third network entity or a UE associated with a consent profile ID of the consent profile.

[0020] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, components, or instructions for: receiving an update message from a second network entity identifying an updated end-user device associated with a user ID; and updating the one or more consent parameters of the user ID to include the updated end-user device based on the update message.

[0021] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, a subscription ID associated with the user ID comprises a fifth generation subscription permanent ID.

[0022] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the subscription ID associated with the user ID comprises a universal public subscription ID.

[0023] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, a user ID may be associated with a subscription ID, a consent profile ID, or both.

[0024] In some examples of the methods, apparatus, and non-transitory computer-readable media described herein, the consent profile and the consent profile ID of the consent profile may be determined based on results of a Fast Identity Online (FIDO) authentication procedure for a user associated with the user ID.

[0025] A method for wireless communication at a first network entity is described. The method may include: receiving a consent profile registration request identifying a user ID from a UE; receiving a consent profile from the UE based on the consent profile registration request, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID on at least a per-user basis; and sending the consent profile to a second network entity.

[0026] An apparatus for wireless communication at a first network entity is described. The apparatus may include a processor, a memory coupled to the processor, and instructions stored in the memory. The instructions may be executed by the processor to cause the apparatus to: receive a consent profile registration request identifying a user ID from a UE; receive a consent profile from the UE based on the consent profile registration request, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID at least on a per-user basis; and send the consent profile to a second network entity.

[0027] Another apparatus for wireless communication at a first network entity is described. The apparatus may include: means for receiving a consent profile registration request identifying a user ID from a UE; means for receiving a consent profile from the UE based on the consent profile registration request, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID on at least a per-user basis; and means for sending the consent profile to a second network entity.

[0028] A non-transitory computer-readable medium storing code for wireless communication at a first network entity is described. The code may include instructions executable by a processor to: receive a consent profile registration request identifying a user ID from a UE; receive a consent profile from the UE based on the consent profile registration request, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID at least on a per-user basis; and send the consent profile to a second network entity.

[0029] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, components, or instructions for: receiving a data collection query from the UE, the data collection query requesting a data access status associated with a user associated with a consent profile ID of the consent profile; sending the data collection query and the user ID to a third network entity; receiving a data collection response from the third network entity based on the data collection query and the user ID, the data collection response identifying a data provider that accesses data associated with the consent profile; and sending the data collection response to the UE based on the data collection query.

[0030] A method for wireless communication at a UE is described. The method may include: sending a consent profile registration request to a network entity, the consent profile registration request identifying a user ID; and sending a consent profile to the network entity based on the consent profile registration request, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID on at least a per-user basis.

[0031] An apparatus for wireless communication at a UE is described. The apparatus may include a processor, a memory coupled to the processor, and instructions stored in the memory. The instructions may be executed by the processor to cause the apparatus to: send a consent profile registration request to a network entity, the consent profile registration request identifying a user ID; and send a consent profile to the network entity based on the consent profile registration request, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID at least on a per-user basis.

[0032] Another apparatus for wireless communication at a UE is described. The apparatus may include: a component for sending a consent profile registration request to a network entity, the consent profile registration request identifying a user ID; and a component for sending a consent profile to the network entity based on the consent profile registration request, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID on at least a per-user basis.

[0033] A non-transitory computer-readable medium storing code for wireless communication at a UE is described. The code may include instructions executable by a processor to perform the following operations: sending a consent profile registration request to a network entity, the consent profile registration request identifying a user ID; and sending a consent profile to the network entity based on the consent profile registration request, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID at least on a per-user basis.

[0034] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, components, or instructions for: sending a data collection query to the network entity, the data collection query requesting a data access status associated with the consent profile; and receiving a data collection response from the network entity based on the data collection query, the data collection response identifying a data provider that accesses the data associated with the consent profile.

[0035] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, components, or instructions for: sending an update message to the network entity identifying updated parameters of at least one of the one or more consent types; and receiving a confirmation message from the network entity confirming the update of the updated parameters of the at least one consent type based on the update message.

[0036] A method for wireless communication at a first network entity is described. The method may include: receiving a first request from a data provider requesting access to data associated with a user ID, the data provider corresponding to at least one of one or more consent types for the user ID; sending a second request to a second network entity, the second request indicating the user ID and requesting an access level for the data provider; receiving a first response from the second network entity indicating the access level; and sending a second response to the data provider indicating the access level.

[0037] An apparatus for wireless communication at a first network entity is described. The apparatus may include a processor, a memory coupled to the processor, and instructions stored in the memory. The instructions may be executed by the processor to cause the apparatus to: receive a first request from a data provider requesting access to data associated with a user ID, the data provider corresponding to at least one of one or more consent types for the user ID; send a second request to a second network entity, the second request indicating the user ID and requesting an access level for the data provider; receive a first response from the second network entity indicating the access level; and send a second response to the data provider indicating the access level.

[0038] Another apparatus for wireless communication at a first network entity is described. The apparatus may include: means for receiving a first request from a data provider requesting access to data associated with a user ID, the data provider corresponding to at least one of one or more consent types for the user ID; means for sending a second request to a second network entity, the second request indicating the user ID and requesting an access level for the data provider; means for receiving a first response from the second network entity indicating the access level; and means for sending a second response to the data provider indicating the access level.

[0039] A non-transitory computer-readable medium storing code for wireless communication at a first network entity is described. The code may include instructions executable by a processor to: receive a first request from a data provider requesting access to data associated with a user ID, the data provider corresponding to at least one of one or more consent types for the user ID; send a second request to a second network entity, the second request indicating the user ID and requesting an access level for the data provider; receive a first response from the second network entity indicating the access level; and send a second response to the data provider indicating the access level.

[0040] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, components, or instructions for sending an indication to the data provider to grant access to at least a portion of the data associated with the user ID based on the second response, wherein at least the portion of the data may be based on the access level.

[0041] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, components, or instructions for: receiving an access level request for data associated with at least one consent type for a user ID from a second data provider; and sending an access level response to the second data provider indicating a second access level for the second data provider.

[0042] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, components, or instructions for identifying a set of one or more data consumers that access data associated with a user ID based on the one or more consent types for the user ID.

[0043] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, components, or instructions for: receiving a deactivation request for a subset of the one or more consent types for the user ID from the data provider; and updating the access level of the data provider to a deactivated state based at least in part on the deactivation request.

[0044] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, components, or instructions for: receiving a revocation request for the subset of the one or more consent types for the user ID from a second network entity; and updating an access level associated with the subset of the one or more consent types to a revoked state based on the revocation request.

[0045] Some examples of the methods, apparatus, and non-transitory computer-readable media described herein may also include operations, features, components, or instructions for: receiving a dynamic access request message from the data provider requesting access to a portion of data associated with the user ID; sending the dynamic access request message to a second network entity, the dynamic access request message identifying the portion of the data associated with the user ID and at least one of the one or more consent types; and receiving a dynamic access response from the second network entity, the dynamic access response authorizing or denying access to the portion of the data associated with the user ID; and sending the dynamic access response to the data provider. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 An example of a wireless communication system supporting a consent management procedure in accordance with one or more aspects of the present disclosure is illustrated.

[0047] Figure 2 An example of a wireless communication system supporting a consent management procedure in accordance with one or more aspects of the present disclosure is illustrated.

[0048] Figure 3 An example of a consent configuration file that supports a consent management procedure in accordance with one or more aspects of the present disclosure is illustrated.

[0049] Figure 4A and Figure 4B An example of a provisioning configuration that supports a consent management procedure in accordance with one or more aspects of the present disclosure is illustrated.

[0050] Figure 5 An example of a method of supporting a consent management procedure in accordance with one or more aspects of the present disclosure is illustrated.

[0051] Figure 6 An example of a method of supporting a consent management procedure in accordance with one or more aspects of the present disclosure is illustrated.

[0052] Figure 7 An example of a consent management configuration that supports a consent management procedure in accordance with one or more aspects of the present disclosure is illustrated.

[0053] Figure 8 An example of a method of supporting a consent management procedure in accordance with one or more aspects of the present disclosure is illustrated.

[0054] Fig. 9 An example of a method of supporting a consent management procedure in accordance with one or more aspects of the present disclosure is illustrated.

[0055] Fig.10 An example of a method of supporting a consent management procedure in accordance with one or more aspects of the present disclosure is illustrated.

[0056] Fig.11 An example of a method of supporting a consent management procedure in accordance with one or more aspects of the present disclosure is illustrated.

[0057] Fig.12 An example of a method of supporting a consent management procedure in accordance with one or more aspects of the present disclosure is illustrated.

[0058] Fig.13 An example of a method of supporting a consent management procedure in accordance with one or more aspects of the present disclosure is illustrated.

[0059] Fig.14 An example of a method of supporting a consent management procedure in accordance with one or more aspects of the present disclosure is illustrated.

[0060] Fig.15 and Fig.16 A block diagram illustrating a device that supports consent management procedures in accordance with one or more aspects of the present disclosure.

[0061] Fig.17 A block diagram of a communications manager supporting consent management procedures is shown in accordance with one or more aspects of the present disclosure.

[0062] Fig.18 A diagram illustrating a system including a device that supports a consent management procedure in accordance with one or more aspects of the present disclosure.

[0063] Fig.19 and Fig. 20 A block diagram illustrating a device that supports consent management procedures in accordance with one or more aspects of the present disclosure.

[0064] Fig.21 A block diagram of a communications manager supporting consent management procedures is shown in accordance with one or more aspects of the present disclosure.

[0065] Fig. 22 A diagram illustrating a system including a device that supports a consent management procedure in accordance with one or more aspects of the present disclosure.

[0066] Figure 23 to Figure 26 A flow chart illustrating a method of supporting a consent management procedure in accordance with one or more aspects of the present disclosure is shown. DETAILED DESCRIPTION

[0067] Wireless communication systems can benefit from data analysis to support enhanced mobile user experience. Such technologies typically use data or other information about users (e.g., associated with a user identifier of the user) to improve products and services provided to users. Such data analysis may involve user consent for managing access to user data and other information. Other different networks typically define user consent on a per-subscription basis. For example, as part of a subscription procedure, a user may subscribe, sign up, or otherwise access a service (e.g., a data consumer), and may be granted access to user data. Based on the granted user consent, the service may access user data when providing services to the user, which may be on an on-demand basis or may be continuous access. However, such technologies are not sufficient to address the nature of extended user data and users of wireless communications (e.g., such as when the same user may be associated with multiple devices). In addition, such technologies do not provide a mechanism for providing and managing granular consent for user data that supports multiple services, use of multiple devices, etc. In addition, such technologies limit the ability of users to update or revoke their consent to data access.

[0068] Therefore, various aspects of the described technology provide a consent platform implemented in a wireless network that improves the consent management of user data. For example, various aspects of the technology described herein provide a consent platform that implements various network functions (e.g., network functions implemented at least to some extent via network entities). The consent platform may include a data governance server (DGS) that provides an interface to a user or end user to manage user consent and query the network about active data processing and other data governance procedures. The consent platform may include a subscription-based consent profile storage device (e.g., in a unified data repository (UDR)), which hosts one or more consent profiles in the network (e.g., on a per-subscription basis). The consent profile may include a unified data management (UDM), which provides access to the consent profile at the UDR to other network functions and services. The consent platform may include a consent profile storage device shared across subscriptions (e.g., an end-user data repository (EUDR)), which hosts the consent profile on a per-user (e.g., per-end-user) basis and / or on a per-user per-device basis in the network. The consent profiles stored in the EUDR may be made available to different network functions and services via the UDM or End-User Unified Data Management (EUDM). In some examples, the EUDR may be implemented as part of the UDR or separately from the UDR. Similarly, the EUDM may be implemented as part of the UDM or separate from the UDM, where references to the (E)UDM refer to either configuration (e.g., a configuration implemented as part of the UDM or separate from the UDM). The consent platform may include a consent management function (CMF) that manages user consent within the network in real time (e.g., dynamically).

[0069] For example, a first network entity (e.g., a network entity coupled to an (E)UDM in this example) may identify, store, or otherwise manage aspects of a consent profile for a user identifier (ID), such as an identifier associated with a user / end-user. Broadly speaking, the consent profile may include one or more consent types for the user ID. In some aspects, each consent type may configure consent parameters for the user identifier broadly, such as on a per-user or end-user basis. The first network entity may receive, obtain, or otherwise identify a request indicating the user identifier from a second network entity (e.g., a CMF in this example). In some aspects, the request may carry or otherwise convey a request for an access level to a data provider for at least one consent type. Thus, the first network entity may send, provide, or otherwise output a response indicating the access level to the second network entity. For example, the first network entity may use one or more of the consent types of the consent profile to identify or otherwise determine the access level, if any, of the data provider to the user data. The response may indicate the access level and the consent parameters of the consent type in response to the request.

[0070] In some examples, a first network entity (e.g., a network entity coupled to the DGS in this example) may receive, obtain, or otherwise identify a consent profile registration request. The network entity may receive or otherwise obtain the request from the user (such as from a user equipment (UE) or other device of the user). In some examples, the request may carry or otherwise convey an indication of a user ID. In this example, the first network entity may receive or otherwise obtain the consent profile (e.g., from the UE) in response to the request. The consent profile may include a consent type for the user ID, which configures consent parameters for the user ID on a per-user basis. The first network device may send or otherwise provide the consent profile to a second network entity (e.g., (E)UDM in this example). Thus, the DGS may collaborate with the (E)UDM to supply a consent profile for the user ID.

[0071] In some examples, the device of the user (e.g., one of the UE or other devices of the user) may include a data governance client (DGC) (e.g., operating at an application layer within the wireless network) that supports consent management functions for the user. For example, the UE may send or otherwise provide the consent profile registration request to a network entity (e.g., a network entity coupled to the DGS in this example). The UE may send or otherwise provide the consent profile to the network entity in response to the request.

[0072] In some examples, a first network entity (e.g., a network entity coupled to a CMF in this example) may receive or otherwise obtain a first request requesting access to the user data. The first request may be obtained from a data provider (such as a data provider within the network or separate from the network). The data provider (e.g., alone or in combination with one or more consumers of the user data) may correspond to or otherwise be associated with a consent type for a user ID. The first network entity may send or otherwise provide a second request indicating the user ID and requesting an access level for the user identifier (e.g., the access level of the data provider or the data consumer initiating the first request). The second request may be provided to a second network entity (e.g., UDM / EUDM in this example). The first network entity may receive or otherwise obtain a first response indicating the requested access level from the second network entity, and send or otherwise provide a second response indicating the access level to the data provider.

[0073] Aspects of the disclosure are first described in the context of a wireless communication system. Aspects of the disclosure are further illustrated and described by and with reference to apparatus diagrams, system diagrams, and flow diagrams related to consent management procedures.

[0074] Figure 1 An example of a wireless communication system 100 supporting a consent management procedure according to one or more aspects of the present disclosure is illustrated. The wireless communication system 100 may include one or more network entities 105, one or more UEs 115, and a core network 130. In some examples, the wireless communication system 100 may be a Long Term Evolution (LTE) network, an Advanced LTE (LTE-A) network, an LTE-A Pro network, a New Radio (NR) network, or a network operating according to other systems and radio technologies (including future systems and radio technologies not explicitly mentioned herein).

[0075] The network entities 105 may be dispersed throughout a geographic area to form the wireless communication system 100, and may include devices in different forms or with different capabilities. In various examples, the network entities 105 may be referred to as network elements, mobility elements, radio access network (RAN) nodes, or network equipment, among other names. In some examples, the network entities 105 and the UE 115 may communicate wirelessly via one or more communication links 125 (e.g., radio frequency (RF) access links). For example, the network entity 105 may support a coverage area 110 (e.g., a geographic coverage area), and the UE 115 and the network entity 105 may establish one or more communication links 125 over the coverage area. The coverage area 110 may be an example of a geographic area, and the network entity 105 and the UE 115 may support signal communications over the geographic area according to one or more radio access technologies (RATs).

[0076] The UEs 115 may be dispersed throughout the coverage area 110 of the wireless communication system 100, and each UE 115 may be stationary or mobile, or stationary and mobile at different times. The UEs 115 may be devices in different forms or with different capabilities. Figure 1 Some example UEs 115 are illustrated in FIG. 1 . The UEs 115 described herein can communicate with various types of devices, such as Figure 1 Communicate with other UEs 115 or network entities 105) as shown.

[0077] As described herein, a node of the wireless communication system 100 (which may be referred to as a network node or a wireless node) may be a network entity 105 (e.g., any network entity described herein), a UE 115 (e.g., any UE described herein), a network controller, an apparatus, a device, a computing system, one or more components, or another suitable processing entity configured to perform any of the techniques described herein. For example, the node may be a UE 115. As another example, the node may be a network entity 105. As another example, a first node may be configured to communicate with a second node or a third node. In one aspect of this example, the first node may be a UE 115, the second node may be a network entity 105, and the third node may be a UE 115. In another aspect of this example, the first node may be a UE 115, the second node may be a network entity 105, and the third node may be a network entity 105. In other aspects of this example, the first node, the second node, and the third node may be different relative to these examples. Similarly, references to UE 115, network entity 105, apparatus, device, computing system, etc. may include disclosure of UE 115, network entity 105, apparatus, device, computing system, etc. as nodes. For example, a disclosure that UE 115 is configured to receive information from network entity 105 also discloses that the first node is configured to receive information from a second node.

[0078] In some examples, the network entities 105 may communicate with the core network 130, or with each other, or both. For example, the network entities 105 may communicate with the core network 130 via one or more backhaul links 120 (e.g., according to S1, N2, N3, or other interface protocols). In some examples, the network entities 105 may communicate with each other directly (e.g., directly between the network entities 105) or indirectly (e.g., via the core network 130) via the backhaul communication link 120 (e.g., according to X2, Xn, or other interface protocols). In some examples, the network entities 105 may communicate with each other via the midhaul communication link 162 (e.g., according to the midhaul interface protocol) or the fronthaul communication link 168 (e.g., according to the fronthaul interface protocol) or any combination thereof. The backhaul communication link 120, the midhaul communication link 162, or the fronthaul communication link 168 may be or include one or more wired links (e.g., electrical links, optical fiber links), one or more wireless links (e.g., radio links, wireless optical links), or other examples or various combinations thereof. UE 115 may communicate with core network 130 via communication link 155 .

[0079] One or more of the network entities 105 described herein may include or may be referred to as a base station 140 (e.g., a transceiver base station, a radio base station, an NR base station, an access point, a radio transceiver, a Node B, an evolved Node B (eNB), a next generation Node B, or a Gigabit Node B (any of which may be referred to as a gNB), a 5G NB, a next generation eNB (ng-eNB), a Home Node B, a Home Evolved Node B, or other suitable terms). In some examples, the network entity 105 (e.g., a base station 140) may be implemented in an aggregated (e.g., monolithic, standalone) base station architecture, which may be configured to utilize a protocol stack that is physically or logically integrated within a single network entity 105 (e.g., a single RAN node, such as a base station 140).

[0080] In some examples, the network entity 105 may be implemented in a disaggregated architecture (e.g., a disaggregated base station architecture, a disaggregated RAN architecture) that may be configured to utilize a protocol stack that is physically or logically distributed between two or more network entities 105, such as an integrated access backhaul (IAB) network, an open RAN (O-RAN) (e.g., a network configuration sponsored by the O-RAN Alliance), or a virtualized RAN (vRAN) (e.g., a cloud RAN (C-RAN)). For example, the network entity 105 may include one or more of the following: a central unit (CU) 160, a distributed unit (DU) 165, a radio unit (RU) 170, a RAN intelligent controller (RIC) 175 (e.g., a near real-time RIC (near RT RIC), a non-real-time RIC (non-RT RIC)), a service management and orchestration (SMO) 180 system, or any combination thereof. The RU 170 may also be referred to as a radio head, a smart radio head, a remote radio head (RRH), a remote radio unit (RRU), or a transmit receive point (TRP). One or more components of the network entity 105 in the decomposed RAN architecture may be co-located, or one or more components of the network entity 105 may be located in distributed locations (e.g., separate physical locations). In some examples, one or more network entities 105 of the decomposed RAN architecture may be implemented as virtual units (e.g., virtual CU (VCU), virtual DU (VDU), virtual RU (VRU)).

[0081] The functional split between CU 160, DU 165, and RU 170 is flexible and may support different functionalities depending on which functions (e.g., network layer functions, protocol layer functions, baseband functions, RF functions, and any combination thereof) are performed at CU 160, DU 165, and RU 170. For example, a functional split of a protocol stack may be employed between CU 160 and DU 165 such that CU 160 may support one or more layers of a protocol stack and DU 165 may support one or more different layers of a protocol stack. In some examples, CU 160 may host higher protocol layer (e.g., layer 3 (L3), layer 2 (L2)) functionality and signaling (e.g., radio resource control (RRC), service data adaptation protocol (SDAP), packet data convergence protocol (PDCP)). The CU 160 may be connected to one or more DUs 165 or RUs 170, and the one or more DUs 165 or RUs 170 may host lower protocol layers, such as layer 1 (L1) (e.g., physical (PHY) layer) or L2 (e.g., radio link control (RLC) layer, medium access control (MAC) layer) functionality and signaling, and may each be at least partially controlled by the CU 160. Additionally or alternatively, a functional split of the protocol stack may be employed between the DU 165 and the RU 170, such that the DU 165 may support one or more layers of the protocol stack, and the RU 170 may support one or more different layers of the protocol stack. The DU 165 may support one or more different cells (e.g., via one or more RUs 170). In some cases, the functional split between CU 160 and DU 165 or between DU 165 and RU 170 may be within the protocol layer (e.g., some functions of the protocol layer may be performed by one of CU 160, DU 165, or RU 170, while other functions of the protocol layer are performed by the other of CU 160, DU 165, or RU 170). CU 160 may be further functionally split into CU control plane (CU-CP) functions and CU user plane (CU-UP) functions. CU 160 may be connected to one or more DUs 165 via midhaul communication links 162 (e.g., F1, F1-c, F1-u), and DU 165 may be connected to one or more RUs 170 via fronthaul communication links 168 (e.g., open fronthaul (FH) interface). In some examples, midhaul communication link 162 or fronthaul communication link 168 may be implemented based on interfaces (eg, channels) between layers of a protocol stack supported by respective network entities 105 communicating over those communication links.

[0082] In some wireless communication systems (e.g., wireless communication system 100), infrastructure and spectrum resources for radio access may support wireless backhaul link capabilities to supplement wired backhaul connections, thereby providing an IAB network architecture (e.g., to the core network 130). In some cases, in an IAB network, one or more network entities 105 (e.g., IAB nodes 104) may be partially controlled by each other. One or more IAB nodes 104 may be referred to as host entities or IAB hosts. One or more DUs 165 or one or more RUs 170 may be partially controlled by one or more CUs 160 associated with a host network entity 105 (e.g., a host base station 140). One or more host network entities 105 (e.g., IAB hosts) may communicate with one or more additional network entities 105 (e.g., IAB nodes 104) via supported access and backhaul links (e.g., backhaul communication links 120). The IAB node 104 may include an IAB mobile terminal (IAB-MT) controlled (e.g., scheduled) by a DU 165 of a coupled IAB host. The IAB-MT may include an independent set of antennas for relaying communications with the UE 115, or may share the same antennas of the IAB node 104 (e.g., of the RU 170) for access via the DU 165 of the IAB node 104 (e.g., referred to as a virtual IAB-MT (vIAB-MT)). In some examples, the IAB node 104 may include a DU 165 that supports communication links with additional entities (e.g., IAB node 104, UE 115) within a relay chain or configuration (e.g., downstream) of the access network. In such cases, one or more components of the decomposed RAN architecture (e.g., one or more IAB nodes 104 or components of the IAB node 104) may be configured to operate according to the techniques described herein.

[0083] For example, an access network (AN) or RAN may include an access node (e.g., an IAB host), communications between an IAB node 104 and one or more UEs 115. The IAB host may facilitate a connection between the core network 130 and the AN (e.g., via a wired or wireless connection to the core network 130). That is, the IAB host may refer to a RAN node having a wired or wireless connection to the core network 130. The IAB host may include a CU 160 and at least one DU 165 (e.g., and RU 170), wherein the CU 160 may communicate with the core network 130 via an interface (e.g., a backhaul link). The IAB host and the IAB node 104 may communicate via an F1 interface according to a protocol defining a signaling message (e.g., an F1 AP protocol). Additionally or alternatively, the CU 160 may communicate with the core network via an interface (which may be an example of a portion of a backhaul link), and may communicate with other CUs 160 (e.g., CUs 160 associated with an alternative IAB host) via an Xn-C interface (which may be an example of a portion of a backhaul link).

[0084] An IAB node 104 may refer to a RAN node that provides IAB functionality (e.g., access for UE 115, wireless self-backhaul capabilities, etc.). DU 165 may act as a distributed scheduling node toward child nodes associated with IAB node 104, and IAB-MT may act as a scheduled node toward a parent node associated with IAB node 104. That is, an IAB host may be referred to as a parent node that communicates with one or more child nodes (e.g., an IAB host may relay for UE transmissions through one or more other IAB nodes 104). Additionally or alternatively, depending on the relay chain or configuration of the AN, an IAB node 104 may also be referred to as a parent node or child node of other IAB nodes 104. Thus, the IAB-MT entity of the IAB node 104 may provide a Uu interface for the child IAB node 104 to receive signaling from the parent IAB node 104 , and a DU interface (eg, DU 165 ) may provide a Uu interface for the parent IAB node 104 to signal to the child IAB node 104 or the UE 115 .

[0085] For example, the IAB node 104 may be referred to as a parent node supporting child IAB node communications and as a child IAB node associated with the IAB host. The IAB host may include a CU 160 having a wired or wireless connection (e.g., backhaul communication link 120) to the core network 130, and may act as a parent node of the IAB node 104. For example, the DU 165 of the IAB host may relay transmissions to the UE 115 via the IAB node 104, and may directly signal the transmissions to the UE 115. The CU 160 of the IAB host may signal the establishment of a communication link to the IAB node 104 via the F1 interface, and the IAB node 104 may schedule transmissions (e.g., transmissions relayed from the IAB host to the UE 115) via the DU 165. That is, data may be relayed to and from the IAB node 104 via signaling on the NR Uu interface of the MT to the IAB node 104. Communications with the IAB node 104 may be scheduled by the DU 165 of the IAB host, and communications with the IAB node 104 may be scheduled by the DU 165 of the IAB node 104 .

[0086] Where the techniques described herein are applied in the context of a decomposed RAN architecture, one or more components of the decomposed RAN architecture may be configured to support the consent management procedures as described herein. For example, some operations described as being performed by a UE 115 or a network entity 105 (e.g., a base station 140) may additionally or alternatively be performed by one or more components of the decomposed RAN architecture (e.g., an IAB node 104, a DU 165, a CU 160, a RU 170, a RIC 175, a SMO 180).

[0087] UE 115 may include or may be referred to as a mobile device, a wireless device, a remote device, a handheld device, or a subscriber device, or some other suitable term, where "device" may also be referred to as other examples such as a unit, a station, a terminal, or a client. UE 115 may also include or may be referred to as a personal electronic device such as a cellular phone, a personal digital assistant (PDA), a tablet computer, a laptop computer, or a personal computer. In some examples, UE 115 may include or may be referred to as other examples such as a wireless local loop (WLL) station, an Internet of Things (IoT) device, an Internet of Everything (IoE) device, or a machine type communication (MTC) device, which may be implemented in various objects such as appliances or vehicles, meters, and other examples.

[0088] The UE 115 described herein may be capable of communicating with various types of devices, such as other UEs 115, which may sometimes act as relays, as well as network entities 105 and network equipment including macro eNBs or gNBs, small cell eNBs or gNBs, relay base stations, and other examples, such as Figure 1shown.

[0089] The UE 115 and the network entity 105 may wirelessly communicate with each other via one or more communication links 125 (e.g., access links) on one or more carriers. The term "carrier" may refer to a collection of RF spectrum resources having a defined physical layer structure for supporting the communication link 125. For example, a carrier for the communication link 125 may include a portion of an RF spectrum band (e.g., a bandwidth portion (BWP)) that operates according to one or more physical layer channels for a given radio access technology (e.g., LTE, LTE-A, LTE-A Pro, NR). Each physical layer channel may carry acquisition signaling (e.g., synchronization signals, system information), control signaling for coordinating carrier operations, user data, or other signaling. The wireless communication system 100 may support communications with the UE 115 using carrier aggregation or multi-carrier operation. Depending on the carrier aggregation configuration, the UE 115 may be configured to have multiple downlink component carriers and one or more uplink component carriers. Carrier aggregation may be used for both frequency division duplex (FDD) component carriers and time division duplex (TDD) component carriers. Communication between the network entity 105 and other devices may refer to communication between a device and any portion (e.g., entity, sub-entity) of the network entity 105. For example, the terms "send," "receive," or "communicate" when referring to the network entity 105 may refer to any portion of the network entity 105 (e.g., base station 140, CU 160, DU 165, RU 170) of the RAN communicating with another device (e.g., directly or via one or more other network entities 105).

[0090] In some examples, such as in a carrier aggregation configuration, a carrier may also have acquisition signaling or control signaling that coordinates the operation of other carriers. A carrier may be associated with a frequency channel (e.g., an Evolved Universal Mobile Telecommunications System Terrestrial Radio Access (E-UTRA) Absolute RF Channel Number (EARFCN)) and may be located according to a channel raster for discovery by UE 115. A carrier may operate in a standalone mode, in which case initial acquisition and connection may be performed by UE 115 via the carrier, or a carrier may operate in a non-standalone mode, in which case the connection is anchored using a different carrier (e.g., a different carrier of the same or different radio access technology).

[0091] The communication link 125 shown in the wireless communication system 100 may include downlink transmissions (e.g., forward link transmissions) from the network entity 105 to the UE 115, uplink transmissions (e.g., return link transmissions) from the UE 115 to the network entity 105, or both, among other transmission configurations. A carrier may carry either downlink communications or uplink communications (e.g., in FDD mode), or may be configured to carry both downlink communications and uplink communications (e.g., in TDD mode).

[0092] A carrier may be associated with a particular bandwidth of the RF spectrum, and in some examples, the carrier bandwidth may be referred to as a "system bandwidth" of the carrier or wireless communication system 100. For example, the carrier bandwidth may be one of a set of bandwidths (e.g., 1.4 megahertz (MHz), 3 MHz, 5 MHz, 10 MHz, 15 MHz, 20 MHz, 40 MHz, or 80 MHz) of a carrier of a particular radio access technology. A device (e.g., a network entity 105, a UE 115, or both) of the wireless communication system 100 may have a hardware configuration that supports communication on a particular carrier bandwidth or may be configurable to support communication on one of a set of carrier bandwidths. In some examples, the wireless communication system 100 may include a network entity 105 or a UE 115 that supports concurrent communication via carriers associated with multiple carrier bandwidths. In some examples, each served UE 115 may be configured to operate on a portion (e.g., a subband, a BWP) or all of a carrier bandwidth.

[0093] The signal waveform sent on the carrier may be composed of multiple subcarriers (e.g., using multi-carrier modulation (MCM) techniques, such as orthogonal frequency division multiplexing (OFDM) or discrete Fourier transform spread OFDM (DFT-S-OFDM)). In a system using MCM technology, a resource element may refer to a resource of one symbol period (e.g., the duration of one modulation symbol) and one subcarrier, in which case the symbol period and the subcarrier spacing may be inversely related. The amount of bits carried by each resource element may depend on the modulation scheme (e.g., the order of the modulation scheme, the coding rate of the modulation scheme, or both), so that the more resource elements a device receives and the higher the order of the modulation scheme, the higher the data rate for the device may be. Wireless communication resources may refer to a combination of RF spectrum resources, time resources, and spatial resources (e.g., spatial layers, beams), and the use of multiple spatial resources may increase the data rate or data integrity of communications with UE 115.

[0094] One or more numerologies for a carrier may be supported, where the numerologies may include subcarrier spacing (Δf) and cyclic prefixes. A carrier may be divided into one or more BWPs with the same or different numerologies. In some examples, a UE 115 may be configured with multiple BWPs. In some examples, a single BWP for a carrier may be active at a given time, and communications of a UE 115 may be constrained to one or more active BWPs.

[0095] The time interval for the network entity 105 or the UE 115 may be expressed as a multiple of a basic time unit, which may be, for example, a sampling period T s =1 / (Δf max ·N f ) seconds, where Δf max It can represent the maximum supported subcarrier spacing, and N f The maximum supported discrete Fourier transform (DFT) size may be indicated. Time intervals of communication resources may be organized according to radio frames, each having a specified duration (e.g., 10 milliseconds (ms)). Each radio frame may be identified by a system frame number (SFN) (e.g., ranging from 0 to 1023).

[0096] Each frame may include multiple consecutively numbered subframes or time slots, and each subframe or time slot may have the same duration. In some examples, the frame may be divided into subframes (e.g., in the time domain), and each subframe may be further divided into multiple time slots. Alternatively, each frame may include a variable number of time slots, and the number of time slots may depend on the subcarrier spacing. Each time slot may include multiple symbol periods (e.g., depending on the length of the cyclic prefix added before each symbol period). In some wireless communication systems 100, the time slot may also be divided into multiple mini-time slots containing one or more symbols. Excluding the cyclic prefix, each symbol period may include one or more (e.g., N f The duration of a symbol period may depend on the subcarrier spacing or the operating frequency band.

[0097] A subframe, a slot, a mini-slot, or a symbol may be the smallest scheduling unit (e.g., in the time domain) of the wireless communication system 100 and may be referred to as a transmit time interval (TTI). In some examples, the TTI duration (e.g., the number of symbol periods in a TTI) may be variable. Additionally or alternatively, the smallest scheduling unit of the wireless communication system 100 may be dynamically selected (e.g., in bursts of shortened TTIs (sTTIs)).

[0098] Physical channels may be multiplexed on a carrier according to various techniques. For example, physical control channels and physical data channels may be multiplexed on a downlink carrier using one or more of a time division multiplexing (TDM) technique, a frequency division multiplexing (FDM) technique, or a hybrid TDM-FDM technique. A control region (e.g., a control resource set (CORESET)) for a physical control channel may be defined by a set of symbol periods and may extend across a system bandwidth or a subset of a system bandwidth of a carrier. One or more control regions (e.g., CORESETs) may be configured for a group of UEs 115. For example, one or more of the UEs 115 may monitor or search the control region for control information according to one or more search space sets, and each search space set may include one or more control channel candidates in one or more aggregation levels arranged in a cascaded manner. The aggregation level of the control channel candidate may refer to the amount of control channel resources (e.g., control channel elements (CCEs)) associated with the coded information for a control information format having a given payload size. The search space sets may include a common search space set configured for transmitting control information to a plurality of UEs 115 , and a UE-specific search space set for transmitting control information to a specific UE 115 .

[0099] The network entity 105 may provide communication coverage via one or more cells (e.g., macro cells, small cells, hot spots, or other types of cells, or any combination thereof). The term "cell" may refer to a logical communication entity used to communicate with the network entity 105 (e.g., via a carrier), and may be associated with an identifier used to distinguish adjacent cells (e.g., a physical cell identifier (PCID), a virtual cell identifier (VCID), or other cell identifier). In some examples, a cell may also refer to a coverage area 110 or a portion of a coverage area 110 (e.g., a sector) within which the logical communication entity operates. Depending on various factors such as the capabilities of the network entity 105, such cells may range from smaller areas (e.g., structures, subsets of structures) to larger areas. For example, a cell may be or may include a building, a subset of a building, or an external space between or overlapping coverage areas 110, and the like.

[0100] A macro cell generally covers a relatively large geographic area (e.g., several kilometers in radius) and may allow unrestricted access to UEs 115 that have service subscriptions with a network provider that supports the macro cell. Small cells may be associated with lower power network entities 105 (e.g., lower power base stations 140) than macro cells, and small cells may operate in the same or different (e.g., licensed, unlicensed) frequency bands as macro cells. Small cells may provide unrestricted access to UEs 115 that have service subscriptions with a network provider, or may provide restricted access to UEs 115 associated with small cells (e.g., UEs 115 in a closed subscriber group (CSG), UEs 115 associated with users in a home or office). A network entity 105 may support one or more cells, and may also use one or more component carriers to support communications on one or more cells.

[0101] In some examples, a carrier may support multiple cells, and different cells may be configured according to different protocol types (e.g., MTC, narrowband IoT (NB-IoT), enhanced mobile broadband (eMBB)) that may provide access to different types of devices.

[0102] In some examples, the network entities 105 (e.g., base stations 140, RUs 170) may be mobile and thus provide communication coverage for mobile coverage areas 110. In some examples, different coverage areas 110 associated with different technologies may overlap, but the different coverage areas 110 may be supported by the same network entity 105. In some other examples, overlapping coverage areas 110 associated with different technologies may be supported by different network entities 105. The wireless communication system 100 may include, for example, a heterogeneous network in which different types of network entities 105 provide coverage for various coverage areas 110 using the same or different radio access technologies.

[0103] The wireless communication system 100 may support synchronous or asynchronous operation. For synchronous operation, the network entities 105 (e.g., base stations 140) may have similar frame timing, and transmissions from different network entities 105 may be approximately aligned in time. For asynchronous operation, the network entities 105 may have different frame timing, and in some examples, transmissions from different network entities 105 may not be aligned in time. The techniques described herein may be used for synchronous or asynchronous operation.

[0104] Some UEs 115, such as MTC or IoT devices, may be low-cost or low-complexity devices and may provide automated communication between machines (e.g., via machine-to-machine (M2M) communication). M2M communication or MTC may refer to data communication technology that allows devices to communicate with each other or with a network entity 105 (e.g., base station 140) without human intervention. In some examples, M2M communication or MTC may include communication from devices that integrate sensors or meters to measure or capture information and relay such information to a central server or application that utilizes the information or presents the information to a person interacting with the application. Some UEs 115 may be designed to collect information or implement automated behavior of machines or other devices. Examples of applications for MTC devices include: smart metering, inventory monitoring, water level monitoring, equipment monitoring, health care monitoring, wildlife monitoring, weather and geographic event monitoring, queue management and tracking, remote security sensing, physical access control, and transaction-based commercial charging.

[0105] Some UEs 115 may be configured to employ a reduced power consumption mode of operation, such as half-duplex communication (e.g., a mode that supports one-way communication via transmission or reception but does not transmit and receive concurrently). In some examples, half-duplex communication may be performed at a reduced peak rate. Other power saving techniques for UE 115 include entering a power-saving deep sleep mode when not engaged in active communications, operating with limited bandwidth (e.g., according to narrowband communications), or a combination of these techniques. For example, some UEs 115 may be configured to operate using a narrowband protocol type that is associated with a defined portion or range (e.g., a subcarrier or resource block (RB) set) within a carrier, within a guard band of a carrier, or outside a carrier.

[0106] The wireless communication system 100 may be configured to support ultra-reliable communication or low-latency communication or various combinations thereof. For example, the wireless communication system 100 may be configured to support ultra-reliable low-latency communication (URLLC). The UE 115 may be designed to support ultra-reliable or low-latency or critical functions. Ultra-reliable communication may include private communication or group communication, and may be supported by one or more services (such as push-to-talk, video, or data). Support for ultra-reliable, low-latency functions may include prioritization of services, and such services may be used for public safety applications or general commercial applications. The terms ultra-reliable, low-latency, and ultra-reliable low-latency are used interchangeably herein.

[0107] In some examples, a UE 115 may be able to communicate directly with other UEs 115 via a device-to-device (D2D) communication link 135 (e.g., according to a peer-to-peer (P2P), D2D, or sidelink protocol). In some examples, one or more UEs 115 in a group that are performing D2D communication may be within a coverage area 110 of a network entity 105 (e.g., a base station 140, a RU 170), which may support aspects of such D2D communication configured or scheduled by the network entity 105. In some examples, one or more UEs 115 in such a group may be outside of the coverage area 110 of the network entity 105, or may otherwise be unable or not configured to receive transmissions from the network entity 105. In some examples, a group of UEs 115 communicating via D2D communication may support a one-to-many (1:M) system, in which each UE 115 transmits to each of the other UEs 115 in the group. In some examples, the network entity 105 may facilitate scheduling of resources for D2D communication. In some other examples, D2D communications may occur between UEs 115 without involving network entity 105 .

[0108] In some systems, the D2D communication link 135 can be an example of a communication channel (such as a sidelink communication channel) between vehicles (e.g., UE 115). In some examples, the vehicles can communicate using vehicle-to-everything (V2X) communication, vehicle-to-vehicle (V2V) communication, or some combination of these items. The vehicles can signal information related to traffic conditions, signal scheduling, weather, safety, emergency situations, or any other information related to the V2X system. In some examples, vehicles in the V2X system can communicate with roadside infrastructure (such as roadside units), or communicate with the network via one or more network nodes (e.g., network entity 105, base station 140, RU 170) using vehicle-to-network (V2N) communication, or both.

[0109] The core network 130 may provide user authentication, access authorization, tracking, Internet Protocol (IP) connectivity, and other access, routing, or mobility functions. The core network 130 may be an evolved packet core (EPC) or a 5G core (5GC), which may include at least one control plane entity for managing access and mobility (e.g., a mobility management entity (MME), an access and mobility management function (AMF)) and at least one user plane entity for routing packets or interconnecting to an external network (e.g., a serving gateway (S-GW)), a packet data network (PDN) gateway (P-GW), or a user plane function (UPF)). The control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management for UE 115 served by a network entity 105 (e.g., a base station 140) associated with the core network 130. User IP packets may be delivered via the user plane entity, which may provide IP address allocation and other functions. The user plane entity may be connected to an IP service 150 for one or more network operators. IP services 150 may include access to the Internet, an intranet, an IP Multimedia Subsystem (IMS), or packet-switched streaming services.

[0110] The wireless communication system 100 may operate using one or more frequency bands that may be in the range of 300 megahertz (MHz) to 300 gigahertz (GHz). Typically, the region from 300 MHz to 3 GHz is referred to as the ultra-high frequency (UHF) region or decimeter band because the wavelength range is approximately one decimeter to one meter. UHF waves may be blocked or redirected by buildings and environmental features (which may be referred to as clusters), but these waves may be sufficient to penetrate structures so that macro cells provide service to UEs 115 located indoors. Transmission of UHF waves may be associated with smaller antennas and shorter ranges (e.g., less than 100 kilometers) than transmission using smaller frequencies and longer wavelengths of the high frequency (HF) or very high frequency (VHF) portions of the spectrum below 300 MHz.

[0111] The wireless communication system 100 may also operate in a super high frequency (SHF) region using a frequency band from 3 GHz to 30 GHz (also known as a centimeter band) or in an extremely high frequency (EHF) region of the spectrum (e.g., from 30 GHz to 300 GHz) (also known as a millimeter band). In some examples, the wireless communication system 100 may support millimeter wave (mmW) communications between UE 115 and network entity 105 (e.g., base station 140, RU 170), and the EHF antenna of the corresponding device may be smaller and closer than the UHF antenna. In some examples, this may facilitate the use of antenna arrays within the device. However, there may be even greater atmospheric attenuation and a shorter range for the propagation of EHF transmissions than SHF or UHF transmissions. The technology disclosed herein may be adopted across transmissions using one or more different frequency regions, and the use of frequency bands specified across these frequency regions may vary by country or regulatory agency.

[0112] The wireless communication system 100 may utilize both licensed RF spectrum bands and unlicensed RF spectrum bands. For example, the wireless communication system 100 may use licensed assisted access (LAA), LTE unlicensed (LTE-U) radio access technology, or NR technology in unlicensed bands such as the 5 GHz industrial, scientific, and medical (ISM) band. When operating in an unlicensed RF spectrum band, devices such as the network entity 105 and the UE 115 may employ carrier sensing for conflict detection and avoidance. In some examples, operations in an unlicensed band may be based on a carrier aggregation configuration (e.g., LAA) in conjunction with component carriers operating in a licensed band. Operations in an unlicensed spectrum may include other examples such as downlink transmissions, uplink transmissions, P2P transmissions, or D2D transmissions.

[0113] The network entity 105 (e.g., base station 140, RU 170) or UE 115 may be equipped with multiple antennas that can be used to employ technologies such as transmit diversity, receive diversity, multiple-input multiple-output (MIMO) communication, or beamforming. The antennas of the network entity 105 or UE 115 may be located in one or more antenna arrays or antenna panels that can support MIMO operations or transmit or receive beamforming. For example, one or more base station antennas or antenna arrays may be co-located at an antenna assembly, such as an antenna tower. In some examples, antennas or antenna arrays associated with the network entity 105 may be located at different geographical locations. The network entity 105 may have an antenna array having a set of rows and columns of antenna ports that the network entity 105 can use to support beamforming for communications with the UE 115. Similarly, the UE 115 may have one or more antenna arrays that can support various MIMO or beamforming operations. Additionally or alternatively, the antenna panel may support RF beamforming for signals transmitted via the antenna ports.

[0114] The network entity 105 or UE 115 may use MIMO communication to utilize multipath signal propagation and improve spectral efficiency by sending or receiving multiple signals via different spatial layers. Such technology may be referred to as spatial multiplexing. Multiple signals may be, for example, sent by a transmitting device via different antennas or different combinations of antennas. Similarly, multiple signals may be received by a receiving device via different antennas or different combinations of antennas. Each of the multiple signals may be referred to as a separate spatial stream and may carry information associated with the same data stream (e.g., the same codeword) or different data streams (e.g., different codewords). Different spatial layers may be associated with different antenna ports for channel measurement and reporting. MIMO technology includes single-user MIMO (SU-MIMO), in which multiple spatial layers are sent to the same receiving device; and multi-user MIMO (MU-MIMO), in which multiple spatial layers are sent to multiple devices.

[0115] Beamforming (which may also be referred to as spatial filtering, directional transmission, or directional reception) is a signal processing technique that may be used at a transmitting device or a receiving device (e.g., a network entity 105, a UE 115) to shape or steer an antenna beam (e.g., a transmit beam, a receive beam) along a spatial path between the transmitting device and the receiving device. Beamforming may be achieved by combining signals conveyed via antenna elements of an antenna array so that some signals propagating at a particular orientation relative to the antenna array experience constructive interference, while other signals experience destructive interference. Adjustments to signals conveyed via antenna elements may include the transmitting device or the receiving device applying an amplitude offset, a phase offset, or both to signals carried via antenna elements associated with the device. Adjustments associated with each of the antenna elements may be defined by a set of beamforming weights associated with a particular orientation (e.g., relative to the antenna array of the transmitting device or the receiving device or relative to some other orientation).

[0116] The network entity 105 or UE 115 may use beam scanning techniques as part of a beamforming operation. For example, the network entity 105 (e.g., base station 140, RU 170) may use multiple antennas or antenna arrays (e.g., antenna panels) to perform beamforming operations for directional communication with UE 115. Some signals (e.g., synchronization signals, reference signals, beam selection signals, or other control signals) may be sent multiple times by the network entity 105 along different directions. For example, the network entity 105 may send signals according to different sets of beamforming weights associated with different transmission directions. Transmissions along different beam directions may be used to identify (e.g., by a transmitting device (such as network entity 105), or by a receiving device (such as UE 115)) beam directions for later transmission or reception by the network entity 105.

[0117] Some signals, such as data signals associated with a particular receiving device, may be sent by a transmitting device (e.g., transmitting network entity 105, transmitting UE 115) along a single beam direction (e.g., a direction associated with a receiving device (such as receiving network entity 105 or receiving UE 115)). In some examples, a beam direction associated with transmission along a single beam direction may be determined based on signals sent along one or more beam directions. For example, UE 115 may receive one or more of the signals sent by network entity 105 along different directions, and may report to network entity 105 an indication of the signal received by UE 115 with the highest signal quality or other acceptable signal quality.

[0118] In some examples, transmission by a device (e.g., by network entity 105 or UE 115) may be performed using multiple beam directions, and the device may use a combination of digital precoding or beamforming to generate a combined beam for transmission (e.g., from network entity 105 to UE 115). UE 115 may report feedback indicating precoding weights for one or more beam directions, and the feedback may correspond to a configured set of beams across a system bandwidth or one or more subbands. Network entity 105 may send a reference signal (e.g., a cell-specific reference signal (CRS), a channel state information reference signal (CSI-RS)), which may be precoded or non-precoded. UE 115 may provide feedback for beam selection, which may be a precoding matrix indicator (PMI) or codebook-based feedback (e.g., a multi-panel codebook, a linear combination codebook, a port selection codebook). Although these techniques are described with reference to signals sent along one or more directions by a network entity 105 (e.g., base station 140, RU 170), UE 115 may use similar techniques to send signals multiple times along different directions (e.g., to identify a beam direction for subsequent transmission or reception by UE 115), or to send signals along a single direction (e.g., to send data to a receiving device).

[0119] A receiving device (e.g., UE 115) may perform receiving operations according to multiple receiving configurations (e.g., directional listening) when receiving various signals (such as synchronization signals, reference signals, beam selection signals, or other control signals) from a receiving device (e.g., network entity 105). For example, the receiving device may perform reception according to multiple receiving directions by: receiving via different antenna subarrays, processing received signals according to different antenna subarrays, receiving according to different receiving beamforming weight sets (e.g., different directional listening weight sets) applied to signals received at multiple antenna elements of an antenna array, or processing received signals according to different receiving beamforming weight sets applied to signals received at multiple antenna elements of an antenna array, any of which may be referred to as "listening" according to different receiving configurations or receiving directions. In some examples, the receiving device may use a single receiving configuration to receive along a single beam direction (e.g., when receiving a data signal). A single receive configuration may be aligned along a beam direction determined based on listening according to different receive configuration directions (e.g., a beam direction determined to have the highest signal strength, highest signal-to-noise ratio (SNR), or other acceptable signal quality based on listening according to multiple beam directions).

[0120] The wireless communication system 100 may be a packet-based network that operates according to a layered protocol stack. In the user plane, the communication at the bearer or PDCP layer may be IP-based. The RLC layer may perform packet segmentation and reassembly to communicate on a logical channel. The MAC layer may perform priority processing and multiplexing of logical channels to transport channels. The MAC layer may also use error detection technology, error correction technology, or both to support retransmission at the MAC layer to improve link efficiency. In the control plane, the RRC protocol layer may provide the establishment, configuration, and maintenance of an RRC connection that supports a radio bearer for user plane data between a UE 115 and a network entity 105 or a core network 130. At the PHY layer, a transport channel may be mapped to a physical channel.

[0121] UE 115 and network entity 105 may support retransmission of data to increase the likelihood that the data is successfully received. Hybrid automatic repeat request (HARQ) feedback is a technique for increasing the likelihood of correctly receiving data through a communication link (e.g., communication link 125, D2D communication link 135). HARQ may include a combination of error detection (e.g., using a cyclic redundancy check (CRC)), forward error correction (FEC), and retransmission (e.g., automatic repeat request (ARQ)). HARQ may improve throughput at the MAC layer under poor radio conditions (e.g., low signal-to-noise ratio conditions). In some examples, a device may support simultaneous slot HARQ feedback, wherein the device may provide HARQ feedback in a specific time slot for data received in a previous symbol in the time slot. In some other examples, the device may provide HARQ feedback in a subsequent time slot or according to some other time interval.

[0122] The network entity 105 (e.g., a first network entity, which may include the (E)UDM in this example) may identify a consent profile for a user ID, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID on at least a per-user basis. The network entity 105 may receive a request from a second network entity (e.g., a CMF and / or DGS in this example), the request indicating the user ID and requesting an access level for a data provider corresponding to at least one of the one or more consent types. The network entity 105 may send a response indicating the access level to the second network entity based at least in part on the request and the one or more consent parameters of at least one consent type.

[0123] The network entity 105 (e.g., a first network entity, which may include a DGS in this example) may receive a consent profile registration request identifying a user ID from the UE 115. The network entity 105 may receive a consent profile from the UE 115 based at least in part on the consent profile registration request, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis. The network entity 105 may send the consent profile to a second network entity (e.g., (E)UDM in this example).

[0124] UE 115 (e.g., a DGC implemented at UE 115 in this example) may send a consent profile registration request to network entity 105 (e.g., DGS), the consent profile registration request identifying the user ID. UE 115 may send a consent profile to network entity 105 based at least in part on the consent profile registration request, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID at least on a per-user basis.

[0125] The network entity 105 (e.g., a first network entity, which may include a CMF in this example) may receive a first request from a data provider requesting access to data associated with a user ID, the data provider corresponding to at least one of the one or more consent types for the user ID. The network entity 105 may send a second request to a second network entity (e.g., a DGS and / or (E)UDM in this example), the second request indicating the user ID and requesting an access level for the data provider. The network entity 105 receives a first response from the second network entity indicating the access level. The network entity 105 may send a second response to the data provider indicating the access level.

[0126] Figure 2 An example of a wireless communication system 200 that supports a consent management procedure according to one or more aspects of the present disclosure is illustrated. The wireless communication system 200 may implement aspects of the wireless communication system 100.

[0127] The wireless communication system 200 may include a device 205, a RU 215, a DU 220 of one or more DUs 225, a CU-UP 235 of a CU-230, and a CU-CP 240, and a core network 245, which may be examples of corresponding devices described herein. For example, the device 205 may be an example of a UE or any other device associated with a user or an end user. In some aspects, the RU 215, the DU 220 of one or more DUs 225, and / or the CU-UP-235 and CU-CP 240 of the CU 230 may be components or functions of the network entity 105 discussed herein or otherwise support various aspects of the network entity. In some examples, the core network 245 may include a DGS 250, a UDM 255, an EUDM 260, a UPF 265, an AMF 270, a CMF 275, a UDR 280, and an EUDR 285, which may be examples of corresponding devices described herein. For example, DGS 250, UDM 255, EUDM 260, UPF 265, AMF 270, CMF 275, UDR 280, and EUDR 285 may be examples of one or more servers, functions, devices, or otherwise supported features within a core network. Although shown separately, it should be understood that various aspects, features, or other functionality of EUDM 260 may be implemented or otherwise performed at or by UDM 255. In some examples, UDR 280 may be accessed via UDM 255. In some examples, EUDR 285 may be accessed via UDM 255 or EUDM 260, or some combination of the two.

[0128] In general, the device 205 may communicate with a network entity, such as a RU 215 associated with the network entity, via a Uu interface (e.g., a cellular interface). The RU 215 may communicate aspects of wireless communications to one or more DUs 225 via an open fronthaul interface (OFI), which may communicate aspects of communications to the CU 230 via a midhaul interface (e.g., an F1 interface). The CU 230 may communicate with the core network 245 via a backhaul interface (e.g., an N2 interface, an N3 interface, etc.).

[0129] Advanced wireless networks (such as wireless communication system 200) can create new services and capabilities within the connected intelligent edge. The connected intelligent edge may typically include an integrated platform that distributes intelligence across clouds, networks, and different devices. New applications and technologies can converge into cloud-connected devices (such as UEs, IoT devices, etc.). Similar convergence can be supported at the edge and infrastructure (e.g., networks, RSUs, etc.). Such edge features may include connectivity (e.g., transmitting data across networks), computing (e.g., hosting network functions across services, etc.), analysis, and security. Using data analysis can provide support for new / enhanced mobile experiences. Such edge security features may include providing data traceability (e.g., identity, proof) and governance (e.g., security, privacy, consent).

[0130] Therefore, aspects of such advanced wireless networks typically utilize consent from users to support data provenance and governance. Such user consent can typically apply to a variety of scenarios, such as a single user using a single device, a single user using multiple devices, a single device being used by multiple users, and / or multiple users across multiple devices.

[0131] There are different laws, regulations, and principles around privacy / user consent in different countries and different states / provinces within a country. For example, consent can use an affirmative action by a data subject (e.g., a user or end user that can be associated with one or more user IDs). The consent can be associated with the end user (e.g., on a per-user basis, rather than in the case of a specific device or on a per-device basis). The consent can be applied for a specific purpose and can be withdrawn at any time. In addition, the current use of data (e.g., user data and / or data associated with a user) can be queried by the data subject (e.g., dynamically queried or otherwise queried via an end user).

[0132] However, legacy wireless networks are generally unable to support such new services and use cases. For example, such legacy networks may not provide granular user consent parameters (e.g., duration of consent, coverage area, etc.). In addition, such legacy networks may not provide a unified set of procedures for addressing user consent for all services and use cases handled by or otherwise involving the wireless network. Conventional networks may also not support differentiation between end users and devices to obtain consent for regulatory consistency.

[0133] Typically, user consent defines a specific and clear opt-in by a user to indicate permission for the processing and / or collection of the user's personal data for a specific purpose. User consent typically includes a data subject (e.g., a subscriber, such as an end user or an entity authorized by the end user), a data controller (e.g., a data operator / provider that collects and stores personal data and provides personal data to a data processor / consumer). The data processor / consumer can typically be part of a network operator or a third party that receives personal data from a data controller and returns the result. The user provides user consent for the service to the data controller of the service.

[0134] User consent is typically obtained from an end user (e.g., an end user and / or an entity authorized to provide consent on behalf of the end user). Such consent is typically associated with subscription information. The subscription information (e.g., subscription ID) can be an example of a globally unique 5G subscription permanent ID (SUPI) within a wireless network and / or an example of a universal public subscription ID (GPSI) outside of a wireless network. For example, when outside of a wireless network, the GPSI can be used to resolve a wireless network subscription (e.g., SUPI).

[0135] In other different systems, the UDM (such as UDM 255) supports retrieving user consent parameters from the UDR 280 and notifying the UDR 280 of changes in user consent parameters related to user consent. That is, the user consent parameters are usually stored in the UDM / Uniform Data Repository (UDR) as subscription data, which is bound to the SUPI / GPSI, bound to the specific purpose of data processing, and includes whether the user consent is granted. Although the UDM does not usually provide a revocation service, the user consent parameters are valid after the consent is given and until it is revoked.

[0136] Access to user data typically involves a user consent check. For example, any network function (NF) considered as an enforcement point for user consent (which may be an example of a data processor / consumer) may support retrieving user consent parameters from the UDM, may not accept any service or request for data processing unless user consent is granted, etc. User consent is typically associated with a specific subscription, which may not be the end user of the device. For example, personal identification information of a user on a per-use case basis may include a subscription ID and a user ID.

[0137] Thus, the described technology provides a consent platform implemented within the wireless communication system 200 that improves the consent management of user data, at least to some extent. For example, various aspects of the technology described herein provide a consent platform that implements various network functions (e.g., core network 245 functions implemented at least to some extent via network entities). The consent platform may include a DGS 250 that provides an interface to a user or end user to manage user consent and query the network about active data processing and other data governance procedures. The consent platform may include a UDR 280 that hosts a consent profile within the core network 245 (e.g., on a per-subscription basis and / or on a per-user basis). The UDM 255 may access the consent profile stored in the UDR 280 within the network. The consent platform may include an EUDR 285 that hosts a consent profile within the core network (e.g., on a per-user basis, on a per-subscription basis and / or on a per-user per-device basis). The UDM 255 and / or the EUDM 260 may access the consent profile stored in the EUDR 285. In some examples, EUDM 260 may be implemented as part of UDM 255 or separate from UDM 255 (as shown). The consent platform may include a CMF 275 that manages user consent within the network in real time (eg, dynamically).

[0138] Aspects of the consent platform support user consent that requires an affirmative action by the data subject, consent can be associated with an end user relative to a device (e.g., on a per-user basis), consent can be required for a specific purpose, consent can be withdrawn at any time, and current use of the data can be queried by the data subject. Broadly speaking, consent management can refer to the management of a user's consent profile (e.g., including registration and updates, such as revocation of consent). Consent enforcement can include implementation of validation of user consent defined in a consent profile in order to perform data collection and processing (e.g., including dynamic consent updates and end-user switching). End-user authentication can include authentication of the end user of a device (e.g., including onboarding of an end user, end-user switching, continuous authentication, etc.). Data processing queries can typically include determining which services are currently processing or collecting data for a user (e.g., associated with a subscription).

[0139] In some aspects, the consent platform may support the (E)UDM (e.g., in this example, the first network entity) to identify, store, or otherwise manage aspects of a consent profile for a user ID (such as an identifier associated with a user / end-user). A consent profile may generally include consent parameters associated with the user ID. For example, a consent profile may include one or more consent types for the user ID, where each consent type broadly configures consent parameters for the user ID. A user ID may generally be associated with a subscription ID (e.g., SUPI and / or GPSI) and an identifier of a consent profile (e.g., a consent profile ID).

[0140] In some examples, this may include a consent profile provisioned or otherwise stored in the UDR 280 and / or EUDR 285. For example, a user ID may be used for a subscriber (e.g., as identified by a subscriber ID, corresponding to a SUPI or GPSI) and for an end user (e.g., as identified by a consent profile ID using a consent profile). In other examples, a subscription ID for a user ID may be provisioned or otherwise stored in the UDR 280, where a consent profile for the user ID is provisioned or otherwise stored in the EUDR 285. As discussed, in some examples, the UDM 255 and / or EUDM 260 may access aspects of a consent profile stored in the UDR 280 and / or EUDR 285 within the network.

[0141] The (E)UDM may receive, obtain, or otherwise identify a request indicating a user identifier from a second network entity (e.g., in this example, DGS250 and / or CMF 275). In some aspects, the request may carry or otherwise convey a request for an access level to a data provider (e.g., a data controller / operator) for at least one consent type. Accordingly, the (E)UDM may send, provide, or otherwise output a response indicating the access level to the second network entity. For example, the (E)UDM may use the consent type of the consent profile to identify or otherwise determine the access level (if any) of the data provider to the user data. Additionally or alternatively, the (E)UDM may convey only some or all of the consent parameters of the consent type to the second network entity. The response may indicate the access level and / or consent parameters in response to the request.

[0142] In some aspects, the consent platform may support DGS250 (e.g., in this example, the first network entity) receiving, obtaining, or otherwise identifying a consent profile registration request. DGS250 receives or otherwise obtains a request from a user (such as from device 205 or other device of the user, such as a UE). In some examples, the request may carry or otherwise convey an indication of a user ID. In this example, DGS250 may receive or otherwise obtain a consent profile (e.g., from device 205) in response to the request. Similarly, the consent profile may include a consent type for the user ID that configures consent parameters for the user ID on a per-user basis, per-device basis, and / or per-subscription basis. DGS250 may send or otherwise provide the consent profile to (E)UDM (e.g., in this example, the second network entity). That is, DGS250 may send or otherwise provide a consent profile for the user ID to be stored in UDM 255 and / or EUDM 260. Therefore, DGS 250 may collaborate with the (E)UDM to provision a consent profile for a user ID.

[0143] In some aspects, the consent platform may support a user's device (e.g., one of the user's UEs, such as device 205 or other device) to implement, support, or otherwise include a DGC 210 (e.g., operating at an application layer within a wireless network) that supports consent management functionality for the user. For example, device 205 may send or otherwise provide a consent profile registration request to DGS 250 (e.g., a network entity in this example). Device 205 may send or otherwise provide a consent profile to DGS 250 in response to the request (e.g., to provision a consent profile for a user ID stored in the (E)UDM).

[0144] In another example, the consent platform may support the CMF 275 (e.g., in this example, the first network entity) to receive or otherwise obtain a first request requesting access to user data. The first request may be obtained from a data provider (e.g., a data provider within the network or separate from the network). The data provider (e.g., alone or in combination with one or more data processors / consumers of the user data) may correspond to or otherwise be associated with a consent type for the user ID. That is, in some examples, each consent type may correspond to a specific data processor / consumer, such as to provide granular consent provisioning and enforcement for each service / processor of the user data. The CMF 275 may send or otherwise provide a second request indicating the user ID and requesting an access level for the user identifier (e.g., the access level of the data provider or data processor / consumer associated with the first request). The second request may be provided to the DGS 250 and / or the (E) UDM (e.g., in this example, the second network entity). The request may carry or otherwise convey an indication of the user ID, a consent profile (e.g., a consent profile ID), a subscription ID, etc.

[0145] The CMF 275 may receive or otherwise obtain a first response indicating the requested access level from the second network entity, and send or otherwise provide a second response indicating the access level to the data provider. That is, the second response may indicate a consent parameter of the consent type, indicate the access granted or revoked, indicate the coverage area / period of the consent type, etc.

[0146] More specific examples of features of the consent platform functionality are provided in the following discussion.

[0147] Figure 3 An example of a consent profile 300 supporting a consent management procedure according to one or more aspects of the present disclosure is illustrated. The consent profile 300 may implement aspects of the wireless communication system 100 and / or 200. Aspects of the consent profile 300 may be implemented at or by a UE and / or a network entity, which may be examples of corresponding devices described herein.

[0148] For example, aspects of the technology described herein provide for provisioning a consent profile for user ID 305 at the (E)UDM. Provisioning may include the UE (e.g., a DGC implemented at or by the UE, such as at an application layer), the DGS, and / or the (E)UDM communicating various information configuring the consent profile for user ID 305. Broadly speaking, provisioning may include the UE sending or otherwise conveying a consent profile registration request. The request may be sent or otherwise provided from the DGC of / at the UE to a DGS (e.g., a network entity) within the core network. The DGS may receive or otherwise obtain the request from the UE (or other device of the end user), and in response, receive or otherwise obtain the consent profile for user ID 305. The DGS may send or otherwise provide the consent profile to the (E)UDM, which may store the consent profile for user ID 305.

[0149] As discussed above, the user ID 305 may generally include or be otherwise associated with a subscription ID (eg, SUPI and / or GPSI) and a consent profile ID, where the consent profile ID is an identifier of a consent profile.

[0150] Typically, a consent profile corresponding to user ID 305 may typically include one or more consent types, where consent type 310, consent type 315, consent type 320, consent type 325, and consent type 330 are shown only by way of example. Broadly speaking, each consent type for user ID 305 may include consent parameters for user ID 305 on a per-user basis and / or on a per-device basis. Each consent type may be configured separately for each subscription / use case (e.g., using different parameters). Each consent type may be enabled, activated, revoked, deactivated, etc., individually or in combination. This may support granular consent provisioning / management / implementation within a consent platform that supports a connected intelligent edge.

[0151] Consent types 310 broadly illustrate features where each consent type is associated with different consent parameters. That is, some or all of the consent types in the consent profile may include different parameters, have parameters reconfigured to generate weighting / triggering parameters, etc. Thus, for different consent types, the end user may have different granularity with corresponding consent parameters.

[0152] Consent type 315 illustrates consent type K, where K may correspond to an identifier of the consent type. Consent type K may generally include multiple consent parameters. A consent parameter of consent type K may include a service data / processor ID, which may generally be an identifier of an allowed and / or prohibited data processor / consumer (e.g., based on a corresponding subscription). Another consent parameter of consent type K may include an action regarding user consent revocation, which may generally indicate the action to be taken by the data processor / consumer when the end user revokes consent (e.g., erase, modify, stop, etc.). Another consent parameter of consent type K may include a validity area, which may generally define the area to which the consent profile applies (e.g., within a public land mobile network (PLMN), within a radio access technology (RAT), within a radio network controller (RNC), within a target area, etc.).

[0153] Another consent parameter for consent type K may include a validity time, which may generally define a timeline (e.g., time such as periodicity, day / month, etc., start time, end time, etc.) over which the user consent applies. Another consent parameter for consent type K may include a valid slice, which may generally define the slice / service to which the consent type applies. Another consent parameter for consent type K may include a carrier frequency, which may generally define the carrier frequency to which the consent type applies. Another consent parameter for consent type K may include a UE state, such as whether the consent profile applies to a specific UE state, such as when the UE is operating in an active or connected state, in an inactive or idle state, etc. The consent type 315 generally illustrates an example in which each consent parameter is listed equally within the consent type stored at the (E)UDM.

[0154] Consent type 320 illustrates consent type K+1, where K corresponds to an identifier of consent type 320. Consent type 320 includes similar consent parameters discussed with reference to consent type 315. However, consent type 320 may include a purpose for the data request consent parameter, which typically defines consent type 320 based on a threshold related to the purpose of the data request. That is, the data processor / consumer may use the user data for different purposes (e.g., tracking, advertising preference updates, etc.). The request to access the user data may include a purpose indication, which may match the purpose of the data request consent parameter. If the purpose indication matches the purpose of the data request consent parameter, this may act as an enabling threshold, where the remaining consent parameters of consent type 320 are applied.

[0155] Consent type 325 illustrates consent type K+2, where K corresponds to an identifier of consent type 325. Consent type 325 includes similar consent parameters discussed with reference to consent type 315 and consent type 320. However, consent type 325 may be configured such that the service / data process ID consent parameter and the action on user consent revocation consent parameter are given equal weight. However, the action on user consent revocation consent parameter may be configured to act as a threshold gate for applying a validity zone consent parameter, a validity time consent parameter, etc.

[0156] Consent type 330 illustrates consent type K+3, where K corresponds to an identifier of consent type 330. Consent type 330 includes similar parameters discussed with reference to consent type 315, consent type 320, and consent type 325. However, consent type 330 may be configured such that the purpose of the data request serves as a threshold gate for the service / data process ID consent parameter and the action on the user consent revocation consent parameter. Additionally, the action on the user consent revocation consent parameter serves as a threshold gate for the validity zone and other consent parameters.

[0157] Thus, the consent profile for a user ID provisioned at the (E)UDM may include one or more consent types, wherein each consent type configures or otherwise identifies consent parameters. The consent parameters may be configured differently within the consent type to enable granular user consent provisioning within or otherwise involving the wireless communication network.

[0158] Figure 4A and Figure 4B An example of a provisioning configuration 400 that supports consent management procedures according to one or more aspects of the present disclosure is illustrated. The provisioning configuration 400 may implement various aspects of the wireless communication system 100 and / or 200 and / or various aspects of the consent profile 300. Various aspects of the provisioning configuration 400 may include a UDR / UDM 405 and an EUDR / EUDM 410, which may be examples of corresponding devices described herein. For example, the UDR / UDM 405 and / or the EUDR / EUDM 410 may implement various aspects of a consent platform within a wireless communication system. In some aspects, the UDR / UDM 405 may refer to various aspects of a consent profile that is stored or otherwise provisioned within a UDR and accessed via a UDM within a network on a per-subscription basis. In some aspects, the EUDR / EUDM 410 may refer to various aspects of a consent profile that is stored within a EUDR and accessed via an EUDM within a network (or, in some examples, a UDR) on a cross-subscription basis. Figure 4A Provisioning configuration 400-a illustrates an example in which aspects of a consent profile for a user ID are provisioned or otherwise stored on / accessed by a UDR / UDM 405, wherein Figure 4BThe provisioning configuration 400 - b illustrates an example in which aspects of a consent profile are provisioned or otherwise stored on / accessed by the EUDR / EUDM 410 .

[0159] For example, various aspects of the technology described herein provide for provisioning a consent profile for a user ID at an (E)UDM (e.g., stored at a UDR / EUDR and accessed by the (E)UDM). The provisioning may include the UE (e.g., a DGC implemented at or by the UE, such as at an application layer), the DGS, and / or the (E)UDM communicating various information configuring the consent profile for the user ID. Broadly speaking, the provisioning may include the UE sending or otherwise conveying a consent profile registration request. The request may be sent or otherwise provided from the DGC of / at the UE to a DGS (e.g., a network entity) within the core network. The DGS may receive or otherwise obtain a request from the UE (or other device of the end user), and in response, receive or otherwise obtain a consent profile for the user ID. The DGS may send or otherwise provide a consent profile to the (E)UDM, which may store the user's consent profile at the UDR / EUDR, and access the consent profile through the (E)UDM.

[0160] A user ID may typically include or be otherwise associated with a subscription ID (e.g., SUPI and / or GPSI) and a consent profile ID, where the consent profile ID is an identifier of the consent profile. A consent profile corresponding to a user ID may typically include a consent type, where each consent type for the user ID may include consent parameters for the user ID on a per-user basis and / or per-device basis. Each consent type may be configured separately for each subscription / use case (e.g., using different parameters). Each consent type may be enabled, activated, revoked, deactivated, etc., individually or in combination. This may support granular consent provisioning / management / implementation within a consent platform that supports a connected intelligent edge.

[0161] Figure 4AThe provisioning configuration 400-a generally illustrates an example in which a consent profile for a user ID and a subscription ID are stored or otherwise provisioned at a UDR / UDM 405. That is, the techniques and features discussed herein with respect to a separate EUDM may be adopted, supported, or otherwise implemented at the UDM. Specifically, the DGS may send or otherwise provide a consent profile for a user ID to the UDM. The UDM may provision, store, or otherwise save a consent profile associated with a subscription ID (e.g., an identifier of a service to which the user has subscribed and agreed, a use case, a data processor / consumer, etc.). For example, the UDR may store a subscriber consent profile for a subscription ID, which may generally include information about subscription information, subscriber consent profiles, and the like. Under a subscription ID, the UDR may store one or more consent profiles, where consent profiles 1-n are shown by way of example only. The UDM may access a consent profile stored at a UDR within the network.

[0162] Thus, provisioning configuration 400-a illustrates an example in which a subscriber repository (e.g., UDR / UDM 405) maintains a consent profile on a per-subscription basis. A consent profile may be specific to a subscriber (e.g., based at least in part on a SUPI and / or GPSI), which may correspond to an end user (e.g., as identified using a consent profile ID).

[0163] Figure 4BThe provisioning configuration 400-b generally illustrates a different example in which the subscription ID of the user ID is stored or otherwise provided at the UDR / UDMM 405, but the consent profile of the user ID associated with the subscription ID is stored or otherwise provided at the EUDR / EUDM 410. Specifically, the DGS may send or otherwise provide the subscription ID of the user ID to the UDM. The UDM may supply, store or otherwise save the subscription ID of the user ID at the UDR. The DGS may also send or otherwise provide the consent profile of the user ID associated with the subscription ID stored at the UDR / UDM 405 to the EUDM. The UDR / UDM405 may store the subscriber consent profile of the subscription ID, which may generally include information about subscription information, subscriber consent profiles, etc., and the EUDM 410 may supply, store or otherwise save the consent profile associated with the subscription ID. For example, for a subscription ID, the EUDR / EUDM 410 may store the subscriber consent profile of the user ID associated with the subscription ID stored at the UDR / UDM 405. The EUDR may store one or more consent profiles for a user ID associated with a subscription ID, where consent profiles 1-n are shown by way of example only. (E) The UDM may access consent profiles stored at the EUDR within the network.

[0164] Thus, provisioning configuration 400-b illustrates an example in which a subscriber repository (e.g., UDR / UDM 405) maintains and accesses a subscriber's consent profile (e.g., as identified using SUPI and / or GPSI). An end-user repository (e.g., EUDR / EUDM 410) maintains and accesses an end-user's consent profile (e.g., as identified using a consent profile ID across multiple subscriptions). Likewise, a reference to a user ID may include both a subscription ID and a consent profile ID.

[0165] Figure 5An example of a method 500 for supporting consent management procedures according to one or more aspects of the present disclosure is illustrated. The method 500 may implement aspects of the wireless communication system 100 and / or 200, aspects of the consent profile 300, and / or aspects of the provisioning configuration 400. Aspects of the method 500 may be implemented by or at a DGC 505, a DGS 510, and a (E)UDM 515, which may be examples of corresponding devices described herein. For example, the DGC 505 may refer to an application, feature, or other functionality that operates at a device of an end user (e.g., a UE or some other device) or is otherwise associated with an end user (e.g., operating at an application layer of a UE). The DGC 505 may be a component within a consent platform that includes the DGS 510 and / or the (E)UDM 515 operating within a core network. Thus, references to network entities may include the DGS 510 and / or the (E)UDM 515.

[0166] As discussed above, aspects of the technology described herein provide for consent profile provisioning within a consent platform. Method 500 illustrates a non-limiting example of an overview of consent management by an end-user within a consent platform.

[0167] For example, at 520, the DGC 505 may generally obtain, identify, or otherwise acquire a consent profile for an end user. For example, an end user may activate one or more applications, programs, or other features at an end user device (such as the DGC 505). In some examples, this may include the end user initiating a consent registration at the DGC 505. The DGC 505 may support or otherwise facilitate the end user to enter various information related to the consent profile. For example, a consent profile may include one or more consent types, where each or some consent types are associated with a particular subscription, associated with different user consent levels for different data access features of a subscription, and the like. Different consent types may also be configured in different ways, such as in Figure 3 exemplified in .

[0168] In some aspects, a user may use the DGC 505 to configure user information for a consent profile, subscription information for a consent profile, consent information for a consent profile, and the like. For example, the user information may include personal information about the end user, such as personal identification information (e.g., user biometrics, login name, password, etc.). Typically, the personal identification information may be used to confirm the identity of the end user (e.g., during initial consent profile provisioning, during a dynamic consent implementation procedure, during a consent profile update procedure initiated by the end user and / or subscriber, etc.). Subscription information may typically identify the data processor / consumer to which the end user has subscribed. For example, subscription information may typically include a subscriber ID (or other information that may be used to identify and distinguish the subscribed service), an indication of the nature of the subscribed service (e.g., how the user data will be used, what the end user receives in exchange for access to the user data, etc.), and the like. The consent profile information may include an indication of the level of access that the end user agrees to or otherwise grants the subscriber when accessing the end user data, which end user data the subscriber is allowed to access, and the like. In some examples, the consent information may include additional information, such as defining the actions to be taken by the subscriber (e.g., data processor / consumer) when the end user revokes consent, the regions / times / slices for which the user's consent is valid, etc.

[0169] The DGC 505 may typically use user information, subscription information, and / or consent information to generate consent parameters of the consent type of the consent profile to be supplied in the consent platform. Therefore, at 525, the DGC 505 and the DGS 510 may exchange one or more messages during the end-user registration and authentication process. In some examples, the end-user registration and authentication process may be a fast identity online (FIDO) online authentication procedure using public key cryptography. The FIDO procedure typically relies on the end-user authentication at the user's device. For example, the FIDO procedure may be based on the registration credentials of the end-user to prove that the current end-user is the same as the end-user when the FIDO credentials are used to register for the service. However, it should be understood that other end-user identification and authentication procedures may also be used to register and authenticate end-users in the consent platform. In some examples, the consent profile ID may be or be based on a FIDO KeyID, an advertising ID (such as Google Advertising ID (GAID), Android Advertising ID (AAID), etc.) or some other ID derived during the end-user registration and authentication procedure.

[0170] In some examples, a consent profile (or one or more consent types of a consent profile) may be associated with an end user's device (e.g., based on a device ID). Therefore, in some examples, a consent profile (or consent type) may include consent parameters associated with an end user's device. However, it should be understood that the consent platform discussed herein is not limited to a single end user on a single device. On the contrary, the techniques described herein may be equally applicable to end users using multiple devices, where the devices share consent types and / or different consent types of consent profiles may be used. In addition, the techniques described herein also support end users switching consent profiles to different devices. For example, a single end user may create and register multiple consent profiles with different FIDO credentials. In this context, this may include DGC.

[0171] At 530, the DGC 505 may generally supply the consent profile to the DGS 510. For example, this may include the DGC 505 sending or otherwise providing (and the DGS 510 receiving or otherwise obtaining) a consent profile registration request. The request may carry or otherwise convey an indication of the user ID (e.g., the consent profile ID and / or subscription ID). The request may carry or otherwise convey an indication of the consent profile. For example, the request may identify some or all of the consent parameters to be included in the consent profile. The consent type may generally identify or otherwise configure the consent parameters of the consent profile for the user ID.

[0172] At 535, the DGS 510 may generally provision the consent profile to the (E)UDM 515. For example, this may include the DGS 510 sending or otherwise providing (and the (E)UDM 515 receiving or otherwise obtaining) a consent profile including a consent type. The (E)UDM 515 may generally store, save, or otherwise maintain a consent profile for an end user (e.g., a user ID) for use across consent platforms for consent management, consent enforcement, and the like. For example, provisioning the consent profile at the (E)UDM 515 may include the DGS 510 sending or otherwise providing an indication of an identifier of a device of the end user, a consent profile ID, and the like.

[0173] Figure 6An example of a method 600 for supporting consent management procedures according to one or more aspects of the present disclosure is illustrated. The method 600 may implement aspects of the wireless communication system 100 and / or 200, aspects of the consent profile 300, aspects of the provisioning configuration 400, and / or aspects of the method 500. Aspects of the method 600 may be implemented by or at a DGC 605, a DGS 610, and a (E)UDM 615, which may be examples of corresponding devices described herein. For example, a DGC 605 may refer to an application, feature, or other functionality that operates at a device of an end user (e.g., a UE or some other device) or is otherwise associated with an end user (e.g., operating at an application layer of a UE). The DGC 605 may be a component or function within a consent platform that includes a DGS 610 and / or a (E)UDM 615 operating within a core network. Thus, references to a network entity may include a DGS 610 and / or a (E)UDM 615.

[0174] As discussed above, aspects of the technology described herein provide for consent profile provisioning within a consent platform.Method 600 illustrates a non-limiting example of an overview of consent management by an end-user within a consent platform.

[0175] For example, at 620, DGC 605 may send or otherwise provide (and DGS 610 may receive or otherwise obtain) an HTTPS message (e.g., a consent profile registration request) that initiates the provisioning of the consent profile within the consent platform. In some examples, the HTTPS message (e.g., operating at an application layer of a UE or other user device implementing DGC 605) may carry or otherwise convey an indication of user information (e.g., a user ID and other information of the end user), an indication of the consent profile, etc.

[0176] At 625, the DGS 610 may send or otherwise provide (and the (E)UDM 615 may receive or otherwise obtain) a parameter provisioning message that typically carries or otherwise conveys a user ID (e.g., based at least in part on the FIDO registration and authentication process) and a consent profile. For example, the message may typically include consent types for the consent profile, wherein one, some, or all of the consent types configure consent parameters for the consent profile for the user ID. As previously discussed, at 630, the (E)UDM 615 may typically provision, store, or otherwise maintain the consent profile at a UDM within the consent platform, or may store aspects of the consent profile (e.g., subscription ID) at the UDM and other aspects of the consent profile at the EUDM.

[0177] At 635, the (E)UDM 615 may send or otherwise provide (and the DGS 610 may receive or otherwise obtain) a parameter provisioning response that generally confirms that the end-user's consent profile has been provisioned at the (E)UDM 615. At 640, the DGS 610 may send or otherwise communicate (and the DGC 605 may receive or otherwise obtain) an OK message confirming that the consent profile has been provisioned for the end-user at the (E)UDM 615.

[0178] Thus, user consent is typically managed at the application layer within the consent platform between the DGC 605 and the DGS 610. This may include support for different elements of consent profiles being configured or otherwise provisioned (e.g., different consent types, different consent parameters within a consent type). In some examples, support for special consents for minors may also be managed at the application layer within the consent platform.

[0179] Likewise, mapping user information to a user ID may be based on a subscription ID and a consent profile ID (e.g., a user ID is composed of a subscription ID and a consent profile ID). A user ID uniquely identifies a subscription ID under which one or more consent profiles are provisioned or otherwise stored. A user ID may be used to associate a data subject (e.g., an end user) with a user consent having a corresponding consent profile. A user ID may be defined as a subscription ID consent profile ID. A user ID may be generated by a system (e.g., within a consent platform) and mapped to a corresponding {subscription ID, consent profile ID} pair. Likewise, examples of subscription IDs may include SUPI, GPSI, etc.

[0180] The consent profile ID uniquely identifies a user at the DGS 610. A consent profile may be generated / assigned during the user registration and authentication process. The consent profile ID may be registered at the DGS 610 and the (E)UDM 615. The consent profile ID may be provided to the DGS 610 during a consent profile change (e.g., update) procedure.

[0181] It should be understood that similar techniques may be applied to permit an end user to update consent parameters of a consent type, a consent type of a consent profile, and / or the consent profile itself. For example, the DGC 605 may send or otherwise provide an update message to a network entity (e.g., DGS 610 in this example). The update message may generally identify the updated parameters (e.g., consent parameters of one or more consent types in the consent type of the consent profile). The DGS 610 may receive the update message and update the consent parameters of the consent type based on the update message. In other examples, one or more consent parameters may be updated by a subscriber (e.g., a data provider and / or a data processor / consumer).

[0182] Figure 7 An example of a consent management configuration 700 that supports consent management procedures according to one or more aspects of the present disclosure is illustrated. The consent management configuration 700 may implement aspects of the wireless communication system 100 and / or 200, aspects of the consent profile 300, aspects of the provisioning configuration 400, and / or aspects of the method 500 and / or 600. Various aspects of the consent management configuration 700 may be implemented by or at the CMF 705, the data provider 710, and the data processor / consumer 715, which may be examples of corresponding devices described herein. For example, the CMF 705 may refer to an application, feature, or other function that operates within the consent platform. Thus, references to a network entity may include the CMF 705.

[0183] As discussed above, aspects of the technology described herein provide for consent profile provisioning within a consent platform. Consent management configuration 700 illustrates a non-limiting example of an overview of consent enforcement by CMF 705 using consent profiles within a consent platform.

[0184] Data provider 710 typically includes a data provider service that provides access to data (e.g., end-user data) to one or more data processors / consumers. Examples of data provider 710 may include an AMF within a core network, but other components / functions of the core network that may monitor, obtain, or otherwise collect data or other information related to end users. Data provider 710 typically may provide subscription services to data processors / consumers (e.g., using one or more subscription messages and response notification messages). Data processor / consumer 715 typically may refer to any entity or function that accesses end-user data or other information to at least some extent. Data provider 710 and / or data processor / consumer 715 typically may be responsible for terminating data collection procedures and / or retaining or erasing end-user data.

[0185] The CMF 705 typically indicates user consent for data access in real time within the consent platform. For example, the CMF 705 may subscribe to a notification service associated with a consent profile for a user ID to the (E)UDM. The CMF 705 may provide support for query services to data provider 710 services to confirm consent to access user data (e.g., using one or more query / notification messages). The CMF 705 may provide notification services to data provider 710 services to allow data providers to implement consent for end-user data. The CMF 705 typically maintains a list of network services that currently access the data of a user ID. For example, the CMF 705 may support notifying network services (e.g., data processors / consumers 715) when a consent profile has changed.

[0186] Figure 8 An example of a method 800 for supporting a consent management procedure according to one or more aspects of the present disclosure is illustrated. The method 800 may implement aspects of the wireless communication system 100 and / or 200, aspects of the consent profile 300, aspects of the provisioning configuration 400, aspects of the methods 500 and / or 600, and / or aspects of the consent management configuration 700. Aspects of the method 800 may be implemented by or at the (E)UDM 805, CMF 810, data provider 815, and data processor 820 (e.g., data processor / consumer), which may be examples of corresponding devices described herein. For example, the (E)UDM 805 and / or CMF 810 may refer to an application, feature, or other function operating within a consent platform. Thus, references to a network entity may include the (E)UDM 805 and / or CMF 810.

[0187] As discussed above, various aspects of the technology described herein provide for the provision of consent profiles within a consent platform. The consent management configuration 700 discussed above illustrates an example of an overview of the implementation of consent by CMF 705 using a consent profile within a consent platform. Method 800 illustrates a non-limiting example of an activity request for initiating consent implementation within a consent platform. Broadly speaking, a data processor 820 may request data from a data provider 815 and indicate a use case (e.g., a data processor 820 may be an example of a third party accessing end-user data via a network open function (NEF)). That is, various aspects of the provision and management of consent profiles within a consent platform may be defined at the NEF to expose actual data, including NEF implementation regarding whether a third party may access end-user data. The data provider 815 may typically determine whether consent is required for the data requested for the use case. The consent profile associated with the use case may be queried via CMF 810, and the CMF may also track a list of current data providers for a user ID, such as to support revocation. The data provider 815 typically initiates data collection at a device and across different network services based on a consent profile. For example, data provider 815 may generally provide relevant information to data processor 820 to retrieve data.

[0188] For example, at 825, the data processor 820 may send or otherwise provide (and the data provider 815 may receive or otherwise obtain) a subscription message. The subscription message may carry or otherwise convey an indication of the user ID (e.g., if known), may identify the data being requested to access, a use case (e.g., a subscription), and an activation indication. The activation indication may indicate that the data processor 820 is requesting access to end-user data. In some examples, the subscription message may be sent or otherwise provided via or based at least in part on the NEF.

[0189] At 830, the data provider 815 may identify or otherwise determine whether consent is required. For example, the data to which the data processor 820 is requesting access may be open or otherwise available for access without user consent (e.g., public information or non-personal information). Other data (perhaps most of the end user's data or data related to the end user) may require the user's consent before access is granted. If consent is not required, the data provider 815 may simply respond to the subscription message indicating that the data is available and / or providing the data.

[0190] Otherwise, when user consent is required for data access, at 835, the data provider 815 may send or otherwise provide (and the CMF 810 may receive or otherwise obtain) a query message (e.g., a first request). Broadly speaking, the query message (e.g., a first request) may generally request access to data associated with a user ID. For example, the query message may carry or otherwise convey an indication of the user ID, a use case, and an activation indication. The activation indication may signal to the CMF 810 that a new data access request is being initiated by the data processor 820. Thus, the CMF 810 may generally receive a first request (e.g., a query message) from the data provider 815 requesting access to end-user data.

[0191] In response to the query message, at 840, CMF 810 may optionally send or otherwise provide (and (E)UDM 805 may optionally receive or otherwise obtain) a subscription request message (e.g., a second request). The subscription request message may carry or otherwise convey an indication of the user ID. The subscription request message may generally request an access level for the data provider 815 and / or the data processor 820. That is, the subscription request message may generally request an access level for the data provider 815 and / or the data processor 820 to the end-user data. Therefore, CMF 810 may optionally send a second request (e.g., a subscription request message) to the second network entity (e.g., (E)UDM 805 in this example), the second request indicating the user ID and requesting an access level.

[0192] At 845, the (E)UDM 805 may optionally perform or otherwise determine end-user authentication. For example, the (E)UDM 805 may generally access a provisioned content profile for the user ID to determine a level of access, if any, to some or all of the end-user data by the data provider 815 and / or the data processor 820. This may include the (E)UDM 805 accessing one or more consent types of a consent profile to determine the level of access.

[0193] At 850, (E)UDM 805 may optionally send or otherwise provide (and CMF 810 may optionally receive or otherwise obtain) a notification message (e.g., a first response). That is, CMF 810 may receive or otherwise obtain a first response from a second network entity (e.g., (E)UDM 805 in this example), the first response carrying or otherwise conveying an indication of the access level. For example, the notification message may carry or otherwise convey a consent profile for the user ID, one or more consent types for the use case, and / or may simply use a bit or flag to indicate the access level that the data provider 815 and / or data processor 820 is granted to the end-user data.

[0194] At 855, CMF 810 may send or otherwise provide (and data provider 815 may receive or otherwise obtain) an update message (e.g., a second response). That is, CMF 810 may send a second response (e.g., an update message) to data provider 815, the second response carrying or otherwise conveying an indication of the user ID and the consent profile (or consent type of the consent profile) for the use case. Thus, CMF 810 may send or otherwise provide a second response (e.g., an update message) to the data provider indicating the access level.

[0195] At 860, the data provider 815 may identify, determine, or otherwise verify consent for the use case. For example, the data provider 815 may use the consent profile (or consent type of the consent profile) for the use case and the subscription message received from the data processor 820 to confirm or otherwise verify that the user has granted consent to the user data for the data provider 815 and / or the data processor 820.

[0196] Thus, at 865, (E)UDM 805, CMF 810, and data provider 815 may initiate data collection at the end-user device and utilizing different network services (such as data processor 820) based on the consent profile (or consent type of the consent profile). This may include CMF 810 sending or otherwise providing an indication to data provider 815 to grant access to some or all of the end-user data associated with the user ID (e.g., based on an access level).

[0197] At 870, the data provider 815 may send or otherwise provide (and the data processor 820 may receive or otherwise obtain) a notification message. The notification message may generally carry or otherwise convey an indication that consent has been given to data collection. For example, the notification message may carry or convey an indication of a user ID and data information, such as end-user data, information for collecting end-user data from an end-user device, etc. Likewise, the access level of the data processor 820 may be based on the consent profile of the user ID. Thus, the data processor 820 may collect end-user data from end-user devices and, where applicable, across different network services.

[0198] Fig. 9An example of a method 900 for supporting a consent management procedure according to one or more aspects of the present disclosure is illustrated. The method 900 may implement aspects of the wireless communication system 100 and / or 200, aspects of the consent profile 300, aspects of the provisioning configuration 400, aspects of the methods 500, 600, and / or 800, and / or aspects of the consent management configuration 700. Aspects of the method 900 may be implemented by or at the (E)UDM 905, CMF 910, data provider 915, and data processor 920 (e.g., data processor / consumer), which may be examples of corresponding devices described herein. For example, the (E)UDM 905 and / or CMF 910 may refer to an application, feature, or other function operating within a consent platform. Thus, references to a network entity may include the (E)UDM 905 and / or CMF 910.

[0199] As discussed above, aspects of the technology described herein provide for the provision of consent profiles within a consent platform. Method 900 illustrates a non-limiting example of a deactivation request from a data processor 920 to deactivate consent within a consent platform. Broadly speaking, this may include a data processor / consumer indicating to a data provider 915 (e.g., as a third party via an NEF) that end-user data is no longer required to be collected (e.g., for periodic reporting). The data provider 915 typically updates the state of the CMF 910 (e.g., the CMF 910 tracks a list of current data providers for a user ID). Based on the deactivation request, the data provider 915 typically terminates data collection at the end-user device and across different network services where applicable.

[0200] At 925, the data processor 920 may send or otherwise provide (and the data provider 915 may receive or otherwise obtain) a subscription message. The subscription message may generally carry or otherwise convey an indication of a user ID (e.g., a user ID for ongoing or active data collection) and a deactivation indication (e.g., using one or more bits, fields, flags, parameters, etc.).

[0201] At 930, the data provider 915 may send or otherwise provide (and the CMF 910 may receive or otherwise obtain) an update message. The update message may typically carry or otherwise convey an indication of the user ID and a deactivation indication. This may signal to the CMF 910 that the data provider 915 and / or data processor 920 is deactivating the collection of end-user data.

[0202] At 935, CMF 910 may send or otherwise provide (and data provider 915 may receive or otherwise obtain) an update response message. The update response message may carry or otherwise convey an indication confirming that data provider 915 and / or data processor 920 has not deactivated the collection of end-user data.

[0203] At 940, the (E)UDM 905, CMF 910, and / or data provider 915 may generally terminate data collection at the end-user device and across different network services based on the consent profile and / or deactivation indication. For example, the CMF 910 may generally identify, store, or otherwise determine a list of data consumers that access data associated with the user ID (e.g., based on a consent profile associated with the user ID). The CMF 910 may remove the data provider 915 and / or data processor 920 from the list based on the deactivation procedure. In some examples, this may include updating the access level of the data provider 915 and / or data processor 920 based on the deactivation procedure (e.g., consent profile).

[0204] At 945, the data provider 915 may send or otherwise provide (and the data processor 920 may receive or otherwise obtain) a notification message. The notification message may generally carry or otherwise convey an indication confirming that collection of end-user data has been stopped or otherwise deactivated.

[0205] Fig.10 An example of a method 1000 for supporting a consent management procedure according to one or more aspects of the present disclosure is illustrated. The method 1000 may implement aspects of the wireless communication system 100 and / or 200, aspects of the consent profile 300, aspects of the provisioning configuration 400, aspects of the methods 500, 600, 800, and / or 900, and / or aspects of the consent management configuration 700. Aspects of the method 1000 may be implemented by or at the DGC 1005, (E)UDM 1010, CMF 1015, and data provider 1020, which may be examples of corresponding devices described herein. For example, the DGC 1005, (E)UDM 1010, and / or CMF 10150 may refer to an application, feature, or other function operating within a consent platform. Thus, references to a network entity may include the (E)UDM 1010 and / or CMF 1015.

[0206] As discussed above, aspects of the technology described herein provide for the provision of consent profiles within a consent platform. Method 1000 illustrates a non-limiting example of a revocation request from an end user within a consent platform to revoke consent. Broadly speaking, this may include (E) UDM 1010 notifying CMF 1015 that consent has been revoked by the user. CMF 1015 may typically notify data providers (such as data providers 1020) that currently subscribed to a user ID whether the consent profile has changed for their use case. Data providers and / or data processors / consumers may take appropriate actions, such as notifying corresponding data processors / consumers, termination or modification of data processing (e.g., including potential termination of data processing) based on the revocation. Data providers and / or data processors / consumers may retain, correct or erase user data based on the revocation request. For example, based on the revocation request, CMF 1015 typically terminates or updates data collection at the end user device and across different network services where applicable.

[0207] At 1025, the DGC 1005 may send or otherwise provide (and the (E)UDM 1010 may receive or otherwise obtain) a parameter provisioning message. Broadly speaking, the parameter provisioning message may carry or otherwise convey an indication that the end user (e.g., using the DGC 1005 on an end user device such as a UE) has, at least to some extent, revoked consent for one or more use cases (e.g., to one or more data providers and / or data processors / consumers). For example, the parameter provisioning message may carry or otherwise convey an indication of a user ID and a revocation indication of a consent profile for the user ID.

[0208] In response to the parameter provisioning message, at 1030, the (E)UDM 1010 may send or otherwise provide (and the CMF 1015 may receive or otherwise obtain) a notification message (e.g., a revocation request). The notification message may carry or otherwise convey an indication of the user ID and a revocation indication for the consent profile for the user ID. Thus, the CMF 1015 may receive a revocation request for a consent type and / or a subset of consent profiles for the user ID.

[0209] At 1035, CMF 1015 may identify or otherwise determine which data provider and / or data consumer is affected by the revocation request. For example, CMF 1015 typically maintains a list of active processes in which data providers and / or data processors / consumers are accessing the end user's data or other information. Based on the user ID and the revocation indication for the consent profile, CMF 1015 may access the list to determine which (if any) data provider and / or data processor / consumer's consent has been revoked or modified by the end user. Fig.10 In the non-limiting example shown, this may include the CMF 1015 identifying or otherwise determining that the data provider 1020 is affected, although it is understood that multiple data providers and / or data processors / consumers are affected.

[0210] Based on the data provider 1020 being affected by the revocation request, at 1040, the CMF 1015 may send or otherwise provide (and the data provider 1020 may receive or otherwise obtain) a notification message indicating the user ID and the revocation indication.

[0211] Thus, at 1045, the DGC 1005, (E)UDM 1010, CMF 1015, and / or data provider 1020 may update actions that occur at the end-user device and across different network services based on the user ID / consent profile. For example, this may include stopping or otherwise modifying data collection based on a revocation request from the end-user. In some examples, this may include the CMF 1015 updating an access level associated with a consent type to a revoked state based on the revocation request. In some examples, this may include the data provider 1020 and / or data processor / consumer adopting an action to be taken on a revoke consent parameter in a consent type of a consent profile for the user ID in response to the revocation request.

[0212] Fig.11 An example of a method 1100 for supporting a consent management procedure according to one or more aspects of the present disclosure is illustrated. The method 1100 may implement aspects of the wireless communication system 100 and / or 200, aspects of the consent profile 300, aspects of the provisioning configuration 400, aspects of the methods 500, 600, 800, 900, and / or 1000, and / or aspects of the consent management configuration 700. Aspects of the method 1100 may be implemented by or at the DGC 1105, DGS 1110, and / or (E) UDM 1115, which may be examples of corresponding devices described herein. For example, the DGC 1105, DGS 1110, and / or (E) UDM 1115 may refer to an application, feature, or other function operating within a consent platform. Thus, references to a network entity may include the (E) UDM 1115 and / or the DGS 1110. References to a UE may include the DGC 1105.

[0213] As discussed above, aspects of the technology described herein provide for consent profile provisioning within a consent platform. Method 1100 illustrates a non-limiting example of dynamic user authentication applied during consent enforcement within a consent platform. This may include consent enforcement activation at or by (E)UDM 1115.

[0214] For example, at 1120, the (E)UDM 1115 may send or otherwise provide (and the DGS 1110 may receive or otherwise obtain) an end-user authentication request (e.g., a dynamic access request). Broadly speaking, the end-user authentication request may carry or otherwise convey an indication of a request to access some or all of the data / information (e.g., a portion of the data / information) associated with the user ID. For example, the (E)UDM 1115 may receive an indication for dynamic end-user authentication from a CMF within the consent platform, and in response, provide a dynamic access request. The indication may carry or otherwise convey consent that end-user authentication is required for enforcement. For example, the CMF may receive a dynamic access request message from a data provider requesting access to data associated with the user ID. In response, the CMF may send or otherwise provide a dynamic access request to a second network entity (e.g., in this example, the (E)UDM 1115). The message may carry or otherwise convey an indication of a user ID, data of the end user for whom access is being requested, and / or a consent type associated with the use case.

[0215] At 1125, DGS 1110 may send or otherwise provide (and DGC 1105 may receive or otherwise obtain) an end-user authentication request. The request may carry or otherwise convey an indication of a user ID, data of the end-user requesting access, and / or a consent type associated with the use case.

[0216] In response to the dynamic user authentication request, the DGC 1105 and DGS 1110 may perform an end-user authentication procedure, such as a FIDO procedure, at 1130. This may be used to confirm that the user of the device is actually the end-user associated with the user ID that is requesting access.

[0217] At 1135, the DGS 1110 may send or otherwise provide (and the (E)UDM 1115 may receive or otherwise obtain) an end-user consent result message (e.g., a dynamic access response). Typically, the end-user consent result message may carry or otherwise convey an indication of whether the end-user has approved the access request or has denied the access request.

[0218] In some aspects and based on the (E)UDM 1115 receiving the end-user consent result, the (E)UDM 1115 may send or otherwise provide a dynamic access response to the CMF that authorizes or denies access to some or all of the end-user data. The CMF within the consent platform may forward, send, or otherwise provide the dynamic access response to the data provider requesting access to the end-user data.

[0219] Fig.12 An example of a method 1200 for supporting a consent management procedure according to one or more aspects of the present disclosure is illustrated. The method 1200 may implement aspects of the wireless communication system 100 and / or 200, aspects of the consent profile 300, aspects of the provisioning configuration 400, aspects of the methods 500, 600, 800, 900, 1000, and / or 1100, and / or aspects of the consent management configuration 700. Aspects of the method 1200 may be implemented by or at the DGC 1205, DGS 1210, and / or (E) UDM 1215, which may be examples of corresponding devices described herein. For example, the DGC 1205, DGS 1210, and / or (E) UDM 1215 may refer to an application, feature, or other functionality operating within a consent platform. Thus, references to a network entity may include the (E) UDM 1215 and / or the DGS 1210. References to the UE may include DGC 1205.

[0220] As discussed above, aspects of the technology described herein provide for consent profile provisioning within a consent platform. Method 1200 illustrates a non-limiting example of switching an end user of a device (e.g., switching an end user from one device to another device and / or adding another end user to a device). In some aspects, this may include updating end user information at (E)UDM 1215.

[0221] At 1220, this may include the DGC 1205 (which may be a DGC operating on a new or different device) obtaining or otherwise identifying a user update. For example, the user update may include the DGC 1205 receiving or otherwise updating information of its associated device from the end user, such as the end user initiating an initial or update consent profile procedure using the DGC on a new device. In some examples, this may include the DGC 1205 identifying or otherwise determining an identifier of the device on which the DGC 1205 is operating, a consent profile associated with a user ID, and the like.

[0222] At 1225, DGC 1205 and DGS 1210 may perform an end-user authentication procedure (e.g., FIDO procedure) to confirm the identity of the end-user. This procedure may be used to confirm that the end-user who previously used the first device provisioning consent profile is the same end-user who submitted the end-user device update procedure within the consent platform.

[0223] At 1230, DGS 1210 may send or otherwise provide (and (E)UDM 1215 may receive or otherwise obtain) a consent profile change request that identifies the device ID of the new device that the end-user is switching to or otherwise registering with and the consent profile ID associated with the user ID of the end-user. For example, (E)UDM 1215 may receive an update message from the second network entity (DGS 1210 in this example) identifying an updated end-user device associated with the user ID. In response, (E)UDM 1215 may update the consent parameter of the consent type of the consent profile for the user ID to include the updated end-user device.

[0224] Fig.13 An example of a method 1300 for supporting a consent management procedure according to one or more aspects of the present disclosure is illustrated. The method 1300 may implement aspects of the wireless communication system 100 and / or 200, aspects of the consent profile 300, aspects of the provisioning configuration 400, aspects of the methods 500, 600, 800, 900, 1000, 1100, and / or 1200, and / or aspects of the consent management configuration 700. Aspects of the method 1300 may be implemented by or at the DGC 1305, DGS 1310, and / or CMF 1315, which may be examples of corresponding devices described herein. For example, the DGC 1305, DGS 1310, and / or CMF 1315 may refer to an application, feature, or other function operating within a consent platform. Thus, references to a network entity may include the DGS 1310 and / or CMF 1315. References to a UE may include the DGC 1305.

[0225] As discussed above, aspects of the technology described herein provide for the provision of consent profiles within a consent platform. Method 1300 illustrates, at a high level, a non-limiting example of a data processing query initiated by an end user (e.g., by an end user using DGC 1305 on an end user device). The technology outlined in method 1300 may provide a mechanism for an end user to identify or otherwise determine which data providers and / or data processors / consumers are currently accessing end user data. As discussed above, CMF 1315 may typically maintain a list of data providers and / or data processors / consumers that are accessing or have access to some or all of the end user data.

[0226] At 1320, the DGC 1305 may identify or otherwise obtain a user query. For example, an end user may submit a data processing query using the DGC 1305 running at an application layer within a consent platform.

[0227] In response, DGC 1305 and DGS 1310 may perform end-user authentication procedures (eg, FIDO procedures) at 1325. This may enable confirmation of the end user submitting the data processing query.

[0228] At 1330, the DGC 1305 may send or otherwise provide (and the DGS 1310 may receive or otherwise obtain, for example, from the UE) a data collection status query (e.g., a data collection query). In some aspects, the query may carry or otherwise convey a request for a data access status associated with a user associated with the consent profile ID of the consent profile. The data access status may generally refer to a list of data providers and / or data processors / consumers that currently access or have access to the end-user data.

[0229] At 1335, the DGS 1310 and the CMF 1315 may generally exchange one or more messages for data collection status queries. For example, the DGS 1310 may send or otherwise provide a data collection query and a user ID to a third network entity (e.g., CMF 1315 in this example). The CMF 1315 may send or otherwise provide a data collection response that identifies the data provider and / or data processor / consumer that is accessing the data associated with the consent profile. In response, the DGS 1310 may send (e.g., to a UE implementing the DGC 1305) a data collection response that identifies the data provider and / or data processor / consumer that is accessing the end-user data.

[0230] Fig.14 An example of a method 1400 for supporting a consent management procedure according to one or more aspects of the present disclosure is illustrated. The method 1400 may implement aspects of the wireless communication system 100 and / or 200, aspects of the consent profile 300, aspects of the provisioning configuration 400, aspects of the methods 500, 600, 800, 900, 1000, 1100, 1200, and / or 1300, and / or aspects of the consent management configuration 700. Aspects of the method 1400 may be implemented by or at a DGC 1405, a DGS 1410, a CMF 1415, and / or a data provider 1420, which may be examples of corresponding devices described herein. For example, a DGC 1405, a DGS 1410, and / or a CMF 1415 may refer to an application, feature, or other function operating within a consent platform. Thus, references to a network entity may include a DGS 1410 and / or a CMF 1415. References to the UE may include DGC1405.

[0231] As discussed above, aspects of the technology described herein provide for the provision of consent profiles within a consent platform. Method 1400 illustrates, at a more detailed level, a non-limiting example of a data processing query initiated by an end user (e.g., by an end user using a DGC 1405 on an end user device). The technology outlined in method 1400 may provide a mechanism for an end user to identify or otherwise determine which data providers and / or data processors / consumers are currently accessing end user data. As discussed above, CMF 1415 may typically maintain a list of data providers and / or data processors / consumers that are accessing or have access to some or all of the end user data.

[0232] Broadly speaking, a data processing query may include the DGS 1410 querying the CMF 1415 to see which services are currently collecting / processing data for a user. In response, the CMF 1415 generates a list that includes identifiers of data providers and / or data processors / consumers that are currently accessing the end-user data. In some examples, the CMF 1415 maintains a list of active data providers and / or data processors / consumers and generates a list of active users in response to an end-user query. In some examples, the CMF 1415 queries data providers and / or data processors / consumers to see which are processing or otherwise accessing the end-user data.

[0233] At 1425, DGC 1405 may send or otherwise provide (and DGS 1410 may receive or otherwise obtain) a data processing status query. For example, an end user may initiate a data processing status query using DGC 1405 on an end user device operating at an application layer within the consent platform. In some examples, the data processing status query may carry or otherwise convey user information, such as a user ID, a consent profile ID, etc.

[0234] At 1430, DGS 1410 may send or otherwise provide (and CMF 1415 may receive or otherwise obtain) a data processing request. The data processing request may carry or otherwise convey an indication of the user ID and may trigger the CMF to provide a list of data providers and / or data processors / consumers that access the end-user data.

[0235] At 1435, CMF 1415 may generate a list of data providers and / or data processors / consumers accessing the end-user data. As discussed above, in some examples, CMF 1415 may generally store or otherwise maintain a list of data providers and / or data processors / consumers that are accessing, processing, or otherwise have access to the end-user data.

[0236] Additionally or alternatively, CMF 1415 may optionally send or otherwise provide (and data provider 1420 may receive or otherwise obtain) a query at 1440. The query may generally indicate a user ID and request an indication of whether data provider 1420 is accessing or otherwise processing end-user data.

[0237] At 1445, the data provider 1420 may optionally query the data processors / consumers to determine which, if any, are accessing the end-user data. For example, the data provider 1420 may determine which, if any, data processors / consumers are utilizing the end-user data based on previous activation requests.

[0238] At 1450, the data provider 1420 may optionally send or otherwise provide (and the CMF 1415 may receive or otherwise obtain) a query response. The query response may generally identify whether the data provider 1420 and any associated data processors / consumers are accessing the end-user data.

[0239] At 1455, CMF 1415 may send or otherwise provide (and DGS 1410 may receive or otherwise obtain) a response that carries or otherwise conveys an indication of a list of data providers and / or data processors / consumers that are accessing the end-user data (e.g., based on the user ID of the consent profile).

[0240] At 1460, the DGS 1410 may send or otherwise provide (and the DGC 1405 may receive or otherwise obtain) a response that carries or otherwise conveys an indication of a list of data providers and / or data processors / consumers that are accessing the end user's data. Thus, the method 1400 illustrates a mechanism within a consent platform for an end user to dynamically request access to the data access status (e.g., according to a consent profile) of data providers and / or data processors / consumers associated with the end user's user ID.

[0241] Fig.15 A block diagram 1500 of a device 1505 supporting consent management procedures according to one or more aspects of the present disclosure is shown. The device 1505 may be an example of aspects of the network entity 105 as described herein. The device 1505 may include a receiver 1510, a transmitter 1515, and a communication manager 1520. The device 1505 may also include a processor. Each of these components may communicate with each other (e.g., via one or more buses).

[0242] Receiver 1510 may provide means for obtaining (e.g., receiving, determining, identifying) information associated with various channels (e.g., control channels, data channels, information channels, channels associated with a protocol stack), such as user data, control information, or any combination thereof (e.g., I / Q samples, symbols, packets, protocol data units, service data units). The information may be communicated to other components of device 1505. In some examples, receiver 1510 may support obtaining information by receiving signals via one or more antennas. Additionally or alternatively, receiver 1510 may support obtaining information by receiving signals via one or more wired (e.g., electrical, optical fiber) interfaces, wireless interfaces, or any combination thereof.

[0243] The transmitter 1515 may provide means for outputting (e.g., transmitting, providing, conveying, transmitting) information generated by other components of the device 1505. For example, the transmitter 1515 may output information associated with various channels (e.g., control channels, data channels, information channels, channels associated with a protocol stack) (such as user data, control information, or any combination thereof (e.g., I / Q samples, symbols, packets, protocol data units, service data units)). In some examples, the transmitter 1515 may support outputting information by sending signals via one or more antennas. Additionally or alternatively, the transmitter 1515 may support outputting information by sending signals via one or more wired (e.g., electrical, optical fiber) interfaces, wireless interfaces, or any combination thereof. In some examples, the transmitter 1515 and the receiver 1510 may be co-located in a transceiver, which may include a modem or be coupled to a modem.

[0244] The communication manager 1520, the receiver 1510, the transmitter 1515, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the consent management procedures as described herein. For example, the communication manager 1520, the receiver 1510, the transmitter 1515, or various combinations thereof or components thereof may support methods for performing one or more of the functions described herein.

[0245] In some examples, the communication manager 1520, the receiver 1510, the transmitter 1515, or various combinations or components thereof may be implemented in hardware (e.g., in a communication management circuit). The hardware may include a processor, a DSP, a CPU, an ASIC, an FPGA or other programmable logic device, a microcontroller, discrete gate or transistor logic, discrete hardware components, or any combination thereof configured as or otherwise supporting means for performing the functions described in the present disclosure. In some examples, a processor and a memory coupled to the processor may be configured to perform one or more of the functions described herein (e.g., by executing instructions stored in the memory by the processor).

[0246] Additionally or alternatively, in some examples, the communication manager 1520, the receiver 1510, the transmitter 1515, or various combinations or components thereof may be implemented in code executed by a processor (e.g., as communication management software or firmware). If implemented in code executed by a processor, the functionality of the communication manager 1520, the receiver 1510, the transmitter 1515, or various combinations or components thereof may be performed by a general purpose processor (e.g., configured as or otherwise supporting means for performing the functionality described in the present disclosure), a DSP, a CPU, an ASIC, an FPGA, a microcontroller, or any combination of these or other programmable logic devices.

[0247] In some examples, communication manager 1520 may be configured to perform various operations (e.g., receive, obtain, monitor, output, send) using or otherwise cooperating with receiver 1510, transmitter 1515, or both. For example, communication manager 1520 may receive information from receiver 1510, transmit information to transmitter 1515, or be integrated in conjunction with receiver 1510, transmitter 1515, or both to obtain information, output information, or perform various other operations as described herein.

[0248] The communication manager 1520 may support wireless communications at the first network entity according to examples as disclosed herein. For example, the communication manager 1520 may be configured to or otherwise support a component for identifying a consent profile for a user identifier, the consent profile including one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis. The communication manager 1520 may be configured to or otherwise support a component for receiving a request from a second network entity, the request indicating the user identifier and requesting an access level for a data provider corresponding to at least one of the one or more consent types. The communication manager 1520 may be configured to or otherwise support a component for sending a response indicating an access level to the second network entity based on the request and one or more consent parameters for at least one consent type.

[0249] Additionally or alternatively, according to examples as disclosed herein, the communication manager 1520 may support wireless communications at the first network entity. For example, the communication manager 1520 may be configured to or otherwise support a component for receiving a consent profile registration request identifying a user identifier from a UE. The communication manager 1520 may be configured to or otherwise support a component for receiving a consent profile from the UE based on the consent profile registration request, the consent profile including one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis. The communication manager 1520 may be configured to or otherwise support a component for sending a consent profile to a second network entity.

[0250] Additionally or alternatively, according to examples as disclosed herein, the communication manager 1520 may support wireless communications at the first network entity. For example, the communication manager 1520 may be configured to or otherwise support a component for receiving a first request from a data provider requesting access to data associated with a user identifier, the data provider corresponding to at least one of the one or more consent types of the user identifier. The communication manager 1520 may be configured to or otherwise support a component for sending a second request to a second network entity, the second request indicating the user identifier and requesting an access level for the data provider. The communication manager 1520 may be configured to or otherwise support a component for receiving a first response from the second network entity indicating an access level. The communication manager 1520 may be configured to or otherwise support a component for sending a second response to the data provider indicating an access level.

[0251] By including or configuring a communications manager 1520 according to examples as described herein, a device 1505 (e.g., a processor controlling or otherwise coupled to a receiver 1510, a transmitter 1515, a communications manager 1520, or a combination thereof) may support techniques for a consent platform implemented within a wireless communications system that provides or otherwise supports granular end-user configuration of consent profiles for end users on at least a per-end-user basis (e.g., rather than solely on a per-subscription basis).

[0252] Fig.16 A block diagram 1600 of a device 1605 supporting consent management procedures according to one or more aspects of the present disclosure is shown. The device 1605 may be an example of aspects of the device 1505 or the network entity 105 as described herein. The device 1605 may include a receiver 1610, a transmitter 1615, and a communication manager 1620. The device 1605 may also include a processor. Each of these components may communicate with each other (e.g., via one or more buses).

[0253] Receiver 1610 may provide means for obtaining (e.g., receiving, determining, identifying) information associated with various channels (e.g., control channels, data channels, information channels, channels associated with a protocol stack), such as user data, control information, or any combination thereof (e.g., I / Q samples, symbols, packets, protocol data units, service data units). The information may be communicated to other components of device 1605. In some examples, receiver 1610 may support obtaining information by receiving signals via one or more antennas. Additionally or alternatively, receiver 1610 may support obtaining information by receiving signals via one or more wired (e.g., electrical, optical fiber) interfaces, wireless interfaces, or any combination thereof.

[0254] Transmitter 1615 may provide means for outputting (e.g., transmitting, providing, conveying, transmitting) information generated by other components of device 1605. For example, transmitter 1615 may output information associated with various channels (e.g., control channels, data channels, information channels, channels associated with a protocol stack) (such as user data, control information, or any combination thereof (e.g., I / Q samples, symbols, packets, protocol data units, service data units)). In some examples, transmitter 1615 may support outputting information by sending signals via one or more antennas. Additionally or alternatively, transmitter 1615 may support outputting information by sending signals via one or more wired (e.g., electrical, optical fiber) interfaces, wireless interfaces, or any combination thereof. In some examples, transmitter 1615 and receiver 1610 may be co-located in a transceiver, which may include a modem or be coupled to a modem.

[0255] Device 1605 or its various components may be examples of components for performing various aspects of the consent management procedures as described herein. For example, communication manager 1620 may include (E)UDM manager 1625, DGS manager 1630, CMF manager 1635, or any combination thereof. Communication manager 1620 may be an example of various aspects of communication manager 1520 as described herein. In some examples, communication manager 1620 or its various components may be configured to use or otherwise cooperate with receiver 1610, transmitter 1615, or both to perform various operations (e.g., receive, obtain, monitor, output, send). For example, communication manager 1620 may receive information from receiver 1610, transmit information to transmitter 1615, or be integrated in combination with receiver 1610, transmitter 1615, or both to obtain information, output information, or perform various other operations as described herein.

[0256] The communication manager 1620 may support wireless communication at the first network entity according to examples as disclosed herein. (E) The UDM manager 1625 may be configured to or otherwise support means for identifying a consent profile for a user identifier, the consent profile comprising one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis. (E) The UDM manager 1625 may be configured to or otherwise support means for receiving a request from a second network entity, the request indicating the user identifier and requesting an access level for a data provider corresponding to at least one of the one or more consent types. (E) The UDM manager 1625 may be configured to or otherwise support means for sending a response indicating an access level to the second network entity based on the request and the one or more consent parameters for the at least one consent type.

[0257] Additionally or alternatively, according to examples as disclosed herein, the communication manager 1620 may support wireless communications at the first network entity. The DGS manager 1630 may be configured to or otherwise support a component for receiving a consent profile registration request identifying a user identifier from a UE. The DGS manager 1630 may be configured to or otherwise support a component for receiving a consent profile from the UE based on the consent profile registration request, the consent profile including one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis. The DGS manager 1630 may be configured to or otherwise support a component for sending a consent profile to a second network entity.

[0258] Additionally or alternatively, according to examples as disclosed herein, the communication manager 1620 may support wireless communications at the first network entity. The CMF manager 1635 may be configured to or otherwise support a component for receiving a first request from a data provider requesting access to data associated with a user identifier, the data provider corresponding to at least one of the one or more consent types for the user identifier. The CMF manager 1635 may be configured to or otherwise support a component for sending a second request to a second network entity, the second request indicating the user identifier and requesting an access level for the data provider. The CMF manager 1635 may be configured to or otherwise support a component for receiving a first response indicating an access level from the second network entity. The CMF manager 1635 may be configured to or otherwise support a component for sending a second response indicating an access level to the data provider.

[0259] Fig.17Block diagram 1700 of a communication manager 1720 supporting a consent management procedure according to one or more aspects of the present disclosure is shown. The communication manager 1720 may be an example of aspects of the communication manager 1520, the communication manager 1620, or both as described herein. The communication manager 1720 or its various components may be examples of components for performing various aspects of the consent management procedure as described herein. For example, the communication manager 1720 may include an (E)UDM manager 1725, a DGS manager 1730, a CMF manager 1735, a provisioning manager 1740, a profile ID manager 1745, a profile update manager 1750, a device update manager 1755, a query manager 1760, an access manager 1765, an access level manager 1770, a state manager 1775, a dynamic access manager 1780, or any combination thereof. Each of these components may communicate with each other directly or indirectly (e.g., via one or more buses), which communication may include communication within a protocol layer of a protocol stack, communication associated with a logical channel of a protocol stack (e.g., between protocol layers of a protocol stack, within a device, component, or virtualized component associated with the network entity 105, between devices, components, or virtualized components associated with the network entity 105), or any combination thereof.

[0260] The communication manager 1720 can support wireless communication at the first network entity according to examples as disclosed herein. (E) The UDM manager 1725 can be configured to or otherwise support components for identifying a consent profile for a user identifier, the consent profile including one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis.

[0261] In some examples, (E)UDM manager 1725 may be configured or otherwise support means for receiving a request from a second network entity, the request indicating a user identifier and requesting an access level for a data provider corresponding to at least one of the one or more consent types. In some examples, (E)UDM manager 1725 may be configured or otherwise support means for sending a response indicating an access level to the second network entity based on the request and one or more consent parameters of the at least one consent type.

[0262] In some examples, provisioning manager 1740 may be configured or otherwise support means for storing a subscription identifier for a consent profile and a user identifier in a unified data management entity, where the first network entity includes the unified data management entity.

[0263] In some examples, provisioning manager 1740 may be configured to or otherwise support components for storing a subscription identifier for a user identifier in a unified data management entity and storing a consent profile for the user identifier in an end-user unified data management entity, where the first network entity includes the end-user unified data management entity.

[0264] In some examples, profile ID manager 1745 can be configured to or otherwise support means for receiving a consent profile identifier from a third network entity associated with the first network entity, wherein a consent profile identifying the user identifier is based on receiving the consent profile identifier. In some examples, the consent profile identifier maps the consent profile to a user associated with the user identifier at the UE.

[0265] In some examples, profile update manager 1750 may be configured or otherwise support means for receiving an update message identifying updated parameters of at least one of the one or more consent types. In some examples, profile update manager 1750 may be configured or otherwise support means for updating one or more consent parameters of at least one consent type of the consent profile based on the update message. In some examples, the update message is received from a third network entity or a UE associated with a consent profile identifier of the consent profile.

[0266] In some examples, the device update manager 1755 may be configured to or otherwise support a component for receiving an update message identifying an updated end-user device associated with a user identifier from a second network entity. In some examples, the device update manager 1755 may be configured to or otherwise support a component for updating one or more consent parameters of the user identifier based on the update message to include an updated end-user device. In some examples, the subscription identifier associated with the user identifier includes a fifth generation subscription permanent identifier. In some examples, the subscription identifier associated with the user identifier includes a universal public subscription identifier. In some examples, the user identifier is associated with a subscription identifier, a consent profile identifier, or both. In some examples, the consent profile and the consent profile identifier of the consent profile are determined based on the results of the FIDO authentication procedure for the user associated with the user identifier.

[0267] Additionally or alternatively, according to examples as disclosed herein, the communication manager 1720 may support wireless communications at the first network entity. The DGS manager 1730 may be configured to or otherwise support a component for receiving a consent profile registration request identifying a user identifier from a UE. In some examples, the DGS manager 1730 may be configured to or otherwise support a component for receiving a consent profile from the UE based on the consent profile registration request, the consent profile including one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis. In some examples, the DGS manager 1730 may be configured to or otherwise support a component for sending a consent profile to a second network entity.

[0268] In some examples, the query manager 1760 may be configured to or otherwise support a component for receiving a data collection query from a UE, the data collection query requesting a data access state associated with a user associated with a consent profile identifier of a consent profile. In some examples, the query manager 1760 may be configured to or otherwise support a component for sending a data collection query and a user identifier to a third network entity. In some examples, the query manager 1760 may be configured to or otherwise support a component for receiving a data collection response from a third network entity based on the data collection query and the user identifier, the data collection response identifying a data provider accessing data associated with the consent profile. In some examples, the query manager 1760 may be configured to or otherwise support a component for sending a data collection response to the UE based on the data collection query.

[0269] Additionally or alternatively, according to examples as disclosed herein, the communication manager 1720 may support wireless communications at the first network entity. The CMF manager 1735 may be configured to or otherwise support a component for receiving a first request from a data provider requesting access to data associated with a user identifier, the data provider corresponding to at least one of the one or more consent types of the user identifier. In some examples, the CMF manager 1735 may be configured to or otherwise support a component for sending a second request to a second network entity, the second request indicating the user identifier and requesting an access level for the data provider. In some examples, the CMF manager 1735 may be configured to or otherwise support a component for receiving a first response indicating an access level from the second network entity. In some examples, the CMF manager 1735 may be configured to or otherwise support a component for sending a second response indicating an access level to the data provider.

[0270] In some examples, access manager 1765 may be configured or otherwise support means for sending an indication to the data provider to grant access to at least a portion of the data associated with the user identifier based on the second response, where at least the portion of the data is based on the access level.

[0271] In some examples, access level manager 1770 may be configured or otherwise support means for receiving an access level request for data associated with at least one consent type for a user identifier from a second data provider. In some examples, access level manager 1770 may be configured or otherwise support means for sending an access level response to the second data provider indicating a second access level for the second data provider.

[0272] In some examples, access manager 1765 may be configured or otherwise support components for identifying a set of one or more data consumers that access data associated with a user identifier based on one or more consent types for the user identifier.

[0273] In some examples, state manager 1775 may be configured or otherwise support means for receiving a deactivation request for a subset of one or more consent types for a user identifier from a data provider. In some examples, state manager 1775 may be configured or otherwise support means for updating an access level of a data provider to a deactivated state based at least in part on the deactivation request.

[0274] In some examples, state manager 1775 can be configured or otherwise support means for receiving a revocation request for a subset of one or more consent types for a user identifier from a second network entity. In some examples, state manager 1775 can be configured or otherwise support means for updating an access level associated with the subset of one or more consent types to a revoked state based on the revocation request.

[0275] In some examples, the dynamic access manager 1780 may be configured to or otherwise support means for receiving a dynamic access request message from a data provider requesting access to a portion of data associated with a user identifier. In some examples, the dynamic access manager 1780 may be configured to or otherwise support means for sending a dynamic access request message to a second network entity, the dynamic access request message identifying the portion of data associated with the user identifier and at least one of the one or more consent types. In some examples, the dynamic access manager 1780 may be configured to or otherwise support means for receiving a dynamic access response from the second network entity, the dynamic access response authorizing or denying access to the portion of data associated with the user identifier. In some examples, the dynamic access manager 1780 may be configured to or otherwise support means for sending a dynamic access response to the data provider.

[0276] Fig.18 A diagram of a system 1800 including a device 1805 supporting consent management procedures according to one or more aspects of the present disclosure is shown. The device 1805 can be an example of a device 1505, a device 1605, or a network entity 105 as described herein, or include components of these devices. The device 1805 can communicate with one or more network entities 105, one or more UEs 115, or any combination thereof, which communication may include communication through one or more wired interfaces, through one or more wireless interfaces, or any combination thereof. The device 1805 may include components that support output and acquisition of communications, such as a communication manager 1820, a transceiver 1810, an antenna 1815, a memory 1825, a code 1830, and a processor 1835. These components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more buses (e.g., bus 1840).

[0277] The transceiver 1810 may support bidirectional communication via a wired link, a wireless link, or both as described herein. In some examples, the transceiver 1810 may include a wired transceiver and may communicate bidirectionally with another wired transceiver. Additionally or alternatively, in some examples, the transceiver 1810 may include a wireless transceiver and may communicate bidirectionally with another wireless transceiver. In some examples, the device 1805 may include one or more antennas 1815, which may be capable of (e.g., concurrently) sending or receiving wireless transmissions. The transceiver 1810 may also include a modem for modulating a signal, for providing a modulated signal for transmission (e.g., via one or more antennas 1815, via a wired transmitter), for receiving a modulated signal (e.g., from one or more antennas 1815, from a wired receiver), and for demodulating a signal. Where applicable, transceiver 1810, or transceiver 1810 and one or more antennas 1815, or a wired interface may be an example of transmitter 1515, transmitter 1615, receiver 1510, receiver 1610, or any combination thereof or any component thereof as described herein. In some examples, the transceiver is operable to support communication via one or more communication links (e.g., communication link 125, backhaul communication link 120, midhaul communication link 162, fronthaul communication link 168).

[0278] Memory 1825 may include RAM and ROM. Memory 1825 may store computer-readable, computer-executable code 1830 including instructions that, when executed by processor 1835, cause device 1805 to perform various functions described herein. Code 1830 may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. In some cases, code 1830 may not be directly executable by processor 1835, but may (e.g., when compiled and executed) cause a computer to perform the functions described herein. In some cases, memory 1825 may include, among other things, a BIOS that may control basic hardware or software operations, such as interaction with peripheral components or devices.

[0279] Processor 1835 may include an intelligent hardware device (e.g., a general-purpose processor, DSP, ASIC, CPU, FPGA, microcontroller, programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof). In some cases, processor 1835 may be configured to operate a memory array using a memory controller. In some other cases, the memory controller may be integrated into processor 1835. Processor 1835 may be configured to execute computer-readable instructions stored in a memory (e.g., memory 1825) so that device 1805 performs various functions (e.g., functions or tasks that support consent management procedures). For example, device 1805 or a component of device 1805 may include processor 1835 and memory 1825 coupled to processor 1835, and processor 1835 and memory 1825 are configured to perform various functions described herein. Processor 1835 may be an example of a cloud computing platform (e.g., one or more physical nodes and supporting software such as an operating system, a virtual machine, or a container instance), which may host functions (e.g., by executing code 1830) to perform functions of device 1805.

[0280] In some examples, bus 1840 may support communications of a protocol layer of a protocol stack (e.g., within the protocol layer). In some examples, bus 1840 may support communications associated with a logical channel of a protocol stack (e.g., between protocol layers of the protocol stack), which may include communications performed within a component of device 1805 or between different components of device 1805 that may be co-located or located in different locations (e.g., where device 1805 may refer to a system where one or more of communication manager 1820, transceiver 1810, memory 1825, code 1830, and processor 1835 may be located in one of the different components or divided between the different components).

[0281] In some examples, the communication manager 1820 may manage aspects of communications with the core network 130 (e.g., via one or more wired or wireless backhaul links). For example, the communication manager 1820 may manage the delivery of data communications for client devices, such as one or more UEs 115. In some examples, the communication manager 1820 may manage communications with other network entities 105 and may include a controller or scheduler for controlling communications with the UE 115 in coordination with the other network entities 105. In some examples, the communication manager 1820 may support an X2 interface within an LTE / LTE-A wireless communication network technology to provide communications between network entities 105.

[0282] The communication manager 1820 may support wireless communications at the first network entity according to examples as disclosed herein. For example, the communication manager 1820 may be configured to or otherwise support a component for identifying a consent profile for a user identifier, the consent profile including one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis. The communication manager 1820 may be configured to or otherwise support a component for receiving a request from a second network entity, the request indicating the user identifier and requesting an access level for a data provider corresponding to at least one of the one or more consent types. The communication manager 1820 may be configured to or otherwise support a component for sending a response indicating an access level to the second network entity based on the request and one or more consent parameters for at least one consent type.

[0283] Additionally or alternatively, according to examples as disclosed herein, the communication manager 1820 may support wireless communications at the first network entity. For example, the communication manager 1820 may be configured to or otherwise support a component for receiving a consent profile registration request identifying a user identifier from a UE. The communication manager 1820 may be configured to or otherwise support a component for receiving a consent profile from the UE based on the consent profile registration request, the consent profile including one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis. The communication manager 1820 may be configured to or otherwise support a component for sending a consent profile to a second network entity.

[0284] Additionally or alternatively, according to examples as disclosed herein, the communication manager 1820 may support wireless communications at the first network entity. For example, the communication manager 1820 may be configured to or otherwise support a component for receiving a first request from a data provider requesting access to data associated with a user identifier, the data provider corresponding to at least one of the one or more consent types for the user identifier. The communication manager 1820 may be configured to or otherwise support a component for sending a second request to a second network entity, the second request indicating the user identifier and requesting an access level for the data provider. The communication manager 1820 may be configured to or otherwise support a component for receiving a first response from the second network entity indicating an access level. The communication manager 1820 may be configured to or otherwise support a component for sending a second response to the data provider indicating an access level.

[0285] By including or configuring a communications manager 1820 according to examples as described herein, device 1805 may support technology for a consent platform implemented within a wireless communications system that provides or otherwise supports granular end-user configuration of consent profiles for end users on at least a per-end-user basis (e.g., rather than solely on a per-subscription basis).

[0286] In some examples, the communication manager 1820 may be configured to perform various operations (e.g., receive, obtain, monitor, output, transmit) using or otherwise cooperating with the transceiver 1810, one or more antennas 1815 (e.g., where applicable), or any combination thereof. Although the communication manager 1820 is illustrated as a separate component, in some examples, one or more functions described with reference to the communication manager 1820 may be supported or performed by the processor 1835, the memory 1825, the code 1830, the transceiver 1810, or any combination thereof. For example, the code 1830 may include instructions executable by the processor 1835 to cause the device 1805 to perform various aspects of the consent management procedures as described herein, or the processor 1835 and the memory 1825 may be otherwise configured to perform or support such operations.

[0287] Fig.19 Block diagram 1900 of a device 1905 supporting consent management procedures according to one or more aspects of the present disclosure is shown. The device 1905 can be an example of aspects of the UE 115 as described herein. The device 1905 may include a receiver 1910, a transmitter 1915, and a communication manager 1920. The device 1905 may also include a processor. Each of these components may communicate with each other (e.g., via one or more buses).

[0288] The receiver 1910 may provide means for receiving information such as packets associated with various information channels (e.g., control channels, data channels, information channels related to consent management procedures), user data, control information, or any combination thereof. The information may be communicated to other components of the device 1905. The receiver 1910 may utilize a single antenna or a set of multiple antennas.

[0289] The transmitter 1915 may provide means for transmitting signals generated by other components of the device 1905. For example, the transmitter 1915 may transmit information such as packets associated with various information channels (e.g., control channels, data channels, information channels related to consent management procedures), user data, control information, or any combination thereof. In some examples, the transmitter 1915 may be co-located with the receiver 1910 in a transceiver module. The transmitter 1915 may utilize a single antenna or a set of multiple antennas.

[0290] The communication manager 1920, the receiver 1910, the transmitter 1915, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the consent management procedures as described herein. For example, the communication manager 1920, the receiver 1910, the transmitter 1915, or various combinations thereof or components thereof may support methods for performing one or more of the functions described herein.

[0291] In some examples, the communication manager 1920, the receiver 1910, the transmitter 1915, or various combinations or components thereof may be implemented in hardware (e.g., in a communication management circuit). The hardware may include a processor, a digital signal processor (DSP), a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a microcontroller, discrete gate or transistor logic, discrete hardware components, or any combination thereof that is configured as or otherwise supports means for performing the functions described in the present disclosure. In some examples, the processor and a memory coupled to the processor may be configured to perform one or more of the functions described herein (e.g., by executing instructions stored in the memory by the processor).

[0292] Additionally or alternatively, in some examples, the communication manager 1920, the receiver 1910, the transmitter 1915, or various combinations or components thereof may be implemented in code executed by a processor (e.g., as communication management software or firmware). If implemented in code executed by a processor, the functionality of the communication manager 1920, the receiver 1910, the transmitter 1915, or various combinations or components thereof may be performed by a general purpose processor (e.g., configured as or otherwise supporting means for performing the functionality described in the present disclosure), a DSP, a CPU, an ASIC, an FPGA, a microcontroller, or any combination of these or other programmable logic devices.

[0293] In some examples, communication manager 1920 may be configured to perform various operations (e.g., receive, obtain, monitor, output, send) using or otherwise cooperating with receiver 1910, transmitter 1915, or both. For example, communication manager 1920 may receive information from receiver 1910, transmit information to transmitter 1915, or be integrated in conjunction with receiver 1910, transmitter 1915, or both to obtain information, output information, or perform various other operations as described herein.

[0294] According to examples as disclosed herein, the communication manager 1920 may support wireless communications at the UE. For example, the communication manager 1920 may be configured to or otherwise support a component for sending a consent profile registration request to a network entity, the consent profile registration request identifying a user identifier. The communication manager 1920 may be configured to or otherwise support a component for sending a consent profile to the network entity based on the consent profile registration request, the consent profile including one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis.

[0295] By including or configuring a communications manager 1920 according to examples as described herein, a device 1905 (e.g., a processor controlling or otherwise coupled to a receiver 1910, a transmitter 1915, a communications manager 1920, or a combination thereof) may support technology for a consent platform implemented within a wireless communications system that provides or otherwise supports granular end-user configuration of consent profiles for end users on at least a per-end-user basis (e.g., rather than solely on a per-subscription basis).

[0296] Fig. 20 A block diagram 2000 of a device 2005 supporting consent management procedures according to one or more aspects of the present disclosure is shown. The device 2005 can be an example of aspects of the device 1905 or UE 115 as described herein. The device 2005 may include a receiver 2010, a transmitter 2015, and a communication manager 2020. The device 2005 may also include a processor. Each of these components may communicate with each other (e.g., via one or more buses).

[0297] The receiver 2010 may provide means for receiving information such as packets associated with various information channels (e.g., control channels, data channels, information channels related to consent management procedures), user data, control information, or any combination thereof. The information may be communicated to other components of the device 2005. The receiver 2010 may utilize a single antenna or a set of multiple antennas.

[0298] The transmitter 2015 may provide means for transmitting signals generated by other components of the device 2005. For example, the transmitter 2015 may transmit information such as packets associated with various information channels (e.g., control channels, data channels, information channels related to consent management procedures), user data, control information, or any combination thereof. In some examples, the transmitter 2015 may be co-located with the receiver 2010 in a transceiver module. The transmitter 2015 may utilize a single antenna or a set of multiple antennas.

[0299] Device 2005 or its various components may be examples of components for performing various aspects of the consent management procedures as described herein. For example, communication manager 2020 may include DGC manager 2025 or any combination thereof. Communication manager 2020 may be examples of various aspects of communication manager 1920 as described herein. In some examples, communication manager 2020 or its various components may be configured to perform various operations (e.g., receive, obtain, monitor, output, send) using or otherwise in conjunction with receiver 2010, transmitter 2015, or both. For example, communication manager 2020 may receive information from receiver 2010, transmit information to transmitter 2015, or be integrated in combination with receiver 2010, transmitter 2015, or both to obtain information, output information, or perform various other operations as described herein.

[0300] According to examples as disclosed herein, the communication manager 2020 may support wireless communications at the UE. The DGC manager 2025 may be configured to or otherwise support a component for sending a consent profile registration request to a network entity, the consent profile registration request identifying a user identifier. The DGC manager 2025 may be configured to or otherwise support a component for sending a consent profile to the network entity based on the consent profile registration request, the consent profile including one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis.

[0301] Fig.21 Block diagram 2100 of a communication manager 2120 supporting a consent management procedure in accordance with one or more aspects of the present disclosure is shown. The communication manager 2120 can be an example of the communication manager 1920, the communication manager 2020, or aspects of both as described herein. The communication manager 2120, or its various components, can be examples of components for performing various aspects of the consent management procedure as described herein. For example, the communication manager 2120 can include a DGC manager 2125, a query manager 2130, an update manager 2135, or any combination thereof. Each of these components can communicate with each other directly or indirectly (e.g., via one or more buses).

[0302] According to examples as disclosed herein, the communication manager 2120 may support wireless communications at the UE. The DGC manager 2125 may be configured to or otherwise support a component for sending a consent profile registration request to a network entity, the consent profile registration request identifying a user identifier. In some examples, the DGC manager 2125 may be configured to or otherwise support a component for sending a consent profile to the network entity based on the consent profile registration request, the consent profile including one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis.

[0303] In some examples, query manager 2130 may be configured or otherwise support means for sending a data collection query to a network entity, the data collection query requesting a data access state associated with a consent profile. In some examples, query manager 2130 may be configured or otherwise support means for receiving a data collection response from the network entity based on the data collection query, the data collection response identifying a data provider that accesses data associated with the consent profile.

[0304] In some examples, update manager 2135 may be configured or otherwise support means for sending an update message identifying updated parameters of at least one of the one or more consent types to a network entity. In some examples, update manager 2135 may be configured or otherwise support means for receiving a confirmation message from the network entity confirming the update of the updated parameters of the at least one consent type based on the update message.

[0305] Fig. 22 A diagram of a system 2200 including a device 2205 supporting consent management procedures according to one or more aspects of the present disclosure is shown. The device 2205 may be an example of a device 1905, a device 2005, or a UE 115 as described herein, or include components of these devices. The device 2205 may communicate (e.g., wirelessly) with one or more network entities 105, one or more UEs 115, or any combination thereof. The device 2205 may include components for two-way voice and data communications, including components for sending and receiving communications, such as a communication manager 2220, an input / output (I / O) controller 2210, a transceiver 2215, an antenna 2225, a memory 2230, a code 2235, and a processor 2240. These components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more buses (e.g., a bus 2245).

[0306] I / O controller 2210 can manage input and output signals for device 2205. I / O controller 2210 can also manage peripheral devices that are not integrated into device 2205. In some cases, I / O controller 2210 can represent a physical connection or port to an external peripheral device. In some cases, I / O controller 2210 can utilize an operating system such as or another known operating system. Additionally or alternatively, I / O controller 2210 may represent or interact with a modem, keyboard, mouse, touch screen, or similar device. In some cases, I / O controller 2210 may be implemented as part of a processor, such as processor 2240. In some cases, a user may interact with device 2205 via I / O controller 2210 or via hardware components controlled by I / O controller 2210.

[0307] In some cases, the device 2205 may include a single antenna 2225. However, in some other cases, the device 2205 may have more than one antenna 2225, which may be capable of concurrently sending or receiving multiple wireless transmissions. The transceiver 2215 may communicate bidirectionally via one or more antennas 2225, a wired link, or a wireless link as described herein. For example, the transceiver 2215 may represent a wireless transceiver and may communicate bidirectionally with another wireless transceiver. The transceiver 2215 may also include a modem for modulating packets, providing the modulated packets to one or more antennas 2225 for transmission, and for demodulating packets received from one or more antennas 2225. The transceiver 2215, or the transceiver 2215 and one or more antennas 2225 may be examples of transmitters 1915, transmitters 2015, receivers 1910, receivers 2010, or any combination thereof or any components thereof as described herein.

[0308] The memory 2230 may include random access memory (RAM) and read-only memory (ROM). The memory 2230 may store computer-readable, computer-executable code 2235 including instructions that, when executed by the processor 2240, cause the device 2205 to perform various functions described herein. The code 2235 may be stored in a non-transitory computer-readable medium (such as system memory or another type of memory). In some cases, the code 2235 may not be directly executable by the processor 2240, but may (e.g., when compiled and executed) cause the computer to perform the functions described herein. In some cases, the memory 2230 may include, among other things, a basic I / O system (BIOS) that may control basic hardware or software operations, such as interaction with peripheral components or devices.

[0309] The processor 2240 may include an intelligent hardware device (e.g., a general-purpose processor, a DSP, a CPU, a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof). In some cases, the processor 2240 may be configured to operate a memory array using a memory controller. In some other cases, the memory controller may be integrated into the processor 2240. The processor 2240 may be configured to execute computer-readable instructions stored in a memory (e.g., memory 2230) so that the device 2205 performs various functions (e.g., functions or tasks that support consent management procedures). For example, the device 2205 or a component of the device 2205 may include a processor 2240 and a memory 2230 coupled to or coupled to the processor 2240, and the processor 2240 and the memory 2230 are configured to perform the various functions described herein.

[0310] According to examples as disclosed herein, the communication manager 2220 may support wireless communications at the UE. For example, the communication manager 2220 may be configured to or otherwise support a component for sending a consent profile registration request to a network entity, the consent profile registration request identifying a user identifier. The communication manager 2220 may be configured to or otherwise support a component for sending a consent profile to the network entity based on the consent profile registration request, the consent profile including one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis.

[0311] By including or configuring a communications manager 2220 according to examples as described herein, the device 2205 may support technology for a consent platform implemented within a wireless communications system that provides or otherwise supports granular end-user configuration of consent profiles for end users on at least a per-end-user basis (e.g., rather than solely on a per-subscription basis).

[0312] In some examples, the communication manager 2220 may be configured to perform various operations (e.g., receive, monitor, transmit) using or otherwise cooperating with the transceiver 2215, one or more antennas 2225, or any combination thereof. Although the communication manager 2220 is illustrated as a separate component, in some examples, one or more functions described with reference to the communication manager 2220 may be supported or performed by the processor 2240, the memory 2230, the code 2235, or any combination thereof. For example, the code 2235 may include instructions executable by the processor 2240 to cause the device 2205 to perform various aspects of the consent management procedures as described herein, or the processor 2240 and the memory 2230 may be otherwise configured to perform or support such operations.

[0313] Fig.23 2300 is a flowchart illustrating a method 2300 for supporting a consent management procedure according to one or more aspects of the present disclosure. The operations of the method 2300 may be implemented by a network entity or a component thereof as described herein. For example, the operations of the method 2300 may be implemented by a network entity or a component thereof as described herein. Figures 1 to 18 In some examples, the network entity may execute an instruction set to control the functional elements of the network entity to perform the described functions. Additionally or alternatively, the network entity may use dedicated hardware to perform various aspects of the described functions.

[0314] At 2305, the method may include identifying a consent profile for the user identifier, the consent profile including one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis. The operations of 2305 may be performed according to examples as disclosed herein. In some examples, aspects of the operations of 2305 may be performed as described in reference to Fig.17 The (E)UDM manager 1725 described above is used to perform the above operations.

[0315] At 2310, the method may include receiving a request from a second network entity, the request indicating a user identifier and requesting an access level for a data provider corresponding to at least one of the one or more consent types. The operations of 2310 may be performed according to examples as disclosed herein. In some examples, aspects of the operations of 2310 may be performed as described in reference to Fig.17 The (E)UDM manager 1725 described above is used to perform the above operations.

[0316] At 2315, the method may include sending a response indicating an access level to the second network entity based on the request and one or more consent parameters of at least one consent type. The operations of 2315 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2315 may be performed as described in reference to Fig.17 The described (E)UDM manager 1725 is executed.

[0317] Fig.24 2400 is a flowchart illustrating a method 2400 for supporting a consent management procedure according to one or more aspects of the present disclosure. The operations of the method 2400 may be implemented by a network entity or a component thereof as described herein. For example, the operations of the method 2400 may be implemented by a network entity or a component thereof as described herein. Figures 1 to 18 In some examples, the network entity may execute an instruction set to control the functional elements of the network entity to perform the described functions. Additionally or alternatively, the network entity may use dedicated hardware to perform various aspects of the described functions.

[0318] At 2405, the method may include receiving a consent profile registration request from the UE identifying a user identifier. The operations of 2405 may be performed according to examples as disclosed herein. In some examples, aspects of the operations of 2405 may be performed as described in reference to Fig.17 The described DGS manager 1730 is executed.

[0319] At 2410, the method may include receiving a consent profile from the UE based on the consent profile registration request, the consent profile including one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis. The operations of 2410 may be performed according to examples as disclosed herein. In some examples, aspects of the operations of 2410 may be performed as described in reference to Fig.17 The described DGS manager 1730 is executed.

[0320] At 2415, the method may include sending a consent profile to the second network entity. The operations of 2415 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2415 may be performed as described in reference to Fig.17 The described DGS manager 1730 is executed.

[0321] Fig.25 2500 is a flowchart illustrating a method 2500 for supporting consent management procedures according to one or more aspects of the present disclosure. The operations of the method 2500 may be implemented by a UE or a component thereof as described herein. For example, the operations of the method 2500 may be implemented by a UE or a component thereof as described in reference to Figures 1 to 14 and Figures 19 to 22 The described UE 115 may be performed. In some examples, the UE may execute an instruction set to control the functional elements of the UE to perform the described functions. Additionally or alternatively, the UE may use dedicated hardware to perform various aspects of the described functions.

[0322] At 2505, the method may include sending a consent profile registration request to a network entity, the consent profile registration request identifying a user identifier. The operations of 2505 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2505 may be performed as described in reference to Fig.21 The described DGC manager 2125 is executed.

[0323] At 2510, the method may include sending a consent profile to a network entity based on the consent profile registration request, the consent profile including one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis. The operations of 2510 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2510 may be performed as described in reference to Fig.21 The described DGC manager 2125 is executed.

[0324] Fig.26 2600 is a flowchart illustrating a method 2600 for supporting consent management procedures according to one or more aspects of the present disclosure. The operations of the method 2600 may be implemented by a network entity or a component thereof as described herein. For example, the operations of the method 2600 may be implemented by a network entity or a component thereof as described herein. Figures 1 to 18 In some examples, the network entity may execute an instruction set to control the functional elements of the network entity to perform the described functions. Additionally or alternatively, the network entity may use dedicated hardware to perform various aspects of the described functions.

[0325] At 2605, the method may include receiving a first request from a data provider requesting access to data associated with a user identifier, the data provider corresponding to at least one of the one or more consent types for the user identifier. The operations of 2605 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2605 may be performed as described in reference to Fig.17 The described CMF manager 1735 is executed.

[0326] At 2610, the method may include sending a second request to a second network entity, the second request indicating a user identifier and requesting an access level for a data provider. The operations of 2610 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2610 may be performed as described in reference to Fig.17 The described CMF manager 1735 is executed.

[0327] At 2615, the method may include receiving a first response from the second network entity indicating the access level. The operations of 2615 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2615 may be performed as described in reference to Fig.17 The described CMF manager 1735 is executed.

[0328] At 2620, the method may include sending a second response to the data provider indicating the access level. The operations of 2620 may be performed according to examples disclosed herein. In some examples, aspects of the operations of 2620 may be performed as described in reference to Fig.17The described CMF manager 1735 is executed.

[0329] The following provides an overview of various aspects of the disclosure:

[0330] Aspect 1: A method for wireless communication at a first network entity, comprising: identifying a consent profile for a user ID, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID on at least a per-user basis; receiving a request from a second network entity, the request indicating the user ID and requesting an access level for a data provider corresponding to at least one of the one or more consent types; and sending a response indicating the access level to the second network entity based at least in part on the request and the one or more consent parameters of the at least one consent type.

[0331] Aspect 2: The method according to aspect 1, further comprising: storing the consent profile and the subscription ID of the user ID in a UDM entity, wherein the first network entity comprises the UDM entity.

[0332] Aspect 3: The method according to any one of Aspects 1 to 2 further includes: storing the subscription ID of the user ID in a UDM entity and storing the consent profile of the user ID in an end-user UDM entity, wherein the first network entity includes the end-user UDM entity.

[0333] Aspect 4: The method according to any one of Aspects 1 to 3 further includes: receiving a consent profile ID from a third network entity associated with the first network entity, wherein the consent profile identifying the user ID is at least partially based on receiving the consent profile ID.

[0334] Aspect 5: The method according to aspect 4, wherein the consent profile ID maps the consent profile to the user associated with the user ID at the UE.

[0335] Aspect 6: The method according to any one of Aspects 1 to 5 further includes: receiving an update message identifying updated parameters of at least one of the one or more consent types; and updating the one or more consent parameters of at least one consent type of the consent profile based at least in part on the update message.

[0336] Aspect 7: The method according to aspect 6, wherein the update message is received from a third network entity or a UE associated with the consent profile ID of the consent profile.

[0337] Aspect 8: The method according to any one of Aspects 1 to 7 further includes: receiving an update message identifying an updated terminal user device associated with the user ID from the second network entity; and updating the one or more consent parameters of the user ID to include the updated terminal user device based at least in part on the update message.

[0338] Aspect 9: The method according to any one of aspects 1 to 8, wherein the subscription ID associated with the user ID comprises a fifth generation subscription permanent ID.

[0339] Aspect 10: The method according to any one of aspects 1 to 9, wherein the subscription ID associated with the user ID comprises a universal public subscription ID.

[0340] Aspect 11: The method according to any one of aspects 1 to 10, wherein the user ID is associated with a subscription ID, a consent profile ID, or both.

[0341] Aspect 12: The method of any one of Aspects 1 to 11, wherein the consent profile and the consent profile ID of the consent profile are determined based at least in part on a result of a FIDO authentication procedure for a user associated with the user ID.

[0342] Aspect 13: A method for wireless communication at a first network entity, comprising: receiving a consent profile registration request identifying a user ID from a UE; receiving a consent profile from the UE based at least in part on the consent profile registration request, the consent profile comprising one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID at least on a per-user basis; and sending the consent profile to a second network entity.

[0343] Aspect 14: The method according to Aspect 13 also includes: receiving a data collection query from the UE, the data collection query requesting a data access status associated with a user, the user being associated with a consent profile ID of the consent profile; sending the data collection query and the user ID to a third network entity; receiving a data collection response from the third network entity based at least in part on the data collection query and the user ID, the data collection response identifying a data provider that accesses data associated with the consent profile; and sending the data collection response to the UE based at least in part on the data collection query.

[0344] Aspect 15: A method for performing wireless communications at a UE, comprising: sending a consent profile registration request to a network entity, the consent profile registration request identifying a user ID; and sending a consent profile to the network entity based at least in part on the consent profile registration request, the consent profile including one or more consent types for the user ID, the one or more consent types configuring one or more consent parameters for the user ID at least on a per-user basis.

[0345] Aspect 16: The method according to Aspect 15 also includes: sending a data collection query to the network entity, the data collection query requesting a data access status associated with the consent profile; and receiving a data collection response from the network entity based at least in part on the data collection query, the data collection response identifying a data provider that accesses the data associated with the consent profile.

[0346] Aspect 17: The method according to any one of Aspects 15 to 16 further includes: sending an update message identifying updated parameters of at least one of the one or more consent types to the network entity; and receiving a confirmation message confirming the update of the updated parameters of the at least one consent type from the network entity based at least in part on the update message.

[0347] Aspect 18: A method for wireless communication at a first network entity, comprising: receiving a first request from a data provider requesting access to data associated with a user ID, the data provider corresponding to at least one of one or more consent types of the user ID; sending a second request to a second network entity, the second request indicating the user ID and requesting an access level of the data provider; receiving a first response from the second network entity indicating the access level; and sending a second response to the data provider indicating the access level.

[0348] Aspect 19: The method according to Aspect 18 also includes: sending an indication to the data provider to grant access to at least a portion of the data associated with the user ID based at least in part on the second response, wherein at least the portion of the data is based at least in part on the access level.

[0349] Aspect 20: The method according to any one of Aspects 18 to 19 further includes: receiving an access level request for data associated with at least one consent type of the user ID from a second data provider; and sending an access level response to the second data provider indicating a second access level of the second data provider.

[0350] Aspect 21: The method according to any one of Aspects 18 to 20 further includes: identifying a group of one or more data consumers who access data associated with the user ID based on the one or more consent types of the user ID.

[0351] Aspect 22: The method according to any one of Aspects 18 to 21 further includes: receiving a deactivation request for a subset of the one or more consent types for the user ID from the data provider; and updating the access level of the data provider to a deactivated state based at least in part on the deactivation request.

[0352] Aspect 23: The method according to any one of Aspects 18 to 22 further includes: receiving a revocation request for a subset of the one or more consent types for the user ID from the second network entity; and updating the access level associated with the subset of the one or more consent types to a revoked state based at least in part on the revocation request.

[0353] Aspect 24: The method according to any one of Aspects 18 to 23 further includes: receiving a dynamic access request message from the data provider requesting access to a portion of the data associated with the user ID; sending the dynamic access request message to the second network entity, the dynamic access request message identifying the portion of the data associated with the user ID and at least one of the one or more consent types; receiving a dynamic access response from the second network entity, the dynamic access response authorizing or denying access to the portion of the data associated with the user ID; and sending the dynamic access response to the data provider.

[0354] Aspect 25: An apparatus for wireless communication at a first network entity, comprising: a processor; a memory coupled to the processor; and instructions stored in the memory and executable by the processor to cause the apparatus to perform a method according to any one of Aspects 1 to 12.

[0355] Aspect 26: An apparatus for wireless communication at a first network entity, comprising at least one means for performing the method according to any one of aspects 1 to 12.

[0356] Aspect 27: A non-transitory computer-readable medium storing code for wireless communication at a first network entity, the code comprising instructions executable by a processor to perform the method according to any one of aspects 1 to 12.

[0357] Aspect 28: An apparatus for wireless communication at a first network entity, comprising: a processor; a memory coupled to the processor; and instructions stored in the memory and executable by the processor to cause the apparatus to perform a method according to any one of Aspects 13 to 14.

[0358] Aspect 29: An apparatus for wireless communication at a first network entity, comprising at least one means for performing the method according to any one of aspects 13 to 14.

[0359] Aspect 30: A non-transitory computer-readable medium storing code for wireless communication at a first network entity, the code comprising instructions executable by a processor to perform the method according to any one of aspects 13 to 14.

[0360] Aspect 31: An apparatus for performing wireless communication at a UE, comprising: a processor; a memory coupled to the processor; and instructions stored in the memory and executable by the processor to cause the apparatus to perform a method according to any one of Aspects 15 to 17.

[0361] Aspect 32: An apparatus for wireless communication at a UE, comprising at least one means for performing a method according to any one of aspects 15 to 17.

[0362] Aspect 33: A non-transitory computer-readable medium storing a code for wireless communication at a UE, the code comprising instructions executable by a processor to perform a method according to any one of aspects 15 to 17.

[0363] Aspect 34: An apparatus for wireless communication at a first network entity, comprising: a processor; a memory coupled to the processor; and instructions stored in the memory and executable by the processor to cause the apparatus to perform a method according to any one of Aspects 18 to 24.

[0364] Aspect 35: An apparatus for wireless communication at a first network entity, comprising at least one means for performing a method according to any one of aspects 18 to 24.

[0365] Aspect 36: A non-transitory computer-readable medium storing code for wireless communication at a first network entity, the code comprising instructions executable by a processor to perform the method according to any one of aspects 18 to 24.

[0366] It should be noted that the methods described herein describe possible implementations, and that the operations and steps may be rearranged or otherwise modified and that other implementations are possible. Furthermore, aspects from two or more methods may be combined.

[0367] Although aspects of LTE, LTE-A, LTE-A Pro, or NR systems may be described for example purposes, and LTE, LTE-A, LTE-A Pro, or NR terminology may be used in much of the description, the techniques described herein may also be applicable to networks other than LTE, LTE-A, LTE-A Pro, or NR networks. For example, the described techniques may be applicable to various other wireless communication systems, such as Ultra Mobile Broadband (UMB), Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM, and other systems and radio technologies not explicitly mentioned herein.

[0368] The information and signals described herein may be represented using any of a variety of different technologies and methods. For example, data, instructions, commands, information, signals, bits, symbols, and chips mentioned throughout the specification may be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or optical particles, or any combination thereof.

[0369] The various illustrative blocks and components described in conjunction with the disclosure herein may be implemented or performed with a general purpose processor, DSP, ASIC, CPU, FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in an alternative, the processor may be any processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration).

[0370] The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored as one or more instructions or codes on a computer-readable medium, or sent via a computer-readable medium. Other examples and specific implementations are within the scope of this disclosure and the appended claims. For example, due to the nature of software, the functions described herein may be implemented using software executed by a processor, hardware, firmware, hard wiring, or a combination of any of these items. Features that implement the functions may also be physically located at different locations, including being distributed so that the functions are implemented at different physical locations.

[0371] Computer-readable medium includes both non-transient computer storage medium and communication medium, including any medium that facilitates computer program to be transmitted from one place to another.Non-transient storage medium can be any available medium that can be accessed by general or special-purpose computer.In an example and not limiting manner, non-transient computer-readable medium may include RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory, compact disc (CD) ROM or other optical disc storage, disk storage or other magnetic storage device, or can be used to carry or store desired program code components and can be accessed by general or special-purpose computer or general or special-purpose processor in the form of instruction or data structure Any other non-transient medium.Moreover, any connection is appropriately referred to as computer-readable medium.For example, if software is sent from website, server or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL) or wireless technology such as infrared, radio and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL or wireless technology such as infrared, radio and microwave are included in the definition of computer-readable medium. Disk and disc, as used herein, includes CD, laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of computer-readable media.

[0372] As used herein (including in the claims), "or" used in a list of items (e.g., a list of items with a phrase such as "at least one of" or "one or more of") indicates an inclusive list, so that, for example, a list of at least one of A, B, or C means A or B or C or AB or AC or BC or ABC (i.e., A and B and C). In addition, as used herein, the phrase "based on" should not be interpreted as a reference to a closed set of conditions. For example, an example step described as "based on condition A" can be based on condition A and condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase "based on" should be interpreted in the same manner as the phrase "based at least in part on."

[0373] The term "determining" encompasses a variety of actions, and thus, "determining" may include calculating, computing, processing, deriving, investigating, looking up (such as via looking up in a table, database, or other data structure), ascertaining, etc. Additionally, "determining" may include receiving (such as receiving information), accessing (such as accessing data in a memory), and similar actions. Additionally, "determining" may include resolving, obtaining, selecting, choosing, establishing, and other such similar actions.

[0374] In the drawings, similar components or features may have the same reference label. In addition, various components of the same type may be distinguished by following the reference label with a dash and a second label to distinguish between similar components. If only the first reference label is used in the specification, the description may apply to any of the similar components having the same first reference label regardless of the second reference label, or other subsequent reference labels.

[0375] The descriptions set forth herein in conjunction with the accompanying drawings describe example configurations and do not represent all examples that may be implemented or within the scope of the claims. The term "example" as used herein means "used as an example, instance, or illustration," rather than "preferred" or "having advantages over other examples." The specific embodiments include specific details to provide an understanding of the described technology. However, these technologies may be practiced without these specific details. In some instances, known structures and devices are shown in block diagram form to avoid obscuring the concepts of the described examples.

[0376] The description herein is provided to enable one of ordinary skill in the art to implement or use the present disclosure. Various modifications to the present disclosure will be apparent to one of ordinary skill in the art, and the general principles defined herein may be applied to other variations without departing from the scope of the present disclosure. Thus, the present disclosure is not limited to the examples and designs described herein, but should be granted the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for wireless communication at a first network entity, comprising: identifying a consent profile for a user identifier, the consent profile comprising one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis; receiving a request from a second network entity, the request indicating the user identifier and requesting an access level for a data provider corresponding to at least one of the one or more consent types; as well as A response indicating the access level is sent to the second network entity based at least in part on the request and the one or more consent parameters of the at least one consent type.

2. The method according to claim 1, further comprising: The consent profile and a subscription identifier of the user identifier are stored in a unified data management entity, wherein the first network entity comprises the unified data management entity.

3. The method according to claim 1, further comprising: A subscription identifier for the user identifier is stored in a unified data management entity and the consent profile for the user identifier is stored in an end-user unified data management entity, wherein the first network entity comprises the end-user unified data management entity.

4. The method according to claim 1, further comprising: A consent profile identifier is received from a third network entity associated with the first network entity, wherein the consent profile identifying the user identifier is based at least in part on receiving the consent profile identifier. 5 . The method of claim 4 , wherein the consent profile identifier maps the consent profile to a user associated with the user identifier at a user equipment (UE).

6. The method according to claim 1, further comprising: receiving an update message identifying updated parameters of at least one of the one or more consent types; as well as The one or more consent parameters of at least one consent type of the consent profile are updated based at least in part on the update message.

7. The method of claim 6, wherein the update message is received from a third network entity or a user equipment (UE) associated with a consent profile identifier of the consent profile.

8. The method according to claim 1, further comprising: receiving, from the second network entity, an update message identifying an updated end-user device associated with the user identifier; as well as The one or more consent parameters of the user identifier are updated based at least in part on the update message to include the updated end-user device.

9. The method of claim 1, wherein the subscription identifier associated with the user identifier comprises a fifth generation subscription permanent identifier.

10. The method of claim 1, wherein the subscription identifier associated with the user identifier comprises a universal public subscription identifier.

11. The method of claim 1 , wherein the user identifier is associated with a subscription identifier, a consent profile identifier, or both.

12. The method of claim 1, wherein the consent profile and the consent profile identifier of the consent profile are determined based at least in part on results of a Fast Identity Online (FIDO) authentication procedure for a user associated with the user identifier.

13. A method for wireless communication at a first network entity, comprising: receiving a consent profile registration request identifying a user identifier from a user equipment (UE); receiving a consent profile from the UE based at least in part on the consent profile registration request, the consent profile comprising one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis; as well as The consent configuration file is sent to the second network entity.

14. The method according to claim 13, further comprising: receiving, from the UE, a data collection query requesting a data access status associated with a user associated with a consent profile identifier of the consent profile; sending the data collection query and the user identifier to a third network entity; receiving a data collection response from the third network entity based at least in part on the data collection query and the user identifier, the data collection response identifying a data provider that accesses data associated with the consent profile; as well as The data collection response is sent to the UE based at least in part on the data collection query.

15. A method for wireless communication at a user equipment (UE), comprising: sending a consent profile registration request to a network entity, the consent profile registration request identifying a user identifier; as well as A consent profile is sent to the network entity based at least in part on the consent profile registration request, the consent profile comprising one or more consent types for the user identifier, the one or more consent types configuring one or more consent parameters for the user identifier on at least a per-user basis.

16. The method according to claim 15, further comprising: sending a data collection query to the network entity, the data collection query requesting a data access status associated with the consent profile; as well as A data collection response is received from the network entity based at least in part on the data collection query, the data collection response identifying a data provider that accesses data associated with the consent profile.

17. The method according to claim 15, further comprising: sending an update message identifying updated parameters of at least one of the one or more consent types to the network entity; as well as A confirmation message is received from the network entity confirming the updating of the updated parameters of the at least one consent type based at least in part on the update message.

18. A method for wireless communication at a first network entity, comprising: receiving a first request from a data provider requesting access to data associated with a user identifier, the data provider corresponding to at least one of the one or more consent types for the user identifier; sending a second request to a second network entity, the second request indicating the user identifier and requesting an access level for the data provider; receiving a first response from the second network entity indicating the access level; and A second response is sent to the data provider indicating the access level.

19. The method according to claim 18, further comprising: An indication is sent to the data provider based at least in part on the second response to grant access to at least a portion of the data associated with the user identifier, wherein at least the portion of the data is based at least in part on the access level.

20. The method of claim 18, further comprising: receiving, from a second data provider, an access level request for data associated with at least one consent type for the user identifier; as well as An access level response is sent to the second data provider indicating a second access level for the second data provider.

21. The method of claim 18, further comprising: A set of one or more data consumers accessing data associated with the user identifier is identified based on the one or more consent types of the user identifier.

22. The method of claim 18, further comprising: receiving, from the data provider, a deactivation request for a subset of the one or more consent types for the user identifier; as well as The access level of the data provider is updated to a deactivated state based at least in part on the deactivation request.

23. The method of claim 18, further comprising: receiving, from the second network entity, a revocation request for a subset of the one or more consent types for the user identifier; as well as The access level associated with the subset of the one or more consent types is updated to a revoked state based at least in part on the revocation request.

24. The method of claim 18, further comprising: receiving a dynamic access request message from the data provider requesting access to a portion of data associated with the user identifier; sending the dynamic access request message to the second network entity, the dynamic access request message identifying the portion of the data associated with the user identifier and the at least one of the one or more consent types; receiving a dynamic access response from the second network entity, the dynamic access response authorizing or denying access to the portion of the data associated with the user identifier; as well as The dynamic access response is sent to the data provider.

Images