Method and apparatus for downlink small data reception

Abstract

Methods and apparatuses for downlink small data reception. The present disclosure provides methods and apparatuses for downlink small data reception in wireless communications. In one example, a method includes receiving configuration information for small data transmission (SDT), and the configuration information indicates one or more uplink (UL) configured grants (CGs), one or more downlink (DL) CGs, and a transport block size (TBS) threshold for SDT; receiving a DL data transmission using a DL CG of the one or more DL CGs; determining a TBS, HARQ feedback, and a data radio bearer (DRB) associated with the received DL data transmission; and based on determining that the TBS associated with the received DL data transmission is less than the TBS threshold and / or the DRB associated with the received DL data transmission supports SDT, transmitting the HARQ feedback associated with the received DL data transmission using a UL CG of the one or more UL CGs.

Description

[0001] Cross-references to related applications This application claims priority and benefit to U.S. Provisional Application No. 63 / 007,027 filed with the U.S. Patent and Trademark Office on April 8, 2020, and U.S. Provisional Application No. 63 / 093,977 filed with the U.S. Patent and Trademark Office on October 20, 2020, the entire contents of each of these applications are incorporated herein by reference as if their entire contents were fully set forth below for all applicable purposes. Background Technology

[0002] Small and / or infrequent data transfers can lead to power consumption losses. For example, switching from inactive mode to connected mode to send small amounts of data can increase signaling overhead in the network and may also result in increased battery consumption. For devices supporting enhanced mobile broadband (eMBB) services, applications may have frequent background small data transfers (e.g., application refresh data, notifications, etc.), which can be periodic or non-periodic. Furthermore, sensor and Internet of Things (IoT) devices may have a considerable amount of signaling and small data transfers (e.g., periodic heartbeats or keep-alive signals, monitoring updates, periodic video streaming, motion-sensing-based non-periodic video, etc.). The need for a wireless transmit / receive unit (WTRU) to switch or transition to connected mode for such small data transfers or signaling can result in significant power consumption, especially for power- or battery-constrained sensor / IoT devices or for eMBB mobile devices designed to reduce battery consumption. Summary of the Invention

[0003] Methods, systems, apparatus, and techniques for downlink small data transmission and / or reception in wireless communications are provided. In one example, the method for wireless communication (e.g., implemented by a WTRU) includes receiving configuration information for small data transmission (SDT), and the configuration information indicates one or more uplink (UL) configuration grants (CGs), one or more downlink (DL) CGs, and a transport block size (TBS) threshold for the SDT. The method includes receiving DL data transmission using one of the one or more DL CGs. The method also includes determining the TBS, HARQ feedback, and data radio bearer (DRB) associated with the received DL data transmission. The method further includes transmitting the HARQ feedback associated with the received DL data transmission using one of the one or more UL CGs based on determining that the TBS associated with the received DL data transmission is less than the TBS threshold and / or the DRB associated with the received DL data transmission supports the SDT.

[0004] In another example, a method for wireless communication (e.g., implemented by a WTRU) includes monitoring the Physical Downlink Control Channel (PDCCH) for either receiving DL assignment and control signaling after the UL SDT. The method includes triggering a DL small data transmission process upon receiving a trigger signal, and monitoring a subset of one or more DL CGs for DL ​​assignment based on any of the following: Reference Signal Received Power (RSRP), TBS, or UL time alignment. The method also includes initiating random access (RA) to transition to connected mode based on any of the following: subsequent DL data reception, small data reception including negative acknowledgment (NACK), or the TBS being greater than or equal to a TBS threshold. The method further includes starting a PDCCH monitoring timer for retransmission after a small data reception including at least a NACK. Attached Figure Description

[0005] A more detailed understanding can be obtained from the following detailed description, which is given by way of example in conjunction with its accompanying drawings. As with the detailed description, the figures in such drawings are illustrative. Therefore, the drawings and specific embodiments should not be considered limiting, and other equally effective examples are possible and contemplated. Furthermore, similar reference numerals in the drawings indicate similar elements, and wherein: Figure 1A This is a system diagram illustrating an exemplary communication system that can be implemented in one or more of the disclosed embodiments; Figure 1B This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown; Figure 1C This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown; Figure 1D This illustrates that, according to one implementation scheme, it is possible to Figure 1A The system diagram shown illustrates another exemplary RAN and another exemplary CN used within the communication system; and Figure 2 This is a flowchart illustrating an exemplary process for receiving downlink small data according to one or more embodiments. Detailed Implementation

[0006] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, the embodiments and other examples expressly, implicitly, and / or inherently described, disclosed, or otherwise provided herein (collectively, the “Provided”). Although various embodiments are described and / or claimed herein, in which apparatuses, systems, devices, etc., and / or any elements thereof perform operations, processes, algorithms, functions, etc., and / or any part thereof, it should be understood that any embodiment described herein and / or protected by the claims presupposes that any apparatus, system, device, etc., and / or any element thereof is configured to perform any operation, process, algorithm, function, etc., and / or any part thereof.

[0007] The methods, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. Wired networks are well-known. Compared to... Figures 1A to 1D An overview of various types of wireless devices and infrastructures is provided, wherein various elements of the network may utilize, perform, be arranged according to, and / or be adapted to and / or configured with respect to the methods, apparatuses and systems provided herein.

[0008] Figure 1A This is a schematic diagram illustrating an exemplary communication system 100 that can be implemented in one or more of the disclosed embodiments. Communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word Discrete Fourier Transform Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0009] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 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 user equipment (UE), mobile stations, fixed or mobile user units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0010] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, Internet 110, and / or other networks 112. As examples, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, evolved Node Bs (eNBs), home Node Bs, home evolved Node Bs, next-generation NodeBs such as gNode Bs (gNBs), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0011] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a specific geographic area, which may be relatively fixed or changeable over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in an embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0012] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

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

[0014] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0015] In one implementation, base station 114a and WTRUs 102a, 102b, 102c can enable radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0016] In the implementation scheme, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for example, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0017] In other implementations, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rate Evolution (EDGE), and GSM EDGE (GERAN).

[0018] Figure 1ABase station 114b can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106.

[0019] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to RAN 104 which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA or WiFi radio technology.

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

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

[0022] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that, while remaining consistent with the implementation, WTRU 102 may include any sub-combination of the foregoing elements.

[0023] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0024] Transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 may be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 may be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0025] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0026] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. For example, transceiver 120 may therefore include multiple transceivers to enable WTRU 102 to communicate via various RATs such as NR and IEEE 802.11.

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

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

[0029] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may acquire location information using any suitable location determination method.

[0030] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth.® Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors. Sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0031] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for 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 for reducing and / or substantially eliminating self-interference through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception)) are concurrent.

[0032] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0033] RAN 104 may include evolved Nodes B 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Nodes B while remaining consistent with the implementation scheme. Evolved Nodes B 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In the implementation scheme, evolved Nodes B 160a, 160b, and 160c may implement MIMO technology. Therefore, evolved Node B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0034] Each of the evolved nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the UL and / or DL, etc. Figure 1C As shown, evolution nodes B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0035] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0036] The MME 162 can connect to each of the evolved nodes B 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0037] The SGW 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to and from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-evolved Node B handovers, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0038] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0039] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0040] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is conceivable that in some representative implementations, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0041] In a representative implementation, the other network 112 may be a WLAN.

[0042] A WLAN in Infrastructure Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more sites (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 to and / or carries traffic out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative implementations, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using Standalone BSS (IBSS) mode may not have access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. IBSS communication mode may sometimes be referred to as "ad-hoc" communication mode in this document.

[0043] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz wide bandwidth) or dynamically configured. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative implementations, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA (including the AP) can listen to the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0044] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0045] The Very High Throughput (VHT) STA supports channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be processed by a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. These streams can be mapped to two 80MHz channels, and data can be transmitted via the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to Media Access Control (MAC).

[0046] 802.11af and 802.11ah support operating modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative implementations, 802.11ah may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., only support) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain a very long battery life).

[0047] WLAN systems supporting multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. A primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS (each supporting a minimum bandwidth operating mode). In the 802.11ah example, for STAs supporting (e.g., only supporting) a 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (supporting only the 1MHz operating mode) is transmitting to the AP, all available frequency bands can be considered busy even if most available bands remain idle.

[0048] In the United States, the available frequency bands for 802.11ah are 902MHz to 928MHz. In South Korea, the available frequency bands are 917.5MHz to 923.5MHz. In Japan, the available frequency bands are 916.5MHz to 927.5MHz. The total available bandwidth for 802.11ah ranges from 6MHz to 26MHz, depending on the country code.

