Systems, methods, and devices associated with GNB offloading of SL scheduling

Abstract

Systems, methods, and instrumentalities are described herein related to WTRUs and / or group-based services. A wireless transmit / receive unit (WTRU) may include a processor. The WTRU may be configured to determine that data is available for sidelink transmission. The WTRU may determine a sequence based on a property of the data. The WTRU may determine a sidelink resource based on a mapping associated with the sidelink scheduling request (SL-SR). The WTRU may send the SL-SR via the determined sidelink resource. The WTRU may receive a sidelink grant to use the sidelink resource. The WTRU may determine that the sidelink grant is smaller than a threshold. The WTRU may determine that a group coordinator (GC) is an intended receiver of a transmission. The WTRU may include an indication of a buffer status associated with the WTRU in the transmission. The WTRU may send the transmission via the sidelink resource.

Description

SYSTEMS, METHODS, AND DEVICES ASSOCIATED WITH GNB OFFLOADING OF SL SCHEDULINGCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 553,800, filed February 15, 2024, the contents of which is incorporated by reference herein.BACKGROUND

[0002] Mobile communications using wireless communication continue to evolve. A fifth generation may be referred to as 5G. A previous (legacy) generation of mobile communication may be, for example, fourth generation (4G) long term evolution (LTE).SUMMARY

[0003] Systems, methods, and devices are described herein that may be associated with gNB offloading of sidelink (SL) scheduling, which may in some examples be related to new radio (NR) target gNB aggregate (TAGG). A wireless transmit / receive unit (WTRU) may include one or more of the following: a processor, a memory, or a transceiver (e.g., a transmitter and / or receiver). The WTRU may be configured to perform one or more of the following. The WTRU may determine that data is available for sidelink transmission. The WTRU may determine a sequence based on a property of the data. The sequence may be associated with a sidelink scheduling request (SL-SR). The WTRU may determine a sidelink resource based on a mapping associated with the SL-SR. The WTRU may send the SL-SR via the determined sidelink resource. The WTRU may receive a sidelink grant to use the sidelink resource. The WTRU may determine that the sidelink grant is smaller than a threshold. The WTRU may determine that a group coordinator (GC) is an intended receiver of a transmission. The WTRU may (e.g., based on the determination that the sidelink grant is smaller than the threshold and / or the determination that the GC is an intended receiver of the transmission), include an indication of a buffer status associated with the WTRU in the transmission. The WTRU may send the transmission via the sidelink resource. At least a portion of the data may be sent via the transmission.

[0004] A method may include one or more of the following. The method may include determining that data is available for sidelink transmission. The method may include determining a sequence based on a property of the data. The sequence may be associated with a SL-SR. The method may include determininga sidelink resource based on a mapping associated with the SL-SR. The method may include sending the SL-SR via the determined sidelink resource. The method may include receiving a sidelink grant to use the sidelink resource. The method may include determining that the sidelink grant is smaller than a threshold. The method may include determining that a GC is an intended receiver of a transmission. The method may include (e.g., based on the determination that the sidelink grant is smaller than the threshold and / or the determination that the GC is an intended receiver of the transmission) including an indication of a buffer status associated with the WTRU in the transmission. The method may include sending the transmission via the sidelink resource. At least a portion of the data may be sent via the transmission.

[0005] The WTRU and / or a method may include one or more features. For example, the indication of the buffer status may be indicated via a sidelink medium access control element (SL-MAC CE), a sidelinkbuffer status request (SL-BSR), or a sidelink dynamic scheduling request (SL-DSR). The SL-SR may include an indication of at least one of a range of a number of protocol data units (PDUs) in a buffer, a range of a number of requested resources, a range of priorities associated with data in the buffer, or a range of PDU set delay budgets (PSDBs) associated with data in the buffer. The transmission may include a request for a second sidelink resource. The threshold may be associated with a number of PDUs in a buffer associated with the WTRU. The property of the data may include at least one of a quality of service (QoS) associated with the data or a quantity of the data. The data available for sidelink transmission may include a PDU or a reference-signal. The SL-SR may include an indication of whether the data comprises a PDU or a reference signal.

[0006] Systems, methods, and instrumentalities are described herein related to offloading sensing, resource allocation, and scheduling of WTRUs in group-based services from the network.

[0007] A WTRU (e.g., a member WTRU of a group) may (e.g., be configured to) perform one or more actions. The WTRU may determine that data is available for sidelink transmission (e.g., multi-bit SL-SR transmission). The WTRU may determine a sequence based on a property of the data (e.g., an amount of data and / or a QoS of the data). The sequence may be associated with a SL-SR. The WTRU may determine a sidelink resource based on a mapping associated with the SL-SR (e.g., a mapping between SL-SR resources and sidelink resources). The WTRU may receive a sidelink grant to use the determined sidelink resource. The WTRU may send a transmission via the determined sidelink resource. A portion of the data may be sent via the transmission.

[0008] The WTRU may determine that the received sidelink grant is insufficient to transmit the data available for sidelink transmission. The WTRU may, based on the determination that the received sidelink grant is insufficient, send the SL-SR to a GC. The SL-SR may indicate a request for an additional sidelink resource associated with transmission of the data. The determination that the received sidelink grant isi insufficient to transmit the data available for sidelink transmission may be based on a buffer size associated with the data available for sidelink transmission.

[0009] The WTRU may determine that the received sidelink grant is insufficient to transmit the data available for sidelink transmission and / or that a GC is an intended receiver of the transmission. The WTRU may, based on the determination that the GC is the intended receiver of the data and based on the determination that the received sidelink grant is insufficient, send an indication to the GC that indicates a request for an additional sidelink resource associated with transmission of the data.

[0010] The indication of the request for an additional sidelink resource may comprises an indication of buffer information. The indication of the request for an additional sidelink resource may be sent via SL-MAC CE, a SL-BSR, or a SL-DSR.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

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

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

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

[0015] FIG. 2 depicts an example of a gNB controlling a group of WTRUs.

[0016] FIG. 3 depicts an example determination of which resource to transmit a resource request message to, based on expected transmission resources.

[0017] FIG. 4 depicts an example determination of which resource to transmit group-scheduling message on based on the associated scheduled resources.

[0018] FIG. 5 depicts an example use of a first period to reserve periodic resource for a group.

[0019] FIG. 6 depicts an example use of a first resource to reserve a set of resources for a group.

[0020] FIG. 7 depicts an example of a WTRU being triggered to send an indication of resource usage to the network.DETAILED DESCRIPTION

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

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

[0023] The communications systems 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 / 115, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a 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 beappreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0024] The base station 114a may be part of the RAN 104 / 113, 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. The base station 114a and / or the 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 coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0025] 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).

[0026] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). 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 UL Packet Access (HSUPA).

[0027] 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).

[0028] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 116 using New Radio (NR).

[0029] 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 LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., a eNB and a gNB).

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

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

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

[0033] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit- switched telephone networks that provide 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), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communications 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 / 113 or a different RAT.

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

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

[0036] 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 in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0040] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), 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).

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

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

[0043] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

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

[0046] 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 one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

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

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

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

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

[0051] 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.

[0052] 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 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. Inaddition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

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

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

[0055] 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 an access or an interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic in to and / or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and / or referred to as peer-to- peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11 z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an “ad- hoc” mode of communication.

[0056] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

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

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

[0059] Sub 1 GHz modes of operation are supported by 802.11af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11 ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0060] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

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

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

[0063] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

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

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

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

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

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

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

[0070] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, 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. The UPF 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 downlink packets, providing mobility anchoring, and the like.

[0071] The CN 115 may facilitate communications with other networks. For example, the CN 115 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 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local Data Network (DN) 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

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

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

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

[0075] Systems, methods, and devices are described herein that may be associated with gNB offloading sidelink (SL) scheduling, which may in some examples be related to NR target gNB aggregate (TAGG). A WTRU may include one or more of the following: a processor, a memory, or a transceiver (e.g., a transmitter and / or receiver). The WTRU may be configured to perform one or more of the following. The WTRU may determine that data is available for sidelink transmission. The WTRU may determine a sequence based on a property of the data. The sequence may be associated with a sidelink scheduling request (SL-SR). The WTRU may determine a sidelink resource based on a mapping associated with the SL-SR. The WTRU may send the SL-SR via the determined sidelink resource. The WTRU may receive a sidelink grant to use the sidelink resource. The WTRU may determine that the sidelink grant is smaller than a threshold. The WTRU may determine that a group coordinator (GC) is an intended receiver of a transmission. The WTRU may (e.g., based on the determination that the sidelink grant is smaller than the threshold and / or the determination that the GC is an intended receiver of the transmission), include an indication of a buffer status associated with the WTRU in the transmission. The WTRU may send the transmission via the sidelink resource. At least a portion of the data may be sent via the transmission.

[0076] A method may include one or more of the following. The method may include determining that data is available for sidelink transmission. The method may include determining a sequence based on a property of the data. The sequence may be associated with a SL-SR. The method may include determining a sidelink resource based on a mapping associated with the SL-SR. The method may include sending the SL-SR via the determined sidelink resource. The method may include receiving a sidelink grant to use the sidelink resource. The method may include determining that the sidelink grant is smaller than a threshold. The method may include determining that a GC is an intended receiver of a transmission. The method may include (e.g., based on the determination that the sidelink grant is smaller than the threshold and / or the determination that the GC is an intended receiver of the transmission) including an indication of a buffer status associated with the WTRU in the transmission. The method may include sending the transmission via the sidelink resource. At least a portion of the data may be sent via the transmission.

[0077] The WTRU and / or a method may include one or more features. For example, the indication of the buffer status may be indicated via a sidelink medium access control element (SL-MAC CE), a sidelinkbuffer status request (SL-BSR), or a sidelink dynamic scheduling request (SL-DSR). The SL-SR may include an indication of at least one of a range of a number of protocol data units (PDUs) in a buffer, a range of a number of requested resources, a range of priorities associated with data in the buffer, or a range of PSDBs associated with data in the buffer. The transmission may include a request for a second sidelink resource. The threshold may be associated with a number of PDUs in a buffer associated with the WTRU. The property of the data may include at least one of a QoS associated with the data or a quantity of the data. The data available for sidelink transmission may include a PDU or a reference-signal. The SL-SR may include an indication of whether the data comprises a PDU or a reference signal.

[0078] A WTRU (e.g., a member WTRU of a group) may (e.g., be configured to) perform one or more actions. The WTRU may obtain data for sidelink transmission (e.g., multi-bit SL-SR transmission). The WTRU may determine a sequence to transmit a SL-SR transmission based on a property of the data (e.g., an amount of data, or a QoS of the data). The WTRU may determine a sidelink resource based on a mapping between SL-SR and the sidelink resources. The WTRU may receive a sidelink grant to use the determined sidelink resource. The WTRU may transmit, via the determined sidelink resource, the sequence in the sidelink grant.

[0079] The WTRU may determine whether a size of the sidelink grant is smaller than a buffer size of the data. The WTRU may, based on a determination that the size of the sidelink grant is smaller than the buffer size of the data, send a SL-SR to request additional sidelink grant. The WTRU may, based on a determination that the size of the sidelink grant is smaller than the buffer size of the data, determine whether a GC is an intended receiver of the data, and based on a determination that the GC is an intended receiver of the data, may send a SL-SR to request additional sidelink grant, wherein the request includes buffer information of the data.

[0080] Applications for 5G and beyond may expand in many vertical directions, such as extended reality (XR), industrial internet of things (loT), intelligent transportation systems, etc. These scenarios may impose new service requirements with reasonable resource and power efficiency, such as ultra-high uplink (UL) data rate, ultra-low latency, and high reliability. Some services such as XR, virtual reality (VR)Zaugmented reality (AR), and metaverse services may require a tight synchronization among data flows from different devices (e.g., gloves, glasses, etc.) running an (e.g., a single) application layer. The conventional cellular network managing a service per WTRU basis may not be sufficient to guarantee the more stringent requirement(s) of multiple devices (e.g., simultaneously).

[0081] In a system, the network may control a group of WTRUs running an application involving interaction among multiple WTRUs in the group. The group may have the GC and member WTRU(s). It may be expected that a group may have more information of the group than the gNB. Such information may include the channel condition among WTRUs in the group, QoE / QoS requirement, transmission alignment, and / or buffer status of a WTRU (e.g., each WTRU) in the group.

[0082] FIG. 2 depicts an example of a gNB controlling a group of WTRUs, in which a WTRU (e.g., each WTRU) is running an application (e.g., requiring a tight interaction among WTRUs). As shown in FIG. 2, the gNB may control the group of WTRUs. A WTRU (e.g., a WTRU in the group) may be a main WTRU (e.g., a GC) and / or an assistant WTRU, in which the main WTRU may coordinate some transmission / reception activity of the WTRUs in the group. A WTRU in the group (e.g., each WTRU in the group) may be running an application requiring the tight interaction among WTRUs. For example, the signal (e.g., a PDU, a reference-signal, and / or the like) transmission of one WTRU may be correlated and / or associated with the signal transmission of one or more other WTRUs (e.g., WTRUs in the group).

[0083] In applications which may require the WTRUs in the group to interact for signal transmission and / or reception (e.g., group-based applications), it may be beneficial for the gNB to offload some functionality to a WTRU in the group (e.g., one of the WTRUs in the group), such as scheduling offloading. The GC may solicit information of one or more member WTRUs in the group (e.g., traffic information, channel condition information, and / or the like), for example to reduce signaling overhead between the gNB and WTRUs (e.g., all WTRUs) in the group. The GC may interact with the gNB regarding the information of the member WTRU(s) in the group. Such an approach may help reduce Uu signaling overhead and / or coordinate signal transmissions of the WTRUs in the group. In gNB offloading for SL scheduling, the gNB may offload the SL scheduling to a GC, as the GC may have more information of the group as compared to the gNB. For example, the gNB may offload the scheduling of sidelink resource(s) to the GC. The sidelink resource used for the group may be scheduled by the network (e.g., mode 1 -like resource) and / or selected by the GC (e.g., mode 2-like resources).

[0084] The GC may perform sensing, resource allocation, and / or scheduling for the group considering both initial transmission and hybrid automatic repeat request (HARQ)-retransmission. The GC may report sidelink resource usage to the gNB, for example to support the network in providing (e.g., guaranteeing) the QoS for the group (e.g., because the gNB may not be aware of a sidelink transmission situation as it is not the receiver of any sidelink transmission).

[0085] A WTRU (e.g., a member WTRU) may determine which scheduling request information to send based on a property of data that the WTRU has for sidelink transmission (e.g., based on an amount of data, a QoS of the data, and / or the like). If the WTRU receives a resource for sidelink transmission, theWTRU may (e.g., then) indicate its buffer status (e.g., in a SL-MAC CE) in the transmission, for example, if the GC is a receiver (e.g., one of the receivers) and the WTRU has (e.g., still has) data to transmit.

[0086] A WTRU (e.g., a member WTRU) may be (pre-)configured to perform one or more of the following.

[0087] The WTRU may be (pre)configured with (e.g., and / or receive configuration information indicating) a SL-SR transmission (e.g., multi-bit SL-SR information). For example, the multi-bit SL-SR information may indicate multiple values (e.g., sequences), where a (e.g., each) value is associated with a (e.g., respective) parameter and / or range of one or more parameters associated with data (e.g., a range of parameters associated with data of the SL-SR transmission). For example, the WTRU may be (pre-)configured with N bits for a SL-SR, where a (e.g., each) codepoint and / or sequence is associated with one or more of: a range of the amount of data; or a range of PDB and / or priority.

