Method, apparatus and system for enhanced control signaling of ultra-reliable transmission

Abstract

To disclose a method to be executed in a wireless transmit / receive unit (WTRU).SOLUTION: A WTRU receives first and second Physical Downlink Shared Channels (PDSCH) associated with first and second types of service or priority level in first and second slots or mini slot, determines first and second Physical Uplink Control Channels (PUCCH) for first and second HARQ-ACK information, determines priorities of the first and second HARQ-ACK information, determines to allow that higher-priority HARQ information is multiplexed on lower-priority HARQ information on condition that the first and second PUCCH resources overlap in time and that priorities are different between the first and second HARQ information, and multiplexes the first and second HARQ information on condition that the multiplexing is allowed, to be transmitted within a single PUCCH transmission.SELECTED DRAWING: Figure 6

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE The embodiments disclosed herein relate generally to wireless communications, and for example, to methods, apparatus and systems for enhanced control signaling (eg, for ultra-reliable transmissions), for example based on service type. [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of priority to U.S. Patent Application No. 62 / 790,428, filed January 9, 2019, U.S. Patent Application No. 62 / 875,227, filed July 17, 2019, U.S. Patent Application No. 62 / 886,035, filed August 13, 2019, and U.S. Patent Application No. 62 / 931,389, filed November 6, 2019, the contents of each of which are incorporated by reference as if fully set forth herein.

[0003] Some networks can be implemented using network slicing principles, which may enable ultra-reliable transmission. Summary of the Invention

[0004] A method and apparatus are provided for operation by a wireless transmit / receive unit (WTRU) in a network. In one embodiment, the method may include the WTRU receiving a first physical downlink shared channel (PDSCH) associated with a first service type or first priority level in a first slot or first minislot and a second PDSCH associated with a second service type or second priority level in a second slot or second minislot, and determining a first HARQ codebook acknowledgement index (HCAI) based on properties of the first PDSCH or control information associated with the first PDSCH and a second HCAI based on properties of the second PDSCH or control information associated with the second PDSCH. The method may further include generating a first physical uplink control channel (PUCCH) including the first HARQ-ACK information according to the first HCAI, generating a second PUCCH including the second HARQ-ACK information according to the second HCAI, for a subsequent slot or a subsequent minislot, and transmitting the first and second PUCCHs. [Brief description of the drawings]

[0005] A more detailed understanding will be had from the following detailed description, given by way of example in conjunction with the drawings attached hereto. The figures in the description are examples. Thus, the figures and detailed description should not be considered limiting, as other equally valid examples are possible. Moreover, like reference numbers in the figures refer to like elements. [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1A is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A in accordance with an embodiment. [Figure 1C]FIG. 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A in accordance with an embodiment. [Figure 1D] FIG. 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A in accordance with an embodiment. [Diagram 2] A diagram showing time-frequency resources used to carry control signaling for ultra-reliable low latency communications (URLS) / enhanced URLLC (eURLLC) services and enhanced mobile broadband (eMBB) services. [Diagram 3] A diagram showing a representative set of bit fields used for eMBB services or URLLC / eURLLC services. [Figure 4] A diagram showing another representative set of bit fields used for eMBB services or URLLC / eURLLC services. [Diagram 5] A diagram showing various HARQ feedback timings. [Figure 6] FIG. 1 illustrates an exemplary procedure for using feedback information (eg, HARQ Codebook Acknowledgement Index (HCAI)). [Figure 7] FIG. 1 illustrates an exemplary transmission procedure after collision determination. [Figure 8] FIG. 1 illustrates an exemplary intra-WTRU prioritization process. [Figure 9] FIG. 1 illustrates a typical procedure for using overflow resources. [Figure 10] 1 is a flow chart illustrating an exemplary procedure for using feedback information (eg, HCAI). [Figure 11] 11 is a flow chart illustrating another exemplary procedure for using feedback information (eg, HCAI). [Figure 12]1 is a flowchart illustrating an exemplary procedure for time domain overlap (e.g., of eMBB and URLLC or enhanced URLLC information / control signaling). [Figure 13] 1 is a flowchart illustrating an exemplary procedure for using overflow resources for non-priority information / control signaling (eg, HARQ acknowledgment (HARQ-ACK)). [Figure 14] 1 is a flowchart illustrating an exemplary procedure for using bit field interpretation (eg, based on service type). [Figure 15] 1 is a flowchart illustrating an exemplary procedure for HARQ feedback (eg, based on service type). [Figure 16] 1 is a flowchart illustrating a representative overwriting procedure. [Figure 17] 1 is a flow chart illustrating an exemplary procedure for avoiding anticipated collisions. [Figure 18] 1 is a flow chart illustrating an exemplary multiplexing procedure. [Figure 19] 1 is a flowchart illustrating an exemplary procedure (eg, for transmission of uplink control information (UCI)). DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] Exemplary Network for Implementation of the Embodiments 1A illustrates an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tailed Unique Word DFT Spread OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multi-Carrier (FBMC), etc.

[0007] 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, which may all be referred to as “stations” and / or “STAs,” may be configured to transmit and / or receive wireless signals, and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain contexts), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c and 102d may be referred to interchangeably as UEs.

[0008] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B (eNB), a Home Node B (HNB), a Home eNode B (HeNB), a gNB, a NR Node B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each illustrated as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

[0011] More specifically, as discussed above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and WTRUs 102a, 102b, 102c in the RAN 104 / 113 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

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

[0013] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as New Radio (NR) radio access, which may establish the air interface 116 using NR.

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

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

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

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

[0018] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing Plain Old Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RANs 104 / 113 or a different RAT.

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

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

[0021] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

[0027] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding a 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 air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may collect location information via any suitable location determination method while remaining consistent with an embodiment.

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

[0029] The processor 118 of the WTRU 102 may be in operative communication with various peripherals 138 including, for example, one or more accelerometers, one or more gyroscopes, a USB port, other communications interfaces / ports, a display and / or any other visual / audio indicators to implement the representative embodiments disclosed herein.

[0030] The WTRU 102 may include a full-duplex radio, where the transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the UL (e.g., for transmission) and the downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference either through hardware (e.g., a choke) or signal processing via a processor (e.g., via a separate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio, where the transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or the downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

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

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

[0034] 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 will be appreciated that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0035] The MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during initial attachment 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 employ other radio technologies, such as GSM and / or WCDMA.

[0036] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during inter-eNodeB handover, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

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

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

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

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

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

[0042] When using an 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically set width via 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 some representative embodiments, for example in an 802.11 system, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented. For CSMA / CA, STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

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

[0044] A very high throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. A 40 MHz and / or 80 MHz channel may be formed by combining consecutive 20 MHz channels. A 160 MHz channel may be formed by combining eight consecutive 20 MHz channels or by combining two non-consecutive 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, the data after channel coding may be passed through a segment parser, which may split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The streams may be mapped onto two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed, and the combined data may be sent to the media access control (MAC).

[0045] Sub-1 GHz operation modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz and 20 MHz bandwidths in TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine type communication, such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including some capabilities, for example, some and / or limited bandwidth support (e.g., only support of it). MTC devices may include a battery with above-threshold battery life (e.g., to maintain extremely long battery life).

