Methods, architectures, devices and systems for discontinuous reception and logical channel prioritization for HARQ state information based on L1 indication

Abstract

In an embodiment, a method implemented in a wireless transmit / receive unit is described herein. The method may include receiving configuration information indicating: (1) a downlink control information (DCI)-based indication of a hybrid automatic repeat request (HARQ) state, and (2) a first HARQ state associated with a HARQ process. The method may include performing a first discontinuous reception (DRX) operation based on the first HARQ state. The method may comprise: receiving DCI; and determining that the DCI may indicate a second HARQ state associated with the HARQ process based on configuration information indicating that a DCI-based indication of the HARQ state may be enabled. The method may include performing a second DRX operation associated with the HARQ process based on the second HARQ state.

Description

[0001] This application is a divisional application of patent application number 202380069155.8, filed on September 28, 2023, with the title “Methods, Architectures, Devices, and Systems for Discontinuous Reception and Logical Channel Prioritization for L1 Indication Based HARQ Status Information”. Cross Reference to Related Applications

[0002] This patent application claims the benefit of U.S. Patent Application No. 63 / 410,791, filed on September 28, 2022, which is incorporated by reference herein in its entirety. TECHNICAL FIELD

[0003] The present disclosure relates generally to the fields of communication, software, and coding, including, for example, methods, architectures, devices, systems for discontinuous reception (DRX) and logical channel prioritization (LCP). BACKGROUND

[0004] Non-terrestrial networks (NTNs) can facilitate deployment of wireless networks in areas where land-based antennas can not be practical, for example, due to geography or cost. For example, NTNs can be coupled with terrestrial networks to enable coverage of third generation partnership project (3GPP) 5G networks. Initial 3GPP Rel-17 NTN deployments can support basic voice and text. Further releases, in anticipation of a proliferation of next generation low earth orbit satellites, can enable enhanced services, such as web browsing. Embodiments described herein are designed with the above in mind. SUMMARY

[0005] Methods, architectures, devices, and systems are described herein for adapting DRX and LCP based on either downlink control information (DCI) and a physical layer (L1) based indication of whether hybrid automatic repeat request (HARQ) feedback is enabled or disabled. In embodiments, a method can be implemented in a wireless transmit / receive unit (WTRU). The method can include receiving downlink control information indicating HARQ status information, and performing discontinuous reception (DRX) based on the HARQ status information. In embodiments, the WTRU can be configured to receive downlink control information indicating HARQ status information, and perform DRX based on the HARQ status information.

[0006] In an embodiment, a method implemented in a WTRU is described herein. The method can include receiving configuration information indicating (1) a DCI-based indication of a HARQ state and (2) a first HARQ state associated with a HARQ process. The method can include performing a first DRX operation based on the first HARQ state. The method can include receiving a DCI and determining, based on the configuration information, that the DCI can indicate a second HARQ state associated with the HARQ process, the configuration information indicating that the DCI-based indication of a HARQ state can be enabled. The method can include performing a second DRX operation associated with the HARQ process based on the second HARQ state.

[0007] In an embodiment, a WTRU is described herein. The WTRU can include a processor and a transmitter and a receiver (e.g., transceiver) operably coupled to the processor. The WTRU can be configured to receive configuration information indicating (1) a DCI-based indication of a HARQ state and (2) that downlink HARQ feedback can be disabled for a HARQ process. The WTRU can be configured to perform a first discontinuous reception (DRX) operation with the downlink HARQ feedback disabled. The WTRU can be configured to receive a DCI and determine, based on the configuration information, that the DCI can indicate that downlink HARQ feedback can be enabled for the HARQ process, the configuration information indicating that the DCI-based indication of a HARQ state can be enabled. The WTRU can be configured to perform a second DRX operation with the downlink HARQ feedback enabled, wherein monitoring to receive a retransmission can be delayed based on a WTRU-to-base station round trip time. BRIEF DESCRIPTION OF DRAWINGS

[0008] A more detailed understanding can be had from the following description, given by way of example in conjunction with the accompanying drawings wherein: FIG. 1A is a system diagram illustrating an example communications system; FIG. 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used within the communications system 100 shown in FIG. 1A is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used within the communications system 100 shown in FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used within the communications system 100 shown in FIG. 1A is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that can be used within the communications system 100 shown in FIG. 1D is a system diagram illustrating different interfaces in a non-terrestrial network; FIG. 1A is a system diagram of yet another example RAN and yet another example CN that can be used within the communications system 100 illustrated in FIG. 2 is a system diagram illustrating an example of different interfaces in a non-terrestrial network; FIG. 3 is a diagram illustrating an example of user plane and control plane protocol stacks for a transparent payload system; FIG. 4 is a system diagram illustrating an example of DRX adaptation based on HARQ feedback status and HARQ feedback mode; FIG. 5 is a system diagram illustrating an example of LCP adaptation; FIG. 6 is a system diagram illustrating an example method for adapting DRX based on L1 indication; FIG. 7 is a system diagram illustrating an example method for adapting DRX based on L1 indication; FIG. 8 is a diagram illustrating an example method for adapting DRX based on L1 indication; and FIG. 9 is a diagram illustrating an example method for adapting DRX based on L1 indication. DETAILED DESCRIPTION

[0009] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples can be practiced without some or all of these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the following description. Also, embodiments and examples

[0010] Example communication system The methods, devices, and systems provided herein are well suited to communications involving wired and wireless networks. With reference to FIGS. 1A-1DAn overview of various types of wireless devices and infrastructure is provided, where various elements of a network can utilize, perform, be arranged in accordance with, and / or be adapted and / or configured for the methods, apparatus, and systems provided herein.

[0011] FIG. 1A is a system diagram illustrating an example communications system 100 in which one or more disclosed embodiments can be implemented. The communications system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 can 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 (ZT) unique-word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0012] As FIG. 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, an air interface access network (RAN) 104 / 113, a core network (CN) 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it will 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 may 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 “site” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include (or be) user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other 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 the context of industrial and / or automated processing chains), 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.

[0013] 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 / 115, Internet 110, and / or Network 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), node-B (NB), eNode-B (eNB), master node-B (HNB), master eNode-B (HeNB), gNode-B (gNB), NR node-B (NR NB), site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0014] Base station 114a may be part of RAN 104 / 113, 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 in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a specific geographic area that may be relatively fixed or may vary over time. A cell may also be 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 for each 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 or any sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0015] 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 air interface access technology (RAT) can be used to establish air interface 116.

[0016] More specifically, as described above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 104 / 113 and WTRUs 102a, 102b, 102c can implement radio technologies, such as using Wideband CDMA (WCDMA) to establish Universal Mobile Telecommunications System (UMTS) terrestrial air interface (UTRA) access for air interface 116. WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

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

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

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

[0020] In the embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global System for Multi-Use Microwave Access (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), Enhanced Data Rate GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0021] FIG. 1ABase station 114b can be, for example, a wireless router, master node B, master eNode-B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In embodiments, 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 embodiments, 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 embodiments, 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 any of small cells, picocells, or femtocells. FIG. 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0022] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data may have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 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 FIG. 1A As not shown, but will be understood, RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs employing the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may be utilizing NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) employing any of the following radio technologies: GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi.

[0023] CN 106 / 115 can also serve 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 / 114 or a different RAT.

[0024] Some or all of the WTRUs 102a, 102b, 102c, and 102d in 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, FIG. 1A The WTRU 102c shown can be configured to communicate with a base station 114a that can use cellular-based radio technology and with a base station 114b that can use IEEE 802 radio technology.

[0025] FIG. 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) FIG. 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 components / peripherals 138, etc. It will be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the foregoing components.

[0026] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may 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 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although FIG. 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 can be integrated together, for example, in an electronic package or chip.

[0027] Transmitting / receiving element 122 can 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 can be an antenna configured to transmit and / or receive RF signals. In an embodiment, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In an embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF signals and optical signals. It will be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0028] Although the transmitting / receiving element 122 is in FIG. 1B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. For example, WTRU 102 may employ MIMO technology. Therefore, in an 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.

[0029] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, transceiver 120 can include multiple transceivers for enabling WTRU 102 to communicate via various RATs (e.g., such as NR and IEEE 802.11).

[0030] The processor 118 of WTRU 102 can be coupled to and receive user input data from: 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). The processor 118 can also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Additionally, the processor 118 can access information and store data from any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. 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 subscriber identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 can access information and store data from memory not actually located on WTRU 102, such as on a server or home computer (not shown).

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

[0032] 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 information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable location determination method.

[0033] The processor 118 may also be coupled to other components / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functions, and / or wired or wireless connectivity. For example, components / peripherals 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (e.g., for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, 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. Components / peripherals 138 may include one or more sensors, which 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, and / or humidity sensors.

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

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

[0036] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 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 embodiments, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a.

[0037] Each of the eNode-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, user scheduling in the uplink (UL) and / or downlink (DL), etc. FIG. 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0038] FIG. 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. While each of the foregoing elements is depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0039] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, activating / deactivating bearers, 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.

[0040] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to or from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during eNode-B handover, triggering paging when DL data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0041] SGW 164 can be connected to PGW 166, which can provide 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.

[0042] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or be able to communicate with it, serving as an interface between CN 106 and PSTN 108. 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.

[0043] Despite WTRU in FIGS. 1A-1D While described as a wireless terminal, it is envisioned that, in some representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0044] In a representative embodiment, the other network 112 may be a WLAN.

[0045] A WLAN in Infrastructure Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may access a distribution system (DS) or another type of wired / wireless network that loads traffic into and / or out of the BSS, or have an interface to it. Traffic originating outside the BSS destined for a STA can be delivered to the AP. Traffic from a STA to 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 a source STA and a destination STA using a direct link setup (DLS) (e.g., directly between them). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a "self-organizing" communication mode in this document.

[0046] 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 bandwidth of 20 MHz) or dynamically set via signaling. 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 embodiments, 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 sense the primary channel. If a particular STA senses / detects the primary signal and / or determines that the primary signal is busy, that STA can back off. A single STA (e.g., only one station) can transmit in a given BSS at any given time.

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

[0048] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which can be referred to as an 80+80 configuration. In the 80+80 configuration, data, after channel coding, can be passed through a fragment parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each stream separately. The streams can be mapped onto the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC) layer, entities, etc.

[0049] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can 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 supporting (e.g., only supporting) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0050] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The 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 the STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier 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, due to STAs (which only support the 1 MHz operating mode) transmitting to the AP, the entire available band can be considered busy even if most of the band remains idle and potentially available.

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

