WO2020069165A1

WO2020069165A1 - Downlink data reception with rrc configured scheduling and pdsch blind decoding

Info

Publication number: WO2020069165A1
Application number: PCT/US2019/053211
Authority: WO
Inventors: Mahmoud Taherzadeh Boroujeni; Shahrokh Nayeb Nazar; Moon-Il Lee; Ahmad Reza HEDAYAT; Oghenekome Oteri
Original assignee: Idac Holdings, Inc.
Priority date: 2018-09-26
Filing date: 2019-09-26
Publication date: 2020-04-02
Also published as: TW202025823A

Abstract

Methods and apparatuses for scheduling and receiving a downlink data transmission are provided. A method comprises receiving a higher layer configuration for one or more Physical Downlink Shared Channel (PDSCH) candidates. Each PDSCH candidate may have one or more Code Blocks (CBs) or Code Block Groups (CBGs). The method comprises monitoring a search space for a Group-Common Physical Downlink Control Channel transmission. The transmission includes a Downlink Monitoring Indication (DMI) flag that activates blind decoding. Blind decoding may be performed for CBs or CBGs in the PDSCH candidates. Limits may be applied to a total number of CBs or CBGs for which to attempt blind decoding. The method may further comprise selecting a subset of PDSCH candidates for which blind decoding of the CBs or CBGs will not exceed the limits. Blind decoding may then be attempted on one or more CBs or CBGs in the selected candidates.

Description

DOWNLINK DATA RECEPTION WITH RRC CONFIGURED

SCHEDULING AND PDSCH BLIND DECODING

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 62/736,900, filed September 26, 2018, the contents of which are incorporated herein by reference.

BACKGROUND

[0002] In wireless systems, a new structure and design may be adopted for the physical downlink control channel (PDCCH), as well as the physical downlink shared channel (PDSCH). Slot-based and non-slot-based transmissions and different rates of monitoring for PDCCH may be defined. For data transmission, a Transport Block (TB) is a unit of data transmission consisting of one or multiple Code Blocks (CBs). A CB is a part of data that is associated with one block of error correction code and one Cyclic Redundancy Code (CRC). A Code Block group (CBG) is a group of CBs that are associated with a single bit for ACK-NACK. One transport block may consist of multiple CBGs. The maximum of number of CBGs per TB may be configured by higher layer signaling.

SUMMARY

[0003] Methods and apparatuses for scheduling and receiving a downlink data transmission are provided. A method comprises receiving a higher layer configuration for one or more PDSCH candidates. Each PDSCH candidate may have one or more CBs or CBGs. The method comprises monitoring a search space for a Group-Common Physical Downlink Control Channel transmission. The transmission includes a Downlink Monitoring Indication (DMI) flag that activates blind decoding. Blind decoding may be performed for CBs or CBGs in the PDSCH candidates. Limits may be applied to a total number of CBs or CBGs for which to attempt blind decoding. The method may further comprise selecting a subset of PDSCH candidates for which blind decoding of the CBs or CBGs will not exceed the limits. Blind decoding may then be attempted on one or more CBs or CBGs in the selected candidates.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the figures indicate like elements, and wherein: [0005] FIG. 1 A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

[0006] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment;

[0007] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0008] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1 A according to an embodiment;

[0009] FIG. 2 is an example of a PDSCFI candidate in which only the first CBs of each CBG are used for blind detection;

[0010] FIG. 3 is an example of a PDSCFI candidate in which only the first CBGs of each TB are used for blind detection;

[001 1] FIG. 4 is an example procedure for blind detection of PDCCFI-less PDSCFI candidates based on the joint limit on the number of blind-decoded CCEs, CBs, CBGs and their associated Resource Blocks (RBs) and Resource Block Groups (RBGs) in a slot ;

[0012] FIG. 5 is an example of a WTRU procedure for monitoring PDCCFI-less PDSCFI based on the DMI flag received in a group-common PDCCFI;

[0013] FIG. 6 is an example process for blind detection as applied to a subset of configured PDSCFI candidates;

[0014] FIG. 7 is an example of blind detection performed according to the example of FIG. 6, wherein four PDSCFI candidates are monitored following positive indication by a DMI flag.

DETAILED DESCRIPTION

[0015] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0016] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (ON) 106, a public switched telephone network (PSTN) 108, the Internet 1 10, and other networks 1 12, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0017] The communications systems 100 may also include a base station 114a and/or a base station 1 14b. Each of the base stations 1 14a, 1 14b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 1 10, and/or the other networks 112. By way of example, the base stations 1 14a, 1 14b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Flome Node B, a Flome eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 1 14a, 1 14b are each depicted as a single element, it will be appreciated that the base stations 1 14a, 114b may include any number of interconnected base stations and/or network elements. [0018] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 1 14a and/or the base station 1 14b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 1 14a may be divided into three sectors. Thus, in one embodiment, the base station 1 14a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 1 14a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and/or receive signals in desired spatial directions.

[0019] The base stations 1 14a, 1 14b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 1 16, 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 1 16 may be established using any suitable radio access technology (RAT).

[0020] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 1 14a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (FISPA+). HSPA may include High-Speed Downlink (DL) Packet Access (FISDPA) and/or High-Speed Uplink (UL) Packet Access (HSUPA).

[0021] In an embodiment, the base station 1 14a 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 1 16 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro). [0022] In an embodiment, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 1 16 using NR.

[0023] In an embodiment, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., an eNB and a gNB).

[0024] In other embodiments, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., 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), and the like.

[0025] The base station 1 14b in FIG. 1 A may be a wireless router, Flome Node B, Flome eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.1 1 to establish a wireless local area network (WLAN). In an embodiment, the base station 1 14b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 1 14b 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. As shown in FIG. 1A, the base station 1 14b may have a direct connection to the Internet 1 10. Thus, the base station 1 14b may not be required to access the Internet 1 10 via the CN 106.

[0026] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location- based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high- level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0027] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 1 12. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 1 10 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 1 12 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 1 12 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0028] 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, which may employ a cellular-based radio technology, and with the base station 1 14b, which may employ an IEEE 802 radio technology.

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

[0030] The processor 1 18 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 1 18 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 1 18 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 1 18 and the transceiver 120 as separate components, it will be appreciated that the processor 1 18 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0034] 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 organic light-emitting diode (OLED) display unit). The processor 1 18 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 1 18 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), readonly memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital

