Reliable control signaling

Abstract

Systems, methods, and means for reliable control signaling in New Radio (NR) and the like are disclosed. In one embodiment, a receiver in a wireless transmit / receive unit (WTRU) can receive one or more physical downlink control channel (PDCCH) transmissions including downlink control information (DCI). The WTRU can determine a transmission profile associated with uplink control information (UCI). Based on the transmission profile, the WTRU can determine one or more transmission characteristics associated with transmitting the UCI. The WTRU can transmit the UCI via a physical uplink control channel (PUCCH). The UCI can be transmitted using the transmission characteristics determined by the WTRU. The WTRU can transmit the UCI based on at least one of a control resource set (CORESET), a search space, or a radio network temporary identifier (RNTI).

Description

Technical Field

[0001] Relates to reliable control signaling.

Background Art

[0002] Cross-reference to related applications This application claims the benefit of U.S. Provisional Patent Application No. 62 / 519,585, filed Jun. 14, 2017; U.S. Provisional Patent Application No. 62 / 585,937, filed Nov. 14, 2017; U.S. Provisional Patent Application No. 62 / 652,002, filed Apr. 3, 2018; and U.S. Provisional Patent Application No. 62 / 667,015, filed May 4, 2018, the contents of which are incorporated herein by reference.

[0003] Mobile communications using wireless communication continue to evolve. The fifth generation or next generation (NG) wireless system can be referred to as 5G or New Radio (NR). Previous generations of mobile communications can be, for example, the fourth generation (4G) Long Term Evolution (LTE). The set of use cases for NR can generally be classified into one of enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), or massive machine type communication (mMTC).

Summary of the Invention

Problems to be Solved by the Invention

[0004] Current processing and transmission mechanisms used for such use cases may be inferior in efficiency.

Means for Solving the Problems

[0005] For example, a system, method, and means for reliable control signaling in new radio (NR) is disclosed. A receiver in a radio transceiver unit (WTRU) can receive one or more physical downlink control channel (PDCCH) transmissions containing downlink control information (DCI). The WTRU can determine a transmission profile associated with uplink control information (UCI). The transmission profile may be determined based on one or more of the following: identification of a logical channel or logical channel group for the data associated with the UCI, and characteristics of at least one PDCCH transmission. The PDCCH transmission may be mapped to one or more resources in a control resource set (CORESET).

[0006] The transmit profile may be determined based on one or more DCI fields in the received DCI, or one or more identifiers of the bandwidth portion (BWP) used to transmit one or more DCI or UCIs.

[0007] A DCI may include a first DCI and a second DCI. The DCI field may indicate a Hybrid Automatic Retransmission Request (HARQ) process index or a logical channel priority. The first DCI may be received using a first control resource set (CORESET), and the second DCI may be received using a second CORESET. The first or second CORESET may include one or more of the following: a component carrier, at least one BWP, a subset of resource blocks within each bandwidth portion, a set of time symbols within a slot or minislot, a subcarrier interval, a subset of slots within a subframe, or at least one reference signal.

[0008] A UCI can include a first UCI and a second UCI. The first or second UCI can include one or more Hybrid Automatic Retransmission Requests (HARQs), Scheduling Requests (SRs), or Channel Quality Indicators (CQIs). A UCI can be transmitted based on a CORESET, search space, or RNTI. A UCI can be associated with a PDSCH transmission or a PDCCH transmission. In one example, the first or second UCI can include feedback information bits for data transmissions assigned by the first or second DCI. In another example, the second UCI can correspond to redundant transmissions of the first UCI.

[0009] Based on the transmit profile, the WTRU can determine one or more transmit characteristics associated with the UCI transmit. One or more transmit characteristics may include at least one of the following: one or more coding parameters, one or more transmit power parameters, one or more resource allocation parameters, or priority levels.

[0010] A WTRU can transmit a UCI via a physical uplink control channel (PUCCH). The UCI can be transmitted using transmission characteristics determined by the WTRU. The WTRU can transmit a UCI based on one or more of the following: CORESET, search space, or radio network temporary identifier (RNTI). The PUCCH transmitting the UCI can be transmitted over the uplink (UL) carrier and / or auxiliary uplink (SUL) carrier.

[0011] The WTRU can determine the transmit profile associated with a PDSCH transmit, for example, if the UCI includes a Hybrid Auto-Retransmit Request Acknowledgment (HARQ ACK), based on one or more of the following: the transmit duration, the bandwidth part, the neurology, or the Modulation Coding Scheme (MCS) table for the control information.

[0012] For example, if the UCI includes Channel Status Information (CSI), the WTRU can determine the transmit profile based on one or more of the following: the value of the Block Error Rate (BLER) target associated with the CSI, or the CSI reporting settings.

[0013] For example, if the UCI includes a scheduling request (SR) associated with a physical uplink control channel (PUCCH) resource configured for transmitting an SR, the WTRU can determine the transmit profile based on one or more of the following: subcarrier interval, duration of the PUCCH resource, logical channel associated with the SR configuration, and priority associated with the logical channel.

[0014] A more detailed understanding can be obtained from the following description, which is provided as an example along with the attached drawings. [Brief explanation of the drawing]

[0015] [Figure 1A] This figure shows an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] Figure 1A shows an exemplary wireless transceiver unit (WTRU) that may be used in the communication system. [Figure 1C] Figure 1A is a system diagram showing exemplary radio access networks (RANs) and core networks (CNs) that may be used within the communication system. [Figure 1D]Figure 1A is a system diagram showing further exemplary RANs and further CNs that may be used within the communication system. [Figure 2] This figure shows an example of Downlink Control Information (DCI) diversity. [Figure 3] This figure shows examples of DCI and Uplink Control Information (UCI) diversity. [Modes for carrying out the invention]

[0016] With reference to various figures, a detailed description of exemplary embodiments will now be given. This description provides detailed examples of possible implementations, but it should be noted that the details are illustrative and are not intended to limit the scope of this application in any way.

[0017] Figure 1A is a diagram of an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may consist of multiple access systems that provide content such as voice, data, video, messaging, and broadcast communications to multiple radio users. The communication system 100 enables multiple radio users to access such content by sharing system resources, including radio bandwidth. For example, the communication system 100 may use one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), quadrature FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT spread OFDM (ZT UW DTS-s OFDM), unique-word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and similar.

[0018] As shown in Figure 1A, the communication system 100 may include radio transceiver units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d may all be called “stations” and / or “STAs” that are configured to transmit and / or receive radio signals and may include user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain situations), consumer electronic devices, and devices operating on commercial and / or industrial wireless networks. Any of WTRU102a, 102b, 102c, and 102d may be mutually interchangeable and referred to as UEs.

[0019] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as CN 106 / 115, the Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be transceiver base stations (BTS), node B, eNodeB, home node B, home eNodeB, gNB, NR node B, site controller, access point (AP), wireless router, and similar. Although base stations 114a and 114b are shown as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0020] Base station 114a can be part of RAN104 / 113, which can also include other base stations and / or network elements (not shown) such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Base station 114a and / or base station 114b can be configured to transmit and / or receive radio signals at one or more carrier frequencies that can be referred to as a cell (not shown). These frequencies can be an authorized spectrum, an unlicensed spectrum, or a combination of authorized and unlicensed spectra. A cell can provide a coverage area for providing radio services to a specific geographic area that can be relatively fixed or can change over time. A cell can be further divided into cell sectors. For example, the cell associated with base station 114a can be divided into three sectors. Thus, in one embodiment, base station 114a can include three transceivers, i.e., one for each sector of the cell. In an embodiment, base station 114a can use multiple-input multiple-output (MIMO) technology and can utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0021] Base stations 114a, 114b can communicate with one or more of WTRUs 102a, 102b, 102c, 102d via a wireless interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The wireless interface 116 can be established using any suitable radio access technology (RAT).

[0022] More specifically, as described above, the communication system 100 can be a plurality of access systems, and can use one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113, and the WTRUs 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) that can establish radio interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High Speed Downlink (DL) Packet Access (HSDPA) and / or High Speed UL Packet Access (HSUPA).

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

[0024] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access that can establish the radio interface 116 using New Radio (NR).

[0025] In this embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can implement both LTE radio access and NR radio access, for example, using the dual connection (DC) principle. Therefore, the radio interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to multiple types of base stations (e.g., eNBs and gNBs).

[0026] In other embodiments, base stations 114a and WTRUs 102a, 102b, 102c can 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, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Evolution Enhanced Data Rate (EDGE), GSM EDGE (GERAN), and similar.

[0027] The base station 114b in Figure 1A can be, for example, a wireless router, home node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as workplaces, homes, vehicles, campuses, industrial facilities, aerial walkways (e.g., used by drones), roadways, and similar locations. In one embodiment, the base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and WTRU 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.

[0028] RAN104 / 113 can communicate with CN106 / 115, which can be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more WTRU102a, 102b, 102c, and 102d. The data may have various Quality of Service (QoS) requirements, including different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and so on. CN106 / 115 can provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or implement high-level security features such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 can communicate directly or indirectly with other RANs using the same RAT as RAN104 / 113, or different RATs. For example, in addition to connecting to RAN104 / 113 which can utilize NR radio technology, CN106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0029] CN106 / 115 can also act as a gateway to WTRU102a, 102b, 102c, 102d for access to PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing basic telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs that can use the same RAT as RAN104 / 113, or a different RAT.

[0030] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 can include multimode functionality (for example, WTRUs 102a, 102b, 102c, and 102d can include multiple transceivers for communicating with various radio networks via various radio links). For example, the WTRU 102c shown in Figure 1A can be configured to communicate with a base station 114a that can use cellular-based radio technology and a base station 114b that can use IEEE 802 radio technology.

[0031] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among others, a processor 118, a transceiver 120, a transmit / receive element 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. The WTRU 102 may include any sub-combination of the aforementioned elements, but it will be understood that this is consistent with the embodiment.

[0032] 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 DCP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a rewritable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can perform signal coding, 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 may be coupled to the transceiver 120, and the transceiver 120 may be coupled to the transmit / receive element 122. Although Figure 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0034] Although the transmit / receive element 122 is shown 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 utilize MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) to transmit and receive radio signals via the radio interface 116.

[0035] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multimode functionality. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate with multiple RATs, such as NR and IEEE 802.11.

[0036] The processor 118 of the WTRU102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and can receive user input data from there. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can access information from any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132, and can store data therein. 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 identification module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access and / or store data from memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0038] The processor 118 can 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, information from the GPS chipset 136, the WTRU 102 can receive location information from base stations (e.g., base stations 114a, 114b) via the radio interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 can acquire location information by any suitable location determination method while maintaining consistency with the embodiments.

[0039] The processor 118 may be further coupled to other peripheral devices 138 which may include one or more software and / or hardware modules that provide further features, functionality, and / or wired or wireless connectivity. For example, peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photography and / or video), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. Peripheral devices 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0040] WTRU102 may include a full-duplex radio, in which case some or all of the transmission and reception of signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be simultaneous and / or occur at the same time. The full-duplex radio may include an interference management unit that reduces and / or substantially eliminates self-interference by signal processing via hardware (e.g., chokes) or a processor (e.g., a separate processor (not shown) or processor 118). In embodiments, WRTU102 may include a half-duplex radio for transmitting and receiving some or all of the signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)).

