Reliable control signaling

Abstract

To provide systems, methods and means for reliable control signaling, e.g., in New Radio (NR).SOLUTION: A receiver in a wireless transmit / receive unit (WTRU) may receive one or more physical downlink control channel (PDCCH) transmissions comprising downlink control information (DCI). The WTRU may determine a transmission profile associated with uplink control information (UCI). Based on the transmission profile, the WTRU may determine one or more transmission characteristics associated with the transmission of the UCI. The WTRU may transmit the UCI over a physical uplink control channel (PUCCH). The UCI may be transmitted using transmission characteristics determined by the WTRU. The WTRU may transmit the UCI based on at least one of a control resource set (CORESET), a search space and a radio network temporary identifier (RNTI).SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] Reliable control signaling. [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 519,585, filed June 14, 2017, U.S. Provisional Patent Application No. 62 / 585,937, filed November 14, 2017, U.S. Provisional Patent Application No. 62 / 652,002, filed April 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 radio waves continue to evolve. Fifth-generation or next-generation (NG) radio systems can be referred to as 5G or New Radio (NR). Previous generations of mobile communications can be, for example, fourth-generation (4G) Long Term Evolution (LTE). The set of use cases for NR can generally be categorized into one of the following: enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), or massive machine-type communications (mMTC). Summary of the Invention [Problem to be solved by the invention]

[0004] Current processing and transmission mechanisms used in such applications can be less efficient. [Means for solving the problem]

[0005] For example, systems, methods, and means are disclosed for reliable control signaling in New Radio (NR). 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 the uplink control information (UCI). The transmission profile can be determined based on one or more of the following: an identification of a logical channel or logical channel group for data associated with the UCI and characteristics of at least one PDCCH transmission. The PDCCH transmission can be mapped to one or more resources of a control resource set (CORESET).

[0006] The transmission profile may be determined based on one or more DCI fields in the received DCI or one or more identifications of bandwidth portions (BWPs) used to transmit one or more of the DCI or UCI.

[0007] The DCI may include a first DCI and a second DCI. The DCI field may indicate a hybrid automatic repeat 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 CORESET or the 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 spacing, a subset of slots within a subframe, or at least one reference signal.

[0008] The UCI may include a first UCI and a second UCI. The first UCI or the second UCI may include one or more of a hybrid automatic repeat request (HARQ), a scheduling request (SR), or a channel quality indicator (CQI). The UCI may be transmitted based on a CORESET, a search space, or an RNTI. The UCI may be associated with a PDSCH transmission or a PDCCH transmission. In an example, the first UCI or the second UCI may include feedback information bits for a data transmission assigned by the first DCI or the second DCI. In another example, the second UCI may correspond to a redundant transmission of the first UCI.

[0009] Based on the transmission profile, the WTRU may determine one or more transmission characteristics associated with transmitting the UCI. The one or more transmission 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 a priority level.

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

[0011] For example, if the UCI includes a hybrid automatic repeat request acknowledgment (HARQ ACK), the WTRU may determine a transmission profile associated with the PDSCH transmission based on one or more of the following: duration of the transmission, bandwidth part, numerology, or modulation and coding scheme (MCS) table for the control information.

[0012] For example, if the UCI includes channel state information (CSI), the WTRU may determine the transmission profile based on one or more of the following: a block error rate (BLER) target value associated with the CSI, or a CSI reporting configuration.

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

[0014] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which: [Brief explanation of the drawings]

[0015] [Figure 1A] FIG. 1 illustrates an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B illustrates an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system of FIG. 1A. [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and core network (CN) that may be used within the communication system of FIG. 1A. [Figure 1D]FIG. 1B is a system diagram illustrating a further exemplary RAN and a further CN that may be used within the communication system of FIG. 1A. [Figure 2] FIG. 1 illustrates an example of downlink control information (DCI) diversity. [Figure 3] FIG. 1 illustrates an example of DCI and uplink control information (UCI) diversity. DETAILED DESCRIPTION OF THE INVENTION

[0016] A detailed description of exemplary embodiments will now be provided with reference to various figures. While the description provides detailed examples of possible implementations, it should be noted that the details are illustrative and are not intended to limit the scope of the present application in any way.

[0017] 1A is a diagram of an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 enables the multiple wireless users to access such content by sharing system resources, including wireless 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), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tailed unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0018] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” are configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspot 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, devices operating in commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as UEs.

[0019] The communications system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a Base Transceiver Station (BTS), a Node B, an eNodeB, a Home Node B, a Home eNodeB, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each shown as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

[0022] More specifically, as noted above, the communication system 100 may be a multiple access system and may use one or more channel access schemes, 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 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

[0023] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air 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 may implement a radio technology such as New Radio (NR) radio access that may establish an air interface 116 using NR.

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

[0026] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Evolution Enhanced Data Rates (EDGE), GSM EDGE (GERAN), and the like.

[0027] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a workplace, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., used by drones), a roadway, and similar locations. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. 1A, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0028] The RAN 104 / 113 can communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A , it will be understood that the RAN 104 / 113 and / or the CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to a RAN 104 / 113 that may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0029] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use 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. The network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may use the same RAT as the RAN 104 / 113 or a different RAT.

[0030] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links.) For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a that can use cellular-based wireless technology and with a base station 114b that can use IEEE 802 wireless technology.

[0031] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements and still be consistent with an embodiment.

[0032] The processor 118 may be a general-purpose processor, a special-purpose 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), field programmable gate array (FPGA) circuitry, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 is coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts 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 transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0034] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may use MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0035] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate over multiple RATs, such as, for example, NR and IEEE 802.11.

[0036] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from 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). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Additionally, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from and / or store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

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

[0038] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0039] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, 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. The peripherals 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] The WTRU 102 may include a full-duplex radio, in which case transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the 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 to reduce and / or substantially eliminate self-interference by signal processing via hardware (e.g., a choke) or a processor (e.g., by a separate processor (not shown) or processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for transmitting and receiving some or all of the signals (e.g., associated with a particular subframe for the UL (e.g., for transmission) or downlink (e.g., for reception)).

[0041] 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As mentioned above, the RAN 104 may use E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

[0042] The RAN 104 may include eNodeBs 160a, 160b, and 160c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the eNodeBs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, the eNodeB 160a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0043] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown in FIG. 1C, the eNodeBs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0044] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is shown as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0045] The MME 162 is connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may handle authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that use other radio technologies, such as GSM and / or WCDMA.

[0046] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during handovers between eNodeBs, triggering paging when DL data becomes available to the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0047] The SGW 164 may be connected to a PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0048] The CN 106 may facilitate communication with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless communication networks owned and / or operated by other service providers.

[0049] Although in Figures 1A-1D the WTRU is described as a wireless terminal, it is contemplated that in some representative embodiments such a terminal may use (e.g., temporarily or permanently) a wired communication interface with the communication network.

[0050] In an exemplary embodiment, the other network 112 may be a WLAN.

