Uplink quality of service (QOS) during network energy saving (NES) states

Abstract

As discussed herein, there may be one or more methods, systems, and / or devices that address activation of one or more conditional configuration authorization (CG) resources during a network energy saving (NES) state. A wireless transmit / receive unit (WTRU) may be configured with one or more forwarding configurations to apply during NES states, such as a cell discontinuous reception (DRX) mode, including cell DRX active periods and / or cell DRX inactive periods. The WTRU may be configured with one or more Quality of Service (QoS) conditions to determine whether one or more data units may be transmitted in a cell DRX mode. The WTRU may determine whether to use one or more conditional CG resources to transmit one or more data units in a cell DRX mode based on one or more QoS conditions. The WTRU may also transmit an indication associated with the transmission.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Application Serial No. 63 / 531,247, filed on August 7, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] In wireless communication systems, devices can be attached to a network. To conserve energy from both the device and network perspectives, each entity (i.e., the device and the network) can operate and / or switch between multiple periods of low-energy and / or no-energy states. When the network operates in a low-energy and / or no-energy state, the device may need to transmit data to the network. In such cases, uplink transmissions from the device to the network may require different resources when the network operates in different energy states. Therefore, a configuration is needed to manage uplink transmissions across different energy states, and improvements are needed for these states, particularly for data transmission during low-energy and / or no-energy states. Summary of the Invention

[0003] As discussed herein, one or more methods, systems, and / or devices may exist to address the activation of Conditional Configuration Grant (CG) resources during Network Energy Saving (NES) states, such as (but not limited to) Discontinuous Cell Reception (DRX) states. A Radio Transmit / Receive Unit (WTRU) may be configured with one or more forwarding configurations to apply during active and / or inactive DRX periods. The WTRU may determine whether conditional CG resources are used to transmit data and / or indications during active and / or inactive DRX periods.

[0004] In one embodiment, a method implemented by a WTRU is provided. The method includes receiving configuration information regarding one or more logical channels, one or more conditional CGs, one or more default CGs, an association between one or more logical channels and at least one of the one or more conditional CGs, one or more default CGs, or one or more Quality of Service (QoS) conditions. The one or more QoS conditions are associated with one or more data unit transmissions using a conditional CG from one or more conditional CGs during a period of cell discontinuous reception (DRX) inactivity. When the cell is in a cell DRX inactivity period and the QoS conditions among the one or more QoS conditions are satisfied for the data unit, the method includes selecting a conditional CG from the one or more conditional CGs. The method further includes using one or more resources of the selected conditional CG to transmit the data unit. The data unit transmission includes requesting deactivation of cell DRX mode. When the cell is in a cell DRX inactivity period and none of the one or more QoS conditions are satisfied, the method includes using one or more resources of the default CG among the one or more default CGs to transmit the data unit during a subsequent cell DRX active period.

[0005] In one embodiment, a WTRU is provided, comprising a memory, a receiver, a transmitter, and a processor. The memory is configured to store data units. The receiver is configured to receive configuration information regarding one or more logical channels, one or more conditional CGs, one or more default CGs, associations between one or more logical channels and at least one of the one or more conditional CGs, one or more default CGs, or one or more QoS conditions. The one or more QoS conditions are associated with the transmission of one or more data units using one or more conditional CGs during a cell DRX inactive period. The transmitter and processor are configured to: select a conditional CG from one or more conditional CGs and use one or more resources of the selected conditional CG to transmit the data unit, provided that the cell is in a cell DRX inactive period and the QoS conditions among the one or more QoS conditions are satisfied for the data unit. The data unit transmission includes requesting deactivation of cell DRX mode. The transmitter and processor are configured to: use one or more resources of one or more default CGs to transmit the data unit during a subsequent cell DRX active period, provided that the cell is in a cell DRX inactive period and none of the one or more QoS conditions are satisfied.

[0006] In this embodiment, the WTRU receives an indication that the cell DRX mode is activated.

[0007] In this embodiment, when one or more resource transmission data units are used with the selected condition CG, the request to disable the cell DRX mode is implicit.

[0008] In this embodiment, the request to disable the cell DRX mode is explicit and multiplexed with the data unit.

[0009] In one embodiment, one or more QoS conditions include the remaining time of the data unit.

[0010] In an embodiment, one or more QoS conditions include the importance of the data unit.

[0011] In one embodiment, a method executed by a WTRU is provided. The method includes receiving configuration information regarding one or more conditional CGs, one or more default CGs, and one or more QoS conditions. The method further includes: when a QoS condition among the one or more QoS conditions is satisfied for a data element, transmitting the data element using the conditional CG from the one or more conditional CGs, along with a request to disable cell DRX mode, during a period of cell DRX inactivity.

[0012] In an embodiment, the method further includes: when one or more QoS conditions are not met for a data unit, using a default CG from one or more default CGs to transmit the data unit during a cell DRX active period.

[0013] In one embodiment, the method includes selecting a condition CG for transmitting the data unit based on a logical channel mapped to the data unit.

[0014] In this embodiment, the configuration information further includes a cell DRX activation indication.

[0015] In an embodiment, the QoS condition is satisfied when the remaining time associated with the data unit is less than the threshold time indicated by the QoS condition.

[0016] In an embodiment, a QoS condition is satisfied when the priority value associated with a data unit exceeds a threshold priority value indicated by the QoS condition.

[0017] In this embodiment, the request to disable the cell DRX mode is implicit when transmitting data units.

[0018] In this embodiment, the request and data unit used to disable the cell DRX mode are multiplexed. Attached Figure Description

[0019] A more detailed understanding can be obtained from the following description, given by way of example and in conjunction with the accompanying drawings, wherein similar reference numerals in the figures indicate similar elements, and wherein: Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented; Figure 1B The illustration shows that, according to the embodiment, it is possible to... Figure 1A The diagram illustrates a system diagram of an example wireless transmit / receive unit (WTRU) used within a communication system. Figure 1C The illustration shows that, according to the embodiment, it is possible to... Figure 1A The diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system. Figure 1D The illustration shows that, according to the embodiment, it is possible to... Figure 1A The diagram shows another example RAN and another example CN used in the communication system. Figure 2 This is a diagram illustrating a multi-physical uplink shared channel (multi-PUSCH) configuration grant (CG) configuration according to an embodiment; Figure 3A is a diagram illustrating one or more data units and one or more CG resources according to an embodiment; Figure 3B This is a diagram illustrating the transmission of one or more data units using one or more CG resources illustrated in FIG3A according to an embodiment; Figure 4 This is a flowchart illustrating an example process according to one or more embodiments disclosed herein; Figure 5 It is a flowchart illustrating an example process of transmitting one or more data units according to one or more embodiments discussed herein; and Figure 6 This is a flowchart illustrating an example process for transmitting one or more data units according to one or more embodiments discussed herein. Detailed Implementation

[0020] As discussed in this article, one or more abbreviations in the following (not exhaustive) list (as shown in Table 1) may be used in this article. ACK confirm BLER Block error rate BWP Bandwidth section BFD Beam fault detection CA Carrier aggregation CAP Channel access priority CAPC Channel access priority class CCA Free channel assessment C-DRX Discontinuous reception in connection mode CE Control elements CG Configuration authorization or cell group CP Cyclic prefix CP-OFDM Conventional OFDM (depending on the cyclic prefix) CQI Channel quality indicator CRC Cyclic Redundancy Check CSI Channel state information CW Contest window CWS Contending for window size CO Channel occupancy DAI Downlink Allocation Index DC Dual connectivity DCI Downlink control information DFI Downlink feedback information DG Dynamic authorization DL downlink DM-RS Demodulation reference signal DRB Data radio bearer DRX Discontinuous reception DTX discontinuous transmission HARQ Hybrid Automatic Repeat Request LAA Licensed assisted access LBT Listen first, then speak LTE Long-term evolution, for example, from 3GPP LTE R8 to higher versions. NACK Negation ACK NES Network energy saving MCS Modulation and encoding / decoding schemes MIB Main information block MIMO Multiple Input Multiple Output NR New Radio OFDM Orthogonal Frequency Division Multiplexing PHY Physical layer PID Process ID PEI Early instructions for paging PO Paging timing PRACH Physical Random Access Channel PSS Main synchronization signal RA Random access (or program) RACH Random Access Channel RAR Random access response RCU Central Unit of Radio Access Network RF Radio front end RLF Radio link failure RLM Radio link monitoring RMSI Remaining system information RNTI Radio network identifier RO RACH timing RRC Radio Resource Control RRM Radio resource management RS Reference signal RSRP Reference signal received power RSSI Received signal strength indicator SDU Service Data Unit SI System Information SIB System Information Block SRS Detection reference signal SS Synchronization signal SSB Synchronization signal block SSS auxiliary synchronization signal SWG Switching interval (within a self-contained subframe) SPS Semi-persistent scheduling SUL Supplement uplink SN auxiliary nodes TB Transport block TBS Transfer block size TRP Transmit / Receive Point TRS Tracking reference signal TSC Time-sensitive communication TSN Time-sensitive networking UL uplink Table 1.

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

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

[0023] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b can be any type of device configured to connect to at least one of the WTRUs 102a, 102b, 102c, and 102d via a wireless ground interface to facilitate access to one or more communication networks, such as CN 106, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be interchangeable with base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home NodeBs, home eNodeBs, next-generation NodeBs (such as gNodeBs (gNBs)), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, etc. (e.g., as described anywhere herein). 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.

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

[0025] 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, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

[0026] 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 stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish an air interface 116 using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink (UL) Packet Access (HSUPA).

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

[0028] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c may implement radio technology, such as NR radio access, which can use NR to establish air interface 116.

[0029] In this embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmission representations sent to / from various types of base stations (e.g., eNBs and gNBs).

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

[0031] For example, Figure 1A Base station 114b can be a wireless router, home Node B, home eNode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business location, home, vehicle, campus, industrial facility, air corridor (e.g., for use by drones), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106.

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

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

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

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

[0036] 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), any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding / decoding, 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 Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0037] 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 embodiments, for example, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another 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.

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

[0039] Transceiver 120 can be configured to modulate signals to be 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. Thus, for example, transceiver 120 can include multiple transceivers for enabling WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

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

[0041] The processor 118 can receive power from the power supply 134 and can be configured to distribute the power to other components in the WTRU 102 and / or control that power. The power supply 134 can 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-chromium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cell units, fuel cell units, etc.

[0042] 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 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 the WTRU 102 may acquire location information using any suitable location determination method, while remaining consistent with the embodiments.

[0043] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (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. Peripheral devices 138 may include one or more sensors. Sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

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

[0045] Figure 1C This diagram illustrates a system diagram of 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.

[0046] RAN 104 may include eNode-B 160a, 160b, 160c, although it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-B 160a, 160b, 160c may each include one or more transceivers for communicating with WTRU 102a, 102b, 102c via air interface 116. In one embodiment, eNode-B 160a, 160b, 160c may implement MIMO technology. Thus, for example, eNode-B 160a may use multiple antennas to transmit radio signals to WTRU 102a and / or receive radio signals from WTRU 102a.

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

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

[0049] 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, performing bearer activation / deactivation, and selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c. 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.

[0050] 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 / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, and so on.

[0051] The SGW 164 can be connected to the 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.

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

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

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

[0055] In Infrastructure Basic Services Set (BSS) mode, a WLAN may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or outside the BSS. Traffic originating outside the BSS and destined for a STA can be delivered to the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the corresponding 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 peer-to-peer traffic. Peer-to-peer traffic can be sent between the source and destination STAs (e.g., directly between them) using a direct link setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without 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 the "ad-hoc" communication mode in this document.

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

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

[0058] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 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). For the 80+80 configuration, after channel coding, data can be passed through a segmented parser that splits the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. The streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0059] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MNz, 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 support for (e.g., only support) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., for maintaining very long battery life).

[0060] 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 STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. 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, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, all available frequency bands can be considered busy, even if most available frequency bands are still idle.

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

[0062] Figure 1D This diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0063] RAN 104 may include gNBs 180a, 180b, and 180c, although it will be understood that RAN 104 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 gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

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

[0065] 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 needing to access other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate with / connect to gNBs 180a, 180b, and 180c, and simultaneously communicate with / connect to 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-B 160a, 160b, and 160c can act as mobility anchors for WTRU 102a, 102b, and 102c, and gNB 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRU 102a, 102b, and 102c.

[0066] 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, scheduling of users in UL and / or DL, support for network slicing, networking between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

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

[0068] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 104 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 Non-Access Stratum (NAS) signaling, mobility management, etc. Network slices can be used by AMF 182a and 182b to customize CN support for WTRU 102a, 102b, and 102c based on the service types utilized by WTRU 102a, 102b, and 102c. For example, different network slices can establish services for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies (such as WiFi).

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

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

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

[0072] Given Figures 1A to 1D And to Figures 1A to 1D As described herein, one or more of the following functions may be performed by one or more emulation devices (not shown): 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 device(s) described herein. An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0073] Simulation devices can be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, one or more simulation devices can perform one or more or all of their functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more or all of their functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing and / or performing tests using over-the-air wireless communication.

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

[0075] For a given wireless communication scenario, there may be underlying motivations to improve and make the system more efficient. One such improvement or efficiency might lie in reducing energy consumption. Generally, it is desirable for the network to minimize its power consumption during transmission and reception. This is desirable because such minimization helps reduce operating costs and environmental sustainability.

[0076] Compared to earlier cellular systems, the New Radio (NR) can be considered highly efficient from the perspective of minimizing uplink and / or downlink transmissions between the WTRU and the network when data is not transmitted between the WTRU and the network. For example, to reduce power consumption, the always-on Cell Specific Reference Signal (CRS) (which was typically used in earlier cellular systems) is not used in the NR. However, it is still possible to further reduce power consumption, for example, by using one or more Network Energy Saving (NES) states, such as (but not limited to) operating the network in Discontinuous Reception (DRX) mode.

[0077] For example, when not transmitting data, a network can consume energy to perform other functions. Examples of such functions include, but are not limited to, baseband (i.e., digital) processing or beamforming, resulting in unused power consumption. In dense networks, this unused power consumption may not be negligible, even when no WTRUs are served during a given period. If the network could shut down these functions when not transmitting to any WTRUs, energy consumption could be further reduced.

[0078] Unlike Long Term Evolution (LTE), NR does not require the transmission of a constantly active synchronization or reference signal. NR also supports adaptable bandwidth and multiple-input multiple-output (MIMO) capabilities. While some energy savings are possible with NR compared to earlier cellular systems, the adaptation to network resources can enable newer deployments and subsequent versions (such as NR and subsequent technologies) to operate more efficiently.

[0079] NR can facilitate the implementation of Extended Reality (XR) applications in WTRU. Here, XR is a collective term for different types of immersive experiences, such as (but not limited to) Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR), or other combinations of such realities. VR applications include virtual rendered versions of visual or audio scenes. The rendering is designed to simulate real-world visual (e.g., stereoscopic three-dimensional (3D)) stimuli and / or audiovisual stimuli, presenting them to the observer or user as naturally as possible, as if the observer or user were moving within the constraints defined by the VR application. AR applications may include one or more artificially generated objects, items, and / or content that provide additional information and / or are overlaid on the current environment displayed to the observer or user. MR applications are a higher form of AR applications, in which multiple virtual elements are inserted into a real scene to provide the illusion that the virtual elements are part of the real scene. XR applications may include a combination of a real environment and one or more virtual environments, and may also facilitate human-computer interaction through one or more wearable devices.

[0080] As described herein, a WTRU can include (e.g., any XR device and / or node other than any other definition provided herein), and in some cases, the XR device and / or node can be implemented in various form factors. Example WTRUs (e.g., XR WTRUs) can include (but are not limited to) the following: head-mounted displays (HMDs), optical see-through glasses, camera-through HMDs for AR and MR, mobile devices with location tracking and cameras, wearable devices, haptic gloves, haptic tights, haptic shoes, etc. One or more devices, nodes, and / or WTRUs can be grouped into collaborative XR groups to support any XR application, experience, and / or service.

[0081] In XR applications and / or XR services, data traffic can include data such as, but not limited to, one or more Protocol Data Units (PDUs), which can be associated with Application Data Units (ADUs), PDU sets, or data bursts. In the example, multiple PDUs in a PDU set can be associated with different segments and / or components of a video frame or video slice. A data burst can include one or more PDU sets that can be transmitted and / or received within a time window. For example, multiple PDUs in a PDU set, or a data burst transmitted in uplink (UL) communication and / or received in downlink (DL) communication, can depend on a type of media frame (e.g., a 3D video frame or an audio frame, etc.). XR applications and / or XR services are merely example scenarios that may require a certain level of performance and are not intended to be limiting. As described herein, XR applications and / or XR services are discussed as examples of special cases; however, their purpose is merely to serve as placeholder examples of the different technologies and / or methods disclosed herein, which are generally applicable to all special cases requiring the disclosed technologies and / or methods.

[0082] A synchronization signal block (SSB) or synchronization signal / physical broadcast channel (SS / PBCH) block may include at least one of the following: primary synchronization signal (PSS), secondary synchronization signal (SSS), PBCH (data, primary information block (MIB)), and PBCH (demodulation reference signal (DMRS)). One or more SSBs may be transmitted by the base station in a direction different from one or more beams. The multiple SSB beams in an SSB burst (which may be transmitted periodically at intervals (e.g., 5 ms)) may depend on the carrier frequency. For example, an SSB burst may contain 4 SSBs for frequency range 1 (FR1) (<3 GHz), 8 SSBs for FR1 (3 GHz to 6 GHz), and 64 SSBs for frequency range 2 (FR2).

[0083] System information (SI) may include at least a MIB and one or more System Information Blocks (SIBs). The MIB may be received by the WTRU at a certain period (e.g., 80 ms) and through one or more repetitions (e.g., within 80 ms) on the broadcast channel (BCH). The MIB may include one or more parameters required to obtain SIB1 from the cell. The initial transmission of the MIB is scheduled in one or more subframes, and repetitions are scheduled according to the period of the SSB.

[0084] SIB1 (also known as Remaining Minimum SI (RMSI)) can be received on the DL Shared Channel (DL-SCH) at a certain periodicity (e.g., 160 ms) and with a variable transmission repetition periodicity (e.g., within 160 ms). SIB1 may include information about the availability and scheduling of other SIBs (e.g., SIB-to-SI message mapping, periodicity, SI window size) and an indication of whether one or more SIBs are provided only as needed, and in this case, the configuration required for the WTRU to perform the SI request. SIB1 is a cell-specific SIB.

[0085] All SIBs except SIB1 and the Positioning SIB (posSIB) are carried in one or more SI messages, which may be received on the DL-SCH. Only SIBs or posSIBs with the same periodicity can be mapped to the same SI message. Any SIB other than SIB1, or any posSIB, can be configured as cell-specific or area-specific using the indication in SIB1. Cell-specific SIBs are applicable only in the cell providing the SIB, while area-specific SIBs are applicable in an area called an SI area, which includes one or more cells and is identified by the systemInformationAreaID.

