User agreement policy management

Abstract

Methods and apparatus for providing a user agreement policy in a wireless network are disclosed. A method includes a network open function (NEF) receiving a request from an application function (AF) to create or update a user agreement policy for data sharing of a wireless transmit receive unit (WTRU), retrieving user agreement parameters for the WTRU from a unified data management (UDM), and retrieving relevant privacy laws, regulations and / or operator rules (if any) from a unified data store (UDR). The NEF may forward information from the AF, UDR, and UDM to a policy control function (PCF) that creates or updates a user agreement policy for the WTRU based on user agreement (including privacy laws, regulations, and operator rules) as an executable policy that guides sensing data collection, processing, distribution, and redistribution. Other embodiments are also disclosed.

Description

Cross-reference to related applications

[0001] This application claims priority to U.S. Provisional Application No. 63 / 529,289, filed July 27, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] Enhancements to 5G and next-generation systems will provide sensing services for various target verticals and applications, such as autonomous / assisted driving, vehicle-to-everything (V2X), unmanned aerial vehicles (UAVs), 3D map reconstruction, smart cities, smart homes, factories, healthcare, and maritime sectors. Existing mechanisms based on the 3GPP Unified Data Management (UDM) / Unified Data Repository (UDR) do not provide any dynamic, flexible, or detailed control over user consent for sensing based on conditions such as location, time, data collection time, network, consumer information, scope, and combinations thereof. Furthermore, there is currently no system architecture guidance on how to apply laws, local regulations, and / or operator rules when enforcing user consent.

[0003] Network-sensored information should ideally be sent to authorized parties only based on user consent from the sensing device / environment. Sensing data should ideally be protected for confidentiality, integrity, privacy, and replay protection. The collection, transmission, and consumption of sensing data should obtain user consent from the relevant parties and comply with privacy regulations / laws and operator privacy policies. The scope of user consent should allow for specific control over which data, collection time and window, and which parties can receive sensing data, and these parties should be able to withdraw or update user consent. Network elements involved in 3GPP data collection, processing, and release (e.g., Sensor Operation Management Function (SOMF) / Integrated Sensor Auxiliary Network Function (ISANF)) should be able to control the flow of sensing data based on user consent to ensure that data collection, processing, and release are user-authorized and comply with applicable laws and regulations.

[0004] There is a need for methods and systems that: obtain dynamic and flexible user consent; provide detailed control over sensor data streams to collect, process, and / or release sensor results to consumers in accordance with the scope and granularity agreed upon by the user; and have the ability to comply with privacy laws, regulations, and / or operator policies. Summary of the Invention

[0005] The aspects of this disclosure can address one or more of the aforementioned needs through methods and apparatus for one or more of the following aspects as detailed herein: user consent policies, user consent policy management, token-based authorization for redistribution of sensor data based on user consent policies, and integrated sensing and communication embodiments.

[0006] It should be recognized that the various aspects described can be used to control services other than sensor data collection / processing / release, where similar advantages can be obtained. As used herein, the term "function" is used in the context of service-based architecture (SBA) and refers to purpose-based software executing on a processing platform such as a server. Some functions may be grouped together on the same platform or geographically separated, depending on the network design. For example, some functions may be part of the radio access network (RAN), part of the core network (CN), or located externally and accessible by the RAN and / or CN.

[0007] In one aspect, a user registers with an Application Function (AF) carrying user consent information that includes conditions for the collection, processing, and / or release of sensor data. Attributes in these conditions may include the timing of sensor data collection, location validity, permitted networks (e.g., home / visited), sensor data type, accuracy, sensor information receiving application, policy validity period, and permission for redistribution.

[0008] In one aspect, the network AF formulates user consent conditions based on user input and sends these conditions to the User Equipment's (UE) Home Policy Control Function (PCF) and Unified Data Management (UDM) function / service. As used herein, the UE may be alternatively referred to as a Transmitter Receiver Unit (WTRU). The PCF retrieves user consent parameters from the UDM service, combines the conditions with subscription data, and updates the UDM data based on information received from the AF. When formulating the user consent policy, the PCF may also map relevant privacy laws, local regulations, and / or operator rules into the user consent policy. Depending on some aspects, the user consent policy may be stored in the UDM / UDR.

[0009] In some respects, the Sensor Network Function (NF) subscribes to a user consent policy for the WTRU associated with the sensing process. The sensing NF receives the user consent policy and updates from the PCF, and then the NF can control the collection, processing, consumption, and release of sensor data based on this policy.

[0010] In one aspect, when the redistribution of sensor data is permitted, the user consents that the controller can issue authorization tokens based on a policy that enables the next-hop consumer to receive sensor information from the first-hop consumer.

[0011] In some respects, the WTRU can update or invoke user consent at the AF at any time. The AF will update the policy in the PCF, and the PCF will then notify the sensing NF of the updated user consent policy.

[0012] Depending on the context, when the WTRU is in the visited network, the policy framework should send a request to the roaming network, and the control NF is used to enforce the relevant sensor data collection, processing, and / or release.

[0013] As part of user consent policy management, the Network Open Function (NEF) receives requests from the AF to create or update user consent policies for one or more WTRUs (including user consent attributes for each sensor data type, such as collection, processing, release, or combinations thereof). The NEF interacts with the UDM service / function to store, update, and / or retrieve user consent parameters in the UDM, and with the UDR to retrieve relevant privacy laws, regulations, and / or operator rules. The NEF sends information received from the AF, UDR, and UDM to the PCF so that the PCF can develop a user consent policy as a final, enforceable policy that guides the collection, processing, distribution, and redistribution of sensor data based on user consent and privacy laws / regulations / operator rules. The NEF can send the user consent policy back to the WTRU via the AF or through the PCF platform.