[0052] FIG. 1D This is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0053] RAN 113 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, 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 WTRUs 102a, 102b, and 102c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In an embodiment, gNBs 180a, 180b, and 180c may 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 located on unlicensed spectrum, while the remaining component carriers may be located on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0054] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can vary for 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., including different numbers of OFDM symbols and / or absolute times of varying durations).

[0055] 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., eNode 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 mobile 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 / connect with gNBs 180a, 180b, and 180c while also communicating / connecting with another RAN (such as eNode-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 eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobile anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRUs 102a, 102b, and 102c.

[0056] 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, support for network slicing, dual connectivity, interoperability between 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. FIG. 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

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

[0058] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act 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 NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing, for example, to customize CN support for WTRU 102a, 102b, and 102c based on the service types being used by WTRU 102a, 102b, and 102c. For example, different network slices can be created for different use cases, such as services that rely on Ultra Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-A Pro) and / or non-3GPP access technologies (such as Wi-Fi).

[0059] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure them to route traffic 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 downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0060] UPFs 184a and 184b can be connected via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 113. These gNBs can provide WTRUs 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110), for example, to facilitate communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. UPFs 184a 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 downlink packets, and providing mobility anchoring.

[0061] CN 115 can facilitate communication with other networks. For example, CN 115 may include or be able to communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 115 and PSTN 108. Additionally, CN 115 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. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to DN 185a and 185b via UPF 184a and 184b through the N3 interface to UPF 184a and 184b and the N6 interface between UPF 184a and 184b and local data networks (DNs) 185a and 185b.

[0062] Given FIGS. 1A-1D and FIGS. 1A-1D The corresponding description may be performed by one or more of the functions described herein with respect to any of the following: WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other element / device described herein. The simulation device may be one or more devices configured to simulate one or more of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0063] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices may perform one or more functions when 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. One or more simulation devices may perform one or more functions when 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 may use over-the-air wireless communication to perform tests.

[0064] One or more simulation devices can perform one or more functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, a simulation device can be used to test scenarios in a laboratory and / or undeployed (e.g., tested) wired and / or wireless communication networks to enable testing of one or more components. One or more simulation devices can be test equipment. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0065] Throughout the embodiments described herein, the terms "serving base station," "base station," and "gNB" are collectively referred to as "gNB" and may be used interchangeably to designate any network element, such as a network element that acts as a serving base station. The embodiments described herein are not limited to gNBs and are applicable to any other type of base station.

[0066] For clarity, throughout the embodiments described herein, the terms "metdient," "failed-to-metdient" (e.g., criteria), and "configuration condition parameters" are used in relation to thresholds (e.g., greater than or less than a threshold), values ​​(e.g., thresholds), configuration values ​​(e.g., thresholds), etc. For example, a metted condition (e.g., a criterion) may be described as being above a value (e.g., a threshold), and a failed-to-metdient condition (e.g., a criterion) may be described as being below a value (e.g., a threshold). The embodiments described herein are not limited to threshold-based conditions (e.g., criteria). Any other kind of conditions and parameters (e.g., belonging to or not belonging to a value range) may be applied to the embodiments described herein.

[0067] Throughout the embodiments described herein, (e.g., configuration) information can be described as being received by the WTRU from the network, for example, via system information or via any kind of protocol message. Although not explicitly mentioned throughout the embodiments described herein, the same (e.g., configuration) information can be pre-configured in the WTRU (e.g., via any kind of pre-configuration method, such as via factory settings) so that the (e.g., configuration) information can be used by the WTRU without being received from the network.

[0068] Throughout the embodiments described herein, the statements "the WTRU can be configured with a set of parameters" and "the WTRU can receive configuration information indicating a set of parameters (e.g., from another network element (e.g., a gNB))" are equivalent or interchangeable. Throughout the embodiments described herein, the statements "the WTRU can report something" and "the WTRU can be configured to report something" and "the WTRU can transmit (e.g., report) information indicating something" are equivalent or interchangeable.

[0069] Examples of non-terrestrial networks Non-terrestrial networks (NTNs) can facilitate the deployment of wireless networks in areas where ground-based antennas might be impractical due to geography or cost. For example, NTNs can be coupled with terrestrial networks to achieve (e.g., truly ubiquitous) 5G network coverage. Initial Rel-17 NR NTN deployments can support (e.g., basic) calls and text messaging. Further deployments, combined with the anticipated surge in next-generation low-Earth orbit satellites, could enable enhanced services such as web browsing.

[0070] NTN can include either airborne or spaceborne platforms that can transmit (e.g., transmit) signals received from a terrestrial gNB to a WTRU via a gateway (GW) and vice versa. Rel-17 NR NTN supports power class 3 WTRUs with omnidirectional antennas and linear polarization, or Very Small Aperture Antenna (VSAT) terminals with directional antennas and circular polarization. Based on recommendations from 3GPP TR 36.763 “Research on Narrowband Internet of Things (NB-IoT) / Enhanced Machine Type Communication (eMTC) Support for Non-Terrestrial Networks (NTN)” v17.0.0, support for LTE-based Narrowband IoT (NB-IoT) and enhanced machine type communication (eMTC) devices can be standardized in Rel-17. For example, any Rel-17 NTN WTRU can be a Global Navigation Satellite System (GNSS) capable of being used with any device type.

[0071] Airborne and / or spaceborne platforms can be classified based on their orbits. For example, an NR system can be based on either a Low Earth Orbit (LEO) satellite with an altitude range of, for example, 300 km to 1500 km, or a Geostationary Orbit (GEO) satellite with an altitude of, for example, 35786 km. NR systems can be compatible with other satellite platforms (e.g., classifications), such as Medium Earth Orbit (MEO) satellites with an altitude range of, for example, 7000 km to 25000 km, and High Altitude Platform Stations (HAPS) with an altitude range of, for example, 8 km to 50 km. Satellite platforms can be further classified as having either “transparent” payloads or “regenerative” payloads. A transparent satellite payload system can, for example, utilize one or more transparent satellites connected to a ground-based gNB to perform frequency conversion and RF amplification in the uplink and downlink. A regenerative satellite payload system can be implemented in either a full gNB or a gNB distributed unit (DU) on a satellite. A regenerative payload system can, for example, perform digital processing on signals, including, for example, demodulation, decoding, recoding, remodulation, and filtering.

[0072] FIG. 2 This is a system diagram illustrating examples of different interfaces in a non-terrestrial network. For example, an NTN network may include a radio link between GW20 and satellites 21 and 22, which may be referred to herein as feeder links 201 and 202. For example, an NTN network may include a radio link between satellites 21 and 22 and WTRU 23, which may be referred to herein as service link 203. An NTN network may include a transport link between satellites 21 and 22, which may be referred to herein as inter-satellite link (ISL) 204. In a regenerative payload system, an ISL may exist (e.g., only), which may be compatible with either a 3GPP radio interface or a proprietary (e.g., optical) interface.

[0073] Depending on the satellite payload configuration (e.g., transparent or regenerative), different 3GPP interfaces can be used for (e.g., each) radio links. In a transparent payload system, the NR-Uu radio interface can be used for both the serving link and the feeder link. For a regenerative payload system, the NR-Uu interface can be used on the serving link, and the Satellite Radio Interface (SRI) can be used for the feeder link. There is no description of ISL in 3GPP Rel-17.

[0074] FIG. 3This is a diagram illustrating an example of the user plane (UP) 31 and control plane (CP) 32 protocol stack for a transparent payload system. Protocol stacks for other types of payload systems are described in Sections 5.1 and 5.2, “Solutions for NR-Supported Non-Terrestrial Networks (NTN),” of 3GPP TR 38.821 v16.1.0.

[0075] NTN satellites can support one or more cells, and a cell can include one or more satellite beams. A satellite beam can cover an area on Earth (e.g., a terrestrial cell), the diameter of which in a LEO deployment can range from, for example, 100 km to 1000 km, and in a GEO deployment, the diameter can range from 200 lm to 3500 km. The beam coverage area in a GEO deployment can remain fixed relative to the Earth, while in a LEO deployment, the area covered by the beam (e.g., a cell) can change over time based on satellite movement. Where the LEO beam can move continuously on Earth, this beam movement may be referred to herein as “Earth movement,” or where the beam can be manipulated to maintain a fixed coverage position until a new cell can, for example, exceed that coverage area through discrete and coordinated changes, it may be referred to as “Earth fixed.”

[0076] Based on either the altitude or beam diameter of the NTN platform, the round-trip time (RTT) and maximum differential delay may be greater than those of a terrestrial system. For example, in a transparent NTN deployment, the RTT can range from 25.77 ms (for LEO at an altitude of 600 km) to 541.46 ms (for GEO), and the maximum differential delay can range from 3.12 ms to 10.3 ms. The RTT of a regenerative payload system can be half that of a transparent payload system. In fact, a transparent configuration can include both serving links and feeder links, and the RTT of a regenerative payload system may (e.g., only) involve the serving link. For example, the WTRU can perform timing pre-compensation before initial access to reduce (e.g., minimize) the impact on existing NR systems (e.g., avoiding preamble ambiguity or properly timing the receive window).

[0077] For example, the WTRU can obtain its position via GNSS and can obtain feeder link (or common) delay and satellite position via satellite ephemeris data to continue the pre-compensation process. Satellite ephemeris data can be periodically broadcast in system information and can include any of satellite velocity, orientation, and speed. For example, the WTRU can determine (e.g., estimate) the distance to the satellite (and, for example, the delay). For example, the WTRU can add a feeder link delay component to obtain the complete WTRU-gNB RTT, which can be used to compensate for any of the timers, receive windows, and timing relationships. Frequency compensation can be performed, for example, by the network.

[0078] 3GPP NR Rel-17 NTN further describes WTRU mobility and measurement reporting. For example, the difference in Reference Signal Received Power (RSRP) between the cell center and cell edge may not be as significant as in terrestrial systems. This, combined with large cell overlap areas, can lead to less reliable mobility based on 3GPP NR measurements in NTN environments. New location- and time-dependent conditional handover and measurement reporting triggering can allow for improved mobility management in NTN systems. Enhanced mobility may be particularly important in LEO deployments, where a stationary WTRU can (e.g., approximately) perform a move every 7 seconds (depending on deployment characteristics) due to satellite movement.

[0079] Example of disabling HARQ feedback in Rel-17 NTN HARQ stalling in this context can be considered as (e.g., all) HARQ process identifiers (IDs) having been assigned and are pending, making it impossible for any to be reused for new data transmission / reception. Several enhancements were introduced in Rel-17 NR NTN to avoid HARQ stalling due to increased propagation delays. For example, the ability to disable HARQ feedback allows HARQ process IDs to be used for new data transmission immediately after transmission (e.g., immediately), thus preventing HARQ stalling.