[0088] The WTRU may be (pre)configured with (e.g., receive configuration information indicating) a mapping between and / or of a SL-SR (e.g., a SL-SR sequence) and a sidelink resource. For example, the WTRU may be (pre-)configured with a mapping that indicates a (e.g., respective) SL-SR resource for a (e.g., each / respective) period of the sidelink transmission. In examples, the WTRU may determine a sidelink resource, to transmit the SL-SR, based on the mapping.

[0089] The WTRU may (e.g., if data arrives for sidelink transmission, if data is available for transmission, and / or the like) determine the codepoint and / or sequence to use in the transmission of the SL-SR to the GC, for example, based on a property of its data (e.g., based on an amount of data, a QoS of the data, and / or the like).

[0090] The WTRU may (e.g., if data arrives for sidelink transmission, if data is available for transmission, and / or the like) determine the resource to use to transmit a SL-SR (e.g., the SL-SR with the determined sequence), for example, based on the intended sidelink transmission period.

[0091] The WTRU may transmit a SL-SR to request resource(s) for a sidelink transmission by the WTRU.

[0092] The WTRU may receive a sidelink grant (e.g., from the GC). In examples, the WTRU may receive a sidelink grant to use the for a sidelink transmission. If the number of scheduled sidelink grant(s) is smaller than (e.g., less than) the WTRU’s buffer size, the scheduled grant may not be enough and / or sufficient for the WTRU’s sidelink transmission (e.g., the WTRU may determine that the sidelink grant is insufficient to transmit the data available for sidelink transmission). If the GC is a receiver (e.g., one of the indicated receivers) of the (e.g., sidelink) transmission, the WTRU may include its buffer information in the sidelink transmission (e.g., via a SL-MAC CE, a SL-BSR, a SL-DSR), for example, in a scheduled sidelink grant (e.g., one of the scheduled sidelink grants to request resource(s) to transmit more sidelink data). Inexamples, based on a determination that the sidelink grant is smaller than the threshold and / or based on a determination that the GC is an intended receiver of the (e.g., sidelink) transmission, the WTRU may include an indication of a buffer status associated with the WTRU in the (e.g., sidelink) transmission. In examples, the WTRU may send the (e.g., sidelink) transmission via the sidelink resource (e.g., where at least a portion of the data is sent via the transmission).

[0093] If the GC is not a receiver (e.g., one of the indicated receivers) of the sidelink transmission, the WTRU may determine the SL-SR resource, and / or send the SL-SR to the GC to request a grant(s) (e.g., more grant(s) (e.g., to request additional transmission resource(s), for example due to the first (e.g., original) sidelink grant not providing enough and / or sufficient resources to transmit the data available for transmission).

[0094] In examples, a WTRU may determine that data is available for sidelink transmission. The WTRU may determine a sequence based on a property of the data. The sequence may be associated with the SL- SR (e.g., the WTRU may transmit the SL-SR, where, in examples, the SL-SR transmission comprises the determined sequence, for example N bits, where the values of the bits correspond to the determined sequence).

[0095] The WTRU may be configured with a mapping between a respective sequence and a respective property of data (e.g., property of data in a buffer of the WTRU). The WTRU may (e.g., then), e.g., if the WTRU has data for sidelink transmission, determine which sequence to transmit based on a property of data for sidelink transmission (e.g., using the mapping). In examples, the WTRU may be configured with a set of sequences, in which a (e.g., each) sequence is associated with a range of delay budget(s) associated with the data in the buffer. The WTRU may (e.g., then) determine which sequence to transmit based on the delay budget of the data in the buffer. In examples, the WTRU may be configured with a set of sequences, in which a (e.g., each) sequence may be associated with a range of the amount of data in the buffer. The WTRU may (e.g., then) determine which sequence to transmit based on the amount of data in the buffer. In examples, the WTRU may be configured with a set of sequences, in which a (e.g., each) sequence may be associated with one or more priority levels of the data in the buffer. The WTRU may (e.g., then) determine which sequence to transmit based on the priority of the data in the buffer.

[0096] The WTRU may be configured with a mapping between a SL-SR resource and the set of resources to transmit sidelink data. The WTRU may (e.g., then) determine a SL-SR to use based on the sidelink data to be transmitted. For example, the WTRU may be configured with one or more SL-SR resources, in which a (e.g., each) SL-SR resource may be associated with a sidelink transmission window. The WTRU may (e.g., then) determine to transmit a SL-SR in a resource if the resource is associated with the (e.g., potential) window of sidelink data transmission. A transmission window may be configured tooccur (e.g., happen) after an (e.g., each) associated SL-SR resource. The duration of the transmission window may be fixed, or configured as a function of the QoS of the sidelink data (e.g., priority, latency, and / or the like).

[0097] The WTRU may transmit (e.g., a first and / or second portion of the) sidelink data, for example in the scheduled sidelink grant resource(s) and / or in the additional sidelink grant resource(s).

[0098] A PDU may refer to a PDU at a (e.g., any) protocol layer. For example, a PDU may refer to a SDAP PDU, a PDCP PDU, a RLC PDU, a MAC PDU, a PHY PDU, a TB, or a HARQ RV. For example, a PDU may refer to a PDU of an (e.g., a new) adaptation layer introduced to support WTRU aggregation.

[0099] The term reference-signal may be used to describe one more of the existing reference-signals such as SRS, SRS for positioning, or SL-PRS. The term reference-signal may be used to describe the (e.g., new) reference-signal designed for other purposes, such as sensing. A reference-signal may be transmitted in a standalone manner or together with PDU.

[0100] QoS of a PDU (e.g., MAC PDU) may refer to one or more of the following: one or more 5QI parameters associated of an RB / LCH and control information (e.g., MAC CE) included in the PDU such as priority, PDB, reliability (e.g., PER), maximum data burst volume (MDBV); and / or one or more configurations of an RB / LCH included in the PDU (e.g., MAC PDU). For example, a configuration of an RB / LCH included in the PDU may be whether the RB / LCH is (pre-)configured with WTRU aggregation enabled / disabled. For example, a configuration of an RB / LCH included in the PDU may be the number of aggregated WTRUs associated with the RB / LCH. For example, a configuration of an RB / LCH included in the PDU may be the HARQ retransmission mode associated with the RB / LCH. For example, a configuration of an RB / LCH included in the PDU may be whether the RB / LCH is associated with HARQ enabled or HARQ disabled transmission.

[0101] The QoS of a PDU comprising multiple higher PDUs may refer to one or more of the following QoS: the maximum and / or minimum of a (e.g., one) 5QI parameter of a (e.g., all) RB / LCH or control information (e.g., MAC CE) included in the PDU; one or more QoS associated with the multiple PDUs; or one or more configurations of an RB / LCH included in the PDU (e.g., MAC PDU).

[0102] The QoS of a PDU comprising multiple higher PDUs may refer to the maximum and / or minimum of one 5QI parameter of a (e.g., all) RB / LCH or control information (e.g., MAC CE) included in the PDU, such as the maximum of the priority, the minimum of PDB, the minimum PER, or the maximum MDBV.

[0103] The QoS of a PDU comprising multiple higher PDUs may refer to one or more QoS associated with the multiple PDUs (e.g., a PDU set), for example, in which the considered PDU may be a (e.g., one) PDU in the PDU set. The QoS parameters for the PDU set may include one or more of the following: PSDB; PDU set error rate (PSER); or PDU set integrated handling information (PSI HI). PSDB may be usedto indicate the maximum duration between the reception time of the first PDU and the time when the (e.g., all) PDUs of a PDU set have been successfully received. PSER may be used to indicate the bound for the data lost rate of a PDU set. PSI HI may be used to indicate whether all PDUs of a PDU set are needed for the usage of the PDU set.

[0104] The QoS of a PDU comprising multiple higher PDUs may refer to one or more configurations of an RB / LCH included in the PDU (e.g., MAC PDU). One or more configurations of an RB / LCH included in the PDU (e.g., MAC PDU) may indicate, for example: whether the PDU included in a (e.g., one) RB / LCH is (pre-)configured with a WTRU aggregation enabled / disabled; the maximum number of aggregated WTRUs associated with a (e.g., one) RB / LCH included in the PDU; or the HARQ retransmission mode associated with a (e.g., one) RB / LCH included in the PDU.

[0105] The QoS associated with the reference-signal may be used to refer to the priority, latency, and / or reliability of the reference-signal. The QoS associated with the reference-signal may (e.g., also) be used to refer to one or more transmission parameters of the reference-signal, such as the bandwidth, comb size, comb pattern, and / or the like).

[0106] The term traffic may be used to describe the one or more of the following: the PDU generated from the WTRU, the PDU received by the WTRU, and / or the PDU transmitted by the WTRU; and / or the reference-signal, such as SL-PRS, SRS, SRS for positioning generated by the WTRU, received by the WTRU, and / or transmitted by the UE. Traffic may be used interchangeably with PDU traffic, referencesignal traffic, and / or PDU / reference-signal traffic.

[0107] One or more of the following types of WTRUs may be used (e.g., as described herein): source WTRU, destination WTRU, assistance WTRU, GC WTRU, or member WTRU. A source WTRU may refer to an initiator of a PDU to transmit to another node (e.g., such as the gNB or another WTRU). A destination WTRU may refer to an end receiver of a PDU (e.g., which may be transmitted from gNB or another WTRU). An assistant WTRU may refer to a WTRU supporting another WTRU (e.g., source WTRU or destination WTRU) in transmitting and receiving a PDU. A GC WTRU may refer to a WTRU supporting the gNB to perform one or more functions such as scheduling for one or more WTRUs, for example, which may belong to a group (e.g., a group of WTRUs). A member WTRU may refer to a (e.g., one) WTRU in a group, which may interact with the GC WTRU and / or other member WTRU to perform one or more procedures under the coordination of the GC WTRU. A member WTRU may refer to a (e.g., one) WTRU in a group, which may coordinate with other WTRUs in the group to perform a group-related application.

[0108] A WTRU may be (pre-)configured (e.g., also interchangeably referred to herein as configured) based on one or more of the following situations. The WTRU may receive a configuration from gNB or another node such as the GC. The configuration received from a gNB may be via one or any combinationof a DCI, a MAC CE, a RRC, a SIB, and / or a NAS message. The configuration received from another node (e.g., a GC) may be via one or any combination of a sidelink control information (SCI), a PC5 MAC CE, a PC5 RRC, and / or a NAS message. The WTRU may be (pre-)configured in the internal WTRU with a (e.g., certain) configuration.

[0109] A resource-request message may be used to indicate one or more transmissions and / or messages from a node (e.g., from one node such as a member WTRU) to another node (e.g., GC, gNB) to request for transmission resource. The transmission and / or messages may include one or more of the following: a scheduling request (SR), a SL-SR, a MAC CE, or a PC5 MAC CE. A SL-SR may be a SR sent from a (e.g., one) WTRU to the GC, to request resource(s) from the GC. A MAC CE may be, for example, BSR, DRS, or a (e.g., new) MAC CE. A PC5 MAC CE may be a SL-BSR, or a SL-DSR. A PC5 MAC CE may be used to indicate information regarding the requested resource or buffer status information at the WTRU conveyed to the GC via sidelink.

[0110] A SR may be used instead of SL-SR, where a SR may be used to indicate the SR transmitted in PC5 from a first (e.g., one) WTRU to a second (e.g., another) WTRU (e.g., GC).

[0111] A MAC CE (e.g., BSR, DSR, and / or the like) may be used instead of a PC5 MAC CE (e.g., SL- BSR, SL-DSR, and / or the like), where a MAC CE may be used to indicate information regarding the requested resource or buffer status of the WTRU conveyed to the GC via sidelink.

[0112] A GC-based SR may be performed (e.g., if the gNB partially offloads the scheduling functionality to the GC). For example, the resource-request (e.g., sending an SR, and / or a buffer status reporting) procedure may be configured support the GC in scheduling.

