EP4690924A1 - Data collection enhancements for artificial intelligence and machine learning - Google Patents

Abstract

Methods and apparatuses for collecting data for artificial intelligence (AI) and machine learning (ML) training and performance, may include a wireless transmit/receive unit (WTRU) being configured to perform and log various measurements. A WTRU may be configured to perform logging of beam/cell measurements of one or more cells, while in a connected state. The configuration may include conditions for determining when to start/stop logging, the cell/beam identities to be logged, conditions for determining which measurement results are to be included in the logging. The WTRU may be configured to perform the measurement logging, send an indication about the availability of the logged measurements, and send the report upon some condition.

Description

DATA COLLECTION ENHANCEMENTS FOR ARTIFICIAL INTELLIGENCE AND MACHINE LEARNING

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application Number 63/456,841 , filed April 4, 2023, the entirety of which is incorporated by reference herein.

BACKGROUND

[0002] A network or user equipment (UE), also referred to as a wireless transmit/receive unit (WTRU), that utilizes artificial intelligence (Al) and/or machine learning (ML) based functions, depends on data (e.g., radio quality measurements, quality of experience, quality of experience (QoE), measurements such as throughput, delay /latency, buffering levels, or the like, etc.) for model training and performance monitoring.

SUMMARY

[0003] In various example embodiments described herein, a WTRU may be configured to perform and log various measurements to facilitate the collection of data for AI/ML training and performance. A WTRU that utilizes Al and/or ML based functions may depend upon data measurements such as, for example, radio quality measurements, quality of service (QoS), quality of experience (QoE), throughput measurements, delay measurements, latency measurements, buffering levels, or the like. The measurements may be used for model training. The measurements may be used for performance monitoring. A WTRU may be configured to perform logging of beam/cell measurements of one or more cells, wherein the configuration may include conditions for determining when to start/stop logging, the cell/beam identities to be logged, conditions for determining which measurement results are to be included in the logging (e.g., conditions to determine whether to log an entry or not), perform the measurement logging, send an indication about the availability of the logged measurements, and send the report upon some condition (e.g., receiving a request/grant from the network), or the like, or any appropriate combination thereof.

[0004] In various examples, which will become evident in context of the herein description, to accomplish data collection for AI/ML a WTRU may be configured to perform and log measurements of a given beam. A WTRU may be configured to determine a cell quality for logging that considers all detected beams of a cell. A WTRU may be configured to perform logging under certain conditions (e.g., certain battery level, certain UL/DL throughput rate, certain data inactivity level, under certain mobility state, etc.). A WTRU may be configured to log measurements of beams/cells if the quality of the beam/cell is different from the previous logged measurement by a certain value/percentage. A WTRU may be configured to perform logging based on WTRU locations and/or WTRU actions that are being taken or anticipated to be taken. A WTRU may be configured to perform measurement/logging according to a first measurement/logging configuration before an action is taken or anticipated to be taken. A WTRU may be configured to perform measurement/logging according to a second measurement/logging configuration after an action is taken.

[0005] An example method for data measurement and logging may be performed by a WTRU. The method may include performing a measurement of at least one measurement object associated with at least one beam of at least one cell. While the WTRU is in a connected state, the method may include logging the at least one measurement, wherein the logging may be based on at least one condition. And, the method may include sending an indication that the at least one logged measurement is available. The method further may include sending a report comprising the at least one logged measurement. The report may be sent in response to a request from a network. The at least one condition may include when to start and stop the logging. The at least one condition may include an identification of at least one cell for logging. The at least one condition may include an identification of at least one beam for logging. The at least one condition may include an indication of at least one measurement object for logging.

[0006] An example WTRU configured to measure and log data may comprise a transceiver and a processor. The WTRU may be configured to perform a measurement of at least one measurement object associated with at least one beam of at least one cell. While in a connected state, the WTRU may log the at least one measurement, wherein the logging is based on at least one condition. And the WTRU may send, via the transceiver, an indication that the at least one logged measurement is available. The WTRU further may be configured to send, via the transceiver, a report comprising the at least one logged measurement. The report may be sent in response to a request from a network. The at least one condition may include when to start and stop the logging. The at least one condition may include an identification of at least one cell for logging. The at least one condition may include an identification of at least one beam for logging. The at least one condition may include an indication of at least one measurement object for logging.

[0007] An example computer-readable storage medium may have executable instructions stored thereon that when executed by a processor, cause the processer to perform a measurement of at least one measurement object associated with at least one beam of at least one cell. While in a connected state, the processor may log the at least one measurement, wherein the logging is based on at least one condition. And the processor may be configured to send an indication that the at least one logged measurement is available. The processor further may be configured to send a report comprising the at least one logged measurement. The report may be sent in response to a request from a network. The at least one condition may include when to start and stop the logging. The at least one condition may include an identification of at least one cell for logging. The at least one condition may include an identification of at least one beam for logging. The at least one condition may include an indication of at least one measurement object for logging.

[0008] An example WTRU configured to perform data measurement and logging may comprise a memory and a processor. The processor may be configured to receive a configuration related to measurement logging and reporting. The configuration may include at least one first condition to start logging measurements in the memory and at least one second condition to stop the logging of the measurements in the memory. The at least one first condition may be related to a likelihood of an occurrence of at least one first event within a first period of time. The at least one second condition may be related to a likelihood that at least one second event has occurred within a second period of time. The processor may be configured to perform first measurements. The processor may be configured to, in response to the first measurements indicating that the likelihood of the at least one first event occurring within the first period of time is at or above a first threshold, start logging second measurements in the memory. The processor may be configured to, based on a determination that the likelihood of the at least one second event having occurred within the second period of time being above a second threshold, stop logging the second measurements in the memory. The processor may be configured to send a report comprising an indication of the logged second measurements. The processor may be configured to send the report in response to a determination that a third condition for reporting the measurements is fulfilled, wherein the third condition is related to a likelihood of an occurrence of at least one third event. The report may be sent in response to a request from a network. The at least one first condition my comprise an identification of at least one configured cell for logging. The at least one first event may be based on a location of the WTRU. The likelihood of the occurrence of at least one of the at least one first event or the at least one second event may be based on an artificial i ntell igence/machine learning (AI/ML) model. The first measurements may comprise a quality of a cell. The first measurements may comprise a quality of a beam The processor may be configured to, in response to the first measurements indicating that the likelihood of the at least one first event occurring within the first period of time is below a threshold, delete from the memory the first measurements. The processor may be configured to log in the memory a logical identifier associated with an artificial intelligence/machine learning (AI/ML) model.

[0009] An example method for performing data measurement and logging may comprise receiving a configuration related to measurement logging and reporting. The configuration may include at least one first condition to start logging measurements in the memory and at least one second condition to stop the logging of the measurements in the memory. The at least one first condition may be related to a likelihood of an occurrence of at least one first event within a first period of time. The at least one second condition may be related to a likelihood that at least one second event has occurred within a second period of time. The method may include performing first measurements. The method may include, in response to the first measurements indicating that the likelihood of the at least one first event occurring within the first period of time is at or above a first threshold, start logging second measurements in the memory. The may include, based on a determination that the likelihood of the at least one second event having occurred within the second period of time being above a second threshold, stop logging the second measurements in the memory. The method may include sending a report comprising an indication of the logged second measurements. The method may include sending the report in response to a determination that a third condition for reporting the measurements is fulfilled, wherein the third condition is related to a likelihood of an occurrence of at least one third event. The report may be sent in response to a request from a network. The at least one first condition my comprise an identification of at least one configured cell for logging. The at least one first event may be based on a location of the WTRU The likelihood of the occurrence of at least one of the at least one first event or the at least one second event may be based on an artificial intel ligence/machi ne learning (AI/ML) model. The first measurements may comprise a quality of a cell. The first measurements may comprise a quality of a beam. The method may include, in response to the first measurements indicating that the likelihood of the at least one first event occurring within the first period of time is below a threshold, deleting from the memory the first measurements. The method may include logging in the memory a logical identifier associated with an artificial intelligence/machine learning (AI/ML) model.

[0010] An example computer-readable storage medium may have executable instructions stored thereon that when executed by a processor, cause the processer to perform data measurement and logging. The executable instructions may cause the processor to receive a configuration related to measurement logging and reporting. The configuration may include at least one first condition to start logging measurements in the memory and at least one second condition to stop the logging of the measurements in the memory. The at least one first condition may be related to a likelihood of an occurrence of at least one first event within a first period of time. The at least one second condition may be related to a likelihood that at least one second event has occurred within a second period of time. The executable instructions may cause the processor to perform first measurements. The executable instructions may cause the processor to, in response to the first measurements indicating that the likelihood of the at least one first event occurring within the first period of time is at or above a first threshold, start logging second measurements in the memory. The executable instructions may cause the processor to, based on a determination that the likelihood of the at least one second event having occurred within the second period of time being above a second threshold, stop logging the second measurements in the memory. The executable instructions may cause the processor to send a report comprising an indication of the logged second measurements. The executable instructions may cause the processor to send the report in response to a determination that a third condition for reporting the measurements is fulfilled, wherein the third condition is related to a likelihood of an occurrence of at least one third event. The report may be sent in response to a request from a network. The at least one first condition my comprise an identification of at least one configured cell for logging. The at least one first event may be based on a location of the WTRU. The likelihood of the occurrence of at least one of the at least one first event or the at least one second event may be based on an artificial intelligence/machine learning (AI/ML) model. The first measurements may comprise a quality of a cell. The first measurements may comprise a quality of a beam. The executable instructions may cause the processor to, in response to the first measurements indicating that the likelihood of the at least one first event occurring within the first period of time is below a threshold, delete from the memory the first measurements. The executable instructions may cause the processor to log in the memory a logical identifier associated with an artificial intelligence/machine learning (AI/ML) model.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] A more detailed understanding may be had from the detailed description below, given by way of example in conjunction with drawings appended hereto. Figures in such drawings, like the detailed description, are examples. As such, the Figures and the detailed description are not to be considered limiting, and other equally effective examples are possible and likely. Like reference numerals (“ref.” or “refs.") in the Figures indicate like elements.

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

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

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

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

[0016] FIG. 2 depicts an example summary of a measurement framework in new radio (NR).

[0017] FIG. 3 is an example depiction of conditional handover configuration and execution.

[0018] FIG. 4 depicts an example minimization of drive test (MDT) configuration for logged MDT.

[0019] FIG. 5 depicts an example information transfer procedure.

[0020] FIG. 6A is a schematic illustration of an example system environment that may implement an artificial intelligence (Al) and/or machine learning (ML) model.

[0021] FIG. 6B illustrates an example of a neural network.

[0022] FIG. 6C is a schematic illustration of an example system environment for training and/or implementing an AI/ML model that includes a neural network (NN). [0023] FIG. 6D is a schematic illustration of an example system environment for training and/or implementing an AI/ML model that includes an auto-encoder.

[0024] FIG. 7 depicts an example process for performing and logging measurements.

EXAMPLE NETWORKS FOR IMPLEMENTATION OF THE INVENTION

[0025] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail uniqueword DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

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

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

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

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

[0030] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104/113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 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 UL Packet Access (HSUPA).

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

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

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

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

[0036] The RAN 104/113 may be in communication with the ON 106/115, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The ON 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104/113 and/or the CN 106/115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104/113 or a different RAT. For example, in addition to being connected to the RAN 104/113, which may be utilizing a NR radio technology, the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology. [0037] The CN 106/115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104/113 or a different RAT.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0051] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface. [0052] The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

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

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

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

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

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

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