[0080] For example, a Radio Resource Control (RRC) configuration (e.g., information) that may be referred to herein as downlinkHARQ-feedbackDisabled can indicate whether downlink (DL) HARQ feedback is enabled or disabled. For example, downlinkHARQ-feedbackDisabled can be configured (e.g., RRC) for each serving cell (e.g., HARQ feedback can be disabled). For example, the WTRU can receive (e.g., semi-static) configuration information indicating whether the WTRU can generate HARQ feedback for a DL assignment addressed to a HARQ procedure ID for each HARQ procedure ID. Similarly, RRC configuration information that may be referred to herein as uplinkHARQ-Mode can be applied to UL HARQ procedures. For example, uplinkHARQ-Mode configuration information can be configured (e.g., RRC) for each serving cell (e.g., uplink HARQ mode A can be configured). For example, the WTRU can receive (e.g., semi-static) configuration information indicating whether a HARQ procedure can be configured as HARQ mode A or HARQ mode B for each HARQ procedure ID. For example, the network can provide UL authorization independently of HARQ mode configuration. For example, based on WTRU DRX behavior, HARQ mode A may be more suitable for HARQ procedures that enable UL HARQ retransmission (e.g., suitable for HARQ procedures that can enable monitoring of HARQ retransmission authorization information), and HARQ mode B may be more suitable for HARQ procedures that disable UL HARQ retransmission (e.g., suitable for HARQ procedures that can enable monitoring of HARQ retransmission authorization information), as further detailed in the embodiments described herein.

[0081] The terms “HARQ Mode A,” “Uplink HARQ Mode A,” “HARQmode A,” and “First Uplink HARQ Mode” are collectively referred to as “HARQ Mode A” and can be used interchangeably throughout the embodiments described herein to refer to an uplink HARQ mode that may be more suitable for enabling UL HARQ retransmissions (e.g., where monitoring of HARQ retransmission authorization information can be enabled). The terms “HARQ Mode B,” “Uplink HARQ Mode B,” “HARQmode B,” and “Second Uplink HARQ Mode” are collectively referred to as “HARQ Mode B” and can be used interchangeably throughout the embodiments described herein to refer to an uplink HARQ mode that may be more suitable for disabling UL HARQ retransmissions (e.g., where monitoring of HARQ retransmission authorization information can be disabled).

[0082] For example, for at least enhanced machine type communication (eMTC) devices, DL HARQ feedback can be either enabled or disabled via a semi-static RRC configuration.

[0083] Example of DRX adaptive The timing for reusing the HARQ procedure ID in subsequent transmissions can be based on whether DL HARQ feedback is enabled or disabled. For example, a HARQ procedure with DL HARQ feedback enabled can use at least one RTT for the WTRU to provide HARQ feedback and receive subsequent transmissions (e.g., retransmissions), while a WTRU procedure with DL HARQ feedback disabled can be reused (e.g., immediately after the last) transmission.

[0084] FIG. 4 This is a system diagram illustrating an example of DRX adaptation based on downlink HARQ feedback state and uplink HARQ feedback mode.

[0085] As shown at 41, the WTRU can determine whether the serving cell is configured to disable downlink HARQ feedback. If the WTRU determines that the serving cell is configured to disable downlink HARQ feedback, as shown at 42, the WTRU can determine whether HARQ feedback is enabled for a HARQ procedure (e.g., ID). If the WTRU determines that HARQ feedback is enabled for a HARQ procedure (e.g., ID), the WTRU can start a retransmission timer (referred to herein as drx-RetransmissionTimerDL) after the transmission. This timer can be delayed by an offset corresponding to the WTRU-gNB RTT, allowing the WTRU to wake up at an appropriate time and monitor the Physical Downlink Control Channel (PDCCH) (e.g., for receiving upcoming transmissions). For example, for a HARQ procedure with HARQ feedback disabled, the WTRU procedure may not perform any subsequent retransmissions. In this case, drx-RetransmissionTimerDL may not be started after the transmission, which improves WTRU energy efficiency. If downlink HARQ feedback is not configured to be disabled for the serving cell, conventional behavior can be applied.

[0086] Similarly, in the UL case, as shown at 43, the WTRU can determine whether the serving cell is configured with uplink HARQ mode. If the WTRU determines that the serving cell is configured with uplink HARQ mode, as shown at 44, the WTRU can determine which HARQ mode can be configured for the HARQ procedure ID. For example, if the WTRU is configured with uplink HARQ mode and the HARQ procedure is configured with HARQ mode A, the WTRU can offset (e.g., delay) the start of the DRX UL retransmission timer (which may be referred to herein as drx-RetransmissionTimerUL) by WTRU-gNB RTT. If the WTRU is configured with HARQ mode B, the WTRU may not start the DRX UL retransmission timer. In the case where no uplink HARQ mode is configured for the serving cell, conventional behavior can be applied.

[0087] In the embodiments described herein, the terms “drx-RetransmissionTimerDL”, “DRX DL retransmission timer”, and “DL retransmission timer” are used interchangeably to refer to the time period during which the WTRU can monitor (e.g., PDCCH) to obtain (e.g., receive) DL retransmissions, for example, as described in Section 5.7 of 3GPP TS 38.321. For example, the DL retransmission timer may be applied to each DL HARQ procedure.

[0088] In the embodiments described herein, the terms “drx-RetransmissionTimerUL”, “DRX UL retransmission timer”, and “UL retransmission timer” are used interchangeably to refer to the time period during which the WTRU can monitor (e.g., PDCCH) to obtain (e.g., receive) UL authorization (e.g., information) for UL retransmission. For example, the UL retransmission timer may be applied to each UL HARQ procedure.

[0089] In the embodiments described herein, the term "DL HARQ RTT timer" can be used to refer to a period of time after which the WTRU can monitor (e.g., PDCCH) to obtain (e.g., receive) DL assignments (e.g., information) for HARQ retransmissions, as described, for example, in Section 5.7 of 3GPP TS 38.321. During this period, it is anticipated that the WTRU may not receive DL assignments (e.g., information) for HARQ retransmissions. For example, the DL HARQ RTT timer can be applied to every DL HARQ procedure.

[0090] In the embodiments described herein, the term "UL HARQ RTT timer" can be used to refer to a period of time after which the WTRU can monitor (e.g., PDCCH) to obtain (e.g., receive) UL HARQ retransmission grants (e.g., information), as described, for example, in Section 5.7 of 3GPP TS 38.321. During this period, it is anticipated that the WTRU may not receive UL HARQ retransmission grants (e.g., information). For example, the UL HARQ RTT timer can be applied to every UL HARQ procedure.

[0091] Example of LCP adaptation The gNB can disable UL HARQ retransmission by sending authorization information indicating a new authorization with a new data indicator (NDI) for switching before waiting for the network decoding result, which may make transmissions sent on (e.g., some) HARQ procedures less reliable than other HARQ procedures. As discussed in the embodiments described herein, a UL HARQ procedure ID configured with HARQ mode A may receive information indicating a UL retransmission authorization based on the network decoding result, while a UL HARQ procedure ID configured with HARQ mode B may not (e.g., the subsequent authorization may be either a blind retransmission authorization or a no-retransmission authorization).

[0092] The configuration of the uplink HARQ mode can imply that the UL authorization assigned to (e.g., certain) HARQ procedures may be more reliable than that of other HARQ procedures. For example, a (e.g., new) LCP restriction (referred to herein as the allowed HARQ mode, e.g., allowedHARQ-Mode) can be used. The allowedHARQ-Mode LCP restriction can indicate, for each logical channel (LCH), that data from that LCH can be mapped to (e.g., associated with) a HARQ procedure ID configured with either HARQ mode A or HARQ mode B. In the absence of either the uplink HARQ mode or the allowed HARQ mode configured, conventional LCP behavior can be applied.

[0093] FIG. 5This is a system diagram illustrating an example of LCP adaptation. For example, the WTRU can receive authorization information indicating uplink authorization for the LCH. At step 51, the WTRU can determine whether a permitted HARQ mode LCP restriction can be configured for the LCH. If a permitted HARQ mode LCP restriction is configured for the LCH, at step 52, the WTRU can determine whether a UL HARQ mode has been configured for the HARQ procedure associated with UL authorization. If a UL HARQ mode has been configured for the HARQ procedure, at step 53, the WTRU can determine whether the permitted UL HARQ mode configured according to the mapping rules can match the UL HARQ mode configured for the HARQ procedure to determine whether the restriction is satisfied.

[0094] Overview Disabling HARQ feedback can affect either DRX or LCP, and the adaptive adjustment of WTRU behavior based on HARQ feedback status (e.g., for DRX and LCP) can rely on (e.g., received) RRC configuration information (e.g., downlink HARQ feedback is disabled, uplink HARQ mode, and allowed HARQ modes). For example, (e.g., received) RRC configuration (e.g., information) may not be suitable for lower-capacity applications such as Reduced Capability (RedCap) and Narrowband Internet of Things (NB-IoT). For example, NB-IoT may support fewer HARQ procedures (e.g., one or two), making the flexibility to enable or disable a set of HARQ procedures potentially less. For example, RRC reconfiguration may not be supported, making it impossible to change the configuration after the initial connection setup.

[0095] The embodiments described herein can allow indication of whether HARQ feedback is enabled or disabled via means other than RRC configuration information (e.g., such as DCI-based indications). The embodiments described herein can allow adaptation of DRX and LCP operation for DCI-based solutions. For example, with L1-based (e.g., DCI) indications for enabling / disabling either DL HARQ feedback and providing (e.g., indicating) UL HARQ mode, the embodiments described herein can allow adaptation of either DRX timers and LCP limits.

[0096] This document describes embodiments of reduced-capacity and IoT devices. The embodiments described herein are not limited to those reduced-capacity and IoT devices, and can be equally applied to any device, technology, and / or environment that supports L1-based indications of HARQ feedback status information.

[0097] Throughout the embodiments described herein, the terms “DCI-based indication,” “physical layer information indicating…,” and “L1-based indication” are collectively referred to as “L1 indication” and are used interchangeably to refer to a technique that uses L1 (e.g., physical layer) information to indicate a message. The embodiments described herein are not limited to DCI-based indications and can be applied to any other L1-based method capable of indicating whether downlink HARQ feedback is either enabled or disabled and / or indicating uplink HARQ mode.

[0098] Throughout the embodiments described herein, the terms “HARQ state” and “HARQ feedback state” may be used interchangeably to refer to either (i) DL HARQ feedback is enabled or disabled, and (ii) UL HARQ mode (e.g., A or B) is configured, for example, for use in at least one HARQ process.