[0049] Figure 1D This is a system diagram illustrating RAN 104 and CN 106 according to one implementation scheme. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 104 can also communicate with CN 106.

[0050] RAN 104 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 104 may include any number of gNBs while remaining consistent with the implementation scheme. Each gNB 180a, 180b, and 180c may include one or more transceivers for communication with WTRUs 102a, 102b, and 102c via air interface 116. In the implementation scheme, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In the implementation scheme, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to 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 the implementation scheme, gNBs 180a, 180b, and 180c can implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0051] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with an scalable set of parameters. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0052] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., evolved Node Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate or connect to gNBs 180a, 180b, and 180c, and also communicate or connect to other RANs (such as evolved Node Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more evolved Node Bs 160a, 160b, and 160c. In a non-standalone configuration, evolved Node Bs 160a, 160b, and 160c can be used as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0053] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interoperability between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0054] Figure 1DThe CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0055] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c via the N2 interface in RAN 104 and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra-Reliable Low Latency (URLLC) access, services that rely on Enhanced Mobile Broadband (eMBB) access, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between 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.

[0056] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0057] UPF 184a and 184b can connect via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 104. These gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring.

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

[0059] Given Figures 1A to 1D as well as Figures 1A to 1D The corresponding descriptions herein refer to one or more of the functions described below, which may be performed by one or more emulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein. An emulation device may be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0060] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, the one or more simulation devices may perform 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 to test other devices within the communication network. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or use over-the-air wireless communication to perform tests.