[0059] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an "ad-hoc” mode of communication.

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

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

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

[0063] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11ac.

802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control/Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

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

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

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

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

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

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

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

[0071] The CN 115 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

[0072] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and/or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP (third generation partnership project) access technologies such as WiFi.

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

[0074] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

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

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

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

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

[0079] Described herein are methods and apparatuses for obtaining data utilizable by WTRUs and/or other devices implementing Al and/or ML. Measurements performed by a WTRU may be used for several purposes such as scheduling of resources for uplink (UL) and downlink (DL) transmission, maintaining a serving cell/link (e.g., Radio Link Monitoring (RLM), Radio Link Management (RRM)), for mobility decisions such as Handover, Carrier Aggregation/Dual connectivity (CA/DC), setup/release/change, or the like, etc.

[0080] In radio resource control (RRC)_CONNECTED mode, a WTRU may measure one or more beams (at least one) of a cell and the measurement results (e.g., power values) may be averaged to derive cell quality. In doing so, the WTRU may be configured to consider a subset of detected beams. Filtering may take place, for example, at two different levels: at the physical layer (L1) level to derive beam quality and at the RRC layer (L3) level to derive cell quality from multiple beams. The L1 filtering may depend upon WTRU implementation, and the L3 filtering may be configured by a network. The cell quality may be derived by averaging a certain (e.g., configured) number of beams that have a signal level above a certain (e.g., configured) threshold. Cell quality from beam measurements may be derived in the same way for a serving cell, or cells, and for a non-serving cell, or cells. Measurement reports may contain the measurement results of the X best beams. Measurement reports may be provided by a WTRU if the WTRU is configured to do so. A WTRU may be configured to provide measurement results by any appropriate entity (e.g., network node), such as, for example, by a next generation node B (gNB).

