Systems and methods for ue cooperative MIMO

Abstract

The present disclosure provides a transmitter and receiver framework flexible configuration that can be flexibly configured between various cooperative MIMO configurations (e.g., between closed loop MIMO and open loop MIMO). The present disclosure provides a signaling method for configuring a shared media access control (MAC) layer in a first device (e.g., user equipment) for cooperative transmission of a plurality of devices including the first device.

Description

[0001] This application claims priority to U.S. Provisional Patent Application No. 63,352,299, filed on June 15, 2022, entitled “SYSTEMS AND METHODS FOR UE COOPERATIVE MIMO,” the entire contents of which are incorporated herein by reference. Technical Field

[0002] The present application relates generally to wireless communications, and more particularly to systems and methods for user equipment (UE) cooperative multiple input multiple output (MIMO) communications. Background Art

[0003] In a traditional wireless communication system, each user equipment (UE) transmits / receives with the base station on its own. This system can be considered a cell-centric system. In order to improve direct communication between UEs, UE-to-UE communication (also called device-to-device or D2D) has been studied and specified. Unlike UE-to-UE communication, UE cooperation (UC) involves a group of UEs working together to improve the transmission / reception between the UE and the base station and between the UEs. A system characterized by UE cooperation can be considered a UE-centric system. This system can be used to supplement the traditional cell-centric system and improve the performance and capacity of the entire system.

[0004] UC multiple input multiple output (MIMO) uses the antennas and transmit power of multiple UEs to send / receive data simultaneously, thereby benefiting from improved transmit power / spatial diversity / multiplexing. However, UC MIMO requires more precise phase alignment / synchronization between UEs, which may be difficult to achieve. For example, in order to obtain the benefits, UC coherent joint transmission (CJT) MIMO requires one or more UEs to frequently perform strict phase alignment between UEs, which may place higher requirements on the UE and the system. Summary of the invention

[0005] The present disclosure provides a transmitter and receiver framework that can be flexibly configured between various collaborative MIMO configurations (for example, between closed-loop MIMO and open-loop MIMO). The present disclosure provides a signaling method for configuring a common medium access control (MAC) layer in a first device such as a user equipment or a device in a user equipment for collaborative transmission of multiple devices including the first device. Closed-loop MIMO configuration and open-loop MIMO configuration (more generally, different MIMO configurations) are most effective in different contexts or network conditions; a flexible framework can be used to implement switching between different configurations to achieve a configuration suitable for a given context or network condition.

[0006] According to one aspect of the present disclosure, a method in a first device is provided. The method includes: receiving a configuration of a common medium access control (MAC) entity in the first device for cooperative transmission of multiple devices including the first device; sending transport block (TB) data to a network device as part of the cooperative transmission; and sending TB data to another device among the multiple devices for the other device to transmit to the network device as part of the cooperative transmission.

[0007] In some embodiments, the common MAC entity comprises a common HARQ entity or multiple HARQ entities.

[0008] In some embodiments, the common MAC entity comprises a common HARQ entity configured with one or more HARQ processes, each of the one or more HARQ processes being associated with one or more of the plurality of apparatuses.

[0009] In some embodiments, the sending of TB data to the network device and the sending of TB data to another device both involve the same TB data; the common MAC entity includes a common HARQ entity, and the common HARQ entity is configured with a HARQ process for managing the transmission of the same TB data by the first device and the other device.

[0010] In some embodiments, the sending of TB data to the network device and the sending of TB data to another device among the multiple devices both involve the same TB data; the common MAC entity includes a first HARQ entity and a second HARQ entity, the first HARQ entity is configured with a first HARQ process for managing the sending of TB data to the network device, and the second HARQ entity is configured with a second HARQ process for managing the transmission of the same TB data by the other device.

[0011] In some embodiments, the common MAC entity includes a first HARQ entity and a second HARQ entity, wherein the first HARQ entity is configured with a first HARQ process for managing the transmission of a first TB of data by the first device, and the second HARQ entity is configured with a second HARQ process for managing the transmission of a second TB of data by the other device.

[0012] In some embodiments, the common MAC entity includes a first HARQ entity related to the TB transmission of the first device and other HARQ entities related to the TB transmission of the other device among the multiple devices, wherein, in the case of repeated TB transmission, the first HARQ entity is configured with a first HARQ process related to managing the first device sending TB data to the network device, and the second HARQ entity is configured with another HARQ process related to managing the repeated transmission of the same TB data by the other device; in the case of split TB transmission, the first HARQ entity is configured with a first HARQ process related to the first device sending TB data to the network device, and the second HARQ entity is configured with a second HARQ process related to the transmission of the second TB data by the other device.

[0013] In some embodiments, the common MAC entity supports outputting repeated TBs and split TBs to the physical (PHY) layer of the multiple devices, and the method further includes: when the MAC entity outputs repeated TBs, sending TB data to another device includes sending TB data that is the same as the TB data sent by the first device to the network device; when the MAC entity outputs split TBs, sending TB data to another device includes sending TB data that is different from the TB data sent by the first device to the network device.

[0014] In some embodiments, the configuration is used to configure whether to use open-loop MIMO or closed-loop MIMO for the cooperative transmission.

[0015] In some embodiments, when configuring the first apparatus to use closed-loop MIMO, the configuration is further used to indicate whether to use a precoder indicated by the network or a precoder based on measurement of a downlink reference signal.

[0016] In some embodiments, when the first device is configured to use closed-loop MIMO, the configuration is further used to indicate whether to use coherent precoding or non-coherent precoding.

[0017] In some embodiments, the method also includes: receiving downlink control information (DCI) for scheduling transmission of the first device or scheduling transmission of the first device and the other device; and sending signaling information for scheduling transmission of the other device to the other device when the DCI schedules transmission of the first device and the other device.

[0018] In some embodiments, the DCI includes an explicit or implicit indication of whether the DCI schedules transmission for the first apparatus or schedules transmission for the first apparatus and the another apparatus.

[0019] According to another aspect of the present disclosure, a method in a network device is provided. The method includes: sending a configuration of a common medium access control (MAC) entity in a first device to a first device for cooperative transmission of multiple devices including the first device; receiving transport block (TB) data from the first device as part of the cooperative transmission; and receiving TB data from another device in the multiple devices as part of the cooperative transmission.

[0020] In some embodiments, the common MAC entity comprises a common HARQ entity or multiple HARQ entities.

[0021] In some embodiments, the common MAC entity comprises a common HARQ entity configured with one or more HARQ processes, each of the one or more HARQ processes being associated with one or more of the plurality of apparatuses.

[0022] In some embodiments, the receiving of TB data from the first device and the receiving of TB data from another device both involve the same TB data; the public MAC entity includes a public HARQ entity, and the TB data received from the first device and the same TB data received from the other device are managed by the same HARQ process configured to the public HARQ entity.

[0023] In some embodiments, the receiving TB data from the first device and the receiving TB data from another device among the multiple devices both involve the same TB data; the common MAC entity includes a first HARQ entity and a second HARQ entity, wherein the TB data received from the first device is managed by a first HARQ process configured to the first HARQ entity, and the same TB data received from the other device is managed by a second HARQ process configured to the second HARQ entity.

[0024] In some embodiments, the common MAC entity includes a first HARQ entity and a second HARQ entity, wherein the first HARQ entity is configured with a first HARQ process for managing the transmission of a first TB of data by the first device, and the second HARQ entity is configured with a second HARQ process for managing the transmission of a second TB of data by the other device.

[0025] In some embodiments, the common MAC entity includes a first HARQ entity associated with the TB transmission of the first device and another HARQ entity associated with the TB transmission of the other device among the multiple devices, wherein, in the case of repeated TB transmission, the first HARQ entity is configured with a first HARQ process associated with managing the first device sending TB data to the network device, and the second HARQ entity is configured with another HARQ process associated with managing the repeated transmission of the same TB data by the other device; in the case of split TB transmission, the first HARQ entity is configured with a first HARQ process associated with managing the first device sending TB data to the network device, and the second HARQ entity is configured with a second HARQ process associated with managing the transmission of a second TB data by the other device.

[0026] In some embodiments, the configuration is used to configure whether to use open-loop MIMO or closed-loop MIMO for the cooperative transmission.

[0027] In some embodiments, when configuring the first apparatus to use closed-loop MIMO, the configuration is further used to indicate whether to use a precoder indicated by the network or a precoder based on measurement of a downlink reference signal.

[0028] In some embodiments, when the first device is configured to use closed-loop MIMO, the configuration is further used to indicate whether to use coherent precoding or non-coherent precoding.

[0029] In some embodiments, the method further includes sending downlink control information (DCI) for scheduling transmission of the first device or scheduling transmission of the first device and the another device.