[0099] This document describes an embodiment for using L1-based indications (e.g., whether HARQ feedback is enabled or disabled) from the adapted DRX and / or LCP based on the HARQ feedback status.

[0100] Example of L1 indication of HARQ feedback status This article describes L1 indications (e.g., how WTRU can determine the HARQ feedback state (e.g., based on DCI)) in more detail.

[0101] In an embodiment, the WTRU can receive information (e.g., an indication) in L1 indicating the HARQ feedback status (e.g., whether DL HARQ feedback can be enabled or disabled and / or whether UL HARQ mode A or B can be configured). This indication (e.g., the information) can be explicit or implicit. This indication (e.g., the information) can work independently of or in conjunction with one or more RRC configurations (e.g., it can be used for any of the following: (1) enabling HARQ feedback, (2) disabling HARQ feedback, and (3) configuring a HARQ mode for either (i) the HARQ process and (ii) LCP mapping constraints).

[0102] For example, the WTRU can receive information (e.g., an indication) indicating the HARQ feedback status within the DCI. In one example, this indication (e.g., information) may exist within a DL assignment, where the indication (e.g., information) may refer to the HARQ feedback behavior received by the corresponding DL. In another example, the indication (e.g., information indicating the HARQ status) may exist within a UL authorization, where the indicated HARQ behavior may refer to the corresponding UL transmission.

[0103] In an embodiment, the WTRU may receive information via DCI indicating (e.g., an indication) the following: (1) the HARQ feedback status of the associated HARQ process (e.g., whether HARQ feedback is enabled or disabled) and / or (2) HARQ mode behavior. This indication may represent one or more of the following information examples: In the example, this information can indicate whether DL HARQ feedback is enabled or disabled for the scheduled physical downlink shared channel (PDSCH) in DCI.

[0104] In another example, this information can indicate whether DL HARQ feedback is enabled or disabled for all HARQ procedures.

[0105] In yet another example, this information could indicate whether DL HARQ feedback is enabled or disabled for a subset of HARQ procedures, where the subset can be configured via higher-level signaling (e.g., such as RRC) (e.g., indicated by receiving configuration information). For example, the WTRU could receive configuration information indicating one or more subsets of HARQ procedures, where each (e.g., each) subset of the HARQ procedure can be configured with an index (e.g., associated with it). The index can be indicated in the DCI (e.g., included therein).

[0106] In yet another example, this information could indicate that DLHARQ feedback can be disabled except for PDSCHs carrying MAC control elements (MAC-CE). For instance, if the WTRU receives this indication, it can skip HARQ feedback for the PDSCH except when the PDSCH carries the MAC-CE.

[0107] In yet another example, this information could indicate whether DL HARQ feedback is enabled or disabled for all HARQ procedures other than those that can be used for MAC-CE transmission. The HARQ procedures carrying MAC-CE can be, for example, configured, determined, and indicated by the gNB. The HARQ procedures carrying MAC-CE can be implicitly determined, for example, based on the HARQ procedure number (e.g., any of the lowest HARQ procedure identifier, highest HARQ procedure identifier, etc.).

[0108] In yet another example, this information could indicate UL HARQ mode A.

[0109] In yet another example, this information could indicate UL HARQ mode B.

[0110] In yet another example, this information could indicate the switching of HARQ feedback behavior for that HARQ procedure (e.g., unless otherwise indicated, all subsequent DCIs addressed to that HARQ procedure could have the same HARQ feedback state).

[0111] In yet another example, this information can indicate the RRC configuration that overrides the HARQ procedure.

[0112] Throughout the embodiments described herein, the term "enabling / disabling HARQ feedback" may be used interchangeably with "activating / deactivating HARQ feedback".

[0113] In embodiments, information related to the HARQ feedback state (e.g., indicating the HARQ feedback state) may be indicated (e.g., transmitted), and / or the WTRU may determine the HARQ feedback state via one or more of the following method examples.

[0114] In the example, explicit flags within the DCI can indicate the HARQ feedback status (e.g., a flag set to 1 can correspond to DL HARQ feedback being enabled, while a flag set to 0 can correspond to HARQ feedback being disabled, and vice versa. Similarly, flags can correspond to (e.g., indicate) UL HARQ mode A or UL HARQ mode B).

[0115] In another example, the HARQ feedback status can be indicated based on the DCI format. For example, one or more DCI formats can be configured (e.g., the WTRU can receive configuration information indicating one or more DCI formats). When the WTRU receives a specific DCI format (e.g., a DCI format indicated by the gNB as associated with and / or corresponding to either HARQ feedback enabling or disabling), the WTRU can determine whether to disable or enable the HARQ feedback associated with the HARQ process based on the DCI format. For example, when the WTRU receives a first DCI format for PDSCH (e.g., DCI format A), the WTRU can determine that the associated HARQ feedback can be disabled (e.g., for subsequent DL assignments addressing to the HARQ process), and when the WTRU receives a second DCI format for PDSCH (e.g., DCI format B), the WTRU can determine that the associated HARQ feedback can be enabled (e.g., for subsequent DL assignments addressing to the HARQ process).

[0116] In another example, the WTRU can determine the HARQ feedback state based on a Radio Network Temporary Identifier (RNTI) scrambled with the Cyclic Redundancy Check (CRC) of the scheduled DCI. For example, if the DCI format of the scheduled PDSCH is scrambled with a first cell RNTI (C-RNTI) (e.g., C-RNTI-1), the WTRU can determine that HARQ feedback for the scheduled PDSCH can be disabled; if the DCI format of the scheduled PDSCH is scrambled with a second C-RNTI (e.g., C-RNTI-2), the WTRU can determine that HARQ feedback for the scheduled PDSCH can be enabled. The WTRU can be configured with one or more C-RNTIs (e.g., receiving configuration information indicating one or more C-RNTIs), and (e.g., each) a C-RNTI can be associated with a HARQ feedback state (or mode). If the WTRU is configured with a single HARQ procedure, HARQ disabling may not be supported, and a single C-RNTI (e.g., C-RNTI-1) can be used. In cases where HARQ disabling is not supported (e.g., based on WTRU capability), WTRU can be configured with a single C-RNTI.

[0117] In yet another example, the WTRU can determine the HARQ feedback status based on the PDCCH search space. For example, one or more PDCCH search spaces can be configured (e.g., indicated by received configuration information) or used; and (e.g., each) PDCCH search space can be associated with a HARQ feedback status (e.g., enabled or disabled). If the WTRU receives a DCI in a first PDCCH search space (e.g., the first search space is associated with HARQ feedback enabled), the WTRU can determine that HARQ feedback can be enabled for the scheduled PDSCH. If the WTRU receives a DCI in a second PDCCH search space (e.g., the second search space is associated with HARQ feedback disabled), the WTRU can determine that HARQ feedback can be disabled for the scheduled PDSCH. Throughout the embodiments described herein, the term "PDCCH search space" can be used interchangeably with "search space identifier," "control resource set (CORESET)," "PDCCH candidate," and "PDCCH search area identifier."

[0118] In yet another example, the WTRU can determine the HARQ feedback state based on scheduling information such as transport block size (TBS) and repetition. For instance, the HARQ feedback state (e.g., enabled / disabled) can be determined based on scheduling parameters of the PDSCH, including any of the following: TBS, modulation and coding scheme (MCS), number of repetitions, demodulation reference signal (DMRS) density, NDI, HARQ procedure number, number of layers, number of codewords, and DMRS port indication.

[0119] Example of L1 indication of HARQ feedback status to higher layers This document describes in more detail an embodiment for indicating the HARQ feedback status to a higher layer (e.g., MAC).

[0120] In an embodiment, the WTRU may (e.g., always) indicate the HARQ feedback status (or L1 indication) to a higher layer when the WTRU can receive a DL DCI that can schedule the PDSCH (e.g., afterward).

[0121] In another embodiment, the WTRU may indicate the HARQ feedback status to a higher layer if one or more of the following conditions are met.

[0122] In the example, if the HARQ feedback state indicated in the DCI is different from the HARQ feedback state configured, for example via higher-level signaling (e.g., RRC configuration), the WTRU may indicate the HARQ feedback state to the higher level.

[0123] In another example, if the HARQ feedback state indicated in the DCI differs from a previous HARQ feedback state (e.g., the previously indicated HARQ feedback state), the WTRU can indicate the HARQ feedback state to a higher layer. For example, the WTRU can be instructed (e.g., by receiving the following instruction) to enable HARQ feedback for the PDSCH in the DCI in a first time slot, and the WTRU can be instructed (e.g., by receiving the following instruction) to disable HARQ feedback for the PDSCH in the DCI in a second time slot, where the first time slot may be earlier than the second time slot.

[0124] In yet another example, where a time slot is configured such that the WTRU can indicate the HARQ feedback status to a higher layer, the configuration of the time slot for indicating the HARQ feedback status to a higher layer can be (e.g., based on) periodic reporting.

[0125] In another example, if the number of disabled (or enabled) HARQ processes meets a condition (e.g., exceeds a certain value (e.g., a threshold)), the WTRU can indicate the HARQ feedback status to a higher layer, where the value (e.g., the threshold) can be either predetermined, configured, or indicated by the gNB.

[0126] In yet another example, if HARQ feedback is disabled for all HARQ processes, WTRU can indicate the HARQ feedback status to higher levels.

[0127] In an embodiment, the gNB (e.g., in the DCI) may instruct the WTRU to report the HARQ feedback status to a higher layer.

[0128] In the embodiments described herein, the term "HARQ feedback state" may be used interchangeably with "L1 indication", "L1 HARQ state indication", "L1 state of HARQ feedback state" and "L1 indication of HARQ feedback state".

[0129] In an embodiment, an L1 indication (e.g., a HARQ feedback status indicated to a higher layer) may include one or more of the following information.

[0130] In the example, the L1 indicator may include information indicating whether HARQ feedback is enabled or disabled.

[0131] In another example, the L1 indication may include information indicating whether the HARQ feedback status has changed (e.g., from enabled to disabled, from activated to deactivated, etc.).

[0132] In yet another example, the L1 indication may include information indicating the number of HARQ procedures that are disabled (or enabled).

[0133] In yet another example, the L1 instruction may include information indicating a list of HARQ procedures that are disabled (or enabled).

[0134] In yet another example, the L1 indicator may include information indicating, for example, the ratio between HARQ feedback enabled and HARQ feedback disabled within a window.

[0135] In yet another example, the L1 indication may include information indicating the duration of the indication.

[0136] Example of higher-level adaptation based on L1 indication of HARQ feedback state This paper describes the effects and adaptations of L1 indices on DRX and LCP.

