Methods, systems, and devices for transferring data with different reliability

Abstract

To provide systems, methods, and devices for transferring data with different reliability.SOLUTION: A WTRU receives configuration information indicating a first CG and a second CG, where the configuration information further indicates a first CG offset associated with the first CG and a second CG offset associated with the second CG: determines that a first transmission resource associated with the first CG and a second transmission resource associated with the second CG at least partially overlap in time; selects the first transmission resource or the second transmission resource for uplink transmission; determines a HARQ process ID associated with the uplink transmission, on the basis of, at least the first CG offset when the first transmission resource is selected, or the second CG offset when the second transmission resource is selected; and transmits the uplink transmission using the selected one of the first transmission resource or the second transmission resource.SELECTED DRAWING: Figure 4

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 687,085, filed June 19, 2018, U.S. Provisional Patent Application No. 62 / 752,807, filed October 30, 2018, and U.S. Provisional Patent Application No. 62 / 779,271, filed December 13, 2018, the contents of which are incorporated herein by reference.

[0002] A New Radio (NR) radio transmit / receive unit (WTRU) may be configured by radio resource control (RRC) with an additional network temporary identifier (RNTI) apart from the cell radio network temporary identifier (C-RNTI). Summary of the Invention

[0003] Some embodiments provide a method implemented in a wireless transmit / receive unit (WTRU) for uplink (UL) transmission. A first grant is received or configured for a first UL resource, and a second grant is received or configured for a second UL resource. The WTRU transmits uplink data and / or control information (e.g., SR signaling, HARQ ACK / NACK information, MAC CE) using the UL resource. It is determined whether the first UL resource overlaps in time with the second UL resource. If the first UL resource overlaps in time with the second UL resource, a first available processing time is determined. If the first available processing time is greater than a first threshold, either the first UL resource or the second UL resource is designated as a preferred UL resource, a single transmission and / or transport block (TB) is generated for the preferred resource, and the single TB is transmitted on the preferred resource.

[0004] In some embodiments, if the first available processing time is less than a first threshold but the second available processing time is greater than a second threshold, either the first UL resource or the second UL resource is designated as a preferred UL resource, a first TB and / or UL control information is generated for the first resource, a second TB and / or UL control information is generated for the second resource, a first transmission is initiated on the first UL resource, a second transmission is initiated on the second UL resource, and a preemption procedure is performed on the first transmission and the second transmission.

[0005] In some embodiments, if the second available processing time is less than a second threshold, either the first UL resource or the second UL resource is designated as a preferred UL resource, TB and / or UL control information is generated for the overlapping resource, processing and transmission for the non-preferred UL resource is discontinued, and TB and / or UL control information is transmitted on the preferred UL resource.

[0006] In some embodiments, the first available processing time includes a time difference between a determination that the first UL resource overlaps in time with the second UL resource and an earliest start time of all transmissions on the first UL resource and the second UL resource. In some embodiments, the second available processing time includes a time difference between a determination that the first UL resource overlaps in time with the second UL resource and a start of the overlap in time between the first UL resource and the second UL resource. In some embodiments, the WTRU determines whether the first UL resource and the second UL resource overlap in time based on scheduling information. In some embodiments, the scheduling information includes resources for transmission of the first UL grant, the second UL grant, or UL control information. In some embodiments, the WTRU determines that the first UL resource and the second UL resource overlap in time, provided that at least one logical channel with buffered data is allowed initial transmission on both the first UL resource and the second UL resource. In some embodiments, the WTRU determines that the first UL resource and the second UL resource overlap in time, provided that the highest logical channel priority mapped to the first UL resource is different from the highest logical channel priority mapped to the second UL resource.

[0007] In some embodiments, the first threshold is based on the shortest time required by the WTRU to determine the priority of the first UL resource and the priority of the second UL resource. In some embodiments, the first threshold is based on the shortest time required by the WTRU to evaluate logical channel prioritization (LCP) restrictions for the first grant and for the second grant, and the logical channel of the highest configured priority is mapped to the first grant and the second grant. In some embodiments, the first threshold is based on the shortest time required by the WTRU to evaluate the logical channel of the highest configured priority mapped to the first UL resource according to the configured logical channel prioritization (LCP) restrictions and the logical channel corresponding to (or that triggered) the UL control information mapped to the second UL resource. In some embodiments, the second threshold is based on the shortest time required to perform a preemption procedure and to determine the priority for each UL resource based on grant processing at the physical layer. In some embodiments, the preemption procedure includes preempting the first transmission or the second transmission by the physical layer based on the prioritization of the first UL resource or the second UL resource. In some embodiments, designating either the first UL resource or the second UL resource as a prioritized UL resource includes performing logical channel prioritization (LCP), evaluating the highest priority logical channel mapped to the UL resource, and / or evaluating the logical channel that corresponds to (or triggered) the UL control information mapped to the UL resource.

[0008] Some embodiments provide a wireless transmit / receive unit (WTRU) configured for uplink (UL) transmission. The WTRU includes a receiver circuit that receives a first grant for a first UL resource and a second grant for a second UL resource, and a processor coupled to the receiver circuit that determines whether the first UL resource overlaps in time with the second UL resource. If the first UL resource overlaps in time with the second UL resource, the processor determines a first available processing time. If the first available processing time is greater than a first threshold, the processor designates either the first UL resource or the second UL resource as a preferred UL resource, generates a single transport block (TB) and / or UL control information for the preferred resource, and transmits it over the preferred resource via a transmitter circuit coupled to the processor.

[0009] In some embodiments, if the first available processing time is less than a first threshold but the second available processing time is greater than a second threshold, the processor designates either the first UL resource or the second UL resource as a prioritized UL resource, generates a first TB and / or UL control information for the first resource and a second TB and / or UL control information for the second resource, initiates a first transmission on the first UL resource, initiates a second transmission on the second UL resource, and performs a preemption procedure for the first transmission and the second transmission.

[0010] In some embodiments, if the second available processing time is less than a second threshold, the processor designates either the first UL resource or the second UL resource as a preferred UL resource, generates TB and / or UL control information for the overlapping resource, discontinues processing and transmission for the non-preferred UL resource, and transmits the TB and / or UL control information on the preferred UL resource.

[0011] In some embodiments, the first available processing time includes a time difference between a determination that the first UL resource overlaps in time with the second UL resource and an earliest start time of all transmissions on the first UL resource and the second UL resource. In some embodiments, the second available processing time includes a time difference between a determination that the first UL resource overlaps in time with the second UL resource and a start of the overlap in time between the first UL resource and the second UL resource. In some embodiments, the processor is further configured to determine whether the first UL resource and the second UL resource overlap in time based on scheduling information. In some embodiments, the scheduling information includes resources for transmission of the first UL grant, the second UL grant, or UL control information. In some embodiments, the processor is further configured to determine that the first UL resource and the second UL resource overlap in time, provided that at least one logical channel having buffered data is allowed initial transmission for both the first UL resource and the second UL resource. In some embodiments, the processor is further configured to determine that the first UL resource and the second UL resource overlap in time, provided that a highest logical channel priority mapped to the first UL resource is different from a highest logical channel priority mapped to the second UL resource.

[0012] In some embodiments, the first threshold is based on a minimum time required by the WTRU to determine a priority of the first UL resource and a priority of the second UL resource. In some embodiments, the first threshold is based on a minimum time required by the WTRU to evaluate logical channel prioritization (LCP) restrictions for the first grant and for the second grant, and the processor is further configured to map the logical channel of the highest configured priority to the first grant and the second grant. In some embodiments, the second threshold is based on a minimum time required to perform a preemption procedure, and the processor is further configured to determine a priority for each UL resource based on grant processing at the physical layer. In some embodiments, the preemption procedure includes preempting the first transmission or the second transmission by the physical layer based on the prioritization of the first UL resource or the second UL resource. In some embodiments, designating either the first UL resource or the second UL resource as a prioritized UL resource includes performing logical channel prioritization (LCP), evaluating the highest priority logical channel mapped to the UL resource, and / or evaluating the logical channel that corresponds to (or triggered) the UL control information mapped to the UL resource. [Brief explanation of the drawings]

[0013] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate similar elements and in which: [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] 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communication system shown in FIG. 1A, according to an embodiment. [Figure 1C]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 shown in FIG. 1A, according to an embodiment. [Figure 1D] 1B is a system diagram illustrating another example RAN and another example CN that may be used within the communication system shown in FIG. 1A, according to an embodiment. [Figure 2] 10 is a signaling diagram illustrating an example case in which a WTRU prioritizes and / or selects between grants in a MAC. [Figure 3] 10 is a signaling diagram illustrating an example case in which a WTRU preempts an ongoing UL transmission. [Figure 4] 1 is a signaling diagram illustrating a physical uplink channel transmission from a WTRU on a first uplink resource overlapping in the time domain with a physical uplink channel transmission from a WTRU on a second uplink resource. [Figure 5] 1 is a flowchart illustrating an example method for addressing overlapping transmissions on different resources. [Figure 6] 6 is a flowchart further illustrating the example method of FIG. 5 for addressing overlapping transmissions on different resources. [Figure 7] 7 is a flowchart further illustrating the example method of FIGS. 5 and 6 for addressing overlapping transmissions on different resources. DETAILED DESCRIPTION OF THE INVENTION

[0014] 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 providing content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. The communication system 100 enables the multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tailed unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0015] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, mobile phones, PDAs, smartphones, laptops, netbooks, personal computers, wireless sensors, hotspot or Mi-Fi devices, IoT devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), 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 a UE.

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

[0017] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of the licensed and unlicensed spectrum. A cell may provide coverage for wireless services 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, one for each sector of the cell. In an embodiment, the base station 114a may use MIMO technology and 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.

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

[0019] More specifically, as noted above, the communication system 100 may be multiple-access and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a and the 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).

[0020] 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).

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

[0022] 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 jointly implement LTE radio access and NR radio access, e.g., using a dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may feature multiple types of radio access technologies and / or transmissions sent to or from multiple types of base stations (e.g., eNBs and gNBs).

[0023] 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.

[0024] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point and may utilize any suitable RAT for facilitating wireless connectivity within 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 roadway, 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 other embodiments, 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 through the CN 106 / 115.

[0025] The RAN 104 / 113 can communicate with the CN 106 / 115, which can 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 resilience requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 can provide call control, billing services, mobile location services, prepaid calls, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A , it will be understood that the RAN 104 / 113 and / or the CN 106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with other RANs (not shown) that use GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technologies.

[0026] The CNs 106 / 115 may also serve as gateways 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 TCP, UDP, and / or 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 other CNs connected to one or more RANs, which may use the same RAT as the RANs 104 / 113 or a different RAT.

[0027] 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 the base station 114a enabled with cellular-based wireless technology and with the base station 114b enabled with IEEE 802 wireless technology.

[0028] 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 GPS chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0029] 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 in association with a DSP core, a controller, a microcontroller, an ASIC, an 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 function 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. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic circuit package or chip.

[0030] 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, for example, an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In other embodiments, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0032] 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 over multiple RATs, such as NR and IEEE 802.11.

[0033] 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. Additionally, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include RAM, ROM, a hard disk, or any other type of memory storage device. The removable memory 132 may include a SIM card, a memory stick, an SD memory card, etc. 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 home computer (not shown).

[0034] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to other components within 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 batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

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

[0036] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a USB port, a vibration device, a television receiver / transmitter, 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, etc. The peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

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

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

[0040] 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 over an X2 interface.

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

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

[0043] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 through an S1 interface. The SGW 164 may generally route and forward user data packets to or 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 for the WTRUs 102a, 102b, 102c is available, and managing and storing the context of the WTRUs 102a, 102b, 102c.

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

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

[0046] 1A-1D are described as wireless terminals, it is contemplated that in some representative embodiments such terminals may use a wired communication interface with the communication network (e.g., temporarily or permanently). In a representative embodiment, the other network 112 may be a WLAN.

[0047] 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 an interface to a distribution system (DS) or other type of wired / wireless network that carries traffic to and / or from the BSS. Traffic to an STA originating from outside the BSS may arrive through the AP and be delivered to the STA. Traffic originating from an STA destined for a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs within the BSS may be sent through the AP; for example, a source STA may send traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source and destination STA via 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 in or using the IBSS (e.g., all of the STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0048] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a 20 MHz wide bandwidth) or a width that is dynamically set through signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In some representative embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented. For CSMA / CA, STAs (e.g., every STA), including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, the particular STA can back off. At any given time in a given BSS, one STA (e.g., only one station) can transmit.

[0049] High-throughput (HT) STAs may use, for example, a 40 MHz wide channel for communication through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0050] A very high throughput (VHT) STA may support channels of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz width. A 40 MHz and / or 80 MHz channel may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data may be passed through a segment parser that can split the data into two streams. Separate inverse fast Fourier transform (IFFT) processing and time-domain processing may be performed 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 medium access control (MAC).

[0051] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. In 802.11af and 802.11ah, the channel operating bandwidths and carriers are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include batteries with a battery life greater than a threshold (e.g., to maintain a very long battery life).