[0046] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be referred to as a primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the smallest bandwidth operating mode of all STAs operating in the BSS. In an 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., 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 other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) setting may depend on the status of the primary channel. For example, if the primary channel is busy due to a STA (that only supports 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band may be available while remaining idle.

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

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

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

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

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

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

[0053] 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 will be appreciated that any of these elements may be owned and / or operated by an entity other than a CN operator. The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and 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 slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service being utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency communications (URLLC) access, services relying on enhanced mobile (e.g., high capacity mobile) broadband (eMBB) access, services for machine type communications (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

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

[0056] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. 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 owned and / or operated by other service providers. In an embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

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

[0058] The emulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, the emulation device or devices may perform one or more, or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network for testing other devices within that communication network. The emulation device or devices may perform one or more, or all functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and / or may implement testing using over-the-air wireless communications.

[0059] The emulation device or devices may perform one or more functions inclusively while remaining unimplemented / undeployed as part of a wired and / or wireless communications network. For example, the emulation device may be utilized in a test lab and / or in a test scenario in an undeployed (e.g., for testing) wired and / or wireless communications network to implement testing of one or more components. The emulation device or devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0060] New Radio (NR) systems are expected to be deployed in 2020 and will include both eMBB and URLLC service types. These systems will be -5 The 3GPP standard is to support URLLC use cases with a BLER target of 100 Mbps and a latency of 1.0 ms. -6They have begun to study eURLLC with a BLER target of 0.5 ms and a latency of 0.5 ms.

[0061] Data transmission (max 10 -6 The requirement for low latency (on the order of 0.5 ms) and / or low latency (BLER of 10 ms) may affect the reliability requirements of control signaling in both the downlink and / or uplink. Having unreliable uplink control information messages may affect the reliability of downlink and / or uplink data transmissions. For example, unreliable HARQ-ACK feedback may result in a high probability of NACK vs. ACK or NACK / ACK loss detection. NR Rel-15 control signaling was designed to support both eMBB and URLLC traffic types. The WTRU 102 may multiplex control signaling for different services (e.g., services such as eURLLC, URLLC, eMBB and / or high capacity machine type communications (mMTC), among others) with different latency and reliability requirements within the same control message, which may affect the latency and / or reliability of a transmission (e.g., eURLLC transmission). For example, in a long format PUCCH, multiplexing URLLC HARQ feedback with eMBB HARQ feedback may result in increased latency (e.g., instead of sending low-latency related HARQ feedback in PUCCH over two symbols, it may be sent on PUCCH over a larger set of symbols (e.g., 14 symbols)), which may make it difficult to meet the 0.5 ms latency requirement.

[0062] In some representative embodiments, apparatus, methods, procedures and / or operations may be implemented to indicate to a WTRU 102 that supports different service types that and / or how to separate control signaling for each service type. Service type generally refers to the requirements of a given transmission, including, for example, latency, reliability, and / or priority, among others.

[0063] In some representative embodiments, the WTRU 102 may interpret the control signaling based on the service type.

[0064] In some representative embodiments, apparatus, methods, procedures and / or operations may be implemented by the WTRU 102 to determine when and how to interpret control signaling. For example, the WTRU 102 may be configured to interpret downlink control information bit fields based on a control channel configuration. The control channel configuration may include, among other things, (1) a search space monitoring pattern (e.g., within a slot), (2) a search space periodicity, and / or (3) a search space duration.

[0065] In addition to or instead of using a control channel configuration, the WTRU 102 may be configured to interpret a set of downlink control information (DCI) bit fields based on one or more values ​​of another or other set of DCI bit fields.

[0066] 2 is a diagram illustrating time-frequency resources used to carry control signaling for URLLC / eURLLC and eMBB services. Referring to FIG. 2, multiple time-frequency resources 200-1, 200-2...200-N may carry control signaling for multiple services (e.g., control DCI scheduling 210 for eMBB, DCI scheduling 220 for URLLC / eURLLC services, PDSCH 230 for eMBB, PDSCH 240 for URLLC / eURLLC services, and PUCCH 250 carrying HARQ-ACK feedback, among others). Time-frequency resource 200 may separately carry DCI scheduling 210 for eMBB and DCI scheduling 220 for eURLLC services, and may separately carry PDSCH 230 for eMBB and PDSCH 240 for URLLC / eURLLC services. The HARQ-ACK feedback 250 for the eMBB service and for the URLLC / eURLLC service may be multiplexed together and carried over the PUCCH. In some representative embodiments, the HARQ-ACK feedback for the eMBB service and the eURLLC service may be carried separately over the PUCCH.

[0067] 3 and 4 are diagrams illustrating a representative set of bit fields (e.g., four bit fields) used for eMBB or URLLC / eURLLC services. In FIG. 3, the bit fields (e.g., bit fields 1-4) associated with a first service type (e.g., URLLC / eURLLC service) are the same size as the corresponding bit fields (e.g., bit fields 1-4) associated with a second service type (e.g., eMBB service). In FIG. 4, the bit fields (e.g., bit fields 1-4) associated with a first service type (e.g., URLLC / eURLLC service) are not the same size as the corresponding bit fields (e.g., bit fields 1-4) associated with a second service type (e.g., eMBB service).

[0068] 3 and 4, when a first service type (e.g., URLLC / eURLLC service type) is determined by the WTRU 102, bit field 1 may be interpreted in a first manner, and when a second service type (e.g., eMBB service type) is determined by the WTRU 102, bit field 1 may be interpreted in a second manner. Bit fields 2-4 may be interpreted in the same manner for both the first and second service types. For example, the WTRU 102 may be configured to interpret the control information bit field differently depending on the service type being scheduled. Interpreting the DCI bit field differently may mean that for the same value of the bit field, the WTRU 102 may interpret the control information differently. For example, a "000" value of the HARQ timing bit field may indicate a first time value t1 for the first service type (e.g., URLLC / eURLLC service type) and a second time value t2 for the second service type (e.g., eMBB service type). The WTRU 102 may be configured to interpret differently a bit field, a subset of the bit fields (e.g., only the subset of the bit fields as illustrated, for example, by bit field 1 in Figures 3 and 4), or all of the bit fields in the DCI. As illustrated in Figures 3 and 4, bit field 1 (e.g., only bit field 1) is to be interpreted differently. For example, when and / or how the WTRU 102 may interpret control signaling based on the service type is disclosed herein.

[0069] Although in Figures 3 and 4 only bit field 1 is shown as being interpreted differently for different service types, any number of bit fields may be interpreted differently for different service types.

[0070] Although bit field 1 is shown as being interpreted differently for different service types, any bit field (bit field 1 or any other bit field) may be interpreted differently for different service types.

[0071] Representative triggers for different interpretations of control signaling fields In some representative embodiments, downlink and / or uplink control interpretation may be based on a control channel configuration.

[0072] In some embodiments, the WTRU 102 may be configured with one DCI size to monitor downlink control signaling for different service types (e.g., the WTRU 102 may be configured to determine / interpret the DCI fields based on the control channel configuration on which the DCI is received). For example, as shown in Figures 3 and 4, the WTRU 102 may be configured with one DCI size to monitor various services (e.g., two services eMBB and URLLC), which services (e.g., each service) may have different bit field configurations. For example, the WTRU 102 may be configured to interpret the DCI fields based on the control channel configuration on which the DCI is received. The WTRU 102 may be semi-statically pre-configured / configured (e.g., via network signaling and / or RRC signaling) with a subset of fields to be interpreted differently. For example, the WTRU 102 may be pre-configured to interpret (e.g., only interpret) the HARQ-ACK feedback timing field (e.g., a bit field) differently, and the remaining fields may have the same interpretation regardless of which control channel configuration is used. The control channel configuration may include, among other things, any of the following: (1) A search space configuration that includes, among other things, any of the following: (i) a monitoring periodicity and / or offset, such that, for example, the WTRU 102 may be configured with a periodicity and / or offset threshold at which bit fields in the DCI may be interpreted differently (e.g., if the WTRU 102 is configured with a search space with a monitoring periodicity equal to or greater than the threshold, the WTRU 102 may interpret DCI fields received within that search space in a first manner, or if the WTRU 102 is configured with a search space with a monitoring periodicity less than the threshold, the WTRU 102 may interpret DCI fields received within that search space in a second, different manner); (ii) a search space duration, such that, for example, DCI received by the WTRU 102 in a search space with a duration shorter than K slots may be interpreted differently than DCI received in a search space with a duration longer than K slots; (iii) monitoring patterns within a slot, e.g., such that DCI received by the WTRU 102 within a search space configured with any pattern of symbols may be interpreted differently (e.g., the WTRU 102 may be configured with a set of patterns, and DCI received within a search space configured with one or set of those patterns may be interpreted differently than DCI received within a search space not configured with one or set of those patterns); (iv) a search space index (e.g., the WTRU 102 may be configured with a search space index, and one or more DCIs received by the WTRU 102 on this search space corresponding to the search space index may be interpreted differently); and / or (v) if PDCCH candidates belonging to more than one search space are successfully decoded, the WTRU 102 may determine the search space based on a priority index configured by a higher layer for the search space (e.g., each search space) and / or based on another parameter associated with one or more search spaces (e.g., the search space with the lowest periodicity); (2) A CORESET configuration that includes, in particular, any of the following: (i) the duration of the CORESET (e.g., the number of symbols (e.g., consecutive symbols) in the CORESET), and / or (ii) a control resource set index; (3) The RNTI, which is used to scramble the cyclic redundancy check (CRC); (4) a CRC length, e.g., the configuration may include, e.g., a 16-bit CRC for an eMBB service type, or a 24-bit CRC for a URLLC service type, and / or (5) Bandwidth Part (BWP) configuration.

[0073] Representative Procedures for Downlink / Uplink Control Interpretation Based on Several DCI Values In some representative embodiments, the WTRU 102 may be configured to interpret a set of DCI fields differently depending on the value of one or more other DCI fields. For example, the WTRU 102 may be configured with a field (e.g., a bit field), a subset of the fields of the DCI, or all fields of the DCI to be interpreted differently based on one or more other DCI fields (e.g., one or more bit values ​​in a particular DCI field). The WTRU 102 may be configured with a given bit field value (e.g., a PDSCH time domain allocation) that upon decoding triggers the WTRU 102 to interpret the set of bit fields differently. For example, a PDSCH time domain value that is below a threshold or within a range of values ​​may be interpreted by the WTRU 102 as indicative of a particular service type and / or may be used as an indication to interpret one or more other DCI fields in a particular manner (e.g., in a manner associated with a particular service type).

[0074] Typical Transmission Profile (TP) in DCI In some representative embodiments, the WTRU 102 may be configured with one or more TPs. For example, a first TP value may indicate a first (e.g., eMBB) service type and a second TP value may indicate a second (e.g., URLLC) service type. In such a case, the WTRU 102 may receive a DCI and determine a corresponding TP for the DCI. The WTRU 102 may interpret one or more fields of the DCI according to the determined value of the TP for the DCI (e.g., using a first value or set of values ​​for the first particular TP value and a second value or set of values ​​for the second particular TP value).

[0075] Exemplary logical channel prioritization (LCP) for a transport block (TB) corresponding to a DCI (e.g., which may require and / or use eNB blind decoding) In some representative embodiments, the WTRU 102 may be configured with one or more logical channels (LCHs). For example, a first LCH may be associated with data corresponding to a first (e.g., eMBB) service type and / or a second LCH may indicate a second (e.g., URLLC) service type. The WTRU 102 may determine how to interpret at least some of the content of the DCI depending on the data to be included in the corresponding transmission. For example, the WTRU 102 may determine a transport block (TB) size (TBS) for a transmission associated with the DCI. The WTRU 102 may determine what LCHs to service for the TB (e.g., based on a logical channel prioritization (LCP) function). The WTRU 102 may determine the service type associated with the LCH of interest. The WTRU 102 may interpret one or more fields of the DCI according to the determined service type associated with the LCH of interest (e.g., using a first value or set of values ​​for a first particular LCH configured for a first service type, or using a second value or set of values ​​for a second particular LCH configured for a second service type).

[0076] Those skilled in the art will appreciate that the procedures / operations disclosed herein with respect to the LCH may be applied to a logical channel group (LCG) instead of or in addition to the LCH. Similar procedures / operations may be applied for the LCP using a different set of mapping restrictions or TPs. In such a case, the WTRU 102 may determine that the DCI schedules a new transmission, e.g., the DCI may toggle a new data indicator field (NDI). The WTRU 102 may determine that an interpretation of the HARQ PID corresponds to a first PID space for the first LCH or a second PID space for the second LCH (e.g., a different set of HARQ processes may be indicated depending on the interpretation of the DCI). Proper reception of such a transmission may require and / or use blind decoding at the network node (e.g., the eNB, or gNB, among others).

[0077] Typical HARQ Process Identifiers (PIDs) in DCI In some representative embodiments, the WTRU 102 may be configured with one or more HARQ process identification (PID) spaces. For example, a first PID value may indicate a first (e.g., eMBB) service type and / or a second PID value may indicate a second (e.g., URLLC) service type. In such a case, the WTRU 102 may receive a DCI for a HARQ transmission and may determine a corresponding HARQ PID of the DCI. The WTRU 102 may interpret one or more fields of the DCI according to the determined value of the HARQ PID (e.g., using a first value or set of values ​​for the first particular HARQ PID value (and / or a corresponding first range of values) and a second value or set of values ​​for the second particular HARQ PID value (and / or a corresponding second range of values)).

[0078] Exemplary Procedures for Downlink / Uplink Control Interpretation Based on Explicit Indications in DCI In some embodiments, the WTRU 102 may be configured to interpret the set of DCI fields differently depending on the value of the bits in the DCI. For example, the WTRU 102 may be configured to use a "set" indication in the DCI to determine a PUCCH resource for HARQ A / N feedback from a PUCCH resource set. In one example, the WTRU 102 may be configured to simultaneously receive eMBB and URLLC / eURLLC data transmissions. The WTRU 102 may be configured with at least two PUCCH resource sets, each corresponding to a service type (e.g., URLLC / eURLLC, eMBB and / or mMTC). The WTRU 102 may determine the PUCCH resource set to which the acknowledgement (e.g., PUCCH) resource indicator (ARI) bit field points based on the set indication.

[0079] Various interpretations of representative control signaling fields Representative HARQ-ACK feedback timing indication FIG. 5 is a diagram illustrating various HARQ feedback timings.

[0080] 5, the HARQ timing indication 510 may be signaled, for example, using system information. The HARQ timing indication 510 may indicate the HARQ timing associated with each of a plurality of HARQ feedback timing sets 520A, 520B...520N (e.g., for DMRS mapping type A 520A and for DMRS mapping type B 520B, among others). For example, the HARQ timing set 520A may include HARQ timings t1, t2, t3, and t4, and the HARQ timing set 520B may include HARQ timings t5, t6, t7, and t8. The HARQ timing indicator 510 may be a multi-bit indicator. For example, when this multi-bit indicator is set to a code point of "11", the HARQ feedback timing may be set to t4 for DMRS type A and t8 for DMRS type B.

[0081] The WTRU 102 may be semi-statically configured (e.g., using RRC signaling or via reception of a system information block (SIB)) with two or more sets of HARQ feedback timing values, where each set may be configured with a different timing (e.g., timing in different units). For example, the WTRU 102 may be configured with a first set of timing in units of slots, a second set of timing in units of symbols, and a third set of timing in units of groups of symbols. Each set of HARQ feedback timing values ​​may correspond to an interpretation. For example, the first set of HARQ timing values ​​may correspond to a particular PDSCH start symbol. In some representative embodiments, apparatus, methods, operations and / or procedures may be implemented such that the WTRU 102 dynamically determines the unit of the HARQ feedback timing for a given transport block. Those skilled in the art will appreciate that these apparatus, methods, operations and / or procedures may be similarly applied to interpretations of other DCI fields, such as the PUCCH resource indicator (ARI).

[0082] The WTRU 102 may be configured to interpret the HARQ timing indication bit field differently based on a trigger described herein (e.g., based on a control channel configuration). The WTRU 102 may then determine the HARQ-ACK timing value based on, among other things, the following bit field values: (1) PDSCH time domain allocation value (eg, the WTRU 102 may interpret the HARQ feedback timing indication based on the PDSCH start time and / or PDSCH duration values). The PDSCH time domain field may include, among others, any of the following: (i) a k0 value that may indicate a slot scheduled for data transmission (e.g., slot number n in which DCI is received and data to be transmitted in slot n+k0) (e.g., the WTRU 102 may be configured with a value of k0 at which the WTRU 102 may interpret the HARQ timing differently. In some embodiments, the WTRU 102 may be configured with a k0 threshold at which the HARQ-ACK timing may be interpreted differently. For example, when the k0 value is below the k0 threshold, the HARQ-ACK timing may be interpreted in a first manner (e.g., based on symbol timing / symbol timing period) and when the k0 value is equal to or greater than the k0 threshold, the HARQ-ACK timing may be interpreted in a second manner (e.g., based on slot timing / slot timing period)); (ii) DMRS mapping type (e.g., DMRS mapping type A or DMRS mapping type B) (e.g., the WTRU 102 may be configured with two HARQ feedback timing sets, and based on the DMRS mapping type indication in the DCI, the WTRU 102 may determine which HARQ timing set the HARQ timing indication refers to, as shown in FIG. 5 ); (iii) the starting symbol and / or length of the PDSCH transmission (e.g., the WTRU 102 may be configured with a set of starting symbols (e.g., the last three symbols of a slot), and thus, if the WTRU 102 receives a PDSCH scheduling that starts on those symbols, the HARQ-ACK timing field may be interpreted differently. For example, if the WTRU 102 receives a PDSCH scheduling that starts on one of those symbols, the HARQ-ACK timing field may be interpreted in a first manner, and if the WTRU 102 receives a PDSCH scheduling that does not start on any of those symbols, the HARQ-ACK timing field may be interpreted in a second manner), and / or (iv) an offset or delay, in symbols, between the reception of the PDCCH and the start symbol of the PDSCH; and / or (2) One or more HARQ process ID values ​​(e.g., the WTRU 102 may be configured with a set of HARQ process IDs for which the timing indication bit field may be interpreted differently. For example, the WTRU 102 may be configured with HARQ IDs 0, 1, and 2. Upon receiving a PDSCH assignment with HARQ IDs {0,1,2}, the WTRU 102 may interpret the HARQ-ACK timing field differently. The WTRU 102 may be semi-statically configured with a mapping between or among the set of HARQ process IDs and HARQ-ACK timing.)

[0083] Typical Procedures Using HARQ Processing Indication The WTRU 102 may be configured to interpret the HARQ process ID indication in the DCI based on one or more triggers discussed herein (e.g., based on a control channel configuration and / or certain DCI bit fields).

[0084] Exemplary Procedure Using PUCCH Resource Indication for HARQ-ACK The WTRU 102 may be configured to interpret the PUCCH resource indicator (ARI) based on the scheduled service type and / or based on any indication associated with the service type according to one of the representative embodiments (e.g., solutions) described herein. For example, the WTRU 102 may be configured to send HARQ-ACK information in two or more PUCCH resources of the same slot, where one PUCCH resource may include and / or contain a HARQ-ACK related to a first set of PDSCH transmissions and a second PUCCH resource may include and / or contain another HARQ-ACK related to a second set of PDSCH transmissions. The WTRU 102 may determine whether a given PDSCH transmission belongs to the first set of PDSCH transmissions or the second set of PDSCH transmissions based on the scheduled service type and / or based on any indication associated with the service type according to one of the representative embodiments (e.g., solutions) described herein. For example, the WTRU 102 may determine that a PDSCH transmission belongs to a first set of PDSCH transmissions if the PDSCH duration is below a threshold, and may determine that it belongs to a second set otherwise.

[0085] Exemplary Procedures Using PDSCH / PUSCH Time Domain Allocation Indication The WTRU 102 may be configured to interpret the PDSCH and / or PUSCH time domain allocation indication based on one or more triggers described herein. For example, the WTRU 102 may be semi-statically configured with two sets of time domain allocations, each corresponding to a service type (e.g., URLLC / eURLLC and / or eMBB, among others). The WTRU 102 may be configured to interpret the time domain allocation bit field in the DCI based on the control channel configuration on which the DCI scheduling downlink or uplink data was received. The WTRU 102 may receive a semi-static mapping configuration between the control channel configuration and the set of time domain allocations.

[0086] Typical Procedure for Supporting Multiple PUCCHs per Slot FIG. 6 illustrates a procedure for supporting multiple PUCCHs per slot.

[0087] 6, the WTRU 102 may receive a first PDSCH 620 / DCI 625, e.g., associated with a first service type (e.g., eMBB service) and a second PDSCH 630 / DCI 635, e.g., associated with a second service type (e.g., URLLC / eURLLC service or mMTC service) in slot 600-3. The WTRU 102 may determine a first codebook index 0 for the HARQ feedback timing of the PDSCH 625 on the uplink and a second codebook index 1 for the HARQ feedback timing of the PDSCH 630 on the uplink from the first PDSCH 620 / DCI 625. When HARQ feedback associated with different services (e.g., URLLC and eMBB) should occur within the same slot 600N for the uplink, the WTRU 102 may generate a first PUCCH 640 (e.g., PUCCH1 associated with the URLLC service) and a second PUCCH 650 (e.g., PUCCH0 associated with the eMBB service) for the uplink. For example, the WTRU 102 may determine that codebook index 0 is indicated for the HARQ feedback timing associated with the PDSCH 620 and codebook index 1 is indicated for the HARQ feedback timing associated with the PDSCH 630. In such a scenario, when different codebook indices (e.g., codebook indexes 0 and 1) may be indicated, multiple PUCCHs 640 and 650 may be generated in the same slot 600-N.

[0088] Although HARQ feedback for multiple services is shown to occur in one slot, other scenarios are possible. For example, HARQ feedback for a given service can occur in one slot (e.g., a first HARQ feedback may correspond to a first slot and a second HARQ feedback may correspond to a second, different slot) without having HARQ feedback from any other services (e.g., any other codebooks) requested in the same slot. In such a scenario, two codebooks may be indicated in two different slots.

[0089] In some representative embodiments, the WTRU 102 may indicate the same sub-slot or the same symbol from multiple DCIs, which may indicate a downlink assignment or SPS release (e.g., using DCI format 1_0 or 1_1), for two or more PUCCH resources of the same slot 600-N. The WTRU 102 may determine that a PUCCH 640 or 650 is transmitted for at least one PUCCH resource in the slot 600-N, sub-slot, or symbol, where the at least one PUCCH resource is determined based on at least one index (codebook index 0 or 1). The index may be referred to herein as a codebook index. Each of the at least one PUCCH resource may correspond to a codebook index corresponding to at least one of the DCIs. For a received codebook index (e.g., for each received codebook index (e.g., codebook index 0 or 1)), the PUCCH resource may be determined from the PUCCH resource indicator field in the last DCI among all DCIs corresponding to the codebook index (e.g., codebook index 0 or 1), and the DCIs may be ordered according to legacy procedures / operations (e.g., set in ascending order over serving cell indexes and then set in ascending order over PDCCH monitoring occasion indexes).

[0090] The codebook index 0 or 1 corresponding to the DCI may be determined in particular according to any of the following: (1) An additional field in the DCI that explicitly indicates the codebook index; (2) the properties of the corresponding PDCCH, in particular the TP, search space, search space periodicity, and / or RNTI; and / or (3) From an existing field of the DCI, such as the PUCCH resource indicator (e.g., the codebook index may be mapped to a value of the PUCCH resource indicator (e.g., each of the 16 possible values ​​of the PUCCH resource indicator), and the mapping may be predetermined, signaled, and / or configured by higher layers.)

[0091] Following determination of at least one PUCCH resource in a slot, subslot, or symbol, the WTRU 102 may determine that there is an overlap in the time and / or frequency domain for at least two resources. The WTRU 102 may prioritize one of the overlapping PUCCH resources and / or drop the other overlapping PUCCH resource (at least one overlapping portion) based on, among other things, any of the following: (1) Properties of the PUCCH resources (e.g., the WTRU 102 may drop the PUCCH resource with the longest duration); (2) PUCCH formats for a PUCCH resource (e.g., each PUCCH resource) using a predefined priority order among the PUCCH formats; (3) a codebook index (e.g., for prioritizing based on the lowest or highest codebook index associated with a PUCCH resource); (4) TP, (5) properties of PDSCH transmissions associated with PUCCH resources (e.g., each PUCCH resource) (e.g., the WTRU 102 may drop a PUCCH resource carrying a HARQ-ACK for the longest duration PDSCH); and / or (6) Properties of the corresponding PDCCH (e.g., the WTRU 102 may drop PUCCH resources carrying a HARQ-ACK of a downlink assignment received from a PDCCH with the longest periodicity search space or based on the RNTI).

[0092] Although two HARQ codebook indexes are shown (e.g., HARQ codebook indexes 0 and 1), any number of HARQ codebook indexes are possible. For example, each HARQ codebook index may correspond to a priority level, a priority, a service type, and / or an application type, among others, and / or may be based on a predetermined HARQ format and / or HARQ bundling.

[0093] Typical procedure for handling conflicts between UCI or data related to different services In some representative embodiments, methods, apparatus, and systems may be implemented to handle conflicts between UCIs of different types and services based on priority levels.

[0094] In some representative embodiments, the WTRU 102 may handle situations in which transmissions carrying uplink control information (UCI) and / or data associated with different services (e.g., for URLLC and / or eMBB) may or will overlap, such that the latency and / or reliability requirements of each service are met.

[0095] Representative Procedure for Identification of Service Relationship Priorities The WTRU 102 may determine a priority (eg, a service-related priority and / or a transmission profile) associated with data or uplink control information, particularly for at least one of the following: (1) For data, the logical channel (LCH) and / or logical channel group (LCG) from which the data is transmitted (e.g., the WTRU 102 may determine the priority of a given PUSCH transmission as the RRC configured LCH priority of the highest priority LCH mapped to the PDU carried by the PUSCH transmission); (2) For a Scheduling Request (SR), the logical channel and / or logical channel group of the data that triggered the SR; (3) For the physical random access channel (PRACH), a predefined priority, such as the lowest priority and / or the highest priority; the event initiating the random access procedure (e.g., handover, re-establishment, beam failure recovery, scheduling request, and / or PDCCH command, etc.); whether the random access procedure is contention-based or contention-free; whether the PRACH is transmitted on a PCell or an SCell; whether the random access procedure is a prioritized random access procedure, e.g., the WTRU 102 may determine the highest priority level for the PRACH in case of a prioritized random access procedure, and the lowest priority level otherwise; in case of a random access procedure initiated by a scheduling request, the logical channel or logical channel group of the data that triggered the SR; in case of a random access procedure initiated when the SR counter exceeds a maximum value, the priority of the last SR resource transmitted; in case of a random access procedure initiated when no valid PUCCH resources are configured for a pending SR, the priority may be the lowest priority. (4) For SRS, depending on whether the SRS is periodic or triggered by the PDCCH, in the former case the priority may be the lowest priority, and in the latter case the SRS may have a priority determined from the PDCCH; (5) For HARQ-ACK, whether a slot-based HARQ feedback procedure or a subslot-based HARQ feedback procedure is used; (6) for a PUSCH, WTRU 102 processing capabilities for PUSCH preparation, e.g., such capabilities are associated with the PUSCH transmission and / or configured for the carrier on which the PUSCH is transmitted; (7) Properties of resources configured for (or associated with) the transmission of data and / or UCI. For example, the properties may include, among others: (i) the duration and / or format of a PUCCH configured and / or indicated for transmitting SR or HARQ-ACK, and / or the duration of a PUSCH configured or indicated for transmitting data or UCI (e.g., the priority of the service relationship may be a first value if the duration of the PUSCH and / or PUCCH indicated by the configuration is higher than a threshold, and may be a second value if the PUSCH or PUCCH has a duration lower than the threshold. In another example, the priority of the service relationship may be a first value); (ii) bandwidth part, numerology (e.g., subcarrier spacing, symbol duration), and / or transmission configuration indication (TCI) state; (iii) the modulation and coding scheme (MCS) and / or MCS table used for the transmission; (iv) the properties used to determine logical channel limitations for logical channel prioritization; and / or (v) the serving cell and / or uplink carrier on which the transmission occurs, or whether the transmission occurs on a normal uplink carrier or a supplemental uplink (SUL) carrier; (8) Configuration from a higher layer (e.g., in particular, the RRC layer and / or the MAC layer), in particular any of the following: (i) An information element (IE) that explicitly indicates the priority of the corresponding service relationship, e.g., the IE may be included as part of the SR resource configuration (for SR), included as part of the resource configuration for a Link Recovery Request (LRR), or included as part of the configured grant configuration (for data scheduled using a configured grant); (ii) implicitly from configuration aspects such as periodicity, offset, and / or resources (e.g., the priority of the service relationship for SR and / or for data scheduled using a configured grant may be a first value if the periodicity is above a threshold and a second value if the periodicity is below a threshold. In another example, the priority of the service relationship for CSI may be determined from a BLER target configured for a CSI reporting setting); (iii) a mapping table between LCH priorities and priority levels (e.g., the WTRU 102 may be configured by the RRC with an LCH priority quantization table that may map a set of LCH priorities to a given priority level. For example, the priority of an SR and / or PUSCH transmission may be determined differently when the SR and / or PUSCH transmission conflicts with a HARQ-ACK. In some embodiments, the MAC layer may pass the LCH priority associated with the SR and / or PUSCH transmission. The LCH priority may then be converted to a priority level, which may be compared to the priority level attached to and / or associated with the HARQ-ACK (e.g., with the same granularity)); and / or (iv) The RRC may configure the WTRU 102 with a set of LCHs when applicable for intra-WTRU prioritization (e.g., the WTRU 102 may ignore a resource contention, e.g., if a colliding transmission does not involve at least one LCH that is applicable for intra-WTRU prioritization); (9) Downlink control information (DCI) related to UCI and / or data and / or SRS, such as any of the following: (i) for HARQ-ACK, a DCI containing corresponding PDSCH scheduling information (e.g., in dynamic allocation and / or semi-persistent scheduling (SPS) activation); (ii) for data, DCI containing corresponding PUSCH scheduling information; (iii) for a CSI, the service-related priority, which is also applicable to the DCI that triggers the transmission of the CSI, and thus to the PDCCH carrying the DCI, may be determined by (a) the DCI format and / or DCI size, (b) a field that explicitly indicates the service-related priority, such as a priority indication, (c) implicitly from the value of the field, e.g., the value of the Radio Network Temporary Identifier (RNTI) used to mask the CRC and / or the size of the CRC, and / or (d) implicitly from the properties of the PDCCH carrying the DCI, e.g., the CORESET, whether the PDCCH is monitored at the start of a slot, the search space type, the identity and / or the monitoring period, e.g., each search space may be explicitly configured with the service-related priority, the serving cell (e.g., where the PDCCH is decoded and / or indicated by the DCI), the bandwidth part (e.g., where the PDCCH is decoded) (e.g., the service-related priority index may be configured by RRC, among others, for the CORESET, the search space, the bandwidth part and / or the serving cell); (10) For HARQ-ACK and / or PDSCH related to HARQ_ACK, the properties of the PDSCH, such as: (i) the serving cell where the PDSCH is decoded; (ii) the duration of the PDSCH; (iii) the bandwidth part on which the PDSCH is decoded; (iv) the WTRU processing capability associated with the PDSCH and / or configured for the carrier on which the PDSCH is decoded; (11) for data, the number of retransmissions of the transport block, and / or (12) The WTRU PHY may determine a priority associated with the PUSCH and / or SR transmission as a priority level indicated from one or more higher layers (e.g., the MAC layer).

[0096] The priority of a service relationship may be associated with at least one of the following parameters (e.g., for transmission of UCI or data): in particular, (1) maximum latency, (2) maximum code rate and / or MCS, (3) maximum duration of a single transmission, and / or (4) maximum payload.

[0097] At least some of the parameters may be implicitly determined from configuration aspects, for example, the maximum latency of SR for a certain service-related priority may correspond to the periodicity of SR transmissions and / or, or on the other hand, the maximum duration of a single transmission may correspond to the duration of the corresponding PUCCH resource.

[0098] For the PUSCH, the WTRU 102 may determine and / or consider service-related priorities to determine whether data from a logical channel may be included in one or more transport blocks. For example, the RRC may configure a set of allowed service-related priorities for each logical channel.

[0099] The priority of the service relationship may determine the set of parameters used for power control (e.g., P0, α) and power control adjustment state. For example, the set of parameters may be applied to PUCCH resources for SR and / or LRR depending on the priority configured by higher layers.

[0100] Representative procedures for identifying crash situations A collision may occur when there is an overlap between at least two dynamically indicated and / or configured transmissions, either in the time domain only or in both the time and frequency domains.

[0101] Collisions may occur when there is overlap only in the time domain if the transmissions are not allowed to occur at the same time. For example, collisions may occur between PUCCH and PUSCH transmissions in different serving cells in the same slot (e.g., overlapping in the time domain) if the PUCCH and PUSCH are not allowed to be transmitted in the same slot (or not overlap in the time domain). For example, collisions may occur between two PUSCH transmissions in the same slot and the same serving cell if they overlap in the time domain (e.g., only in the time domain).

[0102] Collisions can occur even when there is no overlap in the time domain if there is not enough processing time to process both transmissions (eg, the colliding transmissions).

[0103] A collision may occur when the WTRU 102 determines that one or more transmissions should be performed and the start of at least one transmission is less than a certain amount of time (e.g., time x), where time x may correspond to a configured value and / or processing time requirement from the time the WTRU 102 determined that the transmission should be performed. The WTRU 102 may further consider a data transmission in a set of colliding transmissions if the WTRU 102 has buffered data that can be mapped onto the transmission and / or if the data priority is higher than the priority of other transmissions in the overlapping set of resources. The WTRU 102 may further consider whether an LCH configured by the RRC is eligible for intra-WTRU prioritization (e.g., by satisfying a criterion or rule) and may or should be included or associated with the transmission before considering the transmission a colliding transmission. For example, the WTRU 102 may ignore a resource contention if the colliding transmission does not involve such an LCH (e.g., an eligible LCH).

[0104] For example, the WTRU 102 may be indicated a first resource for transmitting an HARQ-ACK for a first service related priority (e.g., eMBB) and may then be indicated a second resource for transmitting an HARQ-ACK for a second service related priority (e.g., URLLC), where the first and second resources overlap in the time domain.

[0105] In another example, the WTRU 102 may be indicated a first resource for transmitting a PUSCH for a first service related priority (e.g., eMBB) and then may be indicated a second resource for transmitting a HARQ-ACK for a second service related priority (e.g., URLLC), where the first and second resources overlap in the time domain.

[0106] In a further example, the WTRU 102 may be indicated a first resource for transmission of a PUSCH for a first service-related priority (e.g., of eMBB) and subsequently be indicated a second resource for transmission of a PUSCH for a second service-related priority (e.g., of URLLC), where the second PUSCH resource precedes the first PUSCH resource and there may not be enough processing time to process both PUSCHs.

[0107] In the following, the at least two resources are referred to as "conflicting resources."

[0108] Typical Procedures for Action When Identifying a Crash When a conflict is identified for at least two conflicting resources, at least one of the following actions may be taken.

[0109] The WTRU 102 may select at least one resource for transmission of a subset or all of the UCI and / or data that would be transmitted over the conflicting resources. In some representative embodiments, resource selection may be implemented, for example, as follows: The WTRU 102 may then not transmit (and possibly stop or suspend ongoing transmissions) on the remaining conflicting resources, at least over the overlapping portion in the time domain (or in both the time and frequency domains). The WTRU 102 may transmit on at least one remaining conflicting resource if the WTRU 102 is on a different serving cell, unless a limitation is configured or defined based on the type of physical channel (e.g., when simultaneous PUCCH and PUSCH are not enabled).

[0110] The WTRU 102 may multiplex the UCI and / or data on at least one of the conflicting resources. When multiplexing the UCI and / or data across the selected resources, the WTRU 102 may follow a priority order. The priority of the UCI and / or data may be based on any of the following: (1) using service-based priorities (e.g., priority indications), e.g., numerical values ​​(where higher values ​​may indicate higher priority, or alternatively, lower priority), or labels (e.g., URLLC and / or eMBB, among others) with relative priority (URLLC>eMBB); and / or (2) The type of UCI and / or data, including the type of CSI report (HARQ-ACK, SR, CSI, and / or data), e.g., SR and / or HARQ-ACK may have the highest priority, followed by data and CSI;

[0111] The service-based priority criterion may take precedence over other criteria (e.g., priority is determined first by service-based priority and second (if equal) by type of UCI / data). The overall priority may be determined using a formula. For example, the WTRU 102 may prioritize in the following order: URLLC SR / HARQ-ACK, URLLC data, eMBB SR / HARQ-ACK, eMBB data, and CSI. An example multiplexing implementation for UCI and / or data multiplexing is described as follows.

[0112] The WTRU 102 may multiplex some (e.g., only some) combinations of UCI and / or data on selected resources according to predefined or configured rules or according to a dynamic indication. The combinations (e.g., allowed combinations) may depend on the service-based priority level of the UCI and / or data (e.g., each UCI or data) and on the type of resource (e.g., PUCCH and / or PUSCH) and / or PUCCH format. For example, the WTRU 102 may multiplex (e.g., only multiplex) UCI ​​and / or data associated with the same priority level, e.g., in the same resource. In another example, the WTRU 102 may multiplex (e.g., only multiplex) SR / HARQ-ACKs of the same priority level into PUCCH and / or PUSCH. For example, the WTRU 102 may multiplex a HARQ-ACK of a first priority level (e.g., for URLLC) with data of a second priority level (e.g., for eMBB) onto a PUSCH if such is indicated in the DCI, e.g., for a DL assignment corresponding to the HARQ-ACK and / or for a UL grant corresponding to the PUSCH. In another example, the WTRU 102 may multiplex (e.g., only multiplex) CSI with the HARQ-ACK and / or SR associated with the lowest priority level.

[0113] The WTRU 102 may drop at least a subset of the UCI, SR, and / or data. For example, the WTRU 102 may drop UCI and / or data that could not be multiplexed on a selected resource because the UCI and / or data is not allowed to be multiplexed with higher priority UCI and / or data. In another example, the WTRU 102 may drop UCI if it is not allowed to be multiplexed on a resource, e.g., due to payload and / or maximum code rate limitations. The dropping of lower priority transmissions may be performed for any symbols starting later than a first minimum time Tdrop1 after the last symbol of the PDCCH indicating a high priority UL transmission. In some representative embodiments, the dropping may be applied under the condition that the first symbol of a lower priority transmission is not before a second minimum time Tdrop2 after the last symbol of the PDCCH indicating a high priority UL transmission.

[0114] In some embodiments, the WTRU 102 may process a subset of UCI to reduce the number of information bits. For example, if the HARQ-ACK is code block group based (CBG based), the WTRU 102 may report (e.g., only report) the TB level HARQ-ACK. For example, the HARQ-ACK information may be bundled (e.g., via an AND operation) in the time, frequency and / or spatial domain. The WTRU 102 may reduce the number of information bits for UCI of a priority level (e.g., eMBB) depending on any of the following: (1) When it is a combination of UCI and / or data of higher priority levels on a resource, e.g., when a HARQ-ACK of a first higher priority level (e.g., for URLLC) is combined with a HARQ-ACK of a second lower priority level (e.g., for eMBB) on PUCCH and / or PUSCH, the number of HARQ-ACK bits of the second priority level may be reduced; (2) When it may not be possible to multiplex UCI (with other UCI or data of higher priority) due to payload or maximum code rate limitations.

[0115] In some embodiments, the WTRU 102 may include a UCI multiplexing indicator in the resource to facilitate decoding of different UCI (e.g., possible UCI) combinations at the network side. The UCI multiplexing indicator may consist of an N-bit field, and the values ​​(e.g., each possible value) may indicate a combination (e.g., a particular combination) of UCIs of different types and / or priority levels. For example, among others, a first value may indicate that the UCI includes one or more HARQ-ACKs of a first priority level (e.g., only the first priority level), a second value may indicate that the UCI includes one or more HARQ-ACKs of a second priority level (e.g., only the second priority level), a third value may indicate that the UCI includes one or more HARQ-ACKs of the first and second priority levels, and a fourth value may indicate that the UCI includes an SR of the first priority level and one or more HARQ-ACKs of the second priority level. The UCI multiplexing indicator may be coded separately from other UCI and data and may be mapped onto one or more resource elements (eg, specific resource elements) of the resource.

[0116] In some embodiments, the WTRU 102 may determine, e.g., at a later point in time, resources for transmission of a subset of non-prioritized UCI and / or data, hereinafter referred to as “overflow” resources. Exemplary embodiments for determining overflow resources are described herein.

[0117] The WTRU action upon determining a collision may depend on whether a conflicting PUSCH transmission has started and / or whether a PDU for the conflicting PUSCH resource has been generated and delivered to the HARQ process. If the WTRU 102 determines that a PDU can or will be dropped at the physical layer, the WTRU 102 may not generate a PDU at the MAC (e.g., MAC layer) for a grant that conflicts with another resource. For example, if the WTRU 102 determines that a PUSCH transmission has a lower priority than a conflicting SR and / or UCI transmission and that the PUSCH transmission can or will be dropped (e.g., can or will be dropped entirely at the physical layer), the WTRU 102 may ignore the grant at the MAC layer and may not generate a PDU for the PUSCH resource. The WTRU 102 may consider whether the SR and / or UCI can be multiplexed on a lower priority PUSCH. For example, if the SR and / or UCI cannot be multiplexed on a PUSCH transmission and the PDU can or will be dropped at the physical layer, the WTRU 102 may ignore the grant at the MAC layer and may not generate a PDU for the PUSCH resource. In another example, for example, if the WTRU 102 determines that the SR will not or will not be dropped at the physical layer, the MAC of the WTRU 102 may determine whether to instruct the physical layer to transmit an SR. For example, the WTRU 102 may determine to instruct the physical layer to transmit an SR of lower priority (e.g., lower priority level) than the overlapping PUSCH transmission if the SR and / or UCI can be multiplexed on a PUSCH transmission. In some representative embodiments, for example, if the lower priority SR and / or UCI cannot be multiplexed on a higher priority PUSCH transmission, the WTRU MAC may not instruct the physical layer to generate an SR transmission.

[0118] Due to SR versus PUSCH collisions, the WTRU 102 may consider whether it has signaled (e.g., already signaled) the same pending SR to the physical layer before again instructing the physical layer to transmit the same pending SR in the overlapping PUSCH. For example, if the WTRU 102 has signaled (e.g., already signaled) a pending SR to the physical layer and the SR is multiplexed with the overlapping PUSCH, the MAC (e.g., MAC layer) of the WTRU 102 may not instruct the physical layer to transmit the SR in the overlapping PUSCH. In some representative embodiments, the WTRU 102 may drop the SR transmission at the physical layer, for example, if the SR is multiplexed (e.g., already multiplexed) on the overlapping PUSCH. In some examples, if the WTRU 102 is signaling (e.g., already signaling) a pending SR and the WTRU 102 interrupts and / or punctures the PUSCH at the physical layer to transmit the SR, the MAC (e.g., MAC layer) of the WTRU 102 may not instruct the physical layer to transmit the SR during the overlapping PUSCH.

[0119] A typical procedure for resource selection (e.g., in general) The WTRU 102 may select at least one of the conflicting resources for transmission. This resource may be referred to as a “prioritized resource.” The WTRU 102 may select the prioritized resource based on any of the following criteria: (1) a service-based priority, e.g., associated with the resource and / or associated with the UCI and / or data configured to be transmitted on the resource; (2) whether the resource meets the latency and / or reliability requirements of the highest priority UCI and / or data to be carried by the conflicting resource; (3) whether, for the highest priority UCI and / or data, transmission of the UCI and / or data over the resource may or would result in an increase in latency by more than a certain amount; (4) in particular, the type of (1) physical channel (e.g., PUSCH and / or PUCCH) and / or (2) PUCCH format; (4) the time-related properties of the resource, such as the duration and timing of the first and last symbols (e.g., W TRU 102 may select the resource with the shortest duration among the set of suitable conflicting resources); (5) whether a transmission on the resource may use (e.g., may require) a transmit power that exceeds a configured maximum power; (6) whether the processing time is sufficient to multiplex UCI and / or data over the prioritized resource; (7) a resource for SR may be selected if (e.g., only if) a particular value of UCI, e.g., SR, corresponding value is negative; (8) the number of bits of UCI and / or data that may be multiplexed and / or transmitted using the resource, e.g., subject to a priority order of different UCI and / or data; and / or (9) whether the carrier, serving cell, frequency band, or resource is on a normal uplink or a supplemental uplink.

[0120] Representative procedure for resource selection (e.g., for a PUCCH resource set) The WTRU 102 may be configured with two or more PUCCH resource sets, and the maximum payload of a resource set (e.g., each resource set) and the PUCCH resources within a set (e.g., each set) may be configured for a service-based priority level (e.g., separately for each service-based priority level).

[0121] In an example, a resource set for a PUCCH associated with a priority level may be selected across conflicting resources based on some UCI bits associated with that priority level (e.g., some UCI bits associated only with that priority level) or some UCI bits associated with priority levels below that priority level. For example, some UCI bits may include CSI regardless of priority level.

[0122] In some representative embodiments, the resource set for the PUCCH may be selected based on the total number of UCI bits across the colliding resources, regardless of the priority level.

[0123] Representative Procedures for Suitability-Based Resource Selection In some embodiments, a resource may be selected if (e.g., only if) it is first determined to be "suitable" for transmission of a combination of UCI and / or data based on the rules and / or circumstances described herein. For example, a preferred resource may be selected (e.g., only) among a subset of conflicting resources determined to be suitable.

[0124] For UCI and / or data (or one or more portions thereof) associated with some service-based priority levels, a resource may be suitable (e.g., may be considered suitable only if it is possible to multiplex the UCI and / or data under at least one condition. The suitability of a resource may be defined with respect to a particular combination of UCI and / or data. For example, a resource may be suitable (e.g., considered or determined to be suitable) for a first combination of UCI and / or data and not suitable for a second combination of UCI and / or data.

[0125] Representative Procedure for Suitability Related to Priority Levels The suitability condition may relate to a priority level associated with the resource. For example, a PUCCH resource indicated for HARQ-ACK of a certain priority level may be suitable for including UCI associated with that priority level (e.g., UCI associated only with that priority level) and / or UCI associated with priority levels equal to or lower than that priority level.

[0126] Representative Procedure for Latency-Related Suitability The suitability condition may relate to latency requirements. A resource may be considered or determined to be suitable if (e.g., only if) UCI ​​and / or data (e.g., all of the UCI and / or data) can be mapped onto resource elements in a time symbol occurring before a certain threshold. The threshold may be determined from any of the following: (1) the duration, start time and / or end time of the conflicting resources that may or will carry UCI and / or data (e.g., if HARQ-ACK and / or SR may or will be carried on a PUCCH resource, the threshold may correspond to the end+offset of the last symbol of the PUCCH resource), and / or (2) the configuration aspects of the UCI and / or data, e.g., the maximum time delay and / or offset, may be explicitly configured by higher layers for UCI and / or data or may be determined from aspects such as the periodicity of the SR configuration.

[0127] Representative procedures for reliability-related suitability The suitability condition may relate to a reliability requirement. For example, a resource may be determined to be suitable if (e.g., only if) some coded modulation symbols per layer are mapped for UCI (e.g., HARQ-ACK and / or SR) and can or will be lower than a threshold. The threshold may be determined as a fraction of the total number of resource elements available for transmission of UCI. The fraction may be configured by higher layers or dynamically indicated for a type of UCI and / or a service-based priority level.

[0128] In another example, the suitability condition may relate to a maximum amount of puncturing applied to other UCI and / or data. For example, if HARQ-ACK and / or SR of a certain priority level are mapped to a PUSCH by replacing (e.g., puncturing) modulation symbols that would have been used for data and / or other UCI, the WTRU 102 may determine that a resource is suitable if (e.g., only if) the fraction of modulation symbols available for data and / or other UCI that can or will be punctured is lower than a threshold. The threshold may be configured by higher layers or indicated for the type of UCI and / or service-based priority level that is subject to puncturing.

[0129] In another example, the suitability condition may be that after multiplexing, the coding rate applicable to a UCI may or will be below a threshold for the UCI type and / or priority level. For example, a resource may be suitable for multiplexing HARQ-ACKs of a first and second priority level if (e.g., only if) the coding rate of the HARQ-ACK of the first priority level may not or will not exceed a threshold. The threshold or maximum coding rate may be configured separately, for example, for different priority levels. In another example, the suitability condition may be that the modulation order or spectral efficiency applicable to a UCI or data is below a threshold.

[0130] In another example, the suitability condition may be that the total number of UCI (and / or data) bits is less than the maximum payload configured for the resource. In another example, the suitability condition may be that the UCI is mapped onto a certain subset of the carrier, serving cell, frequency band, or whether it is on the normal uplink or the auxiliary uplink.

[0131] In a further example, the suitability condition may be that the transmit power (e.g., the required transmit power) may or will be below a threshold. In one example, the threshold may depend on a configured maximum power (Pcmax) applicable to the carrier and / or the WTRU 102. In another example, the threshold may be defined with respect to a transmit power that may be used / required to transmit UCI and / or data over a colliding resource, e.g., if multiplexing with UCI and / or data may not or will not be performed. For example, in case of a collision between a first resource for HARQ-ACK of a first priority level and a second resource for HARQ-ACK of a second priority level, such that the first priority level may be higher than the second priority level, the resource may be determined to be suitable for multiplexing HARQ-ACKs of both priority levels if, for example, a difference between a transmit power (e.g., required transmit power) for the resource with multiplexing and a transmit power (e.g., required transmit power) for the first resource with the HARQ-ACK of the first priority level (e.g., only the HARQ-ACK of the first priority level) may be or will be less than a threshold. The threshold may be configured by higher layers and / or may be dynamically indicated for a type of UCI and / or priority level.

[0132] Representative procedure for resource selection using determined preferred resources The WTRU 102 may determine a prioritized resource among the set of conflicting resources based on any of the following:

[0133] The WTRU 102 may determine the prioritized resource as the resource suitable for transmitting the highest priority level UCI and / or the largest number of data bits.

[0134] If more than one resource meets this criterion, the WTRU 102 may determine among or between the two or more resources which resource is suitable for transmission of the next highest priority level UCI and / or the largest number of data bits, etc. In some representative embodiments, or if more than one resource remains after determining / considering all priority levels, the WTRU 102 may use other criteria to select one resource. For example, the WTRU 102 may select the resource that starts earliest in time, has the shortest duration, has the lowest transmit power requirement, and / or has the lowest coding rate, modulation order, and / or spectral efficiency. In another example, the WTRU 102 may select the resource depending on the carrier, the serving cell, whether the resource is on the normal or auxiliary uplink, or the frequency band. The priority order may be configured by higher layers or predefined.

[0135] For example, there may be a collision between a first resource for HARQ-ACK (i.e., PUCCH) of a first service-based priority level (e.g., of URLLC) and a second resource for data (e.g., on PUSCH) of a second service-based priority level (e.g., of eMBB) such that the first priority level may be higher than the second priority level. If the second resource starts later than the first resource and ends earlier than, or earlier than the last symbol of the first resource plus an offset, the WTRU 102 may select the second resource for multiplexing the URLLC HARQ-ACK and eMBB data. For example, if the first resource is on PUCCH for HARQ-ACK for a transmission in a subslot, the WTRU 102 may select the second resource for multiplexing the URLLC HARQ-ACK and eMBB data if the second resource is included within the subslot in the time domain. Otherwise, the WTRU 102 may select the first resource for transmission of the HARQ-ACK of the URLLC (eg, only the first resource for transmission of the HARQ-ACK of the URLLC).

[0136] For example, there may be a collision between a first resource for SR (e.g., PUCCH) of a first service-based priority level (e.g., of URLLC) and a second resource for data (e.g., on PUSCH) of a second service-based priority level (e.g., of eMBB), such that the first priority level may be higher than the second priority level. If the last symbol of the PUSCH, or the last symbol of the PUSCH to which the SR is mapped, is at most X symbols after the last symbol of the first resource, the WTRU 102 may select the second resource for multiplexing the SR of URLLC and the eMBB data. X may vary depending on the periodicity of the SR configuration (e.g., X may be 1 / 2 the periodicity). Otherwise, the WTRU 102 may select the first resource if the SR is positive and the second resource if the SR is negative. For example, the SR may be multiplexed in the PUSCH if (e.g., only if) the latency requirement above is met.

[0137] FIG. 7 illustrates an exemplary transmission procedure 700 after a collision determination.

[0138] Referring to FIG. 7, the transmission procedure 700 may include, at block 710, the WTRU 102 determining that a collision is expected between two transmissions (e.g., prior to the actual transmission), and the WTRU 102 may follow a procedure involving any of the following (e.g., to prevent the expected collision): (1) At block 720, the WTRU 102 may determine a priority for each conflicting transmission; (2) The WTRU 102 may determine whether a lower priority transmission may be multiplexed with the prioritized transmission, at block 730. After this determination of whether a lower priority transmission may be multiplexed with the prioritized transmission, the WTRU 102 may: (i) If the WTRU 102 determines that a lower priority transmission can be multiplexed with the prioritized transmission (e.g., if yes), then at block 740, the WTRU 102 may generate a multiplexed transmission including the PDU, e.g., if applicable; or (ii) If the WTRU 102 determines that the lower priority transmission cannot be multiplexed with the prioritized transmission (e.g., if no), then the WTRU 102 may determine whether the non-prioritized transmission can be partially transmitted (e.g., on at least the non-overlapping portion) at block 750. After this determination of whether the non-prioritized transmission can be partially transmitted, the WTRU 102 may: (a) If the WTRU 102 determines that the non-prioritized transmission may be partially transmitted (e.g., if yes), then in blocks 760 and 770, the MAC (e.g., MAC layer) may generate a PDU for the non-prioritized resources (e.g., if applicable and / or not already generated) and the PHY (e.g., physical layer) of the WTRU 102 may transmit the non-prioritized transmission on at least the non-overlapping portion; or (b) If the WTRU 102 determines that the non-prioritized transmission cannot be partially transmitted (e.g., no), then in blocks 780 and 790, the WTRU 102 may drop the non-prioritized transmission at the physical layer and / or refrain from generating / constructing a PDU on associated resources (e.g., if applicable), and the PHY (e.g., physical layer) of the WTRU 102 may transmit the non-prioritized transmission on at least the non-overlapping portion.

[0139] When the WTRU 102 determines contention (and / or collision) among more than two transmissions, the WTRU 102 may follow the same process on a pair-wise basis when ranking the competing transmissions by priority. In some representative embodiments, the WTRU 102 may rank the competing transmissions by priority and may perform intra-WTRU prioritization on a subset of the competing transmissions (e.g., a subset of the highest ranked competing transmissions, such as only for the top x competing transmissions, where x is configured, signaled, and / or predetermined). The WTRU 102 may drop the remaining transmissions. In some examples, the WTRU 102 may rank the transmissions by type (PUSCH, UCI, or SR) and may retain and / or keep the highest priority transmissions per type (e.g., only the highest priority transmissions per type) prior to running / performing the prioritization process. The WTRU 102 may drop the remaining lower priority (e.g., non-highest priority) transmissions for each type. The WTRU 102 may multiplex UCIs (eg, HARQ-ACKs) together using legacy rules before comparing their priority with other competing transmissions.

[0140] In some representative embodiments, methods, apparatus, and systems may be implemented to handle PUSCH vs. UCI / SR prioritization, including interactions with the MAC layer.

[0141] FIG. 8 illustrates an exemplary intra-WTRU prioritization procedure.

[0142] 8, a representative intra-WTRU prioritization procedure 800 may include the WTRU 102 determining whether a collision (e.g., a PUSCH vs. SR collision) is expected to occur and whether action should be initiated to prevent / mitigate the collision. For example, based on some criteria, conditions and / or rules, the WTRU 102 may (1) transmit an SR (e.g., by dropping or dropping a PUSCH, e.g., at the physical layer), (2) transmit an SR and a PUSCH (e.g., by multiplexing an SR on a PUSCH), (3) transmit an SR (e.g., by not generating a corresponding PDU or a PDU at the MAC layer, e.g., by dropping or dropping a PUSCH), (4) drop an SR (e.g., if the SR is signaled to the physical layer), and / or (5) not generate an SR transmission (e.g., if the SR is not signaled to the physical layer).

[0143] For example, in block 805, the WTRU 102 may determine whether a collision between a PUSCH and an SR will occur. In block 810, the WTRU 102 may determine a priority for each transmission (e.g., a priority of the PUSCH and a priority of the SR). In block 815, the WTRU 102 may determine whether the priority of the PUSCH is less than the priority of the SR. If the priority of the PUSCH is less than the priority of the SR, in block 820, the WTRU 102 may determine whether a PUSCH transmission has started and. if a transport block (TB) has already been constructed, e.g., at the physical layer. If a PUSCH transmission has started and a TB has already been constructed, in block 825, the WTRU 102 may drop or interrupt the PUSCH transmission, and in block 830, the WTRU 102 may transmit an SR. If a PUSCH transmission has not started and / or a TB has not already been constructed, in block 835, the WTRU 102 may determine whether an SR can be multiplexed on the PUSCH. If the SR can be multiplexed on the PUSCH, then the WTRU 102 may multiplex the SR onto the PUSCH, at block 840, and the WTRU 102 may transmit both the SR and the PUSCH, at block 845. If the SR cannot be multiplexed on the PUSCH, then the WTRU 102 may drop or suspend the PUSCH at the physical layer (e.g., by not generating a PDU) or at a higher layer (e.g., the MAC layer), at block 850, and the WTRU 102 may transmit the SR, at block 830.

[0144] If the priority of the PUSCH is equal to or greater than the priority of the SR, in block 855, the WTRU 102 may determine, e.g., at the physical layer, whether a PUSCH transmission has started and whether a TB has already been established. If a PUSCH transmission has started and a TB has already been established, in block 860, the WTRU 102 may determine whether an SR has already been signaled to the WTRU's physical layer. If an SR has already been signaled to the WTRU's physical layer, in block 865, the WTRU 102 may drop the SR. If an SR has not yet been signaled to the WTRU's physical layer, in block 870, the WTRU 102 may not or will not command the WTRU's physical layer to generate an SR transmission. If a PUSCH transmission has not started and / or a TB has not yet been established, in block 875, the WTRU 102 may determine whether the reliability and / or latency of the PUSCH will be compromised if the SR is multiplexed with the PUSCH. If multiplexing the SR with the PUSCH would impair the reliability and / or latency of the PUSCH, then in block 880, the WTRU may determine whether the SR has already been signaled to the physical layer. If, after block 880, the SR has already been signaled to the physical layer, then in block 865, the WTRU 102 may drop the SR. If, in block 880, the SR has not yet been signaled to the physical layer of the WTRU 102, then in block 870, the WTRU 102 may not or will not instruct the physical layer of the WTRU 102 to generate an SR transmission. If, after block 875, multiplexing the SR with the PUSCH would not impair the reliability and / or latency of the PUSCH, then in block 885, the WTRU may multiplex the SR onto the PUSCH, and in block 890, the WTRU may transmit both the SR and the PUSCH.

[0145] Although FIG. 8 illustrates intra-WTRU prioritization for one type of collision (PUSCH vs. SR collision), the same or substantially similar processing may be used for other types of collisions, including, for example, but not limited to, PUSCH vs. UCI collisions.

[0146] Exemplary Procedure for Resource Selection Using Multiple PUSCH Transmissions The WTRU 102 may be configured to transmit two or more PUSCH transmissions in a slot (e.g., the same slot) and / or overlapping in the time domain, where the PUSCH transmissions may be on different serving cells and / or different carriers (e.g., each PUSCH transmission may be on a different serving cell and / or different carrier). The PUSCH transmissions may have different service-related priorities (e.g., each PUSCH transmission may have different service-related priorities). For example, the WTRU 102 may be transmitting a low priority PUSCH on a carrier (e.g., one carrier). For example, the WTRU 102 may be transmitting a low priority PUSCH on a carrier while a new higher priority SR or UCI may be triggered. The carriers may map to PUCCH resources on different carriers that may overlap in the time domain. In some examples, the WTRU 102 may be transmitting low priority UCI and / or SR on one carrier while new high priority data may arrive that may be configured and / or scheduled to be transmitted on a different carrier. The WTRU 102 may be configured and / or scheduled with PUSCH resources on different carriers, which may potentially carry data traffic of different priorities.

[0147] The WTRU 102 may select at least one PUSCH for multiplexing the UCI based on any of the following criteria: (1) whether PUSCH transmission is suitable for combined transmission of UCI and data; (2) one or more service level priorities associated with the PUSCH and the UCI; and / or (3) Any criteria used for the selection of PUSCH transmissions used in existing systems (e.g., NR Release 15, e.g., as specified in TS 38.213 v15.6.0, including Section 9), e.g., in particular, whether the PUSCH is scheduled by DCI, whether aperiodic CSI should be multiplexed in the PUSCH, the serving cell index of the PUSCH, and / or whether timeline conditions related to processing time are met).

[0148] The WTRU 102 may determine a subset of PUSCH transmissions as candidate PUSCH transmissions for multiplexing UCI of a given type and / or priority. The WTRU 102 may then determine the subset of candidate PUSCH transmissions. The subset of candidate PUSCH transmissions is determined by the WTRU 102 to be suitable for transmission of a combination of UCI and data. This determination may be performed based on one or more examples disclosed herein. The WTRU 102 may select a PUSCH from among the subset based on one or more rules, e.g., specified for existing systems. For example, the WTRU 102 may select a PUSCH with the smallest serving cell index in the subset. If there is no suitable PUSCH transmission among the candidate PUSCH transmissions, the WTRU 102 may determine a preferred resource (e.g., according to one or more of the examples disclosed herein). For example, if the prioritized resource is a PUCCH transmission and / or a simultaneous PUCCH and a PUSCH transmission is not allowed in the serving cell or in the cell group, the WTRU 102 may drop one or more PUSCH transmissions in the same serving cell or in all serving cells of the cell group.

[0149] The subset of candidate PUSCH transmissions for a UCI of a given type and / or priority may include, consist of, or be determined from, among others, any of the following: (1) a set of PUSCH transmissions that the WTRU 102 is configured to transmit on (e.g., the full set), (2) a subset of PUSCH transmissions of the same service-related priority as the UCI, and in the case of periodic CSI, for example, the service-related priority may be configured or defined to correspond to a particular priority, such as the lowest priority, (3) a subset of PUSCH transmissions of the highest service-related priority among the set of PUSCH transmissions (e.g., the full set), (4) a subset of PUSCH transmissions scheduled by dynamic grants, configured grants for semi-persistent PUSCH and / or for which aperiodic CSI was requested, and / or (5) a PUSCH transmission determined according to the rules used for PUSCH selection in existing systems (Release 15) (e.g., only PUSCH transmissions).

[0150] If collisions occur for UCIs of more than one type and / or priority, the subset of candidate PUSCH transmissions may be different for each UCI and / or each UCI may be multiplexed on a different PUSCH. For example, the WTRU 102 may multiplex a first priority HARQ-ACK in a first priority PUSCH and a second priority HARQ-ACK in a second priority PUSCH. In some representative embodiments, multiplexing of UCIs may be allowed only on a single PUSCH. In this case, for any UCI, the subset of candidate PUSCHs may be determined as applicable to the highest priority UCI.

[0151] For example, in a scenario, the WTRU 102 may transmit a first PUSCH of a first priority in a first serving cell (e.g., associated with a URLLC service), a second PUSCH of a second priority in a second serving cell (e.g., associated with an eMBB service), and a third PUSCH of a second priority in a third serving cell (e.g., associated with an eMBB service) in a given slot. If the WTRU 102 would or should be transmitting a HARQ-ACK of the second priority (e.g., associated with an eMBB service) in a PUCCH in the same slot, the WTRU 102 may multiplex the HARQ-ACK of the second priority in the second PUSCH. If the WTRU 102 would or should be transmitting a HARQ-ACK of the first priority in a PUCCH in the same slot, the WTRU 102 may multiplex the HARQ-ACK of the first priority in the first PUSCH. In the above scenario, the WTRU 102 may multiplex UCI of different priorities in different PUSCH transmissions in the same slot.

[0152] If the subset of candidate PUSCH transmissions for a UCI of a given type and / or priority is empty according to one set of criteria, the WTRU 102 may fall back to a second (e.g., less restrictive) set of criteria. For example, for a UCI of a given service-related priority, the subset of candidate PUSCH transmissions may correspond to a PUSCH transmission of the same service-related priority if there is at least one such PUSCH transmission, or to a set (e.g., the full set) of PUSCH transmissions if not.

[0153] In some scenarios, the WTRU 102 may not be able to transmit a PUSCH and a PUCCH simultaneously, or the WTRU 102 may not be able to transmit (1) a PUSCH and a PUCCH simultaneously, (2) a PUSCH and a PUSCH simultaneously, or (3) a PUCCH and a PUCCH simultaneously while meeting reliability requirements for the higher priority transmission. The WTRU 102 may drop a low priority transmission and transmit a high priority transmission. The WTRU 102 may puncture a low priority transmission on a portion that overlaps in time with a higher priority transmission. The WTRU 102 may multiplex SR or UCI on a PUSCH transmission if reliability and / or latency metrics are met for the high priority transmission. In another example, the WTRU 102 may apply different transmit power and / or power control parameters if an overlapping transmission has not started. In some examples, the WTRU 102 may allocate power to higher priority transmissions first, followed by some power to lower priority overlapping transmissions (taking into account according to and / or based on the power headroom of the WTRU 102). In other examples, the WTRU 102 may be configured by higher layers with two sets of power control parameters, and the WTRU 102 may select a particular set of power control parameters for a PUCCH or PUSCH transmission when (e.g., only when) the PUCCH or PUSCH transmission overlaps with another PUSCH or PUCCH transmission.

[0154] In some representative embodiments, the WTRU 102 may drop a transport block (TB) generated for transmission on a given carrier if it overlaps with a higher priority transmission on a different carrier. The WTRU 102 may determine, configure, and / or consider a subset of resources as inactive and / or not generate a PDU applicable to such resources, for example, if the subset of resources overlaps with another resource applicable to a transmission of higher priority data on a different carrier. In some examples, the WTRU 102 may be configured with two or more configured grants on different carriers that may overlap in the time domain. For example, a first configured grant CG1 may carry data of all priorities and a second configured grant CG2 may carry data (e.g., data only) from a lower priority. When WTRU102 buffers high priority and low priority data, for example, if the second configured grant CG2 overlaps in the time domain with a CG occasion associated with the first configured grant CG1, WTRU102 may multiplex data from the low priority LCH and high priority LCH on the first configured grant CG1 (e.g., only the first configured grant CG1) and may not generate a TB for the second configured grant CG2.

[0155] Typical Procedures for Handling Non-Priority Resources For at least one conflicting resource, the WTRU 102 may transmit over at least one portion that does not overlap with the preferred resource, such that the overlap can be in the time domain (e.g., only the time domain) or in both the time and frequency domains. For example, the first resource may be a PUSCH transmission resource with a duration of 14 symbols, and the second (e.g., preferred) resource may be a PUCCH transmission with a duration of two symbols that overlaps with the third and fourth symbols of the first resource. The WTRU 102 may transmit the two first symbols of the first resource, skip the third and fourth symbols of the first resource, transmit the second resource, and then transmit the first resource from the fifth symbol.

[0156] When at least a portion of a first resource overlaps with a second (e.g., preferred) resource, the WTRU 102 may determine whether to transmit on the first resource, at least on the remaining non-overlapping portion, based on any of the following conditions: (1) if code block group-based HARQ is configured for the transmission (e.g., at least for a PUSCH transmission), (2) at least a certain number (e.g., one) of one or more code blocks and / or one or more code block groups are mapped onto the non-overlapping portion, (3) if at most a certain number of one or more code blocks and / or one or more code block groups are mapped across one or more skipped portions, (3) if the non-overlapping portion or portions exceed a certain fraction of the resources, (4) if a reference signal (e.g., DM-RS) is present in the non-overlapping portion, and / or (5) if a second transmission can be multiplexed onto the first transmission.

[0157] Representative Procedure for Multiplexing In some examples, the WTRU 102 may multiplex UCI and / or data that may be associated with different service-based priority levels into a single resource. For example, the WTRU 102 may multiplex HARQ-ACK and / or SR and / or data that are associated with different service-based priority levels into a single PUCCH or a single PUSCH.

[0158] When multiplexing UCI on PUSCH, the set of resource elements available for UCI may depend on the service-based priority level associated with the UCI. For example, the number of resource elements available for HARQ-ACK and / or SR may be 0 for the N last time symbols for some priority levels. The value of N may depend on the latency requirement applicable to the priority level. For example, N may be such that the last N symbols may or will not overlap with PUCCH resources that may carry HARQ-ACK and / or SR in the absence of collisions.

[0159] The WTRU 102 may multiplex UCI and / or data associated with different service-based priority levels on the PUSCH or PUCCH. In some examples, the WTRU 102 may encode (e.g., jointly encode) UCI ​​(e.g., HARQ-ACK and / or SR) associated with different priority levels prior to multiplexing on the PUSCH or PUCCH. For the PUSCH, the WTRU 102 may determine a number of coded modulation symbols per layer (Q′) for the jointly coded UCI by using a set of parameters (α, β) configured for the highest priority level among the jointly coded UCI.

[0160] In some representative embodiments, the WTRU 102 may encode (e.g., separately encode) UCI ​​(e.g., HARQ-ACK / SR) associated with different priority levels before multiplexing on the PUCCH or PUSCH. For the PUSCH, the WTRU 102 may determine a number of coded modulation symbols per layer (Q') for each priority level by using parameters (α, β) specific to the priority level (e.g., each priority level). The WTRU 102 may map the coded modulation symbols to different sets of resource elements of the PUSCH.

[0161] When multiplexing UCI associated with different priority levels with data on the PUSCH, the WTRU 102 may first encode and multiplex on the PUSCH a first subset of the UCI and data, given a first set of available resource elements, and may encode a second subset of the UCI and swap values ​​(e.g., may puncture or overwrite a subset of the coded bits or modulated symbols previously determined for the first subset of UCI and / or data). Alternatively, the multiplexing can be performed by “rate matching”, where the WTRU 102 may encode a first subset, given the first set of available resource elements reduced by a second set of resource elements required to map the modulation symbols of the second subset, where the coded bits of the second subset are modulated and mapped onto the second set of available resource elements, without overwriting the coded bits of the first subset.

[0162] Whether joint or individual coding is employed and / or whether multiplexing of subsets of UCIs is performed by puncturing may depend on (1) the priority levels associated with the different UCIs, (2) the number of bits for the different UCIs, and (3) the available processing time, as determined, for example, by the time difference between a PDCCH or PDSCH transmission and the corresponding resource on which an HARQ-ACK is reported (e.g., in the case of a HARQ-ACK).

[0163] For example, HARQ-ACKs of different priority levels may be jointly coded if the total number of HARQ-ACK bits is below a threshold or if the number of HARQ-ACK bits for at least one priority level is below a threshold.

[0164] For example, UCI associated with a higher priority level (eg, HARQ-ACK and / or SR) may be multiplexed by puncturing UCI and / or data associated with a lower priority level.

[0165] For example, HARQ-ACKs associated with PDSCH transmissions that end less than X symbols before the start of the PUSCH resource may be multiplexed by puncturing UCI and / or data that may be associated with an earlier PDCCH transmission or an earlier PDSCH transmission.

[0166] In some examples, when HARQ-ACKs associated with multiple priority levels may be multiplexed on the same PUCCH or PUSCH resource, the WTRU 102 may encode a minimum of M HARQ-ACK bits for at least one priority level even if a PDSCH assignment for the corresponding priority level was not received. M may be set to any positive integer, e.g., 2. This example may ensure that decoding of a HARQ-ACK associated with the highest priority level does not fail due to failure to detect a single or multiple PDSCH assignments for lower priority transmissions. This example may be used if (e.g., only if) a PUCCH or PUSCH resource is enabled to carry HARQ-ACKs associated with lower priority levels. For example, if a PUSCH transmission meets the conditions for multiplexing (e.g., potentially multiplexing) a HARQ-ACK of a higher priority level and a HARQ-ACK of a lower priority level, and the WTRU 102 determines that N1 HARQ-ACK bits should or need to be multiplexed for the higher priority level, but that no HARQ-ACKs should or need to be multiplexed for the lower priority level, the WTRU 102 may further multiplex M HARQ-ACK bits set to 0 for the lower priority level.

[0167] In some examples, the SR may be multiplexed with other UCI and / or data on the PUCCH or PUSCH. The SR may be jointly coded with the HARQ-ACK, e.g., if (e.g., only if) it is associated with the same priority level, or may be coded separately from another UCI. In the latter case, when multiplexed on the PUSCH, the WTRU 102 may determine a number of coded modulation symbols per layer (Q') for the SR at a given priority level by using separately configured parameters (α, β) for the SR. In some representative embodiments, the same parameters for the HARQ-ACK at the same priority level may be reused.

[0168] The number of bits of the SR may be determined based on the number K of scheduling requests whose corresponding PUCCH resources may or will overlap with the PUCCH or PUSCH used for multiplexing. For example, if the SR is multiplexed on the PUSCH, the number (e.g., simply the number) K' of scheduling requests associated with a higher priority level than the PUSCH may be included. For example, the number of bits corresponding to the smallest integer greater than log2(k+1) or log2(K'+1) may be included.

[0169] Representative Procedure for Determining Overflow Resources FIG. 9 illustrates a typical procedure for using overflow resources.

[0170] Referring to FIG. 9, the overflow resource procedure 900 may include, at block 910, the WTRU 102 being identified as mixed traffic capable. At block 920, the WTRU 102 may receive a configuration for primary and overflow UCI. At block 930, the WTRU 102 may determine whether a UCI collision is identified (e.g., will occur). If a UCI collision will occur, at block 940, the WTRU 102 may transmit high priority (e.g., first priority or multiplexed) traffic on the primary PUCCH. At block 950, the WTRU 102 may transmit overflow PUCCH utilization signaling. At block 960, the WTRU 102 may transmit low priority UCI (e.g., second priority, lower priority, and / or remaining UCI) on the overflow PUCCH. If a UCI collision is not identified (e.g., will not occur), then in block 970, the WTRU 102 may transmit on a 5G NR standalone and / or non-standalone PUCCH (e.g., a PUCCH in 3GPP Release 15 or later).

[0171] For example, the WTRU 102 may be configured with two or more PUCCH resource sets, e.g., a primary resource and one or more overflow or secondary resources. The number of resource sets the WTRU 102 selects may be associated with the number UCIs with different service-based priority levels that the WTRU 102 needs to transmit. It is contemplated that with latency-based service-based priority, the primary resources may start earlier and be shorter than the secondary resources.

[0172] In one example, the primary resource and the overflow resource may be in separate time and frequency resources with no overlap in either time or frequency.

[0173] In one example, the primary and overflow resources may be separate in time (e.g., time only) or in frequency (frequency only) (e.g., the primary and overflow resources may be separate in time but not in frequency, or separate in frequency but not in time).

[0174] In one example, the WTRU 102 may be statically, semi-statically, and / or dynamically configured with one or more dedicated overflow resources. In some representative embodiments, the WTRU 102 may be statically, semi-statically, and / or dynamically configured with one or more common overflow resources (e.g., multiple WTRUs 102 may be configured with the same one or more overflow resources). In some representative embodiments, the WTRU 102 may be statically, semi-statically, and / or dynamically configured with a mix of dedicated and common overflow resources.

[0175] In an example, the WTRU 102 may determine the timing and / or resource allocation of the overflow resources from the resource allocation of the primary resources. The WTRU 102 may conditionally use the overflow resources when the primary resources are dropped, suspended, and / or deprioritized due to intra-WTRU or inter-WTRU prioritization. For example, the WTRU 102 may drop a HARQ-ACK transmission (e.g., due to intra-WTRU prioritization) and may use the overflow resources to transmit a non-prioritized HARQ-ACK. The WTRU 102 may use previously (or initially) indicated PUCCH resources and HARQ-ACK timing to determine the overflow PUCCH resources. For example, the WTRU 102 may use a previously signaled K1 (e.g., which is generally the delay between the PDSCH and the corresponding PUCCH) and a PRI associated with the PUCCH resource (e.g., this may be defined as a PUCCH resource indicator) to determine another PUCCH overflow resource starting K1 slots (or depending on the previously signaled K1) after deprioritizing the HARQ-ACK transmission.

[0176] One or more primary resources and overflow resources may be used to transmit UCI for traffic of different priority. In this case, higher priority level traffic may be transmitted in the primary resources to meet the traffic priority level (e.g., latency), and / or the overflow resources may be used to transmit lower priority traffic. In some representative embodiments, the primary resources may be used to transmit multiplexed higher and lower priority UCI, and the overflow resources may be used to transmit lower priority UCI (e.g., only the lower priority UCI).

[0177] Explicit or implicit signaling may be required from the WTRU to a network entity (e.g., a gNB or other access point) to indicate the traffic (e.g., specific traffic) transmitted in that resource. In one example, the WTRU 102 may transmit overflow utilization signaling to a network entity and / or gNB to indicate the WTRU's use of overflow resources (e.g., in the transmission of the overflow utilization signaling) as a separate UCI and / or as part of the UCI on the primary PUCCH resource. The overflow utilization signaling may be a flag or indicator (e.g., a single-bit indicator or a multi-bit indicator) indicating the use of overflow resources and / or may include information regarding the specific PUCCH resource or resources used. In one example, the WTRU 102 may assume or determine that the network entity or gNB may implicitly identify the use of overflow resources due to the transmission of an unexpected higher priority UCI on the primary resource.

[0178] If the WTRU 102 is configured with non-dedicated overflow resources, collisions between or among the WTRUs 102 may occur if multiple WTRUs 102 use the overflow resources simultaneously. A network entity or gNB may explicitly acknowledge receipt of information in the non-dedicated overflow resources. To mitigate the effects of possible collisions, in one embodiment, the WTRU 102 may be configured to transmit information in a non-orthogonal manner in the non-dedicated resources (e.g., using a non-orthogonal multiple access (NOMA) waveform) to allow multiple WTRUs 102 to access the resources. This may be acceptable when the transmitted information is most likely from lower priority traffic. In one example, the WTRU 102 may be configured to access the overflow resources using a listen-before-talk mechanism, such as in NR-U, or using a random access mechanism in which the WTRU 102 may randomly select a subset of the non-dedicated resources (e.g., select the code, frequency, and / or time). In some representative embodiments, the overflow resources may be restricted to a PUCCH format that may allow for multiplexing of data from multiple WTRUs 102 within the same time-frequency resource (e.g., by using a sequence-based PUCCH).

[0179] In one example, upon identifying a UCI collision between traffic with different priority levels, the WTRU 102 may autonomously switch between the primary and overflow UCI transmission configurations.

[0180] Some examples of collision scenarios and possible exemplary solutions are described herein. In the following, "eMBB" may refer to a first service-based priority level, and "URLLC" may refer to a second service-based priority level, such that, for example, URLLC may have a higher priority than eMBB.

[0181] Exemplary procedure for collision between eMBB HARQ-ACK and URLLC HARQ-ACK. The priority of the HARQ-ACK may be indicated in the scheduling DCI (and / or the activation DCI command for DL ​​SPS).

[0182] The WTRU 102 may multiplex the HARQ-ACK of eMBB and URLLC on the PUCCH resources indicated for URLLC if the maximum code rate applicable to URLLC is not exceeded, otherwise the WTRU 102 may drop the HARQ-ACK of eMBB. When the UCI of eMBB (e.g., only eMBB UCI) is multiplexed, the maximum code rate may be configured separately. The power control parameters applicable to the HARQ-ACK of URLLC may be used.

[0183] Exemplary Procedure for Collision Between eMBB HARQ-ACK and URLLC PUSCH The priority of the PUSCH may be indicated by DCI and / or for grant type 1 configured by RRC signaling. The priority of the HARQ-ACK may be indicated in the scheduling DCI (and / or the activate DCI command for DL ​​SPS).

[0184] 13 is an exemplary procedure for eMBB HARQ-ACK multiplexed into URLLC PUSCH. The WTRU 102 may select an additional set of parameters (e.g., α and β) configured for the case of a low priority HARQ-ACK being multiplexed into a high priority PUSCH. PUSCH offset ) may be used, for example, to avoid too many resources being used for eMBB's HARQ-ACK for the required reliability and to ensure that sufficient resources are reserved for URLLC's PUSCH.

[0185] Exemplary Procedure for Collision Between eMBB PUSCH and URLLC SR The priority of PUSCH may be indicated by DCI and / or for grant type 1 configured by RRC signaling. The priority of SR may be indicated by RRC signaling for the corresponding SR configuration.

[0186] The WTRU 102 may multiplex the SR on the PUSCH if a condition is met, and may drop the PUSCH for at least the overlap portion otherwise, e.g., when the SR is positive. For example, the condition may be, among others, (1) the PUSCH resource in the time domain is within the PUCCH resource for the SR (e.g., to ensure that latency requirements are met) and / or (2) the layer Q′ SR The number of coded modulation symbols per metric may include either: being less than a threshold (eg, to ensure that reliability requirements are met).

[0187] When multiplexing a URLLC SR SR on an eMBB PUSCH, the WTRU 102 may jointly encode with the URLLC HARQ-ACK (e.g., if present), at least if the number of HARQ-ACK bits is greater than 2. The WTRU 102 may use an additional set of parameters (e.g., α and β) configured for the case of a high priority HARQ-ACK being multiplexed into a low priority PUSCH. PUSCH offset ) may be used.

[0188] Exemplary Procedure for Collision Between eMBB PUSCH and URLLC HARQ-ACK The priority of the PUSCH may be indicated by DCI and / or for grant type 1 configured by RRC signaling. The priority of the HARQ-ACK may be indicated in the scheduling DCI (and / or the activate DCI command for DL ​​SPS).

[0189] The WTRU 102 may multiplex the HARQ-ACK of URLLC on the PUSCH of eMBB if a condition is met, otherwise the WTRU 102 may drop the PUSCH for at least the overlapping portion. The condition is: (1) the PUSCH resource in the time domain is within a subslot where the HARQ-ACK of URLLC is reported, e.g., to ensure that latency requirements are met, and / or (2) the layer Q′ ACK It may include, for example, that the number of coded modulation symbols per frame is less than a threshold to ensure that reliability requirements are met.

[0190] An additional set of parameters (e.g., α and β) are provided for the case of a high priority HARQ-ACK multiplexed into a low priority PUSCH. PUSCH offset ) may be constructed and used.