[0137] In embodiments, the WTRU can adapt to higher-level processes (e.g., either DRX or LCP) based on HARQ feedback state indications (e.g., L1 indications) from lower layers. These adaptations can allow WTRU behavior to be enabled based on the indicated HARQ feedback state, for example, in the absence of default behavior or RRC configuration. The WTRU actions (e.g., operations) described herein can vary according to one or more of, for example: In the first example, WTRU actions (e.g., operations) can be based on whether an RRC configuration that enables / disables HARQ feedback has been configured.

[0138] In the second example, WTRU actions (e.g., operations) can be based on the indicated HARQ procedure.

[0139] In another example, WTRU actions (e.g., operations) can be based on the number of HARQ procedures supported by WTRU.

[0140] In yet another example, WTRU actions (e.g., operations) can be based on the serving cell from which a bearer instruction may have already been received.

[0141] In yet another example, WTRU actions (e.g., operations) can be based on what is indicated (e.g., whether the HARQ procedure is indicated to enable or disable HARQ feedback).

[0142] In yet another example, WTRU actions (e.g., operations) can be based on device type (e.g., whether the device is classified as NB-IoT, eMTC, WTRU, VSAT, or RedCap).

[0143] In yet another example, WTRU actions (e.g., operations) can be based on satellite characteristics (e.g., whether the satellite belonging to the serving cell is in geostationary orbit (GSO) or non-GSO, in the case where the WTRU is connected to a non-terrestrial network).

[0144] In yet another example, WTRU actions (e.g., operations) can be based on WTRU-gNB RTT (e.g., its length).

[0145] In yet another example, WTRU actions (e.g., operations) can be based on whether the DCI indicates that it is part of a DL assignment or a UL authorization.

[0146] Example of maintaining HARQ feedback state in a HARQ process In the example, the HARQ feedback state can be maintained in either a new state or a variable (e.g., in the absence of RRC configuration or in the absence of a default state). The new variable can be maintained for example for any of the following: (1) each HARQ procedure, (2) each serving cell, (3) all HARQ procedures, and (4) HARQ procedures that may not have a configured HARQ feedback state (e.g., not configured as enabled, disabled, HARQ mode A, and HARQ mode B).

[0147] In the example, upon receiving an L1 instruction, the WTRU can set either a state or a variable to the value within the L1 instruction for the corresponding HARQ process instruction that can assign UL authorization and / or DL ​​assignment (e.g., enabling HARQ feedback, disabling HARQ feedback, HARQ mode A, or HARQ mode B). For example, subsequent UL authorization and / or DL ​​assignments addressed to this HARQ process can follow this HARQ feedback state, e.g., until the L1 instruction can change (e.g., switch) the state value.

[0148] In the example, the state can be applied and / or can be changed based on subsequent transmissions and / or indications from the network. For example, in the case of an L1 indication switching HARQ feedback and / or HARQ mode, the WTRU can update the HARQ state after acknowledging and / or transmitting the corresponding UL transmission (e.g., in the case of L1 indication provided via UL authorization), receiving DL HARQ feedback (indicating DL assignment), and / or receiving the corresponding DL transmission associated with the DL assignment.

[0149] Example of DRX adaptation based on instructions within DL assignment In the example, the WTRU and / or MAC entity may adapt DRX behavior based on indications from lower layers (e.g., either L1 or L2). For example, upon receiving a DL assignment carrying an L1 indication and / or upon receiving a corresponding DL transport, if the L1 indication indicates that DL HARQ feedback is enabled, the WTRU may perform one or more of the following operations, for example.

[0150] In the operational example, WTRU can extend the length of the DL HARQ RTT timer by at least WTRU-gNB RTT.

[0151] In another operational example, the WTRU can offset the start of the DL HARQ RTT timer by WTRU-gNB RTT. During the time period corresponding to (e.g., extended, offset) the DL HARQ RTT, the WTRU can, for example, not monitor the downlink control channel (e.g., PDCCH) to save power.

[0152] In yet another operational example, WTRU can set the start offset of the DL retransmission timer to WTRU-gNB RTT.

[0153] In yet another operational example, the WTRU can extend the length of the DL retransmission timer to WTRU-gNB RTT. During the time period corresponding to the (e.g., extended, offset) DL retransmission time, the WTRU can, for example, monitor the downlink control channel to receive retransmissions.

[0154] In another operational example, the WTRU can start a new timer (e.g., a MAC timer) with a length equal to the sum of the DL HARQ RTT timer and the WTRU-gNBRTT. While the timer may be running, the WTRU may not monitor the downlink control channel (e.g., the PDCCH). After the timer expires, the WTRU may, for example (e.g., start), monitor the downlink control channel (e.g., the PDCCH) and may start the DL retransmission timer.

[0155] In yet another operational example, the WTRU may enter DRX active time. Throughout the embodiments described herein, "entering DRX active time" can be understood as monitoring the downlink control channel (e.g., PDCCH) to detect (e.g., receive) transmissions, for example, directed to the WTRU.

[0156] If the L1 instruction indicates that DL HARQ feedback can be disabled (e.g., for either DL assignment or the HARQ process), the WTRU may perform one or more of the following operations, for example.

[0157] In the operational example, WTRU may not start the DL HARQ RTT timer.

[0158] In another operational example, the WTRU may not initiate the DL retransmission timer. For instance, the WTRU may monitor the downlink control channel (e.g., PDCCH) based on a different DRX timer than the DL HARQ RTT timer and / or the DL retransmission timer (e.g., either an inactive timer associated with other HARQ procedures and the DL retransmission timer).

[0159] In yet another operational example, the WTRU can enter the DRX active time (e.g., and can start the DL retransmission timer).

[0160] In yet another operational example, the WTRU can start a new timer (for example, the WTRU can monitor the PDCCH while the timer may be running).

[0161] Example of DRX Adaptation Based on Instructions Within UL Authorization In the example, the WTRU and / or MAC entities may adapt DRX behavior based on information (e.g., indications) from lower layers provided (e.g., received) within the UL authorization. This indication (e.g., physical layer information, L1 indication) may indicate (e.g., indicate) any of the following: (i) UL HARQ retransmission may be enabled, (ii) UL HARQ retransmission may be disabled, (iii) DRX adaptation may be based on HARQ mode A, and (iv) DRX adaptation may be based on HARQ mode B.

[0162] Where an L1 indication indicates (e.g., an indication) that UL HARQ retransmission can be enabled and / or that DRX can be adapted based on HARQ mode A, after the corresponding UL transmission indicated within the UL authorization has been transmitted, the WTRU may perform one or more of the following operations, for example.

[0163] In the operational example, after transmitting the corresponding UL transmission indicated within the UL authorization, the WTRU can extend the length of the UL HARQRTT timer to WTRU-gNB RTT.

[0164] In another operational example, after transmitting the corresponding UL transmission indicated within the UL license, the WTRU can offset the start of the ULHARQ RTT timer by WTRU-gNB RTT. For example, the WTRU can adjust the downlink control channel monitoring delay to correspond to a period of time (e.g., extended, offset) of the UL HARQ RTT timer (e.g., to save power).

[0165] In another operational example, after transmitting the corresponding UL transmission indicated within the UL authorization, the WTRU can set the start offset of the UL retransmission timer to WTRU-gNB RTT.

[0166] In another operational example, after transmitting the corresponding UL transmission indicated within the UL grant, the WTRU can extend the length of the UL retransmission timer to WTRU-gNB RTT. For example, the WTRU can monitor the downlink control channel for a period corresponding to (e.g., extended, offset) the UL retransmission timer (e.g., to receive either acknowledgment or HARQ retransmission grant information). For example, if no acknowledgment is received within this period, the WTRU can retransmit the UL transmission.

[0167] In yet another operational example, after the corresponding UL transmission indicated within the UL authorization has been transmitted, the WTRU can start a new timer (e.g., a MAC timer).

[0168] In another operational example, after transmitting the corresponding UL transmission indicated within the UL license, the WTRU can enter the DRX active period. The length of the new timer (e.g., a MAC timer) can be equal to the sum of the UL HARQ RTT timer and the WTRU-gNBRTT. While the timer may be running (e.g., for a period of time corresponding to the new timer), the WTRU may not (e.g., not expected to) monitor the downlink control channel (e.g., the PDCCH). After the new timer expires (e.g., after the amount of time corresponding to the new timer may have elapsed), the WTRU may, for example (e.g., start) monitor the downlink control channel (e.g., the PDCCH) and may start the UL retransmission timer.

[0169] Where an L1 indication indicates (e.g., an indication) that UL HARQ retransmission can be disabled and / or that DRX can be adapted based on HARQ mode B, after the corresponding UL transmission indicated within the UL authorization has been transmitted, the WTRU may perform one or more of the following operations, for example.

[0170] In the operational example, after transmitting the corresponding UL transmission indicated within the UL authorization, the WTRU may not start the ULHARQ RTT timer.

[0171] In another operational example, after transmitting the corresponding UL transmission indicated within the UL authorization, the WTRU may not initiate the UL retransmission timer. For example, the WTRU may monitor the downlink control channel (e.g., PDCCH) based on other DRX timers (e.g., such as inactive timers and retransmission timers associated with other HARQ procedures) that are different from the UL HARQ RTT timer and / or the UL retransmission timer.

[0172] In another operational example, after transmitting the corresponding UL transmission indicated within the UL authorization, the WTRU can enter the DRX active time (e.g., without starting the UL retransmission timer).

[0173] In another operational example, after transmitting the corresponding UL transmission indicated within the UL license, the WTRU can start a new timer during which the WTRU can monitor the downlink control channel (PDCCH).

[0174] Example of L1-based DRX adaptive duration In an embodiment, the WTRU may apply adaptive DRX behavior (e.g., adaptive DRX operation) for any of, for example, a specific duration, one or more transmissions, and one or more HARQ processes. For example, the WTRU may adapt DRX behavior based on L1 indications according to one or more of the following examples.

[0175] In the first example, the WTRU can adapt its DRX behavior to transports scheduled by UL authorization and / or DL ​​assignment, including L1 indication.

[0176] In another example, the WTRU can adapt its DRX behavior for the next X transmissions and / or receptions used for and / or assigned to the HARQ process, where X can be any integer (e.g., a fixed integer).

[0177] In yet another example, the WTRU can adapt DRX behavior for (e.g., all) transmissions of a particular HARQ procedure (e.g., the WTRU can adapt DRX behavior based on an L1 indication until a subsequent L1 indication addressing the same HARQ procedure can be received, where the L1 indication can indicate a change in DRX behavior).

[0178] In yet another example, the WTRU can adapt DRX behavior for (e.g., all) HARQ procedures belonging to the serving cell.

