Methods and apparatus for enhancing artificial intelligence machine learning (AIML) frameworks to support wireless transmit and receive unit (WTRU) data collection.

Abstract

A Wireless Transmit and Receive Unit (WTRU) can receive a user consent token from the network. The WTRU can determine that user consent has been authorized based on the user consent token. The WTRU can send a request to the network to establish a Protocol Data Unit (PDU) session. This request may include a request type indicating the type of data session used for application-specific measurement data collection. The WTRU can receive an indication from the network to accept the PDU session. This indication may include application-specific WTRU data collection assistance information. The WTRU can use the application-specific data collection assistance information to determine the data collection and reporting configuration associated with the application. The WTRU can use the established PDU session and, based on the data collection and reporting configuration, send application-specific measurement reports to the network.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 595,524, filed November 2, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] An event consumer is a subscriber to event data generated by, for example, a network function (NF). The event data is generated by the NF and then exposed to the event consumer. An event consumer can be another NF or AF. An event consumer managed by a mobile network operator (MNO) is an instance of an event consumer managed by the MNO (e.g., by a network function (NF) within the MNO network). Event consumers can be trusted or untrusted. Event data exposure can be performed via a network exposure function (NEF), for example, for untrusted event consumers, or, in the absence of a NEF, for example, for trusted event consumers. Summary of the Invention

[0003] This paper describes a data collection and reporting procedure for artificial intelligence / machine learning (AI / ML) applications that can run in a Wireless Transmit and Receive Unit (WTRU). The procedure can specify mechanisms executed by network functions in the core network, such as Network Data Analysis Functions (NWDAF), to collect data from the WTRU via intermediate entities of the functions, such as Application Functions (AF). Such mechanisms can be facilitated by leveraging some functionalities supported by 5G systems (5GS). These functionalities enable client configuration for WTRU data collection and reporting, WTRU procedures for reporting the collected data, and the subsequent exposure of the reported WTRU-collected data to the AF.

[0004] Data Collection Application Function (DCAF) can be implemented in the 5G Core (5GC) network. The WTRU Direct Data Collection Client can be implemented within the WTRU. AI / ML applications can be running within the WTRU. Application data can be collected by the WTRU AI / ML application and internally reported to the WTRU Direct Data Collection Client for further processing and filtering. The Direct Data Collection Client can submit data reports to the DCAF. The receipt of data reports by the DCAF can expose events to interested event consumers, who may have previously subscribed to the event, such as NWDAF. Attached Figure Description

[0005] A more detailed understanding can be obtained by referring to the following description, which is given by way of example in conjunction with the accompanying drawings, wherein the same reference numerals in the figures indicate the same elements, and wherein: Figure 1AThis is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented; Figure 1B The illustration shows an embodiment that can be used Figure 1A The diagram shows a system illustration of an example wireless transmit / receive unit (WTRU) used within a communication system. Figure 1C The illustration shows an embodiment that can be used Figure 1A The diagram shows an example radio access network (RAN) and an example core network (CN) used in a communication system. Figure 1D The illustration shows an embodiment that can be used Figure 1A The diagram shows another example RAN and another example CN used in the communication system. Figure 2 A diagram depicting a reference architecture for WTRU data collection is provided. Figure 3 An example of a reporting mechanism is illustrated; Figure 4 The diagram illustrates an example call flow for a WTRU configuration procedure used for data collection and reporting; Figure 5 The diagram illustrates a sample call flow from a WTRU data report; Figure 6 A diagram depicting an instantiation of a direct data collection client as part of a WTRU application; Figure 7 The illustration shows an example of an AI application juxtaposed with a gNB and its associated DCAF deployment; Figure 8 The illustration shows a deployment example of an AI application co-located with a gNB and DCAF deployed outside the access network. Figure 9 The illustration shows an example of an AI application and DCAF deployed outside the access network; Figure 10 An example of an MNO integration architecture for data collection is illustrated; Figure 11 The diagram illustrates the use of Figure 10 The architecture in the example is used via the control plane to align MDT and AI data reports through MDT reporting entities; Figure 12 The diagram illustrates the use of Figure 10 An example of an architecture in which the user plane directly collects data from clients to provide MDT and AI data reports; Figure 13 The diagram illustrates the case where UPF and DCAF are co-located with RAN. Figure 11Examples of variations of the architecture in the example; Figure 14 The diagram illustrates the case where UPF and DCAF are co-located with RAN. Figure 12 Examples of variations of the architecture in the example; Figure 15 An example of policy-based authorization for WTRU data collection is depicted; Figure 16 The call flow is depicted as an example of policy-based user consent; Figure 17 The call flow depicts an example of application-triggered WTRU data collection; Figure 18 The call flow is depicted as an example of RAN configuration during application-triggered WTRU data collection; Figure 19 This is an example of a call flow diagram illustrating WTRU data collection reporting when the report type is PMF; Figure 20 This is an example of a call flow diagram illustrating WTRU data collection reports when the report type is OTT; Figure 21 This is an example of a call flow diagram illustrating WTRU data collection reports when the report type is MDT; Figure 22 The diagram illustrates an example of WTRU data collection configuration and reporting; Figure 23 The illustration shows an example of a diagram for WTRU data collection via PMF user plane adaptation according to one embodiment; Figure 24 The illustration shows an example of an instantiation of a direct data collection client in a PMF application according to one embodiment; Figure 25 The illustration shows an example of an MDT activation mechanism that enables routing MDT measurements via direct data collection client, according to one embodiment. Figure 26 The diagram illustrates an example call flow for user consent verification based on an MNO; and Figure 27 The illustration shows an example call flow for an MNO-based configuration of WTRU data collection. Detailed Implementation

[0006] The following abbreviations used in this article have the following extensions.

[0007] AF application functions AMF Access and Mobility Management Functions App ID ASP application service provider DCAF Data Collection Application Functions DN Data Network DNN Data Network Name Minimum Drive Testing (MDT) MNO mobile network operator NEF Network Exposure Function NR New Radio NSSAI Network Slice Selection Auxiliary Information NSI ID (Network Slice Instance Identifier) OFDM (Orthogonal Frequency Division Multiplexing) OSid (Operating System Identifier) PCF policy control function PDU Protocol Data Unit PMF performance management functions RAN (Radio Access Network) RRC Radio Resource Control S-NSSAI Single NSSAI SUPI subscription permanent identifier UDM Unified Data Management User Equipment (UE and WTRU can be used interchangeably in this document) UPF User Plane Functions URSP UE routing policy WLAN (Wireless Local Area Network) and related technologies (IEEE 802.xx domain) WTRU (Wireless Transmitter / Receiver Unit) (WTRU and UE can be used interchangeably in this document)

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

