Method and apparatus for performing simultaneous sidelink discontinuous reception (DRX) and uplink DRX in New Radio (NR) vehicle-to-everything (V2X)

Abstract

Disclosed are methods and apparatus for uplink DRX and sidelink DRX. A WTRU may receive a configuration for a hybrid automatic repeat request (HARQ) round trip time (RTT) timer. The WTRU may start the HARQ RTT timer in response to an event. The event may include receiving downlink control information (DCI) scheduling a sidelink transmission. The event may include the transmission of sidelink control information (SCI) for a sidelink HARQ process. The event may include receiving HARQ feedback for the sidelink transmission. The event may include a preconfigured time period after a physical sidelink feedback channel (PSFCH) resource is used for feedback associated with the HARQ transmission. The WTRU may determine the timer value based on sidelink transmission characteristics or sidelink transmission time.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 975,500, filed February 12, 2020, and U.S. Provisional Application No. 63 / 027,003, filed May 19, 2020, the contents of which are incorporated herein by reference. Background Art

[0003] Vehicular communication is a communication mode in which vehicles can communicate directly with each other. A scenario for vehicle-to-everything (V2X) operation is an in-coverage scenario, where the WTRU receives assistance from the network to initiate transmission and reception of V2X messages. Another scenario for V2X operation is an out-of-coverage scenario, where the WTRU can initiate transmission and reception of V2X messages using pre-configured parameters.

[0004] V2X communication is supported in LTE Release 14 (Rel-14) and is inspired by previous work on device-to-device (D2D) communication. V2X communication services can consist of different types, including vehicle-to-vehicle (V2V), where vehicle WTRUs can communicate directly with each other; vehicle-to-infrastructure (V2I), where vehicle WTRUs can communicate with RSUs / eNBs; vehicle-to-network (V2N), where vehicle WTRUs can communicate with the core network; and vehicle-to-pedestrian (V2P), where vehicle WTRUs can communicate with WTRUs with special conditions (e.g., low battery capacity). Summary of the Invention

[0005] Methods and apparatus for uplink DRX and sidelink DRX are disclosed. In one embodiment, a WTRU may receive sidelink data for transmission. The WTRU may perform physical downlink control channel (PDCCH) decoding based on the received sidelink data. The WTRU may report sidelink-related information to the network. The sidelink-related information reported to the network may include: reception of the sidelink, physical sidelink control channel (PSCCH) transmission, arrival of sidelink data in the sidelink transmission buffer; and enabling or disabling sidelink discontinuous reception (DRX). The WTRU may receive an indication from the network that sidelink monitoring is allowed. The WTRU may receive a set of sidelink DRX parameters that are independent of the parameters configured for Uu DRX. The WTRU may receive a scheduled sidelink grant from the network during its Uu active time (i.e., the time when the WTRU actively monitors the PDCCH). The WTRU may receive a first DRX configuration associated with the Uu and a second DRX configuration associated with the sidelink DRX. The WTRU may receive a sidelink transmission indicating a change in activity state. The WTRU may receive a sidelink transmission indicating a set of resources to which an indicated activity state applies. The WTRU may receive a sidelink transmission indicating a period and offset to be applied to a periodic activity state. The WTRU may receive a sidelink transmission indicating a new set of resources to monitor. The WTRU may receive a configuration of sidelink time and frequency resources to monitor for an activity state change transmission. The activity state change may be for a group of WTRUs. The WTRU may transmit an activity state change indication upon receiving an activity state change transmission from another WTRU.

[0006] The WTRU may determine the value of a timer associated with Uu and / or sidelink DRX based on sidelink timing information related to the sidelink transmission. The determination may be based on the separation of the PSCCH from the PSFCH. The determination may be a function of the selected timing resource. The determination may be a function of the packet delay budget. The determination may be a function of the priority. The determination may be a function of the maximum number of retransmissions between the retransmission resource and the initial transmission resource. The determination may be a function of the time offset between the retransmission resource and the initial transmission resource.

[0007] The WTRU may inform a peer WTRU of its active behavior on Uu. The WTRU may send parameters related to the sidelink active behavior, which may be affected or changed by the Uu active behavior. The WTRU may provide the information explicitly or implicitly. The WTRU may include the parameters of its UuDRX configuration and / or active behavior in the PC5-RRC message after establishing a unicast link and / or when configuring an SLRB. The WTRU may send an indication to a peer WTRU or a peer WTRU group when moving to DRX. The WTRU may select the physical sidelink feedback channel (PSFCH) transmission resource based on the active behavior or status of the peer WTRU. The WTRU may determine whether to send a sidelink reconfiguration success / failure message based on whether the WTRU is configured with the same or similar DRX parameters on Uu and / or DRX. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] A more detailed understanding may be obtained from the following description given by way of example with reference to the accompanying drawings in which like reference numerals indicate like elements and in which:

[0009] Figure 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

[0010] Figure 1B It is shown that according to one embodiment, Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) for use within the illustrated communication system;

[0011] Figure 1C It is shown that according to one embodiment, Figure 1A A system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) for use within the illustrated communication system;

[0012] Figure 1D It is shown that according to one embodiment, Figure 1A A system diagram of another exemplary RAN and another exemplary CN used within the illustrated communication system;

[0013] Figure 2 is a diagram illustrating an exemplary method of determining a timer value;

[0014] Figure 3 is a diagram illustrating one exemplary method of determining a timer value; and

[0015] Figure 4 is a flow chart illustrating one exemplary method for determining activity time on a Uu. DETAILED DESCRIPTION

[0016] Figure 1A is a schematic diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable 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 spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0017] 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. However, it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (WTRUs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspot 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 process chain environments), consumer electronic devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.

[0018] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a NodeB, an evolved NodeB (eNB), a Home NodeB, a Home evolved NodeB, a next generation NodeB such as a gNodeB (gNB), a New Radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

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

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

[0023] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access and may establish the air interface 116 using NR.

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

[0025] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), GSM Enhanced Data rates for Evolution (EDGE), GSM EDGE (GERAN), etc.

[0026] Figure 1A The base station 114b in the may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a microcell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to the Internet 110. Thus, base station 114b may not need to access the Internet 110 via CN 106.

[0027] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although not described in detail in the text, the CN 106 may be configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Figure 1AAlthough not shown in the figures, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0031] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors 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. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0034] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. For example, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

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

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

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

[0038] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Module, frequency modulation (FM) radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripheral device 138 may include one or more sensors. The sensor may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

[0039] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., a choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL (e.g., for reception)) may be concurrent and / or simultaneous.

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

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

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

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

[0044] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

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

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

[0048] Although the WTRU Figures 1A to 1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments such a terminal may (eg, temporarily or permanently) employ a wired communications interface with a communications network.

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

[0050] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or out of the BSS. Traffic originating from outside the BSS and destined for a STA can reach the AP and be delivered to the STA. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the destination. Traffic between STAs within a BSS can be sent through 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 a BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between a source and destination STA (e.g., directly between them) using direct link setup (DLS). In certain representative embodiments, the DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0051] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. With CSMA / CA, STAs (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected by a particular STA and / or determined to be busy, the particular STA may back off. One STA (e.g., only one station) may transmit in a given BSS at any given time.

[0052] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a primary 20 MHz channel combined with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0053] 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-contiguous 80 MHz channels (this may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can separate the data into two streams. Each stream can be individually processed using an inverse fast Fourier transform (IFFT) and time domain processing. These streams can be mapped to two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0054] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah relative 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, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter 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 for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0055] WLAN systems that support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah include a channel that can be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (that supports the minimum bandwidth operating mode) from among all STAs operating in the BSS. In the example of 802.11ah, for a STA (e.g., an MTC-type device) that supports (e.g., only supports) 1 MHz mode, the primary channel may 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 sensing and / or network allocation vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, because a STA (that only supports 1 MHz operating mode) is transmitting to the AP, the entire available frequency band may be considered busy even if most of the available frequency band remains idle.

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

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

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

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