[0051] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or from the BSS. Traffic to a STA originating from outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP and delivered to the destination. Traffic between STAs within a BSS may be sent, for example, through the AP, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs using direct link setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may have no APs, and the STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication is sometimes referred to herein as an "ad hoc" mode of communication.

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

[0053] A high-throughput (HT) STA may use a 40 MHz wide channel for communication, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form the 40 MHz wide channel.

[0054] A very high throughput (VHT) STA can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight adjacent 20 MHz channels or two non-adjacent 80 MHz channels, which can be called an 80+80 configuration. For 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 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).

[0055] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af also supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support meter-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices can have limited functionality, including support for some and / or limited bandwidths (e.g., only support for them). MTC devices can include batteries with above-threshold battery life (e.g., to maintain 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 a primary channel. The primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In an 802.11ah example, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only support) 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) setting can depend on the state of the primary channel. For example, if the primary channel is busy due to a STA (that only supports 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band remains idle and available.

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

[0058] 1D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As described above, the RAN 113 can communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 113 can also communicate with the CN 115.

[0059] The RAN 113 may include gNBs 180a, 180b, and 180c, although it will be understood that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, for example, the gNB 180a may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In an embodiment, the gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0060] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., including different numbers of OFDM symbols and / or lasting different lengths of absolute time).

[0061] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c can communicate with the gNBs 180a, 180b, 180c without further access to another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c can communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNBs 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNodeBs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput to serve the WTRUs 102a, 102b, 102c.

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

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

[0064] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and act as a control node. For example, the AMF 182a, 182b may handle authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling various PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, and the like. Network slicing can be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services utilizing Ultra-Reliable Low-Latency Communications (URLLC) access, services utilizing enhanced High-Capacity Mobile Broadband (eMBB) access, services for Machine-Type Communications (MTC) access, and / or the like. The AMF 182 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that use other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0065] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as managing and assigning IP addresses for WTRUs, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, and the like. The PDU session type may be IP-based, non-IP-based, Ethernet-based, and the like.

[0066] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks such as the Internet 110 to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184a, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

[0067] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. Additionally, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b via the UPFs 184a, 184b by an N3 interface to the UPFs 184a, 184b and by an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0068] 1A-1D , one or more, or all, of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functionality.

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

[0070] The one or more emulation devices may perform one or more, including all, functions but are not implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a test lab and / or in a test scenario in an undeployed (e.g., test) wired and / or wireless communication network to perform testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0071] New Radio (NR) can be operational with current and future mobile wireless communication systems. NR use cases can include, for example, eMBB, Ultra-Reliable Low-Latency Communications (URLLC), and Massive Machine-Type Communications (mMTC). NR can support transmissions in higher frequency bands, such as centimeter-wave (cm-wave) and / or millimeter-wave (mm-wave) frequencies. Operation in cm-wave and / or mm-wave frequency bands can present challenges related to propagation, for example, given high path loss and shadowing.

[0072] Highly reliable services may be supported by a very low block error rate, e.g., on the order of 0.001%. A low error rate may be achieved, for example, with high reliability for physical layer control information (e.g., hybrid automatic repeat request-acknowledgement (HARQ-ACK), uplink grants, and downlink assignments). In an example (e.g., for HARQ-ACK), a 0.1% level probability of misinterpreting a NACK as an ACK may be adequate for some (e.g., common) mobile broadband services, but may be too large for, e.g., ultra-reliable services (e.g., because the misinterpretation of a negative acknowledgment (NACK) for an ACK may result in the loss of a transport block).

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

[0074] For EN-DC, NR CA, and NR DC in licensed bands, various combinations (e.g., different combinations) of carriers may lead to various timing relationships (e.g., different timing relationships) between transmissions associated with a WTRU (or between transmissions that may at least partially overlap in time) with respect to one or more of numerology, transmission start time, or transmission duration. For example, each of the configured component carriers (downlink (DL) and / or uplink (UL)) and / or bandwidth portion (BWP) for a WTRU (DL and / or UL) may have the same or different numerology, 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) transmission durations.

[0075] For example, timing and / or scheduling aspects may be provided in the case of asynchronous transmissions and / or partial and / or full overlap between different uplink transmissions associated with the WTRU. In an example, different transmissions may operate on different HARQ timelines, e.g., based on dynamic scheduling information. For example, such scheduling information may include a dynamically variable scheduling delay component. The dynamically variable scheduling delay component 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 downlink (DL) data (PDSCH) reception and its corresponding ACK transmission on the uplink (UL). K2 may be the delay between reception of an UL grant on the DL and an UL data transmission (e.g., a PUSCH transmission). N1 may be, for example, the number of OFDM symbols used for WTRU processing from the end of NR-PDSCH reception to the earliest possible start of the corresponding ACK / NACK transmission, as seen by the WTRU. N2 may be, for example, the number of OFDM symbols used for WTRU processing from the end of the NR-PDCCH containing the UL grant reception to the earliest possible start of the corresponding NR-PUSCH transmission, as seen from the WTRU.

[0076] The scheduler can adjust the error probability of the control information, for example, by selecting a transmit power parameter (e.g., associated with an uplink transmission) and / or an aggregation level (e.g., associated with a downlink transmission). Achieving a very low error rate can be problematic.

[0077] In examples, very low error rates may not be achievable by parameter adjustment using transmission techniques, for example, in the presence of bursty interference and / or other channel impairments (e.g., severe shadowing at mm-wave frequencies, etc.).

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

[0079] Very low error rates (e.g., ultra-reliable service) can be achieved. Efficient operation with ultra-reliable and other (e.g., non-ultra-reliable) mobile broadband data traffic can be achieved (e.g., in the system and / or WTRU).

[0080] The uplink control information (UCI) may include, for example, HARQ feedback information (e.g., HARQ-ACK), a scheduling request (SR), and / or channel state information (CSI). The UCI may be transmitted via an uplink control channel (e.g., a physical uplink control channel (PUCCH)) and / or an uplink data channel (e.g., a physical uplink shared channel (PUSCH)). The UCI may be transmitted with or without multiplexing with uplink data. The HARQ feedback information (e.g., HARQ-ACK) may relate to a transport block, a code block, and / or a code block group.

[0081] Downlink control information (DCI) may refer to physical control signaling that may be received from the network (e.g., uplink grants, downlink assignments, power control commands, slot format indicators, HARQ information, and the like). DCI may 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 may be mapped to resources of a control resource set (CORESET). A WTRU may, for example, attempt to decode the PDCCH from one or more search spaces within the CORESET. A WTRU may, for example, be configured with at least one CORESET.

[0082] DCI diversity can be provided. In an example, transmission reliability of DCI can be increased by transmitting multiple DCI instances, e.g., over resources separated in the time, frequency, and / or spatial domains. The multiple instances can provide diversity gain against short-term fading, long-term fading, and / or interference.

