Methods for operator controlled WTRU-side data collection for WTRU-side model training

Abstract

Systems and methods for controlling data collection in a network may include receiving, by a data collection server (DCS), a data collection configuration request from an AI / ML model training entity. The request may include one or more of a model identifier, input parameters for model training, or a data collection scope. A data collection profile (DCP) specifying one or more of data collection parameters, data handling rules, or privacy control mechanisms may be generated by the DCS. The DCP may be transmitted by the DCS to one or more network nodes based on the data collection scope. Data may be collected, by the DCS, from one or more wireless transmit / receive units (WTRUs) in communication with the network nodes according to the DCP. The collected data may be processed to ensure compliance with privacy regulations and user consent. The processed collected data may be sent to the AI / ML model training entity.

Description

2024P00738WGMETHODS FOR OPERATOR CONTROLLED WTRU-SIDE DATA COLLECTION FOR WTRU-SIDE MODEL TRAININGCROSS-REFERENCE TO PRIORITY INFORMATION

[0001] This application claims the benefit of U.S. Non-Provisional Patent Application Number 63 / 703,047, filed October 3, 2024, which is incorporated herein by reference in its entirety.BACKGROUND

[0002] The 3rdGeneration Partnership Project (3GPP) study on the application of artificial intelligence / machine learning (AI / ML) for the New Radio (NR) air interface may define the Life Cycle Management (LCM) of AI / ML models targeting specific use cases, such as Channel State Information (CSI) feedback enhancement, beam management, and positioning accuracy enhancements. The LCM of AI / ML models may include various phases or functions, such as model training, inference, and / or monitoring. Data collection from network nodes or Wireless Transmit / Receive Units (WTRUs) may serve as a crucial function, providing input data for these phases, including model training.SUMMARY

[0003] A data collection server (DCS) may include a processor. The processor may be configured to receive a data collection configuration request. The request may include one or more of a model identifier, input parameters for model training, or a data collection scope. A data collection profile (DCP) may be generated based on the request. The DCP may specify at least one of data collection parameters or handling rules. The DCP may be transmitted to one or more network nodes based on the data collection scope. Data may be collected from one or more wireless transmit / receive units (WTRUs) in communication with the one or more network nodes according to the DCP. The collected data may be processed to ensure compliance with user consent and privacy regulations. The processed collected data may be sent.

[0004] The processor may be configured to select the network nodes based on at least one of a geographical area mapped to a list of tracking areas or cells in the data collection scope.

[0005] The processor may be configured to anonymize privacy-sensitive data before sending the collected data.

[0006] The processor may be configured to perform at least one of a data transfer method selected from a user plane (UP) tunnel or a control plane (CP) tunnel based on data size and handling requirements.

[0007] The processor may be configured to apply data collection key performance indicators (KPIs) to determine a frequency for reporting collected data.

[0008] The processor may be configured to process the collected data based on user consent profiles stored in a unified data management (UDM) or Unified Data Repository (UDR) system.

[0009] The processor may be configured to configure the WTRUs with measurement configurations for data collection through the network nodes.

[0010] The DCP may include a session identifier for a specific data collection session. The processor may be configured to associate collected data with the session identifier.

[0011] The processor may be configured to transmit the DCP to the network nodes via an access and mobility management function (AMF).

[0012] The processor may be configured to apply privacy handling rules in the DCP that specify whether collected data can be exposed to external entities.

[0013] A method for controlling data collection in a network may include receiving, by a data collection server (DCS), a data collection configuration request from an AI / ML model training entity. The request may include one or more of a model identifier, input parameters for model training, or a data collection scope. A data collection profile (DCP) specifying one or more of data collection parameters, data handling rules, or privacy control mechanisms may be generated by the DCS. The DCP may be transmitted by the DCS to one or more network nodes based on the data collection scope. Data may be collected, by the DCS, from one or more wireless transmit / receive units (WTRUs) in communication with the network nodes according to the DCP. The collected data maybe processed to ensure compliance with privacy regulations and user consent. The processed collected data may be sent to the AI / ML model training entity.

[0014] The method may include selecting network nodes based on at least one of a geographical area or associated tracking areas defined in the data collection scope.

[0015] The method may include anonymizing, by the DCS, privacy-sensitive data collected from the WTRUs before transferring the data to the AI / ML model training entity.

[0016] The DCP may include a data transfer method selected from one or more of user plane (UP) or control plane (CP) tunnels, based on at least one of data or handling requirements.

[0017] The method may include configuring WTRUs with measurement configurations for data collection through the network nodes according to the DCP.

[0018] The method may include processing the collected data based on user consent profiles stored in a unified data management (UDM) system.

[0019] The method may include applying, by the DCS, data collection key performance indicators (KPIs) to determine a reporting frequency for the collected data.

[0020] The method may include associating, by the DCS, collected data with a transaction identifier corresponding to a specific data collection session.

[0021] The DCS may receive the collected data via the network nodes and applies privacy control mechanisms specified in the DCP before transferring the data.

[0022] The method may include transmitting the DCP to the network nodes via an access and mobility management function (AMF) and receiving acknowledgments from the network nodes.

[0023] The mechanisms, systems, and / or methods described herein may enable an operator to have full control of the WTRU-side data collection process and may support different levels of collected data visibility (e.g., partial, full) by using a Data Collection Server Function (DCSF) and / or a Data Collection Server (DCS). The DCS may be responsible for the management of the Data Collection Configuration Profile (DCCP), or Data Collection Profile (DCP) used to configure the WTRU and / or network nodes with regard to collected data content and / or its handling before its transfer to an AI / MLtraining entity (e.g., over-the-top (OTT) server, Network Data Analytics Function (NWDAF)).

[0024] Examples described herein may provide means for the operator to ensure the protection of transferred data and / or compliance with user consent and / or user data privacy protection regulations by using the DCS to apply processing (where applicable) and / or control of the collected (e.g., standardized, proprietary) data based on DCP information, WTRU subscription data, and / or operator local policy. Examples described herein may provide means for the operator to ensure an efficient and relevant data collection process, where the network (e.g., DCS, Radio Access Network (RAN)) may provide (e.g., measurement) configuration to the WTRLI adapted for the data collection characterized by the DCP information.

[0025] A data collection server (DCS) includes a processor that is configured to receive a data collection request. The data collection request may be received from a model training entity. The processor may be configured to determine a data collection profile (DCP) based on the data collection request, where the DCP specifies one or more data collection parameters and one or more handling rules for each data collection parameter of the one or more data collection parameters. The processor may be configured to transmit the DCP to one or more network nodes. The processor may be configured to receive data collected by one or more wireless transmit / receive units (WTRUs) according to the data collection parameters of the DCP. The processor may be configured to process the collected data based on the one or more handling rules for each data collection parameter of the one or more data collection parameters. The processor may be configured to send the processed collected data.

[0026] The data collection parameters may include any combination of a key performance indicator (KPI), a data collection scope, an indication of user consent control, or an indication of privacy control.

[0027] The processor may be configured to apply the KPIs to determine a frequency for reporting collected data.

[0028] The KPIs may include a time-window for data collection to be completed, a minimum number of WTRUs required for data collection, a maximum number of WTRUsrequired for data collection, a period of time data is allowed to be stored, or network load conditions.

[0029] The collected data may include privacy-sensitive data, and to process the collected data based on the one or more handling rules, the processor may be configured to anonymize the privacy-sensitive data based on the handling rules.

[0030] The collected data may include privacy-sensitive data, and to process the collected data based on the one or more handling rules, the processor is configured to modify or filter the privacy-sensitive data based on the handling rules.

[0031] The processor may be configured to receive a data collection configuration request. The processor may be configured to generate the DCP based on the data collection configuration request, where the data collection configuration request may include an identifier associated with an AI / ML model, a list of input parameters for the AI / ML model, a data collection scope, data collection KPI, or a list of candidate WTRUs.

[0032] The one or more handling rules may include, for each data collection parameter, exposure control, anonymization, modification, filtering settings, consent checks indication, transport selection, or KPI-based reporting, and wherein at least one of the one or more handling rules are determined based on user consent profiles stored in a unified data management (UDM) system.

[0033] The processor may be configured to transmit the DCP an access and mobility management function (AMF).

[0034] The processor may be configured to perform at least one of a data transfer method selected from a user plane (UP) tunnel secured using authentication and key management for application (AKMA) or a control plane (CP) tunnel based on data size and handling requirements.