(SD) memory card, and the like. In other embodiments, the processor 1 18 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0036] The processor 118 may also be coupled to the 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 in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 1 16 from a base station (e.g., base stations 1 14a, 1 14b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0037] 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 e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like.

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

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

[0040] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 1 16. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.

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

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

[0043] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve 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 an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.

[0044] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

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

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

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

[0048] In representative embodiments, the other network 1 12 may be a WLAN.

[0049] 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 another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.1 1 e DLS or an 802.11 z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an“ad-hoc” mode of communication. [0050] When using the 802.1 1 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in 802.11 systems. For CSMA/CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0051] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0052] Very High Throughput (V HT) STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels. The 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 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, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0053] Sub 1 GHz modes of operation are supported by 802.1 1 af and 802.1 1 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.1 1 ah relative to those used in 802.1 1 h, and 802.1 1 ac. 802.11 af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.1 1 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.1 1 ah may support Meter Type Control/Machine-Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life). [0054] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.1 1 h, 802.1 1 ac, 802.1 1 at, and 802.1 1 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 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) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

[0055] In the United States, the available frequency bands, which may be used by 802.1 1 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.1 1 ah is 6 MHz to 26 MHz depending on the country code.

[0056] FIG. 1 D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 16. The RAN 104 may also be in communication with the CN 106.

[0057] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 1 16. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 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 while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

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

[0059] 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 the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.

[0060] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0061] The CN 106 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a

Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

[0062] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve 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 of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultrareliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.

[0063] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N1 1 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type may be IP- based, non-IP based, Ethernet-based, and the like.

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

[0065] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 1 12, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0066] In view of FIGs. 1 A-1 D, and the corresponding description of FIGs. 1 A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 1 14a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

[0067] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the 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 purposes of testing and/or performing testing using over-the-air wireless communications.

[0068] The one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data. [0069] Data transmissions may be scheduled dynamically by a gNB using downlink control information (DCI) which may be transmitted by PDCCH. DCI formats used for scheduling PDSCH may include DCI Format 1_0 and Format 1_1. In Table 1 , parameters indicated by DCI having Format 1 -0, with a CRC scrambled by a Cell Radio Network Temporary Identifier (C-RNTI), are shown.

DCI Parameter Bits

Notes

Identifier for DCI formats

jAlways set to 1 , meaning thi

Frequency domain resource assignment \ Variable ^Variable due to DL BWP number of RBs

Table 1 : DCI Format 1 -0 (with CRC scrambled by C-RNTI)

Table 2 shows parameters transmitted within a DCI with Format 1 -1.

PDSCH-to-HARQ_feedback timing indicator 3

Antenna port(s) and number of layers

2, 3, 4, 5,6 !

Table 2: DCI with Format 1-1

Another method for downlink data scheduling is downlink (DL) Semi-Persistent Scheduling (SPS) used in conjunction with PDCCFI validation. A similar method may also be used for configured UL grant Type 2. An exemplary procedure for both cases (DL SPS and configured UL grant) may be described as follows: For instance, a WTRU may validate, for scheduling activation or scheduling release, a DL SPS assignment PDCCH or configured UL grant Type 2 PDCCH if: (1 ) the CRC parity bits of a corresponding DCI format are scrambled with a CS-RNTI provided by higher layer parameter CS-RNTI, and (2) the new data indicator field for the enabled transport block is set to‘O’. Validation of the DCI format may be achieved if all fields for the DCI format are set according to Table 3 or Table 4, shown below. If validation is achieved, the WTRU may consider the information in the DCI format a valid activation or valid release of DL SPS or configured UL grant Type 2. If validation is not achieved, the WTRU considers the DCI format as having been detected with a nonmatching CRC.

Table 3: Special fields for DL SPS and UL grant Type 2 scheduling activation PDCCH validation

Table 4: Special fields for DL SPS and UL grant Type 2 scheduling release PDCCH

[0070] A reference symbol may be used to denote a symbol such as a complex number that is fixed, known, and used as a pilot. A reference signal may be used to denote the time domain signal that is generated after processing reference symbols. For example, in OFDM, reference symbols are complex numbers that are fed into the IDFT block and a reference signal is the output of the IDFT block. Downlink Control Information (DCI) is a set of bits that may be transmitted over a PDCCH for a user or a group of users. A Resource Element (RE) is one OFDM symbol on one subcarrier. A Resource Element Group (REG) is a group of REs and is the smallest building block for a PDCCH. An REG may be used as a building block of a control channel element (CCE). Each REG consists of twelve resource elements REs on one OFDM symbol in time and one Resource Block (RB) in frequency. In each REG, nine REs are used for control information and three REs are used for a demodulation reference signal (DMRS). Multiple REGs (2, 3, or 6), adjacent in time or frequency, form a REG bundle which is used with the same precoder and their DMRSs are used together for channel estimation. Six REGs (in the format of 1 , 2, or 3 REG bundles) form one CCE which is the smallest possible PDCCH. Each PDCCH consists of one or multiple CCEs (i.e. 1 , 2, 4, 8, or 16 CCEs) and the number of CCEs for a PDCCH is called its aggregation level (AL). Mapping of REG bundles may have two different modes of interleaving and non-interleaving. In the non-interleaving mapping, consecutive REG bundles (adjacent in frequency) form a CCE and CCEs adjacent in frequency form a PDCCH. In the interleaving mapping, REGs are interleaved (or permuted) before being mapped to CCEs, generally resulting in non-adjacent REG bundles in one CCE and non- adjacent CCEs in one PDCCH. A control resource set (CORESET) is a set of resource elements used for a downlink control channel and is configured by its frequency assignment, as chunks of six RBs, the length in time (1 -3 OFDM symbols), the type of REG bundle, and the type of mapping from REG bundles to CCEs (i.e. whether it is interleaving or non-interleaving). In each bandwidth part (BWP), there can be up to three CORESETs (twelve CORESETs in all four possible bandwidth parts).

[0071] Each WTRU may be assigned with a set of PDCCH candidates to be monitored during the blind detection of PDCCH, which is called a search space or a set of search spaces (for multiple aggregation levels). Each set of search space is configured by its associated CORESET, the number of candidates with each aggregation level, and the monitoring occasions. The monitoring occasions may be determined by monitoring periodicity in terms of slots, monitoring offset, and monitoring pattern (for instance, as 14 bits corresponding to all possible patterns of symbols inside a slot).