[0086] Channel state information (CSI) may include at least one of the following: channel quality indicator (CQI), rank indicator (RI), precoding matrix indicator (PMI), L1 channel measurement (e.g., reference signal received power (RSRP) (such as L1-RSRP or signal-to-interference-plus-noise ratio (SINR)), CSI-RS resource indicator (CRI), SS / PBCH block resource indicator (SSBRI), layer indicator (LI), and / or any other measurement obtained by the WTRU from the configuration of CSI-RS, SS / PBCH block, or SSB.

[0087] Uplink control information (UCI) may include one or more of the following: CSI, Hybrid Automatic Repeat Request (HARQ) feedback for one or more HARQ procedures, Schedule Request (SR), Link Recovery Request (LRR), Configuration Grant (CG) uplink control information (UCI) and / or other control information bits that may be transmitted on the Physical Uplink Channel (PUCCH) or Physical Uplink Shared Channel (PUSCH).

[0088] One or more channel conditions can be any conditions relating to the state of the radio and / or the channel, which can be determined by the WTRU from one or more of the following: WTRU measurements (e.g., L1 / SINR / RSRP, Channel Quality Indicator (CQI) / Modulation Codec Scheme (MCS), Channel Occupancy, Received Signal Strength Indicator (RSSI), Power Margin or Exposure Margin, etc.), L3 / Mobility-Based Measurements (e.g., Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), S-measure), Radio Link Monitoring (RLM) status, and / or Channel Availability in Unlicensed Spectrum (e.g., whether the channel is occupied based on a Listen-Before-Speak (LBT) procedure, or whether the channel is considered to have experienced a sustained LBT failure).

[0089] Physical random access channel (PRACH) resources are PRACH resources (e.g., in terms of frequency), PRACH timing (RO) (e.g., in terms of time), preamble format (e.g., in terms of total preamble duration, sequence length, guard time duration, and / or cyclic prefix length), and / or a preamble sequence used for the transmission of preambles in a random access procedure.

[0090] The nature of the scheduling information (e.g., uplink grant or downlink allocation) may include at least one of the following: frequency allocation, aspects of time allocation (such as duration), priority, MCS, transport block (TB) size, number of spatial layers, number of TBs to be carried, transport configuration indicator (TCI) status or SRI resource indicator (SRI), number of repetitions, or whether the grant is CG type 1, type 2, or dynamic grant (DG).

[0091] Indications given by Downlink Control Information (DCI) may include at least one of the following: explicit indications given by DCI fields or Radio Network Temporary Identifiers (RNTIs) used for masking the Cyclic Redundancy Check (CRC) of the Physical Downlink Control Channel (PDCCH); implicit indications given by properties such as DCI format, DCI size, Control Resource Set (CORESET) or Search Space (SS), Aggregation Level, and the identifier of the first control channel resource used for the DCI (e.g., the index of the First Control Channel Element (CCE)), wherein the mapping between properties and values ​​can be signaled by Radio Resource Control (RRC) or Medium Access Control (MAC); and explicit indications given by DL MAC Control Elements (CEs).

[0092] Throughout the embodiments described herein, for example, a network may include any of the following: base stations (e.g., gNodeBs (gNBs), Transmit and Receive Points (TRPs), Radio Access Network (RAN) nodes, or access nodes, etc.), core network functions (e.g., Access and Mobility Management Functions (AMF), Session Management Functions (SMF), Policy Control Functions (PCF), or Network Exposure Functions (NEF), etc.), and application functions (e.g., edge server functions or remote server functions). An NES cell may refer to any network node that can operate in and / or is capable of operating in NES states and / or modes, including any of time, frequency, spatial, and / or power domain adaptation modes.

[0093] The terms “network availability status,” “discontinuous transmission (DTX) mode,” and / or “cell DTX configuration” and / or NES status are used interchangeably herein. A PDU set may include one or more data units (e.g., PDUs) or video frames and / or slices associated with a media unit. Such data units or data bursts in a PDU set may depend on each other at the application layer and / or lower layers (e.g., the AS layer).

[0094] One or more attributes and / or properties of a PDU set may differ from each other in the following ways: for example, the number of PDUs in the PDU set, payload size, correlation within the PDU set, importance and / or priority of data units (e.g., one or more priority values ​​associated with the PDU set of PDUs), transmission status (e.g., the percentage of PDUs successfully transmitted and / or received in the PDU set), effective data rate and / or effective reliability associated with transmission.

[0095] In the example, the attributes and / or properties associated with PDUs and / or sets of PDUs may be visible at one or more AS layers (e.g., at Packet Data Convergence Protocol (PDCP), RLC, MAC, Physical (PHY) sublayers / layers) and may be used to support additional actions and / or functions (e.g., prioritization, mapping to logical channels (LCH), multiplexing into one or more TBs, scheduling, or triggering and / or transmission indication, etc.).

[0096] A PDU set can be associated with one or more PDU set-level Quality of Service (QoS) requirements and / or conditions (e.g., data rate, latency, error rate, reliability), which can apply to one or more PDUs or all PDUs associated with the PDU set. Different PDUs in a PDU set can be associated with individual PDU-level QoS requirements. The PDU set delay budget (PSDB) can be the time from the receipt of the first PDU (e.g., at the WTRU in the UL) to the successful delivery of the last arriving PDU in the PDU set (at the network in the UL). The PDU set synthesis processing indicator (PSIHI) indicates whether all PDUs in the PDU set are required for application layer use of the PDU set. The PDU set error rate (PSER) defines the upper limit of the rate at which a non-congestion-related PDU set is lost between the RAN and the WTRU.

[0097] Jitter can refer to the variation relative to an expected time instance during which one or more PDUs can be received and / or transmitted. For example, for a set of PDUs expected to be received periodically at different periodic time instances, jitter can refer to the variation relative to the periodic time instances (e.g., for PDUs received T1 ms earlier or T2 ms later than the expected time instance T, the jitter range is T2 to T1). Jitter can refer to instantaneous values ​​or statistical values ​​(e.g., mean, variance, standard deviation, maximum or minimum values, etc.). Remaining delay or remaining time can refer to the remaining duration of time before the PSDB for receiving and / or transmitting one or more PDUs in the PDU set. Remaining time can also be referred to as the time to live (TTL) associated with the PDU set. The associations and interdependencies of PDU sets and / or data bursts, including start and / or end indications (e.g., via sequence number, start and / or end indication, or timestamp, etc.), start and / or end times, duration, payload size, periodicity, importance and / or priority and / or QoS (e.g., PSDB), can be visible to the AS layer and / or processed at the AS layer according to the associated awareness during data transmission and / or data reception.