[0035] A method for controlling data collection in a network may include one or more of the following steps. The method may include receiving a data collection request. The data collection request may be received from a model training entity. The method may include determining a data collection profile (DCP) based on the data collection request, where the DCP specifies one or more data collection parameters and one or more handling rules, for each data collection parameter of the one or more data collection parameters. The method may include transmitting the DCP to one or more networknodes. The method may include receiving data collected by one or more wireless transmit / receive units (WTRUs) according to the data collection parameters of the DCP. The method may include processing the collected data based on the handling rules for each data collection parameter of the one or more data collection parameters. The process may include sending the processed collected data.

[0036] The data collection parameters may include any combination of a key performance indicator (KPI), a data collection scope, an indication of user consent control, or an indication of privacy control.

[0037] The method may include applying the KPIs to determine a frequency for reporting collected data.

[0038] The KPIs may include a time-window for data collection to be completed, a minimum number of WTRUs required for data collection, a maximum number of WTRUs required for data collection, a period of time data is allowed to be stored, or network load conditions.

[0039] The collected data may include privacy-sensitive data. The method may include processing the collected data based on the one or more handling rules by anonymizing the privacy-sensitive data based on the handling rules.

[0040] The collected data may include privacy-sensitive data. The method may include processing the collected data based on the one or more handling rules by, modifying or filtering the privacy-sensitive data based on the handling rules.

[0041] The method may include receiving a data collection configuration request. The method may include generating the DCP based on the data collection configuration request, where the data collection configuration request may include an identifier associated with an AI / ML model, a list of input parameters for the AI / ML model, a data collection scope, data collection KPI, or a list of candidate WTRUs.

[0042] The one or more handling rules may include, for each data collection parameter, exposure control, anonymization, modification, filtering settings, consent checks indication, transport selection, or KPI-based reporting, and where at least one of the one or more handling rules are determined based on user consent profiles stored in a unified data management (UDM) system.2024P00738WG

[0043] The method may include transmitting the DCP to an access and mobility management function (AMF).

[0044] The method may include performing at least one of a data transfer method selected from a user plane (UP) tunnel secured using authentication and key management for application (AKMA) or a control plane (CP) tunnel based on data size and handling requirements.BRIEF DESCRIPTION OF THE DRAWINGS

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

[0046] 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.

[0047] FIG. 1 C 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.

[0048] FIG. 1 D 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.

[0049] FIG. 2 illustrates an example system architecture for WTRU-side data collection.

[0050] FIG. 3 illustrates an example method for configuration for WTRU-side data collection with full controllability and visibility for a Mobile Network Operator (MNO).

[0051] FIG. 4 is an example method for initiation of WTRU-side data collection with full controllability and visibility for an MNO.DETAILED DESCRIPTION

[0052] 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 thesharing 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), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0053] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will 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” and / or a “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 subscriptionbased 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 headmounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), 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 WTRU.

[0054] 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 / 115, the Internet 110, and / or the other networks 112. By way of example, the basestations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a 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.

[0055] The base station 114a may be part of the RAN 104 / 113, 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, etc. 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.

[0056] 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).

[0057] 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 / 113 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 115 / 116 / 117using 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 UL Packet Access (HSLIPA).

[0058] 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).

[0059] 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 New Radio (NR).

[0060] 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).

[0061] 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.

[0062] 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 a2024P00738WQ 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. 1 A, 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 / 115.

[0063] The RAN 104 / 113 may be in communication with the CN 106 / 115, 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 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, 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 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing a NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E- UTRA, or WiFi radio technology.

[0064] The CN 106 / 115 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 owned2024P00738WG 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 / 113 or a different RAT.

[0065] 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 cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0066] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, 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 subcombination of the foregoing elements while remaining consistent with an embodiment.

[0067] 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) circuits, 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.

[0068] 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 interface116. 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.

[0069] 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.

[0070] 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.

[0071] 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 lightemitting 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), readonly 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 not2024P00738WG physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0072] 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.

[0073] 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 over the 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.

[0074] 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 hands free 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, and / or a humidity sensor.2024P00738WG

[0075] 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 downlink (e.g., for reception) may be concurrent and / or simultaneous. The full duplex radio may include an interference management unit 139 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 halfduplex 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 downlink (e.g., for reception)).

[0076] FIG. 1 C 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.

[0077] 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.

[0078] 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 users in 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.

[0079] The CN 106 shown in FIG. 1 C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of 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.2024P00738WG

[0080] 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.

[0081] 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.

[0082] 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.

[0083] The ON 106 may facilitate communications with other networks. For example, the ON 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 ON 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.

[0084] Although the WTRU is described in FIGS. 1 A-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.

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

[0086] 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 an 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 to the 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.11 e DLS or an 802.11 z 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.

[0087] When using the 802.11ac 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 via signaling. 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.

[0088] 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.

[0089] 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 non-contiguous 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).

[0090] 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.11 ah relative to those used in 802.11 n, 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, 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).

[0091] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, 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 otherSTAs 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, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0092] 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.11 ah is 6 MHz to 26 MHz depending on the country code.

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

[0094] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 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, 180b 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).

[0095] 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 varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0096] 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.