[0014] In another exemplary embodiment, the user data redistribution authorization token can be based on a user consent policy. The sensor control NF (e.g., ISANF / SOMF) receives a request for sensor data redistribution, consults the user consent policy to see if redistribution is permitted, requests an authorization token on behalf of the next-hop consumer, and receives the requested token with a requested scope and statement for the next-hop consumer to request the redistribution of sensor data. The authorization token, along with the scope (e.g., information ID, recipient, granularity, accuracy, validity period, etc.), is passed back to the next-hop consumer.

[0015] In one optional aspect, the WTRU may explicitly request the user's consent for the redistribution of information related to the WTRU. The WTRU may request an authorization token from the Authorization Server (AS) on behalf of the next-hop consumer for authorization. When the WTRU receives an authorization token from the AS authorizing the next-hop consumer to receive sensor data or sensor data-derived information, the WTRU sends the token to the next-hop consumer. Other aspects, features, and embodiments will be disclosed in further detail below. Attached Figure Description

[0016] A more detailed understanding can be obtained from the following description, exemplarily given in conjunction with the accompanying drawings, in which the same reference numerals denote the same elements, and wherein: Figure 1A This is a system diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments; Figure 1B It is shown that, according to the embodiment, it is possible to Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used in the communication system shown; Figure 1C It is shown that, according to the embodiment, it is possible to Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used in the communication system shown; Figure 1D It is shown that, according to the embodiments, it is possible to Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in the communication system shown; Figure 2 This is an exemplary reference model diagram of 5G / next-generation networks; Figure 3 This is a signaling sequence diagram of a user consent policy management method according to an exemplary embodiment; Figure 4 This is a signaling sequence diagram of a user consent policy update method according to an exemplary embodiment; Figure 5 This is a network function diagram of a user consent policy enforcement method according to an exemplary embodiment; Figure 6 This is a network functional diagram of the sensor data redistribution authorization method according to an embodiment; Figure 7 This is a flowchart detailing a method for managing user consent policies according to exemplary embodiments; and Figure 8 This is a flowchart detailing a method for redistributing authorization tokens based on user consent policies, according to an exemplary embodiment. Detailed Implementation

[0017] Figure 1A This is a schematic diagram illustrating an exemplary communication system 100 that can implement one or more of the disclosed embodiments. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 allows multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), Zero-Tail Unique Word Discrete Fourier Transform Spread Spectrum OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0018] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each WTRU 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0019] The communication system 100 may also include base station 114a and / or base station 114b. Each base station 114a, 114b may be any type of device configured to interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks (e.g., CN 106, Internet 110, and / or other networks 112). For example, base stations 114a, 114b may be base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home NodeBs, home eNodeBs, next-generation NodeBs (e.g., gNodeBs (gNBs)), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a, 114b are each depicted as a single element, it should be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0020] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide radio service coverage for a specific geographic area, which may be relatively fixed or change over time. A cell may also be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one for each cell sector. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in the desired spatial orientation.

[0021] Base stations 114a and 114b can communicate with one or more WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

[0022] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish an air interface 116 using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink (UL) Packet Access (HSUPA).

[0023] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0024] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0025] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can simultaneously implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions to / from multiple types of base stations (e.g., eNBs and gNBs).

[0026] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Evolution Enhanced Data Rate (EDGE), and GSM EDGE (GERAN).

[0027] Figure 1ABase station 114b can be a wireless router, home Node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area (e.g., business premises, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, etc.). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b may not need to access Internet 110 through CN 106.

[0028] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, mobile location services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although... Figure 1A As not shown, but it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to connecting to RAN 104, which may be using NR radio technology, CN 106 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0029] CN 106 can also act as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) (in the TCP / IP Internet Protocol suite). Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs using the same RAT as or a different RAT than RAN 104.

[0030] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capabilities (e.g., WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, Figure 1A The WTRU 102c shown can be configured to communicate with base station 114a (which may employ cellular-based radio technology) and base station 114b (which may employ IEEE 802 radio technology).

[0031] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0032] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, and transceiver 120 can be coupled to transmitting / receiving element 122. Although Figure 1B While the processor 118 and transceiver 120 are depicted as separate components, it should be understood that the processor 118 and transceiver 120 may be integrated into an electronic package or chip.

[0033] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF signals and optical signals. It should be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0034] although Figure 1B While the transmitting / receiving element 122 is depicted as a single element, the WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116.

[0035] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers to enable WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

[0036] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and can receive user input data therefrom. The processor 118 can also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 can access information and store data therein from any type of suitable memory (e.g., non-removable memory 130 and / or removable memory 132). Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 can access information and store data therein from memory that is not physically located on WTRU 102 (e.g., a server or home computer (not shown)).

[0037] The processor 118 may receive power from the power supply 134 and may be configured to distribute power to and / or control other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0038] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. As an addition to or alternative to the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method, while remaining consistent with the embodiments.

[0039] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing one or more additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors. Sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0040] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference through signal processing via hardware (e.g., chokes) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., signals associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

[0041] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0042] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0043] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the UL and / or DL, etc. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0044] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. While the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0045] The MME 162 can connect to each eNode-B 162a, 162b, 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting specific serving gateways, etc., during the initial attachment of WTRUs 102a, 102b, 102c. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies (such as GSM and / or WCDMA).