[0060] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate or connect with the gNBs 180a, 180b, 180c while also communicating or connecting with other RANs, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0061] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, interworking between DC, NR, and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0062] Figure 1DThe illustrated CN 106 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 data networks (DNs) 185a, 185b. While the aforementioned elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0063] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c via the N2 interface in the RAN 104 and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating non-access stratum (NAS) signaling, mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services used by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on enhanced Mobile Broadband (eMBB) access, services for MTC access, etc. The AMFs 182 a and 182 b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0064] The SMF 183a, 183b may connect to the AMF 182a, 182b in the CN 106 via the N11 interface. The SMF 183a, 183b may also connect to the UPF 184a, 184b in the CN 106 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

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

[0067] Given that Figures 1A to 1D as well as Figures 1A to 1D As described herein, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more emulated devices (not shown): the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein. An emulated device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulated device may be used to test other devices and / or simulate network and / or WTRU functions.

[0068] The emulation device may be designed to implement one or more tests of other devices in a lab environment and / or in a carrier network environment. For example, the one or more emulation devices may perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communications to perform testing.

[0069] The one or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to enable testing of one or more components. The one or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) can be used by the simulation device to transmit and / or receive data.

[0070] In LTE, modes of operation in V2X communications are defined. In Mode 3, the network may provide the WTRU with scheduling assignments for V2X sidelink transmissions. In Mode 4, the WTRU may autonomously select resources from a configured / pre-configured resource pool. Two types of resource pools are defined in V2X LTE: a receive pool that may be monitored for receiving V2X transmissions, and a transmit pool that may be used by the WTRU to select transmit resources in Mode 4. WTRUs configured in Mode 3 do not use a transmit pool.

[0071] In LTE, resource pools may be semi-statically signaled to the WTRU via RRC signaling. In Mode 4, the WTRU may use sensing before selecting resources from the RRC-configured transmission pool. LTE V2X does not support dynamic resource pool reconfiguration. Pool configuration may only be carried via SIB and / or dedicated RRC signaling.

[0072] 3GPP is currently working on the next-generation wireless system, called New Radio (NR). NR systems are expected to support a variety of use cases, such as enhanced mobile broadband (eMBB) and ultra-reliable low-latency communications (URLLC). NR Rel-15 work items are expected to be completed in June 2018.

[0073] 3GPP expects to approve research projects to support enhanced V2X (eV2X) communications in NR systems. eV2X in NR is expected to support new services for both safety and non-safety scenarios (e.g., sensor sharing, autonomous driving, platooning, and remote driving). Different eV2X services may require different performance requirements. For some scenarios, a latency of 3ms may be required.

[0074] NR V2X is expected to support new use cases. One use case expected to be supported is vehicle platooning, which enables vehicles to dynamically form groups to travel together. All vehicles in the platoon can receive periodic data from the lead vehicle to facilitate platooning operations. This information can allow the distance between vehicles to become extremely small (i.e., the gap distance converted to time can be very low (sub-second)). Platooning applications can allow following vehicles to drive autonomously.

[0075] Another use case expected to be supported is advanced driving, which can enable semi- or fully autonomous driving. Longer inter-vehicle distances can be assumed. Each vehicle and / or roadside unit (RSU) can share data obtained from its local sensors with nearby vehicles, allowing them to coordinate their trajectories or maneuvers. Each vehicle can also share its driving intentions with nearby vehicles. The benefits of this use case group include safer driving, collision avoidance, and improved traffic efficiency.

[0076] Another use case expected to be supported is extended sensors, which can enable the exchange of raw or processed data collected through local sensors or live video data between vehicles, RSUs, pedestrian devices, and V2X application servers. Vehicles can enhance their perception of their environment beyond the range of their own sensors and gain a more comprehensive view of the local situation.

[0077] Another use case that is expected to be supported is remote driving, which can enable a remote driver or V2X application to operate a remote vehicle for a passenger who cannot drive themselves or to operate a remote vehicle in a hazardous environment. For situations where variability is limited and routes are predictable, such as public transportation, cloud-based driving can be used. For this use case group, access to a cloud-based backend service platform can be considered.

[0078] SA2 has begun describing the QoS model for NR V2X. In Rel-14 V2X, QoS on PC5 is supported through ProSe Per-Packet Prioritization (PPP), as documented in 3GPP TS 23.285. This allows the application layer to mark packets using PPPP, which can indicate the required QoS level. Certain enhancements have been added (for example, by allowing the PDB to be derived from PPPP).

[0079] New QoS requirements for NR V2X are described in 3GPP TS 22.186. New performance KPIs are specified using the following parameters: payload (bytes); transmission rate (messages / second); reliability (%); data rate (Mbps); and minimum required communication range (meters).

[0080] The same set of service requirements can be applied to both PC5-based V2X communications and Uu-based V2X communications. These QoS characteristics can be expressed using the 5QI defined in 3GPP TS 23.501.

[0081] SA2 has proposed the possibility of having a unified QoS model for PC5 and Uu (i.e. using 5QI also for V2X communications over PC5) so that the application layer can have a consistent way of indicating QoS requirements regardless of the link used.

[0082] Considering a 5GS V2X-capable WTRU, there are three different types of traffic: broadcast, multicast, and unicast.

[0083] For unicast traffic, the same QoS model as for Uu can be used (i.e., each unicast link can be considered a bearer and a QoS flow can be associated with it). Additional parameters for QoS characteristics and data rates defined in 5QI can be applied. The minimum required communication range can be considered as an additional parameter specific to PC5. Similar considerations may apply to multicast traffic, as it can be considered a special case of unicast (i.e., with multiple defined traffic receivers).

[0084] For broadcast traffic, there may be no bearer concept. Therefore, each message can have different characteristics depending on the application requirements. 5QI can then be used in a similar manner to PPPP / PPPR (i.e., tagged with each packet). 5QI can represent all the characteristics required for PC5 broadcast operation (e.g., latency, priority, reliability, etc.). A set of V2X broadcast-specific 5QIs (i.e., VQIs) can be defined for use by PC5.

[0085] PC5 QoS parameters may be negotiated during the one-to-one communication establishment procedure. The one-to-one communication establishment procedure is enhanced to support PC5 QoS parameter negotiation between two WTRUs. Following the PC5 QoS parameter negotiation procedure, the same QoS may be used in both directions.

[0086] A WTRU participating in a one-to-one communication may Figure 2PC5 QoS parameters are negotiated during the link establishment procedure shown. A first WTRU (WTRU-1) may send a direct communication request message to a second WTRU (WTRU-2) to trigger mutual authentication. The message may include the requested PC5 QoS parameters. WTRU-2 may initiate the mutual authentication procedure. WTRU-2 may include the accepted PC5 QoS parameters in a response message.

[0087] CONNECTED mode DRX is specified for the WTRU in RRC_CONNECTED to save power in the NR Uu. DRX may be scheduled based on the wake-up time configured at the WTRU. If the WTRU receives a PDCCH schedule during its wake-up time, it may remain awake for a certain time until no further schedule is received. The WTRU may be configured with a drx-onDurationTimer, which may indicate the duration when the DRX cycle starts. The WTRU may be configured with a drx-SlotOffset, which may indicate the delay before starting the drx-onDurationTimer. The WTRU may be configured with a drx-InactivityTimer, which may indicate the duration after the PDCCH opportunity in which the PDCCH indicates a new uplink or downlink transmission for the MAC entity. The WTRU may be configured with a drx-RetransmissionTimerDL (for each downlink HARQ process except the broadcast process), which may indicate the maximum duration until a downlink retransmission is received. The WTRU may be configured with a drx-RetransmissionTimerUL (per uplink HARQ process) which may indicate the maximum duration until an uplink retransmission grant is received. The WTRU may be configured with a drx-LongCycleStartOffset which may indicate the long DRX cycle and a drx-StartOffset which may define the subframes at which the long DRX cycle and the short DRX cycle start. The WTRU may be configured with a drx-ShortCycle (which may be optional) which may indicate the short DRX cycle. The WTRU may be configured with a drx-ShortCycleTimer (which may be optional) which may indicate the duration that the WTRU will follow the short DRX cycle. The WTRU may be configured with a drx-HARQ-RTT-TimerDL (per downlink HARQ process except the broadcast process) which may indicate the minimum duration before the MAC entity expects a downlink allocation for HARQ retransmissions. The WTRU may be configured with a drx-HARQ-RTT-TimerUL (per uplink HARQ process) which may indicate the minimum duration before the MAC entity expects an uplink HARQ retransmission grant.

