User consent policy management

Abstract

Methods and devices are disclosed for providing a user consent policy in a wireless network. One method includes a network exposure function (NEF) receiving a request from an application function (AF) to create or update a user consent policy for data sharing of a wireless transmit receive unit (WTRU), retrieving user consent parameters for the WTRU from unified data management (UDM) and, if any, related privacy laws, regulations and / or operator rules from unified data repository (UDR). The NEF may forward information from the AF, UDR and UDM to a policy control function (PCF), which creates or updates the user consent policy for the WTRU as enforceable policies to guide sensing data collection, processing, distribution and redistribution based on user consent, including privacy laws, regulations and operator rules. Additional embodiments are disclosed.

Description

USER CONSENT POLICY MANAGEMENTCROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] Enhancement of 5G and next generation systems will provide sensing services addressing different target verticals and applications, e.g. autonomous / assisted driving, vehide-to-everything (V2X), unmanned aerial vehicles (UAVs), 3D map reconstruction, smart city, smart home, factories, healthcare, maritime sector, etc. Existing third generation partnership program (3GPP) unified data management (UDM)Zunified data repository (UDR)-based mechanisms do not provide any capability for dynamic, flexible or detailed control of user consent for sensing based on conditions such as location, time, data collection time, network, consumer information, scope, and various combinations. In addition, there is no system architecture guidance on how to apply laws, local regulation, and / or operator’s rules when enforcing the user consent.

[0003] Network sensing information should preferably only be sent to an authorized party based on user consent from the sensing device / environment. Preferably, sensing data should be protected for confidentiality, integrity, privacy and replay considerations. The sensing data collection, transportation and consumption should be user consented by related parties and the privacy regulations / laws, operator’s privacy policy should be observed. The user consent scope should be able to be specifically controlled as to what data, collection time and window, parties who can receive the sensing data, and the parties should be able to withdraw or update the user consent. The 3GPP data collection, processing, and releasing network element, e.g , sensing operation management function (SOMF) / integrated sensing assistance network function (ISANF) should be able to control the sensing data flow based on the user consent to make sure the data collecting, processing, and releasing of data are user authorized and consistent with applicable laws and regulations.

[0004] Methods and systems are needed to obtain dynamic and flexible user consent, detailed control of sensing data flow for collecting, processing and / or releasing the sensing results to consumers with a scope and granularity with which users have agreed, as well as ability for compliance with privacy laws, regulations and / or operator policies.SUMMARY

[0005] Aspects of the disclosure may address one or more of the foregoing needs in methods and devices for one or more of a user consent policy, user consent policy management, sensing data redistribution authorization by token based on the user consent policy, and integrated sensing and communication embodiments as detailed herein.

[0006] In should be recognized that the various aspects described can be used to control services other than sensing data collecting / processing / releasing where similar advantages may be attained. As used herein, the term “function” is used in context of a serviced based architecture (SBA) and refers to purposed-based software executed on a processing platform such as a server. Certain functions may be combined on a same platform or separated geographically depending on network design. For example, some functions may be part of a radio access network (RAN), part of a core network (CN) or externally located, and accessible by the RAN and / or CN.

[0007] In one aspect, a user registers with an application function (AF) with the user consent information with conditions that a user agrees to have the sensing data collected, processed and / or released. The attributes in the conditions may include sensing data collection time, location validity, networks allowed (e.g., home / visited), sensing data type, accuracy, sensing information receiving applications, policy valid time, redistribution allowed, etc.

[0008] In one aspect, a network AF formulates the user consent conditions based on the user input and sends the conditions to the user equipment’s (UE’s) home policy control function (PCF) and unified data management (UDM) function / service. As used herein, a UE may be alternatively referenced as a wireless transmit receive unit (WTRU). The PCF retrieves the user consent parameters in the UDM service and combines the conditions with the subscription data and updates the UDM data based on information received from the AF. When the PCF formulates the user consent policy, it may also map associated privacy laws, local regulations and / or operator’s rules into the user consent policy. In certain aspects, the user consent policy may be stored in the UDM / UDR.

[0009] According to certain aspects, a sensing network function (NF) subscribes the user consent policy for WTRUs involved in a sensing process. The sensing NF receives the user consent policy and updates from the PCF, and the NF may then control the sensing data collecting, processing, consuming, and releasing, based on the policy.

[0010] In one aspect, when re-distribution of sensing data is allowed, a user consent controller can issue an authorization token based on the policy that the next hop consumer is able to receive sensing information from a first hop consumer.