[0191] In some representative embodiments, the codebook index may indicate a resource within a slot, such as a subslot, a minislot, or a starting symbol.

[0192] Representative Procedure for Prioritizing for Transmit Power Reduction If the total WTRU transmit power on serving cells in a frequency range in a transmission occasion will or will exceed a threshold (e.g., Pcmax), the WTRU 102 may allocate power according to a priority order. In some examples, the priority order may depend on a service-related priority associated with the transmission (e.g., each transmission). For example, in some embodiments, the service-related priority of a transmission may be prioritized over a priority derived from the type of information carried by the transmission (e.g., whether the transmission carries HARQ-ACK, SR, CSI and / or data only) for at least some types of transmissions, such as PUCCH and / or PUSCH. The prioritization may be set and / or defined by a composite priority index Poverall determined from both types of priorities, e.g., as described in Equation 1 as follows: Poverall=Pserv×Nttype+Pttype (1) where Pserv may be a service-related priority index (e.g., starting at 0 with higher values ​​representing lower priority), Pttype may be a priority index derived from the type of information, and Nttype may be the number of priority levels for the type of information. For example, the value of Nttype may have three priority levels (e.g., a value of 2 for Pttype is associated with a PUSCH transmission without UCI, a value of 1 for Pttype is associated with a PUCCH transmission and / or PUSCH transmission with CSI, and a value of 0 for Pttype is associated with a PUCCH transmission or PUSCH transmission with SR and / or HARQ_ACK). In some embodiments, a PUCCH transmission with CSI may be associated (e.g., always associated) with the highest Pserv value.