[0088] A WTRU configured with DRX may determine its Uu Active Time (i.e., the time during which the WTRU actively monitors the PDCCH). When the DRX cycle is configured, the Uu Active Time may include the time when the drx-onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimerDL or drx-RetransmissionTimerUL or ra-ContentionResolutionTimer is running. When the DRX cycle is configured, the Uu Active Time may include the time during which a scheduling request is sent and waited on the PUCCH. When the DRX cycle is configured, the Uu Active Time may include the time during which a PDCCH indicating a new transmission addressed to the C-RNTI of the MAC entity has not been received after a random access response with a preamble that was not selected by the MAC entity has been successfully received.

[0089] Another power saving mechanism introduced in LTE V2X for pedestrian WTRUs is an aspect of partial sensing. With partial sensing, the WTRU may be configured by upper layers with a minimum number of candidate subframes in a resource selection window [T1, T2], where specific subframes may be selected by the WTRU implementation. The WTRU may perform sensing only on subframes within the sensing window, which may be an integer number of reserved periods from the candidate subframes, thereby reducing the amount of resources required for the WTRU to perform sensing within the sensing window.

[0090] Another possibility for a pedestrian WTRU is to perform random selection on the resource pool. If the resource pool is configured for random selection, the WTRU may perform resource selection without considering any sensing results during the sensing process.

[0091] A WTRU performing sidelink (SL) transmissions which should ensure power savings may also be in DRX on the Uu. Further consideration needs to be given to procedures to ensure consistent power savings on both the Uu and sidelink. In order to time align the network scheduling of the SL with the SL activity, the network may need to be aware of the SL activity. When a WTRU has its Uu DRX and SL DRX aligned, DRX alignment may be required between groups of WTRUs where the group may be in partial coverage (i.e., some WTRUs are in coverage and others are out of coverage).

[0092] A WTRU may determine an activity behavior on a sidelink to reduce power consumption of the WTRU performing a sidelink transmission. The activity behavior may be determined dynamically by the WTRU (e.g., based on measurements on the sidelink and / or receipt and / or transmission of data from upper layers or a peer WTRU), or it may be configured by the network. The network may configure a set of measurement values (e.g., sidelink measurement values) and corresponding activity behaviors to be applied by the WTRU. A WTRU may change its activity behavior due to events related to the receipt of data (e.g., from a peer WTRU or from upper layers for transmission) or the receipt of an explicit indication to change such activity behavior.

[0093] The active behavior may include a DRX cycle indicating a wake-up period when DRX is performed. The active behavior may include one or more timers associated with DRX behavior in Uu DRX or similar behavior, such as: an inactivity timer associated with sidelink transmission; an on-duration timer associated with sidelink transmission; a slot offset; a retransmission timer; a HARQ RTT timer; a DRX short cycle timer. The active behavior may include the length of the sensing window of the resource pool used for sensing Mode 2 resource allocation. The active behavior may include a number of candidate subframes in the resource selection window that the WTRU may consider for transmission (as the resulting sensing resources). The active behavior may include a number of subchannels, a number of frequency resources, an initial and a last subchannel / frequency resource to be considered for sensing and / or resource allocation. The active behavior may include a number of candidate frequency resources or subchannels that the WTRU may consider for transmission. The active behavior may include an offset for one or more sensing and / or resource selection subframes. For example, the WTRU may determine to perform sensing in subframe n1+j*P, where n1 is an offset to the SFN, j is an integer value, and P is a fixed value / (pre-)configured value. The activity behavior may include multiple repetitions performed by the WTRU, possibly with the same TB, possibly to reach other WTRUs in DRX. The activity behavior may include the amount of resources and / or resource pools available for reception / transmission / sensing. For example, the WTRU may be configured with multiple activity states (e.g., low, high, medium, etc.) and may transition between these states based on any of the events described herein.

[0094] The activity behavior may be determined based on the WTRU's receipt and / or measurement of a trigger, similar to the receipt of a PDCCH for Uu DRX. The WTRU may reset the inactivity timer, or have any behavior that modifies its activity behavior, as a result of any of the following: receiving an SCI, whereby the SCI may be an SCI for scheduled data and / or an SCI for performing notification of future scheduled data; receiving a DCI scheduling a sidelink; receiving a sidelink wake-up signal (e.g., a dedicated SCI indicating only wake-up); receiving an SLSSB / PBCH; receiving a data PDU on the sidelink, where such data PDU may also be conditioned based on the characteristics of the PDU or the content of the PDU. For example, when the PDU includes data from a logical channel, the WTRU may have a first behavior (e.g., reset the inactivity timer), and when the PDU includes control information (e.g., MAC CE, CSI feedback, PC5 RRC, etc.), the WTRU may have a second behavior (e.g., do not reset the inactivity timer).

[0095] Methods for common uplink (UL) and sidelink DRX are disclosed. When the WTRU is in RRC_CONNECTED, aligning UL DRX with sidelink activity can be used to ensure common activity time for both SL and UL traffic. In this case, the WTRU may only need to turn on analog and digital components / transceivers once, regardless of whether they are used for Uu traffic or sidelink traffic.

[0096] The WTRU may determine its PDCCH decoding Uu active time based on the sidelink transmission / reception. The WTRU may determine its sidelink transmission / reception based on the PDCCH decoding active time.

[0097] The WTRU may extend, modify, and / or determine its PDCCH decoding on-duration based on sidelink related triggers related to transmission or reception. The WTRU may extend, modify, and / or determine its PSCCH decoding time on the sidelink based on triggers related to Uu DRX.

[0098] In one embodiment, the WTRU may maintain separate timers / counters associated with Uu DRX to determine Uu activity time, and may also maintain separate timers / counters associated with SL DRX to determine SL activity time. The WTRU may determine its sidelink activity behavior (using these separate timers) based on whether it is scheduled with a DCI with an SL or Uu grant. Specifically, the WTRU may determine the value of the timer based on whether the timer is triggered by a DCI scheduling a Uu or SL transmission.

[0099] For example, the WTRU may be configured with separate inactivity timer values on Uu that are associated with Uu and SL scheduling. If the WTRU receives a DCI scheduling for SL, it starts the inactivity timer with a value associated with SL. If the WTRU receives a DCI scheduling for Uu, it starts the inactivity timer with a value associated with Uu.

[0100] For example, the WTRU may be configured with separate HARQ RTT timer / retransmission timer values and use appropriate values of the HARQ RTT / retransmission timers depending on whether the HARQ process is associated with Uu or SL scheduling.

[0101] In another example, the WTRU may be configured with separate timers associated with Uu DRX (a timer associated with SL and a timer associated with Uu). The WTRU may maintain these timers independently. The WTRU may control these timers based on the associated schedule (i.e., DCI schedules sidelink to control the sidelink timer and DCI schedules Uu to control the Uu timer). The WTRU's activity behavior with respect to Uu may then be as follows: (1) the WTRU may (possibly only) monitor the SL-RNTI during the Uu activity time corresponding to the SL and monitor the non-SL-RNTI during the Uu activity time corresponding to the Uu, or (2) the WTRU may monitor the Uu if the activity time / timer is running (Uu or SL).