[0052] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all STAs in a BSS. The bandwidth of the primary channel can be set and / or limited by a STA from among all STAs operating in the BSS that supports the smallest bandwidth operating mode. In the example of 802.11ah, the primary channel can be 1 MHz wide for a STA (e.g., an MTC-type device) that supports (e.g., only supports) 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 can 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 if most of the frequency band remains idle and may be available for use.

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

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

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

[0056] The WTRUs 102a, 102b, 102c can 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 can communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., including different numbers of OFDM symbols and / or lasting for different lengths of absolute time).

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

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

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

[0060] 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, support for network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating 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 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 (URLLC) access, services relying on enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communications (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that use other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

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

[0062] The UPFs 184a, 184b are connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 through 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 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0063] The CN 115 facilitates communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. Additionally, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the 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.

[0064] 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 functionality.

[0065] The emulation device may be designed to perform one or more tests of other devices in a laboratory environment and / or an operator network environment. For example, one or more emulation devices may perform one or more, or all, functions while being implemented and / or deployed, in whole or in part, as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more, or all, functions while being 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 perform testing using over-the-air wireless communication.

[0066] The one or more emulation devices may perform one or more functions, inclusive, without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a test room and / or in a test scenario in a wired and / or wireless communication network that is not deployed (e.g., testing) to perform testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication through RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0067] An NR WTRU may be configured by RRC with first and second MCS tables, e.g., each table may be indicated as applicable for a transmission by a first and second Radio Network Temporary Identifier (RNTI), respectively, or by a Downlink Control Information (DCI) message within a first Physical Downlink Control Channel (PDCCH) Search Space (SS) (e.g., cell-common SS) or a second PDCCH SS (e.g., WTRU-specific SS).

[0068] For grant-based transmissions, the downlink control information (DCI) cyclic redundancy check (CRC) may be scrambled with an additional RNTI to indicate a new MCS table. In some implementations, the network can dynamically indicate a new MCS table even if a new RNTI is not configured, so that DCI sent in the user search space (USS) uses the new MCS table and DCI sent in the common search space (CSS) uses the existing MCS table. For configured grants, the RRC may provide the new RNTI portion of the configured grant resource configuration.

[0069] An NR WTRU may be configured with an additional RNTI having characteristics similar to those of the C-RNTI. For example, the new RNTI may also uniquely identify the WTRU. The new RNTI and the C-RNTI may each indicate one of multiple MCS tables to be used for transmissions scheduled by a DCI. Different MCS tables may correspond to different reliability and / or block error rate (BLER) targets. Alternatively, the WTRU may determine which MCS table to use for transmissions scheduled by a given DCI from the position of the DCI in the WTRU's PDCCH search space. For example, the WTRU may determine that a DCI received in a WTRU-specific search space (UESS) corresponds to the second MCS table, and a DCI received in a common search space (CSS) corresponds to the first (or default) MCS table. The WTRU may receive the second RNTI in the configuration of transmission resources for a configured grant.

[0070] In some implementations, a transport block (TB) is used for UL transmission. In LTE and NR, the network (e.g., an eNB or gNB) may grant radio resources to a WTRU for transmission on an UL shared channel (UL-SCH). The WTRU may receive such resource allocation in a grant received on a physical downlink control channel (PDCCH) or in a configured resource (e.g., a semi-persistently scheduled UL grant in LTE, or a Type 1 or Type 2 grant in NR). In some implementations, after receiving the resource allocation, the medium access control (hereinafter MAC) layer of the WTRU may provide a hybrid automatic repeat request (HARQ) entity (WTRU) with the necessary information for the UL transmission. This information may include one or more of a new data indication (NDI), a transmission unit, a redundancy version (RV), or a transmission duration. The NDI may indicate whether the uplink transmission should be a new transmission or a retransmission. The transmission unit (e.g., transport block (TB) size) may indicate the number of bits available for uplink transmission. The UL HARQ information provided by the MAC for UL transmission indicates the transmission time duration (TTI).

[0071] In a typical single-carrier system, there may be at most a single TB of a given transmission duration at any given time. The HARQ entity may identify the HARQ process for which transmission should occur. The HARQ entity may also provide HARQ feedback and a modulation and coding scheme (MCS) to the HARQ process.

[0072] The values ​​of the NDI, TB size, RV TTI, and MCS may be controlled by the network (e.g., eNB or gNB) and may be selected by the network to meet quality of service (QoS) requirements, such as packet delay budget (PDB), packet error loss rate (PELR), and / or corresponding radio block error rate (BLER) targets of different radio bearers established for the WTRU, for example, based on buffer status report (BSR) information, reported channel quality indication (CQI), and / or HARQ feedback received from the WTRU.

[0073] To assemble a MAC protocol data unit (PDU) for transmission, the WTRU may multiplex one or more MAC service data units (SDUs) from one or more logical channels (LCHs) onto a TB to be delivered to the physical layer on an appropriate transport channel. For such multiplexing, there may also be restrictions on the mapping between data from an LCH and a given TB. Example restrictions include restrictions based on one or more characteristics of the TB's transmission. Example characteristics may include the SCS, maximum PUSCH transmission duration (e.g., maximum TTI), type of configured grant (e.g., NR Type 1, Type 2), and / or the serving cell allowed for transmission of data for the LCH.

[0074] As discussed herein, a logical channel (LCH) may represent a logical association between data packets and / or PDUs. Such association may be based on data units associated with the same bearer. As discussed herein, a logical channel group (LCG) may include a group of LCHs (or equivalents according to the above definition), and such grouping may be based on one or more criteria. Exemplary grouping criteria may include, for example, that one or more LCHs in a group have a similar priority level as other LCHs in the same LCG, or are associated in some way with the same type of transmission (e.g., have the same SCS, duration, waveform, etc.).

[0075] In some implementations, logical channel prioritization (LCP) is used for UL transmission. LCP is a mechanism used to associate data available for transmission with resources available for UL transmission. Some implementations support multiplexing of different data with different QoS requirements within the same transport block. In some implementations, such multiplexing is supported if it does not introduce adverse impacts (e.g., in terms of latency or reliability) to services with the most stringent QoS requirements and / or does not introduce unnecessary waste of system resources (e.g., by introducing spectral inefficiencies by carrying high-reliability traffic on resources configured for best-effort traffic).

[0076] In some implementations, the WTRU assembles a MAC PDU to serve data from one or more LCHs (e.g., fills the TB for UL transmission) using the following principles: For example, in some implementations, the WTRU may perform LCP using up to two rounds of processing.

[0077] In the first round of an example LCP implementation (or, in other words, steps 1 and 2), data from one or more LCHs is served in order of decreasing priority up to a preferred bit rate (PBR). In other words, data may be served to an LCH up to, at most, the PBR. In some examples, the amount of data taken from an LCH for multiplexing to a TB in this round may be, at most, up to a value corresponding to the PBR, and the LCHs are served in order of decreasing priority.

[0078] The served data may exceed the available amount of data capacity for the LCH for transmission within a given TTI (i.e., the served data may exceed the "bucket" or traffic shaper for the amount of possible served data within a given TTI (e.g., envelope) that is typically used to avoid unnecessary RLC segmentation). In other words, some implementations allow more than the maximum amount of data to be served if, for example, doing so would help avoid the need for segmentation of a PDU or packet by the WTRU.

[0079] In round 2 (or alternatively expressed, step 3) of an example LCP implementation, data from the LCH is served in strict priority order to fill the remaining resources, which in some examples include any amount of data in excess of the PBR for the LCH.

[0080] In some implementations, for NR, the RRC controls the LCP procedure by configuring mapping restrictions for each logical channel. Example restrictions include restrictions that set the allowed subcarrier spacing for transmission (e.g., allowedSCS-List), restrictions that set the maximum PUSCH duration allowed for transmission (e.g., maxPUSCH-Duration), restrictions that set whether configured grant type 1 can be used for transmission (e.g., configuredGrantType1Allowed), and / or restrictions that set the cells allowed for transmission (e.g., allowedServingCells).

[0081] Some implementations provide flexible mapping restrictions through the use of transmission profiles (TPs). A TP is a mapping restriction that can be dynamically indicated or configured per grant. From the network perspective, the TP may correspond to a scheduling policy associated with the transmission of a TB. From the WTRU MAC perspective, for a new transmission, the MAC may use the TP indicated by the gNB for a given UL grant to determine which LCH to evaluate when building a transport block. The mapping procedure may be performed by the WTRU without requiring information about the grant's underlying PHY layer characteristics and the scheduling policy from the gNB. In some implementations, the TP allows the scheduler to more flexibly and dynamically control the LCP logic. For example, in some implementations, the TP allows the gNB to allocate a specific set of resources (e.g., with a specific numerology, transmission duration, or a combination of both) to a specific LCH (or LCG) (e.g., to a specific type of data traffic) so that a specific treatment can be applied to the physical layer transmission in terms of latency, reliability, and / or QoS characteristics. In some implementations, the MAC entity multiplexes only data from an LCH configured with a TP value that matches the value associated with the UL grant.

[0082] In some implementations, the WTRU physical layer may determine the applicable TP. The determination may be made, for example, based on reception of dynamic signaling on the PDCCH indicating the applicable TP for the transmission (or, in some embodiments, the applicable LCH or LCG), or based on the values ​​applicable to the grant in terms of mapping restrictions. The WTRU may pass this information (e.g., as part of the grant information) to the MAC layer (e.g., for the LCP). If the WTRU is also configured with at least one TP value per configured LCH, either explicitly (e.g., a TP value between 0 and 3) or otherwise with a default value for TP (e.g., TP=0), by association with one or more values ​​for the configured mapping restrictions (e.g., allowedSCS value 0 and allowedServingCells value 0 corresponding to a particular TP value, or the like), the WTRU may determine what data from which LCH is appropriate for multiplexing in a given TB.

[0083] In some implementations, such flexible mapping restrictions can have the advantage of allowing the scheduler to prioritize services differently for issued UL grants, for example depending on numerology / TTI duration.

[0084] The introduction of a new RNTI (e.g., new-RNTI, MCS-C-RNTI, etc.) allows for dynamic selection of an MCS table to achieve a particular level of reliability. However, functionality at the MAC sublayer does not currently allow for differentiated handling of traffic based on a desired reliability level. Various examples discussed herein discuss an exemplary new RNTI, such as new-RNTI, MCS-C-RNTI, a second C-RNTI, or other notation of multiple RNTIs. Note that this terminology is exemplary and that the techniques discussed herein are generally applicable to multiple RNTI scenarios. For example, as discussed herein, the functionality of the C-RNTI and MCS-C-RNTI is similar except for their correspondence to different MCS tables.

[0085] Some embodiments relate to the impact of additional RNTIs on the MAC. Some such impacts may relate to random access. For example, the WTRU may be configured with a maximum number of preamble transmissions, a backoff value, and a power ramping step value for each configured MCS table and / or C-RNTI value. If the WTRU determines that random access is uniquely associated with at most one MCS table and / or C-RNTI value and that the WTRU's configuration for the serving cell from which the preamble is transmitted includes more than one RNTI value for C-RNTI, the WTRU may determine the maximum number of preamble transmissions for the procedure depending on the RNTI value. This may be useful, for example, when the random access procedure is initiated depending on the QoS requirements (e.g., latency) of the service (e.g., URLLC or eMBB) to dynamically determine the maximum number of attempts before initiating a recovery procedure if the random access procedure is not successfully completed. The determined maximum number of attempts may be a function of logical channel (LCH) mapping restrictions, data and / or the LCH that may have triggered the random access, and / or the C-RNTI of the DCI that triggered the random access (e.g., by a PDCCH command). The QoS used to determine the RA parameters may be determined from the C-RNTI used to scramble the PDCCH that ordered the RA (i.e., a contention-free RA by a PDCCH command). In some cases, the WTRU may be configured with beam failure recovery related parameters, or with an MCS table and / or one value of the beam failure recovery related parameters per C-RNTI value. Such parameters may include any one or more of the following: - A maximum count for beam failure detection, which may be referred to herein as beamFailureInstanceMaxCount, for example. - A timer for beam failure detection, which is called, for example, beamFailureDetectionTimer in this document. - RSRP threshold for beam failure recovery, which is referred to as beamFailureCandidateBeamThreshold in this specification. - A preamble power ramping step for beam failure recovery, which is referred to as preamblePowerRampingStep, for example, in this specification. - Preamble received target power for beam obstruction recovery, which is referred to as preambleReceivedTargetPower in this specification, for example. - Maximum preamble transmission value for beam obstruction recovery, which is referred to as preambleTxMax, for example, in this specification. A time window for monitoring a response to a beam failure recovery using a contention-free random access preamble, which is referred to as ra-ResponseWindow, for example, in this specification.

