Wireless transmit / receive unit and method related to enhancement of physical channels in multiple TRPs
By enhancing the reliability of the physical channel in multi-transmission/receiving point operations, the problem of insufficient physical channel reliability in the prior art is solved, and a higher data transmission success rate and quality is achieved, especially the robustness improvement under complex channel conditions.
Patent Information
- Application Number
- CN202411483278.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2021-01-12
- Filing Date
- 2021-04-07
- Publication Date
- 2025-07-15
- Estimated Expiration
- 2041-04-07
AI Technical Summary
In the prior art, in multi-transmission/receive point (MTRP) operation, the reliability enhancement of physical channels has not been fully solved, especially in wireless communications, where there is room for improvement in the reliability of the physical downlink control channel (PDCCH), physical uplink control channel (PUCCH) and physical uplink shared channel (PUSCH).
By enhancing physical channels in multi-transmission/receive point (MTRP) operations, including reliability enhancement support for PDCCH, such as CORESET combination, DCI repeat timing, and channel state information (CSI) feedback; reliability enhancement for PUCCH, such as repeat combination and spatial filter configuration; reliability enhancement for PUSCH, such as spatial relationship determination and dynamic authorization.
The reliability and robustness of the physical channel in multi-transmission/receive point operation is improved, the reliability and stability of wireless communication is enhanced, especially under complex channel conditions, and the success rate and quality of data transmission are improved.
Smart Images