[0041] Figure 1C is a system diagram showing RAN104 and CN106 according to an embodiment. As described above, RAN104 can use E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via the radio interface 116. RAN104 can also communicate with CN106.

[0042] RAN104 may include eNodeB160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNodeB while maintaining consistency with the embodiment. Each of eNodeB160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the radio interface 116. In one embodiment, eNodeB160a, 160b, and 160c can implement MIMO technology. For example, eNodeB160a may use multiple antennas to transmit and / or receive radio signals from WTRU102a.

[0043] Each of the eNodeB160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, and similar functions. As shown in Figure 1C, the eNodeB160a, 160b, and 160c can communicate with each other via the X2 interface.

[0044] The CN106 shown in Figure 1C 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 aforementioned elements is shown as part of CN106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0045] The MME162 can connect to each of the eNodeB160a, 160b, and 160c in RAN104 via the S1 interface and act as a control node. For example, the MME162 can handle authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c, and similar tasks. The MME162 can provide control plane functionality for switching between RAN104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

[0046] The SGW164 can be connected to eNodeB160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions such as anchoring the user plane during handover between eNodeBs, triggering paging when DL data becomes available to WTRU102a, 102b, and 102c, managing and remembering the context of WTRU102a, 102b, and 102c, and similar functions.

[0047] The SGW164 can connect to the PGW166, which provides WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0048] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108, thereby facilitating communication between WTRU102a, 102b, and 102c and conventional land-line communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. In addition, CN106 can provide WTRU102a, 102b, and 102c with access to another network 112, which may include other wired and / or wireless communication networks owned and / or operated by other service providers.

[0049] In Figures 1A to 1D, the WTRU is described as a wireless terminal, but in some typical embodiments, such a terminal is intended to be able to use a wired communication interface with a communication network (for example, temporarily or permanently).

[0050] In a typical embodiment, the other network 112 can be a WLAN.

[0051] In Infrastructure Basic Service Set (BSS) mode, a WLAN may have an access point (AP) to the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or an interface to a distribution system (DS) or to 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 arrive through the AP and be delivered to the STA. Traffic originating from an STA to a destination outside the BSS may be sent to the AP and delivered to each destination. Traffic between STAs within the BSS may be sent, for example, through the AP, in which case the source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS is considered and / or can be called peer-to-peer traffic. Peer-to-peer traffic can be sent between source and destination STAs (for example, directly) using Direct Link Configuration (DLS). In some typical embodiments, the DLS can be 802.11e DLS or 802.11z Tunnel DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) can communicate directly with each other. The IBSS mode of communication may also be referred to herein as the “ad-hoc” mode of communication.

[0052] When using the 802.11ac infrastructure operating mode, or a similar operating mode, an AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a bandwidth of 20 MHz) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS and can also be used by STAs to establish a connection with the AP. In some typical embodiments, for example in an 802.11 system, Carrier Sensitive Multiple Access (CSMA / CA) with collision avoidance can be implemented. In the case of CSMA / CA, STAs (e.g., any STA), including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA may retreat. One STA (e.g., only one station) can transmit at any given time in a given BSS.

[0053] High-throughput (HT) STAs can use 40MHz wide channels for communication, which is achieved, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels.

[0054] Ultra-high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining adjacent 20MHz channels. 160MHz channels can be formed by combining eight adjacent 20MHz channels or two non-adjacent 80MHz channels, which can be referred to as an 80+80 configuration. In the 80+80 configuration, after channel encoding, the data can be passed through a segment parser that can split it into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams can be mapped to two 80MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the operation described above for the 80+80 configuration can be reversed, and the combined data can be sent to Media Access Control (MAC).

[0055] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af also supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah can support meter-type control / machine-type communications, such as MTC devices in macro coverage areas. An MTC device may have some functionality, including limited functionality such as support for some and / or limited bandwidths (e.g., support only for those bandwidths). An MTC device may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0056] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, the primary channel may be 1MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only supports) 1MHz mode, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. For example, if the primary channel is busy due to an STA (which only supports 1MHz operating mode) transmitting to the AP, the entire available frequency band may be considered busy, even if the majority of the frequency band remains idle and available.

[0057] In the United States, the available frequency band that can be used by 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah is from 6 MHz to 26 MHz, depending on national regulations.

[0058] Figure 1D is a system diagram showing RAN113 and CN115 according to an embodiment. As described above, RAN113 can communicate with WTRU102a, 102b, and 102c via radio interface 116 using NR radio technology. RAN113 can also communicate with CN115.

[0059] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with the embodiment. Each of the gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the radio interface 116. In one embodiment, the gNB180a, 180b, and 180c can implement MIMO technology. For example, the gNB180a and 180b can use beamforming to transmit and / or receive signals from the gNB180a, 180b, and 180c. Thus, for example, the gNB180a can use multiple antennas to transmit and / or receive radio signals from the WTRU102a. In the embodiment, the gNB180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB180a can transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In embodiments, gNB180a, 180b, and 180c can implement Coordinated Multi-Point (CoMP) transmission technology. For example, WTRU102a can receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0060] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable neurology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTI) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or following varying absolute times).

[0061] The gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without further access to other RANs (e.g., eNodeB160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of the gNB180a, 180b, and 180c as a mobility anchor point. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in the unlicensed band. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c while also communicating with other RANs such as eNodeB160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c, and one or more eNodeB160a, 160b, and 160c. In a non-standalone configuration, eNodeB160a, 160b, and 160c can act as mobility anchors to WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional reach and / or throughput to service WTRU102a, 102b, and 102c.

[0062] Each of the gNB180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interconnection between NR and E-UTRA, routing of user plane data to user plane functions (UPF) 184a and 184b, routing of control plane information to access and mobility management functions (AMF) 182a and 182b, and similar functions. As shown in Figure 1D, the gNB180a, 180b, and 180c can communicate with each other via the Xn interface.

[0063] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and possibly a Data Network (DN)185a, 185b. Although each of the aforementioned elements is shown as part of the CN115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0064] AMF182a and 182b can connect to one or more gNB180a, 180b, and 180c in RAN113 via the N2 interface and act as control nodes. For example, AMF182a and 182b can handle authenticating users of WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling various PDU sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and similar tasks. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of services used by WTRU102a, 102b, and 102c. For example, various network slices can be established for a variety of use cases, such as services utilizing ultra-high reliability low latency (URLLC) access, services utilizing enhanced high-capacity mobile broadband (eMBB) access, services for machine-type communication (MTC) access, and / or similar. The AMF182 can provide control plane functionality for switching between RAN113 and other RANs (not shown) using other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0065] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b, and can configure routing for traffic passing through UPF184a and 184b. SMF183a and 183b can perform other functions, such as managing and assigning IP addresses for WTRUs, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and similar. PDU session types can be IP-based, non-IP-based, Ethernet-based, and similar.

[0066] UPF184a, 184b may be connected to one or more of gNB180a, 180b, 180c in RAN113 via the N3 interface, which can provide WTRU102a, 102b, 102c with access to a packet-switched network such as the Internet 110, facilitating communication between WTRU102a, 102b, 102c and IP-enabled devices. UPF184a, 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and similar functions.

[0067] CN115 can facilitate communication with other networks. For example, CN115 can include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN115 and PSTN108. Furthermore, CN115 can provide WTRU102a,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 one embodiment, WTRU102a,102b,102c may be connected to local data networks (DN) 185a,185b via UPF184a,184b through an N3 interface to UPF184a,184b and via an N6 interface between UPF184a,184b and DN185a,185b.

[0068] In the diagrams of Figures 1A to 1D and the corresponding descriptions of Figures 1A to 1D, one or more, or all, of the functions described herein with respect to one or more of the WTRU102a to d, base stations 114a to b, eNodeB160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions.

[0069] Emulation devices may be designed to perform one or more tests of other devices in a laboratory and / or operator network environment. For example, one or more emulation devices may perform one or more, or all, functions, but may be fully or partially performed and / or deployed as part of a wired and / or wireless network to test other devices in a communication network. One or more emulation devices may perform one or more, or all, functions, but may be temporarily performed / deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device to perform tests and / or may perform tests using wireless communication over the air.

[0070] One or more emulation devices can perform one or more functions, including all of them, but are not performed / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory and / or in a test scenario in a wired and / or wireless communication network that is not deployed (e.g., for testing purposes) to perform testing of one or more components. One or more emulation devices can be a test apparatus. Wireless communication via direct RF coupling and / or RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0071] New Radio (NR) can be enabled to work with current and future mobile wireless communication systems. Examples of NR use cases include, for example, eMBB, ultra-high reliability low latency communication (URLLC), and massive machine-type communication (mMTC). NR can support transmission in high frequency bands, such as centimeter-wave (cm) and / or millimeter-wave (mm) frequencies. Operation in the cm and / or mm frequency bands may present propagation-related challenges, for example, considering high path loss and shadowing.

[0072] High-reliability services can be supported by very low block error rates, for example, as low as 0.001%. Low error rates can be achieved by using high reliability for physical layer control information (e.g., Hybrid Automatic Retransmission Request Acknowledgment (HARQ-ACK), uplink granting, and downlink allocation). For example, a 0.1% probability of misinterpreting a NACK as an ACK (for example, for HARQ-ACK) may be adequate for some (e.g., typical) mobile broadband services, but may be too high for ultra-reliable services (e.g., because a misinterpretation event of a Negative Response (NACK) to an Acknowledgment (ACK) could result in transport block loss).

[0073] A WTRU can be configured to perform multiple simultaneous transmissions. NR can support WTRU configurations that include one or more cells for a given MAC entity and / or multiple MAC entities. A single-cell configuration can provide single-cell operation. Multiple-cell configurations can provide carrier aggregation (CA), such as NR CA operation. Configurations of multiple MAC entities can include dual-connection (DC) for NR (NR DC). Configurations of multiple MAC entities can provide a combination of LTE and NR (e.g., Advanced UMTS Terrestrial Radio Access Network (E-UTRAN) New Radio Dual-Connection (EN-DC)). NR can provide WTRU configurations that include a cell consisting of one downlink carrier, one uplink carrier, and an auxiliary uplink carrier (SUL). NR can support a cell consisting of one or more bandwidth portions (BWPs). BWPs can be characterized by at least one of frequency location (e.g., center frequency and / or frequency bandwidth) or neurology.

[0074] With respect to EN-DC, NR CA, and NR DC in the authorized bandwidth, various combinations of carriers (e.g., different combinations) can lead to various timing relationships (e.g., different timing relationships) between transmissions associated with the WTRU (or between transmissions that may overlap at least partially in time) with respect to one or more of the neurology, transmit start time, or transmit duration. For example, each of the configured component carriers (downlink (DL) and / or uplink (UL)) and / or the bandwidth portion (BWP) (DL and / or UL) for the WTRU may have the same or different neurology, and overlapping transmissions between different component carriers / BWPs may have the same or different start times and the same or different physical uplink shared channel (PUSCH) / physical uplink control channel (PUCCH) transmit durations.