[0083] The DCI (e.g., each DCI instance) may be transmitted via a downlink physical control channel (e.g., PDCCH, group-common PDCCH, PHICH, and the like). The instance may be transmitted via a PDSCH (e.g., when DCI on PDSCH may be supported). The PDCCH (e.g., each PDCCH) may be received based on a CORESET, which may be configured by higher layers. 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, subcarrier spacing, a subset of slots within a subframe, and / or one or more reference signals (e.g., CSI-RS). Independent configuration of one or more parameters may provide diversity in time, frequency, and / or space. In examples, frequency diversity may be provided (e.g., by configuring different component carriers or BWPs between CORESETs) with or without providing spatial and / or time diversity (e.g., by configuring different sets of time symbols and / or different reference signals).

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

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

[0086] In an example, each of the multiple DCI instances may include and encode the same information bits for at least one type or format of DCI (e.g., HARQ-ACK for PUSCH, PDSCH assignment, PUSCH grant), and the DCI may be decoded (e.g., fully decodable) from reception of an instance (e.g., a single instance).

[0087] In an example, the DCI may be encoded, for example, by segmenting the DCI into N blocks and encoding the DCI into D blocks. In an example, decoding (e.g., at a receiver) of at least N of the D DCI instances may be sufficient to recover the entire DCI. In an example, the encoding may consist of a parity code.

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

[0089] In an example, a WTRU may be configured to monitor the PDCCH via multiple CORESETs (e.g., two CORESETs). The WTRU may monitor the PDCCH on different carriers or bandwidth portions. The WTRU may, for example, receive multiple DCI instances (e.g., up to two DCI instances). In an example, a DCI instance may include the same information received by the WTRU via the PDCCH on multiple carriers (e.g., each carrier may be received on one carrier in the case of multiple DCIs). The information on the DCI (e.g., each DCI) may include PDSCH (or PUSCH) assignments / grant for multiple carriers (e.g., both carriers). The WTRU may, for example, receive the PDSCH or transmit the PUSCH on multiple carriers (e.g., both carriers) even if it fails to successfully decode a DCI instance (e.g., one of them). As shown in the example of Figure 2, for example, very low BLER can be achieved with low latency when multiple PDSCH transmissions (e.g., both PDSCH transmissions) or PUSCH transmissions can be encoded into the same transport block because the DCI and data can be independently protected (e.g., protected) by diversity. 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 of the DCIs can include information associated with the PDSCH 206 and the PDSCH 208.

[0090] A DCI index may be provided. In an example, a DCI instance (e.g., each DCI instance) may include a field (e.g., a DCI index) that may identify DCI content. The WTRU may discard DCI instances that may contain the same information. Identical DCIs may be discarded to reduce processing. In an example, a WTRU may receive a first DCI instance having a first value of a DCI index. The WTRU may receive subsequent DCI instances that may include the same value of a DCI index (e.g., those in a CORESET set for which DCI diversity may be configured within a time period). The WTRU may discard (e.g., upon receipt) the subsequent DCI instances. The WTRU may use the DCI index, for example, to distinguish between diversity DCI and DCI that may contain new information.

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

[0092] In an example, a UCI instance may be transmitted over multiple carriers and / or bandwidth portions, and the WTRU may be configured to operate on it. As shown in FIG. 3, the same HARQ-ACK information, which may relate to a downlink assignment (e.g., received in a previous slot 302), may 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, which may be transmitted on UL component carrier 1 (CC1) 310, and a second UCI instance 308, which may be transmitted on UL component carrier 2 (CC2) 312. The UCI may be transmitted in slot 2 304. Each of the first UCI instance 306 and the second UCI instance 308 may include similar information (e.g., the same HARQ ACK-NACK information).

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

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

[0095] The information used by the WTRU for beam determination may be derived (e.g., implicitly derived) from the PDCCH, which may include an assignment. In an example, a beam associated with a 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 beam indicator associated with the PDCCH transmission, which may include an assignment. This approach may be used, for example, when PDCCH diversity (or DCI diversity) can be used in addition to UCI diversity. The WTRU may transmit a PUCCH instance (e.g., one PUCCH instance) for a received PDCCH instance (e.g., for each received PDCCH instance). The PDCCH instance may include, for example, an assignment of when and / or how UCI may be transmitted via the PUCCH.

[0096] A supplemental uplink (SUL) may be provided. In an example, the WTRU may be configured with an SUL carrier for at least one serving cell. The WTRU may be configured to transmit UCI, including, for example, a scheduling request (SR), channel state information (CSI), or HARQ ACK / NACK. The UCI may be transmitted over a normal UL carrier and an SUL carrier associated with the serving cell.

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

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

[0099] In an example (e.g., when DCI diversity cannot be applied), the UCI may include a set of HARQ-ACK bits. An association between a particular HARQ-ACK bit and the reception result of a transport block may be determined based on, for example, a downlink assignment index.

[0100] In an example (e.g., when DCI diversity is applicable), a set of HARQ-ACK bits may be generated and transmitted for each DCI instance that may be configured to be received with diversity (e.g., based on the same content). This may be done, for example, regardless of whether the DCI instance may be successfully decoded. For example, the WTRU may be configured to receive multiple DCI instances (e.g., two DCI instances) with diversity, but may report a NACK for a transport block corresponding to a DCI instance that it cannot receive when it receives fewer than the configured DCI instances (e.g., the two configured DCI instances). The reporting may be performed, for example, when the WTRU receives at least one DCI instance. The network may determine lost allocations from the DCI instances (e.g., each DCI instance). Determining the lost allocations may be useful for link adaptation of the PDCCH.

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

[0102] The WTRU may receive multiple DCIs, which may indicate DL data for the same HARQ process and transport block. The DCIs may be encoded with different redundancy versions. The WTRU may report one HARQ-ACK bit per transport block (e.g., regardless of the number of received instances of PDSCH that may contain data for the transport block). The WTRU may send the HARQ-ACK bit per transport block and the PDSCH instance (e.g., with the same value) that may contain the data for the transport block.

[0103] Power control using UCI diversity can be provided. The transmit power associated with a transmission (e.g., a PUCCH transmission or a PUSCH transmission) 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 using UCI diversity to determine transmit power control (TPC) may be provided. The WTRU may determine TPC commands applicable to a transmission for which UCI diversity may be applied.

[0105] In an example determination of TPC, the WTRU may apply similar TPC adjustments to each of multiple UCI instance transmissions. The TPC adjustments may be received, for example, from a DCI that may be associated with the UCI transmission. For example, the DCI may include a DL allocation or a CSI request.

[0106] In an example determination of TPC, the 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, for example, via a DCI that may be associated with the UCI transmission. In an example, the associated DCI may include two TPC adjustment values, for example, if UCI diversity may be configured with two transmissions.

[0107] In an example determination of TPC, the WTRU may apply a separate TPC adjustment to each UCI instance transmission, which may be received for each UCI instance, for example, via a particular DCI instance that may be associated with the UCI instance.