[0179] In yet another example, WTRU can adapt DRX behavior for (e.g., all) HARQ procedures that belong to a MAC entity.

[0180] In yet another example, the WTRU can adapt DRX behavior for (e.g., all) UL HARQ procedures belonging to (e.g., all) serving cells or MAC entities.

[0181] In yet another example, the WTRU can adapt DRX behavior for a configured and / or indicated duration. For instance, the WTRU may have already received information indicating the duration for which DRX adaptation can be performed.

[0182] In an embodiment, the WTRU may apply one or more of the behaviors according to any embodiment described herein based on one or more of the following: (i) explicit instructions from a lower layer (e.g., receiving explicit information indicating one or more behaviors), (ii) receiving information indicating one or more behaviors to be applied (e.g., RRC configuration), (iii) the number of HARQ procedures, and (iv) whether the HARQ procedures are UL or DL ​​HARQ procedures.

[0183] Example of L1-based DRX adaptive configuration In embodiments, the WTRU may determine whether to adapt DRX behavior based on L1 indications (e.g., indications within the DCI) rather than on (e.g., explicit) configuration information. For example, the WTRU may receive configuration information, for instance, via an indication to enable or disable L1-based DRX adaptation in RRC. In the embodiments described herein, the terms “enable / disable L1-based DRX adaptation” and “enable / disable L1-based indication of HARQ state” are used interchangeably to refer to enabling / disabling an operating mode for the WTRU, where the HARQ state can be adjusted (e.g., modified) according to the L1-based indication. This configuration information may indicate that DRX can adapt DRX for all HARQ procedures or at the granularity (e.g., level, basis) of each HARQ procedure. This configuration information may be combined, for instance, with other configuration information indicating whether HARQ feedback can be enabled or disabled for each HARQ procedure (e.g., downlink HARQ feedback disable information).

[0184] In embodiments, the configuration information (e.g., RRC) may include additional fields (e.g., elements) indicating whether DL HARQ feedback is enabled or disabled. For example, the configuration information (e.g., RRC) may indicate three states: 1) DL HARQ feedback is enabled; 2) DL HARQ feedback is disabled; and 3) DL HARQ feedback is controlled by an L1 indication. When a HARQ process is configured to enable or disable DL HARQ feedback, the WTRU may apply the behavior indicated by the (e.g., RRC) configuration information. When a HARQ process is configured with HARQ feedback controlled by an L1 indication, the WTRU may apply DRX behavior based on the L1 indication. For example, an additional HARQ mode (e.g., HARQ mode C) may be used in the (e.g., RRC) configuration information to indicate that DRX behavior can be controlled based on an L1 indication within the UL authorization.

[0185] In an embodiment, an L1 indication indicating a specific HARQ feedback behavior may have already been received, and the HARQ procedure may have been pre-configured with HARQ feedback behavior (e.g., by receiving RRC configuration information). In the event of a conflict between the indication provided by the L1 indication and the (e.g., RRC) configuration information, the WTRU may perform one or more of the following actions (e.g., operations): In the first operational example, the L1 instruction can (e.g., always) override the RRC configuration.

[0186] In another operational example, the L1 indicator can change the RRC configuration (e.g., the L1 indicator can reconfigure the RRC configuration).

[0187] In yet another operational example, the L1 indication can override the RRC configuration based on one or more conditions, such as for one or more HARQ process IDs, based on any of the following: transmission priority, number of repetitions, TBS size.

[0188] In another operational example, the RRC configuration can override the L1 indication. For instance, the L1 indication can be ignored based on the RRC configuration information.

[0189] The actions (e.g., operations) described herein may vary, for example, depending on each WTRU, each HARQ procedure, each MAC entity, and / or each serving cell. The actions that a WTRU can perform may depend, for example, on (e.g., based on) the WTRU configuration.

[0190] Example of WTRU behavior without L1 instruction reception In an embodiment, the WTRU may be able to adapt to DRX behavior. For example, the WTRU is expected to receive an L1 indication to determine how to adapt to DRX behavior. For example, the WTRU may have received configuration information indicating that the HARQ process can be configured with "DL HARQ feedback controlled by L1 indication" or "HARQ mode C". If the expected L1 indication is not received, the WTRU may assume (e.g., apply) one or more of the following: In the absence of an L1 indication, the WTRU may apply default behavior. For example, default behavior may include one or more DRX adaptations according to any of the embodiments described herein, and may be provided (e.g., received) or indicated (e.g., within system information) via configuration information.

[0191] Without receiving an L1 instruction, the WTRU can apply the conventional behavior for DRX operations (e.g., the WTRU-gNB RTT can be omitted from the DRX process).

[0192] If no L1 indication is received, the WTRU can adaptively apply the DRX indicated by the last received L1 indication to the corresponding HARQ procedure.

[0193] In the absence of an L1 instruction, the WTRU may apply the DRX behavior indicated via the RRC configuration (if available).

[0194] Example of Logical Channel Prioritization (LCP) Adaptation In an embodiment, the WTRU may be configured with LCP restrictions (e.g., receiving configuration information indicating LCP restrictions), which may map (e.g., associate) logical channels (LCHs) to a HARQ procedure configured with (e.g., a given) HARQ mode (e.g., HARQ mode A or HARQ mode B). For example, the WTRU may take into account L1 indications (e.g., determined via DCI indications within UL authorization) during the LCP procedure.

[0195] In an embodiment, the WTRU may adapt the LCP based on physical layer information received in the DCI, such as HARQ state information indicated by L1.

[0196] For example, the LCH mapping constraint within the LCP process can be reused.

[0197] For example, the WTRU can interpret physical layer information (e.g., L1 indication) as indicating either HARQ mode A or HARQ mode B. When an LCH is configured with LCH mapping restrictions in which limitations are mapped to (e.g., associated with) a specific HARQ mode and the L1 indication within the UL grant matches the configured HARQ mode, the WTRU can map (e.g., associate) data from that logical channel to the UL grant. In another example, if the HARQ mode indicated within the LCH mapping restrictions does not match the HARQ mode indicated within the L1 indication in the UL grant, data from that LCH may not be mapped to (e.g., associated with) the UL grant.

[0198] Example of DRX adaptation based on L1 indication In an embodiment, the WTRU may receive information (e.g., indications and / or configuration information) that indicates that HARQ status information can be provided and / or modified via L1-based indications. This information (e.g., configuration and / or indications) may be applied to any of the following: (i) each serving cell, (ii) each HARQ procedure, (iii) the UL HARQ procedure, (iv) the DL HARQ procedure, and (v) all HARQ procedures.

[0199] The WTRU can receive information indicating HARQ status information (e.g., within either UL authorization or DL ​​assignment). HARQ status information can indicate any of the following, for example: (i) HARQ feedback can be enabled, (ii) HARQ feedback may be disabled, (iii) HARQ mode A, (iv) HARQ mode B, (v) HARQ feedback and / or HARQ mode may differ from the RRC configuration, and (vi) HARQ feedback may differ from previously indicated HARQ feedback status information.

[0200] In the example, the indication of HARQ status information (e.g., indication of HARQ status information information) may be provided and / or determined via any of the following: (i) explicit flags within the DCI, (ii) based on the DCI format, (iii) based on the RNTI scrambled with the CRC of the scheduled DCI, (iv) the PDCCH search space, and (v) scheduling information (e.g., any of the following such as TBS size, number of repetitions). HARQ status information may be applied to, for example, any of the following: (i) UL transmissions authorized and scheduled by the UL, (ii) DL receptions assigned and scheduled by the DL, (iii) one or more subsequent transmissions on a HARQ process, and (iv) a set of HARQ processes (e.g., any of the following such as one or more HARQ processes, UL HARQ processes, and DL HARQ processes).

[0201] The WTRU can indicate HARQ status information to a higher layer (e.g., MAC). Instructions to the higher layer can include, for example, any of the following: (i) HARQ feedback status (e.g., indicating whether HARQ feedback is enabled and / or disabled), (ii) HARQ mode (e.g., indicating either HARQ mode A or HARQ mode B), and (iii) the duration and / or granularity of the instruction (e.g., indicating whether the instruction applies to a particular transmission and / or reception, or whether the instruction applies to one or more or a set of HARQ procedures). For example, the instruction can be provided to the higher layer after it may have already been received. In another example, the instruction can be provided to the higher layer if, for example, the HARQ status information differs from HARQ status information configured via higher-layer signaling (e.g., such as RRC), and (ii) the HARQ status signal differs from previously indicated HARQ (e.g., feedback) status information.

[0202] Upon receiving physical layer information (e.g., an L1 indication of HARQ status information), the WTRU can, for example, adapt its DRX behavior based on the indicated HARQ status information. When the L1 indication indicates that DL HARQ feedback can be enabled, the WTRU can perform any of the following: (i) modify the DL HARQ RTT timer (e.g., extend the length of WTRU-gNB RTT or start an offset WTRU-gNB RTT); (ii) modify the DL retransmission timer (e.g., start an offset WTRU-gNB RTT or extend WTRU-gNB RTT); (iii) start a new timer; and (iv) enter DRX active time (e.g., monitor the PDCCH). When the L1 indication indicates that DL HARQ feedback can be disabled, the WTRU can perform any of the following: (i) do not start the DL HARQ RTT timer; (ii) do not start the DL retransmission timer and do not start a new timer.

[0203] When the L1 indication signals that UL HARQ retransmission is enabled and / or indicates HARQ mode A, the WTRU may perform any of the following: (i) modify the UL HARQ RTT timer (e.g., extend the length of WTRU-gNB RTT or start an offset WTRU-gNB RTT), (ii) modify the UL retransmission timer (e.g., start an offset WTRU-gNB RTT or extend WTRU-gNB RTT), (iii) start a new timer, and (iv) enter DRX active time (e.g., monitor the PDCCH). When the L1 indication signals that UL HARQ retransmission is disabled and / or indicates HARQ mode B, the WTRU may perform any of the following: (i) not start the UL HARQ RTT timer; (ii) not start the UL retransmission timer and not start a new timer (so that subsequent transmissions can be transmitted).

[0204] In the example, the WTRU may apply DRX behavior for a specific duration (e.g., such as any of the following: (i) for (e.g., a specific) transmission and / or reception, (ii) for the next X transmissions and / or receptions, (iii) indefinitely, and (iv) until a subsequent indication can be received). Either the L1 indication or (e.g., RRC) configuration information can indicate the duration for which the WTRU may apply DRX behavior. The WTRU may apply DRX behavior to, for example, any of the following: (i) a specific HARQ procedure, (ii) one or more HARQ procedures (e.g., a set of HARQ procedures, (e.g., all) ULHARQ procedures, and (e.g., any of all) DL HARQ procedures), and (iii) (e.g., all) HARQ procedures.

