Data collection procedure and model training

Abstract

In wireless communication systems, user equipment (UE) vendors and network entity vendors may configure one or more UEs and network entities to perform data collection and train channel state information (CSI) feedback (CSF) models.

Description

[Technical field]

[0001] The present disclosure relates generally to communication systems, and more particularly to training encoders and decoders associated with user equipments (UEs) and network entities, respectively.

[0002] introduction

[0002] Wireless communication systems have been widely deployed to provide various telecommunication services, such as telephone, video, data, messaging, and broadcast. A typical wireless communication system may employ multiple access technologies capable of supporting communication with multiple users by sharing available system resources. Examples of such multiple access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, and time division synchronous code division multiple access (TD-SCDMA) systems.

[0003]

[0003] These multiple access technologies have been adopted in various telecommunications standards to provide a common protocol that allows different wireless devices to communicate at a city, country, region, or even global level. An exemplary telecommunications standard is 5G New Radio (NR). 5G NR is part of the continuing mobile broadband evolution promulgated by the Third Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (e.g., for the Internet of Things (IoT)), and other requirements. 5G NR includes services associated with enhanced mobile broadband (eMBB), massive machine type communications (mMTC), and ultra-reliable low latency communications (URLLC). Some aspects of 5G NR may be based on the 4G Long Term Evolution (LTE) standard. Further improvements are needed in 5G NR technology that may also be applicable to other multiple access technologies and the telecommunications standards that employ those technologies. Summary of the Invention

[0004]

[0004] The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, nor is it intended to identify key or critical elements of all aspects, nor to delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

[0005] In one aspect of the present disclosure, a method, a non-transitory computer-readable medium, and an apparatus are provided for a user equipment (UE) vendor to train one or more encoder-decoder pairs based on a raw data set of the UE vendor, generate one or more training sets based on outputs of one or more encoders running on the raw data set of the UE vendor, and communicate the one or more training sets to a network entity vendor.

[0006]

[0006] The present disclosure also provides an apparatus (e.g., a UE vendor / server) including a memory storing computer-executable instructions and at least one processor configured to execute the computer-executable instructions to perform the above method, an apparatus including means for performing the above method, and a non-transitory computer-readable medium storing computer-executable instructions for performing the above method.

[0007] In another aspect, the present disclosure provides a method, a non-transitory computer-readable medium, and an apparatus for a UE vendor to train one or more encoder-decoder pairs based on a raw data set of the UE vendor, generate two training sets for each of the one or more encoder-decoder pairs based on outputs of one or more encoders running on the raw data set of the UE vendor, and communicate the two training sets to a network entity vendor.

[0008]

[0008] The present disclosure also provides an apparatus (e.g., a UE vendor / server) including a memory storing computer-executable instructions and at least one processor configured to execute the computer-executable instructions to perform the above method, an apparatus including means for performing the above method, and a non-transitory computer-readable medium storing computer-executable instructions for performing the above method.

[0009] In another aspect, the present disclosure provides a method, a non-transitory computer-readable medium, and an apparatus for a network entity vendor to receive one or more training sets corresponding to one or more encoder-decoder pairs from a UE vendor and train one or more decoders associated with the one or more training sets.

[0010]

[0010] The present disclosure also provides an apparatus (e.g., a network entity vendor / server) including a memory storing computer-executable instructions and at least one processor configured to execute the computer-executable instructions to perform the above method, an apparatus including means for performing the above method, and a non-transitory computer-readable medium storing computer-executable instructions for performing the above method.

[0011] In another aspect, the present disclosure provides a method, a non-transitory computer-readable medium, and an apparatus for a network entity vendor to receive two training sets corresponding to one or more encoder-decoder pairs from a UE vendor and train one or more decoders associated with the two training sets.

[0012]

[0012] The present disclosure also provides an apparatus (e.g., a network entity vendor / server) including a memory storing computer-executable instructions and at least one processor configured to execute the computer-executable instructions to perform the above method, an apparatus including means for performing the above method, and a non-transitory computer-readable medium storing computer-executable instructions for performing the above method.

[0013] In another aspect, the present disclosure provides a method, a non-transitory computer-readable medium, and an apparatus for a UE, the method including: sending a training data request to a network entity, receiving a data collection configuration message from the network entity in response to sending the training data request, sending a data collection configuration acknowledgement (ACK) to the network entity in response to receiving the data collection configuration message, and performing a data collection procedure based on the data collection configuration message.

[0014]

[0014] The present disclosure also provides an apparatus (e.g., a UE) including a memory storing computer-executable instructions and at least one processor configured to execute the computer-executable instructions to perform the above method, an apparatus including means for performing the above method, and a non-transitory computer-readable medium storing computer-executable instructions for performing the above method.

[0015] In another aspect, the present disclosure provides a method, a non-transitory computer-readable medium, and an apparatus for a network entity to receive a training data request from a UE, in response to receiving the training data request, send a data collection configuration message to the UE, in response to sending the data collection configuration message, receive a data collection configuration ACK from the UE, and perform a data collection procedure based on the data collection configuration message.

[0016]

[0016] The present disclosure also provides an apparatus (e.g., a network entity) including a memory storing computer-executable instructions and at least one processor configured to execute the computer-executable instructions to perform the above method, an apparatus including means for performing the above method, and a non-transitory computer-readable medium storing computer-executable instructions for performing the above method.

[0017]

[0017] In another aspect, the present disclosure provides a method, a non-transitory computer-readable medium, and an apparatus for a UE, the method including: receiving a data collection configuration message from a network entity based on a training data request; in response to receiving the data collection configuration message, sending a data collection configuration ACK to the network entity; performing a data collection procedure based on the data collection configuration message; and reporting the training data between at least one of the network entity, a UE vendor, and a network entity vendor based on performing the data collection procedure.

[0018]

[0018] The present disclosure also provides an apparatus (e.g., a UE) including a memory storing computer-executable instructions and at least one processor configured to execute the computer-executable instructions to perform the above method, an apparatus including means for performing the above method, and a non-transitory computer-readable medium storing computer-executable instructions for performing the above method.

[0019]

[0019] In another aspect, the present disclosure provides a method, a non-transitory computer-readable medium, and an apparatus for a network entity, the method including: receiving a training data request from a network entity vendor; in response to receiving the training data request, sending a data collection configuration message to a UE; in response to sending the data collection configuration message, receiving a data collection configuration ACK from the UE; performing a data collection procedure based on the data collection configuration message; and receiving or reporting training data between the UE, the UE vendor, and the network entity vendor based on performing the data collection procedure.

[0020]

[0020] The present disclosure also provides an apparatus (e.g., a network entity) including a memory storing computer-executable instructions and at least one processor configured to execute the computer-executable instructions to perform the above method, an apparatus including means for performing the above method, and a non-transitory computer-readable medium storing computer-executable instructions for performing the above method.

[0021] In another aspect, the present disclosure provides a method, a non-transitory computer-readable medium, and an apparatus for a UE vendor, the method including: communicating a training data request to initiate model training for a UE vendor and a network entity vendor, receiving a training data report in response to communicating the training data request, performing model training for a channel status information (CSI) feedback (CSF) model, and communicating the model training report to the network entity vendor.

[0022]

[0022] The present disclosure also provides an apparatus (e.g., a UE vendor server) including a memory storing computer-executable instructions and at least one processor configured to execute the computer-executable instructions to perform the above method, an apparatus including means for performing the above method, and a non-transitory computer-readable medium storing computer-executable instructions for performing the above method.

[0023] In another aspect, the present disclosure provides a method, a non-transitory computer-readable medium, and an apparatus for a network entity vendor to communicate a training data request to initiate model training for a UE vendor and the network entity vendor, in response to communicating the training data request, receiving a training data report, performing model training for a CSF model, and communicating the model training report to the UE vendor.

[0024]

[0024] The present disclosure also provides an apparatus (e.g., a network entity vendor / server) including a memory storing computer-executable instructions and at least one processor configured to execute the computer-executable instructions to perform the above method, an apparatus including means for performing the above method, and a non-transitory computer-readable medium storing computer-executable instructions for performing the above method.

[0025]

[0025] To the accomplishment of the foregoing and related ends, the one or more aspects include the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of only a few of the various ways in which the principles of the various aspects may be employed, and the description is intended to include all such aspects and their equivalents. [Brief description of the drawings]

[0026] [Figure 1]

[0026] FIG. 1 illustrates an example of a wireless communication system including an access network according to an aspect of the present disclosure. [Figure 2A]

[0027] FIG. 2 illustrates an example of a first frame according to an aspect of the present disclosure. [Figure 2B]

[0028] FIG. 2 illustrates an example of a downlink (DL) channel in a subframe, according to certain aspects of the present disclosure. [Figure 2C]

[0029] FIG. 2 illustrates an example of a second frame according to an aspect of the present disclosure. [Figure 2D]

[0030] FIG. 1 illustrates an example of an uplink (UL) channel in a subframe, according to certain aspects of the present disclosure. [Diagram 3]

[0031] FIG. 2 illustrates an example of a base station and user equipment (UE) in an access network, according to an aspect of the present disclosure. [Figure 4]

[0032] FIG. 1 shows a diagram illustrating an example disaggregated base station architecture. [Diagram 5]

[0033] A diagram showing an example of a communication system including a UE vendor and a gNB vendor. [Figure 6]

[0034] FIG. 1 illustrates a conceptual diagram of channel state information (CSI) feedback (CSF) compression between a UE and a network entity in a wireless communication system. [Figure 7]

[0035] 1 shows a conceptual diagram of the inner loop in UE vendor training for one encoder-decoder pair. [Figure 8]

[0036] FIG. 11 is a message diagram showing example messages for a data collection procedure for CSF compression. [Figure 9]

[0037] FIG. 2 is a conceptual diagram illustrating an exemplary frame structure for uploading data. [Figure 10]

[0038] FIG. 11 is a message diagram showing example messages for a data collection procedure for CSF compression. [Figure 11]

[0039] FIG. 11 is a message diagram illustrating an example message for reporting training data during a data collection procedure for CSF compression. [Figure 12]

[0040] FIG. 11 is a message diagram showing example messages for a data collection procedure for CSF compression. [Figure 13]

[0041] 13 shows an example message for requesting an existing data upload to a repository. [Figure 14]

[0042] 13 illustrates another exemplary message for requesting an existing data upload to a repository. [Figure 15]

[0043] 13 illustrates another exemplary message for requesting an existing data upload to a repository. [Figure 16]

[0044] A message diagram showing example messages for data collection procedures and offline model training for CSF compression using area-based training in a UE. [Figure 17]

[0045] A message diagram showing example messages for data collection procedures and offline model training for CSF compression using UE-based configuration in a UE. [Figure 18]

[0046] FIG. 2 is a conceptual diagram illustrating an exemplary frame structure for uploading data. [Figure 19]

[0047] A message diagram showing example messages for data collection procedures and offline model training for CSF compression using area-based training in a UE. [Figure 20]

[0048] A message diagram showing example messages for data collection procedures and offline model training for CSF compression using UE-based training in a UE. [Figure 21]

[0049] 21 is a message diagram 2100 illustrating an example message for reporting training data during a data collection procedure for CSF compression. [Figure 22]

[0050] FIG. 2 is a conceptual data flow diagram illustrating data flow between different means / components in an exemplary base station. [Diagram 23]

[0051] FIG. 2 is a conceptual data flow diagram illustrating data flow between different means / components in an exemplary UE. [Figure 24]

[0052] 1 is a flowchart of an example method for a UE vendor for cross-node machine learning training. [Diagram 25]

[0053] 1 is a flowchart of an example method for a UE vendor for cross-node machine learning training. [Figure 26]

[0054] 1 is a flowchart of an example method for a network entity vendor for cross-node machine learning training. [Figure 27]

[0055] 1 is a flowchart of an example method for a network entity vendor for cross-node machine learning training. [Figure 28]

[0056] 4 is a flowchart of an example method for a UE to perform a CSF data collection procedure. [Figure 29]

[0057] 1 is a flowchart of an example method for a network entity to perform a CSF data collection procedure. [Diagram 30]

[0058] 4 is a flowchart of an example method for a UE to perform a CSF data collection procedure. [Diagram 31]

[0059] 1 is a flowchart of an example method for a network entity to perform a CSF data collection procedure. [Diagram 32]

[0060] 1 is a flowchart of an example method for a UE vendor to perform data collection and offline model training for CSF compression. [Diagram 33]

[0061] 1 is a flowchart of an example method for a network entity vendor to perform data collection and offline model training for CSF compression.

[0027]

[0062]

[0004] Appendices are included which are part of this application and provide additional details regarding various aspects of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0028]

[0063] The detailed description set forth below with reference to the accompanying drawings describes various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The "detailed description" includes specific details intended to provide a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring such concepts. The following description may focus on 5G NR, but the concepts described herein may be applicable to other similar fields, such as LTE, LTE-A, CDMA, GSM, and other wireless technologies.

[0029]

[0064] In one aspect, the present disclosure provides techniques for training encoders and decoders associated with user equipments (UEs) and network entities, respectively.

[0030]

[0065] Certain aspects of a telecommunications system are now presented with respect to various apparatus and methods that are described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as "elements"). These elements may be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0031]

[0066] As an example, the elements, or any portion of the elements, or any combination of the elements, may be implemented as a "processing system" including one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, systems on a chip (SoC), baseband processors, field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gate logic, discrete hardware circuits, and other suitable hardware configured to perform various functions described throughout this disclosure. One or more processors in a processing system may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise.

[0032]

[0067] Thus, in one or more exemplary embodiments, the functions described may be implemented in hardware, software, or any combination thereof. If implemented in software, the functions may be stored or encoded as one or more instructions or code on a computer-readable medium. Computer-readable media includes computer storage media. A storage medium may be any available medium that can be accessed by a computer. By way of example and not limitation, such computer-readable media may comprise random-access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of the above types of computer-readable media, or any other medium that can be used to store computer-executable code in the form of instructions or data structures that can be accessed by a computer.

[0033]

[0068] 1 illustrates an example of a wireless communication system and access network 100. The wireless communication system (also referred to as a wireless wide area network (WWAN)) includes a network entity 102, also referred to as a base station 102 and / or which may include one or more disaggregated base station entities, a UE 104, an Evolved Packet Core (EPC) 160, and another core network (e.g., 5G Core (5GC) 190). The base station 102 may include a macro cell (high power cellular base station) and / or a small cell (low power cellular base station). The macro cell includes a base station. The small cell includes a femto cell, a pico cell, and a micro cell.

[0034]

[0069] One or more of the UEs 104 may include a UE training component 140 for communicating with at least the UE vendor 502 of FIG. 5 to perform data collection and model training. In an aspect, one or more of the base stations 102 may include a network training component 120 for communicating with at least a network entity vendor, such as the gNB vendor 504 of FIG. 5, to perform data collection and model training with the UEs 104. As used herein, the term vendor includes a device, server, repository, and / or any other device capable of collecting and storing data associated with training a model and transmitting / transmitting data associated with training a model for an encoder and / or decoder.

[0035]