[0193] For example, the priority order may be, in descending order, as follows: (1) PRACH transmission on the PCell, (2) PUCCH and / or PUSCH transmission, whose priority may be determined by Poverall, (3) aperiodic SRS, and (4) semi-persistent and / or periodic SRS and / or PRACH transmission on the SCell.

[0194] FIG. 10 is a flow chart illustrating an exemplary procedure for using feedback information (eg, HCAI).

[0195] 10, an exemplary procedure 1000 may include the WTRU 102 receiving a first physical downlink shared channel (PDSCH) associated with a first service type, first priority level or first priority in a first slot or first minislot and receiving a second PDSCH associated with a second service type / priority level / priority in a second slot or second minislot, at block 1010. At block 1020, the WTRU 102 may determine a first HARQ codebook acknowledgement index (HCAI) based on properties of the first PDSCH or control information associated with the first PDSCH, and may determine a second HCAI based on properties of the second PDSCH or control information associated with the second PDSCH. At block 1030, the WTRU 102 may generate a first physical uplink control channel (PUCCH) including first HARQ acknowledgement (HARQ-ACK) information according to the first HCAI and may generate a second PUCCH including second HARQ-ACK information according to the second HCAI for either the second slot, the second minislot, the subsequent slot or the subsequent minislot. At block 1040, the WTRU 102 may transmit the first and second PUCCHs to a network entity. For example, the properties of the first PDSCH and the second PDSCH may be any of a search space, a transmission profile, and / or a temporary identifier.