[0075] For example, in the case of asynchronous transmissions, and / or partially and / or completely overlapping between different uplink transmissions associated with a WTRU, timing and / or scheduling aspects may be provided. For example, different transmissions may operate on different HARQ timelines based on, for example, dynamic scheduling information. For example, such scheduling information may include a delay component related to dynamically variable scheduling. A delay component related to dynamically variable scheduling may be provided by downlink control information (DCI). The scheduling delay component may include one or more of K1, K2, N1, or N2. K1 may be the delay between the reception of downlink (DL) data (PDSCH) and its corresponding ACK transmission on the uplink (UL). K2 may be the delay between the reception of UL permission in DL and the transmission of UL data (e.g., PUSCH transmission). N1 may be, for example, the number of OFDM symbols used by the WTRU for processing from the end of NR-PDSCH reception to the earliest possible start of the corresponding ACK / NACK transmission, as seen from the WTRU. N2 can be, for example, the number of OFDM symbols used by the WTRU for processing from the end of the NR-PDCCH, including the UL permission reception, as seen from the WTRU, until the earliest possible start of the corresponding NR-PUSCH transmission.

[0076] The scheduler can adjust the error probability of control information, for example, by selecting transmit power parameters (e.g., those associated with uplink transmissions) and / or aggregation levels (e.g., those associated with downlink transmissions). Achieving a very low error rate may involve problems.

[0077] For example, very low error rates may not be achievable by parameter tuning using transmission techniques if, for instance, burst-like interference and / or other channel interference (e.g., extreme shadowing at mm wave frequencies) are present.

[0078] When such techniques are applied to one or more types of transmission, they can consume significantly more resources (time, frequency, and / or power) than when operating at a typical error rate. For example, when operating at a very low error rate, spectral efficiency and user throughput may be severely reduced. Differentiated processing between ultra-reliable transmissions and other transmissions (e.g., by resource isolation) may be less efficient if, for example, the ultra-reliable traffic is bursty.

[0079] It is possible to achieve extremely low error rates (e.g., ultra-reliable services). It is possible to achieve efficient operation with ultra-reliable and other (e.g., non-ultra-reliable) mobile broadband data traffic (e.g., in systems and / or WTRUs).

[0080] Uplink control information (UCI) may include, for example, HARQ feedback information (e.g., HARQ-ACK), scheduling requests (SR), and / or channel status information (CSI). UCI can be transmitted over an uplink control channel (e.g., a physical uplink control channel (PUCCH)) and / or over an uplink data channel (e.g., a physical uplink shared channel (PUSCH)). UCI may be transmitted with or without multiplexing uplink data. HARQ feedback information (e.g., HARQ-ACK) may relate to transport blocks, code blocks, and / or groups of code blocks.

[0081] Downlink control information (DCI) can refer to physical control signaling that may be received from the network (e.g., uplink grant, downlink allocation, power control commands, slot format indicators, HARQ information, etc.). DCI can be transmitted, for example, via a downlink control channel (e.g., PDCCH) (e.g., within a common or WTRU-specific search space, or via a group-common control channel (e.g., on the PDCCH)). The PDCCH can be mapped to a resource in a control resource set (CORESET). A WTRU can attempt to decode the PDCCH, for example, from one or more search spaces within the CORESET. A WTRU can consist of, for example, at least one CORESET.

[0082] DCI diversity can be provided. For example, the transmit reliability of DCI can be enhanced by transmitting multiple DCI instances over resources separated in time, frequency, and / or spatial domains. Multiple instances can provide diversity gains against short-term fading, long-term fading, and / or interference.

[0083] A DCI (e.g., each DCI instance) can be transmitted via a downlink physical control channel (e.g., a PDCCH, a group-common PDCCH, a PHICH, and so on). An instance can be transmitted via a PDSCH (e.g., when DCI on a PDSCH is supported). A PDCCH (e.g., each PDCCH) can be received based on a CORESET that may be configured by a higher layer. The configuration may include one or more parameters. For example, the configuration may include a component carrier or serving cell, one or more bandwidth portions (BWPs), a subset of resource blocks within a BWP (e.g., each BWP), a set of time symbols within a slot or minislot, a subcarrier interval, a subset of slots within a subframe, and / or one or more reference signals (e.g., CSI-RS). An independent configuration of one or more parameters can provide diversity in time, frequency, and / or space. In the example, frequency diversity may provide spatial and / or time diversity (for example, by configuring different component carriers or BWPs between CORESETs) with or without providing spatial and / or time diversity (for example, by configuring different sets of time symbols and / or different reference signals).

[0084] DCI diversity can be configurable. For example, DCI diversity can be activated or deactivated. Activation or deactivation of DCI diversity can be based, for example, on MAC layer signaling or physical layer signaling. For example, a WTRU can receive an activation command based on a first CORESET and begin monitoring a second DCI instance on a second CORESET. A WTRU can also receive a deactivation command for monitoring a DCI instance on a particular CORESET.

[0085] DCI diversity can be applied. The content of a DCI instance (e.g., each DCI instance) can be configured according to one or more of the following: (i) the same content sent through multiple DCI instances (e.g., repetition), (ii) the same content sent through multiple DCI instances (e.g., block encoding), or (iii) the nature of the content.

[0086] In the example, each of multiple DCI instances can contain and encode the same information bits for at least one type or format of DCI (e.g., HARQ-ACK for PUSCH, PDSCH assignment, PUSCH permission). The DCI can be decrypted from the reception of an instance (e.g., a single instance) (e.g., fully decryptable).

[0087] In the example, the DCI can be encoded, for example, by segmenting the DCI into N blocks and encoding the DCI into D blocks. In the example, at least N decodings (e.g., at the receiver) of D DCI instances may be sufficient to reconstruct the entire DCI. In the example, the encoding can consist of parity codes.

[0088] In the example, the DCI instance may include one or more of the following: information associated with at least one DL data transmission via PDSCH, or information associated with at least one UL data transmission via PUSCH.

[0089] In the example, the WTRU can be configured to monitor PDCCHs via multiple CORESETs (e.g., two CORESETs). The WTRU can monitor PDCCHs on different carriers or bandwidth portions. The WTRU can receive, for example, multiple DCI instances (e.g., up to two DCI instances). In the example, a DCI instance can contain the same information received by the WTRU via PDCCHs on multiple carriers (e.g., each carrier, in the case of multiple DCIs, may be received on one carrier). The information on a DCI (e.g., each DCI) can contain PDSCH (or PUSCH) assignments / authorizations for multiple carriers (e.g., both carriers). The WTRU can receive PDSCHs or transmit PUSCHs on multiple carriers (e.g., both carriers) even if it fails to decode a DCI instance (e.g., one of them). As illustrated in the example in Figure 2, for example, DCI and data can be protected independently by diversity (e.g., protected), so very low BLER can be achieved with low latency when, for example, multiple PDSCH transmissions (e.g., both PDSCH transmissions) or PUSCH transmissions can be encoded into the same transport block. As shown in Figure 2, the DCI on downlink component carrier 1 (DL CC1) 202 and the DCI on downlink component carrier 2 (DL CC2) 204 can have the same content. For example, each DCI can contain information associated with PDSCH 206 and PDSCH 208.

[0090] A DCI index can be provided. In the example, a DCI instance (e.g., each DCI instance) may include a field (e.g., a DCI index) that can identify the DCI content. A WTRU can discard DCI instances that may contain the same information. Identical DCIs can be discarded to reduce processing load. In the example, a WTRU may receive a first DCI instance with a first value for the DCI index. A WTRU can receive subsequent DCI instances that may contain the same value for the DCI index (e.g., DCI diversity within a set of CORESETs that can be configured over a time period). A WTRU can discard subsequent DCI instances (e.g., upon receipt). A WTRU can use the DCI index to distinguish, for example, diversity DCIs from DCIs that may contain new information.

[0091] UCI diversity can be provided. The transmit reliability of a UCI can be enhanced, for example, by transmitting multiple instances over resources that can be separated in one or more of the following domains: time, frequency, or spatial domain. Multiple UCI instances can provide diversity gains against, for example, short-term fading, long-term fading, and / or interference. Each UCI instance (e.g., each UCI instance) can transmit over a physical uplink control channel (PUCCH) or a physical uplink shared channel (PUSCH). In the example, UCI diversity is applicable to several types of UCI (e.g., HARQ-ACK).

[0092] In the example, a UCI instance can be transmitted over multiple carriers and / or bandwidth portions, and the WTRU can be configured to operate on it. As shown in Figure 3, the same HARQ-ACK information that may be related to a downlink assignment (e.g., received in the previous slot 302) can be transmitted over multiple PUCCH instances (e.g., two PUCCH instances 306 and 308). The two PUCCH instances may include a first UCI instance 306 that can be transmitted over UL component carrier 1 (CC1) 310 and a second UCI instance 308 that can be transmitted over UL component carrier 2 (CC2) 312. The UCI can be transmitted over slot 2 304. Each of the first UCI instance 306 and the second UCI instance 308 may contain similar information (e.g., the same HARQ ACK-NACK information).

[0093] Figure 3 shows an example of implementing DCI diversity and UCI diversity. In the example, a UCI instance (e.g., each UCI instance) can include sending OFDM symbols (e.g., a single OFDM symbol) to adjacent symbols (e.g., using a short PUCCH format). Other examples in the time domain include sending on the same OFDM symbol or sending on different slots. The resources that may be occupied by a UCI instance (e.g., each UCI instance) (e.g., RBs, time symbols, slots, etc.) can be configured independently.

[0094] In the example, a UCI instance can transmit through multiple beams. For example, multiple beams may be transmitted using different precoders. A WTRU can be configured for beam decisions associated with a UCI instance (e.g., each UCI instance). A WTRU can be configured with information including one or more of the following: beam index, beam process identification, SRS indicator, or CSI-RS indicator (e.g., if a beam correspondence exists). The information used by the WTRU for beam decisions (e.g., for PUCCH) can be configured by a higher layer for a UCI instance (e.g., each UCI instance), or can be shown in a DCI that may include an ACK / NACK resource indicator (ARI). The information used by the WTRU for beam decisions (e.g., for PUSCH) can be shown via a DCI that may include authorization associated with the beam.

[0095] Information used by the WTRU for beam determination can be derived (e.g., implicitly derived) from a PDCCH that may include allocations. For example, the beam associated with the transmission of a PUCCH instance may be derived from a reference signal (e.g., a Channel State Information Reference Signal (CSI-RS)), or from a control resource set, or from a beam indicator that can be associated with a PDCCH transmission that may include allocations. This technique can be used, for example, when PDCCH diversity (or DCI diversity) is available in addition to UCI diversity. The WTRU can transmit a PUCCH instance (e.g., one PUCCH instance) for each received PDCCH instance (e.g., each received PDCCH instance). The PDCCH instance may include allocations of when and / or how UCI may be transmitted via PUCCH.

[0096] A supplementary uplink (SUL) can be provided. For example, a WTRU can be configured with a SUL carrier to at least one serving cell. The WTRU can be configured to transmit UCIs, for example, scheduling requests (SRs), channel status information (CSIs), or HARQ ACKs / NACKs. UCIs can be transmitted via the regular UL carriers and SUL carriers associated with the serving cell.

[0097] UCI diversity can be applied. The content of a UCI instance (e.g., each UCI instance) may be configured according to one or more of the following, for example: (i) whether the same content is sent through each of multiple UCI instances (e.g., iteration), (ii) whether the same content is sent through UCI instances (e.g., block encoding), or (iii) the nature of the content.

[0098] In the example, each UCI instance (e.g., each UCI instance) can contain and encode the same information bits for at least one type of UCI (e.g., HARQ-ACK). A UCI may be decodeable from the reception of a single instance. In the example, a UCI may be encoded, for example, by segmenting the UCI into N blocks and encoding the segmented N blocks into D blocks. In the example, decoding at least N blocks of D UCI instances at the receiver may be sufficient to reconstruct the entire UCI. In the example, the encoding may include a parity code.