[0086] The WTRU may be configured with one or more beam failure recovery configurations for each configured MCS table and / or C-RNTI value. These failure recovery configurations are referred to herein as BeamFailureRecoveryConfig, for example. Differentiated parameters based on the RNTI value may be used to dynamically adapt between different sets of parameters for the beam failure recovery procedure (e.g., depending on the expected speed and / or reliability of recovery). For example, the WTRU may select a BeamFailureRecoveryConfig associated with the MCS table used to transmit a beam failure recovery request, or the WTRU may select a BeamFailureRecoveryConfig associated with high reliability if it is configured with a second C-RNTI.

[0087] For beam failure recovery (BFR), the WTRU may perform contention-free random access (CFRA) by transmitting a preamble and, after transmitting the preamble, monitoring the PDCCH of the serving cell (e.g., a primary cell (PCell) of a master cell group (MCG) or a special cell (SpCell) such as a secondary cell group (SCG)) for a response to the BFR request identified by the C-RNTI. If the WTRU is configured with more than one C-RNTI value (e.g., more than one value per serving cell), the WTRU may monitor the C-RNTI using the RNTI value configured for the transmission addressed to the C-RNTI, or the WTRU may monitor the C-RNTI using a single RNTI value.

[0088] If the WTRU monitors C-RNTI using all configured RNTI values ​​for transmissions addressed to the C-RNTI, the WTRU may consider the random access procedure for BFR successful if it receives a PDCCH transmission addressed to the C-RNTI using any value before the ra-ResponseWindow configured in BeamFailureRecoveryConfig expires. Otherwise, the WTRU may consider the random access reception unsuccessful. In some cases, the WTRU may determine additional information depending on the RNTI value of C-RNTI. For example, the WTRU may determine a first aspect if DCI on the PDCCH is received using a first RNTI value. In another example, the WTRU may determine a second aspect if DCI on the PDCCH is received using a second RNTI value.

[0089] In cases where the WTRU monitors the C-RNTI using a single RNTI value, the WTRU may use the single value applicable to the BFR procedure. Such a value may correspond to a default MCS table (e.g., corresponding to an eMBB service) or another MCS table (e.g., corresponding to a URLLC service). In some cases, which value the WTRU monitors may be a WTRU configuration aspect. In some cases, the WTRU may consider the random access procedure for BFR successful if it receives a PDCCH transmission addressed to the applicable C-RNTI value before the ra-ResponseWindow configured in BeamFailureRecoveryConfig expires; otherwise, the WTRU may consider the random access reception unsuccessful. In some cases, the WTRU may receive a PDCCH transmission addressed with a configured RNTI value other than the RNTI value applicable to the ongoing BFR procedure for C-RNTI. The WTRU may determine that the corresponding beam can no longer be used, may stop using the corresponding beam, and may initiate establishment of a different beam. In this case, the WTRU may consider the random access procedure to be complete and successful, e.g., in this case, the WTRU may not transmit any further preambles for the current instance of the procedure and / or may not indicate any radio link problems to upper layers, and the WTRU may determine that beam failure recovery is complete.

[0090] For general contention-based random access (including when it is used for BFR), if the WTRU is configured with more than one value for C-RNTI (e.g., more than one value per serving cell), the WTRU may determine that contention resolution is successful if it receives a C-RNTI with any configured RNTI value while the ra-ContentionResolutionTimer is running, or the WTRU may determine that contention resolution is successful if it receives a C-RNTI with one particular RNTI value while the ra-ContentionResolutionTimer is running.

[0091] In some cases where the WTRU determines that contention resolution is successful if it receives a C-RNTI with any RNTI value while the ra-ContentionResolutionTimer is running, the WTRU may determine that contention resolution is successful only if the WTRU did not include a C-RNTI MAC CE in Msg3 for the applicable procedure; otherwise, the WTRU may consider the random access reception to be unsuccessful. In such cases, the WTRU may determine additional information depending on the RNTI value of the C-RNTI. For example, the WTRU may determine a first aspect if DCI on the PDCCH is received with a first RNTI value, or the WTRU may determine a second aspect if DCI on the PDCCH is received with a second RNTI value, or both.

[0092] In some cases where the WTRU determines that contention resolution is successful if it receives a C-RNTI with one particular RNTI value while the ra-ContentionResolutionTimer is running, the WTRU may use a single applicable value for contention resolution for the contention-based random access procedure. Such a value may correspond to a default MCS table (e.g., corresponding to an eMBB service) or another MCS table (e.g., corresponding to a URLLC service). In some cases, the value that the WTRU monitors may be a WTRU configuration aspect. In some cases, the value may correspond to the RNTI included in the C-RNTI MAC CE if it was included in Message 3 (Msg3) of the random access procedure. For example, if a CBRA procedure (RA-SR) is initiated following a trigger for a scheduling request (SR), the WTRU may include in the C-RNTI MAC CE the RNTI value depending on the data that triggered the SR. For example, the LCH may be configured such that it is associated with an MCS table (or more generally for a TP) as part of the LCH mapping restriction. In such a case, the WTRU may, for example, include the RNTI value corresponding to the associated MCS table in the C-RNTI MAC CE if the MCS table is itself associated with a particular RNTI value. The WTRU may then perform contention resolution using the RNTI value included in the C-RNTI MAC CE.

[0093] In some cases where the WTRU determines that contention resolution is successful if it receives a C-RNTI with one particular RNTI value while the ra-ContentionResolutionTimer is running, the WTRU may consider contention resolution for random access successful when it receives a PDCCH transmission addressed to the applicable C-RNTI value before the ra-ContentionResolutionTimer expires; otherwise, the WTRU may consider contention resolution unsuccessful. For BFR, the WTRU may receive a PDCCH transmission addressed with a configured RNTI value other than the RNTI value applicable to the ongoing BFR procedure for C-RNTI, and the WTRU may determine that contention resolution was unsuccessful. In this case, the WTRU may determine that the random access procedure for BFR was unsuccessful when the ra-ContentionResolutionTimer expires.

[0094] In some cases, the WTRU may ignore a PDCCH received with a configured RNTI value other than an RNTI value applicable to the ongoing BFR procedure for C-RNTI. In some cases, the WTRU may receive a PDCCH transmission addressed with a configured RNTI value other than an RNTI value applicable to the ongoing BFR procedure for C-RNTI. In some cases, the WTRU may determine that contention resolution was unsuccessful. In some cases, the WTRU may ignore a PDCCH received with a configured RNTI value other than an RNTI value applicable to the ongoing random access procedure for C-RNTI. In some cases, the temporary C-RNTI received in the RAR message always corresponds to the RNTI value associated with the default MCS table.

[0095] For the MAC C-RNTI CE, in some examples, if the WTRU is configured with more than one value for C-RNTI (e.g., more than one value per serving cell), the WTRU shall include in the C-RNTI MAC CE (e.g., for Msg3 of the random access procedure) an RNTI value for C-RNTI that corresponds to at least one of the following four values: First, the RNTI value included may correspond to a default RNTI value, e.g., a default MCS table. Second, the RNTI value included may correspond to the C-RNTI value for which the WTRU successfully decoded the DCI that instructs the WTRU to initiate the random access procedure (e.g., the C-RNTI of the DCI received for the PDCCH command to perform the random access procedure). Third, the RNTI value included may be selected depending on the trigger for the random access procedure. For example, for RA-SR (e.g., triggered by data becoming available for transmission), the RNTI value may correspond to the LCH of the data that triggered the RA-SR depending on the LCH restriction. Such an LCH restriction may include an MCS value or an associated MCS table. In such a case, the WTRU may include an RNTI value that corresponds to the associated MCS table for the LCH restriction in the C-RNTI MAC CE (e.g., if the MCS table is itself associated with a particular RNTI value). Fourth, for formats that support one or more RNTI values, similar to the previous example regarding the LCH that led to the initiation of the random access procedure, for formats that support one or more RNTI values, the included RNTI value may correspond to the LCH for which there is data available for transmission.

[0096] Some embodiments relate to HARQ operation. For example, if a WTRU is configured with more than one value for C-RNTI per serving cell, the WTRU may be configured with one value per C-RNTI for one or more parameters associated with a HARQ entity. Such parameters may include, for example, the maximum number of HARQ retransmissions for a HARQ process and / or for a transport block.

[0097] A WTRU configured with more than one value for C-RNTI per serving cell may receive a DCI on the PDCCH for one of the C-RNTIs of the MAC entity for the serving cell (e.g., the DCI is at least partially scrambled by the C-RNTI). In some embodiments, the WTRU may consider the New Data Indicator (NDI) to be toggled for the HARQ process indicated in the DCI (e.g., the DCI indicates the transmission of a new transport block) if, for example, the DCI schedules a HARQ process (e.g., based on HARQ process identification information) that was last scheduled with a different C-RNTI value; if the DCI schedules a HARQ process (e.g., based on HARQ process identification information) that was last scheduled with a different C-RNTI value, but the MCS or MCS table for the retransmission indicates that this process is not associated with this HARQ process. the DCI schedules the last scheduled HARQ process (e.g., based on the HARQ process identification information) with a different C-RNTI value, but the parameters of the transmission (e.g., MCS or MCS table) do not match the LCH limit of the data associated with the last transmission for this HARQ process; the DCI schedules the last scheduled HARQ process (e.g., based on the HARQ process identification information) with the same C-RNTI value, but the scheduled transport block size is different from the size last scheduled for this HARQ process; or the NDI flag in the DCI indicates that NDI is toggled.

[0098] In some examples, the downlink allocation received on the PDCCH indicates that there is a DL-SCH transmission for a particular MAC entity, and also provides relevant HARQ information. When a MAC entity has a C-RNTI, MCS-C-RNTI, temporary C-RNTI, or CS-RNTI, the MAC entity shall, for each PDCCH opportunity during which it monitors the PDCCH, and for each serving cell, determine whether the downlink allocation for this PDCCH opportunity and this serving cell is equal to the MAC entity's C-RNTI, MCS-C-RNTI, or temporary C-RNTI. If received on the PDCCH for RNTI: indicates the presence of a downlink allocation and delivers the associated HARQ information to the HARQ entity; if this is the first downlink allocation for this temporary C-RNTI: NDI is considered to be toggled; if the downlink allocation is for the C-RNTI of the MAC entity and the previous downlink allocation indicated to the HARQ entity of the same HARQ process was either a downlink allocation received for the CS-RNTI or MCS-C-RNTI of the MAC entity or a configured downlink allocation: NDI is considered to be toggled regardless of the value of NDI; if the downlink allocation is for the MCS-C-RNTI of the MAC entity and the previous downlink allocation indicated to the HARQ entity of the same HARQ process was either a downlink allocation received for the CS-RNTI or C-RNTI of the MAC entity or a configured downlink allocation: NDI is considered to be toggled regardless of the value of NDI.

[0099] In some examples, uplink grants are dynamically received on the PDCCH in a random access response or semi-persistently configured by RRC. The MAC entity shall have an uplink grant to transmit on the UL-SCH. To make the requested transmission, the MAC layer receives HARQ information from lower layers. If the MAC entity has a C-RNTI, a temporary C-RNTI, an MCS-C-RNTI, or a CS-RNTI, the MAC entity shall, for each PDCCH opportunity, and for each serving cell belonging to a TAG with an active timeAlignmentTimer, and for each grant received for this PDCCH opportunity: If an uplink grant for this serving cell is received on the PDCCH for the MAC entity's C-RNTI, MCS-C-RNTI, or temporary C-RNTI, or if an uplink grant is received in a random access response: deliver the uplink grant and associated HARQ information to the HARQ entity; If the uplink grant is for the CS-RNTI or MCS-C-RNTI of the MAC entity and the previous uplink grant delivered to the HARQ entity for the same HARQ process was a received or configured uplink grant for the CS-RNTI or MCS-C-RNTI of the MAC entity, or if the uplink grant is for the MCS-C-RNTI of the MAC entity and the previous uplink grant delivered to the HARQ entity for the same HARQ process was a received or configured uplink grant for the CS-RNTI or C-RNTI of the MAC entity: NDI is considered to be toggled for the corresponding HARQ process regardless of the value of NDI.If the uplink grant is for the C-RNTI or MCS-C-RNTI of the MAC entity and the identified HARQ process is configured for the configured uplink grant: If configured, start or restart the configuredGrantTimer for the corresponding HARQ process.

[0100] In some examples, the downlink allocation received on the PDCCH indicates that there is a DL-SCH transmission for a particular MAC entity, and also provides relevant HARQ information. When a MAC entity has a C-RNTI, MCS-C-RNTI, temporary C-RNTI, or CS-RNTI, the MAC entity shall, for each PDCCH opportunity during which it monitors the PDCCH, and for each serving cell, determine whether the downlink allocation for this PDCCH opportunity and this serving cell is equal to the MAC entity's C-RNTI, MCS-C-RNTI, or temporary C-RNTI. When received on the PDCCH for a temporary C-RNTI: indicates the presence of a downlink allocation and delivers the associated HARQ information to the HARQ entity; if this is the first downlink allocation for this temporary C-RNTI, NDI is considered to be toggled; if the downlink allocation is for the C-RNTI of the MAC entity and the previous downlink allocation indicated to the HARQ entity of the same HARQ process was a downlink allocation received or configured for the CS-RNTI or MCS-C-RNTI of the MAC entity, or if the downlink allocation is for the C-RNTI or MCS-C-RNTI of the MAC entity and the previous downlink allocation indicated to the HARQ entity of the same HARQ process was a downlink allocation for a transmission using a different MCS table: NDI is considered to be toggled regardless of the value of NDI.