[0196] In some representative embodiments, the WTRU 102 may multiplex a first set of HARQ-ACK bits as the first HARQ-ACK information and a second set of HARQ-ACK bits as the second HARQ-ACK information in separate PUCCH resources.

[0197] In some representative embodiments, the first service type may be an ultra-reliable low latency communications (URLLC) service or an enhanced URLLC service, the second service type may be another service type, and / or the second service type may be an enhanced mobile broadband (eMBB) service or a high capacity machine type communications (mMTC) service.

[0198] In some representative embodiments, the WTRU 102 may determine the priority level of the PDSCH from an indicated HCAI associated with the PDSCH.

[0199] For example, the DCI (e.g., control signaling) may indicate one or more delay periods associated with various services / priority levels, each of which may indicate one of: (1) a time between the transmission of a respective PDSCH and a respective PUCCH transmission, (2) a number of slots between the transmission of a respective PDSCH and a respective PUCCH transmission, and / or (3) a number of minislots between the transmission of a respective PDSCH and a respective PUCCH transmission.

[0200] FIG. 11 is a flow chart illustrating another exemplary procedure for using feedback information (eg, HCAI).

[0201] 11, a representative procedure 1100 may include, at block 1110, the WTRU 102 receiving multiple physical downlink shared channels (PDSCHs) associated with different service types, priority levels, or priorities in multiple slots or minislots. At block 1120, the WTRU 102 may determine a HARQ codebook acknowledgement index (HCAI) and either (1) a service type for each of the received multiple PDSCHs, (2) a priority level for each of the received multiple PDSCHs, and / or (3) a priority for each of the received multiple PDSCHs. At block 1130, the WTRU 102 may determine a number of PUCCHs to be transmitted for each slot or minislot based on the determined HCAI and the determined service type / priority level / priority. At block 1140, the WTRU 102 may multiplex a number of PUCCHs in different PUCCH resources of each slot or minislot. The WTRU 102 may transmit the determined number of PUCCHs in each slot or each minislot, at block 1150. For example, the determined (1) service type, (2) priority level, and / or (3) priority associated with a PDSCH may be indicated by one or more properties of the PDSCH, including any of a search space, a transmission profile, and / or a temporary identifier.