[0113] A WTRU may send messages to a second (e.g., another) WTRU to request the transmission resource (e.g., of the second WTRU). For example, a WTRU (e.g., member WTRU) may be (preconfigured with a scheduler (e.g., a GC, or the gNB), to request transmission resources for its transmission (e.g., for a PDU transmission and / or for a reference-signal transmission such as SRS, SRS for positioning, and / or SL-PRS for positioning). The WTRU may (e.g., then) send one or more messages to the scheduler (e.g., the GC or gNB), for example, to request a transmission resource for its transmission (e.g., PDU(s) / reference-signal(s)). The WTRU may send one or more of the following information regarding its transmission to the scheduler: the availability of PDU(s) / reference-signal(s) for its transmission; the property of the PDU(s) / reference-signal(s) for its transmission; the property of the requested resources for its transmission; or the purpose of resource usage.

[0114] The WTRU may send (e.g., to the scheduler) the availability of PDU(s) / reference-signal(s) for its transmission. For example, the WTRU may send an indication to the GC of whether it (e.g., the WTRU) has PDU(s) / reference-signal(s) to transmit (e.g., or not). For example, the WTRU may be (pre-)configured withone or more resources to transmit an indication of the availability of its (e.g., the WTRU’s) PDU(s) / reference-signal(s). For example, in a (pre-)configured resource (e.g., each (pre-)configured resource), the WTRU may indicate whether it has PDU(s) / reference-signal(s) to transmit (e.g., or not). For example, the WTRU may send an indication to the GC if it (e.g., the WTRU) has PDU(s) / reference- signal(s) to transmit. If the WTRU does not have PDU(s) / reference-signal(s) to transmit, the WTRU may not transmit the (e.g., such) indication to the GC.

[0115] The WTRU may be (pre-)configured to send an indication to the GC of the type of PDU(s) / reference-signal(s) to transmit (e.g., whether it has a type (e.g., each type) of PDU(s) / reference- signal(s) to transmit). For example, the WTRU may be (pre-)configured with one or more (e.g., two) types of resources, in which the first type of resource(s) may be used to indicate that the WTRU has a PDU to transmit and / or the second type of resource(s) may be used to indicate that the WTRU has a reference signal (e.g., a SL-PRS, a SL-SR, a SRS, or a SRS for positioning) to transmit. For example, the WTRU may be (pre-)configured with a (e.g., one) type of resource(s) and / or the WTRU may be (pre-)configured with a multi-bit indication, in which a (e.g., each) codepoint may be used to indicate an (e.g., one) indication. For example, the WTRU may be (pre-)configured with the first codepoint to indicate the availability of a PDU for its (e.g., the WTRU’s) transmission. The WTRU may be (pre-)configured with a second (e.g., another) codepoint to indicate the availability of a reference signal (e.g., a SL-PRS, a SL-SR, a SRS, or a SRS for positioning) for its transmission. The WTRU may (e.g., then) determine which codepoint (e.g., the first and / or the second codepoint) to transmit based on which indication the WTRU determines (e.g., wants) to convey to the GC (e.g., whether the WTRU determines to send an indication of the availability of a PDU and / or an indication of a reference signal).

[0116] The WTRU may send (e.g., to the scheduler) the property of the PDU(s) / reference-signal(s) for its transmission. The WTRU may send one or more of the following information regarding the property of PDU(s) / reference-signal(s) for its transmission: the number of PDU(s) in its (e.g., the WTRU’s) buffer; QoS information associated with the PDU(s) / reference-signal(s) for its (e.g., the WTRU’s) transmission; or a number of reference-signal(s) to transmit in the buffer (e.g., of the WTRU). The WTRU may indicate the amount of data in the buffer (e.g., a BSR), for example when sending the number of PDU(s) in its buffer.

[0117] The WTRU may send (e.g., to the scheduler) QoS information associated with the PDU(s) / reference-signal(s) for its transmission. For example, the WTRU may indicate one or more of the priority, reliability, latency, and / or the like, of the PDU(s) / reference-signal(s) in the buffer.

[0118] The WTRU may send (e.g., to the scheduler) the number of reference-signal(s) to transmit in the buffer. For example, the WTRU may have one or more reference-signal(s) to transmit. The WTRU may (e.g., then) indicate the number of reference-signal(s) in the buffer for its transmission.

[0119] The WTRU may send (e.g., to the scheduler) a property of the requested resource(s) for its transmission. For example, the WTRU may indicate one or more of the following information regarding the property of the requested transmission resources: a bandwidth requirement of the transmission resources; a required number of transmission resources; a latency requirement of the transmission resources; or a purpose of resource usage (e.g., whether the resource can be used for which type of transmission (e.g., such as PDU(s)), control signal(s) (e.g., uplink control information (UCI), SCI, and / or the like), or referencesignals) (e.g., SL-PRS, SRS, or SRS for positioning, and / or the like).

[0120] The WTRU may send (e.g., such) information to the scheduler (e.g., GC, gNB) using sequencebased or code-bit-based transmission. For example, the WTRU may use one or any combination of SL-SR, SCI, SFI, MAC (sub-)header, SL MAC CE, PC5 RRC, and / or NAS message to send the information to the GC. The WTRU may use one or any combination of the (e.g., new) channel designed for SL-SR, physical sidelink control channel (PSCCH), physical sidelink shared channel (PSSCH), and / or physical sidelink feedback channel (PSFCH) to transmit to the GC (e.g., to request resources for its transmission). In examples, the WTRU may use one or any combination of a SR, a BSR, a MAC CE, a RRC, and / or a NAS message to send the information to the gNB. The WTRU may use one or any combination of the UCI, physical uplink shared channel (PUSCH), and / or physical uplink control channel (PUCCH) to send the (e.g., such) information to the gNB.

[0121] A WTRU may transmit SL-SR to request resource(s) for its transmission. The WTRU may transmit SL-SR, which may be transmitted in sidelink to request resource(s) for its sidelink and / or uplink transmission (e.g., single-bit, or multi-bit SL-SR). The SL-SR may be transmitted in a sequence-based or code-bit-based transmission.

[0122] For a (e.g., each) SL-SR transmission, the WTRU may (e.g., implicitly / explicitly) indicate one or more of the following: an availability of the PDU(s) / reference-signal(s); an indication of the provided information; buffer status information; the property of the requested resources; or QoS information.

[0123] A WTRU may (e.g., implicitly / explicitly) indicate the availability of the PDU(s) / reference-signal(s). For example, the WTRU may have PDU(s) / reference-signal(s) to transmit, and the WTRU may (e.g., then) transmit a multi-bit SL-SR to request (e.g., the availability) for its (e.g., the WTRU’s) PDU(s) / reference- signal(s)’s transmission. The WTRU may (e.g., implicitly / explicitly) indicate whether it (e.g., the WTRU) has PDU(s) and / or reference-signal(s) to transmit. The WTRU may (e.g., implicitly / explicitly) indicate whether it (e.g., the WTRU) request(s) transmission resource(s) for a PDU(s) transmission and / or a referencesignals) transmission.

[0124] A WTRU may (e.g., implicitly / explicitly) indicate the indication of the provided information. For example, the WTRU may be (pre-)configured with one or more (e.g., multiple) format(s) of a multi-bit SL-SR, in which a (e.g., each) format may indicate(s) information (e.g., one (pre-)configured information for each format). For example, the WTRU may be (pre-)configured with multiple multi-bit SL-SR formats, in which at least one of: a first (e.g., one) SL-SR format is used to indicate the amount of PDU(s) / reference- signal(s) in the buffer, a second (e.g., another) SL-SR format is used to indicate the latency information of the PDU(s) / reference-signal(s) in the buffer (e.g., the lowest delay budget of the PDU(s) / reference-signal(s) in required for transmission), a third (e.g., another) format is used to indicate the priority of the PDU(s) / reference-signal(s) in the buffer (e.g., the highest priority of the PDU(s) / reference-signal(s) in the buffer), a fourth (e.g., another) format is used to indicate the important of the PDU(s) / reference-signal(s) in the buffer such as the PDU set important, and / or a fifth (e.g., another) format is used to indicate the requested (e.g., required) bandwidth of the PDU(s) / reference-signal(s) in the buffer. The WTRU may (e.g., then) transmit a multi-bit SL-SR, for example, indicating which format the WTRU is transmitting (e.g., the first, second, third, fourth, and / or fifth format).

[0125] A WTRU may (e.g., implicitly / explicitly) indicate buffer status information. For example, the WTRU may transmit a multi-bit SL-SR to indicate the number of PDUs in the buffer. For example, the WTRU may be (pre-)configured with one or more (e.g., multiple) codepoints in a multi-bit SL-SR, in which a (e.g., each) codepoint may be used to indicate a (e.g., one) range of the number of PDUs in the buffer. The WTRU may (e.g., then) indicate the range of the number of PDUs in the buffer by indicating the associated codepoint in a multi-bit SL-SR.

[0126] A WTRU may (e.g., implicitly / explicitly) indicate the property of the requested resources (e.g., the number of transmission resources, the bandwidth of the transmission resource, and / or the like). For example, the WTRU may transmit a multi-bit SL-SR to indicate the information regarding its (e.g., associated with the WTRU’s) requested transmission resource (e.g., the bandwidth of the reference signal) for its PDU(s) / reference-signal(s). The WTRU may be (pre-)configured with one or more (e.g., multiple) codepoint(s), in which a (e.g., each) codepoint may be used to indicate a (e.g., one) range of the number of the requested resources. The WTRU may (e.g., then) indicate the range of the number of the requested resources by indicating the associated codepoint in a multi-bit SL-SR.

[0127] A WTRU may (e.g., implicitly / explicitly) indicate QoS information (e.g., one or more of priority, latency, PSDB, PSI, PSIHI, and / or the like) associated with the PDU(s) / reference-signal(s) in the buffer. For example, the WTRU may transmit a multi-bit SL-SR to indicate the priority of the PDU(s) / reference- signal(s) in the buffer. The WTRU may be (pre-)configured with one or more (e.g., multiple) codepoint(s), in which a (e.g., each) codepoint may be associated with a (e.g., one) range of priorities of the PDU(s) / reference-signal(s). The WTRU may use a priority (e.g., the highest priority) of the PDU(s) / reference-signal(s) in the buffer to determine whether the priority of the PDU(s) / reference-signal(s)belongs to which (pre-)configured range of priorities (e.g., whether the priority of a PDU / reference-signal is associated with a range of priorities of the PDU(s) / reference-signal(s)). The WTRU may (e.g., then) indicate the priority information of the PDU(s) / reference-signal(s) in the buffer by indicating the codepoint associated with the priority of the PDU(s) / reference-signal(s) in the buffer.

[0128] For example, the WTRU may transmit a multi-bit SL-SR to indicate the PSDB of the PDU(s) / reference-signal(s) in the buffer. The WTRU may be (pre-)configured with one or more (e.g., multiple) codepoint(s), in which a (e.g., each) codepoint may be associated with a (e.g., one) range of the PSDB of the PDU(s) / reference-signal(s). The WTRU may use a PSDB (e.g., the lowest PSDB) of the PDU(s) / reference-signal(s) in the buffer to determine whether the PSDB of the PDU(s) / reference-signal(s) belongs to which (pre-)configured range of latency(ies) (e.g., whether the PSDB of a PDU / reference-signal is associated with a range of latencies). The WTRU may (e.g., then) indicate the PSDB information of the PDU(s) / reference-signal(s) in the buffer by indicating the codepoint associated with the latency of the PDU(s) / reference-signal(s) in the buffer.

[0129] A WTRU may use SCI to request the resource for its transmission, for example from the GC. For example, the WTRU may be (pre-)configured with a (e.g., one) bitfield in the first stage SCI to indicate whether it (e.g., the WTRU) requests the GC for its transmission resource. The WTRU may (e.g., implicitly / explicitly) indicate the number of requested resources requested for its transmission. For example, the WTRU may be configured with a (e.g., one) set of codepoints in the SCI, in which a (e.g., each) codepoint may indicate a (e.g., one) range of the number of requested resources. The WTRU may (e.g., then) indicate the number of requested resources in the SCI by (e.g., explicitly) indicating the codepoint associated with the range of the requested resource. In examples, the WTRU may be (pre-)configured with a (e.g., one) second stage SCI format to request the GC for its transmission resources. The WTRU may use the first stage SCI to indicate the availability of the second stage SCI, for example, which may be used to request the transmission resource.

[0130] A WTRU may transmit SL MAC CE to the GC, for example to indicate the properties of its PDU(s) / reference-signal(s). For example, the WTRU may transmit a SL MAC CE (e.g., a new SL MAC CE such as a BSR and / or DSR) to the GC (e.g., to indicate one or more properties regarding its PDU(s) / reference-signal(s)) to request a resource for its transmission. The WTRU may trigger sending SL MAC CE to the GC based on one or more of the following: an indication from the GC, sending a SL-SR (e.g., to the GC), if a scheduled resource is not sufficient for its (e.g., the WTRU’s) transmission, or if the GC is a receiver (e.g., one of the receivers or the only receiver) for its (e.g., the WTRU’s) PDU(s) / reference-signal(s) transmission.

[0131] The WTRU may trigger sending SL MAC CE to the GC based on an indication from the GC. For example, the WTRU may receive an indication from the GC to send SL MAC CE (e.g., BSR, DSR). The WTRU may (e.g., then) send the indicated SL MAC CE to the GC. For example, the WTRU may receive an implicit indication from the GC, that may indicate that the GC may schedule a sidelink transmission resource for the WTRU. The WTRU may (e.g., then) trigger sending SL MAC CE to indicate the properties of its PDU(s) / reference-signal(s) and / or request transmission resource(s) for PDU(s) / reference-signal(s) transmission.

[0132] The WTRU may trigger sending SL MAC CE to the GC based on the WTRU sending a SL-SR to the GC. For example, the WTRU may trigger sending SL MAC CE (e.g., a SL BSR, a DSR) to the GC if the WTRU sends a SL-SR to the GC.

[0133] The WTRU may trigger sending SL MAC CE to the GC based on the scheduled resource being insufficient for its transmission. For example, the WTRU may transmit a SL-SR to the GC. The WTRU may (e.g., then) trigger sending SL MAC CE to the GC if the WTRU has not received enough transmission resource within a latency period (e.g., if the WTRU has not received a sufficient transmission resource(s) within a latency period). The WTRU may cancel a SL MAC CE, for example, if it (e.g., the WTRU) has received enough transmission resource(s) within the latency period. The latency period may be based on the latency requirement of the PDU(s) / reference-signal(s) in the buffer.

[0134] The WTRU may trigger sending SL MAC CE to the GC based on if the GC is a receiver (e.g., one of the receivers or the only receiver for) of its (e.g., the WTRU’s) PDU(s) / reference-signal(s) transmission. For example, the WTRU may have a groupcast and / or broadcast service, in which the GC is a receiver (e.g., also one of the receivers) of the groupcast and / or broadcast service. Such information may be exchanged between the WTRUs (e.g., the two WTRUs) before the scheduling offloading procedure. The WTRU (e.g., member WTRU) may (e.g., then opportunistically) multiplex SL MAC CE (e.g., SL BSR, DSR) in a PDU (e.g., MAC PDU) of the groupcast and / or broadcast PDU to transmit to the GC, for example, if the GC is a receiver (e.g., one of the receivers) of its (e.g., the WTRU’s) transmission. In examples, the WTRU may have a unicast link with the GC. The WTRU may determine to transmit a MAC PDU to the GC. The WTRU may (e.g., then) include the SL MAC CE (e.g., SL BSR, DSR) to indicate the properties of its (e.g., the WTRU’s) PDU(s) / reference-signal(s) and / or request the transmission resource from the GC.

[0135] In examples, the WTRU may have PDU(s) / reference-signal(s) for its (e.g., the WTRU’s) transmission (e.g., sidelink and / or Uu uplink transmission). For example, the WTRU may (e.g., then) send SL-SR to the GC to request for a transmission resource. The WTRU may (e.g., then) receive a transmission resource from the GC. For example, the WTRU may be (pre-)configured with a set of transmission resources (e.g., periodic transmission resources) for its (e.g., the WTRU’s) transmission. TheWTRU may (e.g., then) perform a transmission in the scheduled and / or configured resource(s). If the GC is a receiver (e.g., one of the receivers) of the transmission, the WTRU may (e.g., then opportunistically) include a SL MAC CE (e.g., a new SL BSR / DSR) in a PDU (e.g., MAC PDU) to transmit to the GC. For example, the WTRU may include a SL MAC CE in the MAC PDU if the SL MAC CE is available. For example, the WTRU may include and / or generate a SL MAC CE in the MAC PDU if the number of PDUs in the buffer is greater than a (pre-)configured threshold and / or the scheduled and / or configured resources is not sufficient for the WTRU to transmit the PDU(s) / reference-signal(s) in the buffer.