[0101] In some examples, uplink grants are dynamically received on the PDCCH in a random access response or semi-persistently configured by RRC. The MAC entity shall have an uplink grant to transmit on the UL-SCH. To make the requested transmission, the MAC layer receives HARQ information from lower layers. If the MAC entity has a C-RNTI, a temporary C-RNTI, an MCS-C-RNTI, or a CS-RNTI, the MAC entity shall, for each PDCCH opportunity, and for each serving cell belonging to a TAG with an active timeAlignmentTimer, and for each grant received for this PDCCH opportunity: If an uplink grant for this serving cell is received on the PDCCH for the MAC entity's C-RNTI, MCS-C-RNTI, or temporary C-RNTI, or if an uplink grant is received in a random access response: Deliver the uplink grant and associated HARQ information to the HARQ entity; If the uplink grant is for the C-RNTI of the MAC entity, and the previous uplink grant delivered to the HARQ entity for the same HARQ process was an uplink grant received or configured for the CS-RNTI or MCS-C-RNTI of the MAC entity, or if the uplink grant is for the MCS-C-RNTI of the MAC entity, and the previous uplink grant delivered to the HARQ entity for the same HARQ process was an uplink grant for a transmission using a different MCS table: NDI is considered to be toggled for the corresponding HARQ process regardless of the value of NDI. If the uplink grant is for the C-RNTI or MCS-C-RNTI of the MAC entity, and the identified HARQ process is configured for a configured uplink grant: If configured, start or restart the configuredGrantTimer for the corresponding HARQ process.

[0102] A WTRU configured with more than one value for C-RNTI per serving cell may receive DCI on the PDCCH for one of the C-RNTIs of the MAC entity for the serving cell (e.g., the DCI is at least partially scrambled by the C-RNTI). In some examples, the WTRU may consider the NDI to be not toggled for the HARQ process indicated in the DCI (e.g., the DCI indicates a retransmission in a transport block) if the DCI includes a downlink assignment or an UL grant, for example, according to at least one of the following: the DCI schedules the last scheduled HARQ process (e.g., based on the HARQ process identification information) with a different C-RNTI value and the transport block size is the same size as that last scheduled for this HARQ process; the DCI schedules the last scheduled HARQ process (e.g., based on the HARQ process identification information) with a different C-RNTI value and the transport block size is the same size as that last scheduled for this HARQ process and the MCS or MCS table is the same as that last scheduled for this HARQ process; or the NDI flag in the DCI indicates that the NDI is not toggled.

[0103] A WTRU configured with more than one value for C-RNTI per serving cell may receive DCI on the PDCCH for one of the C-RNTIs of the MAC entity for the serving cell (e.g., the DCI is at least partially scrambled by the C-RNTI). In some embodiments, the WTRU may determine that a DCI should be discarded (e.g., the WTRU does not transmit on an UL grant received on the DCI and / or receive on a DL assignment received on the DCI), for example, if it determines at least one of the following: the DCI schedules the last scheduled HARQ process (e.g., based on the HARQ process identification) with a different C-RNTI value; the DCI schedules the last scheduled HARQ process (e.g., based on the HARQ process identification) with a different C-RNTI value and the transport block size is different from the size last scheduled for this HARQ process; or the DCI schedules the last scheduled HARQ process (e.g., based on the HARQ process identification) with a different C-RNTI value and the NDI field in the DCI indicates that NDI is not toggled. This case may correspond to an unexpected case, for example, a network error or a PDCCH false positive detection.

[0104] In some examples, the downlink allocation received on the PDCCH indicates that there is a DL-SCH transmission for a particular MAC entity, and also provides relevant HARQ information. When a MAC entity has a C-RNTI, MCS-C-RNTI, temporary C-RNTI, or CS-RNTI, the MAC entity shall, for each PDCCH opportunity during which it monitors the PDCCH, and for each serving cell, determine whether the downlink allocation for this PDCCH opportunity and this serving cell is equal to the MAC entity's C-RNTI, MCS-C-RNTI, or temporary C-RNTI. If received on the PDCCH for RNTI: If this is the first downlink allocation for this temporary C-RNTI: NDI is considered to be toggled; if the downlink allocation is for the C-RNTI or MCS-C-RNTI of the MAC entity and the previous downlink allocation indicated to the HARQ entity of the same HARQ process was a downlink allocation received for the CS-RNTI of the MAC entity or a configured downlink allocation: NDI is considered to be toggled regardless of the value of NDI; if the downlink allocation is for the C-RNTI of the MAC entity If, and a previous downlink allocation indicated to the HARQ entity of the same HARQ process was received for the MCS-C-RNTI of the MAC entity and NDI is not toggled, or if the downlink allocation is for the C-RNTI of the MAC entity and a previous downlink allocation indicated to the HARQ entity of the same HARQ process was received for the MCS-C-RNTI of the MAC entity and NDI is not toggled: ignore the downlink allocation; otherwise: indicate the presence of a downlink allocation and deliver the associated HARQ information to the HARQ entity.

[0105] In some examples, the uplink grant is dynamically received on the PDCCH in a random access response or semi-persistently configured by RRC. The MAC entity shall have an uplink grant to transmit on the UL-SCH. To make the requested transmission, the MAC layer receives HARQ information from lower layers. If the MAC entity has a C-RNTI, a temporary C-RNTI, an MCS-C-RNTI, or a CS-RNTI, the MAC entity shall, for each PDCCH opportunity, and for each serving cell belonging to a TAG with a running timeAlignmentTimer, and for each grant received for this PDCCH opportunity: if an uplink grant for this serving cell is received on the PDCCH for the MAC entity's C-RNTI, MCS-C-RNTI, or temporary C-RNTI, or if an uplink grant is received in a random access response: if the uplink grant is for the MAC entity's C-RNTI or MCS-C-RNTI, and if the previous uplink grant delivered to the HARQ entity for the same HARQ process was an uplink grant received or configured for the MAC entity's CS-RNTI: the MAC entity shall consider NDI to be toggled for the corresponding HARQ process regardless of the value of NDI.If the uplink grant is for the C-RNTI or MCS-C-RNTI of the MAC entity and the identified HARQ process is the one configured for the configured uplink grant: if configured, start or restart the configuredGrantTimer for the corresponding HARQ process; if the uplink grant is for the C-RNTI of the MAC entity and the previous uplink grant delivered to the HARQ entity of the same HARQ process was received on the MCS-C-RNTI of the MAC entity and NDI is not toggled, or if the uplink grant is for the MCS-C-RNTI of the MAC entity and the previous uplink grant delivered to the HARQ entity of the same HARQ process was received on the C-RNTI of the MAC entity and NDI is not toggled: ignore the uplink grant; otherwise: deliver the uplink grant and associated HARQ information to the HARQ entity.

[0106] Some embodiments relate to logical channel prioritization. For example, in some embodiments, the RRC may control the LCP procedure by configuring one or more mapping restrictions for each logical channel. The mapping restrictions may be indicated, for example, by a parameter configured for each logical channel representing an MCS table or by a parameter indicating an RNTI value for a C-RNTI. These example parameters are referred to herein as allowedMCS-Table and allowedRNTI-value, respectively. In some embodiments, the WTRU may multiplex data scheduled with a particular MCS table and / or with a particular RNTI into a transport block only if the LCH is configured with a mapping restriction that allows the data to be transmitted with the same value or with a value within a range of allowed values.

[0107] In some embodiments, mapping restrictions, such as maximum PUSCH duration or allowed subcarrier spacing, may depend on the type of MCS table indicated by the grant or the type of RNTI (e.g., C-RNTI or new-RNTI) used for the grant. For example, the maximum PUSCH duration may be configured to a first (e.g., higher) value for a first type of MCS table optimized for high reliability and to a second (e.g., lower) value for a second type of MCS table not optimized for high reliability. This approach may exploit efficiencies by reducing the likelihood that retransmissions will be needed when an MCS table optimized for high reliability is indicated.

[0108] In some embodiments, the WTRU may adapt the applicability of the configured LCP mapping restrictions according to the applicable HARQ process IDs. The WTRU may be configured by RRC with some HARQ process IDs as exempt from all or a subset of the LCP restrictions. The WTRU may be configured by RRC with some LCHs as exempt from restrictions only on the exempted HARQ process IDs. The WTRU may not apply all or a subset of the restrictions configured for the LCHs when constructing a TB for an UL grant for which a HARQ process ID is configured by RRC to be exempt from LCP restrictions. For example, the WTRU may receive an UL grant using a HARQ process ID configured as exempt from a subset of the LCP LCH selection restrictions. The WTRU may construct a TB for an UL grant for a new transmission taking into account all LCHs with buffered data, or all LCHs not configured with restrictions, or LCHs configured as exempt from restrictions on exempt HARQ process IDs.

[0109] In some embodiments, the WTRU may receive a dynamic indication from the gNB to suspend or resume application of some configured LCP restrictions. The WTRU may receive an LCP restriction applicability indication from the network and do one of the following: suspend the configured restrictions, apply new restrictions, or resume application of the configured restrictions. The WTRU may receive the applicability indication through explicit signaling or indication. For example, the WTRU may receive the applicability indication over DCI or MAC CE signaling. In other examples, the WTRU may determine the applicability indication from the content of the UL HARQ information, QoS flow markers, and / or protocol subheaders. The indication may be applicable only to a single packet, TB, or HARQ PID transmission.

[0110] The WTRU may implicitly determine the applicability indication from examples from the PDCCH resources (e.g., core set and / or search space), characteristics of the PDCCH resources (e.g., periodicity, monitoring pattern, duration, C-RNTI, and / or scrambling type), or characteristics of the DL transmission corresponding to the UL transmission (e.g., reflected QoS indicator and / or QFI). In one example, the WTRU may be identified or configured by the RRC with a certain C-RNTI as being exempt from restrictions, such that UL grants scheduled on a DCI and / or PDCCH scrambled with such a C-RNTI may be considered by the WTRU as being exempt from the LCP restriction or a subset of the LCP restriction; the WTRU may not apply the LCP restriction (or a subset of the restriction) configured for the LCH when constructing a TB for an UL grant scheduled on a PDCCH scrambled with an exempt C-RNTI. In another example, the WTRU may be identified or configured by the RRC with some core set and / or search space as being exempt from LCP restrictions, such that UL grants scheduled on such PDCCH resources are viewed by the WTRU as being exempt from all or a subset of the LCP restrictions, and the WTRU may not apply the LCP restriction (or a subset of the restrictions) configured for the LCH when constructing a TB for UL grants scheduled on PDCCHs scrambled with C-RNTIs designated as being exempt from LCP restrictions.

[0111] The applicability indication may also indicate (or be applicable as pre-configured) "indicated criteria" for which the LCP restriction suspension or resumption is applicable. The indicated criteria may include at least one of the following: (a) Logical Channel: For example, the applicability indication may provide an indication for an LCH or group of LCHs for which the restriction suspension or resumption is applicable. For example, the WTRU may suspend configured restrictions for a given LCH or LCG upon receiving the indication. In one implementation, the WTRU may be configured by RRC with some LCHs to be exempt from LCP restrictions upon receiving the applicability indication; (b) LCP Restrictions: For example, the applicability indication may provide an indication for LCP restrictions for which the suspension or resumption is applicable. For example, the WTRU may suspend a subset of LCP LCH selection restrictions (e.g., numerology, TTI duration restrictions, and / or configured grant type 1) upon receiving the indication. The indication may provide which restrictions are suspended. In one implementation, the WTRU may be configured by the RRC with some LCP restrictions to be exempted from application in the LCP procedure upon receiving the applicability indication; (c) resource type or index: the WTRU suspends the configured restrictions on a resource type (e.g., configured grant type 1, type 2, and / or dynamic grant) upon receiving the applicability indication. For example, the WTRU may suspend the configured restrictions on a given UL resource (or UL resource index) upon receiving the indication. The UL resource may be indicated by the applicability indication or may be pre-configured by higher layers.For example, the WTRU may be configured by the RRC with several UL resource types or resource indices; the WTRU may suspend the configured restrictions on such UL resources upon receiving the indication; (d) HARQ process ID: The WTRU may suspend or resume the configured restrictions on TBs established for uplink transmissions for HARQ process IDs indicated by the applicability indication or pre-configured to be exempt upon receiving the indication. In one example, the WTRU may be configured by the RRC with several HARQ process IDs as exempt from LCP restrictions upon receiving the indication. The WTRU may suspend the configured restrictions on a given UL resource upon receiving the indication if the determined HARQ process ID was configured by the RRC as exempt. The WTRU may determine the HARQ process ID directly from the signaled UL HARQ information and / or from the selected resource (e.g., based on the resource type and TTI); (e) transport block size. For example, the WTRU may suspend LCP restrictions when the TBS is below (or above) a certain threshold configured by the RRC or indicated to the WTRU; (f) QoS parameters. For example, the WTRU may suspend or apply certain configured restrictions when the highest priority LCH mapped to a grant is above or below a certain threshold. In another example, the WTRU may suspend configured restrictions when data from certain QoS flows or DRBs is buffered.