[0097] 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, dual connectivity, 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. As2024P00738WQ shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0098] The ON 115 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 each of the foregoing elements are depicted as part of the ON 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0099] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 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 PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of 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 communication (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 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.

[0100] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 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 WTRU IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.2024P00738WQ

[0101] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 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 downlink packets, providing mobility anchoring, and the like.

[0102] The CN 115 may facilitate communications with other networks. For example, the CN 115 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 115 and the PSTN 108. In addition, the CN 115 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 Data Network (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.

[0103] In view of Figures 1 A-1 D, and the corresponding description of Figures 1 A-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-ab, 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.

[0104] 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 wirelesscommunication network. The emulation device may be directly coupled to another device for purposes of testing and / or may perform testing using over-the-air wireless communications.

[0105] 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.

[0106] The mechanisms, systems, and / or methods described herein may enable an operator to have full control of the WTRU-side data collection process and may support different levels of collected data visibility (e.g., partial, full) by using a Data Collection Server Function (DCSF) or DCS. The DCS may be responsible for the management of the Data Collection Configuration Profile (DCCP or DCP) used to configure the WTRU and / or network nodes with regard to collected data content and / or its handling before its transfer to an AI / ML training entity (e.g., OTT server, NWDAF).

[0107] Examples described herein may provide means for the operator to ensure the protection of transferred data and / or compliance with user consent and / or user data privacy protection regulations by using the DCS to apply processing (where applicable) and / or control of the collected (e.g., standardized, proprietary) data based on DCP information, WTRU subscription data, and / or operator local policy. Examples may provide means for the operator to ensure an efficient and relevant data collection process, where the network (DCS, RAN) may provide (e.g., measurement) configuration to the WTRU adapted for the data collection characterized by the DCP information.

[0108] With respect to WTRU-side model training, different data sizes and / or latency requirements may be considered for the data collected, depending on the specific use cases. For example, when data is collected for model training, the latency requirements may be "relaxed" (e.g., minutes, hours, days, and / or no latency requirement), while datasize may range from a few thousand bits up to 150K bits, depending on the format and / or required precision (e.g., Target CSI).

[0109] AI / ML operations may be based on models, such as neural networks, which are trained using substantial amounts of data across various scenarios and / or conditions. These conditions may include WTRU-specific conditions (e.g., speed) and / or networkspecific conditions (e.g., antenna patterns, load, and / or other factors). These conditions are referred to as WTRU-side additional conditions and network-side additional conditions, respectively. For a given AI / ML functionality, several models may exist, each trained or suited for different network and / or WTRU-side additional conditions. AI / ML models may take one or more inputs to perform inferences. Some inputs may be common across all models for a given functionality, while others may be model-specific. Therefore, in addition to training conditions, another way to differentiate between AI / ML models for a given functionality is through the inputs used for inference.

[0110] Once a model is trained, it may be deployed (e.g., in a test environment and / or test network) for performance testing. Even after deployment in a real network, model monitoring may be necessary, as the current network and / or WTRU conditions may differ from the scenarios in which the model was initially trained and / or tested. If model monitoring indicates suboptimal WTRU and / or network performance, a decision may be made to switch to another model or stop using AI / ML-based operations for the function in question. Performance monitoring may also help determine whether a model needs to be retrained with new data sets.

[0111] Model training and / or monitoring may occur at the WTRU, within the network, or through a collaboration between the two. These processes may be performed either offline and / or online.

[0112] A given AI / ML model may be trained under specific WTRU and / or network conditions. For example, a WTRU condition may involve the WTRU's speed, while network conditions may relate to network configurations and / or settings that the WTRU may not be aware of but that may impact model performance. For instance, an AI / ML beam management model may perform differently depending on whether the network was using a particular antenna pattern, beam pattern, and / or power level during training. Network load may also affect model performance. Since the WTRU may notneed to know all these details — and the network may prefer not to disclose them — the network may signal a network configuration index and / or associated ID to the WTRU to indicate the relevant network conditions. During data collection for model training, tagging may occur to specify the network conditions under which the model was trained. When a WTRU is configured to perform an AI / ML operation, it may verify the consistency between the training conditions and the current conditions, such as the current WTRU status and the associated ID signaled by the network.

[0113] The terms AI / ML functionality and use case may be used interchangeably herein. An AI / ML functionality may have sub-functionalities, and similarly, a use case may have sub-use cases. For example, the beam prediction use case currently being standardized includes two sub-use cases: temporal beam prediction and spatial beam prediction. It is assumed that (sub-)functionalities or use cases may be associated with identifiers or identities.

[0114] Some inputs required for an AI / ML model to make inferences may be specified or standardized, while others may be left to WTRU implementation. For instance, some standardized inputs may relate to reference signals or other information and / or signaling provided by the network (e.g., gNB, Location Management Function (LMF)) to the WTRU for prediction based on the AI / ML model, and this information may be shared with all WTRUs. It is expected that for each use case or functionality, 3GPP may specify the necessary inputs, such as the type of information the input represents, its format, size, range, and / or other characteristics. When referring to data collected for model training, it may be assumed that one or more of these inputs for the particular use case or functionality are being collected.

[0115] Some WTRU vendors may opt to use inputs for the models that are not standardized or specified. It should be noted that non-standardized data does not necessarily mean proprietary information (e.g., chipset, hardware, or software details of the WTRU). Instead, it could be any information, such as the WTRU's mobility state or pattern, time of day, and / or other factors, that is not standardized as a required input by an AI / ML model for a specific use case.

[0116] The data collected for AI / ML model training relates to the inputs needed for the AI / ML model to make an inference. The assumption here is that the data collectionmechanism should support the collection and transportation of both standardized and non-standardized data.

[0117] With respect to WTRU-side data collection requirements, different deployment options may be considered for WTRU-side data collection for the purpose of WTRU- side model training, where the collected data transfer may terminate either directly at an external entity (e.g., OTT server) and / or inside the MNO domain first (e.g., Application Function (AF) / Network Function (NF), Core Network, or Operation, Administration, Maintenance (0AM)) before being transferred to the OTT server. For options where the data terminates inside the MNO domain, the data collection process may provide operator controllability and visibility over standardized data. On the other hand, some or all of the data (e.g., option (i)) may be transferred to the OTT server transparently to the MNO (e.g., including WTRU proprietary information along with standardized data content). Options for data transfer using UP or CP tunnels (e.g., Radio Resource Control (RRC) or Non-Access Stratum (NAS)) may be considered.

[0118] For the data collection related to WTRU-side model training, the data collected may be fully protected in terms of integrity and confidentiality. Compliance with user data privacy and user consent requirements (e.g., based on local regulations) may also apply. The WTRU-side data collection process may remain under full MNO control (e.g., initiate and / or terminate procedures) and provide visibility for standardized data. Additionally, the defined mechanisms may need to be future-proof and extendable.

[0119] With respect to consent and user information exposure, 3GPP may specify a user consent framework that may provide technical means for operators to manage subscriber permissions in the MNO domain (in the Unified Data Management (UDM)ZUnified Data Repository (UDR)) for exposure of subscription-related data in accordance with local regulations. A mechanism for the control of exposure of WTRU location through WTRU Location Services (LCS) privacy profiles may also be defined. The LCS privacy profile may allow a WTRU to control which LCS clients and AFs are permitted to access WTRU location information.

[0120] With respect to data privacy protection regulations, such privacy regulations (e.g., General Data Protection Regulation (GDPR)), may have provisions that apply to "data controller" or "processor" organizations (e.g., MNO) regarding personal datahandling. These provisions aim to give individuals more control over their personal data by setting strict rules on how organizations collect, store, and use that data. Personal data may be defined as any information that can be used to identify an individual "data subject" (e.g., network identifier). Significant fines may be imposed in cases of non- compliance.

[0121] With respect to data collection context information, in, for example, 5G systems, a data collection profile may be maintained by the Data Collection Coordination Function (DCCF) to track data actively being collected by data sources within the Core Network (CN) without WTRU involvement. The data collection profile and / or its content may serve as a form of contextual information to manage ongoing data collection requests, preventing overlapping requests and enabling the reuse of historical data. The DCCF may compare the data collection profile with new requests to ensure there is no duplication of data collection tasks, such as for the same Service Operation or Analytic ID.

[0122] There may be a need for MNOs to have full control of the standardized data collection process and full visibility of collected standardized data according to the requirements for data protection, confidentiality, user privacy compliance, and / or MNO control over WTRU-side data collection. The collected data may be of a confidential or privacy-sensitive nature (e.g., WTRU identifiers, WTRU location, and / or activity or usage pattern information) and may also be subject to user consent before being exposed outside the MNO domain, in accordance with user data privacy protection regulations. The collected data may disclose various types of sensitive information, such as network topology, configuration, and / or other related data.

[0123] Without control over the data collection process and visibility into the collected data, the MNO risks inadvertently disclosing sensitive and / or proprietary information to external parties. This threat may expose the operator to legal liability due to non- compliance with local regulations. While the currently defined WTRU-side data collection process addresses some current and specific use cases (e.g., CSI feedback), the mechanisms defined may need to be extensible and future-proof to support new use cases and provide input for more and evolving Al models to be trained in the future.

[0124] The collected data for Al model training may present a wide range of data sizes. Therefore, the data collection process may need to support flexible means of transport to accommodate a potentially high range of data volume. Furthermore, without network control, the collected data may not be meaningful for proper model training. For example, if the involved WTRUs do not have the proper measurement configuration from the network, this may lead to wasteful usage of network resources and / or low- quality data collected for model training.

[0125] A challenge may include how to enable MNO controllability of WTRU-side data collection and visibility of standardized data for WTRU-side model training (e.g., by an external training entity or OTT server). The defined mechanisms may need to ensure the protection of transferred data and compliance with user data privacy protection regulations, be extensible and future-proof, and aim for an efficient and relevant data collection process that minimizes air interface overhead and potential negative impacts on network operations.

[0126] The mechanisms described herein may enable the operator to have full control of the WTRU-side data collection process and support different levels of collected data visibility (e.g., partial and / or full) by using a Data Collection Server Function (DCSF) or DCS. The DCS may be responsible for managing the Data Collection Configuration Profile (DCCP or DCP), which is used to configure the WTRU and / or network nodes with respect to collected data content and its handling before transfer to an AI / ML training entity (e.g., OTT server and / or NWDAF).

[0127] Examples described herein may provide an operator with the means to ensure protection of transferred data and compliance with user consent and data privacy protection regulations by using the DCS to apply processing (where applicable) and control over the collected data (e.g., standardized and / or proprietary), based on DCP information, WTRU subscription data, and / or operator local policy. The solution may also ensure an efficient and relevant data collection process, with the network (DCS, RAN) providing measurement configuration to the WTRU, adapted for data collection as characterized by the DCP information.

[0128] The terms RAN Node, Evolved NodeB (eNodeB), Next Generation NodeB (gNodeB, gNB), and Base Station may be used interchangeably. An AF or AccessStratum (AS) may refer to an OTT Server. Data collection generally refers to the WTRU logging data (e.g., measurements) and sending it to an OTT Server. In this paper, context information refers to information provided by the network (e.g., a RAN Node or Core Network Node) about the network at the time when a corresponding piece of data was collected by a WTRU.

[0129] In addition to the inputs required for inference by the AI / ML model, and thus to be collected for training purposes as described below, the WTRU may also need to collect information regarding the "ground truth," e.g., the value that the AI / ML model is expected to infer. For example, for the positioning use case, this may be the actual WTRU location, and for the beam prediction use case, it may be the signal level of the beams being predicted. For brevity, separate descriptions for the inputs and ground truth are not provided here. Many of the descriptions below focus on the input parameters and their corresponding data types. However, all the solutions described below may also apply to ground truth values (e.g., WTRU knowing the ground truth information and / or associated data type / format from the DCP information, either explicitly or implicitly from the functionality ID, and / or WTRU being configured with measurements and / or configurations to acquire and / or log the ground truth information).

[0130] Examples may include an architecture 200 for WTRU-side data collection, as illustrated in Figure 2. This architecture may introduce a Data Collection Server Function (DCSF) or Data Collection Function (DCF) or DCS 208, which may be a server or network function (NF) within the Mobile Network Operator's (MNO) domain. The DCS 208 may sit in the path of collected data transfer to an AI / ML model training entity (e.g., over-the-top (OTT) server 210 and / or NWDAF) regardless of the transport method used by the target WTRU (e.g., tunnel using RRC, NAS, and / or UP). The DCS 208 may manage the data collection configuration and the actual data collection process using a DCP, which describes the types of data to be collected and their handling with respect to user consent, user data privacy control, data collection scope, and / or other relevant considerations. The DCP information may be generated based on input from the OTT server 210, operator local WTRU subscription data, and / or operator local policy. The DCS 208 may interact with the OTT server 210 directly (if trusted) or via a networkexposure function (NEF) 206. The DCP 208 information may be used in the WTRUs, DCS, and gNBs.

[0131] The DCS 208 may handle data collection configuration in the WTRU (via AMF 204 and / or gNB) and in the gNB (via AMF) based on DCP information. The DCS 208 may receive collected data from the WTRUs via gNB (e.g., through an RRC tunnel), AMF 204 (e.g., through a NAS tunnel), or via UPF 216 (e.g., through a UP tunnel). The DCS 208 may also apply any necessary data processing (e.g., anonymization) on the collected data before transferring it to the OTT server 210. The DCS 208 may be realized as an extension of the Data Collection Coordination Function, which may be part of the NWDAF defined in 5G Systems. The services offered by the Network Repository Function (NRF) may allow DCS 208 discovery by other network functions, application functions, and the WTRU, if this capability is supported.

[0132] There may be several instances of DCS 208 within a mobile operator network, and the selection of a DCS 208 may depend on context information related to the WTRU 212, RAN 214, and / or UPF 216. For example, the selection of a DCS 208 may depend on WTRU location, RAT, and / or UPF 216 instance location. The DCS 208 instance discovery (e.g., by AMF 204) may depend on a routing identifier that may be assigned to the WTRU (e.g., by UDM 202).

[0133] Examples may include a data collection profile for WTRU-side data collection. Mechanisms (e.g., systems and methods) described herein may be based on the concept of a Data Collection Profile (DCP) and / or a Data Collection Configuration Profile (DCCP). The DCP may describe the data content (standardized and / or nonstandardized) that is collected, along with metadata related to the specific handling of the data content. The DCP, or portions of it, may be configured and used in the WTRU 212 and network nodes (RAN 214 and / or CN) as part of the data collection process, as described in further detail herein below. Different DCPs may be used to transfer various types of data content, depending on the use case and / or the model to be trained. The DCP may be applied on the WTRU 212 under the condition that specific user consent permissions (e.g., as part of subscription data) indicate the user consents to WTRU-side data collection for AI / ML model training.

[0134] The consent for data collection may be part of a Data Collection Privacy or Consent profile (e.g., in UDM / UDR), which may identify the AF(s) (e.g., OTT server 210) allowed to collect WTRU data for AI / ML model training. The network may provide assistance via the NEF 206 to external AFs (e.g., an OTT server 210 with a Service Level Agreement (SLA)) for selecting WTRUs to participate in the data collection process. A mechanism similar to WTRU member selection may be used.

[0135] A data collection profile (DCP) may be, for example, configured and / or used on a WTRU and a network side (e.g., DCS / RAN), and / or configured and / or used on a network side (e.g., DCS / RAN). In examples when a DCP is configured and / or used on a WTRU 212 and a network side (e.g., DCS / RAN). The DCP may include one or more of the following, for each parameter, a handling rule including exposure permission, consent checking, and privacy processing, a reporting policy based on KPIs, a transport selection between RRC, NAS, and user plane (UP) tunnels, and / or a session identifier;

[0136] A DCP identifier may uniquely identify a Data Collection Profile, as different DCPs may be used to transfer data content to a given OTT server 210. In some cases, the DCP identifier may be transmitted over a non-protected channel (e.g., broadcast) and may therefore be constructed in a privacy-preserving manner (e.g., allocated and changed over time across data collection configurations). In such cases, the identifier may be preferred (e.g., when transmitted in the clear) instead of the model ID, which could lead to the exposure of privacy-sensitive information.

[0137] For a given AI / ML (sub-)functionality or use-case, a functionality or use-case identifier may be used to specify the set of input parameters needed for inference, as well as the “ground truth” values (e.g., the output expected to be inferred by the AI / ML model). The type of data to be collected may be implicitly inferred from the functionality or use-case identifier.

[0138] One or more model IDs may be included to identify AI / ML models. The DCP may be shared for collecting data that serves as input for the training of different models. A WTRU that needs to provide training data for a given model ID may use the corresponding DCP to determine the data to be reported as input for model training. There may be several models for a given AI / ML (sub-)functionality, and the models may share some inputs. The data collected may be used to train all models of a given (sub-2024P00738WG functionality or a particular model. The model ID may implicitly indicate the modelspecific data to be collected.

[0139] The DCP may also include one or more standardized parameters, with their format specified (e.g., Target CSI for CSI compression in float32 format). Based on the DCP indication, the WTRU 212 may determine which parameters to report and in which format. WTRU identification information (e.g., S-TMSI, GUTI) may be part of the parameters. In addition to the functionality ID, which may implicitly indicate the standardized data format, additional parameters (e.g., 3GPP-specified information such as Reference Signal Received Power (RSRP)) may also be included.

[0140] If support for non-standardized or proprietary end-to-end data is indicated, the WTRU may send such data in a transparent container, transferred between the WTRU and the OTT server 210 without operator processing. Non-standardized data may exclude privacy-sensitive information (e.g., WTRU identifying information) or data that would otherwise be subject to user consent (e.g., WTRU location information). Specific proprietary codes understood by the WTRU 212 and OTT server 210 may identify nonstandardized data parameters. These codes may be visible to the network and may include vendor-specific identification. The corresponding data content may be forwarded transparently, meaning it is not processed by the network. Operator policy may restrict the size of the transparent data to be transferred (e.g., fixed size limit) to control the amount of data collected and avoid potential excessive usage of network resources and / or network congestion caused by the transfer of such non-standardized or proprietary data.

[0141] The DCP may specify the supported data handling and transfer methods, which may include User Plane (UP) or Control Plane (CP) options. A preferred transport method may be indicated based on the type of data, with considerations such as the operator-deployed method (e.g., NAS, RRC, and / or UP transport), WTRU capabilities, data content size, and / or other data collection KPIs. A parameter for identifying the data transfer endpoint may also be provided (e.g., IP address for DCS when using a UP tunnel). In the case of an UP tunnel, security parameters (e.g., key material) may be provided to the WTRU 212 to enable secure communication with the DCS 208. In some examples, the WTRU 212 may secure the communication with the DCS 208 based on3GPP credentials using Authentication and Key Management for Applications (AKMA)- based mechanisms. In this scenario, the DCS 208 may obtain an application key (KAF) from an AKMA Anchor Function (AAnF) upon receiving an application session establishment request from the WTRU over the UP. The KAF may be generated based on network credentials (e.g., KAMKA key).

[0142] The DCP may also include an indication of the visibility or privacy handling scope for standardized data, specifying on a per-parameter level whether the value of the parameter may be exposed to an external party and / or whether non-standardized proprietary information may be sent.

[0143] The DCP may indicate distributed AI / ML operations if the WTRU-side training is part of such an operation. The type of distributed AI / ML operation may be specified, for instance, Horizontal Federated Learning (HFL), Vertical Federated Learning (VFL), or split AI / ML operations.

[0144] The DCP may include a distributed AI / ML operation configuration that specifies the expected WTRU behavior within the distributed AI / ML operation. This configuration may indicate which training data (e.g., model parameters, weights, gradients, and / or intermediate data) should be transferred, the conditions and / or events for transferring training data (e.g., periodic, event-based), and the endpoint (e.g., URL, URI, or IP address) of the aggregator where the training data may be transferred in an HFL, VFL, or split AI / ML operation.

[0145] A training iteration step may be indicated in the DCP, as part of the data collection process, to specify the number of iterations expected for a model training operation and / or the current training iteration step.

[0146] A data collection session identifier, also referred to as a "transaction ID," may be included in the DCP to indicate an association between the DCP and a data collection session. This identifier may uniquely identify an instance of data collection at a WTRU, triggered by an AI / ML model training entity (e.g., OTT server 210). In other words, the data collection session identifier may identify a time-delimited WTRU data collection triggered by an OTT server 210.

[0147] In examples when a DCP is configured and / or used on a network side (e.g., DCS / RAN), the DCP may include one or more of the following.2024P00738WQ

[0148] When configured and / or used on the network side (DCS / RAN), the data collection handling and KPIs may include parameters such as the amount of time (e.g., time window) for the data collection to be completed, the frequency of data reporting, and / or the data volume (e.g., per WTRU and / or total across WTRUs). A KPI parameter may indicate the number of WTRUs for the data collection (e.g., minimum required and / or maximum allowed). The data handling may indicate whether the WTRU 212 should perform logging of data locally before transmitting the collected data (e.g., in bulk) and / or how long the data can be stored by the WTRU 212 before the WTRU 212 can discard the logged data.

[0149] The data collection scope may be for a particular time of day, location area, network slice, and / or DNN. An indication for user consent control may indicate that a user consent check is required per data collection or per parameter. For example, one user may consent to any data collection, while another user may consent only to a certain type of data collection identified by the Data Collection Privacy profile. Certain parameters, such as WTRU location information, may require specific consent before the WTRU location information is exposed to an external party.

[0150] An indication for privacy control may indicate that privacy control or anonymization is required at a per-parameter level. For example, a WTRU unique identifier may be marked as under privacy control and may require privacy protection before the WTRU unique identifier is transferred to an external party (e.g., OTT server 210). Examples of per parameter masking may include location coarsening (of WTRU, gNB), hashing or pseudonym ization of WTRU ID, device / equipment identification (e.g., WTRU, gNB) model or brand id, serial number(s)).

[0151] An identifier of AI / ML model training entity (e.g., external OTT server, NF in the network) may be included in the Data Collection Profile (DCP) (e.g., a Fully Qualified Domain Name (FQDN)), which may identify the AI / ML model training entity (e.g., Application Function (AF)) responsible for AI / ML training using data input based on the Data Collection Profile. A target configuration for the concerned Data Collection Profile may be included. For example, the target configuration may correspond to a radio configuration that may enable the use case or application-specific measurements for collecting data for the Data Collection Profile. The target configuration may include an2024P00738WQ index for one or more radio parameters. For example, the target configuration may correspond to a radio bearer configuration. The target configuration may also include one or more scheduling parameters (e.g., QoS parameters for target, prioritized and / or maximum bit rate, packet delay budget, and / or packet error loss). The target configuration may include a maximum delay for the completion of the transfer of the data volume corresponding to the data transfer event (e.g., for the transaction). The target configuration may also include the maximum delay before the start of the data transfer.

[0152] Some or all of the Data Collection Profile information described above may be provided and / or used by each individual WTRLI for the data collection configuration, such as the Data Collection Profile / model ID, the input data collection parameters, and / or the data transfer transport method. Parameters that apply at a data collection level, such as KPIs, scope, and / or user consent, may be maintained and / or used at a Data Collection Server (DCS) and / or RAN level. For example, consent control may be enforced by the Data Collection Server and not sent to the RAN 214 or WTRU 212.

[0153] In some examples, the WTRU 212 may be configured with a transaction ID. The WTRU 212 may include the transaction ID together with the data that is transferred to the network. The transaction ID may be specific to one data transfer event or data collection session between the WTRU 212 and the network. The WTRU 212 may use the same identity from the network-controlled start of the data transfer until the data transfer is completed. The transaction ID may correspond to a particular set of WTRU- side conditions, possibly for a particular Data Collection Profile. Additionally, the network may control the network-side conditions implicitly associated with the transaction ID, such as by controlling the start and the end of the data collection (e.g., measurements) process, when applicable (e.g., when the collection of data is initiated and controlled by the network).

[0154] In examples, configuration for MNO controlled WTRU-side data collection procedures may be included. The Data Collection Server (DCS) 208 may be responsible for creating and maintaining Data Collection Profiles (DCPs), which may be used by the network to control the data collection process across the WTRU 212, RAN 214, and Core Network (CN). The DCS 208 may construct the Data Collection Profileupon receiving a data collection configuration request from an OTT server 210. The DCS 208 may receive a list of input parameters needed for model training. The list of parameters may include the standardized parameters as described above. The DCS 208 may also receive an indication from the OTT server 210 of non-standardized parameters as described above. Additionally, the DCS 208 may receive an identifier from the OTT server 210 for the model to be trained using data input from the data collection associated with the DCP. The DCS 208 may allocate a DCP identifier that uniquely identifies the Data Collection Profile within the network. The DCP identifier may be used during the data collection process to associate collected data received from the WTRLI with the DCP. The DCS 208 may receive some KPI requirements related to the data collection (e.g., periodicity, time to completion, and / or the number of WTRUs). In some examples, this information may be provided during a data collection procedure (e.g., MNO controlled WTRU-side data collection procedure), as described in further detail below.

[0155] The DCS 208 may send the Data Collection Profile (DCP) to configure the applicable WTRU(s) (e.g., via AMF 204, gNB) for the data collection. The DCS 208 may perform the selection of the data-collecting WTRUs based on several conditions. Data collection may be allowed based on user consent being set (e.g., in the Data Collection privacy profile and / or subscription data) for the requesting OTT server. Data collection may be allowed based on user consent being set for one or more parameters to be collected. The WTRU 212 may have the proper measurement configuration adapted for the data collection. The WTRU 212 may be known and selected by the OTT server 210 (e.g., a trusted Application Function (AF) with an SLA), for example, using an external identifier (e.g., GPSI). The WTRU 212 may fulfill the data collection scope (e.g., the WTRU 212 is in the indicated location area and / or connected to a specific network slice or slices).

[0156] The DCS 208 may select the RAN 214 nodes with AMF 204 and / or 0AM assistance that comply with the data collection scope, for example, in terms of location area and / or serving relevant WTRUs. The DCS 208 may send a message to gNB (e.g., via AMF 204) providing Data Collection Profile (DCP) information. The DCS 208 may indicate the list of candidate WTRUs that can participate in the data collection. The gNBmay store DCP information and forward the information to relevant WTRUs. The gNB may select the WTRUs according to their availability, connection state, and / or current measurement configuration. The gNB may send DCP information to the WTRU 212, for example, during an RRC configuration procedure. A gNB available for data collection may broadcast an indication informing the WTRU 212 that the cell is available for data collection. WTRUs that wish to participate in data collection may decide to connect with the gNB to receive data collection configuration information when detecting the broadcasted availability for data collection indication.

[0157] The data collection may not be limited to only CONNECTED WTRUs. For example, the RAN 214 and / or Core Network (CN) may page eligible INACTIVE and / or IDLE WTRUs to cause them to establish and / or resume the connection (e.g., the WTRUs may accept and / or reject such a paging request). The paging information and / or record may indicate that this is paging related to data collection, or a paging identity used for data collection may be employed (e.g., eligible INACTIVE and / or IDLE WTRUs may be configured to monitor the paging channel for such a data collection- related paging identity). The WTRU 212 may indicate that the WTRU 212 is establishing and / or resuming the connection for data collection purposes (e.g., in a new establish and / or resume cause value, additional parameters and / or lEs included in the setup and / or resume complete message, for example, indicating the DCP-related information), and then receive the relevant data collection and / or measurement configuration.

[0158] The DCS 208 may send DCP information to the WTRU 212, for example, using a NAS WTRU Configuration Procedure via the AMF 204. The DCS 208 may receive confirmation from gNB and / or AMF 204 about the WTRU readiness and / or availability for the data collection. The DCS 208 may be notified by gNB and / or AMF 204 when a change occurs in terms of WTRU availability for data collection (e.g., a WTRU becomes unavailable due to battery and / or power-saving reasons). If a cell becomes subject to a network congestion condition and / or gNB is not eligible for data collection, the gNB may decide to stop broadcasting the availability for data collection indication. The DCS 208 may inform the gNB that the gNB is no longer eligible for data collection. The network congestion condition may be detected by the gNB and / or upon indication from the AMF204. The DCS 208 may be informed by the gNB or AMF 204 or 0AM that the gNB is no longer available for data collection (e.g., due to network congestion state).

[0159] At any time, the DCS 208 may send a message to instruct a WTRU (e.g., via AMF, gNB) to update or remove a Data Collection Profile (DCP). The WTRU 212 may be instructed by the DCS 208 to remove a DCP due to a revocation or change in the user consent information in the UDM / UDR. The WTRU 212 may be instructed by the DCS 208 to update a DCP based on a data collection configuration update from the OTT server 210 or operator local policy. The OTT server 210 may, for example, indicate changes for the non-standardized parameters. The operator or DCS 208 may update the preferred transport method or adjust the data collection KPIs according to network load conditions (e.g., increase or reduce collected data transfer time depending on increased or reduced network load conditions). The DCS 208 may receive confirmation from the gNB and / or AMF 204 of the successful configuration of WTRUs for the data collection process.

[0160] The DCS 208 may send a response to the OTT server 210 with acceptance of the data collection configuration. The response may include an identifier of the DCP and / or the AI / ML model. To use a given AI / ML model or functionality, the WTRU may need to be configured with the configurations, inputs, and / or measurements that are necessary for performing the inference. For example, for beam prediction, the WTRU 212 may need to be configured with a certain number of beams to measure in order to predict other beams (e.g., set A of beams to be predicted, set B of beams to be measured). As described above, the inputs for inference may be the data that also may need to be collected for model training. The WTRU 212, even though not performing model inference, may need to receive such a configuration solely for the purpose of data collection.

[0161] Figure 3 illustrates a procedure 300 for Configuration for WTRU-side data collection with full controllability and visibility for the mobile network operator (MNO). The OTT server 311 may interact with the DCS 307 directly or via a NEF (not shown in the figure).

[0162] At 302, the WTRU 301 may be registered with the network and may have indicated data collection capabilities. The DCS 307 may receive a Data CollectionConfiguration request from the OTT server 311 . The request may include any of the following parameters, an identifier for an AI / ML model to be trained based on input from the requested data collection, a list of input parameters for the model, including their respective expected formats, a data collection scope, such as a geographical area and / or time window to perform the collection. The data collection may be scoped to a particular geographical area, and in that case, the DCS 307 (or NEF) may map the geographical area to a network-defined area (e.g., a list of Tracking Areas or cells). The request may also include a data collection KPI, such as time to complete the data collection and / or data volume (e.g., per WTRU or total), or the number of unique data- collecting WTRUs required (e.g., minimum or average number per cell or in total for the data collection). The request may also provide a list of WTRU candidates identified by an external identifier (e.g., GPSI), which may be provided by the OTT server 311 (e.g., trusted and / or with an SLA). The WTRUs may be selected based on prior network assistance procedures as described in further detail herein above. The DCS 307 may verify that the OTT server 311 is authorized for the operation and may send a Data Collection Configuration response as an acknowledgment to the OTT server 311 .

[0163] At 304, the DCS 307 may construct DCP information, as described in further detail above, based on OTT server 311 input and operator local policy. The DCS 307 may determine the preferred collected data transport method based on the data size range, the required data collection KPIs, and network-supported methods. The DCS 307 may determine the privacy and user consent control based on the types of input parameters. For example, certain standardized parameters may be subject to postprocessing (e.g., privacy control and / or user consent check) by the DCS 307 before being transferred to the OTT server 311. In another example, non-standardized and / or proprietary parameters may be transferred transparently to the OTT server 311 (e.g., without modification).

[0164] The DCS 307 may select relevant RAN nodes 303 corresponding to the data collection scope (e.g., mapped to a list of tracking areas and / or cells). If a list of WTRUs is provided, the DCS 307 may check with the UDM / UDR 309 whether user consent allows the WTRU to perform data collection and / or collect certain types of data. Furtheraspects of WTRU selection for data collection by the Core Network (DCS) or RAN 303 are described in further detail below.

[0165] The DCS 307 may send a Data Collection Configuration Request to the target RAN nodes via AMF 305, including DCP information. The request may include a list of candidate WTRUs identified for the data collection. The DCS 307 may send a request for configuration of each individual known candidate WTRU 301 .

[0166] The RAN node 303 may decide to broadcast an indication in the cell informing WTRUs that data collection is allowed to take place in that cell. In some examples, the RAN 303 may page each individual WTRU 301 so the WTRU 301 may connect for data collection configuration.

[0167] Based on the required data parameters for data collection, as specified in the DCP, the gNB may determine whether to send the appropriate measurement configuration to the WTRU 301 , adapted for the data collection (e.g., if the WTRU is not already properly configured). The gNB may send DCP information to the WTRU 301 , which stores the DCP information to be used for the training of the associated model (as identified in the DCP information). DCP information may be sent to the WTRU 301 by AMF 305 in a NAS message.

[0168] The RAN node 303 may send a Data Collection Configuration Response, confirming the configuration of one or more WTRUs with the indicated DCP identifier. The DCS 307 may perform a check of user consent for data collection for WTRUs that were configured (e.g., not known and / or verified for selecting relevant RAN nodes, as described in further detail above). The DCS 307 may store information about the RAN node(s) and / or WTRU(s) that are available for the data collection. The DCS 307 may send a notification message to the OTT server 311 . The message may indicate that WTRUs are now available for data collection. A list of confirmed selected WTRUs may be provided.

[0169] In examples, an MNO controlled WTRU-side data collection procedure may be employed. The DCS 307 may be responsible for initiating the data collection process based on a network trigger and / or a request from the OTT server 311 . The request from the OTT server 311 may include the Data Collection Profile (DCP) or model identifier. The request from the OTT server 311 may indicate a time of completion for the datacollection. The DCS 307 may check whether the data collection KPI requirements can be satisfied, for example, in terms of time or the number of participating WTRUs available for the data collection session. The DCS 307 may be informed by the RAN 303 (either directly or from 0AM) about the WTRUs that are configured with the measurement configurations appropriate for the data collection. The DCS 307 may select the RAN nodes 303 with AMF 305 assistance that comply with the data collection scope, for example, in terms of location area and / or serving relevant WTRUs. The DCS 307 may select the RAN nodes 303 with AMF 305 assistance based on network load level (e.g., the least congested gNB may be selected) and RAN nodes 303 with a meaningful number of participating WTRUs (e.g., based on a minimal WTRU number threshold).

[0170] The RAN node 303 may inform the WTRUs of the data collection process initiation by broadcasting an ongoing / active data collection indication in the cell where the data collection is taking place or is allowed to take place. The WTRUs configured for data collection may identify the specific data collection from the ongoing / active data collection indication (e.g., based on DCP ID) and may connect with the network to perform the data collection. A configured WTRU 301 may be paged to connect with the network to perform the data collection. The DCS 307 may confirm acceptance of the data collection initiation to the OTT server 311 . The gNB may stop broadcasting the ongoing / active data collection indication upon detecting any of the following conditions: the data collection process is completed based on the DCP information conditions (e.g., time or data volume limit), or a network congestion condition is detected as described herein.

[0171] Depending on the transport method supported for the data collection, the DCS 307 may receive the data in different ways. The DCS 307 may select among supported transport methods. The selection may take into consideration the amount of data to be transferred based on the DCP list of parameters and data format requirements (e.g., over a certain size threshold, a preference for UP), and the data collection KPI (e.g., relaxed transfer time, small data CP, or UP may be used). The DCS 307 may determine to enable the logging of parameters in the WTRU 301 .

[0172] The WTRU 301 send data over an RRC connection to the gNB. The information sent to the gNB may include a session or transaction identifier identifying the data collection session, the DCP (and / or model) identifier along with the collected data. The gNB may send the collected data to the 0AM system. The gNB may transfer the collected data to the DCS 307 via the AMF 305. The DCS 307 may receive the collected data from the 0AM or AMF 305 and may locate the applicable DCP based on the mapped identifier (DCP or model). The DCS 307 may apply privacy protection measures according to the privacy handling requirements in the DCP (see examples of anonymization mechanisms described below). As described, the DCP may include one or more handling rules which are used by the DCS (and / or the gNB) to determine whether and how to perform the processing of the collected data. The handling rules may comprise any of, per collected data parameter exposure control, anonymization, modification, filtering settings, consent checks indication, transport selection, and / or KPI-based reporting (e.g., frequency). The DCS 307 may transfer the processed or post-processed collected data to the OTT server 311 based on the addressing information in the DCP.

[0173] The WTRU 301 may send data over a NAS connection to the AMF 305. The information sent to the AMF 305 may include a session or transaction identifier identifying the data collection session, the DCP (and / or model) identifier along with the collected data. The DCS 307 may process data received via the AMF 305 as described above. The WTRU 301 may send data over an UP connection to the DCS 307 based on the DCS 307 addressing information provided in the DCP. The information sent to the DCS 307 may include a session or transaction identifier identifying the data collection session, the DCP (and / or model) identifier along with the collected data. The DCS 307 may process data received from the WTRU over UP as described above.

[0174] Figure 4 illustrates a procedure 400 for the initiation of WTRU-side data collection with full controllability and visibility for the MNO.

[0175] The WTRU 301 and / or gNB may be configured with DCP information configuration and may be available to perform data collection as further described above with reference to the MNO Controlled WTRU-side Data Collection Procedure. The DCS 307 may receive a Data Collection Initiation request from the OTT server 311 .The request may include the DCP ID and / or the associated model ID. The DCS 307 may check that the OTT server 311 is authorized for data collection initiation and may locate the DCP information based on the provided identifier(s). The DCS 307 may retrieve information about available RAN nodes 303 and / or WTRUs 301 , which may be established as further described above with reference to the MNO Controlled WTRU- side Data Collection Procedure.

[0176] The DCS 307 may send a Data Collection Initiation Response to the OTT server 311 to acknowledge the initiation of the data collection. The acknowledgment may be sent after receiving acknowledgments from all RAN nodes. The DCS 307 may send a Data Collection Initiation Request to the target RAN nodes via AMF 305, including DCP information and a list of WTRUs available and / or authorized for data collection. The RAN node may acknowledge acceptance of the data collection or may reject it based on conditions. The RAN node may reject the data collection due to congestion conditions or may reject or indicate a change in the available WTRUs (e.g., if WTRUs have moved to a different gNB). The DCS 307 may use that information, for example, to update the list of WTRUs expected to collect data, and / or may inform the OTT server 311 accordingly.

[0177] The RAN node may decide to broadcast an indication in the cell informing the WTRUs that data collection is allowed to start in that cell. In some examples, the RAN 303 may page each individual WTRU 301 so the WTRU may connect to perform data collection. The WTRU 301 may connect for data collection transfer toward the network. The WTRU 301 may initiate the data collection (e.g., based on internal triggers). The WTRU 301 may report vendor-specific proprietary and / or non-standardized data input, and the data sent to the DCS 307 may be subject to authorization verification by the DCS 307 as further described herein below.

[0178] Based on the supported transfer method for the data collection as indicated in the DCP, the WTRU 301 may send the collected data to the DCS 307 via gNB, AMF 305, and / or UPF. The DCS 307 may apply processing to the received data from each individual WTRU 301 based on the DCP data handling rules. The DCP handling rules may be one or more rules which are used by the DCS (and / or the gNB) to determine whether and how to perform processing of the collected data. For example, the DCS307 may anonymize, modify, and / or filter privacy-sensitive standardized data parameters. The DCS 307 may verify that the WTRU 301 is authorized to send proprietary and / or non-standardized data before forwarding it to the OTT server 311 . The DCS 307 may, for example, restrict the data volume that the WTRU 301 can send using proprietary and / or non-standardized data.

[0179] Figure 4 illustrates a procedure 400 for a WTRU-initiated data collection procedure may include one or more of the following steps. At 402, the WTRU and / or gNB may be configured with DCP information configuration and may be available to perform data collection as further described above with reference to the MNO Controlled WTRU-side Data Collection Procedure. The WTRU 401 may initiate a procedure that requests the establishment of a data collection transfer. The WTRU 401 may send a request to the applicable network function (e.g., to the DCS 409), including one or more parameters that may characterize the data to be transferred. For example, the WTRU 402 may include the DCP information, a data volume, an average IP packet size (or a maximum transmission unit (MTU) for the data), and / or the total number of packets for the data. The WTRU 401 may include DCP information with a transaction ID. The WTRU 401 may include DCP information indicating that at least some of the collected data includes proprietary and / or non-standardized data (e.g., not decodable by the network function). If applicable, the characterization of the data may include separate information for the standardized and / or the non-standardized parts.

[0180] In some examples, the RAN 403 (e.g., gNB) may receive a configuration that enables the data collection for the concerned WTRU 401 and / or DCP profile, if applicable. For example, this configuration may correspond to a target configuration for the requested DCP (e.g., from the DCS 409) and / or UP tunneling information (e.g., from the UPF 407). The WTRU 401 may receive a response that configures the DCP, sets the transaction ID, and / or provides the IP address for the IP tunnel to use for the data (e.g., the IP address of the OTT server). The WTRU 401 may then initiate the transfer of data to the DCS 409 via gNB, AMF 405, and / or UPF 407 depending on the configuration.

[0181] With respect to visibility and / or privacy considerations, the DCS 409 may enforce user consent and user data privacy requirements as follows. The UDM / UDR maymaintain a Data Collection Privacy Profile that indicates the permissions for the transfer of data on a per-external AF / OTT server level and parameter level. For example, the Data Collection Privacy Profile may indicate that OTT server A is allowed, whereas OTT server B is not allowed for the WTRLI. In that scenario, based on the Data Collection Privacy Profile, the DCS 409 may determine to include (or exclude) the WTRU 401 for the data collection performed for OTT server A (or B) model training.

[0182] Some parameters, such as WTRU location information, may be subject to specific privacy requirements (e.g., LCS privacy profile). For example, an OTT server X may not be allowed to obtain WTRU location information. In that scenario, the DCS 409 may determine, based on the LCS privacy profile, whether to include the WTRU 401 for the data collection performed for OTT server X model training. If OTT server X is not allowed to obtain location information, the DCS 409 may determine to exclude or mask location information from the data transferred to OTT server X (e.g., replace it with an arbitrary invalid, unknown, and / or coarse value). In some examples, the DCS 409 may determine to exclude the WTRU 401 from the data collection process (e.g., if location information is a critical input for model training).

[0183] When interacting with a trusted OTT server 411 (e.g., with SLA), the DCS may allow the transfer of data, including authorized WTRU 401 external identifiers (e.g., GPS I). If no external identifier is available to use with an OTT server 411 , the DCS 409 may ensure to anonymize WTRU privacy-sensitive identifiers. For example, the DCS 409 may apply a random hash function to a permanent or temporary WTRU identifier to provide an anonymized value protecting the privacy of the WTRU while preserving the uniqueness of such an identifier parameter. This mechanism allows the distinction and identification of different input data samples from different WTRUs in the AI / ML model training while preserving the privacy of the WTRU identifier(s).

[0184] The data collection framework may be extended in the future using the DCP as follows. A DCP may be extended by adding new standardized parameters to support future new use cases. The DCP mechanism may be reused for the data collection process in the case of monitoring and inference as part of the model LCM. It should be noted that monitoring and inference phases may require more stringent latency requirements for data collection (e.g., in the order of milliseconds instead of minutes ormore in the case of model training). The data collection KPI or an equivalent in the DCP may be used to indicate the latency requirement according to the use case. The same DCP may be used for different data collection phases (training, monitoring, and / or inference) with respective applicable KPI and collected parameters variations. In that case, the DCP may indicate the applicable LCM phase (training, monitoring, and / or inference). This approach may present the advantage of simplified data collection configuration management (e.g., a single DCP for all data collection needs for the model LCM). In examples, the concept of the DCP may be reused beyond AI / ML for the NR air interface and extended to NAS layer or UP AI / ML model training to support new emerging AI / ML model training use cases.

[0185] With respect to WTRU selection for data collection and / or RAN selection aspects, in some examples, it may be important to select only WTRUs that already have the required measurements and / or configurations, or to ensure that a selected WTRU will also be configured with the required configurations. If a WTRU is selected for data collection for a certain AI / ML functionality and / or model, and it determines that it does not have the required configuration (e.g., measurement configuration) to collect the data (e.g., by comparing the required data types to be collected from the DCP and the current data the WTRU is able to collect based on its configuration), it may reject the data collection request.

[0186] In some examples, the WTRU 401 may request the network (e.g., RAN, LMF, CN, etc.) for the configuration that it needs to perform the data collection. In this request, the WTRU 401 may just indicate that it has been selected for data collection of a certain functionality and / or model (e.g., to differentiate from a similar request the WTRU may need to send for other purposes, such as for inference configuration for the same functionality and / or model), and / or it may include detailed information (e.g., one or more of the components from the DCP) regarding the data that needs to be collected.

[0187] In some examples, the WTRU 401 may have some measurement configurations that it has stored but has not activated yet, and the reception of the data collection request can be considered as an implicit activation message for the measurements that are relevant for the data collection. For example, the WTRU 401 may have some mapping of the measurement configurations for different functionalities and / or models,and a reception of a data collection request for a particular functionality and / or model (e.g., as indicated in the DCP) may trigger the WTRU 401 to activate the one or more measurement configurations that are associated with this functionality and / or model.

[0188] A measurement configuration that is going to be used for data collection may include information other than what is to be measured (e.g., how often the measurements should be logged and / or events and / or conditions when measurements should be logged). In some examples, such information may be part of the DCP configuration (e.g., the measurement configuration may just indicate what needs to be measured, while the DCP configuration specifies logging and / or reporting configurations).

[0189] In some cases, the network (e.g., RAN, CN, and / or LMF) may ensure that only WTRUs that already have the configuration for collecting the required data (e.g., have the needed measurement configuration) will be selected for the data collection. In some cases, the network may proactively send the required configurations to the WTRUs that have been selected for collecting data (e.g., along with the data collection request that is being propagated from the OTT server / DCS, as described in further detail herein below.

[0190] A WTRU 401 may indicate that it is capable of data collection (for one or more AI / ML functionalities and / or models) (e.g., as part of a WTRU capability communication, based on an explicit request from the network regarding such capability, and / or proactively using WTRU assistance information like messaging).

[0191] A WTRU 401 that does not have an AI / ML model for a certain AI / ML functionality (or may not even have the capability for that AI / ML functionality (e.g., from a hardware and / or software point of view) may, however, be capable of performing the data collection. For example, the data collection capability may be implicitly determined by the network based on the WTRU’s measurement and reporting capability. For example, a legacy WTRU 401 may be used to collect and report extensive data about beams of serving and neighboring cells, which may then be partitioned as set A and / or set B by the training entity, which may be the OTT server 411 or another entity, to train an AIML model that may perform beam predictions.

[0192] With respect to core network selection aspects, when triggered to perform data collection (as described above with reference to Figure 3), the DCS 409 may need to determine which WTRU(s) to collect data from. The message that may be received by the DCS 409 which may trigger the DCS 409 to perform data collection may identify which WTRU(s) it may need to collect data from. The message that may be received by the OTT server 411 which may trigger the DCS 409 to perform data collection may indicate a list of criteria that WTRU(s) should meet for data collection. The DCS 409 may then use the list of criteria to determine which WTRll(s) data should be collected from. Examples of criteria may include WTRU(s) that are in a certain location, WTRU(s) that have a Protocol Data Unit (PDU) Session established with a certain DNN / S-NSSAI combination, WTRU(s) that are moving at a certain speed, and / or WTRU(s) that are connected via a certain RAT type.

[0193] The DCS 409 may use a list of criteria to invoke the Member WTRU Selection Assistance API of the NEF to determine which WTRU(s) data should be collected from. A procedure to invoke the Member WTRU Selection Assistance API may be performed to identify the WTRU(s) based on the specified criteria. In some examples, the DCS 409 may perform the selection functionality taking place in the NEF to directly determine the appropriate WTRU(s) for data collection.

[0194] It is to be appreciated that the message received by the DCS 409 to perform data collection may indicate a WTRU 401 exclusion list. The exclusion list may indicate specific WTRUs or WTRUs with certain characteristics. The DCS 409 may exclude the WTRUs indicated by the WTRU exclusion list when selecting the WTRUs for data collection, and the WTRU exclusion list may provide finer granularity in the selection of WTRU(s) for data collection. For example, the message may indicate to collect data from WTRUs in a location with an exclusion list indicating WTRUs moving at a certain speed, connected to a certain RAT, and / or that do not consent to data collection.

[0195] The list of criteria that is received by the DCS 409 may also indicate the type of data that needs to be collected for model training. It may be that certain WTRUs are capable of collecting certain types of data, while other WTRUs may not be capable of collecting certain types of data. The list of criteria that is received by the DCS may alsoindicate that the data should be collected from devices that are associated with a certain manufacturer and / or a certain model type.

[0196] The types of data that a WTRU can collect, information about the manufacturer of a WTRU, and / or information about the model type of a WTRU may be stored in the WTRU’s subscription. The information may be read by the NEF when a Member WTRU Selection procedure is performed and compared against the filter information that is provided by the DCS 409 so that the NEF can select WTRU(s) that meet the desired criteria (e.g., support collecting the required type of data, are associated with the desired manufacturer, and / or are of the desired model type).

Claims

CLAIMS:1 . A data collection server (DCS) comprising: a processor configured to: receive a data collection request; determine a data collection profile (DCP) based on the data collection request, wherein the DCP specifies one or more data collection parameters and one or more handling rules for each data collection parameter of the one or more data collection parameters; transmit the DCP to one or more network nodes; receive data collected by one or more wireless transmit / receive units (WTRUs) according to the data collection parameters of the DCP; process the collected data based on the one or more handling rules for each data collection parameter of the one or more data collection parameters; and send the processed collected data.

2. The DCS of claim 1 , wherein the data collection parameters comprise any combination of a key performance indicator (KPI), a data collection scope, an indication of user consent control, or an indication of privacy control.

3. The DCS of claim 2, wherein the processor is configured to apply the KPIs to determine a frequency for reporting collected data.

4. The DCS of claim 2, wherein the KPIs comprise a time-window for data collection to be completed, a minimum number of WTRUs required for data collection, a maximum number of WTRUs required for data collection, a period of time data is allowed to be stored, or network load conditions.

5. The DCS of claim 1 , wherein the collected data comprises privacy-sensitive data, and wherein, to process the collected data based on the one or more handling rules, theprocessor is configured to anonymize the privacy-sensitive data based on the handling rules.

6. The DCS of claim 1 , wherein the collected data comprises privacy-sensitive data, and wherein, to process the collected data based on the one or more handling rules, the processor is configured to modify or filter the privacy-sensitive data based on the handling rules.

7. The DCS of claim 1 , wherein the processor is configured to: receive a data collection configuration request; and generate the DCP based on the data collection configuration request, wherein the data collection configuration request comprises an identifier associated with an AI / ML model, a list of input parameters for the AI / ML model, a data collection scope, data collection KPI, or a list of candidate WTRUs.

8. The DCS of claim 1 , wherein the one or more handling rules comprise, for each data collection parameter, exposure control, anonymization, modification, filtering settings, consent checks indication, transport selection, or KPI-based reporting, and wherein at least one of the one or more handling rules are determined based on user consent profiles stored in a unified data management (UDM) system.

9. The DCS of claim 1 , wherein the processor is configured to transmit the DCP to an access and mobility management function (AMF).

10. The DCS of claim 1 , wherein the processor is configured to perform at least one of a data transfer method selected from a user plane (UP) tunnel secured using authentication and key management for application (AKMA) or a control plane (CP) tunnel based on data size and handling requirements.

11. A method for controlling data collection in a network, the method comprising: receiving a data collection request;determining a data collection profile (DCP) based on the data collection request, wherein the DCP specifies one or more data collection parameters and one or more handling rules for each data collection parameter of the one or more data collection parameters; transmitting the DCP to one or more network nodes; receiving data collected by one or more wireless transmit / receive units (WTRUs) according to the data collection parameters of the DCP; processing the collected data based on the handling rules for each data collection parameter of the one or more data collection parameters; and sending the processed collected data.

12. The method of claim 11 , wherein the data collection parameters comprise any combination of a key performance indicator (KPI), a data collection scope, an indication of user consent control, or an indication of privacy control.

13. The method of claim 12, comprising: applying the KPIs to determine a frequency for reporting collected data.

14. The method of claim 12, wherein the KPIs comprise a time-window for data collection to be completed, a minimum number of WTRUs required for data collection, a maximum number of WTRUs required for data collection, a period of time data is allowed to be stored, or network load conditions.

15. The method of claim 11 , wherein the collected data comprises privacy-sensitive data, and the method further comprises processing the collected data based on the one or more handling rules by anonymizing the privacy-sensitive data based on the handling rules.

16. The method of claim 11 , wherein the collected data comprises privacy-sensitive data, and the method further comprises processing the collected data based on the oneor more handling rules by, modifying or filtering the privacy-sensitive data based on the handling rules.

17. The method of claim 11 , comprising: receiving a data collection configuration request; and generating the DCP based on the data collection configuration request, wherein the data collection configuration request comprises an identifier associated with an AI / ML model, a list of input parameters for the AI / ML model, a data collection scope, data collection KPI, or a list of candidate WTRUs.

18. The method of claim 11 , wherein the one or more handling rules comprise, for each data collection parameter, exposure control, anonymization, modification, filtering settings, consent checks indication, transport selection, or KPI-based reporting, and wherein at least one of the one or more handling rules are determined based on user consent profiles stored in a unified data management (UDM) system.

19. The method of claim 11 , comprising: transmitting the DCP to an access and mobility management function (AMF).

20. The method of claim 11 , comprising: performing at least one of a data transfer method selected from a user plane (UP) tunnel secured using authentication and key management for application (AKMA) or a control plane (CP) tunnel based on data size and handling requirements.

Images