[0061] The one or more simulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation devices may be used in test scenarios within a test laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. The one or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via an RF circuit system (e.g., which may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

[0062] Small and / or infrequent data transfers can lead to power consumption losses. For example, switching from inactive mode to connected mode to send small amounts of data can increase signaling overhead in the network and may also result in increased battery consumption. For devices supporting enhanced mobile broadband (eMBB) services, applications may have frequent background small data transfers (e.g., application refresh data, notifications, etc.), which can be periodic or non-periodic. Furthermore, sensor and Internet of Things (IoT) devices may have a considerable amount of signaling and small data transfers (e.g., periodic heartbeats or keep-alive signals, monitoring updates, periodic video streaming, motion-sensing-based non-periodic video, etc.). The need for a wireless transmit / receive unit (WTRU) to switch or transition to connected mode for such small data transfers or signaling can result in significant power consumption, especially for power- or battery-constrained sensor / IoT devices or for eMBB mobile devices designed to reduce battery consumption.

[0063] Two-step random access (RA) and configuration authorization (CG) can be enabled in NR, UL and / or DL ​​small data transmission without switching to connected mode.

[0064] Implementation schemes for data transmission without WTRU-initiated state transitions for both UL and DL are provided. For example, the state can be set to "No new Radio Resource Control (RRC) state should be introduced in this WID. Transmission of small data in UL, subsequent transmission of small data in UL and DL, and state transition decisions should all be network-controlled." One or more implementation schemes may include the use of 2-step RA, 4-step RA, and / or Configuration Authorization (CG) in inactive states / modes.

[0065] The WTRU context in RRC_INACTIVE can include configurations for radio bearers, logical channels, and security information. WTRUs can retain all or part of their context in inactive and / or idle modes. Some data radio bearers (DRBs) can be paused in inactive or idle modes.

[0066] As applied herein, in one or more implementations, an inactive (or INACTIVE) state may be interchanged with an inactive (or INACTIVE) mode and / or “INACTIVE”.

[0067] As applied herein, in one or more implementations, the idle (or IDLE) state may be interchanged with the idle (or IDLE) mode and / or “IDLE”.

[0068] As applied herein, in one or more implementations, the connected (or CONNECTED) state may be interchanged with the connected (or CONNECTED) mode and / or “CONNECTED”.

[0069] As used herein, channel state information (CSI) may include at least one of the following: channel quality index (CQI), rank indicator (RI), precoding matrix index (PMI), L1 channel measurement (e.g., reference signal received power (RSRP), such as L1-RSRP, or SINR), CSI-RS resource indicator (CRI), SS / PBCH block resource indicator (SSBRI), layer indicator (LI), and / or any other measurement obtained by the WTRU from the configured CSI-RS or SS / PBCH block.

[0070] As used herein, uplink control information (UCI) may include CSI, Hybrid Automatic Repeat Request (HARQ) feedback for one or more HARQ processes, scheduling request (SR), link recovery request (LRR), CG-UCI, and / or other control information bits that may be transmitted on PUCCH or PUSCH.

[0071] As applied herein, channel conditions may include any conditions related to the state of the radio / channel, which may be determined by the WTRU based on: WTRU measurements (e.g., L1 / SINR / RSRP, CQI / modulation and coding scheme (MCS), channel occupancy, RSSI, power margin, exposure margin); L3 / mobility-based measurements (e.g., RSRP, RSRQ); radio link monitoring (RLM) status; and / or channel availability in unlicensed spectrum (e.g., based on LBT process determination, whether the channel is occupied, or whether the channel is considered to have undergone a consistent LBT failure).

[0072] As used herein, Physical Random Access Channel (PRACH) resources may include PRACH resources (e.g., in terms of frequency), PRACH timing (RO) (e.g., in terms of time), preamble format (e.g., based on total preamble duration, sequence length, guard time duration, and / or based on the length of the cyclic prefix), and / or a preamble sequence used to transmit the preamble during random access (RA) procedures.

[0073] As applied herein, small data may include UL-SCH data (e.g., non-CCCH) transmitted by the WTRU in a non-connected mode (including, for example, IDLE and / or INACTIVE modes).

[0074] As used in this paper, MsgA can include preamble and payload transmission on PRACH and Physical Uplink Shared Channel (PUSCH) resources respectively in a 2-step RA process.

[0075] As used herein, MsgB may include a downlink response to MsgA, which may be a successful random access response (RAR), a fallback RAR, or a fallback indication.

[0076] As applied herein, the characteristics of scheduling information (e.g., uplink grant or downlink assignment) may include at least one of the following: frequency allocation; an aspect of time allocation, such as duration; priority; modulation and coding scheme; transport block size; number of spatial layers; number of transport blocks to be carried; TCI status or SRI; number of repetitions; and / or whether the grant is a configuration grant type 1, type 2, or dynamic grant.

[0077] The indication of DCI may include at least one of the following: an explicit indication of the CRC used to mask the Physical Downlink Control Channel (PDCCH) via the DCI field or Radio Network Identifier (RNTI); and / or an implicit indication via characteristics such as DCI format, DCI size, coreset or search space, aggregation level, and the identifier of the first control channel resource for DCI (e.g., the index of the first CCE), wherein the mapping between characteristics and values ​​may be signaled by RRC or MAC.

[0078] This article discloses small downlink data transmission and related aspects. Switching the control plane connectivity state from IDLE or inactive mode to connected mode to send or receive small amounts of user plane data for dedicated radio bearers (DRBs or SRBs) can lead to increased signaling overhead in the network and increased battery consumption of the WTRU.

[0079] It would be beneficial for the WTRU to be able to switch to different connectivity states or different power usage / power saving modes to receive variable small data in the downlink direction.

[0080] In 3GPP, downlink reception of user plane data for dedicated radio bearers (such as DRBs, SRBs) may not be supported when not in RRC connection mode. Therefore, techniques that support downlink data reception in idle or inactive modes are desirable to enable downlink transmission of small amounts of unicast data.

[0081] In various implementation schemes, DL scheduling for small data transmissions can be implemented. WTRU-triggered DL small data scheduling can be implemented, allowing the gNB to transmit DL small data in response to UL small data and / or control signaling sent by the WTRU during the RA process, and vice versa. As disclosed herein, this process can be implemented for inactive or idle modes.

[0082] During PDCCH / Physical Downlink Shared Channel (PDSCH) resource monitoring, the WTRU can optionally exchange both UL and DL small data, UL only, or DL ​​only during small data transmission processes. This process may or may not involve preamble transmission. The WTRU can also predict the reception of DL small data or control signaling in response to the transmitted UL small data. The WTRU can monitor PDCCH with specific characteristics based on previous UL small data transmissions and / or based on the PRACH / PUSCH resources used or the content of the UL small data PDU.

[0083] In one implementation, the WTRU can monitor the PDCCH following UL small data transmission on a given resource (e.g., core set, aggregation level, one or more first indices and / or search space of control channel elements for DCI decoding), for receiving a given RNTI (e.g., I-RNTI, C-RNTI, RA / MsgB-RNTI, small data-RNTI calculated by a formula as a function of the selected PRACH resource, small data-RNTI calculated by a formula as a function of the selected PUSCH resource for UL small data transmission), downlink control signaling (e.g., related to the transmitted UL data), and / or the scheduling of RAR / MsgB. This monitoring can complement conventional PDCCH monitoring for receiving RAR / MsgB in response to Msg1 / MsgA transmissions.

[0084] In one implementation, in addition to monitoring MsgB or Msg4, the WTRU can also monitor the PDCCH for downlink data reception using a specific aggregation level in the core set search space, targeting one or more first indices for control channel elements scrambled by the small data-RNTI, after data transmission in MsgA or Msg3. This process can help the network differentiate between traditional WTRUs and those capable of small data transmission. The specific aggregation level can be a characteristic of the DCI and can be the number of CCEs used to transmit control information. Its value can be, for example, 1, 2, 4, and 8. Each core set can be configured with one or more aggregation levels. If the small data-RNTI is included in MsgA / Msg3, or is an RNTI calculated based on the selected PRACH and / or PUSCH time and / or the resources used to transmit the associated uplink small data, then the small data-RNTI can be a WTRU identifier.

[0085] According to another implementation, the WTRU can monitor PDCCHs with specific characteristics based on the PRACH resources used or the QoS of the transmitted UL data. The WTRU can be configured with preamble groups to indicate the expected TB size of the UL small data to be transmitted, and / or whether the UL small data is associated with DL small data (e.g., the WTRU monitors the PDCCH with the configured specific resources and / or small data-RNTI for this case). If the selected preamble and / or the selected PUSCH resources come from a configured group, if the UL TB size is greater than a threshold or within a specific range, if UL data from a certain LCH / LCG / DRB / QoS stream (e.g., on MsgA or Msg3) is transmitted, and / or if the predicted DL data size is greater than a certain threshold, the WTRU can monitor the PDCCH on the specifically configured core set, search space, and / or small data-RNTI after data transmission in MsgA or Msg3. For example, WTRU can be configured with an association between the UL small data TB size and the predicted DL small data TB, and / or a mapping or association between uplink and downlink LCH / DRB / QoS flows (e.g., for small data flows).

[0086] According to another implementation, if UL small data is transmitted on an associated PUSCH resource or uplink bearer, the WTRU can monitor PDCCH for DL ​​assignment to a specific PDSCH resource. The WTRU can monitor PDCCH signaling on a specific PDCC resource or a specific RNTI (e.g., CS-RNTI or small data-RNTI) or for downlink assignment, or by transmitting UL small data on an associated UL CG or PUSCH resource, transmitting UL small data on an associated PDSCH resource in RA, transmitting UL small data from an associated LCH / DRB / QoS flow, transmitting potentially associated control signaling (e.g., UCI, UCI on PUSCH, or control signaling during RA procedures), and / or monitoring DL assignment on a DL resource (e.g., PDSCH resource, SPS) after transmitting a preamble from a certain / associated configuration preamble group.

[0087] In one implementation, WTRU-triggered DL small data scheduling can be based on subsequent data reception. The WTRU can receive a response type (e.g., an indication in msgB, msg2, msg4, or a portion of a paging message / signaling) that may indicate additional subsequent DL data that is inactive. Upon receiving such a subsequent data indication, the WTRU can monitor one or more of, for example, additional PDCCH signaling, such as PDSCH, or downlink assignments on SPS. The response type may contain additional information about the specific resource to be monitored, and / or the monitoring duration, for example, subject to the duration of a timer or within a window.

[0088] In one implementation, WTRU-triggered DL small data scheduling can be based on WTRU state / mode transitions. Upon receiving a subsequent data indication, the WTRU can initiate RA to enter connected mode. The WTRU can initiate RA to transition to connected mode based on the received DL small data, the DL small data transfer block size (TBS), the data received from a specific LCH / DRB / QoS stream, and / or whether the remaining TB is predicted. The WTRU can transition to connected mode upon receiving DL small data on a given PDCCH or PDSCH resource.

[0089] In one implementation, network-initiated DL small data scheduling with preamble transmission is disclosed. DL small data can be initiated by an application in the absence of prior associated UL small data transmission. The network can initiate DL small data transmission. Trigger-based small data reception techniques can be implemented when the WTRU triggers a DL small data transmission process (e.g., RA for small data) upon receiving a trigger signal from the gNB. The trigger event can transmit a PRACH resource, PDSCH resource, or RA type (or be associated with them).

[0090] The NW can trigger the WTRU to initiate the RA procedure to receive small data over DL in inactive or idle mode. This procedure can be useful when the UL timing is unknown, and therefore, the preamble can provide the gNB with a way to provide / update the WTRU's TA during the RA procedure. When the WTRU is known, the WTRU can use the trigger signal to monitor DL ​​assignment on the downlink configuration grant, and the method described herein is also applicable to small data reception on the DL CG.

[0091] The WTRU can be configured to monitor certain PDCCH resources (e.g., on core sets common to the search space or UE-specific and / or RNTIs) to receive trigger signals from the network. The WTRU can be configured via broadcast or semi-static signaling with these PDCCH resources, associated parameters, and / or PDCCH monitoring modes to monitor the reception of trigger signals. As disclosed, the WTRU can be configured with a monitoring mode and associated PDCCHs and can receive trigger signals prior to RA initiation. Trigger signals can be configured to be associated with a subset of PRACH or PDSCH resources, or can indicate a subset of those resources. Trigger signals can indicate the initiation of RA on a specific PRACH resource (e.g., the associated PRACH resource can be configured and considered applicable upon receiving the trigger signal).

[0092] Upon receiving such a trigger event, the WTRU can initiate a CBRA or CFRA procedure to transmit and / or receive UL and / or DL ​​small data. The WTRU can be configured via broadcast or semi-static signaling with PRACH resources, initiating RA on those PRACH resources upon receiving an RA trigger event. Alternatively, the WTRU can use any Random Access Channel (RACH) resource in the RACH common configuration provided by broadcast signaling. Furthermore, the WTRU may or may not maintain a CFRA configuration when entering inactive mode. If a CFRA configuration is unavailable, the WTRU can use CBRA.

[0093] The WTRU can determine the type of random access procedure (e.g., 2-step or 4-step) or parameters of the random access procedure (e.g., RAR and contention resolution timers, power ramp-up or backoff values, etc.) based on the receipt or absence of the trigger signal or according to the indication portion of the trigger signal.

[0094] The PRACH preamble transmission trigger event can be implicit or explicit. An implicit trigger event can be a trigger event that the WTRU receives from the network, anticipating an upcoming DL small data exchange and therefore requiring RA to be initiated. An implicit trigger event can be determined based on the reception of a DL signal on a given DL resource (e.g., receiving a PDCCH on a core set or search space, receiving an SSB or CSI-RS on a given CSI-RS resource set, MIB / SIB, etc.). For small data exchange purposes, the WTRU can consider the RACH or PDSCH resources valid for the configuration period beginning from the reception of the trigger signal.

[0095] Trigger signals may further implicitly or explicitly indicate one of these contents. Such contents may include the purpose of small data exchange / RA (e.g., mobility / handover, beam realignment, beam failure recovery, exchange of RRC messages for RRC reconstruction, priority, service / LCH / vertical) or suitability indications for one or more WTRUs (e.g., a group or subset of WTRUs, WTRUs capable of small data). For example, suitability indications may be unique IDs used to indicate a subset of WTRUs (e.g., small data-RNTI, RNTI corresponding to the identifier of a single WTRU (C-RNTI or I-RNTI)). These contents may include the RA type or random access procedure (e.g., 2-step or 4-step, regular RA, BFR-RA, handover RA) or parameters of the random access procedure, PRACH or PDSCH resources suitable for small data reception / exchange, and PRACH or PDSCH resources for scheduling small data reception. Furthermore, these contents may include the applicable beam or transmit / receive point (TRP) to be used during the RA process or during small data exchange on the applicable DL CG. The WTRU can implicitly determine the most suitable beam / TRP / SSB / CSI-RS and further select the associated PRACH or PDSCH resources. Additionally, this information can indicate whether to switch to connected mode. The WTRU can switch to connected mode during DL / UL small data exchange during a network-initiated RA process triggered by the NW or during a network-initiated RA process on a subset of PRACH resources (preamble and / or RO).

[0096] WTRU can be configured or predefined using associations and / or rules, allowing WTRU to determine the appropriate RA type, PRACH resource, and / or PDSCH resource for small data transmission based on the reception of one or more trigger signals.

[0097] The WTRU can be triggered to receive small data DL on a given resource, or the RA procedure can be initiated to receive small data after receiving an RAN paging message, the indication portion of a paging PDCCH signaling, or an indication included in a paging message or paging channel. In one implementation, the trigger signal and its content can be embedded in the RAN paging message.

[0098] A WTRU can be triggered to receive small data transfer (DL) data on a given resource, or it can initiate an RA procedure to receive small data after the absence of expected / periodic associated DL signals (e.g., hold / live signals, SSB, DRS, CSI-RS, heartbeat signals, etc.), periodic PDUs or MAC CEs, and / or downlink small data. Therefore, a WTRU can implicitly determine that it has been triggered to initiate a small data exchange procedure based on the absence of expected or periodic downlink signals. A WTRU can initiate an RA procedure even when it has not received expected or periodic downlink signals / channels, downlink PDUs, or downlink small data.

[0099] In various implementations, network-initiated DL small data transmissions without preamble transmissions are disclosed. Without associated preamble transmissions, the WTRU can use configured authorized PDSCH resources to receive small data in inactive or idle modes.

[0100] The WTRU can be configured based on one or more configuration authorizations (e.g., via broadcast and / or RRC signaling) to determine whether small data reception on the cell is suitable for IDLE and / or inactive modes. This configuration can be dedicated (per cell ID, and in the HO command) or provided by broadcast system information signaling. The configuration can indicate whether the WTRU can use small data transmission (e.g., without switching to connected mode), and if so, whether the WTRU should use PRACH and / or send an accompanying preamble. In one implementation, the WTRU can be configured with criteria for DL ​​small data without a preamble, such as a set of channel conditions, TA, S-metrics, CRE area, and / or L3 channel measurements.

[0101] A WTRU can be configured with one or more downlink configuration grants (e.g., SPS resources) to receive small data (DL) data in inactive or idle states. For a WTRU that successfully synchronizes downlink assignments in inactive or idle modes, the WTRU can first determine the cell's downlink timing format broadcast and SSB signaling before any data transmission. The WTRU can be configured (e.g., via broadcast or RRC signaling) based on whether small data reception on the cell is suitable for one or more downlink configuration grants in IDLE and / or inactive modes.

[0102] The WTRU can monitor DL ​​assignments on a PDCCH or DL ​​resource (e.g., PDSCH resource, SPS) based on measured channel conditions (e.g., RSRP), regardless of whether the WTRU is for uplink synchronization, channel occupancy, and / or associated TBS. The WTRU may have one or more CGs configured for small data reception that may be on different carriers. If one or more of these conditions are met, the WTRU can monitor downlink assignments on a subset of the configured / active DL CGs used for small data reception.

[0103] These conditions can be based on TBS. The WTRU can be configured with a TBS range for each CG. If the predicted DL small data volume falls within the configured TBS range of the CG, the WTRU can monitor the DL assignment on the CG. For example, the WTRU can determine the predicted small data packet volume based on the configuration of the associated DRB or QoS flow or based on the UL small data transmitted before reception.

[0104] These conditions can be based on (or include) one or more measured channel conditions. The WTRU can be configured with a channel condition range or threshold (e.g., RSRP, path loss, power margin, etc.) for each CG. If the measured channel conditions are within the configured range or below the threshold, the WTRU can monitor DL ​​assignments on the configuration grant for small data reception. In one example, the channel condition range / threshold can be configured collectively for the downlink carrier (e.g., grants for all configurations on the same DL carrier).

[0105] These conditions can be based on TA. In one example, the WTRU can be configured with a series of TA values ​​per cell or per CG, against which the WTRU monitors the configuration authorization for DL ​​assignment of idle / inactive modes. The WTRU can retain the TA value last used when transitioning from connected mode. With this configuration, the WTRU can monitor small data reception on some configured CGs if the TA is within acceptable limits. If the maintained TA value does not change over a configured time period, the WTRU can further determine that the CG is suitable for small data reception.

[0106] These conditions can be based on one or more active downlink carriers and / or one or more active DL bandwidth portions (BWP).

[0107] In one implementation, or if the small data reception is a negative ACK (NACK) and / or if the TBS is greater than or equal to a threshold, the WTRU can initiate RA to switch to connected mode for subsequent DL data reception.

[0108] If the WTRU is not uplink time synchronized (e.g., no stored / received TA value) or if a TB may not be successfully decoded after all or multiple TBs are received (e.g., the HARQ feedback determined for a received DL small data is NACK), the WTRU can initiate RACH and switch to connected mode. If the received or potentially successfully received DL small data TB is greater than a configured threshold, the WTRU can initiate RACH and switch to connected mode.

[0109] In one implementation, reference Figure 2 The WTRU can receive configuration information including one or more UL CGs (e.g., for SDT), one or more DL CGs (e.g., for SDT), and / or one or more TBS thresholds (e.g., for SDT). This configuration information can be received in inactive or connected mode. The WTRU can operate in inactive mode during and / or after receiving the configuration information. In one example, the WTRU can use one or more DL CGs for SDT to receive DL data transmissions. The WTRU can determine the TBS, HARQ feedback, and / or DRB for DL ​​data transmissions. The WTRU can use UL SDT resources (e.g., PUSCH resources) to determine whether to remain inactive and send HARQ feedback (e.g., DL SDT) for DL ​​data transmissions, or initiate random access (RA) to request an RRC connection (or RRC reconnection) based on, for example, the determined DL TBS, the determined HARQ feedback, DL DRB SDT support, and / or UL time alignment. For example, if the determined TBS is less than the TBS threshold and / or the DRB supports SDT, the WTRU may send a HARQ feedback on the UL CG for SDT (e.g., as a UCI on the PUSCH). The aforementioned conditions for sending HARQ feedback may further include HARQ feedback as an ACK. In another example, if the determined TBS is greater than (or equal to) the TBS threshold, or the HARQ feedback is NACK, or the DRB does not support SDT, the WTRU may send an RRC connection request (e.g., using the conventional RA procedure). In some cases, the WTRU may determine UL time alignment, and if the WTRU is not UL time aligned, the WTRU may send an RRC connection request.

[0110] Still referencing Figure 2 If the above and / or Figure 2 If any of the conditions mentioned above are met, the WTRU can initiate a transition to connected mode and / or send an RRC connection request (e.g., initiate a traditional RA procedure). On the other hand, if the above and / or Figure 2If one or more of the conditions mentioned herein apply, the WTRU may remain in inactive mode and may continue to receive DL SDT (or send UL SDT), and / or send HARQ feedback on the UL CG for SDT (e.g., as UCI on PUSCH or PUCCH).

[0111] In one implementation, a method implemented by a WTRU for wireless communication may include receiving configuration information for Small Data Transmission (SDT), the configuration information indicating one or more UL Configuration Grants (CGs), one or more DLCGs, and a TBS threshold for the SDT. The method may include receiving DL data transmissions using the DLCGs of the one or more DLCGs, and determining the TBS, Hybrid Automatic Repeat Request (HARQ) feedback, and the Data Radio Bearer (DRB) associated with the received DL data transmissions. The method may further include, based on determining 1) that the TBS associated with the received DL data transmissions is less than the TBS threshold and 2) that the DRB associated with the received DL data transmissions supports the SDT, using the ULCGs of the one or more ULCGs to transmit the HARQ feedback associated with the received DL data transmissions.

