Data collection procedures 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]

[0001] This disclosure relates in general 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 are widely deployed to provide various telecommunications services such as telephone, video, data, messaging, and broadcast. Typical wireless communication systems can employ multiple access technologies that support 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 enables different wireless devices to communicate at the city, national, regional, and even global levels. An exemplary telecommunications standard is 5G New Radio (NR). 5G NR is part of the ongoing evolution of mobile broadband, announced by the Third Generation Partnership Project (3GPP) to meet new requirements associated with latency, reliability, security, scalability (for example, 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. These improvements may also be applicable to other multiple access technologies and the telecommunications standards that employ them. [Overview of the project]

[0004]

[0004] Hereinafter, a simplified outline of one or more embodiments is presented to provide a basic understanding of such embodiments. This outline is not a comprehensive overview of all intended embodiments, nor does it identify the main or important elements of all embodiments, nor does it describe the scope of any or all embodiments. Its sole purpose is to present in a simplified form some concepts of one or more embodiments as an introduction to the more detailed descriptions that will be presented later.

[0005]

[0005] In one aspect of the present disclosure, a method, a non-temporary computer-readable medium, and an apparatus for a user equipment (UE) vendor are provided. The method includes training one or more encoder-decoder pairs based on a raw dataset of the UE vendor; generating one or more training sets based on the outputs of one or more encoders running the raw dataset of the UE vendor; and communicating one or more training sets to a network entity vendor.

[0006]

[0006] The Disclosure also provides an apparatus (e.g., a UE vendor / server) comprising: memory for storing computer executable instructions; and at least one processor configured to execute computer executable instructions in order to perform the above method; an apparatus comprising means for performing the above method; and a non-temporary computer-readable medium for storing computer executable instructions for performing the above method.

[0007]

[0007] In another aspect, the Disclosure provides a method, a non-temporary computer-readable medium, and an apparatus for a UE vendor. The method includes training one or more encoder-decoder pairs based on a raw dataset of the UE vendor; generating two training sets for each of the one or more encoder-decoder pairs based on the outputs of one or more encoders running the raw dataset of the UE vendor; and communicating the two training sets to a network entity vendor.

[0008]

[0008] The Disclosure also provides an apparatus (e.g., a UE vendor / server) comprising: memory for storing computer executable instructions; and at least one processor configured to execute computer executable instructions in order to perform the above method; an apparatus comprising means for performing the above method; and a non-temporary computer-readable medium for storing computer executable instructions for performing the above method.

[0009]

[0009] In another aspect, the Disclosure provides a method, a non-temporary computer-readable medium, and an apparatus for a network entity vendor. The method includes receiving from a UE vendor one or more training sets corresponding to one or more encoder-decoder pairs, and training one or more decoders associated with one or more training sets.

[0010]

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

[0011]

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

[0012]

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

[0013]

[0013] In another aspect, the Disclosure provides a method, a non-temporary computer-readable medium, and an apparatus for a UE. The method includes sending a training data request to a network entity; receiving a data collection configuration message from the network entity in response to having sent the training data request; sending a data collection configuration acknowledgment (ACK) to the network entity in response to having received the data collection configuration message; and executing a data collection procedure based on the data collection configuration message.

[0014]

[0014] The Disclosure also provides an apparatus (e.g., UE) comprising: memory for storing computer executable instructions; and at least one processor configured to execute computer executable instructions in order to perform the above method; an apparatus comprising means for performing the above method; and a non-temporary computer-readable medium for storing computer executable instructions for performing the above method.

[0015]

[0015] In another aspect, the Disclosure provides a method, a non-temporary computer-readable medium, and an apparatus for a network entity. The method includes receiving a training data request from a UE; sending a data acquisition configuration message to the UE in response to receiving the training data request; receiving a data acquisition configuration ACK from the UE in response to sending the data acquisition configuration message; and executing a data acquisition procedure based on the data acquisition configuration message.

[0016]

[0016] The Disclosure also provides an apparatus (e.g., a network entity) comprising: memory for storing computer executable instructions; and at least one processor configured to execute computer executable instructions in order to perform the above method; an apparatus comprising means for performing the above method; and a non-temporary computer-readable medium for storing computer executable instructions for performing the above method.

[0017]

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

[0018]

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

[0019]

[0019] In another aspect, the Disclosure provides a method, a non-temporary computer-readable medium, and an apparatus for a network entity. The method includes receiving a training data request from a network entity vendor; sending a data collection configuration message to a UE in response to receiving the training data request; receiving a data collection configuration ACK from the UE in response to sending the data collection configuration message; executing a data collection procedure based on the data collection configuration message; and receiving or reporting training data between the UE, a UE vendor, and a network entity vendor based on executing 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]

[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 includes 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 a 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]

[0023] In another aspect, the present disclosure provides a method, a non - transient computer - readable medium, and an apparatus for a network entity vendor. The method includes 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 CSF model, and communicating a 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 - described method, an apparatus including means for performing the above - described method, and a non - transient computer - readable medium storing computer - executable instructions for performing the above - described method.

[0025]

[0025] To achieve the above - mentioned objects and related objects, one or more aspects include features that are fully described below and particularly pointed out in the claims. The following description and the accompanying drawings detail specific exemplary features of one or more aspects. However, these features are only a part of the various ways in which the principles of the various aspects can be employed, and this description is intended to cover all such aspects and their equivalents.

Brief Description of the Drawings

[0026] [Figure 1]

[0026] A diagram showing an example of a wireless communication system including an access network according to an aspect of the present specification. [Figure 2A]

[0027] A diagram showing an example of a first frame according to an aspect of the present specification. [Figure 2B]

[0028] This figure shows an example of a downlink (DL) channel within a subframe according to one aspect of this specification. [Figure 2C]

[0029] This figure shows an example of a second frame according to one aspect of this specification. [Figure 2D]

[0030] This figure shows an example of an uplink (UL) channel within a subframe according to one aspect of this specification. [Figure 3]

[0031] This figure shows an example of a base station and user equipment (UE) in an access network according to one aspect of this specification. [Figure 4]

[0032] A diagram illustrating an exemplary non-aggregated base station architecture is shown. [Figure 5]

[0033] This figure shows an example of a communication system including a UE vendor and a gNB vendor. [Figure 6]

[0034] This figure shows 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] This diagram illustrates the conceptual inner loop in UE vendor training for a single encoder-decoder pair. [Figure 8]

[0036] This message diagram shows an example message for a data collection procedure for CSF compression. [Figure 9]

[0037] This is a conceptual diagram showing an example frame structure for uploading data. [Figure 10]

[0038] This message diagram shows an example message for a data collection procedure for CSF compression. [Figure 11]

[0039] This message diagram shows an example message for the step of reporting training data during the data collection procedure for CSF compression. [Figure 12]

[0040] This message diagram shows an example message for a data collection procedure for CSF compression. [Figure 13]

[0041] This shows an example message for requesting the upload of existing data to the repository. [Figure 14]

[0042] Here is another example message for requesting the upload of existing data to the repository. [Figure 15]

[0043] Here is another example message for requesting the upload of existing data to the repository. [Figure 16]

[0044] This message diagram shows an example message for data acquisition procedures and offline model training for CSF compression using area-based training in UE. [Figure 17]

[0045] This message diagram illustrates the data acquisition procedure for CSF compression using a UE-based configuration in UE, and provides example messages for offline model training. [Figure 18]

[0046] This is a conceptual diagram showing an example frame structure for uploading data. [Figure 19]

[0047] This message diagram shows an example message for data acquisition procedures and offline model training for CSF compression using area-based training in UE. [Figure 20]

[0048] This message diagram shows an example message for data acquisition procedures and offline model training for CSF compression using UE-based training in UE. [Figure 21]

[0049] Message Figure 2100 shows an example message for the step of reporting training data during the data acquisition procedure for CSF compression. [Figure 22]

[0050] This is a conceptual data flow diagram illustrating the data flow between different means / components within an exemplary base station. [Figure 23]

[0051] This is a conceptual data flow diagram illustrating the data flow between different means / components within an exemplary UE. [Figure 24]

[0052] This is a flowchart illustrating an exemplary method for UE vendors for cross-node machine learning training. [Figure 25]

[0053] This is a flowchart illustrating an exemplary method for UE vendors for cross-node machine learning training. [Figure 26]

[0054] This is a flowchart illustrating an exemplary method for network entity vendors for cross-node machine learning training. [Figure 27]

[0055] This is a flowchart illustrating an exemplary method for network entity vendors for cross-node machine learning training. [Figure 28]

[0056] This is a flowchart illustrating an exemplary method for a UE to execute a CSF data collection procedure. [Figure 29]

[0057] This is a flowchart illustrating an exemplary method for a network entity to execute a CSF data collection procedure. [Figure 30]

[0058] This is a flowchart illustrating an exemplary method for a UE to execute a CSF data collection procedure. [Figure 31]

[0059] This is a flowchart illustrating an exemplary method for a network entity to execute a CSF data collection procedure. [Figure 32]

[0060] This is a flowchart illustrating an exemplary method for a UE vendor to perform data collection and offline model training for CSF compression. [Figure 33]

[0061] This is a flowchart illustrating an exemplary method for a network entity vendor to perform data collection and offline model training for CSF compression.

[0027]

[0062] This application includes an appendix that provides additional details relating to various aspects of this disclosure. [Modes for carrying out the invention]

[0028]

[0063] The detailed descriptions below with respect to the attached drawings describe various configurations and are not intended to represent only the configurations in which the concepts described herein can be put into practice. “Modes for Carrying Out the Invention” include specific details intended to provide a complete understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts can be put into practice without these specific details. In some cases, well-known structures and components are shown in block diagrams to avoid obscuring such concepts. While the following description may focus on 5G NR, 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 embodiment, the disclosure provides techniques for training encoders and decoders associated with user devices (UEs) and network entities, respectively.

[0030]

[0065] Several embodiments of telecommunications systems are presented here with respect to various devices and methods. These devices and methods are described in the following detailed description and are shown in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as "elements"). These elements can be implemented using electronic hardware, computer software, or any combination thereof. Whether such elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system.