[0112] The WTRU may be configured with a pause timer. When the pause timer is running, the WTRU does not apply the LCP restriction (or the LCP restriction for the indicated criteria). As soon as the timer expires, the WTRU reapplies the configured LCP restriction. The WTRU may start the pause timer as soon as it receives an LCP restriction applicability indication indicating the suspension of the LCP restriction. The timer may affect the suspension of the LCP restriction for the indicated criteria if the timer was started by receiving an LCP restriction applicability indication. The WTRU may start the pause timer as soon as it receives a new packet, SDU, and / or buffered data from a higher layer from a configured set of DRBs, LCHs, and / or QoS flows. The WTRU may start the timer as soon as it sends (or triggers) an SR and / or SR configuration associated with a configured set of LCHs. The WTRU may start the timer as soon as it triggers a BSR from a configured set of LCHs. The WTRU may start the timer as soon as it triggers an SR due to data arrival and the WTRU not having available resources that match the configured LCP limit for the LCH that triggered the corresponding BSR. The pause timer may be configured by RRC per WTRU, LCH, LCG, DRB, QoS flow, and / or uplink resource.

[0113] The WTRU may be configured with a restriction applicability timer. When the restriction applicability timer is running, the WTRU applies the configured LCP restriction (or the LCP restriction for the indicated criteria). Upon expiration, the WTRU does not apply the configured LCP restriction (or the LCP restriction for the indicated criteria). The WTRU may start the restriction applicability timer upon receiving an LCP restriction applicability indication, which indicates the resumption of an LCP restriction or the addition of a new LCP restriction. The timer may affect the applicability of the LCP restriction for the indicated criteria if the timer was started by receiving an LCP restriction applicability indication. The WTRU starts the restriction applicability timer upon receiving a new packet, SDU, and / or buffered data from a higher layer from a configured set of DRBs, LCHs, and / or QoS flows. The WTRU may start the timer upon sending (or triggering) an SR and / or SR configuration associated with a configured set of LCHs. The WTRU may start the timer upon triggering a BSR from a configured set of LCHs. The limit applicability timer may be configured by the RRC per WTRU, LCH, LCG, DRB, QoS flow, and / or uplink resource.

[0114] Some embodiments relate to radio link failure. For example, a WTRU may be configured with two or more values ​​for C-RNTI per serving cell. The WTRU may be configured to perform different radio link recovery procedures depending on the C-RNTI value used for scheduling. For example, if a signal transmission (e.g., data on a PUSCH, a preamble transmission) associated with a particular C-RNTI value leads to the initiation of a recovery procedure, a specific radio link recovery procedure associated with that C-RNTI may be performed. In some examples, the WTRU may determine the radio link recovery procedure to perform depending on the RNTI value associated with an ongoing HARQ process (e.g., an HARQ process for which the last transmission has not been acknowledged). For example, a radio link problem may be detected from repeated failures (e.g., indicated by NACK reception) of transmissions of transport blocks associated with a first MCS table and / or RNTI value for C-RNTI. In some embodiments, the WTRU may determine whether to initiate an RRC connection re-establishment procedure if the transmission that caused the radio link failure (RLF) was scheduled using a particular RNTI. The WTRU may determine that if the HARQ process (or the last transmission of the HARQ process) is scheduled with a first RNTI value (e.g., corresponding to an eMBB service), it should initiate an RRC connection re-establishment procedure, or otherwise (e.g., for a URLLC service) initiate a conditional handover (e.g., by applying a pre-configured reconfiguration).

[0115] Some approaches relate to UL / DL allocation. For example, with respect to downlink allocation reception, the WTRU may monitor the PDCCH for each cell if it is configured with a second C-RNTI (e.g., also referred to as MCS-C-RNTI) to receive downlink allocation. Note that the term MCS-C-RNTI may be used synonymously with the term new-RNTI.

[0116] In some embodiments, after receiving a downlink assignment, the WTRU may consider the NDI to be toggled regardless of the value indicated in the signaled NDI if at least one of the following occurs: the WTRU receives a downlink assignment for its MCS-C-RNTI and the previous downlink assignment indicated that the same HARQ process was for a different RNTI than the WTRU was configured with; the WTRU receives a downlink assignment for its MCS-C-RNTI and the previous downlink assignment indicated the same HARQ process for the configured downlink assignment; or the WTRU receives a downlink assignment for its C-RNTI and the previous downlink assignment indicated that the same HARQ process was for the WTRU's MCS-C-RNTI.

[0117] The WTRU may also, or alternatively, determine whether to toggle NDI based on whether the received downlink assignment overlaps with a previously received downlink assignment. The WTRU may also, or alternatively, determine whether to toggle NDI based on physical layer transmission characteristics of the current and previously received downlink assignments, including PDSCH duration, numerology, and / or BLER for the indicated MCS.

[0118] For uplink grant reception, the WTRU may monitor the PDCCH for each cell if it is configured with an MCS-C-RNTI to receive uplink grants. In some examples, after receiving an uplink grant, the WTRU may toggle the NDI regardless of the value indicated in the signaled NDI if one or more of the following occurs: the WTRU receives an uplink grant for its MCS-C-RNTI and the previous uplink grant indicated the same HARQ process for a different RNTI than the WTRU is configured with; the WTRU receives an uplink grant for its MCS-C-RNTI and the previous uplink grant indicated the same HARQ process as for the configured uplink grant; or the WTRU receives an uplink grant for its C-RNTI and the previous uplink grant indicated the same HARQ process for the WTRU's MCS-C-RNTI.

[0119] The WTRU may also, or alternatively, toggle NDI based on whether the received uplink grant overlaps with a previously received uplink grant before toggling NDI. The WTRU may also, or alternatively, toggle NDI based on physical layer transmission characteristics of the current and previously received uplink grants before toggling NDI, including PUSCH duration, numerology, and / or BLER of the indicated MCS.

[0120] For a scheduling request (SR), the WTRU may be configured with scheduling request resources or a configuration tied to a given MCS table. The WTRU may select a certain SR configuration depending on the logical channel configuration. For example, if a certain LCH is restricted in the LCP to use a certain MCS table, the WTRU may select a certain associated SR configuration or resources associated with the allowed MCS table for the LCH that triggered the SR.

[0121] Some approaches relate to configured grants or allocations. For example, in some embodiments, a configured grant may be associated with a type of MCS table. Such association may be signaled as part of an RRC configuration. Alternatively, such association may be defined by physical layer signaling when the configured grant is activated. For example, a configured grant may be associated with a first type of MCS table if the PDCCH containing the activation command is received in a first search space (e.g., a WTRU-specific search space) or with a second type of MCS table if the PDCCH containing the activation command is received in a second search space (e.g., a common search space). In another example, a configured grant may be associated with a first type of MCS table if a first RNTI value (e.g., new-RNTI) is used for the PDCCH containing the activation command and with a second type of MCS table if a second RNTI (e.g., C-RNTI) is used for the PDCCH containing the activation command.

[0122] In some embodiments, the type of retransmission or new transmission and / or the trigger for it due to a configured grant may depend on the type of MCS table associated with the configured grant, with examples of such being discussed below allowing different levels of reliability for traffic using different types of MCS tables.

[0123] In some embodiments, if a configured grant timer associated with a configured grant is running, the WTRU can perform retransmissions (e.g., non-adaptive retransmissions) using the configured grant if it is associated with a first type of MCS table, but cannot perform retransmissions if it is associated with a second type of MCS table. In some examples, for configured grants associated with a first type of MCS table, the WTRU may stop the associated configured grant timer if it receives physical layer signaling of a certain type. The physical layer signaling may include, for example, a PDCCH using a first RNTI value (e.g., new-RNTI) or a PDCCH received in a certain search space (e.g., a WTRU-specific search space). These, or a combination of these, approaches may allow the WTRU to retransmit the same transport block for every configured grant instance until it receives an indication from the network for up to a duration corresponding to the configured grant timer value. This approach may have the advantage of increasing reliability.

[0124] In some examples, if a configured grant timer associated with a configured grant is not running, the WTRU may make a retransmission (e.g., a non-adaptive retransmission) using the configured grant if the configured grant is associated with a first type MCS table, or may make a new transmission (e.g., considering the NDI bit to be toggled) if the configured grant is associated with a second type MCS table.

[0125] A configured grant may overlap in time with a dynamic grant. In some examples, whether a dynamic grant takes precedence (i.e., overrides a configured grant) may depend on at least one of the type of MCS table indicated by the dynamic grant, the type of RNTI (e.g., C-RNTI or new-RNTI) used to decode the dynamic grant, or the type of MCS table associated with the configured grant. For example, in some embodiments, a dynamic grant may take precedence over a configured grant only if the dynamic grant indicates a first type of MCS table (e.g., a type of MCS table optimized for reliability) or a first type of RNTI (e.g., new-RNTI), or if the configured grant is associated with a second type of MCS table (e.g., a type of MCS table not optimized for reliability).

[0126] Some embodiments relate to dealing with multiple sets of scheduling information (e.g., grants (e.g., PUSCH resources), DCI, resources for transmission or signaling of control information (e.g., PUCCH resources), etc., where grant is used as an exemplary SI herein). For example, in some implementations, the WTRU may determine that one grant may overlap in time and / or resources with another grant. In some implementations, the WTRU may determine whether one set of scheduling information (e.g., grants) overlaps in time and / or resources with that indicated in another grant. For example, the WTRU may determine that two grants overlap in time when new data arrives in the WTRU buffer and / or depending on data priority and / or LCP mapping restrictions. The WTRU may perform actions related to prioritizing between overlapping grants or generating separate TBs accordingly. For example, if new data arrives in the WTRU buffer and a subset of the WTRU's buffered data maps to one of the overlapping grants but not both, the WTRU may take action regarding prioritization between the overlapping grants (e.g., determine that one grant has a higher priority than the other and allocate the buffered data accordingly) or may generate another TB.

[0127] In some examples, the configured grant may overlap with the dynamic grant in time. In some examples, the configured grant may overlap with the dynamic grant both in time and in the set of PRBs.

[0128] In some examples, a WTRU may be configured with a grant for uplink transmission. The WTRU may receive such a configuration via L3 or RRC signaling. Such a configuration may include time and / or frequency resources and may include other transmission parameters, such as those typically associated with a grant. In some examples, the configured grant may be associated with at least one transmission profile (TP). In some examples, a WTRU configuration for multiplexing data for transmission in a transport block (TB) may include mapping restrictions for one or more TPs. Such mapping restrictions may include an association between data of a logical channel (LCH) (or logical channel group (LCG), radio bearer (RB), or the like) and a particular TP.

[0129] In some examples, the WTRU may receive information about applicable TPs for a transmission in the grant information (e.g., in the DCI or in the grant configuration). The WTRU may determine the TPs applicable to the TBs associated with the transmission as signaled by the grant information (e.g., as part of a Logical Prioritization Procedure (LCP)), and may include only data from LCHs, LCGs, and / or RBs for which mapping restrictions allow the applicable data to be transmitted using such TBs.

[0130] The WTRU may be informed that such a configured grant is active, for example, based on receipt of signaling configuring the grant and / or from receipt of subsequent control signaling (e.g., DCI) activating the configured grant. In some examples, the resources associated with the configured grant may correspond to resources of a particular bandwidth portion (BWP). In such cases, in some examples, the WTRU determines that the configured grant is active only if the WTRU determines that the corresponding BWP is also in an activated state for the WTRU. In some examples, the resources associated with the configured grant may correspond to resources of a particular cell of the WTRU's configuration. In such cases, in some examples, the WTRU determines that the configured grant is active only if the WTRU determines that such corresponding cell is also in an activated state for the WTRU.

[0131] In some examples, a WTRU may receive dynamic scheduling information (e.g., DCI on a PDCCH) indicating that the WTRU should transmit. Such scheduling information may indicate that the resources (e.g., time and / or frequency resources) for such transmissions at least partially overlap with transmissions indicated by an active configured grant, while the WTRU may only be allowed to make a single transmission on the resources (e.g., the WTRU cannot simultaneously transmit a dynamic grant transmission and a configured grant transmission on the same resource, e.g., one transmission intended for high reliability).

[0132] In some embodiments, the WTRU selects the grant that can carry data available for transmission with the highest QoS requirements. For example, the WTRU may prioritize and / or determine the grant information that corresponds to the grant with the highest priority value (e.g., TP value) and is applicable to the transmission for which the WTRU has buffered data that can be transmitted under the grant's mapping restrictions (e.g., the grant's TP). The UE may determine the priority value of the grant as the highest priority logical channel that has buffered data that can be mapped to it, taking into account the LCP LCH selection restrictions configured for each LCH. In another example, if the WTRU does not have data available for transmission for any of the LCHs that apply to any grants in the set of overlapping grants, the grant information with the lowest priority (or lowest TP value) may be selected (e.g., for transmission of padding information and / or buffer status reports). In some examples, if the WTRU does not have data available for transmission for any of the applicable TPs and / or grants, the WTRU may prioritize or select grant information received by dynamic signaling (e.g., by DCI on the PDCCH).