[0112] In one example, HARQ feedback is further sent based on determining that the HARQ feedback for the received DL data transmission is an acknowledgment (ACK). In one example, the method may also include sending an RRC connection request based on the following determinations: the TBS associated with the received DL data transmission is greater than or equal to a TBS threshold, the HARQ feedback is a negative acknowledgment (NACK), and / or the DRB associated with the received DL data transmission does not support SDT. In one example, the method may further include determining UL time alignment and sending an RRC connection request based on determining that the WTRU is not UL time aligned using the determined UL time alignment. In one example, each of the one or more UL CGs is associated with a Physical Uplink Shared Channel (PUSCH) resource for the UL SDT. In one example, HARQ feedback is sent as uplink control information (UCI) on the Physical Uplink Shared Channel (PUSCH) or Physical Uplink Control Channel (PUCCH). In one example, configuration information for the SDT is received in inactive or connected mode.

[0113] In one implementation, a method implemented by a WTRU for wireless communication may include monitoring the Physical Downlink Control Channel (PDCCH) for either receiving a DL assignment or control signaling after a UL small data transmission; triggering the DL small data transmission process upon receiving a trigger signal from a network entity (e.g., a base station or gNB); monitoring a subset of the DL configuration grant (CG) for DL ​​assignment based on at least one of Reference Signal Received Power (RSRP), Transport Block Size (TBS), and TA; initiating an RA to switch to connected mode based on at least one of subsequent DL data reception, small data reception including a negative acknowledgment (NACK), and TBS being greater than or equal to a threshold; and initiating a PDCCH monitoring timer for retransmission after at least one of small data reception and NACK.