[0072] Downlink data transmissions may be scheduled by DCI and sent by a PDCCH, which is transmitted over its specified resources. A requirement of associating a WTRU-specific DCI with every downlink data transmission may create some problems. One problem is that specified resources for WTRU-specific PDCCH may be not sufficient for scheduling all required downlink data transmission and blocking of PDCCH may occur for some WTRU with high probability. The other problem is that for some small data or some downlink transmission that happens regularly, without much variation in scheduling parameters, transmitting a dynamic dedicated WTRU-specific DCI may be inefficient and may be wasteful in terms of control resources. For flexibility in downlink scheduling by a gNB, the capability of monitoring different options of downlink transmission on the WTRU side may be necessary, which adds to the WTRU receiver overhead. Therefore, it is desirable to have methods for downlink transmission without associated WTRU-specific DCI, and without surpassing the limits of the WTRU receiver in terms of monitoring capability.

[0073] Wireless systems may support multiple types of traffic including eMBB, and URLLC. Semi- Persistent Scheduling (SPS) may be configured by RRC per serving cell and per BWP, and multiple configurations may be active simultaneously on different Serving Cells. The activation and deactivation of the SPS may be independent among the Serving Cells by the PDCCH. To enable SPS support for different use cases, e.g. eMBB and URLLC, or different traffic types within the same use case, multiple SPS configurations may be configured and activated within a single serving cell and/or within a single BWP. In some cases, a single SPS configuration may enable multiple sub-SPS configurations and may be activated within a single serving cell and/or a within single BWP. In the case multiple SPS configurations are active, methods may be needed to signal the properties of each configuration to the WTRU. This may include the identification of priority for each SPS scheduling configuration in addition to the typical parameters for a configuration. In the case that there are multiple SPS configurations, there may be a probability that some configuration resources overlap for the same WTRU. In this case, WTRU procedures may needed to enable the WTRU to identify the specific SPS/CS configuration transmitted when decoding. This may limit the decoding load on the WTRU, especially in the case of large packets.

[0074] A reference symbol may be used to denote a symbol such as a complex number that is fixed and known and used as a pilot. A reference signal may be used to denote the time domain signal that is generated after processing the reference symbols. For example, in OFDM, reference symbols may be considered complex numbers that are fed into the IDFT block while reference signal is the output of the IDFT block. Downlink control information (DCI) may be a set of bits that are transmitted over a PDCCFI for a user or a group of users. A resource element (RE) may be one OFDM symbol on one subcarrier, and a resource element group (REG) may refer to a group of REs used as building blocks of a control channel element (CCE), which may assign resource elements to a user. A control resource set (CORESET) may be a set of resource elements used for downlink control channel, configured by its frequency resources and its length in time (in terms of symbols) and the type of its REG bundles. A search space (or a set of search spaces) may be a set of PDCCFI candidates that are monitored by a WRTU or a group of WTRUs during blind detection of PDCCFI. A Code Block (CB) may be a part of data that is associated with one block of error correction code and one CRC. A Code Block Group (CBG) may be a group of CBs that are associated with a single bit for ACK-NACK. A Transport Block (TB) may be a unit of data transmission consisting of one or multiple CBs.

[0075] Methods for semi-static configuration of PDSCFI candidates are described herein. One method for downlink transmission without an associated physical downlink control channel (PDCCFI) is to use semi-static configuration to configure all or a part of the parameters that are required for scheduling the downlink data transmission.“DCI-less PDSCFI,”“downlink data transmission without WTRU-specific DCI,” and“downlink data reception with configured scheduling” may be used to refer to this method.

[0076] The configuration may determine all the parameters required for scheduling of downlink data transmission, or it may define candidates to be monitored by the WTRU. The semi-static configuration, by RRC or other higher layer signaling, may indicate one or multiple of the following parameters for one or multiple downlink transmission candidates: a modulation and coding scheme (MCS); frequency resources; time resources; associated HARQ parameters; or periodicity and offset, in terms of number of slots.

[0077] In an exemplary embodiment, part of the parameters for PDCCH-less PDSCH may be specified by a standard specification. For example, it may be specified that PDCCH-less PDSCH is only transmitted with QPSK modulation. For a DCI-less downlink transmission, a first set of parameters may be specified in DCI Format 0-1 or 1 -1 and may be RRC configured, where, for each parameter, the WTRU is configured with one or multiple values. A second set of DCI parameters, however, need not necessarily be known during PDSCH decoding and instead may be specified aggregated within PDSCH.

In this example, a configured WTRU may search for a PDSCH with one of the configured values for the parameters that belong to the first set of parameters. If a PDSCH is detected, the WTRU may retrieve the value of the parameters that belong to the second set and continue the PDSCH processing. The parameters that may be suitable for the first set of parameters are the following: frequency domain resource assignment; time domain resource assignment; VRB-to-PRB mapping; modulation and coding scheme; redundancy version (RV); and downlink assignment index. Parameters that are suitable for the second set of parameters may include the following: a new data indicator, HARQ process number, PUCCH resource indicator, TPC command for scheduled PUCCH, and PDSCH-to-HARQ_feedback timing indicator.

[0078] Methods for blind detection of PDSCH candidates with reduced complexity are described herein. One such method to reduce the complexity of blind detection for PDSCH candidates, in the absence of a PDCCH, is to perform blind detection on only a part of the PDSCH candidate and abort the process if detecting that part fails.

[0079] In one embodiment, shown in FIG. 2, the WTRU may perform the blind detection/decoding on the first code block (CB) of a code block group (CBG) or transport block (TB). In this example, if the first CB of a CBG of the transport block associated with the PDSCH candidate is decoded successfully and a CRC check is successful, the subsequent CBs of that CBG may be decoded. Otherwise, the WTRU may abort the decoding/detection process of the subsequent CBs comprising that CBG, as shown in FIG. 2. In this case, if all CBs of a CBG are decoded correctly (i.e. if their CRC passes successfully), the WTRU may transmit HARQ-ACK feedback in a PUCCH for that CBG; otherwise, a NACK will be sent. In one embodiment of this method, HARQ ACK/NACK feedback of PDSCH will be sent only if the first CB of the transport block is detected successfully and its CRC check is successful. As shown in the example of FIG. 2, a WTRU may perform blind detection on a PDSCH candidate using only the first CBs of a CBGs. In this case, the transport block (TB) 200 consists of two CBGs 210 and 220. The first CBG 210 consists of CBs 21 1 , 212, and 213, and the second CBG 220 consists of CBs 221 , 222, and 223.