[0070] A base station 102 configured for 4G LTE (collectively referred to as Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network, E-UTRAN) may interface with the EPC 160 through a backhaul link 132 (e.g., an S1 interface). The backhaul link 132 may be wired or wireless. A base station 102 configured for 5G NR (collectively referred to as Next Generation RAN, NG-RAN) may interface with the 5GC 190 through a backhaul link 184. The backhaul link 184 may be wired or wireless. In addition to other functions, the base stations 102 may perform one or more of the following functions: forwarding user data, encryption and decryption of radio channels, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection setup and release, load balancing, non-access stratum (NAS) message distribution, NAS node selection, synchronization, radio access network (RAN) sharing, multimedia broadcast multicast service (MBMS), subscriber and equipment tracking, RAN information management (RIM), paging, positioning, and alert message distribution. The base stations 102 may communicate with each other directly or indirectly (e.g., through the EPC 160 or 5GC 190) via backhaul links 134 (e.g., X2 interfaces). The backhaul links 134 may be wired or wireless.

[0036]

[0071] The base stations 102 may wirelessly communicate with the UEs 104. Each of the base stations 102 may provide communication coverage for a respective geographic coverage area 110. There may be overlapping geographic coverage areas 110. For example, a small cell 102' may have a coverage area 110' that overlaps with the coverage area 110 of one or more macro base stations 102. A network including both small cells and macro cells may be known as a heterogeneous network. A heterogeneous network may also include Home Evolved Node Bs (eNBs) (Home eNBs, HeNBs), which may provide service to restricted groups known as closed subscriber groups (CSGs). The communication link 112 between the base station 102 and the UE 104 may include uplink (UL) (also referred to as reverse link) transmissions from the UE 104 to the base station 102, and / or downlink (DL) (also referred to as forward link) transmissions from the base station 102 to the UE 104. The communication link 112 may use multiple-input and multiple-output (MIMO) antenna technologies, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link may be through one or more carriers. The base station 102 / UE 104 may use spectrum with a bandwidth of up to Y MHz (e.g., 5, 10, 15, 20, 100, 400 MHz, etc.) per carrier, allocated in a carrier aggregation of up to Yx MHz (x component carriers) in total, used for transmission in each direction. The carriers may be adjacent or non-adjacent to each other. The carrier allocation may be asymmetric for DL ​​and UL (e.g., more or fewer carriers may be allocated for DL ​​than for UL). The component carriers may include a primary component carrier and one or more secondary component carriers.The primary component carrier may be referred to as a primary cell (PCell), and the secondary component carrier may be referred to as a secondary cell (SCell).

[0037]

[0072] Particular UEs 104 may communicate with each other using device-to-device (D2D) communication links 158. The D2D communication links 158 may use DL / UL WWAN spectrum. The D2D communication links 158 may use one or more sidelink channels, such as a physical sidelink broadcast channel (PSBCH), a physical sidelink discovery channel (PSDCH), a physical sidelink shared channel (PSSCH), a physical sidelink control channel (PSCCH), and a physical sidelink feedback channel (PSFCH). The D2D communication may be through various wireless D2D communication systems, such as, for example, FlashLinQ, WiMedia, Bluetooth, ZigBee, Wi-Fi based on IEEE 802.11 standard, LTE, or NR.

[0038]

[0073] The wireless communication system may further include a Wi-Fi access point (AP) 150 in communication with Wi-Fi stations (STAs) 152 over communication links 154 in the 5 GHz unlicensed frequency spectrum. When communicating in the unlicensed frequency spectrum, the STAs 152 / AP 150 may perform a clear channel assessment (CCA) prior to communication to determine if a channel is available.

[0039]

[0074] The small cell 102' may operate in a licensed and / or unlicensed frequency spectrum. When operating in an unlicensed frequency spectrum, the small cell 102' may employ NR and use the same 5 GHz unlicensed frequency spectrum used by the Wi-Fi AP 150. By employing NR in the unlicensed frequency spectrum, the small cell 102' may provide increased coverage to and / or increase the capacity of the access network.

[0040]

[0075] The base station 102, whether a small cell 102' or a large cell (e.g., a macro base station), may include an eNB, a gNodeB (gNB), or other type of base station. Some base stations, such as the gNB 180, may operate within one or more frequency bands in the electromagnetic spectrum.

[0041]

[0076] The electromagnetic spectrum is often subdivided into various classes, bands, channels, etc. based on frequency / wavelength. In 5G NR, two initial operating bands have been identified as frequency range designations FR1 (410 MHz-7.125 GHz) and FR2 (24.25 GHz-52.6 GHz). Frequencies between FR1 and FR2 are often referred to as mid-band frequencies. Although a portion of FR1 is higher than 6 GHz, FR1 is often referred to (interchangeably) as the "sub-6 GHz" band in various documents and papers. Similar nomenclature issues may arise with respect to FR2, which is often referred to (interchangeably) as the "millimeter wave" (mmW) band in documents and papers, even though it is different from the extremely high frequency (EHF) band (30 GHz-300 GHz) identified by the International Telecommunications Union (ITU) as the "mmWave" band.

[0042]

[0077] With the above aspects in mind, it should be understood that unless specifically stated otherwise, terms such as "sub-6 GHz" as used herein may broadly refer to frequencies that may be below 6 GHz, may be in FR1, or may include mid-band frequencies. Additionally, it should be understood that unless specifically stated otherwise, terms such as "millimeter wave" as used herein may broadly refer to frequencies that may include mid-band frequencies, may be in FR2, or may be in the EHF band. Communications using mmW radio frequency bands have significant path loss and short distances. The mmW base station 180 may utilize beamforming 182 with the UE 104 to compensate for path loss and short distances.

[0043]

[0078] The base station 180 may transmit a beamformed signal to the UE 104 in one or more transmit directions 182′. The UE 104 may receive the beamformed signal from the base station 180 in one or more receive directions 182″. The UE 104 may also transmit a beamformed signal to the base station 180 in one or more transmit directions. The base station 180 may receive the beamformed signal from the UE 104 in one or more receive directions. The base station 180 / UE 104 may perform beam training to determine the best receive direction and transmit direction for each of the base station 180 / UE 104. The transmit and receive directions for the base station 180 may or may not be the same. The transmit and receive directions for the UE 104 may or may not be the same.

[0044]

[0079] The EPC 160 may include a Mobility Management Entity (MME) 162, other MMEs 164, a Serving Gateway 166, a Multimedia Broadcast Multicast Service (MBMS) Gateway 168, a Broadcast Multicast Service Center (BM-SC) 170, and a Packet Data Network (PDN) Gateway 172. The MME 162 may communicate with a Home Subscriber Server (HSS) 174. The MME 162 is a control node that handles signaling between the UE 104 and the EPC 160. In general, the MME 162 provides bearer and connection management. All user Internet protocol (IP) packets are forwarded through the Serving Gateway 166, which is itself connected to the PDN Gateway 172. The PDN Gateway 172 provides IP address allocation for the UE as well as other functions. The PDN Gateway 172 and the BM-SC 170 are connected to IP services 176, which may include the Internet, an intranet, an IP Multimedia Subsystem (IMS), PS streaming services, and / or other IP services. The BM-SC 170 may provide functionality for provisioning and delivery of MBMS user services. The BM-SC 170 may act as an entry point for content providers' MBMS transmissions and may be used to authorize and initiate MBMS bearer services in the public land mobile network (PLMN) and may be used to schedule MBMS transmissions.The MBMS Gateway 168 can be used to distribute MBMS traffic to base stations 102 belonging to a Multicast Broadcast Single Frequency Network (MBSFN) area broadcasting a particular service, and can be responsible for session management (start / stop) and collection of eMBMS related charging information.

[0045]

[0080] The 5GC 190 may include an Access and Mobility Management Function (AMF) 192, other AMFs 193, a Session Management Function (SMF) 194, and a User Plane Function (UPF) 195. The AMF 192 may communicate with a Unified Data Management (UDM) 196. The AMF 192 is a control node that handles signaling between the UE 104 and the 5GC 190. In general, the AMF 192 provides QoS flow and session management. All user Internet Protocol (IP) packets are forwarded through the UPF 195. The UPF 195 provides IP address allocation for the UE as well as other functions. The UPF 195 is connected to IP services 197. The IP services 197 may include the Internet, intranet, IP Multimedia Subsystem (IMS), PS streaming services, and / or other IP services.

[0046]

[0081] A base station may also be referred to as a gNB, Node B, evolved Node B (eNB), access point, base transceiver station, radio base station, radio transceiver, transceiver function, basic service set (BSS), enhanced service set (ESS), transmission / reception point (TRP), or some other suitable terminology. The base station 102 provides an access point to the EPC 160 or 5GC 190 for the UE 104. Examples of the UE 104 include a cellular phone, a smartphone, a session initiation protocol (SIP) phone, a laptop, a personal digital assistant (PDA), a satellite radio, a global positioning system, a multimedia device, a video device, a digital audio player (e.g., MP3 player), a camera, a game console, a tablet, a smart device, a wearable device, a vehicle, an electric meter, a gas pump, a large or small cooking appliance, a healthcare device, an implant, a sensor / actuator, a display, or any other similarly functional device. Some of the UEs 104 may be referred to as IoT devices (e.g., a parking meter, a gas pump, a toaster, a vehicle, a heart monitor, etc.) The UEs 104 may also be referred to as a station, a mobile station, a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communication device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other suitable terminology.

[0047]

[0082] 2A-2D are resource diagrams illustrating example frame structures and channels that may be used for uplink, downlink, and sidelink transmissions to a UE 104, including a CB mapping preference component 140. FIG. 2A is a diagram 200 illustrating an example of a first subframe in a 5G NR frame configuration. FIG. 2B is a diagram 230 illustrating an example of a DL channel in a 5G NR subframe. FIG. 2C is a diagram 250 illustrating an example of a second subframe in a 5G NR frame configuration. FIG. 2D is a diagram 280 illustrating an example of a UL channel in a 5G NR subframe. The 5G NR frame configuration may be FDD, where for a particular set of subcarriers (carrier system bandwidth), subframes within the set of subcarriers are dedicated to either DL or UL, or may be TDD, where for a particular set of subcarriers (carrier system bandwidth), subframes within the set of subcarriers are dedicated to both DL and UL. In the example provided by Figures 2A, 2C, the 5G NR frame structure is assumed to be TDD, subframe 4 is configured with slot format 28 (with mostly DL), where D is DL, U is UL, and X is flexible for use between DL / UL, and subframe 3 is configured with slot format 34 (with mostly UL). Subframes 3 and 4 are shown with slot formats 34 and 28, respectively, but any particular subframe can be configured with any of the various available slot formats 0-61. Slot formats 0 and 1 are all DL and UL, respectively. The other slot formats 2-61 include a mix of DL symbols, UL symbols, and flexible symbols. The UE is configured with the slot format through a received slot format indicator (SFI) (either dynamically through DL control information (DCI) or semi-statically / statically through radio resource control (RRC) signaling).Please note that the following description also applies to the 5G NR frame structure, which is TDD.

[0048]

[0083] Other wireless communication technologies may have different frame configurations and / or different channels. A frame (10 ms) may be divided into 10 subframes (1 ms) of equal size. Each subframe may include one or more time slots. A subframe may also include a minislot, which may include 7, 4, or 2 symbols. Each slot may include 7 or 14 symbols depending on the slot configuration. In slot configuration 0, each slot may include 14 symbols, and in slot configuration 1, each slot may include 7 symbols. Symbols on the DL may be cyclic prefix (CP) OFDM (CP-OFDM) symbols. The symbols on the UL can be CP-OFDM symbols (for high throughput scenarios) or discrete Fourier transform (DFT) spread OFDM (DFT-s-OFDM) symbols (also called single carrier frequency division multiple access (SC-FDMA) symbols) (for power limited scenarios, i.e., limited to single stream transmission). The number of slots in a subframe is based on the slot configuration and numerology. For slot configuration 0, the different numerologies μ0-5 allow 1, 2, 4, 8, 16, and 32 slots per subframe, respectively. For slot configuration 1, the different numerologies 0-2 allow 2, 4, and 8 slots per subframe, respectively. Thus, for slot configuration 0 and numerology μ, there are 14 symbols / slots and 2 μ There are slots / subframes. Subcarrier spacing and symbol length / duration are functions of numerology. Subcarrier spacing is 2 μ* may be equal to 15 kHz, where μ is a numerology 0-5. Therefore, numerology μ=0 has a subcarrier spacing of 15 kHz and numerology μ=5 has a subcarrier spacing of 480 kHz. The symbol length / period is inversely proportional to the subcarrier spacing. Figures 2A-2D provide an example of slot configuration 0 with 14 symbols per slot and numerology μ=0 with 1 slot per subframe. The subcarrier spacing is 15 kHz and the symbol period is approximately 66.7 μs.

[0049]

[0084] A resource grid may be used to represent the frame structure. Each time slot contains resource blocks (RBs) (also called physical RBs (PRBs)), which span 12 consecutive subcarriers. The resource grid is divided into multiple resource elements (REs). The number of bits carried by each RE depends on the modulation scheme.

[0050]

[0085] As shown in Figure 2A, some of the REs carry reference (pilot) signals (RS) for the UE. The RS may include demodulation RS (DM-RS) (shown as Rx for one particular configuration where 100x is the port number, but other DM-RS configurations are possible) and channel state information reference signal (CSI-RS) for channel estimation at the UE. The RS may also include beam measurement RS (BRS), beam refinement RS (BRRS), and phase tracking RS (PT-RS).

[0051]

[0086] FIG. 2B illustrates an example of various DL channels in a subframe of a frame. A physical downlink control channel (PDCCH) carries DCI in one or more control channel elements (CCEs), each CCE including 9 RE Groups (REGs), each REG including 4 consecutive REs in one OFDM symbol. A primary synchronization signal (PSS) may be present in symbol 2 of a particular subframe of a frame. The PSS is used by the UE 104 to determine the subframe / symbol timing and the physical layer identity. A secondary synchronization signal (SSS) may be present in symbol 4 of a particular subframe of a frame. The SSS is used by the UE to determine the group number of the physical layer cell identity and the timing of the radio frame. Based on the physical layer identity and the group number of the physical layer cell identity, the UE can determine a physical cell identifier (PCI). Based on the PCI, the UE can determine the location of the DM-RS mentioned above. The physical broadcast channel (PBCH), which carries the master information block (MIB), may be logically grouped with the PSS and SSS to form the synchronization signal (SS) / PBCH block. The MIB provides the number of RBs in the system bandwidth and the system frame number (SFN). The physical downlink shared channel (PDSCH) carries user data, broadcast system information not transmitted over the PBCH, such as system information blocks (SIBs), and paging messages.

[0052]

[0087] As shown in FIG. 2C, some of the REs carry DM-RS (depicted as R for one particular configuration, although other DM-RS configurations are possible) for channel estimation at the base station. The UE may transmit DM-RS for the physical uplink control channel (PUCCH) and DM-RS for the physical uplink shared channel (PUSCH). The PUSCH DM-RS may be transmitted within the first one or two symbols of the PUSCH. The PUCCH DM-RS may be transmitted in different configurations depending on whether a short or long PUCCH is transmitted and depending on the specific PUCCH format used. Although not shown, the UE may transmit a sounding reference signal (SRS). The SRS may be used by the base station for channel quality estimation to enable frequency-dependent scheduling on the UL.

[0053]