[0030] In some embodiments, the DCI includes an explicit or implicit indication of whether the DCI schedules transmission for the first apparatus or schedules transmission for the first apparatus and the another apparatus.

[0031] According to another aspect of the present disclosure, a device is provided, comprising: a processor and a memory, wherein the device is configured to execute the method described herein.

[0032] According to another aspect of the present disclosure, a network device is provided, wherein the network device comprises: a processor and a memory, wherein the device is configured to execute the method described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The following describes the embodiments of the present disclosure with reference to the accompanying drawings, in which:

[0034] Figure 1 is a block diagram of a communication system;

[0035] Figure 2 is a block diagram of a communication system;

[0036] Figure 3 is a block diagram of a communication system showing the basic component structure of an electronic device (ED) and a base station;

[0037] Figure 4 It is a block diagram of a module that can be used to implement or execute one or more steps of an embodiment of the present application;

[0038] Figure 5A and Figure 5B shows a framework configuration for closed-loop MIMO;

[0039] Fig. 6A and Figure 6B shows a framework configuration for open-loop MIMO;

[0040] Figure 7 An example of a signaling channel switching between different UC MIMO configurations is shown;

[0041] Fig. 8A , Figure 8B and Figure 8C shows a common medium access control (MAC) entity with a separate HARQ entity for uplink transmission, an association between a joint HARQ process and a corresponding physical shared channel of one or more participating UEs, and details of multiple HARQ entities;

[0042] Fig.9A and Fig. 9B Detailed information of a common MAC entity with a separate HARQ entity and multiple HARQ entities for downlink transmission are shown respectively. DETAILED DESCRIPTION

[0043] UC MIMO can be used to provide improved transmit power / spatial diversity / multiplexing benefits. However, this may require precise calibration and synchronization between UEs, which may be difficult to achieve. The present disclosure provides a transmitter and receiver framework that can be flexibly configured between various collaborative MIMO configurations (e.g., between closed-loop MIMO and open-loop MIMO).

[0044] refer to Figure 1 , Figure 1 is a non-limiting illustrative example, providing a simplified schematic diagram of a communication system. The communication system 100 includes a radio access network 120. The radio access network 120 may be a next generation (e.g., sixth generation (6G) or higher) radio access network or a traditional (e.g., 5G, 4G, 3G or 2G) radio access network. One or more communication electronic devices (ED) 110a to 110j (collectively referred to as 110) may be interconnected with each other or connected to one or more network nodes (170a, 170b, collectively referred to as 170) in the radio access network 120. The core network 130 may be part of the communication system and may be dependent on or independent of the radio access technology used in the communication system 100. In addition, the communication system 100 includes a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160.

[0045] Figure 2 An exemplary communication system 100 is shown. In general, the communication system 100 enables multiple wireless or wired units to transmit data and other content. The purpose of the communication system 100 may be to provide content such as voice, data, video and / or text through broadcast, multicast and unicast, etc. The communication system 100 can operate by sharing resources such as carrier spectrum bandwidth between its constituent units. The communication system 100 may include a terrestrial communication system and / or a non-terrestrial communication system. The communication system 100 may provide a variety of communication services and applications (e.g., earth monitoring, remote sensing, passive sensing and positioning, navigation and tracking, autonomous delivery and mobility, etc.). The communication system 100 may provide a high degree of availability and robustness through the joint operation of a terrestrial communication system and a non-terrestrial communication system. For example, integrating a non-terrestrial communication system (or its components) into a terrestrial communication system may produce a heterogeneous network including multiple layers. Compared with traditional communication networks, heterogeneous networks can achieve better overall performance through efficient multi-link joint operation, more flexible function sharing, and faster physical layer link switching between terrestrial networks and non-terrestrial networks.

[0046] The terrestrial communication system and the non-terrestrial communication system may be subsystems in the communication system. In the example shown, the communication system 100 includes electronic devices (ED) 110a to 110d (collectively referred to as ED 110), radio access networks (RAN) 120a and 120b, non-terrestrial communication networks 120c, core networks 130, public switched telephone networks (PSTN) 140, Internet 150, and other networks 160. RAN 120a and 120b include corresponding base stations (BS) 170a and 170b, which may be generally referred to as terrestrial transmit and receive points (T-TRP) 170a and 170b. Non-terrestrial communication network 120c includes access node 120c, which may be generally referred to as non-terrestrial transmit and receive point (NT-TRP) 172.

[0047] Any ED 110 may alternatively or additionally be used to connect, access, or communicate with any other T-TRP 170a and 170b, NT-TRP 172, Internet 150, core network 130, PSTN 140, other network 160, or any combination of the foregoing. In some examples, ED 110a may perform uplink and / or downlink transmissions with T-TRP 170a via interface 190a. In some examples, ED 110a, 110b, and 110d may also communicate directly with each other via one or more sidelink air interfaces 190b. In some examples, ED 110d may perform uplink and / or downlink transmissions with NT-TRP 172 via interface 190c.

[0048] The air interfaces 190a and 190b may use similar communication technologies, such as any suitable wireless access technology. For example, the communication system 100 may implement one or more channel access methods in the air interfaces 190a and 190b, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA). The air interfaces 190a and 190b may utilize other high-dimensional signal spaces, which may include a combination of orthogonal dimensions and / or non-orthogonal dimensions.

[0049] Air interface 190c may enable communication between ED 110d and one or more NT-TRPs 172 via a wireless link or a simple link. In some examples, the link is a dedicated connection for unicast transmission, a connection for broadcast transmission, or a connection between a group of EDs and one or more NT-TRPs for multicast transmission.

[0050] The RANs 120a and 120b communicate with the core network 130 to provide various services, such as voice, data, and other services, to the EDs 110a, 110b, and 110c. The RANs 120a and 120b and / or the core network 130 may communicate directly or indirectly with one or more other RANs (not shown), which may or may not be directly served by the core network 130 and may or may not use the same radio access technology as the RANs 120a, 120b, or both. The core network 130 may also serve as a gateway access between (i) the RANs 120a and 120b or the EDs 110a, 110b, and 110c, or both, and (ii) other networks, such as the PSTN 140, the Internet 150, and other networks 160. In addition, some or all of the EDs 110a, 110b, and 110c may include functionality for communicating with different wireless networks over different radio links using different radio technologies and / or protocols. Instead of (or in addition to) wireless communications, EDs 110a, 110b, and 110c may communicate with a service provider or switch (not shown) and with the Internet 150 via a wired communication channel. PSTN 140 may include a circuit-switched telephone network for providing plain old telephone service (POTS). Internet 150 may include computer networks and / or subnets (intranets), and include protocols such as Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). EDs 110a, 110b, and 110c may be multi-mode devices capable of operating according to a variety of wireless access technologies, and may include a plurality of transceivers required to support these technologies.

[0051] Figure 3Another example of ED 110 and base stations 170a, 170b and / or 170c is shown. ED 110 is used to connect people, objects, machines, etc. ED 110 can be widely used in various scenarios, such as cellular communication, device-to-device (D2D), vehicle to everything (V2X), peer-to-peer (P2P), machine-to-machine (M2M), machine-type communication (MTC), Internet of Things (IoT), virtual reality (VR), augmented reality (AR), industrial control, autonomous driving, telemedicine, smart grid, smart furniture, smart office, smart wear, smart transportation, smart city, drone, robot, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery and mobility, etc.

[0052] Each ED 110 represents any suitable end-user device for wireless operation, and may include (or may be referred to as): user equipment / device (UE), terminal equipment, wireless transmit / receive unit (WTRU), mobile station, fixed or mobile user unit, cellular phone, station (STA), machine type communication (MTC) equipment, personal digital assistant (PDA), smartphone, laptop, computer, tablet, wireless sensor, consumer electronic device, smart book, vehicle, car, truck, bus, train or IoT device, industrial equipment, or devices in the above devices (e.g., communication module, modem or chip), etc. The next generation ED 110 may be referred to using other terms. Base stations 170a and 170b are T-TRPs, hereinafter referred to as T-TRP 170. Similarly, Figure 3 As shown, the NT-TRP is hereinafter referred to as NT-TRP 172. Each ED 110 connected to T-TRP 170 and / or NT-TRP 172 can be dynamically or semi-statically started (i.e., established, activated, or enabled), shut down (i.e., released, deactivated, or disabled), and / or configured in response to one or more of connection availability and connection necessity.