[0081] For each measurement type to be performed, a WTRU may be configured with at least one measurement object. A measurement object may specify what is to be measured. For example, a measurement object may include, but not limited to, any appropriate combination of the following information, such as, for example, synchronization signal block/channel state information-reference signal (SSB/CSI-RS) resource configuration (e.g., frequency, timing (e.g., SSB-based RRM measurement timing configuration (SMTC) window), sub carrier spacing, a list of cells (allowed cells, blocked cells, etc.), minimum beam quality to be considered during cell quality derivation, a number of beams to average for cell quality derivation, a measurement quantity, e.g., reference signal received power (RSRP), radio signal received quality (RSRQ), signal to noise ratio (SNR), or the like.

[0082] A measurement object may be associated with one or more reporting configurations (e.g., via a measurement identifier (ID)), where the reporting configuration may be either event triggered or periodical If it is periodical, a WTRU may send the measurement report every reporting interval (which may range, for example, between 120 milliseconds (ms) and 30 minutes (min)).

[0083] For event triggered measurements, the WTRU may send the measurement report when the conditions associated with the event are fulfilled. The WTRU may keep on measuring serving cell and neighbors report quantity and validate it with the threshold or offset defined in a report configuration. The report quantity may be RSRP, RSRQ, signal to signal to interference and noise ratio (SI NR), or the like, or any appropriate combination thereof.

[0084] Measurement reports may contain the cell quality of serving and/or neighbor cells, and along with the cell quality, the X best beams of that cell may be included. A WTRU may be configured to provide measurement reports by any appropriate entity, such as, for example, by a gNB.

[0085] Measurement events may include intra-radio access technology (intra-RAT) events and inter-RAT events. Example intra-RAT events may include events A1 , A2, A3, A4, A5, and A6 as described below.

[0086] Event A1 may be indicative of a particular measurement object of a serving cell becoming better than a threshold. Event A1 may trigger cancelation of an ongoing handover procedure. This may be applicable if a WTRU moves towards a cell edge and triggers a mobility procedure, but then subsequently moves back into good coverage before the mobility procedure has completed.

[0087] Event A2 may be indicative of a particular measurement object of a serving cell becoming worse than a threshold. Event A2 may not involve any neighbor cell measurements. Event A2 may be used to trigger a blind mobility procedure. A network may configure a WTRU for neighbor cell measurements when it receives a measurement report that is triggered due to event A2 in order to save WTRU battery (e.g., not perform neighbor cell measurements when the serving cell quality is good enough). [0088] Event A3 may be indicative of a particular measurement object of a neighbor cell becoming better that the particular measurement object of a special cell (SpCell). Event A3 may be used to trigger a handover procedure. Note that an SpCell is the primary serving cell of either a Master Cell Group (MCG), e.g., the primary cell (PCell, or Secondary Cell Group (SCG), e.g., the primary secondary serving cell (PSCell). Thus, in dual connectivity (DC) operation, the Secondary Node (SN) can configure an A3 event for secondary node (SN) triggered PSCell change. Event A3 may be used in conjunction with a conditional handover (CHO) or a conditional PSCell change.

[0089] Event A4 may be indicative of a particular measurement object of a neighbor cell becoming better than a threshold). Event A4 may be used to trigger handover procedures which do not depend upon the coverage of the serving cell (e.g., load balancing, where the WTRU is handed over to a good neighbor cell even if the serving cell conditions are excellent)

[0090] Event A5 may be indicative of a particular measurement object of a SpCell becoming worse than a first threshold (threshold 1) and the particular measurement object of a neighbor cell becoming better than a second threshold (threshold2). Similar to event A3, event A5 may be used to trigger a handover, but unlike event A3, event A5 may provide a handover triggering mechanism based upon absolute measurements of the serving and neighbor cells, while event A3 uses a relative comparison. Event A5 may be suitable for time critical handover when the serving cell becomes weak and it is necessary to change towards another cell which may not satisfy the criteria for an event A3 handover.

[0091] Event A6 may be indicative of a particular measurement object of a neighbor cell becoming better than the particular quality of a SCell by an offset. Event A6 may be used for SCell addition/releasing.

[0092] . Example inter-RAT events may include events B1 and B2 as described herein. Event B1 may be indicative of a particular quality of an inter-RAT neighbor cell becoming better than threshold. Event B1 is similar to event A4, but for the case of inter-RAT handover. Event B2 may be indicative of a particular measurement object of a PCell becoming worse than threshold 1 and the particular measurement object of an inter RAT neighbor becoming better than threshold2. Event B2 is similar to event A5, but for the case of inter-RAT handover.

[0093] FIG. 2 summarizes an example measurement framework in new radio (NR). As depicted in FIG. 2, A represents the measurement (beam specific samples) internal to the physical layer. Layer 1 filtering is internal layer 1 filtering of the inputs measured at point A. Exact filtering is implementation dependent. How measurements are executed in the physical layer by an implementation (inputs A and Layer 1 filtering) is not constrained by a standard. A1 represents the measurements (e.g., beam specific measurements) reported by layer 1 to layer 3 after layer 1 filtering. Beam Consolidation/Selection are beam specific measurements that may be consolidated to derive cell quality. The configuration of the Beam consolidation/selection module may be provided by RRC signaling. Reporting period at B equals one measurement period at A1. B represents a measurement (e.g., cell quality) derived from beam-specific measurements reported to layer 3 after beam consolidation/selection. Layer 3 filtering for cell quality is filtering performed on the measurements provided at point B. The configuration of the layer 3 filters may be provided by RRC signaling. Filtering reporting period at C equals one measurement period at B. C represents a measurement after processing in the layer 3 filter. The reporting rate may be the same as the reporting rate at point B. This measurement may be used as input for one or more evaluation of reporting criteria. Evaluation of reporting criteria may check whether actual measurement reporting is appropriate at point D. The evaluation may be based on more than one flow of measurements at reference point C, e.g., to compare between different measurements. This is illustrated by input C and C1 . The WTRU may evaluate the reporting criteria at least every time a new measurement result is reported at point C, C1. The reporting criteria may be standardized and the configuration may be provided by RRC signaling (WTRU measurements). D represents measurement report information (message) sent on the radio interface.

[0094] L3 Beam filtering is filtering performed on the measurements (e.g., beam specific measurements) provided at point A1 . The behavior of the beam filters may be standardized and the configuration of the beam filters may be provided by RRC signaling. Filtering reporting period at E may equal one measurement period at A1 . E represents a measurement (e.g., beam-specific measurement) after processing in the beam filter. The reporting rate may be the same as the reporting rate at point A1. This measurement may be used as input for selecting which measurements (X measurements) to be reported. Beam Selection for beam reporting may select the X measurements from the measurements provided at point E. The behavior of the beam selection may be standardized and the configuration of this module may be provided by RRC signaling. F represents beam measurement information included in measurement report, which may be sent on the radio interface. Layer 1 filtering may introduce a certain level of measurement averaging. How and when the WTRU exactly performs the required measurements may be implementation specific. Layer 3 filtering for cell quality and related parameters used may not introduce any delay in the sample availability between B and C. Measurements at point C, C1 may be the input used in the event evaluation. L3 Beam filtering and related parameters may not introduce any delay in the sample availability between E and F.

[0095] FIG. 3 is an example depiction of conditional handover configuration and execution. The concept of conditional handover (CHO) and conditional PSCell Addition/Change (CPA/CPC, or collectively referred to as CPAC) was introduced in NR to reduce the likelihood of radio link failures (RLFs) and handover failures (HOFs). Handover may be triggered by measurement reports, even though there is nothing preventing the network from sending a HO command to the WTRU without the WTRU receiving a measurement report. For example, a WTRU may be configured with an A3 event that triggers a measurement report to be sent when the radio signal level/quality (RSRP, RSRQ, etc.) of a neighbor cell becomes better than the Primary serving cell (PCell) (or the Primary Secondary serving Cell (PSCell), in the case of Dual Connectivity (DC)). The WTRU may monitor the serving and neighbor cells and may send a measurement report when the conditions get fulfilled. When such a report is received, the network (current serving node/cell) may prepare the HO command (basically, an RRC Reconfiguration message, with a reconfigurationWithSync) and may send it to the WTRU, which the WTRU may execute immediately resulting in the WTRU connecting to the target cell.

[0096] CHO differs from legacy handover in at least two aspects. In CHO, multiple handover targets are prepared (as compared to only one target in legacy case). In CHO, the WTRU does not immediately execute the CHO as in the case of the legacy handover. Instead, the WTRU may be configured with triggering conditions, such as a set of radio conditions, and the WTRU my execute the handover towards one of the targets only when/if the triggering conditions are fulfilled.

[0097] A CHO command may be sent when the radio conditions towards the current serving cells are still favorable, thereby reducing two points of failure in legacy handover, e.g., risk failing to send a measurement report (e.g., if the link quality to the current serving cell falls below acceptable levels when the measurement reports are triggered in normal handover) and the failure to receive the handover command (e.g., if the link quality to the current serving cell falls below acceptable levels after the WTRU has sent the measurement report, but before it has received the HO command).

[0098] Triggering conditions for a CHO also may be based on the radio quality of the serving cells and neighbor cells like the conditions that are used in legacy NR/LTE to trigger measurement reports. For example, a WTRU (302) may be configured (304) with a CHO that has an A3 like triggering condition and associated HO command. The WTRU may monitor (306) the current and serving cells and when the A3 triggering conditions are fulfilled, it may, instead of sending a measurement report, execute the associated HO command (308) and switch its connection towards the target cell.

[0099] Another benefit of CHO is in helping prevent unnecessary re-establishments in case of a radio link failure. For example, assume a WTRU is configured with multiple CHO targets and the WTRU experiences a radio link failure (RLF) before the triggering conditions with any of the targets gets fulfilled. Legacy operation would have resulted in RRC re-establishment procedure that would have incurred considerable interruption time for the bearers of the WTRU. However, in the case of CHO, if the WTRU, after detecting a RLF, ends up in a cell for which it has a CHO associated with (e.g., the target cell is already prepared for it), the WTRU may execute the HO command associated with this target cell directly, instead of continuing with the full re-establishment procedure.

[0100] CPC and CPA are extensions of CHO, but in DC scenarios. A WTRU could be configured with triggering conditions for PSCell change or addition, and when the triggering conditions are fulfilled, it may execute the associated PSCell change or PSCell add commands. Additional events for conditional handover may include a conditional event A3 (CondEvent A3), conditional event A4 (CondEvent A4), and conditional event A5 (CondEvent A5). CondEvent A3 may be indicative of a particular quality of a conditional reconfiguration candidate becoming better than the particular quality of a PCell/PSCell, by an offset amount. CondEvent A4 may be indicative of a particular quality of a conditional reconfiguration candidate becomes better than an absolute threshold. CondEvent A5 may be indicative of a particular quality of a PCell/PSCell becoming worse than an absolute threshold 1 AND the particular quality of a conditional reconfiguration candidate becomes better than another absolute threshold2.

[0101] NR has a Minimization of Drive Test (MDT) framework in which a WTRU may be configured to perform measurements, log the measurements, and report them to the network upon request. The MDT framework may be used for network performance optimization (e.g., identify coverage holes). For example, a WTRU (402) may be provided, while in RRC_CONNECTED for example, with a logged measurement configuration (404) as shown in FIG. 4. The WTRU may perform the measurements and log them while in RRCJDLE or RRCJNACTIVE. The logged measurement configuration may include, for example, any appropriate combination of the following information. The logged measurement configuration may include the area (e.g., list of cells) in which a WTRU performs the measurement logging (e.g., WTRU may perform the measurements only on the list of cells included in the area configuration). The logged measurement configuration may include the neighboring frequencies and cells to be measured while in the configured area. The logged measurement configuration may include a logging duration. The logged measurement configuration may include a logging type (periodical logging or event based, e.g , when the camped cell quality is below a specified threshold).

[0102] A WTRU may log not only the measurement results (e.g., signal levels of camped on cell and neighbor cells) but also additional information such as the location and timestamp of where/when each measurement sample is taken.

[0103] While in a RRC_CONNECTED state, a WTRU may indicate that it has logged measurements available (e.g., in RRC complete messages such RRCReconfigurationComplete), and the network (502) may request (506) the WTRU (504) to send (508) the logged measurements via a WTRU information transfer procedure shown below in FIG. 5 (network indicating logged measurements in the UElnformationRequest message and WTRU sending the logged measurements in the UElnformationResponse message). The WTRU may be allowed to release the logged measurements 48 hours, for example, after the end of the logging duration if the network have not requested it.

[0104] Artificial (Al)/machine learning (ML) operations are based on models (e.g., neural networks) that have been trained using a substantial amount of data under different scenarios/conditions. For a given function, there may be several models (e.g., each trained/suitable for different network/WTRU conditions/characteristics). Mechanisms and frameworks may be specified for using AI/ML based approaches for the air interface level (e.g., CSI-feedback enhancements (e.g., CSI compression), beam management and WTRU positioning), and network level (e.g., network energy saving, load balancing and mobility), for example. [0105] As used herein, the term AI/ML (Artificial Intelligence/ Machine Learning) describes any model and/or associated learning algorithm used by a WTRU, network, device, or the like, to predict future behavior (e.g., the behavior of data arrival rate/volume at a WTRU to be sent to a network, or from the network to the WTRU). The model and associated learning algorithm are assumed to utilize a big set of data that may be collected by WTRUs and/or networks. Also, it may be assumed that the AI/ML model is making predictions based on several conditions such as current time, current WTRU location, WTRU mobility pattern, etc. For example, the AI/ML model may be able to predict future UL/DL data arrival based on current and/or historical measurements of UL/DL data arrival/volume (e.g., considering the UL/DL data arrival rates/volumes at a similar time of day or/and at a similar location as the current time/location, considering the current active bearers/applications, etc.).

[0106] As described herein, the terms Artificial Intelligence (Al), Machine Learning (ML), Deep Learning (DL), DNNs may be used interchangeably. Although the techniques described herein are exemplified based on learning in wireless communication systems, they may additionally, or alternatively, be used in other systems, including, for example, any type of transmissions, communication systems and/or services, etc.

[0107] Techniques and mechanisms described herein for data collection enhancement are agnostic/independent to the AI/ML model/technique that is being used (e.g., the algorithm used, the mechanism such as neural network or what kind of neural network, e.g., depth and parameters/weights of the network, etc.). However, a WTRU may have a pre-trained AI/ML model that can produce predictions of UL/DL data arrival rate/volume.

[0108] Predictions may be associated with one point in time (e.g., model produces the expected UL/DL data arrival rate/volume X ms from now) or may extend over several time steps (e.g., a time series of predictions for the next Y ms, at every X ms interval, etc.). An AI/ML model residing on a WTRU may be implementation-based (e.g., installed/provided by the WTRU vendor) or the WTRU may obtain the AI/ML model from the network.

[0109] For any predicted value, the predicted value itself may be associated and/or represented by a confidence or error margin value, and may be represented by an average, peak, minimum value, etc., along a short time window representing the validity of that prediction. A WTRU may communicate with a network about AI/ML capabilities (e.g., where the WTRU can indicate to the network the supported AI/ML models/functions, confidence level of predictions, e.g., time horizon of predictions (how far along in the future are the prediction being made), etc.). The WTRU may support several AI/ML models for a certain functionality (e.g., with different prediction time horizons, prediction confidence levels, processing requirements, trained under/for operation in different cells/location/times of day/application types, etc.). A given AI/ML model may operate in different modes (e.g., with different levels of prediction confidence levels at different prediction time horizons, etc.). The WTRU may choose the AI/ML model to use for a certain functionality (e.g., network decides for which functionalities the WTRU can use AI/ML based operation, and the WTRU may choose the AI/ML model to use) or the network may explicitly control this (e.g., WTRU provides details about AI/ML models and their capabilities, network determines which model to activate for a particular functionality).

[0110] AI/ML models may be available at the WTRU already trained, or the WTRU may be provided with an untrained AI/ML model and perform the training by itself. An AI/ML model may be available at the WTRU already trained, and the WTRU may be enabled/configured to perform further training (e.g., for different conditions such as cells/location/times of day etc., for conditions different from the initial training, for conditions the same as the initial training but for increasing the level of confidence or/and the prediction time horizon, etc.).

[0111] In the case of a time series output, the prediction confidence may be variable from one output to the other (e.g., higher confidence level for prediction that are X ms away as compared to predictions Y ms away, where Y>X, etc.). Prediction confidence level may be in percentage confidence (e.g., expected likelihood of this prediction will come true), in terms of error margin (e.g., in Y ms, the predicted UL data rate is expected to be between X- lower_error_margin and X+upper_error_margin), or both in confidence percentage and error margin (e.g., in Z ms, the predicted UL data rate is expected to be between X-lower-errorjnargin and X+upper_error_magin, with a confidence of 90%). For a given time horizon of prediction, there may be different ranges of predicted values with different confidence levels or error margins (e.g., in Y ms, the predicted UL data rate is expected to be between X1- Iower_error_margin1 and X1 +upper_error_margin1 , with a confidence of 95%, between X2 -Iower_error_margin2 and X2+upper_error_margin2, with a confidence of 85%, etc.).

[0112] FIG. 6A is a schematic illustration of an example system environment 601 that may implement an AI/ML 609 model. The AI/ML model 609 may be implemented at the WTRU and/or the network. AI/ML 609 model may include model data and one or more algorithms and/or functions configured to learn from input data 607 that is received to train the AI/ML 609 and/or generate an output 615. Input data 607 may be input in one or more formats, such as an image format, an audio format (e.g., spectrogram or other audio format), a tensor format (e.g., including single-dimensional or multi-dimensional arrays), and/or another data type capable of being input into the AI/ML 609 algorithms. Input data 607 may be the result of pre-processing 605 that may be performed on raw data 603, or input data 607 may include raw data 603 itself. Raw data 603 may include image data, text data, audio data, or another sequence of information, such as a sequence of network information related to a communication network, and/or other types of data. Pre-processing 605 may include format changes or other types of processing in order to generate input data 607 in a format for being input into the AI/ML 609 algorithms. Output 615 may be generated by the AI/ML 609 algorithm in one or more formats, such as a tensor, a text format (e.g., a word, sentence, or other sequence of text), a numerical format (e.g., a prediction), an audio format, an image format (e.g., including video format), another data sequence format, or/ another output format. As described herein, output 615 may include one or more of predicted beam pairs, predicted measurements for the one or more beam-pairs based on the stored training data samples and a predictive beam refinement configuration, predictive beam identifiers, codebook identifiers, predictive layer 1 received signal received power (L1-RSRP) values, and/or predictive angle of arrival (AoA), for example based on the predicted measurements.

[0113] AI/ML 609 may be implemented as described herein using software and/or hardware. AI/ML 609 may be stored as computer-executable instructions on computer-readable media accessible by one or more processors for performing as described herein. Example AI/ML environments and/or libraries include TENSORFLOW, TORCH, PYTORCH, MATLAB, GOOGLE CLOUD Al and AUTOML, AMAZON SAGEMAKER, AZURE MACHINE LEARNING STUDIO, and/or ORACLE MACHINE LEARNING.

[0114] AI/ML 609 may include one or more algorithms configured for unsupervised learning. Unsupervised learning may be implemented utilizing AI/ML 609 algorithms that learn from input data 607 without being trained toward a particular target output. For example, during unsupervised learning AI/ML 609 algorithms may receive unlabeled data as input data 607 and determine patterns or similarities in the input data 607 without additional intervention (e.g., updating parameters and/or hyperparameters). The AI/ML 609 algorithms that are configured for implementing unsupervised learning may include algorithms configured for identifying patterns, groupings, clusters, anomalies, and/or similarities or other associations in the input data 607. For example, AI/ML 609 may implement hierarchical clustering algorithms, k-means clustering algorithms, k nearest neighbors (K-NN) algorithms, anomaly detection algorithms, principal component analysis algorithms, and/or apriori algorithms. AI/ML 609 algorithms configured for unsupervised learning may be implemented on a single device or distributed across multiple devices, such that output 615, or portions thereof, may be aggregated at one or more devices for being further processed and/or implemented in other downstream algorithms or processes, as may be further described herein.

[0115] The AI/ML 609 may include one or more algorithms configured for supervised learning Supervised learning may be implemented utilizing AI/ML 609 algorithms that are trained during a training process to determine a predictive model using known outcomes. The AI/ML 609 algorithms may be characterized by parameters and/or hyperparameters that may be trained during the training process. The parameters may include values derived during the training process. The parameters may include weights, coefficients, and/or biases. The AI/ML 609 may also include hyperparameters. The hyperparameters may include values used to control the learning process. The hyperparameters may include a learning rate, a number of epochs, a batch size, a number of layers, a number of nodes in each layer, a number of kernels (e.g., CNNs), a size of stride (e.g., CNNs), a size of kernels in a pooling layer (e.g., CNNs), and/or other hyperparameters. Some may use certain parameters and hyperparameters interchangeably.

[0116] The AI/ML 609 may be trained during supervised learning by inputting training data to the AI/ML 609 algorithm and adjusting the parameters and/or hyperparameters toward a known target output 615 while minimizing a loss or error in the output 615 generated by the AI/ML 609 algorithm. The raw data 603 may include or be separated into training data, validation data, and/or test data for training, validation, and/or testing, respectively, the AI/ML 609 algorithms during supervised learning. The training data, validation data, and/or test data may be pre-processed from the raw data 603 for being input into the AI/ML 609 algorithm. During supervised learning, the training data may be labeled prior to being input into the AI/ML 609. The training data may be labeled to teach the AI/ML 609 algorithm to learn from the labeled data and to test the accuracy of the AI/ML 609 for being implemented on unlabeled input data 607 during production/implementation of the AI/ML 609 algorithms, or similar AI/ML 609 algorithms utilizing similar parameters and/or hyperparameters. The training data may be used to fit the parameters of the AI/ML 609 model using optimization functions, such as a loss or error function. Often the training data includes pairs of input data 607 and a corresponding target output 615 to which the parameters may be trained to generate (e.g., within a threshold loss or error). The trained or fitted AI/ML 609 model may receive the validation data as input to evaluate the model fit on the training data set, while tuning the hyperparameters of the AI/ML 609 model. The AI/ML 609 model may receive the test data to evaluate a final model fit on the training data set and to assess the performance of the AI/ML 609 model. One or more of the training, validation, and/or testing may be performed during supervised learning for different types of AI/ML 609 models.

[0117] Supervised learning may be implemented for various types of AI/ML 609 algorithms, including algorithms that implement linear regression, logistic regression, neural networks (NNs), decision trees, Bayesian logics, random forests, and/or support vector machines (SVMs). NNs and Deep NNs (DNNs) are popular examples of algorithms utilized in AI/ML models that may be trained using supervised learning. However, AI/ML 609 models may implement one or more NN and/or non-NN-based algorithms. Various examples of NNs include: perceptrons, multilayer perceptrons (MLPs), feed-forward NNs, fully-connected NNs, convolutional Neural Networks (CNNs), recurrent NNs (RNNs), long-short term memory (LSTM) NNs, and/or residual NNs (ResNets). A perceptron is a NN that includes a function that multiplies its input by a learned weight coefficient to generate an output value. A feed-forward NN is a NN that receives input at one or more nodes of an input layer and moves information in a direction through one or more hidden layers to one or more nodes of an output layer. In a feed-forward NN, one or more nodes of a given layer may be connected to one or more nodes of another layer. A fully connected NN is a NN that includes an input layer, one or more hidden layers, and an output layer. In a fully connected NN, each node in a layer is connected to each node in another layer of the NN. An MLP is a fully connected class of feed-forward NNs. A CNN is a NN having one or more convolutional layers configured to perform a convolution. Various types of NNs may have elements that include one or more CNNs or convolutional layers, such as Generative Adversarial Networks (GANs). GANs may include conditional GANs (CGANs), cycle-consistent GANs (CycleGANs), StyleGANs, DiscoGANs, and/or IsGANs. A GAN may include a generator sub-model and a discriminator sub-model. The generator submodel may be configured to receive input data and pass true and independently generated data to the discriminator sub-model. The discriminator sub-model may be configured to receive the true and independently generated data from the generator, discriminate the true and independently generated data, and provide feedback to the generator sub-model during training to improve the function of the generator sub-model in independently generating an output based on a received input. The GAN is a popular model for generating data types or data sequences, such as image data, audio data, and/or text, for example. An RNN is a NN that is recurrent in nature, as the nodes include feedback connections and an internal hidden state (e.g., memory) that allows output from nodes in the NN to affect subsequent input to the same nodes. LSTM NNs may be similar to RNNs in that the nodes have feedback connections and an internal hidden state (e.g., memory). However, LSTM NNs may include additional gates to allow the LSTM NNs to learn longer-term dependencies between sequences of data. A ResNet is a NN that may include skip connections to skip one or more layers of the NN. An autoencoder may be a form of AI/ML 109 that may be implemented for supervised learning, such that parameters and/or hyperparameters may be updated during a training procedure. The parameters and/or hyperparameters may relate to the encoder portion and/or the decoder portion of the autoencoder. Some NNs include one or more attention layers or functions to enhance or focus on some portions of the input data, while diminishing or de-emphasizing other portions.

[0118] Different types of NNs and/or layers may be implemented for processing different types of data and/or producing different types of output. For example, a NN may comprise one or more convolutional layers (e.g., for CNNs or GANs), which may be popular for processing image data and/or audio data (e.g., spectrograms). Each convolutional layer may vary according to various convolutional layer parameters or hyperparameters, such as kernel size (e.g., field of view of the convolution), stride (e g., step size of the kernel when traversing an image), padding (e.g., for processing image borders), and/or input and output size. The image being processed may include one or more dimensions (e.g., a line of pixels or a two-dimensional array of pixels). The pixels may be represented according to one or more values (e.g., one or more integer values representing color and/or intensity) that may be received by the convolutional layer. The kernel, which may also be referred to as a convolution matrix or mask, may be a matrix used to extract and/or transform features from the input data being received. The kernel may be used for blurring, sharpening, edge detection, and/or the like. An example kernel size may include a 3x3, 5x5, 10x10, etc. matrix (e.g., in pixels for a 6D image). The stride may be the parameter used to identify the amount the kernel is moved over the image data. An example default stride is of a size of 1 or 6 within the matrix (e.g., in pixels for a 6D image). The padding may include the amount of data (e.g., in pixels for a 6D image) that is added to the boundaries of the image data when it is processed by the kernel. The kernel may be moved over the input image data (e.g., according to the stride length) and perform a dot product with the overlapping input region to obtain an activation value for the region. The output of each convolutional layer may be provided to a next layer of the NN or provided as an output (e.g., image data, feature map, etc.) of the NN itself with the updated features based on the convolution.

[0119] The NN may include layers of a similar type (e.g., convolutional layers, feed-forward layers, fully- connected layers, etc.) and/or having a similar or different configuration (e.g., size, number of nodes, etc.) for each layer. The NN may also, or alternatively, include one or more layers having different types or different subsets of NNs that may be interconnected for training and/or implementation, as described herein. For example, a NN may include both convolutional layers and feed-forward or fully-connected layers.

[0120] FIG. 6B illustrates an example of a neural network 609a. The objective of training may be to apply input 607a as training data and/or adjust one or more weights, indicated as w and x in FIG. 6B (e.g., which may be referred to as neuron weights and/or link weights), such that output 615 from neural network 609a approaches the desired target values which are associated with the input 607a values for the training data. In examples, a neural network may include three layers (e.g., as shown in FIG. 6B). During the training, for given input, the difference between output and desired values may be computed and/or the difference may be used to update the one or more weights in the neural network. If a significant (e.g., large) difference between output and desired value(s) is observed, for example, one or more relatively significant (e.g., large) changes in one or more weights may be expected. A small difference (e.g., between output and desired value(s) may include one or more relatively small changes in one or more weights. For example, for positioning, input 607a may be reference signal parameters and/or output 615 may be an estimated position. The desired value may be location information acquired by global navigation satellite system (GNSS) with high accuracy.

[0121] Once neural network 609a completes its training, the difference between output 615 and desired values may be below a threshold. Neural network 609a may be applied or implemented after training for positioning by feeding input data 607a and/or by estimating or predicting output 615 as the expected outcome for associated input 607a. Output 615 may be an estimated position and/or location of the WTRU.

[0122] Training a neural network 609a may include identifying one or more of the following information: the input for the neural network; the expected output associated with the input; and/or the actual output from the neural network against which the target values are compared.

[0123] In examples, a neural network model may be characterized by one or more parameters and/or hyperparameters, which may include: the number of weights and/or the number of layers in the neural network.

[0124] As used herein, the term "deep learning” may refer to a class of machine learning algorithms that employ artificial neural networks (e.g., deep neural networks (DNNs)) which were loosely inspired from biological systems and/or include at least one hidden layer. DNNs may be a special class of machine learning models inspired by the human brain where the input is linearly transformed and/or pass through a non-linear activation function one or more (e.g., multiple) times. DNNs may include one or more (e.g., multiple) layers where one or more (e.g., each) layer includes linear transformation and/or a given non-linear activation function(s). DNNs may be trained using the training data via a back-propagation algorithm. DNNs have shown state-of-the-art performance in variety of domains, e.g., speech, vision, natural language etc., and/or for various machine learning settings (e.g., supervised, unsupervised, and/or semi-supervised). [0125] FIG. 6C is a schematic illustration of an example system environment 601 a for training and implementing an AI/ML model that comprises NN 609a. However, other types of AI/ML models (e g. , including NNs and/or non-NN models) may be similarly trained and/or implemented. NN 609a may be trained and/or implemented on one or more devices to determine and/or update parameters and/or hyperparameters 617 of the NN 609a. Raw data 603a may be generated from one or more sources. For example, raw data 603a may include image data, text data, audio data, or another sequence of information, such as a sequence of network information related to a communication network, and/or other types of data. Raw data 603a may be preprocessed at 605a to generate training data 607a. The preprocessing may include formatting changes or other types of processing in order to generate training data 607a in a format for being input into NN 609a.

[0126] NN 609a may include one or more layers 611. The configuration of NN 609a and/or layers 611 may be based on the parameters and/or hyperparameters 617. As described herein, the parameters may include weights, or coefficients, and/or biases for the nodes or functions in layers 611 . The hyperparameters may include a learning rate, a number of epochs, a batch size, a number of layers, a number of nodes in each layer, a number of kernels (e.g., CNNs), a size of stride (e.g., CNNs), a size of kernels in a pooling layer (e.g., CNNs), and/or other hyperparameters. As described herein, NN 109a may include a feed forward NN, a fully connected NN a CNN, a GAN, an RNN, a ResNet, and/or one or more other types of NNs. NN 609a may comprise one or more different types of NNs or different layers for different types of NNs. For example, NN 109a may include one or more individual layers having one or more configurations.

[0127] During the training process, training data 607a may be input into NN 609a and may be used to learn the parameters and/or tune hyperparameters 617. The training may be performed by initializing parameters and/or hyperparameters of the NN 609a, generating and/or accessing the training data 607a, inputting the training data 607a into the NN 609a, calculating the error or loss from the output of the NN 609a to a target output 615a via a loss function 613 (e.g., utilizing gradient descent and/or associated back propagation), and/or updating the parameters and/or hyperparameters 617.

[0128] The loss function 613 may be implemented using backpropagation-based gradient updates and/or gradient descent techniques, such as Stochastic Gradient Descent (SGD), synchronous SGD, asynchronous SGD, batch gradient descent, and/or mini-batch gradient descent. Examples of loss or error functions may include functions for determining a squared-error loss, a mean squared error (MSE) loss, a mean absolute error loss, a mean absolute percentage error loss, a mean squared logarithmic error loss, a pixel-based loss, a pixel-wise loss, a crossentropy loss, a log loss, and/or a fiducial-based loss. Loss functions may be implemented in accordance one or more quality metrics, such as a Signal to Noise Ratio (SNR) metric or another signal or image quality metric.

[0129] An optimizer may be implemented along with loss function 613. The optimizer may be an algorithm or function that is configured to adapt attributes of the NN 609a, such as a learning rate and/or weights, to improve the accuracy of the NN 609a and/or reduce the loss or error. The optimizer may be implemented to update the parameters and/or hyperparameters 617 of NN 609a.

[0130] The training process may be iterated to update the parameters and/or hyperparameters 617 until an end condition is achieved. The end condition may be achieved when the output of NN 609a is within a predefined threshold of target output 615a.

[0131] After the training process is complete, the trained NN 609a, or portions thereof, may be stored for being implemented by one or more devices. The trained NN 609a, or portions thereof, may be implemented in other downstream algorithms or processes, as may be further described herein. The trained NN 609a, or portions thereof, may be implemented on the same device on which the training was performed. The trained NN 609a, or portions thereof, may be transmitted or otherwise provided to another device for being implemented. For example, the NN 609b, 609c may include one or more portions of the trained NN 609a. The NN 609b and NN 609c may receive respective input data 607b, 607c and generate respective outputs 615b, 615c. The output 615b, 615c may be generated in one or more formats, such as a tensor, a text format (e.g., a word, sentence, or other sequence of text), a numerical format (e.g., a prediction), an audio format, an image format (e.g., including video format), another data sequence format, and/or another output format. The output 615b, 615c may be aggregated at one or more devices for being further processed and/or implemented in other downstream algorithms or processes, as may be further described herein.

[0132] Alternatively, or additionally, after the training process is complete, the trained parameters and/or tuned hyperparameters 617, or portions thereof, may be stored for being implemented by one or more devices. The trained parameters and/or tuned hyperparameters 617, or portions thereof, may be implemented in other downstream algorithms or processes, as may be further described herein. The trained parameters and/or tuned hyperparameters 617, or portions thereof, may be implemented on the same device on which the training was performed. The trained parameters and/or tuned hyperparameters 617, or portions thereof, may be transmitted or otherwise provided to another device for being implemented. For example, trained parameters and/or tuned hyperparameters 617, or portions thereof, may be transmitted or otherwise provided to another device or devices that may implement the NN 609b, 609c based on the trained parameters and/or tuned hyperparameters 617. For example, NN 609b, NN 609c may be constructed at another device based on the trained parameters and/or tuned hyperparameters 617, or portions thereof. NN 609b and NN 609c may be configured from the parameters/hyperparameters 617, or portions thereof, to receive respective input data 607b, 607c and to generate respective outputs 615b, 615c. Outputs 615b, 615c may be generated in one or more formats, such as a tensor, a text format (e.g., a word, sentence, or other sequence of text), a numerical format (e.g., a prediction), an audio format, an image format (e.g., including video format), another data sequence format, and/or another output format. Outputs 615b, 615c may be aggregated at one or more devices for being further processed and/or implemented in other downstream algorithms or processes, as may be further described herein.

[0133] The AI/ML models and/or algorithms described herein may be implemented on one or more devices. For example, AI/ML 609 may be implemented in whole or in part on one or more devices, such as one or more WTRUs, one or more base stations, and/or one or more other network entities, such as a network node or a network server. Example networks in which AI/ML may be distributed may include federated networks. A federated network may include a decentralized group of devices that each include AI/ML. As shown in FIG. 6C, the AI/ML 609b and AI/ML 609c may be distributed across separate devices. Though FIG. 6C shows two models (e.g., AI/ML 609b and AI/ML 609c), any number of models may be implemented across any number of devices. The AI/ML may be implemented for collaborative learning in which the AI/ML is trained across multiple devices. In another example, the AI/ML may be trained at a centralized location or device and one or more portions of the AI/ML, or trained parameters and/or tuned hyperparameters, may be distributed to decentralized locations. For example, updated parameters or hyperparameters may be sent to one or more devices for updating and/or implementing the AI/ML thereon.

[0134] FIG. 6D is a schematic illustration of an example system environment 601 b for training and/or implementing an AI/ML model that includes an auto-encoder. An Auto-encoder (AE) 609b may include one of more DNNs 611 . For example, the AE 609b may include a class of DNNs 611 that arise in context of an un-supervised machine learning setting. Data (e.g., high-dimensional data) 607b may be (e.g., non-linearly) transformed to a lower dimensional latent vector, for example, using a DNN based encoder. A lower dimensional latent vector may be used to reproduce the high-dimensional data, for example using a non-linear decoder. The encoder may be represented as E(x,- W_e), where x may be the high-dimensional data and W_e may represent the parameters of the encoder. The decoder 619b may be represented as £)(z; W_d), where z may be the low-dimensional latent representation and W_d may represent the parameters of the decoder. Using training data 607b { x , • •• , x_w}_; for example, the auto-encoder may be trained. For example, the auto-encode may be trained using Equation (1) below:

[0136] Equation (1) may be solved (e.g., approximately solved), for example, using a backpropagation algorithm. The trained encoder E x W_P ^tr) may be used to compress the high-dimensional data, and trained decoder D z; W_d ^r) may be used to decompress the latent representation. The auto-encoder 609b may be trained and/or implemented on one or more devices to determine and/or update parameters and/or hyperparameters 617 of NN 609a. Training data 607b may include measurement(s), for example RS measurements. The target output 615b may include one or more of predicted beam pairs, predicted measurements for the one or more beam-pairs based on the stored training data samples and a predictive beam refinement configuration, predictive beam identifiers, codebook identifiers, predictive layer 1 received signal received power (L1-RSRP) values, and/or predictive angle of arrival (AoA), for example based on the predicted measurements. The training data may be associated with a wider beam or beam pair. The output may be associated with a narrower beam or beam pair.