[0202] In some representative embodiments, the WTRU 102 may multiplex a first set of HARQ-ACK bits as a first HARQ-ACK information according to a first HCAI and a second set of HARQ-ACK bits as a second HARQ-ACK information according to a second HCAI in separate PUCCH resources of a common slot (e.g., provided that each HARQ codebook includes a HARQ-ACK for one or more PDSCHs associated with a HARQ codebook index and / or priority level).

[0203] In some representative embodiments, the conditions for separate PUCCH resources in a common slot may include a first service type, a first priority level, and / or a first priority being indicated as associated with a first HCAI and a different service type, a different priority level, and / or a different priority being indicated as associated with a second HCAI.

[0204] In some representative embodiments, the WTRU 102 may multiplex a first set of HARQ-ACK bits as a first HARQ-ACK information associated with a first HCAI and a second set of HARQ-ACK bits as a second HARQ-ACK information associated with a second HCAI in separate PUCCH resources of different slots (e.g., provided that each HARQ codebook includes a HARQ-ACK for one or more PDSCHs associated with a HARQ codebook index and / or priority level).

[0205] In some representative embodiments, the conditions for separate PUCCH resources in different slots may include a first service type, priority level, and / or priority being indicated as associated with a first HCAI and a different service type, different priority level, and / or different priority being indicated as associated with a second HCAI.

[0206] In some representative embodiments, the WTRU 102 may multiplex a first set of HARQ-ACK bits associated with a first set of PDSCHs and a second set of HARQ-ACK bits associated with a second set of PDSCHs in a common PUCCH resource of a common slot based on a multiplexing rule associated with the priorities, priority levels and / or service types associated with the first and second sets of PDSCHs.

[0207] In some representative embodiments, the first service type may be an ultra-reliable low latency communications (URLLC) service or an enhanced URLLC service, and the second service type may be another service type, and / or, for example, the second service type may be an enhanced mobile broadband (eMBB) service or a high capacity machine type communications (mMTC) service.

[0208] In some representative embodiments, the priority levels may be a highest priority level, e.g., associated with the most important control signaling and / or data, and one or more lower priority levels, e.g., associated with less important control signaling and / or data.

[0209] In some representative embodiments, the WTRU 102 may determine to drop (or whether to drop) at least one PUCCH. For example, the dropping of one or more PUCCHs may be based on any of: (1) properties of the at least one PUCCH, (2) a PUCCH format of the at least one PUCCH, (3) an HCAI, (4) a transmission profile, (5) properties of a PDSCH transmission associated with the at least one PUCCH, and / or (6) properties of a corresponding physical downlink control channel (PDCCH).

[0210] In some representative embodiments, the one or more service types may include any of: (1) ultra-reliable low latency communications (URLLC) service, (2) enhanced URLLC service, (3) enhanced mobile broadband (eMBB) service, and / or (4) high capacity machine type communications (mMTC) service.

[0211] In some representative embodiments, each control signal of the HCAI may indicate a delay period associated with either (1) a time, (2) a number of slots, or (3) a number of minislots between a PDSCH transmission and a PUCCH transmission.

[0212] In some representative embodiments, the WTRU 102 may determine to drop at least one PUCCH or PUSCH. For example, the WTRU 102 may determine to drop at least one PUCCH or PUSCH based on any of: (1) properties of the at least one PUCCH, (2) a PUCCH format of the at least one PUCCH, (3) a HARQ codebook index, (4) a transmission profile, (5) properties of a PDSCH transmission associated with the at least one PUCCH, (6) a priority level, (7) a relative priority level, and / or (8) properties of a corresponding physical downlink control channel (PDCCH).

[0213] FIG. 12 is a flowchart illustrating an exemplary procedure for time domain overlap (eg, of eMBB and URLLC information / control signaling).

[0214] 12, an exemplary procedure 1200 may include the WTRU 102 determining, at block 1210, that a scheduling request (SR) or HARQ information associated with a priority level, e.g., an enhanced mobile broadband (eMBB) service, will overlap in the time domain with a physical uplink shared channel (PUSCH) associated with a higher priority level, e.g., an ultra-reliable low latency communication (URLLC) service or an enhanced URLLC (eURLLC) service. At block 1220, the WTRU 102 may multiplex the SR or HARQ information associated with the lower priority level, e.g., an eMBB service, on a PUSCH associated with the higher priority level, e.g., an URLLC or eURLLC service, provided that the SR or HARQ information associated with the lower priority level will overlap in the time domain with a PUSCH associated with the higher priority level. At block 1230, the WTRU 102 may transmit a PUSCH.

[0215] In some representative embodiments, the WTRU 102 may determine a first priority level for SR or HARQ information (e.g., associated with an eMBB service) and a second priority level for a PUSCH (e.g., associated with a URLLC service or an eURLLC service).

[0216] In some representative embodiments, the multiplexing of SR or HARQ information on the PUSCH may be further conditioned on predetermined rules associated with the first and second priority levels.

[0217] FIG. 13 is a flowchart illustrating an exemplary procedure for using overflow resources for non-priority information / control signaling (eg, HARQ-ACK).