[0046] The SGW 164 can connect to each eNode B 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when WTRUs 102a, 102b, and 102c have available DL data, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0047] SGW 164 can connect to PGW 166, which can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

[0048] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional terrestrial line communication equipment. For example, CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), which acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0049] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is envisioned that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

[0050] In a representative embodiment, the other network 112 may be a WLAN.

[0051] A WLAN in Infrastructure Basic Services Set (BSS) mode may have an access point (AP) for that BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic flows to and from the BSS. Traffic flows from outside the BSS destined for STAs can reach the AP and be delivered to the STAs. Traffic flows from STAs destined for destinations outside the BSS can be sent to the AP for delivery to their respective destinations. Traffic flows between STAs within the BSS can be sent through the AP; for example, a source STA can send a traffic flow to the AP, and the AP can deliver the traffic flow to the destination STA. Traffic flows between STAs within the BSS can be considered and / or referred to as point-to-point traffic flows. Point-to-point traffic flows can be transmitted between the source and destination STAs (e.g., directly) using Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a "self-organizing" communication mode in this article.

[0052] When using 802.11ac infrastructure operation mode or a similar operation mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can be of fixed width (e.g., a 20 MHz wide bandwidth) or dynamically configured width. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented, for example in an 802.11 system. For CSMA / CA, each STA (including the AP) can listen to the primary channel. If a particular STA listens / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0053] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0054] Very High Throughput (VHT) STAs can support wide channels of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels; this can be referred to as an 80+80 configuration. For the 80+80 configuration, the channel-coded data is transmitted via a segmented parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each stream separately. The streams can be mapped onto the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0055] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Compared to those used in 802.11n and 802.11ac, the channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support metering-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities including support for certain and / or limited bandwidths (e.g., only support). MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0056] WLAN systems supporting multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs supporting (e.g., only supporting) 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (supporting only 1MHz operating mode) is transmitting to the AP, all available frequency bands may be considered busy, even if most available frequency bands are still idle.

[0057] In the United States, the available frequency bands for 802.11ah are from 902MHz to 928MHz. In South Korea, the available frequency bands are from 917.5MHz to 923.5MHz. In Japan, the available frequency bands are from 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah varies from 6MHz to 26MHz depending on the country code.

[0058] Figure 1D This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 104 can also communicate with CN 106.

[0059] RAN 104 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 104 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may use beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In this embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. Some of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In this embodiment, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0060] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions with scalable parameters. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a variable number of OFDM symbols and / or varying absolute time lengths).

[0061] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without simultaneously accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobile anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, and also with another RAN (e.g., eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobile anchors for WTRUs 102a, 102b, and 102c, while gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0062] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interoperability between DC, NR, and E-UTRA, routing user plane data to User Plane Functions (UPF) 184a and 184b, routing control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0063] Figure 1DThe CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0064] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service being utilized. For example, different network slices can be established for different use cases (e.g., services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, etc.). AMF 182a and 182b can provide control plane functions for switching between RAN 104 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies (such as WiFi)).

[0065] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure service flow routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0066] UPF 184a and 184b can connect to one or more gNBs 180a, 180b, and 180c in RAN 104 via the N3 interface. The N3 interface can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring.

[0067] CN 106 can facilitate communication with other networks. For example, CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to local DNs 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0068] Given Figures 1A to 1D The functions described herein with respect to one or more of the following: WTRU 102a to 102d, base stations 114a and 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a and 182b, UPF 184a and 184b, SMF 183a and 183b, DN 185a and 185b, and / or any other devices described herein, may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0069] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices can perform one or more or all functions to test other devices within a communication network while being fully or partially implemented and / or deployed as part of a wired / or wireless communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired / or wireless communication network. Simulation devices can be directly coupled to another device for testing purposes and / or for testing using wireless communication.

[0070] One or more simulation devices can perform one or more functions without being implemented / deployed as part of a wired / or wireless communication network. For example, simulation devices can be used in test scenarios within a test laboratory and / or an undeployed (e.g., tested) wired / or wireless communication network to perform testing of one or more components. One or more simulation devices can be test devices. Simulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0071] refer to Figure 2 Figure 200 illustrates an exemplary reference model of a possible architecture for a 5G or next-generation network. As shown, RAN node 205 refers to a radio access network based on 5G Radio Access Technology (RAT) or evolved E-UTRA, connected to the next-generation core network (CN). Access Control and Mobility Management Function (AMF) 210 may include functions such as registration management, connection management, reachability management, and mobility management. Session Management Function (SMF) 215 may include functions such as session management (including session establishment, modification, and release), WTRU IP address allocation, and selection and control of User Plane Function (UPF) 220. UPF 220 may include functions such as packet routing and forwarding, packet inspection, and traffic usage reporting.

[0072] Integrated sensing refers to the research and development of sensing services tailored to different target verticals and applications, such as autonomous / assisted driving, V2X, UAV, 3D map reconstruction, smart cities, smart homes, factories, healthcare, and maritime sectors, aimed at enhancing 5G systems to provide sensing services for various target verticals and applications. For integrated sensing, there exists a process of collecting sensing measurement data and deriving sensing results by processing this data, which is data collected for sensing purposes from radio / wireless signals affected by the object of interest or the environment (e.g., reflection, refraction, diffraction). A sensing area, called the sensing service area location, is defined; it is the area where the 5G system can provide sensing services with a certain quality regardless of obstacles. Other non-3GPP (N3GPP) entities are also considered, and sensing measurement data used for N3GPP is considered transparent to the 5G system (5GS), enabling the use of standard protocols to transmit data to interfaces defined by the 5GS.