[0205] In the event of a conflict between the L1 indication and a higher-level configuration, the WTRU may operate, for example, according to any of the following: (i) the L1 indication (e.g., always) overrides the RRC configuration; (ii) the L1 indication changes the RRC configuration (e.g., the L1 indication may reconfigure the RRC configuration); (iii) the L1 indication overrides the RRC configuration based on one or more conditions (e.g., based on any of the following: transport priority, number of repetitions, TBS size, or one or more HARQ process IDs); and (iv) the RRC configuration overrides the L1 indication.

[0206] FIG. 6 This is a system diagram illustrating an example method for using L1-based indices from the adaptive DRX.

[0207] As shown at 610, the WTRU can receive first configuration information that indicates, for example, whether HARQ feedback can be enabled or disabled for one or more HARQ procedures.

[0208] As shown at 620, the WTRU can receive second configuration information indicating whether DRX adaptation can be enabled or disabled, for example, for one or more HARQ procedures based on an L1-based indication. For example, the first and second configuration information can be received in one or more (e.g., RRC) messages. For example, configuration information indicating either: (i) an L1-based indication of the HARQ state and (ii) a first HARQ state. For example, a first DRX operation can be performed based on the first HARQ state.

[0209] As shown at 630, WTRU can determine whether the serving cell is configured to disable downlink HARQ feedback.

[0210] As shown at 640, the WTRU can receive an L1 indication that indicates the HARQ feedback status of one or more HARQ processes.

[0211] As shown at 650, the WTRU can determine whether DRX adaptation is enabled or disabled for one or more HARQ procedures associated with the received L1 indication.

[0212] If the WTRU determines that DRX adaptation can be enabled for one or more HARQ processes, as shown at 660, the WTRU can determine whether an L1 indication indicates that HARQ feedback is enabled for one or more HARQ processes. For example, a DCI can be received, and the WTRU can determine, based on an L1-based indication that a HARQ state can be enabled according to configuration information, that the DCI can indicate a second HARQ state. For example, a second DRX operation can be performed based on the second HARQ state.

[0213] If the WTRU determines that HARQ feedback can be enabled by the L1 indication, the WTRU can retransmit the DRX retransmission DL timer start offset WTRU-gNB RTT, as shown at 670.

[0214] FIG. 7 This is a system diagram illustrating an example method 700 for L1-based indication from an adaptive DRX. For example, this method can be implemented in a WTRU. As shown at 710, the WTRU can receive downlink control information indicating HARQ status information. As shown at 720, the WTRU can perform discontinuous reception based on the HARQ status information.

[0215] In various embodiments, HARQ status information can be indicated in either uplink authorization information or downlink assignment information.

[0216] In various embodiments, the HARQ status information may indicate any of the following: (i) downlink HARQ feedback is enabled, (ii) downlink HARQ feedback is disabled, (iii) a first uplink HARQ mode, and (iv) a second uplink HARQ mode.

[0217] In various embodiments, HARQ status information may indicate a first uplink HARQ mode, which may be different from a second uplink HARQ mode indicated by previous HARQ status information.

[0218] In various embodiments, HARQ status information may indicate a first downlink HARQ feedback state, which may differ from a second downlink HARQ feedback state indicated by previous HARQ status information.

[0219] In various embodiments, HARQ status information may be applied to any of the following: (i) uplink transmissions scheduled by uplink grants of downlink control information, (ii) downlink receptions scheduled by downlink assignments of downlink control information, and (iii) one or more subsequent transmissions of one or more HARQ procedures.

[0220] In various embodiments, HARQ status information can indicate that downlink HARQ feedback can be enabled, and performing DRX can include: monitoring the delay based on the WTRU to base station round-trip time to receive subsequent transmissions (e.g., retransmissions).

[0221] In various embodiments, HARQ status information may indicate a first uplink HARQ mode, and performing DRX may include retransmitting uplink transmissions that have not been acknowledged for at least a period including the WTRU-to-base station round-trip time.

[0222] In various embodiments, HARQ status information may indicate a second uplink HARQ mode, and performing DRX may include monitoring the downlink control channel for receiving subsequent transmissions during a time period different from the uplink retransmission time period.

[0223] In various embodiments, DRX can be performed based on HARQ state information until subsequent HARQ state information can be indicated in subsequent downlink control information.

[0224] In various embodiments, DRX can be executed according to default behavior after a period of time based on HARQ state information.

[0225] In various embodiments, the method may further include receiving configuration information indicating that HARQ state information can be modified based on information indicated by downlink control information.

[0226] In various embodiments, HARQ state information may be applied to any of the following: (i) each serving cell, (ii) each HARQ procedure, (iii) uplink HARQ procedure, (iv) downlink HARQ procedure, or (iv) all HARQ procedures.

[0227] FIG. 8This is a diagram illustrating an example method 800 for using L1-based indication from adaptive DRX. Method 800 can be implemented in a WTRU. As shown at 810, the WTRU can receive configuration information indicating (1) a DCI-based indication of the HARQ state and (2) a first HARQ state associated with a HARQ procedure. As shown at 820, the WTRU can perform a first DRX operation based on the first HARQ state. As shown at 830, the WTRU can receive a DCI. As shown at 840, the WTRU can determine, based on the configuration information, that the DCI can indicate a second HARQ state associated with a HARQ procedure, the configuration information indicating that a DCI-based indication of the HARQ state can be enabled. As shown at 850, the WTRU can perform a second DRX operation (e.g., associated with a HARQ procedure) based on the second HARQ state.

[0228] In various embodiments, the second HARQ state can be indicated in either the uplink grant information or the downlink assignment information.

[0229] In various embodiments, the second HARQ state may be different from the first HARQ state.

[0230] In various embodiments, either the first HARQ state or the second HARQ state may indicate any of the following: (i) downlink HARQ feedback can be enabled, (ii) downlink HARQ feedback can be disabled, (iii) a first uplink HARQ mode, and (iv) a second uplink HARQ mode.

[0231] In various embodiments, a first uplink HARQ mode may be associated with the monitoring of HARQ retransmission authorization information being enabled, and a second uplink HARQ mode may be associated with the monitoring of HARQ retransmission authorization information being disabled.

[0232] In various embodiments, the second HARQ state may be applicable to any of the following: (i) an uplink transmission scheduled by the uplink grant of the DCI, (ii) a downlink reception scheduled by the downlink assignment of the DCI, or (iii) one or more subsequent transmissions of the HARQ process.

[0233] In various embodiments, a first HARQ state may indicate that downlink HARQ feedback can be disabled, and a second HARQ state may indicate that downlink HARQ feedback can be enabled. In various embodiments, performing a second DRX operation may include: monitoring for retransmission based on the WTRU-to-base station round-trip time delay.

[0234] In various embodiments, delay monitoring to receive retransmissions may include: monitoring of the physical downlink control channel based on the WTRU-to-base station round-trip time delay.

[0235] In various embodiments, DRX can be performed based on the second HARQ state until the first HARQ state can be indicated in a subsequent DCI.

[0236] In various embodiments, DRX can be executed according to the first HARQ state after a period of time following execution according to the second HARQ state.

[0237] In various embodiments, the second HARQ state may be applied to any of the following: (i) each serving cell, (ii) each HARQ procedure, and (iii) all HARQ procedures of the WTRU.

[0238] In various embodiments, LCP restriction can associate one or more logical channels with an uplink HARQ mode. In various embodiments, LCP can be performed based on configuration information indicating that DCI-based indication of HARQ status can be enabled.

[0239] In various embodiments, data from one or more logical channels indicated in the LCP restriction can be transmitted in the second DRX operation based on the matching of the uplink HARQ mode indicated in the LCP restriction with the second HARQ state indicated in the DCI.

[0240] FIG. 9 This is a diagram illustrating an example method 900 for adapting DRX based on L1 indication. Method 900 can be implemented in a WTRU. As shown at 910, the WTRU can receive configuration information indicating (1) a DCI-based indication of the HARQ state and (2) that downlink HARQ feedback can be disabled for a HARQ procedure. As shown at 920, the WTRU can perform a first DRX operation with downlink HARQ feedback disabled. As shown at 930, the WTRU can receive a DCI. As shown at 940, the WTRU can determine, based on the configuration information, that the DCI indicates downlink HARQ feedback can be enabled for a HARQ procedure, the configuration information indicating that a DCI-based indication of the HARQ state can be enabled. As shown at 950, the WTRU can perform a second DRX operation (e.g., associated with a HARQ procedure) with downlink HARQ feedback enabled, wherein the WTRU can receive retransmissions based on WTRU-to-base station round-trip time delay monitoring.

[0241] In various embodiments, delay monitoring to receive retransmissions may include: monitoring of the physical downlink control channel based on the WTRU-to-base station round-trip time delay.

[0242] In various embodiments, downlink HARQ feedback can be enabled for any of the following: (i) downlink reception scheduled by the DCI downlink assignment, and (ii) one or more subsequent transmissions of the HARQ process.

[0243] In various embodiments, DRX can be performed with downlink HARQ feedback enabled until a subsequent DCI indicates that downlink HARQ feedback can be disabled.

[0244] In various embodiments, DRX can be performed for a period of time with downlink HARQ feedback enabled, or with downlink HARQ feedback disabled.

[0245] In various embodiments, DRX operation with HARQ feedback enabled can be applied to any of the following: (i) each serving cell, (ii) each HARQ procedure, and (iii) all HARQ procedures of the WTRU.

[0246] The following references may have been cited above, and each reference is incorporated herein by reference in its entirety.

[0247] 3GPP TS 38.321, “NR, Media Access Control (MAC) Protocol Specification” v17.1.0.

[0248] 3GPP TS 36.321, “Evolved Universal Terrestrial Air Interface Access (E-UTRA); Media Access Control (MAC) Protocol Specification” v17.1.0.

[0249] This document describes an embodiment using 3GPP HARQ as an example of an automatic repeat request technology. The embodiments described herein can be applied to any other type of automatic repeat request technology. This document also describes an embodiment using 3GPP DRX as an example of a transmit / receive technology. The embodiments described herein can be applied to any other type of transmit / receive technology.

[0250] Any features, variations, or embodiments described for the method are compatible with apparatus including components for processing the disclosed method, apparatus including a processor configured to process the disclosed method, computer program products including program code instructions, and non-transitory computer-readable storage media storing program instructions.

[0251] 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 in its description of the specific embodiments described herein, which are intended as illustrative of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. Any element, action, or instruction used in the description of this application should not be construed as critical or essential to the invention unless expressly provided so. In addition to those listed herein, functionally equivalent methods and apparatus within the scope of this disclosure will be apparent to those skilled in the art based on the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only by the terms of the appended claims and the full scope of equivalents conferred by such claims. It should be understood that this disclosure is not limited to the specific methods or systems described herein.