[0137] Once a model is trained, it can be deployed (e.g., in a test environment, e.g., test network) for performance testing Model monitoring may be performed after deployment in a real network, as the current network/WTRU conditions can become different from the scenarios/conditions in which the model was trained/tested. If the model monitoring is shown to provide undesirable WTRU/network performance, a decision may be made to switch to another model, or stop using AI/ML based operations for the concerned function, etc. Performance monitoring also may be used to determine whether a model needs to be retrained with new sets of data. Model training and monitoring may be performed at the WTRU, at the network, or in collaboration between the two. Model training and monitoring may be performed offline or online.

[0138] In a network/WTRU that utilizes AI/ML based functions, it may be advantageous to have substantial and relevant data available (e.g., radio quality measurements, quality of experience, quality of experience (QoE), measurements such as throughput, delay/latency, buffering levels, etc.) for model training and performance monitoring. NR has mechanisms for measuring radio conditions while a WTRU is in IDLE/INACTIVE/CONNECTED, logging them while in IDLE/I NACTIVE, and reporting the measurements in CONNECTED (either the logged measurements when going to CONNECTED state, or the immediate measurements performed in CONNECTED state when the certain event is fulfilled or periodically).

[0139] Regarding radio resource management (RRM) and MDT frameworks of NR in the context of AI/ML model training and performance monitoring, however, measurement logging is not supported in CONNECTED state. Due to beam consolidation that considers only a certain number of best beams of a given cell (e.g., beams with a radio quality above a certain threshold), there is no possibility to "track” a beam's quality over a certain duration. Logging every sample of measured beam/cell or even the L3 filtered measurements may be overburdensome (e.g., memory requirements at the WTRU), and some of the logged data may not be relevant to the task at hand. Measurements performed for RRM purposes may not be sufficient for model training or performance training purposes, as the network is likely to configure the WTRU with as little measurements as possible that is expected to be sufficient for normal operations (e.g., WTRU configured to measure only a handful of neighbor cells/frequencies). If extensive logging is made by the WTRU, most of the logged data may not be relevant for model training or performance monitoring, for example, for performance monitoring, only measurements that were performed some duration before and after an action is taken (e.g., autonomously by the WTRU due to AI/ML functions, triggered by the network, etc.) may be sufficient. Various embodiments discussed below address these shortcomings.