[0114] In one example, the PDCCH is monitored on at least one of a specific resource and a Radio Network Identifier (RNTI). The PDCCH can be monitored based on previous UL small data transmissions. In one example, the PDCCH is monitored based on at least one of a Physical Random Access Channel (PRACH) resource, a Physical Uplink Shared Channel (PUSCH) resource, and UL Small Data Protocol Data Unit (PDU) content. In one example, the DL small data transmission process includes an RA for small data. In one example, the triggering event can include one or more of the PRACH, Physical Downlink Shared Channel (PDSCH), and / or RA types.

[0115] In various implementations, the HARQ feedback for downlink small data, sent as part of the RA procedure, can be implicit or explicit. For example, the WTRU can implicitly indicate HARQ-ACK for small data received in Msg2 by sending Msg3 or by an indication portion including the Msg3 payload (e.g., UCI on PUSCH). For small data received on MsgB, Msg4, or DL ​​CG, the WTRU can provide HARQ-ACK by explicit signaling (e.g., UCI on PUSCH or PUCCH).

[0116] The WTRU may or may not be uplink time-synchronized to provide HARQ-ACK feedback on the PUCCH or PUSCH. The WTRU may have predefined or configured (e.g., via broadcast or semi-static signaling) HARQ feedback parameters (e.g., feedback timing, K1, feedback resources such as PRI, uplink carrier, etc.), possibly for each cell, each DL CG, and / or each RA type (small data received in 2 steps versus 4-step RA). The WTRU may determine the feedback parameters based on the indication portion of dynamic explicit signaling / PDCCH signaling, a portion of the MsgB / Msg2 / Msg4 content, or a portion of the content of the downlink small data PDU itself. The WTRU may also implicitly determine the feedback parameters based on the DL resources used to transmit downlink data.

[0117] The WTRU can further provide dynamic uplink grants for sending HARQ feedback as the UCI on the PUSCH, and possibly associated uplink small data. The WTRU can override semi-static or predefined feedback parameters when providing dynamic uplink grants for sending HARQ feedback as the UCI on the PUSCH, and possibly associated uplink small data.

[0118] When determining a NACK or providing HARQ feedback as a NACK for one or more TBs, the WTRU can monitor PDCCH signaling or downlink assignments or monitor DL ​​assignments on a DL resource (e.g., PDSCH resource, SPS).

[0119] The WTRU can start a timer during which it monitors the PDCCH, for example, after sending a NACK feedback or after receiving a DL TB, as described. The timer value can be configured via broadcast or semi-static signaling. When the timer expires, the WTRU can stop monitoring the PDCCH for retransmission.

[0120] This document discloses procedural aspects of small data reception (such as DL small data format). A WTRU can receive one or more types of content in a small data PDU / sub-PDU / MAC CE. This content may include data from one or more LCHs, a resumeID (e.g., to enable the network to move the WTRU to connected mode), and / or an I-RNTI or C-RNTI.

[0121] This one or more content may include an indication of whether subsequent data is available. For example, if the WTRU is to monitor subsequent DL assignments to receive subsequent small data, the WTRU may receive a bit indication. This indication may further indicate the associated DL resources used for receiving subsequent data.

[0122] The one or more contents may include: an indication of whether to switch to a connection mode, for example, to receive additional data; HARQ feedback parameters / resources (PRI, HARQ feedback timing (K1), HARQ process ID for which WTRU provides feedback); reception acknowledgments / HARQ-ACKs for the relevant previous UL small data for one or more HARQ PIDs; and / or WTRU context information or configuration, including configuration of radio bearers, logical channels, and / or security information / keys.

[0123] WTRU can be configured by RRC or broadcast signaling, which includes PRACH and PDSCH resources suitable for small data reception, configuration authorization suitable for small data reception in power-saving mode, whether HARQ feedback is used, small data reception method that can be configured for each resource (or each CG or each PRACH or each DL), and / or small data applicability configured for each downlink LCH / DRB / LCG / QoS flow.

[0124] Additionally, some DRBs can be paused in inactive or idle modes. The RRC can configure the WTRU of each DRB by whether it is maintained or paused in idle and / or inactive modes.

[0125] In various implementations, the WTRU can be configured to perform spatial filter maintenance in INACTIVE mode. For example, the WTRU can perform beam alignment and maintenance, beam fault detection, recovery processes, and / or rollback.

[0126] In CONNECTED state / mode, the WTRU and / or gNB can maintain spatial filter pairs by monitoring the signal quality of the reference signal. Spatial filter monitoring can be performed via SSB or CSI-RS. Typically, SSBs are used for broad cell coverage, and the WTRU can use them for coarse pairing, while CSI-RS allows for more granular selection. However, when the WTRU is in INACTIVE state, it may not monitor CSI-RS. Furthermore, when using configuration authorization in INACTIVE state, the WTRU can be configured with spatial filters for transmission. However, the WTRU may not be aware of the status of the spatial filters (e.g., whether the spatial filter is still the optimal filter to use), because the WTRU may not be intensively monitoring spatial filter quality in INACTIVE state.

[0127] For a RACH procedure initiated in IDLE or INACTIVE state, the WTRU can indicate the optimal beam (e.g., the SSB with the highest measured RSRP) to the gNB based on the selection of PRACH resources (e.g., RO and / or preamble). The gNB can then use this information to select its receive spatial filter for Msg3 and its transmit beam for Msg2 / MsgB / Msg4. However, for small data transmissions in an inactive state under configuration authorization, a proper beam alignment procedure may not exist. The WTRU may have moved since the RACH procedure was completed, or a period of time may have elapsed since the RACH procedure was completed, which does not provide the gNB with a method for selecting an appropriate spatial filter to receive small UL data transmitted under configuration authorization in an INACTIVE state.

[0128] In various implementations, the WTRU can be configured with spatial filter diversity in the INACTIVE state / mode. For example, the WTRU can monitor the spatial filter quality on a subset of RSs, and this subset of RSs can be configured only for INACTIVE mode. In one example, the WTRU can be configured with multiple RSs for spatial filter monitoring, and a subset of RSs for spatial filter monitoring in INACTIVE mode. When the WTRU switches to INACTIVE, it can determine to monitor INACTIVE only on a subset of RSs for receiving DL data, or to determine to utilize only spatial filters for transmission, which can be received at the gNB on the subset of RSs used for INACTIVE. In some cases, the parameters used to detect beam faults may be specific to the INACTIVE state compared to the CONNECTED state (e.g., RSRP threshold or BFR RACH configuration). When the WTRU moves / switches to the INACTIVE state, the WTRU can use the parameters used for INACTIVE.

[0129] In various implementations, to increase the likelihood of successful reception (or transmission), a WTRU in the INACTIVE state may determine to monitor DL ​​data (or transmit UL data) on more than one spatial filter, and these spatial filters may be part of a subset of RSs configured for use only in the INACTIVE state.

[0130] In one implementation, the WTRU can determine the spatial filter configuration based on signal quality. The WTRU can use measurements taken in the INACTIVE state on the RS (e.g., SSB-RSRP) to determine the number of spatial filters to transmit. For example, based on one or more SSB-RSRP measurements below a threshold, the WTRU can determine to transmit two UL data copies, where the WTRU can use / apply two different spatial filters. If the WTRU determines that the SSB-RSRP measurement is above a threshold, the WTRU can use one UL data copy and one spatial filter.

[0131] In one implementation, the WTRU can use an SSB-RSRP threshold to determine the number of RSs to monitor in the INACTIVE state. For example, if the measured SSB-RSRP is below the threshold, the WTRU can monitor two RSs, while if it is above the threshold, the WTRU can monitor one RS. When the WTRU is in the INACTIVE state, the gNB can use the subset of RSs configured for INACTIVE to send DL data or monitor UL transmissions from the WTRU.