[0011] In some aspects, the WTRU can update or invoke the user consent at the AF any time. The AF will update the policy in the PCF, which in turn will notify the sensing NFs with an updated user consent policy.

[0012] According to certain aspects, the policy is sent to a roaming network by the policy framework when the WTRU is in the visiting network upon request and used by the controlling NF to enforce the related sensing data collection, processing and / or releasing.

[0013] According to one aspect for user consent policy management, a network exposure function (NEF) receives a request from the AF to create or update a user consent policy for some WTRU(s) (including user consent attributes per sensing data type, e.g., collected, processed, released or combinations of these). TheNEF interacts with the UDM service / function to store, update and / or retrieve the user consent parameters in the UDM and interacts with the UDR to retrieve relevant privacy laws, regulations and / or operator’s rules. The NEF sends the information received from the AF, UDR, and UDM to the PDF so that the PDF may formulate the user consent policy as the final enforceable policy that guides the sensing data collection, processing, distribution, and redistribution based on user consent, as well as the privacy laws / regulations / operator’s rules. The NEF may send the user consent policy back to the WTRU via the AF or via the PDF platform to the WTRU.

[0014] In another example embodiment, a user data re-distribution authorization token may be based on a user consent policy. A Sensing Control NF (e g. ISANF / SOMF) receives the request of sensing data redistribution, consults with the user consent policy to see if the redistribution is allowed, and requests the authorization token on behalf of the next-hop consumer and receives the requested token with requested scope and claims for the next-hop consumer to request the redistribution of the sensing data. The authorization token is delivered back to the next-hop consumer with a scope such as info ID, recipient, granularity, accuracy, validity time, etc.

[0015] In one optional aspect, the WTRU may be explicitly requested for the user’s consent for WTRU- related information redistribution. The WTRU may request the authorization token from an authorization server (AS) on behalf of the next-hop consumer for the authorization. When the WTRU receives the authorization token from the AS that authorizes the next-hop consumer to receive the sensing data or sensing data derived information, the WTRU sends the token to the next-hop consumer. Additional aspects, features and embodiments are disclosed in further detail below.BRIEF DESCRIPTION OF THE DRAWINGS

[0016] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein:

[0017] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

[0018] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG 1A according to an embodiment;

[0019] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0020] FIG. 1D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG 1A according to an embodiment;

[0021] FIG. 2 is an example reference model diagram of a 5G / NextGen Network;

[0022] FIG. 3 is a message sequence diagram for a method of user consent policy management according to one example embodiment;

[0023] FIG. 4 is a message sequence diagram for a method of user consent policy update of an example embodiment;

[0024] FIG. 5 is a network function diagram for a method of user consent policy enforcement of an example embodiment;

[0025] FIG. 6 is a network function diagram for a method of sensing data re-distribution authorization of an embodiment;

[0026] FIG. 7 is a flow diagram detailing a method for user consent policy management of an example embodiment; and

[0027] FIG. 8 is a flow diagram detailing a method for a user data re-distribution authorization token based on a user consent policy of an example embodiment.DETAILED DESCRIPTION

[0028] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 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 FDMA (OFDMA), singlecarrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S- OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0029] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (ON) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though itwill be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment By way of example, the WTRUs 102a, 102b, 102c, 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 a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remotesurgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0030] The communications systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0031] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0032] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

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

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

[0035] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using NR.

[0036] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g , an eNB and a gNB).

[0037] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e , Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0038] The base station 114b in FIG 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0039] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, videodistribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0040] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

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

[0042] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0043] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0044] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0046] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example.

[0047] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit) The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The 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. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0048] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 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, and the like.

[0049] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information overthe air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment

[0050] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a handsfree headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like.

[0051] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e g., associated with particular subframes for both the 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 to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e g., for transmission) or the DL (e g., for reception)).

[0052] FIG. 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0053] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0054] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of usersin the UL and / or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0055] The CN 106 shown in FIG. 1C 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 the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0056] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA

[0057] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0058] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0059] The CN 106 may facilitate communications with other networks For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0060] Although the WTRU is described in FIGS. 1A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0061] In representative embodiments, the other network 112 may be a WLAN.

[0062] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the 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 in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered tothe STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA The traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. The peer-to- peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad-hoc” mode of communication.

[0063] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0064] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0065] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels The 40 MHz, and / or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0066] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11af and 802.11ah relative to those used in 802.11n, and 802.11ac. 802.11 af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine-Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g , only support for) certain and / or limited bandwidths The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0067] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802 11 n, 802.11ac, 802.11af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

[0068] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6 MHz to 26 MHz depending on the country code.