[0218] 13, the exemplary procedure 1300 may include, at block 1310, the WTRU 102 configuring a primary uplink resource and at least one uplink overflow resource. At block 1320, the WTRU 102 may receive information or control signaling. At block 1330, the WTRU 102 may determine whether a HARQ acknowledgement (HARQ-ACK) of the information or control signaling is deprioritized. At block 1340, on the condition that the HARQ-ACK is deprioritized, the WTRU 102 may transmit the HARQ-ACK on the uplink overflow resource. At block 1350, on the condition that the HARQ-ACK is not deprioritized, the WTRU 102 may transmit the HARQ-ACK on the primary uplink resource. For example, the WTRU 102 may determine whether a collision between the HARQ-ACK and any other information or other control signaling will occur, may determine whether the priority level of the HARQ-ACK exceeds the priority level of the other information or other control signaling, and, provided that the priority level of the HARQ-ACK does not exceed the priority level of the other information or other control signaling, the WTRU 102 may de-prioritize the HARQ-ACK.

[0219] The primary and overflow resources may be distinct time and frequency resources with either overlap in time or frequency or no overlap in either of them.

[0220] FIG. 14 is a flow chart illustrating an exemplary procedure for using bit field interpretation (eg, based on service type).

[0221] 14, a representative procedure 1400 may include, at block 1410, the WTRU 102 receiving, by the WTRU, information including downlink control information (DCI). At block 1420, the WTRU 102 may determine or obtain from the received information a service type / priority level / priority to be provisioned to the WTRU. At block 1430, the WTRU 102 may perform an interpretation of a set of bit fields in the received DCI based on the determined service type, the determined priority level and / or the determined priority. At block 1440, the WTRU 102 may configure the WTRU according to the interpretation of the set of bit fields. For example, an interpretation of at least one of the bit fields in the set of bit fields may be different for a first service type, priority level and / or priority to a second service type, priority level and / or priority.

[0222] In some representative embodiments, the interpretation of at least one of the bit fields in the set of bit fields may be associated with (1) a first unit type for a first service type / priority level / priority and (2) a second unit type for a second service type / priority level / priority. For example, the first unit type is (1) a symbol, (2) a group of symbols, (3) a minislot, (4) a slot, or (5) a subframe, and / or the second unit type is a different one of (1) a symbol, (2) a group of symbols, (3) a minislot, (4) a slot, or (5) a subframe. As another example, the first unit type may be a symbol used in association with HARQ feedback timing for ultra-reliable low latency communication (URLLC) services or enhanced URLLC services, and the second unit type may be a slot used in association with HARQ feedback timing for enhanced mobile broadband (eMBB) services.

[0223] In some representative embodiments, the WTRU 102 may determine or obtain one or more service types / priority levels / priorities to be provisioned to the WTRU from either: (1) DCI; (2) radio resource control (RRC) signaling; and / or (3) one or more system information blocks (SIBs).

[0224] In some representative embodiments, the service type may be either an ultra-reliable low latency communication (URLLC) type service, an enhanced URLLC, an enhanced mobile broadband (eMBB) type service, or a high capacity machine type communication (mMTC) type service.

[0225] In some representative embodiments, the received information may include either control channel configuration information and / or PDSCH time domain values. For example, the WTRU 102 may determine the provisioned service type, priority level and / or priority from the included control channel configuration information or the included PDSCH time domain values.

[0226] In some representative embodiments, the control channel configuration information may include any of: (1) a search space monitoring pattern, (2) a search space monitoring periodicity, (3) a search space duration, (4) a CORESET configuration, (5) an RNTI used to scramble the cyclic redundancy check (CRC), and / or (6) a bandwidth part configuration.

[0227] In some representative embodiments, if the DCI received by the WTRU 102 is within a search space configured using the search space monitoring pattern, the WTRU 102 may determine that the service type, priority level or priority to be provisioned to the WTRU is a first service type, first priority level or first priority, and if the DCI received by the WTRU is not within a search space configured using the search space monitoring pattern, the WTRU 102 may determine that the service type to be provisioned to the WTRU is a second service type, second priority level or second priority.

[0228] In some representative embodiments, on condition that the monitoring periodicity exceeds the periodicity threshold, the WTRU 102 may determine that the service type, priority level or priority to be provisioned to the WTRU is a first service type, first priority level or first priority, and on condition that the monitoring periodicity does not exceed the periodicity threshold, the WTRU 102 may determine that the service type, priority level or priority to be provisioned to the WTRU is a second service type, second priority level or second priority.

[0229] In some representative embodiments, if the DCI received by the WTRU 102 is within a search space having a duration less than K slots, where K is an integer, the WTRU 102 may determine that the service type, priority level or priority to be provisioned to the WTRU is a first service type, first priority level or first priority, and if the duration is greater than or equal to K slots, the WTRU 102 may determine that the service type, priority level or priority to be provisioned to the WTRU is a second service type, second priority level or second priority.

[0230] In some representative embodiments, if the PDSCH time domain value is below the threshold or within the range between the thresholds, the WTRU 102 may determine that the service type, priority level or priority provisioned to the WTRU is a first service type, first priority level or first priority, and if the PDSCH time domain value is not below the threshold or within the range between the thresholds, the WTRU 102 may determine that the service type, priority level or priority provisioned to the WTRU is a second service type, second priority level or second priority.

[0231] In some representative embodiments, the set of bit fields in the received DCI may include a HARQ timing indication value in a HARQ timing indication bit field. For example, interpretation of the HARQ timing indication value in the HARQ timing indication bit field may be based on any of: (1) one or more physical downlink shared channel (PDSCH) time domain allocation values, (2) a DMRS mapping type, (3) a starting symbol of the PDSCH, (4) a length of the PDSCH transmission, (5) an offset or delay between reception of the PDCCH and the starting symbol of the PDSCH, and / or (6) one or more HARQ process ID values.

[0232] In some representative embodiments, the WTRU 102 may determine that the PDSCH transmission belongs to a first set of PDSCH transmissions associated with a first service type, a first priority level, or a first priority if the PDSCH duration is below a threshold, and may otherwise determine that the PDSCH transmission belongs to a second set of PDSCH transmissions associated with a second service type, a second priority level, or a second priority.

[0233] FIG. 15 is a flow chart illustrating an exemplary procedure for HARQ feedback (eg, based on service type).

[0234] 15, the exemplary procedure 1500 may include, at block 1510, the WTRU 102 receiving, by the WTRU, information. At block 1520, the WTRU 102 may determine from the received information that the WTRU is provisioned for a first service type / priority level / priority. At block 1530, the WTRU 102 may generate coded bits for a transmission associated with the first service type / priority level / priority. At block 1540, the WTRU 102 may overwrite a subset of the generated coded bits with coded bits associated with a second service type / priority level / priority, as the overwritten coded bits, to generate a sequence of coded bits associated with the first and second services / priority levels / priorities, the second service type / priority level / priority having a higher priority level than the priority level of the first service type / priority level / priority. The WTRU 102 may generate a signal for transmission using the sequences of coded bits associated with the first and second services / priority levels / priorities, at block 1550. The WTRU 102 may transmit the signal to a network entity, at block 1550.

[0235] In some representative embodiments, the coded bits of the transmitted signal may include a set of coded bits associated with a first type of service / priority level / priority control function or data and a set of coded bits associated with a second type of service / priority level / priority control function.

[0236] In some representative embodiments, the first service type may be an enhanced Mobile Broadband (eMBB) service and the second service type may be Ultra Reliable Low Latency Communications (URLLC) or enhanced URLLC.

[0237] In some representative embodiments, the control function or data of the first service type / priority level / priority may be any of (1) a scheduling request (SR), (2) a HARQ-ACK, (3) a CSI, or (4) data of the first service type / priority level / priority, and / or the control function of the second service type / priority level / priority may be any of (1) a SR, (2) a HARQ-ACK, or (3) a CSI of the second service type / priority level / priority.

[0238] In some representative embodiments, the WTRU 102 may determine whether some coded bits of a first service type / priority level / priority to be overwritten have a correspondence with the coded bits to be overwritten and some bits to be replaced. For example, the WTRU 102 may overwrite some coded bits of a first service type, first priority level or first priority, provided that some coded bits of a first service type, first priority level or first priority to be overwritten have a correspondence with some coded bits to be replaced with the coded bits to be overwritten. As another example, the WTRU 102 may drop some of the coded bits of a first service type, first priority level or first priority without overwriting, and replace the dropped bits with a set of coded bits associated with a second service type, second priority level or second priority, provided that some coded bits of a first service type, first priority level or first priority to be overwritten do not have a correspondence with some coded bits to be replaced with the coded bits to be overwritten.

[0239] Overwriting a subset of coded bits associated with a first service type, a first priority level or a first priority may include the WTRU determining a first sequence of coded bits associated with the first service type, the first priority level or first priority, determining positions in the first sequence of coded bits associated with the first service type, the first priority level or first priority to be replaced with coded bits associated with a second service type, the second priority level or second priority, deleting in the first sequence of coded bits at the determined positions, and / or inserting coded bits associated with the second service type at the determined positions.

[0240] FIG. 15 is a flow chart illustrating an exemplary procedure for HARQ feedback (eg, based on service type).

[0241] 15, an exemplary procedure 1500 may include the WTRU 102 receiving information, at block 1510. The WTRU 102 may determine from the received information that the WTRU is provisioned for a first service type or first priority level and a second service type or second priority level, at block 1520. The WTRU 102 may configure the WTRU for transmission of a first HARQ feedback associated with the first service type or first priority level and a second HARQ feedback associated with the second service type or second priority level, at block 1530.

[0242] In some representative embodiments, the configuration of the WTRU for transmission of a first HARQ feedback associated with a first service type or first priority level and a second HARQ feedback associated with a second service type or second priority level may include setting a first portion of time-frequency resources for carrying the first HARQ feedback and a second separate portion of time-frequency resources for carrying the second HARQ feedback.

[0243] In some representative embodiments, the WTRU 102 may receive first data associated with a first service type or a first priority level and second data associated with a second service type or a second priority level such that a first delay time between receiving the first data and transmitting the first HARQ feedback may be less than a second delay time between receiving the second data and transmitting the second HARQ feedback. For example, the first service type or the first priority level may be or correspond to an ultra-reliable low latency communication (URLLC) service or an enhanced URLLC (eURLLC) service, and the second service type or the second priority level may be or correspond to an enhanced mobile broadband (eMBB) service. For example, the first priority level may be a priority associated with a URLLC or eURLLC service, and the second priority may be a priority level associated with eMBB.

[0244] In some representative embodiments, the second HARQ feedback may be sent in a long format physical uplink control channel (PUCCH) and / or the first HARQ feedback may be sent in a format with a shorter latency than the second HARQ feedback.

[0245] FIG. 16 is a flow chart illustrating a typical overwrite procedure.

[0246] Referring to FIG. 16, a representative procedure 1600 may include, at block 1610, the WTRU 102 receiving information. At block 1620, the WTRU 102 may determine from the received information that the WTRU 102 is provisioned for a first service type or a first priority level. At block 1630, the WTRU 102 may generate coded bits for a transmission associated with the first service type / priority level. At block 1640, the WTRU 102 may overwrite a subset of the generated coded bits with coded bits associated with a second service type or second priority level as the overwritten coded bits to generate a sequence of coded bits associated with the first and second services / priority levels. In some embodiments, the second service type may have a higher priority level than the priority level of the first service type. At block 1650, the WTRU 102 may generate a signal for transmission using the sequence of coded bits associated with the first and second services / priority levels. At block 1660, the WTRU 102 may transmit the generated signal to a network entity.

[0247] In some representative embodiments, the coded bits of the transmitted signal may include a set of coded bits associated with a control function or data of a first service type / priority level and a set of coded bits associated with a control function of a second service type / priority level. For example, the first service type / priority level may be or correspond to an eMBB service and the second service type may be a URLLC service or an eURLLC service.

[0248] The control function or data of the first service type / priority level may be, for example, any of (1) a scheduling request (SR), (2) a HARQ-ACK, (3) CSI, and / or (4) data of the first service type / priority level, and / or the control function of the second service type / priority level may be any of (1) a SR, (2) a HARQ-ACK, and / or (3) CSI of the second service type / priority level.

[0249] In some representative embodiments, the WTRU 102 may determine whether a number of coded bits of the first service type / priority level to be overwritten have a correspondence between the coded bits being overwritten and the number of coded bits to be replaced, and, provided that a number of bits of the first service type / priority level to be overwritten have a correspondence between the coded bits being overwritten and the number of coded bits to be replaced, the WTRU 102 may overwrite a number of coded bits of the first service type / priority level.

[0250] In some representative embodiments, the WTRU 102 may drop a portion of the coded bits of the first service type / priority level and replace the dropped bits with a set of coded bits associated with a second service type / priority level, provided that some coded bits of the first service type / priority level to be overwritten do not have a correspondence with some coded bits to be replaced with the coded bits to be overwritten. For example, overwriting a subset of the coded bits associated with the first service type / priority level may include the WTRU 102 determining a first sequence of coded bits associated with the first service type / priority level, determining positions in the first sequence of coded bits associated with the first service type / priority level to be replaced with coded bits associated with the second service type / priority level, deleting in the first sequence of coded bits at the determined positions, and / or inserting coded bits associated with the second service type / priority level at the determined positions.

[0251] FIG. 17 is a flow chart illustrating an exemplary procedure for avoiding anticipated collisions.

[0252] 17, the exemplary procedure 1700 may include the WTRU 102 selecting, at block 1710, either (1) a multiplexing operation to multiplex coded bits of a first service type / priority level with coded bits of a second service type / priority level, (2) an overwriting operation to overwrite coded bits of the first service type / priority level with coded bits of the second service type / priority level, and / or (3) a drop / insert operation to drop coded bits of the first service type / priority level and insert coded bits of the second service type / priority level in the position of the dropped coded bits based on a suitability criterion. At block 1720, the WTRU 102 may generate a sequence of coded bits associated with the first and second services using the selected operation. At block 1730, the WTRU 102 may generate a signal for transmission using the sequence of coded bits. At block 1740, the WTRU 102 may transmit the signal to a network entity.

[0253] In some representative embodiments, the suitability criteria may be based on any of: (1) a service-based priority level; (2) a latency requirement of the second service type / priority level; (3) a duration of the conflicting resources; (4) an end time of the conflicting resources; (5) a maximum time delay and / or offset configured by a higher layer; (6) a periodicity of the conflicting resources; (7) a reliability requirement of the second service type / priority level; (8) a number of coded modulation symbols per layer that is below a first threshold; (9) a maximum amount of overwriting; (10) a coding rate associated with the conflicting resources that is less than a second threshold; and / or (11) a total number of coded bits associated with the first or second service type / priority level that is less than a maximum payload configured for the conflicting resources.

[0254] FIG. 18 is a flow chart illustrating a representative multiplexing procedure.

[0255] 18, a representative procedure 1800 may include, at block 1810, the WTRU 102 determining whether a collision between or among one or more of the multiple transmissions is expected. At block 1820, the WTRU 102 may determine a timing or status of the expected collision. At block 1830, on the condition that at least one collision is expected, the WTRU 102 may determine whether to initiate an action to mitigate the at least one collision at a first layer or at a second layer (e.g., to drop and / or not initiate some expected subsequent actions) based on the timing or status of the expected collision. At block 1840, the WTRU 102 may initiate an action to mitigate the at least one collision at the determined layer. For example, expected collisions may be between any of: (1) the physical uplink shared channel (PUSCH) and a scheduling request (SR), (2) the PUSCH and uplink control information (UCI), and / or (3) higher priority uplink control information and lower priority uplink control information.

[0256] In some representative embodiments, the WTRU 102 may determine whether a scheduling request (SR) or uplink control information (UCI) to be transmitted in the first transmission has already been signaled to the physical layer as a first layer, or whether construction of a PUSCH has started at the physical layer.

[0257] In some representative embodiments, the WTRU 102 may decide to initiate action at the physical layer (1) on condition that an SR or UCI has already been signaled to the physical layer or construction of a PUSCH has started at the physical layer, or (2) on condition that an SR or UCI has not been signaled to the physical layer or construction of a PUSCH has not started at the physical layer. For example, if the WTRU 102 signals a higher priority SR that overlaps with a PUSCH, the WTRU 102 may not construct a MAC PDU.

[0258] For example, initiating an action at the determined layer may include any of: (1) dropping the SR or UCI at the physical layer after the SR or UCI has been signaled; (2) stopping the signaling of the SR or UCI at the MAC layer; (3) dropping or suspending the PUSCH at the physical layer; and / or (4) stopping the signaling of the PUSCH at the MAC layer.

[0259] FIG. 19 is a flow chart illustrating an exemplary procedure (eg, for transmission of uplink control information (UCI)).