[0088] 2D shows an example of various UL channels within a subframe of a frame. The PUCCH may be arranged as shown in one configuration. The PUCCH carries uplink control information (UCI) such as scheduling requests, channel quality indicators (CQI), precoding matrix indicators (PMI), rank indicators (RI), and HARQ ACK / NACK feedback. The PUSCH carries data and may additionally be used to carry buffer status reports (BSR), power headroom reports (PHR), and / or UCI.

[0054]

[0089] 3 is a block diagram of a base station / network entity vendor 310 communicating with a UE / UE vendor 350 in an access network. In the DL, IP packets from the EPC 160 may be provided to a controller / processor 375. The controller / processor 375 implements layer 3 and layer 2 functions. Layer 3 includes a radio resource control (RRC) layer, and layer 2 includes a service data adaptation protocol (SDAP) layer, a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, and a medium access control (MAC) layer. The controller / processor 375 is responsible for RRC layer functions associated with broadcasting system information (e.g., MIBs, SIBs), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), mobility between radio access technologies (RATs), and measurement configuration for UE measurement reporting; PDCP layer functions associated with header compression / decompression, security (encryption, decryption, integrity protection, integrity verification), and handover support functions; RLC layer functions associated with forwarding higher layer packet data units (PDUs), error correction via ARQ, concatenation, segmentation, and reassembly of RLC service data units (SDUs), resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and mapping of logical channels to transport channels, multiplexing of MAC SDUs onto transport blocks (TBs), MAC SDUs from TBs, and MAC SDUs from TBs. It provides the MAC layer functions associated with demultiplexing of SDUs, scheduling information reporting, error correction via HARQ, priority handling, and logical channel prioritization.

[0055]

[0090] The transmit (Tx) processor 316 and receive (Rx) processor 370 implement Layer 1 functionality associated with various signal processing functions. Layer 1, including the physical (PHY) layer, may include error detection on the transport channel, forward error correction (FEC) encoding / decoding of the transport channel, interleaving, rate matching, mapping onto the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. The Tx processor 316 processes mapping to signal constellations based on various modulation schemes (e.g., binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying (M-PSK), M-quadrature amplitude modulation (M-QAM)). The coded and modulated symbols may then be split into parallel streams. Each stream can then be mapped to an OFDM subcarrier, multiplexed with a reference signal (e.g., pilot) in the time and / or frequency domain, and then combined together using an Inverse Fast Fourier Transform (IFFT) to generate a physical channel carrying a time-domain OFDM symbol stream. This OFDM stream is spatially precoded to generate multiple spatial streams. Channel estimates from a channel estimator 374 can be used to determine the coding and modulation schemes as well as for spatial processing. The channel estimates can be derived from a reference signal and / or channel condition feedback transmitted by the UE 350. Each spatial stream can then be provided to a different antenna 320 via a separate transmitter 318Tx. Each transmitter 318Tx can modulate an RF carrier with the respective spatial stream for transmission.

[0056]

[0091] At the UE 350, each receiver 354Rx receives a signal through its respective antenna 352. Each receiver 354Rx recovers information modulated onto an RF carrier and provides the information to a receive (Rx) processor 356. The Tx processor 368 and the Rx processor 356 implement Layer 1 functionality associated with various signal processing functions. The Rx processor 356 may perform spatial processing on the information to recover any spatial streams destined for the UE 350. If multiple spatial streams are destined for the UE 350, they may be combined by the Rx processor 356 into a single OFDM symbol stream. The Rx processor 356 then converts the OFDM symbol stream from the time domain to the frequency domain using a Fast Fourier Transform (FFT). The frequency domain signal includes a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, as well as the reference signal, are recovered and demodulated by determining the most likely signal constellation point transmitted by the base station 310. These soft decisions may be based on channel estimates calculated by a channel estimator 358. The soft decisions are then decoded and deinterleaved to recover the data and control signals originally transmitted by the base station 310 on the physical channel. The data and control signals are then provided to a controller / processor 359, which implements Layer 3 and Layer 2 functions.

[0057]

[0092] The controller / processor 359 may be associated with a memory 360 that stores program codes and data. The memory 360 may be referred to as a computer-readable medium. In the UL, the controller / processor 359 provides transport and logical channel demultiplexing, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets from the EPC 160 or 5GC 190. The controller / processor 359 is also responsible for error detection using an ACK and / or NACK protocol to support HARQ operations.

[0058]

[0093] Similar to the functionality described in connection with DL transmission by base station 310, the controller / processor 359 provides RRC layer functionality associated with system information (e.g., MIB, SIB) acquisition, RRC connection, and measurement reporting; PDCP layer functionality associated with header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functionality associated with forwarding of higher layer PDUs, error correction via ARQ, concatenation, segmentation, and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping of logical channels to transport channels, multiplexing of MAC SDUs onto TBs, demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via HARQ, priority handling, and logical channel prioritization.

[0059]

[0094] Channel estimates derived by the channel estimator 358 from a reference signal or feedback transmitted by the base station 310 may be used by the Tx processor 368 to select an appropriate coding and modulation scheme as well as to facilitate spatial processing. The spatial streams generated by the Tx processor 368 may be provided to different antennas 352 via separate transmitters 354Tx. Each transmitter 354Tx may modulate an RF carrier with a respective spatial stream for transmission.

[0060]

[0095] The UL transmissions are processed at the base station 310 in a manner similar to that described with respect to the receiver functions at the UE 350. Each receiver 318Rx receives a signal through its corresponding antenna 320. Each receiver 318Rx recovers the information modulated onto the RF carrier and provides the information to the Rx processor 370.

[0061]

[0096] The controller / processor 375 may be associated with a memory 376 that stores program codes and data. The memory 376 may be referred to as a computer-readable medium. In the UL, the controller / processor 375 provides transport and logical channel demultiplexing, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets from the UE 350. The IP packets from the controller / processor 375 may be provided to the EPC 160. The controller / processor 375 is also responsible for error detection using an ACK and / or NACK protocol to support HARQ operations.

[0062]

[0097] At least one of the TX processor 368, the RX processor 356, and the controller / processor 359 may be configured to perform aspects associated with the UE training component 140 of FIG.

[0063]

[0098] At least one of the TX processor 316, the RX processor 370, and the controller / processor 375 may be configured to implement aspects associated with the network training component 120 of FIG.

[0064]

[0099] 4 illustrates a diagram showing an example disaggregated base station 102 architecture, which may be one form of a network entity 102 or base station 400 described herein. The disaggregated base station 400 architecture may include one or more central units (CUs) 410 that may communicate directly with a core network 420 over a backhaul link or indirectly with the core network 420 through one or more disaggregated base station units (e.g., a near real-time (near-RT) RAN Intelligent Controller (RIC) 425 over an E2 link, or a non-real-time (non-RT) RIC 415 associated with a Service Management and Orchestration (SMO) framework 405, or both). The CUs 410 may communicate with one or more distributed units (DUs) 430 over respective midhaul links, such as an F1 interface. The DUs 430 may communicate with one or more radio units (RUs) 440 over respective fronthaul links. The RUs 440 may communicate with each UE 104 over one or more radio frequency (RF) access links. In some implementations, a UE 104 may be served by multiple RUs 440 simultaneously.

[0065]

[0100] Each of the units, i.e., CU 410, DU 430, RU 440, quasi-RT RIC 425, non-RT RIC 415, and SMO framework 405, may include or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) over a wired or wireless transmission medium. Each of the units, or an associated processor or controller that provides instructions to the unit's communication interface, may be configured to communicate with one or more of the other units over a transmission medium. For example, the units may include a wired interface configured to receive or transmit signals to one or more of the other units over a wired transmission medium. Furthermore, the units may include a wireless interface, which may include a receiver, transmitter, or transceiver (such as a radio frequency (RF) transceiver) configured to receive or transmit or transmit signals over a wireless transmission medium to one or more of the other units.

[0066]

[0101] In some aspects, the CU 410 may host one or more upper layer control functions. Such control functions may include Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Service Data Adaptation Protocol (SDAP), etc. Each control function may be implemented with an interface configured to communicate signals with other control functions hosted by the CU 410. The CU 410 may be configured to handle user plane functions (i.e., Central Unit-User Plane (CU-UP)), control plane functions (i.e., Central Unit-Control Plane (CU-Control Plane (CU-CP)), or a combination thereof. In some implementations, the CU 410 may be logically divided into one or more CU-UP units and one or more CU-CP units. The CU-UP unit, when implemented in an O-RAN configuration, may communicate bidirectionally with the CU-CP unit via an interface, such as an E1 interface. The CU 410 may be implemented to communicate with the DU 430, as necessary, for network control and signaling.

[0067]

[0102] The DU 430 may correspond to a logical unit including one or more base station functions for controlling the operation of one or more RUs 440. In some aspects, the DU 430 may host one or more of a Radio Link Control (RLC) layer, a Medium Access Control (MAC) layer, and one or more upper physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.), at least in part according to a functional division such as that defined by the 3rd Generation Partnership Project (3GPP). In some aspects, the DU 430 may further host one or more lower PHY layers. Each layer (or module) may be implemented with an interface configured to communicate signals with other layers (and modules) hosted by the DU 430 or with a control function hosted by the CU 410.

[0068]

[0103] The lower layer functions may be implemented by one or more RUs 440. In some deployments, the RUs 440 controlled by the DU 430 may correspond to logical nodes hosting RF processing functions, or low PHY layer functions (such as performing fast Fourier transform (FFT), inverse FFT (iFFT), digital beamforming, physical random access channel (PRACH) extraction and filtering, etc.), or both, based at least in part on a functional division, such as a lower layer functional division. In such an architecture, the RUs 440 may be implemented to handle over the air (OTA) communications with one or more UEs 104. In some implementations, real-time and non-real-time aspects of control and user plane communications with the RUs 440 may be controlled by a corresponding DU 430. In some scenarios, this configuration may enable the DUs 430 and CUs 410 to be implemented in a cloud-based RAN architecture, such as a vRAN architecture.

[0069]

[0104] The SMO framework 405 may be configured to support RAN deployment and provisioning of non-virtualized and virtualized network elements. For non-virtualized network elements, the SMO framework 405 may be configured to support deployment of dedicated physical resources for RAN coverage requirements that can be managed via an operation and maintenance interface (such as an O1 interface). For virtualized network elements, the SMO framework 405 may be configured to interact with a cloud computing platform (such as an open cloud (O-cloud) 490) to perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface (such as an O2 interface). Such virtualized network elements may include, but are not limited to, the CU 410, the DU 430, the RU 440, and the quasi-RT RIC 425. In some implementations, the SMO framework 405 may communicate with hardware aspects of a 4G RAN, such as an open eNB (O-eNB) 411, via an O1 interface. Additionally, in some implementations, the SMO framework 405 can communicate directly with one or more RUs 440 via an O1 interface. The SMO framework 405 can also include a non-RT RIC 415 configured to support the functionality of the SMO framework 405.

[0070]

[0105] The non-RT RIC 415 may be configured to include logic functions that enable non-real-time control and optimization of RAN elements and resources, Artificial Intelligence / Machine Learning (AI / ML) workflows including model training and updates, or policy-based guidance of applications / features in the quasi-RT RIC 425. The non-RT RIC 415 may be coupled to or in communication with the quasi-RT RIC 425 (e.g., via an A1 interface). The quasi-RT RIC 425 may be configured to include logic functions that enable near real-time control and optimization of RAN elements and resources via one or more CUs 410, one or more DUs 430, or both, and data collection and action via an interface connecting the O-eNB to the quasi-RT RIC 425 (e.g., via an E2 interface).

[0071]

[0106] In some implementations, the non-RT RIC 415 may receive parameters or external enrichment information from an external server to generate the AI / ML models deployed to the quasi-RT RIC 425. Such information may be utilized by the quasi-RT RIC 425 or may be received at the SMO framework 405 or non-RT RIC 415 from non-network data sources or from network functions. In some examples, the non-RT RIC 415 or quasi-RT RIC 425 may be configured to adjust RAN behavior or performance. For example, the non-RT RIC 415 may employ the AI / ML models to monitor long-term trends and patterns regarding performance and implement corrective actions through the SMO framework 405 (e.g., reconfiguration via O1) or through the creation of RAN management policies (e.g., A1 policies).

[0072]

[0107] FIG. 5 illustrates an example of a communication system including a UE vendor and a gNB vendor. For example, a UE vendor 502 serves multiple UEs, such as the UE 104 of FIG. 1, and may correspond to the UE vendor 316 of FIG. 3. The UE vendor 502 may be configured for data collection from multiple UEs 104 with which it is in direct communication. The multiple UEs 104 may be linked to the UE vendor 502 wirelessly or via a wired connection. The UE vendor 502 may be directly and / or indirectly linked 506 to a gNB vendor 504. The gNB vendor 504 may be directly and / or indirectly linked to multiple gNBs, such as the base stations 102 of FIG. 1, and may correspond to the network entity vendor 310 of FIG. 3. The UE vendor 502 and the gNB vendor 504 may perform data collection and online / offline training for channel state information (CSI) feedback (CSF) compression for communication between the UE 104 and the gNB 102.

[0073]

[0108] In one aspect, a UE vendor 502 may initiate UE-based training for multiple UEs 104 with which it is associated. For example, the UE vendor 502 may request the UE 104 to collect data for model training. In some instances, the request may occur via a UE application running on the UE 104. In response to receiving the request, the UE 104 may send a request via communication link 112 to a gNB, such as the base station 102 of FIG. 1, and a model manager for the gNB 102 may configure the UE 104 for training data collection. The model manager of the gNB 102 may correspond to the gNB vendor 504.

[0074]

[0109] In one aspect, the UE vendor 502 may initiate model training and coordinate with the gNB vendor 504. In another aspect, the UE vendor 502 can perform area-based training by directly sending a request to the gNB vendor 504 to initiate model training. The gNB vendor 502 can request the gNB 102 to configure the model training and select appropriate UEs 104 for training data collection based on UE type, UE capabilities, and user consent.

[0075]

[0110] 6 shows a conceptual diagram 600 of CSF compression between a UE and a network entity in a wireless communication system. For example, the UE 104 may correspond to the UE 104 of FIG. 1, and the gNB 102 may correspond to the base station 102 of FIG.

[0076]

[0111] For example, in cross-node machine learning (ML), a neural network (NN) is split into two parts: an encoder 602 on a UE, such as the UE 104, and a decoder 604 on a gNB, such as the base station 102. The encoder output from the UE 104 is sent to the gNB 102 as an input to the decoder 604. In one example, the encoder 602 at the UE 104 outputs a compressed CSF 606 that is input to the decoder 604 at the gNB 102. The decoder 604 at the gNB 102 outputs a reconstructed CSF 608, such as a precoding vector. To train the encoder 602 and the decoder 604, a UE vendor, such as the UE vendor 502 of FIG. 5, can train both models using its own dataset and share the trained decoder model with a gNB vendor, such as the gNB vendor 504.

[0077]

[0112] In one aspect, the decoder shared with the infrastructure vendor may reveal or imply details of the UE modem's implementation due to the symmetry that typically exists between the encoder and the decoder. For example, if the encoder employs a convolutional layer, the decoder correspondingly employs a transposed convolutional layer. To overcome this problem, the UE vendor 502 may share with the gNB vendor 504 a training set that includes expected (input, output) tuples for its trained decoder. Then, from the perspective of the gNB vendor 504, the learning of the decoder 604 becomes supervised learning using the training set created by the UE vendor 502. Supervised learning may correspond to knowledge distillation, where the decoder model trained by the UE vendor 502 becomes the teacher and the decoder model adopted by the gNB vendor 504 becomes the student. Thus, the decoder model trained by the UE vendor 502 is not revealed to the gNB vendor 504. Therefore, the architecture of the decoder model adopted by the gNB vendor 504 is not the same as the architecture of the decoder model trained by the UE vendor 502.