[0108] Power control may be provided with a power control mode, such as for carrier aggregation (CA) and / or dual connectivity (DC). In an example, the WTRU may apply a priority level to transmissions that may include UCI, e.g., when UCI diversity is activated. The WTRU may apply the priority level, e.g., when configured in power control mode (PCM). The WTRU may be configured to group one or more types of transmissions. The WTRU may be configured, e.g., to allocate at least a certain amount (e.g., a portion) of the total WTRU-available power to a group of transmissions that uses a minimum guaranteed power. The WTRU may determine that transmissions that include UCI are part of the same group of transmissions. The WTRU may implement such grouping, e.g., when the UCI is associated with a transmission profile. For example, such a transmission profile may correspond to an ultra-reliable, low-latency communication (URLLC) type of transmission. The WTRU may assign a higher priority to such a group of transmissions than other data transmissions (e.g., data transmissions associated with a transmission profile corresponding to a non-URLLC type of transmission). For example, in a WTRU configured with CA, a transmission that includes at least some UCI generated when applying UCI diversity may have the highest priority over other transmissions for a given MAC instance. For example, in the case of a WTRU configured with DC and / or multiple transmission groups, a group of transmissions (or cell group) that has at least one transmission (e.g., generated when applying UCI diversity) that includes at least some UCI may have the highest priority over other groups.

[0109] The resource allocation may comprise UCI diversity using the PUCCH. The resources and format of the PUCCH transmission may be determined, for example, according to one or more example procedures (e.g., when a UCI instance is transmitted via the PUCCH). In an example, a WTRU may be configured with one or more combinations of PUCCH resources. A PUCCH resource (e.g., each PUCCH resource) may correspond to a resource over which a UCI instance may be transmitted. In an example (e.g., with two UCI instances), a combination may be defined as PUCCH resource index #24 on a first CC or bandwidth portion and PUCCH resource index #13 on a second CC or bandwidth portion. The combination may be referred to as a PUCCH diversity resource or a PUCCH diversity super resource. A WTRU may be configured (e.g., by higher layers) with multiple PUCCH diversity resources. The PUCCH diversity resources may be indicated in a field of the associated DCI (e.g., an ARI field). A WTRU may be configured (e.g., by higher layers) with a pool. The pool may include normal PUCCH resources and PUCCH diversity resources that allow the network to control (eg, dynamically control) the use of UCI diversity.

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

[0111] Transmission of DTX feedback may be provided. In an example, the WTRU may transmit HARQ-ACK information on a particular PUCCH resource. The HARQ-ACK may indicate (e.g., explicitly indicate) that no DL transmission or DL ​​assignment has been received from a particular CORESET in a given slot or minislot (e.g., in the case of discontinuous transmission (DTX)). The timing of the PUCCH resource may be obtained, for example, from the timing of the slot or minislot in which no DL assignment was received.

[0112] PUCCH interference randomization may be provided. In an example, PUCCH transmissions from two or more WTRUs to two or more transmit / receive points (TRPs) may collide. For example, interference randomization may be used to reduce the impact of a strongly interfering PUCCH transmission on a victim PUCCH transmission. For example, interference randomization may be used by pairs of WTRUs not using colliding PUCCH resources.

[0113] Interference randomization may be utilized to increase transmit diversity. The interference randomization may include, for example, one or more of the following hopping resources: hopping a transmit beam or beam pair, hopping a PUCCH symbol within or across slots, or hopping a replication pattern.

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

[0115] In an example of transmit beam or beam pair hopping, the PUCCH transmission can cycle through a set of beams. In an example, cycling through beams can be implemented, for example, using a beam for each set of PUCCH symbols within a PUCCH transmission. In an example of PUCCH symbol hopping within or across slots, for each of multiple PUCCH transmissions, a short PUCCH can occupy a different symbol of the slot.

[0116] In an example of a hopping duplication pattern, a PUCCH transmission (e.g., each PUCCH transmission) may use multiple duplications. Each of the duplications may use different resources. Subsequent PUCCH transmissions (e.g., each subsequent PUCCH transmission) may use a different set (e.g., a separate set) of resources. The different sets of resources may be used to allow for multiple duplications.

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

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

