RU2839341C2 - Reliable control signalling - Google Patents

Abstract

FIELD: wireless communication.

SUBSTANCE: receiver in a wireless transmit/receive unit (WTRU) can receive one or more physical downlink control channel (PDCCH) transmissions containing downlink control information (DCI), WTRU determines a transmission profile associated with uplink control information (UCI), based on which the WTRU module determines one or more transmission characteristics associated with UCI transmission; WTRU transmits UCI via physical uplink control channel (PUCCH), and the UCI is transmitted using transmission characteristics determined by WTRU. WTRU transmits UCI based on at least one of control resource set (CORESET), search space or radio network temporary identifier (RNTI); WTRU may differently determine the transmission profile based on possible UCI content.

EFFECT: high efficiency of using resources and reliability of control signalling.

24 cl, 6 dwg

Description

Cross-reference to related applications

This application claims the benefit of U.S. Provisional Patent Application Nos. 62/519,585 filed June 14, 2017, 62/585,937 filed November 14, 2017, 62/652,002 filed April 3, 2018, and 62/667,015 filed May 4, 2018, the contents of which are incorporated herein by reference.

Prerequisites for the creation of an invention

Mobile communications based on wireless technologies continue to improve. Fifth generation or Next Gen (NG) wireless systems may be referred to as 5G systems or New Radio (NR). The previous generation of mobile communications may be, for example, the fourth generation (4G) Long Term Evolution (LTE) standard. NR use cases can generally be classified into one of the following groups: enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), or massive machine type communications (mMTC). Current processing and transmission mechanisms used in such use cases may be less efficient.

Statement of the essence of the invention

Systems, methods and means for implementing robust control signaling, for example, in new radio network (NR) systems are described. A receiver in a wireless transmit/receive unit (WTRU) can receive one or more transmissions on a physical downlink control channel (PDCCH) containing 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 identifier of a logical channel or a group of logical channels for data associated with the UCI, and some characteristic of at least one PDCCH transmission. The PDCCH transmission can be associated with one or more resources from a control resource set (CORESET).

The transmission profile may be determined based on one or more of: one or more DCI fields in the received DCI or an identifier of a bandwidth portion (BWP) used to transmit one or more of the DCIs or UCIs.

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 portion of the bandwidth, a set of time symbols within a slot or mini-slot, a subcarrier spacing, a subset of slots within a subframe, or at least one reference signal.

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 a network temporary identifier (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 data transmission allocated by the first DCI or the second DCI. In another example, the second UCI may correspond to a redundant transmission of the first UCI.

Based on the transmission profile, the WTRU may determine one or more transmission characteristics associated with the transmission of 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.

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 carrier (UL) and/or a supplemental uplink carrier (SUL).

The WTRU may determine the transmission profile associated with the PDSCH transmission based on one or more of the following, for example if the UCI contains a hybrid automatic repeat request acknowledgement (HARQ ACK): the transmission duration, the portion of the bandwidth, the numerical value, or the modulation and coding scheme (MCS) for the control information.

The WTRU may determine the transmission profile based on one or more of the following, for example if the UCI contains channel state information (CSI):

CSI-related block error rate (BLER) target or CSI report parameter.

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

Brief description of graphic materials

A more detailed explanation is contained in the description below, given as an example, in conjunction with the attached drawings.

Fig. 1A is a system diagram illustrating an example of a communication system in which one or more of the described embodiments may be implemented.

Fig. 1B is a system diagram illustrating an example of a wireless transmit/receive unit (WTRU) that may be employed within the communication system of Fig. 1A.

Fig. 1C is a system diagram illustrating an example of a radio access network (RAN) and an example of a core network (CN) that may be implemented within the communication system shown in Fig. 1A.

Fig. 1D is a system diagram illustrating an additional example of a RAN and another additional example of a CN that may be employed in the communication system of Fig. 1A.

Fig. 2 shows an example of downlink control information (DCI) diversity.

Fig. 3 shows an example of the diversity of DCI and uplink control information (UCI).

Detailed description

The following is a detailed description of illustrative embodiments with reference to various figures. Although this description provides detailed examples of possible embodiments, it should be noted that this detailed description is provided as an example and in no way limits the scope of the present application.

Fig. 1A shows a diagram of an example of a communication system 100 in which one or more of the described embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasting, and the like, to a plurality of wireless users. The communication system 100 may be configured to provide a plurality of wireless users with access to such content by sharing system resources, including wireless bandwidth. For example, in the communication systems 100, one or more channel access methods may be used, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal frequency division multiple access (OFDMA), single carrier FDMA (SC-FDMA), zero-redundancy extended discrete Fourier transform (DFT) OFDM with sync packet (ZT UW DTS-s OFDM), sync packet OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), and the like.

As shown in Fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104/113, CN 106/115, public switched telephone network (PSTN) 108, Internet 110 and other networks 112, although it should be understood that the described embodiments assume any number of WTRUs, base stations, networks and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or interact in a wireless communication environment. For example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station and/or STA, may be configured to transmit and/or receive radio signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, an access point or a Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, an unmanned aerial vehicle, a medical device and applications (e.g., used in remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or automated process chain environment), a device related to consumer electronics, a device operating in a commercial and/or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as user equipment (UE).

The communication systems 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 interact with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the Internet 110 and/or other networks 112. As an example, the base stations 114a, 114b may be base transceiver stations (BTS), Node-B stations, eNode B stations, Home Node B stations, Home eNode B stations, a next generation base station (gNB), an NR-based NodeB, a site controller, an access point (AP), a wireless router, and the like. Although base stations 114a, 114b are shown as a single element, it should be understood that base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

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, and the like. The base station 114a and/or the 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 a wireless service in a specific geographic area, which may be relatively fixed or which may change over time. The 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 use multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and/or receive signals in the desired spatial directions.

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

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 communication technology such as universal terrestrial access (UTRA) for a universal mobile telecommunications system (UMTS), which can establish a radio interface 115/116/117 using wideband CDMA (WCDMA). The wideband code division multiple access (WCDMA) technology may include communication protocols such as high speed packet access (HSPA) and/or HSPA enhanced (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed Uplink (UL) Packet Access (HSUPA).

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as the UMTS Unified Terrestrial Radio Access Network (E-UTRA), which may establish a radio interface 116 using the Long Term Evolution (LTE) standard and/or LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro).

In an embodiment, the base station 114a and the WTRU 102a, 102b, 102c may implement a radio technology such as a new radio access technology (NR Radio Access), which may establish a radio interface 116 using the New Radio (NR) technology.

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a plurality of radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may jointly implement LTE radio access and NR radio access, for example, using two-way communication (DC) principles. Thus, the radio interface used by the WTRUs 102a, 102b, 102c may be characterized by the use of a plurality of types of radio access technologies and/or transmissions sent to a plurality of types of base stations (e.g., eNB and gNB) from them.

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

The base station 114b shown in Fig. 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may employ any suitable RAT to facilitate wireless communications in a localized area such as a commercial enterprise, a residential premises, a vehicle, an educational institution, an industrial facility, an air corridor (e.g., for use by unmanned aerial vehicles), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to create 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 create a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may use a cell-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to create a pico cell or a femto cell. As shown in Fig. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106/115.

RAN 104/113 may communicate with CN 106/115, which may be any type of network configured to provide voice, data, applications and/or voice over Internet protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. The data may be subject to various quality of service (QoS) requirements, such as various performance requirements, latency requirements, fault tolerance requirements, reliability requirements, data rate requirements, mobility requirements, etc. CN 106/115 may provide call control, billing services, location-based mobile services, prepaid calls, Internet connectivity, video distribution, etc. and/or implement high-level security functions such as user authentication. Although not shown in Fig. 1A, it should be understood that RAN 104/113 and/or CN 106/115 may directly or indirectly communicate with other RANs that use the same RAT as RAN 104/113 or a different RAT. For example, in addition to connecting to RAN 104/113, which may use NR radio technology, CN 106/115 may also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

CN 106/115 may also act as a gateway for WTRUs 102a, 102b, 102c, 102d to provide access to PSTN 108, Internet 110, and/or other networks 112. PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). 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. Networks 112 may include wired and/or wireless communication networks that are owned and/or provided for use by other service providers. For example, networks 112 may include another CN connected to one or more RANs that may use the same RAT as RANs 104/113 or a different RAT.

Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for interacting with different wireless networks over different wireless communication links). For example, the WTRU 102c shown in Fig. 1A may be configured to interact with a base station 114a that may use a cell-based radio technology, as well as with a base station 114b that may use an IEEE 802 radio technology.

1B is a system diagram illustrating an example of a 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 keyboard 126, a display/touch panel 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripheral devices 138. It should be understood that the WTRU 102 may include any subcombination of the above elements and still comply with an embodiment.

The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), an integrated circuit (IC) of any other type, a state machine, and the like. The processor 118 may perform signal coding, data processing, power management, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless communication environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmitting/receiving element 122. Although the processor 118 and the transceiver 120 are shown as separate components in Fig. 1B, it should be understood that the processor 118 and the transceiver 120 may be integrated together into an electronic unit or microcircuit.

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

Although the transmit/receive element 122 is shown as a single element in Fig. 1B, 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 radio signals over the air interface 116.

The transceiver 120 may be configured to modulate signals that are to be transmitted by the transmitting/receiving element 122, and to demodulate signals that are received by the transmitting/receiving element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include a plurality of transceivers to provide the WTRU 102 with the ability to interact via a plurality of RATs, such as, for example, NR and IEEE 802.11.

The processor 118 of the WTRU 102 may be connected to and may receive user input via the speaker/microphone 124, the keyboard 126, and/or the display/touch panel 128 (e.g., a liquid crystal display (LCD) or an organic light-emitting diode (OLED) display). The processor 118 may also output user data to the speaker/microphone 124, the keyboard 126, and/or the display/touch panel 128. In addition, the processor 118 may access information from any suitable storage device, such as a non-removable storage device 130 and/or a removable storage device 132, and store data thereon. The non-removable storage device (MS) 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of storage device. The removable storage device 132 may include a subscriber identity module (SIM) card, a memory card, a secure digital memory (SD) card, etc. In other embodiments, the processor 118 may access information from a storage device that is not physically located in the WTRU 102, such as a server or a home computer (not shown), and store data thereon.

The processor 118 may receive power from a power source 134 and may be configured to manage power and/or distribute 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-hydride (NiMH), lithium-ion (Li-ion) batteries, etc.), solar cells, fuel cells, etc.

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) relative to 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 over the radio interface 116 from a base station (e.g., from base stations 114a, 114b) and/or determine its location based on the timing of signals received from two or more neighboring base stations. It should be understood that the WTRU 102 may obtain location information through any suitable location determination method and still comply with the embodiment.