[0031]

[0066] For example, an element, any part of an element, or any combination of elements can be implemented as a “processing system” comprising 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 the various functions described throughout this disclosure. One or more processors in a processing system can execute software. Software should be broadly interpreted to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, etc., regardless of whether they are called software, firmware, middleware, microcode, hardware description languages, or otherwise.

[0032]

[0067] Accordingly, in one or more exemplary embodiments, the functions described may be implemented in hardware, software, or any combination thereof. If implemented in software, these functions may be stored or encoded on a computer-readable medium as one or more instructions or codes. The computer-readable medium includes computer storage media. The storage medium may be any available medium accessible by a computer. Such computer-readable media may include, but not limited to, 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 computer-readable media of the types described above, or any other medium that can be used to store computer executable code in the form of instructions or data structures accessible by a computer.

[0033]

[0068] Figure 1 shows an example of a wireless communication system and access network 100. The wireless communication system (also called a wireless wide area network (WWAN)) includes a network entity 102, also called a base station 102, and / or which may include one or more unaggregated base station entities, a UE 104, an evolved packet core (EPC) 160, and another core network (e.g., a 5G core (5GC) 190). The base station 102 may include macrocells (high-power cellular base stations) and / or small cells (low-power cellular base stations). Macrocells include base stations. Small cells include femtocells, picocells, and microcells.

[0034]

[0069] One or more of the UE104 may include a UE training component 140 for communicating with at least one UE vendor 502 in Figure 5 to perform data acquisition and model training. In one embodiment, one or more of the base stations 102 may include a network training component 120 for communicating with at least one network entity vendor, such as the gNB vendor 504 in Figure 5, to perform data acquisition and model training with the UE104. As used herein, the term vendor includes devices, servers, repositories, and / or any other devices capable of collecting and storing data associated with model training and transmitting / transmitting data associated with model training for encoders and / or decoders.

[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 EPC 160 via a backhaul link 132 (e.g., 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 5GC 190 via a backhaul link 184. The backhaul link 184 may be wired or wireless. In addition to other functions, base stations 102 can perform one or more of the following functions: transfer of 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, distribution of non-access stratum (NAS) messages, 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 distribution of warning messages. Base stations 102 can communicate with each other directly or indirectly (e.g., through EPC160 or 5GC190) via backhaul links 134 (e.g., X2 interfaces). Backhaul links 134 may be wired or wireless.

[0036]

[0071] Base station 102 can communicate wirelessly with UE 104. Each base station 102 can provide communication coverage for its respective geographical coverage area 110. Overlapping geographical coverage areas 110 may exist. 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 evolved node Bs (eNBs) (Home eNBs, HeNBs) that are capable of serving a limited group known as a closed subscriber group (CSG). The communication link 112 between base station 102 and UE 104 may include uplink (UL) transmission (also referred to as a reverse link) from UE 104 to base station 102, and / or downlink (DL) transmission (also referred to as a forward link) from base station 102 to UE 104. The communication link 112 may use multiple-input and multiple-output (MIMO) antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link may be through one or more carriers. Base station 102 / UE 104 may use a spectrum with a bandwidth of up to Y MHz per carrier (e.g., 5, 10, 15, 20, 100, 400 MHz, etc.) allocated in a carrier aggregation of up to Yx MHz (x component carriers) in total for transmission in each direction. These carriers may be adjacent or not adjacent to each other. Carrier allocation may be asymmetrical between DL and UL (for example, DL may be allocated more or fewer carriers than UL). Component carriers may include primary component carriers and one or more secondary component carriers.A primary component carrier may be called a primary cell (PCell), and a secondary component carrier may be called a secondary cell (SCell).

[0037]

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

[0038]

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

[0039]

[0074] Small cell 102' can operate in the licensed frequency spectrum and / or the unlicensed frequency spectrum. When operating in the unlicensed frequency spectrum, small cell 102' may employ NR and use the same 5GHz unlicensed frequency spectrum used by Wi-Fi AP150. By employing NR in the unlicensed frequency spectrum, small cell 102' can enhance coverage to the access network and / or increase the capacity of the access network.

[0040]

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

[0041]

[0076] The electromagnetic spectrum is often subdivided into various classes, bands, and channels based on frequency / wavelength. In 5G NR, two initial operating bands are identified as frequency range designations FR1 (410 MHz to 7.125 GHz) and FR2 (24.25 GHz to 52.6 GHz). Frequencies between FR1 and FR2 are often called intermediate 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. A similar nomenclature issue can 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 to 300 GHz) identified by the International Telecommunication Union (ITU) as the "millimeter wave" band.

[0042]

[0077] With the above aspects in mind, unless otherwise specifically stated, terms such as "sub-6GHz" may broadly refer to frequencies that are below 6GHz, within FR1, or may include intermediate band frequencies when used herein. Furthermore, unless otherwise specified, terms such as "millimeter wave" may broadly refer to frequencies that are within the intermediate band, within FR2, or within the EHF band when used herein. Communications using the mmW radio frequency band have extremely high path loss and short distances. The mmW base station 180 may utilize beamforming 182 in conjunction with UE 104 to compensate for path loss and short distances.

[0043]

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

[0044]

[0079] EPC160 may include a Mobility Management Entity (MME) 162, another MME 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. MME 162 can communicate with the Home Subscriber Server (HSS) 174. MME 162 is a control node that handles signaling between the UE 104 and EPC160. Generally, MME 162 provides bearer and connection management. All user Internet Protocol (IP) packets are forwarded through the serving gateway 166, which itself is connected to the PDN gateway 172. The PDN gateway 172 provides IP address assignment for the UE, as well as other functions. The PDN gateway 172 and BM-SC170 are connected to IP service 176. IP service 176 may include the Internet, intranet, IP Multimedia Subsystem (IMS), PS streaming service, and / or other IP services. BM-SC170 can provide functions for provisioning and delivering MBMS user services. BM-SC170 can act as an entry point for MBMS transmissions for content providers and can be used to authorize and initiate MBMS bearer services within a public land mobile network (PLMN), and can be used to schedule MBMS transmissions.The MBMS gateway 168 can be used to distribute MBMS traffic to base stations 102 that belong to a Multicast Broadcast Single Frequency Network (MBSFN) area broadcasting a specific service, and may be involved in session management (start / stop) and collection of eMBMS-related billing information.

[0045]

[0080] 5GC190 may include an Access and Mobility Management Function (AMF) 192, another AMF 193, a Session Management Function (SMF) 194, and a User Plane Function (UPF) 195. AMF 192 can communicate with Unified Data Management (UDM) 196. AMF 192 is a control node that handles signaling between UE 104 and 5GC190. Generally, AMF 192 provides QoS flow and session management. All user Internet Protocol (IP) packets are forwarded through UPF 195. UPF 195 provides IP address assignment for UEs and other functions. UPF 195 is connected to IP services 197. 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, advanced node B (eNB), access point, base transceiver station, radio base station, radio transceiver, transceiver function, basic service set (BSS), extended service set (ESS), transmit / receive point (TRP), or any other preferred term. Base station 102 provides access point to EPC160 or 5GC190 to UE104. Examples of UE104 include cellular phones, smartphones, session initiation protocol (SIP) phones, laptops, personal digital assistants (PDAs), satellite radios, global positioning systems, multimedia devices, video devices, digital audio players (e.g., MP3 players), cameras, game consoles, tablets, smart devices, wearable devices, vehicles, electric meters, gas pumps, large or small kitchen appliances, healthcare devices, implants, sensors / actuators, displays, or any other similar functional devices. Some of the UE104s may be called IoT devices (e.g., parking meters, gas pumps, toasters, vehicles, heart monitors, etc.). The UE104 may also be called a station, mobile station, subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, client, or any other suitable term.

[0047]

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

[0048]

[0083] Other wireless communication technologies may have different frame configurations and / or different channels. A frame (10 ms) can be divided into 10 subframes (1 ms) of equal size. Each subframe may contain one or more time slots. A subframe may also contain minislots, which may contain 7, 4, or 2 symbols. Each slot may contain 7 or 14 symbols, depending on the slot configuration. In slot configuration 0, each slot may contain 14 symbols, and in slot configuration 1, each slot may contain 7 symbols. Symbols on 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 referred to as single-carrier frequency-division multiple access (SC-FDMA) symbols) (for power-limited scenarios, i.e., when limited to single-stream transmission). The number of slots within a subframe depends on the slot configuration and numerology. Slot configuration 0 allows 1, 2, 4, 8, 16, and 32 slots per subframe, respectively, for different numerologies μ0-5. Slot configuration 1 allows 2, 4, and 8 slots per subframe, respectively, for different numerologies 0-2. Therefore, for slot configuration 0 and numerology μ, there are 14 symbols / slot and 2 μ There are 2 slots / subframes. Subcarrier interval and symbol length / duration are functions of numerology. The subcarrier interval is 2 μ*The subcarrier interval may be equal to 15 kHz, where μ is numerology 0 to 5. Therefore, numerology μ=0 has a subcarrier interval of 15 kHz, and numerology μ=5 has a subcarrier interval of 480 kHz. The symbol length / duration is inversely proportional to the subcarrier interval. Figures 2A to 2D provide examples of slot configuration 0 with 14 symbols per slot and numerology μ=0 with 1 slot per subframe. The subcarrier interval is 15 kHz, and the symbol duration is approximately 66.7 μs.

[0049]

[0084] A resource grid can be used to represent the frame structure. Each time slot contains a resource block (RB) (also called physical RBs, PRBs) spanning 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 signals (RS) related to the UE. 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 signals (CSI-RS) for channel estimation in the UE. RS may also include beam measurement RS (BRS), beam refinement RS (BRRS), and phase tracking RS (PT-RS).

[0051]

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

[0052]