[0140] In various example embodiments, a WTRU may be configured to perform logging of beam/cell measurements of one or more cells, where the configuration may include conditions for determining when to start/stop logging, the cell/beam identities to be logged, conditions for determining which measurement results are to be included in the logging (e.g., conditions to determine whether to log an entry or not), perform the measurement logging, send an indication about the availability of the logged measurements, and send the report upon some condition (e.g., receiving a request/grant from the network). For example, a first condition associated with when to start logging may be related to a likelihood of an occurrence of at least one first event within a first period of time. The WTRU may perform measurements and analyze the measurement results. If the measurement results indicate that the likelihood of the at least one event occurring within the first period of time is equal to or exceeds a threshold, the WTRU may start logging additional measurements. A second condition associated with when to stop logging may be related to a likelihood that the at least one second event has occurred within a second period of time. Based on a determination that the likelihood of the at least one event having occurred within the second period of time exceeds a second threshold, the WTRU may stop logging measurements. The WTRU may then send the report comprising an indication of the logged measurements.

[0141] In an example embodiment, a WTRU may be configured to perform beam/cell level measurement logging and logged measurement reporting of one or more cells, where the configuration may include at least one of measurement resources, information to be logged, and/or triggers. Measurement resources (e.g., reference signal (RS) resources) on which to perform and log measurements may include the identities of the cells to be logged (e.g., frequency, list of cells, etc.), the identities of particular beams or RS resources (e.g., per cell), or any appropriate combination thereof. Information to be logged may include beam/cell ID and quality, beam quality (e.g., the detected beams of at least the configured beam identities or RS resources), cell quality of the configured cells, where the cell quality derivation considers at least one of the indicated beams or all of the detectable beams of the cell, timing and location of the measurement (time/location/serving cell information), or any appropriate combination thereof. Triggers to perform measurement logging and/or logged measurement reporting may include reception of a request/indication from network. Triggers may be based on time durations. Triggers may include when a serving/neighbor cell radio quantity is above/below absolute/relative thresholds. Triggers may be based on WTRU conditions (e.g., if battery level is above a certain value, when WTRU UL/DL throughput is below a certain value, when data inactivity is longer than a configured duration, when WTRU mobility state is below/above a certain value), or the like. Triggers may be based on the value of the performed measurement quantity, absolute value of the measurement (e.g., above a certain value), a relative measurement value, relative to a previous measurement value (e.g., a previously logged measurement value), or any appropriate combination thereof. Triggers may be based on WTRU location (WTRU may log different measurements for different number of beams for example, based on location and configurations). Triggers may be based on WTRU action (e.g., handover to a particular cell, performing an AI/ML action such as model switching, etc.). Triggers may be based on anticipated events/conditions. Triggers may be based on the number/size of logged measurements (WTRU may filter logging to reduce logged information based on the current size of all the logged data). [0142] The WTRU may perform measurements on the configured cells and/or beams and/or RS resources. The WTRU may be triggered to log one or more measurements as per at least one of the configured triggering conditions The WTRU may be triggered to report one or more logged measurements as per at least one of the configured triggering conditions. The WTRU may report the one or more logged measurements and associated logged information.