[0098] Regarding application and / or higher-level importance and / or priority, different PDUs or all PDUs in a PDU set can be associated with different importance and / or priority values. Such importance and / or priority values ​​can correspond to spatial importance (e.g., the spatial location of video frames whose data is carried by the PDU and / or PDU set, where a PDU and / or PDU set carrying the field-of-view (FoV) spatial location can be associated with higher spatial importance compared to non-FoV spatial locations) or temporal importance (e.g., the temporal sequence of video and / or application frames whose data is carried by the PDU and / or PDU set, where a PDU and / or PDU set carrying one or more base video frames (such as, but not limited to, I-frames) can be associated with higher temporal importance compared to one or more different video frames (such as, but not limited to, P-frames and / or B-frames). During data transmission and / or reception, such importance and / or priority values ​​can be visible to the AS layer (e.g., with associated identifiers (IDs) and / or tags).

[0099] Regarding QoS flows and / or data flows, an application's PDUs and / or PDU sets can be encoded and / or transmitted by the application to the WTRU (in the UL) or the network (in the DL) via one or more QoS flows and / or data flows. Different QoS flows carrying PDU sets associated with a specialty application and / or experience (e.g., an XR application and / or XR experience) can be visible to the AS layer (e.g., with an associated ID) and / or processed at the AS layer according to the associated awareness during data transmission and / or reception.

[0100] As described herein, forwarding configuration can correspond to any of the following: radio bearers (e.g., data radio bearers (DRB), signaling radio bearers (SRB), transport radio bearers, PDU set bearers), LCH, logical channel groups (LCG), one or more configuration parameters in various layers within the AS protocol stack (e.g., Serving Data Adaptation Protocol (SDAP), PDCP, RLC, MAC, PHY, other new protocol layers), parameters associated with logical channel prioritization (LCP) (e.g., priority, PBR, BSD), bandwidth portion (BWP), carrier, radio link and / or interface (e.g., Uu link, SL), and / or radio resources (e.g., a collection of one or more frequency, time, and / or spatial resources, such as, but not limited to, symbols, time slots, subcarriers, resource elements, or beams). For example, radio resources can be associated with CG, DG, and / or any other licensed or unlicensed resource.

[0101] Base stations (e.g., gNBs or network nodes connected to WTRUs) can currently use reduced downlink transmission and / or uplink reception without explicit cell DTX and / or cell DRX modes, while being subject to one or more limitations due to WTRU DRX configuration and any configured transmission and / or reception (such as common channels and / or signaling). In one case, each WTRU is configured with a connection mode DRX (C-DRX). Alignment of one or more DRX cycles or offsets for different WTRUs can be done via RRC. During WTRU DRX off periods, WTRUs may not expect to monitor PDCCH, but WTRUs may be allowed to initiate UL transmissions based on one or more configured resources (e.g., using PUCCH, RACH, SR, or CG-PUSCH). Alignment and / or omission of one or more DRX modes across multiple WTRUs can be implemented via base station implementation.

[0102] Cell DTX / DRX modes can provide mechanisms for informing the WTRU whether a cell remains inactive. This can include enhancements to the WTRU DRX configuration, such as, but not limited to, aligning and / or omitting one or more DRX cycles and / or DRX start offsets for WTRUs in connected mode or idle and / or inactive mode, potentially allowing for longer periods of cell inactivity. During cell DTX and / or cell DRX modes, the cell may not transmit and / or receive, or may only perform limited transmission and / or reception. For example, the cell may not need to transmit and / or receive one or more periodic signals and / or channels, such as common channels and / or signals or WTRU-specific signals and / or channels.

[0103] Cell DTX and / or cell DRX modes can be applied to at least one or more WTRUs in the RRC_CONNECTED state. Periodic cell DTX and / or cell DRX modes (e.g., active and inactive periods) can be configured by the base station for each serving cell via WTRU-specific RRC signaling. Cell DTX and / or cell DRX modes can be activated and / or deactivated via dynamic L1 signaling and WTRU-specific RRC signaling. To activate and / or deactivate cell DTX and / or cell DRX modes, both WTRU-specific signaling and group common L1 signaling can be considered. Cell DTX and / or cell DRX modes can be configured and operated individually (e.g., one RRC configuration set for DL ​​and another for UL). Cell DTX and / or cell DRX modes can also be configured and operated together. At least the following parameters can be configured according to the cell DTX and / or cell DRX mode configuration: periodicity, start timeslot and / or offset, and on-time duration. In one case, the cell DTX indication can also be part of an SI update or SIB signaling. For all WTRUs, there may be a common time to determine the cell DTX and / or cell DRX status.

[0104] The WTRU can determine whether it can transmit or receive on certain resources based on network availability status, which can imply the base station's power-saving status. Availability status can correspond to NES status, cell DTX mode, cell DRX mode, and / or base station activity level. Availability status can be uplink-specific and / or downlink-specific, and can change with symbol, time slot, frame, or with longer duration granularity. Availability status can be determined by the WTRU or indicated by the network. Availability status can be, for example: "On," "DL and UL Active," "UL Active Only," "Off," "Reduced Tx Power," "Sleep," "Micro Sleep," "Light Sleep," or "Deep Sleep." Such states can be abstracted by one or more network configuration parameters and / or values, and dynamic indications can indicate active availability status (e.g., via DCI or MAC CE signaling). "Off" availability status can imply that the base station's baseband hardware is completely off. "Sleep" availability status can imply that the base station periodically wakes up to transmit certain signals (e.g., presence signals, synchronization signals, or reference signals) or receive certain UL signals. In certain availability states, one or more DL and / or UL resources may be unavailable for certain time periods, allowing the network to shut down baseband processing and other activities or functions. One or more measurement resources (e.g., SSB or CSI-RS) may be available only in certain availability states, including one or more of the following: RLM, BFD, RRM measurements, CSI-RS feedback configuration, and / or different power offsets for CSI feedback.

[0105] In some cases, the WTRU may further transmit a request to the network (e.g., a wake-up request or wake-up signal and / or indication) to modify the availability state to a state in which resources satisfying one or more WTRU requirements are available. The WTRU may determine the availability state based on receiving availability state indications from, for example, L1 and / or L2 signaling (e.g., group common DCI or indications), or implicitly based on the receipt or absence of periodic DL signaling.

[0106] If resources are applicable in an active availability state, the WTRU can determine whether the resources are available for transmission and / or reception and / or one or more measurements for the determined network availability state. Additionally, the WTRU can adapt its active C-DRX cycle, one or more active spatial elements (e.g., the WTRU's antennas or logical ports), one or more active TRPs, and / or one or more paging opportunities based on the availability state notified by signaling and / or the determined availability state. The WTRU can be configured with one or more sets of NES transmission and / or reception parameters, such as via broadcast or dedicated configuration signaling, depending on the availability state. The WTRU can apply a set of NES parameters, i.e., an NES parameter set, based on the determined availability state and / or the availability state notified by signaling. The WTRU can apply one or more applicable configurations based on the determined NES state. A set of NES parameters may include at least one of the following: multiple antenna ports, C-DRX configuration, measurement configuration (e.g., for RRM, RLM, and / or BFD), CSI feedback, CSI-RS configuration, SSB configuration, CHO or mobility candidate, and / or a set of active TRPs.

[0107] Availability status can apply to at least one transmission, reception, and / or measurement resource. Availability status can apply to at least one time period, such as, but not limited to, time slots or time symbols. Availability status can apply to a serving cell, cell group, frequency band, bandwidth portion, TRP, a set of spatial elements, or a series of frequencies within a bandwidth portion. For example, when the NES status changes in a cell, the WTRU can receive an availability status change indication indicating that the change in availability status applies only to that cell, to all cells at the same frequency, or / or to the same RAT.

[0108] Upon receiving DL signaling that changes the availability status of a cell or TRP, the WTRU can treat the active availability status associated with the cell, carrier, TRP, or frequency band as "off," "deep sleep," or "micro sleep." For example, the WTRU can receive a shutdown command on broadcast signaling, RRC signaling, DCI (e.g., group common DCI), or DL ​​MAC CE (e.g., the indication portion of PDSCH). The WTRU can determine the availability status based on receiving an availability status indication from, for example, L1 and / or L2 signaling (e.g., group common DCI or indication) or broadcast signaling associated with the availability status. For example, the availability status change indication can also be part of an SI update or SIB signaling (e.g., in a separate SIB, which would not be read by the legacy WTRU). There can also be a common time for all WTRUs in the cell to determine the availability status.

[0109] WTRU can implicitly assume a certain availability state (e.g., "off", "deep sleep", "micro sleep", or "dormant") associated with a cell, carrier, TRP, or frequency band by the following: receiving paging messages (e.g., paging DCI, paging PDSCH, or paging-related signals, such as PEI), base station DTX status (e.g., whether the base station is active or the associated activity timer is running), no presence indication detected, availability state of the associated cell, and / or one or more measured channel conditions below or above a threshold.

[0110] A WTRU can be configured as a monitoring indicator that characterizes the level of network activity (e.g., availability status). Network activity can be associated with base stations and / or cells. A WTRU can assume the same availability status for all cells that are part of the same base station (e.g., cells of the same MAC entity). Network activity indicators (e.g., presence indicators) can include channels (e.g., PDCCH) and / or signals (e.g., sequences). Activity indicators or NES state change indicators and / or commands (e.g., referred to as cell activity indicators) can indicate the level of activity that the WTRU can anticipate from the associated base station and / or cell, e.g., reducing activity. Activity indicators can contain activity information from other base stations and / or cells. Activity indicators can be PDCCHs containing group common signaling. For example, the network can transmit group common DCIs to a group of WTRUs (e.g., WTRUs in the serving cell) to indicate changes in activity status or activity level in the UL and / or DL. The CRC of the PDCCH can be scrambled using a dedicated “Activity Indication RNTI or NES-RNTI”. A WTRU can be configured with at least one search space associated with the monitoring timing of the activity indicator PDCCH. Indicators may include sleep signals, such as predefined sequences. When the WTRU detects this sequence, it can anticipate a reduced activity level over a specific time duration. The WTRU may activate C-DRX during the indicated time period. Alternatively, one or more sequences may be used to indicate normal activity and / or reduced activity.

[0111] Signalling within PDCCH and / or activity indications may contain at least one or more data segments. For example, a data segment that can be included in the signaling may be the expected activity level (e.g., availability status) of the associated base station and / or cell within a specific time interval. Activity levels may be predetermined and / or configured, and may include, for example, regular activity and / or reduced activity. Signalling may indicate activity levels. For example, a bit "1" may indicate regular activity, and a bit "0" may indicate reduced activity. For example, a data segment that can be included in the signaling may be one or more transmit and / or receive attributes (e.g., each activity level and / or availability status). For example, during reduced activity, the WTRU may not expect to monitor certain PDCCH search spaces (including all SS), and / or receive a certain type of PDSCH (including all PDSCH), and / or transmit PUCCH / PUSCH, and / or perform certain measurements. The WTRU may start or stop monitoring PDCCH and / or TCI states associated with determined NES states, including PDCCH resources or TCI states associated with activated and / or deactivated TRPs or spatial elements. For example, a segment of information that can be included in the signaling can be a set of configurations that can be associated with an activity level and used and / or applied when the aforementioned activity level is indicated (e.g., NES parameter set). Examples include SS configuration, CSI report configuration, one or more indices of the transmitted SSB, etc. Each set of configurations can have at least one attribute associated with the corresponding activity level. For example, a label can be set to "reduced activity". For example, a segment of information that can be included in the signaling can be a time interval within which the assumed activity level can be signaled in the PDCCH or a portion of the activity indication. For example, the time interval can be indicated using a bitmap, where each bit in the bitmap can be associated with a specific duration (such as, but not limited to, a time slot or frame). For example, a bit "1" can indicate regular activity, and a bit "0" can indicate reduced activity on the associated frame. For example, the time interval can be indicated by the start time and length of the interval. The start time can be defined, for example, it can be determined by adding a fixed offset to the time the indication is received. The length of the interval can be configured and / or signaled in the indicating PDCCH.

[0112] For example, a segment of information that can be included in the signaling could be a time interval within which the assumed activity level can be predetermined. The WTRU can assume an interruption delay after receiving the NES state change command (e.g., after the last symbol or time slot after receiving the command), or more generally, the time until the NES state changes. The interruption time can be absolute time, multiple symbols, or multiple time slots.

[0113] If uplink and / or downlink resources are applicable in an active availability state, the WTRU can determine that, for the determined network availability state, uplink and / or downlink resources or signals are available for transmission and / or reception. The WTRU can determine that a subset of measurement resources and / or signals (e.g., SSB, CSI-RS, TRS, or PRS, etc.) are not applicable in certain availability states. The WTRU can determine that a subset of uplink or downlink resources (e.g., PRACH, PUSCH, or PUCCH, etc.) are not applicable in certain availability states. The WTRU can transmit only some uplink signals in a subset of network availability states (e.g., SRS, location SRS, PRACH, or UCI, etc.).

[0114] Network nodes or cells in NES state and / or mode may operate in cell DTX mode and / or cell DRX mode or spatial and / or power domain adaptation mode, where the cell may not be able to transmit and / or receive at full capacity or full coverage at all times. This may result in one or more QoS requirements of signals and / or channels transmitted in UL and / or received in DL not being met. For non-periodic traffic, such as UL and DL transmissions and / or retransmissions, delays may occur due to cell DTX mode and / or cell DRX mode. Similarly, for periodic traffic, any interruptions and / or skips during certain periods may cause data buffering, which, if data is buffered for a long time, can lead to QoS failures.

[0115] When transmitting PDU sets (including a set of interdependent PDUs), any increase in scheduling delay and / or loss of PDU subsets due to NES can lead to QoS failures, including for previously transmitted PDUs and / or PDU sets. Other issues related to jitter within and between PDU sets (e.g., due to network congestion or processing delays) can cause misalignment between the expected timing of data transmission and the cell DTX and / or cell DRX modes.

[0116] When configured for multi-push-coil CG transmissions, the WTRU performing autonomous retransmissions may incur significant delays if the network fails to receive and / or detect the initial transmission due to NES mode operation. This can cause transmission intervals to exceed the delay budget or the associated DRB-QoS TTL. Additionally, any SRB / RRC data critical to system performance, as well as high-priority MAC CEs (e.g., PHR, BSR) transmitted on the CG, may also experience substantial delays due to cell DRX periods. Several issues may arise in this regard. For example, one problem to be addressed is how to ensure QoS for different traffic types (e.g., PDU sets, control information) while enabling cells to operate in NES mode as much as possible.

[0117] As described herein, a cell DTX active period can be a duration during which the configured cell DTX mode is active (e.g., one or more time periods during the cell DTX mode's on-duration period). The WTRU can be predefined and / or pre-configured to monitor the PDCCH and one or more DL signals and / or channels during this period. In some examples, this may only apply after the network (NW) has indicated that the cell DTX configuration should be activated. As described herein, a cell DTX inactive period can be a duration during which the configured cell DTX mode is not active, i.e., inactive (e.g., time periods outside the periodically on-duration period of the cell DTX mode). In many more examples, this may only apply after the network has indicated that the cell DTX configuration should be activated. As described herein, a cell DRX active period can be a duration during which the configured cell DRX mode is active (e.g., one or more time periods during the cell DRX mode's on-duration period). The WTRU can be predefined to be allowed to transmit UL signals and on UL channels during this period. This may only apply after the network has instructed to activate the cell DRX configuration. As described herein, a cell DRX inactivity period can be a duration during which the configured cell DRX mode is not active, i.e., inactive (e.g., a period outside the periodic on duration of the cell DRX mode). In some examples, this may only apply after the network has instructed to activate the cell DRX configuration. As described herein, an activated cell DRX and / or cell DTX can be the state of a configured cell DRX and / or cell DTX mode, wherein this state has been activated by L1 and / or L2 DL signaling, RRC (re)configuration, and / or cell common configuration, and has not been deactivated. As described herein, a deactivated cell DRX and / or cell DTX can be the state of a configured cell DRX and / or cell DTX mode, wherein this state has been deactivated by L1 and / or L2 DL signaling (e.g., dedicated or group common signaling), RRC (re)configuration, and / or cell common configuration. As described herein, availability status may be associated with cell DTX and / or cell DRX, and the two terms are used interchangeably. The WTRU can implicitly determine the cell DTX status from the determined active availability status, and vice versa. The WTRU can implicitly determine the cell DRX status from the determined active availability status, and vice versa.

[0118] Generally, cell DTX configuration can treat active cell DTX periods as a set of cell DTX opportunities. This set can be parameterized by at least one of the following: the duration between the start of successive opportunities (Cell-DTX-cycle), the offset (Cell-DTX-offset), and / or the duration of each cell DTX opportunity (Cell-DTX-duration). For example, such parameters can be represented in subframes (or milliseconds) in the same manner as long WTRU DRX cycles. In this case, cell DTX opportunities can include time periods that begin in a subframe satisfying [SFN×10 + number of subframes] modulo (Cell-DTX-cycle) = (Cell-DTX-offset), where SFN is the system frame number, and subsequently end (Cell-DTX-duration).

[0119] Cell DTX configuration may also include a slot offset relative to the start of a subframe in which the cell DTX timing begins. At least one parameter of the cell DTX configuration may be signaled via RRC, MAC CE, and / or DCI (WTRU-specific or WTRU group-common). The WTRU may predefine and / or configure a cell DTX and / or cell DRX configuration and / or a subconfiguration having one or more parameters and behaviors described herein. For example, parameters and / or behaviors may be one or more applicable CG or semi-persistent scheduling (SPS) configurations. For example, the WTRU may activate such a CG configuration when the cell DTX and / or cell DRX configuration is activated. The WTRU may configure whether the CG takes precedence over the configured cell DTX mode and / or configured cell DRX mode (e.g., whether the WTRU can transmit and / or receive on UL CG or DL ​​SPS respectively during cell DRX or cell DTX inactive periods) based on the CG configuration or a subconfiguration (e.g., a subset of CG resources or periods). For example, parameters and / or behaviors could be: whether the WTRU should monitor PDCCH for dynamic granting, dynamic DL allocation, or other DL signaling (e.g., DCI, PDCCH skip indication with CRC scrambled via PS-RNTI) during cell DTX inactivity periods. For example, parameters and / or behaviors could be: whether the WTRU is allowed to transmit on dynamic granting or CG. For example, parameters and / or behaviors could be one or more PRACH resources or PRACH resource configurations that may or may not be applicable during cell DRX inactivity periods, or if cell DRX configuration is activated. For example, parameters and / or behaviors could be SR / PUCCH resources or SR / PUCCH resource configurations that may or may not be applicable during cell DRX inactivity periods, or if cell DRX configuration is activated. For example, parameters and / or behaviors could be CSI reporting or CSI resource configurations that may or may not be applicable during cell DRX inactivity periods, or if cell DRX configuration is activated. For example, parameters and / or behaviors can be SRS resources or SRS resource configurations that may or may not be applicable during periods when cell DRX is inactive, or if cell DRX configuration is activated.

[0120] A WTRU can be configured with multiple cell DRX and / or cell DTX configurations simultaneously within a given serving cell. A WTRU can be configured with a primary or default cell DTX and / or cell DRX configuration, which it can apply by default. When receiving signaling instructions to activate a cell DTX and / or cell DRX configuration, the WTRU can deactivate one or more other DTX and / or DRX configurations (e.g., or all other configurations). When receiving signaling instructions to deactivate a cell DTX and / or cell DRX configuration, the WTRU can activate another configuration or activate the default cell DTX / DRX configuration. When a timer expires, the WTRU can fall back to the default cell DRX and / or default cell DTX configuration. When receiving DL signaling or data, or an instruction from the network to maintain a given non-default cell DTX or cell DRX state, the WTRU can reset the timer.

[0121] The WTRU can be configured to transmit indications (e.g., wake-up requests or wake-up signals and / or wake-up indications) to the network to modify the availability state to a state in which resources satisfying the WTRU's requirements are available. The wake-up signal and / or indication may be referred to as a cell wake-up signal (WUS) or UL indication. The WTRU can be predefined and / or configured based on each availability and / or NES state, each cell DTX, cell DRX, each SSB and / or beam, and each resource (e.g., CG, SPS) configuration or sub-configuration, wherein the predefined and / or configuration includes one or more resources or behaviors associated with the cell wake-up signal (WUS) indication.

[0122] For example, there may be one or more sequence, time, or frequency resources associated with a transmission indicated by a cell WUS. Resources associated with a cell WUS may correspond to any of the following: PRACH resources or PRACH resource configurations and / or SR / PUCCH resources or SR / PUCCH resource configurations, or a new set of sequence, time, or frequency resources. Resources for a cell WUS may or may not be applicable during the WUS event (e.g., resources or configurations during which the WTRU can transmit a cell WUS indication and the base station can monitor UL transmissions). Resources for a cell WUS may or may not be applicable during periods of active and / or inactive cell DTX and / or inactive cell DRX.

[0123] Figure 2 This diagram illustrates an example multi-PUSCH CG configuration according to an embodiment. WTRU (WTRU) in the communication network 200 Figure 2(Not shown) can receive a cell DRX activation indication 202 associated with at least one cell and / or at least one gNB associated with that cell. The cell DRX activation indication 202 may include a cell DRX configuration. The cell DRX configuration may indicate one or more cell DRX cycles. Each cell DRX cycle may include one or more active and / or inactive periods for the cell. For example, the cell DRX cycle 204 indicated by the cell DRX activation indication 202 may include a cell DRX active period 206 and a cell DRX inactive period 208.

[0124] Furthermore, the WTRU can receive multi-PUSCH CG configurations. A multi-PUSCH CG configuration can refer to one or more configuration resources or CG configurations, where each CG configuration can include a set of PUSCH timings. The set of PUSCH timings can include consecutive and / or non-consecutive PUSCH timings for each slot and / or each CG period. For example, in Figure 2 In the illustrated multi-PUSCHCG configuration, the PUSCH timing indicated by the multi-PUSCHCG configuration may include one or more default CGs 210 occurring during the cell DRX active period 206 and one or more conditional CGs 212 occurring during the cell DRX inactive period 208. For example, the default CG 210 may include a first PUSCH timing and a second PUSCH timing, and the conditional CG 212 may include a third PUSCH timing and a fourth PUSCH timing.

[0125] In the examples, a multi-PUSCH CG configuration may include one or more CG periods (e.g., each CG period may repeat periodically according to a certain periodicity value). In the examples, a CG period in a multi-PUSCH CG configuration may include one or more consecutive or discontinuous time slots. In the examples, a time slot in a CG period of a multi-PUSCH CG configuration may include one or more consecutive or discontinuous PUSCH opportunities. In the examples, a PUSCH opportunity in a time slot / CG period of a multi-PUSCH CG configuration may include one or more consecutive or discontinuous symbols (e.g., time-domain resources) with a certain symbol length. A PUSCH opportunity may include one or more resource blocks or groups of resource blocks in the frequency domain. As described herein, PUSCH usage can refer to any of the number, location, position, or timing of one or more PUSCH opportunities in one or more time slots or periods, which may be associated with one or more multi-PUSCH CG configurations.

[0126] As described herein, an Unused Transmission Occasion (UTO) can refer to an indication (UTO indication) of any one of one or more PUSCH occasions in one or more time slots or periods that the WTRU may not use for uplink transmissions. For example, the UTO indication can be transmitted by the WTRU in a bitmap format, where each bit in the bitmap can correspond to one or more PUSCH transmission occasions that the WTRU may intend to use or not use during uplink transmissions. For example, a '1' in the bitmap can indicate that the corresponding PUSCH occasion is unused, and a '0' can indicate that the corresponding PUSCH occasion can be used by the WTRU. The length of the bitmap can include N bits, where N can correspond to the number of PUSCH occasions configured in one or more CG periods associated with one or more multi-PUSCH CG configurations. The UTO indication can be transmitted in the UCI using PUSCH (e.g., multiplexed with one or more PUSCH occasions) and / or PUCCH resources.

[0127] As described herein, one or more low-latency QoS conditions may include triggers associated with a PDB, failure to deliver one or more PDUs from a PDU set, and / or out-of-order SDU SNs. As described herein, one or more low-latency QoS conditions may exist. For example, a low-latency condition may be the arrival of data with a certain priority, i.e., the arrival of a PDU associated with a priority value higher than a threshold priority value. WTRUs can be configured with priority indexes based on LCHs or DRBs. When high-priority data or data associated with a predetermined priority value arrives, the WTRU may apply any method associated with satisfying the low-QoS requirement. For example, a low-latency condition may be the remaining time in the PDB, such as, but not limited to, if the remaining time in the PDB associated with the data is less than a threshold latency, or expires, or is about to expire. For example, a low-latency condition may be the time since the data arrived. If the time elapsed since the data arrived in the WTRU's buffer is less than or greater than a configured or predefined threshold time period, the WTRU may apply any method associated with satisfying the low-QoS requirement. For example, a low-latency condition may be missing one or more PDUs from a PDU set. When it is determined that one or more PDUs (e.g., anchor PDUs) from a PDU set have not been successfully transmitted, not acknowledged by a peer WTRU, or not received from a higher layer, the WTRU may apply any method associated with satisfying a low QoS requirement state. The WTRU may be configured to determine and / or identify which PDU in the PDU set is the anchor PDU (e.g., a PDU associated with certain frames of a video stream). For example, a low latency condition could be receiving acknowledgments of out-of-order PDCP SNs received from a peer WTRU. For instance, if the WTRU receives successful acknowledgments of reception for PDCP SNs 1, 2, and 4, the WTRU may apply any method associated with satisfying a low QoS requirement state because SN 3 was not acknowledged. Similarly, if or when SN 3 is not received from a higher layer within the WTRU, the WTRU may apply any method associated with satisfying a low QoS requirement state. For instance, a low latency condition could be intra-WTRU prioritization among one or more PDUs of different priorities. When one or more PDUs are dropped due to intra-WTRU prioritization of a higher-priority HARQ-ACK or higher-priority SL PDU, the WTRU may apply any method associated with satisfying the low QoS requirement state. For example, a low latency condition may include a triggered BSR or SR caused by the arrival of data from a DRB configured with low latency QoS requirements. For example, a low latency condition may be configuring a lifetime or low latency QoS parameter or priority for at least one SL DRB. For example, a low latency condition may be receiving DL data associated with a certain priority value or from a DL DRB associated with an SL DRB.As described herein, meeting low-latency QoS requirements can lead to the implementation of any of the methods described herein to meet the PSDB or latency associated with the PDU set. Furthermore, as described herein, DRB, LCH, and LCG can be associated with each other or used interchangeably.

[0128] Data units comprising one or more PDUs, PDU sets, or data bursts associated with a specific type of traffic (e.g., XR traffic) may be marked or indicated by WTRUs (e.g., in the UL, NAS, SDAP, PDCP, RLC, MAC layers at the application level), including but not limited to any of the following: Serial Number (SN), where the SN may be marked on a per PDU, per PDU set, or per data burst basis, and different types of SNs may include a count (COUNT), a superframe number (HFN), and / or a PDU. SN, QoS attributes (such as, but not limited to, QFI, PSER, PSDB, PSIHI), PDU set attributes (such as, but not limited to, type, importance and / or priority), total payload size (e.g., bits / byte, number of PDUs), the starting PDU and / or data burst of the PDU set, and / or the ending / last PDU and / or data burst of the PDU set (end marker); timing and / or counting information, wherein a bitmap indicates the time when a PDU is generated or received in the buffer, the remaining delay relative to the delay budget (e.g., PSDB), the hop count (e.g., number of hops elapsed or remaining), and / or the timing offset relative to a reference time (e.g., SFN, arrival time of the first PDU in the PDU set); association information, such as, but not limited to, identifiers (ID) and / or indexes, for indicating the association of the PDU set with one or more other PDU sets in the same and / or different flows.

[0129] One or more markers (e.g., in the PDU header and / or subheader) may be used by the transmitting entity and / or receiving entity to perform certain actions associated with any of the following: determining whether a data unit can be prioritized and / or multiplexed in one or more TBs, the number of TBs that can be used, the number of HPIs associated with the TBs that can be used, whether a data unit can be transmitted in one or more time slots, timings or periods, whether a data unit can be delayed to a subsequent time slot, timing or period, and the number of repetitions that can be applied to a data unit or a subset of data units.

[0130] Data units, including PDUs, PDU sets, or data bursts associated with specialized traffic (these data units having the same or different QoS requirements and / or characteristics), can be mapped to one or more forwarding configurations. Different forwarding configurations can be configured to implement and / or enforce different QoS when transmitting PDUs and / or PDU sets using DG and / or CG resources. In the example, a PDU set received from an application in one or more QoS flows can be mapped to one or more forwarding configurations (e.g., a DRB with common / different PDCP entities or an LCH with different configurations), where the forwarding configurations may be associated and / or grouped to implement and / or ensure PDU set-level QoS. At the time of mapping, a set of parameters (e.g., priority, PBR, BSD) and / or configurations (e.g., LCP restrictions) can be applied at the forwarding configuration to implement and / or enforce PDU set-level QoS or data burst-level QoS for the PDUs and / or PDU sets in the buffer associated with the forwarding configuration.

[0131] In the example, the PDUs in the PDU set can have different expected QoS (e.g., residual delay) that must be satisfied during transmission and / or during NES modes (e.g., cell DRX or cell DTX). In this case, based on the determination of the expected QoS of the PDUs and / or the PDU set, the WTRU can apply certain mapping, buffering and / or queue management, multiplexing, and scheduling mechanisms in one or more layers of the AS layer protocol stack to ensure that the expected QoS of the PDUs and / or the PDU set is satisfied during transmission. To ensure the QoS of data units, different layers in the forwarding configuration can be configured with different configuration parameters. Configuration parameters can be configured on a per DRB, per LCH, and / or per data unit profile basis (e.g., PDU set profile, data burst profile, multi-mode profile). For example, configuration parameters may include: supporting SN allocation at PDCP and sorting and / or reordering of PDUs and / or PDU sets; supporting AM, UM, or TM at RLC; LCP rules and / or restrictions during TB assembly based on associated LCH parameters (e.g., PBR, BSD, priority); HARQ transmission and / or retransmission at MAC; and mapping TBs to DG and CG resources at PHY.

[0132] As used herein, the term “expected QoS” refers to the expected margin of a QoS metric (e.g., latency, data rate, or reliability) before data units, including PDUs, PDU sets, and / or data bursts, arrive or are received at one or more buffers and / or sublayers at the WTRU. In the example, expected QoS corresponds to the time duration available at the WTRU from reception (e.g., from a higher layer and / or another WTRU or another device) to successful transmission of data via a radio link (e.g., a Uu link or sidelink). For example, expected QoS may also correspond to the remaining time or TTL (e.g., the maximum time available for buffering, processing, and transmission) of individual data units. For example, expected QoS can be determined based on the following: indications and / or markers in the data unit (e.g., QFI, timestamp, start or end marker, PDU set ID / index in the packet header and / or packet subheader), indications from higher and / or upper layers (e.g., control PDUs), time spent on the data unit in the buffer, and the use of a timer (which can be set when a data unit is received (e.g., the first PDU in the PDU set arrives) and reset / stopped when the timer (i.e., the configured time duration) expires).

[0133] In some examples, the expected QoS can be flexible (e.g., more stringent or less stringent, depending on the stage or state of the transmission) compared to the default QoS metric associated with the same data unit. For example, if a PDU set arrives late at the WTRU, and is cached in the LCH due to the cell DRX or an importance (or priority) value for the PDU set indicating it is high (e.g., above a threshold priority value), and has experienced more latency and jitter at the application layer (e.g., due to the encoder) or in the WTRU cache, the expected delay budget for the PDU set (which must be satisfied during transmission over the Uu link) will be lower than the default PSDB typically used to send the PDU set. Alternatively, if the PDU set arrives early or its importance (or priority) value is low (e.g., below a threshold priority value), the expected delay budget during transmission over the Uu link can be considered more lenient than the PSDB. In summary, the expected QoS of a PDU set can be flexible and dynamic, where for a fixed QoS (e.g., PSDB, PSER), an increase and / or decrease in expected QoS before transmission can be respectively translated into a decrease and / or increase in expected QoS during transmission and / or reception via the radio link.

[0134] In one approach, the WTRU may receive configuration information and / or sub-configurations (e.g., a subset of parameters associated with the configuration, updates to the configuration) from the network associated with QoS satisfaction during NES. This configuration information and / or configuration parameters may be applicable to any techniques and / or methods disclosed herein. During CONNECTED mode or in INACTIVE / IDLE mode (e.g., the RRC Release message upon transition from CONNECTED mode), the configuration and / or sub-configurations may be received in broadcast transmissions (e.g., MIB, SIB, etc.) or in dedicated RRC signaling (e.g., in the RRC Reconfiguration message). Alternatively, for example, the configuration and / or sub-configurations may be received by the WTRU in one or more NES or one or more cell activity indicators. Such NES and / or cell activity indicators may be received, for example, in RRC signaling, MAC CE, PDCCH (e.g., WTRU-specific or group-common DCI), or PDSCH.

[0135] As disclosed herein, the configuration and / or sub-configuration received by the WTRU may include a wide variety of information. For example, the configuration and / or sub-configuration received by the WTRU may include one or more of the following: CG resource configuration parameters (e.g., the type of CG configuration, parameters associated with multi-PUSCH CG resources and / or configurations, etc.); cell DTX and / or cell DRX configurations; and / or conditions and / or thresholds for selecting or using any resources that occur during periods of cell DRX inactivity.

[0136] For CG resource configurations and / or parameters, there may be a type of CG configuration, such as a single CG or multiple PUSCHCGs. The type may include any of the following: Type 1 (e.g., resource parameters and activation and / or deactivation indications are provided via RRC signaling), Type 2 (e.g., resource parameters are provided via RRC signaling, and other subsets of resource parameters and activation and / or deactivation indications are provided via DCI or MAC CE), and a new Type 3 (e.g., a subset of resource parameters may be provided via RRC and / or MAC CE and / or DCI signaling, and other subsets of parameters may be selected by WTRU).

[0137] For CG resource configurations and / or parameters, there may be one or more parameters associated with the multi-PUSCH CG resource and / or configuration. For example, a parameter associated with the multi-PUSCH CG resource and / or configuration could be the number of PUSCH opportunities in a time slot and / or CG period. For example, a parameter associated with the multi-PUSCH CG resource and / or configuration could be the start offset of the PUSCH opportunity and / or CG period in the multi-PUSCH CG configuration. For example, a parameter associated with the multi-PUSCH CG resource and / or configuration could be periodicity (e.g., associated with the CG period of the multi-PUSCH CG). For example, parameters associated with multi-PUSCH CG resources and / or configurations could be CG timers (e.g., the duration for which the WTRU determines whether a transmission in one or more PUSCH moments is successful and / or unsuccessful. If no indication is received during a transmission and the CG timer expires, the WTRU can assume an acknowledgment (ACK). For example, if a dynamic authorization for a retransmission is received in the DCI along with the HARQ process ID, the WTRU can assume a negative acknowledgment (NACK). For example, parameters associated with multi-PUSCH CG resources and / or configurations could be CG retransmission timers (e.g., the duration for which the WTRU performs a discretionary retransmission of a TB. For example, if no indication corresponding to the HARQ process associated with the TB is received, the WTRU can perform a retransmission of the TB in the next PUSCH moment). For example, with multi-PUSCH... Parameters associated with CG resources and / or configurations may be one or more Time Domain Resource Allocation (TDRA) parameters associated with a PUSCH timing (e.g., one or more SLIV values, where each SLIV can indicate the starting offset symbol of the PUSCH timing and the length and / or number of symbols for each PUSCH timing), an index of a row in a pre-configured mapping and / or table associated with the TDRA, where the row can indicate one or more SLIV values ​​corresponding to different PUSCH timings in the CG period). For example, parameters associated with multi-PUSCH CG resources and / or configurations may be one or more Time Domain Resource Allocation (FDRA) parameters associated with a PUSCH timing (e.g., one or more Resource Indicator Values ​​(RIVs) corresponding to multiple contiguous resource blocks (RBs) or groups of resource blocks), an index of a row in a pre-configured mapping and / or table associated with the FDRA, where the row can indicate one or more RIV values ​​corresponding to one or more PUSCH timings in the CG period). For example, parameters associated with multi-PUSCH CG resources and / or configurations may be DMRS configurations (e.g., symbols and / or resources for the DMRS used for one or more PUSCH timings or slots).For example, parameters associated with multi-PUSCH CG resources and / or configuration may be MCS tables (e.g., whether the same or different MCS sets are applied to one or more PUSCH moments within a CG period. For example, WTRU may be configured to use a high MCS index for the initial subset of one or more PUSCH moments within a slot and / or period, and a low MCS index for subsequent subsets of one or more PUSCH moments). For example, parameters associated with multi-PUSCH CG resources and / or configuration may be resources used to indicate PUSCH usage (e.g., whether the resource used to send UCI on a UTO in a multi-PUSCH CG is a PUSCH or a PUCCH). For example, parameters associated with multi-PUSCH CG resources and / or configuration may be bandwidth portions and numerators (e.g., SCS values, etc.). For example, parameters associated with multi-PUSCH CG resources and / or configuration may be the number of HARQ processes and the corresponding HARQ process IDs (e.g., whether HARQ processes are configured for each PUSCH moment or for multiple PUSCH moments). For example, a parameter associated with multi-PUSCH CG resources and / or configuration could be repetition K (e.g., the number of repetitions allowed for a TB to repeat and transmit across multiple PUSCH opportunities). Another parameter associated with multi-PUSCH CG resources and / or configuration could be a mute mode associated with multi-PUSCH CG (e.g., a WTRU can be configured with a set of mute modes indicating PUSCH opportunities that are muted or unavailable to the WTRU during CG periods. Such mute modes can be associated with different cell DRX configurations and can be applied when the corresponding cell DRX configuration is activated).

[0138] For cell DTX and / or cell DRX configurations, parameters associated with the cell DTX and / or cell DRX configuration may include a start offset (e.g., a slot and / or symbol offset relative to the SFN or reference slot and / or symbol), the duration of active and / or inactive periods, periodicity, index, and / or ID. For example, a WTRU may be configured with one or more cell DTX modes and / or cell DRX modes. Each mode and / or configuration may be associated with a different set of parameters. Another parameter may be an indication of activation and / or deactivation of cell DTX and / or cell DRX (e.g., received by the WTRU in RRC signaling, MACCE, WTRU-specific DCI, group common DCI, or cell common DCI).

[0139] There may be one or more conditions and / or thresholds for selecting or using any resources that appear during a cell DRX inactivity period. For example, one condition and / or threshold for selecting and / or using any resources that appear during a cell DRX inactivity period could be the type of data unit. For example, a data unit with a specific marker or indication (e.g., PSIHI indication) and / or a data unit associated with certain types of media and / or video frames (e.g., I-frames, base frames, or reference frames). For example, one condition and / or threshold for selecting and / or using any resources that appear during a cell DRX inactivity period could be an importance or priority value associated with a data unit (including any subset of PDUs in a PDU set) that is greater than a threshold priority value. For example, one condition and / or threshold for selecting and / or using any resources that appear during a cell DRX inactivity period could be the payload size of one or more data units that is greater than a threshold payload size value. For example, a data unit could include a PDU, a subset of PDUs in a PDU set, or one or more PDU sets that are received and / or expected to be received by the WTRU from a higher layer and / or by the application in the LCH. For example, a condition and / or threshold for selecting or using any resource that appears during a cell DRX inactive period could be that the priority value of one or more LCHs configured to receive data units is greater than a threshold priority value. For example, a condition and / or threshold for selecting and / or using any resource that appears during a cell DRX inactive period could be that the payload size of one or more remaining data units is greater than a threshold payload size value. For example, remaining data units correspond to a second subset of data units that may arrive at the LCH later and / or remain in the LCH after a first subset of data units were used by the PUSCH during a cell DRX active period. For example, a condition and / or threshold for selecting and / or using any resource that appears during a cell DRX inactive period could be that the percentage of remaining PDUs in the PDU set that have not yet been transmitted is less than or greater than a threshold percentage value. For example, a condition and / or threshold for selecting and / or using any resource that appears during a cell DRX inactive period could be that the QoS associated with the PDU set is greater than and / or less than a threshold. For example, the PSDB of the PDU set is less than a threshold and / or the PSER of the PDU set is less than a threshold. For example, a condition and / or threshold for selecting and / or using any resources that occur during a cell DRX inactive period could be that the remaining time of a data unit (e.g., relative to the PSDB) is less than a threshold remaining time value. For example, a condition and / or threshold for selecting or using any resources that occur during a cell DRX inactive period could be that the remaining time of the remaining data units (in the case of being deferred to the next cell DRX active period) is less than a threshold remaining time value. For example, this condition might apply if the remaining PDUs in the PDU set cannot be deferred to the next cell DRX active period due to the low remaining time associated with the PSDB.

[0140] Among a range of approaches, the WTRU can determine the timing of PUSCHs associated with one or more CG configurations (e.g., a multi-PUSCH CG configuration) that may be unavailable for UL data transmission due to the activation of the cell DRX mode. In this case, the WTRU can perform one or more actions (or functions), including, for example, prioritizing only one or more subsets of CG PUSCHs from the CG configuration, transmitting indications to request new resources, or adapting CG PUSCHs to be consistent with the cell DRX. For example, this / these approaches can be applied to satisfy certain conditions associated with the QoS of a data unit (e.g., a PDU or set of PDUs).

[0141] In the examples described herein, the WTRU can receive PDUs associated with one or more PDU sets from a higher layer and / or the application. For example, such PDUs may be received in a single burst or simultaneously in multiple bursts, where each burst may include one or more subsets of the PDUs in the PDU set. When configured with a multi-PUSCH CG for transmitting data units, the WTRU can determine PUSCH usage based on the number of PDUs and the arrival of PDUs in the PDU set. This PUSCH usage may refer to determining the expected number of PUSCHs and / or the location of PUSCHs in the CG period and / or configuration, anticipating that these PUSCHs will be used or not used by the WTRU during UL transmission. For example, after receiving a first subset of PDUs from the PDU set in the WTRU buffer, a second subset of the PDUs expected by the WTRU may not be received immediately due to jitter or delay at the application. In this case, the WTRU may use the first subset of PUSCH timings in the CG period of the multi-PUSCH CG configuration to transmit the first subset of PDUs from the PDU set. The WTRU may determine a certain number of PUSCHs after the first subset of PUSCHs is not used or skipped to address jitter. For example, the WTRU may determine to use a second subset of PUSCHs to transmit a second subset of PDUs after a certain number of gaps, or it may skip one or more PUSCHs. The WTRU may also determine that one or more additional PUSCHs are not used in the CG period and / or configuration, in which case there may be no PDUs in the buffer for UL transmission. This information about PUSCH usage (associated with the number and location of PUSCHs that the WTRU intends to use or not use) may be transmitted to the network in one or more indications (e.g., UTO-UCI or UCI) before or during UL data transmission.

[0142] In one scenario, the WTRU can selectively prioritize one or more CG PUSCH timings that occur during cell DRX active periods and / or cell DRX inactive periods. In one example, after receiving PDUs from a higher layer and mapping such PDUs to one or more LCHs, the WTRU can determine the first set of PUSCH timings within a time window (e.g., a CG period) based on the payload size of the PDUs in the LCH cache. This determination can be made upon receiving an indication from the network regarding the activation of a cell DRX mode. For example, in this case, the first set of PUSCHs could be PUSCHs that occur during cell DRX active periods. The WTRU can be configured with a set of conditions for using CG PUSCHs that occur during cell DRX active periods and / or cell DRX inactive periods. For example, such conditions might be designed to prioritize PUSCHs that occur during cell DRX active periods for data transmission before the WTRU selects any PUSCH during inactive periods. In this scenario, there may be no configuration conditions or only legacy conditions (e.g., payload size based on data in the WTRU cache) that apply to WTRU selection of PUSCHs during cell DRX active periods, while new conditions may apply to selection of PUSCHs during cell DRX inactive periods to enable the network and / or cells to operate in NES or cell DRX inactive modes. The conditions and / or thresholds used to select and / or use CG PUSCHs that occur during cell DRX inactive periods can include any of the conditions described herein.

[0143] If the first set of PUSCHs that appears during a cell DRX active period is sufficient to transmit the PDU set and / or if none of the above conditions are met, the WTRU may transmit an indication to the network at a selected PUSCH timing (e.g., in UCI or UTO-UCI). The WTRU can then use the selected first set of PUSCHs to transmit the PDUs.

[0144] If any of the above conditions are met, the WTRU can determine a second set of CG PUSCHs during the CG period for transmitting the remaining data units. This second set of CG PUSCHs can correspond to any of the following: PUSCH timings within the CG period of a multi-PUSCH CG configuration that may occur during a cell DRX inactivity period, and / or PUSCHs associated with another CG configuration or with another cell. To enable the network to operate in inactive and / or sleep modes as much as possible, the WTRU can be further configured with certain rules and / or restrictions when determining the second set of CG PUSCHs. For example, such rules and / or restrictions used to determine CG PUSCHs in the second group may include any of the following: selecting only consecutive PUSCH opportunities (e.g., PUSCHs without any gaps or unused PUSCHs); selecting only PUSCH opportunities after an offset of K opportunities / slots / symbols from the start of an inactive period (e.g., to allow the network to process any indications received from the WTRU); selecting only PUSCH opportunities within a configuration window (e.g., start offset or duration) during an inactive period; and / or selecting only PUSCH opportunities associated with a set of configuration parameters (e.g., SCS / Numerology, BWP, MCS, SLIV, RB / RBG, or TCI status, etc.). The WTRU may use these rules and / or restrictions when selecting PUSCH opportunities during an inactive period to transmit any remaining data units in the LCH buffer.

[0145] In one scenario, the WTRU may transmit indications regarding PUSCH usage during cell DRX active periods and / or cell DRX inactive periods. In an example, the WTRU may transmit an indication to the network that includes information about PUSCH usage associated with the timing of PUSCH usage during cell DRX active periods and / or cell DRX inactive periods when the WTRU intends to use or not use it. This information about PUSCH usage may correspond to different subsets of CG PUSCHs in a CG period or CG configuration. For example, this information and / or indication may be sent by the WTRU in UCI (e.g., using PUCCH or PUSCH resources), UL WUS, MAC CE, or RRC signaling. For example, if the WTRU is unable to transmit the indication (possibly due to the unavailability of PUCCH or PUSCH resources or during cell DRX inactive periods), the WTRU may transmit the indication in UL WUS (e.g., in pre-configured RACH resources and / or timings).

[0146] Instructions and / or information regarding PUSCH usage can be transmitted in a single instruction or in multiple instructions. For example, a single instruction may include information about PUSCH usage (e.g., PUSCHs that the WTRU intends to use or not use) across one or more cell DRX active periods and cell DRX inactive periods. When information about PUSCH usage is transmitted in multiple instructions, at least one instruction may correspond to a PUSCH timing that occurs during a cell DRX active period (e.g., a first set of PUSCHs), and another instruction may correspond to a PUSCH timing that occurs during a cell DRX inactive period (e.g., a second set of PUSCHs). One or more such instructions may indicate PUSCH usage during a cell DRX active period and / or a cell DRX inactive period within a single CG period or multiple CG periods or CG configurations. Information and / or instructions regarding PUSCH usage may be transmitted in a bitmap format, where each bit in the bitmap may correspond to one or more PUSCH timings across a cell DRX active period and / or a cell DRX inactive period. Alternatively, for example, instructions regarding PUSCH usage can be sent in multiple bitmaps, each of which can be associated with a PUSCH timing during active and / or inactive periods.

[0147] In the example, the WTRU can be configured with any of the resources, timings, slots, symbols, or time windows or ranges (e.g., N timings, slots, symbols) for transmitting indications of PUSCH usage corresponding to a first subset of PUSCHs during a cell DRX active period and / or a second subset of CG PUSCHs during an inactive period. For example, the WTRU can be configured to transmit indications of at least N timings, slots, and symbols before the first PUSCH timing and / or a reference PUSCH timing associated with the first and / or second subset of PUSCHs, or before the start of a cell DRX inactive period. Alternatively, the WTRU can be configured to transmit PUSCH usage indications corresponding to PUSCHs (e.g., a second set of PUSCHs) during an inactive period during a cell DRX active period, possibly in the PUCCH or in one or more PUSCH timings during an active period. For example, alternatively, the WTRU can be configured to transmit indications in each of the PUSCH timings that the WTRU intends to use for data transmission during both a cell DRX active period and a cell DRX inactive period.

[0148] In another example, the WTRU transmits a second indication when transmitting a first indication regarding PUSCH usage associated with a CG PUSCH timing that the WTRU intends to use or not use during a cell DRX active period and / or a cell DRX inactive period. For example, the second indication may be transmitted to override the first indication (e.g., due to updated information about the payload or the arrival of a new data unit), where the WTRU may update a subset of PUSCH timings that might have previously been indicated as 'used' to 'unused,' or vice versa. The WTRU may be configured to transmit the second indication no later than J1 configuration timings, slots, or symbols after the transmission of the first indication and at least J2 configuration timings, slots, or symbols before the first PUSCH timing or reference PUSCH timing during a cell DRX active period and / or a cell DRX inactive period, or before the start of a cell DRX inactive period.

[0149] In one scenario, the WTRU may receive acknowledgments regarding the use of PUSCH timings during inactive periods. In an example, the WTRU may monitor the PDCCH used to receive acknowledgments regarding the use of CGPUSCH timings occurring during cell DRX inactivity periods, possibly while transmitting indications regarding PUSCH use. For example, the acknowledgment may be received in DCI (e.g., a new DCI format or paging DCI), MAC CE, or RRC signaling. For instance, the acknowledgment may indicate PUSCH timings permitted for use by the WTRU during cell DRX active periods and / or cell DRX inactive periods. Alternatively, the acknowledgment may indicate the activation of a new resource (e.g., DG resource) or another CG configuration for the WTRU to use.

[0150] In the example, when activating NES mode (e.g., activating cell DTX and / or cell DRX), or when transmitting an indication of PUSCH usage (possibly to receive an acknowledgment indication), the WTRU can switch to a pre-configured search space (SS) or core set while monitoring PDCCH. The SS may be associated with a cell DTX active mode and / or a cell DRX active mode, which may differ from the SS used prior to activating NES mode (e.g., activating cell DRX / DTX). The SS may only be applied during cell DTX active periods, which may or may not coincide with cell DRX active periods. Alternatively, the WTRU can switch between different PDCCH monitoring modes in the SS based on NES mode and / or when transmitting an indication of PUSCH usage. For example, the WTRU may use a low-density and / or low-periodicity monitoring mode before transmitting the indication and switch to a high-density and / or high-periodicity mode after transmitting the indication. In another alternative, when activating NES mode or when transmitting an indication of PUSCH usage, the WTRU may monitor PDCCHs other than the regular SS in an additional pre-configured SS. Monitoring of additional SS can be adjusted based on any of the following: the DRB / LCH used for data transmission and / or reception, the type of data units to be processed or expected to be received in the buffer (e.g., a set of high-importance PDUs or a set of PDUs with PSIHI), the QoS of data units in UL and / or DL ​​(e.g., priority, remaining time), the type of resources used for data transmission and / or reception (e.g., CG configuration associated with a single and / or multiple PUSCHs or SPS configuration associated with a single and / or multiple PDSCHs), and the type of indication transmitted (e.g., UCI, UTO-UCI regarding the PUSCH used).

[0151] The WTRU can receive acknowledgment indications in bitmap or window format, where the window format can indicate the start offset and the number of consecutive and / or valid PUSCHs allowed for use by the WTRU. In the example, the WTRU can monitor the PDCCH for information regarding acknowledgment indications for K timings, symbols, or time slots following the transmission of an indication of PUSCH usage, possibly to account for processing time in the network. In this case, the WTRU can be configured with one or more K parameter values, where a first K value can be used and / or assumed by the WTRU if the PUSCH usage indication is transmitted during a cell DRX active period, and a second K value can be used if the indication is transmitted during a cell DRX inactive period.

[0152] If an acknowledgment (indicating that a CG PUSCH appearing during an inactive period is permitted for use) is received by the WTRU, the WTRU can use the first set of CG PUSCH during the active period and the second set of CG PUSCH during the inactive period to transmit PDUs from the PDU set. If no acknowledgment is received, the WTRU uses only the first set of CG PUSCH during the active period to transmit PDUs, and may delay the transmission of any remaining PDUs until the next cell DRX active period. Alternatively, the WTRU may retransmit the indication regarding PUSCH usage, possibly after a certain duration associated with an inactive timer.

[0153] In one scenario, the WTRU can perform actions to utilize PUSCH opportunities that occur during periods of cell DRX inactivity. In another example, the WTRU can determine the number of PUSCH opportunities that are unavailable in one or more CG periods and / or configurations based on the overlap of PUSCH with periods of cell DRX inactivity. The WTRU can compare the unavailable PUSCH with the expected PUSCH that the WTRU can use for UL transmissions of PDUs and / or PDU sets. Based on the comparison, the WTRU can determine whether any configuration conditions and / or thresholds associated with triggering one or more actions are met. For example, if the number of unavailable PUSCH or the difference between the number of unavailable PUSCH and the expected number of PUSCH is greater than a threshold, the WTRU can perform one or more actions to ensure that the QoS of data is satisfied during cell DRX. For example, the threshold can be associated with an exemption for PUSCH opportunities that are permitted to be used by the WTRU during periods of cell DRX inactivity. Other conditions and / or thresholds are further described herein.

[0154] In the example, the WTRU can be configured with one or more thresholds that are associated with the nature and / or attributes of the data unit (e.g., PDU or PDU set) and / or the QoS of the data unit expected to be satisfied during UL transmission. For example, when transmitting PDUs and / or PDU sets with high importance (e.g., above importance and / or priority thresholds), high payload size, or strict QoS (e.g., remaining time less than the threshold remaining time, PSER above the threshold), the WTRU can use and / or assume a high threshold. Alternatively, when transmitting PDUs and / or PDU sets with low importance, low payload size, or flexible QoS (e.g., remaining time above the threshold), the WTRU can use and / or assume a low threshold or a zero threshold (e.g., no exceptions are allowed on PUSCHs occurring during periods of cell DRX inactivity).

[0155] If any conditions and / or thresholds are met that are associated with performing UL transmissions during cell DRX inactive periods and / or the unavailability of sufficient resources or PUSCH timings during cell DRX active periods, the WTRU may perform one or more of the following actions: trigger an indication and / or transmit it to the NW; switch to resource and / or CG configurations consistent with the NES and perform adaptation for CG PUSCH timings; and / or apply a mode for CG PUSCH timings.

[0156] To trigger an indication and / or transmit it to the network, for example, the WTRU may send an indication regarding PUSCH usage and information about the number, location, or pattern of PUSCH opportunities occurring during one or more cell DRX inactive periods that the WTRU intends to use or not use. For example, to trigger an indication and / or transmit it to the network, the WTRU may assume that PUSCH opportunities during a cell DRX inactive period are valid and available, for example, when transmitting an indication regarding PUSCH usage (e.g., N opportunities, slots, symbols prior to the start of a cell DRX inactive period) and / or upon receiving an acknowledgment or exemption indication from the network. Regarding triggering an indication and / or transmitting it to the network, for example, when delaying one or more PDUs or a subset of PDUs in a PDU set to the next cell DRX active period, the WTRU may send an indication to the network along with information about the delayed PDUs (e.g., payload size, remaining time of the PDU, etc.). To trigger an indication and / or transmit it to the network, for example, to transmit one or more PDUs or a subset of PDUs in a PDU set that cannot be delayed to the next cell DRX active period (e.g., due to low residual latency below a threshold), the WTRU may transmit an indication (e.g., SR, BSR, UCI) to request new resources (e.g., DG or new CG resources), or a request to at least temporarily disable cell DRX mode for one or more periods. Regarding triggering the indication and / or transmitting it to the network, for example, when transmitting an indication regarding PUSCH usage, the WTRU may additionally transmit priority values ​​associated with a selected PUSCH during a cell DRX active period and / or a cell DRX inactive period. For example, the priority value may correspond to the priority and / or importance of data expected to be transmitted at the corresponding selected PUSCH timing. Alternatively, the priority value (e.g., a binary value) may correspond to a preference indication of the WTRU associated with the PUSCH timing. The WTRU may receive an acknowledgment indication (indicating a threshold priority value) from the network. In this scenario, WTRU can assume that any PUSCH opportunity with a relative priority value below the threshold priority value will be skipped. For example, any PUSCH opportunity with a corresponding priority value above the threshold priority value can be used for data transmission.

[0157] Regarding switching to NES-consistent resource and / or CG configurations, for example, when NES mode is activated (e.g., cell DRX / DTX mode), the WTRU may switch to an NES-consistent CG configuration, including any of the following: CG PUSCH timing is consistent with the cell DRX active period; CG PUSCH timing before and / or after the cell DRX inactive period may be configured with a different set of parameters (e.g., high MCS index, higher number and / or density of RBs or RBGs, SLIVs with higher symbol lengths, different TCI states) to compensate for the lack of transmissions during the inactive period; and / or sub-configurations of the NES CG configuration (e.g., including a subset of CG PUSCH timings) may be common to a set of WTRUs, and another sub-configuration (e.g., including another subset of PUSCHs) may be WTRU-specific. Different CG sub-configurations may be associated with different priorities, a set of parameters (e.g., FDRA or TDRA), and / or limitations on whether the sub-configuration is applicable during the cell DRX active period, inactive period, or both. For example, the WTRU may switch to an appropriate sub-configuration based on the activated NES mode. For example, the WTRU can start a timer when switching to a CG configuration consistent with NES. As long as the timer is running, the WTRU can use the resources associated with the NES CG configuration and switch back to the default CG configuration or a non-NES consistent CG configuration after the timer expires. To adapt CG PUSCH timing, for example, for one or more PUSCH timings that are skipped due to occurring during a cell DRX inactivity period, the WTRU can assume the addition of additional PUSCH timings before and / or after the inactive period. For example, time shifting can be performed on PUSCHs during inactive periods by applying a pre-configured offset value to the initial slot or symbol offset, causing the PUSCHs to be adjusted (e.g., advanced or delayed) to appear during a cell DRX active period. The time-shifted subset of PUSCHs can be configured with different parameters (e.g., a higher number of RBs or RBGs, a higher MCS). To apply one or more patterns to CG PUSCH timing, for example, the WTRU can apply a pre-configured pattern corresponding to a subset of CG PUSCH timings occurring during a cell DRX inactivity period, and the WTRU is allowed to use these timings for data transmission. WTRU can indicate the selected mode (e.g., index or ID) to the network or autonomously activate the mode based on certain conditions associated with the QoS of the data unit and / or the data unit (e.g., the remaining time of the PDU set, the importance of the PDU set, etc.).

[0158] Among a range of methods relating to one or more UL HARQ retransmissions during active cell DRX mode, the WTRU can determine whether and how to perform transmission and / or retransmission for at least a subset of the PDU set based on the allocated DG resources for one and / or multiple transmissions and the remaining time for satisfying the PSDB requirements of the PDU set. Because the network may not have a complete understanding of the nature of the UL PDU set, such as the remaining time of the PSDB, time to lifetime, and / or other QoS requirements, the resources allocated for transmission or retransmission during the active period of cell DRX for one or more TBs of PDUs containing the PDU set may not be suitable for satisfying the QoS of the PDU set. In this case, the WTRU can perform certain actions during retransmission, as described herein, to ensure that QoS is satisfied while enabling the network to operate in NES mode as much as possible. In one example, if a new PDU (e.g., associated with a DRB or LCH) has not been transmitted within a certain time (e.g., time to lifetime) since the last transmission, the QoS requirement may not be satisfied, and the WTRU can apply similar logic to transmit a retransmission to satisfy the PDB, which is another TB of the same DRB or alternatively, the LCH. Therefore, the methods described in this paper can be applied to new transmissions and / or retransmissions.

[0159] In the examples described herein, the WTRU can receive PDUs associated with one or more PDU sets from higher layers and / or applications. The WTRU can also receive implicit or explicit information (e.g., QFI, PSDB, PSER, PSIHI) about the QoS associated with a DRB or PDU set based on higher-layer markings and / or indications in the PDUs (e.g., PDU headers and / or subheaders, control PDUs) or DRBs. For example, the WTRU can map PDUs of a PDU set to one or more LCHs based on the importance and / or priority of the PDU and / or PDU set, and the priority of the LCH. At the WTRU's MAC sublayer, the PDUs of the PDU set can be multiplexed into one or more TBs based on the LCP procedure.

[0160] In one scenario, the WTRU can multiplex PDUs from a PDU set into multiple TBs and HARQ processes. In the example, for a PDU set comprising N PDUs mapped to M LCHs, a subset of the N PDUs can be multiplexed into a single TB according to the LCP procedure, based on the size of the resource grant associated with the TB and the priority of the LCHs. The remaining subset of PDUs can be multiplexed into one or more other TBs. Since the M LCHs may also contain other PDUs (which may not be associated with the PDU set), one or more TBs may contain combinations of N PDUs from the PDU set and non-PDU sets. In the example, the WTRU can be configured with restrictions such that when multiplexing PDUs into one or more LCHs of one or more TBs, the N PDUs from the PDU set take precedence over other PDUs associated with non-PDU sets. Different TBs comprising different subsets of PDUs from the PDU set can be associated with one or more HARQ processes, where each HARQ process can be associated with a HARQ process ID. At different PUSCH times, one or more TBs can be transmitted by WTRU in the UL, where the PUSCH time can be associated with CG resources (e.g., multi-PUSCH CG configuration) or DG resources (e.g., a single DCI scheduling multiple PUSCHs). For example, if NES and / or cell DRX mode is activated, such transmission of a TB of PDUs containing a set of PDUs can be accomplished using a PUSCH time available during a cell DRX active period, and in some exceptional cases, if the PDB associated with the set of PDUs expires before the PDUs are transmitted and / or retransmitted before the next cell DRX active period, the PDUs can be transmitted during an inactive period.

[0161] For example, based on association and / or constraint information between PDU sets, LCHs, and HARQ processes, a WTRU (e.g., at the MAC sublayer) can understand which PDUs in one or more LCHs are mapped to TBs and HARQ processes. The WTRU can transmit to the network an indication as well as information about which TBs contain PDUs associated with the PDU set. This indication can be transmitted with the TB (e.g., in a UCI or MAC CE multiplexed with one or more PUSCHs) or in a separate indication (e.g., in a UCI in a PUCCH). For example, a set of one or more TBs containing PDUs of a PDU set may include a flag or ID (e.g., the ID or index of the PDU set) indicating that the TB contains interdependent data. In another example, the WTRU may select a subset of HARQ process IDs from a configured set of IDs and indicate the selected IDs in the TB to implicitly indicate to the network that the TB includes interdependent data.

[0162] In one scenario, one or more indications regarding PDUs and / or TBs transmitted in cell DRX active mode can be received from the network. In an example, the WTRU may receive indications from the network when performing a transmission of one or more TBs of PDUs comprising a set of PDUs. For example, such indications may provide feedback information associated with the transmission of one or more TBs. For example, such indications may be received by the WTRU in DCI, DL MAC CE, or RRC signaling. Such indications may be received in a single indication (e.g., in a single DCI) with information associated with multiple TB transmissions or in multiple indications (where each indication may be associated with a TB transmission). Such indications may be received during a cell DTX active period, which may or may not coincide with a cell DRX active period. For example, the WTRU may use the same, different, or additional SS when monitoring a PDCCH containing one or more indications (e.g., a single DCI or multiple DCIs).

[0163] Indications received by the WTRU may include any of the following information: HARQ process ID, NDO information about the associated HARQ process ID, resources for retransmission, timing information for the retransmission resources, conditions associated with the use of resources that occur during periods of cell DRX inactivity, and / or resource granting information for transmitting early or preferred indications. Indications including HARQ process IDs, for example, information about one or more HARQ processes (e.g., IDs) may be provided as a single indication or multiple indications, each of which may be associated with a HARQ process ID. When providing information about multiple HARQ processes associated with multiple TB transmissions, a bitmap format may be used. For example, each bit in the bitmap may be associated with a HARQ process ID and may indicate the ACK and / or NACK status of the associated TB transmission. For example, the bitmap format may be related to a downlink feedback indication (DFI). For indications including NDI information about the associated HARQ process ID, for example, if the NDI flag for the HARQ process ID is toggled or reset, the WTRU may assume that the transmission of the TB associated with the HARQ process ID was successful. WTRU can release data in the cache associated with the HARQ process.

[0164] Indications for resources used for retransmission may include, for example, resources for retransmission that can be associated with one or more HARQ process IDs, where the WTRU can use the resources to retransmit TBs associated with the HARQ process. Such resources for retransmission may be DG, CG, or a combination of DG and CG. In the case of a DG resource, resource information may include any of the following: TDRA (e.g., PUSCH timing or SLIV), FDRA (e.g., the number of RBs or RBGs), and transmission parameters (e.g., MCS or RV, etc.). In the case of a CG resource, information may include activation indications for one or more CG configurations (e.g., the ID or index of the CG configuration) other than TDRA and / or FDRA. A subset of such resources for retransmission may be available during one or more cell DRX active periods, and another subset may be available during one or more cell DRX inactive periods.

[0165] For indications of timing information including resources for retransmission, for example, one or more PUSCH timings may be associated with at least one K2 value, where K2 may indicate the timing, slot, or symbol for performing a TB retransmission. For example, such timing information may indicate a reference timing, slot, or symbol (e.g., the start of an SFN or cell DRX active period or cell DRX inactive period). In the example, the WTRU may receive multiple K2 values ​​associated with PUSCH timings, where a subset of K2 values ​​may correspond to PUSCH timings overlapping during a cell DRX active period (e.g., a first subset of PUSCHs), and another subset of K2 values ​​may correspond to PUSCH timings overlapping during a cell DRX inactive period (e.g., a second subset of PUSCHs). For PUSCHs overlapping during a cell DRX inactive period, the availability of the PUSCH and the associated K2 may be conditional upon satisfaction of certain pre-configured and / or indicated conditions. The CG can be implicitly determined by the WTRU from the signaled K2 value (e.g., if the K2 value overlaps with an inactive period of the cell's DRX). Alternatively, the CG can be explicitly signaled by the network under specific conditions.

[0166] Indications that include conditions associated with the use of resources during cell DRX inactivity periods may include, for example, any conditions described herein, including, for example: the importance and / or priority of the data unit (e.g., whether the multiplexed data has a minimum high priority level and / or if all multiplexed data comes from a minimum priority level), whether the data comes from an associated DRB (e.g., a DRB configured with low latency requirements), the payload size of the data unit, the priority of the LCH, the remaining time relative to the PSDB, whether high-priority SRB data (e.g., RRC messages) has been multiplexed, whether high-priority MAC CEs have been multiplexed, etc. Such conditions may also indicate that resources should only be used during cell DRX inactivity periods if the allocated resources during cell DRX active periods are insufficient or cannot be time-consistent with meeting the QoS of the data unit. Such conditions may be semi-statically pre-configured in the WTRU (e.g., via RRC signaling) and may apply when the WTRU receives certain indications or resources with a K2 value that overlap during cell DRX inactivity periods. Alternatively, such conditions or thresholds for certain conditions can be dynamically received by the WTRU in the instruction.

[0167] For indications including resource grants for transmitting early and / or preference indications, for example, the WTRU may receive one or more resource grants for transmitting early or preference indications for using PUSCH timings that occur during cell DRX inactivity periods to perform TB transmissions. Alternatively, the WTRU may use resource grants to send requests to disable cell DRX mode or disable one or more cell DRX inactivity periods. The WTRU may multiplex indications regarding available grants (e.g., portions of UCI on the PUSCH). Such resources may include any of the following: UL WUS resources (e.g., RACH), PUCCH resources (e.g., SR, UCI with a short K2 value), and / or PUSCH resources (e.g., with a short K2 value). The WTRU may trigger a new SR, possibly based on an SR configuration associated with scheduling grants or CGs during cell DRX, to provide such indications. To provide indications, the WTRU may be configured with separate SR configurations or PUCCH resources. Even during cell DTX inactivity periods, the WTRU may monitor the PDCCH for the possible duration following the SR transmission. Alternatively, the WTRU may use only one CG to indicate that the remaining CGs should not be used (e.g., a portion of the UCI). If any of the above conditions are met, the WTRU may use this resource to transmit early and / or preference indications, in which case the WTRU may send the indication before retransmitting the TB using the PUSCH during a period of cell DRX inactivity.

[0168] Following an early transmission and / or preference indication, the WTRU may start a timer (e.g., a cell DRX deactivation activity timer). While the timer is running, the WTRU may assume that the cell DTX and / or cell DRX are suspended or deactivated. Upon receiving a scheduling or indication from the network (e.g., via DCI) (e.g., possibly for scheduling one or more PDUs associated with low-latency requirements) or upon receiving a PDSCH for a DL DRB associated with a UL DRB associated with low-latency requirements, the WTRU may restart the timer.

[0169] In one example, the WTRU can use a CG to indicate remaining CGs that will not be used (e.g., a portion of the UCI or a MAC CE, such as a BSR). In this case, the WTRU may not provide early and / or preference indications. This may be applicable if a set of CGs is scheduled during an inactive period, and the first grant in that set of CGs can be used to indicate whether other grants will be used. For example, if the WTRU has no further data to transmit, or if the WTRU has no further data to transmit with low latency requirements, the WTRU can build a TB using a padding BSR or a regular BSR.

[0170] In one scenario, the WTRU can use resources during both active and / or inactive periods of the cell's DTX to perform retransmissions. In this example, based on whether the allocated resources (e.g., PUSCH timings) are during an active or inactive period of the cell's DTX, and whether any conditions for using resources during inactive periods are met, the WTRU can determine whether and how to use the network-allocated resources to perform retransmissions of one or more terabytes (TBs). For instance, when resources for retransmissions are allocated (including a first subset of PUSCH timings overlapping during active periods of the cell's DTX and a second subset of PUSCH timings during inactive periods of the cell's DTX), the WTRU can determine whether the first subset of PUSCHs is sufficient to satisfy the QoS of data units during the retransmission period before considering using the second subset of PUSCHs.

[0171] To determine which subsets of PUSCH timings can be used for retransmission, the WTRU can determine the remaining time of the PDU set relative to different points. This remaining time of the PDU set can be determined based on any of the following reference points: T1, which is the time when the Nth PDU in the PDU set arrives at the PDCP and / or LCH buffer, where N can be the first or last PDU; T2, which is the initial transmission time of the first TB containing one or more PDUs associated with the PDU set (e.g., the transmission time can be determined based on the timing of the PUSCH timings (e.g., timing, slot, or symbol) in which the first TB is transmitted); and T3, which is the time when an indication is received from the network indicating information about the NDI flag and / or for a PDU set associated with it. Resources for retransmission of one or more TBs (e.g., such indication may correspond to feedback indications of one or more HARQ processes associated with a TB); and / or T4, which is the time of the Mth retransmission of any TB containing PDUs associated with a PDU set (e.g., the time of the Mth retransmission may be a timing based on the PUSCH timing in which any TB is retransmitted; such timing of the PUSCH timing for retransmission may correspond to a PUSCH timing that occurs during a cell DRX active period (K2_active) or a PUSCH timing that occurs during a cell DRX inactive period (K2_non-active).

[0172] In the first example, upon receiving feedback from the network, the remaining time of the PDU set can be determined as (PSDB – T2) – (T3 – T2) = PSDB – T3. In the second example, when performing retransmissions using PUSCH timings during the cell's DRX active and inactive periods, the remaining time values ​​of the PDU set are PSDB – T4(K2_active) and PSDB – T4(K2_non-active), respectively.

[0173] In one example, if the associated remaining time is greater than a threshold (e.g., PSDB – T3 > threshold or PSDB – T4(K2_active) > threshold), the WTRU can determine when to use the PUSCH during the cell DRX active duration. Otherwise, if the associated remaining time is less than the threshold, the WTRU can choose to use the PUSCH during a cell DRX inactive period. In another example, if the difference between the remaining time values ​​is less than a threshold remaining time value (e.g., PSDB – T4(K2_active) – PSDB – T4(K2_non-active) < threshold), the WTRU can determine when to use the PUSCH during the cell DRX active duration. Otherwise, if the difference between the remaining time values ​​is greater than a threshold remaining time value, the WTRU can choose to use the PUSCH during an inactive period.

[0174] If any condition associated with using resources during a cell DRX inactive period (e.g., remaining time of the PDU set < a threshold) is met, the WTRU may transmit an early and / or preference indication to the network, possibly for requesting the use of resources during a cell DRX inactive period (e.g., PUSCH timing) or for requesting temporary deactivation of the cell DRX mode. This indication may be transmitted using resource authorization allocated by the network. This indication may include, for example, any of the following: indication and / or flags for using resources during the inactive period; information about the selected PUSCH timing during the cell DRX inactive period (e.g., the K2 value of the PUSCH timing); the remaining time of the PDU set; or the duration of time (e.g., one or more periods) for deactivating cell DRX.

[0175] During transmission of an indication, the WTRU may monitor the PDCCH used to receive acknowledgment indications from the network, potentially confirming the use of resources or another set of resources during a cell DRX inactivity period. Alternatively, when transmitting an indication with allocated resource grants, the WTRU may assume that the resources during a cell DRX inactivity period are valid. The WTRU can then use the resources during the cell DRX inactivity period to perform retransmissions of one or more TBs.

[0176] In another example, if any condition is met, the WTRU can trigger a repeat of the TB, possibly using available and / or unused CGs and / or allocated DG resources. For example, such a repeat of the TB (e.g., using a different RV for each repeat) can be performed before the start of a cell DRX inactivity period or after its end. Performing such a repeat might be to improve the probability of correctly decoding the TB in the network and / or reduce the probability of retransmissions.

[0177] If none of the conditions for using resources during a cell DRX inactive period are met, the WTRU can use resources during a subsequent cell DRX active period to perform TB retransmissions. If the cell DRX active period corresponds to a duration that can begin after the current cell DRX inactive period ends, the WTRU can pause one or more retransmission timers associated with C-DRX during the cell DRX inactive period, if configured in the WTRU. The WTRU can then restart the retransmission timers in the next cell DRX active period, for example, when performing a retransmission. In the example, a subsequent cell DRX active period can be the next cell DRX active period, a future cell DRX active period, or any other cell DRX active period that occurs after the current cell DRX inactive period.

[0178] In another example, when resources from a multi-PUSCH CG configuration are used to perform transmissions of one or more TBs of a PDU set, the WTRU may perform one or more of the following actions associated with retransmission during cell DRX mode: monitor the PDCCH for indicating early feedback on a subset of previously transmitted TBs, even during cell DTX inactive periods, possibly when any condition is met (e.g., the remaining delay of the PDU set is below a threshold remaining delay); adjust the start time and / or duration of the CG timer associated with one or more CG PUSCH timings based on cell DTX and / or cell DRX mode (e.g., the duration of the inactive period) to avoid making incorrect assumptions about any transmission failures at the WTRU; perform autonomous retransmission of any unacknowledged TB using one or more DG resources if the timing (e.g., K2) of at least one retransmission of a TB is within the current cell DRX active period; and / or perform autonomous retransmission only after the CG retransmission timer expires and / or the CG timer runs, even if no feedback indication for any TB is received (e.g., in the DCI) even during cell DTX active periods. In this final action, the WTRU can perform autonomous retransmission of the TB using the CG-PUSCH resource only if the cell DRX is active, or if the cell DRX is inactive and any one or more related conditions are met (e.g., the remaining time of the PDU set is less than the threshold remaining time).

[0179] In certain circumstances, when certain conditions associated with the transmission are met, the WTRU determines to transmit data in the UL, or to transmit an indication requesting the network to disable cell DRX mode. This data or indication can be transmitted using conditional CG resources, which can be associated with one or more pre-configured conditions. This approach allows the WTRU to achieve low latency or minimal latency when transmitting data or indications to implicitly or explicitly disable cell DRX mode.

[0180] In one scenario, the WTRU can be configured with a forwarding configuration for use during cell DRX mode. In the examples described herein, the WTRU can be configured with one or more forwarding configurations that it can use to transmit PDU sets within the UL. In some cases, any different DRB, PDCP entity, leg, RLC entity, and LCH can be associated with different forwarding configurations, as described herein.

[0181] In one example, the SDAP sublayer and / or entity of the WTRU can be configured to map different sets of PDUs received from higher layers to different DRBs based on the QoS attributes of the PDU set (e.g., QFI) and pre-configured mapping rules at the SDAP. The PDCP sublayer and / or entity associated with the DRB can map all or different subsets of the PDUs in the PDU set to one or more RLC entities or LCHs. This mapping to single or multiple RLCs and / or LCHs may apply when the WTRU is configured with a regular DRB (e.g., non-split bearer) or when it is configured with a split bearer for DC or CA operation. For example, in this case, different LCHs carrying PDUs mapped from single or multiple DRBs can be associated with common or different MAC entities or cells, depending on whether the WTRU is configured for CA or DC.

[0182] When multiple branches and / or LCHs are configured (whether in a non-split bearer scenario or a split bearer scenario), the WTRU may forward a first subset of the PDUs in the PDU set to the first and / or primary branch corresponding to the first LCH, and forward a second subset of the PDUs in the PDU set to the secondary branch corresponding to the second LCH. Decisions regarding forwarding and / or mapping PDUs in the PDU set to one or more branches (e.g., RLC entities or LCHs) or using any configuration and / or resources associated with different branches may be based on one or more factors, such as, but not limited to, the QoS of the PDUs, the loading conditions of one or more primary branches and / or secondary branches, the radio link conditions associated with one or more primary branches and / or secondary branches, the configuration and resources associated with one or more primary branches and / or secondary branches, and the cell DRX mode associated with one or more primary branches and / or secondary branches.

[0183] For PDU QoS, the WTRU can forward all PDUs in a PDU set to a single branch and / or LCH based on the QoS properties of the PDU set (e.g., importance or priority and / or PSDB) and the LCH configuration. For example, PDUs in a PDU set with high importance can be forwarded to an LCH configured with a high priority value. Alternatively, if different subsets of PDUs in a PDU set have different QoS properties (e.g., different priority and / or importance values), the WTRU can forward subsets of PDUs to different branches and / or LCHs based on the associated priority values ​​of the branches and / or LCHs.

[0184] For loading conditions of one or more main branches and / or sub-branches, for example, a WTRU (e.g., a PDCP entity) may forward a first subset of PDUs from the PDU set to the main branch until a threshold is reached. Any remaining PDUs (including a second subset of PDUs) may be forwarded to the sub-branch. Alternatively, if the cache in the main branch contains some PDUs that have reached a first threshold, the WTRU may forward a first subset of PDUs from the PDU set to the main branch until a second threshold is reached. Any remaining PDUs (e.g., a second subset of PDUs) are then forwarded to the sub-branch.

[0185] For radio link conditions associated with one or more main branches and / or secondary branches, for example, the WTRU can perform measurements (e.g., RSRP measurements of CSI-RS or SSB) on links or channels associated with different branches. The WTRU can then determine, based on these measurements, whether and how to forward a subset of PDUs from the PDU set to one or more branches. In the example, if the RSRP measurement of the main branch is less than a threshold and / or the RSRP measurement of the secondary branch is greater than a threshold, the WTRU can forward the PDUs to the secondary branch. Otherwise, the WTRU can forward the PDUs to the main branch.

[0186] For configurations and resources associated with one or more primary branches and / or secondary branches, different branches and / or LCHs can be configured with different groups of configurations or resources. For example, the association between configurations and / or resources and branches and / or LCHs can be supported based on LCP constraints. Alternatively, any single branch and / or LCH can be associated with a first group and a second group of configurations and / or resources. For example, the use of a first group of configurations and / or resources for an LCH can depend on the satisfaction of one or more pre-configured conditions. Similarly, a second group of configurations and / or resources can be used when another group of conditions is satisfied. Such conditions can include any conditions related to the importance of the PDU set, the remaining time of the PDU set, and other items listed herein. Different groups of configurations and / or resources can include different BWPs and different CG configurations. For example, when multiple LCHs are configured or a single LCH has multiple groups of conditional configurations and / or resources, such LCHs can be associated with a first CG configuration and a second CG configuration, respectively. For example, the first CG configuration and the second CG configuration may include a first set of parameters and a second set of parameters (e.g., in the CG configuration, there are N1 and N2 PUSCH opportunities per CG period, where N1 and N2 can be greater than or equal to 1). For example, the second CG configuration may correspond to a conditional CG configuration, whose resources are only available when one or more configuration conditions are met. In the example, an LCH may be configured with resources associated with the first CG configuration and the second CG configuration, where the first CG configuration can only be used during cell DRX active periods, and the second CG configuration may be conditional and can be used during cell DRX inactive periods after certain conditions are met. For example, the first CG configuration and / or the second CG configuration may be restricted and / or associated with a single LCH or may be shared across a set of LCHs.

[0187] In another example, when the LCH is configured with resources associated with a conditional CG configuration, different subsets of resources (e.g., PUSCH timings) can be used during cell DRX inactivity periods when one or more conditions are met. For example, when the remaining delay of the PDU set is less than a first threshold (threshold 1) and higher than a second threshold (threshold 2), the WTRU can use a first set of PUSCH timings in a conditional multi-PUSCH CG configuration, where the first set of PUSCH timings can fall within a time window between the first and second thresholds (i.e., between threshold 1 and threshold 2). Similarly, for example, when the remaining delay of the PDU set is less than the second threshold (threshold 2), the WTRU can use a second set of PUSCH timings in a conditional multi-PUSCH CG configuration, where the second set of PUSCH timings can fall within a time window that is smaller than the second threshold (threshold 2).

[0188] In another example, the WTRU can switch to an alternative BWP when conditions associated with the use of a conditional resource are met for performing a transmission during a period of inactive cell DRX. For example, this alternative BWP may be associated with a conditional CG resource and / or may be different from the BWP used when the conditions for the handover are met.

[0189] For cell DRX modes associated with one or more main branches and / or secondary branches, different branches and / or LCHs can be associated with different cell DRX modes. For example, a main branch can be associated with a cell DRX active mode, while a secondary branch can be associated with a cell DRX deactivated mode. Alternatively, any branch and / or LCH can be associated with different cell DRX modes, including both active and deactivated modes. For example, an LCH can be semi-statically configured or dynamically activated and / or deactivated to operate in either cell DRX active or cell DRX deactivated modes. When an LCH is associated with a cell DRX active mode, any associated configurations, parameters, and / or resources (including restrictions on whether LCH-cached data can be transmitted during cell DRX active and / or cell DRX inactive periods) may apply. Different cell DRX modes associated with one or more branches and / or LCHs can depend on one or more pre-configured conditions. These conditions may include any of those listed herein.

[0190] In the example, if, upon receiving an indication to activate NES mode (e.g., cell DRX mode), there may still be one or more PDUs pending in one or more LCHs, the WTRU may continue to use existing configurations, limits, or resources (e.g., LCP procedures, LCP limits, or default CG configuration, etc.) until a certain configuration validity period is reached, which may be used to clear or refresh data in the LCH cache. This validity period may apply, for example, when conditions associated with data or LCHs are met. When performing transmissions using existing configurations and / or resources, the WTRU may use new configurations and / or resources associated with the NES mode. In the example, if, upon receiving an indication to activate NES mode (e.g., cell DRX mode) and there are still one or more PDUs pending in one or more LCHs, the WTRU may dynamically change the priority value associated with the LCH (e.g., L2 priority) and / or any associated timers (e.g., inactivity timers or retransmission timers, etc.). Such changes may allow any pending PDUs in the LCH to be prioritized and transmitted during the current cell DRX active period or during an upcoming cell DRX inactive period. In the example, if an indication to activate NES mode (e.g., cell DRX mode) is received and the WTRU is aware of data about to arrive in the LCH (e.g., a subset of PDUs from the expected PDU set), then an SR or preemptive BSR can be triggered to provide information about the payload and / or timing information of the data about to arrive. For example, if the network allocates DG resources, such an SR / BSR can allow the WTRU to purge data before activating NES mode. In the example, if, upon receiving an indication to activate NES mode (e.g., cell DRX mode), the WTRU determines that the QoS of a data element (e.g., a set of PDUs) cannot be satisfied, perhaps because no transmissions can be performed during a period of cell DRX inactivity, the WTRU can discard the associated pending PDUs in the LCH. When discarding a PDU, the WTRU can indicate this discard to PDCP / RLC entities (e.g., transmitting and / or receiving entities), the network, and / or higher layers.

[0191] Figure 3A is a diagram illustrating one or more data units (i.e., one or more PDUs) and one or more CG resources according to an embodiment. Figure 3BThis diagram illustrates the transmission of one or more data units using one or more CG resources illustrated in FIG3A according to an embodiment. A WTRU (not shown in FIG3) in the communication network 300 can receive a cell DRX activation indication 302 associated with at least one cell and / or at least one gNB associated with that cell. The WTRU can also receive a cell DRX deactivation indication 318. The cell DRX activation indication 302 and the cell DRX deactivation indication 318 can respectively indicate the activation and deactivation of the cell DRX mode of the cell. The WTRU can be configured with a multi-PUSCH configuration indicating one or more default CGs (including a first default CG 304 and a second default CG 306) and one or more conditional CGs (including a first conditional CG 308 and a second conditional CG 310). The WTRU can receive multiple PDUs and / or one or more sets of PDUs, including first to third PDUs 312-316, from one or more higher layers and / or one or more applications implemented by the WTRU. The first default CG 304 and the second default CG 306, as well as the first condition CG 308 and the second condition CG 310, can indicate one or more PUSCH timings on which the WTRU can transmit one or more PDUs from a plurality of PDUs. The WTRU can also be configured with one or more logical channels, including a first logical channel LCH1 and a second logical channel LCH2. The first logical channel LCH1 and the second logical channel LCH2 can be associated with one or more default CGs and / or one or more condition CGs. For example, the first logical channel LCH1 can be associated with the first default CG 304 and / or the first condition CG 308, while the second logical channel LCH2 can be associated with the second default CG 306 and / or the second condition CG 310. The WTRU can map the first to third PDUs 312-316 to the first logical channel LCH1 and / or the second logical channel LCH2 based on one or more PDU attributes associated with the first to third PDUs 312-316. The WTRU can determine whether to use the first default CG 304 and the second default CG 306 and / or the first condition CG 308 and the second condition CG 310 based on the mapping of logical channels and / or based on whether the first to third PDUs 312-316 satisfy one or more QoS conditions. In one example, the WTRU can determine that the first PDU 312 is mapped to the first logical channel LCH1 associated with the first default CG 304, while the second PDU 314 and the third PDU 316 are mapped to the second logical channel LCH2. In another example, the WTRU can determine that the second PDU 314 does not satisfy any of the one or more QoS conditions, while the third PDU 316 satisfies at least one of the one or more QoS conditions.Therefore, WTRU can determine that the second PDU 314 is transmitted using the second default CG 306, while the third PDU 316 is transmitted using the second condition CG 310.

[0192] The WTRU can identify the cell DRX period 320 based on the cell DRX activation indication 302. The cell DRX period 320 can include a cell DRX active period 322 and a cell DRX inactive period 324. During the cell DRX active period 322, the WTRU can transmit a second PDU 314 using a second default CG 306 associated with the second logical channel LCH2. During the cell DRX inactive period 324, the WTRU can transmit a third PDU 316 using a second condition CG 310 associated with the second logical channel LCH2.

[0193] In one scenario, the WTRU can determine whether to use conditional CG resources to transmit data and / or indications during cell DRX mode. In an example, the WTRU may be configured with a set of LCHs, where at least a subset of the LCHs may be associated with a first CG configuration and / or a default CG configuration, and a second and / or conditional CG configuration. For instance, such a conditional CG configuration may be associated with resources used to implicitly disable cell DRX mode. In this case, when conditional CG resources are used to transmit any transmissions, the WTRU may implicitly request the network to disable cell DRX mode.

[0194] The WTRU can also be configured with a set of conditions and / or thresholds that are associated with data transmission when using conditional CG resources to activate cell DRX modes (e.g., during periods of cell DRX inactivity). Such conditions or thresholds may include any of those listed herein, such as the remaining time of the PDU set being less than a first threshold indicating the remaining time of the threshold (i.e., remaining time < threshold 1) and / or the importance and / or priority value of the PDU set being greater than a second threshold indicating the priority value of the threshold (i.e., priority value > threshold 2).

[0195] When a PDU associated with a PDU set is received from a higher layer and / or application, the WTRU can also receive implicit or explicit information associated with the PDU set properties and / or QoS (e.g., PSIHI or PSDB) based on higher-layer markings and / or indications in the PDU (e.g., PDU headers and / or subheaders, or control PDUs, etc.). The WTRU can forward and / or map PDUs in the PDU set to one or more LCHs based on certain conditions and / or thresholds associated with the PDU set properties and the configured LCH.

[0196] When mapping PDUs from a PDU set to their associated LCHs, the WTRU can determine whether any conditions associated with the resources configured using the Conditional Cell CG (Cellular Cell Grid Configuration) are met for PDU transmission during cell DRX inactive periods. If no conditions are met, the WTRU can use the resources in the default CG configuration to transmit PDUs, depending on the active cell DRX mode. In this case, for example, the WTRU can only transmit PDUs during cell DRX active periods (e.g., subsequent cell DRX active periods, future cell DRX active periods, and / or any other cell DRX active period that occurs after a cell DRX inactive period). In the example, the WTRU can cache and / or store PDUs until the start of a subsequent cell DRX active period. In the example, the WTRU can store and / or cache PDUs in the output queue until the start of a subsequent cell DRX active period.

[0197] If any condition is met, the WTRU can select one or more resources configured in the condition CG to transmit at least a subset of indications (e.g., requests to disable cell DRX mode) and / or PDUs in the relevant LCH. In this case, using any resource in the condition CG allows the WTRU to implicitly or explicitly request the network to allow data transmission and / or disable cell DRX mode during periods of cell DRX inactivity.

[0198] In the example, the WTRU can be configured with a first multi-PUSCH CG configuration and a second multi-PUSCH CG configuration, where the first CG configuration is unconditional and can be used during cell DRX active periods, while the second CG configuration is conditional and can be used during cell DRX inactive periods. If any conditions for using the second CG configuration are met (e.g., expected data transmission is performed during cell DRX inactive periods), then for a PDU set comprising multiple PDUs, the WTRU can use a subset of the PUSCH timings associated with the second CG configuration to transmit one or more PDUs. The remaining PDUs in the PDU set can be transmitted using a subset of the PUSCH timings in the first CG configuration. The WTRU can also transmit indications about the number and / or location of CG PUSCH timings expected to be used and / or not used in the first and second CG configurations, possibly indicating the use of resources in the second CG configuration (e.g., a conditional CG).

[0199] In the example, the WTRU can use resources in the conditional CG configuration to transmit indications or subsets of data and / or PDUs. The WTRU can monitor the conditional SS or the PDCCH in the core set for receiving indications from the network. Indications can correspond to acknowledgment indications (e.g., in the DCI), feedback information associated with PDU transmissions (e.g., NDI flag status, additional DG resources for retransmission), or additional and / or new resources for data transmission (e.g., activation of DG resources or a new CG configuration). The conditional SS can be associated with the conditional CG configuration, the LCH, or with the reception of any indications, signaling, or data during cell DTX inactive periods and / or cell DRX inactive periods. For example, the conditional SS can be the same as or different from the SS used to receive any signaling or data during cell DTX active periods and / or cell DRX active periods or when cell DTX mode and / or cell DRX mode are not activated.

[0200] In some cases, when the DRX inactivity period is long enough, contentious transmissions, retransmissions, and control information for transmission may occur during the active period. In one scenario, the network may prioritize network energy conservation over WTRU throughput or QoS achievement across all bearers. In this case, the WTRU may need to prioritize contentious data and / or control information during pending transmissions. Data may include data from different priorities, PDU sets, or importance. Control information may include MAC CEs, SRB data, or UCIs of various priorities (e.g., HARQ ACKs, CQI, or CSI reports). In some cases, if data is not transmitted before a certain latency budget (such as, but not limited to, the PSDB associated with the PDU set), the entire PDU set may fail, becoming unusable, especially in cases of interdependent PDUs and / or interdependent PDU sets.

[0201] In one scenario, time-based TB prioritization can be used during the cell's DRX active period. When pending transmissions immediately after the cell's DRX inactive period ends, the WTRU can prioritize contentious data (e.g., data or PDU sets with different priorities) over control information.

[0202] When cell DRX mode is activated, the WTRU can prioritize pending data (e.g., data whose priority is reduced due to cell DRX) and control information ready to be transmitted (e.g., based on buffer time) by prioritizing them before other new and / or high-priority data in the LCH. In one example, if arriving data has a priority of 4 and a high buffer delay (e.g., determined based on arrival time), then the data's priority is increased to 2 based on the buffer delay and the correlation between buffer delay and priority change. If new data arrives after the first set of data and the priority of earlier data is updated based on buffer delay, then it is possible that the amount of high-priority data could be high after a long period of cell DRX inactivity. To control priority changes, updates are relative and scaled based on the initial priority.

[0203] WTRU can change TB priority only for data arriving within a time window before the start of a cell DRX inactivity period and / or for data cached within a threshold time period after the start of cell DRX mode. WTRU can choose not to prioritize data arriving after the threshold time period following the start of cell DRX. Windowing allows control over only a subset of data to be prioritized, rather than all data. Within the window, cache time can still be used to determine priority updates.

[0204] In one approach, the WTRU may receive configuration information, including but not limited to: LCH configuration, LCH or DRB priority (e.g., LCP priority), cell DRX configuration (e.g., start offset, or duration of active and / or inactive periods), correlation information between PDU cache time and priority offset (e.g., delta priority), and / or cache window configuration (e.g., start offset or window duration relative to the start of an inactive period of the cell DRX).

[0205] The WTRU can receive PDU sets from higher layers and map PDUs to one or more LCHs based on their initial priorities. The WTRU can receive activation indications for cell DRX configurations (e.g., DCI indications or cell DRX activation indications). The WTRU can cache PDUs in the LCH during cell DRX inactivity periods. The WTRU can determine the cache time for PDUs in the LCH based on the PDU arrival time within the cache window and the duration of the cell DRX inactivity period. For example, the WTRU can calculate the cache time as the time difference between the next cell DRX active period in which PDUs can be transmitted and the PDU arrival time at the WTRU cache. The WTRU can determine the new priority of the PDUs based on the initial priority (e.g., the priority of the highest-priority LCH or PDU set among the PDUs), the cache time, and associated information (e.g., priority offset).

[0206] The WTRU can prioritize a set of PDUs in the LCH within a buffer window over other PDUs arriving outside the buffer window based on a new priority of the PDUs. The WTRU can: prioritize lower-priority PDUs buffered during inactive periods of cell DRX over higher-priority PDUs arriving after cell DRX or within the buffer window; prioritize PDUs (if a PDU is not transmitted, it may exceed the delay budget, resulting in the associated PDU set failing to meet the corresponding QoS requirements) over other PDUs; prioritize the transmission of new data over retransmissions if the new data includes high-priority control information (e.g., UCI, CQI, SRB data, or high-priority MAC CE) and / or if the PDU buffer time is greater than a configured threshold (for example, threshold buffer time); prioritize the transmission of a UCI (e.g., transmitted in PUCCH or PUSCH) over new data if the associated delay budget is about to expire and / or if neither can be transmitted during an active period; and / or prioritize the retransmission of PDUs pending processing in the buffer window over new data, such as, but not limited to, if the CG retransmission timer is configured and / or has expired. If a delay budget (e.g., associated with a PDU set or QoS requirements) is about to expire, or if the PDU is part of a PDU set whose delay budget is about to expire, WTRU can prioritize the retransmission of pending PDUs over new data.

[0207] Once the prioritized PDUs are identified during an active period, the WTRU can transmit the PDUs during the next and / or applicable cell DRX active period. Based on the above rules, the WTRU can determine when to transmit PDUs during a future cell DRX active period, which may not be the next available period (e.g., the WTRU can determine to transmit PDU x after 3 cell DRX cycles).

[0208] The WTRU can only run the CG retransmission timer and / or the autonomous CG retransmission timer during cell DRX active periods. The WTRU can pause the timers during inactive periods. If a cell DRX activation command is received, the WTRU can start and / or restart such timers. If a cell DRX deactivation command is received, the WTRU can stop such timers.

[0209] For example, a PDU set may contain N PDUs, which are transmitted over N TBs and N NARQ processes (HPs) and N PUSCHs (e.g., consecutive PUSCHs with potential gaps between them). The transmission of the first TB (t1) marks the start of the remaining time for the PSDB, and the successful reception of the N TBs (t2 = max(t_i)) marks the total transmission time (T). If each TB has a transmission time t_i, i…N, then t2 = max(t_i) is the longest time taken to successfully receive any of the N TBs, including ReTx times. If T(t2-t1)<= PSDB, then the PSDB is satisfied. The PSDB cannot be satisfied as long as any of the N TBs is not ACKed (e.g., at least one of the N TBs is NACKed). In one case, the WTRU can track the remaining time of any TB that is not ACKed by starting a timer after the transmission of the first TB in the series. If the remaining time for K unacknowledged TBs exceeds a threshold remaining time and / or if the percentage of remaining NACKs exceeds a threshold, the WTRU can perform an action. This action could include sending an indication (e.g., in the UCI) when the threshold is exceeded and / or when the timer expires and no ACK is received. The base station can then provide resources (e.g., MCS or RB) in the DCI to allow the TB to be ACKed. The WTRU can determine certain information (e.g., remaining time, number of NACKs) and indicate this in the indication sent to the base station to allow a higher probability of ACK.

[0210] This action may include determining transmission (Tx) parameters (e.g., MCS, RV for repetition) and using these Tx parameters in conjunction with CG, while also combining them with DG resources provided by the base station. However, if the base station does not know the start of the transmission time of the PDU set (e.g., the first TB transmission) or the remaining time of the PDU set, the provided DG resources may not be suitable for retransmission (ReTx).

[0211] In one scenario, there may be an anomalous DRB, SRB, or LCH that can be transmitted during a cell DRX inactive period. The WTRU can be configured with a dedicated DRB or SRB on which data can be mapped and / or remapped and transmitted during a cell DRX inactive period and / or during a cell DRX active period, data transmission can have absolute priority over other data. The WTRU can support NES-aware DRBs and / or SRBs, enabling the association of high-priority UL information that should and is ready to be transmitted with a specific SRB and / or DRB, and any UL authorization provided to the WTRU when the cell transitions to a cell DRX inactive period can be used to transmit data from the DRB and / or SRB with the highest LCP priority. For example, the WTRU can be used to first "extract" anything recorded on this SRB (e.g., then the DRBs in priority order). The WTRU can be configured with a flag indicating whether the LCH can claim an authorization scheduled during a cell DRX inactive period in the LCP. DCI can indicate that authorized scheduling during cell DRX inactive periods can only be applied to data from DRBs and / or LCHs with this flag. In one case, rule-based TB prioritization may exist during cell DRX active periods. For example, one or more methods may exist for prioritizing among contentious transmissions.

[0212] In some approaches, during a cell DRX active period, the WTRU may attempt to transmit a TB on a CG resource. The WTRU may receive a scheduling DCI indicating that a DG transmission is expected to occur concurrently with the CG resource, such as overlapping in the time domain. In another example, the WTRU may transmit a first TB on a first CG resource. While the CGRT is still running, the WTRU may attempt to transmit a second TB on a second CG resource and / or at a time within the same CG resource. During a cell DRX active period, the WTRU may need to retransmit both TBs in a subsequent CG resource and / or at a subsequent time. The next CG resource can be used for either TB. In both cases, the WTRU may multiplex the transmissions into a single CG resource if possible. The WTRU may include indications that multiplexing of two CG TBs has occurred in the CG resource, possibly because the subPDUs have the same size, and / or the TB at the CG time can accommodate them. For example, the WTRU may include a sub-header in the combined PDU to indicate the location where the first TB and / or the multiplexed subPDU ends and the next TB begins, and / or the number of multiplexed TBs and / or previously generated subPDUs. The sub-header may include the TBS for each subPDU. In one case, during an active period, such as when neither of the two TBs can be transmitted during the current cell DRX active period, the WTRU may transmit a single TB in the CG resource. The selection of the TB to be transmitted may depend on prioritization rules. Always transmitting the TB with the highest priority (e.g., as determined by the LCH) may be unfair, as lower-priority TBs may suffer undue delays.

[0213] To determine which TBs should be transmitted at a given PUSCH timing during a cell DRX active period, the WTRU can prioritize the TBs to be processed. Prioritization rules can depend on one or more factors, such as, but not limited to: buffer time; whether the TB is part of a PDU set and / or a TB set, whose PDF is not satisfied if the TB is not transmitted during the next cell DRX active period; whether the lifetime is not satisfied if the TB is not transmitted during the next cell DRX active period; priority index; DCI indicator priority; LCH priority; whether the transmission is a first transmission or a retransmission; the RV of the transmission; the reason for the retransmission; the number of times the TB has not been transmitted; the CG timer value; the content of the TB; and / or whether the TB is part of a duplicate bundle. The buffer time factor can be explained as described herein (e.g., the time elapsed between data arriving at the buffer and a possible PUSCH transmission timing). One factor could be whether the TB is part of a set, whose PSDB is not satisfied if the TB is not transmitted during the next cell DRX active period. Another factor could be whether the lifetime is not satisfied if the TB is not transmitted during the next cell DRX active period. Regarding the priority index factor, for example, the WTRU can maintain a priority index for each TB. The initial value of the priority index can be determined based on the data to be transmitted (e.g., its priority). The initial value of the priority index can be applied to a new HARQ process. The priority index can then be incremented and / or decremented based on whether the TB was transmitted at the time it was initially intended to be transmitted. For example, a TB might have a priority index x, and if the TB fails to be transmitted at its intended time (e.g., in CG resource 1) (because it competed with a higher-priority TB during a cell DRX active period), the WTRU can increment the priority index to x+1 during the next cell DRX active period. The priority index of the TB can be decremented when the transmission and / or retransmission is successful. For example, if the initial priority index is x and the WTRU successfully transmits the TB, the WTRU can decrement the priority index to x-1 (e.g., for use in cases where a retransmission is required). It is understood that the opposite approach can be used (e.g., the priority index decrements on transmission failures and increments on transmission successes).

[0214] Regarding the DCI indication priority factor, for example, the WTRU can select the TB to be transmitted based on the highest or lowest DCI indication priority. The DCI can indicate an applicable priority, HARQ PID, DRB, or PDU set, from which data is prioritized for transmission during the next cell DRX active period. Regarding the LCH priority factor, for example, the WTRU can select the TB to be transmitted based on the priority of at least one LCH multiplexed into the TB. The WTRU can prioritize the TB to be processed and / or the transmission, and order them according to the order in which they are multiplexed by their highest priority LCH, or it can perform multiplexing. Regarding whether the transmission is a first transmission or a retransmission factor, for example, the WTRU can prioritize the TB based on whether the TB has been transmitted previously, or whether the TB has not been transmitted previously (e.g., due to loss or UL LBT failure), or whether this is the first attempt to transmit the TB. One factor could be the RV of the transmission. Regarding the factor of transmission cause, prioritization can depend on whether it is the first attempt to transmit, a retransmission due to a NACK (e.g., a NACK received on the DFI), a retransmission due to loss (e.g., due to a collision within the WTRU), a retransmission due to loss (e.g., due to a collision between WTRUs), and / or a retransmission due to an expired CGRT, etc. Regarding the factor of the number of times a TB has not been transmitted, for example, when cell DRX is activated, the WTRU can maintain a counter for the number of times a TB has been lost due to competition with higher-priority TB transmissions. The WTRU can use the counter to determine the priority associated with a TB. The counter can be reset when a TB has been transmitted and / or retransmitted at least once. In another case, the counter can be reset when the HARQ process is cleared. Regarding the factor of CG timer value, for example, the priority of a TB can be determined based on the remaining time left in the CG timer associated with the TB. This ensures that the TB is transmitted and / or retransmitted before the CG timer expires. Regarding the content of the TB, for example, prioritization may depend on whether the TB includes a MAC CE and / or the type of MAC CE (e.g., CG acknowledgment MAC CE, BFR MAC CE, UL LBT fault MAC CE, C-RNTI MAC CE, PHR and / or BSR MAC CE, etc.). The WTRU may be configured with priorities according to MAC CEs or subsets of MAC CEs, which the WTRU can use to compare and prioritize overlapping transmissions. Regarding whether the TB is part of a duplicate bundle, for example, priority may be determined based on whether the TB is part of a duplicate bundle, the number of times it is repeated in the bundle, or the number of times it is successfully transmitted and / or unsuccessfully transmitted in the bundle.

[0215] WTRU can use a combination of one or more factors to determine the prioritization of multiple TBs, thereby determining which TBs to transmit and / or lose. The combination can weight different factors in different ways. The weighting of factors can be configurable or determined based on PUSCH resources or the timing of transmissions relative to a cell DRX active period. Some prioritization factors presented in this paper may never be overridden by other factors. For example, WTRU can maintain a priority index that can increment or decrement based on whether a TB has been previously transmitted. However, if a second TB with a specific LCH and / or MAC CE needs to be transmitted, the priority index value of the first TB may be meaningless. The second TB can have a higher priority than the first TB regardless of the priority index value of the first TB. In one example, UL QoS may exist during NES with multiple PUSCH CGs. When multiple PUSCH CGs are configured, a subset of PUSCHs may become invalid if PUSCHs overlap with a cell DRX inactive period. This can lead to over-buffering and QoS failures, especially when transmitting PDU sets. To address this issue, the WTRU can determine the number of unavailable PUSCHs based on the required number of PUSCHs that the WTRU wants to use but which overlap with cell DRX inactive periods. If the number of unavailable PUSCHs exceeds a threshold, the WTRU can trigger an indication and / or assume that the network provides exceptions for partially overlapping PUSCHs during cell DRX inactive periods to allow data to be cleared from the cache and QoS to be satisfied. To achieve this, the WTRU can perform one or more actions. The WTRU can receive configuration information, including but not limited to multi-PUSCH CG configuration (e.g., the timing of N PUSCHs per CG cycle, periodicity) and / or cell DRX configuration (e.g., start offset, duration of active and / or inactive periods, periodicity) and cell DRX activation indication (i.e., cell DRX activation indication). The WTRU can receive one or more PDUs, such as a PDU set, from higher layers and / or applications and map the PDUs to LCHs. The WTRU can determine the first set of CG PUSCHs that appear during cell DRX active periods based on the payload size of the PDUs in the PDU set in the LCH cache. For example, WTRU can prioritize PUSCH for transmitting data and UTO-UCI indications during periods of active DRX in the cell.

[0216] If any conditions for using CG PUSCHs that occur during a cell DRX inactive period are met (e.g., such conditions may include, but are not limited to, one or more of the following: the payload size of the remaining PDUs in the PDU set is greater than a threshold and / or the remaining PDUs in the PDU set cannot be delayed to the next cell DRX active period due to low TTL and / or PSDB), the WTRU can determine the second set of CG PUSCHs that occur during a cell DRX inactive period based on the payload size of the remaining PDUs in the PDU set in the LCH buffer. The WTRU can transmit an indication (e.g., in a UCI) that indicates information about the PUSCHs required in the first set of CG PUSCHs (which occur during a cell DRX active period) and the second set of CG PUSCHs (which occur during a cell DRX inactive period) (e.g., the WTRU can monitor N slots and / or symbols of the PDCCH after transmitting the indication). If an acknowledgment is received indicating the use of a second set of CG PUSCH (e.g., in DCI), the WTRU can use the first set of CG PUSCH and the second set of CGPUSCH to transmit PDU sets, including indicated PUSCH timings that occur during periods of cell DRX inactivity.

[0217] If none of the conditions for using CG PUSCHs that occur during a cell DRX inactive period are met, the WTRU may transmit an indication (e.g., UTO-UCI) indicating the first set of CG PUSCHs (e.g., the number of consecutive PUSCHs) that occurs during a cell DRX active period, and / or the WTRU may use the first set of CG PUSCHs to transmit PDUs of the PDU set. In one example, UL HARQ transmissions and / or retransmissions may occur during NES. The network may not have a complete understanding of the nature of the UL PDU set (e.g., the number of associated PDUs, the remaining time with respect to the PSDB). During multiple TB of HARQ retransmissions associated with the PDU set, the allocated bundles of DG PUSCH resources for ReTx (which may be consistent with the cell DRX pattern) may not be suitable for satisfying the QoS of the PDU set. To address this issue, the WTRU may determine the remaining time of the PDU set based on the timing of the allocated DG resources for ReTx (e.g., which is consistent with the next cell DRX active period) and the PSDB. If the remaining time resulting from delaying ReTx to the next active period of cell DRX is low (e.g., less than a threshold), the WTRU may send an indication to request the use of resources that occurred during the inactive period of cell DRX or to temporarily disable cell DRX for retransmission.

[0218] To achieve this goal, the WTRU can perform one or more actions or functions. The WTRU can receive configuration information, including cell DRX configuration (e.g., start offset, duration of active and / or inactive periods) and activation indications of the cell DRX configuration and / or thresholds associated with expected changes in the remaining time of the PDU set. The WTRU can receive, for example, one or more PDUs of the PDU set and information about the PSDB from higher layers. The WTRU can perform initial PDU transmissions in one or more TBs during the cell DRX active period (e.g., the WTRU (MAC) can determine which PDUs of the PDU set in the LCH will be mapped to one or more TBs and HARQ processes based on certain associations and / or constraints between the PDU set and the HARQ process ID). The WTRU can receive indications from the network (e.g., in the DCI), including DG PUSCH retransmissions for TB and timing information of the DG PUSCH, as well as one or more DG PUSCHs associated with multiple K2 values ​​(e.g., regular K2 consistent with the next cell DRX active period and conditional K2 consistent with the cell DRX inactive period), and / or resource grants (e.g., SR or PUCCH resources with short K2), such as indicating to the WTRU a preference for using DG PUSCHs with conditional K2. The WTRU can determine the remaining time of the PDU set based on the timing of the DG PUSCH for ReTx (e.g., regular K2 consistent with the next cell DRX active period) and PSDB (e.g., remaining time of the PDU set = PSDB - K2 of the DG PUSCH in the next cell DRX active period).

[0219] If a cell DRX inactive period is activated and the remaining time of the PDU set is less than the threshold remaining time, the WTRU can use resource grants to transmit an indication (e.g., in UCI) to request the use of a DG PUSCH with condition K2 (overlapping during the cell DRX inactive period), and / or to perform a TB retransmission using the requested DG PUSCH. If a cell DRX inactive period is activated and the remaining time of the PDU set is greater than or equal to the threshold remaining time, the WTRU can use a DG PUSCH with regular K2 (overlapping with the next cell DRX active period) to perform a TB retransmission (e.g., if ReTx is performed during the next cell DRX active period, the WTRU can pause the ReTx timer). In one example, conditional CG resources might be activated during NES. A method is needed regarding how to indicate to a network with low latency a request to temporarily disable cell DRX mode while transmitting data with strict QoS. To address this issue, the WTRU can implicitly disable cell DRX when using conditional CG resources (e.g., resources restricted to transmitting emergency PDUs) to transmit one or more emergency PDUs from a PDU set, provided that one or more QoS conditions are met.

[0220] To achieve this goal, the WTRU can receive configuration information, including a set of LCH configurations associated with at least the default CG configuration and the implicitly disabled conditional CG configuration associated with the cell DRX, a set of QoS conditions associated with transmissions during the cell DRX and the conditional CG (e.g., the remaining time of the PDU set is less than a first threshold, or the importance or priority of the PDU set is greater than a second threshold), and / or the cell DRX configuration and an activation indication for the cell DRX. The WTRU can receive PDUs, such as PDU sets, from higher layers and map the PDU sets to one or more LCHs. The WTRU can determine, based on the received PDU set and the cell DRX configuration, whether any QoS conditions associated with the conditional CG configuration are met for transmitting PDUs during periods of cell DRX inactivity.

[0221] If any QoS conditions associated with the transmission of PDUs during cell DRX are met, the WTRU can select a condition CG configuration associated with the LCH and PDU (e.g., the WTRU can switch to a condition CG associated with a different BWP), use the selected condition CG to transmit at least a subset of PDUs to request implicit deactivation of cell DRX mode, monitor additional condition SS and / or core sets when transmitting PDUs from an LCH configured with condition CG, and / or receive indications (e.g., DCI) in the condition SS and / or core sets (e.g., the received indications may include confirmation indications for cell DRX deactivation or DG resources for PDU retransmission).

[0222] If QoS conditions are not met, the WTRU can transmit PDUs using the default CG configuration, based on the cell DRX configuration (e.g., only during cell DRX active periods). In one example, cached data can be selectively prioritized during NES. When pending transmissions immediately after the cell DRX inactive period ends, the WTRU may need to prioritize competing data (e.g., data or PDU sets with different priorities) over control information. To address this, when the cell DRX mode is activated, the WTRU can prioritize pending data (e.g., data whose priority is reduced due to cell DRX) and control information ready to be transmitted (e.g., based on cache time) by prioritizing them before other new and / or high-priority data in the LCH.

[0223] In operation, the WTRU can receive configuration information, including LCH configuration (e.g., priority values ​​for each LCP), cell DRX configuration (e.g., start offset, duration of active and / or inactive periods), association information between PDU cache time and priority offset (e.g., delta priority), and / or cache window configuration (e.g., start offset or window duration relative to the start of a cell DRX inactive period). The WTRU can receive, for example, a set of PDUs from higher layers and map PDUs to one or more LCHs based on their initial priorities. The WTRU can receive activation indications for cell DRX configurations from the network (e.g., during a cell DRX inactive period, the WTRU caches PDUs in the LCH). The WTRU can determine the cache time of PDUs in the LCH based on the PDU arrival time within the cache window and the duration of the cell DRX inactive period. The WTRU can determine a new priority for PDUs based on the initial priority, cache time, and association information (e.g., including priority offset). The WTRU can prioritize the set of PDUs in the LCH within the cache window over other PDUs arriving outside the cache window based on the new PDU priority. For example, prioritization can be accomplished via LCP, where lower-priority PDUs cached during cell DRX can be prioritized over higher-priority PDUs arriving after cell DRX. For instance, if new data contains high-priority control information (e.g., UCI, CQI, SRB data, or high-priority MAC CE) and / or if the cache time exceeds a threshold, the WTRU can prioritize the transmission of new data over retransmissions. For example, if the associated delay budget is about to expire, the WTRU can prioritize the transmission of a UCI (e.g., transmitted in PUCCH or PUSCH) over new data. If CG retransmission is configured, the WTRU can prioritize the ReTx of PDUs pending within the cache window over new data. The WTRU can transmit PDUs during the next cell DRX active period.

[0224] Figure 4 An example of process 400 according to one or more embodiments disclosed herein is illustrated. Process 400 may be manufactured by WTRU ( Figure 4 (Not shown in the diagram) is implemented. In 402, the WTRU receives configuration information, including LCH configuration (e.g., priority value for each LCP), cell DRX configuration (e.g., start offset, duration of active and / or inactive periods, etc.), correlation information between PDU cache time and priority offset (e.g., delta priority) and / or cache window configuration (e.g., start offset or window duration relative to the start of an inactive period of cell DRX, etc.), or multiple PUSCH configuration (e.g., CG and / or DG resources, including a set of DG and / or CG, CG period, PUSCH timing, etc.).

[0225] In a 404 error, the WTRU receives PDUs and / or sets of PDUs from a higher layer and maps them to one or more LCHs based on the initial priority of the PDUs. The WTRU also maps PDUs and / or sets of PDUs with the same or different QoS requirements and / or characteristics to one or more forwarding configurations. Different forwarding configurations can be configured to implement and / or enforce different QoS when transmitting PDUs and / or sets of PDUs using DG resources and / or CG resources.

[0226] In 406, the WTRU determines the timing of the first set of PUSCHs within a time window (e.g., the CG period) based on the payload size of the PDUs in the LCH cache. For example, the first set of PUSCHs could be PUSCHs that occur during a cell DRX active period. That is, before selecting PUSCHs from inactive periods, the WTRU prioritizes PUSCHs that occur during a cell DRX active period for data transmission.

[0227] In 408, WTRU checks whether any QoS conditions for using the CG PUSCH that occurred during a period of cell DRX inactivity are met. QoS conditions may include one or more conditions, such as, but not limited to, that the remaining time of the PDU set is less than a first threshold indicating the remaining time (i.e., remaining time < threshold 1) and / or the importance and / or priority value of the PDU set is greater than a second threshold indicating the priority value (i.e., priority value > threshold 2).

[0228] In 410, the WTRU determines the timing of the second set of PUSCHs within a time window (e.g., the CG period) based on the payload size of the PDUs in the LCH cache. For example, the second set of PUSCHs could be PUSCHs that occur during periods of cell DRX inactivity.

[0229] In 412, the WTRU transmits an indication (e.g., in the UCI) that indicates information about the required PUSCH in the first set of CG PUSCH (occurring during periods of cell DRX activity) and the second set of CG PUSCH (occurring during periods of cell DRX inactivity). In this case, for example, the WTRU monitors N slots and / or symbols of the PDCCH after the transmission indication.

[0230] In 414, the WTRU receives an acknowledgment associated with the use of a PUSCH opportunity during an inactive period. In the example, the WTRU may monitor the PDCCH used to receive acknowledgments regarding the use of a CG PUSCH opportunity occurring during a cell DRX inactive period when transmitting an indication of PUSCH use. For example, the acknowledgment may be received in a DCI (e.g., a new DCI format or paging DCI), MAC CE, or RRC signaling. For example, the acknowledgment may indicate a PUSCH opportunity permitted for use by the WTRU during a cell DRX active period and / or a cell DRX inactive period. Alternatively, the acknowledgment may indicate the activation of a new resource (e.g., a DG resource) or another CG configuration for the WTRU to use.

[0231] In 416, if an acknowledgment (indicating the permitted use of CG PUSCHs that occur during inactive periods) is received by the WTRU, the WTRU uses the first set of CG PUSCHs during the active period and the second set of CG PUSCHs during the inactive period to transmit the PDUs of the PDU set. If no acknowledgment is received, the WTRU may use only the first set of CG PUSCHs during the active period to transmit the PDUs, and delay the transmission of any remaining PDUs until the next cell DRX active period. Alternatively, the WTRU may retransmit the indication regarding PUSCH usage, possibly after the duration associated with the prohibition timer.

[0232] In 418, if the first set of PUSCHs that occurs during a cell DRX active period is sufficient to transmit the PDU set and / or any QoS conditions are not met, the WTRU transmits an indication to the network at the selected PUSCH timing (e.g., in UCI or UTO-UCI).

[0233] In 420, if the first set of PUSCHs that appears during a cell DRX active period is sufficient to transmit the PDU set and / or any QoS conditions are not met, the WTRU uses the selected first set of PUSCHs to transmit the PDUs.

[0234] As shown in the example, there may be one or more methods, systems, and / or devices for addressing the activation of conditional CG resources during NES state. The WTRU may be configured with forwarding settings to be applied during cell DRX active mode. The WTRU can determine whether conditional CG resources are used to transmit data and / or indications during cell DRX mode.

[0235] A network (as cited herein) may refer to any node or function within a network. For example, a WTRU may send transmissions / messages / information to and / or receive transmissions / messages / information from a network, where a network may mean any network node or function disclosed herein (e.g., see the device, base station, etc. discussed in Figure 1).

[0236] As described herein, a higher layer can refer to one or more layers in a protocol stack or a specific sublayer within a protocol stack. A protocol stack can include one or more layers in a WTRU or network node (e.g., eNB, gNB, other functional entities, etc.), where each layer can have one or more sublayers. Each layer / sublayer can be responsible for one or more functions. Each layer / sublayer can communicate directly or indirectly with one or more other layers / sublayers. In some cases, these layers can be numbered, such as Layer 1, Layer 2, and Layer 3. Layer 3 can include one or more of the following: Non-Access Stratum (NAS), Internet Protocol (IP), and / or Radio Resource Control (RRC). For example, Layer 2 can include one or more of the following: Packet Data Convergence Control (PDCP), Radio Link Control (RLC), and / or Media Access Control (MAC). For example, Layer 3 can include Physical (PHY) layer type operations. The higher the layer number, the higher it is relative to other layers (e.g., Layer 3 is higher than Layer 1). In some cases, the examples above can themselves be referred to as layers / sublayers, regardless of the layer number, and can be referred to as higher layers as described herein. For example, from highest to lowest, a higher layer can refer to one or more of the following layers / sublayers: NAS layer, RRC layer, PDCP layer, RLC layer, MAC layer, and / or PHY layer. Any reference to a higher layer in this document in connection with a process, device, or system refers to a layer above the layer described in the process, device, or system. In some cases, a reference to a higher layer may refer to a function or operation performed by one or more layers described herein. In some cases, a reference to a higher layer may refer to information sent or received by one or more layers described herein. In some cases, a reference to a higher layer may refer to configuration sent or received by one or more layers described herein.

[0237] Figure 5 This is a flowchart illustrating an example process 500 for transmitting one or more data units according to one or more embodiments discussed herein. Process 500 may be provided by WTRU ( Figure 5(Not shown in the diagram) Implementation. In 510, the WTRU receives configuration information. The configuration information includes one or more logical channels, one or more conditional CGs, one or more default CGs, and the association between one or more logical channels and one or more conditional CGs and / or default CGs, as well as one or more QoS conditions. One or more QoS conditions are associated with data units in one or more data units transmitted using conditional CGs from one or more conditional CGs during periods of cell DRX inactivity.

[0238] In 520, the WTRU checks whether the cell is in a period of inactive cell DRX. If the cell is in a period of inactive cell DRX, the WTRU checks whether any QoS condition in one or more QoS conditions is met for the data unit.

[0239] In 530, if at least one QoS condition is met for a data unit while the cell is in a period of inactive cell DRX, the WTRU selects a condition CG from one or more condition CGs to transmit the data unit.

[0240] In 540, the WTRU uses one or more resources in the selected condition CG to transmit data units. In this case, using one or more resources in the selected condition CG to transmit data units indicates a request to disable cell DRX mode.

[0241] In 550, if no QoS conditions are met for a data unit during a period when the cell is inactive for DRX, the WTRU will use the default CG to transmit the data unit during the subsequent period when the cell is active for DRX.

[0242] Figure 6 This is a flowchart illustrating an example process 600 for transmitting one or more data units according to one or more embodiments discussed herein. Process 600 may be provided by WTRU ( Figure 6 (Not shown in the diagram) Implementation. In 610, the WTRU receives configuration information. The configuration information includes one or more conditional CGs, one or more default CGs, and one or more QoS conditions. The configuration information further includes a cell DRX activation indication.

[0243] In 620, when the cell is in a period of inactive cell DRX and when at least one QoS condition for a data unit is met, the WTRU selects condition CG to transmit data units in one or more data units.

[0244] In 630, the WTRU uses the selected condition CG to transmit data units and a request to disable cell DRX mode during periods of cell DRX inactivity. In the example, the request to disable cell DRX mode is implicit when transmitting the data unit. In another example, the request to disable cell DRX mode is multiplexed along with the data unit.

[0245] Although features and elements have been described above in specific combinations (e.g., embodiments, methods, examples, etc.), those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. For example, as disclosed herein, for illustrative purposes, there may be a method described in association with the figures, and those skilled in the art will understand that one or more features or elements from this method can be used alone or in combination with one or more features from another method described elsewhere. The symbol ' / ' (e.g., a forward slash) may be used herein to mean 'and / or', where, for example, 'A / B' may imply 'A and / or B'. As used herein, 'a' and 'an', and similar phrases, should be interpreted as 'one or more' and 'at least one'. Similarly, any term ending with the suffix '(s)' should be interpreted as 'one or more' and 'at least one'. The term 'may' should be interpreted as 'can, for example' or indicating that something "will actually happen" or "may happen". Furthermore, the methods described herein can be implemented in computer programs, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, caches, 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 discs (DVDs)). The processor associated with the software can be used to implement radio frequency transceivers for use in WTRUs, UEs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: Receive configuration information relating to one or more logical channels, one or more conditional configuration grants (CGs), one or more default CGs, the association between the one or more logical channels and at least one of the one or more conditional CGs, the one or more default CGs, or one or more quality of service (QoS) conditions, wherein the one or more QoS conditions are associated with one or more data unit transmissions using the conditional CGs from the one or more conditional CGs during periods of inactive cell discontinuous reception (DRX); as well as When the cell is in a period of DRX inactivity and the QoS conditions among one or more of the QoS conditions for the data unit are met, Select the CG condition from the one or more CG conditions, and The data unit is transmitted using one or more resources of the selected condition CG, wherein the data unit transmission includes a request to disable cell DRX mode, and When the cell is in a period of DRX inactivity and one or more of the QoS conditions are not met, During subsequent active DRX periods in the cell, one or more resources of the default CG in one or more default CGs are used to transmit the data unit.

2. The method according to claim 1, further comprising: The recipient received an indication that the cell's DRX mode was activated.

3. The method of claim 2, wherein when the data unit is transmitted using one or more resources of the selected condition CG, the request to disable the cell DRX mode is implicit.

4. The method of claim 2, wherein the request to disable the cell DRX mode is explicit and multiplexed together with the data unit.

5. The method of claim 2, wherein the one or more QoS conditions include the remaining time of the data unit.

6. The method of claim 2, wherein the one or more QoS conditions include the importance of the data unit.

7. A wireless transmit / receive unit (WTRU), the WTRU comprising: Memory, which is configured to store data units; A receiver configured to receive configuration information relating to one or more logical channels, one or more conditional configuration grants (CGs), one or more default CGs, an association between the one or more logical channels and at least one of the one or more conditional CGs, the one or more default CGs, or one or more quality of service (QoS) conditions, wherein the one or more QoS conditions are associated with one or more data unit transmissions using the conditional CGs from the one or more conditional CGs during periods of inactive cell discontinuous reception (DRX). Transmitter; as well as Processor, wherein the transmitter and the processor are configured as follows: When the cell is in a period of DRX inactivity and the QoS conditions among the one or more QoS conditions for the data unit are met, Select the CG condition from the one or more CG conditions, and The data unit is transmitted using one or more resources of the selected condition CG, wherein the data unit transmission includes a request to disable cell DRX mode, and When the cell is in a period of DRX inactivity and one or more of the QoS conditions are not met, During subsequent active DRX periods in the cell, one or more resources of the default CG in one or more default CGs are used to transmit the data unit.

8. The WTRU of claim 7, wherein the receiver is further configured to receive an indication that the cell DRX mode is activated.

9. The WTRU of claim 8, wherein when the data unit is transmitted using one or more resources of the selected condition CG, the request to disable the cell DRX mode is implicit.

10. The WTRU of claim 8, wherein the request to disable the cell DRX mode is explicit and multiplexed together with the data unit.

11. The WTRU of claim 8, wherein the one or more QoS conditions include the remaining time of the data unit.

12. The WTRU of claim 8, wherein the one or more QoS conditions include the importance of the data unit.

13. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: Receive configuration information, which specifies one or more conditional authorization (CG), one or more default CGs, and one or more quality of service (QoS) conditions; as well as When a QoS condition in one or more of the QoS conditions is satisfied for a data unit, the data unit and a request to disable cell DRX mode are transmitted using a condition CG from one or more condition CGs during a period of inactive cell discontinuous reception (DRX).

14. The method of claim 13, further comprising: When one or more QoS conditions are not met for the data unit, the data unit is transmitted using the default CG among the one or more default CGs during the active period of cell DRX.

15. The method of claim 14, further comprising: Based on the logical channel mapped to the data unit, the condition CG is selected for the transmission of the data unit.

16. The method of claim 15, wherein the configuration information further includes a cell DRX activation indication.

17. The method of claim 16, wherein the QoS condition is satisfied when the remaining time associated with the data unit is less than a threshold time indicated by the QoS condition.

18. The method of claim 17, wherein the QoS condition is satisfied when the priority value associated with the data unit exceeds a threshold priority value indicated by the QoS condition.

19. The method of claim 18, wherein the request to disable the cell DRX mode during the transmission of the data unit is implicit.

20. The method of claim 18, wherein the real-time request for disabling the cell DRX mode is multiplexed together with the data unit.

Images