[0069] FIG. 1 D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0070] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0071] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0072] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non- standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0073] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0074] The CN 106 shown in FIG. 1 D 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. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0075] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c.For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like The AMF 182a, 182b may provide a control plane function for switching between the 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.

[0076] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

[0077] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may 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, providing mobility anchoring, and the like.

[0078] The CN 106 may facilitate communications with other networks For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0079] In view of FIGs. 1A-1 D, and the corresponding description of FIGs. 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0080] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network.The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network The emulation device may be directly coupled to another device for purposes of testing and / or performing testing using over-the-air wireless communications.

[0081] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0082] Referring to FIG. 2, a diagram 200 of an example reference model of a potential architecture of a 5G or NextGen network is shown. As shown, RAN node 205 refers to a radio access network based on the 5G radio access technology (RAT) or Evolved E-UTRA that connects to the NextGen core network (CN). The Access Control and Mobility Management Function (AMF) 210 may include the following functionalities, Registration management, Connection management, Reachability management, Mobility Management, etc. The Session Management Function (SMF) 215 may include the following functionalities, session management (including session establishment, modify and release), WTRU IP address allocation, selection and control of user plane function (UPF) 220, etc. The UPF 220 may include the following functionalities, packet routing and forwarding, packet inspection, traffic usage reporting, etc.

[0083] Integrated sensing refers to research and development on use cases and potential requirements for enhancement of 5G system to provide sensing services addressing different target verticals and applications, e.g. autonomous / assisted driving, V2X, UAVs, 3D map reconstruction, smart city, smart home, factories, healthcare, maritime sector, etc. For integrated sensing, there is a process of collecting sensing measurement data, which is data collected about radio / wireless signals impacted (e.g. reflected, refracted, diffracted) by an object or an environment of interest for sensing purposes, and deriving sensing results from processing the sensing measurement data. An area is defined for sensing, referred to as a sensing service area location, which is an area location, whether with or without obstacle, the 5G system can provide sensing service with a certain quality. Other non-3GPP (N3GPP) entities are also considered and sensing measurement data for N3GPP is considered as transparent to 5G system (5GS) such that data is communicated using a standard protocol to an interface defined by the 5GS.

[0084] As mentioned previously, the current 3GPP UDM / UDR-based mechanism does not provide a dynamic, flexible, fine grain control of the user consent based on conditions such as location, time, data collection time, network, consumer information, scope, and / or their combinations. In addition, there is no system architecture guidance on how to apply laws, local regulation, and / or operator’s rules when enforcing the user consent.

[0085] There are several considerations in designing solutions to provide dynamic and flexible user consent for sensing applications enabling a fine-grain control of the sensing data flow for collecting, processing and / or releasing sensing results to consumers with a scope and granularity that a user agrees, as well as compliance with privacy laws / regulations / operator policies For example, the sensing information should preferably only be sent to an authorized party based on a user consent from the sensing object, e.g., a user’s WTRU. Preferably the sensing data should be protected with confidentiality, integrity, privacy and authorized replay. The sensing data collection, transportation and consumption should be performed with consent by the related parties and the privacy regulations / laws and / or network operator’s privacy policy should be adhered to. In various embodiments, the user consent scope should be specifically controlled as to what data, collection time and window are allowed and the parties who can receive or use the sensing data. Preferably, the parties also should be able to withdraw or update the user consent as desired In various embodiments, the 3GPP data collection, processing, and releasing network element, e.g., sensing operation management function (SOMF)Zintegrated sensing assistance network function (ISANF) should be configured to control the sensing data flow based on the user consent to make sure the data collecting, processing, and releasing is user authorized.

[0086] Embodiments of the present disclosure may therefore address one or more of: (i) how a WTRU manages and controls the user consent policy; (ii) the attributes that should be included in conditions for the user consent policy; (iii) the mechanisms in which control network functions communicate the user consent policy; (iv) how the national or local laws / regulations / rules / operator rules are integrated into the user consent policy and should be enforced by the policy enforcing NF; and / or (v) the method in which user data redistribution is authorized and controlled according to the user consent policy.

[0087] In various embodiments, a user may register with the application function (AF), user consent information with conditions that a user agrees to have the sensing data collected / processed / released. The attributes in the conditions may include one or more of a window or duration when sensing data is collected, a location, allowed networks (e.g., list of allowed public land mobile networks (PLMNs), equivalent PLMN (E- PLMN), non-3GPP interworking function (N3IWF), home PLMN (HPLMN), visiting PLMN (VPLMN), etc.), sensing data type, accuracy, sensing info receiving applications, policy valid time, re-distribution allowed, etc.

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