[0087] As shown in Figure 2C, some of the REs carry DM-RS (shown as R for one particular configuration, but 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). PUSCH DM-RS may be transmitted within the first one or two symbols of the PUSCH. PUCCH DM-RS may be transmitted in different configurations depending on whether a short or long PUCCH is transmitted and 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] Figure 2D shows an example of various UL channels within a frame subframe. In one configuration, the PUCCHs may be arranged as shown. The PUCCHs carry 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 PUCCHs carry data and may additionally be used to carry buffer status reports (BSR), power headroom reports (PHR), and / or UCI.

[0054]

[0089] Figure 3 is a block diagram showing the communication between the base station / network entity vendor 310 and the UE / UE vendor 350 in the access network. In the DL, IP packets from the EPC 160 can be provided to the controller / processor 375. The controller / processor 375 implements Layer 3 and Layer 2 functions. Layer 3 includes the Radio Resource Control (RRC) layer, and Layer 2 includes the Service Data Adaptation Protocol (SDAP) layer, the Packet Data Convergence Protocol (PDCP) layer, the Radio Link Control (RLC) layer, and the Medium Access Control (MAC) layer. The controller / processor 375 includes RRC layer functions associated with broadcasting system information (e.g., MIB, SIB), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection correction, and RRC connection release), mobility between radio access technologies (RATs), and measurement settings 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 upper-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 sorting of RLC data PDUs; and mapping between logical channels and transport channels, multiplexing MAC SDUs onto transport blocks (TBs), and MAC from TBs. It provides MAC layer functionality associated with SDU demultiplexing, scheduling information reporting, error correction via HARQ, priority processing, and logical channel prioritization.

[0055]

[0090] The transmit (Tx) processor 316 and the receive (Rx) processor 370 implement Layer 1 functions 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 to the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. The Tx processor 316 processes mapping to a signal constellation 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 encoded and modulated symbols can then be divided into parallel streams. Next, each stream can be mapped to an OFDM subcarrier, multiplexed with a reference signal (e.g., a pilot) in the time domain and / or frequency domain, and then combined together using an Inverse Fast Fourier Transform (IFFT) to generate a physical channel that carries the time-domain OFDM symbol stream. This OFDM stream is spatially precoded to generate multiple spatial streams. The channel estimate from the channel estimator 374 can be used to determine the coding and modulation scheme and for spatial processing. The channel estimate can be derived from the reference signal and / or channel state feedback transmitted by the UE 350. Each spatial stream can then be provided to different antennas 320 via separate transmitters 318Tx. Each transmitter 318Tx can modulate the RF carrier on its respective spatial stream for transmission.

[0056]

[0091] In UE350, each receiver 354Rx receives signals through its respective antenna 352. Each receiver 354Rx reconstructs the information modulated on the RF carrier and provides this information to the receiver (Rx) processor 356. The Tx processor 368 and Rx processor 356 implement Layer 1 functions associated with various signal processing functions. The Rx processor 356 may perform spatial processing on the information to reconstruct any spatial stream destined for UE350. Multiple spatial streams destined for UE350 may be combined into a single OFDM symbol stream by the Rx processor 356. The Rx processor 356 then uses a Fast Fourier Transform (FFT) to convert the OFDM symbol stream from the time domain to the frequency domain. The frequency domain signal contains a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, and the reference signal, are reconstructed and demodulated by determining the most likely signal constellation point transmitted by the base station 310. These soft decisions can be obtained based on channel estimates calculated by the channel estimator 358. The soft decisions are then decoded and deinterleaved to reconstruct the data and control signals initially transmitted by the base station 310 on the physical channel. These data and control signals are then provided to the controller / processor 359, which implements Layer 3 and Layer 2 functions.

[0057]

[0092] The controller / processor 359 may be associated with memory 360 for storing program code and data. Memory 360 may be referred to as computer-readable media. In UL, the controller / processor 359 provides demultiplexing of transport and logical channels, packet reassembly, decoding, header decompression, and control signal processing to recover IP packets from EPC160 or 5GC190. The controller / processor 359 also participates in error detection using the ACK and / or NACK protocols to support HARQ operation.

[0058]

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

[0059]

[0094] The channel estimate 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 and to facilitate spatial processing. The spatial stream generated by the Tx processor 368 may be provided to different antennas 352 via separate transmitters 354Tx. Each transmitter 354Tx can modulate the RF carrier in its respective spatial stream for transmission.

[0060]

[0095] UL transmission is processed at base station 310 in a manner similar to that described for receiver functions in UE350. Each receiver 318Rx receives the signal through its corresponding antenna 320. Each receiver 318Rx reconstructs the information modulated on the RF carrier and provides this information to Rx processor 370.

[0061]

[0096] The controller / processor 375 may be associated with memory 376 that stores program code and data. Memory 376 may be referred to as computer-readable media. In UL, the controller / processor 375 provides demultiplexing of transport and logical channels, packet reassembly, decoding, header decompression, and control signal processing to recover IP packets from the UE350. IP packets from the controller / processor 375 may be supplied to the EPC160. The controller / processor 375 also participates in error detection using the ACK and / or NACK protocols to support HARQ operation.

[0062]

[0097] At least one of the TX processor 368, RX processor 356, and controller / processor 359 may be configured to perform an embodiment related to the UE training component 140 in Figure 1.

[0063]

[0098] At least one of the TX processor 316, RX processor 370, and controller / processor 375 may be configured to implement an embodiment related to the network training component 120 shown in Figure 1.

[0064]

[0099] Figure 4 shows an exemplary unaggregated base station 102 architecture, which may be one form of the network entity 102 or base station 400 described herein. The unaggregated base station 400 architecture may include one or more central units (CUs) 410 that can communicate directly with the core network 420 via backhaul links, or indirectly with the core network 420 through one or more unaggregated base station units (e.g., a quasi-real-time (quasi-RT) RAN Intelligent Controller (RIC) 425 via 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 can communicate with one or more distributed units (DUs) 430 via their respective midhaul links, such as an F1 interface. The DUs 430 can communicate with one or more radio units (RUs) 440 via their respective fronthaul links. The RU440 can communicate with each UE104 via one or more radio frequency (RF) access links. In some implementations, the UE104 can be serviced simultaneously by multiple RU440s.

[0065]

[0100] Each of the units, namely CU410, DU430, RU440, and the quasi-RT RIC425, non-RT RIC415, 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 communication interface of a unit, may be configured to communicate with one or more of the other units over a transmission medium. For example, a unit 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, those units may include a wireless interface that may include a receiver, transmitter, or transceiver (such as a radio frequency (RF) transceiver) configured to receive or transmit or receive signals over a wireless transmission medium to one or more of the other units.

[0066]

[0101] In some embodiments, the CU410 may host one or more higher-layer control functions. Such control functions may include Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Service Data Adaptive Protocol (SDAP), etc. Each control function may be implemented using an interface configured to communicate signals with other control functions hosted by the CU410. The CU410 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 CU410 may be logically divided into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP units may communicate bidirectionally with the CU-CP units via an interface such as the E1 interface. The CU410 can be implemented to communicate with the DU430 as needed for network control and signaling.

[0067]

[0102] The DU430 may correspond to a logic unit containing one or more base station functions for controlling the operation of one or more RU440s. In some embodiments, the DU430 may host one or more of the following, at least in part, depending on a functional decomposition such as that defined by the Third Generation Partnership Project (3GPP): the Radio Link Control (RLC) layer, the Media Access Control (MAC) layer, and one or more higher physical (PHY) layers (such as modules related to forward error correction (FEC) coding and decoding, scrambling, modulation and demodulation). In some embodiments, the DU430 may further host one or more low PHY layers. Each layer (or module) may be implemented using an interface configured to communicate signals with other layers (and modules) hosted by the DU430, or with control functions hosted by the CU410.

[0068]

[0103] Lower-layer functions can be implemented by one or more RU440s. In some deployments, RU440s controlled by DU430s 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, at least partially based on functional partitioning such as lower-layer functional partitioning. In such architectures, RU440s can be implemented to handle over-the-air (OTA) communication with one or more UE104s. In some implementations, real-time and non-real-time modes of control and user-plane communication with the RU440s can be controlled by the corresponding DU430s. In some scenarios, this configuration can enable the DU430 and CU410 to be implemented in cloud-based RAN architectures such as vRAN architectures.

[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 the deployment of dedicated physical resources for RAN coverage requirements, which can be managed via operational and maintenance interfaces (such as the O1 interface). For virtualized network elements, the SMO framework 405 may be configured to interact with a cloud computing platform (such as the open cloud (O-cloud) 490) and perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface (such as the O2 interface). Such virtualized network elements may include, but are not limited to, the CU410, DU430, RU440, and quasi-RT RIC425. In some implementations, the SMO framework 405 may communicate with hardware embodiments of the 4G RAN, such as the open eNB (O-eNB) 411, via the O1 interface. Additionally, in some implementations, the SMO framework 405 can communicate directly with one or more RU440s via the O1 interface. The SMO framework 405 may also include a non-RT RIC415 configured to support the functionality of the SMO framework 405.

[0070]

[0105] Non-RT RIC415 may be configured to include logical 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 updating, or policy-based guidance for applications / features in quasi-RT RIC425. Non-RT RIC415 may be coupled to quasi-RT RIC425 or communicate with quasi-RT RIC425 (e.g., via the A1 interface). Quasi-RT RIC425 may be configured to include logical functions that enable quasi-real-time control and optimization of RAN elements and resources via data acquisition and actions through one or more CU410s, one or more DU430s, or both, and an interface connecting the O-eNB to quasi-RT RIC425 (e.g., via the E2 interface).

[0071]

[0106] In some implementations, the non-RT RIC415 may receive parameter or external enrichment information from an external server to generate an AI / ML model deployed to the quasi-RT RIC425. Such information may be utilized by the quasi-RT RIC425 and may be received in the SMO framework 405 or the non-RT RIC415 from a non-network data source or from a network function. In some examples, the non-RT RIC415 or quasi-RT RIC425 may be configured to tune RAN behavior or performance. For example, the non-RT RIC415 may monitor long-term trends and patterns in performance and employ AI / ML models to 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] Figure 5 shows an example of a communication system including a UE vendor and a gNB vendor. For example, UE vendor 502 may serve multiple UEs, such as UE104 in Figure 1, and correspond to UE vendor 316 in Figure 3. UE vendor 502 may be configured for data collection from multiple UE104 with which it is communicating directly. Multiple UE104 may be linked to UE vendor 502 wirelessly or via wired connections. UE vendor 502 may be directly and / or indirectly linked to gNB vendor 504 (506). gNB vendor 504 may be directly and / or indirectly linked to multiple gNBs, such as base station 102 in Figure 1, and correspond to network entity vendor 310 in Figure 3. UE vendor 502 and gNB vendor 504 may perform data collection and online / offline training for channel state information (CSI) feedback (CSF) compression for communication between UE104 and gNB102.

[0073]

[0108] In one embodiment, a UE vendor 502 may initiate UE-based training for multiple UEs 104 associated with it. For example, UE vendor 502 may request a UE 104 to collect data for model training. In some cases, the request may arise via a UE application running on the UE 104. In response to receiving the request, the UE 104 sends a request via communication link 112 to a gNB, such as the base station 102 in Figure 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 embodiment, UE vendor 502 may initiate model training and coordinate with gNB vendor 504. In another embodiment, UE vendor 502 may perform area-based training by directly sending a request to gNB vendor 504 to initiate model training. gNB vendor 502 may request gNB 102 to configure the model training and select an appropriate UE 104 for training data collection based on UE type, UE capability, and user consent.

[0075]

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

[0076]

[0111] For example, in cross-node machine learning (ML), a neural network (NN) is divided into two parts: an encoder 602 on a UE such as UE104, and a decoder 604 on a gNB such as base station 102. The encoder output from UE104 is sent to gNB102 as input to decoder 604. In one example, encoder 602 on UE104 outputs a compressed CSF606 which is input to decoder 604 on gNB102. Decoder 604 on gNB102 outputs a reconstructed CSF608, such as a precoded vector. To train encoder 602 and decoder 604, a UE vendor such as UE vendor 502 in Figure 5 can train both models using its own dataset and share the trained decoder model with a gNB vendor such as gNB vendor 504.

[0077]

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

[0078]

[0113] In one embodiment, the decoder 604 output includes the downlink channel matrix (H), the transmit covariance matrix, the downlink precoder (V), and the interference covariance matrix (R). nn ), and at least one of the following: a raw-to-whitened downlink channel.