[0080] In an embodiment shown generally in FIG. 3, the WTRU may perform the blind detection/decoding on the first code block (CBG) of a transport block (TB). In this embodiment, if the first CBG of a TB associated with the PDSCH candidate is decoded successfully and a CRC check is successful for all CBs comprising the CBG, the subsequent CBGs of that TB may be decoded. Otherwise, the WTRU may abort the decoding/detection process of the subsequent CBGs comprising that TB.

[0081] For instance, as can be seen from FIG. 3, a WTRU may perform blind detection on a PDSCFI candidate 300 where only the first CBGs of each TB are used for blind detection. Here, each transport block (TB) consists of three CBGs. The first TB 310 consists of CBGs 31 1 , 312, and 313, and the second TB 320 consists of CBGs 321 , 322, and 323.

[0082] In an embodiment, a limit can be specified in the standards specification on the maximum number of CBs/CBGs for PDSCFI monitoring/blind detection for a WTRU per slot for a given numerology. Similar limits may be applied, for example, for a span of slots, symbols, CBs, CBGs or TBs. In this case, the WTRU may determine which of its configured PDSCFI candidates should be considered for blind detection. In case the number of configured PDSCFI candidates exceeds the specified limit on the maximum number of CBs/CBGs, which could be based on the WTRU capability/category, the WTRU may not be expected to monitor, decode, or detect a subset of configured PDSCFI candidates.

[0083] The WTRU may select a subset of PDSCFI candidates for blind detection based on one or more of the following parameters: an index of the carrier in case the WTRU is configured for operation with carrier aggregation, an index of the bandwidth part (BWP) in case the WTRU is configured for operation with multiple active BWPs, an index of the PDSCFI candidate, an index of the search space in case the PDSCFI candidates are grouped in multiple search spaces, a priority of the PDSCFI candidate (e.g., URLLC vs eMBB), a number of TBs comprising the PDSCFI candidate, a number of CBGs comprising a TB, a number of CBs comprising a CBG, a TB size for the PDSCFI candidate, a modulation and coding scheme for the PDSCFI candidate, a number of layers for the PDSCFI candidate (which impacts the detection complexity), a PRB bundling size for the PDSCFI candidate (which impacts the channel estimation complexity), a number of component carriers (e.g., serving cells) in case the WTRU is configured for operation with carrier aggregation, or a number of BWPs in case the WTRU is configured for operation with multiple active BWPs. [0084] In one example, starting with the lowest PDSCH index, and/or highest priority, on the lowest index DL BWP of a serving cell, the WTRU may add the PDSCH candidates to the pool of active PDSCH candidates for monitoring/blind detection if their total number of CBs/CBGs does not pass the specified limit on the number of blind-detected CBs/CBGs.

[0085] In an embodiment, a limit can be specified in the standards specification on the maximum number of RBs and/or Resource Block Groups (RBGs) for PDSCH monitoring/blind detection for a WTRU per slot for a given numerology. Given that the WTRU may be needed to perform channel estimation for each Physical Resource Block (PRB) or PRB bundle for PDSCH detection, a limit on the number of PRBs/RBGs may ensure that the complexity of channel estimation per slot does not exceed a WTRU’s capability. Similar limits may be applied, for example, for a span of slots, symbols, CBs, CBGs or TBs. In case the number of configured PDSCH candidates exceeds the specified limit on the maximum number of RBs/RBGs, which could be based on the WTRU capability/category, the WTRU is not expected to monitor, decode, or detect a subset of configured PDSCH candidates.

[0086] When the WTRU is determining the PDSCH candidates for monitoring, the WTRU may not consider the overlapped RBs/RBGs toward the maximum number of RBs/RBGs for PDSCH monitoring limit. The WTRU may determine that the RBs/RBGs are non-overlapped if they correspond to different BWP indexes, different carrier indexes, different PDSCH search space indexes, different first symbols for the reception of the respective PDSCH candidates, different lengths for the respective PDSCH candidates, or different PRB bundling sizes.

[0087] According to an embodiment, the WTRU may consider that there is a joint limit on the maximum number of RBs and/or RBGs as well as the maximum number of CBs/CBGs for PDSCH monitoring. There may also be a joint limit on the number of CCEs of blind decoded PDCCH candidates and the number of blind-decoded CBs for PDCCH-less PDSCH or a fixed multiple of blind decoded CBs (e.g. N_{CCE} + 4*N_{CB} < 100). In this example, the WTRU may determine the limit on the number of blind-detected CBs/CBGs in a slot based on the joint limit on the number of blind-decoded CCEs, based on the configured search space, and the number of CBs/CBGs that may be specified in the standard specifications.

[0088] In another example, there may be two joint limits for the blind detection of PDCCH and PDSCH:

(1) a joint limit on the number of blind detections and CRC checks for PDCCH candidates and the number of blind detections and CRC checks for blind-decoded CBs of the PDSCH candidates (e.g. NJPDCCH} + N_{CB} < 60); or (2) a joint limit for the number of CCEs covered by blind-decoded PDCCH candidates, and the number of RBs/RBGs for the blind-decoded CBs of the PDSCH candidates (e.g. a*N_{CCE} + b*N_{ RBGs} < NJtotal}). This limit may correspond to a limit on the complexity of channel estimation for PDCCH and DCI-less PDSCH.

[0089] In general, there may be one or multiple limits to be satisfied for blind detection of PDCCH and DCI-less PDSCH in a slot, where each of those limits may be based on one or multiple of the following parameters in that slot: a number of blind-decoded PDCCH candidates, a number of distinct CCEs covered by blind-decoded PDCCH candidates, a number of blind decoded PDSCH candidates, a number of blind-decoded CBs or CBGs associated with the blind-decoded PDSCH candidates, a number of distinct RBs or RBGs covered by blind-decoded PDSCH candidates, a number of distinct RBs or RBGs covered by blind-decoded CBs of the PDSCH candidates, a number of distinct RBs covered by blind-decoded CBGs of the PDSCH candidates, or a number of distinct RBGs covered by blind-decoded CBs of the PDSCH candidates.