[0133] In some examples, the WTRU may make such a decision based on one or more parameters of a configured mapping restriction for the LCP (e.g., when there is no explicit indication for the TP in the scheduling information and / or for the configured grant and / or in the WTRU's configuration for the configured LCH, LCG, or RB). In other words, the WTRU may select the grant that may carry data associated with the logical channel having buffered data with the highest priority when two grants (e.g., a configured grant and a dynamically scheduled grant) are available for transmission and at least one symbol is common in time to both grant information for their respective transmission durations.

[0134] In some examples, the WTRU may perform different procedures (e.g., a first selection procedure or a second selection procedure, examples of which are described below) to determine which of its current grants to select depending on the type of transmission resource (e.g., in terms of applicable MCS, MCS table, SCS, numerology, transmission duration, number of symbols, etc.) and / or depending on the type of overlap of the transmission resources (e.g., in terms of time and / or frequency).

[0135] In some examples, the WTRU always overrides an available grant (e.g., a currently active configured grant) based on the DCI if both grants are for the exact same resource / PRB / data. In some examples, the WTRU may perform the first selection procedure (e.g., as described above) only if the grant information for all grants indicates something other than an exact overlap in time and frequency (i.e., the grant information indicates that both transmissions will result in different usage of resources in terms of physical resource blocks). Otherwise, if the overlap is exact in terms of PRBs, the WTRU may deterministically (e.g., using rules that do not change dynamically) select one of the grants (e.g., depending on how the WTRU obtained the grant information). For example, the WTRU may always select a dynamically scheduled grant. This may correspond to cases where the network dynamically adapts a transmission that the WTRU would otherwise have made using a configured grant (e.g., the network allocates a dynamic grant that overlaps with a configured grant opportunity to adapt MCS or PHY reliability characteristics). In some examples, the WTRU may select a dynamically scheduled grant only if the TP and / or mapping restrictions for either grant lead to the same data being selected for transmission (e.g., if both grants indicate that they are applicable to transmission of the same data).

[0136] In some examples, the WTRU always overrides the available grant (e.g., the currently active configured grant) based on the DCI if both grants carry the same LCH mapping restrictions and / or TP and / or QoS. In some examples, the WTRU may perform a second selection procedure (e.g., as described above) only if the TP and / or resulting mapping restrictions in the grant information of both grants indicate that different data may be multiplexed on the transmission (e.g., if both grants indicate that they are applicable to transmission of data from different LCHs, LCGs, and / or RBs). Otherwise, if the same data may be transmitted using either grant, the WTRU may deterministically (e.g., using rules that do not change dynamically) select one of the grants (e.g., depending on how the WTRU obtained the grant information; e.g., the WTRU may always select the dynamically scheduled grant). For example, this may correspond to cases where the network dynamically adapts a transmission that the WTRU would otherwise have made using a configured grant (e.g., as described above).

[0137] In some examples, the WTRU always overrides an available grant (e.g., a currently active configured grant) based on the DCI if both grants have similar PHY layer QoS. For example, (possibly in one or more of the above overrides), the WTRU may deterministically (e.g., using rules that do not change dynamically) select one of the grants (e.g., depending on how the WTRU obtained the grant information, e.g., when both grants indicate use of the same MCS table, they are of the same transmission duration, they are of the same numerology, and / or they are of the same set of PRBs, the WTRU may always select the dynamically scheduled grant). In some examples, this may correspond to cases where the network dynamically adapts transmissions relative to the configured grants (e.g., as described above).

[0138] In some examples, the WTRU considers data included in a particular TB as retransmitted data. For example, in any of the above scenarios, in some implementations, if the grant is for HARQ retransmission, the WTRU may consider the data included in the transport block (e.g., for which retransmission is applicable) as part of the data available for transmission. In some examples, the WTRU may determine that a grant corresponding to an initial transmission always takes precedence over a grant corresponding to a retransmission.

[0139] Some embodiments relate to preemption. In some embodiments, preemption prioritizes one transmission over another overlapping transmission. In some embodiments, a preemptive transmission may interrupt an ongoing transmission. For example, a WTRU may determine that transmissions associated with each of the two grants may occur, at least in part, if the WTRU determines that one grant overlaps in time and / or resources with another grant (a grant is used herein as an example of a set of scheduling information for convenience, but this applies to sets of scheduling information in general). For example, a WTRU (e.g., a MAC) may generate one TB for each grant, initiate the first transmission, and then apply physical layer preemption for the portions of the transmissions that overlap with each other. In some examples, a WTRU may use physical layer preemption to address such multiple grants when the WTRU is configured to apply preemption to overlapping transmissions and / or when it is not possible to select one grant, e.g., due to insufficient processing resources or insufficient processing time. For example, such a processing time (e.g., a first processing time) may correspond to the time between receipt of a second (e.g., later in time) grant and the time corresponding to the earliest start of the applicable overlapping transmissions, and the WTRU may apply preemption to the overlapping transmissions to prioritize transmissions at the MAC layer (e.g., using LCP) if the processing time is insufficient (e.g., below a configured threshold). In some examples, such a processing time may correspond to a capability of the WTRU (which capability may be signaled to the network, for example, as part of a WTRU capability information exchange). In other examples, the WTRU may apply preemption provided that the second processing time is greater than a configured threshold, and such second processing time may correspond to the time between receipt of a second (e.g., later in time) grant and the time corresponding to the start of resource overlap between the applicable overlapping transmissions.

[0140] 2 is a signaling diagram illustrating an example scenario 200 in which a WTRU prioritizes and / or selects between grants in the MAC. In scenario 200, at time 250, the WTRU determines that transmission 210 for grant 1 will begin at time 220, and that transmission 230 for grant 2 will overlap in the time domain with transmission 210 and begin before transmission 210 at time 240. To perform MAC layer prioritization of the two grants, the WTRU determines the minimum processing time T min Time 250 requires T min , the WTRU has enough time to prioritize the two grants and prioritize transmissions accordingly using MAC layer prioritization.

[0141] 3 is a signaling diagram illustrating an example scenario 300 in which a WTRU preempts an ongoing UL transmission. In scenario 300, at time 350, the WTRU determines that transmission 310 for grant 1 will begin at time 320, and that transmission 330 for grant 2 will overlap in the time domain with transmission 310 and begin before transmission 310 at time 340. To perform MAC layer prioritization of the two grants, the WTRU determines the minimum processing time T min Time 250 requires T min , the WTRU does not have enough time to prioritize the two grants and use physical layer preemption accordingly to preempt overlapping transmissions on either Grant 1 or Grant 2.

[0142] 4 is a signaling diagram illustrating an example scenario 400 in which a physical uplink channel transmission 410 from a WTRU on UL resource 1 overlaps in the time domain with a physical uplink channel transmission 420 from a WTRU on UL resource 2. The first symbol of transmission 410 occurs at time t3, and the first symbol of transmission 420 occurs later at time t4. In order for a WTRU to handle overlaps or "collisions" between transmissions 410 and 420, the WTRU needs to have sufficient lead time to detect the collision. In order for the WTRU to use MAC layer processing (e.g., with LCP) to handle the overlap and / or generate a single transport block, the WTRU must wait a threshold time t from the start of the earlier overlapping transmission 410. MACProc It is necessary to detect duplicates only a short time before

[0143] Thus, the WTRU has already determined when transmission 410 occurs (e.g., at time t1) and has determined that the overlap with transmission 420 occurs before time t2 (i.e., at least t MACProc If the WTRU determines that overlaps will occur some time in advance (e.g., a few minutes in advance), the WTRU has sufficient processing time to handle the overlaps using MAC layer processing (e.g., MAC layer prioritization).

[0144] Alternatively, if the WTRU has already determined when transmission 410 occurs (e.g., at time t1), and the overlap with transmission 420 occurs at time t 2bis At least t before the beginning of the later transmission (i.e., the beginning of the overlap between transmission 410 and transmission 420). PHYProc If the WTRU determines that overlaps will occur before the WTRU has enough processing time to handle them using PHY layer processing (eg, physical layer preemption).

[0145] 5, 6, and 7 are flowcharts illustrating example methods that may be implemented in a WTRU to address overlap between a physical channel transmission on a first resource (e.g., a first grant) and a second physical channel transmission on a second resource (e.g., a second grant). Note that the order of the steps is exemplary. In some embodiments, the steps may occur in a different order, may overlap in time, or some steps may be omitted. Note that the generation of transport blocks (TBs) in some steps is exemplary for the type of transmission on the uplink resources and may be replaced with UL control information or generalized as an uplink transmission.

[0146] FIG. 5 is a flowchart 500 illustrating an example method for addressing the above-mentioned overlap. In step 510, a WTRU receives a first grant for a first resource, and in step 520, the WTRU receives a second grant for a second resource. The WTRU determines whether and when transmissions on the first and second grants are expected. If the transmissions on the first and second resources overlap in the time domain 530, the WTRU determines available processing time in step 540; otherwise, flow returns to step 510, where the WTRU receives another grant for the potentially overlapping set of resources. If the processing time is greater than a first threshold 550, the WTRU designates preferred resources in step 560, generates a single TB for the preferred resources in step 570, and transmits the single TB on the preferred resources in step 580. Otherwise, flow continues at step 610 as shown and described with respect to FIG. 6.

[0147] In step 540, the WTRU determines both a first available processing time for the first threshold and a second available processing time for the second threshold, according to various embodiments described above.

[0148] For example, the first available processing time for the first threshold may be determined as the time remaining after the WTRU determines that a transmission on the second grant is expected (if the transmission on the second grant occurs later than the transmission on the first grant) and the start of the transmission on the first grant, which in some embodiments corresponds to the time between t2 and t3 as shown and described with respect to FIG.

[0149] The second available processing time for the second threshold may be determined as the time remaining after the WTRU determines that a transmission on the second grant is expected (assuming the transmission on the second grant occurs later than the transmission on the first grant) and the start of the transmission on the second grant (i.e., the start of the overlap between the transmissions), which in some embodiments corresponds to the time between t2 and t4 as shown and described with respect to FIG.

[0150] At condition 550, the WTRU compares the first available processing time to a first threshold to determine whether there is enough processing time remaining for the WTRU to use MAC layer prioritization to determine which of the two should be prioritized. This threshold may be t, as shown and described with respect to FIG. MACProc Corresponds to.

[0151] It should be noted that the various steps and conditions represent only one example embodiment and are separate and, particularly, for ease of illustration and understanding only. The various steps and conditions are not necessarily sequential or separate operations. For example, the first and second grants received in steps 510 and 520, respectively, may in some embodiments be received simultaneously or in the reverse order from that shown.

[0152] An example method is described using a combination of flowcharts 500, 600, and 700, as shown and described with respect to Figures 5, 6, and 7, respectively. However, it should be noted that the method of flowchart 500 can also be conceptualized as a method for MAC layer prioritization in its own right, in which case, in some embodiments, a negative condition of condition 550 would result in a return to step 510.

[0153] Figure 6 is a flowchart 600 further illustrating an example method for addressing the above-mentioned overlap. Flow proceeds from condition 550 to condition 610 as shown and described with respect to Figure 5. In condition 610, where the first available processing time is less than a first threshold but the second available processing time is greater than a second threshold, the WTRU designates a preferred resource in step 620, generates a first TB for the first resource and a second TB for the second resource in step 630, begins transmission of the first TB on the first resource in step 640, begins transmission of the second TB on the second resource in step 650, and performs a preemption procedure (at the PHY layer) for transmission of the first TB and the second TB in step 660. Otherwise, flow continues to step 710 as shown and described with respect to Figure 7. It should be noted that the order of the various processing steps 630, 640, and 650 is exemplary and that in other embodiments, they may occur in any suitable order and / or may overlap or be simultaneous in time. It should be noted that the generation of transport blocks (TBs) in some steps is exemplary for the type of transmission on the uplink resources and may be replaced with UL control information or more generalized as an uplink transmission.

[0154] At condition 610, the WTRU compares the second available processing time (i.e., as determined in step 540 as shown and described with respect to FIG. 5) to a second threshold to determine whether there is enough processing time remaining for the WTRU to use PHY layer prioritization to determine which of the two should be prioritized. This threshold is t PHYProc Corresponds to.

[0155] FIG. 7 is a flowchart 700 further illustrating a method for addressing the overlap described above. Flow proceeds from condition 610 to condition 710 as shown and described with respect to FIG. 6. In condition 710, where the second available processing time is less than a second threshold, the WTRU designates preferred resources in step 720, generates a single TB for the resources on which the prioritized transmission is to occur in step 730, ceases processing and transmission on non-preferred UL resources in step 740, and transmits the single TB on the preferred resources in step 750. It should be noted that the order of the various processing steps 730, 740, and 750 is exemplary and may occur in any suitable order and / or overlap or be simultaneous in time in other embodiments. It should be noted that the generation of transport blocks (TBs) in some steps is exemplary for the type of transmission on uplink resources and may be swapped with UL control information or more generalized as an uplink transmission. Flow returns to step 510 as shown and described with respect to FIG. 5.

[0156] 5, 6, and 7, condition 710 is an implicit condition, i.e., if processing reaches condition 710, the second available processing time will always be less than the second threshold (i.e., there is no negative condition). However, it should be noted that this processing order is merely exemplary. In other implementations, the WTRU may determine this condition before conditions 610 and / or 550, in which case the negative condition would cause the flow to proceed accordingly to the next appropriate condition (e.g., condition 610 or 550).

[0157] In some implementations, preemption involves the WTRU stopping a first ongoing transmission (e.g., corresponding to a first grant) in order to start a second transmission (e.g., corresponding to a second grant). In some implementations, the WTRU may determine whether a grant should be considered overlapping with another grant depending on the available data in the WTRU's buffer for the applicable LCHs (e.g., if there is non-zero and / or more than a certain amount of data available for transmission for those LCHs). Such a determination can be based on LCH mapping restrictions and / or based on a determination of the applicable TP for the TB associated with a given grant.

[0158] In some implementations, the WTRU may determine that the first grant overlaps in time and / or resources with the second grant, but that the available processing resources (e.g., time) are insufficient to complete processing of the second grant before the start of the transmission corresponding to the first grant, before the transmission corresponding to the first grant has already started, and / or before at least one TB of the transmission corresponding to the first grant has already been delivered to the physical layer. In this case, the WTRU may transmit over the second grant and may preempt the transmission associated with the first grant depending on the data available for transmission and the characteristics of the first and second grants.

[0159] Specifically, in some implementations, the WTRU may preempt a transmission associated with the first grant if at least one of the following example conditions occurs:

[0160] In a first example, a WTRU may preempt a transmission associated with a first grant if the WTRU has data available for transmission that may be transmitted through a second grant in accordance with logical channel restrictions and / or TPs. In some implementations, an additional condition is that such data cannot be transmitted through the first grant in accordance with such restrictions and / or TPs.

[0161] In a second example, the WTRU may preempt a transmission associated with a first grant if the resources of the first and second grants overlap (fully or partially) in the time domain but do not overlap or do not fully overlap in the frequency domain. In some implementations, such conditions may be configurable by higher layers.

[0162] In a third example, the WTRU may preempt a transmission associated with a first grant if a priority parameter associated with the data available for transmission is higher than any priority parameter associated with the data included in the transport block carried by the transmission corresponding to the first grant. In some implementations, such priority parameters may include logical channel priorities or may include preemption priorities, e.g., as part of an LCP procedure. In some implementations, such preemption priorities may be configured by higher layers for each logical channel or group of logical channels independently of the logical channel priorities.

[0163] In a fourth example, the WTRU may preempt a transmission associated with a first grant if a priority parameter (e.g., a preemption parameter) associated with the second grant is higher than the priority parameter associated with the first grant. In some implementations, such a priority parameter may be configured for each grant, e.g., as part of the TP, or explicitly signaled in the DCI or by RRC. In some implementations, the priority parameter may be implicitly determined based on the characteristics of the grant.

[0164] In a fifth example, the WTRU may preempt a transmission associated with the earliest occurring grant if the HARQ processes corresponding to the first and second grants are not the same. In such a case, if the earliest occurring grant also overlaps with a third grant (e.g., later in time), the WTRU may still transmit via the third grant if other applicable conditions are met.

[0165] In a sixth example, the WTRU may preempt a transmission associated with a first grant if the PUSCH durations corresponding to the first and second grants are different. For example, the WTRU may preempt a transmission of a first grant if the PUSCH duration of the second grant is shorter than a fixed configured value (in some examples, such a value may depend on a maximum PUSCH duration LCP limit configured for a highest priority LCH with buffered data or a semi-statically configured value), if the PUSCH duration of the second grant is shorter than a fixed relative value (e.g., shorter than the PUSCH duration of the first grant or the remaining PUSCH duration of the first grant), and / or if the remaining time to complete the first transmission (on the first grant) is greater than a fixed value.

[0166] In a seventh example, the WTRU may preempt a transmission associated with a first grant if one of the selection methods described in the above paragraph, applied to the first and second grants, results in selecting the second grant. In other words, the above-mentioned conditions for grant prioritization may be applied as conditions for preemption (e.g., based on processing time, grant priority, QoS, etc.).

[0167] In some cases, such as in some implementations of the above case, when a WTRU preempts a transmission associated with a first grant (i.e., a "preempted transmission") to make a transmission associated with a second grant (i.e., a "preempting transmission"), one or more of the following may occur: the preempted transmission may be interrupted or canceled at or before the start of the preempting transmission; the preempted transmission may resume at or after the end of the preempting transmission; if the HARQ processes of the preempted and preempting transmissions are the same, the HARQ process of the preempted transmission may be flushed; and / or the WTRU may generate a CBG-based retransmission for the preempted code block group (in such cases, in some implementations, the WTRU may therefore receive a later grant with a smaller TBS than the total TB size of the initial transmission. The WTRU may provide an index of the preempted CBG on the first grant portion of the second grant or on the uplink control channel).

[0168] Some examples relate to HARQ process selection. In some implementations, if the second grant is a configured grant, the WTRU may identify the HARQ process associated with the configured grant. In some implementations, the WTRU may determine the HARQ process based on a predefined formula (e.g., based on resources occupied by the grant). In some implementations, the WTRU may determine that the HARQ process will be the same as the HARQ process associated with another grant (e.g., a previous, overlapping first grant). To prevent overwriting of data in the HARQ process of the first grant, the WTRU may determine (e.g., reselect) an HARQ process (i.e., a HARQ process ID other than the one determined autonomously by the WTRU based on a predefined formula) based on at least one of the following example approaches: In a first example approach, the WTRU selects an HARQ process for which a configured grant timer is not running. For example, the WTRU may cycle through available HARQ processes, e.g., starting from the one initially determined, until it finds one for which a configured grant timer is not running. If no such HARQ process can be found, the WTRU may select the HARQ process for which the timer has been running the longest. In a second example approach, the WTRU selects an HARQ process that is not associated with any ongoing transmission.

[0169] After receiving a dynamic grant that overlaps in the time domain with a configured grant, the WTRU may take one or more of several actions. In a first example action, the WTRU may stop a configured grant timer associated with the overlapping configured grant. For example, if the WTRU determines that the configured grant takes precedence over the dynamic grant, the WTRU may stop the configured grant timer, if it is running. In a second example action, the WTRU may stop the configured grant timer, for example, if the dynamic grant takes precedence over the configured grant. In a third example action, the WTRU may conditionally take the example action of the first or section if the overlapping grant has the same HARQ process ID.

[0170] In some implementations, a WTRU may have multiple active configured grants. Depending on the resource configuration aspects of the configured grants, two or more configured grants may overlap in time. The WTRU may determine the HARQ process ID of a configured grant for a certain occasion (i.e., the configured grant occasion, e.g., the time or slot into which the configured grant resources are scheduled for possible transmission) based on a predefined formula (e.g., a formula based on the resources occupied by the grant). If multiple active configured grants overlap at a given occasion for configured grant transmission, the WTRU may determine the HARQ process ID based on the selected active configured grant. For example, for a given occasion, the WTRU may select different HARQ process IDs for different configured grants, e.g., by including a configured grant index or offset in the formula used to determine the HARQ process ID.

[0171] Some examples relate to selecting and / or prioritizing among multiple active configured grants. In some implementations, a WTRU may have multiple active configured grants. Depending on the resource configuration aspect, two or more configured grants may overlap in time. The WTRU may need to prioritize or select among the overlapping configured grants. Such prioritization or selection may be made by the WTRU based on, for example, one or more conditions.

[0172] In a first example condition, the prioritization or selection is based on the highest priority of the data available for transmission. For example, the WTRU may select a configured grant over which the highest priority data may be transmitted. The priority may be based on the LCH priority configured for the LCP.

[0173] In a second example condition, the prioritization or selection is based on a configured service index and / or TP. For example, one or more TPs may be configured per configured grant and per LCH. The WTRU may select a configured grant having a TP that matches at least one TP configured for a highest priority LCH for which buffered data for transmission is available.

[0174] In a third example condition, the prioritization or selection is based on the LCP limit of the highest priority LCH for which buffered data for transmission is available. For example, the WTRU may prioritize configured grants that meet the LCP LCH selection limit of the highest priority LCH that has buffered data for transmission.

[0175] In a fourth example condition, the prioritization or selection is based on characteristics of the configured grants. Example characteristics may include the type of configured grant (e.g., NR Type 1 or Type 2) and the following: the periodicity of the configured grant (e.g., the WTRU selects the configured grant with the shortest configured periodicity); the PUSCH duration of the configured grant (e.g., the WTRU selects the configured grant with the shortest PUSCH duration, where such duration may include, for example, the total duration including repetitions (K)); the configured value for the configured grant timer for each grant (e.g., the WTRU selects the configured grant with the shortest configured grant timer); the MCS table of the configured table (e.g., the WTRU selects the configured grant with the MCS table corresponding to the lowest spectral efficiency); and / or the configured minimum number of repetitions (K) (e.g., the WTRU selects the configured grant with the fewest number of repetitions. If at least one repetition of a first configured grant does not overlap with a second configured grant, the WTRU may, for example, use the first configured grant for at least one repetition).

[0176] In a fifth example condition, the prioritization or selection is based on measurements made on the configured grants. For example, the WTRU may select a configured grant on a certain BWP based on measurements made on that BWP. The WTRU may select the configured grant with the best metric (including, but not limited to, RSRP, RSRQ, RSSI, and / or channel occupancy).

[0177] In a sixth example condition, the prioritization or selection is based on whether the transmission is an initial transmission or a retransmission, including, for example, a retransmission number or revision number. In a seventh example condition, the prioritization or selection is based on the cell or bandwidth portion in which the configured grant resource is located. In other examples, the prioritization or selection can be based on a combination of these and / or other conditions.

[0178] In some implementations, the WTRU may consider certain configured grants as deactivated. In some implementations, the WTRU may consider certain configured grants as deactivated even if they are configured within an active bandwidth portion, depending on, for example, the period of the configured grant, the active traffic / service profile, and / or the LCP restrictions for the LCH that has buffered data mapping to the configured grant. For example, if a certain TP is configured for a configured grant, the WTRU may consider only configured grants with a TP that matches that of the LCH that has buffered data for transmission as active configured grants. In another example, the WTRU may consider only configured grants with a configured period that matches the packet delay budget of the LCH that has buffered data for transmission as active configured grants.

[0179] In some implementations, grant prioritization can affect MAC and higher layers. For example, if the MAC constructs a TB that is not transmitted, not delivered to the physical layer for transmission, or preempted after the start of its PUSCH transmission duration, there may be an impact on higher layers regarding the loading of control elements and associated timers and counters. More generally, when a TB is canceled or not transmitted at the MAC, the MAC may consider taking one or more actions, such as the following example actions:

[0180] In a first example, if the canceled MAC PDU (e.g., a preempted transmission) includes several MAC CEs, the WTRU may generate MAC CEs in a later grant. The MAC CEs may include, but are not limited to, a C-RNTI MAC CE, a BSR MAC CE, and a power headroom (PHR) MAC CE. For example, the MAC entity may generate all or a subset of the MAC CEs that were included in the first grant portion of the MAC PDU for the second grant, which may be considered in the MAC prior to the preemption event (or without knowledge of whether the PHY will preempt the first TB). The MAC may consider generating such MAC CEs if the second grant overlaps in resources with the first grant.

[0181] In a second example, if some timers or actions were modified / carried in the MAC as a result of the inclusion of a MAC CE in the revoked MAC PDU (e.g., first grant / preempted grant), the MAC may reset or revert such actions. For timers that were started as a result of the inclusion of a MAC CE in a preempted grant, the MAC may stop or restart such timers. For example, if a second TB is included in the same MAC CE, the MAC may restart the associated timers, and / or if the second TB does not include the same MAC CE, the MAC may stop the associated timers.

[0182] In a third example, if a BSR MAC CE was included in a pre-empted MAC PDU and BSR timers (e.g., periodicBSR-Timer and retxBSR-Timer) were started as a result of the inclusion, the MAC may stop these timers as soon as it determines that the relevant MAC PDU is or will be pre-empted. The MAC may further retrigger a BSR that was revoked by the MAC as a result of the inclusion of the BSR MAC CE in the revoked MAC PDU, e.g., to include the BSR MAC CE in a second / later grant.

[0183] In a fourth example, if a PHR MAC CE is included in a pre-empted MAC PDU and PHR timers (e.g., phr-ProhibitTimer and phr-PeriodicTimer) were started as a result of the inclusion, the MAC may stop these timers as soon as it determines that the associated MAC PDU is or will be pre-empted. The MAC may further retrigger a PHR that was revoked by the MAC as a result of the inclusion of the PHR MAC CE in a revoked MAC PDU, e.g., to include the PHR MAC CE in a second / later grant.

[0184] In a fifth example, if a counter was incremented or modified as a result of the inclusion of a MAC CE in a revoked MAC PDU (e.g., first grant / preempted grant), the MAC may decrement the counter to restore its value or may reset the counter.

[0185] These example actions (or other actions) can be taken more generally by the MAC for cases where the TB is canceled or not transmitted, and can be further conditioned on the MAC CE priority, or the priority of the LCH that triggered the MAC CE incorporation.

[0186] Some approaches relate to discontinuous reception (DRX). For example, DRX procedures may be enhanced to provide different power saving opportunities for the WTRU, e.g., depending on the type of traffic. In some examples, an additional DRX timer may be utilized when a grant or assignment (or using two or more RNTIs, such as C-RNTI and new-RNTI) indicating one of multiple types of MCS tables may be received. Such an additional DRX timer may be started or stopped based on conditions similar to those for starting or stopping an existing DRX timer, e.g., with the additional condition that the grant or assignment indicates a first type of MCS table (or uses a first RNTI, such as new-RNTI). In some examples, an existing DRX timer may be started or stopped with the additional condition that the grant or assignment indicates a second type of MCS table (or uses a second RNTI, such as C-RNTI).

[0187] In some examples, a new timer (e.g., drx-HARQ-RTT-TimerUL-UR, the minimum duration before a UL HARQ retransmission grant is expected by the MAC entity) may be started only when the PDCCH indicates a UL transmission indicating a first type MCS table or when a MAC PDU is transmitted in a configured uplink grant associated with a first type MCS table. A new timer (e.g., drx-RetransmissionTimerUL-UR, the maximum duration until a grant for UL retransmission is received) may be stopped under the same conditions. In some examples, the first type MCS table may correspond to so-called ultra-reliable communication (e.g., URLLC). Thus, in the examples herein, the active time and various timers are shown as pertaining to ultra-reliable communication (UR), but it should be noted that these techniques may be applied to any desired type of MCS table in other examples. In some examples, an existing timer (e.g., drx-HARQ-RTT-TimerUL) may be started only when the PDCCH indicates an UL transmission indicating a second type MCS table or a MAC PDU is transmitted in a configured uplink grant associated with a second type MCS table. An existing timer (e.g., drx-RetransmissionTimerUL) may be stopped under the same conditions. In some examples, a new timer (e.g., drx-InactivityTimer-UR) may be started only when the PDCCH indicates a new transmission associated with a first type MCS table. In some examples, a new timer (e.g., drx-RetransmissionTimerUL) may be started as soon as the new timer (e.g., drx-HARQ-RTT-Timer-UL-UR) expires.

[0188] Similar behavior may apply to the corresponding DL timers. In some examples, a common active time is used for all types of MCS tables or RNTIs. In such a case, the active time may also include the time when some of the newly defined timers are running, such as drx-InactivityTimer-UR (duration after a PDCCH opportunity in which the PDCCH indicates a new UL or DL ​​transmission for the MAC entity), drx-RetransmissionTimerDL-UR (maximum duration until a DL retransmission is received), or drx-RetransmissionTimerUL-UR or drx-onDurationTimer-UR (duration at the beginning of a DRX cycle). Alternatively, in some examples, the active time may be defined for a certain type of MCS table or set of MCS tables for an RNTI. Multiple types of active time may be defined, each of which may apply when the WTRU monitors the PDCCH for a certain set of types of MCS tables (e.g., UR MCS) or RNTI.

[0189] For example, Active Time UR may include the time during which at least one of drx-onDurationTimer-UR, or drx-InactivityTimer-UR, or drx-RetransmissionTimerDL-UR, or drx-RetransmissionTimerUL-UR, or ra-ContentionResolutionTimer-UR is running. During Active Time UR, the WTRU may monitor the PDCCH only for a first type of MCS table or only for a first RNTI (e.g., new-RNTI). Alternatively, the WTRU may monitor the PDCCH regardless of the MCS table or RNTI type. During Active Time, the WTRU may monitor the PDCCH only for a second type of MCS table or only for a second RNTI (e.g., C-RNTI). Alternatively, the WTRU may monitor the PDCCH regardless of the MCS table or RNTI type.

[0190] Some approaches relate to search space configuration. For example, a WTRU may be configured to monitor the PDCCH using a first set of DCI formats (or DCI sizes) with a first RNTI (e.g., C-RNTI) and a second set of DCI formats (or DCI sizes) with a second RNTI (e.g., new-RNTI). In some examples, the WTRU may be configured to monitor the PDCCH on a particular search space or core set using a certain set of RNTIs. The set of RNTIs may be signaled by RRC. For example, a UE may be configured to monitor the PDCCH only for the new-RNTI within a first core set or search space, and to monitor the PDCCH for both the C-RNTI and the new-RNTI within a second core set or search space.

[0191] In some examples, the set of RNTIs may be determined from the monitoring period of the search space. For example, <k thr For k, the WTRU may monitor the new-RNTI, and for higher periods, the WTRU may monitor the C-RNTI (or both the new-RNTI and the C-RNTI). thr is the threshold by which the WTRU is configured. In other words, the period of the search space is k thrIf it is less than, the WTRU monitors for the first RNTI or uses the first MCS table; otherwise, it monitors for the second RNTI or uses the second MCS table. In some examples, the set of RNTIs may be determined from the Symbol Within Slot (i.e., for a PUSCH transmission, determine the C-RNTI from the symbol number within the slot). For example, the first N symbols may be associated with the C-RNTI, and the remaining symbols of the slot may be associated with the new-RNTI. In some examples, the set of RNTIs may be determined from the aggregation level. In some examples, if a new RNTI is used with the same DCI size, the interpretation of the DCI field may depend on the RNTI used. This may allow for a reduction in the false alarm rate.

[0192] Some examples relate to time domain allocation for PDSCH / PUSCH. In some examples, the time domain allocation for URLLC points to different tables. Some examples relate to HARQ feedback timing indication. In some examples, the set of K1 values ​​differs between URLLC / eMBB. In some examples, unused fields may be reused to reduce the false alarm rate. For example, since URLLC packets are expected to have small sizes, CBG may not be used even if the cell is configured with CBG-based transmission. In this case, the CBGTI / CBGFI fields in the DCI may be set to a special value.

[0193] Note that K1 refers to the delay between DL data (PDSCH) reception and the corresponding ACK transmission on the UL. K2 refers to the delay between UL grant reception on the DL and UL data (PUSCH) transmission. The set of K2 values ​​may differ between URLLC / eMBB, e.g., for different RNTI values. N1 refers to the number of OFDM symbols required for WTRU processing from the end of NR-PDSCH reception to the earliest possible start of the corresponding ACK / NACK transmission from the WTRU's perspective. The set of N1 values ​​may differ between URLLC / eMBB, e.g., for different RNTI values. N2 refers to the number of OFDM symbols required for WTRU processing from the end of NR-PDCCH, including UL grant reception, to the earliest possible start of the corresponding NR-PUSCH transmission from the WTRU's perspective. The set of N2 values ​​may differ between URLLC / eMBB, e.g., for different RNTI values.

[0194] Although features and elements are described above in particular combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. 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 computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, ROM, RAM, registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and DVDs. A processor in conjunction with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal device, base station, RNC, or any host computer.

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: receiving configuration information indicating a first configured grant (CG) and a second CG, the configuration information further indicating a first offset associated with the first CG and a second offset associated with the second CG; determining that a first transmission resource associated with the first CG and a second transmission resource associated with the second CG at least partially overlap in time; selecting one of the first CG and the second CG as a prioritized grant; transmitting an uplink transmission using the first transmission resource associated with the first CG or the second transmission resource associated with the second CG, wherein the uplink transmission is associated with a first Hybrid Automatic Repeat Request (HARQ) process identifier (ID) determined based on the first offset, on condition that the first CG is selected as the prioritized grant, and the uplink transmission is associated with a second HARQ process ID determined based on the second offset, on condition that the second CG is selected as the prioritized grant; 10. A WTRU comprising: a processor configured to execute:

2. 2. The WTRU of claim 1, wherein the first HARQ process ID is determined based on a formula using the first offset associated with the first CG, and the second HARQ process ID is determined based on a formula using the second offset associated with the second CG.

3. The WTRU of claim 1 , wherein the first CG is associated with a first CG opportunity and the second CG is associated with a second CG opportunity.

4. 4. The WTRU of claim 3, wherein the first CG includes a first time or slot in which configured grant resources are scheduled for possible transmissions, and the second CG includes a second time or slot in which configured grant resources are scheduled for possible transmissions.

5. 2. The WTRU of claim 1, wherein the processor being configured to determine that a first transmission resource associated with the first CG and a second transmission resource associated with the second CG at least partially overlap in time includes the processor being configured to determine that at least one symbol of a first transmission resource associated with the first CG overlaps with at least one symbol of a second transmission resource associated with the second CG.

6. 10. The WTRU of claim 1, wherein the processor is configured to select one of the first CG and the second CG as a prioritized grant based on one or more Logical Channel Prioritization (LCP) restrictions.

7. 2. The WTRU of claim 1, wherein the first CG is associated with a first type, a first period, and a first physical uplink shared channel (PUSCH) duration, and the second CG is associated with a second type, a second period, and a second PUSCH duration.

8. 2. The WTRU of claim 1, wherein the processor is configured to select one of the first CG and the second CG as a prioritized grant based on a logical channel priority of a first logical channel mapped to the first CG and a logical channel priority of a second logical channel mapped to the second CG.

9. 1. A method performed by a wireless transmit / receive unit (WTRU), comprising: receiving configuration information indicating a first configured grant (CG) and a second CG, the configuration information further indicating a first offset associated with the first CG and a second offset associated with the second CG; determining that a first transmission resource associated with the first CG and a second transmission resource associated with the second CG at least partially overlap in time; selecting one of the first CG and the second CG as a prioritized grant; transmitting an uplink transmission using the first transmission resource associated with the first CG or the second transmission resource associated with the second CG, wherein the uplink transmission is associated with a first Hybrid Automatic Repeat Request (HARQ) process identifier (ID) determined based on the first offset, on condition that the first CG is selected as the prioritized grant, and the uplink transmission is associated with a second HARQ process ID determined based on the second offset, on condition that the second CG is selected as the prioritized grant; A method comprising:

10. 10. The method of claim 9, wherein the first HARQ process ID is determined based on a formula using the first offset associated with the first CG, and the second HARQ process ID is determined based on a formula using the second offset associated with the second CG.

11. The method of claim 9 , wherein the first CG is associated with a first CG opportunity and the second CG is associated with a second CG opportunity.

12. 12. The method of claim 11, wherein the first CG includes a first time or slot in which configured grant resources are scheduled for possible transmissions, and the second CG includes a second time or slot in which configured grant resources are scheduled for possible transmissions.

13. 10. The method of claim 9, wherein determining that a first transmission resource associated with the first CG and a second transmission resource associated with the second CG at least partially overlap in time includes determining that at least one symbol of the first transmission resource associated with the first CG overlaps with at least one symbol of the second transmission resource associated with the second CG.

14. 10. The method of claim 9, wherein one of the first CG and the second CG is selected as a prioritized grant based on one or more logical channel prioritization (LCP) restrictions.

15. 10. The method of claim 9, wherein the first CG is associated with a first type, a first periodicity, and a first Physical Uplink Shared Channel (PUSCH) duration, and the second CG is associated with a second type, a second periodicity, and a second PUSCH duration.

16. 10. The method of claim 9, wherein one of the first CG and the second CG is selected as an active grant based on a logical channel priority of a first logical channel mapped to the first CG and a logical channel priority of a second logical channel mapped to the second CG.

17. A base station, transmitting, to a wireless transmit / receive unit (WTRU), configuration information indicating a first configured grant (CG) and a second CG, wherein a first transmission resource associated with the first CG and a second transmission resource associated with the second CG at least partially overlap in time, and the configuration information further indicates a first offset associated with the first CG and a second offset associated with the second CG; receiving an uplink transmission from the WTRU on the first transmission resource associated with the first CG or the second transmission resource associated with the second CG, the uplink transmission being associated with a hybrid automatic repeat request (HARQ) process identifier (ID), the HARQ process ID being determined based on a formula using a first offset on condition that the uplink transmission is received via the first transmission resource associated with the first CG, or the HARQ process ID being determined based on a formula using the second offset on condition that the uplink transmission is received via the second transmission resource associated with the second CG; 11. A base station comprising: a processor configured to execute

18. 20. The base station of claim 17, wherein the first CG is associated with a first CG opportunity and the second CG is associated with a second CG opportunity.

19. 20. The base station of claim 18, wherein the first CG includes a first time or slot in which configured grant resources are scheduled for possible transmission, and the second CG includes a second time or slot in which configured grant resources are scheduled for possible transmission.

20. 20. The base station of claim 17, wherein the configuration information is transmitted via a radio resource control (RRC) message.

Images