[0132] In another implementation, the WTRU can use a timer to determine the spatial filter configuration. The WTRU can determine, for example, the duration for which the WTRU has been in an INACTIVE state, and the timer can be mapped to the spatial filter configuration. In one example, for the duration of the timer, the WTRU can determine whether to use RS1 to determine the spatial filter for UL transmission or for DL ​​monitoring. The WTRU can use multiple timers, where each timer can determine the number (1 or 2), RS index (RS1 or RS2), and / or a pattern with multiple repeating spatial filters (RS1-RS2 or RS2-RS1). In some cases, the timer can start when another timer times out, so the WTRU can start by monitoring RS1 and if the WTRU fails to receive RS1 when the timer times out, the WTRU can start another timer in which the WTRU can monitor both RS1 and RS2.

[0133] In various implementations, the WTRU can be configured to perform beam fault detection in an INACTIVE state / mode. In one implementation, the WTRU in the INACTIVE state can determine a beam fault based on one or more conditions, including signal quality and / or other conditions. The WTRU can examine individual conditions and can use them as an estimate of the WTRU's beam state. The WTRU can use timers, counters, or combinations of these measured (or determined) parameters (which may or may not be related to beam quality) to determine that a beam fault has occurred. For example, one or more conditions that trigger a beam fault may include one or a combination of the following conditions, as determined by the WTRU (e.g., during the INACTIVE state / mode).

[0134] In one example, a timer can be used as a condition or trigger event (e.g., determined by the WTRU). Using a timer, the WTRU can track time since the last occurrence of an event (such as the last time the WTRU sent a CSI report), since the WTRU became INACTIVE, since the WTRU was last CONNECTED, and / or since the WTRU last transmitted / received data. In another example, a counter can be used as a condition or trigger event (e.g., determined by the WTRU). Using a counter, the WTRU can track the number of failed attempts to transmit UL data, the number of different spatial filters the WTRU attempted to use within a certain time period, the number of times the WTRU transmitted a preamble, and / or the number of times the WTRU switched between CG and RACH or between 2-step RACH and 4-step RACH. In one example, a power level can be used as a condition or trigger event (e.g., determined by the WTRU). For example, the WTRU can determine that a power level (e.g., transmit power level or receive power level) is higher (or lower) than a threshold. Based on the determination that the power level is higher (or lower) than the threshold, the WTRU can determine that its spatial filter is no longer effective based on the determined transmit power level. The determined transmit power level can be based on a threshold, WTRU's P cmax And / or power margin.

[0135] In various implementations, the WTRU can be configured to perform beam fault recovery in INACTIVE state / mode. In one implementation, when a beam fault is detected in INACTIVE mode, the WTRU can perform one or more of the following recovery activities: (1) The WTRU can switch to connected mode. (2) The WTRU can perform cell reselection. (3) The WTRU can employ a different small data transmission method. For example, if the WTRU is configured to perform small data transmission on a configuration grant, the WTRU can alternatively attempt to transmit small data on RACH-based resources (e.g., MsgA or Msg3). (4) The WTRU can select a different CG. For example, the WTRU can select a CG with a more conservative MCS. The WTRU can select an alternative CG, for example, only if the WTRU has / uses a more conservative MCS, only if there are no remaining CGs configured for the WTRU, or until there are no remaining CGs configured for the WTRU. (5) The WTRU can select a different spatial filter. For example, the WTRU can perform retransmissions on an alternative spatial filter. The WTRU may have a configured back-off spatial filter, or the WTRU may randomly select candidate spatial filters. The WTRU may be configured with a finite number of attempts to select different spatial filters, wherein upon reaching a configured value, it will perform an alternative recovery action or transition to IDLE. And / or (6) the WTRU may utilize a subset of resources / RNTIs configured for beam fault recovery to perform RACH. Such resources may be pre-configured by the gNB and indicated as WTRUs, wherein the WTRU may attempt to access, for example, a subset of RACH preambles dedicated to beam fault recovery, and / or perform CFRA with a dedicated RNTI.

[0136] In one implementation, the WTRU can perform beam fault recovery actions upon explicit instruction from the gNB. For example, the WTRU can receive explicit instruction from the gNB to perform one or more of the recovery actions listed above. This instruction can be, for example: (1) upon receiving one or more NACKs or retransmission grants. For example, the WTRU can perform the above actions upon receiving one or more NACKs or retransmission grants from the gNB. In one implementation, the WTRU can be configured with a counter, which, after receiving a certain number of NACKs / retransmission grants, will execute one or more of the above recovery actions according to the counter. Alternatively, the WTRU can be configured with a timer, which will execute one or more of the above recovery actions if the WTRU has not yet received an ACK; and / or (2) upon receiving an RRC release message.

[0137] In various implementations, the WTRU can be configured to perform beam fault reporting in INACTIVE state / mode. In one implementation, upon beam fault detection, the WTRU can report a beam fault to the gNB. In one example, the WTRU can be configured with a dedicated subset of PRACH resources. Upon beam fault detection, the WTRU can use one of the dedicated beam fault preambles to initiate RACH. In another example, the WTRU can send a BFR MAC CE in msg3 / MsgA. A set of PRACH resources can be configured for INACTIVE beam fault recovery. The WTRU can use the PRACH resources to trigger an INACTIVE BFR, and the gNB can detect that the INACTIVE BFR has been triggered. The gNB can determine whether to keep the WTRU in INACTIVE mode after the WTRU has determined its new spatial filter.

[0138] In various implementations, the WTRU can be configured to perform beam alignment and maintenance of small data CG transmissions. In one example, the WTRU can perform a beamforming process before transmitting on a CG PUSCH resource. In one implementation, the WTRU can measure available SSBs and / or CSI-RS before transmitting small data on a PUSCH resource in an idle or inactive state.

[0139] In one implementation, the WTRU can select and report the best (or preferred) beam (e.g., SSB and / or CSI-RS) by performing beam training preamble transmissions or beam training PUCCH transmissions on resources associated with the selected beam, SSB, and / or CSI-RS. The association between PRACH resources and beams, SSBs, and / or CSI-RS can be configured by a higher layer (e.g., the maintenance portion of the WTRU context) or delivered via broadcast signaling. For example, the WTRU can transmit beam training preambles on PRACH resources (e.g., preambles and / or ROs) to indicate the best or preferred beam, followed by transmissions with small data transmissions on PUSCH CG resources. The gap between preamble transmissions and PUSCH transmissions can be configured, predetermined, or provided via broadcast signaling. Beam training preambles can be beneficial to the receiver in determining the best receiving beam for receiving subsequent PUSCH transmissions. The WTRU may not need to continue the RACH process after transmitting such training preambles; i.e., the WTRU may (or may not) monitor the PDCCH used for receiving RARs. The WTRU can monitor the PDCCH to obtain a gNB response after sending a beam training preamble or beam training PUCCH; the WTRU can also send small data on the PUSCH resource after successfully receiving such a gNB response. The WTRU can be configured with dedicated signaling using dedicated beam training PRACH and / or PUCCH resources. Otherwise, the WTRU can use the public PRACH to send the beam training preamble.

[0140] In one implementation, the WTRU may select and report the best (or preferred) beam (e.g., SSB and / or CSI-RS) in a MAC CE (e.g., a beam training MAC CE or a BFR MAC CE). The WTRU may selectively include such MAC CEs after a configured or predetermined number of (re)transmissions or upon receiving an instruction from the gNB to perform such an action.

[0141] For example, if a configured time period has elapsed or after multiple (re)transmissions, the WTRU may selectively perform such beam training procedures before a subset of CG timings. For instance, the WTRU may start a beam maintenance timer after each beam training procedure. If such a beam maintenance timer has expired, the WTRU may perform the beam training procedure. The WTRU may start the beam maintenance timer after sending the beam training preamble, any preamble, the beam training PUCCH, the beam training-related MAC CE, and / or after successfully completing the RACH procedure. In another example, the WTRU may perform such beam training procedures after, for example, a certain number of (re)transmissions on the CG resource. In one implementation, the WTRU may perform such beam training procedures periodically, for example, once per configured time period.