[0102] The WTRU may determine that the WTRU is active (ie, performs both PDCCH monitoring and PSCCH monitoring) if either the UL DRX procedure or the SL DRX procedure or both indicate that the WTRU should be active.

[0103] In one embodiment, the WTRU may perform SL decoding based on Uu DRX activity behavior and may modify / update Uu DRX related parameters (e.g., timers) upon SL events. For example, the WTRU may reset timers related to UL scheduling (e.g., existing or new activity timers) upon the occurrence of any or a combination of the following events. The WTRU may receive a PSCCH / PSSCH with data intended for / decoded by the WTRU. The WTRU may receive DCI on the PDCCH indicating a new SL transmission. For example, if the PDCCH indicates a new UL or DL or SL transmission, the WTRU may restart the drx-InactivityTimer. The WTRU may determine the activity time on both the UL and SL based on the existing drx-InactivityTimer. The WTRU may receive HARQ feedback in response to its transmission. This may further depend on the type of HARQ feedback, such as receive only NACK, receive only ACK, receive DTX, or NACK. The WTRU may receive a CSI request from a peer WTRU. The WTRU may receive CSI feedback from a peer WTRU. The WTRU may transmit SCI / data on the SL. Such a transmission may correspond to a first transmission. Such a first transmission may correspond to a transmission with associated retransmission resources, associated HARQ feedback resources, and / or associated reserved resources for a new transmission. The WTRU may transmit HARQ feedback in response to the received TB. This may further depend on the type of HARQ feedback, such as NACK-only, ACK-only, DTX, or NACK. The measured CBR may increase by a certain amount or increase above a threshold.

[0104] In one embodiment, the WTRU may enable PDCCH decoding due to the arrival of SL data for transmission. A WTRU in Uu DRX (i.e., waiting for the start of the Uu On Duration) may perform PDCCH decoding when SL data for transmission arrives. Uu decoding may start when the data arrives. Uu decoding may start at a time corresponding to or closest to the SL resource selected for such data transmission. As a result of the SL data arrival / transmission, the WTRU may start a DRX activity timer associated with the SL or UL (or both) when PDCCH decoding is enabled.

[0105] In one embodiment, the WTRU may be configured with a HARQ_RTT timer for a SL HARQ process for which HARQ feedback may be enabled. The WTRU may start the HARQ RTT timer for the SL HARQ process in any of the following circumstances: (1) upon receiving a DCI scheduling a sidelink transmission (e.g., a sidelink transmission for a particular HARQ process); (2) upon transmitting an SCI for a particular HARQ process; (3) upon receiving HARQ feedback for a SL transmission; (4) upon transmitting SL HARQ feedback to the network on the PUCCH; and (5) at some fixed or preconfigured time period (e.g., the next time slot) after a physical sidelink feedback channel (PSFCH) resource is used for feedback associated with the HARQ transmission.

[0106] When (or whether) the WTRU starts the Uu activity timer (and the value of the timer) may further depend on the configuration of the SL. In another example, when (or whether) the WTRU starts the Uu activity timer and the value of the timer may further depend on the configuration of the SL, which may further include: (1) whether the WTRU is configured with a PSFCH on the sidelink (e.g., in a resource pool); (2) whether the WTRU is configured with a PUCCH for transmitting SL HARQ feedback to the network; and / or (3) whether the HARQ process is configured with HARQ enabled or disabled.

[0107] In one example, when the WTRU resets the HARQ RTT for the SL HARQ process, the WTRU may start the HARQ RTT timer when transmitting HARQ feedback on the PUCCH when the WTRU is configured to transmit PUCCH to the network, or may start the HARQ RTT timer when receiving the SCI or receiving HARQ feedback for the SL when no PUCCH is configured. The WTRU may also be configured with different HARQ RTT timer values for each of these two cases.

[0108] In another example, when the WTRU resets the HARQ RTT for the SL HARQ process, the WTRU may start the HARQ RTT timer when transmitting the SCI for the HARQ process when PSFCH is not configured (or when the SL HARQ process has HARQ disabled), and may start the HARQ RTT timer when receiving SL HARQ feedback when PSFCH is configured (or when the SL HARQ process has HARQ enabled).

[0109] In another example, if the WTRU is configured without PUCCH for reporting SL HARQ feedback, or is configured without PSFCH, or when the HARQ process disables HARQ feedback, the WTRU may not use the HARQ RTT timer when defining the active time (i.e., not sleep during the HARQ RTT).

[0110] The WTRU may be configured to determine the value of the timer based on SL transmission characteristics or SL transmission time.The WTRU may determine the value of the timer associated with Uu DRX and / or SL DRX based on SL timing information related to the SL transmission.

[0111] The WTRU may determine the value of a timer (eg, a HARQ RTT timer) based on the separation of PSCCH from PSFCH. For example, the WTRU may determine the value of the HARQ RTT timer by adding the separation of PSCCH from PSFCH to the network configured value.

[0112] The WTRU may determine the value of a timer (eg, an inactivity timer) based on the timing of the resource selected in Mode 2, for example.

[0113] The WTRU may determine the value of a timer (eg, a retransmission timer) based on a packet delay budget (PDB), priority, T2, or similar parameter associated with the delay on the sidelink.

[0114] The WTRU may determine the value of a timer (eg, a retransmission timer) based on the maximum number of retransmissions and / or the time offset between the retransmission resource and the initial transmission resource.

[0115] Figure 2 An example of how a WTRU may determine the value of a timer is shown. The WTRU may determine the inactivity timer associated with the Uu DRX based on the priority of the SL transmission to be performed. Specifically, the amount of time that the WTRU may remain awake to monitor the PDCCH for SL scheduling after a DCI may depend on the priority of the data that the WTRU transmits on the sidelink. For example, the WTRU may be configured with a first inactivity timer (T1) for a priority value of P1 and a second inactivity timer (T2) for a priority value of P2. When a DCI is received during an active period, in which case the DCI schedules a SL, the WTRU may set the Uu inactivity timer to a value corresponding to the priority of the data it transmits on the sidelink.

[0116] Figure 3 Another example of how a WTRU may determine the value of a timer is shown. Figure 3As shown, the WTRU may determine the value of the Uu retransmission timer based on the priority and / or PDB (packet delay budget) of the retransmission performed on the SL. Specifically, the WTRU may receive a grant (SL grant) on the PDCCH for transmission on the sidelink. When the WTRU reports a NACK on the PUCCH (e.g., after receiving a NACK from a peer WTRU on the SL), the WTRU may set a retransmission timer that depends on the PDB and / or the priority of the packet transmitted on the sidelink. For example, the WTRU may be configured with a value for the Uu retransmission timer for one or a set of given SL priorities. In the figure below, the WTRU is configured with a retransmission timer ReTX1 that corresponds to the priority and / or PDB associated with the packet it selects for transmission on the sidelink using the grant. The WTRU may start the retransmission timer at a time (e.g., HARQ RTT) after transmitting the NACK on the PUCCH. For the second retransmission (in the case where the NACK is reported after the second grant in the figure), the WTRU may set the retransmission timer of ReTX2 to the remaining PDB. The WTRU may determine the value of the retransmission timer ReTX2 in two ways: (1) by subtracting the time that has passed from the residual value of ReTX1 since ReTX1 was stopped, or (2) by determining the remaining PDB of the packet (based on its priority) and setting ReTX2 to the value of the remaining PDB.

[0117] The WTRU may report information related to SL activity behavior to the network. In one embodiment, the WTRU may report information related to or indicative of activity behavior to the network via the sidelink. Such reporting may enable the network to align UL DRX with SL activity behavior at the WTRU in RRC_CONNECTED. While in RRC_CONNECTED, the WTRU may report any of the following information related to the sidelink:

[0118] The WTRU may report the reception of a SL PSCCH / PSSCH transmission. For example, the WTRU may report the reception and / or successful decoding of a SL PSCCH / PSSCH to the network. Such reception may be reported in a BSR transmission via a dedicated PUCCH resource (e.g., an SR transmission or similar PUCCH resource), in a MAC CE, or in an RRC transmission. Such indication may further be reported when the received PSCCH / PSSCH changes the behavior of the WTRU's activity on the sidelink and / or UL, such as extending the common UL / SL activity time, changing between different configured wake-up time periods, etc. For example, the report may be sent when the reception occurs in the last N slots of the WTRU's on-duration on Uu. For example, the report may be sent when the first SL reception representing the WTRU's on-duration is received, while the WTRU did not receive any DL / SL grant from the network during the on-duration. For example, the report may be sent when the reception causes an activity timer to be reset. For example, the report may be sent when the reception causes an activity timer to be extended compared to what was indicated from the DL / SL scheduling.

[0119] The WTRU may report the arrival of sidelink data to be transmitted in the WTRU's SL TX buffer. For example, when the WTRU is operating in Mode 2 and RRC_CONNECTED, the WTRU may report the arrival of new data in the WTRU's SL TX buffer. For example, this reporting may be performed by the WTRU if the WTRU is currently in DRX with respect to Uu.

[0120] A WTRU may report its own activity behavior or any related parameters, either for itself or for a peer WTRU. For example, a WTRU may report its own on-duration, current SL DRX cycle, inactivity timer value, or similar parameters associated with another WTRU, which may be known from the other WTRU. For example, a WTRU may report an index associated with a resource pool corresponding to the activity behavior of a peer WTRU (e.g., received in PC5-RRC). For example, a WTRU may report changes to any of the above activity behavior parameters, such as a reset of a timer, a change in the SL DRX cycle, etc.

[0121] The WTRU may report that the WTRU enables / disables SL DRX. For example, the WTRU's upper layers may disable SL DRX at a certain time. The WTRU may report such events / indications to the network.

[0122] The WTRU may report events that may result in a change in SL activity behavior due to the relationship between the event and the defined SL activity behavior at the WTRU, such as: a CBR change by a preconfigured amount; a change in a sensing metric (e.g., the number or percentage of available resources, the average RSSI of resources in a sensing window, etc.); a change in the coverage status of a peer WTRU or WTRU group notified by another WTRU.

[0123] A WTRU may notify a peer WTRU or peer WTRU group of its activity on the Uu, such as changes in Uu activity. The WTRU may provide parameters or values related to the DRX state, indications of events that affect the scheduling period for PDCCH monitoring, etc. to the peer WTRU or peer WTRU group. The WTRU may send parameters related to the sidelink activity behavior that may be affected or changed by the Uu activity behavior. The WTRU may provide the information explicitly (e.g., in PC5-RRC, sidelink MAC CE, SCI, or in a dedicated control channel) or implicitly (e.g., derived from the results of another sidelink transmission).

[0124] The WTRU may send indications and / or parameters to a peer WTRU or peer WTRU group at any of the following times: upon reception of a DRX MAC CE for Uu received by the network; upon establishment of a unicast or multicast session or link with a peer WTRU or peer WTRU group; upon expiration, reset or start of a timer related to Uu DRX (such as an on-duration timer, an inactivity timer, a short cycle timer, etc.); upon reception or absence of a wake-up signal (WUS); upon configuration or reconfiguration of DRX parameters by Uu (e.g., receipt of an RRC reconfiguration, wherein DRX is (re)configured); upon receipt of a Uu schedule that resets the inactivity time.