[0089] The sensing network NF subscribes the user consent policy for WTRUs involved in a sensing process and receives the user consent policy and updates from the PCF. The NF then control the sensing data collecting, processing, consuming, and / or releasing based on the authorized policy. In certain embodiments,when re-distribution is allowed, a user consent controller, which is the user consent policy enforcement point, can issue an authorization token based on the policy that the next hop consumer can use to receive the sensing information from a first hop consumer.

[0090] In various embodiments, the WTRU or network can update or invoke the user consent at the AF at any time. The AF will update the policy in the PCF, which in turn will notify the sensing NFs with the updated user consent policy. In some embodiments, the policy may be sent to a roaming network by the policy framework, e.g., when the WTRU is in the visiting network, upon request and used by the controlling NF of the visiting network to enforce the sensing data collection / processing / releasing. It should be recognized that this methodology / framework may be used to control services in addition, or in alternative to sensing data collection / processing / releasing. For example, methodology / framework of the described embodiments for sensing, may alternatively or in addition, be used for a WTRU to participate in artificial intelligence / machine learning (AIML) federated learning using user consent. Another example is whether a WTRU may consent to serving as a relay WTRU to other WTRUs that do not have the cellular coverage, etc. Accordingly, while the embodiments are described in relation to user consent and policy control for sensing applications, the inventive embodiments are not limited to sensing applications.

[0091] Integrated sensing may use existing or new network functions such as an Integrated Sensing Assistance NF (ISANF) and / or Sensing Operation Management Function (SOMF). As described herein, the ISANF and / or SOMF are logical entities and may be collocated with any other entity, e g. the ISANF maybe collocated with the NEF, the ISANF and SOMF both collocated with the NEF, the SOMF may be collocated with the AMF, or the SOMF may be collocated with the RAN, etc. In some embodiments, the ISANF oversees interaction with the Application Function (AF) for the sensing service. The ISANF understands the service request from the AF and can derive a corresponding requested sensing mechanism. Based on the sensing mechanism, the ISANF forwards AF requests to the relevant NFs within the 5G core (5GC), which may serve the region of interest or requested entities such as WTRUs. When the AF is a 3rd party application function, which is not a trusted entity of the 5GS, theAF and the ISANF may communicate through the Network Exposure Function (NEF).

[0092] In some embodiments, the SOMF handles coordination of a sensing operation among the base station (BS) and WTRUs. Based on information received from the AMF, for example requesting a sensing region, the BSs and WTRUs’ list, and requested sensing mechanism with quality of service (QoS) requirement, the SOMF may derive coordination information for the sensing operation. For example, the SOMF may decide the roles of a sensing operation such as sender(s) of sensing signal(s), receiver(s) of sensing signal(s), entity to collect the sensing measurement data and / or entity to calculate sensing results. For example, the SOMF may decide a sensing period, the waveform of the sensing signal and ask BS(s) or sender(s) resource assignment for sending sensing signal at the sensing period.

[0093] Referring to FIG. 3, an example method 300 detailing user consent policy management in a network is shown. In this example, network entities may include a WTRU / UE, AF, NEF, policy control function (PCF),one or more additional network functions (NFs) and the UDR. At step 302, a user registers with the AF including agreeing with user consent information with conditions to have sensing data collected, processed and / or released. As an example, attributes in the conditions may include one or more of sensing data collection time / window, location, network(s) allowed (such as list of PLMN ID (home / visitor networks)), sensing data type, accuracy, sensing information receiving applications, policy valid time, whether re-distribution is allowed with agreed grain and accuracy, and etc.

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

[0095] As another alternative, when the AF sends 304 the create / update message to the PCF via the NEF, the NEF interacts with the UDM service / function to get the user consent parameters in the UDM and also the NEF interacts with the UDR service / function to retrieve the privacy laws, regulations and / or operator’s rules. In this alternative, the NEF may then forward the information in the original policy create / update message, and information retrieved from the UDR / UDM, to the PCF.

[0096] Next, the PCF requests 310, e.g., using a Nudr_DataRepository_Query request, from the UDR, the WTRU subscription for user consent subscription parameters and any existing user consent policy / information. The PCF receives 312 a response, e.g., via a Nudr_DataRepository_Query response, from the UDR including user subscription parameters, privacy laws, regulations and / or operator’s rules, and optionally, any existing user consent policy / information.