The processor 118 may be further connected to other peripheral devices 138, which may include one or more software and/or hardware modules that provide additional features, functionalities and/or capabilities for establishing wired or wireless communication. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photo and video shooting), a universal serial bus (USB) port, a vibration device, a television transceiver, a wireless headset, a Bluetooth® module, a radio module with frequency modulation (FM), a digital music player, a multimedia player, a device module for playing video games, an Internet browser, a virtual reality and/or augmented reality (VR/AR) device, an activity tracker, etc. Peripheral devices 138 may include one or more sensors, wherein the sensors may be one or more of a gyroscope, an accelerometer, a Hall sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geographic location sensor; an altimeter, an illumination sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.

The WTRU 102 may include a full-duplex radio device in which transmission and reception of some or all signals (e.g., associated with particular subframes) for both the UL (e.g., for transmission) and the downlink (e.g., for reception) may be performed jointly and/or simultaneously. The full-duplex radio device may include an interference control module for reducing and/or substantially eliminating self-interference using any hardware (e.g., a throttle) or signal processing using a processor (e.g., a separate processor (not shown) or processor 118). In an embodiment, the WTRU 102 may include a full-duplex radio device for transmitting and receiving some or all signals (e.g., associated with particular subframes) for both the UL (e.g., for transmission) and the downlink (e.g., for reception).

Fig. 1C shows a system diagram of RAN 104 and CN 106 according to an embodiment. As noted above, RAN 104 may use E-UTRA radio technology to interact with WTRUs 102a, 102b, 102c over radio interface 116. RAN 104 may also exchange data with CN 106.

RAN 104 may include eNode-Bs 160a, 160b, 160c, although it should be understood that RAN 104 may include any number of eNode-Bs and still comply with an embodiment. Each eNode-B 160a, 160b, 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, 102c over air interface 116. In one embodiment, eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, eNode-B 160a may, for example, use multiple antennas to transmit radio signals to and/or receive radio signals from WTRU 102a.

Each eNode-B 160a, 160b, 160c may be associated with a specific cell (not shown) and may be configured to make radio resource management decisions, handover decisions, UL and/or DL user scheduling, etc. As shown in Fig. 1C, eNode-B 160a, 160b, 160c may communicate with each other via an X2 interface.

The CN 106 shown in Fig. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the above elements is shown as part of the CN 106, it should be understood that any of these elements may be owned and/or provided for use by an entity other than the CN operator.

The MME 162 may be connected to each base station eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authentication of users of the WTRUs 102a, 102b, 102c, activation/deactivation of a channel, selection of a specific serving gateway during initial connection of the WTRUs 102a, 102b, 102c, etc. 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.

SGW 164 may be connected to each eNode B 160a, 160b, 160c in RAN 104 via an S1 interface. SGW 164 may substantially route and forward user downlink data packets to and from WTRUs 102a, 102b, 102c. SGW 164 may perform other functions, such as user plane association during handover between eNode B base stations, initiating paging when DL data is available to WTRUs 102a, 102b, 102c, managing and storing context of WTRUs 102a, 102b, 102c, etc.

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

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

Although the WTRU is described in Figs. 1A-1D as a wireless terminal, it is contemplated that in certain exemplary embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

In exemplary embodiments, the other network 112 may be a WLAN.

A WLAN in the basic service set (BSS) infrastructure 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 communicate over another type of wired/wireless network that carries traffic into the BSS and/or outside the BSS. Traffic to the STAs provisioned outside the BSS may enter through the AP and may be delivered to the STA. Traffic originating from the STAs to destinations outside the BSS may be sent to the AP for delivery to the appropriate destinations. Traffic between STAs within the BSS may be sent through the AP, for example, if the source STA can send traffic to the AP and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and/or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between (e.g., directly between) a source STA and a destination STA with the establishment of a direct link (DLS). In certain exemplary embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all STAs) within, or using, the IBSS may communicate directly with each other. The IBSS mode may sometimes be referred to herein as a direct connection communication mode.

When using the 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit a beacon via a fixed channel, such as a primary channel. The primary channel may have a fixed width (e.g., a bandwidth of 20 MHz) or a width dynamically set using signaling. The primary channel may be an operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain example embodiments, carrier sense multiple access with collision avoidance (CSMA/CA) may be implemented, such as in 802.11 systems. For CSMA/CA, STAs (e.g., each STA), including the AP, may sense the primary channel. Upon sensing/detection and/or determining that the primary channel is occupied by a particular STA, that particular STA may disconnect. One STA (e.g., only one station) may transmit at any given time in a given BSS.

To implement high throughput (HT) STA communications, a 40 MHz wide channel can be used, for example, by combining a 20 MHz primary channel with an adjacent or non-adjacent 20 MHz channel to form a 40 MHz wide channel.

Ultra-High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and/or 160 MHz channels. The 40 MHz and/or 80 MHz channels can be formed by combining 20 MHz solid channels. A 160 MHz channel can be formed by combining 8 20 MHz solid channels or by combining two 80 MHz non-solid channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, the data after channel encoding can pass through a segment analyzer, which can separate the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed separately for each stream. These 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 above operation for the 80+80 configuration can be inverted, and the combined data can be sent to the MAC device.