[0090] FIG. 4 shows an example of a WTRU-based procedure for this method. This approach may be used, for instance, when two different types of downlink traffic are supported by the WTRU. As shown in FIG. 4, at step 410, a WTRU may receive higher layer signaling indicating the PDSCH candidates, a maximum number of CBGs per TB, and a configuration of PDCCH search spaces. At step 420 the WTRU may determine the limit on the number of RBs/RBGs of the blind-decoded CBs for PDSCH candidates based on the joint limit on channel estimation complexity of PDCCH and DCI-less PDSCH. The WTRU may subtract the number of CCEs covered by the associated search spaces in the slot. In other cases, similar limits may be applied, for example, for a span of slots, symbols, CBs, CBGs or TBs. In step 430, the WTRU may determine the limit on the number of blind-decoded CBs for PDSCH candidates, based on the joint limit on the number of PDCCH and PDSCH blind-decodes. Again, the WTRU may subtract the number of CCEs covered by the associated search spaces in the slot. At step 440, the WTRU may select the subset of PDSCH candidates that satisfies the limit on the number of blind-decoded CBs and associated RBs/RBGs, based on their indices and their number of CBGs. The WTRU may perform blind detection on the first CBs of the CBGs of PDSCH candidates in step 450. At step 460, if the CRC passes, the WTRU may continue decoding of CBGs. If the CRC does not pass, the WTRU may end the blind detection of the PDSCH candidate.

[0091] Another approach for blind detection with reduced complexity is to take advantage of the presence of configured WTRU-specific DMRS sequence(s). In an example, a WTRU may attempt to detect the assigned WTRU-specific DMRS in each of the PDSCH frequency-time regions for which the WTRU has been configured for DCI-less PDSCH transmission. If the WTRU does not detect any of the configured DMRS sequences with high certainty, then the WTRU may assume there is no DCI-less PDSCH; otherwise the WTRU may continue the blind detection procedure.

[0092] In another example, multiple DMRS sequences may be assigned to the WTRU where the presence of each sequence may indicate that a DCI-less PDSCH is scheduled for the WTRU. For instance, a WTRU may be configured for DCI-less PDSCH transmission with four MCS values, and the WTRU may determine that each of the DMRS sequences is mapped to one of the four MCS values. A WTRU may attempt to detect the assigned WTRU-specific DMRS sequences in each of the PDSCH frequency-time regions for which the WTRU is configured. If the WTRU detects any of the configured DMRS sequences with high certainty, then the WTRU may assume there is a DCI- less PDSCH and the detected DMRS sequence is mapped to the value of the assigned parameter. In another approach, the WTRU may put in order more than one value for the assigned DCI parameter where the values may be ordered according to the reliability of the detected associated DMRS sequence. Therefore, if the WTRU detects one or more of the configured DMRS sequences with an acceptable level of reliability, then the WTRU may place the values of the DCI parameter in an ordered set where the value associated with a higher-reliability DMRS sequence is at the top of the ordered set. The WTRU may continue the detection of the PDSCH with the DCI parameter value that is associated with highest reliable DMRS sequence; if a PDSCH with checked CRC is not detected, the WTRU may choose the second value for the DCI parameter that is associated with the second most reliable DMRS sequence and so on. However, if a WTRU detects a sequence that is unique from the configured set of sequences, the WTRU may construe this sequence as an indication that a DCI parameter that corresponds to the PDSCH transmission exists.

[0093] In this method, a group-common PDCCH (GC-PDCCH) may be used to indicate the activeness of configured PDSCH candidates, or a subset of the configured PDSCH candidates in a slot. This method may be useful, for instance, when different sporadic downlink transmissions are intended for different WTRUs but their timing might be correlated or simultaneous, such as certain event-based individual downlink data for a group of WTRUs .

[0094] In an embodiment, a group common DCI , which may be called a data monitoring indicator or DMI, may be used to dynamically indicate a subset of configured PDSCH candidates in a slot or in multiple consecutive slots. A DMI may be sent by a specified DCI format that may be scrambled based on its own specific RNTI (e.g. DMI-RNTI). A DMI may also be attached to another group- common DCI. For example, a DMI may be combined with an SFI or implicitly interpreted based on the configured table for an SFI. [0095] In one example, a DMI may comprise a one-bit flag indicating activation or deactivation of the blind detection of configured PDSCH candidates in the associated slot or slots. In another example, a DMI may indicate one or multiple active PDSCH candidates. In another example, a DMI may indicate the monitoring occasion inside the slot or a group of associated slots.

[0096] FIG. 5 provides an example procedure by which the WTRU may determine to blind decode its configured PDSCH candidates or monitor its configured WTRU-specific PDCCH search space based on the DMI flag. At step 510, the WTRU may receive higher layer signaling indicating a number of PDCCH search spaces and PDCCH-less PDSCH candidates. At step 520, the WTRU may receive a GC-PDCCH containing a DMI flag. At step 530, the WTRU may determine whether the DMI indicates a specific a subset of configured PDSCH candidates. If not, at step 540(a), the WTRU may monitor one or more WTRU-specific PDCCHs based on the configured search spaces before receiving, in step 545, the PDSCH as scheduled by the PDCCH. If, at step 530, the WTRU determines that the DMI has enabled blind decoding, then instead at step 540(b), the WTRU may perform blind detection on the configured PDSCH candidates.

[0097] In another example, the activeness of PDSCH blind detection, as indicated by DMI, may reduce the number of active monitored WTRU-specific search spaces, based on a specified joint limit on the number of blind-decoded CBs and CCEs.

[0098] Processes for blind detection as applied to a subset of configured PDSCH candidates and shown in FIG. 6, are provided herein. Assuming that the DMI enables blind detection, at step 610, the WTRU may determine a number of blind decodes for each of the PDSCH candidate. At step 620, the WTRU may compare the PDSCH blind decodes and their corresponding number of blind decoded CBs with the joint limits on the blind detection of PDSCH and PDCCH. In doing so, the WTRU may consider the number of blind decoded CBs that correspond to the PDSCH candidates and/or the active PDCCH candidates and their corresponding number of CCEs that are blind decoded in that slot. At step 630, the WTRU may select a subset of the PDSCH candidates that satisfy the joint blind detection limits— for instance, according to the index and/or priority— as the active PDSCH candidates in that slot. At step 640, the WTRU may then perform blind detection on the active PDSCH candidates in the slot by first blind-decoding a predefined number of its CBs. If, during this step, the WTRU determines at least a part of a subset of CBs from an intended transmission are detected, the WTRU may continue decoding of the entire PDSCH candidate.

[0099] FIG. 7 provides an example of a process for blind detection carried out according to the rules described above. As shown in FIG. 7, a WTRU may receive an indication to monitor four