[0119] The configuration of the PUCCH resource may include, for example, (i) the PUCCH format (e.g., short PUCCH format or long PUCCH format), (ii) the PUCCH duration in symbols (e.g., one or two symbols for short PUCCH and long PUCCH duration, etc.), (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 numerology used for PUCCH (e.g., subcarrier spacing, CP type, etc.), (v) the time location (e.g., the symbol location within the slot where the PUCCH may be transmitted), (vi) the frequency location (e.g., subcarrier, PRB, bandwidth portion (BWP)), (vii) the frequency index (FOR), and (viii) the PUCCH duration in symbols (e.g., one or two symbols for short PUCCH and long PUCCH duration). This may include one or more of the following: an interlace index (e.g., used to enable FDM of multiple PUCCHs on the same PRB or BWP, in which case the PUCCH transmissions can be assigned to one or more interlaces within the PRB or BWP); (viii) a hopping pattern (e.g., to hop within or across PUCCH transmissions); (ix) a beam or beam pair; (x) a duplication pattern (e.g., for PUCCH transmissions that may be duplicated across multiple resources); (xi) an orthogonal cover code (OCC) (e.g., which may include whether the OCC is applied over time or for subcarrier elements); (xii) a cyclic shift; or (xiii) a transmit diversity scheme.

[0120] The frequency location may include, for example, a frequency allocation at which the PUCCH can be transmitted. The frequency location may be provided, for example, as an offset value. The offset may be applied, for example, to the frequency location of the PDCCH or PDSCH to which the PUCCH can be configured, or to which the PDCCH or PDSCH is assigned. The offset may be applied to the frequency location of the concurrent PUSCH. The frequency location may include, for example, a set of subcarriers, PRBs, and / or BWPs. The set may be used to indicate (e.g., dynamically indicate) a frequency location for a PUCCH transmission instance (e.g., each PUCCH transmission instance). For example, the set may be used to enable frequency diversity through repetition. For example, the set may be used to enable frequency hopping.

[0121] The configuration (e.g., including a duplication pattern) may include a set of resources on which the PUCCH transmission may be duplicated. Different duplication patterns may be selected (e.g., dynamically selected).

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

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

[0124] The implicit indication 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 slot size example, 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 slot UL / DL configuration example, the WTRU may determine the PUCCH type (e.g., short or long) or long PUCCH duration based on, for example, the number of symbols allocated to the UL transmission. In the service type example, URLLC may include a PUCCH format for HARQ that enables higher reliability. In an example, URLLC transmission may request PUCCH diversity. In a UCI multiplexing example, a HARQ transmission combined with multiple TBs (e.g., due to multiple carriers or slot aggregation) may have a higher payload PUCCH format. In an example of feedback timing, feedback timing with an offset less than a threshold may use a first PUCCH table, while feedback timing with an offset greater than a threshold may use a second PUCCH table. In an example, a short PUCCH may be used for self-contained slots, e.g., where feedback may be provided in the same slot as DL data. In an example of feedback type, HARQ feedback may use a first PUCCH configuration, while CSI may use a second PUCCH configuration. In an example, transport block (TB)-based HARQ feedback may use a first PUCCH configuration (e.g., a short PUCCH), and code block group (CBG)-based HARQ feedback may use a second PUCCH configuration. In an example of conflict between different feedback types (e.g., associated with different service types), the PUCCH configuration for the service type with a higher priority may be used.In an example, feedback multiplexing can be used for PUCCH configuration for URLLC services, eg, when eMBB HARQ feedback may collide with URLLC HARQ feedback.

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

[0126] PUCCH transmissions may be multiplexed. In an example, a WTRU may be configured to multiplex multiple PUCCH transmissions. Multiplexing may be achieved, for example, by allocating multiple PUCCH transmissions on the same resources. The WTRU may be assigned a different frequency interlace, hopping pattern, and / or orthogonal cover code (OCC) for each of the multiple PUCCH transmissions.

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

[0128] Differentiated processing may be provided. Determination of a profile applicable to a transmission may be provided. The WTRU may, for example, process and transmit the UCI according to a transmission profile (e.g., a determined transmission profile) that may be associated with the UCI. The transmission profile may, for example, be determined such that the amount and prioritization of resources can meet a reliability objective for the UCI. Such determination of the transmission profile enables efficient utilization of resources.

[0129] In an example, a transmission profile may be associated with uplink data or sidelink data. For example, a transmission profile associated with uplink data or sidelink data may be used to enable prioritization between uplink data or sidelink data and UCI of different profiles.

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

[0131] The transmission profile associated with the UCI or uplink data may, for example, include the following: (i) the logical channel or logical channel group over which the data may be transmitted based on higher layer configuration (e.g., a transmission profile may be configured for each logical channel or logical channel group, or the WTRU may determine the transmission profile based on the configuration of the logical channel (LCH) to one or more physical layer characteristics for a given transmission, such as, for example, transmission duration or the like); (ii) the logical channel or logical channel group of the data that triggered the SR; (iii) the value of a field in the DCI that may be associated with the transmission of the UCI or uplink data (e.g., an explicit indication of the transmission profile, or implicitly from an existing field (e.g., HARQ process index), or from a field that may be used for logical channel prioritization (e.g., for uplink grants), or a Radio Network Temporary Identifier (RNTI) value that may be used to mask a cyclic redundancy check (CRC)); (iv) the transmission profile (v) characteristics of a PDCCH that can be associated with UCI or uplink data transmission (e.g., CORESET, monitoring period, decision on 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), such as when the file can be configured (e.g., by higher layers) for a CORESET (e.g., each CORESET) or for a PDCCH configuration (e.g., each PDCCH configuration); (v) higher layer signaling (e.g., for CSI) and / or fields in DCI that can indicate a set of parameters, e.g., configured by higher layers (e.g., CSI reporting setting that can be indicated by a non-periodic CSI field); (vi) characteristics of or associated with a PDSCH transmission, such as duration, bandwidth portion, numerology characteristics (e.g., subcarrier spacing, symbol duration, etc.), transmission configuration indication (TCI) state (e.g., for HARQ-ACK), control information (e.g., in DCI) associated with a PDSCH transmission;or an indicated modulation and coding scheme (MCS) table, (vii) characteristics of or associated with the PUCCH resource configured for SR transmission (such as subcarrier spacing, duration of the PUCCH resource, logical channel associated with the SR configuration, or its characteristics such as priority, and / or a transmission profile explicitly configured as part of the SR configuration), (viii) characteristics of or associated with the grant or PUSCH transmission (e.g., for uplink data), e.g., characteristics used to determine logical channel restrictions for logical channel prioritization (such as the duration of the PUSCH transmission, numerology characteristics (e.g., subcarrier spacing, symbol duration), or carrier characteristics), or (ix) the bandwidth portion over which the associated PDSCH or PUSCH transmission is transmitted. Regarding (iv), the transmission profiles can have a priority based on a configured priority order. For example, the transmission profiles can have a priority based on a configured priority order if a PDCCH candidate is part of a search space associated with multiple transmission profiles. Regarding (i), the transmission profile associated with the UCI may be determined based on attributes (e.g., QoS metrics) associated with a logical channel or logical channel group from which data may be transmitted. Regarding (v), a BLER target value may be configured for a CSI reporting configuration. The BLER target value may implicitly indicate a transmission profile. For example, a low BLER target value may indicate a high-priority transmission profile. In an example, a CQI reporting table may be configured for a CSI reporting configuration.

[0132] The transmission profile for the DCI or downlink data may be determined based on, for example, one or more of the following: (i) characteristics of the PDCCH from which the DCI may be decoded or from which an allocation for downlink data may be decoded (e.g., search space, explicit configuration, etc.), e.g., as disclosed herein with respect to UCI or uplink data; (ii) a modulation and coding scheme (MCS) table indicated for control information associated with the PDSCH transmission (e.g., in the DCI); such an indication may be configured by higher layers or may be included in a field of the DCI; (iii) a value of a field in the DCI that may be associated with the transmission of downlink data or an RNTI value that may be used to mask the CRC; or (iv) characteristics of or associated with the allocation or PDSCH transmission (e.g., for downlink data), such as characteristics of the duration and / or numerology (e.g., subcarrier spacing, symbol duration, etc.) of the PDSCH transmission.

[0133] In an example, a transmission profile for a physical channel (e.g., a PDCCH, a PUCCH, a PDSCH, or a PUSCH) may be defined. The transmission profile may be determined, for example, based on the type of data or control information that may be conveyed by the physical channel. The transmission profile may be set, for example, based on the highest priority level among the profiles when the physical channel transmission includes control information and / or data of different profiles (e.g., UCI multiplexed onto a PUSCH).

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

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

[0136] In an example, the WTRU may determine from the transmission 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 may be determined may include one or more of the following: (i) a type of code (e.g., polar, LDPC, turbo, repetitive), (ii) a code rate, (iii) a cyclic redundancy check (CRC) length that may be appended to a set of information bits for error detection, (iv) a mapping between a modulation coding scheme field and a modulation order and code rate, or (v) one or more search spaces for one or more aggregation levels for decoding the PDCCH.

[0137] In an example, the WTRU may be configured with a 16-bit CRC for the PDCCH, for example, when the higher layer configuration for the PDCCH may indicate a first transmission profile. The WTRU may be configured with a 24-bit CRC, for example, when the configuration may indicate a second transmission profile. For example, using a variable CRC size may allow the network to use more reliable PDCCH transmissions, as may be required by the characteristics of the data being transmitted.

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

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

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

[0141] In an 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 higher layers, the WTRU may apply a first set of power control parameters. If the PDSCH transmission is above the threshold, the WTRU may apply a second set of power control parameters.

[0142] In an 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) on which the HARQ-ACK is transmitted or on the DL bandwidth portion on which the corresponding PDSCH is transmitted, each bandwidth portion may be configured by higher layers with a set of power control parameters.

[0143] In an example, power control parameters applied to transmission of CSI over PUCCH (or PUSCH) may depend on a BLER target value configured for a CSI reporting configuration. For example, the WTRU may apply a power offset based on the BLER target value. The BLER target value may be configured, for example, by higher layers for each of the BLER target values. A power offset may be configured, for example, for each CSI reporting configuration.