[0079]

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

[0080]

[0115] In one embodiment, an access network such as access network 100 in Figure 1 may include one or more heterogeneous UEs (different baseband and RF implementations, different antennas, different OEMs), such as UE104, and heterogeneous channel statistics across cells. In this embodiment, a single encoder-decoder may not achieve a performance level above a certain acceptable threshold across all scenarios. In these cases, UE104 participating in data acquisition tags the acquired data with metadata describing the data acquisition scenario originating from both gNB102 and UE104. For example, metadata from gNB102 may include gNB antenna configuration, CSI-RS beam configuration, etc. Furthermore, gNB102 metadata may be provided to UE104 with respect to a "gNB Meta ID," but without revealing the gNB implementation. Metadata from UE104 may include UE antenna configuration, SNR, RSRP, delay spread, mean delay, timestamp, etc. UE104 can decompose UE metadata into a "UE Meta ID" that the UE vendor does not wish to disclose to the gNB vendor 504, and the rest of the UE metadata.

[0081]

[0116] In one aspect, in UE server / UE vendor 502, N data sets are collected from a plurality of UEs 104 participating in data collection. For example, UE server / UE vendor 502 may combine N data sets into L (<N) data sets according to 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, UE vendor 502 can obtain M training sets from M trained encoder-decoder pairs to be shared with gNB vendor 504 by training M encoder-decoder pairs and executing an inner loop procedure M times. 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 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, 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 encoder 602 in FIG. 6, z corresponds to a latent vector, for example, compressed CSI, and z = q φ (H) is calculated based on. p θ corresponds to a decoder such as decoder 604 in FIG. 6,

[0083]

Number

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

[0085]

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

[0086]

[0119] In one embodiment, an alternative procedure for UE vendor-driven offline training of cross-node ML may include the following steps: In the first step, on the server of UE vendor 502, UE vendor 502 uses the raw dataset of UE vendor 502 to perform encoder-decoder pairs (q φ ,p θ ) is trained. In the second step, after the encoder-decoder pair has been trained, UE vendor 502 runs encoder 602 and decoder 604 using two training sets, namely the raw dataset of UE vendor 502, to train the first training set {( encoder ID, z,

[0087]

number

[0088] (z)}} and a second training set {(encoderID, z+ε, p) obtained by perturbing the encoder 602 output with a small vector and calculating the corresponding decoder 604 output. θ (z+ε)} is generated, where z corresponds to the output of encoder 602 and V corresponds to the desired output of decoder 604.

[0089]

number

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

[0091]

[0120] In one embodiment, an alternative procedure for UE vendor-driven offline training of cross-node ML may include the following steps: In the first step, on the server of UE vendor 502, UE vendor 502 uses the raw dataset of UE vendor 502 to perform encoder-decoder pairs (q φ ,p θ ) is trained. In the second step, after the encoder-decoder pair is trained, UE vendor 502 generates two training sets, namely, a first training set {(encoder ID, z)} by running encoder 602 using UE vendor 502's raw dataset, 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 the third step, UE vendor 502 responds to the two training sets by p θ The found decoder p θ Find an alternative decoder f that approximates the original. p θ (z+ε)=f(z+ε) and p θ (z)=f(z)

[0092]

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

[0093]

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

[0094]

number

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

[0096]

[0123] Figure 8 is Message Figure 800, which shows exemplary messages for a data collection procedure for CSF compression. For example, Figure 800 shows messaging between a UE vendor such as UE vendor 502 in Figure 5, a UE such as UE104 in Figure 1, and a gNB such as base station 102 in Figure 1.

[0097]

[0124] In one embodiment, 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, in response to receiving the training data request, the gNB 102 may send a data acquisition configuration to the UE 104. For example, information regarding the data acquisition configuration message may include at least one of the following: a reference signal (RS) such as CSI-RS, a list for data acquisition, an area for data acquisition, a period for data acquisition, a network-side configuration, a channel type, and a process ID related to data acquisition. In some cases, the configured RS may be dynamically activated / deactivated by the gNB 102 via a media 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 the network entity for data acquisition. The meta-ID may correspond to the CSI-RS beam configuration, or antenna configuration including antenna layout, mapping from antenna elements to TxRU, and digital / analog beamforming. In some cases, the signaling of the data acquisition configuration may correspond to the reuse of MDT configuration signaling, or as informational elements (IEs) in the RRCReconfiguration message.

[0098]

[0125] In step 808, UE104 may send a data acquisition configuration acknowledgment (ACK) to gNB102 to indicate successful reception of the data acquisition configuration. Then, in step 810, UE104 may perform data acquisition with gNB102. Once data acquisition is complete, UE104 may upload the collected data to UE vendor 502 in step 812.

[0099]

[0126] Figure 9 is a conceptual diagram 900 showing an exemplary frame structure for uploading data. For example, UE104 may send a data report to UE vendor 502 in response to performing data collection between UE104 and gNB102, as shown in some instances 902, 904, 906, and 908.

[0100]