PDSCH candidates 710, 720, 730, and 740. PDSCH candidate 710 may have two CBGs 71 1 and 712, and each CBG may have CBs (a) through (c). PDSCH candidate 720 may have two CBGs 721 and 722, each with two CBs (a) and (b). Candidate 730 may also have two CBGs 731 and 732, each with two CBs (a) and (b). Finally, PDSCH candidate 740 may have two CBGs 741 and 742, and each CBG may have CBs (a) through (c). In this example, the WTRU may determine the number of CB blind decodes by adding the total number of CBs— in this case, 20. Subsequently, the WTRU may compare the PDSCH blind decodes with a joint limit on the PDSCH and PDCCH blind decodes within the slot by subtracting the number of PDSCH blind decodes. Here, assuming the WTRU has determined the joint limit on the PDSCH and PDCCH blind decodes is 24, the WTRU will determine the maximum number of CB blind decodes by subtracting 20 from 24 to reach 4. Thus, in this example, the WTRU must select a subset of the PDSCH candidates that will not require the WTRU to conduct blind decoding on more than 4 CBs. Beginning with the first PDSCH candidate 710, the WTRU may attempt blind decoding on each of the first CBs (a) of each CBG 71 1 and 712. Given that both decoding instances fail, the WTRU may abort decoding and attempt decoding for the next PDSCH candidate 720. Again, the WTRU may apply the above procedures to each of the first CBs (a) of the first and second CBGs 721 and 722. Assuming decoding of CB 721 (a) fails, but decoding of CB 722(a) passes, the WTRU may continue decoding of candidate 720. Here, because the WTRU has attempted 4 CB blind decodes, PDSCH candidates 730 and 740 are dropped from the blind detection procedures.

[0100] Semi-Persistent Scheduling (SPS)-based procedures may enable reception of PDSCH transmissions without WTRU-specific scheduling. To enable signaling for multi-traffic PDCCH-less downlink data reception, methods described herein may be used. In an embodiment, each SPS may be allocated to a separate Cell Radio Network Temporary Identifier (C-RNTI) and, thus, a WTRU may be configured with multiple SPS C-RNTIs. In one example, a separate configuration may be made for each use case (e.g. eMBB or URLLC) or for each traffic type within a use case, such as high priority and/or low priority mMTC. For SPS-based PDSCH reception, a WTRU may monitor a PDCCH using each SPS C-RNTI independently to identify when an SPS is activated or deactivated. This may increase the PDCCH monitoring load on the WTRU and may require reduced PDCCH monitoring methods such as those discussed

[0101] In an embodiment, the WTRU may be allocated a single C-RNTI with multiple sub-RNTIs mapping to multiple sub_SPSs. The SPS C-RNTI may be modified to contain multiple SPS subconfigurations that identify the use cases or traffic types. The configuration may include parameters that identify the number of SPS sub-configurations available and/or identify if a specific SPS subconfiguration is active. [0102] Both options may include information identifying the relative priority of an SPS subconfiguration. The information may be transmitted implicitly. If the relative priority is transmitted implicitly, the priority may be ordered by a property of the configuration, such as periodicity. In one example, a smaller periodicity implies higher priority, as in URLLC implementations, for example. In another example, the information may be transmitted explicitly. In this case, a priority parameter may be configured , such as when priority is provided as a fixed set of numbers with a higher or lower number indicating a lower or higher priority.

[0103] One or more issues with having more than one active SPS resource may occur if there is a collision of resources for different configurations. In this case, the WTRU may have to decode multiple SPS configurations, resulting in an unnecessary increase in complexity. To resolve this, one or more of several rules may be considered. In one system, the gNB ensures that no collision between multiple configurations and their repetition locations occurs. For example, the configurations may be setup on orthogonal resources by BWP and/or frequency. In this system, the WTRU may be required to check all possible configurations. In another system, the gNB does not prevent collisions, but may still be required to check all possible SPS configurations.

[0104] In yet another example, gNB limits collisions by way of a rule-based or priority-based transmission decide which resources correspond to each resource. Here, the WTRU may use a drop-decoding rule based on the gNB rules to decode a subset of the configurations and drops the rest. For instance, the WTRU may decode the configuration with the higher priority and drop decoding of a configuration with a lower priority. In another example, the WTRU may decode the configuration with a lower or higher retransmission number in that resource and drop decoding of the configuration with the higher or lower retransmission number. If one configuration is provided for an initial transmission and one is provided for re-transmission, the WTRU may decode the configuration pertaining to an initial transmission (or a re-transmission, depending on the rule) regardless of priority.

[0105] In another example, the WTRU may check for a configuration with a higher number of retransmissions in that resource. The WTRU may apply any combination of rules. For example, if two configurations pertain to initial transmissions, a WTRU may check use higher priority traffic type to avoid a collision of resources.

[0106] A WTRU that is configured for multiple SPS/CS resources may follow the following procedures. For instance, a WTRU may receive a first configuration (e.g. SPS-CRNTI 1) via RRC. The WTRU may then receive a second configuration (e.g. SPS-CRNTI2) via RRC. The WTRU may start PDCCH monitoring using multiple configurations. The WTRU may then receive a PDCCH transmission for configuration 1 , activating or deactivating SPS 1 , in a time interval or slot. In one case, multiple PDCCH configurations may be enabled for each time interval. The WTRU may continue to monitor the PDCCH for configuration 2 in the same time interval or slot. The WTRU may then receive a PDCCH transmission for configuration 2 (activating SPS 2) in the same slot. In another case, a single PDCCH configuration may be enabled for each time interval. Here, the WTRU may stop PDCCH monitoring as only one PDCCH is sent per time interval or slot.

[0107] For downlink transmissions, systems also enable single or multiple Configured Scheduling configurations. The procedures discussed above may apply to downlink CS. Methods for resource allocation for PDSCH reception with configured scheduling are provided herein. According to these embodiments, the WTRU may semi-statical ly be configured by a higher layer (e.g., parameter ConfiguredScheduleConfig) with a resource allocation for PDSCH reception with configured scheduling.