[0143] A WTRU may be configured with a measurement logging configuration that specifies several aspects related to logging, such as what is to be measured for logging purposes, when the WTRU starts/resumes logging, when the WTRU stops/suspends logging, while logging is active, what condition must be fulfilled for a measurement result to be included in the log, information to be included in the logged entry in addition to the measurements, what triggers the measurement log reporting to the network, or the like, or any appropriate combination thereof.

[0144] A WTRU may be configured with a measurement configuration (e.g., measurement object) and a logging configuration associated with the measurement object (akin to measurement reporting configuration). A given measurement object may be associated with RRM measurement reporting configuration and a logging configuration. Separate measurement objects may be used for RRM measurements and for logging purposes. A WTRU may be configured with one or more cells whose measurements it must log (e.g., serving cells, neighbor cells at a certain frequency/radio access technology (RAT), list of specific neighbor cells, etc., beam/RS index/identity, etc.) and this could be per a given servi ng/neighbor cell (e.g., log all neighbor cells of frequency x when the serving cell is a or b, log all neighbor cells of frequency y when the serving cell is of frequency z, etc.). A WTRU may be configured with one or more cells whose measurements it must not log. A WTRU may be configured with one or more beams (e.g., beam/RS index/identity, etc.) whose measurements it must log (e.g., per a given serving/neighbor cell). A WTRU may be configured with one or more beams (e.g., beam/RS index/identity, etc.) whose measurements it must not log (e.g., per a given serving/neighbor cell).

[0145] Regarding determining when a measurement result is logged, a logging configuration may be periodic, or event/condition triggered. With periodic triggering, a WTRU, at every reporting periodicity, may append the latest measurements in the log entry. With event triggered reporting, a WTRU may log the latest measurements only if the conditions for logging the latest measurements are fulfilled.

[0146] Event triggered measurement logging conditions may be dependent on the serving cell's quality. For example, a WTRU may log the latest measurements if a serving cell quality is above a certain threshold, a serving cell quality is below a certain threshold, a serving cell quality is between two thresholds, or the like.

[0147] Event triggered measurement logging conditions may be dependent on the quality of the beam/cell being logged. For example, a WTRU may log the beam/cell measurements if a beam/cell quality is above a certain threshold, a beam/cell quality is below a certain threshold, a beam/cell quality is between two thresholds, a beam/cell quality has changed from previous logged entry for the cell/beam by more than a certain absolute/relative threshold, or the like.