[0127] In one embodiment, the UE report may include {H_raw, meta_id}, where H_raw is a channel estimate relating to the RB index, port index, and Rx index, and Meta_id has the following hierarchy: data package ID (which may be generated using the data process ID), cell / carrier ID, CSI-RS resource ID (implicitly carrying the 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., a CSI-RS transmission instance or slot index, or a measurement period index (e.g., a record is based on measurements over a period, and the period should be composed of these), gNB102 can dynamically change the antenna mapping / layout, and the timestamp is required to label the reported data with the correct antenna mapping / layout. Furthermore, each record includes SNR, SINR or RSRP, subcarrier spacing, and Doppler / delay spread measurements.

[0101]

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

[0102]

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

[0103]

[0130] In one embodiment, 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 acquisition configuration to the UE 104. For example, information regarding a data acquisition configuration message may include at least one of the following: a reference signal (RS) such as CSI-RS, a list for data acquisition, an area for data acquisition, a period for data acquisition, a network-side configuration, a channel type, and a process ID related to data acquisition. In some cases, the configured RS may be dynamically activated / deactivated by the gNB 102 via a media 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 data acquisition configuration signaling may correspond to reusing MDT configuration signaling, or it may correspond as information elements (IEs) to an RRCReconfiguration message.

[0104]

[0131] In step 1006, UE104 may send a data acquisition configuration ACK to gNB102 in response to receiving the data acquisition configuration. In some cases, UE104 may reject the data acquisition request and instead send a model training configuration rejection message to gNB102. Then, in step 1008, UE104 may perform data acquisition with gNB102. In step 1010, training data may be reported between UE vendor 502, UE104, gNB102 and model / data repository 504.

[0105]

[0132] Figure 11 is Message Figure 1100, which shows exemplary messages for a step in reporting training data during the data collection procedure for CSF compression. For example, Figure 1100 shows specific messaging that takes place during step 1010 in Figure 10 between a UE vendor such as UE vendor 502 in Figure 5, a UE such as UE104 in Figure 1, a gNB such as base station 102 in Figure 1, and a data repository / collection entity such as gNB vendor 504 in Figure 5.

[0106]

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

[0107]

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

[0108]

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

[0109]

[0136] Figure 12 is Message Figure 1200, which shows exemplary messages for a data collection procedure for CSF compression. For example, Figure 1200 shows messaging between a UE vendor, such as UE vendor 502 in Figure 5, a UE, such as UE104 in Figure 1, a gNB, such as base station 102 in Figure 1, and a data repository / collection entity, such as gNB vendor 504 in Figure 5.

[0110]

[0137] In one embodiment, in step 1202, data reporting 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, information in the data collection configuration message may include at least one of the following: an RS such as a CSI-RS, a list for data collection, an area for data collection, a period for data collection, a network-side configuration, a channel type, and a process ID related to data collection. In some cases, the configured RS may be dynamically activated / deactivated by the gNB 102 via 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 acquisition. The meta ID may correspond to the CSI-RS beam configuration, or antenna layout, mapping from antenna elements to TxRU, and antenna configuration including digital / analog beamforming. In some cases, the signaling of the data acquisition configuration may correspond to reusing the MDT configuration signaling, or to an IE for the RRCReconfiguration message.

[0111]

[0138] In step 1208, UE104 may send a data collection configuration ACK to gNB102 in response to receiving the data collection configuration. Then, in step 1210, UE104 may perform data collection with gNB102. In step 1212, the data may be uploaded to UE vendor 502. In step 1214, UE vendor 502 may upload the data to data repository collection entity 504.

[0112]

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

[0113]

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

[0114]

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

[0115]

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

[0116]

[0143] Figure 16 is Message Figure 1600, which shows an example message for data acquisition procedures and offline model training for CSF compression using area-based training in the UE. For example, Figure 1700 shows messaging between a UE vendor such as UE vendor 502 in Figure 5, a UE such as UE104 in Figure 1, a gNB such as base station 102 in Figure 1, model manager / OAM1602, and model / data repository 504, both of which are associated with and / or part of gNB vendor 504 in Figure 5.

[0117]

[0144] In one embodiment, in step 1604, an MLF for CSF compression is defined and registered across UE vendor 502, UE104, gNB102, model manager / OAM1602, and model / data repository 504. For example, UE vendor 502 registers its CSF model with the network, such as gNB102 and / or gNB vendor 504. In some cases, 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 if multiple models are registered. For example, model training is initiated by UE vendor 502. In some cases, model training is coordinated by model manager / OAM1602, which may correspond to OAM, RIC (ORAN Defined Network Entity, Intelligent Network Controller), CU-XP, or gNB such as gNB102, depending on the deployment scenario and use case.

[0118]

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

[0119]

[0146] In step 1608, the model / data repository 504 may send a model training start message to the model manager / OAM 1602. In 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 in step 1606. In step 1612, the model manager / OAM 1602 sends the model training request 1612 to the gNB 102. In step 1614, the gNB 102 performs UE selection and may send the model training configuration to the UE 104 in step 1616. In step 1618, the UE 104 may send a model training configuration ACK to the gNB 102. In step 1620, the gNB 102 sends a model training response to the model manager / OAM 1602.

[0120]

[0147] For example, UE104 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 absolute time, relative time, or SFN + time slot + (optional) symbol, location information such as GNSS and radio fingerprints, i.e., RSRP / RSRQ measurements of serving and adjacent cells, if available, and metadata such as RS type, ID, and NM_ID. In some cases, model training can be obtained based on previously collected data without metadata. The received configuration information can be used as metadata and reported to the UE vendor 502 server. In this case, actual data collection and reporting may be skipped. In step 1622, UE104 performs data collection. In step 1624, having performed data collection, UE104 reports the training data to UE vendor 502. In step 1626, having received the training data report, UE vendor 502 performs model training.

[0121]

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

[0122]

[0149] Figure 17 is a message diagram 1700 showing exemplary messages for data acquisition procedures and offline model training for CSF compression using a UE-based configuration in the UE. For example, Figure 1700 shows messaging between a UE vendor such as UE vendor 502 in Figure 5, a UE such as UE104 in Figure 1, a gNB such as base station 102 in Figure 1, a model manager / OAM 1602, and a model / data repository 504, both of which are associated with and / or part of the gNB vendor 504 in Figure 5.

[0123]

[0150] In one embodiment, in step 1702, an MLF for CSF compression is defined and registered across UE vendor 502, UE104, gNB102, model manager / OAM1602, and model / data repository 504. For example, UE vendor 502 registers its CSF model with the network, such as gNB102 and / or gNB vendor 504. In some cases, 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 if multiple models are registered. For example, model training is initiated by UE vendor 502. In some cases, model training is coordinated by the model manager / OAM1602, which may correspond to OAM, RIC (ORAN Defined Network Entity, Intelligent Network Controller), CU-XP, or gNB such as gNB102, depending on the deployment scenario and use case.

[0124]

[0151] In a UE104-based training example, UE vendor 502 requests UE104 to collect data for model training via a UE application or the like. UE104 sends requests to gNB102 and model manager 1602 for gNB102 to configure UE104 for training data collection. For example, in step 1704, UE vendor 504 may send a training data request to UE104. In step 1706, UE104 may send a model training request message to gNB102. In step 1708, gNB102 may forward the model training request message to model manager / OAM1602. In the model training configuration, the network, including gNB102, transmits metadata and data collection information for model training. For example, information regarding data collection may include a list of RSs (e.g., CSI-RS) for data collection, and configured RSs may be dynamically activated / deactivated by the gNB via, for example, MAC CE or DCI, the area for data collection, and the period for data collection. In some cases, metadata may include NM IDs (associated with network-side mode IDs), network-side configuration, and additional information such as channel type, so that data for different NM IDs can be used separately for model training. In some cases, signaling may include the reuse of MDT configuration signaling, where configuration information is added to the RRCReconfiguration message as IE, or a new signaling procedure.

[0125]

[0152] In step 1710, gNB102 and Model Manager / OAM1602 may authorize UE104 for CSF model training. Once authorization is complete, Model Manager / OAM1602 may send a model training request to gNB102 in step 1712. In step 1714, gNB102 may send a model training configuration to UE104. In step 1716, UE104 may send a model training configuration ACK to gNB102 in response to receiving the model training configuration message. In step 1718, gNB102 sends a model training response to Model Manager / OAM1602.

[0126]

[0153] For example, UE104 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 absolute time, relative time, or SFN + time slot + (optional) symbol, location information such as GNSS and radio fingerprints, i.e., RSRP / RSRQ measurements of serving and adjacent cells, if available, and metadata such as RS type, ID, and NM_ID. In some cases, model training can be obtained based on previously collected data without metadata. The received configuration information can be used as metadata and reported to the UE vendor 502 server. In this case, actual data collection and reporting may be skipped. In step 1720, UE104 performs data collection. In step 1722, UE104 sends a training data report to UE vendor 502. In step 1724, UE vendor 502 performs model training.

[0127]

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

[0128]

[0155] Figure 18 is a conceptual diagram 1800 showing an exemplary frame structure for uploading data. For example, UE104 may send a data report to UE vendor 502 in response to performing data collection between UE104 and gNB102, as shown in some instances 1802, 1804, 1806, and 1808.

[0129]

[0156] In one embodiment, the UE report may include {H_raw,meta_id}, where H_raw is a channel estimate relating to the RB index, port index, and Rx index, and Meta_id has the following hierarchy: cell ID, CSI-RS resource ID (implicitly conveying antenna mapping / layout), each record includes a timestamp, e.g., CSI-RS transmission instance or slot index, or measurement period index (e.g., a record is based on a measurement over a period, the period should be composed of), gNB102 can dynamically change the antenna mapping / layout, and the timestamp is required to label the reported data with the correct antenna mapping / layout, including a list of records {recorde#1,record#2, etc.}, SNR, SINR, or RSRP, subcarrier spacing, and Doppler / delay spread measurement.

[0130]

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

[0131]

[0158] Figure 19 is a message diagram 1900 showing an example message for data acquisition procedures and offline model training for CSF compression using area-based training in a UE. For example, Figure 1900 shows messaging between a UE vendor such as UE vendor 502 in Figure 5, a UE such as UE104 in Figure 1, a gNB such as base station 102 in Figure 1, a model manager / OAM1602, and a model / data repository 504, both of which are associated with and / or part of the gNB vendor 504 in Figure 5.

[0132]

[0159] In one embodiment, in step 1902, an MLF for CSF compression is defined and registered across UE vendor 502, UE104, gNB102, model manager / OAM1602, and model / data repository 504. For example, UE vendor 502 registers its CSF model with the network, such as gNB102 and / or gNB vendor 504. In some cases, 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 if multiple models are registered. For example, model training is initiated by UE vendor 502. In some cases, model training is coordinated by the model manager / OAM1602, which may correspond to OAM, RIC (ORAN Defined Network Entity, Intelligent Network Controller), CU-XP, or gNB such as gNB102, 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. 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 the 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 the UE model delivery to the UE vendor 502.

[0134]

[0161] Figure 20 is a message diagram 2000 showing an example message for data acquisition procedures and offline model training for CSF compression using UE-based training in a UE. For example, Figure 2000 shows messaging between a UE vendor such as UE vendor 502 in Figure 5, a UE such as UE104 in Figure 1, a gNB such as base station 102 in Figure 1, a model manager / RIC2002, and a model / data repository 504, both of which are associated with and / or part of the gNB vendor 504 in Figure 5.

[0135]

[0162] In one embodiment, in step 2004, an MLF for CSF compression is defined and registered across UE vendor 502, UE104, gNB102, model manager / RIC2002, and model / data repository 504. For example, UE vendor 502 registers its CSF model with the network, such as gNB102 and / or gNB vendor 504. In some cases, 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 if multiple models are registered. For example, model training is initiated by UE vendor 502. In some cases, model training is coordinated by model manager / RIC2002, which may correspond to an OAM, RIC (ORAN Defined Network Entity, Intelligent Network Controller), CU-XP, or gNB such as gNB102, 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 / RIC2002. In step 2008, the model manager / RIC2002 performs UE selection. In step 2010, the model manager / RIC2002 forwards the model training request to the gNB102. In step 2012, the gNB102 sends the model training configuration to the UE104. In step 2014, the UE104 sends a model training configuration ACK to the gNB102. In step 2016, the gNB102 sends a model training response to the model manager / RIC2002. 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 the UE model delivery to the UE vendor 502.

[0137]

[0164] Figure 21 is Message Figure 2100, which shows exemplary messages for a step in reporting training data during the data acquisition procedure for CSF compression. For example, Figure 2100 shows specific messaging that takes place during step 1916 in Figure 19 and step 2018 in Figure 20 between a UE vendor such as UE vendor 502 in Figure 5, a UE such as UE104 in Figure 1, a gNB such as base station 102 in Figure 1, a model manager 1602, and a model / data repository such as gNB vendor 504 in Figure 5. In one example, the data to be reported may include UE model information such as channel matrix, MS ID and PS ID, as well as NM ID and timestamp.

[0138]

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

[0139]

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

[0140]

[0167] In one embodiment, the data collected by the UE may be used to train both models on the network side. For example, data collection may be performed 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 in Figure 21. Furthermore, model training may be performed, similar to 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] Figure 22 is a conceptual data flow diagram 2200 showing data flow between different means / components in an exemplary base station 2202, which may be an example of a base station 102 including 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 the signals described herein. The transmitter component 2252 may include, for example, an RF transmitter for transmitting the 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 / RX318 in Figure 3.

[0143]

[0170] Figure 23 is a conceptual data flow diagram 2300 showing the data flow between different means / components in an exemplary UE2304, which may be an example of UE104 and may include a UE training component 140. As described with respect to Figure 1, the UE training component 140 may include a data acquisition component 142.

[0144]

[0171] UE104 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 the signals described herein. The transmitter component 2372 may include, for example, an RF transmitter for transmitting the signals 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 / RX354 in Figure 3.

[0145]

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

[0146]

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

[0147]

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

[0148]

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

[0149]

[0176] In some implementations, each of the one or more training sets includes encoder identification information (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 allow switching between one or more models during inference.

[0151]

[0178] In some implementations, one or more metadata items include at least one of the following: UE antenna configuration, signal-to-noise ratio (SNR), reference signal receive power (RSRP), delay rate, mean delay, and timestamp.

[0152]

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

[0153]

[0180] In some implementations, the encoder outputs of one or more encoders correspond to compressed channel state information (CSI) feedback (CSF) messages.

[0154]

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

[0155]

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

[0156]

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

[0157]

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

[0158]

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

[0159]

[0186] In some implementations, generating two training sets further involves generating a first training set based on the encoder and decoder outputs using the UE vendor's raw dataset.

[0160]

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

[0161]

[0188] In some implementations, generating two training sets further involves generating a second training set based on perturbing the encoder output in the first training set with a vector and computing the corresponding decoder output.

[0162]

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

[0163]

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

[0164]

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

[0165]

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

[0166]

[0193] In some implementations, the encoder outputs of one or more encoders correspond to compressed channel state information (CSI) feedback (CSF) messages.

[0167]

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

[0168]

[0195] Figure 26 is a flowchart of an exemplary method 2600 for a network entity vendor for cross-node machine learning training. Method 2600 can be performed by a network entity vendor such as a network entity / gNB vendor 316 / 504 (which may include memory 376 and may be components 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] In block 2610, method 2600 includes receiving one or more training sets from a UE vendor corresponding to one or more encoder-decoder pairs. In some implementations, for example, a network entity / gNB vendor 316 / 504, a Tx processor 316, or a controller / processor 375 may be configured to receive one or more training sets from a UE vendor, each corresponding to one or more encoder-decoder pairs. Thus, a network entity / gNB vendor 316 / 504, a Tx processor 316, or a controller / processor 375 can provide means for receiving one or more training sets from a UE vendor corresponding to one or more encoder-decoder pairs.

[0170]

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

[0171]

[0198] In some implementations, each of the one or more training sets includes encoder identification information (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 allow switching between one or more models during inference.

[0173]

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

[0174]

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

[0175]

[0202] Figure 27 is a flowchart of an exemplary method 2700 for a network entity vendor for cross-node machine learning training. Method 2700 can be performed by a network entity vendor such as a network entity / gNB vendor 316 / 504 (which may include memory 376 and may be components 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] In block 2710, method 2700 includes receiving two training sets from a UE vendor, each corresponding to one or more encoder-decoder pairs. In some implementations, for example, a network entity / gNB vendor 316 / 504, a Tx processor 316, or a controller / processor 375 may be configured to receive two training sets from a UE vendor, each corresponding to one or more encoder-decoder pairs. Thus, a network entity / gNB vendor 316 / 504, a Tx processor 316, or a controller / processor 375 can provide means for receiving two training sets from a UE vendor, each corresponding to one or more encoder-decoder pairs.

[0177]

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

[0178]

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

[0179]

[0206] In some implementations, the second training set includes the encoder ID, combinations of encoder outputs and vectors, and the 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 the decoder found in one of the one or more encoder-decoder pairs.

[0181]

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

[0182]

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

[0183]

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

[0184]

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

[0185]

[0212] Figure 28 is a flowchart of an exemplary method 2800 for a UE to perform a CSF data acquisition procedure. Method 2800 can be performed by a UE (which may include memory 360 and may be the entire UE104, or components of the UE104 such as the TX processor 368, the Rx processor 356, or the controller / processor 359).

[0186]

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

[0187]

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

[0188]

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

[0189]

[0216] In block 2840, method 2800 includes sending a data acquisition configuration acknowledgment (ACK) to a network entity in response to receiving a data acquisition configuration message. In some implementations, for example, UE104, Rx processor 356, or controller / processor 359 may be configured to send a data acquisition configuration acknowledgment (ACK) to a network entity in response to receiving a data acquisition configuration message. Thus, UE104, Rx processor 356, or controller / processor 359 may provide means for sending a data acquisition configuration acknowledgment (ACK) to a network entity in response to receiving a data acquisition configuration message.

[0190]

[0217] In block 2850, method 2800 includes executing a data acquisition procedure based on a data acquisition configuration message. In some implementations, for example, UE104, Rx processor 356, or controller / processor 359 may be configured to execute a data acquisition procedure based on a data acquisition configuration message. Thus, UE104, Rx processor 356, or controller / processor 359 may provide means for executing a data acquisition procedure based on a data acquisition configuration message.

[0191]

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

[0192]

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

[0193]

[0220] In some implementations, the process ID corresponds to the model ID registered in the 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 uploads that corresponds to one or more metadata based on the process ID.

[0195]

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

[0196]

[0223] In some implementations, one or more data points correspond to a UE report that includes a downlink raw channel matrix and metadata identifiers (meta IDs).

[0197]

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

[0198]

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

[0199]

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

[0200]

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

[0201]

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

[0202]

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

[0203]

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

[0204]

[0231] In block 2920, method 2900 includes sending a data acquisition configuration message to the UE in response to receiving a 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 send a data acquisition configuration message to the UE in response to receiving a training data request. Thus, the network entity 102, the Tx processor 316, or the controller / processor 375 may provide means for sending a data acquisition configuration message to the UE in response to receiving a training data request.

[0205]

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

[0206]

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

[0207]

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

[0208]

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

[0209]

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

[0210]

[0237] In some implementations, sending a data acquisition configuration message further includes sending the data acquisition configuration message as at least one of the information elements in a Radio Resource Control (RRC) reconfiguration message or a new signaling procedure.

[0211]

[0238] Figure 30 is a flowchart of an exemplary method 3000 for a UE to perform a CSF data acquisition procedure. Method 3000 can be performed by a UE (which may include memory 360 and may be the entire UE104, or components of UE104 such as the TX processor 368, the Rx processor 356, or the controller / processor 359).

[0212]

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

[0213]

[0240] In block 3020, method 3000 includes sending a data acquisition configuration acknowledgment (ACK) to a network entity in response to receiving a data acquisition configuration message. In some implementations, for example, UE104, Rx processor 356, or controller / processor 359 may be configured to send a data acquisition configuration acknowledgment (ACK) to a network entity in response to receiving a data acquisition configuration message. Thus, UE104, Rx processor 356, or controller / processor 359 may provide means for sending a data acquisition configuration acknowledgment (ACK) to a network entity in response to receiving a data acquisition configuration message.

[0214]

[0241] In block 3030, method 3000 includes executing a data acquisition procedure based on a data acquisition configuration message. In some implementations, for example, UE104, Rx processor 356, or controller / processor 359 may be configured to execute a data acquisition procedure based on a data acquisition configuration message. Thus, UE104, Rx processor 356, or controller / processor 359 may provide means for executing a data acquisition procedure based on a data acquisition configuration message.

[0215]

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

[0216]

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

[0217]

[0244] In some implementations, reporting training data using the MDT extension involves sending the training data to the network entity.

[0218]

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

[0219]

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

[0220]

[0247] In some implementations, the data acquisition configuration message includes a list of reference signals (RS) for data acquisition, the area for data acquisition, the period for data acquisition, the network configuration, the channel type, and process identification information (ID) related to data acquisition.

[0221]

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

[0222]

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

[0223]

[0250] In some implementations, performing a data acquisition procedure further includes receiving a reference signal (RS) from a network entity in response to sending a data acquisition configuration ACK, and performing one or more measurements based on the RS.

[0224]

[0251] Figure 31 is a flowchart of an exemplary method 3100 for a network entity to perform a CSF data acquisition procedure. Method 3100 can be performed by a network entity (such as network entity 102, which may include memory 376 and may be a component of network entity 102, such as a Tx processor 316, an Rx processor 370, or a controller / processor 375).

[0225]

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

[0226]

[0253] In block 3120, method 3100 includes sending a data acquisition configuration message to the user equipment (UE) in response to receiving a 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 send a data acquisition configuration message to the user equipment (UE) in response to receiving a training data request. Thus, the network entity 102, the Tx processor 316, or the controller / processor 375 may provide means for sending a data acquisition configuration message to the user equipment (UE) in response to receiving a training data request.

[0227]

[0254] In block 3130, method 3100 includes receiving a data acquisition configuration acknowledgment (ACK) from the UE in response to sending a data acquisition 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 acquisition configuration acknowledgment (ACK) from the UE in response to sending a data acquisition configuration message. Thus, the network entity 102, the Tx processor 316, or the controller / processor 375 may provide means for receiving a data acquisition configuration acknowledgment (ACK) from the UE in response to sending a data acquisition configuration message.

[0228]

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

[0229]

[0256] In block 3150, method 3100 includes receiving or reporting training data between the UE, the UE vendor, and the network entity vendor based on the execution of a data acquisition 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 the execution of a data acquisition procedure. Thus, the network entity 102, the Tx processor 316, or the controller / processor 375 may provide means for receiving or reporting training data between the UE, the UE vendor, and the network entity vendor based on the execution of a data acquisition procedure.

[0230]

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

[0231]

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

[0232]

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

[0233]

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

[0234]

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

[0235]

[0262] In block 3210, 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 a 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 means for communicating a training data request to initiate model training for the UE vendor and the network entity vendor.

[0236]

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

[0237]

[0264] In block 3230, 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, Rx processor 356, or controller / processor 359 may be configured to perform model training for a channel state information (CSI) feedback (CSF) model. Thus, the UE vendor 310 / 502, Rx processor 356, or controller / processor 359 may provide means for performing model training for a channel state information (CSI) feedback (CSF) model.

[0238]

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

[0239]

[0266] In some implementations, communicating training data requests further includes communicating training data requests to network entity vendors to initiate model training.

[0240]

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

[0241]

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

[0242]

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

[0243]

[0270] In some implementations, registering one or more CSF models involves registering one or more model identification information (IDs) or a list of model structure (MS) IDs, 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 the following: timestamp, location information, and metadata.

[0245]

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

[0246]

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

[0247]

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

[0248]

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

[0249]

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

[0250]

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

[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 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 at least one of Doppler / delay spread measurements.

[0253]

[0280] In some implementations, the format of the UE report including the downlink raw channel matrix corresponds to the frequency domain resolution and eigen-directions of the downlink raw channel matrix.

[0254]

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

[0255]

[0282] In block 3310, 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, a network entity / gNB vendor 316 / 504, a Tx processor 316, or a controller / processor 375 may be configured to communicate a training data request to initiate model training for a user equipment (UE) vendor and a network entity vendor. Thus, a network entity / gNB vendor 316 / 504, a Tx processor 316, or a controller / processor 375 may provide means for communicating a training data request to initiate model training for a user equipment (UE) vendor and a network entity vendor.

[0256]

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

[0257]

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

[0258]

[0285] In block 3340, method 3300 includes communicating a model training report to the UE vendor. In some implementations, for example, a network entity / gNB vendor 316 / 504, a Tx processor 316, or a 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 means for communicating the model training report to the UE vendor.

[0259]

[0286] In some implementations, communicating training data requests further involves communicating training data requests to the model manager in order to forward them to the network entity for executing the UE selection procedure.

[0260]

[0287] In some implementations, communicating training data requests further involves communicating training data requests to the model manager in order to execute the UE selection procedure.

[0261]

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

[0262]

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

[0263]

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

[0264]

[0291] In some implementations, the distilled data for network entities corresponds to a UE report that includes the downlink raw channel matrix and metadata identifiers (meta-IDs).

[0265]

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

[0266]

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

[0267]

[0294] In some implementations, receiving training data reports further includes receiving training data reports using at least one of the following: Minimized Driving Test (MDT) extensions and cross-vendor methods.

[0268]

[0295] In some implementations, receiving training data reports using the MDT extension includes receiving training data reports from the Model Manager.

[0269]

[0296] In some implementations, receiving training data reports using inter-vendor protocols involves receiving training data reports from UE vendors using proprietary protocols.

[0270]

[0297] This application includes an appendix that provides additional details relating to various aspects of this disclosure.

[0271]

[0298] The following examples are illustrative and their embodiments may be combined with other embodiments or teachings described herein without limitation. Clause 1. A wireless communication method for user equipment (UE) vendors, Training one or more encoder-decoder pairs based on the UE vendor's raw dataset, This involves generating one or more training sets based on the output of one or more encoders running on the UE vendor's raw dataset, Communicating one or more training sets to a network entity vendor A method including Clause 2. Each of the one or more training sets includes encoder identification information (ID), encoder output, and a desired decoder output, the method according to Clause 1 3. 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, the method according to Clause 1 or 2 4. The one or more metadata include at least one of UE antenna configuration, signal-to-noise ratio (SNR), reference signal received power (RSRP), Doppler speed, average delay, and timestamp, the method according to any one of Clauses 1 to 3 5. The method according to any one of Clauses 1 to 4 further includes decomposing the one or more metadata into UE meta IDs 6. The encoder output of the one or more encoders corresponds to a compressed channel state information (CSI) feedback (CSF) message, the method according to any one of Clauses 1 to 5 7. The decoder output of one or more decoders among the one or more encoder-decoder pairs includes a reconstructed CSF corresponding to one or more precoding vectors, the method according to any one of Clauses 1 to 6 8. A method of wireless communication for a user equipment (UE) vendor Training one or more encoder-decoder pairs based on the raw data set of the UE vendor Generating two training sets for each of the one or more encoder-decoder pairs based on the output of one or more encoders that execute the raw data set of the UE vendor Communicating the two training sets to a network entity vendor A method including 9. The method according to clause 8, further comprising generating two training sets using the raw dataset from the UE vendor and generating a first training set based on the outputs of the encoder and decoder. 10. The method according to Clause 8 or 9, wherein the first training set includes encoder identification information (ID), encoder output, and reconstruction of a desired decoder output by the decoder. 11. The method according to clauses 8-10, further comprising generating two training sets, perturbing the encoder output in the first training set by a vector and calculating the corresponding decoder output. 12. The second training set is as described in clauses 8-11, including an encoder ID, a combination of encoder output and vector, and the corresponding decoder output. 13. Identifying an alternative decoder that approximates the decoder found in one or more encoder-decoder pairs, Communicating the alternative decoder to the network entity vendor, The method described in clauses 8-1, further including the method described in clauses 8-1. 14. The method according to clauses 8-13, wherein the alternative decoder produces an output at least similar to that of the found decoder in response to the first and second training sets. 15. The method of Clauses 8-14, wherein identifying an alternative decoder further comprises identifying the respective alternative decoder for each encoder ID corresponding to each encoder of one or more encoder-decoder pairs. 16. The encoder outputs of one or more encoders correspond to compressed channel status information (CSI) feedback (CSF) messages, as described in clauses 8 to 15. 17. The method according to clauses 8 to 16, wherein the decoder output of one or more decoders in one or more encoder-decoder pairs includes a reconstructed CSF corresponding to one or more precoding vectors. 18. A method of wireless communication for a network entity vendor, Receiving one or more training sets from the UE vendor corresponding to one or more encoder-decoder pairs, Training one or more decoders associated with one or more training sets, Methods that include... 19. The method according to Clause 18, wherein each of one or more training sets includes encoder identification information (ID), encoder output, and desired decoder output. 20. The method described in Clause 18 or 19, wherein 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. 21. One or more metadata items as described in Clauses 18-20, including at least one of the following: UE antenna configuration, signal-to-noise ratio (SNR), reference signal received power (RSRP), delay rate, mean delay, and timestamp. 22. The method according to clauses 18-21, further comprising determining, based on one or more training sets, whether one or more decoders are associated with a network entity or shared across multiple network entities. 23. A method of wireless communication for a network entity vendor, Receiving two training sets from the UE vendor corresponding to one or more encoder-decoder pairs, Training one or more decoders associated with two training sets, Methods that include... 24. The method according to Clause 23, wherein the first training set includes encoder identification information (ID), encoder output, and reconstruction of a desired decoder output by one or more decoders. 25. The second training set is as described in clauses 23-24, including an encoder ID, a combination of encoder output and vector, and the corresponding decoder output. 26. The method according to clauses 23-25, further comprising receiving an alternative decoder that approximates the decoder found in one of the one or more encoder-decoder pairs. 27. The method according to clauses 23-26, wherein the alternative decoder produces an output at least similar to that of the found decoder in response to a first training set and a second training set. 28. The method according to clauses 23-27, wherein each of the two training sets is associated with one or more metadata to allow switching between one or more models during inference. 29. One or more metadata items include at least one of the following: UE antenna configuration, signal-to-noise ratio (SNR), reference signal received power (RSRP), delay rate, mean delay, and timestamp, as described in clauses 23 to 28. 30. The method according to clauses 23-29, further comprising determining, based on two training sets, whether one or more decoders are associated with a network entity or shared across multiple network entities. 31. Device for wireless communications for user equipment (UE) vendors, Memory that stores executable computer instructions, At least one processor coupled to memory and configured to execute computer executable instructions to perform the method described in any one of the clauses 1 to 17, A device equipped with the following features. 32. Device for wireless communications for a user equipment (UE) vendor, comprising means for performing the method described in any one of the clauses 1 to 17. 33. A non-temporary computer-readable medium for storing computer executable code, wherein the code, when executed by a user equipment (UE) vendor's processor, causes the processor to perform the actions described in any one of the clauses 1 to 17. 34. Device for wireless communications for network entity vendors, Memory that stores executable computer instructions, At least one processor coupled to memory and configured to execute computer executable instructions to perform the method described in any one of the clauses 18 to 30, A device equipped with the following features. 35. Apparatus for wireless communications for network entity vendors, comprising means for performing the method described in any one of the clauses 18 to 30. 36. A non-temporary computer-readable medium for storing computer executable code, wherein the code, when executed by a processor of a network entity, causes the processor to perform the actions described in any one of the clauses 18 to 30.

[0272]

[0299] The foregoing descriptions are provided to enable any person skilled in the art to practice the various embodiments described herein. Various modifications to these embodiments will be readily apparent to a person skilled in the art, and the general principles defined herein may apply to other embodiments. Accordingly, the claims are not intended to be limited to the embodiments shown herein, but should be given the maximum scope consistent with the language of the claims, and singular references to elements shall mean "one or more" and not "unique" unless otherwise specified. The word "exemplary" is used herein to mean "serving as an example, case, or illustration." None of the embodiments described herein as "exemplary" should necessarily be construed as being preferable or advantageous to any other embodiment. Unless otherwise specified, the term "several" 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 A's, multiple B's, or multiple C's. 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" can 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 elements of various aspects described throughout this disclosure, whether known to those skilled in the art or to become known thereafter, are expressly incorporated herein by reference and intended to be encompassed by the claims. Furthermore, nothing disclosed herein is intended to be made public, whether such disclosure is expressly stated in the claims or not.The terms "module," "mechanism," "element," and "device" are not always substitutes for the term "means." Therefore, no element of a patent claim should be interpreted as means plus function unless that element is explicitly enumerated using the phrase "~means." The invention described in the original claims of this application is listed below. [C1] A wireless communication method for user equipment (UE) vendors, Training one or more encoder-decoder pairs based on the raw dataset of the aforementioned UE vendor, To generate one or more training sets based on the output of one or more encoders running the raw dataset of the UE vendor, Communicating the aforementioned one or more training sets to the network entity vendor, Methods that include... [C2] The method according to C1, wherein each of the one or more training sets includes encoder identification information (ID), an encoder output, and a desired decoder output. [C3] The method according to C1, wherein 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. [C4] The method according to C3, wherein the one or more metadata includes at least one of the following: UE antenna configuration, signal-to-noise ratio (SNR), reference signal received power (RSRP), delay rate, mean delay, and timestamp. [C5] The method of C3, further comprising decomposing the one or more metadata into UE meta IDs. [C6] The method according to C1, wherein the encoder output of one or more encoders corresponds to a compressed channel status information (CSI) feedback (CSF) message. [C7] The method according to C1, wherein the decoder output of one or more decoders in the one or more encoder-decoder pairs includes a reconstructed CSF corresponding to one or more precoding vectors. [C8] A wireless communication method for user equipment (UE) vendors, Training one or more encoder-decoder pairs based on the raw dataset of the aforementioned UE vendor, Based on the output of one or more encoders running the raw dataset of the UE vendor, two training sets are generated for each of the one or more encoder-decoder pairs. A method comprising communicating the two aforementioned training sets to a network entity vendor. [C9] The method according to C8, wherein generating the two training sets further comprises generating a first training set based on the outputs of the encoder and decoder using the raw dataset of the UE vendor. [C10] The method according to C9, wherein the first training set includes encoder identification information (ID), an encoder output, and a reconstruction of a desired decoder output by the decoder. [C11] The method according to C9, wherein generating the two training sets further comprises generating a second training set based on perturbing the encoder output in the first training set by a vector and calculating the corresponding decoder output. [C12] The method according to C11, wherein the second training set includes the encoder ID, a combination of the encoder output and the vector, and the corresponding decoder output. [C13] Identifying an alternative decoder that approximates the decoder found in one of the aforementioned one or more encoder-decoder pairs, The alternative decoder is communicated to the network entity vendor, The method described in C8, further including the method described in C8. [C14] The method according to C13, wherein the alternative decoder produces an output at least similar to that of the found decoder in response to a first training set and a second training set. [C15] The method of C13, wherein identifying the alternative decoder further comprises identifying the respective alternative decoder for each encoder ID corresponding to each encoder of the one or more encoder-decoder pairs. [C16] The method according to C8, wherein the encoder output of one or more encoders corresponds to a compressed channel state information (CSI) feedback (CSF) message. [C17] The method according to C8, wherein the decoder output of one or more decoders in the one or more encoder-decoder pairs includes a reconstructed CSF corresponding to one or more precoding vectors. [C18] A wireless communication method for network entity vendors, Receiving one or more training sets from the UE vendor corresponding to one or more encoder-decoder pairs, Training one or more decoders associated with the one or more training sets, Methods that include... [C19] The method according to C18, wherein each of the one or more training sets includes encoder identification information (ID), an encoder output, and a desired decoder output. [C20] The method according to C18, wherein 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. [C21] The method according to C20, wherein the one or more metadata includes at least one of the following: UE antenna configuration, signal-to-noise ratio (SNR), reference signal received power (RSRP), delay rate, mean delay, and timestamp. [C22] The method according to C18, further comprising determining, based on the one or more training sets, whether the one or more decoders are associated with a network entity or shared across multiple network entities. [C23] A wireless communication method for network entity vendors, Receiving two training sets from the UE vendor corresponding to one or more encoder-decoder pairs, Training one or more decoders associated with the two aforementioned training sets, Methods that include... [C24] The method according to C23, wherein the first training set includes encoder identification information (ID), an encoder output, and reconstruction of a desired decoder output by the one or more decoders. [C25] The method according to C23, wherein the second training set includes the encoder ID, a combination of the encoder output and the vector, and the corresponding decoder output. [C26] The method according to C23, further comprising receiving an alternative decoder that approximates the decoder found in one of the one or more encoder-decoder pairs. [C27] The method according to C26, wherein the alternative decoder generates an output at least similar to that of the found decoder in response to a first training set and a second training set. [C28] The method according to C23, wherein each of the two training sets is associated with one or more metadata to enable switching between one or more models during inference. [C29] The method according to C28, wherein the one or more metadata includes at least one of the following: UE antenna configuration, signal-to-noise ratio (SNR), reference signal received power (RSRP), delay rate, mean delay, and timestamp. [C30] The method according to C23, further comprising determining, based on the two training sets, whether the one or more decoders are associated with a network entity or shared across multiple network entities.

Claims

1. A wireless communication method for user equipment (UE) vendors, Training one or more encoder-decoder pairs based on the raw dataset of the aforementioned UE vendor, To generate one or more training sets based on the output of one or more encoders running the raw dataset of the UE vendor, wherein each of the one or more training sets includes encoder identification information (ID), encoder output, and desired decoder output. Communicating one or more of the aforementioned training sets to the network entity vendor, Methods that include...

2. The method according to claim 1, wherein 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.

3. The method according to claim 2, wherein the one or more metadata includes at least one of UE antenna configuration, signal-to-noise ratio (SNR), reference signal received power (RSRP), delay rate, mean delay, and timestamp.

4. The method according to claim 2, further comprising decomposing the one or more metadata into UE meta IDs.

5. The method according to claim 1, wherein the encoder outputs of the one or more encoders correspond to compressed channel state information (CSI) feedback (CSF) messages.

6. The method according to claim 1, wherein the decoder output of one or more decoders in the one or more encoder-decoder pairs includes a reconstructed CSF corresponding to one or more precoding vectors.

7. A wireless communication method for user equipment (UE) vendors, Training one or more encoder-decoder pairs based on the raw dataset of the aforementioned UE vendor, Based on the output of one or more encoders running the raw dataset of the UE vendor, two training sets are generated for each of the one or more encoder-decoder pairs. The two aforementioned training sets are communicated to the network entity vendor, Methods that include...

8. The method according to claim 7, wherein generating the two training sets further comprises generating a first training set based on the outputs of the encoder and decoder using the raw dataset of the UE vendor.

9. The method according to claim 8, wherein the first training set includes encoder identification information (ID), an encoder output, and a reconstruction of a desired decoder output by the decoder.

10. The method according to claim 8, wherein generating the two training sets further comprises generating a second training set based on perturbing the encoder output in the first training set by a vector and calculating the corresponding decoder output.

11. The method according to claim 10, wherein the second training set includes encoder identification information (ID), a combination of the encoder output and the vector, and the corresponding decoder output.

12. Identifying an alternative decoder that approximates the decoder found in one of the aforementioned one or more encoder-decoder pairs, The alternative decoder is communicated to the network entity vendor, The method according to claim 7, further comprising:

13. The method according to claim 12, wherein the alternative decoder generates an output at least similar to that of the found decoder in response to a first training set and a second training set.

14. The method according to claim 12, wherein identifying the alternative decoder further includes identifying the respective alternative decoder for each encoder ID corresponding to each encoder of the one or more encoder-decoder pairs.

15. The method according to claim 7, wherein the encoder outputs of the one or more encoders correspond to compressed channel state information (CSI) feedback (CSF) messages.

16. The method according to claim 7, wherein the decoder output of one or more decoders in the one or more encoder-decoder pairs includes a reconstructed CSF corresponding to one or more precoding vectors.

17. A wireless communication method for network entity vendors, Receiving from a UE vendor one or more training sets corresponding to one or more encoder-decoder pairs, wherein each of the one or more training sets includes encoder identification information (ID), encoder output, and desired decoder output. Training one or more decoders associated with the one or more training sets, Methods that include...

18. The method according to claim 17, wherein 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.

19. The method according to claim 18, wherein the one or more metadata includes at least one of UE antenna configuration, signal-to-noise ratio (SNR), reference signal received power (RSRP), delay rate, mean delay, and timestamp.

20. The method according to claim 17, further comprising determining, based on the one or more training sets, whether the one or more decoders are associated with a network entity or shared across multiple network entities.

21. A wireless communication method for network entity vendors, Receiving two training sets from a UE vendor corresponding to one or more encoder-decoder pairs, wherein the two training sets include a first training set and a second training set. Training one or more decoders associated with the two aforementioned training sets, Methods that include...

22. The method according to claim 21, wherein the first training set includes encoder identification information (ID), an encoder output, and reconstruction of a desired decoder output by the one or more decoders.

23. The method according to claim 21, wherein the second training set includes encoder identification information (ID), a combination of an encoder output in the first training set and a vector that perturbs the encoder output, and a corresponding decoder output.

24. The method according to claim 21, further comprising receiving an alternative decoder that approximates the decoder found in one of the one or more encoder-decoder pairs.

25. The method according to claim 24, wherein the alternative decoder generates an output at least similar to that of the found decoder in response to a first training set and a second training set.

26. The method according to claim 21, wherein each of the two training sets is associated with one or more metadata to enable switching between one or more models during inference.

27. The method according to claim 26, wherein the one or more metadata includes at least one of UE antenna configuration, signal-to-noise ratio (SNR), reference signal received power (RSRP), delay rate, mean delay, and timestamp.

28. The method according to claim 21, further comprising determining, based on the two training sets, whether the one or more decoders are associated with a network entity or shared across multiple network entities.

Images