[0144] Data or UCI for multiple transmission profiles can be multiplexed into the same transmission, and power control parameters for the common transmission can be determined based on the profile, e.g., the profile with the highest priority level.

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

[0146] For example, resource selection or allocation may be determined based on a transmission profile. In an example, resources and / or formats that may be used by a transmission may depend on the transmission profile. For example, for PUCCH, the set of resources indicated by the ARI and / or the format may depend on the transmission profile. The network may configure at least one set of resources for a transmission profile, e.g., each transmission profile. A set of resources that may experience low interference may be associated with a transmission profile that can be used for more reliable transmission.

[0147] In an example, using a long or short PUCCH format and / or a number of symbols may correspond to a transmission profile. In an example, a WTRU may be configured to transmit the PUCCH over multiple symbols (e.g., two symbols) for a transmission profile (e.g., a first transmission profile) that may be appropriate for ultra-reliable traffic. The WTRU may be configured to transmit the PUCCH over a symbol (e.g., one symbol) for another transmission profile (e.g., a second transmission profile) that may be appropriate for other, non-ultra-reliable mobile broadband traffic.

[0148] In examples, the set of bandwidth portions and numerology (e.g., including one or more of subcarrier spacing, cyclic prefix length, or number of symbols per slot or minislot) may be used for downlink or uplink transmission within a carrier and may depend, for example, on a transmission profile.

[0149] In an example, the waveform can depend on the transmission 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 an example, the use of frequency hopping can depend on the transmission profile.

[0150] In an example, for at least one type of UCI (e.g., HARQ-ACK), the UCI may be transmitted via a PUCCH or multiplexed with data transmitted via a PUSCH. The selection of whether the UCI is transmitted via a PUCCH or multiplexed with data transmitted via a PUSCH may be made according to a transmission profile associated with the UCI and the data. In an example, for example, when the UCI and the data may have the same transmission profile or the same priority level associated with the transmission profile, the UCI may be multiplexed with data via a PUSCH. The UCI may be transmitted separately via a PUCCH. In an example, at least one type of UCI (e.g., channel state information (CSI)) may be excluded.

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

[0152] In an example, the WTRU may determine whether UCI diversity is applied. For example, the SR configuration may include a configuration of PUCCH resources (or PUCCH diversity resources) applicable to UCI diversity. For example, when SR is triggered by a logical channel (LCH) mapped to such an SR configuration, the WTRU may transmit the SR via multiple PUCCH resources (or PUCCH diversity resources).

[0153] Prioritization among transmissions can be provided. In an example, a priority level can be defined or configured for a transmission profile (e.g., each transmission profile). The priority level can be used, for example, to determine whether one or more transmissions can be excluded or aborted, scaled back, allocated fewer resources, or processed at a later time when a conflict exists. The occurrence of a conflict can be beneficial (e.g., from a system perspective), for example, by allowing a greater percentage of system resources to be used (e.g., compared to a situation where resources may be reserved).

[0154] Prioritization may be provided for power scaling. In an example, the WTRU may, for example, scale back at least one transmission when a configured total maximum power is likely to be exceeded during a period of time (e.g., during a subframe, slot, or minislot). The order of priority for scaling may depend on the transmission profile (e.g., in addition to other criteria such as UCI or data type). In an example, the transmission profile criteria may override or supersede other criteria. In an example, if a first transmission profile has a higher priority level than a second transmission profile, a PUSCH that may include data transmitted according to the first transmission profile may be allocated power before a PUCCH that may include a HARQ-ACK transmitted according to the second transmission profile. Prioritization based on using a transmission profile may be applied even if the HARQ-ACK would otherwise be prioritized over data.

[0155] Prioritization can be provided to exclude transmissions, or at least portions of transmissions. In an example, a WTRU can determine that multiple transmissions may overlap across a subset of resources and can exclude or interrupt at least a portion of at least one of the transmissions, e.g., based on a transmission profile associated with the overlapping transmissions. The WTRU can, for example, determine that the transmission having the highest priority (e.g., based on the transmission profile) can be transmitted over the resource.

[0156] The overlapping may result, for example, from scheduling instructions that may be received at different times and with different latency requirements. In an example, a WTRU may receive a downlink assignment that may require transmission of a HARQ-ACK over a PUCCH in several symbols of a certain slot. The WTRU may receive a grant (e.g., subsequently receive a grant) for a PUSCH transmission for the same slot. The WTRU may determine that a PUSCH transmission takes priority over a PUCCH transmission, for example, when a transmission profile associated with uplink data that may be transmitted over a PUSCH has a higher priority level than a transmission profile associated with a HARQ-ACK that may be transmitted over a PUCCH. Based on such a determination, the WTRU may use the overlapping resources for the PUSCH transmission and may exclude the PUCCH transmission. In an example, the WTRU may transmit a PUCCH over the overlapping resources. The WTRU may use the remaining resources that may be indicated for the PUSCH, for example, to account for the reduced amount of resources in a rate-matching calculation.

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

[0158] In an example, a WTRU may receive a grant for a PUSCH over a slot. The WTRU may receive (e.g., subsequently receive) a downlink assignment (or trigger a scheduling request) that may require transmission of a PUCCH over one or more resources of the same slot (e.g., over the last time symbol for a short PUCCH or over one or more time symbols (e.g., most or all of the time symbols) available on the uplink for a long PUCCH). The WTRU may determine that the PUCCH can be transmitted over overlapped resources, for example, when the PUCCH includes UCI associated with a higher transmission profile than the data transmitted over the PUSCH. The WTRU may exclude the PUSCH or determine that the PUSCH can be transmitted over non-overlapping resources, for example, with puncturing applied to the overlapped resources. The course of action may depend on the type of transmission to interrupt (e.g., PUSCH can still be transmitted when interrupted by a short PUCCH) and / or whether the percentage of interrupted resources exceeds a threshold.

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

[0160] Prioritization for DL ​​data processing may be provided. In an example, a WTRU may be scheduled to receive DL data with different transmission profiles via at least one PDSCH and may report HARQ-ACKs associated with the DL data (e.g., at specific times). The WTRU may not be able to complete decoding of at least one code block within the time for the corresponding HARQ-AC transmission. The WTRU may, for example, prioritize decoding of high priority DL data according to the transmission profile associated with the DL data.

[0161] In an example, a HARQ-ACK may be transmitted for a transport block before decoding of at least one code block group is complete. Depending on the transmission profile associated with the data, the WTRU may configure the HARQ-ACK using one of the following methods: The WTRU may set the HARQ-ACK for a code block group that has not yet been decoded to ACK, e.g., when decoding may be completed, and may set it to NACK for at least one other code block group of the transport block. The WTRU may set the HARQ-ACK for one or more code block groups other than those that may be set to NACK to ACK. This may minimize the amount of resources that may be used for retransmissions by the network, e.g., when some not-yet-decoded code blocks may be successful and not require retransmission. This example procedure may be selected, e.g., for a transmission profile that may have a low priority.