[0148] Various triggers may start, stop, suspend, or resume the performance of measurement logging. For example, the reception of a measurement logging configuration may be considered by a WTRU as an indication to start performing the measurement logging. A WTRU may be configured to wait for an explicit/separate indication to start measurement logging (or resume a measurement logging that has been suspended). A WTRU may be configured to perform measurement logging until an explicit indication is received indicating to stop/suspend measurement logging. A WTRU may be configured to perform measurement logging until a certain time duration has elapsed since the start of the measurement logging. A WTRU may be configured to perform measurement logging until a certain amount of measurement results (e.g. , number of samples, size, e.g., in Mbytes, etc.) has been logged. A WTRU may be configured to start/resume measurement logging when it is in certain locations (e.g., between GNSS co-ordinates) and otherwise stop/suspend the measurement logging. A WTRU may be configured to start/resume measurement logging when its mobility state is at a certain level (e.g., low/high mobility state, speed above/below a certain level, etc.) and otherwise stop/suspend the measurement logging. A WTRU may be configured to start/resume measurement logging when its battery level is at a certain level (e.g., above a certain percentage) and otherwise stop/suspend the measurement logging. A WTRU may be configured to start/resume measurement logging when its overheating level is at a certain level (e.g., below a certain level) and otherwise stop/suspend the measurement logging. A WTRU may be configured to start/resume measurement logging when its UL/DL throughput is at a certain level (e.g., below a certain throughput threshold) and otherwise stop/suspend the measurement logging. A WTRU may be configured to start/resume measurement logging when its UL/DL data inactivity level at a certain level (e.g., more than x seconds of UL/DL data inactivity) and otherwise stop/suspend the measurement logging. A WTRU may be configured to start/resume measurement logging when its buffer size is at a certain level (e.g., remaining/available buffer size below a certain buffer threshold) and otherwise stop/suspend the measurement logging. A WTRU may be configured to start/resume measurement logging at certain time durations (e.g., between 10 am and 10:10 am) and stop/suspend measurement logging at other time durations. A WTRU may be configured to stop/suspend measurement logging at certain time durations (e.g., between 10 am and 10:10 am) and start/resume measurement logging at other time durations. A WTRU may be configured to start/resume measurement logging whenever it is being served by a certain cell (or cells), frequency (or frequencies), RAT(s), etc., and stop/suspend the logging otherwise. A WTRU may be configured to stop/suspend measurement logging whenever it is being served by a certain cell (or cells), frequency (or frequencies), RAT(s), etc., and start/resume the logging otherwise. A WTRU may be configured to start/resume measurement logging whenever the quality of its serving cell or a neighbor cell is at a certain threshold (e.g., serving/neighbor cell below a threshold, serving/neighbor cell above a threshold, serving/neighbor cell between two thresholds, serving cell below/above a neighbor cell by more than a certain threshold, etc.). A WTRU may be configured to stop/suspend the measurement logging whenever the quality of its serving cell or a neighbor cell is at a certain threshold (e.g., serving/neighbor cell below a threshold, serving/neighbor cell above a threshold, serving/neighbor cell between two thresholds, serving cell below/above a neighbor cell by more than a certain threshold, etc.). A WTRU may be configured to perform measurement logging until it performs a certain action (e.g., network triggered action such as a handover; UE triggered action such as a CHO, AI/ML model switching, start using AI/ML for a certain function or any function, deactivate AI/ML operation for all or certain functions, etc.). A WTRU may be configured to perform measurement logging until it performs a certain number of actions. A WTRU may be configured to perform measurement logging if it has not performed a certain action within a given duration. A WTRU may be configured to perform measurement logging if it has not performed an action a certain number of times within a given duration. A WTRU may be configured to start/resume performing measurement logging when it anticipates some upcoming action/event. The anticipation of the upcoming action/event can be implicit (e.g., based on another AI/ML prediction model at the WTRU) or explicit (e.g., based on network configuration). For example, a WTRU may be configured with a CHO configuration (e.g., condA3, target cell better than serving by more than thresholdl), and the WTRU may further be configured with another threshold, thresh2 < threshl , and if a target cell becomes better than the serving cell by threshl (i.e., the likelihood of the CHO is becoming high), then UE starts/resumes the measurement logging. A WTRU may be configured to perform measurement logging after it performs a certain action (e.g., network triggered action such as a handover; WTRU triggered action such as a CHO, AI/ML AI/ML model switching, start using AI/ML for a certain function or any function, deactivate AI/ML operation for all or certain functions, etc.).

[0149] If a WTRU has started/resumed performing measurement logging due to an anticipation of an action/event, it may be configured to stop/suspend the logging if the anticipated action/event does not happen within a given time duration. If the WTRU has started/resumed performing measurement logging due to an anticipation of an action/event, and the anticipated action/event happens, the WTRU may be configured to continue to log the measurements until a certain condition is fulfilled (e.g., until a certain duration has elapsed, until a certain amount/number/time window of measurements were taken, e.g., equal to those taken before the action/event happened, etc.). A WTRU may be configured to keep a sliding window of measurements (e.g., a certain size/duration of measurements in temporary memory), where the latest measurement result replaces the oldest measurement result after the configured window of measurements is taken. A WTRU may be configured to transfer a sliding window of temporary log into the actual measurement log when a certain action/event happens. The WTRU may further be configured to log a certain window of measurements after the action/event happens (e.g., equal in size/duration to the measurements logged before the action/event, until a subsequent event happens, etc.). The start/stop/suspend/resume of measurement logging, according to any of the solutions above, may be performed for all measurement logging. The start/stop/suspend/resume of measurement logging, according to any of the solutions above, is performed independently for each measurement logging configuration. Some measurement configurations may be active while others are suspended/stopped. For example, the explicit/separate indication to start/stop/suspend/resume measurement logging may be specific to a particular measurement logging configuration (e.g., logging identity, measurement id, etc., included in the indication). In another example, different conditional ways to start/stop/suspend/resume measurement logging discussed above can be configured for different measurement logging configurations (e.g., the time duration to start/stop one measurement logging configuration could be different from another measurement logging configuration).

[0150] If a WTRU is configured with a measurement object specific to measurement logging, then the WTRU may activate the measurement (e.g., starts performing the measurements according to the logging measurement configuration) if the measurement logging is being performed (e.g., activate the performing of the associated measurement on starting/resuming the logged measurements according to any of the solutions above, stop performing the associated measurements on stopping/suspending the logged measurements according to any of the solutions above, etc.). Performing measurements for logging and the logging of the measurements may be controlled independently. For example, a WTRU may be configured to continue performing measurements associated with logging even if logging has been stopped/suspended as described herein. If a WTRU is configured to perform measurement logging before and after an (anticipated) event/action, it may be further configured with measurement logging configuration to apply after the event that is different from the measurement logging configuration that was being used before the event/action (e.g., WTRU configured to perform/log more/less cells/frequencies after the event/action as compared to before the action).

[0151] Regarding information to be logged, a WTRU may be configured to log filtered measurements (e.g., using similar or different filtering parameters like L3 RRM measurements). A WTRU may be configured to log unfiltered measurements (e.g., every L1/L3 measurement sample). The cell quality to be logged may be a cell quality derived according to RRM measurements configuration (e.g., average of best n beams above a certain threshold). A WTRU, when logging an entry regarding a cell, may be configured to also log all the detected beams of the cell. The cell quality to be logged may be a cell quality specific to logging purposes. For example, the logged cell quality may be derived based on considering at least one of the indicated beams to be logged, considering only the beams that were indicated to be logged, or considering all the detected beams.

[0152] If a WTRU, at a particular logging instant, is not able to detect a particular beam/cell that it was configured to log, it may be configured to make an entry in the log indicating that the concerned beam/cell was not detected. A WTRU may be configured to include absolute/relative location/time or serving cell information in the log (e.g., with each log entry, associated with a group of log entries, etc.). A WTRU may be configured to make an entry indicating a particular WTRU or network triggered action (e.g., network triggered action such as a handover, WTRU triggered action such as a CHO, AI/ML model switching, start using AI/ML for a certain function or any function, deactivate AI/ML operation for all or certain functions, etc.). Like a measurement result entry, this entry may contain associated location/time/serving cell information. [0153] A WTRU may be configured to make an entry in the log indicating that the measurements after this entry were logged because of anticipated action/event. A WTRU may be configured with a first measurement object/measurement ID for RRM measurement reporting and a second measurement object/measurement ID for measurement logging. For example, both the first measurement ID and second measurement ID may result in the same measurement result. The WTRU may be configured to skip the logging if the same measurement is applicable for the reporting in RRM measurement report and the logged measurement. In other words, the WTRU may be configured to skip logging of a measurement, if such measurement is included in a RRM measurement report. For example, this may be beneficial to avoid duplicate reporting. A WTRU may be configured to log a reference to the transmitted RRM measurement report instead of logging the entire measurement result.

[0154] A WTRU may be configured to tag the logged measurements with a logical identifier associated with specific event that triggered the logging. For example, the logical identifier may have a preconfigured structure. The preconfigured structure may include trigger event ID (e.g., different identifiers for CHO, AI/ML model switching, cell quality above/below threshold etc.), an ID associated with the location (cell ID, beam ID etc.), an ID associated with the time (single frequency network (SFN), coordinated universal time (UTC), etc.). A WTRU may be configured to tag a logged measurement with a network (NW) command ID, if that logging is event triggered by a request/reconfiguration/command from the NW. Possibly the NW command ID may be signaled within the request/reconfiguration/command from the NW. For example, the NW may trigger a handover via RRC reconfiguration message. Such RRC reconfiguration message may trigger a logging action at the WTRU. Such RRC reconfiguration message may carry a NW command ID. A WTRU may tag the logged measurement with the NW command - wherein the tagging may refer to attaching a unique ID to the logged measurement. In an example, a WTRU may be configured to use RRC transaction identifier associated with the RRC reconfiguration message as the NW command ID or a portion thereof.

[0155] Regarding reporting logged measurements, a WTRU may send an indication to the network indicating it has logged measurement available. This may be triggered due to one or more of the following reasons. For example, sending the indication by the WTRU may be triggered by the WTRU receiving a request from the network inquiring if the WTRU has logged measurements. Sending the indication may be triggered when logging is stopped/paused (e.g., according to any of the solutions above). Sending the indication may be triggered when the log size is above a certain configured size. Sending the indication may be triggered when the log is older than a certain configured time duration value. Sending the indication may be triggered when the WTRU performs RRC state transition (e.g., IDLE/I NACTIVE to CONNECTED, upon reception of RRC Release, etc.) Sending the indication may be triggered when sending an UL control message (e.g., RRC complete message, MAC CE, etc.). Sending the indication may be triggered when the WTRU performs a certain action (e.g., upon HO to a certain cell, after performing an AI/ML related action, after it has logged measurements before and after an action, etc.). [0156] A trigger described herein for measurement logging may be used to trigger measurement reporting (e.g., in addition to measurement logging or in lieu of measurement logging). A WTRU may be configured to send the logged measurements without the need to send an indication of logged measurement availability and receive a request to send the log from the network. The indication of availability of logged measurements may include further information such as, for example, a size of the log, beams/cells/frequencies/RATs included in the log, time duration of the log (e.g., length, start and end time, etc.), cell where the logged measurement was configured, cells the WTRU has been served by while the measurements were being logged, location (e.g., location where the log started, location where the log ended, etc ), type(s) of triggers that led to logging, e.g., types of triggers for which the logged measurements are available, or the like, or any appropriate combination thereof.