[0142] In various implementations, the WTRU can be configured to perform an active RACH process for beam alignment. In one implementation, a beam training preamble can be part of a newly initiated RACH process. Such processes can be initiated periodically or triggered by events and can (or may not) be tied to the timing of CG transmissions. The WTRU can measure SSB and / or CSI-RS, and / or trigger a new RACH process for beam training. For example, a WTRU may measure one or more SSBs, and / or measure one or more CSI-RSs, and / or trigger a new RACH procedure for beam training if one or more of the following conditions are met: 1) The WTRU measures a new SSB or CSI-RS with an RSRP higher than a configured threshold; 2) The reported preferred beam has changed; 3) The new SSB or CSI-RS has a higher RSRP than the previously reported beam; 4) A period of time has elapsed, and / or multiple small data (re)transmissions have occurred; 5) A timing advance timer has expired (e.g., a TA timer associated with CG resources); 6) The WTRU has received a DL instruction (issued by the DCI or MAC CE) to change the beam or TCI state; 7) The WTRU has moved (e.g., the estimated location of the WTRU has changed or its speed is above a threshold), or the WTRU has a new serving cell, and / or the WTRU has a new serving TRP; and / or 8) A configured timer (e.g., a beam maintenance timer) has expired.

[0143] In various implementations, the WTRU can backtrack to retransmit the small data payload on a RACH resource suitable for small data, for example, after a configured or predetermined number of (re)transmissions, or after a timer (e.g., a beam maintenance timer) has expired. If the TBS of the RACH resource does not match, the WTRU can segment the stored TBS and may include indications for subsequent transmissions. Alternatively, the WTRU can use a RACH procedure for beam realignment (without retransmitting the stored small data payload) and then retransmit the small data payload on the CG after the RACH procedure is successfully completed.

[0144] Although features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Furthermore, 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 via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile optical discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

[0145] Furthermore, the above embodiments specify processing platforms, computing systems, controllers, and other devices including processors. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be executed by various CPUs and memories. Such actions and operations or instructions can be considered as being “executed,” “computer-executed,” or “CPU-executed.”

[0146] Those skilled in the art will recognize that the actions and symbols representing operations or instructions include the CPU's manipulation of electrical signals. The electrical system represents data bits, which can lead to the final transformation or reduction of electrical signals and the retention of data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the CPU's operation and performing other signal processing. The memory location holding the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that representative embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may also support the provided methods.

[0147] Data bits may also be stored on a computer-readable medium, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (“RAM”) or non-volatile (e.g., read-only memory (“ROM”) mass storage system. The computer-readable medium may include cooperative or interconnected computer-readable media that are uniquely present on the processing system or distributed across multiple interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that representative embodiments are not limited to the memory described above, and other platforms and memories may also support the method described.

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

[0149] There is little difference between the hardware and software implementations of various aspects of the system. The use of hardware or software typically (but not always, as the choice between hardware and software may become important in certain contexts) represents a design choice that weighs cost against efficiency. Various media (e.g., hardware, software, and / or firmware) may exist to implement the processes and / or systems and / or other technologies described herein, and the preferred media may vary depending on the context of deployment. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose a media that is primarily hardware and / or firmware. If flexibility is most important, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0150] The above detailed description has illustrated various embodiments of the apparatus and / or process using block diagrams, flowcharts, and / or examples. Where such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or virtually any combination thereof. Suitable processors include (by way of example) general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), field-programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines.

[0151] Although features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. This disclosure is not limited to the specific embodiments described in this patent application, which are intended as examples of various aspects. Many modifications and variations are possible without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. Unless expressly stated otherwise, no element, action, or description used in this specification should be construed as essential or necessary to the invention. Based on the foregoing description, functionally equivalent methods and apparatus within the scope of this disclosure, other than those listed herein, will be apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only to the terms of the appended claims and the full scope of equivalents of such claimed claims. It should be understood that this disclosure is not limited to any particular method or system.

[0152] It should also be understood that the terminology used herein is for the purpose of describing specific implementations only and is not intended to be limiting. As used herein, when referred to herein, the term “station” and its abbreviation “STA”, “user equipment” and its abbreviation “UE” may mean: (i) a wireless transmitting and / or receiving unit (WTRU), as described below; (ii) any of several implementations of a WTRU, as described below; (iii) equipment having wireless and / or wired (e.g., tetherable) capabilities configured with some or all of the structure and functions of a WTRU, as described below; (iii) equipment having wireless and / or wired capabilities configured with fewer than all the structure and functions of a WTRU, as described below; or (iv) etc. The following is relative to Figures 1A to 1D Details of an exemplary WTRU that may represent (or be interchangeable with) any UE described herein are provided.

[0153] In some representative embodiments, portions of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein are, wholly or partially, equivalently implemented in an integrated circuit as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and that designing circuitry and / or writing code for software and / or firmware according to this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein can be distributed as program products in various forms, and the exemplary embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually implement that distribution. Examples of signal-bearing media include, but are not limited to, recordable media (such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc.); and transmission media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0154] The topics described herein sometimes illustrate different components contained within or connected to different other components. It should be understood that such depicted architectures are merely examples, and many other architectures can in fact achieve the same functionality. Conceptually, any arrangement of components achieving the same function is effectively “associated” to enable the desired functionality. Therefore, any two components combined herein to achieve a particular function can be considered “associated” with each other to enable the desired functionality, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired functionality. Specific examples of operably coupled components include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or logically interact and / or logically interact.

[0155] Regarding virtually any plural and / or singular terms used herein, those skilled in the art can appropriately convert them from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural permutations may be explicitly listed herein.

[0156] Those skilled in the art will understand that, in general, the terminology used herein, particularly in the appended claims (e.g., the body of the appended claims), is typically intended as “open-ended” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will also understand that if it is intended to specify a particular number of introduced claim objects, such intention will be explicitly stated in the claims, and if no such claim objects are present, such intention will not exist. For example, the term “single” or similar language may be used where only one item is anticipated. To aid understanding, the appended claims and / or the description herein may contain the use of the introductory phrases “at least one” and “one or more” to introduce claim objects. However, the use of such phrases should not be construed as implying that any particular claim containing such introduced claim objects is limited to an embodiment containing only one such claim object by using the indefinite articles “a” or “an.” This is true even when the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce the subject matter of a claim. Furthermore, even when a specific number of the introduced subject matter of a claim is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the stated number (e.g., a bare statement of "two subject matters" without other modifiers means at least two subject matters, or two or more subject matters).

[0157] Furthermore, in instances where the convention of "at least one of A, B, and C" is used, generally speaking, such a construction implies that a person skilled in the art will understand that the convention (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C). In instances where the convention of "at least one of A, B, or C" is used, generally speaking, such a construction implies that a person skilled in the art will understand that the convention (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C). A person skilled in the art should also understand that, in fact, any separate words and / or phrases presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one term, any one of the terms, or both of the terms. For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”. Additionally, as used herein, the term “any one of…” followed by a list of multiple items and / or multiple item categories is intended to include items alone or in combination with other items and / or other item categories, “any one of,” “any combination,” “any multiple,” and / or “any combination of multiples of.” Furthermore, as used herein, the term “group” or “cluster” is intended to include any number of items, including zero. Additionally, as used herein, the term “quantity” is intended to include any quantity, including zero.

[0158] Furthermore, where features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member of the Markush Group or a subgroup of its members.

[0159] As those skilled in the art will understand, for any and all purposes (such as for providing a written description), all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily identified as sufficiently descriptive and such that the same scope can be divided into at least two equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily divided into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, all language such as “at most,” “at least,” “greater than,” “less than,” etc., includes the referenced number and refers to a scope that can subsequently be divided into subscopes as described above. Finally, as those skilled in the art will understand, a scope includes each individual number. Thus, for example, a group having 1 to 3 units means a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units means a group having 1, 2, 3, 4, or 5 units, etc.

[0160] Furthermore, unless otherwise stated, the claims should not be construed as being limited to the order or elements provided. Additionally, the use of the term "means for..." in any claim is intended to refer to the claim format of 35 USC §112, ¶6 or means plus function, and any claim without the term "means for..." is not intended to be so.

[0161] The software-associated processor can be used to implement the radio frequency transceiver in a Transmitter-Receiver Unit (WTRU), User Equipment (UE), terminal, base station, Mobility Management Entity (MME), or Evolved Packet Core (EPC), or any host. The WTRU can be used in conjunction with modules and can be implemented in hardware and / or software including: Software-Defined Radio (SDR) and other components such as cameras, video camera modules, videophones, speakerphones, vibration devices, speakers, microphones, television transceivers, hands-free headsets, keypads, and Bluetooth. ® Modules, FM radio units, Near Field Communication (NFC) modules, Liquid Crystal Display (LCD) units, Organic Light Emitting Diode (OLED) units, Digital Music Players, Media Players, Video Game Players, Internet Browsers, and / or any Wireless Local Area Network (WLAN) or Ultra-Wideband (UWB) modules.