[0108] In one example, the WTRU may receive and apply one or more of several parameters from a higher layer for PDSCH reception when the WTRU is configured for PDSCH reception with configured scheduling. For instance, the WTRU may apply a time domain offset. A higher layer parameter (e.g., pdsch-TimeDomainOffsef) may indicate an offset for downlink data reception with configured scheduling related to a prespecified System Frame Number (e.g., SFN=0). The WTRU may apply a time domain allocation. In this case, the higher layer parameter (e.g., pdsch- TimeDomainAllocation) may indicate a combination of start symbol, length and mapping type for PDSCH reception with configured scheduling. The WTRU may apply a frequency domain allocation. The higher layer parameter (e.g., pdsch-FrequencyDomainAllocation) may indicate a frequency domain resource assignment for PDSCH reception with configured scheduling. The WTRU may apply parameters for a modulation and coding scheme and TB size. The higher layer parameter (e.g., pdsch-McsAndTBS) may indicate the modulation order, target code rate and TB size for PDSCH reception with configured scheduling. The WTRU may apply a redundancy version. The higher layer parameter (e.g., pdsch-RV) may define a redundancy version pattern to be applied to the repetitions of the PDSCH if the WTRU is configured by a higher layer with downlink data repetitions. The WTRU may specify one or more antenna ports. The higher layer parameter (e.g., pdsch-AntennaPort) may indicate the antenna port(s) for PDSCH reception with configured scheduling The WTRU may specify a transmission configuration indication. The higher layer parameter (e.g., pdsch-TCI) may indicate antenna port quasi co-location (QCL) relationships between the DL Reference Symbols (RSs) in one RS set and PDSCH Demodulation Reference Symbol (DM-RS) ports from a list of configured TCI states (e.g., tci-StatesToAddModLisf). The WTRU may apply a DMRS sequence initialization. The higher layer parameter (e.g., pdsch-DMRS- Seqlnitialization) may indicate a scrambling ID for DM-RS sequence initialization for PDSCH reception with configured scheduling, when multiple scrambling IDs have been configured in DMRS configuration by a higher layer (e.g., DMRS-DownlinkConfig).