[0097] The PCF may then formulate 314 (or update) the user consent policy with conditions received from the AF (e.g., from step 304), the user subscription parameters, and any existing user consent policy (e.g., from step 312). When formulating the user consent policy, the PCF may also consider the operator’s local policy for local regulation (e.g. the privacy laws, regulations such as European privacy regulation, General Data Protection Regulation (GDPR) or California Consumer Privacy Act (CCPA)).

[0098] After the user consent policy is formulated / updated based on the WTRU input in Step 302, the user consent policy is sent 316 back to the AF, e.g., via a Npcf_UEPolicyControl_Create response with the UE ID. As mentioned previously, in alternate option, the WTRU, after registering with the AF and providing user consent information, may inform the PCF, via the control plane channel, to retrieve the user consent policy from the subscribed AF’s, based on a NAS policy management procedure (e.g., WTRU State Indication, etc.).

[0099] The AF may then send 318, e.g., via the NEF, the user consent policy back to the WTRU. At this stage, the WTRU may optionally confirm the newly created / updated user consent policy (not shown). In variousembodiments, the PCF may update 320 the UDR, e.g., via a Nudr_DataRepository_Update request, the user consent policy so that it can be retrieved by other user consent policy consumers or applications. A UDR response may be sent 322, e.g., via a Nudr_DataRepository_Update response, back to the PCF to confirm the user consent policy is created / updated successfully. According to certain embodiments, the user consenting consumer, such as sensing data collecting, processing and / or releasing NF, can subscribe to the user consent policy from the UDR by a request 324, e.g., via a Nudr_DataRepository_Subscribe request, to receive the policy when they are created / updated. The NF may receive 326 the confirmation of the subscription and user consent policy in a response, e.g., via a Nudr_ DataRepository_Subscribe response, from the UDR.

[0100] Referring to FIG. 4, an example method 400 for updating a user consent policy update is shown. For example, at step 402, the WTRU updates consent, or is invoked for user consent, with the AF any time after registration with the AF. The register / update from the WTRU triggers the AF to send 404, e.g., via a Npcf_U EPolicyControLU pdate request, user policy consent conditions such as those previously described, to the PCF. When the WTRU registers with the AF regarding the user consent, the AF updates the PCF. In certain examples not shown, when the AF sends 404 an update message to the PCF via the NEF, the NEF may interact with the UDM to obtain the user consent parameters in the UDM and also the NEF may interact with the UDR to retrieve relevant privacy laws, regulations and / or operator’s rules The NEF may then forward the information from the UDR / UDM to the PCF.

[0101] Alternatively, to steps 402 and 404, in certain embodiments, after registering with the AF and providing of the user consent information, the WTRU may inform the PCF via the control plane channel to retrieve, e.g., via a user consent information request 406 and response 408, a user consent policy from the subscribed AF’s based on a NAS policy management procedure (e.g., using WTRU State Indication, etc.).

[0102] The PCF updates 410 the user consent policy based on updated WTRU consent conditions received from the AF and optionally other existing information such as user subscription parameters and / or privacy laws / regulations / operator’s rules. The PCF may then update the user consent policy stored at the UDR via update request 412 and response 414 messages. In certain embodiments, the UDR may then notify 416, e.g., via a Nudr_DataRepository_Notify message, the NFs of the updated consent policy of the subscribed user. After updating 410 the user consent policy, the PCF may send 418, e.g., via a Npcf_UEPolicyControl_Update response, the updated consent policy back to the AF, and at step 420, the PCF delivers the policy back to the WTRU for the WTRU to know what policy has been constructed by the AF and ensure that the WTRU has control over the policy which is being sent by the AF to the PCF. In an alternative embodiment, the updated policy can be sent 422 to the WTRU via the AF. It should be recognized that, as with any of the example embodiments described, the order of steps described may be performed in different orders, and steps may be omitted or combined, e g., with other embodiments.