802.11af and 802.11ah support 1 GHz sub-modes of operation. The channel bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the television white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using spectrum other than TVWS. According to an exemplary embodiment, 802.11ah may support metered control/machine-to-machine communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., support only) certain and/or limited bandwidths. MTS devices may include a battery that has a battery life exceeding a threshold (e.g. to provide very long battery life).

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 total operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and/or limited by the STA, from among all STAs operating in the BSS, that supports the operating mode with the smallest bandwidth. In the 802.11ah example, the primary channel can have a width of 1 MHz for STAs (e.g., MTC-type devices) that support (e.g., support only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or operating modes with other channel bandwidths. The carrier detection and/or network allocation vector (NAV) parameters may depend on the state of the primary channel. If the primary channel is occupied, for example due to an STA (which only supports 1 MHz operation) transmitting to an AP, all available frequency bands may be considered occupied, even though most frequency bands remain unoccupied and may be available.

In the United States, the available frequency bands that can be used by 802.11ah range from 902 MHz to 928 MHz. The available frequency bands in Korea are from 917.5 MHz to 923.5 MHz. The available frequency bands in Japan are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11ah ranges from 6 MHz to 26 MHz, depending on the country code.

Fig. 1D shows a system diagram of RAN 113 and CN 115 according to an embodiment. As noted above, RAN 113 may use NR radio technology to interact with WTRUs 102a, 102b, 102c over radio interface 116. RAN 113 may also exchange data with CN 115.

RAN 113 may include gNBs 180a, 180b, 180c, although it should be understood that RAN 113 may include any number of gNBs and still comply with an embodiment. Each gNB 180a, 180b, 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, 102c over air interface 116. In one embodiment, gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may use beamforming to transmit signals to and/or receive signals from gNBs 180a, 180b, 180c. Thus, gNB 180a, for example, may use multiple antennas to transmit radio signals to and/or receive radio signals from WTRU 102a. In an embodiment, gNB 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be from unlicensed spectrum, while the remaining component carriers may be from licensed spectrum. In an embodiment, gNB 180a, 180b, 180c may implement matching multi-point (CoMP) technology. For example, WTRU 102a may receive matched transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable numerical value. For example, the OFDM symbol spacing and/or the OFDM subcarrier spacing may be different 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 a subframe or transmission time intervals (TTIs) of different or scalable duration (e.g., containing a different number of OFDM symbols and/or having constant different absolute time value durations).

The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a stand-alone configuration and/or in a non-stand-alone configuration. In the stand-alone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without simultaneously accessing other RANs (e.g., such as the eNode-Bs 160a, 160b, 160c). In the stand-alone configuration, the WTRUs 102a, 102b, 102c may use one or more gNBs 180a, 180b, 180c as a reference point for mobility. In a stand-alone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in the unlicensed band. In a non-stand-alone configuration, the WTRUs 102a, 102b, 102c may communicate/establish a connection with the gNBs 180a, 180b, 180c while simultaneously communicating/establishing a connection with another RAN, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement dual connectivity (DC) principles to substantially simultaneously communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, 160c may act as a mobility anchor point for WTRUs 102a, 102b, 102c, and gNBs 180a, 180b, 180c may provide additional coverage and/or capacity to serve WTRUs 102a, 102b, 102c.

Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to make radio resource management decisions, handover decisions, UL and/or DL user scheduling, support network segmentation, two-way communication, NR and E-UTRA interworking, routing user plane data to a user plane function (UPF) 184a, 184b, routing control plane information to an access and mobility management (AMF) function 182a, 182b, etc. As shown in Fig. 1D, the gNBs 180a, 180b, 180c may communicate with each other over an Xn interface.

The CN 115 shown in Fig. 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. Although each of the above elements is shown as part of the CN 115, it should be understood that any of these elements may be owned by and/or provided for use by an entity other than the CN operator.

The AMF 182a, 182b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network segmentation (e.g., handling different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, managing a registration area, terminating NAS signaling, managing mobility, etc. Network segmentation may be used by the management of the AMF 182a, 182b to configure CN support for the WTRUs 102a, 102b, 102c based on the types of services used by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services based on highly reliable low latency communication (URLLC), services based on access to an enhanced mobile broadband (eMBB) network, services for access to machine-to-machine communication (MTC), and/or the like. AMF 162 may provide a control plane function for switching between RAN 113 and other RANs (not shown) that use other radio technologies such as LTE, LTE-A, LTE-A Pro, and/or access technologies other than 3GPP, such as WiFi.

The SMF 183a, 183b may be connected to the AMF 182a, 182b in CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating an IP address of the WTRU, managing PDU sessions, managing policy and QoS enforcement, providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

The UPF 184a, 184b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface that may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks such as the Internet 110 to facilitate data exchange between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions such as packet routing and forwarding, user-plane policing, support for multi-channel PDU sessions, user-plane QoS processing, downlink packet buffering, mobility tethering, etc.

The CN 115 may facilitate interaction with other networks. For example, the CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108, or may communicate with it. In addition, 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 that are owned and/or provided for use by other service providers. In one embodiment, the WTRU modules 102a, 102b, 102c may be connected to the local data network (DN) 185a, 185b via the UPF 184a, 184b via an N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

With reference to Figs. 1A-1D and the corresponding descriptions of Figs. 1A-1D, one or more or all of the functions described herein in connection with one or more of: WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a c, AMF 182a b, UPF 184a b, SMF 183a b, DN 185a b and/or any other device(s) described herein may be implemented 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, emulation devices may be used to test other devices and/or to simulate network functions and/or WTRUs.

The emulation devices may be configured to perform one or more tests of other devices in a laboratory environment and/or in an operator network environment. For example, one or more emulation devices may perform one or more functions or all functions, being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network, for testing other devices in the communication network. One or more emulation devices may perform one or more functions or all functions, being temporarily implemented/deployed as part of a wired and/or wireless communication network.

The emulation device may be directly connected to another device for testing and/or performing testing using wireless communication via a wireless communication channel.

One or more emulation devices may perform one or more functions, including all functions, without being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be used in a test scenario in a test lab and/or in a non-deployed (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 connection and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used to transmit and/or receive data in the emulation devices.

New radio (NR) technology can work with existing and future mobile wireless communication systems. Use cases for NR technology may include, for example, enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), and massive machine-type communications (mMTC). NR technology can support transmission in high-frequency bands, such as centimeter waves (cmwaves) and/or millimeter waves (mmwaves). When operating in cmwave and/or mmwave frequency bands, there may be propagation issues, such as higher signal attenuation and shadowing.

Highly reliable services can be supported, for example, at very low block error rates, for example on the order of 0.001%. Lower error rates can be achieved, for example, by increasing the reliability of the physical layer control information (e.g. Hybrid Automatic Repeat Request (HARQ) acknowledgements, uplink grants and downlink assignments). In an example (e.g. for HARQ ACK), a probability of misinterpreting a negative acknowledgement (NACK) as an ACK of 0.1% may be sufficient for some (e.g. general) Mobile Broadband services, but may be too high, for example, for ultra-reliable services (e.g. since misinterpreting a negative acknowledgement (NACK) as an acknowledgement (ACK) may lead to the loss of a transport block).

The WTRU may be configured to perform multiple transmissions simultaneously. The NR technology may support a WTRU configuration that may include one or more cells for a given MAC entity and/or for multiple MAC entities. The single cell configuration may support single cell operation. The multiple cell configuration may support carrier aggregation (CA), such as NR CA operations. The multiple MAC entity configuration may include NR DC (NR DC). The multiple MAC entity configuration may support a combination of LTE and NR (e.g., DC between an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN) and a New Radio System (EN-DC)). The NR technology may support a WTRU configuration that includes a cell configured with one downlink carrier, one uplink carrier, and a supplemental uplink carrier (SUL). The NR technology may support a cell configured with one or more bandwidth fractions (BWP). The BWP may be characterized by at least one of a frequency position (e.g., a center frequency and/or a bandwidth) or a numerical value.

For EN-DC, NR CA and NR DC in the licensed bands, different combinations (e.g. different combinations) of carriers may introduce different timing relationships (e.g. different timing relationships) between transmissions associated with the WTRU (or between transmissions that may at least partially overlap in time) in terms of one or more of the following parameters: a numerical value, a transmission start time, or a transmission duration. For example, each of the configured component carriers (downlink (DL) and/or uplink (UL)) and/or bandwidth portions (BWP) (DL and/or UL) for the WTRU may have the same or different numerical value, and overlapping transmissions between different component carriers/BWP portions may have the same or different start times; and the same or different transmission durations of the physical uplink shared data channel (PUCCH)/physical uplink control channel (PUCCH).

The synchronization and/or scheduling aspects may be provided, for example, in case of asynchronous transmissions and/or in cases of partial and/or full overlap between different uplink transmissions associated with the WTRU. In an example, different transmissions may be performed with different HARQ time scales, for example, based on dynamic scheduling information. For example, such scheduling information may include dynamically changing scheduling-related delay components. The dynamically changing scheduling-related delay components may be provided by downlink control information (DCI). The scheduling-related delay components may include one or more of K1, K2, N1 or N2. K1 may be a delay between the receipt of data on the downlink (DL) (PDSCH) and the transmission of the corresponding ACK on the uplink (UL). K2 may be a delay between the receipt of an UL grant message on the DL and the transmission of data on the UL (e.g., a PUSCH transmission). N1 may be a series of OFDM symbols used for processing by the WTRU from the end of reception of the NR-PDSCH until the earliest possible time to start transmitting the corresponding ACK/NACK, for example from the WTRU's perspective. N2 may be a series of OFDM symbols used for processing by the WTRU from the end of reception of the NR-PDCCH containing the UL grant until the earliest possible time to start transmitting the corresponding NR-PUSCH, for example from the WTRU's perspective.

The scheduler may adjust the error probability of the control information, for example, by selecting the transmission power parameters (e.g., associated with uplink transmission) and/or the aggregation level (e.g., associated with downlink transmission). Ensuring very low error rates may be problematic.

In the example, very low error rates may not be achieved due to changes in transmission technology parameters, such as in the presence of uneven interference and/or other channel distortions (e.g. strong shadowing at millimeter frequencies).

Spectrum efficiency and user data throughput may be significantly reduced, for example, when operating at very low error rates, since the application of such technologies to one or more types of transmissions may consume significantly more resources (time, frequency, and/or power) than when operating at standard error rates. Differentiating between highly reliable transmissions and other types of transmissions (e.g., through resource segregation) may be less effective, for example, due to the possible unevenness of the highly reliable traffic.

Very low error rates can be achieved (e.g. for ultra-reliable services). Efficient operation (e.g. in the WTRU system and/or module) with ultra-reliable and other (e.g. non-ultra-reliable) mobile broadband data traffic can be ensured.

The uplink control information (UCI) may comprise, for example, HARQ feedback information (e.g., a HARQ-ACK message), a scheduling request (SR), and/or channel state information (CSI). The UCI may be transmitted on an uplink control channel (e.g., a physical uplink control channel (PUCCH)) and/or on an uplink data channel (e.g., a physical uplink shared channel (PUSCH)). The UCI may be transmitted with or without multiplexing with the uplink data. The HARQ feedback information (e.g., a HARQ-ACK message) may relate to a transport block(s), a code block(s), and/or a group(s) of code blocks.

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

DCI diversity may be provided. In an example, the reliability of DCI transmission may be increased, for example, by transmitting multiple instances of DCI over resources divided by time, frequency, and/or spatial domains. The multiple instances may provide diversity gain to protect against short-term fading, long-term fading, and/or interference.

The DCI (e.g., each DCI instance) may be transmitted on a physical downlink control channel (e.g., PDCCH, group-wide PDCCH, PHICH, etc.). A single instance may be transmitted on a PDSCH (e.g., when DCI is supported on the PDSCH). 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 mini-slot, 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 an example, frequency diversity may be achieved (e.g., by configuring different component carriers or BWP portions 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).

The DCI diversity may be configurable. For example, the DCI diversity may be activated or deactivated. The activation or deactivation of the DCI diversity, for example, may be based on MAC layer signaling or physical layer signaling. In an example, the WTRU may receive an activate command based on a first CORESET to initiate monitoring of a second DCI instance in a second CORESET. The WTRU may receive a deactivate command to monitor a DCI instance on a given CORESET.

DCI diversity may be applied. The content of a DCI instance (e.g., each DCI instance) may 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.

In an example, each of a plurality of DCI instances may include and encode the same information bits for at least one DCI type or format (e.g., HARQ-ACK for PUSCH, PDSCH assignment, PUSCH grant). The DCI may be decodable (e.g., fully decodable) upon receipt of an instance (e.g., one instance).

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 at least N of the D instances of the DCI (e.g., at the receiver) may be sufficient to fully recover the DCI. In an example, the encoding may consist of a parity code.

In an example, the DCI instances may include one or more of the following: information associated with at least one DL data transmission on the PDSCH or information associated with at least one UL data transmission on the PUSCH.

In an example, the WTRU may be configured to monitor the PDCCH over a plurality of CORESETs (e.g., two CORESETs). The WTRU may monitor the PDCCH on different carriers or portions of bandwidth. The WTRU may receive, for example, a plurality of DCI instances (e.g., up to two DCI instances). In an example, the DCI instances may include the same information that was received by the WTRU via the PDCCH on the plurality of carriers (e.g., in the case of a plurality of DCIs, each carrier may be received on one of the carriers). The information on the DCIs (e.g., each DCI) may include PDSCH (or PUSCH) assignments/grantings for the plurality of carriers (e.g., both carriers). The WTRU may receive the PDSCH or transmit the PUSCH on the plurality of carriers (e.g., both carriers), for example, even in the case where (e.g., one) of the DCI instances may not be successfully decoded. A very low BLER can be obtained with a low delay, for example, when multiple PSDCH transmissions (e.g., both PDSCH transmissions) or PUSCH transmissions can be coded in the same transport block, for example, since the DCI and data can be (e.g., are) independently protected by diversity, as shown in the example of Fig. 2. As shown in Fig. 2, the DCI on the downlink component carrier 1 (DL CC1) 202 and the DCI on the 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 PSDCH 208.

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 define the content of the DCI. The WTRU may discard DCI instances that may include the same information. Duplicate DCIs may be discarded to reduce processing. In an example, the WTRU may receive a first DCI instance with a first DCI index value. The WTRU may receive subsequent DCI instances that may include the same DCI index value (e.g., within a CORESET in which DCI diversity may be configured over a period of time). The WTRU may (e.g., upon receipt) discard subsequent DCI instances. The WTRU may use the DCI index, for example, to differentiate between diversity DCI and DCI that may include new information.

UCI diversity may be provided. The reliability of UCI transmission may be increased, for example, by transmitting multiple instances over resources that may be partitioned into one or more of the following: time, frequency, or spatial domains. With multiple UCI instances, it is possible to provide, for example, diversity gain to protect against short-term fading, long-term fading, and/or interference. An instance of UCI (e.g., each UCI instance) may be transmitted on a physical uplink control channel (PUCCH) or a physical shared channel for uplink data transmission (PUSCH). In an example, UCI diversity may be applicable to certain types of UCI (e.g., HARQ ACK).

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

3 shows an example of implementing DCI diversity and UCI diversity. In the example, a UCI instance (e.g., each UCI instance) may include transmitting an OFDM symbol (e.g., one OFDM symbol) in adjacent symbols (e.g., using a short PUCCH format). Other examples in the time domain may include, for example, transmitting in the same OFDM symbol or transmitting in different slots. The resources (e.g., RB, time symbol, slot, etc.) that may be occupied by a UCI instance (e.g., each UCI instance) may be configured independently.

In an example, UCI instances may be transmitted using multiple beams. For example, multiple beams may be transmitted using different precoders. The WTRU may be configured to determine a beam associated with a UCI instance (e.g., with each UCI instance). The WTRU may be configured to use information including one or more of the following: a beam index, a beam process identifier, an SRS indicator or a CSI-RS indicator (e.g., when there is a beam mapping), and the like. The information used by the WTRU to determine the beam (e.g., for PUCCH) may be configured using higher layers for the UCI instance (e.g., for each UCI instance) or may be indicated in the DCI, which may include an ACK/NACK resource indicator (ARI). The information used by the WTRU to determine the beam (e.g., for PUSCH) may be indicated by the DCI, which may include a grant associated with the beam.

The information used by the WTRU to determine the beam may be derived (e.g., implicitly derived) from the PDCCH, which may include an assignment. In an example, the beam associated with the transmission of a PUCCH instance may be determined from a reference signal (e.g., a channel state information reference signal (CSI-RS)) or a beam indicator, which may be associated with a set of control resources or a PDCCH transmission, which may include an assignment. Such an approach may be used, for example, when PDCCH diversity (or DCI diversity) may be used in addition to UCI diversity. The WTRU may transmit some PUCCH instance (e.g., one PUCCH instance) for a received PDCCH instance (e.g., for each received PDCCH instance). The PDCCH instance may include an assignment, for example, indicating when and/or how UCI may be transmitted on the PUCCH.

A supplemental uplink (SUL) may be provided. In an example, the WTRU may be configured with a 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 a HARQ ACK/NACK. The UCI may be transmitted on a regular UL carrier and a SUL carrier associated with the serving cell.

UCI diversity may be applied. The content of a UCI instance (e.g. each UCI instance) may be determined, for example, according to one or more of the following: (i) whether the same content needs to be conveyed on each of a plurality of UCI instances (e.g. repetition); (ii) whether the same content needs to be conveyed across UCI instances (e.g. block encoding); or (iii) the nature of the content.

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., a HARQ-ACK acknowledgement). The UCI may be configured to be decoded after receiving one instance. In an example, the UCI may be encoded, for example, by segmenting the UCI into N blocks and encoding the N segmented blocks into D blocks. In an example, decoding at least N blocks of the D UCI instances at the receiver may be sufficient to recover the entire UCI. In an example, the encoding may include a parity code.