Figure CN119543999B_ABST
Abstract
Description
[0001] This divisional application is a divisional application of the application with the filing date of April 7, 2021, application number 202180031953.2, and invention title "Enhancement of Physical Channels in Multiple TRPs".
[0002] Cross - reference to related applications
[0003] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 006,977, filed April 8, 2020; U.S. Provisional Patent Application No. 63 / 061,281, filed August 5, 2020; U.S. Provisional Patent Application No. 63 / 091,545, filed October 14, 2020; and U.S. Provisional Patent Application No. 63 / 136,306, filed January 12, 2021, the entire disclosures of which are incorporated herein by reference. Background of the Invention
[0004] Mobile communication using wireless communication continues to evolve. The fifth generation can be referred to as 5G. Previous (conventional) mobile communication can be, for example, the fourth generation (4G) Long - Term Evolution (LTE). Summary of the Invention
[0005] Systems, methods, and tools associated with enhancement of physical channels in multi - transmission / reception point (MTRP) operation are disclosed herein. Reliability enhancements can be provided for the physical downlink control channel (PDCCH), including, for example, enhanced support for control resource set (CORESET) combinations. Reliability enhancements for the PDCCH can include enhancements for determining downlink control information (DCI) repetition timing, determining transmission configuration indicator (TCI) selection for data scheduled with DCI repetition, determining PDCCH candidates from multiple beams, and detecting PDCCH decoding failures and related behaviors including channel state information (CSI) feedback. Reliability enhancements can be provided for the physical uplink control channel (PUCCH), including, for example, activation / deactivation of repetition combining, resource selection, spatial filter configuration tables for repetition, and multiplexing in cases of overlap with the physical uplink shared channel (PUSCH). Reliability enhancements can be provided for the PUSCH, including, for example, spatial relationship determination and signaling, configured and dynamic grant enhancements, and spatial filter configuration and repeated transmission based on DCI field values and / or spatial filter configuration tables.
[0006] A wireless transmit / receive unit (WTRU) can be used for enhanced transmission in MTRP operation. The WTRU can receive SRI information. For example, the SRI information can include multiple sets of SRI patterns. The WTRU can receive DCI associated with uplink scheduling information. The DCI can indicate a transmission repetition number, a redundancy value, and / or a spatial domain resource allocation (SDRA) indicator. The WTRU can determine, for example, an SRI pattern from a set of sounding reference signal resource indicator (SRI) patterns. The WTRU can determine an SRI pattern based on the SDRA indicator, the repetition number, and / or the redundancy value. The SRI pattern can be associated with an SRI sequence. The WTRU can determine (e.g., based on the SRI pattern) a spatial relationship for repeated transmission (e.g., PUSCH repeated transmission). The WTRU can determine a spatial relationship for repeated transmission based on the SRI sequence (e.g., the first repeated transmission uses the first SRI in the sequence, the second repeated transmission uses the second SRI in the sequence, and so on). The WTRU can use the determined spatial relationship to send repeated transmission (e.g., PUSCH repeated transmission). The WTRU can determine a transmission time associated with repeated transmission (e.g., PUSCH repeated transmission) based on, for example, an offset value (e.g., K2 value).
[0007] A wireless / transmit unit (WTRU) can determine whether to adopt a single TRP operation mode or a multi-TRP operation mode in combination with PUSCH / PUCCH transmission. The WTRU can determine a spatial filter configuration based on a dynamic switch between the single TRP mode and the multi-TRP mode. BRIEF DESCRIPTION OF THE DRAWINGS
[0008] Figure 1A is a system diagram showing an exemplary communication system in which one or more of the disclosed embodiments can be implemented.
[0009] Figure 1B is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that can be used within the communication system shown in accordance with an embodiment. Figure 1A shown communication system.
[0010] Figure 1C is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that can be used within the communication system shown in accordance with an embodiment. Figure 1A shown communication system.
[0011] Figure 1D is a system diagram showing another exemplary RAN and another exemplary CN that can be used within the communication system shown in accordance with an embodiment. Figure 1A shown communication system.
[0012] Figure 2It is a diagram showing examples of single DCI and multi-DCI MTRP configurations.
[0013] Figure 3 It is a diagram showing examples of multi-TRP enhancements to physical channels.
[0014] Figure 4 It is a diagram showing an exemplary DCI repetition offset.
[0015] Figure 5 It is a diagram showing an example of PUCCH repetition for enhancing PUCCH.
[0016] Figure 6 It is a diagram showing an example of enhanced PUCCH transmission with spatial relation cycling.
[0017] Figure 7 It is a diagram showing an example of resource configuration for PUCCH repetition based on the K1 value.
[0018] Figure 8 It is a diagram showing an exemplary table linking repetition and spatial filter patterns.
[0019] Figure 9 It is a diagram showing an example of resource configuration for PUSCH repetition based on SDRA and TDRA.
[0020] Figure 10 It is a diagram showing an exemplary DCI having a field linked to a table with repetition and spatial filter patterns.
[0021] Figure 11 It shows resource selection based on dynamic switching between single TRP and multi-TRP. Detailed Description
[0022] Figure 1A It is a schematic diagram showing an exemplary communication system 100 in which one or more of the disclosed embodiments can be implemented. The communication system 100 can be a multi-access system that provides content such as voice, data, video, messages, broadcasts, etc. to multiple wireless users. The communication system 100 can enable multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, the communication system 100 can employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tail unique word discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.
[0023] As Figure 1A shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any one of which may be referred to as a "station" and / or "STA") may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop computer, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., a robot and / or other wireless devices operating in an industrial and / or automated processing chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any one of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.
[0024] The communication system 100 may also include base station 114a and / or base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an evolved Node B (eNB), a home Node B, a home evolved Node B, a next-generation Node B (gNB), an NR Node B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each depicted as a single element, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.
[0025] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographical area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in an embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.
[0026] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) may be used to establish air interface 116.
[0027] More specifically, as noted above, communication system 100 may be a multi-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 104 / 113 and WTRUs 102a, 102b, 102c may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117. WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).
[0028] In an embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-A Pro to establish air interface 116.
[0029] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may use New Radio (NR) to establish air interface 116.
[0030] In an embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Accordingly, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions to / from multiple types of base stations (e.g., eNBs and gNBs).
[0031] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., wireless fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rate for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.
[0032] Figure 1AThe base station 114b therein can be, for example, a wireless router, a home Node B, a home evolved Node B, or an access point, and can utilize any suitable RAT to facilitate wireless connections in a local area such as a commercial venue, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for drones), a road, etc. In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As Figure 1A shown, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.
[0033] The RAN 104 / 113 can communicate with the CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or Internet protocol voice technology (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 can provide call control, billing services, location-based services, prepaid calls, Internet connections, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not shown in Figure 1A it, it should be understood that the RAN 104 / 113 and / or the CN 106 / 115 can communicate directly or indirectly with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113 that can utilize NR radio technology, the CN 106 / 115 can also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.
[0034] CN 106 / 115 can also act as a gateway for WTRU 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 can include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 can include a global system of interconnected computer networks and devices that use common communication protocols such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The network 112 can include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 can include another CN connected to one or more RANs, which can employ the same RAT as the RAN 104 / 113 or a different RAT.
[0035] Some or all of the WTRU 102a, 102b, 102c, 102d in the communication system 100 can include multi-mode capabilities (e.g., the WTRU 102a, 102b, 102c, 102d can include multiple transceivers for communicating with different wireless networks over different wireless links). For example, Figure 1A the illustrated WTRU 102c can be configured to communicate with a base station 114a that can employ a cellular-based radio technology and with a base station 114b that can employ an IEEE 802 radio technology.
[0036] Figure 1B is a system diagram showing an exemplary WTRU 102. As Figure 1B shown, the WTRU 102 can include a processor 118, a transceiver 120, transmit / receive elements 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, among others. It should be understood that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with the embodiments.
[0037] The processor 118 can be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 can execute signal encoding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to a transceiver 120, which can be coupled to a transmit / receive element 122. Although Figure 1B the processor 118 and the transceiver 120 are depicted as separate components, it should be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.
[0038] The transmit / receive element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via an air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive RF and optical signals. It should be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.
[0039] Although the transmit / receive element 122 is depicted as a single element in Figure 1B the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can employ MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 116.
[0040] The transceiver 120 can be configured to modulate the signals to be transmitted by the transmit / receive element 122 and demodulate the signals received by the transmit / receive element 122. As noted above, the WTRU 102 can have multi-mode capabilities. For example, thus, the transceiver 120 can include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).
[0041] The processor 118 of the WTRU 102 may be coupled to the speaker / microphone 124, keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from any type of suitable memory (such as the non-removable memory 130 and / or the removable memory 132) and store data in any type of suitable memory. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from a memory that is not physically located on the WTRU 102 (such as on a server or a home computer (not shown)) and store data in that memory.
[0042] The processor 118 may receive power from a power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for powering the WTRU 102. For example, the power supply 134 may include one or more dry battery packs (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), a solar cell, a fuel cell, etc.
[0043] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information via an air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with the embodiments.
[0044] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and / or hardware modules that provide additional features, functions, and / or wired or wireless connections. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geographical location sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.
[0045] WTRU 102 may include a full-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., chokes) or via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WRTU 102 may include a half-duplex radio, for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)).
[0046] Figure 1C is a system diagram showing RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 may employ E-UTRA radio technology to communicate with WTRU 102a, 102b, 102c via air interface 116. RAN 104 may also communicate with CN 106.
[0047] RAN 104 may include evolved Node Bs 160a, 160b, 160c, but it should be understood that RAN 104 may include any number of evolved Node Bs while remaining consistent with the embodiment. Each of evolved Node Bs 160a, 160b, 160c may include one or more transceivers to communicate with WTRU 102a, 102b, 102c via air interface 116. In an embodiment, evolved Node Bs 160a, 160b, 160c may implement MIMO technology. Thus, evolved Node B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from WTRU 102a.
[0048] Each of evolved Node Bs 160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, etc. As Figure 1C shown, the evolved Node Bs 160a, 160b, and 160c may communicate with each other via the X2 interface.
[0049] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. Although each of the foregoing elements is depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.
[0050] The MME 162 may be connected to each of the evolved Node Bs 162a, 162b, and 162c in the RAN 104 via the S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide control plane functions for handover between the RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.
[0051] The SGW 164 may be connected to each of the evolved Node Bs 160a, 160b, and 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during handover between evolved Node Bs, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.
[0052] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to a packet switched network such as the Internet 110 to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.
[0053] CN 106 may facilitate communication with other networks. For example, CN 106 may provide the WTRUs 102a, 102b, 102c with access to a circuit-switched network such as the PSTN 108 to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and the PSTN 108 or may communicate with the IP gateway. Additionally, CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.
[0054] Although the WTRU is described as a wireless terminal in Figures 1A to 1D it is contemplated that in some representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.
[0055] In a representative embodiment, the other network 112 may be a WLAN.
[0056] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or an interface with a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or from the BSS. Traffic originating outside the BSS and destined for an STA may reach the STA through the AP and may be delivered to the STA. Traffic originating from an STA and destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS may be sent through the AP, e.g., where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between the source and destination STAs (e.g., directly between them) using direct link setup (DLS). In some representative embodiments, DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within the IBSS or using the IBSS (e.g., all STAs) may communicate directly with each other. The IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode in this document.
[0057] When operating in an 802.11ac infrastructure operation mode or a similar operation mode, the AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be of a fixed width (e.g., 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may be the operation channel of the BSS and may be used by the STA to establish a connection with the AP. In some representative embodiments, for example, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) may be implemented in an 802.11 system. For CSMA / CA, the STA (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.
[0058] High Throughput (HT) STAs may communicate using a 40 MHz wide channel, e.g., by combining the primary 20 MHz channel with an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel.
[0059] Very High Throughput (VHT) STAs may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels may be formed by combining consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels or by combining two non - consecutive 80 MHz channels (which may be referred to as an 80 + 80 configuration). For the 80 + 80 configuration, after channel coding, the data may pass through a segment parser that may divide the data into two streams. Each stream may be separately processed with an Inverse Fast Fourier Transform (IFFT) and time - domain processing. These streams may be mapped to two 80 MHz channels and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations for the 80 + 80 configuration described above may be reversed and the combined data may be sent to the Medium Access Control (MAC).
[0060] 802.11af and 802.11ah support operation modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, the channel operation bandwidth and carriers are reduced in 802.11af and 802.11ah. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine type communication, such as MTC devices in a macro coverage area. The MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. The MTC devices may include a battery with a battery life higher than a threshold (e.g., to maintain a very long battery life).
[0061] A WLAN system that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operation bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or restricted by the STA (which supports the minimum bandwidth operation mode) from all STAs operating in the BSS. In an example of 802.11ah, for an STA (e.g., an MTC type device) that supports (e.g., only supports) the 1 MHz mode, the primary channel may be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because an STA (only supporting the 1 MHz operation mode) is transmitting to the AP, the entire available frequency band may be considered busy even if most of the frequency bands remain idle and may be available.
[0062] In the United States, the available frequency band for 802.11ah is 902 MHz to 928 MHz. In Korea, the available frequency band is 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is 916.5 MHz to 927.5 MHz. The total available bandwidth for 802.11ah is 6 MHz to 26 MHz, depending on the country code.
[0063] Figure 1D Is a system diagram showing RAN 113 and CN 115 according to one embodiment. As noted above, RAN113 may communicate with WTRU 102a, 102b, 102c via air interface 116 using NR radio technology. RAN 113 may also communicate with CN115.
[0064] The RAN 113 may include gNBs 180a, 180b, 180c, but it should be understood that, while remaining consistent with the embodiments, the RAN 113 may include any number of gNBs. Each of the gNBs 180a, 180b, 180c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c via the air interface 116. In an embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to the WTRU 102a and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive a coordinated transmission from the gNB 180a and the gNB 180b (and / or gNB 180c).
[0065] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different parts of the radio transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using various or scalable length subframes or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or having an absolute time length that continuously varies).
[0066] gNBs 180a, 180b, 180c can be configured to communicate with WTRUs 102a, 102b, 102c in a stand-alone configuration and / or a non-stand-alone configuration. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without accessing other RANs (e.g., such as evolved Node Bs 160a, 160b, 160c). In the stand-alone configuration, WTRUs 102a, 102b, 102c can use one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In the non-stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with or be connected to gNBs 180a, 180b, 180c while also communicating with or being connected to other RANs (such as evolved Node Bs 160a, 160b, 160c). For example, WTRUs 102a, 102b, 102c can implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node Bs 160a, 160b, 160c substantially simultaneously. In the non-stand-alone configuration, evolved Node Bs 160a, 160b, 160c can be used as a mobility anchor for WTRUs 102a, 102b, 102c, and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, 102c.
[0067] Each of gNBs 180a, 180b, 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As Figure 1D shown, gNBs 180a, 180b, 180c can communicate with each other via the Xn interface.
[0068] Figure 1DThe shown CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possibly data networks (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.
[0069] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may be used as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selection of a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases (such as services relying on ultra-reliable low-latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc.). The AMF 162 may provide control plane functions for handover between the RAN 113 and other RANs (not shown) employing other radio technologies (such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi).
[0070] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.
[0071] The UPFs 184a, 184b may be connected via the N3 interface to one or more of the gNBs 180a, 180b, 180c in the RAN 113, which may provide the WTRUs 102a, 102b, 102c with access to a packet switched network such as the Internet 110 to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.
[0072] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108, or may communicate with the IP gateway. Additionally, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In an embodiment, the WTRUs 102a, 102b, 102c may be connected to the DNs 185a, 185b via the UPFs 184a, 184b through the N3 interface to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the local data network (DN) 185a, 185b.
[0073] In view of Figures 1A to 1D and Figures 1A to 1D the corresponding descriptions, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more emulation devices (not shown): WTRU102a-d, base stations 114a-b, evolved Node Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMF182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device described herein. The emulation device(s) may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the emulation device(s) may be used to test other devices and / or simulate network and / or WTRU functionality.
[0074] The simulation device can be designed to implement one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more simulation devices can perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to another device for testing purposes and / or can perform tests using over-the-air wireless communication.
[0075] The one or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test laboratory and / or in a test scenario of a non-deployed (e.g., test) wired and / or wireless communication network to implement tests of one or more components. The one or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit system (e.g., which can include one or more antennas) can be used by the simulation device to transmit and / or receive data.
[0076] Systems, methods, and tools associated with enhancing physical channels in multi-transmit / receive point (MTRP) operation are disclosed herein. Reliability enhancements can be provided for the physical downlink control channel (PDCCH), including, for example, enhanced support for control resource set (CORESET) combinations. Reliability enhancements for the PDCCH can include enhancements for determining downlink control information (DCI) repetition timing, determining transmission configuration indicator (TCI) selection for data scheduled with DCI repetition, determining PDCCH candidates from multiple beams, and detecting PDCCH decoding failures and related behaviors including channel state information (CSI) feedback. Reliability enhancements can be provided for the physical uplink control channel (PUCCH), including, for example, activation / deactivation of repetition combinations, resource selection, spatial filter configuration tables for repetition, and multiplexing in the case of overlap with the physical uplink shared channel (PUSCH). Reliability enhancements can be provided for the PUSCH, including, for example, spatial relationship determination and signaling, configured and dynamic grant enhancements, and spatial filter configuration and repeated transmission based on DCI field values and / or spatial filter configuration tables.
[0077] A wireless transmit / receive unit (WTRU) can be used for enhanced transmission in MTRP operation. The WTRU can receive SRI information. For example, the SRI information can include multiple sets of SRI patterns. The WTRU can receive DCI associated with uplink scheduling information. The DCI can indicate a transmission repetition number, a redundancy value, and / or a spatial domain resource allocation (SDRA) indicator. The WTRU can determine, for example, an SRI pattern from a set of sounding reference signal resource indicator (SRI) patterns. The WTRU can determine an SRI pattern based on the SDRA indicator, the repetition number, and / or the redundancy value. The SRI pattern can be associated with an SRI sequence. The WTRU can determine (e.g., based on the SRI pattern) a spatial relationship for repeated transmission (e.g., PUSCH repeated transmission). The WTRU can determine a spatial relationship for repeated transmission based on the SRI sequence (e.g., the first repeated transmission uses the first SRI in the sequence, the second repeated transmission uses the second SRI in the sequence, and so on). The WTRU can use the determined spatial relationship to send repeated transmission (e.g., PUSCH repeated transmission). The WTRU can determine a transmission time associated with repeated transmission (e.g., PUSCH repeated transmission) based on, for example, an offset value (e.g., K2 value).
[0078] A wireless / transmit unit (WTRU) can determine whether to adopt a single TRP operation mode or a multi-TRP operation mode in combination with PUSCH / PUCCH transmission. The WTRU can determine a spatial filter configuration based on a dynamic switch between the single TRP mode and the multi-TRP mode.
[0079] Multi-transmit / receive point (MTRP) operation (e.g., in New Radio (NR)) can be supported. The WTRU can receive and process physical downlink control channel (PDCCH) and physical downlink shared channel (PDSCH) transmissions. In an example, the channel transmissions described herein (such as PDCCH and PDSCH transmissions) can be NR transmissions. For example, NR physical downlink control channel and NR physical downlink shared channel transmissions. The channels mentioned herein (e.g., PDCCH, PDSCH, PUCCH, PUSCH, etc.) can refer to channel transmissions (e.g., the received or transmitted channel transmissions).
[0080] Figure 2 It is a diagram showing examples of single downlink control information (DCI) and multi-DCI MTRP configurations. Figure 2Two exemplary scenarios of downlink MTRP operation with a primary TRP (P-TRP) and a secondary TRP (S-TRP) are shown. In the first exemplary scenario (e.g., Scenario 1), a single PDCCH can schedule a single PDSCH, where separate layers can be transmitted from separate TRPs. In the second exemplary scenario (e.g., Scenario 2), multiple PDCCHs can schedule (e.g., can each schedule) corresponding PDSCHs, where the PDSCHs (e.g., each PDSCH) can be transmitted from separate TRPs. NR can support a limited number of PDSCHs and / or PDCCHs. In an example, the maximum number of PDSCHs can be two, and the maximum number of PDCCHs can be two.
[0081] Multi-TRP transmission can be implemented, for example, for the downlink (DL) shared data channel, e.g., for enhanced mobile broadband (eMBB) and ultra-reliable low-latency (URLLC) scenarios. Multiple transmission schemes (e.g., four transmission schemes) for the PDSCH can enhance the reliability and robustness of downlink data transmission (e.g., for URLLC). Additional resources can be used in the spatial, frequency, and time domains, e.g., to support the transmission schemes. The additional resources can be used, for example, to achieve a lower code rate for transmission and / or support the repetition of the original transmission (e.g., depending on the transmission scheme).
[0082] Operations in frequency range 1 (FR1) and range 2 (FR2) can be enhanced. The reliability and robustness enhancements of the PDSCH can be extended to other physical channels (e.g., PDCCH, physical uplink shared channel (PUSCH), and / or physical uplink control channel (PUCCH)). The enhancements can use multi-TRP and / or multi-panel functionality. Quasi-co-location (QCL) and transmission configuration indicator (TCI) related enhancements can enable inter-cell MTRP with multi-DCI-based multi-PDSCHs. Beam management can be enhanced. Multiple-input multiple-output (MIMO) can be applied to MTRP to support, for example, high-speed train (HST) scenarios in a single frequency network (SFN).
[0083] Reliability enhancements for physical channels (e.g., PDCCH, PUCCH, and PUSCH) are disclosed, e.g., as Figure 3 shown.
[0084] Figure 3FIG. is an example showing multi-TRP enhancements to physical channels (e.g., PDCCH, PUCCH, and / or PUSCH). In an example (e.g., a single-TRP system), a physical channel may be transmitted over a channel with poor channel conditions, which may, for example, degrade reception performance. The connection between the WTRU and the TRP may fail, for example, due to WTRU rotation and / or blockage. The robustness of the physical channel may be enhanced. For example, multiple TRPs may be used for the transmission of PDCCH and / or for the reception of PUCCH and / or PUSCH, for example, to provide diversity. Multiple copies may be transmitted. More than one TRP may participate in the downlink (DL) transmission or the reception of the uplink (UL) transmission. Repetition may be combined, for example, to provide a combining gain. Repetition may allow for the reception of one of the multiple copies, which may enhance reception performance if one or more of the other copies fail to reach the destination.
[0085] The nature of the grant may include, for example, one or more of the following: frequency allocation; an aspect of time allocation (e.g., duration); priority; modulation and coding scheme (MCS); transport block (TB) size; number of spatial layers; number of transport blocks (TBs); TCI state, channel state information reference signal (CSI-RS) resource indicator (CRI), or sounding reference signal (SRS) resource index (SRI); number of repetitions; and / or an indication of whether the grant is a configured grant type 1, type 2, or dynamic grant.
[0086] The PDCCH enhancements disclosed herein may be implemented.
[0087] CORESET may be used interchangeably with search space, PDCCH search space, PDCCH, PDCCH candidate, PDCCH decoding candidate, and / or PDCCH monitoring set. Identity, ID, and index may be used interchangeably. The joint coding of CORESET may be referred to as a bit-level and / or symbol-level combination of one or more of the following: one or more bits (e.g., soft or hard bits) from different CORESETs or PDCCHs; one or more modulation symbols from different CORESETs or PDCCHs; and / or one or more DCIs from different CORESETs or PDCCHs.
[0088] The PDCCH can be associated with a TRP. The WTRU can be configured with one or more CORESETs and PDCCH search spaces for a bandwidth part (BWP). A CORESET (e.g., each CORESET) and / or a PDCCH search space (e.g., each PDCCH search space) can be associated with a TRP. The TRP can be referred to as a TRP identifier. The TRP identifier (TRP-id) can be used interchangeably with a CORESET group, a CORESET group identifier, a CORESET pool, a CORESET pool identifier (CORESETpoolId), a PDCCH search space group, a PDCCH search space group identifier, a PDCCH search space pool, a PDCCH search space pool identifier (searchSpacePoolId), a QCL group identifier, and / or a TRP group identifier. The PDCCH search space can be used interchangeably with a search space (SS).
[0089] The TRP or TRP identifier of a CORESET and / or a PDCCH search space can be determined based on one or more of the following examples. In an example, the TRP identifier can be indicated, for example, in a configuration for the CORESET and / or the search space. For example, if the WTRU is configured to operate in an operating mode for multi-TRP PDCCH monitoring, the TRP identifier can be present in a certain configuration. In an example, one or more QCL parameters can be indicated or configured for the CORESET and / or the search space. The CORESET and / or the search space can have the same QCL association and can be considered to have the same TRP association. The same QCL association can be, for example, the same source reference signal, which can be used for one or more QCL parameters.
[0090] A WTRU may determine an operation mode, for example, for PDCCH reception. One or more operation modes may be used for PDCCH reception. A first operation mode may be based on single PDCCH reception. A second operation mode may be based on multiple PDCCH reception. The WTRU may monitor, receive, and / or attempt to decode a single PDCCH that may carry scheduling information for one or more PDSCHs and / or one or more PUSCHs. The WTRU may (e.g., for multiple PDCCH reception) monitor, receive, and / or attempt to decode one or more PDCCHs that may carry scheduling information for one or more PDSCHs and / or one or more PUSCHs. There may be multiple modes, such as one or more of the following. Mode-1 may be a single PDCCH decoding mode (e.g., decoding a single PDCCH to receive a single DCI). In Mode-1a, a single PDCCH may schedule a single PDSCH and / or a single PUSCH. In Mode 1b, a single PDCCH may schedule one or more PDSCHs. Mode-2 may be, for example, a multiple PDCCH decoding mode (e.g., decoding multiple PDCCHs to receive a single DCI). In Mode-2a, one or more PDCCHs may schedule a single PDSCH and / or a single PUSCH. In Mode-2b, one or more PDCCHs may schedule one or more PDSCHs.
[0091] The PDCCH may be a PDCCH candidate in a search space. A single PDCCH may be referred to as a PDCCH candidate carrying a DCI or as a DCI. For example, a single PDCCH may refer to the time / frequency resources of a PDDCH candidate, or it may refer to DCI bits. A PDSCH or PUSCH may be referred to as a transport block (e.g., a shared channel).
[0092] PDCCH decoding mode, PDCCH decoding type, PDCCH decoding scheme, PDCCH reception mode, PDCCH reception type, PDCCH reception scheme, PDCCH monitoring mode, PDCCH monitoring type, and PDCCH monitoring scheme may be used interchangeably.
[0093] The number of CORESETs used to decode multiple PDCCHs may be determined, for example, based on the operation mode. One or more of the following may be applied.
[0094] For example, the operation mode may be determined based on the number of CORESETs in a CORESET group. In an example, for instance, if the CORESET group includes two or more CORESETs, the WTRU may consider the CORESET group as a first operation mode (e.g., multi-PDCCH decoding). For example, if the CORESET group includes zero or one CORESET, the WTRU may consider the CORESET group as a second operation mode (e.g., single-PDCCH decoding).
[0095] For example, the operation mode may be determined based on the number of associated CORESETs (e.g., for DCI reception). In an example, for instance, if two or more CORESETs are associated, the WTRU may consider the associated CORESETs as a first operation mode (e.g., multi-PDCCH decoding). The WTRU may consider the lack of associated CORESETs (e.g., zero or one CORESET or multiple unassociated CORESETs) as a second mode of operation (e.g., single-PDCCH decoding). The number of associated CORESETs for DCI may be implicitly indicated, for example, based on the number of search spaces associated with different CORESET-ids configured to monitor DCI.
[0096] For example, the operation mode may be determined based on the WTRU capabilities and the gNB configuration reported according to the WTRU capabilities. For example, the WTRU may receive a PDCCH decoding type or mode indication (e.g., single-PDCCH decoding mode or multi-PDCCH decoding mode). For example, if the PDCCH decoding type or mode indication indicates multi-PDCCH decoding, the WTRU may decode the DCI based on multiple PDCCHs. For example, if the PDCCH decoding type indication indicates single-PDCCH decoding or does not indicate a PDCCH decoding type, the WTRU may decode the DCI based on a single PDCCH.
[0097] The WTRU may request a preferred operation mode, e.g., for PDCCH decoding. For example, if the WTRU does not support multiple (e.g., two) operation modes and / or decoding of DCI based on a CORESET fails, the WTRU may indicate (e.g., to the gNB) the preferred operation mode. In an example, the WTRU may be configured with one or more uplink resources (e.g., Physical Random Access Channel (PRACH), PUCCH, and / or PUSCH) that the WTRU may use to indicate the preferred operation mode. For example, if decoding of DCI based on a CORESET fails, the WTRU may transmit one or more uplink signals (e.g., based on a first uplink resource among one or more uplink resources). For example, if decoding of DCI based on a CORESET is successful, the WTRU may transmit one or more uplink signals (e.g., based on a second uplink resource). The first uplink resource and the second uplink resource may be the same. For example, if the first uplink resource and the second uplink resource are the same, the indication may be based on a handover. In an example, for instance, if the WTRU is configured with a first operation mode (e.g., multi-PDCCH decoding), transmission of an uplink signal on the first uplink resource may indicate a request for a second operation mode (e.g., single-PDCCH decoding). For example, if the WTRU is configured with a second operation mode, transmission of an uplink signal on the first uplink resource may indicate a request for the first operation mode.
[0098] For example, the operation mode can be determined based on the configuration of the CORESET and / or the search space. In an example, the operation mode can be determined, for example, based on the number of TRP-ids configured for the CORESET configured in the BWP. For example, if the number of TRP-ids is 1, the first operation mode can be used. The second operation mode can be used in other ways. In an example, if no TRP-id is configured and / or the CORESET configuration does not have a TRP-id, the first operation mode can be used. If a TRP-id is configured for the CORESET configuration, the second operation mode can be used. In an example, the QCL association information can determine the operation mode. For example, if the QCL association is the same for multiple (e.g., all) configured CORESETs, the first operation mode can be used. For example, if the QCL association is different across multiple (e.g., all) CORESETs, the second operation mode can be used. One or more of the following may apply. The TRP-id may exist in the CORESET / SS configuration, for example, based on the operation mode for PDCCH reception. The QCL association can be configured commonly for multiple (e.g., all) CORESETs / SSs of the first operation mode. The QCL association can be configured individually or separately for each CORESET / SS of multiple (e.g., all) CORESETs / SSs of the second operation mode. The QCL association can be referred to as the QCL type configuration.
[0099] The operation mode can be determined based on a dynamic indication. For example, the DCI in the common search space can indicate the operation mode (e.g., PDCCH reception mode) for PDCCH reception in one or more WTRU-specific search spaces. The DCI in the common search space can be a group common DCI. The group common DCI can be shared by a group of WTRUs. The group common DCI can be, for example, a cyclic redundancy check (CRC) scrambled with a group radio network temporary identifier (RNTI). The start time of the PDCCH reception mode indicated in the group common DCI can be X symbols or time slots after the last symbol or time slot of the PDCCH carrying the group common DCI. X can be determined, for example, based on the subcarrier spacing of the associated BWP and / or the WTRU capabilities (e.g., WTRU processing capabilities). The DCI in the (e.g., same) search space can indicate the activation / deactivation of the PDCCH reception mode (e.g., mode-2). In an example, for example, if the PDCCH reception mode is deactivated or not activated, the default PDCCH reception mode (e.g., mode-1) can be used, and for example, if the PDCCH reception mode is activated, the indicated PDCCH reception mode (e.g., mode-2) can be used. The DCI and the media access control (MAC) control element (CE) can be used interchangeably (e.g., the DCI and the MAC CE can perform the same function).
[0100] Multiple PDCCH decoding schemes may be implemented. One or more multiple PDCCH decoding schemes may be used. One or more PDCCHs (e.g., which may be PDCCH transmissions as used herein), such as PDCCH candidates, received (e.g., by a WTRU) in a multiple PDCCH reception scheme may overlap in the time domain and / or frequency domain. One or more PDCCHs, such as for receiving one or more PDSCHs or PUSCHs, in a multiple PDCCH mode may be referred to as a multiple PDCCH set In one or more of the PDCCHs or PDCCH candidates may be combined (e.g., at bit level or symbol level) and may be used to decode the associated DCI.
[0101] The PDCCHs may overlap (e.g., completely overlap) in the time domain and frequency domain (e.g., spatial domain multiplexing (SDM)). In one or more of the PDCCHs may be from different CORESETs or non-overlapping CORESETs. For example, in the first PDCCH may be from a first CORESET, and in the second PDCCH may be from a second CORESET.
[0102] In an example, the CORESET associated with one or more PDCCHs in may be configured with multiple symbols (e.g., the same number of symbols) and frequency positions (e.g., the same frequency position), such as the same set of physical resource blocks (PRBs) in a BWP. In the first PDCCH may be from a first search space, which may be associated with a first CORESET. In the second PDCCH may be from a second search space, which may be associated with a second CORESET. The first CORESET and the second CORESET may have different CORESET-ids.
[0103] In an example, the search space associated with one or more PDCCHs may be associated with a CORESET and / or the same CORESET-id. The search space (e.g., each search space) may be configured with one or more QCL parameters. For example, if a WTRU monitors one or more PDCCHs in a search space, the QCL parameters configured in the associated CORESET may be ignored or overridden by the QCL parameters configured in the search space (e.g., each search space).
[0104] In an example, PDCCH candidates can be received from one or more spatial Rx parameters (e.g., QCL type-D). A PDCCH candidate with a first spatial Rx parameter can be referred to as the first PDCCH in the second PDCCH in
[0105] PDCCHs can overlap in the time domain and / or frequency domain (e.g., partially overlap) (e.g., time division multiplexing (TDM) and / or frequency division multiplexing (FDM)). One or more search spaces associated with one or more PDCCHs in
[0106] In an example, one or more search spaces for the PDCCH in can be associated with the same CORESET (e.g., the same CORESET-id). One or more search spaces can be monitored at different time positions (e.g., different symbols in a certain time slot or different time slots). A search space (e.g., each search space) can be configured with one or more QCL parameters. For example, if a WTRU monitors one or more PDCCHs in a search space, the QCL parameters configured in the associated CORESET can be ignored or overridden by the QCL parameters configured in the search space (e.g., each search space).
[0107] In an example, one or more search spaces for the PDCCH in can be associated with different CORESETs. The search spaces can be located within a time window (e.g., a time slot, a subframe, etc.).
[0108] PDCCHs can be non-overlapping in the time domain and frequency domain (e.g., TDM and / or FDM). One or more search spaces associated with one or more PDCCHs in
[0109] A WTRU can determine the associated CORESET. For example, based on using one or more CORESETs, the WTRU can support enhanced reliability for PDCCH reception. In an example, the WTRU can jointly decode DCI, for example, by combining signals of multiple PDCCHs received from multiple CORESETs. Multiple CORESETs used to receive multiple PDCCHs to decode DCI can be associated with each other, for example, by using one or more of the following: explicit indication or implicit indication.
[0110] In an example of associating a CORESET by explicit indication, a WTRU may receive one or more CORESET IDs using a downlink channel (e.g., PDCCH and / or PDSCH), for example. The downlink channel may carry bit information of one or more CORESET IDs.
[0111] In an example, a WTRU may receive one or more associated CORESET IDs in a CORESET configuration (e.g., each CORESET configuration), which may be, for example, in and / or received in one or more radio resource control (RRC) messages.
[0112] In an example, a WTRU may receive one or more associated CORESET IDs in one or more MAC-CE messages. The one or more MAC-CE messages may include, for example, one or more of the following: target cell ID; target BWP ID; target CORESET ID; and / or associated CORESET ID.
[0113] In an example, the gNB may indicate one or more associated CORESET IDs in one or more group DCIs. One or more DCI fields in the one or more group DCIs may include (e.g., explicitly include) one or more CORESET IDs. The indication of the one or more CORESET IDs may be based on an RRC configuration. For example, the WTRU may be provided with a list. Code points in the list (e.g., each code point) may include one or more CORESET groups in a CORESET group. One or more CORESET groups in a CORESET group (e.g., each CORESET group in the one or more CORESET groups) may include one or more associated CORESET IDs. The WTRU may receive a DCI field indicating a code point of the list. The WTRU may receive multiple PDCCHs and decode the DCI, for example, based on the code point. In an example, the group DCI may indicate a CORESET ID, and the CORESET ID may indicate to the WTRU which CORESET ID is associated with receiving a WTRU-specific DCI.
[0114] The WTRU may receive one or more CORESET group IDs using, for example, a downlink channel transmission (e.g., PDCCH and / or PDSCH). The downlink channel transmission may carry bit information of one or more CORESET group IDs. For example, the WTRU may receive one or more group IDs in a CORESET configuration (e.g., each CORESET configuration), e.g., where the CORESET configuration is received via one or more messages such as one or more RRC messages. One or more CORESETs may be determined to be associated CORESETs based on one or more CORESETs including one or more identical CORESET group IDs.
[0115] In an example, an indication that a CORESET is associated may be provided by an implicit indication, which may be based on a CORESET pool ID and / or a CORESET decoding type.
[0116] In an example, the WTRU may receive multiple PDCCHs for DCI based on CORESETs having the same CORESET pool ID.
[0117] In an example, the WTRU may receive a decoding type, for example, in a CORESET configuration (e.g., each CORESET configuration) of one or more RRC messages. For example, if the decoding type is indicated as multi-PDCCH decoding, the WTRU may jointly decode the PDCCHs from one or more CORESETs, which may be indicated as multi-PDCCH decoding. For example, if the decoding type is not indicated or single-PDCCH decoding is indicated, the WTRU may decode the PDCCH from the CORESET.
[0118] The associated CORESET may be used interchangeably with the CORESETs in the CORESET group and / or the CORESETs having the same PDCCH decoding type.
[0119] The WTRU may determine multi-PDCCH decoding.
[0120] The WTRU may apply multi-PDCCH decoding based on, for example, one or more of the following: RNTI, CORESET ID, precoder granularity, or control channel element (CCE) resource element group (REG) mapping type.
[0121] The WTRU may apply multi-PDCCH decoding based on, for example, an RNTI. For example, the WTRU may apply multi-PDCCH decoding to one or more PDCCHs that may be CRC scrambled with multi-PDCCH decoding by a first RNTI (e.g., a cell (C)-RNTI, an MCS-C-RNTI, and / or a configured scheduling (CS)-RNTI). The WTRU may apply single-PDCCH decoding to one or more PDCCHs that may be CRC scrambled by a second RNTI (e.g., a system information (SI)-RNTI, a paging (P)-RNTI, a random access (RA)-RNTI, a slot format indicator (SFI)-RNTI, an interruption (INT)-RNTI, a transmission power control (TPC)-PUSCH-RNTI, a TPC-PUCCH-RNTI, and / or a TPC-SRS-RNTI).
[0122] The WTRU may apply multi-PDCCH decoding based on, for example, a CORESET ID. For example, the WTRU may apply single-PDCCH decoding to one or more CORESETs with a first CORESET ID (e.g., CORESET 0), and may apply multi-PDCCH decoding to one or more CORESETs with a second CORESET ID (e.g., a CORESET other than 0).
[0123] The WTRU may apply multi-PDCCH decoding based on, for example, a precoder granularity (e.g., a REG bundle size).
[0124] The WTRU may apply multi-PDCCH decoding based on, for example, a CCE REG mapping type (e.g., interleaved or non-interleaved).
[0125] The WTRU may determine whether to use single-PDCCH decoding or multi-PDCCH decoding to perform decoding (e.g., the decoding that will be attempted) based on, for example, downlink measurement quality. Single-PDCCH decoding may be a separate configuration from multi-PDCCH decoding or part of multi-PDCCH decoding. The WTRU may attempt to decode / use the determined single-PDCCH decoding or multi-PDCCH decoding for decoding.
[0126] Single PDCCH decoding may refer to a WTRU monitoring one PDCCH out of multiple PDCCHs for multi-PDCCH decoding. For example, a WTRU may be configured for multi-PDCCH decoding. Multiple (e.g., two) PDCCHs may be used for DCI reception. The WTRU may decode or attempt to decode the first PDCCH (e.g., only the first PDCCH) or the second PDCCH (e.g., only the second PDCCH) for DCI reception, which may be referred to as single PDCCH decoding. The WTRU may be configured with a separate configuration (e.g., for single PDCCH decoding) that may be different from multi-PDCCH decoding (e.g., in terms of the number of CORESETs, CORESETPoolId, etc.).
[0127] The WTRU may determine whether to perform, decode, or operate single PDCCH decoding or multi-PDCCH decoding based on, for example, one or more of the following: DL measurements of one or more reference signals associated with the PDCCH; system parameters; the number of non-overlapping CCEs for PDCCH blind decoding and / or channel estimation in a time slot; the type of traffic expected in the time slot; PDSCH / PUSCH scheduling type; demodulation reference signal (DM-RS) configuration; or minimum scheduling timing.
[0128] The WTRU may determine whether to perform, decode, or operate single PDCCH decoding or multi-PDCCH decoding based on, for example, DL measurements of one or more reference signals that may be associated with the PDCCH (e.g., measurement references of CORESETs associated with multiple PDCCHs (e.g., PDCCH groups)).
[0129] In an example, for instance, if the measurement of a CORESET within a CORESET group is above a threshold, the WTRU may decode the PDCCH associated with the CORESET having a measurement above the threshold. The measurement may include at least one of, for example, reference signal received power (RSRP), L1-RSRP, signal-to-interference plus noise ratio (SINR), L1-SINR, or radio link quality (e.g., assuming block error rate (BLER)).
[0130] In an example, for instance, if the measurement result of a CORESET has a gap greater than X [dB], the WTRU may decode or attempt to decode the PDCCH of the CORESET having a higher measurement result.
[0131] In an example, if the sum of the measurement results from CORESETs associated with multi-PDCCH decoding is within a specific gap Y [dB] of the measurement result from the CORESET having the highest measurement result, the WTRU may, for example, perform single PDCCH decoding.
[0132] The WTRU may determine whether to perform, decode, or operate single PDCCH decoding or multi-PDCCH decoding, for example, based on system parameters (e.g., time slot number, sub-frame number, radio frame number).
[0133] The WTRU may determine whether to perform, decode, or operate single PDCCH decoding or multi-PDCCH decoding, for example, based on PDCCH blind decoding and / or the number of non-overlapping CCEs used for channel estimation in a time slot. In an example, if the number of PDCCH blind decodings and / or the number of non-overlapping CCEs used for channel estimation is higher than a threshold, the WTRU may perform single PDCCH decoding, for example. Otherwise, the WTRU may perform multi-PDCCH decoding, for example.
[0134] The WTRU may determine whether to perform, decode, or operate single PDCCH decoding or multi-PDCCH decoding, for example, based on the type of traffic expected in a time slot (e.g., eMBB or URLLC).
[0135] The WTRU may determine whether to perform, decode, or operate single PDCCH decoding or multi-PDCCH decoding, for example, based on the PDSCH / PUSCH scheduling type (e.g., time slot level or sub-time slot level).
[0136] The WTRU may determine whether to perform, decode, or operate single PDCCH decoding or multi-PDCCH decoding, for example, based on the DM-RS configuration (e.g., pre-loaded DM-RS or pre-loaded DM-RS with additional DM-RS).
[0137] The WTRU may determine whether to perform, decode, or operate single PDCCH decoding or multi-PDCCH decoding, for example, based on the minimum scheduling timing (e.g., the minimum K0 value in the Time Domain Resource Allocation (TDRA) table).
[0138] The WTRU may determine whether to avoid buffering.
[0139] The WTRU may skip blind decoding of PDCCH from a CORESET, for example, based on one or more conditions.
[0140] For example, if DCI is successfully decoded based on, for example, PDCCH from an earlier CORESET associated with the CORESET, the WTRU may skip blind decoding of PDCCH from the CORESET. In an example, if DCI is successfully decoded from a first CORESET, for example, the WTRU may not decode DCI from a second CORESET. The successfully decoded DCI may include passing a CRC check.
[0141] For example, if one or more CORESETs associated with the CORESET are deactivated, the WTRU may skip blind decoding of PDCCH from the CORESET.
[0142] For example, if a CORESET group associated with a CORESET is deactivated, the WTRU may skip blind decoding of PDCCH from the CORESET.
[0143] Skipping blind decoding may be implemented based on, for example, one or more of the following conditions: the CORESET is within a time window and / or the CORESET is within a frequency window.
[0144] In an example, for instance, if DCI is decoded (e.g., successfully decoded) from a first CORESET, the WTRU may skip decoding of DCI from a second CORESET that is within a time window. The time window may be configured or may be based on, for example, one or more of milliseconds, symbols, time slots, or frames. The time window may be based on a particular CORESET (e.g., the first CORESET). For example, the time window may be defined as n+T, where n may indicate the time slot of the first CORESET. The time window may be based on periodicity and offset. For example, the WTRU may be configured with periodicity and offset in one or more RRC configurations. The WTRU may determine the CORESET within the time window based on, for example, periodicity (e.g., configured periodicity) and offset (e.g., configured offset).
[0145] In an example, for instance, if DCI is decoded (e.g., successfully decoded) from a first CORESET, the WTRU may skip decoding of DCI from a second CORESET that is within a frequency window. The frequency window may be based on one or more of resource blocks (RBs), resource block groups (RBGs), precoded resource block groups (PRGs), and / or subbands.
[0146] The WTRU may determine a priority order of CORESETs. Prioritization may be implemented, for example, within a CORESET and / or a CORESET group. For example, the WTRU may determine the first one or more CORESETs to be decoded or monitored. The WTRU may monitor the first one or more CORESETs based on, for example, that determination. The WTRU may skip monitoring the second one or more CORESETs. The WTRU may determine the first one or more CORESETs based on, for example, one or more of the following: the lowest CORESET ID; the lowest CORESET group ID; the lowest physical cell ID; and / or the lowest serving cell ID.
[0147] The WTRU may prioritize CORESETs, for example, based on the lowest CORESET ID. In an example, the WTRU may determine or select the CORESET with the lowest CORESET ID. The WTRU may determine (e.g., select) the CORESET ID among one or more CORESET IDs of an associated CORESET (e.g., for one or more associated CORESETs in the associated CORESET) for prioritization. For example, the WTRU may determine or select the CORESET with the lowest CORESET ID among one or more CORESET IDs in the CORESET ID.
[0148] The WTRU may prioritize CORESETs, for example, based on the lowest CORESET group ID. For example, the WTRU may determine or select the CORESET group with the lowest CORESET group ID.
[0149] The WTRU may prioritize CORESETs, for example, based on the lowest physical cell ID. For example, the WTRU may determine or select the CORESET associated with the lowest physical cell ID.
[0150] The WTRU may prioritize CORESETs, for example, based on the lowest serving cell ID. For example, the WTRU may determine or select the CORESET associated with the lowest serving cell ID.
[0151] For example, prioritization may be used if one or more of the following conditions are met: the number of CORESETs per time slot is greater than the maximum number of CORESETs supported by the WTRU; the number of serving cells is greater than a certain number (e.g., a first number); and / or the number of active BWPs in the serving cells is greater than a certain number (e.g., a first number).
[0152] The WTRU may determine a repetition time reference. Different timing references for DCI repetition may be determined. DCI repetition may be sent with a timing offset (e.g., for each DCI repetition), and the timing offset may be variable. The WTRU may determine a moment if DCI can be sent according to a reference timing point and an offset relative to that reference timing point. The WTRU may use one of the following as a reference timing point: a random access channel (RACH) opportunity; a synchronization signal block (SSB); a search space time slot; or a time slot index pattern.
[0153] The WTRU may use the RACH opportunity as a reference timing point. The WTRU may determine that multiple repetitions of DCI may be sent in a search space within a time gap after the RACH opportunity time slot. The WTRU may determine the position at which the repetition may be offset relative to the RACH opportunity time slot. As Figure 4As shown, the WTRU can recognize that after the RACH occasion, it can be Repetition 0 and Repetition 1. If the WTRU uses the preamble from the RACH occasion to send msg1, the WTRU can determine that msg2 can be sent in two repetitions offset from the RACH occasion.
[0154] The WTRU can use the SSB as a reference timing point. The WTRU can use the position of the SSB and determine the repetition offset from the SSB timing. The WTRU can measure the RSRP or the reference signal received quality (RSRQ) and determine the presence and number of repetitions based at least on the channel measurement. If the RSRP or RSRQ drops below a threshold n1, the WTRU can determine the channel measurement by determining that more than one repetition can be sent. The WTRU can determine the channel measurement by determining the number of repetitions based on a mapping from the RSRP or RSRQ value to the number of repetitions. For example, if the WTRU determines that the RSRP can be less than n1 (RSRP < n1), the WTRU can determine to use K = 2 repetitions. If the WTRU determines that the RSRP can be greater than n1 (RSRP > n1), the WTRU can determine to use K = 1 repetition.
[0155] The WTRU can use the search space time slot as a reference timing point. The WTRU can determine the search space (SS) ID and can determine to send the repetition relative to the SS time slot with an offset that varies with the number of repetitions. As Figure 4 shown, at T1, the WTRU can use SS0. The WTRU can determine that the repetition k can be sent at time T1 + k * T_offset, where T_offset can be a configurable parameter. The search space can be configured with values for the k-th repetition. The WTRU can first monitor (e.g., be restricted to the first monitor) the SS where k is equal to zero (k = 0), and if it fails to receive in the case where k is equal to zero (k = 0), the WTRU can search the search space (SS) configured with k greater than zero (>0).
[0156] The WTRU can use the time slot index pattern as a reference timing point, where the time slot index (e.g., each time slot index) can be used to determine the number of repetitions. The WTRU can use the slot format indicator (SFI) to determine the DL time slot timing. The WTRU can use a pattern that identifies time slot 1 where repetition 1 can be sent and time slot 2 where repetition 2 can be sent. The pattern of time slots with repetitions can be configured with the SFI or configured in a separate system information block (SIB).
[0157] If multiple DCI repetitions are detected, the WTRU may determine the TCI for the data. If a single DCI is sent, the WTRU may determine the spatial filter to be used for the scheduled data (e.g., PDSCH transmission or PUSCH transmission) based on the DCI. The DCI may contain an explicit QCL indication, and the WTRU may have time (e.g., sufficient time) to switch the spatial filter. If the WTRU does not have time to switch its spatial filter, the WTRU may use (e.g., as a default) the same spatial filter that was used to receive the DCI. If multiple DCI repetitions are used and each DCI repetition is sent with its own TCI, the WTRU may not have information for determining which TCI is used for the scheduled data. The WTRU may receive an indication that K is equal to 2 (K = 2). The WTRU may recognize that repetition 1 may be configured with TCI1 and repetition 2 may be configured with TCI2. It may not be clear whether the WTRU expects the scheduled data to be sent with TCI1 or TCI2. If the CORESET can be configured with multiple TCI values, or if data transmission can be scheduled using a DCI with multiple TCI values, the WTRU behavior may not be defined.
[0158] The WTRU may determine the spatial relationship of the scheduled data based on rules for determining the spatial relationship (e.g., default spatial relationship) that may apply in the case of receiving multiple DCI repetitions with multiple TCIs for the scheduled data. The reference timing used by the WTRU to switch its spatial filter may depend on whether the rules are applicable. If the WTRU identifies a repetition that satisfies the rules, the WTRU may switch its spatial filter. The WTRU may ignore other repetitions. The WTRU may determine how many repetitions are expected and may switch its spatial filter after receiving the repetitions.
[0159] If the WTRU receives multiple DCIs with different TCIs, the WTRU may apply one or more rules or logic (e.g., associated with the TCI and used to determine the DCI, etc.), such as one or more of the following.
[0160] The WTRU may use the TCI corresponding to the repetition index k. The WTRU may determine the index of the DCI repetition and may use the TCI of the k-th DCI repetition.
[0161] The WTRU may use the TCI from the last successfully received DCI. The DCI may correspond to a DCI sent without a repetition that may have been used in a previous transmission, or the DCI may correspond to one of the repetitions in the current repetition set.
[0162] The WTRU may determine to use the TCI associated with the first DCI repetition correctly decoded within a set of K repetitions.
[0163] The WTRU may use repetitions with a TCI corresponding to the RS with the highest RSRP.
[0164] The WTRU may determine that a TCI associated with a panel may be used. The WTRU may receive repetition 1 on panel 1 and receive repetition 2 on panel 2. The WTRU may use the TCI associated with panel 1 (e.g., because panel 1 may be a panel that the WTRU is configured to use).
[0165] The WTRU may determine that a TCI associated with a TRP index may be used. If the WTRU receives repetition 1 from TRP1 and receives repetition 2 from TRP2, the WTRU may use the TCI from TRP1 (e.g., because TRP1 may be the TRP associated with the TRP index).
[0166] For example, if some of the repetitions are configured with an unknown TCI state, the WTRU may determine to use the TCI from a known state. The unknown TCI state may be a TCI state where the WTRU may not have determined the spatial filter yet (e.g., the WTRU has not yet performed a measurement on the QCL source RS).
[0167] The WTRU may determine to use the TCI index as a reference. The WTRU may use the lowest TCI index from the repetitions (e.g., all repetitions), or may use a specific TCI index (e.g., TCI = 2).
[0168] The WTRU may use the code point table configured for the PDSCH to determine the TCI and may determine the code point index. The WTRU may receive multiple DCI repetitions. The WTRU may determine to use the TCI corresponding to TCI code point 1 that may be configured for the PDSCH.
[0169] The WTRU may use a TCI mode. The WTRU may determine the TCI based on the mapping from the mode. In an example, the mode may include TCI1 and TCI2. The WTRU may determine which TCI from the mode to use based on the number of repetitions. If one (1) repetition is determined, the WTRU may determine to use TCI1. If two (2) repetitions are determined, the WTRU may determine to use TCI2.
[0170] The WTRU may determine the TCI based on the RNTI of the DCI. If the WTRU decodes a DCI scrambled with a C-RNTI, the WTRU may use TCI1. If the WTRU decodes a DCI scrambled with an RA-RNTI, the WTRU may use TCI2.
[0171] The WTRU may select a TCI based on the traffic type. If the WTRU receives DCI scheduling URLLC data, the WTRU may use TCI1 as a reference. If the WTRU receives DCI scheduling eMBB data, the WTRU may use TCI2.
[0172] The WTRU may determine PDCCH candidates from multiple TRPs and / or beams. The WTRU may determine at least one PDCCH candidate mapped by a resource that may have more than one QCL association or TCI state (e.g., a resource transmitted from more than one TRP or beam). The WTRU may determine PDCCH candidates (e.g., a set of PDCCH candidates) for an operation mode (e.g., where the operation mode may refer to a PDCCH transmission in which PDCCH candidates are sent with two TCI states, e.g., one PDDCH candidate may be transmitted over several RBs, some of which may be transmitted with TCI1 and others with TCI2).
[0173] The WTRU may determine PDCCH candidates by determining a search space configuration that includes more than one CORESET identity. The WTRU may determine control channel elements and / or resource element groups, for example, by combining resources of more than one CORESET according to one or more rules (e.g., predefined rules). The WTRU may determine REGs and / or CCEs from the collocation in the time domain of more than one CORESET. The WTRU may determine PDCCH candidates (e.g., blind-level PDCCH candidates) based on concatenated control channel elements that may have the same index from the corresponding CORESET and may increase the aggregation level (e.g., double). The WTRU may bit-interleave or symbol-interleave the combined control channel elements or the control channel elements themselves. Doing so may improve robustness in cases of unequal quality between TRPs.
[0174] For example, if the QCL association or TCI state depends on time symbols, the WTRU may determine PDCCH candidates by determining a single CORESET having more than one symbol in the time domain. The WTRU may perform other (e.g., all other) operations (e.g., REG / CCE mapping, determining PDCCH candidates) from existing rules. The WTRU may determine that a REG or CCE includes resource elements from two symbols according to mapping rules (e.g., new mapping rules).
[0175] The WTRU may determine PDCCH candidates by determining such candidate search spaces, for example, based on a combination of at least two previously configured search spaces. The combination of at least two search spaces may be signaled by a higher layer. The PDCCH candidates for the combination may be restricted to monitoring time slots / symbols common to at least two search spaces. Separate periodicity and offsets may be configured specifically for the combination. The PDCCH candidates may be derived as a combination (e.g., juxtaposition) of control channel elements from two search spaces. The WTRU may interleave bits or symbols of the combined control channel elements or interleave the control channel elements themselves.
[0176] If the number of PDCCH candidates or the number of control channel elements exceeds the corresponding maximum in a time slot or PDCCH span (e.g., overbooking), the WTRU may apply a lower or higher priority level to PDCCH candidates mapped to resources with more than one QCL property compared to other resources. The WTRU may determine the priority level and / or activate or deactivate PDCCH monitoring from such resources based on a MAC CE received from the network.
[0177] The WTRU may determine (e.g., detect) PDCCH decoding failures and / or behavior. Since the TRP transmits its own PDCCH transmissions that may be mapped to different CORESETS or different search spaces within the same CORESET or two different search spaces associated with two different CORESETS, the WTRU may have reference signals (RSs) and may use the RSs to distinguish radio link quality.
[0178] The WTRU may be configured with TCI states. The TCI states may result in a collocated arrangement (e.g., QCL) of CSI-RS and PDCCH DM-RS for a particular TRP radio link. Two disjoint sets of CSI-RS#1 and DM-RS#1 sets and CSI-RS#2 and DM-RS#2 sets may be used for the WTRU configured for MTRP reception. These TCI states may be configured per CORESET and per TRP. If multiple CORESETS are defined per TRP, the spatial relationship of the collocated arrangement of CSI-RS and DM-RS may be maintained per TRP. Other subdivisions of search spaces and CORESETS (e.g., any other subdivision) may follow the TCI state partitioning per TRP.
[0179] When a WTRU monitors (e.g., initiates monitoring) the PDCCH of a link (e.g., two links), the WTRU may measure (e.g., simultaneously measure) the CSI-RS for the radio link (e.g., each TRP radio link) configured for the TRP. The WTRU may maintain one or more of the following measurements and numbers (e.g., counters) separately for each link: Qin, aQout (e.g., for radio link monitoring (RLM)), and the RLM number (e.g., counters and timers); RSRP; RSRQ; L1-SINR; and the channel quality indicator (CQI).
[0180] A CORESET or search space (SS) may have two associated TCI states (e.g., different TCI states). The WTRU may use two different spatial filters and may accordingly decode PDCCH candidates. The WTRU may apply different spatial filters to each decoding candidate per TRP / TCI.
[0181] The WTRU may determine to decode (e.g., attempt to decode) a PDCCH candidate (e.g., two PDCCH candidates) or one candidate (e.g., only one candidate) based on one or more measurements of the RLM results or associated CSI-RS per TRP. Qin / Qout may be replaced with an RSRP threshold or an L1-SINR level linked to the CSI-RS set belonging to the TRP. If the previously calculated (e.g., last calculated) Qin / Qout state of the TRP link is Qin, the WTRU may attempt to decode the associated PDCCH transmission. If the link (e.g., two links) indicates that the previously evaluated (e.g., last evaluated) RLM state is Qin and the first TRP-related PDCCH transmission fails, the WTRU may search for and decode the second TRP-associated PDCCH transmission. If the previously calculated (e.g., last calculated) Qin / Qout RLM state of the TRP (e.g., two TRPs) indicates Qout and the WTRU has not declared a radio link failure (RLF), the WTRU may initiate decoding of the spatially related PDCCH transmission (e.g., two spatially related PDCCH transmissions) in the CORESET. If the WTRU successfully decodes the first PDCCH candidate from one TRP, the WTRU may eliminate the search for and decoding of the second PDCCH candidate.
[0182] MTRP-related PDCCH decoding feedback may be provided. The following feedback and measurement reporting techniques may be used individually or in any combination.
[0183] If the PDCCH candidate decoding from a particular TRP (e.g., all decoding options) fails and other PDCCH transmissions from another TRP are decoded successfully, the WTRU may include in the feedback message an indication of the PDCCH decoding failure for that TRP.
[0184] The WTRU may include feedback regarding the PDCCH decoding status, which may assist the gNB in adapting the aggregation level or reconfiguring the repetition scheme for PDCCH reliability, including reconfiguring the WTRU with single TRP transmissions or other measures (e.g., BWP reconfiguration).
[0185] The feedback may be added to the Ack / Nack on the PUCCH transmission for the scheduled PDSCH transmission or to the UCI in a subsequent PUSCH transmission in the form of a two-bit codebook. The two-bit codebook may be as follows: {(0,1),(1,0),(1,1)}.
[0186] The WTRU may use two different RNTIs, e.g., one per PDCCH or TRP. The WTRU may use the successful PDCCH-related RNTI for feedback such that the gNB can determine which PDCCH transmission was successful. The WTRU may use (e.g., implicitly or explicitly) the RNTI of the decoded PDCCH transmission to indicate whether the decoding of the first received PDCCH transmission or the second received PDCCH transmission was successful.
[0187] The WTRU may indicate the ID corresponding to the CORESET or SS associated with the PDCCH (e.g., CORSETpoolindex) to indicate the decoded PDCCH transmission.
[0188] If the WTRU receives multiple PDCCH transmissions, the WTRU may attempt to decode the first transmission. If the decoding of the first transmission fails, the WTRU may attempt to decode the second transmission, and so on. If the attempt to decode an individual PDCCH transmission fails, the WTRU may attempt to decode the soft combination of the received PDCCH transmissions.
[0189] For two PDDCH repetitions, the WTRU may use an ID corresponding to each attempt and may feedback the ID to the gNB. The ID may be associated with each attempt and may be a simple index (e.g., 1, 2, 3, etc.). The ID may be an RNTI (e.g., RNTI_attempt1, RNTI_attempt2, etc.). The ID may correspond to the CORESET or SS associated with the PDCCH (e.g., CORSETpoolindex).
[0190] The WTRU may combine two PDCCH repetitions and use (e.g., only use) two IDs. If the first attempt is successful, the WTRU may indicate ID1, and if the second attempt is successful, the WTRU may indicate ID2. The WTRU may indicate that there is no ID in its feedback to indicate that its final attempt via soft combination is successful.
[0191] For two PDDCH repetitions, in order to reduce the number of decoding attempts and power consumption, the WTRU may attempt to receive the decoding of the PDCCH transmission twice (e.g., only twice). The two attempts may be the decoding of PDCCH1 and PDCCH2, or the decoding of PDCCH1 and the soft combination of PDCCH1 and PDCCH2. The WTRU may indicate to the gNB its PDCCH decoding capabilities (e.g., the number of decoding attempts) and soft combination capabilities. Based on the indicated capabilities, the WTRU may receive relevant configuration parameters (e.g., power saving mode, processing time parameters, etc.). The WTRU may feedback (e.g., implicitly or explicitly feedback) the RNTI of the decoded PDCCH transmission to indicate whether the decoding of the first attempt or the second attempt is successful.
[0192] The determination of successful PDCCH transmission decoding may be made at the PUCCH resource selection. A specific PUCCH resource (e.g., the resource that configures the PUCCH resource set) may be linked to the successful TRP PDCCH transmission decoding.
[0193] If the gNB determines that the DCI is sent at more than one aggregation level (AL), the WTRU may report which ALs have been successfully decoded. The WTRU may report the minimum successful AL (e.g., search space index, CORESET ID, REG bundle size). The report may be mapped to a codebook that can minimize the size of the feedback report. If the PDCCH transmission is sent at all ALs, the report may be periodic or triggered by a threshold (e.g., a threshold related to the AL size) or related to a failed attempt.
[0194] The WTRU may use the ID corresponding to each AL to indicate the minimum successful AL. The ID may be associated with each attempt and may be a simple index corresponding to AL = 1, 2, 4, etc. (e.g., 1, 2, 3, etc.). The ID may be an RNTI (e.g., RNTI_AL1, RNTI_AL2, etc.). The ID may correspond to the CORESET or SS associated with the PDCCH (e.g., CORSETpoolindex).
[0195] Based on the success or failure of PDCCH decoding per TRP, the WTRU may maintain a count per TRP (e.g., via a counter) that may increase with each successive failure and may be reset upon successful decoding of a PDCCH transmission. Each count may have a network-configured threshold. If the WTRU reaches the threshold for a particular TRP, the WTRU may use a feedback technique to signal the decoding failure. The threshold may be set, for example, to one (1), which may result in reporting each failure. After the count increment rule and threshold are met, a higher count may imply a failure feedback.
[0196] When signaling a PDCCH transmission decoding failure for a particular TRP, the WTRU may stop the decoding attempt associated with the TRP and may operate in a single-TRP reception mode. If the TRP has determined that the Qin / Qout state is Qin and the failed PDCCH decoding threshold is reached, the WTRU may signal the threshold. The WTRU may continue to monitor the PDCCH on the TRP and attempt to decode it.
[0197] If the measurement of the TRP based on the QCL RS signal (e.g., CSI-RS) associated with the TRP is below a threshold, the WTRU may report using an RRC report (e.g., L3) or using a physical layer feedback implementation and may stop attempting to decode the associated TRP PDCCH transmission. If the TRP is not in an RLF state, based on the Qin / Qout state and the count (e.g., counter), and the RS measurement is below the configured threshold, the WTRU may report the situation and continue the decoding attempt for the TRP-related PDCCH transmission.
[0198] If the PDCCH transmission is sent in a time-mode repetition pattern, the WTRU may report the number of failed attempts in the repetition cycle. If the PDCCH is sent in two different time slots and the WTRU's first attempt fails, the WTRU may signal the number of failed attempts as one (1) for the assumed PDCCH combination, otherwise zero (0) failures. The gNB may optimize the number of repetitions in the time domain or change the reliability scheme.
[0199] The WTRU may reset the count (e.g., counter) used in the reporting implementation when sending the relevant feedback or report.
[0200] The PUCCH enhancements disclosed herein may be implemented in a system, apparatus, and / or method.
[0201] The WTRU can improve the reliability of PUCCH transmission by, for example, transmitting multiple copies (e.g., two copies). The copies (e.g., each copy) can be transmitted with different spatial relationships, time, or frequency resource allocations (e.g., to improve receive diversity). For example, if the PUCCH configuration is only configured for one spatial relationship, the WTRU may not be able to transmit repetitions with different parameters to multiple TRPs. Disclosed are enhancements that enable the WTRU to switch between different transmission configurations (e.g., transmission configurations with different spatial relationships) and enable the combinations of repetitions.
[0202] PUCCH formats 0 and 1 (e.g., in NR) can carry uplink control information (UCI) (e.g., small UCI), such as containing hybrid automatic repeat request (HARQ) feedback and / or scheduling request (SR) bits. PUCCH formats 1 and 0 can be based on the transmission of sequences, for example, for carrying UCI information bits. The transmission of PUCCH format 0 can be completed, for example, within the duration of one or two symbols. PUCCH format 1 can be based on the transmission of a long sequence extended over several symbols, for example, to provide more reliable operation and performance for cell-edge WTRUs. The maximum RB size of PUCCH format 1 can be limited to one RB, which may not provide sufficient gain in terms of range and reliability. The repetition of PUCCH format 1 over several time slots can enhance reliability and coverage but can increase decoding delay (e.g., simultaneously). PUCCH format 2 can have a short duration (e.g., similar to PUCCH format 0). PUCCH format 2 can carry a larger payload (e.g., PUCCH format 2 can be configured with more than one RB).
[0203] For example, in a system with one or more transmission points, enhanced PUCCH transmission can be used to enhance reliability and extend the range. One form of enhanced PUCCH transmission can be based on repetition (e.g., the repetition form). In an example, the transmission of short PUCCHs (e.g., PUSCH formats 0 and 2) can be repeated within a time slot, for example, to enhance coverage and transmission reliability. For example, PUCCH repetition can be achieved by using resources that can otherwise be used for PUSCH transmission (e.g., as shown in the examples in Figure 5 ).
[0204] Figure 5 is a diagram showing an example of PUCCH repetition for enhanced PUCCH transmission.
[0205] The activation and deactivation of enhanced PUCCH transmission and resource allocation can be performed, for example, by a WTRU. The WTRU can determine (e.g., implicitly and / or explicitly determine) the use of enhanced PUCCH transmission, for example, by dynamic or semi-static signaling. The WTRU can receive a set of resources (e.g., an indication of a resource set) for enhanced PUCCH transmission. The indication of the resources can be received, for example, by semi-static or dynamic indication (e.g., implicitly or explicitly).
[0206] For example, the WTRU can implicitly determine the use of enhanced PUCCH transmission. The WTRU can determine (e.g., implicitly determine) the activation (e.g., and deactivation) of enhanced PUCCH transmission. The WTRU can be configured to react to one or more implicit indications. In addition to other triggers for activating enhanced PUCCH transmission, the WTRU can also consider implicit indications. Implicit indications for enhanced PUCCH transmission can be implemented. One or more of the following can be applied.
[0207] In an example, for instance, if the WTRU determines that the WTRU is configured in an MTRP transmission, the WTRU can detect the activation of enhanced PUCCH transmission.
[0208] In an example, for instance, if the WTRU receives an indication by DCI including multiple (e.g., two) TCI states and one code division multiplexing (CDM) group, and if a higher layer parameter RepSchemeEnabler is set to any one of "FDMSchemeA", "FDMSchemeB", and "TDMSchemeA", the WTRU can detect the activation of enhanced PUCCH transmission. Two antenna ports can be multiplexed on the same subcarrier set by allocating different orthogonal codes. For example, if the WTRU receives an indication by DCI including two TCI states and two CDM groups without a TDRA field, the WTRU can detect the activation of enhanced PUCCH transmission.
[0209] In an example, the WTRU may be triggered to use multiple PUCCH configurations, e.g., based on the detected RNTI. For example, the WTRU may detect DCI scrambled with an RNTI. The WTRU may determine from the RNTI value that the transmission is intended for multiple TRPs (e.g., MTRP-RNTI, or C-RNTI with values defined in different ranges of a single MTRP). The WTRU may be triggered (e.g., based on the determination) to use multiple PUCCH configurations. In an example, a PUCCH configuration (e.g., each PUCCH configuration) may be associated with a separate K1, PUCCH resource indicator (PRI), and spatial relation, such that the WTRU may send multiple copies. For example, an MTRP-RNTI may be defined to indicate or permit the WTRU to determine the number of repetitions from the MTRP-RNTI value. For example, for n1 repetitions, the MTRP-RNTI values may be defined from [0; k*n1-1], and for n2 repetitions, the MTRP-RNTI values may be defined from [k*n1:k*n2-1], where k may be a scaling factor. For example, if the MTRP-RNTI value is less than k*n1, the WTRU may determine to use n1 repetitions with the K1, PRI, spatial relation, and / or PUCCH configuration associated with n1. Multiple PUCCH configurations, K1, PRI, spatial relations, etc. may be indicated (e.g., explicitly indicated) in the DCI (e.g., scrambled with an mTRP-RNTI) and / or may be pre-configured at the WTRU.
[0210] The WTRU may perform enhanced PUCCH transmission, e.g., based on a quality measurement threshold. The WTRU may perform enhanced PUCCH transmission, e.g., based on a comparison of downlink measurements (e.g., L1-RSRP, L1-SINR, CQI, mobility state, Doppler frequency, etc.) with a configured threshold.
[0211] The WTRU may determine the activation of enhanced PUCCH transmission, e.g., based on the PUCCH format and / or priority. For example, the WTRU may employ enhanced PUCCH transmission for PUCCH format 0 or 1 (e.g., only PUCCH format 0 or 1).
[0212] The WTRU may be configured (e.g., explicitly configured) to activate or deactivate enhanced PUCCH transmission.
[0213] The WTRU may be configured (e.g., via higher layer signaling) to activate or deactivate enhanced PUCCH transmission. The WTRU may be configured with additional information related to a dedicated resource set that may be used for enhanced transmission (e.g., PUCCH repetition on dedicated resources). The dedicated resources may be determined (e.g., based on configuration) to be available statically (e.g., without a time limit or always) and / or for a configured duration. The duration of time (e.g., which may be tracked using a timer, for example) may be based on an indication (e.g., explicit), such as (e.g., DCI or MAC CE).
[0214] The WTRU may receive an indication (e.g., dynamic), such as via DCI or MAC CE, to activate or deactivate enhanced PUCCH transmission. In an example, a DCI field may be considered an indication of activation or deactivation of enhanced PUCCH transmission. The DCI field may be a new field or a reuse of an existing field.
[0215] The DCI may indicate a resource set to be used by the enhanced PUCCH transmission. In an example, the DCI may (e.g., directly) point to the resource set. The resources may be determined, for example, based on a fixed or configurable offset from the PUSCH resources. The resources indicated for the enhanced PUCCH may be within or outside of the PUSCH resource region.
[0216] In an example, for instance, if the WTRU receives an uplink grant (e.g., without having sent an SR), the WTRU may use the indicated PUSCH resources for enhanced PUCCH transmission. The WTRU may interpret the received grant as an activation of enhanced PUCCH transmission.
[0217] PUCCH repetition and resource selection may be provided. The WTRU may perform in-slot frequency hopping for each repetition, for example, to improve (e.g., further improve) the performance of PUCCH repetition. The WTRU may use different repetition and frequency hopping patterns (e.g., per PUCCH type). The WTRU may employ a fixed or predefined repetition and frequency hopping pattern. The WTRU may receive related information (e.g., semi-static or dynamic). The related information may include the frequency hopping pattern. The WTRU may assume the pattern may be fixed, predefined, or it may be indicated dynamically / semi-statically. In an example, the repetition may be repeated at a location other than the resource location indicated by the PUCCH resource indicator (e.g., as shown within the bandwidth part). Figure 5 shown, within the bandwidth part).
[0218] Beamforming for PUCCH transmission can be indicated by spatial information (e.g., in NR). There can be one or more spatial relation configurations (e.g., parameter values) for a PUCCH resource (e.g., each PUCCH resource). The spatial settings for PUCCH transmission can be provided, for example, by a pucch - SpatialRelationInfoId configured in the PUCCH - SpatialRelationInfoId (e.g., for a single configuration). For example, if the WTRU is provided with multiple values for PUCCH SpatialRelationInfo, the WTRU can determine the spatial settings for PUCCH transmission (e.g., a single spatial setting) via a MAC control element. PUCCH transmission can be performed according to the spatial filter used for receiving the SSB, the configured CSI - RS, or the transmission for the SRS, for example, depending on the index configured in the spatial relation information.
[0219] Figure 6 FIG. is an example showing enhanced PUCCH transmission with a spatial relation cycle. The WTRU can be configured with multiple PUCCH repetitions. The WTRU can cycle within the configured spatial relation cycle for PUCCH repeated transmissions (e.g., each PUCCH repeated transmission).
[0220] In an example, a PUCCH resource ID (e.g., each PUCCH resource ID) can be configured with multiple (e.g., eight) PUCCH spatial relation information, for example, which is represented by code points in the MAC CE. The spatial information configured in the code points (e.g., each code point) can be applied to PUCCH transmission (e.g., each PUCCH transmission). The WTRU can determine from the MAC CE (e.g., one of the reserved bits in the MAC CE) whether to apply spatial cycling to PUCCH repetition or the active spatial relation (e.g., only the active spatial relation).
[0221] In an example, the WTRU can be configured with multiple PUCCH - SpatialRelationInfo. The configured code points (e.g., each configured code point) can represent one or more states of a spatial domain filter. The code points can be indicated to the WTRU. The WTRU can apply the spatial domain filters represented by different states in the code points on each repetition of the PUCCH. The application of the spatial domain filters indicated by the states (e.g., each state) can be, for example, sequential (e.g., based on the state order or another predetermined pattern known to the WTRU and the gNB).
[0222] The WTRU can (e.g., as Figure 6Transmit PUCCH repetitions, as shown in the example in , by, for example, considering one or more symbols as guard time (TG) between transmissions, e.g., to allow sufficient time to retune the spatial filter.
[0223] In an example, the WTRU may be configured with multiple beams (e.g., multiple PUCCH-spatialRelationInfo, spatial domain filters, etc.) for PUCCH transmissions with N repetitions. Each PUCCH transmission with N repetitions (e.g., each PUCCH transmission) may be associated with one of the configured beams (e.g., one configured beam). The beam may be determined, for example, based on: the symbol index (e.g., the starting symbol index within a time slot); and / or the PUCCH transmission number (e.g., the i-th transmission of the N repetitions, where i may be referred to as the PUCCH transmission number).
[0224] The WTRU may be configured with multiple PUCCH repetitions. Each PUCCH repetition (e.g., each PUCCH repetition) may be associated with PUCCH spatial relation information (e.g., a beam). The WTRU may determine a subset of PUCCH repetitions for transmission, for example, based on one or more of the following: measurements of the associated downlink reference signal in each PUCCH spatial relation information and / or the power backoff level of the PUCCH transmission associated with the PUCCH spatial relation information.
[0225] The WTRU may determine a subset of PUCCH repetitions for transmission, for example, based on measurements of the associated downlink reference signal in the PUCCH spatial relation information (e.g., each PUCCH spatial relation information). For example, one or more downlink reference signals may be associated with one or more PUCCH spatial relation information. The WTRU may determine the subset based on the measurements. For example, the WTRU may select the subset of repetitions associated with PUCCH spatial relation information having measurements above a threshold. For example, if the SRI is used as the PUCCH spatial relation information, the DL reference signal associated with the SRI may be used for DL measurements.
[0226] The WTRU may determine a subset of PUCCH repetitions for transmission, for example, based on the power backoff level of the PUCCH transmission associated with the PUCCH spatial relation information (e.g., due to maximum permitted exposure (MPE)). For example, based on the associated PUCCH spatial relation information, e.g., if the associated PUCCH transmission power is less than a threshold, or if the power backoff level is above a threshold (e.g., due to MPE), the WTRU may determine (e.g., decide) to skip transmitting the PUCCH within the PUCCH repetition.
[0227] A WTRU may determine different Physical Uplink Control Channel (PUCCH) Resource Indicators (PRIs) and spatial relationships for PUCCH repetition. For example, the WTRU may use a PRI value to determine which PUCCH resource configuration to use. The PRI may be a one-to-one index of the PUCCH resource. The WTRU may receive the PRI, for example, in Downlink Control Information (DCI), and / or the WTRU may receive the PRI in a Random Access Channel (RACH) procedure (e.g., msgB or msg4).
[0228] For example, the WTRU may determine the PUCCH spatial relationship and the PRI.
[0229] The WTRU may determine the PUCCH spatial relationship and the PRI, for example, by an association between the PRI value and a spatial filter. For example, the WTRU may receive the PRI. The PRI may be associated with multiple spatial filters. The WTRU may be triggered to transmit multiple PUCCH copies using the PRI. The WTRU may use multiple different spatial filters associated with the PRI of the multiple copies. The association between the PRI and the spatial filter may be preconfigured, for example. The PUCCH configuration may be implemented using frequency hopping. The WTRU may determine different spatial relationships for each hop.
[0230] The WTRU may determine the PUCCH spatial relationship and the PRI, for example, by multiple PRI values. The PRI (e.g., each PRI) may be associated with a spatial relationship. For example, the WTRU may receive a pair (e.g., PRI_i1, PRI_i2). The WTRU may determine, for example, whether to use PRI_i1 for repetition i1 (e.g., with an associated SRI_i1) and PRI_i2 for repetition i2 (e.g., with an associated SRI_i2). The SRI may be associated with the PRI, for example, as part of a configuration.
[0231] The WTRU may determine the PUCCH spatial relationship and the PRI, for example, based on an offset. The WTRU may receive the offset (e.g., delta_K). The spatial relationship and the PRI for repetition may be determined, for example, based on a pair (PRI, SRI). For example, the WTRU may determine to use PRI_i1 = PRI, where the associated SRI_i1 = SRI for repetition i1. The WTRU may decide to use PRI_i2 = PRI + delta_K, where the associated SRI_i2 = SRI for repetition i2, or the WTRU may decide to use PRI_i2 = PRI, where SRI_i2 = SRI for repetition i2 + delta_K. For example, the WTRU may use Equation 1 with delta_K to determine the PUCCH resource:
[0232]
[0233] where N CCE,pIt may be the number of CCEs in CORESETp for PDCCH reception of a DCI format, n CCE,p It may be the index of the first CCE for PDCCH reception, and Δ PRI It may be the value of the PUCCH resource indicator field of a DCI format.
[0234] The WTRU may select K1 and the spatial relationship for PUCCH repetition. The WTRU may use the K1 value, for example, to determine when to transmit the PUCCH timely. K1 may be the time offset between PDSCH and PUCCH transmissions. The WTRU may receive the K1 value (e.g., a K1 value) in DCI, for example, or the WTRU may receive K1 in a RACH procedure (e.g., msgB or msg4), for example.
[0235] The WTRU may determine the PUCCH spatial relationship by using the K1 value, for example.
[0236] The WTRU may determine the PUCCH spatial relationship by associating between the K1 value and the spatial relationship. For example, the WTRU may receive multiple K1 values (e.g., two K1 values), and may transmit the PUCCH at multiple different time instances (e.g., two different instances) identified by the multiple K1 values (e.g., two K1 values). K1 (e.g., each K1) may be associated with a spatial filter. The WTRU may determine which spatial transmission filter to use for transmission (e.g., each transmission) based on the K1 value, for example. For example, K1 (e.g., each K1) may be linked to an SSB, CSI-RS, or SRS, from which the WTRU may determine the QCL information.
[0237] The WTRU may determine the PUCCH spatial relationship by associating between the TCI code point and one or more K1 values. For example, the WTRU may receive the TCI code point linked to multiple TCI states (e.g., two TCI states). For example, the WTRU may determine that the code point will be configured with multiple K1 values (e.g., two K1 values), or each TCI state may be configured with a K1 value. The WTRU may be triggered to transmit multiple repetitions according to the number of K1 values linked to the TCI code point or multiple TCI states.
[0238] In an example, a K1 value (e.g., one K1 value) and an offset K1_offset can be linked to multiple PUCCH resources. The PUCCH resources (e.g., each PUCCH resource) can be configured with a spatial relationship. In the example, the WTRU can decide to send a first PUCCH repetition on PUCCH resource 1 with a time offset K1. The WTRU can send a second PUCCH repetition on PUCCH resource 2 with a time offset K1+K1_offset. The time offset K1_offset can be indicated (e.g., dynamically indicated), or the time offset can be a configurable value.
[0239] Figure 7 FIG. is an example diagram showing a resource configuration for PUCCH repetition based on a K1 value. Figure 7 An example is shown where the WTRU determines PUCCH resources based on K1 indication and uses an offset to trigger the WTRU to send multiple repetitions, e.g., each repetition having a separate configuration.
[0240] The WTRU can determine the PUCCH spatial relationship, for example, by using the K1 value. The WTRU can use an offset index to determine the spatial relationship for each TRP. In the example, i1 can be the SRI indicated in the DCI. The WTRU can decide to use i1 for the first repetition and i2 = i1+(i3-1)*SRI_offset for the second repetition (e.g., where SRI_offset can be indicated in the DCI or pre-configured), and i3 is the transmission index (e.g., repetition index, TRP index, CORESET pool index).
[0241] The WTRU can determine the PUCCH spatial relationship, for example, by using the K1 value. The time or SRI offset can be indicated, for example, dynamically in the DCI, indicated in msg3 or msgB, or indicated as part of a MAC-CE that updates the spatial relationship of the PUCCH resources.
[0242] The WTRU may be configured to determine the repetition number and the spatial filter mode. The WTRU may determine (e.g., dynamically determine) the repetition number and the spatial filter mode (such as, for example, SRI) of the PUCCH based on a look-up table. The table may be pre-configured (e.g., via RRC) as part of the PUCCH configuration. The SRI configuration may consist of the value or mode of the SRI (e.g., SRI1 - SRI2). The SRI value / mode may be determined for the PUCCH case. The WTRU may also determine the SRI value / mode for PUSCH repetition. The table may be configured for PUCCH or PUSCH configuration and may be used for either configuration. One table may be used for PUCCH and PUSCH, or one table may be configured per PUCCH and PUSCH. The table may consist of a link between the repetition number and one SRI value or multiple SRI values of a certain mode. The table may link one repetition number to SRI values of more than one mode. The table may include a link to the SRI mode. For PUCCH repetition, the table may be applicable to determine the PRI value / mode or a combination of SRI / PRI pairs. The SRI value / mode may be linked to multiple PRI values / modes, and a pair of SRI / PRI values / modes to be used may be determined using, for example, techniques as described herein. The PRI value / mode (e.g., one PRI value / mode) may be linked to multiple SRI values / modes.
[0243] A pre-determined rule may be employed to select the PUCCH repetition number and / or mode based on parameters and / or parameter combinations (e.g., as described herein). The TRP may know the WTRU selection via the pre-determined rule. The TRP may monitor the repetition number and the mode based on the table and the rules configured with the table. The WTRU may dynamically switch between single-TRP operation and multi-TRP operation. The WTRU may determine the switch based on the RSRP difference between TRP1 and TRP2. If the determined difference is below the threshold, the WTRU may determine that it may be equally far from the TRP and may determine to use transmission towards multiple TRPs.
[0244] Figure 8 An exemplary technique of a WTRU pre-configured with a table linking repetition and spatial filter mode is shown, where each spatial filter may be determined by SRI. Refer to Figure 8, the targets of SRI1 and SRI2 can be TRP1. The targets of SRI3 and SRI4 can be TRP2. The WTRU can use a parameter combination to select an appropriate number of repetitions, multi-TRP operation mode, and spatial filter mode. The WTRU can perform RSRP measurements and report them to the TRP. The WTRU can determine that the RSRP is higher than a threshold that can be determined to be sufficient for one repetition. The WTRU can determine that the RSRP difference between TRP1 and TRP2 is higher than the threshold. The WTRU can determine that TRP1 can be used (e.g., preferably used). Based on the table and CSI report, TRP1 can determine that the next PUCCH transmission can be a single repetition sent from the WTRU using SRI1. For the next PUCCH transmission, the WTRU can select a single-TRP mode with one repetition and can use the SRI1 spatial filter. The WTRU can perform (e.g., can subsequently perform) other RSRP measurements and can report the measurements to the TRP. The WTRU can determine that the RSRP difference between TRP1 and TRP2 is lower than the threshold. If the WTRU subsequently sends a PUCCH transmission, the WTRU can select a multi-TRP mode with two repetitions and can use the SRI1 and SRI3 modes.
[0245] The WTRU can determine which entry in a table consisting of a combination of a number of repetitions and / or modes to use based on one or more parameters. The parameters can be associated with one or more of the following: signal quality; panel configuration; TRP operation mode; previous transmission; subframe number; RS group; PRI (associated with the PUCCH case); and / or repetition type.
[0246] The WTRU can determine which entry in the table to use based on a parameter associated with signal quality. If the RSRP is higher than the threshold, the WTRU can determine to use SRI.
[0247] The WTRU can determine which entry in the table to use based on a parameter associated with panel configuration. The WTRU can determine to use SRI sent from the same or different panels. The WTRU can determine to change the number of repetitions, for example, based on the number of activated panels. If the WTRU employs two panels, the WTRU can use two repetitions per panel. If one panel is deactivated, the WTRU can switch to four repetitions on a single panel.
[0248] The WTRU can determine which entry in the table to use based on a parameter associated with the TRP operation mode. The WTRU can determine to use SRI based on whether the WTRU is sending to one TRP or multiple TRPs. The WTRU can use a mode in which multiple SRIs target one TRP, or can use a mode in which there is one SRI per TRP.
[0249] The WTRU may determine which entry in the table to use based on parameters associated with a previous transmission (e.g., the last transmission). The WTRU may determine to use a mode containing the SRI used in a previously scheduled transmission (e.g., in DCI or configured grant) or in a previous UL transmission (e.g., the last UL transmission) such as a RACH.
[0250] The WTRU may determine which entry in the table to use based on parameters associated with time, duration of time, etc. (e.g., using a timer). The WTRU may determine to use a certain repetition number or mode based on time, duration of time, etc. (e.g., using a timer). For example, the WTRU may determine to use a mode including the SRI used within the last T subframe or TTI.
[0251] The WTRU may determine which entry in the table to use based on parameters associated with the subframe number. The WTRU may determine the SRI based on the SFI mode or based on the parity of the time slot. If scheduled to start in an even time slot, the WTRU may determine to use one SRI mode.
[0252] The WTRU may determine which entry in the table to use based on parameters associated with the RS group. The WTRU may determine to use the SRI belonging to the same RS group.
[0253] The WTRU may determine which entry in the table to use based on parameters associated with the PRI (e.g., in the case of PUCCH). The WTRU may determine the SRI based on the associated PRI value. The PRI value / mode (e.g., each PRI value / mode) may be linked to multiple SRI values. If transmitting with PRI1, the WTRU may determine to use one of the SRI values / modes (e.g., SRI1, SRI2) linked to the PRI. The WTRU may determine which PRI value / mode and PRI number to use based on the SRI value / mode.
[0254] The WTRU may determine which entry in the table to use based on the associated repetition type A / B (e.g., in the case of PUSCH). The WTRU may determine the SRI configuration to use based on the configured repetition type. For example, if the repetition type is type A, the WTRU may determine to use SRI mode 1. If the repetition type is type B, the WTRU may use SRI mode 2. If the repetition type is type B, the WTRU may determine the mode based on whether the nominal repetition number is equal to the actual repetition.
[0255] The WTRU may be configured to solve PUCCH repetition that overlaps with PUSCH. A PUCCH repetition set may overlap with one or more PUSCH transmissions or PUSCH repetitions. For example, if at least one of the following conditions is met, the WTRU may multiplex the uplink control information (UCI) of the PUCCH repetition with the overlapping PUSCH transmission: the payload size of the PUCCH is below a threshold, where the threshold may be predefined (e.g., 12 bits or 2 bits) and may correspond to the maximum payload size of a certain type of coding such as, for example, polar coding or block coding; the coding scheme used to code the UCI is one of a set of allowed coding schemes for multiplexing with PUCCH repetition (e.g., block coding); the number of coded bits for the UCI after rate matching is the same across PUCCH repetitions and PUSCH repetitions or transmissions (e.g., all PUCCH repetitions and PUSCH repetitions or transmissions); or each PUCCH repetition will overlap with a PUSCH transmission or repetition, and for each PUCCH repetition, a multiplexing condition related to the timeline is met. If at least one of the above conditions is met, the PUSCH transmission may not be cancelled, and a receiver on the network side may be able to combine the reception from multiple UCI transmissions via PUCCH or PUSCH.
[0256] Additional conditions related to the priority index of PUCCH and PUSCH transmissions may be satisfied for multiplexing. If the priority index of a PUCCH or PUSCH transmission is lower than the overlapping transmission, and if the delay and / or reliability requirements of the transmission with a higher priority index may not be met in the case where multiplexing will occur, the PUCCH or PUSCH transmission may be discarded.
[0257] If the priority indices of the PUCCH repetition and the PUSCH transmission or repetition are the same, for example, in the case where at least one condition is not met, the WTRU may discard the overlapping PUSCH transmission or repetition.
[0258] PUCCH / PUSCH multiplexing and repetition may be provided. In PUCCH formats, PUCCH format 2 may be based on OFDM transmission, PUCCH formats 0 and 1 may be sequence-based, and formats 3 and 4 may be based on DFT-OFDM transmission. PUCCH format 2 may have a short duration in time (e.g., similar to PUCCH format 0).
[0259] In an example, enhanced PUCCH transmission may be based on repetition of PUCCH format 2. One or more occasions of PUCCH repetition may occur simultaneously with PUSCH transmission. For example, PUCCH repetition may occur (e.g., if enhanced PUCCH transmission is activated) based on a fixed or predefined pattern relative to the PUCCH resource indicated by the PUCCH resource indicator. For example, PUCCH transmission may be repeated at the same frequency location as the PUCCH resource indicated by the PUCCH resource indicator. PUCCH repetition may occur based on, for example, a frequency hopping pattern having a configurable offset relative to the actual (e.g., original, non-repeated) PUCCH transmission.
[0260] In an example (e.g., if repetition of PUCCH transmission is simultaneous with PUSCH transmission), the spatial domain filter for PUCCH repetition may be replaced with the spatial domain filter for the ongoing PUSCH transmission. UCI may be multiplexed with PUSCH data (e.g., in NR). For example, depending on the size of the UCI, the PUSCH payload may be punctured or rate matched. In an example, UCI transmission may be enhanced, for example, by employing a repetition mechanism for the actual UCI. The WTRU may enhance UCI transmission, for example, by using repetition (e.g., simple repetition) of HARQ and / or SR bits or by using codewords. The WTRU may enhance the reliability of UCI transmission, for example, by using more than one bit to transmit HARQ and / or SR feedback. The WTRU may use a codeword consisting of a number of bits corresponding to the UCI content (e.g., each UCI content). For example, in addition to the transmission of the actual PUCCH, UCI multiplexing with PUSCH may be used for UCI repetition (e.g., only for UCI repetition).
[0261] The PUSCH enhancements disclosed herein may be implemented in a system, apparatus, and / or method.
[0262] The WTRU may transmit multiple copies to, for example, improve the reliability of PUSCH transmission. The copies (e.g., each copy) may be transmitted, for example, with different spatial relationships, time, or frequency resource allocations, for example, to improve receive diversity. The WTRU may determine the spatial transmission filter.
[0263] The WTRU may use a spatial domain resource allocation table. The WTRU may determine the spatial relationship for uplink transmission and downlink reception. Examples described as determining the spatial relationship for uplink transmission on the PUSCH may be used to determine multiple spatial relationships for downlink reception on the PDSCH. The use of the word PUSCH may be replaced with PDSCH, and similar implementations may apply to the downlink.
[0264] The WTRU may determine the spatial relationship between PUSCH repetition and the spatial transmission filter, for example, based on a Spatial Domain Resource Allocation (SDRA) table. The SDRA table may be organized, for example, by the number of repetitions (e.g., row 1 for single repetition, row 2 for two repetitions, etc.). Table 1 is an example of an SDRA table. Each row may have N_sets sub-entries, where N_sets may be the number of sets of spatial relationships configured per repetition (e.g., see Figure 8 , Figure 10 and Figure 11 ).
[0265] Table 1 - Example of SDRA Table
[0266] Repetition number SDRA bit field Spatial relation set 1 0 {RS_1} 1 {RS_2} 2 0 {(RS_1, RS_2)} 1 {(RS_3, RS_4)}
[0267] The WTRU may be triggered to use a set of spatial relationships (e.g., one set of spatial relationships), for example, based on a bit field K_SDRA of length log2(N_sets) in the DCI scheduling the PUSCH transmission (e.g., as shown in Figure 9 ) and / or the RS index provided in the DCI.
[0268] Figure 9 FIG. is an example showing a resource configuration for PUCCH repetition based on one or more of SDRA and TDRA. The TDRA may be used by the WTRU to determine the number of repetitions. In the example, the resource configuration may refer to being associated with the spatial filter of the repetition. The WTRU may be triggered to use a set of spatial relationships based on, for example, a bit field K_SDRA of length log2(N_sets) in the DCI scheduling the PUSCH (e.g., as shown in the example in Figure 9 ). The WTRU may determine, for example, from the TDRA that the PUSCH transmission of the WTRU is configured with two repetitions. In the example, the WTRU may be configured with an SDRA table (e.g., the exemplary SDRA table in Table 1) and look up the row corresponding to two repetitions (e.g., row 2). The row may be configured with a set of spatial relationships N_sets: {(RS_1, RS_2), (RS_3, RS_4)}. The value of the received SDRA bit field may be 0. The WTRU may be triggered to use the first set of spatial relationships (RS_1, RS_2) based on the SDRA bit field having a value of 0. The WTRU may determine the spatial transmission filters for repetitions 1 and 2 based on RS_1 and RS_2, respectively.
[0269] The WTRU may trigger the use of a set of spatial relations based on, for example, the RS index provided in the DCI. For example, a set of spatial relations may be defined such that each set may be linked one-to-one with an RS. The WTRU may determine a row of the SDRA table based on, for example, the number of repetitions. The WTRU may decide to use the set of spatial relations containing the RS index. For example, the RS in the set of spatial relations consists of an SRI. The WTRU may receive the SRI in the DCI. The WTRU may decide to transmit two repetitions. The WTRU may determine (e.g., based on the SDRA table shown in Table 1) that the set of spatial relations linked to two repetitions may be configured as {(SRI_1,SRI_2),(SRI_3,SRI_4)}. The WTRU may receive SRI_1 in the DCI. For example, if the WTRU receives SRI_1 in the DCI, the WTRU may decide to use the set of spatial relations containing SRI_1, which is (SRI_1,SRI_2).
[0270] For example, if the WTRU or the TRP determines that the updated spatial relations may provide better performance, the set of spatial relations in the SDRA table may be reconfigured. The TRP may update the set of spatial relations, for example, via a MAC-CE containing a K_SDRA value. The WTRU may provide the set of spatial relations with an uplink MAC-CE. For example, the WTRU may decide to deactivate the panel. For example, the WTRU may recommend updating the SDRA table with the set of spatial relations such that the set of spatial relations (e.g., all sets of spatial relations) is configured for the activated panel.
[0271] The WTRU may determine spatial relations based on, for example, an enhanced TDRA configuration. The WTRU may be configured with a pusch-AllocationList table. The rows of the table (e.g., each row) may be configured with a set of spatial relations. For example, if the PUSCH allocation is configured with repetitions, the WTRU may be triggered to use multiple spatial relations from the set. The WTRU may decide to apply the spatial relations from the list by, for example, associating a repetition index (e.g., one repetition index) with a value (e.g., one value) in the set of spatial relations. For example, the switching timing offset may be configured to allow the WTRU to switch the WTRU's spatial relations for each transmission. For example, the WTRU may receive a TDRA pointing to row n of the pusch-AllocationList, and the row may be configured with a K2 value, a mapping type B, a start and length indicator value (SLIV), a switching timing offset, and a set of spatial relations spatialRelationSet = [RS_1,RS_2,…]. The WTRU may decide to use the spatial relations for the repetitions in the corresponding order of the list. For example, repetition 1 uses RS1, repetition 2 uses RS2, and so on. The WTRU may decide to apply the switching timing offset between each repetition when switching the WTRU's spatial relations. The TRP may expect to receive repetitions at a specified spatial relation and at a timing with an offset imposed therebetween.
[0272] PUSCH repetitions can be scheduled with different spatial relationships. The WTRU can use a K2 value, for example, to determine when to transmit the PUSCH in a timely manner. K2 can be the time offset between PDCCH to PUSCH transmission. The WTRU can receive the K2 value (e.g., one K2 value) in the DCI that schedules the PUSCH transmission, for example. The WTRU can decide to transmit multiple PUSCH repetitions with different spatial filters. For example, the WTRU can cause the WTRU transmission to alternate towards several receiving TRPs. The spatial filters for each TRP can be selected differently, for example, to maximize the received signal. The WTRU can use the time gap between repetitions, for example, to determine when to send the repetitions and to allow the WTRU to change the spatial filter characteristics of the WTRU.
[0273] In an example, the WTRU can determine the K2 value and the PUSCH spatial relationship for multiple PUSCH repetitions.
[0274] The WTRU can determine the K2 value and the PUSCH spatial relationship for multiple PUSCH repetitions, for example, by an association between the K2 value and the spatial relationship. For example, the WTRU can receive multiple K2 values. The K2 value (e.g., each K2 value) can be associated with a spatial filter. For example, the WTRU can receive multiple (e.g., two) K2 values in the DCI that schedules the PUSCH transmission. The WTRU can transmit the PUSCH transmission at multiple (e.g., two) different times identified by the multiple (e.g., two) K2 values. The K2 value (e.g., each K2 value) can be associated with a spatial filter, for example, such that the WTRU can determine which spatial transmission filter to use for the repetition (e.g., each repetition) based on the K2 value.
[0275] The WTRU can determine the K2 value and the PUSCH spatial relationship for multiple PUSCH repetitions, for example, by an association between the UL TCI code point and the K2 value. For example, the WTRU can receive the UL TCI code point linked to multiple (e.g., two) TCI states. The code point can be linked to multiple K2 values. The WTRU can use the multiple K2 values to send PUSCH repetitions at different time instances. The WTRU can determine the spatial filter of the WTRU, for example, based on the UL TCI state connected to the TCI code point. The K2 value can be linked to the TCI state.
[0276] The WTRU may receive a K2 value (e.g., a single K2 value) and an offset K2_offset, which the WTRU may use to determine when to send PUSCH repetitions. The WTRU may decide to send the first PUSCH repetition with a time offset of K2 and the second PUSCH repetition with a time offset of K2+K2_offset. The time offset K2_offset may be indicated (e.g., dynamically indicated) in the DCI, or the time offset may be a configurable value. For example, if the WTRU is scheduled for multiple repetitions towards multiple TRPs, the WTRU may decide to use the offset. The WTRU may decide to use the spatial relation for the repetitions (e.g., provided in the DCI), or the offset may be linked to the spatial relation. For example, the WTRU may apply the offset as: K2 = K2_DCI+(i3-1)*K2_offset, where K2 may be the offset for the repetition, K2_DCI may be the value indicated in the DCI, i3 may be the index of the i3-th transmission (e.g., repetition index, TRP index, coresetpoolindex), and K2_offset may be the offset. The WTRU may determine the time slot to be used for the i3-th transmission, e.g., having i3.
[0277] For example, the WTRU may determine the spatial filter for the repeated transmission.
[0278] The WTRU may use an offset index to determine the spatial relation included in the DCI. For example, i1 may be the SRI indicated in the DCI. The WTRU may decide to use i1 for the first repetition and i2 = i1+(i3-1)*SRI_offset for the second repetition (e.g., where SRI_offset may be indicated in the DCI or may be pre-configured), and i3 may be the index of the i3-th transmission (e.g., repetition index, TRP index, coresetpoolindex).
[0279] The WTRU may be pre-configured with a spatial relation pattern to be used for multiple relations, for example. If the WTRU receives a TCI code point linked to multiple TCI states, for example, the WTRU may be triggered to use a certain pattern.
[0280] The WTRU may implicitly determine the spatial filter based on DCI fields. The spatial filter index, number of repetitions, single / multi-TRP mode, and / or spatial filter mode may be referred to as the spatial filter configuration. The WTRU may be scheduled to send PUSCH repetitions with a DCI that may or may not signal (e.g., explicitly signal) the spatial filter, number of repetitions, or spatial filter mode.
[0281] The WTRU may determine (e.g., implicitly determine) the spatial filter configuration, for example, through a field or combination of fields in the DCI and a link from the fields to a spatial filter configuration table, asFigure 10 As shown. One or more DCI fields may be linked to the spatial filter configuration. The WTRU may determine the spatial filter configuration based on the status of one DCI field or a combination of DCI field statuses. The DCI field may include a new data indicator (NDI), a hopping flag, MCS, a redundancy value (RV), a BWP indicator, a UL or supplementary UL (SUL) indicator, etc. If the WTRU receives an NDI = 0 field status, the WTRU may use mode 1 (e.g., SRI1 - SRI2). If the WTRU receives an NDI = 1 field status, the WTRU may use SRI1 - SRI2 - SRI3 - SRI4. The WTRU may use a combination of field statuses to determine the spatial filter configuration. If the WTRU receives data indicating NDI = 0 and RV = 0, the WTRU may determine to use SRI1 - SRI2. If the WTRU receives data indicating NDI = 0 and RV = 1, the WTRU may determine to use SRI3 - SRI4. The DCI field status may be encoded as a bitstream. The value '00' in the bitstream may be used to correspond to a DCI field NDI equal to zero (NDI = 0) and a DCI field RV equal to zero (RV = 0). The value '01' in the bitstream may be used to correspond to a DCI field NDI equal to zero (NDI = 0) and a DCI field RV equal to one (RV = 1). Each bitstream may be mapped to a spatial filter configuration table. The mapping may be reconfigured, for example, by MAC - CE.
[0282] The WTRU may determine how to map the spatial filter configuration one - to - one to the repetition, or the WRTU may determine different modes based on the DCI field. The WTRU may determine that the spatial configuration mode is SRI1 - SRI2 with four repetitions. If it is determined that the RV is equal to zero (RV = 0), the WTRU may apply SRI1 - SRI1 - SRI2 - SRI2. If it is determined that the RV is equal to one (RV = 1), the WTRU may apply SRI1 - SRI2 - SRI1 - SRI2. The mode may be linked to the number of repetitions, so the WTRU may determine to use one mode with two repetitions and a different mode if four repetitions are sent.
[0283] The field may be linked to an entry in a table such as the SDRA table described in conjunction with Table 1. The WTRU may receive an explicit SDRA indication in the DCI. For example, the explicit SDRA indication may indicate a subset of SRI values / modes. The WTRU may, for example, use the field value from the DCI to determine one value / mode from the subset. If there is no indication (e.g., explicit indication) in the DCI for the spatial filter configuration, a pre - configured table (e.g., as Figure 10As depicted). The TRP can be used to configure the link between the DCI value and the spatial filter configuration table entry. The WTRU can derive (e.g., implicitly derive) the spatial filter configuration based on one or more DCI fields. The WTRU can receive DCI with a hopping flag equal to one (hopping flag = 1), an NDI equal to zero (NDI = 0), and an RV equal to three (RV = 3). The WTRU can map those DCI fields to a table with a pre-configured spatial filter configuration. The table can be part of the PUSCH configuration or linked to the PUSCH configuration that can be used, for example, for the PUCCH. The WTRU can determine to use four repetitions towards multiple TRPs in SRI1 - SRI1 - SRI3 - SRI3 of mode SRI1 - SRI3. If the TRP schedules the WTRU with DCI, the TRP can monitor the WTRU repetitions according to the established link in the table. The WTRU can provide feedback via CSI reporting or beam failure recovery (BFR) (e.g., BFR MAC - CE). The TRP can change the spatial filter configuration in the table according to the WTRU feedback. MAC - CE or RRC reconfiguration can be used to update the table.
[0284] The DCI field can be mapped to more than one mode. The WTRU can determine to use one mode based on, for example, a parameter. The WTRU can determine to use one or more modes based on one or more of the following: channel quality (RSRP, SINR, etc.); the last used spatial filter configuration; the default configuration (e.g., default use of a single TRP); time, duration of time, timer, etc. (e.g., between the DCI and the scheduled PUSCH); and / or the subframe index in which the DCI is received.
[0285] The WTRU can use a configured grant with multiple spatial relationships. The WTRU can be (pre)-configured to perform PUSCH transmission in a configured grant (e.g., one configured grant) using, for example, a set of spatial relationships. The WTRU can determine the spatial relationship transmission mode for the TB (e.g., each TB) and / or the configured grant (e.g., each configured grant), which can include, for example, one or more of the following: the set of spatial relationships that can be used for TB transmission (e.g., each TB transmission); the set of spatial relationships that can be used for transmission in the configured grant (e.g., each configured grant); the sequence of spatial relationships that can be used for resources in a beam (e.g., each resource in a beam) and / or the sequence of spatial relationships that can be used for a resource bundle (e.g., each resource bundle), which can allow the WTRU to determine which spatial relationship to use in each transmission resource; and / or the sequence of spatial relationships that can be used for the transmission of a TB (e.g., one TB), which can allow the WTRU to determine which beam to use for the transmission of the TB (e.g., each transmission) (e.g., which spatial relationship to use for the initial transmission, and which beam to use for each retransmission).
[0286] The spatial relation transmission mode may be determined, for example, based on one or more of the following: (pre)configuration via the network; the number of repetitions of the TB in the configuration grant; the time gap between consecutive transmissions of the TB (e.g., two consecutive transmissions); the set of spatial relations configured in the configuration grant; and / or the QoS of the data configured in the grant.
[0287] The spatial relation may be (pre)configured via the network. The WTRU may determine the spatial relation transmission mode, for example, based on the configuration grant configuration. The WTRU may be configured with a spatial relation transmission mode in the configuration grant, which may be associated with the TB (e.g., each TB), the resource bundle, and / or the period of the configuration grant. For example, the WTRU may be (pre)configured as a table of multiple spatial relation transmission modes. The WTRU may be configured with an index in the table indicating which spatial relation transmission mode to use.
[0288] The number of repetitions of the TB may be specified (e.g., in the configuration grant). The WTRU may determine the spatial relation transmission mode, for example, based on the number of repetitions of the TB in the configuration grant. For example, the WTRU may be scheduled with a grant for a transmission bundle with repK resources (e.g., when the WTRU uses a configuration grant, repK may give the number of repetitions to use). The WTRU may decide to use a first beam for the first N transmissions and a second spatial relation for the remaining transmissions of the bundle.
[0289] There may be a time gap between consecutive transmissions of the TB (e.g., two consecutive transmissions). The WTRU may be configured with a multi-beam set for PUSCH transmission. The WTRU may determine which beam set to use for transmission in the grant's bundle (e.g., one bundle), for example, based on the time gap between the resources in the bundle. For example, if the time gap is less than a threshold, the WTRU may use a first set of spatial relations (e.g., the first beam set may be associated with one panel). For example, if the time gap is greater than the threshold, the WTRU may use a second set of beams (e.g., the second beam set may be associated with multiple antenna panels).
[0290] A beam set can be configured in the grant. The WTRU can determine a spatial relationship transmission mode, for example, based on the beam set configured in the grant. The WTRU can determine which beam subset can be used for transmission in the beam and / or for transmission of the TB based on the beam set configured for the configured grant. For example, the WTRU can be configured with (e.g., one) beam set (e.g., two beams) for transmission in the configured grant. For example, if the beam set is associated with a panel (e.g., one panel), the WTRU can decide to use (e.g., all) the beams for transmission of the TB or for transmission within the beam. For example, if the beam set is associated with multiple panels, the WTRU can decide to use a beam subset (e.g., one beam subset) associated with a panel (e.g., one panel) for transmission of the TB or for transmission within one beam. This method can prevent the WTRU from performing panel switching for transmission within a beam (e.g., one beam) and / or for transmission of the TB.
[0291] The beam transmission mode can be determined based on the QoS of the TB. The WTRU can determine the beam transmission mode, for example, based on the QoS of the associated TB, which can be determined, for example, based on one or more of the following: the priority of the logical channel (LCH) included in the TB and / or the reliability of the data included in the TB. In an example, the priority of the TB can be determined as the highest priority of the LCHs included in the TB. The reliability of the data included in the TB can be based on the packet error rate (PER). In an example, an LCH (e.g., each LCH) can be configured with one or more reliability values that can be used to indicate the required PER of the data in the LCH. For example, the WTRU can determine the reliability of the TB based on the highest reliability of the LCHs having data included in the TB. The WTRU can be configured with one or more reliability levels for a QoS flow (e.g., each QoS flow). For example, the WTRU can determine the reliability of the TB based on the highest reliability of the flows included in the TB.
[0292] In an example, the WTRU can use a first beam mode for a TB having a first priority range. The WTRU can use a second beam mode for a TB having a second priority range. In an example, the WTRU can be configured with multiple (e.g., two) LCH sets. The first LCH set can be associated with high-reliability data, and the second LCH set can be associated with low-reliability data. The WTRU can use a first beam set (e.g., one beam) for transmission of a TB having data from the second LCH set and can use a second beam set (e.g., having two associated panels) for transmission of a TB having data from at least one LCH in the first LCH set.
[0293] The WTRU may be configured to perform resource selection based on dynamic switching between a single-TRP transmission mode and a multi-TRP transmission mode. In an example, Figure 11 the features described herein associated with resource selection based on dynamic switching between single-TRP and multi-TRP may be shown. For example, the WTRU may determine a repetition category based on the indicated repetition. The WTRU may determine, for example (e.g., after determining the repetition category), an SRI mode from among multiple SRI modes in the repetition category based on signaled RV information (e.g., RV bits) and SDRA information (e.g., SDRA bits).
[0294] The WTRU may dynamically determine a transmission mode for PUSCH transmission (e.g., PUSCH transmission scheduled using DCI) or for PUCCH related to DCI (e.g., single-TRP or multi-TRP, e.g., as Figure 10 and Figure 11 shown). The WTRU may determine the transmission mode based on, for example, a dynamic indication in the DCI, an explicit indication using, for example, SDRA, and / or an implicit indication (e.g., DCI field combination), e.g., as described in exemplary Figure 10 and Figure 11 .
[0295] The WTRU may determine to transmit using an uplink single-TRP mode or a multi-TRP mode based on the scrambling for the DCI. The scrambling may be partitioned into subsets of values, where each subset may be associated with a transmission mode (e.g., single-TRP mode or multi-TRP mode).
[0296] The WTRU may use the scheduling type to determine whether to use single-TRP transmission or multi-TRP transmission. The WTRU may determine that a type 1 configured grant subset may be used for single-TRP transmission and another subset may be used for multi-TRP transmission. The WTRU may determine that type 1 configured grant may be associated with a single-TRP transmission mode and type 2 configured grant may be associated with a multi-TRP transmission mode.
[0297] If the WTRU determines the transmission mode, the WTRU may not have values for other spatial relation parameters, such as, for example, SRI, mode, etc. The WTRU may determine the values of unknown parameters based on the transmission mode.
[0298] The WTRU may determine transmission parameters for the repetition for PUCCH transmission or PUSCH transmission, for example, based on the transmission mode (e.g., single-TRP or multi-TRP) or based on a threshold given by the number of TRPs (e.g., N_TRP > 1).
[0299] The WTRU may determine that a default transmission mode is linked to the number of repetitions. The WTRU may determine that N_rep > 2 may be configured for the multi-TRP mode.
[0300] For N_rep > 2 repetitions, if the WTRU determines that it is in a multi-TRP mode, the WTRU may determine to adopt N_rep spatial relations across the TRPs (e.g., N_rep best spatial relations). The WTRU may be configured with one set of spatial relations per TRP (e.g., a minimum set). During the N_rep repetitions, the WTRU may determine to use at least one spatial relation from each TRP to ensure the use of multi-TRP.
[0301] The WTRU may determine to add a switching gap between repetitions, for example, according to the transmission mode. If scheduled in a multi-TRP mode, the WTRU may determine to add an additional switching gap when switching between SRIs (e.g., if each SRI is associated with a different panel and each panel is associated with a TRP, the panel switching time is considered). The switching gap may be associated with the repetition pattern, and the switching gap may be activated according to the number of TRPs. In the case of one TRP, there may be no switching gap. For MTRP, if the WTRU switches SRIs, the WTRU may use a gap of T_gap seconds.
[0302] The WTRU may determine a default repetition pattern (e.g., cyclic or sequential) or a default spatial relation (e.g., SRI) for each transmission mode. If the WTRU determines to use a single-TRP mode, the WTRU may determine to use a cyclic repetition pattern (e.g., SRI1 - SRI2 - SRI1 - SRI2). If the WTRU determines to use multi-TRP, the WTRU may determine to use a sequential repetition pattern (e.g., SRI1 - SRI1 - SRI2 - SRI2). Assuming the SRIs are on different panels, these may be configured to reduce (e.g., minimize) the switching time between SRI changes.
[0303] The WTRU may determine the set of spatial relations for repetition based on whether the transmission is single-TRP or multi-TRP. If the WTRU determines that the transmission is single-TRP, the WTRU may determine to use two spatial relations to the single-TRP, which may be, for example, two best spatial relations. If the WTRU determines that the transmission is multi-TRP, the WTRU may determine to use the spatial relation from TRP1 (e.g., the best spatial relation) and the spatial relation from TRP2 (e.g., the best special relation). The WTRU may select the spatial relation, such as the best spatial relation, at least based on the signal quality indicated by, for example, the reference signal received power (RSRP).
[0304] If the PUSCH transmission corresponds to a Type 2 configured grant activated by DCI, the WTRU may dynamically switch between multiple configuredGrantConfigs. The WTRU may be configured with multiple configured grants. The WTRU may receive DCI with a dynamic indication of a switch from a single TRP mode to a multi-TRP mode. The WTRU may determine to use a configured grant with spatial relation parameters for the multi-TRP mode.
[0305] The WTRU may be configured with one configured grant, and the configured grant may be associated with multiple spatial relation sets. The WTRU may determine that the spatial relations can be divided into single-TRP spatial relations and multi-TRP spatial relations, and the WTRU may determine which spatial relation to use based on which transmission mode is used. The WTRU may have a configured grant type 1 that can be configured with one spatial relation mode for the single-TRP mode and one spatial relation mode for the multi-TRP mode. The WTRU may determine that the PUSCH transmission on the configured grant is for the multi-TRP mode. The WTRU may determine to use the spatial relation for the multi-TRP associated with the configured grant.
[0306] The WTRU may determine transmission parameters based on the scrambling used. For Type 2 configured grants, the grants may be divided according to a scrambling subset (e.g., CS-RNTI subset). The WTRU may determine the spatial filter for single-TRP transmission or multi-TRP transmission based on a configured link between the subset and an index.
[0307] For PUCCH transmission, the WTRU may determine the PUCCH repetition parameter based on whether the single-TRP mode or the multi-TRP mode is used.
[0308] For PUCCH transmission carrying a CSI report, the WTRU may determine the PUCCH configuration or PRI according to whether the CSI report is for the single-TRP mode or the multi-TRP mode. If the CSI report contains a report of reference signals associated with more than one TRP, the WTRU may determine to use the PUCCH spatial relation repetition configuration for the multi-TRP with a switching gap and SRI determined for the multi-TRP.
[0309] The WTRU may determine the CSI report configuration to be used based on the number of TRPs or the repetition number. The WTRU may select resources (e.g., group-based or non-group-based reports, number of beams in the report, RSRP or SINR report) according to whether the CSI report is repeated to a single TRP or a multi-TRP. The WTRU may determine that it is reporting PUCCH repetition to multiple TRPs. If N_TRP is greater than one (N_TRP>1), the WTRU may determine to report SINR. If the CSI is reported to a single TRP, the WTRU may determine to report RSRP.
[0310] If the WTRU receives a dynamic indication between a single TRP and multiple TRPs, the WTRU may determine a set of spatial relations and transmission parameters to be used for transmission. The WTRU may adjust its spatial transmission filter so as to apply it to PUCCH transmission or PUSCH transmission. The WTRU may send multiple repetitions, where each repetition may use one of the spatial relations from the determined set of spatial relations.
[0311] Although the above features and elements have been described in specific combinations, each feature or element may be used alone without the other features and elements of the preferred embodiment, or may be used in various combinations with or without other features and elements.
[0312] Although the specific implementations described herein may consider 3GPP-specific protocols, it should be understood that the specific implementations described herein are not limited to such scenarios and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to this scenario and are also applicable to other wireless systems.
[0313] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or a processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and optical media (such as compact disc (CD)-ROM disks and / or digital versatile disc (DVD)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, a terminal, a base station, an RNC, and / or any host computer.
Claims
1. A wireless transmit / receive unit (WTRU), the WTRU comprising: a processor configured to: obtain configuration information associated with multi-transmission / reception point (M-TRP) physical downlink control channel (PDCCH) transmission decoding, wherein the configuration information includes conditions associated with performing M-TRP PDCCH transmission decoding, wherein the conditions are associated with a radio network temporary identifier (RNTI), a control resource set identifier, a precoder granularity, and a mapping type; determine to attempt to perform M-TRP PDCCH transmission decoding based on a determination that the conditions are met; detect at least a first PDCCH transmission and a second PDCCH transmission, wherein the first PDCCH transmission is associated with a first transmission / reception point (TRP) and the second PDCCH transmission is associated with a second TRP; attempt to perform M-TRP PDCCH transmission decoding on the first TRP and the second TRP; determine that the PDCCH transmission decoding associated with the first TRP has been successful, wherein the determination that the PDCCH transmission decoding associated with the first TRP has been successful is based on a determination that the first PDCCH transmission associated with the first TRP has been successfully decoded; determine that the PDCCH transmission decoding associated with the second TRP has not been successful, wherein the determination that the PDCCH transmission decoding associated with the second TRP has not been successful is at least based on a determination that decoding of the second PDCCH transmission associated with the second TRP has not been successful; and send feedback to a base station via a physical uplink control channel (PUCCH) transmission, wherein the feedback includes the RNTI, the TRP index, and the control resource set index associated with the first PDCCH transmission, wherein the RNTI, the TRP index, and the control resource set index associated with the first PDCCH transmission indicate that the PDCCH transmission decoding associated with the first TRP has been successful, wherein the feedback indicates the aggregation level associated with the PDCCH transmission decoding associated with the first TRP, and wherein the feedback indicates that M-TRP PDCCH transmission decoding has been used.
2. The WTRU according to claim 1, wherein, The determination that the PDCCH transmission decoding associated with the second TRP has not been successful is further based on a determination that decoding of a third PDCCH transmission associated with the second TRP has not been successful, wherein attempting to decode the third PDCCH transmission associated with the second TRP is performed based on a determination that decoding of the second PDCCH transmission associated with the second TRP has not been successful, and wherein the feedback further indicates a repetition index associated with the second TRP.
3. The WTRU according to claim 2, wherein, The determination that the decoding of the PDCCH transmission associated with the second TRP is unsuccessful is further based on the determination that the decoding of the soft combination information associated with the second PDCCH transmission and the third PDCCH transmission is unsuccessful, where the feedback further indicates that the decoding using the soft combination information associated with the second PDCCH transmission and the third PDCCH transmission is unsuccessful.
4. The WTRU according to claim 3, wherein The feedback further includes an indication to switch to a single-TRP transmission mode.
5. A method for use in a wireless transmit / receive unit (WTRU), the method comprising: Obtaining configuration information associated with multi-transmit / receive point (M-TRP) physical downlink control channel (PDCCH) transmission decoding, where the configuration information includes conditions associated with performing M-TRP PDCCH transmission decoding, where the conditions are associated with a radio network temporary identifier (RNTI), a control resource set identifier, a precoder granularity, and a mapping type; Based on the determination that the conditions are met, determining to attempt to perform M-TRP PDCCH transmission decoding; Detecting at least a first PDCCH transmission and a second PDCCH transmission, where the first PDCCH transmission is associated with a first transmit / receive point (TRP), and the second PDCCH transmission is associated with a second TRP; Attempting to perform M-TRP PDCCH transmission decoding for the first TRP and the second TRP; Determining that the decoding of the PDCCH transmission associated with the first TRP has been successful, where the determination that the decoding of the PDCCH transmission associated with the first TRP has been successful is based on the determination that the first PDCCH transmission associated with the first TRP has been successfully decoded; Determining that the decoding of the PDCCH transmission associated with the second TRP is unsuccessful, where the determination that the decoding of the PDCCH transmission associated with the second TRP is unsuccessful is at least based on the determination that the decoding of the second PDCCH transmission associated with the second TRP is unsuccessful; and Transmitting feedback to a base station via a physical uplink control channel (PUCCH) transmission, where the feedback includes the RNTI, the TRP index, and the control resource set index associated with the first PDCCH transmission, where the RNTI, the TRP index, and the control resource set index associated with the first PDCCH transmission indicate that the decoding of the PDCCH transmission associated with the first TRP has been successful, where the feedback indicates the aggregation level associated with the decoding of the PDCCH transmission associated with the first TRP, and where the feedback indicates that M-TRP PDCCH transmission decoding has been used.
6. The method according to claim 5, wherein, The determination that the decoding of the PDCCH transmission associated with the second TRP is unsuccessful is further based on the determination that the decoding of the third PDCCH transmission associated with the second TRP is unsuccessful, wherein the attempt to decode the third PDCCH transmission associated with the second TRP is performed based on the determination that the decoding of the second PDCCH transmission associated with the second TRP is unsuccessful, and wherein the feedback further indicates a repetition index associated with the second TRP.
7. The method according to claim 6, wherein, The determination that the decoding of the PDCCH transmission associated with the second TRP is unsuccessful is further based on the determination that the decoding of the soft combination information associated with the second PDCCH transmission and the third PDCCH transmission is unsuccessful, and wherein the feedback further indicates that the decoding using the soft combination information associated with the second PDCCH transmission and the third PDCCH transmission is unsuccessful.
8. The method according to claim 7, wherein, The feedback further includes an indication to switch to the single-TRP transmission mode.
Citation Information
Patent Citations
Method implemented in WTRU, WTRU, and network node
CN108599905A
Feedback transmission techniques in coordinated clusters of transmission reception points
US20190261278A1