[0162] In an example, the WTRU may set the HARQ-ACK for code block groups that have not yet been decoded to NACK. This may minimize the latency of transport block delivery, e.g., making retransmitted data available sooner, e.g., in the event that the decoding result may be unsuccessful. This example procedure may be selected for a transmission profile that may have a high priority, for example.

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

[0164] The payload / MCS selection can be based on prioritization. In an example, the WTRU can be configured to use a first modulation and coding scheme, transport block size, and / or payload for a transmission, e.g., if the transmission does not conflict with a higher priority transmission according to the transmission profile. The WTRU can be configured to use a second modulation and coding scheme, transport block size, or payload for a transmission, e.g., if the transmission conflicts with a higher priority transmission according to the transmission profile. A conflict can correspond to a situation, e.g., when resources of multiple transmissions overlap or when the configured maximum total transmit power may be excessive.

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

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

[0167] In an example, a WTRU may receive a DCI indicating a change in an active bandwidth portion (e.g., in which case the new active bandwidth portion and the existing active bandwidth portion may share the same configuration except for at least the transmission profile and associated parameters). For example, the WTRU may 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 (e.g., that meets this condition), the WTRU may receive a PDSCH in the same slot in which the DCI was received based on the parameters indicated in the DCI (e.g., as if there was no change in the active bandwidth portion). In an example, if the WTRU receives an indication of an active bandwidth portion in which the new active bandwidth portion does not have the same frequency allocation as the existing active bandwidth portion, the WTRU may apply a gap in reception of the PDSCH (e.g., to allow for retuning and / or to perform other actions (e.g., CSI measurements on the new active bandwidth portion, etc.)).

[0168] Systems, methods, and means may be provided for handling transmission characteristics having overlap between multiple transmissions. A WTRU may determine that overlap exists in the time between multiple transmissions, e.g., between a first transmission and a second transmission. The WTRU may do at least one of the following: (1) perform a subset (e.g., one) of the transmissions; (2) cancel, exclude, or suspend one of the transmissions (e.g., if already in progress); (3) suspend and / or delay one of the transmissions; (4) perform both transmissions and / or apply a power scaling function to at least one transmission, e.g., if there is no overlap in frequency between the transmissions; or (5) modify at least one characteristic of the first transmission, e.g., to convey at least a portion of the information that would otherwise be conveyed using the second transmission. For example, the WTRU may modify characteristics of a demodulation reference signal (DM-RS) for the first PUSCH transmission to indicate a scheduling request (SR). The modifications may include, for example, allocating zero power, changing to a second pre-configured resource, changing the phase, etc. The WTRU may perform such actions in combination with allocating zero power to a second transmission that would otherwise overlap in time, such as an SR on a 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 the PUSCH or PUCCH. The 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 a transmission, such as a PUSCH or PUCCH transmission, associated with the second transmission profile. In an example, the first transmission profile may have a higher priority than the second transmission profile. In an example, the duration of the 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 the PUSCH or PUCCH transmission may be such that waiting for the end of the PUSCH or PUCCH transmission before transmitting the SR may exceed a latency value (e.g., an acceptable latency value).

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

[0171] The at least one characteristic of the transmission that may be modified may include a transmit power parameter of at least one time symbol (or resource element). For example, the transmit power of at least one symbol may be reduced when an SR is transmitted compared to the transmit power of the remaining symbols. In an example, the transmit power of at least one symbol may be reduced to zero, and / or the WTRU may not transmit on at least one symbol. This allows the network to reliably detect the transmission of the SR and enable successful decoding of the PUSCH.

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

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

[0174] Systems, methods, and means may be provided for processing transmission characteristics based on timing that may be provided. For example, one or more aspects may be determined depending on available WTRU processing, such as WTRU processing time.

[0175] The WTRU may determine that it can apply at least one prioritization or multiplexing solution, which may, for example, take into account the following: (1) timing aspects of when data is available for transmission or when data applicable for transmission can trigger the transmission of a BSR and / or an SR, (2) timing aspects of when a scheduling request (SR) can be triggered, (3) timing aspects of when downlink control information indicating an uplink transmission (e.g., a PUSCH transmission or a PUSCH transmission) can be received, (4) timing aspects of receiving higher layer signaling, e.g., at least in the case of a configured grant or in the case of another periodic or semi-persistent transmission (e.g., CSI, SRS, etc.), and (5) timing aspects of when a configured grant can be received. The timing aspect may be dependent on one or more timing aspects including at least one of: (5) a timing aspect regarding when a PUSCH transmission may be scheduled to start (and / or end) according to a grant made or dynamic, (6) a timing aspect regarding when a PUCCH transmission may start (and / or end), e.g., according to a semi-static configuration or an indication in downlink control information, (7) a duration of a PUSCH or PUCCH transmission, or (8) a timing aspect regarding when a transmission may be determined to occur in the future for any other reason, e.g., reception of a paging request, initiation of a procedure such as RRC connection re-establishment, etc. For example, in the case of (1), the WTRU may perform such a determination when new data becomes available for transmission for a logical channel (LCH) of a particular priority and / or type, or when data available for transmission may trigger transmission of a buffer status report (BSR) and / or transmission of an SR. The WTRU may make such a determination for data associated with a mapping restriction (eg, LCH to transmit mapping restriction), a profile, and / or an LCH / logical channel group (LCG) priority.

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

[0177] The WTRU may perform a first action 1 (action 1) or a second action (action 2), for example, if the WTRU determines that a first event (event A) occurs at least x symbols in time before the start of event B (event B). Event B may be a known event.

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

[0179] In action 1, the WTRU may determine that sufficient time is available to act on the scheduled information and / or prioritize one of the two events before the lower priority event starts. In action 2, the WTRU may determine that there is not enough time before the lower priority event starts to adjust its transmission and / or prioritize one of the two events, and may therefore decide to modify the characteristics of the corresponding ongoing transmission instead. The WTRU may be configured, e.g., by RRC, with a value of x, where x may be, e.g., a time value of a symbol in framing units (e.g., minislots, slots, subframes) or a time value in absolute time, e.g., milliseconds.

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

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

[0182] In an example, one of the transmissions may correspond to a first transmission profile or the like, e.g., URLLC service, and another may correspond to a second transmission profile, e.g., 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 determination before any of the at least partially overlapping transmissions start, the WTRU may prioritize the following for different combinations of signals: (1) the WTRU may prioritize SR (for URLLC) and exclude PUSCH (for eMBB); (2) the WTRU may prioritize UCI (for URLLC) using a similar concatenation principle as used, e.g., for UCI on PUSCH for LTE. (3) the WTRU may pad the transmission, e.g., by removing part of the PUSCH (for eMBB) and replacing it with an sPUSCH (including BSR (for URLLC)); (4) the WTRU may signal the SR using modifications to the DM-RS sequence of the PUSCH (for eMBB); (5) the WTRU may adjust the UL PC, e.g., by applying power scaling, e.g., if the WTRU is power-limited.