In an example (e.g., when DCI diversity may not be applied), the UCI may include a set of HARQ-ACK bits. The association between a specific HARQ-ACK bit and the result of receiving a transport block may be determined, for example, based on a downlink assignment index.

In an example (e.g., when DCI diversity can be applied), a set of HARQ-ACK bits can be generated and transmitted, for example, for each of the DCI instances that can be configured to be received in diversity conditions (e.g., based on the same content). This can occur, for example, regardless of the possibility of successful decoding of the DCI instance. The WTRU can issue a NACK acknowledgement for transport blocks corresponding to a DCI instance that may not be received, for example, when the WTRU can be configured to receive multiple DCI instances (e.g., two DCI instances) in diversity conditions, but the received number of DCI instances is less than a configured number (e.g., if two DCI instances are configured). Issuing such an acknowledgement is possible, for example, when the WTRU receives at least one DCI instance. The network can be allowed to determine missing assignments from a DCI instance (e.g., each DCI instance). Determining missing assignments can be useful for PDCCH link adaptation.

In an example, DCI diversity may be applied. The WTRU may provide a set of HARQ-ACK bits for a set of DCI instances that may be capable of being received in diversity conditions, such as when the WTRU receives at least one DCI instance. The WTRU may provide an indication of a subset of DCI instances that may be successfully decoded within the set of DCI instances in diversity conditions.

The WTRU may receive more than one DCI information, which may indicate DL data for the same HARQ process and transport block(s). The DCI information may be encoded using different versions of redundancy. The WTRU may issue one HARQ-ACK bit per transport block (e.g., regardless of the number of received PDSCH instances, which may include data for the transport block). The WTRU may transmit a HARQ-ACK bit per transport block and PDSCH instance, which may include data for the transport block (e.g., with the same value).

Power control can be provided using UCI diversity. The transmit power associated with a transmission (e.g., a PUCCH transmission or a PUSCH transmission) can be set independently, for example, when using UCI diversity. For example, a separate configuration of one or more reference signals can be used to estimate the signal attenuation, and other parameters can be used to determine the transmit power.

Power control using diversity may be provided to specify transmit power control (TPC). The WTRU may specify a TPC command that may be applicable to a transmission in which UCI diversity may be applied.

In an example of determining the TPC, the WTRU may apply such a TPC adjustment for each of a plurality of transmissions of a UCI instance. The TPC adjustment may be obtained, for example, from a DCI that may be associated with the UCI transmission. For example, the DCI may include a DL assignment or a CSI request.

In an example of determining the TPC, the WTRU may apply a separate TPC adjustment for each of a plurality of transmissions of a UCI instance. The TPC adjustment (e.g., each TPC adjustment) may be obtained, 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, when UCI diversity may be configured using two transmissions.

In the example of TPC definition, the WTRU may apply a separate TPC adjustment for each of the transmissions of the UCI instance. The TPC adjustment may be received for each of the UCI instances, for example, by means of a specific DCI instance that may be associated with the UCI instance.

Power control may be provided using power control modes, such as for carrier aggregation (CA) and/or direct communication (DC). In an example, the WTRU may apply a priority level to a transmission that may include a UCI, such as when UCI diversity is activated. The WTRU may apply the priority level, such as if the configuration provides for a power management mode (PCM). The WTRU may be configured to group one or more transmission types (transmissions). The WTRU may be configured to allocate at least some amount (e.g., a portion) of the total available power of the WTRU to a group of transmissions, such as to provide a minimum guaranteed power. The WTRU may determine that transmissions including a UCI are included in the same group of transmissions. The WTRU may perform such grouping, such as if the UCI is associated with a transmission profile. For example, such a data transmission profile may correspond to an ultra-reliable low latency transmission type (URLLC). The WTRU may assign such a group of transmissions a higher priority than other data transmissions (e.g., data transmissions associated with a transmission profile that corresponds to a transmission type other than the URLLC type). For example, in a WTRU configured to provide CA, a transmission that includes at least some UCI generated using UCI diversity may have the highest priority compared to other transmissions for a given MAC instance. For a WTRU configured to provide DC and/or multiple groups of transmissions, for example, one group of transmissions (or group of cells) in which at least one transmission includes at least some UCI (generated, for example, using UCI diversity) may have the highest priority compared to other group(s).

Resource allocation can be provided using UCI diversity using PUCCH. The PUCCH resource and transmission format can be defined (e.g., when transmitting a UCI instance on PUCCH), for example, in accordance with one or more example procedures. In an example, a WTRU can be implemented with one or more combinations of PUCCH resources. A PUCCH resource (e.g., each PUCCH resource) can correspond to a resource on which a UCI instance can be transmitted. In an example (e.g., with two UCI instances), a combination can be defined as PUCCH resource index #24 on a first CC or portion of bandwidth and PUCCH resource index #13 on a second CC or portion of bandwidth. The combination can be referred to as a PUCCH diversity resource or a super PUCCH diversity resource. A WTRU can be implemented (e.g., by higher layers) with more than one PUCCH diversity resource. The PUCCH diversity resource may be indicated in some field (e.g., ARI field) of the associated DCI. The WTRU may be implemented (e.g., by higher layers) with a pool. The pool may include standard PUCCH resources and PUCCH diversity resources with which the network may be able to manage (e.g., dynamically manage) the use of UCI diversity.

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

DTX feedback may be provided. In an example, the WTRU may transmit HARQ-ACK information in a specific PUCCH resource. The HARQ-ACK information may indicate (e.g., explicitly indicate) non-receipt of a DL transmission or DL assignment (e.g., in case of discontinuous transmission (DTX)) from a specific CORESET in a given slot or mini-slot. The duration of the PUCCH resource may be derived, for example, based on the duration of the slot or mini-slot in which the DL assignment was not received.

PUCCH interference randomization may be provided. In an example, a PUCCH transmission from two or more WTRUs to two or more transmit/receive points (TRPs) may create a collision. Interference randomization may be used, for example, to reduce the impact of a highly interfering PUCCH transmission on an interfered with PUCCH transmission. Interference randomization may be implemented, for example, by a pair of WTRUs to avoid using PUCCH resources that conflict with each other.

Interference randomization can be used to increase transmit diversity. Interference randomization can include, for example, one or more of the following resource hopping techniques: beam or beam pair hopping, PUCCH symbol hopping within a slot or over multiple slots, or duplication pattern hopping.

In an example of resource hopping, the hopping may be performed within a single BWP or over multiple BWPs. A PUCCH transmission (e.g., each PUCCH transmission) may, for example, cyclically switch to a frequency resource pattern. In an example, the hopping may be performed within a PUCCH transmission.

In an example of beam hopping of a single or pair of beams, PUCCH transmissions may be cyclically switched between a set of beams. In an example, cyclic switching between beams may be accomplished, for example, by using one beam for each set of PUCCH symbols within a PUCCH transmission. In an example of PUCCH symbol hopping within a single slot or over multiple slots, a short PUCCH may occupy a different slot symbol for each of a plurality of PUCCH transmissions.

In the example of hopping the duplication pattern, multiple duplicates may be used in a PUCCH transmission (e.g., in each PUCCH transmission). Each of the duplicates may use different resources. A subsequent PUCCH transmission (e.g., each subsequent PUCCH transmission) may use a different set (e.g., a separate set) of resources. Different sets of resources may be used to employ multiple duplicates.

The WTRU may receive an indication to apply interference randomization and/or hopping patterns. For example, the WTRU may receive a dynamic indication to apply interference randomization and/or hopping patterns. The hopping patterns may be determined, for example, based on some characteristic of the PUCCH transmission. In an example, the hopping of the PUCCH configuration may depend on a frame duration, a subframe duration, or a PUCCH interval duration. In an example, the PUCCH configuration may depend on the PUCCH configuration used for the previous PUCCH transmission. In an example, the hopping of the PUCCH configuration may depend on some WTRU parameter (e.g., a WTRU identifier) or a TRP parameter (e.g., a TRP identifier).

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., a short PUCCH or a long PUCCH). The WTRU may be configured with parameters associated with one or more PUCCH formats. A configuration of PUCCH resources may be provided, for example, semi-statically provided.

The PUCCH resource configuration may include, for example, one or more of: (i) a PUCCH format (e.g., a short PUCCH format or a long PUCCH format); (ii) a PUCCH duration in symbols (e.g., a short PUCCH duration of 1 or 2 symbols and a long PUCCH duration); (iii) a signal used to transmit the PUCCH (e.g., cyclic prefix orthogonal frequency division multiplexing (CP-OFDM) or extended discrete Fourier transform orthogonal frequency division multiplexing (DFT-s-OFDM)); (iv) a numerical value used for the PUCCH (e.g., subcarrier spacing, CP type, etc.); (v) a time position (e.g., a symbol position in an interval in which the PUCCH can be transmitted). (vi) frequency positions (e.g., subcarriers, physical RBs, bandwidth fraction (BWP)); (vii) frequency division multiplexing index (e.g., used to activate FDM of multiple PUCCHs on the same physical RB or BWP when a PUCCH transmission can be assigned to one or more multiplexes within a physical RB or BWP); (viii) hopping pattern(s) (e.g., for hopping within a single PUCCH transmission or during multiple PUCCH transmissions); (ix) a beam or beam pair; (x) a duplication pattern (e.g., for a PUCCH transmission that can be duplicated on multiple resources); (xi) an orthogonal cover code (OCC) (e.g., may include an indication of whether to apply the OCC code over time or with subcarrier elements); (xii) a cyclic shift; or (xiii) a transmit diversity scheme.