[0078]

[0113] In one aspect, the decoder 604 output includes a downlink channel matrix (H), a transmit covariance matrix, a downlink precoder (V), an interference covariance matrix (R nn ), and live vs. whitened downlink channels.

[0079]

[0114] FIG. 7 shows a conceptual diagram 700 of the inner loop in UE vendor training for one encoder-decoder pair.

[0080]

[0115] In one aspect, an access network, such as the access network 100 of FIG. 1, may include one or more heterogeneous UEs (different baseband and RF implementations, different antennas, different OEMs), such as the UE 104, and heterogeneous channel statistics across cells. In this aspect, one encoder-decoder may not achieve a performance level above a certain acceptable threshold across all scenarios. In these cases, the UE 104 participating in data collection tags the collected data with metadata describing the scenario for the data collection originating from both the gNB 102 and the UE 104. For example, the metadata from the gNB 102 may include gNB antenna configuration, CSI-RS beam configuration, etc. Additionally, the gNB 102 metadata may be provided to the UE 104 in terms of a "gNB Meta ID," but without revealing the gNB implementation. The metadata from the UE 104 may include UE antenna configuration, SNR, RSRP, delay spread, average delay, timestamp, etc. The UE 104 may resolve the UE metadata into a “UE Meta ID” that the UE vendor does not want to disclose to the gNB vendor 504, and the remainder of the UE metadata.

[0081]

[0116] In one aspect, at the UE server / UE vendor 502, N data sets are collected from a plurality of UEs 104 participating in data collection. For example, the UE server / UE vendor 502 may combine the N data sets into L (<N) data sets according to the associated metadata. The L data sets are further grouped into M (M << L) subsets based on UE type and channel statistics. As further described herein, the UE vendor 502 may train M encoder-decoder pairs and execute the inner loop procedure M times to obtain M training sets from the M trained encoder-decoder pairs to be shared with the gNB vendor 504. In some cases, each of the M trained encoder-decoders is associated with one or more metadata. The association between the M encoder-coder pairs and the metadata enables the gNB 102 to switch between models during inference.

[0082]

[0117] In one aspect, H raw represents the channel observed from the CSIRS channel, and H corresponds to the processed form of H raw , for example, the whitened channel. For example, H = f(H raw , R nn ), where R nn corresponds to the observed noise covariance matrix. In this implementation, the UE 104 may desire to hide from the infrastructure. Further, V may correspond to the ground truth of something that the decoder aims to reconstruct, such as a precoding vector. q φ corresponds to an encoder such as the encoder 602 in FIG. 6, z corresponds to a latent vector, for example, the compressed CSI, and z = q φ (H) is calculated based on. p θ corresponds to a decoder such as the decoder 604 in FIG. 6,

[0083]

Number

[0084] corresponds to the reconstruction of V by the decoder 604.

[0085]