[0162] Although the invention has been described in relation to a communication system, it is conceivable that the system can be implemented in software on a microprocessor / general-purpose computer (not shown). In some embodiments, one or more functions of the various components can be implemented in software that controls the general-purpose computer.

[0163] Furthermore, while the invention has been shown and described herein with reference to specific embodiments, it is not intended to be limited to the details shown. Rather, various modifications may be made to the details within the scope and domain of equivalents of the claims without departing from the invention.

[0164] Throughout the disclosed content, those skilled in the art should understand that certain representative implementations may be used in alternative forms or in combination with other representative implementations.

[0165] Although features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Furthermore, 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 non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile optical discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

[0166] Furthermore, the above embodiments specify processing platforms, computing systems, controllers, and other devices including processors. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be executed by various CPUs and memories. Such actions and operations or instructions can be considered as being “executed,” “computer-executed,” or “CPU-executed.”

[0167] Those skilled in the art will recognize that actions and symbols representing operations or instructions include the CPU's manipulation of electrical signals. Electrical systems represent data bits that can lead to the final transformation or reduction of electrical signals and the retention of data bits at memory locations in a memory system, thereby reconfiguring or otherwise altering the CPU's operations and performing other signal processing. The memory location holding the data bits is a physical location having specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits.

[0168] Data bits may also be stored on a computer-readable medium, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (“RAM”) or non-volatile (e.g., read-only memory (“ROM”) mass storage system. The computer-readable medium may include cooperative or interconnected computer-readable media that are uniquely present on the processing system or distributed across multiple interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that representative embodiments are not limited to the memory described above, and other platforms and memories may also support the method described.

[0169] Suitable processors include (by way of example) general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), field-programmable gate arrays (FPGAs), any other type of integrated circuit (IC) and / or state machines.

[0170] Although the invention has been described in relation to a communication system, it is conceivable that the system can be implemented in software on a microprocessor / general-purpose computer (not shown). In some embodiments, one or more functions of the various components can be implemented in software that controls the general-purpose computer.

[0171] Furthermore, while the invention has been shown and described herein with reference to specific embodiments, it is not intended to be limited to the details shown. Rather, various modifications may be made to the details within the scope and domain of equivalents of the claims without departing from the invention.

Claims

1. A method for wireless communication implemented by a wireless transmit / receive unit (WTRU), the method comprising: Receive configuration information for Small Data Transmission (SDT) via Radio Resource Control (RRC) signaling, including one or more Data Radio Bearers (DRBs) that support SDT. Receive a paging message, the paging message including indication information for downlink (DL) SDT and including an I-Radio Network Temporary Identifier (I-RNTI) for WTRU. The uplink (UL) transmission is determined based at least on the reception of paging messages including indication information for DL ​​SDT and I-RNTI for WTRU; It has been determined that the WTRU is not time-synchronized with the UL. Based on the fact that WTRU is not a deterministic uplink time synchronization mechanism, a transmission preamble is transmitted. Based on the determination of the UL transmission, the UL transmission is transmitted on one or more Physical Uplink Shared Channel (PUSCH) resources; After transmitting the UL, the Physical Downlink Control Channel (PDCCH) is monitored to receive the DL assignment; Receive DL assignment; and Based on the DL assignment, one or more DRBs supporting SDT are used to receive DL data transmission.

2. The method of claim 1, wherein the configuration information indicates authorization (CG) for one or more UL configurations for SDT and one or more DL CGs for SDT, wherein DL data transmission is further received using one of the one or more DL CGs; and the method further comprises: Based on one or more DRBs supporting SDT, UL CGs in one or more UL CGs are used to transmit Hybrid Automatic Repeat Request (HARQ) feedback associated with DL data transmission, wherein one or more DRBs supporting SDT are associated with DL data transmission, and wherein the HARQ feedback is further transmitted using UL CGs based on HARQ feedback as an acknowledgment (ACK) of DL data transmission.

3. The method according to claim 1 or claim 2, wherein the method further comprises: Based on the determination that WTRU is not UL time synchronization, an RRC connection request is transmitted.

4. The method of claim 2, further comprising transmitting the RRC connection request based on the following: the transport block size (TBS) associated with DL data transmission is greater than or equal to a TBS threshold configured for SDT, and the HARQ feedback associated with DL data transmission is a negative acknowledgment (NACK).

5. The method of claim 2, wherein each of the one or more UL CGs is associated with a PUSCH resource for ULSDT.

6. The method of claim 2, wherein the HARQ feedback is transmitted as uplink control information (UCI) on the PUSCH or physical uplink control channel (PUCCH).

7. The method of claim 2, wherein the configuration information for SDT is received in an inactive mode or a connected mode.

8. The method according to claim 2, further comprising: After the UL SDT, the Physical Downlink Control Channel (PDCCH) is monitored for either the received DL assignment or control signaling. The DL small data transmission process is triggered upon receiving a trigger signal; A subset of the one or more DL CGs is monitored for DL ​​assignment based on any of the following: Reference Signal Received Power (RSRP), Transport Block Size (TBS), or UL Time Alignment; Random access (RA) is initiated to switch to connected mode based on any of the following: subsequent DL data reception, small data reception including negative acknowledgment (NACK), or the TBS is greater than or equal to the TBS threshold; and Start the PDCCH monitoring timer for retransmission after receiving a small amount of data, including at least NACK.

9. The method of claim 8, wherein the PDCCH is monitored based on previous UL small data transmissions.

10. The method of claim 8, wherein the PDCCH is monitored based on any of the following: Physical Random Access Channel (PRACH) resources, PUSCH resources, or UL Small Data Protocol Data Unit (PDU) content.

11. The method of claim 2, wherein the configuration information indicates a transport block size (TBS) threshold for SDT, and wherein UL CG is used to transmit HARQ feedback based on the TBS associated with DL data transmissions smaller than the TBS threshold.

12. The method of claim 2, wherein the HARQ feedback is further transmitted using UL CG based on the UL transmission time of the synchronized WTRU.

13. The method of claim 2, wherein the HARQ feedback is transmitted in the current RRC mode, and wherein the DL data transmission is received in the inactive mode.

14. A wireless transmit / receive unit (WTRU) for wireless communication, the WTRU comprising: Receiver, the receiver being configured to: Receive configuration information for Small Data Transmission (SDT) via Radio Resource Control (RRC) signaling, including one or more Data Radio Bearers (DRBs) that support SDT. Receive a paging message, the paging message including indication information for downlink (DL) SDT and including an I-Radio Network Temporary Identifier (I-RNTI) for WTRU. A processor, operatively coupled to a receiver, is configured to: The uplink (UL) transmission is determined based at least on the reception of paging messages including indication information for DL ​​SDT and I-RNTI for WTRU; It has been determined that the WTRU is not time-synchronized with the UL. A transmitter operatively coupled to a receiver and a processor, the transmitter being configured to transmit UL transmissions on one or more Physical Uplink Shared Channel (PUSCH) resources based on the determination of transmitting UL transmissions; The processor and receiver are configured to monitor the Physical Downlink Control Channel (PDCCH) to receive DL assignments after the UL transmission; The receiver is configured to: Receive DL assignment; and Based on the DL assignment, one or more DRBs supporting SDT are used to receive DL data transmission.

15. The WTRU of claim 14, wherein the configuration information indicates authorization (CG) for one or more UL configurations for SDT and one or more DL CGs for SDT, wherein DL data transmission is further received using one of the one or more DL CGs; The transmitter is further configured to transmit Hybrid Automatic Repeat Request (HARQ) feedback associated with DL data transmission using one or more UL CGs, based on one or more DRBs supporting SDT, wherein the DRBs supporting SDT are associated with DL data transmission. The HARQ feedback is further based on the use of UL CG to transmit HARQ feedback as an acknowledgment (ACK) of DL data transmission.

16. The WTRU of claim 15, wherein the transmitter is further configured to transmit an RRC connection request based on: 1) The transport block size (TBS) associated with DL data transmission is greater than or equal to the TBS threshold configured for SDT, and 2) HARQ feedback associated with DL data transmission is a negative acknowledgment (NACK).

17. The WTRU of claim 14 or claim 15, wherein the transmitter is further configured to transmit an RRC connection request based on determining that the WTRU is not UL time-synchronized.

18. The WTRU of claim 14, wherein the configuration information of SDT 1) is received in inactive mode or connected mode and indicates the Radio Network Identifier (RNTI).

Images