[0183] In an example, when the WTRU determines that there is not enough processing time (e.g., the time between two events is less than x), or if the WTRU does not make this determination before starting any one of the at least partially overlapping transmissions, the WTRU may perform at least one of the following for different combinations of signals: (1) the WTRU may interrupt / disturb or puncture the ongoing PUSCH (for eMBB) and the WTRU may transmit an SR (for URLLC) using the associated resource, e.g., on a short PUCCH instead, e.g., transmit a BSR (for URLLC), e.g., transmit a short PUSCH (for URLLC) instead, and / or transmit a URLLC TB, e.g., transmit a short PUSCH (for URLLC) instead, (2) the WTRU may signal the SR with a DM-RS sequence change for the ongoing PUSCH (for eMBB), and (3) the WTRU may adjust the UL PC accordingly (e.g., for boosting DM-RS).

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

[0185] The WTRU may allocate power using one or more power control functions. The WTRU may consider transmissions that may be transmitted at least partially overlapping in time, for which the WTRU may not have made a decision whether to transmit. The WTRU may include the following factors in making a decision whether to transmit such a transmission: the priority of each in the power allocation function, the method, and / or the resources that may be used if implemented, for example, for a maximum power reduction (MPR) setting.

[0186] The systems and / or methods described herein may be implemented in a computer program, software, and / or firmware embodied in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media may include electronic signals (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media may include 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 versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, a terminal, a base station, an RNC, and / or any host computer. [Industrial Applicability]

[0187] The present invention can be used in wireless communication.

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: receiving configuration information indicating a first set of one or more parameters associated with resource allocations for first uplink control information (first UCI) associated with a first priority and a second set of one or more parameters associated with resource allocations for a second UCI associated with a second priority; receiving information indicating that the first UCI associated with the first priority will be transmitted, the first UCI being transmitted in a physical uplink shared channel transmission (PUSCH transmission); a receiver configured to: a processor configured to determine an amount of resources for the PUSCH transmission to be allocated to a first UCI based on the first set of one or more parameters associated with resource allocation for the first UCI associated with the first priority; and a transmitter configured to transmit the first UCI using the amount of resources for the PUSCH transmission determined based on the first set of one or more parameters associated with a resource allocation for the first UCI associated with the first priority; A WTRU comprising:

2. the receiver is further configured to receive information indicating that the second UCI associated with the second priority will be transmitted, the second UCI being transmitted in a second PUSCH transmission; The processor is further configured to determine an amount of resources for the second PUSCH transmission to be allocated to the second UCI based on the second set of one or more parameters associated with a resource allocation for the second UCI associated with the second priority; The transmitter is further configured to transmit the second UCI using the amount of resources for the second PUSCH transmission determined based on the second set of one or more parameters associated with a resource allocation for the second UCI associated with the second priority. The WTRU of claim 1.

3. The WTRU of claim 1 , wherein the first priority is associated with a first transmission profile and the second priority is associated with a second transmission profile.

4. 2. The WTRU of claim 1, wherein the first set of one or more parameters associated with resource allocation for the first UCI associated with the first priority includes a first set of one or more beta parameters for multiplexing the first UCI associated with the first priority onto PUSCH resources, and the second set of one or more parameters associated with resource allocation for the second UCI associated with the second priority includes a second set of one or more beta parameters for multiplexing the second UCI associated with the second priority onto PUSCH resources.

5. 5. The WTRU of claim 4, wherein the first set of one or more beta parameters is associated with a greater proportion of PUSCH resources allocated for transmission of the first UCI than the second set of one or more beta parameters, and the first priority is a higher priority than the second priority.

6. 2. The WTRU of claim 1, wherein the information indicating that the first UCI is associated with the first priority comprises downlink control information (DCI) received in a physical downlink control channel transmission, the DCI including a field indicating the first priority.

7. 2. The WTRU of claim 1, wherein the first UCI is multiplexed with uplink data associated with the first priority in the PUSCH transmission.

8. 2. The WTRU of claim 1, wherein the first UCI includes a scheduling request, and the information indicating that the first UCI is associated with the first priority includes information indicating that a logical channel associated with the scheduling request is associated with the first priority.

9. The WTRU of claim 1 , wherein the amount of resources for the PUSCH transmission to be allocated to the first UCI includes a number of resource elements.

10. 2. The WTRU of claim 1, wherein the information indicating that the first UCI is associated with the first priority comprises configuration information received via higher layer signaling.

11. 1. A method for transmitting uplink control information (UCI), comprising: receiving configuration information indicating a first set of one or more parameters associated with resource allocations for first uplink control information (first UCI) associated with a first priority and a second set of one or more parameters associated with resource allocations for a second UCI associated with a second priority; receiving information indicating that the first UCI associated with the first priority will be transmitted, the first UCI being transmitted in a physical uplink shared channel transmission (PUSCH transmission); determining an amount of resources for the PUSCH transmission to be allocated to a first UCI based on the first set of one or more parameters associated with resource allocation for the first UCI associated with the first priority; transmitting the first UCI using the amount of resources for the PUSCH transmission determined based on the first set of one or more parameters associated with a resource allocation for the first UCI associated with the first priority; A method for providing

12. 12. The method of claim 11, wherein the information indicating that the first UCI is associated with the first priority comprises downlink control information (DCI) received in a physical downlink control channel transmission, the DCI including a field indicating the first priority.

13. 12. The method of claim 11, wherein the first UCI is multiplexed with uplink data associated with the first priority in the PUSCH transmission.

14. 12. The method of claim 11, wherein the first priority is associated with a first transmission profile and the second priority is associated with a second transmission profile.

15. 12. The method of claim 11, wherein the amount of resources for the PUSCH transmission to be allocated to the first UCI comprises a number of resource elements.

16. 12. The method of claim 11, wherein the first UCI includes a scheduling request (SR), and the information indicating that the first UCI is associated with the first priority includes information indicating that a logical channel associated with the scheduling request is associated with the first priority.

17. 12. The method of claim 11, wherein the information indicating that the first UCI is associated with the first priority comprises configuration information received via higher layer signaling.

18. receiving information indicating that the second UCI associated with the second priority will be transmitted, the second UCI being transmitted in a second PUSCH transmission; determining an amount of resources for the second PUSCH transmission to be allocated to the second UCI based on the second set of one or more parameters associated with resource allocation for the second UCI associated with the second priority; transmitting the second UCI using the amount of resources for the second PUSCH transmission determined based on the second set of one or more parameters associated with a resource allocation for the second UCI associated with the second priority; The method of claim 11 further comprising:

19. 12. The method of claim 11 , wherein the first set of one or more parameters associated with resource allocation for the first UCI associated with the first priority includes a first set of one or more beta parameters for multiplexing the first UCI associated with the first priority on PUSCH resources, and the second set of one or more parameters associated with resource allocation for the second UCI associated with the second priority includes a second set of one or more beta parameters for multiplexing the second UCI associated with the second priority on PUSCH resources.

20. 20. The method of claim 19, wherein the first set of one or more beta parameters is associated with a greater proportion of PUSCH resources allocated for transmission of the first UCI than the second set of one or more beta parameters, and the first priority is a higher priority than the second priority.

Images