The frequency position may include, for example, an allocation of frequencies on which the PUCCH may be transmitted. The frequency position may be provided, for example, by specifying an offset value. The offset may be applied, for example, to a frequency position of a PDCCH that may configure a PUCCH, or a PDCCH that assigns a PDSCH, or a PDSCH. The offset may be applied to a frequency position in a concurrent PUSCH. The frequency position may include, for example, a set of subcarriers, physical RBs, and/or parts of a BWP. The set may be used to indicate (e.g., dynamically indicate) a frequency position for a PUCCH transmission instance (e.g., for each PUCCH transmission instance). The set may be used, for example, to provide frequency diversity through repetition. The set may be used, for example, to provide frequency hopping.

A configuration (e.g., including a duplication pattern) may include a set of resources over which PUCCH transmission may be duplicated. Different duplication patterns may be selected (e.g., dynamically selected).

The semi-static configuration may include one or more tables. A 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, a table may be applicable to multiple PUCCH durations and PUCCH formats.

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., at the WTRU) by 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 an index of code points to be used in the table. In an example, a dynamic indication may be provided (e.g., implicitly provided). For example, the dynamic indication may be represented as a function of transmission (e.g., as a function of a PDCCH transmission parameter or a PDSCH transmission). In an example, a hybrid procedure may be applied. The WTRU may determine the PUCCH configuration, for example, based on a combination of an explicitly specified index and an implicit dependency. 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 determine a second set of configurations or a code point in the table. For example, the PUCCH configuration table may be defined implicitly, and the second set of configurations or code point may be defined explicitly.

The implicit indication may include one or more of the following: (i) slot size, (ii) UL/DL slot configuration, (iii) service type, (iv) UCI multiplexing, (v) feedback timing, (vi) feedback type, or (vii) conflicts between different feedback types. In the example of the slot size, a mini-slot may indicate the use of a short PUCCH or a standard slot may indicate the use of a long PUCCH. In the example of the UL/DL slot configuration, the WTRU may determine the PUCCH type (e.g., short or long) or the duration of a long PUCCH, for example, based on the number of symbols allocated for UL transmissions. In the example of the service type, the URLLC may include a PUCCH format for HARQ, thereby providing greater reliability. In the example, PUCCH diversity may be required for URLLC transmission. In an example of UCI multiplexing, the transmission of HARQ associated with multiple TBs (e.g., due to multiple carriers or slot aggregation) may have a PUCCH format with a higher payload. In an example of feedback synchronization, a first PUCCH table may be used for feedback synchronization using an offset smaller than a threshold, and a second PUCCH table may be used for feedback synchronization using an offset greater than a threshold. In an example, a short PUCCH may be used, such as for a single slot, and the feedback may be provided in the same slot as the DL data. In an example of a feedback type, the HARQ feedback may use a first PUCCH configuration, and the CSI may use a second PUCCH configuration. In an example, the transport block (TB)-based HARQ feedback may use a first PUCCH configuration (e.g., a short PUCCH), and the code block gating (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), a PUCCH configuration for a higher priority service type may be used. In an example, feedback multiplexing may be used in PUCCH configurations for a URLLC service, e.g., when eMBB HARQ feedback may conflict with URLLC HARQ feedback.

It may be possible to select feedback based on a PUCCH configuration. In an example, the WTRU may determine the type of feedback based on the PUCCH configuration that will be used for the feedback. A WTRU assigned with short PUCCH resources may, for example, determine that TB-based HARQ feedback may be required for PDSCH transmission. A WTRU assigned with long PUCCH resources may, for example, determine that CBG-based HARQ feedback may be required. In an example, the WTRU may determine the type of CSI feedback based on, for example, the PUCCH configuration.

The PUCCH transmission may be multiplexed. In an example, the WTRU may be configured to multiplex multiple PUCCH transmissions. The multiplexing may be achieved, for example, by assigning multiple PUCCH transmissions to the same resources. The WTRU may be assigned different frequency division multiplexing, hopping patterns, and/or orthogonal cover codes (OCCs) for each of the multiple PUCCH transmissions.

The WTRU may be assigned resources for a plurality of PUCCH transmissions. For example, the resources may be conflicting resources. In an example, the WTRU may multiplex a plurality of UCIs on the same PUCCH resources. In an example, the WTRU may have a priority list associated with the UCIs. The WTRU may discard UCIs or feedback with a lower priority. In an example, the WTRU may have a priority list associated with the UCIs and may use the PUCCH resources for the UCI with the highest priority and may use a different set of PUCCH resources (e.g., a backup set of PUCCH resources) to transmit a different UCI. In an example, the WTRU may use the backup PUCCH resources for a plurality of UCI transmissions. In an example, each of the plurality of UCIs may be assigned a separate backup resource. The backup resources may provide multiplexing (e.g., efficient multiplexing). In an example, the PUCCH configuration for the UCIs may not use multiplexing. In an example, the backup configuration may use a multiplexing pattern that may provide multiplexing. In the example, the PUCCH configuration for UCI may include a BWP offset (e.g., in case of a collision with another UCI transmission). In the example, the synchronization parameters in the short PUCCH configuration (e.g., the position of the symbol(s)) may depend on the possibility of a collision with a UCI transmission. In the example, the PUCCH hopping configuration may depend on the occurrence of a collision.

Differentiated processing may be provided. A profile definition applicable to the transmission may be provided. The WTRU may process and transmit the UCI, for example, in accordance with a transmission profile (e.g., a specific transmission profile), which may be associated with the UCI. The transmission profile may be defined, for example, to ensure that the amount of resources and the assignment of priorities are consistent with reliability-related objectives for the UCI. By defining such a transmission profile, resources can be used efficiently.

In an example, a transmission profile may be associated with uplink data or direct connection data. For example, a transmission profile associated with uplink data or direct connection data may be used to allow prioritization between uplink data or direct connection data and UCIs with different profiles.

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

A transmission profile associated with UCI or uplink data may be determined, for example, based on one or more of the following: (i) a logical channel or a group of logical channels from which data may be transmitted based on a higher layer configuration (e.g., a transmission profile may be configured for each logical channel or a group of logical channels, or the WTRU may determine a transmission profile based on a logical channel (LCH) configuration for one or more physical layer characteristics for a given transmission, such as a transmission duration or a similar characteristic); (ii) a logical channel or a group of logical channels of data that may have initiated SR; (iii) a value of a field in the DCI that may be associated with the transmission of UCI or uplink data (e.g. a direct indication of the transmission profile or an implicit indication based on an existing field (e.g. a HARQ process index) or a field that may be used to determine the priority of a logical channel (e.g. for uplink provisioning) or a value of the Radio Network Temporary Identifier (RNTI) that may be applied to mask a cyclic redundancy check (CRC)); (iv) a characteristic of the PDCCH that may be associated with the transmission of UCI or uplink data (e.g. a CORESET, a monitoring period, a determination of whether to monitor the PDCCH at the beginning of an interval, a search space or a level of aggregation that may be used to decode the PDCCH, or a portion of the bandwidth), such as where the transmission profile can be configured (e.g. by higher layers) for some CORESET (e.g. each CORESET) or a PDCCH configuration (e.g. the configuration of each PDCCH); (v) higher layer signaling (e.g. for CSI) and/or a field in the DCI that may indicate a set of parameters, e.g. configured by higher layers (e.g. a CSI report parameter that may be indicated in an aperiodic CSI field); (vi) any characteristic of the PDSCH transmission or any characteristic associated with the PDSCH transmission, such as a duration, a portion of bandwidth, a characteristic of a numerical value (e.g. subcarrier spacing, symbol duration, etc.), a transmit configuration indication (TCI) state (e.g. for HARQ-ACK), a modulation and coding scheme (MCS) table configured or indicated for control information (e.g. DCI) associated with the PDSCH transmission; (vii) any characteristic of the PUCCH resource or any characteristic associated with the PUCCH resource configured for the SR transmission (such as a subcarrier spacing, a PUCCH resource duration, a logical channel associated with the SR configuration or any of its characteristics such as a priority, and/or a transmission profile explicitly configured as part of the SR configuration); (viii) any characteristic of the PUSCH grant or transmission or any characteristic associated with the grant or transmission of the PUSCH (e.g. for uplink data), such as any characteristic used to define a logical channel constraint to determine the priority of the logical channel (e.g. a PUSCH transmission duration, any characteristic of a numerical quantity (e.g. a subcarrier spacing, a symbol duration), or any characteristic of a carrier); or (ix) the portion of the bandwidth on which the corresponding PDSCH transmission or PUSCH transmission is transmitted. With respect to (iv), the transmission profile may have a priority based on a priority order that may be configured. For example, the transmission profile may have a priority based on a configured priority order if the PDCCH candidate is part of search spaces associated with more than one transmission profile. With respect to (i), the transmission profile associated with the UCI may be determined based on some attribute (e.g., QoS metric data) associated with the logical channel or group of logical channels from which the data may be transmitted. With respect to (v), a BLER target value may be configured for some CSI report parameter. The BLER target value may implicitly indicate a transmission profile. For example, a lower BLER target value may indicate a transmission profile with a higher priority. In an example, the CQI report table may be configured to customize the CSI report.

The DCI or downlink data transmission profile may be determined, for example, based on one or more of the following: (i) any characteristic of the PDCCH from which the DCI can be decoded or from which the downlink data assignment can be decoded, for example as described herein for the UCI or uplink data (e.g., search space, explicit configuration, etc.); (ii) a modulation and coding scheme (MCS) table indicated for control information (e.g., in the DCI) that is associated with the PDSCH transmission; such an indication may be configured by higher layers or may be included in one of the fields of the DCI; (iii) a value of a field in the DCI that may be associated with the downlink data transmission, or an RNTI value that may be used for CRC masking; or (iv) any characteristic of the purpose or characteristic related to the purpose of the PDSCH transmission (e.g., for downlink data), such as the duration of the PDSCH transmission, and/or any characteristic of a numerical quantity (e.g., subcarrier spacing, symbol duration, etc.).

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