[0136] A WTRU may indicate the availability of a SL MAC CE in the MAC PDU. For example, the WTRU may indicate the availability of the SL MAC CE (e.g., a new BSR / DSR) to request a transmission resource in a MAC PDU transmitting to the GC (e.g., which may be used to support other WTRUs in receiving the MAC PDU from the WTRU). This approach may be done, for example, (e.g., a WTRU may indicate the availability of a SL MAC CE in the MAC PDU) if the WTRU transmits the MAC PDU to multiple WTRUs including the GC. The WTRU may indicate the availability of the SL MAC CE in the SCI or in the MAC (subheader. A WTRU that receives the MAC PDU (e.g., other WTRUs, which are the receivers of the MAC PDU), may (e.g., then) ignore and / or skip the SL MAC CE in the MAC PDU.

[0137] A WTRU may prioritize the transmission to the GC. For example, the WTRU may be scheduled with a resource for its (e.g., the WTRU’s) transmission. The WTRU may have PDU(s) / reference-signal(s) targeting a destination (e.g., different destinations). For example, the WTRU may have a (e.g., different) set of PDU(s) / reference-signal(s) for unicast, groupcast, and / or broadcast services. For example, the WTRU may have a (e.g., different) set(s) of PDU(s) / reference-signal(s) targeting a (e.g., different) set(s) of WTRUs. The WTRU may (e.g., then) determine which destination to prioritize during the LCP procedure based on one or more of the following: a priority associated with the destination of the PDU(s) / reference- signal(s); a priority and / or precedence associated with the destination; a service associated with the destination; or whether the transmission is for reference transmission or PDU transmission.

[0138] The WTRU may determine which destination to prioritize during the LCP procedure based on a priority associated with the destination of the PDU(s) / reference-signal(s). For example, the WTRU may prioritize the transmission to the GC if it (e.g., the WTRU) has a SL-SR to transmit to the GC. The WTRU may prioritize the transmission to the GC if it has a SL MAC CE (e.g., BSR, DSR) to transmit to the GC.

[0139] The WTRU may determine which destination to prioritize during the LCP procedure based on a priority and / or precedence associated with the destination. For example, the WTRU may be (preconfigured to prioritize a transmission to a (e.g., one) destination. The WTRU may prioritize a transmission to the GC. The WTRU may prioritize a transmission to the gNB.

[0140] The WTRU may determine which destination to prioritize during the LCP procedure based on service(s) associated with the destination. For example, the WTRU may prioritize the transmission associated with a Uu service (e.g., a transmission having the gNB as the receiver). In examples, the WTRU may prioritize a transmission based on a cast type (e.g., a unicast, a groupcast, and / or a broadcast) associated with the service. For example, the WTRU may (e.g., first) prioritize broadcast services. The WTRU may (e.g., then) prioritize groupcast services.

[0141] The WTRU may determine which destination to prioritize during the LCP procedure based on whether the transmission is for a reference transmission or a PDU transmission. For example, the WTRU may prioritize transmit a (e.g., certain) reference signal (e.g., CSI-RS, SL-PRS). In examples, the WTRU may be configured to prioritize a transmission based on the reference signal type (e.g., a CSI-RS, a SL- PRS, and / or the like).

[0142] A WTRU may determines whether to cancel a resource request (e.g., SR, BSR, and / or DSR).

[0143] The WTRU may trigger sending a resource request (e.g., using UCI, MAC CE, SR, BSR, and / or DSR) to request a transmission resource from a (e.g., one) scheduler (e.g., GC, or gNB). The (e.g., triggered) resource request may be transmitted to the GC or the gNB. The WTRU may (e.g., then) determine to cancel sending the resource-request (e.g., UCI, MAC CE, SR, BSR, and / or DSR) based on one or more of the following: whether the WTRU has a scheduled transmission resource from one scheduler; whether the resource-request (e.g., SR, BSR, and / or DSR) is (e.g., already) transmitted; or whether a SR, BSR, and / or DSR prohibit timer is running.

[0144] The WTRU may determine to cancel sending a resource request if the WTRU has scheduled a transmission resource from a scheduler (e.g., one scheduler). For example, the WTRU may trigger sending a SR, BSR, and / or DSR to a (e.g., one) scheduler (e.g., the GC). The WTRU may (e.g., then) cancel a SR, BSR, and / or DSR if the WTRU is scheduled with a transmission resource by a (e.g., any) scheduler (e.g., either the GC or the gNB). In examples, the WTRU may (e.g., only) cancel SR, BSR, and / or DSR if the WTRU is scheduled with a transmission resource by the target scheduler (e.g., the gNB). The scheduled resource may be used to transmit a BSR and / or DSR to the scheduler. For example, the WTRU may trigger sending SR, BSR, and / or DSR to the gNB. For example, the WTRU may cancel SR, BSR, and / or DSR to the gNB if it is scheduled to transmit resources by another scheduler (e.g., the gNB). In examples, the WTRU may cancel SR and / or BSR to the gNB if a SR, BSR, and / or DSR is transmitted to the GC.

[0145] The WTRU may determine to cancel sending a resource request if the resource request (e.g., SR, BSR, and / or DSR) has (e.g., already) been transmitted. For example, the WTRU may (e.g., first) trigger sending a resource request to a (e.g., one) scheduler. The WTRU may cancel sending the resource request if it has (e.g., already) sent the resource request to the scheduler. For example, the WTRU maycancel sending a resource request to the target scheduler (e.g., to the gNB) if it has (e.g., already) sent the resource request to a (e.g., any) scheduler (e.g., either to the gNB or the GC).

[0146] The WTRU may determine to cancel sending a resource request if a SR, BSR, and / or DSR prohibit timer is running.

[0147] A WTRU may send a resource request (e.g., UCI, MAC CE, SR, BSR, and / or DSR) to a (e.g., another) scheduler. For example, a WTRU may (e.g., first) trigger sending resource-request (e.g., SR, BSR, and / or DSR) to a first (e.g., one) scheduler. The WTRU may (e.g., then) trigger sending the resourcerequest (e.g., SR, BSR, and / or DSR) to a second (e.g., another) scheduler based on one or more of the following: a time gap to the resource to send a resource-request to the target scheduler; the availability of a transmission resource from the target scheduler; a number resource-requests (e.g., SR) sent to the target scheduler; or if / whether the remaining PDB of the PDU(s) / reference-signal(s) is smaller than a (preconfigured threshold.

[0148] The WTRU may trigger sending the resource-request (e.g., SR, BSR, and / or DSR) to a (e.g., another) scheduler based on the time gap to the resource to send a resource-request to the target scheduler. For example, the WTRU may (e.g., first) trigger sending a resource-request (e.g., SR, BSR, and / or DSR) to a target scheduler (e.g., gNB). The WTRU may trigger sending the resource-request (e.g., SR, BSR, and / or DSR) to a second (e.g., another) scheduler (e.g., the GC) if the time gap to the PUCCH and / or PUSCH resource scheduled by the gNB to send a SR, BSR, and / or DSR is larger than a (pre- )configured threshold.

[0149] The WTRU may trigger sending the resource-request (e.g., SR, BSR, and / or DSR) to a (e.g., another) scheduler based on the availability of a transmission resource from the target scheduler. For example, the WTRU may (e.g., already) send a resource-request to a scheduler (e.g., the current scheduler such as the GC). The WTRU may then trigger sending a resource-request to a second (e.g., another) scheduler (e.g., the gNB) if it hasn’t received the scheduling resource from the target scheduler for a (pre-)configured period.

[0150] The WTRU may trigger sending the resource-request (e.g., SR, BSR, and / or DSR) to a second (e.g., another) scheduler based on a number resource-requests (e.g., SR) sent to the target scheduler. For example, the WTRU may be (pre-)configured with a maximum number of SR transmissions to the target scheduler. The WTRU may (e.g., then) trigger sending a resource-request to a second (e.g., another) scheduler if the number of SR transmission to the first scheduler is larger than a (pre-)configured threshold.

[0151] The WTRU may trigger sending the resource-request (e.g., SR, BSR, and / or DSR) to a second (e.g., another) scheduler based on whether a remaining PDB of the PDU(s) / reference-signal(s) is smaller than a (pre-)configured threshold. For example, the WTRU may be (pre-)configured with a scheduler. TheWTRU may trigger sending a resource-request to a first (e.g., one) scheduler. The WTRU may (e.g., then) trigger sending a resource-request to a second (e.g., another) scheduler if the remaining PDB of the PDU(s) / reference-signal(s) is smaller than a threshold (e.g., a (pre-)configured threshold) and the WTRU does have a grant for its (e.g., the WTRU’s) transmission within a period. This approach may be motivated to help the WTRU to get a transmission resource from a second (e.g., another) scheduler to meet the PDB requirements of the PDU(s) / reference-signal(s).

[0152] In examples, GC-based scheduling request transmission may be performed. A WTRU (e.g., member WTRU) may determine which scheduling request information to send based on the property of the data that the WTRU has for sidelink transmission (e.g., based on an amount of data, a QoS of the data, and / or the like). If the WTRU receives a resource for sidelink transmission, the WTRU may (e.g., then) indicate its (e.g., the WTRU’s) buffer status (e.g., in a SL-MAC CE) in the transmission, for example, if the GC is a resource (e.g., one of the receivers) and the WTRU has (e.g., still has) data to transmit. The WTRU may be (pre-)configured to perform one or more the following.

[0153] The WTRU may be (pre)configured with (e.g., and / or receive configuration information indicating) a SL-SR transmission (e.g., multi-bit SL-SR information). For example, the multi-bit SL-SR information may indicate multiple values (e.g., sequences), where a (e.g., each) value is associated with a (e.g., respective) parameter and / or a range of one or more parameters associated with data (e.g., a range of parameters associated with data of the SL-SR transmission. For example, the WTRU may be (pre-)configured with N bits for a SL-SR, where a (e.g., each) codepoint and / or sequence is associated with one or more of: a range of the amount of data; or a range of PDB and / or priority.

[0154] The WTRU may be (pre)configured with (e.g., receive configuration information indicating) a mapping between and / or of a SL-SR (e.g., a SL-SR sequence) and a sidelink resource. For example, the WTRU may be (pre)configured with a mapping that indicates a (e.g., respective) SL-SR resource for a (e.g., each / respective) period of the sidelink transmission. In examples, the WTRU may determine a sidelink resource, to transmit the SL-SR, based on a mapping.

[0155] The WTRU may (e.g., if data arrives for sidelink transmission, if data is available for transmission, and / or the like) determine the codepoint and / or sequence to use in the transmission of the SL-SR to the GC, for example, based on a property of its data (e.g., based on an amount of data, a QoS of the data, and / or the like).

[0156] The WTRU may (e.g., if data arrives for sidelink transmission, if data is available for transmission, and / or the like) determine the resource to use to transmit a SL-SR (e.g., the SL-SR with the determined sequence), for example, based on the intended sidelink transmission period.

[0157] The WTRU may receive a sidelink grant (e.g., from the GC). In examples, the WTRU may receive a sidelink grant to use the sidelink resource. If the number of scheduled sidelink grant(s) is smaller than (e.g., less than) the WTRU’s buffer size, the scheduled grant may not be enough and / or sufficient for the WTRU’s sidelink transmission (e.g., the WTRU may determine that the sidelink grant is insufficient to transmit the data available for sidelink transmission). If the GC is a receiver (e.g., one of the indicated receivers) of the (e.g., sidelink) transmission, the WTRU may include its buffer information in the sidelink transmission (e.g., via a SL-MAC CE, a SL-BSR, a SL-DSR), for example, in a scheduled sidelink grant (e.g., one of the scheduled sidelink grants to request resource(s) to transmit more sidelink data). In examples, based on a determination that the sidelink grant is smaller than the threshold and / or based on a determination that the GC is an intended receiver of the (e.g., sidelink) transmission, the WTRU may include an indication of a buffer status associated with the WTRU in the (e.g., sidelink) transmission. In examples, the WTRU may send the (e.g., sidelink) transmission via the sidelink resource (e.g., where at least a portion of the data is sent via the transmission).

[0158] The WTRU may transmit (e.g., a first portion of the) sidelink data in the scheduled sidelink grant (e.g., and / or transmit a second portion of the sidelink data in the additional sidelink grant resource(s)).

[0159] Sensing and / or resource allocation for group(s) may be performed.

[0160] In sidelink, sidelink resource(s) may be scheduled by the network or autonomously selected by the WTRU for a (e.g., its own) transmission. For GC scheduling offloading, (e.g., it may be possible that) the GC may perform sensing and / or resource allocation by itself for the group. For example, a GC may autonomously perform sensing and / or select resources for the group (e.g., as described herein).

[0161] A WTRU may be (pre-)configured with multiple types of resources. For example, a WTRU (e.g., GC) may be (pre-)configured with multiple types of resources for transmission, reservation, and / or selection. A (e.g., each) type of a resource(s) (e.g., for resource transmission, reservation, and / or selection) may be associated with one or more of the following: the set of WTRU(s) using the resource; the type of WTRUs using the resources; the state of the WTRU using the resource; the scheduler of the resource (e.g., the type of resource); whether the resource (e.g., type of resource) is for HARQ feedback enabled and / or disabled PDU / reference-signals; whether the resource is for initial transmission and / or retransmission of a PDU / reference-signal; whether the resource (e.g., type of resource) is periodic or aperiodic; whether the resource (e.g., type of resource) is used for Uu and / or SL transmission; whether the resource (e.g., type of resource) is used for unicast groupcast, or broadcast; or a destination associated with the resource (e.g., type of resource).

[0162] A (e.g., each) type of a resource(s) (e.g., for resource transmission, reservation, and / or selection) may be associated with the set of WTRU(s) using the resource. For example, the WTRU may be (pre-)configured with a first (e.g., one) type of resources for a transmission. The WTRU may be (pre-)configured with a second (e.g., another) type of resources for other WTRU’s transmission (e.g., one or more member WTRUs in the group). The WTRU may be (e.g., further) (pre-)configured with a third type (e.g., another type) of resources for transmission of either itself or other WTRUs.

[0163] A (e.g., each) type of a resource(s) (e.g., for resource transmission, reservation, and / or selection) may be associated with the type of WTRUs using the resources. The WTRU may be (pre-)configured with multiple types of resources, in which a (e.g., each) type of a resource(s) may be associated with a (e.g., one) type of WTRU using the resource for transmission, reservation, and / or selection. For example, a WTRU (e.g., a member WTRU) may be (pre-)configured with at least two types of resources, in which the first type of resources may be used for power saving and / or RedCap WTRUs, and the second type of resources may be used for normal WTRUs.

[0164] In examples, a WTRU (e.g., a GC) may be (pre-)configured to schedule, reserve, and / or select resources for other WTRUs in the group. The WTRU may be (pre-)configured with at least two types of resources, in which the first type of resources may be reserved and / or scheduled for the power saving WTRUs and / or RedCap WTRUs, and the second type of resources may be reserved and / or scheduled for normal WTRUs. The WTRU may (e.g., then) determine which type of resources to use to schedule and / or reserve based on which WTRU is transmitting the scheduled and / or reserved resource.

[0165] A (e.g., each) type of resource(s) (e.g., for resource transmission, reservation, and / or selection) may be associated with the state of the WTRU using the resource. For example, the WTRU may be (pre- )configured with multiple types of resources, in which a (e.g., each) type of resources may be used for a (e.g., one) state of the WTRU. The WTRU may (e.g., then) determine which type of resources to use based on a state of the WTRU. The state of WTRU may be one or more of the following: RRC state (e.g., RRC connected, inactive, or idle); DRX state (e.g., DRX ON, or DRX inactive); power saving state (e.g., normal power saving state and / or power saving state on); or sensing state for resource allocation of the WTRU (e.g., non-power-saving sensing state (e.g., full sensing state), partial sensing state, and no sensing state). For example, the WTRU may be (pre-)configured with three types of resources, in which the first type of resources may be used for full sensing-based resource transmission, reservation, and / or selection, the second type of resources may be used for partial-sensing-based-resource transmission, reservation, and / or selection, and the third type of resources may be used for no-sensing-based resource transmission, reservation, and / or selection.

[0166] A (e.g., each) type of a resource(s) (e.g., for resource transmission, reservation, and / or selection) may be associated with the scheduler of the resource. For example, the WTRU may be (pre-)configured with multiple types of resources, in which a (e.g., each) type of resources may be associated with a (e.g.,one) scheduler. For example, the first type of resources may be scheduled by the gNB, the second type of resources may be scheduled by another node (e.g., a GC), and the third type of resources may be autonomously selected by the WTRU.

[0167] A (e.g., each) type of a resource(s) (e.g., for resource transmission, reservation, and / or selection) may be associated with whether the resource is for HARQ feedback enabled and / or disabled PDU / reference-signals. For example, the WTRU may be (pre-)configured and / or scheduled with three types of resources, in which the first type of resources allows the WTRU to transmit HARQ enabled PDU / reference-signal (e.g., only), the second type of resources allows the WTRU to transmit HARQ disabled PDU / reference-signal (e.g., only), and the third type of resources allows the WTRU to transmit either HARQ enabled and / or HARQ disabled PDUs and / or reference-signals.

[0168] A (e.g., each) type of a resource(s) (e.g., for resource transmission, reservation, and / or selection) may be associated with whether the resource is for initial transmission and / or retransmission of a PDU / reference-signal. For example, the WTRU may be (pre-)configured with three types of resources, in which the first type of resources may be used for initial transmission of a PDU / reference-signal (e.g., only), the second type of resources may be used for retransmission of a PDU / reference-signal (e.g., only), and the third type of resources may be used for either initial or retransmission of a PDU / reference-signal.

[0169] A (e.g., each) type of a resource(s) (e.g., for resource transmission, reservation, and / or selection) may be associated with whether the resource is a periodic or an aperiodic resource(s). For example, the WTRU may be (pre-)configured with three types of resources, in which the first type of resources may be used for periodic reservation and / or transmission, the second type of resources may be used for aperiodic transmission, and the third type of resources may be used for either periodic or aperiodic transmission and / or reservation.

[0170] A (e.g., each) type of a resource(s) (e.g., for resource transmission, reservation, and / or selection) may be associated with whether the resource is used for Uu and / or SL transmission. For example, the WTRU may be (pre-)configured with multiple types of resources, in which the first type of resources may be used for Uu (e.g., uplink transmission and / or downlink reception), the second type of resources may be used for sidelink, and the third type of resources may be use for either sidelink or Uu.

[0171] A (e.g., each) type of a resource(s) (e.g., for resource transmission, reservation, and / or selection) may be associated with whether the resource is used for unicast, groupcast, or broadcast. For example, the WTRU may be (pre-)configured with three types of resources, in which the first type of resources may be used for unicast, the second type of resources may be used for groupcast, and the third type of resources may be used for broadcast transmission.

[0172] A (e.g., each) type of a resource(s) (e.g., for resource transmission, reservation, and / or selection) may be associated with a destination associated with the resource. For example, the WTRU may be (pre- )configured with multiple types of resources, in which a (e.g., each) type of resources may be associated with a (e.g., one) destination (e.g., a destination ID). The destination may be used to indicate the receiver of the transmission. The destination may (e.g., alternatively or also) be used to indicate the service associated with the transmission. The WTRU may (e.g., then) determine which type of resources to use based on the destination associated with its (e.g., the WTRU’s) transmission.

[0173] A WTRU may determine to transmit a resource request to the GC. For example, a WTRU (e.g., a member WTRU) may have PDU / reference-signal for its (e.g., the WTRU’s) transmission. The WTRU may (e.g., then) send the resource request to the GC. In the resource request, the WTRU may indicate one or more of the following information: the information regarding the requested resource, such as the number of resources, the bandwidth of each resources, the window of associated with the set of resources; or the information regarding the PDU / reference-signal in the buffer of the WTRU, such as the number of PDUs in the buffer, the QoS (e.g., latency, reliability, accuracy, priority, and / or the like) associated with the PDU / reference-signal in the buffer.

[0174] In examples, the WTRU may use a (e.g., one) message to send the resource request. In examples, the WTRU may use multiple messages to send the resource request. The WTRU may send one or more resource request messages using one or any combination of a SCI, a PC5 MAC CE, a PC5 RRC, or a NAS message (e.g., to request transmission resource from the GC). For example, the WTRU may use a (e.g., new) SCI format (e.g., a new first stage SCI format or a new second stage SCI format) to transmit resource request format to the GC. For example, the WTRU may be (pre-)configured with a PC5 MAC CE to indicate information regarding a requested resource and / or the information regarding the PDU / reference- signal traffic. The WTRU may use PC5 RRC to request the GC for a transmission resource for its (e.g., the WTRU’s) PDU / reference-signal. The WTRU may use PC5 RRC message to request periodic transmission resources. The WTRU may use PC5 MAC CE to request for a dynamic transmission resource.

[0175] The WTRU (e.g., a member WTRU) may use one or more of the following channels to send the resource request to the GC: a (e.g., new) physical channel designed for sending resource requests; PSCCH; or PSSCH.

[0176] The WTRU (e.g., a member WTRU) may use a (e.g., new) physical channel designed for sending resource requests, to send a resource request to the GC. For example, the WTRU may be (pre-)configured with a physical channel to send resource-request to the GC. The WTRU may (e.g., then) use the physical channel to request a resource for a PDU / reference-signal transmission.

[0177] The WTRU (e.g., a member WTRU) may use PSCCH to send a resource request to the GC. For example, the WTRU may be (pre-)configured to transmit a resource request message using first stage SCI. The WTRU may be (pre-)configured with a (e.g., new) first stage SCI format, which may be used to transmit to the GC and / or to indicate that the WTRU is requesting transmission resources scheduled by the GC. For example, the WTRU may be (pre-)configured with a second SCI format and / or PC5 MAC CE, which may be transmitted using PSSCH channel (e.g., to convey the information regarding the resource request to the GC). The WTRU may use the first stage SCI (e.g., which may be transmitted using PSCCH), to indicate the availability of the second stage SCI and / or PC5 MAC CE for resource request.

[0178] The WTRU (e.g., member WTRU) may use PSSCH to send a resource request to the GC. For example, the WTRU may be (pre-)configured to transmit a resource request message using PC5 MAC CE, PC5 RRC, and / or NAS message. The WTRU may (e.g., then) use PSSCH to convey a message to request the resource for the WTRU transmission.

[0179] A WTRU may determine which resource to use to send the resource request. For example, the WTRU may determine the resource to transmit one or more resource request message. In examples, the WTRU may perform resource allocation to select one or more resources to transmit the resource request message. In examples, the WTRU may be (pre-)configured with an association with (e.g., between) one or more resource(s) to transmit the resource request message and the expected transmission resource for its (e.g., the WTRU’s) PDU / reference-signal. If the WTRU is (pre-)configured with multiple resources to transmit the resource request message, the WTRU may select a (e.g., one of the) (pre-)configured resource based on an I D(s) (e.g., such as member WTRU ID, source ID, and / or destination ID).

[0180] FIG. 3 depicts an example determination of which resource to transmit a resource request message to, based on expected transmission resources.

[0181] As shown in FIG. 3, the WTRU may have data to be transmitted within the expected transmission resource window. The WTRU may be (pre-)configured with an association with (e.g., between) the resource request window and the expected transmission resource window. The WTRU may (e.g., then) select a (e.g., one of the) resource(s) in the resource-request window to transmit the resource request message to request the GC for a transmission resource in the expected transmission resource window.

[0182] A WTRU may receive a resource request from a member WTRU for transmission resources. For example, a WTRU (e.g., GC) may receive resource-request from one or more member WTRUs for transmission resources. In examples, the WTRU may trigger resource allocation for a (e.g., each) member WTRU if the WTRU receives the resource-request from the member WTRU. In examples, the WTRU may trigger resource allocation for multiple member WTRUs. The WTRU may include (e.g., combine) theresource allocation of multiple member WTRUs in a (e.g., one) resource allocation procedure. This approach may be motivated to reduce the number of resource allocation process for the GC.

[0183] A WTRU may determine whether to perform resource allocation or request transmission resources for the group. In examples, a WTRU may receive resource-request from member WTRUs for transmission resource(s). For example, the WTRU may trigger resource allocation to select the transmission resource(s) for the group. In examples, the WTRU may request the gNB for transmission resource(s) for the group. The WTRU may determine whether to perform resource allocation or request transmission resource(s) for the group based on one or more of the following: (pre-)configuration from the gNB; QoS parameters associated with the PDU / reference-signal of the member WTRUs; one or more parameters associated with the requested resources; indication(s) from the member WTRU(s); the type of requested resources; the set of WTRUs using the resource; the destination associated with the requested resources; whether the resource is for HARQ feedback enabled and / or disabled PDU / reference-signals; whether the resource is for initial transmission and / or retransmission of a PDU / reference-signal; and / or whether the resource is a periodic resource or an aperiodic resource.

[0184] The WTRU may determine whether to perform resource allocation or request transmission resource(s) for the group based on (pre-)configuration from the gNB. For example, the WTRU may be (preconfigured to perform resource allocation for the group. The WTRU may (e.g., then) trigger resource allocation if the WTRU receives the resource-request from a member WTRU. For example, the WTRU may be (pre-)configured to request the transmission resource from the network for the member WTRUs in the group. If the WTRU receives the resource-request from a member WTRU in the group, the WTRU may trigger sending the resource-request to the gNB to request resource for the group.

[0185] The WTRU may determine whether to perform resource allocation or request transmission resource(s) for the group based on one or more QoS parameters associated with the PDU / reference-signal of the member WTRUs. For example, the WTRU may request the resource from the gNB if the PDB associated with the PDU / reference-signal of the member WTRU is larger than a (pre-)configured threshold. The WTRU may (e.g., otherwise) trigger resource allocation for the member WTRUs. For example, the WTRU may trigger resource allocation for the member WTRU if the priority is smaller than a (pre- )configured threshold. The WTRU may (e.g., otherwise) request the transmission resource for the member WTRUs from the gNB.

[0186] The WTRU may determine whether to perform resource allocation or request transmission resource(s) for the group based on one or more parameters associated with the requested resources. For example, the WTRU may trigger resource allocation for the member WTRU if the bandwidth of therequested resource from the member WTRU is smaller than a (pre-)configured threshold. The WTRU may (e.g., otherwise) request the transmission resource from the gNB.

[0187] The WTRU may determine whether to perform resource allocation or request transmission resource(s) for the group based on an indication from the member WTRU. For example, the WTRU may receive a request from the member WTRU of whether to request the resource from the gNB (e.g., or not). The WTRU may (e.g., then) request the resource from the gNB if it received such a request from the member WTRU. The WTRU may (e.g., otherwise) trigger resource allocation for the member WTRU.

[0188] The WTRU may determine whether to perform resource allocation or request transmission resource(s) for the group based on the type of requested resources. For example, the WTRU may trigger resource allocation for sidelink resources, and / or the WTRU may request resource(s) from the gNB for uplink resources. The WTRU may (e.g., then) indicate the selected and / or scheduled resource to the member WTRU.

[0189] The WTRU may determine whether to perform resource allocation or request transmission resource(s) for the group based on the set of WTRU(s) using the resource. For example, the GC may be (pre-)configured with two sets of member WTRUs in which the first set of member WTRUs may cause (e.g., require) the GC to request a transmission resource from the gNB and the second set of member WTRUs may cause (e.g., require) the GC to perform resource allocation. The GC may (e.g., then) determine whether to request resource from the gNB and / or trigger resource allocation based on whether the WTRU receives the resource request from the first set or second set of member WTRUs. For example, if the WTRU receives the resource request from the first set of member WTRUs, the WTRU may request the resource from the gNB. If the WTRU (e.g., alternatively) receives the resource request from the second set of member WTRUs, the WTRU may perform resource allocation to select resources for the member WTRUs.

[0190] The WTRU may determine whether to perform resource allocation or request transmission resource(s) for the group based on a destination associated with the requested resources. For example, the WTRU may be (pre-)configured with two sets of destinations associated with the requested resources, in which the first set of destinations may cause (e.g., require) the WTRU to request transmission resource from the gNB and the second set of destinations may cause (e.g., require) the WTRU to perform resource allocation. The WTRU may (e.g., then) determine whether to request resource from the gNB and / or trigger resource allocation based on whether the WTRU receives the resource request for the first set of destinations or the second set of destinations. For example, if the WTRU receives the resource request from the first set of destinations, the WTRU may request the resource from the gNB. If the WTRU (e.g.,alternati vely) receives the resource-request from the second set of destinations, the WTRU may perform resource allocation to select resources for the member WTRUs.

[0191] The WTRU may determine whether to perform resource allocation or request transmission resource(s) for the group based on whether the resource is for HARQ feedback enabled and / or disabled PDU / reference-signals. For example, the WTRU may perform resource allocation for HARQ disabled PDUs / reference-signals and it may request resource from the gNB for HARQ enabled PDUs / reference- signals. The WTRU may (e.g., then) indicate the selected and / or scheduled resource for the member WTRUs.

[0192] The WTRU may determine whether to perform resource allocation or request transmission resource(s) for the group based on whether the resource is for initial transmission and / or retransmission of a PDU / reference-signal. For example, the WTRU may request the resource from gNB for a (e.g., initial) transmission of a PDU / reference-signal and / or it may perform resource allocation for retransmission of a PDU / reference-signal.

[0193] The WTRU may determine whether to perform resource allocation or request transmission resource(s) for the group based on whether the resource is a periodic or an aperiodic resource(s). For example, the WTRU may request the resource for member WTRU for periodic resources. The WTRU may perform resource allocation for member WTRU for aperiodic resources. The WTRU may reduce the latency in obtaining resources for aperiodic transmission (e.g., using this approach).

[0194] A WTRU may trigger resource allocation for the group. The GC may trigger resource allocation for the group based on one or more of the following: reception of resource-request from one or more member WTRUs; a number of requested resources from the member WTRUs; a number of resource request messages received from member WTRUs; or QoS associated with the resource request and / or the PDU / reference-signal of the member WTRUs.

[0195] The GC may trigger resource allocation for the group based on reception of resource request(s) from one or more member WTRUs. In examples, the WTRU may trigger resource allocation for a (e.g., each) member WTRU(s). The WTRU may trigger resource selection for the requested WTRU(s) (e.g., if the WTRU receives a resource-request from a (e.g., one) member WTRU). The WTRU may (e.g., then) indicate the selected resources to the requested WTRU(s). In examples, the WTRU may trigger resource allocation for multiple member WTRUs. The WTRU may combine one or multiple resource-requests from one or more member WTRUs to trigger resource allocation. The WTRU may (e.g., then) indicate and / or schedule the selected resources to the member WTRU(s). The WTRU may use a message (e.g., one message) to schedule selected resources for multiple WTRUs (e.g., groupcast transmission), in which theWTRU may indicate whether an (e.g., each) indicated resource is used for which member WTRU. The WTRU may use an (e.g., one) ID (e.g., group ID) to indicate that the message is for group scheduling.

[0196] The GC may trigger resource allocation for the group based on a number of requested resources from the member WTRUs. For example, the WTRU may trigger resource allocation for one or multiple member WTRUs if the number of requested resources is greater than a (pre-)configured threshold.

[0197] The GC may trigger resource allocation for the group based on the number of resource-request messages received from member WTRUs. For example, the WTRU may trigger resource allocation for one or multiple member WTRUs if the number of resource-request messages is greater than a (pre-)configured threshold.

[0198] The GC may trigger resource allocation for the group based on the QoS associated with the resource-request and / or the PDU / reference-signal of the member WTRU. For example, the WTRU may trigger resource allocation for the member WTRU if the remaining PDB of a PDU / reference-signal is smaller than a first threshold (e.g., a (pre-)configured threshold) and greater than a second threshold (e.g., another (pre-)configured threshold).

[0199] A WTRU may determine the parameters for resource selection. The WTRU (e.g., GC) may trigger resource allocation for the group (e.g., for one or more member WTRUs and / or the WTRU itself). The WTRU may (e.g., then) determine one or more of the following parameters to access the resource and / or to perform for resource reservation and / or selection: the number of selected resources; the channel occupation time (COT) (e.g., COT duration); a resource allocation window; the priority associated with the selected resource; the reference signal received power (RSRP) threshold to determine the availability of a reserved resource; or one or more parameters to access the resource (e.g., which may be used to access the shared resource such as unlicensed spectrum). For example, the WTRU may determine one or more of the following parameters to access the resource: the channel access priority class (CAPC); the clear channel access (CCA) duration; the LBT type (e.g., whether the WTRU should perform short CCA (e.g., LBT type 2-like channel access procedure) or long CCA (e.g., LBT type 1 -like channel access procedure); CPE used for transmission; contention window size; or the LBT energy detection threshold to determine the availability of a channel. Contention window size may include the current contention window (CWp), the minimum, and / or the maximum contention window associated with the channel access priority class p (e.g., CWj Is,, ' CWm11inI fiL}J, ' and / or CWmIaxfnLJ ).

[0200] One or more of the above parameters may be determined based on one or more of the following: (pre-)configuration from the network; an indication and / or request from the member WTRU(s); or one or more QoS parameters of the PDU / reference-signal reported and / or indicated from the member WTRU(s).

[0201] One or more of the above parameters may be determined based on (pre-)configuration from the network. In examples, the WTRU may be (pre-)configured with a (e.g., one) set of parameters (e.g., RSRP threshold to determine the availability of a reserved resource, priority associated with the selected resource, CAPO to access the channel) to perform resource allocation and / or access the channel for the group. The WTRU may (e.g., then) use the (pre-)configured parameters to select transmission resources and / or access the channel for the group. For example, the WTRU may be (pre-)configured with one CAPC to access the channel for the group. In examples, the WTRU may be (pre-)configured with a first set of parameters to perform resource allocation and / or access the channel (e.g., for itself). The WTRU may be (e.g., further) (pre-)configured with a second set (e.g., another set) of parameters (e.g., delta_RSRP_threshold, delta_priority, delta_CAPC), which may be added to the first set of parameters if the WTRU performs resource allocation and / or access to the channel for the group.

[0202] One or more of the above parameters may be determined based on an indication and / or request from the member WTRUs. In examples, the WTRU may determine the resource selection window based on the indication from the member WTRU. The WTRU may first receive resource-request from one or more member WTRUs. In the resource-request message, the WTRU may be indicated the delay budget associated with the requested resource. The WTRU may (e.g., then) determine the resource selection window based on the delay budget received from the member WTRUs it is selecting resource for. In examples, the WTRU may receive the indication from the member WTRUs regarding the priority of the selected resources. The WTRU may (e.g., then) determine the priority associated with its selected resources based on the priorities received from the member WTRUs it is selecting resources for. The WTRU may select the highest priority among (e.g., all) the indicated priority. The WTRU may (e.g., alternatively) select the lowest priority among (e.g., all) the indicated priority. In examples, the WTRU may receive the indication from the member WTRUs regarding the CAPC to access the channel. The WTRU may (e.g., then) determine the CAPC to access the channel for the member WTRUs based on the CAPC received from the member WTRUs. The WTRU may select a (e.g., the lowest) CAPC among (e.g., all) one or more of the indicated CAPC. The WTRU may (e.g., alternatively) select the highest CAPC among all the indicated CAPC.

[0203] One or more of the above parameters may be determined based on one or more QoS parameters of the PDU / reference-signal reported and / or indicated from the member WTRUs. In examples, the WTRU may determine the priority associated with its selected resource based on the priority of the PDU / reference-signal received from the member WTRUs. The WTRU may use a (e.g., the highest) priority among (e.g., all) the priorities of the PDU / reference-signals received from the member WTRU. In examples, the WTRU may determine the CAPC to access the channel for the member WTRUs based onthe CAPC associated with the PDU / reference-signal received from the member WTRUs. The WTRU may select a (e.g., the lowest) CAPC among one or more of (e.g., all) the CAPC of the PDU / reference-signals received from the member WTRUs. The WTRU may (e.g., alternatively) select a (e.g., the highest) CAPC among (e.g., all) the CAPC of the PDUs / reference-signals received from the member WTRUs. For example, the WTRU may be (pre-)configured with a first set of parameters to perform resource allocation and / or access the channel, which may be associated with the priority of the PDU / reference-signal. The WTRU may be (e.g., may also be further) (pre-)configured with a second set of parameters (e.g., delta_RSRP_threshold, delta_priority, delta_CAPC) to be added to the first set of parameters if the WTRU performs resource allocation and / or access the channel for the group. The WTRU may (e.g., then) determine the priority to use, to perform resource allocation and / or access the channel. The priority may be determined based on the QoS of the PDU / reference-signal reported from the member WTRUs (e.g., the priority may be the highest reported priority). The WTRU may (e.g., then) determine the set of parameters to perform resource allocation and / or access the channel (e.g., by combining the first and the second set of parameters.)

[0204] A WTRU may indicate the selected and / or scheduled resources for the group. If the WTRU performs resource allocation and / or receiving the scheduled resource (e.g., from the gNB), the WTRU (e.g., GC) may send a group-scheduling message to the member WTRU. A group-scheduling message may be used to schedule, indicate, and / or reserve the transmission resource for the group (e.g., for one or more member WTRUs and / or for the WTRU itself). The WTRU may indicate to the member WTRUs whether the message may be used for conveying the group-scheduling for the group. A group-scheduling may be indicated using one or more of the following: a dedicated resource for group-scheduling message; SCI; PC5 MAC CE; or PC5 RRC.

[0205] Group-scheduling may be indicated (e.g., by a WTRU) using a dedicated resource for group- scheduling message. In examples, the WTRU may be (pre-)configured with a dedicated resource for transmission of group-scheduling to the member WTRU. A dedicated resource may be a periodic resource(s). The WTRU (e.g., the GC) may (e.g., then) transmit the group-scheduling in the dedicated resource. The member WTRUs may monitor a group-scheduling message in a (e.g., each) dedicated resource to determine whether there is a (e.g., any) group-scheduling from the GC to assign transmission resource (e.g., for itself). In examples, the WTRU (e.g., GC) may be (pre-)configured with an association between the set of scheduling resource(s) and the resource for transmission of scheduling decision. The WTRU may (e.g., then) determine which resource to transmit the group-scheduling to the member WTRUs based on which resource the WTRU is scheduling for the member WTRUs in the group.

[0206] Group-scheduling may be indicated (e.g., by a WTRU) using SCI. In examples, the GC may be configured with a dedicated ID (e.g., group-scheduling destination ID) to indicate the group-scheduling message to the member WTRUs. The member WTRU may (e.g., then) determine the transmission is for group-scheduling if the indicated destination ID matches the (pre-)configured destination ID for group- scheduling (e.g., group-scheduling destination ID). In examples, the WTRU may be (pre-)configured with a bitfield in the SCI to indicate whether the associated transmission is for group-scheduling indication from the GC. In examples, the WTRU may be (pre-)configured with a second SCI format, which may be used to indicate that the transmission is a group-scheduling message from the GC. If the member WTRU receives the SCI format, the WTRU may decode the message to determine the scheduled resource for its transmission.

[0207] Group-scheduling may be indicated (e.g., by a WTRU) using PC5 MAC CE. For example, the WTRU may be (pre-)configured with a PC5 MAC CE (e.g., which may be used to convey the group- scheduling from the GC). The WTRU may (e.g., then) decode the PC5 MAC CE to determine which resource may be scheduled (e.g., for itself).

[0208] Group-scheduling may be indicated (e.g., by a WTRU) using PC5 RRC. For example, the WTRU may be (pre-)configured with a PC5 RRC message, which may be used to convey the group-scheduling from the GC. The WTRU may (e.g., then) decode the PC5 RRC to determine which resource may be scheduled (e.g., for itself).

[0209] FIG. 4 depicts an example determination of which resource to transmit a group-scheduling message on based on the associated scheduled resources. As shown in FIG. 4, the WTRU may be (pre- )config ured with a periodic set of resources to transmit a group-scheduling message for the group. Each set of resources may be used to indicate scheduling decision for an associated resource(s). The WTRU may (e.g., then) determine which resource may be used to transmit a group-scheduling message based on its associated scheduled resources. As shown in FIG. 4, the WTRU may use the second period to transmit a group-scheduling message (e.g., in PC5 MAC CE) to indicate its scheduling decision (e.g., of which WTRU is using which resource in the second set of scheduled resources).

[0210] A WTRU may reserve resource(s) for a group. For example, if resources are selected for the group, the GC may perform transmission in a (e.g., one) resource and reserve the set of resources for the group. The WTRU may use SCI (e.g., first stage SCI) to reserve the resource for the group. The WTRU may indicate (e.g., in the SCI) the type of resources it is reserving. For example, the WTRU may indicate whether the set of resources is reserved for the WTRU itself or for the group (e.g., for one or more member WTRUs and / or the WTRU itself).

[0211] In examples, the WTRU may be (pre-)configured with a bitfield (e.g., in the first SCI), in which a (e.g., each) codepoint may be associated with a (e.g., one) type of resources to be reserved. For example, the WTRU may be configured with a (e.g., one) codepoint to indicate that it is reserving the set of resources for the group and another codepoint to indicate that it is reserving the set of resources for itself.

[0212] In examples, the WTRU may be (pre-)configured with a set of second SCI formats in which a (e.g., each) SCI format may be used to indicate and / or reserve a (e.g., one) type of resource(s). The WTRU may be (pre-)configured with a (e.g., one) second SCI format to reserve a set of resources for the group (e.g., one or more member WTRUs) and another SCI format to reserve a set of resources for itself. The WTRU may (e.g., then) reserve a set of resources for the group by using the second stage SCI format associated with group reservation.

[0213] FIG. 5 depicts an example determination (e.g., by a GC) to use the first period to reserve the periodic resource for the group. As shown in FIG. 5, the WTRU may select a periodic resource for the group. The WTRU may use the resource in the first period to reserve the periodic resources for the group.

[0214] FIG. 6 depicts an example determination (e.g., by a GC) to use the first resource to reserve a set of resources for the group. As shown in FIG. 6, the WTRU may reserve a COT for the group. The WTRU may use the first resource in the COT to reserve the resource for the group.

[0215] A WTRU may determine the availability of a resource reserved for a group. For example, a WTRU (e.g., a normal sidelink WTRU) may be (pre-)configured to perform WTRU autonomous sensing and resource allocation (i.e., Mode 2 sensing and resource allocation). The WTRU may (e.g., then) determine the availability of a resource reserved by another WTRU. The WTRU may (e.g., first) determine whether the resource is (e.g., still) selectable based on the type of reserved resource. The WTRU may be (pre- )configured with multiple set(s) of parameters (e.g., the RSRP threshold, priority associated with the reserved resource, and / or the like) to determine the availability of a reserved resource, in which a (e.g., each) set of parameters may be associated with a (e.g., one) type of resource. The type of reserved resource may be indicated in the SCI associated with the reservation transmission. The WTRU may (e.g., if the WTRU detects a reserved resource) determine the type of reserved resource (e.g., in SCI of the reservation transmission). The WTRU may (e.g., then) determine which set of parameters to use based on the detected type of reserved resource. In examples, the WTRU may (e.g., then) determine whether the reserved resource is available based on whether the measured RSRP is smaller than a threshold. If the RSRP is smaller than a (pre-)configured threshold, the WTRU may determine that the resource is still available, and it (e.g., the resource) can be selected. If the RSRP is larger than the (pre-)configured threshold, the WTRU may determine that the reserved resource is not selectable, and that the reservedresource is not selected. In examples, if the resource is reserved by the group, the WTRU may determine that the resource is not available, and that the resource is not selected.

[0216] A WTRU may perform pre-emption based on detection of a resource reserved for a group. For example, a WTRU (e.g., a normal sidelink WTRU) may perform pre-emption checking to determine whether its reserved resource is still available. The WTRU may detect another WTRU reserving its reserved resource. The WTRU may (e.g., then) determine whether its reserved resource is (e.g., still) available. If the reserved resource is (e.g., still) available, the WTRU may (e.g., continue to) transmit in the reserved resource. If the reserved resource is not available, the WTRU may trigger resource allocation to reselect another resource for its transmission. The WTRU may determine whether the resource is (e.g., still) available based on the type of reserved resource. For example, if the other WTRU reserve the resource for the group, the WTRU may yield the reserved resource. The WTRU may (e.g., otherwise) continue using the reserved resource.

[0217] A WTRU (e.g., GC) may perform sensing and resource allocation for a group. The WTRU may be (pre-)configured with a dedicated set of parameters (e.g., delta_RSRP_threshold, delta_priority, delta_CAPC, etc.) to perform resource allocation and / or channel access for the group. The WTRU may (e.g., if the WTRU receives the resource-request from the member WTRUs) perform resource allocation and / or channel access for the group, for example, in which the parameters used to perform resource allocation and / or channel access may be determined based on the resource request from the member WTRUs and / or the dedicated parameters (pre-)configured for resource allocation for the group. The WTRU may (e.g., if the WTRU selects resources for the group) use a (pre-)configured destination (e.g., group- scheduling destination ID) to convey the group-scheduling message to the member WTRUs (e.g., which may be used to help the member WTRUs identify whether the message is used for group-scheduling). The WTRU may perform one or more of the following.

[0218] A WTRU (e.g., GC) may be (pre-)configured with a set of parameters (e.g., delta_RSRP_threshold, delta_priority, delta_CAPC, etc.) to perform resource selection for the group; and / or a destination ID (e.g., group-scheduling destination ID) to transmit group-scheduling for member WTRUs in the group in sidelink (e.g., to support the member WTRUs aware of the scheduling message).

[0219] If the WTRU receives a resource request from the member WTRUs, the WTRU may determine the parameters for resource allocation and / or channel access based on the resource-request from the member WTRUs and / or the dedicated parameters (pre-)configured for resource allocation for the group. For example, the WTRU may determine the number of resources to select based on the number of requests from the member WTRUs. For example, the WTRU may increase priority of the requested data (e.g., a delta_priority) to prioritize the transmission resource for the group.

[0220] The WTRU may transmit group-scheduling to the member WTRUs, which may include the (pre- )configured destination (e.g., group-scheduling destination ID (e.g., in SCI)) and / or the scheduled resources for a (e.g., each) member WTRU(s) (e.g., in a PC5 MAC CE for group-scheduling).

[0221] The WTRU may transmit the reservation (e.g., in SCI) to indicate and / or reserve the resource for the group.

[0222] Sidelink HARQ retransmission scheduling may be performed (e.g., as described herein).

[0223] The GC may schedule sidelink resource(s) for initial and / or retransmission of the WTRU and / or may schedule retransmission resources for HARQ enabled TB.

[0224] A WTRU may indicate whether a scheduling resource can be used for HARQ enabled and / or disabled. In examples, a WTRU (e.g., GC) may schedule a transmission resource for a WTRU (e.g., member WTRU). The WTRU may indicate to the member WTRU whether the scheduled resource may be used for HARQ enabled and / or disabled PDU / reference-signal. For example, the WTRU may indicate to the member WTRU that the scheduled resource may be used for HARQ disabled PDU / reference-signal (e.g., only). For example, the WTRU may indicate to the member WTRU that the scheduled resource may be used for HARQ enabled PDU / reference-signal (e.g., only). In examples, the WTRU may indicate to the member WTRU that the scheduled resource may be used for either HARQ enabled or HARQ disabled PDU / reference-signal.

[0225] A WTRU may indicate the destination(s) associated with the scheduled resource. In examples, the GC may transmit a group-scheduling message to the member WTRU to indicate and / or schedule transmission resource for a member WTRU. The WTRU may (e.g., also) indicate the destination associated with the scheduled transmission resource (e.g., L2 destination ID). If the member WTRU receives a group-scheduling message having an indicated destination (e.g., L2 destination ID), the member WTRU may (e.g., then) determine which PDU / reference-signal to transmit in the scheduled resource based on the indicated destination in the group-scheduling message. For example, the WTRU may use the scheduled resource for PDU / reference-signal associated with the indicated destination. For example, the WTRU may prioritize the PDU / reference-signal associated with the indicated destination. The WTRU may (e.g., also) transmit PDU / reference-signal associated with another (e.g., other) destination, for example if the PDU / reference-signal associated with the indicated destination is (e.g., already) transmitted and / or there is no PDU / reference-signal associated with the indicated destination.

[0226] In examples, the WTRU may be indicated in a group-scheduling message to use the scheduled and / or indicated resource to transmit to one or more WTRUs in the group. In examples, the WTRU may be indicated (e.g., in the group-scheduling message) to use the scheduled and / or indicated resource to transmit PDU / reference-signal for the group (e.g., using groupcast transmission). The WTRU may (e.g.,then) prioritize the PDU / reference-signal associated with the indicated destination to transmit in the indicated and / or scheduled resource.

[0227] A WTRU may indicate whether the scheduled WTRU should (e.g., needs to) monitor HARQ feedback. In examples, a WTRU (e.g., GC) may determine which WTRU(s) to monitor HARQ ACK / NACK for the transmission by a member WTRU in its indicated and / or scheduled resource. The WTRU may (e.g., then) indicate a (e.g., such) determination to the member WTRU. The WTRU may determine one or more of the following WTRUs (e.g., to monitor the HARQ ACK / NACK feedback): the member WTRU; the GC; another WTRU in the group; or both the member WTRU and the GC.

[0228] The WTRU may indicate such information (e.g., which WTRU is monitored, and / or for HARQ ACK / NACK feedback) using SCI, MAC CE, PC5 RRC, or a new message to convey the indication. For example, the WTRU may dynamically indicate whether it monitors HARQ ACK / NACK feedback for the member WTRU in a group-scheduling message. The WTRU may send a group-scheduling message, which may, for example, indicate the transmission resource for the member WTRU and / or implicitly / explicitly indicate whether it monitors HARQ ACK / NACK feedback for the transmission resource for the member WTRU. In examples, the WTRU may send a PC5 RRC message to indicate to the member WTRU if / whether it (e.g., the WTRU) monitors HARQ ACK / NACK feedback for the member WTRU and / or if / whether the member WTRU may (e.g., needs to) monitor HARQ ACK / NACK feedback.

[0229] A WTRU may determine which WTRU(s) to monitor the HARQ ACK / NACK for the member WTRUs. In examples, a WTRU (e.g., GC) may schedule a transmission resource to the member WTRU. The WTRU may determine to monitor HARQ ACK / NACK associated with the transmission in the scheduled and / or indicated of the member WTRU. The WTRU may decode the SCI transmitted in the scheduled resource to determine whether the member WTRU transmit a HARQ enabled or disabled PDU / reference- signal. If SCI indicates HARQ enabled is transmitted, the WTRU may (e.g., then) monitor the HARQ ACK / NACK feedback associated with the transmission of the member WTRU.

[0230] The WTRU (e.g., GC) may (e.g., first) determine which WTRU(s) to monitor the HARQ ACK / NACK feedback associated with the transmission of the member WTRU (e.g., in the resource indicated and / or scheduled by the WTRU) based on one or more of the following: the link quality between the WTRU and the member WTRU; the link quality between the WTRU and the receiver of the member WTRU; the link quality between the member WTRU and its receiver; the destination(s) associated with the transmission in the scheduled / indicated resource; the association between the member WTRU and another WTRU; or the QoS of the PDU / reference-signal transmitted in the scheduled / indicated resource.

[0231] The WTRU may determine which WTRU(s) are to monitor the HARQ ACK / NACK feedback associated with the transmission of the member WTRU based on the link quality between the WTRU andthe member WTRU. In examples, the WTRU may determine to monitor and / or overhear the HARQ ACK / NACK feedback associated with the transmission of the member WTRU if the SL-RSRP of the link between the two WTRUs is greater than a (pre-)configured threshold. The WTRU may (e.g., otherwise) indicate to the member WTRU to monitor the HARQ ACK / NACK feedback (e.g., for itself). In examples, the WTRU may monitor and / or overhear the HARQ ACK / NACK feedback associated with the transmission of the member WTRU if the distance between two WTRUs is smaller than a (pre-)configured threshold. The WTRU may (e.g., otherwise) indicate to the member WTRU to monitor the HARQ ACK / NACK feedback (e.g., for itself).

[0232] The WTRU may determine which WTRU(s) are to monitor the HARQ ACK / NACK feedback associated with the transmission of the member WTRU based on the link quality between the WTRU and the receiver of the member WTRU. In examples, the WTRU may determine to monitor and / or overhear the HARQ ACK / NACK feedback from the receiver of the transmission from the member WTRU if the SL-RSRP of the link between the receiver of the member WTRU and itself is greater than a (pre-)configured threshold. The WTRU may (e.g., otherwise) indicate to the member WTRU to monitor the HARQ ACK / NACK feedback for itself. In examples, the WTRU may determine to monitor / overhear the HARQ ACK / NACK feedback from the receiver of the transmission from the member WTRU if the distance between the two WTRUs is smaller than a (pre-)configured threshold. The WTRU may (e.g., otherwise) indicate the member WTRU to monitor the HARQ ACK / NACK feedback for itself.

[0233] The WTRU may determine which WTRU(s) are to monitor the HARQ ACK / NACK feedback associated with the transmission of the member WTRU based on the link quality between the member WTRU and its receiver. For example, the WTRU may determine to monitor and / or overhear the HARQ ACK / NACK feedback from the receiver of the transmission from the member WTRU if the SL-RSRP of the link between the member WTRU and the receiver is smaller than a (pre-)configured threshold. The WTRU may (e.g., otherwise) indicate to the member WTRU, to monitor the HARQ ACK / NACK feedback (e.g., for itself).

[0234] The WTRU may determine which WTRU(s) are to monitor the HARQ ACK / NACK feedback associated with the transmission of the member WTRU based on the destination(s) associated with the transmission in the scheduled and / or indicated resource. For example, the WTRU may be (pre-)configured with a set of destinations, in which the WTRU may overhear and / or monitor the HARQ ACK / NACK feedback for the member WTRU. In examples, the GC may indicate which destination can be transmitted in the scheduled and / or indicated resource. The GC may (e.g., then) determine to monitor HARQ ACK / NACK feedback for the member WTRU if the indicated destination ID is within the (pre-)configured set of destinations to overhear and / or monitor HARQ ACK / NACK feedback. In examples, the member WTRUmay indicate which destination ID to transmit in the scheduled and / or indicated resource. The GC may (e.g., then) determine to monitor HARQ ACK / NACK feedback for the member WTRU if the indicated destination ID is within the (pre-)configured set of destinations to overhear and / or monitor HARQ ACK / NACK feedback. For example, the WTRU may monitor the HARQ ACK / NACK feedback for the member WTRU if the WTRU (e.g., itself) is a (e.g., one of the) receiver(s) of the transmission. For example, the WTRU may monitor HARQ ACK / NACK feedback for the member WTRU if the receiver is a (e.g., one) member of the group.

[0235] The WTRU may determine which WTRU(s) are to monitor the HARQ ACK / NACK feedback associated with the transmission of the member WTRU based on the association between the member WTRU and another WTRU. For example, the member WTRU may be (e.g., have an) associated with an assistant WTRU (e.g., which may be used to support the WTRU in signal transmission and / or reception). The assistant WTRU and the member WTRU may have a wired connection. The WTRU may (e.g., then) indicate (e.g., instruct) the assistant WTRU to monitor the HARQ ACK / NACK feedback for the member WTRU.

[0236] The WTRU may determine which WTRU(s) are to monitor the HARQ ACK / NACK feedback associated with the transmission of the member WTRU based on the QoS of the PDU / reference-signal transmitted in the scheduled and / or indicated resource. In examples, the GC may determine (e.g., both) the member and / or the GC to monitor HARQ ACK / NACK feedback, if the priority of the PDU / reference-signal is greater than a (pre-)configured threshold. The GC may (e.g., otherwise) request the member WTRU to monitor the HARQ ACK / NACK feedback for itself (e.g., the GC). In examples, the WTRU may determine to overhear and / or monitor the HARQ ACK / NACK feedback for the member WTRU if the latency requirements (e.g., delay budget) of the PDU / reference-signal is smaller than a (pre-)configured threshold. This approach may reduce the signaling overhead of the resource-request procedure, for example, by allowing the GC to autonomously schedule the retransmission resource for the member WTRU without waiting for resource-request.

[0237] A WTRU may indicate information about the receiver(s) of its transmission. A WTRU (e.g., member WTRU) may indicate to another node (e.g., GC, gNB) information regarding the receiver of the PDU / reference-signal, which may help other node(s), such as the GC, to determine whether to monitor and / or overhear the HARQ ACK / NACK feedback to the member WTRU. The member WTRU may indicate one or more of the following information of the receiver: the location of the receiver (e.g., zone ID); or the link quality between the receiver and itself. For example, the WTRU may indicate the RSRP of the link between itself and the receiver. For example, the WTRU may indicate the distance between itself and the receiver.

[0238] A WTRU may request another WTRU (e.g., a second WTRU) to monitor HARQ ACK / NACK for its (e.g., the second WTRU’s) transmission. For example, a WTRU (e.g., member WTRU) may request a first (e.g., one) WTRU to monitor and / or overhear HARQ ACK / NACK feedback for itself (e.g., the first WTRU). The WTRU may request the GC to monitor and / or overhear HARQ ACK / NACK feedback for itself (e.g., the GC). The WTRU may request an assistant WTRU, which may be connected with a member WTRU (e.g., have an ideal connection with the member WTRU), to monitor and / or overhear HARQ ACK / NACK feedback for itself (e.g., the WTRU). The WTRU may (e.g., then) send a message to a (e.g., another) node (e.g., gNB, GC, receiver WTRUs) to indicate which WTRU(s) may monitor the HARQ ACK / NACK feedback associated with its (e.g., the WTRU’s) transmission. For sending the message to another WTRU (e.g., a second WTRU), a first WTRU may use one or any combination of a SCI, a PC5 MAC CE, and / or a PC5 RRC. For sending the message to the gNB, the first WTRU may use UCI, MAC CE, or RRC.

[0239] A WTRU may request the member WTRU to retransmit a PDU / reference-signal. For example, one WTRU (e.g., the GC) may request another WTRU (e.g., the member WTRU) to retransmit a PDU / reference-signal. In examples, the WTRU may schedule a retransmission resource to the member WTRU and request the member WTRU to retransmit a PDU / reference-signal. A (e.g., such) request may be indicated via a HARQ ID. The WTRU may indicate the HARQ ID and retransmission indication to request the WTRU to transmit the PDU / reference-signal. The indicated HARQ ID may be associated with the initial transmission of the PDU / reference-signal. In examples, the GC may request the member WTRU to retransmit a PDU / reference-signal. If the member WTRU receives the retransmission request, may determine to retransmit the indicate PDU / reference-signal. The WTRU may select the resource by itself (e.g., autonomous resource selection by the WTRU) and / or may use the resource indicated and / or scheduled by the other node (e.g., gNB or the GC).

[0240] A WTRU may determine whether to request the WTRU to retransmit a PDU / reference-signal.

[0241] The WTRU may determine to request the member WTRU to retransmit a PDU / reference-signal and / or schedule and / or indicate retransmission resource for the member WTRU based on one or more of the following: the WTRU detecting HARQ NACK or DTX from the receiver; a HARQ ACK / NACK feedback reception being deprioritized; the reception of the resource-request for retransmission from the member WTRU; or the WTRU failing to decode / receive the PDU / reference-signal from the member WTRU.

[0242] The WTRU may determine to request the member WTRU to retransmit a PDU / reference-signal and / or schedule and / or indicate retransmission resource for the member WTRU based on the WTRU detecting HARQ NACK or DTX from the receiver. For example, the WTRU may determine to monitor and / or overhear the HARQ ACK / NACK feedback for the member WTRU. The WTRU may (e.g., if theWTRU receives a HARQ NACK feedback from the receiver) request the member WTRU to retransmit the PDU / reference-signal. If DTX is detected (e.g., no HARQ feedback received), the WTRU may (e.g., also) request the member WTRU to retransmit the PDU / reference-signal.

[0243] The WTRU may determine to request the member WTRU to retransmit a PDU / reference-signal and / or schedule and / or indicate retransmission resource for the member WTRU based on whether HARQ ACK / NACK feedback reception is deprioritized. For example, the WTRU may request the member WTRU to retransmit the PDU / reference-signal if the HARQ ACK / NACK feedback reception is deprioritized. The resource associated with the HARQ ACK / NACK may conflict with a prioritized transmission and / or reception of the GC. The WTRU may (e.g., then) determine to drop the HARQ ACK / NACK feedback reception. The WTRU may (e.g., then) request the member WTRU to retransmit the associated PDU / reference-signal.

[0244] The WTRU may determine to request the member WTRU to retransmit a PDU / reference-signal and / or schedule and / or indicate retransmission resource for the member WTRU based on reception of the resource-request for retransmission from the member WTRU. For example, both the GC and the member WTRU may monitor HARQ ACK / NACK feedback from the receiver.

[0245] The WTRU may determine to request the member WTRU to retransmit a PDU / reference-signal and / or schedule and / or indicate retransmission resource for the member WTRU based on if / whether the WTRU fails to decode / receive the PDU / reference-signal from the member WTRU. For example, the WTRU may (e.g., first) decode the SCI associated with the transmission in the scheduled and / or indicated resource by the member WTRU. The WTRU may receive an indication in the SCI (e.g., the destination ID in the second stage SCI) indicating that the WTRU is a receiver of the transmission (e.g., it is one of the receivers of the transmission). The WTRU may (e.g., then) request the member WTRU to retransmit the PDU / reference-signal, for example, if it (e.g., the WTRU) fails to receive the message successfully.

[0246] A WTRU (e.g., GC) may schedule a retransmission resource for the member WTRU. The GC may (e.g., first) schedule a resource to a member WTRU for initial transmission. The WTRU may (e.g., then) decode and / or overhear the PSFCH associated with the scheduled resource. The WTRU may determine whether to schedule the retransmission resource based on whether the WTRU detects ACK / NACK / DTX in the associated HARQ ACK / NACK feedback resource. The WTRU may be configured to perform one or more of the following.

[0247] A WTRU (e.g., GC) may be (pre-)configured as a GC to support member WTRU(s) and / or maximize distance to overhear and / or monitor HARQ ACK / NACK feedback for the member WTRU(s). The WTRU may receive information regarding a zone ID associated with the receiver of the member WTRU. The WTRU may determine whether to overhear the HARQ ACK / NACK feedback for the member WTRU.The WTRU may send the decision to the member WTRU, for example based on the distance between itself and the member WTRU. For example, if the distance between the GC and the receiver is larger than a threshold, the WTRU may monitor the HARQ ACK / NACK feedback for the member WTRU.

[0248] The WTRU may schedule and / or indicate transmission resource(s) for the member WTRU for the initial transmission (e.g., in a (pre-)configured sidelink grant).

[0249] If the WTRU determines to overhear HARQ ACK / NACK feedback for the member WTRU, the WTRU may decode the SCI associated with the transmission of the scheduled resource (e.g., to determine whether it is HARQ enabled / disabled transmission).

[0250] If SCI indicates the transmission is HARQ enabled, the WTRU may decode the PSFCH associated with the scheduled resource and / or determine whether to schedule a retransmission resource for the WTRU based on the of the sequence detected in the associated PSFCH.

[0251] If NACK / DTX is detected, the WTRU may schedule a retransmission resource for the WTRU.

[0252] Resource usage reporting may be performed.

[0253] The gNB may offload the sidelink scheduling for the GC. The gNB may (e.g., should) be aware of the sidelink transmission situation for the group and / or whether the group is underutilize or needs more resources for sidelink transmission. A reporting procedure may be configured such that the network is aware of its sidelink resource (e.g., as described herein).

[0254] A WTRU may report the resource usage of a (pre-)configured set of sidelink resources.

[0255] In examples, a WTRU (e.g., GC) may be (pre-)configured with a set of resources for a group. The WTRU may (e.g., then) indicate and / or schedule the (pre-)configured resources for the group (e.g., one or more member WTRUs and the WTRU itself). The WTRU may (e.g., then) send the resource-usage reporting of the (pre-)configured set of resources to the network. The WTRU may use one or more of UCI, MAC CE, and / or RRC messages to report the resource-usage to the network. Such reporting may help (e.g., enable) the network to be aware of the resource usage in the (pre-)configured sidelink resource for the group. The WTRU may be (pre-)configured with an evaluation period to determine the resource usage of the set of (pre-)configured resources for the group. The WTRU may (e.g., if the WTRU evaluates the resource usage of the resources) report one or more of the following information associated with the resource usage of the (pre-)configured resources for the group: the resource usage of a (pre-)configured set of resources for the group; the resource usage of a subset of a (pre-)configured resources for the group (e.g., in which each subset of resource may be scheduled to a (e.g., one) WTRU in the group); the resource-request information from one or more WTRUs in the group; scheduling information of the set of resources for the group; or resource utilization of one or more member WTRUs.

[0256] The WTRU may report the resource usage of a (pre-)configured set of resources for the group. For example, the WTRU may report the number and / or percentage of the used and / or unused resources during the evaluation period. For example, the WTRU may report the resource utilization of (preconfigured set of resources. For example, the WTRU may report the number and / or percentage of the scheduled and / or non-scheduled resources from the set of resource for the group. For example, the WTRU may report the resource usage by a (e.g., each) WTRU in the group. The GC may report the number and / or percentage of the resources used by a (e.g., each) WTRU in the group (e.g., each member WTRU and / or for itself). For example, the GC may report the number and / or percentage of the resources scheduled for a (e.g., each) WTRU in the group. For example, the WTRU may report the resource utilization of a (e.g., each) WTRU in the group.

[0257] The WTRU may report the resource usage of a subset of a (pre-)configured resources for the group, in which a (e.g., each) subset of resource(s) may be scheduled to a (e.g., one) WTRU in the group. For example, the GC may receive multiple configured grants for the group. The WTRU may (e.g., then) schedule and / or indicate a (e.g., one) configured grant for a (e.g., one) member WTRU. The WTRU may (e.g., then) report to the gNB the resource usage of the configured grant (e.g., which may be used by the member WTRU).

[0258] The WTRU may report the resource-request information from one or more WTRUs in the group. For example, the WTRU may report the number of resources requested by a WTRU (e.g., one WTRU, each WTRU, multiple WTRUs, a set of WTRUs, and / or all WTRUs) in the group.

[0259] The WTRU may report scheduling information of the set of resources for the group. For example, if the WTRU receives of a set of resources for the group, the WTRU may schedule different subset of resources to a (e.g., each) member WTRU. The WTRU may (e.g., then) report its scheduling information to the gNB to indicate which WTRU is using which subset of resources for the group.

[0260] The WTRU may report resource utilization of one or more member WTRUs. For example, the GC may (e.g., first) receive a set of resources for the group. It may (e.g., then) indicate and / or schedule a (e.g., each) subset of resources for a member WTRU in the group. The WTRU may (e.g., then) report the resource utilization of a (e.g., each) member WTRU in the group to the network. The resource utilization of a (e.g., each) member WTRU may be determined and / or obtained based on one or any combination of the following: reception of the resource usage reporting from the member WTRU; or monitoring the resource usage of the member WTRU.

[0261] The resource utilization of a (e.g., each) member WTRU may be determined and / or obtained based on reception of the resource usage reporting from the member WTRU. For example, a (e.g., each) member WTRU may be (pre-)configured to report the resource usage of the subset of resources assignedfor itself. The WTRU may be (pre-)configured to report the resource usage periodically and / or based on a triggering event (e.g., the resource utilization of the subset of resources is smaller than a (pre-)configured threshold or greater than a (pre-)configured threshold).

[0262] The resource utilization of a (e.g., each) member WTRU may be determined and / or obtained based on monitoring the resource usage of the member WTRU. For example, the GC may monitor transmission of the member WTRUs in the subset of resources scheduled for each member WTRU. The GC may (e.g., then) determine the resource utilization of a (e.g., each) member WTRU. The GC may (e.g., then) release the subset of resources scheduled for the member WTRU (e.g., if the resource utilization of the member WTRU is smaller than a (pre-)configured threshold). The GC may (e.g., alternatively) request the gNB to release the subset of resources scheduled by the WTRU. The GC may (e.g., alternatively) request the network to schedule different subset of resources for the member WTRU.

[0263] For example, the WTRU may report the resource usage of the (pre-)configured set of resources for the group periodically. For example, the WTRU may report the resource usage of the (pre-)configured resource for the group based on (e.g., one) a (pre-)configured triggering event. The WTRU may be (preconfigured with one or more of the following triggering events to report the resource usage of the set of resources for the group: if the resource usage of the set of (pre-)configured resources for the group satisfies a (pre-)configured condition; if the resource usage and / or utilization of one or more member WTRUs satisfies a (pre-)configured conditions; or if the resource-request from the WTRUs in the group satisfies a (pre-)configured condition.

[0264] A triggering event may be the resource usage of the set of (pre-)configured resources for the group satisfying (pre-)configured condition(s). For example, the WTRU may report the resource usage of the (pre-)configured set of resources if the number and / or percentage of the used resources is smaller than a (pre-)configured threshold. For example, the WTRU may report the resource utilization of a (pre- )configured set of resources if the utilization of the resources is smaller than a (pre-)configured threshold and / or larger than another (pre-)configured threshold. For example, the WTRU may report the resource usage of the (pre-)configured set of resources if the number and / or percentage of the scheduled resources is smaller than a (pre-)configured threshold. For example, the WTRU may report the resource utilization of a (e.g., one) WTRU if the number and / or percentage of the resources used by the WTRU is greater than a (pre-)configured threshold or smaller than another (pre-)configured threshold. For example, the WTRU may report the resource utilization of a WTRU and / or the (pre-)configured set of resources for the group if the number and / or percentage of the resource scheduled for the WTRU is larger than a (pre-)configured threshold and / or smaller than a (pre-)configured threshold.

[0265] A triggering event may be the resource usage and / or utilization of one or more member WTRUs satisfying a (pre-)configured condition(s). For example, The WTRU may (e.g., then) perform resource usage reporting of the member WTRU to the gNB if the resource utilization of the member WTRU is smaller than a (pre-)configured threshold.

[0266] A triggering event may be the resource-request from the WTRUs in the group satisfying (preconfigured condition(s). For example, the WTRU may report the resource usage of the set of resources for the group if the number of requested resources from the WTRUs is greater than a (pre-)configured threshold. For example, the WTRU may send an indication to the network if the number of requested resources from the WTRUs in the group is larger than a (pre-)configured threshold.

[0267] FIG. 7 depicts an example of a WTRU being triggered to send an indication of resource usage to the network (e.g., as the resource utilization in a resource usage evaluation window is smaller than a (pre- )configured threshold).

[0268] As shown in FIG. 7, the GC may receive a sidelink configured grant from the gNB for the group. The WTRU may be (pre-)configured with a resource usage evaluation duration, in which the WTRU may report the resource usage of the (pre-)configured grant if the resource utilization of the (pre-)configured grant is smaller than the (pre-)configured threshold. As shown in FIG. 7, the WTRU may be (pre- )configured to report the resource usage of the configured grant if the resource utilization of the configured grant is smaller than, for example, approximately 50%. In an evaluation period, the WTRU may determine that the resource utilization of the configured grant is smaller than approximately 50% and it (e.g., the WTRU) may report the resource usage of the configured grant to the gNB.

[0269] A WTRU (e.g., GC) may release a subset of resources scheduled to a member WTRU. In examples, a WTRU (e.g., GC) may receive a set of resources (e.g., sidelink and / or uplink resources) from the network, which may be used by one or more member WTRUs. The WTRU may (e.g., then) indicate and / or schedule the indicated subset of resources to the member WTRUs in the group. The WTRU may (e.g., then) determine the resource usage of the subset of resources. For example, the WTRU (e.g., GC) may (e.g., then) determine to release the subset of resources. The WTRU may (e.g., alternatively) determine to reassign and / or reschedule the subset of resources to another WTRU (e.g., a configured grant). A decision may be determined based on one or more of the following: resource utilization of the subset of resources; an indication from the member WTRU; or an indication from the gNB.

[0270] The WTRU may determine to reassign and / or reschedule the subset of resources to another WTRU based on resource utilization of the subset of resources. For example, the WTRU may release the subset of resources (e.g., a configured grant) scheduled for the member WTRU if the resource utilization of the subset of resources is smaller than a (pre-)configured threshold. For example, the WTRU mayreschedule the subset of resources to another WTRU if the resource utilization of the subset of resources is smaller than a (pre-)configured threshold.

[0271] The WTRU may determine to reassign and / or reschedule the subset of resources to another WTRU (e.g., in the group) based on an indication from the member WTRU. For example, the WTRU (e.g., GC) may receive a release message from the member WTRU, which may request the WTRU to release a subset of resources. The GC may (e.g., then) reassign the subset of resources (e.g., a configured grant) to another WTRU in the group.

[0272] The WTRU may determine to reassign and / or reschedule the subset of resources to another WTRU based on an indication from the gNB. For example, the gNB may release a subset of resources from a (e.g., one) member WTRU. A release message may be conveyed to the GC. The GC may (e.g., then) send the release indication to the member WTRU. A release indication may (e.g., can) be transmitted using one or any combination of SCI, PC5 MAC CE, and / or PC5 RRC message. The WTRU may (e.g., then) reschedule the subset of resources for a (e.g., another) WTRU in the group.

[0273] A WTRU (e.g., GC) may perform sidelink resource usage reporting. The WTRU may be configured (e.g., first (pre-)configured) with a set of resources (e.g., a resource pool, one or more (preconfigured grants, and / or the like) for the group. The WTRU may (e.g., then) trigger SL resource usage reporting if the amount and / or percentage of the used resources from the group is smaller than a (pre- )config ured threshold and / or the amount of request resources is greater than a (pre-)configured threshold. The WTRU may be (pre-)configured to perform one or more of the following.

[0274] A WTRU (e.g., GC) may receive (e.g., from the network) a (pre-)configured grant for the group, the duration for SL resource usage evaluation, and / or a threshold (e.g., percentage of resource usage, amount of request resources) to trigger SL resource usage reporting. The WTRU may receive sidelink resource request(s) from member WTRUs. The WTRU may schedule a sidelink resource for one or more member WTRUs. The WTRU may, for a (e.g., each) SL resource usage evaluation period, determine the resource usage of the group. For example, the WTRU may determine whether the SL resource usage is smaller than the (pre-)configured threshold. For example, the WTRU may determine whether the amount of request resource is larger than a (pre-)configured threshold. The WTRU may send the resource usage reporting to the gNB (e.g., in RRC message such as UAI), for example if the resource usage of the group satisfies the threshold.

[0275] Although features and elements described above are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without other features and elements.

[0276] Although the implementations described herein may consider 3GPP specific protocols, it is understood that the implementations described herein are not restricted to this scenario and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well.

[0277] The processes described above may be implemented in a computer program, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM disks, and / or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

CLAIMS1. A wireless transmit / receive unit (WTRU) comprising: a processor configured to: determine that data is available for sidelink transmission; determine a sequence based on a property of the data, wherein the sequence is associated with a sidelink scheduling request (SL-SR); determine a sidelink resource based on a mapping associated with the SL-SR; send the SL-SR via the determined sidelink resource; receive a sidelink grant to use the sidelink resource; determine that the sidelink grant is smaller than a threshold; determine that a group coordinator (GC) is an intended receiver of a transmission; based on the determination that the sidelink grant is smaller than the threshold and the determination that the GC is an intended receiver of the transmission, include an indication of a buffer status associated with the WTRU in the transmission; and send the transmission via the sidelink resource, wherein at least a portion of the data is sent via the transmission.

2. The WTRU of claim 1, wherein the indication of the buffer status is indicated via a sidelink medium access control element (SL-MAC CE), a sidelink-buffer status request (SL-BSR), or a sidelink dynamic scheduling request (SL-DSR).

3. The WTRU of any one of claims 1 or 2, wherein the SL-SR comprises an indication of at least one of a range of a number of protocol data units (PDUs) in a buffer, a range of a number of requested resources, a range of priorities associated with data in the buffer, or a range of PDU set delay budgets (PSDBs) associated with data in the buffer.

4. The WTRU of any one of claims 1 -3, wherein the transmission further comprises a request for a second sidelink resource.

5. The WTRU of any one of claims 1-4, wherein the threshold is associated with a number of PDUs in a buffer associated with the WTRU.

6. The WTRU of any one of claims 1-5, wherein the property of the data comprises at least one of a qualityof service (QoS) associated with the data or a quantity of the data.

7. The WTRU of any one of claims 1 -6, wherein the data available for sidelink transmission comprises a PDU or a reference-signal.

8. The WTRU of any one of claims 1-7, wherein the SL-SR comprises an indication of whether the data comprises a PDU or a reference signal.

9. A method comprising: determining that data is available for sidelink transmission; determining a sequence based on a property of the data, wherein the sequence is associated with a sidelink scheduling request (SL-SR); determining a sidelink resource based on a mapping associated with the SL-SR; sending the SL-SR via the determined sidelink resource; receiving a sidelink grant to use the sidelink resource; determining that the sidelink grant is smaller than a threshold; determining that a group coordinator (GC) is an intended receiver of a transmission; based on the determination that the sidelink grant is smaller than the threshold and the determination that the GC is an intended receiver of the transmission, including an indication of a buffer status associated with the WTRU in the transmission; and sending the transmission via the sidelink resource, wherein at least a portion of the data is sent via the transmission.

10. The method of claim 9, wherein the indication of the buffer status is indicated via a sidelink medium access control element (SL-MAC CE), a sidelink-buffer status request (SL-BSR), or a sidelink dynamic scheduling request (SL-DSR).11 . The method of any one of claims 9 or 10, wherein the SL-SR comprises an indication of at least one of a range of a number of protocol data units (PDUs) in a buffer, a range of a number of requested resources, a range of priorities associated with data in the buffer, or a range of PDU set delay budgets (PSDBs) associated with data in the buffer.

12. The method of any one of claims 9-11 , wherein the transmission further comprises a request for a second sidelink resource.

13. The method of any one of claims 9-12, wherein the threshold is associated with a number of PDUs in a buffer associated with the WTRU.

14. The method of any one of claims 9-13, wherein the property of the data comprises at least one of a quality of service (QoS) associated with the data or a quantity of the data.

15. The method of any one of claims 9-14, wherein the data available for sidelink transmission comprises a PDU or a reference-signal.

Images