[0118] In one aspect, a procedure for UE vendor driven offline training of cross-node ML may include the following steps: In a first step, the UE vendor 502 trains an encoder-decoder pair (q φ ,p θ In a second step, once the encoder-decoder pair is trained, the UE vendor 502 generates a training set {(encoder ID, z, V)} by running the encoder 602 using the UE vendor's 502 raw dataset. For example, z corresponds to the output of the encoder 602, e.g., a latent vector, and V corresponds to the output of the desired decoder 604, e.g., a precoding vector. In a third step, the UE vendor 502 provides the training set {(encoder ID, z, V)} to the gNB vendor 604.

[0086]

[0119] In one aspect, another procedure for UE vendor-driven offline training of cross-node ML may include the following steps: In a first step, on the server of the UE vendor 502, the UE vendor 502 uses the raw data set of the UE vendor 502 to generate an encoder-decoder pair (q φ ,p θ In the second step, after the encoder-decoder pair is trained, the UE vendor 502 trains two training sets: the first training set {(encoder ID, z,

[0087]

number

[0088] }}, and a second training set {(encoder ID, z+ε, p θ (z+ε)}, where z corresponds to the encoder 602 output and V corresponds to the desired decoder 604 output,

[0089]

number

[0090] corresponds to the reconstruction of V by the decoder 604. In a third step, the UE vendor 502 provides two training sets to the gNB vendor 504.

[0091]

[0120] In one aspect, another procedure for UE vendor-driven offline training of cross-node ML may include the following steps: In a first step, on the server of the UE vendor 502, the UE vendor 502 uses the raw data set of the UE vendor 502 to generate an encoder-decoder pair (q φ ,p θ ) in response to the two training sets based on the following: In a second step, after the encoder-decoder pair is trained, the UE vendor 502 generates two training sets, a first training set {(encoder ID, z)} by running the encoder 602 with the UE vendor's 502 raw data set, and a second training set {(encoder ID, z+ε)} by perturbing the encoder 602 output z in the first training set by a small vector ε, where z corresponds to the encoder 602 output. In a third step, the UE vendor 502 generates p in response to the two training sets based on the following: θ Find a decoder p such that f produces the same or similar output as θ Find an alternative decoder f that approximates p θ (z+ε)=f(z+ε) and p θ (z)=f(z)

[0092]

[0121] For example, the UE vendor 502 may determine one alternative decoder 504 for each encoder ID. In a fourth step, the UE vendor 502 provides the gNB vendor 504 with two training sets and the alternative decoders (encoder IDs, f).

[0093]

[0122] In one aspect, the gNB vendor 504 may train one or more decoders 604 based on the M sets of training sets. For example, the gNB vendor 504 may train at least one of one decoder for all M groups, one decoder per group (i.e., M decoders), or one decoder per some groups (i.e., less than M decoders). The decoders 604 may be gNB 102 specific or may be shared across multiple gNBs 102. Additionally, the gNB vendor 504 may determine associations between specific gNBs 102 or associations shared across multiple gNBs 102 based on at least one of the training sets {(encoder ID, z, V)}. For example, the gNB vendor 504 may train at least one of one decoder for all M groups, one decoder per group (i.e., M decoders), or one decoder per some groups (i.e., less than M decoders). The decoders 604 may be gNB 102 specific or may be shared across multiple gNBs 102 based on at least one of the training sets {(encoder ID, z, V)}.

[0094]

number

[0095] )},{(encoder ID, z+ε, p θ We use the training set {(encoder ID, z)}{(encoder ID, z+ε)}} and two training sets ({(encoder ID, z)}{(encoder ID, z+ε)}}) and an alternative decoder {(encoder ID, f}).

[0096]

[0123] 8 is a message diagram 800 illustrating example messages for a data collection procedure for CSF compression. For example, diagram 800 illustrates messaging between a UE vendor, such as UE vendor 502 of FIG. 5, a UE, such as UE 104 of FIG. 1, and a gNB, such as base station 102 of FIG. 1.

[0097]

[0124] In one aspect, in step 802, the UE vendor 502 may send a training data request to the UE 104. In response to receiving the training data request, the UE 104 may forward the training data request to the gNB 102 in step 804. In step 806, the gNB 102 may send a data collection configuration to the UE 104 in response to receiving the training data request. For example, the information on the data collection configuration message may include at least one of a reference signal (RS) such as a CSI-RS, a list for data collection, an area for data collection, a periodicity for data collection, a network side configuration, a channel type, and a process ID for data collection. In some cases, the configured RS may be dynamically activated / deactivated by the gNB 102 via a medium access control (MAC) control element (CE) or downlink control information (DCI), etc. In some cases, the process ID may be a model ID already registered in the MLF, or the process ID may be used to generate a meta ID used in data upload. In some cases, the process ID is a meta ID provided by a network entity for data collection. The meta ID may correspond to CSI-RS beam configuration or antenna configuration including antenna layout, antenna element to TxRU mapping, digital / analog beamforming. In some cases, the data collection configuration signaling may correspond to reusing MDT configuration signaling or as information elements (IEs) to the RRCReconfiguration message.

[0098]

[0125] At step 808, the UE 104 may send a data collection configuration acknowledgment (ACK) to the gNB 102 to indicate successful receipt of the data collection configuration. The UE 104 may then perform data collection with the gNB 102 at step 810. Upon completion of the data collection, the UE 104 may upload the collected data to the UE vendor 502 at step 812.

[0099]

[0126] 9 is a conceptual diagram 900 illustrating an example frame structure for uploading data. For example, the UE 104 may send a report of data to the UE vendor 502 in response to performing data collection between the UE 104 and the gNB 102, as shown at several instances 902, 904, 906, and 908.

[0100]

[0127] In one aspect, the UE report may include {H_raw,meta_id}, where H_raw is the channel estimate for RB index, port index, and Rx index, and Meta_id has the following hierarchy and includes a data package ID (which may be generated using data process ID), cell / carrier ID, CSI-RS resource ID (implicitly carries antenna mapping / layout), a list of records {record #1, record #2, etc.}, and (if possible) GNSS. For example, each record includes a timestamp, e.g., CSI-RS transmission instance or slot index, or measurement period index (e.g., the record is based on measurements over a period of time, and the period should be configured), and the gNB 102 may dynamically change the antenna mapping / layout, and the timestamp is needed to label the reported data with the correct antenna mapping / layout. Additionally, each record includes SNR, SINR or RSRP, subcarrier spacing, and Doppler / delay spread measurements.

[0101]

[0128] In one aspect, the format of H_raw and other additional data may include a frequency domain resolution corresponding to a subcarrier, RB, or subband, and / or the eigendirection of H_raw is also reported as {H_raw, V_raw, meta_id}, where the V_raw frequency granularity is less than or equal to the H_raw frequency granularity.

[0102]

[0129] Figure 10 is a message diagram 1000 illustrating example messages for a data collection procedure for CSF compression. For example, diagram 1000 illustrates messaging between a UE vendor, such as UE vendor 502 of Figure 5, a UE, such as UE 104 of Figure 1, a gNB, such as base station 102 of Figure 1, and a data repository / collection entity, such as gNB vendor 504 of Figure 5.

[0103]

[0130] In one aspect, in step 1002, the model / data repository 502 may send a training data request to the gNB 102. In step 1004, the gNB 1002 may send a data collection configuration to the UE 104. For example, the information on the data collection configuration message may include at least one of a reference signal (RS) such as CSI-RS, a list for data collection, an area for data collection, a periodicity for data collection, a network side configuration, a channel type, and a process ID for data collection. In some cases, the configured RS may be dynamically activated / deactivated by the gNB 102 via a medium access control (MAC) control element (CE) or downlink control information (DCI), etc. In some cases, the process ID may be a model ID already registered in the MLF, or the process ID may be used to generate a meta ID used in data upload. In some cases, the signaling of the data collection configuration may correspond to reusing MDT configuration signaling or as information elements (IEs) to an RRC Reconfiguration message.

[0104]

[0131] In step 1006, the UE 104 may send a data collection configuration ACK to the gNB 102 in response to receiving the data collection configuration. In some instances, the UE 104 may reject the data collection request and instead send a model training configuration reject message to the gNB 102. The UE 104 may then perform data collection with the gNB 102 in step 1008. In step 1010, training data may be reported between the UE vendor 502, the UE 104, the gNB 102, and the model / data repository 504.

[0105]

[0132] Figure 11 is a message diagram 1100 illustrating example messages for reporting training data during a data collection procedure for CSF compression. For example, diagram 1100 illustrates certain messaging that occurs during step 1010 of Figure 10 between a UE vendor, such as UE vendor 502 of Figure 5, a UE, such as UE 104 of Figure 1, a gNB, such as base station 102 of Figure 1, and a data repository / collection entity, such as gNB vendor 504 of Figure 5.

[0106]

[0133] In one aspect, reporting of training data may be performed based on MDT extensions. For example, in step 1102, the UE 104 may send a data report to the gNB 104. In step 1104, the gNB 104 may forward the data report to the data repository / collection entity 504. In some cases, a new IE may be added to the MDT report signaling, which may be file-based or streaming-based.

[0107]

[0134] In one aspect, the reporting of training data may be performed vendor-UE-vendor. For example, in step 1106, the UE 104 may send a data report to the UE vendor 502. Further, in step 1108, the UE 104 may send a data address report to the gNB 102. In step 1110, the gNB 102 may forward the data address report to the data repository / collection entity 504. In some cases, the UE 104 may send the data to a UE server corresponding to the UE vendor 502 due to limited memory in the UE 104, and the UE 104 may then provide an address for the gNB vendor 504 to download the data. Alternatively, the UE 104 may report the data directly to the data repository / collection entity 504.

[0108]

[0135] In one aspect, training data reporting may be performed vendor-to-vendor. For example, in step 1112, the UE 104 may send a data report to the UE vendor 502. In step 1114, the UE vendor 502 may upload data received from the data report to the data repository / collection entity 504. In some instances, the UE vendor 502 may report directly to the gNB vendor 504 using a proprietary protocol.

[0109]

[0136] 12 is a message diagram 1200 illustrating example messages for a data collection procedure for CSF compression. For example, diagram 1200 illustrates messaging between a UE vendor, such as UE vendor 502 of FIG. 5, a UE, such as UE 104 of FIG. 1, a gNB, such as base station 102 of FIG. 1, and a data repository / collection entity, such as gNB vendor 504 of FIG. 5.

[0110]

[0137] In one aspect, in step 1202, the data report to the data repository / collection entity 504 may send a training data request to the UE vendor 502. In step 1204, the UE vendor 502 may forward the training data request to the UE 104. After receiving the request from the UE vendor 502, the UE 104 forwards the request to the gNB 102 to request a data collection RS. In step 1206, the gNB 102 may send a data collection configuration to the UE 104. For example, the information on the data collection configuration message may include at least one of an RS such as a CSI-RS, a list for data collection, an area for data collection, a periodicity for data collection, a network side configuration, a channel type, and a process ID for data collection. In some cases, the configured RS may be dynamically activated / deactivated by the gNB 102 via a MAC CE or DCI, etc. In some cases, the process ID may be a model ID already registered in the MLF, or the process ID may be used to generate a meta ID used in data upload. In some cases, the process ID is a meta ID used in data collection. The meta ID may correspond to the CSI-RS beam configuration or antenna configuration including antenna layout, antenna element to TxRU mapping, digital / analog beamforming. In some cases, the data collection configuration signaling may correspond to reusing MDT configuration signaling or as an IE to the RRCReconfiguration message.

[0111]

[0138] At step 1208, the UE 104 may send a data collection configuration ACK to the gNB 102 in response to receiving the data collection configuration. The UE 104 may then perform data collection with the gNB 102 at step 1210. At step 1212, the data may be uploaded to the UE vendor 502. At step 1214, the UE vendor 502 may upload the data to the data repository collection entity 504.

[0112]

[0139] 13-15 show example messages for requesting an existing data upload to a repository. For example, FIG. 1300, FIG. 1400, and FIG. 1500 show messaging between a UE vendor, such as UE vendor 502 of FIG. 5, a UE, such as UE 104 of FIG. 1, a gNB, such as base station 102 of FIG. 1, and a data repository / collection entity, such as gNB vendor 504 of FIG. 5.

[0113]

[0140] In one aspect, message diagram 1300 illustrates a sideline where a repository, such as data repository / collection entity 504, may communicate directly with a UE server of a UE vendor 502 via a proprietary protocol. For example, at step 1302, data repository / collection entity 504 may send a training data request to UE vendor 502. At step 1304, UE vendor 502 may send a data upload to data repository / collection entity 504 in response to the training data request.

[0114]

[0141] In one aspect, message diagram 1400 illustrates a case where there is no sideline between the data repository / collection entity 504 and the UE vendor 502. For example, at step 1402, the data repository / collection entity 504 may send a training data request to the gNB 102. At step 1404, the gNB 102 may forward the training data request 1404 to the UE 104. At step 1406, the UE 104 may communicate a data report to the data repository / collection entity 504. In some cases, the UE 104 may communicate the data report to the gNB 102, which forwards the data to the data repository / collection entity 504.

[0115]

[0142] In one aspect, message diagram 1500 illustrates another case where there is no sideline between data repository / collection entity 504 and UE vendor 502. For example, in step 1502, data repository / collection entity 504 may send a training data request to gNB 102. In step 1504, gNB 102 may forward training data request 1504 to UE 104. In step 1506, UE 104 may send a training data query to UE vendor 502. In step 1508, UE vendor 502 may send data or a data address to UE 104. In step 1510, UE 104 may send data and a data address report to gNB 102. In step 1512, gNB 102 may send data and a data address report to data repository / collection entity 504.

[0116]

[0143] 16 is a message diagram 1600 illustrating example messages for a data collection procedure and offline model training for CSF compression using area-based training at a UE. For example, diagram 1700 illustrates messaging between a UE vendor, such as UE vendor 502 of FIG. 5, a UE, such as UE 104 of FIG. 1, a gNB, such as base station 102 of FIG. 1, model manager / OAM 1602, and model / data repository 504, both of which are associated with and / or part of gNB vendor 504 of FIG. 5.

[0117]

[0144] In one aspect, in step 1604, an MLF for CSF compression is defined and registered across the UE vendor 502, the UE 104, the gNB 102, the model manager / OAM 1602, and the model / data repository 504. For example, the UE vendor 502 registers its CSF model with a network, such as the gNB 102 and / or the gNB vendor 504. In some cases, the registration includes a model ID or Model Structure (MS) ID, a list of Parameter Set (PS) IDs, applicable scenarios for each PS including area, configuration, and UE type, and applicable scenarios for each model in case multiple models are registered. For example, the model training is initiated by the UE vendor 502. In some cases, the model training is coordinated by the model manager / OAM 1602, which may correspond to an OAM, an ORAN-defined network entity (RIC, Intelligent Network Controller), a CU-XP, or a gNB, such as the gNB 102, depending on the deployment scenario and use case.

[0118]

[0145] In the case of area-based training, the UE vendor 502 sends a request directly to a network side server, e.g., a Model / Data Repository (MR) 504 corresponding to the gNB vendor 504. For example, the MR 504 requests the Model Manager 1602 to start model training. The Model Manager 1602 requests the gNB 102 to configure model training. The gNB 102 then selects a suitable UE 104 for training data collection based on UE type, UE capabilities, and user consent. For example, in step 1606, the UE vendor 502 may send a training data request to the Model / Data Repository 504 as part of a training initiation procedure. In the model training configuration, a network, such as the gNB 102, sends metadata for model training and information about data collection. For example, the information regarding data collection may include a RS (e.g., CSI-RS) list for data collection, and the configured RS may be dynamically activated / deactivated by the gNB, e.g., via MAC CE or DCI, areas for data collection, and time periods for data collection. In some cases, the metadata may include NM IDs (associated with network side mode IDs) where data of different NM IDs may be used separately for model training, network side configurations, and additional information such as channel types. In some cases, the signaling may include a new signaling procedure or reuse of MDT configuration signaling where configuration information is added as an IE to the RRCReconfiguration message.

[0119]

[0146] At step 1608, the model / data repository 504 may send a model training start message to the model manager / OAM 1602. At step 1610, the model / data repository 504 may send a training data request ACK to the UE vendor 502 in response to receiving the training data request at step 1606. At step 1612, the model manager / OAMA 1602 sends a model training request 1612 to the gNB 102. At step 1614, the gNB 102 may perform UE selection and at step 1616 send a model training configuration to the UE 104. At step 1618, the UE 104 may send a model training configuration ACK to the gNB 102. At step 1620, the gNB 102 sends a model training response to the model manager / OAM 1602.

[0120]

[0147] For example, the UE 104 collects data based on the received configuration. The collected data is uploaded to the UE vendor 502 server along with additional information including timestamps described in terms of either absolute time, relative time, or SFN+timeslot+(optionally)symbol, location information such as GNSS and radio fingerprints, i.e., RSRP / RSRQ measurements of serving and neighboring cells, if available, and metadata such as RS type, ID, and NM_ID. In some cases, the model training may be based on previously collected data without metadata. The received configuration information may be used as metadata and reported to the UE vendor 502 server. In this case, the actual data collection and reporting may be skipped. In step 1622, the UE 104 performs data collection. In step 1624, the UE 104 reports the training data to the UE vendor 502 once it has performed data collection. In step 1626, the UE vendor 502 performs model training upon receiving the training data report.

[0121]

[0148] For example, the model training report may be uploaded directly to the model / data repository 504, or the data may be distilled for the gNB 102 to derive the base station model. If the data is distilled, the UE vendor 502 generates some distilled data {Z, CSI} for the trained base station model, and the gNB vendor 504 can derive the model based on the data. Once the model training is complete, the UE vendor 502 may send the model training report to the model / data repository 504 in step 1628. Upon receiving the model training report, the model / data repository 504 performs a model update in step 1630.

[0122]

[0149] 17 is a message diagram 1700 illustrating example messages for a data collection procedure and offline model training for CSF compression using UE-based configuration in a UE. For example, diagram 1700 illustrates messaging between a UE vendor, such as UE vendor 502 of FIG. 5, a UE, such as UE 104 of FIG. 1, a gNB, such as base station 102 of FIG. 1, model manager / OAM 1602, and model / data repository 504, both of which are associated with and / or part of gNB vendor 504 of FIG. 5.

[0123]

[0150] In one aspect, in step 1702, an MLF for CSF compression is defined and registered across the UE vendor 502, the UE 104, the gNB 102, the model manager / OAM 1602, and the model / data repository 504. For example, the UE vendor 502 registers its CSF model with a network, such as the gNB 102 and / or the gNB vendor 504. In some cases, the registration includes a model ID or model structure (MS) ID, a list of parameter set (PS) IDs, applicable scenarios for each PS including area, configuration, and UE type, and applicable scenarios for each model in case multiple models are registered. For example, the model training is initiated by the UE vendor 502. In some cases, the model training is coordinated by the model manager / OAM 1602, which may correspond to an OAM, a RIC (ORAN defined network entity, intelligent network controller), a CU-XP, or a gNB, such as the gNB 102, depending on the deployment scenario and use case.

[0124]

[0151] In the case of UE 104-based training, the UE vendor 502, such as via a UE app, requests the UE 104 to collect data for model training. The UE 104 sends a request to the gNB 102 and the model manager 1602 for the gNB 102 to configure the UE 104 for training data collection. For example, in step 1704, the UE vendor 504 may send a training data request to the UE 104. In step 1706, the UE 104 may send a model training request message to the gNB 102. In step 1708, the gNB 102 may forward the model training request message to the model manager / OAM 1602. In the model training configuration, a network such as the gNB 102 sends metadata and information regarding data collection for model training. For example, the information regarding data collection may include a RS (e.g., CSI-RS) list for data collection, and the configured RS may be dynamically activated / deactivated by the gNB, e.g., via MAC CE or DCI, areas for data collection, and time periods for data collection. In some cases, the metadata may include NM IDs (associated with network side mode IDs) where data of different NM IDs may be used separately for model training, network side configurations, and additional information such as channel types. In some cases, the signaling may include a new signaling procedure or reuse of MDT configuration signaling where configuration information is added as an IE to the RRCReconfiguration message.

[0125]

[0152] At step 1710, the gNB 102 and the model manager / OAM 1602 may authorize the UE 104 for CSF model training. Once authorization is complete, the model manager / OAM 1602 may send a model training request to the gNB 102 at step 1712. At step 1714, the gNB 102 may send a model training configuration to the UE 104. At step 1716, the UE 104 may send a model training configuration ACK to the gNB 102 in response to receiving the model training configuration message. At step 1718, the gNB 102 sends a model training response to the model manager / OAM 1602.

[0126]

[0153] For example, the UE 104 collects data based on the received configuration. The collected data is uploaded to the UE vendor 502 server along with additional information including timestamps described in terms of either absolute time, relative time, or SFN+timeslot+(optionally)symbol, location information such as GNSS and radio fingerprints, i.e., RSRP / RSRQ measurements of serving and neighboring cells, if available, and metadata such as RS type, ID, and NM_ID. In some cases, the model training may be based on previously collected data without metadata. The received configuration information may be used as metadata and reported to the UE vendor 502 server. In this case, the actual data collection and reporting may be skipped. In step 1720, the UE 104 performs data collection. In step 1722, the UE 104 sends a training data report to the UE vendor 502. In step 1724, the UE vendor 502 performs model training.

[0127]

[0154] For example, the model training report may be uploaded directly to the model / data repository 504, or the data may be distilled for the gNB 102 to derive the base station model. If the data is distilled, the UE vendor 502 generates some distilled data {Z, CSI} for the trained base station model, and the gNB vendor 504 can derive the model based on the data. In step 1726, the UE vendor 502 sends the model training report to the model / data repository 504. In step 1728, the model / data repository 504 performs a model update upon receiving the model training report.

[0128]

[0155] 18 is a conceptual diagram 1800 illustrating an example frame structure for uploading data. For example, the UE 104 may send a report of data to the UE vendor 502 in response to performing data collection between the UE 104 and the gNB 102, as shown at several instances 1802, 1804, 1806, and 1808.

[0129]

[0156] In one aspect, the UE report may include {H_raw, meta_id}, where H_raw is the channel estimate for RB index, port index, and Rx index, and Meta_id has the following hierarchy: Cell ID; CSI-RS resource ID (implicitly conveys antenna mapping / layout); each record includes a timestamp, e.g., CSI-RS transmission instance or slot index, or measurement period index (e.g., record is based on measurements over a period of time, period should be configured); gNB 102 can dynamically change antenna mapping / layout, and timestamps are needed to label the reported data with the correct antenna mapping / layout; a list of records {record #1, record #2, etc.}; SNR, SINR or RSRP; subcarrier spacing; and Doppler / delay spread measurements.

[0130]

[0157] In one aspect, the format of H_raw and other additional data may include a frequency domain resolution corresponding to a subcarrier, RB, or subband, and / or the eigendirection of H_raw is also reported as {H_raw, V_raw, meta_id}, where the V_raw frequency granularity is less than or equal to the H_raw frequency granularity.

[0131]

[0158] 19 is a message diagram 1900 illustrating example messages for a data collection procedure and offline model training for CSF compression using area-based training at a UE. For example, diagram 1900 illustrates messaging between a UE vendor, such as UE vendor 502 of FIG. 5, a UE, such as UE 104 of FIG. 1, a gNB, such as base station 102 of FIG. 1, model manager / OAM 1602, and model / data repository 504, both of which are associated with and / or part of gNB vendor 504 of FIG. 5.

[0132]

[0159] In one aspect, in step 1902, an MLF for CSF compression is defined and registered across the UE vendor 502, the UE 104, the gNB 102, the model manager / OAM 1602, and the model / data repository 504. For example, the UE vendor 502 registers its CSF model with a network, such as the gNB 102 and / or the gNB vendor 504. In some cases, the registration includes a model ID or model structure (MS) ID, a list of parameter set (PS) IDs, applicable scenarios for each PS including area, configuration, and UE type, and applicable scenarios for each model in case multiple models are registered. For example, the model training is initiated by the UE vendor 502. In some cases, the model training is coordinated by the model manager / OAM 1602, which may correspond to an OAM, a RIC (ORAN defined network entity, intelligent network controller), a CU-XP, or a gNB, such as the gNB 102, depending on the deployment scenario and use case.

[0133]

[0160] In step 1904, the model / data repository 504 may send a model training request to the model manager / OAM 1602, and in step 1906, the model manager / OAM 1602 forwards the model training request to the gNB 102. In step 1908, the gNB 102 performs UE selection. In step 1910, the gNB 102 sends a model training configuration to the UE 104. In step 1912, the UE 104 sends a model training configuration ACK to the gNB 102. In step 1914, the gNB 102 sends a model training response to the model manager / OAM 1602. In step 1916, training data reporting is performed. In step 1918, the model / data repository 504 performs model training. In step 1920, the model / data repository 504 sends a UE model delivery to the UE vendor 502.

[0134]

[0161] 20 is a message diagram 2000 illustrating example messages for a data collection procedure and offline model training for CSF compression using UE-based training in a UE. For example, diagram 2000 illustrates messaging between a UE vendor, such as UE vendor 502 of FIG. 5, a UE, such as UE 104 of FIG. 1, a gNB, such as base station 102 of FIG. 1, a model manager / RIC 2002, and a model / data repository 504, both of which are associated with and / or part of gNB vendor 504 of FIG. 5.

[0135]

[0162] In one aspect, in step 2004, an MLF for CSF compression is defined and registered across UE vendor 502, UE 104, gNB 102, model manager / RIC 2002, and model / data repository 504. For example, UE vendor 502 registers its CSF model with a network, such as gNB 102 and / or gNB vendor 504. In some cases, the registration includes a model ID or model structure (MS) ID, a list of parameter set (PS) IDs, applicable scenarios for each PS including area, configuration, and UE type, and applicable scenarios for each model in case multiple models are registered. For example, model training is initiated by UE vendor 502. In some cases, model training is coordinated by model manager / RIC 2002, which may correspond to OAM, RIC (ORAN defined network entity, intelligent network controller), CU-XP, or gNB, such as gNB 102, depending on the deployment scenario and use case.

[0136]

[0163] In step 2006, the model / data repository 504 may send a model training request to the model manager / RIC 2002. In step 2008, the model manager / RIC 2002 performs UE selection. In step 2010, the model manager / RIC 2002 forwards the model training request to the gNB 102. In step 2012, the gNB 102 sends a model training configuration to the UE 104. In step 2014, the UE 104 sends a model training configuration ACK to the gNB 102. In step 2016, the gNB 102 sends a model training response to the model manager / RIC 2002. In step 2018, training data reporting is performed. In step 2020, the model / data repository 504 performs model training. In step 2022, the model / data repository 504 sends a UE model delivery to the UE vendor 502.

[0137]

[0164] Figure 21 is a message diagram 2100 illustrating example messages for reporting training data during a data collection procedure for CSF compression. For example, diagram 2100 illustrates specific messaging that occurs during step 1916 of Figure 19 and step 2018 of Figure 20 between a UE vendor, such as UE vendor 502 of Figure 5, a UE, such as UE 104 of Figure 1, a gNB, such as base station 102 of Figure 1, model manager 1602, and a model / data repository, such as gNB vendor 504 of Figure 5. In one example, the data to be reported may include channel matrix, UE model information such as MS ID and PS ID, as well as NM ID and timestamp.

[0138]

[0165] In one aspect, reporting of training data may be performed based on MDT extensions. For example, in step 2102, the UE 104 may send a data report to the gNB 104. In step 2104, the gNB 104 may forward the data report to the model manager 1602. In some cases, a new IE may be added to the MDT report signaling, which may be file-based or streaming-based. In step 2106, the model manager 1602 may forward the data report to the model / data repository 504.

[0139]

[0166] In one aspect, training data reporting may be performed vendor-to-vendor. For example, in step 2108, the UE 104 may send a data report to the UE vendor 502. In step 2110, the UE vendor 502 may upload data received from the data report to the model / data repository 504. In some instances, the UE vendor 502 may report directly to the gNB vendor 504 using a proprietary protocol.

[0140]

[0167] In one aspect, the UE collected data can be used to train both models on the network side. For example, the data collection can be done by the UE vendor 502 similar to the messaging described in Figures 16 and 17. The UE vendor 502 uploads the collected data to the gNB vendor 504 based on steps 2108 and 2110 of Figure 21. Furthermore, the model training can be done similar to the messaging as described in Figures 19 and 20. The gNB vendor 504 sends the UE model to the UE vendor 502 similar to the messaging described in Figures 19 and 20.

[0141]

[0168] 22 is a conceptual data flow diagram 2200 illustrating data flow between different means / components in an exemplary base station 2202, which may be an example of a base station 102 that includes a network training component 120. The network training component 120 may include a data collection component 124.

[0142]

[0169] The base station 2202 may also include a receiver component 2250 and a transmitter component 2252. The receiver component 2250 may include, for example, an RF receiver for receiving signals described herein. The transmitter component 2252 may include, for example, an RF transmitter for transmitting signals described herein. In some implementations, the receiver component 2250 and the transmitter component 2252 may be co-located within a transceiver, such as the TX / RX 318 of FIG. 3.

[0143]

[0170] 23 is a conceptual data flow diagram 2300 illustrating data flow between different means / components in an exemplary UE 2304, which may be an example of a UE 104 and may include a UE training component 140. As described with respect to FIG.

[0144]

[0171] The UE 104 may also include a receiver component 2370 and a transmitter component 2372. The receiver component 2370 may include, for example, an RF receiver for receiving signals as described herein. The transmitter component 2372 may include, for example, an RF transmitter for transmitting signals as described herein. In some implementations, the receiver component 2370 and the transmitter component 2372 may be co-located within a transceiver, such as the TX / RX 354 of FIG. 3.

[0145]

[0172] 24 is a flow chart of an example method 2400 for a UE vendor for cross-node machine learning training. The method 2400 may be performed by a UE vendor (such as the UE vendor 310 / 502, which may include memory 360 and may be the entire UE vendor 310 / 502 or a component of the UE vendor 310 / 502, such as the Tx processor 368, the Rx processor 356, or the controller / processor 359).

[0146]

[0173] At block 2410, the method 2400 includes training one or more encoder-decoder pairs based on the UE vendor's raw data set. In some implementations, for example, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may be configured to train one or more encoder-decoder pairs based on the UE vendor's raw data set. Thus, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may provide means for training one or more encoder-decoder pairs based on the UE vendor's raw data set.

[0147]

[0174] At block 2420, the method 2400 includes generating one or more training sets based on the output of one or more encoders running the UE vendor's raw data set. In some implementations, for example, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may be configured to generate the one or more training sets based on the output of the one or more encoders running the UE vendor's raw data set. Thus, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may provide a means for generating the one or more training sets based on the output of the one or more encoders running the UE vendor's raw data set.

[0148]

[0175] At block 2420, the method 2400 includes communicating the one or more training sets to a network entity vendor. In some implementations, for example, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may be configured to communicate the one or more training sets to the network entity vendor. Thus, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may provide a means for communicating the one or more training sets to the network entity vendor.

[0149]

[0176] In some implementations, each of the one or more training sets includes an encoder identification (ID), an encoder output, and a desired decoder output.

[0150]

[0177] In some implementations, each of the one or more training sets is associated with one or more metadata to enable switching between one or more models during inference.

[0151]

[0178] In some implementations, the one or more metadata include at least one of a UE antenna configuration, a signal-to-noise ratio (SNR), a Reference Signal Receive Power (RSRP), a delay rate, an average delay, and a timestamp.

[0152]

[0179] In some implementations, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may be configured to resolve one or more pieces of metadata into a UE meta ID.

[0153]

[0180] In some implementations, the encoder output of the one or more encoders corresponds to a compressed channel state information (CSI) feedback (CSF) message.

[0154]

[0181] In some implementations, the decoder output of one or more decoders of the one or more encoder-decoder pairs includes reconstructed CSFs corresponding to the one or more precoding vectors.

[0155]

[0182] 25 is a flow chart of an example method 2500 for a UE vendor for cross-node machine learning training. The method 2500 may be performed by a UE vendor (such as the UE vendor 310 / 502, which may include memory 360 and may be the entire UE vendor 310 / 502 or a component of the UE vendor 310 / 502, such as the Tx processor 368, the Rx processor 356, or the controller / processor 359).

[0156]

[0183] At block 2510, the method 2500 includes training one or more encoder-decoder pairs based on the UE vendor's raw data set. In some implementations, for example, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may be configured to train one or more encoder-decoder pairs based on the UE vendor's raw data set. Thus, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may provide means for training one or more encoder-decoder pairs based on the UE vendor's raw data set.

[0157]

[0184] At block 2520, the method 2500 generates two training sets for each of the one or more encoder-decoder pairs based on the output of one or more encoders running the UE vendor's raw data set. In some implementations, for example, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may be configured to generate two training sets for each of the one or more encoder-decoder pairs based on the output of one or more encoders running the UE vendor's raw data set. Thus, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may provide means for generating two training sets for each of the one or more encoder-decoder pairs based on the output of one or more encoders running the UE vendor's raw data set.

[0158]

[0185] At block 2520, the method 2500 includes communicating the two training sets to a network entity vendor. In some implementations, for example, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may be configured to communicate the two training sets to the network entity vendor. Thus, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may provide a means for communicating the two training sets to the network entity vendor.

[0159]

[0186] In some implementations, generating the two training sets further includes generating a first training set based on an output of an encoder and a decoder using a raw data set of a UE vendor.

[0160]

[0187] In some implementations, the first training set includes an encoder identification (ID), an encoder output, and a reconstruction of the desired decoder output by the decoder.

[0161]

[0188] In some implementations, generating the two training sets further includes generating a second training set based on perturbing the encoder outputs in the first training set by the vector and calculating corresponding decoder outputs.

[0162]

[0189] In some implementations, the second training set includes encoder IDs, combinations of encoder outputs and vectors, and corresponding decoder outputs.

[0163]

[0190] In some implementations, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may be configured to identify an alternative decoder that approximates a decoder found in one of the one or more encoder-decoder pairs and communicate the alternative decoder to the network entity vendor.

[0164]

[0191] In some implementations, the alternative decoder produces at least similar output as the found decoder in response to the first training set and the second training set.

[0165]

[0192] In some implementations, identifying the alternative decoder further comprises identifying a respective alternative decoder for each encoder ID corresponding to a respective encoder of the one or more encoder-decoder pairs.

[0166]

[0193] In some implementations, the encoder output of the one or more encoders corresponds to a compressed channel state information (CSI) feedback (CSF) message.

[0167]

[0194] In some implementations, the decoder output of one or more decoders of the one or more encoder-decoder pairs includes reconstructed CSFs corresponding to the one or more precoding vectors.

[0168]

[0195] 26 is a flow chart of an example method 2600 for a network entity vendor for cross-node machine learning training. The method 2600 may be performed by a network entity vendor (such as a network entity / gNB vendor 316 / 504, which may include memory 376 and may be a component of the network entity / gNB vendor 316 / 504, such as a Tx processor 316, an Rx processor 370, or a controller / processor 375).

[0169]

[0196] At block 2610, the method 2600 includes receiving one or more training sets corresponding to one or more encoder-decoder pairs from a UE vendor. In some implementations, for example, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may be configured to receive one or more training sets from a UE vendor, where the one or more training sets correspond to one or more encoder-decoder pairs. Thus, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may provide means for receiving one or more training sets corresponding to one or more encoder-decoder pairs from a UE vendor.

[0170]

[0197] At block 2620, the method 2600 includes training one or more decoders associated with the one or more training sets. In some implementations, for example, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may be configured to train one or more decoders associated with the one or more training sets. Thus, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may provide means for training one or more decoders associated with the one or more training sets.

[0171]

[0198] In some implementations, each of the one or more training sets includes an encoder identification (ID), an encoder output, and a desired decoder output.

[0172]

[0199] In some implementations, each of the one or more training sets is associated with one or more metadata to enable switching between one or more models during inference.

[0173]

[0200] In some implementations, the one or more metadata include at least one of a UE antenna configuration, a signal-to-noise ratio (SNR), a reference signal received power (RSRP), a delay rate, an average delay, and a timestamp.

[0174]

[0201] In some implementations, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may be configured to determine, based on one or more training sets, whether one or more decoders are associated with a network entity or shared across multiple network entities.

[0175]

[0202] 27 is a flow chart of an example method 2700 for a network entity vendor for cross-node machine learning training. The method 2700 may be performed by a network entity vendor (such as a network entity / gNB vendor 316 / 504, which may include memory 376 and may be a component of the network entity / gNB vendor 316 / 504, such as a Tx processor 316, an Rx processor 370, or a controller / processor 375).

[0176]

[0203] At block 2710, the method 2700 includes receiving two training sets corresponding to one or more encoder-decoder pairs from a UE vendor. In some implementations, for example, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may be configured to receive two training sets from a UE vendor, the two training sets corresponding to one or more encoder-decoder pairs. Thus, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may provide means for receiving two training sets corresponding to one or more encoder-decoder pairs from a UE vendor.

[0177]

[0204] At block 2720, the method 2700 includes training one or more decoders associated with the two training sets. In some implementations, for example, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may be configured to train one or more decoders associated with the two training sets. Thus, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may provide means for training the two decoders associated with the two training sets.

[0178]

[0205] In some implementations, the first training set includes encoder identification (ID), encoder outputs, and reconstructions of desired decoder outputs by one or more decoders.

[0179]

[0206] In some implementations, the second training set includes encoder IDs, combinations of encoder outputs and vectors, and corresponding decoder outputs.

[0180]

[0207] In some implementations, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may be configured to receive an alternative decoder that approximates a decoder found in one of the one or more encoder-decoder pairs.

[0181]

[0208] In some implementations, the alternative decoder produces at least similar output as the found decoder in response to the first training set and the second training set.

[0182]

[0209] In some implementations, each of the two training sets is associated with one or more metadata to enable switching between one or more models during inference.

[0183]

[0210] In some implementations, the one or more metadata include at least one of a UE antenna configuration, a signal-to-noise ratio (SNR), a reference signal received power (RSRP), a delay rate, an average delay, and a timestamp.

[0184]

[0211] In some implementations, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may be configured to determine, based on the two training sets, whether one or more decoders are associated with a network entity or shared across multiple network entities.

[0185]

[0212] 28 is a flowchart of an example method 2800 for a UE to perform a CSF data collection procedure. The method 2800 may be performed by a UE (such as the UE 104, which may include memory 360 and may be the UE 104 in its entirety or a component of the UE 104, such as the TX processor 368, the Rx processor 356, or the controller / processor 359).

[0186]

[0213] At block 2810, the method 2800 optionally includes receiving a training data request from a UE vendor. In some implementations, for example, the UE 104, the Rx processor 356, or the controller / processor 359 may be configured to receive the training data request from the UE vendor. Thus, the UE 104, the Rx processor 356, or the controller / processor 359 may provide means for receiving the training data request from the UE vendor.

[0187]

[0214] At block 2820, the method 2800 includes transmitting the training data request to a network entity. In some implementations, for example, the UE 104, the Rx processor 356, or the controller / processor 359 may be configured to transmit the training data request to the network entity. Thus, the UE 104, the Rx processor 356, or the controller / processor 359 may provide a means for transmitting the training data request to the network entity.

[0188]

[0215] At block 2830, the method 2800 includes receiving a data collection configuration message from a network entity in response to transmitting the training data request. In some implementations, for example, the UE 104, the Rx processor 356, or the controller / processor 359 may be configured to receive a data collection configuration message from a network entity in response to transmitting the training data request. Thus, the UE 104, the Rx processor 356, or the controller / processor 359 may provide means for receiving a data collection configuration message from a network entity in response to transmitting the training data request.

[0189]

[0216] At block 2840, the method 2800 includes transmitting a data collection configuration acknowledgement (ACK) to a network entity in response to receiving the data collection configuration message. In some implementations, for example, the UE 104, the Rx processor 356, or the controller / processor 359 may be configured to transmit a data collection configuration acknowledgement (ACK) to a network entity in response to receiving the data collection configuration message. Thus, the UE 104, the Rx processor 356, or the controller / processor 359 may provide a means for transmitting a data collection configuration acknowledgement (ACK) to a network entity in response to receiving the data collection configuration message.

[0190]

[0217] At block 2850, the method 2800 includes performing a data collection procedure based on the data collection configuration message. In some implementations, for example, the UE 104, the Rx processor 356, or the controller / processor 359 may be configured to perform the data collection procedure based on the data collection configuration message. Thus, the UE 104, the Rx processor 356, or the controller / processor 359 may provide means for performing the data collection procedure based on the data collection configuration message.

[0191]

[0218] At block 2860, the method 2800 optionally includes uploading one or more data to a UE vendor based on performing the data collection procedure. In some implementations, for example, the UE 104, the Rx processor 356, or the controller / processor 359 may be configured to upload one or more data to a UE vendor based on performing the data collection procedure. Thus, the UE 104, the Rx processor 356, or the controller / processor 359 may provide a means for uploading one or more data to a UE vendor based on performing the data collection procedure.

[0192]

[0219] In some implementations, the data collection configuration message includes at least one of a reference signal (RS) list for data collection, an area for data collection, a period for data collection, a network side configuration, a channel type, and a process identification (ID) for data collection.

[0193]

[0220] In some implementations, the process ID corresponds to a model ID registered with a machine learning function (MLF).

[0194]

[0221] In some implementations, the process ID corresponds to a meta ID used for data collection or generates a meta ID for data upload that corresponds to one or more metadata based on the process ID.

[0195]

[0222] In some implementations, receiving the data collection configuration message further includes receiving the data collection configuration message as at least one of a radio resource control (RRC) reconfiguration message or an information element in a new signaling procedure.

[0196]

[0223] In some implementations, the one or more pieces of data correspond to a UE report including a downlink raw channel matrix and a metadata identification (Meta ID).

[0197]

[0224] In some implementations, the downlink raw channel matrix corresponds to a channel estimate based on a resource block (RB) index, a port index, and a receive antenna index.

[0198]

[0225] In some implementations, the meta ID includes at least one of a data package ID, a cell / carrier ID, a channel state information (CSI) reference signal (RS) resource ID, a list of one or more records of collected data, and a Global Navigation Satellite System (GNSS) ID.

[0199]

[0226] In some implementations, the list of one or more records includes at least one of a timestamp, a signal-to-noise ratio (SNR), a signal-to-interference and noise ratio (SINR), or a reference signal received power (RSRP), a subcarrier spacing, and a Doppler / delay spread measurement.

[0200]

[0227] In some implementations, a format of the UE report including at least one of the downlink raw channel matrices corresponds to a first frequency domain resolution, and an eigendirection of the downlink raw channel matrix corresponds to a second frequency domain resolution.

[0201]

[0228] In some implementations, the UE 104, Rx processor 356, or controller / processor 359 configured to perform the data collection procedure further comprises receiving a reference signal (RS) from the network entity in response to transmitting the data collection configuration ACK, and performing one or more measurements based on the RS.

[0202]

[0229] 29 is a flowchart of an example method 2900 for a network entity to perform a CSF data collection procedure. The method 2900 may be performed by a network entity (which may include memory 376 and may be the network entity 102, or a component of the network entity 102, such as the Tx processor 316, the Rx processor 370, or the controller / processor 375).

[0203]

[0230] At block 2910, the method 2900 includes receiving a training data request from a user equipment (UE). In some implementations, for example, the network entity 102, the Tx processor 316, or the controller / processor 375 may be configured to receive the training data request from the user equipment (UE). Thus, the network entity 102, the Tx processor 316, or the controller / processor 375 may provide means for receiving the training data request from the user equipment (UE).

[0204]

[0231] At block 2920, the method 2900 includes transmitting a data collection configuration message to the UE in response to receiving the training data request. In some implementations, for example, the network entity 102, the Tx processor 316, or the controller / processor 375 may be configured to transmit the data collection configuration message to the UE in response to receiving the training data request. Thus, the network entity 102, the Tx processor 316, or the controller / processor 375 may provide means for transmitting a data collection configuration message to the UE in response to receiving the training data request.

[0205]

[0232] At block 2930, the method 2900 includes receiving a data collection configuration acknowledgement (ACK) from the UE in response to transmitting the data collection configuration message. In some implementations, for example, the network entity 102, the Tx processor 316, or the controller / processor 375 may be configured to receive a data collection configuration acknowledgement (ACK) from the UE in response to transmitting the data collection configuration message. Thus, the network entity 102, the Tx processor 316, or the controller / processor 375 may provide means for receiving a data collection configuration acknowledgement (ACK) from the UE in response to transmitting the data collection configuration message.

[0206]

[0233] At block 2940, the method 2900 includes performing a data collection procedure based on the data collection configuration message. In some implementations, for example, the network entity 102, the Tx processor 316, or the controller / processor 375 may be configured to perform the data collection procedure based on the data collection configuration message. Thus, the network entity 102, the Tx processor 316, or the controller / processor 375 may provide means for performing the data collection procedure based on the data collection configuration message.

[0207]

[0234] In some implementations, performing the data collection procedure further includes transmitting a reference signal (RS) to the UE in response to receiving the data collection configuration ACK.

[0208]

[0235] In some implementations, the data collection configuration message includes at least one of a reference signal (RS) list for data collection, an area for data collection, a period for data collection, a network side configuration, a channel type, and a process identification (ID) for data collection.

[0209]

[0236] In some implementations, the process ID corresponds to a model ID registered with a machine learning function (MLF) or corresponds to a meta ID used for data collection.

[0210]

[0237] In some implementations, transmitting the data collection configuration message further includes transmitting the data collection configuration message as at least one of a radio resource control (RRC) reconfiguration message or an information element in a new signaling procedure.

[0211]

[0238] 30 is a flowchart of an example method 3000 for a UE to perform a CSF data collection procedure. The method 3000 may be performed by a UE (such as the UE 104, which may include memory 360 and may be the UE 104 in its entirety or a component of the UE 104, such as the TX processor 368, the Rx processor 356, or the controller / processor 359).

[0212]

[0239] At block 3010, the method 3000 includes receiving a data collection configuration message from a network entity based on the training data request. In some implementations, for example, the UE 104, the Rx processor 356, or the controller / processor 359 may be configured to receive the data collection configuration message from the network entity based on the training data request. Thus, the UE 104, the Rx processor 356, or the controller / processor 359 may provide a means for receiving a data collection configuration message from the network entity based on the training data request.

[0213]

[0240] At block 3020, the method 3000 includes transmitting a data collection configuration acknowledgement (ACK) to a network entity in response to receiving the data collection configuration message. In some implementations, for example, the UE 104, the Rx processor 356, or the controller / processor 359 may be configured to transmit a data collection configuration acknowledgement (ACK) to a network entity in response to receiving the data collection configuration message. Thus, the UE 104, the Rx processor 356, or the controller / processor 359 may provide a means for transmitting a data collection configuration acknowledgement (ACK) to a network entity in response to receiving the data collection configuration message.

[0214]

[0241] At block 3030, the method 3000 includes performing a data collection procedure based on the data collection configuration message. In some implementations, for example, the UE 104, the Rx processor 356, or the controller / processor 359 may be configured to perform the data collection procedure based on the data collection configuration message. Thus, the UE 104, the Rx processor 356, or the controller / processor 359 may provide means for performing the data collection procedure based on the data collection configuration message.

[0215]

[0242] At block 3040, the method 3000 includes reporting training data between at least one of the network entities, the UE vendor, and the network entity vendor based on performing the data collection procedure. In some implementations, for example, the UE 104, the Rx processor 356, or the controller / processor 359 may be configured to report training data between at least one of the network entities, the UE vendor, and the network entity vendor based on performing the data collection procedure. Thus, the UE 104, the Rx processor 356, or the controller / processor 359 may provide a means for reporting training data between at least one of the network entities, the UE vendor, and the network entity vendor based on performing the data collection procedure.

[0216]

[0243] In some implementations, reporting the training data further includes reporting the training data using at least one of a minimizing driving test (MDT) extension, vendor-UE-vendor, and inter-vendor.

[0217]

[0244] In some implementations, reporting the training data using the MDT extension includes transmitting the training data to a network entity.

[0218]

[0245] In some implementations, reporting the training data using the vendor-UE-vendor includes reporting the training data to a UE vendor and sending a data or data address report to a network entity.

[0219]

[0246] In some implementations, reporting the training data using inter-vendor includes reporting the training data to a UE vendor.

[0220]

[0247] In some implementations, the data collection configuration message includes a reference signal (RS) list for data collection, an area for data collection, a period for data collection, a network side configuration, a channel type, and a process identification (ID) for data collection.

[0221]

[0248] In some implementations, the process ID corresponds to a model ID registered with a machine learning function (MLF) or corresponds to a meta ID used for data collection.

[0222]

[0249] In some implementations, receiving the data collection configuration message further includes receiving the data collection configuration message as at least one of a radio resource control (RRC) reconfiguration message or an information element in a new signaling procedure.

[0223]

[0250] In some implementations, performing the data collection procedure further includes receiving a Reference Signal (RS) from the network entity in response to transmitting the Data Collection Configuration ACK, and performing one or more measurements based on the RS.

[0224]

[0251] 31 is a flow chart of an example method 3100 for a network entity to perform a CSF data collection procedure. The method 3100 may be performed by a network entity (such as the network entity 102, which may include memory 376 and may be a component of the network entity 102, such as the Tx processor 316, the Rx processor 370, or the controller / processor 375).

[0225]

[0252] At block 3110, the method 3100 includes receiving a training data request from a network entity vendor. In some implementations, for example, the network entity 102, the Tx processor 316, or the controller / processor 375 may be configured to receive the training data request from the network entity vendor. Thus, the network entity 102, the Tx processor 316, or the controller / processor 375 may provide a means for receiving the training data request from the network entity vendor.

[0226]

[0253] At block 3120, the method 3100 includes transmitting a data collection configuration message to the user equipment (UE) in response to receiving the training data request. In some implementations, for example, the network entity 102, the Tx processor 316, or the controller / processor 375 may be configured to transmit the data collection configuration message to the user equipment (UE) in response to receiving the training data request. Thus, the network entity 102, the Tx processor 316, or the controller / processor 375 may provide means for transmitting a data collection configuration message to the user equipment (UE) in response to receiving the training data request.

[0227]

[0254] At block 3130, the method 3100 includes receiving a data collection configuration acknowledgement (ACK) from the UE in response to transmitting the data collection configuration message. In some implementations, for example, the network entity 102, the Tx processor 316, or the controller / processor 375 may be configured to receive a data collection configuration acknowledgement (ACK) from the UE in response to transmitting the data collection configuration message. Thus, the network entity 102, the Tx processor 316, or the controller / processor 375 may provide means for receiving a data collection configuration acknowledgement (ACK) from the UE in response to transmitting the data collection configuration message.

[0228]

[0255] At block 3140, the method 3100 includes performing a data collection procedure based on the data collection configuration message. In some implementations, for example, the network entity 102, the Tx processor 316, or the controller / processor 375 may be configured to perform the data collection procedure based on the data collection configuration message. Thus, the network entity 102, the Tx processor 316, or the controller / processor 375 may provide a means for performing the data collection procedure based on the data collection configuration message.

[0229]

[0256] At block 3150, the method 3100 includes receiving or reporting training data between the UE, the UE vendor, and the network entity vendor based on performing the data collection procedure. In some implementations, for example, the network entity 102, the Tx processor 316, or the controller / processor 375 may be configured to receive or report training data between the UE, the UE vendor, and the network entity vendor based on performing the data collection procedure. Thus, the network entity 102, the Tx processor 316, or the controller / processor 375 may provide a means for receiving or reporting training data between the UE, the UE vendor, and the network entity vendor based on performing the data collection procedure.

[0230]

[0257] In some implementations, reporting the training data further includes reporting the training data using at least one of a Minimized Drive Test (MDT) extension, vendor-UE-vendor, and inter-vendor.

[0231]

[0258] In some implementations, reporting the training data using the MDT extension includes receiving the training data from the UE and forwarding the training data to a network entity vendor.

[0232]

[0259] In some implementations, reporting training data using a vendor-UE-vendor includes receiving a data or data address report from the UE and forwarding the data or data address report to the network entity vendor.

[0233]

[0260] In some implementations, performing the data collection procedure further includes transmitting a reference signal (RS) to the UE in response to receiving the data collection configuration ACK.

[0234]

[0261] 32 is a flow chart of an example method 3200 for a UE vendor to perform data collection and offline model training for CSF compression. The method 3200 may be performed by a UE vendor (such as the UE vendor 310 / 502, which may include memory 360 and may be the entire UE vendor 310 / 502 or a component of the UE vendor 310 / 502, such as the Tx processor 368, the Rx processor 356, or the controller / processor 359).

[0235]

[0262] At block 3210, the method 3200 includes communicating a training data request to initiate model training for the UE vendor and the network entity vendor. In some implementations, for example, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may be configured to communicate the training data request to initiate model training for the UE vendor and the network entity vendor. Thus, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may provide a means for communicating the training data request to initiate model training for the UE vendor and the network entity vendor.

[0236]

[0263] At block 3220, the method 3200 includes receiving a training data report in response to communicating the training data request. In some implementations, for example, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may be configured to receive the training data report in response to communicating the training data request. Thus, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may provide means for receiving the training data report in response to communicating the training data request.

[0237]

[0264] At block 3230, the method 3200 includes performing model training for a channel state information (CSI) feedback (CSF) model. In some implementations, for example, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may be configured to perform model training for the channel state information (CSI) feedback (CSF) model. Thus, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may provide means for performing model training for the channel state information (CSI) feedback (CSF) model.

[0238]

[0265] At block 3240, the method 3200 includes communicating the model training report to a network entity vendor. In some implementations, for example, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may be configured to communicate the model training report to the network entity vendor. Thus, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may provide a means for communicating the model training report to the network entity vendor.

[0239]

[0266] In some implementations, communicating the training data request further includes communicating the training data request to a network entity vendor to initiate model training.

[0240]

[0267] In some implementations, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may be configured to receive a training data request acknowledgment (ACK) from the network entity vendor in response to communicating the training data request.

[0241]

[0268] In some implementations, communicating the training data request further includes communicating the training data request to the UE to collect data for model training.

[0242]

[0269] In some implementations, the UE vendor 310 / 502, the Rx processor 356, or the controller / processor 359 may be configured to register one or more CSF models with a network associated with the UE vendor and the network entity vendor.

[0243]

[0270] In some implementations, registering one or more CSF models includes registering one or more model identifications (IDs) or model structure (MS) IDs, a list of parameter set (PS) IDs, and applicable scenarios for each PS including area, configuration, and UE type.

[0244]

[0271] In some implementations, the training data report includes at least one of a timestamp, location information, and metadata.

[0245]

[0272] In some implementations, the timestamp corresponds to at least one of an absolute time, a relative time, or a combination of a system frame number (SFN), a time slot, and optionally a symbol.

[0246]

[0273] In some implementations, the location information includes at least one of Global Navigation Satellite System (GNSS) and radio fingerprints corresponding to Reference Signal Received Power (RSRP) / Reference Signal Received Quality (RSRQ) measurements of the serving cell and neighboring cells.

[0247]

[0274] In some implementations, the metadata includes at least one of a reference signal (RS) type identification (ID) and an NM ID.

[0248]

[0275] In some implementations, communicating the model training further includes either directly uploading the model training or a network entity distilling the data to derive the model training.

[0249]

[0276] In some implementations, the distilled data for the network entity corresponds to a UE report including a downlink raw channel matrix and metadata identification information (Meta ID).

[0250]

[0277] In some implementations, the downlink raw channel matrix corresponds to a channel estimate based on a resource block (RB) index, a port index, and a receiver index.

[0251]

[0278] In some implementations, the meta ID includes a cell ID, a channel state information (CSI) reference signal (RS) resource ID, and a list of one or more records.

[0252]

[0279] In some implementations, the list of one or more records includes at least one of a timestamp, a signal-to-noise ratio (SNR), a signal-to-interference-plus-noise ratio (SINR), or a reference signal received power (RSRP), a subcarrier spacing, and a Doppler / delay spread measurement.

[0253]

[0280] In some implementations, the format of the UE report containing the downlink raw channel matrix corresponds to the frequency domain resolution and eigendirections of the downlink raw channel matrix.

[0254]

[0281] 33 is a flowchart of an example method 3300 for a network entity vendor to perform data collection and offline model training for CSF compression. The method 3300 may be performed by a network entity vendor (such as the network entity / gNB vendor 316 / 504, which may include memory 376 and may be a component of the network entity / gNB vendor 316 / 504, such as the Tx processor 316, the Rx processor 370, or the controller / processor 375).

[0255]

[0282] At block 3310, the method 3300 includes communicating a training data request to initiate model training for a user equipment (UE) vendor and a network entity vendor. In some implementations, for example, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may be configured to communicate the training data request to initiate model training for a user equipment (UE) vendor and a network entity vendor. Thus, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may provide a means for communicating the training data request to initiate model training for a user equipment (UE) vendor and a network entity vendor.

[0256]

[0283] At block 3320, the method 3300 includes receiving a training data report in response to communicating the training data request. In some implementations, for example, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may be configured to receive the training data report in response to communicating the training data request. Thus, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may provide means for receiving the training data report in response to communicating the training data request.

[0257]

[0284] At block 3330, the method 3300 includes performing model training for a channel state information (CSI) feedback (CSF) model. In some implementations, for example, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may be configured to perform model training for the channel state information (CSI) feedback (CSF) model. Thus, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may provide means for performing model training for the channel state information (CSI) feedback (CSF) model.

[0258]

[0285] At block 3340, the method 3300 includes communicating the model training report to the UE vendor. In some implementations, for example, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may be configured to communicate the model training report to the UE vendor. Thus, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may provide a means for communicating the model training report to the UE vendor.

[0259]

[0286] In some implementations, communicating the training data request further includes communicating the training data request to a model manager for forwarding to a network entity for performing a UE selection procedure.

[0260]

[0287] In some implementations, communicating the training data request further includes communicating the training data request to a model manager to perform a UE selection procedure.

[0261]

[0288] In some implementations, the network entity / gNB vendor 316 / 504, the Tx processor 316, or the controller / processor 375 may be configured to register one or more CSF models with a network associated with the UE vendor and the network entity vendor.

[0262]

[0289] In some implementations, registering one or more CSF models includes registering one or more model identifications (IDs) or model structure (MS) IDs, a list of parameter set (PS) IDs, and applicable scenarios for each PS including area, configuration, and UE type.

[0263]

[0290] In some implementations, communicating the model training further includes either directly uploading the model training or a network entity distilling the data to derive the model training.

[0264]

[0291] In some implementations, the distilled data for the network entity corresponds to a UE report including a downlink raw channel matrix and metadata identification information (Meta ID).

[0265]

[0292] In some implementations, the downlink raw channel matrix corresponds to a channel estimate based on a resource block (RB) index, a port index, and a receiver index.

[0266]

[0293] In some implementations, the meta ID includes a cell ID, a channel state information (CSI) reference signal (RS) resource ID, and a list of one or more records.

[0267]

[0294] In some implementations, receiving the training data report further includes receiving the training data report using at least one of a Minimized Drive Test (MDT) extension and cross-vendor.

[0268]

[0295] In some implementations, receiving the training data report using the MDT extension includes receiving the training data report from a model manager.

[0269]

[0296] In some implementations, receiving the training data report using inter-vendor includes receiving the training data report from the UE vendor using a proprietary protocol.

[0270]

[0297]

[0004] Appendices are included which are part of this application and provide additional details regarding various aspects of the present disclosure.

[0271]

[0298] The following examples are exemplary clauses only, aspects of which may be combined without limitation with aspects of other embodiments or teachings described herein.

[0272]

[0299] Clause 1. A method of wireless communication for a user equipment (UE) vendor, comprising: Communicating a training data request to initiate model training for a UE vendor and a network entity vendor; receiving a training data report in response to communicating the training data request; performing model training for a channel state information (CSI) feedback (CSF) model; communicating the model training report to a network entity vendor; A method comprising:

[0273]

[0300] Clause 2. The method of clause 1, wherein communicating the training data request further includes communicating the training data request to a network entity vendor to initiate model training.

[0274]

[0301] Clause 3. The method of clause 1 or 2, further comprising receiving a training data request acknowledgment (ACK) from the network entity vendor in response to communicating the training data request.

[0275]

[0302] Clause 4. The method of any of clauses 1-3, wherein communicating the training data request further includes communicating the training data request to a UE to collect data for model training.

[0276]

[0303] Clause 5. The method of any one of clauses 1 to 4, further comprising registering one or more CSF models with a network associated with a UE vendor and a network entity vendor.

[0277]

[0304] Clause 6. The method of clause 5, wherein registering one or more CSF models includes registering one or more model identification information (ID) or model structure (MS) ID, a list of parameter set (PS) IDs, and applicable scenarios for each PS including area, configuration, and UE type.

[0278]

[0305] Clause 7. The method of any of clauses 1-6, wherein the training data report includes at least one of a timestamp, location information, and metadata.

[0279]

[0306] Clause 8. A method according to any of clauses 1 to 7, wherein the timestamp corresponds to at least one of an absolute time, a relative time, or a combination of a system frame number (SFN), a time slot, and an optional symbol.

[0280]

[0307] Clause 9. The method of any of clauses 1 to 8, wherein the location information includes at least one of Global Navigation Satellite System (GNSS) and radio fingerprints corresponding to Reference Signal Received Power (RSRP) / Reference Signal Received Quality (RSRQ) measurements of the serving cell and neighboring cells.

[0281]

[0308] Clause 10. The method of any of clauses 1 to 9, wherein the metadata includes at least one of a reference signal (RS) type identification (ID) and an NM ID.

[0282]

[0309] Clause 11. The method of any of clauses 1-10, wherein communicating the model training further includes either directly uploading the model training or a network entity distilling the data to derive the model training.

[0283]

[0310] Clause 12. The method according to any of clauses 1 to 11, wherein the distilled data for the network entity corresponds to a UE report including a downlink raw channel matrix and a metadata identification (Meta ID).

[0284]

[0311] Clause 13. The method of any of clauses 1-12, wherein the downlink raw channel matrix corresponds to a channel estimate based on a resource block (RB) index, a port index, and a receiver index.

[0285]

[0312] Clause 14. The method of any one of clauses 1 to 13, wherein the meta ID includes a cell ID, a channel state information (CSI) reference signal (RS) resource ID, and a list of one or more records.

[0286]

[0313] Clause 15. The method of any of clauses 1 to 14, wherein the list of one or more records includes at least one of a timestamp, a signal-to-noise ratio (SNR), a signal-to-interference-plus-noise ratio (SINR), or a reference signal received power (RSRP), a subcarrier spacing, and a Doppler / delay spread measurement.

[0287]

[0314] Clause 16. The method of any of clauses 1 to 15, wherein a format of the UE report including the downlink raw channel matrix corresponds to a frequency domain resolution and an eigendirection of the downlink raw channel matrix.

[0288]

[0315] Clause 17. A method of wireless communication for a network entity vendor, comprising: Communicating a training data request to initiate model training for a user equipment vendor and a network entity vendor; receiving a training data report in response to communicating the training data request; performing model training for a channel state information (CSI) feedback (CSF) model; communicating the model training report to a UE vendor; A method comprising:

[0289]

[0316] Clause 18. The method of clause 17, wherein communicating the training data request further comprises communicating the training data request to a model manager for forwarding to a network entity for performing a UE selection procedure.

[0290]

[0317] Clause 19. The method of clause 17 or 18, wherein communicating the training data request further comprises communicating the training data request to a model manager to perform a UE selection procedure.

[0291]

[0318] Clause 20. The method of any of clauses 17 to 19, further comprising registering one or more CSF models with a network associated with the UE vendor and the network entity vendor.

[0292]

[0319] Clause 21. The method of any of clauses 17 to 20, wherein registering one or more CSF models includes registering one or more model identification information (ID) or model structure (MS) ID, a list of parameter set (PS) IDs, and applicable scenarios for each PS including area, configuration, and UE type.

[0293]

[0320] Clause 22. The method of any of clauses 17 to 21, wherein communicating the model training further comprises either directly uploading the model training or a network entity distilling the data to derive the model training.

[0294]

[0321] Clause 23. The method according to any of clauses 17 to 22, wherein the distilled data for the network entity corresponds to a UE report including a downlink raw channel matrix and a metadata identification (Meta ID).

[0295]

[0322] Clause 24. The method of any of clauses 17 to 23, wherein the downlink raw channel matrix corresponds to a channel estimate based on a resource block (RB) index, a port index, and a receiver index.

[0296]

[0323] Clause 25. The method of any of clauses 17 to 24, wherein the meta ID includes a cell ID, a channel state information (CSI) reference signal (RS) resource ID, and a list of one or more records.

[0297]

[0324] Clause 26. The method of any of clauses 17-25, wherein receiving the training data report further includes receiving the training data report using at least one of a minimizing driving test (MDT) extension and cross-vendor.

[0298]

[0325] Clause 27. The method of any of clauses 17 to 26, wherein receiving training data reports using the MDT extension includes receiving training data reports from a model manager.

[0299]

[0326] Clause 28. The method of any of clauses 17-27, wherein receiving the training data report using inter-vendor includes receiving the training data report from the UE vendor using a proprietary protocol.

[0300]

[0327] Article 29. Apparatus for wireless communication, comprising: a memory storing computer executable instructions; An apparatus comprising: at least one processor coupled to a memory and configured to implement computer-executable instructions for performing the method described in any of clauses 1-28; and / or configured to execute the method described in any of clauses 1-28.

[0301]

[0328] Clause 30. Apparatus for wireless communication, comprising: 29. An apparatus comprising one or more means for carrying out the method according to any one of clauses 1 to 28.

[0302]

[0329] 31. A computer-readable medium, which may optionally be a non-transitory computer-readable medium, having instructions or code stored thereon, the instructions or code being executable by at least one processor to perform a method according to any of clauses 1 to 28.

[0303]

[0330] The foregoing description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein but are to be accorded the widest scope consistent with the language of the claims, and references to elements in the singular do not mean "one and only," unless otherwise expressly stated, but rather "one or more." The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any aspect described herein as "exemplary" should not necessarily be construed as preferred or advantageous over other aspects. Unless otherwise expressly stated, the term "some" refers to one or more. Combinations such as "at least one of A, B, or C," "one or more of A, B, or C," "at least one of A, B, and C," "one or more of A, B, and C," and "A, B, C, or any combination thereof" include any combination of A, B, and / or C, and may include multiple As, multiple Bs, or multiple Cs. Specifically, combinations such as "at least one of A, B, or C," "one or more of A, B, or C," "at least one of A, B, and C," "one or more of A, B, and C," and "A, B, C, or any combination thereof" may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, and any such combination may include one or more elements of A, B, or C. All structural and functional equivalents of the elements of the various embodiments described throughout this disclosure that are known or that later become known to those of skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Furthermore, nothing disclosed herein is intended to be made available to the public, regardless of whether such disclosure is expressly recited in the claims.Words such as "module," "mechanism," "element," "device," and the like may not be substitutes for the word "means." Thus, no element of a claim should be construed as a means-plus-function unless the element is expressly recited using the phrase "means for."

Claims

1. A method of wireless communication for a user equipment (UE) vendor, comprising: communicating a training data request to initiate model training for the UE vendor and a network entity vendor; receiving a training data report in response to communicating the training data request; performing the model training for a channel state information (CSI) feedback (CSF) model; communicating a model training report to the network entity vendor. A method as described above.

2. The method according to claim 1, wherein communicating the training data request further comprises communicating the training data request to the network entity vendor to initiate model training.

3. The method according to claim 2, further comprising receiving a training data request acknowledgement (ACK) from the network entity vendor in response to communicating the training data request.

4. The method according to claim 1, wherein communicating the training data request further comprises communicating the training data request to a UE to collect data for the model training.

5. The method according to claim 1, further comprising registering one or more CSF models with a network associated with the UE vendor and the network entity vendor.

6. The method according to claim 5, wherein registering the one or more CSF models comprises registering a list of one or more model identification information (ID) or model structure (MS) ID, parameter set (PS) ID, and applicable scenarios of each PS including area, configuration, and UE type.

7. The method according to claim 1, wherein the training data report includes at least one of a timestamp, location information, and metadata.

8. The method according to claim 7, wherein the timestamp corresponds to at least one of absolute time, relative time, or a combination of a system frame number (SFN), a time slot, and an optional symbol.

9. The method according to claim 7, wherein the location information includes at least one of a global navigation satellite system (GNSS) and a wireless fingerprint corresponding to reference signal received power (RSRP) / reference signal received quality (RSRQ) measurements of a serving cell and adjacent cells.

10. The method according to claim 7, wherein the metadata includes at least one of reference signal (RS) type identification information (ID) and NM ID.

11. The method according to claim 1, wherein communicating the model training further includes either directly uploading the model training or distilling data by a network entity to derive the model training.

12. The method according to claim 11, wherein the distilled data for the network entity corresponds to a UE report including a downlink raw channel matrix and metadata identification information (meta ID).

13. The method according to claim 12, wherein the downlink raw channel matrix corresponds to channel estimation based on a resource block (RB) index, a port index, and a receiver index.

14. The method according to claim 12, wherein the meta ID includes a cell ID, a channel state information (CSI) reference signal (RS) resource ID, and a list of one or more records.

15. The method according to claim 14, wherein the list of one or more records includes at least one of a timestamp, a signal-to-noise ratio (SNR), a signal-to-interference-plus-noise ratio (SINR), or a reference signal received power (RSRP), a subcarrier spacing, and a Doppler / delay spread measurement.

16. The method according to claim 12, wherein the format of the UE report including the downlink raw channel matrix corresponds to the frequency domain resolution and the eigen direction of the downlink raw channel matrix.

17. A method of wireless communication for a network entity vendor, comprising: communicating a training data request to initiate model training for a user equipment vendor and the network entity vendor; receiving a training data report in response to communicating the training data request; Performing the model training for a channel state information (CSI) feedback (CSF) model; Communicating a model training report to the UE vendor; A method comprising the above.

18. The method according to claim 17, wherein communicating the training data request further comprises communicating the training data request to a model manager for transfer to a network entity for performing a UE selection procedure.

19. The method according to claim 17, wherein communicating the training data request further comprises communicating the training data request to a model manager for performing a UE selection procedure.

20. The method according to claim 17, further comprising registering one or more CSF models with a network associated with the UE vendor and the network entity vendor.

21. The method according to claim 20, wherein registering the one or more CSF models comprises registering a list of one or more model identification information (ID) or model structure (MS) ID, parameter set (PS) ID, and applicable scenarios of each PS including area, configuration, and UE type.

22. The method according to claim 17, wherein communicating the model training further comprises either directly uploading the model training or distilling data for the network entity to derive the model training.

23. The method according to claim 22, wherein the distilled data for the network entity corresponds to a UE report including a downlink raw channel matrix and metadata identification information (meta ID).

24. The method according to claim 23, wherein the downlink raw channel matrix corresponds to channel estimation based on a resource block (RB) index, a port index, and a receiver index.

25. The method according to claim 23, wherein the meta ID comprises a cell ID, a channel state information (CSI) reference signal (RS) resource ID, and a list of one or more records.

26. Receiving the training data report further includes receiving the training data report using at least one of minimizing driving test (MDT) extension and between vendors, the method according to claim 17. **Claim 27** Receiving the training data report using the MDT extension includes receiving the training data report from a model manager, the method according to claim 18. **Claim 28** Receiving the training data report using between the vendors includes receiving the training data report from the UE vendor using a proprietary protocol, the method according to claim 18. **Claim 29** An apparatus for wireless communication for a user equipment (UE) vendor, a memory storing computer-executable instructions, at least one processor coupled to the memory, comprising, the at least one processor communicating a training data request to initiate model training for the UE vendor and a network entity vendor, receiving a training data report in response to communicating the training data request, performing the model training for a channel state information (CSI) feedback (CSF) model, communicating a model training report to the network entity vendor, configured to execute the computer-executable instructions for the apparatus. **Claim 30** An apparatus for wireless communication for a network entity vendor, a memory storing computer-executable instructions, at least one processor coupled to the memory, comprising, the at least one processor communicating a training data request to initiate model training for a user equipment (UE) vendor and the network entity vendor, receiving a training data report in response to communicating the training data request, performing the model training for a channel state information (CSI) feedback (CSF) model, communicating a model training report to the UE vendor, configured to execute the computer-executable instructions for the apparatus.

Images