The profile definition may indicate a timing characteristic. In an example, a transmission profile may be associated with a timing characteristic. Such a timing characteristic may correspond to at least one of the following: (1) scheduling-related delay components, for example, such a component may correspond to one of N1 or N2; (2) processing time in the WTRU, for example, such processing time may correspond to one of N1 or N2; (3) a transmission start symbol; or (4) a transmission duration. N1 and/or N2 may be a series of OFDM symbols as described herein. In an example, the transmission profile may correspond to a transmission for which one or more of such timing characteristics may be provided up to a certain value. The particular value may represent one aspect of the WTRU configuration. The transmission profile may be associated with at least one priority level or at least one parameter defining channel access characteristics for operation in an unlicensed band. For example, the at least one parameter may include a maximum contention window size or a delay duration.

Processing of transmission characteristics may be provided based on some profile (e.g., a transmission profile). Coding aspects, transmission power, and/or resource selection or allocation may be determined, for example, based on a transmission profile, as described in this document.

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

In an example, the WTRU module may be implemented with a CRC equal to 16 bits for the PDCCH, for example, when the higher-level configuration for the PDCCH may indicate the first transmission profile. The WTRU may be implemented with a CRC equal to 24 bits, for example, when the configuration may indicate the second transmission profile. By using a variable CRC size, for example, the network can use more reliable transmission of the PDCCH when this may be required in accordance with the characteristics of the data being transmitted.

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

The transmit power may be determined based on a transmit profile. In an example, the WTRU may determine and apply the transmit power associated with a transmission. The transmit power may be determined using a formula and/or based on parameters that may depend on the transmit profile. In an example, the parameters that may be used in the power control formula may be configured (e.g., independently configured) for each transmit profile. In an example, the power control parameter may be based on an offset value that may be configured using the transmit profile. In an example, the interpretation of the TPC field (e.g., based on a number of dB decreases or increases) may depend on the transmit profile. Applying the transmit profile to determine the transmit power may facilitate applying an appropriate power level to achieve a target reliability associated with the transmission (e.g., each transmission).

In the example, the power control parameters applied to the scheduling request (SR) transmission may depend on the SR configuration. The SR configuration may be associated with any logical channel that may have initiated the SR.

In an example, the power control parameters applied to the HARQ-ACK transmission may depend on the duration of the corresponding PDSCH transmission. For example, when the PDSCH transmission decreases below a threshold configured by higher layers, the WTRU may apply a first set of power control parameters. When the PDSCH transmission exceeds the threshold, the WTRU may apply a second set of power control parameters.

In an example, the power control parameters applied to the HARQ-ACK transmission may depend on the portion of the UL bandwidth (e.g., the active portion of the bandwidth) over which the HARQ-ACK is transmitted, or on the portion of the DL bandwidth over which the corresponding PDSCH is transmitted. Each portion of the bandwidth may be implemented with a set of power control parameters specified by higher layers.

In an example, the power control parameters applied for transmitting CSI on the PUCCH (or PUSCH) may depend on the BLER target value configured for the CSI reporting parameter. For example, the WTRU may apply a power offset based on the BLER target value. The BLER target value may be configured at higher levels, for example, for each of the BLER targets. The power offset may be configured, for example, for each CSI reporting parameter.

Data or UCI with multiple transmission profiles can be multiplexed into one transmission. Power control parameters for the overall transmission can be determined, for example, based on a profile, such as the profile with the highest priority level.

In an example, the power management parameters may include a specific power management mode (PCM) or a minimum guaranteed power level. For example, a PCM may include PCM1, PCM2, etc.

The selection or allocation of a resource may be determined, for example, based on a transmission profile. In an example, the resource and/or format that may be used for transmission may be a function of the transmission profile. For example, in the case of PUCCH, the set of resources and/or the format indicated by the ARI indicator may depend on a transmission profile. For example, the network may configure at least one set of resources for a transmission profile, such as for each transmission profile. A set of resources that may be subject to lower interference may be associated with transmission profiles that may be applied for transmissions with higher reliability.

In an example, the use of a long or short PUCCH format and/or a number of symbols may be a function of a transmission profile. In an example, a WTRU may be configured to transmit PUCCH on a plurality of symbols (e.g., two symbols) for a transmission profile (e.g., a first transmission profile), which may be suitable for ultra-reliable traffic. The WTRU may be configured to transmit PUCCH on some symbol (e.g., one symbol) for another transmission profile (e.g., a second transmission profile), which may be suitable for other mobile broadband traffic that is not ultra-reliable.

In an example, a set of bandwidth portions and a numerical value (e.g., including one or more of a subcarrier spacing, a cyclic prefix duration, or a number of symbols per slot or mini-slot) may be used for downlink transmission or uplink transmission within a carrier and may, for example, depend on a transmission profile.

In the example, the signal may depend on the transmission profile. For example, the signal may be an orthogonal frequency division multiplexing (OFDM) signal or a single-carrier frequency division multiple access (SC-FDMA) signal. In the example, the use of frequency hopping may depend on the transmission profile.

In an example, with respect to at least one type of UCI (e.g., HARQ-ACK), the UCI may be transmitted on PUCCH or multiplexed using data transmitted on PUSCH. The choice of whether to transmit the UCI on PUCCH or multiplexed using data transmitted on PUSCH may depend on transmission profiles associated with the UCI and the data. In an example, the UCI may be multiplexed using data transmitted on PUSCH, such as when the UCI and data may have the same transmission profile or the same priority level associated with the transmission profile. The UCI may be transmitted separately on PUCCH. In an example, at least one type of UCI (e.g., channel state information (CSI)) may be discarded.

In an example, a certain number or part of the resource elements that can be used by at least one UCI type (e.g., when multiplexing using data on the PUSCH) can be determined, for example, by one or more factors (e.g., beta parameters). Such factors can depend on the transmission profile. In an example, for a given UCI type, the WTRU can be configured with a first set of factors that can be applied to a first transmission profile, and a second set of factors that can be applied to a second transmission profile. A transmission profile that can be suitable for ultra-reliable traffic can, for example, provide the ability to use a greater part of the PUSCH resources.

In an example, the WTRU may determine whether to apply UCI diversity. For example, the SR configuration may include a configuration of PUCCH resources applicable to UCI diversity (or a PUCCH diversity resource). For example, when an SR is initiated by a logical channel (LCH) mapped to such an SR configuration, the WTRU may transmit the SR on two or more PUCCH resources (or a PUCCH diversity resource).

Prioritization between transmissions may be provided. In an example, a priority level may be defined or configured for a transmission profile (e.g., for each transmission profile). The priority level may be used, for example, to determine whether one or more transmissions may be dropped or replaced, reduced in power, processed later, or may be assigned fewer resources, for example, in the case of contention. The occurrence of contention may be beneficial (e.g., from a systems approach perspective), for example, by being able to use a larger share of system resources (e.g., compared to a situation where resources may be reserved).

Prioritization may be provided for power scaling. In an example, the WTRU may reduce the power of at least one transmission, for example, when a configured total maximum power may be exceeded for a certain period of time (for example, during a subframe, interval, or mini-slot). The order of priorities for scaling may depend on a transmission profile (for example, in addition to other criteria, such as UCI or data type). In an example, a transmission profile criterion may take precedence over or supersede other criteria. In an example, if a first transmission profile has a higher priority level than a second transmission profile, a PUSCH, which may include data to be transmitted according to the first transmission profile, may be allocated power before a PUCCH, which may include a HARQ-ACK to be transmitted according to the second transmission profile. Prioritization based on the use of a transmission profile may be applied even if the HARQ-ACK may otherwise receive a higher priority than the data.

Priority determination may be provided for discarding a transmission or at least some portion of a transmission. In an example, the WTRU may determine whether two or more transmissions may overlap a subset of resources and whether a portion of at least one of the transmissions may be discarded or replaced, for example, based on transmission profiles associated with the overlapping transmissions. The WTRU may, for example, determine whether a transmission may be transmitted on a transmission resource with the highest priority (for example, based on the transmission profile).

The overlap may occur due to, for example, scheduling commands that may be received at different times and with different latency requirements. In an example, the WTRU may receive a downlink assignment that may require transmission of a HARQ-ACK on a PUCCH in certain symbols of a certain interval. The WTRU may receive a grant (e.g., sequentially receive a grant) to transmit a PUSCH for the same interval. The WTRU may determine that the PUSCH transmission has priority over the PUCCH transmission, for example when the transmission profile associated with the uplink data that may be transmitted on the PUSCH has a higher priority level than the transmission profile associated with the HARQ-ACK that may be transmitted on the PUCCH. Based on such determination, the WTRU may use overlapping resources for PUSCH transmission and may discard the PUCCH transmission. In an example, the WTRU may transmit PUCCH on the overlapping resources. The WTRU may use the remaining resources that may be indicated for PUSCH, e.g. taking into account the reduced number of resources, in the rate matching calculations.

The WTRU may receive a first downlink assignment indicating transmission of a HARQ-ACK on a PUCCH in a first resource. The WTRU may receive (e.g., sequentially receive) a second downlink assignment indicating transmission of a HARQ-ACK on a PUCCH in a second resource. The WTRU may transmit a HARQ-ACK corresponding to a PDSCH (or PDCCH) with a transmission profile with a higher priority, such as when the first resource and the second resource overlap or coincide. The WTRU may transmit a HARQ-ACK corresponding to a PDSCH (or PDCCH) based on, for example, a CORESET, a search space, and/or an RNTI.

In an example, a WTRU may receive a grant for a PUSCH in an interval. The WTRU may receive (e.g., sequentially receive) a downlink assignment (or initiate a scheduling request) that may require transmission of a PUCCH on one or more resources of the same interval (e.g., on the last symbols of time for a short PUCCH or on one or more symbols of time (e.g., most or all symbols of time) available for the uplink for a long PUCCH). The WTRU may determine whether to transmit the PUCCH on an overlapped resource, for example when the PUCCH includes a UCI associated with a transmission profile that has a higher priority than the data transmitted on the PUSCH. The WTRU may determine whether to discard the PUSCH or whether to transmit the PUSCH on a non-overlapped resource, for example, by applying puncturing to the overlapped resource. The course of action may depend on the type of replacement transmission (e.g. PUSCH transmission is still possible even after replacement by a short PUCCH) and/or on the possibility of a portion of the previously used resources exceeding the threshold.

The WTRU may multiplex the HARQ-ACK and CSI into a single PUCCH transmission or a PUSCH transmission and determine to select a subset of the CSI report(s) (e.g., _Nreported ^CSI ) based on a maximum code rate that can be configured. The priority order for the CSI report(s) may depend on the transmission profile (or configured BLER target) such that a CSI report associated with a lower BLER target may be considered to have a higher priority than a CSI report associated with a higher BLER target. The priority determined from the BLER target or the transmission profile may have a higher priority than at least one of the other priority assignment criteria used to select the CSI reports, such as the CSI type. For example, this may result in a higher overall priority than the RI (rank information) of the precoding matrix information (PMI) of a CSI report associated with a lower target BLER value than of a CSI report associated with a higher target BLER value.