[0103] Referring to FIG. 5, an example method 500 for user consent policy enforcement in a network is shown. As exampled, entities involved may include a sensing device such as a UE / WTRU, a radio access network (RAN), an access and mobility management function (AMF / session management function (SMF), a UDR / PCF, a sensing control NF, e.g., an integrated sensing assistance network function (ISANF)Zsensing operation management function (SOMF), and a sensing data consumer such as another UE / WTRU, a network function, an application server or the like.

[0104] In example method 500, the user consent policy is formulated and stored 502. For example, a user (UE / WTRU) registers with the AF (not shown) with the user consent information and conditions that the user agrees to have the sensing data collected / processed / released, the PCF formulates the user consent policy based on AF’s input and WTRU’s subscription data and the user consent policy is stored in the UDR, as described in reference to the embodiments of FIG. 3.

[0105] The sensing control NF subscribes the user consent policy for integrated sensing for WTRUs that are involved in the sensing process based on request 504, e.g., via a Nudr_DataRepository_Subscribe request. The sensing control NF receives 506 the user consent policy from the PCF / UDR, e.g., via a Nudr_DataRepository_Subscribe response. Next, the WTRU / Network updates 508 the user consent, and a new user consent policy is generated. Additionally or alternatively, the sensing control NF may register for notification service of PCF / UDR user consent policy updates, and the sensing control NF may be notified 510, e.g., via a Nudr_DataRepository_Notify message, of user consent policy updates from the PCF / UDR when the user consent policy is updated. The sensing NF receives the user consent policy updates from the PCF / UDR if the user consent policy is updated.

[0106] The sensing control NF may then control 512 the sensing data collection, processing, consuming, and / or releasing by the WTRU based on the user consent policy. The sensing control NF (e.g., ISANF / SOMF) can also enforce the redistribution of the sensing data or information derived from the sensing data based on the policy. When the user consent policy is enforced, the sensing data may be filtered, anonymized, removed, or altered based on the allowed action in the user consent policy. For example, if the sensing data accuracy is more than the policy allows, the accuracy of the data can be replaced with less accurate data, such as meter level position data can be replaced with cell-ID data. Another example is the UE / WTRU ID can be replaced with a random string if the user consent policy does not allow the UE / WTRU ID being used. Since the PCF formulates the user consent policy, it may include the user consent information from the AF, user subscription parameters, and the privacy laws / regulations / operator rules, the sensing control NF becomes a enforcement point for the privacy laws / regulations / operator’s rule to implicitly enforce the privacy laws / regulations / operator’s rules, such as GDPR or CCPA.

[0107] In reference to FIG. 6, an example method 600 for user data redistribution with an authorization token based on a user consent policy is shown. Entities involved in method 600 may be similar to those previously discussed in FIG. 5 method 500, with the addition of an authorization server (AS) and a next-hop consumer. Method 600 begins at step 602, where a user registers with an application function with userconsent information having user-agreed conditions for collecting, processing and / or releasing sensor data. A user consent policy is formulated for the WTRU by the PCF and stored in the UDR. The user consent policy may be based on the AF’s input, the WTRU’s subscription data, and privacy laws / regulations / operator’s rules similarly as described in the embodiment of FIG. 3. In these embodiments, it is assumed that a first consumer, e.g., previous-hop consumer, is already authorized to hold or use the sensing data from the UE / WTRU, but not authorized to redistribute the data to a next-hop consumer without explicit authorization based on a user consent policy of the WTRU.

[0108] The next-hop consumer sends 604 a request to the authorization server (AS) for the authorization of sensing data redistribution with one or more of: information ID, scope of use, granularity of the sensing data, a consumer ID of the previous consumer, e.g., previous-hop, that holds the sensing data information of the WTRU, the WTRU ID for which the sensing data is requested and / or the credential that can be used to authenticate and / or authorize the redistribution request. As an alternative to the step 604, in step 606, the nexthop consumer sends 606 the request to the sensing control NF (e.g., ISANF / SOMF) for the authorization of sensing data redistribution which may include one or more of an information ID, scope, granularity of the sensing data, the consumer ID that holds the sensing data information, WTRU ID for which the sensing data is requested and / or the credential that can be used to authenticate and / or authorize the redistribution request. The Control NF forwards 608 the request to the authorization server (AS) to request the authorization token to be used by the next-hop consumer to receive the redistribution of the sensing data.

[0109] As another alternative to steps 604 or 606, at step 618, the next-hop consumer sends the requests to the WTRU to request the authorization of sensing data re-distribution with information ID, scope, granularity of the sensing data, the consumer ID that holds the sensing data information, WTRU ID for which the sensing data is requested, the credential that can be used to authenticate and authorize the redistribution request. At step 620, based on the information in request from the next-hop consumer, if the WTRU consents to the information redistribution to the next-hop consumer, the WTRU sends the request to the AS for the authorization of sensing data redistribution with the same information as the alternative options.

[0110] At step 610, the authorization server (AS) requests the user consent policy from the Control NF (e g., ISANF / SOMF) and at step 612, the Control NF responds to the request with the user consent policy for the WTRU. In one optional embodiment, at step 614, the authorization server requests the user for explicit consent, e.g., if it is required based on policy or user subscription agreements. At step 616, the user responds to the request with the user consent for the redistribution.

[0111] The authorization server decides based on the user consent policy at step 622. If the request is authorized, the authorization server issues an authorization token to the next-hop consumer with token claims and scope for the next-hop consumer to receive the sensing data from the consumer, i.e , the sensing data holder. The authorization token for the redistribution is issued by the authorization server based on the user consent policy with scope, recipient, information, accuracy, validity time, and etc.

[0112] In one example, at step 624, the authorization server responds to the next-hop consumer request with the authorization token. In the example that the authorization request was from the Control NF in step 608, the AS responds 628 to the Control NF request 608 with the authorization token that authorizes the nexthop consumer to receive requested information from the consumer and the Control NF sends 628 the token to the next-hop consumer as the response of step 606 with the authorization token. If the authorization request came from the WTRU as in the step 620, the AS responds 630 to the request 620 with the authorization token that authorizes the next-hop consumer to receive requested information from the consumer and at step 632, the WTRU responds to the next-hop consumer request 618 with the authorization token.

[0113] At Step 634, the next-hop consumer sends the sensing data request from the sensing data holder (i.e., the first consumer) along with the authorization token. The sensing data holder validates the authorization token with authorization and requested scope. If the request is validated, the sensing data holder responds 636 to the redistribution request 634 with the requested sensing data. In this manner, the consumer can redistribute the sensing data to a next-hop consumer based on the authorization token received

[0114] In one optional embodiment, if the next-hop consumer wants to subscribe to the sensing data from the sensing data holder and the authorization has been issued by the authorization server based on the user consent policy, the next-hop consumer may subscribe 638 to the sensing data from the sensing data holder / consumer. Additionally, at step 640, the sensing data holder may notify the next-hop consumer when a trigger for new data occurs.

[0115] Embodiments for a user consent policy for users to consent control for 3GPP services other than sensing data may also be facilitated according to the previously described solutions. Although the previously described embodiments use sensing as an example for the user consent, the embodiments may also apply to all use cases using 5G services for which user consent is desirable or required.

[0116] Referring to FIG. 7, an example method 700 for a network exposure function (NEF) handling a user consent policy may generally include the NEF receiving 705 a request from an AF to create or update a user consent policy for one or more WTRUs (including user consent attributes per sensing data type, e.g. either collected, processed, released or combination of these).

[0117] The NEF communicates 710 with the UDM to retrieve the user consent parameters stored by the UDM. The NEF may also communicate 715 with the UDR to retrieve privacy laws, regulations and / or operator’s rules relevant to the WTRU. In step 720, the NEF sends the information received from the AF, UDR, and UDM to the PCF, so that the PCF may formulate the user consent policy for the WTRU as the final enforceable policy that guides the sensing data collection, processing, distribution, and / or redistribution based on user consent, as well as the privacy laws / regulations / operator’s rules. The NEF may then send 730 the user consent policy back to the WTRU, e.g., via the AF or via the PCF platform to the WTRU.

[0118] Turning to FIG. 8, an example method 800 is shown for a sensing control network function (NF) (e g., ISANF / SOMF) to manage user data redistribution based on a user consent policy. Method 800 maybegin with the ISANF / SOMF receiving 805 a request from a next-hop consumer for sensing data redistribution. The ISANF / SOMF checks 810 the user consent policy of the WTRU associated with the sensing data to determine whether the redistribution of sensing data is allowed / consented. If 815 redistribution is allowed, the ISANF / SOMF may request 820 an authorization token (e.g , from the authorization server) on behalf of the next-hop consumer. If 825 authorization is approved, the ISANF / SOMF receives the requested token with a requested scope of use for the next-hop consumer to request the redistribution of the sensing data from a data holder. The authorization token is sent 830 back to the next-hop consumer with scope such as information ID, recipient, granularity, accuracy, validity time, etc. If 815 it is determined that data redistribution is not allowed based on the user consent policy or if 825 the authorization token is denied, the NEF denies 835 the request for data redistribution.

[0119] In other embodiments a method for a WTRU handling sensing data redistribution authorization token based on a user consent policy is disclosed. Optionally, the WTRU is explicitly requested for user consent for the WTRU related data redistribution. The WTRU may request the authorization token from the authorization server (AS) on behalf of the next-hop consumer for the authorization. When the WTRU receives the authorization token from the AS that authorizes the next-hop consumer to receive the sensing data or sensing data derived information, the WTRU sends the token to the next-hop consumer.

[0120] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magnetooptical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMSWhat is Claimed:

1. A method for use by a network exposure function (NEF), the method comprising: receiving, from an application function (AF), a request to create or update a user consent policy for data of a wireless transmit receive unit (WTRU), the request including user consent attributes for sharing the data of the WTRU; retrieving, from a unified data management (UDM) service, user consent parameters for the WTRU; forwarding the request received from the AF and the user consent parameters retrieved from the UDM service to a policy control function (PCF); receiving, from the PCF, a new or updated user consent policy for the WTRU based on the forwarded request and the user consent parameters; and sending the new or updated user consent policy to the AF.

2. The method of claim 1 , further comprising: retrieving, from a unified data repository (UDR) service, information relating to data sharing of the WTRU including at least one of privacy laws, regulations and network operator rules; and forwarding, to the PCF, the retrieved information relating to data sharing for the new or updated user consent policy.

3. The method of claim 2, wherein user consent attributes include one or more of a duration when sensing data may be collected, a location of the WTRU, a network allowed for the sensing data, a sensing data type, an accuracy of the sensing data, a receiving application, a policy valid time and an indication whether redistribution of the sensing data is allowed.

4. The method of claim 1 , wherein the user consent policy includes the user consent attributes relating to at least one of sensing data collection, processing, distribution and redistribution.

5. The method of claim 1, wherein the user consent parameters include subscription information of the WTRU.

6. A network node including a network exposure function (NEF), the network node comprising: a processor operatively coupled to a transceiver, the processor and transceiver configured to: receive, from an application function (AF), a request to create or update a user consent policy for data of a wireless transmit receive unit (WTRU), the request including user consent attributes for sharing the data of the WTRU; retrieve, from a unified data management (UDM) service, user consent parameters for the WTRU;forward the request received from the AF and the user consent parameters retrieved from the UDM service to a policy control function (PCF); receive, from the PCF, a new or updated user consent policy for the WTRU based on the forwarded request and the user consent parameters; and send the new or updated user consent policy to the AF.

7. The network node of claim 6, wherein the processor and transceiver are further configured to: retrieve, from unified data repository (DDR) service, information relating to data sharing of the WTRU including at least one of privacy laws, regulations and network operator rules; and forward, to the PCF, the retrieved information relating to data sharing for the new or updated user consent policy.

8. The network node of claim 7, wherein user consent attributes include one or more of a duration when sensing data may be collected, a location of the WTRU, a network allowed for the sensing data, a sensing data type, an accuracy of the sensing data, a receiving application, a policy valid time and an indication whether redistribution of the sensing data is allowed.

9. The network node of claim 6, wherein the user consent policy includes the user consent attributes relating to at least one of sensing data collection, processing, distribution and redistribution10. The network node of claim 6, wherein the user consent parameters include subscription information of the WTRU.

11. A method for use by a sensing control network function (NF), the method comprising: receiving a request, from a next-hop consumer, for redistribution of sensing data of a wireless transmit receive unit (WTRU) held by a previous consumer; determining that sensing data redistribution is allowed based on a user consent policy of the WTRU; requesting, from an authorization server (AS), an authorization token on behalf of the next-hop consumer, including a requested scope of redistribution of the sensing data; receiving the requested authorization token for the requested scope of redistribution of the sensing data; and forwarding the received authorization token to the next-hop consumer.

12. The method of claim 11 , wherein the requested scope of redistribution comprises information including one or more of information ID of the sensing data, scope of use of the sensing data, granularity of the sensing data, WTRU ID, ID of the previous consumer and a credential used to authenticate and authorize the request for redistribution.

13. The method of claim 11 , further comprising: receiving, from the AS, a request for the user consent policy; and sending, to the AS, a response including the user consent policy.

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

15. The method of claim 11 , wherein the sensing control NF comprises one or both of an integrated sensing assistance NF (ISANF) and a sensing operation management function (SOMF)16. A network node including a sensing control network function (NF), the network node comprising: a processor operatively coupled to a transceiver, the processor and transceiver configured to: receive a request, from a next-hop consumer, for redistribution of sensing data of a wireless transmit receive unit (WTRU) held by a previous consumer; determine that sensing data redistribution is allowed based on a user consent policy of the WTRU; request, from an authorization server (AS), an authorization token on behalf of the next-hop consumer, including a requested scope of redistribution; receive the requested authorization token for the requested scope of redistribution; and forward the received authorization token to the next-hop consumer.

17. The network node of claim 16, wherein the requested scope of redistribution comprises information including one or more of information ID of the sensing data, scope of use of the sensing data, granularity of the sensing data, WTRU ID, ID of the previous consumer and a credential used to authenticate and authorize the request for redistribution.

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

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 sensing control NF comprises one or both of an integrated sensing assistance NF (ISANF) and a sensing operation management function (SOMF).

Images