[0157] A WTRU may send logged measurements upon explicit request from the network. A WTRU may receive a request from the network for logged measurement, which may include information regarding what part of the log the WTRU should send. For example, the logging associated with a specific trigger condition should be sent. A WTRU may receive a request to report the logged measurements associated with specific logging measurement ID.

[0158] The request from the network for logged measurements may include information regarding what part of the log the WTRU should send (e.g., only measurements concerning some beams/cells/frequencies, only measurements performed while in a certain serving cell, the first/last x seconds of logged measurements, etc.).

[0159] A WTRU may be configured to send the logged measurements in several logged measurement reports (e.g., depending on the log size and resources granted by the network to send the logged measurements). A WTRU may be configured to delete the logged measurements (or parts of the logged measurements, if granular logged measurement report was requested from the network according to the solution above) after it has successfully sent them to the network. A WTRU may be configured to delete the logged measurements after it has stored them for a certain duration and network has not requested them. A WTRU may be configured to delete the logged measurements on transitioning to IDLE/I NACTIVE from CONNECTED.

[0160] Although embodiments described herein are directed to a WTRU in CONNECTED state, all the embodiments are applicable also to I DLE/I NACTIVE state. As such, logged measurement configuration may be used across RRC states. For example, a WTRU may receive configurations in CONNECTED state, perform the measurements and log in CONNECTED state, transition to IDLE/I NACTIVE, continue to perform and log the measurements while in IDLE/I NACTIVE, etc A WTRU may receive the measurement logging configuration on transitioning to IDLE/I NACTIVE (e.g., in RRC Release), and use the measurement configurations in IDLE/I NACTIVE state and then also after transitioning to CONNECTED state. In an example, a WTRU may be configured to send the logged measurement configuration to the network upon state transition (e.g., WTRU configured with logged measurement in cell x while in CONNECTED state, WTRU transitioning to IDLE state, WTRU transitioning to CONNECTED state in cell y, etc.). [0161] WTRU configuration/behavior may be different in I DLE/I NACTI VE versus CONNECTED (e.g., WTRU configured to perform only a subset of the measurements/logging). The measurement logging configuration may be provided to a WTRU in a dedicated fashion (e.g., RRC message), common signaling (e.g., SIB) or a combination. Although embodiments described herein are directed to L3/RR- like measurements, all embodiments described here are equally applicable to L1 measurements (filtered or unfiltered, even L1 CSI measurements/reports).

[0162] Embodiments described herein directed to radio measurements, also are equally applicable to any other measurement/metric/key performance indicator (KPI) a WTRU is capable of measuring/determining. For example, a WTRU may be configured to log some Quality of Experience (QoE) metric, such as throughput, application buffer level, before and after an action/event, according to any of the solutions above. A WTRU may be configured to perform and log radio related measurements before an action is taken and perform/log QoE related measurements after an action is taken, or vice versa.

[0163] In an example embodiment, a WTRU may be configured to perform and log measurements, where configuration may include at least one, or any appropriate combination, of the following. The configuration may include measurement type (beam/cell quality measurements, throughput measurements, delay/latency measurements). The configuration may include a first measurement and logging configuration. The configuration may include a second measurement and logging configuration (which can be the same as or different from the first configuration). The configuration may include a first condition when to start performing the measurements (e.g., time location, radio conditions, etc.) according to the first measurement configuration. For example, a first condition being a determination that a subsequent WTRU action is required/anticipated within a given time (e.g., HO, change in AI/ML model, fallback AI/ML operation). The configuration may include a second condition when to start logging the measurements. For example, a second condition being related to the timing of the WTRU action (e.g., triggered by the first condition). The second condition may be the same as the first condition. The configuration may include a third condition when to stop performing the measurements. For example, a third condition being related to a WTRU action (e.g., triggered by a first condition) has been completed. The configuration may include a fourth condition when to stop logging the measurements. For example, a fourth condition being related to the timing of the WTRU action (e.g., triggered by the first condition). The fourth condition may be the same as the third condition.

[0164] A WTRU may start performing measurements according to the first measurement configuration when the first condition is satisfied. A WTRU may begin logging measurement results according to the first logging configurations when the second condition is satisfied. A WTRU may perform an action associated with the first condition, for example HO, AI/ML model switch, fallback to legacy operations from AI/ML operation). A WTRU may log information related to the action associated with the first condition, for example, a cause value, metadata/detailed information about the action such as the identity of the action, AI/ML models before/after the action, ti me/location/cel I when/where the action was taken. A WTRU may stop performing the measurements according to the first configuration and stop logging the measurements according to the first logging configuration. A WTRU may start performing measurements according to the second measurement configuration. A WTRU may begin logging measurement results according to the second logging configuration. A WTRU may stop performing the measurements according to the second configuration when the third condition is satisfied. A WTRU may stop logging the measurements according to the second logging configurations when the fourth condition is satisfied. A WTRU may report logged measurements, for example, immediately after the fourth condition is satisfied. A WTRU may report logged measurements based on reception of network request.

[0165] FIG. 7 depicts a simplified overview of the above embodiment, wherein the first and second condition are the same, the third and fourth condition are the same, and the WTRU may send the logged measurements immediately after logging is stopped.

[0166] Although features and elements are provided above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly provided as such. Functionally equivalent methods, apparatuses, and articles of manufacture, within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims.

[0167] In addition, methods provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer- readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media (which do not include transitory signals). Examples of computer-readable storage media, which are differentiated from signals, may include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0168] In an illustrative embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable storage medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and/or any other computing device.

Claims

CLAIMS What is claimed is:

1 . A wireless transmit/receive unit (WTRU) comprising: a memory; and a processor configured to: receive a configuration related to measurement logging and reporting, where the configuration includes at least one first condition to start logging measurements in the memory and at least one second condition to stop the logging of the measurements in the memory, wherein the at least one first condition is related to a likelihood of an occurrence of at least one first event within a first period of time, and wherein the at least one second condition is related to a likelihood that at least one second event has occurred within a second period of time; perform first measurements; in response to the first measurements indicating that the likelihood of the at least one first event occurring within the first period of time is at or above a first threshold, start logging second measurements in the memory; and based on a determination that the likelihood of the at least one second event having occurred within the second period of time being above a second threshold, stop logging the second measurements in the memory; and send a report comprising an indication of the logged second measurements.

2. The WTRU of claim 1, the processor further configured to send the report in response to a determination that a third condition for reporting the measurements is fulfilled, wherein the third condition is related to a likelihood of an occurrence of at least one third event.

3. The WTRU of claim 1, wherein the report is sent in response to a request from a network.

4. The WTRU of claim 1 , wherein the at least one first condition comprises an identification of at least one configured cell for logging.

5. The WTRU of claim 1 , wherein the at least one first event is based on a location of the WTRU.

6. The WTRU of claim 1 , wherein the likelihood of the occurrence of at least one of the at least one first event or the at least one second event is based on an artificial intelligence/machine learning (AI/ML) model.

7. The WTRU of claim 1 , wherein the first measurements comprise a quality of a cell.

8. The WTRU of claim 1, wherein the first measurements comprise a quality of a beam.

9. The WTRU of claim 1, the processor further configure to, in response to the first measurements indicating that the likelihood of the at least one first event occurring within the first period of time is below a threshold, delete from the memory the first measurements.

10 The WTRU of claim 1 , the processor further configured to log in the memory a logical identifier associated with an artificial intelligence/machine learning (AI/ML) model.

11. A method performed by a wireless transmit/receive unit (WTRU), the method comprising: receiving a configuration related to measurement logging and reporting, where the configuration includes at least one first condition to start logging measurements in memory and at least one second condition to stop the logging of the measurements in the memory, wherein the at least one first condition is related to a likelihood of an occurrence of at least one first event within a first period of time, and wherein the at least one second condition is related to a likelihood that at least one second event has occurred within a second period of time; performing first measurements; in response to the first measurements indicating that the likelihood of the at least one first event occurring within the first period of time is at or above a first threshold, start logging second measurements in the memory; and based on a determination that the likelihood of the at least one event having occurred within the second period of time being above a second threshold, stop logging the second measurements in the memory; and sending a report comprising and indication of the logged second measurements.

12. The method of claim 11, further comprising sending the report in response to a determination that a third condition for reporting the measurements is fulfilled, wherein the third condition is related to a likelihood of an occurrence of at least one third event.

13. The method of claim 11, wherein the report is sent in response to a request from a network.

14. The method of claim 11, wherein the at least one first condition comprises an identification of at least one configured cell for logging.

15. The method of claim 11 , wherein the at least one first event is based on a location of the WTRU.

16. The method of claim 11, wherein the likelihood of the occurrence of at least one of the at least one first event of the at least o second even is based on an artificial intelligence/machine learning (Al/M) model.

17 The method of claim 1, wherein the first measurements comprise measuring a quality of a cell.

18. The method of claim 11 , wherein the first measurements comprise measuring a quality of a beam.

19. The method of claim 11 , further comprising, in response to the first measurements indicating that the likelihood of the at least one first event occurring within the first period of time is below a threshold, deleting from the memory the first measurements.

20. The method of claim 11 , further comprising logging in the memory a logical identifier associated with an artificial intelligence/machine learning (AI/ML) model.