Prioritization may be provided for processing DL data. In an example, a WTRU may be programmed to receive DL data with different transmission profiles from at least one PDSCH and may report a HARQ-ACK (e.g., at certain times) associated with the DL data. The WTRU may not be able to complete decoding of at least one code block in time to transmit the corresponding HARQ-ACK. The WTRU may determine the decoding priority of DL data with a higher priority, e.g., according to the transmission profile associated with the DL data.

In an example, the HARQ-ACK may be transmitted prior to decoding of at least one group of code blocks for a transport block. Depending on the transmission profile associated with the data, the WTRU may set the HARQ-ACK in one of the following ways. The WTRU may set the HARQ-ACK for a not yet decoded group of code blocks to "ACK", for example, when decoding may be completed, and may set it to "NACK" for at least one other group of code blocks of the transport block. The WTRU may set the HARQ-ACK to "ACK" for one or more groups of code blocks other than those for which this acknowledgment may be set to "NACK". This may minimize the number of resources that may be used by the network for retransmissions, for example in the case where the transmission of some not yet decoded code blocks may be successful and retransmissions are not required. This example procedure may be selected, for example, for a transmission profile that may have a lower priority.

In an example, the WTRU may set the HARQ-ACK acknowledgement of a yet to be decoded group of code blocks to "NACK". This may minimize the delay in the delivery of a transport block, for example, when retransmitted data is available earlier, for example in the case of a decoding failure. This example procedure may be selected, for example, for a transmission profile that may have a higher priority.

Prioritization may be provided for resource sharing. In an example, the WTRU may be configured to multiplex UCI and/or uplink data according to different transmission profiles in (e.g., the same) PUSCH transmission or PUCCH transmission. The proportion of a resource (e.g., resource elements (RE)) that may be allocated to UCI or data according to a transmission profile may depend on the relative priority levels of the transmission profiles. In an example (e.g., when multiplexing UCI in PUSCH), a first beta value for a UCI type may be applied, for example, when the priority of a transmission profile associated with UCI is higher than the priority of a transmission profile associated with data. A second beta value may be applied, for example, when the transmission profiles have the same priorities. A third value may be applied, for example, when the priority of a transmission profile associated with UCI is lower than the priority associated with a data transmission profile.

The selection of the MCS payload may be based on priority. In an example, the WTRU may be configured to apply a first modulation and coding scheme, transport block size, and/or payload for a transmission, such as when the transmission may not conflict with a transmission having a higher priority according to a transmission profile. The WTRU may be configured to apply a second modulation and coding scheme, transport block size, or payload for a transmission, such as when the transmission conflicts with a transmission having a higher priority according to a transmission profile. The conflict may correspond to a situation such as when multiple transmissions may overlap or when a configured maximum total transmit power may be exceeded.

Differentiated processing may be provided based on a state. In an example, the WTRU may apply a set of parameters corresponding to a transmission profile (e.g., based on a state of the transmission profile). The state of the transmission profile may be changed by an indication from the network. For example, the state of the transmission profile may be changed using a MAC control element (MAC CE) or using downlink control information (DCI). The state of the transmission profile may be changed upon the occurrence of an event, such as the expiration of a timer (e.g., a lead timer (TA)). 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 the proportion of resource elements used for UCI in the PUSCH, etc.

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

In an example, the WTRU may receive a DCI indicating a change in a portion of the active bandwidth (e.g., where the new portion of the active bandwidth and the existing portion of the active bandwidth may have the same configuration except for at least the transmission profile and related parameters). For example, the WTRU may be configured with two portions of bandwidth having the same frequency allocation. When the WTRU receives an indication of a change in the portion of the active bandwidth (e.g., when this condition is met), the WTRU may receive the PDSCH in the same slot as the slot in which the DCI is received, based on the parameters indicated in the DCI (e.g., as if the portion of the active bandwidth did not change). In an example, if the WTRU receives an indication of a portion of the active bandwidth in which the new portion of the active bandwidth does not have the same frequency allocation as the existing portion of the active bandwidth, the WTRU may apply a gap when receiving the PDSCH (e.g., to allow for fallback and/or perform other actions (e.g., measure CSI on the new portion of the active bandwidth)).

Systems, methods, and means may be provided for handling transmission characteristics with overlap between a plurality of transmissions. A WTRU may determine whether there is a time overlap between a plurality of transmissions, such as a first transmission and a second transmission. The WTRU may perform at least one of the following actions: (1) performing a subset (e.g., one) of one of the transmissions; (2) canceling, discarding, or aborting (e.g., if already in progress) one of the transmissions; (3) pausing and/or delaying one of the transmissions; (4) performing both transmissions and/or applying power scaling functions to the at least one transmission, such as when there is no frequency overlap between the transmissions; or (5) changing at least one characteristic of the first transmission, such as to transmit at least a portion of information that could otherwise be transmitted using the second transmission. For example, the WTRU may change any characteristic of a demodulation reference signal (DM-RS) for the first PUSCH transmission to indicate a scheduling request (SR). For example, the change may include assigning zero power, switching to a second preconfigured resource, changing the phase, etc. The WTRU may perform such action in combination with assigning zero power to a second transmission, such as SR on PUCCH, which might otherwise overlap in time.

In other examples of transmissions described herein, the first transmission may include an SR and the second transmission may include a PUSCH (or PUCCH). The SR associated with high priority traffic may be multiplexed with the PUSCH or the PUCCH. The WTRU may indicate and/or transmit uplink control information, such as an SR associated with the first transmission profile, by changing at least one transmission characteristic associated with a second transmission profile, such as a PUSCH transmission or a PUCCH transmission. 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 scheduling request periodicity for the first transmission profile. The duration of the PUSCH transmission or the PUCCH transmission may be such that waiting for the PUSCH transmission or the PUCCH transmission to end before transmitting the SR may exceed a delay value (e.g., an acceptable delay value).

At least one characteristic of the transmission that can be changed may include some 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 have a first value, for example, when there is no SR transmission. The relative phase may have a second value when a scheduling request is transmitted.

At least one transmission characteristic that can be changed can include some parameter of the transmit power of at least one symbol of time (or resource element). For example, the transmit power of at least one symbol can be reduced compared to the transmit power of the remaining symbols when transmitting the SR. In an example, the transmit power of at least one symbol can be reduced to zero, and/or the WTRU can not transmit at least one symbol. Due to this, the network can reliably detect the SR transmission, and the PUSCH can be successfully decoded.

At least one time symbol (or resource element) on which transmission can be changed can be limited to a subset of the transmission time symbols. For example, when transmitting an indication by changing some characteristic of a reference signal, the time symbols can be limited to the time symbols transmitting such a reference signal. The time symbols affected by this change can include the time symbols (e.g., all the time symbols) transmitting the reference signal after the initiation of the SR. In an example, when transmitting an indication by changing the transmission power of at least one time symbol, the subset can be determined based on a configured periodicity of the scheduling request. The at least one time symbol affected by this change can include one or more time symbols (e.g., all the time symbols) immediately after the initiation of the SR, which can coincide with the configured events of the scheduling request. In an example, one or more time symbols including the reference signals can be excluded from the subset.

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 initiated since the start of the transmission. The WTRU may be configured with at least one indicated subset of resource elements regularly (e.g., periodically) generated in the time domain. Such a configuration may depend on a configured SR periodicity or may coincide with configured events for transmitting SR. In a given subset, the WTRU may transmit a first predetermined sequence of modulated symbols, for example, if SR has not been initiated until an offset before the time symbol(s) of the subset. The WTRU may transmit a second predetermined sequence of modulated symbols, for example, after SR has been initiated. A predetermined sequence may be written over (e.g., by puncturing) modulated PUSCH or PUCCH symbols that may be mapped (e.g., pre-mapped) to subsets of resource elements, or subsets of resource elements may be initially excluded from the set of resource elements to which modulated PUSCH or PUCCH transmit symbols are mapped.

Systems, methods and means may be provided for processing transmission characteristics based on time that can be provided. One or more aspects may be defined as a function of available processing of the WTRU, such as the processing time of the WTRU.

The WTRU may determine whether it can apply at least one priority or multiplexing decision. The priority or multiplexing decision may be a function of one or more timing aspects, including, for example, at least one of the following: (1) a timing aspect when data may be available for transmission, or when data available for transmission may trigger a BSR transmission and/or an SR transmission; (2) a timing aspect when a scheduling request (SR) may be started; (3) a timing aspect during which downlink control information indicative of an uplink transmission (e.g., a PUSCH transmission or a PUCCH transmission) may be received; (4) a timing aspect of receiving higher layer signaling, for example at least in the case of a configured grant or other periodic or semi-persistent transmission (e.g., CSI, SRS); (5) a timing aspect during which a start (and/or end) of a PUSCH transmission may be scheduled according to a configured or dynamic grant; (6) a time aspect at which a PUCCH transmission may start (and/or end), such as in accordance with a semi-static configuration or an indication from downlink control information; (7) a duration of a PUSCH or PUCCH transmission; or (8) a time aspect at which it may be determined that, for some other reasons, such as reception of a paging request, initiation of a procedure such as RRC connection reestablishment, etc., a transmission may be performed in the future. In case of (1), for example, the WTRU may make such a determination when new data may become available for transmission for a logical channel (LCH) of a certain priority level and/or type, or when data available for transmission may trigger transmission of a buffer status report (BSR) and/or SR. The WTRU may make such a determination for data associated with a mapping constraint (e.g. a mapping constraint of an LCH to a transmission), a profile, and/or an LCH/logical channel group (LCG) priority.

The WTRU may make such a determination of the application of at least one prioritization or multiplexing decision for data and/or for a transmission associated with a particular mapping constraint (LCH to transmission), a particular profile, and/or a particular LCH/LCG priority. For example, the WTRU may determine a prioritization or multiplexing decision that may be applied in 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 the first transmission and the time when the presence of the second transmission is determined, as described herein.

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

One or more time intervals may be provided to indicate a possible dependency of the SR trigger signal on the applicability of the grant. Event A may correspond to an autonomous trigger signal of the WTRU associated with the reception of downlink control signaling and/or to some event that may correspond to a higher priority than the priority of event B (e.g., based on the corresponding transmission profile). The autonomous trigger signal may be one of the timing aspects described herein, such as the initiation of SR upon the availability of new data for transmission. Event B may correspond to a scheduled event (e.g., uplink transmission).