[0125] The WTRU may include parameters of its Uu DRX configuration and / or active behavior in a PC5-RRC message after establishing a unicast link and / or when configuring an SLRB. The WTRU may include configured timers / parameters such as any of drx-onDurationTimer, drx-SlotOffset, drx-InactivityTimer, drx-RetransmissionTimerDL, drx-RetransmissionTimerUL, drx-LongCycleStartOffset, drx-ShortCycle, drx-ShortCycleTimer, drx-HARQ-RTT-TimerDL, drx-HARQ-RTT-TimerUL. The WTRU may include one or more SL DRX parameters (e.g., a selected DRX mode or resource pool or pool index that defines the WTRU's active behavior) that may be determined by the WTRU from the Uu DRX parameters.

[0126] The WTRU may trigger a PC5-RRC message when any of the above parameters are changed.

[0127] A WTRU may send an indication (e.g., via SCI, SL MAC CE, PC5-RRC) to a peer WTRU or group of peer WTRUs when it moves to DRX. For example, the WTRU may send this indication when a drx-InactivityTimer or drx-onDurationTimer expires without receiving DCI. For example, the WTRU may send this indication when it receives a DRX MAC CE.

[0128] The WTRU may perform an action, such as a change in an active behavior, upon receiving the active behavior.

[0129] The WTRU may report the above parameters or a subset of parameters to the network (e.g., in a Sidelink WTRU Information message or a WTRU Assistance Information message). For example, the WTRU may perform resource selection or reselection and may take the received information into account. For example, the WTRU may limit or prioritize resource selection among resources corresponding to the peer WTRU's On Duration on Uu (or a time period when the peer WTRU is expected to monitor the PDCCH). For example, the WTRU may exclude or de-prioritize resource selection among resources corresponding to the peer WTRU's Off Duration on Uu (or a time period when the peer WTRU is not expected to monitor the PDCCH).

[0130] The WTRU may select PSFCH transmission resources based on the activity behavior or state of the peer WTRU. For example, the WTRU may determine the PSFCH resources for HARQ feedback transmission based on whether the WTRU is actively monitoring the Uu PDCCH. For example, the WTRU may select PSFCH resources that fall within the active time of the peer WTRU based on the received activity behavior information.

[0131] The WTRU may determine whether to send a SL reconfiguration success / failure message based on whether the WTRU is configured with the same or similar DRX parameters on Uu and / or DRX. For example, the WTRU may compare the received DRX parameters with its own Uu DRX parameters and may trigger a SL reconfiguration failure based on a condition related to both configurations (e.g., the percentage of common timeslots for the on-duration is below a threshold).

[0132] The WTRU may adjust the timing of SL transmissions based on Uu DRX activity. In an embodiment, the WTRU may adjust the scheduling of its SL transmissions to ensure that such transmissions are time-aligned with the Uu activity. The WTRU may perform any of the following actions to align SL transmissions with the Uu DRX activity: perform resource selection by including only resources that fall within the WTRU's Uu active time (e.g., resources in the Uu On Duration); discard SL packets / transmissions when the WTRU's next Uu active time occurs after the delay required for the packet; perform resource reselection for SL transmissions when its active time on Uu is extended, for example, due to reception on the PDCCH.

[0133] The WTRU may receive an indication from the network as to whether SL monitoring is allowed or required. In one embodiment, the WTRU may receive an indication from the network to allow, enable, or disable SL monitoring for a defined time period and / or until the next indication is received. The time period may be pre-configured or indicated in the network indication. For example, the WTRU may receive a network indication (e.g., a DCI, MAC CE, or RRC message) that instructs the WTRU to start or stop SL monitoring from the time the indication is received and for a time period indicated in the indication itself. The time period may correspond to the WTRU Uu on-duration. For example, the WTRU may receive a network indication (e.g., a DCI, MAC CE, or RRC message) that indicates to the WTRU whether SL monitoring is to be performed during the WTRU Uu on-duration. In the absence of this signal during a given on-duration, the WTRU may monitor the PDCCH, but may not monitor the PSCCH during the next or current on-duration of the Uu. In the presence of this signal, the WTRU may monitor both the PDCCH and the PSCCH during the next or current on-duration of the Uu. For example, the signal may be transmitted in conjunction with a wake-up signal for the Uu. The WTRU may receive two separate indications during the wake-up signal timing, such as a Uu wake-up signal and a SL wake-up signal. If the WTRU receives both the SL wake-up signal and the UL wake-up signal, then the WTRU may perform both PSCCH decoding and PDCCH decoding during the on-duration. If the WTRU receives only the SL (UL) wake-up signal, then the WTRU may perform only PSCCH (PDCCH) decoding during the on-duration.

[0134] The WTRU may be configured with a subset of the Uu OnDuration for monitoring specific L2 IDs / services. In one embodiment, the WTRU may receive a configuration that maps a portion of the Uu OnDuration or Active Time to one or a group of L2 IDs or services. The L2 ID may represent the identity of a group of sidelink WTRUs. Based on the configuration, the WTRU may determine whether to perform monitoring and / or SL monitoring and / or SL transmission of SL-RNTI associated with a specific L2 ID in a portion of the OnDuration, if allowed. The OnDuration may be subdivided into N portions. If the WTRU has a transmission or expected reception for one or more L2 IDs associated with the nth portion (based on upper layer configuration), the WTRU may determine whether to perform SL monitoring in the nth portion of the OnDuration. If the WTRU is not interested in any L2 ID configured for the nth portion, the WTRU may perform Uu PDCCH decoding only in the nth portion of the OnDuration. The advantage of this solution is that it further restricts the transmissions associated with one or more L2 IDs to occur within a subset of resources in the OnDuration, thereby limiting the blind decoding of Uu and SL monitoring of the PSCCH for the WTRU that may be interested in the subset of services. The WTRU may also restrict the selected destinations (e.g., during the LCP procedure) to transmit within the nth portion of the OnDuration to those within the network SL grants, such that only the allowed destinations for that portion may be selected.

[0135] A method is disclosed for allowing UL and SL DRX to operate independently of each other. A WTRU may be configured to perform independent Uu PDCCH decoding and PSCCH decoding based on independent SL and UL DRX states. The WTRU may be configured with an active behavior for the sidelink or a set of sidelink DRX parameters that are independent of the parameters configured for the Uu. The WTRU may perform the following operations on the Uu and SL channels in each of the following scenarios. If the timeslot is within the Uu active time but outside the SL active time: the WTRU may perform PDCCH decoding on RNTIs other than the SL-RNTI; the WTRU may not perform PSCCH decoding; and the WTRU may perform PSFCH decoding and / or transmit. If the timeslot is within the SL active time but outside the Uu active time: the WTRU may perform PDCCH decoding only on the SL-RNTI; the WTRU may perform PSCCH decoding; and the WTRU may decode and / or transmit on the PSFCH. If the timeslot is within both SL active time and UL active time: the WTRU may perform PDCCH decoding for both UL / DL and SL RNTI; the WTRU may perform PSCCH decoding; and the WTRU may perform PSFCH decoding and / or transmission.

[0136] The WTRU may perform independent maintenance of SL / UL related counters or timers based on events associated with each scenario. If the WTRU receives a PDCCH indicating a new SL transmission or receives / decodes a SL SCI from the PSCCH, the WTRU may reset the inactivity timer associated with the SL DRX. The WTRU may determine its OnDuration for the SL based on the SL-specific DRX cycle, the SL-specific DRX offset, and the SL-specific OnDuration timer, which is defined as the period during which the WTRU decodes the SL and / or UL for SL allocation.

[0137] The WTRU may receive a network-scheduled SL grant only during active PDCCH decoding on Uu. This SL DCI may apply to a future time. In one embodiment, the WTRU may receive a network-scheduled SL grant only during Uu DRX active time. The WTRU may apply the grant at a time during the next SL active period determined by SL DRX. The WTRU may determine the timing of the SL grant within the SL active period, explicitly in the grant itself, or implicitly based on any one or a combination of the following: the timing of receiving the SL grant within the Uu active period; QoS, L2 destination ID; the frequency / subchannel resources associated with the SL grant; the MCS or MCS range in the SL grant.

[0138] The SL grant may include an indication of whether the WTRU should apply the SL grant immediately or within the next SL activity period. The SL grant may include a slot offset, which may correspond to the offset from the start of the SL activity period to which the SL grant should be applied. The WTRU may implicitly apply the SL grant to the slot offset within the SL activity period, whereby the slot offset may correspond to the slot offset within the Uu activity period in which the SL grant was received.

[0139] Dynamic determination of a DRX configuration for PDCCH monitoring is disclosed. A WTRU may be configured with one or more DRX configurations. A first DRX configuration may be used or applicable for DCI scheduling Uu (e.g., downlink or uplink), and a second DRX configuration may be used or applicable for DCI scheduling sidelink (e.g., NR V2X Mode 1). A DRX configuration may be associated with an RNTI. For example, one or more DRX configurations may be configured, and each DRX configuration may be associated with an RNTI, which may be a CRC scrambled with the DCI. The WTRU may monitor a PDCCH carrying DCI with a first RNTI based on the first DRX configuration, and the WTRU may monitor a PDCCH carrying DCI with a second RNTI based on the second DRX configuration. The DRX configuration for Uu may be determined based on the operating mode of the sidelink. For example, when the WTRU operates the sidelink in Mode 1, the first DRX configuration for Uu may be used, and when the WTRU operates the sidelink in Mode 2, the second DRX configuration for Uu may be used. Mode 1 may be referred to as network-inside downlink operation, and Mode 2 may be referred to as network-outside downlink operation.

[0140] The WTRU may be configured with one or more DRX configurations for Uu (e.g., downlink and / or uplink). The DRX configuration may be determined based on whether the DRX configuration for the sidelink is activated. For example, a first DRX configuration may be used when sidelink DRX is activated, and a second DRX configuration may be used when sidelink DRX is deactivated. The DRX configuration may be determined based on the sidelink operation mode. For example, one or more sidelink operation modes may be used, including a normal power consumption mode and a power saving mode. When the sidelink operation mode is the normal power consumption mode, a first DRX configuration may be used for Uu, and when the sidelink operation mode is the power saving mode, a second DRX configuration may be used for Uu. The DRX configuration may be determined based on the sidelink traffic type. The DRX configuration may be determined based on the worst-case QoS expected for the sidelink traffic. The DRX configuration may be determined based on the service type of the sidelink. The DRX configuration may be determined based on the broadcast type of the sidelink (e.g., broadcast, unicast, multicast). The DRX configuration may be determined based on the WTRU speed (e.g., absolute speed or relative speed).

[0141] When both Uu and sidelink are in the off duration, the WTRU may skip monitoring PDCCH. The WTRU may be configured with a first DRX configuration for Uu and a second DRX configuration for the sidelink. The first DRX configuration may be the same as or different from the second DRX configuration. If the WTRU is not in active time for the first DRX configuration and / or the second DRX configuration, the WTRU may skip monitoring PDCCH in the timeslot. The time when the WTRU is not in active time may be referred to as inactive time. Inactive time may be used interchangeably with off duration, off time, no PDCCH monitoring time, inactive timeslot, sleep time, and sleep duration. When the WTRU is in inactive time for all configured DRX configurations, the WTRU may skip monitoring. For example, if the WTRU is in the inactive time of a timeslot, the timeslot may be within the time window of the first DRX configuration and the second DRX configuration. Otherwise, the WTRU may monitor PDCCH.

[0142] Receive activity at a WTRU based on explicit signaling is disclosed. Power saving behavior at the WTRU may be explicitly signaled by a transmission indicating desired / expected behavior. The WTRU may receive a sidelink transmission that may indicate a change in the activity state of the WTRU or a group of WTRUs. In one embodiment, the WTRU may receive an explicit transmission on a sidelink that may change the activity state of the WTRU. The WTRU may perform any of the following operations upon receiving an explicit transmission. Upon receiving an explicit transmission, the WTRU may switch from a receive resource pool that monitors an SCI to a receive resource pool that does not monitor an SCI, or vice versa. Upon receiving an explicit transmission, the WTRU may change the receive resource pool on which the WTRU monitors an SCI. For example, the WTRU may switch from monitoring a first receive pool before receiving a sidelink transmission to monitoring a second receive pool after receiving the sidelink transmission. Upon receiving an explicit transmission, the WTRU may switch from monitoring a receive pool with one activity behavior (e.g., a first set or percentage of time and / or frequency resources) to a second activity behavior (e.g., a second set or percentage of time and / or frequency resources). Upon receiving an explicit transmission, the WTRU may change one or more parameters associated with the activity behavior, as defined herein. Upon receiving an explicit transmission, the WTRU may change one or more parameters related to sensing, such as increasing or decreasing the sensing window, increasing or decreasing the amount of resources on which the WTRU performs sensing, applying or not applying sensing to a particular set or pool of resources. Upon receiving an explicit transmission, the WTRU may perform PSCCH decoding within a time period associated with the validity of the activity status change indication, such as performing the decoding for a particular L1 / L2 ID on a (pre-)configured or (pre-)defined set of resources. For example, the activity status change indication may further indicate whether the WTRU should monitor the sidelink relative to the schedule indicated by the scheduled activity determination within the next X seconds, where X seconds may be the periodicity of the activity status indication transmission.

[0143] Any of the above information (e.g., the specific activity state to be transitioned to or the parameters to be applied) may be implicitly or explicitly included in the transmission itself. For example, the activity state change transmission may include an indication that the WTRU is entering or moving out of a power saving state or changing the activity state. The activity state change transmission may include a set of resources to which the indicated activity state should apply. For example, the transmission may include a starting time slot or time from which the activity state should be changed. For example, the transmission may include a set of resources (e.g., a time period or resource pool) on which a specific activity state (e.g., regular monitoring of sidelink resources, reduced power monitoring of a sidelink resource pool, periodic collection of sensing results) should be applied. The activity state change transmission may include a new period and / or offset to be applied to a periodic activity state. The activity state change transmission may include a set of resources (new set or new resources) on which to monitor, such as an activity state change signal. For example, the WTRU may determine the resource pool to be monitored based on an indication of the resource pool in the activity state change indication. For example, the WTRU may determine the time / frequency resource to be monitored (e.g., DRX cycle, on-duration, etc.) based on an indication of the time / frequency resource in the activity state change indication. The activity state change transmission may include the duration of the new activity state being applied (e.g., how long the indicated receiving WTRU should remain in normal reception mode). Such duration may be (pre)configured or (pre)determined (i.e., the WTRU may remain in normal reception mode for a period of time X after receiving the activity state indication). The activity state change transmission may include the group to which the activity state change indication applies.

[0144] The WTRU may monitor for activity state change transmissions in a defined set of time / frequency resources. The WTRU may be (pre-)configured with a set of sidelink time / frequency resources on which to monitor for activity state change signals / transmissions. The (pre-)configured resources may be a (pre-)configured sidelink resource pool. For example, the WTRU may be (pre-)configured with a sidelink resource pool in which to send and / or receive activity state change signals. Such a resource pool may be reserved for transmitting activity state change transmissions. The (pre-)configured resources may be a (pre-)defined or (pre-)configured set of time slots and / or subchannels within a receive resource pool that is also used for data. For example, the WTRU may be (pre-)configured with a set of time slots within a resource pool in which the WTRU may expect to receive activity state change transmissions. The (pre-)configured resources may be a (pre-)defined or (pre-)configured set of time slots and / or subchannels relative to the received control / data transmissions. For example, a WTRU may be (pre-)configured to monitor activity state change transmissions in a sub-channel / time slot located in a time / frequency resource relative to past or future data transmissions of another WTRU or relative to future reserved resources of another WTRU.

[0145] Receipt of an activity state change transmission may be targeted to a subset of WTRUs. An activity state change transmission may be targeted to a group or subset of WTRUs. The transmission may result in a change in activity state for: a specific group of WTRUs, as indicated by the L2 ID or L1 ID associated with the group; a specific WTRU in a unicast link, as indicated by the destination L2 ID or L1 ID of the unicast link; a specific broadcast service, as indicated by the L2 ID associated with the broadcast service or an L1 ID derived from the L2 ID; or a set of WTRUs configured with common activity state parameters, such as all WTRUs configured to monitor for activity state change transmissions on a specific resource pool, set of time / frequency resources, etc.

[0146] A change in the activity state of one group of WTRUs may change the activity of all groups. The WTRU may determine its overall activity state (e.g., sidelink monitoring, sensing behavior, etc.) based on an activity state change indication of at least one L2 of interest. Upon receiving an activity state change indication for a particular group, the WTRU may change its activity behavior for all groups / transmissions. For example, the WTRU may be in a first activity state (e.g., monitoring only for activity state indications) and may receive an indication to transition to normal / regular monitoring / reception. The WTRU may then perform sidelink PSCCH channel monitoring for all L1 IDs after receiving the indication.

[0147] A change in the activity state of a group of WTRUs may change the activity relative to the group. The WTRU may determine its activity state (e.g., sidelink monitoring, sensing behavior, etc.) for each of its L2 IDs / L1 IDs of interest based on an activity state indication specific to that L2 / L1 ID. For example, upon receiving an activity state change indication (e.g., monitoring only activity state indication) during a first activity state, the WTRU may perform sidelink PSCCH channel monitoring only for the associated L1 ID (i.e., it may perform control channel decoding only for the L1 IDs for which regular monitoring is already allowed). The WTRU may continue to not monitor the other L1 IDs in the WTRU set of the L1 ID of interest, and monitoring of these L1 IDs may be further subject to receiving another activity state change indication.

[0148] Signaling of an activity state change indication. An activity state change may include a transmission addressed only to the WTRU to which it is intended. An activity state change may be addressed to a globally known / (pre-)configured destination ID and may include the intended WTRU or group of WTRUs within the transmission content. An activity state change transmission may include any of the following. An activity state change transmission may include an SCI-only transmission addressed to an identifier (e.g., an L1 ID or L2 ID) of a subset of WTRUs to which it applies. The SCI itself may have an indicator that further identifies the new activity to be applied. For example, a first-level SCI or a second-level SCI may include an index to the intended activity state. The SCI itself may have an indicator that identifies that the transmission (i.e., the SCI transmission) is an activity state change indication. For example, a first-level SCI or a second-level SCI may have an explicit bit that indicates that the SCI (and possibly an associated PSSCH transmission) is associated with an activity state change indication. The SCI may have an indication of the time / frequency resources in which the state change may be applied. For example, a first-level SCI may carry an indicator marking the SCI as indicating a change in activity state, and the associated resource allocation may indicate the time / frequency resources associated with the start / end of the activity state change. The activity state change transmission may comprise an SCI-only transmission addressed to a globally unique L1 ID and including the L1 ID of the WTRU or group to which the activity state change may apply. For example, the activity state change and the identification of the WTRU to which it applies (e.g., L1 / L2 group ID) may be carried in a second-level SCI, where the first-level SCI may include a globally unique identifier. For example, the activity state change indication may be carried in the first-level SCI, and the second-level SCI may carry the L1 ID to which the activity state change applies. The activity state change transmission may comprise an SCI transmission that additionally reserves resources for data transmission. For example, the activity state change may include the indicator in the first-level SCI. The activity state change transmission may comprise an SL MAC CE or SL RRC message that includes an identifier (e.g., L1 ID or L2 ID) of the subset of WTRUs to which it applies.

[0149] In one embodiment, an activity state change transmission may indicate a change in the transmission state of a set of WTRUs that are configured to receive a specific L2 / L1 ID. For example, a WTRU may be configured to receive sidelink transmissions associated with a specific L2 / L1 ID (e.g., a multicast destination or broadcast service). The WTRU may operate in an active state (i.e., performing sidelink monitoring only on resources that may include an activity state change). Upon receiving an activity state change transmission indicating a specific L2 / L1 ID, the WTRU may change its activity state to a second state (i.e., monitoring all sidelink resources in the resource pool). If the WTRU is not configured to receive the specific L2 / L1 ID indicated in the activity state change transmission, it may not change its activity state upon receiving the indication.

[0150] A WTRU may relay an activity state change transmission received from another WTRU. In one embodiment, a WTRU may be configured to transmit an activity state change indication upon receiving an activity state change transmission from another WTRU. For example, such behavior may be used to avoid half-duplex issues associated with the reception of a state change indication and / or misdetection of an activity state change indication (e.g., due to fading or the physical distance spanned by a group of WTRUs). A WTRU that receives an activity state change indication in a set of dedicated resources (e.g., time / frequency resources or a resource pool) may also transmit the indication in the same set of resources. The WTRU may perform transmission of an activity state change indication upon receiving an activity state change under certain conditions. For example, the WTRU may transmit the activity state change indication after receiving the activity state change under any one or any combination of the following conditions. The WTRU may perform transmission of the activity state change indication under the condition that the L1 / L2 ID associated with the activity state change indication matches one of the L1 / L2 IDs that the WTRU is interested in receiving / transmitting. The WTRU may perform transmission of the activity state change indication under the condition that the WTRU is configured by upper layers to retransmit or relay the activity state indication. The WTRU may perform transmission of an activity state change indication if the received power / energy associated with the received activity state change indication is below a (pre-)configured or (pre-)defined threshold. Depending on upper layers, the WTRU may perform transmission of an activity state change indication if the L1 / L2 ID associated with the activity state change indication is associated with a specific type of group and / or group size. For example, the WTRU may perform such transmission if the group size associated with the L1 / L2 ID is known / unknown and / or above / below a threshold. The WTRU may perform transmission of an activity state change indication if the timing of receiving the activity state change indication meets specific criteria. For example, the WTRU may be configured with a time window for receiving the activity state change indication and may relay the indication if the indication is received within the first X time slots of the time window. The WTRU may perform transmission of an activity state change indication if the measured congestion of the resource that may be associated with the transmission of the activity state change indication meets certain criteria. For example, the WTRU may be configured with a threshold CBR above / below which it will relay the indication.

[0151] A WTRU may adjust its activity behavior based on the sensing results received from a peer WTRU. In an embodiment, a transmitting WTRU may send its sensing and / or resource allocation information to a peer WTRU via an RRC or MAC CE. This information may include one or any combination of the following: a set of subframes and / or subchannel resources used for resource selection; a set of subframes and / or subchannels used for sensing for the purpose of resource selection; the set selecting resources for subsequent transmissions. Based on this information, the receiving WTRU may adjust its reception activity, such as DRX configuration or sensing resources. The transmitting WTRU may determine to send its sensing and resource allocation information periodically and / or based on one or any of the following triggers: the WTRU performs resource (re)selection; the CBR is greater than and / or less than a threshold; the WTRU receives a grant (e.g., from a gNB or peer WTRU). For example, in V2X, when the transmitting WTRU determines to perform resource reselection for a sidelink process for a unicast service, it may send the set of subframes used for resource selection to the receiving WTRU in the next period. The receiving WTRU may change its sensing subframe accordingly to monitor the data from the transmitting WTRU.

[0152] Figure 4 An example method 400 implemented in a first WTRU is shown. At 402, the first WTRU may receive a SL grant on the Uu. At 404, the first WTRU may determine a value for a timer, wherein the timer defines an active time on the Uu based on one or more attributes of the SL data. At 406, the first WTRU may monitor for PDCCH transmissions during the Uu active time on the Uu.

[0153] In one embodiment, a first WTRU may determine its Uu Active Time relative to SL activity between it and a second WTRU to signal a retransmission to the second WTRU. To make this determination, the first WTRU may receive a SL grant during the Uu Active Time. The first WTRU may transmit SL data to the second WTRU based on the SL grant. The first WTRU determines a value for a timer that defines an active time for retransmissions based on one or more attributes of the SL data. During the Uu Active Time, the first WTRU may monitor PDCCH transmissions associated with the Uu.

[0154] In one example, the timer may be an inactivity timer. If the timer is an inactivity timer, the Uu active time may be based on the priority of the SL data. For example, higher priority data will receive a longer Uu active time than lower priority data. In another example, the timer may be a retransmission timer, which may be started when the WTRU reports SL HARQ feedback over Uu. In one embodiment, the WTRU may reset the timer each time an additional SL grant is received. Additionally, one or more attributes of the SL data may be a function of the remaining PDB of the SL data.

[0155] Although features and elements are described above in particular combinations, it will be understood by those skilled in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, WTRU, terminal, base station, RNC, or any host computer.

Claims

1. A discontinuous reception (DRX) method for use in a wireless transmit / receive unit (WTRU) configured for sidelink (SL) communication, the method comprising: receiving SL DRX configuration information from a peer SL WTRU, wherein the SL DRX configuration information includes timer information, wherein the timer information includes at least a SL on-duration timer, a SL inactivity timer, a SL hybrid automatic repeat request (HARQ) round trip time (RTT) timer, and a SL HARQ retransmission timer; accepting the received SL DRX configuration information; and Under the condition that the WTRU has a radio resource control (RRC) connection to the base station, a message is sent to the base station, wherein the message indicates that the WTRU accepts the received SL DRX configuration information from the peer SL WTRU, wherein the message is sent in an RRC information element, and wherein the message indicates that the accepted SL DRX configuration information includes at least the SL on duration timer and the SL DRX time slot offset.

2. The method according to claim 1, wherein The accepting the received SL DRX configuration information includes applying the received SL DRX configuration information.

3. The method according to claim 2, wherein: The SL DRX configuration information received by the application includes setting SL activity behavior.

4. The method according to claim 1, wherein The accepting the received SL DRX configuration information includes setting a SL active time value.

5. The method according to claim 1, further comprising: A second message is transmitted to the peer SL WTRU in response to the accepted SL DRX configuration information, wherein the second message indicates that the WTRU accepted the received SL DRX configuration information.

6. The method of claim 1, wherein the WTRU receives the SL DRX configuration information via PC5 signaling.

7. The method of claim 1 , wherein the WTRU maintains separate timers associated with Uu DRX and SLDRX.

8. The method of claim 1, wherein the message to the WTRU accepting the SL DRX configuration information is sent in a SL information element.

9. A wireless transmit / receive unit (WTRU) configured for sidelink (SL) communication, the WTRU comprising: transceiver; and a processor, wherein: The transceiver is configured to receive SL discontinuous reception (DRX) configuration information from a peer SL WTRU, wherein the SL DRX configuration information includes timer information, wherein the timer information includes at least a SL on-duration timer, a SL inactivity timer, a SL hybrid automatic repeat request (HARQ) round trip time (RTT) timer, and a SL HARQ retransmission timer; and The transceiver is further configured to send a first message to the base station under a condition that the processor determines to accept the received SLDRX configuration information and at least partially based on a condition that the WTRU has a radio resource control (RRC) connection to the base station, wherein the first message indicates that the WTRU accepts the received SLDRX configuration information from the peer SLWTRU, wherein the first message is sent in an RRC information element, and wherein the first message indicates that the accepted SL DRX configuration information includes at least the SL on duration timer, and the SL DRX time slot offset.

10. The WTRU of claim 9, wherein the processor is configured to accept the received SL DRX configuration information by applying the received SL DRX configuration information.

11. The WTRU of claim 10, wherein the processor is further configured to apply the received SL DRX configuration information by setting a SL active behavior.

12. The WTRU of claim 9, wherein the processor is further configured to accept the received SL DRX configuration information by setting a SL active time value.

13. The WTRU of claim 9, wherein the transceiver is further configured to transmit a second message to the peer SL WTRU in response to the accepted SL DRX configuration information, wherein the second message indicates that the WTRU accepts the received SL DRX configuration information.

14. The WTRU of claim 9, wherein the transceiver is further configured to receive the SL DRX configuration information via PC5 signaling.

15. The WTRU of claim 9, wherein the WTRU maintains separate timers associated with Uu DRX and SL DRX.

16. The WTRU of claim 9, wherein the transceiver is further configured to send the first message that the WTRU accepts the DRX configuration information in a SL information element.

Images