[0073] As mentioned earlier, the current 3GPP UDM / UDR-based mechanism does not provide dynamic, flexible, and fine-grained control over user consent based on conditions such as location, time, data collection time, network, consumer information, range, and / or combinations thereof. Furthermore, there is currently no system architecture guidance on how to apply laws, local regulations, and / or operator rules when enforcing user consent.

[0074] Several considerations exist when designing solutions to provide dynamic and flexible user consent for sensing applications, enabling fine-grained control over the flow of sensing data to collect, process, and / or release sensing results to consumers according to the scope and granularity of user consent, while complying with privacy laws / regulations / carrier policies. For example, sensing information should ideally be sent to authorized parties only based on user consent from the sensing object (e.g., a user's WTRU). Sensing data should ideally be protected by confidentiality, integrity, privacy, and authorized replay. The collection, transmission, and consumption of sensing data should be conducted with the consent of the relevant parties and should comply with privacy regulations / laws and / or the network operator's privacy policy. In various embodiments, the scope of user consent should be specifically controlled regarding which data is permitted, the collection time and window, and which parties can receive or use the sensing data. Preferably, these parties should also be able to withdraw or update user consent as needed. In various embodiments, network elements for 3GPP data collection, processing, and release (e.g., Sensor Operation Management Function (SOMF) / Integrated Sensor Auxiliary Network Function (ISANF)) should be configured to control sensor data flows based on user consent to ensure that data collection, processing, and release are user-authorized.

[0075] Therefore, embodiments of this disclosure can address one or more of the following aspects: (i) how the WTRU manages and controls user consent policies; (ii) attributes that should be included in the conditions used for user consent policies; (iii) mechanisms for controlling network functions to transmit user consent policies; (iv) how national or local laws / regulations / rules / operator rules are integrated into user consent policies and should be enforced by the policy enforcement NF; and / or (v) methods for authorizing and controlling the redistribution of user data in accordance with user consent policies.

[0076] In various embodiments, a user can register user consent information with an application function (AF) that includes conditions for the user's consent to the collection / processing / release of sensor data. Attributes in these conditions may include one or more of the following: the time window or duration for collecting sensor data, location, permitted networks (e.g., a list of permitted Public Land Mobile Networks (PLMNs), Equivalent PLMN (E-PLMN), Non-3GPP Interoperability Function (N3IWF), Home PLMN (HPLMN), Visited PLMN (VPLMN), etc.), sensor data type, accuracy, sensor information receiving application, policy validity period, and permission for redistribution, etc.

[0077] The AF formulates user consent conditions based on user input and sends these conditions to the WTRU's home PCF and / or UDM function / service. In one example, the PCF retrieves user consent parameters from the UDM, combines the conditions with the WTRU's subscription data, and updates the UDM data based on information received from the AF. When formulating a user consent policy, the PCF can also map relevant privacy laws, regulations, and / or operator rules into the user consent policy. In various embodiments, the final policy may be stored in the UDM / UDR.

[0078] The sensor network (NF) subscribes to the user consent policy of the WTRU associated with the sensing process and receives and updates the user consent policy from the PCF. The NF then controls the collection, processing, consumption, and / or release of sensor data based on the authorization policy. In some embodiments, when redistribution is permitted, the user consent controller (i.e., the user consent policy enforcement point) can issue an authorization token based on the policy, which the next-hop consumer can use to receive sensing information from the first-hop consumer.

[0079] In various embodiments, the WTRU or network can update or invoke user consent at the AF at any time. The AF updates the policy in the PCF, which in turn notifies the sensing NF of the updated user consent policy. In some embodiments, the policy may be sent to the roaming network upon request by the policy framework (e.g., when the WTRU is in a visited network) and used by the control NF of the visited network to enforce sensor data collection / processing / release. It should be recognized that this methodology / framework can be used to control other services as an adjunct or alternative to sensor data collection / processing / release. For example, the methodology / framework for sensing described in the embodiments can be used alternatively or additionally for the WTRU to use user consent to participate in Artificial Intelligence / Machine Learning (AIML) federated learning. Another example is whether the WTRU can consent to serve as a relay WTRU to other WTRUs without cellular coverage, etc. Therefore, although the embodiments are described with respect to user consent and policy control for sensing applications, the embodiments of the invention are not limited to sensing applications.

[0080] Integrated sensing can utilize existing or new network functions, such as Integrated Sensing Assisted NFs (ISANFs) and / or Sensing Operations Management Functions (SOMFs). As described herein, ISANFs and / or SOMFs are logical entities and can co-located with any other entity; for example, an ISANF can co-located with a NEF, both an ISANF and SOMF can co-located with a NEF, a SOMF can co-located with an AMF, or a SOMF can co-located with a RAN, etc. In some embodiments, the ISANF supervises interactions with Application Functions (AFs) used for sensing services. The ISANF understands service requests from AFs and can deduce the corresponding requested sensing mechanism. Based on the sensing mechanism, the ISANF forwards AF requests to relevant NFs within the 5G Core (5GC), which can provide services to the Area of ​​Interest (AIO) or the requested entity (e.g., WTRU). When the AF is a third-party application function of an untrusted entity in the 5GS, the AF and ISANF can communicate via Network Open Functions (NEFs).

[0081] In some embodiments, the SOMF handles the coordination of sensing operations between the base station (BS) and the WTRU. For example, based on information received from the AMF (e.g., a request for a sensing area, a list of BSs and WTRUs, and a requested sensing mechanism with Quality of Service (QoS) requirements), the SOMF can derive coordination information for sensing operations. For example, the SOMF can determine the roles of the sensing operations, such as the sender of the sensing signal, the receiver of the sensing signal, the entity that collects sensing measurement data, and / or the entity that calculates the sensing results. For example, the SOMF can determine the sensing period, the waveform of the sensing signal, and request the BS or sender to allocate resources for transmitting the sensing signal during the sensing period.

[0082] refer to Figure 3 This illustrates an exemplary method 300 for managing user consent policies in a network. In this example, network entities may include WTRU / UE, AF, NEF, Policy Control Function (PCF), one or more Additional Network Functions (NF), and UDR. In step 302, the user registers with the AF, including consenting to user consent information with conditions for the collection, processing, and / or release of sensor data. For example, attributes in the conditions may include one or more of the following: sensor data collection time / window, location, allowed networks (e.g., a list of PLMN IDs (home / visited networks)), sensor data type, accuracy, sensor information receiving application, policy validity period, whether redistribution is allowed at the granularity and accuracy of consent, etc.

[0083] The AF sends a 304 request to the PCF to create a user consent policy (if it does not exist) and / or update an existing user consent policy (if a user consent policy for the WTRU already exists) (e.g., Npcf_UEPolicyControl_Create). In another example, after registering with the AF 305 and providing / accepting user consent information, the WTRU can notify the PCF via a control plane channel, and the PCF can request a 306 user consent policy from the subscribed AF(s) using the WTRU ID based on the Non-Access Stratum (NAS) policy management procedure. In step 308, the AF sends a response to the PCF including the requested user consent information.

[0084] As an alternative, when the AF sends a 304 Create / Update message to the PCF via the NEF, the NEF interacts with the UDM service / function to obtain user consent parameters from the UDM, and also interacts with the UDR service / function to retrieve privacy laws, regulations, and / or operator rules. In this alternative, the NEF can then forward the information from the original policy create / update message, as well as the information retrieved from the UDR / UDM, to the PCF.

[0085] Next, the PCF requests 310 (e.g., using a Nudr_DataRepository_Query request) from the UDR for WTRU subscriptions for user consent subscription parameters and any existing user consent policies / information. The PCF receives a 312 response from the UDR (e.g., via a Nudr_DataRepository_Query response), which includes user subscription parameters, privacy laws, regulations and / or operator rules, and (optionally) any existing user consent policies / information.

[0086] The PCF can then use the conditions received from the AF (e.g., from step 304), user subscription parameters, and any existing user consent policies (e.g., from step 312) to develop a 314 (or updated) user consent policy. In developing the user consent policy, the PCF may also consider the operator's local policies regarding local regulations (e.g., privacy laws and regulations such as the European Privacy Regulations, the General Data Protection Regulation (GDPR), or the California Consumer Privacy Act (CCPA)).

[0087] After the user consent policy is formulated / updated based on the WTRU input in step 302, the user consent policy is sent back to the AF 316, for example, via an Npcf_UEPolicyControl_Create response with the UE ID. As previously mentioned, in another alternative, after registering with the AF and providing user consent information, the WTRU may notify the PCF (via the control plane channel) to retrieve the user consent policy from the subscribed AF based on the NAS policy management procedure (e.g., WTRU status indication, etc.).

[0088] The AF can then send the user consent policy back to the WTRU (e.g., via the NEF) at 318. At this stage, the WTRU can optionally acknowledge the newly created / updated user consent policy (not shown). In various embodiments, the PCF can update the user consent policy in the UDR (e.g., via a Nudr_DataRepository_Update request) at 320 so that other user consent policy consumers or applications can retrieve it. A UDR response (e.g., via a Nudr_DataRepository_Update response) can be sent back to the PCF at 322 to acknowledge that the user consent policy has been successfully created / updated. According to some embodiments, a user consent consumer (e.g., sensor data collection, processing, and / or release NF) can subscribe to user consent policies from the UDR via request 324 (e.g., via a Nudr_DataRepository_Subscribe request) to receive them upon policy creation / update. The NF can receive a subscription confirmation and user consent policy from the UDR in a response at 326 (e.g., via a Nudr_DataRepository_Subscribe response).

[0089] refer to Figure 4An exemplary method 400 for updating a user consent policy is illustrated. For example, in step 402, the WTRU updates its consent with the AF or is invoked to solicit user consent at any time after registering with the AF. Registration / update from the WTRU triggers the AF to send a 404 (e.g., via an Npcf_UEPolicyControl_Update request) to the PCF regarding the user policy consent conditions (e.g., those described above). When the WTRU registers user consent with the AF, the AF updates the PCF. In some examples not shown, when the AF sends a 404 update message to the PCF via the NEF, the NEF may interact with the UDM to obtain user consent parameters from the UDM, and the NEF may also interact with the UDR to retrieve relevant privacy laws, regulations, and / or operator rules. The NEF may then forward the information from the UDR / UDM to the PCF.

[0090] As an alternative to steps 402 and 404, in some embodiments, after registering with the AF and providing user consent information, the WTRU can notify the PCF via a control plane channel to retrieve the user consent policy from the subscribed AF based on the NAS policy management process (e.g., using WTRU status indication, etc.) (e.g., via user consent information request 406 and response 408).

[0091] The PCF updates the user consent policy at step 410 based on the updated WTRU consent conditions received from the AF and optional other existing information (e.g., user subscription parameters and / or privacy laws / regulations / operator rules). The PCF can then update the user consent policy stored in the UDR via update request 412 and response 414 messages. In some embodiments, the UDR can then subscribe to the user's updated consent policy by notifying the NF at step 416 (e.g., via a Nudr_DataRepository_Notify message). After updating the user consent policy at step 410, the PCF can send the updated consent policy at step 418 (e.g., via an Npcf_UEPolicyControl_Update response) back to the AF, and at step 420, the PCF passes the policy back to the WTRU so that the WTRU knows what policy the AF has constructed and ensures that the WTRU has control over the policy sent by the AF to the PCF. In an alternative embodiment, the updated policy can be sent to the WTRU via step 422 by the AF. It should be understood that, as with any exemplary embodiment described, the order of the described steps can be performed in a different order, and steps can be omitted or combined (e.g., with other embodiments).

[0092] refer to Figure 5An exemplary method 500 for enforcing user consent policies in a network is illustrated. For example, the entities involved may include sensing devices (e.g., UE / WTRU), radio access networks (RAN), access and mobility management functions (AMF) / session management functions (SMF), UDR / PCF, sensor control NFs (e.g., integrated sensor-assisted network functions (ISANF) / sensor operation management functions (SOMF)), and sensor data consumers (e.g., another UE / WTRU, network functions, application servers, etc.).

[0093] In exemplary method 500, a user consent policy is formulated and stored 502. For example, a user (UE / WTRU) registers with an AF (not shown) carrying user consent information and conditions for user consent to the collection / processing / release of sensor data. The PCF formulates a user consent policy based on the input from the AF and the subscription data of the WTRU, and the user consent policy is stored in the UDR, as referenced. Figure 3 As described in the embodiments.

[0094] The sensor control NF subscribes to the user consent policy for integrated sensing for the WTRU associated with the sensing process based on request 504 (e.g., via a Nudr_DataRepository_Subscribe request). The sensor control NF receives the user consent policy from the PCF / UDR (506), for example, via a Nudr_DataRepository_Subscribe response. Next, the WTRU / network updates the user consent (508) and generates a new user consent policy. Additionally or alternatively, the sensor control NF may register for a notification service for PCF / UDR user consent policy updates, and when the user consent policy is updated, the sensor control NF may be notified (510) of the user consent policy update from the PCF / UDR (e.g., via a Nudr_DataRepository_Notify message). The sensor NF receives the user consent policy update from the PCF / UDR (if the user consent policy has been updated).

[0095] The sensor control NF can then control the collection, processing, consumption, and / or release of sensor data from 512 WTRUs based on a user consent policy. The sensor control NF (e.g., ISANF / SOMF) can also enforce the redistribution of sensor data or information derived from sensor data based on policies. When enforcing a user consent policy, sensor data can be filtered, anonymized, deleted, or modified according to the actions permitted in the user consent policy. For example, if the accuracy of the sensor data exceeds what the policy allows, the more accurate data can be replaced with less accurate data; for example, meter-level location data can be replaced with cell ID data. Another example is that if the user consent policy does not allow the use of the UE / WTRU ID, the UE / WTRU ID can be replaced with a random string. Because the PCF formulates the user consent policy, it can include user consent information from the AF, user subscription parameters, and privacy laws / regulations / operator rules. Therefore, the sensor control NF becomes an enforcement point against privacy laws / regulations / operator rules to implicitly enforce privacy laws / regulations / operator rules such as GDPR or CCPA.

[0096] refer to Figure 6 This illustrates an exemplary method 600 for redistributing user data using authorization tokens based on a user consent policy. The entities involved in method 600 can be related to... Figure 5 The entities discussed in Method 500 are similar, with the addition of an Authorization Server (AS) and a next-hop consumer. Method 600 begins at step 602, where the user registers with the application function carrying user consent information with conditions for the collection, processing, and / or release of sensor data. The PCF develops a user consent policy for the WTRU and stores it in the UDR. The user consent policy can be based on input from the AF, the WTRU's subscription data, and rules from privacy laws / regulations / operators, similar to... Figure 3 As described in the embodiments. In these embodiments, it is assumed that the first consumer (e.g., the previous-hop consumer) has been authorized to hold or use sensor data from the UE / WTRU, but is not authorized to redistribute the data to the next-hop consumer without explicit authorization based on the WTRU user consent policy.

[0097] The next-hop consumer sends a 604 Authorized Sensor Data Redistribution Request to the Authorization Server (AS), which includes one or more of the following: information ID, scope of use, granularity of the sensor data, consumer ID of the previous consumer (e.g., the previous hop) holding the WTRU sensor data information, the WTRU ID to which the requested sensor data belongs, and / or credentials that can be used to authenticate and / or authorize the redistribution request. Alternatively to step 604, in step 606, the next-hop consumer sends an Authorized Sensor Data Redistribution Request to the Sensor Control NF (e.g., ISANF / SOMF), which may include one or more of the following: information ID, scope, granularity of the sensor data, consumer ID holding the sensor data information, the WTRU ID to which the requested sensor data belongs, and / or credentials that can be used to authenticate and / or authorize the redistribution request. The Control NF forwards the request 608 to the Authorization Server (AS) to request an authorization token for the next-hop consumer to receive the sensor data redistribution.

[0098] As an alternative to steps 604 or 606, in step 618, the next-hop consumer sends a request to the WTRU to authorize the redistribution of sensor data. This request includes an information ID, scope, granularity of the sensor data, the consumer ID holding the sensor data information, the WTRU ID to which the requested sensor data belongs, and credentials that can be used to authenticate and authorize the redistribution request. In step 620, based on the information in the request from the next-hop consumer, if the WTRU agrees to redistribute the information to the next-hop consumer, the WTRU sends an authorization request for sensor data redistribution to the AS, this request including the same information as in the alternative.

[0099] In step 610, the Authorization Server (AS) requests a user consent policy from the Control NF (e.g., ISANF / SOMF), and in step 612, the Control NF responds to the request with a user consent policy for WTRU. In an alternative embodiment, in step 614, the Authorization Server requests explicit consent from the user, for example, if required by a policy or user subscription agreement. In step 616, the user responds to the request with user consent for redistribution.

[0100] In step 622, the authorization server makes a decision based on the user consent policy. If the request is authorized, the authorization server issues an authorization token to the next-hop consumer, which includes a token statement and scope for the next-hop consumer to receive sensor data from the consumer (i.e., the sensor data holder). Authorization tokens used for redistribution are issued by the authorization server based on the user consent policy, including scope, recipient, information, accuracy, validity period, etc.

[0101] In one example, at step 624, the authorization server responds to the next-hop consumer's request with an authorization token. In the example where the authorization request originates from the control NF at step 608, the AS responds to the control NF's request at 628 with an authorization token authorizing the next-hop consumer to receive the requested information from the consumer, and the control NF sends the token (authorization token) to the next-hop consumer as a response to step 606 at 628. If the authorization request originates from the WTRU as in step 620, the AS responds to request 620 with an authorization token authorizing the next-hop consumer to receive the requested information from the consumer at 630, and at step 632, the WTRU responds to the next-hop consumer's request at 618 with an authorization token.

[0102] In step 634, the next-hop consumer sends a sensor data request and an authorization token to the sensor data holder (i.e., the first consumer). The sensor data holder verifies the authorization of the authorization token and the scope of the request. If the request is verified, the sensor data holder responds with the requested sensor data in response to step 636 (redistribution request 634). In this way, the consumer can redistribute the sensor data to the next-hop consumer based on the received authorization token.

[0103] In an alternative embodiment, if a next-hop consumer wants to subscribe to sensor data from a sensor data holder, and the authorization server has issued authorization based on a user consent policy, the next-hop consumer can subscribe to 638 sensor data from the sensor data holder / consumer. Furthermore, in step 640, when a trigger for new data occurs, the sensor data holder can notify the next-hop consumer.

[0104] The previously described solution can also facilitate embodiments of user consent policies for controlling user consent to 3GPP services (other than sensor data). Although the previously described embodiments use sensing as an example of user consent, the embodiments are also applicable to use cases using all 5G services that require or demand user consent.

[0105] refer to Figure 7 An exemplary method 700 for processing user consent policies in a Network Open Function (NEF) may typically include: the NEF receiving 705 a request from the AF to create or update user consent policies for one or more WTRUs, including user consent attributes for each sensor data type (e.g., collection, processing, release, or a combination thereof).

[0106] The NEF communicates with the UDM 710 to retrieve user consent parameters stored in the UDM. The NEF may also communicate with the UDR 715 to retrieve privacy laws, regulations, and / or operator rules related to the WTRU. In step 720, the NEF sends information from the AF, UDR, and UDM to the PCF so that the PCF can develop a user consent policy for the WTRU. This policy, as a final enforceable policy, guides the collection, processing, distribution, and / or redistribution of sensor data based on user consent and privacy laws / regulations / operator rules. The NEF can then send the user consent policy back to the WTRU 730, for example, via the AF or via the PCF platform.

[0107] Go to Figure 8 This paper illustrates an exemplary method 800 for managing the redistribution of user data based on a user consent policy for a Sensor Control Network Function (NF) (e.g., ISANF / SOMF). Method 800 may begin with ISANF / SOMF receiving a request for redistribution of sensor data from a next-hop consumer at 805. ISANF / SOMF checks the user consent policy of the WTRU associated with the sensor data at 810 to determine whether to allow / consent to the redistribution of the sensor data. If redistribution is allowed at 815, ISANF / SOMF may request an authorization token (e.g., from an authorization server) on behalf of the next-hop consumer at 820. If authorization is approved at 825, ISANF / SOMF receives the requested token, which includes the requested scope of use for the next-hop consumer to request the redistribution of the sensor data from the data holder. The authorization token is sent back to the next-hop consumer at 830, including the scope such as information ID, recipient, granularity, accuracy, validity period, etc. If the NEF determines at 815 that data redistribution is not permitted based on the user consent policy, or if the authorization token is denied at 825, then the NEF rejects the data redistribution request at 835.

[0108] In other embodiments, a method is disclosed for a WTRU to process sensor data redistribution authorization tokens based on a user consent policy. Optionally, the WTRU is explicitly requested to obtain user consent for the redistribution of data associated with the WTRU. The WTRU may request an authorization token from an authorization server (AS) on behalf of the next-hop consumer. When the WTRU receives an authorization token from the AS authorizing the next-hop consumer to receive sensor data or sensor data-derived information, the WTRU sends the token to the next-hop consumer.

[0109] Although the features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware contained in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (e.g., internal hard disks and removable disks), magneto-optical media, and optical media (e.g., CD-ROM disks and digital multifunction disks (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method used by Network Open Function (NEF), the method comprising: Receives a request from the Application Function (AF) to create or update a user consent policy for data of a Wireless Transmitter Receiver Unit (WTRU), the request including user consent attributes for sharing the data of the WTRU; Retrieve user consent parameters for the WTRU from the Unified Data Management (UDM) service; The request received from the AF and the user consent parameters received from the UDM service are forwarded to the Policy Control Function (PCF). Receive from the PCF a new or updated user consent policy for the WTRU based on the forwarded request and user consent parameters; as well as The newly created or updated user consent policy is sent to the AF.

2. The method of claim 1, further comprising: Retrieve information related to data sharing with the WTRU from the Unified Data Repository (UDR) service, including at least one of privacy laws, regulations, and network operator rules; as well as The retrieved information related to data sharing is forwarded to the PCF for use in the newly created or updated user consent policy.

3. The method of claim 2, wherein the user consent attributes include one or more of the following: the duration for which sensor data can be collected, the location of the WTRU, the networks permitted for the sensor data, the type of sensor data, the accuracy of the sensor data, the receiving application, the policy validity period, and an indication of whether the redistribution of the sensor data is permitted.

4. The method of claim 1, wherein the user consent policy includes user consent attributes associated with at least one of the following: sensor data collection, processing, distribution, and redistribution.

5. The method of claim 1, wherein the user consent parameter includes the subscription information of the WTRU.

6. A network node including Network Open Function (NEF), the network node comprising: A processor operatively coupled to a transceiver, the processor and the transceiver being configured to: Receives a request from the Application Function (AF) to create or update a user consent policy for data of a Wireless Transmitter Receiver Unit (WTRU), the request including user consent attributes for sharing the data of the WTRU; Retrieve user consent parameters for the WTRU from the Unified Data Management (UDM) service; The request received from the AF and the user consent parameters received from the UDM service are forwarded to the Policy Control Function (PCF). Receive from the PCF a new or updated user consent policy for the WTRU based on the forwarded request and user consent parameters; as well as The newly created or updated user consent policy is sent to the AF.

7. The network node of claim 6, wherein the processor and the transceiver are further configured to: Retrieve information related to data sharing with the WTRU from the Unified Data Repository (UDR) service, including at least one of privacy laws, regulations, and network operator rules; and The retrieved information related to data sharing is forwarded to the PCF for use in the newly created or updated user consent policy.

8. The network node of claim 7, wherein the user consent attribute includes one or more of the following: the duration for which sensor data can be collected, the location of the WTRU, the networks permitted for the sensor data, the type of sensor data, the accuracy of the sensor data, the receiving application, the policy validity period, and an indication of whether the redistribution of the sensor data is permitted.

9. The network node of claim 6, wherein the user consent policy includes user consent attributes associated with at least one of the following: sensor data collection, processing, distribution, and redistribution.

10. The network node of claim 6, wherein the user consent parameter includes the subscription information of the WTRU.

11. A method used by a sensor control network function (NF), the method comprising: The next-hop consumer receives a request for redistribution of sensor data from a wireless transmit-receive unit (WTRU) held by the previous consumer. The user consent policy of the WTRU is used to determine whether to allow the redistribution of sensor data; The next-hop consumer requests an authorization token from the authorization server (AS), the authorization token including the scope of the redistribution request for the sensor data; Receive the requested authorization token for the redistribution request scope of the sensor data; as well as The received authorization token is forwarded to the next-hop consumer.

12. The method of claim 11, wherein the redistribution request scope includes information including one or more of the following: an information ID of the sensor data, a scope of use of the sensor data, a granularity of the sensor data, a WTRU ID, the ID of the previous consumer, and credentials for authenticating and authorizing the redistribution request.

13. The method of claim 11, further comprising: Receive a request for the user's consent policy from the AS; as well as Send a response including the user consent policy to the AS.

14. The method of claim 11, wherein the sensing control NF retrieves the user consent policy from a policy control function (PCF) or a unified data repository (UDR) service.

15. The method of claim 11, wherein the sensing control NF includes one or both of integrated sensing assist NF (ISANF) and sensing operation management function (SOMF).

16. A network node including a sensor control network function (NF), the network node comprising: A processor operatively coupled to a transceiver, the processor and the transceiver being configured to: The next-hop consumer receives a request for redistribution of sensor data from a wireless transmit-receive unit (WTRU) held by the previous consumer. The user consent policy of the WTRU is used to determine whether to allow the redistribution of sensor data; The next-hop consumer requests an authorization token from the authorization server (AS), the authorization token including the scope of the redistribution request; Receive the requested authorization token for the scope of the redistribution request; as well as The received authorization token is forwarded to the next-hop consumer.

17. The network node of claim 16, wherein the redistribution request scope includes information comprising one or more of the following: the information ID of the sensor data, the scope of use of the sensor data, the granularity of the sensor data, the WTRU ID, the ID of the previous consumer, and credentials for authenticating and authorizing the redistribution request.

18. The network node of claim 16, wherein the processor and the transceiver are further configured to: Receive a request for the user consent policy from the AS; and Send a response including the user consent policy to the AS.

19. The network node of claim 16, wherein the user consent policy is retrieved by the sensing control NF from a policy control function (PCF) or a unified data repository (UDR) service.

20. The network node of claim 16, wherein the sensor control NF includes one or both of integrated sensor-assisted NF (ISANF) and sensor operation management function (SOMF).

Images