In step 1, the WTRU may determine that the available time is sufficient to perform an action on the scheduling information and/or to determine the priority of one of the two events before the start of the event with a lower priority. In step 2, the WTRU may determine that the available time is insufficient to change the schedule of its transmissions and/or to determine the priority of one of the two events before the start of the event with a lower priority, so it may determine to change the characteristic of the corresponding current transmission instead. The WTRU may be configured with a value of x, for example by RRC, where x may be a time value in symbols, in frame units (e.g. mini-slots, slots, sub-frames) or in absolute time units, for example milliseconds.

In an example, event A may correspond to an initiating SR signal for data associated with a transmission profile, such as a transmission profile corresponding to URLLC data transmission. Event B may correspond to the start of uplink transmission on the PUSCH channel for data associated with a transmission profile, such as a transmission profile corresponding to eMBB data transmission.

Action 1 may correspond to canceling an uplink transmission, such as a PUSCH transmission corresponding to the eMBB data, and the WTRU performing an SR transmission using a resource/method corresponding to the URLLC data type. Action 2 may correspond to setting a power cancellation/drop/zeroing of one or more specific symbols and/or DM-RS modification of the PUSCH transmission for the eMBB data, such as to indicate an SR for the URLLC, as described herein.

In an example, one of the transmissions may correspond to a first transmission profile or a similar profile, such as a URLLC service, and the other may correspond to a second transmission profile, such as an eMBB service. In such an example, if the WTRU determines that the available processing time is sufficient (e.g., if the time between two events is less than x), and if the WTRU determines this before starting any one of the transmissions that at least partially overlap, the WTRU may perform at least one of the following actions for different combinations of signals: (1) the WTRU may prioritize SR (for URLLC), discard PUSCH (for eMBB); (2) the WTRU may add and/or puncture PUSCH (for eMBB) with SR (for URLLC), such as using a similar concatenation principle applied for UCI on PUSCH for LTE; (3) The WTRU may embed the transmission, such as discarding part of the PUSCH (for eMBB) and replacing it with sPUSCH (including BSR (for URLLC)); (4) The WTRU may generate the SR signal by changing the DM-RS sequence in the PUSCH (for eMBB); (5) The WTRU may modify the UL PC, such as applying power scaling, such as when the WTRU is power limited.

In an example, if the WTRU determines that the available processing time is sufficient (e.g., if the time between two events is less than x), or if the WTRU does not determine this before starting any one of the transmissions that at least partially overlap, the WTRU may perform at least one of the following actions for various combinations of signals: (1) the WTRU may replace/interrupt or puncture the current PUSCH (for eMBB), and the WTRU may transmit SR (for URLLC) using an associated resource, such as on a short PUCCH in its place, transmit BSR (for URLLC), such as on a short PUSCH (for URLLC) in its place, and/or transmit URLLC TB, such as on a short PUSCH (for URLLC) in its place; (2) the WTRU may output the SR signal by changing the DM-RS sequence for the current PUSCH (for eMBB); (3) The WTRU module may change the UL PC accordingly (e.g. by strengthening the DM-RS signal).

In an example, the WTRU may initiate an additional transmission on the same carrier, such as if the WTRU is configured with simultaneously operating PUSCH+PUSCH or PUSCH+PUCCH channels. The WTRU may send the additional transmission in the same portion of the bandwidth or in different portions of the bandwidth, such as if they are configured and/or active. The WTRU may perform such transmission using unrelated resources and/or related resources. Unrelated resources may include separate PUSCH and/or PUCCH transmissions that may be initiated in conjunction with other ongoing transmission(s). Related resources may be used, such as when URLLC is configured and/or any grant for another type of traffic (e.g., with a lower priority) may include resources for additional SR, BSR transmissions.

The WTRU may allocate power using one or more power management functions. The WTRU may consider transmissions that may be transmitted with at least partial overlap in time, but for which the WTRU may not have determined whether such a transmission will be transmitted or not. The WTRU may include the following factors in determining whether to transmit such a transmission: an appropriate priority in the power allocation function, a method and/or resources that can be applied, such as when transmitting under a maximum power reduction (MPR) parameter.

The systems and/or methods described herein may be implemented in a computer program, software and/or firmware recorded in a machine-readable medium for execution by a computer and/or a processor. Examples of machine-readable medium may include electronic signals (transmitted over wired and/or wireless connections) and/or machine-readable storage media. Examples of machine-readable storage media may include read-only memory (ROM), random access memory (RAM), a register, a high-speed buffer memory, semiconductor data storage devices, magnetic media such as, but not limited to, internal hard drives and removable disks, magneto-optical media and/or optical media such as CD-ROMs and/or digital versatile discs (DVDs). The processor in combination with software may be used to implement a radio frequency transceiver intended for use in a WTRU, a terminal, a base station, an RNC and/or any host computer.

Claims (39)

1. A wireless transmit/receive unit (WTRU) comprising: a processor configured to: receiving a first transmission on a physical downlink control channel (PDCCH) comprising first downlink control information (DCI), wherein the first DCI indicates a first priority level associated with a scheduled first transmission on an uplink channel; receiving a second transmission on the PDCCH containing a second DCI, wherein the second DCI indicates a second priority level associated with the scheduled second transmission on the uplink channel; and transmitting information associated with one or more transmissions from a scheduled first uplink transmission or a scheduled second uplink transmission, wherein: provided that the first priority level associated with the scheduled first transmission on the uplink channel coincides with the second priority level associated with the scheduled second transmission on the uplink channel, and the first set of resources associated with the scheduled first transmission on the uplink channel overlap with the second set of resources associated with the scheduled second transmission on the uplink channel, it is possible to: transmitting common information, wherein the common information includes information associated with a scheduled first transmission on an uplink channel, which is combined with information associated with a scheduled second transmission on an uplink channel. 2. The WTRU of claim 1, wherein, provided that the first priority level associated with the scheduled first transmission on the uplink channel is higher than the second priority level associated with the scheduled second transmission on the uplink channel, and the first set of resources associated with the scheduled first transmission on the uplink channel overlaps with the second set of resources associated with the scheduled second transmission on the uplink channel, the processor is further configured to: discarding the scheduled second transmission on the uplink channel; and transmission of information related to the scheduled first transmission on the uplink channel. 3. The WTRU of claim 1, wherein the common information is transmitted using transmission on an uplink control channel or transmission on a common uplink channel. 4. The WTRU of claim 2, wherein the scheduled first transmission on the uplink channel is transmitted using a transmission on an uplink control channel or a transmission on a shared uplink channel. 5. The WTRU of claim 1, wherein the first DCI or the second DCI is associated with transmission on a physical downlink shared channel (PDSCH). 6. The WTRU of claim 5, wherein the first priority level is associated with a physical downlink shared channel (PDSCH) on which the PDSCH transmission is received or with a physical uplink control channel (PUCCH) on which a feedback signal associated with the PDSCH transmission is transmitted. 7. The WTRU of claim 1, wherein the first scheduled transmission on the uplink channel is a first transmission on the PUCCH channel, and the second scheduled transmission on the uplink channel is a second transmission on the PUCCH channel. 8. The WTRU of claim 1, wherein the first DCI or the second DCI is associated with a transmission on a physical uplink shared channel (PUSCH). 9. The WTRU of claim 1, wherein the scheduled first transmission on the uplink channel is a transmission on a physical uplink control channel (PUCCH) and the scheduled second transmission on the uplink channel is a transmission on a physical uplink shared channel (PUSCH). 10. The WTRU of claim 1, wherein the first priority level or the second priority level is associated with a transmission profile. 11. The WTRU of claim 1, wherein the information associated with the scheduled first transmission on the uplink channel includes control information and the information associated with the scheduled second transmission on the uplink channel includes control information or data information. 12. The WTRU of claim 11, wherein the control information comprises HARQ (Hybrid Automatic Repeat Request) feedback information or uplink control information (UCI), and wherein the data information comprises data transmitted on the uplink. 13. A method associated with transmitting information over an uplink channel, wherein the method comprises: receiving a first transmission on a physical downlink control channel (PDCCH) comprising first downlink control information (DCI), wherein the first DCI indicates a first priority level associated with a scheduled first transmission on an uplink channel; receiving a second transmission on the PDCCH containing a second DCI, wherein the second DCI indicates a second priority level associated with the scheduled second transmission on the uplink channel; and transmitting information associated with one or more transmissions of a scheduled first uplink transmission or a scheduled second uplink transmission, wherein: provided that the first priority level associated with the scheduled first transmission on the uplink channel coincides with the second priority level associated with the scheduled second transmission on the uplink channel, and the first set of resources associated with the scheduled first transmission on the uplink channel overlap with the second set of resources associated with the scheduled second transmission on the uplink channel, it is possible to: transmitting common information, wherein the common information includes information associated with a scheduled first transmission on an uplink channel, which is combined with information associated with a scheduled second transmission on an uplink channel. 14. The method of claim 13, wherein, provided that the first priority level associated with the scheduled first transmission on the uplink channel is higher than the second priority level associated with the scheduled second transmission on the uplink channel, and the first set of resources associated with the scheduled first transmission on the uplink channel overlaps with the second set of resources associated with the scheduled second transmission on the uplink channel, the following is provided: discarding the scheduled second transmission on the uplink channel; and transmission of information related to a scheduled first transmission on an uplink channel. 15. The method of claim 13, wherein the common information is transmitted using transmission on an uplink control channel or transmission on a common uplink channel. 16. The method of claim 14, wherein the scheduled first transmission on the uplink channel is transmitted using a transmission on an uplink control channel or a transmission on a shared uplink channel. 17. The method of claim 13, wherein the first DCI or the second DCI is associated with transmission on a physical downlink shared channel (PDSCH). 18. The method of claim 17, wherein the first priority level is associated with a physical downlink shared channel (PDSCH) on which the PDSCH transmission is received, or with a physical uplink control channel (PUCCH) on which a feedback signal associated with the PDSCH transmission is transmitted. 19. The method of claim 13, wherein the first scheduled transmission on the uplink channel is a first transmission on the PUCCH channel, and the second scheduled transmission on the uplink channel is a second transmission on the PUCCH channel. 20. The method of claim 13, wherein the first DCI or the second DCI is associated with transmission on a physical uplink shared channel (PUSCH). 21. The method of claim 13, wherein the scheduled first transmission on the uplink channel is a transmission on a physical uplink control channel (PUCCH), and the scheduled second transmission on the uplink channel is a transmission on a physical uplink shared channel (PUSCH). 22. The method according to claim 13, wherein the first priority level or the second priority level is related to a transmission profile. 23. The method of claim 13, wherein the information associated with the scheduled first transmission on the uplink channel includes control information, and the information associated with the scheduled second transmission on the uplink channel includes control information or data information. 24. The method of claim 23, wherein the control information includes HARQ (Hybrid Automatic Repeat Request) feedback information or uplink control information. (UCI), and in which the information in the form of data includes data transmitted on the uplink.