[0009] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will be appreciated that the disclosed embodiments are contemplated to 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. For example, WTRUs 102a, 102b, 102c, and 102d—any of which can be referred to as a “station” (STA)—can be configured to transmit and / or receive wireless signals and can include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

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

[0011] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, and the like. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for radio services to a specific geographic area, which may be relatively fixed or may change over time. The cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, 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 a desired spatial direction.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0025] Despite Figure 1B While the transmit / receive element 122 is described 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 via the air interface 116.

[0026] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multimode capability. Therefore, transceiver 120 can include multiple transceivers for example enabling WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

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

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

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

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

[0031] WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with a specific subframe for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference via hardware (e.g., a choke) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with a specific subframe for UL (e.g., for transmission) or DL ​​(e.g., for reception) may be concurrent and / or simultaneous.

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

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

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

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

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

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

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

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

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

[0041] In a representative embodiment, another network 112 may be a WLAN.

[0042] In Infrastructure Basic Services Set (BSS) mode, a WLAN may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access to or interfacing with a Distributed System (DS) or carry services within and / or out of the BSS to another type of wired / wireless network. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined outside the BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be sent via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between a source STA and a destination STA (e.g., directly between the source STA and the destination STA) using Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to as the "self-organizing" communication mode in this document.

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

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

[0045] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight adjacent 20 MHz channels, or by combining two non-adjacent 80 MHz channels—this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

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

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

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

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

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

[0051] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute durations).

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

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

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

[0055] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types being used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, and so on. AMF 182a and 182b can provide control plane functions for switching between RAN104 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.

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

[0057] UPF 184a and 184b can be connected via an N3 interface to one or more of gNB 180a, 180b, and 180c in RAN 104. This N3 interface provides WTRU 102a, 102b, and 102c with access to a packet-switched network (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-destination PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and so on.

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

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

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

[0061] One or more emulation devices may perform one or more functions (including all functions) but are not implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in test scenarios in a test laboratory and / or in non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices may be test equipment. Emulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0062] The procedures for WTRU data collection and reporting for AIML applications can specify a mechanism executed by the Network Data Analysis Function (NWDAF) to collect data from the WTRU via an intermediate entity of the function (e.g., the Application Function (AF)). Functionality supported by 5G systems (5GS) can include client configuration for WTRU data collection and reporting, WTRU procedures for reporting the collected data, and the subsequent exposure of the reported WTRU-collected data to the AF.

[0063] Figure 2 A diagram depicts a reference architecture for WTRU data collection.

[0064] WTRU data is collected by WTRU applications 201, such as Artificial Intelligence Machine Learning (AIML) applications, and reported to WTRU Direct Data Collection Client 202 for further processing and filtering. Direct Data Collection Client 202 may submit data reports to Data Collection Application Function (DCAF) 203 in the network. Receipt of data reports by DCAF 203 may expose events to interested event consumers, such as Network Data Analysis Function (NWDAF) 204, which may have previously subscribed to the event.

[0065] An event consumer is a subscriber to event data at the DCAF. In 3GPP standards, the term event consumer is used synonymously with the terms NF consumer or NF service consumer. An event consumer managed by a mobile network operator (MNO) is an instance of an event consumer managed by the MNO, such as a network entity like a Network Function (NF) or AF, or may be an event consumer. Event data is data exposed to event consumers by the DCAF. In 3GPP standards, the term event data is used synonymously with the term event reporting information. Exposure can be implemented via a Network Exposure Function (NEF), for example, for untrusted event consumers, or, in the absence of a NEF, for example, for trusted event consumers.

[0066] The direct data collection client is the functional entity in the WTRU that collects data and reports it to the DCAF. It supports three data reporting reference points: the direct data collection client, the indirect data collection client, and the application server (AS).

[0067] Figure 3 An example of a reporting mechanism is illustrated.

[0068] In direct reporting, data reports can be sent from the direct data collection client 301 to the DCAF 302 via the R2 interface 303. In indirect reporting, data reports can be sent from the WTRU application 304 to the DCAF 302 via the indirect data collection function 305 of the application service provider (ASP) 306. In the case of indirect reporting, data reports can be sent from the WTRU application 304 to the indirect data collection function 305 in the ASP 306 via the user plane, i.e., the R8 interface 307. The indirect data collection function 305 can then send the data report to the DCAF 302 via the R3 interface 308. The data can then be exposed to the NWDAF 309 via the R5 interface 310.