[0109] For PDSCH reception with configured scheduling, if the WTRU detects a PDSCH in slot n, the WTRU may provide the corresponding HARQ-ACK information in a PUCCH transmission within slot n + /( where k is provided by a higher layer (e.g., parameter dl-DataToUL-ACK). For PDSCH a reception with configured scheduling, the WTRU may determine a PUCCH resource for a corresponding HARQ-ACK information transmission from a parameter provided by a higher layer (e.g., parameter n1PUCCH-AN). The WTRU may not decode a PDSCH scheduled by higher layer when it partially or fully overlaps in time with another PDSCH transmission scheduled dynamically by a DCI where its CRC is scrambled with CS-RNTI in the same cell (e.g., the primary cell).

[01 10] URLLC messages may be transmitted or received via a PDCCH channel using various methods. Hereafter, the term “URLLC message” may be interchangeably used with a “URLLC PDSCH,”“a transport block,”“a message,”“a URLLC message,”“a packet,”“or a URLLC packet.”

[01 1 1] In an example, a WTRU may monitor, attempt to decode, or receive a URLLC message (e.g., a transport block) in a search space of PDCCH, wherein the search space may be configured with a search space for the URLLC message reception. One or more of following circumstances may apply. For instance, a WTRU may monitor one or more types of PDCCH search space, wherein the WTRU may monitor or attempt to decode a downlink control information (DCI) in a first type of PDCCH search space and the WTRU may monitor or attempt to decode a transport block in a second type of PDCCH search space. In this case, a WTRU may send an associated HARQ-ACK when the WTRU received a transport block in the second type of PDCCH search space while the WTRU may not send an associated HARQ-ACK if the WTRU received a DCI. If the WTRU received a DCI in a first type of PDCCH search space, the DCI may be used for an associated PDSCH reception or PUSCH transmission.

[01 12] A subset of aggregation level (AL) candidate values of the first type of search space may be used for the second type of search space. For example, a WTRU may be configured with a set of ALs from the AL candidate values (e.g., {1 , 2, 4, 8, 16}) for the first type of search space while the WTRU may be configured with a set of ALs from the subset of the AL candidate values (e.g., {4, 8, 16}). In an embodiment, a single AL may be used for the second type of search space and one or more ALs may be used for the first type of search space. The largest AL among the AL candidate values may be used for the second type of search space. [01 13] The size of the transport block which may be monitored or received in a PDCCH search space may be determined based on one or more of following: a time and/or frequency location of the search space, an identity of the PDCCH decoding candidate, a higher layer configuration, an RNTI scrambled in the CRC, an REG bundle size, an aggregation level of the PDCCH decoding candidate, a number of RBs configured for an associated CORESET, or a scrambling identity which may be used for the transport block.

[01 14] If a higher layer configuration is used to determine the transport block size, the search space configuration may include one or more transport block sizes which may be monitored or received in the PDCCH search space. If the actual transport block size is smaller than the configured transport block size, one or more zero bits may be padded at the first or end of the transport block. If an RNTI is scrambled in the CRC, one or more RNTIs may be used and each RNTI may be associated with a transport block size.

[01 15] A HARQ process number of the transport block which may be monitored or received in a PDCCH search space may be determined based on one or more indicators, exemplified as follows. The HARQ process number may be determined from a time location of the search space within a slot. For example, if a WTRU received the transport block in the search space located in a first time location in a slot (e.g., a first symbol in a slot), a first HARQ process number may be used. If the WTRU received the transport block in the search space located in a second time location in a slot (e.g., a third symbol in a slot), a second HARQ process number may be used.

[01 16] The HARQ process number may be determined based on an RNTI scrambled in the CRC. Here, for example, one or more RNTIs may be used and each RNTI may be associated with a HARQ process number. The HARQ process number may be determined based on a scrambling identity which may be used for the transport block.

[01 17] In another example, a WTRU may be configured to monitor, attempt to decode, or receive a URLLC message (e.g., a transport block) in a PDCCH search space configured to monitor one or more DCIs. One or more of following circumstances may apply. A DCI payload may carry one or more information types, wherein a first information type may be a control information and a second information type may be a transport block. A WTRU may determine the information type of the DCI payload based on at least one of several indicators.

[01 18] In one example, an RNTI scrambled with a CRC may indicate the information type of the DCI payload. For example, two RNTIs may be used and if a WTRU detects a first RNTI, the WTRU may determine that a first information type is carried in the DCI and if the WTRU detects a second RNTI, the WTRU may determine that a second information type is carried in the DCI.

[01 19] In another, a bit flag at the beginning of the DCI payload may indicate the information type. For example, if the bit flag indicates“TRUE,” a first information type may be carried in the DCI payload ,and if the bit flag indicates“FALSE,” a second information type may be carried in the DCI payload.

[0120] In another example, a PDCCH decoding candidate may indicate the information type. A DCI payload may carry a first information type in a first subset of PDCCH decoding candidates in a search space, and a DCI payload may carry a second information type in a second subset of PDCCH decoding candidates.

[0121] In yet another example, a time location may indicate the information type. For example, a DCI payload may carry a first information type in a first time instance of the search space, and a DCI payload may carry a second information type in a second time instance.

[0122] In another example, a transport block for URLLC may be transmitted via a PDCCH or a PDSCH based on the transport block size. If the transport block size for a URLLC transport block is smaller than a threshold, a WTRU may monitor, attempt to decode, or receive the transport block in a PDCCH. If the transport block size is larger than the threshold, the WTRU may monitor, attempt to decode, or receive the transport block in a PDSCH which may be scheduled by a DCI. The threshold may be determined based on at least one of: a WTRU coverage level (e.g., L1-RSRP or pathloss), a maximum aggregation level of the PDCCH, a higher layer configuration, or a WTRU capability.

[0123] An RNTI may be used to determine which downlink channel (e.g., PDCCH or PDSCH) is used for the transport block transmission. A first RNTI scrambled with a CRC of a DCI may indicate that the transport block is transmitted in the DCI and a second RNTI scrambled with a CRC of a DCI may indicate that the PDSCH scheduling information of the transport block is transmitted in the DCI.

[0124] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated 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, a read only memory (ROM), a random access memory (RAM), a register, 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 digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMS What is Claimed:

1. A method for scheduling and receiving a downlink data transmission comprising: receiving a higher layer configuration for one or more Physical Downlink Shared Channel (PDSCH) candidates, each PDSCH candidate being associated with one or more Code Blocks (CBs) or Code Block Groups (CBGs); monitoring a Physical Downlink Control Channel (PDCCH) search space for a transmission on a Group-Common Physical Downlink Control Channel (GC-PDCCH), wherein the transmission includes a Downlink Monitoring Indication (DMI) flag; determining, from the DMI flag, to attempt blind decoding for one or more CBs or CBGs associated with the PDSCH candidates; comparing the CBs or CBGs with one or more joint limits on a total number of CBs or CBGs for which to attempt blind decoding; selecting, based on the one or more joint limits, a subset of PDSCH candidates for which blind decoding of the CBs or CBGs will not exceed the one or more joint limits; and attempting blind decoding on one or more CBs or CBGs in the selected subset of PDSCH candidates.

2. The method of claim 1 , wherein the one or more joint limits are determined based on at least one of: a number of active PDCCH candidates, a number of Control Channel Elements (CCEs) corresponding to the number of active PDCCH candidates, a number of active PDSCH candidates, or a number of blind decoded CBs corresponding to the active PDSCH candidates.

3. The method of claim 1 , wherein the one or more joint limits provides a total number of CBs or CBGs within a slot for which to attempt blind decoding.

4. The method of claim 1 , further comprising selecting a subset of PDSCH candidates for blind decoding based on a maximum number of Resource Blocks (RBs) or Resource Block Groups (RBGs) covered by the CBs or CBGs of each PDSCH candidate.

5. The method of claim 1 , wherein selecting a subset of PDSCH candidates is further based on one of an index of a carrier, an index of a bandwidth part (BWP), an index of the PDSCH candidate, or a priority of the PDSCH candidate.

6. The method of claim 1 , wherein attempting blind decoding involves decoding a first CB of a CBG associated with a PDSCH candidate, performing a Cyclic Redundancy Code (CRC) check, and, on a condition that the CRC check succeeds, decoding a subsequent CB in the CBG.

7. The method of claim 1 , wherein blind detection of an individual PDSCH candidate is aborted when blind detection fails for a predetermined number of CBs or CBGs in the PDSCH candidate.

8. The method of claim 1 , wherein the DMI includes an indication of one or more active PDSCH candidates.

9. A wireless transmit/receive unit (WTRU) comprising:

a processor; and a receiver, the processor and receiver configured to: receive a higher layer configuration for one or more Physical Downlink Shared Channel (PDSCH) candidates, each PDSCH candidate being associated with one or more Code Blocks (CBs) or Code Block Groups (CBGs); monitor a Physical Downlink Control Channel (PDCCH) search space for transmission on a Group-Common Physical Downlink Control Channel (GC-PDCCH), wherein the transmission includes a Downlink Monitoring Indication (DMI) flag; determine, from the DMI flag, to attempt blind decoding for one or more CBs or CBGs of the PDSCH candidates; compare the CBs or CBGs with one or more joint limits on a total number of CBs or CBGs for which to attempt blind decoding; select, based on the one or more joint limits, a subset of PDSCH candidates for which blind decoding of the CBs or CBGs will not exceed the one or more joint limits; and attempt blind decoding on one or more CBs or CBGs in the selected subset of PDSCH candidates.

10. The WTRU of claim 9, further configured to determine the one or more joint limits based on at least one of: a number of active PDCCH candidates, a number of Control Channel Elements (CCEs) corresponding to the number of active PDCCH candidates, a number of active PDSCH candidates, or a number of blind decoded CBs corresponding to the active PDSCH candidates.

11. The WTRU of claim 9, wherein the one or more joint limits provides a total number of CBs or CBGs within a slot for which to attempt blind decoding.

12. The WTRU of claim 9, further configured to select a subset of PDSCH candidates for blind decoding based on a maximum number of Resource Blocks (RBs) or Resource Block Groups (RBGs) covered by the CBs or CBGs of each PDSCH candidate.

13. The WTRU of claim 9, configured to select a subset of PDSCH candidates is further based on one of an index of a carrier, an index of a bandwidth part (BWP), an index of the PDSCH candidate, or a priority of the PDSCH candidate.

14. The WTRU of claim 9, configured to decode a first CB of a CBG in a PDSCH candidate, perform a Cyclic Redundancy Code (CRC) check, and, on a condition that the CRC check succeeds, decode a subsequent CB in the CBG.

15. The WTRU of claim 9, wherein blind detection of an individual PDSCH candidate is aborted when blind detection fails for a predetermined number of CBs or CBGs in the PDSCH candidate.

16. The WTRU of claim 9, wherein the DMI includes an indication of one or more active PDSCH candidates.