[0099] In the example (for instance, when DCI diversity cannot be applied), the UCI may include a set of HARQ-ACK bits. The association between a particular set of HARQ-ACK bits and the result of receiving a transport block may be determined, for example, based on the downlink allocation index.

[0100] In the example (for example, when DCI diversity can be applied), a set of HARQ-ACK bits may be generated and transmitted for each DCI instance (for example, based on the same content) that can be configured to be received in diversity. This can be done regardless of whether the DCI instance can be successfully decoded. A WTRU may be configured to receive multiple DCI instances (for example, two DCI instances) in diversity, but if it receives fewer DCI instances than configured (for example, two configured DCI instances), it can report a NACK for the transport block corresponding to the DCI instances that were not received. This report may be made when the WTRU receives at least one DCI instance. The network can determine the lost allocation from the DCI instances (for example, each DCI instance). Determining the lost allocation can be useful for link adaptation of the PDCCH.

[0101] In the example, DCI diversity can be applied. A WTRU may, for example, report a set of HARQ-ACK bits for a set of DCI instances that can be configured to be received by diversity when the WTRU receives at least one DCI instance. The WTRU may also report an indication of a subset of DCI instances within the set of DCI instances that can be successfully decrypted by diversity.

[0102] A WTRU can receive multiple DCIs that represent DL data for the same HARQ process and transport block. DCIs can be encoded using different redundancy versions. A WTRU can report one HARQ-ACK bit per transport block (regardless of the number of received instances of PDSCH that can contain data for the transport block). A WTRU can transmit the HARQ-ACK bit for each transport block and PDSCH instances that can contain data for the transport block (e.g., having the same value).

[0103] Power control using UCI diversity can be provided. The transmit power associated with a transmit (e.g., PUCCH transmit or PUSCH transmit) can be set independently, for example, when UCI diversity is applied. For example, separate configurations of one or more reference signals can be used for path loss estimation, and other parameters can be used to determine the transmit power.

[0104] Power control may be provided using UCI diversity to determine transmit power control (TPC). The WTRU can determine the applicable TPC commands for transmits where UCI diversity is applicable.

[0105] In an exemplary TPC decision, a WTRU may apply similar TPC adjustments to each of multiple UCI instance transmissions. TPC adjustments may be received from, for example, a DCI that can be associated with a UCI transmission. For example, a DCI may include DL allocations or CSI requests.

[0106] In an exemplary TPC determination, a WTRU may apply a separate TPC adjustment to each of multiple UCI instance transmissions. The TPC adjustment (e.g., each TPC adjustment) may be received via a DCI that can be associated with a UCI transmission, for example. In the example, the associated DCI may contain two TPC adjustment values, for example, if the UCI diversity can be composed using two transmissions.

[0107] In an exemplary TPC decision, the WTRU may apply a separate TPC adjustment to each UCI instance transmission. The TPC adjustment may be received for each UCI instance, for example, through a specific DCI instance that may be associated with the UCI instance.

[0108] For example, power control can be provided with power control modes such as carrier aggregation (CA) and / or dual connection (DC). For example, a WTRU can apply priority levels to transmits that may contain UCIs, for example, when UCI diversity is activated. A WTRU can apply priority levels, for example, when configured with a power control mode (PCM). A WTRU can be configured to group one or more types of transmits. A WTRU can be configured to allocate at least a certain amount (e.g., a portion) of the total power available in the WTRU to a group of transmits using the minimum guaranteed power. A WTRU can determine that transmits containing UCIs are part of the same group of transmits. A WTRU can implement such grouping, for example, when UCIs are associated with a transmit profile. For example, such a transmit profile may correspond to an ultra-high reliability low-latency communication (URLLC) type transmit. A WTRU can assign a higher priority to such a group of transmits than to other data transmits (e.g., data transmits associated with a transmit profile corresponding to a non-URLLC type transmit). For example, in a WTRU configured with a CA, a transmission containing at least some UCIs generated when applying UCI diversity may have the highest priority over other transmissions to a given MAC instance. For example, in a WTRU configured with a DC and / or multiple transmission groups, a group (or cell group) of transmissions having at least one transmission containing at least some UCIs (e.g., generated when applying UCI diversity) may have the highest priority over other groups.

[0109] Resource allocation can incorporate UCI diversity using PUCCH. The resources and format of a PUCCH transmission can be determined, for example, by one or more exemplary procedures (e.g., when a UCI instance is transmitted via PUCCH). In the example, a WTRU may be composed of one or more combinations of PUCCH resources. Each PUCCH resource (e.g., each PUCCH resource) can correspond to a resource through which a UCI instance may transmit. In the example (e.g., with two UCI instances), the combination may be defined as PUCCH resource index #24 on the first CC or bandwidth portion and PUCCH resource index #13 on the second CC or bandwidth portion. The combination can be called a PUCCH diversity resource or a PUCCH diversity superresource. A WTRU can be composed of multiple PUCCH diversity resources (e.g., by a higher layer). PUCCH diversity resources can be indicated by fields in the relevant DCI (e.g., the ARI field). A WTRU can be composed using a pool (e.g., by a higher layer). The pool can include regular PUCCH resources and PUCCH diversity resources that allow the network to control (for example, dynamically) the use of UCI diversity.

[0110] In the example, a WTRU can be configured with DCI diversity in addition to UCI diversity. A WTRU can transmit a UCI instance with resources that may be indicated by the associated DCI instance. A DCI instance (e.g., each DCI instance) may have an ARI that can indicate a PUCCH resource. A WTRU can transmit a UCI instance, for example, if it has received a corresponding DCI instance.

[0111] DTX feedback can be provided. For example, a WTRU can send HARQ-ACK information on a specific PUCCH resource. The HARQ-ACK can indicate (e.g., explicitly) that no DL transmission or DL ​​allocation has been received from a particular CORESET on a given slot or minislot (e.g., in the case of a discontinuous transmission (DTX)). The timing of the PUCCH resource can be obtained, for example, from the timing of the slot or minislot where no DL allocation was received.

[0112] Randomization of PUCCH interference can be provided. For example, PUCCH transmissions from two or more WTRUs to two or more transmit / receive points (TRPs) may collide. For example, interference randomization can be used to reduce the impact of strongly coherent PUCCH transmissions on sacrificial PUCCH transmissions. For example, interference randomization can be used by a pair of WTRUs not using a colliding PUCCH resource.

[0113] Interference randomization can be used to increase transmit diversity. Interference randomization may include, for example, one or more of the following hopping resources: hopping of transmit beams or beam pairs, hopping of PUCCH symbols within or across slots, or hopping of replication patterns.

[0114] In the example of hopping resources, hopping can be performed within a BWP or across multiple BWPs. A PUCCH transmission (e.g., each PUCCH transmission) can cycle across a pattern of frequency resources, for example. In the example, hopping can be performed within a PUCCH transmission.

[0115] In the example of hopping between transmit beams or beam pairs, a PUCCH transmit can circulate within a set of beams. In the example, the circulating within beams may be performed, for example, using a beam for each set of PUCCH symbols within a PUCCH transmit. In the example of hopping between PUCCH symbols within or across slots, for each of multiple PUCCH transmits, a short PUCCH may occupy a different symbol in the slot.

[0116] In the example of replication pattern hopping, a PUCCH send (e.g., each PUCCH send) can use multiple replicas. Each replica can use different resources. Subsequent PUCCH sends (e.g., each subsequent PUCCH send) can use a different set of resources (e.g., a separate set). Different sets of resources can be used to enable multiple replicas.

[0117] The use of interference randomization and / or hopping patterns can be indicated in the WTRU. For example, such use of interference randomization and / or hopping patterns can be indicated dynamically in the WTRU. The hopping pattern may be determined, for example, based on the characteristics of the PUCCH transmission. In the example, the hopping PUCCH configuration may depend on the frame timing, subframe timing, or slot timing of the PUCCH. In the example, the PUCCH configuration may depend on the PUCCH configuration used in the previous PUCCH transmission. In the example, the hopping PUCCH configuration may depend on WTRU parameters (e.g., WTRU ID) or TRP parameters (e.g., TRP ID).

[0118] The configuration of a PUCCH resource can be provided. The WTRU can be configured to use one or more PUCCH formats or format types (e.g., short PUCCH or long PUCCH). The WTRU may consist of parameters associated with one or more PUCCH formats. The configuration of the PUCCH resource can be provided, for example, semi-statically.

[0119] The configuration of a PUCCH resource includes, for example, (i) the PUCCH format (e.g., short PUCCH format or long PUCCH format), (ii) the duration of the PUCCH in the symbol (e.g., the duration of a short PUCCH with 1 or 2 symbols, and the duration of a long PUCCH), (iii) the waveform used for PUCCH transmission (e.g., cyclic prefix-based orthogonal frequency division multiplexing (CP-OFDM), or discrete Fourier transform spread orthogonal frequency division multiplexing (DFT-s-OFDM)), (iv) the neurology used for PUCCH (e.g., subcarrier spacing, CP type, etc.), (v) the time position (e.g., the symbol position in the slot where the PUCCH may be transmitted), (vi) the frequency position (e.g., subcarrier, PRB, bandwidth portion (BWP)), and (vii) the frequency (xiii) Interlace index (e.g., used to enable FDM of multiple PUCCHs on the same PRB or BWP, in which case a PUCCH transmission can be assigned to one or more interlaces within the PRB or BWP), (viii) Hopping pattern (e.g., for hopping within or across PUCCH transmissions), (ix) Beam or beam pair, (x) Replication pattern (e.g., for PUCCH transmissions that can be replicated across multiple resources), (xi) Orthogonal Cover Code (OCC) (e.g., which may include whether the OCC is applied over time or to subcarrier elements), (xii) Cyclic shift, or (xiii) Transmit diversity scheme, one or more of the above may be included.

[0120] A frequency position can include, for example, frequency assignments on which a PUCCH can be transmitted. A frequency position can be provided, for example, as an offset value. An offset can be applied to, for example, the frequency position of a PDCCH that can constitute a PUCCH, or a PDCCH that assigns a PDSCH, or a PDSCH. An offset can be applied to the frequency position of a simultaneous PUCCH. A frequency position can include, for example, a set of subcarriers, PRBs, and / or BWPs. A set can be used to indicate (for example, dynamically indicate) the frequency position for a PUCCH transmission instance (for example, each PUCCH transmission instance). A set can be used, for example, to enable frequency diversity through iteration. A set can be used, for example, to enable frequency hopping.

[0121] The configuration (including, for example, the replication pattern) can include a set of resources that a PUCCH transmission may replicate. Different replication patterns can be selected (for example, dynamically selected).

[0122] A semi-static configuration may include one or more tables. A table may include a set of sign points and a set of PUCCH configurations that can be associated with each sign point in the set of sign points. In the example, the first table may include configurations for short PUCCH transmissions, and the second table may include configurations for long PUCCH transmissions. In the example, the tables are applicable to multiple PUCCH durations and PUCCH formats.