[0069] DCAFs can register with 5GC (e.g., via NRF based on the Nnrf service's reference point) to indicate their event reporting capabilities by specifying the event IDs they support. For example, an event ID could refer to a report of WTRU data consumption. ASPs interested in exposing application-specific events (e.g., Quality of Experience (QoE)) from WTRU applications can use the R1 interface to configure WTRU data collection and reporting in one or more DCAFs dispatched to one or more WTRUs running the applications of interest.

[0070] The direct data collection client in WTRU can use the R2 interface to obtain data collection and reporting configuration. The direct data collection client in WTRU can receive context information from the WTRU application via the R7 interface, which can trigger the direct data collection client to obtain the required configuration from the DCAF. When WTRU data collection is complete, WTRU can submit a data report through the same interface (i.e., R2).

[0071] Figure 4 The diagram illustrates an example call flow for a WTRU configuration procedure used for data collection and data reporting.

[0072] The ASP can configure the application in WTRU via a user plane 401. This configuration can include information such as authentication information, user consent, or the address of the relevant DCAF (e.g., the DCAF's IP address).

[0073] The ASP provisioning function can configure the provisioning of data reporting and WTRU data collection in DCAF402 for a specific application identified by an App ID and one or more specific events. Based on operator policies, DCAF can authorize or deny provisioning requests.

[0074] WTRU applications can be triggered by ASP applications to establish a context with a direct data collection client 403, for example by providing authentication credentials, user consent, and the fully qualified domain name (FQDN) of the relevant DCAF.

[0075] A direct data collection client triggered by a WTRU application establishing a context can retrieve client configuration from DCAF 404 for the relevant application identified by the App ID and addressed by the FQDN provided by the WTRU application.

[0076] The direct data collection client can configure WTRU applications 405 for WTRU data collection and reporting based on the configuration obtained from DCAF.

[0077] Figure 5 The diagram illustrates a sample call flow from a WTRU data report.

[0078] Based on the configuration obtained from the direct data collection client, the WTRU application can report relevant data. This can be done directly with a 501 or indirectly with a 503.

[0079] DCAF can receive data reports directly via 502 or indirectly via 504.

[0080] DCAF can handle 506 reports and determine whether an event needs to be reported. If so, it determines when it needs to be reported (e.g., immediately, later, or based on a certain condition) and the event consumer, such as NWDAF. DCAF can expose event 506 to event consumers who have previously subscribed to the event. DCAF can provide the WTRU ID, event ID, and event-specific parameters, such as experience quality information.

[0081] Direct data collection client functions can be instantiated within other WTRU functions to meet domain-specific data collection and reporting requirements corresponding to the specific characteristics of 5G systems.

[0082] Therefore, several reporting domain-specific data collection client instances can exist simultaneously on a given WTRU, each performing a different role. An effective deployment option would be to combine these instances into a common middleware component. Another option is to provide a direct data collection client as an integration component for each relevant WTRU application.

[0083] Figure 6 A diagram depicting an instantiation of a direct data collection client as part of a WTRU application.

[0084] In this example, WTRU 601 includes WTRU application 602, and direct data collection client 603 is instantiated as part of the application. Direct data collection client 603 communicates with DCAF 604 via R2 interface 605. WTRU application 602 communicates with ASP 606 via R8 interface 607.

[0085] The WTRU will report the collected data to the network, thus enabling routing improvements for WTRU data reports and the potential deployment of applications and / or associated DCAFs closer to the Radio Access Network (RAN), such as near or in the same location as the gNB. This can optimize the data path between direct data collection clients and DCAFs that may be located in the same location as the gNB, as well as applications that may reside in the gNB.

[0086] Figure 7 The illustration shows an example of an AI application juxtaposed with a gNB and its associated DCAF deployment.

[0087] AI application 701 can be deployed in RAN node 702. In this example, DCAF 703 can also be implemented in RAN node 702. DCAF 703 can be implemented as part of AI application 701, such as... Figure 7 As shown in the example.

[0088] Figure 8The illustration shows a deployment example of an AI application co-located with a gNB and DCAF deployed outside the access network.

[0089] In this example, AI application 801 is co-located with gNB 802. DCAF 803 is located outside the access network, for example, outside the gNB. DCAF 803 can be part of the CN or outside the CN. AI application 801 can provide DCAF 803 through R1 interface 804. Optionally, a new interface from gNB to DCAF can be defined.

[0090] Figure 9 The illustration shows an example of an AI application and DCAF deployed outside the access network.

[0091] In this example, gNB 901 can provide AI-specific parameters to AI application 902 based on the specific use cases or characteristics that gNB wants the AI ​​application to perform. These parameters can be provided to AI application 902 directly from gNB via a new interface 903, or via CN, for example, using an enhanced N2 procedure (e.g., via AMF / SMF). Application-specific provisioning can then be performed via R1 interface 904.

[0092] An MNO can be enabled to control and manage the configuration of WTRU data collection, WTRU data reporting, and WTRU data exposure. This can include specific operator policies governing the authorization mechanism in the DCAF or operator policies that are directly updated to WTRU direct data collection clients. Among other considerations, end-user security, RAN configuration requirements for model training, and the impact on 5G systems can be taken into account.

[0093] 5GS can support WTRU data collection on the control plane, such as through Minimized Drive Testing (MDT). Application-specific WTRU data reporting and MDT data reporting can coexist and benefit from each other. Mechanisms can be used to determine when to use one mechanism without the other, or when to combine them.

[0094] WTRU data can be reported independently of the existing MDT data reporting mechanism, or it can be reported in conjunction with the existing MDT data reporting mechanism. CN can use policies to configure WTRU to enable federated or independent data reporting.

[0095] Figure 10 An example of an MNO integration architecture for data collection is illustrated.

[0096] In one example, WTRU data can be sent to DCAF 1001 via the control plane, for example, using RRC or NAS signaling. In another example, WTRU data can be sent to DCAF via the user plane, for example, using a PDU session. In one example, WTRU data can be reported to DCAF 1001 using a direct connection 1002 from the gNB to DCAF. In another example, WTRU data can be reported via control plane 1003, for example, using RCC signaling and / or NAS signaling. In another example, WTRU data can be reported to DCAF via data plane using PDU session 1004. In yet another example, RRC can send data to UPF 1005, possibly using gateway functionality between RRC and UPF. Figures 11 to 14 The diagram shows the use of... Figure 10 Examples of some of these different options are implemented in the architecture.

[0097] Figure 11 The diagram illustrates the use of Figure 10 The architecture in the example is an example of an architecture that aligns with MDT and AI data reports via the control plane and the MDT reporting entity.

[0098] The WTRU can combine collected AI data and collected MDT data and report them via the control plane. In this example, the Direct Data Collection Client 1101 is shown as a separate entity of the AI ​​Application Client 9002. In another example, the Direct Data Collection Client 1101 can be instantiated as part of the AI ​​Application Client 1102. In this example, the combination / aggregation of the two types of data (e.g., collected AI data and collected MDT data) can be performed by the Direct Data Collection Client 1101 in the WTRU or by the MDT entity in the WTRU 1103. This information can be sent by the WTRU to the network in a NAS message encapsulated in an RRC message 1104. The NAS message 1105 can be forwarded to the AMF / SMF 1106 in the CN. The AMF / SMF 1106 can interface with the DCAF 1107 directly or via the NEF 1108.

[0099] Figure 12 The diagram illustrates the use of Figure 10 The architecture in the example is an example of an architecture that connects to MDT and AI data reporting via a user plane and a direct data collection client.

[0100] The WTRU can combine collected AI data and collected MDT data and report them via the user plane. In this example, the direct data collection client 1201 is shown as a separate entity of the AI ​​application client 1202. In another example, the direct data collection client 1201 can be instantiated as part of the AI ​​application client 1202. In this example, the combination / aggregation of the two types of data (e.g., collected AI data and collected MDT data) can be performed by the direct data collection client 1201 in the WTRU or by the MDT entity in the WTRU 1203. The WTRU can send the combination information 1204 to the DCAF via the user plane using PDU session 1204.

[0101] Figure 13 The diagram illustrates the case where UPF and DCAF are co-located with RAN. Figure 11 Examples of variations of the architecture in [the document / framework].

[0102] exist Figure 13 In the example, a combined report is sent to RRC entity 1301 via the control plane in RRC message 1302. RRC 1301 can process this information and send it to Gateway Function / Local Switch 1303, which forwards it to UPF 1304. From UPF 1304, the data can be reported to DCAF 1305. In one example, UPF 1304 and AI Application Server / DCAF 1305 can be located at RAN location 1306 with the gNB to minimize end-to-end latency.

[0103] Figure 14 The diagram illustrates the case where UPF and DCAF are co-located with RAN 1401. Figure 12 Examples of variations of the architecture.

[0104] This document discloses embodiments to address MNO-driven WTRU data collection and reporting. WTRU data collection based on the MNO and AF authorization controlled by the MNO are used to configure AI applications, operating entirely on top of the 5GS as currently defined. Therefore, new procedures can be required to enable the MNO to authorize, configure, and filter WTRU measurements using existing policy frameworks. Utilizing current user consent information stored in subscriber records to assist in determining which WTRU data / measurements should be allowed can be beneficial.

[0105] Figure 15 An example of policy-based authorization for WTRU data collection is depicted.

[0106] In this example, a policy-based mechanism enables the MNO to control WTRU data collection. The ASP can request authorization from the CN to configure AI application parameters to enable WTRU data collection, for example, for model training and / or inference. The AF can provide the DNN, S-NSSAI, AF service ID, and expected configuration data for collecting AI application data, such as configuring measurements to obtain data for model training.

[0107] The NEF can obtain user consent and authorization for the intended WTRU data collection configuration through user consent (Figure 1502), and may filter user consent for specific measurements or data. Furthermore, operator policies may allow specific ASPs (such as those defined by the AF service ID) to perform direct WTRU data collection configuration procedures entirely on the user plane.

[0108] User consent graphs can include filters or associations for user consent to specific measurements or data collected.

[0109] When performing direct ASP / WTRU application configuration, NEF can provide a user consent graph and tokens or security reference 1503 that ASP can use to authenticate user consent.

[0110] Figure 16 An example call flow based on policy-based user consent is depicted.

[0111] A WTRU can register with the network and can provide its WTRU data collection 5GMM CN capability, indicating its ability to collect application-specific measurements, such as AI application measurements used for model training. This capability can be sent in a NAS message, for example, in a NAS registration request message 1601. The presence of this information can trigger the AMF to obtain user consent and associated WTRU data collection permission from subscriber records. The data collection permission can be based on user consent.

[0112] Data collection permission is the type of data collection that is permitted, such as Performance Management Function (PMF), Minimum Drive Test (MDT), Overhead Test (OTT), or a combination of these types or mechanisms.

[0113] AMF can request WTRU data collection subscription information 1602 from UDM. The existence of the WTRU data collection 5GMM CN capability provided by WTRU in the registration request message signals AMF to obtain user consent and, based on user consent, obtain the associated WTRU data collection permission from the subscriber record.

[0114] UDM can provide AMF with WTRU data collection permission and user consent (Figure 1603).

[0115] AMF can provide the WTRU with a user consent graph, the associated S-NSSAI, and the DNN in which WTRU data collection is authorized, as well as a user consent token 1604. The consent token can be used to provide user consent integrity and DCAF authentication credentials. For example, this can be sent in a NAS registration acceptance message.

[0116] The 5G NAS layer in WTRU can deliver user consent purposes and user consent tokens to direct data collection clients for each App ID, ensuring that user consent is not tampered with at the application layer 1605. The user consent purpose is user consent associated with a specific application ID; for example, a user might be able to consent to data collection on an application-by-application basis, and the token can also be associated with the user consent purpose.

[0117] Figure 17 The call flow is depicted as an example of application-triggered WTRU data collection.

[0118] When a WTRU AI application requests a data connection that leads to the establishment or modification of a PDU session for the purpose of contacting the DCAF, the AI ​​AF, which has been authorized to configure the WTRU AI application client, can request a notification from the 5GS. The notification request / response can be enabled by the NEF. This is illustrated in 1700a and 1700b.

[0119] WTRU AI applications can trigger requests for WTRU data collection configurations. This can be achieved by triggering requests for data connections from the NAS layer to a specific DNN and S-NSSAI within the WTRU direct data collection client.

[0120] The WTRU AI application can request WTRU data collection configuration from the direct data collection client 1701, providing the App ID and user consent token received from the AI ​​AF. The WTRU AI application can request modifications to the data connection if, for example, the perceived quality of experience is suboptimal.

[0121] The Direct Data Collection (DGC) client can verify user consent. To verify consent, the DGC client compares a token received from the AF with a token received from the network / UDM. When the two tokens match, user consent is confirmed / authorized. If authorized, the DGC client requests a data connection from NAS layer 1702, providing the APP ID, OSid, DNN, and S-NSSAI. If the WTRU AI application requests modification to the data connection supporting the application, the DGC client can request modification of the PDU session, causing the NAS layer to trigger a PDU session modification request, for example, using an Attention (AT) command.

[0122] The NAS layer in the WTRU can send a PDU session establishment request message 1703 to the AMF, indicating the selected WTRU data collection type (e.g., PMF, MDT, hybrid), and it also indicates a new PDU session request type to signal that the PDU session will be used for WTRU data collection. Alternatively, if an existing PDU session exists that supports WTRU data collection, the WTRU or the network (e.g., the SMF) can request updates to the parameters of the existing PDU session using a PDU session modification procedure. For example, the WTRU can request a new QoS value, or the SMF, prompted by a modification associated with a session management policy from the PCF, can request a policy modification, such as a new WTRU data collection mechanism.

[0123] SMF can request SM policy association from PCF 1704, and it provides the request type to indicate the establishment of a PDU session for WTRU data collection purposes.

[0124] PCF can provide WTRU data collection strategies 1705, including guidance on when WTRU data collection can be applied under system conditions including slice loads, specific WTRU data collection mechanisms such as Performance Measurement Function (PMF), Drive Test Minimization (MDT), Overhead Test (OTT) or combinations thereof, and geographical and validity conditions.

[0125] Figure 18 The example call flow of the RAN configuration during application-triggered WTRU data collection is depicted.

[0126] AMF can send a response 1801 to a subscription request (which is in...) Figure 17 (See diagram 1700b in the diagram), and it can include the address of the DCAF, which the AI ​​AF can use to configure the WTRU AI application client.

[0127] SMF, for example, using Initial Context Setup Message 1802, can leverage RAN WTRU data collection policies to configure gNB, including sliding load tolerance and QoS thresholds.

[0128] gNB, for example using RRC signaling 1803, can leverage relevant AI model measurements and permitted WTRU data collection mechanisms to configure the WTRU RRC layer for each App ID.

[0129] In response to PDU session establishment request message 1703, SMF can use PDU session establishment accept message 1804 to deliver a new WTRU data collection policy to WTRU NAS layer 1406, including WTRU data collection auxiliary information, permitted data collection mechanisms (i.e., PMF, OTT, MDT or a combination thereof), QoS parameters for each QoS flow associated with a specific WTRU application layer measurement, and the associated DCAF address.

[0130] The NAS layer can pass WTRU data collection assistance information, permitted data collection mechanisms (i.e., PMF, OTT, MDT or a combination thereof) and associated DCAF address 1805 to the upper layers.

[0131] The direct data collection client can use the WTRU data collection assistance information received from the NAS layer 1806 to configure the WTRU AI application 1408 for each App ID.

[0132] Regarding MNO integration with WTRU data collection reporting, depending on the data reporting configuration, WTRU can use data collection types (i.e., PMF, MDT, OTT) or combinations thereof to report WTRU data collection results.

[0133] Figure 19 This is an example of a call flow diagram for a WTRU data collection report when the report type is PMF.

[0134] PMF can be instantiated as a direct data collection client. WTRU AI applications can request application-layer measurements from the WTRU direct data collection client 1901. WTRU AI applications provide GPSI, App ID, and DCAF address.

[0135] If the direct data collection client is configured to use PMF functionality to request WTRU AI measurements, the instantiation of the PMF application can request the relevant application layer measurements from RRC layer 1902 and provide the relevant application layer measurement configuration provided by the WTRU AI application.

[0136] The RRC layer in the WTRU can request application layer measurement control 1903 from the gNB to provide guarantees, such as that the measurements are performed using applicable QoS and are done according to the configuration provided in the RAN WTRU data collection rules, as well as details of the application layer measurements (e.g., whether these measurements are intended for location, beamforming channel state indication (CSI) model training, for example, by using a model ID provided by the WTRU AI application). The gNB can modify the application layer measurement reporting mechanism at any time, for example, based on cell load, slice load, geographic, or time-based conditions.

[0137] The RRC layer can provide suitable AI application layer measurements 1904.

[0138] The PMF client can forward AI application WTRU data collected for a specific WTRU AI application 1905, and it provides an App ID, PDU session ID, and (one or more) QFIs. PMF instantiation in DCAF uses the App ID, PDU session ID, and (one or more) QFIs to identify a specific instance of the WTRU AI application for which data has been collected.

[0139] Figure 20 This is an example of a call flow diagram illustrating the WTRU data collection report when the report type is OTT.

[0140] The WTRU AI application can request application-layer measurements from the direct data collection client. The WTRU AI application provides GPSI, App ID, and DCAF address.

[0141] If the direct data collection client is configured to request WTRU AI measurements using an over-the-top (OTT) data connection mechanism, the direct data collection client can request the relevant application-layer measurement 2002 from the RRC layer and can provide the relevant application-layer measurement configuration, which is provided directly to the DCAF address by the WTRU AI application through either the WTRU data collection rules or the DCAF address information provided by the WTRU AI application. The WTRU data collection rule information resides on the DCAF address provided by the WTRU AI application.

[0142] The RRC layer in the WTRU can request application layer measurement control 2003 from the gNB to ensure that measurements are performed using applicable QoS, and the measurements are performed based on the configuration provided in the RAN WTRU data collection rules and the details of the application layer measurements (e.g., whether these measurements are intended for positioning, beamforming, or CSI model training, for example, by using a model ID provided by the WTRU AI application). The gNB can modify the application layer measurement reporting mechanism at any time, for example, based on cell load, slice load, geographic, or time-based conditions.

[0143] The RRC layer can provide applicable AI application layer measurements 2004.

[0144] The Direct Data Collection (DCAF) forwards WTRU data collected for a specific WTRU AI application (2005) to the DCAF. It can provide an App ID, PDU session ID, and (one or more) QFIs. The DCAF can use the App ID, PDU session ID, and (one or more) QFIs to identify a specific instance of the WTRU AI application for which it has collected data.

[0145] Figure 21 This is an example of a call flow diagram illustrating the WTRU data collection report when the report type is MDT.

[0146] The WTRU AI application can request application-layer measurements from the direct data collection client 2101. The WTRU AI application provides GPSI, App ID, and DCAF address.

[0147] The direct data collection client requests relevant application layer measurements from RRC layer 2102 and provides the relevant application layer measurement configuration provided by the WTRU AI application, including the DCAF address, PDU session ID, and (one or more) QFIs.

[0148] The RRC layer in the WTRU requests application layer measurement control 2103 from the gNB to provide (e.g., guarantee) the use of applicable QoS to perform measurements, and performs the measurements according to the configuration provided in the RAN WTRU data collection rules and the details of the application layer measurements (e.g., whether these measurements are intended for positioning, beamforming, or CSI model training, for example, by using a model ID provided by the WTRU AI application). The gNB can modify the application layer measurement reporting mechanism at any time, for example, based on cell load, slice load, geographic, or time-based conditions.

[0149] The RRC layer can use RCC signaling to forward applicable AI application layer measurements via gNB, and it provides GPSI, PDU session ID, and QFI9 2104.

[0150] The gNB can use NGAP signaling to forward applicable AI application layer measurements 2105 to the AMF, and it provides GPSI, PDU session ID, and (one or more) QFIs.

[0151] AMF can forward applicable AI application layer measurements 2106 to DACF (possibly via NEF), and it provides, for example, GPSI, PDU session ID, and (one or more) QFIs in the Naf_Event_Notification message.

[0152] exist Figures 19 to 21 In the example, DCAF can provide event notification services to service consumers (e.g., NWDAF).

[0153] Figure 22 The diagram illustrates an example of WTRU data collection configuration and reporting.

[0154] NAS layer 2201 may provide WTRU data collection rules or rule sets to direct data collection client 2203, which instruct the direct data collection client 2203 on reporting mechanisms for application-layer specific WTRU data measurements. For example, the rules may indicate that for a specific geographic location (e.g., cell ID or band) or a specific time period (e.g., during midnight maintenance), WTRUs may be permitted to collect data from a specific application on a specific network slice, possibly using slice load as a criterion for reporting. The rules may also include reporting mechanisms such as PMF, MDT, or OTT.

[0155] Based on the aforementioned rules, the data measurements to be collected can be configured at RRC layer 2204. RRC layer 2204 can report measurements 2205 to direct data collection client 2203. In the case of a PMF reporting mechanism, direct data collection client 2203 or PMF 2206 can report measurements to DCAF 2207. This reporting can be implemented on user plane 2208 / R8 interface 2209, or on control plane 2209 via RRC 2206 in the RRC application layer measurement container.

[0156] WTRU data reporting rules can also instruct RAN reporting controls, for example, to extend existing RAN-visible QoE (or QoS) measurements, and to define new sets of measurements, for example, based on models that need to be trained, such as measurements used to train localization models.

[0157] Direct data collection clients can be instantiated as extensions of the PMF protocol. DCAFs can be housed within a PSA. AI AFs can be standalone or located within a single PSA.

[0158] Figure 23 An example diagram illustrating WTRU data collection via PMF user plane adaptation is shown according to one embodiment.

[0159] exist Figure 23 In the example, the configuration of MDT data measurement can be achieved by inserting an adapter layer 2301, which maps or transforms (via the adapter layer) configuration commands from the AI ​​App extension into MDT configuration information. The MDT configuration information can be directly injected (2303) into the RRC layer 2304, as depicted by the arrow 2303 pointing from the adapter layer to the RRC layer.

[0160] Figure 24 An example of a diagram illustrating the instantiation of a direct data collection client in a PMF application according to an embodiment.

[0161] In Figure 24 the example of, the AI application function may be able to configure MDT functionality by contacting the direct data collection client with an adaptation layer 2401, similar to Figure 23 2301. Also here, the downward arrow 2402 illustrates the configuration of MDT measurements in the RCC layer, as indicated by the AI application function.

[0162] Figure 25 An example of an MDT activation mechanism enabling routing of MDT measurements through a direct data collection client according to an embodiment.

[0163] In Figure 25 the example of, the RCC layer may send MDT measurements via the direct data collection client, which is illustrated by an arrow from the RCC layer up to the WTRU AI application 2501. The WTRU AI application may then send the data to the AI application function (similar to Figure 24 the example in).

[0164] For the WTRU, in order to collect and report data that can be used by the access network (e.g., gNB) for AI-based network optimization, it is desirable to configure WTRU data collection to meet the AI requirements for the access network. It is also desirable to enhance 5GS to enable coexistence and cooperation of application-specific WTRU data collection and MDT-based data collection.

[0165] It is desirable for the MNO to provide policies associated with how to collect application-specific data in their networks. The operator policies can then be used to configure the RAN and WTRU to enable MNO-managed WTRU data collection for AI applications.

[0166] Figure 26 An example call flow based on MNO user consent verification is illustrated.

[0167] Initially, the AF provides user consent tokens to WTRU 2600a, 2600b. The AF obtains the user consent tokens from the core network.

[0168] The WTRU NAS layer can register with the network 2601 and indicate its data collection capabilities. In response, the network (e.g., AMF) can provide a user consent token, a user consent graph, an associated S-NSSAI, and a DNN, where WTRU data collection is authorized 2602. The consent token can be used to provide user consent integrity and DCAF authentication credentials. The WTRU NAS layer can deliver the user consent token and user consent purpose to the direct data collection client for each App ID 2603.

[0169] The WTRU AI application can trigger a request for WTRU data collection configuration 2604. This can trigger a request from the NAS layer in the WTRU direct data collection client for data connectivity for a specific DNN and S-NSSAI. The WTRU AI application can provide the App ID and user consent token received from the AI AF. The WTRU can verify the user consent by comparing the user consent initially received from the AF 2600b with the user consent received from the AMF 2603 2605.

[0170] Figure 27 An example call flow for MNO-based configuration of WTRU data collection is illustrated.

[0171] After user consent 2605, if the WTRU is authorized, the direct data collection client can request PDU session establishment from the NAS layer 2701. The NAS layer can send a request to the CN (e.g., AMF) 2702 indicating that the PDU session is to be used for transmitting WTRU data collection, and it can indicate the preferred WTRU data collection type (e.g., PMF, MDT, OTT, hybrid). The SMF can obtain the data collection policy from the PCF 2703.

[0172] In the acceptance response 2704, the network can include WTRU data collection assistance information, permitted data collection mechanisms (e.g., PMF, OTT, MDT, or a combination thereof), and the associated DCAF address. The direct data collection client in the WTRU can use the WTRU data collection assistance information received from the NAS layer to configure the WTRU AI application 2705. If there are more than one application, this can be done for each application based on the App ID.

[0173] When requested by the WTRU application 2706, the direct data collection client in the WTRU can obtain measurements from the RRC layer and send the measurements to the network. The reporting can be done using PMF on the PMFP, or DCAF on the user plane, or MDT on the RRC signaling.

[0174] Note that the signaling and procedures described above are examples and are not restrictive. For instance, several other possibilities for controlling the data collection process and transmitting the collected data are given below.

[0175] In one embodiment, the OTT server can directly request the collection of RAN / CN data for some AIML-related operations (such as training), and the RAN / CN can control the entire data collection process on behalf of the OTT server (e.g., select the WTRU from which to collect data, initiate a data collection procedure, collect data from different WTRUs, etc.), and can provide the collected data to the OTT server.

[0176] In one embodiment, the RAN or CN may have proactively collected data from numerous WTRUs and may provide a subset of the collected data to the OTT server upon request.

[0177] In one embodiment, the OTT server may be pre-registered to be notified when a particular type of collected data becomes available at the RAN / CN (e.g., data collected at a particular location, time of day, containing specific information elements, from a particular type of user, and / or serving cell frequency).

[0178] In one embodiment, the RAN / CN may modify the collected data before sending it to the OTT server. For example, the RAN / CN may remove / obfuscate / randomize certain information elements, such as WTRU identity and location, to ensure that user privacy / anonymity is protected and / or confidential network information, such as configuration / deployment information, is not disclosed to external OTT entities.

[0179] In one embodiment, data collection from the WTRU can be performed using legacy data collection mechanisms such as Radio Resource Management (RRM) measurement reports, MDT, QoE reports, etc., and the WTRU may not even be aware that the data will be used outside the network (e.g., for AIML training or performance monitoring purposes).

[0180] In one embodiment, the WTRU knows / is informed of the purpose of the data collection. This can be part of the initial registration / user consent provisioning process, or it can be done independently. For example, the user may give consent for the data to be used for a specific purpose but not for other purposes, and the RAN / CN may prevent such information from being provided to an external OTT server (or at least allow such information to be transformed in a way that is undetectable from the collected data as user / WTRU information).

[0181] In one embodiment, the WTRU may have full or partial autonomy in performing data collection and transmitting the collected data. For example, the OTT / RAN / CN may request to initiate a data collection procedure, and the WTRU may refuse to collect data (e.g., by sending a response with a rejection message indicating a reason for rejection, such as limitations of resources like battery or memory). This rejection may be temporary or final (e.g., the WTRU may indicate that data collection can be performed later or when certain conditions are met).

[0182] In one embodiment, the WTRU / user voluntarily collects data and notifies the RAN / CN / OTT (e.g., indicating the types of data the WTRU / user is willing to collect and report and / or the amount / size of data to be reported).

[0183] In one embodiment, a WTRU that has established a PDU session and / or RRC connection can request the RAN / CN to modify the PDU session and / or reconfigure the RRC connection to accommodate / facilitate data collection and the transmission of collected data. For example, the WTRU can request modification or establishment of one or more radio bearers for data transmission, request the network to provide additional information such as measurement configurations of neighboring cells, inter-frequency cells, etc., and / or request the network to begin transmitting additional reference signals, etc.

[0184] In one embodiment, the WTRU can terminate or pause ongoing data collection (e.g., if the size of the collected data becomes larger than a certain amount, if the WTRU battery power drops below a certain level, if the WTRU has overheated, etc.) and can notify the RAN / CN / OTT server.

[0185] In one embodiment, the WTRU can terminate or suspend the ongoing transmission of collected data (e.g., for reasons such as terminating / suspending data collection).

[0186] In one embodiment, the WTRU can resume / restart a paused / terminated data collection procedure and can notify the network / OTT server. In an alternative embodiment, the WTRU can notify the network / OTT server that data collection can be resumed / restarted, and then resume data collection.

[0187] In one embodiment, the WTRU can decide to resume / restart the paused / terminated transmission of the collected data and can send instructions / requests to the network / OTT server.

[0188] Devices and systems that can be constructed, configured, or operated based on the topics disclosed herein include smartphones, tablets, wearable devices, head-mounted displays, connected vehicles, drones, CPE gateways, access points, base stations, core networks, and servers.

[0189] Regarding WTRU data collection and WTRU data collection authorization based on Mobile Network Operator (MNO), the AF performs the following actions: The AF provides DNN, S-NSSAI, AF service identifier or identifier (ID) and expected configuration data for collecting data for artificial intelligence (AI) applications, such as configuring measurements to obtain data for model training.

[0190] The Network Exposure Function (NEF) performs the following actions: The NEF obtains user consent and authorization for the intended WTRU data collection configuration from the Unified Data Management (UDM), potentially filtering user consent for specific measurements or data through a user consent graph. Furthermore, operator policies may allow specific ASPs (such as those defined by the AF service ID) to perform direct WTRU data collection configuration procedures entirely on the user plane; and when performing direct ASP / WTRU application configuration, the NEF provides a user consent graph and tokens or security references used by the ASP to authenticate user consent.

[0191] The WTRU performs the following actions: The WTRU registers with the network, and it provides its WTRU data collection 5GMM core network capabilities, indicating its ability to collect application-specific measurements, such as AI application measurements for model training; the presence of this information element signals the Access and Mobility Management Function (AMF) to obtain user consent and associated WTRU data collection permission from the subscriber record based on user consent; and at the WTRU, the 5G NAS layer delivers user consent for each App ID and a user consent token obtained from the AMF to ensure that user consent is not tampered with at the application layer.

[0192] The AMF performs the following actions: the AMF obtains user consent and associated WTRU data collection permission from the subscriber record; and the AMF also provides a user consent graph, associated S-NSSAI and DNN, where WTRU data collection is authorized, and the user consent token provides the integrity of the user consent, and the user consent token can also provide DCAF authentication credentials.

[0193] Regarding the establishment and provisioning of WTRU data collection connections, in one embodiment, the WTRU performs the following actions: The direct data collection client in the WTRU verifies user consent provided by the WTRU application, and if the request is authorized, the direct data collection client requests data connectivity from the NAS layer, providing the App ID, Operating System Identifier / Identifier (OSid), DNN, and S-NSSAI; the WTRU (NAS layer) issues a PDU session establishment request, indicating the selected WTRU data collection type (e.g., Performance Management Function (PMF), Minimum Drive Test (MDT), Hybrid), and it also indicates a new PDU session request type to signal the use of a PDU session for WTRU data collection; the NAS layer in the WTRU passes WTRU data collection assistance information, permitted data collection mechanisms (i.e., PMF, Overhead Test (OTT), MDT, or a combination thereof) and associated DCAF address to the upper layer; and the direct data collection client, according to the App ID, configures the WTRU AI application using the WTRU data collection assistance information received from the NAS layer.

[0194] The SMF performs the following actions: The SMF requests an SM policy association from the PCF, and it provides the requested type to the indicated PDU session establishment for the purpose of WTRU data collection; The SMF uses the PDU session establishment accept message to deliver a new WTRU data collection policy to the WTRU NAS layer, including WTRU data collection assistance information, permitted data collection mechanisms (i.e., PMF, OTT, MDT, or combinations thereof), QoS parameters for each QoS flow associated with a specific WTRU application layer measurement, and the associated DCAF address; and The SMF, for example, uses an initial context establishment message to configure the gNB using the RAN WTRU data collection policy, including sliding load tolerance and QoS thresholds.

[0195] PCF performs the following actions: PCF provides WTRU data collection strategies, including guidance on when WTRU data collection can be applied under system conditions including slice load, specific WTRU data collection mechanisms (such as PMF, MDT, OTT or combinations thereof), and geographical and validity conditions.

[0196] The RAN node (e.g., gNB) performs the following actions: the gNB, for example, uses RRC signaling, according to the App ID, to configure the WTRU RRC layer by utilizing the relevant AI model measurements and permitted WTRU data collection mechanisms.

[0197] Regarding the MNO integrated WTRU data collection report, WTRU performs the following operations: The WTRU AI application requests application-layer measurements from the WTRU direct data collection client. The WTRU AI application provides GPSI, App ID, and DCAF address. If the direct data collection client in WTRU is configured to use PMF functionality to request WTRU AI measurements, the instantiation of the PMF application requests the relevant application layer measurements from the RRC layer and provides the relevant application layer measurement configuration provided by the WTRU AI application. If the direct data collection client is configured to use the over-the-top data connection mechanism to request WTRU AI measurements, the direct data collection client requests the relevant application layer measurements from the RRC layer and provides the relevant application layer measurement configuration, which is provided directly to the DCAF address by the WTRU AI application through DCAF address information provided by the WTRU data collection rules or by the WTRU AI application. If the direct data collection client is configured to request WTRU AI measurements using MDT, the RRC layer forwards the applicable AI application layer measurements via gNB using RCC signaling, and it provides GPSI, PDU session ID, and QFI9.

[0198] The RRC layer in the WTRU requests application layer measurement control from the gNB to perform measurements using applicable QoS, and performs the measurements according to the configuration provided in the RAN WTRU data collection rules and the details of the application layer measurements, such as whether these measurements are intended for localization, beamforming, or CSI model training, for example, by using a model ID provided by the WTRU AI application; The RRC layer in WTRU provides applicable AI application layer measurements received from the gNB; If the reporting mechanism is from PMF to DCAF, the PMF client in WTRU forwards AI application WTRU data collected for a specific WTRUAI application to DCAF, and it provides the App ID, PDU session ID and (one or more) QFI; If the reporting mechanism is direct data collection from the client to the DCAF, the direct data collection client forwards AI application WTRU data collected for a specific WTRU AI application to the DCAF, and it provides the App ID, PDU session ID, and (one or more) QFIs; and If the reporting mechanism is RRC-AMF-DCAF, the direct data collection client requests the RRC layer to forward application layer measurements to the AMF via the gNB, and it provides the GPSI, PDU session ID, and (one or more) QFIs.

[0199] In one embodiment, the RAN node (e.g., gNB) performs the following actions: the gNB can modify the application layer measurement reporting mechanism at any time, for example, based on cell load, slice load, geographic or time-based conditions; for MDT-based WTRU data collection, the gNB uses NGAP signaling to forward the applicable AI application layer measurements to the AMF and provides GPSI, PDU session ID and(one or more) QFI.

[0200] In one embodiment, the Data Collection Application Function (DCAF) performs the following actions: instantiation of the PMF within the DCAF, or the DCAF itself, uses the App ID, PDU session ID, and (one or more) QFIs to identify a specific instance of a WTRU AI application for which data has been collected. The DCAF may provide event notification services to service consumers (e.g., NWDAF).

[0201] In one embodiment, the AMF performs the following action: the AMF forwards the applicable AI application layer measurement to the DACF (possibly via the NEF), and it provides, for example, the GPSI, PDU session ID, and (one or more) QFI in the Naf_Event_Notification message.

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

Claims

1. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Receive user consent tokens from the network; Based on the user consent token, it is determined that the user's consent has been authorized; Based on the determination that the user has agreed to be authorized, a request to establish a Protocol Data Unit (PDU) session is sent to the network, wherein the request includes a request type; Receive an indication from the network that a PDU session has been successfully established, wherein the indication includes data collection assistance information; Use data collection aids to determine data collection and reporting configurations; and Based on data collection and reporting configuration, application-specific measurement data is sent to the network using the established PDU sessions.

2. The method of claim 1, wherein the application of specific measurement data includes data associated with artificial intelligence machine learning (AIML) applications.

3. The method of claim 1 or claim 2, further comprising receiving a Data Collection Application Function (DCAF) authentication credential from the network.

4. The method according to any one of claims 1 to 3, further comprising receiving an instruction from the network for one or more data collection types.

5. The method according to any one of claims 1 to 4, wherein the request to establish a PDU session further includes an indication of one or more data collection types.

6. The method of claim 4 or claim 5, wherein the data collection type includes at least one of the following: a Performance Management Function (PMF) procedure, a Minimum Drive Test (MDT) procedure, or an Overhead Test (OTT) procedure.

7. The method according to any one of claims 1 to 6, wherein the request type indicates that the PDU session is for applying specific measurement data collection.

8. The method according to any one of claims 1 to 7, wherein the data collection auxiliary information includes one or more of the following: permitted data collection types, quality of service (QoS) parameters, or data collection application function (DCAF) addresses.

9. The method according to any one of claims 1 to 8, wherein the user consent token is received from the network during the WTRU registration process.

10. The method according to any one of claims 1 to 9, wherein the data collection auxiliary information is application-specific.

11. A wireless transmit / receive unit (WTRU), the WTRU comprising at least one processor and a transceiver, wherein: The at least one processor and transceiver are configured to: Receive user consent tokens from the network; Based on the user consent token, it is determined that the user's consent has been authorized; Based on the determination that the user has agreed to be authorized, a request to establish a Protocol Data Unit (PDU) session is sent to the network, wherein the request includes a request type; Receive an indication from the network that a PDU session has been successfully established, wherein the indication includes data collection assistance information; Use data collection aids to determine data collection and reporting configurations; and Based on data collection and reporting configuration, application-specific measurement data is sent to the network using the established PDU sessions.

12. The WTRU of claim 11, wherein the application-specific measurement data includes data associated with artificial intelligence machine learning (AIML) applications.

13. The WTRU according to claim 11 or claim 12, wherein the at least one processor and transceiver are further configured to: Receive Data Collection Application Function (DCAF) authentication credentials from the network.

14. The WTRU according to any one of claims 11 to 13, wherein the at least one processor and transceiver are further configured to receive instructions from the network for one or more data collection types.

15. The WTRU of any one of claims 11 to 14, wherein the request to establish a PDU session further includes an indication of one or more data collection types.

16. The WTRU of claim 14 or claim 15, wherein the data collection type includes at least one of the following: a Performance Management Function (PMF) procedure, a Minimum Drive Test (MDT) procedure, or an Overhead Test (OTT) procedure.

17. The WTRU of any one of claims 11 to 16, wherein the request type indicates that the PDU session is for applying specific measurement data collection.

18. The WTRU according to any one of claims 11 to 17, wherein the data collection assistance information includes one or more of the following: permitted data collection types, quality of service (QoS) parameters, or data collection application function (DCAF) addresses.

19. The WTRU according to any one of claims 11 to 18, wherein the user consent token is received from the network during the WTRU registration process.

20. The WTRU according to any one of claims 11 to 19, wherein the data collection assistance information is application-specific.

Images