[0252] For simplicity, the foregoing embodiments have been discussed in terms of terminology and construction of infrared-capable devices (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0253] It will also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" may mean any of a snapshot, a single image, and / or multiple images displayed on a time basis. As another example, when referred to herein, the term "user equipment" and its abbreviation "UE," the term "remote," and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of many embodiments of a WTRU; (iii) a device particularly configured with some or all of the construction and functions of a WTRU and having wireless and / or wired (e.g., tetherable) capabilities; (iv) a device configured with fewer than all the construction and functions of a WTRU and having wireless and / or wired capabilities; or (iv) a similar device. References herein FIGS. 1A-1D Details of an example WTRU are provided, which may represent any WTRU described herein. As another example, various disclosed embodiments herein are described above and below as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be utilized, and some or all of the embodiments of this disclosure and the various disclosures can be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adaptive, realistic experience.

[0254] Furthermore, the methods provided herein can be implemented in computer programs, software, or firmware incorporated into computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. 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 discs and digital multifunction disks (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

[0255] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the appended claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery) that provides any suitable voltage.

[0256] Furthermore, in the embodiments provided above, a processing platform, computing system, controller, and other means including a processor are mentioned. These means 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 actions and symbolic representations of operations or instructions can be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as “execution,” “computer execution,” or “CPU execution.”

[0257] Those skilled in the art will understand that the actions and symbols representing operations or instructions include the CPU's manipulation of electrical signals. An electrical system represents a data bit, which can cause a final conversion or reduction of an electrical signal and is maintained in a memory location within a storage system, thereby reconfiguring or otherwise altering the CPU's operation and other signal processing. The memory location maintaining the data bit is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bit. It should be understood that the embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the provided methods.

[0258] Data bits can also be maintained 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 can include cooperative or interconnected computer-readable media that exist only on the processing system or are distributed across multiple interconnected processing systems that may be located locally or remotely on the processing system. It should be understood that the embodiments are not limited to the above-described memories, and other platforms and memories may support the provided methods.

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

[0260] The differences between the hardware and software implementations of various aspects of the system are minor. The use of hardware or software is typically (but not always, as the choice between hardware and software can become important in certain situations) a design choice representing a cost-efficiency trade-off. Various vehicles (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 vehicle can vary depending on the context in which the processes and / or systems and / or other technologies are deployed. For example, if the implementer determines that speed and accuracy are most important, then the implementer may choose the primary hardware and / or firmware vehicle. If flexibility is most important, then the implementer may choose the primary software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0261] The foregoing detailed description has illustrated various embodiments of the apparatus and / or processes using block diagrams, flowcharts, and / or examples. 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, with respect to the inclusion of one or more functions and / or operations in such block diagrams, flowcharts, or examples. In embodiments, several 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 all or part of some aspects of the embodiments disclosed herein can be equivalently implemented in integrated circuits as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or virtually as any combination thereof, and that designing circuit systems 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 a program product in various forms, and the illustrative examples of the subject matter described herein apply regardless of the specific type of signal-bearing medium used for actual distribution. Examples of signal-bearing media include, but are not limited to, the following: 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.).

[0262] Those skilled in the art will recognize that devices and / or processes are typically described in the manner set forth herein, and that engineering practice is subsequently used to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable number of experiments. Those skilled in the art will recognize that a typical data processing system typically includes a system unit housing, a video display device, a memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, drivers, a graphical user interface, and applications, one or more interactive devices such as a touchpad or screen, and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or speed; control motors for moving and / or adjusting components and / or quantity). A typical data processing system can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0263] The topics described herein sometimes illustrate different components that are included within or connected to different other components. It should be understood that such depicted architectures are merely examples, and many other architectures that achieve the same functionality can actually be implemented. Conceptually, any arrangement of components used to achieve the same functionality is effectively “associated” such that the desired functionality can be achieved. Therefore, any two components combined herein to achieve a particular function can be considered “associated” with each other such that the desired functionality is achieved 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) physically matable and / or physically interacting components, and / or wirelessly interacting and / or logically interacting components.

[0264] Regarding the use of virtually any plural and / or singular terms in this document, those skilled in the art can convert plural to singular and / or singular to plural as appropriate to the context and / or application. For clarity, various singular / plural permutations may be explicitly described herein.

[0265] Those skilled in the art will understand that, generally, the terms used herein and especially in the appended claims (e.g., the body of the appended claims) are intended to be largely "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "including but not limited to," etc.). Those skilled in the art will further understand that if a specific number of introduced claim statements are intended to express, then such intention will be explicitly stated in the claims, and without such a statement, such intention does not exist. For example, the term "single" or similar language may be used where only one item is desired. To aid understanding, the appended claims and / or the description herein may include the use of introductory phrases "at least one" and "one or more" to introduce multiple claim statements. However, the use of such phrases should not be construed as implying that a claim statement introduced by the indefinite article "a" or "an" will limit any particular claim including such an introduced claim statement to an embodiment that includes only one such statement, even if 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 claim statements. Furthermore, even if a specific number of introduced claim statements are explicitly stated, those skilled in the art will recognize that this statement should be interpreted as meaning at least the number stated (e.g., simply stating "two statements" without other modifiers implies at least two statements or two or more statements). Furthermore, in cases where conventions such as "at least one of A, B, and C" are used, this structure is generally intended to represent a convention that a person skilled in the art would understand (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C). In cases where conventions such as "at least one of A, B, or C" are used, a person skilled in the art will generally understand that such a meaning is expected in the sense of the convention (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C). A person skilled in the art will further understand that any transitional words and / or phrases (whether in the specification, claims, or drawings) that actually give two or more alternatives should be understood to be intended to include the possibility of including one, any, or both of the items.For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”. Furthermore, the term “any” followed by a list of multiple items and / or multiple categories of items as used herein is intended to include “any,” “any combination,” “any multiple,” and / or “any combination of multiple” individually or in combination with other items and / or other categories of items. Additionally, as used herein, the term “set” is intended to include any number of items, including zero. Furthermore, as used herein, the term “number” is intended to include any number, including zero. And the term “multiple” as used herein is intended to be synonymous with “multiple.”

[0266] Furthermore, when 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 or subgroup member of the Markush Group.

[0267] As those skilled in the art will understand, for any and all purposes, such as 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 capable of being decomposed into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily decomposed 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 listed numbers and refers to a scope that can subsequently be subdivided into subscopes as discussed above. Finally, as those skilled in the art will understand, a scope includes each individual member. Thus, for example, a group having 1 to 3 units refers to a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units refers to a group having 1, 2, 3, 4, or 5 units, and so on.

[0268] 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 "for means of" in any claim is intended to invoke 35 USC §112, ¶ 6 or the means plus function claim format, and any claim without the term "for means of" is not intended to do so.

Claims

1. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: Receive Radio Resource Control (RRC) configuration information, the RRC configuration information indicating: (1) a downlink control information (DCI) based indication for covering the hybrid automatic repeat request (HARQ) state of the RRC configuration, and (2) a first HARQ state of the RRC configuration associated with the HARQ procedure, wherein the first HARQ state indicates that downlink HARQ feedback is enabled for the HARQ procedure; The first discontinuous reception (DRX) operation is performed based on enabling downlink HARQ feedback for the HARQ procedure. Receive DCI; Based on the configuration information, a second HARQ state associated with the HARQ procedure is determined by the DCI indication, wherein the configuration information indicates that a DCI-based indication for overriding the HARQ state of the RRC configuration is enabled, and the second HARQ state indicates that downlink HARQ feedback is disabled for the HARQ procedure. The RRC configuration of the HARQ procedure is overridden by disabling downlink HARQ feedback for the HARQ procedure; and The second DRX operation is performed by disabling downlink HARQ feedback for the HARQ procedure.

2. The method according to claim 1, wherein, Performing the second DRX operation includes entering the DRX activity time.

3. The method according to claim 1, wherein, Performing the second DRX operation includes: not ceasing monitoring of the physical downlink control channel during the round-trip time from the base station to the WTRU.

4. The method according to claim 1, wherein, DRX is performed based on downlink HARQ feedback being disabled until downlink HARQ feedback is indicated to be enabled in a subsequent DCI.

5. The method according to claim 1, wherein, After performing DRX for a period of time with downlink HARQ disabled, perform DRX with downlink HARQ feedback enabled.

6. The method according to claim 1, wherein, Downlink HARQ feedback is disabled for any of the following: (i) each serving cell, (ii) each HARQ procedure, and (iii) all HARQ procedures of the WTRU.

7. A wireless transmit / receive unit (WTRU) including a circuit system comprising a transmitter, a receiver, a processor, and a memory, the WTRU being configured to: Receive Radio Resource Control (RRC) configuration information, the RRC configuration information indicating: (1) a downlink control information (DCI) based indication for covering the hybrid automatic repeat request (HARQ) state of the RRC configuration, and (2) a first HARQ state of the RRC configuration associated with the HARQ procedure, wherein the first HARQ state indicates that downlink HARQ feedback is enabled for the HARQ procedure; The first discontinuous reception (DRX) operation is performed based on enabling downlink HARQ feedback for the HARQ procedure. Receive DCI; Based on the configuration information, a second HARQ state associated with the HARQ procedure is determined by the DCI indication, wherein the configuration information indicates that a DCI-based indication for overriding the HARQ state of the RRC configuration is enabled, and the second HARQ state indicates that downlink HARQ feedback is disabled for the HARQ procedure. The RRC configuration of the HARQ procedure is overridden by disabling downlink HARQ feedback for the HARQ procedure; and The second DRX operation is performed by disabling downlink HARQ feedback for the HARQ procedure.

8. The WTRU according to claim 7, wherein, Being configured to perform the second DRX operation includes: being configured to enter DRX activity time.

9. The WTRU according to claim 7, wherein, The configuration to perform the second DRX operation includes: being configured not to stop monitoring the physical downlink control channel during the round-trip time from the base station to the WTRU.

10. The WTRU according to claim 7, wherein, DRX is performed based on downlink HARQ feedback being disabled until downlink HARQ feedback is indicated to be enabled in a subsequent DCI.

11. The WTRU according to claim 7, wherein, After performing DRX for a period of time with downlink HARQ disabled, perform DRX with downlink HARQ feedback enabled.

12. The WTRU according to claim 7, wherein, Downlink HARQ feedback is disabled for any of the following: (i) each serving cell, (ii) each HARQ procedure, and (iii) all HARQ procedures of the WTRU.

Images