[0123] Dynamic indication of PUCCH configurations can be provided. For example, an indication (e.g., a dynamic indication) showing a combination of PUCCH configurations for transmitting a UCI, such as HARQ A / N or CSI, may be provided (e.g., to the WTRU). The dynamic indication may include, for example, a table index and a code point index used within the table. In the example, a dynamic indication may be provided (e.g., implicitly). For example, a dynamic indication may be provided depending on the transmission (e.g., depending on the parameters of a PDCCH transmission or a PDSCH transmission). A hybrid procedure may be used in the example. The WTRU may determine the PUCCH configuration based on, for example, a combination of explicit indexes and implicit relationships. In the example, the WTRU may dynamically determine the PUCCH configuration. In the example, the WTRU may determine a first set of configurations or a PUCCH configuration table, and also determine a second set of configurations or code points within the table. For example, the PUCCH configuration table can be determined implicitly, and the second set of configurations or the sign point can be determined explicitly.

[0124] Implicit indications may include one or more of the following: (i) slot size, (ii) UL / DL configuration of the slot, (iii) service type, (iv) UCI ​​multiplexing, (v) feedback timing, (vi) feedback type, or (vii) collision of different feedback types. In the example of slot size, a mini-slot may indicate the use of a short PUCCH, or a regular slot may indicate the use of a long PUCCH. In the example of UL / DL configuration of the slot, a WTRU may determine the PUCCH type (e.g., short or long) or long PUCCH duration based, for example, on the number of symbols assigned to the UL transmission. In the example of service type, URLLC may include a PUCCH format for HARQ that enables higher reliability. In the example, a URLLC transmission may request PUCCH diversity. In the example of UCI multiplexing, a HARQ transmission coupled to multiple TBs (e.g., due to multiple carriers or slot aggregation) may have a PUCCH format for a higher payload. In the example of feedback timing, feedback timing using offsets below a threshold can use the first PUCCH table, while feedback timing using offsets above a threshold can use the second PUCCH table. In the example, a short PUCCH may be used for self-contained slots where the feedback may be provided in the same slot as the DL data. In the example of feedback types, HARQ feedback can use the first PUCCH configuration, while CSI can use the second PUCCH configuration. In the example, transport block (TB)-based HARQ feedback can use the first PUCCH configuration (e.g., short PUCCH), and code block group (CBG)-based HARQ feedback can use the second PUCCH configuration. In the example of collisions between different feedback types (e.g., associated with different service types), the PUCCH configuration for the service type with the higher priority can be used.For example, when eMBB HARQ feedback may conflict with URLLC HARQ feedback, feedback multiplexing can be used for a PUCCH configuration for a URLLC service.

[0125] A feedback selection based on the PUCCH configuration can be provided. In an example, a WTRU can determine the type of feedback based on the PUCCH configuration used for the feedback. A WTRU assigned to a short PUCCH resource can determine, for example, that TB-based HARQ feedback may require PDSCH transmission. A WTRU assigned to a long PUCCH resource can determine, for example, that CBG-based HARQ feedback may require. In an example, a WTRU can determine the type of CSI feedback based on the PUCCH configuration.

[0126] PUCCH transmissions can be multiplexed. For example, a WTRU can be configured to multiplex multiple PUCCH transmissions. Multiplexing can be achieved, for example, by assigning multiple PUCCH transmissions on the same resource. A WTRU can be assigned different frequency interlaces, hopping patterns, and / or quadrature cover codes (OCCs) for each of the multiple PUCCH transmissions.

[0127] A WTRU can assign resources to multiple PUCCH transmissions. Resources can be, for example, conflicting resources. In the example, a WTRU can multiplex multiple UCIs onto the same PUCCH resource. In the example, a WTRU can have a priority ranking associated with UCIs. A WTRU can exclude UCIs with lower priority or feedback. In the example, a WTRU can have a priority ranking associated with UCIs and can use a PUCCH resource for the highest priority UCI, and use a different set of PUCCH resources (e.g., an alternative set of PUCCH resources) for a different UCI transmission. In the example, a WTRU can use alternative PUCCH resources for multiple UCI transmissions. In the example, each of multiple UCIs can be assigned to a different alternative resource. The alternative resources can enable multiplexing (e.g., efficient multiplexing). In the example, the PUCCH configuration for a UCI may not use interlacing. In the example, the alternative configuration can use an interlacing pattern that enables multiplexing. In the example, the PUCCH configuration for a UCI may include a BWP offset (e.g., in case of a collision with another UCI transmission). In the example, a short PUCCH configuration timing (e.g., symbol position) may depend on whether the UCI transmission can recognize the collision. In the example, the PUCCH hopping configuration may depend on whether a collision occurs.

[0128] It can provide differentiated processing. It can provide the determination of profiles applicable to transmission. A WTRU can process and transmit a UCI according to a transmission profile that can be associated with the UCI (e.g., a determined transmission profile). The transmission profile may be determined such that the amount and prioritization of resources can satisfy reliability objectives for the UCI. Such determination of the transmission profile enables efficient use of resources.

[0129] In this example, a transmit profile can be associated with uplink or sidelink data. For instance, a transmit profile associated with uplink or sidelink data can be used to enable prioritization between the uplink or sidelink data and UCIs with different profiles.

[0130] A transmit profile applicable to DCI, UCI, or data can be determined. For example, the transmit profile associated with UCI may be equivalent to or determined from one or more of the following: (i) a transmit profile for the associated downlink data transmission (e.g., for HARQ-ACK or CSI), (ii) a transmit profile for the associated uplink data transmission (e.g., for SR), or (iii) the bandwidth portion on which UCI is transmitted.