[0053] ED 110 includes a transmitter 201 and a receiver 203 coupled to one or more antennas 204. Only one antenna 204 is shown. One, some or all of the antennas may alternatively be a panel. Transmitter 201 and receiver 203 may be integrated into a transceiver or the like. The transceiver is used to modulate data or other content so that it can be sent through at least one antenna 204 or a network interface controller (NIC). The transceiver is also used to demodulate data or other content received through at least one antenna 204. Each transceiver includes any suitable structure for generating signals for wireless or wired transmission and / or for processing signals received wirelessly or wired. Each antenna 204 includes any suitable structure for sending and / or receiving wireless signals or wired signals.

[0054] ED 110 includes at least one memory 208. Memory 208 stores instructions and data used, generated, or collected by ED 110. For example, memory 208 may store software instructions or modules that implement some or all of the functions and / or embodiments described herein and are executed by one or more processing units 210. Each memory 208 includes any suitable one or more volatile and / or non-volatile storage and retrieval devices. Any suitable type of memory may be used, such as random access memory (RAM), read only memory (ROM), hard disk, optical disk, subscriber identity module (SIM) card, memory stick, secure digital (SD) card, processor cache, etc.

[0055] ED 110 may also include one or more input / output devices (not shown) or interfaces (e.g., Figure 1 The input / output devices support interaction with users or other devices in the network. Each input / output device includes any suitable structure for providing information to or receiving information from a user, such as a speaker, microphone, keypad, keyboard, display or touch screen, including network interface communications.

[0056] ED 110 also includes a processor 210 for performing operations related to preparing uplink transmissions to be sent to NT-TRP 172 and / or T-TRP 170, operations related to processing downlink transmissions received from NT-TRP 172 and / or T-TRP 170, and operations related to processing sidelink transmissions to and from other ED 110. Processing operations related to preparing uplink transmissions may include operations such as encoding, modulation, transmit beamforming, and generating symbols for transmission. Processing operations related to processing downlink transmissions may include operations such as receive beamforming, demodulation, and decoding received symbols. According to an embodiment, the downlink transmission may be received by receiver 203 using receive beamforming, and processor 210 may extract signaling from the downlink transmission (e.g., by detecting and / or decoding the signaling). An example of signaling may be a reference signal sent by NT-TRP 172 and / or T-TRP 170. In some embodiments, the processor 276 implements transmit beamforming and / or receive beamforming according to a beam direction indication (e.g., beam angle information (BAI)) received from the T-TRP 170. In some embodiments, the processor 210 may perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as operations related to detecting a synchronization sequence, decoding, and obtaining system information. In some embodiments, the processor 210 may perform channel estimation using a reference signal received from the NT-TRP 172 and / or the T-TRP 170, for example.

[0057] The processor 210 may be part of the transmitter 201 and / or part of the receiver 203, but is not shown. The memory 208 may be part of the processor 210, but is not shown.

[0058] The processor 210, the processing components in the transmitter 201, and the processing components in the receiver 203 may be implemented by the same or different one or more processors, respectively, which are used to execute instructions stored in a memory (e.g., the memory 208). Alternatively, some or all of the processor 210, the processing components in the transmitter 201, and the processing components in the receiver 203 may be implemented using a programmed field-programmable gate array (FPGA), a graphical processing unit (GPU), or an application-specific integrated circuit (ASIC).

[0059] In some implementations, the T-TRP 170 may be represented by other names, such as a base station, a base transceiver station (BTS), a wireless base station, a network node, a network device, a network-side device, a transmitting / receiving node, a NodeB, an evolved NodeB (eNodeB or eNB), a home eNodeB, a next generation NodeB (gNB), a transmission point (TP), a site controller, an access point (AP) or a wireless router, a relay station, a ground node, a ground network device, or a ground base station, a baseband unit (BBU), a remote radio unit (RRU), an active antenna unit (AAU), a remote radio head (RRH), a centralized unit (CU), a distributed unit (DU), a positioning node, etc. The T-TRP 170 may be a macro BS, a micro BS, a relay node, a donor node, etc., or a combination thereof. T-TRP 170 may refer to the above-mentioned device, or may refer to a device in the above-mentioned device (eg, a communication module, a modem, or a chip).

[0060] In some embodiments, various parts of T-TRP 170 can be distributed. For example, some modules in T-TRP 170 can be remote from the device that houses the antenna of T-TRP 170, and can be coupled to the device that houses the antenna through a communication link (not shown) sometimes called a fronthaul (e.g., a common public radio interface (CPRI)). Therefore, in some embodiments, the term "T-TRP 170" can also refer to a network-side module that performs the following processing operations: for example, determining the location of ED 110, resource allocation (scheduling), message generation, and encoding / decoding, which modules are not necessarily part of the device that houses the antenna of T-TRP 170. These modules can also be coupled to other T-TRPs. In some embodiments, T-TRP 170 can actually be multiple T-TRPs that operate together to serve ED 110 through coordinated multi-point transmission, etc.

[0061] The T-TRP 170 includes at least one transmitter 252 and at least one receiver 254 coupled to one or more antennas 256. Only one antenna 256 is shown. One, some or all of the antennas may alternatively be panels. The transmitter 252 and the receiver 254 may be integrated into a transceiver. The T-TRP 170 also includes a processor 260 for performing operations related to preparing downlink transmissions sent to the ED 110, processing uplink transmissions received from the ED 110, preparing backhaul transmissions sent to the NT-TRP 172, and processing transmissions received from the NT-TRP 172 via the backhaul. Processing operations related to preparing to send downlink transmissions or backhaul transmissions may include operations such as encoding, modulation, precoding (e.g., MIMO precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing received transmissions in the uplink or on the backhaul may include operations such as receive beamforming, demodulation, and decoding received symbols. The processor 260 may also perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as generating the content of a synchronization signal block (SSB), generating system information, and the like. In some embodiments, the processor 260 also generates a beam direction indication, such as a BAI, that the scheduler 253 may schedule for transmission. The processor 260 may perform other network-side processing operations described herein, such as determining the location of the ED 110, determining the location at which the NT-TRP 172 is deployed, and the like. In some embodiments, the processor 260 may generate signaling to configure one or more parameters of the ED 110 and / or one or more parameters of the NT-TRP 172, and the like. Any signaling generated by the processor 260 is sent by the transmitter 252. It should be noted that the "signaling" used herein may alternatively be referred to as control signaling. Dynamic signaling may be sent in a control channel such as a physical downlink control channel (PDCCH), while static or semi-static higher-layer signaling may be included in a data packet sent in a data channel such as a physical downlink shared channel (PDSCH).

[0062] The scheduler 253 may be coupled to the processor 260. The scheduler 253 may be included in the T-TRP 170 or may operate separately from the T-TRP 170. The scheduler 253 may schedule uplink transmissions, downlink transmissions, and / or backhaul transmissions, including issuing scheduling grants and / or configuring scheduling-free (“configuration grants”) resources. The T-TRP 170 also includes a memory 258 for storing information and data. The memory 258 stores instructions and data used, generated, or collected by the T-TRP 170. For example, the memory 258 may store software instructions or modules that are used to implement some or all of the functions and / or embodiments described herein and are executed by the processor 260.

[0063] The processor 260 may be part of the transmitter 252 and / or part of the receiver 254, but is not shown. In addition, the processor 260 may implement the scheduler 253, but is not shown. The memory 258 may be part of the processor 260, but is not shown.

[0064] The processor 260, the scheduler 253, the processing components in the transmitter 252, and the processing components in the receiver 254 may be implemented by the same or different one or more processors, which are used to execute instructions stored in a memory (e.g., the memory 258). Alternatively, part or all of the processor 260, the scheduler 253, the processing components in the transmitter 252, and the processing components in the receiver 254 may be implemented using a dedicated circuit such as an FPGA, a GPU, or an ASIC.

[0065] Although NT-TRP 172 is only illustrated as a drone, NT-TRP 172 can be implemented using any suitable non-ground form. In addition, NT-TRP 172 can use other names such as non-ground node, non-ground network device or non-ground base station in some implementations. NT-TRP 172 includes a transmitter 272 and a receiver 274 coupled to one or more antennas 280. Only one antenna 280 is shown. One, part or all of the antennas can be panels instead. Transmitter 272 and receiver 274 can be integrated into a transceiver. NT-TRP 172 also includes a processor 276 for performing operations related to: preparing downlink transmissions sent to ED 110, processing uplink transmissions received from ED 110, preparing backhaul transmissions sent to T-TRP 170, and processing transmissions received from T-TRP 170 via backhaul. Processing operations related to preparing to transmit a downlink transmission or a backhaul transmission may include operations such as encoding, modulation, precoding (e.g., MIMO precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing received transmissions in the uplink or on the backhaul may include operations such as receive beamforming, demodulation, and decoding of received symbols. In some embodiments, the processor 276 implements transmit beamforming and / or receive beamforming based on beam direction information (e.g., BAI) received from the T-TRP 170. In some embodiments, the processor 276 may generate signaling to configure one or more parameters of the ED 110, etc. In some embodiments, the NT-TRP 172 implements physical layer processing but does not implement higher-level functions, such as functions in the medium access control (MAC) or radio link control (RLC) layer. Since this is just an example, in addition to physical layer processing, the NT-TRP 172 may generally implement higher-level functions.

[0066] NT-TRP 172 also includes a memory 278 for storing information and data. Processor 276 may be part of transmitter 272 and / or part of receiver 274, but is not shown. Memory 278 may be part of processor 276, but is not shown.

[0067] The processor 276, the processing components in the transmitter 272, and the processing components in the receiver 274 may be implemented by the same or different one or more processors, which are used to execute instructions stored in a memory (e.g., the memory 278). Alternatively, some or all of the processor 276, the processing components in the transmitter 272, and the processing components in the receiver 274 may be implemented using a dedicated circuit such as a programmed FPGA, GPU, or ASIC. In some embodiments, the NT-TRP 172 may actually be a plurality of NT-TRPs that operate together to serve the ED 110 through coordinated multi-point transmission or the like.

[0068] The T-TRP 170, NT-TRP 172, and / or ED 110 may include other components, but these components are omitted for clarity.

[0069] One or more steps of the exemplary methods provided herein may be performed by Figure 4 The corresponding unit or module provided is executed. Figure 4 Units or modules in a device (e.g., in ED 110, in T-TRP 170, or in NT-TRP 172) are shown. For example, a signal may be sent by a sending unit or a sending module. For example, a signal may be sent by a sending unit or a sending module. A signal may be received by a receiving unit or a receiving module. A signal may be processed by a processing unit or a processing module. Other steps may be performed by an artificial intelligence (AI) or machine learning (ML) module. The corresponding units or modules may be implemented using hardware, one or more components or devices that execute software, or a combination thereof. For example, one or more units or modules may be an integrated circuit, such as a programmed FPGA, GPU, or ASIC. It should be understood that if these modules are implemented using software for execution by a processor or the like, these modules may be retrieved by the processor in whole or in part as needed, retrieved individually or collectively for processing, retrieved in one or more instances, and these modules themselves may include instructions for further deployment and instantiation.

[0070] Other details about ED 110, T-TRP 170 and NT-TRP 172 are known to those skilled in the art. Therefore, these details are omitted here.

[0071] Closed-Loop and Open-Loop UC MIMO

[0072] The present disclosure provides a transmitter and receiver framework that can be flexibly configured between various collaborative MIMO schemes (e.g., between closed-loop MIMO and open-loop MIMO). The transmitter and receiver used to implement such a framework can be configured according to Figures 1 to 4One or more examples in , etc. Figure 5A The closed-loop MIMO scheme in Fig. 6A The open-loop MIMO scheme is shown in FIG.

[0073] First, refer to Figure 5A The various components of the framework are described. Then, the specific configurations for closed-loop MIMO and open-loop MIMO are described.

[0074] The figure shows a first UE 500 used as a source UE (SUE) and a second UE used as a cooperating UE (CUE). The SUE is called a SUE because it is the source of the transmission packets in this scheme. The CUE is called a CUE because it helps the SUE to transmit. However, in general, a UE can be configured as a source UE or a cooperating UE. The figure also shows a base station in the form of a gNB 504. In Figure 5A In the embodiment, a common medium access control (MAC) layer 506 (shared by SUE 500 and CUE 502) is configured in SUE (or primary UE, master UE). Each of the two UEs 500 and 502 has a corresponding physical (PHY) layer 508 and 510. Collaborative transmission is performed to send data of SUE 500 to gNB 504, which has its own PHY layer 512 and MAC entity 514, or to receive data of SUE 500 from gNB 504 and send the received data to SUE 500.

[0075] Figure 5A The framework provides various configuration options. In some implementations, all of these configuration options are available. Alternatively, a subset of these configuration options can be used. The following is a non-limiting list of four configuration options:

[0076] Location of the common MAC entity: A common MAC entity for UE cooperation (UC) MIMO transmission or simple UC transmission may be configured in the SUE, while the CUE is not configured with a common MAC entity for UC MIMO transmission. Each UE is used as a SUE, in which case each UE has a common MAC entity configured for cooperative MIMO transmission, or each UE is used as a CUE, in which case each UE is not configured with a common MAC entity for cooperative MIMO transmission. Generally speaking, here, the common MAC entity refers to a MAC entity used as a MAC layer for data transmission / reception through multiple UEs in UE cooperation. In some embodiments, the common MAC entity for UC MIMO may be configured outside the two UEs (for example, in another UE), in which case both UEs are used as CUEs. The common MAC entity is described in further detail below. In some embodiments, signaling is used to configure a common MAC entity in a UE to be used as a source UE (more generally, a first device) for cooperative transmission of multiple UEs (more generally, multiple devices) including the first UE. In another embodiment, a public MAC entity is configured in the SUE together with a local MAC entity, that is, a MAC entity is configured in the SUE, some functions of which support UC MIMO transmission in which both the SUE and one or more CUEs participate, and some functions support non-UC transmission in which only the SUE participates.

[0077] Repeating transport blocks (TB) and splitting TB: It is configurable whether to repeat the TB output by the MAC entity 506 so that the same TB is sent to the two PHY layers 508, 510, or whether to split the TB output by the common MAC entity 506 so that different TBs are sent to the two PHY layers 508, 510. In some embodiments, this configuration belongs to a hybrid automatic repeat request (HARQ) configuration, which will be described later. It should be noted that for ease of description, a transport block (TB) is only an example of a block for carrying data. Other formats of blocks for carrying data may also be applied to the present application. For simplicity, in the present application, TB may be used to describe TB data. It should also be noted that although uplink data transmission is described in the description, downlink data transmission is also applicable. For example, in downlink data transmission, both PHY layers 508, 510 receive the same TB and send these TBs to the common MAC entity 506.

[0078] Open-loop MIMO vs. closed-loop MIMO: It is configurable whether to implement open-loop MIMO vs. closed-loop MIMO. In the case of closed-loop UCMIMO, each UE uses a precoding vector based on feedback from the network (e.g., base station / gNB). The precoding operation is performed in the PHY layer 508, 510. This may include the UE sending a reference signal in the uplink and receiving feedback from the base station indicating which precoder to use based on channel measurements based on the reference signal. This is also known as codebook-based (CB) precoding. Alternatively, in the case where the reciprocal channel assumption can be applied, the network can send a downlink reference signal and the UE can derive the precoder to be used based on measurements made on the downlink reference signal. This is also known as non-codebook based (NCB) precoding. Both methods are considered closed-loop methods because they both rely on channel measurements to generate precoding vectors. In some embodiments, the CB method and the NCB method may be used / supported, and which method is used is configurable. On the other hand, in the case of open-loop MIMO, channel-based precoding (based on feedback or downlink channel measurements) is not used. One benefit of this approach over closed-loop MIMO is reduced latency. Additionally, when using closed-loop MIMO, the channel may change very quickly in a closed-loop MIMO system, especially if the UE is moving quickly, so the channel measurements and, accordingly, the precoding may also become outdated quickly. Therefore, if the UE is moving quickly, closed-loop MIMO is not ideal, but for UEs that are moving slowly and the channel changes slowly, closed-loop MIMO may be appropriate. The configuration between closed-loop MIMO and open-loop MIMO may include the configuration of how precoding is performed in each PHY layer 508, 510, for example, between the following options:

[0079] (a) Network-based feedback (closed loop);

[0080] (b) Based on reciprocal channel measurement (closed loop) of downlink reference signals;

[0081] (c) Use coherent precoding or non-coherent precoding: In the case of closed-loop MIMO, the UE can use coherent joint transmission (CJT) MIMO. In this case, coherent joint precoding is used to use joint precoding between the SUE / one or more CUEs, for example, the joint precoding operation is used to generate streams for transmission through all antennas of the SUE / CUE. For example, if each SUE and CUE has two transmit antennas, a joint precoding is performed to generate four streams, which are to be transmitted through all four antennas of the SUE / CUE. In this case, the same TB of data (or the same TB for simplicity) is sent to the SUE / one or more CUEs for joint precoding and transmission under the same HARQ process. Alternatively, non-coherent precoding can be used, in which case each PHY layer 508, 510 performs separate precoding, which means that the separate precoding operation is used to generate streams for transmission through the antennas of each SUE / CUE respectively. For example, if each SUE and CUE has two transmit antennas, two separate precoding operations are performed to generate two separate streams, each of which is transmitted through the two antennas of the SUE or CUE, respectively;

[0082] (d) Selected by the transmitter without reference to channel measurements (open loop). In this case, the transmitter can select a precoding vector, which can be configured or predefined to be applied to the precoding operation. For open-loop MIMO, such a precoding vector is not based on uplink (UL) or downlink (DL) channel measurements. HARQ entity: Typically, a HARQ entity is a function that manages one or more HARQ processes. In some embodiments, the HARQ entity is configured in or defined in a MAC entity, and each cell in a cell group including multiple cells corresponds to a HARQ entity. The corresponding HARQ process is used to manage the original transmission and retransmission of a TB. In a conventional system, the HARQ process is configured in a MAC entity of a UE (a conventional MAC entity, not a common MAC entity), which manages the transmission of TB data (or TB for simplicity) through the PHY layer of the UE. For UC MIMO, a common HARQ entity may be defined / configured in a common MAC that is responsible for managing separate HARQ processes associated with jointly or individually precoded TB data, or in the case of individually precoded TBs, for managing the respective HARQ processes. For example, in the case of individually precoded UC MIMO, TB#1 and TB#2 may be sent and transmitted from SUE 500 to gNB 504 via SUE 500 and CUE 502, respectively, as shown in FIG. Figure 5AAs shown. The two TBs are transmitted / retransmitted under HARQ processes #1 and #2, respectively. In the case where the same TB is sent from SUE 500 and CUE 502 using separate precoding or joint precoding, the same HARQ process can also be used to manage such transmission of the same TB through SUE and CUE. For example, the same TB #1 can be sent from SUE 500 and CUE 502 under the same HARQ process #1.

[0083] The first closed-loop MIMO solution is Figure 5A As shown. In this scheme, TB segmentation is used, where data is segmented in a common MAC entity into different TBs that the MAC entity outputs to the PHY layer. Through this scheme, different TBs are sent from the common MAC entity to the PHY layers 508, 510 of the SUE 500 and the CUE 502. Figure 5A As shown, TB #1 520 is sent to PHY 508, and TB #2 522 is sent to PHY 510. These TBs are then sent to gNB 504 via the PHY layer of SUE 508 and CUE 510, respectively. Figure 5A In the example of , PHY layers 508, 510 are used to use precoding vectors based on channel measurements (e.g., based on feedback from gNB, or reciprocal channel measurements, closed-loop MIMO) and non-coherent UC MIMO, which means that each UE performs precoding separately in the corresponding PHY layer. Different precoders are used to precode the first TB in the SUE and the second TB in the CUE for transmission under separate HARQ processes. Figure 5A In the example of , signaling is used to configure a common MAC entity in SUE 500.

[0084] The second closed-loop MIMO solution is Figure 5B In this scheme, the public MAC entity 606 is configured outside the UE 500, 502 (for example, in another UE or another device, not shown), so neither the UE 550, 502 has a public MAC entity configured for UCMIMO, and each UE can be regarded as a CUE. The rest of the scheme and data flow are similar to Figure 5A The CUE may still have its own MAC entity for its own transmissions, but not for UC MIMO, since UC MIMO uses a common MAC entity.

[0085] Although Figure 5A and Figure 5BA closed-loop MIMO scheme with TB segmentation is shown, but the closed-loop MIMO scheme can also be used for TB repetition. In this case, the same TB is repeated and sent from the common MAC entity to the PHY layer of the SUE 500 and the CUE 502, respectively. Then, the same TB is separately precoded in the PHY layer of each of the SUE 500 and the CUE 502 for transmission to the gNB 504.

[0086] A first example of an open-loop MIMO scheme is Fig. 6A As shown. In this example, UE 500 is configured with a common MAC entity 506 to act as a SUE, while UE 502 is configured as a CUE. MAC entity 506 is used to repeat TBs for transmission by both UEs. PHY layers 508, 510 are configured with open-loop MIMO transmission. For example, each PHY layer 508, 510 precodes the same TB using a corresponding cyclic precoder. For the same TB, a joint HARQ process is used between SUE / CUE. For example, Fig. 6A As shown, TB#1 is sent from SUE 500 and CUE 502 and transmitted to gNB 504 using corresponding cyclic precoders. For example, TB#1 is transmitted / retransmitted under the same HARQ process #1.

[0087] The second open-loop MIMO solution is Figure 6B In this scheme, the public MAC entity 606 is configured outside the UE 500, 502 (for example, in another UE, not shown), so neither the UE 500, 502 has a public MAC entity configured for UC MIMO, and each UE can be regarded as a CUE. The rest of the scheme and data flow are similar to Fig. 6A The same as in.

[0088] In some embodiments, each of the four configuration options is individually configurable based on network signaling, etc., which allows for maximum flexibility. In general, there may be a set of configuration options different from the specifically listed configuration options, each of which is individually configurable.

[0089] Alternatively, a set of transmitter configurations is defined; each defined transmitter configuration includes a specific configuration for each configuration option (more generally, each configuration option in a set of configuration options). For example, closed-loop MIMO may use one or more defined transmitter configurations, and open-loop MIMO may use one or more defined transmitter configurations. The defined transmitter configurations may be predefined or configured.

[0090] In some embodiments, the network (e.g., gNB) controls which configuration is active, e.g., switching between a closed-loop configuration and an open-loop configuration. Various factors may be considered when deciding when to switch. For example, the gNB may make a switching decision based on the success / failure rate of data transmissions under each configuration. For example, if closed-loop MIMO is used and an increase in the number of decoding failures is observed at a certain point, this may indicate strong inter-UE interference (the mutual channels between UEs participating in UC MIMO transmissions are more correlated) or higher mobility (thus, closed-loop MIMO may perform poorly due to latency). The gNB may switch the UE to an open-loop MIMO configuration.

[0091] In some embodiments, high-level signaling such as radio resource control (RRC) signaling is used to indicate which configuration to use. Alternatively, dynamic signaling can be used to indicate which configuration to use; for example, an implicit indication or an explicit indication in a DCI can be used to indicate such a configuration. Figure 7 An example of a signaling link that may be employed is shown. Figure 7 A UE 700 used as a SUE, a UE 702 used as a CUE, and a gNB 704 are shown. A connection 708 between the two UEs 700 and 702 is also shown. For this embodiment and other embodiments, the inter-UE connection 704 can be a 3GPP-specified connection (e.g., a sidelink or PC5 link) or a non-3GPP-specified connection (e.g., Wi-Fi, Bluetooth, Ethernet, etc.) or a non-standardized connection. The inter-UE connection 704 is used to transmit data and control information between UEs participating in UC MIMO. For example, in UC MIMO, when TBs are sent out from a common MAC entity (in this example, it is assumed that the common MAC entity is configured in the SUE 700), these TBs are sent to the CUE 702 through the inter-UE connection 708. The PHY layer of the CUE 702 then processes these TBs (performs channel coding, modulation, precoding, etc.) and sends them to the gNB 704. The same or different TBs may be passed from a common MAC entity located in the SUE 700 to the PHY layer of the CUE 702 and processed (performing channel coding, modulation, precoding, etc.) before being sent to the gNB 704. Typically, 710 shows downlink control signaling possibilities in the form of RRC or downlink control information (DCI) that can be used to set / control the configuration of the UE. 710 also shows uplink physical uplink shared channel (PUSCH) transmissions, which are uplink transmissions that send packets from the UE to the gNB using UCMIMO.

[0092] In some embodiments, the presence / absence of valid precoding information in the DCI is used to implicitly indicate whether closed-loop MIMO and open-loop MIMO are to be adopted. For example, the DCI can be used to indicate valid or invalid precoding information (e.g., precoder vector / matrix index), wherein the valid precoding information indicates that the UE uses the indicated valid precoder to perform closed-loop precoding operations accordingly, and the invalid precoding information indicates that the UE uses a predefined / preconfigured cyclic precoder to perform cyclic precoding operations for open-loop MIMO. Alternatively, an explicit indication may be included in the DCI to indicate closed-loop MIMO (mode) or open-loop MIMO (mode). For example, a 1-bit indication may be used to directly indicate that one of closed-loop MIMO and open-loop MIMO is to perform UC MIMO transmission. Alternatively, a 1-bit indication may be used to indicate switching between closed-loop MIMO and open-loop MIMO (e.g., when the bit is switched between two consecutive DCIs, switching from the current UC MIMO transmission mode (open-loop MIMO or closed-loop MIMO) to another UC MIMO mode). In some embodiments, the selection / switching between open-loop MIMO and closed-loop MIMO is indicated by MAC entity signaling such as a MAC control element (MAC CE).

[0093] The provided framework enables more flexible MIMO transmission for UC. Closed-loop UC MIMO can be used to improve UE and system throughput, while open-loop UC MIMO can be used to improve diversity and robustness, which may be beneficial for cell-edge UEs or UEs with relatively high mobility.

[0094] Common MAC / HARQ structure and procedures for UC MIMO

[0095] refer to Fig. 8A More details of a common MAC entity for uplink UC MIMO are described. A common MAC entity 800, PHY layers of two UEs 802, 804, and a gNB 806 are shown. The common MAC entity 800 may be configured in one of the UEs including the UE PHY layer 802 or 804 (in this case, the UE may be considered a master UE / primary UE / SUE), or in another device (e.g., another UE). The connection between the common MAC entity 800 and the individual UE PHY layers may be a wireless connection or a wired connection, and may be standardized (e.g., 3GPP, IEEE) or non-standardized. The common MAC entity 800 has a common HARQ entity 810 that manages the configuration of multiple HARQ processes. In some embodiments, the number of HARQ processes managed by the common HARQ entity 810 is configurable. Fig. 8ATwo HARQ processes 812, 814 are shown. In the gNB 806, there is a corresponding HARQ entity 820, which is configured with the corresponding HARQ processes 822, 824 shown in the gNB and the corresponding HARQ buffers 826, 828 for storing / decoding the received data managed under each HARQ process. It should be noted that the TB is not actually sent from the HARQ process 812 to the PHY layer of the UE for transmission (retransmission). The HARQ process is more like a function to manage the transmission (retransmission) of the TB. Similar aspects also apply to the receiving end, where the HARQ process itself does not actually process the received TB data, but manages the transmission (retransmission) of the TB by notifying the success / failure of data decoding.

[0096] The common HARQ entity supports the joint HARQ process. In this case, the uplink data (e.g., TB) transmission (retransmission) (transmission and retransmission of the same TB) under a certain HARQ process can be scheduled to be sent from different one or more UEs. The same or different redundancy versions (RV) of the same TB can be scheduled from different one or more UEs. Fig. 8A An example is shown, where the transmission (or retransmission) of TB#1 under joint HARQ process #1 is scheduled to be sent from UE#1 and UE#2 respectively. RV#0 of TB#1 can be scheduled from UE#1, and RV#2 of TB#1 can be scheduled from UE#2.

[0097] The joint HARQ process may also be referred to as a split HARQ process, indicating that the HARQ process is split between different UEs to manage the transmission / reception of the same TB. The joint HARQ process (or split HARQ process) may be configured to be associated with different physical shared channels running on different UEs, through which the corresponding transmission (retransmission) of the TB is performed, for example, a physical uplink shared channel (PUSCH) or a physical downlink shared channel (PDSCH). For example, the joint HARQ process #1 may be configured to be associated with the PUSCH or PDSCH on UE #1 and UE #2, respectively. Figure 8BAn example of such an association between HARQ processes and channels is shown. For example, HARQ process #1 is associated with corresponding physical shared channels (e.g., PUSCH and PDSCH) used by UE #1 and UE #2 to send / receive data, respectively, while HARQ process #2 is associated with corresponding physical shared channels (e.g., PUSCH and PDSCH) used by UE #2 to send / receive data. By configuring such an association, one or more UEs and gNBs can know that one or more TBs managed under a certain HARQ process are to be transmitted using corresponding physical shared channels such as PUSCH by one or more corresponding UEs participating in UC MIMO. Alternatively, a joint HARQ process can be configured to be associated with multiple corresponding UEs, through which transmission (retransmission) of the TBs managed by the joint HARQ process is performed.

[0098] In some embodiments, the common HARQ entity also supports separate HARQ processes (similar to conventional HARQ processes). In this case, the UL data (eg, TB) transmission (retransmission) of a TB is only scheduled from one UE. Fig. 8A An example is shown in which the transmission (or retransmission) of TB#2 under a separate HARQ process #2 is scheduled only from UE#2. It should be noted that the common HARQ entity that manages the separate HARQ process can be located somewhere other than the UE performing the transmission. For example, the HARQ entity can be located in one UE, while the TB transmission / reception managed by the HARQ entity can be performed in the PHY layer of another UE. In this case, the association between the HARQ process and the physical shared channel (e.g., PUSCH) on the PHY layer of the particular UE is configurable. For example, HARQ process #2 can be configured to be associated with the physical shared channel of UE#2.

[0099] One or both of the joint HARQ process and the separate HARQ process may be configured for one or more UEs. For example, HARQ process #1 may be configured as a joint (split) HARQ process, and HARQ process #2 may be configured as a separate HARQ process. The configuration including the association between the HARQ process and the corresponding physical shared channel of the participating one or more UEs may be indicated to the corresponding one or more UEs, for example, UE #1 and UE #2.

[0100] Through the above configuration, during transmission, the gNB can use scheduling to schedule transmissions (retransmissions) managed by two types of HARQ processes and combine these transmissions (retransmissions) accordingly at the gNB.

[0101] Alternatively, for UL UC transmission, in some embodiments, two or more HARQ entities are configured in a common MAC entity, with one HARQ entity corresponding to each UE participating in the UC transmission. Figure 8C An example is shown, showing HARQ entity #1 850 configured for UE #1 852 and HARQ entity #2 854 configured for UE #2 856. HARQ entity #1 850 supports HARQ process #1 860 to send TB #1 to gNB 870 via UE #1 852. HARQ entity #2 854 supports HARQ process #1 862 to send TB #1 to gNB 870 via UE #2 856. HARQ entity #2 854 also supports HARQ process #2 864 to send TB #2 to gNB 870 via UE #2 856. Since HARQ entity #1, HARQ process #1, HARQ entity #2, and HARQ process #1 are all used to send the same TB, i.e., TB #1 in this example, gNB 870 can combine these TBs together to improve reception performance. This combination can be soft combination (combining the soft symbols in the HARQ#1 buffer configured at the gNB for UE#1 and UE#2 respectively to store / decode the received TB) or hard combination (combining by the HARQ function in the MAC entity, for example, after either UE#1 or UE#2 successfully decodes the TB and passes the result to the HARQ entity), as shown by the dotted circle 872 at the gNB 870. Different RVs of the same TB can be sent through different HARQ processes supported by different HARQ entities. To this end, a certain relationship is established between different HARQ processes managed by different HARQ entities. For example, HARQ processes with the same HARQ process index under different HARQ entities can be predefined / preconfigured to send the same TB. For example, HARQ process #1 of HARQ entity #1 and HARQ process #1 of HARQ entity #2 can be predefined / preconfigured to send the same TB. In some embodiments, this relationship between different HARQ processes of different HARQ entities is configured through high-layer signaling such as RRC or indicated through dynamic signaling such as DCI, etc. Alternatively, this relationship can be achieved through dynamic scheduling by the gNB, which is a gNB-centric implementation and transparent to one or more UEs. For example, the gNB can schedule the transmission (retransmission) of the same HARQ process to the gNB through different one or more UEs, and at the gNB, the corresponding data received from the different one or more UEs are combined. Similarly, the association between the HARQ entity / HARQ process and the physical shared channel (e.g., PUSCH) of one or more UEs that can send corresponding data (managed by the HARQ entity / HARQ process) can be configurable.

[0102] Alternatively, for UL UC transmission, in some embodiments, two or more HARQ entities are configured in a common MAC entity. One or more HARQ entities are configured to support a joint (or split) HARQ process that manages only the transmission / reception of the same TB between multiple UEs. Other HARQ entities are configured to support separate HARQ processes that manage the transmission / reception of a TB only through one of the UEs. Different HARQ entities may be configured to be associated with different one or more UEs. For example, HARQ entity #1 may be configured to support only multiple joint (separate) HARQ processes between UE #1 and UE #2, while HARQ entity #2 is configured to support multiple separate HARQ processes on UE #1, and HARQ entity #3 is configured to support multiple separate HARQ processes on UE #2. The above configuration may include an association between a HARQ entity / HARQ process and a physical shared channel of one or more UEs or only one or more UEs, where there is data reception under the corresponding HARQ process.

[0103] Although the above detailed description focuses on uplink transmission, these embodiments can also be used for downlink transmission. Fig.9A , describes the details of the common MAC / HARQ structure and process for DL ​​UC MIMO transmission. The figure shows a common MAC entity 900, two UE PHY layers 902, 904, a gNB PHY layer 906 and a gNB MAC entity 908. The common MAC entity 900 can be configured in one of the UEs 902, 904, or configured at another location (e.g., another UE). The connection between the common MAC entity 900 and the individual UE PHY layers can be a wireless connection or a wired connection, and can be standardized (e.g., 3GPP, IEEE) or non-standardized. The common MAC entity 900 has a common HARQ entity 910 that manages the configuration of multiple HARQ processes. The number of HARQ processes managed by the common HARQ entity 910 can be configurable. Fig.9A Two HARQ processes 912, 914 are shown. In the gNB MAC entity 908, there is a corresponding HARQ entity 920; HARQ processes 922, 924 are shown in the gNB.

[0104] The framework shown supports joint HARQ processes. DL data (e.g., TB) transmission (retransmission) of a certain HARQ process can be scheduled to different one or more UEs. The same or different RVs of the same TB can be scheduled to different one or more UEs. For example, Fig.9AAs shown, the transmission or retransmission of TB#1 under HARQ process #1 is scheduled to UE#1 and UE#2. RV#0 of TB#1 can be scheduled out from UE#1, while RV#2 can be scheduled out from UE#2. The figure shows the corresponding HARQ#1 buffers 932, 934 in each UE, which are used to store / decode data received under the HARQ process HARQ#1 912. Alternatively, TB#1 with the same RV version can be broadcast (multicast) to multiple UEs (e.g., UE#1 and UE#2). Similar to uplink UC MIMO, for DL ​​UC MIMO, the joint HARQ process (or split HARQ process) can be configured to be associated with different physical shared channels running on different UEs, for example, the physical uplink shared channel (PDSCH) for the downlink. For example, the joint HARQ process #1 can be configured to be associated with the PDSCH channels configured on UE#1 and UE#2, respectively. By configuring this association, one or more UEs and the gNB may know that one or more TBs managed under a specific HARQ process may be received by one or more corresponding UEs participating in UC MIMO using a corresponding physical shared channel (e.g., PDSCH).

[0105] Individual HARQ processes are also supported (similar to conventional HARQ processes): in this case, the (re)transmission of DL data (eg, TB) of a certain HARQ process is scheduled to only one UE. Fig.9A An example is shown where the transmission (or retransmission) of TB#2 is scheduled only to UE#2. In this case, only UE#2 has a HARQ#2 buffer 936 for storing / decoding data received under the HARQ process HARQ#2 914. In this case, the association between the HARQ process and the physical shared channel (e.g., PDSCH) on the PHY layer of the particular UE is configurable. For example, HARQ process #2 can be configured to be associated with the physical shared channel of UE#2.

[0106] One or both of the joint HARQ process and the separate HARQ process can be configured for UC. For the joint HARQ process, data received by different one or more UEs under the same HARQ process can be combined to improve reception capabilities. This combination can be implemented in the PHY layer (soft symbols are passed between one or more UEs through the PHY layer UE-to-UE connection for soft combination); or in the common MAC entity through hard combination (for example, after decoding a data packet, any UE reports success as decoding the data packet successfully at the MAC entity).

[0107] In the above example, one end of the link has multiple UEs operating in UC mode, and the other end is the network (gNB or base station). In another embodiment, the other end is one or another group of UEs (to replace gNB), and a flexible framework similar to the above framework can be applied in this embodiment. This embodiment is more suitable for UE MIMO transmission for UE-to-UE communication.

[0108] The common MAC entity may be configured by the gNB or by the primary UE in a group of UEs formed for UC operation. The common MAC for DL / UL UC operation may be configured separately, for example, the common MAC may be configured for DL ​​only or UL only or both DL / UL.

[0109] Alternatively, for DL ​​UC transmission, two or more HARQ entities may be configured in a common MAC entity, with one HARQ entity corresponding to each UE participating in the UC transmission. Fig. 9B An example is shown.

[0110] For example, HARQ entity #1 970 is configured for UE #1 972 and HARQ entity #2 974 is configured for UE #2 976. HARQ entity #1 970 supports HARQ process #1 980 for receiving TB #1 from gNB 990 to UE #1 972. HARQ entity #2 974 supports HARQ process #1 982 for receiving TB #1 from gNB 990 to UE #2 976. HARQ entity #2 974 supports HARQ process #2 984 for receiving TB #2 from gNB 990 to UE #2 976. Alternatively, only HARQ entity #1 and HARQ process #1 may be used to broadcast TB #1 to UE #1 and UE #2, respectively. Since HARQ entity #1, HARQ process #1 and HARQ entity #2 HARQ process #1 are all used to receive the same TB, i.e., TB #1 in this example, these TBs can be combined at the UE to improve reception performance. This combination can be a soft combination (combining the soft symbols in the HARQ buffers in UE #1 and UE #2 to decode the TB, as shown in dotted circle 996) or a hard combination (combining through the HARQ function in the common MAC, for example, after either UE #1 or UE #2 successfully decodes the TB, it is considered successful, as shown in dotted circle 998). Different RVs of the same TB can be sent through different HARQ processes supported by different HARQ entities. To this end, it is necessary to establish a certain relationship between different HARQ processes managed by different HARQ entities. For example, HARQ processes with the same HARQ process index under different HARQ entities can be predefined / preconfigured to send the same TB. For example, the HARQ process #1 of HARQ entity #1 and the HARQ process #1 of HARQ entity #2 can be predefined / preconfigured to receive the same TB. This relationship between different HARQ processes of different HARQ entities can be configured to one or more UEs to send the same TB, so that one or more UEs can appropriately (for example, when one or more TBs have different RVs) combine the same TB. The configuration can be indicated by high-level signaling such as RRC or by dynamic signaling such as DCI. Similarly, the association between the HARQ entity / HARQ process and the physical shared channel (for example, the PDSCH of one or more UEs) that can receive corresponding data (managed by the HARQ entity / HARQ process) can be configurable.

[0111] Alternatively, for DL ​​UC transmission, in some embodiments, two or more HARQ entities are configured in a common MAC entity. One or more HARQ entities are configured to support a joint (or split) HARQ process that manages only the reception of the same TB between multiple UEs. Other HARQ entities are configured to support separate HARQ processes that manage the reception of a TB from one UE. Different HARQ entities may be configured to be associated with different one or more UEs. For example, HARQ entity #1 may be configured to support only multiple joint (separate) HARQ processes between UE #1 and UE #2, while HARQ entity #2 is configured to support multiple separate HARQ processes on UE #1, and HARQ entity #3 is configured to support multiple separate HARQ processes on UE #2. The above configuration may include an association between the HARQ entity / HARQ process and a physical shared channel of one or more UEs that perform data reception under the corresponding HARQ process.

[0112] Common DCI Design for UC MIMO

[0113] To schedule UC MIMO transmissions, in some embodiments, a first DCI is sent including information for the SUE, and another DCI is sent including information for the CUE; each DCI is a separate UE DCI. In other embodiments, a common (group) DCI is sent including scheduling information for both the SUE and the CUE. In some embodiments, whether independent DCI or common DCI is used is configurable. In some embodiments, there is an indication in the DCI to indicate whether the DCI is a common DCI; if there is no such indication, the DCI is a separate UE DCI. In another embodiment, closed-loop MIMO uses separate DCIs, while open-loop MIMO uses common DCIs.

[0114] The following is a specific example of scheduling information for transmission of two TBs under closed-loop MIMO, where, for individual DCIs, each DCI includes a set of scheduling information, and for common DCIs, each DCI includes one or two sets of scheduling information, and each SUE / CUE corresponds to (shares) a set of scheduling information:

[0115] One or two groups of resource allocations for PUSCH (one group of resource allocations for each SUE / CUE);

[0116] One or two HARQ process IDs and one / two RV indexes (one ID and one index for each SUE / CUE);

[0117] One or two groups of MCS (one group of MCS for each SUE / CUE);

[0118] For CB, two sets of precoding information (one set of precoding information for each SUE / CUE);

[0119] For NCB, two SRS resource indicators (SRS) (one for each SUE / CUE);

[0120] One or two groups of TPCs (one group of TPCs for each SUE / CUE).

[0121] The following is a specific example of scheduling information for a TB under open-loop MIMO, where, for individual DCIs, each DCI includes a set of scheduling information, and for common DCIs, each DCI includes one or two sets of scheduling information, and each SUE / CUE corresponds to (shares) a set of scheduling information:

[0122] One or two groups of resource allocations for PUSCH (one group of resource allocations for each SUE / CUE);

[0123] A HARQ process ID and one / two RV indexes (one ID and index for each SUE / CUE);

[0124] One or two groups of MCS (one group of MCS for each SUE / CUE);

[0125] One or two TPCs (one TPC for each SUE / CUE).

[0126] In some embodiments, when common DCI is used, the common DCI is sent in the search space (SS) of both SUE / CUE. In this case, the common DCI is sent twice with the same content. In another embodiment, the common DCI is sent only in the SS of the SUE, and the SUE sends the scheduling information to the CUE via the inter-UE connection.

[0127] In some embodiments, a common DCI or a separate DCI may be used, and the UE determines which DCI to use based on an indication in the DCI. In another embodiment, the UE determines the common DCI and the separate DCI based on the size of the DCI. The size of the common DCI is greater than the size of the separate UE DCI.

[0128] The configurable framework provided for UC MIMO may provide one or more of the following benefits:

[0129] Open-loop MIMO and closed-loop MIMO including individual precoding and joint precoding;

[0130] Protocol structure with common MAC entity and common / separate HARQ entities;

[0131] Support different types of HARQ processes, including joint HARQ process and separate HARQ process;

[0132] The ability to switch between open-loop MIMO and closed-loop MIMO or other configurations based on explicit or implicit signaling.

[0133] Numerous modifications and variations of the present disclosure are possible in light of the above teachings.It is therefore to be understood that within the scope of the appended claims, the present disclosure may be practiced otherwise than as specifically described herein.

Claims

1. A method in a first device, characterized in that include: receiving a configuration of a common media access control (MAC) entity in the first device for cooperative transmission of a plurality of devices including the first device; Sending a transmission block TB of data to a network device as part of the collaborative transmission; A TB of data is sent to another device among the plurality of devices for the other device to transmit to the network device as part of the collaborative transmission.

2. The method according to claim 1, characterized in that The common MAC entity includes a common hybrid automatic repeat request HARQ entity or multiple HARQ entities.

3. The method according to claim 1, characterized in that The common MAC entity comprises a common HARQ entity configured with one or more HARQ processes, each of the one or more HARQ processes being associated with one or more of the plurality of apparatuses.

4. The method according to claim 1, characterized in that: The sending of the TB of data to the network device and the sending of the TB of data to another device both involve the same TB of data; The common MAC entity includes a common HARQ entity configured with a HARQ process for managing transmission of the same TB data by the first device and the other device.

5. The method according to claim 1, characterized in that: The sending of the TB of data to the network device and the sending of the TB of data to another device among the plurality of devices both involve the same TB of data; The public MAC entity includes a first HARQ entity and a second HARQ entity, wherein the first HARQ entity is configured with a first HARQ process for managing the transmission of the TB data to the network device, and the second HARQ entity is configured with a second HARQ process for managing the transmission of the same TB data by the other device.

6. The method according to claim 1, characterized in that The common MAC entity includes a first HARQ entity and a second HARQ entity, wherein the first HARQ entity is configured with a first HARQ process for managing the transmission of a first TB of data by the first device, and the second HARQ entity is configured with a second HARQ process for managing the transmission of a second TB of data by the other device.

7. The method according to claim 1, characterized in that The common MAC entity includes a first HARQ entity associated with TB transmission of the first device and other HARQ entities associated with TB transmission of another device among the multiple devices, wherein, In case of repeated TB transmission, the first HARQ entity is configured with a first HARQ process associated with managing the first device sending TB data to the network device, and the second HARQ entity is configured with another HARQ process associated with managing repeated transmission of the same TB data by the other device; In the case of split TB transmission, the first HARQ entity is configured with a first HARQ process related to the first device sending TB data to the network device, and the second HARQ entity is configured with a second HARQ process related to the transmission of second TB data by the other device.

8. The method according to claim 1, characterized in that The common MAC entity supports outputting duplicate TBs and split TBs to a physical PHY layer of the plurality of devices, the method further comprising: In the case where the MAC entity outputs duplicate TBs, the sending of TB data to another device includes: sending TB data identical to the TB data sent by the first device to the network device; In a case where the MAC entity outputs the split TB, the sending the TB data to another device includes: sending TB data different from the TB data sent by the first device to the network device.

9. The method according to any one of claims 1 to 8, characterized in that The configuration is used to configure whether to use open-loop multiple-input multiple-output MIMO or closed-loop MIMO for the cooperative transmission.

10. The method according to claim 9, characterized in that In case of configuring the first apparatus to use closed-loop MIMO, the configuration is further used to indicate whether to use a precoder indicated by the network or a precoder based on measurement of a downlink reference signal.

11. The method according to claim 9, characterized in that In case that the first device is configured to use closed-loop MIMO, the configuration is further used to indicate whether to use coherent precoding or non-coherent precoding.

12. The method according to any one of claims 1 to 11, characterized in that Also includes: receiving downlink control information DCI for scheduling transmission of the first device or scheduling transmission of the first device and the another device; In a case where the DCI schedules transmissions of the first device and the other device, signaling information scheduling transmissions of the other device is sent to the other device.

13. The method according to claim 12, characterized in that The DCI includes: Whether the DCI schedules transmission of the first apparatus or schedules transmission of the first apparatus and the another apparatus is an explicit indication or an implicit indication.

14. A method in a network device, characterized in that: include: Sending a configuration of a common media access control (MAC) entity in the first device to a first device for cooperative transmission of a plurality of devices including the first device; receiving a transmission block TB of data from the first device as part of the collaborative transmission; A TB of data is received from another device among the plurality of devices as part of the collaborative transmission.

15. The method according to claim 14, characterized in that The common MAC entity includes a common hybrid automatic repeat request HARQ entity or multiple HARQ entities.

16. The method according to claim 14, characterized in that The common MAC entity comprises a common HARQ entity configured with one or more HARQ processes, each of the one or more HARQ processes being associated with one or more of the plurality of apparatuses.

17. The method according to claim 14, characterized in that The receiving of TB data from the first device and the receiving of TB data from another device both relate to the same TB data; The common MAC entity includes a common HARQ entity, and the TB data received from the first device and the same TB data received from the other device are managed by the same HARQ process configured for the common HARQ entity.

18. The method according to claim 14, characterized in that The receiving of TB data from the first device and the receiving of TB data from another device among the plurality of devices both relate to the same TB data; The common MAC entity includes a first HARQ entity and a second HARQ entity, wherein TB data received from the first device is managed by a first HARQ process configured to the first HARQ entity, and the same TB data received from the other device is managed by a second HARQ process configured to the second HARQ entity.

19. The method according to claim 14, characterized in that The common MAC entity includes a first HARQ entity and a second HARQ entity, wherein the first HARQ entity is configured with a first HARQ process for managing the transmission of a first TB of data by the first device, and the second HARQ entity is configured with a second HARQ process for managing the transmission of a second TB of data by the other device.

20. The method according to claim 14, characterized in that The common MAC entity includes a first HARQ entity associated with a TB transmission of the first device and another HARQ entity associated with a TB transmission of the another device among the plurality of devices, wherein, In case of repeated TB transmission, the first HARQ entity is configured with a first HARQ process associated with managing the first device sending TB data to the network device, and the second HARQ entity is configured with another HARQ process associated with managing repeated transmission of the same TB data by the other device; In the case of split TB transmission, the first HARQ entity is configured with a first HARQ process related to managing the first device sending TB data to the network device, and the second HARQ entity is configured with a second HARQ process related to managing the transmission of second TB data by the other device.

21. The method according to any one of claims 14 to 20, characterized in that The configuration is used to configure whether to use open-loop multiple-input multiple-output MIMO or closed-loop MIMO for the cooperative transmission.

22. The method according to claim 21, characterized in that In case of configuring the first apparatus to use closed-loop MIMO, the configuration is further used to indicate whether to use a precoder indicated by the network or a precoder based on measurement of a downlink reference signal.

23. The method according to claim 21, characterized in that In case that the first device is configured to use closed-loop MIMO, the configuration is further used to indicate whether to use coherent precoding or non-coherent precoding.

24. The method according to any one of claims 21 to 23, characterized in that Also includes: Sending downlink control information (DCI) for scheduling transmission of the first device or scheduling transmission of the first device and the another device.

25. The method according to claim 24, characterized in that The DCI includes: Whether the DCI schedules transmission for the first apparatus or schedules transmission for the first apparatus and the another apparatus is an explicit indication or an implicit indication.

26. A device, characterized in that include: A processor and a memory, wherein the device is configured to execute the method according to any one of claims 1 to 13.

27. A network device, characterized in that: include: A processor and a memory, wherein the apparatus is configured to execute the method according to any one of claims 14 to 25.

28. A method, characterized in that include: The second device sends the configuration of a common media access control MAC entity in the first device to the first device, for cooperative transmission of multiple devices including the first device; The first device receives the configuration; The first device sends a transmission block TB data to the second device as part of the collaborative transmission; A second device receives TB of data from the first device; and receiving a TB of data from another device among the plurality of devices as part of the collaborative transmission.

Images