[0260] 19, a representative procedure 1900 may include, at block 1910, the WTRU 102 configuring the WTRU to transmit multiple PUSCH transmissions in a slot and / or overlapping in the time domain. At block 1920, the WTRU 102 may select at least one PUSCH for multiplexing uplink control information (UCI) based on one or more criteria including one or more service level priorities associated with each of the PUSCH transmissions. At block 1930, the WTRU 102 may multiplex the UCI on the selected PUSCH. At block 1940, the WTRU 102 may transmit a PUSCH carrying the multiplexed UCI. For example, the one or more criteria may include whether the PUSCH transmission is suitable for transmission of a combination of UCI and data.

[0261] In some representative embodiments, PUSCH transmissions in a slot or overlapping may be on different serving cells and / or different carriers and / or each PUSCH transmission may have a different service-related priority.

[0262] In some representative embodiments, the WTRU 102 may select a PUSCH for multiplexing UCI based on a service level priority of the PUSCH and / or a service level priority of the UCI.

[0263] The systems and methods for processing data according to the representative embodiments may be implemented by one or more processors executing sequences of instructions contained in a memory device. Such instructions may be read into the memory device from other computer-readable media, such as a secondary data storage device. Execution of the sequences of instructions contained in the memory device causes the processor to operate, for example, as described above. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. Such software may be executed on a processor stored within a robotic assist / apparatus (RAA) and / or remotely on another mobile device. In the latter case, data may be transferred over wirelines or wirelessly between the RAA or other mobile device including the sensor and a remote device including a processor executing software implementing the scale estimation and compensation described above. According to other representative embodiments, some of the processing described above with respect to localization may be implemented in the device including the sensor / camera, while the remainder of the processing may be implemented in the second device after receiving partially processed data from the device including the sensor / camera.

[0264] Although the features and elements have been described above in certain combinations, those skilled in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks and removable disks, magnetic media such as magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0265] Moreover, in the embodiments described above, processing platforms, computing systems, controllers, and other devices that include processors are noted. These devices may include at least one central processing unit ("CPU") and memory. In accordance with the practices of those skilled in the art of computer programming, references to acts and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "computer-executed," or "CPU-executed."

[0266] Those skilled in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by a CPU. The electrical system represents the data bits, which cause the resulting transformation or reduction of the electrical signals and the maintenance of the data bits in memory locations in a memory system, thereby reconfiguring or otherwise altering the operation of the CPU, as well as other processing of the signals. The memory locations in which the data bits are maintained are physical locations that have specific electrical, magnetic, optical, or organic properties that correspond to or are representative of the data bits. It should be understood that representative embodiments are not limited to the platforms or CPUs mentioned above, and that other platforms and CPUs may support a given method.

[0267] The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read only memory ("ROM")) mass storage system readable by a CPU. The computer readable medium may include computer readable media that resides solely on a processing system or that is distributed, cooperating, or interconnected among multiple interconnected processing systems that may be local or remote to a processing system. It is to be understood that representative embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the described methods. It is to be understood that representative embodiments are not limited to the above-mentioned platforms or CPUs and that other platforms and CPUs may support a given method.

[0268] In an example embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0269] There is little difference remaining between hardware and software implementations of aspects of the system. The use of hardware or software is generally a design choice that represents a cost vs. efficiency tradeoff (although this is not always the case, in that in some contexts the choice between hardware and software can be significant). There may be various vehicles (e.g., hardware, software, and / or firmware) in which the processes and / or systems and / or other techniques described herein may be affected, and the preferred vehicle may change with the context in which the processes and / or systems and / or other techniques are deployed. For example, if the implementer determines that speed and accuracy are paramount, the implementer may select a primarily hardware and / or firmware vehicle. If flexibility is paramount, the implementer may select a primarily software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0270] The above detailed description describes various embodiments of the devices and / or processes through the use of block diagrams, flow charts, and / or examples. To the extent that such block diagrams, flow charts, and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation within such block diagrams, flow charts, or examples may be individually and / or collectively implemented by a wide range of hardware, software, firmware, or virtually any combination thereof. Suitable processors include, by way of example, general purpose processors, special purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors in conjunction with a DSP core, controllers, microcontrollers, application specific integrated circuits (ASICs), application specific standard products (ASSPs), field programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines.

[0271] The present disclosure should not be limited with respect to the specific embodiments described in this application, which are intended as examples of various aspects. Numerous modifications and changes can be made without departing from the spirit and scope thereof, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of this application should be construed as critical or essential to the invention unless expressly provided as such. In addition to those recited herein, functionally equivalent methods and apparatuses within the scope of the present disclosure will be apparent to those skilled in the art from the above description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is to be understood that the present disclosure is not limited to a particular method or system.

[0272] It should also be understood that the terminology used herein is for purposes of describing particular embodiments only and is not intended to be limiting. As used herein, the terms "station" and its abbreviations "STA" and "user equipment" and "UE" when referenced herein may mean (i) a wireless transmit and / or receive unit (WTRU), as described below, (ii) any of several embodiments of a WTRU, as described below, (iii) a wireless-enabled and / or wired-enabled (e.g., tetherable) device configured with some or all of the structure and functionality of a WTRU, as described below, among others, (iii) a wireless-enabled and / or wired-enabled device configured with less than all of the structure and functionality of a WTRU, as described below, or (iv) the like. Details of an exemplary WTRU, which may represent any UE recited herein, are provided below with respect to FIGS. 1A-1D.

[0273] In some representative embodiments, some portions of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein may be equivalently implemented in integrated circuits, in whole or in part, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as nearly any combination thereof, and that designing circuitry and / or writing code for software and / or firmware may be well within the skill of those skilled in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as program products in various forms, and that the exemplary embodiments of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually effect the distribution. Examples of signal bearing media include, but are not limited to, recordable type media such as floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memory, and transmission type media such as digital and / or analog communications media (e.g., fiber optic cables, wave guides, wired communications links, wireless communications links, etc.).

[0274] The subject matter described herein sometimes shows different components contained within or connected to different other components. It should be understood that such illustrated architectures are merely examples, and that in fact many other architectures that achieve the same functionality may be implemented. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that a desired functionality may be achieved. Thus, any two components combined herein to achieve a particular functionality may be viewed as "associated" with one another such that a desired functionality is achieved, regardless of the architecture or intermediate components. Similarly, any two components so associated may be viewed as "operably connected" or "operably coupled" with one another to achieve a desired functionality, and any two components capable of being so associated may be viewed as "operably coupled" with one another to achieve a desired functionality. Particular examples of operably coupleable include, but are not limited to, physically matable and / or physically interacting components, and / or wirelessly interacting and / or wirelessly interacting components, and / or logically interacting and / or logically interacting components.

[0275] With respect to the use of virtually any plural and / or singular term herein, those of skill in the art can convert from plural to singular and / or from singular to plural as appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for clarity.

[0276] In general, it will be understood by those of skill in the art that the terms used herein, and particularly in the appended claims (e.g., the body of the appended claims), are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including, but not limited to," the term "having" should be interpreted as "having at least," the term "including" should be interpreted as "including, but not limited to," etc.). Furthermore, it will be understood by those of skill in the art that if a specific number of claim recitations to be introduced are intended, such intent will be expressly recited in the claim, and in the absence of such recitation, no such intent exists. For example, if only one item is intended, the term "single" or similar language may be used. As an aid to understanding, the following appended claims and / or description of this specification may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation with the indefinite article "a" or "an" limits any particular claim containing such an introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be construed to mean "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim recitations. In addition, those skilled in the art will recognize that even if a specific number of introduced claim recitations is explicitly recited, such recitations should be construed to mean at least the recited number (e.g., the bare recitation "two recitations" without other modifiers means at least two recitations, or more than two recitations).Additionally, in instances where notation similar to "at least one of A, B, and C, etc." is used, such syntax is generally intended in the sense that one of ordinary skill in the art would understand the notation (e.g., "a system having at least one of A, B, and C" would include, but is not limited to, a system having only A, a system having only B, a system having only C, a system having A and B together, a system having A and C together, a system having B and C together, and / or a system having A, B, and C together, etc.). In instances where notation similar to "at least one of A, B, or C, etc." is used, such syntax is generally intended in the sense that one of skill in the art would understand the notation (e.g., "a system having at least one of A, B, or C" would include, but is not limited to, a system having only A, a system having only B, a system having only C, a system having A and B together, a system having A and C together, a system having B and C together, and / or a system having A, B, and C together, etc.). Additionally, it will be understood by those of skill in the art that nearly any disjunctive word and / or phrase presenting two or more alternative terms, regardless of whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Additionally, as used herein, the term "any of" and its associated listing of items and / or item categories is intended to include "any of," "any combination of," "any number of," and / or "any combination of multiple of" the items and / or item categories, either individually or in conjunction with other items and / or other item categories. Moreover, as used herein, the term "set" or "group" is intended to include any number of items, including zero.Furthermore, as used herein, the term "number" is intended to include any number, including zero.

[0277] In addition, when features or aspects of the disclosure are described in terms of a Markush group, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual members or subgroups of members of the Markush group.

[0278] As will be understood by those skilled in the art, for any and all purposes, including with respect to providing a specification, all ranges disclosed herein include any and all possible subranges, as well as combinations of subranges thereof. Any listed range can be readily recognized as fully describing and allowing for the same range to be subdivided into at least equal 1 / 2, 1 / 3, 1 / 4, 1 / 5, 1 / 10, etc. As a non-limiting example, each range discussed herein can be readily subdivided into a lower 1 / 3, a middle 1 / 3, and an upper 1 / 3, etc. As will also be understood by those skilled in the art, all phrases such as "up to," "at least," "greater than," "less than," etc., include the recited numbers and refer to ranges that can be subsequently subdivided into subranges as discussed above. Finally, as will be understood by those skilled in the art, a range includes each individual member. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to groups having 1, 2, 3, 4, or 5 cells, etc.

[0279] Moreover, the claims should not be read as limited to the order or elements provided unless stated to that effect. In addition, the use of the term "means for" in any claim is intended to invoke 35 U.S.C. 112, sixth paragraph or means-plus-function claim format, and any claim without the term "means for" is not so intended.

[0280] A processor in association with software may be used to implement a wireless transmit / receive unit (WTRU), user equipment (UE), terminal, base station, mobility management entity (MME) or evolved packet core (EPC), or a radio frequency transceiver for use in any host computer. The WTRU may be used in conjunction with modules implemented in hardware and / or software including software defined radios (SDRs) and other components such as cameras, video camera modules, videophones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keyboards, Bluetooth modules, frequency modulation (FM) radio units, near field communications (NFC) modules, liquid crystal display (LCD) display units, organic light emitting diode (OLED) display units, digital music players, media players, video game player modules, Internet browsers, and / or any wireless local area network (WLAN) or ultra-wideband (UWB) modules.

[0281] Throughout this disclosure, those skilled in the art will understand that some representative embodiments may be used in the alternative or in combination with other representative embodiments.

[0282] In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable storage medium as instructions for a computer or processor to execute to perform the acts described above. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks and removable disks, magnetic media such as magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A wireless transmit receive unit (WTRU), comprising: A receiver and a transmitter, and a processor, The receiver includes: receiving a first physical downlink shared channel (PDSCH) transmission; receiving a second PDSCH transmission; It is configured as follows: The processor, determining a first physical uplink control channel (PUCCH) resource for transmission of first hybrid automatic repeat request (HARQ) information associated with the first PDSCH transmission; determining a second PUCCH resource for transmission of second HARQ information associated with the second PDSCH transmission; determining a priority of each of the first HARQ information and the second HARQ information; determining that lower priority HARQ information is allowed to be multiplexed with higher priority HARQ information, on condition that the first PUCCH resource overlaps in time with the second PUCCH resource and on condition that the priority of the first HARQ information is different from the priority of the second HARQ information; It is configured as follows: the transmitter is configured to multiplex the first HARQ information and the second HARQ information and send the multiplexed first HARQ information and second HARQ information within a single PUCCH transmission, the multiplexing being subject to the condition that the lower priority HARQ information is allowed to be multiplexed with the higher priority HARQ information. WTR U.

2. 2. The WTRU of claim 1, wherein the receiver is configured to receive configuration information indicating a plurality of PUCCH resource sets used for transmission of HARQ information, each of the plurality of PUCCH resource sets including a plurality of PUCCH resources.

3. 2. The WTRU of claim 1, wherein the receiver is configured to receive information in a first downlink control information (DCI) including (1) a first PUCCH set indication and (2) a first resource indicator, the first PUCCH set indication and the first resource indicator being separate fields in the first DCI.

4. 2. The WTRU of claim 1, wherein the receiver is configured to receive information in a second DCI including: (1) a second PUCCH set indication and (2) a second resource indicator, the second PUCCH set indication and the second resource indicator being separate fields in the second DCI.

5. 3. The WTRU of claim 2, wherein the receiver is configured to receive information in a first downlink control information (DCI) including (1) a first PUCCH set indication and (2) a first resource indicator, and the processor is configured to select a first PUCCH resource set of the plurality of PUCCH resource sets based at least on the first PUCCH set indication.

6. 6. The WTRU of claim 5, wherein the processor configured to determine a first PUCCH resource for transmission of the first HARQ information comprises a processor configured to select a first PUCCH resource of the plurality of PUCCH resources of the selected first PUCCH resource set based at least on the first resource indicator.

7. 3. The WTRU of claim 2, wherein the receiver is configured to receive information in a second DCI including (1) a second PUCCH set indication and (2) a second resource indicator, and the processor is configured to select a second PUCCH resource set from the plurality of PUCCH resource sets based at least on the second PUCCH set indication.

8. 8. The WTRU of claim 7, wherein the processor configured to determine a second PUCCH resource for transmission of the second HARQ information comprises a processor configured to select a second PUCCH resource from the plurality of PUCCH resources of the selected second PUCCH resource set based at least on the second resource indicator.

9. 2. The WTRU of claim 1, wherein the single PUCCH transmission includes the higher priority HARQ information and does not include the lower priority HARQ information, provided that the lower priority HARQ information is not allowed to be multiplexed with the higher priority HARQ information.

10. The WTRU of claim 1 , wherein the lower priority HARQ information and the higher priority HARQ information are encoded separately before the multiplexing.

11. 1. A method implemented in a wireless transmit receive unit (WTRU), comprising: receiving a first physical downlink shared channel (PDSCH) transmission; determining a first physical uplink control channel (PUCCH) resource for transmission of first hybrid automatic repeat request (HARQ) information associated with the first PDSCH transmission; receiving a second PDSCH transmission; determining a second PUCCH resource for transmission of second HARQ information associated with the second PDSCH transmission; determining a priority of each of the first HARQ information and the second HARQ information; determining that lower priority HARQ information is allowed to be multiplexed with higher priority HARQ information, on condition that the first PUCCH resource overlaps in time with the second PUCCH resource and on condition that the priority of the first HARQ information is different from the priority of the second HARQ information; multiplexing the first HARQ information and the second HARQ information, on condition that the lower priority HARQ information is allowed to be multiplexed with the higher priority HARQ information, and sending the multiplexed first HARQ information and second HARQ information within a single PUCCH transmission; The method includes:

12. 12. The method of claim 11, further comprising: receiving configuration information indicating a plurality of PUCCH resource sets used for transmission of HARQ information, each of the plurality of PUCCH resource sets including a plurality of PUCCH resources.

13. 12. The method of claim 11, further comprising receiving, in a first downlink control information (DCI), information including (1) a first PUCCH set indication and (2) a first resource indicator, wherein the first PUCCH set indication and the first resource indicator are separate fields in the first DCI.

14. 12. The method of claim 11, further comprising receiving, in a second DCI, information including (1) a second PUCCH set indication and (2) a second resource indicator, wherein the second PUCCH set indication and the second resource indicator are separate fields in the second DCI.

15. Receiving information in a first downlink control information (DCI) including (1) a first PUCCH set indication and (2) a first resource indicator; selecting a first PUCCH resource set of the plurality of PUCCH resource sets based at least on the first PUCCH set indication; The method of claim 12 further comprising:

16. 16. The method of claim 15, wherein determining a first PUCCH resource for transmission of the first HARQ information comprises selecting a first PUCCH resource of the plurality of PUCCH resources of the selected first PUCCH resource set based at least on the first resource indicator.

17. Receiving information in a second DCI, the information including (1) a second PUCCH set indication and (2) a second resource indicator; selecting a second PUCCH resource set from the plurality of PUCCH resource sets based at least on the second PUCCH set indication; The method of claim 12 further comprising:

18. 20. The method of claim 17, wherein determining a second PUCCH resource for transmission of the second HARQ information comprises selecting a second PUCCH resource of the plurality of PUCCH resources of the selected second PUCCH resource set based at least on the second resource indicator.

19. 12. The method of claim 11, wherein the single PUCCH transmission includes the higher priority HARQ information and does not include the lower priority HARQ information, provided that the lower priority HARQ information is not allowed to be multiplexed with the higher priority HARQ information.

20. The method of claim 11 , wherein the lower priority HARQ information and the higher priority HARQ information are encoded separately before the multiplexing.

Images