[0131] A transmit profile associated with UCI or uplink data may include, for example, the following: (i) a logical channel or logical channel group from which data can be transmitted based on the upper layer configuration (e.g., a transmit profile may be configured for each logical channel or logical channel group, or a WTRU may determine a transmit profile based on the configuration of a logical channel (LCH) to match one or more physical layer characteristics for a given transmit, such as transmit duration or similar); (ii) a logical channel or logical channel group of data that triggered the SR; (iii) a field value in the DCI that can be associated with the transmission of UCI or uplink data (e.g., an explicit indication of the transmit profile, or from an existing field (e.g., HARQ process index), or implicitly from a field that can be used for logical channel prioritization (e.g., for uplink permission), or a Radio Network Temporary Identifier (RNTI) value that can be used to mask cyclic redundancy check (CRC); or (iv) a transmit profile If a file can be configured for a CORESET (e.g., each CORESET) or for a PDCCH configuration (e.g., each PDCCH configuration) (e.g., by a higher layer), then the following may be configured for a PDCCH characteristic that can be associated with the transmission of UCI or uplink data (e.g., CORESET, monitoring period, determination of whether PDCCH is monitored at the start of a slot, search space or aggregation level that can be used for PDCCH decoding, or bandwidth portion), (v) signaling of a higher layer (e.g., for CSI), and / or fields in DCI that can indicate a set of parameters configured by a higher layer (e.g., CSI report settings that can be indicated by a non-periodic CSI field), (vi) characteristics of or associated with PDSCH transmissions, e.g., duration, bandwidth portion, neurology characteristics (e.g., subcarrier interval, symbol duration, etc.), Transmit Configuration Indication (TCI) state (e.g., for HARQ-ACK), control information associated with PDSCH transmissions (e.g., in DCI),(iv) The transmission profile may be determined based on one or more of the following: (vii) the characteristics of or associated with the PUCCH resource configured for transmitting the SR (such as its characteristics such as subcarrier interval, duration of the PUCCH resource, logical channels associated with the SR configuration, or priority, and / or the transmission profile explicitly configured as part of the SR configuration), (viii) the characteristics of or associated with the permit or PUSCH transmission (e.g., with respect to uplink data), such as the characteristics used to determine logical channel limits for logical channel prioritization (such as the duration of the PUSCH transmission, neurology characteristics (e.g., subcarrier interval, symbol duration), or carrier characteristics), or (ix) the bandwidth portion on which the relevant PDSCH transmission or PUSCH transmission is transmitted. With respect to (iv), the transmission profile may have priority based on the order of priority which may be configured. For example, the transmission profile may have priority based on the order of priority which may be configured if the PDCCH candidate is part of a search space associated with multiple transmission profiles. Regarding (i), the transmit profile associated with the UCI can be determined based on attributes (e.g., QoS metrics) associated with the logical channel or logical channel group from which data can be transmitted. Regarding (v), a BLER target value can be configured for the CSI reporting settings. The BLER target value can implicitly indicate the transmit profile. For example, a low BLER target value can indicate a high-priority transmit profile. In the example, the CQI reporting table can be configured for the CSI reporting settings.

[0132] A transmission profile for a DCI or downlink data can be determined based on one or more of the following characteristics of an assignment or PDSCH transmission (e.g., for downlink data), or characteristics associated therewith, for example: (i) characteristics of a PDCCH from which a DCI can be decoded or an assignment for downlink data can be decoded (e.g., search space, explicit configuration, etc.), as disclosed herein for UCI or uplink data; (ii) a Modulation Coding Scheme (MCS) table indicated for control information associated with a PDSCH transmission (e.g., in the DCI), such indications may be composed by a higher layer or may be included in a field of the DCI; (iii) a field value in the DCI that can be associated with the transmission of downlink data, or an RNTI value that can be used to mask the CRC; or (iv) characteristics of the duration of the PDSCH transmission and / or neurology (e.g., subcarrier interval, symbol duration, etc.).

[0133] In the example, a transmit profile can be defined for a physical channel (e.g., PDCCH, PUCCH, PDSCH, or PUSCH). The transmit profile can be determined, for example, based on the type of data or control information that can be transmitted by the physical channel. The transmit profile can be set, for example, based on the highest priority level in the profile when a physical channel transmit contains control information and / or data from a different profile (e.g., UCI multiplexed on PUSCH).

[0134] The determination of a profile can indicate timing characteristics. In the example, a transmit profile can be associated with timing characteristics. Such timing characteristics can correspond to at least one of the following: (1) a delay component related to scheduling, e.g., such a component may correspond to either N1 or N2; (2) WTRU processing time, e.g., such processing time may correspond to either N1 or N2; (3) the transmit start symbol; or (4) the transmit duration. N1 and / or N2 can represent the number of OFDM symbols as described herein. In the example, a transmit profile can correspond to a transmit for which one or more such timing characteristics, depending on a value, may be provided. A particular value may represent one aspect of the WTRU configuration. A transmit profile can be associated with at least one priority level or at least one parameter that determines channel access characteristics for operating in unlicensed bandwidth. For example, at least one parameter may include the maximum competition window size or the delay duration.

[0135] Processing of transmission characteristics based on a profile (e.g., a transmission profile) can be provided. For example, based on the transmission profile described herein, coding aspects, transmission power, and / or resource selection or allocation may be determined.

[0136] In the example, the WTRU can determine from the transmit profile one or more aspects that may be related to channel coding for a physical channel (e.g., PDCCH, PDSCH, PUCCH, or PUSCH). The coding aspects that can be determined may include one or more of the following: (i) the type of code (e.g., polar, LDPC, turbo, iterative), (ii) the coding rate, (iii) the length of the cyclic redundancy check (CRC) that may be added to the set of information bits for error detection, (iv) the mapping between the modulation coding scheme field and the modulation order and coding rate, or (v) one or more search spaces for one or more aggregation levels for decoding the PDCCH.

[0137] For example, the WTRU can be configured with a 16-bit CRC for the PDCCH when the higher-layer configuration for the PDCCH can indicate a first transmit profile. The WTRU can be configured with a 24-bit CRC when the configuration can indicate a second transmit profile. For example, using a variable CRC size may be necessary depending on the characteristics of the data being transmitted, allowing the network to use more reliable PDCCH transmissions.

[0138] In the example, the coding rate that can be applied to at least one type of UCI (e.g., HARQ-ACK) should depend, for example, on the transmission profile. In the example, UCIs of multiple transmission profiles can be multiplexed into the same transmission (e.g., PUCCH). Each UCI (e.g., each UCI) can be encoded separately using, for example, a profile-dependent coding rate. Such encodings can represent a first encoding stage. The coded bits from the first encoding stage associated with each UCI can be concatenated and receive a second encoding stage.

[0139] The transmit power can be determined based on the transmit profile. In the example, the WTRU can determine and apply the transmit power associated with the transmit. The transmit power can be determined using formulas and / or parameters that may depend on the transmit profile. In the example, parameters that may be used in the power control formula may be configured for each transmit profile (e.g., independently). In the example, the power control setting may be based on an offset value that may be configured by the transmit profile. In the example, the interpretation of the TPC field (e.g., with respect to the number of dB for up / down adjustment) may depend on the transmit profile. Using the transmit profile to determine the transmit power can facilitate the use of appropriate levels of power and achieve the target reliability associated with the transmit (e.g., each transmit).

[0140] In the example, the power control parameters applied to the transmission of a scheduling request (SR) may depend on the SR configuration. The SR configuration may be mapped to the logical channel that triggered the SR.

[0141] In the example, the power control parameters applied to a HARQ-ACK transmission may depend on the duration of the corresponding PDSCH transmission. For example, if the PDSCH transmission is below a threshold configured by the upper layer, the WTRU may apply a first set of power control parameters. If the PDSCH transmission exceeds the threshold, the WTRU may apply a second set of power control parameters.

[0142] In the example, the power control parameters applied to the transmission of the HARQ-ACK may depend on the UL bandwidth portion (e.g., the active bandwidth portion) to which the HARQ-ACK is transmitted, or on the DL bandwidth portion to which the corresponding PDSCH is transmitted. Each bandwidth portion may be configured by the upper layer using a set of power control parameters.

[0143] In the example, the power control parameters applied to CSI transmission via PUCCH (or PUSCH) may depend on the BLER target value configured for the CSI report setting. For example, WTRU may apply a power offset based on the BLER target value. The BLER target value may be configured by the upper layer for each BLER target value, for example. The power offset may be configured for each CSI report setting, for example.

[0144] Data or UCIs from multiple transmit profiles can be multiplexed into the same transmit. Power control parameters for a common transmit can be determined, for example, based on the profiles, for example, the profile with the highest priority level.

[0145] In the example, the power control parameters may include a specific power control mode (PCM) or a minimum guaranteed power level. For example, the PCMs may include PCM1, PCM2, etc.

[0146] For example, resource selection or allocation can be determined based on the transmit profile. In the example, the resources and / or format that may be used by the transmit may depend on the transmit profile. For example, in the case of PUCCH, the set of resources and / or format indicated by ARI may depend on the transmit profile. The network may consist of at least one set of resources for a transmit profile, such as each transmit profile. A set of resources that are less likely to be affected by interference may be associated with a transmit profile that can be used for more reliable transmits.

[0147] In the example, using long or short PUCCH formats and / or several symbols can correspond to transmit profiles. In the example, the WTRU can be configured to transmit PUCCH via multiple symbols (e.g., two symbols) for a transmit profile that may be suitable for ultra-reliable traffic (e.g., a first transmit profile). The WTRU can be configured to transmit PUCCH via a symbol (e.g., one symbol) for another transmit profile that may be suitable for other non-ultra-reliable mobile broadband traffic (e.g., a second transmit profile).

[0148] In the example, a set of bandwidth portions and neurology (including, for example, one or more of the subcarrier interval, cyclic prefix length, or number of symbols per slot or minislot) can be used for downlink or uplink transmissions within the carrier and may depend, for example, on the transmit profile.

[0149] In the example, the waveform can depend on the transmit profile. For example, the waveform can be an orthogonal frequency division multiplexing (OFDM) waveform or a single-carrier frequency division multiple access (SC-FDMA) waveform. In the example, the use of frequency hopping can depend on the transmit profile.

[0150] In the example, with respect to at least one type of UCI (e.g., HARQ-ACK), the UCI may be transmitted via PUCCH or multiplexed with data transmitted via PUSCH. The choice of whether the UCI is transmitted via PUCCH or multiplexed with data transmitted via PUSCH can be made depending on the transmission profile associated with the UCI and the data. In the example, for example, the UCI can be multiplexed with the data via PUSCH when the UCI and the data can have the same transmission profile or the same priority level associated with the transmission profile. The UCI may be transmitted separately via PUCCH. In the example, at least one type of UCI (e.g., Channel Status Information (CSI)) may be excluded.

[0151] In the example, several resource elements, or parts thereof, available to at least one type of UCI (for example, when data is multiplexed in PUSCH) may be determined, for example, by one or more factors (e.g., beta parameters). Such factors may depend on the transmit profile. In the example, for a given type of UCI, the WTRU may consist of a first set of factors that may be applicable to a first transmit profile, and a second set of factors that may be applicable to a second transmit profile. A transmit profile suitable for ultra-reliable traffic may, for example, allow the use of a large portion of PUSCH resources.

[0152] In this example, the WTRU can determine whether UCI diversity applies. For example, an SR configuration may include a configuration of PUCCH resources (or PUCCH diversity resources) that are applicable to UCI diversity. For example, when an SR is triggered by a logical channel (LCH) mapped to such an SR configuration, the WTRU may send the SR through multiple PUCCH resources (or PUCCH diversity resources).

[0153] Prioritization between transmissions can be provided. For example, priority levels may be defined or configured for each transmission profile (e.g., each transmission profile). Priority levels can be used, for example, to determine whether one or more transmissions can be excluded or interrupted, scaled down, allocated to fewer resources, or processed later, in the event of a conflict. The occurrence of a conflict can be beneficial (e.g., from a system perspective) by making a larger percentage of system resources available (e.g., compared to a situation where resources might be reserved).

[0154] Prioritization can be provided for power scaling. In the example, WTRU may reduce at least one transmit if the configured total maximum power may be exceeded during a time period (e.g., during a subframe, slot, or mini-slot). The order of priority for scaling may depend on the transmit profile (in addition to other criteria such as UCI or data type). In the example, the transmit profile criterion may take precedence over or replace other criteria. In the example, if the first transmit profile has a higher priority level than the second transmit profile, a PUSCH that may contain data transmitted according to the first transmit profile may be allocated power before a PUCCH that may contain HARQ-ACKs transmitted according to the second transmit profile. Prioritization based on the use of transmit profiles can be applied even if HARQ-ACKs would normally be prioritized over data.

[0155] Prioritization can be provided to exclude a transmission, or at least a portion of a transmission. For example, a WTRU might determine that multiple transmissions may overlap across a subset of resources, and that at least one or at least a portion of those transmissions can be excluded or suspended, for example, based on the transmission profile associated with the overlapping transmissions. The WTRU might determine, for example, that the transmission with the highest priority (for example, based on the transmission profile) can be sent through the resource.

[0156] Duplication can arise, for example, from scheduling instructions that may be received at different times and with different latency requirements. In an example, a WTRU may receive downlink assignments that require sending HARQ-ACKs via PUCCH for some symbols in a given slot. The WTRU may receive an authorization for a PUSCH transmission for the same slot (e.g., receiving a subsequent authorization). The WTRU may decide that a PUSCH transmission takes precedence over a PUCCH transmission if, for example, the transmission profile associated with uplink data that can be sent via PUSCH has a higher priority level than the transmission profile associated with HARQ-ACKs that can be sent via PUCCH. Based on such a decision, the WTRU may use redundant resources for a PUSCH transmission and exclude the PUCCH transmission. In an example, the WTRU may send a PUCCH via redundant resources. The WTRU may, for example, in rate matching calculations, use the remaining resources that could have been allocated for a PUSCH, taking into account the reduced amount of resources used.

[0157] A WTRU may receive a first downlink assignment indicating the transmission of a HARQ-ACK via PUCCH on a first resource. A WTRU may receive a second downlink assignment indicating the transmission of a HARQ-ACK via PUCCH on a second resource (for example, subsequently). A WTRU may transmit a HARQ-ACK corresponding to a PDSCH (or PDCCH) with a higher priority transmission profile, for example, if the first and second resources overlap or are the same. A WTRU may transmit a HARQ-ACK corresponding to a PDSCH (or PDCCH) based, for example, on CORESET, search space, and / or RNTI.

[0158] In the example, a WTRU may receive permission for a PUSCH via a slot. The WTRU may receive (e.g., subsequently receive) (or trigger a scheduling request) a downlink allocation that may require the transmission of a PUCCH via one or more resources in the same slot (e.g., via the last time symbol for a short PUCCH, or via one or more time symbols available on the uplink for a long PUCCH (e.g., most or all of the time symbols)). The WTRU may decide that a PUCCH can be transmitted via a duplicate resource, for example, when the PUCCH contains a UCI associated with a higher transmit profile than the data transmitted via the PUSCH. The WTRU may decide to exclude the PUSCH, or that the PUSCH can be transmitted via a non-duplicate resource, for example, using puncturing applied to the duplicate resource. The sequence of actions may depend on the type of transmission being interrupted (e.g., a PUSCH may still be transmitted when interrupted by a short PUCCH), and / or whether the percentage of resources interrupted exceeds a threshold.

[0159] WTRU can multiplex HARQ-ACK and CSI into a single PUCCH or PUSCH transmission, and a subset of the CSI report (e.g., N reported CSI It can be determined that the CSI report can be selected based on the highest possible coding rate. The priority order for CSI reports can depend on the transmission profile (or configured BLER target value), and therefore, a CSI report associated with a lower BLER target value can be considered to have a higher priority than a CSI report associated with a higher BLER target value. The priority determined from the BLER target value or transmission profile can take precedence over at least one of the other priority criteria used to select the CSI report, such as the type of CSI. For example, doing so can yield precoding matrix information (PMI) for a CSI report associated with a lower BLER target value that has a higher overall priority than the RI (rank information) for a CSI report associated with a higher BLER target value.

[0160] Prioritization of DL data processing can be provided. For example, a WTRU may be scheduled to receive DL data with different transmission profiles via at least one PDSCH and report HARQ-ACKs associated with that DL data (e.g., a certain number of times). The WTRU may not be able to complete decoding at least one code block within the time available for transmitting the corresponding HARQ-ACKs. The WTRU may, for example, prioritize decoding higher-priority DL data according to the transmission profile associated with the DL data.

[0161] In the example, the HARQ-ACK may be sent to the transport block before the decoding of at least one group of code blocks is complete. Depending on the transmit profile associated with the data, the WTRU may set the HARQ-ACK using one of the following methods: For example, the WTRU may set the HARQ-ACK of a group of code blocks that have not yet been decoded to an ACK when decoding may be complete, and set it to a NACK for at least one other group of code blocks in the transport block. The WTRU may set the HARQ-ACK to an ACK for one or more groups of code blocks that could not be set to a NACK. This way, for example, if some code blocks that have not yet been decoded may be successful and do not require retransmission, the network can minimize the amount of resources that may be used for retransmission. This exemplary procedure may be chosen, for example, for transmit profiles that may have a lower priority.

[0162] In the example, the WTRU can set the HARQ-ACK of a code block group that has not yet been decoded to a NACK. Doing so can minimize the latency of transport block delivery, for example, by making retransmitted data available more quickly if the decryption result may be unsuccessful. This exemplary procedure may be chosen, for example, for a transmit profile that can have a high priority.

[0163] Prioritization can be provided for resource sharing. For example, a WTRU can be configured to multiplex UCI and / or uplink data into (e.g., the same) PUSCH or PUCCH transmit according to different transmit profiles. The proportion of resources (e.g., resource elements (REs)) that can be allocated to UCI or data according to the transmit profile can depend on the relative priority level of the transmit profiles. For example, in the example (e.g., with respect to UCI multiplexing in PUSCH), a first value of the beta parameter for the UCI type can be applied when, for example, the priority of the transmit profile associated with the UCI is higher than the priority of the transmit profile associated with the data. A second value of the beta parameter can be applied when, for example, the transmit profiles have equal priority. A third value can be applied when, for example, the priority of the transmit profile associated with the UCI is lower than the priority associated with the transmit profile of the data.

[0164] Payload / MCS selection can be based on prioritization. For example, the WTRU may be configured to use a first modulation coding scheme, transport block size, and / or payload for a transmit if, for example, the transmit does not conflict with a higher-priority transmit by transmit profile. The WTRU may be configured to use a second modulation coding scheme, transport block size, or payload for a transmit if, for example, the transmit conflicts with a higher-priority transmit by transmit profile. Conflict can correspond to situations such as when the resources of multiple transmits overlap, or when the maximum total transmit power configured may be excessive.

[0165] State-based differentiated processing can be provided. For example, a WTRU can apply a set of parameters corresponding to a transmit profile (e.g., based on the transmit profile state). The transmit profile state can change due to indications from the network. For example, the transmit profile state can change due to MAC control elements (MAC CE) or downlink control information (DCI). The transmit profile state can also change when an event occurs, such as the end of a timer (e.g., a timing advance (TA) timer). The set of parameters corresponding to the transmit profile may include a set of PUCCH resources for HARQ-ACK / NACK, a set of parameters used to determine some of the resource elements used for UCI in PUSCH, etc.

[0166] In the example, transmit profiles and associated parameters can be configured for bandwidth portions. A WTRU configured with multiple bandwidth portions can apply transmit profiles and associated parameters corresponding to the active bandwidth portion. A WTRU can receive DCI or MAC CE indicating a change in the active bandwidth portion. A WTRU can apply the transmit profile and associated parameters associated with the received (or indicated) active bandwidth portion (for example, upon receiving this indication).

[0167] In the example, the WTRU can receive a DCI indicating a change in the active bandwidth portion (for example, in which case the new active bandwidth portion and the existing active bandwidth portion can share the same configuration, except for the transmit profile and associated parameters). For example, the WTRU can be configured with two bandwidth portions having the same frequency allocation. When the WTRU receives an indication of a change in the active bandwidth portion (for example, satisfying this condition), the WTRU can receive a PDSCH in the same slot in which the DCI was received, based on the parameters indicated in the DCI (for example, as if there were no change in the active bandwidth portion). In the example, if the WTRU receives an indication of an active bandwidth portion where the new active bandwidth portion does not have the same frequency allocation as the existing active bandwidth portion, the WTRU can apply a gap in the PDSCH reception (for example, to allow readjustment and / or to perform other actions, such as a CSI measurement on the new active bandwidth portion).

[0168] A system, method, and means can be provided for handling transmission characteristics with overlap between multiple transmissions. The WTRU can determine that there is an overlap in time between multiple transmissions, for example, between a first transmission and a second transmission. The WTRU can do at least one of the following: (1) perform a subset of the transmissions (e.g., one); (2) cancel, exclude, or interrupt (e.g., if already in progress) one of the transmissions; (3) temporarily interrupt and / or delay one of the transmissions; (4) perform both transmissions and / or apply a power scaling function to at least one of the transmissions, for example, if there is no frequency overlap between the transmissions; or (5) modify at least one characteristic of the first transmission to carry at least a portion of the information that would normally be carried using the second transmission. For example, the WTRU can modify the characteristics of the demodulated reference signal (DM-RS) for the first PUSCH transmission to indicate a scheduling request (SR). Modifications may include, for example, assigning zero power, switching to a second pre-configured resource, or changing the phase. The WTRU may perform such actions in combination with assigning zero power to a second transmission that would normally overlap in time, such as an SR on PUCCH.

[0169] In other examples of transmissions described herein, the first transmission may include an SR, and the second transmission may include a PUSCH (or PUCCH). An SR associated with high-priority traffic may be multiplexed with a PUSCH or PUCCH. A WTRU may indicate and / or transmit uplink control information, such as an SR associated with the first transmission profile, by modifying at least one characteristic of the transmission associated with the second transmission profile, such as a PUSCH or PUCCH transmission. In the example, the first transmission profile may have a higher priority than the second transmission profile. In the example, the duration of a PUSCH or PUCCH transmission may be longer (e.g., significantly longer) than the periodicity of scheduling requests for the first transmission profile. The length of a PUSCH or PUCCH transmission may be of a nature that could cause waiting for the completion of the PUSCH or PUCCH transmission before transmitting an SR to exceed a latency value (e.g., an acceptable latency value).

[0170] At least one characteristic of a transmission that can be modified may include a characteristic of a reference signal embedded in the transmission, such as a demodulated reference signal (DM-RS). For example, such a characteristic may include the relative phase between two time symbols carrying the DM-RS. The relative phase may be a first value, for example, if no SR is transmitted. The relative phase may be a second value, if a scheduling request is transmitted.

[0171] At least one modifiable transmission characteristic may include a transmit power parameter for at least one time symbol (or resource element). For example, the transmit power of at least one symbol may be reduced compared to the transmit power of the remaining symbols when an SR is transmitted. In the example, the transmit power of at least one symbol may be reduced to zero, and / or the WTRU may not be transmitted on at least one symbol. Doing so ensures that the network can reliably detect the transmission of the SR and that the PUSCH can be successfully decoded.

[0172] At least one time symbol (or resource element) whose transmission can be modified may be limited to a subset of the time symbols of the transmission. For example, if the indication is conveyed by modifying the characteristics of a reference signal, the time symbols may be limited to the time symbols that convey such a reference signal. The time symbols affected by the modification may include time symbols that convey the reference signal after the trigger of the SR (e.g., all time symbols). In the example, if the indication is conveyed by modifying the transmit power of at least one time symbol, that subset may be determined based on the configured periodicity of the scheduling request. At least one affected time symbol may include a single symbol or time symbol (e.g., all time symbols) immediately following the trigger of the SR, which may occur concurrently with the configured opportunity of the scheduling request. In the example, one or more time symbols containing the reference signal may be excluded from the subset.

[0173] In the example, a subset of resource elements (or time symbols) for a PUSCH or PUCCH transmission can be configured to indicate whether an SR has been triggered since the start of the transmission. A WTRU can be configured with at least one such subset of resource elements that occur regularly (e.g., periodically) in the time domain. Such a configuration may depend on the configured periodicity of the SR, or it may coincide with the configured occasions for the transmission of the SR. Through a given subset, the WTRU can transmit, for example, a first predefined sequence of modulated symbols if an SR has not been triggered up to the offset before the time symbol in the subset. The WTRU can transmit, for example, a second predefined sequence of modulated symbols if an SR has been triggered. The predefined sequences can override (e.g., using puncturing) the modulated symbols of a PUSCH or PUCCH transmission that are mapped to the subset of resource elements, or to the resource elements that can be excluded first from the set of resource elements to which the modulated symbols of a PUSCH or PUCCH transmission are mapped (e.g., previously mapped).

[0174] A system, method, and means for processing transmission characteristics can be provided based on the timing that can be provided. For example, one or more aspects can be determined depending on the available WTRU processing, such as WTRU processing time.

[0175] A WTRU can determine that at least one prioritization or multiplexing solution can be applied. A prioritization or multiplexing solution may include, for example, the following: (1) timing aspects of when data is available for transmission or when data applicable to transmission can trigger BSR transmissions and / or SR transmissions; (2) timing aspects of when scheduling requests (SRs) can be triggered; (3) timing aspects of when downlink control information indicating an uplink transmission (e.g., push transmission or push transmission) can be received; (4) timing aspects of receiving higher layer signaling, for example, at least in the case of configured authorization or in the case of another periodic or semi-permanent transmission (e.g., CSI, SRS, etc.); (5) configuration (1) The timing aspects may be one or more of the following, including at least one of the timing aspects: (6) the timing aspect of when a PUSCH transmission may be scheduled to start (and / or end) in accordance with made or dynamic authorizations; (7) the timing aspect of when a PUSCH transmission may be scheduled to start (and / or end) in accordance with, for example, a semi-static configuration or indication of downlink control information; (8) the timing aspect of when it may be determined that a transmission will be made in the future for any other reason, such as the initiation of a procedure such as the receipt of a paging request or the re-establishment of an RRC connection. For example, in case (1), the WTRU may make such a decision when new data becomes available for transmission to a particular priority and / or type of logical channel (LCH), or when data available for transmission can trigger the transmission of a Buffer Status Report (BSR) and / or an SR. WTRU can make such decisions on data associated with mapping limits (e.g., LCH relative to transmit mapping limits), profiles, and / or LCH / logical channel group (LCG) priorities.

[0176] A WTRU can make such a decision to apply, for a particular profile and / or for a particular LCH / LCG priority, at least one of prioritization or multiplexing solutions to data and / or transmissions associated with a particular (LCH to transmission) mapping restriction. For example, a WTRU can determine a prioritization or multiplexing solution that may be applied to at least two or more transmissions (e.g., partially overlapping transmissions). The decision may be made based on the difference between the start time of the first transmission and the time at which the second transmission is determined to exist, as described herein.

[0177] For example, if the WTRU determines that the first event (event A) occurs at a time of at least x symbols prior to the onset of event B (event B), it may take either the first action 1 (action 1) or the second action (action 2). Event B may be a known event.

[0178] One or more timing cases may be provided to indicate that the SR trigger may depend on the appropriateness of the authorization. Event A may correspond to an autonomous trigger of the WTRU associated with the reception of downlink control signaling and / or an event that may have a higher priority than that of Event B (e.g., based on the applicable transmit profile). The autonomous trigger may be one of the timing aspects described herein, such as triggering an SR when new data becomes available for transmit. Event B may correspond to a scheduled event (e.g., an uplink transmit).

[0179] In Action 1, the WTRU may decide that there is sufficient time available to act on the scheduled information and / or to prioritize one of the two events before the lower-priority event begins. In Action 2, the WTRU may decide that there is not enough time to adjust its transmission and / or prioritize one of the two events before the lower-priority event begins, and therefore, instead, to modify the characteristics of the corresponding ongoing transmission. The WTRU can be constructed, for example, by the RRC, using a value of x, where x can be, for example, the time value of a symbol in a framing unit (e.g., minislot, slot, subframe) or a time value in absolute time, such as milliseconds.

[0180] In the example, Event A could correspond to an SR trigger for data associated with a transmission profile, such as a transmission profile corresponding to the transmission of URLLC data. Event B could correspond to the start of an uplink transmission on PUSCH for data associated with a transmission profile, such as a transmission profile corresponding to the transmission of eMBB data.

[0181] Action 1 can correspond to the cancellation of an uplink transmission, such as a PUSCH transmission corresponding to eMBB data, and the WTRU performs an SR transmission using resources / methods corresponding to URLLC type data. Action 2 can correspond to the cancellation / exclusion / zero power setting of one or more specific symbols and / or DM-RS modifications of a PUSCH transmission to eNBB to indicate an SR requesting URLLC, as described herein.

[0182] In this example, one transmission may correspond to a first transmission profile or similar, such as a URLLC service, and the other may correspond to a second transmission profile, such as an eMBB service. In such an example, if the WTRU determines that there is sufficient processing time (e.g., the time between two events is less than x), and if the WTRU makes this decision before any of the partially overlapping transmissions begin, the WTRU may, for different combinations of signals, do the following: (1) The WTRU may prioritize SR (for URLLC) and exclude PUSCH (for eMBB), and (2) The WTRU may, using a similar coupling principle as used for UCI over PUSCH for LTE, for example, to prioritize (for URLLC) (1) The WTRU can implement at least one of the following: (2) It can prepend an SR to the PUSCH (for eMBB) and / or puncture the PUSCH (for eMBB); (3) The WTRU can embed a transmission, for example, by excluding a portion of the PUSCH (for eMBB) and replacing it with an sPUSCH (including a BSR (for URLLC)); (4) The WTRU can signal an SR using a modification of the DM-RS sequence of the PUSCH (for eMBB); (5) The WTRU can adjust the UL PC, for example, by applying power scaling if the WTRU is power limited.

[0183] For example, if the WTRU determines that there is insufficient processing time (e.g., the time between two events is less than x), or if the WTRU does not make this determination before initiating any one of the transmissions that overlap at least partially, the WTRU may, for different combinations of signals, do at least one of the following: (1) the WTRU may interrupt / interrupt or puncture an ongoing PUSCH (for eMBB) and the WTRU may transmit an SR (for URLLC) using the relevant resources, e.g., with a shorter PUSCH instead, e.g., transmit a BSR (for URLLC) e.g., with a shorter PUSCH (for URLLC) instead, and / or transmit a URLLC TB e.g., with a shorter PUSCH (for URLLC) instead, e.g., (2) the WTRU may signal an SR using a change in the DM-RS sequence for an ongoing PUSCH (for eMBB), or (3) the WTRU may adjust the UL PC accordingly (e.g., for a DM-RS boost).

[0184] In the example, if a WTRU is configured, for example, with simultaneous PUSCH+PUSCH or PUSCH+PUCCH transmissions, it can initiate further transmissions on the same carrier. A WTRU can send further transmissions, for example, on the same bandwidth portion or on different bandwidth portions, if configured and / or active. A WTRU can perform such transmissions using non-joint resources and / or joint resources. Non-joint resources may include separate PUSCH and / or PUCCH transmissions that can be initiated alongside other ongoing transmissions. Joint resources can be used, for example, when a URLLC is configured and / or authorization for any other type of traffic (e.g., lower priority) may include resources for further transmissions of SR, BSR.

[0185] A WTRU can allocate power using one or more power control functions. A WTRU may consider transmissions that may overlap at least partially in time, but it may not make a decision on whether such transmissions should be transmitted. In making a decision on whether to transmit such transmissions, a WTRU may include the following factors: the priority of each power allocation function, the method thereof, and / or the resources that may be used, for example, when applied to a Maximum Power Reduction (MPR) setting.

[0186] The systems and / or methods described herein can be implemented in computer programs, software, and / or firmware embedded in computer-readable media executed by a computer and / or processor. Examples of computer-readable media may include electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media may include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and / or optical media such as CD-ROM disks and / or digital multi-purpose disks (DVDs). Processors associated with software can be used to implement radio frequency transceivers used in WTRUs, terminals, base stations, RNCs, and / or any host computer. [Industrial applicability]

[0187] This invention can be used for wireless communication.

Claims

1. A wireless transceiver unit (WTRU), A first physical downlink control channel (PDCCH) transmission is received, which includes first downlink control information (first DCI), and the first DCI includes a first resource indicator. Based on the first DCI, a first transmit profile is determined for a first uplink transmit, the first transmit profile is associated with a first priority level and a first physical uplink control channel configuration (first PUCCH configuration), and the first PUCCH configuration is associated with a first set of PUCCH resources. A second PDCCH transmission is received, which includes a second DCI, and the second DCI includes a second resource indicator. Based on the second DCI, a second transmit profile is determined for the second uplink transmit, the second transmit profile is different from the first transmit profile, the second transmit profile is associated with a second priority level and a second PUCCH configuration, the second PUCCH configuration is associated with a second set of PUCCH resources, and the first uplink transmit and the second uplink transmit are associated with the same cell. Based on the first resource indicator, a first PUCCH resource is selected for the first uplink transmission, and the first PUCCH resource is included in the first set of PUCCH resources associated with the first PUCCH configuration. Based on the second resource indicator, a second PUCCH resource is selected for the second uplink transmission, and the second PUCCH resource is included in the second set of PUCCH resources associated with the second PUCCH configuration. It is determined that the selected first PUCCH resource and the selected second PUCCH resource overlap in time. It is determined that the first priority level associated with the first transmission profile is higher than the second priority level associated with the second transmission profile. The first uplink transmission is transmitted using the selected first PUCCH resource. Processor configured in such a way WTRU equipped with.

2. The WTRU according to claim 1, wherein the first uplink transmission includes hybrid automatic retransmission request (HARQ) acknowledgment / negation (ACK / NACK) feedback.

3. The WTRU according to claim 1, wherein the first resource indicator is an affirmative / negative response (ACK / NACK) resource indicator (ARI).

4. The WTRU according to claim 1, wherein the processor is further configured to determine, based on the first transmission profile, one or more of the format associated with the first uplink transmission, the number of symbols associated with the first uplink transmission, or the neurology associated with the first uplink transmission.

5. The WTRU according to claim 4, wherein the neurology associated with the first uplink transmission includes one or more of the subcarrier interval, the length of the cyclic prefix, and the number of symbols per slot.

6. The aforementioned processor, Based on the determination that the first priority level associated with the first transmit profile is higher than the second priority level associated with the second transmit profile, the second uplink transmit is dropped. A WTRU according to claim 1, further configured as follows.

7. The WTRU according to claim 1, further configured to determine, based on the first transmit profile, one or more of the following: the type of code associated with the first uplink transmit, the code rate associated with the first uplink transmit, and the length of the cyclic redundancy check (CRC) associated with the first uplink transmit.

8. The WTRU according to claim 1, wherein the processor is further configured to determine a transmit power level for the first uplink transmit based on the first transmit profile, and the first uplink transmit is transmitted using the determined transmit power level.

9. A method implemented in a wireless transceiver unit (WTRU), Steps include receiving a first physical downlink control channel (PDCCH) transmission including first downlink control information (first DCI), wherein the first DCI includes a first resource indicator; A step of determining a first transmit profile for a first uplink transmit based on the first DCI, wherein the first transmit profile is associated with a first priority level and a first physical uplink control channel configuration (first PUCCH configuration), and the first PUCCH configuration is associated with a first set of PUCCH resources. A step of receiving a second PDCCH transmission including a second DCI, wherein the second DCI includes a second resource indicator. A step of determining a second transmit profile for a second uplink transmit based on the second DCI, wherein the second transmit profile is different from the first transmit profile, the second transmit profile is associated with a second priority level and a second PUCCH configuration, the second PUCCH configuration is associated with a second set of PUCCH resources, and the first uplink transmit and the second uplink transmit are associated with the same cell. A step of selecting a first PUCCH resource for the first uplink transmission based on the first resource indicator, wherein the first PUCCH resource is included in the first set of PUCCH resources associated with the first PUCCH configuration, A step of selecting a second PUCCH resource for the second uplink transmission based on the second resource indicator, wherein the second PUCCH resource is included in the second set of PUCCH resources associated with the second PUCCH configuration, The steps include determining that the selected first PUCCH resource and the selected second PUCCH resource overlap in time, The steps include determining that the first priority level associated with the first transmission profile is higher than the second priority level associated with the second transmission profile, The steps include: transmitting the first uplink transmission using the selected first PUCCH resource; A method for providing this.

10. The method according to claim 9, wherein the first uplink transmission includes hybrid automatic retransmission request (HARQ) acknowledgment / negation (ACK / NACK) feedback.

11. The method according to claim 9, wherein the first resource indicator is an affirmative / negative response (ACK / NACK) indicator (ARI).

12. A step of determining, based on the first transmission profile, one or more of the following: the format associated with the first uplink transmission, the number of symbols associated with the first uplink transmission, or the neurology associated with the first uplink transmission. The method according to claim 9, further comprising:

13. The method according to claim 12, wherein the neurology associated with the first uplink transmission includes one or more of the subcarrier interval, the length of the cyclic prefix, and the number of symbols per slot.

14. Steps to drop the second uplink transmission based on the determination that the first priority level associated with the first transmission profile is higher than the second priority level associated with the second transmission profile. The method according to claim 9, further comprising:

15. A step of determining, based on the first transmission profile, one or more of the following: the type of code associated with the first uplink transmission, the code rate associated with the first uplink transmission, and the length of the cyclic redundancy check (CRC) associated with the first uplink transmission. The method according to claim 9, further comprising:

16. A step of determining a transmit power level for a first uplink transmit based on the first transmit profile, wherein the first uplink transmit is transmitted using the determined transmit power level. The method according to claim 9, further comprising:

17. A wireless transceiver unit (WTRU), A first physical downlink control channel (PDCCH) transmission is received, which includes first downlink control information (first DCI), and the first DCI includes a first resource indicator. Based on the first DCI, it is determined whether a first uplink transmission will be sent according to a first or second transmission profile, wherein the first transmission profile is associated with a first physical uplink control channel configuration (first PUCCH configuration), and the second transmission profile is associated with a second PUCCH configuration, wherein the first PUCCH configuration is associated with a first set of PUCCH resources, and the second PUCCH configuration is associated with a second set of PUCCH resources. A second PDCCH transmission is received, which includes second downlink control information (second DCI), and the second DCI includes a second resource indicator. Based on the second DCI, it is determined whether the second uplink transmission will be sent according to the first or second transmission profile, and the first and second uplink transmissions are associated with the same cell. Based on the first resource indicator, a first PUCCH resource is selected for the first uplink transmission, and the first PUCCH resource is included in the first set of PUCCH resources when the first DCI indicates the first transmission profile, and the first PUCCH resource is included in the second set of PUCCH resources when the first DCI indicates the second transmission profile. Based on the second resource indicator, a second PUCCH resource is selected for the second uplink transmission, and the second PUCCH resource is included in the first set of PUCCH resources when the second DCI indicates the first transmission profile, and the second PUCCH resource is included in the second set of PUCCH resources when the second DCI indicates the second transmission profile. It is determined that the selected first PUCCH resource and the selected second PUCCH resource overlap in time. It is determined that the first priority level associated with the first transmission profile is higher than the second priority level associated with the second transmission profile. The first uplink transmission is transmitted using the selected first PUCCH resource. Processor configured in such a way WTRU equipped with.

18. The aforementioned processor, The WTRU according to claim 17, further configured to drop the second uplink transmission based on the determination that the first priority level associated with the first transmission profile is higher than the second priority level associated with the second transmission profile.

Images